Architektur einer virtuellen OpenStack-Bereitstellung (Juju/MAAS) mit 1 physischen Knoten

Question

Ich möchte einige der HA/FT-Funktionen von OpenStacks demonstrieren (vor allem Live-Migration und Speicherreplikation). Zu diesem Zweck habe ich eine Maschine mit 32 GB RAM und einen Xeon e3v2 mit 4 Kernen (8 Threads). Bisher habe ich es geschafft, MAAS und Juju zum Laufen zu bringen, aber ich bin mir nicht sicher, wie viele virtuelle Knoten ich sicher bereitstellen kann (und wie hoch das CPU/RAM-Overcommit-Verhältnis ist, obwohl ich irgendwo gelesen habe, dass die physische CPU Overcommiting mit 1-VCPU-Maschinen ziemlich gut bewältigen kann).

Derzeit verwendet die VM, auf der MAAS ausgeführt wird, 1 vCPU und 8 GB RAM. Juju läuft auf dem Host. Damit bleiben mir 7 vCPUs und 24 GB RAM, ohne dass ich Ressourcen überlaste. Ich bin auf Folgendes gekommen:

• 1 Controllerknoten: 2 vCPUs, 4 GB RAM – RabbitMQ, MySQL, Keystone, Dashboard, Cinder, Nova-Cloud-Controller und Glance in LXC-Containern
• 2 Ceph-Knoten: jeweils 1 vCPU, 4 GB RAM – Ceph
• 2 Rechenknoten: 2 vCPUs, jeweils 8 GB RAM - nova-compute
• 1 Netzwerkknoten: 1 vCPU, 2 GB RAM - Quanten-Gateway
• Plus der MAAS-Host: 1 vCPU, 8 GB RAM

Dies ergäbe eine Gesamtsumme von 38 GB RAM und 10 vCPUs, ich übernehme also etwas das Budget.

Meine eigentliche Frage ist, ob jemand eine bessere Architektur im Sinn hat. Ich habe eigentlich nur vor, einige Funktionen von OpenStack (oder Clouds im Allgemeinen) zu zeigen.

Answer 1

Ich habe ein ähnliches Setup und möchte für Ihre Konfiguration Folgendes vorschlagen:

• Reduzieren Sie die MAAS zugewiesene RAM-Menge. Etwa 2 GB sind ausreichend.
• Fügen Sie einen weiteren Ceph-Knoten hinzu. Dadurch können Sie die Ausfallsicherheit demonstrieren, wenn Sie Ceph verwenden und ein Knoten ausfällt.
• Eine Überlastung der CPU ist nicht so schlimm, aber Sie sollten keine Überlastung des Arbeitsspeichers verursachen, da das System mit dem Swapping beginnt und die Leistung dadurch unbrauchbar wird.
• Was Sie nicht erwähnen, sind die Festplatten, die Sie haben. Das ist für mich ein riesiger Engpass. Ich habe zwei Festplatten mit 7200 U/min und BTRFS (RAID0), aber das reicht nicht aus, während Juju bereitgestellt wird.
• Möglicherweise möchten Sie auch juju-deployer verwenden und die zum Bereitstellen verwendete Befehlszeile optimieren, insbesondere Timeout-Modifikatoren und „-s“, das eine Verzögerung zwischen jedem „juju deploy“-Aufruf darstellt.

Ich hoffe das hilft.

Herr Felipe,

Answer 2

Ich schlage vor, dass Sie es löschen, wenn es noch läuft, und LXD verwenden. Sie sollten keine Probleme habenBereitstellung dieserohne MaaS und nur mit Juju und lokaler Steuerung Ihres lokalen LXDwie hier beschrieben. Ihr Computer sollte in der Lage sein, es ohne große Probleme auszuführen. Wenn Sie MaaS zur Demonstration benötigen (es ist wirklich ziemlich beeindruckend. Sie sollten versuchen, sich die OpenStack Roadshows von Canonical anzusehen, wenn eine in der Nähe ist ...), wird es etwas komplizierter.

Diese Referenz zeigtEinrichten auf 3 Maschinen, aber Sie können es auch hinterhältig angehen und Juju und MaaS auf derselben anderen Maschine bereitstellen, wenn es wirklich sein muss. Wenn auf Ihrer zweiten Maschine MaaS und JuJu unter LXD laufen, die Brücke mit Ihrem Labor-LAN verbunden ist und Ihr PXE-Verkehr durchkommt, sollten Sie alles in Containern auf zwei Maschinen ausführen können. Ich versuche, etwas Ähnliches mit VMWare Fusion VMs auf meinem Laptop zu machen, wo ich das interne Netzwerk mit einer Thunderbolt-NIC verbunden habe, damit die MaaS- und Juju-Maschinen Raspberry Pi- und NUC-Geräte orchestrieren können.

Answer 3

Ich habe keine Erfahrung mit der Verwendung von Juju für die OpenStack-Orchestrierung, aber aus Erfahrung mit Ceph und OpenStack weiß ich, dass Sie Ceph zu Demozwecken problemlos auf 2-GB-Maschinen ausführen können und dass der Maas-Host auch mit 6 GB statt 8 konfiguriert werden kann.

Ich weiß nicht, ob Juju das Kombinieren verschiedener Rollen in derselben VM zulässt. In unseren (Nicht-Juju-)Bereitstellungen kombinieren wir den Controller und die Netzwerkrollen auf derselben VM (ohne Container zu verwenden).

Answer 4

Wenn Sie physische Knoten in einem kleinen Cluster verwenden, insbesondere bei Testlabors, besteht eine typische Abkürzung darin, die Ceph-Knoten mit Ihren Rechenknoten zu kombinieren. Sehen Sie sich diesen Satz aus der Ceph-0.48-Ära an.Anweisungen für Debianoder dieses modernereLaborkonfiguration für Proxmox VE.

Anhand der von Ihnen angegebenen Zahlen und der Vorschläge zur RAM-Verringerung plus Triple-Ceph in den anderen Antworten könnte es etwa so aussehen:

1. 3 vCpu + 8 GB == RabbitMQ/Keystone/Glance/usw. + CephMon1/Osd1
2. 2 vCpu + 10 GB == novaComp2/Net2/Vol2 + cephMon2/Osd2/Httpd2/Rgw2
3. 2 vCpu + 10 GB == novaComp3/Net3 + cephMon3/Osd3
4. 1 vCpu + 2 GB == novaQuantum4
5. 1 vCpu + 3 GB == MAAS_host5

Ich arbeite derzeit selbst an einer Ein-Knoten-Konfiguration dieser Art, habe aber weniger RAM zur Verfügung und nur vier Festplatten (cephOsd ist mit mehreren Festplatten besser). Ich kann nicht bestätigen, dass die oben genannten Zahlen für Sie mit ausreichender Leistung funktionieren, da ich dieses Schema nicht selbst ausprobiert habe, aber die Grundidee, einigermaßen orthogonale Knoten zusammenzuführen, um mit vCpu&ram sparsam umzugehen, bietet Ihnen möglicherweise genügend Antrieb, um Ihr Ziel zu erreichen.

ps Siehe auch semioffizielle Hilfedokumente für OpenStack in einem physischen Knoten miteinsVM sowie das relevantere OpenStack-Tutorial auf einer dedizierten Box unter devstack.org