Exchange 2010 HA 101

올 가을 쯤이면 Exchange 2010이 출시 됩니다. Exchange 2003을 사용하시던 분들 중에 상당히 많이 바뀐 Exchange 2007에 불안감을 떨치시지 못하시고 마이그레이션을 계획을 접으셨다는 Feedback을 들은 적이 있습니다. 사실, 개인적으로도 Exchange 2000을 2000년 초반에 접했을 때의 기억이 아주 좋지 많은 않습니다. 물론 Exchange 5.5 보다는 훨씬 세련된 UI 와 인터페이스를 보여주긴 했지만, 사실 처음에는 불안정한 면이 있었던 건 사실입니다. 그리고 Exchange 2003이 나왔을 때는, 많이 안정화 된 버전이었고 좋은 Feedback 많았었습니다. 개인적으로는 Exchange 2007 -->Exchange2010은 기본 Exchange 2000에서 Exchange 2003 정도의 변화라고 생각합니다. 물론 일부 스키마 변경과 디자인 변경이 있긴 하지만, 기본 코드 베이스는 유사하기 때문에, 안정성은 크게 염려 하지 않으셔도 될겁니다.

자, 오늘은 그 달라진 기능 중에 High Availability 에 대해서 간단히 다루도록 하겠습니다.

우선, Exchange 2003 시절에는 윈도우 클러스터에 전통적인 방식으로 Cluster aware 하게 익스체인지를 인스톨 해서 Active-Passive 형태로 사용을 했습니다. 대부분의 대형 고객사에서는 Shared 영역으로 SAN 장비를 주로 사용했습니다. 이것이 Exchange 2007에서는 SCC(single Copy Cluster)형태로 변경 되었으며, 전통적인 클러스터 방식을 고집하는 사이트에서는 이 구성으로 HA를 구현했습니다. 하지만, MS에서 추천하는 방식은 CCR이었으면, CCR의 경우는 기존처럼 Shared 공간영역으로 SAN이 필요하지 않고, DAS등을 시스템에 붙여서 Serve TO Server로 DB를 Copy 하는 방식입니다.

SCC의 경우는 Storage가 Failure 이 되면, HA의 의미가 사라지게 되죠. 즉 SCC는 Storage Failure를 Cover 하지 못하는 단점이 있습니다. Store Fail 시 진정한 Cluster failover는 기대할 수 없게 됩니다. 정리하면, SCC는 서버 layer의 failure 만을 cover할 뿐입니다.

이번에는 Continuous Replication 방식인, LCR,CCR,SCR 입니다. 로컬에서 Log shipping이 일어나거나, 클러스터로 묶인 두 노드간에 Log shiping, 또는 Standby 개념으로 Log shipping이 일어나는 경우입니다. Log Shipping은 Copy logàInspect LogàReply log 형태로 DB layer에서 일어나게 됩니다. 글로벌하게 많이 사용하는 Exchange 2007 HA 솔류션은 CCR+SCR 결합형태입니다. CCR의 경우는 한 노드에 DB1/DB2/DB3가 있다면, 다른 노드에 동일하게 같은 셋이 존재하게 됩니다. 그리고 다른 사이트에 Standby로 복제본을 SCR 형태로 구성할 수 있습니다. 이 CCR의 경우에는 Mailbox Server가 다른 Role과 공존할 수 없다는 점과 여전히 Clustering 관련 지식을 쌓아야 한다는 부담감, 그리고 여전히 Database에 문제가 생기면, Server based의 Failover 가 이뤄져야 한다는 단점이 있습니다. 더구나, SCR의 경우는 UI 상에 핸들이 안 되며, 수동으로 activation을 시켜야 하는 번거로움이 있습니다.

위에서 언급된 문제점을 보완하기 위해서 새로운 형태의 HA 솔류션이 필요로 하게 되었고, 이를 Exchange 2010에서 채택하게 되었습니다. 우선 복잡성이 없어야 하고, 비용도 절감하며, 복구 시간도 단축해야 하며, 큰 메일박스도 지원해야 하는 전제 조건을 만족하는 솔류션을요.

“Make High Availability Exchange deployments mainstream!!! “

다음은 향상된 내용입니다.

ü Improved mailbox uptime(향상된failover/CCR+SCR의통합/간단한 관리…)

ü More storage flexibility(IO가 개선/larger mailbox지원)

ü Better end-to-end availability(Better SLA)

아래 그림을 보고 얘기를 하도록 하죠.

위에서와 같이 Mailbox Server1~5 까지는 한 사이트에 구성이 되고, Mailbox6은 다른 사이트에 있다고 가정합니다.

서버 하단에 있는 DB명을 유심히 보시면, 각 서버별로 여러 곳에 존재하는 것을 알 수 있습니다. 즉 DB1이 Mailbox Server1에서 서비스를 받다가 문제가 생기면, Mailbox Server2에 존재 했던 DB1이 이어서 서비스를 받게 됩니다. 또 이 DB가 문제가 생기면 Mailbox Server4에서 서비스를 받게 됩니다. 결국 “Database centric failover”, 즉, Database중심의 Failover방식인 셈입니다. 간단히 working mechanism을 설명 드리면, client 가 메일을 보내면, 이것은 무조건 CAS서버로 가며, 이것이 최초 Mailbox Server1의 DB1으로 갑니다. 그리고 이 내용이 다른 서버 Mailbox2와 Mailbox Server4로 복제를 하면서(CCR개념), HA를 구현하는 것입니다. Mailbox Server1에 있는 DB1이 문제가 생기는 경우, Exchange서버 내에서 관리되는 Failover를 통해 적절한 서버로 라우팅을 하게 됩니다. 이로 인해 클라이언트가 다시 접근하는 경우 CAS가 알아서 Mailbox Server2로 라우팅을 해 줍니다. 우측의 외부 사이트까지 이 개념을 확대함으로써 SCR 까지 Cover를 하게 됩니다.

이러한 개념을 구현하기 위해 당연히 스키마 변경이 아래와 같이 이뤄졌습니다.

이를 ADSIEDIT에서 살펴보면 아래와 같다. Servers와 DAG와 Database가 Exchange Administrative Group하단에 동일한 layer에 존재하게 됩니다.

Exchange 2010의 HA 에서 사용하는 용어를 간략히 살펴보면 다음과 같습니다.

Ø Database Availability Group(DAG)

Ø Server

Ø Database

Ø Database Copy

Ø Active Manager(AM)

Ø Remote Procedure Call Client Service.

여기에서 DAG의 개념을 간단히 살펴보면 다음과 같습니다. 최대 16대의 서버에 걸쳐서 일련의 Database 셋을 호스팅 하는 서버 그룹을 의미합니다.

복제의 경계와 Failover의 경계, DAG의 Active Manager의 경계를 정의합니다.

Server의 경우는 복수개의 active/passive mailbox database 카피본을 호스팅하는 멤버쉽 Unit입니다. 당연히 Active mailbox database 카피본에서 CI 나 Assistant를 수행합니다.

그리고 Passive mailbox database로 Replication service를 수행합니다. 아래 녹색 부분이 Active mailbox database 입니다. 화살표는 Replication SVC를 통해서 passive mailbox database로 복제를 하는 것을 보여주고 있습니다.

또한, Information Store와 RPC Client Access 사이에 연결 포인트를 제공해 줍니다.

다음은 Mailbox Database 에 대해서 알아보도록 하죠.

한 개의 Database는 1개의 Active Copy을 갖게 되며, Active Copy만이 Mount또는 Dismount될 수 있습니다.

Maximum # of passive copies == #Servers in DAG – 1 active

Database 이름은 forest에 걸쳐서 unique 해야 하며, Server Failover/Switchover 시에 모든 active database를 이동시킵니다. 그리고 GUID, EdbFilePath, Server 와 같은 Database 레벨과 관련된 Property를 정의합니다. 여기서, 잠깐 Active/Passive 와 Source/Target의 용어를 논의해 보도록 하죠.

Availability 관점에서 볼 때는 Active/Passive라는 용어를 사용하게 됩니다. Active의 경우는 클라이언트에게 Email 서비스를 제공하도록 선택 받은 것을 말하며, Passive의 경우는 만약 Active 가 fail시에 클라이언트에게 Email 서비스를 제공하는 것을 말합니다.

Replication관점에서는 Source/Target 이라는 용어를 사용합니다. 용어자체가 직관적인 관계로 추가 설명이 하지 않도록 하겠습니다.

Mailbox Database Copy에 대해서 알아보도록 하죠. 간단히 설명하면, 복제 범위입니다.

아래그림을 보도록 하죠.

위에서 녹색 테두리 선에 있는 DB가 Active mailbox database입니다. A copy는 언제든 복제의 관점에서 Source 또는 Target이 되며, Active 또는 Passive 입니다. 두 개 동시가 되는 경우는 없습니다. DAG내의 한 Copy는 한번에 하나씩 Active 입니다. DB1,DB2,DB3 각각 하나씩이 Active인 것을 확인하실 수 있습니다.

Database copy 에 해당하는 Properties는 다음과 같습니다.

Ø Copy Status

Ø CopyQueueLength

Ø ActiveCopy

Ø ReplayQueueLength

Ø ActivationSuspended

이번엔 Active Manager에 대해서 알아보도록 하겠습니다.

High Availability의 Brain 이라고 할 수 있습니다. 어떤 Database가 Active또는Passive 역할을 할 지 관장을 합니다.

AD가 configuration 정보의 Primary source라면, 이 Active Manager는 active 와 Mount처럼 변경 가능한 정보에 대한 Primary source라고 보시면 됩니다. DAG내에 존재하는 모든 서버상에 running하는 Process 이며 PAM(Primary Active manager)와 Secondary Active Manager(SAMs)이 있습니다.

한편, 연속 복제(Continuous Replication) 에는 다음의 기본 스텝이 존재합니다.

Ø Database seeding

Ø Log copying

Ø Log inspection

Ø Log Replay

Database Seeding에는 다음 세가지가 존재합니다.

ü 자동 Seeding

ü Update-MailboxDatabaseCopy cmdlet

ü 수동으로 Database 복사.

Log Shipping 은 TCP 소켓 통신이며 암호화와 압축을 지원합니다. 타켓 복제 서비스는 Active instance에게 자기가 예상하는 로그파일을 알려 줍니다.

소스 복제 서비스는 해당 로그파일을 보내줌으로써 응답하게 됩니다. 복사 된 로그파일은 Inspector 디렉토리에 위치하게 됩니다.

Log Inspection의 경우는 Replay되기 전에 아래 세 가지를 수행하게 됩니다.

Ø Physical integrity inspection

Ø Header inspection

Ø Removal of Exx.log

만약 로그가 정상적으로 이 과정(Inspection)을 통과하게 되면, 비로소 타켓 로그 디렉토리로 이동하게 되며, 만약 실패하는 경우는 최대 3차례 까지 Recopy됩니다.

Log Replay 는 Information Store로 이동하는 것을 말합니다. 여러 Validation 과정을 거쳐서 log Replay 가 이뤄지게 됩니다.

자 그럼, 만약 문제가 발생 시에 어떤 식으로 failed 된 Database에 대한 처리가 이뤄질까요?

살펴보도록 하죠.

Ø Active Manger는 Active시킬 가장 Best 한 Copy을 결정합니다.

Ø 타켓 서버에 있는 복제 서비스는 위에서 결정된 가장 Best 한 소스로부터 missing된 로그를 Copy 받으려고 시도하게 됩니다

Ø 마운트된 database는 새로운 로그를 생성하게 됩니다.

Ø Transport Dumpster 요청이 잃어버린 메시지들을 복구하기 위해서 마운트 된 Database을 위해 발생하게 됩니다.

Ø 원본 서버 또는 Database 가 복구 되면, increment reseed 또는 Full reseed를 하게 됩니다.

Active manager는 아래의 Criteria을 근거로 Activate 시킬 database copy 본을 결정하게 됩니다.

a. Database is healthy or disconnected

b. CopyQueueLength < 10

c. Content Index is healthy.

위에서부터 차례로 우선 선호도에 따라서 순차적으로 진행하게 됩니다.

잠시 여기서 Incremental Reseed를 살펴보기로 하죠.

아래 그림을 보시기 바랍니다.

위 그림에서 녹색 부분이 Active Copy 본이라고 가정합니다. 갑자기 Sever 1의 DB1이 Fail 되었으며, Server3에 있던 Passive DB1이 Take over 해 옵니다. 그러면, 이젠 Server3의 DB1이 녹색이 되고, Server1의 DB1은 없어지게 됩니다. 얼마 후에 Server1의 DB1이 파란색으로 Passive 형태로 돌아 옵니다. 물론 inconsistent한 데이터를 가지게 됩니다. 이 때 이 DB12을 새롭게 Active 된 것과 consistent한 상태로 맞춰 줍니다.

Divergence point는 Active 와 passive copy 사이의 트랜잭션로그의 비교를 통해서 알아 낼 수 있으며, Divergence point 후에 변경된 Database Page는 로그로부터 결정하게 됩니다.

그리고 Active에서 Passive copy로 데이터베이스 페이지를 카피하며, 그 후에 새로운 로그를 Play하게 됩니다. Exchange 2010의 LLR(Lost Log Resilence)는 1로 변경 됩니다.

Backup의 경우는 Streaming API 가 아닌 반드시 VSS(Volumn Shadow Copy Service)를 사용해야 합니다. 어떤 DB나 Log를 백업해도 되지만, 가급적이면, Passive copy 본을 선택하는 것이 좋으며(물론 Active copy를 해도 된다) 전체 서버를 할 수도 있습니다.

각 Database copy 는 백업이 없는 아래 설정을 Enable합니다.

지금 까지 Exchange 2010에서 새로이 소개 된 DAG 관련 내용을 여러분께 소개해 드렸습니다.

도움이 많이 되셨기 바랍니다.

 written by Jungseo.