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

Never edit or delete the file /etc/openstack_deploy/openstack_inventory.json. This can lead to problems with the inventory: existng hosts and containers will be unmanaged and new ones will be generated instead, breaking your existing deployment.

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.

Adding virtual nest groups¶

If you want to create a custom group for arbitrary grouping of hosts and containers within these hosts but skip the generation of any new containers, you should use is_nest property under container_skel and skip defining belongs_to structure. is_nest property will add host-containers as children to such a group.

Example: Defining Availability Zones¶

A good example of how is_nest property can be used is describing Availability Zones. As when operating multiple AZs it’s handy to define AZ-specific variables, like AZ name, for all hosts in this AZ. And leveraging group_vars is best way of ensuring that all hosts that belong to same AZ have same configuration applied.

Let’s assume you have 3 controllers and each of them is placed in different Availability Zones. There is also a compute node in each Availability Zone. And we want each host or container that is placed physically in a specific AZ be part of it’s own group (ie azN_all)

In order to achieve that we need:

Define host groups in conf.d or openstack_user_config.yml to assign hosts accordingly to their Availability Zones:

az1-infra_hosts: &infra_az1
  az1-infra1:
    ip: 172.39.123.11

az2-infra_hosts: &infra_az2
  az2-infra2:
    ip: 172.39.123.12

az3-infra_hosts: &infra_az3
  az3-infra3:
    ip: 172.39.123.13

shared-infra_hosts: &controllers
  <<: *infra_az1
  <<: *infra_az2
  <<: *infra_az3

az1-compute_hosts: &computes_az1
  az1-compute01:
    ip: 172.39.123.100

az2-compute_hosts: &computes_az2
  az2-compute01:
    ip: 172.39.123.150

az3-compute_hosts: &computes_az3
  az3-compute01:
    ip: 172.39.123.200

compute_hosts:
  <<: *computes_az1
  <<: *computes_az2
  <<: *computes_az3

az1_hosts:
  <<: *computes_az1
  <<: *infra_az1

az2_hosts:
  <<: *computes_az2
  <<: *infra_az2

az3_hosts:
  <<: *computes_az3
  <<: *infra_az3

Create env.d/az.yml file that will leverage is_nest property and allow all infra containers to be part of the AZ group as well

component_skel:
  az1_containers:
    belongs_to:
      - az1_all
  az1_hosts:
    belongs_to:
      - az1_all

  az2_containers:
    belongs_to:
      - az2_all
  az2_hosts:
    belongs_to:
      - az2_all

  az3_containers:
    belongs_to:
      - az3_all
  az3_hosts:
    belongs_to:
      - az3_all

container_skel:
  az1_containers:
    properties:
      is_nest: True
  az2_containers:
    properties:
      is_nest: True
  az3_containers:
    properties:
      is_nest: True

Now you can leverage group_vars file to apply a variable to all containers and bare metal hosts in AZ. For example /etc/openstack_deploy/group_vars/az1_all.yml:
```
---
az_name: az1
cinder_storage_availability_zone: "{{ az_name }}"
```

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 Adding virtual nest groups 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.

Having SSH network different from OpenStack Management network¶

In some environments SSH network that is used to access nodes from deploy host and management network are different. In this case it’s important that services were listening on correct network while ensure that Ansible use SSH network for accessing managed hosts. In these cases you can define management_ip key while defining hosts in your openstack_user_config.yml file.

management_ip will be used as management_address for the node, while ip will be used as ansible_host for accessing node by SSH.

Example:

shared-infra_hosts:
  infra1:
    ip: 192.168.0.101
    management_ip: 172.29.236.101

Konfigurieren des Inventars