Inhoud

Inleiding

Achtergrondinformatie

Afkortingen

Werkstroom van de MoP

Moederbordvervanging in Ultra-M setup

Vervanging moederbord in computingsknooppunt

Identificeer de VM's die worden Hosted in het computing-knooppunt

GainMaker-voeding

Compact knooppunt en hosts CPS/ESC VM’s

ESC-back-up

Reserve ESC-database

Moederbord vervangen

De VM's herstellen

Compact knooppunt voor hosts CPS, ESC

De CPS VM’s herstellen

Moederbordvervanging in OSD computing-knooppunt

CEPH in onderhoudsmodus plaatsen

Identificeer de VM's die worden Hosted in het OSD-computing knooppunt

GainMaker-voeding

Case 1. OSD-computing knooppunten ESC

Moederbord vervangen

Verplaats CEPH uit de onderhoudsmodus

De VM's herstellen

Case 1. OSD-computing knooppunten die ESC of CPS ontvangen

Moederboard vervanging in controllerknooppunt

Controleer de controllerstatus en plaats de cluster in de onderhoudsmodus

Moederbord vervangen

Cluster status terugzetten

Inleiding

In dit document worden de stappen beschreven die vereist zijn om een defect moederbord van een server te vervangen in een Ultra-M installatie waarin CPS Virtual Network Functions (VPN’s) wordt opgeslagen.

Achtergrondinformatie

Ultra-M is een vooraf verpakte en gevalideerde gevirtualiseerde mobiele pakketoplossing die is ontworpen om de plaatsing van VNFs te vereenvoudigen. OpenStack is de Gevirtualiseerde Infrastructuur Manager (VIM) voor Ultra-M en bestaat uit deze knooptypen:

- berekenen

- Object Storage Disk - computing (OSD)

- Controller

- OpenStack Platform - Director (OSPF)

De hoge architectuur van Ultra-M en de betrokken onderdelen zijn in deze afbeelding weergegeven:

Dit document is bedoeld voor Cisco-personeel dat bekend is met het Cisco Ultra-M platform en bevat informatie over de stappen die moeten worden uitgevoerd op niveau van OpenStack en StarOS VPN op het moment dat het moederbord in een server wordt vervangen.

Opmerking: De Ultra M 5.1.x release wordt overwogen om de procedures in dit document te definiëren.

Afkortingen

VNF

Virtuele netwerkfunctie

ESC

Elastic Service Controller

MOP

Procedure

OSD

Objectopslaglocaties

HDD

Station vaste schijf

SSD

Solid State Drive

VIM

Virtual-infrastructuurbeheer

VM

Virtuele machine

EM

Element Manager

UAS

Ultra Automation Services

UUID

Universele unieke ID-versterker

Werkstroom van de MoP

Moederbordvervanging in Ultra-M setup

In een Ultra-M opstelling kunnen er scenario's zijn waar een vervanging van het moederbord in de volgende servertypes vereist is: Computeren, OSD-computing en controller.

Opmerking: De laarsschijven met de installatie van de opening worden vervangen na de vervanging van het moederbord. Daarom is het niet vereist het knooppunt weer aan de overcloud toe te voegen. Nadat de server is ingeschakeld na de vervangingsactiviteit, kan deze zich terugschrijven naar de overcloud-stapel.

Vervanging moederbord in computingsknooppunt

Voor de activiteit worden de VM's die in het computing-knooppunt worden gehost, scherp uitgeschakeld. Nadat het moederbord is vervangen, worden de VM's weer teruggezet.

Identificeer de VM's die worden Hosted in het computing-knooppunt

Identificeer de VM's die op de computerserver worden gehost.

De computerserver bevat CPS of Elastic Services Controller (ESC) VM’s:

[stack@director ~]$ nova list --field name,host | grep compute-8

| 507d67c2-1d00-4321-b9d1-da879af524f8 | VNF2-DEPLOYM_XXXX_0_c8d98f0f-d874-45d0-af75-88a2d6fa82ea | pod1-compute-8.localdomain     |

| f9c0763a-4a4f-4bbd-af51-bc7545774be2 | VNF2-DEPLOYM_c1_0_df4be88d-b4bf-4456-945a-3812653ee229     | pod1-compute-8.localdomain     |

| 75528898-ef4b-4d68-b05d-882014708694 | VNF2-ESC-ESC-0                                             | pod1-compute-8.localdomain     |

Opmerking:In de hier weergegeven output komt de eerste kolom overeen met de universeel-unieke IDentifier (UUID), de tweede kolom is de VM-naam en de derde kolom is de hostname waar de VM aanwezig is. De parameters uit deze uitvoer worden in de volgende secties gebruikt.

GainMaker-voeding

Compact knooppunt en hosts CPS/ESC VM’s

Stap 1. Meld u aan bij het ESC-knooppunt dat overeenkomt met de VNF en controleer de status van de VM's.

[admin@VNF2-esc-esc-0 ~]$ cd /opt/cisco/esc/esc-confd/esc-cli

[admin@VNF2-esc-esc-0 esc-cli]$ ./esc_nc_cli get esc_datamodel | egrep --color "<state>|<vm_name>|<vm_id>|<deployment_name>"

<snip>

<state>SERVICE_ACTIVE_STATE</state>

<vm_name>VNF2-DEPLOYM_c1_0_df4be88d-b4bf-4456-945a-3812653ee229</vm_name>

<state>VM_ALIVE_STATE</state>

<vm_name>VNF2-DEPLOYM_c3_0_3e0db133-c13b-4e3d-ac14-

<state>VM_ALIVE_STATE</state>

<deployment_name>VNF2-DEPLOYMENT-em</deployment_name>

<vm_id>507d67c2-1d00-4321-b9d1-da879af524f8</vm_id>

<vm_id>dc168a6a-4aeb-4e81-abd9-91d7568b5f7c</vm_id>

<vm_id>9ffec58b-4b9d-4072-b944-5413bf7fcf07</vm_id>

<state>SERVICE_ACTIVE_STATE</state>

<vm_name>VNF2-DEPLOYM_XXXX_0_c8d98f0f-d874-45d0-af75-88a2d6fa82ea</vm_name>

<state>VM_ALIVE_STATE</state>

<snip>

Stap 2. Stop de CPS VM's één voor één met het gebruik van de VM-naam. (VM-naam genoteerd uit paragraaf Identificeer de VM's die in het computingsknooppunt worden gehost).

[admin@VNF2-esc-esc-0 esc-cli]$ ./esc_nc_cli vm-action STOP VNF2-DEPLOYM_c1_0_df4be88d-b4bf-4456-945a-3812653ee229

[admin@VNF2-esc-esc-0 esc-cli]$ ./esc_nc_cli vm-action STOP VNF2-DEPLOYM_XXXX_0_c8d98f0f-d874-45d0-af75-88a2d6fa82ea

Stap 3. Nadat dit stopt, moeten de VM's de SHUTOFF-status invoeren.

[admin@VNF2-esc-esc-0 ~]$ cd /opt/cisco/esc/esc-confd/esc-cli

[admin@VNF2-esc-esc-0 esc-cli]$ ./esc_nc_cli get esc_datamodel | egrep --color "<state>|<vm_name>|<vm_id>|<deployment_name>"

<snip>

<state>SERVICE_ACTIVE_STATE</state>

<vm_name>VNF2-DEPLOYM_c1_0_df4be88d-b4bf-4456-945a-3812653ee229</vm_name>

<state>VM_SHUTOFF_STATE</state>

<vm_name>VNF2-DEPLOYM_c3_0_3e0db133-c13b-4e3d-ac14-

<state>VM_ALIVE_STATE</state>

<deployment_name>VNF2-DEPLOYMENT-em</deployment_name>

<vm_id>507d67c2-1d00-4321-b9d1-da879af524f8</vm_id>

<vm_id>dc168a6a-4aeb-4e81-abd9-91d7568b5f7c</vm_id>

<vm_id>9ffec58b-4b9d-4072-b944-5413bf7fcf07</vm_id>

<state>SERVICE_ACTIVE_STATE</state>

<vm_name>VNF2-DEPLOYM_XXXX_0_c8d98f0f-d874-45d0-af75-88a2d6fa82ea</vm_name>

VM_SHUTOFF_STATE

<snip>

Stap 4. Meld u aan bij het ESC dat in het computerknooppunt is opgeslagen en controleer of dit in de status van de master is. Zo ja, schakel ESC in op de stand-by modus:

[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!

ESC-back-up

Stap 1. ESC heeft 1:1 redundantie in UltraM-oplossing. 2 ESC-VM's worden ingezet en ondersteunen één storing in UltraM. d.w.z. het systeem wordt teruggewonnen indien het systeem één keer defect vertoont .

Opmerking: Als er meer dan één storing is, wordt deze niet ondersteund en kan er een herschikking van het systeem nodig zijn.

Back-uplijn van het ESC:

- Configuratie uitvoeren

- ConfD CDB DB

- ESC-vastlegging

- Syslog-configuratie

Stap 2. De frequentie van de ESC DB-back-up is lastig en moet zorgvuldig worden behandeld als ESC de verschillende staatsmachines controleert en onderhoudt voor verschillende VPN-VM's die worden ingezet. Het wordt aanbevolen deze back-ups te maken na de volgende activiteiten in een VNF/POD/Site.

Stap 3. Controleer de gezondheid van ESC goed is voor het gebruik van health.sh script.

[root@auto-test-vnfm1-esc-0 admin]# escadm status

0 ESC status=0 ESC Master Healthy

[root@auto-test-vnfm1-esc-0 admin]# health.sh

esc ui is disabled -- skipping status check

esc_monitor start/running, process 836

esc_mona is up and running ...

vimmanager start/running, process 2741

vimmanager start/running, process 2741

esc_confd is started

tomcat6 (pid 2907) is running...                           [  OK  ]

postgresql-9.4 (pid  2660) is running...

ESC service is running...

Active VIM = OPENSTACK

ESC Operation Mode=OPERATION

/opt/cisco/esc/esc_database is a mountpoint

============== ESC HA (MASTER) with DRBD =================

DRBD_ROLE_CHECK=0

MNT_ESC_DATABSE_CHECK=0

VIMMANAGER_RET=0

ESC_CHECK=0

STORAGE_CHECK=0

ESC_SERVICE_RET=0

MONA_RET=0

ESC_MONITOR_RET=0

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

ESC HEALTH PASSED

Stap 4. Neem een back-up van de configuratie en breng het bestand over naar de reserveserver.

[root@auto-test-vnfm1-esc-0 admin]# /opt/cisco/esc/confd/bin/confd_cli -u admin -C

admin connected from 127.0.0.1 using console on auto-test-vnfm1-esc-0.novalocal

auto-test-vnfm1-esc-0# show running-config | save /tmp/running-esc-12202017.cfg

auto-test-vnfm1-esc-0#exit

[root@auto-test-vnfm1-esc-0 admin]# ll /tmp/running-esc-12202017.cfg

-rw-------. 1 tomcat tomcat 25569 Dec 20 21:37 /tmp/running-esc-12202017.cfg

Reserve ESC-database

Stap 1. Meld u aan bij ESC VM en voer deze opdracht uit voordat u de back-up neemt.

[admin@esc ~]# sudo bash

[root@esc ~]# cp /opt/cisco/esc/esc-scripts/esc_dbtool.py /opt/cisco/esc/esc-scripts/esc_dbtool.py.bkup

[root@esc esc-scripts]# sudo sed -i "s,'pg_dump,'/usr/pgsql-9.4/bin/pg_dump," /opt/cisco/esc/esc-scripts/esc_dbtool.py

#Set ESC to mainenance mode

[root@esc esc-scripts]# escadm op_mode set --mode=maintenance

Stap 2. Controleer de ESC-modus en controleer of deze in de onderhoudsmodus staat.

[root@esc esc-scripts]# escadm op_mode show

Stap 3. Back-updatabase met back-up van gegevensbestanden die beschikbaar is in ESC.

[root@esc scripts]# sudo /opt/cisco/esc/esc-scripts/esc_dbtool.py backup --file  scp://

:

@

:

Stap 4. Stel ESC Terug naar de Bewerkingsmodus in en bevestig de modus.

[root@esc scripts]# escadm op_mode set --mode=operation

[root@esc scripts]# escadm op_mode show

Stap 5. Navigeer naar de map scripts en verzamel de logboeken.

[root@esc scripts]# /opt/cisco/esc/esc-scripts

sudo ./collect_esc_log.sh

Stap 6. Een momentopname van het ESC creëren door het ESC eerst af te sluiten.

shutdown -r now

Stap 7. Maak vanaf het ruimtesysteem een foto-snapshot.

- nova image-create --poll esc1 esc_snapshot_27aug2018

Stap 8. Controleer dat de momentopname is gemaakt

openstack image list | grep esc_snapshot_27aug2018

Stap 9. Start het ESC vanaf het OSPD-overleg

nova start esc1

Stap 10. Herhaal dezelfde procedure op de stand-by ESC VM en breng de logbestanden naar de reserveserver over.

Stap 1. Verzamel back-up van de configuratie van het systeem op zowel het ESC VMS als breng deze over naar de reserveserver.

[admin@auto-test-vnfm2-esc-1 ~]$ cd /etc/rsyslog.d

[admin@auto-test-vnfm2-esc-1 rsyslog.d]$ls /etc/rsyslog.d/00-escmanager.conf

00-escmanager.conf

[admin@auto-test-vnfm2-esc-1 rsyslog.d]$ls /etc/rsyslog.d/01-messages.conf

01-messages.conf

[admin@auto-test-vnfm2-esc-1 rsyslog.d]$ls /etc/rsyslog.d/02-mona.conf

02-mona.conf

[admin@auto-test-vnfm2-esc-1 rsyslog.d]$ls /etc/rsyslog.conf

rsyslog.conf

Moederbord vervangen

Stap 1. De stappen ter vervanging van het moederbord op een UCS C240 M4-server kunnen worden doorverwezen van:

Cisco UCS C240 M4-serverinstallatie en -servicegids

Stap 2. Meld u aan bij de server met gebruik van de CIMC IP.

Stap 3. Start een upgrade van het besturingssysteem uit als de firmware niet voldoet aan de aanbevolen versie die eerder is gebruikt. Hier worden stappen voor een upgrade gegeven:

Cisco UCS C-Series upgrade-handleiding voor rackservers

De VM's herstellen

Compact knooppunt voor hosts CPS, ESC

Herstel van ESC-VM

Stap 1. ESC VM kan worden hersteld indien de VM in een fout of in een stilstand verkeert, een harde herstart doet om de geïmpliceerde VM op te halen. Start deze stappen om ESC te herstellen.

Stap 2. Identificeer de VM die zich in de staat FOUT of shutdown bevindt, zodra de ESC VM herstart. In dit voorbeeld, herstart auto-test-vnfm1-ESC-0.

[root@tb1-baremetal scripts]# nova list | grep auto-test-vnfm1-ESC-

| f03e3cac-a78a-439f-952b-045aea5b0d2c | auto-test-vnfm1-ESC-0                                       | ACTIVE | -          | running     | auto-testautovnf1-uas-orchestration=172.57.12.11; auto-testautovnf1-uas-management=172.57.11.3                                                                                      |

| 79498e0d-0569-4854-a902-012276740bce | auto-test-vnfm1-ESC-1                                       | ACTIVE | -          | running     | auto-testautovnf1-uas-orchestration=172.57.12.15; auto-testautovnf1-uas-management=172.57.11.5                                                                                      |

[root@tb1-baremetal scripts]# [root@tb1-baremetal scripts]# nova reboot --hard f03e3cac-a78a-439f-952b-045aea5b0d2c\

Request to reboot server <Server: auto-test-vnfm1-ESC-0> has been accepted.

[root@tb1-baremetal scripts]#

Stap 3. Indien ESC VM wordt verwijderd en opnieuw moet worden opgevoed.

[stack@pod1-ospd scripts]$ nova list |grep ESC-1

| c566efbf-1274-4588-a2d8-0682e17b0d41 | vnf1-ESC-ESC-1                                                 | ACTIVE | -          | running     | vnf1-UAS-uas-orchestration=172.168.11.14; vnf1-UAS-uas-management=172.168.10.4                                                                                                 |

[stack@pod1-ospd scripts]$ nova delete vnf1-ESC-ESC-1

Request to delete server vnf1-ESC-ESC-1 has been accepted.

Stap 4. Controleer vanaf OSPF of nieuwe ESC-VM actief/actief is:

[stack@pod1-ospd ~]$ nova list|grep -i esc

| 934519a4-d634-40c0-a51e-fc8d55ec7144 | vnf1-ESC-ESC-0                                                 | ACTIVE | -          | running     | vnf1-UAS-uas-orchestration=172.168.11.13; vnf1-UAS-uas-management=172.168.10.3                                                                                                 |

| 2601b8ec-8ff8-4285-810a-e859f6642ab6 | vnf1-ESC-ESC-1                                                 | ACTIVE | -          | running     | vnf1-UAS-uas-orchestration=172.168.11.14; vnf1-UAS-uas-management=172.168.10.6                                                                                                 |

#Log in to new ESC and verify Backup state.  You may execute health.sh on ESC Master too.

…

####################################################################

#   ESC on vnf1-esc-esc-1.novalocal is in BACKUP state.

####################################################################

[admin@esc-1 ~]$ escadm status

0 ESC status=0 ESC Backup Healthy

[admin@esc-1 ~]$ health.sh

============== ESC HA (BACKUP) =================

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

ESC HEALTH PASSED

[admin@esc-1 ~]$ cat /proc/drbd

version: 8.4.7-1 (api:1/proto:86-101)

GIT-hash: 3a6a769340ef93b1ba2792c6461250790795db49 build by mockbuild@Build64R6, 2016-01-12 13:27:11

1: cs:Connected ro:Secondary/Primary ds:UpToDate/UpToDate C r-----

ns:0 nr:504720 dw:3650316 dr:0 al:8 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0

Stap 5. Als ESC VM niet kan worden hersteld en de database moet worden hersteld, moet u de database van de eerder opgenomen back-up herstellen.

Stap 6. Voor het herstellen van de ESC-databank moeten we ervoor zorgen dat de ESC-dienst wordt gestopt voordat de databank wordt hersteld; Voor ESC HA, eerst uitvoeren in secundaire VM en daarna de primaire VM.

# service keepalived stop

Stap 7. Controleer ESC-servicestatus en zorg ervoor dat alles wordt gestopt in zowel primaire als secundaire VM's voor HA's

# escadm status

Stap 8. Voer het script uit om de database te herstellen. Als onderdeel van het herstel van de DB naar de nieuwe ESC-instantie, zal het gereedschap ook een van de gevallen promoten die een primaire ESC zijn, de DB-map op het drbd-apparaat zetten en de PostgreSQL-database starten.

# /opt/cisco/esc/esc-scripts/esc_dbtool.py restore --file scp://

:

@

:

Stap 9. Start ESC-service opnieuw om de database te herstellen.

Voor HA-uitvoering in beide VM's moet de onderhoudsservice opnieuw worden gestart

# service keepalived start

Stap 10. Zodra de VM met succes is hersteld en actief is; ervoor zorgen dat alle syslogspecifieke configuratie wordt hersteld van de vorige succesvolle bekende back-up. Zorg ervoor dat deze in alle ESC-VM's wordt hersteld

[admin@auto-test-vnfm2-esc-1 ~]$

[admin@auto-test-vnfm2-esc-1 ~]$ cd /etc/rsyslog.d

[admin@auto-test-vnfm2-esc-1 rsyslog.d]$ls /etc/rsyslog.d/00-escmanager.conf

00-escmanager.conf

[admin@auto-test-vnfm2-esc-1 rsyslog.d]$ls /etc/rsyslog.d/01-messages.conf

01-messages.conf

[admin@auto-test-vnfm2-esc-1 rsyslog.d]$ls /etc/rsyslog.d/02-mona.conf

02-mona.conf

[admin@auto-test-vnfm2-esc-1 rsyslog.d]$ls /etc/rsyslog.conf

rsyslog.conf

Stap 11. Als het ESC moet worden herbouwd van een Ospd-snapshot, gebruik dan onder commando een momentopname die tijdens de back-up is genomen.

nova rebuild --poll --name esc_snapshot_27aug2018 esc1

Stap 12. Controleer de status van het ESC nadat de heropbouw is voltooid.

nova list --fileds name,host,status,networks | grep esc

Stap 13. Controleer ESC-status met onderstaande opdracht.

health.sh

Copy Datamodel to a backup file

/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli get esc_datamodel/opdata > /tmp/esc_opdata_`date +%Y%m%d%H%M%S`.txt

De CPS VM’s herstellen

De CPS VM zou in de nova-lijst een foutstatus hebben:

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

De CPS VM herstellen van het 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

<?xml version="1.0" encoding="UTF-8"?>

<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1">

<ok/>

</rpc-reply>

Monitor het 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].

Als ESC er niet in slaagt om VM te starten

Stap 1. In sommige gevallen zal ESC de VM niet starten vanwege een onverwachte toestand. Een omschakelingsmechanisme is het uitvoeren van een ESC - omschakeling door herstart van het ESC. De ESC-omschakeling zal ongeveer een minuut duren.  Execute health.sh op de nieuwe Master ESC om te controleren of het in orde is. Wanneer het ESC Meester wordt, kan ESC de VM-status vastleggen en de VM starten. Aangezien deze bewerking is gepland, moet u 5-7 minuten wachten voordat deze is voltooid.

Stap 2. U kunt /var/log/esc/yangesc.log en /var/log/esc/escmanager.log controleren. Indien VM na 5-7 minuten niet wordt hersteld, moet de gebruiker de geïmpacte VM(s) handmatig gaan herstellen.

Stap 3. Zodra de VM met succes is hersteld en operationeel is; ervoor zorgen dat alle syslogspecifieke configuratie wordt hersteld van de vorige succesvolle bekende back-up. Zorg ervoor dat deze in alle ESC-VM's wordt hersteld.

root@autotestvnfm1esc2:/etc/rsyslog.d# pwd

/etc/rsyslog.d

root@autotestvnfm1esc2:/etc/rsyslog.d# ll

total 28

drwxr-xr-x  2 root root 4096 Jun  7 18:38 ./

drwxr-xr-x 86 root root 4096 Jun  6 20:33 ../]

-rw-r--r--  1 root root  319 Jun  7 18:36 00-vnmf-proxy.conf

-rw-r--r--  1 root root  317 Jun  7 18:38 01-ncs-java.conf

-rw-r--r--  1 root root  311 Mar 17  2012 20-ufw.conf

-rw-r--r--  1 root root  252 Nov 23  2015 21-cloudinit.conf

-rw-r--r--  1 root root 1655 Apr 18  2013 50-default.conf

root@abautotestvnfm1em-0:/etc/rsyslog.d# ls /etc/rsyslog.conf

rsyslog.conf

Moederbordvervanging in OSD computing-knooppunt

Voor de activiteit worden de VM's die in de Computeknoop worden geserveerd, op een slinkse manier afgekoppeld en wordt de CEPH in de onderhoudsmodus geplaatst. Zodra het moederbord is vervangen, worden de VM's weer teruggezet en wordt de CEPH uit de onderhoudsmodus verwijderd.

CEPH in onderhoudsmodus plaatsen

Stap 1. Controleer of de status van de ceptboom in de server aanwezig is

[heat-admin@pod1-osd-compute-1 ~]$ sudo ceph osd tree

ID WEIGHT   TYPE NAME                         UP/DOWN REWEIGHT PRIMARY-AFFINITY

-1 13.07996 root default

-2  4.35999     host pod1-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 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

Stap 2. Meld u aan bij het OSD computing-knooppunt en zet de CEPH in de onderhoudsmodus.

[root@pod1-osd-compute-1 ~]# sudo ceph osd set norebalance

[root@pod1-osd-compute-1 ~]# sudo ceph osd set noout

[root@pod1-osd-compute-1 ~]# 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 {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 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

Opmerking: Wanneer de CEPH wordt verwijderd, komt de VNF-HD-VAL in de gedegradeerde staat terecht, maar de hd-schijf moet nog toegankelijk zijn

Identificeer de VM's die worden Hosted in het OSD-computing knooppunt

Identificeer de VM's die op de OSD-computerserver worden gehost.

De computerserver bevat Elastic Services Controller (ESC) of CPS VM’s

[stack@director ~]$ nova list --field name,host | grep osd-compute-1

| 507d67c2-1d00-4321-b9d1-da879af524f8 | VNF2-DEPLOYM_XXXX_0_c8d98f0f-d874-45d0-af75-88a2d6fa82ea   | pod1-compute-8.localdomain     |

| f9c0763a-4a4f-4bbd-af51-bc7545774be2 | VNF2-DEPLOYM_c1_0_df4be88d-b4bf-4456-945a-3812653ee229     | pod1-compute-8.localdomain     |

| 75528898-ef4b-4d68-b05d-882014708694 | VNF2-ESC-ESC-0                                             | pod1-compute-8.localdomain     |

| f5bd7b9c-476a-4679-83e5-303f0aae9309 | VNF2-UAS-uas-0                                             | pod1-compute-8.localdomain     |

Opmerking: In de hier weergegeven output komt de eerste kolom overeen met de universeel-unieke IDentifier (UUID), de tweede kolom is de VM naam en de derde kolom is de hostname waar de VM aanwezig is. De parameters uit deze uitvoer worden in de volgende secties gebruikt.

GainMaker-voeding

Case 1. OSD-computing knooppunten ESC

De procedure voor de energiekracht van ESC- of CPS-VM's is gelijk, ongeacht of de VM's worden gehost in computingsknooppunt of OSD-Computeknooppunt.

Volg stappen van "Motherboard Rereplacement in Compute Node" om de VMs energiek uit te schakelen.

Moederbord vervangen

Stap 1. De stappen ter vervanging van het moederbord in een UCS C240 M4-server kunnen worden verwezen van:

Cisco UCS C240 M4-serverinstallatie en -servicegids

Stap 2. Meld u aan bij de server met het gebruik van de CIMC IP

3. Start een upgrade op als de firmware niet volgens de aanbevolen versie is. Hier worden stappen voor een upgrade gegeven:

Cisco UCS C-Series upgrade-handleiding voor rackservers

Verplaats CEPH uit de onderhoudsmodus

Log in op het OSD computing knooppunt en verplaats CEPH uit de onderhoudsmodus.

[root@pod1-osd-compute-1 ~]# sudo ceph osd unset norebalance

[root@pod1-osd-compute-1 ~]# sudo ceph osd unset noout

[root@pod1-osd-compute-1 ~]# sudo ceph status

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 e196: 12 osds: 12 up, 12 in

flags sortbitwise,require_jewel_osds

pgmap v584954: 704 pgs, 6 pools, 531 GB data, 344 kobjects

1585 GB used, 11808 GB / 13393 GB avail

704 active+clean

client io 12888 kB/s wr, 0 op/s rd, 81 op/s wr

De VM's herstellen

Case 1. OSD-computing knooppunten die ESC of CPS ontvangen

De procedure voor het herstellen van CF/ESC/EM/UAS VM's is gelijk, ongeacht of de VM's worden gehost in computingsknooppunt of OSD-Computeknooppunt.

Volg stappen van "Case 2. Compute Node Hosts CF/ESC/EM/UAS" om de VM’s te herstellen.

Moederboard vervanging in controllerknooppunt

Controleer de controllerstatus en plaats de cluster in de onderhoudsmodus

Vanaf OSPF is de inlognaam naar controller en verify-pc's in goede staat - alle drie controllers online en galera met alle drie controllers als Master.

[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-controller-0 (stonith:fence_ipmilan): Started pod1-controller-0

my-ipmilan-for-controller-1 (stonith:fence_ipmilan): Started pod1-controller-0

my-ipmilan-for-controller-2 (stonith:fence_ipmilan): Started pod1-controller-0

Daemon Status:

corosync: active/enabled

pacemaker: active/enabled

pcsd: active/enabled

Zet de cluster in onderhoudsmodus.

[heat-admin@pod1-controller-0 ~]$ sudo pcs cluster standby

[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-controller-0 (stonith:fence_ipmilan): Started pod1-controller-1

my-ipmilan-for-controller-1 (stonith:fence_ipmilan): Started pod1-controller-1

my-ipmilan-for-controller-2 (stonith:fence_ipmilan): Started pod1-controller-2

Moederbord vervangen

Stap 1. De stappen ter vervanging van het moederbord op een UCS C240 M4-server kunnen worden doorverwezen van:

Cisco UCS C240 M4-serverinstallatie en -servicegids

Stap 2. Meld u aan bij de server met gebruik van de CIMC IP.

Stap 3. Start een upgrade van het besturingssysteem uit als de firmware niet voldoet aan de aanbevolen versie die eerder is gebruikt. Hier worden stappen voor een upgrade gegeven:

Cisco UCS C-Series upgrade-handleiding voor rackservers

Cluster status terugzetten

Meld u aan bij de getroffen controller en verwijder de stand-by modus door stand-by in te stellen. Controleer dat controller online komt met cluster en galera alle drie controllers als Master. Dit kan een paar minuten duren.

[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-controller-0 (stonith:fence_ipmilan): Started pod1-controller-1

my-ipmilan-for-controller-1 (stonith:fence_ipmilan): Started pod1-controller-1

my-ipmilan-for-controller-2 (stonith:fence_ipmilan): Started pod1-controller-2

Daemon Status:

corosync: active/enabled

pacemaker: active/enabled

pcsd: active/enable