소개
이 문서에서는 ssmgr 서버 상태를 일으키는 RCM(Redundancy Configuration Manager) 및 UPF(User Plane Function) 문제에 대해 설명합니다.
사전 요구 사항
요구 사항
다음 주제에 대한 지식을 보유하고 있으면 유용합니다.
사용되는 구성 요소
이 문서의 정보는 다음 소프트웨어 및 하드웨어 버전을 기반으로 합니다.
- RCM-checkpointmgr
- UPF-Sessmgr
이 문서의 정보는 특정 랩 환경의 디바이스를 토대로 작성되었습니다. 이 문서에 사용된 모든 디바이스는 초기화된(기본) 컨피그레이션으로 시작되었습니다. 현재 네트워크가 작동 중인 경우 모든 명령의 잠재적인 영향을 미리 숙지하시기 바랍니다.
배경 정보
또한 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
-
이 시나리오에서는 문제가 있는 세션을 다시 시작하고 sesstrl을 다시 시작하여 문제를 해결하려고 시도해도 영향을 받는 세션이 복원되지 않습니다.
-
또한 영향을 받는 세션이 예상 클라이언트 모드가 아닌 서버 모드에서 중단된 것으로 관찰되며, 이는 제공된 명령을 사용하여 확인할 수 있는 조건입니다.
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 서버 모드로 전환 중
-
각 세션 관리자(sessmgr)는 검사점의 통신 및 전송을 용이하게 하기 위해 해당 이중화 관리자(redmgr)와의 TCP 피어 연결을 설정합니다.
-
TCP 피어 연결이 설정되면 redmgr은 sessmgr에서 모든 가입자 컨텍스트를 검사하고 저장할 수 있습니다. 그러면 체크포인트가 해당 sessmgr 인스턴스와 함께 다른 UPF(사용자 플레인 기능)로 전송될 수 있으므로 원활한 전환이 가능합니다.
-
Sessmgr이 항상 클라이언트 모드에 있어야 합니다. 어떤 이유로든 서버 모드에서 sessmgr이 탐지되면 연결된 redmgr과의 끊어진 TCP 피어 연결을 나타냅니다. 이 시나리오에서는 체크포인트가 발생하지 않습니다.
-
UPF에서 세션이 이 상태로 고정되면 sessmgr 상태를 고려하지 않고 다른 UPF로 계획되지 않은 전환을 수행하면 동일한 문제가 발생합니다. 이 상황에서는 Sessmgr이 트래픽을 처리할 수 없습니다.
참고: checkpointmgr 자체에서 checkpointing을 기다리는 동안 RCM에서 checkpointing을 시작하고 UPF에서 응답을 다시 기다리는 특정 문제가 있습니다. 그러나 응답 checkpointmgr 자체가 통신할 수 없을 때 전환 절차의 완료가 전환 타이머 값을 초과하게 됩니다. 따라서 이러한 경우 UP는 PendActive 상태로 고정됩니다.
이는 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이 서버 모드로 들어가는 것을 방지할 수 있습니다.