Skip to content

Systemd SLES12 Pacemaker und Apache

Wer wie ich das grenzenlose Glück besitzt, sich mit Pacemaker Clustern rum plagen zu müssen.... dem sei folgender Tip an die Hand gegeben.

Seit SLES12 mit Systemd ausgeliefert wird, ist der Heartbeat Apache Agent obsolet.

Wer seinen Cluster weiter mit folgender primitive konfiguriert...

 

crm configure primitive res-apache apache \         params configfile="/etc/apache2/httpd.conf" \         op start interval=0 timeout=40 \         op stop interval=0 timeout=60 \         op monitor interval=10 timeout=20 \         meta target-role=Started

Wird ziemlich auf die Schnauze fliegen... seit SLES12 liest der Agent  /etc/sysconfig/apache2

nicht mehr korrekt aus, dies hat zur Folge das einige Module wie z.B. mod_proxy nicht mehr sauber geladen werden.

Der aktuelle Workaround, oder sagen wir mal neue Standard... ist das ganze mit dem Systemd Manifest zu konfigurieren.

 crm configure primitive res-apache systemd:apache2 

Das ganze auch Ohne Parameter!



Zerstören von Filesystemem und Clusterresourcen

ist toll!! wink

Besonders wenn man es mit offiziellem Segen machen kann. laugh

Als erstes deaktivieren wir die NFS Ressource und die virtuelle IP .... wir wollen ja nicht auf die Nase fallen.

Das unmounten der Filesysteme bitte vorher erledigen insbesondere wenn diese in Zonen hängen. wink

umount /export/zones/s1haumichblau_SAP/zonepath/root/backup

clrs "disable" "haumichblau_SAP_backup_nfs_rs"

clrs "disable" "haumichblau_SAP_backup_addr_rs"

Wir zerstören mit vollem Enthusiasmus die Softpartitions....

metaset -s haumichblau_SAP_backup_dg -P

Da das Diskset im Cluster hängt müssen die Devices weg geschmissen werden.

metaset -s haumichblau_SAP_backup_dg -d -f /dev/did/rdsk/d1

metaset -s haumichblau_SAP_backup_dg -d -f /dev/did/rdsk/d2

metaset -s haumichblau_SAP_backup_dg -d -f /dev/did/rdsk/d3

metaset -s haumichblau_SAP_backup_dg -d -f /dev/did/rdsk/d4

Wir entfernen die Mediatoren..

metaset -s shared_PSP_backup_dg -d -m sapbacknode01 sapbackupnode02

Im folgenden ist es wichtig das Metaset auf der letzten Aktiven Node zuletzt zu löschen!

metaset -s shared_PSP_backup_dg -d -h sapbacknode01

metaset -s shared_PSP_backup_dg -d -h sapbackupnode02

Nach dem dies alles abgearbeitet ist können wir uns an das zertrümmern der Cluster Ressource Gruppe machen.

Also entweder man nimmt die sanfte und sichere Vorgehensweise....... die natürlich mit höherem Zeitaufwand... verbunden ist...


 clrs "disable" "haumichblau_SAP_backupstorage_res"

 clrs "delete" "haumichblau_SAP_backupstorage_res"


clrs "delete" "haumichblau_SAP_backup_nfs_rs"

 clrs "delete" "haumichblau_SAP_backup_addr_rs"

Ressource Gruppe abklemmen und

clrg "offline" "haumichblau_SAP_backup_rg"


 clrg "delete" "haumichblau_SAP_backup_rg"

Oder man nimmt die Gummihammermethode 

clrg delete haumichblau_SAP_backup_rg +

Am Ende des Tages sollte man unbedingt! Die unter /etc/zones/ liegenden Zone xml Files anpassen und die zerstörten Filesysteme aus der Konfig entfernen... denn sollte der Cluster irgendwann mal schalten müssen und die Zone.xml wurde nicht angepasst, kommt die Zone nicht mehr hoch.  wink

Strato High Availability the open Issue with the Cluster_IP Feature

My webhoster is offering a feature called Cluster IP.

In particular it's a floating public IP Adress.

The issue with this feature is a very poor documentation.

They also offer a "brilliantly an well crafted" Script, for manual switching the IP Adress. 

Hohoho... tongue

If you want to switch the IP you have to forward a Username and a Password.... thats why you need a separate Script.

But manual switching doesn't make any sense, if your Clusterframework should manage the Failover Scenario. Regarding this the Documentation lacks not only a lot, it's a devastating black hole.

If we talk about High Availability, we talk also about Cluster Frameworks. The prefered LInux Clusterframework is called Corosync Pacemaker, the current Heartbeat Successor.  All Major Distributions are shipping this Framework.

After reading the Documentation, i found out, the necessary Cluster Agent for my Use Case is the Agent IPaddr in Case it offerd a flag called

local_start_script

So it thougt brilliant.... thats it... lets rock!! laugh

I started configuring the Ressource... the Ressource failed over as expected, unfortunately the Script itself wasn't triggerd.

Later on i had a look into the Agent itself, i was wondered, there wasnt any code related to the

local_start_script

Flag...  you may expect i was wondered.. ? Yes i really was. So i sent a Mail to the Clusterlabs Mailing List   cause i thought i missed something out, and wanted to ask for Clarification, cause i was quite unsure.

As i suspected the Code was removed, but remained within the Meta Datas like one guy confirmed,.

To solve my annoying issue i checked out an old Version from IPaddr Agent.

Took the necessary Code,

###################################################
#added local_start_script_value################
if [ ! -z "${OCF_RESKEY_local_start_script}" ]; then
if [ -x "${OCF_RESKEY_local_start_script}" ]; then
${OCF_RESKEY_local_start_script} $*
      fi
fi
 

Made use of lovely vi /usr/lib/ocf/resource.d/heartbeat/IPaddr Ifound a proper place at Line 638 

and

Deployed the modified Agent on the Nodes and now it works.

ZFS on Linux mit DRB verheiraten.

Wie wir ja alle wissen, ist der alte Sun Werbeslogan "The last word in Filesystems" in punkto ZFS nicht so ganz übertrieben.

Seit einigen Monaten gibt es wie ich schon vor einiger Zeit erwähnt habe vom Lawrence Livermore Institute ein Kernelmodul für ZFS.

In jedem Fall kann man damit gleich mehrere Klappen auf einmal schlagen. Wer LVM und geschätzte Drei Millionen Filesysteme schon immer für den letzten Gammel gehalten hat, kann stattdessen ZFS einsetzen.  Es auf Linux extrem stabil und meine Erfahrungen sind bisher durchweg positiv. Obwohl mehrere Virtualboxen parallel schon  aus einem Pool rausgefahren wurden.

Wer noch mutiger ist/ auf Schmerzen steht. wink Kann das ganze noch mit DRBD verheiraten. Die Pakte müssen natürlich je nach Distribution nach installiert werden, mit dem Paketmanager der Wahl. wink

Man kreiere auf zwei Knoten einfach mal zwei identisch große ZVOLS mit wie in diese Beispiel verwendet 4GB


zfs create -V 4g clusterpool/drbd 

zpool status pool: clusterpool state: ONLINE scan: scrub repaired 0 in 0h23m with 0 errors on Tue Oct 25 09:21:18 2011 config: NAME STATE READ WRITE CKSUM clusterpool ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 sda ONLINE 0 0 0 sdb ONLINE 0 0 0

Da das ZVOL nur als Container fungiert... ist es im Prinzip auch völlig wurscht was man dort im Endeffekt parkt. In jedem Fall sollte das ganze dann unter Linux bei der Pruefung so oder ähnlich aussehen.. wink

root@node1:~# ls -latr /dev/zvol/clusterpool/ total 0 lrwxrwxrwx 1 root root 9 Oct 18 14:19 drbd -> ../../zd0 drwxr-xr-x 3 root root 60 Oct 18 14:19 .. drwxr-xr-x 2 root root 60 Oct 18 14:19 .

 


"ZFS on Linux mit DRB verheiraten." vollständig lesen

SC 3.2 bin ich völlig meschugge??? UPDATE

oder einfach blos blind ???

-- IPMP Groups --


              Node Name           Group   Status         Adapter   Status 

              ---------           -----   ------         -------   ------

  IPMP Group: gnom                bacula_ipmp Online         vnic5     Standby

IPMP Group: gnom bacula_ipmp Online vnic4 Online IPMP Group: gnom zonec_ipmp Online vnic3 Standby IPMP Group: gnom zonec_ipmp Online vnic2 Online IPMP Group: gnom sc_ipmp0 Online vnic1 Standby IPMP Group: gnom sc_ipmp0 Online myk0 Online
Ressourcegruppe abklemmen

clrg offline bacula-rg

Ressource abklemmen....

clrs disable datenhalde-pool-rs

Ressourcegruppe auf unmanaged setzen...

clrg unmanage bacula-rg

  clrslh create -g bacula-rg -N NetIfList=bacula_ipmp@gnom -h gnom  bacula-lh-rs
clrslh:  NetIfList=bacula_ipmp not configured on gnom

 clrslh create -g bacula-rg -N NetIfList=bacula_ipmp@bacula-lh bacula-lh-rs 
clrslh:  Unable to validate  bacula-lh as nodename or nodeid.

 grep bacula-lh /etc/hosts
xxx.xxx.x.120 bacula-lh

grep gnom /etc/hosts
xxx.xxx.x.100 gnom gnom.local localhost loghost 

 cat /etc/nodename 
gnom
 cat /etc/cluster/nodeid 
1

Ich frage mich grad wirklich was ich übersehe...... irgendwo seh
 ich grad den Wald vor lauter Bäumen nicht mehr.
Wieso verschluckt sich die Kiste am Logical Hostname...?? 
Bei mehreren IPMP Gruppen muss ich ja mit NetIFList arbeiten.

kopfkratz

Update

Kreative "Problemlösung/Workaround"

Alle IPMP Gruppen, bis auf

"sc_ipmp0" in die Tonne klopfen.....

clrslh create -g bacula-rg -h bacula-lh -N sc_ipmp0@gnom bacula-lh-rs

clrs enable datenhalde-pool-rs

clrs enable bacula-lh-rs

clrg manage bacula-rg

clrg online bacula-rg

root@gnom:/etc# clrg status bacula-rg === Cluster Resource Groups === Group Name Node Name Suspended Status ---------- --------- --------- ------ bacula-rg gnom No Online Nicht wirklich befriedigend.... normal aber so funktionierts dann... doch..

FreeBSD und Ha Storage

Mittlerweile hat es sich ja schon rumgesprochen, das auch FreeBSD ZFS nutzt...

Was FreeBSD bisher eigentlich immer gefehlt hat, war eine HA Loesung, vergleichbar zu Veritas Cluster, Sun Cluster, RHEL Cluster.

So langsam tut sich aber was im Daemonwald. wink

Die FreeBSD Buben, zimmern auf Basis von CARP  eine HA Loesung das ganze nennt sich HAST und steckt zwar noch in den Kinderschuhen, aber es ist ein Anfang und ich bin gespannt wie vital sich das Projekt entwickelt. Wenn es zu einer echten Alternative zum Sun Cluster Modul HAStorage Plus würde, wäre glaub ich niemand traurig und CARP bewährt sich ja schon lange. wink

Im Moment wird zwar nur der Storage hochverfügbar gemacht, aber es ist ein Anfang. :)