メインコンテンツまでスキップ

StorageX の移行で Secd が大量に発生

すべてのとおり  

に適用されます

  • ONTAP 9
  • StorageX
  • 移行

回答

サードパーティ製のマルチスレッド移行ツールを使用したストレージの移行では、 SE次元 のボトルネックが発生する可能性があります。多くの場合、これは、移行が発生しているときにクライアント認証のパフォーマンスの潜在的な問題であると考えられます。ノードの認証に関連する作業も影響を受ける可能性があります。
 
 

このボトルネックの証拠
は、次のエラーで確認できます。 SE次元 SE2D はキューイングを開始でき、要求は長期間キューに格納されます。


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

 最終的には、 S2D RPC メモリ割り当てが 80% に達した場合、

これらのメッセージの記録を開始します。 SE次元
[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
[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.

による SE次元 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 スレッドを使用するため(設定可能)、大規模なマルチプロセッサ / コアサーバでは同時実行時に迅速に拡張できます。各スレッドはファイルのコピーを行い、ジョブタスクの最後に dACL\SACL\ 所有者情報を含むセキュリティ記述子を配置します。最後に、そのスレッドは次のファイルで動作します。
 
たとえば、 8 CPU コアサーバは、 128 スレッドに相当し、非常に小さなファイルを移行します。各ファイル所有者が一意である場合、 ONTAP は短時間で多くのクレデンシャル検索を実行することになります。また、 StorageX では、レプリケーションエージェントを実行している複数のサーバを扱うこともできました。
 
ファイル所有者を設定すると、 ONTAP の機能が強化されるのはなぜですか。
 
ファイル所有者を設定すると、 ONTAP はユーザのクレデンシャルを作成する必要があります。そのクレデンシャルがまだキャッシュされていない場合は、ドメインコントローラにユーザのクレデンシャルを照会します。
 
この RFE は、今後この状況を回避するのに役立ちます
。 RFE :
ファイルに ACL を設定する際に SID 所有者の検索を無効にするオプション https://mysupport-beta.netapp.com/si.p/burt/1153207

または修正バージョンを使用すると、状況を回避できます。
ファイル所有権を設定する際に Windows グループメンバーシップを取得しないようにします
 

パケットトレースに表示される内容の例:
 
>>file owner is set by StorageX at the end of the file sync
Frame1 Source: StorageX  Dest: ONTAPSMB2    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 と協力して、移行を支援します

外部サーバのボトルネックをチェックし

ます。 \n ファイル同期の一部に、移行するファイルの所有者情報の設定が含まれているため、 S2D 処理に負荷がかかる可能性があります。通常のクライアントワークロードでは、アカウントクレデンシャルの検索を大量に作成する必要はありません。多数のスレッドが発生し、多数の小さなファイルが同期されている大規模な移行では、大量のクレデンシャル検索が発生する可能性があります。外部サーバ通信( DNS 、 AD 、 LDAP 、 NIS 、ネームマッピング、ネームサービスなど)の遅延やボトルネックをチェック
します。これらの遅延のトラブルシューティングやボトルネックは、クレデンシャル検索のフラッディングによる影響を軽減するのに役立ちます。

Netlogon 、 ldap-ad 、 LSA 、 ldap-nis-nameMap 、 NIS などの外部サービスの応答が遅いかどうかを確認する方法を参照してください。

Offbox Vscan 、 FPolicy 、監査に関する外部サーバの遅延をチェックします。移行に関連する運用の増加に遅延を追加できるものはすべて含まれています。
 

StorageX スレッドの減少

この推奨事項では、同時実行を制限する最適なアプローチを検証するために StorageX 契約が必要になる可能性が高くなります。公開時に、これを実現する方法は既知の方法です。
 
レジストリキーはDWORD -  HKEY_LOCAL_MACHINE\SOFTWARE\Data Dynamics\StorageX\ReplicationAgent\MaxDirectoryEnumerationThreads

MaxDirectoryEnumerationThreads ( REG_DWORD )です。デフォルトは 0 (または未定義)です。つまり、現在のシステムの CPU 数に基づいてスレッドの最大数を計算します。 
 
RA を再起動します。
 
Linux ( UNIX )レプリケーションエージェント:
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>
 
ベストプラクティスでは、 SE次元 を圧倒して移行をペースを維持するために必要なバランスについて、試行錯誤が必要になる場合があります。スレッド数は「 1 」以下にすることができます。
 

追加情報

ここにテキストを追加します。