Composants modulaires RMA-PCRF
Options de téléchargement
-
ePub (88.1 KB)
Consulter à l’aide de différentes applications sur iPhone, iPad, Android ou Windows Phone -
Mobi (Kindle) (91.1 KB)
Consulter sur un appareil Kindle ou à l’aide d’une application Kindle sur plusieurs appareils
Langage exempt de préjugés
Dans le cadre de la documentation associée à ce produit, nous nous efforçons d’utiliser un langage exempt de préjugés. Dans cet ensemble de documents, le langage exempt de discrimination renvoie à une langue qui exclut la discrimination en fonction de l’âge, des handicaps, du genre, de l’appartenance raciale de l’identité ethnique, de l’orientation sexuelle, de la situation socio-économique et de l’intersectionnalité. Des exceptions peuvent s’appliquer dans les documents si le langage est codé en dur dans les interfaces utilisateurs du produit logiciel, si le langage utilisé est basé sur la documentation RFP ou si le langage utilisé provient d’un produit tiers référencé. Découvrez comment Cisco utilise le langage inclusif.
À propos de cette traduction
Cisco a traduit ce document en traduction automatisée vérifiée par une personne dans le cadre d’un service mondial permettant à nos utilisateurs d’obtenir le contenu d’assistance dans leur propre langue. Il convient cependant de noter que même la meilleure traduction automatisée ne sera pas aussi précise que celle fournie par un traducteur professionnel.
Contenu
Introduction
Ce document décrit les étapes requises pour remplacer les composants défectueux mentionnés ici dans un serveur Cisco Unified Computing System (UCS) dans une configuration Ultra-M qui héberge les fonctions de réseau virtuel (VNF) de Cisco Policy Suite (CPS).
- Module de mémoire DIMM (Dual In-line Memory Module) de remplacement
- Défaillance du contrôleur FlexFlash
- Défaillance du disque dur SSD (Solid State Drive)
- Défaillance du module de plateforme sécurisée (TPM)
- Échec du cache RAID
- Panne du contrôleur RAID/adaptateur HBA (Hot Bus Adapter)
- Panne de montage PCI
- Carte PCIe Intel X520 10G en panne
- Défaillance de la carte mère LAN-on modulaire (MLOM)
- Unité de ventilation RMA
- Défaillance du processeur
Contribué par Nitesh Bansal, Cisco Advance Services.
Informations générales
Ultra-M est une solution virtualisée préemballée et validée conçue pour simplifier le déploiement des VNF. OpenStack est le gestionnaire d'infrastructure virtualisée (VIM) pour Ultra-M et comprend les types de noeuds suivants :
- Calcul
- Disque de stockage d'objets - Calcul (OSD - Calcul)
- Contrôleur
- Plate-forme OpenStack - Director (OSPD)
- La version Ultra M 5.1.x est prise en compte pour définir les procédures de ce document.
- Ce document est destiné au personnel Cisco familier avec la plate-forme Cisco Ultra-M et décrit les étapes à suivre au niveau OpenStack et CPS VNF au moment du remplacement de composants sur le serveur.
Avant de remplacer un composant défectueux, il est important de vérifier l'état actuel de l'environnement de plate-forme Red Hat Open Stack. Il est recommandé de vérifier l'état actuel afin d'éviter les complications lorsque le processus de remplacement est activé.
En cas de récupération, Cisco recommande de procéder à la sauvegarde de la base de données OSPD à l'aide des étapes suivantes :
[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é des instances.
Note: Si un serveur est un noeud contrôleur, passez à la section , sinon passez à la section suivante.
Abréviations
| VNF |
Fonction de réseau virtuel |
| PD |
Policy Director (équilibreur de charge) |
| PS |
Policy Server ( pcrfclient ) |
| Échap |
Contrôleur de service flexible |
| MOP |
Méthode de procédure |
| OSD |
Disques de stockage d'objets |
| HDD |
Disque dur |
| SSD |
Disque dur SSD |
| VIM |
Gestionnaire d'infrastructure virtuelle |
| VM |
Machine virtuelle |
| SM |
Gestionnaire de session |
| QNS |
Serveur de noms Quantum |
| UUID |
Identificateur unique |
Dépannage de RMA de composant - Noeud Compute/OSD-Compute
Étape 1. Arrêt gracieux
Identifier les machines virtuelles hébergées dans le noeud Compute/OSD-Compute
Le calcul/OSD-Compute peut héberger plusieurs types de VM. Identifiez toutes les étapes et poursuivez avec le noeud sans système d'exploitation particulier et pour les noms de machines virtuelles spécifiques hébergés sur ce calcul :
[stack@director ~]$ nova list --field name,host | grep compute-10 | 49ac5f22-469e-4b84-badc-031083db0533 | SVS1-tmo_cm_0_e3ac7841-7f21-45c8-9f86-3524541d6634 | pod1-compute-10.localdomain | | 49ac5f22-469e-4b84-badc-031083db0533 | SVS1-tmo_sm-s3_0_05966301-bd95-4071-817a-0af43757fc88 | pod1-compute-10.localdomain |
Pour l'arrêt gracieux de la machine virtuelle du Gestionnaire de cluster
Étape 1. Créez un snapshot et FTP du fichier vers un autre emplacement en dehors du serveur ou, si possible, en dehors du rack lui-même.
openstack image create --poll
Étape 2. Arrêter la machine virtuelle de l'ESC.
/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli vm-action STOP < CM vm-name>
Étape 3. Vérifiez si la machine virtuelle est arrêtée.
[admin@esc ~]$ cd /opt/cisco/esc/esc-confd/esc-cli [admin@esc ~]$ ./esc_nc_cli get esc_datamodel | egrep --color "<state>|<vm_name>|<vm_id>|<deployment_name>" <snip> <state>SERVICE_ACTIVE_STATE</state> SVS1-tmo_cm_0_e3ac7841-7f21-45c8-9f86-3524541d6634 VM_SHUTOFF_STATE
Pour l'arrêt gracieux de la machine virtuelle PD/équilibreur de charge actif
Étape 1. Connectez-vous à la bibliothèque active et arrêtez les services comme ci-dessous
- Basculer de actif en veille
service corosync restart
- arrêter les services sur l'adaptateur de secours
service monit stop service qns stop
Étape 2. À partir du maître ESC.
/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli vm-action STOP < Standby PD vm-name>
Étape 3. Vérifiez si la machine virtuelle est arrêtée.
admin@esc ~]$ cd /opt/cisco/esc/esc-confd/esc-cli
[admin@esc ~]$ ./esc_nc_cli get esc_datamodel | egrep --color "
|
|
|
"
SERVICE_ACTIVE_STATE
SVS1-tmo_cm_0_e3ac7841-7f21-45c8-9f86-3524541d6634 VM_SHUTOFF_STATE
Pour la mise hors tension gracieuse de la machine virtuelle PD/équilibreur de charge de secours
Étape 1. Connectez-vous à la bibliothèque de secours et arrêtez les services.
service monit stop service qns stop
Étape 2. À partir du maître ESC.
/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli vm-action STOP < Standby PD vm-name>
Étape 3. Vérifiez si la machine virtuelle est arrêtée.
[admin@esc ~]$ cd /opt/cisco/esc/esc-confd/esc-cli
[admin@esc ~]$ ./esc_nc_cli get esc_datamodel | egrep --color "
|
|
|
"
SERVICE_ACTIVE_STATE
SVS1-tmo_cm_0_e3ac7841-7f21-45c8-9f86-3524541d6634 VM_SHUTOFF_STATE
Pour l'arrêt gracieux de la machine virtuelle PS/QNS
Étape 1. Arrêter le service :
service monit stop service qns stop
Étape 2. À partir du maître ESC.
/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli vm-action STOP < PS vm-name>
Étape 3. Vérifiez si la machine virtuelle est arrêtée.
[dmin@esc ~]$ cd /opt/cisco/esc/esc-confd/esc-cli
[dmin@esc ~]$ ./esc_nc_cli get esc_datamodel | egrep --color "
|
|
|
"
SERVICE_ACTIVE_STATE
SVS1-tmo_cm_0_e3ac7841-7f21-45c8-9f86-3524541d6634 VM_SHUTOFF_STATE
Pour la mise hors tension gracieuse de la machine virtuelle SM
Étape 1. Arrêtez tous les services de mongo présents dans sessionmgr.
[root@sessionmg01 ~]# cd /etc/init.d [root@sessionmg01 init.d]# ls -l sessionmgr* [root@sessionmg01 ~]# /etc/init.d/sessionmgr-27717 stop Stopping mongod: [ OK ] [root@ sessionmg01 ~]# /etc/init.d/sessionmgr-27718 stop Stopping mongod: [ OK ] [root@ sessionmg01 ~]# /etc/init.d/sessionmgr-27719 stop Stopping mongod: [ OK ]
Étape 2. À partir du maître ESC.
/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli vm-action STOP < PS vm-name>
Étape 3. Vérifiez si la machine virtuelle est arrêtée.
[admin@esc ~]$ cd /opt/cisco/esc/esc-confd/esc-cli
[admin@esc ~]$ ./esc_nc_cli get esc_datamodel | egrep --color "
|
|
|
"
SERVICE_ACTIVE_STATE
SVS1-tmo_cm_0_e3ac7841-7f21-45c8-9f86-3524541d6634 VM_SHUTOFF_STATE
Pour l'arrêt gracieux de la machine virtuelle OAM/pcrfclient
Étape 1. Vérifiez si le SVN de stratégie est synchronisé à l'aide de ces commandes. Si une valeur est renvoyée, le SVN est déjà synchronisé et vous n'avez pas besoin de la synchroniser à partir de PCRFCLIENT02. Vous devez ignorer la récupération de la dernière sauvegarde peut toujours être utilisée si nécessaire.
/usr/bin/svn propget svn:sync-from-url --revprop -r0 http://pcrfclient01/repos
Étape 2. Rétablir la synchronisation maître/esclave SVN entre pcrfclient01 et pcrfclient02 avec pcrfclient01 comme maître en exécutant la série de commandes sur PCRFCLIENT01.
/bin/rm -fr /var/www/svn/repos /usr/bin/svnadmin create /var/www/svn/repos /usr/bin/svn propset --revprop -r0 svn:sync-last-merged-rev 0 http://pcrfclient02/repos-proxy-sync /usr/bin/svnadmin setuuid /var/www/svn/repos/ "Enter the UUID captured in step 2" /etc/init.d/vm-init-client /var/qps/bin/support/recover_svn_sync.sh
Étape 3. Effectuez une sauvegarde du SVN dans le gestionnaire de clusters.
config_br.py -a export --svn /mnt/backup/svn_backup_pcrfclient.tgz
Étape 4. Arrêtez les services dans pcrfclient.
service monit stop service qns stop
Étape 5. Du maître ESC :
/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli vm-action STOP < pcrfclient vm-name>
Étape 6. Vérifiez si la machine virtuelle est arrêtée.
[admin@esc ~]$ cd /opt/cisco/esc/esc-confd/esc-cli
[admin@esc ~]$ ./esc_nc_cli get esc_datamodel | egrep --color "
|
|
|
"
SERVICE_ACTIVE_STATE
SVS1-tmo_cm_0_e3ac7841-7f21-45c8-9f86-3524541d6634 VM_SHUTOFF_STATE
Pour la machine virtuelle arbitre
Étape 1. Connectez-vous à l'arbitre et arrêtez les services.
[root@SVS1OAM02 init.d]# ls -lrt sessionmgr* -rwxr-xr-x 1 root root 4382 Jun 21 07:34 sessionmgr-27721 -rwxr-xr-x 1 root root 4406 Jun 21 07:34 sessionmgr-27718 -rwxr-xr-x 1 root root 4407 Jun 21 07:34 sessionmgr-27719 -rwxr-xr-x 1 root root 4429 Jun 21 07:34 sessionmgr-27717 -rwxr-xr-x 1 root root 4248 Jun 21 07:34 sessionmgr-27720
service monit stop service qns stop
/etc/init.d/sessionmgr-[portno.] stop , where port no is the db port in the arbiter.
Étape 2.À partir du maître ESC
/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli vm-action STOP < pcrfclient vm-name>
Étape 3. Vérifiez si la machine virtuelle est arrêtée.
[admin@esc ~]$ cd /opt/cisco/esc/esc-confd/esc-cli
[admin@esc ~]$ ./esc_nc_cli get esc_datamodel | egrep --color "
|
|
|
"
SERVICE_ACTIVE_STATE
SVS1-tmo_cm_0_e3ac7841-7f21-45c8-9f86-3524541d6634 VM_SHUTOFF_STATE
Pour le contrôleur de services élastiques (ESC)
Étape 1. Les configurations de l'ESC-HA doivent être sauvegardées tous les mois, avant/après toute opération d'évolutivité ou de réduction avec le VNF et avant/après les modifications de configuration à l'ESC. Il convient de le renforcer afin d'assurer une reprise après sinistre de l'ESC de manière efficace
- Connectez-vous à l'ESC à l'aide des informations d'identification et de connexion admin et exportez les données opdata au format XML.
/opt/cisco/esc/confd/bin/netconf-console --host 127.0.0.1 --port 830 -u-p --get-config > /home/admin/ESC_config.xml - Téléchargez ce fichier sur votre ordinateur local de ftp/sftp vers un serveur en dehors du cloud.
Étape 2. Sauvegarder la configuration du cloud PCRF Tous les scripts et fichiers de données utilisateur référencés dans les XML de déploiement.
- Rechercher tous les fichiers de données utilisateur référencés dans les XML de déploiement de tous les VNF à partir des opdata exportés à l'étape précédente.Exemple de sortie.
file://opt/cisco/esc/cisco-cps/config/gr/cfg/std/pcrf-cm_cloud.cfg file://opt/cisco/esc/cisco-cps/config/gr/cfg/std/pcrf-oam_cloud.cfg file://opt/cisco/esc/cisco-cps/config/gr/cfg/std/pcrf-pd_cloud.cfg file://opt/cisco/esc/cisco-cps/config/gr/cfg/std/pcrf-qns_cloud.cfg file://opt/cisco/esc/cisco-cps/config/gr/cfg/std/pcrf-sm_cloud.cfg - Recherchez tous les scripts de post-déploiement utilisés pour envoyer l'API d'orchestration CPS.
- Exemples de scripts de post-déploiement dans esc opdata.
Exemple 1 :
PCRF_POST_DEPLOYMENT
LCS::POST_DEPLOY_ALIVE
FINISH_PCRF_INSTALLATION
SCRIPT
----------
script_filename
/opt/cisco/esc/cisco-cps/config/gr/tmo/cfg/../cps_init.py
script_timeout
3600
Exemple 2 :
PCRF_POST_DEPLOYMENT
LCS::POST_DEPLOY_ALIVE
FINISH_PCRF_INSTALLATION
SCRIPT
CLUMAN_MGMT_ADDRESS
10.174.132.46
CLUMAN_YAML_FILE
/opt/cisco/esc/cisco-cps/config/vpcrf01/ cluman_orch_config.yaml
script_filename
/opt/cisco/esc/cisco-cps/config/vpcrf01/vpcrf_cluman_post_deployment.py
wait_max_timeout
3600
Si les opdata de l'ESC de déploiement (extraites à l'étape précédente) contiennent l'un des fichiers mis en surbrillance, effectuez la sauvegarde.
Exemple de commande de sauvegarde :
tar –zcf esc_files_backup.tgz /opt/cisco/esc/cisco-cps/config/
Téléchargez ce fichier sur votre ordinateur local de ftp/sftp vers un serveur en dehors du cloud.
Note:- Although opdata is synced between ESC master and slave, directories containing user-data, xml and post deploy scripts are not synced across both instances. It is suggested that customers can push the contents of directory containing these files using scp or sftp, these files should be constant across ESC-Master and ESC-Standby in order to recover a deployment when ESC VM which was master during deployment is not available do to any unforeseen circumstances.
Étape 2. Sauvegarde de base de données ESC.
Étape 1. Collectez les journaux des machines virtuelles ESC deux et sauvegardez-les.
$ collect_esc_log.sh
$ scp /tmp/
@
:
Étape 2. Sauvegarder la base de données à partir du noeud ECS maître.
Étape 3. Passez à l'utilisateur racine et vérifiez l'état de l'ESC principal et validez que la valeur de sortie est Master.
$ sudo bash $ escadm status Set ESC to maintenance mode & verify $ sudo escadm op_mode set --mode=maintenance $ escadm op_mode show
Étape 4. Utilisez une variable pour définir le nom du fichier, inclure les informations de date et appeler l'outil de sauvegarde et fournir la variable de nom de fichier de l'étape précédente.
fname=esc_db_backup_$(date -u +"%y-%m-%d-%H-%M-%S") $ sudo /opt/cisco/esc/esc-scripts/esc_dbtool.py backup -- file /tmp/atlpod-esc-master-$fname.tar
Étape 5. Vérifiez le fichier de sauvegarde dans votre stockage de sauvegarde et assurez-vous qu'il est présent.
Étape 6. Remettez l'ESC Master en mode de fonctionnement normal.
$ sudo escadm op_mode set --mode=operation
Si l'utilitaire de sauvegarde dbtool échoue, appliquez la solution de contournement suivante une fois dans le noeud ESC. Répétez ensuite l'étape 6.
$ sudo sed -i "s,'pg_dump,'/usr/pgsql-9.4/bin/pg_dump," /opt/cisco/esc/esc-scripts/esc_dbtool.py
Étape 3. Migrer l'ESC en mode veille.
Étape 1. Connectez-vous à l'ESC hébergé dans le noeud et vérifiez qu'il est à l'état maître. Si oui, passez en mode veille.
[admin@VNF2-esc-esc-0 esc-cli]$ escadm status 0 ESC status=0 ESC Master Healthy [admin@VNF2-esc-esc-0 ~]$ sudo service keepalived stop Stopping keepalived: [ OK ] [admin@VNF2-esc-esc-0 ~]$ escadm status 1 ESC status=0 In SWITCHING_TO_STOP state. Please check status after a while. [admin@VNF2-esc-esc-0 ~]$ sudo reboot Broadcast message from admin@vnf1-esc-esc-0.novalocal (/dev/pts/0) at 13:32 ... The system is going down for reboot NOW!
Étape 2. Une fois que la machine virtuelle est en veille ESC, arrêtez la machine virtuelle à l'aide de la commande shutdown -r now
Note: Si le composant défectueux doit être remplacé sur le noeud OSD-Compute, mettez le CEPH dans Maintenance sur le serveur avant de procéder au remplacement du composant.
[admin@osd-compute-0 ~]$ sudo ceph osd set norebalance
set norebalance
[admin@osd-compute-0 ~]$ sudo ceph osd set noout
set noout
[admin@osd-compute-0 ~]$ sudo ceph status
cluster eb2bb192-b1c9-11e6-9205-525400330666
health HEALTH_WARN
noout,norebalance,sortbitwise,require_jewel_osds flag(s) set
monmap e1: 3 mons at {tb3-ultram-pod1-controller-0=11.118.0.40:6789/0,tb3-ultram-pod1-controller-1=11.118.0.41:6789/0,tb3-ultram-pod1-controller-2=11.118.0.42:6789/0}
election epoch 58, quorum 0,1,2 tb3-ultram-pod1-controller-0,tb3-ultram-pod1-controller-1,tb3-ultram-pod1-controller-2
osdmap e194: 12 osds: 12 up, 12 in
flags noout,norebalance,sortbitwise,require_jewel_osds
pgmap v584865: 704 pgs, 6 pools, 531 GB data, 344 kobjects
1585 GB used, 11808 GB / 13393 GB avail
704 active+clean
client io 463 kB/s rd, 14903 kB/s wr, 263 op/s rd, 542 op/s wr
Étape 4. Remplacez le composant défectueux du noeud Compute/OSD-Compute.
Mettez le serveur spécifié hors tension. Pour remplacer un composant défectueux sur le serveur UCS C240 M4, procédez comme suit :
Remplacement des composants du serveur
Reportez-vous à la procédure Connexion permanente ci-dessous et exécutez-la si nécessaire.
Étape 5. Restaurer les machines virtuelles
Récupération VM de l'ESC
- La machine virtuelle serait dans l'état d'erreur dans la liste nova.
[stack@director ~]$ nova list |grep VNF2-DEPLOYM_s9_0_8bc6cc60-15d6-4ead-8b6a-10e75d0e134d | 49ac5f22-469e-4b84-badc-031083db0533 | VNF2-DEPLOYM_s9_0_8bc6cc60-15d6-4ead-8b6a-10e75d0e134d | ERROR | - | NOSTATE |
- Récupérez les machines virtuelles à partir de l'ESC.
[admin@VNF2-esc-esc-0 ~]$ sudo /opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli recovery-vm-action DO VNF2-DEPLOYM_s9_0_8bc6cc60-15d6-4ead-8b6a-10e75d0e134d [sudo] password for admin: Recovery VM Action /opt/cisco/esc/confd/bin/netconf-console --port=830 --host=127.0.0.1 --user=admin --privKeyFile=/root/.ssh/confd_id_dsa --privKeyType=dsa --rpc=/tmp/esc_nc_cli.ZpRCGiieuW - Surveillez la yangesc.log
admin@VNF2-esc-esc-0 ~]$ tail -f /var/log/esc/yangesc.log … 14:59:50,112 07-Nov-2017 WARN Type: VM_RECOVERY_COMPLETE 14:59:50,112 07-Nov-2017 WARN Status: SUCCESS 14:59:50,112 07-Nov-2017 WARN Status Code: 200 14:59:50,112 07-Nov-2017 WARN Status Msg: Recovery: Successfully recovered VM [VNF2-DEPLOYM_s9_0_8bc6cc60-15d6-4ead-8b6a-10e75d0e134d].
- Vérifiez tous les services des machines virtuelles en cours de démarrage.
Récupération de la machine virtuelle ESC
- Connectez-vous à l'ESC via la console et vérifiez l'état.
- Démarrer les processus si ce n'est déjà fait
[admin@esc ~]$ sudo service keepalived start
[admin@esc ~]$ escadm status 0 ESC status=0 ESC Slave Healthy
Manipulation de l'échec de récupération ESC
Dans les cas où l'ESC ne démarre pas la machine virtuelle en raison d'un état inattendu, Cisco recommande d'effectuer une commutation ESC en redémarrant l'ESC principal. Le passage à l'ESC prendrait environ une minute. Exécutez le script “ health.sh ” sur le nouvel ESC maître pour vérifier si l'état est actif. Master ESC pour démarrer la machine virtuelle et régler l'état de la machine virtuelle. Cette tâche de récupération prend jusqu'à 5 minutes.
Vous pouvez surveiller /var/log/esc/yangesc.log et /var/log/esc/escmanager.log. Si vous ne voyez PAS la récupération de la machine virtuelle après 5 à 7 minutes, l'utilisateur doit effectuer la récupération manuelle des machines virtuelles affectées.
Si la machine virtuelle ESC n'est pas restaurée, suivez la procédure de déploiement d'une nouvelle machine virtuelle ESC. Contactez l'assistance Cisco pour connaître la procédure.
Dépannage de la RMA de composant - Noeud contrôleur
Étape 1. Contrôleur - Précontrôles
À partir d'OSPD, connectez-vous au contrôleur et vérifiez que les ordinateurs sont dans un bon état : les trois contrôleurs en ligne et la galère affichant les trois contrôleurs en tant que maîtres.
Note: Un cluster sain nécessite 2 contrôleurs actifs, donc vérifiez que les deux autres contrôleurs sont en ligne et actifs.
heat-admin@pod1-controller-0 ~]$ sudo pcs status Cluster name: tripleo_cluster Stack: corosync Current DC: pod1-controller-2 (version 1.1.15-11.el7_3.4-e174ec8) - partition with quorum Last updated: Mon Dec 4 00:46:10 2017 Last change: Wed Nov 29 01:20:52 2017 by hacluster via crmd on pod1-controller-0 3 nodes and 22 resources configured Online: [ pod1-controller-0 pod1-controller-1 pod1-controller-2 ] Full list of resources: ip-11.118.0.42 (ocf::heartbeat:IPaddr2): Started pod1-controller-1 ip-11.119.0.47 (ocf::heartbeat:IPaddr2): Started pod1-controller-2 ip-11.120.0.49 (ocf::heartbeat:IPaddr2): Started pod1-controller-1 ip-192.200.0.102 (ocf::heartbeat:IPaddr2): Started pod1-controller-2 Clone Set: haproxy-clone [haproxy] Started: [ pod1-controller-0 pod1-controller-1 pod1-controller-2 ] Master/Slave Set: galera-master [galera] Masters: [ pod1-controller-0 pod1-controller-1 pod1-controller-2 ] ip-11.120.0.47 (ocf::heartbeat:IPaddr2): Started pod1-controller-2 Clone Set: rabbitmq-clone [rabbitmq] Started: [ pod1-controller-0 pod1-controller-1 pod1-controller-2 ] Master/Slave Set: redis-master [redis] Masters: [ pod1-controller-2 ] Slaves: [ pod1-controller-0 pod1-controller-1 ] ip-10.84.123.35 (ocf::heartbeat:IPaddr2): Started pod1-controller-1 openstack-cinder-volume (systemd:openstack-cinder-volume): Started pod1-controller-2 my-ipmilan-for-pod1-controller-0 (stonith:fence_ipmilan): Started pod1-controller-0 my-ipmilan-for-pod1-controller-1 (stonith:fence_ipmilan): Started pod1-controller-0 my-ipmilan-for-pod1-controller-2 (stonith:fence_ipmilan): Started pod1-controller-0 Daemon Status: corosync: active/enabled pacemaker: active/enabled pcsd: active/enabled
Étape 2. Déplacer le cluster du contrôleur en mode Maintenance.
- Mettre le cluster pc sur le contrôleur en cours de mise à jour en veille.
[heat-admin@pod1-controller-0 ~]$ sudo pcs cluster standby
- Vérifiez à nouveau l'état des ordinateurs et assurez-vous que le cluster des ordinateurs s'est arrêté sur ce noeud.
[heat-admin@pod1-controller-0 ~]$ sudo pcs status Cluster name: tripleo_cluster Stack: corosync Current DC: pod1-controller-2 (version 1.1.15-11.el7_3.4-e174ec8) - partition with quorum Last updated: Mon Dec 4 00:48:24 2017 Last change: Mon Dec 4 00:48:18 2017 by root via crm_attribute on pod1-controller-0 3 nodes and 22 resources configured Node pod1-controller-0: standby Online: [ pod1-controller-1 pod1-controller-2 ] Full list of resources: ip-11.118.0.42 (ocf::heartbeat:IPaddr2): Started pod1-controller-1 ip-11.119.0.47 (ocf::heartbeat:IPaddr2): Started pod1-controller-2 ip-11.120.0.49 (ocf::heartbeat:IPaddr2): Started pod1-controller-1 ip-192.200.0.102 (ocf::heartbeat:IPaddr2): Started pod1-controller-2 Clone Set: haproxy-clone [haproxy] Started: [ pod1-controller-1 pod1-controller-2 ] Stopped: [ pod1-controller-0 ] Master/Slave Set: galera-master [galera] Masters: [ pod1-controller-1 pod1-controller-2 ] Slaves: [ pod1-controller-0 ] ip-11.120.0.47 (ocf::heartbeat:IPaddr2): Started pod1-controller-2 Clone Set: rabbitmq-clone [rabbitmq] Started: [ pod1-controller-0 pod1-controller-1 pod1-controller-2 ] Master/Slave Set: redis-master [redis] Masters: [ pod1-controller-2 ] Slaves: [ pod1-controller-1 ] Stopped: [ pod1-controller-0 ] ip-10.84.123.35 (ocf::heartbeat:IPaddr2): Started pod1-controller-1 openstack-cinder-volume (systemd:openstack-cinder-volume): Started pod1-controller-2 my-ipmilan-for-pod1-controller-0 (stonith:fence_ipmilan): Started pod1-controller-1 my-ipmilan-for-pod1-controller-1 (stonith:fence_ipmilan): Started pod1-controller-1 my-ipmilan-for-pod1-controller-2 (stonith:fence_ipmilan): Started pod1-controller-2 Daemon Status: corosync: active/enabled pacemaker: active/enabled pcsd: active/enabled
- L'état des ordinateurs sur les 2 autres contrôleurs doit également afficher le noeud en veille.
Étape 3. Remplacez le composant défectueux du noeud contrôleur.
Mettez le serveur spécifié hors tension. Pour remplacer un composant défectueux sur le serveur UCS C240 M4, procédez comme suit :
Remplacement des composants du serveur
Étape 4. Mettez le serveur sous tension.
- Mettez le serveur sous tension et vérifiez que le serveur est allumé.
[stack@tb5-ospd ~]$ source stackrc [stack@tb5-ospd ~]$ nova list |grep pod1-controller-0 | 1ca946b8-52e5-4add-b94c-4d4b8a15a975 | pod1-controller-0 | ACTIVE | - | Running | ctlplane=192.200.0.112 |
- Connectez-vous au contrôleur affecté, supprimez le mode veille en configurant unstandby. Vérifiez que le contrôleur est disponible en ligne avec le cluster et que la galère affiche les trois contrôleurs comme Master. Cela peut prendre quelques minutes.
[heat-admin@pod1-controller-0 ~]$ sudo pcs cluster unstandby [heat-admin@pod1-controller-0 ~]$ sudo pcs status Cluster name: tripleo_cluster Stack: corosync Current DC: pod1-controller-2 (version 1.1.15-11.el7_3.4-e174ec8) - partition with quorum Last updated: Mon Dec 4 01:08:10 2017 Last change: Mon Dec 4 01:04:21 2017 by root via crm_attribute on pod1-controller-0 3 nodes and 22 resources configured Online: [ pod1-controller-0 pod1-controller-1 pod1-controller-2 ] Full list of resources: ip-11.118.0.42 (ocf::heartbeat:IPaddr2): Started pod1-controller-1 ip-11.119.0.47 (ocf::heartbeat:IPaddr2): Started pod1-controller-2 ip-11.120.0.49 (ocf::heartbeat:IPaddr2): Started pod1-controller-1 ip-192.200.0.102 (ocf::heartbeat:IPaddr2): Started pod1-controller-2 Clone Set: haproxy-clone [haproxy] Started: [ pod1-controller-0 pod1-controller-1 pod1-controller-2 ] Master/Slave Set: galera-master [galera] Masters: [ pod1-controller-0 pod1-controller-1 pod1-controller-2 ] ip-11.120.0.47 (ocf::heartbeat:IPaddr2): Started pod1-controller-2 Clone Set: rabbitmq-clone [rabbitmq] Started: [ pod1-controller-0 pod1-controller-1 pod1-controller-2 ] Master/Slave Set: redis-master [redis] Masters: [ pod1-controller-2 ] Slaves: [ pod1-controller-0 pod1-controller-1 ] ip-10.84.123.35 (ocf::heartbeat:IPaddr2): Started pod1-controller-1 openstack-cinder-volume (systemd:openstack-cinder-volume): Started pod1-controller-2 my-ipmilan-for-pod1-controller-0 (stonith:fence_ipmilan): Started pod1-controller-1 my-ipmilan-for-pod1-controller-1 (stonith:fence_ipmilan): Started pod1-controller-1 my-ipmilan-for-pod1-controller-2 (stonith:fence_ipmilan): Started pod1-controller-2 Daemon Status: corosync: active/enabled pacemaker: active/enabled pcsd: active/enabled
- Vous pouvez vérifier certains services de surveillance, tels que la céphalée, qu'ils sont en bonne santé.
[heat-admin@pod1-controller-0 ~]$ sudo ceph -s cluster eb2bb192-b1c9-11e6-9205-525400330666 health HEALTH_OK monmap e1: 3 mons at {pod1-controller-0=11.118.0.10:6789/0,pod1-controller-1=11.118.0.11:6789/0,pod1-controller-2=11.118.0.12:6789/0} election epoch 70, quorum 0,1,2 pod1-controller-0,pod1-controller-1,pod1-controller-2 osdmap e218: 12 osds: 12 up, 12 in flags sortbitwise,require_jewel_osds pgmap v2080888: 704 pgs, 6 pools, 714 GB data, 237 kobjects 2142 GB used, 11251 GB / 13393 GB avail 704 active+clean client io 11797 kB/s wr, 0 op/s rd, 57 op/s wr
Contribution d’experts de Cisco
- Nitesh BansalCisco Advance Services
CommentairesContacter Cisco
- Ouvrir un dossier d’assistance
- (Un contrat de service de Cisco est requis)