про час останнього тестування в нашій лабораторії жорстких дисків з інтерфейсом SCSI будь-яких революційних змін на ринку SCSI-вінчестерів не відбулося. Природно, що всі компанії за минулий рік анонсували нові моделі дисків, але ці інновації були пов'язані перш за все з підтримкою нового інтерфейсу Ultra SCSI 320 з максимальною пропускною здатністю 320 Мбайт / с. Решта ж характеристики жорстких дисків не зазнали істотних змін.
Аналогічна ситуація спостерігається і на ринку RAID-контролерів. У модельному ряду почали з'являтися контролери з інтерфейсом Ultra SCSI 320. Звичайно, підтримка нового інтерфейсу сама по собі ще не означає зростання продуктивності - дискові підсистеми з інтерфейсом Ultra SCSI 160 за певних умов дозволяють отримати не менше продуктивне рішення. У той же час очевидно, що новий інтерфейс дозволяє будувати дискові підсистеми з великим запасом по масштабованості. Наприклад, швидкість лінійного читання сучасних SCSI-дисків становить приблизно 50 Мбайт / с. Теоретично пропускна здатність шини стане вузьким місцем тільки при використанні більше трьох дисків на одному каналі, об'єднаних в RAID-масив. У реальних же умовах, враховуючи, що запити на читання і запис носять переважно непослідовно, а випадковий характер, можна очікувати, що вплив пропускної здатності шини почне позначатися при об'єднанні в RAID-масив п'яти і більше дисків на одному каналі. Тому актуальність використання RAID-контролерів і дисків з інтерфейсом Ultra SCSI 320 проявляється при побудові дискових підсистем з кількістю дисків більше п'яти на одному каналі RAID-контролера.
З вищевикладених причин ми визнали можливим об'єднати в нашому тестуванні RAID-контролери як з інтерфейсом Ultra SCSI 160, так і з інтерфейсом Ultra SCSI 320. Ми також використовували SCSI-диски з двома різними інтерфейсами. Однак, з огляду на, що в тестуванні застосовувалися набори всього з чотирьох дисків, які, крім того, групувалися за два на кожен канал RAID-контролера, пропускна здатність інтерфейсу Ultra SCSI 160 не була вузьким місцем в тестах і не могла вплинути на результати тестування.
Говорячи про продуктивність жорсткого диска, мають на увазі його продуктивність, що вимірюється тестовими утилітами без використання RAID-контролера, тобто при підключенні тестованого диска безпосередньо до SCSI-контролера. Правда, в такому способі тестування є свої підводні камені. Справа в тому, що результати цього тестування не можна просто екстраполювати на набір декількох дисків, що об'єднується за допомогою RAID-контролера в дисковий масив. А адже саме таке рішення найбільш актуально при побудові дискових серверних підсистем. У цьому сенсі застосування більш продуктивних дисків не означає, що в поєднанні з RAID-контролером можна буде отримати більш продуктивне рішення, ніж при використанні з тим же контролером набору менш продуктивних дисків.
Тестування RAID-контролерів для порівняння їх один з одним без прив'язки до набору використовуваних жорстких дисків взагалі позбавлено будь-якого сенсу. Тобто в принципі не можна абстрактно стверджувати, що один RAID-контролер продуктивніше іншого, не обумовлюючи при цьому про поєднання з яким набором дисків йдеться. Тому ще раз підкреслимо, що при порівнянні дискових підсистем потрібно говорити саме про поєднання певного RAID-контролера з конкретним набором дисків.
Цей висновок, до якого ми прийшли в ході тестування серверів, ліг в основу проведення даного тестування, головним завданням якого був пошук оптимального поєднання (отакою «солодкої парочки») RAID-контролера і набору жорстких дисків. Ми спробували не просто порівняти різні рішення і вибрати найбільш продуктивне, а підібрати кожному RAID-контролеру оптимальний набір SCSI-дисків.
Методика тестування
Утиліта IOmeter є синтетичним тестом, що дозволяє прецизійно налаштовувати тест на вимірювання продуктивності жорстких дисків при виконанні ними специфічних завдань. Утиліта працює з неразбітие на логічні розділи жорсткими дисками, тому результати тестування не залежать від файлової структури, а вплив операційної системи мінімально.
Утиліта IOmeter дозволяє створювати різноманітні моделі доступу до дискової підсистеми, причому для конкретної моделі доступу можна змінювати наступні параметри:
- розмір запиту на передачу даних (Transfer Request Size);
- відсотковий розподіл випадкових / послідовних запитів (Percent Random / Sequential Distribution);
- відсотковий розподіл операцій читання / запису (Percent Read Write Distribution);
- відсоток доступу по даному запиту (Percent of Access Specification);
- кількість одночасно виконуваних окремих операцій введення / виводу (# of Outstanding I / Os).
З огляду на, що диски з SCSI-інтерфейсом призначені в першу чергу для використання в серверах, при тестуванні дисків ми використовували різні моделі доступу, типові для серверів. Таких моделей було три: FileServer, WebServer і DataBase.
Модель доступу FileServer створює навантаження на дискову підсистему, типову для файл-сервера. Характерно, що в цій моделі розглядаються різні за розміром запити на читання і запис. Розмір запиту варіюється від 512 байт до 64 Кбайт, а частка тих чи інших запитів в загальній моделі доступу задається ваговими коефіцієнтом участі даного запиту (відсоток доступу по даному запиту). Якщо, наприклад, запиту розміром 4 Кбайт присвоюється відсоток доступу по даному запиту рівний 60%, то це означає, що з 100 запитів 60 матимуть розмір 4 Кбайт. У моделі доступу FileServer 80% всіх операцій введення-виведення доводиться на читання і тільки 20% - на запис. Причому всі операції введення-виведення мають стовідсотково випадковий характер, що цілком типово для файл-серверів. Характеристики моделі доступу FileServer наведені в табл. 1.
Таблиця 1. Характеристики моделі доступу FileServer
Ваговий коефіцієнт запиту,%
Відсоток операцій читання
При використанні моделей доступу послідовного і випадкового читання / запису (Random Read, Random Write, Sequential Read і Sequential Write) розмір запиту не є фіксованою величиною і змінюється від 512 байт до 256 Кбайт так, що розмір кожного наступного запиту вдвічі більше попереднього. Тобто для кожної моделі доступу швидкість виконання дискових операцій обчислюється для розмірів запиту рівних 512 байт, 1, 2, 4, 8, 16, 32, 64, 128 і 256 Кбайт. Тому результати тестування при використанні моделей доступу Random Read, Random Write, Sequential Read і Sequential Write представляються у вигляді графіка залежності швидкості виконання дискових операцій від розміру запиту.
Для всіх емульованого моделей доступу ми встановлювали одне і те ж кількість одночасно виконуваних окремих операцій введення-виведення (# of Outstanding I / Os) рівне 4. Звичайно, якщо використовувати більше значення # of Outstanding I / Os, то і швидкість виконання дискових операцій виявиться вище, проте в даному випадку ми переслідували завдання не стільки отримати максимальне значення, допустиме для тієї чи іншої дискової підсистеми, скільки наблизити по можливості нашу емуляцію дискових операцій до реальних умов. Як показує практика, для переважної більшості серверних дискових підсистем значення # of Outstanding I / Os не перевищує 2-5 в режимі максимального навантаження, в чому можна переконатися, запустивши утиліту Performance і використовуючи лічильник Avg. Disk Queue Length для жорсткого диска. Саме тому ми і вибрали значення # of Outstanding I / Os рівне 4 для всіх моделей доступу.
Вимірюваним параметром у всіх тестах була швидкість виконання дискових операцій в Мбайт / с.
Як вже зазначалося, при тестуванні дискових підсистем ми використовували з кожним RAID-контролером набір з чотирьох однакових SCSI-дисків. При цьому з двоканальним RAID-контролером диски групувалися по два на кожен канал і встановлювалися в два кошики, кожна з яких підключалася до одного з каналів RAID-контролера, а при застосуванні одноканального RAID-контролера всі чотири диска встановлювалися в одну корзину, яка під'єднується до одному каналу контролера.
При тестуванні ми використовували один-єдиний RAID-рівень масиву - Level 5 як найбільш поширений в сучасних дискових серверних підсистемах початкового рівня. Цей рівень поєднує в собі як високу продуктивність, зростаючу пропорційно кількості об'єднуються в масив дисків, так і необхідний ступінь надійності зберігання даних за рахунок відносно невеликий надмірності.
На всіх RAID-контролерів встановлювався розмір страйп-блоку рівний 64 Кбайт. Крім того, всі RAID-контролери тестувалися в двох режимах кешування даних при їх запису на диск: Write Back, тобто відкладений запис, і Write Through, тобто наскрізна запис. Всі інші настройки RAID-контролерів використовувалися за замовчуванням.
Двухпроцесорний сервер Desten NavigatorDX728 (533) з процесором Intel Xeon 2,8 ГГц зібраний на базі системної плати Intel SE7501BR2 з набором мікросхем Intel E7501, що підтримує 533-мегагерцевого системну шину. При тестуванні ми використовували 2 Гбайт DDR266 пам'яті. Відзначимо також, що всі тестовані RAID-контролери встановлювалися в слот PCI-X (64 біт / 133 МГц), назад сумісний з PCI-шиною 64 біт / 66 МГц.
Результати тестування
Перш ніж переходити до опису результатів тестування для кожного RAID-контролера в окремо, розглянемо загальні важливі висновки, отримані нами в ході тестування.
Як вже зазначалося, крім емуляції роботи дискових підсистем, типових для файл-сервера, Web-сервера і сервера баз даних, нами було проведено тестування контролерів при різних розмірах запитів в режимах вибіркової і послідовного запису і читання. При цьому ми спочатку припускали, що, використовуючи дані про роботу RAID-контролера з різними за розміром запитами, можна буде спрогнозувати продуктивність контролера в будь-якої моделі доступу, використовуючи різні вагові коефіцієнти запитів.
Розглянемо типовий приклад емуляції режиму роботи файл-сервера. В даному випадку використовується вісім різних за розміром запитів з різними ваговими коефіцієнтами (табл. 1) при повністю випадковому доступі. В ході тестування контролера з різними за розміром запитами в режимі стовідсотково випадкового доступу при записі і читанні даних ми отримали наступні результати (табл. 5).
Таблиця 5. Результати тестування контролера в режимах читання і запису даних при повністю випадковому доступі при різних розмірах запитів
Режим читання, Мбайт / с
Режим запису, Мбайт / с
Використовуючи вагові коефіцієнти для кожного розміру запиту (табл. 1), можна спробувати передбачити, якою буде продуктивність контролера в режимі емуляції файл-сервера. Для цього необхідно скористатися наступною очевидною формулою:
де S - продуктивність контролера (в Мбайт / с) для моделі доступу FileServer;
Si read # 151; швидкість читання при i-му розмірі запиту;
Si write # 151; швидкість запису при i-му розмірі запиту;
ai # 151; ваговий коефіцієнт участі i-го запиту.
Коефіцієнти 0,8 і 0,2 в цій формулі відображають частку операцій читання (80%) і операцій запису (20%), що характерно для режиму емуляції FileServer.
Для вищенаведеного прикладу розрахунок за цією формулою дає результат 2,68 Мбайт / с.
Однак при тестуванні того ж RAID-контролера при емуляції режиму доступу FileServer, тобто коли в саму модель доступу до дискової підсистеми закладаються різні за розміром запити з різними ваговими коефіцієнтами при виконанні в заданій пропорції операцій запису і читання, результати тестування виходять зовсім іншими. Наприклад, для розглянутого вище прикладу результат становить 1,9 Мбайт / с, тобто на 40% нижче очікуваного.
Аналогічна ситуація спостерігається і для інших моделей доступу - WebServer і DataBase. При цьому характерно, що розрахунковий (очікуваний) результат продуктивності контролера може виявитися як вище, так і нижче реально спостережуваного. Проаналізувавши для всіх контролерів різницю між дійсною і розрахунковою продуктивністю для всіх моделей доступу, ми прийшли до висновку, що будь-якої закономірності в даному випадку не простежується. Розрахунковий результат продуктивності для різних контролерів при одній і тій же моделі доступу може виявитися як вище, так і нижче реально спостережуваного результату.
Отже, одночасне використання різних за розміром запитів при емуляції того чи іншого режиму доступу призводить до того, що ці запити корелюють один з одним таким чином, що результат, отриманий для RAID-контролера, відрізняється від результату, який можна розрахувати на підставі даних про продуктивність контролера при роботі з окремими запитами. У разі використання моделі доступу FileServer це означає, що для коректного розрахунку продуктивності контролера необхідно в розглянутої вище формулою врахувати ще і кореляційні члени:
де коефіцієнти c xij (Si read. Si read) визначають кореляційні співвідношення між запитами різної довжини.
Звичайно, використовувати цю формулу для практичних обчислень не має сенсу, оскільки самі кореляційні коефіцієнти не відомі. Єдине, що ми хочемо підкреслити, приводячи таку довгу формулу, - це той факт, що знання одних лише швидкостей читання і запису при різних розмірах запитів (Si read. Sj write) ще не досить, щоб можна було передбачити поведінку контролера в моделі доступу, коли одночасно використовується кілька запитів. Мабуть, це найважливіший висновок, до якого ми прийшли в ході тестування.
Після загальних зауважень, справедливих для всіх контролерів, перейдемо до докладного розгляду результатів тестування кожного контролера окремо.
RAID-контролери
Таблиця 6. Технічні характеристики RAID-контролерів
Adaptec SCSI RAID 2120S
Adaptec SCSI RAID 2200S
SCSI-диски
аждий з даних RAID-контролерів тестувався з чотирма наборами SCSI-дисків: Fujitsu MAM3367MC U160 SCSI 36.7Gb, IBM Ultrastar 36Z15 IC35L036UCPR15-X U160 SCSI 36.7Gb, Seagate Cheetah X15 36LP ST336752LC U160 SCSI 36.7Gb, Seagate Cheetah 15K.3 ST318453LW U320 SCSI 18.4Gb. Технічні характеристики тестованих жорстких дисків представлені в табл. 7.
Таблиця 7. Технічні характеристики жорстких дисків
Fujitsu MAM3367MC U160 SCSI
IBM Ultrastar 36Z15 IC35L036UCPR15-X U160 SCSI
Seagate Cheetah X15 36LP ST336752LC U160 SCSI
Seagate Cheetah 15K.3 ST318453LW U320 SCSI