в corosync, debian, pacemaker

Установка и настройка Pacemaker & Corosync в Debian Jessie

active-passive cluster
Ранее мы подробно рассматривали процесс установки и настройки Active/Passive Cluster, в примерах использовалась операционная система Debian Wheezy.

Для ОС Debian Jessie процесс практически идентичен, но существует несколько особенностей — давайте разберемся!

Самое важное — в основном репозитории Debian Jessie нет необходимых пакетов для настройки кластера, поэтому придется использовать jessie-backports.

Кроме того, pacemaker попытается установить пакет openhpid — с этим обязательно возникнут проблемы. Для корректной установки замаскируем openhpid командой:

systemctl mask openhpid.service

Теперь можем приступать к установке:

apt-get update && apt-get install -t jessie-backports pacemaker crmsh

Будут установлены pacemaker (1.1.14-2~bpo8+1) и все необходимые зависимости, включая corosync (2.3.5-3~bpo8+1) и fence-agents (4.0.22-2~bpo8+1). Текущие версии пакетов будут искать базовые настройки в /etc/sysconfig (по умолчанию используется в RedHat), однако в Debian эти настройки находятся в каталоге /etc/defaults. Для решения данной проблемы выполняем:

cd /etc; ln -nfs default sysconfig

Далее на обоих серверах кластера разрешаем автозапуск corosync — в конфигурационном файле /etc/default/corosync, добавляем:

...
START=yes

Процедура создания и копирования ключей corosync для такая же, как и в Debian Wheezy:

corosync-keygen
scp /etc/corosync/authkey root@db2:/etc/corosync/authkey

А вот конфигурационный файл /etc/corosync/corosync.conf был серьезно изменен, и теперь (в нашем случае) должен выглядеть так:

totem {
  version: 2
  token: 3000
  token_retransmits_before_loss_const: 10
  clear_node_high_bit: yes
  crypto_cipher: none
  crypto_hash: none
  rrp_mode: passive
  transport: udpu

  interface {
    ringnumber: 0
    bindnetaddr: 172.16.0.0
    mcastport: 5405
    ttl: 1
  }
  interface {
    ringnumber: 1
    bindnetaddr: 192.168.0.0
    mcastport: 5407
    ttl: 1
  }
}

service {
ver:       0
name:      pacemaker
}

logging {
  to_logfile: yes
  logfile: /var/log/corosync/corosync.log
  debug: off
  timestamp: on
  logger_subsys {
    subsys: QUORUM
    debug: off
  }
}

quorum {
  provider: corosync_votequorum
  two_node: 1
}

nodelist {
        node {
           ring0_addr: 172.16.0.1
           ring1_addr: 192.168.25.8
           name: db1
           nodeid: 1
        }
        node {
           ring0_addr: 172.16.0.2
           ring1_addr: 192.168.25.9
           name: db2
           nodeid: 2
        }
}

Запускаем corosync:

/etc/init.d/corosync start

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

crm configure property stonith-enabled="false"
crm configure property symmetric-cluster="false"
crm configure rsc_defaults resource-stickiness="110"
crm configure rsc_defaults migration-threshold=3
crm configure property no-quorum-policy=ignore

Настройка ресурсов кластера в новой операционной системе осталась неизменной, поэтому можем воспользоваться этим примером.

Добавить комментарий

  1. Ой, люди добрые, сам я не местный… поможите кто чем может, укажите дуралею, где почитать, про то как мастер со слейвом местами поменять? Ну в смысле, что когда ужо все работает, и вот я хочу мастер пропылесосить, что мне ему шепнуть? Миграция ресурсов что-то как-то неверно работает — ресурс ocf::heartbeat:LVM не может остановится (unknown error) и потом ваще всё в разнос идёт… мозги на половинки и пр. ресинк. Если на мастере crm node standby, то вроде вначале все пучком, пока этот нод опять online не сделаешь — и снова два primary у drbd и всё плохо. Явно я чего-то не понимаю в этой жизне. Мнеп букварь какой… Токма оно воно чего — грамоте мы не обучены. Буквы только россейские разумею…

    Stack: corosync
    Current DC: st1 (version 1.1.15-e174ec8) — partition with quorum
    Last updated: Wed Feb 8 23:28:18 2017 Last change: Wed Feb 8 23:21:15 2017 by root via crm_attribute on st1

    2 nodes and 7 resources configured
    Online: [ st1 st2 ]

    Master/Slave Set: drbd0clone [drbd0]
    Masters: [ st1 ]
    Slaves: [ st2 ]
    Resource Group: rg_iscsi_grp
    p_lvm_r0 (ocf::heartbeat:LVM): Started st1
    p_ip_iscsi (ocf::heartbeat:IPaddr2): Started st1
    p_target_r0 (ocf::heartbeat:iSCSITarget): Started st1
    p_lu_r0_lun1 (ocf::heartbeat:iSCSILogicalUnit): Started st1
    p_lu_r0_lun2 (ocf::heartbeat:iSCSILogicalUnit): Started st1

    • Сергей, здравствуйте!
      Команда

      crm node standby

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

      crm resource cleanup ...

      Также можно переносить ресурсы вручную командой

      crm resource migrate ...

      (пример).

      Еще я бы попробовал перевести кластер в режим обслуживания (чтоб не сломать весь кластер) и попробовать вручную переместить ресурс (проблемный LVM или что-там мешает переключиться) и понаблюдать за логами в момент переключения — возможно, какой-то процесс использует этот диск/раздел.

      А пробовали просто перезагрузить (выключить) мастер? в этот момент все ресурсы должны подниматься на слейве (слейв->мастер), а когда мастер загрузится он сам станет слейвом.

  2. Понятно, просто ищу возможные ошибки, почему у меня не работает.

    Все делаю по инструкции, но когда добавляю ресурс drbd, называю r206, сразу выдается предупреждение, что не найден RA monitor, а crm status выдает

    r206 (ocf::linbit:drbd): FAILED db1 (blocked)

    Failed Actions:
    * r206_stop_0 on db1 ‘not configured’ (6): call=6, status=complete, exitreason=’none’,
    last-rc-change=’Mon Feb 6 05:35:41 2017′, queued=0ms, exec=61ms

    ocf-tester ругается на какие права

    ocf-tester -n r206
    Beginning tests for …
    sh: 0: Can’t open meta-data
    * rc=127: Your agent has too restrictive permissions: should be 755
    /usr/sbin/ocf-tester: 226: /usr/sbin/ocf-tester: meta-data: not found
    -:1: parser error : Document is empty

    проверял /usr/lib/ocf/resource.d/, там все на месте

    гуглежка не помогла

    • Вы добавляете ресурс так как описано в этой статье — https://letsclearitup.com.ua/debian/active-passive-cluster-v-linux-chast-3-nastroyka-resursov-klastera.html, верно?

      командой:
      crm configure primitive drbd_mysql ocf:linbit:drbd params drbd_resource=»mysql» op monitor interval=»60s» op start interval=»0″ timeout=»240s» op stop interval=»0″ timeout=»240s» op monitor role=Master interval=»10s» op monitor role=Slave interval=»30s»

      При этом отдельно (без кластера) drbd-ресурс работает нормально?

      • Да, все делаю именно по этой инструкции, drbd работает нормально

        в руководстве Pacemaker прочитал про какой-то баг ocf для drbd84 в CentOS, пробовал обновлять ocf по аналогии — не помогает.

        • Вы настраиваете кластер на CentOS? Я все это хозяйство поднимал в Debian Wheezy/Jessie, но вот в CentOS yне проверял…
          Давайте сравним версии ПО:

          # dpkg -l | grep drbd
          ii  drbd-utils                             8.9.2~rc1-2+deb8u1                 amd64        RAID 1 over TCP/IP for Linux (user utilities)
          ii  drbd8-utils                            2:8.9.2~rc1-2+deb8u1               amd64        transitional dummy package
          
          
          # dpkg -l | grep coros
          ii  corosync                               2.3.6-3~bpo8+1                     amd64        cluster engine daemon and utilities
          ii  libcorosync-common4:amd64              2.3.6-3~bpo8+1                     amd64        cluster engine common library
          
          # dpkg -l | grep pacem
          ii  crmsh                                  2.2.0-1~bpo8+1                     amd64        CRM shell for the pacemaker cluster manager
          ii  pacemaker                              1.1.15-3~bpo8+1                    amd64        cluster resource manager
          ii  pacemaker-cli-utils                    1.1.15-3~bpo8+1                    amd64        cluster resource manager command line utilities
          ii  pacemaker-common                       1.1.15-3~bpo8+1                    all          cluster resource manager common files
          ii  pacemaker-resource-agents              1.1.15-3~bpo8+1                    all          cluster resource manager general resource agents
          
          • я делал на debian jessie. Версии пакетов у меня чуть посвежее. Но дело в том что я на старой платформе ibm запускаю. То есть пакеты у меня для архитектуры i386, наверное там какой-то баг

          • Да, скорее всего вы правы.
            К сожалению, у меня нет возможности проверить работоспособность кластера на другой платформе, но буду благодарен если вы напишете о своих результатах )

    • Это совершенно разные вещи, в конфигурационном файле коросинка параметр ver используется для определения очередности запуска сервисов, например:

      service {
             name: pacemaker
             ver: 0
      }

      This automatically starts the pacemaker services (but not pacemakerd).
      The services have corosync as the parent process.

      или

      service {
             name: pacemaker
             ver: 1
      }

      This does not start the pacemaker services
      automatically, I have to start pacemaker with «/etc/init.d/pacemaker
      start» and the services have the pacemakerd as the parent process.