blog.virtualtacit.com

It has been of great interest to me how the landscape of distributed computing has developed over the last few years. Even though the idea was developed in the late 70’s, it most recently has begun to take lead in the race toward “liberation” as Diane Greene stated at a recent tech conference in Boston, blogged about here. No doubt many tech giants have taken notice of this trend and have been working toward a workable, profitable and stable web computing solution, ie. Amazon’s S3/EC2 , Yahoo!’s Hadoop, IBM Blue Cloud and Google’s AppEngine to name a few. Considering that these models are built on the backs of virtual infrastructure (typically XEN-based) I thought it may be beneficial to explain the differences between the three.

• Cloud Computing is really the way applications are built, delivered, run and maintained in a virtual environment. Surrounding that is the automation of that application, the ability to expand and shrink computational needs and self-recoverability.CC offers a way to extend IT services without having to invest in new infrastructure. Sound familiar? Its no wonder virtualization is the catalyst for this technology. The backend services (storage, networking, security, etc) are abstracted from the end user. The resources are controlled by the provider, the user cares little about where their application lives only about services provided.

• Grid Computing? Well the best known example of this model is SETI (Search for Extra Terrestrial Intelligence). That’s right whether we want to admit to it or not most of us probably at one time or another contributed a sliver of our unused processors toward this cause. The obvious draws toward this trend are the ability to harness large amounts of computing power at relatively low cost. This type of computing power in most situations would be unobtainable due to power, cooling and financial constraints. The use of geographically dispersed commodity nodes to aid in the same computational cause will always have its place and notably will most likely evolve into a pseudo cloud model.

• Utility Computing is ultimately built on some form of computing cloud. It encompasses a metered approach or time sharing of sorts based on actual capacity or resources used. This is generally where your EC2’s and 3Tera’s operate. This business model in essence was built as any public utility, the provider (ie.public utility) is paid for use of its infrastructure. In return it maintains that infrastructure to provide you, the customer, with an acceptable level of service. Again this model goes hand and hand with virtualization as data centers in general are notoriously underutilized and over provisioned.

As these “utility clouds” expand in popularity, the traditional start-up client base will move to enterprise companies looking to disperse their workloads outside of their traditional data center. This will in turn lead toward increased utilization and a greener approach toward computing in general. It will be very interesting to see how this plays out in the forth coming years.

It was always time consuming for me to decipher Cisco documentation that related to port group bandwidth and module overscription rates for their Gen-2 FC Modules. So what follows is a brief interpretation of how those ratios are determined and why they matter. Currently the modules available are 12 port, 24 port, 48 port and the 4 port 10G cards. The 12 port card offers a full 4G line rate per port, the 24 and 48 port cards share their bandwidth and operate according to the following subscription ratio’s:

So what this means is that if all ports were active on a 24 port module they would operate at the full line rate of 2Gbps. Broken down this equates to four 6 port port groups, each group capable of 12.8 Gbps. The 48 port modules consist of four 12 port port groups, each group again capable of 12.8 Gbps. That being said the full line rate of each port on a 48 port module if all ports were active would be 1Gbps. The maximum bandwidth per port per module, minus the 10G mod, is 4Gbps. So why does all this matter? Well its extremely important for host placement on those fiber switches. Ideally if you had a pleothra of modules in your director, you could seperate your traffic as follows:

12-port 1/2/4 FC Module-high perfomance servers, front end array ports, ISL’s, and tape drives/libraries

24-port 1/2/4 FC Module-server connections, front end array ports

48-port 1/2/4 FC Module-tier storage solutions (low,medium and high), server connections

4-port 10Gbps FC Module-ISL consolidation, high performance metro connections

These recommendations are highly dependent on your environment as there is nothing preventing you from putting a front end array port on a 48 port card. But being aware of what other devices exist on that module can save you trouble in the long run, not to mention it will ease you down the path of scalability. In addition, you should not only be cognizant of per module placement but also per port group placement. Remember you only have 12.8Gbps of bandwidth per port group so loading up all you front end ports, high performance servers, etc. into one port group is a recipe for a poor design.

For all of you individuals out there that were circumventing solutions around running the VI client from a 64-Bit OS, VMware finally decided to add support for this in Update 1. In short you will need to install .NET 2.0 (x64) prior to the installation of the client. Here is the link for your reference.

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1004093

So now that I have my first Lab Manager implementation under my belt, I must say it is a pretty slick product. The last time I touched it was during the beta release and there is no doubt it has come a long way. But with that being said there are a couple of areas that need improving and wouldn’t you know it, VMware has managed to overcome those shortcomings in the 3.0 release due out I believe in late July. Here are a few features that I am privy too…

VC Awareness
Lab Manager 3 will be VC Aware. This means that Lab Manager will manage VC resource pools instead of ESX hosts directly. Lab Manager VMs will be organized in the VC interface by configuration for ease of use, reporting, and alerting.

DRS, VMotion, HA aware
The resource pools managed by Lab Manager can have DRS, HA, and VMotion turned on, and Lab Manager VMs will be able to take advantage of these capabilities

Auto-install of Agent
VC will push the Lab Manager Agent onto the ESX hosts managed by Lab Manager, eliminating the need for manual installs.

Easy import of VMs from VC
VMs in the VirtualCenter inventory can be browsed and copies made to bring them under Lab Manager management.

Enterprise Features
Several features in Lab Manager 3 are intended to make Lab Manager usable in organizations with multiple and distinct project groups.

Organizations
Organizations are a method of creating separate groups of users in Lab Manager with either separate or shared resources (compute, storage) and entities (configurations, templates, media).

Customizable Roles and Rights
Lab Manager 3 introduces the ability to define custom user roles with varying rights. In this way, an organization can define users with different capabilities and levels of access to entities and resources.

Expanded LDAP Support
Lab Manager 3 will support the use of OpenLDAP in addition to Active Directory for user authentication. LDAP groups are mapped to organizations.

Improved Sharing Model
Lab Manager 3 introduces a more granular sharing model. In addition to keeping entities private or shared amongst organizations, users can also share with one or more users, one or more groups, or across organizations.

Org-aware Notifications and Alerts
Notifications and Alerts are updated to be scoped by the organization. Messages have been improved for consistency and usability. (not in beta)

Platform Improvements

“Gold Master” Library Configurations
The Lab Manager 3 library will allow configurations that serve as “gold master” or reference configurations to be sorted separately from other library configurations that can be temporary in nature.

Forced Deployment Modes
Some organizations require users to deploy configurations fenced (for instance if they have a domain controller in them that they don’t want “out” on the network) or unfenced (for instance if they need its machines to connect to a central domain controller). Lab Manager 3 will allow this to be defined.

Storage Utility
Lab Manager 3 adds storage tools necessary for managing the distribution of VM files across an installation with multiple datastores. This can be used to both manage free space and optimize storage load balancing. (not in beta)

Use Case Expansion

Multiple NICs, Nets, Subnets
Lab Manager 3 will allow for the definition of multiple physical and virtual networks, each with their own subnet and VLAN characteristics, then the definition of VMs with multiple vNICs to attach to those networks. This greatly increases the number of network topologies that can be handled in a Lab Manager Configuration. (VLANs not in beta)

Configuration Combining, Splitting, and Selective Checkout
Configurations can be combined or split in Lab Manager 3; and large configurations can be selectively checked out of the Library. This greatly increases the flexibility of the library for combinatorial use cases.

Directed Deployment
When a Lab Manager 3 configuration is deployed, each of its machines can be manually directed by the user to deploy onto a separate resource pool under Lab Manager control. This will allow the tailoring of VMs to physical resources for performance testing and other purposes. (not in beta)

Non-Diff-Disk VMs
Lab Manager VMs in the library can be indicated to be fully-cloned if the user wishes. In this way, the user is given the flexibility to use linked clones or full clones at his discretion.

BEA LiquidVM Guests
This feature allows Lab Manager to be used as a team-scalable development environment for BEA’s LiquidVM platform. (not in beta)

Infrastructure Improvements

AJAX interface
Lab Manager 3 sports a new AJAX interface that significantly increases interactivity and eliminates unnecessary screen refreshes.

Upgrade from 2.4, 2.5, 3.0 beta
Lab Manager 3’s installer will upgrade previous GA versions of Lab Manager to Lab Manager 3. A resource pool and organization will be automatically created from the source installation’s resources and the administrator will be dropped into a single organization installation matching his previous Lab Manager instance but with added Lab Manager 3 functionality. (not in beta)

Documentation
The Lab Manager documentation set will be updated to reflect the new Lab Manager 3 product features, and will be augmented with a Best Practices guide that will include the results of performance and scalability studies.

SOAP API
The Lab Manager SOAP API will be updated to reflect the new functionality in Lab Manager 3. (not in beta)

So you’re thinking about automating your test and development environment huh? Well you are definitely moving in the right direction with VMware’s Lab Manager 2.5. Now in all honesty I really have nothing to compare it to, I haven’t demo’d VMlogix’s LabManager offering, supposedly a like product. But I will say I have gone through the pains of managing a dynamic lab environment, so I know what value these solutions add. VMware is definitely making the most of its akimbi systems acquistion and from my eyes looks to be the leader in this space. But take my comments with a grain of salt as they are 100% one-sided, anyways let’s get started.

Below are the four key components of a basic LM environment. This article will briefly describe each but future articles will talk more in depth about sizing implementations, and best practices.

1. Physical or virtual (preferable) Windows 2003 system. This will run the LM server software and control the configuration tear up and tear down, template creation, and general control of the managed server.

2. Managed ESX Server. At the heart of LM is ESX 3.X. A LM agent is manually installed on each LM managed host, communications between the two parties operate over tcp port 5212.

3. Storage Server. This really is a separate logical entity but physically is whatever managed host is connected to shared storage. If you have one managed server it is the storage server as well from what I understand.

4. Media Server. This is typically share based via NFS or CIFS/SMB and essentially houses all pertinent media, ie. ISO’s, flp’s, etc. For simplicity sake, my design placed this service on the LM server on a secondary drive.