Saturday, December 15, 2018

Real Use Cases For Stretched Networks

I wanted to take a quick poll from some of you out there to help me understand something.  With all the work I have done with the Nicira Layer 2 Gateway, as well as the vCloud Connector Data Center Extension, the concept of extending your network to the cloud always comes up.  As an ex-administrator myself I can certainly see a small number of real, true uses cases where you would without a doubt, have to extend the network.  Off the top of my head this would be:

  • Licenses tied to a MAC address
  • Applications hard-coded to IP
  • Lack of DNS control preventing DNS Updates
  • Disaster Recovery (Maybe but not so much)

What I am struggling with is outside of these what makes this so attractive and a “must have” for you?  I have never really had an issue as an administrator changing IP address, albeit it’s a PITA, but it’s not impossible.  That being said would the scenarios above really be the first things you would try to move to the cloud in a hybrid scenario?  I would think you’d go after something easier like net new Infrastructure with a site to site VPN or MPLS to the cloud.  Migrating existing virtual machines that are not tied to their IP should be also easy to deal with.

So I take it to you all, to help me identify more “Must Have” reasons to extend your network into the cloud.  Are there really reasons to have every network on premise in your cloud or is it really isolated to some of these one-off use cases?  Everyone wants to do it but when I keep asking “Why?”, usually it is just because they “want to” not because they “have to”.  That tells me maybe it’s more about making it easier, but really how hard is it to change an IP address?  If it’s that hard, isn’t that an issue with the application design?

Please chime in, I’m curious to start a discussion about this, and get some more valid “Why’s” to this question.  As always I am curious to start a spirited discussion on this topic, so please leave your comments below.

13 comments

  1. DR is not a use case. If you have disaster that you have to recover from, then supposedly you don’t have live VMs in the original location, so you can move the subnet over to DR site by reconfiguring L3 equipment @ DR site … although some people prefer to have a single failure domain across 2 DCs instead of a config script.

    • Great point Ivan, but it surprises me how many people mention DR and Stretched Cloud network in the same sentence as something they want to do. I do hope others chime in so I can see if my small set of use cases really is what floats to the top of the pool. 🙂

  2. Changing the IP’s on 15,000 VM’s is no simple task. What is not like with concept of Metro or GEO HA? If I can have my primary datacenter go off line and HA starts up all my VM’s at my second data cetner that’s huge. Or if we find a cheeper datacetner or have datacenter maintanance? Simple just vMotion the VM’s to differnt Datacetner, it’s true BC not DR.

    • I would not say it is a simple task, but I’m really looking for the reasons why people must have the need to keep all the IP’s the same. I think your scenario is more about Ivan’s comment if this is for DR or not. I still have not heard if my other reasons are the only other valid ones, BC/DR aside.

  3. I’ve had multiple VMware employees tell me the only use case for this technology is for 1 time workload migrations. After that you have to control two subnets as if it’s another location.

    Greg Herzog
    @miamiowangeles for vCC in general? Yes it’s primarily a migration tool.

    “In addition, we discussed the
    layer 2 capability as it is offered today, and clarified the suggested use
    cases including migration of workloads to the cloud. Since you had originally
    understood our layer 2 capability within a DR perspective, Henry
    suggested that since your router would still be required to move workloads –
    this would not fit DR as a use case in the event your Primary Data Center went
    down.” – Lori Scott vCloud Air Specialist

    • I think you need to be careful when adding words like “only” before use case. My quote on vCC in general is that it was primarily used for workload migrations at this stage as that’s what it was built for, but obviously we’ve been expanding its feature set. The new features like DCE expand on its core principles to start including other use cases, although as Lori pointed out, they may not be a fit for everything such as DR. But to say that the only use case for this technology (not sure if you’re referring to vCC or DCE since they’re separate things and the article is about DCE) is migration is not correct.

    • Greg was just ahead of me I think. 🙂

      The question in this article is about Stretched networking in general not even DCE specifically. We do need to separate the core function of vCC which has been always first and foremost a tool to copy and migrate workloads. New features have started getting added in like DCE and Catalog Sync and vCC is just the product that houses those features.

      Taken out of context the two things can get confusing and I do see people use vCC and DCE together under the same “Technology”, but what I am asking about here is not about vCloud Connector as a product but trying to gather thoughts on the other possible use cases for stretched networks, even outside of DCE since that is just ONE way to do it. There are a few other ways as well.

      • Guess I should have stated my use case first huh? 🙂 Didn’t mean to ruffle any feathers guys – I’m on your side here I want DCE to work. We have the luxury of knowing a hurricane will hit us 3-5 days in advanced. We want to temporarily move/migrate our “critical” servers (basically everything but VDI) to a leased cloud – with little or no downtime (we are a 24/7 shop) this would obviously mean no internal ip changes – external IP’s would obviously have to be routed differently somehow. After the hurricane assuming my equipment is alive I’d like to move it back. As I understand vCloud Air won’t support this as is due to the routing between the sites will always be based at physical site? So if the physical site is down – both sites would be down? Thank’s for the input.

        • No feathers ruffled at all, just trying to get the use case :). I think you have something interesting but I would also ask, how many of those critical systems can you run in Parallel? Meaning can you deploy a peer in vCloud Air potentially load balanced or otherwise so you don’t HAVE to migrate there and back. Some of it is application dependent of course, but Disaster avoidance is what you are taking about due to your situation of knowing something is coming.

          I’d examine where you can split apps real time in both places (Using S2S VPN) and new IP’s first if that is possible anywhere and then look to the smaller set of apps that you cannot do that. I guess my argument in these stretched network scenarios is there should always be some way around the “MUST HAVE” for the same IP but I will conceded there are some you might not be able to.

          The migration over with DCE and reverse is something like the original SRM failover with manual fail back, but there is a process to reverse the DCE so I’m not sure the exact context of the last few comments about the routing. I’d have to better understand it and noodle on that a bit.

          • Apps like MS AD, Exch, SQL(?) can be setup in parallel but other business function apps the vendors aren’t as advanced to build that option in. Furthermore, we already have this kind of setup in a physical offsite location (separate subnet) where we also do dual VM replication to (Veeam Rep & SAN block level rep). The problem is the hours it takes to spin all these up, change IP’s + test/troubleshoot not to mention maintaining hardware and colo/equipment costs, lease terms, etc….

            • Understandable. I think outside of the technology of the stretched network you need to factor in the shear process time to perform the Stretch Deploy on every VM. There is the export, copy, import, re-configure processes that have to be done over the wire for each VM. DCE has it’s place for targeted workloads you move and leave in the cloud, but I cannot say it was thought of to use for a repeatable process like you are looking to do just to minimize the IP changes.

              I see how you want to simplify the current process and technically this could move your VM’s and keep their IP there is a lot of other factors to consider, least of all the copy times and the manual fail back.

              I will be sure to present your use case though as something that could combine DCE and DR2C, but of course it’s just a conversation I can have right now nothing more and no way I can even talk about timeline.

              Based on what you are trying to do I’d say DCE can solve part of it, but not all of it when you factor in the other things since it’s not a replication process, it’s an export, copy, import process as well having been designed for migrations not DR or Disaster Avoidance.

              This gives me a few ideas to cultivate though now that you have given more context. I hope it has also helped clarify some things for you to think about as well.

Leave a Reply

Your email address will not be published. Required fields are marked *

*

Scroll To Top
%d bloggers like this: