СОДЕРЖАНИЕ Модуль ду Резервное р копирование р Копирование данных с продакшен-сервера на backup-сервер Перекрестное копирование данных Системы хранения данных Другие носители данных Виды бекапа Схемы ротации бекапов 10 Методы резервирования баз данных .10 RAID – Redundant Array of Independent Disks 11 Типы RAID-массивов 11 Уровни RAID-массивов 12 RAID (Striped Disk Array without Fault Tolerance) .12 RAID (Mirroring & Duplexing) 12 RAID (Independent Data Disks with Distributed Parity Blocks) .13 RAID 1+0 (Very High Reliability with High Performance) Performance) 13 13 RAID 5+0 (High I/O Rates & Data Transfer Performance) .14 Storage Area Networkk 14 14 Network Attached Storage .15 Direct Attached Storage 16 Самописный скрипт использующий атрибут mtime файлов .17 файлов 17 Rsync 19 Зеркалируем разделы 21 Amanda 22 Модуль ду Сетевой интерфейс рф Linux Какие файлы влияют на работу сетевого интерфейса интерфейса 30 30 DHCP iface 31 Loopback iface 32 Custom iface 32 Практика .33 Маршрутизация 35 Прописываем маршруты 36 Про шлюз 38 Полезные ключи netstat 38 NMAP 40 tcpdump 41 Модуль ду TFTP Установка .42 Работа с TFTP .42 Типы пакета 43 Режимы передачи 43 Коды ошибок 43 Клиент tftp .44 Модуль ду NFS Установка .45 Настройка 46 Опции конфигурационного файла 47 Дополнительная информация .48 Модуль ду Install-сервер р р Принцип работы 49 DHCP 50 TFTP 51 Syslinux 51 NFS 51 Создаем структуру tftp-сервера добавляем контент на сервер 52 Устанавливаем ОС по сети .52 Автоматизация установки с помощью Kickstart 53 Диагностика 55 Модуль ду Виртуализация р у ц Xen Что это такое ? 56 Зачем это нужно ? .56 Типы виртуализации 56 Архитектура Xen 58 Причины по которым стоит использовать виртуализацию 58 Настраиваем сервер виртуализации 58 Установка Xen .59 Создание новых виртуальных машин в Xen 60 Работа с виртуальными машинами 61 Производительность виртуальных машин 62 Модуль ду Subversion Архитектура Subversion 63 Протоколы работы с SVN 64 Способы хранения данных 64 Компоненты Subversion 64 Проблема одновременной работы с файлами 64 Рабочий цикл 66 Установка .66 Работаем с репозиторием 66 Получение копии репозитария с удаленного сервера где у вас есть аккаунт 68 Ограничение доступа .69 Работа через Proxy .72 Модуль ду Apache p Об Apache 73 Установка .73 Настройка 74 Добавляем виртуальный хост 82 Возможные опции в директиве Options 84 Определение возможных директив в htaccess 85 Аутентификация на сайте .86 Включение SSL .87 Server-status и server-info 90 SSI .91 Использование mod_rewrite 91 Регулярные выражения mod_rewrite и флаги 93 Коды веб-сервера 94 Модуль ду SAMBA Что такое SAMBA и зачем она нужна ? 104 Возможности SAMBA 104 Установка 104 Типы аутентификации 104 Ключевые файлы 105 Структура конфигурационного файла 106 Пример конфигурационного файла 106 Описание конфигурационного файла 107 SWAT – веб-интерфейс к SAMBA 111 Модуль ду 10 DHCPD Принцип работы 112 Установка DHCPD 113 Настройка DHCPD 113 Описание опций из dhcpd.conf dhcpd.conf f 114 Секции-объявления 116 Типы пакетов протокола DHCP 119 Используемые порты 119 DHCP-клиент 119 Модуль ду 11 MySQL y Q Принцип работы 121 Пример роли MySQL в информационном пространстве 122 Типы данных 122 Сколько нужно места под хранение типа данных ? 124 Практика 125 Файл как источник запросов 130 Пользователи и привелегии 132 Саммари по командам и принципу работы 133 Конфигурационный файл my.cnf 134 Забытый пароль администратора 136 Резервное копирование 136 Проверка целостности таблиц с помощью myisamchkk 137 Саммари по myisamchkk 138 Модуль ду 12 Мониторинг р О Nagios 139 Установка и настройка Nagios 140 Добавление хостов и сервисов на мониторинг 166 Мониторинг различных параметров сервера 167 Мониторинг свободного места 167 Защита системы от пользовательских процессов 168 Мониторинг S.M.A.R.T - параметров жесткого диска 168 Мониторинг сетевых портов в Linux 169 Мониторинг открытых файлов и сокетов 169 Мониторинг запущенных процессов 170 Мониторинг системных ресурсов 170 Мониторинг свободного места в разделах 170 Мониторинг сетевой подсистемы в реальном времени 171 Мониторинг работы DNS-сервера в реальном времени 171 Мониторинг соединений proftpd в реальном времени времени 172 Статистика по виртуальной памяти 172 Статистика по процессору и устройствам ввода-вывода 172 Модуль ду 13 DNS Установка 173 Инструменты 173 Базовые понятия 174 Правила построения DNS-системы 174 Режимы работы ДНС-серверов 175 Типы ответов DNS-серверов 177 Виды запросов к DNS-серверу 177 Способы копирования зоны с master-сервера 177 Виды записей 179 Структура конфигурационного файла 181 Настройка 182 Опции конфигурационного файла 186 Slave-сервер 187 Записи в /etc/resolv.conff 190 Статистика работы 190 Модуль ду 14 Nginx g Что такое Nginx ? 192 Преимущества Nginx 192 Варианты использования Nginx 192 Установка EPEL 193 Ставим EPEL-пакет 193 Установка Nginx с поддержкой PHP Настраиваем связку Nginx + FastCGI FastCGI 194 Конфигурирование Nginx + FastCGI 195 Понижаем нагрузку на основной веб-сервер Установка Nginx как Frontend к Apache 198 Установка mod_rpaff 201 Включение SSL 202 Использование двух версий PHP в Nginx одновременно 203 Примеры производительности с Nginx и без него 204 205 Описание директив конфигурационного файла файла Модуль ду 15 Postfix Установка и настройка 210 Postfix 210 MySQL 216 Dovecot 217 Clamd 220 ClamSMTP 221 Spamassassin 221 Postfixadmin 224 Squirrelmail 225 Описание конфигурационных файлов 226 Postfix 226 Dovecot 229 Clamd 230 Clamsmtp 231 Spamassassin 232 Модуль ду 16 OpenVPN p Об OpenVPN 234 Установка Linux VPN-сервера 234 Настройка Linux VPN-сервера 235 Linux VPN-клиент 240 Windows VPN-клиент 242 Добавление клиентов 243 Таблица предназначения ключей и сертификатов 243 Конфигурационный файл openvpn.conf на Linux VPN-сервере 243 Конфигурационный файл client.conf на Linux-клиентах 246 Конфигурационный файл client.ovpn на Windows-клиенте 247 Модуль ду 17 Отказоустойчивый у кластер р Что такое кластер ? 248 Принцип работы нашего кластера 248 DRBD 249 Программы входщие в состав пакета DRBD 250 Heartbeat 251 Именование серверов 251 Установка ПО 251 Настройка DRBD 252 Настройка Heartbeat 257 Установка Apache 259 Модуль Резервное копирование Процедура бекапа или резервного копирования очень проста, но может стать большой головной болью если её не делать Бизнес многих компаний напрямую зависит от манипуляций с информацией которая хранится на серверах Базы данных, репозитории исходных кодов, веб-проекты и т.д Все это нужно ежедневно сохранять на резервные носители информации В случае потери информации и её невозможности восстановить компания может понести большие убытки В этом модуле мы рассмотрим несколько вариантов резервного копирования, от самописных скриптов до промышленных решений и получим необходимую теорию Во первых, есть несколько схем резервного копирования Копирование данных с продакшен-сервера на backup-сервер Продакшен-сервер – это рабочий сервер, который выполняет какие либо сервисы для пользователей backup-сервер – это сервер на который копируется контент с продакшенсервера Единственное предназначение такого сервера – хранить данные с других серверов Обычно сам он никаких сервисов не выполняет Главное требование – большое дисковое пространство Скорость дисковых накопителей особого значения не имеет, так как доступ к данным не частый – записать бекап на диск и считать его в случае необходимости Минус этого решения – необходимость в отдельном сервере под backup`ы а это дополнительные затраты Маленькие и средние компании обычно пытаются сэкономить деньги на покупке вспомогательного оборудования Перекрестное копирование данных Когда два или более продакшен серверов копируют друг на друга свои данные В случае когда на продакшен серверах есть достаточное количество дискового пространства для хранение данных с других серверов, их можно использовать как backup-серверы Мы копируем данные с сервера server1 на server2 а данные с server2 на server1 Плюс – экономим деньги на оборудование Как я писал выше маленькие и средние организации могут не выделить деньги на вспомогательное оборудование, даже если это необходимо под резервные копии В таком случае вам может помочь такой способ бекапа Модуль Резервное копирование Системы хранения данных “Классические” сервера для хранения бекапов хороши при относительно небольших объемах Сейчас это несколько сотен гигабайт Когда же объемы гораздо больше на помощь приходят СХД, Системы Хранения Данных Дисковые массивы Д По сути такой же сервер, но спроектирован специально под хранение данных Имеет много HDD большего размера Дисковый массив Sun Storage J4500 Масштабируемость – от 24 до 192 Тб Поддерживаемые ОС: Solaris, RedHat, Suse, Windows Ленточные накопители Они же стримеры Данные как и в случае с ленточными библиотеками записываются на специальные картриджи Как правило, картридж – это магнитная лента в пластиковом корпусе Ленточный накопитель HP StorageWorks DAT 160 SAS Картридж для HP StorageWorks DAT 160 SAS 160 Гб Модуль Резервное копирование Ленточные библиотеки Предназначены для автоматизированного резервного копирования данных Одновременное использование нескольких лентопротяжных механизмов увеличивает производительность библиотеки и сокращает время, необходимое для записи и чтения резервных копий Одно из самых серьезных решений SUN Ленточная библиотека Sun StorageTek SL8500 До 56 петабайт данных До 70 тысяч картриджей Другие носители данных optical disc (CD-R/RW, DVD-R/RW); flash-накопители; ZIP, Jaz, MO драйвы Виды бекапа Полное – все файлы и каталоги которые мы хотим сохранять на отдельном носителе Инкрементальное – копируем только то, что изменилось с момента последнего резервного копирования Полного или инкрементального Дифференциальное – копируем только то, что изменялось с момента последнего ПОЛНОГО бекапа Пофайловый метод – копируем нужные файлы в индивидуальном порядке Дублирование диска – метод при котором мы делаем полный снимок диска Например утилитой dd Модуль Резервное копирование Схемы ротации бекапов Ротация – это политика по которой делается резервное копирование Как часто мы будем делать бекап, как долго мы будем хранить резервные копии Все это описывается политикой ротации Одноразовое копирование – администратор делает копирование вручную Обычно делается полный бекап данных Простая ротация – подразумевается, что некий набор носителей используется циклически К примеру ленточных носителей на каждый день недели В пятницу мы делаем полный бекап данных а в остальные дни недели инкрементальный “Дед, отец, сын” (GFS) – имеет иерархическую структуру ротации Используется три набора носителей Раз в неделю делается полной бекап данных В остальные дни недели – инкрементальный Раз в месяц делается еще один полный бекап системы Набор носителей для ежедневного инкрементального копирования – сын, набор для еженедельного полного бекапа – отец, набор для ежемесячного полного бекапа – дед “Ханойская башня” – название пошло от древней китайской игры Смысл игры заключается в следующем Есть три стержня и какой-то набор дисков Диски нужно перемещать со стержня на стержень, но так, чтобы каждый новый диск ложился на диск большего диаметра Такой метод бекапа достаточно сложен и практически не применяется в настоящее время “10 наборов” – метод рассчитан на 10 наборов носителей Период из 40 недель делится на десять циклов В течение цикла за каждым набором закреплен один день недели По прошествии четырехнедельного цикла осуществляется сдвиг номера набора То есть в первом цикле за понедельник отвечал набор N1, за вторник N2, за среду N3 и т.д Во втором цикле за понедельник будет отвечать набор N2, за вторник N3, за среду N4 и т.д Такая схема позволяет равномерно распределить нагрузку между носителями но из-за своей сложности практически не используется Методы резервирования баз данных hot backup – горячий бекап базы данных Это когда резервная копия делается при включенном сервере БД cold backup – холодный бекап базы данных Это когда сервер БД нужно выключить чтобы сделать резервную копию 10 Модуль Резервное копирование Не обращайте внимание на сообщения “not found” [root@node1 ~]# service drbd start После запуска DRBD на первичной ноде она перейдет в режим ожидания вторичной, и не запуститься пока не получит от нее отклик *************************************************************** DRBD's startup script waits for the peer node(s) to appear - In case this node was already a degraded cluster before the reboot the timeout is seconds [degr-wfc-timeout] - If the peer was available before the reboot the timeout will expire after seconds [wfc-timeout] (These values are for resource 'r0'; sec -> wait forever) To abort waiting enter 'yes' [ 58]: [root@node2 ~]# service drbd start [root@node1 ~]# cat /proc/drbd version: 8.0.13 (api:86/proto:86) GIT-hash: ee3ad77563d2e87171a3da17cc002ddfd1677dbe build by buildsvn@c5-i386build, 2008-10-02 13:31:44 0: cs:Connected st:Secondary/Secondary ds:Inconsistent/Inconsistent C r ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 resync: used:0/61 hits:0 misses:0 starving:0 dirty:0 changed:0 act_log: used:0/127 hits:0 misses:0 starving:0 dirty:0 changed:0 Если видим строку 0: cs:Connected st:Secondary/Secondary ds:Inconsistent/Inconsistent C r - то все хорошо, продолжаем st: означает статус, обе ноды в secondary режиме, нам необходимо node1 перевести в primary, делается это вот такой командой: [root@node1 ~]# drbdadm overwrite-data-of-peer primary r0 После этого начнется процесс синхронизации нод Запустив 'watch cat /proc/drbd' на отдельной консоли можем в реальном времени наблюдать за процессом синхронизации наших разделов [root@node1 ~]# watch cat /proc/drbd 254 Модуль 17 Отказоустойчивый кластер Every 2.0s: cat /proc/drbd Sun Apr 26 20:04:58 2009 version: 8.0.13 (api:86/proto:86) GIT-hash: ee3ad77563d2e87171a3da17cc002ddfd1677dbe build by buildsvn@c5-i386build, 2008-10-02 13:31:44 0: cs:SyncSource st:Primary/Secondary ds:UpToDate/Inconsistent C r ns:1936384 nr:0 dw:0 dr:1936384 al:0 bm:118 lo:0 pe:0 ua:0 ap:0 [===> ] sync'ed: 23.1% (6300/8191)M finish: 0:09:28 speed: 11,304 (10,244) K/sec resync: used:0/61 hits:120905 misses:119 starving:0 dirty:0 changed:119 act_log: used:0/127 hits:0 misses:0 starving:0 dirty:0 changed:0 После завершения синхронизации убедимся, что статус устройства изменился [root@node1 ~]# cat /proc/drbd version: 8.0.13 (api:86/proto:86) GIT-hash: ee3ad77563d2e87171a3da17cc002ddfd1677dbe build by buildsvn@c5-i386build, 2008-10-02 13:31:44 0: cs:Connected st:Primary/Secondary ds:UpToDate/UpToDate C r ns:8388316 nr:0 dw:0 dr:8388316 al:0 bm:512 lo:0 pe:0 ua:0 ap:0 resync: used:0/61 hits:523758 misses:512 starving:0 dirty:0 changed:512 act_log: used:0/127 hits:0 misses:0 starving:0 dirty:0 changed:0 Также, статус можно посмотреть с помощью команды drbdadm [root@node1 ~]# drbdadm dstate r0 UpToDate/UpToDate [root@node2 ~]# drbdadm dstate r0 UpToDate/UpToDate Ресурс полностью синхронизирован и готов к работе! Создаем файловую систему на нашем диске [root@node1 ~]# mkfs -t ext3 /dev/drbd0 Создаем точку монтирования для нашего диска [root@node1 ~]# mkdir /mnt/drbd0 Монтируем диск [root@node1 ~]# mount /dev/drbd0 /mnt/drbd0/ Модуль 17 Отказоустойчивый кластер 255 Запросив статус DRBD мы можем выяснить смонтировано ли устройство или нет [root@node1 ~]# service drbd status drbd driver loaded OK; device status: version: 8.0.13 (api:86/proto:86) GIT-hash: ee3ad77563d2e87171a3da17cc002ddfd1677dbe build by buildsvn@c5-i386build, 2008-10-02 13:31:44 m:res cs st ds p mounted fstype 0:r0 Connected Primary/Secondary UpToDate/UpToDate C /mnt/drbd0 ext3 Ну а теперь давайте поработаем с нашей файловой системой Создадим файл [root@node1 ~]# echo ‘test content’ > /mnt/drbd0/testfile Итак, мы установили DRBD, настроили, синхронизировали ноды, сделали node1 primary node, создали там контент Нам только осталось выяснить происходит ли репликация, в случае выхода из строя primary node сможет ли secondary продолжить работу? Для того чтобы это выяснить делаем следующее Отмонтируем устройство [root@node1 ~]# umount /mnt/drbd0/ Понижаем роль node1 до вторичной ноды [root@node1 ~]# drbdadm secondary r0 Повышаем роль node2 до первичной ноды [root@node2 ~]# drbdadm primary r0 Создаем директорию куда мы будем монтировать устройство Очевидно раз программное обеспечение на обеих нодах будет выполнять одну работу с одними файлами конфигурации то расположение контента должно быть идентичным 256 Модуль 17 Отказоустойчивый кластер [root@node2 ~]# mkdir /mnt/drbd0 Монтируем устройство [root@node2 ~]# mount /dev/drbd0 /mnt/drbd0 Проверяем статус, как мы видим устройство успешно примонтировано [root@node2 ~]# service drbd status drbd driver loaded OK; device status: version: 8.0.13 (api:86/proto:86) GIT-hash: ee3ad77563d2e87171a3da17cc002ddfd1677dbe build by buildsvn@c5-i386build, 2008-10-02 13:31:44 m:res cs st ds p mounted fstype 0:r0 Connected Primary/Secondary UpToDate/UpToDate C /mnt/drbd0 ext3 Ну что там в нашем файле ? :) [root@node2 ~]# cat /mnt/drbd0/testfile test content Волшебство, весь контент в самом свежем виде присутствует на node2 Все функционирует должным образом Теперь вернем обратно роль первичного сервера node1 и продолжим настройку кластера, будем настраивать Heartbeat [root@node2 ~]# umount /mnt/drbd0/ [root@node2 ~]# drbdadm secondary r0 [root@node1 ~]# drbdadm primary r0 [root@node1 ~]# mount /dev/drbd0 /mnt/drbd0 Активность DRBD можно наблюдать в log-файле [root@node1 ~]# cat /var/log/messages Настройка Heartbeat Файлы конфигурации Heartbeat на обеих нодах должны быть идентичными Копируем шаблоны файлов конфигурации в /etc/ha.d/ # cp /usr/share/doc/heartbeat-2.1.3/{ha.cf,authkeys,haresources} /etc/ha.d/ Конфигурационные файлы Heartbeat Модуль 17 Отказоустойчивый кластер 257 ha.cf haresources authkeys Главный конфигурационный файл; Файл ресурсов; Файл аутентификации Необходимо убедиться, что название нод указанное в конфигурационных файлах соответствует содержимому команды uname -n [root@node1 ~]# uname -n node1.company.ru [root@node2 ~]# uname -n node2.company.ru Конфигурационный ф ур ц файл ф /etc/ha.d/authkeys y В файле конфигурации мы выбираем режим аутентификации и указываем секретную фразу по которой она будет происходить Секретная фраза должна быть одинаковой на обеих нодах Далее на этот файл необходимо установить право на чтение только пользователю root, для этого выполните команду chmod указанную ниже Рекомендуется использовать sha1 как в примере auth 2 sha1 NoOneKnowsIt # chmod 600 /etc/ha.d/authkeys Конфигурационный ф ур ц файл ф /etc/ha.d/ha.cf Это главный конфигурационный файл и поведение Heartbeat задается здесь logfacility local0 keepalive deadtime 30 initdead 120 bcast eth0 auto_failback on node node1.company.ru node node2.company.ru respawn hacluster /usr/lib/heartbeat/ipfail use_logd yes logfile /var/log/ha.log debugfile /var/log/ha-debug.log После того, как файл конфигурации готов создадим log-файлы 258 Модуль 17 Отказоустойчивый кластер # touch /var/log/{ha.log,ha-debug.log} Конфигурационный ф ур ц файл ф /etc/ha.d/haresources В этом файле описываются наши ресурсы для управления с помощью Heartbeat node1.company.ru IPaddr::192.168.146.140/24 drbddisk::r0 \ Filesystem::/dev/drbd0::/mnt/drbd0::ext3::defaults httpd Содержимое файла можно прочитать вот так: При старте Heartbeat, node1 будет primary node с shared IP-адресом 192.168.146.140, drbddisk – это диск описанный в ресурсе r0 (/etc/drbd conf ), устройство /dev/drbd0, файловая система /mnt/drbd0, это именно та файловая система которая будет доступна для приложений, используется тип файловой системы ext3 с опциями по умолчанию, после монтирования ФС необходимо запустить сервис httpd Как мы видим именно здесь задается shared IP-адрес, это тот самый IPадрес по которому пользователи должны обращаться к вашим сервисам Если первичная нода станет недоступна то этот IP-адрес будет назначен вторичной ноде которая станет первичной и начнет обрабатывать запросы Такой подмены пользователи не заметят и сервис будет предоставляться без перебоев, а именно это нам и нужно Укажите здесь любой свободный IP-адрес из вашей сети и закрепите его за кластером После того как файлы конфигурации Heartbeat на обеих нодах будут готовы, можно запускать сервис Наш кластер почти готов, как вы помните повышать отказоустойчивость мы будем веб-сервера, поскольку DRBD и Heartbeat готовы к работе, самое время установить Apache # yum -y install httpd Настройки в httpd.conf по умолчанию или те, которые освещаются в модуле про Apache Для нас самое главное – это секция виртуального хоста, в которой мы опишем сайт нашей компании В конец файла /etc/httpd/conf/ httpd.conf добавляем секцию виртуального хоста Модуль 17 Отказоустойчивый кластер 259 ServerAdmin support@company.ru DocumentRoot /mnt/drbd0/ ServerName company.ru ServerAlias www.company.ru DirectoryIndex index.html ScriptAlias /cgi-bin/ /mnt/drbd0/cgi-bin/ ErrorLog /mnt/drbd0/logs/error_log CustomLog /mnt/drbd0/logs/access_log common RewriteLog /mnt/drbd0/logs//rewrite.log RewriteLogLevel Создаем структуру папок для веб-сервера [root@node1 ~]# mkdir /mnt/drbd0/{logs,cgi-bin} Создаем log-файлы [root@node1 ~]# touch /mnt/drbd0/logs/{access.log,error.log,rewrite.log} Создаем индексный файл [root@node1 ~]# echo 'High-availability Page' > /mnt/drbd0/index.html Запускаем Heartbeat, при старте он запустит Apache [root@node1 ~]# service heartbeat start Starting High-Availability services: 2009/04/26_21:29:04 INFO: Resource is stopped [ OK ] В выводе команды ifconfig вы заметите что был создан сетевой алиас (eth0:0), это виртуальный интерфейс с назначенным ему IP-адресом В случае выхода первичной ноды он будет переназначен на вторичной и она став первичной будет обрабатывать запросы! [root@node1 ~]# ifconfig 260 Модуль 17 Отказоустойчивый кластер eth0 Link encap:Ethernet HWaddr 00:0C:29:77:9C:9C inet addr:192.168.146.150 Bcast:192.168.146.255 Mask:255.255.255.0 inet6 addr: fe80::20c:29ff:fe77:9c9c/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:2743855 errors:0 dropped:0 overruns:0 frame:0 TX packets:6180468 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:203601157 (194.1 MiB) TX bytes:691044303 (659.0 MiB) Interrupt:59 Base address:0x2000 eth0:0 Link encap:Ethernet HWaddr 00:0C:29:77:9C:9C inet addr:192.168.146.140 Bcast:192.168.146.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 Interrupt:59 Base address:0x2000 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:32 errors:0 dropped:0 overruns:0 frame:0 TX packets:32 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:3637 (3.5 KiB) TX bytes:3637 (3.5 KiB) [root@node2 ~]# service heartbeat start Попробуйте в браузере обратиться к нашему веб-серверу Чтобы веб-сервер понял что от него хотят заголовок запроса должен содержать нужный нам хост Пропишете в файл hosts такую запись: 192.168.146.140 company.ru 192.168.146.140 www.company.ru Файл hosts в Linux находится в /etc/, в Windows C:\WINDOWS\system32\ drivers\etc Вы должны увидеть нашу страницу index.html с текстом “High-availability Page ” Если это так то продолжаем, если она не показывается то внимательно перечитываем все выше написанное Теперь надо убедится что при недоступности одной ноды работу будет выполнять вторая Берем и просто отключаем Heartbeat на node1, в свою очередь он выключит веб-сервер и перейдет в режим secondary node [root@node1 ~]# service heartbeat stop Еще раз запрашиваем страницу в браузере и замечаем что все продолжает работать Модуль 17 Отказоустойчивый кластер 261 Виртуальный интерфейс переместился на Node2, там же запустился Apache и начал сразу же обрабатывать запросы Вторичная нода стала первичной [root@node2 ~]# service drbd status drbd driver loaded OK; device status: version: 8.0.13 (api:86/proto:86) GIT-hash: ee3ad77563d2e87171a3da17cc002ddfd1677dbe build by buildsvn@c5-i386build, 2008-10-02 13:31:44 m:res cs st ds p mounted fstype 0:r0 Connected Primary/Secondary UpToDate/UpToDate C /mnt/drbd0 ext3 [root@node2 ~]# ifconfig eth0 Link encap:Ethernet HWaddr 00:0C:29:25:04:55 inet addr:192.168.146.134 Bcast:192.168.146.255 Mask:255.255.255.0 inet6 addr: fe80::20c:29ff:fe25:455/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:6180400 errors:2 dropped:2 overruns:0 frame:0 TX packets:2742239 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:693847272 (661.7 MiB) TX bytes:200769641 (191.4 MiB) Interrupt:59 Base address:0x2000 eth0:0 Link encap:Ethernet HWaddr 00:0C:29:25:04:55 inet addr:192.168.146.140 Bcast:192.168.146.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 Interrupt:59 Base address:0x2000 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:34 errors:0 dropped:0 overruns:0 frame:0 TX packets:34 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:3798 (3.7 KiB) TX bytes:3798 (3.7 KiB) После того как node1 будет починена ее можно вернуть на первичную роль [root@node1 ~]# service heartbeat start [root@node2 ~]# service heartbeat stop [root@node2 ~]# service heartbeat start Теперь проведем более жесткий тест Сделаем имитацию потери подключения ноды к сети Выдерните сетевой кабель из node1, если это 262 Модуль 17 Отказоустойчивый кластер физический сервер или просто наберите команду ниже: [root@node1 ~]# ifdown eth0 В течение нескольких секунд виртуальный интерфейс должен мигрировать на node2 и работа веб-сервера продолжится После того, как вы это заметите, верните подключение на node1: [root@node1 ~]# ifup eth0 Через несколько секунд node1 опять станет primary node и начнет обслуживать подключения, потому что “auto_fallback on” На этом построение отказоустойчивого кластера подошло к успешному завершению Конфигурационный ф ур ц файл ф /etc/drbd.conf minor-count По умолчанию модуль DRBD загружается с minorcount 32, если используется много устройств и номеров не хватает их можно явно указать здесь; dialog-refresh Обновление экрана каждые n секунд, может быть полезно при подключение к серверу по последовательному интерфейсу; disable-ip-verification Позволяет отключить одну из проверок drbdadm; usage-count Участвовать в глобальном подсчете пользователей DRBD или нет; common { } Секция, опции которой наследуют все ресурсы; syncer Позволяет задать пропускную способность при синхронизации устройств по сети, разработчики рекомендуют использовать 30% от возможностей сети Например, если у вас 100 Мбит сеть, то 100 * 0.3 = 30 Мб; resource r0 { } Секция описания ресурса; protocol Задает протокол для DRBD, подробнее о них написано выше; handlers { } Задает обработчики, например что делать в случае потери соединения первичной ноды; startup { } Секция для опций используемых в процессе загрузки DRBD; wfc-timeout Ожидание таймаута соединения; degr-wfc-timeout Ожидание таймаута подключения, в случае если в кластере одна рабочая нода; Модуль 17 Отказоустойчивый кластер 263 wait-after-sb disk { } on-io-error detach fencing Ожидание после split brain, ситуация когда все ноды могут попытаться запустить сервис одновременно, думая что другие ноды недоступны В свою очередь это может повлечь за собой повреждение данных; Секция с настройками оповещения верхних уровней, если замечено, что происходят I/O ошибки при обращение к диску; Нода перестает работать с носителем данных если на нем происходят I/O ошибки; Процесс блокировки ресурсов с нод статус которых сомнителен; net { } Секция задает различные опции сети, такие как размеры буфера, максимальное число запросов обрабатываемых DRBD В обычных ситуациях значений по умолчанию достаточно; on host { } Секция описания нод; device Указывает на устройство DRBD, они расположены в /dev/ и начинаются с 0; disk Физический диск или раздел, который будет задействован в работе DRBD; address IP-адрес и порт этой ноды, нужно указывать именно ее IP-адрес а не shared IP; meta-disk Meta данные могут храниться на отдельном разделе/ диске а могут на диске описанном в опции disk; max-buffers Число буферов используемых для хранения данных, пока те записываются на диск; max-epoch-size Максимальное число запросов на запись Должно соответствовать max-buffers; timeout ping-int Эти значения можно повысить если наблюдаются обрывы связи; Значения опций в выводе cat /proc/drbd Информация о ресурсе cs ro ds ns 264 connection state roles disk states network send Модуль 17 Отказоустойчивый кластер nr dw dr al bm lo pe ua ap network receive disk write disk read activity log bit map local count pending unacknowledged application pending Возможный статус соединения StandAlone Disconnecting Unconnected Timeout BrokenPipe NetworkFailure ProtocolError TearDown WFConnection WFReportParams Connected StartingSyncS Не доступна сетевая конфигурация Этот ресурс еще не был подключен или был административно отключен (drbdadm disconnect), или сбросил сетевое подключение из за не пройденной аутентификации или split brain; Временное состояние пока происходит отключение, следующее состояние – StandAlone; Временное состояние до попытки подключения Следующее возможное состояние – WFConnection или WFReportParams; Временное состояние после перерыва связи с peer-ом Следующее возможное состояние – Unconnected; Временное состояние после потери связи с peer-ом Следующее возможное состояние – Unconnected; Временное состояние после потери связи с партнером Следующее возможное состояние – Unconnected; Временное состояние после потери связи с партнером Следующее возможное состояние – Unconnected; Временное состояние, peer закрывает соединение Следующее возможное состояние – Unconnected; Нода ожидает пока peer станет виден в сети; TCP соединение было установлено, нода ожидает первый сетевой пакет от peer-ра; DRBD соединение установлено, зеркалирование данных активно Это нормальное состояние; Начата полная синхронизация, выполняется администратором Следующее возможное состояние – SyncSource или PausedSyncS; Модуль 17 Отказоустойчивый кластер 265 StartingSyncT WFBitMapS WFBitMapT WFSyncUUID SyncSource SyncTarget PausedSyncS PausedSyncT VerifyS VerifyT Начата полная синхронизация, выполняется администратором Следующее возможное состояние – WFSyncUUID; Частичная синхронизация начата Следующее возможное состояние – SyncSource или PausedSyncS; Частичная синхронизация начата Следующее возможное состояние – WFSyncUUID; Синхронизация скоро начнется Следующее возможное состояние – SyncTarget или PausedSyncT; Синхронизация запускается, локальная нода является источником синхронизации; Синхронизация запускается, локальная нода является целью синхронизации; Локальная нода источник синхронизации, но синхронизация находится в режиме паузы; Локальная нода является целью синхронизации, но синхронизация находится в режиме паузы; Запускается онлайн верификация, локальная нода является источником верификации; Запускается онлайн верификация, локальная нода является целью верификации Роли ресурсов Primary Secondary Unknown Primary node; Secondary node; Роль ресурса неизвестна Локальный ресурс не бывает в этой роли Она отображается только для ресурса peer-ра в отключенном режиме Возможное состояние диска Diskless Attaching Failed Negotiating Inconsistent Драйверу DRBD не назначено блочное устройство; Переходное состояние пока считываются meta данные; Переходное состояние последовавшее за I/O ошибкой локального блочного устройства, следующее возможное состояние – Diskless; Переходное состояние пока налаживается соединение; Данные непоследовательны Это статус нового ресурса; Outdated Данные ресурса последовательны но устарели; 266 Модуль 17 Отказоустойчивый кластер DUnknown Consistent UpToDate Статус используется для peer-ра если не доступно сетевое подключение; Последовательные данные ноды без сетевого подключения После подключения будет решено, данные являются актуальными или устаревшими; Все данные в актуальном состояние Это нормально состояние Конфигурационный ф ур ц файл ф /etc/ha.d/ha.cf debugfile logfile logfacility keepalive deadtime warntime initdead udpport baud serial bcast mcast ucast auto_failback stonith watchdog Задает расположение файла для записи отладочной информации; Задает расположение файла для записи всей остальной информации; Опция для Syslog; Как часто проверять состояние другой ноды, указывается в секундах; Как быстро нужно решить, что удаленная нода вышла из строя, указывается в секундах; Через какой промежуток времени после последнего ответа от удаленной ноды генерировать предупреждение; На некоторых серверах и ОС, сетевой интерфейс начинает работать правильно только после перезагрузки, для корректной обработки ситуации введен дополнительный счетчик; UDP порт для broadcast/unicast запросов; Скорость для последовательного соединения; Устройство для последовательного соединения; Через какой интерфейс отправлять broadcast-запросы Heartbeat; Интерфейс для multicast-запросов, если используется; Интерфейс для unicast-запросов, если используется; Переключаться ли обратно на primary node после ее восстановления: on – переключаться; off – secondary node продолжит работать как primary node; legacy – включать auto_failback в системах, где все ноды еще не поддерживают опцию auto_failback; Опция используется только в первой версии Heartbeat; Позволяет включить Watchdog timer, если наш собственный Heartbeat не ответит в течение минуты то сервер будет перезагружен; Модуль 17 Отказоустойчивый кластер 267 node ping Задает ноду; Позволяет пинговать сетевое устройство, например свой шлюз, используется для определения работоспособности сети; respawn Процессы стартуют и останавливаются вместе с Heartbeat, ipfail определяет какая нода имеет лучшее сетевое подключение, в случае если нода теряет сетевое подключение или испытывает большие затруднения в передаче трафика, ipfail заметит это и роль primary node может быть передана другой ноде; apiauth API authorization directive; debug Задает уровень отладки; use_logd Использовать ли logging daemon; conn_logd_time Интервал переподключения к logd; compression Здесь указывается модуль компрессии Таблица ниже позволяет оценить доступность сервиса в процентах в год Доступность сервиса в % в год Недоступность сервиса в мин./часах в год 99.9999% 99.999% 99.99% 99.9% 99% 30 сек минут 52 минуты часов с половиной дня Резюме В этом модуле мы выяснили какие виды кластеров бывают Подробнее разобрали принцип работы отказоустойчивого кластера, узнали о программном обеспечение которое нам может помочь в его построение и удачно воспользовались им Мы установили и настроили наш кластер на базе DRBD и Heartbeat, далее развернули веб-сервер Apache и протестировали его работу Это была простая конфигурация кластера, но полученный опыт является хорошим фундаментом для дальнейших исследований Домашнее задание На двух виртуальных машинах построить отказоустойчивый кластер для веб-сервера и убедиться, что все работает 268 Модуль 17 Отказоустойчивый кластер ... 173 Инструменты 173 Базовые понятия 174 Правила построения DNS-системы 174 Режимы работы ДНС-серверов 175 Типы ответов... 171 Мониторинг соединений proftpd в реальном времени времени 172 Статистика по виртуальной памяти 172 Статистика по процессору и устройствам ввода-вывода 172 ... процессов 170 Мониторинг системных ресурсов 170 Мониторинг свободного места в разделах 170 Мониторинг сетевой подсистемы в реальном времени 171 Мониторинг