Datasheet

overvieW of availabilitY MechanisMs

CCR Cluster continuous replication, for high availability (HA)

SCR Standby continuous replication, for disaster recovery (DR)

DAG Database availability group, for HA and DR combined

Exchange Server protection options will be covered in Chapter 7.

Decision Question: How Asynchronous?

Because built-in availability solutions usually replicate (asynchronously), we need to ask our-

selves, “How asynchronous can we go?”

Asynchronous Is Not Synonymous with “Near Real Time” — It Means

Not Synchronous

Within the wide spectrum of the replication/mirroring/synchronization technologies of data pro-

tection, the key variance is RPO. Even within the high availability category, RPO will vary from

potentially zero to perhaps up to 1 hour. This is due to different vendor offerings within the space,

and also because of the nature of asynchronous protection.

Asynchronous replication can yield zero data loss, if nothing is changing at the moment of

failure. For replication technologies that are reactive (meaning that every time production data

is changed, the replication technology immediately or at best possible speed transmits a copy of

those changes), the RPO can usually be measured within seconds. It is not assured to be zero,

though it could be if nothing had changed during the few seconds prior to the production server

failure. For the same class of replication technologies, the RPO could yield several minutes of

data loss if a signiﬁcant amount of new data had changed immediately prior to the outage. This

scenario is surprisingly common for production application servers that may choke and fail dur-

ing large data imports or other high-change-rate situations, such as data mining or month-end

processing.

However, not all solutions that deliver asynchronous replication for the purpose of availability

attempt to replicate data in near real time. One good example is the DFS included with Windows

Server (covered in Chapter 5). By design, DFS-R replicates data changes every 15 minutes. This

is because DFS does not reactively replicate. In the earlier example, replication is immediately

triggered because of a data change. With DFS-R, replication is a scheduled event. And with the

recognition that the difference in user ﬁles likely does not have the ﬁnancial impact necessitating

replication more often than every 15 minutes, this is a logical RPO based on this workload.

Even for the commonplace workload of ﬁle serving, one solution does not ﬁt all. For example, if

you were using DRS-R not for ﬁle serving but for distribution purposes, it might be more reason-

able to conﬁgure replication to occur only after hours. This strategy would still take advantage of

the data-moving function of DFS-R, but because the end goal is not availability, a less frequent rep-

lication schedule is perfectly reasonable. By understanding the business application of how often

data is copied, replicated, or synchronized, we can assess what kinds of frequency, and therefore

which technology options, should be considered. We will take a closer look at establishing those

quantiﬁable goals and assessing the technology alternatives in Chapter 2.

572146c01.indd 11 6/23/10 5:42:20 PM