Stretched cluster + DL380Storage Server + OV Storage Mirroring

[Bas van Beek]

Is it possible to build an stretched Cluster (with iSCSI-Featurepack) on two mirrored DL380 Storage Servers? The cluster is based on W2K3-ENT and probably Exchange-ENT and SQL-ENT.

Clusternode 1 and DL380SS-1 are on location 1 and clusternode 2 and DL308SS-2 are on location 2. Both clusternodes use DL380SS-1 as primary storage (via iSCSI Featurepack). Via OV Storage Mirroring DL380SS-1 is mirrored to DL380SS-2. If DL380SS-1 fails DL380SS-2 should immediately become the primary storage. Both locations are linked with Fo (1000Sx).

[Steven Clementi]

Bas:

I think as long as the 2 nodes of the cluster are on the same subnet, you should have no problem building the cluster. The nodes need to have at least 1 NIC that is on the same IP Subnet.

I have several "stretch" clusters between my 2 sites using direct EVA storage and Windows Server 2003. The only unknown for me is the iSCSI piece.


Steven

[Jon Paul]

Hi Bas,
Using the OV Storage Mirroring would not be suggested. OVSM will not maintain the data integrity of your SQL or Exchange databases.
The iSCSI feature pack has an available replication option with application specific Snapshot agents "to ensure database and messaging system integrity throughout the replication process"

There is a trial version of the iSCSI software available from HP. http://h18006.www1.hp.com/products/storage/software/inas/index.html

[Ruslan]

Hi Bas!

I have build cluster on single storage server using iSCSI. There are 2 version of Storage Servers based on Win2k3 Standard Edt. and Win2k3 Ent.Ed. The last version have the ability build Storage Server Cluster with iSCSI Clustering option. iSCSI isn't recommended of high I/O application such as SQL server.
As posted above - OVSM is not full REAL-TIME mirroring solution

[Basil Vizgin]

Cannot agree with Ruslan that OVSM is not full REAL-TIME mirroring solution. SM do byte-to-byte replication of written data, while application agents needed for snapshot purposes (or when the replication started, as used in iSCSI replication) to flush the cache. When replication in progress we can achieve full transaction integrity only with application cache turned off. Or create snapshots every second:)
And actually for iSCSI clusters is preferably to use iSCSI Replication services to achieve fully integrated solution.
All of this text is my HO:)