Archive for the ‘vSphere’ Category

A Boring Introduction:

It’s been a crazy week! A lot of stuff is happening right now at my work, personal life, and my career. For example, I’m building our much-awaited “Private Cloud” at work, using both the ultimate vSphere Cloud OS and the rock-solid IBM hardware that was finally delivered this week. But wait, this is not ‘the’ exciting thing that was happing this week for me, it’s most definitely the news that I’ve received last Thursday about winning the first round of the vSphere blogging contest. I will not thank John Troyer & Mike Adams for their great idea and their incredible efforts for organizing this contest, and I will not thank Deepak Narain, the man behind this blog existence who kept pushing me to lunch it a year back (more on this soon), I will, instead, thank everyone for their kind words and encouragement (including the names I’ve just mentioned), I was literally thrilled by the emails, blog posts and “tweets” that were thrown at me since the news was out. THANK YOU!

Now, enough of this boring talk about me, myself and I, and let’s get started with this new round of the blogging contest. A heads up first: I was not supposed to participate this week since I’ve been so busy as you see, but I had a 24 hours after canceling some plans that I had at the last minute. That said, what you see here is not quite final, I believe I need to work more on the diagram especially the IO plane layout in the hidden vSS, and probably add a couple of more configurations to the video to show some cool stuff like the consistent network stats of a mobile VM jumping from an ESX to another. I’ll be updating all these stuff hopefully during next week.

The Configuration Video:

The Architecture Diagram:

Another vSphere diagram! I told you, you are going to see these blueprints more than any time before. Quick notes:

• This is an A3 scale diagram in case you want to print it.
• The diagram reflects the exact configuration on the video. I’ve done this intentionally to make it easier and faster for any one new to the vDS to understand the concept and the various configuration aspects.
• As I mentioned above, due to the very short period of time that I had, I will most probably modify small parts in the diagram to achieve better results. You can come back and check the version number of the diagram to download the latest updates.

MASTER IT!

I love this part at the end of any book/chapter published by SYBEX. It gets down and dirty with all the theoretic parts covered, and guide you through a practical path to try what you’ve learned. This is what I want to do here as well. The vDS is quite confusing as a concept and configuration for the first time, and I personally didn’t get it except when I started getting my hands on it and playing around with the configurations. The challenge here is that you probably won’t have the required lab to do this, especially that you need large number of NICs to test all the configurations. If you are one of my regular blog readers, you’ve probably guessed what I’m getting to. It’s the “vSphere in a box”!

Around three month back, I published a series of posts talking about building a vSphere configurations using ESX inside itself. Instead of rewriting the whole story again, here is the links for your consideration. One last thing to note here: the entire lab you’ve seen in the video was built using Lab Manager 4.0 as you will read in the following posts.

• vSphere in A Box: A “Virtual Private Cloud” Blueprint
• vSphere In A Box: Part (2): Putting the pieces all together
• vSphere In A Box: Part (3): The Lab Manager 4.0 Automation

Special Thanks:

I’d like to thank Duncan Epping for reviewing part of the contents here. I was having some doubts about few points and due to the time constrain, I didn’t have the time to research more on them. I asked for Duncan’s help and he was very kind to do so.

Additional Recourses:

These are the best resources that I’ve found so far for the vDS:

• WitePapers: VMware vNetwork Distributed Switch: Migration and Configuration
• VMworld 2009 Sessions: TA2525, TA2105
• Blog Posts: Eric Sloof, Barry Combs, Luc Dekens, ICT-Freak

This is a response to the new vSphere Blogging contest that was announced in the middle of this month. I truly think that it’s a cool idea, and I believe that regardless of winning or losing, the excitement and fun a blogger would have during his/her participation is something awesome by itself.

The rules say that my post need to be compact and straight to the point, so I won’t be able to cover all the aspects about something huge like FT. If by any chance I failed to write such a short post, then here are some tips to avoid wasting your time:
1 – If you are one of those people who wear a tie at work, you should jump straight to the “Use Cases” section.
2 – If you are one of those people who are using the words: 10GbE, VMkernel and %RDY, then you probably don’t have time for this, but take my advice and have a look on the next two sections.

Fault Tolerance Architecture Diagram:

From the newly launched vSphere Blog on VMTN I quote this part: “[..] they do say a picture is worth a thousand words [..]“, well, I believe I’ve said that also once before on a previous post, and in fact this is the whole concept my blog is built on. So here is a blueprint for the FT with my own tweaks to save you (and me) a thousand words describing how FT works and how it’s architectured.. (BTW, this is the first of vSphere blueprints to come):

Fault Tolerance Video Demonstration:

Thank god the contest rules mentioned the possibility of republishing an old content; otherwise I would have been rerecording and video editing this from the scratch, which is a kind of nightmare. I published this video back in April this year when the vSphere was just announced by VMware (the bits were not even available for download at that time), this means it’s one of the very first videos ever published about this cool new feature.

Before you hit the play button, let me tell you why this video is deferent from many of the other ones that I’ve seen later on:
1 – In my scenario, I have three ESX hosts in a cluster rather than two as you may see in most of the FT demonstrations. What is so special about that? Well, it clearly shows the true concept of the “continues availability”, where in case of a complete ESX host failure, the FT will not just failover to another host, but will also automatically assign a third host in the cluster to protect itself in case of another host failure until the SysAdmin attend to the incident.

2 – I’m using in this video a continues file copy to the protected VM throughout the host failure process. This is to show you a “real-life” scenario where your VM is busy doing something critical (backup for example). You really don’t play movies in your mission critical VMs (I think Microsoft is the one who invented this idea in their Hyper-V live-migration demonstration, kind of weird!)

My Real-life FT use cases:

I’m taking off now my “VMware Evangelist” hat, and putting on the “VMware Customer” hat. What you’ll read here is my real-life use cases for the FT, no marketing talk, no political debates. This “is” the real deal:

1 – Blackberry Enterprise Server & RoveIT Mobile Admin:
BES is one of our most business critical applications because it’s being used by our higher management in their day-to-day communications. Initially we were depending on HA since we didn’t think that our luck would be that bad to have an ESX host failure while one of the executives sending an email.

This continued to be the case until we deployed the RoveIT Mobile Admin & vCenter Mobile Access (with BES/MDS in the backend). We basically wanted to have a 24/7 access for our SysAdmins to our entire IT environment (including VMware) while they are on the go, using their Blackberry smart-phones (given by the corp for this specific purpose). This was mainly to improve our response time for emergency situations, and of course this service makes no sense unless it can tolerate the most severe situations of hardware failures. Enabling FT on both the BES and the Mobile Admin VMs allow us, from one hand, to ensure that our executives will never complain that they can’t use their Blackberry whenever they need, and that “IT Suck”. From the other hand, we, the IT suckers..er..i mean SysAdmins & consultants, can have a piece of mind that we will always be able to get to our backend systems wherever there is a problem that requires an immediate attention.

2 – ManageEngine Application Manager:
We heavily depend on the ManageEngine Application Manager in our environment, where we get real-time emails and SMS notifications for any issues happening either in the OS layer (e.g. disk usage, service status ..etc) or the applications (e.g. Exchange high local queue, MS SQL DB issues ..etc). In order to maintain this level of real-time notifications, we had to put this application in a very high availability. Although the application comes with optional cluster capabilities, the VMware HA really was doing this trick without paying extra money. In both cases (the cluster option or the ESX HA) if an ESX host fails, we will have to wait approximately 10min for the application to be powered and operational on another host in the cluster. This is not realistic for an application that is supposed to tell us that the ESX has failed at the first place. With FT we are able to have the application up & running all the time with no interruption whatsoever, and consequently send us the notifications of any Host/OS/Application issues no matter what happens across the underlying infrastructure.

3 – Custom Application – Online payment gateway:
We have an online customer payment service consisting of a custom written application integrated with the IBM Websphere MQ and a backend Oracle DB. Everything is in high availability as you would expect, except for the custom application! I must add also that it is poorly written that it needs human intervention every time the VM needs to be rebooted in order to bring it up again. That being said, HA is not even an option in case of host failures. Unfortunately the application developer does not know how to address these issues in his application, and we are stuck with that fact since he’s working with the same backend payment gateway provider. We came up with two solutions for that:
a) The Long run: gradually migrate the online service to a new system with a new backend payment gateway. We are around 30% now on this new service.
b) The short run: put the custom application on FT enabled VM where we don’t have to suffer from any unplanned downtime associated with the VM and/or the host.

The conclusion:

FT is a “must have” not a “nice to have” feature in any environment. I don’t really understand the big debate around it from the so-called “experts” who have been flooding us on twitter or the blogosphere about reasons why it’s “not enterprise ready yet”. Most of these debates are coming really from people who have not seen enough of these enterprise environments they are talking about and the challenges we have every day with scenarios like the ones I’ve listed above. Surely enough, FT has a quite long list of limitations that you can find on any of these blog posts (or on the VMware website itself), but you should also know that VMware is working on most of these limitations in future releases. The number one limitation that you will always hear about is the (1 vCPU) restriction for the FT enabled VM, well, let me tell you two things about that to finish up my article:

1 – The vast majority of the applications running in any datacenter do not need, or even make use of SMP. My three use cases above are examples for that.
2 – VMware has published recently this blog post showing how a 1vCPU VM based on the revolutionary Intel Nehalem processor, can perform better than 2vCPUs using older generations.

P.S. This is probably one of my largest blog posts. I’m disqualified from the contest.

I’m a big believer in the saying “A picture is worth a thousand words“. If you don’t believe in that, then this blog will never be the right place for you. I think there is a fair amount of my blog readers who had actually visited me in my office, and they’ve seen how I have all sorts of diagrams covering the walls, starting from the infrastructure and solutions architectures, all the way to detailed blueprints for the deferent technologies that I implement in my environment. Beside the extreme fun I have designing these diagrams, just looking at them on daily basis help me identify the areas of improvement and future developments quite easily. Why am I telling you this small story? Well, you are going to see many of this stuff coming on my blog more than any time before folks!

Introducing the “VMware vSphere In The Enterprise” diagram v1.0

Disclaimer: This is a very, very high level “visualization” of the “virtualization” architecture using VMware vSphere. Having said that, this should never be taken for granted or looked at as the perfect design for your vSphere environment. There is no such thing as a “perfect design” at the first place. There is always a customer requirement, and best practices that we follow to achieve the “perfect solution” for the customer. I can’t stress enough on this point as I know there are many VMware-newbie visitors on my blog who might be caught in this trap.

A word of appreciation: I’d like to thank Duncan Epping for his great work of choosing the (Top 5 Planet V12n blog posts), which even for me, as a good follower of that RSS feed, I always miss quite a few great posts in there. In week 29, Duncan selected this post that had an incredible list of network ports in the VMware environment, which I have used some of them in my diagram above. It’s not the complete list of course since it’s out of my diagram scope, although I do intend to do a complete “block diagram” in the future to visualize the entire list.

Printing Considerations:
In case you haven’t noticed, this is an A2 scale diagram. I’ve initially tried to fit it into A3 while designing it but I couldn’t. The amount of information and layouts were just too much to fit in the A3 scale. The diagram still prints well on A3, but you’ll have a hard time reading some parts like the port numbers. That said, I highly recommend that you print it on an A2 plotter, which will give you the real look and feel of the diagram. In my case, although we have in our GIS department many plotters for printing even larger scales like A1 and A0, I just went to the nearest Xerox center and printed it there just to make sure how it will look like in commercial printing centers, and the printout was phenomenal.

We’ve got quite a bit of stuff to talk about in this post/diagram/video, so I’ll keep the introduction as simple as this: It’s the third part, it’s the final part, and it’s my favorite part of the (vSphere In A Box) series.

The Diagram:
This is an overall illustration of the workflow and automation process of the environment using the same single server, and an iSCSI array, that we’ve used in the previous posts. The diagram may look a bit complicated at the first glance, but I tried to keep things as simple as possible. I used the actual IP addresses, configurations, and workplaces names that I use in my environment and as you will see in the next video, to keep things clear and easier to follow.

The Video:
This is by no mean a Lab Manager tutorial, it’s just a very “quick tour” on the components and automation of the my vSphere labs. I intend to do a series of tutorials in the future on Lab Manager 4.0 itself, but for the sake of this subject I created this quick walkthrough video instead of taking more than 20 screenshots that won’t make much sense individually.

My Use Cases:
If you’ve been reading my previous few posts, you’ve probably known what are my objectives from this, and since I hate to repeat myself, I will copy & paste one of the use cases I mentioned in an earlier post, followed by two new cases I’m working on now:

1. [...] I need to build my own labs for my “virtual private cloud” project, which will typically require building multiple vESX clusters, not to mention the importance of having the templates and libraries for deploying these clusters whenever I need to test something new that would require significant changes (e.g. Nexus1000v for networking, or Reflex vTrust for security) [...]
2. I’m trying these days also to evaluate the VMware Site Recovery Manager running in two deferent and independent setups to simulate a real life scenario instead of using the traditional all-in-one-subnet setup. Since part of these applications are still in Beta, and consequently under NDA, I won’t be able to elaborate more on this use case until all the software are in the GA stage.
3. I discovered another great use case while I was working on the Lab Manager, which is training the SysAdmins in my current corp on the new vSphere platform. We are also growing rapidly with our virtual environment (soon to be: private cloud) and we’ll definitely need more SysAdmins on board. That being said, I now have an instrumental tool for provisioning independent labs for the SysAdmins to login and have their own hands-on experience with the new platform.

Other Considerations:
As you all know, the vCenter Lab Manager 4.0 was never meant to run virtual ESX hosts inside itself, therefore, there are some tweaks and considerations that you need to know about while you are implementing this in your own environment. But the beauty of VMware is that all its components are highly customizable and work in a true harmony regardless of what you want to achieve at the end.

1) As you know, the vESX hosts need to be connected to a “Promiscuous enabled” vSwitch. When you create new Network Templates in LM, and later on deploy them within your configurations, the LM by default create the new vSwitch with this feature disabled, so you will need to go an manually enable that. I’m trying to figure out a way to automate this or set it to be enabled by default, I will update the post should I manage to do that.

2) When you import your vESX templates you must uncheck the customization part as shown in the screenshot since the VM is not running a supported OS by VMware (like Windows or Linux), however, I managed to install the VMware tools inside the classic ESX 4.0 as shown in the next point.

3) Although I haven’t tested this thoroughly yet, I believe you can customize the classic ESX hosts with COS in Lab Manager by installing the VMware tools as follows:

Mount the VMware tools ISO

unzip/untar the package

Run the perl script and follow the installation instructions:

Conclusion:
By this part, I believe that we’ve completed the entire series of the (vSphere In A  Box) and shown how and why you need to be doing this setup. I hope that everyone can clearly see now the huge deference between running the ESX hosts inside VMware Workstation compared to running it inside ESX itself, as well as the great benefits of doing that in a larger scale with the automation to achieve many of the use cases mentioned across this series of posts.

At the time of submitting this post, the press release from VMware should be out. It’s July 13^th, 12 midnight NY time, and VMware is announcing a bunch of vCenter products including the much awaited Lab Manager 4.0.

Unfortunately I was not in the beta program of LM4.0 to have an early hands-on experience, but I’ve been briefed about it, and I must say that I’m quite happy with the new features of the product. I’m exceptionally interested in this product now more than any time before, for three main reasons:
1) I need to implement LM in a wide scale for our development department. Currently our developers are working independently everyone in his/her own island, using things like VMware server or workstation! No effective collaboration or automation whatsoever.

2) I need to implement LM for our infrastructure team to simulate our entire production environment. Again, I need something that can scale out easily (typically on blades), yet with flexible and fenced network configurations.

3) Lastly, I need to build my own labs for my “virtual private cloud” project, which will typically require building multiple vESX clusters, not to mention the importance of having the templates and libraries for deploying these clusters whenever I need to test something new that would require significant changes (e.g. Nexus1000v for networking, or Reflex vTrust for security)

As soon as I wake up from sleep (yes, technically I’m sleeping now, this is a scheduled post) I will download the bits and start playing with it. I will come back with more details later, but between now and then, here are some highlights on the new features of LM4.0 along with two screenshots from the product team:

- Lab Manager 4.0 now fully supports VMware vSphere 4
- Support for the VMware ESX(i) Form Factor (was not supported in previous versions).
- LM is integrated now with VMware vCenter Stage Manager.
- Host Spanning Private Networks: Host Spanning Private Networks, a new technology in Lab Manager 4, creates isolated private networks without the need for setting up VLANs. This new feature requires the Distributed Switch capability of VMware vSphere Enterprise Plus edition.
- Multiple Workspaces: VMware vCenter Lab Manager 4 introduces the concept of multiple workspaces within organizations.
- Archive to Library: Lab Manager 4 provides the ability to keep a particular configuration together with its change history for record within the library.
- Configuration History: Lab Manager 4 mow provides a new configuration history tab for all configurations. The history of a configuration displays the list of the events related to this configuration.

For the complete and detailed list of new features, you can check out this WP from VMware: http://www.vmware.com/files/pdf/VMW_09Q2_WP_vCenter_LabManager4_10_R1.pdf

Screenshot (1): VMware vCenter Lab Manager 4 streamlines application releases from development to production. The self-service interface provides on-demand access to virtualized application environments while IT remains in administrative control.

Screenshot (2): Advanced networking capabilities in Lab Manager 4 allow application teams to create realistic, production-like test environments for complex system and network configurations.