Данная страница находится в разработке. Эта страница ещё не закончена. Информация, представленная здесь, может оказаться неполной или неверной.
Если вы считаете, что её стоило бы доработать как можно быстрее, пожалуйста, скажите об этом.
Отказоустойчивый кластер — это комбинация из одного или более узлов (серверов) на двух или более общих дисках, которые называются группой ресурсов. Группу ресурсов вместе с ее сетевым именем и IP-адресом, которые составляют кластерное приложение или сервер, называют отказоустойчивым кластером или экземпляром отказоустойчивого кластера. В сети отказоустойчивый кластер представлен как один компьютер, но при этом он обеспечивает переход на другой узел в случае, если текущий узел становится недоступным. Отказоустойчивый кластер в сети выступает в роли обычного приложения или отдельного компьютера, но поддерживает дополнительные возможности, увеличивающие его доступность.
Чтобы создать HA кластер нужно создать отказоустойчивость по нескольким направлениям:
Агрегирование каналов позволяет работать при повреждении одного из кабелей;
Устанавливаем Debian GNU/Linux amd64 Squeeze. О том как установить лучше обратиться к русскому первоисточнику
[править] Дисковая подсистема
Предлагаю два варианта RAID
[RAID 6] — похож на RAID 5, но имеет более высокую степень надёжности — под контрольные суммы выделяется ёмкость 2-х дисков, рассчитываются 2 суммы по разным алгоритмам. Требует более мощный RAID-контроллер. Обеспечивает работоспособность после одновременного выхода из строя двух дисков — защита от кратного отказа. Для организации массива требуется минимум 4 диска[2]. Обычно использование RAID-6 вызывает примерно 10-15% падение производительности дисковой группы, по сравнению с аналогичными показателями RAID-5, что вызвано большим объёмом обработки для контроллера (необходимость рассчитывать вторую контрольную сумму, а также прочитывать и перезаписывать больше дисковых блоков при записи каждого блока).
[RAID 10] — зеркалированный массив, данные в котором записываются последовательно на несколько дисков, как в RAID 0. Эта архитектура представляет собой массив типа RAID 0, сегментами которого вместо отдельных дисков являются массивы RAID 1. Соответственно, массив этого уровня должен содержать как минимум 4 диска. RAID 10 объединяет в себе высокую отказоустойчивость и производительность. Нынешние контроллеры используют этот режим по умолчанию для RAID 1+0. То есть, один диск основной, второй — зеркало, считывание данных производится с них поочередно. Сейчас можно считать, что RAID 10 и RAID 1+0 — это просто разное название одного и того же метода зеркалирования дисков. Утверждение, что RAID 10 является самым надёжным вариантом для хранения данных, ошибочно, т.к., несмотря на то, что для данного уровня RAID возможно сохранение целостности данных при выходе из строя половины дисков, необратимое разрушение массива происходит при выходе из строя уже двух дисков, если они находятся в одной зеркальной паре.
Устанавливаем Raid 10 по схеме:
[править] Установка Debian на Linux RAID
[править] Установка grub на все жесткие диски
На все диски нужно устанвовить загрузчик. Пример установка на диск sda.
После установки сервера можно проверить скорость чтения и записи.
Источник
Corosync + Pacemaker. Как правильно развернуть кластер высокой отказоустойчивости
Содержание статьи
Рассмотрим несколько возможных решений.
Oracle Clusterware для Oracle Unbreakable Linux — достаточно дорогой вариант, его стоит использовать, только если имеешь дело с продуктами Oracle.
Veritas Infoscale Availabilty — коммерческое решение, ранее известное как Veritas Cluster Server. Лицензия VCS Access на узловой кластер из четырех нод будет стоить порядка 20–30 тысяч долларов.
Red Hat Cluster Suite — решение с открытым исходным кодом. Но для его грамотного использования необходимо изучить большой объем документации, на что у тебя уйдет куча времени.
Я же хочу рассказать, как создать кластеризацию на уровне приложений с высокой отказоустойчивостью в сжатые сроки, с ограниченным бюджетом и без глубоких познаний в построении кластеров. Оптимальным решением, на мой взгляд, будет использование Corosync и Pacemaker. Эта связка бесплатна, ее легко освоить, и на развертывание не уйдет много времени.
Corosync — программный продукт, который позволяет создавать единый кластер из нескольких аппаратных или виртуальных серверов. Corosync отслеживает и передает состояние всех участников (нод) в кластере.
Этот продукт позволяет:
мониторить статус приложений;
оповещать приложения о смене активной ноды в кластере;
отправлять идентичные сообщения процессам на всех нодах;
предоставлять доступ к общей базе данных с конфигурацией и статистикой;
отправлять уведомления об изменениях, произведенных в базе.
Pacemaker — менеджер ресурсов кластера. Он позволяет использовать службы и объекты в рамках одного кластера из двух или более нод. Вот вкратце его достоинства:
позволяет находить и устранять сбои на уровне нод и служб;
не зависит от подсистемы хранения: можем забыть общий накопитель, как страшный сон;
не зависит от типов ресурсов: все, что можно прописать в скрипты, можно кластеризовать;
поддерживает STONITH (Shoot-The-Other-Node-In-The-Head), то есть умершая нода изолируется и запросы к ней не поступают, пока нода не отправит сообщение о том, что она снова в рабочем состоянии;
поддерживает кворумные и ресурсозависимые кластеры любого размера;
поддерживает практически любую избыточную конфигурацию;
может автоматически реплицировать конфиг на все узлы кластера — не придется править все вручную;
можно задать порядок запуска ресурсов, а также их совместимость на одном узле;
поддерживает расширенные типы ресурсов: клоны (когда ресурс запущен на множестве узлов) и дополнительные состояния (master/slave и подобное) — актуально для СУБД (MySQL, MariaDB, PostgreSQL, Oracle);
имеет единую кластерную оболочку CRM с поддержкой скриптов.
Идея заключается в том, что с помощью Corosync мы построим кластер, а следить за его состоянием будем с помощью Pacemaker.
В теории
Попробуем решить следующие задачи.
Развернуть кластер высокой отказоустойчивости из двух нод для обработки забросов от клиентов при условии, что они используют общий сетевой адрес и службу веб-сервера nginx.
Протестировать отказ одной из нод в кластере, убедиться, что ресурсы передаются на рабочую ноду, когда активная нода упала.
Время проверки сбоя на активной ноде 30 секунд.
Схема работы кластера из двух нод
Перед началом любых работ настоятельно советую нарисовать схему взаимодействия узлов сети. Это упростит понимание и принципы взаимодействия и работы узлов.
На практике
Настала пора реализовать намеченные задачи. Я в своем примере использовал дистрибутив Red Hat Enterprise Linux 7. Ты можешь взять любой другой Linux, принципы построения кластера будут те же.
Для начала установим пакеты, которые требуются для нормальной работы ПО на обеих нодах (ставим пакеты на обе ноды).
Следующую команду тоже нужно исполнять с правами рута, но если использовать sudo , то скрипт установщика отработает неверно и не создастся пользователь hacluster.
Проверяем пользователя hacluster (Pacemaker) и меняем пароль:
Авторизуемся на нодах под именем пользователя hacluster. Если выходит ошибка доступа к ноде ( Error: Unable to communicate with ha-node1 ), то, скорее всего, из-под Linux-УЗ наложены запреты на использование удаленных оболочек. Необходимо снять ограничение SUDO на время установки.
Когда увидишь следующее, можешь двигаться дальше:
User may run the following commands on ha-node1: (ALL) NOPASSWD: ALL
Теперь проверяем на обеих нодах установленные пакеты corosync, pacemaker и pcs, добавляем в автозагрузку и запускаем службу конфигурации pacemaker.
Авторизуемся на нодах под пользователем hacluster:
Создаем кластер из двух нод:
Включаем и запускаем все кластеры на всех нодах:
При использовании двух нод включаем stonith. Он нужен для «добивания» серверов, которые не смогли полностью завершить рабочие процессы. Игнорируем кворум.
Запрашиваем статус на обеих нодах ( $ sudo pcs status ) и видим:
Cluster name: HACLUSTER Stack: corosync Current DC: ha-node2 (version 1.1.18-11.el7_5.3-2b07d5c5a9) — partition with quorum Last updated: Wed Oct 17 13:12:00 2018 Last change: Wed Oct 17 13:10:47 2018 by root via cibadmin on ha-node1
Как только первая нода будет доступна, вручную переключаем на нее виртуальный IP и nginx командой
Осталось запросить статус кластера и убедиться, что адрес присвоен первой ноде.
virtual_ip (ocf::heartbeat:IPaddr2): Started ha-node1
Список всех поддерживаемых сервисов можно посмотреть c помощью команды $ sudo crm_resource —list-agents ocf .
Кластеризация на базе nginx
На обеих нодах должен быть установлен и настроен nginx. Подключаемся к кластеру и создаем следующий ресурс:
Здесь мы создаем ресурс из службы, которая будет каждые 30 секунд проверяться, и в случае минутного тайм-аута ресурс будет включен на другой ноде.
Чтобы удалить ноду из кластера, воспользуйся командой $ sudo pcs cluster node remove .
Выводы
Мы построили простой, но очень отказоустойчивый кластер для фронтенда приложения. Помни, что построение кластера — задача творческая и все зависит только от твоих смекалки и воображения. Невыполнимых задач для системного администратора не бывает!
Иван Рыжевцев
Системный администратор с богатым опытом. Прошедший огонь, воду и медные трубы. Главный девиз в жизни: Нерешаемых задач нет, надо только найти правильное решение!
Источник
Настройка кластера Pacemaker на CentOS 7
Подготовка серверов
Обновляем систему.
Настраиваем время.
Необходимо, чтобы на всех нодах было одинаковое время.
Устанавливаем утилиту для синхронизации даты и времени:
* также, будет создан конфигурационный файл /etc/corosync/corosync.conf.
Разрешаем автозапуск и запускаем созданный кластер:
pcs cluster enable —all
pcs cluster start —all
* опция —all говорит, что необходимо выполнить команду для всех нод, к которым мы подключились (вместо этой опции можно перечислить ноды вручную).
При использовании 2-х нод (как в данном примере) отключаем stonith (нужен для «добивания» серверов, которые не смогли полностью завершить рабочие процессы) и кворум:
pcs property set stonith-enabled=false
pcs property set no-quorum-policy=ignore
Просмотреть состояние можно командой:
Настройка виртуального IP
Рассмотрим самый распространенный вариант использования Pacemaker. Он заключается в использовании виртуального IP-адреса, который будет назначаться активному узлу кластера.
Для этого создаем ресурс командой:
pcs resource create virtual_ip ocf:heartbeat:IPaddr2 ip=192.168.0.15 cidr_netmask=24 op monitor interval=60s
* гдеvirtual_ip — название ресурса (может быть любым); 192.168.0.15 — виртуальный IP, который будет назначен кластеру; 24 — префикс сети (соответствует маске 255.255.255.0); 60s — критическое время простоя, которое будет означать недоступность узла.
Мы должны увидеть, примерно такую строку:
virtual_ip (ocf::heartbeat:IPaddr2): Started node1
Для проверки, перезагружаем активную ноду (node1) командой:
Через небольшой промежуток времени должен смениться узел с virtual_ip:
virtual_ip (ocf::heartbeat:IPaddr2): Started node2
Для смены активной ноды ресурса, вводим команду:
pcs resource move virtual_ip node1
Отказоустойчивость сервисов
Кластеризация по виртуальному IP-адресу позволит обеспечить высокую доступность на уровне работы сервера. Но если необходимо более тонкая настройка, позволяющая менять активную ноду при отказе службы, выполняем действия, описанные ниже.
Список всех поддерживаемых сервисов можно посмотреть командой:
crm_resource —list-agents ocf
Разберем кластеризацию на базе postfix.
Подключаемся к кластеру и создаем следующий ресурс:
pcs cluster auth node1 node2 -u hacluster
pcs resource create postfix ocf:heartbeat:postfix op monitor interval=30s timeout=60s
Удаление ноды
При необходимости исключить одну из нод кластера, выполняем следующую команду:
pcs cluster node remove node_name
* где node_name — имя узла, который хотим удалить.
Схема работы кластера из двух нод 
