‘고 가용성·페일오버’ 지원 … 뛰어난 관리 능력 ‘인포블록스’ 최고
오늘날 기업들은 활동 추적에서부터 규정준수 감사 및 VoIP(Voice over IP)에 이르는 비즈니스 프로세서용으로 DNS와 DHCP를 이용하고 있다. 하지만 분산된 조직에서는 종종 원격 사이트들간에 DNS와 DHCP 서버를 배치해야 하는데, 이는 관리나 운영면에서 모두 악몽 같은 일이다.
DNS/DHCP 어플라이언스는 변화 복제 및 부적절한 보고 및 관리 같은 문제를 해결함으로써 원격 및 지사 사무소에 기간 서비스를 배치하는 일을 단순화할 수 있게 설계됐다. 이들은 또한 무결정성 페일오버(sealmess failover)를 허용함으로써 DHCP 가동시간을 향상시킨다.
이러한 주장을 검증해 보기 위해 우리는 VoIP와 NAC(Net
work Access Control)를 모두 염두에 두고 있는 다소재지 회사를 만들었다. 그리고 업체들에게 최대 가동시간을 위해 HA(high-availability)와 페일오버 기능을 제공하도록 구성된 DNS/DHCP 어플라이언스를 보내줄 것을 요청했다.
인포블록스(Infoblox)와 INS(International Network Services)는 각각 다섯 가지 어플라이언스를 우리 시러큐스 대학 리얼월드 랩으로 보내 왔다. 이들 가운데 네 개는 독립된 네트워크에서 HA 쌍으로, 하나는 관리 서버로 사용했다. 메타인포(MetaInfo)는 네 개의 어플라이언스를 보냈으며, 우리는 그 관리 UI를 윈도 2003 서버에 설치했다.
블루캣 네트웍스(BlueCat Networks)는 요청에 응하지 않았다. 멘 앤 마이스(Men&Mice)의 동명의 제품은 기존의 DNS와 DHCP 제품을 관리하는 것으로 이번 테스트에 적합하지 않았다.
문제 해결사들
전체적인 테스트 결과는 만족할만했다. 시스템 셋업이 약간 일관성이 없었으며, 로깅과 IP주소 라우팅도 마찬가지였다. 그리고 이런 제품을 모든 사람들이 필요로 하지는 않을 것이다. 즉 주로 주소를 종단 지점으로 내보내고 있고, 활동에 대해 보고할 필요가 거의 없을 경우에는 마이크로소프트와 ISC(Internet Software Consortium) DNS 및 DHCP 서버면 충분하다.
하지만 보다 복잡한 기업에서는 이런 어플라이언스가 해결할 수 있는 문제에 부딪친다. 예를 들어 로컬 DNS/DHCP 서버를 보증하는 지사 수가 늘어나면, DNS와 DHCP 인프라 관리 문제가 급격히 커진다. 다중 DNS 및 DHCP 서버로 변화를 복제하는 일은 기분 나쁘게 복잡할 수 있으며, 부적절한 주소 공간 관리 및 보고로 인한 여파가 당신에게 다시 돌아갈 수도 있다. 이번에 분석한 모든 장비들은 강력하고 단순화된 DNS/DHCP 관리와 구성을 제공하고 있었다.
나아가 VoIP나 NAC를 고려하는 곳에서는 DNS와 DHCP 프로토콜의 기본 사양인 고 가용성 외에도 다단계 관리, IP 주소 관리 및 보고, 엔터프라이즈 구성 능력, 그리고 중복성과 같은 멋진 기능을 제공하는 고급 DNS 및 DHCP 시스템의 혜택을 누릴 수 있을 것이다.
결론적으로 말하자면 직접 DNS 영역 파일을 편집하는 게 어렵지 않은 일임을 알고, named.conf 파일을 침대에서 보는 것으로 여기면서, ‘플리즈 릴리즈 미’ 노래를 흥얼거리며 dhcpd.conf 파일을 구성한다 하더라도, 이제 프로그램을 이용하기 시작할 때라는 얘기다. 단순화된 DNS와 DHCP는 마이크로소프트 제품에서 오랫동안 사용 가능했으며, 오늘날에는 많은 오픈 소스 프로젝트들까지도 ISC BIND(Berkely Internet Name Daemon)와 DHCP 구성을 단순화 해주고 있다. 적어도 이름이 마침표로 끝나는 때나 그렇지 않은 때를 기억해야 하는 시대는 이제 분명 지나간 것 같다.
액티브 디렉토리 통합
초기 DNS/DHCP 설치에서는 그리 흥미로울 게 없다. 첫 경험을 쌓고 나면 그 다음 배치는 보다 수월하게 진행될 것이다. 하지만 원활한 배치를 보장하기 위해서는 IP 어드레싱 방안을 그리고, DHCP 리스 풀(lease pool)을 정의하고, DNS 영역을 정의함으로써 대비를 해야 할 필요가 있다.
우리 네트워크에 맞게 어플라이언스를 구성한 다음 우리는 액티브 디렉토리를 통합시켰다. 액티브 디렉토리 마이그레이션은 처음 DNS 서버를 구성한 다음 여기서 액티브 디렉토리를 포인팅하기만 하면 됐기 때문에 모든 제품에서 매우 간단했다. 메타인포의 ESA(Enterprise Server Appliance)에서는 영역 정의 단계(zone definition phase)에서 액티브 디렉토리 영역을 구성하자 관리 스테이션이 필요한 모든 하부영역(subzone)을 만들어 주었다.
인포블록스 DNSone에서는 액티브 디렉토리에서 DNS 서버로부터 데이터를 엑스포팅하고; 엑스포팅된 데이터를 전환 마법사를 통해 실행했는데, 이 마법사는 영역 정보를 BIND 9으로 포매팅했으며; 영역을 DNS 서버로 임포팅했다. INS IP컨트롤 사파이어(IPControl Sapphire)에서는 액티브 디렉토리 시스템들이 DNS 서버에 등록이 되도록 이들을 재부팅하기만 하면 됐다. 멋진 일이다.
우리로서는 DNS 어플라이언스가 DNS에 대한 권위를 갖기를 원했지만, 어플라이언스가 액티브 디렉토리로부터 업데이트를 수신하는 슬레이브(slave) 영역이 되도록 하거나, 액티브 디렉토리가 어플라이언스의 슬레이브가 되게 하는 다른 구성을 사용하는 것도 가능했다. 일단 설치 및 가동 준비가 끝나면, 서로 다른 아키텍처로 바꾸는 일은 비교적 간단하다. 체계적이 이동 계획만 잘 세우면 된다.
시스템 셋업은 인포블록스 DNSone과 메타인포 ESA가 빛을 발휘하는 부문이었으며, 반면 INS의 사파이어 장비는 얼마간 뒤쳐지는 모습을 보였다. 예를 들어 인포박스에서 우리는 어플라이언스를 추가하고, DNS 영역과 각 박스를 돌리는 서비스를 정의하고, DHCP 주소 풀을 추가했으며, 그러자 DDNS(Dynamic DNS) 업데이트와 TSIG(transaction signature) 키 등의 구성이 배포됐다. 간단한 일이었다.
메타인포 ESA도 못지 않게 간단해서 일단 DNS 서버에 DHCP 서버를 포인팅하자 모든 것이 대부분 돌아갔다. 여기서 ‘대부분’이라고 말한 이유는 테스트를 하는 동안 어떤 지점에서 액세스 제어 구성이 ‘사라졌기’ 때문이었다. 신중하게 매뉴얼을 따라한 다음 기술 지원 팀과 몇 시간 장애관리를 해 보았지만, 왜 그런 문제가 발생했는지는 알 수가 없었다. 마침내 제대로 돌려 놓긴 했으나 메타인포 ESA가 구성을 푸싱 아웃하는 방식에 대해 대단한 확신을 갖고 있다는 말은 차마 할 수가 없다. 한 번 설정했다면 확인은 두 번 해보기를 권한다. INS의 IP컨트롤에는 많은 멋진 기능들이 있지만 불행히도 DNS와 DHCP 구성은 여기에 속하지 못하고 있다. IP 주소 관리 시스템용으로는 너무 많은 버튼을 눌러야 하고, 너무 많은 정보를 기억해야만 했다. INS의 실질적인 강점은 DNS/DHCP 관리가 아니라 IPAM(IP Address Management)
에 있다. INS의 주장대로라면 IP컨트롤은 제출한 사파이어 어플라이언스뿐만 아니라 ISC와 마이크로소프트의 DNS와 DHCP 서버를 관리할 수 있겠지만, 자기 회사 제품들과 보다 잘 통합이 됐더라면 좋았을 것이다. DDNS와 DHCP 통합을 셋업하기 위해서는 예를 들어 수동으로 DNS ACL과 키를 설정해야 했는데, 이것은 시스템에서 자체적으로 할 수 있어야 하는 작업이다.
우리는 또한 INS 사파이어 어플라이언스에 실수로 윈도 DHCP 구성 파일을 적용시킨 곳에서 구성 문제에 부딪쳤다. 그 결과로 생긴 구성 파일은 로딩에 실패했으며, 시스템 로그에서는 어떤 정보도 말해주지 않았다. 우리는 어플라이언스 콘솔에 올라 타서 시스로그 파일을 검토해 에러를 찾아내야 했다. 다행히도 사파이어 어플라이언스는 오류를 잡아 내고 원래의 구성 파일을 다시 적용시킴으로써 우리 DHCP가 계속 돌아갈 수 있었지만, 역시 장애관리를 위해 우리끼리, 그리고 기술 지원팀과 함께 몇 시간을 보내야 했다. 관리 소프트웨어라면 오구성 문제를 잡아 내고 픽스에 대해 유용한 지침을 제공해 주었어야 했다.
가동시간 극대화
기간 서비스들은 완벽에 가까운 가동시간을 낼 수 있어야 한다. DNS에는 잘 정의된 페일오버 셋업이 있으며, DHCP에는 그런 것이 없다. DHCP 페일오버를 표준화한 표준안이 IETF DHC(Dynamic Host Configuration) 워크 그룹에 의해 IESG(Internet Engineering Steering Group)에 제출된 바 있다(지금은 만기가 된 상태). 이렇게 지연되고 있는 원인은 무엇일까?
DHCP 워크 그룹의 공동 회장인 랄프 드롬스(Ralph Droms)는 “IESG로 제출된 표준안은 아직도 검토 중”이라며, “이 사양은 복잡하며, 신중한 검토를 거쳐야만 표준화가 가능하다”고 말했다. 그 때까지는 범위 분할(scope splitting)이나 윈도 서버의 서버 클러스터링 기술을 사용함으로써 윈도 2000에서 DHCP 페일 오버를 확보할 수 있다.
메타인포는 ISC DHCP 3.X 서버에서 DHCP 페일오버 메커니즘을 사용하는데, 이 메커니즘은 IETF 표준안을 기반으로 한다. ISC DHCPD(DHCP Distribution) 페일오버는 DHCP 풀을 절반으로 분할함으로써 작동하며, 각각의 DHCP 서버는 결정 알고리즘(degerministic algorithm)을 기반으로 그 자체 풀에서 주소를 할당한다. DHCPD 피어는 리스들을 동기화함으로써 하나의 서버가 다운이 되면 다른 것이 계속해서 어떠한 충돌도 없이 리스를 지원 및 갱신할 수 있다. DHCP 서버는 또한 리스를 전달하기 전에 IP 주소를 핑하도록 구성될 수도 있다는 사실을 명심해야 한다. 이것은 좋은 생각이긴 하지만 우리는 리스 할당이 지연되지 않도록 적당한 타임아웃(1초 등)을 설정하기를 권하는 바다.
인포블록스와 INS는 둘 다 강력한 HA 프로세스를 지원하는데, 여기서는 주 및 보조 어플라이언스가 능동/수동 모드로 구성이 된다. 인포블록스의 경우 어플라이언스는 VRRP (Virtual Router Redundancy Protocol)를 사용하며, 가상 MAC(Media Access Control)과 IP 주소를 공유한다. INS는 VRRP와 유사한 기능을 하는 전용 페일오버 프로토콜을 사용한다.
두 가지 경우 모두 제품들은 DNS와 DHCP를 동기화하며, 따라서 페일오버시 보조 어플라이언스는 주소 풀에 대한 완벽한 그림을 갖게 된다. 능동/수동 페일오버를 사용함으로써 얻을 수 있는 이점으로는 보다 신속한 페일오버와 DHCP 풀을 분할할 필요가 없다는 점을 들 수 있다. 물론 필요할 때까지는 사용하지 않은 채 놓여 있을 어플라이언스에 돈을 지불하는 것이긴 하지만, 호스트가 네트워크 액세스를 할 수가 없음 으로써 발생하는 다운타임 비용과 비교하면 그 비용은 내세울 게 못된다.
일상의 고역들 관리
반갑게도 테스트한 모든 제품에는 일상의 관리 기능들이 총망라돼 있었다. 모두가 객체나 계층적 모델에 적용될 수 있는 템플릿을 지원하며, 부모로부터 물려받은 자식 객체에 대한 구성 옵션도 지원하고 있다. 두 가지 방안은 구성 작업을 대폭 단순화해 주는데, 단 이것은 제대로 된 글로벌 옵션 세트가 정의돼 있을 경우에 한해서다.
예를 들어 인포블록스 ID 그리드 매니저(Grid Manager)는 계층적 모델을 사용하며, 부모 객체에서 글로벌 구성이 설정되고 자식 객체에서 맞춤화될 수 있다. 우리는 글로벌 레벨에서 모든 DHCP 리스에 대해 우리가 원하는 리스 타임과 일반 옵션들을 구성했다. 그런 다음 네트워크에 연결된 DHCP 서버 자식 객체와 주소 풀에서 네트워크 전용 파라미터들을 맞춤화했다. 이상하게도 ID 그리드 매니저는 상속받은 설정을 보여주지 않았는데, 이로 인해 무엇이 어떤 객체에서 설정됐는지를 보려면 많은 검색 작업을 해야만 했다. 인포블록스는 이 부분을 수정해야 할 것이다. 상속받은 설정의 콘텐츠를 찾기 위해 객체 트리를 조사해야 한다는 것은 시간 낭비에 다름 아니다.
INS와 메타인포는 모두 구성을 설정하기 위해 템플릿을 사용하는데, 이것은 분명 충분히 쉽게 파악할 수 있는 유연한 솔루션이다. 우리는 윈도 DHCP와 ISC DHCP용으로 사전 정의된 정책을 이용하고, VoIP 전화기 지원을 전문으로 하는 몇 가지 정책을 만들었다. 주소 풀을 정의할 때는 옵션과 정책 세트도 또한 정의를 했다. 예를 들어 우리는 특정 풀에서 할당받은 주소가 될 특정 사용자 등급을 추가할 수 있었다. 템플릿을 바꾸면 일단 구성이 푸싱 아웃되고 난 후 이 템플릿을 사용하는 모든 서버가 바뀐다.
유일한 함정은 템플릿의 수가 늘어날 것이기 때문에 정보가 되는 이름을 사용해야 한다는 것이다. 또한 변화가 적용되기 이전에 시스템을 먼저 재시동해야 하는 서버 구성이 많다. 이것은 실제로는 모든 사람이 ISC BIND와 DHCP를 사용하고 있기 때문이다.
재시동을 하는 동안에는 서비스가 중단된다는 사실을 명심해야 한다. 인포블록스에서는 중단 시간이 1초를 넘기지 않았다. INS와 메타인포에서는 지연이 약간, 잘 해야 몇 초 더 길었다. DHS/DHCP 서버 부하에 따라, 그리고 특히 리스 시간이 짧아서 빈번한 갱신을 유발하는 경우, 네트워크 호스트의 중단을 최소화하도록 변화 창을 스케줄링하는 게 좋다.
경보와 로그
우리는 또한 보고 및 경보 기능을 평가했다. INS와 인포블록스는 리스 경보를 지원하며, INS는 비록 아웃 오브 더 박스로는 그 자체 로그에만 경보 기능을 지원하긴 하지만 SNMP 트랩을 비롯한 기타 전송 방식이 스크립트에 의해 지원되었다. 반면에 인포블록스는 SNMP 트랩과 e-메일을 아웃 오브 더 박스로 전송한다.
전반적으로 우리는 로깅에서는 얻을 게 거의 없다는 사실을 알 수 있었다. 기본적으로는 시스로그 엔트리들밖에 없었다. 놀랍게도 IP 주소 할당 보고도 또한 일관적이지 못했다. IP 주소, 상태, MAC 주소 및 타임 스탬프 등을 반영해 주는 DHCP 풀 이용량 통계를 수집할 수 있긴 했지만, INS 사파이어 어플라이언스에서는 이 보고서가 신뢰성이 없었다. 우리는 DHCP 리스용으로 모든 어플라이언스를 폴링하는 작업을 만든 다음, 롤업용으로 두 번째 작업을 스케줄링해야만 유용한 보고서를 얻을 수 있었다. 인포블록스와 메타인포는 모두 실시간 및 실시간에 가까운 데이터에서 미흡함이 없었다.
가격 면에서는 HA 구성으로 2,032 IP 수조를 지원하도록 두 개의 어플라이언스를 구성하는 데 드는 정가를 기준으로 점수를 매겼다. 인포블록스가 테스트 구성 가격이 1만2천900달러로 가장 낮았으며, 메타인포와 INS는 각각 1만9천990와 1만9천985달러로 비슷했다. 인포블록스는 인포블록스-550의 빛나는 HA와 관리 능력 덕분에 에디터즈 초이스로 선정되었다. INS의 사파이어 장비들은 HA에서는 높은 점수를 얻었지만 관리에서, 특히 DHCP 면에서 뒤쳐졌다. 이들은 IPAM용으로 더 적합하다. 메타인포는 HA 테스팅에서 점수를 잃었다.
기존 서비스에 관리 기능 추가하기
DNS 어플라이언스에 투자한다는 생각은 아직 해보지 않았을지 모르지만, 관리하고 있는 DNS 및 DHCP 서버가 많을 경우에는 보다 나은 관리 시스템으로 혜택을 볼 수 있다. 이미 나와 있는 수많은 오픈 소스 프로젝트들외에도 두 가지 상용 애플리케이션, 즉 INS IP컨트롤과 멘 앤 마이스의 동명 제품은 집중식 DNS 및 DHCP 관리를 DNS 영역와 DHCP 풀로 가져다 주며, 여기에는 역할 기반의 액세스 제어 및 위임 기능이 완비돼 있다.
우리가 테스트한 어플라이언스에 있는 페일오버 메커니즘에 맞출 수 있는 소프트웨어 제품은 없긴 하지만, 집중식 DHCP가 가져다 주는 이점은 많다. 예를 들어 옵션에 글로벌 변화를 만들 수 있는 능력은 복제 시간을 줄여 주고 변화가 정확히 일어나도록 보장해 준다. 물론 일부 옵션들은 로컬라이징이 돼야 하기도 한다. 즉 옵션과 범위를 관리하는 능력이 한정된 온 사이트 관리자는 맞춤화의 의무를 공유하며, 중앙 IT 부서에서 서버 제어를 관리한다.
IP컨트롤과 멘 앤 마이스 제품이 제공하는 IPAM(IP Address Management)은 엔터프라이즈에서 자신들의 IP 주소 공간을 제어할 수 있게 해준다. DHCP 스코프는 유한한 자원이며, 최고 수위를 추적하고 이에 대해 경보를 할 수 있는 방법이 없으면 DHCP 풀이 고갈되어 합법적인 호스트로의 액세스가 불가능해질 수 있다. 글로벌 뷰를 통해 IT 스태프는 주소 공간을 보다 효율적으로 사용하고 문제에 미리 대응할 수 있을 것이다.
기본적인 NAC 지원
이번에 테스트한 모든 어플라이언스는 패키지의 일부로 기본적인 NAC(network access control) 기능을 제공하지만, 그렇다고 해서 DNS/DHCP 어플라이언스가 효과적인 액세스 제어 솔루션이라고 착각해서는 안 된다.
네트워크 액세스 시행은 보통 MAC 주소 인증으로 시작이 되는데, 이것은 MAC 주소가 권한을 부여 받았는지 여부를 확인하는 데 있어 오해를 불러 일으킬 수 있는 용어다. 즉 MAC 어드레스가 특정 호스트와 연관이 돼 있는 것을 전제로 하는데 반드시 그렇지만은 않기 때문이다. 사용자가 임의로 네트워크로 내보내지는 MAC 주소를 바꿀 수 있게 해주는 유틸리티도 존재한다. 따라서 MAC 인증은 MAC이 알려져 있다는 것만을 나타내며, 이것이 특정 컴퓨터에 속해 있다는 것은 보장하지 않는다. DNS/DHCP NAC 기능에 있어 MAC 주소를 포탈을 캡처하기 위해 어떤 호스트가 사용돼야 하며, 다른 방식을 이용해서 인증이 강행돼야 하는지를 결정할 때 하나의 결정 포인트로 사용할 수 있기 때문에, MAC 주소 인증을 이해하는 것은 매우 중요하다.
캡처 포털은 제한된 네트워크에서 호스트에 IP 주소를 주고, 모든 DNS 요청을 캡처 포털로 주소 분해(resolving)를 함으로써 작동한다. 사용자가 웹 사이트로 접속하기 시작하면 이들은 캡처 포털로 보내져서 인증을 강요 받는다. 캡처 포털은 호텔이나 무선 핫스팟 인터넷 액세스를 사용해 본 사람이면 누구에게나 친숙할 것이다. 일단 사용자가 인증이 되면 그의 주소가 DHCP에 업데이트돼 적절한 IP 네트워크에 배치된다. 대안 제어 방식에서는 802.1x를 이용해 포트나 VLAN 스티어링(steering)을 사용할 수도 있다. MAC 주소 인증과 DHCP 리스 관리는 해악성이 없는 사용자 제어용으로는 좋지만 의도적인 공격자들에게는 유효하지 못할 것이다. MAC 주소나 IP 주소를 바꾸기란 너무나 쉬운 일이다. 특정 MAC 어드레스에 어떤 리스가 할당됐는지, 그리고 이런 MAC 주소가 어떤 포트에 연결됐는지를 추적하고, 호스트로 하여금 포트간 이동을 할 때 리스를 갱신하도록 요구하는 인프라(라우터와 스위치)가 없다면 액세스를 제어할 수 있는 길이 없다.
IP 주소, 호스트 이름 및 MAC 주소와 같이 신뢰성 있는 IP 주소 정보는 NAC 시스템에 의해 액세스 제어 결정의 일부로 사용된다. 이런 제품에서 발견되는 NAC 기능의 보다 흥미로운 용례는 NAC 시스템에서 확보할 필요가 있는 세그먼테이션(segmentation)을 파일로팅 및 정의하는 동안, 그리고 보다 강력한 솔루션을 배치하기 앞서 필요한 정책을 정의하는 동안 확인할 수 있다.
