内容

はじめに

前提条件

要件

使用するコンポーネント

背景説明

基本事項の概要

RedmgrsとSessmgrsのマッピング

必要なログ

トラブルシュート

Sessmgrがサーバモードに入る

Sessmgrがサーバモードになる理由

回避策

はじめに

このドキュメントでは、Redundancy Configuration Manager(RCM)とユーザプレーン機能(UPF)の問題によってsessmgrサーバの状態が発生することについて説明します。

前提条件

要件

次の項目に関する知識があることが推奨されます。

- RCM（必須）

- UPF

使用するコンポーネント

このドキュメントの情報は、次のソフトウェアとハードウェアのバージョンに基づいています。

- RCMチェックポイントマネージャ

- UPFセッションマネージャ

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、クリアな（デフォルト）設定で作業を開始しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。

背景説明

また、sessmgrサーバの状態の問題に関する詳細なトラブルシューティングガイドを提供し、トラフィックとコール処理を妨げます。さらに、リカバリ用のラボテストセクションもあります。

基本事項の概要

図に示すように、RCMの冗長マネージャ（checkpointmgrsと呼ばれる）とUPFのsessmgrs間の直接接続を監視して、チェックポイントを追跡できます。

RedmgrsとSessmgrsのマッピング

1. UPごとにN個のsessmgrがあります。

2. RCMには、UPFのsessmgrsの数に応じて「M」個のredmgrsがあります。

3. sessmgrごとに別々のredmgrsがある場合、redmgrsとsessmgrの両方にIDに基づく1:1のマッピングがあります。

Note :: Redmgr IDs (m) = sessmgr instance ID (n-1)

For example :: smgr-1 is mapped with redmgr 0;smgr-2 is mapped with redmgr-1,

smgr-n is mapped with redmgr(m) = (n-1)

This is important to understand proper IDs of redmgr because we need to have proper logs to be checked

必要なログ

RCMログ – コマンド出力：

rcm show-statistics checkpointmgr-endpointstats

RCM controller and checkpointmgr logs (refer this link)

Log collection

UPF:

Command outputs (hidden mode)

show rcm checkpoint statistics verbose

show session subsystem facility sessmgr all debug-info | grep Mode

If you see any sessmgr in server state check the sessmgr instance IDs and no of sessmgr

show task resources facility sessmgr all

トラブルシュート

通常、UPFには21のsessmgrインスタンスがあり、20のアクティブなsessmgrと1つのスタンバイインスタンスで構成されます（ただし、この数は特定の設計によって異なる場合があります）。

以下に例を挙げます。

1. 非アクティブなセッションを識別するには、次のコマンドを使用します。

show task resources facility sessmgr all

2. このシナリオでは、問題のあるsessmgrを再起動し、さらにsessctrlを再起動して問題を解決しようとしても、影響を受けるsessmgrは復元されません。

3. さらに、該当するセッションが、期待されるクライアントモードではなく、サーバモードでスタックしていることが確認されています。この状態は、提供されたコマンドを使用して確認できます。

show rcm checkpoint statistics verbose

show rcm checkpoint statistics verbose

Tuesday August 29 16:27:53 IST 2023

smgr state peer recovery pre-alloc chk-point rcvd chk-point sent

inst conn records calls full micro full micro

---- ------- ----- ------- -------- ----- ----- ----- ----

1 Actv Ready 0 0 0 0 61784891 1041542505

2 Actv Ready 0 0 0 0 61593942 1047914230

3 Actv Ready 0 0 0 0 61471304 1031512458

4 Actv Ready 0 0 0 0 57745529 343772730

5 Actv Ready 0 0 0 0 57665041 356249384

6 Actv Ready 0 0 0 0 57722829 353213059

7 Actv Ready 0 0 0 0 61992022 1044821794

8 Actv Ready 0 0 0 0 61463665 1043128178

Here in above command all the connection can be seen as Actv Ready state which is required

show session subsystem facility sessmgr all debug-info | grep Mode

[local]<Nodename># show session subsystem facility sessmgr all debug-info | grep Mode

Tuesday August 29 16:28:56 IST 2023

Mode: UNKNOWN State: SRP_SESS_STATE_SOCK_ACTIVE

Mode: CLIENT State: SRP_SESS_STATE_SOCK_ACTIVE

Mode: CLIENT State: SRP_SESS_STATE_SOCK_ACTIVE

Mode: CLIENT State: SRP_SESS_STATE_SOCK_ACTIVE

Mode: CLIENT State: SRP_SESS_STATE_SOCK_ACTIVE

Mode: CLIENT State: SRP_SESS_STATE_SOCK_ACTIVE

Mode: CLIENT State: SRP_SESS_STATE_SOCK_ACTIVE

Mode: CLIENT State: SRP_SESS_STATE_SOCK_ACTIVE

Mode: CLIENT State: SRP_SESS_STATE_SOCK_ACTIVE

ここでは、すべてのセッションがクライアントモードであることが理想的です。ただし、この問題では、サーバモードになっているため、トラフィックを処理できません。

Sessmgrがサーバモードに入る

1. チェックポイントの通信と転送を容易にするために、各セッションマネージャ(sessmgr)は、対応する冗長マネージャ(redmgr)とのTCPピア接続を確立します。

2. TCPピア接続が確立されると、redmgrはsessmgrからすべての加入者コンテキストをチェックポイントし、保存できます。これにより、チェックポイントをそれぞれのsessmgrインスタンスで他のユーザプレーン機能(UPF)に転送できるため、シームレスなスイッチオーバーが可能になります。

3. sessmgrが常にCLIENTモードになっていることが重要です。何らかの理由でsessmgrがサーバモードで検出された場合は、関連するredmgrとのTCPピア接続が切断されていることを示しています。このシナリオでは、チェックポイントは実行されません。

4. sessmgrがUPF内でこの状態のままになっている場合は、sessmgrの状態を考慮せずに別のUPFへの予定外のスイッチオーバーを実行すると、同じ問題が発生します。この状況では、sessmgrはトラフィックを処理できません。

注：RCMがチェックポイントを開始し、UPFから応答が返されるのを待機している場合、checkpointmgr自体がチェックポイントを待機している特定の問題があります。しかし、応答がない場合、checkpointmgr自体は通信できないため、スイッチオーバータイマー値を超えるスイッチオーバー手順の完了が遅延します。そのため、このような場合、UPはPendActive状態のままになります。

これは、RCM統計情報とRedmgrログで確認できます。また、このコマンドを使用すると、どのcheckpointmgrがどのUPFに問題があるのかを知ることができます。

rcm show-statistics checkpointmgr-endpointstats

4. sessmgrがローカルでサーバモードになる理由は複数ある可能性がありますが、その主な理由の1つは次のとおりです。

Sessmgrがサーバモードになる理由

1. ユーザプレーン機能(UPF)内のセッションマネージャの数に基づいて、冗長性マネージャ(redmgr)用のレプリカが作成され、リソースコントロールマネージャ(RCM)で設定されます。この設定により、各redmgrがセッションマネージャインスタンスに接続されます。

2. redmgrとsessmgrの間に1:1のマッピングがある場合、セッションマネージャインスタンスIDがセッションマネージャの数より大きい値を超えると、何が起こりますか。

For example :::

Sessmgr instance ID :: 1 to 20

Redmgr IDs :: 0 to 19

In this example somehow if my sessmgr instance ID goes beyond the mentioned limit i.e say 21/22/23/24/25 so in this case redmgr is already mapped with instance IDs 0 to 19 and would be unaware about this new sessmgr instance ID created by UPF from 21 to 25 and in such a  case sessmgr with this instance IDs :: 21/22/23/24/25 will not be able to form any TCP peer connection with RCM redmgr leading to no checkpoint sync and since there won’t be any checkpoint sync sessmgr will get stuck into server mode and won’t take any traffic.

Refer this diagram

Both this sessmgr instance-7/8 have no TCP peer connection since for RCM redmgr-1 was

connected with instance-2 and redmgr-2 was connected to instance-5 so even though sessmgr

came up with new instance ID value which is beyond defined limit it wont have connection

back with redmgrs which is still just pointing to previous instance but connection is broken

回避策

この問題の解決策は、上記のコマンドで指定されているように、UPFのsessmgrの数とRCMのredmgrsの数に一致するようにsessmgrインスタンスIDの数を制限することです。

Max value of sessmgr instance ID = no of checkpointmgr – 1

このロジックに従って、スタンバイセッションを含むセッションの数を定義する必要があります。

task facility sessmgr max <no of max sessmgrs>

Note :: Implementation of this command needs node reload to enable full functionality of this command

このコマンドを実行すると、sessmgrが強制終了される回数に関係なく、sessmgrの最大カウント以下のインスタンスID値が常に生成されます。これにより、RCMでのチェックポイントの問題を防ぎ、sessmgrがこの理由でサーバモードに入るのを防ぐことができます。