ヘルス チェックを実行する前に、すべてのサービスが実行され、ノードが準備完了状態になっていることを確認します。ヘルス チェックを実行するには、マスター ノードにログ オンし、次の構成を使用します：

kubectl get pods -n smi 
kubectl get nodes 
kubectl get pod --all-namespaces -o wide 
kubectl get pods -n smf-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@smismf-cm01:~$ mkdir -p "temp_$(date +'%m%d%Y_T%H%M')" && cd "$_"

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

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

   例：

   test@smi1smf01-cm01:~/temp_08072019_T1651$ tar -xzvf smf.2020.01.0-1.SPA.tgz
   ./
   ./smf_REL_KEY-CCO_RELEASE.cer
   ./cisco_x509_verify_release.py
   ./smf.2020.01.0-1.tar
   ./smf.2020.01.0-1.tar.signature.SPA
   ./smf.2020.01.0-1.tar.SPA.README
   

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

   例：

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

   重要	「Ops Center 構成のバックアップ」セクションに進む前に、SPA.README ファイルに記載されている手順に従ってビルドを確認します。

このセクションでは、Ops Center の構成のバックアップを作成する手順について説明します。

Ops Center の構成のバックアップを実行するには、次の手順を実行します：

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. 次のコマンドを実行して、SMF Ops センターの構成を /home/ubuntu/smfops.backup ファイルにバックアップします。

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

このセクションでは、マスター ノードから CEE および Ops センター構成のバックアップを作成する手順について説明します。

CEE および Ops センターの構成のバックアップを実行するには、次の手順を実行します：

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

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

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

3. SMF Ops Center の構成をバックアップし、バック アップ ファイルの行数を確認します。

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

   例：

   ubuntu@posmf-mas01:~/backups_09182019_T2141$ ssh -p 2024 admin@$(kubectl get svc -n $(kubectl get namespaces | grep -oP 'smf-(\d+|\w+)') | grep <port_number> | awk '{ print $3 }') "show run | nomore" > smfops.backup_$(date +'%m%d%Y_T%H%M') && wc -l smfops.backup_$(date +'%m%d%Y_T%H%M')
   admin@<ipv4address>'s password: smf-OPS-PASSWORD
   334 smfops.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@posmf-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@posmf-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@posmf-mas01:~/backups_09182019_T2141$ wc -l *
     233 ceeops.backup
     334 smfops.backup
     361 smiops.backup
     928 total
   

このセクションでは、アップグレードを開始する前に新しい SMF イメージをステージングする手順について説明します。

新しい SMF イメージをステージングするには、次の手順を実行します：

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

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

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

   sudo mv smf_new_image.tar /data/software/uploads 

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

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

   sleep 30; ls /data/software/uploads 

   例：

   ubuntu@posmf-cm01:~/temp_08072019_T1651$ sleep 30; ls /data/software/uploads
   ubuntu@posmf-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/smf.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 エンドポイント ポッドの代わりに、サービスポッドが送信元ポートとシーケンス番号を設定します。

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

プロトコル（PFCP）エンドポイント ポッド

着信メッセージ（Incoming Messages）

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

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

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

発信メッセージ（Outgoing Messages）

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

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

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

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

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

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

次に、ローリング アップグレード中の RADIUS エンドポイント ポッドの動作を示します。

• アップグレード中、ポッドの状態は、トポロジの更新を介して他のポッドに伝達されます。非アクティブになるポッドは、新しいメッセージを転送するために選択されていません。

• アップグレードの RADIUS エンドポイント ポッドでメッセージを受信すると、アプリケーション停止指示が他のポッドに伝達されます。

• アプリケーション停止指示を受信すると、メッセージは他のアクティブな RADIUS エンドポイント ポッドにリダイレクトされます。

次に、ローリング アップグレード中の Diameter エンド ポイント ポッドの動作を示します：

• VIP スイッチ オーバーの前に、着信メッセージはサービス ポッドまたは Diameter ピアに転送されます。

• VIP スイッチオーバー後、新しいメッセージは停止中のポッドで受信されません。

アップグレード中、UDP プロキシ ポッドは着信メッセージを許可します。

アップグレード中、GTPP エンドポイント ポッドは着信メッセージを許可します。