NRW:Arbeitsgruppe/Technik/Dokumentation/Server/IMS

Aus Piratenwiki
Wechseln zu: Navigation, Suche
AG Technik NRW
Verwaltung: Übersicht | Protokolle | Dokumentation | FAQ
Dienste: E-Mail | Lists | Blogs | Domains | RT | Mumble | LAN | Serverstatus


Intel Modular Server

Die IT-Dienste der AG Technik NRW basieren auf einem Intel Modular Server (IMS) System. Alle relevanten Komponenten wie Speichermedien, Speichercontroller, Netzwerkkarten, Switches, Server und Netzteile sind redundant ausgelegt. Im Fehlerfall ermöglichen die redundanten Komponenten ein automatisches Failover.

Zugriff

Um auf die Verwaltungsconsole des IMS zuzugreifen, ist eine Anmeldung am VPN erforderlich.Anschließend steht die Console unter folgender Adresse zur Verfügung:

  • twilightsparkle.piratenpartei-nrw.de (192.168.41.2)

Zur Anmeldung an der Verwaltungsconsole werden personifizierte Accounts und Passwörter verwendet. Um sich anzumelden, greift man mit einem Browser per https auf Port 443 auf die jeweilige Adresse zu. Je nach Einstellung erhält man Zugriff auf eine Auswahl von Server- und Speicher- und Verwaltungssystemen.

Änderungen an der Konfiguration sind bitte ausschließlich nach Rücksprache mit den anderen Mitgliedern der AG Technik NRW vorzunehmen.

MultiPath SCM

Der IMS verfügt über redundante Storage-Controller, hier wird dokumentiert wie sie einzurichten und zu warten sind.

Failover

Hintergrund

Der Intel Modular Server und Proxmox unterstützen so genanntes "failover". Dabei handelt es sich um ein Hochverfügbarkeits (HA) feature das dabei hilft trotz eines teilweise Ausfalls weiterhin erreichbar zu bleiben. HA Systeme sind recht komplex und es ist wichtig, für dessen Funktionalität einige Grundlagen zu verstehen. In unserem Fall greifen verschiedene Systeme ineinander, daher ist genaues Verständnis der Komponenten äußerst wichtig.

Failover bedeutet, dass eine andere Komponente einspringt, falls eine Komponente gleichen Typs ausfällt. Das kann zum Beispiel ein redundant ausgelegtes Netzteil im standby sein, eine USV oder ein ganzer Server. In unserem Fall handelt es sich um ein server-failover. Dabei erkennt ein so genanntes fencing-device, wenn ein physikalischer Server (compute-node) ausgeschaltet ist und eine weitere Komponente leitet die gewünschten Maßnahmen ein. Das fencing-device ist in unserem Fall das Chassis des Intel Modular Server. Per SNMP können Echtzeitdaten abgerufen werden, zum Beispiel der aktuelle Status der verfügbaren compute-nodes. Das fencing-device ist außerdem in der Lage, einzelne compute-nodes herunterzufahren, um beispielsweise eine gewollte failover Situation herzustellen. Sollte das Chassis ausfallen, ist kein failover möglich - allerdings dürfte dann die gesamte Infrastruktur betroffen sein.

Ein konkretes Beispiel: compute-node A und B sind für failover konfiguriert. Wird nun compute-node A ausgeschaltet, erkennt das fencing-device dies und compute-node B kann die virtuellen Maschinen (VMs) von compute-node A hochfahren. Da wir ein shared storage nutzen, ist dies sehr kurzfristig notwendig da lediglich die Konfiguration kopiert und die VM hochgefahren werden muss.

Die compute-nodes überwachen sich gegenseitig, lesen also permanent die Daten aller nodes über das chassis per SNMP aus. Es ist wichtig zu wissen, dass dabei nicht überprüft wird, ob die node absichtlich oder unabsichtlich heruntergefahren wurde. Per SNMP wird überprüft ob eine node ausgeschaltet ist, ein "hängendes" hostsystem kann ebenfalls zur Nichtverfügbarkeit aller VMs einer compute-node führen, würde allerdings kein failover auslösen da die compute-node noch aktiv ist. Da in unserem Fall keine Maschine mit genügend Ressourcen im hot-standby läuft, müssen Kompromisse eingegangen werden was die Verfügbarkeit von Diensten angeht. Nicht alle Dienste können bei dem Ausfall einer compute-node auf der jeweilig anderen node betrieben werden ohne weitere Ausfälle und Fehlfunktionen zu riskieren. Bei einer failover Situation ist je nach Dienst mit einer Nichtverfügbarkeit von etwa 20 Sekunden zu rechnen. Dienste die nicht für failover konfiguriert sind, werden nicht migriert und sind bis zu einer Wiederherstellung ihrer compute-node nicht mehr verfügbar. Bei dem Ausfall einer compute-node besteht trotz failover die Gefahr eines Datenverlustes falls Daten innerhalb der VM noch nicht verarbeitet wurden. Failover ist ein Notfallsystem, kein Werkzeug zur Vereinfachung von Wartungsaufgaben. Bei Wartungsarbeiten ist es ratsam, failover auszuschalten um ungewollte Migration von VMs zu verhindern.

Software

Die gegenseitige Überwachung passiert auf den Proxmox-Hostsystemen durch die Software RGManager und entsprechende Agenten für das fencing-device (fence_intelmodular). Es geschieht keine Überwachung der einzelnen VMs. Weiterhin besteht keine Überwachung der VMs. Sollte eine VM absichtlich oder unabsichtlich heruntergefahren werden bzw. abstürzen, tritt kein failover ein. Damit VMs innerhalb von Proxmox umziehen können, muss der Proxmox cluster in der Lage sein, VMs zu migrieren. Konkret wird dabei die Konfiguration einer VM von einem hostsystem auf das andere kopiert. Ist eine VM für failover vorgesehen, existiert die Konfiguration auf mehreren hostsystemen des clusters und wird bei Bedarf aktiviert.

Die Konfiguration einer VM darf nur einmal aktiv sein, ansonsten kann die Datenintegrität der virtuellen Festplatte gefährdet werden. Das ist der Grund, wieso eine compute-node erst ausgeschaltet sein muss bevor die VM auf einer anderen compute-node gestartet wird. ACPI ist eine schöne Sache, leider kommt sie einem bei HA Umgebungen ungelegen. Sollte der failover Fall eintreten, muss eine Maschine sofort ausgeschaltet werden können. Durch ACPI features wie soft-off kann sich das herunterfahren des Systems verzögern was die Migration der VMs scheitern lässt.

Konfiguration

Achtung! Noch nicht fertig! Für ordentliches failover benötigt man bei Proxmox eigentlich 3 Maschinen da sonst die Synchronisation im Cluster verloren geht sobald eine Maschine ausfällt. TODO: Lösung finden

Compute node A und B müssen sich beim herunterfahren sofort ausschalten und hochfahren sobald die Stromversorgung wieder vorhanden ist. Dazu müssen evtl. BIOS Optionen geändert werden.

Compute node A und B, GRUB boot Optionen 

acpi=off

ACPI daemon beenden und entfernen 

/etc/init.d/acpid stop
apt-get remove –purge acpid

/etc/default/redhat-cluster-pve 

FENCE_JOIN=“yes”

Compute node A 

fence_tool join

Compute node B 

fence_tool join
fence_tool ls

/etc/pve/cluster.conf Wichtig! config_version MUSS bei jeder Änderung inkrementiert werden, da die Konfiguration im Cluster sonst nicht übernommen wird und auseinanderläuft. 

<?xml version="1.0"?>
<cluster config_version="5" name="ppnrw">
  <cman keyfile="/var/lib/pve-cluster/corosync.authkey"/>
  <fencedevices>
    <fencedevice agent="fence_intelmodular" ipaddr="192.168.41.2" login="snmpv3user" name="ims" passwd="SNMPpass" snmp_auth_prot="SHA" snmp_sec_level="authNoPriv" snmp_version="3"/>
  </fencedevices>
  <clusternodes>
    <clusternode name="applejack" nodeid="1" votes="1">
      <fence>
        <method name="1">
          <device name="ims" port="1"/>
        </method>
      </fence>
    </clusternode>
    <clusternode name="rainbowdash" nodeid="2" votes="1">
      <fence>
        <method name="1">
          <device name="ims" port="2"/>
        </method>
      </fence>
    </clusternode>
  </clusternodes>
  <rm/>
</cluster>

Links

Abgerufen von „https://wiki.piratenpartei.de/wiki/index.php?title=NRW:Arbeitsgruppe/Technik/Dokumentation/Server/IMS&oldid=1851169“