Ganz vorne weg: in diesem Artikel werde ich viele der aktuellen buzzwords verwenden.
Wenn man sich die vielen neuen und spannenden technologien anschauen möchte, braucht man eine Menge Ressourcen. Nicht grade leichtgewichtig kommen sie daher. OpenStack bietet hier keine Ausnahme. Es ist das Softwareprodukt das man einsetzen möchte, wenn man sich mit den Prinzipien und funktionsweisen von Cloudumgebungen wie AWS oder GCE auseinandersetzen möchte.
OpenStack setzt sich aus einer ziemlich großen Latte an einzelnenen Services zusammen. Dabei kann man zwischen unbedingt notwendigen Diensten die Keystone und möglichen Diensten wie Zun unterscheiden. Alle diese Services haben gemeinsam, dass sie unabhängig voneinander installiert und in die Umgebung integriert werden können. Das ist bei kleinen Umgebungen wie in den meisten Firmen vermutlich so nicht notwendig. Mit einem Blick auf eine große Cloudumgebung hingegen macht es sinn.
Zum lernen und aufbauen meiner Testumgebungen nutze ich gern Vagrant. Damit kann ich mir diverse Order mit meinen Projekten machen und mir immer eine frische virtuelle Umgebung provisionieren, wenn ich sie brauche. Alles was sich nicht auf diese Art und Weise vorhalten lässt wurde nicht richtig gebaut und ist mist.
Es macht wirklich keinen Spaß OpenStack von Hand zu installieren. Daher sollte man sich eine Lösung wie Kolla-Ansible ansehen. Kolla-Ansible ist ein wirklich interessantes Projekt, das die oben genannten OpenStack-Komponenten in Docker verpackt und ausliefert. So spart man sich enorm viel Einrichtungsaufwand und hat vor allem nochmals eine Abstraktionsebene die im Falle eine Fehlverhaltens oder defekte unkompliziert getauscht und beeinflusst werden kannst.
Zentrale Komponente von Kolla-Ansible ist die Datei /etc/kolla/globals.yml über diese werden die notwendigen und gewünschten Einstellungen definiert und über die kolla-ansible Befehle angewendet.
Sofern eine VM zur Hand ist, gehe ich folgenden Schritte für eine laufenden All-in-One Umgebung.
Wer sich ein wenig tiefer einlesen möchte, dem sei die Dokumentation ans Herz gelegt:
https://docs.openstack.org/kolla-ansible/latest/user/quickstart.html
Nach der Dokumentation sollte eine all-in-one Maschine folgende Ressourcen aufweisen
Jetzt geht es ans eingemachte. Wir fangen an den Server zu installieren
Während meiner Setuporgien habe ich ein paar Fehler gehabt, welche ich durch die Art und Weise der Einrichtung umgehe.
yum install -y epel-release
yum upgrade -y
yum install -y python-devel libffi-devel gcc openssl-devel libselinux-python
pip install -U pip
pip uninstall requests
pip uninstall urllib3
yum remove -y python-urllib3 python-requests
pip freeze | grep requests
yum install -y python-urllib3 python-requests
rebootIch gehe den Weg direkt auf der Maschine zu arbeiten ohne weitere Verschachtelungen.
easy_install pip
pip install -U pip
yum install ansible
pip install --upgrade decorate
pip install kolla-ansible
pip install --ignore-installed python-openstackclient
mkdir -p /etc/kolla
chown $USER:$USER /etc/kolla
cp -r /usr/share/kolla-ansible/etc_examples/kolla/* /etc/kolla
cp /usr/share/kolla-ansible/ansible/inventory/* .Nun sollten wir ein Kolla-Ansible samt Abhängigkeiten und Inventory haben. Ein Inventory wird genutzt um die Umgebung der Server zu pflegen und Aufganen zu verteilen. In unserem Fall landet alles auf einem Server - sollte man aber vor haben OpenStack so richtig zu nutzen und eine größere Installation planen, so sollte man sich unbedingt anschauen was die Datei multinode zu bieten hat.
Bei einem System wie OpenStack kann man sich vorstellen, das an allen Ecken und enden ein Kennwort vergeben wird. Wir können froh sein, dass Kolla-Ansible sich für uns darum kümmert - ansonsten wären wir lange beschäftigt.
kolla-genpwdDieser Befelhl sorgt dafür, dass wir die Datei /etc/kolla/passwords.yml mit Leben füllen. Darin enthalten sind alle Kennwörter - also vorsicht.
Die Datei /etc/kolla/globals.yml ist die zentrale Anlaufstelle um die Ausstattung und Konfiguration unseres OpenStack Server vorzunehmen. Hier sollte man sich Zeit lassen und die Möglichkeite studieren. In meinem einfachen Fall enthält die Datei den folgenden Inhalt:
---
---
config_strategy: "COPY_ALWAYS"
kolla_base_distro: "centos"
kolla_install_type: "binary"
openstack_release: "train"
kolla_internal_vip_address: "192.168.124.254"
kolla_external_vip_address: "{{ kolla_internal_vip_address }}"
docker_configure_for_zun: "no"
network_interface: "eth0"
network_address_family: "ipv4"
openstack_region_name: "itemisDemoRegion"
enable_openstack_core: "yes"
enable_aodh: "yes"
enable_heat: "{{ enable_openstack_core | bool }}"
enable_horizon: "{{ enable_openstack_core | bool }}"
enable_horizon_blazar: "{{ enable_blazar | bool }}"
enable_horizon_cloudkitty: "{{ enable_cloudkitty | bool }}"
enable_horizon_congress: "{{ enable_congress | bool }}"
enable_horizon_designate: "{{ enable_designate | bool }}"
enable_horizon_fwaas: "{{ enable_neutron_fwaas | bool }}"
enable_horizon_freezer: "{{ enable_freezer | bool }}"
enable_horizon_heat: "{{ enable_heat | bool }}"
enable_horizon_ironic: "{{ enable_ironic | bool }}"
enable_horizon_karbor: "{{ enable_karbor | bool }}"
enable_horizon_magnum: "{{ enable_magnum | bool }}"
enable_horizon_manila: "{{ enable_manila | bool }}"
enable_horizon_masakari: "{{ enable_masakari | bool }}"
enable_horizon_mistral: "{{ enable_mistral | bool }}"
enable_horizon_murano: "{{ enable_murano | bool }}"
enable_horizon_neutron_vpnaas: "{{ enable_neutron_vpnaas | bool }}"
enable_horizon_octavia: "{{ enable_octavia | bool }}"
enable_horizon_qinling: "{{ enable_qinling | bool }}"
enable_horizon_sahara: "{{ enable_sahara | bool }}"
enable_horizon_searchlight: "{{ enable_searchlight | bool }}"
enable_horizon_senlin: "{{ enable_senlin | bool }}"
enable_horizon_solum: "{{ enable_solum | bool }}"
enable_horizon_tacker: "{{ enable_tacker | bool }}"
enable_horizon_trove: "{{ enable_trove | bool }}"
enable_horizon_vitrage: "{{ enable_vitrage | bool }}"
enable_horizon_watcher: "{{ enable_watcher | bool }}"
enable_horizon_zun: "{{ enable_zun | bool }}"
enable_kuryr: "no"
enable_magnum: "yes"
enable_mistral: "no"
enable_murano: "no"
enable_senlin: "yes"
enable_zun: "no"
nova_compute_virt_type: "qemu"
num_nova_fake_per_node: 5Jetzt geht es los und wir bauen unser OpenStack auf
kolla-ansible -i ./all-in-one bootstrap-servers
kolla-ansible -i ./all-in-one prechecks
kolla-ansible -i ./all-in-one deployDas Passwort für das Web-Ui-Dashboard Dingen erhalten wir aus unserer zentralen Kennwort-Datenbank:
grep -i keystone_admin_password /etc/kolla/passwords.yml Nun können wir uns schon auf dem Horizon-Web-Ding anmelden. Dazu steuern wir einfach die Host-Adresse - oder noch besser die virtual IP an. In meinem Fall also die 192.168.124.254
Weil das aber voll langweilig ist, setzen wir noch einen nach und installieren gleich ein paar Demo Daten:
kolla-ansible post-deploy
. /etc/kolla/admin-openrc.sh
#deploy the demo stuff
/usr/share/kolla-ansible/init-runonce
# deploy demo instance
openstack server create --image cirros --flavor m1.tiny --key-name mykey --network demo-net demo1Quellen und Links:
Ich mach es kurz: ich liebe Proxmox als einfache und potente Lösung für die Virtualisierung. Es macht einfach Spaß und bedient viele Bedürfnisse die man so in der IT-Infrastruktur hat.
Das Update auf Version 6 hat bei mir einige Probleme gelöst und dem ganzen natürlich einen neuen Anstrich gegeben. Gleichzeitig war es cool, das man zweigleisig fahren konnte - also Hosts mit Version 5 und Hosts mit Version 6 im Cluster mischen kann.
In meinem Beitrag zeige ich auf, wie ich as Upgrade möglich kompakt durchgeführt habe und die notwendigen Schritte quasi mit Copy and Paste gegangen bin.
Zunähchst einmal wollen wir aktualisieren was wir unter den Fingern haben. Das ist immer gut und minimiert die Stolpersteine.
apt-get update && apt-get dist-upgrade -y && apt-get autoclean -y && apt-get autoremove -yNach dem Update wollen wir schauen, was wir überhaupt zu tun haben. Dafür wird ein kleines Skript mitgeliefert, welches wir gefahrlos ausfühen können.
pve5to6Normaler Weise wollen wir HA. So jedoch nicht wenn wir updaten - andernfalls haben wir russisch Roulette mit den Diensten. Daher schalten wir auf allen Knoten die HA-Services ab.
systemctl stop pve-ha-lrm
systemctl stop pve-ha-crm
systemctl status pve-ha-lrm pve-ha-crm | grep -i activeSofern CEPH im Einsatz ist, wollen wir ausnahmesweise mal kein rebalancing solange wir die Software aktualisieren und die Kisten rebooten.
ceph osd set nooutJetzt geht es los: damit wir nicht alles still legen, aktualisieren wir zunächst Corosync - das ist einfach gemacht und funktionierte bei mir auch ohne sorgen im Cluster - quasi on the fly
echo "deb http://download.proxmox.com/debian/corosync-3/ stretch main" > /etc/apt/sources.list.d/corosync3.list
apt update
apt dist-upgrade --download-only
apt dist-upgrade -yOb alles richtig gelaufen ist, sehen wir durch das folgende Kommando.
pvecm statusJetzt könnte man die HA-Dienste wieder starten - ich mache das nicht, ich will schnell fertig werden.
systemctl start pve-ha-lrm
systemctl start pve-ha-crm
systemctl status pve-ha-lrm pve-ha-crm | grep -i activeDamit wir nun das gesamte System aktualisieren können, müssen wir auch die vorhandenen Repos anfassen. Ich bin faul und mache das mit sed.
sed -i 's/stretch/buster/g' /etc/apt/sources.list
sed -i 's/stretch/buster/g' /etc/apt/sources.list.d/pve-*Wenn Ceph im Einsatz ist empfiehlt es sich wirklich das auch gleich mit zu aktualisieren. Bei meinem drei Knoten Backup Cluster hat es wunder gewirkt.
echo "deb http://download.proxmox.com/debian/ceph-luminous buster main" > /etc/apt/sources.list.d/ceph.listJetzt wird es ernst. Bitte anschnallen und die Hosen hochziehen. Wir aktualisieren.
apt update
apt-get dist-upgrade -yWenn wir fertig sind, die Hosts und VMs alle wieder laufen, dann können wir auch ein wenig aufräumen.
rm /etc/apt/sources.list.d/corosync3.list
apt-get autoclean -y
apt-get autoremove -yCeph only
ceph osd unset noout Memo an mich selbst: Sollte es vorkommen, das ceph health detail der Meinung ist, das inkonsistente Placementgroups vorhanden sind: cool bleiben!
Wenn man es nicht auf die lange Bank schiebt und sich die Doku dazu gut angesehen hat, dann wird man recht schnell fündig wie man der Sache Herr werden kann.
Zunächst einmal findet man heraus, welche PGs kaputt sind:
ceph health detail
HEALTH_ERR 2 scrub errors; Possible data damage: 2 pgs inconsistent
OSD_SCRUB_ERRORS 2 scrub errors
PG_DAMAGED Possible data damage: 2 pgs inconsistent
pg 9.9d is active+clean+inconsistent, acting [2,12,23]
pg 9.fe is active+clean+inconsistent, acting [15,23,2]Man sieht hier, das die PGs mit den IDs 9.9d und 9.fe einen weg haben.
Anschließend startet man die Heilung:
ceph pg repair 9.9d
ceph pg repair 9.feGar nicht so schwer, oder?