Questo documento descrive un framework per l'implementazione di RHOSP su server UCS C220 M6 per il supporto di VPC-DI Cisco.
Cisco raccomanda la conoscenza di Red Hat OpenStack Platform (RHOSP) e la conoscenza di Red Hat Enterprise Linux (RHEL). Inoltre, è necessaria una solida conoscenza dei concetti di virtualizzazione e rete.
Il documento può essere consultato per tutte le versioni software o hardware.
Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.
Questa guida descrive l'integrazione di RHOSP con l'infrastruttura UCS (Unified Computing System), sottolineando la scalabilità, l'affidabilità e l'ottimizzazione delle prestazioni.
Descrive le best practice e utilizza un'automazione basata su script flessibile per l'installazione di OpenStack TripleO, che comprende l'architettura Undercloud e Overcloud.
Utilizzando questa guida all'installazione, le organizzazioni possono ottenere un'infrastruttura cloud ROSP robusta ed efficiente personalizzata per le funzioni VNF (Virtual Packet Core - Distributed Instance) basate su Cisco Virtual Packet Core (VPC-DI).
RHOSP è una soluzione di cloud privato di livello enterprise basata sul progetto open-source OpenStack, integrata e supportata da Red Hat. Consente alle organizzazioni di installare e gestire l'infrastruttura IaaS (Infrastructure-as-a-Service) per macchine virtuali (VM), reti e storage su richiesta.
Offre funzionalità quali alta disponibilità (HA, High Availability), virtualizzazione delle funzioni di rete e installazioni personalizzabili.
Il RHOSP è basato principalmente sul progetto TripleO OpenStack. Openstack utilizza Director come set di strumenti per l'installazione e la gestione di un ambiente RHOSP completo.
RHOSP è progettato per fornire un'infrastruttura cloud scalabile e flessibile. La sua architettura è costituita da due componenti principali: Undercloud e Overcloud.

L'undercloud è il nodo di gestione principale che contiene il set di strumenti del director RHOSP. Si tratta di un'installazione OpenStack a sistema singolo che include componenti per il provisioning e la gestione dei nodi OpenStack che formano l'ambiente OpenStack (overcloud).
L'undercloud utilizza i componenti OpenStack come set di strumenti di base. Ciascun componente opera all'interno di un contenitore separato sul subcloud:
L'overcloud è l'ambiente RHOSP risultante creato utilizzando l'undercloud. Sono inclusi diversi ruoli dei nodi definiti in base all'ambiente OpenStack Platform (OSP) che il cliente intende creare.
I nodi di controller forniscono amministrazione, rete e disponibilità elevata per l'ambiente OpenStack. Un ambiente OpenStack consigliato contiene tre nodi Controller in un cluster HA.
I nodi di elaborazione forniscono risorse di elaborazione per l'ambiente OpenStack. I nodi di elaborazione possono essere scalabili in base ai requisiti di rete nel tempo. Un nodo di calcolo predefinito contiene i seguenti componenti:
I nodi di storage forniscono storage per l'ambiente OpenStack.
Nota: Sono disponibili diversi approcci per l'installazione di Undercloud/Director e Repository offline (REPO) nella rete del Cliente; è possibile installarli direttamente su un nodo baremetrico o come VM su un hypervisor KVM. Nella guida all'installazione corrente, il server UCS Director ospita KVM (Hypervisor) per l'installazione di più VM. Il nodo RHOSP Director e i nodi Offline-REPO vengono implementati come VM su hypervisor KVM.
Redhat fornisce un'utility chiamata reposync che può essere utilizzata per scaricare i pacchetti dal Content Delivery Network (CDN). Per scaricare tutti i pacchetti da un canale specifico, il sistema deve essere abbonato a quel canale. Se il sistema non è sottoscritto al canale richiesto, reposync non è in grado di scaricare e sincronizzare tali pacchetti sul sistema locale.
I repository sono configurati in /etc/yum.repos.d/ percorso da file che terminano con l'estensione .repo. È possibile definire più repository nello stesso file.
Il servizio di rete (neutron) è il componente di rete definito dal software (SDN) di RHOSP. Il servizio di rete RHOSP gestisce il traffico interno ed esterno da e verso le istanze VM e fornisce servizi di base come routing, segmentazione, DHCP e metadati. Fornisce l'API per le funzionalità di rete virtuale e la gestione di switch, router, porte e firewall.
Il director RHOSP mappa i servizi OpenStack su diverse reti isolate. Le reti che trasportano ciascun tipo di traffico sono: Cisco Integrated Management Controller (CIMC), provisioning, API interna, dati di archiviazione, gestione dello storage, tenant e esterno (SSH (Secure Shell) e operazioni, amministrazione e manutenzione (OAM)).
L'implementazione RHOSP utilizza diverse porte fisiche dei server Cisco UCS C220 M6 per diversi scopi di connettività.

| Numero di serie |
Porte fisiche |
Dettagli |
| 1. |
CIMC |
CIMC fornisce connettività fuori banda per il provisioning e la gestione dei server. |
| 2. |
Single Root I/O Virtualization (SR-IOV)/Peripheral Component Interconnect Express (PCIe) |
La scheda di interfaccia di rete (NIC, Network Interface Card) PCIe viene utilizzata sui nodi di elaborazione per le reti DI-internal e di servizio per il VNF. |
| 3. |
Lan modulare su scheda madre (MLOM) |
Le porte MLOM sono configurate come collegamenti. osp_external, osp_internal, osp_tenant, osp_external, osp_storage_data, osp_storage_mgmt utilizza la porta MLOM per le comunicazioni interne. |
| 4. |
Lan on MotherBoard (LOM) |
Il director utilizza le porte LOM1 e LOM2, mentre i computer e i controller utilizzano solo la porta LOM1. LOM1 viene utilizzato per distribuire o effettuare il provisioning di Openstack su tutti i server. LOM2 viene utilizzato come OAM (External Network) sul director. |
Il diagramma mostra la connettività fisica con i server.

La rete RHOSP dispone di più subnet che forniscono servizi diversi all'interno del cloud.

CIMC è l'interfaccia IPMI (Intelligent Programming Management Interface) che controlla la gestione di tutti i server UCS. Questa rete CIMC è configurata sulla porta CIMC autonoma di tutti i server UCS.
Questa rete è responsabile del provisioning e della gestione dell'avvio PXE (Preboot Execution Environment) dei computer e dei server controller durante l'installazione di Overcloud, nonché per ottenere l'indirizzo IP DHCP. Per semplicità e compatibilità, la rete di provisioning è configurata come VLAN nativa sulla porta LOM1 di tutti i server UCS. Questa rete di provisioning è responsabile dell'installazione del cloud su tutti i server.
A causa della virtualizzazione sul server Director, è necessario creare una rete bridge sullo switch KVM affinché la VM Director possa comunicare con gli altri server.
La rete API interna viene utilizzata per la comunicazione tra i servizi OpenStack come neutron, nova, keystone e così via.
La rete OSP_Internal è configurata su porte MLOM collegate sui nodi Controller e Compute.
La rete tenant viene creata per impostazione predefinita nei progetti cloud per la gestione VNF. Nell'installazione corrente, per la distribuzione VNF viene creato solo il progetto OpenStack singolo.
La rete OSP_Tenant è configurata su porte MLOM collegate sui nodi Controller e Compute.
La rete esterna viene utilizzata per tutte le reti di accesso esterno (ad esempio SSH) e API.
La rete OSP_External è configurata sulla porta LOM2 sul nodo Director e sulle porte MLOM collegate sui nodi Controller e Compute.
La rete OSP_Storage viene utilizzata per tutte le operazioni correlate all'accesso allo storage. Questo è necessario per la comunicazione tra il servizio CEPH e VNF che hanno bisogno di accedere allo storage. Viene utilizzato da Controller, Nodi di calcolo e CEPH.
La rete OSP_Storage_Data è configurata su porte MLOM collegate sui nodi Controller e Compute.
OpenStack Object Storage utilizza questa rete per sincronizzare gli oggetti dati tra i nodi di replica partecipanti nel cluster di archiviazione, formati tra i nodi di elaborazione dei controller.
La rete OSP_Storage_Mgmt è configurata su porte MLOM collegate sui nodi Controller e Compute.
Il diagramma mostra come le reti logiche subcloud sono connesse a ciascun tipo di nodi nel cluster RHOSP.

Esistono diversi metodi per l'installazione di Undercloud/Director e Offline REPO nella rete del cliente. Questi possono essere installati direttamente su un nodo bare-metal o come VM in esecuzione su un hypervisor KVM.
Nella guida all'installazione corrente, il server UCS Director è configurato per ospitare l'hypervisor KVM, che semplifica la creazione di più VM. Il nodo RHOSP Director e il nodo Offline REPO vengono implementati come VM su questo hypervisor KVM.
Nota: Per installare l'hypervisor KVM è necessario seguire le procedure di installazione KVM RHEL standard.
br-prov : eth0
br-ext eth1
I bridge devono essere creati tramite l'interfaccia utente di testo (NMTUI) di Network Manager.
# dnf install qemu-kvm libvirt virt-install virt-manager virt-viewer libguestfs-tools

# mkdir /data # mkdir /data/offlineRepos # mkdir /data/isoImages # mkdir /data/qcow2Images # mkdir /data/images # 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/
# mount -t iso9660 -o loop /data/isoImages/rhel-8.4-x86_64-dvd.iso /mnt/iso
# 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/
# dnf repolist

$ 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

$ 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

# 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


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

Il server REPO deve essere registrato con la rete CDN Redhat e deve disporre del repository di tutti i pacchetti disponibili di RHOSP 16.2 necessari per la distribuzione. I pacchetti RHEL RPM e le immagini contenitore RHOSP devono essere scaricate nella VM REPO utilizzando il proxy.
RHOSP 16.2 viene implementato nella rete del cliente tramite automazione. Gli script ansibili vengono utilizzati per automatizzare l'installazione di Undercloud e Overcloud.
Passaggi da seguire prima di avviare l'effettiva distribuzione cloud:
# cd /home
# mkdir cisco
# cd /home/cisco
# mkdir automation
# cd /home/cisco/automation
La funzione Tarball è costituita da tre strutture di directory delle cartelle, denominate come:
4. Installare il pacchetto sshpass. sshpass è un'utilità della riga di comando utilizzata per fornire password al protocollo ssh in modo non interattivo. Viene utilizzato principalmente in scenari di script o automazione in cui non è possibile immettere manualmente la password.
# yum install gcc
# yum install make
# tar -xvzf sshpass.tar.gz
# cd sshpass-1.10/
# ./configure
# sudo make install
# sshpass -V
5. Il processo di installazione della directory richiede un utente non root per eseguire i comandi. L'utente 'Stack' deve essere creato in Director VM con accesso 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. Copiare il file rootCA.crt dal server REPO alla macchina virtuale Director e allo switch KVM nel percorso specificato. Inoltre, aggiornare il certificato della macchina virtuale REPO nell'elenco di attendibilità.
# /etc/pki/ca-trust/source/anchors
# update ca-trust
7. Aggiornare i dettagli relativi al nome host del server REPO locale nel file in /etc/hosts di Director VM e KVM.
8. Su KVM e Director VM, installare pacchetti aggiuntivi come python, ansible e così via per eseguire script di automazione andibili.
# dnf install python3 python3-devel ansible httpd -y
# update-alternatives --set python /usr/bin/python3
9. La subnet CIMC deve essere raggiungibile dalla rete di provisioning di Director per abilitare il provisioning durante l'installazione del cloud. Se necessario, aggiungere la route statica per la stessa.
# ip -6 route add <CIMC Subnet> via <Provisioning Subnet>
10. In KVM e Director VM, creare un file host nella cartella /ansible e aggiungere i dettagli specifici dello stack, se necessario.
[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. Verificare che tutti i playbook e i file di input analizzabili siano conservati nella cartella /home/stack di Director VM.
È presente un file di variabile di input costituito da dettagli specifici della rete del cliente che devono essere preparati per l'installazione del cloud.
Percorso: /home/cisco/automation/ansible/podvars
Nome file: <nome-stack>_vars.yml
Aggiornare i parametri evidenziati in base al piano IP specifico del sito/documento di progettazione di basso livello.
Nota: Gli indirizzi IP fittizi vengono utilizzati solo a scopo di rappresentazione.
# #############################
# 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
# ##################################
Undercloud viene distribuito utilizzando gli script ansibili in sette passaggi. Tutti i passaggi devono essere eseguiti da un host KVM che in questo caso funge da host di collegamento.
| Passaggio |
Contrassegno |
Descrizione |
YAML playbook |
| Passaggio 1. |
file di controllo |
Verificare playbook, script e RPM richiesti su OpenStack Platform Director (OSPD). |
osp16_published_playbooks_verifica.yml |
| Passaggio 2. |
genpodvar |
Generare file di variabili specifiche del POD correlati a hardware, RHEL e così via, ad esempio common_vars.yml (hardware, software, dettagli di rete), hw_m6_vars.yaml (CPU, memoria, hugepages, disco, NIC e così via), rhel_84_vars.yml (RHEL, kernel, driver ICE, versione NIC), pf_esc_vars.yml (dettagli ESC (Elastic Services Controller))), osp_16_vars.yml (versione OSP, fuso orario, tipo IP, ID VLAN, IP, dettagli neutroni). |
osp16_generate_pod_specific_vars.yml |
| Passaggio 3. |
preucdeploy |
Configurare FQDN (Fully Qualified Domain Name), NTP (Network Time Protocol) e aggiornare tutti i pacchetti nel nodo della directory. |
osp16_pre_undercloud_deploy.yml |
| Passaggio 4. |
primo riavvio |
Esegue il primo riavvio del nodo della directory Undercloud dopo la configurazione e l'installazione del pacchetto precedenti. |
osp16_undercloud_deploy.yml |
| Passaggio 5. |
disinstallazione |
Installa stack undercloud su director |
osp16_undercloud_tuning.yml |
| Passaggio 6. |
cstate |
Configurare le impostazioni dello stato C della CPU del BIOS sul nodo della directory. |
osp16_cstate.yml |
| Passaggio 7. |
riavvio secondario |
Secondo riavvio dopo modifiche del BIOS sul director Undercloud. |
N/D |
Il file con nome osp16_auto_undercloud_deploy.yml è un playbook principale che può essere eseguito in una singola iterazione, ma è consigliabile eseguire il playbook in modo graduale utilizzando tag diversi per facilitare la risoluzione dei problemi in caso di problemi di distribuzione.
# 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
Overcloud viene implementato con almeno tre controller in modalità HA e un computer. Overcloud viene distribuito utilizzando script ansibili in 17 passaggi. Tutti i passi devono essere eseguiti da Director-VM che, in questo caso, funge da host di collegamento.
| Passaggio |
Contrassegno |
Descrizione |
YAML playbook |
| Passaggio 1. |
genpodvar |
Generare file di variabili specifiche del POD per Overcloud relativi a hardware, RHEL e così via, come common_vars.yml (hardware, software, dettagli di rete), hw_m6_vars.yaml (CPU, memoria, hugepages, disco, NIC e così via), rhel_84_vars.yml (RHEL, kernel, driver ICE, versione NIC), pf_esc_vars.yml (dettagli ESC), osp_16_vars.yml (versione OSP timezone, tipo di IP, ID VLAN, IP, dettagli neutroni). |
osp16_generate_pod_specific_vars.yml |
| Passaggio 2. |
geninstack |
Generare il file JSON Instackenv da /var/common_vars.yml creato nel passaggio precedente. La directory richiede un modello di definizione del nodo, che viene creato manualmente. Il file instackenv.json utilizza il formato JSON e contiene tutti i dettagli relativi all'hardware e al risparmio energia per i nodi. Questa procedura consente inoltre di convalidare la configurazione hardware sul server UCS prima di generare il file. |
osp16_generate_instackenv.yml |
| Passaggio 3. |
cimcvd |
Configurare l'impostazione CIMC e i dischi virtuali (VD) su ciascun server che fa riferimento a common_vars.yml, hw_m6_vars.yaml e rhel_84_vars.yml. |
osp16_cimc_vd_configure.yml |
| Passaggio 4. |
predistribuzione |
In questo passaggio vengono eseguiti tutti i prerequisiti per la distribuzione di Overcloud. Imposta l'FQDN, l'NTP e aggiorna tutti i pacchetti, quindi esegue il push dell'immagine nel percorso per la distribuzione. |
osp16_pre_overcloud_deploy.yml |
| Passaggio 5 |
importonodi |
In questo passaggio vengono introdotti la CPU del server, la memoria, la scheda NIC e l'interfaccia e le porte sugli switch di rete. L'introspezione viene eseguita sugli switch di rete collegati per tutti i controller e i computer. |
osp16_import_ironic_nodes.yml |
| Passaggio 6. |
modelli |
Generare file modello personalizzati per controller e computer. Nel modello personalizzato, definire i ruoli di controller e calcolo per tutti i servizi in esecuzione su di essi. Consente inoltre di rendere più sicuro il sistema applicando certificati, route e così via. |
osp16_generate_custom_templates.yml |
| Passaggio 7. |
ocdeploy |
In questo passaggio viene eseguita una distribuzione di Openstack Overcloud. Eseguire deploy.sh fornito da Red Hat per la distribuzione di RHOSP. |
osp16_overcloud_deploy.yml |
| Passaggio 8 |
geninventario |
In questo passaggio viene generato un file con il codice di inventario utilizzabile da ansible in cui l'indirizzo IP di provisioning, l'indirizzo IP di IPMI (CIMC) e le credenziali vengono archiviati e mappati con il controller e i computer per consentire l'accesso automatico al sistema ed eseguire i passaggi successivi. |
osp16_build_inventory_v3.py |
| Passaggio 9. |
offlinerepo |
Configurare Overcloud Offline REPO nel file /etc/yum.repo.d/offline.repo che punta al server repo tramite la rete esterna. |
osp16_config_offline_repo.yml |
| Passaggio 10. |
recinzione |
Configurare la schermatura su tutti i nodi di controller con Shoot The Other Node In The Head (una tecnica di schermatura nei cluster HA) (STONITH). |
osp16_config_recinzione.yml |
| Passaggio 11. |
raidcache |
Configurare l'impostazione della cache RAID per tutti i controller e i computer e configurare anche le impostazioni di archiviazione SWIFT. |
osp16_raid_cache_tuning.yml |
| Passaggio 12. |
dnfupdate |
Eseguire aggiornamenti DNF per tutti i pacchetti in tutti i nodi. |
dnf_update_all_packages.yml |
| Passaggio 13. |
setiplink |
In questo passaggio, il controllo della modalità di attendibilità per le porte SR-IOV è abilitato per il traffico dati e interno di Evolved Packet Data Gateway (EPDG). Il supporto per le porte SR-IOV è disponibile in neutroni e consente alle VM di accedere alla rete tramite le funzioni virtuali SR-IOV. |
osp16_setIpLink.yml |
| Passaggio 14. |
watchdog |
In questo passaggio, l'impostazione IPMI sul nodo del director è configurata per l'attività di gestione su tutti i server tramite connessione fuori banda. |
osp16_config_ipmi_watchdog.yml |
| Passaggio 15. |
icedriver |
Aggiornare il driver Intel E810 ICE per schede PCI (Peripheral Component Interconnect) alla versione 1.12.6 per EPDG in modo da utilizzare le porte NIC Intel come SR-IOV. |
osp16_ice_driver_install.yml |
| Passaggio 16. |
riavviare |
Riavviare tutti i nodi di overcloud dopo l'esecuzione dei passaggi precedenti. |
osp16_reboot_overcloud_hosts.yml |
| Passaggio 17. |
verifica |
Verificare la configurazione e l'integrità della distribuzione RHOSP. |
osp16_rospo_verifica.yml |
Per il provisioning dei nodi Overcloud, Undercloud utilizza 'overcloud-hardened-uefi-full.qow2'. Pertanto, prima di iniziare l'installazione di Overcloud, l'immagine deve essere archiviata nel percorso indicato in undercloud/director.
Copiare il file qws2 Overcloud dal sito 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
Per monitorare i log di distribuzione, utilizzare il file di log più recente.
# tail -F </home/stack/autologs/osp16_auto_overcloud_deploy_*.log>
Verificare che tutti i 17 passaggi siano stati completati.
Controlli non riusciti => Il conteggio deve essere 0.
Log => /home/stack/autologs/osp16_rhosp_verify.yml _20200703T042257.log
#==================================================================================================================
N. FASE TAG | | DESCRIZIONE PLAYBOOK |
#==================================================================================================================
# passaggio1 | genpodvar | Genera file di variabili specifiche del POD | osp16_generate_pod_specific_vars.yml -e nomepod=
# passaggio2 | geninstack | Genera file JSON Instackenv | osp16_generate_instackenv.yml -e nomepod=
# passaggio 3 | cimcvd | Configurazione di VD CIMC | osp16_cimc_vd_configure.yml
# passaggio4 | prelocalizzazione | Configura distribuzione pre-overcloud | osp16_pre_overcloud_deploy.yml
# passaggio 5 | importnodi | Importa Nodi Ironici Baremetrici Openstack | osp16_import_ironic_nodes.yml
# passaggio6 | modelli gentili | Genera modelli personalizzati | osp16_generate_custom_templates.yml
# passaggio7 | ocdeploy | Distribuzione Openstack Overcloud | osp16_overcloud_deploy.yml
# passaggio8 | geninventario | Genera file di inventario | osp16_build_inventory_v3.py —ipmipass
# passaggio9 | eropoffline | Configurare il repository offline di Overcloud dal file TAR offline | osp16_config_offline_repo.yml
n. passaggio10 | recinzioni | Post-distribuire il MOP prima del riavvio - Configurare la restrizione | osp16_config_recinzione.yml
n. passaggio11 | raidcache | Post-distribuire MOP prima del riavvio - Cache Raid e tuning PR | osp16_raid_cache_tuning.yml
n. passaggio12 | dnfupdate | Post Deploy MOP Before Reboot - Pacchetti di aggiornamento DNF | dnf_update_all_packages.yml
n. passaggio13 | setiplink | Post Deploy MOP Before Reboot - Imposta attendibilità collegamento IP VF ON | osp16_setIpLink.yml
n. passaggio14 | watchdog | Post-distribuire MOP prima del riavvio - Configura watchdog IPMI | osp16_config_ipmi_watchdog.yml
n. passaggio15 | fiume icedriver | Post Deploy MOP Before Reboot - Aggiorna il driver ICE E810 | osp16_ice_driver_install.yml
n. passaggio16 Riavvio | | Riavvia tutti i nodi di overcloud | osp16_reboot_overcloud_hosts.yml
n. passaggio17 | verifirrospo | Verifica della configurazione e dell'integrità dell'installazione di RHOSP | osp16_rhosp_verify.yml -e nomepod=
#==================================================================================================================
TUTTI GLI HOST RAGGIUNGIBILI
============================================================================================
CONTROLLI ESEGUITI => 17
CONTROLLI SUPERATI => 17
CONTROLLI NON RIUSCITI => 0
============================================================================================
STATO COMPLESSIVO => SUPERATO!!
============================================================================================
Dopo la corretta distribuzione di Overcloud, verificare che il dashboard Orizzonte sia accessibile.
Per l'URL del dashboard dell'orizzonte, utilizzare 'OS_AUTH URL' da 'overcloud'.

Dashboard orizzonte:

### 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
La guida all'installazione di RHOSP 16.2 fornisce istruzioni complete e dettagliate per l'installazione di un ambiente cloud OpenStack scalabile e pronto per la produzione utilizzando gli strumenti e le metodologie collaudate di Red Hat. Questa guida è personalizzata per gli amministratori di sistema e gli architetti cloud e si concentra sull'installazione di RHOSP 16.2 mediante il director OpenStack, basato su TripleO (OpenStack su OpenStack).
La guida copre tutte le fasi critiche dell'installazione, tra cui:
Questa guida è essenziale per i team alla ricerca di una piattaforma cloud affidabile di classe enterprise con l'integrazione dell'ecosistema e il supporto di Red Hat.
| Revisione | Data di pubblicazione | Commenti |
|---|---|---|
1.0 |
27-Apr-2026
|
Versione iniziale |