Asynchronous WAN replication

[childsluke]

Hi All,

I'm trying to set up a test lab environment for Asynchronous WAN replication as advertised in the v8 datasheet. This is for a proof of concept, as we may, pending successful trial, be using StarWind products in the future.

We have 2x SANs on-site in an Active-Active configuration working as intended (very easy to setup, this was great ) and want to extend this to a 3rd SAN in an offsite location, however for obvious reasons (eg bandwidth) we would like this 3rd SAN to be set up to replicate asynchronously at defined intervals.

The 3rd SAN is set up in the DR location and is accessible to the other two SANs via VPN. However, the two issues I'm running into are:

1) The DR location is on a different subnet to our onsite SANs (we use IP routing through a gateway to connect between the two)
2) When setting up the asynchronous replication from our HA device's 'Replication Manager', it asks for separate channels [ie separate networks] for heartbeat and sync. Realistically, you're never going to have this over a WAN link, so is there a way to set up the replication using only the single channel [ie the VPN connection?]

Thanks in advance.

[anton (staff)]

1) That's a limitation of a current implementation. Both primary and disaster recovery sites and hosted LUNs should be implemented using same subnets. Please see more below about VLANs.

2) Typically we'd ask for a two physical connections (faster for data and lower performing for syncs) but if you have one then you can configure VLANs and chunk one physical into set of a logical ones.

[transparent]

Is needing two channels for WAN replication still an issue?

This earlier post seemed to suggest it had been addressed: http://www.starwindsoftware.com/forums/ ... ous#p20903

We're looking to implement this, but hoping it is a bit more "WAN friendly".

Thanks!

[thefinkster]

I have (had) WAN Async replication setup for testing out of a production system (just a 20GB image for testing purposes).

The "same subnet" is not required; you are correct. You will have to check the box at the bottom of the network replication window to allow for differing subnets; but it works. I ran my async over a VPN connection.

First issue (biggest): Async replication is automatically limiting it's bandwidth; with no way to adjust (per conversations with support); at least in the current builds. It looks to me to be about 40% of the available bandwidth; at least on my 10mbit connection.

Second issue: no way to schedule. Take DFS from Microsoft; I can set up a schedule that from 1-4am, you can use 8mbit; but from 5am-5pm (production hours for example); you're limited to 1mbit; and then from 5pm-1am; you'll get 512kbit (maybe other backups run here; and you need to make sure they DO run).

Third issue: NO REPORTS. How much changing data do we have per X timeframe; for example. How long to fully replication on async during a high-data-usage moment? Basically being able to answer questions after-the-fact instead of seeing a behavior; and then having to test in a lab the various things that affect that behavior. I cannot prepare or plan; but only react in this case.

Fourth issue: SEEDING: If you have significant data usage; and honestly, who uses StarWind who does NOT have at least 2TB or more of storage; then you'll definitely want to "seed' your async replica. This is tricky; in that you can't change the IP after creation (so they say) and they recommend setting up a VM that is on the off-site IP Subnet scheme; and then moving your data and copying the configurations to a system there; or if you're doing a VM; then migrate the VM to your off-site. That is less than ideal.

I stopped playing with aync at this point; as without being able to, at the very least, adjust bandwidth usage; and with no information available on how they adjust their available bandwidth; testing async was pointless. Too many variables that we cannot control; nor have any information on.

Reporting from the storage system is a "required" feature for me; and is always going to be the second thing I mention when discussing StarWind with other technical people. First is: "Well it works; and it works well."

Let me know if you have any other questions.

[anton (staff)]

@thefinkster

Thank you for detailed report! Good news we're currently re-working our async replication engine (moving it up in the storage stack so now same async replication features would be available w/o the differentiation what's below: FLAT or LSFS). We'll be adding what you say here one-by-one (you're not the first one to complain about seeding and bandwidth throttling). Can you put YOUR priorities on the lack of features you list?

Thank you for your cooperation!

P.S. Also please see your Inbox I've dropped a mail for you

[thefinkster]

Hey Anton.

Been busy; but just replied to your email. Thanks for reaching out!

[anton (staff)]

We're working on this so shortly after LSFS upgrade (soon) there would be a re-worked async replication. Thank you!