Implementatiegids van RHOSP op UCS voor werkbelasting voor mobiliteit in niet-verbonden modus

Inleiding

In dit document wordt een kader beschreven voor de implementatie van RHOSP op C220 M6 UCS-servers ter ondersteuning van Cisco VPC-DI.

Voorwaarden

Vereisten

Cisco beveelt aan dat u kennis hebt van Red Hat OpenStack Platform (RHOSP) en over sterke vaardigheden beschikt in Red Hat Enterprise Linux (RHEL). Daarnaast is een goed begrip van virtualisatie- en netwerkconcepten vereist.

Gebruikte componenten

Dit document is niet beperkt tot specifieke software- en hardware-versies.

De informatie in dit document is gebaseerd op de apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk live is, moet u zorgen dat u de potentiële impact van elke opdracht begrijpt.

Achtergrondinformatie

In deze handleiding wordt de integratie van RHOSP met de UCS-infrastructuur (Unified Computing System) beschreven, waarbij de nadruk ligt op schaalbaarheid, betrouwbaarheid en prestatieoptimalisatie.

Het beschrijft best practices en maakt gebruik van ansible script-based automation voor de implementatie van OpenStack TripleO, bestaande uit Undercloud- en Overcloud-architectuur.

Met deze implementatiegids kunnen organisaties een robuuste en efficiënte RHOSP-cloudinfrastructuur realiseren die is afgestemd op Cisco Virtual Packet Core - Distributed Instance (VPC-DI)-gebaseerde Mobility Virtual Network Functions (VNF).

RHOSP begrijpen

RHOSP is een enterprise-grade private cloud-oplossing gebouwd op het open-source OpenStack-project, geïntegreerd en ondersteund door Red Hat. Hiermee kunnen organisaties Infrastructure-as-a-Service (IaaS) voor virtuele machines (VM's), netwerken en opslag op aanvraag implementeren en beheren.

Het biedt functies zoals High Availability (HA), netwerkfuncties, virtualisatie en aanpasbare implementaties.

RHOSP-architectuur

De RHOSP is voornamelijk gebaseerd op het OpenStack TripleO-project. Openstack maakt gebruik van Director die fungeert als een toolset voor het installeren en beheren van een complete RHOSP-omgeving.

RHOSP is ontworpen om een schaalbare en flexibele cloudinfrastructuur te bieden. De architectuur bestaat uit twee hoofdcomponenten: Undercloud en Overcloud.

onderbewolken

De Undercloud is de belangrijkste beheernode die de RHOSP director toolset bevat. Het is een OpenStack-installatie met één systeem die componenten bevat voor provisioning en beheer van de OpenStack-knooppunten die de OpenStack-omgeving vormen (de Overcloud).

Onderwolkcomponenten

De Undercloud maakt gebruik van OpenStack-componenten als basisgereedschapsset. Elk onderdeel werkt binnen een aparte container op de Undercloud:

• OpenStack Identity (keystone) - Biedt verificatie en autorisatie voor de directeurscomponenten
• OpenStack Bare Metal (ironisch) - Beheert kale metalen knooppunten
• OpenStack Networking (neutron) en Open vSwitch - Controle netwerken voor kale metalen knooppunten
• OpenStack Orchestration (Ephemeral Heat) - Biedt de orkestratie van knooppunten nadat de regisseur de Overcloud-afbeelding op schijf heeft geschreven

overbewolken

De Overcloud is de resulterende RHOSP-omgeving die is gemaakt met behulp van de undercloud. Dit omvat verschillende knooppuntrollen die zijn gedefinieerd op basis van de OpenStack Platform (OSP)-omgeving die de klant wil creëren.

controleur

Controllerknooppunten bieden beheer, netwerken en HA voor de OpenStack-omgeving. Een aanbevolen OpenStack-omgeving bevat drie controllerknooppunten samen in een HA-cluster.

berekenen

Compute nodes bieden computerbronnen voor de OpenStack-omgeving. Compute nodes kunnen scale-in/scale-out zijn op basis van de netwerkvereisten in de loop van de tijd. Een standaard compute node bevat de volgende componenten:

• OpenStack Compute (nova)
• Kernel-gebaseerde VM (KVM)/Quick Emulator (QEMU)
• vSwitch openen

opslag

Opslagknooppunten bieden opslag voor de OpenStack-omgeving.

Lokale repository (REPO-server)

Red Hat biedt een hulpprogramma genaamd reposync dat kan worden gebruikt om de pakketten te downloaden van het Content Delivery Network (CDN). Om alle pakketten van een bepaald kanaal te downloaden, moet het systeem op dat kanaal zijn geabonneerd. Als het systeem niet is geabonneerd op het vereiste kanaal, kan reposync deze pakketten niet downloaden en synchroniseren op het lokale systeem.

Repositories worden geconfigureerd in /etc/yum.repos.d/path door bestanden die eindigen met de extensie .repo. Meerdere repositories kunnen in hetzelfde bestand worden gedefinieerd.

RHOSP-netwerken

De netwerkservice (neutron) is de software-defined networking (SDN) component van RHOSP. De RHOSP-netwerkservice beheert intern en extern verkeer van en naar VM-instanties en biedt kernservices zoals routering, segmentatie, DHCP en metagegevens. Het biedt de API voor virtuele netwerkmogelijkheden en beheer van switches, routers, poorten en firewalls.

RHOSP-directeur koppelt OpenStack-services aan verschillende geïsoleerde netwerken. De netwerken die elk type verkeer vervoeren zijn: Cisco Integrated Management Controller (CIMC), Provisioning, Internal API, Storage Data, Storage Management, Tenant and External (Secure Shell (SSH) en Operations, Administration, and Maintenance (OAM)).

RHOSP fysieke connectiviteit

De RHOSP-implementatie maakt gebruik van verschillende fysieke poorten van Cisco UCS C220 M6-servers voor verschillende connectiviteitsdoeleinden.

serienummer	Fysieke poorten	Details
1.	CIMC	CIMC biedt out-of-band connectiviteit voor serverprovisioning en -beheer.
2.	Single Root I/O Virtualization (SR-IOV)/Peripheral Component Interconnect Express (PCIe)	De PCIe Network Interface Card (NIC) wordt gebruikt op de compute nodes voor de DI-interne en Service netwerken voor de VNF.
3.	Modulair LAN op moederbord (MLOM)	MLOM-poorten worden geconfigureerd als een obligatie. OSP_External, OSP_Internal, OSP_TENANT, OSP_EXTERNAL, OSP_STORAGE_DATA, OSP_STORAGE_MGMT gebruikt de MLOM-poort voor interne communicatie.
4.	LAN op moederbord (LOM)	De directeur gebruikt LOM1- en LOM2-poorten, terwijl computers en controllers alleen LOM1-poorten gebruiken. LOM1 wordt gebruikt om de Openstack op alle servers te implementeren of te leveren. LOM2 wordt gebruikt als OAM (External Network) op de regisseur.

Het volgende diagram toont de fysieke connectiviteit met de servers.

RHOSP logische connectiviteit

Het RHOSP-netwerk heeft meerdere subnetten voor verschillende services binnen de cloud.

• OSP_CIMC:

CIMC is de Intelligent Programming Management Interface (IPMI) die het beheer van alle UCS-servers regelt. Dit CIMC-netwerk is geconfigureerd op de standalone CIMC-poort van alle UCS-servers.

• OSP_provisioning:

Dit netwerk is verantwoordelijk voor de provisioning en Preboot Execution Environment (PXE)-opstartbeheer van de computers en controllerservers tijdens de implementatie van Overcloud en ook voor het verkrijgen van de DHCP IP. Het Provisioning-netwerk is geconfigureerd als Native VLAN op LOM1-poort van alle UCS-servers voor eenvoud en compatibiliteit. Dit provisioningnetwerk is verantwoordelijk voor de implementatie van de cloud op alle servers.

Vanwege virtualisatie op de Director Server moet op de KVM een brugnetwerk voor de Director VM worden gemaakt om met de andere servers te kunnen communiceren.

• OSP_Intern:

Het interne API-netwerk wordt gebruikt voor communicatie tussen de OpenStack-services zoals neutron, nova, keystone, enzovoort.

Het OSP_Internal-netwerk is geconfigureerd op gebundelde MLOM-poorten op controller- en computerknooppunten.

• OSP_Tenant:

Het Tenant-netwerk wordt standaard gemaakt binnen cloudprojecten voor VNF-beheer. In de huidige configuratie wordt slechts één Openstack-project gemaakt voor VNF-implementatie.

Het OSP_Tenant-netwerk is geconfigureerd op gebundelde MLOM-poorten op controller- en computerknooppunten.

• OSP_Extern:

Het externe netwerk wordt gebruikt voor alle externe toegang (zoals SSH) en API-netwerken.

Het OSP_External-netwerk is geconfigureerd op de LOM2-poort op de Director-node en op de aangesloten MLOM-poorten op de Controller- en Compute-nodes.

• OSP_Storage_Data:

Het OSP_Storage-netwerk wordt gebruikt voor alle bewerkingen die verband houden met toegang tot de opslag. Dit is vereist voor communicatie tussen CEPH-service en VNF die toegang tot de opslag nodig hebben. Het wordt gebruikt door Controller, Compute nodes en CEPH.

Het OSP_Storage_Data-netwerk is geconfigureerd op gebundelde MLOM-poorten op controller- en computerknooppunten.

• OSP_Storage_Management:

OpenStack Object Storage gebruikt dit netwerk om gegevensobjecten te synchroniseren tussen deelnemende replicaknooppunten in een opslagcluster, gevormd tussen controller-Compute-knooppunten.

Het OSP_Storage_Management-netwerk is geconfigureerd op gebundelde MLOM-poorten op controller- en computerknooppunten.

Het diagram laat zien hoe de logische netwerken van undercloud verbonden zijn met elk type knooppunten in het RHOSP-cluster.

Hardwareparameterafstemming

• Zorg ervoor dat IP is ingeschakeld en geconfigureerd met het juiste beheeradres volgens het ontwerp.
• Zorg ervoor dat de beheerder en zijn wachtwoord hetzelfde moeten zijn voor alle CIMC-aanmeldingstoegang.
• Zorg ervoor dat de Bootstrap (Boot)-modus is ingesteld op Unified Extensible Firmware Interface (UEFI).
• Zorg ervoor dat u de BIOS-instelling instelt met de aanbevolen parameters.
• Opstartvolgorde instellen op:
  1. LOM-PXE (eno1)
  2. HARDE SCHIJF (HARDE SCHIJF) OPSTARTEN

• Stel het MAC-adres in van LOM1 (eno1).
• Zorg ervoor dat alle UCS/CIMC-servers zijn geüpgraded met de nieuwste aanbevolen firmwareversie.

Hypervisor-KVM-installatie en netwerkcreatie

Er zijn verschillende methoden voor het implementeren van de Undercloud / Director en Offline REPO in het klantennetwerk. Deze kunnen rechtstreeks op een bare-metal node worden geïmplementeerd of als VM's die op een KVM-hypervisor worden uitgevoerd.
In de huidige implementatiegids is de Director UCS-server geconfigureerd om de KVM-hypervisor te hosten, wat het maken van meerdere VM's vergemakkelijkt. De RHOSP Director-node en de Offline REPO-node worden als VM's op deze KVM-hypervisor geïmplementeerd.

• Als de KVM is opgestart, werkt u de hostnaam bij:
  hostnamectl set-hostnaam <hostnaam> --statisch

• Configureer de externe en provisioningbruggen en bind de interfaces.

BR-PROV: ETH0

BR-EXT: ETH1

Deze bruggen moeten worden gemaakt via de Network Manager Text User Interface (NMTUI) GUI.

• Standaard worden eno1- en eno2-poorten gemaakt in KVM voor fysieke LOM1- en LOM2-poorten, en worden deze kruisgeverifieerd met behulp van het MAC-adres van de CIMC-logboekregistratie.
• Maak een bridge-netwerk en voeg slave-poorten toe door het juiste MAC-adres toe te wijzen.
• Zorg ervoor dat de provisioning en externe gateway bereikbaar zijn vanaf de KVM na het maken van een brugnetwerk.

Repo Director en VM maken

Vereisten voor het maken van REPO en VM Director

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

• Installeer de vereiste pakketten in KVM voor REPO en Director VM Creation.

Libvirt & qemu-pakketten installeren

• Maak de vereiste mappen op KVM.
  
  

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

• Kopieer de bestanden naar de mappen.

# 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/

 

• Monteer de ISO op /mnt/ISO.

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

• Maak het REPO-bestand op het pad /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/

 

• Controleer de repolist en zorg ervoor dat de Appstream en Baseos REPO's in kaart zijn gebracht.

# dnf repolist

herpolist

REPO VM maken

$ 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        

Aanpassing RHEL-image

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

Toewijzing van bestandssystemen

• Maak het image van de REPO-server.

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

Repo-image maken

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

Repo-installatie

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

Repo-image maken

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

Guestfish OSP Repo

$ osinfo-query os | grep rhel8

RHEL-pakketten

$ 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

Installatie van repo-server

$ virsh list --all

Status repo-server

Directeur VM maken

• Maak het image van de directeursserver.

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

Creatie van Director-image

# 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-formaat van /dev/sda3

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

Creatie van Director-image

# 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

Directeur VM maken

# virsh list --all

Directeur VM maken

Directeur VM-installatie

• Open een nieuw venster en neem de console-aanmelding van de VM.

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

• Na de implementatie van de Director VM worden twee eth-interfaces eth0 en eth1 gemaakt.
  • eth0 wordt gebruikt voor OSP_provisioning-netwerken, waarbij tijdens de implementatie van Undercloud br-ctlplane-netwerken worden gemaakt.
  • eth1 wordt gebruikt voor externe connectiviteit voor SSH Access. Dus, OSP_external subnet IP-adres wordt toegewezen.

Netwerkconfiguratie van de directeur

Lokale offline REPO-creatie

De REPO-server moet zijn geregistreerd bij Red Hat CDN en moet beschikken over de opslagplaats van alle beschikbare pakketten van RHOSP 16.2 die nodig zijn voor implementatie. RHEL RPM-pakketten en RHOSP-containerafbeeldingen moeten worden gedownload naar REPO VM met behulp van proxy.

Implementatie van RHOSP Cloud

RHOSP 16.2 wordt geïmplementeerd in het klantennetwerk door automatisering. Ansible scripts worden gebruikt om de implementatie van Undercloud en Overcloud te automatiseren.

Voorwaarden

Stappen die in acht moeten worden genomen voordat de daadwerkelijke implementatie van de cloud wordt gestart:

1. Zorgen voor connectiviteit van KVM-knooppunten met lokale REPO VM Director en VM op het OSP_EXT-netwerk.

2. Zorg ervoor dat alle toegankelijke scripts en automatiseringsscripts naar de KVM-host worden geüpload in de aangewezen map.

3. Maak mappen met namen als 'cisco' en 'automation' en zet de tarball van ansible scripts.

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

De tarball bestaat uit drie mapdirectorystructuren, genaamd:

• scripts: bestaat uit shell scripts die worden gebruikt voor baremetale knooppuntconfiguratie.
• rpms: bestaat uit Intel Ethernet Connection (ICE)-stuurprogramma's, Intel-stuurprogramma's en Red Hat Package Manager (RPM)-pakketten.
• ansible: bestaat uit Input vars bestand, ansible yaml bestanden voor implementatie en jinja-sjablonen.

4. Installeer shpass-pakket. shpass is een opdrachtregelhulpprogramma dat wordt gebruikt om wachtwoorden niet-interactief aan ssh te verstrekken. Het wordt voornamelijk gebruikt in scripts of automatiseringsscenario's waarbij handmatige wachtwoordinvoer niet haalbaar is.

• Download shpass pakket shpass.tar.gz van internet/bestaande server.
• Installeer het GNU Compiler Collection (GCC) pakket.

# yum install gcc

• Installeer makpakketten.

# yum install make

• Verwijder het shpass-pakket en installeer SSH-pas.

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

5. Voor het installatieproces van de regisseur is het nodig dat een niet-hoofdgebruiker opdrachten uitvoert. 'Stack'-gebruiker moet worden gemaakt in Director VM met sudo-toegang.

# 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. Kopieer het rootCA.crt-bestand van de REPO-server naar de Director VM en KVM op het opgegeven pad. Werk ook het REPO VM-certificaat bij in de vertrouwenslijst.

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

7. Lokale gegevens van de hostnaam van de REPO-server bijwerken in het Director VM- en KVM-bestand in/etc/hosts.

8. Installeer op KVM en VM Director aanvullende pakketten zoals python, ansible, enzovoort om ansible automation-scripts uit te voeren.

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

9. CIMC-subnet moet bereikbaar zijn via het provisioningnetwerk van Director om provisioning mogelijk te maken tijdens de implementatie van de cloud. Voeg indien nodig statische route toe voor hetzelfde.

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

10. Maak in KVM en VM Director een hostbestand onder /ansible folder en voeg indien nodig stapelspecifieke details toe.

[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. Zorg ervoor dat alle uitvoerbare afspeelmappen en invoerbestanden in de directory-VM onder /home/stack-map moeten worden bewaard.

Bijwerken van invoerbestanden

Er is een variabel invoerbestand dat bestaat uit netwerkspecifieke gegevens van de klant die moeten worden voorbereid voor de implementatie van de cloud.

Pad: /home/cisco/automation/ansible/podvars

Bestandsnaam: <stack-name>_vars.yml

Werk de gemarkeerde parameters bij volgens het locatiespecifieke IP-plan/ontwerpdocument op laag niveau.

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

Undercloud-implementatie

Undercloud wordt geïmplementeerd met behulp van ansible scripts in zeven stappen. Alle stappen moeten worden uitgevoerd vanaf de KVM-host die in dit geval als jumphost fungeert.

trede	labelen	Beschrijving	Playbook YAML's
Stap 1.	controlebestanden	Controleer de vereiste afspeelboeken, scripts en RPM's op OpenStack Platform Director (OSPD).	OSP16_published_playbooks_verify.yml
Stap 2.	genpodvars	Genereer POD-specifieke variabele bestanden met betrekking tot hardware, RHEL, enzovoort, zoals common_vars.yml (hardware, software, netwerkdetails), hw_m6_vars.yaml (CPU, geheugen, enorme pagina's, schijf, NIC, enzovoort), rhel_84_vars.yml (RHEL, kernel, ICE-driver, NIC-versie), pf_esc_vars.yml (details van Elastic Services Controller (ESC)), osp_16_vars.ymlĂ (OSP-versie, tijdzone, IP-type, VLAN-ID, IP, neutronendetails).	OSP16_generate_pod_specific_vars.yml
Stap 3.	vooraf inzetten	Configureer de Fully Qualified Domain Name (FQDN), het Network Time Protocol (NTP) en werk alle pakketten bij op de director node.	OSP16_pre_undercloud_deploy.yml
Stap 4.	eerste opstart	Voert de eerste herstart van de Undercloud director node uit na de eerdere configuratie en pakketinstallatie.	OSP16_undercloud_deploy.yml
Stap 5.	UCdeploy	Installeer de Undercloud-stack op de directeur	OSP16_undercloud_tuning.yml
Stap 6.	schaatsen	Configureer BIOS CPU C-state-instellingen op directory node.	OSP16_CSTATE.YML
Stap 7.	tweede herstart	Tweede herstart op Undercloud-directeur na wijzigingen in BIOS.	N.v.t.

Bestand met de naam osp16_auto_undercloud_deploy.yml is de belangrijkste uitvoerbare playbook die in één iteratie kan worden uitgevoerd, maar het is raadzaam om de playbook stapsgewijs uit te voeren met behulp van verschillende tags om het oplossen van problemen te vergemakkelijken in het geval van implementatieproblemen.

# 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-implementatie

Overcloud wordt geïmplementeerd met minimaal drie controllers in HA-modus en één computer. Overcloud wordt geïmplementeerd met behulp van ansible scripts in 17 stappen. Alle stappen moeten worden uitgevoerd vanuit Director-VM die in dit geval als Jump-host fungeert.

trede	labelen	Beschrijving	Playbook YAML's
Stap 1.	genpodvars	Genereer POD-specifieke variabele bestanden voor Overcloud gerelateerd aan hardware, RHEL, enzovoort, zoals common_vars.yml (hardware, software, netwerkdetails), hw_m6_vars.yaml (CPU, geheugen, hugepages, schijf, NIC, enzovoort), rhel_84_vars.yml (RHEL, kernel, ICE-driver, NIC-versie), pf_esc_vars.yml (ESC-details), osp_16_vars.ymlŻ (OSP-versie, tijdzone, IP-type, VLAN-ID, IP, neutrondetails).	OSP16_generate_pod_specific_vars.yml
Stap 2.	geninstack	Genereer Instacken JSON-bestand van /var/common_vars.yml dat in de vorige stap is gemaakt. De regisseur heeft een nodedefinitiesjabloon nodig, dat handmatig wordt gemaakt. Dit bestand instackenv.json gebruikt JSON-indeling en bevat alle hardware- en energiebeheerdetails voor de knooppunten. Deze stap valideert ook de hardwareconfiguratie op de UCS-server voordat het bestand wordt gegenereerd.	OSP16_generate_instackenV.yml
Stap 3.	CIMCVD	Configureer de CIMC-instellingen en virtuele schijven (VD's) op elke server die verwijzen naar de common_vars.yml, hw_m6_vars.yaml, en rhel_84_vars.yml.	OSP16_CIMC_VD_CONFIGURE.YML
Stap 4.	vooraf inzetten	Deze stap voert alle vereisten uit om de Overcloud te implementeren. Het stelt de FQDN, NTP en update alle pakketten, push image naar pad voor implementatie.	OSP16_pre_overcloud_deploy.yml
Stap 5.	importnodes	In deze stap wordt de server-CPU geïntrospecteerd, het geheugen, de NIC en de interfacepoorten op de switches van het netwerk. Introspectie wordt uitgevoerd op de aangesloten netwerk switches voor alle controllers en computers.	OSP16_import_ironic_nodes.yml
Stap 6.	gentemplates	Aangepaste sjabloonbestanden voor controllers en computers genereren. Definieer in het aangepaste sjabloon controller- en rekenrollen voor alle services die erop worden uitgevoerd. Het doet ook systeemverharding door certificaten, routes, enzovoort toe te passen.	OSP16_generate_custom_templates.yml
Stap 7.	gezamenlijk inzetten	In deze stap wordt een OpenStack Overcloud-implementatie uitgevoerd. Run deploy.sh geleverd door Red Hat voor RHOSP-implementatie.	OSP16_overcloud_deploy.yml
Stap 8.	geninventory	In deze stap wordt een inventaris-yml-bestand voor gebruik door Ansible gegenereerd, waar provisioning IP, IPMI (CIMC) IP en referenties worden opgeslagen en in kaart gebracht met controller en computers voor automatisering om in te loggen in het systeem en de verdere stappen uit te voeren.	OSP16_build_inventory_v3.py
Stap 9.	offlinerepo	Configureer Overcloud Offline REPO in het bestand /etc/yum.repo.d/offline.repo en wijs naar REPO-server via het externe netwerk.	OSP16_config_offline_repo.yml
Stap 10.	omheining	Configureer hekwerk op alle controllerknooppunten met 'Shoot The Other Node In The Head' (een hektechniek in HA-clusters) (STONITH).	OSP16_config_fencing.yml
Stap 11.	radicache	Instelling RAID-cache configureren voor alle controllers en computers en ook SWIFT-opslaginstellingen configureren.	OSP16_RAID_CACHE_TUNING.YML
Stap 12.	bijwerken	Voer DNF-updates uit voor alle pakketten op alle knooppunten.	DNF_UPDATE_ALL_PACKAGES.YML
Stap 13.	setiplink	In deze stap is de vertrouwensmodus voor SR-IOV-poorten ingeschakeld voor Evolved Packet Data Gateway (EPDG) en intern dataverkeer. De ondersteuning voor SR-IOV-poorten is beschikbaar in neutronenmodus en stelt VM's in staat toegang te krijgen tot het netwerk via virtuele SR-IOV-functies.	osp16_setIpLink.yml
Stap 14.	waakhond	In deze stap wordt de IPMI-instelling op de director node geconfigureerd voor beheertaken op alle server via out-of-band-verbindingen.	OSP16_config_IPMI_Watchdog.yml
Stap 15.	ijsrivier	Werk het Intel E810 ICE-stuurprogramma voor PCI-kaarten (Peripheral Component Interconnect) bij naar versie 1.12.6 voor EPDG om Intel NIC-poorten als SR-IOV te gebruiken.	OSP16_ICE_DRIVER_INSTALL.YML
Stap 16.	start opnieuw op	Start alle Overcloud-knooppunten opnieuw op na uitvoering van de eerdere stappen.	OSP16_reboot_overcloud_hosts.yml
Stap 17.	verifyrhosp	Configuratie en status van de RHOSP-implementatie controleren.	OSP16_RHOSP_VERIFIER.YML

Voor de provisioning van Overcloud-knooppunten maakt Undercloud gebruik van 'overcloud-hardened-uefi-full.qcow2'. Dus voordat u begint met de implementatie van Overcloud, moet het image worden opgeslagen op het aangewezen pad in undercloud/director.

Kopieer het Overcloud qcow2-bestand van de externe site.

# 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

Gebruik het meest recente logbestand om de implementatielogs te controleren.

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

Zorg ervoor dat alle 17 stappen zijn doorlopen.

Controles mislukt = Het aantal moet 00 zijn.

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

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

# STAP | TAG | BESCHRIJVING | PLAYBOOK

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

# step1 | genpodvars | Genereer POD Specifieke Variabele Bestanden | osp16_generate_pod_specific_vars.yml -e podname=

# step2 | geninstack | Instacken JSON-bestand genereren | osp16_generate_instackenv.yml -e podname=

# step3 | cimcvd | CIMC VD's configureren | osp16_cimc_vd_configure.yml

# step4 | preocdeploy | Pre-overcloud-implementatie configureren | osp16_pre_overcloud_deploy.yml

# step5 | importnodes | Import Openstack Baremetal Ironic Nodes | osp16_import_ironic_nodes.yml

# step6 | gentemplates | Aangepaste templates genereren | osp16_generate_custom_templates.yml

# step7 | ocdeploy | Openstack Overcloud Implementatie | osp16_overcloud_deploy.yml

# step8 | geninventory | Voorraadbestand genereren | osp16_build_inventory_v3.py --ipmipass

# step9 | offlinerepo | Overcloud Offline Repo configureren vanuit Offline TAR-bestand | osp16_config_offline_repo.yml

# step10 | fencing | Post Deploy MOP Before Reboot - Fencing configureren | osp16_config_fencing.yml

# step11 | raidcache | MOP implementeren voor opnieuw opstarten - RAID-cache en PR-tuning | osp16_raid_cache_tuning.yml

# step12 | enupdate | Post Deploy MOP Before Reboot - Dnf Update Packages | dnf_update_all_packages.yml

# step13 | setiplink | Implementeer MOP voor het opnieuw opstarten - VF IP Link Trust instellen OP | osp16_setIpLink.yml

# step14 | waakhond | Post Deploy MOP Before Reboot - Config IPMI Watchdog | osp16_config_ipmi_watchdog.yml

# step15 | icedriver | Post Deploy MOP Before Reboot - Update E810 ICE Driver | osp16_ice_driver_install.yml

# step16 | reboot | Alle Overcloud-knooppunten opnieuw opstarten | osp16_reboot_overcloud_hosts.yml

# step17 | verifyrhosp | Verify RHOSP Deployment Configuration and Health | osp16_rhosp_verify.yml -e podname=

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

ALLE HOSTS BEREIKBAAR

 

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

VERRICHTE CONTROLES => 17

CONTROLES DOORSTAAN => 17

CONTROLES MISLUKT => 00

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

ALGEMENE STATUS => GESLAAGD!

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

Zorg na succesvolle implementatie van Overcloud dat het Horizon-dashboard toegankelijk is.

Toegang tot het Horizon Dashboard

Gebruik voor de URL van het dashboard 'OS_AUTH URL' van 'overcloudrc'.

Overcloud-bestandsaanmaak

Horizon-dashboard:

Gezondheidscontrole van RHOSP-cluster

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

Samenvatting

De RHOSP 16.2-implementatiegids biedt uitgebreide, stapsgewijze instructies voor het implementeren van een schaalbare en productieklare OpenStack-cloudomgeving met behulp van de bewezen tools en methodologieën van Red Hat. Deze gids is afgestemd op systeembeheerders en cloudarchitecten en richt zich op het implementeren van RHOSP 16.2 met behulp van de OpenStack-directeur, die is gebaseerd op TripleO (OpenStack op OpenStack).

De gids behandelt alle kritieke fasen van de implementatie, waaronder:

• Infrastructuurplanning en -vereisten
• Omgevingsvoorbereiding en netwerkconfiguratie
• Undercloud-installatie en -configuratie
• Implementatie van overcloud en stappen na implementatie
• Opties voor HA, opslag en serviceschaaling

Deze gids is essentieel voor teams die op zoek zijn naar een betrouwbaar cloudplatform van bedrijfsniveau met de ecosysteemintegratie en ondersteuning van Red Hat.

Revisiegeschiedenis

Revisie	Publicatiedatum	Opmerkingen
3.0	11-Aug-2026	Bijgewerkte inhoud
1.0	27-Apr-2026	Eerste vrijgave