[ English | русский | español | English (United Kingdom) | Deutsch | Indonesia ]
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
derenv.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 einenphysical_skel
-Abschnitt für die Hostgruppe in einer neuen oder vorhandenen Datei wieenv.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 einerconf.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
unddb_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 leverageis_nest
property and allow all infra containers to be part of the AZ group as wellcomponent_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 imenv.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