SAN Backup cluster

[nuhu]

Hello All,

I have a potential client that is interested in the starwind solution because of cost (HP too expensive) but they have 2 sites connected via a satellite link (512kb/512kb). They want to have a SAN setup at both ends of the satellite link and be able to incremental backup of the data on site A to site B (via satellite) and vice versa (incremental backup of the data from site B to site A via the same satellite link). The whole initial data at both sides will be manually backed up to the other side and then we only expect incremental byte level changes to the data to be backed up.

Even though i have been told that this will not work unless i get a 100Mbps link (this is Africa, we do not get those kind of luxuries here), i have taken a look at other solutions line storage mirroring from HP and they seem to be able to do incremental backups via LANs and WANs (even over slow links).

Has anyone tried this before? and/or will this work?

how does Starwind's CDP (Continuous Data Protection) help me?

Cheers!!

NM

[anton (staff)]

Unfortunately for our HA configuration you need to have fast link between both nodes. Or link speed is going to be a performance limiting factor... For "one-way-ticket" (background replication) you can use slow link and we do use some techniques to take care of slow connection (cached and overlapped I/O, delayed writes, pseudo-de-duplication etc). But in this case you just have second backup site, if first one will go AWOL you'll have non-zero time to recover. Upcoming StarWind will have fast link requirement eliminated but it's going to take time before you'll see one... (true GEO cluster).

[nuhu]

Hello Anton,

Thank you for the response.

The solution we are proposing is not the typical HA solution or a cluster solution. The client is not looking for automatic failover, they basically just want to have a copy of their data from site A at site B and vice versa in the event that Site A or Site B burns down. This is basically a disaster recovery solution.

You said “For "one-way-ticket" (background replication) you can use slow link and we do use some techniques to take care of slow connection (cached and overlapped I/O, delayed writes, pseudo-de-duplication etc). this may work for me, please can you explain on this further or point me to a document that will help.

Thanks

Nuhu M

[Aitor_Ibarra]

Hi Nuhu,

Even with replication rather than HA, I don't think that the satellite link will be good enough, unless you expect [b]very/b] low i/o.

Apart from the low bandwidth, 512Kbit/s, if used 24/7 and with no contention (other users of the same bandwidth) and no tcp/ip overhead, you would only be able to transfer 5.2GB a day maximum. (512Kbit = 64Kbyte - i.e. you can transfer the RAM of a Commodore 64 every second, or 3.75MB per minute, 225MB per hour, 5400MB per day)

Realistically you're going to see much less than 5GB a day over 512Kbit/s, and if your data changes more than that, then your recovery site would never be in sync with your primary site.

On top of low bandwidth, satellite means higher latency because of the larger distances (your traffic has to go up into space and back, not along a cable) - nothing goes faster than the speed of light! This will be down to the straight line distance between your two sites on the ground and the satellite in space. According to this http://www.dslreports.com/faq/2001 , your ping time (the time it takes for a packet to go out from one location, be received at the other location, and a return packet come back) is going to be about 850 milliseconds. I don't know how well iSCSI can cope with such high latency; the initiators may see the high latency as a broken link. Anton will know!

Maybe you can prioritise some data to go over the link (stuff that doesn't change much every day, but absolutely has to be in sync at both sites) and other larger but lower priority data through a lower-tech method like physically transporting a backup disk every week?

Another option is to look at file level replication, e.g. something like DFS with RDC on windows, which is smart enough to only send the changed part of each changed file, uses compression and can cope with high latency. The main problem with it (unlike block level replication like Starwind) is that a file has to be closed for it to replicate. No good for stuff which keeps locks on files (E.g. databases).

hope this helps,

Aitor

[anton (staff)]

In such a case you need "Mirror and Replication" edition and you really need start looking at mirror and replication PDFs.

Hello Anton,

Thank you for the response.

The solution we are proposing is not the typical HA solution or a cluster solution. The client is not looking for automatic failover, they basically just want to have a copy of their data from site A at site B and vice versa in the event that Site A or Site B burns down. This is basically a disaster recovery solution.

You said “For "one-way-ticket" (background replication) you can use slow link and we do use some techniques to take care of slow connection (cached and overlapped I/O, delayed writes, pseudo-de-duplication etc). this may work for me, please can you explain on this further or point me to a document that will help.

Thanks

Nuhu M

[anton (staff)]

Indeed, only de-duplication based solution with HUGE lookup database and very small transfer block is going to work with such a slow connection. But with tons of generated data and very poor de-duplication coefficients (say we're talking about IP video surveillance or voice recording or whatever generating non-overlapping content) nothing is going to help...

Hi Nuhu,

Even with replication rather than HA, I don't think that the satellite link will be good enough, unless you expect [b]very/b] low i/o.

Apart from the low bandwidth, 512Kbit/s, if used 24/7 and with no contention (other users of the same bandwidth) and no tcp/ip overhead, you would only be able to transfer 5.2GB a day maximum. (512Kbit = 64Kbyte - i.e. you can transfer the RAM of a Commodore 64 every second, or 3.75MB per minute, 225MB per hour, 5400MB per day)

Realistically you're going to see much less than 5GB a day over 512Kbit/s, and if your data changes more than that, then your recovery site would never be in sync with your primary site.

On top of low bandwidth, satellite means higher latency because of the larger distances (your traffic has to go up into space and back, not along a cable) - nothing goes faster than the speed of light! This will be down to the straight line distance between your two sites on the ground and the satellite in space. According to this http://www.dslreports.com/faq/2001 , your ping time (the time it takes for a packet to go out from one location, be received at the other location, and a return packet come back) is going to be about 850 milliseconds. I don't know how well iSCSI can cope with such high latency; the initiators may see the high latency as a broken link. Anton will know!

Maybe you can prioritise some data to go over the link (stuff that doesn't change much every day, but absolutely has to be in sync at both sites) and other larger but lower priority data through a lower-tech method like physically transporting a backup disk every week?

Another option is to look at file level replication, e.g. something like DFS with RDC on windows, which is smart enough to only send the changed part of each changed file, uses compression and can cope with high latency. The main problem with it (unlike block level replication like Starwind) is that a file has to be closed for it to replicate. No good for stuff which keeps locks on files (E.g. databases).

hope this helps,

Aitor

[nuhu]

Hello All,

Thanks for the responses and the insights.

The client will not be generating more than 100MB a day. in anyway, we intend to do a POC just to be sure that the proposed solution will work before we hopefully go live in production.

Thanks again.

Nuhu M

[anton (staff)]

Sure. If you want to have on-line assistance from pre-sales engineers please drop us an e-mail to support@starwindsoftware.com and we'll be happy to help you with the configuration. Thanks!

Hello All,

Thanks for the responses and the insights.

The client will not be generating more than 100MB a day. in anyway, we intend to do a POC just to be sure that the proposed solution will work before we hopefully go live in production.

Thanks again.

Nuhu M