Linux-HA: Pacemaker und Multicast
Prinzipiell sehe ich das auch so, keine Funktionalität nachzubauen, die eh schon vorhanden ist.
Was allerdings nicht abgedeckt ist, ist der Fall, dass Maschinen gezielt nicht erreichbar sein sollen (bspw. bei Konfigurationsänderungen oder OS-Updates und -Upgrades), der Serververbund an sich aber weiterhin erreichbar und funktional bleiben soll.
Ein weiteres Thema kann irgendwann die Skalierung werden, wenn eine VM "zu groß" für einen Host würde. In diesem Fall sähe ich einen Verbund aus mehreren VMs, die die aktuelle Last bearbeiten und ggf. auf mehrere Hosts aufgeteilt werden, im Vorteil gegenüber einer großen monolithischen VM.
Das klappt so nicht, was möglich wäre:
VMware HA -> falls Host A ausfällt, wird die VM auf Host B gestartet (wenige Minuten)
VMware FT(ab Host L verfügbar) -> falls Host A ausfällt, springt automatisch Host B (Sekundär) ein (Fail-Over-Prinzip) -> VM ist auf beiden Hosts installiert (Master und Slave).
Die vorhandenen Funktionen mit anderen zu ersetzen halte ich für falsch, nutze am besten HA, FT etc und gleiche die VMs untereinander ab, fall dies nötig ist.
Eine PublicIP auf mehreren VMs starten geht so leider nicht und kann im besten Fall zur Blockade auf dem Switch führen, wenn unterschiedliche MAC-Adressen die IP melden.
Stefan
Hallo,
bei unseren Überlegungen, ob wir unsere Infrastruktur in die OVH "Private Cloud" migrieren sollten, spielt unter anderem das Thema Multicast eine Rolle:
Einige der virtuellen Maschinen sollen via Linux-HA (Corosync + Pacemaker) als Loadbalancing- und Failover-Cluster arbeiten, um einzelne Hosts gezielt aus dem Betrieb zu nehmen (bspw. für Konfigurationsänderungen oder OS-Update/-Uprgades). Dazu müsste (zumindest für die öffentlich ansprechbaren Loadbalancer-VMs) eine öffentliche IP-Adresse zwischen mehreren VMs ge- bzw. verteilt werden.
Zur Verwaltung einer solchen Cluster-IP verwendet Pacemaker Multicast MAC-Adressen. Laut Aussage des OVH-Supports ist Multicast mit dem derzeitigen Netzwerk-Equipment bei OVH nicht kompatibel / machbar und damit wäre diese Lösung nicht machbar (wäre für uns ein Ausschlusskriterium).
Andererseits würde ich vermuten, dass Multicast innerhalb eines virtuellen vSwitch durchaus machbar ist, d.h. Traffic an eine IP-Adresse aus dem konfigurierten Bereich der VMs wird nur an den VMWare-Host gesandt, welcher dann die Pakete entsprechend an die VMs verteilt, oder habe ich hier einen Denkfehler?
Hat jemand Erfahrung mit diesem Thema und / oder eine andere sinnvolle Lösung für dieses Problem auf der OVH Private Cloud Infrastruktur realisiert?
Bin für jedes Feedback dankbar, da ich den Ansatz für VMware-Hosting bei OVH sehr ansprechend finde und sehr gerne auf diese Infrastruktur wechseln würde.
Viele Grüße
ekmek
