Поиск по сайту:

Настройте высокую доступность с помощью Corosync и Pacemaker

Все приемы и методы, используемые для повышения доступности системы или службы и повышения отказоустойчивости, называются High Availability, в качестве примера неисправности можно упомянуть: аппаратное резервирование, кластеризацию, репликацию данных на горячем физическом уровне (RAID 1 и RAID). 5) либо в программном обеспечении (Снимки, DRBD), либо в кризисных сценариях (деградированный режим, аварийный план). В крупной компании это может привести к занятию ответственной должности с полной занятостью. В этой статье вы увидите картинку реализации одной из сторон этой проблемы: активный/пассивный кластер, обеспечивающий доступность службы приложений.

Что касается GNU/Linux, то в этой статье были протестированы два ПО, способных управлять инфраструктурой кластера:

  • Heartbeat, у которого есть свои доказательства, но оно ограничено: нет кластера из более чем двух нод, нет управления ресурсами и правил переключения с одного узла на другой.
  • Corosync и Pacemaker: это выбор дистрибутива Red Hat, который будет описан далее в этой статье.

Мы установили репрезентативную модель, состоящую из двух виртуальных машин Debian Wheezy с 4 сетевыми интерфейсами, на которых работает служба Apache, доступ к которой осуществляется по IP-адресу, управляемому кластером.

На следующем рисунке представлена сетевая диаграмма:

Интерфейсы eth0 и eth1 являются частью агрегации логических каналов и помогают кластеру проверять состояние других узлов. Они составляют частную сеть с другими узлами сети 10.20.13.0/255.255.255.252. Интерфейсы eth2 и eth3 являются частью другой логической агрегации, они предоставляют услуги снаружи в сети 192.168.1.0/24.

Логическое агрегирование (также называемое связыванием) обеспечивает дополнительную избыточность. Если сетевой адаптер eth0 перегорит, трафик все равно будет проходить через eth1. Его можно настроить в активном/пассивном режиме или в режиме балансировки нагрузки.

Вот конфигурация интерфейсов на машине vm-node1 в «/etc/network/interfaces/»:

auto bond0
iface bond0 inet static
  address 10.20.13.1
  netmask 255.255.255.252
  bond_mode active-backup
  bond_miimon 100
  bond_downdelay 200
  bond_updelay 200
  slaves eth0 eth1
auto bond1
iface bond1 inet static
  address 192.168.1.61
  netmask 255.255.255.0
  gateway 192.168.1.1
  bond_mode active-backup
  bond_miimon 100
  bond_downdelay 200
  bond_updelay 200
  slaves eth2 eth3

И конфигурация бондинга в «/etc/modprobe.d/bonding»:

alias bond0 bonding 
alias bond1 bonding

Конфигурация сети машины vm-node2 симметрична: Bond0 в 10.20.13.2 и Bond1 в 192.168.1.62. Когда конфигурация сети настроена, мы можем справиться с кластером. Сначала вам необходимо установить Corosync и Pacemaker в Debian. Для этого выполните следующие действия:

apt-get install corosyncpacemaker

Затем настройте Corosync. Он управляет инфраструктурой кластера, то есть состоянием узлов и их функционированием в группе. Для этого нам необходимо сгенерировать ключ для аутентификации, который будет использоваться всеми узлами кластера. Утилита corosync-keygen для генерации этого ключа из псевдослучайных нажатий клавиш, который затем необходимо защитить и скопировать на другие узлы.

generation of the key from vm-node1
corosync-keygen
mvauthkey/etc/corosync/authkey
chownroot:root/etc/corosync/authkey
chmod400/etc/corosync/authkey
 
copy of the key to vm-node2
scp/etc/corosync/[email :/etc/corosync/authkey

Corosync предлагает концепцию колец соединений для обеспечения связи между узлами. В рамках модели мы определили два кольца: кольцо0 — кольцо связи по умолчанию, использующее частную сеть, и кольцо 1 — резервное кольцо, которое проходит через коммутаторы с остальным трафиком. Corosync позволяет определять кольца с точки зрения IP/сетевой маски, а не определять IP-адреса. Это важно, поскольку один и тот же файл конфигурации можно развернуть на всех узлах, ничего не меняя.

totem {   
    version:2    
    
    #How long before declaring a token lost(ms)   
    token:3000    

    #How many token retransmits before forming a new configuration   
    token_retransmits_before_loss_const:10    

    #How long to wait for joining messages in the membership protocol(ms)   
    join:60    

    #How long to wait for consensus to be achieved before starting a new round of membership configuration(ms)    consensus:3600    

    #Turn off the virtual synchrony filter   
    vsftype:none    

    #Number of messages that may be sent by one processor on receipt of the token   
    max_messages:20    

    #Limit generated nodeids to 31-bits(positive signed integers)   
    clear_node_high_bit:yes    

    #Disable encryption   
    secauth:off    

    #How many threads to use for encryption/decryption   
    threads:0    

    #Optionally assign a fixed nodeid(integer)   
    #nodeid:1234    

    #This specifies the mode of redundant ring,which may be none,active,or passive.   
    rrp_mode:passive    

    interface {       
        ringnumber:0       
        bindnetaddr:10.20.13.0       
        mcastaddr:226.94.1.1       
        mcastport:5405   
    }   

    interface {       
        ringnumber:1       
        bindnetaddr:192.168.1.0       
        mcastaddr:226.94.1.1       
        mcastport:5407   
     }
} 

amf {   
     mode:disabled
} 

service {   
     #Load the Pacemaker Cluster Resource Manager   
     ver:       0   
     name:     pacemaker
} 

aisexec {   
    user:  root   
    group: root
} 

logging {   
    fileline:off   
    to_stderr:yes   
    to_logfile:no   
    to_syslog:yes   
    syslog_facility:daemon   
    debug:off   
    timestamp:on   
    logger_subsys {       
          subsys:AMF       
          debug:off       
          tags:enter|leave|trace1|trace2|trace3|trace4|trace6   
    }
}

На данный момент инфраструктура кластера существует, но она не управляет никакими ресурсами. Это роль кардиостимулятора.

Он имеет следующие эксплуатационные ограничения:

  1. ресурсы (служба Apache и IP-адрес кластера), работающие на сервере vm-node1 в обычном случае.
  2. Служба Apache и IP-адрес кластера должны работать на одном сервере, если наша служба недоступна.
  3. Если служба Apache выходит из строя на основном сервере, она переключается на вторичный сервер.
  4. если основной сервер подключен через интернет-шлюз, он переключается на вторичный сервер.

Кардиостимулятор предоставляет некоторые утилиты в текстовом режиме для взаимодействия.

  • CRM для управления всеми аспектами конфигурации.
  • crm_mon отображает состояние кластера.

Сначала мы определяем глобальную конфигурацию. Погашен СТОНИТ (Выстрел в другой узел в голове) и кворум. STONITH — это возможность уничтожить другой узел, если он больше не соответствует инфраструктуре кластера. И кворум, он не работает на кластере в пределах 3-х узлов.

property stonith-enabled=false
property no-quorum-policy=ignore

Теперь мы можем определить наш первый ресурс: IP-адрес кластера, прикрепленный к активному узлу.

primitive vip ocf:heartbeat:IPaddr2 params ip=192.168.1.60 cidr_netmask=24nic="bond1"op monitor interval="10s"

Затем ресурс Apache, критически важный сервис, который мы хотим предоставить в этой модели:

primitive httpd ocf:heartbeat:apache params configfile="/etc/apache2/apache2.conf"statusurl="http://localhost/server-status"op start timeout="60s"op stop timeout="60s"op monitor timeout="20s"

Запуск и остановка Apache теперь управляются кластером. Итак, нам теперь предстоит убрать автоматический запуск службы:

update-rc.d-fremoveapache2

Вы заметите, что это выходит за рамки определения ресурса Apache. Атрибут Pacemaker STATUSURL позволяет использовать страницу состояния Apache для определения качалки. Поэтому не забудьте настроить этот URL в Apache:

<Location/server-status>    
    SetHandler server-status    
    Order deny,allow    
    Deny from all    
    Allow from 127.0.0.1
</Location>

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

crm resource clean up httpd

На этом этапе у нас есть адрес кластера и HTTP-ресурс, но не обязательно на одном узле. vip-ресурс переключится, если узел будет удален. Ресурс httpd переключится, если узел будет удален или служба Apache активируется (мониторинг по URL-адресу/статусу сервера).

Давайте пойдем дальше и заставим оба ресурса работать на одном узле:

colocation httpd-with-vip inf : httpd vip

И нам бы хотелось, чтобы это было и в обычном случае, когда ресурсы работают на vm-node1, нашем основном узле:

location preferred-node vip 100 : vm-node1

Наконец, мы добавляем условие масштабирования. Если узел не достигает шлюза через Интернет, мы хотим переместить ресурсы на другой узел. Для этого мы определяем ресурс с типом ping, который работает на всех узлах (с помощью концепции клонированного ресурса). Затем добавляется правило отпуска для переключения, если активный узел не видит мост.

primitive ping-gateway ocf:pacemaker:ping params host_list="192.168.1.1"multiplier="1000"op monitor interval="10s"
clone cloned-ping-gateway ping-gateway
location vip-needs-gateway vip rule-inf:not_defined pingd or pingd lte 0

Это наша операционная модель. и мы надеемся, что поможем вам это сделать.