Host-offload architecture is not slick marketing, It is slick design

The first time I heard the architecture of InMage Systems' DR-Scout described as "host-offload", I thought I misunderstood the person. Then when the individual continued to use the term, I concluded that InMage Systems had come up with an ingenious way to make host agents sound more palatable to end-users but that it really was not any different than any other host based replication product. However, it turns out not only did I correctly hear InMage Systems, the host-offload architecture on which DR-Scout is based is not your typical host-based architecture.

To understand how the host-offload agent architecture works, it is easier to first describe how host-based architectures operate. Host-based replication agents initially replicate the data to a remote system by first making a copy of all data on the host system while monitoring and capturing new write I/Os. In this respect, InMage Systems DR-Scout is similar to most other host-based architectures and this one-time event creates similar amounts of server overhead, ranging from 10 - 20%, depending on the amount of data it needs to copy, available bandwidth and number of write I/Os occurring on the system.

The differences between the host-based and host-offload architectures show up most dramatically in how each one captures ongoing write I/Os. Host-based architectures make a copy of each new write I/O and then store the write to a disk cache. Then the host agent may do one of two things: it may read the writes back from disk and replicate them; or, it may read the copied write back from disk, compress the write, re-write the compressed write back to disk and then read it back again from disk before replicating it. This process of writing these copied write I/Os back to the disk cache once or twice is why agents on host-based architectures create such onerous server overhead. While the number of application reads and writes and network bandwidth all impact server overhead, writing the copied write I/Os to the disk cache is the task that slows most host based replication products.

DR-Scout's host-offload architecture management of these writes is the primary way it differentiates itself from host-based architectures. DR-Scout's agent is a "lite" agent in the sense that it does not copy write I/Os to a local disk cache. Instead it partitions out a small segment of server memory and stores these write I/Os in the server memory. The DR-Scout agent then copies the write from memory to the central DR-Scout Control and Media Server (called the DR-Scout CX) over an ordinary LAN connection.

The DR-Scout CX Server that receives the write is the other half of this equation since it is critical to delivering on the promise of the host-offload architecture. By immediately sending the copied writes to the DR-Scout CX Server, the CX Server bears the brunt of the workload and overhead of copying the write I/Os to disk, not the application server. This architecture makes the CX Server more efficient in handling replications tasks, even in performance intensive environments, than host-based replication architectures.

The host-offload architecture of InMage Systems' DR-Scout may sound on the surface like some slick marketing term that InMage Systems uses to take a company's eye off the ball. Nothing could be further from the truth. Rather it is the best way to describe a slick design that not only solves a thorny problem that host-based architectures do not address. In so doing, DR-Scouts' host-offload architecture more successfully supports virtual and performance intensive environments that pure host-based architectures can not address.