cnSGW-C は、UDP プロキシの高可用性（HA）をサポートしています。UDP プロキシの HA モデルは、キープアライブ仮想 IP の概念に基づいています。

UDP プロキシ冗長性に関する情報については、「ポッドとサービスの参考資料」章の「UDP プロキシの高可用性」セクションを参照してください。

ここでは、cnSGW-C ポッドとそのマイクロサービスの展開について説明します。

次の図は、cnSGW-C における 6 つの VM の導入モデルを示しています。

このモデルでは、ポッドは VM ペアに展開されます。各プロトコルポッド（rest-ep、protocol-ep、gtp-ep など）に対して 2 つのレプリカを使用できます。各プロトコル VM に 1 つのインスタンスが展開されます。

同様に、サービスポッドとセッションポッドは、サービス VM とセッション VM の両方に均等に分散されます。このような分散は、VM にラベルを付け、ポッドのスケジューリング中に K8 アフィニティルールとアンチアフィニティルールを実装することによって制御されます。

このモデルにより、VM の再起動シナリオ中に、各 ポッドタイプの少なくとも 50% のレプリカがユーザーシグナリングの処理に使用可能になります。

ポッドのグレースフル再起動により、ポッドは進行中の処理を 30 秒以内に完了できます。ポッドの突然の再起動は、PDU セッションに影響を与えずに、進行中のトランザクションに影響を与えます。

次に、VM のラベル付けとレプリカの設定例を示します。

k8 label protocol-layer key smi.cisco.com/node-type value smf-proto
exit
k8 label service-layer key vm-type value smf-svc
exit
k8 label cdl-layer key smi.cisco.com/node-type value smf-cdl
exit
k8 label oam-layer key smi.cisco.com/node-type value oam
exit

endpoint pfcp
 replicas 1
 nodes    2
exit
endpoint service
 replicas 1
 nodes    2
exit
endpoint protocol
 replicas 1
 nodes    2
 vip-ip 209.165.201.28
exit
endpoint sbi
 replicas 1
 nodes    2

構成を確認するには、次の show コマンドを使用します。

show running-config instance instance-id instance_id endpoint 

以下は、この show コマンドの出力例です。

show running-config instance instance-id 1 endpoint 
instance instance-id 1
 endpoint nodemgr
  replicas 1
  nodes    2
 exit
 endpoint gtp
  replicas 1
  vip-ip 209.165.201.29
 exit
 endpoint pfcp
  replicas                2
  enable-cpu-optimization true
  interface n4
   heartbeat
    interval               0
    retransmission-timeout 3
    max-retransmissions    5
   exit
  exit
 exit
 endpoint service
  replicas 2
 exit
 endpoint protocol
  replicas 1
  vip-ip 209.165.201.29
  end 

このコマンド出力には、エンドポイント名、ポッドレプリカ、ノードなど、複数のエンドポイントに関連する構成が表示されます。

アクティブ-アクティブモード

• ラック間の展開は、隣接する NF に対して透過的です。

• ラック間の展開には CCG 機能の 2 つのインスタンスが含まれ、各インスタンスは一連のインターフェイス IP で識別されます。

• 各インスタンスは一連のセッションをサポートし、セッションの一貫性のために同じ IP を使用し続けます。

• 特定の期間において、1 つの CCG インスタンスは一方のラックでのみプライマリとして動作し、もう一方のラックではスタンバイとして動作します。

• CCG インスタンスに関連付けられている一連のインターフェイス IP は、インスタンスのプライマリラックに動的にルーティングされます。

cnSGW-C は、データがプライマリからスタンバイインスタンスに複製されるプライマリ/スタンバイ冗長性をサポートします。通常の動作では、プライマリインスタンスがサービスを提供します。プライマリインスタンスで障害が発生すると、スタンバイインスタンスがプライマリになり、動作を引き継ぎます。ラック間の冗長性を実現するために、2 つのプライマリ/スタンバイペアを設定できます。この場合は各ラックがアクティブにトラフィックを処理し、スタンバイ側がリモートラックのバックアップとして機能します。

アクティブ-アクティブのラック間冗長性展開で、同じデータセンターに 2 つのラックがあるとします（ラック 1 と ラック 2）。すべての NF がインスタンス 1 とインスタンス 2 に到達しようとしています。

NF の場合、両方のインスタンスがアクティブになります。しかし実際には、インスタンス 1 とインスタンス 2 はラックにまたがって配置されます。

ラック 1 にはインスタンス 1 とインスタンス 2 があります。トリガー前のシナリオでは、インスタンス 1 はローカルでプライマリとして機能し、インスタンス 2 はスタンバイモードになります。

ラック 2 にもインスタンス 1 とインスタンス 2 があります。トリガー前のシナリオでは、インスタンス 2 はローカルでプライマリとして機能し、インスタンス 1 はスタンバイモードになります。

ラック 1 に障害が発生すると、トラフィックはラック 2 に移動します。ラック 2 では、インスタンス 1 とインスタンス 2 の両方がプライマリとして機能します。

この設定は、複数ラックのラック間冗長性構成を提供するために必要です。インスタンス ID を使用して、ラックごとにエンドポイントを構成する必要があります。

構成例 1

以下は、1 つのインスタンスにおけるエンドポイント VIP 構成の構成例です。

config 
  instance instance-id gr_instanceId 
    endpoint endpoint_name 
        vip-ip vip_ip_address 
  exit 
exit 

例：

config
instance instance-id 1
 endpoint sbi
  vip-ip 209.165.201.21
 exit
exit

構成例 2

次に、インスタンスのシステム ID、クラスタ ID、スライス名に関する情報を提供する構成例を示します。

config 
  instances instance instance_id 
   system-id system_id 
   cluster-id cluster_id 
   slice-name cdl_slice_name 
  exit 
exit 

例：

config
 instances instance 1
  system-id sgw
  cluster-id sgw
  slice-name 1
 exit
exit

（注）	インスタンスの system-id、cluster-id、および展開の app-name、cluster-name に同じ値を使用することをお勧めします。

ローカルラックとリモートラックごとに 2 つのインスタンスのみを構成でき、対応するエンドポイントをインスタンス化できます。

ローカルインスタンス識別子は、ラックが冗長かどうかに関係なく、ローカルラックの識別子です。

ローカルインスタンス識別子の設定

ローカルインスタンスは、 local-instance コマンドを使用して構成されます。

local-instance instance 1

エンドポイント構成は、各一意のインスタンス識別子で指定されたインスタンスの下にある必要があります。

エンドポイントの構成例

次の構成例を参照してください。

（注）	次の例では、インスタンス識別子「1」がローカルインスタンス識別子であり、その下に構成されたエンドポイントはローカルサイトに属しています。 必要に応じて、リモートラックインスタンス識別子「2」をラックに属するエンドポイントに構成できます。

instance instance-id 1
 endpoint li
  replicas 1
  nodes    2
  vip-ip 209.165.201.6
  vip-ip 209.165.201.13
 exit
 endpoint gtp
  replicas 1
  nodes    2
  retransmission timeout 5 max-retry 4
  vip-ip 209.165.201.6
  vip-ip 209.165.201.4
  interface s5
   echo interval          60
   echo retransmission-timeout 5
   echo max-retransmissions 4
  exit
  interface s2b
   echo interval 60
   echo retransmission-timeout 5
   echo max-retransmissions 4
  exit
 exit
exit
instance instance-id 2
 endpoint li
  replicas 1
  nodes    2
  vip-ip 209.165.201.6
  vip-ip 209.165.201.13
 exit
exit
endpoint gtp
  replicas 1
  nodes    2
  retransmission timeout 5 max-retry 4
  vip-ip 209.165.201.6
  vip-ip 209.165.201.5
  interface s5
   echo interval 60
   echo retransmission-timeout 5
   echo max-retransmissions 4
  exit
  interface s2b
   echo interval 60
   echo retransmission-timeout 5
   echo max-retransmissions 4
  exit
 exit
exit

ローカルおよびリモートインスタンスに対応する PGW FQDN のインスタンスを追加します。

例

次に、構成例を示します。

（注）	次の例では、instance-id「1」がローカルインスタンス ID であり、その下に構成された cnSGW-C プロファイルがローカルラックに属しています。 必要に応じて、リモートラック インスタンス ID「2」をラック間に属する FQDN に構成できます。

profile sgw sgw1
locality LOC1
instances 1 fqdn cisco.com.apn.epc.mnc456.mcc123
instances 2 fqdn cisco.com.apn.epc.mnc567.mcc123

エンドポイントの設定は、cnSGW-C にのみ必要です。

例

次に、設定例を示します。

（注）	次の例では、instance-id「1」がローカルインスタンス ID で、その下に設定されたエンドポイントはローカルサイトに属しています。 必要に応じて、リモートサイト instance-id「2」を地理的サイトに属するエンドポイントに設定できます。

instance instance-id 1
 endpoint nodemgr
  replicas 1
  nodes    1
 exit
 endpoint gtp
  replicas 1
  vip-ip 209.165.201.10
  interface s5e
   vip-ip 209.165.201.29
  exit
  interface s11
   vip-ip 209.165.201.29
  exit
 exit
 endpoint pfcp
  replicas 1
  interface sxa
   heartbeat
    interval               0
    retransmission-timeout 5
    max-retransmissions    3
   exit
  exit
exit
 endpoint service
  replicas 1
 exit
 endpoint protocol
  replicas 1
  vip-ip 209.165.201.29
  interface sxa
   vip-ip 209.165.201.29
  exit
 exit
 endpoint sgw-service
  replicas 1
 exit
exit
instance instance-id 2
 endpoint nodemgr
  replicas 1
  nodes    1
 exit
 endpoint gtp
  replicas 1
  vip-ip 209.165.202.150
  interface s5e
   vip-ip 209.165.201.27
  exit
  interface s11
   vip-ip 209.165.201.27
  exit
 exit
 endpoint pfcp
  replicas 1
  interface sxa
   heartbeat
    interval               0
    retransmission-timeout 5
    max-retransmissions    3
   exit
  exit
exit
 endpoint service
  replicas 1
 exit
 endpoint protocol
  replicas 1
  vip-ip 209.165.201.27
  interface sxa
   vip-ip 209.165.201.27
  exit
 exit
 endpoint sgw-service
  replicas 1
 exit
exit

ここでは、BGP を使用したダイナミックルーティングの設定方法について説明します。

AS と BGP ルータの IP アドレスの設定

BGP ルータの AS と IP アドレスを設定するには、次のコマンドを使用します。

config 
   router bgp local_as_number 
   exit 
exit 

注：

• router bgp local_as_number ：BGP ルータの AS の ID 番号を指定します。

  ラック間冗長性展開では、2 つの自律システム（AS）を設定する必要があります。

  • リーフとスパイン用に 1 つの AS。

  • 両方のラックの第 2 AS：Rack-1 と Rack-2。

BGP サービスリスニング IP アドレスの設定

BGP サービスリスニング IP アドレスを設定するには、次のコマンドを使用します。

config 
   router bgp local_as_number 
      interface interface_name 
   exit 
exit 

注：

• router bgp local_as_number ：BGP ルータの AS の ID 番号を指定します。

• interface interface_name ：インターフェイスの名前を指定します。

BGP ネイバーの設定

BGP ネイバーを設定するには、次のコマンドを使用します。

config 
   router bgp local_as_number 
      interface interface_name 
      neighbor neighbor_ip_address remote-as as_number 
   exit 
exit 

注：

• router bgp local_as_number ：BGP ルータの AS の ID 番号を指定します。

• interface interface_name ：インターフェイスの名前を指定します。

• neighbor neighbor_ip_address ：ネイバー BGP ルータの IP アドレスを指定します。

• remote-as as_number ：AS の ID 番号を指定します。

ボンディング インターフェイスの設定

インターフェイスに関連するボンディング インターフェイスを設定するには、次のコマンドを使用します。

config 
   router bgp local_as_number 
      interface interface_name 
      bondingInterface interface_name 
   exit 
exit 

注：

• router bgp local_as_number ：BGP ルータの AS の ID 番号を指定します。

• interface interface_name ：インターフェイスの名前を指定します。

• bondingInterface interface_name ：インターフェイスに関連するボンディング インターフェイスを指定します。ボンディング インターフェイスがアクティブである場合、BGP は、より低い MED 値を提供することで、インターフェイスサービスに高いプリファレンスを与えます。

デフォルトルートの学習の設定

システム上に特定のルートを設定し、すべてのルートをサポートする必要があるユーザーは、learnDefaultRoute を true に設定する必要があります。

（注）	この設定は任意です。

デフォルトルートの学習を設定するには、次のコマンドを使用します。

config 
   router bgp local_as_number 
      learnDefaultRoute true/false 
   exit 
exit 

注：

• router bgp local_as_number ：BGP ルータの AS の ID 番号を指定します。

• learnDefaultRoute true/false ：learnDefaultRoute パラメータを有効または無効にするオプションを指定します。true に設定すると、BGP はデフォルトルートを学習して、カーネルスペースに追加します。デフォルトは False です。

BGP ポートの設定

BGP サービスのポート番号を設定するには、次のコマンドを使用します。

config 
   router bgp local_as_number 
      loopbackPort port_number 
   exit 
exit 

注：

• router bgp local_as_number ：BGP ルータの AS の ID 番号を指定します。

• loopbackPort port_number ：BGP サービスのポート番号を指定します。デフォルト値は 179 です。

ポリシーの追加

BGP スピーカーポッドは、ネイバーから多くのルート情報を学習しますが、発信トラフィックのサポートに使用されるルートはごく一部のルートです。これは、cnSGW-C が外部の AMF/PCF に情報を送信している場合、出力トラフィックの処理にのみ必要です。ルートは、BGP スピーカーでインポートポリシーを設定することでフィルタリングされ、学習したルートをプロトコルポッドに送信するために使用されます。

ポリシー追加用のサンプル CLI コードと、各パラメータに対応する説明を以下に示します。

$bgp policy <policy_Name> ip-prefix 209.165.200.225 subnet 16 masklength-range 21..24 as-path-set “^65100”

この設定は、展開内の BGP スピーカーポッドの数を制御します。BGP スピーカーは、両方のラックからの着信トラフィックのサービス IP 情報をアドバタイズします。

（注）	BGP ピアリングには、BGP スピーカーポッドで非結合インターフェイスを使用します。 Proto ノードごとの BGP ピアリングは、2 つの BGP ルータ/リーフのみでサポートされます。2 つの Proto ノードを考慮すると、最大 4 つの BGP ネイバーシップを設定できます。

instance instance-id  instance_id endpoint bgpspeaker interface { bgp | bfd } internal base-port start base_port_number 

config 
instance instance-id instance_id 
 endpoint bgpspeaker 
   replicas replica_id 
   nodes node_id 
   interface bgp 
     internal base-port start base_port_number  
   exit 
   interface bfd 
     internal base-port start base_port_number 
  exit 
exit 

注：

• instance instance-id instance_id ：GR インスタンス ID を指定します。

• base_port_number ：論理 NF が設定されている場合にのみ、ポート範囲を指定します。この範囲は、展開によって異なります。

例

次に、設定例を示します。

instance instance-id 1
endpoint bgpspeaker
   replicas 1
   nodes    2
   interface bgp
     internal base-port start {24000}
   exit
   interface bfd
     internal base-port start {25000}
 exit

次のセクションでは、IPAM の構成例を示します。

cnSGW-C-1 の例

cnSGW-C-1 の構成例を次に示します。

ipam
 instance 1
  address-pool pool-1
  vrf-name ISP
   tags
   dnn dnn-1
  exit
  ipv4
    address-range 209.165.201.1 209.165.201.31
 exit
instance 2
 address-pool pool-2
  vrf-name ISP
  tags
   dnn dnn-2
  exit
  ipv4
    address-range 209.165.202.129 209.165.202.159
 exit
exit

cnSGW-C-2 の例

cnSGW-C-2 の構成例を次に示します。

ipam
 instance 1
 address-pool pool-1
  vrf-name ISP
  tags
   dnn dnn-1
  exit
  ipv4
    address-range 209.165.201.1 209.165.201.31
 exit
 instance 2
 address-pool pool-2
  vrf-name ISP
   tags
   dnn dnn-2
  exit
  ipv4
    address-range 209.165.202.129 209.165.202.159
 exit
exit

エンドポイントは、インスタンスの下に設定する必要があります。各ラックには 2 つの地理的冗長性ポッドが必要です。また、ETCD/CachePod レプリケーショのために、内部および外部の地理的インターフェイスに VIP を設定する必要があります。

instance instance-id  instance_id endpoint geo interface { geo-internal | geo-external } vip-ip { vip_ip_address } vip-port { vip_port_number }
 

config 
instance instance-id instance_id 
 endpoint geo 
  replicas replica_id 
  nodes node_id 
  internal base-port start base_port_number 
  interface geo-internal 
   vip-ip vip_ip_address vip-port vip_port_number 
  exit 
  interface geo-external 
   vip-ip vip_ip_address vip-port vip_port_number 
  exit 
exit 
exit 

注：

• instance instance-id instance_id ：GR インスタンス ID を指定します。1 つのインスタンス ID はローカルラック用、もう 1 つは別のラック用です。

• vip-ip vip_ip_address ：内部/外部の地理的インターフェイスの VIP IP アドレスを指定します。

• vip-port vip_port_number ：VIP ポート番号を指定します。

• internal base-port start base_port_number ：論理 NF が設定されている場合にのみ、ポート範囲を指定します。

例

次に、設定例を示します。

instance instance-id 1
endpoint geo
  replicas 1
  nodes 2
  internal base-port start 25000
  interface geo-internal
   vip-ip 209.165.201.8 vip-port 7001
  exit
  interface geo-external
   vip-ip 209.165.201.8 vip-port 7002
  exit
exit

ラック間セットアップでポッドモニタリングおよびフェールオーバーしきい値を設定するには、次の設定例を使用します。Geo ポッドは、設定されたポッド名をモニターします。

config 
 geomonitor 
  podmonitor pods pod_name 
   retryCount value 
   retryInterval interval_value 
   retryFailOverInterval failover_interval 
   failedReplicaPercent percent_value 
  exit 
 exit 

注：

• pods pod_name ：モニター対象のポッドの名前を指定します。たとえば、Cache-pod、rest-ep などです。

• retryCount value ：ポッドが ping に失敗した場合に、ポッドがダウンとしてマークされるまで再試行する再試行カウンタ値を指定します。1 〜 10 の範囲の整数で指定する必要があります。

• retryInterval interval_value ：ポッドが ping に成功した場合の再試行間隔をミリ秒単位で指定します。200 ～ 10000 の範囲の整数で指定する必要があります。

• retryFailOverInterval failover_interval ：ポッドが ping に失敗した場合の再試行間隔をミリ秒単位で指定します。200 ～ 10000 の範囲の整数で指定する必要があります。

• failedReplicaPercent percent_value ：ラック間冗長性フェールオーバーがトリガーされるまでの、失敗したレプリカのパーセント値を指定します。10 ～ 100 の範囲の整数で指定する必要があります。

設定例

次に、設定例を示します。

geomonitor podmonitor pods cache-pod
 retryCount 3
 retryInterval 5
 retryFailOverInterval 1
 failedReplicaPercent 40
exit

リモート クラスタ モニタリングは、ロール（リモートラックが STANDBY_ERROR 状態の場合はセルフプライマリになる）を自動修正して、トラフィックのトラフィックフローが中断されないようにします。ただし、このロールの自動修正は、特定のロールに対してのみ実行されます。

この機能を設定するには、次の設定例を使用します。

config 
    geomonitor 
        remoteclustermonitor 
            retryCount value 
            retryInterval interval_value 
            end 

注：

• retryCount value ：現在のラックを PRIMARY にする前の再試行回数を指定します。1 〜 10 の範囲の整数で指定する必要があります。デフォルト値は 3 です。

• retryInterval interval_value ：リモートラックのステータスが取得されるまでの再試行間隔をミリ秒単位で指定します。200 ～ 50000 の範囲の整数で指定する必要があります。デフォルト値は 3000 です。

設定例

次に設定例を示します。

geomonitor remoteclustermonitor
retryCount 3
retryInterval 3000

次のコマンドを使用して、トラフィックをモニターします。

config 
 geomonitor 
  trafficMonitor 
   thresholdCount value 
   thresholdInterval interval_value 
  exit 
 exit 

注：

• thresholdCount value ：スタンバイインスタンスの受信コール数を指定します。0 〜 10000 の範囲の整数で指定する必要があります。デフォルト値は 0 です。UDP プロキシと REST-EP の両方をカウンタ値と見なす必要があります。

• thresholdInterval interval_value ：しきい値カウント値に達するまでの最長時間をミリ秒単位で指定します。100 〜 10000 の範囲の整数で指定する必要があります。デフォルト値は 3000 です。

設定例

次に設定例を示します。

geomonitor trafficmonitor
thresholdCount 3
thresholdInterval 3000

CDL GR を展開する前に、ユーザーは次を構成する必要があります。

• CDL セッションデータベースを設定し、基本設定を定義します。

• CDL 用の Kafka を設定します。

• CDL 用の Zookeeper を設定します。

CDL では、既存の GR 関連パラメータとともに、すべてのラックで機能フラグを使用して GR インスタンス認識を有効にする必要があります。また、この機能をすべてのラックで機能させるには、システム ID からスライス名へのマッピングも提供する必要があります。

CDL には Geo レプリケーション（GR）フェールオーバー通知も用意されていているため、セッションデータのタイマーの期限切れ、および現在アクティブなラックへの一括通知を通知できます。CDL は GR フェールオーバー通知のために、App-Infra を介してボーダー ゲートウェイ プロトコル（BGP）を使用します。

CDL は両方の GR ラックのキー値を登録します。登録したキー値に変更があると、App-Infra は CDL に通知を送信します。キー値は、CDL システム ID または GR インスタンスの状態を示します。GR インスタンスは、 キーの CDL システム ID または GR インスタンス ID を使用して CDL スライスにマッピングされます。

システム ID は両方のラックで必須です。NF 構成の GR インスタンス ID が CDL システム ID と一致している必要があります。

CDL には、インスタンス固有のデータスライスがあります。また、ユーザーは起動時にインスタンス固有のスライス情報を設定できます。

• CDL は、有効期限切れ時またはアクティブなスライスからの一括通知要求時にデータを通知します。

• CDL は、app-infra memory-cache からの通知に基づいてアクティブインスタンスを決定します。

• CDL スライスは、異なる種類のデータを保存する CDL インスタンス内のパーティションです。この場合、NF はデータの別のインスタンスを保存します。

（注）	CDL スライス名は、GR で設定されているスライス名と一致する必要があります。

GR ロールを切り替えるには、プライマリラックでコマンドを開始し（たとえば、PRIMARY ロールから STANDBY のみ）、次のコマンドを使用します。

geo switch-role { role primary | standby  instance-id gr_instanceId [ failback-interval  failback_interval ] } 

注：

• role role ：特定のラックに新しいロールを指定します。

  ロールは、primary または standby です。特定の GR インスタンス ID のプライマリロールから手動スイッチオーバーをトリガーする必要があります。

• instance-id gr_instanceId ：GR インスタンス ID を指定します

• failback-interval は、リリース間のアップグレードの下位互換性を提供するオプションのコマンドです。failback-interval の推奨値は 0 です。

重要	geo switch-role コマンドは、特定のインスタンス ID について、あるラックから別のラックへの手動フェールオーバーをトリガーします。フェールオーバーをトリガーするラックが、PRIMARY ロールから STANDBY_ERROR ロールに変更されます。その間、フェールオーバーをトリガーするラックは、別のラックにフェールオーバー（GR トリガー）メッセージを送信します。フェールオーバーメッセージを受信した他のラックは、STANDBY ロールから PRIMARY ロールに変更されます。

GR インスタンスのロールをリセットする（たとえば STANDBY_ERROR のロールから STANDBY、PRIMARY へ）には、次のコマンド例を使用します。

geo reset-role role role instance-id gr_instanceId 

注：

• role role ：指定のラックに新しいロールを指定します。

  ロールは PRIMARY または STANDBYです。

• instance-id gr_instanceId ：GR インスタンス ID を指定します。

重要	geo reset-role コマンドは、ローカルラックの特定のインスタンスでロールの変更をトリガーします。リモートラックは、同じコマンドのメッセージを受信しません。特定のインスタンス ID のロールを STANDBY_ERROR から STANDBY に、および STANDBY から PRIMARYに変更することのみが可能です。別のロールの変更はできません。

ここでは、問題のデバッグに役立つ show/clear コマンドについて説明します。

サブスクライバのメッセージをキャプチャするには（GR インスタンス対応）、次のコマンドを使用します。

（注）	2021.02 以降のリリースでは、namespace キーワードは廃止され、nf-service キーワードに置き換えられました。

注：

例

次に、設定例を示します。

monitor subscriber imsi 123456789 gr-instance 1
supi: imsi-123456789
captureDuration: 300
enableInternalMsg: false
enableTxnLog: false
namespace(deprecated. Use nf-service instead.): none
nf-service: none
gr-instance: 1
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   295  100    98  100   197  10888  21888 --:--:-- --:--:-- --:--:-- 29500
Command: --header Content-type:application/json --request POST --data 
{"commandname":"mon_sub","parameters":{"supi":"imsi-123456789","duration":300,
"enableTxnLog":false,"enableInternalMsg":false,"action":"start","namespace":"none",
"nf-service":"none","grInstance":1}} http://oam-pod:8879/commands
Result start mon_sub, fileName ->logs/monsublogs/none.imsi-123456789_TS_2021-04-09T09:59:59.964148895.txt
Starting to tail the monsub messages from file: logs/monsublogs/none.imsi-123456789_TS_2021-04-09T09:59:59.964148895.txt
Defaulting container name to oam-pod.
Use 'kubectl describe pod/oam-pod-0 -n smf' to see all the containers in this pod.

異なるインターフェイスでパケットをキャプチャするには（gr インスタンス対応）、次のコマンドを使用します。

monitor protocol { interface interface_name [ capture-duration duration  | gr-instancegr_instance | pcacp yes | | ] | list [ | ] }  

注：

• interface interface_name ：PCAP がキャプチャされるインターフェイス名を指定します。この CLI では、1 つの CLI コマンドで複数のインターフェイス名を設定できます。

• capture-duration duration ：pcap がキャプチャされる期間を秒単位で指定します。デフォルトは 300 秒（5 分）です。

• 構成されたインターフェイス名は show endpoint 、 CLI コマンドを使用して取得できます。

• pcap yes ：このオプションを構成すると、PCAP ファイルの生成が有効になります。デフォルトでは、このオプションは無効になっています。

• list ：プロトコルリストファイルをモニタリングします。

例

次に、設定例を示します。

monitor protocol interface sbi gr-instance 1
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   220  100    95  100   125   8636  11363 --:--:-- --:--:-- --:--:-- 20000
Command: --header Content-type:application/json --request POST --data 
{"commandname":"mon_pro","parameters":{"interface":"sbi","duration":300,"action":
"start","enable_pcap":false,"grInstance":1}} http://oam-pod:8879/commands
Result start mon_pro, fileName ->logs/monprologs/sessintfname_sbi_at_2021-04-30T05:26:22.712229347.txt
Starting to tail the monpro messages from file: logs/monprologs/sessintfname_sbi_at_2021-04-30T05:26:22.712229347.txt
Defaulting container name to oam-pod.
Use 'kubectl describe pod/oam-pod-0 -n cn' to see all of the containers in this pod.

GR 展開の場合、 ノードモニターポッドが自動的に開始されます。RRMA 手順中に、ノードがドレインおよび削除され、マルチコンピューティング障害が検出された場合、ノードモニターポッドは自動的にそのラックをシャットダウンします。

RMA（返品許可）の詳細については、『Ultra Cloud Core：サブスクライバ マイクロサービス インフラストラクチャ』 の 「SMI クラスタの RMA」セクションを参照してください。

RMA 手順を開始する前に、次の手順を実行してください。

1. geo switch-role role コマンドを使用して両方のインスタンスのロールを他方のラックに切り替え、RMA 対象のラックが両インスタンスともに STANDBY_ERROR ロールになっていることを確認します。

2. ノードモニターポッドを無効にします。

   1. daemonsets のバックアップを取ります。

      kubectl get daemonsets node-monitor -n cn -o yaml > node-monitor.yaml

   2. ノードモニターポッドを削除します。

      kubectl delete daemonsets node-monitor -n cn

3. RMA 手順に進みます。詳細については、リンクを参照してください：

4. RMA 手順が完了したら、ノードモニターポッドがすでに生成されているかどうかを確認します。

   kubectl get pods -n cn -o wide | grep node-monitor

   ノードモニターポッドが開始していない場合は、再起動します。

   kubectl create -f node-monitor.yaml

   （注）	node-monitor.yaml ファイルは、ステップ 2.aと同じです。

5. インスタンスのロールを適宜修正します。

（注）	以前の SMI バージョンと現在の SMI バージョンの両方の場合： mLOM カードなどのファームウェアを含む RMA の手順中にハードウェアコンポーネントを交換する場合、修理または交換したノードをクラスタに戻す前に HUU（ホスト アップグレード ユーティリティ）を実行して、コンポーネントがシステムと互換性があることを確認してからノードをサービスに同期させる必要があります。 RMA の一環として、クラスタからノードを削除し、それを製造元に返却する場合は、ハードウェアベンダーの指示に従ってデバイス上のすべてのデータを消去する必要があります。

次のセクションでは、GR セットアップの正常性チェックに関する情報を提供します。

• すべての重要なポッドは、ユーザートラフィックを処理できる良好な状態です。

  GR および CDL に関連するポッドが実行状態にあるかどうかを確認するには、次のコマンドを使用します。

  kubectl get pods -n cn-cn1 -o wide | grep georeplication-pod
  kubectl get pods -n cn-cn1 -o wide | grep cdl
  kubectl get pods -n cn-cn1 -o wide | grep mirror-maker

• キープアライブポッドは正常な状態になり、check-interface/check-port 用に構成されたすべての VIP をモニタリングします。

  次のコマンドを使用して、「smi-vips」名前空間のキープアライブポッドが「実行」状態であるかどうかを確認します。

  kubectl get pods -n smi-vips

• CDL に関連するポッドの正常性チェック：CDL DB エンドポイント、スロット、およびインデックスのステータスを確認します。システム ID 1 と 2 の両方で、すべてのが STARTED または ONLINE 状態になっている必要があります。

  cdl show status 
  message params: {cmd:status mode:cli dbName:session sessionIn:{mapId:0 limit:500 key: purgeOnEval:0 filters:[] nextEvalTsStart:0 nextEvalTsEnd:0 allReplicas:false maxDataSize:4096} sliceName:}
  db-endpoint {
      endpoint-site {
          system-id 1
          state STARTED
          total-sessions 4
          site-session-count 2
          total-reconciliation 0
          remote-connection-time 66h37m31.36054781s
          remote-connection-last-failure-time 2021-07-13 11:24:10.233825924 +0000 UTC
          slot-geo-replication-delay 2.025396ms
      }
      endpoint-site {
          system-id 2
          state STARTED
          total-sessions 4
          site-session-count 2
          total-reconciliation 0
          remote-connection-time 66h58m49.83449066s
          remote-connection-last-failure-time 2021-07-13 11:02:51.759971655 +0000 UTC
          slot-geo-replication-delay 1.561816ms
      }
  }
  slot {
      map {
          map-id 1
          instance {
              system-id 1
              instance-id 1
              records 4
              capacity 2500000
              state ONLINE
              avg-record-size-bytes 1
              up-time 89h38m37.335813523s
              sync-duration 9.298061ms
          }
          instance {
              system-id 1
              instance-id 2
              records 4
              capacity 2500000
              state ONLINE
              avg-record-size-bytes 1
              up-time 89h39m11.1268024s
              sync-duration 8.852556ms
          }
          instance {
              system-id 2
              instance-id 1
              records 4
              capacity 2500000
              state ONLINE
              avg-record-size-bytes 1
              up-time 89h28m38.274713022s
              sync-duration 8.37766ms
          }
          instance {
              system-id 2
              instance-id 2
              records 4
              capacity 2500000
              state ONLINE
              avg-record-size-bytes 1
              up-time 89h29m37.934345015s
              sync-duration 8.877442ms
          }
      }
  }
  index {
      map {
          map-id 1
          instance {
              system-id 1
              instance-id 1
              records 4
              capacity 60000000
              state ONLINE
              up-time 89h38m16.119032086s
              sync-duration 2.012281769s
              leader false
              geo-replication-delay 10.529821ms
          }
          instance {
              system-id 1
              instance-id 2
              records 4
              capacity 60000000
              state ONLINE
              up-time 89h39m8.47664588s
              sync-duration 2.011171261s
              leader true
              leader-time 89h38m53.761213379s
              geo-replication-delay 10.252683ms
          }
          instance {
              system-id 2
              instance-id 1
              records 4
              capacity 60000000
              state ONLINE
              up-time 89h28m29.5479133s
              sync-duration 2.012101957s
              leader false
              geo-replication-delay 15.974538ms
          }
          instance {
              system-id 2
              instance-id 2
              records 4
              capacity 60000000
              state ONLINE
              up-time 89h29m11.633496562s
              sync-duration 2.011566639s
              leader true
              leader-time 89h28m51.29928233s
              geo-replication-delay 16.213323ms
          }
      }
  }

• CDL レプリケーションステータス

  [CDL Replication Stats] Grafana ダッシュボードの [GRPC_Connections_to_RemoteSite] パネルのラック全体で、（各名前空間の）CDL EP セッションポッド間で 4 つの gRPC 接続が確立されているかどうかを確認します。両方のラックで Grafana をチェックします。

  

• Geo レプリケーション用のラック間の管理ポートステータス。

  [GR Statistics] Grafana ダッシュボードの [Periodic_Heartbeat_to_Remote_Site] パネルで、ラック全体の Geo レプリケーションポッド間のハートビートメッセージを確認します。

  

• ラック上の BGP/BFD リンクステータス

  BGP ピアとの隣接関係が確立されているかどうかを、[BGP, BFD Statistics] Grafana ダッシュボードの [BGP Peers] パネルで確立しているかどうかを確認します。

  

  BFD リンクが接続状態であるかどうかを、[BGP, BFD Statistics] Grafana ダッシュボードの [BFD Link Status] パネルで確認します。

  

• 各インスタンスのロールが正常な状態である

  各ラックのロールがどの時点においても STANDBY_ERROR 状態でないことを確認します。

  • アクティブ/スタンバイモデル：ロールは各ラックで次の状態である必要があります。

    Rack-1：

    show role instance-id 1
    result "PRIMARY"
    show role instance-id 2
    result "PRIMARY"

    Rack-2：

    show role instance-id 1
    result "STANDBY"
    show role instance-id 2
    result "STANDBY"

  • アクティブ/アクティブモデル：ロールは、各ラックで次の状態になっている必要があります。

    Rack-1：

    show role instance-id 1
    result "PRIMARY"
    show role instance-id 2
    result "STANDBY"

    Rack-2：

    show role instance-id 1
    result "STANDBY"
    show role instance-id 2
    result "PRIMARY"

Rack-1 上

1. Rack-1 の両方のインスタンスのロールが STANDBY_ERROR であることを確認します。

   show role instance-id 1
   result "STANDBY_ERROR"

   show role instance-id 2
   result "STANDBY_ERROR"

2. Rack-1 の両方のインスタンスで、STANDBY へのロールのリセットを開始します。このステップにより、ロールが STANDBY_ERROR/STANDBY_ERROR から STANDBY/STANDBY に移行します。

   geo reset-role instance-id 1 role standby
   geo reset-role instance-id 2 role standby

3. Rack-1 の両方のインスタンスのロールが STANDBY に移行したことを確認します。

   show role instance-id 1
   result "STANDBY"

   show role instance-id 2
   result "STANDBY"

4. フェールバック間隔を 30 秒にして、Rack-2 で instance-id 1 のロールの STANDBY への切り替えを開始します。このステップにより、Rack-2 のロールが PRIMARY/PRIMARY から STANDBY_ERROR/PRIMARY に、Rack-1 のロールが STANDBY/STANDBY から PRIMARY/STANDBY に移行します。

   geo switch-role instance-id 1 role standby [failback-interval 0]

5. Rack-2 の両方のインスタンスのロールが STANDBY_ERROR/PRIMARY であることを確認します。

   show role instance-id 1
   result "STANDBY_ERROR"

   show role instance-id 2
   result "PRIMARY"

6. Rack-1 の両方のインスタンスのロールが PRIMARY/STANDBY であることを確認します。

   show role instance-id 1
   result "PRIMARY"

   show role instance-id 2
   result "STANDBY"

7. Rack-2 の instance-id 1 で、STANDBY へのロールのリセットを開始します。このステップにより、Rack-2 のロールが STANDBY_ERROR/PRIMARY から STANDBY/PRIMARY に移行します。

   geo reset-role instance-id 1 role standby

8. Rack-2 のロールが STANDBY/PRIMARY であることを確認します。

   show role instance-id 1
   result "STANDBY"

   show role instance-id 2
   result "PRIMARY"

Rack-2 上

1. Rack-2 の両方のインスタンスのロールが STANDBY_ERROR であることを確認します。

   show role instance-id 1
   result "STANDBY_ERROR"

   show role instance-id 2
   result "STANDBY_ERROR"

2. Rack-2 の両方のインスタンスで、STANDBY へのロールのリセットを開始します。このステップにより、ロールが STANDBY_ERROR/STANDBY_ERROR から STANDBY/STANDBY に移行します。

   geo reset-role instance-id 1 role standby
   geo reset-role instance-id 2 role standby

3. Rack-2 の両方のインスタンスのロールが STANDBY に移行することを確認します。

   show role instance-id 1
   result "STANDBY"

   show role instance-id 2
   result "STANDBY"

4. Rack-1 の instance-id 2 で、STANDBY へのロールの切り替えを開始します。このステップにより、Rack-1 のロールが PRIMARY/PRIMARY から PRIMARY/STANDBY_ERROR に、Rack-2 のロールが STANDBY/STANDBY から STANDBY/PRIMARY に移行します。

   geo switch-role instance-id 2 role standby [failback-interval 0]

5. Rack-1 のインスタンスのロールが PRIMARY/STANDBY_ERROR モードであることを確認します。

   show role instance-id 1
   result "PRIMARY"

   show role instance-id 2
   result "STANDBY_ERROR"

6. Rack-2 のインスタンスのロールが STANDBY/PRIMARY モードであることを確認します。

   show role instance-id 1
   result "STANDBY"

   show role instance-id 2
   result "PRIMARY"

7. Rack-1 の instance-id 2 で、STANDBY へのロールのリセットを開始します。このステップにより、Rack-1 のロールが PRIMARY/STANDBY_ERROR から PRIMARY/STANDBY に移行します。

   geo reset-role instance-id 2 role standby

8. Rack-1 のインスタンスのロールが PRIMARY/STANDBY であることを確認します。

   show role instance-id 1
   result "PRIMARY"

   show role instance-id 2
   result "STANDBY"

次の項では、KPI について説明します。

ETCD/Cachepod 複製 KPI

次の表に、ETCD/Cachepod 複製 KPI のリストを記載します。

地理的なロール変更拒否の KPI

次の表に、地理的なロール変更拒否の KPI のリストを記載します。

モニタリング KPI

次の表に、モニタリング KPI のリストを記載します。

BFD KPI

次の表に、BFD KPI のリストを記載します。

クロスラックルーティング BFD インターフェイスのモニタリング

ローカル インターフェイス モニタリング

GR インスタンス情報

Geo メンテナンスモード

次のセクションでは、GR 固有のバルク統計情報について詳しく説明します。

bulk-stats query GR-BGP-Incoming-Failed-Routes
 expression "sum(bgp_incoming_failedrouterequest_total) by (namespace, interface, service_IP, next_hop, instance_id)"
 labels     [ instance_id interface next_hop service_IP ]
 alias      gr-bgp-routes-in
exit
bulk-stats query GR-Geo-Monitoring-Failure
 expression "sum(geo_monitoring_total{ControlActionNameType=~'MonitorPod|RemoteMsgHeartbeat|
RemoteMsgGetSiteStatus|RemoteSiteRoleMonitoring|RemoteClusterPodFailure|RemoteMsgNotifyFailover|
RemoteMsgNotifyPrepareFailover|MonitorVip',status!~'success|monitoring.*'}) by (namespace, 
AdminNode, ControlActionType, ControlActionNameType,  pod, status, status_code)"
 labels     [ pod AdminNode ControlActionNameType status status_code ]
 alias      gr-geo-monitoring-failure
exit
bulk-stats query GR-Geo-Monitoring-Success
 expression "sum(geo_monitoring_total{ControlActionNameType=~'MonitorPod|RemoteMsgHeartbeat|
RemoteMsgGetSiteStatus|RemoteSiteRoleMonitoring|RemoteClusterPodFailure|RemoteMsgNotifyFailover|
RemoteMsgNotifyPrepareFailover',status=~'success|monitoring.*'}) by (namespace, AdminNode, 
ControlActionType, ControlActionNameType,  pod, status)"
 labels     [ pod AdminNode ControlActionNameType status ]
 alias      gr-geo-monitoring
exit
bulk-stats query GR-Geo-Monitoring-Total
 expression "sum(geo_monitoring_total{ControlActionNameType=~'MonitorPod|RemoteMsgHeartbeat|
RemoteMsgGetSiteStatus|RemoteSiteRoleMonitoring|RemoteClusterPodFailure|RemoteMsgNotifyFailover
|RemoteMsgNotifyPrepareFailover|MonitorVip'}) 
by (namespace, AdminNode, ControlActionType, ControlActionNameType,  pod, status)"
 labels     [ pod AdminNode ControlActionNameType status ]
 alias      gr-geo-monitoring
exit
bulk-stats query GR-Geo-Replication-Failure
 expression "sum(geo_replication_total{ReplicationNode=~'CACHE_POD|ETCD|PEER',status!='success',
ReplicationRequestType='Response'}) by (namespace, ReplicationNode, ReplicationSyncType,
ReplicationReceiver,ReplicationRequestType,status,status_code)"
 labels     [ pod ReplicationNode ReplicationReceiver ReplicationRequestType ReplicationSyncType status status_code ]
 alias      gr-geo-replication-failure
exit
bulk-stats query GR-Geo-Replication-Success
 expression "sum(geo_replication_total{ReplicationNode=~'CACHE_POD|ETCD|PEER',
status='success',ReplicationRequestType='Response'}) by (namespace, ReplicationNode, 
ReplicationSyncType,ReplicationReceiver,ReplicationRequestType,status)"
 labels     [ pod ReplicationNode ReplicationReceiver ReplicationRequestType ReplicationSyncType status ]
 alias      gr-geo-replication-success
exit
bulk-stats query GR-Geo-Replication-Total
 expression "sum(geo_replication_total{ReplicationNode=~'CACHE_POD|ETCD|PEER'}) 
by (namespace, ReplicationNode, ReplicationSyncType,ReplicationReceiver,
ReplicationRequestType,pod)"
 labels     [ pod ReplicationNode ReplicationReceiver ReplicationRequestType ReplicationSyncType ]
 alias      gr-geo-replication-total
exit
bulk-stats query GR-Trigger-ResetRole-Api
 expression "sum(geo_monitoring_total{ControlActionNameType=~'TriggerGRApi|ResetRoleApi'}) 
by (namespace, AdminNode, ControlActionType, ControlActionNameType,  pod, status, status_code)"
 labels     [ pod AdminNode ControlActionNameType status status_code ]
 alias      gr-api
exit
bulk-stats query GR-CDL-Index-Replication
 expression "sum(consumer_kafka_records_total) by (pod, origin_instance_id)"
 labels     [ origin_instance_id pod ]
 alias      gr-cdl-index-replication
exit
bulk-stats query GR-CDL-Inter-Rack-Replications-Failures
 expression "sum(datastore_requests_total{local_request='0',errorCode!='0'}) by (operation,sliceName,errorCode)"
 labels     [ sliceName operation errorCode ]
 alias      gr-cdl-inter-rack-replications
exit
bulk-stats query GR-CDL-Inter-Rack-Replications-Success
 expression "sum(datastore_requests_total{local_request='0',errorCode='0'}) by (operation,sliceName,errorCode)"
 labels     [ sliceName operation errorCode ]
 alias      gr-cdl-inter-rack-replications
exit
bulk-stats query GR-CDL-Inter-Rack-Replications-Total
 expression "sum(datastore_requests_total{local_request='0'}) by (operation,sliceName,errorCode)"
 labels     [ sliceName operation errorCode ]
 alias      gr-cdl-inter-rack-replications
exit
bulk-stats query GR-CDL-Intra-Rack-Operations-Failures
 expression "sum(datastore_requests_total{local_request='1',errorCode!='0'}) by (operation,sliceName,errorCode)"
 labels     [ sliceName operation errorCode ]
 alias      gr-cdl-intra-rack-operations
exit
bulk-stats query GR-CDL-Intra-Rack-Operations-Success
 expression "sum(datastore_requests_total{local_request='1',errorCode='0'}) by (operation,sliceName,errorCode)"
 labels     [ sliceName operation errorCode ]
 alias      gr-cdl-intra-rack-operations
exit
bulk-stats query GR-CDL-Intra-Rack-Operations-Total
 expression "sum(datastore_requests_total{local_request='1'}) by (operation,sliceName,errorCode)"
 labels     [ errorCode operation sliceName ]
 alias      gr-cdl-intra-rack-operations
exit
bulk-stats query GR-CDL-Session-Count-Per-Slice
 expression sum(avg(db_records_total{namespace=~'$namespace',session_type='total'})by(systemId,sliceName))by(sliceName)
 labels     [ sliceName ]
 alias      gr-cdl-session-count-per-slice
exit
bulk-stats query GR-CDL-Session-Count-Per-System-ID
 expression sum(avg(db_records_total{namespace=~'$namespace',session_type='total'})
by(systemId,sliceName))by(systemId)
 labels     [ systemId ]
 alias      gr-cdl-session-count-per-system-id
exit
bulk-stats query GR-CDL-Slot-Records-Per-Slice
 expression "sum(slot_records_total{pod=~'.*',systemId!=''}) by (pod, sliceName)"
 labels     [ pod sliceName ]
 alias      gr-cdl-slot-records-per-slice
exit
bulk-stats query GR-CDL-Slot-Records-Per-System-ID
 expression "sum(slot_records_total{pod=~'.*',systemId!=''}) by (pod, systemId)"
 labels     [ pod systemId ]
 alias      gr-cdl-slot-records-per-system-id
exit
bulk-stats query GR-CDL-Total-Session-Count
 expression "sum(db_records_total{namespace=~'$namespace',session_type='total'}) by (systemId,sliceName)"
 labels     [ sliceName systemId ]
 alias      gr-cdl-total-session-count
exit

GR 関連の統計情報の詳細については、次を参照してください。

• cnSGW-C 統計情報では、gr_instance_id ラベルを使用して GR 固有の統計情報をフィルタリングできます。

  詳細については、「UCC サービング ゲートウェイ コントロール プレーンの機能 - メトリックリファレンス」を参照してください。

ここでは、GR アラートについて詳しく説明します。

BFD アラート

次の表に、interval-seconds が 60 に設定されているルールグループ BFD のアラートを示します。

GR アラート

次の表に、interval-seconds が 60 に設定されているルールグループ GR のアラートを示します。

CDL アラート

次の表に、interval-seconds が 60 に設定されているルールグループ CDL のアラートを示します。

cnSGW-C はメンテナンスモードフラグをサポートしており、GR セットアップのクラスタがインサービス（ローリングアップグレード）用にスケジュールされている場合に、クラスタへの影響を無効化できます。これは、他の従属クラスタがその役割やその他のアクティビティを、ターゲットのクラスタで問題なく実行できるようにするのに役立ちます。

メンテナンスモードフラグが true に設定されている場合、クラスタロールの変更およびラックに対する GR トリガーは、CLI ベースのフェールオーバーの場合にのみ許可されます。

実行中、すべてのモニタリングスレッドでフラグのランタイム値がチェックされ、メンテナンスモードフラグが true に設定されている場合は実行が保留されます。デフォルトでは、新規インストールの場合、フラグは false に設定されます。要件に基づいてメンテナンスモードを設定するには、次の設定を使用します。

config 
  geo maintenance mode { true | false } 
  end  

注：

• geo maintenance mode { true | false } ：メンテナンスモードを有効/無効にします。

  メンテナンスモードの値は、etcd に保存されます。

両方のクラスタを同時にメンテナンスできます。従属クラスタがすでにメンテナンス中の場合は、システムをメンテナンスモードに移行できます。メンテナンス作業を開始する前に、geo maintenance mode フラグの値を true に設定してください。メンテナンスが完了したら、システムの正常性を確認後、フラグを false にリセットします。

メンテナンスフラグが true に設定されている場合：

• すべてのモニタリングアクティビティが一時停止します。

• 従属クラスタは、ローカルの障害を検出してもフェールオーバーをトリガーできません。

• レプリケーション アクティビティはクラスタで続行されます。

• メンテナンスモードでは、サイトのインスタンスロールは暗黙的に変更されませんが、ロールの変更は geo switch-role role CLI コマンドを使用して可能です。

メンテナンス中のクラスタとの間で GR トリガーの送受信はできません。メンテナンス中のクラスタからは、CLI ベースのフェールオーバーのみがサポートされます。メンテナンスモードを無効にしたら、ポッドと VIP のモニタリング用の新しいデータから開始します。リモートクラスタには、NotifyMaintenanceActivity() [Operation 24] メッセージを使用してメンテナンスモード値が通知されます。

例

次に、設定例を示します。

geo maintenance mode true
result "success"

geo maintenance mode false
result "success"

メンテナンスモードのステータスの表示

メンテナンスモードのステータスを確認するには、次の show コマンドを使用します。

show geo maintenance mode
result "geo maintenance mode is disabled"