OVH Community, your new community space.

Failoverips - Roulettespiel der besonderen Sorte


Laser-12
16.03.11, 14:09
Hallo,

nachdem das Problem immer noch nicht behoben wurde, hat der Admin um die Installation des OVH Supportschlüssels gebeten. Dies habe ich auch getan.
Mein Ticket:
Code:
 Hallo,
 
 wie gewünscht wurde der OVH Supportschlüssel
 installiert. Sie können nun selbst auf den Server
 zugreifen und die Konfiguration überprüfen.
 
 Ich habe den aktuellen Stand auch noch einmal im
 Rescue-pro Modus überprüft:
 Testaufbau: 
 Auf dem Server "tcpdump -en -i eth0 ip host TESTIP"
 Von einem beliebigen anderen Rechner die TESTIP gepingt.
 
  87.98.XXX.120 ok
  188.165.XXX.76 ok
  188.165.XXX.77 ok
  188.165.XXX.78 ok
  188.165.XXX.79 ok
  178.32.XXX.73 nicht ok
  178.32.XXX.74 nicht ok
  178.33.XXX.17 nicht ok
  178.33.XXX.18 nicht ok
  178.33.XXX.41 nicht ok
  178.33.XXX.42 nicht ok
  178.33.XXX.57 hat die falsche MAC-Adresse ->
 "00:30:XX:XX:3c:f6" von der Hauptip
  178.33.XXX.58 nicht ok
 
 Ich bitte um Rückmeldung sobald Sie sich mit dem Server
 beschäftigen und sobald Sie etwas gefunden haben.
 
 MfG
und direkt auch noch Zugang zur virtuellen Maschine auf der diese IPs konfiguriert sind:
Code:
 Hallo, 
 falls Sie sich auch in die virtuelle Maschine einloggen
 möchten der diese IPs zugewiesen sind hier die
 notwendigen Daten:
 Xen-Name der VM: vmname
 DNS-Name: XXX.meinserver.com
 
 Auch hier wurde der OVH-Supportschlüssel installiert.
 
 MfG
Um 12:10 sich Angie auf dem der Hauptmaschine für 12 Minuten eingloggt und in dieser Zeit den Befehl "ifconfig" ausgeführt. Danach sofort wieder ausgeloggt.

Ihre Antwort danach war folgende:
Code:
Hallo,

arp 178.33.XXX.57 0200.0000.0dcc ARPA
arp 178.33.XXX.58 0200.0000.0dcc ARPA

Ich bestätige nochmals das diese beiden IP Adressen mit
der von ihnen im Manager ausgewählten MAC gerouted werden.

Das Problem liegt nicht an den IP Adressen sondern an der
Route des Blocks:
ip route 178.33.XXX.56 255.255.255.252 188.165.XXX.204
ip route 178.33.XXX.56 255.255.255.252 VlanX92

Doppelter Routeneintrag im Router.
Habe ich nun entfernt.

MfG,
Angie
Die einzige Änderung danach: die IP "178.33.XXX.57" kommt jetzt gar nicht mehr an dem Server an. Weder mit falscher noch richtiger MAC Adresse.

Warum wird nicht auf alle fraglichen IPs eingegangen?
Warum wird nicht einmal getestet ob es nach Änderungen geht?
Warum wird nur einmal "ifconfig" ausgeführt wenn man die Situation analysieren sollte?

Fazit: War da wirklich ein Techniker/Admin auf dem Server unterwegs oder etwa ein Auszubildender?

Gruß
Laser

Laser-12
15.03.11, 00:29
Hallo,

auf dem Server stehen mir 3 Slots zur Verfügung und nur diese Verwende ich. Das heißt, ich habe aktuell 3 FailoverIPs auf diesen Server geleitet.

Außerdem sollte er mir doch dann im Interface auf die Finger klopfen wenn ich eine FailoverIP auf einen Server umleiten wollte der keine entsprechenden freien Slots mehr hätte.

Gruß
Laser

chi
14.03.11, 23:44
Hallo,

ich setze aktiv mehrere Systeme als primary/primary Cluster ein.
Auf denen arbeiten mehrere VM`s
IP-Wechsel werden über die SOAPI abgehandel. Heartbeat übernimmt das switchen. Läuft sauber.

Kann es sein das dir die Slots auf dem einen Server ausgegangen sind?

Lg

Laser-12
14.03.11, 23:29
Hallo,

die Störungshotline ist eine schöne Sache. Sie ist 24/7 verfügbar und man kann jederzeit anrufen.

Leider sind in der Nacht allerdings keine Techniker oder Admins greifbar, somit können die Mitarbeiter keinerlei Aktionen veranlassen außer es für den nächsten Tag aufzuschreiben.
Sie haben (laut ihrer eigenen Aussage) auch nicht die Kompetenz ein Ticket zu beantworten, selbst wenn es ihnen erlaubt wäre.

Somit ist für mich die 24/7 Störungshotline eine Augenwischerei da sie nachts nicht mehr machen können als selbst ein Ticket zu eröffnen.
Tagsüber kann man wenigstens noch über wiederholte Nachfragen und dem Stille-Post-System eventuell ein paar mehr Informationen bekommen.

Beim Ticketsystem muß man auch genau aufpassen. Jede eigene Antwort bedeutet dass man vor 24 Stunden später eigentlich nicht nachfragen darf warum noch nichts geschehen ist. Egal ob die Antwort des Technikers sinnvoll oder richtig waren, die 24 Stunden Frist wurde eingehalten und man darf wieder einen Tag warten.

Gruß
Laser

Laser-12
14.03.11, 21:23
Hallo,

die Failoverips sind eine wirklich super Idee. Ideal für Umzüge ohne großen Aufwand und manchmal auch richtig stressfrei.

Wenn man sie aber wirklich einmal nutzt artet es ziemlich schnell zu einem Roulettspiel aus bei dem man nur beten kann dass alles klappt.

Als ideale Ergänzung zu den Failoverips nutze ich XEN und habe alle Services in virtuellen Maschinen. Hierfür verwende ich Bridged Mode. Wie von OVH vorgeschrieben muß jede virtuelle Maschine ihre eigene virtuelle MAC-Adresse haben und auch alle IPs für die virtuelle Maschine müssen dieser Adresse zugeordnet sein.

Mein Plan war die Migration von mehreren virtuellen Maschinen von einem Server zu einem anderen (neuere Hardware). Dazu neue Maschine ausführlich getestet und nach Erfolg alle Dateien der virtuellen Maschinen transferiert.

Bleiben nur noch die virtuellen IPs:

Erste virtuelle Maschine hat eine normale FailoverIP. Für diese den Umzug angestoßen und innerhalb von 2 Sekunden war die IP und die virtuelle MAC-Adresse auf dem neuen Server. Man hat kaum eine Unterbrechung gemerkt. Super!

Zweite virtuelle Maschine hat 11 IPs, eine normale FailoverIP und 5x einen 4er Block RIPE-FailoverIPs (jeweils nur 2 nutzbar).
Normale FailoverIP umgezogen: virtuelle MAC-Adresse taucht beim neuen Server nicht auf -> kann auch nicht manuell zugewiesen werden.
Alle RIPE-FailoverIPs umgezogen: virtuelle MAC-Adressen werden mitgenommen sofern ein RIPE-Block nicht aufgesplittet wurde.
Somit steht nun endlich die alte virtuelle MAC-Adresse auch für die erneute Zuordnung zur Verfügung wird entsprechend eingeteilt.

Laut dem Kundeninterface von OVH sieht nun alles gut aus aber es kommt kein einziges Packet an. (Mittels "tcpdump -e -i xenbr0" ausführlich überprüft)

Kundendienst angerufen, Ticket aufgemacht, Rückmeldung bekommen: Switchport des alten Servers wurde neu installiert, sollte jetzt alles funktionieren.
Auch wenn die Verbindung des alten Switchports mit dem neuen Server für mich nicht nachvollziehbar ist, so funktioniert doch wenigstens die normale FailoverIP und der RIPE-Block der aufgeteilt worden war.
Zwischenzeitlich kamen von einer weiteren IP auch mal 30% der Pings an, dies verschwand aber nach 30 Minuten.

Mehrmals mit der Störungshotline telefoniert und auch Rückmeldungen von den Admins übers Ticket bekommen. Hier ein paar Auszüge:
1. We have taken note of your message.
We are doing necessary checks and get back to you shortly.
2. Das Problem wurde korrigiert. Wir haben
die Korrektur im Bezug auf dem Router vorgenommen.
Sie sollen jetzt kein Problem haben.
3. Ich befinde mich dran, das switch ACL für Ihren Server neu
wiederspielen zu lassen.
Wenn das Problem weiterhin besteht, bitte präzisieren Sie
uns die ipfailover und geben sie uns mehr Details.
4.Von unserer Seite sehen wir kein Problem weder auf dem
Router noch auf dem Switch Ihres Servers.

Aktueller Stand der Odyssee:
Normale FailoverIP und aufgesplittete RIPE-FailoverIPs funktionieren nach der Intervention der Admins.
Von den nicht aufgeteilten RIPE-FailoverIPs kommt ein Block mit der falschen MAC-Adresse an und der Rest gar nicht.
Admins verlangen erneut Netzwerkconfig die kurz nach Ticketeröffnung als Dateianhang bereits hinzugefügt worden ist.

Bisherige Schlußfolgerungen:
- Wenn FailoverIPs umgezogen werden sollen, nehmt euch genügend Zeit und erwartet nicht dass sie immer sofort funktionieren (es ist für diese auch kein SLA angegeben!!)
- Kundendienst kann keine an Tickets angehängte Dateien einsehen
- Auch wenn die Konfiguration von allen IPs identisch ist und nur ein Teil funktioniert gehen Admins davon aus dass es an der Konfiguration liegt.
- Habt ihr virtuelle MACs, so richtet euch für jede IP auf 6 Minuten Wartezeit ein da ihr so lange warten müßt bis ihr sie erneut zuordnen dürft (sofern die alte virtuelle MAC-Adresse wieder auftaucht)
- Admins sind nur von 9 Uhr morgends bis 18 Uhr abends vorhanden und für FailoverIPs haben teilweise nur diese die entsprechenden Berechtigungen.

Fazit:
Aus einem Umzug von Samstag Nachmittag der nur ein paar Stunden dauern sollte sind es nun bereits 2,5 Tage und bisher ist noch kein Ende in Sicht.

Gruß
Laser