PowerFlexの書き込みパフォーマンスの問題

シナリオ
- この問題は、トップ オブ ラック スイッチ (TOR) のネットワーク メンテナンス (通常はスイッチの再起動) が実行された後に発生します。

 - SDSノードは、データ ネットワークにLACPボンドを使用しています。

 - メンテナンスが実行されたスイッチを使用しているSDSノードのみが影響を受けます。

 - 書き込みパフォーマンスは、特定のストレージプール/PDで最大数百ミリ秒になる可能性があります。

 - 同じSDSセットの読み取りパフォーマンスは正常です。

 - diag_counters.txtの「NET_LONG_RCV_GRP_PROCESS」は、値が急速に上昇していることを示していますが、最後に増加した時間は低いままです。

例：

 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  

この例では、3 番目の列の値が高くなります (ライブ視聴の場合は増加します)。5番目の列は、最後に発生した時刻を示します。これは、SDSの大部分で1秒未満です。
正常なPowerFlexシステムでは、最後に発生した時間が時間の経過とともに長くなるため、3列目はカウントアップせず、5列目はカウントアップします。 

カウンターをライブで監視するには、次のコマンドを実行します。

影響を受ける保護ドメイン内のSDSの変数 #Set ます。ここに適切なPD名を入力します。

 pd=<PD_NAME>

保護ドメイン内のSDSの数の変数 #Set。これをそのまま実行します。

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

最後のコマンドを機能させる #login。

 scli --login --username admin

各SDSの「query_diag_counters」コマンドから正しいカウンター #Watch ます。

 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"

正常なシステムでは、時間の経過に伴って 5 番目の列は定期的にカウントアップされ、3 番目の列は静的であると予想されます。5 番目の列の時間が短いままで、3 番目の列がカウントアップしている場合、これは問題の兆候です。 

想定される影響
クライアントの書き込みパフォーマンスが悪い。

上記で追跡されている「NET_LONG_RCV_GRP_PROCESS」は、リモートSDSへのTCPデータの送信が完了するまでに1秒以上かかったことを示しています。

この遅延は、ネットワーク メンテナンス後の初期TCP輻輳ウィンドウが小さく、オペレーティング システムでOOO(順不同)パケット パラメーターが適切に設定されていないために発生する可能性があります。これにより、SDSからSDSソケットへの効果的な通信ができなくなり、TCPの再送信が複数回発生し、セグメント サイズが縮小します。これは、SDSからSDSソケットにのみ影響するため、書き込みのレイテンシーが長くなります。 

SDC(クライアント)は読み取りIO要求ごとに単一のSDSと通信し、SDSからSDS TCPへの通信に依存しないため、読み取りレイテンシーは影響を受けません。

即時の回避策として、影響を受ける各ノードでSDSサービスを再起動します。SDSプロセスを再開する場合は、メンテナンス モードを使用します。ノードがメンテナンス中になると、「pkill sds」で十分です。  

この問題が今後発生しないようにするには、次の手順を実行します。

1. この公開KB記事で説明されているsysctl設定を適用します。
   Storage Data Serverノードに正しいシステム チューニング パラメーターが含まれておらず、パフォーマンスの問題が発生する可能性があります
    
2. RHEL/CentOS 7を使用している場合は、SDSノードのOSカーネル バージョンを「3.10.0-1160.66.1」以降にアップデートします

影響を受けるバージョン

PowerFlex 3.x

修正バージョン

RCMバージョン3.6.3.2以降
ICバージョン38.363.02以降