Hardware replication, which is the replication method addressed in this article, is executed by a physical component involved in the storage system: the storage array. An enterprise class storage array holds firmware that contains codes to handle replication. Every time an I/O occurs on the primary disk, the modification is instantly copied onto the secondary disk. The storage array monitors every disk for modifications, and modifies the secondary disk accordingly. Consequently, the secondary disk is identical to the primary diskit is cloned.
When an application accesses its data repository, it accesses, in fact, several physical disks located in the storage array. An important function of a storage array is to regroup those physical disk drives under one logical unit number (LUN). Through the software layers, an application reads its data from and writes its data to this LUN. In other words, a single I/O at the OS level implies several physical I/Os at the disk-drive level. These physical I/Os are copied onto the secondary disks during replication.
As stated previously, the physical layer is independent of the OS. Therefore, this replication is almost invisible to the OS and is controlled from physical components only. In a storage architecture, different components can control the replication: SAN switches (such as the Sun PSX-1000 switch) and disk subsystems (Sun StorEdge SE99x0 systems). This article concentrates on the disk subsystem-based replication, as this is commonly used in large storage environments. Although it is an attractive way of replicating, it brings on a number of challenges. The main challenge is: how can an application access the replicated data reliably?