Exchange 2010 의 발표가 내년으로 다가왔다. 솔직히 정확하게 발표 될지 되지 않을 지는 미지수지만, 언제나 MS 의 라이센스 정책상 기능의 완성도를 떠나서 일단 발표는 될 것 같다. 요즘들어 MS 제품의 발표가 잦은 것 같다. 그런데 중요한 점은 MS 제품은 발표되고 서비스 팩이 2정도 발표되어야 안정된다는 점이다. 이점은 exchange 도 예외가 아닌데, exchange 만의 특성은 신버젼의 적용도 신속하다는 점이다.
여담은 그만 두고, exchange 2007 의 신 기술이 발표되었다. 이름하여 CCR 이라는 놈인데… 드물게 RTM 에는 포함되지 않았다가, 서비스 팩이 발표되면서 포함된 특이한 놈이다.
그럼 기본적인 설정을 위한 개략적인 형태를 보자.
기본 요구 사항으로 MNS 가 요구된다. MNS 라 하면 Windows 2003 부터 존재하던 클러스터 방식이다. 클러스터를 일종의 소프트웨어 형태로 구성한 것이라, 신뢰성이나 기타 하드웨어적인 신뢰성을 따라잡기가 힘든지라, 널리 쓰이지는 못했다. 일반적으로 분리된 서버를 이용한 다중 구성시 외장 HDD의 가격이 그다지 큰 factor 로서 작용하지 않으므로 큰 효용성이 없었다. 3기 이상의 노드가 과반수 이상 정상적이 서비스를 해야 한다는 약간 이상한 기능의 제한이 있다. 물론 그건 그렇다 치고 더 자세한 내용은 technet 에서 mns 를 참고하시라…
일단 3대가 1조의 클러스터로 구성되면 한대가 지속적으로 옆 노드에 복제를 시작한다. 문제가 생기면 서비스를 정상적인 노드가 인수 받는 형식인 것이다. 그런데, 이전의 MSCS 기반의 exchange 가 존재하고 있음에도 MS 는 구태여 왜 이런 복잡한 구조의 고가용성 솔루션을 도입한 것일까?
이 글을 읽고 있는 사람은 익스체인지의 운영자 이거나 아니면, 프로젝트를 하는 개발자 일 수 있다. 그대 익스체인지 2003 에서 esutil 을 사용한 경험이 있는가? 해본 경험이 없다면 그대는 정말 행운아다. 하지만 계속 그런 행운이 따라올 것이라는 기대는 좀 접어두자. 특히 한번 발생하게 되면 해당 저장소의 모든 메일에 접근이 불가능해지는 대형 사고가 발생하게 되므로 정말 어마어마한 장애다. 그리고 esutil 은 머신이 좋다고 금방 끝나는 것이 아니라 논리적으로 손상된 data를 수정하여야 하므로 정말 오랜 기간 서비스를 복구할 수 없는 상황이 발생한다,
이전의 MSCS 가 고가용성을 지원함에도 불구하고 논리적 파일의 손상에 대해서는 지원하지 못했던 한개를 로그를 통한 복제로 해결한 것이다. HDD 에 로그가 write 되었다는 의미는 정확하게 data 가 write 되었다는 것을 의미하므로 논리적 손상이 발생한 경우 정상적인 파일을 확보하고 있음을 뜻하는 것이다. 그렇다면, 로그가 넘어오는 중에 원본에 장애가 발생하면? 그런건 걱정하지 말자, 알아서 안 쓴다…^^
처음 보는 사람이면, 이게 뭐야… 라고 이야기 할 수도 있지만, 익스체인지를 한번 운영해 본 사람이라면…특히 파일의 장애로 인하여 심하게 고생해 본 사람이라면 본 기능을 정말 환영할 것이라고 생각된다.
자 그럼 세세한 설정은 다음에 이야기 하기로 하자…