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

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

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

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?

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

Windows и teaming Broadcom

Да, собственно отказоустойчивость сетевых интерфейсов предложенная Broadcom в своем софте BACS вполне достаточна для реализации отказоустойчивости этих самых интерфейсов практически во всех ситуациях.

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

Наблюдения описанные здесь относятся к ОС windows 2003/2008. В общем случае все работает отлично. В определенных ситуациях бывает необходимо фиксированным образом задать все параметры сетевой карты, и отключить все что можно отключить (RSS, Offloading etc). Ниже картинка на которой, как раз таки, все отключено. При настройке имеет смысл повторять все как на скриншоте, за исключением строк “Locally administered address” и если у вас скорость не гигабит, задать её фиксировано.

В каких ситуациях могут начаться сложности? Если кроме тиминга на конкретных сетевых интерфейсах будут использоваться еще какие-то компоненты влияющие на трафик. К ним можно отнести: MS NLB, Failover Cluster, Hyper-v virtual свитч.

Практика показывает, что тиминг и Virtual Switch – живут нормально если отключить все ненужное (см скриншот выше).

С прочими комбинациями, необходимо проводить дополнительные проверки.

Документы описывающие тиминг от broadcom:
Виденье IBM для SystemX
BNT – Broadcom + BNT swithes
FAQ на сайте Broadcom, не только про teaming
Dell и teaming Broadcom
Офф сайт с драйверами и утилитой управления тимингом(BACS)

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

Отказоустойчивость сетевых подключений в 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

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