Benutzer-Werkzeuge

Webseiten-Werkzeuge


openqrm_-_grundinstallation_storage

openQRM - Grundinstallation Storage

Vorbereitende Maßnahmen

Netzwerk Konfiguration

Detailierte Informationen zur Netzwerkeinrichtung siehe Netzwerkkarten bündeln - Bonding

  • speicher - 10.10.1.100 HA-Adresse
  • speicher01 - 10.10.1.101 Knoten 1
  • speicher02 - 10.10.1.102 Knoten 2

speicher01 - /etc/network/interfaces

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet manual

auto eth1
iface eth1 inet manual

# DRBD Kommunikations-Interface
auto eth2
iface eth2 inet static
      address 172.16.0.1
      netmask 255.255.255.0
      network 172.16.0.0
      broadcast 172.16.0.255

# Heartbeat Kommunikations-Interface
auto eth3
iface eth3 inet static
      address 172.16.1.1
      netmask 255.255.255.0
      network 172.16.1.0
      broadcast 172.16.1.255

# openQRM Kommunikations-Interface
auto bond0
iface bond0 inet static
      address 10.10.1.101
      netmask 255.255.255.0
      network 10.10.1.0
      broadcast 10.10.1.255
      gateway 10.10.1.1
      slaves eth0 eth1
      bond_mode 1
      bond_miimon 100
      bond_updelay 200
      bond_downdealy 200

speicher02 - /etc/network/interfaces

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet manual

auto eth1
iface eth1 inet manual

# DRBD Kommunikations-Interface
auto eth2
iface eth2 inet static
      address 172.16.0.2
      netmask 255.255.255.0
      network 172.16.0.0
      broadcast 172.16.0.255

# Heartbeat Kommunikations-Interface
auto eth3
iface eth3 inet static
      address 172.16.1.2
      netmask 255.255.255.0
      network 172.16.1.0
      broadcast 172.16.1.255

# openQRM Kommunikations-Interface
auto bond0
iface bond0 inet static
      address 10.10.1.102
      netmask 255.255.255.0
      network 10.10.1.0
      broadcast 10.10.1.255
      gateway 10.10.1.1
      slaves eth0 eth1
      bond_mode 1
      bond_miimon 100
      bond_updelay 200
      bond_downdealy 200

/etc/hosts

...
10.10.1.101     speicher01
10.10.1.102     speicher02
...

DRBD Konfiguration

Detailierte Konfigurationsanleitung siehe DRBD

/etc/lvm/lvm.conf

...
filter = [ "r|/dev/cdrom|", "r|/dev/sdb|", "a|/dev/drbd1|" ]
...

/etc/drbd.d/global_common.conf

global {
      usage-count yes;
      # minor-count dialog-refresh disable-ip-verification
}

common {
      protocol C;

      handlers {
              pri-on-incon-degr "/usr/lib/drbd/notify-pri-on-incon-degr.sh; /usr/lib/drbd/notify-emergency-reboot.sh; echo b > /proc/sysrq-trigger ; reboot -f";
              pri-lost-after-sb "/usr/lib/drbd/notify-pri-lost-after-sb.sh; /usr/lib/drbd/notify-emergency-reboot.sh; echo b > /proc/sysrq-trigger ; reboot -f";
              local-io-error "/usr/lib/drbd/notify-io-error.sh; /usr/lib/drbd/notify-emergency-shutdown.sh; echo o > /proc/sysrq-trigger ; halt -f";
              # fence-peer "/usr/lib/drbd/crm-fence-peer.sh";
              # split-brain "/usr/lib/drbd/notify-split-brain.sh root";
              # out-of-sync "/usr/lib/drbd/notify-out-of-sync.sh root";
              # before-resync-target "/usr/lib/drbd/snapshot-resync-target-lvm.sh -p 15 -- -c 16k";
              # after-resync-target /usr/lib/drbd/unsnapshot-resync-target-lvm.sh;
      }

      startup {
              # wfc-timeout degr-wfc-timeout outdated-wfc-timeout wait-after-sb;
              wfc-timeout 0;
              degr-wfc-timeout 120;    # 2 Minuten
      }

      disk {
              # on-io-error fencing use-bmbv no-disk-barrier no-disk-flushes
              # no-disk-drain no-md-flushes max-bio-bvecs
              on-io-error   detach;
      }

      net {
              # sndâbuf-size rcvbuf-size timeout connect-int ping-int ping-timeout max-buffers
              # max-epoch-size ko-count allow-two-primaries cram-hmac-alg shared-secret
              # after-sb-0pri after-sb-1pri after-sb-2pri data-integrity-alg no-tcp-cork
              after-sb-0pri discard-zero-changes;
              after-sb-1pri discard-secondary;
              after-sb-2pri disconnect;
      }

      syncer {
              # rate after al-extents use-rle cpu-mask verify-alg csums-alg
              ### 100Mbps - Beispiel
              #rate 40M;
              ### 1Gbps - Beispiel
              #rate 110M;
              #al-extents 255;
              ### 10Gbps - Beispiel
              rate 2048M;
              al-extents 511;
      }
}

/etc/drbd.d/data.res

resource data {
    on speicher01 {
            device     /dev/drbd1;
            disk       /dev/sdb;
            address    172.16.0.1:7788;
            meta-disk  internal;
    }

    on speicher02 {
            device    /dev/drbd1;
            disk      /dev/sdb;
            address   172.16.0.2:7788;
            meta-disk internal;
    }
}

automatisches aushandeln der optimalen DRBD-Parameter für die Sync- und Disk-Geschwindigkeit

Diese beiden Einstellungen haben wir mit "drbd8-utils 8.4.3" getestet, sie sollten aber auch mit "drbd8-utils 8.3.x" funktionieren.

Die hier entscheidenden Parameter heißen "sndbuf-size 0;" und "c-plan-ahead 0;":

> vi /etc/drbd.d/global_common.conf
global {
                usage-count     no;
}

common {
        startup {
                degr-wfc-timeout        0;
        }


        net {
                ...
                sndbuf-size 0;
        }

        disk {
                ...
                c-plan-ahead 0;
        }

}

Partitionierung

/dev/sda1 on / type jfs (rw,errors=remount-ro)
/dev/mapper/data-configs on /opt/etc type jfs (rw)
/dev/mapper/data-nfsdata on /data type jfs (rw)
/dev/mapper/data-openqrm on /usr/share/openqrm type jfs (rw)

Die VolumeGroup liegt auf dem Device /dev/drbd1 (data). Das DRBD wurde direkt auf /dev/sdb gelegt.

# vgs
  VG   #PV #LV #SN Attr   VSize VFree
  data   1  14   0 wz--n- 3,54t 3,52t
# lvs
  LV         VG   Attr   LSize  Origin Snap%  Move Log Copy%  Convert
  configs    data -wi-ao 52,00m
  nfsdata    data -wi-ao 20,00m
  openqrm    data -wi-ao 52,00m

Heartbeat Konfiguration

Detailierte Konfigurationsanleitung siehe Heartbeat

/etc/ha.d/ha.cf

#Logging
logfacility     local0


autojoin none

# Heartbeart communication timing
keepalive 2
deadtime 30
warntime 10
initdead 60
mcast eth3 239.0.0.43 694 1 0

# Don't fail back automatically
auto_failback off

# Heartbeat cluster members
node    speicher01
node    speicher02

# Monitoring of network connection to default gateway
ping 10.10.1.1
respawn hacluster /usr/lib/heartbeat/ipfail

/etc/ha.d/haresources

speicher02 \
      IPaddr::10.10.1.100/24/bond0 \
      mydrbd \
      drbddisk::data \
      LVM::data \
      fsck_jfs::/dev/data/configs \
      fsck_jfs::/dev/data/nfsdata \
      fsck_jfs::/dev/data/openqrm \
      Filesystem::/dev/data/configs::/opt/etc/::jfs \
      Filesystem::/dev/data/nfsdata::/data::jfs \
      Filesystem::/dev/data/openqrm::/usr/share/openqrm \
      vblade_stop

/etc/ha.d/resources.d/vblade_stop

Die Einbindung eines vblade_stop Scripts ist notwendig, da openQRM sich beim initialen Start der vblade Prozesse nicht an die Syntax des Pakets aus dem Ubuntu Repository hält. Beim Start durch die openQRM-Management-Oberfläche, z.B. im Rahmen des Neuanlegens eines AOE Devices wird das sonst übliche PID File für den vblade Prozess nicht angelegt. Beim regulären Stop der vblade Prozesse orientiert sich das normale Initscript allerdings an eben diesen PID-Files. Da diese nicht existieren, werden einige vblade-Prozesse nicht gestoppt und Heartbeat würde im Falle eines kontrollierten Clusterschwenks einen kill des init-Prozesses und somit einen harten reboot auslösen. Das eingebundene Script ist eine Kopie des normalen Init-Scripts (vblade muss natürlich bereits installiert sein um eine Kopie des Initscripts anzufertigen). Bei Übergabe des Parameters Start werden allerdings keine Aktionen ausgelöst und der Aufruf mit dem Parameter Stop wurde um eine Schleife erweitert, welche alle verbleibenden vblade Prozesse beendet, auch wenn für diese kein PID-File existiert.

#!/bin/bash
 
set -e
# set -x

# /etc/init.d/vblade start and stop the vblade daemon

test -x /usr/sbin/vblade || exit 0

. /lib/lsb/init-functions

RETVAL=0
prog=vblade

stop() {
 log_daemon_msg "Stopping vblade daemons" "vblade"
 log_progress_msg "vblade"
 if [ -x /var/run/$prog/*.pid]
 then
     for pidfile in `ls /var/run/$prog/*.pid`
     do
              kill -9 `cat $pidfile`
              rm -f $pidfile
     done
 else
     for VBLADE_PID in `ps ax | grep vblade | grep -w "bond0:0 /dev/mapper" | awk {' print $1 '}`
     do
              kill -9 $VBLADE_PID
     done
     sync
 fi
echo
}
  
case "$1" in
      start)
              ;;
      stop)
              stop
              ;;
      restart|force-reload)
              ;;
      reload)
              ;;
      *)
      echo $"Usage: $0 {start|stop|restart|reload|restart|force-reload}"
      RETVAL=1
esac

exit 0

Nachdem die Konfigs auf beiden Server publiziert wurden sollte zunächst auf dem ersten Knoten Heartbeat gestartet werden.

root@speicher01:/# scp -r /etc/ha.d/authkeys /etc/ha.d/ha.cf /etc/ha.d/haresources /etc/ha.d/resource.d speicher02:/etc/ha.d/
root@speicher01:/# /etc/init.d/heartbeat start && tailf /var/log/syslog

Wenn der Start des Heartbeat Daemons ohne Probleme verläuft, sollte ebenfalls geprüft werden, ob der Stop der Dienste ohne Probleme verläuft.

root@speicher01:/# /etc/init.d/heartbeat stop && tailf /var/log/syslog

Wenn auch hier keine Probleme angezeigt werden, kann ein Schwenk auf den anderen Clusterknoten getestet werden.

Also zunächst den Hearbeat auf dem ersten Knoten starten.

root@speicher01:/# /etc/init.d/heartbeat start && tailf /var/log/syslog

Nachdem dieser alle Ressourcen gestartet hat, den Heartbeat Daemon ebenfalls auf dem zweiten Knoten starten und einen manuellen Schwenk initiieren.

root@speicher02:/# /etc/init.d/heartbeat start && tailf /var/log/syslog
root@speicher01:/# /etc/init.d/heartbeat standby && tailf /var/log/syslog

Nach prüfung der ordnungsgemäßen Übernahme aller Ressourcen kann zurückgeschwenkt werden.

root@speicher01:/# tailf /var/log/syslog
root@speicher02:/# /etc/init.d/heartbeat standby && tailf /var/log/syslog

Nachdem Heartbeat konfiguriert wurde und der Server der erste Knoten mit seiner HA-IP-Adresse zur verfügung steht, kann mit der Integration in die openQRM Umgebung begonnen werden.

Integration in openQRM

Installation benötigter Pakete

# aptitude udate && aptitude install nfs-kernel-server vblade
# update-rc.d -f nfs-kernel-server remove && update-rc.d -f vblade remove 

Leider fehlt auch nach integration des openqrm-client das Tool /usr/bin/lockfile, welches eigentlich zusammen mit dem Paket procmail ausgeliefert wird. Da dieses Paket auf dem System aber unnötigt ist, reicht es aus das Binary vom openqrm01 zu übertragen.

root@openqrm01:/# scp /usr/bin/lockfile speicher01:/usr/bin/ && scp /usr/bin/lockfile speicher02:/usr/bin/

Installation openQRM-Client

In der GUI des openQRM-Servers findet sich unter Misc→Local-Server→About ein kleines How-To zur Integration eines Local-Server.

Zur Integration sind also folgende Befehle nötig. Bitte beachten, dass hier bereits das HA-Interface des Clusters zur Verfügung stehen muss. Im ersten Schritt wird das Integrationsscript auf das Zielsystem kopiert. Im Anschluss wird es ausgeführt, der automatische Start des Init-Scripts wird verhindert, da der Start über Heartbeat erfolgt.

root@openqrm01:/# scp /usr/share/openqrm/plugins/local-server/bin/openqrm-local-server 10.10.1.101:/tmp/
root@openqrm01:/# ssh 10.10.1.101 /tmp/openqrm-local-server integrate -u openqrm -p openqrm -q 10.10.1.80 -i bond0:0
root@openqrm01:/# ssh 10.10.1.101 update-rc.d -f openqrm-client remove

Der Link des Initscripts wird nun ebenfalls auf dem zweiten Knoten angelegt. Eine Integration des zweiten Knotens per Script ist nicht notwendig, da relevante Verzeichnisse im DRBD liegen.

root@openqrm01:/# ssh 10.10.1.102 ln -s /usr/share/openqrm/etc/init.d/openqrm-client /etc/init.d/openqrm-client

Damit die Konfigurationen von vblade und nfs auf beiden Systemen zur Verfügung stehen, sind entsprechende Konfigurationsdateien ins DRBD zu verlinken.

root@openqrm01:/# ln -s /opt/etc/vblade.conf /etc/vblade.conf
root@openqrm02:/# ln -s /opt/etc/vblade.conf /etc/vblade.conf
root@openqrm01:/# ln -s /opt/etc/exports /etc/exports
root@openqrm02:/# ln -s /opt/etc/exports /etc/exports

Um ein Problem bei der Bereitstellung von AOE Storages zu vermeiden ist es notwendig die Netzwerkschnittstelle zur Bereitstellung AOEs festzulegen. Im Standard wird versucht automatisch eine Schnittstelle zu ermitteln, was aber häufig daneben geht. Es wird oftmals das erste eth0 Interface gewählt, was in unserem Fall nicht korrekt ist.

root@speicher01:/# echo  "OPENQRM_SERVER_INTERFACE=bond0:0" > /usr/share/openqrm/etc/openqrm-server.conf
root@speicher02:/# echo  "OPENQRM_SERVER_INTERFACE=bond0:0" > /usr/share/openqrm/etc/openqrm-server.conf

Da im Script zunächst die Konfigdatei durchsucht wird und erst dann eine automatische Ermittlung der Schnittstelle stattfindet, wird nun dauerhaft bond0:0 für die Bereitstellung von AOEs genutzt.

Weitere Anpassungen zur redundanten Anbindung des Storage erfolgten durch Anpassungen an den von openQRM ausgelieferten Scripts. Da diese vom openQRM Server bereitgestellt werden, sind die Änderungen im Bereich der openQRM Management Einrichtung Dokumentiert openqrm_-_anpassungen_zur_integration_des_redundanten_local-server_storage dokumentiert

Anpassungen in der GUI

FIXME

Anpassung Heartbeat Konfiguration

Nach der Installation kann der openqrm-client in die Heartbeat Konfiguration aufgenommen werden:

/etc/ha.d/haresources

speicher02 \
      IPaddr::10.10.1.100/24/bond0 \
      mydrbd \
      drbddisk::data \
      LVM::data \
      fsck_jfs::/dev/data/configs \
      fsck_jfs::/dev/data/nfsdata \
      fsck_jfs::/dev/data/openqrm \
      Filesystem::/dev/data/configs::/opt/etc/::jfs \
      Filesystem::/dev/data/nfsdata::/data::jfs \
      Filesystem::/dev/data/openqrm::/usr/share/openqrm \
      vblade_stop \
      openqrm-client
/home/http/wiki/data/pages/openqrm_-_grundinstallation_storage.txt · Zuletzt geändert: von 127.0.0.1