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

The first time I heard the architecture of InMage Systems' 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 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 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.

Scout's host-offload architecture management of these writes is the primary way it differentiates itself from host-based architectures. 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 Scout agent then copies the write from memory to the central Scout Control and Media Server (called the Scout CX) over an ordinary LAN connection.

The 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 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' 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, Scouts' host-offload architecture more successfully supports virtual and performance intensive environments that pure host-based architectures can not address.