Remplacement d'OSD-Compute UCS 240M4 - CPAR

Introduction

Ce document décrit les étapes requises pour remplacer un disque de stockage d'objets (OSD) - Serveur de calcul défectueux dans une configuration Ultra-M.

Cette procédure s'applique à un environnement Openstack avec la version NEWTON où ESC ne gère pas CPAR et CPAR est installé directement sur la machine virtuelle (VM) déployée sur Openstack.

Informations générales

Ultra-M est une solution de coeur de réseau de paquets mobiles virtualisés prépackagée et validée conçue pour simplifier le déploiement des VNF. OpenStack est le Virtual Infrastructure Manager (VIM) pour Ultra-M et comprend les types de noeuds suivants :

• Calcul
• OSD - Calcul
• Contrôleur
• Plate-forme OpenStack - Director (OSPD)

L'architecture de haut niveau d'Ultra-M et les composants impliqués sont représentés dans cette image :

Ce document est destiné au personnel de Cisco qui connaît la plate-forme Cisco Ultra-M et décrit en détail les étapes à suivre dans les systèmes d'exploitation OpenStack et Redhat.

Note: La version Ultra M 5.1.x est prise en compte afin de définir les procédures de ce document.

Abréviations

MoP	Méthode de procédure
OSD	Disques de stockage d'objets
OSPD	OpenStack Platform Director
HDD	Disque dur
SSD	Disque dur SSD
VIM	Gestionnaire d'infrastructure virtuelle
VM	Machine virtuelle
EM	Gestionnaire d'éléments
UAS	Services d’automatisation ultra
UUID	Identificateur unique

Flux de travail de MoP

  

Sauvegarde

Avant de remplacer un noeud Compute, il est important de vérifier l'état actuel de votre environnement Red Hat OpenStack Platform. Il est recommandé de vérifier l'état actuel afin d'éviter les complications lorsque le processus de remplacement informatique est activé. Il peut être atteint par ce flux de remplacement.

En cas de récupération, Cisco recommande d'effectuer une sauvegarde de la base de données OSPD en procédant comme suit :

[root@director ~]# mysqldump --opt --all-databases > /root/undercloud-all-databases.sql
[root@director ~]# tar --xattrs -czf undercloud-backup-`date +%F`.tar.gz /root/undercloud-all-databases.sql 
/etc/my.cnf.d/server.cnf /var/lib/glance/images /srv/node /home/stack
tar: Removing leading `/' from member names

Ce processus garantit qu'un noeud peut être remplacé sans affecter la disponibilité d'instances.

Note: Assurez-vous que vous disposez de l'instantané de l'instance afin de pouvoir restaurer la machine virtuelle si nécessaire. Suivez la procédure pour prendre un instantané de la machine virtuelle.

1. Identifiez les machines virtuelles hébergées dans le noeud OSD-Compute.
2. Identifiez les machines virtuelles hébergées sur le serveur.

  

[stack@director ~]$ nova list --field name,host | grep osd-compute-0
| 46b4b9eb-a1a6-425d-b886-a0ba760e6114 | AAA-CPAR-testing-instance | pod2-stack-compute-4.localdomain |

Note: Dans le résultat présenté ici, la première colonne correspond à l'identificateur unique universel (UUID), la deuxième colonne correspond au nom de la machine virtuelle et la troisième au nom d'hôte de la machine virtuelle. Les paramètres de cette sortie sont utilisés dans les sections suivantes. 

Arrêt de l'application CPAR

Étape 1. Ouvrez tout client Secure Shell (SSH) connecté au réseau et connectez-vous à l'instance CPAR.

Il est important de ne pas arrêter les 4 instances AAA d'un site en même temps, le faire une par une.

Étape 2. Pour arrêter l'application CPAR, exécutez la commande suivante :

/opt/CSCOar/bin/arserver stop

Un message “ l'Agent Cisco Prime Access Registrar Server s'est arrêté. ” doit apparaître.

Note: Si un utilisateur a laissé une session CLI (Command Line Interface) ouverte, la commande arserver stop ne fonctionnera pas et ce message s'affiche.

ERROR:    You cannot shut down Cisco Prime Access Registrar while the
          CLI is being used.   Current list of running
          CLI with process id is:
2903 /opt/CSCOar/bin/aregcmd –s

Dans cet exemple, l'ID de processus mis en surbrillance 2903 doit être terminé avant que CPAR puisse être arrêté. Si c'est le cas, exécutez la commande afin de mettre fin à ce processus :

kill -9 *process_id*

Répétez ensuite l'étape 1.

Étape 3. Afin de vérifier que l'application CPAR a bien été arrêtée, exécutez la commande :

/opt/CSCOar/bin/arstatus

Ces messages doivent apparaître :

Cisco Prime Access Registrar Server Agent not running
Cisco Prime Access Registrar GUI not running

Tâche de capture instantanée de VM

Étape 1. Saisissez le site Web de l'interface graphique d'Horizon correspondant au site (ville) sur lequel vous travaillez actuellement.

Lorsque vous accédez à Horizon, l'écran observé est comme illustré dans cette image.

Étape 2. Accédez à Project > Instances comme indiqué dans cette image.

Si l'utilisateur utilisé était CPAR, seules les 4 instances AAA apparaissent dans ce menu.

Étape 3. Arrêtez une seule instance à la fois et répétez l'ensemble du processus de ce document. Afin d'arrêter la machine virtuelle, accédez à Actions > Arrêter l'instance comme indiqué dans l'image et confirmez votre sélection.

Étape 4. Vérifiez que l'instance a bien été arrêtée en vérifiant l'état = Arrêt et l'état d'alimentation = Arrêt comme illustré dans cette image.

Cette étape met fin au processus d'arrêt CPAR.

Instantané VM

Une fois que les machines virtuelles CPAR sont désactivées, les snapshots peuvent être pris en parallèle car ils appartiennent à des ordinateurs indépendants.

Les quatre fichiers QCOW2 sont créés en parallèle.

Prenez un instantané de chaque instance AAA. (25 minutes -1 heure) (25 minutes pour les instances qui utilisent une image qcow comme source et 1 heure pour les instances qui utilisent une image brute comme source)

1. Connectez-vous à l'interface utilisateur graphique Horizon d'Openstack du POD.
2. Une fois connecté, accédez à Project > Compute > Instances dans le menu supérieur et recherchez les instances AAA comme indiqué dans cette image.

3. Cliquez sur Create Snapshot afin de poursuivre la création de clichés (qui doit être exécutée sur l'instance AAA correspondante) comme indiqué dans cette image.

4. Une fois l'instantané exécuté, cliquez sur Images et vérifiez que tous les problèmes se terminent et ne signalent aucun problème comme indiqué dans cette image.

5. L'étape suivante consiste à télécharger l'instantané au format QCOW2 et à le transférer à une entité distante, au cas où l'OSPD serait perdu au cours de ce processus. Pour ce faire, identifiez le snapshot en exécutant la commande glance image-list au niveau OSPD.

[root@elospd01 stack]# glance image-list

+--------------------------------------+---------------------------+

| ID                                   | Name                      |             +--------------------------------------+---------------------------+

| 80f083cb-66f9-4fcf-8b8a-7d8965e47b1d | AAA-Temporary             |             | 22f8536b-3f3c-4bcc-ae1a-8f2ab0d8b950 | ELP1 cluman 10_09_2017    |

| 70ef5911-208e-4cac-93e2-6fe9033db560 | ELP2 cluman 10_09_2017    |

| e0b57fc9-e5c3-4b51-8b94-56cbccdf5401 | ESC-image                 |

| 92dfe18c-df35-4aa9-8c52-9c663d3f839b | lgnaaa01-sept102017       |

| 1461226b-4362-428b-bc90-0a98cbf33500 | tmobile-pcrf-13.1.1.iso   |

| 98275e15-37cf-4681-9bcc-d6ba18947d7b | tmobile-pcrf-13.1.1.qcow2 |

+--------------------------------------+---------------------------+ 

6. Une fois l'instantané à télécharger (celui marqué en vert) identifié, vous pouvez le télécharger au format QCOW2 avec la commande glance image-download comme illustré.

[root@elospd01 stack]# glance image-download 92dfe18c-df35-4aa9-8c52-9c663d3f839b --file /tmp/AAA-CPAR-LGNoct192017.qcow2 &

• Le & envoie le processus en arrière-plan. Cette action prend un certain temps, une fois terminée, l'image peut être localisée dans le répertoire /tmp.
• Lors de l'envoi du processus en arrière-plan, si la connectivité est perdue, le processus est également arrêté. 
• Exécutez la commande disown -h afin que, en cas de perte de connexion SSH, le processus continue à s'exécuter et se termine sur l'OSPD.

7. Une fois le processus de téléchargement terminé, un processus de compression doit être exécuté car ce snapshot peut être rempli de ZEROES en raison de processus, de tâches et de fichiers temporaires gérés par le système d'exploitation. La commande à utiliser pour la compression de fichiers est virt-sparsify.

[root@elospd01 stack]# virt-sparsify AAA-CPAR-LGNoct192017.qcow2 AAA-CPAR-LGNoct192017_compressed.qcow2

Ce processus peut prendre un certain temps (environ 10 à 15 minutes). Une fois terminé, le fichier résultant est celui qui doit être transféré à une entité externe comme spécifié à l'étape suivante.

Pour ce faire, vous devez vérifier l'intégrité du fichier. Exécutez la commande suivante et recherchez l'attribut ” corrompu “ à la fin de sa sortie.

[root@wsospd01 tmp]# qemu-img info AAA-CPAR-LGNoct192017_compressed.qcow2
image: AAA-CPAR-LGNoct192017_compressed.qcow2
file format: qcow2
virtual size: 150G (161061273600 bytes)
disk size: 18G
cluster_size: 65536
Format specific information:

    compat: 1.1

    lazy refcounts: false

    refcount bits: 16

    corrupt: false 

• Afin d'éviter un problème de perte de l'OSPD, l'instantané récemment créé au format QCOW2 doit être transféré à une entité externe. Avant de commencer le transfert de fichiers, vous devez vérifier si la destination a suffisamment d'espace disque disponible, exécutez la commande df -kh afin de vérifier l'espace mémoire. Un conseil est de le transférer temporairement à l'OSPD d'un autre site avec le SFTP sftp root@x.x.x.x ” où x.x.x.x.x est l'IP d'un OSPD distant. Afin d'accélérer le transfert, la destination peut être envoyée à plusieurs OSPD. De la même manière, vous pouvez exécuter la commande scp *name_of_the_file*.qcow2 root@ x.x.x.x:/tmp (où x.x.x.x est l'adresse IP d'un OSPD distant) afin de transférer le fichier vers un autre OSPD. 

1. Identifiez les machines virtuelles hébergées dans le noeud OSD-Compute. 
2. Identifiez les machines virtuelles hébergées sur le serveur.

  

[stack@director ~]$ nova list --field name,host | grep osd-compute-0
| 46b4b9eb-a1a6-425d-b886-a0ba760e6114 | AAA-CPAR-testing-instance | pod2-stack-compute-4.localdomain |

Note: Dans le résultat présenté ici, la première colonne correspond à l'identificateur unique universel (UUID), la deuxième colonne correspond au nom de la machine virtuelle et la troisième au nom d'hôte de la machine virtuelle. Les paramètres de cette sortie sont utilisés dans les sections suivantes.

• Vérifiez que CEPH a une capacité disponible afin de permettre la suppression d'un seul serveur OSD. 

[heat-admin@pod2-stack-osd-compute-0 ~]$ sudo ceph df

GLOBAL:

    SIZE       AVAIL      RAW USED     %RAW USED
    13393G     11088G        2305G         17.21

POOLS:
    NAME        ID     USED      %USED     MAX AVAIL     OBJECTS
    rbd         0          0         0         3635G           0
    metrics     1      3452M      0.09         3635G      219421
    images      2       138G      3.67         3635G       43127
    backups     3          0         0         3635G           0
    volumes     4       139G      3.70         3635G       36581
    vms         5       490G     11.89         3635G      126247

• Vérifiez que ceph osd tree status est actif sur le serveur osd-computing. 

[heat-admin@pod2-stack-osd-compute-0 ~]$ sudo ceph osd tree
ID WEIGHT   TYPE NAME                         UP/DOWN REWEIGHT PRIMARY-AFFINITY
-1 13.07996 root default
-2  4.35999     host pod2-stack-osd-compute-0
 0  1.09000         osd.0                          up  1.00000          1.00000
 3  1.09000         osd.3                          up  1.00000          1.00000
 6  1.09000         osd.6                          up  1.00000          1.00000
 9  1.09000         osd.9                          up  1.00000          1.00000
-3  4.35999     host pod2-stack-osd-compute-1
 1  1.09000         osd.1                          up  1.00000          1.00000
 4  1.09000         osd.4                          up  1.00000          1.00000
 7  1.09000         osd.7                          up  1.00000          1.00000
10  1.09000         osd.10                         up  1.00000          1.00000
-4  4.35999     host pod2-stack-osd-compute-2
 2  1.09000         osd.2                          up  1.00000          1.00000
 5  1.09000         osd.5                          up  1.00000          1.00000
 8  1.09000         osd.8                          up  1.00000          1.00000
11  1.09000         osd.11                         up  1.00000          1.00000

• Les processus CEPH sont actifs sur le serveur osd-computing.

[heat-admin@pod2-stack-osd-compute-0 ~]$ systemctl list-units *ceph*

UNIT                             LOAD   ACTIVE SUB     DESCRIPTION
var-lib-ceph-osd-ceph\x2d0.mount loaded active mounted /var/lib/ceph/osd/ceph-0
var-lib-ceph-osd-ceph\x2d3.mount loaded active mounted /var/lib/ceph/osd/ceph-3
var-lib-ceph-osd-ceph\x2d6.mount loaded active mounted /var/lib/ceph/osd/ceph-6
var-lib-ceph-osd-ceph\x2d9.mount loaded active mounted /var/lib/ceph/osd/ceph-9
ceph-osd@0.service               loaded active running Ceph object storage daemon
ceph-osd@3.service               loaded active running Ceph object storage daemon
ceph-osd@6.service               loaded active running Ceph object storage daemon
ceph-osd@9.service               loaded active running Ceph object storage daemon
system-ceph\x2ddisk.slice        loaded active active  system-ceph\x2ddisk.slice
system-ceph\x2dosd.slice         loaded active active  system-ceph\x2dosd.slice
ceph-mon.target                  loaded active active  ceph target allowing to start/stop all ceph-mon@.service instances at once
ceph-osd.target                  loaded active active  ceph target allowing to start/stop all ceph-osd@.service instances at once
ceph-radosgw.target              loaded active active  ceph target allowing to start/stop all ceph-radosgw@.service instances at once
ceph.target                      loaded active active  ceph target allowing to start/stop all ceph*@.service instances at once

LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB    = The low-level unit activation state, values depend on unit type.

14 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'. 

•  Désactivez et arrêtez chaque instance ceph, supprimez chaque instance de osd et démontez le répertoire. Répétez l'opération pour chaque instance de césure.

[heat-admin@pod2-stack-osd-compute-0  ~]# systemctl disable ceph-osd@0

[heat-admin@pod2-stack-osd-compute-0 ~]# systemctl stop ceph-osd@0

[heat-admin@pod2-stack-osd-compute-0 ~]# ceph osd out 0

• marqué osd.0.
  
  

[heat-admin@pod2-stack-osd-compute-0 ~]# ceph osd crush remove osd.0

• nom 'osd.0' de l'ID d'élément supprimé de la carte de broyage
  
  

[heat-admin@pod2-stack-osd-compute-0  ~]# ceph auth del osd.0

• mise à jour 
  
  

[heat-admin@pod2-stack-osd-compute-0 ~]# ceph osd rm 0

• osd supprimé.0

[heat-admin@pod2-stack-osd-compute-0 ~]# umount /var/lib/ceph.osd/ceph-0

[heat-admin@pod2-stack-osd-compute-0 ~]# rm -rf /var/lib/ceph.osd/ceph-0

 OU,

• Le script Clean.sh peut être utilisé pour cette tâche à la fois.

[heat-admin@pod2-stack-osd-compute-0 ~]$ sudo ls /var/lib/ceph/osd
ceph-0  ceph-3  ceph-6  ceph-9

[heat-admin@pod2-stack-osd-compute-0 ~]$ /bin/sh clean.sh

[heat-admin@pod2-stack-osd-compute-0 ~]$ cat clean.sh

#!/bin/sh
set -x
CEPH=`sudo ls /var/lib/ceph/osd`
for c in $CEPH
do
   i=`echo $c |cut -d'-' -f2`
   sudo systemctl disable ceph-osd@$i || (echo "error rc:$?"; exit 1)
   sleep 2
   sudo systemctl stop ceph-osd@$i || (echo "error rc:$?"; exit 1)
   sleep 2
   sudo ceph osd out $i || (echo "error rc:$?"; exit 1)
   sleep 2
   sudo ceph osd crush remove osd.$i || (echo "error rc:$?"; exit 1)
   sleep 2
   sudo ceph auth del osd.$i || (echo "error rc:$?"; exit 1)
   sleep 2
   sudo ceph osd rm $i || (echo "error rc:$?"; exit 1)
   sleep 2
   sudo umount /var/lib/ceph/osd/$c || (echo "error rc:$?"; exit 1)
   sleep 2
   sudo rm -rf /var/lib/ceph/osd/$c || (echo "error rc:$?"; exit 1)
   sleep 2
done

sudo ceph osd tree 

Une fois que tous les processus OSD ont été migrés/supprimés, le noeud peut être supprimé du nuage.

Note: Lorsque CEPH est supprimé, le RAID HD VNF passe à l'état Dégradé, mais le disque dur doit toujours être accessible.

Mise hors tension gracieuse

• Noeud de mise hors tension

1. Afin de mettre l'instance hors tension : nova stop <NOM_INSTANCE>
2. Vous pouvez voir le nom de l'instance avec l'arrêt de l'état.

[stack@director ~]$ nova stop  aaa2-21

Request to stop server aaa2-21 has been accepted.

[stack@director ~]$ nova list

+--------------------------------------+---------------------------+---------+------------+-------------+------------------------------------------------------------------------------------------------------------+

| ID                                   | Name                      | Status  | Task State | Power State | Networks                                                                                                   |

+--------------------------------------+---------------------------+---------+------------+-------------+------------------------------------------------------------------------------------------------------------+

| 46b4b9eb-a1a6-425d-b886-a0ba760e6114 | AAA-CPAR-testing-instance | ACTIVE  | -          | Running     | tb1-mgmt=172.16.181.14, 10.225.247.233; radius-routable1=10.160.132.245; diameter-routable1=10.160.132.231 |

| 3bc14173-876b-4d56-88e7-b890d67a4122 | aaa2-21                   | SHUTOFF | -          | Shutdown    | diameter-routable1=10.160.132.230; radius-routable1=10.160.132.248; tb1-mgmt=172.16.181.7, 10.225.247.234  |

| f404f6ad-34c8-4a5f-a757-14c8ed7fa30e | aaa21june                 | ACTIVE  | -          | Running     | diameter-routable1=10.160.132.233; radius-routable1=10.160.132.244; tb1-mgmt=172.16.181.10                 |

+--------------------------------------+---------------------------+---------+------------+-------------+------------------------------------------------------------------------------------------------------------+

• Suppression de noeud

Les étapes mentionnées dans cette section sont communes indépendamment des machines virtuelles hébergées dans le noeud de calcul.

Supprimez OSD-Compute Node de la liste de services.

• Supprimer le service de calcul de la liste de services :

  [stack@director ~]$ openstack compute service list |grep osd-compute
  
  | 135 | nova-compute     | pod2-stack-osd-compute-1.localdomain | AZ-esc2  | enabled | up    | 2018-06-22T11:05:22.000000 |
  
  | 150 | nova-compute     | pod2-stack-osd-compute-2.localdomain | nova     | enabled | up    | 2018-06-22T11:05:17.000000 |
  
  | 153 | nova-compute     | pod2-stack-osd-compute-0.localdomain | AZ-esc1  | enabled | up    | 2018-06-22T11:05:25.000000 |

• openstack calculer service delete <ID>

[stack@director ~]$ openstack compute service delete 150 

Supprimer les agents neutres

• Supprimez l'ancien agent neutron associé et l'agent vswitch ouvert pour l'ordinateur :

  [stack@director ~]$ openstack network agent list | grep osd-compute-0
  
  | eaecff95-b163-4cde-a99d-90bd26682b22 | Open vSwitch agent | pod2-stack-osd-compute-0.localdomain | None              | True  | UP    | neutron-openvswitch-agent |

• openstack network agent delete <ID>

[stack@director ~]$ openstack network agent delete eaecff95-b163-4cde-a99d-90bd26682b22

Supprimer de la base de données ironique

• Supprimez un noeud de la base de données ironique et vérifiez-le :

[root@director ~]#  nova list | grep osd-compute-0
| 6810c884-1cb9-4321-9a07-192443920f1f | pod2-stack-osd-compute-0 | ACTIVE | -          | Running     | ctlplane=192.200.0.109 |

[root@al03-pod2-ospd ~]$ nova delete 6810c884-1cb9-4321-9a07-192443920f1f

• nova show < ordinateur -noeud> | hyperviseur grep

[root@director ~]# source stackrc

[root@director ~]#  nova show pod2-stack-osd-compute-0 | grep hypervisor
| OS-EXT-SRV-ATTR:hypervisor_hostname  | 05ceb513-e159-417d-a6d6-cbbcc4b167d7      

• noeud ironique-delete <ID>

[stack@director ~]$ ironic node-delete 05ceb513-e159-417d-a6d6-cbbcc4b167d7
[stack@director ~]$ ironic node-list 

Le noeud supprimé ne doit pas figurer dans la liste des noeuds ironiques.

Supprimer du nuage

• Créez un fichier de script nommé delete_node.sh avec le contenu comme indiqué. Assurez-vous que les modèles mentionnés sont identiques à ceux utilisés dans le script Deployment.sh utilisé pour le déploiement de la pile :

• delete_node.sh :

openstack overcloud node delete --templates -e /usr/share/openstack-tripleo-heat-templates/environments/puppet-pacemaker.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/storage-environment.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/neutron-sriov.yaml -e /home/stack/custom-templates/network.yaml -e /home/stack/custom-templates/ceph.yaml -e /home/stack/custom-templates/compute.yaml -e /home/stack/custom-templates/layout.yaml -e /home/stack/custom-templates/layout.yaml --stack <stack-name> <UUID>

[stack@director ~]$ source stackrc
[stack@director ~]$ /bin/sh delete_node.sh
+ openstack overcloud node delete --templates -e /usr/share/openstack-tripleo-heat-templates/environments/puppet-pacemaker.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/storage-environment.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/neutron-sriov.yaml -e /home/stack/custom-templates/network.yaml -e /home/stack/custom-templates/ceph.yaml -e /home/stack/custom-templates/compute.yaml -e /home/stack/custom-templates/layout.yaml -e /home/stack/custom-templates/layout.yaml --stack pod2-stack 7439ea6c-3a88-47c2-9ff5-0a4f24647444
Deleting the following nodes from stack pod2-stack:
- 7439ea6c-3a88-47c2-9ff5-0a4f24647444
Started Mistral Workflow. Execution ID: 4ab4508a-c1d5-4e48-9b95-ad9a5baa20ae

real   0m52.078s
user   0m0.383s
sys    0m0.086s

• Attendez que l'opération de pile OpenStack passe à l'état COMPLET :

[stack@director ~]$  openstack stack list
+--------------------------------------+------------+-----------------+----------------------+----------------------+
| ID                                   | Stack Name | Stack Status    | Creation Time        | Updated Time         |
+--------------------------------------+------------+-----------------+----------------------+----------------------+
| 5df68458-095d-43bd-a8c4-033e68ba79a0 | pod2-stack | UPDATE_COMPLETE | 2018-05-08T21:30:06Z | 2018-05-08T20:42:48Z |
+--------------------------------------+------------+-----------------+----------------------+----------------------+

Installer un nouveau noeud de calcul

• Les étapes permettant d'installer un nouveau serveur UCS C240 M4 et les étapes de configuration initiale peuvent être référencées à l'adresse suivante :

Guide d'installation et de maintenance du serveur Cisco UCS C240 M4

• Après l'installation du serveur, insérez les disques durs dans les logements respectifs en tant qu'ancien serveur.
• Connectez-vous au serveur à l'aide de l'adresse IP CIMC.
• Effectuez une mise à niveau du BIOS si le micrologiciel n'est pas conforme à la version recommandée précédemment utilisée. Les étapes de mise à niveau du BIOS sont indiquées ici :

Guide de mise à niveau du BIOS du serveur rack Cisco UCS série C

• Vérifiez l'état des lecteurs physiques. Il doit être Non configuré Bon :

Accédez à Storage > Cisco 12G SAS Modular Raid Controller (SLOT-HBA) > Physical Drive Info comme illustré dans cette image.

• Créez un lecteur virtuel à partir des lecteurs physiques avec RAID Niveau 1 :

Accédez à Storage > Cisco 12G SAS Modular Raid Controller (SLOT-HBA) > Controller Info > Create Virtual Drive from Unused Physical Drives comme illustré dans cette image.

• Sélectionnez le VD et configurez Set as Boot Drive comme indiqué dans l'image.

• Activer IPMI sur LAN :

Accédez à Admin > Communication Services > Communication Services comme illustré dans l'image.

  

• Désactiver l'hyperthreading :

Naviguez jusqu'à Compute > BIOS > Configure BIOS > Advanced > Processor Configuration comme illustré dans l'image.

• À l'instar de BOOTOS VD créé avec les disques physiques 1 et 2, créez quatre disques virtuels supplémentaires comme :
  
  

  JOURNAL > From physical drive number 3
  
  OSD1 > From physical drive number 7
  
  OSD2 > From physical drive number 8
  
  OSD3 > From physical drive number 9
  
  OSD4 > From physical drive number 10
  

  
  
• À la fin, les disques physiques et virtuels doivent être similaires à ceux présentés dans les images.

Note: L'image ci-dessous et les étapes de configuration mentionnées dans cette section se rapportent à la version 3.0(3e) du microprogramme et il peut y avoir de légères variations si vous travaillez sur d'autres versions.

Ajouter un nouveau noeud OSD-Computing au nuage

Les étapes mentionnées dans cette section sont communes indépendamment de la machine virtuelle hébergée par le noeud de calcul.

• Ajoutez Compute server avec un index différent.

Créez un fichier add_node.json avec uniquement les détails du nouveau serveur de calcul à ajouter. Assurez-vous que le numéro d'index du nouveau serveur de calcul n'a pas été utilisé auparavant. Généralement, incrémentez la valeur de calcul la plus élevée suivante.

Exemple : Le plus élevé précédent a été osd-calcul-17, par conséquent, créé osd-calcul-18 dans le cas d'un système 2-vnf. 

Note: Tenez compte du format json.

[stack@director ~]$ cat add_node.json 
{
    "nodes":[
        {
            "mac":[
                "<MAC_ADDRESS>"
            ],
            "capabilities": "node:osd-compute-3,boot_option:local",
            "cpu":"24",
            "memory":"256000",
            "disk":"3000",
            "arch":"x86_64",
            "pm_type":"pxe_ipmitool",
            "pm_user":"admin",
            "pm_password":"<PASSWORD>",
            "pm_addr":"192.100.0.5"
        }
    ]
}

• Importer le fichier json. 

[stack@director ~]$ openstack baremetal import --json add_node.json
Started Mistral Workflow. Execution ID: 78f3b22c-5c11-4d08-a00f-8553b09f497d
Successfully registered node UUID 7eddfa87-6ae6-4308-b1d2-78c98689a56e
Started Mistral Workflow. Execution ID: 33a68c16-c6fd-4f2a-9df9-926545f2127e
Successfully set all nodes to available.

• Exécutez l'introspection de noeud avec l'utilisation de l'UUID noté à l'étape précédente.

[stack@director ~]$ openstack baremetal node manage 7eddfa87-6ae6-4308-b1d2-78c98689a56e
[stack@director ~]$ ironic node-list |grep 7eddfa87
| 7eddfa87-6ae6-4308-b1d2-78c98689a56e | None | None                                 | power off   | manageable         | False       |

[stack@director ~]$ openstack overcloud node introspect 7eddfa87-6ae6-4308-b1d2-78c98689a56e --provide
Started Mistral Workflow. Execution ID: e320298a-6562-42e3-8ba6-5ce6d8524e5c
Waiting for introspection to finish...
Successfully introspected all nodes.
Introspection completed.
Started Mistral Workflow. Execution ID: c4a90d7b-ebf2-4fcb-96bf-e3168aa69dc9
Successfully set all nodes to available.

[stack@director ~]$ ironic node-list |grep available
| 7eddfa87-6ae6-4308-b1d2-78c98689a56e | None | None                                 | power off   | available          | False       |

• Ajoutez des adresses IP à custom-templates/layout.yml sous Osd Compute IPs. Dans ce cas, en remplaçant osd-computing-0 vous ajoutez cette adresse à la fin de la liste pour chaque type

OsdComputeIPs :

internal_api:

    - 11.120.0.43

    - 11.120.0.44

    - 11.120.0.45

    - 11.120.0.43   <<< take osd-compute-0 .43 and add here

    tenant:

    - 11.117.0.43

    - 11.117.0.44

    - 11.117.0.45

    - 11.117.0.43   << and here

    storage:

    - 11.118.0.43

    - 11.118.0.44

    - 11.118.0.45

    - 11.118.0.43   << and here

    storage_mgmt:

    - 11.119.0.43

    - 11.119.0.44

    - 11.119.0.45

    - 11.119.0.43   << and here

• Exécutez le script Deployment.sh précédemment utilisé pour déployer la pile, afin d'ajouter le nouveau noeud de calcul à la pile de surcloud : 

  [stack@director ~]$ ./deploy.sh
  ++ openstack overcloud deploy --templates -r /home/stack/custom-templates/custom-roles.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/puppet-pacemaker.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/storage-environment.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/neutron-sriov.yaml -e /home/stack/custom-templates/network.yaml -e /home/stack/custom-templates/ceph.yaml -e /home/stack/custom-templates/compute.yaml -e /home/stack/custom-templates/layout.yaml --stack ADN-ultram --debug --log-file overcloudDeploy_11_06_17__16_39_26.log --ntp-server 172.24.167.109 --neutron-flat-networks phys_pcie1_0,phys_pcie1_1,phys_pcie4_0,phys_pcie4_1 --neutron-network-vlan-ranges datacentre:1001:1050 --neutron-disable-tunneling --verbose --timeout 180
  …
  Starting new HTTP connection (1): 192.200.0.1
  "POST /v2/action_executions HTTP/1.1" 201 1695
  HTTP POST http://192.200.0.1:8989/v2/action_executions 201
  Overcloud Endpoint: http://10.1.2.5:5000/v2.0
  Overcloud Deployed
  clean_up DeployOvercloud: 
  END return value: 0
  
  real   38m38.971s
  user   0m3.605s
  sys    0m0.466s

• Attendez que l'état d'openstack soit Terminé :

[stack@director ~]$  openstack stack list
+--------------------------------------+------------+-----------------+----------------------+----------------------+
| ID                                   | Stack Name | Stack Status    | Creation Time        | Updated Time         |
+--------------------------------------+------------+-----------------+----------------------+----------------------+
| 5df68458-095d-43bd-a8c4-033e68ba79a0 | ADN-ultram | UPDATE_COMPLETE | 2017-11-02T21:30:06Z | 2017-11-06T21:40:58Z |
+--------------------------------------+------------+-----------------+----------------------+----------------------+

• Vérifiez que le nouveau noeud de calcul est à l'état Actif :

[stack@director ~]$ source stackrc
[stack@director ~]$ nova list |grep osd-compute-3
| 0f2d88cd-d2b9-4f28-b2ca-13e305ad49ea | pod1-osd-compute-3    | ACTIVE | -          | Running     | ctlplane=192.200.0.117 |

[stack@director ~]$ source corerc
[stack@director ~]$ openstack hypervisor list |grep osd-compute-3
| 63 | pod1-osd-compute-3.localdomain    |

• Connectez-vous au nouveau serveur osd-computing et vérifiez les processus ceph. Initialement, l'état est dans HEALTH_WARN au fur et à mesure de la récupération de la céphalée.

• [heat-admin@pod1-osd-compute-3 ~]$ sudo ceph -s
  
      cluster eb2bb192-b1c9-11e6-9205-525400330666
       health HEALTH_WARN
              223 pgs backfill_wait
              4 pgs backfilling
              41 pgs degraded
              227 pgs stuck unclean
              41 pgs undersized
              recovery 45229/1300136 objects degraded (3.479%)
              recovery 525016/1300136 objects misplaced (40.382%)
       monmap e1: 3 mons at {Pod1-controller-0=11.118.0.40:6789/0,Pod1-controller-1=11.118.0.41:6789/0,Pod1-controller-2=11.118.0.42:6789/0}
              election epoch 58, quorum 0,1,2 Pod1-controller-0,Pod1-controller-1,Pod1-controller-2
       osdmap e986: 12 osds: 12 up, 12 in; 225 remapped pgs
              flags sortbitwise,require_jewel_osds
        pgmap v781746: 704 pgs, 6 pools, 533 GB data, 344 kobjects
              1553 GB used, 11840 GB / 13393 GB avail
              45229/1300136 objects degraded (3.479%)
              525016/1300136 objects misplaced (40.382%)
                   477 active+clean
                   186 active+remapped+wait_backfill
                    37 active+undersized+degraded+remapped+wait_backfill
                     4 active+undersized+degraded+remapped+backfilling 

• Mais après une courte période (20 minutes), le CEPH revient à l'état HEALTH_OK.

[heat-admin@pod1-osd-compute-3 ~]$ sudo ceph -s

    cluster eb2bb192-b1c9-11e6-9205-525400330666
     health HEALTH_OK

     monmap e1: 3 mons at {Pod1-controller-0=11.118.0.40:6789/0,Pod1-controller-1=11.118.0.41:6789/0,Pod1-controller-2=11.118.0.42:6789/0}
            election epoch 58, quorum 0,1,2 Pod1-controller-0,Pod1-controller-1,Pod1-controller-2
     osdmap e1398: 12 osds: 12 up, 12 in
            flags sortbitwise,require_jewel_osds
      pgmap v784311: 704 pgs, 6 pools, 533 GB data, 344 kobjects
            1599 GB used, 11793 GB / 13393 GB avail
                 704 active+clean
  client io 8168 kB/s wr, 0 op/s rd, 32 op/s wr


[heat-admin@pod1-osd-compute-3 ~]$ sudo ceph osd tree
ID WEIGHT   TYPE NAME                         UP/DOWN REWEIGHT PRIMARY-AFFINITY

-1 13.07996 root default
-2        0     host pod1-osd-compute-0
-3  4.35999     host pod1-osd-compute-2
 1  1.09000         osd.1                          up  1.00000          1.00000
 4  1.09000         osd.4                          up  1.00000          1.00000
 7  1.09000         osd.7                          up  1.00000          1.00000
10  1.09000         osd.10                         up  1.00000          1.00000
-4  4.35999     host pod1-osd-compute-1
 2  1.09000         osd.2                          up  1.00000          1.00000
 5  1.09000         osd.5                          up  1.00000          1.00000
 8  1.09000         osd.8                          up  1.00000          1.00000
11  1.09000         osd.11                         up  1.00000          1.00000
-5  4.35999     host pod1-osd-compute-3
 0  1.09000         osd.0                          up  1.00000          1.00000
 3  1.09000         osd.3                          up  1.00000          1.00000
 6  1.09000         osd.6                          up  1.00000          1.00000
 9  1.09000         osd.9                          up  1.00000          1.00000

Restaurer les machines virtuelles

Récupérer une instance avec un snapshot

Il est possible de redéployer l'instance précédente avec l'instantané effectué lors des étapes précédentes.

Étape 1. (Facultatif) S'il n'y a pas de capture instantanée de machine virtuelle précédente disponible, connectez-vous au noeud OSPD où la sauvegarde a été envoyée et redirigez la sauvegarde vers son noeud OSPD d'origine. L'utilisation de sftp root@x.x.x.xwhere x.x.x.x est l'adresse IP d'un OSPD d'origine. Enregistrez le fichier d'instantané dans le répertoire /tmp.

Étape 2. Connectez-vous au noeud OSPD où l'instance est redéployée.

Source des variables d'environnement avec cette commande :

             

 # source /home/stack/pod1-stackrc-Core-CPAR

Étape 3. Pour utiliser l'instantané comme image, il est nécessaire de le télécharger sur horizon en tant que tel. Exécutez la commande suivante pour cela.

#glance image-create -- AAA-CPAR-Date-snapshot.qcow2 --container-format bare --disk-format qcow2 --name AAA-CPAR-Date-snapshot

Le processus peut être vu dans l'horizon comme illustré dans cette image.

Étape 4. Dans Horizon, accédez à Project > Instances et cliquez sur Lauch Instance comme illustré dans cette image.

Étape 5. Entrez le nom de l'instance et choisissez la zone de disponibilité comme indiqué dans cette image.

Étape 6. Dans l'onglet Source, sélectionnez l'image afin de créer l'instance. Dans le menu Sélectionner la source de démarrage, sélectionnez image, une liste d'images s'affiche, choisissez celle qui a été précédemment téléchargée par cliquet sur son +signe et comme indiqué dans cette image.

Étape 7. Dans l'onglet Flavor, choisissez la saveur AAA en cliquant sur le +signe tel qu'indiqué dans cette image.

Étape 8. Enfin, accédez à l'onglet Réseau et choisissez les réseaux dont l'instance a besoin en cliquant sur le signe +. Dans ce cas, sélectionnez diamètre-soutable1, radius-routable1 et tb1-mgmt comme indiqué dans cette image.

Étape 9. Enfin, cliquez sur Lancer l'instance pour la créer. La progression peut être surveillée dans Horizon comme le montre cette image.

Après quelques minutes, l'instance sera complètement déployée et prête à être utilisée.

Créer et attribuer une adresse IP flottante

Une adresse IP flottante est une adresse routable, ce qui signifie qu'elle est accessible depuis l'extérieur de l'architecture Ultra M/Openstack et qu'elle peut communiquer avec d'autres noeuds du réseau.

Étape 1. Dans le menu supérieur Horizon, accédez à Admin > Floating IPs.

Étape 2. Cliquez sur Allouer IP au projet.

Étape 3. Dans la fenêtre Allouer une adresse IP flottante, sélectionnez le pool auquel appartient la nouvelle adresse IP flottante, le projet où elle sera affectée et la nouvelle adresse IP flottante elle-même.

Exemple :

                                                       

Étape 4. Cliquez sur Allouer IP flottante.

Étape 5. Dans le menu supérieur Horizon, accédez à Project > Instances.

Étape 6. Dans la colonne Action, cliquez sur la flèche pointant vers le bas dans le bouton Créer un instantané, un menu doit être affiché. Sélectionnez l'option Associer une adresse IP flottante.

Étape 7. Sélectionnez l'adresse IP flottante correspondante à utiliser dans le champ Adresse IP, puis choisissez l'interface de gestion correspondante (eth0) dans la nouvelle instance où cette adresse IP flottante sera attribuée dans le port à associer. Reportez-vous à l'image suivante comme exemple de cette procédure.

Étape 8. Enfin, cliquez sur Associer.

Activer SSH

Étape 1. Dans le menu supérieur Horizon, accédez à Project > Instances.

Étape 2. Cliquez sur le nom de l'instance/de la machine virtuelle créée dans la section Déjeuner une nouvelle instance.

Étape 3. Cliquez sur Console. L'interface de ligne de commande de la machine virtuelle s'affiche.

Étape 4. Une fois l'interface de ligne de commande affichée, saisissez les informations d'identification de connexion appropriées :

username (nom d’utilisateur) : racine

Mot de passe : cisco123 comme illustré dans cette image.

Étape 5. Dans l'interface de ligne de commande, exécutez la commande vi /etc/ssh/sshd_config afin de modifier la configuration ssh.

Étape 6. Une fois le fichier de configuration SSH ouvert, appuyez sur I afin de modifier le fichier. Recherchez ensuite la section affichée ici et modifiez la première ligne de PasswordAuthentication no à PasswordAuthentication yes.

Étape 7. Appuyez sur Échap et saisissez :wq! pour enregistrer les modifications du fichier sshd_config.

Étape 8. Exécutez la commande service sshd restart.

Étape 9. Afin de tester les modifications de configuration SSH correctement appliquées, ouvrez n'importe quel client SSH et essayez d'établir une connexion sécurisée à distance à l'aide de l'adresse IP flottante attribuée à l'instance (c'est-à-dire 10.145.0.249) et à la racine utilisateur.

Établir une session SSH

Étape 1. Ouvrez une session SSH avec l'adresse IP de la machine virtuelle/serveur correspondante sur laquelle l'application est installée, comme illustré dans cette image.

Début de l'instance CPAR

Suivez ces étapes, une fois l'activité terminée et que les services CPAR peuvent être rétablis sur le site qui a été arrêté.

Étape 1. Reconnectez-vous à Horizon, accédez à Project > Instance > Start Instance.

Étape 2. Vérifiez que l'état de l'instance est Actif et que l'état d'alimentation est En cours d'exécution comme indiqué dans cette image.

Vérification de l'intégrité après l'activité

Étape 1. Exécutez la commande /opt/CSCOar/bin/arstatus au niveau du système d'exploitation :

[root@wscaaa04 ~]# /opt/CSCOar/bin/arstatus
Cisco Prime AR RADIUS server running       (pid: 24834)
Cisco Prime AR Server Agent running        (pid: 24821)
Cisco Prime AR MCD lock manager running    (pid: 24824)
Cisco Prime AR MCD server running          (pid: 24833)
Cisco Prime AR GUI running (pid: 24836)
SNMP Master Agent running                (pid: 24835)
[root@wscaaa04 ~]#

Étape 2. Exécutez la commande /opt/CSCOar/bin/aregcmd au niveau du système d'exploitation et entrez les informations d'identification de l'administrateur. Vérifiez que l'état CPAr est 10 sur 10 et quittez l'interface CLI CPAR.

[root@aaa02 logs]# /opt/CSCOar/bin/aregcmd
Cisco Prime Access Registrar 7.3.0.1 Configuration Utility
Copyright (C) 1995-2017 by Cisco Systems, Inc.  All rights reserved.
Cluster:
User: admin
Passphrase:
Logging in to localhost
[ //localhost ]
      LicenseInfo = PAR-NG-TPS 7.2(100TPS:)

PAR-ADD-TPS 7.2(2000TPS:)

PAR-RDDR-TRX 7.2()

PAR-HSS 7.2()

Radius/

Administrators/
Server 'Radius' is Running, its health is 10 out of 10
--> exit

  

Étape 3. Exécutez la commande netstat | grand diamètre et vérifiez que toutes les connexions DRA sont établies.

  

Le résultat mentionné ici est pour un environnement où des liaisons de diamètre sont attendues. Si moins de liens sont affichés, cela représente une déconnexion du DRA qui doit être analysée.

[root@aa02 logs]# netstat | grep diameter
tcp         0            0 aaa02.aaa.epc.:77 mp1.dra01.d:diameter ESTABLISHED
tcp         0            0 aaa02.aaa.epc.:36 tsa6.dra01:diameter ESTABLISHED
tcp         0            0 aaa02.aaa.epc.:47 mp2.dra01.d:diameter ESTABLISHED
tcp         0            0 aaa02.aaa.epc.:07 tsa5.dra01:diameter ESTABLISHED
tcp         0            0 aaa02.aaa.epc.:08 np2.dra01.d:diameter ESTABLISHED

  

Étape 4. Vérifiez que le journal TPS affiche les demandes traitées par CPAR. Les valeurs mises en évidence représentent le TPS et celles-ci sont celles auxquelles vous devez prêter attention.

La valeur de TPS ne doit pas dépasser 1 500.

[root@wscaaa04 ~]# tail -f /opt/CSCOar/logs/tps-11-21-2017.csv
11-21-2017,23:57:35,263,0
11-21-2017,23:57:50,237,0
11-21-2017,23:58:05,237,0
11-21-2017,23:58:20,257,0
11-21-2017,23:58:35,254,0
11-21-2017,23:58:50,248,0
11-21-2017,23:59:05,272,0
11-21-2017,23:59:20,243,0
11-21-2017,23:59:35,244,0
11-21-2017,23:59:50,233,0

Étape 5. Recherchez tous les messages d'erreur “ ” ou de ” d'alarme “ dans name_radius_1_log.

  

[root@aaa02 logs]# grep -E "error|alarm" name_radius_1_log 

Étape 6. Afin de vérifier la quantité de mémoire utilisée par le processus CPAR, exécutez la commande :

top | grep radius
[root@sfraaa02 ~]# top | grep radius
27008 root      20   0 20.228g 2.413g  11408 S 128.3  7.7   1165:41 radius

Cette valeur mise en surbrillance doit être inférieure à 7 Go, ce qui correspond au maximum autorisé au niveau de l'application.