Alles klar, danke für eure Information.
Hast DU Dein Problem gelöst?
Oder benötigst Du hier noch Unterstützung?
Nur so als Anmerkung nicht alles was mit Pacemaker geht, ist unbedingt sinnvoll.
Beste Grüße.
Alles klar, danke für eure Information.
Hast DU Dein Problem gelöst?
Oder benötigst Du hier noch Unterstützung?
Nur so als Anmerkung nicht alles was mit Pacemaker geht, ist unbedingt sinnvoll.
Beste Grüße.
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.
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
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..
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/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...
:/etc/netcupip # cat stonith_netcup.xml
<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ns1="http://enduser.service.web.vcp.netcup.de/">
<SOAP-ENV:Body>
<ns1:stopVServer>
<loginName>Netcupkennung</loginName>
<password>Netcuppassword</password>
<vserverName>derzukillendeserver</vserverName>
</ns1:stopVServer>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Alles anzeigen
Wenn das ganze mit CURL dann abgesetzt wird, haut es die Node auch runter...
Works as designed
/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.
Hier mit korrigiert.
[Unit]
Description=Netcupfailoverip
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/bin/curl -H "Content-Type: text/xml; charset=utf-8" -H "SOAPAction:" -d @/etc/netcupip/netcupip.xml -X POST https://www.servercontrolpanel.de:443/WSEndUser
[Install]
WantedBy=multi-user.target
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
Schritt 2
Anlegen der XML Datei mit der Konfiguration um die SOAP API anzusprechen.
<?xml version="1.0" encoding="UTF-8"?><SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:ns1="http://enduser.service.web.vcp.netcup.de/">
<SOAP-ENV:Body>
<ns1:changeIPRouting>
<loginName>12345678</loginName>
<password>daskundenpasswortfürdenwebservice</password>
<routedIP>1.2.3.4.</routedIP>
<routedMask>32</routedMask>
<destinationVserverName>v123456789012</destinationVserverName>
<destinationInterfaceMAC>co:ff:ee:00:00:001</destinationInterfaceMAC>
</ns1:changeIPRouting>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Alles anzeigen
Schritt 3
Anlegen des Systemd Services
[Unit]Description=Netcupfailoverip
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/bin/curl -H "Content-Type: text/xml; charset=utf-8" -H
"SOAPAction:" -d @/etc/netcupip/netcupip.xml -X POST
https://www.vservercontrolpanel.de:443/WSEndUser?xsd=1
[Install]
WantedBy=multi-user.target
Alles anzeigen
[size=10]
Schritt 4
Prüfen ob Systemd das Unit File findet...
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.
Schritt Sechs:
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.
Wenn das ganze abgeschlossen ist, sollte der Output auf dem Cluster folgendermaßen
aussehen.
Resource Group: rg-network
res-netcupip (systemd:systemd-netcupip): Started vserver1
res-virtual-ip (ocf::heartbeat:IPaddr2): Started vserver1
Have fun!
Alles anzeigenGrüß dich BerndH
also ich hab das damals so gemacht (und es läuft noch immer).
1. XML Datei erstellt
Diese XML wird dann von einer sh-Datei ausgeführt.
Codecurl -H "Content-Type: text/xml; charset=utf-8" -H "SOAPAction:" -d @test.xml -X POST https://www.vservercontrolpanel.de:443/WSEndUser?xsd=1
Läuft alles ohne Probleme. Evtl. musst du bei deiner XML bei dem vServername nur die Leerzeichen wegnehmen ;).
Deine Fehlermeldung "validation error" könnte auch auf Grund falscher Zugänge ausgegeben werden. Für die WebService VCP Soap API musst du separat ein Passwort vergeben, hast du das eingestellt und vergeben? Ansonsten kann man die API nicht ansteuern.
Grüße
Daniel
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
./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.
<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ns1="http://enduser.service.web.vcp.netcup.de/">
<SOAP-ENV:Body>
<ns1:changeIPRouting>
<loginName>12345</loginName>
<password>haumichblau</password>
<routedIP>1.2.3.4</routedIP>
<routedMask>32</routedMask>
<destinationVserverName> v1234567890 </destinationVserverName>
<destinationInterfaceMAC>c0:ff:ee:00:00:01</destinationInterfaceMAC>
</ns1:changeIPRouting>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Alles anzeigen
Für eine mögliche Anregung wäre ich wirklich dankbar.
Mit freundlichen Grüßen.