[ English | 한국어 (대한민국) | English (United Kingdom) | Indonesia | français | русский | Deutsch ]
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
# apt-get update
# apt-get dist-upgrade
# reboot
## CentOS
# yum upgrade
# yum install git
# 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.
## openSUSE
# zypper up
# zypper in git-core
# reboot
Bemerkung
Wenn Sie mit eingeschränkter Konnektivität arbeiten, lesen Sie den Anhang Installing with limited connectivity im Bereitstellungshandbuch Deployment Guide bevor wir fortfahren.
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/ussuri # git describe --abbrev=0 --tags # # Checkout the latest tag from either method of retrieving the tag. # git checkout ussuri-em
Bemerkung
The Ussuri release is only compatible with Debian 10 (buster), Ubuntu 18.04 (Bionic Beaver), Ubuntu 20.04 (Focal Fossa), CentOS 7 and CentOS 8. Experimentat support is provided for openSUSE Leap 15.X but this is expected to be removed in the next major release.
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"
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
Sie können dies auch während der ersten Ausführung des Bootstrap-Skripts tun (und andere Standardeinstellungen ändern), indem Sie die SCENARIO-Umgebungsvariable ändern, bevor Sie das Skript ausführen. Mit dem Schlüsselwort ‚aio‘ wird sichergestellt, dass ein grundlegender Satz von OpenStack-Diensten (Cinder, Glance, Horizont, Neutron, Nova) bereitgestellt wird. Mit den Schlüsselwörtern ‚lxc‘ und ‚nspawn‘ kann das Container-Back-End festgelegt werden. Mit dem Schlüsselwort ‚metal‘ werden alle Dienste ohne Container bereitgestellt. Um andere Dienste zu implementieren, fügen Sie den Namen der Datei „conf.d“ ohne die Erweiterung „.yml.aio“ in die Umgebungsvariable SCENARIO ein. Jedes Schlüsselwort sollte durch einen Unterstrich begrenzt werden. Im Folgenden wird beispielsweise ein AIO mit Barbican, Cinder, Glance, Horizont, Neutron und Nova implementiert. Das Cinder-Speicher-Back-End wird auf ceph gesetzt und LXC wird als Container-Back-End verwendet.
# export SCENARIO='aio_lxc_barbican_ceph'
# scripts/bootstrap-aio.sh
Bemerkung
If the ‚metal‘ and ‚aio‘ key words are used together, horizon will not be deployed because haproxy and horizon will conflict on the same listening ports.
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
Wenn dies den Datenbank-Cluster nicht in einen aktiven Zustand versetzt, verwenden Sie den Abschnitt Galera Cluster Recover </admin/maintenance-tasks.html#galera-cluster-recovery> im Betriebshandbuch.
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 ]-
