|
|
|
Disaster Preparedness in a Post 9/11 World
So much has changed in the last several years after 9/11, and
yet most businesses are still inadequately prepared for
disastrous situations. Not only are they vulnerable from the
threat of terrorism, but from security and natural...
Hard Drive Crash? Avoid Making A Bad Situation Worse
If you experience a hard drive crash, it doesn't take much to
make a bad situation even worse. In the event of a hard drive
crash, in most instances, the data is completely recoverable at
first. However, as part of human nature, we often try to...
Intranet
Introduction to Intranets
What exactly is an intranet? It's one of those terms that's more thrown around than understood, and has become more of a buzzword than a commonly understood idea. Simply put, an intranet is a private network with...
Software That Takes Care Of ... Other Software
What's housekeeping software? It's software that takes care of your PC and everything recorded on that hard-drive. If that's what you need, make sure you consider these titles.
HandyRecovery 2.0 (SoftLogica LLC)
As you might expect, data...
SYI: Save your Identity
The warning signs can start innocently enough that you don't even recognize them as being warning signs of impending doom. Perhaps it's a letter from your credit card company about a credit application. It might be a call from your bank inquiring...
|
|
| |
|
|
|
|
|
|
Exchange Disaster Recovery with SANRAD V-Switch Planning Guide
Introduction
Designing a disaster recovery system requires planning and
consideration of the available options that will best fit your
company's needs, SLA and budget. This guide will help you design
an Exchange Disaster Recovery plan
in conjunction with SANRAD Replication. The guide assumes that
you have basic knowledge of SANRAD V-Switch and Exchange
Administration.
Note: It is recommended to read Microsoft's Exchange
Server 2003 Disaster Recovery Planning Guide available from
http://www.microsoft.com/downloads/details.aspx?FamilyId=784BBE
A2-28DD-409A-8368-F9914E993B28&displaylang=en.
Exchange Disaster Recovery Planning
This section discusses both general and Exchange specific
considerations that need to be addressed when designing a
disaster recovery solution combining SANRAD replication and
Microsoft Exchange Server.
General Considerations
SANRAD replication solution allows for flexibility with Exchange Disaster Recovery design.
The most influential factors affecting design consideration are:
* Budget limitations
* Recovery Time Objective (RTO) requirements (the time until the
data is back online)
* Recovery Point Objective (RPO) requirements (the amount of
data that can be lost)
* Network bandwidth between the local site and remote site
* Replication method: Synchronous versus Asynchronous
* Replication frequency (only for Asynchronous replication)
* Initial volume synchronization
RTO (Recovery Time Objective)
* With high level RTO, duplicate hardware is required to allow
quick recovery making the solution more costly.
RPO (Recovery Point Objective)
RPO requirements are best defined by the amount of data that
the company is willing to lose.
* High level RPO requires more bandwidth for both Synchronous
and Asynchronous replication.
* Low level RPO requires less frequent replication and increases
the risk of losing more data.
Network Bandwidth between the Local and Remote sites
Bandwidth between the sites is generally the most crucial
factor affecting the replication component of a Disaster
Recovery solution.
* T1 (1.5Mb) links impose less frequent data replication and the
use of asynchronous replication methods.
* T3 (45Mb) links or a 1Gb links allow frequent replication and
the flexibility to choose between synchronous replication or
asynchronous replication methods.
Replication method
When considering which replication method to choose it is
important to remember:
* In Synchronous Replication the I/O commands are written
to the local disk and to the remote volume at the same time.
Every IO command requires an acknowledgment from both the local
and remote sites before the next command. Consequently,
synchronous replication is best deployed with a high bandwidth
connection in order to allow the remote acknowledgment to arrive
back to the local site as fast as possible and the replication
can run faster.
* In Asynchronous Replication the I/O commands are
written to the local volume and local journal volume which in
turn is replicated periodically to the remote volume as
periodically defined by the user. Consequently asynchronous
replication can work well with lower
Associated Websites
bandwidth (minimum
recommended for Exchange replication is 1.5 Mb) since both
acknowledgements are local (from the primary volume and the
journal volume) and thus the replication is fast by default.
* For Asynchronous replication, you must decide the data
replication frequency. There are three factors that must be
considered:
1. The size of the network bandwidth between the sites.
2. The amount of data changes that need to replicate each time.
For example, large amounts of data changes take longer to
replicate using T1 links.
3. The RPO requirements.
Initial Volume Synchronization
SANRAD replication solution can be used to protect existing
production Exchange data. SANRAD Disaster Recovery solution
supports both online and offline synchronization. When using
SANRAD replication with existing Exchange data, an Initial
synchronization of the Exchange volumes on the local site to the
remote site must be performed. The initial volume sync method
depends on:
* The size of the volumes needed to be synchronized.
* The network bandwidth between the sites. For example, the
bigger the volume size, the longer it will take to synchronize
over a T1 link.
Online synchronization starts immediately when
replication is started and uses the same network link that will
be used during the replication.
Offline synchronization is a manual process where SANRAD
replication prepares the volumes on the primary site and the
user must copy the data to the remote site. It is the user's
responsibility to make sure the volumes on the remote site are
synchronized.
Exchange Considerations
Any Exchange Disaster Recovery
planning should (at the very least) consider the following
requirements:
* Quick access to the most recent copy of the Exchange database
and the transaction logs. In a disaster situation SANRAD
replication provides fast access to the replicated data on the
remote site.
* The Exchange database and its related transaction logs must be
replicated together to the remote site. SANRAD replication uses
consistency groups to ensure simultaneous replication of all
volumes assigned to a consistency group.
* Exchange is integrated into Active Directory. An Active
Directory domain controller (running Global Catalog) which is
part of the same Active Directory domain that exists in the
primary site, must exist in the remote site as well (or at least
the capability to rebuild one and reconnect it to the existing
Active Directory Domain).
* The most up to date replicated copy of the Windows backup set
(which includes system state) to expedite Exchange Server
recovery.
Note: for detailed information about Exchange 2003 disaster
recovery considerations please read Microsoft's article,
"Exchange Server 2003 Disaster Recovery Planning Guide
(http://go.microsoft.com/fwlink/?LinkId=21277)".
This guide deals with designing a disaster recovery system while
planning and considering the available options. It further
discusses about suggested Disaster Recovery Designs, fully
Mirrored Remote Site, partially Mirrored Remote Site, small
Remote Site, combining SANRAD Disaster Recovery Designs with
Exchange Disaster, restore Models, restore Exchange with a
Standby Server and restore by Rebuilding Exchange Server. For
further reading click here
About the author:
None
|
|
|
|
|
|