Table of Contents
Copyright 2015 LockLAN Systems Pty Ltd
The right of LockLAN Systems Pty Ltd to be identified as author and copyright owner of this work is asserted by LockLAN Systems Pty Ltd in accordance with Australian copyright laws as determined by the Australian Copyright Council.
Copyright extends to any and all countries in which this publication is purchased and/or viewed and/or read.
All rights reserved. No part of this publication may be reproduced or transmitted, in any form by any means without the prior written permission of the author, nor be otherwise circulated in any form of binding or cover other than that in which it is published and without a similar condition being imposed on the subsequent purchaser.
The purchaser of this publication indemnifies Paul Cunningham and LockLAN Systems Pty Ltd and its directors, officers, employees and agents from and against all losses, claims, damages and liabilities which arise out of any use of this publication and/or any application of its content.
To buy a copy of this ebook visit http://exchangeserverpro.com/ebooks.
If you find an error in this ebook wed love to fix it. Please let us know at http://exchangeserverpro.com/contact.
About the Authors
Paul Cunningham
| Paul Cunningham is an Exchange Server MVP and Systems Consultant living in Brisbane, Australia. Paul is the founder of ExchangeServerPro.com, a leading website in the Exchange Server community. He also holds several Microsoft certifications including for Exchange Server 2007, 2010 and 2013. Connect with Paul on Twitter (@ExchServerPro) and LinkedIn. |
Michael Van Horenbeeck
| Michael Van Horenbeeck is the Director of Product Research for ENow Software, an Exchange Server MVP, and a Microsoft Certified Solutions Master from Belgium who specializes in Office 365 and Hybrid deployments. Connect with Michael on Twitter (@mvanhorenbeeck) and LinkedIn. |
Steve Goodman
| Steve Goodman is Head of Unified Communications for Content and Code, one of the United Kingdoms top Microsoft partners, and an Exchange Server MVP. Steve is an expert in complex, large scale Exchange Server deployments as well as Office 365. Connect with Steve on Twitter (@stevegoodman) and LinkedIn. |
The authors would like to extend a special thanks to Tony Redmond, Tony Murray, Scott Schnoll and Tim Heeney for their assistance with this ebook.
Introduction
Welcome to Deploying and Managing High Availability for Exchange Server 2013.
High availability has become an essential part of the email services in many organizations around the world, which means that understanding how to deploy and maintain a highly available Exchange Server environment is a critical skill for Exchange Server administrators.
Microsoft Exchange Server 2013 builds upon the high availability features of previous versions of Exchange, as well as introducing many architectural changes and new features.
In this guide well go through these changes and features, explain how they work, and demonstrate how they can be used in the real world when you are working with Exchange Server 2013 for your customers.
The chapters in this guide cover:
- Client Access server high availability, including load balancing, namespace planning, and SSL certificates.
- Mailbox server high availability, including deploying and configuring Database Availability Groups, multi-site considerations, and using features such as lagged database copies.
- Transport high availability, including the features of Exchange Server 2013 that protect email in transit, and Edge Transport servers.
- Unified Messaging high availability, including how the architectural changes in Exchange Server 2013 impact UM.
- Managing and monitoring high availability, including backups, recovery scenarios, and Managed Availability.
- Hybrid configuration high availability, including the considerations for organizations integrating with Office 365.
What is High Availability?
In the world of Information Technology (IT) the term high availability generally refers to a system or service that has been designed and implemented to meet a desired level of performance and availability.
Were sure you are already familiar with the term high availability, but lets discuss it here first to lay the foundation.
A service is available when it is accessible by end users, and is successfully performing the tasks that the service is designed to fulfil. This is also referred to as uptime.
A service is unavailable when it is not accessible by the end users. This is also referred to as downtime. Depending on the organization downtime may or may not include scheduled downtime for systems.
High availability doesnt necessarily mean always available, but it does tend to mean a very high percentage of uptime during the hours of the day that the service is required, such as 98%, 99.9%, or even the five nines target of 99.999%.
Availability is usually measured across an entire year. Here are some common availability targets, along with what they mean in terms of weekly, monthly, and yearly downtime.
Availability Target % | Yearly Downtime | Monthly Downtime | Weekly Downtime |
90% | 36.5 days | 72 hours | 16.8 hours |
95% | 18.25 days | 36 hours | 8.4 hours |
99% | 3.65 days | 7.2 hours | 1.68 hours |
99.5% | 1.83 days | 3.6 hours | 50.5 minutes |
99.9% | 8.76 hours | 43.8 minutes | 10.1 minutes |
99.99% | 52.56 minutes | 4.32 minutes | 1.01 minutes |
99.999% | 5.26 minutes | 25.9 seconds | 6.05 seconds |
As you can see a high availability target % leaves very little room for unplanned downtime.
Availability targets should be driven by a customers genuine business needs, although often they are just a number out of thin air with no real business justification behind it.
For example, a business might determine that they can afford only 1 hour of downtime for their email service in a month. So their availability target could be defined as 99.9%, which means about 43 minutes of downtime per month.
Availability targets such as those become the basis for the design of the service, as well as the operational procedures surrounding it.
For example, servers need to be maintained with security patches and other updates, which means some planned downtime of components of the service will be necessary at regular intervals.
So the email service would require a technical design that allows some parts to be unavailable at different times without interrupting the availability of the service, and operational procedures to be followed when performing planned maintenance.