Posts Tagged ‘diagrams’

If we are gonna perform Inception then we need imagination. An elegant solution for keeping track of reality – The “Inception” Movie.

Before I introduce this new diagram to you, I would like to make a bold statement: No matter how complex this diagram will look to you from the first glance, I can tell you that you’ve been practicing all its core technical concepts for a quite long time. You will just need a bit of imagination and I guarantee to you that everything will make a perfect sense faster than you can imagine. Read on…

Let’s go back to the very first VMware product that has changed the way we think in our IT industry – Workstation! When you create a new virtual machine in Workstation, you get four options for networking:

• Bridged connection – a pass-through network to the outside world.
• NAT’ed connection – a network translated connection.
• Host-only connection – a private network isolated from the outside world.
• None – no network at all.

Guess what? that’s the core technical concepts I’ve been talking about. Here are the new names that we will be using from now on when we refer to vCD (in the same order):

• Direct connection
• Routed connection.
• Isolated (private)
• None (no network)

Now, have you seen the “Inception” movie? (if you haven’t, you missed one of the greatest movies in this decade!) Do you remember the layer of dreams in that movie? Well, that is somehow what we have here. Imagine your virtual machines running in different layers of dreams networks, and depending on which layer you are looking at, it might be direct, routed or isolated. Let’s see that from a closer look:

• First Layer: the real world – this is the actual physical network which we are in most cases not concerned about.
• Second Layer: the vNetwork Standard Switch, Distributed Switch or even Cisco Nexus 1000V.
• Third Layer: the External network – this is sort of your gateway to the outer world.
• Forth Layer: the Organization network – this is sort of the gatekeeper for your VMs. It will always show you what is your logical boundaries.
• Fifth and last layer: the vApp Network – this is the ultimate end your VM can reach (think LIMBO!)

Now that you have these basic concepts in mind, let’s see what we have in this diagram:

• This is an A2 size diagram. I’ve really tried my best to keep it in the A3 scale but it’s just not possible with all this amount of information in one place.
• The diagram covers nearly all the networking options of the vCD but from a “Private Cloud” perspective. In the world of Public Clouds this might be a bit different to layout (which i will do in the future) but the core concepts remains exactly the same.
• The diagram comes with some text describing the various components and elements. I’m introducing this for the first time here to help you understand what you are looking at instantly without taking your focus away from the diagram.
• You will see a different PDF layers in the diagram, you can hide/show them as you need. Example: when you are having a closer look into a specific area in the diag, you might find the descriptions useful to have while they might be a bit distracting if you are zooming out to have a holistic view of the diagram.
• You will see the actual screens of the vCenter networking – the vSS, vDS and the different port groups. Not just that, you will actually see how the VMs in your cloud ultimately look like in vCenter. Add to that all the other components like the External/Organization networks as well as the vShield Edge devices. Of course i’m taking just examples of everything in most cases to avoid the complexity.
• I’ve included as well the screens of the vCloud Director to show you how the Network Pools looks like along with the other panels of the External and Organization networks.
• The IP addresses can play a very important role towards your understanding on how all these vApps communicate together. For example, when you see two vApps sharing the same OrgNetwork and still have the exact same IP addressing, it automatically means that they are routed through an edge device.
• I included three connectivity examples for the outside world of your private cloud. A production cloud, an Internet cloud and an MPLS cloud. Please note that these are just examples not the only options you can have. This is something that can be very specific from a customer use case to another.
• Last but not least, the vApp networks are laid out like that to fit the best view in the diagram. This is not an attempt to tell you how you should run your vApps but rather show you the different options you have. Again, this is something that is very specific to the customer use cases and requirements.

In the future networking posts on vCD i will start going deeper in the discussion and reference the examples shown in this diagram all the way through. I encourage you to print out this diagram and keep it somewhere near your home/office desk and have a glance through it from time to time. There is nothing better than visualizing something that is as complex rich as the vCD networking. I highly recommend also checking out Duncan Epping’s article on vCD networking, this is a must read for all the vCD newbies.

One more thing. I’d like to give some credit to my colleague at VMware, Massimo Re Ferre’, for showing me the way to understand this great networking topic. Massimo along with Eddie Dinel, Mike D and Vishal Kumar, presented together one of the most interesting presentations I’ve attended for vCD when it was still in Beta. I believe parts of this great presentation have been divided into more than one session in VMworld 2010, so I urge you to go and have a look into the recordings when the sessions are available online.

UPDATE: (14-09-2010): The networking part of the presentation I’ve mentioned above has been re-written by the master at this link. Another MUST-READ.

Yes, finally! It’s been like what? Five months?! Well, the delay in publishing this part was mainly because of the delay in certifying the new IBM HX5 blades on vSphere. It’s a quite long process that you can read about it here, but the good news is that the hardware is finally on VMware’s HCL, and that I can comfortably blog about the subject now without causing any confusions to the readers.

Before we dig deep into the new designs, I’d like to mention some minor changes in the diagram.

Updated Diagram

I’ve included the old configurations along with the new ones in one updated PDF. The main difference now is that I’m using normal pages for showing each configuration. In the old version I used the layers to show and hide the configurations as you select them. I thought now that using separate pages for different diagrams would ease the process of browsing through the configurations, and to tell you the truth, to reduce also the high complexity of designing the diagram. It’s a crazy process to keep track of all these layers in Visio especially when we are talking about more than 7,000 shapes floating on the same design area!

Now let’s get down to business.

Configuration (5) – HX5:

This is the Big Blue’s latest two-node blade technology. I emphasized on the “two-node” here because it’s the only configuration certified to run with vSphere as of the time of writing these lines. Please note that you can use up to 4 nodes with the HX5 but this won’t be supported by VMware. When we talk about two nodes here we mean the following:

• Having the base blade (CPU + Mem + HDD) (+Plus+) the MAX5 expansion try to scale up more memory for the blade.
• Having the base blade (again CPU + Mem + HDD) (+Plus+) another similar expansion board to scale all the blade components, that’s 4 x CPUs + 2 x Memory modules + 2 x IO expansion cards.

As you will see in the diagram, I chose the second option to talk about.

Now, what do we have here? it’s simply the redundancy at its best! We can place our networks here freely with full redundancy as you see in the layout of the vNICs. For example, if we have a failure in the CFFh expansion card on any of the two nodes, we will still be able to flow the traffic without any issues on the other CFFh card. Same thing holds true for the on-board ports, if for any reason one of these posts fail, the traffic will flow on the other node’s board.

Apart from that, I’m introducing here the DMZ networks for the first time. Most of the enterprises prefer to separate the DMZ networks/servers on different chassis for security reasons. While this is a valid decision, we can have with this blade configuration a workaround for organizations that are less paranoid about the DMZ security, yet with good isolation. Let’s see how this is done in details:

• For the networks, we have two dedicated blade switches that will be uplinking *only* to the corp DMZ switches (in this case Bay 9 & 10). This means we will have no traffic following from either the internal networks or the VMkernel networks. Same thing for the blade ports, you will always have the NICs 4, 5, 10 and 11 dedicated for the DMZ networks and running in full performance and redundancy.
• For the SAN, we can also ensure that we have a dedicated HBAs as well as an isolation. The uplinks to the SAN switches will be segmented across the two bays 3 and 4, and connected directly/physically to the appropriate SAN fabrics.

Configuration (6) – Virtual Fabric:

Before we start with this configuration, I would like to state that I am not quite sure whether these Emulex Virtual Fabric Adapters (VFA) are supported by VMware or not. While I can’t see them clearly on the HCL with the name VFA, I can see some Emulex documents saying that they are. Of course the reference here should be always the VMware HCL itlself, not anything else, but I will double check on that and update this post later. With that said, please refer to this configuration carefully and make sure to confirm this point before engaging with any vSphere design around it.

Now let’s dig deep into this cool technology. IBM simply has this Virtual Fabric concept of slicing your CFFh expansion card into 8 different ports. This doesn’t only mean that you have the flexibility to adjust the speed, but also the protocol. For example, you can choose to use either Ethernet, Fibrechannel, FCoE or even iSCSI with hardware initiators.

In our case here I used only Ethernet as the protocol for these ports, and then sliced them into 8 different vNICs with various link speeds. Perhaps a screenshot from the diagram would make things more clear.

As you see, we set the bandwidth for the SC to 1GB since we normally don’t require high BW for management, while we set 3GB and 5GB link speed for the Fault Tolerance and VM Networks respectively. By default these ports are set to 2.5GB ( 4 x 2.5GB = 10GbE into two ports), but you have the full flexibility to change that as you see.

Configuration (7) – CNA:

A very simple design to wrap up this series with. It’s the traditional CNA (oh yeah, it’s a common and traditional technology now!). As you see in the diagram, we have here a CFFh expansion card, and it has got four ports:

• Ethernet ports: that’s 2 x 10GbE Ethernet ports for the networking traffic. We will treat them here normally as we treat any 10GbE port. We will slice them via the vNetwork traffic shaping in vSphere to achieve the bandwidth that we want.
• FibreChannel ports: that’s 2 x HBA ports for SAN traffic. Instead of going into the traditional Bay 3 & 4 as we’ve see across the whole series and configurations, this time the traffic is multiplexed and pushed to the Nexus 4000 blade switches.

Did I just say Nexus 4000?! yep, that’s a specially developed Nexus switches by Cisco to be used only/currently with the IBM BladeCenter H/HT. But here is the catch, you will still need to have the Nexus 5000 switches to segregate the FCoE traffic coming from the Nexus 4000 and then forward the network and FC traffic to the existing LAN and SAN respectively. Of course we should have redundancy here at all layers. In the BCH we have two Nexus 4000 sitting in bays 7 and 9, while we have two Nexus 5000 switches in the back end.

Now what?

Well, as much as I worked really hard in this series to come up with different kind of configurations and design scenarios, as much as I enjoyed it! Now I need to move on to another vendor, but without all these mad options. I initially was planning to jump straight to the HP realm, however, i found myself involved in two different Cisco UCS vSphere designs lately, so it would make much sense to me if I blogged about this platform now. Don’t take my word for it though, I might surprise with a Dell or Fujitsu series, who knows?!

• This is the first diagram of more ESX blueprints to come. Previously I was focused more onto the vSphere architectures as a whole, but there will be more granular diagrams on ESX itself as a hypervisor very soon.
• The colors play a major role in this diagram. I thought I should stick with the original colors used in the vCenter Server Recourse monitoring box (on the top right of the diagram) instead of reinventing the wheel. As an example, if you want to scan through the swapping memory reclamation technique, all what you need is to focus your sight on the red colors. Whether it’s in the VMs, hypervisor, esxtop or vCenter, the red color will always relate to the swapping activity, and so forth.
• In the MMU virtualization I did not put much detail (as I was hoping to) because of the diagram limited space, but I’m planning to make more detailed diagrams about this topic in the future, along with other technologies like NUMA and EPT/RVI for example.
• In the memory reclamation techniques, you might have noticed that the “idle memory tax” is not there. I intend to illustrate that in a deferent topic related to shares and resource management.
• The Memory compression and swapping to SSD are future features coming soon in the vSphere generation. This information was mentioned in the VMworld 2009 session TA2627 so it’s public.
• The most interesting part for me while creating this diagram was the ESXTOP. I have a wild idea of creating a crazy huge diagram (poster-like) and add the deferent screens and options for ESXTOP along with real-world numbers and descriptions to show the beauty of this incredible tool. I might also use Duncan’s esxtop section as a reference for the thresholds, I urge you to go there and share your experience!
• For some reason, the PDF converter kept converting the ESXTOP text box into an image and then down-sample it, which ended up not looking as sharp and clean as in the original Visio diagram. I’m trying to figure out why the Acrobat is giving me this grief, so I will probably update the PDF later on (check the version numbers).
• I’ve received a number of emails asking for some descriptions accompanying my diagrams (like the admission control calculations in the HA diagram), and I believe you are right about that, especially for the newbies entering the fascinating world of VMware. I’ll revisit these diagrams in the future with detailed descriptions and write-ups, so stay tuned.

I hope you’ll like this diagram and see the real beauty of the ESX memory management (well a glimpse of it at least). If you have any corrections or suggestions please drop a comment or email and let me know your thoughts.

Recourses:
- Book: Operating System Concepts (Part Three – Memory Management)
- Book: Modern Operating Systems 3rd Edition (Chapter 3 – Memory Management)
- Documentation: vSphere Resource Management Guide
- WP: Understanding Memory Resource Management in VMwareо ESX™ Server
- WP: Memory Resource Management in VMware ESX Server – by Carl A. Waldspurger
- VMworld2009 Session: TA2963 “esxtop for advanced users”
- VMworld2009 Session: TA2627 “Understanding “Host” and “Guest” Memory Usage and Related Memory Management Concepts”
- Blog: Arnim van Lieshout (Part-1 , Part-2, Part-3)

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.