ヘルスチェックを実行して、すべてのサービスが実行され、ノードが準備完了状態になっていることを確認します。

ヘルスチェックを実行するには、次の設定を使用します。

• マスターノードにログインし、次の設定を使用します。

  kubectl get pods -n smi 
  kubectl get nodes 
  kubectl get pod --all-namespaces -o wide 
  kubectl get pods -n cnsgw-wsp -o wide 
  kubectl get pods -n cee-wsp -o wide 
  kubectl get pods -n smi-vips -o wide 
  helm list 
  kubectl get pods -A | wc -l 
  

重要	続行する前に、すべてのサービスが実行されており、ノードが準備完了状態になっていることを確認してください。

バックアップ設定、ログ、および展開ファイルを作成するには、次の構成を使用します。

1. Ubuntu ユーザーとして SMI クラスタマネージャノードにログインします。

2. 展開用の新しいディレクトリを作成します。

   例：

   test@smicnsgw-cm01:~$ mkdir -p "temp_$(date +'%m%d%Y_T%H%M')" && cd "$_"

3. 新しく作成した展開ディレクトリに作業ファイルをバックアップします。

4. cnsgw 展開ファイルを解凍します。

   例：

   test@smi1cnsgw01-cm01:~/temp_08072019_T1651$ tar -xzvf cnsgw.2020.01.0-1.SPA.tgz
   ./
   ./cnsgw_REL_KEY-CCO_RELEASE.cer
   ./cisco_x509_verify_release.py
   ./cnsgw.2020.01.0-1.tar
   ./cnsgw.2020.01.0-1.tar.signature.SPA
   ./cnsgw.2020.01.0-1.tar.SPA.README
   

5. ダウンロードしたイメージを確認します。

   例：

   test@smi1cnsgw01-cm01:~/temp_08072019_T1651$ cat cnsgw.2020.01.0-1.tar.SPA.README

   重要	次のステップに進む前に、SPA.README ファイルに記載されている手順に従ってビルドを確認します。

Ops センターの設定をバックアップするには、次の設定を使用します。

1. Ubuntu ユーザーとして SMI クラスタマネージャノードにログインします。

2. 次の構成を使用して、SMI Ops センターの構成を /home/ubuntu/smiops.backup ファイルにバックアップします。

   ssh -p <port_number> admin@$(kubectl get svc -n smi | grep '.*netconf.*<port_number>' | awk '{ print $4 }') "show run | nomore" > smiops.backup_$(date +'%m%d%Y_T%H%M') 

3. 次の構成を使用して、CEE Ops センターの構成を /home/ubuntu/ceeops.backup ファイルにバックアップします。

   ssh admin@<cee-vip> "show run | nomore" > ceeops.backup_$(date +'%m%d%Y_T%H%M') 

4. 次の構成を使用して、cnSGW-C Ops センターの構成を /home/ubuntu/cnSGWops.backup ファイルにバックアップします。

   ssh admin@<cnSGW-vip> "show run | nomore" > cnSGWops.backup_$(date +'%m%d%Y_T%H%M') 

マスターノードから CEE および Ops Center の設定をバックアップするには、次の設定を使用します。

1. マスターノードに Ubuntu ユーザーとしてログインします。

2. 次の設定を使用して、構成ファイルをバックアップするためのディレクトリを作成します。

   mkdir backups_$(date +'%m%d%Y_T%H%M') && cd "$_" 

3. cnSGW-C Ops Center の設定をバックアップし、次の設定を使用してバックアップファイルの行数を確認します。

   ssh -p <port_number> admin@$(kubectl get svc -n $(kubectl get namespaces | grep -oP 'cnSGW-(\d+|\w+)') | grep <port_number> | awk '{ print $3 }') "show run | nomore" > cnSGWops.backup_$(date +'%m%d%Y_T%H%M') && wc -l cnSGWops.backup_$(date +'%m%d%Y_T%H%M') 

   例：

   ubuntu@pocnSGW-mas01:~/backups_09182019_T2141$ ssh -p 2024 admin@$(kubectl get svc -n $(kubectl get namespaces | grep -oP 'cnSGW-(\d+|\w+)') | grep <port_number> | awk '{ print $3 }') "show run | nomore" > cnSGWops.backup_$(date +'%m%d%Y_T%H%M') && wc -l cnSGWops.backup_$(date +'%m%d%Y_T%H%M')
   admin@<ipv4address>'s password: cnSGW-OPS-PASSWORD
   334 cnSGWops.backup
   

4. CEE Ops Center の設定をバックアップし、次の設定を使用してバックアップファイルの行数を確認します。

   ssh -p <port_number> admin@$(kubectl get svc -n $(kubectl get namespaces | grep -oP 'cee-(\d+|\w+)') | grep <port_number> | awk '{ print $3 }') "show run | nomore" > ceeops.backup_$(date +'%m%d%Y_T%H%M') && wc -l ceeops.backup_$(date +'%m%d%Y_T%H%M') 

   例：

   ubuntu@pocnSGW-mas01:~/backups_09182019_T2141$ ssh -p <port_number> admin@$(kubectl get svc -n $(kubectl get namespaces | grep -oP 'cee-(\d+|\w+)') | grep <port_number> | awk '{ print $3 }') "show run | nomore" > ceeops.backup_$(date +'%m%d%Y_T%H%M') && wc -l ceeops.backup_$(date +'%m%d%Y_T%H%M')
   admin@<ipv4address>'s password: CEE-OPS-PASSWORD
   233 ceeops.backup
   

5. 次の設定を使用して、SMI Cluster Manager からの SMI Ops Center のバックアップファイルをバックアップディレクトリに移動します。

   scp $(grep cm01 /etc/hosts | awk '{ print $1 }'):/home/ubuntu/smiops.backup_$(date +'%m%d%Y_T%H%M') . 

   例：

   ubuntu@pocnSGW-mas01:~/backups_09182019_T2141$ scp $(grep cm01 /etc/hosts | awk '{ print $1 }'):/home/ubuntu/smiops.backup_$(date +'%m%d%Y_T%H%M') .
   ubuntu@<ipv4address>'s password: SMI-CM-PASSWORD
   smiops.backup                                                       100% 9346    22.3MB/s   00:00                                                                            
   

6. バックアップファイルの行数を確認します。

   例：

   ubuntu@pocnSGW-mas01:~/backups_09182019_T2141$ wc -l *
     233 ceeops.backup
     334 cnSGWops.backup
     361 smiops.backup
     928 total
   

更新を開始する前に新しい cnSGW-C イメージをステージングするには、次の設定を使用します。

1. 新しい cnSGW-C イメージをダウンロードして確認します。

2. Ubuntu ユーザーとして SMI クラスタマネージャノードにログインします。

3. イメージを uploads ディレクトリにコピーします。

   sudo mv <cnSGW_new_image.tar> /data/software/uploads 

   （注）	SMI は、uploads ディレクトリに存在する新しいイメージを使用して更新します。

4. uploads ディレクトリから処理するために、イメージが SMI によって取得されているかどうかを確認します。

   sleep 30; ls /data/software/uploads 

   例：

   ubuntu@pocnSGW-cm01:~/temp_08072019_T1651$ sleep 30; ls /data/software/uploads
   ubuntu@pocnSGW-cm01:~/temp_08072019_T1651$
   

5. イメージが正常に取得され、処理されたかどうかを確認します。

   例：

   auser@unknown:$ sudo du -sh /data/software/packages/*
   1.6G	/data/software/packages/cee.2019.07
   5.3G	/data/software/packages/cnSGW.2019.08-04
   16K	/data/software/packages/sample
   

   （注）	SMI は、ステージングを完了するためにイメージを packages ディレクトリに正常に解凍する必要があります。

ピアポッドは特定のポッドのアップグレードや再起動を認識するため、そのポッドとの間のトランザクションが正常に処理されるようになります。

ここでは、サービスポッドでの着信および発信メッセージの処理について説明します。

着信メッセージ（Incoming Messages）

• アップグレード中、サービスポッドの状態は、トポロジの更新を介して他のポッドに伝達されます。セッションにアフィニティが存在しない場合、そのポッドは新しいメッセージの転送ポッドとして選択されません。

• セッションでは、サービスポッドにコンテキストがない場合、これがキャッシュタイムアウト後のユーザーに対する最初のメッセージであり、アプリケーション停止メッセージがプロトコルポッドに伝達されます。そのプロトコルポッドが、他のサービスポッドインスタンスにメッセージをリダイレクトします。

• サービスポッドにセッションのコンテキストがあり、セッションまたはユーザーに対する保留中の手順やトランザクションがない場合、アプリケーション停止メッセージがプロトコルポッドに伝達されます。そのプロトコルポッドが、他のサービスポッドインスタンスにメッセージをリダイレクトします。ただし、プロトコルポッドと通信する前に、セッション状態の強制同期が CDL に対して実行されます。さらに、セッションまたはユーザーのアフィニティエントリが削除されます。

発信メッセージ（Outgoing Messages）

• セッションまたはユーザーのコールフローや手順の完了後、サービスポッドがアップグレードや再起動の通知を受信すると、セッションまたは PDU の状態と CDL との同期が実行されます。さらに、サービスまたはユーザーのアフィニティエントリが削除され、サービスポッドインスタンスに対する後続メッセージのトリガーが許可されません。

• 進行中の既存のコールフローについては、コールを完了させるためにベストエフォートベースでトランザクションが処理されます。

ここでは、REST エンドポイント、GTPC エンドポイント、およびプロトコル（PFCP）エンドポイントポッドでのメッセージの処理について説明します。

REST エンドポイントポッド

ここでは、REST エンドポイントポッドでの着信および発信メッセージの処理について説明します。

着信メッセージ（Incoming Messages）

• 新しい TCP 接続の場合、入力 K8 サービスでは、アップグレードまたは再起動中に特定の REST エンドポイントポッドは選択されず、そのような要求は他のインスタンスに転送されます。

• アップグレード通知または再起動通知を受信後、既存の接続で GOAWAY フレームが送信されます。このフレームを送信すると、新しいメッセージがピアノードの新しい接続で送信されます。

発信メッセージ（Outgoing Messages）

• サービスポッドから発信要求メッセージを受信後、アプリケーション停止通知がサービスポッドに送り返されます。その結果、サービスポッドが、メッセージをトリガーする別の REST エンドポイントインスタンスを選択できます。

• 既存の一時的なメッセージの発信応答では、ベストエフォート方式でトランザクションが完了します。

GTPC エンドポイントポッド

着信メッセージ（Incoming Messages）

GTPC エンドポイントポッドの再起動中時に、着信要求メッセージの処理をサポートするために、セッションレベルの応答メッセージキャッシュがサービスポッドに追加されました。サービスポッドは、シーケンス番号、送信元 IP アドレス、送信元ポート、および要求メッセージタイプに基づいて、応答メッセージバッファを保存します。

• GTPC エンドポイントポッドの再起動が原因で回線上の応答メッセージが失われた場合、ピアで要求メッセージが再試行されます。このメッセージは、セッションレベルの応答メッセージキャッシュを使用して応答されます。

• 応答メッセージがサービスポッドで生成されない場合でも、メッセージは再送信としてサービスで検出されて適宜処理されます。

発信メッセージ（Outgoing Messages）

GTPC エンドポイントポッドの再起動中、発信要求メッセージは次の方法で処理されます。

• サービスポッドが、BGIPC を実行する際の要求のタイムアウト間隔と再送信回数を設定します。タイムアウト間隔と送信回数は、S5、S11、および S5E インターフェイスに対して定義されている N3 T3 に基づいています。

• GTPC エンドポイントポッドの代わりに、サービスポッドが送信元ポートとシーケンス番号を設定します。

• このメカニズムは、ポッドの再起動中に応答メッセージが失われた場合の発信メッセージの再送信に役立ちます。サービスポッドがシーケンス番号とポートを生成します。この場合、ピアでもメッセージが再送信として検出されるため、回線上のメッセージに不明瞭さはありません。

ノードマネージャポッドの 1 つのインスタンスは、アップグレード中にコールを処理するために使用できます。準備状況プローブとタイマーも、アップグレードシナリオ用に設定されます。ポッドが非アクティブの場合、サービスポッドは他のノードマネージャのポッドインスタンスを再試行します。

CDL ポッドには、アップグレードプロセス中にサービスを継続するための複数のレプリカがあります。アップグレードおよび再起動プロセス中の障害を最小限に抑えるために、CDL エンドポイントに対して複数の接続ストリームを使用できます。これらのプロセスでエラーが発生した場合、再試行メカニズムは別の CDL エンドポイント接続に対しても実装されます。