книги хакеры / журнал хакер / 159_Optimized

Веб-клиентUlteo

$ qemu-kvm -spice port=1234,disable-ticketing \

-hda /путь/до/образа/диска

2. Насторонеклиента:

$ sudo apt-get install spice-client $ spicec -h localhost -p 1234

Для тестирования этого вполне достаточно, но для развертывания сети с десятком-другим клиентов, работающих с разными ОС, гораздо удобнее воспользоваться графическим менеджером виртуальных машин virt-manager. Я не призываю устанавливать на сервер иксы, потому как virt-manager может работать и удаленно, посылая команды демону libvirtd по ssh. Итак, ставим на сервер qemu, libvirt и демон libvirtd:

$ sudo apt-get install bridge-utils dnsmasq \

kvm qemu libvirt libvirt-bin

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

$ sudo /etc/init.d/libvirtd start

Теперь идем на машину с иксами, ставим virt-manager и подключаемся к libvirtd:

$ sudo apt-get install virt-manager

$ virt-manager -c qemu+ssh://root@server.com/system

Нажав на кнопку «Новая», создаем новую виртуальную машину с нужными опциями, производим установку ОС, тестируем. Если имеем дело с UNIX, обязательно устанавливаем видеодрайвер для Spice-сервера xorg-video-qxl, без него большая часть оптимизаций не будет работать. Далее выключаем виртуальную машину, выбираем пункт меню «Вид -> Подробности», нажимаем «Добавить оборудование», выбираем пункт «Graphics», в поле «Тип» указываем «Spice server», указываем нужный номер порта

Нередко в организациях можно встретить приложения, работающие толькоподWinXP—переносихподновыеWin7илиVistaневозможенили нецелесообразен. Даунгрейд ОС также неприемлем, самая банальная причина — нет драйверов под новый ноутбук. Держать отдельный комп лишь для одной древней проги тоже не выход. Технология MED- V (Microsoft Enterprise Desktop Virtualization, clck.ru/WQqT) является неким аналогом реализации VDI, но на клиентской стороне. Одной из основных ее частей является всем известный XP Mode, позволяющий запускатьвиртуальнуюОС(WinXP/Vista)в специальнойредакцииVirtual PC. При этом пользователь даже не заметит «подмены», — вместо окна виртуальной машины он будет работать с «обычным» приложением, запускаемым через меню «Пуск».

ТехнологияApp-V(MicrosoftApplicationVirtualization)даетвозможность преобразовать обычные приложения в виртуальные, причем пользователю не нужно их перед этим устанавливать и настраивать.

Внешнетакоеприложениеработаеткакобычное(еговиднов менеджере задач),новыполняетсяв особойвиртуальнойсреде.Посути,App-V—это удобное средство доставки приложений, работающих в родной среде (в отличиеотMED-V),нетребующеевыделенияподнихотдельногоПКили подключенияк терминальномусервису.Назначениемприложенийможно управлятьприпомощигрупповыхполитик,такжепростои убратьдоступ, не удаляя его физически.

Данные технологии не доступны для Win7 Home/Starter и не входят в стандартную поставку. Чтобы воспользоваться

возможностями MED-V, необходимо установить MDOP (Desktop Optimization Pack, пакет содержит еще ряд полезных решений). Если систем, требующих MED-V, очень много, понадобится развертывание специального сервера управления, хотя MED-V 2.0 и App-V интегрируются с System Center Configuration Manager.

SPICE ПОЗВОЛЯЕТ ПРОБРАСЫВАТЬ ПО СЕТИ НЕ ТОЛЬКО ИЗОБРАЖЕНИЕ РАБОЧЕГО СТОЛА, НО И УСТРОЙСТВА ВВОДА, USB-ПОРТЫ, АУДИОПОТОК

и пароль. Если был установлен драйвер qxl, переходим в раздел «Видео» и в поле «Модель» выбираем qxl. Все, виртуальная машина готова к удаленному подключению по протоколу Spice. Теперь нужно настроить тонкие клиенты так, чтобы они автоматически цеплялись к Spice-серверу после загрузки. Для этого устанавливаем на клиенты любой Linux дистрибутив, содержащий X-сервер из коробки. После установки создаем беспарольного пользователя с любым именем и прописываем ему в автозагрузку следующую команду:

spicec -f -h адрес_сервера -p номер_порта -w пароль

Ее можно поместить либо в файл ~/.xsession пользователя, сразу после слова «exec», либо в скрипт внутри каталога ~/.config/ autostart, чтобы его подхватывала среда рабочего стола. В любом случае после логина пользователя будет стартовать Spice-клиент на полный экран и устанавливать соединение с виртуальной машиной. Чтобы пользователю не приходилось два раза входить (сначала в реальную машину, затем — в виртуальную), лучше настроить автологин.

Для каждого терминала можно создать собственную виртуальную машину, указывая разные порты и пароли Spice в настройках. Сделать это с помощью virt-manager очень просто. Достаточно создать нужное число клонов виртуальной машины («правый клик

мыши на виртуальной машине -> Clone») и немного изменить настройки каждой из них. Само собой разумеется, что при количестве клиентов, превышающем 10-15, одним сервером не обойтись, поэтому в virt-manager есть возможность управления виртуальными машинами на нескольких серверах («Файл Æ Добавить соединение»).

QVD

Проект QVD (Quality Virtual Desktop, theqvd.com) представляет собой масштабируемое, эффективное и простое в управлении VDI с открытым исходным кодом, построенное на базе GNU/Linux и позволяющее запускать VM с одного или нескольких образов ОС на одном узле. Основным направлением развития проекта является обеспечение доступа к VDI как можно большего числа пользователей и минимизация потребления ресурсов для каждой сессии. Шаблонный образ ОС может быть использован несколькими VDI, что позволяет стандартизировать рабочую среду и упростить управление. Состояние VD записывается в отдельный образ (overlays), который по окончании работы может уничтожаться (по умолчанию) или сохраняться. Во втором варианте при следующем подключении клиент сразу продолжит работу с того же места. В настоящее время проект предлагает клиенты для Windows и Linux, на подходе версия для Android.

В настоящее время QVD считается надежной и безопасной средой и используется во многих организациях, в том числе благодаря быстрой окупаемости вложений (Return on Investment, ROI). Например, его выбрал крупнейший банк Мексики BBVA Bancomer.

Основой QVD является технология KVM (Kernel Virtual Machine), клиент для доступа использует протокол NX, обеспечивающий защищенное и стабильное соединение при низкоскоростных подключениях. Авторизация пользователя возможна средствами LDAP. Функционально система состоит из трех компонентов: одного

или нескольких QVD-серверов, сервера управления и сервера PostgreSQL. Чтобы обеспечить максимальную производительность и масштабируемость, они должны располагаться на разных машинах. Разработчиками сообщается, что QVD был развернут на предприятии для обслуживания более 35 000 пользователей и обра-

INFO

•Онастройке

сервератерминалов

вWin2k8читайв][ 09.08;

•подробнееоHyper-

Vчитайвстатье «Гиперактивная виртуальность»,][ 02.09;

•в][11.10ты

найдешьобзор VMwareView4.5;

•вWin2k8R2RDS

умеетназначать динамический/ виртуальный IP-адрескаждому сеансуили приложению,что решаетпроблему привязкикIP;

•технологииTS/RDS

иVDIне взаимоисключают, адополняютдруг друга;

• внастоящеевремя

QVDиспользуется

вкрупнейшембанке МексикиBBVA Bancomer.

WWW

•Наборруководств

отMicrosoftпо развертываниюRDS иVDI:clck.ru/WddP;

•сайтQVD: theqvd.com.

WARNING

Длявозможности удаленного подключения ксессииклиентов

необходимовветке реестраHKEY_LOCAL_ MACHINE\SYSTEM\CurrentControlSet\Control\TerminalServer

установитьзначение параметраAllowRemoteRPC в«1».

ботки до 9 000 одновременных сессий, причем успешно справлялся с работой. Сервер управления обеспечивает подключение клиентов, запуск нужной VM и получение виртуального IP. Состоит из трех компонентов: брокера соединений L7R, демона HKD (House Keeping Daemon), отвечающего за пуск/останов VM и связь с БД, и Node

— элемента управления L7R и HKD. Для хранения данных используется любой NAS/SAN ресурс. Управление и мониторинг работы производятся при помощи веб-интерфейса QVD Web Administration Tool (WAT, написан на Perl Catalyst) или из консоли (qvd-admin).

Доступно несколько версий QVD – свободный Community, платный Commercial и сервис Cloud (на хостинге QVD). Сравнение их функциональности можно найти на сайте.

Проект предоставляет репозиторий пакетов для Ubuntu 10.04 LTS и SLES, а также демообразы для виртуальных машин (на базе Ubuntu 10.10). Но разработчики отмечают, что установить QVD при помощи исходных текстов можно на любом Linux. В Ubuntu 10.04 LTS процесс выглядит довольно просто, вначале следует добавить информацию о новом репозитории:

$ sudo apt-add-repository \

'deb http://theqvd.com/debian lucid main'

$ sudo apt-get update

После обновления в списке появится несколько пакетов qvd-*. Для упрощения изучения разработчики предлагают специальный метапакет, устанавливающий все компоненты на один сервер:

$ sudo apt-get install \

qvd-demo-single-instance-nosupport qvd-admin

Теперь можно подключаться к WAT, который по умолчанию работает на 3000 порту, и приступать к настройкам. Чтобы упростить установку, из поставки убраны все образы ОС, поэтому их придется «готовить» самостоятельно (за плату разработчики предлагают несколько вариантов, в том числе и индивидуальные). Все образы хранятся в четырех подкаталогах /var/lib/qvd/storage (его обычно монтируют через NFS): homes (qcow2 изображения пользовательского /home), images (ОС), overlays (временные файлы) и staging.

ЗАКЛЮЧЕНИЕ

Как ты мог убедиться, идея терминалов и единого вычислительного центра продолжает жить и процветать, заставляя программистов и админов выдумывать все более изощренные методы связи, удовлетворяющие потребностям сегодняшнего дня. z

РАЗВОРАЧИВАЕМ

ОТКАЗОУСТОЙЧИВЫЙ СЕРВИСХРАНЕНИЯ ДАННЫХНАБАЗЕ SAMBA

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

Странички,посвященныепроектуCTDB

ВВЕДЕНИЕ

В этой статье мы рассмотрим процесс создания высоконадежного файлового хранилища, реализованного на безе двух типичных серверов, операционной системы GNU/Linux и сервера Samba.

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

ТЕОРИЯ

В обычной ситуации файловый сервис на основе Samba выглядит как машина, оснащенная достаточно емким жестким диском, на которую установлен дистрибутив Linux и пакет программ Samba, отвечающих за обслуживание клиентских запросов на доступ к ресурсам. Изъян такой конфигурации в том, что выход из строя жесткого диска моментально обрушит весь сервис и оставит клиентов без хранилища данных.

Понятно, что для решения этой проблемы следует в обязательном порядке применять RAID1-массив, который позволит сохранить данные и работоспособность сервиса, даже если один из дисков умрет. Это типичная конфигурация, которая, тем не менее, не спасет от смерти самого сервера или одной из его железяк. В этом случае данные все равно окажутся недоступны.

Чтобы избежать и этой ситуации, можно собрать мини-кластер из нескольких машин, данные с жестких дисков которых будут зеркалироваться по сети c помощью драйвера DRBD и специальной параллельной файловой системы. Но и здесь есть загвоздка: если мы просто установим на оба этих узла Samba, то легко получим несогласованность файловой системы, видимой удаленным пользователям.

Для отображения семантики файловой системы UNIX в CIFS и поддержки своего состояния Samba использует легковесные базы данных, называемые TDB, которые содержат такие данные как таблица соответствия Windows SID и Unix UID/GID, данные об открытых сессиях, таблицу блокировок и так далее. Если два

экземпляра Samba будут работать с одним общим хранилищем, но иметь разные таблицы TDB, это приведет к весьма печальным последствиям с первых же минут запуска сервиса.

Но и этой проблемы можно избежать, воспользовавшись демоном CTDB (Cluster TDB), который будет хранить единую базу данных для нескольких экземпляров Samba и следить за ее соответствием реальному положению дел. В качестве бонуса CTDB также будет выполнять функции мониторинга и автоматического отключения нерабочих узлов от кластера, что избавит нас от необходимости использования сторонних инструментов.

Итого для настройки высоконадежного файлового сервиса Samba нам необходимо следующее.

1.Обзавестисьдвумясерверами,вкаждомизкоторыхустановлено двадискаидвесетевыекарты.

2.НастроитьсетевойRAID1междуними.

3.ПоднятьпараллельнуюФСнаRAID1-массиве.

4.УстановитьинастроитьнакаждомузлеSamba.

5.ПоднятьCTDBдлярасшариванияданныхосостояниимежду демонамиSamba.

Такой вот многослойный пирог, приготовлением которого мы и займемся прямо сейчас.

НАСТРОЙКА ХРАНИЛИЩА

Итак, у нас есть два сервера, каждый из которых оснащен двумя жесткими дисками. На /dev/sda стоит операционная система

(я буду использовать Debian), /dev/sdb отведен для хранения данных Samba. Можно использовать и один диск, но такая конфигурация будет менее производительной и удобной в сопровождении.

Наша первоочередная задача — объединить жесткие диски двух машин в массив RAID1. Сделать это по сети можно с помощью драйвера DRBD и кроссовер-кабеля, соединяющего серверы напрямую через одну из двух сетевых карт. Это позволит создать мост для быстрого обмена данными между машинами, в то время как клиенты будут получать доступ к кластеру с помощью другого, внешнего сетевого интерфейса.

Чтобы не путаться, сразу определимся, что 10.0.0.1 и 10.0.0.2

— это внутренние IP-адреса, объединяющие серверы с помощью кроссовер-кабеля, а 192.168.0.1 и 192.168.0.2 — это внешние адреса, по которым будет происходить обмен сервисными данными и которые будут видны клиентам (на самом деле все несколько сложнее, но об этом позже).

После настройки IP-адресов выполняем на каждой машине следующую команду:

# apt-get install drbd8-utils

Далее на одной из машин создаем файл /etc/drbd.conf и пишем в него следующее:

# vi /etc/drbd.conf

global { usage-count no; }

common { syncer { rate 100M; } }

ЕвгенийЗобнин

КакработаетDRBD

resource r0 { protocol C;

startup {

wfc-timeout 15;

degr-wfc-timeout 60;

}

net {

#Настройки двухголовой конфигурации (primary/primary) allow-two-primaries;

after-sb-0pri discard-zero-changes; after-sb-1pri consensus; after-sb-2pri disconnect;

#Пароль и метод шифрования

shared-secret "ПАРОЛЬ";

cram-hmac-alg sha1;

}

#Первый узел on node1 {

device /dev/drbd0; disk /dev/sdb; address 10.0.0.1:7788; meta-disk internal;

}

#Второй узел

on node2 {

СОБИРАЕММИНИ-КЛАСТЕРИЗ НЕСКОЛЬКИХМАШИН,ДАННЫЕС ЖЕСТКИХДИСКОВКОТОРЫХБУДУТ ЗЕРКАЛИРОВАТЬСЯПОСЕТИ

device /dev/drbd0;

disk /dev/sdb;

address 10.0.0.2:7788;

meta-disk internal;

}

}

Главное здесь — это пароль, используемый для доступа к массиву, а также два последних блока, описывающих диски массива. Они могут иметь произвольные имена, однако поля должны содержать актуальные данные для каждого из хостов. Опция «disk» задает блочное устройство, которое станет частью массива, опция «address» — внутренний IP-адрес узла и порт DRDB. Файл необходимо скопировать на второй узел в неизменном виде.

Теперь инициализируем массив, выполнив на обоих узлах команду:

# drbdadm create-md r0

Далее стартуем сервис drbd (опять же на обоих узлах):

# /etc/init.d/drbd start

На одном из узлов выполняем следующую команду, которая сделает оба узла главными, то есть позволит монтировать DRBDдевайс с обеих нод:

# drbdsetup /dev/drbd0 primary -o

После этого должна начаться синхронизация, за ходом которой можно следить, читая файл /proc/drbd:

# cat /proc/drbd

После окончания синхронизации на массиве можно создать

файловую систему. Стандартная ФС не подойдет, так как не сможет обеспечить соответствие метаданных при одновременном доступе к ФС с разных узлов. Поэтому нам нужна параллельная файловая система (также называемая кластерной), на роль которой отлично подойдет OCFS2 от Oracle (хотя можно использовать и любую другую, например GFS2).

Код OCFS2 есть в ядре, поэтому все, что требуется установить, это утилиты управления:

# apt-get install ocfs2-tools

Конфиг файловой системы хранится в /etc/ocfs2/cluster.conf. В нашей конфигурации он должен иметь примерно следующий вид:

# vi /etc/ocfs2/cluster.conf

cluster:

node_count = 2

name = ocfs2

node:

ip_port = 7777

ip_address = 192.168.0.1

number = 1

name = node1.cluster.local

cluster = ocfs2

node:

ip_port = 7777

ip_address = 192.168.0.2

number = 2

name = node2.cluster.local

cluster = ocfs2

Этот конфиг описывает кластер с именем ocfs2 и двумя нодами: node1.cluster.local и node2.cluster.local. Имена нод должны совпадать с именами хостов, поэтому необходимо заранее позаботиться о привязке имен хостов к IP-адресам в файле /etc/hosts обоих узлов. Имя кластера менять не стоит, так как загрузочные скрипты по умолчанию будут инициализировать кластер «ocfs2» и не смогут завершить этот процесс, если имя будет другим. Обрати внимание, что в этот раз мы используем внешние IP-адреса.

Копируем конфиг на оба узла и запускаем службу o2cb:

# /etc/init.d/o2cb start

Теперь можно создать файловую систему на DRBD-устройстве. Сделать это можно с любого узла:

# mkfs.ocfs2 -L "ocfs2" /dev/drbd0

ПроизводительностьCTDB-кластерарастетпропорциональноколичествуузлов

Далее ФС можно смонтировать (здесь и далее я буду использовать каталог /samba в качестве точки монтирования и корня для Samba):

#mkdir /samba

#echo "/dev/drbd0 /samba ocfs2 noatime 0 0" >> /etc/fstab

#mount /dev/drbd0

Сделать это необходимо на обоих узлах. Чтобы избежать возможных проблем в будущем, проверь работоспособность кластера и корректность настроек с помощью копирования файлов и каталогов в файловую систему. При правильной настройке содержимое ФС должно выглядеть идентично на обоих узлах.

ЗАПУСК SAMBA

Если в работе файловой системы не возникает проблем, то можно переходить к установке и настройке Samba. Главное здесь, как я уже говорил, демон CTDB, поэтому мы остановимся на очень простом конфиге Samba, а ее кластерную составляющую рассмотрим более подробно.

Итак, наш конфиг Samba будет выглядеть примерно так:

[global]

clustering = yes

idmap backend = tdb2

private dir=/samba/ctdb fileid:mapping = fsid

vfs objects = fileid

[public]

comment = public share

path = /samba/public

public = yes writeable = yes

only guest = yes

Это простейший пример файла /etc/samba/smb.conf с одной публичной «шарой», а также приватным каталогом /samba/ctdb для хранения данных демона CTDB. Фактически, только первые три строки необходимы для работы самбы в кластерном варианте, остальное — просто оптимизация для работы с OCFS2 и описание сетевого диска. Каталоги, естественно, необходимо создать заранее:

#mkdir /samba/ctdb

#mkdir /samba/public

#chmod 777 /samba/public

Инициализируем базу паролей:

# smbpasswd -a root

Проверяемсостояниекластера

Далее устанавливаем самбу на оба узла и копируем на них вышеприведенный конфиг. В качестве окончательного штриха устанавливаем и настраиваем CTDB на обоих узлах:

# apt-get install ctdb

Сам демон не имеет конфигурационного файла, но, тем не менее, требует настройки с помощью скриптов инициализации и закрепленных за ними конфигов. В Fedora/RedHat это /etc/

sysconfig/ctdb, в Debian/Ubuntu — /etc/default/ctdb. Файл необходимо отредактировать на обоих узлах:

#Местонахождение lock-файла мастера восстановления

CTDB_RECOVERY_LOCK="/samba/ctdb/lock"

#Публичный сетевой интерфейс, используемый для

#обмена данными

CTDB_PUBLIC_INTERFACE=eth0

#Список адресов, по которым будет доступен кластер

CTDB_PUBLIC_ADDRESSES=/etc/ctdb/public_addresses

#Перекладываем работу по запуску Samba на CTDB CTDB_MANAGES_SAMBA=yes

#Список CTDB-узлов

CTDB_NODES=/etc/ctdb/nodes

# Куда писать логи

CTDB_LOGFILE=/var/log/log.ctdb

Далее создаем файл /etc/ctdb/nodes и добавляем в него IPадреса узлов Samba, то есть наши два сервера:

192.168.0.1/24

192.168.0.2/24

Также создаем файл /etc/ctdb/public_addresses с еще двумя IP-адресами:

192.168.0.3/24

192.168.0.4/24

Эти адреса должны отличаться от публичных адресов, но находиться в той же подсети. Они будут автоматически назначены узлам кластера в качестве дополнительных IP-адресов, по которым и будет происходить подключение клиентов. Это нужно для автоматического поддержания работоспособности кластера. Если один из узлов выйдет из строя, CTDB автоматически присвоит его IP-адрес другому узлу, и клиенты будут работать, как ни в чем не бывало.

Этих настроек должно быть достаточно. Запускаем CTDB на обоих узлах:

# /etc/init.d/ctdb start

Если он работает нормально, то команда «ctdb status» вернет что-то вроде этого:

Number of nodes:2

pnn:0 192.168.0.1 OK (THIS NODE)

ЧТОБЫ ВОВРЕМЯ РЕАГИРОВАТЬ НА ПАДЕНИЕ УЗЛОВ, СЛЕДУЕТ ПРИМЕНЯТЬ РАЗЛИЧНЫЕ МЕТОДЫ МОНИТОРИНГА

Generation:1362679229

Size:2

hash:0 lmaster:0

hash:1 lmaster:1

Recovery mode:NORMAL (0)

Recovery master:0

Также для проверки соединения можно устроить пинг CTDBхостов:

# ctdb ping -n all

response from 0 time=0.000064 sec (3 clients)

response from 1 time=0.000087 sec (9 clients)

Наконец запускаем демон Samba:

# /etc/init.d/samba start

Если при конфигурировании не было допущено ошибок, кластер уже должен быть готов к подключению клиентов. Со стороны Windows-клиентов кластер должен выглядеть как единое целое, то есть как один сервер хранения. В большинстве сред рабочего стола для UNIX картина будет та же. Однако если потребуется смонтировать «диск» из командной строки, придется указать один из публичных IP-адресов, прописанных в /etc/ctdb/public_addresses:

#mount -t cifs //192.168.0.3/public \ /mnt/samba -o user=ЮЗЕР

#smbclient //192.168.0.4/public

Не важно, какой из адресов использовать, — как я уже говорил, они оба будут доступны ровно до тех пор, пока в строю будет находиться хотя бы один сервер.

МОНИТОРИНГ И ВОССТАНОВЛЕНИЕ

Просто собрать кластер – только начало, гораздо труднее заниматься слежением за его состоянием и предотвращать отказы. К счастью, наша конфигурация всячески этому способствует и требует вмешательства, как правило, только на уровне решения железных проблем, — остальные проблемы будут решены софтом самостоятельно. Как это работает? Представим себе ситуацию, когда один из узлов кластера выходит из строя. Как ведет себя система в этом случае? Первым под удар попадает наше DRBD-устройство, но благодаря режиму master/master смерть одного из узлов никак не отразится на функциональности другого. Поэтому недоступное устройство просто отключается, а второй сервер продолжает функционировать. Второй компонент, реагирующий на смерть узла, это файловая система OCFS2. Но и здесь все заканчивается достаточно благополучно благодаря встроенному механизму фенсинга (fencing), который просто отключает недоступную ноду от кластера и восстанавливает консистентность файловой системы с помощью отката незавершенных операций над файлами, проделанными со сбойного узла. При этом сам сбойный узел отправляется в перезагрузку (если, конечно, он не умер окончательно). Следующим о смерти узла узнает демон CTDB, работающий на живом узле. Однако, в отличие от двух предыдущих компонентов пирамиды, он поступает гораздо умнее. Он помечает мертвый узел флагом UNHEALTHY или DISCONNECTED, назначает его IP-адрес другому узлу и посылает всем его клиентам TCP-пакет с нулевым номером последовательности. Это вынуждает клиентов переустановить соединение с узлом, благодаря чему они автоматически перебрасываются на живой узел, даже не заметив подмены. Сам протокол CIFS позволяет выполнить такой трюк, в результате чего задержка в обслуживании для клиентов составляет всего несколько секунд. Что делать в такой ситуации админу?

ПравимконфигDRBD

Да в общем-то ничего. Если сервер упал из-за ошибок в ПО или каких-то непреднамеренных действий со стороны третьих лиц (пропало питание, не сработал UPS и так далее), то после перезагрузки узел восстановит свое состояние автоматически. То же самое справедливо и в отношении поломки одного из внутренних компонентов сервера. Если же умер сам жесткий диск, то после его замены сервер достаточно просто ввести в строй. В большинстве случаев для этого понадобится выполнить всего две команды:

#drbdadm create-md r0

#drbdadm attach r0

Затем начнется синхронизация массива, по окончании которой можно вновь смонтировать раздел и перезапустить самбу и CTDB:

#mount /dev/drbd0

#/etc/init.d/ctdb restart

#/etc/init.d/samba restart

Чтобы быть в курсе событий и вовремя реагировать на падение узлов, следует применять различные методы мониторинга, это может быть что угодно, начиная банальным пингом по крону и заканчивая специализированными система типа monit. Мы уже не раз писали в ][ о мониторинге, поэтому я не буду рассказывать об этом подробно. Кстати, отслеживать ситуации с проблемами в работе CTDB очень просто с помощью скрипта /etc/ctdb/notify.sh, который выполняется в тех случаях, когда появляются проблемы в работе узла, и он отключается от CTDB-кластера. Прописать в скрипт можно все что угодно, — например, отправку письма админу:

# vi /etc/ctdb/notify.sh

event="$1"

shift

case $event in unhealthy)