Guia de implantação de RHOSP no UCS para carga de trabalho de mobilidade no modo desconectado

Introdução

Este documento descreve uma estrutura para implantar RHOSP em servidores UCS C220 M6 para oferecer suporte ao Cisco VPC-DI.

Pré-requisitos

Requisitos

A Cisco recomenda que você tenha conhecimento da plataforma Red Hat OpenStack (RHOSP) e possua habilidades sólidas no Red Hat Enterprise Linux (RHEL). Além disso, é necessária uma compreensão sólida dos conceitos de virtualização e rede.

Componentes Utilizados

Este documento não se restringe a versões de software e hardware específicas.

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.

Informações de Apoio

Este guia descreve a integração do RHOSP com a infraestrutura do Unified Computing System (UCS), enfatizando escalabilidade, confiabilidade e otimização de desempenho.

Ele detalha as práticas recomendadas e usa uma possível automação baseada em script para implantar o OpenStack TripleO, que inclui as arquiteturas Undercloud e Overcloud.

Ao usar este guia de implantação, as organizações podem obter uma infraestrutura de nuvem RHOSP robusta e eficiente, personalizada para atender ao Cisco Virtual Packet Core - Distributed Instance (VPC-DI) baseado em Mobility Virtual Network Functions (VNF).

Entendendo o RHOSP

O RHOSP é uma solução de nuvem privada de nível empresarial criada com base no projeto OpenStack de código aberto, integrada e com suporte da Red Hat. Ele permite que as organizações implantem e gerenciem infraestrutura como serviço (IaaS) para máquinas virtuais (VMs), rede e armazenamento sob demanda.

Ele fornece recursos como alta disponibilidade (HA), virtualização de funções de rede e implantações personalizáveis.

Arquitetura RHOSP

O RHOSP é baseado principalmente no projeto OpenStack TripleO. O Openstack usa o Diretor, que atua como um conjunto de ferramentas para instalar e gerenciar um ambiente RHOSP completo.

O RHOSP foi projetado para fornecer uma infraestrutura de nuvem escalável e flexível. Sua arquitetura consiste em dois componentes principais: Undercloud e Overcloud.

Subnuvem

O undercloud é o nó de gerenciamento principal que contém o conjunto de ferramentas do diretor RHOSP. É uma instalação de sistema único do OpenStack que inclui componentes para provisionamento e gerenciamento dos nós do OpenStack que formam o ambiente do OpenStack (o overcloud).

Componentes do Undercloud

O undercloud usa componentes do OpenStack como seu conjunto básico de ferramentas. Cada componente opera dentro de um contêiner separado na nuvem inferior:

• Identidade do OpenStack (keystone) - Fornece autenticação e autorização para os componentes do diretor
• OpenStack bare metal (irônico) - Gerencia nós bare metal
• Rede OpenStack (nêutron) e Open vSwitch - Rede de controle para nós bare-metal
• Orquestração do OpenStack (Ephemeral Heat) - Fornece a orquestração de nós depois que o direcionador grava a imagem do overcloud no disco

Overcloud

O overcloud é o ambiente RHOSP resultante criado usando o undercloud. Isso inclui diferentes funções de nó definidas com base no ambiente da plataforma OpenStack (OSP) que o cliente pretende criar.

Controlador

Os nós do controlador fornecem administração, rede e HA para o ambiente OpenStack. Um ambiente OpenStack recomendado contém três nós de controlador juntos em um cluster de alta disponibilidade.

Computação

Os nós de computação fornecem recursos de computação para o ambiente OpenStack. Os nós de computação podem ser dimensionados horizontalmente ou horizontalmente com base nos requisitos de rede ao longo do tempo. Um nó de computação padrão contém os seguintes componentes mencionados:

• Computação OpenStack (nova)
• VM baseada em kernel (KVM)/emulador rápido (QEMU)
• Abrir vSwitch

Armazenamento

Os nós de armazenamento fornecem armazenamento para o ambiente OpenStack.

Repositório local (servidor do REPO)

Redhat fornece um utilitário chamado reposync que pode ser usado para baixar os pacotes da Rede de Entrega de Conteúdo (CDN - Content Delivery Network). Para fazer o download de todos os pacotes de um canal específico, o sistema deve ser inscrito nesse canal. Se o sistema não estiver inscrito no canal necessário, o reposync não poderá baixar e sincronizar esses pacotes no sistema local.

Os repositórios são configurados no caminho /etc/yum.repos.d/ por arquivos que terminam com a extensão .repo. Vários repositórios podem ser definidos no mesmo arquivo.

Rede RHOSP

O serviço de rede (nêutron) é o componente de rede definida por software (SDN) do RHOSP. O serviço de rede RHOSP gerencia o tráfego interno e externo de e para instâncias de VM e fornece serviços centrais como roteamento, segmentação, DHCP e metadados. Ele fornece a API para recursos de rede virtual e gerenciamento de switches, roteadores, portas e firewalls.

O diretor RHOSP mapeia os serviços do OpenStack para diferentes redes isoladas. As redes que transportam cada tipo de tráfego são: Cisco Integrated Management Controller (CIMC), Provisionamento, API interna, Dados de armazenamento, Gerenciamento de armazenamento, Espaço e Externo (Secure Shell (SSH) e Operações, Administração e Manutenção (OAM)).

Conectividade física RHOSP

A implantação do RHOSP usa diferentes portas físicas dos servidores Cisco UCS C220 M6 para diferentes fins de conectividade.

Serial Number	Portas físicas	Detalhes
1.	CIMC	O CIMC fornece conectividade fora da banda para provisionamento e gerenciamento de servidores.
2.	Virtualização de E/S de Raiz Única (SR-IOV)/PCIe (Peripheral Component Interconnect Express)	A Placa de Interface de Rede (NIC) PCIe é usada nos nós de computação para as redes DI-internas e de Serviço para o VNF.
3.	Lan modular na placa-mãe (MLOM)	As portas MLOM são configuradas como ligações. osp_external, osp_internal, osp_tenant, osp_external, osp_storage_data, osp_storage_mgmt usa a porta MLOM para comunicação interna.
4.	Lan na placa-mãe (LOM)	O direcionador usa as portas LOM1 e LOM2, enquanto os computadores e controladores usam apenas a porta LOM1. O LOM1 é usado para implantar ou provisionar o Openstack em todos os servidores. O LOM2 é usado como OAM (rede externa) no direcionador.

O diagrama mostra a conectividade física com os servidores.

Conectividade lógica RHOSP

A rede RHOSP tem várias sub-redes que atendem a diferentes serviços na nuvem.

• OSP_CIMC:

O CIMC é a Intelligent Programming Management Interface (IPMI) que controla o gerenciamento de todos os servidores UCS. Essa rede CIMC é configurada na porta CIMC independente de todos os servidores UCS.

• Provisionamento_OSP:

Essa rede é responsável pelo provisionamento e pelo gerenciamento de inicialização do Preboot Execution Environment (PXE) dos computadores e servidores do controlador durante a implantação de Overcloud e também para obter o IP DHCP. A rede de provisionamento é configurada como VLAN nativa na porta LOM1 de todos os servidores UCS para simplicidade e compatibilidade. Essa rede de provisionamento é responsável pela implantação da nuvem em todos os servidores.

Devido à virtualização no servidor Diretor, uma rede de ponte precisava ser criada no KVM para que a VM Diretor se comunicasse com os outros servidores.

• OSP_Interno:

A rede de API interna é usada para comunicação entre os serviços do OpenStack como nêutron, nova, keystone e assim por diante.

A rede OSP_Internal é configurada em portas MLOM vinculadas nos nós Controlador e Computação.

• Locatário_OSP:

A rede de Locatários é criada por padrão em projetos de nuvem para gerenciamento de VNF. Na configuração atual, apenas um único projeto Openstack é criado para implantação VNF.

A rede OSP_Tenant é configurada em portas MLOM vinculadas nos nós Controlador e Computação.

• OSP_Externo:

A rede externa é usada para todas as redes de acesso externo (como SSH) e API.

A rede OSP_External é configurada na Porta LOM2 no nó Diretor e nas Portas MLOM vinculadas nos nós Controlador e Computação.

• OSP_Storage_Data:

A rede OSP_Storage é usada para todas as operações relacionadas ao acesso ao armazenamento. Isso é necessário para a comunicação entre o serviço CEPH e a VNF que têm a necessidade de acessar o armazenamento. Ele é usado por controladores, nós de computação e CEPH.

A rede OSP_Storage_Data é configurada em portas MLOM vinculadas nos nós Controlador e Computação.

• OSP_Storage_Management:

O OpenStack Object Storage usa essa rede para sincronizar objetos de dados entre nós de réplica participantes no cluster de armazenamento, formado entre nós de computação do controlador.

A rede OSP_Storage_Mgmt é configurada em portas MLOM vinculadas nos nós Controlador e Computação.

O diagrama mostra como as redes lógicas subcloud são conectadas a cada tipo de nós no cluster RHOSP.

Ajuste de parâmetro de hardware

• Verificar se o IP está habilitado e configurado com o endereço de gerenciamento correto de acordo com o design.
• Verifique se o usuário admin e sua senha devem ser iguais para todo o acesso de login do CIMC.
• Verifique se o modo Bootstrap (Boot) está definido como Unified Extensible Firmware Interface (UEFI).
• Certifique-se de definir a configuração do BIOS com os parâmetros recomendados.
• Defina a ordem de inicialização como:
  1. LOM-PXE (eno1)
  2. Unidade de disco rígido (HDD) de BOOT

• Defina o endereço MAC do LOM1 (eno1).
• Verificar se todos os servidores UCS/CIMC estão atualizados com a versão de firmware recomendada mais recente.

Instalação e criação de rede do Hypervisor-KVM

Há vários métodos para implantar o Undercloud/Diretor e o REPO off-line na rede do cliente. Eles podem ser implantados diretamente em um nó bare-metal ou como VMs em execução em um hipervisor KVM.
No guia de implantação atual, o servidor Diretor UCS é configurado para hospedar o hipervisor KVM, o que facilita a criação de várias VMs. O nó RHOSP Diretor e o nó Offline REPO são implantados como VMs neste hipervisor KVM.

• Quando o KVM estiver ativo, atualize o nome do host:
  hostnamectl set-hostname <hostname> —static

• Configure as bridges externa e de provisionamento e vincule as interfaces.

br-prov: eth0

br-ext: eth1

Essas pontes devem ser criadas através da interface de usuário de texto (NMTUI) do Network Manager.

• Por padrão, as portas eno1 e eno2 são criadas no KVM para as portas físicas LOM1 e LOM2, verifique o mesmo usando o endereço MAC do registro do CIMC.
• Crie uma rede de ponte e adicione portas subordinadas a ela mapeando o endereço MAC correto.
• Após a criação da rede de ponte, certifique-se de que o provisionamento e o gateway externo estejam acessíveis a partir do KVM.

Criação do REPO e do Diretor VM

Pré-requisitos para o REPO e para a criação de VM do Diretor

# dnf install qemu-kvm libvirt virt-install virt-manager virt-viewer libguestfs-tools

• Instale os pacotes necessários no KVM para o REPO e a Criação de VM do Diretor.

• Crie os diretórios necessários no KVM.
  
  

  # mkdir /data # mkdir /data/offlineRepos # mkdir /data/isoImages # mkdir /data/qcow2Images # mkdir /data/images

• Copie os arquivos para os diretórios.

# scp -r root@[remote-IP]:/root/rhel-8.4-x86_64-dvd.iso /data/isoImages/
# scp -r root@[remote-IP]:/root/offlineRepos/RHEL8.4 /data/offlineRepos/
# scp -r root@[remote-IP]:/etc/yum.repos.d/offlinedvd.repo /etc/yum.repos.d/
# scp -r root@[remote-IP]:/root/rhel-8.4-x86_64-kvm.qcow2 /data/qcow2Images/
# scp -r root@[remote-IP]:/root/OSREPO_RHEL_84.qcow2 /data/images/
# scp -r root@[remote-IP]:/root/OSREPO_DIRECTOR_84.qcow2 /data/images/

• Monte o ISO em /mnt/iso.

# mount -t iso9660 -o loop /data/isoImages/rhel-8.4-x86_64-dvd.iso /mnt/iso

• Crie o arquivo REPO no caminho /etc/yum.repos.d.

# cat /etc/yum.repos.d/offlinedvd.repo

[RHEL8.4_Appstream]
name=Red Hat Enterprise Linux 8.4.0 Appstream
mediaid=None
metadata_expire=-1
gpgcheck=0
enabled=1
baseurl=file:///data/offlineRepos/RHEL8.4/AppStream/

[RHEL8.4_BaseOS]
name=Red Hat Enterprise Linux 8.4.0 BaseOS
mediaid=None
metadata_expire=-1
gpgcheck=0
enabled=1
baseurl=file:///data/offlineRepos/RHEL8.4/BaseOS/

• Verifique o repolist e certifique-se de que os REPOs Appstream e Baseos estejam mapeados.

# dnf repolist

Criação de VM do REPO

$ cd /var/lib/libvirt/images/
$ export LIBGUESTFS_BACKEND=direct
$ virt-customize -a /var/lib/libvirt/images/rhel-8.4-x86_64-kvm.qcow2 --root-password password:Cisco@123        

$ virt-filesystems --long -h --all -a /var/lib/libvirt/images/rhel-8.4-x86_64-kvm.qcow2

• Criar a imagem do servidor do REPO.

$ qemu-img create -f qcow2 /var/lib/libvirt/images/rhel_84_osprepo.qcow2 500G

$ virt-resize --expand /dev/sda3 /var/lib/libvirt/images/rhel-8.4-x86_64-kvm.qcow2 /var/lib/libvirt/images/rhel_84_osprepo.qcow2

$ qemu-img create -f qcow2 -b /var/lib/libvirt/images/rhel_84_osprepo.qcow2 -F qcow2 /data/images/OSPREPO_RHEL_84.qcow2

$ guestfish -a /data/images/OSPREPO_RHEL_84.qcow2 -i ln-sf /dev/null /etc/systemd/system/cloud-init.service

$ osinfo-query os | grep rhel8

$ virt-install --cpu host --memory 32768 --vcpus 16 --os-variant rhel8.4 --disk path=/data/images/OSPREPO_RHEL_84.qcow2,device=disk,bus=virtio,format=qcow2 --import --noautoconsole --vnc --network bridge:br-ext --name OSPREPO_RHEL_84

$ virsh list --all

Criação de VM do Diretor

• Crie a imagem do servidor direcionador.

# qemu-img create -f qcow2 /var/lib/libvirt/images/rhel_84_ospdirector.qcow2 500G

# virt-resize --expand /dev/sda3 /var/lib/libvirt/images/rhel-8.4-x86_64-kvm.qcow2 /var/lib/libvirt/images/rhel_84_ospdirector.qcow2

# qemu-img create -f qcow2 -b /var/lib/libvirt/images/rhel_84_ospdirector.qcow2 -F qcow2 /data/images/OSPDIRECTOR_RHEL_84.qcow2

# guestfish -a /data/images/OSPDIRECTOR_RHEL_84.qcow2 -i ln-sf /dev/null /etc/systemd/system/cloud-init.service
# virt-install --cpu host --memory 131072 --vcpus 32 --os-variant rhel8.4 --disk path=/data/images/OSPDIRECTOR_RHEL_84.qcow2,device=disk,bus=virtio,format=qcow2 --import --noautoconsole --vnc --network bridge:br-prov --network bridge:br-ext --name OSPDIRECTOR_RHEL_84

# virsh list --all

• Abra uma nova janela e faça o login do console da VM.

# virsh list –all
# virsh console <domain-id>

• Após a implantação da VM do Diretor, duas interfaces eth0 e eth1 são criadas.
  • eth0 é usado para a rede OSP_provisioning, na qual durante a rede br-ctlplane são criadas durante a implantação do Undercloud.
  • eth1 é usado para conectividade externa para acesso SSH. Assim, o endereço IP da sub-rede OSP_externa é atribuído.

Criação de REPO offline local

O servidor do REPO deve ser registrado com o Redhat CDN e deve ter o repositório de todos os pacotes disponíveis de RHOSP 16.2 necessários para a implantação. Os pacotes RPM RHEL e as imagens do contêiner RHOSP devem ser baixados para a VM do REPO usando o proxy.

Implantação de nuvem RHOSP

O RHOSP 16.2 é implantado na rede do cliente por meio da automação. Scripts analisáveis são usados para automatizar a implantação de Undercloud e Overcloud.

Pré-requisitos

Etapas a serem seguidas antes de iniciar a implantação real da nuvem:

1. Garantindo a conectividade do nó KVM com o REPO VM Local e o Diretor VM na rede OSP_EXT.
2. Certifique-se de que todos os scripts de automação e de análise sejam carregados no host KVM na pasta designada.
3. Crie pastas com nomes como 'cisco' e 'automation' e coloque o tarball dos scripts possíveis.

# cd /home
# mkdir cisco
# cd /home/cisco
# mkdir automation
# cd /home/cisco/automation

O pacote consistirá em três estruturas de pastas, nomeadas como:

• scripts: consiste em scripts de shell usados para configuração de nó baremetal.
• rpms: consiste em drivers ICE (Intel Ethernet Connection), drivers intel e pacotes RPM (Red-Hat Package Manager).
• Ansible consiste no arquivo Input vars, nos arquivos ansíveis yaml para deployment e nos modelos jinja.

4. Instale o pacote shpass. sshpass é um utilitário de linha de comando usado para fornecer senhas ao ssh de forma não interativa. Ele é usado principalmente em cenários de script ou automação em que a entrada manual de senha não é viável.

• Baixe o pacote sshpass sshpass.tar.gz do servidor de internet/existente.
• Instale o pacote GNU Compiler Collection (GCC).

# yum install gcc

• Instalar pacotes make.

# yum install make

• Descompacte o pacote sshpass e instale o SSH pass.

# tar -xvzf sshpass.tar.gz
# cd sshpass-1.10/
# ./configure
# sudo make install
# sshpass -V

5. O processo de instalação do direcionador requer que um usuário não raiz execute comandos. O usuário 'Stack' deve ser criado no Diretor VM com acesso sudo.

# useradd stack
# passwd stack

Disable password requirements for the ‘stack’ user when using sudo.
# echo "stack ALL=(root) NOPASSWD:ALL" | tee -a /etc/sudoers.d/stack
# chmod 0440 /etc/sudoers.d/stack

6. Copie o arquivo rootCA.crt do servidor REPO para o Diretor VM e KVM no caminho fornecido. Além disso, atualize o certificado da VM do REPO na lista de confiança.

# /etc/pki/ca-trust/source/anchors
# update ca-trust

7. Atualize os detalhes do nome do host do servidor do REPO local no Diretor VM e KVM no arquivo /etc/hosts.

8. No KVM e Diretor VM, instale pacotes adicionais como python, ansible e assim por diante para executar scripts de automação possíveis.

# dnf install python3 python3-devel ansible httpd -y
# update-alternatives --set python /usr/bin/python3

9. A sub-rede CIMC deve estar acessível a partir da rede de provisionamento do Diretor para permitir o provisionamento durante a implantação da nuvem. Se necessário, adicione a rota estática para o mesmo.

# ip -6 route add <CIMC Subnet> via <Provisioning Subnet>

10. No KVM e no Diretor VM, crie um arquivo de host na pasta /ansible e adicione detalhes específicos da pilha conforme necessário.

[ospd]
# <PODNAME> ansible_host=<OSPD IP> ansible_ssh_user=stack ansible_ssh_pass='<STACKPASSWD>' ansible_ssh_common_args='-o StrictHostKeyChecking=no'

<podname> - Stack Name of the Cloud.
<OSPD IP> - Baremetal OSPD Node IP Address
<STACKPASSWD> - OSPD Node password for ‘stack’ user

11. Certifique-se de que todos os manuais de atividades e arquivos de entrada devem ser mantidos no Diretor VM na pasta /home/stack.

Atualização dos arquivos de entrada

Há um arquivo de variável de entrada que consiste em detalhes específicos da rede do cliente que devem ser preparados para a implantação da nuvem.

Caminho: /home/cisco/automation/ansible/podvars

Nome do arquivo: <nome-da-pilha>_vars.yml

Atualize os parâmetros destacados de acordo com o plano IP específico do site/documento de projeto detalhado.

# #############################
# XR21 Specific Variables
# #############################

# ===========================
# Common Variables
# ===========================

# UCS hardware type: 'm4/m5/m6'
hardware: m6

# Platform type: 'epc/pcrf'
platform: epc

# RHEL version
rhel: { version: 84, tag: 8.4 }

# Openstack version
osp: { version: 16, major: 2 }

# Container version
container: { tag: 16.2, tools: 3.0 }

# Overcloud stack name
stack_name: ''

# OSPD full hostname
fqdn_hostname: '.epdg.ap.hamb.a6.cloud.com’

# OSPD host login
ospd_host: { ip: '2405:XXXX:089:1054::11', username: 'stack', password: '*******' }

# OSPD cimc login
ospd_cimc: { ip: '2405:XXXX:089:1054::11', username: 'admin', password: '********' }

# CIMC username and pasword must be same across all Overcloud nodes
cimc: { username: 'admin', password: '********', ip_pool: '2405:XXXX:089:1055::/64' }

# Undercloud-Overcloud provision
internal_network: {
   ip_type: 'v6',
   local_interface: 'eth0',
   local_ip: ‘2405:XXXX:089:1041::103',
   undercloud_public_host: ‘2405:XXXX:089:1041::105',
   undercloud_admin_host: ‘2405:XXXX:089:1041::104',
   cidr: ‘2405:XXXX:089:1041::/64',
   dhcp_start: ‘2405:XXXX:089:1041::200',
   dhcp_end: ‘2405:XXXX:089:1041::299',
   gateway: ‘2405:XXXX:089:1041::199',
#   nexthop: ‘2405:XXXX:089:1041::1',
   inspection_iprange_start: ‘2405:XXXX:089:1041::300',
   inspection_iprange_end: ‘2405:XXXX:089:1041::399',
}

# DNS
dns_ips: [ '2405:YYYY:a10:f100::1' ]
dns_search_domains: [ 'cloud.com' ]

# NTP
ntp_ips: [ '2405:YYYY:801:700::afa', '2405:YYYY:801:700::afb' ]

# Deployment type: 'offline/online'
repos: { rhel: 'offline', container: 'offline' }

# Offline details if repos is 'offline'
offline: {
    environment: 'v01_00',
    deliverymedia: '/home/stack/deliverymedia/'
}

# Satellite details if repos is 'online'    
satellite: {
    fqdn_name: 'rh-satellite2.mitg-bxb300.cisco.com',
    ip: '10.XX.XX.XX',
    org: 'MITG',
    user: 'admin',
    password: '*******',
    environment: 'production',
    activation_key: 'ak-rhel{{rhel.version}}-osp{{osp.version}}{{osp.major}}',
    repos_file: 'rhel{{rhel.version}}osp{{osp.version}}{{osp.major}}.yaml'
}

# Offline container registry details
offline_registry: {
    ip: '2405:XXXX:089:1055::100',
    name: '.',
    port: '5000',
    container_tag: '16.2.6',
    user: 'ciscoadmin',
    password: '******'
}

# Custom cloud domain details
domain_name: {
    domain: '',
    cloudshortname: 'nl'
}

# Container images namespace  
container_namespace: 'mitg-{{satellite.environment}}-cv-rhel{{rhel.version}}-osp{{osp.version}}{{osp.major}}-rhel{{rhel.version}}-osp{{osp.version}}{{osp.major}}'

# List of cimc IPs
ctrl_cimc_ip:
  - 2405:XXXX:YYYY:1036::12
  - 2405:XXXX:YYYY:1036::13
  - 2405:XXXX:YYYY:1036::14

osdc_cimc_ip:
cmpt_cimc_ip:
  - 2405:XXXX:YYYY:1037::17
  - 2405:XXXX:YYYY:1038::18
  - 2405:XXXX:YYYY:1038::19
  - 2405:XXXX:YYYY:1038::20

mgmt_cimc_ip:
  - 2405:XXXX:YYYY:1051::15
  - 2405:XXXX:YYYY:1051::16

# ===========================
# Hardware Specific Variables
# ===========================

# Isolcpu for cpu pinning
isolcpus: { osdc: '4-31,36-63', cmpt: '2-31,34-63', mgmt: '2-31,34-63' }

# Hugepages in 1G Pages
hugepages: { osdc: 428, cmpt: 448, mgmt: 448 }

# Reserved host memory in MB
reserved_host_memory: { osdc: 84000, cmpt: 64000, mgmt: 64000 }

# Number of VFs per SR-IOV port
sriov_vfs_per_port: 16

# List of SR-IOV ports
sriov_port_list: [ens1f0, ens1f1, ens9f0, ens9f1]

# List of OVS bonding interface
ovs_bond_interface: [eno5, eno6]

# Physical networks
physical_network: [phys_pcie1_0, phys_pcie1_1, phys_pcie2_0, phys_pcie2_1]

# Boot disk size
boot_disk_mb_size: { ctrl: 761985, osdc: 761985, cmpt: 761985, mgmt: 1524925 }

# Boot disk PD slot number
boot_disk_pd_slot: { ctrl: [1,2], osdc: [1,2], cmpt: [1,2], mgmt: [1,2] }

# Boot disk VD slot number
boot_disk_vd_slot: { ctrl: 237, osdc: 235, cmpt: 239, mgmt: 239 }

# Storage backend 'swift' or 'ceph'
storage_backend: 'swift'

# Storage disk size
storage_disk_mb_size: { swift: 761985, ceph: 914573, journal: 0 }

# Storage disk PD slot number
storage_disk_pd_slot: { swift: [6,7], ceph: [3,4,5,6], journal: [0] }

# Storage disk VD slot number
storage_disk_vd_slot: { swift: [238,239], ceph: [236,237,238,239], journal: [0] }

# Firmware version 'yes' or 'no' ???
firmware: { check: 'no', bios_version: '4.2.3c', cimc_version: '4.2(3e)' }

# ===========================
# OSP Specific Variables
# ===========================

# Timezone for overcloud nodes
timezone: 'Asia/Kolkata'

# Overcloud node count to deploy
node_count: { ctrl: 3, osdc: 0, cmpt: 11, mgmt: 2 }
local_network: {
   ip_type: 'v6',
   tenant_vlan_id: 1045,
   tenant_net_cidr: '240f:ppp:rr:1045::/64',
   tenant_alloc_pools_start: '240f:ppp:rr:1045::10',
   tenant_alloc_pools_end: '240f:ppp:rr:1045:ffff:ffff:ffff:fffe',

   storage_vlan_id: 1043,
   storage_net_cidr: '240f:ppp:rr:1043::/64',
   storage_alloc_pools_start: '240f:ppp:rr:1043::10',
   storage_alloc_pools_end: '240f:ppp:rr:1043:ffff:ffff:ffff:fffe',

   storage_mgmt_vlan_id: 1044,
   storage_mgmt_net_cidr: '240f:ppp:rr:1044::/64',
   storage_mgmt_alloc_pools_start: '240f:ppp:rr:1044::10',
   storage_mgmt_alloc_pools_end: '240f:ppp:rr:1044:ffff:ffff:ffff:fffe',

   internal_api_vlan_id: 1042,
   internal_api_net_cidr: '240f:ppp:rr:1042::/64',
   internal_api_alloc_pools_start: '240f:ppp:rr:1042::10',
   internal_api_alloc_pools_end: '240f:ppp:rr:1042:ffff:ffff:ffff:fffe'
}

# External VLAN and IP configs
external_network: {
   ip_type: 'v6',
   vlan_id: 1046,
   default_route: '2405:XXXX:YYYY:1055::1',
   network_cidr: '2405:XXXX:YYYY:1055::/64',
   alloc_pool_start: '2405:XXXX:YYYY:1055::100',
   alloc_pool_end: '2405:XXXX:YYYY:1055::200',
   horizon_ip: '2405:XXXX:YYYY:1055::107'
}

# Neutron mechanism driver 'ovs' or 'ovn'
neutron: {
   driver: 'ovs',
   dvr: false,
   datacenter_vlan_start: 1050,
   datacenter_vlan_end: 1070
}


# ===========================
# OS Specific Variables
# ===========================

# RHEL kernel version
kernelversion: '4.18.0-305.88.1.el8_4.x86_64'

# E810 ICE driver
ice_driver: { check: 'yes', version: 1.12.6, intel_aux_version: 1.0.1 }

# ENIC and FNIC verison
nic_version: { enic: '2.3.0.53', fnic: '1.6.0.53' }

# IPMI watchdog timer config
watchdog: { action: enabled, version: '2.0.31-3.el8.x86_64', timer: 250 }

# StorCLI raid management
storcliver: '007.2612.0000.0000-1.noarch'

# ===========================
# Platform Specific Variables
# ===========================

# Buffer pool size based on platform type
innodb_buffer_pool_size: 1610
# ##################################
# END - XR21 Specific Variables
# ##################################

Implantação de subnuvem

O Undercloud é implantado usando scripts possíveis em sete etapas. Todas as etapas devem ser executadas a partir do host KVM que atua como host de salto neste caso.

Etapa	Marca	Descrição	YAMLs do manual
Etapa 1.	arquivos de verificação	Verifique os manuais de atividades, scripts e RPMs necessários no OSPD (Openstack Platform Diretor).	osp16_publishbooks_verify.yml
Etapa 2.	genpodvars	Gerar arquivos variáveis específicos do POD relacionados ao hardware, RHEL, etc., como common_vars.yml (hardware, software, detalhes da rede), hw_m6_vars.yaml (CPU, memória, hugepages, disco, NIC, etc.), rhel_84_vars.yml (RHEL, kernel, driver ICE, versão NIC), pf_esc_vars.yml (detalhes do Controlador de Serviços Elásticos (ESC)), osp_16_vars.yml (versão do OSP, fuso horário, tipo de IP, ID da VLAN, IP, detalhes de nêutrons).	osp16_generate_pod_specific_vars.yml
Etapa 3.	preucdeploy	Configure o FQDN (Fully Qualified Domain Name, nome de domínio totalmente qualificado), o NTP (Network Time Protocol, protocolo de tempo de rede) e atualize todos os pacotes no nó do direcionador.	osp16_pre_undercloud_deploy.yml
Etapa 4.	firstreboot	Executa a primeira reinicialização do nó do diretor Undercloud após a configuração anterior e a instalação do pacote.	osp16_undercloud_deploy.yml
Etapa 5.	ucdeploy	Instalar pilha Undercloud no diretor	osp16_undercloud_tuning.yml
Etapa 6.	cstate	Defina as configurações de estado C da CPU do BIOS no nó do direcionador.	osp16_cstate.yml
Passo 7.	segundainicialização	Segunda reinicialização no diretor Undercloud após alterações de BIOS.	N/A

O arquivo com o nome osp16_auto_undercloud_deploy.yml é um manual de atividades principal que pode ser executado em uma única iteração, mas é aconselhável executar o manual de atividades em etapas, usando tags diferentes para facilitar a solução de problemas no caso de qualquer problema de implantação.

# cd /home/stack/ansible/
# ansible-playbook -i hosts osp16_auto_undercloud_deploy.yml -e podname=<> --tags= TAG

For Ex –

# ansible-playbook -i hosts osp16_auto_undercloud_deploy.yml -e podname=<> --tags=checkfiles
# ansible-playbook -i hosts osp16_auto_undercloud_deploy.yml -e podname=<> --tags=genpodvars
# ansible-playbook -i hosts osp16_auto_undercloud_deploy.yml -e podname=<> --tags=preucdeploy
# ansible-playbook -i hosts osp16_auto_undercloud_deploy.yml -e podname=<> --tags=firstreboot
# ansible-playbook -i hosts osp16_auto_undercloud_deploy.yml -e podname=<> --tags=ucdeploy
# ansible-playbook -i hosts osp16_auto_undercloud_deploy.yml -e podname=<> --tags=cstate
# ansible-playbook -i hosts osp16_auto_undercloud_deploy.yml -e podname=<> --tags=secondreboot

Note :- Deployment Logs would be generated in “/home/stack/autologs” in Director-VM.

Post-Checks for Verification of Undercloud Deployment.
“stackrc” & “undercloud.conf” file must be generated in /home/stack folder.

# sudo podman ps -a
# source stackrc
# openstack stack list
# openstack stack show <stack-name> --fit
# openstack server list
# openstack network list
# openstack subnet list

Implantação de Overcloud

O Overcloud é implantado com no mínimo três controladores em modo HA e um computador. O Overcloud é implantado usando scripts possíveis em 17 etapas. Todas as etapas devem ser executadas a partir do Diretor-VM que atua como host de salto neste caso.

Etapa	Marca	Descrição	YAMLs do manual
Etapa 1.	genpodvars	Gerar arquivos de variáveis específicas do POD para Overcloud relacionados a hardware, RHEL, etc., como common_vars.yml (hardware, software, detalhes da rede), hw_m6_vars.yaml (CPU, memória, hugepages, disco, NIC, etc.), rhel_84_vars.yml (RHEL, kernel, driver ICE, versão NIC), pf_esc_vars.yml (detalhes ESC), osp_16_vars.yml (versão do OSP, fuso horário, tipo de IP, ID da VLAN, IP, detalhes de nêutrons).	osp16_generate_pod_specific_vars.yml
Etapa 2.	geninstack	Gere o arquivo JSON Instackenv de /var/common_vars.yml criado na etapa anterior. O direcionador requer um modelo de definição de nó, que é criado manualmente. Este arquivo instackenv.json usa o formato JSON e contém todos os detalhes de gerenciamento de energia e hardware para os nós. Esta etapa também valida a configuração de hardware no servidor UCS antes de gerar o arquivo.	osp16_generate_instackenv.yml
Etapa 3.	cimcvd	Defina a configuração do CIMC e os Discos Virtuais (VDs) em cada servidor referindo-se a common_vars.yml, hw_m6_vars.yaml e rhel_84_vars.yml.	osp16_cimc_vd_configure.yml
Etapa 4.	preocdeploy	Esta etapa executa todos os pré-requisitos para implantar o Overcloud. Ele define o FQDN, o NTP e atualiza todos os pacotes, envia a imagem para o caminho para implantação.	osp16_pre_overcloud_deploy.yml
Etapa 5	importnodes	Nesta etapa, a CPU do servidor é introspectada, a memória, a placa de rede junto com a interface e as portas nos switches de rede. A introspecção é realizada nos switches de rede conectados para todos os controladores e computadores.	osp16_import_ironic_nodes.yml
Etapa 6.	gentemplates	Gere arquivos de modelo personalizados para controladores e computadores. No modelo personalizado, defina as funções de controlador e de computação para todos os serviços em execução neles. Ele também reforça o sistema aplicando certificados, rotas e assim por diante.	osp16_generate_custom_templates.yml
Passo 7.	ocdeploy	Nesta etapa, é feita uma implantação do Openstack Overcloud. Execute o deploy.sh fornecido pela Red Hat para a implantação do RHOSP.	osp16_overcloud_deploy.yml
Passo 8	geninventory	Nesta etapa, um arquivo yml de inventário para uso pelo Ansible é gerado onde o IP de Provisionamento, o IP da IPMI (CIMC) e as credenciais são armazenados e mapeados com controlador e computadores para que a automação faça login no sistema e execute as etapas posteriores.	osp16_build_inventory_v3.py
Etapa 9.	offlinerepo	Configure o REPO Offline Overcloud no arquivo /etc/yum.repo.d/offline.repo para apontar para o servidor do repo através da rede externa.	osp16_config_offline_repo.yml
Etapa 10.	cercas	Configure o zoneamento em todos os nós do controlador com Shoot The Other Node In The Head (uma técnica de zoneamento em clusters HA) (STONITH).	osp16_config_fencing.yml
Etapa 11.	cache RAID	Defina a configuração de Cache Raid para todas as controladoras e computadores e também defina as configurações de armazenamento SWIFT.	osp16_raid_cache_tuning.yml
Etapa 12.	dnfupdate	Execute atualizações de DNF para todos os pacotes em todos os nós.	dnf_update_all_packages.yml
Etapa 13.	setiplink	Nesta etapa, o controle do modo de confiança para portas SR-IOV é habilitado para tráfego interno e de dados do Evolved Packet Data Gateway (EPDG). O suporte para portas SR-IOV está disponível em neutrões e permite que as VMs acessem a rede através de funções virtuais SR-IOV.	osp16_setIpLink.yml
Etapa 14.	watchdog	Nesta etapa, a configuração da IPMI no nó direcionador é configurada para tarefas de gerenciamento em todos os servidores em conexões fora de banda.	osp16_config_ipmi_watchdog.yml
Etapa 15.	rio geloweather forecast	Atualize o driver ICE Intel E810 para placas PCI (Peripheral Component Interconnect) para a versão 1.12.6 para EPDG para usar as portas NIC Intel como SR-IOV.	osp16_ice_driver_install.yml
Etapa 16.	reinicialização	Reinicialize todos os nós Overcloud após a execução das etapas anteriores.	osp16_reboot_overcloud_hosts.yml
Etapa 17.	verifyrhosp	Verifique a configuração e a integridade da implantação do RHOSP.	osp16_rhosp_verify.yml

Para o provisionamento de nós Overcloud, o Undercloud usa 'overcloud-hardened-uefi-full.qcow2'. Assim, antes de iniciar a implantação de Overcloud, a imagem deve ser armazenada no caminho designado em undercloud/diretor.

Copie o arquivo qcow2 Overcloud do site remoto.

# su - stack
# cd /home/stack
# mkdir deliverymedia
# cd deliverymedia

### Copy overcloud-hardened-uefi-full.qcow2 to deliverymedia ###
# scp overcloud-hardened-uefi-full.qcow2 stack@[Director-IP]:/home/stack/deliverymedia
[stack@[stack@ Undercloud ~]$ cd /home/stack/ansible/
[stack@[stack@ Undercloud ansible]$ ansible-playbook osp16_auto_overcloud_deploy.yml -e podname=POD_NAME –tags= TAG

For Ex –
# ansible-playbook -i hosts osp16_auto_overcloud_deploy.yml  -e podname=<> --tags=genpodvars
# ansible-playbook -i hosts osp16_auto_overcloud_deploy.yml  -e podname=<> --tags=geninstack
# ansible-playbook -i hosts osp16_auto_overcloud_deploy.yml  -e podname=<> --tags=cimcvd
# ansible-playbook -i hosts osp16_auto_overcloud_deploy.yml  -e podname=<> --tags=preocdeploy
# ansible-playbook -i hosts osp16_auto_overcloud_deploy.yml  -e podname=<> --tags=importnodes
# ansible-playbook -i hosts osp16_auto_overcloud_deploy.yml  -e podname=<> --tags=gentemplates
# ansible-playbook -i hosts osp16_auto_overcloud_deploy.yml  -e podname=<> --tags=ocdeploy

#### Push & Update the rootCA.pem in all the Controllers & Computes ####
# for node in $(nova list | grep -i active | awk '{print $12}' | awk -F "=" '{print $2}' ); do scp -o StrictHostKeyChecking=no rootCA.pem heat-admin@[$node]:/home/heat-admin; ssh heat-admin@$node " sudo mv /home/heat-admin/rootCA.pem /etc/pki/ca-trust/source/anchors/ ; sudo chown root:root /etc/pki/ca-trust/source/anchors/rootCA.pem ; sudo update-ca-trust"; echo "" ; done

#### Append the Director Entry in "/etc/hosts" file ########
# for node in $(nova list | grep -i active | awk '{print $12}' | awk -F "=" '{print $2}' ); do ssh -o StrictHostKeyChecking=no heat-admin@$node "hostname; echo '2405:200:1412:9999::1:217  gujrjmngdcurp101co.qalabs.com gujrjmngdcurp101co' | sudo tee -a /etc/hosts" echo "" ; done

# ansible-playbook -i hosts osp16_auto_overcloud_deploy.yml  -e podname=<> --tags=geninventory
# ansible-playbook -i hosts osp16_auto_overcloud_deploy.yml  -e podname=<> --tags=offlinerepo
# ansible-playbook -i hosts osp16_auto_overcloud_deploy.yml  -e podname=<> --tags=fencing

### In case of Fencing Failures, please check the reachability of CIMC Subnet from Controllers ######

## If CIMC Subnet is not pinging, Do add the static Route ###
# ip -6 route add <CIMC Subnet> via <Provisioning Subnet>
Ex: ip -6 route add 2405:XXXX:YYY:9999::/64 via 2405:XXXX:YYY:9999:1

# ansible-playbook -i hosts osp16_auto_overcloud_deploy.yml  -e podname=<> --tags=raidcache
# ansible-playbook -i hosts osp16_auto_overcloud_deploy.yml  -e podname=<> --tags=dnfupdate
# ansible-playbook -i hosts osp16_auto_overcloud_deploy.yml  -e podname=<> --tags=setiplink
# ansible-playbook -i hosts osp16_auto_overcloud_deploy.yml  -e podname=<> --tags=watchdog
# ansible-playbook -i hosts osp16_auto_overcloud_deploy.yml  -e podname=<> --tags=icedriver
# ansible-playbook -i hosts osp16_auto_overcloud_deploy.yml  -e podname=<> --tags=reboot
# ansible-playbook -i hosts osp16_auto_overcloud_deploy.yml  -e podname=<> --tags=verifyrhosp

Para monitorar os logs de implantação, use o arquivo de log mais recente.

# tail -F </home/stack/autologs/osp16_auto_overcloud_deploy_*.log>

Verifique se todas as 17 etapas foram aprovadas.

Falha nas verificações => A contagem deve ser 00.

Logs => /home/stack/autologs/osp16_rhosp_verify.yml _20200703T042257.log

#====================================================================================================================

# ETAPA   | MARCA            | DESCRIÇÃO                                              | MANUAL

#====================================================================================================================

# etapa1  | genpodvars     | Gerar arquivos de variáveis específicas do POD                     | osp16_generate_pod_specific_vars.yml -e podname=

# etapa2  | geninstack     | Gerar arquivo JSON Instackenv                            | osp16_generate_instackenv.yml -e podname=

# etapa3  | cimcvd         | Configurar VDs do CIMC                                       | osp16_cimc_vd_configure.yml

# etapa4  | pré-implantação    | Configurar Implantação Pré-Overcloud                           | osp16_pre_overcloud_deploy.yml

# etapa 5  | importnodes    | Importar Nós Irônicos Openstack Baremetal                  | osp16_import_ironic_nodes.yml

# etapa6  | gentemplates   | Gerar modelos personalizados                                | osp16_generate_custom_templates.yml

# etapa7  | Ocdeploy       | Implantação Do Openstack Overcloud                               | osp16_overcloud_deploy.yml

# etapa8  | geninventory   | Gerar arquivo de inventário                                  | osp16_build_inventory_v3.py — ipmipass

# etapa9  | Oflinerepo    | Configurar o Overcloud Offline Repo a partir do Arquivo TAR Offline   | osp16_config_offline_repo.yml

# etapa10 | Esgrima        | Pós-implantação MOP antes da reinicialização - Configurar zoneamento        | osp16_config_fencing.yml

# etapa11 | cache RAID      | Pós-implantação do MOP antes da reinicialização - cache Raid e ajuste de PR | osp16_raid_cache_tuning.yml

# etapa12 | dnfupdate      | Pós-Implantar MOP Antes Da Reinicialização - Pacotes De Atualização Dnf      | dnf_update_all_packages.yml

# etapa13 | setiplink      | Pós-implantação MOP antes da reinicialização - Definir VF IP Link Trust ON  | osp16_setIpLink.yml

# etapa14 | cão de guarda       | Pós-implantação do MOP antes da reinicialização - Config IPMI Watchdog     | osp16_config_ipmi_watchdog.yml

# etapa15 | rio gelado      | Pós-implantar MOP antes da reinicialização - Atualizar driver ICE E810   | osp16_ice_driver_install.yml

# etapa16 | reinicialização         | Reinicializar todos os nós Overcloud                               | osp16_reboot_overcloud_hosts.yml

# etapa17 | verifyrhosp    | Verificar a configuração e a integridade da implantação de RHOSP        | osp16_rhosp_verify.yml -e podname=

#====================================================================================================================

TODOS OS HOSTS ACESSÍVEIS

====================================================================================================================

CHEQUES CONCLUÍDOS => 17

CONTROLOS APROVADOS => 17

VERIFICAÇÕES COM FALHA => 00

====================================================================================================================

STATUS GERAL => APROVADO !!

====================================================================================================================

Após a implantação bem-sucedida do Overcloud, verifique se o painel do Horizon está acessível.

Acesso ao Painel do Horizon

Para a URL do painel do horizonte, use 'OS_AUTH URL' em 'overcloudrc'.

Painel do Horizon:

Verificação de Integridade do Cluster RHOSP

### Check OpenStack Services Status ###
# openstack compute service list
# openstack network agent list
# openstack volume service list
# openstack orchestration service list
# openstack identity service list
# openstack endpoint list
# openstack server list
# openstack image list

Summary

O guia de implantação do RHOSP 16.2 fornece instruções passo a passo abrangentes para implantar um ambiente de nuvem OpenStack escalável e pronto para produção usando as ferramentas e metodologias comprovadas da Red Hat. Este guia é adaptado para administradores de sistema e arquitetos de nuvem e se concentra na implantação do RHOSP 16.2 usando o diretor OpenStack, que é baseado no TripleO (OpenStack no OpenStack).

O guia aborda todas as fases críticas da implantação, incluindo:

• Planejamento e pré-requisitos de infraestrutura
• Preparação do ambiente e configuração da rede
• Instalação e configuração em nuvem
• Etapas de implantação e pós-implantação na nuvem
• Opções de escalabilidade de HA, armazenamento e serviços

Este guia é essencial para equipes que buscam uma plataforma de nuvem confiável e de nível empresarial com a integração do ecossistema e suporte da Red Hat.

Histórico de revisões

Revisão	Data de publicação	Comentários
1.0	27-Apr-2026	Versão inicial