Jake Robinson | Bluelock

The 4 Levels of Replication for Disaster Recovery in the Cloud

Friday, May 11, 2012 by Jake Robinson

Disaster Recovery as a Service (DRaaS or RaaS) is big on the hype meter right now, and cloud computing providers are clamoring to find solutions to fill the gap. The biggest driver in DR in the Cloud is the utility-like aspect of purchasing infrastructure, because you only pay for what you use. Disaster Recovery lends itself well to the concept of cloud computing, because you want to keep that insurance premium as low as possible. Virtualization has enabled some pretty amazing things in regards to Disaster Recovery as well. Recovery time objectives (RTO) and recovery point objectives (RPO) have dropped significantly since virtualization became mainstream, without adding cost.

On to the practical application: How on earth do I replicate my data to a public cloud provider?

Replication is essential to a low RPO. Doing full backups across a WAN link is going to result in a lot of data loss. There are methods to only replicated changed blocks, but even then you could have some pretty hefty loss.

Here are the 4 levels of replication currently out on the market:

Application

Replication at the Application level has been around for some time. Relational database servers such as Microsoft SQL are a good example. You can replicate database transactions to a remote server, and restore the database when disaster strikes.

Pros: Public Cloud-friendly, very low RTO and RPO, can be physical to virtual, or any combination of the two.

Cons: Target server must be running in the cloud. OS and application must be set up properly and maintained (patches, OS, etc).

Guest OS

Vision Solution's Double-Take product is a good example of this. The OS, application, and data can all be replicated on a block-level basis to a target machine. The OS files are "staged" on the target machine, and upon clicking the failover button, the target machine "becomes" the source machine. Pretty cool technology indeed.

Pros: Public cloud-friendly, Low RTO and RPO, physical to virtual, or any combination of the two. One click failover.

Cons: Agent overhead on source machine (CPU, Disk and Memory), license cost, target server must be running in the cloud.

VM/Hypervisor

There are two strategies at this level. The first is snapshot based replication. Veeam is a good example of snapshot-based replication. A virtual machine snapshot is taken, much like a normal VM backup is taken, and the changed blocks are replicated to the target VM.

Hypervisor-based replication is new to VMware vSphere 5. ESXi 5 now has a low level driver to capture VM disk data writes at the SCSI level. This is incredibly cool because it means I don't need to rely on snapshots. VMware SRM VR takes advantage of this, as does the ultra-cool Zerto.

As we move down the stack, this is the first replication level we have to think about VMware vCloud Director and it's meta-data. At the time of writing this blog post neither VMware's VR or Veeam replication have solutions for vCloud Director. Zerto supports vCloud Director in both private and public cloud scenarios.

The challenge for DR to public vCloud providers is direct access to the SAN. Most of the hypervisor level replication solutions have been built around the enterprise, not around a multi-tenant cloud. The public cloud is certainly NOT going to give you self-service, open access to the SAN.

Pros: Public vCloud friendly (Zerto), very low RTO and low RPO replicates entire servers, storage agnostic, target VMs powered off and not consuming resources.

Cons: NOT public vCloud friendly (VMware SRM, Veeam), Snapshot rollups can hurt performance (Veeam), virtual only, not hypervisor agnostic.

SAN/LUN

SAN-based replication is a great solution for Enterprises looking to back up all or part of their infrastructure. The source and target in this case is not a VM though. It's an entire LUN. Typically you have multiple VMs running on a single LUN, which is nice if the group of VMs require data/time consistency. VMware SRM uses SAN replication to achieve a fully orchestrated DR solution, and even physical servers with disks on the SAN can be replicated.

As stated previously, no public cloud provider is going to give you access to the SAN, which leaves you needing to buy another SAN of the same make and model, and slap it in a colocation rack.

But wait...SAN vendors also have virtual storage appliances (VSA), which DO run in the cloud. So if you run SANs such as EMC, Nexenta, or HP, there is a possibility you could at least get your data off-site. The only challenge there is you can't run the VMs in the cloud from the VSA. There would need to be a seperate script to migrate VMs from the VSA to the public vCloud provider through the vCloud API. It's not impossible, but it would certainly add some time onto the RTO.

Pros: Public cloud friendly (maybe with a VSA), Low RTO and low RPO, replicates virtual and physical machines

Cons: NOT public cloud friendly (hardware SAN-to-SAN), NOT hardware, SAN, or hypervisor agnostic.

Don't forget Failback!

Just an additional note that you should always ask about how to failback once your primary site is healthy. You don't want to be stuck in DR mode forever, and most of the above mentioned solutions require full replication of the systems back to your datacenter. Make that a top ten question when looking for a DR solution. The Disaster Recovery is not complete until you are back in your production datacenter!

Bluelock Upgrades to VMware vCloud Director 1.5

Monday, March 12, 2012 by Jake Robinson

2012 has proven to be an exciting year for Bluelock clients! In January, we introduced the cost projection feature within our Bluelock Portfolio cloud support tool. Today, Bluelock continues the tradition of cloud innovation with the upgrade to VMware vCloud Director 1.5. This upgrade delivers increased cloud agility and makes it even easier to adopt a cloud computing model leveraging existing IT investments.

Ben Miller, our Product Solution Director, reviews the new features and benefits vCloud Director 1.5 provides to Bluelock clients:

Key Features of vCloud Director 1.5

UI Enhancements – General user interface enhancements, including improved browser support and usability, make building and managing enterprise-level cloud solutions a snap.
Self-Service VPN – In addition to creating VPN tunnels for hybrid cloud communication to your Virtual Datacenter, you can now automatically configure both sides of the VPN tunnel to reduce time and labor.
Source-based Firewall Rules – vCloud firewall rules now include source IP address, port, and protocol for increased network granularity and control. Unique network designs in your Virtual Datacenter also benefit from static routing within firewall configurations.
vCloud API 1.5 – Added vCloud API functionality improves automation and consumption of cloud resources. The new Query API increases developer efficiency and support for free tools like PowerCLI 5.0.1 and vCenter Orchestrator 4.2 sweeten the deal.
Network Adapter control – You can now specify network adapter type within vCloud Director to take advantage of the universal e1000 adapter, or the more powerful VMXNET3 adapter.

vCloud Director 1.5 allows Bluelock clients to build and leverage secure hybrid cloud resources with ease. We're excited to provide these new virtual datacenter features to our clients! Learn more about vCloud Director 1.5 at Bluelock »

Bluelock Portfolio gives you the vCloud Forecast

Monday, January 23, 2012 by Jake Robinson

Portfolio, Bluelock's vCloud portal and decision support tool just learned a new skill: Cost Projection!

Bluelock already excels in providing predictable costs in the cloud, but what about those months you need to burst by adding additional resources to your capacity? Portfolio is now outfitted with helpful run rate calculations, allowing you to see early on what your costs will be at the end of the month.

By knowing your cost projection well in advance, you'll be able to dial back the resources in use, or for example, see what adding 100 new users worth of resources to your application will cost you on a monthly basis.

Also in this release, we've added some granularity to your organization costs. Previously, catalog storage was combined with the rest of the organization costs, but now catalog costs are completely transparent to you.

By breaking catalog storage costs into it's own column, you have even more visibility into how your virtual datacenters at Bluelock are being utilized.

Want to know more about Bluelock Portfolio, or virtual datacenters powered by VMware vCloud? We'd be happy to help you discover a path on your cloud journey! Just visit www.bluelock.com.

VMware vCloud Powershell (Part 1: Get-vCloud)

Thursday, November 4, 2010 by Jake Robinson

VMware vCloud Director (and vCloud Datacenter) is the answer to a lot of needs. It gives the VMware Administrator the ability to grant more control to different departments (or orgs), provide better insight into how orgs are using resources, and the ability to control a worldwide infrastructure from a central management system.

There are, of course, caveats. vCloud Director, like Lab Manager, tends to get a little fussy when we do things to infrastructure behind it's back. You must make sure to perform through the vCloud Director interface, or at least shut something down through the interface first, or you might catch some slack.

The web interface is nice, but unfortunately it doesn't like my browser of choice. I grimace every time I have to fire up Internet Explorer to get into vCloud Director. Once I am in though, I completely forget about the browser and go about my tasks. That is, until I have to navigate the foreign interface. "Where was that stinkin' network setting?!"

Of course with every new toy comes a new API. The vCloud API, in this case. I imagine an episode of Sesame Street with "The Count" counting all of the VMware APIs: "One API, ah ah ah...Two APIs, ah ah ah," but I digress.

I very rarely open the vSphere client anymore. I have been using PowerCLI since Powershell v2 arrived and haven't looked back. Now, once in a while I'll pop in there to look at a pretty graph, or to visually verify what someone else is seeing in the interface, but other than that, I do everything through PowerCLI.

PowerCLI still works for the underlying Infrastructure in a vCD environment, but You're not allowed to do anything too useful without first having to do something in vCD.

So what is a command-line loving Engineer to do?

Get-vCloud

The vCloud API is REST based which was the biggest hurdle for me. I had to write some sort of pseudo-cmdlet to talk to vCloud Director through HTTPs. Now, I am no stranger to software development, but this was my first endeavor in the world of REST and web requests in .NET, for that matter.

The requirements I had for this first Proof of Concept were:

1. It must function like powerCLI.

2. It must not rely on anything besides the built-in .NET libraries.

I wrote vCloud-Powershell as advanced functions, which means they work close if not exactly to cmdlets.

The first cmdlets I wrote were Connect-vCloud (obviously), Get-vCloudURI, and Post-vCloudURI. "Get" and "Post" are directly related to the type of HTTP request that the cmdlet performs against the vCloud API. Generally if you are making a change, you will be using the Post command, and if you are retrieving info, you will be using the Get command. Easy enough, right? I'll also add that Get-vCloudURI is much like PowerCLI's Get-View, which doesn't hold anything back. :D

These functions, when given a URI, enabled me to look at the raw response and content that the vCloud API was returning. These commands are the interface for all of my other cmdlets to go through.

The next set I wrote were Disconnect-vCloud, Get-vCloudvDC, Get-vCloudvApp, and Get-vCloudVM. These do not do any direct REST communication, but use the Get and Post commands to get the raw content from the vCloud, Prune, format, and return as a PSObject.

Example usage

First, import the vCloud functions:

. .vCloud-functions.ps1

Connect to the server:

Connect-vCloud "https://vCloudAPIserver/api/v1.0/" -username "myUser" -org "MyOrg" -password "supersecretpassword"

List vDC info:

Get-vCloudvDC

List all vApps in all vDCs:

Get-vCloudVDC | Get-vCloudvApp

List all VMs containing the name "Fred"

Get-vCloudVM | where {$_.name -match "Fred"}

Now, this is point where I tell you that these are still under development. I am putting more functionality into the currently written cmdlets, as well as adding more cmdlets.

I will also say that at some point these will be deprecated in favor of whatever VMware comes up with. Until that time, I am going to keep plugging away at creating useful powershell stuff for the vCD users and tinkerers out there.

Download the vCloud-Powershell function library
VMware vCloud API 1.0 programming guide
VMware vCloud API 1.0 Specification

If you're interested in helping out, have a bug to report, or would like to see something in "Part two" of this blog post, hit me up on Twitter or the comments below!

Custom Security in the Cloud

Sunday, May 16, 2010 by Jake Robinson

In my previous post, I mentioned some challenges made by Dan Lohrmann, CTO for the State of Michigan. Mr Lohrmann had some great insight into the challenges within within the Cloud Computing Security domain. Let's talk about 3 specific challenges:

Who owns the end to end security?
Who owns the responsibility in the event of a breach?
Who owns the logs?

Now, before I answer these, we need to look at how the answers between cloud computing providers will vary. Let's take a look at what I refer to as the "XaaS stack."

Let's say we move to the top of the stack to SaaS. This means we don't need to invest the manpower to handle our platform and infrastructure. This is great when a turnkey SaaS solution will meet all of our security requirements.

We need to realize however, the higher we move up the stack, we lose 3 valuable abilities: Visibility, Control, and Customization.

So let's get back to our questions. Answering within the context of IaaS, the answers become clear:

Who owns the end to end security?
IaaS gives you full control over the end to end security. You can utilize controls and procedures you already have in place, without having to conform to a Cloud Computing Provider's proprietary system.

Who owns the responsibility in the event of a breach?
You have complete control and responsibility of every security aspect of your cloud infrastructure.

Who owns the logs?
You have 100% log visibility. The logs are in your Cloud Infrastructure, and thus belong to you.

In summary, more specific security requirements simply mean that you will need to start lower in the stack. Cloud hosting can meet any need you throw at it, just ask Logiq3!

Security: The Thunder in the Cloud

Tuesday, March 23, 2010 by Jake Robinson

Every Information security buff knows the Triad of Information Security:

Confidentiality: No unauthorized users can access our data.

Integrity: No unauthorized users can modify our data.

Availability: My data is there when I need it.

Security in Cloud Computing should be no different.

I recently read an article by Michigan's CTO, Dan Lohrmann with some great questions around Cloud Computing Security.

Some of Mr. Lohrmann's challenges were:

Who owns the end to end security?
Who owns the responsibility in the event of a breach?
Who owns the logs?
Where does the data live (geographically)?
As my security requirements increase, does the cost become prohibitive?

Over the next series of blog posts, we'll discuss these and other Cloud Computing Security Challenges.

Have a specific security challenge? I want to hear it!