[ English | Indonesia | Deutsch | 日本語 ]

Kapazitätsplanung und -skalierung

Cloud-basierte Anwendungen erfordern typischerweise diskretere Hardware (horizontale Skalierung) als herkömmliche Anwendungen, die größere Hardware zur Skalierung benötigen (vertikale Skalierung).

OpenStack ist so konzipiert, dass es horizontal skalierbar ist. Anstatt auf größere Server umzusteigen, beschaffen Sie mehr Server und installieren einfach identisch konfigurierte Dienste. Im Idealfall skalieren und verteilen Sie die Last zwischen Gruppen von funktional identischen Diensten (z.B. Compute-Knoten oder nova-api Knoten), die auf einem Nachrichtenbus kommunizieren.

Bestimmung der Cloud-Skalierbarkeit

Um die Skalierbarkeit Ihrer Cloud zu bestimmen und zu verbessern, müssen viele Variablen ausgeglichen werden. Keine einzige Lösung erfüllt die Skalierungsziele aller Beteiligten. Es ist jedoch hilfreich, eine Reihe von Kennzahlen zu verfolgen. Sie können in OpenStack virtuelle Hardware-Vorlagen, sogenannte „Flavors“, definieren, die sich auf Ihre Cloud-Skalierungsentscheidungen auswirken. Diese Vorlagen definieren Größen für den Speicher im RAM, die Größe der Root-Festplatte, die Menge des verfügbaren ephemeren Datenspeicherplatzes und die Anzahl der CPU-Kerne.

Die standardmäßigen OpenStack-Varianten werden in Tabelle. OpenStack-Standardvarianten angezeigt.

Tabelle. OpenStack-Standardvarianten

Name	Virtuelle Kerne	Speicher	Disk	Ephemeral
m1.tiny	1	512 MB	1 GB	0 GB
m1.small	1	2 GB	10 GB	20 GB
m1.medium	2	4 GB	10 GB	40 GB
m1.large	4	8 GB	10 GB	80 GB
m1.xlarge	8	16 GB	10 GB	160 GB

Der Ausgangspunkt ist die Kernzahl Ihrer Cloud. Durch die Anwendung einiger Kennzahlen können Sie Informationen über:

• Die Anzahl der virtuellen Maschinen (VMs), die Sie voraussichtlich ausführen werden, ((overcommit fraction × cores) / virtual cores per instance)``

• Wie viel Speicherplatz wird benötigt (Flavor Disk Size × Number of Instances)

Anhand dieser Kennzahlen können Sie bestimmen, wie viel zusätzliche Infrastruktur Sie für die Unterstützung Ihrer Cloud benötigen.

Hier ist ein Beispiel anhand der Verhältnisse zur Erfassung von Skalierungsinformationen für die Anzahl der erwarteten VMs sowie den benötigten Speicherplatz. Die folgenden Zahlen unterstützen (200 / 2) × 16 = 1600 VM-Instanzen und benötigen 80 TB Speicherplatz für /var/lib/nova/instances:

• 200 physikalische Kerne.

• Die meisten Fälle haben die Größe m1.medium (zwei virtuelle Kerne, 50 GB Speicher).

• Standard CPU Overcommit Ratio (cpu_allocation_ratio in der nova.conf` Datei) von 16:1.

Bemerkung

Unabhängig vom Overcommit-Verhältnis kann eine Instanz nicht auf einem physischen Knoten mit weniger Raw-Ressourcen (Pre-Overcommit) platziert werden, als der Instanz-Variante entspricht.

Sie benötigen jedoch mehr als nur die Kernzahl, um die Belastung abzuschätzen, der die API-Dienste, Datenbankserver und Queue-Server wahrscheinlich ausgesetzt sind. Sie müssen auch das Nutzungsverhalten Ihrer Cloud berücksichtigen.

Als konkretes Beispiel vergleichen Sie eine Cloud, die eine verwaltete Web-Hosting-Plattform unterstützt, mit einem laufenden Integrationstest für ein Entwicklungsprojekt, das eine VM pro Code Commit erstellt. Im ersten Fall erfolgt die schwere Arbeit bei der Erstellung einer VM nur alle paar Monate, während im zweiten Fall der Cloud-Controller ständig stark belastet wird. Sie müssen Ihre durchschnittliche VM-Lebensdauer berücksichtigen, da eine größere Anzahl in der Regel eine geringere Belastung des Cloud-Controllers bedeutet.

Abgesehen von der Erstellung und Beendigung von VMs müssen Sie die Auswirkungen von Benutzern, die auf den Dienst zugreifen, insbesondere auf nova-api und die zugehörige Datenbank berücksichtigen. Listing-Instanzen liefern eine Vielzahl von Informationen, und angesichts der Häufigkeit, mit der Benutzer diesen Vorgang ausführen, kann eine Cloud mit einer großen Anzahl von Benutzern die Last deutlich erhöhen. Dies kann auch ohne ihr Wissen geschehen. Wenn Sie beispielsweise die Registerkarte OpenStack Dashboard-Instanzen im Browser geöffnet lassen, wird die Liste der VMs alle 30 Sekunden aktualisiert.

Nachdem Sie diese Faktoren berücksichtigt haben, können Sie bestimmen, wie viele Cloud-Controller-Kerne Sie benötigen. Ein typischer 8-Kern-RAM-Server mit 8 GB reicht für bis zu einem Rack von Compute-Knoten - angesichts der oben genannten Einschränkungen.

Sie müssen auch die wichtigsten Hardwarespezifikationen für die Leistung von Benutzer-VMs sowie Budget- und Leistungsanforderungen berücksichtigen, einschließlich Speicherleistung (Spindeln/Kern), Speicherverfügbarkeit (RAM/Kern), Netzwerkbandbreiten-Hardware-Spezifikationen und (Gbps/Kern) und Gesamt CPU-Leistung (CPU/Kern).

Tipp

Eine Erläuterung des metrischen Tracking, einschließlich der Frage, wie Sie Metriken aus Ihrer Cloud extrahieren können, finden Sie im OpenStack Operations Guide.

Hinzufügen von Cloud-Controller-Knoten

Sie können die horizontale Expansion Ihrer Cloud durch Hinzufügen von Knoten erleichtern. Das Hinzufügen von Compute-Knoten ist einfach, da sie von der bestehenden Installation leicht übernommen werden können. Allerdings müssen Sie einige wichtige Punkte berücksichtigen, wenn Sie Ihren Cluster so gestalten, dass er hochverfügbar ist.

Ein Cloud-Controller-Knoten führt mehrere verschiedene Dienste aus. Sie können Dienste installieren, die nur über die Nachrichtenwarteschlange intern kommunizieren - nova-scheduler und nova-console auf einem neuen Server zur Erweiterung. Andere integrale Teile erfordern jedoch mehr Sorgfalt.

Sie sollten benutzerorientierte Dienste wie Dashboard, nova-api oder den Object Storage-Proxy laden. Verwenden Sie eine beliebige Standardmethode des HTTP-Lastausgleichs (DNS Round Robin, Hardware Load Balancer oder Software wie Pound oder HAProxy). Ein Vorbehalt mit Dashboard ist der VNC-Proxy, der das WebSocket-Protokoll verwendet - etwas, womit ein L7-Lastausgleich kämpfen könnte. Siehe auch Horizon Session Storage.

Sie können einige Dienste, wie z.B. nova-api und glance-api, so konfigurieren, dass sie mehrere Prozesse verwenden, indem Sie ein Flag in ihrer Konfigurationsdatei ändern, das es ihnen ermöglicht, die Arbeit zwischen mehreren Kernen auf einer Maschine zu teilen.

Tipp

Für den MySQL-Lastausgleich stehen mehrere Optionen zur Verfügung, und die unterstützten AMQP-Broker verfügen über eine integrierte Clustering-Unterstützung. Informationen zur Konfiguration dieser und vieler anderer Dienste finden Sie im Operations Guide.

Trennung Ihrer Cloud

Die Trennung Ihrer Cloud ist erforderlich, wenn Benutzer verschiedene Regionen aus rechtlichen Gründen für die Datenspeicherung, die Redundanz über Erdbeben-Fehlerleitungen oder für API-Aufrufe mit niedriger Latenz benötigen. Es kann durch Zellen, Regionen, Verfügbarkeitszonen oder Host-Aggregate getrennt werden.

Jede Methode bietet unterschiedliche Funktionen und lässt sich am besten in zwei Gruppen einteilen:

• Zellen und Regionen, die eine ganze Cloud trennen und dazu führen, dass separate Compute-Implementierungen ausgeführt werden.

• Availability zones und Host-Aggregate, die lediglich eine einzelne Compute Deployment teilen.

Tabelle. OpenStack-Separationsverfahren bietet eine Vergleichsansicht jeder Trennmethode, die derzeit von OpenStack Compute bereitgestellt wird.

Tabelle. OpenStack-Separationsverfahren

	Zellen	Regionen	Verfügbarkeitszone	Host-Aggregate
Verwendung	Shard and scale compute deployment while maintaining a single API endpoint.	Diskrete Regionen mit separaten API-Endpunkten und keiner Koordination zwischen den Regionen.	Logische Trennung innerhalb Ihrer nova-Bereitstellung für physische Isolierung oder Redundanz.	So planen Sie eine Gruppe von Hosts mit gemeinsamen Funktionen.
Beispiel	Eine Cloud mit mehreren Standorten, in der Sie VMs „überall“ oder auf einer bestimmten Website planen können.	Eine Cloud mit mehreren Standorten, in der Sie VMs für einen bestimmten Standort planen und eine gemeinsame Infrastruktur benötigen.	Eine Single-Site-Cloud mit Geräten, die von separaten Stromversorgungen gespeist werden.	Planung auf Hosts mit vertrauenswürdiger Hardwareunterstützung.
Overhead	Each Cell contains instances of services with overlapping functionality.	Ein unterschiedlicher API-Endpunkt für jede Region. Jede Region verfügt über eine vollständige nova-Installation.	Die Konfiguration ändert sich zu nova.conf.	Die Konfiguration ändert sich zu nova.conf.
Gemeinsame Dienste**	Keystone, nova-api	Keystone	Keystone, Alle nova-Dienstleistungen	Keystone, Alle nova-Dienstleistungen

Zellen und Regionen

OpenStack Compute-Zellen sind so konzipiert, dass sie den verteilten Betrieb der Cloud ermöglichen, ohne kompliziertere Technologien einsetzen zu müssen oder in bestehende nova-Installationen einzugreifen. Hosts in einer Cloud werden in Gruppen unterteilt, die Zellen genannt werden. Die Zellen werden in einem Baum konfiguriert. Die oberste Zelle („API-Zelle“) hat einen Host, der den Dienst nova-api ausführt, aber keine nova-compute Dienste. Der nova-compute Service läuft in den Kinder Zellen. Jede Zelle hat ihre eigene Message Queue und Datenbank Service.

This allows for a single API server being used to control access to multiple compute installations with the usage of multiple Cells. See Nova Cells V2 Layout for further documentation.

Im Gegensatz zu einem einzelnen API-Endpunkt haben Regionen einen separaten API-Endpunkt pro Installation, was eine diskretere Trennung ermöglicht. Benutzer, die Instanzen über Standorte hinweg ausführen möchten, müssen explizit eine Region auswählen. Die zusätzliche Komplexität der Ausführung eines neuen Dienstes ist jedoch nicht erforderlich.

Das OpenStack-Dashboard (Horizon) kann so konfiguriert werden, dass es mehrere Regionen verwendet. Dies kann über den Parameter AVAILABLE_REGIONS konfiguriert werden.

Verfügbarkeitszonen und Hostaggregate

Sie können Verfügbarkeitszonen, Host-Aggregate oder beides verwenden, um eine nova-Bereitstellung zu partitionieren. Beide Methoden werden in ähnlicher Weise konfiguriert und implementiert.

Verfügbarkeitszone

Dies ermöglicht es Ihnen, OpenStack-Compute-Hosts in logische Gruppen einzuteilen und bietet eine Form der physischen Isolierung und Redundanz von anderen Verfügbarkeitszonen, z.B. durch die Verwendung einer separaten Stromversorgung oder Netzwerkgeräte.

Sie definieren die Verfügbarkeitszone, in der sich ein bestimmter Rechenhost lokal auf jedem Server befindet. Eine Verfügbarkeitszone wird häufig verwendet, um eine Reihe von Servern zu identifizieren, die ein gemeinsames Attribut haben. Wenn sich beispielsweise einige der Racks in Ihrem Rechenzentrum auf einer separaten Stromquelle befinden, können Sie Server in diesen Racks in einer eigenen Verfügbarkeitszone platzieren. Verfügbarkeitszonen können auch helfen, verschiedene Hardwareklassen zu trennen.

Wenn Benutzer Ressourcen bereitstellen, können sie angeben, aus welcher Verfügbarkeitszone ihre Instanz erstellt werden soll. Auf diese Weise können Cloud-Kunden sicherstellen, dass ihre Anwendungsressourcen auf unterschiedliche Computer verteilt sind, um im Falle eines Hardwareausfalls eine hohe Verfügbarkeit zu erreichen.

Host-Aggregate Zone

Auf diese Weise können Sie OpenStack Compute-Bereitstellungen in logische Gruppen für Lastausgleich und Instanzverteilung unterteilen. Sie können Host-Aggregate verwenden, um eine Verfügbarkeitszone weiter zu partitionieren. So können Sie beispielsweise Host-Aggregate verwenden, um eine Verfügbarkeitszone in Gruppen von Hosts zu partitionieren, die entweder gemeinsame Ressourcen wie Speicher und Netzwerk gemeinsam nutzen oder eine spezielle Eigenschaft haben, wie beispielsweise vertrauenswürdige Computerhardware.

Eine gängige Verwendung von Host-Aggregaten ist die Bereitstellung von Informationen für die Verwendung mit dem nova-scheduler. Sie können beispielsweise ein Host-Aggregat verwenden, um eine Reihe von Hosts zu gruppieren, die bestimmte Varianten oder Bilder gemeinsam nutzen.

Der allgemeine Fall dafür ist das Setzen von Schlüssel-Wert-Paaren in den aggregierten Metadaten und das Abgleichen von Schlüssel-Wert-Paaren in den Metadaten von Flavor’s extra_specs. Der AggregateInstanceExtraSpecsFilter im Filterplaner erzwingt, dass Instanzen nur auf Hosts in Aggregaten geplant werden, die den gleichen Schlüssel zum gleichen Wert definieren.

Eine fortgeschrittene Nutzung dieses allgemeinen Konzepts ermöglicht es, dass verschiedene Flavor-Typen mit unterschiedlichen CPU- und RAM-Zuordnungsverhältnissen betrieben werden können, so dass hochintensive Rechenlasten und niedrigintensive Entwicklungs- und Testsysteme die gleiche Cloud gemeinsam nutzen können, ohne die hochgradig genutzten Systeme zu verhungern oder Ressourcen für Systeme mit geringer Auslastung zu verschwenden. Dies funktioniert, indem Sie Metadaten in Ihren Host-Aggregaten setzen und extra_specs in Ihren Flavor-Typen anpassen.

Der erste Schritt besteht darin, die aggregierten Metadatenschlüssel cpu_allocation_ratio und ram_allocation_ratio` auf einen Fließkommawert zu setzen. Die Filterplaner AggregateCoreFilter und AggregateRamFilter verwenden diese Werte anstelle der globalen Standardwerte in nova.conf` bei der Planung auf Hosts im Aggregat. Seien Sie vorsichtig bei der Verwendung dieser Funktion, da jeder Host in mehreren Aggregaten sein kann, aber nur ein Zuordnungsverhältnis für jede Ressource haben sollte. Es liegt an Ihnen, zu vermeiden, einen Host in mehrere Aggregate zu stecken, die unterschiedliche Werte für dieselbe Ressource definieren.

Dies ist die erste Hälfte der Gleichung. Um Flavor-Typen zu erhalten, die ein bestimmtes Verhältnis garantieren, müssen Sie die extra_specs im Flavor-Typ auf das Schlüssel-Wert-Paar setzen, das Sie im Aggregat abgleichen möchten. Wenn Sie beispielsweise extra_specs cpu_allocation_ratio zu „1.0“ definieren, dann laufen Instanzen dieses Typs nur in Aggregaten, in denen der Metadatenschlüssel cpu_allocation_ratio` auch als „1.0“ definiert ist. In der Praxis ist es besser, ein zusätzliches Schlüssel-Wert-Paar in den aggregierten Metadaten zu definieren, das auf on passt, als direkt auf cpu_allocation_ratio oder core_allocation_ratio`. Dies ermöglicht eine bessere Abstraktion. Wenn Sie beispielsweise einen Schlüssel „overcommit“ definieren und einen Wert von „high“, „medium“ oder „low“ einstellen, können Sie dann die numerischen Allokationsverhältnisse in den Aggregaten anpassen, ohne auch alle damit verbundenen Flavor-Typen ändern zu müssen.

Bemerkung

Bisher hatten alle Dienste eine Verfügbarkeitszone. Derzeit hat nur der Dienst nova-compute eine eigene Verfügbarkeitszone. Dienste wie nova-scheduler, nova-network und nova-conductor erstrecken sich seit jeher über alle Verfügbarkeitszonen.

Wenn Sie eine der folgenden Operationen ausführen, erscheinen die Dienste in einer eigenen internen Verfügbarkeitszone (CONF.internal_service_availability_zone):

• openstack host list (os-hosts)

• euca-describe-availability-zones verbose

• openstack compute service list öffnen

Die interne Verfügbarkeitszone ist in euca-describe-availability_zones (nonverbose) versteckt.

Die CONF.node_availability_zone wurde in CONF.default_availability_zone umbenannt und wird nur von den Diensten nova-api und nova-scheduler verwendet.

CONF.node_availability_zone funktioniert noch, ist aber veraltet.

Skalierbare Hardware

Obwohl es bereits mehrere Ressourcen gibt, die bei der Bereitstellung und Installation von OpenStack helfen, ist es sehr wichtig, sicherzustellen, dass Sie Ihre Bereitstellung frühzeitig planen lassen. Dieser Leitfaden geht davon aus, dass Sie ein Rack für die OpenStack-Cloud reserviert haben, bietet aber auch Vorschläge, wann und was Sie skalieren sollten.

Hardware-Beschaffung

„Die Cloud“ wurde als eine volatile Umgebung beschrieben, in der Server nach Belieben erstellt und beendet werden können. Dies mag zwar wahr sein, bedeutet aber nicht, dass Ihre Server volatil sein müssen. Die Sicherstellung, dass die Hardware Ihrer Cloud stabil und korrekt konfiguriert ist, bedeutet, dass Ihre Cloud-Umgebung funktionsfähig bleibt.

OpenStack kann auf jeder Hardware bereitgestellt werden, die von einer OpenStack-kompatiblen Linux-Distribution unterstützt wird.

Die Hardware muss nicht konsistent sein, aber sie sollte zumindest den gleichen CPU-Typ haben, um die Instanzmigration zu unterstützen.

Die typische Hardware, die für die Verwendung mit OpenStack empfohlen wird, ist das Standardangebot, das die meisten Hardwareanbieter führen. Es sollte einfach sein, Ihre Beschaffung in Bausteine wie „Compute“, „Object Storage“ und „Cloud Controller“ aufzuteilen und beliebig viele davon abzurufen. Alternativ können alle vorhandenen Server, die den Leistungsanforderungen und der Virtualisierungstechnologie entsprechen, OpenStack unterstützen.

Kapazitätsplanung

OpenStack wurde entwickelt, um die Größe auf einfache Weise zu vergrößern. Unter Berücksichtigung der oben genannten Überlegungen, insbesondere zur Dimensionierung des Cloud Controllers, sollte es möglich sein, bei Bedarf zusätzliche Rechen- oder Objektspeicherknoten zu beschaffen. Neue Knoten müssen nicht die gleiche Spezifikation oder den gleichen Lieferanten haben wie bestehende Knoten.

Für Compute-Knoten verwaltet nova-scheduler Unterschiede in der Größe mit der Kernanzahl und dem RAM. Sie sollten jedoch berücksichtigen, dass sich die Benutzererfahrung mit unterschiedlichen CPU-Geschwindigkeiten ändert. Beim Hinzufügen von Objektspeicherknoten sollte ein Gewicht angegeben werden, der den Fähigkeit des Knotens widerspiegelt.

Die Überwachung des Ressourcenverbrauchs und des Benutzerwachstums ermöglicht es Ihnen zu wissen, wann Sie beschaffen müssen. Das Kapitel Logging und Monitoring im Operations Guide beschreibt einige nützliche Kennzahlen.

Burn-In-Tests

Die Wahrscheinlichkeit eines Ausfalls der Hardware des Servers ist am Anfang und am Ende ihrer Lebensdauer hoch. Dadurch kann die Behandlung von Hardwareausfällen während der Produktion durch geeignete Burn-In-Tests vermieden werden, um zu versuchen, die Fehler im Frühstadium auszulösen. Das allgemeine Prinzip besteht darin, die Hardware an ihre Grenzen zu bringen. Beispiele für Burn-In-Tests sind das Ausführen eines CPU- oder Festplatten-Benchmarks über mehrere Tage.