Strict Standards: call_user_func_array() expects parameter 1 to be a valid callback, non-static method GoogleSitemapGeneratorLoader::Enable() should not be called statically in /home/sync4me/domains/aboutnetapp.ru/public_html/blog/wp-includes/plugin.php on line 311
Rhel | about NetApp

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

20/0.079

Данный блог не спонсируется, не аффилирован, и не санкционирован компанией NetApp, Inc. Излагаемая в этом блоге точка зрения выражает мнение исключительно его автора и может не совпадать с позицией NetApp, Inc.

This content is not endorsed, sponsored or affiliated with NetApp, Inc. The views expressed in this blog are solely those of the author and do not represent the views of NetApp, Inc.