Failover Clustered Storage Spaces а-ля Cluster-in-a-box (проверка отказа ресурсов кластера в сценарии бюджетной СХД)

(Ликбеза по технологии Windows server 2012 - Storage Spaces, как настраивать и обзора всего того, что это может дать, в статье не будет. Кому интересно, все есть как на сайте разработчика ОС, так и других обзоров по Storage Spaces навалом)

Наверняка многие знают про новый функционал по работе с дисковой подсистемой появившейся в Windows Server 2012, а именно  Storage Spaces, позволяющий объединять диски с разными интерфейсами, в единый дисковый пул и дальнейшим созданием виртуальных дисков на этом пуле, с необходимым уровнем отказоустойчивости.

Так же не является секретом, то что Storage Spaces возможно кластеризовать и с точки зрения Microsoft , получить  не дорогое решение высоко доступного хранилища. Доступ к системе хранения может быть как файловый (CIFS, NFS, SMBScale-Out), так и блочный (iSCSI).

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

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

Семинар Тринити + Microsoft + Hyper-V

Мы рады пригласить Вас на семинар, проводимый  компаниями Microsoft и Тринити, посвященный теме:

«Построение систем высокой доступности»

Одна из основных задач IT – это повышение доступности сервисов, которые предоставляются пользователям. Данный круглый стол посвящен теме построению систем высокой доступности с помощью технологий виртуализации компании Microsoft и ее партнеров.  В рамках семинара будут рассмотрены как решения Microsoft, так и сторонние прикладные решения, расширяющие их функционал.

Мероприятие состоится 19 октября - (с 09:30-13:00) по адресу ул. Крылатская, д.17, корп. 1., бизнес центр «Крылатские холмы»

Программа:

09:30 – 10:00    Утренний кофе, регистрация
10:00 – 11:30    Как построить систему высокой доступности и нужна ли для этого виртуализация?
11:30 – 12:00    Перерыв на кофе
12:00 – 13:00    Средства повышения доступности приложений в виртуальной среде Microsoft Hyper-V

Будем рады видеть Вас!

Участие в семинаре бесплатное, просьба для регистрации направить письмо по адресу s.sosunova@trinitygroup.ru.

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

Глобальное пространство имен файлов (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.

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

Глобальное пространство имен файлов (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:

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

Глобальное пространство имен файлов (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 в плане прозрачной интеграции в уже имеющуюся инфраструктуру рассказ будет продолжен завтра.

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

Windows + Itanium = ?

Очевидцы пишут, что любовь ушла. В том смысле, что 2008R2 станет последней версией для процессоров Intel Itanium. Поддержка сохранится до 2013 года (а расширенная поддержка еще 5 лет), так что все в рамках стандартов Microsoft. Однако новых версий ждать не стоит (равно как не будет новых версий SQL Server и Visual Studio).

Основная озвученная причина – стремительная эволюция систем x86 (не только в плане производительности, но и в плане отказоустойчивости). Кроме того, поставки Windows на Superdome всегда были очень незначительными по сравнению с HP-UX и OpenVMS. Слишком медленное развитие Itanium (как и постоянные, но объявляемые “запланированными” задержки с выпуском процессоров), как мне кажется, играли в данном решении отнюдь не последнюю роль.

Стоит напомнить, что Microsoft не первый - в RedHat не так давно также отказались от дальнейшей поддержки систем на базе Itanium. Второй большой линуксовод (Novell) продолжает поддерживать IA64, но как долго это еще продлится?

Что дальше? HP столько лет всеми силами отстаивала процессоры Itanium, что отказываться от них конечно теперь не будут, но вот останутся ли другие производители или для Intel будет теперь только один покупатель на Itanium?

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

Общий доступ к дискам (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. А купить и/или получить более подробную информацию, как обычно, можно у нас. :)

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

Достоинства Microsoft Hyper-V

Некоторое время назад я писал про недостатки MS Hper-v с которыми я столкнулся в практическом внедрении. Прочтя тот текст могло сложиться впечатление, что продукт вообще не нужный и ни к чему не подходит, но это не так.

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

1. Это виртуализация от Microsoft и она работает! Как это не смешно звучит, но это очень сильный аргумент и из него вытекают многие другие  аргументы ниже.

2. Ядро системы базируется на Windows Server. В результате администраторам, которые исторически работают только с системами Microsoft, нет необходимости изучать Unix. Все же полноценное администрирование VMware без знания RedHat Linux невозможно. Самый просто пример – установка драйвера устройства отсутствующего в системе.

3. Продукт имеет встроенный функционал по обеспечению отказоустойчивости реализованный с помощью Failover Cluster. Что любопытно, имеют право на жизнь конфигурации в которых узлы кластера, кроме виртуальных машин поддерживают отказоустойчивость других сервисов. К примеру, это может быть кластер из двух серверов поддерживающий SQL, а до кучи на нем может работать 2-3 виртуальных машины. В случае если производительности хватит на всех, это на 100% рабочая конфигурация.

Опять же немаловажно, что для техников уже работавших с Microsoft Failover Cluster кластеризация виртуальных машин будет таким же привычным делом как кластеризация файловой шары.

4. Система очень неприхотлива к оборудованию на котором она работает. Есть конечно жесткое требование по обязательной поддержке технологий Intel-VT или AMD-V процессорами в системе, но за исключением этого,система работает на любой платформе. Всё же системы Windows, чрезвычайно распространены в мире и количество драйверов под них не поддается исчислению.

5. Если рассматривать вариант лицензирования отказоустойчивого кластера Hyper-V, для которого требуется минимум две лицензии на Windows Server Enterprise Edition, то эти две лицензии также позволяют запустить 4 виртуальные машины с ОС Windows Server в виртуальной среде. В ситуации когда в компании работают только Windows это вполне актуально, при определенных расчетах может получиться так что сам Hyper-V вам достается бесплатно.

6. Hyper-V комфортно управляется средствами продуктов Microsoft System Center. С их помощью он умеет отправлять сообщения о проблемах, проводить резервное копирование, мониторить производительность, детально управлять обновлениями. Что приятно есть лицензия на SystemCenter для серверов, которая лицензирует все виртуальные машины физического сервера, на все компоненты SystemCenter.

7. В Hyper-V нормально реализована система сетевого подключения для виртуальных машин. Есть VLan, есть возможность надобавлять кучу разных сетевых карт. Конечно по сравнению с другими производителями это смотрится бедненько, но с другой стороны что еще надо?

 

В результате я вижу что заказчики имеющие чисто Microsoft среды с настроенным и работающим SystemCenter, остаются довольны продуктом. Он удовлетворяет все их потребности, не заставляя вносить в свою “исключительно MS” инфраструктуру чужеродные элементы, которые еще надо кому-то поддерживать. Опять же зачастую использование Hyper-V совпадает в таких ситуациях с лицензированием нелегальных Windows Server, что фактически означает что стоимость Windows 2008 EE уходит не только на сам Hyper-V, но и на легализацию существующих Windows.

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

Полезная утилита Microsoft Diskpart

Полезность её в том, что она позволяет расширять NTFS диски в W2003, делается это нехитрым путем:

>cmd
>diskpart
>list volume
>select volume #
>extend

в этом случае все свободное место на диске, где находится том будет ему отдано. Требования: диск должен быть базовым, ФС – NTFS, место должно идти сразу за этим самым томом. Наиболее частое использование – расширение томов отданных с внешней дисковой системы. Поскольку в СХД проще недодать сейчас, чем отнять потом – команда пригодится.

также утилиту можно пользовать для просмотра ID дисков в системе:

>cmd
>diskpart
>list disk
>select disk #
>detail disk

Актуально для Microsoft Cluster Service.

Вообще утилита полезна не только этим, но это – то, чем приходится пользоваться часто.

UPD Спасибо, Александру в комментариях напомнил про выравнивание блока отступа в RAID массивах!

Проблема с выравниванием отступа (offset) старая и актуальная для 2003 сервера и младше. Заключается в том что выравнивание отступа начала файловой системы не совпадает с размером блока на массиве и поэтому все операции задействуют больше сегментов дисковой емкости чем могли бы в результате снижая быстродействие.

Описывать проблему долго и я не планирую здесь это делать, посмотреть как этот самый отступ менять можно в KB по ссылке ниже, применяя поиск по статье с ключевым словом “offset”. Для верности это значение проще всего ставить в 1024КБ. В 2008 сервере оно по умолчанию именно такое.

Ссылка на Microsoft KB по теме - №300415.

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

VMware ThinApp против…

Tolly Group на днях опубликовали новое сравнение: “Application Virtualization: VMware ThinApp 4.0 versus Microsoft App-V 4.5 CU1 and Citrix XenApp 5.0”. Указанное сравнение не включает тестирование производительности, а оценивает, что называется, общие впечатления: требования при установке продукта, развертывание клиентов, процесс “упаковки” приложений, предоставление on-line и off-line доступа к приложениям. С одной стороны, статья подготовлена по заказу VMware, поэтому довольно просто угадать лидера сравнений :) Кроме того, XenApp наверное не совсем корректно сравнивать с ThinApp – все-таки это продукты немного разных категорий, хотя возможность стриминга приложений есть и там, и там. С другой стороны, если интересует именно “упаковка” приложений для доступа как по сети, так и, например, с USB флэшек, то по простоте и универсальности обойти ThinApp пока никому из конкурентов не удается: максимально упрощен как сам процесс упаковки приложений (а главное, контроль доступа к приложениям), так и сам доступ со стороны клиента – не требуется ни установки, ни настройки никаких дополнительных приложений. Стоимость VMware ThinApp на текущий момент составляет 5000$ за комплект для 50ти пользователей и по 39$ дополнительно за каждого следующего пользователя (без учета стоимости поддержки).

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

Отказоустойчивость сетевых подключений в Windows 2008 server и Hyper-V

Для обеспечения отказоустойчивости сети, наиболее понятный путь – объединение нескольких интерфейсов в одну группу, в Linux  эта процедура называется бондинг, в Windows эта функция не заложена в ОС и требует дополнительных компонент для своей работы, компоненты эти предоставляются производителями сетевых карт. Соответственно сколько производителей сетевых карт, столько технологий объединения. Для меня представляет определенный интерес сетевые адаптеры broadcom, поскольку именно их встраивают в свои сервера все основные вендоры: IBM, HP, Dell, Fuji. Встраивают в основном карты NetXtreme I или II. Понятно что при необходимости можно добавить карты Intel, но зачастую это не позволяет сделать конструктив, к примеру в Blade системах, либо в другой ситуации оказываешься перед фактом – есть то железо которое есть. Как известно добавляют сетевые карты в сервера сверх встроенных – нечасто.

Итак о какой задаче пойдет речь – необходимо реализовать полную отказоустойчивость сервера на уровне локальной сети - 1GB Ethernet. При том, что сервер работает в кластере и используется для работы Microsoft hyper-v.

Зачем нужна отказоустойчивость сети

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

По большому счету платформа виртуализации представляет собой 3 больших блока – вычислительная часть, сетевая (I/O) и система хранения данных для виртуальных машин. Отказоустойчивость для вычислительной части на 100% процентов для х86 систем невозможна, к ней можно приблизиться путем создания Failover Cluster в Microsoft. С точки зрения отказоустойчивости системы хранения можно отметить что, отказоустойчивость самой системы рационально реализовать с помощью надежного конструктива собственно СХД и дублирования её компонент, к Microsoft и операционной системе это отношения не имеет. Отказоустойчивость путей подключения сервера к СХД реализуется с помощью встроенного в Windows 2008 MPIO либо с помощью ПО производителя СХД, тут тоже все работает без каких либо сложностей. Остается отказоустойчивость сети. Как я писал выше единственно возможный путь здесь – объединение карточек в одну группу и настройка отказоустойчивости канала в этой группе. В системах виртуализации Vmware и Citrix это встроенный функционал реализованный внутри самой системы, в Microsoft Hyper-V необходимо использовать сторонний софт. Как я писал выше я пытаюсь реализовать эту схему на сетевых картах Broadcom.

Реализация Broadcom

В ПО предлагаемом Broadcom есть 3 варианта организации Teaming:
1. Проприетарный вариант имени Broadcom. (называется - “SLB”)
2. LACP 802.11 ad
3. Generic Trunking

Несколько слов о том чем они отличаются:
1. Работает на уровне драйвера, поддержки от коммутатора не требует. теоретически в настройках есть два режима – балансировка и отказоустойчивость.
2. Требует поддержки от свитча соответствующей технологии.
3. Похоже на второй вариант, отличается жесткой организацией транка. (Более подробно в документации)

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

Настройки сетевой карты. В общем случае должно быть все также, только Locally Administered Address будет пустой. Это скриншот с уже собранного тиминга.

Первичная проверка и способ тестирования работы

Итак, чтобы с чего то можно было начать, был сделан самый просто вариант тиминга SLB из двух сетевых карт одна из которых была в режиме standby. То есть был собран самый просто режим отказоустойчивости. Эта процедура была проведена на двух серверах на которых стояла ОС w2008 server SP2 ent x64, на этих серверах был настроен hyper-v и оба они были в составе одного Failover Cluster. В кластере было 3 виртуальные машины, одна с домен контроллером для кластера и две с установленной 2008 Windows в качестве демо нагрузки. В обоих узлах кластера было по две сетевые карты broadcom BCM5708S NetExtreme II, версия драйвера 4.8.5.0, версия прошивки 4.6.0 на момент проверок это были наиболее актуальные версии взятые с сайта производителя.

Проверка осуществлялась следующим образом – на каждой из двух демо машин создавался скрипт с одной строкой “shutdown –s –t 40” этот скрипт ставился на выполнение после загрузки ОС на каждой виртуальной машине. Естественно обе машины были в кластере.

Что получалось таким образом? Виртуальная машина включалась, грузилась, а через 40 секунд выключалась. Кластерный сервис воспринимал это как аварию и включал эту виртуальную машину на другом сервере. Там происходило все с самого начала и машина опять выключалась.

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

Да, надо сказать о настройке самого кластера – в нем два узла-сервера, находящихся в одной подсети. В  качестве внешнего стораджа используется FC система, на ней хранятся виртуальные машины и кворум кластера. В кластере используется одна сеть вида 192.168.199.0/24 в этой подсети и находятся оба узла. Использование этой сети для кластера – разрешено. Режим работы кластера – “Node and Disk Majority”.

Результат первой проверки

После порядка 40 переключений ВМ, или около часа времени постоянных переключений виртуальных машин один из узлов вылетел в BSOD. В результате образовался minidump который был разобран и получен следующий результат:

C:\Users\admin\Desktop\kdfe>kdfe.cmd "teaming BASP Mini072909-01.dmp"
Analyzing "C:\Users\admin\Desktop\kdfe\teaming BASP Mini072909-01.dmp", please wait... Done.

Crash date:         Wed Jul 29 17:54:58.282 2009 (GMT+4)
Stop error code:    0x7f_8
Process name:       System
Probably caused by: NETIO.SYS ( NETIOMatchValues+14e )

Эта стоп ошибка – описана в KB842465 если коротко – ошибка вычислений CPU. По большому счету показывает что произошла критическая ошибка в вычислениях.

Затем было произведено переконфигурение тиминга в режим LACP, сделаны нужные настройки на свитче куда включались интерфейсы и повторен тест, система упала в BSOD еще быстрее в результате был получен следующий minidump:

C:\Users\admin\Desktop\kdfe>kdfe.cmd LACP_Mini073009-05.dmp
Analyzing "C:\Users\admin\Desktop\kdfe\LACP_Mini073009-05.dmp", please wait... Done.

Crash date:         Thu Jul 30 14:01:32.501 2009 (GMT+4)
Stop error code:    0x7f_8
Process name:       System
Probably caused by: NETIO.SYS ( NETIOMatchValues+14e )

ошибка полностью повторяет первую.

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

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

TS LB и как его можно отлаживать

http://blogs.technet.com/askperf/archive/2008/02/25/ws2008-session-broker-load-balancing.aspx

В этой статье - интересна следующая информация: по ключу HKLM\System\CurrentControlsSet\Control\Terminal Server можно задать уровень детализации логов, которые можно прочитать в %systemroot%\system32\tssesdir рядом с базюками самого сервиса.

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

http://blogs.technet.com/askperf/archive/2008/02/24/ws2008-terminal-server-session-broker-overview.aspx
2-ая часть статьи из предыдущего абзаца. В этом материале описываются конфигурации с использованием DS и NLB и возможности их комбинирования. Получается, что предпочтительным является вариант использования SBLB (session broker) совместно с NLB так как будет и балансировка на уровне приложения и определение того что узел NLB кластера в дауне тоже сохранится. Для такой конфигурации все узлы должны быть на серверах W2008. Оптимальным будет использование “ping back” с сервера который принял подключение, в этом случае бродкастный трафик NLB минимизируется, поскольку используется только на 1-м этапе подключения клиента к целевому IP адресу за которым стоит NLB ферма. Собственно все последующие подключения будут идти не на IP NLB, а на IP

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

Недостатки Hyper-V

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

итак по порядку

1. отсутствие нормально реализованного teaming для сетевых карт, существующий вариант от broadcom требует донастройки и “из коробки” не работает. Если же у нас узлы hyper-v еще и в кластере – то конфигурация становится невалидной, т.к. использовать на кластерных интерфейсах teaming низя по докам от MS. Т.е. нужно либо больше 2-х интерфейсов либо отказаться от teaming.

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

3. Огромное количество патчей. Часть из патчей не полностью валидировано поддержкой. Я прихожу к выводу что человек который поддерживает большую ферму hyper-v вынужден очень хорошо уметь контролировать апдейты. Поскольку не все апдейты идут через WSUS это приходится делать вручную. Немаловажно что приходится периодически для апдейтов машинки перегружать.

4. Отсутствие живых миграций. Это конечно не самый важный минус, но учитывая необходимость перегружать сервера после апдейтов периодически это нехороший момент. Да, после релиза 2008R2 лично я его не буду использовать минимум пол года.

5. Отсутствие возможности детализировать приоритеты по сети, дискам. То что есть, сделано на зачаточном уровне и в реальности сложно используемо.

6. Отсутствие поддержки FC устройств внутрь ВМ.

7. Невозможность сделать Failover Cluster между ВМ без iSCSI. Таким образом получается что приходится делать устойчивый iSCSI таргет, т.е. это либо дисковая с 2-мя контроллерами либо еще один кластер, таким образом чисто между ВМ его не сделать.

8. Сложность мониторинга состояния системы и отсылки простых оповещений. Понятно что это достигается средствами SyscOM, но ИМХО сложность продукта сравнима со сложностью самого hyper-v. В итоге получается, что для мониторинга только hyper-v приходится осваивать универсальный инструмент связанный с SQL и т.д.

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

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

11. Невозможность добавить в существующую виртуальную сеть более одного физического адаптера с каждого хоста. См выше про teaming.

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

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