Hallo,
vorab bitte ich um Entschuldigung, dass ich diesen Thread ausgrabe; doch bei der Suche nach "Failover Webservice" findet man vor Allem iesen Thread hier und deshalb wollte ich hier kurz eine Info bzw. auf einen möglichen Stolperstein hinweisen.
tl;dr: Nur https://www.servercontrolpanel.de/WSEndUser?wsdl nutzen (vorne kein "v"; nicht vServerControlPanel.de)
tl;dr (extended): Mit dem Webservice https://www.vservercontrolpanel.de/WSEndUser?wsdl (mit "v" vorne, im folgenden "alter Webservice") kann eine FailOver-IP mehreren Servern zugewiesen sein. Das Verhalten des Routings ist dann nur noch mäßig zuverlässig. Laut Support soll nur noch der Webservice unter https://www.servercontrolpanel.de/WSEndUser?wsdl genutzt werden (ohne "v"; "neuer Webserivce") [Verhalten wird heute Nacht verifiziert].
Hintergrund
Ich habe in meinem Setup drei Server per corosync/pacemaker in einem Cluster, in dem die FailOverIP auch eine Ressource ist (sorgt dafür, dass die IP auf eth0:0 auf jeweils dem aktive Server gebunden wird). Ebenfalls wird ein Request an den Webservice ausgelöst, dass die FailOver-IP auf den dann aktiven Server geroutet werden soll. Was mir erst heute auffiel: Alle drei Server hatten die FailOver-IP zugewiesen (wohl, weil sie über die Zeit alle mal primary waren). Das Ganze hat die letzten Monate dennoch gut funktioniert; es wurde wohl quasi immer (Zufall?) an den "neusten" Server geroutet.
Bis heute um zwischen 8:15 und 8:30 Uhr. Da wurde die IP scheinbar gar nicht mehr geroutet oder so; auf jeden Fall kamen Pakete, die an diese IP gesendet wurden auf keinem der drei Server an. Zuvor wurde kein Request an die API ausgelöst und ich (alleiniger Zugriff auf CCP / SCP) war noch am frühstücken. Ich hab ca. 1,5h gebraucht bis ich realisiert habe, dass im SCP an allen drei Servern die FailOverIP dran steht. Habe sie dann bei allen drei entfernt und absichtlich den aktuellen Primary gekillt, um ein FailOver zu provozieren; danach ging alles wieder wie gewohnt.
Zwischenzeitlich habe ich mit dem Support Kontakt aufgenommen (NC-2017071710002805) und hoffe, dass durch die Umstellung des Webservices das Problem nicht mehr auftreten kann.
Da die FailOverIP im produktiven Betrieb ist, werde ich erst heute Nacht testen können, ob das FailOver-Switching mit dem neuen Webservice zuverlässig funktioniert oder ob die IP dann wieder an allen Servern dran steht.
Vielleicht hilft jemandem, der auf ähnliche Probleme stößt, dieser Post.