소개

이 문서에서는 ssmgr 서버 상태를 일으키는 RCM(Redundancy Configuration Manager) 및 UPF(User Plane Function) 문제에 대해 설명합니다.

사전 요구 사항

요구 사항

다음 주제에 대한 지식을 보유하고 있으면 유용합니다.

• RCM
• UPF

사용되는 구성 요소

이 문서의 정보는 다음 소프트웨어 및 하드웨어 버전을 기반으로 합니다.

• RCM-checkpointmgr
• UPF-Sessmgr

이 문서의 정보는 특정 랩 환경의 디바이스를 토대로 작성되었습니다. 이 문서에 사용된 모든 디바이스는 초기화된(기본) 컨피그레이션으로 시작되었습니다. 현재 네트워크가 작동 중인 경우 모든 명령의 잠재적인 영향을 미리 숙지하시기 바랍니다.

배경 정보

기본 개요

그림에 나와 있는 것처럼 RCM의 이중화 관리자(checkpointtmgrs라고 함)와 체크포인트 추적을 위한 UPF의 세션 간의 직접 연결을 관찰할 수 있습니다.

Redmgrs 및 세션 매핑

1. 모든 UP에는 "N"개의 sessmgr이 있습니다.

2. RCM에는 UPF의 세션 수에 따라 "M"개의 rdmgrs가 있습니다.

3. rmgrs와 essmgr 모두 ID를 기준으로 1:1 매핑을 수행하므로 각 essmgr에 대해 별도의 redgrs가 있습니다.

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개의 essmgr 인스턴스가 있으며, 20개의 활성 세션과 1개의 대기 인스턴스로 구성됩니다(이 개수는 특정 설계에 따라 다를 수 있음).

예:

show task resources facility sessmgr all

2. 이 시나리오에서는 문제가 있는 세션을 다시 시작하고 sesstrl을 다시 시작하여 문제를 해결하려고 시도해도 영향을 받는 세션이 복원되지 않습니다.

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]
    
    
      # 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 서버 모드로 전환 중

이는 RCM 통계 및 redmgr 로그에서 확인할 수 있습니다. 또한 이 명령을 사용하면 어떤 checkpointmgr에 어떤 UPF에 문제가 있는지 알 수 있습니다.

rcm show-statistics checkpointmgr-endpointstats

4. sessmgr이 로컬로 서버 모드로 전환되는 데에는 여러 가지 이유가 있을 수 있지만, 그 주된 이유 중 하나는 여기에 설명되어 있는 것과 같습니다.

Sessmgr이 서버 모드로 전환된 이유

1. UPF(User Plane Function)의 세션 관리자 수에 따라 redundancy Manager(redundancy Manager)용 복제본이 생성되고 RCM(Resource Control Manager)에 구성됩니다. 이 컨피그레이션을 통해 각 redmgr이 세션 관리자 인스턴스와 연결됩니다. 

2. redmgr과 essmgr 간에 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 인스턴스 ID 수와 RCM의 redmgrs 수를 일치시키는 sessmgr 인스턴스 ID 수를 제한하는 것입니다.

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

이러한 논리에 따라, 대기(standby) 세션들을 포함하여 세션들의 수가 정의될 필요가 있다.

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이 서버 모드로 들어가는 것을 방지할 수 있습니다.