Компания Lenovo недавно представила две новые дисковые системы S2200 и S3200. Рассчитаны они, прежде всего, на малый бизнес. Конкуренция на этом рынке довольно активная - среди наиболее активных игроков HP с системами MSA, Dell с MD3, NetApp E2700 и FAS2500, EMC VNXe, IBM V3700 и целый ряд B-брендов.
Если посмотреть на характеристики объявленных новинок, то мы увидим классическую архитектуру двухконтроллерного массива, который масштабируется вертикально (за счет добавления дисковых полок). Для S2200 максимальное количество дисков составляет 96 (контроллерный модуль и 3 полки по 24 диска), для S3200 максимум можно подключить 192 диска (контроллерный модуль и 7 полок по 24 диска). Если использовать полки с дисками 3.5" (по 12 дисков на полку), то максимальное число дисков будет 48 и 96, соответственно.
Технические подробности, сравнение систем друг с другом, а также с аналогом от HP - в полной версии статьи по ссылке.
Раз я упомянул анонс новых систем IBM FlashSystem 900 и V9000, то наверное стоит немного уделить внимания уникальной “фишке” этих систем - реализации отказоустойчивости.
В FlashSystem используется RAID5 для защиты от сбоя всего модуля MicroLatency, но это далеко не единственная технология, обеспечивающая отказоустойчивость:
RAID5 защищает систему от сбоя модуля. В зависимости от числа модулей, конфигурация массива вальируется от 2D+1P+1HS, до 10D+1P+1HS. В системе всегда только один RAID массив для модулей, поэтому объем всех модулей должен быть одинаковым
RAID5 внутри каждого модуля защищает от сбоя отдельного чипа
Variable Stripe RAID внутри каждого модуля защищает от частичного сбоя чипов NAND
ECC на уровне чипа защищают от битовых и блочных ошибок
Кроме того, как и в любых системах на базе flash, присутствует зарезервированное пространство, которое используется когда очередная ячейка выходит из строя.
Совместное использование двух уровней RAID ("внутри” отдельных модулей и между всеми модулями) и носит фирменное название 2D RAID (two-dimensional RAID).
Благодаря такой многоуровневой защите можно минимизировать возникновение ошибок, приводящих к необходимости менять целый модуль MicroLatency. Кроме того, сохраняется возможность использовать RAID5 (а не RAID6) и не сталкиваться с повышенными рисками множественных ошибок (хотя объем самих модулей может достигать 5.7ТБ).
Технология RAID “внутри” модуля MicroLatency была запатентована еще компанией TMS (где и родились предшественники нынешних FlashSystem - тогда они назывались RamSAN) и носит название Variable Stripe RAID (VSR). Она позволяет не просто обеспечить отказоустойчивость при большинстве частичных сбоев внутри модуля, но и позволяет большой срок службы модуля, а это, в свою очередь, снижает стоимость, так как не нужно закладывать дополнительные расходы на “лишние" замены в гарантийный срок.
Каждый MicroLatency модуль имеет внутри несколько чипов Flash и 4 FPGA контроллера, которые и реализуют VSR. Каждый из этих контроллеров, в свою очередь, “отвечает” не более чем за 20 чипов. Но RAID внутри модуля построен не на уровне чипов, а на уровне слоя (plane) в отдельных чипах (по 16 слоев в каждом чипе). Все это позволяет спокойно пережить сбой до 256 блоков перед тем как весь слой будет считаться сбойным. Чтобы модуль все-таки вышел из строя необходимо, как минимум:
признать сбойными 64 слоя
сбой 4 чипов в модуле целиком
Таким образом, разработчики FlashSystem постарались сделать все возможное, чтобы продлить жизнь отдельного модуля MicroLatency и обеспечить отказоустойчивость.
Отличительной особенностью VSR является:
RAID защищает не отдельный чип, а только слой чипа. Это позволяет гораздо эффективнее использовать модули, не производя лишних замен и перестроений массивов;
страйп не фиксирован в размере - в зависимости от состояния слоев, он может быть не в стандартной конфигурации 9D+1P, а 8D+1P, 7D+1P или 6D+1P.
Именно вариативный размер страйпа позволяет максимизировать объем полезного пространства в модуле, не “отбраковывая” рабочие части остальных чипов. Давайте посмотрим как это работает. В случае, когда мы используем обычный RAID-массив (пусть даже и на уровне слоя микросхемы), сбой в любом из слоев приведет к тому, что нам будет нужно исключить все такие же (еще рабочие!) слои остальных чипов, чтобы сохранить архитектуру массива:
При использовании Variable Stripe RAID, нам достаточно перестроить страйп на меньшем количестве элементов:
Т.е. мы потеряем только малую часть одного чипа и не потеряем в скорости для имеющихся данных. Так как сбои чаще всего происходят не на уровне всей микросхемы, а на уровне отдельных блоков, мы получаем прекрасную возможность избежать лишних перестроений массивов, “отбрасывания” целых чипов из-за сбоя в одном слое и, разумеется, гораздо быстрее можем исправить проблему, так как в перестроении участвует лишь очень малая часть данных.
Кроме того, VSR работает “внутри” каждого модуля, не требуя для восстановления "перекачки" данных к центральному процессору или FPGA, отвечающему за RAID на уровне системы. А это, в свою очередь, позволяет избежать деградации производительности при перестроении массивов, что для All Flash систем, где мы ожидаем получить гарантированный уровень производительности, очень важно.
И вот только в том случае, когда исчерпаны все “внутренние” ресурсы MicroLatency модуля по обеспечению отказоустойчивости, система использует RAID5 между модулями и задействует spare модуль для перестроения массива.
Первая статья описывает текущую ситуацию в системах NetApp E-series (бывший LSI/Engenio). После многолетнего использования ASIC для расчета контрольных сумм, сейчас нагрузка по расчету данных для RAID перенесена в центральный процессор. С одной стороны, это конечно упрощает дизайн системы, кроме того, мы все прекрасно знаем, что производительность современных процессоров сделала огромный рывок (и продолжает "рвать" :) Поэтому многие компании спокойно используют программные решения (стоит упомянуть в первую очередь конечно различные реализации Software Defined Storage).
С другой стороны, в NetApp столкнулись с проблемой производительности (СХД может создать поток, превышающий возможности процессора). Можно говорить что это большой плюс ситем NetApp - загрузить процессор это тоже достижение! Справедливости ради нужно сказать, что в NetApp используется не совсем программное решение, а аппаратные возможности процессоров Intel (Crystal Beach 3 DMA). Так вот, оказалось, что на больших нагрузках, процессор не может обработать весь поток, который могут обеспечить остальные компоненты СХД. Для дальнейшего повышения производительности, в новых версиях микрокода происходит автоматическое переключение на программный режим расчета контрольных сумм, что позволяет повысить интегральную производительность системы. Все управление процессом заложено в микрокод и "подкрутить" что-то своими руками не получится.
Новые возможности микрокода доступны в системах E5400/5500 и EF540/550 - остальные по-прежнему используют RoC чипы для расчета контрольных сумм.
С другой стороны баррикад, в HP продолжают восхвалять свой ASIC, использующийся в системах 3PAR. Безусловно, "заточенный" под определенные операции чип, можно снять множество головных болей с архитектора СХД. Здесь и предсказуемая производительность (в силу узкой специфичности чипа), реализация определенного функционала "в железе" (в 3PAR это, в первую очередь, thin provisioning), разгрузка центрального процессора для других задач (впрочем, это спорный аргумент - все зависит от качества кода "других задач").
Есть ли уже победитель или стоит подождать? Пока на рынке остается целый ряд успешных решений, использующих специализированные процессоры, говорить о победе "commodity" процессоров еще рано. Однако, не за горами день, когда производительности стандартного чипа будет вполне достаточно. Intel ведет активную работу в этом направлении и явно не собирается останавливаться. Активное продвижение SDS на рынок систем хранения только способствует тому, что в один прекрасный момент вести разработку СХД со "своим" чипом будет слишком дорого.
Обновилась камасутра библия для владельцев систем NetApp и IBM N-series – документ с говорящим за себя названием “NetApp Storage Best Practices for VMware vSphere” (TR-3749). Основные изменения коснулись возможностей vSphere 5. Скачать можно совершенно свободно, даже регистрация не требуется. Всем, кто использует VMware, документ обязательно нужно прочитать хотя бы один раз!
Для серверов IBM x3650M3 и x3550M3 анонсирован новый RAID контроллер – ServeRAID M5016. Ключевая особенность – наличие 1GB кэш памяти с защитой, но не батарейкой, а флэш-памятью с конденсаторным модулем (ну наконец-то уже!). Для активации RAID6/60 более не требуется дополнительный ключ – все работает “из коробки”.
Предвосхищая – модуль с конденсаторами на фото не показан, он “болтается” отдельно, пристегнутый длинным кабелем к контроллеру (примерно как с использованием Remote Mount Cable на M5015).
LSI анонсировал два новых контроллера – MegaRAID SAS 9265-8i и 9285-8e. Это представители уже второго поколения контроллеров с поддержкой SAS2 (6Gbps). Оба контроллера построены на одном чипе (RAID on Chip, ROC) – LSISAS2208, работающем на 800МГц и имеющем два ядра. Объем кэша составляет уже 1ГБ (используется память DDR3). Фактически отличие контроллеров только в том, как расположены порты – 9265-8i имеет 8 портов “внутрь”, а 9285-8e 8 портов “наружу”. Отличается и максимально поддерживаемое число дисков (через экспандер) – 128 для 8i и 240 для 8e. Выпущена и новая модификация батареи для защиты кэша – LSIiBBU09. Новизна состоит в том, что батарея более терпимо относится к повышенным температурам внутри сервера (до 550C). Как и для прошлого поколения, предлагаются опциональные “расширения”: FastPath (оптимизация для работы с SSD), CacheCade (возможность использовать SSD в качестве “умного” кэша), Recovery (снапшоты) и SafeStor (поддержка шифрования на уровне дисков).
Но, конечно же, самое интересное это производительность новых контроллеров (что особенно актуально при использовании SSD дисков). Заявлено, что при использовании технологии FastPath производительность выросла более чем в 3.5 раза по сравнению с прошлым поколением до 465,000 IOPs:
На картинке – сравнение первого и второго поколения 6Гбит контроллеров LSI (внутренние тесты LSI) для вариантов с включенным и отключенным FastPath. подробности (и другие результаты можно найти здесь).
Немного удивляет батарейка вместо ставшими уже привычными (у других производителей) суперконденсаторов и флэш-памяти. А учитывая, что уже наверное пару месяцев назад были вполне предметные разговоры про аналогичную технологию и у LSI (и даже назывались модели контроллеров) это еще более странно. И до сих пор, кроме строчки в списке зарегистрированных торговых марок, никакой официальной информации про это нет. Посмотрим, как это все отразится на PMC-Sierra (Adaptec), у которых сейчас только начинаются продажи первых 6Гбит контроллеров. LSI сделал все возможное (включая прочное сотрудничество с такими производителями серверов как IBM, Dell и Fujitsu), чтобы занять как можно большую долю рынка.
Компания PMC-Sierra, впервые после приобретения Adaptec, анонсировала долгожданное продолжение линейки RAID-контроллеров! Объявлено о выпуске 6й серии: Adaptec RAID 6405, 6445 и 6805.
Контроллеры построены на базе чипа серии SRC 8x6G (dual core 600MHz PM8013) RoC (RAID-on-Chip). Все три новых контроллера имеют одинаковый функционал, а отличие только в портах: 6405 имеет 4 внутренних SAS порта, 6445 – 4 внутренних и 4 внешних, а 6805, как легко догадаться, – 8 внутренних портов. Для всех контроллеров вместо батарейки предлагается использовать флэш-память, защищаемую конденсаторами (Adaptec Flash Module 600 - AFM 600). Остальные характеристики:
512МБ кэш памяти (DDR2-667)
поддержка SAS 2.0 (6Gbps)
шина PCIe Gen2 x8
поддержка до 256 дисков SAS/SATA (при использовании экспандеров)
поддержка уровней RAID 0, 1, 1E, 5, 5EE, 6, 10, 50, 60 и JBOD
возможность использования Hybrid RAID (SSD + HDD)
Как и для прошлых серий, управление осуществляется через Adaptec Storage Manager – это может быть очень важно для тех, кто уже активно использует контроллеры Adaptec в своих серверах, но посматривали “на сторону” в поисках продуктов с поддержкой 6Gbps.
Про поддержку технологии maxCache в новых контроллерах у меня однозначного ответа пока нет – нужно будет отдельно уточнить.
Более подробная информация должна быть через несколько дней.
Последний рубеж взят – для x86 серверов IBM появился контроллер ServeRAID M5025. Теперь SAS 2.0 6Gbps можно использовать везде – и внутри сервера, и во внешних СХД, и в JBOD. Последний вариант и стал возможен благодаря этому контроллеру. Сами JBOD доступны с момента анонса DS3500: это EXP3512 и EXP3524, а теперь есть и RAID контроллер с внешними портами:
В комплекте, как и у младшего брата (M5015, у которого порты смотрят внутрь), есть батарейка. Кратко по характеристикам и возможностям:
Контроллер построен на базе чипа LSI SAS2108 (RAID on Chip)
512МБ кэш-памяти на борту
Поддерживается подключение до 240 дисков (до 9ти шасси с дисками на порт)
Можно создать до 64 томов (LUN)
Размер одного LUN ограничен 64ТБ
Одновременное использование SAS и SATA дисков поддерживается, но смешивать диски в одном массиве нельзя.
Стандартно поддерживается RAID 0, 1, 10, 5 и 50 (уровни 6 и 60 становятся доступны после покупки M5000 Advanced Feature Key)
ServeRAID M5025 это фактически копия LSI MegaRAID SAS 9280-8e, так что остальную информацию можно посмотреть на страничке оригинала.
В блоге у Robin Harris углядел ссылку на очень интересную статью за авторством Julian Turner о влиянии вибраций на производительность жестких дисков. Все наверняка помнят разошедшийся по интернету ролик, где было отчетливо показано, как обычным криком можно изменить производительность дисковой системы SUN. Джулиан же провел более аккуратные с научной точки зрения тесты и результаты действительно впечатляют – максимальное наблюдаемое различие в производительности операций случайного чтения достигает 246% (!), а операций записи – до 88% (при наличии естественных вибраций и их максимальном гашении) . Кроме того, не нужно забывать что увеличение латентности (которое как раз и наблюдается при наличии вибраций), является одной из причин “вылета” дисков из RAID-массивов. Использование дисков 2.5” может существенно снизить эффект, а уж про SSD и говорить не нужно – им вообще все равно.
IBM анонсировали новый RAID контроллер, предназначенный специально для SSD. В отличие от остальных, представленных сейчас в портфеле IBM контроллеров, этот сделан не компанией LSI, а совместно с PMC-Sierra. Так как ServeRAID B5015 предназначен исключительно для SSD, то и выбор уровней RAID довольно скромный – только RAID1 и RAID5, создать можно до 4х логических дисков (LUN) на контроллер. Максимум можно подключить до 8ми дисков SAS 2.0 6Gb/s (замечательно укладывается в концепцию exFlash для серверов IBM x3850X5/x3950X5). Сердце контроллера – три ядра MIPS с поддержкой многопоточности. В стеке maxRAID активно используется эта самая многопоточность для увеличения производительности по сравнению с имеющимися на рынке решениями. Кэша нет, а следовательно нет и необходимости в батарейке.
Adaptec буквально вот только что перешел в руки PMC-Sierra (фактически поглощение закончится ближе к концу второго квартала). А тем временем извечный конкурент - LSI анонсировал выпуск целого ряда опциональных дополнений к своим контроллерам.
В первую очередь необходимо отметить CacheCade – аналог нашумевшего Adaptec MaxIQ. Являясь ключиком активации, CacheCade позволяет использовать SSD диски (до 32шт и суммарным объемом до 512ГБ) для хранения наиболее часто используемых данных. У продукта нет привязки к SSD (есть список протестированных дисков) и можно выбрать тот носитель, который доступен или более привлекателен по цене (конечно эффект CacheCade будет зависеть от производительности SSD). На текущий момент CacheCade поддерживается на контроллерах MegaRAID 9260-4i, 9260-8i, 9280-4i4e. Все остальные новые опции (на момент выпуска) также доступны только для этих контроллеров.
Второй продукт, также направленный на увеличение производительности – FastPath. Он обеспечивает повышенную производительность контроллера при подключении SSD дисков. Обещано повышение производительности до 2.5 раз при операциях случайной записи на SSD и до 2х раз на операциях случайного чтения. Благодаря Fastpath контроллеры могут обеспечить до 150.000 операций ввода-вывода в секунду (IOPs). Как следствие, FastPath особенно рекомендуется тем, кто использует SSD для OLTP задач. На рисунке данные для RAID-0 из 8ми дисков Intel X25E на контроллере 9260-8i (при включенном кэше дисков):
Два других продукта помогут обеспечить лучшую защиту данных:
Recovery Software служит для создания мгновенных снимков. Здесь нет ничего нового – используется классический Copy-on-Write механизм. Поэтому увлекаться снапшотами на высоконагруженной системе не стоит – производительность будет деградировать. Интеграция с VVS упрощает поддержание консистентности данных приложений в снимках. Работа со сделанными снимками осуществляется через MSM, поддерживаются версии Windows 2003 и 2008. Можно создать до 8ми снимков на том и до 504х на контроллер. В случае необходимости можно вернуть состояние тома на момент любого сделанного ранее снимка (сделать это можно и через WebBIOS, что позволяет защитить загрузочный том).
SafeStore позволит использовать SED (Self-Encrypting Drives) диски, чтобы ограничить несанкционированный доступ к данным (очень сомневаюсь, что в ближайшее время это будет востребовано в России – в силу ограничений на ввоз). Данная технология уже некоторое время доступна в контроллерах 9260DE и 9280DE, а теперь ее можно приобрести и в виде опции для обычных версий этих контроллеров.
Заметка в блоге Adaptec про “full-stripe writes” - что это и почему это плохо? Если в двух словах (и вольном переводе), то контроллер может работать с массивами RAID5 (да и с RAID6 почти также) двумя способами:
Записываемые данные могут попадать в “страйп” на одном диске и записывается только этот измененный страйп, да еще и новый блок с контрольной суммой. Т.е. операция записи блока данных в одном страйпе раскладывается на такую последовательность действий: чтение старого страйпа, чтение контрольной суммы, изменение блока данных, изменение контрольной суммы, запись нового блока и новой контрольной суммы. Этим и объясняется почему RAID5 заметно медленнее чем, например, RAID10 на операциях записи.
Данные записываются потоком, т.е. сразу пишутся все страйпы на весь набор дисков. В этом случае контроллер “собирает” так называемый full stripe, считает контрольную сумму и все это записывает на диски. Такой способ, очевидно, работает гораздо быстрее, но только в том случае, когда запись идет последовательно.
Но так работает контроллер в том случае, когда есть уверенность, что контрольные суммы верны (т.е. массив полностью проинициализирован и контрольные суммы не содержат заведомо неверных значений). Но, если при создании массива указать опцию “Quick Init”, никакой полной инициализации не произойдет – будут изменены только метаданные с конфигурацией. Чтобы данные пользователя не пострадали при сбое одного из дисков, в этом случае контроллер обрабатывает операции записи несколько иначе: любая операция записи влечет за собой чтение всех страйпов, изменение нужного страйпа, расчет контрольной суммы, запись “full stripe” обратно на диски. Т.е. всегда пишем “full-stripe”, но недостающие данные сначала считываем с дисков. Таким образом, любая операция записи будет задействовать все диски в массиве. Скорость, при этом, конечно будет заметно ниже, но пока не будет проведена полная верификация такого массива, никакого улучшения ждать не следует.
Отдельно хочу отметить, что использованная здесь (да и во всех документах Adaptec) терминология немного не соответствуетпринятой в SNIA – Adaptec (да и многие другие, надо сказать) под словом “страйп” (stripe) подразумевают то, что в SNIA называют “стрип” (strip), т.е. тот блок, которым оперирует контроллер при работе с RAID-массивом:
А вот использованный выше термин “full stripe” как раз соответствует страйпу в терминологии SNIA. Размер страйпа по умолчанию (в текущих версиях контроллеров Adaptec) равен 256КБ, т.е. после Quick Init любая (абсолютно любая) операция записи на массиве RAID5 из 5ти дисков (как на картинке) потребует чтения 256KB*4=1MB с 4х дисков и записи 1.25МБ уже на все 5 дисков. Согласитесь, не очень это должно способствовать производительности. Мораль такова: не нужно использовать Quick Init. Лучше день подождать (выбрать опцию Clear), а потом за пять минут долететь!
LSI анонсировал две модели 6Gb/s SAS JBOD (ящики для жестких дисков), предназначенные для подключения непосредственно к SAS контроллерам LSI и 3Ware. Модель 630J имеет 12 отсеков для дисков 3.5’’, а модель 620J – 24 отсека для 2.5’’ дисков. Оба варианта поддерживают 6Gb/s SAS (используется экспандер LSI SAS2x36), имеют стандартную высоту 2U, оснащены двумя блоками питания (система охлаждения находится в блоках питания, поэтому она также дублирована), в базе идет один ESM модуль, но можно установить и второй для обеспечения отказоустойчивости. Поддерживаются диски SAS или SATA (правда пока не очень понятно, будут ли доступны отдельно мультиплексоры для подключения SATA дисков в конфигурации с двумя ESM).
Каждый ESM модуль имеет по два SFF-8088 порта для подключения к хостам и один порт для каскадирования. Последовательное подключение JBOD позволит обеспечить необходимый запас для дальнейшего расширения:
Целевая аудитория – все, кто еще “не созрел” материально на внешнюю дисковую систему, либо те, кому достаточно отказоустойчивости, которую обеспечивает DAS, а гораздо более важна производительность системы.
Очень часто задают вопрос о том, как правильно выбрать stripe-size для того или иного массива. Как посчитать, а что будет если на массиве и SQL, и файловый сервер. А если SQL работает с дисками блоками по 8КБ, а RAID-контроллер не позволяет задать такой страйп, то наверное все теперь будет работать неоптимально и вообще наверное нужно искать такой контроллер, где stripe в 8КБ можно задать? На самом деле, все это не совсем так. То что какое-то конкретное приложение общается с дисками блоками по ххКБ вовсе не означает, что именно такой stipe-size будет оптимальным. Поэтому практически всегда на вопрос “как настроить, чтобы было лучше”, следует простой ответ: “оставьте то значение, которое предлагается по умолчанию”. Разработчики прошивки тратят много времени на оптимизацию кода прошивки, тратят много сил на обеспечение высокой производительности. Но все эти оптимизации наилучшим образом работают как раз на выбранных в качестве “default” значениях. До недавнего момента я все это говорил, ссылаясь исключительно на свое понимание вопроса, но на днях представитель Adaptec в своем блоге разместил точно такой же совет:
While there is credibility in doing the maths and trying to match the stripe size to the OS/application requirements, the reality is that the defaults will “normally” walk all over specifying a particular size. Why? Because our engineers spend a lot of time in making the defaults work best. We aim to make an out-of-the-box experience for the majority of users, and put a lot of effort into making the product work without a user having to be a rocket scientist to use it.
Зачем же производитель контроллеров дает выбор? Конечно, в ряде случаев можно получить дополнительные проценты (хотя обычно все-таки доли процентов) производительности, тщательно проанализировав характер нагрузки и выбрав значение, которое характерно именно для нее. Особенно это будет заметно, если размер блоков, которыми приложение общается с дисками, будет больше, чем stripe по умолчанию, а нагрузка создается преимущественно случайным обращением. Но такая ситуация возникает довольно редко, поэтому если никакие экстраординарные приложения использовать не предполагается, отдайтесь на волю разработчиков и пусть они, зная свой продукт изнутри, выберут для Вас правильные настройки.
P.S. Здесь речь идет о внутренних RAID-контроллерах. В “больших” системах есть свои особенности, связанные с работой кэша, и там оптимизация настроек может дать более заметный эффект.
Несколько дней назад (по большей части от любопытства) занимался реанимацией IBM DS4500. На всякий случай – с 2003 до 2006го года это была старшая система класса midrange у IBM. Потом на смену ей пришла DS4800, а с год назад и DS5100/DS5300, а пациент все работал и работал на благо … ну наверняка на чьё-то благо он все-таки работал. Только вот в какой-то момент ему стало тошно от такой жизни и решил он уйти на покой вместе со всеми данными. Сказал, что и дисков он своих знать не хочет, и с контроллерами у него не все ладно (да на всякий случай от одного сразу и открестился). И пришлось вокруг старичка попрыгать разве что не с бубном. По счастью, завести эту DS4500 удалось (конечно не без какой-то там матери, но главное при помощи девственно чистого файберного диска, лежавшего в загашнике). После “оживления” оказалось, что и контроллеры оба замечательно себя ощущают, и диски все живы, и даже данные оказались на своих местах. Но повозиться пришлось изрядно, а одна из основных причин состояла на мой взгляд в том, что прошивка на системе стояла чуть ли не та, с которой она вышла с завода. Сама по себе, возникшая проблема со старой прошивкой связана скорее всего не была, но вот будь она (прошивка) поновее, решение проблем потребовало бы в несколько раз меньше времени. Поэтому решил я дать несколько рекомендаций для тех, кто администрирует различные системы хранения:
Как правило, производитель рекомендует определенную версию прошивки для каждой системы (разумеется, со временем рекомендуемая версия меняется). Не стоит пренебрегать этим! Даже если проблем с системой нет, раз в пол-года проверяйте актуальные рекомендации и просматривайте список изменений. Даже если Вы не будете обновлять систему, Вы хотя бы будете знать какие проблемы были исправлены (вполне возможно что Вы уже с этими проблемами сталкивались, но не соотнесли их с СХД) – предупрежден, значит вооружен!
Самую последнюю прошивку, которая вышла “вот только вчера ночью”, устанавливать можно лишь в том случае, когда в системе есть серьезные проблемы, которые мешают ее нормальной эксплуатации! Прошивать “продуктив”, чтобы проверить “ту самую фишку”, которую только что анонсировали, не стоит – проблемы, которые могут возникнуть, сильно омрачат Вашу радость от мизерных улучшение. Если все-таки нужны новые возможности, то оптимальный путь – дождаться следующего обновления и, если не было найдено критических ошибок, доведите версию ПО до предыдущей.
Убедитесь, что фоновые процедуры проверки работают – в противном случае можете оказаться лицом к лицу с “вылетевшим” вторым (третьим) диском при перестроении массива. Чем это грозит наверное можно даже и не упоминать.
Регулярно проверяйте состояние батарей, защищающих кэш. Заранее озаботьтесь заказом новых. Помните, что при выходе батареи из строя, большинство СХД отключают кэш записи. После этого производительность может снизиться в нескольких раз. Конечно есть ненулевой шанс найти батарейку “живьем” в Москве или другом городе, но если система Ваша не новая (а тем более, если она уже снята с производства), батарейка эта наверняка провалялась на складе не один год. Так что нашли-то Вы ее “живьем”, а вот по факту она окажется “трупом”. Лучше прождать два-три месяца (в наших реалиях), но получить батарею, которая прослужит хотя бы пару лет.
Следите за состоянием массива даже если он находится на вторых (третьих или четвертых) ролях. Потому как по закону подлости на нем обязательно окажутся данные, которые есть в единственном экземпляре (“вот только вчера записали, а сегодня хотели бэкап сделать”) и которые ни в коем случае нельзя потерять. Только вот массив-то уже месяц был в критическом состоянии, а сегодня его совсем медным тазом прикрыло.
Ну и два главных совета:
Постарайтесь, чтобы слова “О, а у нас оказывается есть СХД!” звучали не только тогда, когда эта СХД сломалась!
Если есть финансовая возможность продлевать сервисное обслуживание, то этим Вы существенно облегчите себе жизнь! А если такой возможности вроде бы и нет, то постарайтесь аргументировать для людей, выделяющих финансы, необходимость этого продления – в случае возникновения проблем в системе без сервиса, решать эти проблемы придется скорее всего Вам самому.
Я уже писал про выход новой прошивки для систем Xyratex 5412/6412 и уже несколько раз возникали вопросы, как же нужно прошивать. Так что сегодня огромный пост будет про, на мой взгляд, самый большой недостаток этих дисковых систем – а именно про процедуру обновления firmware. Почему недостаток? А потому как процедура эта многоступенчатая, требует внимательности и осторожности. А, помимо прочего, требует еще и остановки системы (а, как следствие и всех приложений, которые с ней работают). Конечно, обновление прошивок дисков и в других системах потребует прервать ввод-вывод, но обычно все-таки действий нужно делать меньше. Итак, если Вам нужно обновить прошивку, то запланируйте downtime заранее. Если обновлять будете еще и прошивки на дисках, то учтите, что время простоя заметно возрастет – диски обновляются по-одному и если их 60 штук, то времени уйдет порядком. Что нам потребуется?
Ноутбук или ПК, с которого и будем все обновлять. Обязательное условие – наличие последовательного порта! Стандартный кабель подключается к 9-пиновому разъему, возможно потребуется переходник.
Кабель для последовательного порта, который скорее всего был в комплекте поставки (хотя это зависит от того, как была куплена система). Номер для заказа: RS-CAB-2M-RS232-USB.
Программа для работы в терминале (либо стандартный HyperTerminal, либо что-то еще с поддержкой протокола 1K X-Modem для передачи файлов).
Ну и конечно, необходимо иметь возможность подключиться к системе также и через локальную сеть.
Всего существует 5(!) различных прошивок (указаны в том порядке, в котором нужно обновлять):
прошивка модуля Disk I/O (это тот, который установлен в полках расширения)
boot PROM контроллера
прошивка самого контроллера RAID
прошивка StorView (система управления)
прошивка жестких дисков
Порядок обновления важен и рекомендуется его соблюдать чтобы избежать лишних и ненужных проблем.
Подготовили все необходимое. Сделали очередную резервную копию. Выключили серверы (или отмонтировали на серверах тома, находящиеся на дисковой системе). И только после этого начинаем. Первым делом убеждаемся, что система работает нормально, нет ни “вылетевших” дисков, массивы не находятся в состоянии перестроения и не происходят никакие другие чудеса. Затем следует определиться с тем, что нужно обновлять, а что – нет. Если кроме контроллерного модуля ничего нет, то прошивку Disk I/O пропускаем так как их физически нет. Текущую версию boot PROM можно увидеть в StorView, нажав мышкой на любой из контролеров:
Нажав в этом же окне на кнопку DIAGNOSTICS DUMP (откроется текстовый файл), можно узнать версии Disk I/O модуля (если он все-таки есть) и прошивок дисков:
Версию StorView можно узнать, нажав на кнопку ABOUT в правой верхней части основного окна (впрочем, версию StorView все равно обновлять придется практически наверняка):
Все полученные данные о версиях нужно сравнить с тем, что указано в сопроводительном файле к новому релизу прошивки. И вот уже после этого можно приступать к самому обновлению:
1. Прошивка модуля Disk I/O.
Если система не имеет модулей расширения (или их прошивки обновлять не требуется), то переходим к следующему пункту. Если система одноконтроллерная, то задача упрощается и мы сразу приступаем к прошивке: заходим в утилиту управления (StorView) через любой браузер (с отключенной блокировкой всплывающих окон) на адрес http://ip-address:9292/ (ip-address это очевидно адрес нашего единственного контроллера). Нажимаем на иконку Controller 0&1:
В открывшемся окне нажимаем кнопку UPDATE EXPANSION F/W.
Загружаем файл, ждем завершения. Первый этап закончен.
Если же система двухконтроллерная, то действий потребуется больше: необходимо сначала физически извлечь из системы один из RAID-контроллеров (из “головной” полки) – действуем, как было описано выше, но вместо UPDATE EXPANSION, делаем SHUTDOWN одному из контроллеров, а затем физически его извлекаем. После этого выполнить процедуру прошивки (как описано выше). Выключаем “головной” модуль, устанавливаем обратно вытащенный контроллер, а второй извлекаем. Включаем систему и повторяем процедуру обновления. Обратите внимание, что не нужно ничего вытаскивать из модулей расширения и выключать их также не нужно! Важно: прошивка занимает время, но статус ее через web-интерфейс отследить нельзя – только по индикаторам на системе. Так что лучше подождать и никуда не торопиться.
2. Прошивка boot PROM контроллера.
Вот здесь нам понадобится подключение к последовательному порту. На счастье boot PROM обновляется не так часто. Для двухконтроллерных систем, как и прежде, потребуется извлечь один из контроллеров, так что этот этап можно совместить с первым (чтобы два раза не дергать контроллеры). Оставив один контроллер, подключаемся к нему через терминальную программу. Стандартные установки порта 115200-8N1. Включаем систему, и несколько раз нажимаем на Enter (до того, как что-то появится на экране), чтобы попасть в “Monitor” (специальная утилита, которая загружается еще до Firmware контроллера). Еще раз проверить версию boot PROM можно, набрав команду ver (ниже, кстати, будет указана и модель контроллера чтобы не ошибиться):
Убедившись, что версию надо обновить, набираем команду dp и отправляем файл с прошивкой по протоколу 1K X-Modem. Подтверждаем свое желание обновить прошивку и ждем завершения. Контроллер автоматически перезагрузится. Можно снова зайти в Monitor и проверить, что прошивка обновилась:
Как видим все получилось, поэтому выключаем систему, вытаскиваем “прошитый” контроллер и устанавливаем второй. Повторяем уже проделанную процедуру.
3. Прошивка контроллера RAID.
Неприятные процедуры практически закончились. Теперь проверяем, что оба контроллера установлены и все кабели (к дисковым полкам) подключены – их отключать и не нужно было, но лучше бы проверить. Включаем систему и после этого заходим в StorView (через барузер). Проверяем, что все компоненты определились и ошибок нет. Нажимаем на иконку Controller 0&1, а там на кнопку UPDATE CONTROLLER F/W, отправляем файл с прошивкой и ждем около трех минут. За это время оба контроллера будут прошиты. Проверить успешность процедуры можно еще раз нажав на Controller 0&1 и посмотрев версию.
4. Прошивка StorView
Находясь в StorView, нажимаем на кнопку About (вверху справа):
В открывшемся окне нажимаем кнопку UPDATE, указываем файл прошивки и пароль для входа в StorView. Процедура длится примерно минуту. В некоторых обновлениях может присутствовать и новый “boot code” для StorView – его также нужно обновить. Для этого используется специальная утилита (идет вместе с прошивкой) - eSV_AutoUpdate_xxx.exe Запустив ее, указываем IP-адрес контроллера и прошивку, также ставим галочку “reboot when completed”:
После сообщения об успешной прошивке можно переходить к прошивке StorView на втором контроллере – вновь подключаемся по IP (уже к другому контроллеру) и повторяем все действия.
5. Прошивка жестких дисков.
И на сладкое осталась не самое приятное и, пожалуй, самое опасное – прошивка жестких дисков. Для этого нам опять потребуется доступ через последовательный порт. Для двухконтроллерной системы второй контроллер необходимо отключить (можно не вытаскивать, а просто сказать ему SHUTDOWN в окне Controller 0&1). После этого, привычным жестом подключаемся через терминал. Нажимаем Ctrl-E, чтобы вызвать меню:
Далее двигаемся по меню: “2” - Diagnostics, “2” - Online Diagnostics, “2” - Drive Maintenance, “1” - Download Drive Firmware to Buffer. Через 1K X-Modem отправляем прошивку и затем нажимаем “3” - Program and Save Drive Firmware. После этого можно выбрать, какие именно диски надо обновить (все поддерживаемые, все поддерживаемые из незадействованных и hot-spare, все поддерживаемые с отличной от загруженной прошивкой). После этого потребуется нажать “Y” чтобы подтвердить свою уверенность. Остается ждать успешного завершения. Процедура не слишком быстрая, поэтому терпение потребуется. Выключаем “головную” полку и включаем ее снова - чтобы ожил отключенный на начальном этапе контроллер.
Все! После этого остается зайти в StorView по IP и проверить что все запустилось. Если все удалось, то нажимаем Controller 0&1 и там нажимаем на кнопки CLEAR LOGS и SYNCHRONIZE TIME. Затем на основном окне нажимаем Logical Drive Statistics:
И там нажимаем кнопку CLEAR.
Вот теперь действительно все обновили! Можно подключать серверы обратно и работать.
Процедура, как я и обещал, длинная и непростая. Но если варианта “свалить” работу на кого-то еще нет, то придется делать, а я постарался все описать максимально подробно.
Я, когда весной прошлого года узнал о том что компания 3Ware перешла в руки LSI, считал что на этом (как это часто случалось при подобных поглощениях) история контроллеров 3Ware благополучно закончится, а LSI просто задействует часть их разработок в своих продуктах. Однако, каюсь, ошибался - LSI с толком использовали приобретенные активы для развития своего канального бизнеса. В качестве подтверждения того что “никто не забыт и ничто не забыто”, вчера были анонсированы два новых RAID контроллера с поддержкой SAS 6Gbps – 3Ware SAS 9740-4i и 9750-8i.
Как несложно догадаться, отличия только в числе портов (4 и 8, соответственно). Оба контроллера построены на базе чипа LSISAS2108 ROC, имеют интерфейс x8 PCI-Express 2.0, оснащены 512МБ кэш-памяти и поддерживают до 96 дисков SAS или SATA через экспандеры. Управление и настройка традиционно осуществляется через привычную всем пользователям контроллеров 3Ware утилиту 3DM2. RAID стек также остался без изменений, что безусловно является плюсом для приверженцев контроллеров 3Ware (среди которых немалую долю составляют число пользователи Linux). Благодаря технологии StreamFusion(TM)+ достигается высокая производительность на потоковых операциях чтения/записи (контроллеры способны обеспечить производительность до 2.5GB/s на последовательном чтении и до 1.1GB/s при последовательной записи).
Глупый вопрос, не правда ли? Особенно глупо звучит, если Вы вдруг пропустили начало 90х годов прошлого века в России. Зато сейчас заканчивается первое десятилетие уже этого века, а все чаще приходится слышать не менее странную фразу: “зачем бэкап делать, если я уже RAID настроил?”. И звучит это, к сожалению, чаще всего не в момент создания системы, а уже в тот момент, когда данные надо спасать, причем спасать далеко не традиционными способами. И чем дороже был куплен RAID-контроллер, тем больше возмущение – “Я потратил такие деньги на контроллер, я разве похож на Рокфеллера, чтобы еще и резервную копию делать?! Все пропало! Производители сговорились! Нет справедливости на свете! Ведь я купил контроллер как раз для того, чтобы защитить свои данные!” Как Вы понимаете, речь идет главным образом о “домашних” пользователях, но иногда и в малом бизнесе наблюдаются подобные проблемы.
И возмущение это могло бы быть справедливым, если бы только хоть один производитель RAID-контроллеров позиционировал свой продукт как замену резервному копированию. Так для чего же тогда нужен RAID? Может ли он обеспечить защиту данных? Ответ, как это обычно и бывает, не так однозначен: может, но только в некоторых случаях. В каких? Очень просто - RAID (кроме RAID-0) обеспечит доступность данных при выходе из строя одного или более (например, двух в случае RAID-6) дисков. Вот собственно и вся защита, которую теоретически может Вам обеспечить аппаратный или программный RAID. Не больше! Обратите внимание на слово “доступность” – именно это главная задача, т.е. целю является не защита данных вообще, а минимизация возможных простоев. А могут ли данные на RAID-массиве “пропасть”? Конечно могут! И вариантов здесь очень много, вот лишь несколько примеров:
Программная ошибка - самый простой случай и никак не зависит от наличия RAID.
Ошибка пользователя – не менее редкий (а скорее более распространенный) вариант.
Поломка сразу двух дисков в RAID-5 (либо трех в RAID-6). Скажете, что это маловероятно? Вовсе нет – если используются диски большого объема, то вероятность повторного сбоя во время перестроения (rebuild) массива при выходе одного из дисков заметно возрастает. Кроме того, возможна банальная проблема с блоком питания, который просто “убьет” электронику в нескольких дисках.
“Накопившиеся” логические ошибки на массиве. Откуда они берутся? На аппаратных RAID-контроллерах обычно есть кэш, который может значительно увеличить производительность дисковой операций записи. Но если кэш на запись никак не защищен, то неожиданная перезагрузка системы приведет потере данных в кэше контроллера. Если эта перезагрузка произошла, когда данные просто “ждали” в кэше, то будет ошибка на уровне файловой системы. А вот если в момент перезагрузки данные из кэша уже записывались на диски, то часть данных может оказаться записанными, а часть – нет. И теперь уже ошибки есть не только на уровне файловой системы, но и на уровне самого RAID-массива, так как неизвестно какая часть страйпа записана, а какая –нет. Для “отлова” таких ошибок большинство производителей предлагают соответствующие процедуры (consistency check), но кто ими пользуется пока гром не грянул? Защитить себя от этих проблем можно и батарейкой (BBU), конденсаторами с флэш-памятью или отключением кэша на запись. Но первое стоит денег, а второе - производительности.
Кэш есть не только на контроллере, но и на самих дисках. И операции записи кэшируются и на самих дисках. Всегда рекомендуется этот кэш выключать, но для SATA дисков и слабеньких контроллеров это радикально снижает производительность дисковой подсистемы. И те, кто не желает получить медленную систему все-таки оставляют этот кэш включенным. Что может случиться? Правильно, как и несколькими строками выше, перезагрузка может повлечь за собой потерю данных в кэше. И даже если контроллер думает, что с массивом все нормально, но на самом диске данные будут записаны совсем не те, которые нужны. И если этот сбой произошел на блоке с четностью, то до тех пор пока с массивом все нормально, данные будут доступны, а как только этот блок будет использован для восстановления (после сбоя совсем другого диска), в восстановленных данных будет “мусор”.
Контроллер взаимодействует с дисками, которые могут “отвечать” на команды контроллера с различными задержками (например, когда диск пытается сделать remap сбойного сектора). И контроллер может не дождаться ответа и отправит диск “на покой”. А что будет если это уже второй диск в RAID5? Правильно – данным можно сказать “прощай”. Да, конечно, диски из списков совместимости такими проблемами страдают крайне редко, но вот часто ли домашний пользователь смотрит на эти пресловутые списки? К сожалению нет, гораздо чаще голосование происходит либо рублем, либо в пользу “любимой” марки.
Выше я перечислил только самые распространенные случаи, все это может накладываться друг на друга и число потенциальных проблем вырастает как снежный ком. Если в момент какого-то из сбоев происходит еще и “рисковая” операция с массивом (например добавление диска в массив), то вероятность успешного восстановления данных “своими руками” (я уже даже не говорю про средства самого контроллера) стремительно приближается к нулю. Что мы, увы, очень часто наблюдаем (правда со стороны).
Так может быть, скажете Вы, RAID контроллеры это “зло” и средство для обогащения жадных производителей? Столько ужасов рассказано, может быть RAID дома и не нужен вовсе? Когда же имеет смысл его использовать?
Если нужно повысить скорость работы дисковой подсистемы (когда производительности одного диска мало). Если хобби это обработка видео или “игры” с виртуальными машинами, то почему бы и нет?
Компьютер – часть домашнего офиса и там хранится коммерчески важная информация. Вам ведь нужно обеспечить защиту данных до того, как будет сделана резервная копия.
Жалко времени на переустановку системы в случае выхода из строя диска. Вполне логично, особенно если компьютер это не полигон для испытаний и еженедельная переустановка Windows не входит в воскресное расписание.
Хранятся большие объемы данных в оперативном доступе и нет никакого желания восстанавливать их в случае сбоя диска.
О чем же нужно помнить, если решили упростить себе жизнь, используя RAID?
Использование любого RAID, установка BBU, отключение кэшей, регулярные проверки – ничто не гарантирует сохранность данных, если нет проверенной резервной копии.
Копии важных данных должны храниться на разных носителях и очень желательно, чтобы один из этих носителей не был бы доступен для записи.
А ниже несколько рекомендаций на случай, если все-таки хочется наплевать на все то, что было сказано выше, и сделать по-своему:
Создавая RAID-массив, записывайте все настройки (порядок дисков, размер страйпа и т.п.). Записывайте даже если Вы просто приняли все предлагаемые значения. Фактическое значение этого самого “default” для разных версий прошивки (firmware) аппаратного контроллера может отличаться. Разумеется не нужно хранить эти данные в текстовом файле на самом массиве – не пожалейте листа бумаги.
Поддерживайте актуальную версию прошивок и драйверов. Хотя и не нужно бросаться грудью на амбразуры и устанавливать новую прошивку в день ее выхода – если у Вас сейчас нет проблем, подождите с недельку-другую, может быть именно с ней возникнут проблемы и она будет вскоре заменена.
Используйте все доступные средства мониторинга. Если о случившемся сбое Вы узнали не из сообщения об ошибке в почте, а из того что система уже не загружается, зачастую уже поздно бывает что-то спасать.
Делайте регулярную проверку целостности данных.
Сделайте копию хотя бы самых-самых важных данных, например на DVD диски.
Если планируете что-то изменить в конфигурации массива (добавить диски, изменить уровень RAID и т.п.), перечитайте еще раз пункт №5 (а лучше все это сообщение). Если изменение прошло успешно, вспомните про пункт №1 и измените соответствующие записи.
Для аппаратных контроллеров диски выбирайте не по цене или общему впечатлению о бренде, а из списков совместимости для данного контроллера.
Если что-то сломалось, прежде всего скопируйте самые важные данные, а уже потом занимайтесь самолечением.
Если сломалось все так, что данные уже недоступны, не делайте резких движений и обратитесь к профессионалам. Найти таковых не представляет особенных проблем – даже если Вы находитесь вдали от двух столиц, общение можно свести к пересылке по почте и телефонному общению. Поверьте, почтовые затраты померкнут на фоне стоимости работ по восстановлению. Если есть возможность, сделайте посекторную копию всех дисков и экспериментируйте уже “на кошках”.
Все это конечно не оградит Вас от потери данных, но поможет заметно снизить риск этих потерь и вполне возможно сделает чуть ниже стоимость работ по восстановлению (если все-таки час “Х” настанет). Еще раз: будьте готовы к тому, что для восстановления данных нужно будет обратиться в специализированные организации. И не удивляйтесь когда стоимость работ окажется в несколько раз выше цены дисков и контроллера вместе взятых. Если же такие траты Вам не по плечу, то задумайтесь еще раз о резервном копировании тех данных, которые не хотите терять. И мойте руки с мылом, а в чай кладите сахар.
Наболело! Чуть ли не каждый день вижу вопросы такого плана: “В сервер можно поставить 16 (24) жестких диска, а SAS RAID контроллер у меня только 8-ми (или того хуже 4х) портовый! Что мне делать? Это наверное ошибка в конфигурации?!”. Ну что на это можно сказать? Может быть это конечно и ошибка, но скорее всего нет. Как же так? А все очень просто: SAS это протокол последовательной передачи данных и поддерживающий коммутацию. Если Вам нужно к серверу подключить 7 рабочих станций, Вы же не ставите в сервер 7 сетевых карт, а используете коммутатор на 8 портов, который позволяет всем машинам получить доступ к серверу. Точно также и в данной ситуации: либо в самом корпусе (прямо на бэкплейне), либо в виде отдельной карты присутствует аналог этого самого коммутатора. Только в данном случае он называется SAS-экспандером и позволяет подключить к RAID контроллеру гораздо больше дисков, чем есть SAS линий на самом контроллере. Наиболее распространены экспандеры на базе чипов LSI: LSISASx28, LSISASx36 или LSISAS2x36 (для 6Gbps SAS). В частности, на бэкплейнах в корпусах Supermicro используются экспандеры именно LSI. Отдельные карты с экспандерами также существуют, например в России проще всего найти их среди продукции компании Chenbro.
На рисунке – возможная схема подключения с двумя RAID контроллерами для отказоустойчивости к дискам через экспандер. Правда, надо сказать что это довольно специфичная конфигурация, которую мы обычно наблюдаем во внешних дисковых системах, в серверах же используется более простая схема, в которой нет ни второго контроллера, ни второго экспандера.
Вот вроде бы и разобрались – для подключения 24х дисков вовсе не нужно 24 порта на контроллере, достаточно и 4х (так как обычно именно 4 SAS линии используется для соединения контроллера с экспандером). А используя контроллер с 4мя внутренними портами и 4мя внешними можно не только задействовать (при использовании экспандера все диски в сервере, но и обеспечить возможность дальнейшего увеличения дисковой подсистемы за счет добавления внешней дисковой полки (JBOD).
Но сразу возникает несколько новых вопросов: “А нужно ли использовать экспандер? Может быть он так замедляет работу, что от него надо отказаться? У меня целых 24 (а то и еще больше) диска подключено только по 4м линиям SAS – наверное это будет очень медленно?”.
Попробуем найти ответы. Начнем с конца: 4 SAS линии по 3Gbps дают в сумме 12Gbps, а это целых 1.5 Гига-байта в секунду. Можно ли реально достичь такой пропускной способности? В принципе можно, но (а) нужно помнить, что наверное с этим потоком нужно еще что-то делать, а не просто читать или писать и (б) дисков для этого потребуется (даже при благоприятном стечении обстоятельств) заметно больше десятка. А если учесть, что при типичной работе сервера запросы к дисковой подсистеме идут в значительной степени случайные, то полосы пропускания в 12Gbps оказывается вполне достаточно – можете проверить сами на любом своем сервере, запустив perfmon (под Windows) и посмотрев на трансфер с дисков во время работы. А что до возникновения дополнительных задержек при использовании экспандеров, то они конечно есть, но “поймать” (измерить) их Вам не удастся – настолько они малы по сравнению с задержками при обращении к жесткому диску. Есть и еще один аргумент, чтобы не бояться экспандеров – в RAID-контроллерах, где количество портов больше 8, зачастую это объясняется именно наличием интегрированного на плате экспандера – например Adaptec 51245, 51645, 52445. Так что по сути, делая выбор в пользу многопортового контроллера, Вы просто приобретаете SAS экспандер на одной плате с контроллером.
Итак, использование SAS экспандеров не только не противопоказано, а вполне оправдано в подавляющем большинстве случаев!
Вчера, в день анонсов, IBM объявил о доступности довольно простенького контроллера ServeRAID M1015. Это уже третья модель у IBM для 6Gbps SAS 2.0. Из возможностей – RAID1/0/10 и поддержка до 32х дисков SAS/SATA. После установки M1000 Advanced Feature Key появляются RAID5 и 50 и encryption. Контроллер построен на базе чипа LSI SAS2008 и, как я понимаю, не имеет прямого аналога в линейке LSI MegaRAID. Ни кэш-памяти, ни возможности поставить батарейку нет, так что применение довольно ограниченное, но как достойная замена BR10i вполне подойдет.
Заодно был выпущен и M5000 Advanced Feature Key для контроллеров M5014 и M5015 – после его установки появляется RAID 6 и 60, а также возможность использовать encryption.
Обновился также документ ServerRAID Adapter Quick Reference, в котором содержится информация по возможностям и совместимости контроллеров для серверов IBM System x.
