Announcement

Collapse
No announcement yet.

Clusters & RPs=Supercomputer?

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Clusters & RPs=Supercomputer?

    Hi, it's me again, your resident virtualization noob.

    I need some quick clarification, because me is confused, as per usual.

    I've been reading VMWare White Papers non-stop all week and when I got to the section about Clusters and Resource Pools I was forced to do a double-take. Here is my understanding of how it works. The example I'm using is how we would implement it where I work. Please correct any and all misconceptions of the whole setup.

    I start with a blade chassis and put 2 dual 2GHz quad-core, 16GB blades in it. I connect the chassis up to our FC SAN, distribution network, etc. I somehow squeeze the money out of my boss to buy VI3 Infrastructure Enterprise and the necessary license for the management server. Now I create a VMWare cluster out of the two host blades above. I now have 32GHz and 32GB memory available to my guest "machines". I build a few guest "machines" and they dynamically use the resources of the two hosts as load and policies dictate. If one guest needs more resources, it gets them, assuming the other guests aren't using them. Down the road, if I need more resources for higher resource demand, I add another blade, and performance magically improves. This, to me, creates, for lack of a better term, a supercomputer.

    • This seems way too good to be true.
    • I have read conflicting reports on this scenario, specifically on this here forum.
      • The post at 102428 seems to confirm it:
        You will need to create what VMWare calls a "cluster", add both physical blades to the cluster and then you will (after additional configuration....) be able to add the both blades physical resources to the cluster and allow your virtual machines to utilize these resources.
      • The post at 92714 seems to crap all over it:
        VMWare is designed to split the resources of one physical machine into multiple virtual machines. Its not really designed to combine the resources of multiple physical machines into one 'super computer'.


    Anyone else wanna join in the crapping on this idea?

  • #2
    Re: Clusters & RPs=Supercomputer?

    You've got it mostly correct. A group of ESX hosts (hopefully similar or identical in hardware) can be made into a cluster.

    VMs run on clusters and can be moved around within the cluster as necessary by DRS (automatically by VirtualCenter) or by VMotion (manually by a human). Additional features of a cluster include but are not limited to HA for hosts and VMs, DPM (still experimental), Storage VMotion, etc.

    One important component you need for a VMware cluster (as required in many other clusters) is qualifying shared storage (SAN, iSCSI, NAS).

    Reserverations and Limits can be assigned in resources pools as well as shares. Reservations and limits kick in the moment the VM is powered on. Shares only kick in when there is resource contention on the ESX host.

    Lastly, don't think of VMware clusters as collaborative computing across the cluster in the sense that VMs can be using resources simultaneously on several different ESX hosts, but it's awfully close. At the end of the day, a VM can only be running on a single ESX host (with the exception of a split second in time during a VMotion). DRS will balance loads of VMs across hosts in the clusters.

    If you want to put it in Microsoft clustering terms, think of it as an Active/active/active/etc. cluster and the cluster resources can be moved around to the different cluster nodes as necessary to balance loads or to remediate a hardware failure or network isolation situation. One big difference in the architecture though is Microsoft clustering is a "shared nothing" concept where only one node can have access to a disk, while VMware architecture allows all ESX hosts in the cluster (and beyond) to read and write from the same VMFS volume(s) on a LUN.
    Last edited by jasonboche; 31st October 2008, 02:01.
    VCDX3 #34, VCDX4, VCDX5, VCAP4-DCA #14, VCAP4-DCD #35, VCAP5-DCD, VCPx4, vEXPERTx4, MCSEx3, MCSAx2, MCP, CCAx2, A+
    boche.net - VMware Virtualization Evangelist
    My advice has no warranties. Follow at your own risk.

    Comment


    • #3
      Re: Clusters & RPs=Supercomputer?

      You can look at it this way as well..

      It is a super computer with (almost..) never-ending resources that hosts virtual computers underneath it.

      Other than that .. I fully concur with what Jason said in the post above...
      Maish
      ----------------------------------------------------------
      Technodrone|@maishsk|Author of VMware vSphere Design
      VMware vExpert 2013-2010,VCAP5-DCA/DCD,VCP
      MSCA 2000/2003, MCSE 2000/2003
      A proud husband and father of 3 girls
      ----------------------------------------------------------
      If you find the information useful please don't forget to give reputation points sigpic.

      Have a good one!!

      Comment


      • #4
        Re: Clusters & RPs=Supercomputer?

        Lastly, don't think of VMware clusters as collaborative computing across the cluster in the sense that VMs can be using resources simultaneously on several different ESX hosts, but it's awfully close. At the end of the day, a VM can only be running on a single ESX host (with the exception of a split second in time during a VMotion). DRS will balance loads of VMs across hosts in the clusters.
        Okay, I'm with you now. So a guest machine can't utilize the hardware resources of more than one host machine, correct? In other words, in my example, I couldn't have a single guest use 30GHz and 30GB of memory, I would be limited to a maximum of 16GHz and 16GB for single guest.

        Am I on track now?

        Also, is DRS required for ESX clustering?

        Comment


        • #5
          Re: Clusters & RPs=Supercomputer?

          Yes,

          Think of it as the SAN holding the VM Guest files and the ESX hosts are the mapped pointers to the guests and allow you to access the operating system. One host per X amount of guests at a time .

          Comment


          • #6
            Re: Clusters & RPs=Supercomputer?

            Originally posted by ErEkoSuave View Post
            Okay, I'm with you now. So a guest machine can't utilize the hardware resources of more than one host machine, correct? In other words, in my example, I couldn't have a single guest use 30GHz and 30GB of memory, I would be limited to a maximum of 16GHz and 16GB for single guest.

            Am I on track now?

            Also, is DRS required for ESX clustering?
            You got it. There is no magical "interconnect" cable between all of the hosts that allow it to share their computing power to a single VM.

            Although you can assign 16GB of RAM to a VM, it would beg the question "Is this really a virtualization candidate?". Most ESX implementations I've seen are light on RAM. RAM is typically what runs out first. Putting 16GB of RAM in a VM isn't going to net you a very handsome consolidation ratio. Not to mention, 16GB of VMotion traffic is going to result in lengthy VMotion times, not that it can't be done.

            Since the vCPU limit is 4, you'd need at least 4GHz CPUs to have 16GHz of vCPU power in a VM.
            VCDX3 #34, VCDX4, VCDX5, VCAP4-DCA #14, VCAP4-DCD #35, VCAP5-DCD, VCPx4, vEXPERTx4, MCSEx3, MCSAx2, MCP, CCAx2, A+
            boche.net - VMware Virtualization Evangelist
            My advice has no warranties. Follow at your own risk.

            Comment


            • #7
              Re: Clusters & RPs=Supercomputer?

              Originally posted by jasonboche View Post
              Although you can assign 16GB of RAM to a VM, it would beg the question "Is this really a virtualization candidate?". Most ESX implementations I've seen are light on RAM. RAM is typically what runs out first. Putting 16GB of RAM in a VM isn't going to net you a very handsome consolidation ratio. Not to mention, 16GB of VMotion traffic is going to result in lengthy VMotion times, not that it can't be done.
              Right, this was all just for the sake of argument. I'm all cleared up now. Much appreciated as always.

              Comment

              Working...
              X