Главная › Телефон › Серверы adaptec. Тестирование массива RAID6 из жестких дисков на трех поколениях контроллеров Adaptec. NAS-серверы Adaptec Snap Server

Серверы adaptec. Тестирование массива RAID6 из жестких дисков на трех поколениях контроллеров Adaptec. NAS-серверы Adaptec Snap Server

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

Если вам интересны raid-технологии и задачи администрирования raid-контроллеров, рекомендую обратиться к рубрике на моем блоге.

Создание массива RAID Adaptec 6405

При загрузке сервера нажимаем CTRL+A и попадаем в меню контроллера. Нам нужно выбрать Array Configuration Utility :

Сначала необходимо зайти в пункт меню Initialize Drives , чтобы сообщить контроллеру какие диски будут использоваться.

Пробелом нужно отметить каждый диск:

После того как диски выбраны, нажимаем Enter и получаем предупреждение:

В итоге у меня поучились следующие настройки:

Примечание: пару слов о разделах объемом более 2ТБ — если итоговый размер массива меньше этого значения, то беспокоиться не стоит. Если объем больше, то ваша система откажется видеть все, что больше примерно 2ТБ. Это связано с MBR-разметкой, которая не позволяет разметить более 2ТБ. Выход — использовать GPT-разметку, но в таком случае ваша материнская плата должна поддерживать UEFI, чего на старых материнках нет. Чтобы это обойти, можно назначить массиву меньший объем, а потом оставшийся объем использовать для другого массива RAID такого же типа .

Снова получаем предупреждение об использовании функции отложенной записи.

Замена вышедшего из строя диска

На данном этапе я постараюсь смоделировать выход из строя одного из жестких дисков массива. Поскольку ранее я создал массив типа Raid1, он позволяет сохранить работоспособность при поломке половины дисков. В моем случае половина — это 1 диск (всего их два).

Порядок действий:

я отключаю полностью сервер;
достаю один из дисков и в соседнюю корзину монтирую другой.

В идеале после этого массив должен находиться в деградированном состоянии, но продолжать работать. После подключения третьего диска он не должен автоматически подцепиться к массиву. Во-первых, потому что он не инициализирован; во-вторых, потому что он не был указан как hotspare (диск горячего резерва) при создании массива.

Итак, приступим.

После включения сервера, в bios получаем следующие предупреждения:

В принципе так оно и должно быть, ведь одного диска в массиве не стало. Кстати, после «пропажи» диска из массива, контроллер стал очень громко и мерзко пищать и ко мне даже стали заходить коллеги и предупреждать о странном шуме из серверной.

Заходим в утилиту управления массивами, смотрим состояние массива в Manage Arrays :

Как видно, одного диска в массиве нет, сам массив находится в деградированном состоянии. Все как и предполагалось.

После этого нам надо инициализировать новый диск. На скриншоте вверху было видно, что в действующем массиве используется один диск в слоте 31, значит новый диск будет в каком-либо другом. Заходим в пункт меню Initialize Drives , инициализируем диск в слоте 29:

Получаем предупреждение (по-хорошему, к этому моменту у вас уже должны быть бэкапы всей актуальной информации, а сервер выведен на плановое обслуживание, если конечно это возможно):

Теперь нам необходимо сообщить контроллеру, что он должен использовать новый диск, чтобы включить его в массив вместо вышедшего из строя. Сделать это нужно через пункт меню Manage Arrays — нажимаем Enter, стрелочками вверх/вниз выделяем нужный массив (если их несколько), нажимаем CTRL+S и попадаем на страницу управления Global Hotspare :

Выбрать вы можете только диски, которые не находятся в данный момент ни в каких массивах. Пробелом выделяем нужный диск:

Нажимаем Enter. Выйдет диалоговое окно подтверждения изменения, вводим Y . Поскольку диск мы сделали диском горячей замены, то контроллер должен автоматически сделать его частью массива и сразу же начать процесс ребилда (rebuild array ), проверить это можно все также из пункта меню Manage Arrays :

С этого момента вы можете загружать сервер в нормальном режиме и работать дальше. Полный ребилд представляет из себя достаточно длительный процесс и зависит от множества параметров — производительности контроллера/дисков, текущей нагрузки на контроллер/диски и др. Можно сделать вывод, что скорость ребилда значительно изменится в большую сторону, если вы начнете использовать массив сразу после добавления диска. Если есть возможность, лучше дать контроллеру время спокойно завершить перестройку массива и уже после этого давать на него реальную нагрузку(это особенно касается массивов RAID5).

Процесс ребилда физически будет сопровождаться миганием красного светодиода на корзине того диска, который был только что добавлен в массив.

В утилите Adaptec Storage Manager перестроение массива выглядит таким образом:

Кстати, утилита запущена с того же самого сервера. На этом обзор задач управления массивами RAID Adaptec 6405 завершен.

Если вам помогла статья, оставляйте комментарии, делитесь своим опытом.

Adaptec Snap Server - семейство дисковых хранилищ, которые могут выполнять функции сетевых файловых серверов (NAS-сервера) в средах Windows, Linux или Apple либо использоваться в качестве дисковых RAID-массивов с интерфейсом iSCSI в соcтаве IP-сетей хранения данных для обслуживания серверов приложений Windows и Linux.

NAS-серверы Adaptec Snap Server

NAS-серверы Adaptec Snap Server подключаются непосредственно с сети передачи данных (LAN) через встроенные порты Ethernet и выполняют роль файлового сервера для клиентов сети. Adaptec Snap Server - простой и эффективный способ создания дискового хранилища совместного доступа как для небольших рабочих групп, так и для центров обработки данных.

Использование Adaptec Snap Server обеспечивает:

Простоту развертывания - Вы просто подключаете к локальной сети, выполняете минимальные настройки и сервер готов к работе.

Гибкость - Вы можете использовать Adaptec Snap Server в гетерогенной сети, предоставляя дисковое пространство для клиентов Windows, Linux, Unix и Apple. Кроме того, одновременно Вы можете использовать Adaptec Snap Server как хранилище для серверов приложений при помощи протокола iSCSI. Таким образом, Adaptec Snap Server может обеспечивать доступ к данным не только на уровне файлов, но и на уровне блоков.

Высокую доступность - надежность работы Adaptec Snap Server обеспечивается дублированием Ethernet-подключений, организацией данных в RAID, горячей заменой дисков, резервированием систем питания и охлаждения.

Производительность - возможность использования дисков с интерфейсом SAS и скоростью вращения шпинделя 15000 об/мин, "широкие" порты SAS (12Gbit/s) для подключения дополнительных модулей расширения JBOD.

Масштабируемость - увеличение емкости хранилища осуществляется добавлением модуля расширения на 12 дисков, всего можно подключить до 7 модулей, при этом максимальный объем хранилища составляет 66TB.

Управляемость - сервер работает под управлением операционной системы GuardianOS, настройки сервера выполняются через WEB-интерфейс.

Защиту данных - встроенные средства безопасности и контроля доступа, антивирусная защита, репликация данных, "моментальная" копия данных - технология snapshot, развитые средства резервного копирования данных (в том числе данных на компьютерах-клиентах) на диски, ленту или сетевое устройство.

Экономичность - снижение совокупной стоимости владения ввиду отсутствия необходимости приобретения клиентских лицензий.

Семейство Adaptec Snap Server включает следующие модели NAS-серверов:

Snap Server 110 - компактное сетевое хранилище (NAS-сервер) емкостью до 750GB. Опционально: поддержка iSCSI, функции backup-сервера или виртуальной ленточной библиотеки, антивирусное ПО, технология Snapshot, репликация данных.

Snap Server 210 - компактное сетевое хранилище (NAS-сервер) емкостью до 1,5TB. Два жестких диска обеспечивают удвоение производительности дисковых операций (RAID 0) либо защиту данных (RAID 1). Опционально: поддержка iSCSI для блочного доступа к данным, функции backup-сервера или виртуальной ленточной библиотеки, антивирусное ПО, технология Snapshot, репликация данных.

Snap Server 410 - сетевое хранилище (NAS-сервер) емкостью до 3TB. Форм-фактор 1U для установки в стойку. Включает ПО эмуляции ленточной библиотеки резервного копирования. Опционально: поддержка iSCSI для блочного доступа к данным, антивирусное ПО, технология Snapshot, репликация данных, SCSI-интерфейс для подключения внешнего ленточного накопителя.

Snap Server 520 - сетевое хранилище (NAS-сервер) емкостью до 3TB. Возможно подключение до семи модулей расширения JBOD для максимальной емкости 66TB (требуется дополнительный SAS HBA). Форм-фактор 1U для установки в стойку. ПО эмуляции ленточной библиотеки резервного копирования, поддержка iSCSI для блочного доступа к данным, антивирусное ПО, Snapshot. Опционально: ПО репликации данных.

Snap Server 650 - сетевое хранилище (NAS-сервер) емкостью до 1,2TB, расширяемое до 64,2TB путем подключения модулей расширения JBOD. Форм-фактор 1U для установки в стойку. ПО эмуляции ленточной библиотеки резервного копирования, поддержка iSCSI для блочного доступа к данным, антивирусное ПО, Snapshot. Опционально: ПО репликации данных.

SANbloc S50 JBOD - модуль расширения для Snap Server 650 и Snap Server 520. Имеет форм-фактор 2U и включает до 12 дисков SAS или SATA. Возможно "прямое" подключение к серверу через контроллеры Adaptec 4800SAS или 4805SAS (до 8 модулей).

RAID-массивы Adaptec Snap Server с интерфейсом iSCSI

RAID-массивы Adaptec Snap Server с интерфейсом iSCSI предназначены для создания дисковых хранилищ, обслуживающих сервера приложений Windows и Linux в IP-сетях хранения данных (IP SAN). Один RAID-массив может обслуживать одновременно до 512 серверов, вмещать до 512 логических томов с максимальной емкостью до 18TB, обеспечивая пропускную способность 386MB/s.

Массивы Adaptec Snap Server поддерживают технологию Snapshot для снятия моментальной копии данных по расписанию или требованию, зеркалирование томов на разных RAID-массивах, аггрегирование и резервирование каналов подключения, кластеризацию в среде Windows, а также централизованное управление.

Семейство Adaptec Snap Server включает следующие модели RAID-массивов с интерфейсом iSCSI:

Snap Server 720i - дисковый RAID-массив емкостью 1 или 2 TB, которая может быть увеличена на 33TB с помощью модулей расширения SANbloc S50 JBOD. Форм-фактор 1U для установки в стойку.

Snap Server 730i - дисковый RAID-массив емкостью 3TB, которая может быть увеличена до 36TB с помощью модулей расширения SANbloc S50 JBOD. Форм-фактор 1U для установки в стойку.

Snap Server 750i - дисковый RAID-массив емкостью 1.2TB, которая может быть увеличена на 33TB с помощью модулей расширения SANbloc S50 JBOD. Форм-фактор 1U для установки в стойку.

Дисковые массивы Adaptec обеспечиваются гарантией 3 года.

Подход Adaptec к выпуску RAID-контроллеров с поддержкой SAS-накопителей является системным и весьма логичным. После выпуска «пробных» моделей компания перешла к производству контроллеров на единой архитектуре (Unified Serial Architecture). К ним относятся как недорогие четырехпортовые контроллеры начального уровня первой и второй серии (номер серии определяется по первой цифре в обозначении модели), так и контроллеры основной, третьей серии. Конечно же, высокопроизводительная пятая серия, являющаяся, на текущий момент, пиком развития контроллеров Adaptec, стала логичным продолжением предыдущих моделей.

Любопытно, кстати, сравнить контроллеры между собой: первая серия вовсе лишена встроенных процессоров и буферной памяти и довольствуется интерфейсом PCI-Express x4; третья серия обходится 500- и 800-МГц процессорами Intel 80333, объемы встроенной памяти в ней варьируются между 128 и 256 МБ, четырехпортовые модели имеют интерфейс PCI-Express x4, а восьмипортовая - PCI-E x8 (кстати, представитель третьей серии, ASR-3405 , некоторое время назад уже был у нас на тестах). Пятая же серия целиком перешла на PCI-E x8, все модели, кроме четырехпортовой, оснащены 512 МБ памяти (лишь младшая ASR-5405 урезана до 256 МБ), плюс во всех контроллерах серии используется самый мощный процессор среди встречающихся сегодня на RAID-контроллерах - двухъядерный, с частотой 1,2 ГГц. Мы сознательно пропустили вторую серию: такое впечатление, что она получена «упрощением» пятой серии, а вовсе не третьей. Судите сами: обе модели серии четырехпортовые, то есть, с одним внутренним разъемом SFF-8087 или внешним SFF-8088, но при этом они имеют интерфейс PCI-E x8 и оснащены двухъядерным процессором. Правда, частота процессора меньше, чем у пятой серии - «всего» 800 МГц. Да и буферной памяти у второй серии поменьше - 128 МБ, видимо, чтобы сохранить позиционирование серии как младшей, по отношению к третьей. Еще одной ниточкой, указывающей на происхождение второй серии, является то, что модели из нее поддерживают появившееся в пятой серии «умное управление питанием» (Adaptec Intelligent Power Management), заключающееся в отключении неиспользуемых дисков или снижении их потребления за счет перевода в спящее состояние. Главным же отличием второй серии является то, что она поддерживает лишь массивы RAID0, 1 и 10 - то есть полностью лишена возможностей работы с массивами с контролем четности (RAID5, RAID6 и их двухуровневые производные).

Итак, пятая серия, и ее представитель в лице Adaptec ASR-5805.

Adaptec RAID ASR-5805

Сразу отметим, что пятая серия стала одной из самых больших: на текущий момент в нее входят аж семь моделей, от простейшей ASR-5405 до 28-портовой ASR-52445. Разобраться в них несложно, достаточно расшифровать наименование: первая цифра - номер серии, одна или две следующих - количество внутренних портов, далее идут две цифры, указывающие количество внешних портов и тип интерфейса. Поскольку все модели серии имеют интерфейс PCI-E x8, то и заканчиваются они все на «5», а вот на старых моделях можно встретить и «0» - признак PCI-X интерфейса.

Единый дизайн серии означает и единство характеристик - лишь четырехпортовая модель выделяется вдвое меньшим объемом памяти, все остальное же у всех моделей «под копирку»: двухъядерный 1,2 ГГц процессор, 512 МБ памяти, PCI-E x8 в качестве используемого интерфейса, поддержка приобретаемой отдельно батареи питания, до 256 SATA/SAS устройств (естественно, при использовании соответствующих корзин и экспандеров). Кстати, предыдущие серии поддерживали лишь до 128 устройств - в компании Adaptec не только устанавливают более мощные процессоры в новую серию, но и не забывают править прошивку.

Кстати, о прошивках. Есть некоторые технические ограничения по построению массивов, связанные с особенностями работы самих контроллеров. Пожалуй, мало кто из пользователей столкнется с ними, разве что те, кому по долгу службы надо работать с очень большими СХД (системами хранения данных), но все же... Пятая серия (а вместе с ней и вторая) поддерживает до 64 массивов на одном контроллере (третья - лишь 24), до 128 дисков в одном массиве RAID0, до 32 дисков в массивах с вращением четности RAD5 и RAID6.

Контроллеры пятой серии поддерживают практически все популярные типы массивов, а именно:

одиночный диск,
RAID0,
RAID1,
RAID1E,
RAID5,
RAID5EE,
RAID6,
RAID10,
RAID50,
RAID60.

Здесь хочется сделать небольшую остановку. Если привычные RAID0, 1, 5, 6 и их комбинации хорошо знакомы большинству пользователей, то массивы RAID1E и RAID5EE малоизвестны и до сих пор вызывают вопросы о том, как же они работают.

Начнем с RAID1E. Массивы этого типа действительно очень близки к RAID1, так как используют зеркалирование данных. Но в них зеркалируются не диски целиком, а лишь отдельные блоки. Такой подход позволяет использовать для построения массивов три и более дисков (в случае двух дисков RAID1E вырождается в обычный RAID1). Проще всего понять логику расположения страйпов в массиве из диаграммы:

Буквами «М» помечены «зеркальные» блоки. Итак, что же мы имеем в результате? Массивы RAID1E обладают избыточностью данных, то есть прощают потерю одного диска, при этом, в отличие от RAID1 и RAID10, их можно строить на нечетном числе дисков, у них неплохие скорости записи и чтения - за счет «размазанности» страйпов по разным дискам массивы RAID1E будут быстрее, чем RAID1, и как минимум сравнимы с RAID10 (если, конечно, в RAID1 массивах контроллер не умеет читать данные сразу с обоих дисков в зеркальных парах). Но не стоит считать эти массивы идеальными: потеря объема у них такая же, как и у всех массивов на основе зеркалирования, то есть 50 %. Что же касается защищенности данных, то RAID10 оказывается более выгодным: при равном числе дисков он в некоторых случаях выдерживает выход из строя сразу двух винчестеров. Таким образом, ценность RAID1E состоит, в основном, в возможности построить массив с зеркалированием на нечетном количестве дисков, получив при этом еще и некоторое увеличение скорости, что достаточно актуально для тех случаев, когда контроллер не умеет читать сразу с двух дисков в обычных зеркальных парах.

Массив RAID5EE является более забавной штукой. Как и бывший для него исходным RAID5, он построен на принципе защищенности данных при помощи хранения страйпов с контрольными суммами XOR, причем эти страйпы «вращаются», то есть равномерно распределены по всем дискам массива. Отличием является то, что для построения RAID5EE строго необходим прикрепленный к массиву диск горячей замены, который не может быть использован для замены в других массивах. Дело в том, что этот диск замены не ждет несчастного случая, как это обычно бывает, а участвует в работе вполне исправного массива. Информация в массиве в виде страйпов располагается сразу на всех дисках, включая диск замены, а та емкость, которая принадлежит диску замены, равномерно располагается сразу на всех дисках массива. То есть, фактически, диск замены становится виртуальным - сам диск в работе используется, но его емкость занять нельзя, поскольку она резервируется контроллером и для пользователя недоступна. Причем в ранних реализациях, называвшихся RAID5E, эта виртуальная емкость располагалась в конце всех дисков, в то время как в RAID5EE она располагается по всему массиву в виде равномерно распределенных блоков. Чтобы понять, как это выглядит, предлагаем снова обратиться к диаграмме, где P1, P2, P3, P4 - контрольные суммы соответствующих полных страйпов, а HS - та самая равномерно распределенная по всему массиву емкость резервного диска:

Соответственно при выходе из строя одного из дисков потерянная информация восстанавливается в оставшиеся по всему массиву «пустые» страйпы (отмеченные на диаграмме «HS»), и массив превращается в самый обычный RAID5.

В чем преимущество такого подхода? В том, что резервный диск не простаивает, а участвует в работе, увеличивая скорость чтения с массива за счет большего количества дисков, на которые распределяется каждый полный страйп. Недостаток таких массивов также несложно заметить: резервный диск привязывается к массиву намертво, соответственно, если вы строите на одном контроллере сразу несколько массивов, то каждому из них приходится выделять свои диски замены, что увеличивает затраты и требует больше места в сервере.

Однако, вернемся к нашему контроллеру. За счет высокой плотности монтажа компании Adaptec удалось сделать все контроллеры достаточно короткими, а четырех- и восьмипортовые модели - еще и половинной высоты. При этом батарея питания не занимает отдельный разъем в корпусе, а устанавливается на заднюю часть контроллера.

Сама батарея расположена на маленькой дочерней плате, а уж та через маленькие проставки крепится пластиковыми винтами на сам контроллер. Мы настоятельно рекомендуем пользоваться батареями - информация слишком дорога, чтобы терять ее из-за копеечной экономии, а отложенная запись, как показывает пример Promise , работавшего без батареи, слишком важна для скоростных характеристик массивов. Пользоваться же отложенной записью в небезопасном режиме, то есть без батареи питания буферной памяти, на наш взгляд, слишком рискованно: мы можем позволить себе это иногда на тестах, но никогда бы не позволили такого же в реальных рабочих условиях.

Список поддерживаемых операционных систем очень широк и, пожалуй, охватывает практически все существующие ОС, кроме самых экзотических. Помимо всех версий Windows, начиная с Windows 2000 (64-битные версии не забыты), в него входят несколько популярных дистрибутивов Linux, а также FreeBSD, SCO Unix и Solaris. Более того, есть даже драйвера для работы под управлением VMWare. Для большей части этих операционных систем существуют и свои сборки Adaptec Storage Manager - фирменного программного обеспечения для работы с контроллером. Функционал последнего весьма широк, с его помощью можно проводить любые операции с контроллером и массивами на нем, не переходя в BIOS. Работать в нем весьма удобно: все функции расположены логично и не требуют большого количества времени для поиска. Удобству работы способствует и большое количество наглядной информации и режимах функционирования контроллера.

Методика тестирования

Во время тестирования использовались следующие программы:

IOMeter версии 2003.02.15;
WinBench версии 99 2.0;
FC-Test версии 1.0;

Тестовая система была следующей:

корпус Intel SC5200;
системная плата Intel SE7520BD2;
два процессора Intel Xeon 2,8 ГГц на 800-МГц системной шине;
2 х 512 МБ регистровой памяти DDR PC3200 ЕСС
жесткий диск IBM DTLA-307015 объемом 15 ГБ в качестве системного диска;
видеокарта - встроенное видео ATI Rage XL
операционная система Microsoft Windows 2000 Professional SP4

Kонтроллер во время тестов устанавливался в слот PCI-Express x8 на материнской плате. Для тестирования использовались жесткие диски Fujitsu MBA3073RC, установленные в штатные салазки корпуса SC5200 и закрепленные в них четырьмя винтами за нижнюю грань. Контроллер тестировался с использованием четырех и восьми жестких дисков в следующих режимах:

RAID0;
RAID10;
деградировавший 8-дисковый RAID10 без одного диска;
RAID5;
RAID5;
деградировавший 8-дисковый RAID5 без одного диска;
RAID6;
деградировавший 8-дисковый RAID6 без одного диска;
деградировавший 8-дисковый RAID6 без двух дисков.

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

Для сравнения мы будем везде приводить результаты одиночного диска Fujitsu MBA3073RC, полученные на контроллере LSI SAS3041E-R, считая их неким базовым уровнем производительности. Сразу оговоримся, что у такого сочетания есть одна хорошо известная нам проблема: его скорость записи в «FileCopy Test» всегда очень мала.

По умолчанию, контроллер предлагает для массивов размер страйпа 256 кБ, мы же его везде выставляли на 64 кБ. С одной стороны, это поставит контроллер в равное положение с другими моделями (большинство конкурентов используют именно такой размер), а с другой... именно блоками по 64 кБ осуществляется работа с файлами во всех версиях Windows, вплоть до Windows Vista SP1, соответственно, при совпадении размера блока и размера страйпа, мы вправе ожидать некоторого прироста скорости за счет уменьшения издержек.

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

В контроллер была прошита самая последняя доступная на сайте производителя на момент тестирования версия BIOS и использовались самые свежие драйвера. Соответственно, мы использовали прошивку 5.2.0 build 16116 и драйвера 5.2.0.15728 .

IOMeter: Database

Как всегда, начнем с, пожалуй, наиболее интересного с точки зрения нагрузки на контроллер теста - «Database», с помощью которого мы выясняем способность контроллеров работать с потоками запросов на чтение и запись 8-кБ блоков данных со случайной адресацией. В ходе тестирования происходит последовательное изменение процентного соотношения запросов на запись от нуля до ста процентов (с шагом 10 %) от общего количества запросов и увеличение глубины очереди команд от 1 до 256.

Численные результаты измерений здесь и далее вы можете, при желании, увидеть в соответствующих таблицах, мы же будем работать с графиками и диаграммами.

Таблицы с результатами тестирования вы можете посмотреть по следующей ссылке:

На минимальной нагрузке все выглядит очень прилично: масштабируемость на месте, деградировавший RAID10 и не думает снижать производительность, и вместе с «нормальным» RAID10 на восьми дисках совпадает с RAID0 на четырех дисках, как оно и должно быть по теории.

В массивах с использованием контрольных сумм на минимальной нагрузке дела обстоят также весьма хорошо. Если раньше, на четырех SATA-дисках WD Raptor, мы наблюдали резкое снижение производительности на операциях записи, то новое поколение контроллеров демонстрирует, что за счет большего объема буферной памяти, меньшего времени отклика дисков и быстрой архитектуры даже на четырех дисках в RAID6 они способны показать производительность такую же, как у одиночного диска. Массив RAID5 на четырех дисках оказывается уже заметно быстрее одиночного диска на записи, а уж 8-дисковые массивы и подавно уходят вперед.

Лишившийся одного диска RAID6 несколько снижает скорость, но не так чтобы очень сильно. Действительным ударом по его производительности является потеря сразу двух дисков - вынужденный постоянно восстанавливать данные из двух контрольных сумм (а ведь запись на массивы с вращающейся четностью также требует и операций чтения), контроллер резко снижает производительность, в результате чего скорость деградировавшего массива становится меньше, чем у одиночного диска. RAID5 весьма болезненно переживает потерю даже одного диска - его результаты хуже, чем у RAID6, деградировавшего на один диск, но все же он не падает настолько низко, как RAID6 без двух дисков.

Увеличение нагрузки до 16 запросов в очереди приводит к закономерному возрастанию производительности. На записи массивы RAID10, как и полагается, держатся вплотную к RAID0 из вдвое меньшего количества дисков, а на чтении также вплотную подбираются к массивам RAID0 из такого же числа дисков. А вот сколько-нибудь заметно обогнать последние они не могут - видимо, читать с обоих дисков мы умеем, но нет оптимизации чтения, направленной на поиск в зеркальной паре диска с более удачным положением головки над пластиной, способного быстрее отдать данные.

Деградировавший RAID10 при преобладании запросов на запись ведет себя, как и полагается, то есть никак не проявляет своей «ущербности», но вот при большом количестве запросов на чтение он заметно теряет в производительности. Хотя последняя все же не падает до уровня массивов из четырех дисков, а значит, на оставшихся целыми зеркальных парах контроллер читает с обоих дисков в паре.

Массивы RAID5 и RAID6 также увеличивают производительность, но если у RAID6 все почти хорошо, то у RAID5 поведение уже нельзя назвать идеальным - на их графиках появились резкие скачки производительности, что говорит об определенных недоработках в прошивке. Особенно плоха ситуация в случае деградировавшего RAID5.

По отношению к RAID6 мы употребили «почти» из-за результатов массива на четырех дисках - при преобладании запросов на запись этот массив неожиданно проиграл одиночному диску. Восьмидисковый массив с более-менее разумными потерями переживает гибель одного диска, но вот выход из строя второго сказывается сильно - если на чтении такой массив еще способен обогнать одиночный диск, то бороться на записи он уже не в силах.

Дальнейшее увеличение нагрузки приводит к тому, что нам приходится признать высказанное выше предположение несправедливым - на самом деле, массив вполне умеет находить быстрые диски в зеркальных парах. Особенно хорошо это заметно при сравнении четырех дисковых массивов - RAID10 оказывается на чистом чтении очень заметно быстрее, чем RAID0. А вот деградировавший RAID10 разочаровывает - хорошо справляясь с записью, он напрочь проваливает чтение. В результате на большинстве нагрузок он лишь незначительно превосходит RAID0 на четырех дисках.

Любопытно сравнить результаты с тем, что недавно продемонстрировал нам 3ware 9690SA , имеющий процессор совсем другой архитектуры. В целом, можно объявить о паритете: Adaptec чуть более эффективен на записи, в то время как 3ware несколько быстрее при преобладании операций чтения. Правда, на стороне 3ware гораздо меньшая потеря производительности у деградировавшего RAID10.

Особых изменений в этой группе не произошло, разве что RAID5 чуть выправил ситуацию - теперь он просто не очень хорошо справляется с операциями чтения (особенно деградировавший массив). В результате на 8-дисковых массивах мы видим небывалое: RAID6 на чистом чтении обгоняет RAID5. С деградировавшими RAID6 все по-прежнему: без одного диска массив просто изрядно теряет в скорости, а без двух потери уже катастрофические, скорость падает ниже уровня одиночного диска.

Если снова сравнивать этот контроллер с 3ware 9690SA, то видно, что последний лучше справляется с массивами RAID6 на всех нагрузках и заметно быстрее в RAID5 на чтении, в то время как Adaptec выигрывает в RAID5 при преобладании записи.

IOMeter: Disk Response Time

Для измерения времени отклика мы в течении десяти минут при помощи IOMeter отправляем на накопитель поток запросов на чтение или запись блоков данных по 512 байт при глубине очереди исходящих запросов, равной единице. Количество запросов, обработанных накопителем, превышает шестьдесят тысяч, так что мы получаем устоявшееся время отклика накопителя, не зависящее от объема буферной памяти.

На чтении по времени отклика все массивы проигрывают одиночному диску. Причем, у 8-дисковых массивов проигрыш не очень большой, а вот 4-дисковые массивы (кроме RAID10) отстают примерно на миллисекунду - при времени отклика меньше 6 мс это весьма заметный отрыв. Как и полагается, лучше всех себя чувствуют массивы RAID10 за счет выбора в зеркальных парах более «подходящего» диска.

Деградировавший RAID10 чувствует себя весьма неплохо, а вот массивам с вращающейся четностью повезло гораздо меньше - из-за появления накладных расходов на операции по восстановлению данных из контрольных сумм они ушли на последние места. Естественно, что хуже всех ситуация у RAID6 без двух дисков - ему приходится восстанавливать данные на основе сразу двух контрольных сумм.

Наблюдаемая на записи ситуация вполне логична: время отклика определяется суммарным кэшем контроллера и дисков, а значит, восьмидисковые массивы выигрывают у четырехдисковых, а RAID0 опережает RAID10, поскольку у последнего каждую пару можно рассматривать лишь как один диск, с точки зрения кэширования. Среди массивов с контрольными суммами восьмидисковые массивы также оказываются впереди, а RAID5 выигрывает у RAID6 - ему приходится считать лишь одну контрольную сумму, а не две. Приятно впечатляют результаты деградировавших RAID5 и RAID6, особенно последнего, лишившегося двух дисков - издержки, появляющиеся из-за необходимости не только считать данные для расчета контрольных сумм, но еще и вычислить их, весьма малы. За это стоит благодарить использованный мощный процессор: даже при потере двух дисков RAID6 на записи обладает временем отклика, сравнимым с результатом одиночного диска, что является очень хорошим результатом.

IOMeter: Random Read & Write

Оценим теперь зависимости производительности контроллеров в режимах чтения и записи с произвольной адресацией от размера используемого блока данных.

Результаты, полученные при работе со случайной адресацией данных, рассмотрим в двух вариантах, в соответствии с обновленной методикой. На блоках малого размера построим зависимости количества операций в секунду от размера используемого блока. А на больших блоках вместо количества операций возьмем в качестве критерия производительности скорость в мегабайтах в секунду. Такой подход позволяет оценить работу массивов сразу в двух типичных случаях нагрузки: работа малыми блоками характерна для баз данных и для нее более важно количество операций в секунду, чем привычная скорость; а вот работа большими и очень большими блоками близка к реальной работе с файлами малых размеров, и здесь уже на первый план выходит именно скорость в привычных мегабайтах в секунду.

Начнем с чтения.

На простом случайном чтении малыми блоками массиву просто не хватает нагрузки, чтобы продемонстрировать свою мощь - все массивы проигрывают одиночному диску. На удивление великолепно держится деградировавший RAID10, особенно с учетом того, что остальные массивы RAID10 как-то слишком мало отличаются от RAID0, хотя должны демонстрировать преимущество за счет чтения с зеркальных пар.

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

При работе большими блоками начинает играть скорость линейных операций и массивы RAID0 закономерно выходят вперед. Впрочем, восьмидисковый RAID10 лучше чем RAID0 на четырех дисках, который идет почти вровень с RAID10 из такого же количества дисков - похоже, контроллер умеет читать данные с обоих дисков в зеркальных парах. Даже деградировавший RAID10 быстрее четырехдискового RAID0 - потеря диска в одной паре не мешает ему читать с обоих дисков в остальных парах.

Та же линейная скорость диктует превосходство массивов RAID5 над RAID6, правда, результаты последних как-то слишком уж невелики. Не очень приятно выглядит и падение скорости четырехдискового RAID5 на очень больших блоках - 200 МБ/с не должно быть пределом для этого массива.

Деградировавшие массивы ведут себя на удивление предсказуемо: без одного диска RAID5 и RAID6 заметно теряют в скорости, а без двух дисков RAID6 становится сравним с одиночным диском.

Перейдем к операциям записи со случайной адресацией.

На записи малыми блоками все решает ее величество кэш-память. Контроллер демонстрирует просто таки идеальную работу - масштабируемость на месте, форма графиков в порядке, значеня тоже (кстати, они чуть выше, чем у 3ware).

При записи мелких блоков на массивы с контрольными суммами количество дисков по-прежнему имеет значение, но немалую роль играет и время расчета контрольных сумм, являющееся замедляющим фактором. Именно из-за того, что в RAID6 приходится считать сразу две суммы, даже деградировавший RAID5 оказывается быстрее, чем RAID6 на тех же восьми дисках. На удивление неплохо чувствует себя RAID6, лишившийся двух дисков - конечно, он попал на последнее место и пропустил вперед одиночный диск, но все же его результаты весьма неплохи для массива, которому при каждой записи приходится не только считывать данные, но еще и восстанавливать их из двух контрольных сумм сразу.

А вот на записи большими блоками мы видим что-то в корне непонятное: массивы RAID0 при работе с такими блоками неожиданно оказываются медленнее, чем RAID10. Особенно хорошо заметна эта странность на восьмидисковом RAID0 - у этого массива в принципе нет никаких предпосылок к тому, чтобы «упереться» в 120 МБ/с. Нет причин и у четырехдискового RAID0 на больших блоках проигрывать всем, включая одиночный диск. Зато очень хорошо понятно поведение деградировавшего RAID10 - он ведет себя точно также, как массив RAID0, то есть каждая зеркальная пара ведет себя как обычный диск. Но почему этого не произошло с обычными массивами RAID10 и что вообще происходит на больших блоках? Уж в случае RAID0, казалось бы, раскидывай блоки по страйпам и не знай проблем. Загадка.

Да, похоже, что с записью большими блоками у Adaptec что-то не задалось. Массивы с записью контрольных сумм идут практически вровень с одиночным диском, причем четырехдисковые массивы демонстрируют большие скорости, чем восьмидисковые. Зато все три деградировавших массива неожиданно рванули по скорости, обогнав своих полноценных конкурентов. Некоторый прирост скорости еще как-то можно было бы объяснить тем, что эти массивы попросту не рассчитывают контрольные суммы, когда они попадают на отсутствующий у них диск, но тогда бы лидировал RAID6 без двух дисков, да и не даст это настолько большой прибавки скорости. Странные, очень странные результаты демонстрирует Adaptec на записи большими блоками.

IOMeter: Sequential Read & Write

Ну что ж, пора оценить способности контроллеров в последовательных операциях. В данном тесте на накопители подается поток запросов с глубиной очереди команд, равной четырем. Раз в минуту размер блока данных увеличивается. В итоге мы получаем возможность проследить зависимость линейных скоростей чтения и записи массивов от размеров используемых блоков данных и оценить максимальные достижимые скорости.

О, какие великолепные результаты у восьмидискового RAID0! Да, мощного процессора вполне хватает, чтобы без проблем читать более чем по сто мегабайт в секунду с каждого из восьми дисков. Чтение с обоих дисков в зеркальных парах явно есть, хотя и не идеальное: если четырехдисковый массив RAID10 показал почти такие же результаты, как и RAID0, то вот восьмидисковый заметно отстал от своего собрата без зеркалирования. Зато приятно радует то, что чтение с обоих дисков в зеркальных парах работает уже на весьма небольших блоках.

Массивы с записью контрольных сумм демонстрируют меньшие скорости, чем RAID0, но это отставание вполне логично - за счет записи контрольных сумм мы теряем на каждом страйпе один блок в RAID5 и два блока в RAID6 - соответственно падает и скорость чтения, при одновременном обращении ко всем дискам. Хорошо заметно, насколько «дорого» с точки зрения производительности деградировавшим массивам обходится потеря дисков. Помимо закономерного снижения скорости от уменьшения массива на один диск, деградировавшие массивы теряют в скорости еще чуть больше 200 МБ/с, то есть цена «восстановления» данных с точки зрения производительности массива на чтения сравнима с потерей еще двух дисков. С этой точки зрения любопытно, что потерю второго диска RAID6 переносит почти безболезненно - потери составляют лишь 100 МБ/с, то есть, как раз соответствуют уменьшению массива на еще один диск.

Мда, линейная запись дается контроллеру как-то, мягко говоря, не очень хорошо. Особенно плохо выглядят результаты массивов RAID0 - их скорости меньше, чем у одиночного диска! К ним присоединился и деградировавший RAID10 - его график практически полностью совпал с графиком четырехдискового RAID0 (да, вот оно, объяснение низких результатов записи большими блоками со случайной адресацией). Можно было бы заподозрить контроллер в отключении отложенной записи, но полноценные массивы RAID10 демонстрируют вполне подобающие им скорости. Правда, их графики тоже далеко не идеальны: изломы на них говорят о том, что над прошивкой контроллера или его драйверами стоит поработать в поисках ошибок.

У массивов RAID5 и RAID6 с записью тоже далеко не все в порядке. Массивы на восьми дисках проигрывают одиночному диску, в то время как их четырехдисковые аналоги оказываются ощутимо быстрее, хотя тоже не добирают до значений, которые можно было бы предполагать, зная скорость одиночного диска. А вот деградировавшие массивы во всех смыслах на высоте - их скорости просто великолепны, причем лидирует RAID6 без двух дисков. И снова на графиках большое количество изломов...

Очень хочется надеяться, что это проблемы взаимодействия контроллера и нашего синтетического теста, и что в «FileCopy Test» мы увидим нормальные результаты.

IOMeter: Multi-thread Read & Write

Данный тест позволяет оценить поведение контроллеров при многопоточной нагрузке. В ходе него эмулируется ситуация, когда с накопителем работают от одного до четырех приложений, причем количество запросов от них изменяется от одного до восьми, а адресные пространства каждого приложения, роли которых выполняют worker-ы в IOMeter, не пересекаются.

При желании, вы можете увидеть таблицы с результатами тестирования по соответствующим ссылкам, а мы же в качестве наиболее показательных, рассмотрим диаграммы записи и чтения для ситуаций с глубиной очереди в один запрос, поскольку при количестве запросов в очереди, равном двум и более, значения скоростей практически не зависят от количества приложений.

Сразу несколько оправдаем результаты массивов на восьми дисках - максимальные скорости такие массивы показывают лишь при глубинах очереди, больших единицы. Мы с этим уже столкнулись ранее при тестировании мощных контроллеров на SAS-дисках, поэтому знаем, что стоит посмотреть в таблицу с данными. Справедливости ради надо также заметить, что Adaptec и при минимальных глубинах очереди демонстрирует на массивах очень неплохие скорости, его результат в данном плане пока лучший среди виденного нами.

При одном потоке на чтение накопители расположились вполне логично: восьмидисковые массивы лидируют, RAID0 впереди, следом RAID5 и RAID6. Любопытно, что четырехдисковый RAID10 оказался быстрее всех остальных массивов из четырех дисков.

Добавление второго потока в корне меняет расстановку сил. Лучше других себя ведут массивы RAID10 - они хоть и не показывают стремления распараллелить нагрузку, читая потоки с разных дисков в зеркальных парах, но все же демонстрируют минимальное снижение производительности. Более-менее неплохо пережили добавление потока и все восьмидисковые массивы, а вот четырехдисковым пришлось довольно туго. На удивление неплохо прошли это испытание и деградировавшие массивы (даже RAID6 без двух дисков), за исключением RAID10 - без одного диска на чтении двух потоков он стал идентичен четырехдисковому RAID0.

Дальнейшее увеличение количества потоков до трех и четырех привело к тому, что массивы RAID10 потеряли свое преимущество, особенно заметно «упал» восьмидисковый. Остальные же массивы просто понемногу снижают скорость.

При одном потоке на запись мы снова видим все те же непонятные проблемы, в результате которых лучше всех с записью справляются деградировавшие массивы, следом за которыми идут RAID10, в то время как восьмидисковые RAID5 и RAID6, а также оба RAID0 отстают даже от одиночного диска.

Второй поток на запись неожиданно приводит к значительным изменениям результатов, причем объяснить их нельзя, можно лишь констатировать. Так, деградировавшие массивы с записью контрольных сумм и все четырехдисковые массивы, кроме RAID0, теряют в скорости (причем RAID6 и RAID10 на четырех дисках весьма значительно), в то время как все остальные массивы наоборот, улучшают свои результаты. Особенно впечатляет «прыжок» по скорости, совершенный восьмидисковыми массивами RAID5 и RAID6 - их результаты улучшились вдвое. А ведь, казалось бы, ну какое им дело до второго потока, все равно же надо считать все те же контрольные суммы.

Дальнейшее увеличение количества потоков снова значительно снижает скорость восьмидисковых RAID5 и RAID6 настолько, что они опять проигрывают своим четырехдисковым аналогам. Словно для равновесия, снова возрастают скорости RAID10 на четырех и на восьми дисках. И лишь деградировавший RAID10 отличается как от деградировавших массивов, так и от RAID10, и схож с четврехдисковым RAID0 в своей низкой скорости.

IOMeter: Webserver, Fileserver и Workstation

В данной группе тестов накопители исследуются под нагрузками, характерными для серверов и рабочих станций.

Напомню, что в «Webserver» и «Fileserver» эмулируется работа накопителя в соответствующих серверах, в то время как в «Workstation» мы имитируем работу накопителя в режиме типичной нагрузки для рабочей станции, с ограничением максимальной глубины очереди на уровне 32 запросов. Естественно, что «Webserver» и «Fileserver» - не более чем собирательные названия; первый будет весьма схоже эмулировать нагрузку любого сервера, работающего только с запросами на чтение, а второй - сервера с преобладанием запросов на чтение, но при этом с определенной, заметно отличной от нуля долей запросов на запись.

В «Webserver», нагружающем диски исключительно запросами на чтение, RAID10 чуть-чуть, но все же опережает RAID0 - сказывается чтение с «удачного» диска в зеркальной паре, пускай и не самое эффективное (нам встречались результаты и получше). Деградировавший RAID10 очень резко теряет в производительности на больших нагрузках - он лишь незначительно превосходит четырехдисковые массивы. При этом на небольших нагрузках (до восьми запросов в очереди) он держится почти вровень с полноценным массивом.

Массивы RAID5 и RAID6 идут практически вровень при равных количествах дисков. А вот деградировавшим массивам приходится весьма туго. Так, для восьмидискового RAID5 потеря одного диска приводит к тому, что его производительность падает до уровня массива из четырех дисков. У RAID6 в такой же ситуации производительность снижается еще больше, а уж потеря двух дисков приводит к тому, что массив по скорости лишь незначительно опережает одиночный диск.

Итоговый рейтинг демонстрирует, что при такой нагрузке тип массива почти не имеет значения, а вот количество дисков, наоборот, влияет очень сильно.

А вот под нагрузкой, включающей в себя запросы на запись, RAID10 заметно отстает от RAID0 при больших глубинах очереди, хотя на малых нагрузках массивы идут очень близко. Да, у RAID0 с ростом нагрузки производительность растет большими темпами, чем у RAID10.

Появление запросов на запись приводит и к тому, что RAID6 отстает от RAID5. Интересно при этом обратить внимание на поведение деградировавших восьмидисковых массивов: в RAID5 производительность такого массива все же выше, чем у четырехдискового, а вот в RAID6 - ниже. Тот же RAID6, лишившийся сразу двух дисков, чуть опережает одиночный диск лишь на малых нагрузках, а вот на больших уже проигрывает битву и уходит на последнее место.

Количество дисков по-прежнему имеет решающее значение, но тип массива становится совсем немаловажен, если сервер имеет сколько-нибудь существенное количество запросов на запись. За повышенную надежность RAID6 и больший, по сравнению с RAID10, объем массивов с контрольными суммами приходится расплачиваться производительностью.

Под нагрузкой, характерной для рабочих станций, RAID0 ожидаемо лидирует. На удивление неплохо чувствует себя деградировавший RAID10 - он снова на малых нагрузках держится вплотную к полноценному массиву.

Как и следовало ожидать, расчет второй контрольной суммы заметно снижает производительность RAID6 относительно RAID5. Деградировавшие массивы держатся сравнительно неплохо, за исключением RAID6 без двух дисков - его производительность уже на всех глубинах очереди меньше, чем у одиночного диска. Любопытно, что при количество запросов в очереди от восьми до шестнадцати он вплотную приближается к своему конкуренту - видимо, такая нагрузка для него наиболее предпочтительна.

Не стоит, ох не стоит собирать высокопроизводительные рабочие станции на массивах с записью контрольных сумм, если только не требуется соответствующего уровня защиты данных. Четырехдисковый RAID0 обгоняет восьмидисковый RAID6 и вплотную приближается к RAID5. Да и RAID10 на четырех дисках выглядит весьма неплохо.

Уменьшение рабочего объема приводит лишь к увеличению превосходства RAID0 над RAID10.

Также растет и превосходство RAID5 над RAID6. Обращает на себя внимание и еще один момент: при работе с уменьшенной зоной гораздо комфортнее чувствуют себя деградировавшие массивы, тот же RAID6 без двух дисков уже оказывается быстрее, чем одиночный диск.

Уменьшение рабочей зоны дополнительно усиливает позиции RAID0 относительно остальных.

FC-Test

Следующим в нашей программе идет FileCopy Test. На накопителе выделяются два раздела по 32 ГБ, размечаемые на двух этапах тестирования сначала в NTFS, а затем в FAT32, после чего на разделе создается определенный набор файлов, считывается, копируется в пределах раздела и копируется с раздела на раздел. Время всех этих операций фиксируется. Напомним, что наборы «Windows» и «Programs» включают в себя большое количество мелких файлов, а для остальных трех шаблонов («MP3», «ISO» и «Install») характерно меньшее количество файлов более крупного размера, причем в «ISO» используются самые большие файлы.

Не забывайте, что тест копирования не только говорит о скорости копирования в пределах одного накопителя, но и позволяет судить о его поведении под сложной нагрузкой. Фактически, во время копирования накопитель одновременно работает с двумя потоками, причем один из них на чтение, а второй на запись.

Поскольку результатов получается много, то мы будем подробно рассматривать лишь значения, достигнутые на наборах файлов «Install», «ISO» и «Programs» в NTFS, являющихся более характерными для обычного использования массивов. Остальные результаты, вы, при желании, можете узнать из таблиц ниже:

Уф, все же результаты RAID0-массивов не столь плохи, как этого можно было бы ожидать из теста на последовательную запись. Правда, того уровня, который можно было бы предполагать, они все равно не достигают: скорость записи файлов ниже примерно в два с половиной раза. Удивляет и то, что максимальные скорости достигаются на наборе «Install», а не на «ISO», в котором находятся самые большие файлы. В результатах на «ISO» вообще много странного и необъяснимого, помимо общих низких скоростей. Так, восьмидисковый RAID10 оказывается в два раза медленнее, чем RAID0 на четырех дисках, хотя они должны идти вровень. А деградировавший массив каким-то образом оказывается быстрее полноценного. Все-таки, определенные проблемы с записью у контроллера есть.

Не все ладно с записью и у массивов RAID5 и RAID6. Как и в тесте на последовательную запись первые места занимают деградировавшие массивы, что является нонсенсом. Более того, с большими файлами в «ISO» восьмидисковые массивы работают вообще очень медленно (особенно забавна ситуация с RAID5: массив из четырех дисков в полтора раза быстрее, чем из восьми). Лишь на мелких файлах «Programs» расстановка сил более-менее в порядке, но вот значения скоростей там вовсе не радуют.

На чтении контролер явно упирается в какое-то ограничение по скорости: все массивы RAID0 и RAID10 демонстрируют примерно равные скорости. Причем с набором «Install» это приводит к забавному факту: скорость чтения с массивов оказывается ниже скорости записи. Правда, приятно радуют результаты, полученные на больших файлах - предел скорости чтения этого контроллера ощутимо выше, чем у рассмотренных нами ранее. Тот же 3ware 9690SA отказывался демонстрировать более 160 МБ/с, а Adaptec перешагнул за 400 МБ/с.

Кстати, судя по скорости RAID10 из четырех дисков, чтение с обоих дисков зеркальных пар действительно работает, иначе бы мы больше 250 МБ/с не увидели.

И снова тот же предел скорости, наблюдаемый на массивах из восьми дисков при работе с большими файлами. Но все же, в целом расстановка сил такая, какую и следовало ожидать. Даже деградировавшие массивы теряют скорость примерно в соответствии с уменьшением количества дисков в массиве.

На результатах копирования явно сказываются «странности», которые мы видели при записи: все массивы оказываются быстрее на наборе «Install», а не на «ISO». Если же сравнивать массивы между собой, то неожиданно низкие результаты демонстрирует RAID0 на восьми дисках, а вот восьмидисковый RAID10, как и полагается, показывает скорость, схожую с RAID0 из четырех дисков. Превосходно держится и деградировавший RAID10, почти не отстающий от полноценного массива.

Те же проблемы со скоростью работы с большими файлами в «ISO» и у массивов с записью контрольных сумм, правда, не настолько заметные. Опять же, нет и того поразительного лидерства деградировавших массивов - на копировании расстановка сил как раз вполне логична.

Увеличение дальности копирования мало меняет результаты. Единственным серьезым отличием становятся лишь слишком уж малые скорости у RAID5 и RAID6 из четырех дисков все в том же наборе «ISO» (да, даже на общем «пониженном» фоне). Странная, очень странная нелюбовь к большим файлам у этого контроллера, неладно что-то в Датском королевстве, то есть в прошивке.

WinBench 99

Ну и в завершение - привычные графики чтения в «WinBench 99».
Графики чтения RAID-массивов на контроллере Adaptec ASR-5805:
Особо внимательные читатели, еще не уставшие от чтения статьи, возможно, обратят внимание на то, что мы не даем графиков для массивов RAID0. Дело тут вовсе не в нашей зловредности, а в том, что Winbench 99 отказывался на этих массивах завершать тестирование, выдавая ошибку. Причем любые действия, включая уменьшение тестируемого объема, не давали положительного эффекта. Так как мы не сомневаемся в надёжности контроллера при работе с массивами RAID0 (многочасовые измывательства над массивами в тестах при помощи IOMeter говорят нам об отсутствии проблем), то спишем этот недостаток на более чем серьезный возраст нашего тестового пакета (как-никак, у него в этом году юбилей - 10 лет).

Сравним массивы по продемонстрированным скоростям чтения в начале и конце получившихся разделов:

Получившиеся результаты приятно радуют своей стройностью - все стоят на своих местах. Если посмотреть на сами графики, то они тоже приятно радуют малым количеством резких скачков скорости, даже деградировавшие массивы работают довольно ровно. Несколько смущает, пожалуй, только RAID5 на дисках своей длинной горизонтальной полкой на графике - такое впечатление, что 700 МБ/с для него является навязанным ограничением. Эх, жаль, что не получились графики RAID0.

Подведение итогов

Вспоминая впечатления, оставшиеся у нас от ASR-3405, хочется сказать, что пятая серия у Adaptec получилась заметно лучше. Сочетание мощнейшего по меркам RAID-контроллеров процессора и основательно переработанной прошивки привело к тому, что ASR-5805 разительным образом отличается от предшественника. Контроллер на всех типах массивов демонстрирует великолепные результаты при работе под серверной нагрузкой, умеет выбирать в зеркальной паре диск с меньшим временем отклика, да и читать с обоих дисков пары одновременно тоже вполне способен. Весьма неплохо контроллер работает и со сложными (с точки зрения создания хорошей прошивки) массивами RAID5 и RAID6, деградировавшие массивы так же были не забыты при оптимизации микрокода. Скорость линейного чтения с массивов у него хоть и далека от теоретической, но все же значительно лучше, чем у виденных нами раньше его конкурентов. И все же, без ложки дегтя не обошлось: ей стала необычайно низкая производительность некоторых массивов при последовательных операциях записи. Особенно плохо контроллеру удается запись больших файлов, так что останавливаться на достигнутом компании Adaptec пока еще рано.

Другие материалы по данной теме

Тестирование SAS RAID-контроллера 3ware 9690SA-8I
Тестирование SAS RAID-контроллера Promise SuperTrak EX8650
Сравнительное тестирование RAID-контроллеров Adaptec

Как ни странно, но на сегодняшний день RAID стеки это частные решения, не подчиняющиеся стандартам. Можно снять все физические диски с созданными на них RAID томами, например, с контроллера Adaptec 6805 и перенести их на контроллер 8885 и тома будут видны. Но если попробовать перенести таким образом тома на контроллер другого производителя, то чуда не случится, и ни будет никакой возможности увидеть данные и эти RAID тома. Почему так происходит? Потому что контроллер другого производителя поддерживает свой собственный стек, не совместимый со стеком Adaptec.

Каждый RAID том представляется операционной системе компьютера как «SCSI диск», который и будет виден как отдельный объект в дисковых утилитах типа disk manager.Выглядит это так.

Таким образом, в менеджере дисков можно увидеть 4 виртуальных диска: RAID0, RAID1 и два диска RAID5.

При создании томов работает каждый уровень.

Задача уровня физических дисков – создать специальную область на дисках, где будет храниться информация о создаваемых томах. Такая область называется областью метаданных и представляет из себя сложный контейнер хранения, где хранится служебная информация. В эту область имеет доступ только операционная система контроллера и больше никто. В стеке Adaptec этот процесс создания служебной области называется – инициализация и выполняется через команду – initialize .

В RAID контроллерах, которые поддерживают режим HBA, есть и обратная команда – deinitialize (это контроллеры 7 и 8 серии). Эта команда полностью удаляет с физического диска такую структуру данных и переводит данный диск в режим HBA. Т.е., для того чтобы контроллер 7 или 8 серии начал работать как обычный HBA на нем достаточно деинициализировать все диски. Тогда они все будут видны в утилите центральной операционной системы типа DISK MANAGER и никакие другие операции не требуются.

На физическом уровне выполняется и другая известная функция, называемая – coercion . В стеке Adaptec она производится одновременно с initialize. Эта функция немного «подрезает» емкость жесткого диска. Дело в том, что диски одной и той же категории по емкости от разных производителей все же имеют неодинаковую емкость. Чтобы диск одного производителя можно было в будущем в случае необходимости заменить диском другого производителя и выполняется функция coercion. Отрезанная емкость просто навсегда “теряется” и никак не используется.

На физическом уровне возможно размещение различных сервисных функций – проверка диска деструктивным или недеструктивным методом, форматирование, полное стирание данных, заполнение диска нулями и т.д.

Логический уровень необходим по двум причинам:

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

Во-вторых, при создании таких объектов информация о них попадает в метаданные, и они перестают быть привязанными к физическим координатам. После этого диски можно переносить с одного порта контроллера на другой, переносить тома с одного контроллера на другой и это будет по-прежнему замечательно работать.

Дальше наступает очередь уровня RAID . Как правило, современные стеки имеют два подуровня на этом уровне. На каждом подуровне располагаются элементарные RAID, такие как: chain или span (это не совсем RAID, это просто “суммирование” емкостей с разных дисков), RAID0, RAID1, RAID1E, RAID5, RAID6 и т.д.

Самый нижний подуровень принимает логические диски, например, LD1, LD2, LD3, как на рисунке, и «выпекает» из них том RAID5. То же самое происходит и с LD4, LD5, LD6. Из них получаем второй RAID5. Два RAID5 тома подаются на еще более высокий уровень, где к ним применяют функцию RAID0. На выходе мы получаем комплексный том, называемый RAID50 (где 5 означает тип RAID, используемый на нижнем подуровне, а 0 – тип функции RAID с верхнего уровня). Единственное, чего не хватает в определении – сколько RAID5 (в данном случае 2) было использовано для создания RAID50. В стеке Adaptec это называется second level device. Этот параметр будет нужен, если Вы будете создавать сложные тома типа 50 или 60.

Самый верхний уровень нужен для того, чтобы предоставить такой виртуальный объект для доступа операционной системы. При передаче на этот уровень предлагается ряд сервисных функций. Самые важные в стеке Adaptec две – build и clear.

Clear записывает на весь новый том, который передается ОС, нули.
Build «строит» новый том. Например, если это RAID1, то все содержимое первого контейнера скопируется в содержимое второго. И так для всех контейнеров.

На рисунке - Виртуальный контейнер типа RAID1. Операция build.

Если у Вас новые диски, с фабрики, то в их секторах записаны нули. Поэтому результат действия обеих функций будет одинаковым.

Отличие между SimpleVolume и HBA режимом.

Эти два режима крайне похожи друг на друга. Оба могут использоваться для создания Software RAID решений.

При работе диска в HBA режиме на нем не создаются метаданные. И нет «подрезания» ёмкости функцией coercion. Это может вызвать проблему при необходимости замены диска на диск другого производителя. Диск напрямую передаётся операционной системе. При этом кэш контроллера с ним работать не будет!

В случае создания Simple Volume через конфигурацию томов, на диске создается область метаданных, “подрезается” емкость функцией coertion. Далее через утилиту конфигурации создается Simple Volume том с использованием всей свободной емкости диска. И после этого данный объект передается в работу центральной операционной системе.

Сегодня стеки RAID контроллеров постоянно совершенствуются. Компания Adaptec в своей функции MaxCache plus устанавливала еще один уровень в стек, так называемый уровень tier, c подуровнями. Это позволяло взять один RAID5 том, созданный на SSD дисках, и другой том, например, RAID60, созданный на дисках SATA с 7200 rpm и собрать из них комплексный, виртуальный том, где наиболее востребованные данные хранились на RAID5, а наименее востребованные на RAID60. При этом тома можно было брать с разных контроллеров. Сегодня эта функция не поддерживается в силу перехода таких возможностей в серверные операционные системы. Естественно, стек контроллеров, как виртуализационный механизм, не стоит на месте и постоянно совершенствуется и на уровне виртуализации и на уровне основных и сервисных функции.

Устройство современного RAID контроллера.

Современный RAID контроллер представляет из себя информационную систему (упрощенно – компьютер), которая в силу выполнения своих основных функций: создания виртуального контейнера, размещения и обработки информации в контейнерах (по сути, ЧТЕНИЕМ – ЗАПИСЬЮ информации) обменивается данными с двумя другими типами информационных систем:
1. C операционной системой;
2. С HDD или SSD дисками.

С точки зрения внутренней архитектуры, современный RAID контроллер представляет из себя следующий набор основных подсистем:

Микросхема RoC (RAIDonChip);
Оперативная память;
Управление “защитой” кэш памяти (как правило, это отдельная дочерняя плата, но в последних реализациях для 8-ой серии контроллеров Adaptec этот модуль встроен в микросхему RoC);
Суперконденсатор, как источник питания для модуля защиты кэш, используется в случае пропадания основного питания;
Flash-память и nvSRAM (память, которая не теряет информацию при выключении питания);
Разъемы SAS, где каждый отдельный физический разъем собран по принципу четыре порта SAS в одном физическом разъеме;
Разъем PCI-E.

Таблица - Основные подсистемы RAID контроллера.

Основные функции современных RAID контроллеров Adaptec.

Поддержка режима HBA.

Мы уже рассмотрели выше, какие модели RAID контроллеров поддерживают режим HBA. Важно отметить, что это делается независимо для каждого диска. Т.е., на контроллере, если вы не будете инициализировать часть дисков на физическом уровне, они автоматически попадут в программу типа «disk manager» и будут там видны и доступны для работы с ними. Вы можете одну часть таких дисков в режиме HBA использовать как одиночные диски, а другую часть использовать для создания software RAID средствами операционной системы. Проинициализированные диски будут использоваться для создания RAID томов средствами RAID контроллера.

Гибридные тома.

На последних версиях прошивки контроллер Adaptec автоматически создает Hybrid RAID-массив, когда вы создаете RAID 1/10 из одинакового количества SSD и HDD (но в старых прошивках было важно, чтобы в RAID1 парах SSD диск стоял «мастером», а HDD диск «слейвом»). Если Вы не знаете, как это проверить – обратитесь с службу тех. поддержки Adaptec. Контроллер Adaptec делает запись одновременно на HDD и SSD. В режиме гибридного тома чтение идет только с SSD! (для тома из двух HDD дисков при превышении некоторого порога операций ввода-вывода чтение происходит с двух дисков. В этом главное отличие гибридного режима RAID1/10). Результат – надежный массив с отличной производительностью чтения. Чтение как у одиночного SSD диска. Это на несколько порядков выше чему у HDD. Функция стандартно поставляется со всеми контроллерами Adaptec Series 2, 5,6, 7, 8.

Поддержка типов томов, являющихся заменой RAID5.

Надеюсь, вы хорошо представляете себе контейнер RAID5 - это достаточно классическое решение.

Красным показан контейнер хранения информации, созданный RAID контроллером. Это контейнер типа RAID5. Сам том RAID5 состоит из большого количества таких виртуальных контейнеров, сложенных в некоторую «пачку». Контейнер RAID5 состоит из набора секторов отдельных физических дисков. Особенность контейнера RAID5 заключается в том, что он может «пережить» проблемы в ряде контейнеров жестких дисков, из которых он состоит, т.е., секторы жестких дисков, которые входят в состав RAID5 контейнера, теряют свою информацию, но сам RAID5 контейнер ее хранит. Это происходит до определенного предела. При некотором количестве «испорченных» секторов сам RAID5 контейнер уже не сможет гарантировать 100% хранение информации. Из-за перехода с технологии SCSI на технологию SAS предлагаемое базовое качество хранения информации контейнером RAID5 очень сильно ухудшилось, буквально, на несколько порядков.

Произошло это из-за ряда объективных причин:
1. Из-за поддержки SATA дисков, особенно десктопного класса, качество хранения информации в контейнере типа «сектор диска» заметно упало (SCSI контроллеры поддерживали только высококачественные SCSI диски);
2. Количество дисков на контроллере выросло многократно (2х канальный SCSI контроллер – максимум 26 дисков, с учетом производительности 8 -10 (по 4-5 на канал));
3. Емкость дисков выросла значительно. Это значит, что в том RAID 5 может попадать намного больше контейнеров RAID5 (мах. Емкость SCSI дисков 400GB, максимальная емкость современного SATA жесткого диска – 8 ТБ).

Все это увеличивает вероятность возникновения проблем в одном контейнере RAID5, что значительно уменьшает вероятность сохранения информации в томе RAID5. По этой причине в современные стеки RAID контроллеров добавлены решения, которые позволяют исключить использование RAID5. Это RAID1E, RAID5EE и RAID6.

Раньше единственной альтернативой RAID5 был RAID10. Поддержка RAID 10, естественно, сохранилась.

Варианты замены RAID5:

Bad Stripe

Раньше, если даже один контейнер контроллера (страйп) терял информацию или не мог гарантировать ее сохранность, это приводило к ситуации перевода всего тома в режим offline со стороны RAID контроллера (остановка доступа, буквально, означала – контроллер не может гарантировать 100% целостность пользовательских данных на томе).

Современный контроллер “отрабатывает” такую ситуацию по-другому:
1. Доступ к тому не останавливается;
2. На томе выставляется специальный маркер “bad stripe”, которые означает, что в RAID томе есть специальные контейнеры, которые потеряли информацию;
3. О таких «испорченных контейнерах» сообщается операционной системе, чтобы она могла оценить возможные меры по предотвращению потери информации или ее восстановлению.

Маркер bad stripe невозможно удалить с тома. Можно только такой том удалить и создать заново. Появление тома с флагом «bad stripe» говорит о СЕРЬЕЗНЫХ ошибках или проблемах на этапе проектирования системы хранения или на этапе ее эксплуатации. Как правило, за такой ситуацией стоит серьезная некомпетентность проектировщика или системного администратора.

Основной источник проблем такого рода - неправильно спроектированный RAID5.

Некоторые реализации RAID 5 (например, RAID5 на десктопных дисках) запрещены для томов с пользовательскими данными. Требуется, как минимум, RAID5 + Hot Spare, что не имеет смысла при наличии RAID6. Получается, что там, где надо было создать RAID6, был создан RAID5, что через несколько лет эксплуатации привело к появлению маркера BAD STRIPE.

SSD кэширование

Функция SSD кэширования является одной из самых востребованных функций для оптимизации производительности RAID томов мощных систем хранения с большим количеством пользователей без значительного увлечения стоимости, количества юнитов решения, без потери емкости системы хранения и обеспечения оптимального энергопотребления.

Для применения SSD кэширования на запись, следует убедиться в выполнении двух условий:
1. Приложение работает в режиме «случайного чтения»;
2. Запросы к данным имеют неравномерную природу – есть контейнеры уровня RAID, к которым обращаются чаще, чтобы считать оттуда данные, а есть те, к которым обращения идут реже.

Надо отметить, что чем больше пользователей у системы, тем вероятнее, что запросы к отдельным контейнерам примут форму стандартного статистического распределения. По параметру «количество запросов в единицу времени» можно выделить условно «горячие данные» (количество обращений к ним будет больше заданного параметра) и «холодные данные» (количество обращений к ним меньше заданного параметра).

Работа SSD кэш на чтение заключается в копировании «горячих данных» на SSD диски и дальнейшем чтении с SSD, что ускоряет процесс в разы. Поскольку это копирование, то кэш на чтение имеет естественную защиту, если SSD диск, формирующий область SSD кэш, выходит из строя, это приводит только лишь к потере производительности, но никак не к потере данных.

Основные настройки функции SSD кэширования для контроллеров 7Q, 8Q:
1. Прежде всего убедиться, есть ли у Вас «горячие данные» и какой они имеют размер. Лучше всего это сделать экспериментально, поместив достаточно большой SSD диск в область кэша и сконфигурировав его в режиме Simple Volume. Такую работу могут сделать для Вас компании-интеграторы. Примерно через неделю через функцию управления можно снять статистику SSD кэширования. Она покажет есть ли у Вас «горячие данные» и какой объем они занимают.
2. К данному объему желательно добавить10-50 % емкости и на основании этих данных настроить Вашу схему кэширования на случай увеличения объема «горячих данных» в будущем, если такая тенденция есть.

Настройки позволяют от емкости ваших SSD дисков «отрезать» нужную емкость, забрать ее в RAID том нужного типа, а оставшуюся емкость можно перевести в обычный RAID том.

Далее следует оценить, есть ли смысл использовать SSD кэш на запись. Как правило, интернет приложения работают на чтение. Кэш на запись, в основном, используется как дополнение к кэшу на чтение, если приложение помимо чтения использует и запись. И в случае использования кэша на запись требуется обеспечить защиту кэша. Если что-то случается с областью кэша, то данные, помещенные туда при кэшировании записи, будут потеряны. Для защиты достаточно использовать RAID том, дающий избыточность по дискам, например, RAID1.

Возможные режимы конфигурации SSD кэш области.

Для отдельных томов на контроллере можно независимо включать и выключать SSD кэш на чтение и на запись в зависимости от потребностей и типов приложений, работающих с каждым томом.

Поддержка uEFI.

Все контроллеры и HBA текущей линейки продуктов Adaptec поддерживают режим uEFI биоса материнских плат. Переход с MBR на uEFI позволил, например, создавать системные и загрузочные тома больше 2TB, что было невозможным на платах с MBR BIOS (отметим, что все продукты Adaptec полностью поддерживают тома >2TB, со стороны контроллеров и HBA этой проблемы не существует). Есть много других преимуществ использования uEFI режима. Например, при поддержке дисков с размером сектора 4K. Все продукты Adaptec текущей линейки поддерживают диски с сектором 4К, кроме 6-ой серии контроллеров.

Важно помнить, что если материнская плата использует режим MBR, то утилита конфигурации контроллера вызывается через Cntrl +A.

На рисунке стандартная утилита конфигурации Adaptec, вызываемая через комбинацию клавиш Cntrl +A.

В случае режима uEFI конфигуратор контроллеров и HBA интегрируется в BIOS материнской платы. Эту утилиту легко найти по строчкам, содержащим слово «Adaptec» или «PMC». И, как видно на примере ниже, uEFI утилита имеет более расширенный функционал, чем утилита, вызываемая через Cntrl + A.

Функции Hot Spare.
Hot Spare диск выполняет роль пассивного элемента RAID тома, и «забирается» в RAID том, если с каким-то из дисков в составе тома что-то случилось, и он больше недоступен для выполнения своей работы. HOT SPARE называется диск, который установлен на контроллер, раскручен и назначен к одному или нескольким томам.

Относительно последней части определения HOT SPARE, можно создать 3 вида дисков:

Hot Spare диски используются в стеке Аdaptеc для ручного «ремонта» томов, у которых по разным причинам вышел из строя один диск. Например, Ваш RAID5 том потерял один диск и перешел в состояние «degraded». Вы вставляете новый диск вместо старого или в любой другой свободный слот, нажимаете функцию rescan и теперь видите новый диск на уровне физических дисков стека. Далее – объявляете его как HOT SPARE (неважно какого типа, например, Global Hot Spare) и ждете, когда это диск на 100% «встроится» в том. Том переходит в состояние – Optimal. После этого, Вы выбираете команду – delete hot spare. Эта команда снимает статус HOT SPARE с данного диска, и он становится полноценным участником данного RAID тома.

Функция Power Management.

RAID тома работают по-разному. Например, тома, созданные для резервного копирования данных, могут использоваться для перемещения данных, к примеру, два – три дня за месяц. Возникает вопрос: насколько хорошо подавать питание на жесткие диски и держать диски раскрученными, если фактически все оставшееся время они не используются?

Решением этого вопроса занимается функция power management. Ее философия – если диски не используются, их вращение можно замедлить (если такая функция поддерживается дисками), а потом полностью остановить и держать, пока они не понадобятся, в выключенном состоянии. Настройки данной функции крайне простые.

Сначала целиком на контроллер задается время по дням недели, когда эта функция активирована, а когда нет. Эта настройка привязана к работе типичной компании. Задаются параметры введения в работу внутренних и внешних дисков – попарно, по три, по четыре и т.д., чтобы распределить нагрузку на блоки питания. Кроме этого, задаются три значения таймера. По истечении первого, если нет операций ввода-вывода на диски данного тома, то эти диски перейдут в состояние «stand by», т.е. уменьшат свои обороты на 50%. Не все диски поддерживают этот режим, если он не поддерживается, то с диском ничего происходить не будет. По истечении второго таймера диски полностью остановятся и перейдут в состояние «power off». Третий таймер используется для периодической проверки дисков, которые выключились надолго. Контроллер включает диски, проводит их недеструктивную проверку и, если все ОК, то переводит их снова в «power off» состояние.

После этих настроек Вы можете активировать power management схему для каждого тома, где это будет полезным. Такие тома в системе управления будут помечаться зеленым цветом. Максимум преимуществ данная функция дает при использовании в центрах обработки данных, позволяя не только прямую экономию энергии за счет остановки дисков, но и вспомогательную экономию за счет уменьшения оборотов вентиляторов, обдувающих диски, когда последние переводятся в выключенное состояние.

Управление системами хранения Adaptec.

Утилиты управления, которые входят в пакет Max View Storage Manager (MSM) построены на самых передовых стандартах и используют самые последние тенденции в совершенствовании принципов и улучшении эффективности управления. Поэтому мы легко можем использовать Adaptec Max View Storage Manager как базовую модель, чтобы посмотреть на основные функции и методы в области управления системами хранения. В качестве основного элемента управления используется RAID контроллер, который может обмениваться служебной информацией с дисками, экспандерами и корзинами и, таким образом, поддерживать функции управления для всей подсистемы хранения в целом.

Основные возможности современных систем управления системами хранения:

В качестве клиентского приложения используется стандартный WEB браузер.
CIM провайдер для работы в виртуальных средах. CIM провайдер из пакета MSM позволяет осуществлять полное управление RAID контроллером из-под любой виртуальной среды. Например, при использовании vmware.
Использование CLI (command line interface) утилит. В пакете MSМ, помимо графической утилиты управления, в качестве клиентской части которой используется WEB браузер, присутствует CLI утилита – ARCCONF.EXE. Список команд можно получить, используя документацию с сайта Adaptec . С помощью CLI можно создавать различные скрипты (мини программы), которые могут использоваться интеграторами для автоматизации производства, настроек, изменения прошивок и т.д. и в компаниях, использующих RAID контроллеры для автоматического опроса систем хранения на предмет выявления нештатных ситуаций.
Возможность управления всей инфраструктурой из одного клиентского приложения. C помощью MSM в окне Enterprise View Вы можете «забрать» на управление все серверы с установленными в них одним или несколькими RAID контроллерами. Для этого вы или прямо указываете IP адрес таких систем, или используете функцию Auto Discovery.

Высокий уровень детализации, визуализации и вложенности объектов управления. Администратор может видеть, что весь сегмент сети стал красным, это означает – существует неисправность. Если раскрыть иконку сетевого сегмента, то будут видны все сервера. Проблемный сервер будет отмечен красным цветом. Если кликнуть мышкой на этом сервере будут видны RAID контроллеры, установленные в этой системе. Красный цвет одного из них означает какую-то проблему. При дальнейшей детализации будут видны тома, созданные на этом контроллере и проблемный том. И так с точностью до проблемного физического диска. Теперь администратор точно знает, что случилось, к каким последствиям это привело, и какой диск надо заменить.
Высокий уровень безопасности систем управления при использовании стандартных сетевых протоколов. Механизмы управления системами хранения, очевидно, нуждаются в защите. Ведь при несанкционированном доступе или при открытом канале управления пользовательские данные могут быть уничтожены без возможности восстановления. С этой целью MSM использует базу пользователей и паролей из самой операционной системы. Кроме этого, на канале между браузером и сервером управления используется шифрование трафика через протокол HTTPS. В других компонентах системы управления вопросы безопасности также решаются на самом высоком уровне.
Возможность отправки важных сообщений из системы хранения администратору. Чтобы не «приковывать» навеки взгляд администратора к экрану с MS в WEB браузере, система управления может быть настроена на отправку сообщений по E-mail. MSM имеет возможность отправлять все типы сообщений, включая тестовые. Наибольшую важность имеют сообщения типа Warning и Error, которые напрямую связаны с переходами RAID томов в состояние Degrade и Failed. Такие сообщения через почтовые приложения могут быть легко переданы на мобильный телефон администратора.

дисковая подсистема

hba

Добавить метки