StorageXへの移行でSecDがフラッディングされる
すべてのとおり
環境
- ONTAP 9
- StorageX
- データ移行
回答
サードパーティのマルチスレッド移行ツールを使用したストレージ移行では、原因 SecDのボトルネックが発生する可能性があります。移行が行われているときに、これ自体がクライアント認証パフォーマンスの問題 となることがよくあります。ノードの認証に関連する作業にも影響する可能性があります。
このボトルネックの証拠は、次のエラーに見られます。
Secd.log
SecDがキューに入り、リクエストが長期間キューに留まることがあります。
[kern_secd:info:10816] debug: Worker Thread 34641252096 processing RPC 153:secd_rpc_auth_get_creds with request ID:6605 which sat in the queue for 23 seconds. { in run() at src/server/secd_rpc_server.cpp:2067 }
これにより、23秒のタイムアウトが原因でRPC要求が失敗する可能性があります。
[kern_secd:info:5895] .------------------------------------------------------------------------------.
[kern_secd:info:5895] | RPC TOOK TOO LONG: |
[kern_secd:info:5895] | RPC used 24 seconds (max is 23) |
[kern_secd:info:5895] | and likely caused the client to timeout |
[kern_secd:info:5895] .------------------------------------------------------------------------------.
最終的に、SecD RPCメモリ割り当てが80%に達した場合、次のメッセージの記録を開始します。
secd.log
[kern_secd:info:10816] [SECD MASTER THREAD] SecD RPC Server: Too many outstanding Generic RPC requests: sending System Error to RPC 153:secd_rpc_auth_get_creds Request ID:65535.
ems.log
[secd: secd.rpc.server.request.dropped:debug]: The RPC secd_rpc_auth_get_creds sent from NBLADE_CIFS was dropped by SecD due to memory pressure.
SecD cm統計を収集すると、この状態が何回発生したかを確認することもできます。
nas::> set diag
nas::*> statistics start -object secd -instance secd -node NETAPP01-06 -sample-id sample_695
nas::*> statistics stop –sample-id sample_695
nas::*> statistics show –sample-id sample_695
Object: secd
Instance: secd
Start-time: 5/24/2018 15:46:34
End-time: 5/24/2018 15:50:09
Elapsed-time: 214s
Scope: NETAPP01-06
instance_name secd
node_name NETAPP01-06
num_rpcs_dropped_due_to_low_memory
mgwd 0
nblade 98765
dblade 0
num_rpcs_failed -
mgwd 0
nblade 98753
dblade 0
libc 0
rpc_task_queue_latency
また、キューに入れられた各要求のヒストグラムと、キューに留まっていた期間も記録します。
process_name secd
rpc_task_queue_latency -
<20us 16667
<40us 0
<60us 0
<80us 0
<100us 0
<200us 0
<400us 0
<600us 0
<800us 0
<1ms 0
<2ms 0
<4ms 0
<6ms 0
<8ms 0
<10ms 0
<12ms 0
<14ms 0
<16ms 0
<18ms 0
<20ms 0
<40ms 0
<60ms 0
<80ms 0
<100ms 0
<200ms 0
<400ms 0
<600ms 0
<800ms 0
<1s 0
<2s 17620
<4s 16077
<6s 43298
<8s 31813
<10s 378
<20s 23
<30s 0
<60s 0
<90s 0
<120s 0
>120s 0
また、secd_rpc_auth_get_credsでクレデンシャル検索が発生するため、次の単位でカウント数が増加すると予想されます。
Object: secd_rpc
Instance: secd_rpc_auth_get_creds
Start-time: 5/24/2018 15:46:34
End-time: 5/24/2018 15:50:09
Elapsed-time: 214s
Scope: vservername
Counter Value
-------------------------------- --------------------------------
instance_name secd_rpc_auth_get_creds
last_update_time Thu May 24 15:50:09 2018
longest_runtime 0ms
node_name NETAPP-06
num_calls 97699
num_failures 86
num_successes 97613
process_name secd
shortest_runtime 0ms
vserver_name
vservername vserver_uuid c4f936f2-66a6-11e7-9713-
90e2bacde704
StorageXについては、この移行製品でこのような問題が発生しているため、特に言及しています。
StorageXはデフォルトでCPUコアごとに16スレッドを使用するため(構成可能)、大規模なmulti-proc\coreサーバでは、同時実行数を迅速に拡張できます。各スレッドは、ファイルをコピーし、次にジョブタスクの最後に、DACL、SACL、所有者情報などのセキュリティ記述子を配置します。最後に、そのスレッドは次のファイルで動作します。
たとえば、8個のCPUコアサーバは128個のスレッドに相当し、非常に小さなファイルを移行します。各ファイルの所有者が固有である場合、ONTAP は短時間で多くのクレデンシャル検索作業を実行する可能性があります。また、StorageXでは、レプリケーションエージェントを実行している複数のサーバを処理できます。
ファイル所有者の 原因 ONTAP を設定するとSecDが増えるのはなぜですか。
ファイルの所有者を設定すると、ONTAP はユーザのクレデンシャルを作成する必要があります。そのクレデンシャルがキャッシュされていない場合は、ドメインコントローラでユーザのクレデンシャルを照会します。
のこの状況を回避するのに役立ちます。RFE:ファイル
https://mysupport-beta.netapp.com/si...P/BURT/1153207または
この固定バージョンのACL設定時にsid所有者の検索を無効にするオプション
です。この状況を回避することもできます。ファイル所有権の設定中にWindowsグループメンバシップを取得しないようにします
パケットトレースに表示される内容の例:
>>file owner is set by StorageX at the end of the file sync
Frame1 Source: StorageX Dest: ONTAP SMB2 SetInfo Request SEC_INFO/SMB2_SEC_INFO_00 File: 1.txt
Owner: S-1-5-21-1417671877-1164952658-2896985891-1156 (Domain SID-Domain RID)
>>ONTAP (if SID not cached) will need to go to Domain Controller to lookup SID
Frame2 Source: ONTAP Dest: DC LSARPC lsa_LookupSids2 request
Sid: S-1-5-21-1417671877-1164952658-2896985891-1156 (Domain SID-Domain RID)
RID: 1156 (Domain RID)
>> Domain Controller will respond with the name translation of SID
Frame3 Source: DC Dest: ONTAP LSARPC lsa_LookupSids2 response
Pointer to String (uint16): thor
>>ONTAP will build the credential via s4u2self (LDAP is fallback) to Domain Controller
Frame4 Source: ONTAP Dest: DC KRB5 TGS-REQ
padata-type: kRB5-PADATA-S4U2SELF (129)
KerberosString: thor
>>Domain Controller will respond with user’s credentials – ONTAP will usermap internally
Frame5 Source: DC Dest: ONTAP KRB5 TGS-REP
>>ONTAP responds to the original setinfo in Frame1
Frame6 Source: ONTAP Dest: StorageX SMB2 SetInfo Response
この状況に該当する場合、どのような推奨事項がありますか?
- 外部サーバのボトルネック/遅延を確認します
- StorageXスレッドを小さくします
- 他のノードのSecDに負荷を分散します
- お客様のアカウントチームとPSの協力を得て、移行を支援してください
外部サーバのボトルネック/遅延を確認します
ファイルの同期では、移行するファイルに所有者情報を設定する必要があるため、SecDの処理を圧迫する可能性があります。クライアントの標準的なワークロードには、アカウントクレデンシャル検索がそれほど多くない場合もあります。多数のスレッドが発生し、多数の小さなファイルが同期されている大規模な移行では、原因 がクレデンシャル検索を大量に実行する可能性があります。外部サーバ通信(DNS、AD、LDAP、NIS、ネームマッピングなど)の遅延やボトルネックをチェックする。 ネームサービスなど)
これらの遅延やボトルネックのトラブルシューティングは、クレデンシャル検索のフラッディングによる影響を軽減するのに役立ちます。
netlogon、ldap-ad、LSA、ldap-nis-namemap、NISなどの外部サービスが応答しているかどうかを調べる方法を参照してください。
外部接続式Vscan、FPolicy、監査について、外部サーバの遅延をチェックします。移行に伴う運用の増加にレイテンシを追加可能なもの。
StorageXスレッドを小さくします
この 推奨構成では、ストレージXとの契約が、同時実行を制限する最善のアプローチを検証する必要があると考えられます。パブリッシュ時に、これを実行する方法についての既知の方法です。
DWORD - HKEY_LOCAL_MACHINE\SOFTWARE\Data Dynamics\StorageX\ReplicationAgent\MaxDirectoryEnumerationThreads
はMaxDirectoryEnumerationThreads(REG_DWORD)です。デフォルトは0です(または定義されていません)。これは、現在のシステムのCPUの数に基づいてスレッドの最大数を計算することを意味します。
RAを再起動します。
Linux(UNIX)Replication Agent:
The same setting came be made on the UNIX RA in the following file: /usr/local/URA/log/Registry.xml. Add the following lines under the <Replication Agent> tag:
<VALUE name = "DisableReplicationPipelining" type "REG_DWORD"><0X00000001>
<VALUE name = "MaxDirectoryEnumerationThreads" type "REG_DWORD"><hex value of number of enumeration threads>
SecDを過負荷にせずにペースで移行を続けるために必要なバランスにトライアルとエラーが必要になる場合があります。スレッド数は、「1」ほど少なくすることができます。
追加情報
ここにテキストを追加します。