Implementatiehandleiding van RHOSP over UCS voor mobiliteitswerklast 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 raadt u aan kennis te hebben van het Red Hat OpenStack Platform (RHOSP) en over sterke vaardigheden te beschikken 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 infrastructuur van het Unified Computing System (UCS) beschreven, waarbij de nadruk wordt gelegd op schaalbaarheid, betrouwbaarheid en prestatieoptimalisatie.

Het beschrijft best practices en maakt gebruik van verstandige op scripts gebaseerde automatisering voor het implementeren van OpenStack TripleO, bestaande uit Undercloud- en Overcloud-architectuur.

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

Inzicht in RHOSP

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, een tool 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.

onderwolk

De undercloud is het belangrijkste managementknooppunt dat de RHOSP director-toolset bevat. Het is een OpenStack-installatie met één systeem die componenten bevat voor de provisioning en het beheer van de OpenStack-knooppunten die de OpenStack-omgeving vormen (de overcloud).

Onderwolkcomponenten

De undercloud maakt gebruik van OpenStack-componenten als basistoolset. Elke component werkt binnen een afzonderlijke container op de onderwolk:

• OpenStack Identity (keystone) - Biedt authenticatie en autorisatie voor de director-componenten
• OpenStack Bare Metal (ironisch) - Beheert kale metalen knopen
• OpenStack Networking (neutron) en Open vSwitch - Controle van netwerken voor bare metal nodes
• OpenStack Orchestration (Ephemeral Heat) - Biedt de orkestratie van knooppunten nadat de regisseur de overcloud-afbeelding op schijf schrijft

overbewolkt

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

controleur

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

berekenen

Compute nodes bieden computerbronnen voor de OpenStack-omgeving. Rekenknooppunten kunnen in de loop van de tijd geschaald worden in/geschaald worden uitgebreid op basis van netwerkvereisten. Een standaard compute node bevat de volgende componenten:

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

opslag

Opslagknooppunten bieden opslag voor de OpenStack-omgeving.

Lokale opslagplaats (REPO-server)

Redhat biedt een hulpprogramma met de naam reposync dat kan worden gebruikt om de pakketten te downloaden van het Content Delivery Network (CDN). Om alle pakketten van een specifiek 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 .repo extensie. Meerdere repositories kunnen in hetzelfde bestand worden gedefinieerd.

RHOSP-netwerken

De netwerkdienst (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 brengt OpenStack-services in kaart op verschillende geïsoleerde netwerken. De netwerken die elk verkeerstype vervoeren zijn: Cisco Integrated Management Controller (CIMC), Provisioning, Interne API, Opslaggegevens, Opslagbeheer, Huurder en Extern (Secure Shell (SSH) en Operations, Administration en Maintenance (OAM)).

Fysieke connectiviteit van RHOSP

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-netwerkinterfacekaart (NIC) wordt gebruikt op de compute nodes voor de DI-interne en servicenetwerken voor de VNF.
3.	Modulaire LAN op moederbord (MLOM)	MLOM-poorten worden geconfigureerd als een binding. 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-poort gebruiken. LOM1 wordt gebruikt om de Openstack op alle servers te implementeren of in te richten. LOM2 wordt gebruikt als OAM (External Network) op de regisseur.

Het diagram toont de fysieke connectiviteit met de servers.

Logische RHOSP-connectiviteit

Het RHOSP-netwerk heeft meerdere subnetten die zich richten op verschillende diensten 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 zelfstandige 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 de LOM1-poort van alle UCS-servers voor eenvoud en compatibiliteit. Dit netwerk is verantwoordelijk voor de implementatie van de cloud op alle servers.

Vanwege virtualisatie op de Director-server moest er een brugnetwerk op de KVM worden gemaakt zodat de Director-VM kon communiceren met de andere servers.

• OSP_Internal:

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

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

• OSP_Tenant:

Het Tenant-netwerk wordt standaard gemaakt binnen cloudprojecten voor VNF-beheer. In de huidige configuratie wordt Only Single Openstack Project gemaakt voor VNF-implementatie.

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

• OSP_External:

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

Het OSP_External-netwerk is geconfigureerd op LOM2-poort op de Director-node en op gebonden MLOM-poorten op controller- en computerknooppunten.

• OSP_Storage_Data:

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

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

• OSP_Storage_Management:

OpenStack Object Storage gebruikt dit netwerk om gegevensobjecten te synchroniseren tussen deelnemende replica-nodes in een opslagcluster, gevormd tussen controller-compute-nodes.

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

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

Afstemming van hardwareparameters

• Zorg ervoor dat IP is ingeschakeld en geconfigureerd met het juiste beheeradres volgens het ontwerp.
• Zorg ervoor dat de beheerdersgebruiker en het bijbehorende wachtwoord hetzelfde 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 met de aanbevolen parameters instelt.
• Opstartvolgorde instellen op:
  1. LOM-PXE (eno1)
  2. BOOT-harde schijf (HDD)

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

Hypervisor-KVM-installatie en netwerkcreatie

Er zijn verschillende methoden voor het inzetten van de Undercloud/Director en Offline REPO in het klantennetwerk. Deze kunnen direct 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 voor het hosten van de KVM-hypervisor, waardoor meerdere VM's kunnen worden gemaakt. De RHOSP Director-node en de Offline REPO-node worden op deze KVM-hypervisor als VM's geïmplementeerd.

• Als de KVM is ingeschakeld, werkt u de hostnaam bij:
  hostnamectl set-hostname <hostname> --static

• Configureer de externe en provisioningbruggen en verbind de interfaces.

BR-PROV: ETH0

BR-EXT: ETH1

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

• Standaard worden eno1- en eno2-poorten gemaakt in KVM voor fysieke LOM1- en LOM2-poorten, waarbij hetzelfde MAC-adres via CIMC-logboekregistratie wordt gecontroleerd.
• Maak een brugnetwerk en voeg slavenpoorten toe door het juiste MAC-adres toe te wijzen.
• Na het maken van een bridge-netwerk moet u ervoor zorgen dat de provisioning en externe gateway bereikbaar zijn via KVM.

REPO en Director VM-creatie

Vereisten voor het maken van REPO en Director VM

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

• Vereiste directory's maken 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 naar /mnt/iso.

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

• Maak het REPO-bestand op /etc/yum.repos.d path.

# 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

CREATIE VAN REPO-VM

$ 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

• Maak het image van de REPO-server.

$ 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

Directeur VM maken

• Maak een image van de director-server.

# 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

• Open een nieuw venster en log in op de console van de VM.

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

• Post Director VM-implementatie, twee eth-interfaces eth0 en eth1 worden gemaakt.
  • eth0 wordt gebruikt voor OSP_provisioning-netwerken, waarin tijdens br-ctplane-netwerken worden gemaakt tijdens Undercloud-implementatie.
  • eth1 wordt gebruikt voor externe connectiviteit voor SSH Access. Dus, OSP_external subnet IP-adres is toegewezen.

Lokale offline REPO maken

De REPO-server moet geregistreerd zijn bij Redhat 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-containerimages moeten met behulp van een proxy naar de REPO-VM worden gedownload.

RHOSP-cloudimplementatie

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

Voorwaarden

De stappen die moeten worden gevolgd voordat de daadwerkelijke implementatie in de cloud wordt gestart:

1. Zorgen voor connectiviteit van KVM-node met Local REPO VM en Director VM op OSP_EXT-netwerk.
2. Zorg ervoor dat alle mogelijke scripts en automatiseringsscripts naar de KVM-host zijn 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 zal bestaan uit drie mappenmapstructuren, genaamd als:

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

4. Installeer shpass pakket. shpass is een opdrachtregelprogramma dat wordt gebruikt om wachtwoorden aan ssh niet-interactief 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 make pakketten.

# yum install make

• Ontkoppel het shpass-pakket en installeer de SSH-pas.

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

5. Het installatieproces van de regisseur vereist dat een niet-rootgebruiker 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 bestand rootCA.crt 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. De hostnaamgegevens van de lokale REPO-server bijwerken in het bestand Director VM en KVM in /etc/hosts.

8. Installeer op KVM en Director VM extra pakketten zoals python, ansible, enzovoort om verstandige automatiseringsscripts uit te voeren.

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

9. Het CIMC-subnet moet bereikbaar zijn vanaf het provisioningnetwerk van de directeur om provisioning tijdens de implementatie in de cloud mogelijk te maken. Voeg indien nodig een statische route toe voor dezelfde route.

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

10. Maak in KVM en Director VM een hostbestand onder /ansible-map 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 beschikbare afspeelboeken en invoerbestanden in de map Director VM onder /home/stack worden bewaard.

Bijwerken van invoerbestanden

Er is een inputvariabel bestand dat bestaat uit klantnetwerkspecifieke details die moeten worden voorbereid voor cloudimplementatie.

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

Bestandsnaam: <stack-name>_vars.yml

Werk de gemarkeerde parameters bij volgens het sitespecifieke 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: ''

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

stap	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, grote pagina's, schijf, NIC, enzovoort), rhel_84_vars.yml (RHEL, kernel, ICE-driver, NIC-versie), pf_esc_vars.yml (ESC-gegevens), osp_16_vars.yml (OSP-versie, tijdzone, IP-type, VLAN) ID, IP, neutronendetails).	OSP16_generate_pod_specific_vars.yml
Stap 3.	vooraf inzetten	Configureren van volledig gekwalificeerde domeinnaam (FQDN), Network Time Protocol (NTP) en bijwerken van alle pakketten op director node.	osp16_pre_undercloud_deploy.yml
Stap 4.	eerste opstart	Voert de eerste reboot uit van de Undercloud director node na de eerdere configuratie en pakketinstallatie.	osp16_undercloud_deploy.yml
Stap 5.	uplosie	Installeer Undercloud stack op director	osp16_undercloud_tuning.yml
Stap 6.	vastkleven	Configureer de instellingen van de BIOS CPU C-status op de director node.	osp16_cstate.yml
Stap 7.	tweede herstart	Tweede reboot op Undercloud-regisseur na wijzigingen in BIOS.	N.v.t.

Bestandsnaam osp16_auto_undercloud_deploy.yml is het belangrijkste leesbare afspeelboek dat in één iteratie kan worden uitgevoerd, maar het is raadzaam om het afspeelboek stapsgewijs uit te voeren met behulp van verschillende tags om probleemoplossing te vergemakkelijken in 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 ingezet 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.

stap	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, enorme pagina's, 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, IP, IP, IP, neutronendetails).	OSP16_generate_pod_specific_vars.yml
Stap 2.	geninstack	Genereer Instackenv JSON-bestand van /var/common_vars.yml gemaakt in de eerdere stap. De regisseur heeft een knooppuntdefinitiesjabloon nodig, dat handmatig wordt gemaakt. Dit bestand instackenv.json gebruikt de JSON-indeling en bevat alle hardware- en energiebeheerdetails voor de knooppunten. Met deze stap wordt ook de hardwareconfiguratie op de UCS-server gevalideerd voordat het bestand wordt gegenereerd.	OSP16_generate_instackenv.yml
Stap 3.	cimcvd	Configureer CIMC-instellingen en virtuele schijven (VD's) op elke server met verwijzing naar de common_vars.yml, hw_m6_vars.yaml, en rhel_84_vars.yml.	osp16_cimc_vd_configure.yml
Stap 4.	vooraf inzetten	Met deze stap worden alle voorwaarden voor de implementatie van de Overcloud uitgevoerd. Hiermee worden de FQDN-, NTP- en updatepakketten ingesteld en wordt het image naar het pad voor implementatie geduwd.	osp16_pre_overcloud_deploy.yml
Stap 5	importnodes	In deze stap wordt de server-CPU geïntrospecteerd, geheugen, NIC samen met de interface en poorten op de netwerk-switches. Introspectie wordt uitgevoerd op de aangesloten netwerk switches voor alle controllers en computers.	osp16_import_ironic_nodes.yml
Stap 6.	gentemplates	Aangepaste sjabloonbestanden genereren voor controllers en computers. Definieer in de aangepaste sjabloon controllerrollen 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. Voer deploy.sh uit dat door Red Hat wordt geleverd voor RHOSP-implementatie.	osp16_overcloud_deploy.yml
Stap 8	geninventaris	In deze stap wordt een inventarisatie-yml-bestand voor gebruik door ansible gegenereerd waar Provisioning IP, IPMI (CIMC) IP en referenties worden opgeslagen en toegewezen 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 point to repo server via het externe netwerk.	OSP16_config_offline_repo.yml
Stap 10.	omheining	Configureer schermen op alle controllerknooppunten met Shoot The Other Node In The Head (een schermtechniek in HA-clusters) (STONITH).	OSP16_config_fencing.yml
Stap 11.	radiocache	De instelling RAID-cache configureren voor alle controllers en computers configureren ook de instellingen voor SWIFT-opslag.	OSP16_RAID_cache_tuning.yml
Stap 12.	afstandelijk	Voer DNF-updates uit voor alle pakketten op alle knooppunten.	dnf_update_all_packages.yml
Stap 13.	setiplink	In deze stap wordt de controle over de vertrouwensmodus voor SR-IOV-poorten ingeschakeld voor intern en gegevensverkeer via Evolved Packet Data Gateway (EPDG). De ondersteuning voor SR-IOV-poorten is beschikbaar in neutronen en stelt VM's in staat toegang te krijgen tot het netwerk via SR-IOV virtuele functies.	osp16_setIpLink.yml
Stap 14.	waakhond	In deze stap wordt de IPMI-instelling op de director node geconfigureerd voor taakbeheer op alle servers via out-of-band verbinding.	osp16_config_ipmi_watchdog.yml
Stap 15.	ijsdrijver	Werk het Intel E810 ICE-stuurprogramma voor PCI-kaarten (Peripheral Component Interconnect) bij naar versie 1.12.6 zodat EPDG de Intel NIC-poorten als SR-IOV kan gebruiken.	OSP16_ICE_DRIVER_INSTALL.YML
Stap 16.	start opnieuw op	Start alle Overcloud-knooppunten opnieuw op na het uitvoeren van de eerdere stappen.	osp16_reboot_overcloud_hosts.yml
Stap 17.	verifyrhosp	Controleer de configuratie en status van de RHOSP-implementatie.	osp16_rhosp_verify.yml

Voor de provisioning van Overcloud nodes maakt Undercloud gebruik van 'overcloud-hardened-uefi-full.qcow2'. Dus voordat Overcloud-implementatie wordt gestart, moet het image worden opgeslagen in een toegewezen 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

Om de implementatielogboeken te bewaken, gebruikt u het nieuwste logbestand.

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

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

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

# STAP | TAG | BESCHRIJVING | PLAYBOOK

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

# stap1 | genpodvars | POD Specific Variable Files genereren | osp16_generate_pod_specific_vars.yml -e podname=

#step2 | geninstack | Instackenv JSON File genereren | osp16_generate_instackenv.yml -e podname=

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

# stap 4 | vooraf implementeren | Pre Overcloud-implementatie configureren | osp16_pre_overcloud_deploy.yml

#step5 | importnodes | OpenStack Baremetal Ironic Nodes importeren | osp16_import_ironic_nodes.yml

# stap 6 | gentemplates | Aangepaste templates genereren | osp16_generate_custom_templates.yml

# stap 7 | ocdeploy | Openstack Overcloud Deploy | osp16_overcloud_deploy.yml

# stap 8 | geninventory | Inventarisbestand genereren | osp16_build_inventory_v3.py --ipmipass

# stap9 | offlinerepo | Offline Repo van overcloud configureren vanuit offline TAR-bestand | osp16_config_offline_repo.yml

# stap 10 | hekwerk | Implementatie MOP vóór opnieuw opstarten - Hekwerk configureren | osp16_config_fencing.yml

# step11 | RAIDcache | Post Deploy MOP Before Reboot - RAID-cache en PR-afstemming | osp16_raid_cache_tuning.yml

#step12 | dnfupdate | Post Deploy MOP Before Reboot - DNF Update Packages | dnf_update_all_packages.yml

# step13 | setiplink | Post Deploy MOP Before Reboot - VF IP Link Trust ON instellen | 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

# stap 16 | opnieuw opstarten | Alle overcloud-knooppunten opnieuw opstarten | osp16_reboot_overcloud_hosts.yml

# stap 17 | RHOSP verifiëren | Configuratie en status van RHOSP-implementatie verifiëren | osp16_rhosp_verify.yml -e podname=

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

ALLE HOSTS BEREIKBAAR

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

CONTROLES UITGEVOERD => 17

CONTROLES DOORGEGEVEN => 17

CONTROLES MISLUKT => 00

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

ALGEMENE STATUS => VOORBIJ!

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

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

Toegang tot het Horizon Dashboard

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

Dashboard van Horizon:

Gezondheidscontrole van het 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 productierijpe OpenStack-cloudomgeving met behulp van de beproefde tools en methodologieën van Red Hat. Deze gids is op maat gemaakt voor systeembeheerders en cloud architecten en richt zich op het inzetten van RHOSP 16.2 met behulp van de OpenStack director, die is gebaseerd op TripleO (OpenStack op OpenStack).

De gids behandelt alle kritieke fasen van implementatie, waaronder:

• Infrastructuurplanning en voorwaarden
• Voorbereiding van de omgeving en netwerkconfiguratie
• Installatie en configuratie onder de cloud
• Stappen voor overcloud-implementatie en post-implementatie
• Opties voor schaling van HA, opslag en service

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

Revisiegeschiedenis

Revisie	Publicatiedatum	Opmerkingen
1.0	27-Apr-2026	Eerste vrijgave