Posts Tagged ‘video’

postheadericon vSphere 4.0 Fault Tolerance (Architecture Diagram, Video and Use Cases)

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.

  • Share/Bookmark

postheadericon Video: vSphere4 Unleashed: 06 – Storage vMotion

A new, thin and compact video! Here we'll demo the new GUI based storage vMotion feature built-in vSphere. Yes, GUI based and built in, no more command lines and hassle. It's fast, it's easy and it's very reliable, especially when doing the thin/thick conversions while you're migrating the VMs.

Happy viewing!

  • Share/Bookmark

postheadericon Video: vSphere4 Unleashed: 04 – Fault Tolerance

And finally some real action of the new amazing vSphere's Fault Tolerance. In this video we'll do the following in order:

  • Verify that the FT logging is enabled on our network card.
  • Enable the FT on one VM.
  • Observe that the VM has two instances, the primary running on one ESX server, and the secondary running on a deferent ESX server.
  • Demonstrate the "Record & Play", or to be acurate the "vLockStep" mechanism used on the FT enabled VM.
  • Start a large file copy to the VM as a continuous operation in place throughout our fail-over process
  • Start the fail-over process by resetting the ESX blade via the Dell admin console.
  • Observe that the VM has been shifted to the secondary ESX server, and that the file copy is not interrupted.
  • Observe that the FT has automatically chosen another ESX server to protect the VM with no intervention from our side.
  • We'll check also the up-time of the VM after the fail over.
  • And finally we'll perform the migration of the FT enabled VM in case of planned maintenance.

I hope you will find this video useful, and see the great benefit of the new Fault Tolerance feature in vSphere 4.

  • Share/Bookmark

postheadericon Video: vSphere4 Unleashed: 03 – Licensing & Configuring vCenter

This is the third video in our vSphere journey. We'll do the following tasks in order:

  • Add our Licenses in vCenter Server.
  • Register our first ESX server in vCenter.
  • Configure the VMkernel on the ESX server along with enabling the vMotion & FT.
  • Configure the iSCSI software initiator and discover the shared LUNs on the SAN.
  • Create an HA/DRS enabled Cluster.
  • Add our three ESX servers to it.
  • Import a Virtual Appliance to the cluster for testing.
  • Test vMotion to ensure that the VMkernel is functioning properly.

And by that we set the stage for Fault Tolerance in the next video. I have it already recorded and I will do my best to produce it by tomorrow since it's a weekend over here.

One last thing to note: please bare with the interesting music that plays along with the video, I can't find my flash loops collection, so until I do, you may either mute the music or dance with it. It's really boring watching silent videos, besides, it's almost impossible not to fall asleep from them.




  • Share/Bookmark

postheadericon Video: vSphere4 Unleashed: 01 – Installing ESX4.0

It's fast, it's wild, and it's out of NDA.
I'm furious, I'm excited and I'm off the hook.

If you are a VMware guru, the first few episodes in this series are not meant for you. You would probably be interested when we reach the level of configuring things like the Cisco Nexsus1000v, create host-profiles, or do some FT magic. Between now and then, it's all for the newbies coming to our wonderful virtual world, and have no clue where to start and what platform they should adopt.

I've been willing to do a similar series in VI3 for quite some time, and start from the basics all the way to advanced configurations, but now that the vS4 is out, well, almost, I said why not, it's a learning journey for me before anyone else.

You have to be patient with me however, the video recording is fairly easy, but the editing and production is quite hard and time consuming to present in this format. If you have any feedback, corrections or anything that can help improve these videos, please don’t hesitate to drop a comment or an email.

What are we waiting for? Let’s do this:

  • Share/Bookmark

My name is Hany Michael and I’m a Senior Consultant at VMware. I blog about various topics ranging from the core vSphere technologies all the way to the vCloud based products. (Read more)
Disclaimer
Any views or opinions expressed on this blog are strictly my own and not the opinions and views of my employer.