Användarverktyg

Webbverktyg


teknik:corosync_och_pacemaker_pa_debian

Corosync och Pacemaker på Debian

Det här dokumentet beskriver en grundläggande konfiguration av Corosync och Pacemaker som jag använder i botten av alla HA-lösningar.

Själva HA-lösningen beskrivs inte här, endast limmet som håller ihop den.

Dokumentet följer metoder som fungerar på Debian 6.0 (Squeeze) och Ubuntu 12.04 (Precise). All konfiguration som görs här ska vara identisk på samtliga noder i klustret.

Termer

Kort förklaring av de termer som kan förekomma inom klustring eller det här dokumentet. Flera andra dokument kan hänvisa till detta, så de flesta av dessa termer blir inte aktuella ännu.

Active/Active

En typ av klusterkonfiguration där båda noderna, eller alla noder, är aktiva och redo att användas samtidigt. Detta kan så klart kräva speciella filsystem så som OCFS2 och GFS2 om man vill kunna skriva från alla noder samtidigt.

Ett alternativ är Active/Standby där en eller flera noder är i vänteläge på om huvudnoden tappas.

Klusterstack

En bred term som kan betyda hela samlingen mjukvara som utgör HA-lösningen eller klustret. Kan även betyda en viss protokollstandard som openais, corosync, cman eller pacemaker.

Fencing

Att fäkta en nod betyder helt enkelt att döda den om den kan riskera integriteten av en tjänst i klustret, eller hela klustret. I fysisk hårdvara används ofta out-of-band management enheter som iLO, iDRAC och UPS enheter för att stänga ner maskiner.

I virtuella kluster måste vi använda VMware för att stänga ner en nod. Det görs då med fence_vmware skriptet som följer med cman-paketet i Debian och RHCS i RHEL eller CentOS.

# fence_vmware -o off -a 10.220.100.220 -l svc_vmware_fencing -p myPassword2012 -n vmlnx-linuxlab01

Fencing är otroligt viktigt i kluster, speciellt när man har delade resurser som filsystem. Det kan förekomma en fenced bakrundsprocess i vissa kluster. Normalt är det cman-paketet som tillhandahåller en fenced process.

Kort sagt så anropar en klustermjukvara som pacemaker en fencingprocess och ber den exekvera kommandon så som det ovannämnda fence_vmware. Kika i /usr/sbin/fence_* för att se fler så kallade fencing agenter som installeras av cman-paketet i Debian.

STONITH

STONITH är en akronym som står för Shoot The Offending Node In The Head, eller Shoot The Other Node In The Head. Det är ett annat ord för fencing och ofta ser man en stonithd bakrundsprocess som hanterar just fencing av noder.

Heartbeat tillhandahåller en stonithd process i pacemaker-paketet för Debian.

Resurs

Normalt sett i detta sammanhanget är en resurs något som drivs av, eller på, klustret. T.ex. om klustret driver en webbserver på flera noder så är det en resurs, eller om vi som i detta dokumentet ska driva ett delat filsystem så är det en resurs. Det kan även vara så att flera resurser krävs som beroenden innan man kan skapa sin primära resurs.

Resurser kan vara aktiva på en nod, eller flera. Resurser kan vara grupperade med andra resurser.

Resource Stickines

En term som har någon motsvarighet i alla klusterstackar. Den anger hur troligt det är att en resurs fastnar hos en viss nod när den väl hamnar där.

Till exempel om nod1 är hem till resursA och nod2 är en standby. Nod1 går ner så resursA flyttar till nod2. Sedan återvänder nod1 till aktivt läge. Då är det inte alltid önskvärt att omedelbart flytta tillbaka resursen till noden, utan istället ge sig själv tid att undersöka felet som fick noden att gå ner.

Det är då man höjer resource-stickines i pacemaker för att hålla kvar resursen på nod2.

Quorum

Ett sätt för noder i ett kluster att rösta på om klustret är operativt eller på vilka noder som ska vara aktiva. Har ett kluster inte quorum så stängs alla tjänster ner och det anses inte vara funktionsdugligt.

I kluster med enbart två noder behövs inte quorum. I ett kluster med tre noder konfigureras quorum oftast så att man kan tappa en nod men inte fler.

OCFS2

Oracle Cluster FileSystem 2. Ett filsystem från Oracle som är gjort för att tillåta delad åtkomst från flera noder samtidigt.

GFS2

Global FileSystem 2. En motsvarighet till OCFS2 från RedHat.

DLM

Distributed Lock Manager är något alla klustrade filsystem behöver för att hålla reda på vem som låst vilken fil och varifrån. När en nod går ner i ett korrekt konfigurerat kluster ska alla låsningar överföras till de överlevande noderna.

Vi kommer i det här dokumentet se att OCFS2 och GFS2 har var sin DLM som måste fungera för att filsystemet ska monteras.

Totem

Är ett sorts token-ring system som i turordning kontaktar varje nod och pratar med den för att se om den lever och vad status på den är. När en nod inte svarar startar en klocka och om en viss fördefinierad tid rinner ut utan att noden svarar så ser Totem till att noden fencas.

Corosync

Corosync hanterar kommunikation mellan noder med hjälp av totem-protokollet.

Pacemaker

Pacemaker är en sorts resurshanterare för kluster där man bland annat kan göra följande relevanta saker.

  • Definiera nya resurser och noder
  • Döpa resurser och noder
  • Välja vilka noder en resurs ska köras på
  • Välja om en resurs ska flyttas mellan noder
  • Flytta resurser mellan noder manuellt
  • Definiera fencing agenter

CRM

Cluster Resource Manager är det gränssnitt som vi använder för att konfigurera resurser i pacemaker. CRM använder normalt väldigt komplicerade XML filer för konfiguration men det förenklas i ett kommandoskal som kallas crmsh.

# crm configure show
node linuxlab01
node linuxlab02
primitive failover-ip ocf:heartbeat:IPaddr2 \
      params ip="10.220.100.100" \
      op monitor interval="30s"
location cli-prefer-failover-ip failover-ip \
      rule $id="cli-prefer-rule-failover-ip" inf: #uname eq linuxlab01
property $id="cib-bootstrap-options" \
      dc-version="1.1.7-ee0730e13d124c3d58f00016c3376a1de5323cff" \
      cluster-infrastructure="openais" \
      expected-quorum-votes="2" \
      stonith-enabled="false" \
      no-quorum-policy="ignore"
rsc_defaults $id="rsc-options" \
      resource-stickiness="100"

I Debian lagras de resulterande XML-filerna under /var/lib/heartbeat/crm.

Colocation

Colocation i CRM anger startordning och startplats för resurser, förenklat. Här är ett exempel, senare i dokumentet finns mer praktiska exempel.

colocation C inf: B A

Vi skapar en colocation-resurs vid namn C och poängvärde obegränsat (infinity). I den enklaste situationen anger vi att B ska starta där A kan starta.

En viktig detalj är att vi med B kan bestämma var A ska starta, om vi använder location.

Location
location C B 100: node01
location D A 101: node02

Här har resurs-A högre prioritet på node02.

Konceptet av colocation förklaras ytterligare här.

Order
order C inf: A B
  • Om både A och B-resursen behöver startas så startas A först.
  • om B behöver startas så startas först A.
  • Behöver A stoppas så stoppas först B.
  • Kan inte A starta så stoppa B.
  • Kan även appliceras på att befordra en resurs från Slave till Master.

Läs mer om order på clusterlabs.org.

Nyttiga kommandon

Jag tänker vara väldigt koncis i dokumentet så här är några kommandon man bör känna till för att hantera sitt kluster.

  • resource restart <resurs-id>
  • resource cleanup <resurs-id>:# (Bra om en resurs har failed actions i crm_mon. Ett kolon och en siffra på slutet anger oftast målnod.)
  • resource move <resurs-id> <nod-id>
  • resource help
  • node standby
  • node online
  • node help
  • cib new <cib-id>
  • cib list
  • cib use <cib-id>
  • cib commit <cib-id>
  • cib help
  • configure verify
  • configure edit <resurs-id>
  • configure help

Läs hjälp-texten i crmsh för mer information.

Utöver crm-skalet är crm_mon ett verktyg man bör ha igång i en terminal hela tiden för att övervaka hälsan av klustret. När man gör ändringar med kommandon som resource restart eller resource cleanup så syns de i crm_mon. De resurs-ID man gör ändringarna på syns även i crm_mon.

CIB

All konfiguration i crm kallas för cib, Cluster Information Base.

Resource Agent

Förkortas ofta RA och är egentligen bara ett program. För enkelhetens skull kommer man mest stöta på agenter skrivna i Bash eller Bourne Shell men tekniskt sett kan de vara vilket språk som helst så länge de returnerar rätt koder.

De anropas från en CRM så som pacemaker och utför olika åtgärder. Som t.ex. att starta/stoppa tjänster, eller få status om tjänster.

RA kan även vara ett vanligt LSB-skript, men där tjänster behöver vara skräddarsydda för kluster så används oftast ett säreget RA-skript.

För information om hur man skriver en RA finns i skrivande stund en utvecklarguide på ClusterLabs github repo.

DRBD

Distributed Redundant Block Device är en utökning till Linux-kärnan som möjliggör skapandet av diskenheter som replikeras över nätverk.

Det kan jämföras med multipath LUNs som erbjuds av vissa SAN-tillverkare.

CLVM

Clustered LVM, eller Clustered Logical Volume Management, är bara en klustrad variant av Linux LVM. LVM är det system i Linux som hanterar alla logiska volymer som kan växas eller krympas dynamiskt.

Det är bra praxis att skapa alla partitioner i Linux med LVM för att kunna ändra storleken av partitioner vid behov. CLVM är en utökning till LVM som gör det möjligt att ha volymer spridda över flera noder.

Klusterstackar

En orsak till förvirring är att det finns så många olika typer av stackar för att bygga kluster i Linux. Att mjukvarorna är öppna och under ständig utveckling förenklar inte.

Här går vi igenom några olika kluster-stackar för olika Linux system.

I RHEL 6 och CentOS 6 är RedHat Cluster Suite det främsta verktyget för att bygga kluster. I RHEL 7 ska cman bytas ut. I Suse är det annars OpenAIS som är den förvalda stacken. Det blir ganska förvirrande så här är en lista av olika verktyg i Linux klustervärld.

  • corosync (kommunikationstack)
  • heartbeat (alt. kommunikationstack)
  • OpenAIS (alt. kommunikationstack)
  • pacemaker (resurshantering)
  • cman (alt. resurshantering)
  • AMF (alt. resurshantering?)

Utöver den vanliga förvirringen så finns det ett projekt som heter Linux-HA och kommer med pacemaker+heartbeat. Det är alltså ett mjukvaruprojekt, samtidigt som Linux HA är ett koncept för klustring.

Konfigurera nätverket

Innan vi ens installerar någon mjukvara måste vi veta hur klustret ska se ut, jag utgår från ett kluster på två noder där varje nod har två nätverkskort. Det ena nätverkskortet är hur klustret kontaktar omvärlden, det andra är ett privat nätverk som endast ska användas för klustertrafik.

Helst ska det privata nätverket vara ett layer-2 nätverk. Så här kan /etc/network/interfaces se ut.

auto eth0
iface eth0 inet dhcp

auto eth1
iface eth1 inet static
 address 10.10.10.111
 netmask 255.255.255.0

En mycket viktig del är /etc/hosts filen som kan se ut så här.

127.0.0.1 localhost
10.10.10.111 crmnode01.local.int crmnode01
10.10.10.112 crmnode02.local.int crmnode02

Samtliga noder måste definieras med namn i /etc/hosts, det går även att använda DNS som jag uppenbart gör för det första nätverkskortet men man ska helst inte lita enbart på DNS för klustertrafik.

Det visas inte här ovan eftersom jag använder DHCP, men klustrets noder heter linuxlab01 och linuxlab02 på det externa nätverket, och det externa nätverket är 192.168.22.0/24.

Konfigurera SSH

Allt blir mycket enklare om det går att logga in på vardera nod med SSH. Just i detta fallet konfigurerar jag bara så att den första noden kan logga in på den andra noden med root-kontot.

Skapa ett par ssh-nycklar åt root på första noden.

ssh-keygen -N '' -f /root/.ssh/id_rsa

Kopiera sedan innehållet av /root/.ssh/id_rsa.pub på den första noden till /root/.ssh/authorized_keys på alla andra noder. Det går också bra att låta samtliga noder kunna logga in på varandra, eftersom det kan hända att en annan nod tar över som huvudnod i framtiden.

Säkerhet för SSH

Eftersom den här smidigheten kräver att PermiRootLogin yes är inställt i /etc/ssh/sshd_config så kan det vara bra att göra den konfigurationen lite säkrare. Framförallt borde nätverksutrustning se till att SSH inte är nåbart utifrån men OpenSSH ska också konfigureras för att endast tillåta root mellan noder.

I detta fallet heter administratörsanvändaren stemid.

PermitRootLogin yes
AllowUsers stemid@* root@192.168.22.*

Finns andra osäkra system på samma nät så kan man finjustera åtkomstreglerna lite.

AllowUsers stemid@* root@192.168.22.111 root@192.168.22.112

Då måste man så klart lägga till alla noder i /etc/ssh/sshd_config också.

Installera corosync och pacemaker

apt-get install corosync pacemaker

Några rekommenderade paket listas här.

apt-get install lsb-core incron

Debian Squeeze

Debian sta(b)le är lite efter så där måste vi installera backports för att få en jämförbar upplevelse med Ubuntu 12 LTS.

Se till att /etc/apt/sources.list.d/backports.list ser ut så här.

deb http://backports.debian.org/debian-backports squeeze-backports main

Kör en uppdatering av apt.

apt-get update

Sedan är det bäst att pinna alla paket till stable så att backports måste installeras uttryckligen. Skapa filen /etc/apt/preferences.d/default med följande innehåll.

Package: *
Pin: release a=squeeze
Pin-Priority: 200

Nu måste vi lägga till argumentet -t=squeeze-backports när paket ska installeras från backports, så här.

apt-get -t=squeeze-backports corosync pacemaker

Annars kan reste av dokumentet följas som vanligt.

Konfigurera och starta Corosync

Börja med /etc/corosync/corosync.conf som kan se ut så här. Lägg märke till nätverkskonfigurationen.

compatibility: whitetank

totem {
 version: 2
 clear_node_high_bit: yes
 secauth: off
 cluster_name: labcluster
 threads: 0
 interface {
  ringnumber: 0
  bindnetaddr: 10.10.10.0
  mcastaddr: 226.94.1.1
  mcastport: 5405
  ttl: 1
 }
}

nodelist {
 node {
  ring0_addr: crmnode01
  nodeid: 1
 }
 node {
  ring0_addr: crmnode02
  nodeid: 2
 }
}

quorum {
 provider: corosync_votequorum
 expected_votes: 1
}

logging {
 to_syslog: yes
}

amf {
 mode: disabled
}

Raden med bindnetaddr anger att multicast-trafik ska skickas i det privata nätet.

Vi konfigurerar omedelbart två tjänster, en för pacemaker och en för checkpoint som egentligen bara behövs av DLM i delade filsystem. Så checkpoint-tjänsten är inte nödvändig i alla situationer.

Filen /etc/corosync/service.d/pcmk anger att corosync ska ha stöd för pacemaker.

service {
 name: pacemaker
 ver: 1
}

Likaså är /etc/corosync/service.d/ckpt för checkpoint.

service {
 name: openais_ckpt
 ver: 0
}

Synka nu /etc/corosync med den andra noden med rsync, som görs smidigare med root-kontot tack vare ssh-nycklarna.

rsync -rav /etc/corosync linuxlab02:/etc/

Innan corosync kan startas på Debian-baserade system måste det aktiveras i /etc/default/corosync.

start=yes

Då kan även den filen synkroniseras över och tjänsten startas.

rsync -rav /etc/default/corosync linuxlab02:/etc/default/
service corosync start

Kontrollera kommunikationen med tcpdump på eth1-gränssnittet, eller använd corosync-cfgtool kommandot.

corosync-cfgtool -s
Printing ring status.
Local node ID 1864083648
RING ID 0
      id      = 10.10.10.111
      status  = ring 0 active with no faults

Konfigurera och starta Pacemaker

Pacemaker är vår CRM, den hanterar all konfiguration av tjänster i klustret. Just nu tänker vi dock bara starta den och lämna själva konfigurationen till andra dokument.

Gör detta på samtliga noder.

service pacemaker start

Kontrollera att noderna kan kommunicera genom att se till att de båda är online i utdatan av crm_mon kommandot.

crm_mon -1
============
Last updated: Sat Jan 12 20:40:25 2013
Last change: Sat Jan 12 11:55:18 2013 via crmd on linuxlab01
Stack: openais
Current DC: linuxlab01 - partition with quorum
Version: 1.1.6-9971ebba4494012a93c03b40a2c58ec0eb60f50c
2 Nodes configured, 2 expected votes
0 Resources configured.
============

Online: [ linuxlab02 linuxlab01 ]

Ser varje nod den andra som offline så är det mest troligt kommunikationsfel mellan noderna, kontrollera nätverket med tcpdump.

Konfigurera ha-logd

Pacemakers resursagenter loggar till ha-logd, så vi måste anpassa oss lite efter detta genom att redigera filen /etc/logd.cf något.

Som standard loggar logd till syslog faciliteten daemon, vilket blir väldigt förvirrande när den loggen snabbt fylls av klustersnack. Så jag brukar ändra det till en fast fil och stänga av syslog, de ändrade raderna ser ut så här.

debugfile /var/log/ha-debug
logfile /var/log/ha-log
logmode 0640
logfacility     none

Starta sedan om logd.

service logd restart

Nu kan vi följa felmeddelanden från resursagenter separat i /var/log/ha-log.

Rutiner

Unclean

  • Online UNCLEAN - STONITH har misslyckats för många gånger så noden är online men litar inte på att den är frisk.
  • Offline UNCLEAN - Kommunikationsfel oftast, kanske blandat med STONITH-fel.

Kända fel

Startskript

Både Debian och Ubuntu lider av några buggar, bland annat behöver corosync och pacemaker få sina startskript fullt aktiverade så de startar vid uppstart av systemet. Detta måste göras på samtliga noder.

/usr/lib/lsb/install_initd /etc/init.d/corosync 
update-rc.d corosync enable
/usr/lib/lsb/install_initd /etc/init.d/pacemaker
update-rc.d pacemaker enable

Startskriptet för Pacemaker i Debian saknar viktig information i LSB-huvudet, ett exempel kan se ut så här.

### BEGIN INIT INFO
# Provides:             pacemaker
# Required-Start:       $network corosync
# Should-Start:         $syslog
# Required-Stop:        $network
# Default-Start:        2 3 4 5
# Default-Stop:         0 1 6
# Short-Description:    Starts and stops Pacemaker Cluster Manager.
# Description:          Starts and stops Pacemaker Cluster Manager.
### END INIT INFO

Oftast måste startskript av tjänster som ska hanteras av Pacemaker stängas av, t.ex. om DRBD ska hanteras av en resurs i Pacemaker så måste /etc/init.d/drbd stängas av helt.

update-rc.d drbd disable

Än viktigare är detta om ett delat filsystem med en DLM ska hanteras av Pacemaker, då kan det uppstå problem vid första uppstarten om man har låtit o2cb eller ocfs2 starta sina skript innan Pacemaker gör det.

Tänk på att pacemakers resurshanterare (resource agent) vill sköta hela uppstarten och konfigurationen av resursen.

Se också

teknik/corosync_och_pacemaker_pa_debian.txt · Senast uppdaterad: 2013-01-18 13:05 av stemid