IBM HS22V – лезвие для виртуализации

9го февраля IBM анонсировал новое лезвие HS22V. Название недвусмысленно намекает на то, что прицелом является виртуализация. Действительно, основное отличие от HS22 (которые уже заняли основную нишу в блейдах IBM), состоит в наличии 18 (а не 12ти) слотов под память. А память является, как известно, наиболее востребованным компонентом при внедрении виртуализации серверов – процессорной мощности зачастую бывает много, а памяти почти всегда не хватает.

Вместо двух hot-swap дисков предлагается использовать пару фиксированных 1.8” 50GB SSD дисков (поддерживается RAID-0 и RAID-1). Желающие могут добавить аппаратный RAID с батарейкой (впрочем, не думаю, что для данного лезвия это будет хоть как-то востребовано). Также уже традиционно присутствует разъем для USB накопителя с предустановленной Vmware ESXi (3.5 или 4). Что касается плат расширения, то здесь все осталось без изменений по сравнению с HS22. Базовые модели лезвий используют процессоры X5570 и E5540, можно также заказывать вариант с процессорами E5506 (но массово он поставляться не будет).

Для виртуализации весьма удобно использовать Virtual Fabric Adapter, про который я уже писал. Для тех, кому актуально использование FibreChannel, но уже есть прицел на FCoE и/или 10Гбит также есть хорошее решение - Virtual Fabric Extension Module.

Начало отгрузок HS22V планируются на 16е марта. Кроме того, в интернет просочилось название нового лезвия на процессорах Nehalem EX  - HX5. Предполагается поддержка 4х процессоров на собственном чипсете eX5. Напомню, что текущую серию процессоров Xeon MP в лезвиях IBM не встретить – аргументом было повышенное энергопотребление и тепловыделение. А на Youtube давно уже можно найти совместный рассказ IBM и Intel о готовящемся чипсете и апдейте линейки 3850M2/3950M2.

Читать дальше ...

Xyratex – обновление прошивок

Я уже писал про выход новой прошивки для систем Xyratex 5412/6412 и уже несколько раз возникали вопросы, как же нужно прошивать. Так что сегодня огромный пост будет про, на мой взгляд, самый большой недостаток этих дисковых систем – а именно про процедуру обновления firmware. Почему недостаток? А потому как процедура эта многоступенчатая, требует внимательности и осторожности. А, помимо прочего, требует еще и остановки системы (а, как следствие и всех приложений, которые с ней работают). Конечно, обновление прошивок дисков и в других системах потребует прервать ввод-вывод, но обычно все-таки действий нужно делать меньше. Итак, если Вам нужно обновить прошивку, то запланируйте downtime заранее. Если обновлять будете еще и прошивки на дисках, то учтите, что время простоя заметно возрастет – диски обновляются по-одному и если их 60 штук, то времени уйдет порядком. Что нам потребуется?

1. Ноутбук или ПК, с которого и будем все обновлять. Обязательное условие – наличие последовательного порта! Стандартный кабель подключается к 9-пиновому разъему, возможно потребуется переходник.
2. Кабель для последовательного порта, который скорее всего был в комплекте поставки (хотя это зависит от того, как была куплена система). Номер для заказа: RS-CAB-2M-RS232-USB.
3. Программа для работы в терминале (либо стандартный HyperTerminal, либо что-то еще с поддержкой протокола 1K X-Modem для передачи файлов).
4. Ну и конечно, необходимо иметь возможность подключиться к системе также и через локальную сеть.

Всего существует 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.

Вот теперь действительно все обновили! Можно подключать серверы обратно и работать.

Процедура, как я и обещал, длинная и непростая. Но если варианта “свалить” работу на кого-то еще нет, то придется делать, а я постарался все описать максимально подробно.

Читать дальше ...

Новости от Adaptec

В свежей рассылке технической информации от Adaptec появилось несколько важных новостей на которые нужно обратить внимание.

Во-первых была пофиксена ошибка при работе RAID контроллеров 2 и 5 серии под операционной системой FreeBSD. Ошибка выглядела следующим образом:kernel: aacu0: COMMAND 0xfffffffe80245378 TIMEOUT AFTER XX SECONDS. Для устранения данной проблемы используйте прошивку b17547, сейчас она доступна в разделе http://www.adaptec.com/support/files/ , для её скачивания понадобиться авторизоваться
Password: CANDLE
Filename: 2045_fw_b17547.zip, 2405_fw_b17547.zip, 5085_fw_b17547.zip, 5405_fw_b17547.zip, 5405z_fw_b17547.zip, 5445_fw_b17547.zip, 5445z_fw_b17547.zip,5805_fw_b17547.zip, 5805z_fw_b17547.zip, 51245_fw_b17547.zip, 51645_fw_b17547.zip, 52445_fw_b17547.zip
Как можно понять имя файла выбираете то которое соответствует вашему контроллеру.

Во-вторых продолжена поддержка новых операционных систем Windows устройствами SCSI 160, драйвера под Windows 2008R2 и Windows 7 для таких устройств можно скачать с офф сайта. Эта новость особенно актуальная для пользователей ленточных накопителей.

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

Читать дальше ...

Вторая жизнь 3Ware

Я, когда весной прошлого года узнал о том что компания 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 при последовательной записи).

Читать дальше ...

Полезное чтиво про IBM DS4000/DS5000

IBM опубликовал сразу 4 драфта новых книжек про системы хранения среднего уровня (DS4000/DS5000), которые должны занять достойное место в подборке документации администраторов СХД:

• IBM Midrange System Storage Hardware Guide
• IBM Midrange System Storage Implementation and Best Practices Guide
• IBM Midrange System Storage Copy Services Guide
• VMware Implementation with IBM Midrange System Storage

По сравнению с тем, что уже можно было найти в “редбуках” ранее, собрана вместе информация по новым системам в линейке DS4000/DS5000 и подробно описаны все нововведения. Две последние работы довольно узко специализированы: в одной подробнейшим образом изложен механизм работы мгновенных снимков и клонирования (в т.ч. и между системами), а вторая посвящена виртуализации на базе VMware ESX/ESXi. В принципе, обе книги не содержат радикально новой информации (по крайней мере, я не увидел ничего, что не встречалось бы в выпущенной ранее документации), однако прочитать и держать под рукой эти материалы полезно. Тем же, кто впервые развертывает VMware на системах IBM DS4000/5000 читать просто необходимо – в соответствующей книге собран вместе обширный материал, который позволит гораздо лучше понять что и как делать. Не оставлен в стороне и вопрос выбора (и оптимизации) настроек дисковой системы для повышения производительности.

Наибольший же интерес, на мой взгляд, должны представлять первые две книги – изложенный материал позволяет гораздо лучше понять, как именно устроены дисковые системы IBM и как с ними нужно работать. Тем, кто впервые сталкивается с системами IBM, очень поможет описание термина “Storage Partitions”, который часто вызывает проблемы в понимании. Объясняется множество вопросов, которые могут возникнуть в процессе подбора конфигурации. Поэтому эти две книги полезны не только пользователям систем, но и пресейлам – правильно подобрать конфигурацию тоже бывает непросто. Отдельная глава посвящена RSM (Remote Support Manager), продукту который пока не слишком популярен на наших просторах, но ситуация должна постепенно меняться.

Администраторам будет интересно прочитать про процедуру обновления прошивок, конфигурацию коммутаторов и настройку СХД в связке с различными операционными системами (в т.ч. есть и пример настройки кластера Windows 2008 при загрузке с SAN). До недавнего момента в многочисленных книжках IBM встречалась рекомендация подключать контроллер A к одному коммутатору, а контроллер B – ко второму. Мне такая схема всегда казалась не очень правильной (хотя она и обеспечивала отказоустойчивость) так как при этой настройке, выход из строя коммутатора, обрыв кабеля от сервера к коммутатору или выход из строя адаптера в сервере гарантированно приводит к переносу LUN’а между контроллерами, что может вызвать проблемы производительности. Поэтому я всегда рекомендовал подключать каждый контроллер к каждому коммутатору и терпеливо объяснял свою позицию внимательным читателям документации. Сейчас же был приятно удивлен – теперь везде приводится рисунок с “правильным” подключением:

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

Можно найти и очень много подробных описаний по оптимизации настроек СХД для тех или иных приложений. Но отдельного упоминания заслуживает вопрос сайзинга, т.е. подбора конфигурации под имеющуюся (планируемую) нагрузку. Здесь и работа с монитором производительности в Storage Manager (Performance Monitor), и IBM Tivoli Storage Producivity Center for Disk. Детально объясняется работа с такой полезной утилитой для сайзинга как Disk Magic (впрочем, я не уверен что она доступна пользователям, но имеющие доступ на IBM Partnerworld могут ее оттуда скачать). Даже если доступа к утилите у Вас и нет, Вы можете собрать необходимые данные и отправить их интегратору, чтобы он провел для необходимый расчет и подобрал нужную конфигурацию, которая обеспечит должный “запас прочности”.

Так как упомянутые книги это пока только драфты, то читать их конечно нужно, но и следить за обновлениями тоже не помешает!

Читать дальше ...

Организационное…

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

Читать дальше ...

Еще один игрок на рынке NAS

Infortrend, как и обещал, официально анонсировал свой выход на рынок сетевых систем хранения данных (NAS). Для начала выпущены 3 модели. Все они поддерживают доступ по протоколам CIFS, NFS, HTTP, FTP и iSCSI; имеют весьма объемный список поддерживаемых ОС; на них можно включить компрессию данных на дисках; мгновенные снимки позволят упростить резервное копирование, а репликация защитит данные от потери в критических ситуациях. Разумеется, поддерживаются всевозможные уровни RAID (все, что умеют обычные их дисковые системы). Диски можно использовать SAS (300GB и 450GB) или SATA (1TB).

• 
  
  EonNAS 3200 – модель начального уровня, оснащена двумя 1Гбит сетевыми портами и имеет 4ГБ кэша. В базовом варианте вмещает в себя до 12ти дисков, а расширяться умеет до 60ти дисков (по 12 дисков в специальном модуле расширения).
  
  
  

• 
  
  EonNAS 5100N и 5100U – более функциональные системы “постарше”. Они даже в базе уже состоят из двух модулей – непосредственно “головы” и дискового модуля на 12 дисков. “Наружу” имеется 4 x 1Gbit сетевых порта, а для 5100U еще и два 8Gbit порта Fibre Channel, максимальный объем кэша составляет уже 12ГБ. Максимальное число дисков составляет уже 84. Помимо тех возможностей, которые есть в модели 3200, в системах 5100 также присутствует thin provisioning (выделение дискового пространства по мере реальной необходимости). Производительность системы можно повысить еще и за счет использования двух SSD дисков оъемом 32ГБ или 64ГБ. И, как уже написано выше, для 5100U можно использовать еще и FC для подключения серверов, что дает возможность строить самые разные решения на базе систем EonNAS.
  
  
  

Узнав о готовящемся анонсе я, признаться, опасался того что будет выпущена система с двумя контроллерами и “перегруженная” возможностями. А это сделает ее совершенно неинтересной из-за попыток прыгнуть выше головы и конкурировать с NetApp и т.п. Однако, все обошлось и получилась довольно типичная для Infortrend “боевая лошадка”.

Читать дальше ...

Общий доступ к дискам (Sanbolic Melio FS и другие)

С завидным постоянством вижу вот такого плана вопрос:

“Мы установили дисковую систему, создали один LUN, все настроили, подключили два сервера. На одном сервере файлы записываем, а на другом никаких изменений не видно. Да еще и ошибки какие-то странные. Что надо еще настраивать?”.

Причем, как это ни странно, технический уровень спрашивающих может быть очень разным, а вопрос один и тот же. А ведь, казалось бы, все очевидно: файловые системы (большинство), которые мы привыкли использовать (NTFS, EXT3, …) просто не умеют работать в таком “распределенном” режиме. Представьте, что на сервер А мы записали на диск файл, но каким образом об этом станет известно серверу B? Без специальной кластерной файловой системы, которая сообщит ему об этом – никак. И наиболее вероятным результатом (даже сравнительно короткого) такого “испытания” на обычной файловой системе будет полный ее крах. Поэтому даже и эксперименты проводить не стоит – работать не будет! А что тогда делать и нужно ли это вообще? В большинстве случаев (особенно если очень пристально посмотреть на задачу или заказчика :) ) такой функционал действительно оказывается ненужным и для совместного доступа к файлам достаточно использовать CIFS (в Windows) или NFS (в Linux). Но, тем не менее, существует и довольно много задач, где общий доступ к дисковому устройству если и не необходим, то очень важен. Как для более простой реализации, так и для лучшей производительности системы. Для того чтобы такой доступ обеспечить нам и  нужна будет кластерная файловая система. Существует их довольно много, подавляющее большинство ориентировано на Linux/Unix (RedHat GFS, IBM GPFS, Lustre, HP Plyserve и т.п.), но и Windows не остался в стороне (Sanbolic MelioFS, HP Polyserve, IBM GPFS). Исторически решения под Linux использовались для HPC кластеров (и ряда других приложений), а под Windows в основном для обработки медиа-контента. Сейчас дисбаланс уже не так заметен – Windows работает на всех фронтах. Кроме того, все активнее внедряются системы виртуализации на базе Hyper-V в Windows Server 2008 и 2008 R2. И, если у основного конкурента (VMware) кластерная файловая система уже есть (VMFS), то в случае с Hyper-V нужно либо обходиться без нее, либо использовать сторонние продукты. Но даже и в случае с VMware разделяемая файловая система может очень пригодиться – например при использовании совместно с бесплатным VMware Server можно размещать образы виртуальных машин на общем дисковом ресурсе, что значительно упрощает миграцию и в разы снижает время простоя при сбоях.

Сегодня более подробно я остановлюсь на решениях компании Sanbolic. Помимо кластерной файловой системы MelioFS, в портфель продуктов постепенно добавлялись и другие решения – это и система управления томами LaScala, и SILM, и AppCluster (о них немного ниже), а выбрать что же именно нужно купить, чтобы получить искомый результат, становилось все сложнее. И, если представители интегратора в большинстве случаев хорошо понимают что и для чего нужно, то объяснить клиенту, что ему нужна не одна лицензия за 2000$, но к ней еще нужно докупить две лицензии по 1500$, было в некоторых случаях сложно. В настоящее время ситуация существенно упростилась и предлагается всего 4 лицензии: Melio Virtualization, Melio Professional, Melio Enterprise и Melio Data Center. Благодаря этому выбор оптимального решения стал гораздо проще.

Все четыре продукта включают в себя (помимо кластерной файловой системы) систему управления томами (volume manager) LaScala. Поддержка страйпинга и конкатенации позволяет получить высокопроизводительный том необходимого объема. Также во все бандлы входит система SILM (Simple Information Lifecycle Manager), которая, на основе заданных пользователем политик, может перемещать файлы между различными системами хранения. Например, файлы, к которым не было обращения более 10 дней, будут перенесены на более медленную дисковую систему. Важно отметить, что поддерживается “смешанный” режим работы – данные могут располагаться не только на томах MelioFS, но и на любых других дисках (в том числе и локальных).

Melio Virtualization ориентирован на заказчиков, которые внедряют у себя Hyper-V или VMware Server, и позволяет получить всем серверам доступ к общей дисковой подсистеме (iSCSI или FC) для размещения на ней образов виртуальных машин. Благодаря поддержке технологий Quick и Live Migration, а также отсутствию ограничения на число серверов в кластере, актуальность данного решения фактически прямо пропорциональна числу физических серверов Hyper-V.

Второй, ориентированный на виртуализацию продукт - Melio Professional. Он предназначен для развертывания отказоустойчивого высокопроизводительного кластера системы динамической загрузки образов операционных систем на базе Citrix Provisioning Services. На общей файловой системе хранится как база данных, так и сами vDisk вместе с файлами кэшей записи. Нужно помнить, что данный бандл имеет ограничение на включение максимум двух узлов в кластер (а использовать меньше и смысла не имеет).

Два оставшиеся варианта лицензий уже не являются такими узкоспециализированными и предназначены для широкого круга заказчиков, чьи задачи не ограничиваются только виртуализацией. Melio Enterprise поддерживает совместную работу до 4х узлов в одном кластере и имеет ряд ограничений по сравнению с “топовой” версией Melio Data Center. В частности, нет поддержки зеркалирования (RAID1) и Quality of Service. Обе версии позволяют создавать высокопроизводительные кластеры файловых серверов, в том числе и с поддержкой балансировки нагрузки (NLB). Разумеется поддерживается DFS и ACL. Возможность динамического расширения файловой системы и томов позволяет избежать лишних остановок сервиса для обслуживания системы. По мере роста требований к файловым серверам можно добавлять как серверы, так и системы хранения в существующий кластер, увеличивая тем самым как суммарную емкость, так и производительность системы в целом:

Также в состав обоих пакетов входит AppCluster Manager – средство управления active-active кластерами MS SQL, когда соответствующие базы данных размещены на разделяемой файловой системе. Конечно, это решение не позволяет (в силу архитектуры MS SQL) построить аналог Oracle RAC, но дает возможность обеспечить минимальное время переключения между серверами в кластере в случае сбоя, а также балансировать нагрузку между физическими машинами:В варианте Data Center AppCluster работает совместно с QoS, чтобы позволяя критичным базам иметь приоритет при работе с дисковыми ресурсами.

Для тех же кто использует Hyper-V есть еще зачастую весьма веская причина использования Enterprise или Datacenter версий – технология Pass-through I/O увеличивает производительность дисковой подсистемы так как не требуется оповещение остальных машин в Windows Failover кластере об операциях записи в виртуальных машинах.

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

Читать дальше ...

Апдейты для дисковых систем Xyratex

Во первых строках хочу поздравить всех Вас с наступившим уже наконец Новым Годом и пожелать всевозможных успехов и конечно же достижения поставленных перед собой целей!

Праздники подходят к финалу и Xyratex выпустил долгожданную прошивку за номером 2.5.6 для систем E5412E, F5412E, F6412E и F5404E. “Долгожданную” – так как именно в ней появилась поддержка 2ТБ дисков (Hitachi HUA722020ALA330). И теперь можно получить до 120ТБ raw пространства на системах 5412 и 6412 и целых 192ТБ на системе F5404E. Причем, в последнем случае, это потребует только лишь в 8U в стандартной 19” стойке. Разумеется, помимо поддержки 2ТБ дисков в прошивку вошли различные исправления (в т.ч. более правильно стал работать интерфейс из под IE 8.0). Еще одно востребованное улучшение – за счет новой прошивки XR3A для дисков Seagate (ST3500320NS, ST3750330NS, ST31000340NS) повышена производительность.

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

Читать дальше ...

FCoE удобнее и компактнее

Строить FCoE уже давно можно – все для этого есть: и адаптеры в серверы, и коммутаторы. Наибольший интерес к FCoE можно ожидать при использовании Blade-решений, так как возможности по установке плат расширения зачастую ограничены. Но цена вопроса все еще довольно высока, особенно учитывая то, что для подключения дисковых систем в большинстве случаев требуется использовать не только 10Gbit коммутационные модули в шасси, но и FCoE коммутаторы с FC портами, либо строить отдельную FC инфраструктуру. Для того чтобы упростить ситуацию, IBM анонсировал для шасси BladeCenter H модули Virtual Fabric Extension. Этот модуль подключается через мид-плэйн к коммутатору BNT Virtual Fabric 10 Gb Switch и позволяет использовать FC порты без необходимости установки дополнительных FC HBA плат в сами лезвия:

В лезвия достаточно установить по одному двухпортовому CNA адаптеру Qlogic, а в шасси – различные по количествам вариации из 10Gb коммутаторов BNT и модулей Virtual Fabric Extension. В максимальной конфигурации поддерживается 2+2 модуля (как на рисунке выше); в минимальной - 1+1 (без отказоустойчивости и задействован только один порт на CNA); кроме того, возможен вариант, когда к двум 10Gb коммутаторам подключен только один модуль Virtual Fabric – это обеспечивает максимальное число внешних портов 10Гбит (16шт).

Virtual Fabric Extension Module может работать как в режиме Full Fabric, так и в режиме NPIV, что обеспечивает дополнительную гибкость конфигураций. Дополнительно хочется отметить, что все “высокоскоростные” прелести  доступны только в шасси BladeCenter H (или HT для телекома), поэтому именно это шасси и имеет смысл рассматривать если есть хоть малейшие перспективы для использования 10Gb.

Читать дальше ...

IBM SVC Entry Edition

Уже довольно давно IBM предлагает (и надо заметить небезуспешно) свою систему виртуализации СХД – SAN Volume Controller (SVC). Писать про SVC можно много, но сейчас не об этом. Так как внедрение системы виртуализации СХД это своего рода радикальное изменение в инфраструктуре (хотя оно и может быть реализовано практически полностью прозрачно), то решиться на этот шаг не всегда просто. Именно поэтому уже больше года, если не ошибаюсь, была выпущена версия “для неуверенных”, т.е. решение, которое имело ограниченный функционал, но зато гораздо более бюджетное. В отличие от старшего собрата Entry Edition лицензируется по числу жестких дисков которые входят в виртуализуемый объем. Ограничение на момент выпуска составляло не более 60 дисков для кластера SVC. С одной стороны, этого вполне достаточно, чтобы развернуться “в полный рост” с системой начального уровня и организовать репликацию на удаленную площадку, но любое сравнительно серьезное расширение требует перехода на полную версию SVC. Да, этот переход не требует покупки нового железа, но все равно “бьет” по карману.

С выпуском версии SVC 5.1 и нового поколения железной части (на базе серверов x3550M2) возможности Entry Edition существенным образом расширились – поддерживается уже до 250 дисков (а это вполне себе серьезная система получается). Но на этом приятные новости не закончились – теперь совершенно бесплатно доступна лицензия на FlashCopy! А это уже серьезное подспорье, например в развертывании системы резервного копирования, – в частности Exchange 2010 можно будет бэкапить только через VSS (а VSS, в свою очередь, замечательно интегрируется с FlashCopy посредством Tivoli Storage FlashCopy Manager). Единственное о чем следует помнить – не нужно перебарщивать с лицензиями на FlashCopy – они конечно в базе (с годом поддержки) бесплатны, но дополнительная поддержка стоит денег и, если известно, что снимки нужно делать не со всего объема, то на дальнейшей поддержке можно немного сэкономить.

Все эти изменения в SVC Entry Edition делают его приобретение весьма заманчивым. Особенно если в хозяйстве уже есть какая-то “старая” система хранения и хочется не только добавить еще одну систему, но и унифицировать управление.

Читать дальше ...

Вам чай с сахаром или руки с мылом помоете?

Глупый вопрос, не правда ли? Особенно глупо звучит, если Вы вдруг пропустили начало 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?

1. Использование любого RAID, установка BBU, отключение кэшей, регулярные проверки – ничто не гарантирует сохранность данных, если нет проверенной резервной копии.
2. Копии важных данных должны храниться на разных носителях и очень желательно, чтобы один из этих носителей не был бы доступен для записи.

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

1. Создавая RAID-массив, записывайте все настройки (порядок дисков, размер страйпа и т.п.). Записывайте даже если Вы просто приняли все предлагаемые значения. Фактическое значение этого самого “default” для разных версий прошивки (firmware) аппаратного контроллера может отличаться. Разумеется не нужно хранить эти данные в текстовом файле на самом массиве – не пожалейте листа бумаги.
2. Поддерживайте актуальную версию прошивок и драйверов. Хотя и не нужно бросаться грудью на амбразуры и устанавливать новую прошивку в день ее выхода – если у Вас сейчас нет проблем, подождите с недельку-другую, может быть именно с ней возникнут проблемы и она будет вскоре заменена.
3. Используйте все доступные средства мониторинга. Если о случившемся сбое Вы узнали не из сообщения об ошибке в почте, а из того что система уже не загружается, зачастую уже поздно бывает что-то спасать.
4. Делайте регулярную проверку целостности данных.
5. Сделайте копию хотя бы самых-самых важных данных, например на DVD диски.
6. Если планируете что-то изменить в конфигурации массива (добавить диски, изменить уровень RAID и т.п.), перечитайте еще раз пункт №5 (а лучше все это сообщение). Если изменение прошло успешно, вспомните про пункт №1 и измените соответствующие записи.
7. Для аппаратных контроллеров диски выбирайте не по цене или общему впечатлению о бренде, а из списков совместимости для данного контроллера.
8. Если что-то сломалось, прежде всего скопируйте самые важные данные, а уже потом занимайтесь самолечением.
9. Если сломалось все так, что данные уже недоступны, не делайте резких движений и обратитесь к профессионалам. Найти таковых не представляет особенных проблем – даже если Вы находитесь вдали от двух столиц, общение можно свести к пересылке по почте и телефонному общению. Поверьте, почтовые затраты померкнут на фоне стоимости работ по восстановлению. Если есть возможность, сделайте посекторную копию всех дисков и экспериментируйте уже “на кошках”.

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

Читать дальше ...