Posts tagged ‘rhel’

Загрузка серверов на 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)

Сравнение производительности протоколов на примере Oracle 11g/RHEL

??нтересный отчет опубликовала сегодня тестовая лаборатория NetApp, анализировавшая производительность Oracle 11g на RHEL и системе хранения NetApp.

Для затравки вам картинка:

image

Полностью читать – там:
Red Hat Enterprise Linux Protocol Performance Comparison with Oracle Database 11g Release 2
http://www.netapp.com/us/library/technical-reports/tr-3932.html