11관리 서버 업그레이드관리 서버 업그레이드

세 방식의 차이를 다시 짚으면 이렇습니다. CPUSE 는 같은 컴퓨터에서 그대로 올리는 가장 단순한 방식입니다. Advanced Upgrade 는 같은 컴퓨터에서 데이터베이스를 export한 뒤 깨끗이 다시 깔고 import합니다. Migration(Migration and Upgrade)은 소스 서버에서 export해 별도의 새 R82 컴퓨터 에 import합니다. 하드웨어를 바꾸거나 OS를 옮긴다면 Advanced나 Migration이 답입니다.

이 장에서 거듭 나오는 두 가지 핵심 도구가 있습니다. 하나는 Upgrade Tools(migrate_server 명령을 포함)이고, 다른 하나는 IP를 바꿀 때 쓰는 특수 JSON 구성 파일 /var/log/mdss.json 입니다. 이 둘은 서버 종류와 무관하게 똑같이 동작하므로, 먼저 한 번만 설명하고 이후 각 절에서는 반복하지 않고 가리키겠습니다.

Upgrade Tools 준비와 빌드 번호 확인

세 방식 모두 시작 단계에서 소스 서버(그리고 Migration·Advanced에서는 타깃 R82 서버에도) R82 Upgrade Tools를 올려 둬야 합니다. 업그레이드 옵션과 사전 준비의 "Upgrade Tools" 항목에서 이 서버가 최신 버전을 자동으로 내려받아 설치할 수 있는지 먼저 확인하세요. 인터넷에 연결돼 있으면 자동으로 최신 버전이 깔리고, 아니면 수동으로 깝니다.

   cpprod_util CPPROD_GetValue CPupgrade-tools-R82 BuildNumber 1
   

출력된 빌드 번호는 내려받은 TGZ 패키지 이름에 들어 있는 빌드 번호와 같아야 합니다. 예를 들어 패키지 이름이 ngm_upgrade_wrapper_993000222_1.tgz 라면 다음처럼 나옵니다.

   Name of the downloaded package: ngm_upgrade_wrapper_993000222_1.tgz
   [Expert@HostName:0]# cpprod_util CPPROD_GetValue CPupgrade-tools-R82 BuildNumber 1
   993000222
   [Expert@HostName:0]#
   

그래서 migrate_server의 모든 하위 명령(verify·export·import)에는 인터넷이 없을 때 쓰는 -skip_upgrade_tools_check 플래그 가 있습니다. 인터넷에 연결돼 있으면 플래그 없이, 없으면 이 플래그를 붙여 실행한다고 기억하면 이 장의 거의 모든 명령이 풀립니다.

IP를 바꿀 때만 필요한 JSON 구성 파일

업그레이드하면서 서버의 IP 주소를 바꾸는 경우에만 /var/log/mdss.json 이라는 특수 구성 파일이 필요합니다. 규칙은 단순합니다.

파일 형식은 옮길 서버마다 SmartConsole 객체 이름과 새 IPv4 주소를 짝지어 적는 것입니다. Log Server 하나를 옮기는 가장 단순한 예는 이렇습니다.

[{"name":"<SmartConsole의 Log Server / SmartEvent Server 객체 이름>","newIpAddress4":"<R82 Log Server / SmartEvent Server의 새 IPv4 주소>"}]

예를 들어 R80.30 환경에 Security Management Server와 Log Server 둘이 있고, 관리 서버는 IP를 유지하되 Log Server만 192.168.10.21 에서 172.30.40.51 로 옮긴다면(객체 이름 MyLogServer), 두 서버 모두에 다음 파일을 둡니다.

[{"name":"MyLogServer","newIpAddress4":"172.30.40.51"}]

---

이 절은 Security Management Server, CloudGuard Controller, 전용 Log Server, 전용 SmartEvent Server 에 똑같이 적용됩니다(Migration은 CloudGuard Controller를 제외). 세 방식 모두 시작 전에 챙길 공통 사전 점검이 있습니다.

방식 1 — CPUSE로 올리기

CPUSE 시나리오에서는 같은 Check Point 서버에서 그대로 업그레이드를 진행합니다. R80.20.M1·R80.20·R80.20.M2·R80.30 이상에서만 지원됩니다.

      SmartEvent Policy Installer installation complete
      SmartEvent Policy Installer installation succeeded
      

자세한 내용은 R82 SmartProvisioning Administration Guide를 참고하세요. 10. 동작을 점검 합니다. R82 관리 서버에 SmartConsole로 연결해 관리 데이터베이스와 구성이 올바르게 업그레이드 됐는지 확인합니다.

방식 2 — Advanced Upgrade로 올리기

Advanced Upgrade도 같은 컴퓨터 에서 진행하지만, 데이터베이스를 export한 뒤 R82을 깨끗이 다시 깔고 import한다는 점이 다릅니다.

      cd $FWDIR/scripts
      

      ./migrate_server verify -v R82
      

인터넷이 없으면 -skip_upgrade_tools_check 를 붙입니다.

      ./migrate_server verify -v R82 -skip_upgrade_tools_check
      

      ./migrate_server export -v R82 [-l | -x] /<전체 경로>/<export 파일 이름>
      

      md5sum /<전체 경로>/<데이터베이스 파일 이름>.tgz
      

먼저 IP를 바꿨다면 위 JSON 구성 파일 절차대로 타깃 서버에 /var/log/mdss.json 을 만듭니다. 관리 서버 하나를 새 IP로 옮기는 형식은 이렇습니다.

   [{"name":"<SmartConsole의 Security Management Server 객체 이름>","newIpAddress4":"<R82 관리 서버의 새 IPv4 주소>"}]
   

그다음 import합니다.

      cplic print
      

      md5sum /<전체 경로>/<데이터베이스 파일 이름>.tgz
      

      cd $FWDIR/scripts/
      ./migrate_server import -v R82 [-l | -x] /<전체 경로>/<export 파일 이름>.tgz
      

      cpstart
      

방식 3 — Migration으로 올리기

Migration 시나리오는 소스 서버와 별개의 타깃 서버 두 대에서 진행합니다. 그래서 마지막에 네트워크 케이블을 옮기는 단계가 더 붙습니다. CloudGuard Controller에는 이 방식이 적용되지 않습니다.

1~13단계는 위 Advanced Upgrade 와 사실상 동일합니다 — Upgrade Tools 준비, 소스에서 Pre-Upgrade Verifier·export, 새 R82 서버 설치, 타깃에 Upgrade Tools 준비, JSON 만들고 import, SmartConsole 설치, (IP 변경 시) 새 라이선스 설치, 전용 Log Server·SmartEvent Server 업그레이드와 객체 버전 갱신, 관리 데이터베이스 설치, Event Policy 설치, SmartLSM 정책 설치, 동작 점검. 차이는 소스와 타깃이 물리적으로 다른 컴퓨터 라는 전제와, 마지막 두 단계입니다.

Management High Availability에서 관리 서버 올리기

이 절차는 Security Management Server 와 CloudGuard Controller 에 똑같이 적용됩니다. 사전 점검은 위 공통 점검과 같고, 한 가지가 더 있습니다.

핵심은 Primary를 먼저 완전히 올린 뒤 Secondary를 올리는 순서입니다.

HA에서 IP를 바꿀 때의 JSON 형식

Primary만, Primary와 Secondary 둘 다, 또는 거기에 Log Server까지 새 IP로 옮기는지에 따라 형식이 달라집니다.

# Primary만 새 IP로
[{"name":"<Primary 관리 서버 객체 이름>","newIpAddress4":"<Primary R82 새 IPv4>"}]

# Primary와 Secondary 둘 다 새 IP로
[{"name":"<Primary 관리 서버 객체 이름>","newIpAddress4":"<Primary R82 새 IPv4>"},
{"name":"<Secondary 관리 서버 객체 이름>","newIpAddress4":"<Secondary R82 새 IPv4>"}]

# Primary·Secondary·Log Server 모두 새 IP로
[{"name":"<Primary 관리 서버 객체 이름>","newIpAddress4":"<Primary R82 새 IPv4>"},
{"name":"<Secondary 관리 서버 객체 이름>","newIpAddress4":"<Secondary R82 새 IPv4>"},
{"name":"<Security Management Server 객체 이름>","newIpAddress4":"<R82 새 IPv4>"}]

예를 들어 Primary(MyPrimarySecMgmtServer)를 172.30.40.51 로, Secondary(MySecondarySecMgmtServer)를 172.30.40.52 로 옮기고 Log Server는 그대로 둔다면, Primary·Secondary·Log Server 모두에 다음 파일을 둡니다.

{"name":"MySecondarySecMgmtServer","newIpAddress4":"172.30.40.52"}]

---

Multi-Domain Server(MDS) 도 같은 세 방식을 따르되, 규모가 크고 도메인이 여럿이라 단계가 더 촘촘 합니다. 단독 MDS, HA의 MDS 쌍, 그리고 별개로 Multi-Domain Log Server(MDLS) 의 업그레이드를 차례로 봅니다.

MDS 업그레이드의 사전 점검은 일반 관리 서버와 비슷하지만 Global Domain에 대한 항목이 추가 됩니다.

단독 Multi-Domain Server 올리기

방식 1 — CPUSE

      cat $MDSDIR/conf/mdsdb/webservices_cmas_ports.conf
      

예시 출력은 이렇습니다.

      : (My_Domain_Management_Server_1
      :port (30000)
      :port_SL (30001)
      :ip_addr (192.168.2.1)
      )
      : (My_Domain_Management_Server_2
      :port (30002)
      :port_SL (30003)
      :ip_addr (192.168.2.2)
      )
      )
      

      vi $UDMDIR/conf/cmas_list.conf
      

예시는 이렇습니다.

      192.168.2.2:WSPort=30002:MDSip=192.168.2.254
      

      udmstop ; udmstart
      

방식 2 — Advanced Upgrade

      $MDS_FWDIR/scripts/migrate_server verify -v R82
      

      cd $MDS_FWDIR/scripts
      ./migrate_server export -v R82 [-l | -x] /<전체 경로>/<export 파일 이름>
      

      md5sum /<전체 경로>/<데이터베이스 파일 이름>.tgz
      

      cd $MDS_FWDIR/scripts/
      ./migrate_server import -v R82 [-l | -x] /<전체 경로>/<export 파일 이름>.tgz
      

어떤 Domain Management Server의 데몬이 "down"이면 5~10분 기다린 뒤 그 Domain Management Server를 재시작하고 다시 확인합니다.

      mdsstop_customer <Domain Management Server의 IP 또는 이름>
      mdsstart_customer <Domain Management Server의 IP 또는 이름>
      mdsstat
      

방식 3 — Migration

Migration은 소스 MDS와 별개의 타깃 MDS 두 대에서 진행합니다. 1~10단계는 위 Advanced Upgrade와 사실상 같고(소스에서 verify·export, 새 R82 MDS Clean Install, Upgrade Tools 준비, import와 mdsstat 확인, SmartConsole·전용 서버 업그레이드, UDM 재구성, SmartLSM 정책, 동작 점검), 마지막에 케이블을 옮기는 두 단계가 더 붙습니다.

High Availability의 Multi-Domain Server 올리기

HA에서는 Primary와 Secondary 두 MDS를 함께 다루며, 시작 전에 항상 (1) Primary가 없으면 Secondary를 Primary로 승격(promote) 하고, (2) Global Domain이 Primary에서 Active 인지 확인합니다.

Primary가 없으면 Secondary를 Primary로 승격 — R82 Multi-Domain Security Management Administration Guide의 "Working with High Availability > Failure Recovery > Promoting the Secondary Multi-Domain Server to Primary" 를 따릅니다.

Global Domain이 Primary에서 Active인지 확인 —

방식 1 — CPUSE (HA)

위 두 사전 단계 뒤에:

방식 2 — Advanced Upgrade (HA)

HA의 Advanced Upgrade는 Primary와 Secondary 양쪽 모두에서 export하고 양쪽 모두 새 R82으로 다시 설치 한다는 점이 단독과 다릅니다. import 명령도 IP 변경 여부에 따라 형식이 갈립니다.

   cd $MDS_FWDIR/scripts
   ./migrate_server export -v R82 [-l | -x] /<전체 경로>/Primary_<export 파일 이름>
   md5sum /<전체 경로>/Primary_<데이터베이스 파일 이름>.tgz
   

MD5를 계산하고 바이너리 모드 로 외부 저장소에 옮깁니다. 7. Secondary MDS에서 전체 관리 데이터베이스를 export 합니다. Secondary_ 접두사 를 붙입니다.

   cd $MDS_FWDIR/scripts
   ./migrate_server export -v R82 [-l | -x] /<전체 경로>/Secondary_<export 파일 이름>
   md5sum /<전체 경로>/Secondary_<데이터베이스 파일 이름>.tgz
   

IP를 바꿨다면 먼저 JSON 파일을 만듭니다. 형식은 HA에서 IP를 바꿀 때의 형식을 따릅니다. 그다음:

       cd $MDS_FWDIR/scripts/

       # 인터넷 연결 + IP 변경 없음
       ./migrate_server import -v R82 [-l | -x] /<전체 경로>/Primary_<export 파일 이름>.tgz

       # 인터넷 연결 + IP 변경 있음 (/var/log/mdss.json 존재 확인 후)
       ./migrate_server import -v R82 [-l | -x] /var/log/mdss.json /<전체 경로>/Primary_<export 파일 이름>.tgz

       # 인터넷 없음 + IP 변경 없음
       ./migrate_server import -v R82 -skip_upgrade_tools_check [-l | -x] /<전체 경로>/Primary_<export 파일 이름>.tgz

       # 인터넷 없음 + IP 변경 있음
       ./migrate_server import -v R82 [-l | -x] -skip_upgrade_tools_check /var/log/mdss.json /<전체 경로>/Primary_<export 파일 이름>.tgz
       

방식 3 — Migration (HA)

Migration HA는 Advanced HA와 흐름이 같되 Primary·Secondary 모두 별개의 새 컴퓨터에 Clean Install 한다는 점이 다릅니다. 순서는 이렇습니다 — Secondary 승격·Global Active 확인 → 양쪽 Upgrade Tools 준비 → Primary·Secondary 각각 Pre-Upgrade Verifier → Primary·Secondary 각각 Primary_·Secondary_ 접두사로 export → 다른 서버에 Primary R82 MDS Clean Install → Primary에 Upgrade Tools 준비 → Primary import(네 가지 형식 + mdsstat) → 다른 서버에 Secondary R82 MDS Clean Install → Secondary에 Upgrade Tools 준비 → Secondary import → Secondary 객체 버전 갱신 → MDLS·전용 서버 업그레이드 → UDM 재구성 → SmartLSM 정책 → Primary R82 MDS에서 동작·HA 점검.

HA에서 IP를 바꿀 때의 MDS JSON 형식

Primary만, Primary와 Secondary 둘 다, 또는 거기에 MDLS까지 옮기는지에 따라 형식이 달라집니다.

# Primary MDS만 새 IP로
[{"name":"<Primary MDS 객체 이름>","newIpAddress4":"<Primary R82 MDS 새 IPv4>"}]

# Primary와 Secondary MDS 둘 다 새 IP로
[{"name":"<Primary MDS 객체 이름>","newIpAddress4":"<Primary R82 MDS 새 IPv4>"},
{"name":"<Secondary MDS 객체 이름>","newIpAddress4":"<Secondary R82 MDS 새 IPv4>"}]

# Primary·Secondary MDS와 MDLS 모두 새 IP로
[{"name":"<Primary MDS 객체 이름>","newIpAddress4":"<Primary R82 MDS 새 IPv4>"},
{"name":"<Secondary MDS 객체 이름>","newIpAddress4":"<Secondary R82 MDS 새 IPv4>"},
{"name":"<Multi-Domain Log Server 객체 이름>","newIpAddress4":"<R82 MDLS 새 IPv4>"}]

예를 들어 Primary(MyPrimaryMDS)를 172.30.40.51, Secondary(MySecondaryMDS)를 172.30.40.52 로 옮기고 MDLS는 그대로 둔다면, Primary·Secondary·MDLS 모두에 다음 파일을 둡니다.

{"name":"MySecondaryMDS","newIpAddress4":"172.30.40.52"}]

업그레이드 중 Domain Management Server 다루기

비즈니스 모델상 관리 다운타임을 감당할 수 없어 업그레이드 중에도 계속 관리해야 한다면 그렇게 할 수 있습니다. 다만 업그레이드 중 Domain Management Server 데이터베이스를 바꾸면, 서로 다른 MDS의 인스턴스 간에 데이터베이스 내용이 어긋날 위험 이 있고 동기화 과정으로는 이 불일치를 해소할 수 없 습니다.

한 MDS를 성공적으로 올린 뒤, 나머지를 올리는 동안 그 MDS의 Domain Management Server를 Active로 둘 수 있습니다. 동기화는 모든 MDS가 업그레이드된 뒤에 일어 납니다.

만약 업그레이드 중 서로 다른 MDS에서 Domain Management Server 데이터베이스를 바꿨다면 내용이 달라지고, 동기화가 불가능하므로 일부 변경은 사라집니다. 이때 Domain Management Server HA 상태는 Collision 으로 나타납니다. 어느 데이터베이스 버전을 남길지 직접 정해 다른 Domain Management Server로 동기화한 뒤, 사라진 변경을 동기화된 데이터베이스에 다시 입력 해야 합니다(같은 객체와 설정을 다시 구성).

Multi-Domain Log Server 올리기

Multi-Domain Log Server(MDLS) 는 반드시 Multi-Domain Server를 먼저 올린 뒤, 같은 버전으로 올립니다. 사전 점검은 다음과 같습니다.

방식 1 — CPUSE

   [{"name":"<서버 #1 객체 이름>","newIpAddress4":"<R82 서버 #1 새 IPv4>"},
   {"name":"<서버 #2 객체 이름>","newIpAddress4":"<R82 서버 #2 새 IPv4>"}]
   

방식 2 — Advanced Upgrade

어떤 Domain Log Server에서 FWM·FWD·CPD 중 하나가 "down"이면 5~10분 기다린 뒤 재시작하고 다시 확인합니다.

   mdsstop_customer <Domain Log Server의 IP 또는 이름>
   mdsstart_customer <Domain Log Server의 IP 또는 이름>
   mdsstat
   

방식 3 — Migration

Migration은 소스와 별개의 타깃 MDLS 에서 진행합니다. 1~9단계는 Advanced와 같되, 3단계의 새 MDLS 설치에는 중요한 제약이 있습니다.

마지막에 케이블을 옮기는 두 단계가 더 붙습니다.

---

Endpoint Security Management Server 와 Endpoint Policy Server 도 동일한 패턴 — CPUSE·Advanced Upgrade·Migration — 으로 R80.20.M1·R80.20·R80.20.M2·R80.30 이상에서 R82으로 올립니다. 두 서버 종류에 똑같이 적용되며, 이 절에서는 둘을 묶어 Endpoint Server 라고 부르겠습니다. 사전 점검은 일반 관리 서버와 같습니다(백업, 사전 준비 확인, 최신 리비전 Publish, SmartConsole 닫기, 최신 CPUSE, 모든 소스 서버에서 Pre-Upgrade Verifier, HA라면 Primary 먼저).

방식 1 — CPUSE

   [{"name":"<SmartConsole의 서버 객체 이름>","newIpAddress4":"<R82 서버의 새 IPv4 주소>"}]
   

방식 2 — Advanced Upgrade

      cd $FWDIR/scripts
      

      ./migrate_server verify -v R82
      

      ./migrate_server export -v R82 [-l | -x] /<전체 경로>/<export 파일 이름>
      

IP를 바꿨다면 먼저 /var/log/mdss.json 을 만듭니다(Endpoint 서버 하나를 옮기는 형식).

   [{"name":"<SmartConsole의 Endpoint Server 객체 이름>","newIpAddress4":"<R82 Endpoint Server 새 IPv4 주소>"}]
   

그다음 라이선스 확인(cplic print), 전송·MD5 비교 후 $FWDIR/scripts/ 에서 import합니다.

   cd $FWDIR/scripts/
   ./migrate_server import -v R82 [-l | -x] /<전체 경로>/<export 파일 이름>.tgz
   

방식 3 — Migration

Migration은 소스와 별개의 타깃 컴퓨터 에서 진행합니다. 1~12단계는 위 Advanced Upgrade와 사실상 동일하며(export에 --include-uepm-msi-files 옵션, import 자동 재시작 등 Endpoint 특유 사항 그대로 적용), 마지막에 케이블을 옮기는 두 단계가 더 붙습니다.

Management High Availability에서 Endpoint 서버 올리기

일반 관리 서버와 마찬가지로 Primary를 먼저 올려 돌게 한 뒤 Secondary 를 올립니다.

---

세 방식 모두, R80.20.M1·R80.20·R80.20.M2·R80.30 이상에서 R82으로 올릴 때 각 단계마다 업그레이드 보고서가 생성 됩니다 — Gaia Portal에서 실시간으로 보거나 $MDS_FWDIR/log/upgrade_report-<날짜시간>.html 에서 확인합니다. 보고서가 "진행 전에 고칠 항목"으로 표시한 것을 모두 해결한 뒤에야 안전하게 진행하세요. 업그레이드가 끝나면 기록해 둔 커스텀 설정을 새 파일에 직접 다시 적용 하는 것을 잊지 마세요(옛 파일을 그대로 복사하면 안 됩니다).

관리 서버 계열을 모두 올렸다면, 이제 그것이 관리하는 장비를 올릴 차례입니다 — Security Gateway·클러스터 업그레이드로 넘어갑니다.