Die Idee: Eine eigene Cloudumgebung aufbauen. Warum? Um die Verwaltung unserer Ressourcen zu vereinfachen. Wie?OpenNebula scheint mir für unsere Umgebung ganz gut geeignet zu sein. OpenStack ist denke ich zu komplex.
Die Verwaltung der Ressourcen kann über das Frontend (Sunstone) oder über die Konsole erfolgen. Es steht eine volle Benutzer-, Gruppen- und Berechtigungsverwaltung zur Verfügung, sodass man den Zugriff auf Ressourcen genau regeln kann.
Die Images der VMs liegen in einem Datastore. Je nach Einsatzzweck der VM bieten sich verschiedene Typen des Datastores an, die sich auch mischen lassen. So lässt sich beim filesystembasierten Typ shared (VM Image liegt in einem shared filesystem, auf das per NFS / CIFS zugegriffen wird) mit ssh (VM Image wird beim Start der VM auf den Host kopiert) mischen.
Für einen tieferen Einblick empfiehlt sich die Dokumentation.
Es ergeben sich mit einer solchen Cloudumgebung interessante neue Möglichkeiten, wie z. B. weitere Automatisierung durch Infrastructure as Code (OpenNebula stellt ein API bereit, für das es Ansible- und Terraformmodule gibt) und den Einsatz von Templates. Der Marketplace ist ebenfalls interessant. Mit dem Image für Kubernetes und einem passenden OneFlow Template lässt sich beispielsweise ein ganzer Kubernetes-Cluster innerhalb kurzer Zeit deployen.
Unsere bisherigen Vorgehensweisen müssten nicht von einem Tag auf den anderen komplett über den Haufen geworfen werden, man könnte die bisherigen VMs theoretisch auch 1 zu 1 in OpenNebula übertragen.
Was die Komplexität betrifft, so ist mein bisheriger kurzer Eindruck positiv. Zum Testen habe ich OpenNebula lokal in eine VirtualBox VM (nested Virtualization musste ich über die Konsole aktivieren) installiert und war nach ca. 20 min startklar. Das ist natürlich nicht vergleichbar mit der Installation einer Produktivumgebung, ich werte es aber als positives Zeichen.
FTR: in GT setzen wir ONe seit Jahren als Verwaltungstool ein, standortübergreifend.
Beim FFRN haben wir damit zum Jahresanfang begonnen, um die derzeit 4 Hetzner-Hosts und ihre VMs einfacher verwalten zu können (vorher: virt-manager).
Es ist halt 'ne Cloud-Umgebung, und funktioniert am besten, wenn man Viehzeug damit einhegen will anstatt Haustieren — oder wie der sprichwörtliche Vergleich geht. (Bei $AG setzen wir es auch ein, da treten dann Reibungspunkte auf, wenn VM Xneu VM Xalt ersetzen soll, mit VM-spezifischer Config (1 bis n Interfaces, v6 mal ja, mal nein, mal anders).)
Das Datastore-Konzept ist einerseits cool, andererseits bei der Planung tricky, gerade wenn man keinen shared storage am Start hat. Alles lösbar, braucht nur etwas Planung vorab Zumal ONe ggf. optimiert und Links vom System- in den Imagestore verwendet. Dazu finden sich aber notfalls auch Infos im Forum.
Schön aus meiner Sicht: Aufsatz auf libvirt mit Skriptwerk, sodaß man selbst Hand anlegen kann, wenn nötig, und zudem rennen die VMs weiter, auch ohne die Management-VM (welche man außerhalb des ONe-Systems anlegen sollte, Henne-Ei :-)).
Die aktuelle Version kann auch parallel zu klassischen VMs diese als Container starten, das probieren wir gerade aus — weniger Overhead z. B. für reine Webserver u. dgl.
Wir sind hier damit soweit zufrieden, und die Kollegen im Süden freute vor allem das einfachere Setup neuer VMs und die zentrale Verwaltbarkeit. Bei FFGT haben wir mittlerweile ein paar anderen Communities Accounts eingerichtet, sodaß diese selbst im Rahmen von CPU-/Speicher-/Host-Limits VMs verwalten können => Works for us
ich finde die Idee auch spannend, frage mich aber noch, was die Vorteile sind - abseits dessen, dass man VMs grafisch klickt statt sie per Ansible anzulegen.
Das Hauptproblem bei uns sind gerade die virtualisierten Gateways. Wir wollen eher dahin, dass die Gateways nativ laufen und nur die Dienste virtualisiert sind. Diese recht ungewöhnliche Kombination lässt sich aber vermutlich besser mit Libvirt bauen.
Ich bin aber auch offen dafür mal einen Host komplett auf das System umzustellen.
Die VMs kann man grafisch zusammenklicken, aber auch automatisch erstellen (es gibt z. B. ein Ansible-Modul für OpenNebula). Das Zusammenklicken ist insbesondere für kurze Tests praktisch, man hat innerhalb von wenigen Minuten eine VM samt Zugang und kann loslegen. Auch die Möglichkeit, anderen Ressourcen bereitstellen zu können, wie wusel es bereits erwähnt hat, ist praktisch. Das ist manuell zeitaufwändig, OpenNebula vereinfacht das stark. Weiterhin ergeben sich einige neue Möglichkeiten, die wir derzeit nicht haben (wie im Ausgangspost kurz angerissen).
Auf was für Limitierungen stoßen wir bei den virtuellen Gateways denn? Aber selbst wenn man OpenNebula erst mal nur für einige Dienste nutzen würde, wäre das vom administrativen Aufwand her denke ich schon eine spürbare Erleichterung.
Mein Vorschlag wäre für das Frontend eine Hetzner-Cloud-VM zu nehmen. Eine CX21 sollte für den Anfang mit einem Host denke ich reichen.
Dreh und Angepunkt sind bei uns die Pakete pro Sekunde, die verarbeitet werden können. Da haben wir mit unserem Layer-2-Kram einfach untypische Anforderungen.
Unser Gateway in Berlin schafft zum Beispiel trotz 10 Gig nur etwa 2,5 mal so viele Knoten wie ein Gateway mit Gigabit. Schuld ist der Stack der Virtualisierung, durch welchen jedes Paket laufen muss.
Um das zu umgehen, wäre mein Wunsch die Gateways wieder nativ laufen zu lassen.
Wir haben in GUT mehrere Server stehen, die per LFS ein shared volume auf jedem Host bereitstellen. Dort sollen die Images zentral liegen (also ein Ubuntu-X-Image soll nur 1x existieren, nicht in jedem Standort; u. a. wegen des Plattenplatzes), die dann auf die an den anderen Standorten stehenden Hosts per scp transferiert werden sollen. Das klappt derzeit durch 1 Cluster je Standort und einem „ssh Image-DS“, der in allen Clustern verfügbar ist. (Sowie einem „ssh System-DS“ je Standort (bzw., außerhalb GUT, Host), jenes im Standort-Cluster.)
Wir haben momentan kein System frei. Müsste man eines anmieten.
@RobWei und ich sind derzeit dabei den Server in Frankfurt auf ein auf dem Blech laufendes Gateway umzustellen. Wenn das durch ist, kann man gucken, ob ein anderes Blech frei wird und dann Dienste und Gateways trennen, sofern die anderen des @Adminteam s da dabei sind. Meine Idee stieß da bisher so auf geteilte Begeisterung.
Zumal ONe ggf. optimiert und Links vom System- in den Imagestore verwendet. Dazu finden sich aber notfalls auch Infos im Forum.
Mein Vorschlag wäre für das Frontend eine Hetzner-Cloud-VM zu nehmen. Eine CX21 sollte für den Anfang mit einem Host denke ich reichen.