CDL エンドポイントポッドは、NF アプリケーションから CDL に対する要求を受信するためのフロントエンドです。CDL エンドポイントは、データベースサービス要求を処理するために、NF クライアントに向けて HTTP2 インターフェイスを介して gRPC を公開します。各ポッドは、次の属性で始まります。

• systemID：このパラメータは、サイト ID（例：Site）を指定します。

• clusterID：このパラメータは、サイト内の一意のデータストア ID（例：X、Y）を指定します。

CDL エンドポイントは、NF アプリケーションから作成、読み取り、更新、削除（CRUD）要求を受信します。これらの操作を実行するために、GRPC を介して CDL インデックスおよびスロットポッドと通信します。

CDL エンドポイントは、サイト内の他のポッドについて、etcdを使用して自動的に学習します。また、Cisco Data Store K8s ポッドは本質的にステートレスであり、セッションのスティッキ性は維持されません。CDL エンドポイントは NF アプリケーションから要求を受信し、GRPC を介して内部的にスロットポッドおよびインデックスポッドと通信して、それに応じて要求を処理します。処理が完了すると応答を返します。

CDL エンドポイントが作成、削除、または更新セッションを受信すると、受信コンテナはそれをスロットポッドおよびインデックスポッドにレプリケートし、「n」個の書き込みがインデックスおよびスロットのマイクロサービスによって確認（ACKed）された場合にのみ、応答を送信します。

（注）	実稼働環境で CDL エンドポイントポッドを展開するには、最大 4 つの仮想 CPU（vCPU）が必要です。

CDL スロットポッドには、実際のセッションデータが保存されます。CDL エンドポイントはクラスタ内のすべてのスロットポッドに接続し、セッションデータをすべてのポッドにレプリケートします。これらのマイクロサービスは、内部 gRPC インターフェイスを Cisco Data Store に公開するために展開された K8s ポッドです。各ポッドは、次の属性で始まります。

• systemID：このパラメータは、サイト ID（例：Site-1）を指定します。

• clusterID：このパラメータは、サイト内の一意のデータストア ID（例：Session）を指定します。

• mapID：このパラメータは、クラスタ内のレプリカセット ID を指定します。（例：map-1、map-2、..map-n）。

• instanceID：このパラメータは、レプリカセット内のインスタンス ID を指定します。（例：map-1.instance-1、map-1.instance-2）

各スロットポッドは、限られた数のセッションと、保存されているセッションデータの事前に割り当てられたメモリを保持します。また、レプリカセット（mapID）内の各レプリカには、定義されたアンチアフィニティルールがあり、同じブレードフォームが同じレプリカセットの複数のメンバーまたはインスタンスをホストするのを防ぎます（ブレードまたはノードに障害が発生した場合の高可用性のため）。各スロットポッドは、タイマーと最後に更新された TS を維持します。スロットポッドは、競合が検出された場合、タイマーが切れたときにアクションを実行するために、クライアント NF への通知コールバックを生成します。

（注）	実稼働環境でスロットポッドを展開するには、最大で 2 つの vCPU が必要です。

ポッドのフェールオーバーと回復が発生した場合、スロットポッドは以下から回復します。

• ローカルレプリカメンバー：スロットは gRPC ストリームから一括で直接読み取り、データを回復します。

• リモートレプリカメンバー：同期に使用できるローカルレプリカがない場合、スロットは同じマップのリモートサイトインスタンスからデータを読み取ります。

  次の図は、ローカルピアおよびリモートピアからのスロットリカバリプロセスを示しています。

  

  

データのスライシング

データのスライシングでは、CDL がスライスとして論理的に分割され、ネットワーク機能（NF）から受信したスライス名に基づいてセッションデータが保存されます。

データのスライシングを使用すると、1 つ以上の NF がさまざまなタイプのセッションデータを CDL の専用スライスに保存できます。

スライス名が設定されていない場合は、session というデフォルトのスライス名が使用されます。

設定は次のとおりです。

cdl datastore <datastore name> slice-names [ <sliceName 1> <sliceName 2> ... <sliceName n> ]

サンプル設定を次に示します。

cdl datastore session slice-names [ session1 session2 ]

（注）	スライス名が NF の ops-center または CDL の ops-center で設定されている場合、NF からのすべての要求に有効なスライス名が必要です。スライス名が設定されているものと違うか空の場合、エラーコードが表示され要求は拒否されます。 スライス名が設定されていない場合、NF 要求はデフォルトの session にルーティングされます。 デプロイメント後の実行中のシステムでは、スライス名を更新できません。

CDL スロットデータの削除

特定のシナリオでは、CDL レコードがスロットでは見つかりますが、インデックスポッドでは見つかりません。そのようなレコードに関するスロットからアプリケーションへの通知では、値が正しく受信されません。インデックスデータが削除されない場合、スロット内のレコードは削除されません。

CDL スロットデータを削除する前に、次のことを確認してください。

• アプリケーションへの通知数がしきい値（デフォルト値の 3）を超えた場合、レコードが古い状態であると考えられます。

• これにより、いずれかのインデックスポッド（ローカルまたは Geo リモートサイト）で対応するレコードを見つけるために、検証チェックがトリガーされます。

• インデックスのマップ ID に不一致がある場合、またはマップ ID がすべてのインデックスポッドで見つからない場合、クリーンアップが呼び出され、ローカルサイトとリモートサイトのレコードが削除されます。

古いレコードを削除するために、次のパラメータが導入されました。

disable-auto-deletion：true に設定すると、古い CDL レコードは削除されません。古いレコードの自動削除は、デフォルトで有効になっています。

notification-retry-count：アプリケーションから更新を受信せずにアプリケーションに送信するタイマー切れ通知の最小再試行回数を指定します。notification-retry-count の回数を超えても更新を受信しない場合、CDL はスロットレコードが古いかどうかのチェックに進みます。デフォルトの回数は 3 です。

CDL のサンプル設定は次のとおりです。

古いスロットレコードの自動削除機能を無効にするには、次の手順を実行します。

cdl datastore session
features slot-stale-session-detection disable-auto-deletion true
exit

notification-retry-count は、5 などの新しい値に変更できます。これは、タイマー切れ通知を 5 回試行した後、データが古いかどうかのチェックに進むことを示しています。

cdl datastore session
features slot-stale-session-detection notification-retry-count 5
exit

トラブルシューティング

エンドポイントおよびスロットポッドで古い CDL スロットデータの障害対応ログを有効にするには、次の設定を使用します。

cdl logging logger ep.staleRecord.session
level info
exit

cdl logging logger slot.staleRecord.session
level info
exit

インデックス作成コンテナには、インデックス作成データが含まれます。インデックスポッドには、次の 2 つの重要な情報が保存されます。

• スロットマップ ID のプライマリキー。

• セカンダリキーからプライマリキーへの固有のマッピング。

インデックスエントリは、セッション接続時に作成され（使用例の場合）、切断時に削除されます。インデックス作成では、インメモリ KV ストアを使用してキーをメモリに保存し、マルチプライマリ書き込みを提供します。インデックス作成書き込みログ（設定操作と削除操作）も、リモートサイトのレプリケーション用に Kafka ポッドに書き込まれます。インデックスポッドの 1 つが Kafka でログを書き込み、リモートサイトでそのログを受信します。対応する操作もリモートサイトで実行されます。

（注）	実稼働環境でインデックスポッドを展開するには、最大で 2 つの vCPU が必要です。

ポッドのフェールオーバーと回復が発生した場合、インデックスポッドは以下から回復します。

• ローカルレプリカメンバー：インデックスは gRPC ストリームから一括で直接読み取り、データを回復します。

• リモートレプリカメンバー：同期に使用できるローカルレプリカがない場合、インデックスは同じマップのリモートサイトインスタンスからデータを読み取ります。

  次の図は、ローカルピアおよびリモートピアからのインデックス リカバリ プロセスを示しています。

  

  

CDL は、DB サービス検出として etcd（オープンソースのキーバリューストア）を使用します。CDL ポッド（エンドポイント、スロット、またはインデックス）が開始、強制終了、またはシャットダウンされると、 状態のパブリッシュによってイベントが etcd に更新されます。

CDL エンドポイントは、スロットポッドまたはインデックスポッドがいつ起動または停止したかを知る必要があります。したがって、スロットポッドおよびインデックスポッドのイベントの通知に etcd で登録されます。

同様に、CDL スロットポッドまたはインデックスポッドは、そのピアレプリカポッド（同じ map-id を持つ）がいつ起動または停止したかを知る必要があります。したがって、対応するスロットまたはインデックス（同じ map-id を持つ）のポッドイベントの通知に etcd で登録されます。

これにより、通知はこれらのイベントに登録された各ポッドに送信されます。また、キーイベントが追加または削除されると、ローカルマップが更新されます。etcd キャッシュは、ローカルサイトのイベントにのみ適用されます。

Kafka ポッドは、インデックス作成のためにローカルレプリカ間とサイト間でデータをレプリケートします。サイト間のレプリケーションの場合、Kafak は MirrorMaker を使用します。Kafka ポッドは、高可用性のためにレプリカ数が少なくとも 2 に設定されたセッション vms に展開されます。

Kafka は Zookeeper ポッドを使用して Kafka クラスタを管理し、Kafka ブローカとの調整を行います。

Mirror Maker ポッドは、インデックスデータをリモート CDL サイトに Geo レプリケートします。リモートサイトからデータを取得し、ローカルの Kafka サイトにパブリッシュして、適切なインデックス作成インスタンスを取得します。

CDL エンドポイントは、CDL Ping RPC を使用して 30 秒ごとにリモートサイトの接続（レプリケーション接続と内部運用接続）をモニターします。いずれかの接続に対して ping が 3 回失敗した場合は、その接続を再作成して古い接続を閉じます。

リモートサイトのモニタリングは設定可能で、デフォルトでは有効になっています。cdl datastore session features remote-site-connection-monitoring enable CLI コマンドを使用して、リモートサイトの接続を有効または無効にします。

リモートサイトの接続を有効または無効にするには、次の CLI コマンドを使用します。

config 
   cdl datastore session features remote-site-connection-monitoring enable [ true | false ] 
   exit 

エンドポイントのリモートサイト接続のログを表示するには、次の設定を使用します。

cdl logging logger ep.remoteConnection.session 
level trace 
exit 

このセクションでは、次のコールフローについて説明します。

• プライマリキーによるレコードの検索

• 一意のキーによるレコードの検索

• レコードの作成

• レコードの更新

• レコードの削除

• タイマーが切れた時の NF への通知

• Geo レプリケーション：作成（GEO）

• Geo レプリケーション：更新（GEO）

• Geo レプリケーション：削除（GEO）

特定のシナリオでは、CDL のインデックスポッドの一意のキーが古くなっています（削除されると想定）。CDL は古いレコードの詳細を NF に示さないため、NF はこれらの一意のキーを別のレコードに使用しようとする場合があります。

CDL ではオペレータが、古いレコードを検出し、その古いレコードに対して必要なアクションを実行するパラメータを有効にできます。

古いレコードを検出してアクションを実行するには、次の手順を実行します。

1. 古いレコードを識別します。新しいレコードが作成されると、一意のキーは上書きされます。このようなレコードを識別するには、index-overwrite-detection パラメータを有効にし、unique-keys-prefix がプレフィックスパターンと一致することを確認します。

2. 識別された古いレコードに対して必要なアクション（通知、削除、またはログ）を実行します。

   CDL は、上書きされた一意のキーを検出し、次のいずれかのアクションを実行します。

   • 古いレコードまたはレコード全体を削除します。削除アクションは、古いレコードの PurgeOnEval フラグが false に設定されている場合にのみトリガーされます。

   • 古いレコードについて NF に通知します。通知アクションは、STALE_INDEX_NOTIFICATION を NF に送信します。

   • 上書きされた一意のキーをログに記録します。ログアクションの場合、古いレコードは WARN ログレベルでログに記録されます。

   （注）	同じプライマリキーを指している 2 つの異なる一意のキーがあり、一方が通知アクションで、もう一方が削除アクションである場合、通知アクションが実行されます。

次の設定を使用します。

features index-overwrite-detection max-tps variable
features index-overwrite-detection queue-size variable
features index-overwrite-detection unique-keys-prefix uk
  action [delete-record, notify-record, log-record]
 

値は次のとおりです。

• max-tps：古いレコードの通知レートを制御します。デフォルトは 200 です。

• queue-size：古いレコードを処理するキューサイズを制御します。デフォルトは 1000 です。

  （注）	queue-size パラメータは、削除アクションと通知アクションの両方に使用されます。max-tps パラメータは通知アクション専用です。

• unique-keys-prefix：実行する必要があるアクションとともに固有のキーのプレフィックスパターンを指定します。

例：

cdl datastore session
features index-overwrite-detection max-tps 250
 features index-overwrite-detection queue-size 2000
 features index-overwrite-detection unique-keys-prefix uk
 action notify-record
 exit    
  exit      
  

トラブルシューティング

古いインデックスレコードをトラブルシュートするには、index.overwrite.session ロガーを INFO レベルに設定します。エンドポイントポッドおよびインデックスポッドからのログは、障害対応に役立ちます。

CDL の設定：

cdl logging logger index.overwrite.session
 level info
exit
 

次のメトリックスが導入されています。

• overwritten_index_records_deleted：インデックスで特定された古いレコードが原因で削除されたレコードの総数を保持します。

• overwritten_index_records_skipped：古いレコードとして検出されたものの、そのレコードの通知または削除の処理中にキューがいっぱいになった場合はドロップされるレコードの総数を保持します。

ネットワーク機能（NF）（セッション管理機能（SMF）およびポリシー制御機能（PCF））の Ops Center を介して CDL を展開できます。

SMF Ops Center を介した CDL の展開については、『Ultra Cloud Core 5G Session Management Function - Configuration and Administration Guide』の「Cisco Common Data Layer in SMF」の章を参照してください。

PCF Ops Center を介した CDL の展開については、『Ultra Cloud Core 5G Policy Control Function -Configuration and Administration Guide』の「Cisco Common Data Layer in PCF」の章を参照してください。

このセクションでは、Geo レプリケーション（GR）の CDL を展開する方法について説明します。

このセクションでは、CDL デプロイメントのアラームについて説明します。

障害を検出するために次のアラームが導入されています。

CNDP は、アップグレードゾーン内のすべてのノードが並行してアップグレードされる、ゾーンベースのアップグレードをサポートしています。これにより、大規模なクラスタのアップグレードに時間をかけずに済みます。CDL は、K8s のトポロジ分散制約機能を利用して、アップグレードゾーン全体にポッドを分散します。

CDL でこのインサービスをサポートするには、ポッドがアップグレードゾーンを認識している必要があり、スロット、インデックス、または Kafka のすべてのレプリカが同じアップグレードゾーンでスケジュールされないようにする必要があります。たとえば、同じマップの両方のスロットレプリカが同じアップグレードゾーンにある場合、両方のレプリカが同時にダウンし、非 GR シナリオでセッションの損失を引き起こします。CDL エンドポイントは、レプリカが 1 つ戻るまで要求の処理を停止します。

少なくとも 3 つのアップグレードゾーンが存在することを確認してください。ノード障害が発生すると、別のゾーンにポッドをスケジュールするスペースがある場合でも、ポッドが保留状態になる可能性があります。

この機能を有効にするために CDL または NF Ops Center で必要な明示的な設定はありません。クラスタデプロイヤ自体が設定を渡します。

次のパラメータを使用して、CDL のシャードあたりの最大キャパシティを定義できます。

• slotRecordCapacity（デフォルト値：1M/シャード）

• indexRecordCapacity（デフォルト値：10M/シャード）

• slotRecordsSizeCapacityInBytes（デフォルト値：5GB/シャード）

（注）	シャードあたりのデフォルトのキャパシティは変更できません。

CDL は次の計算に基づいて最大キャパシティを決定します。

ソフト制限

1. cdl_slot_record_capacity  =  No of shards * slotRecordCapacity

2. cdl_index_record_capacity = No of shards * indexRecordCapacity

3. cdl_slot_size_capacity    = No of shards * slotRecordsSizeCapacityInBytes

ハード制限

1. cdl_slot_record_capacity = No of shards * slotRecordCapacity * 105%

2. cdl_index_record_capacity = No of shards * indexRecordCapacity * 105%

3. cdl_slot_size_capacity = No of shards * slotRecordsSizeCapacityInBytes * 105%

システムが最大キャパシティに達するたびに、CDL は過負荷となります。また、CDL は次のアラートをトリガーして、システムを過負荷から保護します。

• cdlOverloaded - major：このアラートは、CDL システムがキャパシティの 80% に達するとトリガーされます。

• cdlOverloaded - critical：このアラートは、CDL システムがキャパシティの 90% に達するとトリガーされます。

アラートに加え、CDL エンドポイントは次のエラーによってすべての作成要求を拒否します。

error code 507: Datastore reached its full capacity

ただし CDL は、ハード制限キャパシティに達するまで、すべての更新要求を処理します。ハード制限キャパシティを超えると、CDL はすべての更新要求を拒否します。

既存の CDL のオーバーロード防止設定は、新しい設定に置き換えられます。

（注）	以前はオーバーロードの防止がデフォルトで有効になっていて、スロットあたり 100 万レコード、インデックスあたり 1,000 万レコード、かつスロットあたり 5 GB のレコードサイズというハードコーディング制限がありました。しかし本リリースではこの機能はデフォルトで無効になっているため、この機能を有効に設定し、各パラメータに適切なオーバーロード制限（オプション）を設定する必要があります。

cdl datastore session overload-protection disable true 

cdl datastore session features overload-protection enable <true/false> 

オーバーロード防止が有効になっている場合は、アラートも有効になります。prometheus-rules-cdl ポッドが生成されます。オーバーロード防止が無効になっている場合、アラートは無効になります。prometheus-rules-cdl ポッドが削除されます。

オーバーロード防止パラメータの設定

オーバーロード防止の制限を設定するために、次のパラメータが設定されています。

• cdl datastore session features overload-protection index-max-record-count <value> 

• cdl datastore session features overload-protection slot-max-record-count <value> 

• cdl datastore session features overload-protection slot-max-size <value> 

• cdl datastore session features overload-protection hard-limit-percentage <value> 

次の表に、設定の詳細を示します。

cdl datastore session features overload-protection enable <true/false> 

cdl datastore session features overload-protection index-max-record-count <value> 

cdl datastore session features overload-protection slot-max-record-count <value> 

cdl datastore session features overload-protection slot-max-size <value> 

cdl datastore session features overload-protection hard-limit-percentage <value> 

cdl datastore session features overload-protection major-alert-threshold <value> 

cdl datastore session features overload-protection critical-alert-threshold <value> 

アラートのパーセンテージを設定するには、次のコマンドを実行します。

cdl datastore session features overload-protection critical-alert-threshold <percentage> 

cdl datastore session features overload-protection major-alert-threshold <percentage> 

CEE Ops Center CLI で次のコマンドを使用して、アラートを確認できます。

show alerts active { detail | summary }  

show alerts active detail sumary "CDL is overloaded." 

次の例では、システムキャパシティが 80% 以上になった場合に cdlOverloaded - major アラートがトリガーされます。

alerts active detail cdlOverloaded-major 5446095ab264
 severity    major
 type        "Processing Error Alarm"
 startsAt    2020-10-15T15:09:00.425Z
 source      System
 summary     "CDL is overloaded."

次の例では、システムキャパシティが 90% 以上になった場合に cdlOverloaded - critical アラートがトリガーされます。

alerts active detail cdlOverloaded-critical 5446095ab264
 severity    critical
 type        "Processing Error Alarm"
 startsAt    2020-10-15T15:09:16.425Z
 source      System
 summary     "CDL is overloaded."

CDL は、再調整メソッドを使用したトラフィックのドレインなしでの、ハーフハイトからフルハイトへのラック変換をサポートしています。

この再調整メソッドは、移行中の既存のコールと新しいコールには影響しません。この機能は、CDL のインデックスマップの再調整に対応します。

CDL のハーフラック構成をフルラック構成に移行するには、次の手順を使用します。

1. ラック 1 をアクティブ、ラック 2 をスタンバイに設定します。

   

   前提条件：CDL はハーフラック構成を使用して実行されていますが、両方のサイトにフルラックのリソースを備える必要があります。

   アクション：ラック 1 をアクティブにし、ラック 2 をスタンバイにします。CDL の設定変更はありません。

   事後検証：トラフィックはラック 1 にのみ到達します。

2. ラック 2 でシステム モード シャットダウンを設定します。

   

   前提条件：ラック 1 はアクティブモード、ラック 2 はスタンバイモードである必要があります。

   アクション：ラック 2 でシステム モード シャットダウンを実行します。

   事後検証：サイト 1 の mirror-maker は実行状態ではありません。

3. ラック 2 をスタンバイに設定します。新しい設定に合わせてフルラック CDL を構成し、prev-map-count が設定されたスケールアップモードを有効にします。

   以下に設定例を示します。

   configure 
      cdl datastore session mode scale-up 
      cdl datastore session index prev-map-count 2 

   スケールアップモードなしのハーフラック構成：

   cdl datastore session  
   label-config session 
      index map 2 
      slot map 4 
      exit 

   スケールアップモードを使用するフルラック構成：

   cdl datastore session  
   label-config session 
   mode scale-up 
      index map 4 
      index prev-map-count 2 
      slot map 8 
      exit 

4. ラック 2 の system mode running を有効にします。

   

   前提条件：ラック 1 はアクティブである必要があり、ラック 2 はフルラック CDL 構成でスタンバイである必要があります。

   アクション：ラック 2 で system mode running を実行します。

   事後検証：両方のサイトの mirror-maker が実行状態である必要があります。サイト 2 の古いインデックスまたはスロットが、リモートピアとの初期同期を実行できる必要があります。

5. トラフィックをラック 2 に切り替えます。

   

   前提条件：ラック 1 はアクティブになっており、ハーフラック構成で実行されている CDL を含むフルラックリソースを備えている必要があります。ラック 2 はスタンバイになっており、フルラック構成で実行されている CDL を含むフルラックリソースを備えている必要があります。

   アクション：ラック 1 をスタンバイにし、ラック 2 をアクティブにします。CDL で設定を変更する必要はありません。

   事後検証：トラフィックはラック 2 にのみ到達します。

6. ラック 1 のシステム モード シャットダウンを有効にします。

   

   前提条件：ラック 2 はアクティブ、ラック 1 はスタンバイである必要があります。

   アクション：ラック 1 でシステム モード シャットダウンを実行します。

   事後検証：サイト 2 の mirror-maker は実行状態ではありません。

7. ラック 1 をスタンバイに設定します。新しい設定でフルラック CDL を構成し、premap-count が設定されたスケールアップモードを有効にします。

   以下に設定例を示します。

   configure 
      cdl datastore session mode scale-up 
      cdl datastore session index prev-map-count 2 

   フル構成により、スロットマップ数とインデックスマップ数が更新されます。新しく追加されたスロットとインデックスのラベル設定が追加されます。

8. ラック 1 の system mode running を有効にします。

   

   前提条件：ラック 2 はアクティブである必要があり、ラック 1 はフルラック CDL 構成でスタンバイである必要があります。

   アクション：ラック 1 で system mode running を実行します。

   事後検証：両方のサイトの mirror-maker が実行状態である必要があります。サイト 1 のすべてのインデックスとスロットが、リモートピアとの初期同期を実行できる必要があります。CDL レプリケーションエラーがあるかどうかを CEE アラートで確認します。

9. ラック 1（スタンバイ）の CLI を使用してインデックスの再調整をトリガーします。

   

   前提条件：CDL が両方のサイトで正常な状態になっている必要があります。ラック 1 はスタンバイ、ラック 2 はアクティブである必要があります。両方のサイトに、スケールアップモードがインデックス prev-map-count で設定されている必要があります。

   ラック 1 で CLI によるインデックスの再調整を行うと、（古いマップ数に応じて）以前計算されたマップから（新しいマップ数に応じて）新しく計算されたマップにインデックスがコピーされます。これは、コピーが完了し、以前計算されたマップからインデックスを削除した後に行われます。

   アクション：スタンバイサイト（ラック 1）で次のコマンドを使用して、rebalance-index の実行をトリガーします。

   cdl rebalance-index run tps tps_value 
   

   事後検証：再調整ステータスを追跡するには、次の手順を実行します。

   • 次の CLI コマンドを使用して、再調整ステータスをモニターします。

     
     cdl rebalance-index status 
     

   • 次の CLI コマンドを使用して、再調整の実行を検証します。

     cdl rebalance-index validate 
     

10. インスタンスをアクティブ-アクティブに切り替えます。

    

    前提条件：再調整が正常に完了する必要があります。

    アクション：ラック 1 とラック 2 をアクティブとして有効にします。

    事後検証：トラフィックが両方のサイトに到達する必要があります。

11. 両方のサイトから CDL スケールアップモード設定を削除します。

    前提条件：ラック 1 とラック 2 の両方がアクティブである必要があります。

    アクション：両方のサイトで次のコマンドを設定します。

    no cdl datastore session mode 
    

    事後検証：CDL が正常な状態で実行されている必要があります。スケールアップモードが無効になると、mirror-maker が再起動します。

再調整ログを表示するには、CLI で次のロガーを設定します。

cdl logging logger datastore.idx-rebalance.session 
level warn 
exit 

再調整されたインデックスキーの総数を把握するために、インデックスポッドに次のメトリックが導入されています。

このリリースでは、CDL は FindAll クエリと FindAllNotify クエリの拡張機能をサポートしています。

次の操作をサポートするために、新しいクエリフィルタが導入されています。

• FindAllNotify クエリに最大 20 の IN フィルタ。CDL はスロットからすべてのセッションを取得した後、各セッションを渡されたフィルタと照合します。セッションキーが渡されたフィルタのいずれかと一致した場合、一致した IN フィルタ条件とともに NF に通知します。

• 複数の条件を持つ NOT-MATCH 操作。

• CDL CLI の IN 操作と NOT 操作。

• 通知の IPC ストリーミング。

  以前のリリースでは、CDL はアプリケーションへの通知の送信に単項 RPC を使用していました。このリリースでは、CDL は自身とアプリケーション間の IPC を最適化するために、双方向ストリーミング RPC をサポートしています。

このセクションでは、FindAll クエリと FindAllNotify クエリでさまざまなフィルタ条件をサポートする、CDL の動作のシーケンスについて説明します。

IN フィルタのサポート

1. システムは、クエリパラメータ内のすべての AND 条件と IN 条件をチェックします。

   • クエリに AND と IN の両方のクエリフィルタが含まれている場合は、次の方法で処理されます。

     • CDL は、まずすべての AND フィルタをチェックします。いずれかの AND フィルタが失敗した場合、そのキーはフィルタに一致しなかったので、他の AND フィルタと IN フィルタはスキップされます。

     • すべての AND フィルタが一致したら、IN フィルタをチェックします。いずれかの IN フィルタが一致した場合、そのキーはすでにフィルタに一致しているため、CDL は他の IN フィルタをスキップします。

   • クエリに IN フィルタのみが存在し、いずれかの IN フィルタが一致した場合、CDL は他の IN 条件の処理をスキップします。

2. クエリ要求に 20 を超える IN フィルタがある場合は、400 Bad Request メッセージで応答を返します。

3. CDL は、FindAllNotify クエリ要求で有効になっている場合にのみ、通知とともに一致した IN フィルタ条件を送信します。

（注）	要求でより多くの IN フィルタが渡されると、クエリのパフォーマンスに影響します。

複数の条件での NOT-MATCH 操作のサポート

CDL は、このクエリのフィルタ処理で次の追加条件をサポートしています。

• not-match

• not-starts-with

• not-ends-with

• not-contains

（注）	セッションのいずれかのキー（pk/uk/nuk）が match、contains、starts-with、または ends-with の 条件を満たす場合、そのセッションは not-match、not-contains、not-starts-with、または not-ends-with の条件のそれぞれに対応するフィルタには選択されません。

CDL CLI での IN 操作と NOT 操作のサポート

• CLI でセッションをフィルタ処理するために、次の追加の条件がサポートされています。

  • が次の文字列を含む（contains）

  • not-contains

  • not-ends-with

  • not-starts-with

  • not-match

• CLI での IN 操作では、AND フィルタ filter に加えて、in-filter フィルタもサポートされます。

  次のコードスニペットは、CLI コマンドの例です。

  cdl show sessions summary filter { condition ends-with key 6 } in-filter { in-condition starts-with key key-1 } in-filter { in-condition starts-with key key-2 }

  （注）	filter および in-filter フィルタは、条件のリストです。クエリは最大 20 の in-filter フィルタをサポートします。filter で言及されているフィルタはグループ化されているため、フィルタ、filter、および in-filter の順序は重要ではありません。同様に、in-filter で言及されているフィルタもグループ化されています。

• filterと in-filter によるフィルタ処理では、次の CDL 操作がサポートされています。

  • cdl show sessions count summary

  • cdl show sessions count detailed

  • cdl show sessions detailed

  • cdl show sessions summary

  • cdl clear sessions

ストリーミング通知のサポート

• CDL は、双方向ストリーミング RPC を使用して、トランザクション ID を持つストリームを介して通知をアプリケーションに送信します。応答は、関連付けのためのトランザクション ID とともに、アプリケーションからデータストアに異なるストリームで送信されます。

• デフォルトでは、CDL は単項 RPC を使用し、ストリーミング機能は無効になっています。ストリーミングは、機能フラグ use-stream が CDL CLI で設定されている場合にのみ有効になります。ストリーミングが有効になっている場合、CDL 通知はすべてストリーミングを使用して送信されます。

  通知のストリーミング機能を有効にするには、次の CLI コマンドを使用します。

  cdl datastore session slot notification use-stream true

• ストリーミングが有効になっている場合、デフォルトでは、CDL から通知エンドポイントへ 4 つのストリーム接続があります。接続数は CDL CLI を使用して設定できます。ストリーム接続はラウンドロビン方式で使用されます。

• スロットまたはエンドポイントから通知エンドポイントへのアクティブなストリーム接続の数を確認するためのメトリックをサポートします。これらのメトリックを使用して、アクティブなストリーム接続がない場合にアラートを生成します。

このリリースでは、CDL を使用して、ネットワークポリシーを設定しグローバル ネットワーク ポリシー設定をオーバーライドすることができます。設定が有効になっている場合、CDL エンドポイント、インデックス、スロット、Kafka、および Zookeeper のネットワークポリシーが適用されます。

etcd のネットワークポリシーを設定して、グローバル ネットワーク ポリシー設定をオーバーライドすることもできます。設定が有効になっている場合、etcd のネットワークポリシーが適用されます。

CDL ネットワークポリシーを設定するには、次の CLI コマンドを使用します。

config 
   cdl network-policy enable <true/false> 

etcd ネットワークポリシーを設定するには、次の CLI コマンドを使用します。

config 
   etcd network-policy enable <true/false> 

問題の説明

セッションデータがリモートサイトに正しくレプリケートされない。

問題の特定

一方のサイトで追加されたデータに、もう一方のサイトではアクセスできません。

考えられる原因

不適切な Geo レプリケーションの設定がこの問題の原因となっている可能性があります。

対処法

この問題を解決する手順は、次のとおりです。

• ローカルの system-id とリモートサイトの設定を確認します。

• 各サイト間の CDL エンドポイントと Kafka が到達可能かどうかを確認します。

• 各サイトでマップ、インデックスのレプリカ、およびスロットを確認します。それらはすべてのサイトで同一である必要があります。

このセクションでは、CDL 操作の失敗の問題を解決する方法について説明します。

問題の説明

NF は CDL に接続しているが、検索、作成、更新、削除などのセッション操作は失敗する。

問題の特定

NF ログファイルを確認すると、コールの失敗を特定できます。

考えられる原因

この問題は、CDL インデックスとスロットポッドの準備ができていない場合に発生する可能性があります。

対処法

この問題を解決する手順は、次のとおりです。

• すべてのポッドの準備ができており、実行状態であるかどうかを確認します。

• インデックスポッドは、ピアレプリカ（使用可能な場合はローカルまたはリモート）との同期が完了した場合にのみ、準備完了状態に移行します。

• スロットポッドは、ピアレプリカ（使用可能な場合はローカルまたはリモート）との同期が完了した場合にのみ、準備完了状態に移行します。

• エンドポイントを準備完了状態に移行するには、少なくとも 1 つのスロットとインデックスポッドが使用可能である必要があります。準備ができていない場合でも、クライアントは GRPC 接続を受け入れます。

このセクションでは、CDL ポッドがダウンしている場合にこれらを起動する方法について説明します。

問題の説明

CDL の設定が正しくないため、CDL ポッドが「実行」状態にならない。

問題の特定

次のコマンドを使用して、「describe pods」の出力（コンテナ、メンバー、状態、理由、またはイベント）を確認し、ポッドがダウンしているかどうかを識別します。

kubectl describe pods -n  <namespace> <failed pod name> 

考えられる原因

考えられる原因は次のとおりです。

• ポッドが「pending」の状態である。

• ポッドが「CrashLoopBackOff」障害の状態である。

• ポッドが「ImagePullBack」障害の状態である。

対処法

• ポッドが「pending」状態の場合：

  • ラベル値 cdl/node-type を持つ k8s ノードが存在するかどうかを確認します。また、レプリカの数が、ラベル値 cdl/node-type を持つ k8s ノードの数以下であることも確認します。

    kubectl get nodes -l smi.cisco.com/node-type=<value of cdl/node-type, default value is 'session' in multi node setup)
    

• ポッドが「CrashLoopBackOff」障害の状態の場合：

  • ETCD ポッドのステータスを確認します。

    kubectl describe pods -n <namespace> <etcd pod name>

    ETCD ポッドが実行されていない場合は、ETCD の問題を解決してポッドを起動します。

• ポッドが「ImagePullBack」障害の状態の場合：

  • helm リポジトリとイメージレジストリにアクセスできるかどうかを確認します。

  • 必要なプロキシサーバーと DNS サーバーが設定されているかどうかを確認します。

このセクションでは、「準備中（Not Ready）」の状態のままの Mirror Maker ポッドを移動する方法について説明します。

問題の説明

リモートサイトでの接続の問題により、Mirror Maker ポッドが実行状態ではない。

問題の特定

次のコマンドを使用して、Describe ポッドの出力およびポッドログを確認します。

kubectl describe pods -n <namespace> <failed pod name>
kubectl logs -n <namespace> <failed pod name> [-c <container name>]

考えられる原因

リモートサイトの Kafka ブローカとの接続の問題がこの問題の原因となっている可能性があります。

対処法

この問題を解決する手順は、次のとおりです。

• Kafka 用に設定された外部 IP が正確であるかどうかを確認します。

• 外部 IP を介して Kafka のリモートサイトに到達できるかどうかを確認します。

このセクションでは、CDL からのレコード消去について送信される通知が早い、または遅延する問題を解決する方法について説明します。

問題の説明

CDL からのレコード消去について送信される通知が早い、または遅延する。

問題の特定

CDL からのレコードの消去中に来る通知が早い、または遅延します。

考えられる原因

Kubernetes クラスタ内のノードの時刻が同期されていない。

対処法

この問題を解決する手順は、次のとおりです。

• k8s クラスタ内のすべてのノードの時刻が同期されているかどうかを確認する。

• すべての k8s ノードの同期ステータスを確認する。

  chronyc tracking
  chronyc sources -v
  chronyc sourcestats -v

問題の説明

ネットワークの問題または CDL 上の想定外のセッション数によりセッション数が蓄積し、ピアセッション数と一致しない。

問題の特定

CLI または Grafana ダッシュボードからのセッション数に、予想よりも多くのセッション数が表示されているか、セッション数が増え続けています。

考えられる原因

CDL で受信した Create 要求が Delete 要求よりも多くなっています。結果として、セッション数は増加し続けます。

対処法

この問題を解決するには、各 NF がサブスクライバのクリアをトリガーするための適切なアクションを実行する必要があります。

このセクションでは、CDL ポッドでのスケジュール設定、ノードアフィニティ、およびポッド配置に単一のノードラベルを使用することによって発生する可能性のある、スケジュール不可のポッドの問題を解決する方法について説明します。

問題の説明

nodeType パラメータは、CDL でのスケジュール設定、ノードアフィニティ、およびポッド配置を制御する。現在、このパラメータは単一のノードラベル値 smi.cisco.com/node-type で設定されている。CDL がフルノードキャパシティに設定されている場合、単一のノードラベルを使用することによって、（場合により）ポッドがスケジュール不可とマークされる。

問題の特定

CDL ポッドがスケジュール不可とマークされます。

考えられる原因

スケジュール設定、ノードアフィニティ、およびポッド配置に単一のノードラベルを使用している。

対処法

個別のノードラベルを使用して、さまざまな CDL ポッドタイプを制御できます。個別のノードラベルを作成するには、次の手順を実行します。

1. （必須）SMI Cluster Manager Ops Center CLI を介して CDL に使用するすべてのノードで smi.cisco.com/node-type ラベルを作成します。

2. 次の表で指定されているように、CDL ポッドのラベルを作成します。

   ポッド	ラベル	値
   CDL エンドポイントポッド	smi.cisco.com/cdl-ep	true
   CDL スロットポッド	smi.cisco.com/cdl-slot-<MAP Id 1..n>	true
   CDL インデックスポッド	smi.cisco.com/cdl-index-<MAP Id 1..n>	true

   （注）	この設定は、ユーザー定義のスケジュール設定にのみ必要です。

例

次の例は、2 つのエンドポイントレプリカ、4 つのスロットマップ（それぞれ 2 つのレプリカ）、および 2 つのインデックスマップ（それぞれ 2 つのレプリカ）を持つ 4 つの異なるノードを使用する CDL に個別のノードラベルを作成する方法を示しています。

clusters user-k8s
  nodes session1
   k8s node-labels smi.cisco.com/cdl-ep true
   exit
   k8s node-labels smi.cisco.com/cdl-index-1 true
   exit
   k8s node-labels smi.cisco.com/cdl-slot-1 true
   exit
   k8s node-labels smi.cisco.com/cdl-slot-3 true
   exit
   k8s node-labels smi.cisco.com/node-type session
   exit
  exit
exit
clusters user-k8s
  nodes session2
   k8s node-labels smi.cisco.com/cdl-ep true
   exit
   k8s node-labels smi.cisco.com/cdl-index-1 true
   exit
   k8s node-labels smi.cisco.com/cdl-slot-1 true
   exit
   k8s node-labels smi.cisco.com/cdl-slot-3 true
   exit
   k8s node-labels smi.cisco.com/node-type session
   exit
  exit
exit
clusters user-k8s
  nodes session3
   k8s node-labels smi.cisco.com/cdl-ep true
   exit
   k8s node-labels smi.cisco.com/cdl-index-2 true
   exit
   k8s node-labels smi.cisco.com/cdl-slot-2 true
   exit
   k8s node-labels smi.cisco.com/cdl-slot-4 true
   exit
   k8s node-labels smi.cisco.com/node-type session
   exit
  exit
exit
clusters user-k8s
  nodes session3
   k8s node-labels smi.cisco.com/cdl-ep true
   exit
   k8s node-labels smi.cisco.com/cdl-index-2 true
   exit
   k8s node-labels smi.cisco.com/cdl-slot-2 true
   exit
   k8s node-labels smi.cisco.com/cdl-slot-4 true
   exit
   k8s node-labels smi.cisco.com/node-type session
   exit
  exit
exit

cdl label-config session
  endpoint key smi.cisco.com/cdl-ep
  endpoint value true
  slot map 1
    key smi.cisco.com/cdl-slot-1
    value true
  slot map 2
    key smi.cisco.com/cdl-slot-2
    value true
  slot map 3
    key smi.cisco.com/cdl-slot-3
    value true
  slot map 4
    key smi.cisco.com/cdl-slot-4
    value true
  index map 1
    key smi.cisco.com/cdl-index-1
    value true
  index map 2
    key smi.cisco.com/cdl-index-2
    value true
cdl datastore session
  label-config session
  endpoint replica 2
  index replica 2
  index map 2
  slot replica 2
  slot map 4
exit

デフォルトでバンドルされている CDL ダッシュボードと呼ばれる Grafana ダッシュボードを使用して、CDL のさまざまなアクティビティをモニターできます。CDL ダッシュボードには、cdl-endpoint、スロット、インデックス などのさまざまなポッドの CDL に対する TPS と、各操作にかかる応答時間が表示されます。

Type、SliceName、SystemID などで分類した合計レコード数を表示する Grafana CDL Summary ダッシュボードの例を以下に示します。

CDL TPS と応答時間のグラフを表示する Grafana CDL ダッシュボードの例を以下に示します。

Grafana CDL ダッシュボードの拡張により、Geo レプリケーションのステータスが表示されます。Geo レプリケーションのステータスとその他の詳細を表示する Grafana ダッシュボードの例を以下に示します。

GR 接続、インデックス レプリケーションとスロットレプリケーションのパネル、およびそれらの説明を次の表に示します。

CDL Ops Center で cdl show status コマンドを使用して、CDL のステータスを確認し、クライアントによって挿入されたデータを調べることができます。cdl show status コマンドの詳細については、『UCC CDL Command Reference Guide』を参照してください。

次の例は、すべての CDL コンポーネントのステータスとクライアントのデータを示しています。

[unknown] cdl# cdl show status    
message params: {cmd:status mode:cli dbName:session sessionIn:{mapId:0 limit:10000 filters:[]}}
site {
    system-id 1
    cluster-id 1
    db-endpoint {
        state STARTED
    }
    slot {
        map-id 1
        instance-id 2
        records 100
        capacity 1000000
        state STARTED
    }
    slot {
        map-id 1
        instance-id 1
        records 100
        capacity 1000000
        state STARTED
    }
    index {
        map-id 1
        instance-id 2
        records 500
        capacity 2500000
        state ONLINE
    }
    index {
        map-id 1
        instance-id 1
        records 500
        capacity 2500000
        state ONLINE
    }
}
[unknown] cdl#