03요구사항·호환성요구사항·호환성

ClusterXL은 Distributed(멤버와 관리 서버를 다른 컴퓨터에) 또는 Full High Availability(멤버와 관리 서버를 같은 컴퓨터에, 각자 Standalone) 로 설치합니다(Open Server는 Distributed만 가능).

멤버 수는 모드별로 다릅니다 — HA·Load Sharing 모드는 최대 5대(단 4대 초과 시 Delta Sync 부담으로 성능 저하), Gaia VRRP 클러스터는 2대, VSLS(Virtual System Load Sharing)는 최대 13대 입니다.

ClusterXL의 핵심 전제는 멤버들이 동일해야 한다 는 것입니다. ClusterXL은 하드웨어 클록 틱 기반의 내부 타이머에 의존 하므로 CPU 특성이 같은 장비끼리만 지원됩니다. 또 CCP 문제로 인한 예기치 않은 페일오버를 막기 위해 동일한 물리 인터페이스끼리 짝지을 것 이 강력히 권장됩니다.

소프트웨어도 마찬가지입니다 — 운영체제·Check Point 버전(OS 빌드·핫픽스 포함)이 동일 해야 하고, 켜진 Software Blade·기능, SecureXL 상태, CoreXL Firewall 인스턴스 수, Advanced Dynamic Routing 설정이 모두 같아야 합니다. 다르면 트래픽 처리가 어긋나거나 상태가 예기치 않게 바뀌고 Full Sync가 실패합니다(예: CoreXL 인스턴스가 더 많은 멤버는 DOWN 상태가 됨).

HA나 Load Sharing Unicast 모드에서는 단일 멤버(Active 또는 Pivot)가 VIP와 연결 됩니다. 페일오버 후 새 Active가 GARP를 뿌려 VIP를 자기 MAC에 다시 연결하는데, Static NAT 항목이 많으면 GARP가 너무 많아 스위치가 ARP 테이블을 못 따라가 거나, VoIP 전화 같은 장비가 GARP를 무시 해 죽은 멤버로 계속 트래픽을 보내는 일이 생깁니다.

이를 막는 것이 VMAC(Virtual MAC) 입니다. 모든 멤버가 같은 Virtual MAC을 VIP에 연결 하면, 페일오버 때 MAC이 바뀌지 않으니 스위치·장비가 ARP를 갱신할 필요가 없 어 전환이 더 빠르고 매끄럽습니다(설정은 고급 기능 참고).

동기화 네트워크는 여러 토폴로지로 구성할 수 있습니다. Sync 인터페이스를 여러 물리 인터페이스의 Bond로 묶 어, 같은 스위치에 연결하거나(Topology 1·2) Active-Backup Bond로 서로 다른 스위치에 연결(Topology 3·4, Enhanced Active/Backup) 합니다. Enhanced 방식에서는 멤버들이 링크 상태뿐 아니라 멤버 간 경로까지 감시해 어느 subordinate 인터페이스를 쓸지 합의 하고, 모든 subordinate가 다 죽어야 페일오버 합니다.

몇 가지 더 챙길 점이 있습니다. 모든 멤버의 클록을 (수동 또는 NTP로) 동기화 해야 VPN 등이 제대로 동작합니다. IPv6는 HA 클러스터만 지원(Load Sharing은 미지원, Sync 인터페이스에는 IPv6 불가)하며, "Cluster"·"Sync"·"Cluster+Sync" 타입 인터페이스에는 IPv4 주소를 반드시 설정해야 합니다.

동기화에는 제약도 있습니다 — 동기화 중복용으로 전용 물리 인터페이스를 둘 이상 쓰는 건 미지원(대신 Bonding 사용), 한 멤버가 죽으면 그 멤버를 지나던 user-authenticated 연결은 복구 불가(user space 프로세스가 인증 상태를 보관하기 때문), 페일오버 시 관리 서버로 아직 안 보낸 어카운팅 정보는 유실 됩니다.