Posts tagged ‘boot’

Загрузка серверов на Linux с NFS

Некоторое время назад попал на глаза любопытный текст, рассказывающий как можно организовать загрузку серверов с RedHat Server (в общем случае – любого Linux) с сервера NFS (в нашем случае, понятно, с NetApp FAS). В практике описавшего человека речь шла о загрузке большой кластерной вычислительной фермы, но, вероятно, такая возможность подойдет и во множестве других случаев.

По поводу бездисковой загрузки, как я заметил, существует также довольно много странных предубеждений и заблуждений. Например, считается, что только по FC, и только с помощью поддерживающих это HBA можно осуществить бездисковую загрузку сервера. Однако это не совсем так. Конечно, с помощью FC это сделать достаточно просто, и я даже писал на эту тему статью в блоге, с рядом типсов и триксов. Однако кроме загрузки по FC есть и другие варианты. Можно загрузиться по iSCSI, если у вас есть iSCSI HBA с BIOS и режимом загрузки в нем. Но даже и без HBA с BIOS это сделать можно, что и показывает рассматриваемый пример.

Сегодня практически любой современный сервер умеет делать загрузку netboot с помощью PXE – Pre-boot eXecution Environment. С его помощью мы сможем, в том числе, осуществить полноценную загрузку бездисковых серверов с NFS-сервера, без какого-либо FC, а дальше уже вольны использовать все возможности сервера Linux и системы хранения NetApp.

Преимущества такой загрузки, кроме очевидной экономии на локальных дисках:

  • Развертывание новых серверов, особенно когда их счет идет на десятки или даже сотни, становится тривиальным.
  • Отсутствие внутреннего жесткого диска делает проблему замены сервера, например в случае выхода из строя, предельно простой. Сервер с унифицированным “железом” грузится из загрузочного образа, в котором находятся все identities.
  • Очень простой становится и процедура Disaster Recovery. Устанавливаем репликацию SnapMirror между двумя сайтами, в случае проблем на основном сайте переносите или устанавливаете новые сервера (или VM) на резервном сайте, правите MAC на TFTP boot server, чтобы не исправлять этот параметр в бут-образах, и сервера грузятся также, и с тем же содержимым, что и на старом сайте.
  • Нет проблем с повреждениями локальной файловой системы. Никакх fsck. Для сервера его “файловая система” – WAFL на сторадже, отдаваемая по NFS, а WAFL крайне устойчива к повреждениям, так как это транзакционная файловая система.
  • Можно использовать FlexClone. Тома ваших OS и загрузочные образы это идеально подходящий случай для использования FlexClone, экономия пространства будет великолепная, а эффективность работы, в том числе за счет повышения эффективности кэширования – очень высокая.
  • Работа с централизованным, легко расширяемым  стораджем решает проблему исчерпания локального места на дисках серверов.

Конечно есть и ряд недостатков (решаемых):

  • TFTP-сервер и DHCP становятся критичными ресурсами, и могут даже стать “точкой отказа”, если вы не позаботитесь о их резервировании. Например можно поднять tftp-server непосредственно на NetApp FAS (options tftp.enable on и установить том для .rootdir), а для возможности работать с несколькими dhcpd, на разных машинах, можно использовать опцию next-server в файле конфигурации dhcpd.conf на загружающемся сервере.
  • Сетевые интерфейсы иногда могут иметь разные имена. ??з этой ситуации можно выйти, предусмотрев возможность переименовывать в скрипте имена udev, приводя их к единообразному виду. В приведенном документе показан способ этого решения.

Подробный документ how-to по загрузке сервера Linux с NFS-шары по TFTP, со всеми полезными настройками и скриптами можно взять здесь:

RHEL 6.2 NFS Boot installation.docx (63.4 K)

SAN boot

Я обратил внимание, что очень многие, в особенности впервые сталкивающиеся с SAN, обязательно хотят реализовать у себя возможность бездисковой загрузки серверов из SAN, с созданного в ней LUN-а. Но потом как-то охладевают к этой идее, по причине ряда сложностей реализации и неочевидности преимуществ. Действительно, если у вас blade-ферма на три десятка blades в ней, то экономия на жестких дисках по ценам изготовителя blades, может вылиться в экономию, за которую можно пострадать, но при всего 2-4 серверах в SAN это обычно не стоит выделки. Однако если вы все же решили заняться SAN boot, то вот какие полезные сведения я обнаружил в блоге группы поддержки решений Microsoft, сформированной в NetApp.

Во-первых, следует знать, что на сегодняшний день загрузка из SAN для актуальных OS Microsoft полностью поддерживаемое решение. См. статью из Knowledge Base.

Во-вторых, следует помнить, что проблемы с зонингом – есть “номер один” всех проблем с SAN boot. Если у вас что-то не работает – начните с проверки зонинга. Чаще всего разрешение проблемной ситуации с зонингом и есть решение проблемы загрузки из SAN. Если ваша система на поддержке – обратитесь в поддержку NetApp, они “знают много гитик”. Проверяйте и перепроверяйте все настройки зонинга ДО того, как начнете долбить поддержку.

Третий момент, который стоит помнить, это то, что поддержка MS MPIO на этапе загрузки крайне ограничена. ??спользуемый в MS на этапе инсталляции WinPE (Windows Preinstall Environment) не рассчитан на работу с MPIO, и подключение LUN по нескольким путям может давать непредсказуемые результаты. При первой загрузке этапа установки, инсталлятор Windows загружает модуль boot.wim (это и есть WinPE) и начинает копирование файлов из дистрибутива в “локальный диск”, который в вашем случае будет SAN LUN-ом. После копирования загрузится уже собственно Windows. Поддержка рекомендует на время работы WinPE физически отключать второй путь, который можно будет подключить назад позже, когда у вас уже будет работающий MPIO.

Также стоит помнить, что MPIO не поддерживается в sysprep. Вам придется настроить MPIO непосредственно на том образе, с которого будут грузиться система, но официально не поддерживается его конфигурирование непосредственно в syspreped образе. Оно работает, как показывает опыт. Но не поддерживается MS. Be warned, есличо.

MPIO, несмотря на написанное выше, настоятельно рекомендуется для загрузки SAN boot! Если в момент загрузки вы потеряете связь с SAN LUN, с которого система загружается, она упадет в BSOD Inacessible boot device. Смотрите по этому поводу статью в TechNet.

Для того, чтобы LUN в SAN был увиден системой на этапе инсталляции, он должен быть подключен из BIOS карты HBA. Это поддерживается для “аппаратных” HBA FC (FCoE), а также для hardware HBA iSCSI. Теоретически есть методы загрузки из SAN и для Software iSCSI, но рассмотрение этой темы выходит за рамки данной статьи.

Напомню еще раз, что, для двухпортовых карт, вы должны активировать поддержку загрузки в BIOS только для одного из двух имеющихся портов HBA! Реализация отличается в зависимости от вендора HBA, так что внимательно проследите эту тему самостоятельно по документации. На этапе загрузки не работает MPIO, и LUN должен видеться только по одному пути!

Если после всего перечисленного выше, инсталлятор по прежнему не видит диск, на который он может установить OS, то, скорее всего, в дистрибутиве проблема с драйверами для данного типа HBA. Можно попробовать вставить правильные драйвера непосредственно в инсталлятор, в модули boot.wim и install.wim, либо подставьте драйвера вручную, когда это запрашивает инсталлятор. Опять же тема интеграции драйверов в дистрибутив Windows достаточно хорошо рассмотрена в интернете.

Помните, что если вы вынули CD/DVD-диск, чтобы вставить на его место диск с драйверами, то не забудьте вернуть назад диск с дистрибутивом для продолжения установки. :)

Обратите внимание, что в Windows Host Utilities Installation and Setup Guide со страницы 95 идет очень детальное и подробное описание настройки SAN Boot.

Для практической проверки и отработки решения группа построила стенд из 22 серверов Fujitsu RX200, снабженных двухпортовыми FCoE HBA Brocade 1020, включенных в два коммутатора Brocade 8000 FCoE, куда также подключены два контроллера FAS6030 с дисками. HBA обладают возможностью загрузки из SAN в их BIOS, а сервера имеют средства управления Fujitsu iRMS (аналог HP iLO и DELL DRAC). Система хранения NetApp имеет активированную лицензию FlexClone, используемую в дальнейшем процессе. В принципе, описываемые процессы могут быть реализованы и без FlexClone, но с ним они куда эффективнее расходуют пространство хранения, так как место на диске занимают только изменения относительно мастер-LUNа.

Начнем с создания пустого volume и на нем LUN-а, который будет мастер-образом. Смонтируем данный LUN на один из серверов, заполним и сконфигурируем его, а позже склонируем для остальных серверов. Не забудьте установить в этот образ OS все нужные роли, драйвера и приложения, в данном случае были установлены NetApp DSM, Host Utilities, а также драйвера и приложение управления HBA от Brocade.

Запустим sysprep с опциями –generalize и –shutdown, после чего сервер отключится и LUN необходимо отмапить от сервера. Эталонный мастер-образ подготовлен.

Теперь подготовим остальные сервера на загрузку из SAN. Помните, что в BIOS HBA необходимо включить загрузку с SAN LUN только для одного порта! Смотрите ссылку на документ Boot from SAN in Windows Server 2003 and Windows Server 2008 из MS Download Center.

В имеющемся HBA в BIOS была выбрана опция загрузки “First visible LUN” (эти настройки могут отличаться для разных HBA, решайте по аналогии) с тем чтобы обеспечить наиболее простую загрузку, которая не потребует в дальнейшем перенастройки при изменениях, как в случае опции “Preferred LUN”. Вариант First visible LUN, разумеется, требует некоторых предосторожностей, например дисковый массив с загрузочным LUN должен располагаться в ближайшей к серверам фабрике, чтобы минимизировать задержки, а также иметь LUN ID 0.

Создаем клон тома мастер-образа, например с помощью FlexClone. Маппим LUN в клоне тома (не оригинальный мастер-образ, а клон!) на сервер. Включаем сервер с использованием iRMC и подключаемся к серверной консоли.

Сервер загружается и запускается mini-setup после sysprep. В нем вы можете задать пароль, изменить имя сервера, назначить IP-адрес, и так далее (если вы знакомы с развертыванием образов Windows с использованием sysprep, это не должно быть неожиданностью). После завершения mini-setup вы получаете созданную из мастер-образа индивидуальную копию установки Windows.

??так, мы за несколько минут получили полностью загруженный в индивидуальный образ Windows физический сервер, загружаемый из SAN.

Немного иначе происходит процесс для загрузки виртуальных серверов из SAN.

В случае pass-through disks Hyper-V все происходит также, как и в случае физического сервера, но нужно создать для VM еще один клон, и назначить ему LUN ID отличный от 0, чтобы он не пересекся с LUN, используемым для загрузки физического сервера. ??спользуя LUN FlexClone вы можете создать клоны мастер-LUN непосредственно на том же volume, где он сам и находится. Следите, чтобы на volume либо было достаточно места для записи хранимых “разностных” изменений, или чтобы была активирована опция “volume autogrow” и места было достаточно уже на aggregate этого тома. Если вам понадобится создать больше VM, просто создайте еще несколько клонов мастер-LUN.

В случае использования VHD, следует создать LUN для физического сервера, содержащий файлы VHD для находящихся на нем виртуальных. Также можно использовать возможности sub-LUN клонирования FlexClone, создав один клон LUN-а с множеством клонов VHD в нем.

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

??спользование же FlexClone в данном случае поможет значительно сократить занятый объем. Например, в описываемом случае, около 50 LUN-ов разлчных проектов данного стенда имеют совокупную емкость около 5TB, занимая при этом на диске всего около 300GB.