osp director operator
v1.2.3
O operador do Diretor OSP cria um conjunto de definições de recursos personalizadas sobre o OpenShift para gerenciar recursos normalmente criados pelo Undercloud do Tripleo. Esses CRDs são divididos em dois tipos para provisionamento de hardware e configuração de software.
O operador do Diretor OSP é instalado e gerenciado pelo gerenciador de ciclo de vida do operador OLM. O OLM é instalado automaticamente com sua instalação OpenShift. Para obter o mais recente instantâneo do operador de diretor OSP, é necessário criar o CatalogSource, o OperatorGroup e a assinatura apropriados para dirigir a instalação com o 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 : alphaTemos um script para automatizar a instalação aqui com OLM para uma tag específica: Script para automatizar a instalação
NOTA : Em algum momento do futuro, podemos integrar -se ao OperatorHub para que o Operador do Diretor OSP esteja disponível automaticamente nas instalações do OCP, as fontes de catálogo OLM padrão.
Crie um volume base de dados RHEL antes de implantar o OpenStack. Isso será usado pelas VMs do controlador que são provisionadas por virtualização do OpenShift. A abordagem para fazer isso é a seguinte:
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 acima, escolha um que você deseja usar daqueles mostrados em: oc get storageclass
Defina seu recurso personalizado OpenStackNetConfig. Pelo menos uma rede é necessária para o CTLPlane. Opcionalmente, você pode definir várias redes no CR a ser usado com a arquitetura de isolamento de rede da Trileo. Além da definição da rede, o OpenStackNet inclui informações usadas para definir a política de configuração de rede usada para anexar qualquer VM à essa rede por meio da virtualização do OpenShift. A seguir, é apresentado um exemplo de uma rede simples de CTLPlane IPv4 que usa o Linux Bridge para sua configuração 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:bbSe você escrever o YAML acima em um arquivo chamado NetworkConfig.yaml, poderá criar o OpenStackNetConfig por meio deste comando:
oc create -n openstack -f networkconfig.yamlPara usar o isolamento da rede usando a VLAN, adicione o ID da VLAN à especificação da definição de rede
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-ospAo usar a VLAN para isolamento de rede com Linux-Bridge
NOTA : Para usar os quadros Jumbo para uma ponte, crie uma configuração para o dispositivo configurar o Correnct MTU:
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 Crie ConfigMaps que definem quaisquer ambientes de calor personalizados, modelos de calor e arquivo de funções personalizadas (o nome deve ser roles_data.yaml ) usado para a configuração da rede Triboo. Qualquer arquivos de ambiente de calor definido pelo Adminstrator podem ser fornecidos no ConfigMap e serão usados como uma convenção em etapas posteriores usadas para criar a pilha de calor para implantação de overcloud. Como uma convenção, cada instalação do Diretor OSP usará 2 ConfigMaps denominada heat-env-config e tripleo-tarball-config para fornecer essas informações. O ConfigMap heat-env-config contém todos os arquivos de ambiente de implantação em que cada arquivo é adicionado como -e file.yaml ao comando openstack stack create . Um bom exemplo é:
Um "mapa de configuração de tarball" pode ser usado para fornecer tarballs (binários) que são extraídos nos templos triplos de calor quando os manuais são gerados. Cada tarball deve conter um diretório de arquivos em relação à raiz de um diretório THT. Você deseja armazenar coisas como os seguintes exemplos em um mapa de configuração contendo tarballs personalizados:
Arquivos Net-Config.
Ambiente de Configuração NET
NOTA : Os arquivos Net-Config para as máquinas virtuais são criados pelo operador, mas podem ser substituídos usando o "mapa de configuração de tarball". Para substituir, uma configuração de rede pré-renderizada, use o nome do arquivo <role lowercase>-nic-template.yaml para osp16.2 ou <role lowercase>-nic-template.j2 para osp17. Nota : Os nomes da interface de rede para as VMs criados pelo controlador OpenStackvmset são ordenados em ordem alfabética pelos nomes de rede atribuídos à função VM. Uma exceção é a interface de rede default do POD da VM, que sempre será a primeira interface. A seção de inteface resultante da definição da máquina virtual ficará assim:
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 : tenantCom isso, a interface CTLPlane é NIC2, NIC3 externa, ... e assim por diante.
Nota : O tráfego FIP não passa para uma rede de inquilinos da VLAN com ML2/OVN e DVR. O DVR é ativado por padrão. Se você precisar de redes de inquilinos da VLAN com o OVN, poderá desativar o DVR. Para desativar o DVR, inclua as seguintes linhas em um arquivo de ambiente:
parameter_defaults :
NeutronEnableDVR : falseO suporte ao "tráfego de VLAN distribuído no OVN" está sendo rastreado no gerenciamento de endereços MAC para "Adicionar suporte no Tripleo para o tráfego de VLAN distribuído em OVN" (https://bugs.launchpad.net/tripleo/+bug/1881593)
[Mapa de configuração do Git Repo] Este configmap contém a chave SSH e o URL para o repo Git usado para armazenar manuais gerados (abaixo)
Depois de personalizar o modelo/exemplos acima para o seu ambiente, você pode criar o ConfigMaps para o 'Heat-env-config' e 'Tripleo-Tarball-Config' (Tarballs) ConfigMaps usando esses comandos de exemplo nos arquivos que contêm cada respectivo tipo configmap tipo (um diretório para cada tipo de configuração):
# 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) Crie um segredo para o seu OpenStackControlplane. Este segredo fornecerá a senha padrão para sua máquina virtual e hosts Baremetal. Se nenhum segredo for fornecido, você só poderá fazer o login com as teclas SSH definidas no segredo do controle OSP-SSH-KEYS.
apiVersion : v1
kind : Secret
metadata :
name : userpassword
namespace : openstack
data :
# 12345678
NodeRootPassword : MTIzNDU2Nzg=Se você escrever o YAML acima em um arquivo chamado ctlplane-secret.yaml, poderá criar o segredo através deste comando:
oc create -n openstack -f ctlplane-secret.yamlDefina seu recurso personalizado OpenStackControlplane. O recurso personalizado OpenStackControlplane fornece um local central para criar e escalar VMs usados para os controladores OSP, juntamente com qualquer VMSSets adicionais para sua implantação. Pelo menos 1 VM do controlador é necessário para uma instalação de demonstração básica e as Diretrizes de alta disponibilidade de OSP são recomendadas.
Nota : Se a imagem RHEL-GUEST for usada como base para implantar as máquinas virtuais do OpenStackControlplane, remova o parâmetro net.ifNames = 0 kernel da imagem para ter a nomeação da interface da rede BioSDEV. Isso pode ser feito 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 : falseSe você escrever o YAML acima em um arquivo chamado OpenStackControlPlane.yaml, poderá criar o OpenStackControlplane através deste comando:
oc create -f openstackcontrolplane.yamlObserve as VMs dentro do mesmo VMSET (função da VM) são distribuídas em todos os nós do trabalhador disponível usando uma regra anti -afinidade de POD (preferidaDuringsChedulingIngoredDuringExecution). Com isso, ainda é possível que várias VMs de uma função acabem no mesmo nó do trabalhador se não houver outros recursos disponíveis (por exemplo, reinicialização do trabalhador durante a atualização). Não há migração ao vivo automática, se, por exemplo, um nó aparecer após a manutenção/reinicialização. Na próxima solicitação de agendamento, a VM é realocada novamente.
Defina um OpenStackBaremetalSet para ampliar os hosts de computação OSP. O recurso OpenStackBaremetal pode ser usado para definir e escalar recursos de computação e, opcionalmente, ser usado para definir e dimensionar os hosts Baremetal para outros tipos de funções triplo. O exemplo abaixo define um único host de computação a ser criado.
NOTA : Se a imagem RHEL-GUEST for usada como base para implantar os nós de computação OpenStackBaremetalSet, remova o parâmetro Net.IFNames = 0 Kernel da imagem para ter a nomeação da interface da rede BIOSDEV. Isso pode ser feito 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 : userpasswordSe você escrever o YAML acima em um arquivo chamado compute.yaml, poderá criar o OpenStackBaremetalset através deste comando:
oc create -f compute.yamlRegistro de nós (registre os sistemas em overcloud nos canais necessários)
Aguarde o recurso acima concluir a implantação (computação e controle de controle). Depois que os recursos terminarem a implantação, prossiga com o registro do nó.
Use o procedimento conforme descrito em 5.9. A execução do registro baseado em Ansible faz isso manualmente.
Nota: Recomendamos o uso de registro manual, pois funciona, independentemente da escolha da imagem base. Se você estiver usando o Overcloud-Full como sua imagem de implantação básica, o registro automático de RHSM poderá ser usado através da função/arquivo do ambiente RHSM.YAML como uma alternativa a essa abordagem.
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) Crie Arquivo de Funções A) Use o POD OpenStackClient para gerar um arquivo de funções personalizadas
oc rsh openstackclient
unset OS_CLOUD
cd /home/cloud-admin/
openstack overcloud roles generate Controller ComputeHCI > roles_data.yaml
exitb) Copie o arquivo de funções personalizadas da cápsula do OpenStackClient
oc cp openstackclient:/home/cloud-admin/roles_data.yaml roles_data.yaml Atualize o configmap tarballConfigMap para adicionar o arquivo roles_data.yaml ao Tarball e atualizar o ConfigMap.
Nota : Certifique -se de usar roles_data.yaml como o nome do arquivo.
Defina um OpenStackConfiggenerator para gerar manuais de Ansible para a implantação do cluster 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-tripleoSe você escrever o YAML acima em um arquivo chamado generator.yaml, poderá criar o OpenStackConfiggenerator por meio deste comando:
oc create -f generator.yamlO OSCONFIGGERATER CRIADO ACIMAGEM gerará automaticamente os playbooks sempre que você escalar ou modificar o ConfigMaps para sua implantação do OSP. A geração desses manuais leva vários minutos. Você pode monitorar a condição de status do Osconfiggenerator para terminar.
Obtenha o mais recente Osconfigversion (Ansible Playbooks). Selecione o hash/resumo do mais recente OsconfigVersion para uso na próxima etapa.
oc get -n openstack --sort-by {.metadata.creationTimestamp} osconfigversions -o jsonNOTA: Os objetos Osconfigversion também possuem um atributo 'git diff' que pode ser usado para comparar facilmente as alterações entre as versões do Playbook Ansible.
Crie um Osdeploy (executa os manuais Ansible)
apiVersion : osp-director.openstack.org/v1beta1
kind : OpenStackDeploy
metadata :
name : default
spec :
configVersion : n5fch96h548h75hf4hbdhb8hfdh676h57bh96h5c5h59hf4h88h...
configGenerator : defaultSe você escrever o YAML acima em um arquivo chamado Implement.yaml, poderá criar o OpenStackDeploy através deste comando:
oc create -f deploy.yamlÀ medida que a implantação é executada, ele criará um trabalho de Kubernetes para executar os manuais de Ansible. Você pode encaixar os registros deste trabalho/pod para assistir aos Playbooks Ansible. Além disso, você pode acessar manualmente os manuais Ansible executados, fazendo login no pod 'OpenStackClient', entrando no diretório/home/nuvem-admin/work //. Lá você encontrará os Playbooks Ansible junto com o arquivo Ansible.log para a implantação em execução.
É possível implantar a infraestrutura hiperconvergente da Tripleo, onde os nós de computação também atuam como nós CEPH OSD. O fluxo de trabalho para instalar o CEPH via Trileo seria:
Certifique-se de usar quay.io/openstack-k8s-operators/rhosp16-openstack-tripleoclient:16.2_20210521.1 ou posterior para o OpenStackClient openStackClientImageURL .
Tenha nós de computação com discos extras a serem usados como OSDs e crie um Baremetalset para a função ComputeHci, que possui a rede STORAGEMGMT, além das redes de computação padrão e do parâmetro IsHCI definido como true.
NOTA : Se a imagem RHEL-GUEST for usada como base para implantar os nós de computação OpenStackBaremetalSet, remova o Net.IFNames = 0 Parâmetro do kernel da imagem para ter a nomeação da interface da rede BioSDEV. Isso pode ser feito 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 inclui a função ComputeHci/usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-ansible.yaml e qualquer outra personalização para o TriLeo implante configmap personalizado, por exemplo 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 Depois de personalizar o modelo/exemplos acima para o seu ambiente, crie/atualize configurações como explicadas na Deploying OpenStack once you have the OSP Director Operator installed
Deploying OpenStack once you have the OSP Director Operator installed e especificar o arquivo de funções geradas por funções. NOTA : Certifique-se de usar quay.io/openstack-k8s-operators/rhosp16-openstack-tripleoclient:16.2_20210521.1 ou posterior para o Osconfiggenerator imageURL .
Aguarde o OpenStackConfiggenerator concluir o trabalho de renderização do manual.
Obtenha o hash/digestão do mais recente OpenStackConfigVersion.
Crie um OpenStackDeploy para o OpenStackConfigversion especificado. Isso implantará os manuais de Ansible.
A remoção de um host de computação Baremetal requer as seguintes etapas:
Caso um nó de computação seja removido, desative o serviço de computação no nó de saída no overcloud para impedir que o nó agenda novas instâncias
openstack compute service list
openstack compute service set < hostname > nova-compute --disableAnotação de um recurso BMH
oc annotate -n openshift-machine-api bmh/openshift-worker-3 osp-director.openstack.org/delete-host=true --overwrite O status da anotação está sendo refletido no Osbaremetalset/OSVMSET usando o 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 "
}
}Reduzir a contagem de recursos do Osbaremetalset desencadeará o controlador correns que lida com a deleção 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
}
]
}Isso resulta no seguinte comportamento
No momento, se um nó de computação foi removido, existem várias entradas restantes no plano de controle do OpenStack e não sendo limpa automaticamente. Para limpá -los, execute as etapas a seguir.
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 A remoção de uma VM requer as seguintes etapas:
Se a VM hospedar qualquer serviço OSP que deve ser desativado antes da remoção, faça -o.
Anotação de um recurso VM
oc annotate -n openstack vm/controller-1 osp-director.openstack.org/delete-host=true --overwriteReduzindo o recurso Rolecount dos VirtualMachineroles no OpenStackControlplane Cr. O controlador correns para lidar com a exclusão de recursos
oc patch osctlplane overcloud --type=merge --patch ' {"spec":{"virtualMachineRoles":{"<RoleName>":{"roleCount":2}}}} 'Como resultado:
Isso resulta no seguinte comportamento
Se a VM hospedou algum serviço OSP que deve ser removido, exclua o serviço usando o comando OpenStack correspondente.
É possível implantar a arquitetura de redes roteadas da Tripleo (rede de lesões/folhas) para configurar redes de folhas de overcloud. Use o parâmetro de sub -redes para definir as sub -redes de folhas adicionais com uma rede base.
Uma limitação agora é que só pode haver uma rede de provisões para o Metal3.
O fluxo de trabalho para instalar um overcloud usando várias sub -redes seria:
Defina seu recurso personalizado OpenStackNetConfig e especifique todas as sub -redes para as redes overcloud. O operador renderizará o Tripleo Network_Data.yaml para a versão 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-ospSe você escrever o YAML acima em um arquivo chamado NetworkConfig.yaml, poderá criar o OpenStackNetConfig por meio deste 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% '
... Atualize o configmap tarballConfigMap para adicionar o arquivo roles_data.yaml ao Tarball e atualizar o ConfigMap.
Nota : Certifique -se de usar roles_data.yaml como o nome do arquivo.
Os modelos OSP 16.2 TriLEO NIC possuem o parâmetro interfaceroutes por padrão incluído. O parâmetro de rotas renderizado em ambientes/rede-ambiente.yaml, que são nomeados, as rotas geralmente são definidas na propriedade Neutrons Network Host_routes e são adicionadas ao parâmetro de função interfaceroutes. Como não há nêutrons, é necessário adicionar as rotas {{Network.name}} ao modelo NIC, onde necessário e concatar as duas 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
As informações de sub-rede de rotas são renderizadas automaticamente para os environments/network-environment.yaml , que é usado no script que renderiza os manuais de Ansible. Nos modelos da NIC, portanto, use rotas_ <SubNet_Name>, por exemplo, storageroutes_storage_leaf1 para definir a roteamento correto no host.
Para a função ComputEleaf1 de computação, o modelo NIC precisa ser modificado para usá -los:
...
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
... Atualize o configmap tarballConfigMap para adicionar o arquivo NIC Modelos roles_data.yaml ao Tarball e atualizar o ConfigMap.
Nota : Certifique -se de usar roles_data.yaml como o nome do arquivo.
Até o momento, apenas OSP16.2 foi testado com implantação de sub -redes múltiplos e é compatível com a sub -rede única OSP17.0.
TBD
Certifique -se de adicionar os novos modelos de NIC criados ao arquivo de ambiente ao resource_registry para as novas funções de nó:
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 Neste ponto, podemos provisionar o 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 um OpenStackConfiggenerator para gerar manuais de Ansible para a implantação do cluster OSP como na Deploying OpenStack once you have the OSP Director Operator installed e especificar o arquivo de funções geradas por funções.
Conforme descrito anteriormente, Run the software deployment , aplique, registre os nós do overcloud nos repositórios necessários e execute a implantação do software de dentro do OpenStackClient Pod.
O operador OSP-D fornece uma API para criar e restaurar backups de suas configurações atuais de CR, configuração de configurações e secreções. Esta API consiste em dois CRDs:
OpenStackBackupRequestOpenStackBackup O OpenStackBackupRequest CRD é usado para iniciar a criação ou restauração de um backup, enquanto o CRD OpenStackBackup é usado para realmente armazenar o CR, o ConfigMap e os dados secretos que pertencem ao operador. Isso permite vários benefícios:
OpenStackBackup CR, o usuário não precisa exportar/importar manualmente cada parte da configuração do operadorOpenStackBackup , crie um OpenStackBackupRequest com mode para save em suas especificações. Por exemplo: apiVersion : osp-director.openstack.org/v1beta1
kind : OpenStackBackupRequest
metadata :
name : openstackbackupsave
namespace : openstack
spec :
mode : save
additionalConfigMaps : []
additionalSecrets : []Os campos de especificações são os seguintes:
mode: save indica que esta é uma solicitação para criar um backup.additionalConfigMaps e additionalSecrets podem ser usados para incluir configurações e segredos suplementares, dos quais o operador não tem conhecimento (ou seja, os configurações e segredos criados manualmente para determinados fins).OpenStackControlPlane , OpenStackBaremetalSet , etc) no espaço de nome, sem exigir que o usuário os inclua nessas listas adicionais.OpenStackBackupRequest for criado, monitore seu status: oc get -n openstack osbackuprequest openstackbackupsaveAlgo assim deve aparecer:
NAME OPERATION SOURCE STATUS COMPLETION TIMESTAMP
openstackbackupsave save Quiescing O estado Quiescing indica que o operador está aguardando o estado de provisionamento de todos os CRs da operadora OSP-D para atingir seu equivalente "acabado". O tempo necessário para isso varia de acordo com a quantidade de CRs do operador OSP-D e no acaso de seu estado de provisionamento atual. NOTA: É possível que o operador nunca a quieta completamente devido a erros e/ou estados "esperando" nos CRs existentes. Para ver quais CRDs/CRs estão impedindo a quiese, investigue os logs do operador. Por exemplo:
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] Se o OpenStackBackupRequest entrar no estado Error , consulte seu conteúdo completo para ver o erro que foi encontrado ( oc get -n openstack openstackbackuprequest <name> -o yaml ).
OpenStackBackupRequest for homenageado criando e salvando um OpenStackBackup representando a atual configuração do operador OSP-D, ele entrará no estado Saved . Por exemplo: oc get -n openstack osbackuprequest
NAME OPERATION SOURCE STATUS COMPLETION TIMESTAMP
openstackbackupsave save Saved 2022-01-11T19:12:58Z O Associated OpenStackBackup também terá sido criado. Por exemplo:
oc get -n openstack osbackup
NAME AGE
openstackbackupsave-1641928378 6m7sOpenStackBackup , crie um OpenStackBackupRequest com mode definido para restore em suas especificações. Por exemplo: apiVersion : osp-director.openstack.org/v1beta1
kind : OpenStackBackupRequest
metadata :
name : openstackbackuprestore
namespace : openstack
spec :
mode : restore
restoreSource : openstackbackupsave-1641928378Os campos de especificações são os seguintes:
mode: restore indica que esta é uma solicitação para restaurar um OpenStackBackup existente.restoreSource indica qual OpenStackBackup deve ser restaurado. Com mode definido para restore , o operador OSP-D pegará o conteúdo do restoreSource OpenStackBackup e tentará aplicá-los contra os CRs, configurações e segredos existentes atualmente presentes no espaço de nome. Assim, substituirá quaisquer recursos do operador OSP-D existentes no espaço para nome com os mesmos nomes que os do OpenStackBackup e criarão novos recursos para aqueles que atualmente não são encontrados no espaço para nome. Se desejado, mode pode ser definido como cleanRestore para limpar completamente os recursos do operador OSP-D existente no espaço de nome antes de tentar uma restauração, de modo que todos os recursos do OpenStackBackup sejam criados completamente novamente.
OpenStackBackupRequest for criado, monitore seu status: oc get -n openstack osbackuprequest openstackbackuprestore Algo assim deve parecer indicar que todos os recursos do OpenStackBackup estão sendo aplicados contra o cluster:
NAME OPERATION SOURCE STATUS COMPLETION TIMESTAMP
openstackbackuprestore restore openstackbackupsave-1641928378 Loading Então, depois que todos os recursos forem carregados, o operador começará a se reconciliar para tentar provisionar todos os recursos:
NAME OPERATION SOURCE STATUS COMPLETION TIMESTAMP
openstackbackuprestore restore openstackbackupsave-1641928378 Reconciling Se o OpenStackBackupRequest entrar no estado Error , consulte seu conteúdo completo para ver o erro que foi encontrado ( oc get -n openstack openstackbackuprequest <name> -o yaml ).
OpenStackBackupRequest for homenageado restaurando totalmente o OpenStackBackup , ele entrará no estado Restored . Por exemplo: oc get -n openstack osbackuprequest
NAME OPERATION SOURCE STATUS COMPLETION TIMESTAMP
openstackbackuprestore restore openstackbackupsave-1641928378 Restored 2022-01-12T13:48:57Z Nesse ponto, todos os recursos contidos com o OpenStackBackup escolhido devem ser restaurados e totalmente provisionados.
O operador do Diretor OSP cria automaticamente um configuração após a execução de cada recurso do OSDEPLAPE. Este ConfigMap recebeu o nome do nome do recurso Osdeploy e prefixado com TriLeo-Exports-. Por exemplo, triplo-exports-Default seria o nome do ConfigMap para o recurso OSDeploy 'padrão'. Cada ConfigMap contém 2 arquivos YAML:
| Nome do arquivo | Descrição | Comando Triloo equivalente |
|---|---|---|
| ctlPlane-Export.yaml | Usado com várias pilhas para DCN | Exportação de overcloud |
| ctlPlane-Export filtered.yaml | Usado para várias pilhas com pilhas "controlador" de célula | Exportação de células em overcloud |
Use o comando abaixo para extrair os arquivos YAML do configmap. Uma vez extraído, os arquivos YAML podem ser adicionados aos parâmetros de calor personalizados nos recursos OSCONFIGGERATER.
oc extract cm/tripleo-exports-defaultNota: O operador do diretor OSP ainda não gera exportações para pilhas de ceph.
Se necessário, é possível alterar a CPU/RAM de um OpenStackvmset configurado através do OpenStackControlplane. O fluxo de trabalho é o seguinte:
Por exemplo, para alterar o controlador virtualmachinerole para ter 8 núcleos e 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 alimentar a VM de volta. Veja o documento do processo de atualização OSP
