10업그레이드 옵션과 사전 준비업그레이드 옵션과 사전 준비

업그레이드에는 절대 어기면 안 되는 순서 가 있습니다. 관리 서버를 먼저 올린 뒤에야 그것이 관리하는 게이트웨이·Cluster Member를 올릴 수 있습니다. 또 관리 서버가 거느린 전용 Log Server·SmartEvent Server는 관리 서버와 같은 버전으로 올려야 하고(SmartEvent Server는 Log Server와 같거나 높은 버전 가능), Multi-Domain Log Server는 Multi-Domain Server와 같은 버전으로 올려야 합니다. 이 순서를 지키지 않으면 관리가 어긋납니다.

지원되는 업그레이드 경로·최소 하드웨어·지원 게이트웨이는 R82 Release Notes에서, 알려진 제한은 R82 Known Limitations SK에서 반드시 먼저 확인하세요. 또 소스·대상 모든 컴퓨터에 유효한 라이선스와, 소프트웨어 업그레이드·메이저 릴리스를 포함하는 Service Contract 가 등록돼 있어야 합니다(라이선스 관리, sk33089).

가장 먼저 백업을 챙기고, 그다음 커스텀 설정을 따로 적어 둡니다. 업그레이드 과정은 기존 파일을 모두 기본 파일로 덮어쓰므로, 옛 버전의 커스텀 구성 파일을 새 버전에 그대로 복사하면 안 됩니다 — 버전마다 파일이 다를 수 있기 때문입니다. 그래서 $FWDIR/conf/·$FWDIR/lib/·$CVPNDIR/conf/·$MDSDIR/conf/ 같은 디렉터리와 fwkern.conf·fwaffinity.conf·local.arp 같은 파일의 커스텀 변경을 기록해 두고, 업그레이드 후에 새 파일에 직접 다시 적용 해야 합니다(.CPprofile.sh 등 프로파일 스크립트에 특히 주의). VSX 환경에서는 이 디렉터리·파일 일부가 각 Virtual Device의 맥락에 따로 존재한다는 점도 유의하세요.

로그 보존 범위도 미리 정합니다. R81.20부터 관리 서버·Log Server를 올릴 때 로그 마이그레이션이 최근 180일치로 제한 됩니다. 이를 30~360일 사이로 바꾸려면 Expert 모드에서 $FWDIR/conf/upgradeLogData.xml 파일을 만들어 <ImportLogDays> 값을 지정합니다. 외부 저장 장치가 연결돼 있다면 sk66003에 따라 업그레이드 전에 장치를 분리하고, 올린 뒤 다시 연결해 로그 인덱스 설정을 복구 합니다.

Multi-Domain 환경에서는 업그레이드를 최적화하는 사전 작업이 권장됩니다 — Global Domain에서 쓰지 않는 Threat Prevention Profile을 지우고, IPS protection의 Staging Mode를 끄는 것입니다(sk142432). 그리고 업그레이드·마이그레이션을 시작하기 전에 연결된 모든 SmartConsole을 닫 아야 합니다.

가용성 구성은 순서를 신중히 잡아야 합니다. Security Management Server HA에서는 Primary를 먼저 올린 뒤, 두 서버가 통신하고 SIC가 정상인지 확인(sk179794)하고 Secondary를 올립 니다(R80.20.M1 소스라면 Secondary는 clean install 후 Primary에 연결). Multi-Domain Server HA에서는 모든 소스 서버에서 Pre-Upgrade Verifier를 돌려 문제를 고치고, Primary에서 Global Domain이 Active인지 확인한 뒤 Primary를 올리고, 통신·SIC를 확인하고 Secondary를 올립 니다. 어느 경우든 일관성을 위해 HA 환경의 모든 서버 백업·스냅샷은 같은 시점에 함께 수집·복원합니다.

디스크 공간 요건도 봅니다 — 대상 서버의 /var/log/ 파티션은 소스의 최소 25% 이상 이어야 하고, Advanced Upgrade·Migration이라면 하드 디스크가 내보낸 데이터베이스 크기의 최소 5배 여야 합니다. 소스가 IPv4만(또는 IPv6만) 쓴다면 대상도 같은 IP 구성을 써야 합니다(업그레이드 후 변경은 가능).

대상에 따라 쓸 수 있는 방식이 다릅니다.

게이트웨이·Cluster Member 는 Central Deployment(권장) — SmartConsole에서 Check Point Cloud나 Package Repository의 패키지를 관리되는 장비에 배포 하거나, 명령줄 버전인 Central Deployment Tool(sk111158), 또는 각 Gaia에서 직접 CPUSE 로 올립니다.

관리 서버·Log Server 는 세 갈래입니다. CPUSE 는 현재 Gaia에서 도는 컴퓨터를 같은 자리에서 그대로 올리 고(가장 단순, sk92449), Advanced Upgrade 는 같은 컴퓨터에서 R82 Management Server Migration Tool로 데이터베이스를 export한 뒤, Gaia면 업그레이드·다른 OS면 clean install하고 다시 import 하며, Migration and Upgrade 는 소스에서 데이터베이스를 export해 별도의 새 R82 컴퓨터에 import 합니다. CPUSE는 현재 Gaia에서 도는 경우에만 쓸 수 있 으므로, OS를 바꾸거나 하드웨어를 옮긴다면 Advanced Upgrade나 Migration을 택합니다.

관리 서버를 R82으로 올리기 전에 소프트웨어 업그레이드·메이저 릴리스를 포함하는 유효한 Support Contract가 User Center 계정에 등록 돼 있어야 합니다. 업그레이드 과정은 Contract File이 있는지 확인하는데, 대개는 관리 서버가 User Center와 자동으로 통신해 최신 파일을 내려받으므로 신경 쓸 일이 없 습니다. 없으면 User Center에서 수동으로 받아 import하면 됩니다(인터넷이 없는 서버는 다른 컴퓨터에서 받아 옮겨 "Import a local contracts file"). 계약이 서버를 덮지 않으면 자격 없음 메시지가 뜨지만, 유효한 Contract File이 없어도 업그레이드 자체가 막히지는 않 습니다(라이선스 위반이 될 수 있으니 나중에라도 받아 두세요).

업그레이드를 떠받치는 도구가 Upgrade Tools 입니다. 항상 sk135172의 최신 버전을 써야 하며, 인터넷에 연결돼 "Allow Download" 동의 플래그가 켜져 있으면 서버가 자동으로 최신 버전을 받아 깝니다(없으면 수동 설치).

이 도구는 현재 관리 데이터베이스를 문제없이 올릴 수 있는지 검사(Pre-Upgrade Verifier, PUV)하고, 업그레이드를 실패시킬 수 있는 문제 목록을 담은 보고서를 생성 합니다. 보고서는 세 갈래로 나뉩니다 — 업그레이드 전에 고칠 항목(잘못된 정책 이름 같은 에러), 업그레이드 후에 고칠 항목, 그리고 단순 정보 메시지 입니다. 핵심 파일은 데이터베이스와 구성을 export·import하는 migrate_server 와, Advanced Upgrade·Database Migration 설정을 담는 migrate.conf 입니다.

사전 준비를 마쳤으니, 이제 대상별 실제 업그레이드로 들어갑니다 — 먼저 관리 서버 업그레이드부터입니다.