Ersatz für Computing-Server UCS C240 M4 - CPAR
Inhalt
Einleitung
In diesem Dokument werden die Schritte beschrieben, die erforderlich sind, um einen fehlerhaften Computing-Server in einer Ultra-M-Konfiguration zu ersetzen.
Dieses Verfahren gilt für eine OpenStack-Umgebung mit der NEWTON-Version, in der der Elastic Services Controller (ESC) den Cisco Prime Access Registrar (CPAR) nicht verwaltet und CPAR direkt auf dem auf OpenStack bereitgestellten virtuellen System installiert ist.
Hintergrundinformationen
Ultra-M ist eine vorkonfigurierte und validierte virtualisierte Mobile Packet Core-Lösung, die die Bereitstellung von VNFs vereinfacht. OpenStack ist der Virtualized Infrastructure Manager (VIM) für Ultra-M und besteht aus den folgenden Knotentypen:
- Computing
- Objektspeicherplatte - Computing (OSD - Computing)
- Controller
- OpenStack-Plattform - Director (OSPD)
Die High-Level-Architektur von Ultra-M und die beteiligten Komponenten sind in diesem Bild dargestellt:
Dieses Dokument richtet sich an Cisco Mitarbeiter, die mit der Cisco Ultra-M-Plattform vertraut sind. Es beschreibt die erforderlichen Schritte für die Ausführung unter OpenStack und Redhat OS.
Abkürzungen
| MOPP | Verfahrensweise |
| OSD | Objektspeicherplatten |
| OSPD | OpenStack Platform Director |
| Festplatte | Festplattenlaufwerk |
| SSD | Solid-State-Laufwerk |
| VIM | Manager für virtuelle Infrastruktur |
| VM | Virtuelles System |
| EM | Element-Manager |
| USA | Ultra-Automatisierungsservices |
| UUID | Universeller eindeutiger IDentifier |
Workflow des MoP
Voraussetzungen
Backup
Bevor Sie einen Compute-Knoten ersetzen, ist es wichtig, den aktuellen Status Ihrer Red Hat OpenStack Platform-Umgebung zu überprüfen. Es wird empfohlen, den aktuellen Status zu überprüfen, um Komplikationen zu vermeiden, wenn der Compute-Ersetzungsvorgang aktiviert ist. Dies kann durch diesen Austausch erreicht werden.
Im Falle einer Wiederherstellung empfiehlt Cisco, eine Sicherung der OSPD-Datenbank mit folgenden Schritten durchzuführen:
[root@ al03-pod2-ospd ~]# mysqldump --opt --all-databases > /root/undercloud-all-databases.sql [root@ al03-pod2-ospd ~]# 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
Dieser Prozess stellt sicher, dass ein Knoten ersetzt werden kann, ohne die Verfügbarkeit von Instanzen zu beeinträchtigen.
Identifizieren der im Rechenknoten gehosteten VMs
Identifizieren Sie die VMs, die auf dem Computing-Server gehostet werden.
[stack@al03-pod2-ospd ~]$ nova list --field name,host +--------------------------------------+---------------------------+----------------------------------+ | ID | Name | Host | +--------------------------------------+---------------------------+----------------------------------+ | 46b4b9eb-a1a6-425d-b886-a0ba760e6114 | AAA-CPAR-testing-instance | pod2-stack-compute-4.localdomain | | 3bc14173-876b-4d56-88e7-b890d67a4122 | aaa2-21 | pod2-stack-compute-3.localdomain | | f404f6ad-34c8-4a5f-a757-14c8ed7fa30e | aaa21june | pod2-stack-compute-3.localdomain | +--------------------------------------+---------------------------+----------------------------------+
Snapshot-Prozess
Herunterfahren der CPAR-Anwendung
Schritt 1: Öffnen Sie jeden mit dem Netzwerk verbundenen SSH-Client, und stellen Sie eine Verbindung mit der CPAR-Instanz her.
Es ist wichtig, dass nicht alle vier AAA-Instanzen an einem Standort gleichzeitig heruntergefahren werden, sondern nur eine nach der anderen.
Schritt 2: Beenden Sie die CPAR-Anwendung mit diesem Befehl:
/opt/CSCOar/bin/arserver stop
In einer Meldung wird die Meldung angezeigt, dass der Cisco Prime Access Registrar Server Agent heruntergefahren wurde. sollte auftauchen.
ERROR: You can not shut down Cisco Prime Access Registrar while the
CLI is being used. Current list of running
CLI with process id is:
2903 /opt/CSCOar/bin/aregcmd –s
In diesem Beispiel muss die hervorgehobene Prozess-ID 2903 beendet werden, bevor CPAR beendet werden kann. Wenn dies der Fall ist, beenden Sie den Vorgang mit dem folgenden Befehl:
kill -9 *process_id*
Wiederholen Sie dann Schritt 1.
Schritt 3: Vergewissern Sie sich, dass die CPAR-Anwendung mit diesem Befehl tatsächlich heruntergefahren wurde:
/opt/CSCOar/bin/arstatus
Folgende Meldungen werden angezeigt:
Cisco Prime Access Registrar Server Agent not running Cisco Prime Access Registrar GUI not running
VM-Snapshot-Aufgabe
Schritt 1: Geben Sie die Horizon GUI-Website ein, die der aktuell bearbeiteten Website (Stadt) entspricht. Wenn Sie auf den Horizont zugreifen, wird der Bildschirm im Bild angezeigt:
Schritt 2: Navigieren Sie, wie in der Abbildung dargestellt, zu Projekt > Instanzen.
Wenn der verwendete Benutzer cpar war, werden in diesem Menü nur die 4 AAA-Instanzen angezeigt.
Schritt 3: Fahren Sie jeweils nur eine Instanz herunter, und wiederholen Sie den gesamten Vorgang in diesem Dokument. Um die VM herunterzufahren, navigieren Sie zu Aktionen > Instanz herunterfahren und bestätigen Sie Ihre Auswahl.
Schritt 4 Überprüfen Sie, ob die Instanz tatsächlich heruntergefahren wurde: Status = Shutoff (Herunterfahren) und Power State = Shut Down (Betriebsstatus = Herunterfahren).
Dieser Schritt beendet das Herunterfahren der CPAR-Software.
VM-Snapshot
Wenn die virtuellen CPAR-Systeme ausgefallen sind, können die Snapshots parallel erstellt werden, da sie zu unabhängigen Computern gehören.
Die vier QCOW2-Dateien werden parallel erstellt.
Erstellen Sie einen Snapshot jeder AAA-Instanz (25 Minuten -1 Stunde) (25 Minuten für Instanzen, die ein qcow-Image als Quelle verwendet haben, und 1 Stunde für Instanzen, die ein Raw-Image als Quelle verwenden).
Schritt 1: Melden Sie sich bei der OpenStack Horizon GUI des POD an.
Schritt 2. Fahren Sie nach der Anmeldung mit dem Abschnitt Projekt > Berechnen > Instanzen im oberen Menü fort, und suchen Sie nach den AAA-Instanzen.
Schritt 3: Klicken Sie auf Snapshot erstellen, um mit der Snapshot-Erstellung fortzufahren (diese muss für die entsprechende AAA-Instanz ausgeführt werden).
Schritt 4: Nachdem der Snapshot ausgeführt wurde, navigieren Sie zum Menü Images und überprüfen Sie, ob er abgeschlossen ist und keine Probleme meldet.
Schritt 5: Der nächste Schritt besteht darin, den Snapshot im QCOW2-Format herunterzuladen und auf eine entfernte Entität zu übertragen, falls die OSPD während dieses Vorgangs verloren geht. Um dies zu erreichen, identifizieren Sie den Snapshot mit diesem Befehl glance image-list auf OSPD Ebene
[root@elospd01 stack]# glance image-list +--------------------------------------+---------------------------+ | ID | Name | +--------------------------------------+---------------------------+ | 80f083cb-66f9-4fcf-8b8a-7d8965e47b1d | AAA-Temporary | | 22f8536b-3f3c-4bcc-ae1a-8f2ab0d8b950 | ELP1 cluman 10_09_2017 | | 70ef5911-208e-4cac-93e2-6fe9033db560 | ELP2 cluman 10_09_2017 | | e0b57fc9-e5c3-4b51-8b94-56cbccdf5401 | ESC-image | | 92dfe18c-df35-4aa9-8c52-9c663d3f839b | lgnaaa01-sept102017 | | 1461226b-4362-428b-bc90-0a98cbf33500 | tmobile-pcrf-13.1.1.iso | | 98275e15-37cf-4681-9bcc-d6ba18947d7b | tmobile-pcrf-13.1.1.qcow2 | +--------------------------------------+---------------------------+
Schritt 6. Nachdem der Snapshot identifiziert wurde, der heruntergeladen werden soll (in diesem Fall wird der oben in Grün markierte Snapshot sein), wird er in einem QCOW2-Format durch diesen Befehl glance image-download heruntergeladen, wie hier gezeigt.
[root@elospd01 stack]# glance image-download 92dfe18c-df35-4aa9-8c52-9c663d3f839b --file /tmp/AAA-CPAR-LGNoct192017.qcow2 &
- Das "&" sendet den Prozess in den Hintergrund. Es dauert eine Weile, bis diese Aktion abgeschlossen ist. Sobald dies geschehen ist, kann sich das Abbild im Verzeichnis /tmp befinden.
- Wenn der Prozess in den Hintergrund gesendet wird und die Verbindung unterbrochen wird, wird auch der Prozess beendet.
- Führen Sie den Befehl dissown -h aus, sodass der Prozess im Fall des Verlusts der Secure Shell (SSH)-Verbindung weiterhin auf dem OSPD ausgeführt und beendet wird.
Schritt 7: Nachdem der Download-Prozess abgeschlossen ist, muss ein Komprimierungsprozess ausgeführt werden, da dieser Snapshot aufgrund von Prozessen, Aufgaben und temporären Dateien, die vom Betriebssystem verarbeitet werden, möglicherweise mit NULL gefüllt wird. Der für die Dateikomprimierung zu verwendende Befehl lautet virt-sparsify.
[root@elospd01 stack]# virt-sparsify AAA-CPAR-LGNoct192017.qcow2 AAA-CPAR-LGNoct192017_compressed.qcow2
Dieser Vorgang dauert einige Zeit (etwa 10-15 Minuten). Nach Fertigstellung ist die resultierende Datei diejenige, die wie im nächsten Schritt angegeben auf eine externe Entität übertragen werden muss.
Um dies zu erreichen, muss die Integrität der Datei überprüft werden. Führen Sie den nächsten Befehl aus, und suchen Sie am Ende der Ausgabe nach dem Attribut corrupt.
[root@wsospd01 tmp]# qemu-img info AAA-CPAR-LGNoct192017_compressed.qcow2 image: AAA-CPAR-LGNoct192017_compressed.qcow2 file format: qcow2 virtual size: 150G (161061273600 bytes) disk size: 18G cluster_size: 65536 Format specific information: compat: 1.1 lazy refcounts: false refcount bits: 16 corrupt: false
Um ein Problem zu vermeiden, bei dem das OSPD verloren geht, muss der kürzlich erstellte Snapshot im QCOW2-Format auf eine externe Einheit übertragen werden. Bevor Sie mit der Dateiübertragung beginnen, müssen Sie überprüfen, ob das Ziel über genügend freien Speicherplatz verfügt. Verwenden Sie den Befehl df -kh, um den Speicherplatz zu überprüfen. Es wird empfohlen, ihn vorübergehend über SFTP-sftp root@x.x.x.x an die OSPD eines anderen Standorts zu übertragen, wobei x.x.x.x die IP einer Remote-OSPD ist. Um die Übertragung zu beschleunigen, kann das Ziel an mehrere OSPDs gesendet werden. Auf die gleiche Weise kann dieser Befehl mit scp *name_of_the_file*.qcow2 root@ x.x.x.x:/tmp (wobei x.x.x.x die IP-Adresse eines Remote-OSPD ist) verwendet werden, um die Datei in ein anderes OSPD zu übertragen.
Sicheres Ausschalten
Knoten zum Ausschalten
- So schalten Sie die Instanz aus: nova stop <INSTANCE_NAME>
- Jetzt sehen Sie den Instanznamen mit dem Status shutoff.
[stack@director ~]$ nova stop aaa2-21 Request to stop server aaa2-21 has been accepted. [stack@director ~]$ nova list +--------------------------------------+---------------------------+---------+------------+-------------+------------------------------------------------------------------------------------------------------------+ | ID | Name | Status | Task State | Power State | Networks | +--------------------------------------+---------------------------+---------+------------+-------------+------------------------------------------------------------------------------------------------------------+ | 46b4b9eb-a1a6-425d-b886-a0ba760e6114 | AAA-CPAR-testing-instance | ACTIVE | - | Running | tb1-mgmt=172.16.181.14, 10.225.247.233; radius-routable1=10.160.132.245; diameter-routable1=10.160.132.231 | | 3bc14173-876b-4d56-88e7-b890d67a4122 | aaa2-21 | SHUTOFF | - | Shutdown | diameter-routable1=10.160.132.230; radius-routable1=10.160.132.248; tb1-mgmt=172.16.181.7, 10.225.247.234 | | f404f6ad-34c8-4a5f-a757-14c8ed7fa30e | aaa21june | ACTIVE | - | Running | diameter-routable1=10.160.132.233; radius-routable1=10.160.132.244; tb1-mgmt=172.16.181.10 | +--------------------------------------+---------------------------+---------+------------+-------------+------------------------------------------------------------------------------------------------------------+
Löschen von Rechenknoten
Die in diesem Abschnitt beschriebenen Schritte sind unabhängig von den im Computing-Knoten gehosteten VMs üblich.
Löschen des Rechenknotens aus der Serviceliste
Löschen Sie den Computing-Service aus der Serviceliste:
[stack@director ~]$ openstack compute service list |grep compute-3 | 138 | nova-compute | pod2-stack-compute-3.localdomain | AZ-aaa | enabled | up | 2018-06-21T15:05:37.000000 |
openStack Compute Service delete <ID>
[stack@director ~]$ openstack compute service delete 138
Neutronenagenten löschen
Löschen Sie den alten zugeordneten Neutronenagenten und Open-Switch-Agenten für den Compute-Server:
[stack@director ~]$ openstack network agent list | grep compute-3 | 3b37fa1d-01d4-404a-886f-ff68cec1ccb9 | Open vSwitch agent | pod2-stack-compute-3.localdomain | None | True | UP | neutron-openvswitch-agent |
openstack network agent delete <ID>
[stack@director ~]$ openstack network agent delete 3b37fa1d-01d4-404a-886f-ff68cec1ccb9
Aus der Ironischen Datenbank löschen
Löschen Sie einen Knoten aus der ironischen Datenbank, und überprüfen Sie ihn:
nova show <Compute-node> | grep Hypervisor
[root@director ~]# source stackrc [root@director ~]# nova show pod2-stack-compute-4 | grep hypervisor | OS-EXT-SRV-ATTR:hypervisor_hostname | 7439ea6c-3a88-47c2-9ff5-0a4f24647444
ironic node-delete <ID>
[stack@director ~]$ ironic node-delete 7439ea6c-3a88-47c2-9ff5-0a4f24647444 [stack@director ~]$ ironic node-list
Der gelöschte Knoten darf jetzt nicht in der ironischen Knotenliste aufgeführt werden.
Aus Overcloud löschen
Schritt 1. Erstellen Sie eine Skriptdatei mit dem Namen delete_node.sh mit dem angezeigten Inhalt. Stellen Sie sicher, dass die genannten Vorlagen mit den Vorlagen übereinstimmen, die im für die Stapelbereitstellung verwendeten Skript deploy.sh verwendet werden:
delete_node.sh
openstack overcloud node delete --templates -e /usr/share/openstack-tripleo-heat-templates/environments/puppet-pacemaker.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/storage-environment.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/neutron-sriov.yaml -e /home/stack/custom-templates/network.yaml -e /home/stack/custom-templates/ceph.yaml -e /home/stack/custom-templates/compute.yaml -e /home/stack/custom-templates/layout.yaml -e /home/stack/custom-templates/layout.yaml --stack <stack-name> <UUID>
[stack@director ~]$ source stackrc [stack@director ~]$ /bin/sh delete_node.sh + openstack overcloud node delete --templates -e /usr/share/openstack-tripleo-heat-templates/environments/puppet-pacemaker.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/storage-environment.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/neutron-sriov.yaml -e /home/stack/custom-templates/network.yaml -e /home/stack/custom-templates/ceph.yaml -e /home/stack/custom-templates/compute.yaml -e /home/stack/custom-templates/layout.yaml -e /home/stack/custom-templates/layout.yaml --stack pod2-stack 7439ea6c-3a88-47c2-9ff5-0a4f24647444 Deleting the following nodes from stack pod2-stack: - 7439ea6c-3a88-47c2-9ff5-0a4f24647444 Started Mistral Workflow. Execution ID: 4ab4508a-c1d5-4e48-9b95-ad9a5baa20ae real 0m52.078s user 0m0.383s sys 0m0.086s
Schritt 2: Warten Sie, bis der OpenStack-Stapelvorgang in den Status COMPLETE wechselt:
[stack@director ~]$ openstack stack list +--------------------------------------+------------+-----------------+----------------------+----------------------+ | ID | Stack Name | Stack Status | Creation Time | Updated Time | +--------------------------------------+------------+-----------------+----------------------+----------------------+ | 5df68458-095d-43bd-a8c4-033e68ba79a0 | pod2-stack | UPDATE_COMPLETE | 2018-05-08T21:30:06Z | 2018-05-08T20:42:48Z | +--------------------------------------+------------+-----------------+----------------------+----------------------+
Installieren des neuen Rechenknotens
Die Schritte zur Installation eines neuen UCS C240 M4 Servers und die ersten Einrichtungsschritte finden Sie im Cisco UCS C240 M4 Server Installation and Service Guide.
Schritt 1: Legen Sie nach der Installation des Servers die Festplatten als alten Server in die entsprechenden Steckplätze ein.
Schritt 2: Melden Sie sich mit der CIMC-IP beim Server an.
Schritt 3: Führen Sie ein BIOS-Upgrade durch, wenn die Firmware nicht der zuvor verwendeten empfohlenen Version entspricht. Die Schritte für das BIOS-Upgrade sind hier aufgeführt: BIOS-Upgrade-Leitfaden für Cisco UCS Rackmount-Server der C-Serie
Schritt 4: Um den Status der physischen Laufwerke zu überprüfen, der "Nicht konfiguriert, gut" lautet, navigieren Sie zu Storage > Cisco 12G SAS Modular Raid Controller (SLOT-HBA) > Physical Drive Info (Informationen zu physischen Laufwerken).
Schritt 5: Um ein virtuelles Laufwerk von den physischen Laufwerken mit RAID-Level 1 zu erstellen, navigieren Sie zu Storage > Cisco 12G SAS Modular Raid Controller (SLOT-HBA) > Controller Info > Create Virtual Drive from Unused Physical Drives (Virtuelles Laufwerk aus nicht verwendeten physischen Laufwerken erstellen).
Schritt 6: Wählen Sie das VD aus, und konfigurieren Sie Set as Boot Drive, wie im Bild gezeigt.
Schritt 7: Um IPMI über LAN zu aktivieren, navigieren Sie zu Admin > Communication Services > Communication Services, wie im Bild dargestellt.
Schritt 8: Um Hyperthreading zu deaktivieren, navigieren Sie zu Compute > BIOS > Configure BIOS > Advanced > Processor Configuration.
Neuen Rechenknoten zur Overcloud hinzufügen
Die in diesem Abschnitt beschriebenen Schritte sind unabhängig von der VM, die vom Computing-Knoten gehostet wird, üblich.
Schritt 1: Hinzufügen eines Compute-Servers mit einem anderen Index
Erstellen Sie eine Datei add_node.json, in der nur die Details des neuen hinzuzufügenden Computing-Servers enthalten sind. Stellen Sie sicher, dass die Indexnummer für den neuen Computing-Server zuvor nicht verwendet wurde. In der Regel wird der nächsthöhere Rechenwert erhöht.
Beispiel: Der höchste vorherige Wert war compute-17, daher wurde compute-18 für ein 2-VNF-System erstellt.
[stack@director ~]$ cat add_node.json
{
"nodes":[
{
"mac":[
"<MAC_ADDRESS>"
],
"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"
}
]
}
Schritt 2: Importieren Sie die JSON-Datei.
[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.
Schritt 3: Führen Sie eine Knotenintrospektion mit der im vorherigen Schritt beschriebenen UUID aus.
[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 |
Schritt 4: Führen Sie das Skript deploy.sh aus, das zuvor für die Bereitstellung des Stacks verwendet wurde, um den neuen Computenode zum Overcloud-Stack hinzuzufügen:
[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
Schritt 5: Warten Sie, bis der OpenStack-Stack-Status "Abgeschlossen" lautet.
[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 | +--------------------------------------+------------+-----------------+----------------------+----------------------+
Schritt 6: Überprüfen Sie, ob sich der neue Rechenknoten im Status "Aktiv" befindet.
[root@director ~]# nova list | grep pod2-stack-compute-4 | 5dbac94d-19b9-493e-a366-1e2e2e5e34c5 | pod2-stack-compute-4 | ACTIVE | - | Running | ctlplane=192.200.0.116 |
Stellen Sie die VMs wieder her
Wiederherstellen einer Instanz durch Snapshot
Wiederherstellungsprozess:
Es ist möglich, die vorherige Instanz mit dem Snapshot, der in den vorherigen Schritten erstellt wurde, erneut bereitzustellen.
Schritt 1 [OPTIONAL]. Wenn kein vorheriger VMsnapshot verfügbar ist, stellen Sie eine Verbindung mit dem OSPD-Knoten her, an den die Sicherung gesendet wurde, und senden Sie die Sicherung zurück an den ursprünglichen OSPD-Knoten. Über sftp root@x.x.x.x, wobei x.x.x.x die IP der ursprünglichen OSPD ist. Speichern Sie die Snapshot-Datei im Verzeichnis /tmp.
Schritt 2: Stellen Sie eine Verbindung mit dem OSPD-Knoten her, in dem die Instanz erneut bereitgestellt wird.
Verwenden Sie den folgenden Befehl, um die Umgebungsvariablen zu generieren:
# source /home/stack/pod1-stackrc-Core-CPAR
Schritt 3: Um den Snapshot als Image zu verwenden, muss er an Horizont als solches hochgeladen werden. Verwenden Sie dazu den nächsten Befehl.
#glance image-create -- AAA-CPAR-Date-snapshot.qcow2 --container-format bare --disk-format qcow2 --name AAA-CPAR-Date-snapshot
Der Prozess ist am Horizont zu erkennen.
Schritt 4. Navigieren Sie im Horizont zu Projekt > Instanzen, und klicken Sie auf Instanz starten, wie im Bild dargestellt.
Schritt 5: Geben Sie den Instanznamen ein, und wählen Sie die Verfügbarkeitszone aus, wie im Bild dargestellt.
Schritt 6. Wählen Sie auf der Registerkarte Quelle das Bild aus, um die Instanz zu erstellen. Im Menü Select Boot Source wählen Sie Image, eine Liste von Images wird hier angezeigt, wählen Sie die, die zuvor hochgeladen wurde, als Sie auf + Zeichen klicken.
Schritt 7. Wählen Sie auf der Registerkarte Geschmack die AAA-Variante aus, wenn Sie auf das Zeichen + klicken, wie im Bild dargestellt.
Schritt 8. Navigieren Sie nun zur Registerkarte Netzwerke und wählen Sie die Netzwerke aus, die die Instanz benötigt, während Sie auf das +-Zeichen klicken. Wählen Sie in diesem Fall Ø-soutable1, radius-routable1 und tb1-mgmt aus, wie im Bild gezeigt.
Schritt 9. Klicken Sie auf Instanz starten, um sie zu erstellen. Die Fortschritte können in "Horizont" beobachtet werden:
Nach einigen Minuten ist die Instanz vollständig bereitgestellt und einsatzbereit.
Erstellen und Zuweisen einer Floating-IP-Adresse
Eine Floating-IP-Adresse ist eine routbare Adresse, d. h. sie ist von außerhalb der Ultra M/OpenStack-Architektur erreichbar und kann mit anderen Knoten im Netzwerk kommunizieren.
Schritt 1: Navigieren Sie im oberen Menü von Horizon zu Admin > Floating IPs.
Schritt 2: Klicken Sie auf die Schaltfläche IP dem Projekt zuordnen.
Schritt 3: Wählen Sie im Fenster Unverankerte IP-Adresse zuweisen den Pool, aus dem die neue unverankerte IP stammt, das Projekt, dem die neue unverankerte IP-Adresse zugewiesen wird, und die neue unverankerte IP-Adresse selbst aus.
Beispiele:
Schritt 4: Klicken Sie auf Allocate Floating IP-Schaltfläche.
Schritt 5: Navigieren Sie im oberen Menü von Horizon zu Projekt > Instanzen.
Schritt 6. Klicken Sie in der Spalte Aktion auf den Pfeil, der in der Schaltfläche Snapshot erstellen nach unten zeigt. Es sollte ein Menü angezeigt werden. Wählen Sie die Option Unverankerte IP zuordnen aus.
Schritt 7: Wählen Sie die entsprechende Floating-IP-Adresse, die im Feld "IP Address" verwendet werden soll, und wählen Sie die entsprechende Verwaltungsschnittstelle (eth0) aus der neuen Instanz, der diese Floating-IP im zuzuordnenden Port zugewiesen wird. Als Beispiel für diese Vorgehensweise sehen Sie bitte das nächste Bild.
Schritt 8: Klicken Sie auf Zuordnen.
SSH aktivieren
Schritt 1: Navigieren Sie im oberen Menü "Horizont" zu Projekt > Instanzen.
Schritt 2: Klicken Sie auf den Namen der Instanz/VM, die im Abschnitt Neue Instanz starten erstellt wurde.
Schritt 3: Klicken Sie auf die Registerkarte Konsole. Es wird die CLI des virtuellen Systems angezeigt.
Schritt 4: Geben Sie nach der Anzeige der CLI die entsprechenden Anmeldeinformationen ein:
Benutzername: Wurzel
Kennwort: cisco123
Schritt 5: Geben Sie in der CLI den Befehl vi /etc/ssh/sshd_config ein, um die ssh-Konfiguration zu bearbeiten.
Schritt 6: Wenn die SSH-Konfigurationsdatei geöffnet ist, drücken Sie I, um die Datei zu bearbeiten. Dann suchen Sie nach dem Abschnitt unten gezeigt und ändern Sie die erste Zeile von PasswordAuthentication no auf PasswordAuthentication yes.
Schritt 7. Drücken Sie ESC und geben Sie :wq! um die Änderungen der Datei sshd_config zu speichern.
Schritt 8: Führen Sie den Befehl service sshd restart aus.
Schritt 9: Um zu testen, ob die SSH-Konfigurationsänderungen korrekt angewendet wurden, öffnen Sie einen beliebigen SSH-Client, und versuchen Sie, mithilfe der der Instanz zugewiesenen Floating-IP (z. B. 10.145.0.249) und dem Benutzer-Root eine sichere Remote-Verbindung herzustellen.
Einrichten einer SSH-Sitzung
Öffnen Sie eine SSH-Sitzung mit der IP-Adresse des entsprechenden virtuellen Systems/Servers, auf dem die Anwendung installiert ist.
Start der CPAR-Instanz
Führen Sie die folgenden Schritte aus, wenn die Aktivität abgeschlossen wurde und die CPAR-Services auf der Website, die heruntergefahren wurde, wiederhergestellt werden können.
- Um sich wieder bei Horizon anzumelden, navigieren Sie zu Project > Instance > Start Instance.
- Überprüfen Sie, ob der Status der Instanz aktiv ist und der Netzstatus aktiv ist:
Integritätsprüfung nach einer Aktivität
Schritt 1: Führen Sie den Befehl /opt/CSCOar/bin/arstatus auf Betriebssystemebene aus.
[root@wscaaa04 ~]# /opt/CSCOar/bin/arstatus Cisco Prime AR RADIUS server running (pid: 24834) Cisco Prime AR Server Agent running (pid: 24821) Cisco Prime AR MCD lock manager running (pid: 24824) Cisco Prime AR MCD server running (pid: 24833) Cisco Prime AR GUI running (pid: 24836) SNMP Master Agent running (pid: 24835) [root@wscaaa04 ~]#
Schritt 2: Führen Sie den Befehl /opt/CSCOar/bin/aregcmd auf Betriebssystemebene aus, und geben Sie die Admin-Anmeldeinformationen ein. Vergewissern Sie sich, dass CPAR Health 10 von 10 ist, und verlassen Sie CPAR CLI.
[root@aaa02 logs]# /opt/CSCOar/bin/aregcmd
Cisco Prime Access Registrar 7.3.0.1 Configuration Utility
Copyright (C) 1995-2017 by Cisco Systems, Inc. All rights reserved.
Cluster:
User: admin
Passphrase:
Logging in to localhost
[ //localhost ]
LicenseInfo = PAR-NG-TPS 7.2(100TPS:)
PAR-ADD-TPS 7.2(2000TPS:)
PAR-RDDR-TRX 7.2()
PAR-HSS 7.2()
Radius/
Administrators/
Server 'Radius' is Running, its health is 10 out of 10
--> exit
Schritt 3.Ausführen des Befehls netstat | Grep-Durchmesser und überprüfen Sie, ob alle DRA-Verbindungen hergestellt sind.
Die unten genannte Ausgabe ist für eine Umgebung, in der Durchmesserverbindungen erwartet werden. Wenn weniger Links angezeigt werden, stellt dies eine Trennung von der DRA dar, die analysiert werden muss.
[root@aa02 logs]# netstat | grep diameter tcp 0 0 aaa02.aaa.epc.:77 mp1.dra01.d:diameter ESTABLISHED tcp 0 0 aaa02.aaa.epc.:36 tsa6.dra01:diameter ESTABLISHED tcp 0 0 aaa02.aaa.epc.:47 mp2.dra01.d:diameter ESTABLISHED tcp 0 0 aaa02.aaa.epc.:07 tsa5.dra01:diameter ESTABLISHED tcp 0 0 aaa02.aaa.epc.:08 np2.dra01.d:diameter ESTABLISHED
Schritt 4: Überprüfen Sie, ob im TPS-Protokoll Anforderungen aufgeführt sind, die von CPAR verarbeitet werden. Die hervorgehobenen Werte stellen den TPS dar, und dies sind die Werte, denen wir Aufmerksamkeit schenken müssen.
Der Wert von TPS sollte 1500 nicht überschreiten.
[root@wscaaa04 ~]# tail -f /opt/CSCOar/logs/tps-11-21-2017.csv 11-21-2017,23:57:35,263,0 11-21-2017,23:57:50,237,0 11-21-2017,23:58:05,237,0 11-21-2017,23:58:20,257,0 11-21-2017,23:58:35,254,0 11-21-2017,23:58:50,248,0 11-21-2017,23:59:05,272,0 11-21-2017,23:59:20,243,0 11-21-2017,23:59:35,244,0 11-21-2017,23:59:50,233,0
Schritt 5: Suchen Sie nach "Fehler"- oder "Alarm"-Meldungen in name_radius_1_log.
[root@aaa02 logs]# grep -E "error|alarm" name_radius_1_log
Schritt 6.Überprüfen Sie mit dem folgenden Befehl, wie viel Arbeitsspeicher der CPAR-Prozess beansprucht:
oberste | Grep Radius
[root@sfraaa02 ~]# top | grep radius 27008 root 20 0 20.228g 2.413g 11408 S 128.3 7.7 1165:41 radius
Der hervorgehobene Wert sollte kleiner sein als: 7 GB, d. h. die maximal zulässige Größe auf Anwendungsebene.
FeedbackCisco kontaktieren
- Eine Supportanfrage öffnen
- (Erfordert einen Cisco Servicevertrag)