Exchange 2010 Mailbox High Availability Overview
Exchange 2010의 HA 에 대한 기본 개념을 간단히 다뤄 보도록 하겠습니다.
- Database Mobility
Exchange 2010 에서는 Failover 가 Server level 에서 mailbox database level 로 내려갔습니다.
이 때, Database 레벨의 Failover는 같은 서버의 다른 database 상태와는 전혀 상관이 없습니다. 예를 들어 보면, 만약 5개의 DB 가 있다고 가정 합니다. 한 DB를 포함하고 있는 Disk가 Fail 이 났고, 다른 4개의 DB는 전혀 문제가 없습니다. Exchange 2007 CCR 에서는 비록 나머지 DB가 정상이더라도 Clustered mailbox Server를 다른 노드로 Failover해야 합니다. 하지만, Exchange 2010에서는 해당 문제의 DB에 대해, 다른 서버에 있는 available한 passive copy로 failover할 수 있습니다.
이를 구현하기 위해서 AD 상에 스키마 변경이 이루어 졌으며, 좀 더 자세한 내용은 뒤에서 다루도록 하겠습니다.
- Database Mobility 개념
Database object는 더 이상 서버 하위에 존재하는 child 오브젝트 개념이 아닙니다. 그 대신, 서버와 “같은 레벨” 계층구조상에 새로운 컨테이너에 존재하게 됩니다. 그 대신 개별 Database copy instance 를 표현하는 새로운 object가 생겨 났습니다 Database copy object는 database의 child object이며, 각 개별 copy가 존재하는 서버와 연결시켜 줍니다.
아래 그림을 보도록 보시기 바랍니다.
위 그림에서 Database와 Server object의 AD 계층구조에 주목하시기 바랍니다. 변경된 스키마가 있음을 아실 수 있을 겁니다.
Database configuration object는 Database라고 불리는 container에 있으며, Server container와 같은 수준에 존재하게 됩니다. 이 database object에는 여전히 database 와 log 경로정보들이 있으며, maintenance schedule와 quota 제한 설정 값을 가지고 있습니다. 각 database object의 child object는 individual copy instance 입니다.
위 그림에서 한 가지 더 주목할 것은, 더 이상 Storage group은 존재하지 않는 다는 것과 InformationStore 오브젝트 하단에 아무것도 존재하지 않는 다는 것입니다. 예전 Exchange 2007 까지는 storage group이 InformationStore 하단에 존재 했었습니다.
또 다른 그림 하나를 보여드리도록 하겠습니다.
위 그림을 보시면, Exchange 2010 HA 관련된 기본 개념 및 그 boundary를 이해하실 수 있습니다. 이미 다른 블로그에서 한번 언급한 적이 있었던 DAG 라는 것이 가장 상위 개념으로 존재하게 됩니다. 즉, 비슷한 일을 하게 될 서버들의 묶음이라고 보시면 됩니다. 즉 DAG 라는 가장 밖에 존재하는 원 테두리 안에 Server 들이 존재하게 됩니다. 그리고 더 이상 한 서버에만 국한되지 않고 서버에 걸쳐 Active/Passive DB가 존재하게 되며, 가장 healthy한 mount된 DB를 체킹하는 Active manager는 각 서버별로 존재하게 되며 RPC CAS는 mailbox 서버를 contact 하게 됩니다.
- Database Copies
Database failover는 database copies를 통해서 가능합니다. 한 서버에는 한 개의 Active/mounted 한 database copy가 존재할 수 있으며, 하나 이상의 passive/dismounted database copies는 다른 mailbox server들에 존재하게 됩니다.
Passive copy들은 지속적인 복제(log shipping)를 통해서 Active copy와 sync를 맞추게 됩니다. 그 과정은 Exchange 2007의 CCR/SCR 과 같습니다.
지금까지 다룬 database mobility 내용을 정리해 보도록 하겠습니다.
Database 이름은 Organization에 걸쳐서 유일해야 합니다. 그리고 모든 Copy본들은 같은 path에 존재해야 합니다. 그리고 예전 버전처럼 미리 HA 관련된 설정을 할 필요가 없습니다. 필요에 따라 나중에 HA를 구성 할 수 있습니다.
- Active manager
Ø 어떤 database copy가 마운트 되는지를 결정
Ø Database가 어디에서 마운트 되는지를 추적
Ø Primary Active manager와 Secondary Active Manager가 존재함.
PAM은 한 mailbox server 가 DAG의 멤버이고 default cluster group을 관장 할 때이고, 호스트 하지 않을 때는 SAM에 해당합니다. 만약 default cluster group이 다른 서버로 이동하면, PAM Role을 버리고 SAM이 될 수 있습니다. PAM의 역할은 DAG내의 모든 database availability에 영향을 주는 모든 결정을 책임지게 됩니다.
Ø Replication Service의 부분이며, Mailbox Server에서 running합니다.
- 점진적인 Deployment
HA 특징은 더 이상 Server setup의 일부분이 아닙니다. 어떤 때라도 필요에 따라 설치가 가능합니다. HA 특징을 Enable 하는 것은 배포 후의 구성 변경으로, 이미 존재하는 Mailbox server가 재 인스톨하거나 재구성 할 필요 없이 사용될 수 있습니다. 즉, 최초 Standalone으로 구성한 mailbox 서버를 HA 솔류션으로 전환 활용 가능합니다.
Standalone 서버에 존재했던 Mailbox database copy도 지우거나 재 구성 할 필요 없이, HA 에 사용될 수 있습니다. 또한 Exchange 2007 과는 달리, 다른 role도 함께 인스톨 된 Mailbox Server도 HA 에 Join할 수 있다는 특징이 있습니다.
아래 그림을 보도록 하죠.
John 이라는 사람은 Exchange 관리자 입니다. 현재 한 개의 붉은 점선안에 mailbox server가 있고, 우측 서버는 아직 없다고 가정합니다. 즉 Front end 서버와 Mailbox Server1만 있는 상태입니다. mailbox는 아직 클러스터의 일부분이 아닙니다. John은 클러스터링으로 구성하기로 결정했습니다. 하지만 이런 결정에 대해서, 기존 버전에서는 할 일이 많습니다. DB 구성도, 서버를 재인스톨 해야 하는 등등.
하지만, 새로운 Exchange 2010에서는 단지 두 번째 서버만 추가하면 끝입니다. DAG를 구성하고, 복제를 걸어주면 됩니다.
- DAG
데이터 베이스와 서버레벨에서 자동 Failover를 제공하기 위해 함께 동작하는 메일박스서버의 그룹을 DAG 라고 합니다. 더 이상 Clustered Exchange resource 는 존재하지 않습니다. Active /passive node대신에 Active/Passive database copy가 존재합니다. 더 이상 Failover Cluster Manager 가 필요없습니다.
유일한 Clustered 리소스는 Name, IP address, FSW 입니다. 이는 Server 레벨의 failure과 cluster failure를 위해서 존재하는 것입니다.
- DAG Clustering
여전히, Window 2008 Failover clustering 을 필요로 합니다. 하지만, 기존버젼에서처럼 전면에 나서지 않고 숨은 역할을 수행하게 됩니다. Quorum 에 대한 유지관리와 Cluster group의 Failover를 주도합니다. Heartbeat를 통해서 Server 상태를 리포팅하며, 데이터 베이스의 상태정보의 복제를 담당하게 됩니다. 하지만, Window failover clustering은 Database availability에 관한한 어떤 결정에도 참여하지 않습니다.
- DAG Failover
Active Manager라고 불리우는 Exchange component는 DAG 에 포함된 모든 서버에 존재해서 서버와 데이터 베이스 상태를 모니터링 합니다. 만약 서버에 문제가 발생하게 된 경우는 모둔 Active database를 failover시킵니다. 만약 Information store나 ESE가 데이터베이스의 failed된 상태를 리포팅 하면, 해당 Active database를 Failover시킵니다.
Qurom에 문제가 있을 경우는 모든 Active database를 dismount시킵니다.
Active Manager는 DAG상의 모든 서버에서 running합니다. 현재 클러스터 그룹을 호스트 하는 Server의 AM을 특별히 PAM이라고 부릅니다. 그리고, 다른 서버들에 있는 active manager들을 SAM이라고 부릅니다. 만약 PAM role을 가진 서버가 문제가 생기면, SAM에 해당하는 서버들 중의 하나가 이를 Take over해 옵니다.
PAM은 “Select Best Copy”라고 불리우는 과정을 이용하여 어떤 database copy가 마운트 하기 그리고 서비스하기 가장 적합한 것인지를 결정합니다.
AM은 CAS 서버에게 client의 요청을 서비스할 active database를 어디에서 찾을 수 있을지를 알려 주게 됩니다.
- DAG 관리
모든 생성 및 구성관리는 shell 과 management console, 즉 exchange tasks를 통해서 관리되어 집니다. 이전에도 언급한 것 처럼, Exchange 2007 처럼 구성 전에 cluster 관련하여 미리 install 할 필요가 없습니다. 그리고 관리자는 클러스터 관리자 tool를 사용할 필요가 없습니다. 익스체인지는 익스체인지와 클러스터 관련된 이벤트를 통합화 된 방식으로 모니터 할 수 있습니다. 더 이상 T-shoot을 위해서 여러 노드에서 데이터(이벤트/클러스터로그)를 수집할 필요가 없습니다.
- DAG deployment
DAG 배포는 아직 직관적입니다.
- Ø DAG 생성
이것은 Placeholder configuration object를 생성하는 단계입니다. 껍데기를 만드는 과정인 셈이죠. 클러스터 구성과는 전혀 상관이 없습니다. AD상에 FSW 정보를 포함한 configuration object를 생성하는 단계입니다.
2. DAG에 첫 번째 mailbox 추가
백그라운드에서 Exchange는 서버에 클러스터링을 인스톨 하고 구성합니다. 그리고 DAG cluster group을 생성하고 서버를 DAG에 조인 시킵니다.
이때, DAG 클러스터 그룹을 위해서 IP을 설정하게 됩니다. 이 단계에서는 서버가 아직 한대 밖에 없기 때문에 local quorum을 사용하게 되며, 아직 FSW는 구성되기 전이기 때문에 사용되지 않습니다.
3. DAG에 두 번째 mailbox 추가
역시, 백그라운드에서 Exchange는 서버에 클러스터링을 인스톨 하고 구성합니다 그리고 두번째 서버를 DAG에 조인 시킵니다.
이 단계에서 비로서 FSW를 구성하게 되며, MNS mode로 바뀌게 됩니다.
짝수개의 Node가 있을 때는 FSW를 사용하고 홀수개일 경우는 사용하지 않습니다.
4. Repeat as necessary
필요에 따라 Single DAG에 16개 노드까지 추가할 수 있습니다.
- DAG 특징
· DAG는 서버들의 Set 입니다. Server나 DB/Disk failure에 따라 자동 복구가 이뤄집니다.
· DAG는 AD object 입니다.
· DAG는 빈 껍데기에서 시작해서 서버들이 한 때씩 추가가 됩니다.
· 첫번째 노드가 추가 될 때, 자동적으로 WFC(Window Failover Cluster)를 구성하게 됩니다. 물론 관리자에게는 이 과정에 보이지 Invisible 하며, 어떤 Exchange 리소스도 리소스 모델에 존재하지 않습니다.
- Transport Dumpster
Lossy failover 가 발생했을 때, 시스템은 failed 된 CMS로 최근의 메시지를 재전송 하게 되는 데, 이때 이용한 것이 Transport Dumpster 였습니다. 그곳에는 최근의 메시지를 보관되어 있습니다. 이것의 존재 이유는 Lossy failover가 발생했을 때, data loss를 최소화 하기 위함이었습니다. 하지만 이 솔류션은 Site 내에 국한되어졌었습니다.
하지만 ,Exchange 2010에서는 HA의 핵심 개념인 DAG가 Site내로 국한 된 것이 아니기 때문에 이 개념이 좀 더 확장되었다고 볼 수 있습니다. 즉, mailbox database가 site를 넘나 들수 있기 때문에, Transport dumpster의 개념도 재 디자인 되었습니다.
그리고, 또 하나의 변경은 Transport dumpster가 이제는 Replication pipeline으로부터 Feedback을 받는 다는 겁니다. Transport dumpster는 Active manger에 대해서 클라이언트 역할을 하게 되며, 이로서 복제된 데이터베이스의 로그 생성등까지도 알게 됩니다.
Transport dumpster에 있는 메시지를 포함하고 있는 로그가 모든 database copy에 복제가 되었을 때, Transport dumpster에서 비로서 삭제되게 됩니다. 즉 복제의 완료를 기다라는 데이터만이 Transport dumpster에 있게 됨을 의미 합니다.
- Deprecated Features
· No more scc
· No more LCR
· CCR and SCR is replaced by Continuous Availability
· No More SMB
· No more Cluster mailbox Server
- 잊어야 할 것
· Pre-installing a cluster
· Clustered mailbox servers
· Running setup in cluster mode
· Moving a clustered mailbox server
· Storage group
· Two copy limitations
· Shared storage
· Local Continuous Replication
- n 기억해야 할 것
· ESE에 대한 기초지식-logs and database
· Continuous replication에 대한 기초지식
u Log copying, inspection and replay
u Log Truncation
u Database seeding
u Replay service
u Status of log copying and replay
u Divergence
u AutoDatabaseMountDial : BestAvailability
· 사설/공용네트웍 구성
· Tracing 은 여전히 똑같음.
AutodatbaseMountDial은 Failover후에 데이터베이스에 대한 자동 마운트 동작을 명시하는 파라미터로써, Lossless/GoodAvailability(6 logs)/BestAvailability(12 logs) 세가지가 존재하며, default는 BestAvailability입니다.
소스 서버상에서 모든 데이터 없이 activate 된 데이터베이스가 타켓서버로 복제되었을 때, 이를 우리는 lossy failover 라고 일컫는데, Transport dumpster 특징은 Transport dumpster queue에 있는 메시지를 재 전송함으로써 lossy failover를 막습니다.
이것으로 Overview 를 간단히 마치도록 하겠습니다.
PS>When divergence between an active database and a copy of that database is detected, Incremental Re-sync performs.
Written by Jungseo.