• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

SRM Design Questions

Vader

Supreme [H]ardness
2FA
Joined
Dec 22, 2002
Messages
5,137
I'm in the process of setting up SRM with vSphere Replication and eventually SAN replication with a couple of Uber VSA's in my lab to learn how to set this up. Since i'm fairly new to this and need to learn it bare with me.

1. Network: I'm assuming that you want to physically segment the SRM network as to not impose on production bandwidth? Does this mean that all the VM's that will be replicating need to have a virtual interface on this network, again, i'm guessing yes?

2. Storage: I'm assuming that the storage on replicated site isn't as important as the Protected site, so you could go with a lower tier storage? Is this the norm in design?

3. For 10Gbe networks, i'm assuming that you are segmenting bandwidth out of the 10Gbe on a separate VLAN to allow for this traffic, like you would with the VM, MGMT, vMotion..etc?

4. Is there a calculator to figure out required WAN bandwidth for vSphere replication?(My SRM Lab will be on the LAN so I will not have any insight on this right now) For SAN replication, i'm assuming the vendors will provide some insight on this, for example, Recoverpoint SE for EMC..etc?

Thanks in advance. I'll be setting up the protected site today and configuring the recovery site later this week hopefully to have this fully tested by the end of next week.
 
1. What? :) The VMs themselves don't replicate...if using HBR then the vSphere host does it. If using SAN based replication the arrays do it.

2. Depends. How long would an outage last? Are you okay with less performance in DR? If you it's a sustained outage are you still okay with that? More often than you'd think we end up mirroring storage, especially with more and more people looking to cross fail sites and/or do active/active datacenters.

3. Usually, yes. Kendrick Coleman and Scott Lowe have some good blog posts on pNIC configuration and traffic sharing.

4. No. We've asked VMware for this but there is still nothing. Replication traffic depends completely on your write profile. You don't replicate reads...you replicate writes. For EMC arrays I can estimate replication bandwidth but not for HBR yet.
 
The biggest "challenge" to SRM is in the failover side. Do you want to re-IP things? Are you sure? If you don't then you need to either stretch VLANs, do OTV, do VXLAN, do something. Then how do you want to run a DR test? Do you need VMs in a test bubble to talk to physical devices? If so we usually have to do more of a complex network config on the DR side.
 
1. Ok so the vCenter server needs to have an interface on the SRM network then?

2. Surprised on answer for this. but I guess it makes sense.

3. I'll check it out on Lowe's blog.

4. That sux for HBR, but Recoverpoint doens't have a calculator..etc? I guess you have to build your WAN out big then?

So stretched layer 2..what are most people doing and what are you implementing that works best, VXLAN? I did read Lowe's blog on that a while ago..have to go back to reference.
 
1. No. HBR uses vmkernel interfaces for replication and it's IP...so as long as it can route to the other side you're fine. It's vSphere host to vSphere host. Not vCenter to vCenter. vCenter servers on each side need to talk but they can do that out of the regular management interfaces.

4. I can size bandwidth for RecoverPoint. It's a tool that EMC has for pre-sales outside of RecoverPoint itself. Normally I do some PerfMon collections (and other things on other OS) and use that. It's not 100% as we can't really get dedupe/compression ratios out of it.

Most people do stretched Layer 2. We've done a few Nexus 7000 implementations for OTV for Layer 2 connectivity. VXLAN is still too new. With vSphere 5 it's only usable with vCloud Director unless you have the Nexus 1000v. You can also use LISP and we've done one or two of those..but most people just stretch VLANs if they can or they re-IP on failover.
 
I think i'm a bit confused, and I originally misunderstood. Since HBR deploys appliances, it's only those that need to be on the Replication vm network then? I'm seeing in Eric Sloof's lab for SRM he puts the Replication Appliance on a Separate SRM Virtual Machine network. Can you break it down a bit?
 
regarding the re-IPing, can't you use a floating BGP IP here?

I haven't done much with SRM to this point but i've seen this same "well are you going to re-IP everything" question before and haven't seen anyone ask if using BGP (or EIGRP) works here or not.

you ever do something like that junkie?
 
regarding the re-IPing, can't you use a floating BGP IP here?

I haven't done much with SRM to this point but i've seen this same "well are you going to re-IP everything" question before and haven't seen anyone ask if using BGP (or EIGRP) works here or not.

you ever do something like that junkie?

BGP and EIGRP are routing protocols.....really outside of SRM. If you do re-IP you'll need proper routing setup to route to/from the DR side..but you should have that anyway.
 
I think i'm a bit confused, and I originally misunderstood. Since HBR deploys appliances, it's only those that need to be on the Replication vm network then? I'm seeing in Eric Sloof's lab for SRM he puts the Replication Appliance on a Separate SRM Virtual Machine network. Can you break it down a bit?

Yes. They do the work. So if you want them on their own network you can.
 
Ok...I have SRM setup on the Lab Protected Site, and i'm now installing a new Host to act as a Recovery Site, will setup vCenter/SRM with SQL Express DB. I'm sure I'll have more questions after I get the two "sites" talking and preliminary configuration going. Maybe have this tested before the night is out..still raining here so best time to do it.

Thanks for your help.:)

 
BGP and EIGRP are routing protocols.....really outside of SRM. If you do re-IP you'll need proper routing setup to route to/from the DR side..but you should have that anyway.
right but if you have control of your SA and or work with your provider you can setup automatic (shudder) or preferably manual failover for the public IP space via BGP right? then you or the the provider (whomever manages it) swings everything over to the DR site router and the DR side picks up.

Meh, I need to dig into this more. Been meaning too but .. yeah. stuff.
 
right but if you have control of your SA and or work with your provider you can setup automatic (shudder) or preferably manual failover for the public IP space via BGP right? then you or the the provider (whomever manages it) swings everything over to the DR site router and the DR side picks up.

Meh, I need to dig into this more. Been meaning too but .. yeah. stuff.

Yes. Usually people care about the internal networking but if you're failing over public facing systems then yes, you could do this for those.

Things get real fun when you do active/active data centers with VMs moving back and forth.
 
Well, I have SRM up and talking to each other at both sites. Since i'm going to be using vSphere Replication, I have to deploy a VRMS at each site and a VR server at the Recovery site. Problem i'm faced with now is I don't have enough memory at the Recovery site.

I'll have to get some this week and continue.

One thing I am noticing however is the sheer amount of DB's for all the VMware products is staggering. For SRM alone, with VRMS, that's 4 databases just for SRM! Right now I have 8 databases before setting up VRMS..lol. A centralized DB environment must be top priority when planning for these types of deployments. I'm glad that I stood up a centralized environment in my lab..making it much easier.
 
1. No. HBR uses vmkernel interfaces for replication and it's IP...so as long as it can route to the other side you're fine. It's vSphere host to vSphere host. Not vCenter to vCenter. vCenter servers on each side need to talk but they can do that out of the regular management interfaces.

4. I can size bandwidth for RecoverPoint. It's a tool that EMC has for pre-sales outside of RecoverPoint itself. Normally I do some PerfMon collections (and other things on other OS) and use that. It's not 100% as we can't really get dedupe/compression ratios out of it.

Most people do stretched Layer 2. We've done a few Nexus 7000 implementations for OTV for Layer 2 connectivity. VXLAN is still too new. With vSphere 5 it's only usable with vCloud Director unless you have the Nexus 1000v. You can also use LISP and we've done one or two of those..but most people just stretch VLANs if they can or they re-IP on failover.

Host to vr server, not host to host.

Lemme see what i can get on bandwidth for you
 
One thing I am noticing however is the sheer amount of DB's for all the VMware products is staggering. For SRM alone, with VRMS, that's 4 databases just for SRM! Right now I have 8 databases before setting up VRMS..lol. A centralized DB environment must be top priority when planning for these types of deployments. I'm glad that I stood up a centralized environment in my lab..making it much easier.

That's what I thought, too, as my database counts grew. I'd highly recommend setting up a dedicated SQL VM for two reasons:

1. Customers are going to have dedicated SQL servers so you may as well, too.
2. What better way to practice virtualizing a critical SQL server than to do so in your own lab?
 
I have the VRMS Appliance deployed at the protected site, but it will not connect to my SQL DB instance I created for this particular VRMS. I've checked that all the TCI/IP IP connections are using the proper port, Mixed Mode is selected for Authentication since i'm using a Domain Service account, very strange. DNS is validated..etc. Hrmmm....

What's odd is that I can connect no problem from a Windows host using the ODBC System DSN to validate connectivity and I can ping and telnet to port 1433 from the VRMS server.

 
Last edited:
1. Don't use DNS.
2. What version of SQL are you using? If Express, you're going to ahve problems out of the box.
3. It's not ODBC, it's JDBC. This means static ports. See item 2.
4. It's not ODBC, it's JDBC - this means domain accounts no worky. Create a SQL account named the same as the database and schema. Or just use SA if you don't care. See item 2 as well.

It's linux, not windows - think unix-style.
 
That's what I thought, too, as my database counts grew. I'd highly recommend setting up a dedicated SQL VM for two reasons:

1. Customers are going to have dedicated SQL servers so you may as well, too.
2. What better way to practice virtualizing a critical SQL server than to do so in your own lab?

Solution for that will be coming eventually ;)
 
1. Don't use DNS.
2. What version of SQL are you using? If Express, you're going to ahve problems out of the box.
3. It's not ODBC, it's JDBC. This means static ports. See item 2.
4. It's not ODBC, it's JDBC - this means domain accounts no worky. Create a SQL account named the same as the database and schema. Or just use SA if you don't care. See item 2 as well.

It's linux, not windows - think unix-style.
SQL Server 2008 R2.

Just used my viewcomposer local DB account and assigned it to the VRMS DB in SQL MGMT Studio..worked like a charm! Thanks!
 
I'd like to revisit the best practices for Network configuration for SRM. I'm assuming a lot of customer designs will have SRM included.

What do you guys/gals do when adding SRM to the design pertaining network configuration? What are you adding to address the additional replication traffic if using vSphere Replication?

In my lab, I have SRM installed on my Infrastructure VM segment on a vDS with all other infrastructure VM's, however my VRMS is installed on a Separate vSS VM Network on the same segment as to avoid sharing of physical uplinks with my VM network. I'm guessing this is the wrong way to go about it.
 
I've yet to do an actual design with HBR. I think we've done two installations...maybe. To me it all comes down to traffic. Replication traffic is no different than any other. If you're using vDS you can use NIOC and adjust shares for it...let LBT handle load balancing multiple NICs proactively... I don't think I'd be dedicating NICs on each host just for replication.

Just treat it as a constant semi-latency sensitive network load like any other and design around it. Your bottleneck on replication isn't going to be that vSphere host..it's going to be your WAN connection.
 
Ok..that makes sense..so throw those uplinks into my current vDS and run NIOC to assign the bandwidth for this purpose...got it.

Off topic, i'm using IP Hash Load balancing with my vDS along with Port Channels on my switches in my Prod environment at work. Would I see a better benefit, tearing down the portchannels and just going LBT and let vSphere handle it? It certainly is a much easier way to go, no?
 
Depends (yes, I say that a lot). I like LBT a lot. It's easy and the only pro-active balancing scheme BUT it works like Hashing by Virtual Port ID...meaning all traffic to/from a VM (or vmkernel) goes over a single NIC. With IP hashing if you have a server talking to a lot of clients (or other servers) it'll hash those conversations over possibly different NICs...you're just at the mercy of the hashing algorithm as to how it all balances out. There are pros and cons to both. A VM may be constrained by a single NIC w/ LBT but you may also end up with your heaviest network I/O users hashed to the same NICs on IP hashing and not be able to do anything about it.
 
And for discussions on pros, cons, options, and recommendations for hashing types and connectivity go vote for my session on physical connecting vSphere hosts for VMworld. :)
 
I will certainly vote for your sessions, at the current job, VMworld is out, but i'm still pounding the pavement and my goal is to be outta here before the end of summer..so it's quite possible that I could attend..not counting that out as of yet, several possibilities in the pipeline.
 
Last edited:
SRM vSphere Replication Test is successful! Error is from not having VMware tools installed on the UCS Emulator Applianc...didn't think of it until after I ran the test. On to Array based replication with Uber VSA's.

 
Nice work!

What did you use for backend disks on your UBER VSAs? I'm running Nick's UBER VNX and NFS performance is so bad I can't even SVMotion a VM onto it.
 
On one host i'm using 4 x 1TB Western Digital Blacks in a RAID10 array on an LSI SAS 2008 and the other host I have 4 x 500GB Western Digital Blacks in a RAID10 array on an LSI SAS 2008.

I have yet to setup the UberVSA's on these new hosts, but my previous lab I had two setup on a single host, nested ESXi all within VMware Workstation and I remember it was pretty slow but I could svmotion a vm..hrmmm..how is your VSA setup?

I have two SSD's sitting around, I may just use those.

You could try the HP P4000 VSA's as well, very easy to setup, free for 60 days. I have a couple setup in a lab at work, I actually have a crap load of VSA licensing that came with our two p4000's. I have Remote replication running between the two but alas, it's not for vSphere.
 
For environments that need to re-ip is that just done with a Recovery Script?
 
Last edited:
IP changes are built in to SRM. Just adjust the recovery options for the VM.

Ahh..I didn't see that. Going to have to dig a little deeper.
 
Yup..found it under the recovery plan on configuring the VM settings.

This really is a slick product!
 
Back
Top