Xen и DS4800. Многоканальный доступ к системе хранения данных

Задать вопрос по решению

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

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

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

В этом решении мы показываем, как обеспечить многоканальный доступ хосту Xen и гостевым доменам к системе хранения данных IBM System Storage DS4800, используя дистрибутив Red Hat Enterprise Linux 5 update 1 (RHEL 5.1), а также распространяемый компанией IBM драйвер RDAC (RAID-контроллер) c поддержкой многоканального доступа.

Виртуализация и Xen

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

Преимущество данного типа виртуализации состоит в том, что за счёт "сотрудничества" гостевой ОС и гипервизора при выполнении низкоуровневых вызовов в большинстве случаев производительность гостевого домена Xen близка к собственной (native). Стоит заметить, что этот тип виртуализации наиболее эффективен по производительности и работает на широком спектре оборудования.

Недостаток его состоит в том, что поддерживаются только соответствующим образом модифицированные ядра, поэтому вы не сможете использовать Xen со старыми операционными системами (например, Windows® 2000). Тем не менее, поскольку виртуализация становится такой популярной темой, производители микропроцессоров стремятся поддержать эту тенденцию. Процессоры с поддержкой технологий Intel-VT и AMD Pacifica способны обеспечить работу гипервизора Xen и с немодифицированными гостевыми ОС, правда, с некоторой потерей производительности.

На сегодняшний день наиболее распространён гипервизор Xen версии 3; некоторые поставщики Linux решили включить его в свои дистрибутивы. К примеру, Xen стабильно работает и поддерживается дистрибутивами Red Hat Enterprise Linux 5 и Novell SUSE Linux Enterprise Server 10, и, что не менее важно - он бесплатен!

Архитектура Xen

Когда вы запускаете хост Xen, гипервизор Xen первым берёт на себя управление системой. Затем он загружает гостевую ОС, или домен 0 (Dom0) в терминологии Xen. Пользователь взаимодействует с Xen посредством Dom0. Все драйверы устройств для доступа к оборудованию также загружаются в Dom0. Dom0 обеспечивает доступ других гостевых ОС, которые иногда называют доменом U (или DomU), к виртуальным блочным и сетевым устройствам. С этого момента я больше не буду считать Dom0 гостевой ОС, несмотря на то, что по существу это экземпляр гостевой ОС с некоторыми специальными возможностями.

Для доступа к виртуальным блочным и сетевым устройствам внутри каждого гостевого домена (DomU) используются "облегчённые" драйверы устройств - драйверы frontend (внешний интерфейс), в отличие от Dom0, где используются "тяжеловесные" драйверы backend (внутренний интерфейс). На рисунке  представлена схема архитектуры Xen.

Начиная с версии Xen 3.0.3, виртуальный блочный frontend реализован в модуле xenblk, а backend - в модулях blkbk и blktap. Виртуальный сетевой frontend реализован в модуле xennet, а backend - в модуле netbk. Чтобы выяснить, какие модули ядра загружены в вашей системе, а также получить информацию об этих модулях, используйте команды lsmod и modinfo.

Многоканальный доступ и система хранения данных SAN

Переход от прямого соединения между системой хранения данных и хостом к инфраструктуре совместно используемых систем хранения данных SAN - это существенное усложнение картины. То, что когда-то было выделенным интерфейсом SCSI или кабелем FC между хостом и системой хранения данных, сейчас представляет собой скопление кабелей FC, коммутаторов SAN, серверов хранения данных с контроллерами, дисками и т.д. Наряду с бесспорными преимуществами, SAN обладает и недостатками, ввиду высокой вероятности выхода из строя компонентов между хостом и жёсткими дисками. Многоканальный доступ к системам хранения данных - отличный способ решения таких проблем.

Фактически хост имеет возможность доступа к логическим дискам (используя логический номер устройства, или сокращённо LUN) на сервере хранения данных по нескольким независимым каналам. Драйвер многоканального доступа объединяет все маршруты доступа и "показывает" операционной системе только одно блочное устройство. Доступ к каждому LUN осуществляется по наилучшему маршруту, а в случае выхода маршрута из строя драйвер многоканального доступа направляет запросы ввода/вывода по альтернативным маршрутам. Драйверы многоканального доступа разных производителей обладают разной функциональностью: одни способны обеспечивать "интеллектуальную" балансировку нагрузки, другие поддерживают только переключение на резервные маршруты в случае сбоя. Для системы хранения данных DS4800 IBM поверх драйвера HBA (хост-адаптер шины) рекомендует использовать драйвер RDAC. Запомните: драйвер многоканального доступа не заменяет драйвер HBA, они дополняют друг друга. Драйвер многоканального доступа - аналог мозга, а драйвер HBA - аналог рук и ног. Современные операционные системы предлагают свои собственные многоканальные драйверы, но перед тем как их использовать, удостоверьтесь, что они сертифицированы производителем вашей системы хранения.

Оборудование и программное обеспечение

Достаточно теории, давайте перейдём к архитектуре тестовой среды. У меня стоит сервер IBM x3550 c хост-адаптером HBA, который оснащён двумя портами FC. Порты подключены к разным коммутаторам SAN. Система хранения данных DS4800 имеет два контроллера, оснащённых 4 портами FC каждый. Для простоты на рисунке 2 я указал только два FC-соединения. Порты FC системы хранения, также как и порты хоста, подключены к разным коммутаторам. Таким образом, сбой на одном из маршрутов не нарушит доступ хоста к системе хранения данных. Драйвер RDAC, установленный в домене 0, отвечает за выбор наилучшего маршрута при работе в нормальных условиях и переключение на альтернативный маршрут в случае возникновения сбоя. Гостевой ОС не требуется специального драйвера для того, чтобы иметь многоканальный доступ к внутренней системе хранения данных.

 

 

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

• IBM System x3550
• 2 двухъядерных процессора Intel Xeon, 4 ГБ оперативной памяти
• HBA -адаптер QLogic QLE2462
• Дистрибутив Red Hat Enterprise Linux 5 update 1
• Драйвер IBM RDAC, версия 09.01.C5.11
• Драйвер QLogic, версия qla2xxx 8.01.07.15
• Система хранения данных IBM System Storage DS 4800, модель 1815-84A
• 2 контроллера
• 16 дисковых накопителей с интерфейсом FC ёмкостью 136 ГБ
• 8 портов FC, скорость передачи 4 Гбит/с
• Коммутаторы Brocade, модель 2109-F32
• 32 порта, скорость передачи 2 Гбит/с