Ich versuche, einen Proof of Concept zu konfigurieren, bei dem ein Server automatisch hochgefahren wird und einem Replikationscluster beitritt. Wenn der Server nicht mehr benötigt wird, wird er heruntergefahren und automatisch aus dem Cluster entfernt.
Es gibt keine Möglichkeit, IP-Adressen vorab festzulegen, und es gibt auch keine Möglichkeit zu steuern, welche Server heruntergefahren werden, wenn weniger Server benötigt werden. (Amazon Auto-Scaling)
Wie kann ich den Server dazu bringen, den bereits vorhandenen Gluster-Cluster zu erkennen und ihm beizutreten? Ich dachte daran, einen Cron-Job @reboot auszuführen, der das Netzwerk prüft, um zu sehen, ob irgendwelche Server online sind, auf denen Gluster läuft, und dann per SSH auf den ersten Server zugreift, den er findet, und die notwendigen Befehle ausführt. Das Problem ist, dass ich scheinbar keine Möglichkeit finde, das Netzwerk erfolgreich zu prüfen.
Damit automatische Abschaltungen kein Problem darstellen, habe ich überlegt, auf jedem Cluster-Peer einen Cron-Job auszuführen, zu prüfen, ob es getrennte Peers gibt, und diese getrennten Peers zu entfernen, falls welche gefunden werden. Das scheint ziemlich kompliziert. Gibt es eine bessere/sauberere Möglichkeit, dies zu tun?
Ich bin ziemlich neu bei GlusterFS. Alle Tipps und Hinweise sind willkommen.
Antwort1
Nach einiger Suche habe ich „AWS CLI“ entdeckt, um eine Reihe von Instanzen mit einem bestimmten Tag oder in einer bestimmten Skalierungsgruppe zu finden. Von dort aus ist es möglich, eine auszuwählen, sich per SSH anzumelden und alle erforderlichen Befehle auszuführen.
Antwort2
Beim Versuch, GlusterFS mit AWS zum Laufen zu bringen, stieß ich auf dieselben Probleme. Das Trennen von Servern ist kein so großes Problem wie das automatische Verbinden neuer Server mit dem Cluster.
GlusterFS erfordert, dass wir immer die IP/den Hostnamen der „anderen Server“ zum Peering kennen, und es stellt eine Einschränkung dar, wenn wir eine automatische Skalierung durchführen möchten.