Stonith Device per Netcup API

  • Inwieweit das Thema für andere User Relevanz hat, sei jetzt mal dahin gestellt.


    Nur meiner Überzeugung nach sollte ein HA Cluster nie ohne ein Quorum Device, respektive unter Linux nie ohne Stonith Device ausgerollt werden.


    How ever, in Anlehnung an die

    folgenden Threads:

    https://forum.netcup.de/netcup…hlight=corosync#post84321

    https://forum.netcup.de/anwendung/sonstige-anwendungen/p78056-vcp-soap-api-ansteuerung-der-api-per-bash-für-failoverip/?highlight=webservice%2Bapi#post78056

    https://forum.netcup.de/admini…hlight=corosync#post78337


    Hab ich mir mal ein paar Gedanken zum Thema gemacht.


    Der Stonith Agent muss die affektierte Node, einfach komplett abschiessen..

    Prinzipiell funktioniert der Kalt Test schon mal...




    Wenn das ganze mit CURL dann abgesetzt wird, haut es die Node auch runter...

    Works as designed



    Code
    1. /usr/bin/curl -H "Content-Type: text/xml; charset=utf-8" -H "SOAPActio/WSEndUsertc/netcupip/stonith_netcup.xml -X POST https://www.servercontrolpanel.de:443/
    2. <?xml version='1.0' encoding='UTF-8'?><S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"><S:Body><ns2:stopVServerResponse xmlns:ns2="http://enduser.service.web.vcp.netcup.de/"><return><success>true</success></return></ns2:stopVServerResponse></S:Body></S:Envelope>v

    Mir stellt sich jetzt nur die Frage ob das so schon jemand umgesetzt hat, oder ich jetzt das Rad gerade neu erfinde.

    :)

  • Hm...ich arbeite ja ziemlich viel mit HA Clustern, aber dieser Methode bin ich bisher noch nicht begegnet. Sehe da ehrlich gesagt auch nicht so viel Nutzen drin.


    Wie sieht denn dein Szenario aus, bei dem du das benötigst? Im Grunde gibt es ja nur 2 mögliche Fehler: Hardware Fehler (dann ist der Node eh tot) und Software Fehler (z.B. könnte der PHP Dienst sterben, dann schwenkt die Failover-IP auf den noch funktionierenden Node).


    Wenn ich bei einem Software-Fehler den kompletten Node abschieße, dann ist dieser Vorgang ja einmalig, d.h. der Node kann von selbst nicht mehr aktives Mitglied des Clusters werden. Was machst du, wenn z.B. der Health-Check mal fälschlicherweise denkt, der Dienst sei nicht mehr da und den Node einfach so abschießt? Irgendwie ist mit diese Methode etwas zu radikal :-). Aber mich würde es sehr interessieren, wenn du mal beschreiben würdest, warum du das so machen willst.

  • Prinzipiell komm ich vom Solaris Cluster....


    Radikal ist an der Methode eigentlich gar nix... sondern dort das normale.. um die Split Brain Situation

    (Ich bin Brian, nein ich bin Brian)

    zu unterbinden, entscheidet beim


    Solaris Cluster das Quorum Device. Das praktisch das Mehrheitsverhältniss regelt.

    Der Stonith tut ja im Prinzip das gleiche nur das Er sich irgend eines Device bedient sei es bei HP das ILO oder das DRAC vom anderen Hersteller.


    Mittels Failure Fencing will ich ja verhindern das mir im Fehlerfall die Büchsennicht die Daten korrumpieren.

    Wäre ja nicht das erste mal das ich sowas sehe... bevor mir ein amoklaufender Cluster die NON Cluster Filesysteme auf beiden Nodes mounted und ich danach nur noch Schrott auf der Platte habe... und gemäß der Losung : "Backup können wir... aber können wir auch Restore?" Hau ich persönlich lieber mit der Holzhammermethode drauf. :)

  • In der Linux Welt hat man ja genau deswegen auch immer einen Cluster mit einer ungeraden Anzahl an Nodes, die ihren Master dann selbst wählen (MySQL Galera Cluster z.B.). So kann es kein Split-Brain Szenario geben, da es immer eine Mehrheit geben muss. Kommt aber auch auf die Software drauf an, das kann dann teilweise schon unterschiedlich geregelt werden.


    In deinem Fall hat halt das Quorum Device das Sagen. Aber was machst du, wenn dieses selbst mal einen Schaden hat und nicht mehr richtig arbeitet? Dann ist ja dein kompletter Cluster down (Single Point of Failure). Muss aber auch dazu sagen, dass ich Solaris nicht so gut kenne und mir das Verhalten vermutlich deswegen auch etwas fremd vor kommt.

  • In der Linux Welt hat man ja genau deswegen auch immer einen Cluster mit einer ungeraden Anzahl an Nodes, die ihren Master dann selbst wählen (MySQL Galera Cluster z.B.). So kann es kein Split-Brain Szenario geben, da es immer eine Mehrheit geben muss. Kommt aber auch auf die Software drauf an, das kann dann teilweise schon unterschiedlich geregelt werden.


    In deinem Fall hat halt das Quorum Device das Sagen. Aber was machst du, wenn dieses selbst mal einen Schaden hat und nicht mehr richtig arbeitet? Dann ist ja dein kompletter Cluster down (Single Point of Failure). Muss aber auch dazu sagen, dass ich Solaris nicht so gut kenne und mir das Verhalten vermutlich deswegen auch etwas fremd vor kommt.

    Das Problem hast Du bei Solaris natürlich auch, wobei es da klare Vorgaben gibt, was Du darfst und was nicht.

    Sonst sagt Dir das Orakel ganz schnell: "Bub! Unsupported Setup, Ticket geschlossen!" ^^


    Wobei die Disken bei Solaris, generell über Fibre Channel HBA's mehrpfadig angebunden sind und in 99,9 % aller iNstallation ausschließlich dem SAN kommen.


    Sicher das mit den ungerade Nodes ist mir natürlich auch als "Problemlösung" gekommen. Wobei ich auch durchaus Kunden kenne, die auch unter Linux nur Zwei Knoten Cluster fahren und ihre Knoten dann über das ILO ins Nirvana schießen.


    In jedem Fall sag ich Dankeschön fürs antworten. :-)

  • Stonith-Device/OCF bin ich unbedingt dafür. Steht seit einigen Wochen auch bei mir im internen Ticket-System.


    Hatte im Mai (?) ein ärgerliches Split-Brain Szenario aufgrund einer unbekannten temporären nicht-Erreichbarkeit eines Nodes, der mangels Stonith-Fencing nicht abgeschossen wurde und meinte er sei noch Master...

  • Stonith-Device/OCF bin ich unbedingt dafür. Steht seit einigen Wochen auch bei mir im internen Ticket-System.


    .

    Deswegen hab ich ja gefragt ob das schon jemand angefangen hat.


    Prinzipiell stell ich mir das so vor wie beim IMPI Lan Agenten fürs ILO4 wo das Stonith Device auf beiden Seiten konfiguriert wird...

    und mit einer ich nenn es mal Strong Affinity Rule über Kreuz auf die Nodes gebunden wird....


    z.B. hier am Beispiel vom Stonith IPMILan Agent.... ach ja.... Notationsfehler bitte ignorieren...... darauf kommst jetzt grad nicht an. ;)




    Code
    1. crm configure primitive stonith_external_ipmi_res-stonith-schiessmichtotknoten0 stonith:external/ipmi \
    2. params hostname=schiessmichtotkntonen0 ipaddr=1.2.3.5 userid=Administrator
    3. passwd=12345passwd interface=lanplus \
    4. op start interval=0 timeout=30 \
    5. op stop interval=0 timeout=30 \
    6. op monitor interval=1800 timeout=30 start-delay=0

    Code
    1. crm configure primitive stonith_external_ipmi_res-stonith-schiessmichtotknoten1 stonith:external/ipmi \
    2. params hostname=schiessmichtotknoten1 ipaddr=1.2.36.4 userid=Administrator
    3. passwd=12345passwd interface=lanplus \
    4. op start interval=0 timeout=30 \
    5. op stop interval=0 timeout=30 \
    6. op monitor interval=1800 timeout=30 start-delay=0

    So stell ich mir das dann mit den Affinity Rules, bzw.. Location Constraints vor...

    Die Regel hier unten würde besagen... das das Stonith Device von schiessmichtotknoten 0 nie auf Schiessmichtotknoten0 starten darf

    Ebenso dürfte das konfigurierte schiessmichtotknoten1 Stonith nie auf Schiessmichtotknoten1 starten..

    Code
    1. crm configure location location_stonith_ipmi_schiessmichtotknoten0-
    2. stonith_external_ipmi_res-stonith- schiessmichtotknoten0 -inf: schiessmichtotknoten0
    3. crm configure location location_stonith_ipmi_schiessmichtotkntoten1-
    4. stonith_external_ipmi_res-stonith- schiessmichtotknoten1 -inf:  schiessmichtotknoten1 


    Was im Endeffekt dann zum Abschuss in die ewigen Jagdgründe führen sollte.. so ähnlich stelle ich mir das mit Web API vor.

  • Okay, nach einigem testen und implementieren in corosync, habe ich nun das Problem, dass mir der Webservice nicht mehr schnell genug antwortet.


    Code
    1. May 31 20:00:53 atom stonith-ng[910]: notice: Child process 1038 performing action 'monitor' timed out with signal 15
    2. May 31 20:00:53 atom stonith-ng[910]: notice: Operation 'monitor' [1038] for device 'fence_atom' returned: -62 (Timer expired)
    3. May 31 20:00:54 atom crmd[914]: error: Result of start operation for fence_atom on atom: Timed Out


    Gibt es da Limits wie oft ich die Webservice API anfragen darf?

  • Wäre bisher zumindest nicht bekannt. Ich vermute jedoch, dass die Aktion synchron ausgeführt wird, also erst eine Response kommt, wenn der Server tot ist. Was für ein Timeout-Interval ist denn eingestellt?

    Also laut:

    Code
    1. pcs status
    2. fence_atom_start_0 on atom 'unknown error' (1): call=21, status=Timed Out, exitreason='none',
    3. last-rc-change='Thu May 31 20:00:33 2018', queued=0ms, exec=20010ms


    Sind wohl 20 Sekunden zu wenig um auf einen simplen getVServerState Response zu warten.


    Oder ich hab im python script richtig bock-mist gebaut. Bei den ersten tests funktioniere es bei manueller bedinung einwandfrei. Nun irgendwie nicht mehr.

  • Ich habe das Skript nochmal manuell ausführen lassen, um rein nur den Status abzufragen.


    Code
    1. time fence_netcup_soap -a www.servercontrolpanel.de -l <nc-user> -p <passwort> -z -n <server> -o on
    2. Success: Already ON
    3. real 6m32,121s
    4. user 0m0,444s
    5. sys 0m0,056s


    Das ganze läuft mit der anweisung eine schon aktive Box zu starten. (parameter -o on)

    Das sind gesamt 3 Requests. 2 mal um alle Server aufzulisten und 1 mal um den aktuellen zustand zu holen.

    Erst wenn da offline rauskommen würde, würde noch ein 4ter Request starten um den Server wieder zu starten.


    Aber 6 minuten um 3 simple Status Requests zu senden finde ich jetzt doch etwas viel.

    Kein wunder das mir Corosync nach 20 Sekunden sagt Time-out.


    PS.: Code für fence liegt hier: https://github.com/realM4C/fence_netcup_soap