[ English | Indonesia | Deutsch | 日本語 ]

Erweiterte Konfiguration - Ausschlüsse

OpenStack soll in einer Vielzahl von Installationsvarianten gut funktionieren, von sehr kleinen privaten Clouds bis hin zu großen öffentlichen Clouds. Um dies zu erreichen, fügen die Entwickler ihrem Code Konfigurationsoptionen hinzu, mit denen das Verhalten der verschiedenen Komponenten je nach Bedarf angepasst werden kann. Leider ist es nicht möglich, alle möglichen Implementierungen mit den Standardkonfigurationswerten abzudecken.

Zum Zeitpunkt der Erstellung verfügt OpenStack über mehr als 3.000 Konfigurationsoptionen. Sie können sie in der OpenStack Configuration Reference dokumentiert sehen. Dieses Kapitel kann nicht hoffen, all dies zu dokumentieren, aber wir versuchen, die wichtigen Konzepte vorzustellen, damit Sie wissen, wo Sie nach weiteren Informationen suchen müssen.

Unterschiede zwischen verschiedenen Treibern

Viele OpenStack-Projekte implementieren eine Treiberschicht, und jeder dieser Treiber implementiert seine eigenen Konfigurationsoptionen. In OpenStack Compute (nova) gibt es beispielsweise verschiedene Hypervisor-Treiber, die implementiert sind - beispielsweise libvirt, xenserver, hyper-v und vmware. Nicht alle diese Hypervisor-Treiber haben die gleichen Funktionen, und jeder hat unterschiedliche Tuning-Anforderungen.

Bemerkung

Die aktuell implementierten Hypervisoren sind in der OpenStack Configuration Reference aufgelistet. Eine Matrix der verschiedenen Features in den OpenStack Compute (nova) Hypervisor-Treibern finden Sie auf der Hypervisor Supportmatrix-Seite.

Der Punkt, den wir hier ansprechen wollen, ist, dass nur weil es eine Option gibt, nicht bedeutet, dass diese Option für Ihre Treiberauswahl relevant ist. Normalerweise ist in der Dokumentation vermerkt, für welche Treiber die Konfiguration gilt.

Implementierung periodischer Aufgaben

Ein weiteres gemeinsames Konzept in verschiedenen OpenStack-Projekten ist das der periodischen Aufgaben. Periodische Aufgaben sind ähnlich wie Cron-Jobs auf traditionellen Unix-Systemen, aber sie werden innerhalb eines OpenStack-Prozesses ausgeführt. Wenn OpenStack Compute (nova) beispielsweise herausfinden muss, welche Abbilder es aus seinem lokalen Cache entfernen kann, führt es dazu eine regelmäßige Aufgabe aus.

Periodische Aufgaben sind wegen der Einschränkungen im Threading-Modell, das OpenStack verwendet, wichtig zu verstehen. OpenStack verwendet kooperatives Threading in Python, was bedeutet, dass, wenn etwas langes und kompliziertes läuft, es andere Aufgaben innerhalb dieses Prozesses blockiert, es sei denn, es führt freiwillig eine Ausführung für einen anderen kooperativen Thread durch.

Ein konkretes Beispiel dafür ist der Prozess des nova-compute. Um den Image-Cache mit libvirt zu verwalten, hat nova-compute einen periodischen Prozess, der den Inhalt des Image-Cache scannt. Ein Teil dieses Scans ist das Berechnen einer Prüfsumme für jedes der Abbilder und das Sicherstellen, dass die Prüfsumme mit dem übereinstimmt, was nova-compute erwartet. Allerdings können Abbilder sehr groß sein, und diese Prüfsummen können lange Zeit in Anspruch nehmen. An einem Punkt, bevor er als Fehler gemeldet und behoben wurde, würde nova-compute diese Aufgabe blockieren und nicht mehr auf RPC-Anfragen reagieren. Dies war für die Benutzer als Ausfall von Operationen wie Spawning oder Löschen von Instanzen sichtbar.

Wenn Sie einen OpenStack-Prozess beobachten, der für eine Weile „zu stoppen“ scheint und dann normal weiterarbeitet, sollten Sie überprüfen, ob periodische Aufgaben nicht das Problem sind. Eine Möglichkeit, dies zu tun, besteht darin, die periodischen Aufgaben zu deaktivieren, indem Sie ihr Intervall auf Null setzen. Zusätzlich können Sie konfigurieren, wie oft diese periodischen Aufgaben in einigen Fällen ausgeführt werden, es kann sinnvoll sein, sie mit einer anderen Frequenz als der Standardfrequenz auszuführen.

Die Häufigkeit wird für jede periodische Aufgabe separat definiert. Um daher jede periodische Aufgabe in OpenStack Compute (nova) zu deaktivieren, müssen Sie eine Reihe von Konfigurationsoptionen auf Null setzen. Die aktuelle Liste der Konfigurationsoptionen, die Sie auf Null setzen müssten, sind:

• bandwidth_poll_interval

• sync_power_state_interval

• heal_instance_info_cache_interval

• host_state_interval

• image_cache_manager_interval

• reclaim_instance_interval

• volume_usage_poll_interval

• shelved_poll_interval

• shelved_offload_time

• instance_delete_interval

Um eine Konfigurationsoption auf Null zu setzen, fügen Sie eine Zeile wie image_cache_manager_interval=0 in Ihre nova.conf Datei ein.

Diese Liste ändert sich zwischen den Versionen, daher lesen Sie bitte in Ihrem Konfigurationsleitfaden nach, um aktuelle Informationen zu erhalten.

Spezifische Konfigurationsthemen

In diesem Abschnitt werden konkrete Beispiele für Konfigurationsoptionen vorgestellt, die Sie in Betracht ziehen könnten. Es handelt sich bei weitem nicht um eine vollständige Liste.

Sicherheitskonfiguration für Compute, Networking und Storage

Der OpenStack Security Guide bietet einen tiefen Einblick in die Sicherung einer OpenStack-Cloud, einschließlich SSL/TLS, Schlüsselmanagement, PKI- und Zertifikatsmanagement, Datentransport- und Datenschutzbelange sowie Compliance.

Hochverfügbarkeit

Der OpenStack High Availability Guide bietet Vorschläge zur Beseitigung eines einzelnen Fehlers, der zu Systemausfällen führen kann. Es ist zwar kein vollständig normatives Dokument, bietet aber Methoden und Techniken zur Vermeidung von Ausfallzeiten und Datenverlust.

IPv6-Unterstützung aktivieren

Sie können den Fortschritt beim IPV6-Support verfolgen, indem Sie das Neutron IPv6 Subteam bei der Arbeit beobachten.

Durch die Änderung Ihrer Konfigurationseinstellungen können Sie IPv6 einrichten, wenn Sie nova-network für das Netzwerk verwenden, und ein getestetes Setup ist für FlatDHCP und eine Multi-Host-Konfiguration dokumentiert. Der Schlüssel ist, dass nova-network denken lässt, dass ein radvd Befehl erfolgreich ausgeführt wurde. Die gesamte Konfiguration ist in einem Cybera-Blogbeitrag beschrieben, „An IPv6 enabled cloud“.

Geographische Überlegungen zur Objektspeicherung

Die Unterstützung für das globale Clustering von Object Storage Servern ist für alle unterstützten Releases verfügbar. Sie würden diese globalen Cluster implementieren, um im Falle einer Naturkatastrophe die Replikation über geografische Gebiete hinweg sicherzustellen und um sicherzustellen, dass Benutzer ihre Objekte schneller schreiben oder darauf zugreifen können, basierend auf dem nächstgelegenen Rechenzentrum. Sie konfigurieren eine Standardregion mit einer Zone für jeden Cluster, aber stellen Sie sicher, dass Ihr Netzwerk (WAN) die zusätzliche Anfrage- und Antwortlast zwischen den Zonen bewältigen kann, wenn Sie weitere Zonen hinzufügen und einen Ring aufbauen, der mehr Zonen verarbeitet. Weitere Informationen finden Sie in der Dokumentation unter Geographically Distributed Swift Considerations.