09VSX 클러스터 구성Configuring VSX Clusters

모드는 두 가지인데, R81.10 이상으로 새로 설치한 클러스터에서는 VSLS만 쓸 수 있고, High Availability는 R81 이하에서 R82로 업그레이드한 경우에만 가능합니다(VSLS를 HA로 변환할 수도 있습니다). VSLS(Virtual System Load Sharing)는 Active Virtual System들을 여러 멤버에 분산해 성능을 높이면서 투명한 페일오버를 제공하고, High Availability는 모든 멤버와 Virtual System이 Active/Standby로 동작하며 계속 동기화됩니다.

VSX 클러스터를 이해하려면 물리 클러스터를 먼저 떠올리는 게 좋습니다. 일반적인 클러스터는 둘 이상의 동일한 물리 게이트웨이를 묶어 하나의 게이트웨이처럼 동작하게 하고, Cluster IP(Virtual IP) 라는 자체 IP를 가집니다. 외부에서 내부로 가는 트래픽은 이 외부 Cluster IP로 도착하고, 모드에 따라 지정된 멤버가 받아 검사한 뒤 목적지로 보내거나 버립니다. 반대로 내부에서 외부로 가는 트래픽도 Cluster IP로 향합니다. 각 멤버의 인터페이스에는 고유한 물리 IP가 있지만 이 IP는 외부 네트워크에 보이지 않으며, 멤버끼리 그리고 관리 서버와 정책 다운로드·로그·상태 점검 같은 내부 통신에만 쓰입니다.

VSX 클러스터도 똑같이 동기화된 게이트웨이들을 묶어 하나가 죽으면 다른 하나가 즉시 자리를 대신합니다. 다만 VSX에서는 Virtual System·Router·Switch와 그 인터페이스가 모든 멤버에 동일하게 프로비저닝·설정된다는 점이 추가됩니다. 각 멤버에 있는 동일한 가상 장치 인스턴스를 서로 peer(피어) 라고 부릅니다. VSX는 가상 장치 인터페이스마다 가상 IP를 배정하고, 가상 장치의 상태 테이블을 다른 멤버의 피어로 동기화합니다.

물리 네트워크처럼 사전 계획이 성공의 열쇠이며, 특히 IP 주소 할당에 주의해야 합니다. VSX 클러스터에는 실제 IP와 가상 IP가 모두 필요하지만, VSX가 가상 장치 사이의 Warp Link IP는 자동으로 배정해 주므로 부담이 줄어듭니다. 클러스터 네트워크는 세 가지 요소로 이뤄집니다.

동기화 네트워크(Synchronization Network) 는 멤버 간 상태 동기화 데이터를 나르는 물리 네트워크입니다. 클러스터를 처음 정의할 때 설정하며, 멤버를 추가·제거할 때 바꿀 수 있습니다. 여기에는 기업 네트워크 어디에서도 쓰지 않는 고유한 IP 를 써야 합니다.

내부 통신 네트워크(Internal Communication Network) 는 ClusterXL 환경에서 동기화 네트워크에 더해 필요한 가상 네트워크로, 외부에는 보이지 않으며 멤버들이 환경의 상태를 인식하고 통신하게 해 줍니다. VSX가 클러스터 생성 때 IP를 자동 배정하는데, 기본값은 IPv4 192.168.196.0/255.255.252.0(클래스 C 4개 범위)이고 IPv6는 FD9A::1FFE:0:0:0/80입니다. 이 IP는 Virtual System을 만들기 전에만 바꿀 수 있고, 일단 Virtual System을 만들면 변경할 수 없습니다. 그래서 가상 장치를 만들기 전에 이 기본 범위가 외부 네트워크 어디에서도 쓰이지 않는지 반드시 확인해야 IP 충돌을 피할 수 있습니다.

가상 IP 주소(Virtual IP) 는 외부 네트워크에 보이는 유일한 IP 입니다. 직접 연결된 서브넷에 대응해야 하고 유효한 next hop 역할을 해야 합니다.

기본 설정은 대부분 SmartConsole에서 하지만, 클러스터 정의를 바꾸는 것 같은 많은 관리 작업은 CLI(vsx_util)가 필요합니다. 멤버에서 상태를 들여다보는 cphaprob state 같은 명령은 현재 VS 컨텍스트 기준으로 동작하므로, 진단할 때는 vsenv로 대상 VS에 들어간 상태인지 늘 확인하세요. 새 클러스터는 SmartConsole의 VSX Cluster Wizard로 만드는데, 관리 서버나 Main Domain Management Server에 접속해 New Cluster를 시작하면 마법사가 단계별로 안내합니다. General Properties에서 클러스터 이름(공백·특수문자 불가, 밑줄만 허용)과 IPv4·IPv6 Cluster IP를 정하고, 이후 멤버·인터페이스·토폴로지를 설정한 뒤 마법사를 마치면 대부분의 속성은 SmartConsole에서 바로 수정할 수 있습니다.

설정에서 알아둘 항목 몇 가지를 짚으면, ClusterXL 창에서는 상태 동기화를 켜고 끄거나 멤버 상태 변화의 추적 옵션을 고를 수 있고 나머지 ClusterXL 속성은 비활성화됩니다. Topology 페이지에서는 인터페이스와 라우트를 정의하는데, 라우트를 추가할 때 Propagate route to adjacent Virtual Devices 를 켜면 이웃 가상 장치에 그 경로를 알려 장치 간 연결을 활성화합니다. 토폴로지를 라우팅 정보로 자동 계산하는 옵션은 기본으로 켜져 있지만, 동적 라우팅을 쓸 때는 끄는 것이 권장되고 Bridge 모드에서는 쓸 수 없습니다.

NAT 페이지에서는 Virtual System에서 나오는 패킷에 Hide NAT이나 Static NAT을 설정할 수 있습니다. Hide NAT은 내부에서 시작된 연결만 허용하며 게이트웨이 뒤로 숨기거나 라우팅 가능한 가상 IP 뒤로 숨길 수 있고, Static NAT은 사설 주소를 대응하는 공인 주소로 1:1 변환합니다. Bridge 모드를 쓴다면 VSX Bridge Configuration에서 ClusterXL 루프 감지(Active/Standby)나 표준 L2 루프 감지(STP/PVST+)를 고릅니다(자세한 내용은 Bridge 모드 장 참고).

클러스터 관리 IP나 서브넷을 바꾸려면 관리 서버에서 vsx_util change_mgmt_ip·vsx_util change_mgmt_subnet을, 내부 통신 네트워크 IP를 바꾸려면 vsx_util change_private_net을 씁니다.

멤버를 추가·제거하기 전에는 반드시 다른 관리자가 관리 서버에 접속해 있지 않아야 합니다. DB가 잠겨 있으면 vsx_util이 관리 DB를 수정하지 못하기 때문입니다.

멤버를 추가할 때는 새 멤버를 설치한 뒤 모든 SmartConsole을 닫고 환경을 백업(sk100395)하고서, 관리 서버에서 vsx_util add_member를 실행합니다. 그다음 vsx_util reconfigure로 새 멤버를 구성하고 재부팅한 뒤 각 멤버에서 cphaprob state로 상태를 확인합니다. VSLS 모드라면 마지막에 vsx_util vsls로 Virtual System들을 새 멤버에 재분배해야 합니다.

멤버를 제거할 때는 SmartConsole을 닫고 백업한 다음, 먼저 그 멤버에서 라이선스를 분리해야 합니다(분리하지 않으면 제거할 수 없습니다). 그리고 관리 서버에서 vsx_util remove_member를 실행해 안내에 따라 클러스터와 멤버를 고르면 됩니다. 끝나면 SmartConsole에서 클러스터 객체의 Cluster Members에 그 멤버가 사라졌는지 확인합니다.

vsx_util add_member        # 새 멤버 추가
vsx_util reconfigure       # 새 멤버 구성 (이후 재부팅)
cphaprob state             # 각 멤버에서 상태 확인
vsx_util vsls              # VSLS 모드: VS 재분배
vsx_util remove_member     # 멤버 제거 (먼저 라이선스 분리)

VSLS와 HA 사이의 변환에는 관리 서버의 vsx_util convert_cluster를 씁니다(vsx_util의 모든 하위 명령은 명령어 레퍼런스 장에 정리돼 있습니다). 앞서 말했듯 R81.10 이상 신규 설치는 VSLS만 가능하고 HA는 업그레이드한 경우에만 쓸 수 있는데, VSLS를 HA로 변환하는 것은 가능합니다.

VSLS를 HA로 바꾸는 흐름은 이렇습니다. 먼저 vsx_util vsls의 "Set all VSs active on one member" 옵션으로 모든 Active Virtual System을 한 멤버에 몰아넣습니다. 그다음 각 멤버에서 cpconfig로 Per Virtual System State와 Bridge용 ClusterXL Active/Standby를 끄고 cpstop ; cpstart로 서비스를 재시작합니다(이때 페일오버가 일어날 수 있습니다). 마지막으로 관리 서버에서 vsx_util convert_cluster로 클러스터를 High Availability로 변환합니다.

vsx_util vsls              # 모든 VS를 한 멤버에 Active로 모음
cpconfig                   # 각 멤버: Per Virtual System State 비활성화
cpstop ; cpstart           # 서비스 재시작 (페일오버 유발 가능)
vsx_util convert_cluster   # VSLS → HA 변환 (메뉴에서 HA 입력)

반대로 HA를 VSLS로 바꿀 때 는 순서가 거의 뒤집힙니다. 각 멤버에서 cpconfig로 Per Virtual System State와 ClusterXL Bridge Active/Standby를 켜고 cpstop ; cpstart로 재시작한 뒤, 관리 서버에서 vsx_util convert_cluster를 실행해 메뉴에서 LS를 입력하고 변환을 확인합니다. 이때 VS를 멤버에 균등 분배할지, 한 멤버에 모두 Active로 둘지 를 고른 뒤 각 멤버를 재부팅합니다. 다만 Active/Active Bridge 모드의 VS나 Virtual Router가 있으면 VSLS로 변환할 수 없습니다.

여기서부터는 VSLS의 동작 원리를 좀 더 깊이 들여다봅니다(이 내용은 Scalable Platform에는 적용되지 않으며, Maestro·Chassis에서는 gClish set cluster configuration high-availability mode 3을 씁니다).

특히 VS가 멤버들 사이에 자동으로 분배되어 별도 설정이 거의 필요 없고, 표준 스위치만으로 부하 분산이 되며, 멤버를 추가할 때마다 전체 용량과 이중화가 함께 늘어납니다. 한 가지 제약은, Per Virtual System State가 켜진 상태에서는 Virtual Router와, 물리·VLAN 인터페이스가 없는 Virtual Switch는 지원되지 않는다는 것입니다. 또한 VSLS가 상태를 감지·배정하려면 모든 멤버의 모든 VS가 스위치나 VLAN으로 서로 직접 연결돼 있어야 합니다.

우선순위, 가중치, 그리고 세 가지 상태

우선순위(Priority) 는 어느 멤버가 그 VS의 Active·Standby·Backup을 맡을지에 대한 선호 를 정수로 나타냅니다. 0이 가장 높아 Active를 맡을 멤버, 1이 Standby를 맡을 멤버, 2 이상은 Backup을 맡되 우선순위 2가 장애 시 가장 먼저 Standby로 전환되고 3이 그다음 차례입니다. 가중치(Weight) 는 VS마다 트래픽·부하가 다르다는 점을 반영하는 값으로, 무거운 가중치를 준 VS는 특정 멤버에서 더 많은 자원을 차지하고 나머지 VS는 다른 멤버로 분산됩니다. 기본 가중치는 모두 10이며, 우선순위와 가중치 모두 관리 서버의 vsx_util vsls로 바꿉니다.

VSLS는 기존의 Active·Standby에 Backup 상태를 더합니다. 핵심은 Backup은 각 VS의 최신 설정은 갖지만 상태 테이블 동기화는 받지 않는다 는 점입니다. 즉 Active와 Standby만 상태 테이블을 동기화하고, Backup은 정책 업데이트만 받습니다. 이렇게 해서 동기화 네트워크의 부하를 줄입니다.

부하 분산과 장애 시나리오

정상 상태에서는, 멤버 3대에 VS 3개가 있다면 각 멤버가 서로 다른 VS의 Active를 하나씩 맡아 부하가 고르게 퍼집니다. VS를 만들면 VSX가 자동으로 Standby와 Backup 상태를 만들어 다른 멤버들에 분배합니다.

멤버 하나가 죽으면, VSLS가 이를 감지해 그 멤버가 맡던 VS들의 트래픽을 각자의 Standby로 보냅니다. 완전히 동기화돼 있던 Standby가 즉시 Active로 바뀌어 기존 연결을 끊김 없이 유지하고, 동시에 Backup이 Standby로 올라와 새 Active와 완전히 동기화됩니다.

개별 VS 하나만 죽는 경우 도 마찬가지로, 그 VS는 자기 Standby로 페일오버하고 Backup이 새 Standby가 되어 동기화하며, 나머지 VS들은 영향 없이 계속 동작합니다.

죽었던 멤버나 VS가 다시 살아나면 시스템은 원래의 부하 분산 구성으로 되돌아갑니다.

VSLS 모드로 설정하기

먼저 클러스터 멤버를 설치한 뒤, 각 멤버에서 cpconfig로 Per Virtual System State 를 켜야 합니다. 이 설정이 Active VS를 여러 멤버에 두고 VS별 페일오버를 가능하게 하는, VSLS의 필수 조건입니다(켠 뒤 재부팅). 그다음 SmartConsole에서 새 VSX 클러스터를 만들 때 General Properties의 VSX Cluster Platform에서 ClusterXL Virtual System Load Sharing 을 선택하고 마법사를 완료합니다. 이어서 필요한 Virtual System(과 Virtual Router)을 만든 뒤, 관리 서버에서 vsx_util vsls로 분배를 조정합니다.

cpconfig                  # 각 멤버: Enable Per Virtual System State → 재부팅
# SmartConsole: New Cluster → VSX Cluster Platform = ClusterXL Virtual System Load Sharing
vsx_util vsls             # 관리 서버에서 분배·우선순위·가중치 조정

vsx_util vsls는 VSLS 설정의 만능 도구입니다. 현재 VSLS 구성 보기, VS를 멤버에 균등 분배, 모든 VS를 한 멤버에 Active로 모으기, 개별 VS의 우선순위·가중치 수동 지정, Active Up/Primary Up 모드 전환, 그리고 VSLS 설정을 CSV로 import/export 하는 작업을 모두 이 명령으로 합니다. CSV로 내보내고 들여오는 기능 덕분에 복잡한 분배 설정을 백업하거나 다른 클러스터에 옮길 수 있습니다.

VSLS에서의 Virtual Router

VSLS 모드에서도 Virtual Router를 다루는 별도의 고려사항이 있어, 같은 부하를 받는 VS들이 하나의 Virtual Router 그룹으로 묶여 함께 분배됩니다. 그룹의 가중치는 그에 속한 VS들에 영향을 주며, 그룹 단위로 멤버 간 분배가 이뤄집니다.

High Availability 모드에서는 Virtual Switch도 클러스터의 일원으로 동작해, Active 멤버의 Virtual Switch가 트래픽을 처리하고 페일오버 시 Standby 멤버의 Virtual Switch가 이어받습니다.

고급 설정으로는 두 가지가 있습니다. 하나는 모든 VLAN 감시(Monitoring all VLANs) 로, 기본적으로 최고·최저 VLAN ID만 감시하는 동작을 모든 VLAN으로 확장해 더 촘촘하게 연결 장애를 잡아내는 것입니다. 다른 하나는 VSLS 클러스터에서의 CoreXL 설정 으로, 부하 분산 환경에서 코어 자원을 VS들에 맞게 조정하는 것입니다.