Ceph Outbreak Impact Analysis für StarOS VNF

Einführung

In diesem Dokument wird beschrieben, wie sich StarOS VNF, das auf dem Cisco Virtualized Infrastructure Manager (VIM) ausgeführt wird, bei einer Beeinträchtigung des Ceph-Speicherservice auswirkt und wie die Auswirkungen verringert werden können. Es wird davon ausgegangen, dass Cisco VIM als Infrastruktur verwendet wird. Dieselbe Theorie kann jedoch auf jede OpenStack-Umgebung angewendet werden.

Voraussetzung

Anforderungen

Cisco empfiehlt, über Kenntnisse in folgenden Bereichen zu verfügen:

• Cisco StarOS
• Cisco VIM
• OpenStack
• Ceph

Verwendete Komponenten

Die Informationen in diesem Dokument basieren auf den folgenden Software- und Hardwareversionen:

• StarOS: 21.16.c9
• Cisco VIM: 3.2.2 (OpenStack Queens)

Die Informationen in diesem Dokument wurden von den Geräten in einer bestimmten Laborumgebung erstellt. Alle in diesem Dokument verwendeten Geräte haben mit einer leeren (Standard-)Konfiguration begonnen. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die potenziellen Auswirkungen eines Befehls verstehen.

Abkürzungen

Cisco VIM	Cisco Virtualized Infrastructure Manager
VNF	Virtuelle Netzwerkfunktion
Ceph OSD	Ceph Object Storage-Daemon
StarOS	Betriebssystem für die Cisco Mobile Packet Core-Lösung

Ceph in Cisco VIM

Dieses Bild entnimmt man dem Cisco VIM-Administratorhandbuch. Cisco VIM verwendet Ceph als Storage-Back-End.

Ceph unterstützt Block- und Objektspeicher und dient daher zum Speichern von VM-Images und -Volumes, die an VMs angeschlossen werden können. Mehrere OpenStack-Dienste, die vom Storage-Backend abhängen, sind:

• Glance (OpenStack-Image-Service) - Verwendet Ceph zum Speichern von Bildern.
• Cinder (OpenStack Storage-Service) - Verwendet Ceph, um Volumes zu erstellen, die an VMs angeschlossen werden können.
• Nova (OpenStack Computing Service) - Verwendet Ceph, um eine Verbindung zu den von Cinder erstellten Volumes herzustellen.

In vielen Fällen wird in Ceph ein Volume für /flash und /hd-raid für StarOS VNF erstellt, wie im Beispiel hier gezeigt.

openstack volume create --image `glance image-list | grep up-image | awk '{print $2}'` --size 16 --type LUKS up1-flash-boot
openstack volume create --size 20 --type LUKS up1-hd-raid

Grundlagen des Überwachungsmechanismus in Ceph

Im Ceph-Dokument wird die Überwachung wie folgt erläutert:
Jeder Ceph OSD-Daemon überprüft den Heartbeat anderer Ceph OSD-Daemons in unregelmäßigen Abständen von weniger als alle 6 Sekunden. Wenn ein benachbarter Ceph OSD-Daemon innerhalb von 20 Sekunden keinen Herzschlag anzeigt, kann der Ceph OSD-Daemon den benachbarten Ceph OSD-Daemon untersuchen und an einen Ceph-Monitor zurückmelden, der die Ceph Cluster Map aktualisiert. Standardmäßig müssen zwei Ceph OSD-Daemons von verschiedenen Hosts den Ceph Monitors mitteilen, dass ein anderer Ceph OSD-Daemon ausgefallen ist, bevor die Ceph Monitors bestätigen, dass der gemeldete Ceph OSD-Daemon ausgefallen ist.

Im Allgemeinen dauert es also etwa 20 Sekunden, bis das OSD ausgefallen ist und die Ceph-Cluster-Karte aktualisiert wird, erst nachdem dieses VNF ein neues OSD verwenden kann. Während dieser Zeit wird der Datenträger blockiert.

Auswirkungen der Sperre von E/A auf StarOS VNF

Wenn die Datenträger-E/A länger als 120 Sekunden blockiert ist, startet StarOS VNF neu. Es gibt eine spezifische Prüfung für xfssyncd/md0- und xfs_db-Prozesse, die sich auf Festplatten-E/A und StarOS beziehen, die absichtlich neu gestartet werden, wenn ein festgeklemmter Prozess mehr als 120 Sekunden erkannt wird.

StarOS-Debug-Konsolenprotokoll:

[ 1080.859817] INFO: task xfssyncd/md0:25787 blocked for more than 120 seconds.
[ 1080.862844] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 1080.866184] xfssyncd/md0 D ffff880c036a8290 0 25787 2 0x00000000
[ 1080.869321] ffff880aacf87d30 0000000000000046 0000000100000a9a ffff880a00000000
[ 1080.872665] ffff880aacf87fd8 ffff880c036a8000 ffff880aacf87fd8 ffff880aacf87fd8
[ 1080.876100] ffff880c036a8298 ffff880aacf87fd8 ffff880c0f2f3980 ffff880c036a8000
[ 1080.879443] Call Trace:
[ 1080.880526] [<ffffffff8123d62e>] ? xfs_trans_commit_iclog+0x28e/0x380
[ 1080.883288] [<ffffffff810297c9>] ? default_spin_lock_flags+0x9/0x10
[ 1080.886050] [<ffffffff8157fd7d>] ? _raw_spin_lock_irqsave+0x4d/0x60
[ 1080.888748] [<ffffffff812301b3>] _xfs_log_force_lsn+0x173/0x2f0
[ 1080.891375] [<ffffffff8104bae0>] ? default_wake_function+0x0/0x20
[ 1080.894010] [<ffffffff8123dc15>] _xfs_trans_commit+0x2a5/0x2b0
[ 1080.896588] [<ffffffff8121ff64>] xfs_fs_log_dummy+0x64/0x90
[ 1080.899079] [<ffffffff81253cf1>] xfs_sync_worker+0x81/0x90
[ 1080.901446] [<ffffffff81252871>] xfssyncd+0x141/0x1e0
[ 1080.903670] [<ffffffff81252730>] ? xfssyncd+0x0/0x1e0
[ 1080.905871] [<ffffffff81071d5c>] kthread+0x8c/0xa0
[ 1080.908815] [<ffffffff81003364>] kernel_thread_helper+0x4/0x10
[ 1080.911343] [<ffffffff81580805>] ? restore_args+0x0/0x30
[ 1080.913668] [<ffffffff81071cd0>] ? kthread+0x0/0xa0
[ 1080.915808] [<ffffffff81003360>] ? kernel_thread_helper+0x0/0x10
[ 1080.918411] **** xfssyncd/md0 stuck, resetting card

Es ist jedoch nicht auf den 120-Sekunden-Timer beschränkt. Wenn die Festplatten-E/A für eine Weile blockiert wird, selbst weniger als 120 Sekunden, kann VNF aus verschiedenen Gründen neu starten. Die Ausgabe hier ist ein Beispiel, das einen Neustart aufgrund des E/A-Problems der Festplatte, manchmal einen fortlaufenden StarOS-Aufgabenabsturz usw. anzeigt. Dies hängt vom Zeitpunkt der I/O-Vorgänge der aktiven Festplatte und vom Speicherproblem ab.

[ 2153.370758] Hangcheck: hangcheck value past margin!
[ 2153.396850] ata1.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
[ 2153.396853] ata1.01: failed command: WRITE DMA EXT
--- skip ---
SYSLINUX 3.53 0x5d037742 EBIOS Copyright (C) 1994-2007 H. Peter Anvin

Grundsätzlich kann eine lange blockierende E/A als ein kritisches Problem für StarOS VNF betrachtet werden und sollte so weit wie möglich minimiert werden.

E/A-Szenarien mit langer Sperre

Basierend auf den Forschungsergebnissen aus mehreren Kundenbereitstellungen und Labortests wurden zwei Hauptszenarien identifiziert, die in Ceph eine lange blockierende E/A-Verbindung verursachen können.

Laggy Timer-Mechanismus

Es gibt einen Heartbeat-Mechanismus zwischen OSDs, um OSD nicht zu erkennen. Basierend auf dem Standardwert osd_heartbeat_grace (standardmäßig 20 Sekunden) wird OSD als fehlerhaft erkannt.
Es gibt einen Mechanismus für einen verzögerten Timer, bei dem im OSD-Status Fluktuationen oder Flapping auftreten, wird der Grace Timer automatisch angepasst (wird länger). Dies kann den Wert osd_heartbeat_grace größer machen.

In der normalen Situation beträgt die Heartbeat-Graction 20 Sekunden

2019-01-09 16:58:01.715155 mon.ceph-XXXXX [INF] osd.2 failed (root=default,host=XXXXX) (2 reporters from different host after 20.000047 >= grace 20.000000)

Nach mehreren Netzwerk-Flaps eines Speicherknotens wird dieser jedoch zu einem größeren Wert.

2019-01-10 16:44:15.140433 mon.ceph-XXXXX [INF] osd.2 failed (root=default,host=XXXXX) (2 reporters from different host after 256.588099 >= grace 255.682576)

Im obigen Beispiel dauert es 256 Sekunden, bis das OSD ausgefallen ist.

Hardwarefehler der RAID-Karte

Ceph kann eventuell nicht rechtzeitig einen Hardwarefehler der RAID-Karte erkennen. Der Ausfall einer RAID-Karte endet mit einer Art OSD-Hängesituation. In diesem Fall wird das OSD nach einigen Minuten nicht erkannt, was ausreicht, um StarOS VNF-Neustarts vorzunehmen.

Wenn die RAID-Karte hängen bleibt, nehmen einige CPU-Kerne den Status "Way" (Nicht verfügbar) zu 100 % ein.

%Cpu20 : 2.6 us, 7.9 sy, 0.0 ni, 0.0 id, 89.4 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu21 : 0.0 us, 0.3 sy, 0.0 ni, 99.7 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu22 : 31.3 us, 5.1 sy, 0.0 ni, 63.6 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu23 : 0.0 us, 0.0 sy, 0.0 ni, 28.1 id, 71.9 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu24 : 0.0 us, 0.0 sy, 0.0 ni, 0.0 id,100.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu25 : 0.0 us, 0.0 sy, 0.0 ni, 0.0 id,100.0 wa, 0.0 hi, 0.0 si, 0.0 st

Außerdem werden alle CPU-Kerne allmählich aufgebraucht, und das OSD wird mit einer gewissen Zeitlücke ebenfalls allmählich heruntergefahren.

2019-01-01 17:08:05.267629 mon.ceph-XXXXX [INF] Marking osd.2 out (has been down for 602 seconds)
2019-01-01 17:09:25.296955 mon.ceph-XXXXX [INF] Marking osd.4 out (has been down for 603 seconds)
2019-01-01 17:11:10.351131 mon.ceph-XXXXX [INF] Marking osd.7 out (has been down for 604 seconds)
2019-01-01 17:16:40.426927 mon.ceph-XXXXX [INF] Marking osd.10 out (has been down for 603 seconds)

Gleichzeitig werden langsame Anfragen in ceph.log erkannt.

2019-01-01 16:57:26.743372 mon.XXXXX [WRN] Health check failed: 1 slow requests are blocked > 32 sec. Implicated osds 2 (REQUEST_SLOW)
2019-01-01 16:57:35.129229 mon.XXXXX [WRN] Health check update: 3 slow requests are blocked > 32 sec. Implicated osds 2,7,10 (REQUEST_SLOW)
2019-01-01 16:57:38.055976 osd.7 osd.7 [WRN] 1 slow requests, 1 included below; oldest blocked for > 30.216236 secs
2019-01-01 16:57:39.048591 osd.2 osd.2 [WRN] 1 slow requests, 1 included below; oldest blocked for > 30.635122 secs
-----skip-----
2019-01-01 17:06:22.124978 osd.7 osd.7 [WRN] 78 slow requests, 1 included below; oldest blocked for > 554.285311 secs
2019-01-01 17:06:25.114453 osd.4 osd.4 [WRN] 19 slow requests, 1 included below; oldest blocked for > 546.221508 secs
2019-01-01 17:06:26.125459 osd.7 osd.7 [WRN] 78 slow requests, 1 included below; oldest blocked for > 558.285789 secs
2019-01-01 17:06:27.125582 osd.7 osd.7 [WRN] 78 slow requests, 1 included below; oldest blocked for > 559.285915 secs

Das Diagramm hier zeigt, wie lange E/A-Anfragen mit einer Zeitleiste blockiert werden. Das Diagramm wird erstellt, indem die langsamen Anforderungsprotokolle in ceph.log gezeichnet werden. Es zeigt, dass die Blockierungszeit mit der Zeit länger wird. 

Wie lässt sich die Wirkung minimieren?

Von Ceph-Speicher auf lokalen Datenträger verschieben

Die einfachste Möglichkeit, die Auswirkungen zu mindern, besteht darin, vom Ceph-Speicher auf eine lokale Festplatte zu wechseln. StarOS verwendet 2 Festplatten, /flash und /hd-raid, es ist möglich, nur /flash auf die lokale Festplatte zu verschieben, wodurch StarOS VNF robuster für die Ceph-Probleme wird. Die negative Seite bei der Verwendung von Shared Storage (z. B. Ceph) besteht darin, dass alle VNF, die diesen Speicher verwenden, bei Auftreten eines Problems gleichzeitig betroffen sind. Durch die Verwendung der lokalen Festplatte können die Auswirkungen von Speicherproblemen auf VNF minimiert werden, die nur auf dem betroffenen Knoten ausgeführt werden. Die im vorherigen Abschnitt genannten Szenarien gelten nur für Ceph, sodass sie nicht für lokale Datenträger gelten. Die Kehrseite der lokalen Festplatte ist jedoch, dass der Inhalt der Festplatte, wie z. B. StarOS-Image, Konfiguration, Kerndatei und Rechnungsdatensatz, nicht beibehalten werden kann, wenn die VM neu bereitgestellt wird. Dies kann sich auch auf den automatischen VNF-Heilmechanismus auswirken.

CPH-Konfigurationseinstellung

Aus der Sicht von StarOS VNF werden die folgenden neuen Ceph-Parameter empfohlen, um die oben erwähnte Blockierungs-E/A-Zeit zu minimieren.

<Standardeinstellungen>

"mon_osd_adjust_heartbeat_grace": "true",
"osd_client_watch_timeout": "30",
"osd_max_markdown_count": "5",
"osd_heartbeat_grace": "20",

<neue Einstellungen>

"mon_osd_adjust_heartbeat_grace": "false",
"osd_client_watch_timeout": "10",
"osd_max_markdown_count": "1",
"osd_heartbeat_grace": "10",

Es besteht aus:

• Der Mechanismus für den verzögerten Timer ist deaktiviert, keine automatische Anpassung.
• Die Taktzeit verkürzt sich.
• Das OSD wird sofort als "down" markiert (standardmäßig 5 Mal in den letzten 600 Sekunden).

Die neuen Parameter werden in einer Übung getestet, die Erkennungszeit für das Herunterfahren des OSD wird auf ca. 10 Sekunden reduziert. Ursprünglich waren es bei der Standardkonfiguration von Ceph etwa 30 Sekunden.

Hardwareproblem der RAID-Karte überwachen

Im Hardwareszenario für RAID-Karten kann es immer noch schwierig sein, das Problem zeitnah zu erkennen, da es zu einer Situation kommt, in der das OSD zeitweise funktioniert, während die E/A blockiert wird. Dafür gibt es keine einzige Lösung. Es wird jedoch empfohlen, das Server-Hardwareprotokoll auf Fehler der RAID-Karte zu überwachen oder das langsame Anforderungsprotokoll in ceph.log von einem Skript zu überwachen und Maßnahmen zu ergreifen, um das betroffene OSD proaktiv herunterzufahren.

CEPH_OSD_RESEREVED_PCORES-Tuning

Dies bezieht sich nicht auf die genannten Szenarien, aber wenn es aufgrund eines starken E/A-Betriebs zu einem Problem mit der Ceph-Leistung kommt, kann eine Erhöhung des CEPH_OSD_RESEREVED_PCORES-Werts die Ceph-E/A-Leistung verbessern. Standardmäßig ist CEPH_OSD_RESEREVED_PCORES auf Cisco VIM als 2 konfiguriert und kann erhöht werden.