вторник, 6 июля 2010 г.

Как обеспечить высокую доступность XenDesktop?

Citrix XenDesktop активно набирает популярность как решение для виртуализации десктопов (VDI). Не удивительно, что если мы принимаем решение перевести сотню (а то и не одну) пользователей в виртуальную среду, отказоустойчивость решения должна быть на высоте – потери от возможной остановки существенно выше, чем поломка одного ПК в офисе. При развертывании XenDesktop активно используется Citrix Provisioning Services (PVS) и высокая доступность этой компоненты является критичной для всего решения. Существует целый ряд возможностей по защите PVS:

  • репликация
  • LUN в режиме “только чтение”
  • общий доступ посредством CIFS/NFS (общие папки на серверах Windows, NAS устройства)

Однако, все эти решения имеют довольно существенные недостатки:

  • Репликация, во-первых, требует значительных дополнительных работ по администрированию. Во-вторых, репликация не обеспечивает высокую доступность базы данных PVS (а ведь она также необходима!). Невозможно также консолидировать файлы с write cache – его придется всегда хранить локально. Наконец, в таком режиме коэффициент полезного использования дискового пространства крайне мал из-за многократного дублирования информации.
  • Использование LUN в режиме “только чтение” позволяет повысить утилизацию дисковых ресурсов, но администрирование такого решения становится еще более нетривиальной задачей – любое внесение изменений потребует перевода LUN в режим Managed Read-Only и, как следствие, в это время доступ к LUN будет иметь только один из серверов PVS. Но по-прежнему для обеспечения высокой доступности базы данных потребуется отдельное решение.
  • Использование CIFS/NFS является наиболее простым и функциональным вариантом, однако узким местом может стать ограниченная производительность и масштабируемость. Кроме того это решение, как и уже упомянутые, не обеспечивает отказоустойчивость базы данных PVS.

Но есть и еще одно решение, которое позволит решить практически все проблемы, характерные для вышеперечисленных вариантов – совместное использование CIFS (на базе Windows Server) и Sabolic Melio Suite. Какие же преимущества у данного подхода?

  • Как и в случае с использованием только CIFS, любой из серверов PVS имеет доступ к данным как на чтение, так и на запись.
  • Файлы write cache можно хранить на общем ресурсе.
  • Sanbolic Melio 2010 обеспечивает более высокую производительность, так как теперь можно просто увеличить число файловых серверов – так как они работают параллельно, производительность системы будет фактически ограничена только производительностью дисковой подсистемы. А благодаря использованию “страйпинга” можно увеличивать производительность и еще больше. Зеркалирование позволит, при необходимости, повысить отказоустойчивость, защитившись от сбоя в т.ч. и целой СХД.
  • Возможность динамического расширения дискового пространства без какого-либо влияния на работу пользователей является еще одним огромным плюсом – любой администратор понимает, что выделить “окно” для обслуживания становится с ростом пользователей все сложнее и сложнее.
  • Помимо обеспечения высокой доступности дисковых ресурсов, Melio 2010 предоставляет уникальное решение (AppCluster) для обеспечения высокой доступности сервера SQL (базы данных PVS).
  • Поддержка VSS решает упрощает резервное копирование и позволяет быстро восстановить систему после сбоя.

В разговорах я часто слышу примерно такие слова “XenDesktop? Очень интересное решение, мы думали, но обеспечить отказоустойчивость для PVS сложно, поэтому пока отказались”.

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

Понравился пост? Подпишись через RSSRSS, EmailEmail или twitter!

четверг, 27 мая 2010 г.

Маркетинг против технологий

Не могу не скроспостить сообщение из блога про NetApp уважаемого romx. Речь про анонсы различных технологий в системах хранения компанией NetApp и реакцию EMC на эти анонсы. Собственно картинка:

В третьей колонке – время анонса аналогичных технологий в системах EMC.

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

Понравился пост? Подпишись через RSSRSS, EmailEmail или twitter!

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

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

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

Понравился пост? Подпишись через RSSRSS, EmailEmail или twitter!

четверг, 20 мая 2010 г.

О вреде вибрации в дисковой системе

В блоге у Robin Harris углядел ссылку на очень интересную статью за авторством Julian Turner о влиянии вибраций на производительность жестких дисков. Все наверняка помнят разошедшийся по интернету ролик, где было отчетливо показано, как обычным криком можно изменить производительность дисковой системы SUN. Джулиан же провел более аккуратные с научной точки зрения тесты и результаты действительно впечатляют – максимальное наблюдаемое различие в производительности операций случайного чтения достигает 246% (!), а операций записи – до 88% (при наличии естественных вибраций и их максимальном гашении) . Кроме того, не нужно забывать что увеличение латентности (которое как раз и наблюдается при наличии вибраций), является одной из причин “вылета” дисков из RAID-массивов. Использование дисков 2.5” может существенно снизить эффект, а уж про SSD и говорить не нужно – им вообще все равно.

Понравился пост? Подпишись через RSSRSS, EmailEmail или twitter!

среда, 19 мая 2010 г.

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

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

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

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

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

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

    image

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

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

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

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

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

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

Понравился пост? Подпишись через RSSRSS, EmailEmail или twitter!

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

Если используется одна система хранения, то управлять ей конечно несложно! А вот если их три или и того побольше? Как осуществлять мониторинг систем, чтобы не допускать ситуации, когда нагрузка становится фактически предельной, а жизнь пользователей становиться безрадостной? Если у вас используются системы IBM, то существует такой замечательный продукт как 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ти минут) получать следующие данные:

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

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

Понравился пост? Подпишись через RSSRSS, EmailEmail или twitter!

Пара слов про 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):

imageimage

image image

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

Понравился пост? Подпишись через RSSRSS, EmailEmail или twitter!