Showing posts with label vCloud. Show all posts
Showing posts with label vCloud. Show all posts

Thursday, June 23, 2011

Designing Solutions on a Converged Infrastructure

I've been doing a lot of thinking (no answers today, just thoughts) about the solutions and applications running on top of converged infrastructure stacks.  Today, we have a few scenarios to consider that each require increasing levels of design complexity:
  1. A single tenant with a single application (one big VDI farm or maybe Cisco Hosted Collaboration Solution) 
  2. A single tenant with multiple applications (a VDI farm as well as an SAP instance) 
  3. Multiple tenants running the same application (vCloud Director giving out IaaS resources)
  4. Multiple tenants running multiple applications (a service provider hosting vCloud Director as well as Cisco Unified Communications)
Single Tenant with a Single Application - This one is pretty easy to digest; the entire CI (converged infrastructure) can be tweaked and modified to support a single application.  This makes the technical folks happy because they get to play with the "nerd knobs" and do some tuning.  The downside is that unless the application is a really big application, the CI may not be fully utilized or you may have multiple CI's in the data center.  You've just taken the server sprawl problem of a few years ago (single application, single server) and made it worse.


Single Tenant with Multiple Applications - In this scenario we just need to make sure our applications "play well with others".  As long as the CI can support the design, you are just adding more "blocks" at the application level.  This design usually requires a certain level of interop testing to make sure one application doesn't starve the other for resources.


Multiple Tenants Running the Same Application - The classic example here is vCloud Director.  As many are finding out, defining a work area for multiple tenants while at the same time creating a secure environment can be challenging.  When hosting multiple customers or tenants, it's all about the isolation.


Multiple Tenants Running Multiple Applications - This is where the fun begins!  You now have to balance the isolation aspects of multiple tenants while also providing a level of service across all the applications, all in a secure and stable environment.  For CI's to really succeed, this is where our design focus as architects needs to be in the future.


A Note on Multiple Tenants: As brought up by Christian Reilly on a recent episode of the Cloudcast, where do you define Multi-Tenants?  Are you talking just at the hardware layer?  Can you share a database and host multiple instances (a very common practice) or do you need separate databases servers as well?  Things to think about...

Wednesday, September 8, 2010

VMware vCloud Director Link Directory

Wow! The amount of great content around VMware's vCloud Director (vCD) has been fast and furious!  Here is a quick compilation of all the great links I have seen so far:

Some overviews of the product:
My quick write up of vCD from the keynote as well as the technical deep dive session at VMworld:
vCloud Director Security Overview
VMworld vCD Technical Overview Session

Articles from other bloggers:
Duncan's Overview
First Part in a Deep Dive Series from Duncan
vCD Cell Architecture by Hany Michael
Kendrick Coleman's article & video of the announcement
vinf.net - vApps moving to center stage
vinf.net - vApp sprawl in the cloud
Eric Sloff's Overview
Virtual Blog (Great Links to the product and documentation)
Mike Laverick's Article
Frank Denneman's Architecture Overview

Many of us have "grown up" from Windows admins to VMware admins so the concept of installing a RedHat/CentOS and Oracle environment is a bit overwhelming.  Hany to the rescue with this article:
Installing and Configuring vCD by Hany Michael

Official VMware Articles and Videos:
A compilation of all the VMware vCloud videos by Hany Michael
A compilation of all the VMware vCloud KB articles
Backing up and Restoring vCD Provisioned virtual machines

Do you others you would like to share?  Leave a comment!  Thanks!

Tuesday, September 7, 2010

VMworld - vCloud Director Technical Overview Session

I'm playing a little catch up this week.  Sorry for the delay in getting my session write up's posted.  As usual, I took notes as fast as I could but I may be missing a few things and this post may contain some slight inaccuracies here and there.

The vCloud Director Technical Overview session was probably one of my favorite sessions at VMworld.  They did a very nice job staying low level to explain everything while also keeping it interesting at the same time.  The session started off with an overview of the product.  There have been many other good articles already published on this subject so I'll it.

Network Overview

 The first topic was a networking overview.  There are two basic types of networks that can be created in vCloud Director(vCD), External (shared) networks and Internal (pools) networks.

An External network communicates with the outside world and can be shared with other resources.  This type of network is attached to a port group on a virtual switch and isolation occurs through the use of Layer 2 VLAN's similar to regular virtual machine port groups today.  External networks are creating by the cloud administrator, they can't be self provisioned.

An Internal network is where things get interesting.  An internal network isolates a vApp (group of machines) within an organization from other vApps as well as other organizations.  Internal networks are created by the users based on pre-defined values that are entered into pools by the cloud administrator.  Internal networks will be self provisioned.  There are three types of internal networks: 1. portgroup based 2. VLAN based & 3. vCD Network



  1. Portgroup Based Pool - The port groups are created ahead of time and "handed out" to vApps as needed.   The cloud administrator must create all necessary port groups ahead of time and they will attached as needed to the virtual switches
  2. VLAN Based Pool - This pool type allows for creation and isolation based on VLANs.  The cloud admin would create a number of VLANs ahead of time and each vApp would grab a VLAN from the pool upon check out.
  3. vCloud Director Based Pool - This type of network is very similar to Lab Manager's fencing.  A virtual machine (in this instance it is the new vShield Edge product) will sit in between the vApp and the outside world and perform Mac in Mac based isolation, NAT, DHCP, etc to communicate with the outside world.  This feature is limited to one VLAN per vApp at this time.  vCD based networks allow for Internal (fenced & isolated from the outside world) and External Routed (fenced but NOT isolated) networks.
Organization Overview 

Up next we had Organizations.  An organization in vCD is basically a "tenant" or a group that you would like to manage and isolate from others.  Each organization will have a unique web address created for them to use the vCD default GUI.  There are three ways to authenticate against an organization: 1. vCD Local Database (not recommended) 2. Global LDAP & 3. Per Organization LDAP.  I really like the ability of vCD to tie into an LDAP per organization; this will provide multiple tenants from different organizations an easy integration point.

Leases and Quotas

There are two types of leases and quotas in the vCD product, time based and storage based.  The concept of a lease allows users to check out vApps for a specified amount of time and then renew the lease as needed.  The user may also allow the lease to expire and the resources will return to the pool.  Resources can be configured to be suspended and held for an amount of time to make sure the lease expiration was intended.  A good example of this is a user going on vacation during the lease expiration.  The user could not renew the resources and would be very upset if they were destroyed.  This mechanism would prevent that situation.

Quotas are exactly as they sound.  A user is prevented from creating too much sprawl within an organization by checking out and consuming resources they may not need.  Only a certain amount may be checked out at a given time or only a certain amount of storage may be provisioned.

The idea of quotas brought up a number of questions around approvals and provisioning of vApps in the vCD product.  Currently, there is no approval mechanism built into the vCloud Director product but it MAY be incorporated into a future release.  What this means is that if a user has access to provision, there is nothing stopping them today except leases and quotas.

Allocation Models 

There are three types of allocation models built into vCD: 1. pay as you go (no over commit) 2. Allocation Pool (cloud admin over commits resources) & 3. Reservation Pool (organization admin over commits resources)

The use of the Allocation Pool and Reservation Pool models allow you to "thin provision your data center".  You can over commit your resources at either the Cloud or Organization levels based on your desire.  As with anything thin provisioned, use caution, understand the design, carefully monitor the environment, and generate alerts when trouble starts.

Organization Networks

As with everything else in this post, there are three types of Organization Networks.  An Organization Network is a template that is defined at the Organization level and will be associated with a vApp configuration:
  1. Internal - An internal network utilizes the vShield Edge device to both isolate and fence the vApp group of machines from the outside world.  There is no external communication in this configuration.
  2. External Routed - This network type also utilizes the vShield Edge device but allows communication to the outside world through NAT on the Edge device.
  3. External Direct Connect - The vShield Edge device isn't utilized and the vApp group is connected directly to a Port Group on a virtual switch.
Conclusion

That about does it for this post.  I could write more but this is getting long and I'm sure you're sick of reading by now.  I will have more vCloud Director posts in the very near future.  As always, thanks for coming by!

Tuesday, August 31, 2010

vCloud Director Security Model

A few moments ago VMware announced their new Cloud Computing product, vCloud Director.  Yesterday I was able to attend a session dedicated to the security model of this product.  Vishal Kumar from VMware presented the concepts and did an excellent job.  This post is a bit of a brain dump based on how fast I could write down my notes so I may have missed a few things, my apologies for that.

If you are familiar with the design concepts of VMware's Lab Manager, think of vCloud Director as Lab Manager on steroids for production environments.  If you know Lab Manager, you will feel right at home in this product.  vCloud Director is designed from the ground up with secure multi-tenancy in mind.  The environment is achieved by providing a layer of abstraction above the existing VMware Virtual Center and vSphere resources.

Before I go any further, some definitions are needed:

Organization - This is essentially a tenant or a consumer of resources.  This could be different customer, departments, or any other group of people and resources that you would like to present computing capacity


Provider Virtual Data Center (vDC) - An aggregate pool of vSphere resources that represents the entire amount of capacity.  Think of this as an entire pie

Organization vDC - A subset of resources from the Provider vDC that are assigned to a specific organization.  Think of this as a slice (or slices from the pie)

vApps - A vApp is a group of virtual machines that represent a pre-configured grouping that can be delivered to a vCloud Organization.  This is what the Organization users will see.

Cell or Pod - An underlying group of Virtual Center servers and vSphere servers. vCloud Director is designed to scale horizontally by adding more Pods over time as needed.  There is currently a limit of 25 vCenters.

Based on all of this, you will have a nested structure that looks something like this:



As you can see, vCloud Director removes the VMware resources and provides objects that can be assigned to Organizations and users in a way that allows them to "help themselves" while at the same time isolates them from each other.

There are two ways to access vCloud Director as a consumer.  One is to use the built in GUI, the other is through the vCloud API.  I haven't seen the API in depth yet but I'm told it can serve as a complete replacement to the GUI for task automation or it can also provide an alternate GUI specific to your needs.

The security model of vCloud Director is based on a Role Based Access Control (RBAC) model.  RBAC roles and permissions can be assigned at both the top level (System or Cloud level) as well as the Organization level.  vCloud Director is also able to integrate with multiple LDAP directories at once in case your organization or customers use different LDAP resources.

Network security and isolation is very complex in this product and I'm actually attending sessions later in the week to get more information in depth.  I will present this as another post later in the week but here is a quick summary.  Network resources can be isolated through the concept of "fencing".  There is also a firewall product built-in called the vShield Edge device.  This device is a virtual machine and allows vCloud Director to provide both NAT and DHCP capabilities to vApps.  Syslog server support is also included in the product.

In summary, vCloud Director is a fully multi-tenant middleware with charge back, billing models, and service tiers integrated into the product.  I'm very excited to see what the future of vCloud Director holds!