Konfigurieren des Inventars¶

In diesem Kapitel finden Sie Informationen dazu, wie Sie das dynamische Openstack-fähige Inventar Ihren Anforderungen entsprechend konfigurieren können.

Einführung¶

Gängige OpenStack-Dienste und ihre Konfiguration werden von OpenStack-Ansible in der Einstellungsdatei /etc/openstack_deploy/openstack_user_config.yml definiert.

Zusätzliche Dienste sollten mit einer YAML-Datei in /etc/openstack_deploy/conf.d definiert werden, um die Dateigröße zu verwalten.

Das Verzeichnis /etc/openstack_deploy/env.d` `bezieht alle YAML-Dateien in die implementierte Umgebung, sodass ein Deployer zusätzliche Gruppenzuordnungen definieren kann. Dieses Verzeichnis wird verwendet, um das Umgebungsskelett zu erweitern oder die im Verzeichnis ``inventory / env.d definierten Standardwerte zu ändern.

Um zu verstehen, wie das dynamische Inventar funktioniert, siehe Das Inventar verstehen.

Warnung

Bearbeiten oder löschen Sie niemals die Dateien /etc/openstack_deploy/openstack_inventory.json oder /etc/openstack_deploy/openstack_hostnames_ips.yml`. Dies kann zu Dateibeschädigungen und zu Problemen mit der Bestandsliste führen: Hosts und Container können verschwinden und neue werden angezeigt, wodurch Ihre vorhandene Bereitstellung zerstört wird.

Konfigurationsbeschränkungen¶

Gruppenmitgliedschaften¶

Beachten Sie beim Hinzufügen von Gruppen Folgendes:

Eine Gruppe kann Hosts enthalten
Eine Gruppe kann untergeordnete Gruppen enthalten

Gruppen können jedoch keine untergeordneten Gruppen und Hosts enthalten.

Die lxc_hosts-Gruppe¶

Wenn das dynamische Inventarscript einen Containernamen erstellt, wird der Host, auf dem sich der Container befindet, zur Bestandsgruppe lxc_hosts hinzugefügt.

Die Verwendung dieses Namens für eine Gruppe in der Konfiguration führt zu einem Laufzeitfehler.

Bereitstellung direkt auf Hosts¶

Um eine Komponente direkt auf dem Host anstatt innerhalb eines Containers bereitzustellen, setzen Sie die Eigenschaft is_metal auf true für die Containergruppe im Abschnitt container_skel der entsprechenden Datei.

Die Verwendung von container_vars und die Zuordnung von Containergruppen zu Hostgruppen ist für einen Service identisch, der direkt auf dem Host bereitgestellt wird.

You can also use the no_containers option to specify a host that will have all services deployed on metal inside of it.

Bemerkung

Die cinder-volume-Komponente wird standardmäßig direkt auf dem Host bereitgestellt. In diesem Beispiel finden Sie die Datei env.d/cinder.yml.

Example: Running all controllers on metal¶

For example, if you’d like to run all your controllers on metal, you would have the following inside your openstack_user_config.yml.

infra_hosts:
  infra1:
    ip: 172.39.123.11
    no_containers: true
  infra2:
    ip: 172.39.123.12
    no_containers: true
  infra3:
    ip: 172.39.123.13
    no_containers: true

Beispiel: Ausführen von galera auf dedizierten Hosts¶

Um beispielsweise Galera direkt auf dedizierten Hosts auszuführen, führen Sie die folgenden Schritte aus:

Ändern Sie den Abschnitt container_skel der env.d/galera.yml-Datei. Beispielsweise:
```
container_skel:
  galera_container:
    belongs_to:
      - db_containers
    contains:
      - galera
    properties:
      is_metal: true
```
Bemerkung

Zur Bereitstellung in Containern auf diesen dedizierten Hosts muss die Eigenschaft is_metal: true weggelassen werden.
Ordnen Sie die Containergruppe db_containers (aus dem vorherigen Schritt) einer Hostgruppe zu, indem Sie einen physical_skel-Abschnitt für die Hostgruppe in einer neuen oder vorhandenen Datei wie env.d/galera.yml bereitstellen. Beispielsweise:
```
physical_skel:
  db_containers:
    belongs_to:
      - all_containers
  db_hosts:
    belongs_to:
      - hosts
```
Definieren Sie die Host-Gruppe (db_hosts) in einer conf.d/ Datei (z.B.``galera.yml``). Beispielsweise:
```
db_hosts:
  db-host1:
    ip: 172.39.123.11
  db-host2:
    ip: 172.39.123.12
  db-host3:
    ip: 172.39.123.13
```
Bemerkung

Jeder der benutzerdefinierten Gruppennamen in diesem Beispiel (db_containers und db_hosts) ist willkürlich. Wählen Sie Ihre eigenen Gruppennamen, aber stellen Sie sicher, dass die Referenzen in allen relevanten Dateien konsistent sind.

Bereitstellen von 0 (oder mehr als einer) Komponententyp pro Host¶

Wenn OpenStack-Ansible sein dynamisches Inventar generiert, bestimmt die Affinitätseinstellung, wie viele Container eines ähnlichen Typs auf einem einzelnen physischen Host bereitgestellt werden.

Verwenden Sie shared-infra_hosts als Beispiel und betrachten Sie diese openstack_user_config.yml Konfiguration:

shared-infra_hosts:
  infra1:
    ip: 172.29.236.101
  infra2:
    ip: 172.29.236.102
  infra3:
    ip: 172.29.236.103

Drei Hosts sind der Gruppe shared-infra_hosts zugeordnet. OpenStack-Ansible stellt sicher, dass jeder Host einen einzelnen Datenbankcontainer, einen einzelnen Memcached-Container und einen einzelnen RabbitMQ-Container ausführt. Jeder Host hat standardmäßig eine Affinität von 1, was bedeutet, dass jeder Host einen von jedem Containertyp ausführt.

Wenn Sie eine eigenständige Object Storage-Umgebung (Swift) bereitstellen, können Sie die Bereitstellung von RabbitMQ überspringen. Wenn Sie diese Konfiguration verwenden, sieht Ihre openstack_user_config.yml Datei wie folgt aus:

shared-infra_hosts:
  infra1:
    affinity:
      rabbit_mq_container: 0
    ip: 172.29.236.101
  infra2:
    affinity:
      rabbit_mq_container: 0
    ip: 172.29.236.102
  infra3:
    affinity:
      rabbit_mq_container: 0
    ip: 172.29.236.103

Diese Konfiguration stellt auf jedem Host einen Memcached-Container und einen Datenbankcontainer, jedoch keine RabbitMQ-Container bereit.

Überlassen Sie einen Dienst oder eine Komponente aus der Bereitstellung¶

Um eine Komponente aus einer Bereitstellung auszulassen, können Sie eine der folgenden Optionen verwenden:

Entfernen Sie den physical_skel-Link zwischen der Containergruppe und der Hostgruppe, indem Sie die zugehörige Datei im env.d/-Verzeichnis löschen.
Führe das Playbook, das die Komponente installiert, nicht aus. Wenn Sie die Komponente nicht direkt über die Eigenschaft is_metal auf einem Host ausführen, wird ein Container für diese Komponente erstellt.
Passen Sie die Eigenschaft Bereitstellen von 0 (oder mehr als einer) Komponententyp pro Host für die Hostgruppe auf 0 an. Ähnlich wie bei der zweiten hier aufgeführten Option: Wenn Sie die Komponente nicht direkt über die Eigenschaft is_metal auf einem Host ausführen, wird ein Container für diese Komponente erstellt.

Bereitstellen mit einer anderen Containertechnologie¶

Bemerkung

Während es sich bei nspawn um eine verfügbare Containerisierungstechnologie handelt, sollte sie zu diesem Zeitpunkt als experimentell betrachtet werden. Obwohl dieses Subsystem noch nicht für die Produktion empfohlen wird, ist es stabil genug, um es der Community vorzustellen, und etwas, auf das wir gerne Rückmeldungen erhalten würden, wenn wir es im nächsten Zyklus verbessern.

OpenStack-Ansible unterstützt derzeit zwei verschiedene Container-Technologien, LXC und nspawn. Diese beiden Containertechnologien können separat oder zusammen innerhalb desselben Clusters verwendet werden, haben jedoch eine Begrenzung von nur einer Einstellung pro Host.

Verwenden Sie shared-infra_hosts als Beispiel und betrachten Sie diese openstack_user_config.yml Konfiguration:

shared-infra_hosts:
  infra1:
    ip: 172.29.236.101
    container_vars:
      container_tech: lxc
  infra2:
    ip: 172.29.236.102
    container_vars:
      container_tech: nspawn
  infra3:
    ip: 172.29.236.103

In diesem Beispiel werden die drei Hosts der Gruppe shared-infra_hosts zugewiesen und stellen containerisierte Workloads mit lxc auf infra1,` nspawn` auf infra2 und lxc `` auf infra3 bereit. Beachten Sie infra3 definiert die Option container_tech nicht, weil sie nicht benötigt wird. Wenn diese Option nicht definiert ist, wird der Wert automatisch innerhalb des generierten Inventars auf lxc gesetzt. Die zwei unterstützten Optionen für die Konfigurationsvariable container_tech sind `` lxc`` oder nspawn.