Dedicated Server

SCSI RAID против SATA RAID - кто кого? Поставив вопрос ребром - какой же RAID объективно лучше, на SCSI или на SATA винчестерах.

Чтобы ответить на этот вопрос, сначала вспомним аргументы сторонников классических RAID-массивов на SCSI-винчестерах и поглядим, какие из них соответствуют нынешней действительности, а какие безнадежно устарели и лишь вводят всех в заблуждение.

PRO и CONTRA

Основные аргументы в защиту SCSI RAID таковы:

1. SCSI интерфейс существует дольше, чем IDE (и намного дольше, чем SATA), поэтому он более стабилен и отработан.
2. SCSI RAID стоит как минимум вдвое дороже IDE (SATA) RAID - а чем вещь дороже, тем она лучше.
3. SCSI поддерживает multi-threading интерфейс, соответственно будет лучше работать на сильно нагруженных серверах.
4. Раздельные шины (буферизация шины в контроллере SCSI) уменьшает нагрузку на системную шину (PCI) компьютера.
5. Диски со SCSI интерфейсом более надежны, чем с IDE (SATA) интерфейсом.
6. SCSI RAID быстрее, чем IDE (SATA) RAID.
7. IDE (SATA) RAID нельзя кластеризовать.

Разберем эти аргументы по пунктам.

1. Да, интерфейс SCSI существует очень долго. За это время умерло несколько системных шин (MCI, ISA, EISA), сменилось множество поколений процессоров, памяти и сетевых интерфейсов. Да и сам SCSI за это время кардинально изменился - как в плане программного интерфейса, так и аппаратного решения (чего стоит один переход на дифференциальные сигналы интерфейса, произошедший, между прочим, всего несколько лет назад). Если бы SCSI не менялся вслед за ростом требований к системам, он был бы там же, где сейчас находится шина ISA. Ну и где тут стабильность? Текущий интерфейс SCSI-320 моложе, чем текущий SerialATA 1.0 - при этом все равно за ним тянется такой шлейф вынужденных компромиссов и устаревших концепций, что даже разработчикам интерфейса из SCSI group ясно его будущее (следующий SCSI интерфейс станет последовательным и на аппаратном уровне во многом будет копировать решения SerialATA).

Да, SerialATA спроектирован относительно недавно и практически "с чистого листа" (причем целый ряд идей в нем позаимствован из SCSI - например, концепция очереди команд, разделение фаз получения команды и ее исполнения). Однако его структура позволяет относительно просто реализовать аппаратные конверторы SATA-EIDE и, таким образом, опереться на многолетний опыт развития обычного IDE интерфейса в "десктопных" IDE HDD. Такие конверторы, разумеется, не позволяют в полной мере использовать все преимущества нового интерфейса, но зато являются "мостиком" от хорошей проработки решений прошлого к высокой скорости решений будущего.

2. SCSI RAID действительно дороже IDE RAID. Причем дороже как RAID контроллеры, так и собственно винчестеры для этих массивов. Однако, как и везде в области HiTech индустрии, такое ценообразование имеет очень слабую связь с реальными характеристиками продукта.

Возьмем, например, RAID- контроллеры. Я уже отмечал, что один из лучших серверных SATA RAID Intel SRCS14L фактически представляет собой хорошо известный контроллер SCSI RAID Intel SRCU31L, из которого выкинута микросхема SCSI-интерфейса, а вместо нее поставлены две микросхемы SATA-интерфейса. Процессор, память, логика работы контроллера - все сохранено практически без изменений, и, тем не менее, Intel продает этот контроллер почти вдвое дешевле, чем текущие свои SCSI RAID контроллеры. Конечно, микросхема SCSI-интерфейса от LSI Logic дороже, чем две микросхемы SATA-Link от Silicon Image, - но совсем не настолько, насколько SCSI-версия этого RAID дороже SATA-версии. То есть ценообразование во многом вызвано чисто маркетинговыми соображениями - поскольку SCSI-версия конкурирует с дорогими топ-моделями контроллеров от Mylex и Adaptec, на нее и цены "заряжены" на уровень конкурентов, в то время как SATA-версия конкурирует с более дешевыми за счет массовости изделиями от 3Ware и Promise, и на нее приходится ставить более низкую цену.

Отражает ли эта разница в цене разницу в характеристиках контроллеров? Вряд ли - они ведь конструктивно почти идентичны, так что надежность их заведомо одинаковая, а что касается скорости работы, то любой специалист знает, что для RAID-массива вовсе не интерфейс с HDD определяет его скоростные параметры. Особенно при том, что более дешевый SRCS14L имеет 4 независимых канала к HDD со скоростью в 150Mb/s каждый, а более дорогой SRCU31L - всего один канал со скоростью в 160Mb/s.

Про связь цены и характеристик HDD мы поговорим в п.5.

3. Да, SCSI поддерживает multi-threading (многопоточность) запросов. И что из того? Ведь ни Windows-2000 Server (как, собственно, и любой продукт Microsoft на ядре NT), ни набирающий популярность Linux не имеют multi-threading дисковых подсистем, так что при использовании этих ОС толку с поддержки многопоточности в контроллере HDD ровно ноль. Конечно, если Вы используете AIX, SCO или на худой конец Solaris или OS/2 Server, и у Вас в этой системе намечается нагрузка на уровне более сотни пользователей, одновременно и интенсивно работающих с сервером, - тогда да, Вы сможете почувствовать преимущества multi-threading дисковой подсистемы на основе SCSI. Если нет - то, увы, "колеса от Феррари вряд ли помогут Вашему велосипеду ездить быстрее".

Разумеется, ситуация постепенно меняется. В дисковую подсистему Linux предположительно собираются встраивать многопоточные драйвера HDD, что повысит область реальной применимости многопоточности дисковых массивов, - но, с другой стороны, SATA RAID-массивы на контроллерах высокого класса (таких, как Intel SRCS14L) также поддерживают многопоточность запросов, да и на уровне HDD новые SATA винчестеры WD740 Raptor поддерживают эту технологию, так что налицо исчезновение различий между SCSI и SerialATA в этом вопросе.

4. Вопрос с раздельными шинами еще яснее. Дело в том, что простые IDE контроллеры, представлявшие собой примитивный буфер между шиной ISA и IDE-винчестером, давно канули в небытие (вместе с шиной ISA). Все современные IDE контроллеры, поддерживающие режимы DMA mode, вынуждены так или иначе реализовывать разделение шин, буферизацию команд и данных и не имеют никакого "непосредственного" подключения IDE шины к шине PCI компьютера. Тем более это действительно для SerialATA контроллера. Вопрос загруженности шины, таким образом, является лишь вопросом качества реализации контроллера и его драйверов. Для примера: уже упоминавшийся SATA-контроллер SRCS14L обеспечивает минимальную, близкую к нулю, загрузку процессора компьютера при выполнении дисковых операций - что означает, между прочим, загруженность шины PCI при его работе почти исключительно дисковым трафиком (то есть ситуацию наилучшую из возможных для любого, в том числе и SCSI, контроллера дисков).

5. Надежность SCSI-дисков общеизвестна, и она имеет даже четкое числовое выражение в параметре MTBF (Mean Time Between Failure - или, в русской терминологии, наработка на отказ). Типичная MTBF хорошего SCSI-диска - 1.200.000 часов, а для обычных "десктопных" IDE-дисков она составляет 400.000-500.000 часов. На первый взгляд разница не так уж велика - но на практике она означает, что обычные IDE-диски отказывают в несколько раз чаще, чем их SCSI-собратья.

С другой стороны, вероятность отказа в течение года одного из четырех дисков массива RAID Level-10 составляет около 12% в случае использования дешевых "десктопных" IDE HDD и около 4% при использовании наиболее надежных SCSI HDD. Даже если не принимать во внимание заводскую гарантию на HDD, вероятная разница в финансовом ущербе при использовании "ненадежных" IDE HDD вместо надежных SCSI для Вас составит 12% от цены IDE HDD - 4% от цены SCSI HDD. В конкретных цифрах это будет, например, вот столько:

12% от 75$ (цена 40Gb IDE HDD Hitachi IC35L040AVVN07-0) = 9$
4% от 215$ (цена 36Gb SCSI HDD Hitachi IC35L036UCDY10) = 8.6$
Итого разница = 0.4$ в год

В то же время за рассматриваемый массив из 4 дисков SCSI мы переплатили, по сравнению с его IDE аналогом, 4*(215-75)=560$ даже без учета RAID-контроллера (который для SCSI еще как минимум на 100$ дороже, чем для IDE, ну да бог с ним). Разница в цене дисков не только покрывает вероятный финансовый ущерб от "ненадежности" IDE за 1400 лет (!) эксплуатации массива, но и означает, что мы могли бы купить для массива 7 запасных IDE-дисков, и у нас бы еще осталось 34.5$ на то, чтобы отпраздновать столь удачное решение.

"А надежность?" - спросите Вы. А что надежность? О какой надежности мы говорим - о надежности хранения данных в массиве или о надежности обеспечения бесперебойной работы дискового массива? Вряд ли нас всерьез интересует надежность конкретного HDD - особенно после вышеприведенных выкладок, демонстрирующих явную финансовую невыгодность "надежных" SCSI-решений:

Рассмотрим ситуацию подробнее. Предположим, один из четырех дисков в описанном выше RAID Level-10 уже отказал. Shit happens, как говорят американцы. Однако для того мы и строили RAID Level-10, чтобы в подобной ситуации не только обеспечить сохранность данных и непрерывную работу, но и не допустить хоть сколько-нибудь ощутимого снижения производительности дискового массива. Что же должно после этого случиться, чтобы мы потеряли столь ценные для нас данные? А вот что: должен отказать еще один диск из оставшихся трех - но не любой, а только один конкретный, работавший в паре с уже отказавшим. Вероятность такого отказа для дешевых IDE дисков (разумеется, не вообще любых, а определенных хорошо себя зарекомендовавших серий) составляет около 2% за год. Но это за целый год - а каким же интервалом уязвимости располагаем мы?

Предположим, что мы воспользовались разницей в цене IDE и SCSI подсистем и купили-таки хотя бы один запасной IDE HDD. В этом случае интервал уязвимости составит время, потребное нам на обнаружение дефекта, доставание запасного HDD из коробки, физическую замену дефектного HDD на запасной и перестроение (rebuild) RAID-массива. Перестроение RAID здесь процесс самый долгий, но и он занимает для описываемого массива Level-10, построенного на 40Gb HDD, не более 40 минут в фоновом режиме при средней загрузке сервера. Предположим также, что мы использовали SerialATA HDD - это позволит нам, при некоторой предусмотрительности, заменить HDD "на лету", без остановки сервера, даже не тратясь на Hot-Swap корзинки. Оповещение о неисправности HDD современные RAID-массивы умеют выдавать оперативно (даже в виде SMS на мобильник системного администратора), так что и тут интервал реакции минимален. Итого интервал уязвимости составит от 50 до 60 минут, не больше. Вероятность отказа одного IDE HDD за это время ничтожно мала - 0.0023%. А поскольку вероятность самой ситуации с выходом из строя первого винчестера на массиве 12%, мы получаем вероятность потери данных на таком массиве в течение года около 0.00027%, или примерно один случай на 370 тысяч работающих систем в год. Вероятность того, что вы разобьетесь насмерть на автомобиле по пути на работу, будете задавлены при переходе улицы или утонете, купаясь в пруду, несоизмеримо выше.

Разумеется, массив на SCSI HDD теоретически в несколько раз надежнее - однако, положа руку на сердце, много ли Вы видели организаций, где в столе системного администратора лежат запасные SCSI HDD для дискового массива, или где эти HDD установлены в серверах в режиме "горячего резерва" (hot-spare)? А если резервного HDD нет, то увеличившийся на время поиска замены интервал уязвимости сводит на нет всю повышенную надежность SCSI HDD. К тому же для параноиков-лентяев есть прекрасные SerialATA HDD Raptor от Western Digital, имеющие MTBF 1.200.000 часов и гарантию в 5 лет, в точности как у хороших SCSI HDD, при существенно меньшей, чем у последних, цене. Да еще и скорость у Raptor вполне конкурентоспособна с 10.000 rpm SCSI HDD. Та же самая надежность, та же самая скорость - за меньшие деньги и с SerialATA интерфейсом. Тезис об особой надежности SCSI явно остался в прошлом - да и стоит ли уповать на надежность отдельного диска, если все равно надо делать отказоустойчивый RAID?

6. SCSI RAID быстрее, чем IDE (SATA) RAID? Странное дело - как это может быть, если и контроллеры аналогичны (вспомним "сладкую парочку" Intel SRCS14L и SRCU31L), и параметры HDD близки (сравнение WD Raptor с типичными SCSI смотрите ниже), и интерфейс SerialATA в расчете на несколько HDD быстрее самых быстрых SCSI? И, в конце концов, за те же деньги в RAID-массив можно установить в несколько раз большее количество IDE винчестеров, чем SCSI, - что благотворно сказывается на производительности массива.

7. C кластеризацией тоже все понятно - Intel на своих контроллерах продемонстрировал, что нет никакой принципиальной разницы в интерфейсе HDD и что одинаково успешно могут кластеризоваться массивы и со SCSI, и с SATA интерфейсами, важно лишь, чтобы RAID-контроллеры поддерживали такую возможность. Странно было бы ожидать иного:

Фактически существует лишь одна объективная причина, делающая применение SCSI HDD и SCSI RAID оправданным, - это ситуация, когда или в применяемой OC нет нормальных (обеспечивающих хорошую производительность) драйверов для IDE и IDE RAID, или системный администратор не умеет правильно настраивать такую ОС для работы с IDE дисками. Какое-то время назад эта ситуация наблюдалась применительно к FreeBSD и Solaris, и отголоски ее до сих пор бродят в умах наиболее консервативных системных администраторов, хотя технически все проблемы уже решены.

Итак, с тезисами о "принципиальных преимуществах" SCSI перед ATA/SATA разобрались - пора поговорить о тестах скорости винчестеров с разными интерфейсами при различных (типичных и не очень) нагрузках.

Когда рассеялся дым...

На тест были выставлены следующие HDD (в порядке следования на диаграммах):

1. 15K rpm Seagate Cheetah X15-36LP (36.7 GB Ultra160 SCSI) ST336752LW;
2. 10K rpm Seagate Cheetah 36ES (36 GB Ultra160 SCSI) ST336706LW;
3. 10K rpm Western Digital Raptor WD360GD (36 GB SATA150) WD360GD;
4. 10K rpm Maxtor Atlas 10k III (73 GB Ultra160/m SCSI) KW073L8;
5. 10K rpm Seagate Cheetah 10K.6 (146 GB Ultra320 SCSI) ST3146807LW;
6. 10K rpm IBM Ultrastar 146Z10 (146 GB Ultra320 SCSI) IC35L146UWDY10;
7. 7.2K rpm Hitachi Deskstar 7K250 (250 GB SATA150) HDS722525VLSA80;
8. 7.2K rpm IBM Deskstar 180GXP 8 MB (180 GB ATA100) IC35L180AVV207-1;
9. 7.2K rpm Seagate Barracuda 180 (180 GB Ultra160 SCSI) ST1181677LWV.

Я постарался подобрать репрезентативную выборку: тут и один из самых быстрых HDD в мире Seagate Cheetah X15-36LP (жаль, что емкость его невелика - зато скорость отличная, и не только благодаря 15.000 rpm), ему в напарники взяты аналогичные по емкости (36Gb) Cheetah 36ES и Raptor WD360 (оба на 10.000 rpm, но один SCSI, а второй SATA). Тут и новейший Hitachi (бывший IBM) Deskstar 7K250 (250Gb емкость и SATA интерфейс), с ним в компании ставший уже классическим IBM Deskstar 180GXP 7K250 (180Gb емкость, IDE интерфейс) - оба с частотой вращения 7.200 rpm. К сожалению, SCSI не могут похвастаться такой емкостью - пока что самыми большими среди них являются монстрообразная 180Gb Barracuda (7.200 rpm и корпус двойной высоты) плюс "сладкая парочка" новейших 146Gb винчестеров от IBM и Seagate (10.000 rpm). Для заполнения промежутка между "быстрыми" и "емкими" HDD я добавил в обзор 73Gb Maxtor (бывший Quantum) Atlas10K III. За бортом осталась продукция Fujitsu - но нельзя объять необъятное, тем более в рамках одной статьи, да и параметры винчестеров Fujitsu достаточно близки к параметрам представленных моделей Seagate и IBM.

Тестовая платформа: Intel Desktop Board D850MV, 2x256Mb RDRAM PC800, SCSI Adaptec ASC-29160, SATA Promise PDC20378. Все тесты проводились под ОС Windows XP Professional, все драйвера стандартные из дистрибутива ОС.

Рис.1 Среднее время доступа на чтение (True Average Seek - Read). Меньше - лучше.

Среднее время доступа на чтение (см. рис.1), как можно было заранее предсказать, оказалось самым низким у Seagate Cheetah X15 - чему помогли и 15K rpm скорость вращения, и малый диаметр дисков этого HDD. Неплохие цифры демонстрируют также и 10K rpm SCSI винчестеры - однако тут SATA Raptor буквально "наступает им на пятки". Ну и, понятное дело, SCSI никак не помогает 180Gb Барракуде оторваться от 250Gb Хитачи, разница в 0.1 ms находится в пределах погрешности измерений.

Рис.2 Скорость чтения в начале и конце диска по данным WinBench-99, мегабайт в секунду. Больше - лучше.

По скоростям последовательного чтения (см. рис. 2) картина уже не столь однозначна. Очень достойно выглядит WD Raptor, захвативший лидерство по гарантированной скорости чтения (хотя и с ничтожным отрывом от 15K rpm Cheetah) и ненамного пропустивший вперед по максимальной скорости лишь две последних 146Gb модели IBM и Seagate. Можно сказать, что в сегменте 36Gb HDD (емкость, наиболее часто используемая для построения RAID массивов) победа Raptor по скоростям чтения абсолютна. В сегменте же "больших" HDD явно видна неконкурентоспособность 180Gb Барракуды (IDE HDD быстрее и имеют большую емкость), а новые 146Gb SCSI модели продолжают лидировать по скорости (хотя SATA Hitachi все ближе и ближе к их результатам).

Рис.3 Производительность в наборах приложений SR Office DriveMark 2002 и High-End DriveMark 2002, операций ввода-вывода в секунду. Больше - лучше.

От синтетики перейдем к приближенным к практике тестам. На рис.3 можно видеть производительность HDD при работе в типичном офисном наборе приложений (MS Office XP, MSIE 6.0, ICQ, Outlook и т.д.) и в наборе "профессиональных" приложений (Adobe Premiere и Photoshop, FrontPage, MS VisualC++ и т.д.). Эти нагрузочные паттерны важны для оценки производительности дисковой подсистемы не только рабочих станций, как может показаться на первый взгляд, но и терминальных серверов.

Raptor, естественно, лидирует в абсолютном зачете в обеих категориях. Western Digital на пару с IBM/Hitachi преуспел в "затачивании" алгоритмов своих HDD под "пользовательские" нагрузки распространенных пакетов, и скорость вращения 10K rpm ставит всех на свои места - конкуренты могут перекурить в углу. А вот результаты Hitachi при ее 7.200 rpm довольно неожиданны - она обошла все 10K rpm SCSI в обоих паттернах и даже сумела обогнать 15K rpm Cheetah X15 в тесте "профессиональных" приложений. Результаты "старичка" IBM GXP180 скромнее - но и они вплотную приближаются к новейшим 10K rpm SCSI от Seagate и IBM, и серьезно превосходят Cheetah 36ES.

Рис.4 Производительность в наборах приложений SR Bootup DriveMark 2002 и Gaming DriveMark 2002, операций ввода-вывода в секунду. Больше - лучше.

Отпускная цена этого чуда современной техники (в комплектации с двумя процессорами PIII-800EB, двумя HDD IBM 60GXP по 40Gb и 1.5Gb RAM PC133 Micron) составила всего 950$ без учета стоимости корпуса, что рекордно низко для двухпроцессорных серверов 1U формфактора. Ложку дегтя в эту бездну меда внесла относительно высокая цена использованного мной алюминиевого корпуса (~300$) - однако есть ведь более дешевые корпуса 1U, поиском которых я сейчас и занимаюсь...

Раз уж зашла речь о типичных "пользовательских" нагрузках, на рис.4 можно увидеть производительность HDD при загрузке Windows XP (BootUp DriveMark) и в компьютерных играх (Gaming DriveMark). Как видите, результаты качественно повторяют то, что мы уже наблюдали на рис.3. Желающие конкретизации последнего испытания на рис.5 могут увидеть цифры по двум популярным игрушкам - Half-Life и The Sims.

Рис.5 Производительность HDD в играх, операций ввода-вывода в секунду. Больше - лучше.

Рис.6 Производительность в наборах приложений Business и High-End по тесту WinBench99, мегабайт в секунду. Больше - лучше.

Для большей достоверности тесты приложений были проведены повторно с использованием общеизвестной программы WinBench99 (см. рис. 6 и 7). Как видите, результат такой же, только IBM 180GXP "прибавил прыти" в тестах бизнес-приложений, а Raptor в них же несколько поубавил результаты. Однако в HighEnd ситуация стабильна - SATA Raptor вне конкуренции, за ним идут SATA Hitachi и IDE IBM, и в хвосте плетутся SCSI (все-таки приложения - не их конек). К тому же и данные тестов я взял не откуда-то, а с авторитетного для многих сайта StorageReviews - их трудно заподозрить в излишних симпатиях к IDE/SATA и нелюбви к SCSI:

Рис.7 Производительность в некоторых конкретных приложениях набора High-End по тесту WinBench99, мегабайт в секунду. Больше - лучше.

Рис.8 Производительность HDD в типичной роли файлового сервера с различной нагрузкой по данным Intel IOmeter, операций ввода-вывода в секунду. Больше - лучше.

Разумеется, наиболее интересны для создателей серверов производительности дисков и дисковых массивов в ролях файлового и веб-сервера. На рис. 8 и 9 Вы можете видеть результаты выбранных нами дисков в этих ролях. Результаты эти интересные - они явно показывают неспособность (пока что) даже для WD Raptor достичь уровня производительности SCSI HDD под большими нагрузками (хотя при глубине очереди до четырех-шести запросов Raptor 360 вполне конкурентоспособен с типичным SCSI HDD такой же емкости) и явно отмечают выгодность для больших нагрузок SCSI-дисков.

Рис.9 Производительность HDD в типичной роли WEB-сервера с различной нагрузкой по данным Intel IOmeter, операций ввода-вывода в секунду. Больше - лучше.

И все было бы хорошо, если бы не одно (зато большое) НО, касающееся теста Intel IOmeter, любимого многими составителями обзоров железа и сайтами типа iXBT. Цифры, полученные в результате этого теста, уверяют нас, что при росте нагрузки (и, соответственно, числа запросов в очереди) объективная производительность дисковой подсистемы (выражаемая в числе выполненных за секунду запросов) растет - что противоречит элементарной логике. Посудите сами: чем больше независимых нитей теста запрашивают свои данные с HDD - тем чаще HDD вынужден ходить за этими данными к разным областям диска, теряя время на перемещение головок, тем хуже работает система упреждающего чтения (хотя бы из-за того, что размер кэша в HDD фиксирован, и чем на большую группу расположенных в разных местах данных его приходится делить - тем меньше достается каждой группе). Любой системный администратор и даже продвинутый пользователь убедился в этом на собственном опыте - достаточно запустить параллельно десять процедур копирования разных файлов, чтобы увидеть, что суммарное время на эти операции окажется большим, чем если бы мы копировали файлы поочередно (между прочим, именно поэтому практически все файловые менеджеры, архиваторы и бэкапы обрабатывают файлы последовательно, один за другим - хотя если бы Intel IOmeter говорил правду, они могли бы серьезно выиграть в скорости, читая несколько файлов одновременно).

Другими словами, если Intel IOmeter не врет в цифрах (например, "взвешивая" свои результаты под разной нагрузкой к какому-либо зависящему от нагрузки коэффициенту) - это означает, что используемые им паттерны данных и алгоритмы имитации доступа к ним не имеют никакой реальной корреляции с типичными паттернами и алгоритмами доступа реальных приложений и задач. Да и, в конце концов, о какой реальности данных теста IOmeter можно говорить, если он тестирует диски без файловой системы? Что это вообще за тест якобы "файлового сервера" без файловой системы? Люди бьются, придумывают файловые системы, часто специально оптимизированные под конкретные задачи (посмотрите, сколько таких FS сделано под Linux) - и, как выясняется, совершенно напрасно, ибо Intel IOmeter выдаст одинаковые результаты что для Raiser FS, что для FAT16. Он, собственно, вообще не знает, что такое "файл", тестируя HDD неким набором чтений и изредка записей блоков с определенными, по большей части случайными, абсолютными номерами. Я совершенно не против такого тестирования, но только при чем тут "файловый сервер"?

Чтобы было совсем ясно, насколько этот тест соответствует работе файлового сервера, приведу табличку параметров модели FileServer от Intel, используемую в IOmeter (см. табл.1)

Таблица 1. Модель FileServer в Intel IOmeter

Access Patterns
% of Access Specification	Transfer Size Request	% Reads	% Random
File Server Access Pattern (as defined by Intel)
10%	0.5 KB	80%	100%
5%	1 KB	80%	100%
60%	4 KB	80%	100%
2%	8 KB	80%	100%

Обратите внимание на параметр "% Random" - для всех размеров блока данных он составляет 100%, то есть абсолютно все запросы всех блоков идут в случайные места диска. О том, что существуют файлы больше 64Kb и что файлы имеют свойство в большинстве случаев читаться последовательно (хотя бы из-за Read-Ahead кэша в Windows), IOmeter-у никто в Intel не рассказал. Вот берется такая бредовая модель "шимпанзе-склеротик за пультом", с вероятностью, взятой из первой колонки, выбирается размер блока из второй колонки, в 80% случае это будет чтение (а в 20% случаев - запись), и затем читается (или пишется) блок такого размера из 100% случайной области диска (ее можно ограничить разве что размером одной партиции, однако и при этом обращения идут к абсолютным секторам, плюя на таблицы файловой системы и ее организацию - а ведь, например, запись новых данных большинство файловых систем делает далеко не в случайное место диска). Циферка количества I/O (нагрузки на диск) означает у Intel лишь "число одновременно выдаваемых в HDD запросов" - забавный параметр, ведь если учесть 100% случайность в выборе номера блока и заведомую однопоточность очереди запросов к дисковой подсистеме от одного процесса в Windows, то совершенно непонятно, как это "количество запросов" может повлиять (и ведь якобы влияет) на производительность дисковой подсистемы. Или Intel IOmeter шлет запросы прямо в контроллер диска, минуя ОС? Если бы это было так - тогда бы выбранная ОС не влияла на результаты измерений, а она на них заметно влияет.

В общем, как-то этот тест работает, и циферки вот такие получает. К работе настоящих серверов они не имеют никакого разумного отношения, но раз народ их любит и просит приводить, то вот они - радуйтесь. Тем более что разумных и общепринятых тестов, имитирующих реальные серверные нагрузки на дисковую подсистему, на горизонте пока не наблюдается. Вы знаете такой тест? Сообщите мне, будем использовать.

Что же выбрать?

Понятно, что если Вас заботит сохранность данных на сервере - надо делать RAID. Из всех видов отказоустойчивых RAID упоминавшийся выше Level-10 имеет наибольшую отказоустойчивость и при этом наибольшую скорость работы. Он может состоять из 4 и более HDD (обязательно четное количество). Если скорость не важна, Вас может устроить более компактный RAID Level-1 из двух HDD.

Далее следует определиться с объемом массива. Если массив большой и скорость его работы критически важна - следует предпочесть конфигурацию с 8 и более относительно небольшими HDD в RAID Level-10, вместо того чтобы ограничиться использованием меньшего количества HDD большей емкости. Всегда следует помнить, что на большинстве реальных задач с нагрузкой, типичной для сервера малой и средней организации, массив из 8 SATA HDD Raptor (2 контроллера Intel SRCS14L в кластере, 144Gb полезная емкость) окажется быстрее массива такого же объема и цены из четырех SCSI HDD любого производителя.

Если же Вам нужен терабайтный отказоустойчивый массив, а скорость при этом не является критически важным параметром - обратите свое внимание на 250Gb SATA винчестеры Hitachi 7K250 и Western Digital 2500JD. Заветное значение в 1Tb и неплохую скорость работы легко получить, прибегнув, опять же, к кластеризации двух 4-портовых SATA контроллеров.

Если же Вы строите WWW, FTP или Proxy-сервер для работы под очень большими нагрузками (типичными для крупных Internet-провайдеров и проектов), пока что стоит предпочесть дисковую подсистему на основе SCSI.

Если же ожидаемые нагрузки не такие большие - стоит выбрать более дешевое IDE/SATA решение.

Выбор же SCSI или IDE/SATA для файлового сервера зависит от того, сколько пользователей и какие по размерам файлы будут с этого сервера качать. Если файлы большие (десятки мегабайт) или одновременно забирающих файлы пользователей немного (менее 30-50) - стоит выбрать IDE дисковый массив, если же больше - SCSI может оказаться несколько быстрее и компактнее (хотя и дороже).

Для дискового массива терминального сервера почти всегда выгоднее использовать IDE/SATA диски - и в этом случае выбор сводится к определению их оптимального размера и числа, а также к выбору контроллера и типа интерфейса (параллельный IDE или последовательный SATA). Очень хорошие контроллеры IDE RAID делает известная фирма 3Ware - из дешевых моделей с обычным IDE интерфейсом можно порекомендовать 7500-4 (4 диска) и 7500-8 (8 дисков), более серьезные массивы можно построить на моделях 7500-12 (12 дисков) и 7800-16 (16 дисков). В качестве SATA RAID-контроллеров для мощных серверов стоит обратить внимание на 3Ware Escalade 8500 и уже упоминавшийся Intel SRCS14L Taft.

Основным преимуществом SATA перед обычным IDE применительно к серверам является не более высокая скорость передачи данных и особенности протокола передачи команд, а его врожденная способность HotPlug/HotSwap. Для того, чтобы заменить вышедший из строя SATA HDD, Вам необходимо лишь обеспечить себе возможность механически снять HDD (отвернуть винты его крепления) и выдернуть из него SATA-разъемы. Обращаю Ваше внимание: для обеспечения HotPlug/HotSwap следует либо использовать специальный двойной разъем SATA (питание + сигналы), либо выдергивать одинарные SATA-разъемы в определенной последовательности - сначала более узкий сигнальный, затем более широкий питающий. Втыкать разъемы в новый HDD следует в обратном порядке - сначала питание, потом сигналы. Если Вы использовали обычный разъем питания (предусмотренный в качестве дублирующего на винчестерах фирмы Western Digital) - HotSwap/HotPlug делать нельзя.

Разумеется, ряд фирм производит HotSwap-корзины для SATA HDD (например, такими корзинами снабжаются некоторые новейшие серверные платформы Intel) - однако эти корзины не являются обязательным атрибутом HotSwap для SATA HDD, они лишь делают процесс замены таких HDD более удобным. Кстати, Hot-Swap корзины и отдельные Hot-Swap фреймы существуют и для обычных IDE HDD - их выпускает, например, известная фирма Promise. Так что HotSwap не является атрибутом только лишь SCSI-систем.

В заключение хочу упомянуть законченные решения внешних дисковых массивов. Целый ряд фирм выпускает такие решения на основе дешевых IDE и SATA HDD - при этом снаружи такие массивы имеют интерфейс SCSI или FiberLoop, являются полностью транспарентными для ОС на базовом сервере (то есть выглядят для операционной системы "снаружи" как один большой SCSI-диск), но внутри содержат от 8 до 24 дешевых IDE/SATA HDD в HotSwap корзинах. Это решение позволяет обойти проблемы с драйверами IDE дисков в некоторых экзотических ОС и сделать шаг в направлении использования больших массивов дешевых дисков даже в самом консервативном окружении.

Ну, с дисковыми подсистемами, кажется, разобрались? Тогда в следующей статье поговорим о такой переживающей сейчас бум технологии, как терминальные серверы и тонкие клиенты (между прочим, именно поэтому я уделил столь много внимания производительности дисковой подсистемы при работе с типичными приложениями). Я постараюсь показать Вам, каким образом при помощи технологии тонких клиентов можно строить более дешевые и более удобные системы совместной работы для офисов, не испытывая неудобств и ограничений в использовании привычных для пользователя приложений - и в то же время резко упростив работу системного администратора и повысив уровень безопасности сети.

Владимир Федоров
rekvizit.ru