PowerFlex – Probleme mit der Schreibleistung

Szenario
 - Dieses Problem tritt auf, nachdem eine Netzwerkwartung auf TORs (Top of Rack Switches) durchgeführt wurde, in der Regel ein Neustart der Switches.

 - Die SDS-Knoten verwenden eine LACP-Bündelung für die Datennetzwerke.

 - Nur die SDS-Nodes, die die Switches verwenden, auf denen die Wartung durchgeführt wurde, sind betroffen.

 - Die Schreibleistung kann für einen bestimmten Storage Pool/PD bis zu mehreren hundert Millisekunden betragen.

 - Die Leseleistung desselben SDS-Satzes ist normal.

 - Das "NET_LONG_RCV_GRP_PROCESS" im diag_counters.txt zeigt an, dass die Werte schnell steigen, während die zuletzt erhöhte Zeit niedrig bleibt. 

Beispiel:

 Comp     :: Counter                          ::  Value               :: ExtData               :: Last Counted(Ms)    
NET      :: NET_LONG_RCV_GRP_PROCESS         ::  3756453             :: 0xffffffff            :: 3120                
NET      :: NET_LONG_RCV_GRP_PROCESS         ::  3825395             :: 0xffffffff            :: 960                 
NET      :: NET_LONG_RCV_GRP_PROCESS         ::  3705906             :: 0xffffffff            :: 1320                
NET      :: NET_LONG_RCV_GRP_PROCESS         ::  4094919             :: 0xffffffff            :: 1230                
NET      :: NET_LONG_RCV_GRP_PROCESS         ::  3954725             :: 0xffffffff            :: 1390                
NET      :: NET_LONG_RCV_GRP_PROCESS         ::  3594178             :: 0xffffffff            :: 420                 
NET      :: NET_LONG_RCV_GRP_PROCESS         ::  3702403             :: 0xffffffff            :: 680                 
NET      :: NET_LONG_RCV_GRP_PROCESS         ::  3830299             :: 0xffffffff            :: 510                 
NET      :: NET_LONG_RCV_GRP_PROCESS         ::  3491713             :: 0xffffffff            :: 330                 
NET      :: NET_LONG_RCV_GRP_PROCESS         ::  4155343             :: 0xffffffff            :: 690  

In diesem Beispiel ist der Wert in der dritten Spalte high (und nimmt zu, wenn Sie live zuschauen). Die fünfte Spalte zeigt den letzten Zeitpunkt, an dem er aufgetreten ist, was für einen Großteil der SDSs weniger als eine Sekunde beträgt. 
In einem fehlerfreien PowerFlex-System zählt die dritte Spalte nicht aufwärts, sondern die fünfte Spalte hoch, da die zuletzt aufgetretene Zeit im Laufe der Zeit zunimmt. 

Um die Zähler live zu verfolgen, können die folgenden Befehle ausgeführt werden:

#Set die Variable für die SDSs in der betroffenen Schutzdomain. Geben Sie hier den korrekten PD-Namen ein.

 pd=<PD_NAME>

#Set die Variable für die Anzahl der SDSs in der Schutzdomain. Führen Sie dies so aus, wie es ist.

 num=`scli --query_protection_domain --protection_domain_name $pd |grep Protection |awk '{print $16}'`

#login, um den letzten Befehl auszuführen.

 scli --login --username admin

#Watch den korrekten Zähler aus dem Befehl "query_diag_counters" für jeden SDS aus.

 watch -d -n 1 "for x in \$(scli --query_all_sds | grep -A $num $pd | grep ID | awk '{print \$5}'); do echo \$x; scli --query_diag_counters | grep -A30 \$x | grep -Em1 '\$x|NET_LONG_RCV_GRP_PROCESS'; done"

In einem gesunden System können Sie davon ausgehen, dass die fünfte Spalte im Laufe der Zeit regelmäßig hochzählt und die dritte Spalte statisch ist. Wenn die Zeit der fünften Spalte niedrig bleibt und die dritte Spalte hochzählt, ist dies ein Symptom des Problems. 

Aufprall
Die Schreibleistung ist für Clients schlecht.

Die oben nachverfolgte "NET_LONG_RCV_GRP_PROCESS" weist darauf hin, dass das Senden von TCP-Daten an einen Remote-SDS länger als 1 s gedauert hat.

Diese Verzögerung kann aufgrund eines kleinen anfänglichen TCP-Überlastungsfensters nach der Netzwerkwartung auftreten und wenn der Parameter für OOO-Pakete (Out of Order) im Betriebssystem nicht entsprechend festgelegt ist. Dies führt dazu, dass die SDS-zu-SDS-Sockets nicht effektiv kommunizieren können, was zu mehreren erneuten TCP-Übertragungen und einer reduzierten Segmentgröße führt. Dies führt zu einer höheren Latenz bei Schreibvorgängen, da sich dies nur auf die SDS-zu-SDS-Sockel auswirkt. 

Die Leselatenz bleibt hiervon unberührt, da die SDCs (Clients) mit einem einzigen SDS pro Lese-IO-Anforderung kommunizieren und nicht auf die SDS-zu-SDS-TCP-Kommunikation angewiesen sind.

Um das Problem sofort zu umgehen, starten Sie den SDS-Service auf jedem betroffenen Node neu. Verwenden Sie den Wartungsmodus, wenn Sie den SDS-Prozess neu starten. Ein "pkill sds" ist ausreichend, sobald der Node gewartet wird.  

Gehen Sie wie folgt vor, um zu verhindern, dass das Problem in Zukunft auftritt:

1. Wenden Sie die sysctl-Einstellungen an, die in diesem öffentlichen Wissensdatenbank-Artikel erläutert werden:
   Storage Data Server-Nodes enthalten möglicherweise nicht die richtigen Systemtuningparameter, was zu Performanceproblemen führen kann
    
2. Wenn Sie RHEL/CentOS 7 verwenden, aktualisieren Sie die Betriebssystem-Kernel-Version auf den SDS-Nodes auf "3.10.0-1160.66.1" oder höher

Betroffene Version

PowerFlex 3.x

Behoben in Version

RCM-Version 3.6.3.2 oder höher
, IC-Version 38.363.02 oder höher