Inhalt

Einführung

Hintergrundinformationen

Abkürzungen

Workflow des MoP

Herunterfahren der CPAR-Anwendung

VM-Snapshot-Aufgabe

VM-Snapshot

VMs wiederherstellen

Instanz mit Snapshot wiederherstellen

Floating-IP-Adresse erstellen und zuweisen

SSH aktivieren

SSH-Sitzung einrichten

CPAR-Instanzstart

Statusprüfung nach Aktivität

Einführung

Dieses Dokument beschreibt die Schritte, die erforderlich sind, um eine fehlerhafte Object Storage Disk (OSD) - Compute-Server in einer Ultra-M-Konfiguration zu ersetzen.

Dieses Verfahren gilt für eine OpenStack-Umgebung mit NEWTON-Version, in der CPAR nicht vom ESC verwaltet wird und CPAR direkt auf der VM (Virtual Machine) installiert ist, die auf OpenStack bereitgestellt wird.

Hintergrundinformationen

Ultra-M ist eine vorkonfigurierte und validierte Kernlösung für virtualisierte mobile Pakete, die die Bereitstellung von VNFs vereinfacht. OpenStack ist der Virtual Infrastructure Manager (VIM) für Ultra-M und besteht aus den folgenden Knotentypen:

- 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 Mitarbeiter von Cisco, die mit der Cisco Ultra-M-Plattform vertraut sind. Es beschreibt die Schritte, die bei OpenStack und Redhat Operating System (OS) erforderlich sind.

Hinweis: Ultra M 5.1.x wird zur Definition der Verfahren in diesem Dokument berücksichtigt.

Abkürzungen

MoP

Verfahrensweise

OSD

Objektspeicherdatenträger

OSPD

OpenStack Platform Director

HDD

Festplattenlaufwerk

SSD

Solid-State-Laufwerk

VIM

Virtueller Infrastrukturmanager

VM

Virtuelles System

EM

Element Manager

USA

Ultra-Automatisierungsservices

UUID

Universell eindeutige IDentifier

Workflow des MoP

Sicherung

Bevor Sie einen Compute-Knoten ersetzen, müssen Sie den aktuellen Zustand Ihrer Red Hat OpenStack Platform-Umgebung überprüfen. Es wird empfohlen, den aktuellen Zustand zu überprüfen, um Komplikationen zu vermeiden, wenn der Compute-Ersetzungsprozess aktiviert ist. Sie kann durch diesen Austausch erreicht werden.

Im Falle einer Wiederherstellung empfiehlt Cisco, eine Sicherung der OSPD-Datenbank mithilfe der folgenden Schritte durchzuführen:

[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

Dieser Prozess stellt sicher, dass ein Knoten ausgetauscht werden kann, ohne dass die Verfügbarkeit von Instanzen beeinträchtigt wird.

Hinweis: Stellen Sie sicher, dass Sie über den Snapshot der Instanz verfügen, sodass Sie das virtuelle System bei Bedarf wiederherstellen können. Befolgen Sie die Anweisungen zum Erstellen eines Snapshots des virtuellen Systems.

1. Identifizieren Sie die im OSD-Compute-Knoten gehosteten VMs.

2. Identifizieren Sie die VMs, die auf dem Server gehostet werden.

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

| 46b4b9eb-a1a6-425d-b886-a0ba760e6114 | AAA-CPAR-testing-instance | pod2-stack-compute-4.localdomain |

Hinweis: In der hier gezeigten Ausgabe entspricht die erste Spalte dem Universally Unique IDentifier (UUID), die zweite Spalte dem VM-Namen und die dritte Spalte dem Hostnamen, in dem das virtuelle System vorhanden ist. Die Parameter aus dieser Ausgabe werden in nachfolgenden Abschnitten verwendet.

Herunterfahren der CPAR-Anwendung

Schritt 1: Öffnen Sie einen Secure Shell (SSH)-Client, der mit dem Netzwerk verbunden ist, und stellen Sie eine Verbindung zur CPAR-Instanz her.

Es ist wichtig, nicht alle vier AAA-Instanzen an einem Standort gleichzeitig herunterzufahren, sondern dies einzeln zu tun.

Schritt 2: Führen Sie zum Herunterfahren der CPAR-Anwendung den folgenden Befehl aus:

/opt/CSCOar/bin/arserver stop

Die Meldung "Cisco Prime Access Registrar Server Agent heruntergefahren" wird angezeigt. muss erscheinen.

Hinweis: Wenn ein Benutzer eine CLI-Sitzung (Command Line Interface) geöffnet hat, funktioniert der Befehl arserver stop nicht, und diese Meldung wird angezeigt.

ERROR:    You cannot 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, führen Sie den Befehl aus, um diesen Prozess zu beenden:

kill -9 *process_id*

Wiederholen Sie anschließend Schritt 1.

Schritt 3: Führen Sie den folgenden Befehl aus, um zu überprüfen, ob die CPAR-Anwendung tatsächlich heruntergefahren wurde:

/opt/CSCOar/bin/arstatus

Diese Meldungen müssen angezeigt werden:

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 Horizon zugreifen, wird der Bildschirm angezeigt, wie in diesem Bild gezeigt.

Schritt 2: Navigieren Sie zu Projekt > Instanzen wie in diesem Bild gezeigt.

Wenn der Benutzer CPAR verwendet hat, 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 das virtuelle System herunterzufahren, navigieren Sie zu Actions > Shut Off Instance (Aktion abbrechen > Instanz abschalten), wie im Bild gezeigt, und bestätigen Sie Ihre Auswahl.

Schritt 4: Überprüfen Sie, ob die Instanz tatsächlich heruntergefahren wurde, indem Sie Status = Shutoff und Power State = Shut Down (Herunterfahren) wie in diesem Bild gezeigt überprüfen.

Mit diesem Schritt wird der CPAR-Abschaltvorgang beendet.

VM-Snapshot

Sobald die CPAR-VMs ausfallen, können die Snapshots parallel erstellt werden, da sie zu unabhängigen Berechnungen 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 und 1 Stunde für Instanzen, die ein Rohbild als Quelle verwenden)

1. Melden Sie sich bei der Horizon GUI von POD an.

2. Navigieren Sie nach der Anmeldung zum Abschnitt Projekt > Computing > Instanzen im oberen Menü, und suchen Sie die AAA-Instanzen, wie in diesem Bild gezeigt.

3. Klicken Sie auf Snapshot erstellen, um mit der Snapshot-Erstellung fortzufahren (diese muss für die entsprechende AAA-Instanz ausgeführt werden), wie in diesem Bild gezeigt.

4. Nachdem der Snapshot ausgeführt wurde, klicken Sie auf Images und überprüfen Sie, ob alle fertig gestellt sind und keine Probleme melden, wie in diesem Bild gezeigt.

5. Der nächste Schritt besteht darin, den Snapshot im QCOW2-Format herunterzuladen und an eine entfernte Einheit zu übertragen, falls das OSPD während dieses Prozesses verloren geht. Um dies zu erreichen, müssen Sie den Snapshot mithilfe des Befehls Glance image-list auf OSPD-Ebene identifizieren.

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

+--------------------------------------+---------------------------+

6. Sobald Sie den herunterzuladenden Snapshot (der in grün gekennzeichnet ist) identifizieren, können Sie ihn im QCOW2-Format mit dem Befehl glance image-download wie abgebildet herunterladen.

[root@elospd01 stack]# glance image-download 92dfe18c-df35-4aa9-8c52-9c663d3f839b --file /tmp/AAA-CPAR-LGNoct192017.qcow2 &

- Das & sendet den Prozess an den Hintergrund. Es dauert einige Zeit, um diese Aktion abzuschließen. Sobald sie abgeschlossen ist, kann sich das Bild im /tmp-Verzeichnis befinden.

- Wenn der Prozess an den Hintergrund gesendet wird und die Verbindung unterbrochen wird, wird der Vorgang ebenfalls beendet.

- Führen Sie den Befehl dissown -h aus, sodass der Prozess bei Verlust der SSH-Verbindung weiterhin auf dem OSPD ausgeführt wird und abgeschlossen wird.

7. Nach Abschluss des Download-Vorgangs muss ein Komprimierungsprozess ausgeführt werden, da dieser Snapshot aufgrund von Prozessen, Aufgaben und temporären Dateien, die vom Betriebssystem behandelt werden, mit ZEROES gefüllt werden kann. Der für die Dateikomprimierung verwendete Befehl ist virt-sparsify.

[root@elospd01 stack]# virt-sparsify AAA-CPAR-LGNoct192017.qcow2 AAA-CPAR-LGNoct192017_compressed.qcow2

Dieser Vorgang kann einige Zeit in Anspruch nehmen (etwa 10-15 Minuten). Nach Abschluss des Vorgangs muss die resultierende Datei wie im nächsten Schritt angegeben an eine externe Einheit übertragen werden.

Um dies zu erreichen, muss die Dateiintegrität überprüft werden. Führen Sie dazu den nächsten Befehl aus, und suchen Sie am Ende der Ausgabe nach dem Attribut "beschädigt".

[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 beim Verlust des OSPD zu vermeiden, muss der vor kurzem erstellte Snapshot im QCOW2-Format an eine externe Einheit übertragen werden. Bevor Sie die Dateiübertragung starten, müssen Sie überprüfen, ob das Ziel über genügend freien Speicherplatz verfügt, den Befehl df -kh ausführen, um den Speicherplatz zu überprüfen. Eine Empfehlung besteht darin, die Datei temporär mit dem SFTP sftp root@x.x.x.x" auf das OSPD-Dokument eines anderen Standorts zu übertragen, wobei x.x.x.x die IP-Adresse eines Remote-OSPD ist. Um die Übertragung zu beschleunigen, kann das Ziel an mehrere OSPDs gesendet werden. Auf die gleiche Weise können Sie den Befehl scp *name_of_the_file*.qcow2 root@ x.x.x:/tmp (wobei x.x.x.x die IP-Adresse eines Remote-OSPD ist) ausführen, um die Datei in ein anderes OSPD-Projekt zu übertragen.

1. Identifizieren Sie die im OSD-Compute-Knoten gehosteten VMs.

2. Identifizieren Sie die VMs, die auf dem Server gehostet werden.

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

| 46b4b9eb-a1a6-425d-b886-a0ba760e6114 | AAA-CPAR-testing-instance | pod2-stack-compute-4.localdomain |

Hinweis: In der hier gezeigten Ausgabe entspricht die erste Spalte dem Universally Unique IDentifier (UUID), die zweite Spalte dem VM-Namen und die dritte Spalte dem Hostnamen, in dem das virtuelle System vorhanden ist. Die Parameter aus dieser Ausgabe werden in nachfolgenden Abschnitten verwendet.

- Vergewissern Sie sich, dass CEPH über eine verfügbare Kapazität verfügt, damit ein einziger OSD-Server entfernt werden kann.

[heat-admin@pod2-stack-osd-compute-0 ~]$ sudo ceph df

GLOBAL:

SIZE       AVAIL      RAW USED     %RAW USED

13393G     11088G        2305G         17.21

POOLS:

NAME        ID     USED      %USED     MAX AVAIL     OBJECTS

rbd         0          0         0         3635G           0

metrics     1      3452M      0.09         3635G      219421

images      2       138G      3.67         3635G       43127

backups     3          0         0         3635G           0

volumes     4       139G      3.70         3635G       36581

vms         5       490G     11.89         3635G      126247

- Stellen Sie sicher, dass der Status ceph osd tree auf dem osd-Computing-Server aktiv ist.

[heat-admin@pod2-stack-osd-compute-0 ~]$ sudo ceph osd tree

ID WEIGHT   TYPE NAME                         UP/DOWN REWEIGHT PRIMARY-AFFINITY

-1 13.07996 root default

-2  4.35999     host pod2-stack-osd-compute-0

0  1.09000         osd.0                          up  1.00000          1.00000

3  1.09000         osd.3                          up  1.00000          1.00000

6  1.09000         osd.6                          up  1.00000          1.00000

9  1.09000         osd.9                          up  1.00000          1.00000

-3  4.35999     host pod2-stack-osd-compute-1

1  1.09000         osd.1                          up  1.00000          1.00000

4  1.09000         osd.4                          up  1.00000          1.00000

7  1.09000         osd.7                          up  1.00000          1.00000

10  1.09000         osd.10                         up  1.00000          1.00000

-4  4.35999     host pod2-stack-osd-compute-2

2  1.09000         osd.2                          up  1.00000          1.00000

5  1.09000         osd.5                          up  1.00000          1.00000

8  1.09000         osd.8                          up  1.00000          1.00000

11  1.09000         osd.11                         up  1.00000          1.00000

- CEPH-Prozesse sind auf dem osd-Computing-Server aktiv.

[heat-admin@pod2-stack-osd-compute-0 ~]$ systemctl list-units *ceph*

UNIT                             LOAD   ACTIVE SUB     DESCRIPTION

var-lib-ceph-osd-ceph\x2d0.mount loaded active mounted /var/lib/ceph/osd/ceph-0

var-lib-ceph-osd-ceph\x2d3.mount loaded active mounted /var/lib/ceph/osd/ceph-3

var-lib-ceph-osd-ceph\x2d6.mount loaded active mounted /var/lib/ceph/osd/ceph-6

var-lib-ceph-osd-ceph\x2d9.mount loaded active mounted /var/lib/ceph/osd/ceph-9

ceph-osd@0.service               loaded active running Ceph object storage daemon

ceph-osd@3.service               loaded active running Ceph object storage daemon

ceph-osd@6.service               loaded active running Ceph object storage daemon

ceph-osd@9.service               loaded active running Ceph object storage daemon

system-ceph\x2ddisk.slice        loaded active active  system-ceph\x2ddisk.slice

system-ceph\x2dosd.slice         loaded active active  system-ceph\x2dosd.slice

ceph-mon.target                  loaded active active  ceph target allowing to start/stop all ceph-mon@.service instances at once

ceph-osd.target                  loaded active active  ceph target allowing to start/stop all ceph-osd@.service instances at once

ceph-radosgw.target              loaded active active  ceph target allowing to start/stop all ceph-radosgw@.service instances at once

ceph.target                      loaded active active  ceph target allowing to start/stop all ceph*@.service instances at once

LOAD   = Reflects whether the unit definition was properly loaded.

ACTIVE = The high-level unit activation state, i.e. generalization of SUB.

SUB    = The low-level unit activation state, values depend on unit type.

14 loaded units listed. Pass --all to see loaded but inactive units, too.

To show all installed unit files use 'systemctl list-unit-files'.

- Deaktivieren und beenden Sie jede ceph-Instanz, entfernen Sie jede Instanz aus SOD, und heben Sie die Bereitstellung des Verzeichnisses auf. Wiederholen Sie diese Schritte für jede ceph-Instanz.

[heat-admin@pod2-stack-osd-compute-0  ~]# systemctl disable ceph-osd@0

[heat-admin@pod2-stack-osd-compute-0 ~]# systemctl stop ceph-osd@0

[heat-admin@pod2-stack-osd-compute-0 ~]# ceph osd out 0

- osd.0 markiert.

[heat-admin@pod2-stack-osd-compute-0 ~]# ceph osd crush remove osd.0

- Entferntes Element ID 0 Name 'osd.0' aus Crush Map

[heat-admin@pod2-stack-osd-compute-0  ~]# ceph auth del osd.0

- aktualisiert

[heat-admin@pod2-stack-osd-compute-0 ~]# ceph osd rm 0

- entfernt osd.0

[heat-admin@pod2-stack-osd-compute-0 ~]# umount /var/lib/ceph.osd/ceph-0

[heat-admin@pod2-stack-osd-compute-0 ~]# rm -rf /var/lib/ceph.osd/ceph-0

Oder:

- Für diese Aufgabe kann gleichzeitig das Skript Clean.sh verwendet werden.

[heat-admin@pod2-stack-osd-compute-0 ~]$ sudo ls /var/lib/ceph/osd

ceph-0  ceph-3  ceph-6  ceph-9

[heat-admin@pod2-stack-osd-compute-0 ~]$ /bin/sh clean.sh

[heat-admin@pod2-stack-osd-compute-0 ~]$ cat clean.sh

#!/bin/sh

set -x

CEPH=`sudo ls /var/lib/ceph/osd`

for c in $CEPH

do

i=`echo $c |cut -d'-' -f2`

sudo systemctl disable ceph-osd@$i || (echo "error rc:$?"; exit 1)

sleep 2

sudo systemctl stop ceph-osd@$i || (echo "error rc:$?"; exit 1)

sleep 2

sudo ceph osd out $i || (echo "error rc:$?"; exit 1)

sleep 2

sudo ceph osd crush remove osd.$i || (echo "error rc:$?"; exit 1)

sleep 2

sudo ceph auth del osd.$i || (echo "error rc:$?"; exit 1)

sleep 2

sudo ceph osd rm $i || (echo "error rc:$?"; exit 1)

sleep 2

sudo umount /var/lib/ceph/osd/$c || (echo "error rc:$?"; exit 1)

sleep 2

sudo rm -rf /var/lib/ceph/osd/$c || (echo "error rc:$?"; exit 1)

sleep 2

done

sudo ceph osd tree

Nachdem alle OSD-Prozesse migriert/gelöscht wurden, kann der Knoten aus der Overcloud entfernt werden.

Hinweis: Wenn CEPH entfernt wird, wechselt VNF HD RAID in den Zustand "Degraded" (Heruntergestuft), aber der Zugriff auf die Festplatte muss noch möglich sein.

Graceful Power Aus

- Ausschaltknoten

1. So schalten Sie die Instanz aus: nova stop <INSTANCE_NAME>

2. Sie können den Instanznamen mit dem Status-Shutoff sehen.

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

+--------------------------------------+---------------------------+---------+------------+-------------+------------------------------------------------------------------------------------------------------------+

- Knotenlöschung

Die in diesem Abschnitt beschriebenen Schritte sind unabhängig von den im Computing-Knoten gehosteten VMs häufig.

OSD-Computing-Knoten aus der Serviceliste löschen

- Löschen Sie den Computing-Service aus der Liste:
[stack@director ~]$ openstack compute service list |grep osd-compute

| 135 | nova-compute     | pod2-stack-osd-compute-1.localdomain | AZ-esc2  | enabled | up    | 2018-06-22T11:05:22.000000 |

| 150 | nova-compute     | pod2-stack-osd-compute-2.localdomain | nova     | enabled | up    | 2018-06-22T11:05:17.000000 |

| 153 | nova-compute     | pod2-stack-osd-compute-0.localdomain | AZ-esc1  | enabled | up    | 2018-06-22T11:05:25.000000 |

- Offenstack berechnen service delete <ID>

[stack@director ~]$ openstack compute service delete 150

Neutrale Agenten löschen

- Löschen Sie den alten zugeordneten Neutron-Agent und den offenen Switch-Agent für den Computer-Server:
[stack@director ~]$ openstack network agent list | grep osd-compute-0

| eaecff95-b163-4cde-a99d-90bd26682b22 | Open vSwitch agent | pod2-stack-osd-compute-0.localdomain | None              | True  | UP    | neutron-openvswitch-agent |

- openstack network agent delete <ID>

[stack@director ~]$ openstack network agent delete eaecff95-b163-4cde-a99d-90bd26682b22

Aus der Ironischen Datenbank löschen

- Löschen Sie einen Knoten aus der ironischen Datenbank, und überprüfen Sie ihn:

[root@director ~]#  nova list | grep osd-compute-0

| 6810c884-1cb9-4321-9a07-192443920f1f | pod2-stack-osd-compute-0 | ACTIVE | -          | Running     | ctlplane=192.200.0.109 |

[root@al03-pod2-ospd ~]$ nova delete 6810c884-1cb9-4321-9a07-192443920f1f

- nova show < Computing -Node> | grep Hypervisor

[root@director ~]# source stackrc

[root@director ~]#  nova show pod2-stack-osd-compute-0 | grep hypervisor

| OS-EXT-SRV-ATTR:hypervisor_hostname  | 05ceb513-e159-417d-a6d6-cbbcc4b167d7

- ironischer Node-Delete <ID>

[stack@director ~]$ ironic node-delete 05ceb513-e159-417d-a6d6-cbbcc4b167d7

[stack@director ~]$ ironic node-list

Der gelöschte Knoten darf jetzt nicht in der ironischen Knotenliste aufgeführt werden.

Löschen aus der Overcloud

- Erstellen Sie eine Skriptdatei mit dem Namen delete_node.sh, deren Inhalt wie gezeigt angezeigt wird. Stellen Sie sicher, dass die erwähnten Vorlagen mit den Vorlagen übereinstimmen, die im deploy.sh-Skript für die Stackbereitstellung verwendet wurden:

- 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

- Warten Sie, bis der OpenStack-Stack-Vorgang in den VOLLSTÄNDIGEN Zustand 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 |

+--------------------------------------+------------+-----------------+----------------------+----------------------+

Neuen Computing-Knoten installieren

- Die Schritte zur Installation eines neuen UCS C240 M4 Servers sowie die Schritte zur Ersteinrichtung können wie folgt aufgerufen werden:

Cisco UCS C240 M4 Serverinstallations- und Serviceleitfaden

- Nach der Installation des Servers legen Sie die Festplatten in die entsprechenden Steckplätze als alten Server ein.

- Melden Sie sich mit der CIMC IP-Adresse beim Server an.

- Führen Sie ein BIOS-Upgrade durch, wenn die Firmware nicht der zuvor verwendeten empfohlenen Version entspricht. Schritte für ein BIOS-Upgrade finden Sie hier:

BIOS-Upgrade-Leitfaden für Rackmount-Server der Cisco UCS C-Serie

- Überprüfen Sie den Status physischer Laufwerke. Es muss nicht konfiguriert sein Gut:

Navigieren Sie zu Storage > Cisco 12G SAS Modular Raid Controller (SLOT-HBA) > Physical Drive Info (Informationen zum physischen Laufwerk), wie in diesem Bild gezeigt.

- Erstellen Sie eine virtuelle Festplatte von den physischen Laufwerken mit RAID Level 1:

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), wie in diesem Bild gezeigt.

- Wählen Sie die VD aus, und konfigurieren Sie Set as Boot Drive (Als Startlaufwerk festlegen) wie im Bild gezeigt.

- IPMI over LAN aktivieren:

Navigieren Sie zu Admin > Communication Services > Communication Services (Verwaltung > Kommunikationsdienste > Kommunikationsdienste), wie im Bild gezeigt.

- Hyperthreading deaktivieren:

Navigieren Sie zu Compute > BIOS > Configure BIOS > Advanced > Processor Configuration wie im Bild gezeigt.

- Erstellen Sie ähnlich wie BOOTOS VD mit den physischen Laufwerken 1 und 2 vier weitere virtuelle Laufwerke:

JOURNAL > From physical drive number 3

OSD1 > From physical drive number 7

OSD2 > From physical drive number 8

OSD3 > From physical drive number 9

OSD4 > From physical drive number 10

- Am Ende müssen die physischen und virtuellen Laufwerke ähnlich wie in den Images dargestellt sein.

Hinweis: Das hier abgebildete Image und die in diesem Abschnitt beschriebenen Konfigurationsschritte beziehen sich auf die Firmware-Version 3.0(3e). Wenn Sie an anderen Versionen arbeiten, kann es zu geringfügigen Abweichungen kommen.

Neue OSD-Computing-Knoten zur Cloud hinzufügen

Die in diesem Abschnitt beschriebenen Schritte sind unabhängig von der vom Computing-Knoten gehosteten VMs üblich.

- Hinzufügen eines Compute-Servers mit einem anderen Index

Erstellen Sie eine Datei add_node.json, die nur die Details des neuen Computing-Servers enthält, der hinzugefügt werden soll. Stellen Sie sicher, dass die Indexnummer für den neuen Computing-Server noch nicht verwendet wurde. Erhöhen Sie in der Regel den nächsthöchsten Computing-Wert.

Beispiel: Das höchste vorherige System wurde bei osd-compute-17 erstellt und bei 2-vnf-Systemen osd-compute-18 erstellt.

Hinweis: Achten Sie auf das Json-Format.

[stack@director ~]$ cat add_node.json

{

"nodes":[

{

"mac":[

"<MAC_ADDRESS>"

],

"capabilities": "node:osd-compute-3,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"

}

]

}

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

- Führen Sie eine Knotenintrospektion mit der im vorherigen Schritt angegebenen 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       |

- Fügen Sie unter Osd Compute IPs unter custom-templates/layout.yml IP-Adressen hinzu. In diesem Fall fügen Sie durch Ersetzen von osd-compute-0 diese Adresse zum Ende der Liste für jeden Typ hinzu.

OsdComputeIPs:

internal_api:

- 11.120.0.43

- 11.120.0.44

- 11.120.0.45

- 11.120.0.43   <<< take osd-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

storage_mgmt:

- 11.119.0.43

- 11.119.0.44

- 11.119.0.45

- 11.119.0.43   << and here

- Führen Sie deploy.sh-Skript aus, das zuvor für die Bereitstellung des Stacks verwendet wurde, um den neuen Computing-Knoten dem 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

- Warten Sie, bis der Status des OpenStack-Stacks abgeschlossen ist:

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

+--------------------------------------+------------+-----------------+----------------------+----------------------+

- Überprüfen Sie, ob sich der neue Computing-Knoten im aktiven Zustand befindet:

[stack@director ~]$ source stackrc

[stack@director ~]$ nova list |grep osd-compute-3

| 0f2d88cd-d2b9-4f28-b2ca-13e305ad49ea | pod1-osd-compute-3    | ACTIVE | -          | Running     | ctlplane=192.200.0.117 |

[stack@director ~]$ source corerc

[stack@director ~]$ openstack hypervisor list |grep osd-compute-3

| 63 | pod1-osd-compute-3.localdomain    |

- Melden Sie sich beim neuen osd-Computing-Server an, und überprüfen Sie die ceph-Prozesse. Zunächst befindet sich der Status in HEALTH_WARN, wenn sich ceph erholt.

- [heat-admin@pod1-osd-compute-3 ~]$ sudo ceph -s

cluster eb2bb192-b1c9-11e6-9205-525400330666

health HEALTH_WARN

223 pgs backfill_wait

4 pgs backfilling

41 pgs degraded

227 pgs stuck unclean

41 pgs undersized

recovery 45229/1300136 objects degraded (3.479%)

recovery 525016/1300136 objects misplaced (40.382%)

monmap e1: 3 mons at {Pod1-controller-0=11.118.0.40:6789/0,Pod1-controller-1=11.118.0.41:6789/0,Pod1-controller-2=11.118.0.42:6789/0}

election epoch 58, quorum 0,1,2 Pod1-controller-0,Pod1-controller-1,Pod1-controller-2

osdmap e986: 12 osds: 12 up, 12 in; 225 remapped pgs

flags sortbitwise,require_jewel_osds

pgmap v781746: 704 pgs, 6 pools, 533 GB data, 344 kobjects

1553 GB used, 11840 GB / 13393 GB avail

45229/1300136 objects degraded (3.479%)

525016/1300136 objects misplaced (40.382%)

477 active+clean

186 active+remapped+wait_backfill

37 active+undersized+degraded+remapped+wait_backfill

4 active+undersized+degraded+remapped+backfilling

- Nach einer kurzen Zeit (20 Minuten) kehrt CEPH jedoch in den Zustand HEALTH_OK zurück.

[heat-admin@pod1-osd-compute-3 ~]$ sudo ceph -s

cluster eb2bb192-b1c9-11e6-9205-525400330666

health HEALTH_OK

monmap e1: 3 mons at {Pod1-controller-0=11.118.0.40:6789/0,Pod1-controller-1=11.118.0.41:6789/0,Pod1-controller-2=11.118.0.42:6789/0}

election epoch 58, quorum 0,1,2 Pod1-controller-0,Pod1-controller-1,Pod1-controller-2

osdmap e1398: 12 osds: 12 up, 12 in

flags sortbitwise,require_jewel_osds

pgmap v784311: 704 pgs, 6 pools, 533 GB data, 344 kobjects

1599 GB used, 11793 GB / 13393 GB avail

704 active+clean

client io 8168 kB/s wr, 0 op/s rd, 32 op/s wr

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

ID WEIGHT   TYPE NAME                         UP/DOWN REWEIGHT PRIMARY-AFFINITY

-1 13.07996 root default

-2        0     host pod1-osd-compute-0

-3  4.35999     host pod1-osd-compute-2

1  1.09000         osd.1                          up  1.00000          1.00000

4  1.09000         osd.4                          up  1.00000          1.00000

7  1.09000         osd.7                          up  1.00000          1.00000

10  1.09000         osd.10                         up  1.00000          1.00000

-4  4.35999     host pod1-osd-compute-1

2  1.09000         osd.2                          up  1.00000          1.00000

5  1.09000         osd.5                          up  1.00000          1.00000

8  1.09000         osd.8                          up  1.00000          1.00000

11  1.09000         osd.11                         up  1.00000          1.00000

-5  4.35999     host pod1-osd-compute-3

0  1.09000         osd.0                          up  1.00000          1.00000

3  1.09000         osd.3                          up  1.00000          1.00000

6  1.09000         osd.6                          up  1.00000          1.00000

9  1.09000         osd.9                          up  1.00000          1.00000

VMs wiederherstellen

Instanz mit Snapshot wiederherstellen

Es ist möglich, die vorherige Instanz mit dem in vorherigen Schritten ausgeführten Snapshot erneut bereitzustellen.

Schritt 1: (Optional) Wenn kein vorheriger VM-Snapshot verfügbar ist, verbinden Sie sich mit dem OSPD-Knoten, an den die Sicherung gesendet wurde, und SFTP mit der Sicherung zurück zum ursprünglichen OSPD-Knoten. Die Verwendung von sftp root@x.x.x.xwhere x.x.x.x ist die IP-Adresse des ursprünglichen OSPD. Speichern Sie die Snapshot-Datei im /tmp-Verzeichnis.

Schritt 2: Stellen Sie eine Verbindung zum OSPD-Knoten her, in dem die Instanz neu bereitgestellt wird.

Rufen Sie die Umgebungsvariablen mit dem folgenden Befehl auf:

# source /home/stack/pod1-stackrc-Core-CPAR

Schritt 3: Um den Snapshot als Bild zu verwenden, muss er in Horizon als solches hochgeladen werden. Führen Sie dazu den nächsten Befehl aus.

#glance image-create -- AAA-CPAR-Date-snapshot.qcow2 --container-format bare --disk-format qcow2 --name AAA-CPAR-Date-snapshot

Der Prozess ist im Horizont sichtbar, wie in diesem Bild gezeigt.

Schritt 4: Navigieren Sie in Horizon zu Projekt > Instanzen, und klicken Sie auf Lauch Instance (Launchinstanz), wie in diesem Bild gezeigt.

Schritt 5: Geben Sie den Instanznamen ein, und wählen Sie die Verfügbarkeitszone wie in diesem Bild gezeigt aus.

Schritt 6: Wählen Sie auf der Registerkarte Quelle das Bild aus, um die Instanz zu erstellen. Wählen Sie im Menü Boot Source (Startquelle auswählen) die Option image, eine Liste der Bilder wird angezeigt. Wählen Sie das Bild aus, das zuvor hochgeladen wurde, indem Sie auf das +-Zeichen klicken und wie in diesem Bild gezeigt.

Schritt 7: Wählen Sie auf der Registerkarte Flavor den AAA-Geschmack, indem Sie auf das + Zeichen klicken, wie in diesem Bild gezeigt.

Schritt 8: Navigieren Sie schließlich zur Registerkarte Netzwerk, und wählen Sie die Netzwerke aus, die die Instanz benötigt, indem Sie auf das + Zeichen klicken. Wählen Sie in diesem Fall durchmesser-soutable1, radius-routing1 und tb1-mgmt aus, wie in diesem Bild gezeigt.

Schritt 9: Klicken Sie abschließend auf Instanz starten, um sie zu erstellen. Der Fortschritt kann in Horizon überwacht werden, wie in diesem Bild gezeigt.

Nach einigen Minuten wird die Instanz vollständig bereitgestellt und einsatzbereit.

Floating-IP-Adresse erstellen und zuweisen

Eine Floating-IP-Adresse ist eine routbare Adresse, d. h. sie ist von der Außenseite der Ultra M/OpenStack-Architektur aus erreichbar und kann mit anderen Knoten aus dem Netzwerk kommunizieren.

Schritt 1: Navigieren Sie im oberen Horizon-Menü zu Admin > Floating IPs (Admin > Floating-IPs).

Schritt 2: Klicken Sie auf Projekt IP zuweisen.

Schritt 3: Wählen Sie im Fenster Zuweisen von Floating-IP den Pool aus, aus dem die neue unverankerte IP gehört, das Projekt, dem sie zugewiesen werden soll, und die neue Floating-IP-Adresse selbst.

Beispiel:

Schritt 4: Klicken Sie auf Floating-IP zuweisen.

Schritt 5: Navigieren Sie im oberen Menü Horizont zu Projekt > Instanzen.

Schritt 6: Klicken Sie in der Spalte Aktion auf den Pfeil, der in der Schaltfläche Snapshot erstellen nach unten zeigt, sodass ein Menü angezeigt werden muss. Wählen Sie die Option Zuordnen - Floating-IP aus.

Schritt 7: Wählen Sie die entsprechende unverankerte IP-Adresse aus, die im Feld IP-Adresse verwendet werden soll, und wählen Sie die entsprechende Management-Schnittstelle (eth0) aus der neuen Instanz aus, der diese unverankerte IP im zu verknüpfenden Port zugewiesen wird. Ein Beispiel für dieses Verfahren ist das nächste Bild.

Schritt 8: Klicken Sie abschließend auf Zuordnen.

SSH aktivieren

Schritt 1: Navigieren Sie im oberen Menü Horizont zu Projekt > Instanzen.

Schritt 2: Klicken Sie auf den Namen der im Abschnitt Neue Instanz starten erstellten Instanz/VM.

Schritt 3: Klicken Sie auf Konsole. Dadurch wird die CLI des virtuellen Systems angezeigt.

Schritt 4: Geben Sie nach der Anzeige der CLI die entsprechenden Anmeldeinformationen ein:

Benutzername: Wurzel

Kennwort: cisco123 wie in diesem Bild gezeigt.

Schritt 5: Führen Sie in der CLI den Befehl vi /etc/ssh/sshd_config aus, um die SSH-Konfiguration zu bearbeiten.

Schritt 6: Wenn die SSH-Konfigurationsdatei geöffnet ist, drücken Sie I, um die Datei zu bearbeiten. Suchen Sie dann nach dem Abschnitt, der hier angezeigt wird, und ändern Sie die erste Zeile von PasswordAuthentication no in PasswordAuthentication yes.

Schritt 7: Drücken Sie ESC und geben Sie :wq! um die Dateiänderungen sshd_config zu speichern.

Schritt 8: Führen Sie den Befehl service sshd restart aus.

Schritt 9: Um die SSH-Konfigurationsänderungen ordnungsgemäß zu testen, öffnen Sie jeden SSH-Client, und versuchen Sie, eine sichere Remote-Verbindung mithilfe der Floating-IP herzustellen, die der Instanz (d. h. 10.145.0.249) und dem Benutzer-Root zugewiesen wurde.

SSH-Sitzung einrichten

Schritt 1: Öffnen Sie eine SSH-Sitzung mit der IP-Adresse des entsprechenden VM/Servers, auf dem die Anwendung installiert ist, wie in diesem Bild gezeigt.

CPAR-Instanzstart

Befolgen Sie diese Schritte, sobald die Aktivität abgeschlossen ist und die CPAR-Services auf der heruntergefahrenen Website wiederhergestellt werden können.

Schritt 1: Melden Sie sich wieder bei Horizon an, navigieren Sie zu Projekt > Instanz > Instanz starten.

Schritt 2: Überprüfen Sie, ob der Status der Instanz aktiv ist und der Betriebszustand ausgeführt wird, wie in diesem Bild gezeigt.

Statusprüfung nach 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 Administratorberechtigungen ein. Stellen Sie sicher, dass CPAr Health 10 von 10 und die CPAR-CLI-Option für das Beenden ist.

[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: Führen Sie den Befehl netstat aus | grep-Durchmesser und überprüfen, ob alle DRA-Verbindungen hergestellt sind.

Die hier erwähnte Ausgabe ist für eine Umgebung vorgesehen, in der Durchmesser-Links erwartet werden. Wenn weniger Links angezeigt werden, stellt dies eine Trennung von 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 das TPS-Protokoll Anforderungen anzeigt, die von CPAR verarbeitet werden. Die hervorgehobenen Werte stellen TPS dar. Sie müssen genau auf diese Werte achten.

Der TPS-Wert darf 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 in name_radius_1_log nach "error"- oder "alarm"-Meldungen.

[root@aaa02 logs]# grep -E "error|alarm" name_radius_1_log

Schritt 6: Führen Sie den folgenden Befehl aus, um die Speichergröße zu überprüfen, die der CPAR-Prozess verwendet:

top | 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 muss kleiner als 7 GB sein. Dies ist der maximal zulässige Wert auf Anwendungsebene.