Cisco Common Data Layer

機能の概要と変更履歴

要約データ

表 1. 要約データ

該当製品または機能エリア

SMF

該当プラットフォーム

SMI

機能のデフォルト設定

無効：設定が必要

このリリースでの関連する変更点

N/A

関連資料

該当なし

更新履歴

表 2. マニュアルの変更履歴

改訂の詳細

リリース

失敗処理のサポートが追加されました。

2023.03.0

CDL データベース レコードのイベント トレース データの構成と検証に関する手順を追加しました。

2021.02.0

最初の導入。

2020.02.0 より前

SMF の Cisco Common Data Layer の Geo 冗長性

Common Data Layer（CDL）は、クラウドネイティブなすべてのアプリケーションに対応する、高性能の次世代キー値（KV）データ ストア レイヤです。これらのアプリケーションは、高可用性（HA）と Geo HA 機能を備えた状態管理として CDL を使用します。

この機能により、SMF で CDL の Geo 冗長（GR）バージョンをサポートできます。CDL エンドポイントポッドは、SMF アプリケーションから CDL に対する要求を受信するためのフロントエンドです。プライマリ CDL エンドポイントに障害が発生すると、SMF は次に評価の高いセカンダリ エンドポイントにデータベース サービス要求を送信します。次の評価対象エンドポイントが使用できない場合、SMF は、評価が最も高い後続のエンドポイントで操作を再試行します。

CDL から SMF への特定のエラーまたは障害が発生した場合、再試行メカニズムは、作成、検索、更新、および削除のリクエストに使用されます。再試行回数は SLA に従います。

再試行中に SMF が成功応答を受信すると、再試行は中止され、応答がアプリケーションに送信されます。

この機能により、SMF は中断のない N7 または Diameter メッセージ処理を提供します。

アーキテクチャ

次の図は、SMF サービスが CDL データストア エンドポイントにアクセスできない場合に発生するフェールオーバを示しています。

Figure 1. CDL データストア アーキテクチャ

このアーキテクチャとの関連性により、SMF Ops Center を介して CDL を構成できます。SMF は CDL に接続するときに、ローカル エンドポイントを使用します。

SMF での CDL の仕組み

SMF Ops Center を介して SMF で CDL が設定されると、SMF は複数の CDL データストア エンドポイントをサポートできるようになります。エンドポイントを設定するには、IP アドレス、ポートを指定し、各エンドポイントに評価を割り当てます。デフォルトでは、SMF はローカル エンドポイントを、最大の評価を持つプライマリ エンドポイントと見なします。SMF は、プライマリエンドポイントで CDL API オペレーションを実行します。このエンドポイントが使用できない場合、SMF は、次に最大評価のエンドポイントに操作をルーティングします。SMF は、設定されたすべてのセカンダリエンドポイントが使い果たされるまで、アクセス可能なセカンダリエンドポイントにフェールオーバーし続けます。エンドポイントが到達可能でも、エラーまたはタイムアウトで応答する場合、次に評価されたエンドポイントでクエリを再試行しません。

SMF がクラスタ内のどのエンドポイントにもアクセスできない場合、CDL 操作は「Datastore Unavailable」というエラーで失敗します。

次の表は、シナリオ、予想される動作、および CDL からの関連エラー応答を示しています。

Table 3. シナリオ、予想される動作、および CDL からのエラー応答

シナリオ

予期される動作

CDL からのエラー応答

すべてのポッドはアクティブかつ正常であり、CDL 操作をトリガーします。

CDL の作成、読み取り、更新、削除（CRUD）操作は、リトライされません。

N/A

CDL エンドポイント ポッドは、CDL 操作を再開し、トリガーします。

CDL CRUD 操作はリトライされます。

CDL はエラー コードとともに次のエラー応答を送信します。

  • ERROR_FROM_INDEXING [501]

  • ERROR_FROM_SLOT [502]

  • DATASTORE_EP_QUEUE_FULL [503]

  • MAX_CAPACITY_REACHED [507

コール フロー

ここでは、この機能に関連したコール フローについて説明します。

CDL エンドポイント障害のコール フロー

このセクションでは、SMF ローカル データ ストア エンドポイントの失敗のコール フローについて説明します。

Figure 2. CDL エンドポイント障害のコール フロー
Table 4. CDL エンドポイント障害コール フローの説明
ステップ 説明

1

AMF は、N11 インターフェイスを介して SMF REST エンドポイントに作成要求を送信します。

2

要求を受信した後、SMF REST エンドポイントは、SMF サービスに作成要求を転送します。

3

SMF サービスは、CDL エンドポイントに到達してセッション作成要求を送信しようとします。ただし、CDL エンドポイントは到達不能です。

4

要求の作成は保存されているセッションで評価され、SMF サービスがその要求を CDL エンドポイントに転送します。

5

コール要求が成功すると、SMF サービスは SMF REST エンドポイントに成功メッセージを通知します。

6

SMF REST エンドポイントが AMF に成功メッセージを転送します。

制限事項

SMF の CDL 構成には、次の制限があります：

  • SMF サービスでは、UNAVAILABLE などの gRPC エラーが発生した場合にのみコールの再ルーティングが試行されます。データストア エンドポイントが DEADLINE_EXCEEDED gRPC ステータス コードなどの実際の gRPC タイムアウトを返すエラーは確認しません。

  • SMF サービスは、インデックス作成やスロット障害など、データストアで発生した障害を解決しません。CDL レイヤはこれらの障害を解決する必要があり、必要に応じてリモートに API コールを送信します。

  • デフォルトでは、要求の最大再試行制限は 3 です。この制限に達すると、再試行は停止し、応答がアプリケーションに送信されます。

  • 再試行中に成功の応答メッセージを受信すると、再試行は中止され、応答がアプリケーションに送信されます。

SMF Ops センターによる CDL の構成

SMF Ops センターを使用した CDL の構成には、次の手順が含まれます。

  1. CDL セッション データベースを構成して基本構成を定義する

  2. CDLでの Zookeeper の構成

CDL セッション データベースを構成して基本構成を定義する

CDL データベースコレクタを構成するには、次の手順を実行します：

手順

ステップ 1

CDL セッション データベースを設定するには、グローバル構成モードでシステム ID、ノード タイプ、Zookeeper レプリカ サーバー ID を定義します。

CLI コマンド 説明

範囲

デフォルト値

cdl system-id system_id

システムまたは Kubernetes クラスタの ID を指定します。

該当なし

1

cdl node-type node_type

ノード アフィニティを構成するための Kubernetes ノード ラベルを指定します。値は、文字列である必要があります。

0～64

session

cdl zookeeper replica zookeeper_replica_id

zookeeper レプリカ サーバーの ID を指定します。

該当なし

該当なし

ステップ 2

ログレベル、クラスタ、レプリカ、スロット、インデックス、およびスライス パラメータを構成して、CDL データストア セッションの基本構成を定義し、構成を保存します。

CLI コマンド 説明

範囲

デフォルト値

cdl logging default-log-level debug_level

cdl logging default-log-level debug_level ：デフォルトのログ レベルを指定します。

該当なし

該当なし

cluster-id cluster-id

cluster-id cluster-id ：Kubernetes クラスタの ID を指定します。 該当なし 1

endpoint replica num_replica

endpoint replica num_replica ：作成するレプリカの数を指定します。値は必ず整数にしてください。

num_replica ：値は 1 ～ 16 の範囲の整数である必要があります。

num_replica ：デフォルト値は 1 です。

slot { replica num_replica | map num_map/shards| write-factor write_factor }

  • replica num_replica ：作成するレプリカの数を指定します。

  • map num_map/shards ：スロット内のパーティション数を指定します。

  • write-factor write_factor ：正常な応答の前に書き込まれるコピーの数を指定します。

    （注）  

     

    値がレプリカ数以下であることを確認してください。

  • num_replica ：値は 1 ～ 16 の範囲の整数である必要があります。

  • num_map/shards ：値は、1 ～ 1024 の範囲の整数である必要があります。

  • write_factor ：値は 0 ～ 16 の範囲の整数である必要があります。

  • num_replica ：デフォルト値は 1 です。

  • num_map/shards ：デフォルト値は 1 です。

  • write_factor ：デフォルト値は 1 です。

slot notification { host host | port port | limit tps }

  • notification host host ：通知サーバーのホスト名または IP アドレスを指定します。

  • slot notification port port ：通知サーバーのポート番号を指定します。

  • slot notification limit tps ：1 秒あたりの通知上限を指定します。

NA

  • host ：デフォルト値は datastore-notification-ep です。

    .

  • port ：デフォルト値は 8890 です。

  • tps ：デフォルト値は 2000 です。

index { replica num_replica | map num_map/shards | write-factor write_factor }

  • replica num_replica ：作成するレプリカの数を指定します。

  • map num_map/shards ：スロット内のパーティション数を指定します。CDL の展開後は、この値を変更しないでください。

  • write-factor write_factor ：正常な応答の前に書き込まれるコピーの数を指定します。

  • num_replica ：値は 1 ～ 16 の範囲の整数である必要があります。

  • map num_map/shards ：値は、1 ～ 1024 の範囲の整数である必要があります。

  • write-factor write_factor ：値は 0 ～ 16 の範囲の整数である必要があります。

  • num_replica ：デフォルト値は 2 です。

  • num_map/shards ：デフォルト値は 1 です。

  • write_factor ：デフォルト値は 1 です。

slice-names cdl_slice_name slice-names cdl_slice_name ：CDL スライス名を指定します。値は、英数文字列である必要があります。 cdl_slice_name ：値は 0 ～ 16 の範囲の整数である必要があります。 NA

次のタスク

CDLでの Zookeeper の構成

CDLでの Zookeeper の構成

CDLでの Zookeeper の構成にはこれらのステップを使用します。

手順

ステップ 1

グローバル コンフィギュレーション モードで、Zookeeper データ ストレージのサイズをギガバイト単位で指定します。

cdl zookeeper data-storage-size data_storage_size_in_gb

例:

[smf] smf(config)# cdl zookeeper data-storage-size 20 GB

（注）  

 

デフォルト値は 20 GB です。この値には 1 ～ 65535 の範囲の整数を指定する必要があります。

ステップ 2

Zookeeper データ ログのストレージ サイズをギガバイト単位で指定します。

log-storage-size log_storage_size_in_gb

例:

[smf] smf(config-cdl-zookeeper)# log-storage-size 20 GB

（注）  

 

デフォルト値は 20 GB です。この値には 1 ～ 65535 の範囲の整数を指定する必要があります。

ステップ 3

zookeeper で作成するレプリカの数を指定します。

replica num_replicas

例:

[smf] smf(config-cdl-zookeeper)# replica 3

（注）  

 

デフォルト値は 3 です。1 ～ 16 の範囲の整数で指定する必要があります。

ステップ 4

JMX メトリックのステータスを指定します。

enable-JMX-metrics boolean_value

例:

[smf] smf(config-cdl-zookeeper-replica)# enable-JMX-metrics true

（注）  

 

デフォルト値は true です。値はブール値である必要があります。

ステップ 5

Zookeeper データの永続ストレージのステータスを指定し、構成を保存します。

enable-persistence boolean_value

例:

[smf] smf(config-cdl-zookeeper-replica)# enable-persistence false

（注）  

 

デフォルト値は false です。値はブール値である必要があります。

CDL セッション データベースの構成例

このセクションでは、HA 環境での CDL の構成例を示します。

config
cdl system-id system_id
cdl zookeeper replica num_zk_replica
cdl datastore session
 endpoint replica ep_replica
 index map index_shard_count
 slot replica slot_replica
 slot map slot_shard_count
 slice-names cdl_slice_name
exit

イベント トレース データの構成

このセクションでは、イベント トレース データを CDL データベース レコードに保存するように SMF を構成する方法について説明します。システム診断用の CDL データベース レコード内のイベント トレース データ ストレージを有効または無効にします。イベント トレース データは、サブスクライバのコール フローイベントを示します。

手順

ステップ 1

システム診断用に、グローバル コンフィギュレーション モードでのイベント トレース データの保存を有効にします。

system-diagnostics event-trace [ enable | disable ]

例:

[smf] smf(config)# system-diagnostics event-trace  enable

（注）  

 

event_trace_state を無効にすると、各 SMF データベース レコードに対して約 1 KB のデータベース ストレージを節約できます。

構成を保存してコミットします。

ステップ 2

[オプション（Optional）] show running-config system-diagnostics event-trace コマンドを使用して、サブスクリプションの変更が有効かどうかを確認します。

例:


 [smf] smf# show running-config system-diagnostics event-trace
 system-diagnostics event-trace enabled