osp director operator
v1.2.3
El operador director de OSP crea un conjunto de definiciones de recursos personalizados además de OpenShift para administrar recursos que normalmente crean la Cloud de Tripleo. Estos CRD se dividen en dos tipos para el aprovisionamiento de hardware y la configuración del software.
El operador director de OSP está instalado y administrado a través del OLM Operator Lifecycle Manager. OLM se instala automáticamente con su instalación de OpenShift. Para obtener la última instantánea del operador de OSP Director, debe crear el catálogo apropiado, el grupo de operadores y la suscripción para impulsar la instalación con OLM:
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 : alphaTenemos un script para automatizar la instalación aquí con OLM para una etiqueta específica: script para automatizar la instalación
Nota : En algún momento en el futuro, podemos integrarnos en OperatorHub para que el operador de director OSP esté disponible automáticamente en las instalaciones de OCP Fuentes de catálogo OLM predeterminadas.
Cree un volumen base de datos RHEL antes de implementar OpenStack. Esto será utilizado por las máquinas virtuales del controlador que se aprovisionan a través de la virtualización de OpenShift. El enfoque para hacer esto es el siguiente:
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 : <cluster ingress VIP> cdi-uploadproxy-openshift-cnv.apps.<cluster name>.<domain name>
virtctl : 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 anterior, elija uno que desee usar de los que se muestran en: oc get storageclass
Defina su recurso personalizado OpenStackNetCig. Se requiere al menos una red para el CTLPLANE. Opcionalmente, puede definir múltiples redes en el CR que se utilizarán con la arquitectura de aislamiento de red de Tripleo. Además de la definición de la red, OpenStackNet incluye información que se utiliza para definir la política de configuración de red utilizada para adjuntar cualquier VM a esta red a través de OpenShift Virtualization. El siguiente es un ejemplo de una simple red IPv4 CTLPLANE que utiliza el puente Linux para su configuración de host.
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:bbSi escribe el YAML anterior en un archivo llamado networkconfig.yaml, puede crear OpenStackNetConfig a través de este comando:
oc create -n openstack -f networkconfig.yamlPara usar el aislamiento de la red utilizando VLAN, agregue la ID de VLAN a la especificación de la definición de red
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-ospCuando se usa VLAN para el aislamiento de la red con el puente de Linux
Nota : Para usar marcos jumbo para un puente, cree una configuración para que el dispositivo configure la MTU Correnct:
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 Cree configMaps que definan cualquier entorno de calor personalizado, plantillas de calor y archivo de roles personalizados (el nombre debe ser roles_data.yaml ) utilizado para la configuración de la red triple. Cualquier archivo de entorno de calor definido por administrador se puede proporcionar en configMap y se utilizará como una convención en pasos posteriores utilizados para crear la pila de calor para la implementación de overcloud. Como convención, cada instalación de Director de OSP utilizará 2 configMaps llamados heat-env-config y tripleo-tarball-config para proporcionar esta información. El heat-env-config configMap contiene todos los archivos de entorno de implementación donde cada archivo se agrega como -e file.yaml al comando openstack stack create . Un buen ejemplo es:
Se puede usar un "mapa de configuración de tarball" para proporcionar tarballas (binarias) que se extraen en los plantillas tripleo-calor cuando se generan libros de jugadas. Cada tarball debe contener un directorio de archivos en relación con la raíz de un directorio THT. Querrá almacenar cosas como los siguientes ejemplos en un mapa de configuración que contiene tarballs personalizados:
Archivos net-config.
Entorno neto-config
Nota : El operador crea los archivos Net-Config para las máquinas virtuales, pero se pueden sobrescribir utilizando el "Mapa de configuración de Tarball". Para sobrescribir un nombre de red de red pre-renderizado, use el nombre de archivo <role lowercase>-nic-template.yaml para OSP16.2 o <role lowercase>-nic-template.j2 para OSP17. Nota : Los nombres de la interfaz de red para las máquinas virtuales creadas por el controlador OpenStackVMSet están ordenados alfabéticamente por los nombres de red asignados al rol de VM. Una excepción es la interfaz de red default del VM Pod, que siempre es la primera interfaz. La sección Inteface resultante de la definición de la máquina virtual se verá así:
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 : tenantCon esto, la interfaz CTLPLANE es NIC2, NIC3 externo, ... y así sucesivamente.
Nota : El tráfico FIP no pasa a una red de inquilinos VLAN con ML2/OVN y DVR. DVR está habilitado de forma predeterminada. Si necesita redes de inquilinos VLAN con OVN, puede deshabilitar DVR. Para deshabilitar DVR, incluya las siguientes líneas en un archivo de entorno:
parameter_defaults :
NeutronEnableDVR : falseEl soporte para "Tráfico VLAN distribuido en OVN" se está rastreando en administrar direcciones MAC para "Agregar soporte en tripleo para el tráfico VLAN distribuido en OVN" (https://bugs.launchpad.net/tripleo/+bug/1881593)
[Mapa de configuración de Repo Git] Este configMap contiene la tecla SSH y la URL para el repositorio de git utilizado para almacenar libros de jugadas generados (a continuación)
Una vez que personalice la plantilla/ejemplos anteriores para su entorno, puede crear configMaps tanto para el 'calor-config' como para el tipo de configuración tripleo-tarball '(tarballs) utilizando estos comandos de ejemplo en los archivos que contienen cada tipo de configuración respectiva (un directorio para cada tipo de configMap):
# 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@...) >
(Opcional) Cree un secreto para su OpenStackControlplane. Este secreto proporcionará la contraseña predeterminada para su máquina virtual y hosts Baremetal. Si no se proporciona ningún secreto, solo podrá iniciar sesión con las teclas SSH definidas en el secreto OSP-Controlplane-SSH-Keys.
apiVersion : v1
kind : Secret
metadata :
name : userpassword
namespace : openstack
data :
# 12345678
NodeRootPassword : MTIzNDU2Nzg=Si escribe el Yaml anterior en un archivo llamado ctlplane-secret.yaml, puede crear el secreto a través de este comando:
oc create -n openstack -f ctlplane-secret.yamlDefina su recurso personalizado OpenStackControlplane. El recurso personalizado OpenStackControlplane proporciona un lugar central para crear y escalar máquinas virtuales utilizadas para los controladores OSP junto con cualquier VMSET adicional para su implementación. Se requiere al menos 1 VM del controlador para una instalación básica de demostración y se recomiendan las directrices de alta disponibilidad de OSP 3 VM del controlador.
Nota : Si la imagen RHEL-Guest-se usa como base para implementar las máquinas virtuales OpenStackControlplane, asegúrese de eliminar el parámetro net.ifnames = 0 del kernel de la imagen para tener el nombre de la interfaz de red BiosDev. Esto se puede hacer como:
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 : falseSi escribe el YAML anterior en un archivo llamado OpenStackControlplane.yaml, puede crear OpenStackControlplane a través de este comando:
oc create -f openstackcontrolplane.yamlTenga en cuenta que las máquinas virtuales dentro del mismo VMSet (rol de VM) se distribuyen en los nodos de trabajadores disponibles utilizando una regla de Affinity POD (preferido degradación de la creación. Con esto, todavía es posible que múltiples máquinas virtuales de un rol terminen en el mismo nodo de trabajadores si no hay otros recursos disponibles (por ejemplo, el reinicio de los trabajadores durante la actualización). No se produce una migración automática en vivo, si aparece un nodo después del mantenimiento/reinicio. En la siguiente solicitud de programación, la VM se reubica nuevamente.
Defina un OpenStackBaremetalSet para escalar los hosts de cómputo OSP. El recurso OpenStackBaremetal se puede utilizar para definir y escalar los recursos de cálculo y opcionalmente se usa para definir y escalar hosts Baremetal para otros tipos de roles triple. El siguiente ejemplo define un solo host de cómputo que se creará.
Nota : Si la imagen RHEL-Guest-se usa como base para implementar los nodos OpenStackBaremetalSet Compute, asegúrese de eliminar el parámetro net.ifnames = 0 del kernel de la imagen para tener el nombre de la interfaz de red Biosdev. Esto se puede hacer como:
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 : userpasswordSi escribe el Yaml anterior en un archivo llamado Compute.yaml, puede crear OpenStackBaremetalSet a través de este comando:
oc create -f compute.yamlRegistro de nodo (registre los sistemas Overcloud en los canales requeridos)
Espere a que el recurso anterior finalice la implementación (Calcule y Controlplane). Una vez que los recursos terminan de implementar continúen con el registro del nodo.
Use el procedimiento como se describe en 5.9. Ejecutar el registro basado en Ansible manualmente lo hace.
Nota: Recomendamos usar el registro manual, ya que funciona independientemente de la elección de la imagen base. Si está utilizando Overcloud-Full como imagen de implementación base, entonces el registro automático de RHSM podría usarse a través del rol/archivo de entorno RHT RHSM.YAML como una alternativa a este enfoque.
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(Opcional) Crear archivo de roles a) Use el pod OpenStackClient para generar un archivo de roles personalizados
oc rsh openstackclient
unset OS_CLOUD
cd /home/cloud-admin/
openstack overcloud roles generate Controller ComputeHCI > roles_data.yaml
exitb) Copie el archivo de roles personalizados fuera de la vaina OpenStackClient
oc cp openstackclient:/home/cloud-admin/roles_data.yaml roles_data.yaml Actualice el tarballConfigMap configMap para agregar el archivo roles_data.yaml al Tarball y actualizar el configMap.
Nota : asegúrese de usar roles_data.yaml como nombre del archivo.
Defina un OpenStackConfigGenerator para generar libros de jugadas Ansible para el despliegue de clúster OSP.
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-tripleoSi escribe el Yaml anterior en un archivo llamado Generator.yaml, puede crear el OpenStackConfigGenerator a través de este comando:
oc create -f generator.yamlEl OsconFigGenerator creado anteriormente generará automáticamente los libros de jugadas cada vez que escala o modifique los configMaps para su implementación OSP. Generar estos libros de jugadas lleva varios minutos. Puede monitorear la condición de estado de OsconFigGenerator para que termine.
Obtenga la última OsConFigversion (Ansible Playbooks). Seleccione el hash/digest de la última OsConfigversion para su uso en el siguiente paso.
oc get -n openstack --sort-by {.metadata.creationTimestamp} osconfigversions -o jsonNota: Los objetos OsConfigversion también tienen un atributo 'Git Diff' que se puede utilizar para comparar fácilmente los cambios entre las versiones de los libros de jugadas Ansibles.
Crear un Osdeploy (ejecuta Ansible Playbooks)
apiVersion : osp-director.openstack.org/v1beta1
kind : OpenStackDeploy
metadata :
name : default
spec :
configVersion : n5fch96h548h75hf4hbdhb8hfdh676h57bh96h5c5h59hf4h88h...
configGenerator : defaultSi escribe el Yaml anterior en un archivo llamado implement.yaml, puede crear OpenStackDePloy a través de este comando:
oc create -f deploy.yamlA medida que se ejecuta la implementación, creará un trabajo de Kubernetes para ejecutar los libros de jugadas Ansible. Puede seguir los registros de este trabajo/pod para ver ejecutar los libros de jugadas Ansible. Además, puede acceder manualmente a los libros de jugadas Ansible ejecutados iniciando sesión en la vaina 'OpenStackClient', entrando en el directorio/Home/Cloud-Admin/Work //. Allí encontrará los libros de jugadas Ansible junto con el archivo ansible.log para la implementación en ejecución.
Es posible implementar la infraestructura hiperconvergente de Tripleo donde los nodos de cálculo también actúan como nodos Ceph OSD. El flujo de trabajo para instalar Ceph a través de Tripleo sería:
Asegúrese de usar quay.io/openstack-k8s-operators/rhosp16-openstack-tripleoclient:16.2_20210521.1 TIPLEOCLIENT:16.2_20210521.1 o posterior para el OpenStackClient openStackClientImageURL .
Tenga nodos de cómputo con discos adicionales que se utilizarán como OSDS y cree un BaremetalSet para el rol de ComputeHCI que tiene la red StorageMgmt además de las redes de cómputo predeterminadas y el parámetro IsHCI establecido en True.
Nota : Si la imagen RHEL-Guest-se usa como base para implementar los nodos OpenStackBaremetalSet Compute, asegúrese de eliminar la red. Esto se puede hacer como:
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 que incluye el rol de ComputeHCI/usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-ansible.yaml y cualquier otra personalización para el desplegador de complejes de tripleo personalizado, por ejemplo, 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 Una vez que personalice la plantilla/ejemplos anteriores para su entorno, cree/actualice ConfigMaps como se explica en Deploying OpenStack once you have the OSP Director Operator installed
Deploying OpenStack once you have the OSP Director Operator installed y especifique el archivo de roles de roles generados. Nota : Asegúrese de usar quay.io/openstack-k8s-operators/rhosp16-openstack-tripleoclient:16.2_20210521.1 TRIPLEOCLIENT:16.2_20210521.1 o posterior para el OsconfigGenerator imageURL .
Espere a que OpenStackConfigGenerator termine el trabajo de renderizado del libro de jugadas.
Obtenga el hash/digestión de la última OpenStackConfigversion.
Cree un OpenStackDePloy para el OpenStackConfigversion especificado. Esto implementará los libros de jugadas Ansible.
Eliminar un host de cómputo Baremetal requiere los siguientes pasos:
En caso de que se elimine un nodo de cálculo, deshabilite el servicio de cómputo en el nodo saliente en el overcloud para evitar que el nodo programe nuevas instancias
openstack compute service list
openstack compute service set < hostname > nova-compute --disableAnotación de un recurso BMH
oc annotate -n openshift-machine-api bmh/openshift-worker-3 osp-director.openstack.org/delete-host=true --overwrite El estado de anotación se refleja en el OsBaremetalSet/OsVMSet utilizando el parámetro annotatedForDeletion :
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 "
}
}Reducir el recuento de recursos del OsBaremetalSet activará el controlador de corrente de corrente para manejar la eliminación de recursos
oc patch osbms computehci --type=merge --patch ' {"spec":{"count":1}} 'Como resultado:
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
}
]
}Esto da como resultado el siguiente comportamiento
En este momento, si se retiró un nodo de cómputo, hay varias entradas restantes Registrd en el plano de control de OpenStack y no se limpian automáticamente. Para limpiarlos, realice los siguientes pasos.
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 Eliminar una VM requiere los siguientes pasos:
Si la VM aloja algún servicio OSP que debe deshabilitarse antes de la eliminación, hágalo.
Anotación de un recurso VM
oc annotate -n openstack vm/controller-1 osp-director.openstack.org/delete-host=true --overwriteReducción del recurso Rolecount de los virtualesMachineroles en OpenStackControlplane CR. El controlador de corrente de corrente para manejar la eliminación de recursos
oc patch osctlplane overcloud --type=merge --patch ' {"spec":{"virtualMachineRoles":{"<RoleName>":{"roleCount":2}}}} 'Como resultado:
Esto da como resultado el siguiente comportamiento
Si la VM organizó cualquier servicio OSP que debe eliminarse, elimine el servicio utilizando el comando OpenStack correspondiente.
Es posible implementar la arquitectura de redes enrutadas de Tripleo (red de redes/hojas) para configurar las redes de hoja overcloud. Use el parámetro de las subredes para definir las subredes de hoja adicionales con una red base.
Una limitación en este momento es que solo puede haber una red de provisiones para Metal3.
El flujo de trabajo para instalar un overcloud usando múltiples subredes sería:
Defina su recurso personalizado OpenStackNetConfig y especifique todas las subredes para las redes Overcloud. El operador representará el triple network_data.yaml para la versión OSP usada.
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-ospSi escribe el YAML anterior en un archivo llamado networkconfig.yaml, puede crear OpenStackNetConfig a través de este comando:
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% '
... Actualice el tarballConfigMap configMap para agregar el archivo roles_data.yaml al Tarball y actualizar el configMap.
Nota : asegúrese de usar roles_data.yaml como nombre del archivo.
Las plantillas OSP 16.2 Tripleo Nic tienen el parámetro Interfaceroutes por valor predeterminado incluido. El parámetro de rutas renderizado en entornos/red-ambiente.yaml que se nombra rutas generalmente se establecen en la propiedad de la red de neutrones host_routes y se agregan al parámetro de interfaceroutas de roles. Dado que no hay neutrón, se requiere agregar las rutas {{network.name}} a la plantilla NIC donde sea necesario y concat la concatora de las dos listas:
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
La información de la subred de rutas se renderiza automáticamente a los environments/network-environment.yaml que se utiliza en el script que representa los libros de jugadas Ansible. Por lo tanto, en las plantillas de NIC use Routes_ <Subnet_Name>, por ejemplo, Storageroutes_Storage_Leaf1 para establecer el enrutamiento correcto en el host.
Para un rol de cálculo de CompuTeleaf1, la plantilla NIC debe modificarse para usarlas:
...
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
... Actualice el tarballConfigMap configMap para agregar el archivo NIC Templates roles_data.yaml al Tarball y actualizar el configMap.
Nota : asegúrese de usar roles_data.yaml como nombre del archivo.
Hasta ahora, solo OSP16.2 se probó con múltiples implementación de la subred y es compatible con la subred OSP17.0 única.
TBD
Asegúrese de agregar las nuevas plantillas de NIC creadas al archivo de entorno al resource_registry para los nuevos roles de nodo:
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 En este punto, podemos aprovisionar el overcloud.
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 Defina un OpenStackConfigGenerator para generar libros de jugadas Ansible para la implementación del clúster OSP como en Deploying OpenStack once you have the OSP Director Operator installed y especifique el archivo de roles de roles generados.
Como se describió anteriormente en Run the software deployment , aplique, registre los nodos Overcloud a los repositorios requeridos y ejecute la implementación de software desde el interior del PodstackClient Pod.
OSP-D Operator proporciona una API para crear y restaurar copias de seguridad de su CR actual, config y configuraciones secretas. Esta API consta de dos CRD:
OpenStackBackupRequestOpenStackBackup OpenStackBackupRequest CRD se utiliza para iniciar la creación o restauración de una copia de seguridad, mientras que el OpenStackBackup CRD se utiliza para almacenar realmente los datos SECCRESS y Secret que pertenecen al operador. Esto permite varios beneficios:
OpenStackBackup CR, el usuario no tiene que exportar/importar manualmente cada pieza de la configuración del operadorOpenStackBackup , cree una OpenStackBackupRequest con mode configurado para save en su especificación. Por ejemplo: apiVersion : osp-director.openstack.org/v1beta1
kind : OpenStackBackupRequest
metadata :
name : openstackbackupsave
namespace : openstack
spec :
mode : save
additionalConfigMaps : []
additionalSecrets : []Los campos de especificaciones son los siguientes:
mode: save indica que esta es una solicitud para crear una copia de seguridad.additionalSecrets additionalConfigMaps y Se pueden usar para incluir mapas y secretos complementarios de configuración suplementarios de los cuales el operador no es consciente (es decir, configMaps y secretos creados manualmente para ciertos fines).OpenStackControlPlane , OpenStackBaremetalSet , etc.) en el espacio de nombres, sin requerir que el usuario los incluya en estas listas adicionales.OpenStackBackupRequest , monitoree su estado: oc get -n openstack osbackuprequest openstackbackupsaveAlgo como esto debería aparecer:
NAME OPERATION SOURCE STATUS COMPLETION TIMESTAMP
openstackbackupsave save Quiescing El estado Quiescing indica que el operador está esperando el estado de aprovisionamiento de todos los CR del operador OSP-D para alcanzar su equivalente "terminado". El tiempo requerido para esto variará según la cantidad de CRS OSP-D Operator y la casualidad de su estado de aprovisionamiento actual. Nota: Es posible que el operador nunca se fije por completo debido a errores y/o estados de "espera" en CRS existentes. Para ver qué CRDS/CRS están evitando la quiesencia, investigue los registros del operador. Por ejemplo:
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] Si OpenStackBackupRequest ingresa al estado Error , mire su contenido completo para ver el error que se encontró ( oc get -n openstack openstackbackuprequest <name> -o yaml ).
OpenStackBackupRequest se ha honrado creando y guardando un OpenStackBackup que representa la configuración actual del operador OSP-D, ingresará al estado Saved . Por ejemplo: oc get -n openstack osbackuprequest
NAME OPERATION SOURCE STATUS COMPLETION TIMESTAMP
openstackbackupsave save Saved 2022-01-11T19:12:58Z El OpenStackBackup asociado también se habrá creado. Por ejemplo:
oc get -n openstack osbackup
NAME AGE
openstackbackupsave-1641928378 6m7sOpenStackBackup , cree una OpenStackBackupRequest con mode configurado para restore en su especificación. Por ejemplo: apiVersion : osp-director.openstack.org/v1beta1
kind : OpenStackBackupRequest
metadata :
name : openstackbackuprestore
namespace : openstack
spec :
mode : restore
restoreSource : openstackbackupsave-1641928378Los campos de especificaciones son los siguientes:
mode: restore indica que esta es una solicitud para restaurar un OpenStackBackup existente.restoreSource indica qué OpenStackBackup debe restaurarse. Con mode configurado para restore , el operador OSP-D tomará el contenido del restoreSource OpenStackBackup e intentará aplicarlos contra los CRS, ConfigMaps y los secretos existentes actualmente presentes dentro del espacio de nombres. Por lo tanto, sobrescribirá los recursos existentes del operador OSP-D en el espacio de nombres con los mismos nombres que los de OpenStackBackup , y creará nuevos recursos para aquellos que actualmente no se encuentran en el espacio de nombres. Si lo desea, mode se puede configurar en cleanRestore para borrar completamente los recursos del operador OSP-D existentes dentro del espacio de nombres antes de intentar una restauración, de modo que todos los recursos dentro de OpenStackBackup se creen completamente de nuevo.
OpenStackBackupRequest , monitoree su estado: oc get -n openstack osbackuprequest openstackbackuprestore Algo como esto debería parecer indicar que todos los recursos de OpenStackBackup se están aplicando contra el clúster:
NAME OPERATION SOURCE STATUS COMPLETION TIMESTAMP
openstackbackuprestore restore openstackbackupsave-1641928378 Loading Luego, una vez que se hayan cargado todos los recursos, el operador comenzará a reconciliarse para intentar aprovisionar todos los recursos:
NAME OPERATION SOURCE STATUS COMPLETION TIMESTAMP
openstackbackuprestore restore openstackbackupsave-1641928378 Reconciling Si OpenStackBackupRequest ingresa al estado Error , mire su contenido completo para ver el error que se encontró ( oc get -n openstack openstackbackuprequest <name> -o yaml ).
OpenStackBackupRequest ha sido honrado al restaurar completamente el OpenStackBackup , ingresará al estado Restored . Por ejemplo: oc get -n openstack osbackuprequest
NAME OPERATION SOURCE STATUS COMPLETION TIMESTAMP
openstackbackuprestore restore openstackbackupsave-1641928378 Restored 2022-01-12T13:48:57Z En este punto, todos los recursos contenidos con el OpenStackBackup elegido deben restaurarse y aprovisionarse por completo.
El operador del director OSP crea automáticamente un CONFIGMAP después de que cada recurso OSDeploy finalice la ejecución. Este configMap lleva el nombre del nombre del recurso de Osdeploy y prefijado con triple-exports-. Por ejemplo, Tripleo-Exports-Default sería el nombre de configMap para el recurso Osdeploy 'predeterminado'. Cada configMap contiene 2 archivos YAML:
| Nombre del archivo | Descripción | COMANDO DE COMANDO TRIPLEO Equivalente |
|---|---|---|
| ctlplane-export.yaml | Usado con múltiples pilas para DCN | exportación de overcloud |
| ctlplane-export-filtered.yaml | Se utiliza para múltiples pilas con pilas de "controlador" de celda | exportación de células overcloud |
Use el comando a continuación para extraer los archivos YAML de configMap. Una vez extraídos, los archivos YAML se pueden agregar a parámetros de calor personalizados en los recursos OsconFigGenerator.
oc extract cm/tripleo-exports-defaultNota: El operador director de OSP aún no genera exportaciones para las pilas CEPH.
Si es necesario, es posible cambiar la CPU/RAM de un OpenStackVMset configurado a través de OpenStackControlplane. El flujo de trabajo es el siguiente:
Por ejemplo, para cambiar el controlador virtualMachinerole para tener 8 núcleos y 22 GB de RAM:
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> para encender la VM. Consulte el documento del proceso de actualización de OSP
