ScaleMP покоряет новые горизонты

Задача объединения нескольких серверов в один гораздо более мощный замечательно решается при помощи vSMP Foundation от компании ScaleMP – про это я некоторое время назад уже писал. Если вкратце, то используя стандартные x86 серверы, infiniband и гипервизор от ScaleMP можно получить сервер поддерживающий до 32х сокетов и до 4ТБ памяти. Интересно, что конфигурации машин, входящих в кластер могут отличаться – если процессорных ресурсов нужно не слишком много, то часть машин может быть с “быстрыми” процессорами, а остальные с минимальными возможными и предоставлять в качестве общего ресурса только оперативную память. Однако у vSMP Foundation есть и некоторые особенности, про которые необходимо помнить. Во-первых, установить на такой сервер можно далеко не всякую операционную систему – на текущий момент это может быть только Linux, причем для оптимальной производительности нужно либо пересобрать ядро, либо использовать вариант от ScaleMP (они есть в частности для RedHat). Во-вторых, vSMP предназначен именно для объединения ресурсов. То есть вместо двух (трех, четырех…) серверов мы получаем один, но более мощный, соответственно, выход из строя одной из машин вызовет остановку/перезагрузку всего комплекса. Кроме того, так как речь идет про объединение, то на один комплекс vSMP нельзя поставить несколько операционных систем (т.е. выделить полторы машины для одной задачи, а еще две с половиной для другой). Но последний пункт был верен только до недавнего момента! Буквально на днях была анонсирована технология VM-on-VM. Что это такое? Очень просто - фактически заявлено о начале поддержки виртуализации серверов на базе KVM и Xen в кластере vSMP Foundation. Это дает возможность существенно снизить цену “железной составляющей” на базе 4-8ми сокетных систем. А это, в свою очередь, позволит консолидировать (виртуализовать) более требовательные к ресурсам сервисы без использования дорогостоящего оборудования. Декларируется также упрощение управления, впрочем, здесь я не испытываю особенного энтузиазма – самим vSPM тоже нужно управлять, поэтому снижение затрат на управление будет не самым важным аргументом. По крайней мере не таким важным, как цена решения.

Но приятные новости этим не ограничиваются – параллельно была анонсирована и версия 3.0 vSMP Foundation. Основные нововведения касаются поддержки процессоров Nehalem-EX и Westmere-EP. Теперь можно использовать несколько infiniband HCA карт параллельно, причем нагрузка будет равномерно распределяться между ними. Для объединения 4х машин можно обойтись без коммутатора Infiniband – это позволяет существенно снизить начальные вложения. Существенно расширен список поддерживаемых адаптеров – это HBA от LSI и Emulex, кроме того, добавлена поддержка 10Гбит сетевых адаптеров Broadcom. В новой версии увеличены и “максимумы” кластера – теперь можно объединять до 128 серверов, каждый из которых может иметь до 128 процессоров (ядер или потоков); объем поддерживаемой оперативной памяти увеличен до 64ТБ. Версия 3.0 будет доступна заказчикам начиная с 14 июня.

Ссылки по теме:
Объединяй и властвуй!
ScaleMP

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

Глобальное пространство имен файлов (4/4)

Сегодня заключительная (четвертая) часть серии заметок про управление файловыми серверами. Речь пойдет уже не столько про глобальное пространство имен файлов, а про дополнительные возможности, возникающие в результате его внедрения.
Часть 1-ая
Часть 2-ая
Часть 3-я

Политики управления данными.

Основной плюс AutoVirt - это возможность не просто создать глобальное пространство имен, но и обеспечить управление неструктурированными данными на основе предопределенных администратором политик. 
Представьте, что Вам нужно перенести все файловые ресурсы с нескольких старых серверов на новый. А если все эти ресурсы активно используются? А если нужно сохранить ссылки на ресурсы неизменными, а DFS не используется? А если нужно не только перенести данные, но старые серверы вообще вывести из обслуживания, либо использовать для других нужд? Любое из этих "если" добавляет головную боль. Вот здесь преимущества от использования AutoVirt и глобальной системы имен файлов выходит на первый план! Нам достаточно добавить новую политику (Migration) через web-интерфейс, выбрать что и куда мы хотим перенести, задать время и подождать окончания процесса. Все! Больше ничего делать не нужно. Пользователи не заметят вообще ничего. Более того, если исходный файловый ресурс имеет громадный объем и сильно нагружен, мы можем задать предварительное копирование данных в удобный нам интервал времени (вероятно это будет ночь). В это время файлы будут постепенно копироваться на новый ресурс, тогда в момент фактической миграции потребуется скопировать только изменившиеся с момента предварительной синхронизации файлы и переключить пользователей на новый сервер (еще раз отмечу, что все это делается без участия администратора). Важно, что корректно будет произведена не только миграция самих файлов, но и всех прав доступа (ACL). Если необходимо осуществить миграцию настолько большого объема данных, что два стандартных Data Engine (про них подробнее написано во второй части) не справляются с поставленной задачей за приемлемое время, то достаточно просто добавить нужное количество серверов на время миграции (никаких дополнительных лицензий для этого не потребуется). Так как DataEngine работают независимо, то рост их числа практически линейно увеличит скорость миграции (если конечно сам файловый сервер справляется с такой нагрузкой).

Но миграцией возможности AutoVirt не ограничиваются - список политик включает в себя:

• Measure - это просто отчет о том как используется дисковое пространство (число файлов, их объем и т.п.). Позволяет оценить требования к ресурсам для дальнейших операций по миграции/репликации.
• Copy - копирование данных. Отличается от миграции тем, что не происходит переключение пользователей на новый ресурс. Зато можно отфильтровывать файлы по типу. Это довольно ограниченная по возможностям политика, так что если нужны дополнительные функции следует использовать Replication.
• Replication - пожалуй, самая "продвинутая" по возможностям опция. Именно она при миграции с DFS будет альтернативой использованию DFS-R.
  

  

  Несколько слов подробнее про каждый из типов репликации: 
  Клонирование "один источник - один клон" предназначено для обеспечения отказоустойчивости. Данные "мастера" реплицируются на удаленную площадку, а в случае сбоя происходит перенаправление клиентов на реплику. 
  Отношение "один источник - много клонов" удобно для организации с множеством филиалов, в каждым из которых необходимо обеспечить доступность однотипных материалов в режиме чтения. Это позволит сократить расходы и снизить загрузку каналов связи. В случае сбоя, запросы будут перенаправлены на ближайший к клиенту сервер.
  Если в организации много филиалов и стоит задача централизованно хранить данные, то замечательно подойдет третий вариант - "много источников - один клон". В случае сбоя на удаленной площадке, failover будет индивидуальным для каждого филиала (т.е. отсутствует влияние на остальных - они продолжат работу в обычном режиме).
  Во всех описанных вариантах, для восстановления после сбоя следует использовать миграцию, чтобы произвести обратную синхронизацию данных и осуществить переключение пользователей на исходный ресурс.

• И, наконец, последняя политика Deletion - удаляет все исходные данные после успешной миграции. Политика простая, но применяется крайне редко (ввиду очевидного риска).

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

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

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

А для тех, кто продолжает использовать в своей инфраструктуре Brocade StorageX (и имеет оплаченную поддержку), есть очень заманчивое предложение – до 30 июня 2010г. действует специальная акция со скидками при замене лицензий StorageX на AutoVirt.

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

Управлять СХД – просто!

Если используется одна система хранения, то управлять ей конечно несложно! 

А вот если их три или и того побольше? — Как осуществлять мониторинг систем, чтобы не допускать ситуации, когда нагрузка становится фактически предельной, а жизнь пользователей становиться безрадостной? 

Если у вас используются системы IBM, то существует такой замечательный продукт как Tivoli Storage Productivity Center (TPC). 

Tivoli Storage Productivity Center (TPC)

По сути это даже не один продукт, а несколько разных: TPC Basic Edition, TPC for Data, TPC for Disk, TPC for Replication, TPC Standard Edition. 

TPC for Disk как раз позволяет следить за состоянием СХД и их производительностью, а также получать алерты и всевозможные отчеты. 

Проблема в том, что для СХД начального и среднего уровня цена TPC for Disk была до недавнего момента явно высокая (учитывая тот факт, что лицензируется весь объем дискового пространства). 

И вот, совсем недавно (14-го мая) была анонсирована еще одна версия: TPC for Disk MidRange Edition (TPC for Disk MRE). 

Отличие ее от “старшего” брата состоит в том, что, во-первых, поддерживаются только системы DS3000/4000/5000, а во-вторых, (и это, на мой взгляд, основное) лицензирование осуществляется по устройствам. Т.е. фактически нужно просто сложить количество контроллерных и дисковых полок и умножить результат на стоимость лицензии. 

Цена лицензии

В большинстве случаев цена получается ниже примерно в два раза (а если используются SATA диски большого объема, то разница в цене может быть и в несколько раз). В результате, можно централизованно (с интервалом до 5-ти минут) получать следующие данные:

• производительность контроллеров (число операций ввода-ввывода)
• производительность контроллеров (скорость передачи данных)
• процент попадания в кэш
• производительность отдельных портов контроллеров

Качество предоставления сервисов

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

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

Пара слов про IBM DS3500 (DS3512/DS3524)

Официальный анонс прошел, системы начнут отгружаться 15го июня, всю информацию конечно можно найти на сайте IBM, но если не хочется читать и искать,то вот немного информации:

• Две базовых модели – на 12 3.5” диска (DS3512) и на 24 2.5” диска (DS3524), полки расширения также на 12x3.5” и 24x2.5” (EXP3512 и EXP3524 соответственно).
• Максимум на текущий момент поддерживается 96 дисков SAS, т.е. можно получить до 192ТБ на “медленных” дисках.
• Поддерживаются диски с шифрованием (только 600ГБ SAS).
• Двухконтроллерная система в “базе” имеет 4 SAS порта для подключения к хостам, кроме того, можно к каждому контроллеру добавить интерфейсную плату либо с 2мя портами SAS, либо с 4мя портами FC 8Gbit, либо с 4мя портами iSCSI 1Gbit. Выбор по интерфейсам получается такой: 4xSAS, 8xSAS, 4xSAS + 8xFC, 4xSAS + 8xiSCSI. Мне лично немного жаль, что нет варианта iSCSI + FC, но видимо маркетологи посчитали иначе :)
• Производительность из кэша – до 200тыс IOPs (при включенной опции Turbo Performance) и до 40000/12500 IOPs чтение/запись с дисков. Линейная производительность заявлена 4000/2600 MB/s для чтения/записи. Кэш 1 или 2ГБ на контроллер.
• Контроллеры “общаются” друг с другом через интерфейс PCI-E 2.0 x8, что дает пропускную способность 4ГБ/сек.
• RAID традиционно реализован аппаратно, поддерживается и RAID 6 (P+Q).
• Батарейка служит не для того, чтобы поддерживать состояние кэш-памяти при сбоях питания, а для того, чтобы сбросить содержимое кэша на флэшку. Это дает возможность держать систему выключенной долгое время без потери данных в кэше.
• Из новых возможностей – синхронное и асинхронное зеркалирование (Enahnced Remote Mirror) по FC.
• Поддерживается до 64х Storage Partitions (по-умолчанию 4), до 8 мгновенных снимков на том (64 на систему).
• К СХД можно подключать хосты под управлением Windows, Linux, VMware (все это в базе), а также, при покупке соответствующей лицензии, AIX/VIOS, Linux on Power и HP-UX.
• В Linux поддерживается Device Mapper, что избавляет от необходимости устанавливать MPP для нормальной работы.

Выглядят системы вот так (тыльная сторона показана для SAS+FC и SAS+SAS):

Что сказать в итоге? DS3500 производит очень и очень достойное впечатление. Во многом из-за того, что по производительности и функционалу догнали системы среднего уровня и, при этом, остались в ценовых рамках DS3000. Диски SATA поддерживать не стали, я думаю из-за того что не хотели придумывать мультиплексор для 6Gbps, впрочем не сильно-то и нужно, когда Seagate делает 2TB диски с SAS интерфейсом. Пока не увидел возможности делать remote mirror между DS3500 и DS4000/5000 – может быть невнимательно смотрел, а может быть сделают со временем. Если сделают – это будет еще одним огромным плюсом, но пока и так поживем :)  С учетом того, что DS3000 прожили на рынке уже 3года, а актуальность так и не потеряли, думаю, что системы DS3500 ждет большое будущее.

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

Глобальное пространство имен файлов (3/4)

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

"Прозрачное" внедрение в инфраструктуру.

Добавление файлового сервера под управление AutoVirt делается в два этапа:

1. На первом происходит просто сканирование файловых ресурсов, а самому серверу присваивается новое, "виртуальное" имя. При этом, никаких изменений в инфраструктуре в этот момент вообще не происходит - сервер остается доступен всем клиентам. Все файлы на нем также доступны со своими привычными UNC именами. По-умолчанию, виртуальное имя сервера отличается от “настоящего” приставкой "av-", впрочем, его можно задать и совершенно произвольно (главное, чтобы другого сервера с таким именем не было).
   Теперь ко всем ресурсам файлера можно также обращаться, используя не только привычное UNC имя, но и виртуальное имя сервера. На практике это конечно не нужно, но зато дает возможность убедиться в том, что сервер AutoVirt нормально функционирует и можно приступать ко второму этапу. На картинке видно, что у нас есть Dependent (зависимое) пространство имен - это означает, то ресурсы хотя и доступны через сервер AutoVirt, но они "привязаны" к физическому серверу и пока еще не могут быть перенесены с него на другой файлер.
2. Для того, чтобы полностью виртуализировать файловый ресурс (например \\fileserver) и "отвязать" его от "железа", необходимо запустить так называемый процесс "Cutover". Физически он сводится к тому, что мы (под руководством AutoVirt) меняем имя сервера на новое, а запросы к изначальному имени перенаправляются с этого момента на сервер AutoVirt. Собственно это и есть единственный перерыв в обслуживании - смена имени сервера требует его обязательной перезагрузки. Все остальное время все ресурсы сервера доступны пользователям в полном объеме! Т.е. время простоя сервиса составляет всего несколько минут! Теперь любой запрос к \\fileserver будет происходить через AutoVirt, который переадресует его на нужный сервер (либо на оригинальный, либо же на любой другой сервер, если была осуществлена миграция данных).

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

А как быть, если нам потребуется отказаться от AutoVirt (всем система хороша, но бюджет на нее выделили только на следующий год)? И это тоже очень просто - достаточно произвести еще один Cutover, чтобы вернуть все на круги своя. Правда здесь уже нужно быть осторожнее - если была осуществлена миграция данных, процедура не столь тривиальна (иначе данные перестанут быть доступны по привычным UNC именам).

Поддержка DFS.

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

Подробный рассказ о главных преимуществах AutoVirt ждите в заключительной части. А пока (для затравки) сравнение возможностей с DFS:

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

Многопоточный RAID

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 активно используется эта самая многопоточность для увеличения производительности по сравнению с имеющимися на рынке решениями. Кэша нет, а следовательно нет и необходимости в батарейке. 

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

Глобальное пространство имен файлов (2/4)

Это продолжение ранее начатой короткой серии заметок про управление файловыми серверами.

Так какие же есть альтернативные (предлагаемому Microsoft DFS) решения, чтобы удобно, просто и по возможности прозрачно для существующей инфраструктуры получить глобальное пространство имен? Рассказ пойдет о продукте компании AutoVirt. Первое, что бросается в глаза, - это не надстройка и не дополнение к Microsoft DFS. AutoVirt является совершенно самостоятельным решением и для его работы не требуется ни DFS, ни DFS-R - нужен только домен и конечно сами файловые серверы. Какие положительные качества решения можно выделить:

• отказоустойчивость "by design"
• прозрачное внедрение в инфраструктуру без необходимости что либо менять у пользователей
• поддержка DFS
• различные политики, обеспечивающие управление данными (миграция, репликация и т.п.)

Сначала немного остановимся на принципах работы, а затем я постараюсь подробнее описать каждую из "особенностей" AutoVirt.
Реализация глобальной системы имен основана на перенаправлении DNS запросов. Обычно, при обращении к папке на сервере, когда мы набираем \\A\myshare, сначала идет запрос к серверу DNS, который нам возвращает IP адрес сервера "A". А уже потом мы с этого файл-сервера получаем необходимые нам данные:

Глобальная система имен в AutoVirt работает почти также, только теперь разрешением имен занимается не DNS, а сервер AutoVirt, на который DNS сервер и перенаправляет все запросы:

Благодаря такому подходу, становится возможным динамически менять ссылки на ресурсы без каких-либо видимых последствий у пользователей - если все данные были перенесены на сервер "B", то достаточно изменить ссылку на уровне сервера AutoVirt и пользователи будут уже обращаться к новому серверу, а старый можно выводить из обслуживания. Так ведь и Microsoft DFS работает точно также, скажете Вы! Где научная новизна?! Где преимущества? За что деньги-то платить? И будете правы (но лишь отчасти) - сама по себе глобальная система имен работает примерно одинаково у всех производителей. Дьявол кроется, как обычно, в деталях. Давайте к ним и обратимся!

Отказоустойчивость и схема работы.

Совершенно очевидно, что для обеспечения нормальной работы пользователей необходима высокая доступность Global Namespace (глобального пространства имен). AutoVirt имеет встроенные возможности кластеризации (т.е. нет никакой необходимости ни настраивать Microsoft Cluster, ни платить за Enterprise лицензию Windows Server). Более того, настоятельно рекомендуется развернуть сразу два сервера AutoVirt в кластере. Настройка кластеризации происходит автоматически, при установке ПО - ничего для этого делать дополнительно не нужно. Полностью поддерживается установка в виртуальной инфраструктуре, более того, в большинстве случаев рекомендуется изначально идти именно по такому пути (по крайней мере на сравнительно небольших инсталляциях).

Концептуально схема AutiVirt выглядит так:

Политиками (Policy Engine)  в каждый момент времени управляет только один сервер, но в случае его сбоя, управление будет передано на вторую машину. Policy Engine фактически управляет всей работой комплекса. Data Engine (DE) - это процессы, обеспечивающие всю "грязную работу" - миграцию и репликацию данных, т.е. все действия связанные с физическим передвижением файлов между системами. DE работают на обеих машинах одновременно. Более того, если производительности для какой-то глобальной миграции данных недостаточно, то число серверов DE можно увеличить. Скажем, для ускорения миграции файлов на только что закупленный NAS, можно на время увеличить число Data Engine, тем самым практически пропорционально сократив время миграции. Client Referrals, в свою очередь, отвечает на запросы клиентов. Процесс работает параллельно на нескольких серверах. Если в компании есть удаленные офисы, где работает свой сервер AD, то рекомендуется в них  разместить дополнительные серверы AutoVirt, чтобы обеспечить бесперебойную работу клиентов в случае обрыва каналов связи.

Управление AutoVirt'ом осуществляется через простую и интуитивно понятную WEB-консоль, никакого дополнительного ПО (кроме браузера с поддержкой SilverLight) администратору не требуется:

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

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

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

Глобальное пространство имен файлов (1/4)

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

Файловые серверы - казалось бы, что может быть проще? Уже давным давно все привыкли - пишем в адресной строке \\fileserver\mydir\mydoc.doc (то, что заумно называют "UNC имя файла") и открывается нужный нам документ. Если не помним название файла, можно открыть весь список, полазить по папкам. В конце концов, есть ведь и поиск (вплоть до содержимого самих файлов)! А что происходит если вчера этот самый "fileserver" сломался и IT отдел быстро заменил его сервером \\fserver28 (даже все данные удалось вовремя восстановить из резервной копии за ночь)? Тогда мы, в душе поругавшись на айтишников, которые только жить мешают, пойдем открывать файл на этом новом сервере, запомнив новое название на будущее.

Конечно, сейчас опытные админы скажут, что так дела не делаются и можно было несколькими способами оставить UNC имя без изменений! Конечно можно. Можно было и через DNS перенаправить запросы со старого сервера на новый, а можно было задействовать DFS, а можно... Да много чего конечно можно, но это каждый раз требует ручного вмешательства и с каждой такой модификацией шансов запутаться и не найти уже никогда концов становится гораздо больше.  Со своими файлами-то разберемся - поворчим, но найдем - никуда они не денутся. А вот если активно используются ссылки в документах? Кто будет следить за целостностью ссылок во всех документах? Изменилось UNC имя - нужно найти и поменять все ссылки. Кропотливая задачка, может быть можно как-то проще?

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

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

Наиболее яркий пример - Microsoft DFS (Distributed File System). Система очень проста (так как имеет очень ограниченные дополнительные возможности), но зачастую требует кропотливой ручной работы администратора. Главный плюс - продукт совершенно бесплатен (а если точнее, то входит в базовый функционал Windows Server) и за счет этого довольно популярен. Однако, внедрение DFS в существующую инфраструктуру - самая большая головная боль (причем не только для администратора). Разом потребуется заменить все unc имена файлов на новые. Т.е. если раньше мы обращались к файлу \\fileserver1\share2\accounting\nds2010.xls, то теперь это будет что-то типа \\Acme\accounting\nds2010.xls Разумеется, потребуется поменять и все ссылки на внутренние файловые ресурсы внутри документов. А главное, этот процесс нельзя делать постепенно - иначе проблем возникнет еще больше. Поэтому все пользователи начиная с момента внедрения DFS должны начать пользоваться только DFS для доступа к файлам. Хотя от версии к версии DFS становится все более и более удобным, для достижения идеала еще предстоит сделать очень много. Тем временем объем неструктурированных данных растет очень быстро (по ряду оценок рост достигает 100% в год).

Существуют удобные альтернативы (и дополнения) для DFS. В частности, до недавнего времени компания Brocade выпускала такой замечательный продукт как Tapestry StorageX - это была "надстройка" над DFS, существенно упрощающая работу администратора. Помимо удобной консоли для управления, StorageX имел и встроенные возможности по репликации. Репликация могла быть довольно просто интегрирована с NetApp SnapMirror - в случае сбоя на одной из площадок, автоматически активировался том на "зеркальном" файлере и пользователь практически мгновенно получал доступ ко всем файловым ресурсам так, как будто бы ничего и не произошло. Данное решение активно продавалось под именем VFM (Virtual File Manager) вместе с файлерами NetApp (а заодно и с системами IBM N-Series) и действительно многим помогло в развертывании DFS.

Впрочем, и этот продукт не был лишен ряда недостатков:

• Пользователю необходимо помнить о том, что от доступности сервера StorageX напрямую зависит весь функционал (встроенная репликация, failover и т.п). В случае если сервер StorageX "встанет", все политики перестанут работать и не будет происходить автоматического переключения между системами хранения при сбоях.
• Помимо обеспечения высокой доступности сервера StorageX необходимо помнить и про доступность самой DFS - ведь вся работа с файлами происходит непосредственно через DFS, а StorageX - только надстройка. Отказоустойчивость DFS тоже требует определенной настройки и внимания, а следовательно добавляет некоторую головную боль администратору при внедрении и поддержке.
• Отсутствует интеграция с DFS-R (Distributed File System Replication). При этом , непосредственно в самом StorageX нет возможности делать "multi-master" репликацию (т.е. двунаправленную синхронизацию между серверами), а это во многих случаях бывает необходимо для заказчика.

Однако еще летом 2009года в Brocade "закрыли" этот продукт окончательно и бесповоротно. В причины такого решения мы вдаваться не будем - возможно недостаточный спрос или смещение интересов от изрядно нашумевшей концепции File Area Network, а может что-то еще - сейчас это уже не так важно. Однако всем, кто успел приобрести StorageX/VFM, пора бы уже задуматься об адекватной замене, так как оплаченная поддержка уже либо  закончилась, либо подходит к концу.

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

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

Убийца SVC где-то рядом?

Еще один уверенный шаг EMC в сторону концепции IT as a Service сделан. Под брызги шампанского и бурные овации на EMC World 2010 анонсирован VPLEX. Выбранное имя конечно не удивляет – сейчас продукт, в названии которого не будет буквы “V”, могут представить только аутсайдеры (даже если к виртуализации никакого отношения продукт и не имеет, а здесь-то как раз виртуализация на месте). Прозвучали и громкие слова “Storage federation”. VPLEX преподносится как таблетка от всех проблем, связанных со сложностью администрирования разрозненных “островков” систем хранения. Казалось бы, что нового? Все это уже давно есть и у IBM (SVC), и у HDS (USP-V), и даже у самой EMC (Invista) – системы виртуализации СХД уже не первый год на рынке. Но ключевой особенностью VPLEX является возможность объединять не только СХД, расположенные на одной площадке, но и системы территориально распределенные (в перспективе – на сколь угодно большие расстояния). Можно сказать, что VPLEX это вертикально и горизонтально масштабируемая система виртуализации СХД, позволяющая использовать глобальный (распределенный) кэш. В основу продукта положены технологии приобретенные вместе с компанией Yotta Yotta. Вполне логично, что VPLEX эффектно подается в связке с VMware vMotion как решение, позволяющее беспрепятственно перемещать нагрузку между датацентрами и, тем самым, обеспечивающее максимальную гибкость и подкупающую простоту администрирования. Идея произвольным образом “двигать” сервисы между площадками если смотреть “сверху” конечно импонирует (по крайней мере, до того как надо будет закопаться в детали). Привлекательно выглядит возможность передвигать ресурсоемкие сервисы по часовым поясам в зависимости от стоимости вычислительных ресурсов в данное время суток. Звучит красиво, ничего не скажешь!

Но, как и всегда, есть несколько “но”. В настоящее время VPLEX поставляется только в двух вариантах – VPLEX Local (для работы на одном сайте) и VPLEX Metro (для объединения двух площадок, расстояние между которыми позволяет использовать синхронную репликацию, т.е. до 100км). В первом случае решение ничем не отличается от любой другой системы виртуализации СХД,  во втором конечно есть отличия, но и здесь конкурентам есть что предложить. Справедливости ради нужно сказать, что в перспективе EMC обещает еще две версии VPLEX – Global, для объединения двух площадок на расстоянии более 100км (асинхронная репликация) и VPLEX Geo, который уже позволит объединять несколько датацентров на произвольном расстоянии друг от друга. Все это, однако, ждет нас не раньше 2011 года. Кроме того, функционал VPLEX в плане виртуализации также довольно ограничен на текущий момент – поддерживаемые “чужие” СХД (IBM, HDS) можно пересчитать на пальцах одной руки (список конечно планируют еще расширять); нет поддержки ни thin provisioning, ни мгновенных снимков – если это необходимо, то придется пользоваться функционалом СХД. Собственно, из-за этого скорее всего и не было объявлено о смерти Invista. Картина становится несколько мрачнее – в настоящий момент VPLEX для большинства не принесет долгожданной простоты управления, а скорее добавит сложностей. Нужно будет не только научиться управлять VPLEXом, но и продолжать следить за виртуализированными СХД и, возможно, гораздо аккуратнее заниматься выделением пространства, так как теперь между СХД и серверами окажется новое устройство, которое будет усложнять представление данных.

Что же за устройство скрывается за красивым названием VPLEX? Минимальный модуль (VPLEX Engine) состоит из двух кастомизированных x86 серверов (каждый отдельно называется Director), упакованных в одно шасси высотой 4U. Каждый director оснащен двумя 4х ядерными процессорами, 32ГБ памяти и имеет 16 дисков и 16 хостовых портов FibreChannel 8Gbit. Разумеется в комплекте обязательным образом идет еще и SPS (ИБП). Максимум в кластер для увеличения производительности можно объединить до 4х Engine (получается 8 директоров). Друг с другом директоры общаются через выделенные FC порты (помимо упомянутых выше 32х штук), для чего используются отдельные коммутаторы. На каждом директоре присутствует по 2 порта для взаимодействия внутри кластера и 2 порта для взаимодействия с удаленными комплексами. В максимальной набивке комплекс VPLEX выглядит примерно как на картинке справа. Помимо 4х узлов и двух коммутаторов в стойке также размещается управляющий сервер, через который собственно и происходит вся работа с VPLEX. Из 32ГБ памяти каждого директора, в качестве кэша используется около 20ГБ, таким образом, на каждой площадке можно получить до 160ГБ кэша. Кэш используется только для чтения: при получении запроса VPLEX проверяет наличие данных у себя в кэше, если данных там нет, то проверяется глобальный кэш (память остальных узлов) и только если данных не оказывается и там, делается запрос на чтение с дисков. Вся запись ведется “сквозным” образом, т.е. подтверждение хосту об успешном завершении отправляется только после того как VPLEX получит соответствующее подтверждение от всех дисковых систем, участвующих в записи блока данных. Так как VPLEX это по сути своей система виртуализации СХД, то выделение LUNов хостам делается через VPLEX (хотя конечно можно и просто “пробрасывать” LUN с дисковой системы без изменения).  В общем случае, картина примерно такая: LUNы, созданные на дисковой системе, отдается во владение VPLEXу, на них создается один или несколько экстентов (extent) произвольного размера, затем эти extent объединяются в девайсы (devices), на которых можно уже создать виртуальные тома (virtual volume) и уже эти самые virtual volume можно раздавать хостам. На первый взгляд немного запутано, но практически все системы виртуализации так и работают. Каждый комплекс VPLEX может раздавать хостам до 8000 LUNов.

 

 

Итак, анонс прошел, фанфары прозвучали, что в сухом остатке? Отношение неоднозначное. Сказать, что EMC “стрельнули” уникальным продуктом я не могу. Вот если бы все это было реализовано на базе VMAX, это было бы действительно “круто”! Концептуально предложенное решение мне, впрочем, и так нравится. Но вот что не нравится: отсутствие кэша на запись, отсутствие таких функций как thin rpovisioning, снимки, клоны и т.п. Сейчас можно говорить лишь только об озвученном плане на будущее развитие. План радужный, но насколько он будет воплощен в жизнь остается под вопросом. А пока заказчикам остается выслушивать истории про Storage Federation и IT as a Service ну и конечно про Cloud Computing. Впрочем, если вдруг прямо сейчас нужно взять и начать строить (именно начать) пресловутое облако, то возможности VPLEX могут оказаться востребованы. Для двух площадок можно даже обойтись и без VMware SRM, продолжая обеспечивать высокий уровень доступности сервисов. Так что заказчики на VPLEX безусловно найдутся, но сможет ли он серьезно потеснить IBM SVC (или хотя бы HDS) на рынке систем виртуализации – большой вопрос. И на сегодняшний день мой прогноз – в ближайший год шансов очень и очень мало.

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

LSI подсуетился :)

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, а теперь ее можно приобрести и в виде опции для обычных версий этих контроллеров.

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

Podcast про процессоры Intel Xeon 5600

В качестве пробного шара, мы с коллегой попробовали записать подкаст, это как радио только в интернете :-).

На пробу мы выбрали достаточно нейтральную тему связанную с презентацией Intel своих новых процессоров 5600/7500. Понятно что сейчас уже май на дворе, и актуальность темы снижается, несмотря на это я хотел бы попросить читателей прокомментировать наше творчество, поскольку чтобы понять продолжать или нет, как минимум нужна обратная связь.
Собственно запись:

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