Zerto Cloud Service Provider How To – Part 1 Architecture

Zerto Cloud Service Provider’s are the group of people who leverage Zerto Virtual Replication to provide disaster recovery as a service to customers who do not wish to own a DR site. Essentially they (the service provider) have all of the needed infrastructure in place to allow customers to fail over their virtual machines into that service providers environment. So what does it take to be a Zerto cloud service provider?

This article is the first in a series that will show you just what it takes to plan, build, and operate a Zerto based DRaaS offering.

Overview

Designing infrastructure for DRaaS is pretty similar to designing infrastructure for a production multi-tenant workload. You still need compute, storage, and networking; and generally you need a lot of it. I won’t go into over-selling/over-provisioning in any of these articles.

That’s more of a decision which is left to each cloud provider to whether they should over-provision or not. Just keep in mind that if customers are trying to failover more VM’s than you can handle at the same time you might get into trouble. If you have over sold the resources and don’t have enough to allow everyone to failover you could under-delivery on SLA’s and performance. Which could result in loss of your customer to say the least.

The subject of this series of articles is my Zerto cloud service provider lab. Example screenshots from my environment are not meant to show an environment at scale, instead they are supposed to help you conceptualize  what a basic setup will take to get running.

The Foundation

The foundation of most ZCSP environments look very similar to a normal VMware environment. For example in my lab I have two VMware ESXi hosts, a shared storage array, and a network infrastructure with VLAN support.

Remember I said this wasn’t an at scale environment, instead it’s my personal colo gear which is just for testing and messing around. Obviously scale your resources to meet your expected workload.

Compute

Compute Architecture for Zerto Cloud Service ProviderMy hosts are configured in a single cluster. DRS and HA are turned on. The hosts each have dual quad-core cpus with about 100GB of ram. They are pretty old but they work pretty good. They are connected to the network and storage via multiple 1Gbps copper connections to multiple switches.

They key take away here is that everything is redundant with no single points of failure. Remember, as a DRaaS provider you are responsible for saving the day… not making a bad day worse.

Networking

Networking Architecture for Zerto Cloud Service ProviderOn the networking side there is more to explain and many different scenarios, so there will be an entire article on networking coming.

In my lab have leveraged a VMware distributed virtual switch. You can certainly use VMware NSX, standard switches, or whatever else is supported by VMware. Personally I am using a vDS because I am not using vCloud Director, more on that later in the VMware portion of this article.

Each customer you have will require at least two VLAN’s. You can have as many as they need, but two is generally the minimum. I have one test “customer” configured in my lab. Therefore I have set up two port groups:

  • “VLAN-0030” as the production network
  • “VLAN-0031” as the customer’s isolated test network.

These are the port groups that the customer VM’s will live in during live operations and test failovers. VLAN-0030 is also the VLAN that has VPN access over to the customer’s production site. So the customer can actually route traffic to this VLAN via the VPN, and is the VLAN replication traffic tranverses. I will be explaining more about replication traffic flow in the follow-up networking article.

I also have “VLAN-0100-WAN” setup. This isn’t really Zerto related, but it does allow me to configure virtual firewalls. Zerto, in and of itself, does not deploy firewalls or setup VPN tunnels. Instead we have to provide those secure tunnels before Zerto will work.

Options for setting up secure communications to your customers include (but are not limited to):

  • Hardware Firewall VPN to customer site
  • Virtual (software) Firewall to customer site
  • MPLS
  • Direct fiber
  • VMware NSX VPN

Essentially you can use anything as long as the customer can get traffic into a VLAN in your infrastructure without going through a NAT device.

For my little setup, I use pfSense. I alluded to this a while ago in this article. Basically I decided to go this route because I don’t use vCloud Director, nor VMware NSX. Both are just overkill for what I need to do. Many ZCSP’s do however use both.

Storage

Storage Architecture for Zerto Cloud Service ProviderI won’t go too deep into my storage configuration , use whatever makes sense to you. I’ve seen some ZCSP’s use dedicated datastores for each customer while others use shared datastores. I’m running multiple workloads on my datastores, but the only production workload on my gear is this blog. If I were building an environment for production replication used by paying customers I would isolate customers to their own datastores.

I do however isolate my Zerto and VMware infrastructure to a datastore that is not a replication target, they all sit on the “SAS01” datastore. The replicated workloads are landing on “NLSAS02”.

VMware Options

ZCSP’s only have one hypervisor option currently: VMware. They do have options when it comes to how customers access VMware though. One option is vCloud Director the other is just plain vCenter. Which one you choose really depends on what you want to provide to your customers.

If you want a self-service interface into VMware, vCloud Director is a pretty nice interface. If you are OK with providing access directly to vCenter, or you have a 3rd party web interface for VMware, then plain vCenter might be a better option for you. Again, it is up to you.

Plain vCenter

If you use plain vCenter, customers can be assigned resource pools, datastores, and port groups as resources. VM’s are then placed inside of the selected resource pool and attached to the selected port groups during a failover. The downside is that network configuration is more of a manual process that the provider needs to configure. Also access into vCenter is a little more “clunky” because you will have to create some sort of network access to get customers into an area where vCenter can be accessed.

Overall for smaller CSP’s or “white glove” CSP’s plain vCenter is probably the more common way to go, it keeps things simple in terms of VMware upgrades and reduces costs.

vCloud Director

If you use vCloud Director, Zerto attaches each ZORG (our term for a Zerto customer) to a vCloud Org. This makes resource pools, customer networking, and all of the other vCloud Director goodness available for consumption via Zerto.

Self service configuration tasks are also then available for:

  • Virtual networks
  • Virtual routers / Firewall / VPN settings
  • customer console access via web interface

So vCloud Director definitely gives you a lot more detailed control on networking, as well as customer self-service compared to what vCenter alone can provide.

If I had to guess I would say that vCloud Director is used by at least half of the ZCSP’s… but I haven’t asked our cloud team for the exact stats.

Scalability

The bare minimum required to get a Zerto cloud service provider environment going is pretty small. However, the infrastructure can be more complex if you want to scale to hundreds of customers and thousands of protected VM’s.

One way to plan ahead for growth and minimize management complexity is to adopt a POD architecture.

A small cluster for your management components like ZVM, vCenter, ZCM, etc, is used for the static management workload. This cluster may grow a little bit but for the most part will stay the same. It just needs to be redundant and provide enough room for the management components to grow as you scale. No customer workloads would be placed on this cluster.

Customer workloads would instead be placed on one or more DRaaS PODs. this can be represented as different clusters inside of vCenter, or different resource pools inside of vCloud Director. The main point is that each of them is self-contained. They have compute storage and top of rack switching all in place to operate. The only thing they rely on externally would be management.

It might look something like this:

Zerto Cloud Provider Architecture

An architecture like this is the best way I know to start small and grow as your customer base grows.

ZCSP Post Series

This is post 1 of many in a series. I’d love for you to follow along and provide feedback and input as I go. If you are not already following my blog I encourage you to sign up on the right under the sponsor ads. You will only get emails when new posts are published on my blog.

For a list of other articles in this series please visit the series home page here.

Need more info on how to be or get started with a ZCSP? Let me know.

[mauticform id=”6″]

Share This Post

Post Comment