12Security Gateway·클러스터 업그레이드Security Gateway·클러스터 업그레이드

원문은 크게 세 부분으로 나뉩니다.

다시 강조하지만 게이트웨이·Cluster Member를 올리기 전에 반드시 관리 서버(Management Server)와 Log Server를 먼저 올려야 합니다(앞 장). 그다음 백업을 받고, 업그레이드 옵션과 사전 준비를 확인하고, 필요하면 게이트웨이 라이선스를 올립니다(라이선스 관리). VSX Gateway·VSX Cluster라면 관리 서버에서 VSX 객체 구성을 먼저 R82으로 올려야 한다는 점도 잊지 마세요.

또 하나 모든 업그레이드 방식에 공통된 경고가 있습니다. 업그레이드 과정은 기존 파일을 전부 기본(default) 파일로 덮어쓰므로, 장비에 손수 넣어 둔 커스텀 설정은 사라집니다. 그래서 전체 유지보수 창(full maintenance window)을 잡아 업그레이드 후 커스텀 설정을 다시 적용할 시간을 확보 해야 합니다. 클러스터에서는 이 손실이 더 위험합니다 — 커스텀이 사라지면 Cluster Member가 서로를 못 보거나, 원치 않는 상태로 빠지거나, 트래픽이 끊길 수 있습니다.

---

먼저 가장 단순한 경우, 클러스터가 아닌 단일 Security Gateway 입니다.

업그레이드 전 점검

절차

1. Security Gateway를 R82으로 올리거나 Clean Install 합니다.

설치 방법은 세 가지가 있습니다.

2. SmartConsole에서 SIC를 다시 맺기 — 이 단계는 R82을 Clean Install 한 경우에만 필요합니다(In-place 업그레이드만 했다면 건너뜁니다).

3. SmartConsole에서 게이트웨이 객체의 버전을 바꾸기 — Gateways & Servers에서 객체를 열고 General Properties > Platform 섹션 > Version 칸에서 R82을 고른 뒤 OK를 누릅니다.

4. SmartConsole에서 정책 설치 — Access Control Policy와 Threat Prevention Policy를 차례로 설치합니다. Install Policy > 정책 선택 > Install > 성공 확인. 두 정책 모두 정상 설치되어야 합니다.

5. 동작 확인 — SmartConsole > Logs & Events > Logs에서 이 게이트웨이의 로그를 살펴, 트래픽을 기대대로 검사하는지 확인합니다.

---

VSX Gateway 도 CPUSE로 올릴 수 있되, 단일 게이트웨이와 달리 관리 서버 쪽 VSX 객체 구성을 먼저 R82으로 맞춰야 한다는 점이 다릅니다.

업그레이드 시나리오는 둘입니다 — CPUSE로 R82 업그레이드 와 R82 Clean Install 입니다.

시나리오 A — CPUSE로 R82 업그레이드

1. 관리 서버에서 VSX Gateway 객체 구성을 R82으로 올리기

mdsenv <Main Domain Management Server의 IP 주소 또는 이름>

VSX Gateway 객체 구성을 R82으로 올립니다. 이 명령은 대화형 입니다.

vsx_util upgrade

관리 데이터베이스에 로그인하려고 다음을 입력합니다.

이어 VSX Gateway를 선택 하고 R82을 선택 합니다. 감사(audit) 목적으로 vsx_util 로그 파일을 보관해 두세요.

# Security Management Server:
/opt/CPsuite-R82/fw1/log/vsx_util_YYYYMMDD_HH_MM.log

# Multi-Domain Server:
/opt/CPmds-R82/customers/<Domain 이름>/CPsuite-R82/fw1/log/vsx_util_YYYYMMDD_HH_MM.log

그다음 SmartConsole로 R82 관리 서버에 접속해 Gateways & Servers > VSX Gateway 객체 > General Properties에서 Platform 섹션의 Version이 R82으로 보이는지 확인하고, Cancel을 누릅니다(OK를 누르면 안 됩니다).

2. CPUSE로 VSX Gateway 업그레이드 — Gaia에 소프트웨어 패키지 설치를 참고해 알맞은 절차를 따릅니다.

3. SmartConsole에서 정책 설치

4. 동작 확인 — 명령줄에서 vsx stat -v 로 VSX 구성을 보고, SmartConsole의 Logs에서 각 Virtual System이 트래픽을 제대로 검사하는지 확인합니다.

vsx stat -v

시나리오 B — R82 VSX Gateway Clean Install

1. 관리 서버에서 VSX Gateway 객체 구성을 R82으로 올리기 — 시나리오 A의 1단계와 동일합니다(mdsenv → vsx_util upgrade → 로그 보관 → SmartConsole에서 Version 확인 후 Cancel).

2. VSX Gateway에서 R82 Clean Install

3. VSX Gateway 재구성

VSX Gateway에 필요한 설정을 잡습니다(자세한 내용은 R82 CLI Reference Guide > VSX Commands > vsx_util > vsx_util reconfigure). 그다음 관리 서버 명령줄에서 Expert mode로 들어가고, Multi-Domain Server라면 mdsenv <Main Domain Management Server IP/이름> 으로 컨텍스트를 이동한 뒤 VSX 구성을 복원합니다.

vsx_util reconfigure

화면 지시를 따릅니다.

복원이 끝나면 VSX Gateway에 필요한 설정을 다시 잡습니다 — OS 구성(DNS, NTP, DHCP, Dynamic Routing, DHCP Relay 등), 여러 구성 파일에 손수 정의했던 설정, 해당하는 Check Point 구성 파일.

4. 동작 확인 — vsx stat -v 로 VSX 구성을 보고, SmartConsole의 Logs에서 각 Virtual System의 트래픽 검사를 확인합니다.

---

여기서부터는 ClusterXL·VSX Cluster·VRRP Cluster 입니다. 아래 지침은 세 종류 클러스터 모두에 똑같이 적용되고, Upgrade·Clean Install·Hotfix 세 가지 패키지에도 모두 통합니다(단, Hotfix는 클러스터 객체의 버전을 바꿀 필요가 없습니다).

클러스터가 까다로운 이유는 분명합니다 — 업그레이드는 멤버의 모든 Check Point 서비스를 멈추므로, 그동안 클러스터가 통과 연결을 검사·동기화하지 못합니다. 게다가 서로 다른 버전의 멤버는 연결을 동기화하지 못 합니다. 그래서 "다운타임을 얼마나 허용하느냐"에 맞춰 방식을 고르게 됩니다.

업그레이드 전 점검 (모든 클러스터 방식 공통)

확인해야 할 명령과 커널 파라미터는 다음과 같습니다.

fw ctl get int fwha_add_vsid_to_ccp_mac
grep fwha_add_vsid_to_ccp_mac $FWDIR/boot/modules/fwkern.conf

세 가지 클러스터 업그레이드 방식

다운타임을 기준으로 세 갈래입니다. 아래 표가 각 방식의 선택 기준·소요 시간·제약을 정리합니다.

업그레이드 중 "Ready" 상태에 대하여

서로 다른 버전의 멤버가 같은 네트워크에 있으면, 새(업그레이드된) 버전 멤버는 Ready 상태에 머물고, 옛 버전 멤버는 Active Attention 상태에 머뭅니다. Ready 상태의 멤버는 트래픽을 처리하지도, 다른 멤버와 동기화하지도 않습니다.

멤버가 Ready 상태에 빠지지 않게 하려면, 업그레이드하는 멤버를 콘솔로 접속한 뒤 둘 중 하나를 합니다.

set interface <인터페이스 이름> state off

---

MVC 메커니즘은 서로 다른 버전을 도는 Cluster Member 사이에서 연결을 동기화 해 줍니다. 덕분에 연결 손실 없이(Zero Downtime Upgrade) 새 버전으로 올릴 수 있고, 나머지를 올리기 전에 일부 멤버에서 새 버전을 먼저 시험해 볼 수도 있습니다.

MVC 사전 준비

cphaprob state

MVC가 지원하는 버전

R82 멤버의 MVC는 다음 버전을 도는 피어 멤버와 동기화를 지원합니다.

따라서 Multi-Version Cluster 안의 멤버들은 다음 조합만 가능합니다.

\ 지원되는 업그레이드 경로는 R82 Release Notes* 를 참고하세요.

멤버가 둘뿐인 경우 — 허용 조합은 단순합니다.

여기서 "Version X"는 R77.30, R80.10, R80.20 등 하나의 옛 버전 입니다.

멤버가 셋·넷·다섯인 경우

허용되는 멤버 버전 조합은 다음과 같습니다(R82을 한 대씩 늘려 가는 과정).

"Version X"는 R77.30, R80.10, R80.20 등 하나의 옛 버전입니다.

MVC의 제약

일반 구성 제약

이 "두 번 설치" 절차는 이렇게 진행합니다.

페일오버 시 살아남지 못하는 연결 — 버전이 다른 멤버 사이의 페일오버에서는 다음 연결이 끊깁니다.

MVC 업그레이드 절차 — Gateway 모드 (ClusterXL·VRRP)

예시는 멤버 M1, M2, M3 세 대의 클러스터지만, 두 대 이상이면 그대로 응용 할 수 있습니다. 큰 그림은 이렇습니다 — ①클러스터 객체를 R82으로, ②M3 올리고 MVC 켜기 → 정책 설치, ③M2 올리고 MVC 켜기 → 정책 설치, ④마지막 M1 올리기 → 클러스터 객체에 정책 설치 → MVC 끄기. 즉 한 대씩 올리면서 MVC로 옛 멤버와 동기화를 유지 하는 것이 요령입니다.

1. 클러스터 객체 버전을 R82으로 — 클러스터 객체 > General Properties > Platform > Version → R82 → OK.

2. M3을 R82으로 업그레이드 또는 Clean Install

3. M3과 SIC 다시 맺기 — M3을 Clean Install 한 경우에만 필요합니다. 클러스터 객체 > Cluster Members > M3 선택 > Edit > General 탭 > Communication > Reset > Activation Key를 두 번 입력 > Initialize > Trust established 확인 > Close/OK > Publish.

4. R82 M3에 Access Control Policy 설치 — M3을 Clean Install 한 경우에만. 정책을 고르고 독립 설치 선택 + 클러스터 실패 옵션 해제 후 Install. → M3 성공, 옛 멤버 M1·M2 경고 실패(무시).

5. R82 M3에서 MVC 켜기

# Gaia Clish:
set cluster member mvc on

# Expert mode:
cphaconf mvc on

상태를 확인합니다.

# Gaia Clish:
show cluster members mvc

# Expert mode:
cphaprob mvc

6. R82 M3에 Access Control Policy 다시 설치 — 4단계와 같은 옵션으로 Install. → M3 성공, M1·M2 경고 실패(무시).

7. 각 멤버에서 클러스터 상태 확인

# Gaia Clish:
show cluster state

# Expert mode:
cphaprob state

8~13. M2도 같은 흐름 — M2를 업그레이드/Clean Install(재부팅) → (Clean Install이면) SIC 재수립 → R82 M3·M2에 정책 설치(독립+실패옵션 해제, 옛 M1만 경고 실패 무시) → M2에서 MVC 켜기(set cluster member mvc on / cphaconf mvc on) → M3·M2에 정책 다시 설치 → 클러스터 상태 확인. 이 흐름은 M3 때와 사실상 같습니다.

14~15. 마지막 M1 올리기 — M1을 업그레이드/Clean Install(재부팅) → (Clean Install이면) SIC 재수립. M1은 마지막이므로 MVC를 따로 켜지 않습니다.

16. 클러스터 객체에 정책 설치 — 이제 모든 멤버가 R82이므로, 평소처럼 클러스터 객체 전체에 Access Control Policy와 Threat Prevention Policy를 설치합니다. 이때는 Install on each selected gateway independently 선택, For gateway clusters, if installation on a cluster member fails, do not install on that cluster 도 선택 합니다(이전 단계와 반대로 둘 다 선택). 모든 멤버에 정상 설치되어야 합니다.

17. 클러스터 상태 확인 — 모든 멤버가 서로의 상태에 동의하고, HA면 하나만 Active·나머지 Standby, Load Sharing이면 전부 Active 여야 합니다.

18. 모든 멤버에서 MVC 끄기 — 업그레이드가 끝났으니 MVC를 내립니다.

# Gaia Clish:
set cluster member mvc off

# Expert mode:
cphaconf mvc off

상태를 show cluster members mvc 또는 cphaprob mvc 로 확인합니다.

19. 동작 확인 — SmartConsole > Logs & Events > Logs에서 이 클러스터의 로그를 살펴 트래픽 검사를 확인합니다.

MVC 업그레이드 절차 — VSX 모드 (VSX Cluster)

사전 준비는 Gateway 모드와 같지만(백업·사전 준비·관리 서버 선행 업그레이드·계획·유지보수 창), MVC는 커널 에디션이 다른 VSX 멤버도 지원 합니다. 예시는 M1·M2·M3 세 대이며 두 대 이상이면 응용할 수 있습니다.

큰 그림 — ①관리 서버에서 VSX Cluster 객체를 R82으로, ②M3 올리고 MVC 켜기 → 정책 설치, ③M2 올리고 MVC 켜기 → 정책 설치, ④M1 올리기, ⑤VSX Cluster 객체에 정책 설치, ⑥MVC 끄기, ⑦각 Virtual System 객체에 정책 설치.

핵심 차이는 Gateway 모드의 단계마다 VSX 특유의 작업이 더해진다 는 점입니다.

  # Gaia Clish:
  set virtual-system 0
  set cluster member mvc on     # 끌 때는 off

  # Expert mode:
  vsenv 0
  cphaconf mvc on               # 끌 때는 off
  

  vsx stat -v                              # Virtual Device 로드, SIC Trust·정책 확인

  # 클러스터 상태:
  set virtual-system 0; show cluster state   # 또는: vsenv 0; cphaprob state

  # 클러스터 인터페이스:
  set virtual-system 0; show cluster members interfaces all   # 또는: vsenv 0; cphaprob -a if
  

M3을 막 올린 직후에는 업그레이드된 M3이 Ready, 다른 멤버 M1·M2는 M3을 Lost 로 보거나 아예 못 봅니다. M3에서 MVC를 켜고 정책을 설치한 뒤 상태를 다시 보면, High Availability 모드에서는 M3이 Active, 나머지는 Standby가 됩니다. Virtual System Load Sharing 모드에서는 한 멤버가 Active, 나머지는 Standby/Backup이 됩니다.

마지막 M1까지 올린 뒤에는 VSX Cluster 객체에 Access Control·Threat Prevention 정책을 설치(독립 설치 + 클러스터 실패 옵션 둘 다 선택)하고, 모든 멤버에서 MVC를 끈 다음, 각 Virtual System 객체에도 Access Control·Threat Prevention 정책을 따로 설치 합니다. 끝으로 각 Target Domain Management Server에서 Logs를 살펴 Virtual System들의 트래픽 검사를 확인합니다.

Multi-Version Cluster 문제 해결

멤버끼리 연결을 잘 동기화하는지 확인

# 동기화 통계:
show cluster statistics sync     # 또는: cphaprob syncstat

# 동시 연결 수:
fw tab -t connections -s

더 자세한 정보가 필요하면 클러스터 커널 디버그 를 수집합니다. 디버그 모듈 "cluster" 에서 디버그 플래그 "ccp" 와 "cu" 를 켭니다(전체 절차는 R82 Quantum Security Gateway Guide > Kernel Debug on Security Gateway).

---

다운타임이 허용될 때 쓰는 가장 단순한 방식입니다. 각 멤버를 독립된 게이트웨이처럼 올리므로 절차가 쉽습니다.

Security Gateway Cluster의 Minimum Effort Upgrade

사전 준비(백업 → 사전 준비 확인 → 관리 서버 선행 업그레이드 → 계획 확인 → 유지보수 창)를 끝낸 뒤 진행합니다.

1. 각 멤버를 R82으로 업그레이드 또는 Clean Install

설치 방법은 CPUSE Upgrade / CPUSE Clean Install / 처음부터 Clean Install(ClusterXL은 "Installing a ClusterXL Cluster", VRRP는 "Installing a VRRP Cluster", VSX는 "Installing a Legacy VSX Cluster"의 멤버 설치 단계)입니다. 어느 경우든 Gaia Wizard의 Management Connection IP는 이전 멤버와 같은 IP 를 씁니다.

2. 클러스터 객체 버전을 R82으로 — General Properties > Platform > Version → R82 → OK.

3. 각 멤버와 SIC 다시 맺기 — Clean Install 한 멤버에만 필요합니다(Communication > Reset > Activation Key 두 번 > Initialize > Trust established 확인 > Publish).

4. 클러스터 객체에 정책 설치 — Access Control Policy와 Threat Prevention Policy를 설치합니다. 이때 Install on each selected gateway independently 선택, For gateway clusters, if installation on a cluster member fails, do not install on that cluster 도 선택 합니다. 모든 멤버에 정상 설치되어야 합니다.

5. 클러스터 상태 확인 — show cluster state / cphaprob state 로 모든 멤버가 서로의 상태에 동의하는지, HA면 하나만 Active·나머지 Standby, Load Sharing이면 전부 Active 인지 봅니다.

6. 동작 확인 — Logs에서 트래픽 검사를 확인합니다.

VSX Cluster의 Minimum Effort Upgrade

흐름은 위와 같지만 VSX 특유의 단계가 더해집니다. 사전 준비에서 관리 서버와 VSX Cluster Member를 둘 다 백업(sk100395)해야 합니다.

1. 관리 서버에서 VSX Cluster 객체를 R82으로 — Expert mode에서 (Multi-Domain이면 mdsenv <Main Domain Management Server IP/이름> 후) vsx_util upgrade 를 실행합니다. 대화형으로 관리 서버 IP·관리자 이름·암호를 입력하고, VSX Cluster를 고른 뒤 R82을 선택합니다. 로그 파일을 보관하고, SmartConsole에서 Version이 R82인지 확인한 뒤 Cancel(OK 아님) 을 누릅니다.

mdsenv <Main Domain Management Server의 IP 주소 또는 이름>
vsx_util upgrade

2. 각 멤버를 R82으로 업그레이드 또는 Clean Install — CPUSE Upgrade는 평소대로. Clean Install이면 설치 후 관리 서버에서 vsx_util reconfigure 로 VSX 구성을 밀어 넣고(같은 Activation Key 입력), OS 구성·손수 정의 설정·Check Point 구성 파일을 다시 잡습니다. 끝난 뒤 재부팅. Management Connection IP는 이전과 같은 IP.

3. 각 멤버와 SIC 다시 맺기 — Clean Install 한 멤버에만(Communication > Reset > Activation Key > Initialize > Publish).

4. 정책 설치 — VSX Cluster 객체에 기본 정책 <VSX Cluster 객체 이름>_VSX 를 설치(독립 설치 + 클러스터 실패 옵션 둘 다 선택)하고, 이어 Threat Prevention Policy를 설치합니다.

5. VSX 구성·클러스터 상태 확인

vsx stat -v                                  # Virtual Device 로드, SIC Trust·정책 확인
set virtual-system 0; show cluster state      # 또는: vsenv 0; cphaprob state
set virtual-system 0; show cluster members interfaces all   # 또는: vsenv 0; cphaprob -a if

모든 멤버가 서로의 상태에 동의하고, HA면 하나만 Active·나머지 Standby, Virtual System Load Sharing이면 전부 Active, 모든 Virtual System이 같은 상태 정보를 보여야 합니다.

6. 동작 확인 — 각 Target Domain Management Server에서 Logs로 Virtual System 트래픽 검사를 확인합니다.

---

예전엔 Zero Downtime Upgrade 라 불렸습니다. 네트워크 다운타임을 거의 둘 수 없고, 빠르게, 끊김을 최소화 하고 싶을 때 씁니다. 요령은 멤버 일부(M2·M3)를 먼저 올려 Active로 만든 다음, 옛 멤버(M1)에서 cpstop으로 페일오버를 강제 하는 것입니다. 이 방식도 R82 Release Notes 의 모든 지원 버전에 쓸 수 있습니다.

Security Gateway Cluster의 Minimum Downtime Upgrade

사전 준비를 끝낸 뒤, 예시 멤버 M1·M2·M3(두 대 이상 응용 가능)으로 진행합니다.

1. 각 멤버에서 CCP 모드를 Broadcast로

cphaconf set_ccp broadcast

이 변경은 재부팅이 필요 없고, 즉시 적용되며, 재부팅 후에도 유지 됩니다. cphaprob -a if 로 Broadcast로 설정됐는지 확인합니다.

2. M3을 R82으로 업그레이드 또는 Clean Install (재부팅). 설치 방법·Management Connection IP 규칙은 앞과 같습니다.

3. M2도 R82으로 업그레이드 또는 Clean Install (재부팅).

여기서 포인트는 M3·M2를 먼저 올리되 M1은 아직 옛 버전으로 트래픽을 처리하게 둔다 는 점입니다.

4. 클러스터 객체 버전을 R82으로 — General Properties > Platform > Version → R82 → OK.

5. M3과 SIC 다시 맺기 / 6. M2와 SIC 다시 맺기 — 각각 Clean Install 한 경우에만 (Communication > Reset > Activation Key 두 번 > Initialize > Publish).

7. Access Control Policy 설치 — 정책을 고르고 독립 설치 선택 + 클러스터 실패 옵션 해제 후 Install. → 업그레이드된 M2·M3 성공, 옛 M1 경고 실패(무시).

8. 클러스터 상태 확인 — 이 시점에서는 업그레이드된 M2·M3이 Ready, 옛 M1은 Active(!)(R80.20 이상) 또는 Active Attention(R80.10 이하) 입니다.

show cluster state     # 또는: cphaprob state

9. 옛 멤버 M1에서 모든 Check Point 서비스 중지 — 이것이 핵심 단계 입니다.

cpstop

10. 클러스터 상태 확인 — HA면 M2·M3 중 하나가 Active, 다른 하나가 Standby가 됩니다. Load Sharing이면 모두 Active.

11. 옛 M1을 R82으로 업그레이드 또는 Clean Install (재부팅).

12. M1과 SIC 다시 맺기 — Clean Install 한 경우에만.

13. 클러스터 객체에 정책 설치 — 이제 전부 R82이므로 Access Control·Threat Prevention 정책을 독립 설치 + 클러스터 실패 옵션 둘 다 선택 으로 설치합니다. 모든 멤버에 정상 설치되어야 합니다.

14. 클러스터 상태 확인 — 모든 멤버가 서로의 상태에 동의, HA면 하나만 Active·나머지 Standby, Load Sharing이면 전부 Active.

15. 동작 확인 — Logs에서 트래픽 검사를 확인합니다.

VSX Cluster의 Minimum Downtime Upgrade

흐름은 위와 같고 VSX 단계가 더해집니다. 사전 준비에서 관리 서버와 VSX Cluster Member를 둘 다 백업(sk100395).

1. 관리 서버에서 VSX Cluster 객체를 R82으로 — Expert mode에서 (Multi-Domain이면 mdsenv ... 후) vsx_util upgrade. 관리 정보 입력 → VSX Cluster 선택 → R82 선택 → 로그 보관 → SmartConsole에서 Version 확인 후 Cancel.

2. 각 멤버에서 CCP 모드를 Broadcast로

cphaconf set_ccp broadcast     # 재부팅 불필요, 즉시 적용·재부팅 후 유지
cphaprob -a if                 # Broadcast 확인

3. M3을, 4. M2를 각각 R82으로 업그레이드 또는 Clean Install(재부팅). Clean Install이면 vsx_util reconfigure 후처리(같은 Activation Key + OS·커스텀·Check Point 구성 파일 재구성)가 따라옵니다.

5. M3과, 6. M2와 SIC 다시 맺기 — Clean Install 한 경우에만.

7. Access Control Policy 설치 — VSX Cluster의 기본 정책 <VSX Cluster 객체 이름>_VSX 를 독립 설치 선택 + 클러스터 실패 옵션 해제 로 설치. → 업그레이드된 M2·M3 성공, 옛 M1 경고 실패(무시).

8. VSX 구성·클러스터 상태 확인 — 이 시점에서 업그레이드된 M2·M3은 Ready, 옛 M1은 Active(!)(R80.20 이상) 또는 Active Attention(R80.10 이하).

vsx stat -v
set virtual-system 0; show cluster state     # 또는: vsenv 0; cphaprob state

9. 옛 M1에서 모든 Check Point 서비스 중지

cpstop

10. M2·M3 클러스터 상태 확인 — 둘 중 하나가 Active, 다른 하나가 Standby.

11. 옛 M1을 R82으로 업그레이드 또는 Clean Install (재부팅). Clean Install이면 vsx_util reconfigure 후처리.

12. M1과 SIC 다시 맺기 — Clean Install 한 경우에만.

13. 정책 설치 — VSX Cluster 객체에 기본 정책 <...>_VSX(독립 설치 + 클러스터 실패 옵션 둘 다 선택)와 Threat Prevention Policy를 설치합니다.

14. VSX 구성·클러스터 상태 확인

vsx stat -v
set virtual-system 0; show cluster state                    # 또는: vsenv 0; cphaprob state
set virtual-system 0; show cluster members interfaces all   # 또는: vsenv 0; cphaprob -a if

모든 멤버가 서로의 상태에 동의, HA면 하나만 Active·나머지 Standby, Virtual System Load Sharing이면 전부 Active, 모든 Virtual System이 같은 상태 정보를 보여야 합니다.

15. 동작 확인 — 각 Target Domain Management Server에서 Logs로 Virtual System 트래픽 검사를 확인합니다.

---

Full High Availability 클러스터는 관리 서버와 게이트웨이가 같은 두 appliance에 함께 얹혀 있어 업그레이드 순서가 특별합니다. 그래서 일반 클러스터 절차가 아니라 관리 서버 업그레이드 절차 를 따릅니다 — 구체적으로 "Upgrading Security Management Servers in Management High Availability from R80.20 and higher" 절차를 그대로 적용합니다.

여기까지가 표준 설치·업그레이드입니다. 이제 평범하지 않은 상황들을 다룹니다 — 먼저 관리 서버 특수 시나리오로 넘어갑니다.