Remplacement d'OSD-Compute UCS 240M4 - CPAR
Contenu
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.
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.
- Identifiez les machines virtuelles hébergées dans le noeud OSD-Compute.
- 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 |
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.
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)
- Connectez-vous à l'interface utilisateur graphique Horizon d'Openstack du POD.
- 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.
- Identifiez les machines virtuelles hébergées dans le noeud OSD-Compute.
- 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 |
- 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.
Mise hors tension gracieuse
- Noeud de mise hors tension
- Afin de mettre l'instance hors tension : nova stop <NOM_INSTANCE>
- 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.
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.
[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.
Commentaires