Beiträge von BerndH

    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
    crm configure primitive stonith_external_ipmi_res-stonith-schiessmichtotknoten0 stonith:external/ipmi \
    
    params hostname=schiessmichtotkntonen0 ipaddr=1.2.3.5 userid=Administrator
    passwd=12345passwd interface=lanplus \
    op start interval=0 timeout=30 \
    op stop interval=0 timeout=30 \
    op monitor interval=1800 timeout=30 start-delay=0

    Code
    crm configure primitive stonith_external_ipmi_res-stonith-schiessmichtotknoten1 stonith:external/ipmi \
    
    params hostname=schiessmichtotknoten1 ipaddr=1.2.36.4 userid=Administrator
    passwd=12345passwd interface=lanplus \
    op start interval=0 timeout=30 \
    op stop interval=0 timeout=30 \
    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
    crm configure location location_stonith_ipmi_schiessmichtotknoten0-
    stonith_external_ipmi_res-stonith- schiessmichtotknoten0 -inf: schiessmichtotknoten0
    crm configure location location_stonith_ipmi_schiessmichtotkntoten1-
    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.

    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. :)

    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. :)

    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
    /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/
    <?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.

    :)

    In Anlehnung an das Thema Failover IP und Ansteuerung der SOAP Api über den Corosync Pacemaker Cluster.


    Die entscheidende Anregung habe ich in diesem Thread im Betcup Forum gefunden.


    Hier noch mal meinen herzlichen Dank noch an die Threadteilnehmer. :)
    Daran angelehnt habe ich mir folgende Prozedur zusammen gebastelt, die auch funktioniert.


    Hier beschreibe ich nur die Konfiguration wie man Pacemaker beibringt das Er die IP schalten und verwalten soll. Eine weitergehende Clusterkonfiguration beschreibe ich hier nicht. Nur die von mir verwendete Methode um das ganze zum fliegen zu kriegen. Eine weitergehende Clusterkonfiguration, ist in dem Thread nicht vorgesehen.
    Schritt 1


    Grundsätzlich kann die Prozedur mit jedem Pacemaker Cluster umgesetzt werden und ist nicht distributionsabhängig.
    Ein Sonderfall ist CentOS. Beim Einsatz von CentOS müssen die Primitives und Gruppen mit der PCS Shell umgesetzt werden.


    Schritt 1


    Anlegen folgender Directories auf allen Maschinen


    Code
    mkdir /etc/netcupip
    cd /etc/netcupip


    Schritt 2


    Anlegen der XML Datei mit der Konfiguration um die SOAP API anzusprechen.


    Code
    vi  netcupip.xml




    Schritt 3


    Anlegen des Systemd Services



    Code
    vi /usr/lib/systemd/system/systemd-netcupip.service


    [size=10]


    Schritt 4


    Prüfen ob Systemd das Unit File findet...


    Code
    systemctl list-unit-files |grep netcup


    Code
    systemd-netcupip.service                disabled


    Schritt Fünf


    Konfigurieren des Dienstes im Cluster


    Die Bezeichnung res-netcupip steht nur für den Namen Resource/primitive systems:System-netcupip für den Aufruf des Dienstes durch das Clusterframework.


    Code
    crm configure primitive res-netcupip systemd:systemd-netcupip


    Schritt Sechs:


    Code
    primitive res-virtual-ip IPaddr2 \\
            params ip=46.1.2.3  cidr_netmask=32 lvs_support=false nic=eth0 \\
            op start interval=0 timeout=600 \\
            op stop interval=0 timeout=600 \\
            op monitor interval=10 timeout=240 \\
            meta target-role=Started



    Die erzeugten Ressourcen packen wir noch in eine Gruppe.



    Code
    crm configure group rg-network res-netcupip res-virtual-ip \\
            meta target-role=Started


    Wenn das ganze abgeschlossen ist, sollte der Output auf dem Cluster folgendermaßen
    aussehen.


    Code
    Resource Group: rg-network
    res-netcupip (systemd:systemd-netcupip): Started vserver1
    res-virtual-ip (ocf::heartbeat:IPaddr2): Started vserver1







    Have fun! :D

    Hallo.


    Hab es grad selbst fest gestellt... typisches Layer 8 Problem. Hab eben kein Passwort erstellt für den Webservice.
    Nach dem ich das Passwort erstellt hab, klappt es jetzt auch mit der Nachbarin. :)


    Vielen Dank und auch beste Grüße

    Guten Tag.
    Erst mal Danke für den wirklich sehr hilfreichen Thread. Aktuell stehe ich vor der gleichen Herausforderung und habe das ganze jetzt mal bei mir nach gebaut.


    Aber anscheinend übersehe ich etwas. Beim Aufruf des XML Files durch Curl bekomme ich folgende Fehlermeldung

    Code
    ./switch.sh 
    <?xml version='1.0' encoding='UTF-8'?><S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"><S:Body><S:Fault xmlns:ns4="http://www.w3.org/2003/05/soap-envelope"><faultcode>S:Server</faultcode><faultstring>validation error</faultstring></S:Fault></S:Body></S:Envelope>v1234567890:~ #




    Woher der Validation Error kommt ist für mich jetzt nicht wirklich nachvollziehbar.


    Das XML File sieht wie oben beschrieben aus.




    Für eine mögliche Anregung wäre ich wirklich dankbar.


    Mit freundlichen Grüßen. :)