В данном посте я хочу описать шаги для настройки Multipath при помощи dm-multipath. Device Mapper Multipathing (DM-Multipath) позволяет “собрать” несколько маршрутов ввода/вывода между сервером и дисковым массивом в единое целое, и рассматривать доступный по нескольким путям массив как одно мета-устройство. Например, если сервер с двумя двух-портовыми HBA подключен к одному и тому же массиву, то сервер, в самом простейшем случае, будет “видеть” четыре устройства /dev/sd{a,b,c,d}. При помощи dm-multipath можно собрать из них агрегирующее все четыре пути мета-устройство /dev/dm-N, обеспечив прозрачную для операционной системы и приложений конфигурацию, отказоустойчивую в случае выхода из строя HBA, кабеля или коммутатора (если каждый HBA подключен через свой коммутатор).

Я уже писал в блоге об анонсе проекта Russian Fedora. В течение этого месяца в ходе обсуждений инициатива обросла конкретными идеями, и были сделаны первые шаги в их воплощении. Инициатива Russian Fedora распадается на два направления - техническое и организационное. В качестве одного из шагов во втором направлении 20 ноября состоится пресс-конференция, а после нее - встреча с лидером Fedora Project (с 2006 по 2008) Максом Спеваком (Max Spevack). В настоящее время Макс отвечает за стратегию Red Hat по работе с комьюнити. Также на встрече будет проанонсирован ряд конкретных шагов (в том числе в техническом плане), осуществление которых планируется в рамках Russian Fedora, и направленных на то, чтобы сделать Fedora дистрибутивом, подходящим для российских пользователей «из коробки», а также инициативы в плане локализации. На встрече помимо Макса Спивака планируются выступления руководителей Европейского Red Hat и компании VDEL.
О подробностях регистрации на мероприятие читайте на opennet.ru .

В ноябрьском номере журнала “Системный администратор ” выходит моя статья “Создание сервера сетевой установки Fedora/RHEL”.

“Дистрибутив Fedora использует для установки весьма мощную и многофункциональную программу Anaconda, поддерживающую различные режимы работы и сценарии инсталляции. Вместе с рядом других технологий, в частности Spacewalk-сервером, вы можете значительно облегчить процесс развертывания и обслуживания вашей Linux-инфраструктуры.
Однако сегодня мы оставим Spacewalk-сервер в стороне, и рассмотрим, как можно автоматизировать самую начальную стадию жизненного цикла серверов/рабочих станций – их развертывание. При этом в процессе установки мы постараемся обойтись без вмешательства оператора при помощи так называемого сервера сетевой установки.

В начале этого месяца вышла новая версия open source решения для управления Linux-инфраструктурой - Spacewalk . Также обновился основанный на Spacewalk продукт Red Hat Network Satellite Server . К сожалению, планы по поводу возможности установки Spacewalk на Fedora перенесены на следующую версию - 0.4, которая должна появится в середине декабря. Пока что в качестве базовой ОС необходимо использовать Red Hat Enterprise Linux (или CentOS и т.п.). Из нововведений можно отметить новый API, возможность синхронизации серверов Spacewalk между собой, улучшенную систему поиска, исправление более четырех десятков различных ошибок.

Как известно, при использовании существующей сетевой инфраструктуры iSCSI представляет собой недорогую альтернативу FC, а для целей обучения и тестирования вообще не заменим, поскольку, в ряде случаев, можно обойтись без дорогостоящего оборудования. Безусловно, существует и множество “боевых” конфигураций, когда по тем или иным причинам стоит отдать предпочтение iSCSI. В этом посте я хочу кратко описать настройку iSCSI target и iSCSI initiator в Red Hat Enterprise Linux и Fedora. Нужно отметить, что до версии RHEL 5.2 поддержка iSCSI target присутствовала в статусе Technology Preview. Поддержка же iSCSI initiator присутствует в полном объеме еще с Red Hat Enterprise Linux 4.