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

다시 강조하지만 게이트웨이·Cluster Member를 올리기 전에 반드시 관리 서버와 Log Server를 먼저 올려야 합니다(앞 장). 그다음 백업을 받고, 필요하면 게이트웨이 라이선스를 올리고(라이선스 관리), VSX Cluster라면 관리 서버에서 VSX Cluster 객체 구성을 R82으로 먼저 올립 니다.

단일 장비는 CPUSE나 Central Deployment(권장)로 올립니다. Central Deployment는 SmartConsole에서 Check Point Cloud나 Package Repository의 패키지를 장비에 배포 하므로 여러 대를 한꺼번에 다루기 좋고, CPUSE는 각 Gaia에서 직접 올릴 때 씁니다. VSX Gateway도 CPUSE로 올릴 수 있되, 앞서 말한 대로 관리 서버 쪽 VSX 객체 구성을 먼저 R82으로 맞춰 두어야 합니다.

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

시작 전 점검도 더 깐깐합니다. 전체 유지보수 창(maintenance window)을 잡아 업그레이드 후 커스텀 설정을 다시 적용할 시간을 확보 하고(기본 파일로 덮어써 커스텀이 사라지면 멤버가 서로를 못 보거나 트래픽이 끊길 수 있음), 모든 멤버에서 필수 커널 파라미터 값이 같은지 확인 합니다 — Cluster Member는 cphaprob mmagic 로 "MAC magic"·"MAC forward magic"을, VSX Cluster Member는 fwha_add_vsid_to_ccp_mac 값을 봅니다(sk25977).

다운타임을 기준으로 세 갈래입니다. ClusterXL·VSX Cluster·VRRP(Gaia 위 3rd party) 클러스터 모두에 쓸 수 있습니다.

Multi-Version Cluster(MVC) Upgrade 는 연결 유지가 최우선일 때 고릅니다. 업그레이드 전에 시작된 연결을 새 버전 멤버와 동기화해 끊김을 보장하지 않습니다 — 즉 연결 페일오버가 보장 되고 다운타임 창도 필요 없으며 소요 시간도 짧습니다. 다만 특정 업그레이드 경로만 지원하고, 페일오버 뒤 살아남지 못하는 연결 유형이 많 다는 제약이 있습니다(원문의 지원 버전·제한 절 확인). Gateway 모드와 VSX 모드 절차가 각각 있습니다.

Minimum Effort Upgrade(Simple Upgrade)는 다운타임이 허용될 때 쓰는 가장 단순한 방식입니다. 각 Cluster Member를 독립된 Security Gateway처럼 따로 올리 므로 절차가 쉽지만, 업그레이드 전에 시작된 모든 연결이 끊기 고 멤버를 다 올릴 때까지 상당한 다운타임이 필요합니다.

Minimum Downtime Upgrade 는 다운타임을 거의 둘 수 없을 때 쓰는 절충안입니다. 업그레이드 내내 트래픽을 처리하는 Active 멤버가 항상 하나 이상 있어 네트워크 연결은 유지 되지만, 옛 버전 멤버를 거쳐 시작된 연결은 그 멤버를 올릴 때 끊깁 니다(버전이 다른 멤버끼리 동기화가 안 되기 때문). 새로 올린 멤버를 거친 연결은 끊기지 않습니다. 짧은 다운타임 창만 있으면 되지만, Dynamic Routing 연결은 지원하지 않 습니다.

Full High Availability 클러스터는 관리 서버와 게이트웨이가 같은 두 appliance에 얹혀 있어 업그레이드 순서가 특별합니다. 관리 서버 업그레이드와 클러스터 업그레이드의 성격을 모두 갖 기 때문에, 원문 "Upgrading a Full High Availability Cluster" 절의 순서를 그대로 따라야 합니다.

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