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.
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.
Dit document beschrijft de stappen die vereist zijn om een defecte computerserver in een Ultra-M instelling te vervangen die Cisco Policy Suite (CPS) Virtual Network Functions (VPN’s) hosts.
Dit document is bedoeld voor de Cisco-medewerkers die bekend zijn met het Cisco Ultra-M-platform en bevat informatie over de stappen die moeten worden uitgevoerd op niveau van OpenStack en CPS VPN op het moment dat de Computeserververvanging wordt uitgevoerd.
Opmerking: De Ultra M 5.1.x release wordt overwogen om de procedures in dit document te definiëren.
Voordat u een computing-knooppunt vervangt, is het belangrijk om de huidige status van het Rode Hat OpenStack platform te controleren. Aanbevolen wordt om de huidige status te controleren om complicaties te voorkomen wanneer het computing-vervangingsproces is ingeschakeld.
Stap 1. Van OpenStack Deployment (OSPF).
[root@director ~]$ su - stack
[stack@director ~]$ cd ansible
[stack@director ansible]$ ansible-playbook -i inventory-new openstack_verify.yml -e platform=pcrf
Stap 2. Controleer de gezondheid van het systeem op basis van een ultragezondheidsrapport dat elke vijftien minuten wordt gegenereerd.
[stack@director ~]# cd /var/log/cisco/ultram-health
Stap 3. Controleer bestand ultram_health_os.report.De enige services dienen te tonen aangezien XXX status neutron-sriov-nic-agent.service is.
Stap 4. Om te controleren of rabbitmq voor alle controllers werkt vanaf het ruimtesysteem.
[stack@director ~]# for i in $(nova list| grep controller | awk '{print $12}'| sed 's/ctlplane=//g') ; do (ssh -o StrictHostKeyChecking=no heat-admin@$i "hostname;sudo rabbitmqctl eval 'rabbit_diagnostics:maybe_stuck().'" ) & done
Stap 5. Controleer dat STOND is ingeschakeld
[stack@director ~]# sudo pcs property show stonith-enabled
Stap 6. Controleer de PCS-status voor alle controllers.
Stap 7. Van OSPF.
[stack@director ~]$ for i in $(nova list| grep controller | awk '{print $12}'| sed 's/ctlplane=//g') ; do (ssh -o StrictHostKeyChecking=no heat-admin@$i "hostname;sudo pcs status" ) ;done
Stap 8. Controleer dat alle open stapel services actief zijn, vanuit OSPF-beheer deze opdracht uitvoeren.
[stack@director ~]# sudo systemctl list-units "openstack*" "neutron*" "openvswitch*"
Stap 9. Controleer de CEPH-status is HEALTH_OK voor controllers.
[stack@director ~]# for i in $(nova list| grep controller | awk '{print $12}'| sed 's/ctlplane=//g') ; do (ssh -o StrictHostKeyChecking=no heat-admin@$i "hostname;sudo ceph -s" ) ;done
Stap 10. Controleer de loggen van de component OpenStack. Zoek naar elke fout:
Neutron:
[stack@director ~]# sudo tail -n 20 /var/log/neutron/{dhcp-agent,l3-agent,metadata-agent,openvswitch-agent,server}.log
Cinder:
[stack@director ~]# sudo tail -n 20 /var/log/cinder/{api,scheduler,volume}.log
Glance:
[stack@director ~]# sudo tail -n 20 /var/log/glance/{api,registry}.log
Stap 11. Van het OSPF-netwerk voert u deze verificaties voor API uit.
[stack@director ~]$ source
[stack@director ~]$ nova list
[stack@director ~]$ glance image-list
[stack@director ~]$ cinder list
[stack@director ~]$ neutron net-list
Stap 12. Controleer de gezondheid van de diensten.
Every service status should be “up”:
[stack@director ~]$ nova service-list
Every service status should be “ :-)”:
[stack@director ~]$ neutron agent-list
Every service status should be “up”:
[stack@director ~]$ cinder service-list
In geval van herstel, adviseert Cisco om een steun van de spatie- gegevensbank te nemen met het gebruik 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 de beschikbaarheid van de bronnen wordt beïnvloed. Bovendien wordt aanbevolen een back-up te maken van de CPS-configuratie.
Om een back-up te maken van CPS VM's, van Cluster Manager VM:
[root@CM ~]# config_br.py -a export --all /mnt/backup/CPS_backup_$(date +\%Y-\%m-\%d).tar.gz
or
[root@CM ~]# config_br.py -a export --mongo-all --svn --etc --grafanadb --auth-htpasswd --haproxy /mnt/backup/$(hostname)_backup_all_$(date +\%Y-\%m-\%d).tar.gz
Identificeer de VM's die op de computerserver worden gehost:
[stack@director ~]$ nova list --field name,host,networks | grep compute-10
| 49ac5f22-469e-4b84-badc-031083db0533 | VNF2-DEPLOYM_s9_0_8bc6cc60-15d6-4ead-8b6a-10e75d0e134d | pod1-compute-10.localdomain | Replication=10.160.137.161; Internal=192.168.1.131; Management=10.225.247.229; tb1-orch=172.16.180.129
Opmerking: In de hier weergegeven output komt de eerste kolom overeen met de universeel unieke identificator (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.
Stap 1. Meld u aan bij het beheer van IP van de VM:
[stack@XX-ospd ~]$ ssh root@[root@XXXSM03 ~]# monit stop all
Stap 2. Indien de VM een SM, AM of arbiter is, stop dan de sessionemersdiensten:
[root@XXXSM03 ~]# cd /etc/init.d [root@XXXSM03 init.d]# ls -l sessionmgr* -rwxr-xr-x 1 root root 4544 Nov 29 23:47 sessionmgr-27717 -rwxr-xr-x 1 root root 4399 Nov 28 22:45 sessionmgr-27721 -rwxr-xr-x 1 root root 4544 Nov 29 23:47 sessionmgr-27727
Stap 3. Voor elk bestand met de naam sessionhouder-xxxxx voert u de servicesessie uit:
[root@XXXSM03 init.d]# service sessionmgr-27717 stop
Stap 1. Lijst van de nova-aggregaten en identificeer het aggregaat dat overeenkomt met de computerserver op basis van de VPN die door de VPN wordt gehost. Dit is doorgaans het formaat <VNFNAME>-SERVICE<X>:
[stack@director ~]$ nova aggregate-list
+----+-------------------+-------------------+
| Id | Name | Availability Zone |
+----+-------------------+-------------------+
| 29 | POD1-AUTOIT | mgmt |
| 57 | VNF1-SERVICE1 | - |
| 60 | VNF1-EM-MGMT1 | - |
| 63 | VNF1-CF-MGMT1 | - |
| 66 | VNF2-CF-MGMT2 | - |
| 69 | VNF2-EM-MGMT2 | - |
| 72 | VNF2-SERVICE2 | - |
| 75 | VNF3-CF-MGMT3 | - |
| 78 | VNF3-EM-MGMT3 | - |
| 81 | VNF3-SERVICE3 | - |
+----+-------------------+-------------------+
In dit geval behoort de te vervangen computerserver tot VNF2. De corresponderende geaggregeerde lijst is VNF2-SERVICE2.
Stap 2. Verwijder het computerknooppunt uit het geïdentificeerde aggregaat (verwijder door hostname uit Sectie genoemd Identificeer de VM's die in het Compute Node-😞 worden georganiseerd
nova aggregate-remove-host
[stack@director ~]$ nova aggregate-remove-host VNF2-SERVICE2 pod1-compute-10.localdomain
Stap 3. Controleer of het berekende knooppunt uit de aggregaten is verwijderd. Nu moet de Host niet worden gerangschikt onder het aggregaat:
nova aggregate-show
[stack@director ~]$ nova aggregate-show VNF2-SERVICE2
De in dit deel genoemde stappen zijn gebruikelijk ongeacht de VM's die in het computerknooppunt worden georganiseerd.
Stap 1. Maak een script genaamd Delete_Nobh.sh met de inhoud zoals hier weergegeven. Zorg ervoor dat de genoemde sjablonen dezelfde zijn als de sjablonen die in het implementation.sh script worden gebruikt dat voor de stapel implementatie wordt gebruikt.
delete_node.sh
openstack overcloud node delete --templates -e /usr/share/openstack-tripleo-heat-templates/environments/puppet-pacemaker.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/storage-environment.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/neutron-sriov.yaml -e /home/stack/custom-templates/network.yaml -e /home/stack/custom-templates/ceph.yaml -e /home/stack/custom-templates/compute.yaml -e /home/stack/custom-templates/layout.yaml -e /home/stack/custom-templates/layout.yaml --stack
[stack@director ~]$ source stackrc
[stack@director ~]$ /bin/sh delete_node.sh
+ openstack overcloud node delete --templates -e /usr/share/openstack-tripleo-heat-templates/environments/puppet-pacemaker.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/storage-environment.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/neutron-sriov.yaml -e /home/stack/custom-templates/network.yaml -e /home/stack/custom-templates/ceph.yaml -e /home/stack/custom-templates/compute.yaml -e /home/stack/custom-templates/layout.yaml -e /home/stack/custom-templates/layout.yaml --stack pod1 49ac5f22-469e-4b84-badc-031083db0533
Deleting the following nodes from stack pod1:
- 49ac5f22-469e-4b84-badc-031083db0533
Started Mistral Workflow. Execution ID: 4ab4508a-c1d5-4e48-9b95-ad9a5baa20ae
real 0m52.078s
user 0m0.383s
sys 0m0.086s
Stap 2. Wacht tot de OpenStack-handeling naar de COMPLETE status gaat.
[stack@director ~]$ openstack stack list
+--------------------------------------+------------+-----------------+----------------------+----------------------+
| ID | Stack Name | Stack Status | Creation Time | Updated Time |
+--------------------------------------+------------+-----------------+----------------------+----------------------+
| 5df68458-095d-43bd-a8c4-033e68ba79a0 | pod1 | UPDATE_COMPLETE | 2018-05-08T21:30:06Z | 2018-05-08T20:42:48Z |
+--------------------------------------+------------+-----------------+----------------------+----------------------+
Verwijdert de computerservice uit de servicelijst.
[stack@director ~]$ source corerc
[stack@director ~]$ openstack compute service list | grep compute-8
| 404 | nova-compute | pod1-compute-8.localdomain | nova | enabled | up | 2018-05-08T18:40:56.000000 |
openstack compute service delete
[stack@director ~]$ openstack compute service delete 404
Verwijdert de oude neutron-agent en open-switch-agent voor de computerserver:
[stack@director ~]$ openstack network agent list | grep compute-8
| c3ee92ba-aa23-480c-ac81-d3d8d01dcc03 | Open vSwitch agent | pod1-compute-8.localdomain | None | False | UP | neutron-openvswitch-agent |
| ec19cb01-abbb-4773-8397-8739d9b0a349 | NIC Switch agent | pod1-compute-8.localdomain | None | False | UP | neutron-sriov-nic-agent |
openstack network agent delete
[stack@director ~]$ openstack network agent delete c3ee92ba-aa23-480c-ac81-d3d8d01dcc03
[stack@director ~]$ openstack network agent delete ec19cb01-abbb-4773-8397-8739d9b0a349
Verwijdert een knooppunt uit de ironische database en controleer deze.
[stack@director ~]$ source stackrc
nova show| grep hypervisor
[stack@director ~]$ nova show pod1-compute-10 | grep hypervisor
| OS-EXT-SRV-ATTR:hypervisor_hostname | 4ab21917-32fa-43a6-9260-02538b5c7a5a
ironic node-delete
[stack@director ~]$ ironic node-delete 4ab21917-32fa-43a6-9260-02538b5c7a5a
[stack@director ~]$ ironic node-list (node delete must not be listed now)
De stappen om een nieuwe UCS C240 M4-server te installeren en de eerste setup-stappen kunnen worden doorverwezen van: Cisco UCS C240 M4-serverinstallatie en -servicegids
Stap 1. Nadat de server is geïnstalleerd, plaatst u de harde schijven in de respectieve sleuven als de oude server.
Stap 2. Meld u aan bij een server met het 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
Stap 4. Om de status van fysieke schijven te controleren, dient u te navigeren naar Opslag > Cisco 12G SAS modulaire controller (SLOT-HBA) > Physical Drive-informatie. Het moet goed zijn geconfigureerd
Het hier weergegeven opslagapparaat kan een SSD-station zijn.
Stap 5. Om een virtueel station te maken van de fysieke stations met DVD-niveau 1, navigeer naar opslagniveau > Cisco 12G SAS modulaire controller (SLOT-HBA) > Controller informatie > Virtuele station maken van ongebruikte fysieke stuurprogramma's
Stap 6. Selecteer de VD en stel de set in als Boot Drive, zoals in de afbeelding.
Stap 7. Om IPMI via LAN in te schakelen, navigeer naar Admin > Communicatieservices > Communicatieservices, zoals in de afbeelding.
Stap 8. Om hyperthreading uit te schakelen, zoals in de afbeelding wordt getoond, navigeer om te berekenen > Nu > configuratiescherm > Geavanceerd > processorconfiguratie.
Opmerking: Het beeld dat hier wordt getoond en de configuratiestappen die in dit gedeelte worden beschreven, zijn gebaseerd op versie 3.0(3e) van de firmware en er kunnen kleine variaties zijn als u aan andere versies werkt
De in dit deel genoemde stappen zijn gebruikelijk ongeacht de VM die door het computerknooppunt wordt georganiseerd.
Stap 1. Voeg computingsserver toe met een andere index.
Maak een add_knooppunt.json-bestand met alleen de details van de nieuwe te toevoegen computerserver. Zorg ervoor dat het indexnummer voor de nieuwe computerserver niet eerder is gebruikt. Meestal, increment de volgende hoogste berekende waarde.
Voorbeeld: Highest eerdere systeem is daarom berekend-17 en gemaakt voor computer-18 in het geval van een 2-f systeem.
Opmerking: Let op de notatie.
[stack@director ~]$ cat add_node.json
{
"nodes":[
{
"mac":[
""
],
"capabilities": "node:compute-18,boot_option:local",
"cpu":"24",
"memory":"256000",
"disk":"3000",
"arch":"x86_64",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"<PASSWORD>",
"pm_addr":"192.100.0.5"
}
]
}
Stap 2. Importeer het Help-bestand.
[stack@director ~]$ openstack baremetal import --json add_node.json
Started Mistral Workflow. Execution ID: 78f3b22c-5c11-4d08-a00f-8553b09f497d
Successfully registered node UUID 7eddfa87-6ae6-4308-b1d2-78c98689a56e
Started Mistral Workflow. Execution ID: 33a68c16-c6fd-4f2a-9df9-926545f2127e
Successfully set all nodes to available.
Stap 3. Start Nota-inspectie met behulp van de UUID die uit de vorige stap is opgemerkt.
[stack@director ~]$ openstack baremetal node manage 7eddfa87-6ae6-4308-b1d2-78c98689a56e
[stack@director ~]$ ironic node-list |grep 7eddfa87
| 7eddfa87-6ae6-4308-b1d2-78c98689a56e | None | None | power off | manageable | False |
[stack@director ~]$ openstack overcloud node introspect 7eddfa87-6ae6-4308-b1d2-78c98689a56e --provide
Started Mistral Workflow. Execution ID: e320298a-6562-42e3-8ba6-5ce6d8524e5c
Waiting for introspection to finish...
Successfully introspected all nodes.
Introspection completed.
Started Mistral Workflow. Execution ID: c4a90d7b-ebf2-4fcb-96bf-e3168aa69dc9
Successfully set all nodes to available.
[stack@director ~]$ ironic node-list |grep available
| 7eddfa87-6ae6-4308-b1d2-78c98689a56e | None | None | power off | available | False |
Stap 4. Voeg IP-adressen toe aan custom-templates/layout.yml onder ComputingIP’s. U voegt dat adres toe aan het einde van de lijst voor elk type, computer-0 dat hier als voorbeeld wordt weergegeven.
ComputeIPs:
internal_api:
- 11.120.0.43
- 11.120.0.44
- 11.120.0.45
- 11.120.0.43 <<< take compute-0 .43 and add here
tenant:
- 11.117.0.43
- 11.117.0.44
- 11.117.0.45
- 11.117.0.43 << and here
storage:
- 11.118.0.43
- 11.118.0.44
- 11.118.0.45
- 11.118.0.43 << and here
Stap 5. Voer script op dat eerder gebruikt is om de stapel te implementeren om het nieuwe computerknooppunt aan de overcloud toe te voegen.
[stack@director ~]$ ./deploy.sh
++ openstack overcloud deploy --templates -r /home/stack/custom-templates/custom-roles.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/puppet-pacemaker.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/storage-environment.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/neutron-sriov.yaml -e /home/stack/custom-templates/network.yaml -e /home/stack/custom-templates/ceph.yaml -e /home/stack/custom-templates/compute.yaml -e /home/stack/custom-templates/layout.yaml --stack ADN-ultram --debug --log-file overcloudDeploy_11_06_17__16_39_26.log --ntp-server 172.24.167.109 --neutron-flat-networks phys_pcie1_0,phys_pcie1_1,phys_pcie4_0,phys_pcie4_1 --neutron-network-vlan-ranges datacentre:1001:1050 --neutron-disable-tunneling --verbose --timeout 180
…
Starting new HTTP connection (1): 192.200.0.1
"POST /v2/action_executions HTTP/1.1" 201 1695
HTTP POST http://192.200.0.1:8989/v2/action_executions 201
Overcloud Endpoint: http://10.1.2.5:5000/v2.0
Overcloud Deployed
clean_up DeployOvercloud:
END return value: 0
real 38m38.971s
user 0m3.605s
sys 0m0.466s
Stap 6. Wacht tot de openstack-stackstatus is voltooid.
[stack@director ~]$ openstack stack list
+--------------------------------------+------------+-----------------+----------------------+----------------------+
| ID | Stack Name | Stack Status | Creation Time | Updated Time |
+--------------------------------------+------------+-----------------+----------------------+----------------------+
| 5df68458-095d-43bd-a8c4-033e68ba79a0 | ADN-ultram | UPDATE_COMPLETE | 2017-11-02T21:30:06Z | 2017-11-06T21:40:58Z |
+--------------------------------------+------------+-----------------+----------------------+----------------------+
Stap 7. Controleer dat het nieuwe computerknooppunt in de actieve status is.
[stack@director ~]$ source stackrc
[stack@director ~]$ nova list |grep compute-18
| 0f2d88cd-d2b9-4f28-b2ca-13e305ad49ea | pod1-compute-18 | ACTIVE | - | Running | ctlplane=192.200.0.117 |
[stack@director ~]$ source corerc
[stack@director ~]$ openstack hypervisor list |grep compute-18
| 63 | pod1-compute-18.localdomain |
Voeg het computerknooppunt toe aan de aggregaat-host en controleer of de host is toegevoegd.
nova aggregate-add-host
[stack@director ~]$ nova aggregate-add-host VNF2-SERVICE2 pod1-compute-18.localdomain
nova aggregate-show
[stack@director ~]$ nova aggregate-show VNF2-SERVICE2
Stap 1. De VM bevindt zich in de nova-lijst in de foutstatus.
[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 |
Stap 2. Herstel de VM 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
Stap 3. Controleer 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].
Opmerking: Als VM in de afsluitbare stand staat, schakelt u deze in met behulp van ESC_nc_cli van ESC.
Controleer de diagnostics.sh van de clustermanager VM & indien er een fout voor de VM's wordt gevonden die wordt teruggevonden, dan
Stap 1. Meld u aan bij de betreffende VM.
[stack@XX-ospd ~]$ ssh root@[root@XXXSM03 ~]# monit start all
Stap 2. Indien de VM een SM is, OAM of arbiter, naast deze is, start de sessiediensten die eerder zijn gestopt:
Start voor elk bestand met de naam sessionetur-xxxxx de service-sessie:
[root@XXXSM03 init.d]# service sessionmgr-27717 start
Als de diagnostiek nog niet duidelijk is, moet u building_all.sh van Cluster Manager VM uitvoeren en vervolgens VM-init op de actieve VM uitvoeren.
/var/qps/install/current/scripts/build_all.sh
ssh VM e.g. ssh pcrfclient01
/etc/init.d/vm-init
Indien de ESC-herstelopdracht (hierboven) niet werkt (VM_RECOVERY_FAILED) dan de individuele VM's verwijderen en lezen.
Vanuit ESC Portal:
Stap 1. Plaats uw cursor over de blauwe knop Action (Actie), een pop-up-venster, nu klikt op Exportsjabloon, zoals in de afbeelding weergegeven.
Stap 2. Er is een optie om de sjabloon naar de lokale machine te downloaden, en controleer op Opslaan bestand, zoals in de afbeelding.
Stap 3. Zoals in de afbeelding, selecteert u een locatie en slaat u het bestand op voor later gebruik.
Stap 4. Meld u aan bij het actieve ESC zodat de site kan worden verwijderd en kopieert u het bovengenoemde bestand in de ESC-map.
/opt/cisco/esc/cisco-cps/config/gr/tmo/gen
Stap 5. Andere map naar /opt/cisco/esc/cisco-cps/fig/gr/tmo/gen:
cd /opt/cisco/esc/cisco-cps/config/gr/tmo/gen
In deze stap wijzigt u het uitvoersjabloonbestand om de VM-groep of de groepen die met de VM's verbonden zijn, te verwijderen die moeten worden hersteld.
Het sjabloonbestand voor export is voor een specifiek cluster.
Binnen dat cluster zijn meerdere vm_groepen. Er zijn één of meer vm_groepen voor elk VM-type (PD, PS, SM, OM).
Opmerking: Sommige vm_groepen hebben meer dan één VM. Alle VM's binnen die groep worden verwijderd en opnieuw toegevoegd.
Binnen die introductie moet je een of meer van de vm_groepen labelen voor het wissen.
Voorbeeld:
<vm_groep>
<naam>cm</naam>
Wijzig nu de <vm_group>in <vm_group nc:operation="Delete"> en slaat de wijzigingen op.
Vanaf de ESC-run:
/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli edit-config /opt/cisco/esc/cisco-cps/config/gr/tmo/gen/
Vanaf het ESC Portal moet u één of meer VM's kunnen zien die naar de staat van afschrijving gaan en dan volledig verdwijnen.
De vorderingen kunnen worden opgespoord in het ESC /var/log/esc/yangesc.log
Voorbeeld:
09:09:12,608 29-Jan-2018 INFO ===== UPDATE SERVICE REQUEST RECEIVED(UNDER TENANT) ===== 09:09:12,608 29-Jan-2018 INFO Tenant name: Pcrf 09:09:12,609 29-Jan-2018 INFO Deployment name: WSP1-tmo 09:09:29,794 29-Jan-2018 INFO 09:09:29,794 29-Jan-2018 INFO ===== CONFD TRANSACTION ACCEPTED ===== 09:10:19,459 29-Jan-2018 INFO 09:10:19,459 29-Jan-2018 INFO ===== SEND NOTIFICATION STARTS ===== 09:10:19,459 29-Jan-2018 INFO Type: VM_UNDEPLOYED 09:10:19,459 29-Jan-2018 INFO Status: SUCCESS 09:10:19,459 29-Jan-2018 INFO Status Code: 200 | | | 09:10:22,292 29-Jan-2018 INFO ===== SEND NOTIFICATION STARTS ===== 09:10:22,292 29-Jan-2018 INFO Type: SERVICE_UPDATED 09:10:22,292 29-Jan-2018 INFO Status: SUCCESS 09:10:22,292 29-Jan-2018 INFO Status Code: 200
In deze stap wijzigt u het uitvoersjabloonbestand om de VM-groep of de groepen die met de VM's verbonden zijn die worden teruggewonnen, opnieuw toe te voegen.
Het uitvoersjabloonbestand is uitgesplitst in de twee implementaties (cluster1 / cluster2).
Binnen elke cluster is een vm_group. Er zijn één of meer vm_groepen voor elk VM-type (PD, PS, SM, OM).
Opmerking: Sommige vm_groepen hebben meer dan één VM. Alle VM's binnen die groep worden opnieuw toegevoegd.
Voorbeeld:
<vm_group nc:operation="Delete">
<naam>cm</naam>
Verander de <vm_group nc:operation="Delete">naar alleen <vm_group>.
Opmerking: Als de VM's opnieuw moeten worden opgebouwd omdat de host werd vervangen, kan de hostnaam van de host zijn gewijzigd. Als de hostname van de HOST is veranderd dan moet de hostname binnen de plaatsingssectie van de vm_group worden bijgewerkt.
<plaatsing>
<type>zone_host</type>
<handhaving>streng</handhaving>
<host>www-computing-4.localdomain</host>
</plaatsing>
Update de naam van de gastheer die in de voorafgaande sectie wordt getoond aan de nieuwe hostname zoals verstrekt door het Ultra-M team voorafgaand aan de uitvoering van deze MOP. Na de installatie van de nieuwe host slaat u de wijzigingen op.
Vanaf de ESC-run:
/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli edit-config /opt/cisco/esc/cisco-cps/config/gr/tmo/gen/
Vanaf het ESC Portal kunt u een of meer VM's opnieuw zien verschijnen en vervolgens in de actieve toestand.
De vorderingen kunnen worden opgespoord in het ESC /var/log/esc/yangesc.log
Voorbeeld:
09:14:00,906 29-Jan-2018 INFO ===== UPDATE SERVICE REQUESTRECEIVED (UNDER TENANT) ===== 09:14:00,906 29-Jan-2018 INFO Tenant name: Pcrf 09:14:00,906 29-Jan-2018 INFO Deployment name: WSP1-tmo 09:14:01,542 29-Jan-2018 INFO 09:14:01,542 29-Jan-2018 INFO ===== CONFD TRANSACTION ACCEPTED ===== 09:16:33,947 29-Jan-2018 INFO 09:16:33,947 29-Jan-2018 INFO ===== SEND NOTIFICATION STARTS ===== 09:16:33,947 29-Jan-2018 INFO Type: VM_DEPLOYED 09:16:33,947 29-Jan-2018 INFO Status: SUCCESS 09:16:33,947 29-Jan-2018 INFO Status Code: 200 | | | 09:19:00,148 29-Jan-2018 INFO ===== SEND NOTIFICATION STARTS ===== 09:19:00,148 29-Jan-2018 INFO Type: VM_ALIVE 09:19:00,148 29-Jan-2018 INFO Status: SUCCESS 09:19:00,148 29-Jan-2018 INFO Status Code: 200 | | | 09:19:00,275 29-Jan-2018 INFO ===== SEND NOTIFICATION STARTS ===== 09:19:00,275 29-Jan-2018 INFO Type: SERVICE_UPDATED 09:19:00,275 29-Jan-2018 INFO Status: SUCCESS 09:19:00,275 29-Jan-2018 INFO Status Code: 200
Controleer of de PCRF-diensten zijn gestort en start ze.
[stack@XX-ospd ~]$ ssh root@[root@XXXSM03 ~]# monsum
[root@XXXSM03 ~]# monit start all
Indien de VM een SM is, OAM of arbiter, start dan de sessiediensten die eerder zijn gestopt:
Voor elk bestand met de naam sessionetecho-xxxxxxx starten de service sessionetechnicus:
[root@XXXSM03 init.d]# service sessionmgr-27717 start
Als de diagnostiek nog steeds niet duidelijk is, moet u building_all.sh van Cluster Manager VM uitvoeren en vervolgens VM-init op de respectieve VM uitvoeren.
/var/qps/install/current/scripts/build_all.sh
ssh VM e.g. ssh pcrfclient01
/etc/init.d/vm-init
[root@XXXSM03 init.d]# diagnostics.sh