Upgrading from ISCSI (Not R3)

Is there an upgrade path from open-E iscsi to ISCSI R3? Is there a significant reason to upgrade? What about clustering support? It was my understanding that it was supposed to be delivered in the 2006 Q4.

Thanks,

Errol Neal

Currently the iSCSI Enterprise to iSCSI-R3 has no ability to migrate existing Volumes. iSCSI-R3 also is based on USB DOM as the iSCSI Enterprise is IDE DOM based, so this would be difficult to provide. Although if you have a relationship with your Reseller you might be able to convince them for this upgrade, but don't quote me on this as this would be up to them. Updates for the iSCSI Enterprise has ended (we still support it) and new updates for iSCSI-R3 will continue.
We provide failover for both iSCSI Enterprise and iSCSI-R3 Enterprise, although this is manual and not automatic. We will have clustering for DSS only (not sure of the release date or conditions) that will be announced this summer. I would focus on DSS for these advanced functions.

Also I have seen your email in support concerning, not being able to start a new thread, may I please close this out to prevent duplication. ;)

Update to Auto Failover!!

Please be advised that Auto-Failover has been delayed - there is no set date or details related to this subject.
We will announce this at a later date. Thank you for your patience on this matter.

Can you please point me to any threads how to implement and best take advantage of this failover feature? I've not seen it mentioned in the docs. Are you referring to the replication feature?
And yes, the support thread regarding not being able to post is resolved.

iSCSI Enterprise Target Volume Replication is virtually the same for R-3 so if you email me at todd.maxwell@open-e.com I will provide you a video demonstrating this. Also
description below of iSCSI Replication.


iSCSI Target Volume Replication replication is very similar to RAID 1. The first stage is rebuilding of the destination to be the copy of the source volume. Next stage (endless) is online modifying the destination volume to keep the mirror. The difference comparing to the RAID 1 is that, after any broken connection only the changed data will be 'rebuild' (again first stage takes place) on the destination.

Note: the replication should be performed on separate NIC and the connection should be as fast as the main network connection, to prevent lowering data throughput. Once you create the Target Volume you have the choice to set it as Source or Destination to the mirrored server. Replication of volumes should be same size.

Changing destination to source without loosing data is only possible when data is consistent.

How to change source to destination:
1. Stop replication task on source or turn off server 2. Now it will be possible to change destination to source, when the data is consistent.

SNAPSHOT:
The Snapshot functionality is local to the system and not able to be placed on another server.

This function allows you to define parameters of every snapshot.
You can set:
* number of snapshots for logical volumes in specified volume group
* logical volume (TGV), which the snapshot will be taken for.
* space reserved for the changes in file system while the snapshot is
active - you enter value as a percent of space reserved for snapshots
* schedule - the time of automatic creation of the snapshot, if inactive -
only manual snapshot activation is possible
* RO - the snapshot will be visible as a write protected disk

The Snapshot function of the server enables the system administrator to freeze the data content of the volume at a certain time. From this moment on, the users work on a virtual data volume, all changes to the volume are stored in a different partition. The storage of all changes is independent of the file-system - it takes place on block-level. Only when the snapshot is deactivated / removed the changes are permanently transferred to the actual data volume. Snapshots can be activated/deactivated manually or automatically.

NOTE:
Please be reasonable, when you are calculating the space reserved for snapshots. Please set as snapshot size as much space as you expect to change during active snapshot. E.g. when you are doing backup from snapshot which takes one hour please set this snapshot size to as much space that will be changed during one hour. The snapshot will become inactive if the content (data changed on logical volume) exceeds the snapshot capacity. You will not lose data in that case, just the dataset, which is virtual for the users at the moment and will be written to the data volume. The old dataset, which has been frozen with the snapshot, is not available any longer.
When you define the schedule, use only as many snapshots in the same time as really needed. A large count of active snapshots can slow down the system considerably.