Contents

Introdução

Pré-requisitos

Requisitos

Componentes Utilizados

Informações de Apoio

Entendendo o RHOSP

Arquitetura RHOSP

Subnuvem

Componentes do Undercloud

Overcloud

Controlador

Computação

Armazenamento

Repositório local (servidor do REPO)

Rede RHOSP

Conectividade física RHOSP

Conectividade lógica RHOSP

Ajuste de parâmetro de hardware

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

Criação do REPO e do Diretor VM

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

Criação de VM do REPO

Criação de VM do Diretor

Criação de REPO offline local

Implantação de nuvem RHOSP

Pré-requisitos

Atualização dos arquivos de entrada

Implantação de subnuvem

Implantação de Overcloud

Acesso ao Painel do Horizon

Verificação de Integridade do Cluster RHOSP

Summary

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 principal nó de gerenciamento 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 em um contêiner separado no Undercloud:

- 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.

Note: Há várias abordagens para a implantação do Undercloud/Diretor e do Repositório Offline (REPO) na rede do cliente - pode ser implantado diretamente no nó baremetal ou como VM no hipervisor KVM. No guia de implantação atual, o servidor Diretor UCS hospeda o KVM (Hypervisor) para implantar várias VMs. O nó RHOSP Diretor e os nós Offline-REPO são implantados como VM no hipervisor KVM.

Repositório local (servidor do REPO)

A Red Hat fornece um utilitário chamado reposync que pode ser usado para baixar os pacotes da Rede de Fornecimento de Conteúdo (CDN). 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 próximo 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, é necessário criar uma rede de ponte no KVM para a VM Diretor para se comunicar 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, somente um único projeto Openstack é criado para a implantação do 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.

Note: As etapas de instalação padrão do KVM RHEL devem ser observadas para implantar o 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.

Instalar os pacotes libvirt & qemu

- 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

Repolista

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

Personalização de imagem RHEL

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

Mapeamento do sistema de arquivos

- Criar a imagem do servidor do REPO.

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

Criação de imagem do Repo

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

Instalação do Repo

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

Criação de imagem do Repo

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

Acordo de recompra do PSO Guestfish

$ osinfo-query os | grep rhel8

Pacotes RHEL

$ 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

Instalação do servidor do Repo

$ virsh list --all

Status do servidor do repositório

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

Criação de imagem do Diretor

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

virt-resize de /dev/sda3

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

Criação de imagem do Diretor

# 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

Criação de VM do Diretor

# virsh list --all

Criação de VM do Diretor

Instalação do Diretor VM

- 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.

Configuração de rede do Diretor

Criação de REPO offline local

O servidor do REPO deve ser registrado com o Red Hat 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 observadas 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.

Note: Os endereços IP fictícios são usados apenas para fins de representação.

# #############################

# 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: '<stack name>'

# OSPD full hostname

fqdn_hostname: '<stack name>.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: '<Cloud-name>.<domain-name>',

port: '5000',

container_tag: '16.2.6',

user: 'ciscoadmin',

password: '******'

}

# Custom cloud domain details

domain_name: {

domain: '<domain-name>',

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 em caso de problemas 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

Etapa 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 aponte para o servidor 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 a fim de 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'. Portanto, 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'.

criação de arquivo 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.