Vervanging van defecte componenten op server UCS C240 M4 - vEPC

Downloadopties

  • PDF     (446.8 KB)
    Met Adobe Reader op diverse apparaten bekijken
  • ePub     (224.9 KB)
    Bekijken in diverse apps op iPhone, iPad, Android, Sony Reader of Windows Phone
  • Mobi (Kindle)     (182.9 KB)
    Op Kindle-apparaat of via Kindle-app op meerdere apparaten bekijken
Bijgewerkt:2 juli 2018
Document-id:213464

Inclusief taalgebruik

De documentatie van dit product is waar mogelijk geschreven met inclusief taalgebruik. Inclusief taalgebruik wordt in deze documentatie gedefinieerd als taal die geen discriminatie op basis van leeftijd, handicap, gender, etniciteit, seksuele oriëntatie, sociaaleconomische status of combinaties hiervan weerspiegelt. In deze documentatie kunnen uitzonderingen voorkomen vanwege bewoordingen die in de gebruikersinterfaces van de productsoftware zijn gecodeerd, die op het taalgebruik in de RFP-documentatie zijn gebaseerd of die worden gebruikt in een product van een externe partij waarnaar wordt verwezen. Lees meer over hoe Cisco gebruikmaakt van inclusief taalgebruik.

Over deze vertaling

Cisco heeft dit document vertaald via een combinatie van machine- en menselijke technologie om onze gebruikers wereldwijd ondersteuningscontent te bieden in hun eigen taal. Houd er rekening mee dat zelfs de beste machinevertaling niet net zo nauwkeurig is als die van een professionele vertaler. Cisco Systems, Inc. is niet aansprakelijk voor de nauwkeurigheid van deze vertalingen en raadt aan altijd het oorspronkelijke Engelstalige document (link) te raadplegen.

    Inleiding

    In dit document worden de stappen beschreven die moeten worden uitgevoerd om defecte componenten die hier worden vermeld in een UCS-server (Unified Computing System) te vervangen in een Ultra-M setup waarin StarOS Virtual Network Functions (VNFs) wordt gehost. 

    • Vervangingsmodule met dubbel inline geheugen (DIMM)
    • Foute FlexFlash-controller
    • Falen van Solid State Drive (SSD) 
    • Trusted Platform Module-fout (TPM)
    • Snelle cachefout
    • Fout in Raid Controller/Hot Bus Adapter (HBA)
    • PCI-uitbreidingsfout
    • PCIe-adapter Intel X520 10G-fout
    • Modulaire LAN-on Motherboard (MLOM)-fout
    • Ventilatoreenheid RMA
    • CPU-fout

    Achtergrondinformatie

    Ultra-M is een voorverpakte en gevalideerde gevirtualiseerde mobiele packet-core-oplossing die ontworpen is om de implementatie van VNF's te vereenvoudigen. OpenStack is de gevirtualiseerde Infrastructuurbeheerder (VIM) voor Ultra-M en bestaat uit de volgende knooppunten:

    • Computeren
    • Object Storage Disk - computing (OSD - computing)
    • Controller
    • OpenStack-platform - Director (OSPD)

    De hoogwaardige architectuur van Ultra-M en de betrokken componenten worden in dit beeld weergegeven:

    Dit document is bedoeld voor Cisco-personeel dat bekend is met Cisco Ultra-M platform en geeft de stappen aan die moeten worden uitgevoerd op OpenStack- en StarOS VNF-niveau op het moment van vervanging van de component in de server. 

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

    Afkortingen

    VNF   Virtuele netwerkfunctie
    CF    Bedieningsfunctie
    SF    Servicefunctie
    ESC   Elastic-servicecontroller
    MOP   Werkwijze
    OSD   Schijven voor objectopslag
    HDD   Harde schijf
    SSD   Solid state drive
    VIM   Virtual Infrastructure Manager
    VM    Virtuele machine
    EM    Element Manager
    UAS   Ultra-automatiseringsservices
    UUID   Universele unieke IDentifier

    Werkstroom van de MoP 

    213464-replacement-of-faulty-components-on-serv-00.png

    Voorwaarden

    Back-up

    Voordat u een defecte component vervangt, is het belangrijk om de huidige status van uw Red Hat OpenStack Platform omgeving te controleren. Aanbevolen wordt om de huidige status te controleren om complicaties te voorkomen wanneer het vervangingsproces is ingeschakeld. Het kan worden bereikt door deze stroom van vervanging.

    In het geval van herstel raadt Cisco aan een back-up van de OSPD-database te maken met behulp van deze stappen:

    [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


    Dit proces zorgt ervoor dat een knooppunt kan worden vervangen zonder dat dit de beschikbaarheid van enige instanties beïnvloedt. Ook wordt aanbevolen om een back-up te maken van de StarOS-configuratie, met name als de te vervangen compute/OSD-compute knooppunt de Control Functie (CF) Virtual Machine (VM) host.

    Opmerking: Als de Server de Controller-knooppunt is, gaat u verder naar de sectie "", anders gaat u verder met de volgende sectie.


    Component RMA - computing/OSD-computing knooppunt 

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

    Identificeer de VM's die op de server worden gehost. Er zijn twee mogelijkheden:

    • De server bevat alleen servicefunctie (SF) VM:
    [stack@director ~]$ nova list --field name,host | grep compute-10
    | 49ac5f22-469e-4b84-badc-031083db0533 |  VNF2-DEPLOYM_s9_0_8bc6cc60-15d6-4ead-8b6a-10e75d0e134d     |  
    pod1-compute-10.localdomain    |

      

    • De server bevat de combinatie van de controlefunctie (CF)/Elastic Services Controller (ESC)/ Element Manager (EM)/ Ultra Automation Services (UAS) van 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     |
    | f5bd7b9c-476a-4679-83e5-303f0aae9309 | VNF2-UAS-uas-0                                             | pod1-compute-8.localdomain     |

    Opmerking: in de hier getoonde uitvoer komt de eerste kolom overeen met de Universally Unique IDentifier (UUID), de tweede kolom is de naam van de VM en de derde kolom is de hostnaam waar de VM aanwezig is. De parameters van deze uitvoer worden in volgende secties gebruikt.

    Scherpelijk uitschakelen

    Case 1. Compute Node Hosts - alleen SF VM

    SF-kaart naar stand-by status migreren

    • Log in op de StarOS VNF en identificeer de kaart die overeenkomt met de SF VM. Gebruik de UUID van de SF-VM die wordt geïdentificeerd uit de sectie "Identificeer de VM's die worden gehost in het computing/OSD-computing knooppunt" en identificeer de kaart die overeenkomt met de UUID:
    [local]VNF2# show card hardware
    Tuesday might 08 16:49:42 UTC 2018
    <snip>
    Card 8:
      Card Type               : 4-Port Service Function Virtual Card
      CPU Packages            : 26 [#0, #1, #2, #3, #4, #5, #6, #7, #8, #9, #10, #11, #12, #13, #14, #15, #16, #17, #18, #19, #20, #21, #22, #23, #24, #25]
      CPU Nodes               : 2
      CPU Cores/Threads       : 26
      Memory                  : 98304M (qvpc-di-large)
      UUID/Serial Number      :  49AC5F22-469E-4B84-BADC-031083DB0533
    • Controleer de status van de kaart:
    [local]VNF2# show card table
    Tuesday might 08 16:52:53 UTC 2018
    Slot         Card Type                               Oper State     SPOF  Attach
    -----------  --------------------------------------  -------------  ----  ------
     1: CFC      Control Function Virtual Card           Active         No         
     2: CFC      Control Function Virtual Card           Standby        -          
     3: FC       4-Port Service Function Virtual Card    Active         No         
     4: FC       4-Port Service Function Virtual Card    Active         No         
     5: FC       4-Port Service Function Virtual Card    Active         No         
     6: FC       4-Port Service Function Virtual Card    Active         No         
     7: FC       4-Port Service Function Virtual Card    Active         No         
    8: FC       4-Port Service Function Virtual Card    Active         No         
     9: FC       4-Port Service Function Virtual Card    Active         No         
    10: FC       4-Port Service Function Virtual Card    Standby        -  
    • Als de kaart zich in de actieve status bevindt, verplaatst u de kaart naar de stand-by status:
      [local]VNF2# card migrate from 8 to 10

    Uitschakelen SF VM van ESC

    • Log in op de ESC-knooppunt die overeenkomt met de VNF en controleer de status van de SF VM:

    [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>
                        VNF2-DEPLOYM_c1_0_df4be88d-b4bf-4456-945a-3812653ee229
                        VM_ALIVE_STATE
                         VNF2-DEPLOYM_s9_0_8bc6cc60-15d6-4ead-8b6a-10e75d0e134d
                        VM_ALIVE_STATE</state>
    <snip>
    • Stop de SF VM met het gebruik van de VM Name. (VM-naam vermeld in de sectie "De VM's identificeren die worden gehost in het computing/OSD-computing knooppunt"):

    [admin@VNF2-esc-esc-0 esc-cli]$ ./esc_nc_cli vm-action STOP VNF2-DEPLOYM_s9_0_8bc6cc60-15d6-4ead-8b6a-10e75d0e134d
    •  Zodra de VM is gestopt, moet deze 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>
                        VNF2-DEPLOYM_c1_0_df4be88d-b4bf-4456-945a-3812653ee229
                        VM_ALIVE_STATE
                        VNF2-DEPLOYM_c3_0_3e0db133-c13b-4e3d-ac14-
                        VM_ALIVE_STATE
                        VNF2-DEPLOYM_s9_0_8bc6cc60-15d6-4ead-8b6a-10e75d0e134d
                        VM_SHUTOFF_STATE</state>

    Case 2. Compute/OSD-computing knooppunt, hosts CF/ESC/EM/UAS

    CF-kaart naar stand-by status migreren

    • Log in op de StarOS VNF en identificeer de kaart die overeenkomt met de CF VM. Gebruik de UUID van de CF-VM die wordt geïdentificeerd uit de sectie "Identificeer de VM's die worden gehost in het knooppunt" en vind de kaart die overeenkomt met de UUID:

    [local]VNF2# show card hardware
    Tuesday might 08 16:49:42 UTC 2018
    <snip>
    Card 2:
      Card Type               : Control Function Virtual Card
      CPU Packages            : 8 [#0, #1, #2, #3, #4, #5, #6, #7]
      CPU Nodes               : 1
      CPU Cores/Threads       : 8
      Memory                  : 16384M (qvpc-di-large)
      UUID/Serial Number      : F9C0763A-4A4F-4BBD-AF51-BC7545774BE2
    <snip>
    • Controleer de status van de kaart:

    [local]VNF2# show card table
    Tuesday might 08 16:52:53 UTC 2018
    Slot         Card Type                               Oper State     SPOF  Attach
    -----------  --------------------------------------  -------------  ----  ------
     1: CFC      Control Function Virtual Card           Standby        -
     2: CFC      Control Function Virtual Card           Active         No          
     3: FC       4-Port Service Function Virtual Card    Active         No         
     4: FC       4-Port Service Function Virtual Card    Active         No         
     5: FC       4-Port Service Function Virtual Card    Active         No         
     6: FC       4-Port Service Function Virtual Card    Active         No         
     7: FC       4-Port Service Function Virtual Card    Active         No         
     8: FC       4-Port Service Function Virtual Card    Active         No         
     9: FC       4-Port Service Function Virtual Card    Active         No         
    10: FC       4-Port Service Function Virtual Card    Standby        -
    • Als de kaart zich in de actieve status bevindt, verplaatst u de kaart naar de stand-by status:

    [local]VNF2# card migrate from 2 to 1

    Uitschakelen van CF en EM VM van ESC

    • Log in op de ESC-knooppunt die 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>
                        VNF2-DEPLOYM_c1_0_df4be88d-b4bf-4456-945a-3812653ee229
                        VM_ALIVE_STATE</state>
                        VNF2-DEPLOYM_c3_0_3e0db133-c13b-4e3d-ac14-
                        VM_ALIVE_STATE
    <deployment_name>VNF2-DEPLOYMENT-em</deployment_name>
                      507d67c2-1d00-4321-b9d1-da879af524f8
                      dc168a6a-4aeb-4e81-abd9-91d7568b5f7c
                      9ffec58b-4b9d-4072-b944-5413bf7fcf07
                    SERVICE_ACTIVE_STATE
                        VNF2-DEPLOYM_XXXX_0_c8d98f0f-d874-45d0-af75-88a2d6fa82ea
                        VM_ALIVE_STATE</state>
    <snip>
    • Stop de CF en EM VM één-voor-één met het gebruik van de VM Name. (VM-naam vermeld in de sectie "De VM's identificeren die worden gehost in het computing/OSD-computing knooppunt"):

    [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

      

    • Nadat de VM's zijn gestopt, moeten ze 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>
                        VNF2-DEPLOYM_c1_0_df4be88d-b4bf-4456-945a-3812653ee229</vm_name>
                        VM_SHUTOFF_STATE</state>
                        VNF2-DEPLOYM_c3_0_3e0db133-c13b-4e3d-ac14-
                        VM_ALIVE_STATE
    <deployment_name>VNF2-DEPLOYMENT-em</deployment_name>
                      507d67c2-1d00-4321-b9d1-da879af524f8
                      dc168a6a-4aeb-4e81-abd9-91d7568b5f7c
                      9ffec58b-4b9d-4072-b944-5413bf7fcf07
                    SERVICE_ACTIVE_STATE
                        VNF2-DEPLOYM_XXXX_0_c8d98f0f-d874-45d0-af75-88a2d6fa82ea</vm_name>
                        
       
       
         VM_SHUTOFF_STATE 
       
    <snip>

    ESC naar standby-modus migreren

    • Log in op de ESC die in de node wordt gehost en controleer of deze zich in de masterstatus bevindt. Zo ja, switch de ESC in 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!

    Opmerking: Als de defecte component moet worden vervangen op de OSD-computing knooppunt, zet de Ceph in Onderhoud op de server voordat u doorgaat met de componentvervanging. 

    [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

    Vervang de defecte component via het computing/OSD-computing knooppunt

    Schakel de gespecificeerde server uit. De stappen voor het vervangen van een defect onderdeel op UCS C240 M4-server kunnen worden doorverwezen vanaf: 

    De servercomponenten vervangen

    De VM's herstellen

     Case 1. Compute Node Hosts - alleen SF VM

     SF VM-herstel van ESC

    • De SF VM staat in de nova-lijst ten onrechte:

    [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 SF-VM herstellen van de 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>
    • Controleer de 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].
    • Zorg ervoor dat de SF-kaart als stand-by SF verschijnt in het VNF

    Case 2. Compute/OSD-computing knooppunt, host CF, ESC, EM en UAS

      Herstel van UAS VM

    • Controleer de status van de UAS VM in de nova-lijst en verwijder deze:
    [stack@director ~]$ nova list | grep VNF2-UAS-uas-0
    | 307a704c-a17c-4cdc-8e7a-3d6e7e4332fa | VNF2-UAS-uas-0                                                 | ACTIVE | -          | Running     | VNF2-UAS-uas-orchestration=172.168.11.10; VNF2-UAS-uas-management=172.168.10.3
    [stack@tb5-ospd ~]$ nova delete VNF2-UAS-uas-0
    Request to delete server VNF2-UAS-uas-0 has been accepted.
    • Om de automatisch aangepaste VM te herstellen, voert u het uas-check script uit om de status te controleren. Zij moet een fout melden. Voer vervolgens opnieuw uit met — optie repareren om de ontbrekende UAS VM opnieuw te genereren:

    [stack@director ~]$ cd /opt/cisco/usp/uas-installer/scripts/
    [stack@director scripts]$ ./uas-check.py auto-vnf VNF2-UAS
    2017-12-08 12:38:05,446 - INFO: Check of AutoVNF cluster started
    2017-12-08 12:38:07,925 - INFO: Instance 'vnf1-UAS-uas-0' status is 'ERROR'
    2017-12-08 12:38:07,925 - INFO: Check completed, AutoVNF cluster has recoverable errors

    [stack@director scripts]$ ./uas-check.py auto-vnf VNF2-UAS --fix
    2017-11-22 14:01:07,215 - INFO: Check of AutoVNF cluster started
    2017-11-22 14:01:09,575 - INFO: Instance VNF2-UAS-uas-0' status is 'ERROR'
    2017-11-22 14:01:09,575 - INFO: Check completed, AutoVNF cluster has recoverable errors
    2017-11-22 14:01:09,778 - INFO: Removing instance VNF2-UAS-uas-0'
    2017-11-22 14:01:13,568 - INFO: Removed instance VNF2-UAS-uas-0'
    2017-11-22 14:01:13,568 - INFO: Creating instance VNF2-UAS-uas-0' and attaching volume ‘VNF2-UAS-uas-vol-0'
    2017-11-22 14:01:49,525 - INFO: Created instance ‘VNF2-UAS-uas-0'
    • Log in op autovnf-uas. Wacht een paar minuten en UAS moet terug naar de goede staat:
    VNF2-autovnf-uas-0#show uas
    uas version 1.0.1-1
    uas state ha-active
    uas ha-vip 172.17.181.101
    INSTANCE IP   STATE  ROLE
    -----------------------------------
    172.17.180.6  alive  CONFD-SLAVE
    172.17.180.7  alive  CONFD-MASTER
    172.17.180.9  alive  NA

    Opmerking: Als uas-check.py —fix mislukt, moet u mogelijk dit bestand kopiëren en opnieuw uitvoeren.

    [stack@director ~]$ mkdir –p /opt/cisco/usp/apps/auto-it/common/uas-deploy/
    [stack@director ~]$ cp /opt/cisco/usp/uas-installer/common/uas-deploy/userdata-uas.txt /opt/cisco/usp/apps/auto-it/common/uas-deploy/

      

    Herstel van ESC-VM

    • Controleer de status van de ESC-VM in de nova-lijst en verwijder deze:
    stack@director scripts]$ nova list |grep ESC-1
    | c566efbf-1274-4588-a2d8-0682e17b0d41 | VNF2-ESC-ESC-1                                                 | ACTIVE | -          | Running     | VNF2-UAS-uas-orchestration=172.168.11.14; VNF2-UAS-uas-management=172.168.10.4                                                                                                 |
    [stack@director scripts]$ nova delete VNF2-ESC-ESC-1
    Request to delete server VNF2-ESC-ESC-1 has been accepted.
    • Zoek vanuit AutoVNF-UAS de ESC-implementatietransactie en vind in het logbestand voor de transactie de opdrachtregel boot_vm.py om de ESC-instantie te maken:

    ubuntu@VNF2-uas-uas-0:~$ sudo -i
    root@VNF2-uas-uas-0:~# confd_cli -u admin -C
    Welcome to the ConfD CLI    
    admin connected from 127.0.0.1 using console on VNF2-uas-uas-0
    VNF2-uas-uas-0#show transaction
    TX ID                                 TX TYPE          DEPLOYMENT ID    TIMESTAMP                         STATUS
    -----------------------------------------------------------------------------------------------------------------------------
    35eefc4a-d4a9-11e7-bb72-fa163ef8df2b  vnf-deployment   VNF2-DEPLOYMENT  2017-11-29T02:01:27.750692-00:00  deployment-success
    73d9c540-d4a8-11e7-bb72-fa163ef8df2b  vnfm-deployment  VNF2-ESC         2017-11-29T01:56:02.133663-00:00  deployment-success


    VNF2-uas-uas-0#show logs 73d9c540-d4a8-11e7-bb72-fa163ef8df2b | display xml
    <config xmlns="http://tail-f.com/ns/config/1.0">
      <logs xmlns="http://www.cisco.com/usp/nfv/usp-autovnf-oper">
        <tx-id>73d9c540-d4a8-11e7-bb72-fa163ef8df2b</tx-id>
        <log>2017-11-29 01:56:02,142 - VNFM Deployment RPC triggered for deployment: VNF2-ESC, deactivate: 0
    2017-11-29 01:56:02,179 - Notify deployment
    ..
    2017-11-29 01:57:30,385 - Creating VNFM 'VNF2-ESC-ESC-1' with [python //opt/cisco/vnf-staging/bootvm.py VNF2-ESC-ESC-1 --flavor VNF2-ESC-ESC-flavor --image 3fe6b197-961b-4651-af22-dfd910436689 --net VNF2-UAS-uas-management --gateway_ip 172.168.10.1 --net VNF2-UAS-uas-orchestration --os_auth_url http://10.1.2.5:5000/v2.0 --os_tenant_name core --os_username ****** --os_password ****** --bs_os_auth_url http://10.1.2.5:5000/v2.0 --bs_os_tenant_name core --bs_os_username ****** --bs_os_password ****** --esc_ui_startup false --esc_params_file /tmp/esc_params.cfg --encrypt_key ****** --user_pass ****** --user_confd_pass ****** --kad_vif eth0 --kad_vip 172.168.10.7 --ipaddr 172.168.10.6 dhcp --ha_node_list 172.168.10.3 172.168.10.6 --file root:0755:/opt/cisco/esc/esc-scripts/esc_volume_em_staging.sh:/opt/cisco/usp/uas/autovnf/vnfms/esc-scripts/esc_volume_em_staging.sh --file root:0755:/opt/cisco/esc/esc-scripts/esc_vpc_chassis_id.py:/opt/cisco/usp/uas/autovnf/vnfms/esc-scripts/esc_vpc_chassis_id.py --file root:0755:/opt/cisco/esc/esc-scripts/esc-vpc-di-internal-keys.sh:/opt/cisco/usp/uas/autovnf/vnfms/esc-scripts/esc-vpc-di-internal-keys.sh

    Sla de boot_vm.py regel op in een shell script bestand (esc.sh) en update alle gebruikersnaam ***** en wachtwoord ***** regels met de juiste informatie (meestal core/<PASSWORD>). Je moet de optie -encrypt_key ook verwijderen. Voor user_pass en user_confd_pass, moet u de notatie gebruiken - gebruikersnaam: wachtwoord (voorbeeld - beheerder:<PASSWORD>).

    • Vind de URL om bootvm.py te bootvm.py van het in werking stellen-config en het bootvm.py bestand naar de auto-vnf-uas VM te verwijderen. In dit geval, 10.1.2.3 is de Auto-IT VM's IP:
    root@VNF2-uas-uas-0:~# confd_cli -u admin -C
    Welcome to the ConfD CLI
    admin connected from 127.0.0.1 using console on VNF2-uas-uas-0
    VNF2-uas-uas-0#show running-config autovnf-vnfm:vnfm
    …
    configs bootvm
      value http:// 10.1.2.3:80/bundles/5.1.7-2007/vnfm-bundle/bootvm-2_3_2_155.py
    !
    root@VNF2-uas-uas-0:~# wget http://10.1.2.3:80/bundles/5.1.7-2007/vnfm-bundle/bootvm-2_3_2_155.py
    --2017-12-01 20:25:52--  http://10.1.2.3 /bundles/5.1.7-2007/vnfm-bundle/bootvm-2_3_2_155.py
    Connecting to 10.1.2.3:80... connected.
    HTTP request sent, awaiting response... 200 OK
    Length: 127771 (125K) [text/x-python]
    Saving to: ‘bootvm-2_3_2_155.py’
    100%[=====================================================================================>] 127,771  --.-K/s   in 0.001s
    2017-12-01 20:25:52 (173 MB/s) - ‘bootvm-2_3_2_155.py’ saved [127771/127771]
    • Maak een /tmp/esc_params.cfg bestand:

    root@VNF2-uas-uas-0:~# echo "openstack.endpoint=publicURL" > /tmp/esc_params.cfg
    • Voer shell script uit om ESC te implementeren vanuit de UAS-knooppunt:

    root@VNF2-uas-uas-0:~# /bin/sh esc.sh
    + python ./bootvm.py VNF2-ESC-ESC-1 --flavor VNF2-ESC-ESC-flavor --image 3fe6b197-961b-4651-af22-dfd910436689
     --net VNF2-UAS-uas-management --gateway_ip 172.168.10.1 --net VNF2-UAS-uas-orchestration --os_auth_url 
    http://10.1.2.5:5000/v2.0 --os_tenant_name core --os_username core --os_password <PASSWORD> --bs_os_auth_url 
    http://10.1.2.5:5000/v2.0 --bs_os_tenant_name core --bs_os_username core --bs_os_password <PASSWORD> 
    --esc_ui_startup false --esc_params_file /tmp/esc_params.cfg --user_pass admin:<PASSWORD> --user_confd_pass 
    admin:<PASSWORD> --kad_vif eth0 --kad_vip 172.168.10.7 --ipaddr 172.168.10.6 dhcp --ha_node_list 172.168.10.3
    172.168.10.6 --file root:0755:/opt/cisco/esc/esc-scripts/esc_volume_em_staging.sh:/opt/cisco/usp/uas/autovnf/vnfms/esc-scripts/esc_volume_em_staging.sh 
    --file root:0755:/opt/cisco/esc/esc-scripts/esc_vpc_chassis_id.py:/opt/cisco/usp/uas/autovnf/vnfms/esc-scripts/esc_vpc_chassis_id.py 
    --file root:0755:/opt/cisco/esc/esc-scripts/esc-vpc-di-internal-keys.sh:/opt/cisco/usp/uas/autovnf/vnfms/esc-scripts/esc-vpc-di-internal-keys.sh
    • Log in op nieuwe ESC en controleer de back-upstatus:

    ubuntu@VNF2-uas-uas-0:~$ ssh admin@172.168.11.14
    …
       ####################################################################
       #   ESC on VNF2-esc-esc-1.novalocal is in BACKUP state.
       ####################################################################

    [admin@VNF2-esc-esc-1 ~]$ escadm status
    0 ESC status=0 ESC Backup Healthy

    [admin@VNF2-esc-esc-1 ~]$ health.sh
    ============== ESC HA (BACKUP) ===================================================
    ESC HEALTH PASSED

    CF- en EM-VM's herstellen van ESC

    • Controleer de status van de VM's van het CF en de EM uit de nova-lijst. Ze moeten zich in de FOUT-status bevinden:

    [stack@director ~]$ source corerc
    [stack@director ~]$ nova list --field name,host,status |grep -i err   
    | 507d67c2-1d00-4321-b9d1-da879af524f8 | VNF2-DEPLOYM_XXXX_0_c8d98f0f-d874-45d0-af75-88a2d6fa82ea | None                                 | ERROR|
    | f9c0763a-4a4f-4bbd-af51-bc7545774be2 | VNF2-DEPLOYM_c1_0_df4be88d-b4bf-4456-945a-3812653ee229     |None                                 | ERROR

         

    • Log in op ESC Master, voer herstel-vm-actie uit voor elke getroffen EM en CF VM. Wees geduldig. ESC zou de herstelactie plannen en het zou niet voor een paar minuten kunnen gebeuren. Bewaak de yangesc.log:
    sudo /opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli recovery-vm-action DO 
       
       

    [admin@VNF2-esc-esc-0 ~]$ sudo /opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli recovery-vm-action DO VNF2-DEPLOYMENT-_VNF2-D_0_a6843886-77b4-4f38-b941-74eb527113a8
    [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>

    [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-DEPLOYMENT-_VNF2-D_0_a6843886-77b4-4f38-b941-74eb527113a8]
    • Meld u aan bij de nieuwe EM en controleer of de EM-status juist is:

    ubuntu@VNF2vnfddeploymentem-1:~$ /opt/cisco/ncs/current/bin/ncs_cli -u admin -C
    admin connected from 172.17.180.6 using ssh on VNF2vnfddeploymentem-1
    admin@scm# show ems
    EM            VNFM
    ID  SLA  SCM  PROXY
    ---------------------
    2   up   up   up
    3   up   up   up
    • Log in op de StarOS VNF en controleer of de CF-kaart in de stand-by modus staat

       

    ESC-herstelfout behandelen

    In gevallen waarin ESC de VM niet kan starten vanwege een onverwachte status, raadt Cisco aan hoe u een ESC-switching uitvoert door de master-ESC te herstarten. De overschakeling naar het ESC zou ongeveer een minuut duren. Draai het script "health.sh" op de nieuwe Master ESC om te controleren of de status omhoog is. ESC sturen om de VM te starten en de VM-status te repareren. Deze hersteltaak zou tot 5 minuten duren om te voltooien.

    U kunt /var/log/esc/yangesc.log en /var/log/esc/escmanager.log controleren. Als u niet ziet dat VM na 5-7 minuten wordt hersteld, moet de gebruiker handmatig de getroffen VM(s) herstellen.

    Configuratie-update automatisch implementeren

    • Bewerk de automatische implementatie.cfg van AutoImplementation VM en vervang de oude computerserver door de nieuwe. Vervang de lading vervolgens in confd_cli. Deze stap is vereist voor succesvolle deactivering later:
    root@auto-deploy-iso-2007-uas-0:/home/ubuntu# confd_cli -u admin -C
    Welcome to the ConfD CLI
    admin connected from 127.0.0.1 using console on auto-deploy-iso-2007-uas-0
    auto-deploy-iso-2007-uas-0#config
    Entering configuration mode terminal
    auto-deploy-iso-2007-uas-0(config)#load replace autodeploy.cfg
    Loading.     14.63 KiB parsed in 0.42 sec (34.16 KiB/sec)

    auto-deploy-iso-2007-uas-0(config)#commit
    Commit complete.
    auto-deploy-iso-2007-uas-0(config)#end
    • Start de services uas-confd en automatisch implementeren na de wijziging in de configuratie:
    root@auto-deploy-iso-2007-uas-0:~# service uas-confd restart
    uas-confd stop/waiting
    uas-confd start/running, process 14078

    root@auto-deploy-iso-2007-uas-0:~# service uas-confd status
    uas-confd start/running, process 14078

    root@auto-deploy-iso-2007-uas-0:~# service autodeploy restart
    autodeploy stop/waiting
    autodeploy start/running, process 14017
    root@auto-deploy-iso-2007-uas-0:~# service autodeploy status
    autodeploy start/running, process 14017

    Component RMA - controllerknooppunt

    Voorcontrole

                                                       

    • Van OSPD, login aan de controller en controleer pc's is in een goede staat - alle drie controllers Online en Galera tonen alle drie controllers als Master. 

    Opmerking: Een gezond cluster vereist 2 actieve controllers, dus controleer of de twee controllers die overblijven Online en actief zijn.

    [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

    Verplaats controllercluster naar onderhoudsmodus

    • Gebruik het pc-cluster op de controller die in de stand-by modus wordt bijgewerkt:
    [heat-admin@pod1-controller-0 ~]$ sudo pcs cluster standby
    • Controleer de pc-status opnieuw en zorg ervoor dat het pc-cluster op dit knooppunt is gestopt:
    [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               

    Ook de status van de PC's op de andere 2 controllers moet de node als standby tonen.

    Vervang de defecte component via het controllerknooppunt

    Schakel de gespecificeerde server uit. De stappen voor het vervangen van een defect onderdeel op UCS C240 M4-server kunnen worden doorverwezen vanaf: 

    De servercomponenten vervangen

    De server inschakelen

    • Schakel de server in en controleer of de server verschijnt:
    [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 |
    • Login aan de beïnvloede controlemechanisme, verwijder standby wijze met het gebruik van standby. Controleer dat de controller online komt met cluster en Galera toont 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-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

    • U kunt een aantal monitordiensten, zoals ceph, controleren dat ze in een gezonde staat zijn:
    [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

    Revisiegeschiedenis

    Revisie Publicatiedatum Opmerkingen
    1.0
    02-Jul-2018
    Eerste vrijgave
    TAC Authored

    Bijgedragen door Cisco-engineers

    • Prashanth Shetty
      Cisco geavanceerde services
    • Padmaraj Ramanoudjam
      Cisco geavanceerde services

    Was dit document nuttig?

    FeedbackFeedback

    Contact Cisco

    Dit document is van toepassing op deze producten