a "few" questions

[pdeelman]

Replication many to one? As stated in the manual replication is achieved by filling in the replication host IP address. Can i also replicated many to one? (ie, one huge backup SAN)

Replication real-time? It also states that it will be done in real-time, but the options show a replication time (ie 5 or 10 minutes), which leads me to believe that replication isn't done real-time. which is it?

Failover? I constantly read about releasing a failover/replication improved e-open, but nothing on the website. Any idea's when this is going to be released, or still the standard "we are working on a huge improvement"?

Jumboframes? I couldn't find anything about jumboframes. Since this improves on overhead a bit. Is this possible?

List of good hardware? Browsing through the forums made a pretty good picture for me concerning hardware for achieving good GBe speeds, but where is the list? My local vendor offered me a SM box with 4x1TB seagate 32 mb cache discs, which IMO isn't that speedy. I'd rather go for 8x500GB with either 3ware or areca controllers

GPL. In some documents you state GPL is applied on certain parts of the software. So far i have yet to find the GPL software on your website. Can you provide us with a list of used (L)GPL software?

VSS. Does e-open support VSS (volume shadow service?)

[To-M]

Replication - many to one is not possible now only 1 to 1. We are working to developed this sometime next year (no set date as of yet).

Replication "Volume Replication" is synchronous, we use DRBD (you can research this on the net for more details). Info below on our current replication now. Information with AutoFailver will be released at a later date - when announced.

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.

Failover replication will be available once announced on our website. We have finial bata versions now - so should be within the end of next week - providing no other issues arise.

Jumbo frames is located in the console screen for "Hardware Configuration menu" (ALT+CTRL+W) choosing Tuning options.

List of good hardware - well most use what RAID controller interfaces with our GUI - so
3ware or areca controllers can be used. All the ones we support are on the link below.
Just make sure to use a BBU w/WB function on the RAID controller.

http://www.open-e.com/data_storage_solution/server/service_and_support.php?lang=en&subserv=prodcomp&h ardkind=HDD%20controller<br>%20(hardware%20RAID)

The Free Software Foundation certified us to be compliant to the GPL rules. Every package of our software is shipped with a cd containing all used sources.

VSS will be out next year in Q1.

To find other answers please use the search function of the forum to retrieve additional information.

[pdeelman]

List of good hardware - well most use what RAID controller interfaces with our GUI - so
3ware or areca controllers can be used. All the ones we support are on the link below.
Just make sure to use a BBU w/WB function on the RAID controller.

VSS will be out next year in Q1.

As far as OSS goes almost every piece of hardware is supported by your product. What i don't want is a SAN with bad performance. So far as GOOD hardware goes, what is a somewhat optimal configuration for hardware when i want to reach GBe (and more) speeds? I can imagine my cellie 300 box with 3x80 maxtor discs just won't make the cut, but i can find all hardware in the hardware compatibility list.

VSS, will this be self-developed VSS or opensource vss, like the iscsitarget vss? http://iscsitarget.sourceforge.net/w...nagementDaemon
I also found talk in 2005 about vss, but that's it: http://osdir.com/ml/iscsi.iscsi-targ.../msg00094.html

My main question is this: Will e-open support vss quaranteed in q1 2008 or not? What are your current developments and/or can you point me (us) to the relevant discussiongroups concerning vss development for the iscsitarget that you use in e-open.

failover/multireplication was talked about in q3 2007, but so far development has taken longer then anticipated, leading to delays, leading to customer uncomfort. Placing VSS into perspective to failover, will or will you not make the cut in Q1?

[To-M]

We plan only to implement Volume Shadow Copy requester for Samba protocol.

Concerning your question regarding Failover we had some issues that delayed us to redesign this differently. So we felt to hold this off until passing our QA and will not until then. We understand your excitement to have this previously scheduled but in some cases as even with M$ they too have delays as well - so please provide us this flexibility. End.

[pdeelman]

We plan only to implement Volume Shadow Copy requester for Samba protocol.

Concerning your question regarding Failover we had some issues that delayed us to redesign this differently. So we felt to hold this off until passing our QA and will not until then. We understand your excitement to have this previously scheduled but in some cases as even with M$ they too have delays as well - so please provide us this flexibility. End.

Posting in the iscsi subforum only leads me to believe that when requestion information about VSS i want information about vss hardware providers, not samba requesters. And my main problem is not with failover (yes i'd very much like to have it), but placing estimated timeframes in relation to other subprojects.

I only asked if, in all fairness, whether your timeframe of Q1 for VSS implementation was reasonable. I only compared it to failover, because it this feature is already postponed a couple of times.

[To-M]

Comparing the VSS timeframe may have been unjustified as they are different in complexity then replication. As I stated we have it scheduled.