osp director operator
v1.2.3
Der OSP -Direktor -Betreiber erstellt über OpenShift eine Reihe benutzerdefinierter Ressourcendefinitionen, um Ressourcen zu verwalten, die normalerweise von der Undercloud des Tripleo erstellt wurden. Diese CRDs werden in zwei Typen für Hardwarebereitstellung und Softwarekonfiguration aufgeteilt.
Der OSP -Direktor -Betreiber wird über den OLM -Operator Lifecycle Manager installiert und verwaltet. OLM wird automatisch mit Ihrer OpenShift -Installation installiert. Um den neuesten OSP -Director -Operator Snapshot zu erhalten, müssen Sie die entsprechende Katalogsource, die Bedienergruppe und das Abonnement erstellen, um die Installation mit OLM voranzutreiben:
oc new-project openstack apiVersion : operators.coreos.com/v1alpha1
kind : CatalogSource
metadata :
name : osp-director-operator-index
namespace : openstack
spec :
sourceType : grpc
image : quay.io/openstack-k8s-operators/osp-director-operator-index:0.0.1 apiVersion : operators.coreos.com/v1
kind : OperatorGroup
metadata :
name : " osp-director-operator-group "
namespace : openstack
spec :
targetNamespaces :
- openstack apiVersion : operators.coreos.com/v1alpha1
kind : Subscription
metadata :
name : osp-director-operator-subscription
namespace : openstack
spec :
config :
env :
- name : WATCH_NAMESPACE
value : openstack,openshift-machine-api,openshift-sriov-network-operator
source : osp-director-operator-index
sourceNamespace : openstack
name : osp-director-operator
startingCSV : osp-director-operator.v0.0.1
channel : alphaWir haben ein Skript, um die Installation hier mit OLM zu automatisieren, um ein bestimmtes Tag: Skript zu automatisieren, um die Installation zu automatisieren
Hinweis : Irgendwann in der Zukunft können wir uns in OperatorHub integrieren, damit der OSP -Direktor -Betreiber automatisch in Ihren OCP -Installations -Standard -OLM -Katalogquellen verfügbar ist.
Erstellen Sie vor der Bereitstellung von OpenStack ein Basis -RHEL -Datenvolumen. Dies wird von den Controller -VMs verwendet, die über OpenShift -Virtualisierung bereitgestellt werden. Der Ansatz dazu ist wie folgt:
virtctl : sudo subscription-manager repos --enable=cnv-2.6-for-rhel-8-x86_64-rpms
sudo dnf install -y kubevirt-virtctl
curl -O http://download.devel.redhat.com/brewroot/packages/rhel-guest-image/8.4/1168/images/rhel-guest-image-8.4-1168.x86_64.qcow2
dnf install -y libguestfs-tools-c
virt-customize -a < rhel guest image > --run-command ' sed -i -e "s/^(kernelopts=.*)net.ifnames=0 (.*)/12/" /boot/grub2/grubenv '
virt-customize -a < rhel guest image > --run-command ' sed -i -e "s/^(GRUB_CMDLINE_LINUX=.*)net.ifnames=0 (.*)/12/" /etc/default/grub '/etc/hosts hinzu: <cluster ingress VIP> cdi-uploadproxy-openshift-cnv.apps.<cluster name>.<domain name>
virtctl hoch: virtctl image-upload dv openstack-base-img -n openstack --size=50Gi --image-path=<local path to image> --storage-class <desired storage class> --insecure
storage-class eine aus, die Sie verwenden möchten, die in: oc get storageclass
Definieren Sie Ihre openStacknetConfig -benutzerdefinierte Ressource. Für die CTLPlane ist mindestens ein Netzwerk erforderlich. Optional können Sie mehrere Netzwerke in der CR definieren, die mit der Network -Isolationsarchitektur von Tripleo verwendet werden können. Zusätzlich zur Netzwerkdefinition enthält das OpenStackNet Informationen, mit denen die Netzwerkkonfigurationsrichtlinie definiert wird, mit der VMs über OpenShift -Virtualisierung an dieses Netzwerk angehängt werden. Das Folgende ist ein Beispiel für ein einfaches IPv4 -CTLPLANE -Netzwerk, das Linux Bridge für seine Hostkonfiguration verwendet.
apiVersion : osp-director.openstack.org/v1beta1
kind : OpenStackNetConfig
metadata :
name : openstacknetconfig
spec :
attachConfigurations :
br-osp :
nodeNetworkConfigurationPolicy :
nodeSelector :
node-role.kubernetes.io/worker : " "
desiredState :
interfaces :
- bridge :
options :
stp :
enabled : false
port :
- name : enp7s0
description : Linux bridge with enp7s0 as a port
name : br-osp
state : up
type : linux-bridge
mtu : 1500
# optional DnsServers list
dnsServers :
- 192.168.25.1
# optional DnsSearchDomains list
dnsSearchDomains :
- osptest.test.metalkube.org
- some.other.domain
# DomainName of the OSP environment
domainName : osptest.test.metalkube.org
networks :
- name : Control
nameLower : ctlplane
subnets :
- name : ctlplane
ipv4 :
allocationEnd : 192.168.25.250
allocationStart : 192.168.25.100
cidr : 192.168.25.0/24
gateway : 192.168.25.1
attachConfiguration : br-osp
# optional: (OSP17 only) specify all phys networks with optional MAC address prefix, used to
# create static OVN Bridge MAC address mappings. Unique OVN bridge mac address per node is
# dynamically allocated by creating OpenStackMACAddress resource and create a MAC per physnet per node.
# - If PhysNetworks is not provided, the tripleo default physnet datacentre gets created.
# - If the macPrefix is not specified for a physnet, the default macPrefix "fa:16:3a" is used.
# - If PreserveReservations is not specified, the default is true.
ovnBridgeMacMappings :
preserveReservations : True
physNetworks :
- macPrefix : fa:16:3a
name : datacentre
- macPrefix : fa:16:3b
name : datacentre2
# optional: configure static mapping for the networks per nodes. If there is none, a random gets created
reservations :
controller-0 :
macReservations :
datacentre : fa:16:3a:aa:aa:aa
datacentre2 : fa:16:3b:aa:aa:aa
compute-0 :
macReservations :
datacentre : fa:16:3a:bb:bb:bb
datacentre2 : fa:16:3b:bb:bb:bbWenn Sie das obige YAML in eine Datei namens networkConfig.yaml schreiben, können Sie den OpenStackNetConfig über diesen Befehl erstellen:
oc create -n openstack -f networkconfig.yamlUm die Netzwerkisolation mit VLAN zu verwenden, fügen Sie die VLAN -ID der Spezifikation der Netzwerkdefinition hinzu
apiVersion : osp-director.openstack.org/v1beta1
kind : OpenStackNetConfig
metadata :
name : openstacknetconfig
spec :
attachConfigurations :
br-osp :
nodeNetworkConfigurationPolicy :
nodeSelector :
node-role.kubernetes.io/worker : " "
desiredState :
interfaces :
- bridge :
options :
stp :
enabled : false
port :
- name : enp7s0
description : Linux bridge with enp7s0 as a port
name : br-osp
state : up
type : linux-bridge
mtu : 1500
br-ex :
nodeNetworkConfigurationPolicy :
nodeSelector :
node-role.kubernetes.io/worker : " "
desiredState :
interfaces :
- bridge :
options :
stp :
enabled : false
port :
- name : enp6s0
description : Linux bridge with enp6s0 as a port
name : br-ex-osp
state : up
type : linux-bridge
mtu : 1500
# optional DnsServers list
dnsServers :
- 192.168.25.1
# optional DnsSearchDomains list
dnsSearchDomains :
- osptest.test.metalkube.org
- some.other.domain
# DomainName of the OSP environment
domainName : osptest.test.metalkube.org
networks :
- name : Control
nameLower : ctlplane
subnets :
- name : ctlplane
ipv4 :
allocationEnd : 192.168.25.250
allocationStart : 192.168.25.100
cidr : 192.168.25.0/24
gateway : 192.168.25.1
attachConfiguration : br-osp
- name : InternalApi
nameLower : internal_api
mtu : 1350
subnets :
- name : internal_api
attachConfiguration : br-osp
vlan : 20
ipv4 :
allocationEnd : 172.17.0.250
allocationStart : 172.17.0.10
cidr : 172.17.0.0/24
- name : External
nameLower : external
subnets :
- name : external
ipv6 :
allocationEnd : 2001:db8:fd00:1000:ffff:ffff:ffff:fffe
allocationStart : 2001:db8:fd00:1000::10
cidr : 2001:db8:fd00:1000::/64
gateway : 2001:db8:fd00:1000::1
attachConfiguration : br-ex
- name : Storage
nameLower : storage
mtu : 1350
subnets :
- name : storage
ipv4 :
allocationEnd : 172.18.0.250
allocationStart : 172.18.0.10
cidr : 172.18.0.0/24
vlan : 30
attachConfiguration : br-osp
- name : StorageMgmt
nameLower : storage_mgmt
mtu : 1350
subnets :
- name : storage_mgmt
ipv4 :
allocationEnd : 172.19.0.250
allocationStart : 172.19.0.10
cidr : 172.19.0.0/24
vlan : 40
attachConfiguration : br-osp
- name : Tenant
nameLower : tenant
vip : False
mtu : 1350
subnets :
- name : tenant
ipv4 :
allocationEnd : 172.20.0.250
allocationStart : 172.20.0.10
cidr : 172.20.0.0/24
vlan : 50
attachConfiguration : br-ospWenn Sie VLAN für die Netzwerkisolation mit Linux-Bridge verwenden
HINWEIS : Um Jumbo -Frames für eine Brücke zu verwenden, erstellen Sie eine Konfiguration für das Gerät, um die CorRNT -MTU zu konfigurieren:
apiVersion : osp-director.openstack.org/v1beta1
kind : OpenStackNetConfig
metadata :
name : openstacknetconfig
spec :
attachConfigurations :
br-osp :
nodeNetworkConfigurationPolicy :
nodeSelector :
node-role.kubernetes.io/worker : " "
desiredState :
interfaces :
- bridge :
options :
stp :
enabled : false
port :
- name : enp7s0
description : Linux bridge with enp7s0 as a port
name : br-osp
state : up
type : linux-bridge
mtu : 9000
- name : enp7s0
description : Configuring enp7s0 on workers
type : ethernet
state : up
mtu : 9000 Erstellen Sie ConfigMaps, die benutzerdefinierte Wärmeumgebungen, Wärmevorlagen und benutzerdefinierte Rollendatei (Name müssen roles_data.yaml ) definiert werden, die für die Tripleo -Netzwerkkonfiguration verwendet werden. Alle Administrator -Defined -Wärme -Umgebungsdateien können in der configMap bereitgestellt werden und werden in späteren Schritten als Konvention verwendet, um den Wärmestapel für die Bereitstellung von Overcloud zu erstellen. Als Konvention verwendet jede OSP-Direktorinstallation 2 configMaps mit dem Namen heat-env-config und tripleo-tarball-config um diese Informationen bereitzustellen. Das heat-env-config -ConfigMap enthält alle Bereitstellungsumgebungsdateien, in denen jede Datei als -e file.yaml hinzugefügt wird. Yaml zum Befehl openstack stack create . Ein gutes Beispiel ist:
Eine "Tarball-Konfigurationskarte" kann verwendet werden, um (binäre) Tarballs bereitzustellen, die in den Tripleo-Heat-Templates extrahiert werden, wenn Playbooks erzeugt werden. Jeder Tarball sollte ein Verzeichnis von Dateien in Bezug auf das Stammverzeichnis eines THT -Verzeichnisses enthalten. Sie möchten Dinge wie die folgenden Beispiele in einer Konfigurationskarte mit benutzerdefinierten Tarballs speichern:
Netto-Config-Dateien.
Net-Config-Umgebung
HINWEIS : NET-Config-Dateien für die virtuellen Maschinen werden vom Bediener erstellt, können jedoch mit der "Tarball-Konfigurationskarte" überschrieben werden. Um einen vorgezogenen Netto-Konfiguration zu überschreiben, verwenden Sie den Namen <role lowercase>-nic-template.yaml <role lowercase>-nic-template.j2 HINWEIS : Die Netzwerkschnittstellennamen für die vom OpenStackVMSet -Controller erstellten VMs werden alphabetisch von den der VM -Rolle zugewiesenen Netzwerknamen geordnet. Eine Ausnahme ist die default -Netzwerkschnittstelle des VM -Pod, die immer die erste Schnittstelle ist. Der resultierende Abschnitt "Inteface" der Definition der virtuellen Maschine sieht so aus:
interfaces :
- masquerade : {}
model : virtio
name : default
- bridge : {}
model : virtio
name : ctlplane
- bridge : {}
model : virtio
name : external
- bridge : {}
model : virtio
name : internalapi
- bridge : {}
model : virtio
name : storage
- bridge : {}
model : virtio
name : storagemgmt
- bridge : {}
model : virtio
name : tenantDamit ist die CTLPLANE -Schnittstelle NIC2, External NIC3, ... und so weiter.
Hinweis : Der FIP -Verkehr übergeht nicht mit ML2/OVN und DVR an ein VLAN -Mieternetzwerk. DVR ist standardmäßig aktiviert. Wenn Sie VLAN -Mieternetzwerke mit OVN benötigen, können Sie DVR deaktivieren. Um DVR zu deaktivieren, geben Sie die folgenden Zeilen in eine Umgebungsdatei ein:
parameter_defaults :
NeutronEnableDVR : falseDie Unterstützung für "verteiltes VLAN -Verkehr in OVN" wird in den MAC -Adressen verwalten, um "Unterstützung in Tripleo für den verteilten VLAN -Verkehr in OVN hinzufügen" (https://bugs.launchpad.net/tripleo/+bug/1881593)
[Git Repo Config Map] Diese configMap enthält den SSH -Schlüssel und die URL für das GIT -Repo, das zum Speichern erzeugter Playbooks verwendet wird (unten)
Sobald Sie die obige Vorlage/Beispiele für Ihre Umgebung angepasst haben (Ein Verzeichnis für jede Art von Konfiguration):
# create the configmap for heat-env-config
oc create configmap -n openstack heat-env-config --from-file=heat-env-config/ --dry-run=client -o yaml | oc apply -f -
# create the configmap containing a tarball of t-h-t network config files. NOTE: these files may overwrite default t-h-t files so keep this in mind when naming them.
cd < dir with net config files >
tar -cvzf net-config.tar.gz * .yaml
oc create configmap -n openstack tripleo-tarball-config --from-file=tarball-config.tar.gz
# create the Git secret used for the repo where Ansible playbooks are stored
oc create secret generic git-secret -n openstack --from-file=git_ssh_identity= < path to git id_rsa > --from-literal=git_url= < your git server URL (git@...) >
(Optional) Erstellen Sie ein Geheimnis für Ihr OpenStackControlplane. Dieses Geheimnis bietet das Standardkennwort für Ihre virtuellen Maschine und Baremetal -Hosts. Wenn kein Geheimnis bereitgestellt wird, können Sie sich nur mit SSH-Tasten anmelden, die im Geheimnis des OSP-Kontrolplan-SSH-Keys definiert sind.
apiVersion : v1
kind : Secret
metadata :
name : userpassword
namespace : openstack
data :
# 12345678
NodeRootPassword : MTIzNDU2Nzg=Wenn Sie das obige YAML in eine Datei namens ctlplane-secret.yaml schreiben, können Sie das Geheimnis über diesen Befehl erstellen:
oc create -n openstack -f ctlplane-secret.yamlDefinieren Sie Ihre openStackControlplane -benutzerdefinierte Ressource. Die benutzerdefinierte Ressource OpenStackControlplane bietet einen zentralen Ort zum Erstellen und Skalieren von VMs, die für die OSP -Controller sowie zusätzliche VMSets für Ihre Bereitstellung verwendet werden. Für eine grundlegende Demo -Installation ist mindestens 1 Controller VM erforderlich, und pro OSP -Hochverfügbarkeitsrichtlinien 3 Controller VMs werden empfohlen.
HINWEIS : Wenn das RHEL-GUEST-Image als Basis zum Bereitstellen der virtuellen OpenStackControlplane-Maschinen verwendet wird, entfernen Sie das Netz. IWNAMES = 0 Kernel-Parameter aus dem Bild, um die Benennung der BioSdev-Netzwerkschnittstelle zu erhalten. Dies kann wie:
dnf install -y libguestfs-tools-c
virt-customize -a bms-image.qcow2 --run-command ' sed -i -e "s/^(kernelopts=.*)net.ifnames=0 (.*)/12/" /boot/grub2/grubenv ' apiVersion : osp-director.openstack.org/v1beta1
kind : OpenStackControlPlane
metadata :
name : overcloud
namespace : openstack
spec :
openStackClientImageURL : quay.io/openstack-k8s-operators/rhosp16-openstack-tripleoclient:16.2_20210713.1
openStackClientNetworks :
- ctlplane
- external
- internalapi
# openStackClientStorageClass must support RWX
# https://kubernetes.io/docs/concepts/storage/persistent-volumes/#access-modes
openStackClientStorageClass : host-nfs-storageclass
passwordSecret : userpassword
gitSecret : git-secret
virtualMachineRoles :
controller :
roleName : Controller
roleCount : 3
networks :
- ctlplane
- internalapi
- external
- tenant
- storage
- storagemgmt
cores : 6
memory : 12
rootDisk :
diskSize : 50
baseImageVolumeName : openstack-base-img
# storageClass must support RWX to be able to live migrate VMs
storageClass : host-nfs-storageclass
storageAccessMode : ReadWriteMany
# When using OpenShift Virtualization with OpenShift Container Platform Container Storage,
# specify RBD block mode persistent volume claims (PVCs) when creating virtual machine disks. With virtual machine disks,
# RBD block mode volumes are more efficient and provide better performance than Ceph FS or RBD filesystem-mode PVCs.
# To specify RBD block mode PVCs, use the 'ocs-storagecluster-ceph-rbd' storage class and VolumeMode: Block.
storageVolumeMode : Filesystem
# Optional
# DedicatedIOThread - Disks with dedicatedIOThread set to true will be allocated an exclusive thread.
# This is generally useful if a specific Disk is expected to have heavy I/O traffic, e.g. a database spindle.
dedicatedIOThread : false
additionalDisks :
# name must be uniqe and must not be rootDisk
- name : dataDisk1
diskSize : 100
storageClass : host-nfs-storageclass
storageAccessMode : ReadWriteMany
storageVolumeMode : Filesystem
# Optional block storage settings
# IOThreadsPolicy - IO thread policy for the domain. Currently valid policies are shared and auto.
# However, if any disk requests a dedicated IOThread, ioThreadsPolicy will be enabled and default to shared.
# When ioThreadsPolicy is set to auto IOThreads will also be "isolated" from the vCPUs and placed on the same physical CPU as the QEMU emulator thread.
# An ioThreadsPolicy of shared indicates that KubeVirt should use one thread that will be shared by all disk devices.
ioThreadsPolicy : auto
# Block Multi-Queue is a framework for the Linux block layer that maps Device I/O queries to multiple queues.
# This splits I/O processing up across multiple threads, and therefor multiple CPUs. libvirt recommends that the
# number of queues used should match the number of CPUs allocated for optimal performance.
blockMultiQueue : falseWenn Sie das obige YAML in eine Datei namens OpenStackControlplane.yaml schreiben, können Sie über diesen Befehl das OpenStackControlplane erstellen:
oc create -f openstackcontrolplane.yamlHinweis VMs innerhalb derselben VMSET -Rolle (VM -Rolle) werden unter Verwendung einer POD -Anti -Affinitäts -Regel (bevorzugte DuringSchedulingignedDuringExecution) auf die verfügbaren Arbeiterknoten verteilt. Damit ist es immer noch möglich, dass mehrere VMs einer Rolle auf demselben Arbeiterknoten landen, wenn keine anderen Ressourcen verfügbar sind (z. B. Neustart von Worker während des Updates). Es findet keine Auto -Live -Migration statt, wenn nach Wartung/Neustart ein Knoten auftaucht. Bei der nächsten Planungsanfrage wird die VM erneut umgesiedelt.
Definieren Sie einen OpenStackBaremetalset, um die OSP -Berechnung zu skalieren. Die OpenStackBaremetal -Ressource kann verwendet werden, um Rechenressourcen zu definieren und zu skalieren und optional zum Definieren und Skalieren von Baremetal -Hosts für andere Arten von Tripleo -Rollen zu verwenden. Das folgende Beispiel definiert einen einzelnen Berechnungshost, der erstellt werden soll.
HINWEIS : Wenn das RHEL-GUEST-Image als Basis zur Bereitstellung der OpenStackBaremetalset-Rechenknoten verwendet wird, entfernen Sie das Netz. IWNAMES = 0 Kernel-Parameter aus dem Bild, um die Benennung von BioSdev-Netzwerkschnittstellen zu haben. Dies kann wie:
dnf install -y libguestfs-tools-c
virt-customize -a bms-image.qcow2 --run-command ' sed -i -e "s/^(kernelopts=.*)net.ifnames=0 (.*)/12/" /boot/grub2/grubenv ' apiVersion : osp-director.openstack.org/v1beta1
kind : OpenStackBaremetalSet
metadata :
name : compute
namespace : openstack
spec :
# How many nodes to provision
count : 1
# The image to install on the provisioned nodes. NOTE: needs to be accessible on the OpenShift Metal3 provisioning network.
baseImageUrl : http://host/images/rhel-image-8.4.x86_64.qcow2
# NOTE: these are automatically created via the OpenStackControlplane CR above
deploymentSSHSecret : osp-controlplane-ssh-keys
# The interface on the nodes that will be assigned an IP from the mgmtCidr
ctlplaneInterface : enp7s0
# Networks to associate with this host
networks :
- ctlplane
- internalapi
- tenant
- storage
roleName : Compute
passwordSecret : userpasswordWenn Sie das obige YAML in eine Datei namens compute.yaml schreiben, können Sie den OpenStackBaremetalSet über diesen Befehl erstellen:
oc create -f compute.yamlKnotenregistrierung (Registrieren Sie die Überklagesysteme in den erforderlichen Kanälen)
Warten Sie, bis die oben genannte Ressource die Bereitstellung (Berechnung und Steuerung) beendet hat. Sobald die Ressourcen abgeschlossen sind, fahren Sie mit der Notenregistrierung fort.
Verwenden Sie das in 5.9 beschriebene Verfahren. Die manuelle Ausführung von Ansible-basierte Registrierung tun dies.
Hinweis: Wir empfehlen, die manuelle Registrierung zu verwenden, da sie unabhängig von der Auswahl des Basisbildes funktioniert. Wenn Sie Overcloud-Ful als Ihr Basisbereitungsbild verwenden, kann die automatische RHSM-Registrierung über die RHSM.YAML-Umgebungsrolle/-datei als Alternative zu diesem Ansatz verwendet werden.
oc rsh openstackclient
bash
cd /home/cloud-admin
< create the ansible playbook for the overcloud nodes - e.g. rhsm.yaml >
# register the overcloud nodes to required repositories
ansible-playbook -i /home/cloud-admin/ctlplane-ansible-inventory ./rhsm.yaml(Optional) Erstellen Sie die Rollendatei a) Verwenden Sie den OpenStackClient Pod, um eine benutzerdefinierte Rollendatei zu generieren
oc rsh openstackclient
unset OS_CLOUD
cd /home/cloud-admin/
openstack overcloud roles generate Controller ComputeHCI > roles_data.yaml
exitb) Kopieren Sie die benutzerdefinierte Rollendatei aus dem OpenStackClient Pod
oc cp openstackclient:/home/cloud-admin/roles_data.yaml roles_data.yaml Aktualisieren Sie die tarballConfigMap -Konfiguration, um die Datei roles_data.yaml zum Tarball hinzuzufügen, und aktualisieren Sie die configMap.
HINWEIS : Verwenden Sie sicher, dass Sie roles_data.yaml als Dateiname verwenden.
Definieren Sie einen OpenStackConfiggenerator, um Ansible -Playbooks für die OSP -Cluster -Bereitstellung zu generieren.
apiVersion : osp-director.openstack.org/v1beta1
kind : OpenStackConfigGenerator
metadata :
name : default
namespace : openstack
spec :
enableFencing : False
imageURL : quay.io/openstack-k8s-operators/rhosp16-openstack-tripleoclient:16.2_20210713.1
gitSecret : git-secret
heatEnvConfigMap : heat-env-config
tarballConfigMap : tripleo-tarball-config
# (optional) for debugging it is possible to set the interactive mode.
# In this mode the playbooks won't get rendered automatically. Just the environment to start the rendering gets created
# interactive: true
# (optional) provide custom registry or specific container versions via the ephemeralHeatSettings
# ephemeralHeatSettings:
# heatAPIImageURL: quay.io/tripleotraincentos8/centos-binary-heat-api:current-tripleo
# heatEngineImageURL: quay.io/tripleotraincentos8/centos-binary-heat-engine:current-tripleo
# mariadbImageURL: quay.io/tripleotraincentos8/centos-binary-mariadb:current-tripleo
# rabbitImageURL: quay.io/tripleotraincentos8/centos-binary-rabbitmq:current-tripleoWenn Sie das obige YAML in eine Datei namens generator.yaml schreiben, können Sie den OpenStackConfiggenerator über diesen Befehl erstellen:
oc create -f generator.yamlDer oben erstellte Osconfiggenerator generiert automatisch Playbooks, wenn Sie die configMaps für Ihre OSP -Bereitstellung skalieren oder ändern. Das Erzeugen dieser Spielbücher dauert einige Minuten. Sie können den Statuszustand des Osconfiggenerators überwachen, damit er fertig ist.
Erhalten Sie die neueste OsconFigversion (Ansible Playbooks). Wählen Sie den Hash/Digest der neuesten OsconFigversion für die Verwendung im nächsten Schritt aus.
oc get -n openstack --sort-by {.metadata.creationTimestamp} osconfigversions -o jsonHinweis: OsconFigversion -Objekte haben auch ein "Git -Diff" -attribut, mit dem die Änderungen zwischen ansiblen Playbook -Versionen einfach verglichen werden können.
Erstellen Sie einen Osdeploy (führt Ansible Playbooks aus)
apiVersion : osp-director.openstack.org/v1beta1
kind : OpenStackDeploy
metadata :
name : default
spec :
configVersion : n5fch96h548h75hf4hbdhb8hfdh676h57bh96h5c5h59hf4h88h...
configGenerator : defaultWenn Sie das obige YAML in eine Datei namens Deploy.yaml schreiben, können Sie den OpenStackDeploy über diesen Befehl erstellen:
oc create -f deploy.yamlWenn die Bereitstellung ausgeführt wird, wird ein Kubernetes -Job erstellt, um die Ansible -Playbooks auszuführen. Sie können die Protokolle dieses Jobs/Pod verkleinern, um die Ansible -Playbooks zu sehen. Darüber hinaus können Sie manuell auf die ausgeführten Ansible-Playbooks zugreifen, indem Sie sich in den Pod "OpenStackClient" anmelden und in das Verzeichnis/home/cloud-admin/work // gehen. Dort finden Sie die Ansible -Playbooks zusammen mit der Datei Ansible.log für die laufende Bereitstellung.
Es ist möglich, die hyperkonvergierte Infrastruktur von Tripleo einzusetzen, wobei auch Rechenknoten als Ceph OSD-Knoten fungieren. Der Workflow zur Installation von Ceph über Tripleo wäre:
Stellen Sie sicher, dass Sie quay.io/openstack-k8s-operators/rhosp16-openstack-tripleoclient:16.2_20210521.1 oder höher für den OpenStackClient openStackClientImageURL .
Rechenknoten mit zusätzlichen Festplatten als OSDS verwenden und erstellen Sie einen Baremetalset für die computeHCI -Rolle, die zusätzlich zu den Standard -Compute -Netzwerken und dem IsHCI -Parameter auf true eingestuft wird.
HINWEIS : Wenn das RHEL-GUEST-Image als Basis zum Bereitstellen der OpenStackBaremetalset-Rechenknoten verwendet wird, entfernen Sie das Netz. Dies kann wie:
dnf install -y libguestfs-tools-c
virt-customize -a bms-image.qcow2 --run-command ' sed -i -e "s/^(kernelopts=.*)net.ifnames=0 (.*)/12/" /boot/grub2/grubenv ' apiVersion : osp-director.openstack.org/v1beta1
kind : OpenStackBaremetalSet
metadata :
name : computehci
namespace : openstack
spec :
# How many nodes to provision
replicas : 2
# The image to install on the provisioned nodes
baseImageUrl : http://host/images/rhel-image-8.4.x86_64.qcow2
# The secret containing the SSH pub key to place on the provisioned nodes
deploymentSSHSecret : osp-controlplane-ssh-keys
# The interface on the nodes that will be assigned an IP from the mgmtCidr
ctlplaneInterface : enp7s0
# Networks to associate with this host
networks :
- ctlplane
- internalapi
- tenant
- storage
- storagemgmt
roleName : ComputeHCI
passwordSecret : userpassword Deploying OpenStack once you have the OSP Director Operator installed , der die computeHCI -Rolle enthält/usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-ansible.yaml und eine andere Anpassung an die Tripleo Bereitstellung benutzerdefinierter Konfiguration, z. B. storage-backend.yaml : resource_registry :
OS::TripleO::Services::CephMgr : deployment/ceph-ansible/ceph-mgr.yaml
OS::TripleO::Services::CephMon : deployment/ceph-ansible/ceph-mon.yaml
OS::TripleO::Services::CephOSD : deployment/ceph-ansible/ceph-osd.yaml
OS::TripleO::Services::CephClient : deployment/ceph-ansible/ceph-client.yaml
parameter_defaults :
# needed for now because of the repo used to create tripleo-deploy image
CephAnsibleRepo : " rhelosp-ceph-4-tools "
CephAnsiblePlaybookVerbosity : 3
CinderEnableIscsiBackend : false
CinderEnableRbdBackend : true
CinderBackupBackend : ceph
CinderEnableNfsBackend : false
NovaEnableRbdBackend : true
GlanceBackend : rbd
CinderRbdPoolName : " volumes "
NovaRbdPoolName : " vms "
GlanceRbdPoolName : " images "
CephPoolDefaultPgNum : 32
CephPoolDefaultSize : 2
CephAnsibleDisksConfig :
devices :
- ' /dev/sdb '
- ' /dev/sdc '
- ' /dev/sdd '
osd_scenario : lvm
osd_objectstore : bluestore
CephAnsibleExtraConfig :
is_hci : true
CephConfigOverrides :
rgw_swift_enforce_content_length : true
rgw_swift_versioning_enabled : true Sobald Sie die obige Vorlage/Beispiele für Ihre Umgebung angepasst haben, erstellen/aktualisieren Sie Konfigurationen, wie in Deploying OpenStack once you have the OSP Director Operator installed
Deploying OpenStack once you have the OSP Director Operator installed und geben Sie die Rollen -Datei für die generierten Rollen an. HINWEIS : Stellen Sie sicher, dass Sie quay.io/openstack-k8s-operators/rhosp16-openstack-tripleoclient:16.2_20210521.1 oder später für das OsconFiggenerator imageURL .
Warten Sie, bis der OpenStackConfiggenerator den Playbook -Rendering -Job beendet hat.
Erhalten Sie den Hash/Digest der neuesten OpenStackConFigversion.
Erstellen Sie einen OpenStackDeploy für die angegebene OpenStackConFigversion. Dadurch werden die Ansible Playbooks bereitgestellt.
Das Entfernen eines Baremetal -Berechnung Host erfordert die folgenden Schritte:
Wenn ein Rechenknoten entfernt wird
openstack compute service list
openstack compute service set < hostname > nova-compute --disableAnnotation einer BMH -Ressource
oc annotate -n openshift-machine-api bmh/openshift-worker-3 osp-director.openstack.org/delete-host=true --overwrite Der Annotationsstatus wird im Osbaremetalset/OSVMSET unter Verwendung des Parameters annotatedForDeletion widerspiegelt:
oc get osbms computehci -o json | jq .status
{
" baremetalHosts " : {
" computehci-0 " : {
" annotatedForDeletion " : true,
" ctlplaneIP " : " 192.168.25.105/24 " ,
" hostRef " : " openshift-worker-3 " ,
" hostname " : " computehci-0 " ,
" networkDataSecretName " : " computehci-cloudinit-networkdata-openshift-worker-3 " ,
" provisioningState " : " provisioned " ,
" userDataSecretName " : " computehci-cloudinit-userdata-openshift-worker-3 "
},
" computehci-1 " : {
" annotatedForDeletion " : false,
" ctlplaneIP " : " 192.168.25.106/24 " ,
" hostRef " : " openshift-worker-4 " ,
" hostname " : " computehci-1 " ,
" networkDataSecretName " : " computehci-cloudinit-networkdata-openshift-worker-4 " ,
" provisioningState " : " provisioned " ,
" userDataSecretName " : " computehci-cloudinit-userdata-openshift-worker-4 "
}
},
" provisioningStatus " : {
" readyCount " : 2,
" reason " : " All requested BaremetalHosts have been provisioned " ,
" state " : " provisioned "
}
}Durch die Reduzierung der Ressourcenzahl des Osbaremetalsets wird der Corrrensponding -Controller ausgelöst, um die Ressourcenlöschung zu verarbeiten
oc patch osbms computehci --type=merge --patch ' {"spec":{"count":1}} 'Infolge:
oc get osnet ctlplane -o json | jq .status.roleReservations.ComputeHCI
{
" addToPredictableIPs " : true,
" reservations " : [
{
" deleted " : true,
" hostname " : " computehci-0 " ,
" ip " : " 192.168.25.105 " ,
" vip " : false
},
{
" deleted " : false,
" hostname " : " computehci-1 " ,
" ip " : " 192.168.25.106 " ,
" vip " : false
}
]
}Dies führt zum folgenden Verhalten
Wenn ein Rechenknoten entfernt wurde, gibt es mehrere übrig gebliebene Einträge auf der OpenStack -Steuerebene und werden nicht automatisch gereinigt. Um sie aufzuräumen, führen Sie die folgenden Schritte aus.
openstack compute service list
openstack compute service delete < service-id >openstack network agent list
for AGENT in $( openstack network agent list --host < scaled-down-node > -c ID -f value ) ; do openstack network agent delete $AGENT ; done Das Entfernen eines VM erfordert die folgenden Schritte:
Wenn der VM einen OSP -Dienst veranstaltet, der vor der Entfernung deaktiviert werden sollte, tun Sie dies.
Annotation einer VM -Ressource
oc annotate -n openstack vm/controller-1 osp-director.openstack.org/delete-host=true --overwriteReduzierung der Ressourcenrolle der virtuellen Machinerolen im OpenStackControlplane Cr. Der Corrrensponding -Controller zur Behandlung der Ressourcenlöschung
oc patch osctlplane overcloud --type=merge --patch ' {"spec":{"virtualMachineRoles":{"<RoleName>":{"roleCount":2}}}} 'Infolge:
Dies führt zum folgenden Verhalten
Wenn die VM einen OSP -Dienst gehostet hat, der entfernt werden sollte, löschen Sie den Dienst mit dem entsprechenden OpenStack -Befehl.
Es ist möglich, die Routed Networks (Wirbelsäule/Blatt -Networking) von Tripleo bereitzustellen, um Overcloud -Blattnetzwerke zu konfigurieren. Verwenden Sie den Parameter Subnetzes, um die zusätzlichen Blattsubnetze mit einem Basisnetzwerk zu definieren.
Eine Einschränkung ist derzeit, dass es nur ein Vorsorge -Netzwerk für Metal3 geben kann.
Der Workflow für die Installation einer Überschließung mit mehreren Subnetzen wäre:
Definieren Sie Ihre openStackNetConfig -benutzerdefinierte Ressource und geben Sie alle Subnetze für die Overcloud -Netzwerke an. Der Bediener wird das Tripleo Network_Data.yaml für die gebrauchte OSP -Version rendern.
apiVersion : osp-director.openstack.org/v1beta1
kind : OpenStackNetConfig
metadata :
name : openstacknetconfig
spec :
attachConfigurations :
br-osp :
nodeNetworkConfigurationPolicy :
nodeSelector :
node-role.kubernetes.io/worker : " "
desiredState :
interfaces :
- bridge :
options :
stp :
enabled : false
port :
- name : enp7s0
description : Linux bridge with enp7s0 as a port
name : br-osp
state : up
type : linux-bridge
mtu : 1500
br-ex :
nodeNetworkConfigurationPolicy :
nodeSelector :
node-role.kubernetes.io/worker : " "
desiredState :
interfaces :
- bridge :
options :
stp :
enabled : false
port :
- name : enp6s0
description : Linux bridge with enp6s0 as a port
name : br-ex-osp
state : up
type : linux-bridge
mtu : 1500
# optional DnsServers list
dnsServers :
- 192.168.25.1
# optional DnsSearchDomains list
dnsSearchDomains :
- osptest.test.metalkube.org
- some.other.domain
# DomainName of the OSP environment
domainName : osptest.test.metalkube.org
networks :
- name : Control
nameLower : ctlplane
subnets :
- name : ctlplane
ipv4 :
allocationEnd : 192.168.25.250
allocationStart : 192.168.25.100
cidr : 192.168.25.0/24
gateway : 192.168.25.1
attachConfiguration : br-osp
- name : InternalApi
nameLower : internal_api
mtu : 1350
subnets :
- name : internal_api
ipv4 :
allocationEnd : 172.17.0.250
allocationStart : 172.17.0.10
cidr : 172.17.0.0/24
routes :
- destination : 172.17.1.0/24
nexthop : 172.17.0.1
- destination : 172.17.2.0/24
nexthop : 172.17.0.1
vlan : 20
attachConfiguration : br-osp
- name : internal_api_leaf1
ipv4 :
allocationEnd : 172.17.1.250
allocationStart : 172.17.1.10
cidr : 172.17.1.0/24
routes :
- destination : 172.17.0.0/24
nexthop : 172.17.1.1
- destination : 172.17.2.0/24
nexthop : 172.17.1.1
vlan : 21
attachConfiguration : br-osp
- name : internal_api_leaf2
ipv4 :
allocationEnd : 172.17.2.250
allocationStart : 172.17.2.10
cidr : 172.17.2.0/24
routes :
- destination : 172.17.1.0/24
nexthop : 172.17.2.1
- destination : 172.17.0.0/24
nexthop : 172.17.2.1
vlan : 22
attachConfiguration : br-osp
- name : External
nameLower : external
subnets :
- name : external
ipv4 :
allocationEnd : 10.0.0.250
allocationStart : 10.0.0.10
cidr : 10.0.0.0/24
gateway : 10.0.0.1
attachConfiguration : br-ex
- name : Storage
nameLower : storage
mtu : 1350
subnets :
- name : storage
ipv4 :
allocationEnd : 172.18.0.250
allocationStart : 172.18.0.10
cidr : 172.18.0.0/24
routes :
- destination : 172.18.1.0/24
nexthop : 172.18.0.1
- destination : 172.18.2.0/24
nexthop : 172.18.0.1
vlan : 30
attachConfiguration : br-osp
- name : storage_leaf1
ipv4 :
allocationEnd : 172.18.1.250
allocationStart : 172.18.1.10
cidr : 172.18.1.0/24
routes :
- destination : 172.18.0.0/24
nexthop : 172.18.1.1
- destination : 172.18.2.0/24
nexthop : 172.18.1.1
vlan : 31
attachConfiguration : br-osp
- name : storage_leaf2
ipv4 :
allocationEnd : 172.18.2.250
allocationStart : 172.18.2.10
cidr : 172.18.2.0/24
routes :
- destination : 172.18.0.0/24
nexthop : 172.18.2.1
- destination : 172.18.1.0/24
nexthop : 172.18.2.1
vlan : 32
attachConfiguration : br-osp
- name : StorageMgmt
nameLower : storage_mgmt
mtu : 1350
subnets :
- name : storage_mgmt
ipv4 :
allocationEnd : 172.19.0.250
allocationStart : 172.19.0.10
cidr : 172.19.0.0/24
routes :
- destination : 172.19.1.0/24
nexthop : 172.19.0.1
- destination : 172.19.2.0/24
nexthop : 172.19.0.1
vlan : 40
attachConfiguration : br-osp
- name : storage_mgmt_leaf1
ipv4 :
allocationEnd : 172.19.1.250
allocationStart : 172.19.1.10
cidr : 172.19.1.0/24
routes :
- destination : 172.19.0.0/24
nexthop : 172.19.1.1
- destination : 172.19.2.0/24
nexthop : 172.19.1.1
vlan : 41
attachConfiguration : br-osp
- name : storage_mgmt_leaf2
ipv4 :
allocationEnd : 172.19.2.250
allocationStart : 172.19.2.10
cidr : 172.19.2.0/24
routes :
- destination : 172.19.0.0/24
nexthop : 172.19.2.1
- destination : 172.19.1.0/24
nexthop : 172.19.2.1
vlan : 42
attachConfiguration : br-osp
- name : Tenant
nameLower : tenant
vip : False
mtu : 1350
subnets :
- name : tenant
ipv4 :
allocationEnd : 172.20.0.250
allocationStart : 172.20.0.10
cidr : 172.20.0.0/24
routes :
- destination : 172.20.1.0/24
nexthop : 172.20.0.1
- destination : 172.20.2.0/24
nexthop : 172.20.0.1
vlan : 50
attachConfiguration : br-osp
- name : tenant_leaf1
ipv4 :
allocationEnd : 172.20.1.250
allocationStart : 172.20.1.10
cidr : 172.20.1.0/24
routes :
- destination : 172.20.0.0/24
nexthop : 172.20.1.1
- destination : 172.20.2.0/24
nexthop : 172.20.1.1
vlan : 51
attachConfiguration : br-osp
- name : tenant_leaf2
ipv4 :
allocationEnd : 172.20.2.250
allocationStart : 172.20.2.10
cidr : 172.20.2.0/24
routes :
- destination : 172.20.0.0/24
nexthop : 172.20.2.1
- destination : 172.20.1.0/24
nexthop : 172.20.2.1
vlan : 52
attachConfiguration : br-ospWenn Sie das obige YAML in eine Datei namens networkConfig.yaml schreiben, können Sie den OpenStackNetConfig über diesen Befehl erstellen:
oc create -n openstack -f networkconfig.yaml...
# ##############################################################################
# Role: ComputeLeaf1 #
# ##############################################################################
- name : ComputeLeaf1
description : |
Basic ComputeLeaf1 Node role
# Create external Neutron bridge (unset if using ML2/OVS without DVR)
tags :
- external_bridge
networks :
InternalApi :
subnet : internal_api_leaf1
Tenant :
subnet : tenant_leaf1
Storage :
subnet : storage_leaf1
HostnameFormatDefault : ' %stackname%-novacompute-leaf1-%index% '
...
# ##############################################################################
# Role: ComputeLeaf2 #
# ##############################################################################
- name : ComputeLeaf2
description : |
Basic ComputeLeaf1 Node role
# Create external Neutron bridge (unset if using ML2/OVS without DVR)
tags :
- external_bridge
networks :
InternalApi :
subnet : internal_api_leaf2
Tenant :
subnet : tenant_leaf2
Storage :
subnet : storage_leaf2
HostnameFormatDefault : ' %stackname%-novacompute-leaf2-%index% '
... Aktualisieren Sie die tarballConfigMap -Konfiguration, um die Datei roles_data.yaml zum Tarball hinzuzufügen, und aktualisieren Sie die configMap.
HINWEIS : Verwenden Sie sicher, dass Sie roles_data.yaml als Dateiname verwenden.
Die OSP 16.2 Tripleo -NIC -Vorlagen haben den Interfaceroutes -Parameter pro Standardeinstellung enthalten. Der Routes-Parameter, der in Umgebungen/Netzwerk-Umgebung gerendert wird. Yaml, die als Routen bezeichnet werden, werden normalerweise in der Eigenschaft der Neutronen-Netzwerk-Host_routes festgelegt und werden zu dem Parameter Interfaceroutes hinzugefügt. Da es kein Neutron gibt, ist es erforderlich, die Routen {{{network.name}} zur NIC -Vorlage hinzuzufügen und die beiden Listen mitzuschließen:
parameters:
...
{{ $net.Name }}Routes:
default: []
description: >
Routes for the storage network traffic.
JSON route e.g. [{'destination':'10.0.0.0/16', 'nexthop':'10.0.0.1'}]
Unless the default is changed, the parameter is automatically resolved
from the subnet host_routes attribute.
type: json
...
- type: interface
...
routes:
list_concat_unique:
- get_param: {{ $net.Name }}Routes
- get_param: {{ $net.Name }}InterfaceRoutes
Routes-Subnetzinformationen werden automatisch in die Tripleo environments/network-environment.yaml gerendert, die im Skript verwendet wird und die Ansible-Playbooks rendern. Verwenden Sie in den NIC -Vorlagen daher Routes_ <subnet_name>, EG storageroutes_Storage_leaf1, um das richtige Routing auf dem Host festzulegen.
Für die computeleaf1 -Berechnung muss die NIC -Vorlage geändert werden, um diese zu verwenden:
...
StorageRoutes_storage_leaf1 :
default : []
description : >
Routes for the storage network traffic.
JSON route e.g. [{'destination':'10.0.0.0/16', 'nexthop':'10.0.0.1'}]
Unless the default is changed, the parameter is automatically resolved
from the subnet host_routes attribute.
type : json
...
InternalApiRoutes_internal_api_leaf1 :
default : []
description : >
Routes for the internal_api network traffic.
JSON route e.g. [{'destination':'10.0.0.0/16', 'nexthop':'10.0.0.1'}]
Unless the default is changed, the parameter is automatically resolved
from the subnet host_routes attribute.
type : json
...
TenantRoutes_tenant_leaf1 :
default : []
description : >
Routes for the internal_api network traffic.
JSON route e.g. [{'destination':'10.0.0.0/16', 'nexthop':'10.0.0.1'}]
Unless the default is changed, the parameter is automatically resolved
from the subnet host_routes attribute.
type : json
...
get_param : StorageIpSubnet
routes :
list_concat_unique :
- get_param : StorageRoutes_storage_leaf1
- type : vlan
...
get_param : InternalApiIpSubnet
routes :
list_concat_unique :
- get_param : InternalApiRoutes_internal_api_leaf1
...
get_param : TenantIpSubnet
routes :
list_concat_unique :
- get_param : TenantRoutes_tenant_leaf1
- type : ovs_bridge
... Aktualisieren Sie die tarballConfigMap -Konfiguration, um die Datei nic templates roles_data.yaml zum Tarball hinzuzufügen, und aktualisieren Sie die configMap.
HINWEIS : Verwenden Sie sicher, dass Sie roles_data.yaml als Dateiname verwenden.
Bisher wurde nur OSP16.2 mit mehreren Subnetzbereitstellungen getestet und ist mit OSP17.0 Single -Subnetz kompatibel.
TBD
Stellen Sie sicher, dass Sie die neu erstellten NIC -Vorlagen zur Umgebungsdatei zur resource_registry für die neuen Knotenrollen hinzufügen:
resource_registry :
OS::TripleO::Compute::Net::SoftwareConfig : net-config-two-nic-vlan-compute.yaml
OS::TripleO::ComputeLeaf1::Net::SoftwareConfig : net-config-two-nic-vlan-compute_leaf1.yaml
OS::TripleO::ComputeLeaf2::Net::SoftwareConfig : net-config-two-nic-vlan-compute_leaf2.yaml Zu diesem Zeitpunkt können wir die Überwachung vorlegen.
apiVersion : osp-director.openstack.org/v1beta1
kind : OpenStackControlPlane
metadata :
name : overcloud
namespace : openstack
spec :
gitSecret : git-secret
openStackClientImageURL : registry.redhat.io/rhosp-rhel8/openstack-tripleoclient:16.2
openStackClientNetworks :
- ctlplane
- external
- internal_api
- internal_api_leaf1 # optionally the openstackclient can also be connected to subnets
openStackClientStorageClass : host-nfs-storageclass
passwordSecret : userpassword
domainName : ostest.test.metalkube.org
virtualMachineRoles :
Controller :
roleName : Controller
roleCount : 1
networks :
- ctlplane
- internal_api
- external
- tenant
- storage
- storage_mgmt
cores : 6
memory : 20
rootDisk :
diskSize : 40
baseImageVolumeName : controller-base-img
storageClass : host-nfs-storageclass
storageAccessMode : ReadWriteMany
storageVolumeMode : Filesystem apiVersion : osp-director.openstack.org/v1beta1
kind : OpenStackBaremetalSet
metadata :
name : computeleaf1
namespace : openstack
spec :
# How many nodes to provision
count : 1
# The image to install on the provisioned nodes
baseImageUrl : http://192.168.111.1/images/rhel-guest-image-8.4-1168.x86_64.qcow2
provisionServerName : openstack
# The secret containing the SSH pub key to place on the provisioned nodes
deploymentSSHSecret : osp-controlplane-ssh-keys
# The interface on the nodes that will be assigned an IP from the mgmtCidr
ctlplaneInterface : enp7s0
# Networks to associate with this host
networks :
- ctlplane
- internal_api_leaf1
- external
- tenant_leaf1
- storage_leaf1
roleName : ComputeLeaf1
passwordSecret : userpassword apiVersion : osp-director.openstack.org/v1beta1
kind : OpenStackBaremetalSet
metadata :
name : computeleaf2
namespace : openstack
spec :
# How many nodes to provision
count : 1
# The image to install on the provisioned nodes
baseImageUrl : http://192.168.111.1/images/rhel-guest-image-8.4-1168.x86_64.qcow2
provisionServerName : openstack
# The secret containing the SSH pub key to place on the provisioned nodes
deploymentSSHSecret : osp-controlplane-ssh-keys
# The interface on the nodes that will be assigned an IP from the mgmtCidr
ctlplaneInterface : enp7s0
# Networks to associate with this host
networks :
- ctlplane
- internal_api_leaf2
- external
- tenant_leaf2
- storage_leaf2
roleName : ComputeLeaf2
passwordSecret : userpassword Definieren Sie einen OpenStackConfiggenerator, um Ansible -Playbooks für die OSP -Cluster -Bereitstellung zu generieren, wie bei Deploying OpenStack once you have the OSP Director Operator installed und geben Sie die Rollen -Datei für die generierten Rollen an.
Wie bereits im Run the software deployment beschrieben, registrieren Sie die Überverknüpfungsknoten in den erforderlichen Repositorys und führen Sie die Sofware -Bereitstellung in der OpenStackClient Pod aus.
Der OSP-D-Bediener bietet eine API zur Erstellung und Wiederherstellung von Sicherungen seiner aktuellen CR-, ConfigMap- und Secret-Konfigurationen. Diese API besteht aus zwei CRDs:
OpenStackBackupRequestOpenStackBackup Die OpenStackBackupRequest CRD wird verwendet, um die Erstellung oder Wiederherstellung eines Backups zu initiieren, während die OpenStackBackup -CRD verwendet wird, um die CR-, configMap- und geheimen Daten zu speichern, die dem Bediener gehört. Dies ermöglicht mehrere Vorteile:
OpenStackBackup -CR muss der Benutzer jedes Stück der Konfiguration des Bedieners nicht manuell exportieren/importierenOpenStackBackup zu initiieren, erstellen Sie einen OpenStackBackupRequest mit mode der in seiner Spezifikation save soll. Zum Beispiel: apiVersion : osp-director.openstack.org/v1beta1
kind : OpenStackBackupRequest
metadata :
name : openstackbackupsave
namespace : openstack
spec :
mode : save
additionalConfigMaps : []
additionalSecrets : []Spezifische Felder sind wie folgt:
mode: save zeigt an, dass dies eine Anfrage zum Erstellen einer Sicherung ist.additionalConfigMaps und additionalSecrets Listen können verwendet werden, um zusätzliche Konfigurationen und Geheimnisse zu enthalten, von denen der Bediener ansonsten nicht bekannt ist (dh ConfigMaps und Geheimnisse, die manuell für bestimmte Zwecke erstellt haben).OpenStackControlPlane , OpenStackBaremetalSet usw.) im Namespace verbundenen Konfigurationen und Geheimnisse einzubeziehen, ohne dass der Benutzer sie in diese zusätzlichen Listen einbeziehen muss.OpenStackBackupRequest erstellt wurde: oc get -n openstack osbackuprequest openstackbackupsaveSo etwas sollte erscheinen:
NAME OPERATION SOURCE STATUS COMPLETION TIMESTAMP
openstackbackupsave save Quiescing Der Quiescing gibt an, dass der Betreiber auf die Bereitstellung des Zustands aller OSP-D-Betreiber-CRS wartet, um sein "fertiges" Äquivalent zu erreichen. Die dafür erforderliche Zeit variiert je nach Menge des OSP-D-Operator-CRS und dem Zufall ihres aktuellen Bereitstellungszustands. Hinweis: Es ist möglich, dass der Bediener aufgrund von Fehlern und/oder "Warten" -Staaten in vorhandenen CRs niemals vollständig vorhaben. Um zu sehen, welche CRDS/CRS zur Ruhe verhindern, untersuchen Sie die Betreiberprotokolle. Zum Beispiel:
oc logs < OSP-D operator pod > -c manager -f
...
2022-01-11T18:26:15.180Z INFO controllers.OpenStackBackupRequest Quiesce for save for OpenStackBackupRequest openstackbackupsave is waiting for: [OpenStackBaremetalSet: compute, OpenStackControlPlane: overcloud, OpenStackVMSet: controller] Wenn der OpenStackBackupRequest in den Error eingeht, sehen Sie sich den vollständigen Inhalt an, um den aufgetretenen Fehler zu sehen ( oc get -n openstack openstackbackuprequest <name> -o yaml ).
OpenStackBackupRequest durch das Erstellen und Speichern eines OpenStackBackup der aktuellen OSP-D-Operator-Konfiguration geehrt wurde, wird in den Saved Status teilnehmen. Zum Beispiel: oc get -n openstack osbackuprequest
NAME OPERATION SOURCE STATUS COMPLETION TIMESTAMP
openstackbackupsave save Saved 2022-01-11T19:12:58Z Das zugehörige OpenStackBackup wird ebenfalls erstellt. Zum Beispiel:
oc get -n openstack osbackup
NAME AGE
openstackbackupsave-1641928378 6m7sOpenStackBackup zu initiieren, erstellen Sie einen OpenStackBackupRequest mit mode der in seiner Spezifikation restore soll. Zum Beispiel: apiVersion : osp-director.openstack.org/v1beta1
kind : OpenStackBackupRequest
metadata :
name : openstackbackuprestore
namespace : openstack
spec :
mode : restore
restoreSource : openstackbackupsave-1641928378Spezifische Felder sind wie folgt:
mode: restore zeigt an, dass dies eine Anfrage zur Wiederherstellung eines vorhandenen OpenStackBackup ist.restoreSource zeigt an, welche OpenStackBackup wiederhergestellt werden soll. Wenn mode restore wurde, nimmt der OSP-D-Bediener den Inhalt der restoreSource OpenStackBackup an und versucht, sie gegen die vorhandenen CRS, ConfigMaps und Geheimnisse anzuwenden, die derzeit im Namespace vorhanden sind. Daher überschreiben Sie alle vorhandenen OSP-D-Betreiberressourcen im Namespace mit den gleichen Namen wie im OpenStackBackup und erstellen neue Ressourcen für diejenigen, die derzeit nicht im Namespace gefunden werden. Wenn gewünscht, kann mode auf cleanRestore eingestellt werden, um die vorhandenen OSP-D-Betreiberressourcen innerhalb des Namespace vollständig zu löschen, bevor Sie eine Wiederherstellung versuchen, sodass alle Ressourcen innerhalb des OpenStackBackup vollständig neu erstellt werden.
OpenStackBackupRequest erstellt wurde: oc get -n openstack osbackuprequest openstackbackuprestore So etwas scheint anzunehmen, dass alle Ressourcen aus dem OpenStackBackup gegen den Cluster angewendet werden:
NAME OPERATION SOURCE STATUS COMPLETION TIMESTAMP
openstackbackuprestore restore openstackbackupsave-1641928378 Loading Sobald alle Ressourcen geladen wurden, beginnt der Bediener, sich mit dem Versuch zu versöhnen, alle Ressourcen bereitzustellen:
NAME OPERATION SOURCE STATUS COMPLETION TIMESTAMP
openstackbackuprestore restore openstackbackupsave-1641928378 Reconciling Wenn der OpenStackBackupRequest in den Error eingeht, sehen Sie sich den vollständigen Inhalt an, um den aufgetretenen Fehler zu sehen ( oc get -n openstack openstackbackuprequest <name> -o yaml ).
OpenStackBackupRequest durch die vollständige Wiederherstellung des OpenStackBackup ausgezeichnet wurde, wird er in den Restored Zustand eintreten. Zum Beispiel: oc get -n openstack osbackuprequest
NAME OPERATION SOURCE STATUS COMPLETION TIMESTAMP
openstackbackuprestore restore openstackbackupsave-1641928378 Restored 2022-01-12T13:48:57Z Zu diesem Zeitpunkt sollten alle mit dem ausgewählten OpenStackBackup enthaltenen Ressourcen wiederhergestellt und vollständig bereitgestellt werden.
Der OSP -Direktor -Bediener erstellt automatisch eine configMap, nachdem jede OSDeploy -Ressource ausgeführt wird. Diese Konfiguration ist nach dem osdeploy-Ressourcennamen benannt und mit Tripleo-Exports vorangestellt. Zum Beispiel wäre Tripleo-Exports-Default der Name der configMap für die "Standard" Osdeploy-Ressource. Jede Konfiguration enthält 2 YAML -Dateien:
| Dateiname | Beschreibung | Tripleo -Befehlsäquivalent |
|---|---|---|
| ctlplane-export.yaml | Verwendet mit mehreren Stapeln für DCN | Exportieren von Überknüppel |
| ctlplane-export-filtered.yaml | Wird für mehrere Stapel mit Zellen "Controller" -Stacks verwendet | Exportieren von Zellen übertragen |
Verwenden Sie den folgenden Befehl, um die YAML -Dateien aus der Konfiguration zu extrahieren. Nach dem Extrahieren können die YAML -Dateien in Osconfiggenerator -Ressourcen in benutzerdefinierte Wärmeparameter hinzugefügt werden.
oc extract cm/tripleo-exports-defaultHinweis: Der OSP -Direktor -Betreiber generiert noch keine Exporte für Ceph -Stapel.
Bei Bedarf ist es möglich, die CPU/den RAM eines OpenStackVmset zu ändern, das über das OpenStackControlplane konfiguriert ist. Der Workflow ist wie folgt:
ZB den Controller VirtualMachinerol auf 8 Kerne und 22 GB RAM zu ändern:
oc patch -n openstack osctlplane overcloud --type= ' json ' -p= ' [{"op": "add", "path": "/spec/virtualMachineRoles/controller/cores", "value": 8 }] '
oc patch -n openstack osctlplane overcloud --type= ' json ' -p= ' [{"op": "add", "path": "/spec/virtualMachineRoles/controller/memory", "value": 22 }] '
oc get osvmset
NAME CORES RAM DESIRED READY STATUS REASON
controller 8 22 1 1 Provisioned All requested VirtualMachines have been provisionedvirtctl start <VM> zu verwenden, um die VM wieder aufzunehmen. Siehe das OSP -Update -Prozessdokument
