TECHNICAL SOLUTION BRIEF

Transcription

1 EXCHANGE 2010 DAG Microsoft Exchange Database Availability Groups (DAG) provide a simpler way to replicate data than the approaches in previous versions of Exchange, allowing for easier creation of a single-site high availability (HA) solution. But how can you leverage hybrid cloud services in conjunction with the built-in features of a DAG to create a highly resilient Exchange 2010 solution? Overview is an integral and vital part of everyday operation for all businesses. It comes as no surprise that keeping Microsoft Exchange highly available to end users is a chief concern among business and IT leaders. In the event of a disaster of any size, the availability of services is a core concern. For many companies, the loss or disruption of services would severely restrict productivity and business continuity. Mailbox databases and the data they contain are one of the most critical components of any Exchange organization. In Microsoft Exchange Server 2010, you can protect mailbox databases and the data they contain by configuring your mailbox databases for high availability and site resilience. Exchange 2010 reduces the cost and complexity of deploying a highly available and site resilient messaging solution while providing higher levels of end-to-end availability and supporting large mailboxes. Building on the native replication capabilities introduced in Exchange Server 2007, the new high availability architecture in Exchange 2010 provides a simplified, unified framework for high availability and site resilience. Exchange 2010 integrates high availability into the core architecture of Exchange, enabling customers of all sizes and in all segments to economically deploy a messaging continuity service in their organization. In Exchange 2010, Microsoft has introduced a feature called Database Availability Groups (DAGs) which is the most significant feature that has been made available in Exchange 2010 and addresses many of the limitations of HA features that were available with previous versions of Exchange. DAGs provide Exchange administrators with a simplified, elegant and highly capable approach for providing database redundancy. A DAG consists of member servers that participate in the group. Each member server will be responsible for a set of active mailboxes. An active mailbox is the mailbox that will be used for clients to send/receive their messages. Additionally, each member server will have some combination of passive mailboxes. A passive mailbox is a copy of an end user s mailbox that is not being actively accessed. Rather than being actively used, the passive mailbox receives copies of all messages and calendar entries. Since DAG member servers can be located in more than one physical location, this basic architecture allows the Exchange administrator to keep copies of end user mailboxes in more than one location at the same time with the passive mailboxes staying in sync with the equivalent active mailbox. The nscaled Advantage Deploying a DAG in a single site only protects against server or database failures and should be considered an HA solution, not a DR solution. The beauty of the DAG solution, however, truly appears when leveraging the solution by adding a datacenter presence at another location. With access to nscaled s Hybrid Cloud approach, a DAG member server can reside in another location providing a safe, highly available, off-site DR solution for data. Because of nscaled s Recovery as a Service services (RaaS), it is possible to architect an Exchange 2010 environment that is highly available even in a serious disaster. With nscaled, you know where your data lives. Our nscaled, Inc. 1

2 hybrid cloud gives you privacy and security for your most business critical data. In addition to providing a safe and secure off-site location for one or more DAG member servers, nscaled can also protect other business-critical servers to the same off-site location, offering quick recovery times for those services as well. Basic Architecture This drawing shows a basic DAG arrangement with two servers local to the customer datacenter and one cloud DAG member. In this architecture, the nscaled hybrid cloud environment exists as a separate AD site under AD Sites and Services. Each mailbox server local to the customer site has mailboxes redundantly distributed across the local DAG members in order to survive the failure of a single DAG member. The cloud DAG member has passive copies of all of the mailboxes. The cloud can have multiple DAG members if needed for performance. The quantity and roles of auxiliary servers in this model (CAS, HUB, etc.) can be varied depending on specific design goals. This architecture relies on one File Share Witness (FSW) in the customer datacenter and an alternate File Share Witness in the nscaled cloud and DAC (Datacenter Activation Coordinator) enabled. The Witness role can be installed on any Exchange server that is not a member of the DAG such as a Client Access Server (CAS) and used to achieve quorum. nscaled, Inc. 2

3 Single Server Failure The drawing below shows the failure of a local DAG member server. In this scenario, the passive mailbox databases on the surviving DAG member server are made active and the local server carries the entire load of Exchange mailboxes. An alternate approach would be to activate those mailboxes on the cloud DAG member. nscaled, Inc. 3

4 Site-wide Failure Exchange 2010 SP1 reduces the cost and complexity of deploying a highly available and site resilient messaging solution. Recovering from a site-wide failure in an Exchange 2010 SP1 DAG environment is a straightforward process, as is failing back. This drawing shows the failure of both local DAG member servers. In this scenario, the cloud DAG member becomes the primary resource for all Exchange data. The role of auxiliary servers such as CAS and HUB are key to how quickly failover happens as well as how many connections the cloud environment will be configured to handle (simultaneous). With proper planning around a specific Recovery Time Objective (RTO), an appropriate architecture can be developed. nscaled, Inc. 4

5 The Failover-Failback Process The following flow chart shows process of failover and failback using the described architecture. nscaled, Inc. 5

6 Scaling The Solution For Multi-Site Environments The drawing below shows a multi-site customer with multiple database availability groups each with multiple member servers. Each customer location is a site under AD Sites and Services (indicated by the different color outlines and site names). Each site has a DAG (indicated by the shading of the mailbox groups) with at least one DAG member server in the cloud. This model allows any given site to failover to the cloud in a disaster without impacting the other sites in question. About nscaled nscaled provides hybrid cloud infrastructure as a service (IaaS) for the enterprise. We serve customers with highly confidential data and zero tolerance for system downtime or data loss. Our unique Hybrid Cloud architecture gives customers maximum flexibility and dependability; our services agreement is the strongest, most customer-centric available; and our 24x7 customer support is unmatched in expertise and responsiveness. nscaled offers customers multiple cloud solutions, including primary application hosting, disaster recovery, and backup. All services take advantage of our global network of Remote Cloud data centers plus our on-premises Local Cloud Appliance, all managed as one secure, seamless infrastructure. The company is headquartered in San Francisco with offices in London. For more information, please visit or write to info@nscaled.com. Revised nscaled, Inc. 6