목차/05. Maestro를 R82로 업그레이드

05Maestro를 R82로 업그레이드Upgrading Maestro to R82

이 장은 Maestro 환경 — 즉 Quantum Maestro Orchestrator 들과 그 아래의 Security Group 들 — 을 R82로 업그레이드하고, 잘못되면 되돌리는(rollback) 전 과정을 빠짐없이 설명합니다. 핵심은 무중단(Zero Downtime) 으로 업그레이드한다는 점인데, 이를 위해 Multi-Version Cluster (MVC) 라는 방식을 씁니다. 한 클러스터 안에 서로 다른 버전의 멤버를 잠시 공존시키면서, 멤버를 절반씩 나눠 차례로 올리는 것이 핵심 아이디어입니다.

이 절차가 지원하는 Security Group 업그레이드 경로는 딱 두 가지 입니다.

  • R81.20 → R82
  • R81.10 → R82

되돌리기가 필요해지면 두 가지 롤백 절차를 함께 보세요 — Orchestrator 롤백은 이 장 뒤쪽의 Orchestrator 롤백 절을, Security Group 롤백은 별도 절차(Security Group 롤백)를 참고합니다.

시작 전 알아 둘 것 — Orchestrator

먼저 Orchestrator 쪽에서 지켜야 할 원칙들입니다.

  • 모든 사이트의 모든 Orchestrator를 위해 유지보수 시간(maintenance window)을 잡는 것을 권장합니다.
  • Orchestrator의 메이저 소프트웨어 버전은 그것이 관리하는 Security Group의 메이저 버전과 같거나 더 높아야 합니다.
  • 이 절차는 Orchestrator의 현재 구성을 그대로 유지 합니다.
  • Orchestrator를 전부 먼저 올린 다음에야 Security Group을 올립니다.
  • Orchestrator는 한 번에 하나씩 업그레이드합니다.

Dual Site / Dual Chassis 환경의 사전 절차

Maestro Dual Site 또는 Scalable Chassis Dual Chassis 환경에서는 다음 순서를 따릅니다.

  1. Standby 사이트(Site 2) 의 Orchestrator / Scalable Chassis를 먼저 업그레이드합니다.
  2. 각 Security Group에서 아직 업그레이드하지 않은 Active 사이트(Site 1)에서 방금 업그레이드한 Standby 사이트(Site 2)로 fail-over 를 일으킵니다.
    1. 각 Security Group의 명령줄에 접속합니다.
    2. 기본 셸이 Gaia gClish 라면 Expert mode로 들어갑니다.
  1. fail-over를 일으킵니다.
      chassis_admin -c <ID of Active Site> down
      chassis_admin -c <ID of Former Active Site> up
  1. 이제 새 Standby 사이트(Site 1) 가 된 쪽의 Orchestrator / Scalable Chassis를 업그레이드합니다.

시작 전 알아 둘 것 — Security Group

Security Group 쪽은 규칙이 더 많습니다. 무중단을 깨뜨릴 수 있는 작업들이 엄격히 금지 되므로 특히 주의해야 합니다.

  • Security Group을 올리기 전에 그 Security Group을 관리하는 Management Server를 먼저 업그레이드 해야 합니다(설치·업그레이드 가이드 참고).
  • 이 절차는 Gateway 모드 와 Legacy VSX 모드 의 Security Group 모두에 적용됩니다. 단, Legacy VSX 모드에서는 모든 명령을 VS0 컨텍스트에서 실행해야 합니다.
    • Gaia gClish에서 컨텍스트를 바꾸려면 — set virtual-system 0
    • Expert mode에서 컨텍스트를 바꾸려면 — vsenv 0

논리 그룹 "A"와 "B"로 나누기

무중단의 비밀은 한 Security Group의 멤버를 동시에 다 올리지 않는 데 있습니다. 멤버들을 둘 이상의 논리 그룹(logical group) 으로 나눠, 한 그룹을 올리는 동안 다른 그룹이 트래픽을 계속 처리하게 합니다. 이 절차에서는 그룹을 "A" 와 "B" 둘로 나누며, 각 논리 그룹의 멤버 수는 가능한 한 비슷하게 맞춥니다.

환경구성 예시
Single SiteSecurity Group에 멤버 8개. 그룹 "A" = 1_1~1_4, 그룹 "B" = 1_5~1_8.
Single SiteSecurity Group에 멤버 5개. 그룹 "A" = 1_1~1_3, 그룹 "B" = 1_4~1_5.
Dual Site각 사이트에 멤버 4개. 그룹 "A" = Site 1의 1_1~1_4, 그룹 "B" = Site 2의 2_1~2_4.

Dual Site 환경에서의 권장 사항

Dual Site 환경에서는 다음을 권장합니다.

  • 한 Security Group의 한 사이트 멤버를 모두 올린 뒤, 같은 Security Group의 다음 사이트 멤버를 올립니다 — 한 번에 한 Security Group씩.
  • 업그레이드 도중 사이트 간 fail-over가 일어나는 것을 막으려면, 각 Security Group에서 다음을 해 둡니다.
    1. Security Group 명령줄에 접속합니다.
    2. 기본 셸이 Expert mode라면 Gaia gClish로 들어갑니다.
  1. 현재 Active/Standby 모드를 확인해 적어 둡니다 (절차 끝에서 다시 필요합니다).
     show cluster configuration high-availability mode

사용 가능한 High Availability 모드

Mode ID제목설명
0Active/Standby - Active Up주(primary) 사이트가 없습니다. 현재 Active인 사이트가 다음 중 하나가 일어날 때까지 Active를 유지합니다 — ① 현재 Active 사이트가 "DOWN"이 됨(이전 Active 사이트가 다시 "UP"이 되면 Standby가 됨), 또는 ② 현재 Standby 사이트의 품질 등급(quality grade)이 현재 Active 사이트보다 높아짐.
1Active/Standby - Primary UpActive 사이트가 다음 중 하나가 일어날 때까지 항상 Active를 유지 합니다 — ① 현재 Active 사이트가 "DOWN"이 됨(이전 Active 사이트가 다시 "UP"이 되면 다시 Active가 됨), 또는 ② Standby 사이트의 품질 등급이 더 높아짐.

필요한 소프트웨어 패키지

업그레이드에 앞서 sk181127에서 다음 세 가지를 내려받 습니다.

  1. R81.10 또는 R81.20용 Jumbo Hotfix Accumulator 의 필요한 Take.
  2. 필요한 CPUSE Deployment Agent.
  3. Scalable Platform용 R82 Upgrade Package.

전체 흐름 한눈에 보기

세부 단계로 들어가기 전에 큰 그림을 먼저 잡아 둡니다.

  1. Management Server — R82 Security Group을 관리할 수 있는 버전으로 업그레이드(sk113113 참고).
  2. Orchestrator — R82로 업그레이드.
  3. Security Group — Pre-Upgrade Verifier를 돌려 업그레이드 가능 여부 확인.
  4. Security Group — 필요한 Jumbo Hotfix Accumulator 설치(멤버를 두 논리 그룹으로 나눠).
  5. Security Group — CPUSE Deployment Agent 패키지 설치.
  6. Security Group — R82로 업그레이드(역시 두 논리 그룹으로 나눠).
  7. SmartConsole — 정책 설치.

Step 1 — Management Server 업그레이드

가장 먼저 Security Management Server 또는 Multi-Domain Security Management Server 를 R82 Security Group을 관리할 수 있는 버전으로 업그레이드합니다. 정확한 대상 버전은 R82 Release Notes 또는 sk113113에서 확인합니다.

Step 2 — Orchestrator를 R82로 업그레이드

Orchestrator는 CPUSE Deployment Agent 를 통해 업그레이드합니다(CPUSE에 관한 자세한 내용은 sk92449 참고). CPUSE GUI는 신형과 구형 두 가지가 있어 화면이 다르므로, 쓰는 쪽을 따릅니다.

신형 CPUSE GUI (New CPUSE GUI)

단계작업
AOrchestrator가 R80.20SP를 돌리고 있다면, R80.20SP Jumbo Hotfix Accumulator Take 326 이상 을 먼저 설치합니다.
BOrchestrator의 Gaia Portal에서 왼쪽 트리의 Software Updates > Available Updates 로 갑니다.
C왼쪽 위에서 Add package > Upload package from local 을 클릭합니다.
DImport package 창에서 Browse for a file 을 클릭합니다.
Esk181127에서 받은 R82 Upgrade Package for Scalable Platforms를 둔 폴더로 갑니다.
F그 R82 Upgrade Package for Scalable Platforms를 선택합니다.
GOpen 을 클릭합니다.
HImport 를 클릭합니다.
IMajor Versions 섹션에 새 행이 나타납니다.
J가져온 R82 CPUSE Offline Package 행에서 Verify 버튼을 클릭합니다.
K같은 행에서 Upgrade 버튼을 클릭합니다.

구형 CPUSE GUI (Legacy CPUSE GUI)

단계작업
AOrchestrator가 R80.20SP를 돌리고 있다면, R80.20SP Jumbo Hotfix Accumulator Take 326 이상을 먼저 설치합니다.
BGaia Portal에서 왼쪽 트리의 Upgrades (CPUSE) > Status and Actions 로 갑니다.
C오른쪽 위 섹션에서 Import Package 를 클릭합니다.
DBrowse 를 클릭합니다.
Esk181127에서 받은 R82 Upgrade Package for Scalable Platforms를 둔 폴더로 갑니다.
F그 패키지를 선택합니다.
GOpen 을 클릭합니다.
HImport 를 클릭합니다.
I패키지 목록 위, 도움말 아이콘 근처의 필터 버튼(지금은 "Showing Recommended packages")을 클릭해 "All" 을 고릅니다. 필터가 "Showing All packages"로 바뀌어야 합니다.
J가져온 R82 CPUSE Offline Package를 우클릭하고 Verify Update 를 클릭합니다.
K같은 패키지를 우클릭하고 Upgrade 를 클릭합니다.

Step 3 — (Legacy VSX 전용) Management Server에서 객체 버전 변경

단계작업
AManagement Server 명령줄에 접속합니다.
BExpert mode에 로그인합니다.
CMulti-Domain Server라면 해당 Security Group을 VSX 모드로 관리하는 Domain Management Server 컨텍스트로 갑니다. mdsenv <IP Address or Name of Domain Management Server>
D관리 데이터베이스에서 VSX Gateway 객체의 버전을 업그레이드합니다(아래 명령).
EManagement Server 관리자 자격으로 로그인합니다.
F이 Security Group의 Legacy VSX Gateway 객체를 선택합니다.
G버전을 R82 로 바꿉니다. 화면 지시를 따릅니다.

D단계 명령은 다음과 같습니다.

vsx_util upgrade [-s <Mgmt Server>] [-u <UserName>]

자세한 내용은 R82 VSX Administration Guide의 "Command Line Reference" 장 "vsx_util" 절을 참고합니다.

Step 4 — Security Group에서 SMO Image Cloning 끄기

단계작업
ASecurity Group 명령줄에 접속합니다.
B기본 셸이 /bin/bash(Expert mode)라면 Gaia gClish로 들어갑니다 — gclish
CSMO Image Cloning 상태를 확인합니다. show cluster configuration image auto-clone state
D켜져 있으면 끕니다. set cluster configuration image auto-clone state off
E다시 상태를 확인합니다. show cluster configuration image auto-clone state

Step 5 — Security Group에 Jumbo Hotfix Accumulator 설치

이제 현재 버전(R81.10 또는 R81.20)용 Jumbo Hotfix Accumulator 의 필요한 Take를 설치합니다.

sk181127에서 받은 Jumbo Hotfix Accumulator를 다음 지침에 따라 설치합니다.

  • Maestro Security Group — Security Group 멤버에 Hotfix 패키지를 설치하는 절차 참고.
  • Scalable Chassis — Scalable Chassis의 SGM에 Hotfix를 설치/제거하는 절차 참고.

Step 6 — Security Group의 CPUSE Deployment Agent 업그레이드

단계작업
Ask92449에서 받은 CPUSE Deployment Agent 패키지를 Security Group의 적당한 디렉터리(예: /var/log/)로 전송합니다.
BSecurity Group 명령줄에 접속합니다.
C기본 셸이 /etc/gclish(Gaia gClish)라면 Expert mode로 들어갑니다 — expert
D패키지가 있는지 확인합니다. ls -l /<Full Path>/<Name of CPUSE Deployment Agent Package>
ECPUSE Deployment Agent를 업그레이드합니다(아래).
F모든 멤버의 CPUSE Deployment Agent 빌드가 같은지 확인합니다. gclish -c "show installer status build"

E단계 명령과 예시입니다.

update_sp_da /<Full Path>/<Name of CPUSE Deployment Agent Package>
update_sp_da /var/log/DeploymentAgent_XXXXXXXXX.tgz

Step 7 — Security Group에 R82 업그레이드 패키지 가져오기

단계작업
A적용 가능한 CPUSE Offline 패키지(R82 Upgrade Package for Scalable Platforms)가 있는지 확인합니다.
B그 패키지를 Security Group의 적당한 디렉터리(예: /var/log/)로 전송합니다.
CSecurity Group 명령줄에 접속합니다.
D기본 셸이 /bin/bash(Expert mode)라면 Gaia gClish로 들어갑니다 — gclish
ESecurity Group에서 MDPS(sk138672)를 켰다면 Management Plane으로 갑니다 — set mdps environment mplane
F하드디스크에서 CPUSE Offline 패키지를 가져옵니다(아래).
G가져온 CPUSE 패키지를 봅니다. show installer packages imported
H가져온 패키지를 이 Security Group에 설치할 수 있는지 검증합니다(아래).

F단계 명령과 예시입니다.

installer import local /<Full Path>/<Name of the CPUSE Offline Package>
[Global] HostName-ch01-01 > installer import local /var/log/Check_Point_R82_Gaia_Install_and_Upgrade.tar

H단계 검증 명령과 예시입니다. installer verify 뒤에 Tab 을 눌러 패키지 번호를 확인할 수 있습니다.

installer verify [Press Tab]
installer verify <Number of CPUSE Package> member_ids all
[Global] HostName-ch01-01 > installer verify 2 member_ids all
... ...
Update Service Engine
+-----------------------------------------------------------+
|Member ID          |Status                |
+-----------------------------------------------------------+
|1_01 (local)       |Upgrade is allowed.   |
|1_02               |Upgrade is allowed.   |
|1_03               |Upgrade is allowed.   |
|1_04               |Upgrade is allowed.   |
|1_05               |Upgrade is allowed.   |
|1_06               |Upgrade is allowed.   |
|1_07               |Upgrade is allowed.   |
|1_08               |Upgrade is allowed.   |
+-----------------------------------------------------------+
[Global] HostName-ch01-01 >

Step 8 — 논리 그룹 "A" 멤버 업그레이드

여기서부터가 무중단 업그레이드의 핵심 입니다. 그룹 "A"를 먼저 DOWN시켜 트래픽에서 빼고, 그동안 그룹 "B"가 트래픽을 처리하게 한 뒤, "A"만 R82로 올립니다.

단계작업
A다음 중 한 방법으로 접속합니다 — 그룹 "A"의 한 멤버에 콘솔로 접속하거나, 그룹 "B"의 한 멤버에 SSH로 접속합니다.
B그룹 "A"의 한 멤버 컨텍스트로 갑니다. member <Member ID> (예: member 1_1)
C기본 셸이 /etc/gclish(Gaia gClish)라면 Expert mode로 들어갑니다 — expert
D그룹 "A"의 멤버들을 "DOWN" 상태로 만듭니다(아래).
E멤버 상태를 확인합니다 — asg monitor. 그룹 "A"는 "DOWN", 그룹 "B"는 "ACTIVE"여야 합니다.
FExpert mode에서 Gaia gClish로 갑니다. Expert mode(/bin/bash)가 기본이면 gclish, Gaia gClish(/etc/gclish)가 기본이면 exit.
G그룹 "A"의 멤버들을 업그레이드합니다(아래).
HGaia gClish에서 Expert mode로 갑니다. Expert mode 기본이면 exit, Gaia gClish 기본이면 expert.
I그룹 "A" 멤버들이 부팅을 마칠 때까지 asg monitor 로 지켜봅니다.

D단계 — 그룹 "A"를 DOWN으로:

g_clusterXL_admin –b <SGM IDs in Group "A""> down
g_clusterXL_admin –b 1_1-1_4 down

G단계 — 그룹 "A" 업그레이드(Tab 으로 패키지 번호 확인 가능):

installer upgrade [Press the Tab key]
installer upgrade <Number of CPUSE Package> member_ids <SGM IDs in Group "A">
[Global] HostName-ch01-01 > installer upgrade 2 member_ids 1_1-1_4
... ...
Update Service Engine
+-----------------------------------------------------------+
|Member ID          |Status                            |
+-----------------------------------------------------------+
|1_01 (local)       |Package is ready for installation |
|1_02               |Package is ready for installation |
|1_03               |Package is ready for installation |
|1_04               |Package is ready for installation |
+-----------------------------------------------------------+
The machines (1_02,1_02,1_03,1_04) will automatically reboot after upgrade.
Do you want to continue? ([y]es / [n]o) y
[Global] HostName-ch01-01 >

Step 9 — (Gateway 모드) SmartConsole에서 객체 버전 변경

단계작업
A이 Security Group을 관리하는 Management Server에 SmartConsole로 접속합니다.
B왼쪽 패널에서 Gateways & Servers 를 클릭합니다.
C이 Security Group의 Security Gateway 객체를 더블클릭합니다.
D왼쪽 트리에서 General 을 클릭합니다.
EVersion 필드에서 R82 를 선택합니다.
FOK 를 클릭합니다.
G세션을 Publish 합니다.
H이 Security Gateway 객체에 Access Control 정책을 설치합니다(아래 중요 참고).

정책을 설치한 뒤, Security Group(Expert mode)에서 멤버 상태를 확인합니다.

asg monitor

이때 상태는 업그레이드된 그룹 "A"는 "DOWN(READY)(R82)", 그룹 "B"는 "ACTIVE(<이전 버전>)" 여야 합니다.

Step 10 — 그룹 "A"를 "Up"으로

이제 정책까지 받은 그룹 "A"를 다시 트래픽에 투입합니다.

단계작업
A그룹 "A" 멤버들을 "UP" 상태로 만듭니다(아래).
Basg monitor 로 상태를 확인합니다.

A단계 명령과 예시입니다.

g_clusterXL_admin –b <SGM IDs in Group "A""> up
g_clusterXL_admin –b 1_1-1_4 up

이제 상태는 그룹 "A"는 "ACTIVE(R82)", 그룹 "B"는 "ACTIVE(<이전 버전>)" 여야 합니다.

Step 11 — 그룹 "B"를 "Down"으로

단계작업
A다음 중 한 방법으로 접속합니다 — 그룹 "B"의 한 멤버에 콘솔로 접속하거나, 그룹 "A"의 한 멤버에 SSH로 접속합니다.
B그룹 "B"의 멤버들을 "DOWN" 상태로 만듭니다(아래).

B단계 명령과 예시입니다.

g_clusterXL_admin –b <SGM IDs in Group "B""> down
g_clusterXL_admin –b 1_5-1_8 down

Step 12 — 그룹 "B" 멤버 업그레이드

문제가 없다면 이제 그룹 "B"도 R82로 올립니다.

단계작업
A그룹 "B"의 한 멤버에 콘솔로, 또는 그룹 "A"의 한 멤버에 SSH로 접속합니다.
B그룹 "B"의 한 멤버 컨텍스트로 갑니다. member <Member ID> (예: member 1_5)
C기본 셸이 /bin/bash(Expert mode)라면 Gaia gClish로 들어갑니다 — gclish
D그룹 "B"의 멤버들을 업그레이드합니다(아래).
EGaia gClish에서 Expert mode로 갑니다. Expert mode 기본이면 exit, Gaia gClish 기본이면 expert.
F그룹 "B" 멤버들이 부팅을 마칠 때까지 asg monitor 로 지켜봅니다.
G그룹 "B" 멤버들을 "UP" 상태로 만듭니다(아래).

D단계 — 그룹 "B" 업그레이드:

installer upgrade [Press the Tab key]
installer upgrade <Number of CPUSE Package> member_ids <SGM IDs in Group "B">
[Global] HostName-ch01-01 > installer upgrade 2 member_ids 1_5-1_8
... ...
Update Service Engine
+-----------------------------------------------------------+
|Member ID          |Status                            |
+-----------------------------------------------------------+
|1_05 (local)       |Package is ready for installation |
|1_06               |Package is ready for installation |
|1_07               |Package is ready for installation |
|1_08               |Package is ready for installation |
+-----------------------------------------------------------+
The machines (1_05,1_06,1_07,1_08) will automatically reboot after upgrade.
Do you want to continue? ([y]es / [n]o) y
[Global] HostName-ch01-01 >

F단계에서 상태는 그룹 "A"는 "ACTIVE(R82)", 그룹 "B"는 "DOWN(READY)(R82)" 여야 합니다.

G단계 — 그룹 "B"를 "UP"으로:

g_clusterXL_admin –b <SGM IDs in Group "B""> up
g_clusterXL_admin –b 1_5-1_8 up

Step 13 — 업그레이드 성공 확인

단계작업
ASecurity Group 명령줄에 접속합니다.
B기본 셸이 /etc/gclish(Gaia gClish)라면 Expert mode로 들어갑니다 — expert
C멤버 상태를 확인합니다 — asg monitor. 모든 멤버가 "ACTIVE" 여야 합니다.
D헬스 체크 명령을 실행합니다 — hcp -m all -r all

이것으로 무중단(MVC) 업그레이드가 완료됩니다.

Maestro Orchestrator 업그레이드 실패 시 되돌리기

R82로 올린 Orchestrator 업그레이드가 실패했을 때 업그레이드 직전 상태로 되돌리는 절차입니다.

시작 전 알아 둘 것

  • Security Group도 R82로 올렸다면, Orchestrator를 되돌리기 전에 모든 Security Group을 먼저 되돌려 야 합니다(Security Group 롤백 참고).
  • 이 롤백은 Orchestrator를 업그레이드 이전 구성(Gaia 구성, Security Group 토폴로지, 물리 포트 구성 등)으로 그대로 되돌립니다.
  • 롤백은 각 사이트에서 한 번에 한 Orchestrator씩 수행합니다.

Dual Site 환경의 순서

  1. 각 Security Group에서 모든 멤버를 한 사이트(예: Site 2)에서 다른 사이트(예: Site 1)로 failover 합니다. 상태 확인은 asg stat, 사이트 단위 failover는 set cluster site-id <Site ID> admin-state 명령을 씁니다.
  2. 멤버를 모두 빼낸 사이트(예시에서는 Site 2)의 각 Orchestrator에 롤백 절차를 적용 합니다.
  3. 각 Security Group에서 모든 멤버를 현재 사이트에서 방금 되돌린 사이트로 다시 failover합니다(예시에서는 Site 1 → Site 2).
  4. 멤버를 빼낸 사이트(예시에서는 Site 1)의 각 Orchestrator에 롤백 절차를 적용합니다.

Orchestrator 한 대마다 수행하는 절차

단계작업
1Orchestrator 명령줄에 접속합니다(예시에서는 "Orchestrator 1_1").
2기본 셸이 Gaia Clish(/etc/cli.sh)라면 Expert mode로 들어갑니다 — expert
3Orchestrator 서비스를 멈춥니다 — orchd stop
4Expert mode에서 Gaia Clish로 갑니다. Expert mode(/bin/bash)가 기본이면 clish, Gaia Clish(/etc/cli.sh)가 기본이면 exit.
5업그레이드 중 자동 생성된 Gaia 스냅샷을 복원합니다 — set snapshot revert[Press Space][Press Tab]. Orchestrator가 자동 재부팅되며 복원을 시작합니다.
6되돌린 Orchestrator가 부팅을 마칠 때까지 기다립니다.
7환경 내 다른 모든 Orchestrator에 같은 날짜·시각 설정 을 맞춥니다.
8모든 Orchestrator가 서로 통신되는지 확인합니다(아래 ping).
9Security Group Member끼리 트래픽이 오가는지 확인합니다(아래).
10각 멤버에서 Security Group의 모든 링크가 UP인지 확인합니다(아래).

5단계 스냅샷 복원에 관한 자세한 내용은 Gaia 가이드의 Maintenance 장 Snapshot Management 절을 참고합니다.

8단계 — Orchestrator 간 통신 확인입니다. Single Site에서는 ping 1_2, Dual Site에서는 다음을 모두 확인합니다.

ping 1_2
ping 2_1
ping 2_2

9단계 — 멤버 간 트래픽 확인:

  1. Security Group 명령줄에 접속합니다.
  2. 기본 셸이 Gaia gClish(/etc/gclish)라면 Expert mode로 들어갑니다 — expert
  3. SMO 멤버에서 클러스터 상태를 확인합니다. 모든 멤버가 active로 나와야 합니다.
   cphaprob state
  1. 멤버끼리 ping을 보냅니다. 먼저 한 멤버(예: 1_1)로 들어가서 — member 1_1 — 다른 멤버로 ping합니다. Single Site는 ping 1_2, Dual Site는 ping 1_2 와 ping 2_2.

10단계 — 링크 상태 확인:

  1. Security Group 명령줄에 접속합니다.
  2. Gaia gClish에 로그인합니다.
  3. 링크 상태를 확인합니다.
   show cluster info interfaces

이것으로 Orchestrator 롤백 절차가 끝납니다.