[ English | Indonesia | français | Deutsch | English (United Kingdom) | 한국어 (대한민국) | español | русский ]
Schnellstart: AIO¶
All-in-One-Builds (AIO-Builds) sind eine hervorragende Möglichkeit, OpenStack-Ansible-Builds für Folgendes auszuführen:
eine Entwicklungsumgebung
ein Überblick darüber, wie alle OpenStack-Services zusammenpassen
eine einfache Laborbereitstellung
Obwohl AIO-Builds nicht für große Produktionsbereitstellungen empfohlen werden, eignen sie sich hervorragend für kleinere Proof-of-Concept-Bereitstellungen.
Absolute minimale Serverressourcen (derzeit für Gate-Checks verwendet):
8 vCPUs
50 GB freier Speicherplatz auf der Root-Partition
8 GB RAM
Empfohlene Serverressourcen:
CPU / Motherboard, das Hardware-unterstützte Virtualisierung unterstützt
8 CPU-Kerne
80 GB freier Speicherplatz auf der Root-Partition oder 60 GB auf einer leeren sekundären Festplatte. Die Verwendung eines sekundären Laufwerks erfordert die Verwendung des Parameters `` bootstrap_host_data_disk_device``. Weitere Informationen finden Sie unter Erstellen eines AIO.
16 GB RAM
Es ist möglich, AIO-Builds zur Demonstration und Bewertung in einer virtuellen Maschine auszuführen. Die Leistung Ihrer virtuellen Maschinen ist jedoch schlecht, wenn keine verschachtelten Virtualisierungen verfügbar sind. Für Produktions-Workloads werden mehrere Knoten für bestimmte Rollen empfohlen.
Ein AIO bauen¶
Übersicht¶
Es gibt drei Schritte zum Ausführen eines AIO-Builds mit einem optionalen ersten Schritt, falls Sie Ihren Build anpassen müssen:
Den Host vorbereiten
Ansible bootstrappen und die erforderlichen Rollen
Bootstrappen der AIO Konfiguration
Führe Playbooks aus
Den Host vorbereiten¶
Wenn Sie ein AIO auf einem neuen Server erstellen, wird empfohlen, dass alle Systempakete aktualisiert werden und anschließend in den neuen Kernel neu gestartet werden:
Bemerkung
Führen Sie die folgenden Befehle und Skripts als Root-Benutzer aus.
## Ubuntu / Debian
# apt-get update
# apt-get dist-upgrade
# reboot
## CentOS
# dnf upgrade
# dnf install git-core
# systemctl stop firewalld
# systemctl mask firewalld
# reboot
Bemerkung
Before rebooting, in /etc/sysconfig/selinux, make sure that
SELINUX=enforcing is changed to SELINUX=disabled.
SELinux enabled is not currently supported in OpenStack-Ansible
for CentOS/RHEL due to a lack of maintainers for the feature.
Bemerkung
If you are installing with limited connectivity, please review Installing with limited connectivity before proceeding.
Ansible bootstrappen und die erforderlichen Rollen¶
Klonen Sie zunächst das OpenStack-Ansible-Repository und wechseln Sie in das Repository-Stammverzeichnis:
# git clone https://opendev.org/openstack/openstack-ansible \
/opt/openstack-ansible
# cd /opt/openstack-ansible
Als Nächstes wechseln Sie den zutreffenden Zweig / Tag, von dem die Bereitstellung erfolgen soll. Beachten Sie, dass das Deployment vom Kopf eines Zweiges zu einem instabilen Build aufgrund von Änderungen im Flug und Upstream-Änderungen führen kann. Für einen Test (zum Beispiel keine Entwicklung) ist es normalerweise am besten, die neueste getaggte Version auszuprobieren.
# # List all existing tags. # git tag -l # # Checkout the stable branch and find just the latest tag # git checkout stable/xena # git describe --abbrev=0 --tags # # Checkout the latest tag from either method of retrieving the tag. # git checkout xena-eom
Bemerkung
The Xena release is only compatible with Debian 10 (buster), Debian 11 (bullseye), Ubuntu 18.04 (Bionic Beaver), Ubuntu 20.04 (Focal Fossa), CentOS 8 and CentOS 8 Stream.
Warnung
The announcement of early end-of-life for CentOS 8 and the migration to CentOS Stream leaves OpenStack-Ansible currently un-installable on CentOS Stream. A number of critical dependencies are taken from the EPEL repository and currently these will not install onto a CentOS Stream host. Careful consideration should be given to the life-cycle of any new deployments on CentOS 8.
Der nächste Schritt ist das Bootstrappen von Ansible und die Ansible-Rollen für die Entwicklungsumgebung
Rufen Sie Folgendes auf zum Boostrappen von Ansible und den erforderlichen Rollen:
# scripts/bootstrap-ansible.sh
Bemerkung
Möglicherweise tritt beim Ausführen des Ansible-Bootstrap-Skripts beim Erstellen einiger Python-Erweiterungen (wie pycrypto) ein Fehler auf, der besagt:
configure: error: cannot run C compiled programs.
Der Grund für diesen Fehler liegt möglicherweise in einem noexec-Mount-Flag, das für das Dateisystem verwendet wird, das /tmp zugeordnet ist. Sie können dies überprüfen, indem Sie den folgenden Befehl ausführen:
# mount | grep $(df /tmp | tail -n +2 | awk '{print $1}') | grep noexec
Wenn dies der Fall ist, können Sie einen alternativen Pfad angeben, für den diese Mount-Option nicht festgelegt ist:
# TMPDIR=/var/tmp scripts/bootstrap-ansible.sh
Bootstrappen der AIO Konfiguration¶
Damit alle Dienste ausgeführt werden können, muss der Host mit den entsprechenden Festplattenpartitionierungen, Paketen, Netzwerkkonfigurationen und Konfigurationen für die OpenStack-Bereitstellung vorbereitet sein.
Standardmässig installiert das AIO Bootstrap Script ein Basisset von OpenStack Diensten mit sensiblen Einstellungen für den Gate-Check, Entwicklung- oder Test-Systeme.
Überprüfen Sie die bootstrap-host role defaults Datei, um verschiedene Konfigurationsoptionen anzuzeigen. Bereitsteller haben die Möglichkeit zu ändern, wie der Host bootstrapped wird. Dies ist nützlich, wenn Sie möchten, dass das AIO eine sekundäre Datenfestplatte verwendet oder wenn Sie diese Rolle zum Bootstrap einer Entwicklungsumgebung mit mehreren Knoten verwenden.
Das Bootstrap-Skript ist voreingestellt, um die Umgebungsvariable `` BOOTSTRAP_OPTS`` als zusätzliche Option an den Bootstrap-Prozess zu übergeben. Wenn Sie beispielsweise festlegen möchten, dass der Bootstrap ein bestimmtes sekundäres Speichergerät (/dev /sdb) neu partitioniert, wodurch alle Daten auf dem Gerät gelöscht werden, führen Sie Folgendes aus:
# export BOOTSTRAP_OPTS="bootstrap_host_data_disk_device=sdb"
Zusätzliche Optionen können implementiert werden, indem sie einfach mit einem Leerzeichen zwischen den einzelnen Optionen verknüpft werden, z. B .:
# export BOOTSTRAP_OPTS="bootstrap_host_data_disk_device=sdb"
# export BOOTSTRAP_OPTS="${BOOTSTRAP_OPTS} bootstrap_host_data_disk_fs_type=xfs"
If you are installing with limited connectivity, or you don’t have default route set, you will need to define interface for outgoing connections manually
# export BOOTSTRAP_OPTS="bootstrap_host_public_interface=eth1"
Für das Standard-AIO-Szenario wird die Vorbereitung der AIO-Konfiguration abgeschlossen, indem Sie Folgendes ausführen:
# scripts/bootstrap-aio.sh
Um OpenStack Services über die Bootstrap-aio Default Services für das entsprechende Szenario hinzuzufügen, kopieren Sie die` conf.d`-Dateien mit der Dateierweiterung` aio` nach` /etc/openstack_deploy` und benenne sie dann in .yml -Dateien um. Um beispielsweise die OpenStack Telemetrie-Dienste zu aktivieren, führen Sie Folgendes aus:
# cd /opt/openstack-ansible/
# cp etc/openstack_deploy/conf.d/{aodh,gnocchi,ceilometer}.yml.aio /etc/openstack_deploy/conf.d/
# for f in $(ls -1 /etc/openstack_deploy/conf.d/*.aio); do mv -v ${f} ${f%.*}; done
It is possible to also do this (and change other defaults) during the bootstrap script initial execution by changing the SCENARIO environment variable before running the script. The key word ‚aio‘ will ensure that a basic set of OpenStack services (cinder, glance, horizon, neutron, nova) will be deployed. The key words ‚lxc‘ can be used to set the container back-end, while the key word ‚metal‘ will deploy all services without containers. In order to implement any other services, add the name of the conf.d file name without the .yml.aio extension into the SCENARIO environment variable. Each key word should be delimited by an underscore. For example, the following will implement an AIO with barbican, cinder, glance, horizon, neutron, and nova. It will set the cinder storage back-end to ceph and will make use of LXC as the container back-end.
# export SCENARIO='aio_lxc_barbican_ceph'
# scripts/bootstrap-aio.sh
To add any global overrides, over and above the defaults for the applicable
scenario, edit /etc/openstack_deploy/user_variables.yml. In order to
understand the various ways that you can override the default behaviour
set out in the roles, playbook and group variables, see Überschreiben der Standardkonfiguration.
Schauen Sie Deployment Guide für mehr Informationen, wie Ihre eigene Konfiguration in AIP Boostrap zu verwenden ist.
Führe Playbooks aus¶
Führen Sie abschließend die Playbooks aus, indem Sie Folgendes ausführen:
# cd /opt/openstack-ansible/playbooks
# openstack-ansible setup-hosts.yml
# openstack-ansible setup-infrastructure.yml
# openstack-ansible setup-openstack.yml
Der Installationsvorgang wird einige Zeit in Anspruch nehmen, aber hier einige allgemeine Schätzungen:
Bare-Metal-Systeme mit SSD-Speicher: ~ 30-50 Minuten
Virtuelle Maschinen mit SSD-Speicher: ~ 45-60 Minuten
Systeme mit traditionellen Festplatten: ~ 90-120 Minuten
Sobald die Playbooks vollständig ausgeführt wurden, ist es möglich, mit verschiedenen Einstellungsänderungen in /etc/openstack_deploy/user_variables.yml zu experimentieren und nur einzelne Playbooks auszuführen. Um beispielsweise das Playbook für den Keystone-Service auszuführen, führen Sie Folgendes aus:
# cd /opt/openstack-ansible/playbooks
# openstack-ansible os-keystone-install.yml
Neustart eines AIO¶
Da die AIO alle drei Cluster-Mitglieder von MariaDB / Galera umfasst, muss der Cluster nach dem Neustart des Hosts neu initialisiert werden.
Dies geschieht, indem Sie Folgendes ausführen:
# cd /opt/openstack-ansible/playbooks
# openstack-ansible -e galera_ignore_cluster_state=true galera-install.yml
If this fails to get the database cluster back into a running state, then please make use of the Galera Cluster Recovery section in the operations guide.
Wiederaufbau eines AIO¶
Manchmal kann es nützlich sein, alle Container zu zerstören und das AIO neu aufzubauen. Während es bevorzugt wird, dass der AIO vollständig zerstört und neu aufgebaut wird, ist dies nicht immer praktisch. Daher kann stattdessen Folgendes ausgeführt werden:
# # Move to the playbooks directory.
# cd /opt/openstack-ansible/playbooks
# # Destroy all of the running containers.
# openstack-ansible lxc-containers-destroy.yml
# # On the host stop all of the services that run locally and not
# # within a container.
# for i in \
$(ls /etc/init \
| grep -e "nova\|swift\|neutron\|cinder" \
| awk -F'.' '{print $1}'); do \
service $i stop; \
done
# # Uninstall the core services that were installed.
# for i in $(pip freeze | grep -e "nova\|neutron\|keystone\|swift\|cinder"); do \
pip uninstall -y $i; done
# # Remove crusty directories.
# rm -rf /openstack /etc/{neutron,nova,swift,cinder} \
/var/log/{neutron,nova,swift,cinder}
# # Remove the pip configuration files on the host
# rm -rf /root/.pip
# # Remove the apt package manager proxy
# rm /etc/apt/apt.conf.d/00apt-cacher-proxy
Wenn eine vorhandene AIO-Umgebung neu installiert werden muss, besteht die effizienteste Methode darin, das Host-Betriebssystem zu zerstören und neu zu starten. Aus diesem Grund werden AIOs am besten in Form einer virtuellen Maschine oder eines Cloud-Gastes ausgeführt.
Referenzdiagramm für einen AIO Build¶
Hier ist ein grundlegendes Diagramm, das versucht zu veranschaulichen, wie die resultierende AIO-Bereitstellung aussieht.
Dieses Diagramm ist nicht maßstabsgetreu und nicht einmal 100% genau. Dieses Diagramm wurde nur zu Informationszwecken erstellt und sollte ** NUR ** als solches verwendet werden.
------->[ ETH0 == Public Network ]
|
V [ * ] Socket Connections
[ HOST MACHINE ] [ <>v^ ] Network Connections
* ^ *
| | |-------------------------------------------------------
| | |
| |---------------->[ HAProxy ] |
| ^ |
| | |
| V |
| (BR-Interfaces)<------ |
| ^ * | |
*-[ LXC ]*--*----------------------|-----|------|----| |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | V * | |
| * | | [ Galera x3 ] |
| [ Memcached ]<------------| | | |
*-------*[ Rsyslog ]<--------------|--| | * |
| [ Repos Server x3 ]<------| ---|-->[ RabbitMQ x3 ] |
| [ Horizon x2 ]<-----------| | | |
| [ Nova api ec2 ]<---------|--| | |
| [ Nova api os ]<----------|->| | |
| [ Nova console ]<---------| | | |
| [ Nova Cert ]<------------|->| | |
| [ Cinder api ]<-----------|->| | |
| [ Glance api ]<-----------|->| | |
| [ Heat apis ]<------------|->| | [ Loop back devices ]*-*
| [ Heat engine ]<----------|->| | \ \ |
| ------>[ Nova api metadata ] | | | { LVM } { XFS x3 } |
| | [ Nova conductor ]<-------| | | * * |
| |----->[ Nova scheduler ]--------|->| | | | |
| | [ Keystone x3 ]<----------|->| | | | |
| | |--->[ Neutron agents ]*-------|--|---------------------------*
| | | [ Neutron server ]<-------|->| | | |
| | | |->[ Swift proxy ]<----------- | | | |
*-|-|-|-*[ Cinder volume ]*----------------------* | |
| | | | | | |
| | | ----------------------------------------- | |
| | ----------------------------------------- | | |
| | -------------------------| | | | |
| | | | | | |
| | V | | * |
---->[ Compute ]*[ Neutron linuxbridge ]<---| |->[ Swift storage ]-
