Thoughts of the CCNA Exam–How to get Prepped

This aint’ your Daddy’s Oldsmobile”

The CCNA Exam is much more difficult than the VMware VCP Certification.  There are a number of reasons why this is the case.  Mainly the format of the exam goes against the way that I’ve studied for other tests.  The content is also very broad for an ‘entry level’ certification.  I compared the difficulty of content and interaction to the EMC Proven Professional Specialist exams or possibly to the VCAP-DCD.  Consider this exam as a mid-level certification (AKA Don’t overestimate its difficulty) and you will start off in a better place in your preparation.

 

To study for this exam will interrupt some part of your life.  To get the ‘speed and accuracy’ required to get through the questions and not make mistakes, was to learn the content first and then learn how the content applied in the test.   I felt like I knew the content and went to the practice exams and found I missed one of 2-3 correct choices more often than I expected.  Effectively, I was aware of the content but hadn’t studied it.  I made more than 2 runs at the exam and came out with my tail between my legs.  I was confident; but wrong.  I was discouraged.

Red Pill or Blue Pills — Pick your Path

There are two ways you can get to the CCNA certification.   You can take the ICND1 exam 640-822 ICND1 followed by the ICND2 640-816 ICND2 exam or you can combine the two in a single exam 640-802 CCNA

I selected the combined exam because it matched my training class content, but I entered the decision blind.  The CCNA 802 exam is much more intense, on fewer questions, that have to be completed in 90 minutes.   No rest for the wicked.  This is the path we will discuss in more detail; let’s see where the rabbit hole goes.

GET AWARE!

Read / Review the material and then study for 1-2  hours a day.  I had the luxury of a week long bootcamp class with an instructor, but work had a few interruptions during the IP portion of the training.  I thought I could miss that part, I already knew IP, but I was wrong.

Subnetting is very important– Relearn IP Subnetting.  I doubt that you are a wizard and can see the subnets instantly in a scenario .  This is where I underestimated the material. – See  http://subnettingquestions.com for practice exercises and see where you might fall in your understanding.  Then watch this video of an important step to learn about IP subnetting:

PITStop – Mental Subnet Calculator

http://www.cisco.com/web/learning/le31/le46/cln/clp/fastlane/Subnet_Calculator/index2.htm

It’s a little quirky but important for the exam portion below.

That aside, I found that I couldn’t take the exam right after the week training.  Nor would I suggest that you should.  The need to run the content through lab scenarios for the simulator questions is something the week long training didn’t cover well.  I needed to have good content to review beyond the classroom books I took home, which were mostly in slide-deck format.

Use Cisco’s Press CCNA Official Exam Certification Library which has the ICND1 and ICND2 books by Wendell Odom.  These can be found at Amazon.com http://www.amazon.com/Official-Certification-Library-640-802 or your local bookstore.   This book is great because the content comes in all the formats and questions you will see in the exams.  Not the exact questions, but the types of questions you need to wire your brain into studying in the next part below.

I found the following from the Cisco Learning Network to describe the content of the ICND1 vs ICND2 topics I would expect to see on the exam:

ICND1
ICND2

 

Now I found that I could pick up a specific chapter every night after my work/family time calmed down in the evening and get a decent hour of focus on the topics.  Mileage will vary, but having done this for a few weeks, in small chunks, helped when I moved over to the Study portion below.  I didn’t have to argue if  a trick question being presented. I knew that it was, an moved past to the correct answers.

NOW STUDY!

Practice extensively on Simulators and Practice Tests for 3-4 days just before taking the exam.  If you have a Cisco device on contract, you can build some part of the environment with GNS3 and follow the guide from http://freeccnaworkbook.com with the binaries of the device.

http://packetlife.net/lab/ and Cisco Packet Tracer (Cisco Academy Members) are two other tools that are good for use as practice for the lab questions. The difficulty here is building an environment that you can practice on without already knowing what is in the scenario. A new question will present a lab you have never seen and you will have to work through the unknown to find the right answers.

A huge find from the ICND1/ICND2 Cisco Press books was the Boson NetSim . It is found on the last CD of the ICND2 book.  It allows you to run a full simulation of the Composite Exam with a time limit and the opportunity to watch your progress and get answers on each question.  You can also just run without any hints and see how you do.

This sim made all the difference to me. It made the content I learned in the first part apply to the test scores.  I hadn’t put myself in the right frame of mind to take the exam and succeed until I tried this simulator.  TRY THIS SIM BEFORE ALL

 

EXAM TIME

Before the test begins you are provided with a sheet of paper – do a “brain dump” of any items like the PIT Stop calculator learned above. You can do this while the exam environment runs a demo in the beginning of your test time.  Don’t worry it doesn’t count as part of your exam time.  Cisco has a quick survey and this tutorial at the beginning of the test but not counted towards your time.

Example of Exam Environment

Exam Interface Tutorial

Other things to remember:

  • Every exam center will generate the questions in a random order from a different pool
  • Simulators may be at the beginning or the end.
  • Once you answer a question you cannot go back to it.
  • Do not spend a lot of time (5+ mins) on a single question take the hit and move on. ‘Tis better to guess and miss than miss all the questions. The simulators may be the last question when you are short on time.
  • Some CLI “help commands” can be displayed on some of the simulator questions.
  • Hitting tab twice will display the available commands.
  • Hover over the host and switches on any Simulator Topology Map – some equipment can be accessed  for testing of traffic patterns
  • Sometimes a question might trigger your memory – write down any of these “triggers” on the paper provided for future questions

Success

Remember it is a marathon more than a sprint.  Cisco has done a good job of creating a challenging certification exam.  They are good at it.  Do not get discouraged.  I think the first time pass is the exception to the rule on this exam.  You will probably need two times at this one.  Get prepared and do not underestimate the questions.  Use this path and these tools first, and I’m sure you will come out of the experience with better knowledge of the content than breezing through it on the first try.  I know I did.

 

 

 

Anyone wanting to talk about VLSM subnetting and the perils that are caused by a distance vector routing protocols in the present IPV4 versus the upcoming IPV6 orientation of Dual-Stack firewalls and Teredo Tunnels over Frame-Relay;  I will be on twitter on any given #Beerfriday

ESXTOP Replay and VM-Support output– AKA ‘Pain Train’

@vTrooper from the field here:

In an effort to help one of my customers troubleshoot some performance issues within his ESX farm I asked for a run of the vm-support file with some special parameters.  I expected I could pull a few minutes of esxtop data and replay it locally.  Why didn’t I just do the same thing with the esxtop parameters?  Well I wanted to get some of the specifics of the farm at the same time. I thought I could capture both the configuration and the performance data in a simple request.  Seems reasonable right?

Well the delivery of the vm-support file  yielded a legacy of discovery. Read on if you wish to avoid the ‘Pain Train’

Roadblock 1 - OMG the files are HUGE!

The command was simple and can be reviewed from the ‘man’ page of the ESX system.

vm-support -s -i 10 -d 600

This runs the vm-support output and then captures statistics of 10 second intervals for 10 minutes.  It will make the support file take longer to run but you get that sample of data you need.  Just SCP that zip file output and you are good to go to the next step.

Copying 305MB…….          WTF?!!   It was supposed to be 60 samples.  How did that happen?  How did I get a 3ooMB file compressed??  Checking the ‘man’ page again I forgot to exclude the core dumps and other log files. I should have used:

vm-support -n -s -i 10 -d 600

to exclude the core dumps in the vm-support payload. On 4 ESX systems each output was 300MB,65MB,154MB,91MB.  I’m still not sure why, but lets dive into the output and see what is there. I unzip the payload to my local machine and see what I pulled into the boat…. – OUT OF SPACE–   Wait what?  The 300MB monster expanded to 1.3 GB on disk . Well Poo.  I’ll go get coffee while I move some files around.  Ok there. Got the thing expanded. Now I should be able to find my ESXTOP output.  I browse through the file structure of the payload and find that the ESXTOP output is captured in VSI output files.  Only way to see inside the files is to run ESXTOP.  My windows workstation isn’t ESX so I have to try it another way.  Sheesh.

Roadblock 2 –  Wait!  Where the Hell Am I?!

Fine.  I’ll scp the files over to my ESX 4.0 system locally running in my Vmware Workstation 7.1 instance. This should be a piece of cake…. – OUT OF SPACE–   Really?  Again? Oh yeah; I created a small instance locally so I could jump into the CLI/Console and run a few commands if necessary.  I don’t really run ongoing VM’s here. No horsepower on the laptop, and no space apparently.  I had all my space in the VMFS volume not in the /root directory of the ESX console.  Guess I’ll just load the payload on the VMFS area.  Better make the VMFS datastore larger while I’m at it, ok there.  Whoo Hoo! Fully expanded vm-support file.  NOW I’m Ready!  Let’s run the replay command of ESXTOP:

‘   esxtop –R /volumes/vmfs/<vmsupportextractdir>

‘   –INCORRECT VERSION OF ESXTOP— ‘

Are you kidding me?  The kernel version of ESXTOP can’t translate to different versions of the damn output? Unreal. I better go check what format the customer has on their ESX system, I have the configs in the vm-support output after all.  Let’s see /etc/vmware-release should tell me….

‘  VMware ESX 4.0 (Kandinsky)

Well is that the original version of ESX4 ,Update 1 , or Update 2?  Where was I, with my local version?  Let’s check another place: /proc/version

Linux version 2.6.18-164.ESX (mts@pa-lin-bld530.eng.vmware.com) (gcc version 4.1.2) #1 Thu Mar 11 07:09:06 PST 2010 [ESX Service Console build 240614] ‘

Wait.  That doesn’t match what is on the console screen when I first login to the ESX node.

Let’s try another place: /etc/vmware/ft-vmk-version:

‘ product-version = 4.0.0  ft-version = 208167 ‘

OK.  I’m on Update 1 (208167) and the customer is on Update 2 (261974).   More coffee while I get that downloaded….. –OUT OF SPACE—   ? See Roadblock 1

Removed the big vm-support file now that I moved it to the ESX host and got the correct version updated.  Let’s try the replay again.

‘   esxtop –R /volumes/vmfs/<vmsupportextractdir>

SUCCESS!!  Now I’m cooking with Gas.   I’m able to get through the samples of the ESXTOP replay and see all the elements.

Roadblock 3 – The Phat Phinger!

Now I want to show the Customer the output and findings. All I should have to do is run the replay mode command and port that to batch mode and generate the .csv format of the values I care about. Right?

‘  esxtop –R << vmsupportextractdir>> | esxtop -b  >  foo.csv

After running this command I watched the foo.csv file grow and grow… And GROW .  It didn’t stop.  I thought something was up and checked the file.  I had the esxtop of my local ESX instance plugging data into the foo.csv file.  Not my customers vm-support supplied data. Yup I messed up.

The correct command is this:

‘  esxtop –R << vmsupportextractdir>> -b  >  foo.csv

And if you want to parse out more specifics you can run the ESXTOP command in interactive mode set the parameters you care about and save the .esxtop4rc file and run as such.

‘  esxtop –R << vmsupportextractdir>> -b  -c .esxtop4rc  >  foo.csv

It seemed like a marathon but I still had to finish the job.  I SCP’d the file off the ESX host back to my workstation for the last part…The EPIC Line chart:

Roadblock 4 – DDoS of Data <<ChoKe!>>

Now I had my Customers 4 ESX hosts each with a .csv format of the captured data. All I needed to do now is get those .csv samples into esxplot to get some view of the data.

If you haven’t seen the esxplot tool take a look at the vmware labs site and pull it down Here:

You won’t regret the ease of use and the ablility to jump through the data quickly.  Excel limits the column counts and esxplot accommodates the large datasets better than Excel to my knowledge.

How large are the datasets do you say?  Well.  Massive. Let me explain why:

Each of the 4 ESX hosts were told to sample 60 intervals of the default esxtop values.  I didn’t tell the customer to limit those on capture so they all went into the VSI cache files as the vm-support file was created.  Each .csv file included 17,000 metrics over those 60 samples.

Yup. 4 Million metrics would be parsed into my graph if I didn’t pull the unneccessary stuff out.  17,000+ * 60 * 4 = 4,080,000+   Not bad for 10 minutes of work.

Let’s cut to the chase.  I re-ran my extract from the vm-support files and minimized the data to the HBA’s I was reviewing by limiting the output in the .esxtop4rc file.  With those .csv’s reduced to under 5000 metrics I was much improved in parsing through the data to find the Active HBA’s and get my much desired graph of vmhba data.

Hard Knocks? – You Bet.  Now You Know This:

What else can I say folks.   Don’t try this at home. It probably took me a week to get through all these roadblocks for a simple set of data that was probably easier from the Virtual Center reporting tool.  The idea of having someone run the vm-support file and you tackling it by hand is a severe waste of your time.

Tell them what they’ve learned Bob:

  • You can run the vm-support command and capture performance output
  • You can run the esxtop –Replay command and parse that data in batch mode out to a .csv
  • You can limit that batch sample to a lesser amount with additional parameters in the batch mode command with -c
  • You can make pretty graphs of the 4+ Kazillion metrics that may even spit out some interesting data

And Finally:

I’m going to put this train back on some tracks and go find another  adventure in the field.

@vTrooper out

Two Garbage Cans are Better Than One – .NET

The vTrooper Report

I was asked a question about a specific use case where a second vCPU should be added to a VM in a Virtualized environment. Generally its an easy answer;

If the server can execute multiple threads and really uses the second vCPU for that other tread

then it’s probably OK to add the second vCPU to the VM

Now adding a vCPU in a server to make it SMP oriented is an elementary task in VMware, but has a few impacts:

  • It will change your metrics for reporting
  • It changes the HA slot size for your failover needs
  • It will modify your consolidation ratio per core and indirectly per socket affecting your Capacity Planning plans
  • It will make you redeploy your Ubuntu or Linux server that you forgot to compile with an SMP kernel. (Not to be taken lightly or your server won’t boot)

I was exploring the use case and impacts when a bit of information popped up:

Garbage collection on .NET applications will require a second vCPU to perform in ‘Server Mode’ versus ‘Workstation Mode’

Explaination from MSDN: http://msdn.microsoft.com/en-us/library/bb680014.aspx

Managed code applications that use the server API receive significant benefits from using the server-optimized garbage collector (GC) instead of the default workstation GC.

Workstation is the default GC mode and the only one available on single-processor computers. Workstation GC is hosted in console and Windows Forms applications. It performs full (generation 2) collections concurrently with the running program, thereby minimizing latency. This mode is useful for client applications, where perceived performance is usually more important than raw throughput.

The server GC is available only on multiprocessor computers. It creates a separate managed heap and thread for each processor and performs collections in parallel. During collection, all managed threads are paused (threads running native code are paused only when the native call returns). In this way, the server GC mode maximizes throughput (the number of requests per second) and improves performance as the number of processors increases. Performance especially shines on computers with four or more processors.

This caught me by surprise and makes me think;  for every disk of VM’s around the world which are out of whack (mis-aligned) , there are an equal number of .NET app servers that have been virtualized with P2V tools across the globe that are starved for the correct garbage collection mechanism….

OH, THE HUMANITY !!

All would Perish

Hindenburg and .NET

Whoa!  I gotta settle down!

Ok

Now you are going to ask where the special override switch or Regedit value would be used to fix it.  The answer is even more easy.    There isn’t one.  .NET sees one vCPU or more and decides for the app.  You cannot override it.  You can add 4 vCPU’s to improve its performance but not turn it off.

This probably explains a few of the things that have already happened or will happen in your app development world:

  • The .NET development on dual core workstations is working fine and when you move the application to a single core VM the development process hits a hiccup in performance while GC runs.
  • VM admins who have been adverse to the second vCPU that was idle now have a reason to deploy a second vCPU but won’t like it.
  • It drives a reason to migrate to vSphere sooner than later due to the relaxed CPU scheduler that was introduced in 4.0
  • Additional vCPU’s will drive more ‘Eggs’ into your baskets – Do Not Panic

As all the worlds workloads increase its only inevitable that the number of vCPU’s would increase as well.  The push for 64-bit systems with over 4GB of RAM are driving up the size of the VM in most farms as seen by the new maxims in the VMware vSphere release.  Just remember that you can look for vCPU contention and NUMA pressure in the ESXTOP values.

EMC World 2010 – Simplicity and Efficiency

There are plenty of announcements to talk about from the second half of Day 1 and Day 2 of EMCWorld.  Keynotes from Pat Gelsinger, Brian Gallagher,and Rich Napolitano all brought the “Why, What, and How” the datacenter will change over the next year.  With the quick reference to VPLEX by Joe Tucci in the morning Keynote of DAY 1, the official announcement and demo of the technology by Pat Gelsinger in the afternoon keynote explained the VPLEX technology and its purpose in todays datacenters.

Continue reading

EMC World 2010 – Journey to the Private Cloud

– vTrooper Report — from EMC World

My self-imposed gag order has been lifted since my arrival to EMC.

I’m ready to share some of the great news from EMC World 2010.  Stay tuned for all the announcements in detail but for now:

It’s my first time at EMC World.  I’m an infrastructure guy at heart and have been to Cisco World and VM World a few times, but not the big storage show.  That’s good because EMC is not just a storage company.  My “Firehose” treatment over the past few weeks made certain of that fact. So I’ll warm up to EMC World with a little mood and follow it with content.  All good fun starts with a party:

Continue reading

Capacity Conundrum Part Deux

 

– The vTrooper Report –

 

This is a continuation of the Capacity Conundrum, if you missed the first part start here.

$ per Compute VM

So let’s cut to the chase.  In the case of the compute tiles of our Quad we have a price per vCPU and $ per GB of RAM to settle. Keeping our example 2U server in play we could expect to spend approximately $15,000 for a 2U fully loaded with 4GB DIMMs.   Well unfortunately a small part of that 15K  is consumed in I/O cards and maintenance which needs to be pulled out to get the compute number.  For our argument we will use $10K for the compute system without the I/O cards and maint. costs;  This is the CAPEX we will offset in our $/per values.

vCOMPUTE – FIREPOWAH!

We know how a CPU works right? Move process into memory , execute CPU cycles, churn, churn more, back to the I/O guys, rinse and repeat.  Basically, this is where the hardware container happens in our data centers.   I say container because it’s easy to show it as a box; It’s hard to define what it will always be in physical form.  1U, 2U, 4U, half blade, Full Blade, appliance , PC ; you name it, it is probably in some one’s ‘datacenter’.  The lowest common denominator I have been able to settle on for a common form factor is Cores per Ram.  Grouping per socket fits because you are measuring the type of memory that is close to the CPU socket.  The NUMA architectures of AMD and Intel with memory controllers on-board and transports to the memory DIMMs without access through the I/O  controllers (eg. Northbridge) help define the grouping.

TECHNOTE:  Every core has associated memory banks it will use and every container(physical server) has a series of sockets that it controls.   A hypervisor has a limit to how well it can control the associated memory space to the nearest vCPU.   Generally the hypervisor will always schedule available vCPU’s from the same socket and swap the corresponding memory for those processes to the memory banks of the corresponding socket.  It does this is for efficiencies of the x86 architectures.  It can move the vm to another socket and readdress the memory but it has a ‘cost’ associated with such a move.  Path of least resistance is to stay in the same socket.

If you create a 4 vCPU VM and run it on a 1 core  processor it gets bogged down.   If you have the same VM on a two socket Quad Core (8 Cores)  the four cores utilized by the VM are likely to be on socket 1 or socket 2 .  The cost of splitting the vCPU between the two physical sockets by the scheduler is greater than running the vCPU in the same socket.    AMD delivered this earlier than Intel and sustained higher levels of virtualization consolidation “Per Host” than similar class systems of Intel could provide through the Northbridge.   Core i7 is a new game for Intel and the results of Nehalem show the improvements.

For more indepth information here is a good read:  CPU Scheduler in VMware ESX

We have a host of $10K  CapX charge that has two sockets at a 4/45GB Socket Ratio with approx $5k spend in each socket.  Looking at our Hardware invoice the CPU Cores are about 25% of the cost of a socket so we can assume that our per socket cost is broken down into 25% Core and 75% Memory.   So our Socket Ratio yields a $1250 cost for 4 cores and $3750 for 45GB of memory:

Per Core CapX = $312.50;  Per GB RAM CapX = $83.33

That gives us a bare metal cost without a hypervisor charge on top, but we need a hypervisor to get a VM running.  Adding in the ESX cost for a per socket license of ESX Enterprise Plus (worst case) you can add $3500 each socket.

ESX Lic. Cost per socket CapX = $3500

Raw burn rate of the host would be $8500 per socket if we never loaded a VM on the Host.  Well, we did it for a reason, so let’s get our money back. If we target the standard allocation for this host (4/45GB socket ratio) we get our target VM count of 16 per socket(1 vCPU/2.8 GB RAM).  Also, keep in mind that we broke the socket cost down by 25%  to CPU and 75% to Memory so we will keep that  same  split here.  If we don’t do the split, then any VM that is deployed to the socket will bear the same cost regardless of its size.

ESX Lic. Cost per VM= $218.75   ( 3500 / 16 )

-Or-

Split by the 25/75 % we did previously for the cost of the CPU and Memory and you get a little different calculation.

3500 * .25 = 875 / 16  = $55 AND     3500 *.75 = 2625 / 45  = $58

per vCPU=$55

per vMEM=$58

Adding it up with our target ratios in tow we get the burn rate of the $ per Compute on a VM basis.

($312/4  = 4:1 ratio) + (83*2.8) + {(55*1) + (58 * 2.8) } = $530

Or Summarized: (vCPU = $78)+(vMEM = $233)+(Hyper$=219)=(vCOMPUTE = $530)

Assuming 8760 Hours (1 year) this VM would cost $.06/hr in vCOMPUTE.

Lets apply that to some other VM systems and see if it sticks.  If we plan for the following VM deployment on our socket:

vmGrid

The costs would spit out as such:

vCompute

Or slice it up into a per hour number:

perhour

So based on this analysis some of my VM’s probably only cost $.05 per hour for vCompute.  Interesting. What is more interesting is the fact that the memory cost associated with a VM scales more accurately to the consumption.  You can have as much memory you like for your new 4 and 8 GB aspirations; (eg. memory leaks) you just need to pay for it accordingly.

Too bad that only pays for the top part of my total cost model.  That said, the benefit here is that this model can span across hypervisors and any market hypervisor can be split up to show the cost of a VM consumed on a Xen , KVM, VirtualIron, Parallels’, or Hyper-V infrastructure.

I will be working on a few powershell scripts and excel calculators that one can use to make this model more repeatable. At the very least, it is a model that I will use to consider CapacityIQ and third party products like the offering from VKernel; and the output they measure.  Especially if they consume additional costs on a per socket basis.  Which I can now calculate as Overhead.

Alas there is more to consider, stay tuned for Part III – “the I/O that binds”

Capacity Conundrum Part 1

 

–The vTrooper Report –

 

In an effort to gel up an internal billing and allocation model (GaaS – Goughing as a Service) I’ve been struggling with the concept of cost per vm.  I was asking a simple question in the twittersphere about that idea and it turned into a discussion and well…got out of hand.  I apologize for that, as this is a better format to explain. (Special thanks to @asweemer for a dumping ground)

If I had a Nickel for each VM…

At VMWorld 2009 there was a presentation in the keynote that showed the price of a vm hosted with Terramark that was $.05 per hour.  I thought  wow.   A nickel per hour.  If I had a nickel per vm/hour; How much would I have available to spend on coffee?

Then I thought wait.  I have VM’s. How much do they really cost me per hour?  Well the answer is … it depends.  Old servers with high power consumption and low density versus a new system with Intel 5500’s and packed in blades have different burn rates visible to different systems(power, cooling, depreciation).  I haven’t found a great model to break those units down to my satisfaction yet.  I need another way.

As a general practice I create in my mind some maxims that I follow in the creation of a VM.

  1. S  – 1vCPU, 1GB Ram, 1GB Net, 10GB Disk
  2. M -2vCPU, 2GB Ram, 1GB Net, 20GB Disk
  3. L – 4vCPU, 4GB Ram, 2GB Net, 40GB Disk

Seems simple enough, but it doesn’ t really generate a cost model on a consistant basis.   Hardware continues to change and each VM that consumes resources does it at different rates and times of the day.   A VM that isn’t doing anything isn’t really ‘consuming’ anything, right?  I thought I would try break it down further by creating a 4 quadrant block with two macro categories:  Compute (CPU and Memory) and I/O (Network and Disk)

cmnd

Each resource area could increase\decrease for a reason without changing the size of the original maxim it was created under.  This allows for small variations of size without having a customer yell that their bill when up by $2 this month.

The Measureable Unit

Use a unit of measure to identify the four quadrants:   vCPU : vMEM : vNET : vDISK  or C:M:N:D  .   Then overlay the VM creation to count up the units.  This way the growth of a ‘VM’ during its lifecycle can be adequately allocated back into the proper IT metric.  Using the VM creation maxims up above this may be:

  1. S  – 1:1:1:1
  2. M -2:2:1:2
  3. L – 4:4:2:4

This isn’t perfect but it at least allows for the average cpu cost to be allocated seperately from a memory, network, and disk cost.  Afterall, you don’t get to upgrade all four parts of the quadrant in the same fiscal year usually.  This also allows a way to trend an average of your cost rate per unit over a period of months and years to see which cost areas are improving.  It is an interesting metric for the business and IT.  Win-Win in my book.  Even if no-one internally ever has to pay the values back (Showback).  It also helps police which VM is consuming too much of a specific value which would skew the numbers if you simply took the cost of the esx hosts and divide by the number of VM’s.

Apples , Oranges, Lemons, and Grapes = Frutti Results

So you have a unit of measure and a type of system to match the measurement up towards over a period of time.  Here’s where the fruit cart and the horse get hooked up.

This is all very complex, why can’t I just buy the same server I have purchased for the last 5 years?

Sorry Kids. They don’t build’em like they used to.  But in todays market, the UCS system from Cisco has a new buzz to the original players of IBM, HP, and Dell.   How do you sort any of that out among the offerings, and how do you select the right platform for your new ESX System?     By the Socket !   Every system of the x86 family has them from both the Intel and AMD families.  And now that you have to pay for your hypervisor and additional tools (Capacity IQ, AppSpeed,  Nexus1000v) per socket  it matters more.  I need to squeeze the value out of those sockets.

Still staying in the upper half of the Quad;  lets measure cores and RAM as a ratio assuming dual rank 4GB Dimms and measure them to some of the standard 2 socket servers.

Standard Intel x5450

2 Socket – 4 Core – 16 Dimms (8 per socket) produces 4 cores/ 32 GB Ram

Standard Intel Nehalem  x5500

2 Socket – 4 Core – 18 Dimms (9 per socket)  produces 4 cores/ 45 GB Ram

Cisco UCS extention  on x5500

2 Socket – 4 Core – 48 Dimms (24 per socket)   produces 4 cores/ 96 GB ram

What this shows is that for every license of ESX consumed in the environment there are different amounts of memory available for a VM to use.  The approach by the UCS system allows for a much higher allowance of memory to a VM at the same licensing cost.   Sure you could buy 4 way servers and claim that the 256 GB of RAM gives the VM more allowance but in reality the vm will have ratios of contention to the vCPU and Memory within each of the 4 sockets. You can change the size of the container by moving to a 4 way,  but it won’t change the value of the ratio  for that container in regards to the cores and memory.

CPU Contention

The idea of CPU contention is becoming more visible to most administrators of virtualized environments because the desire to pack the vm’s onto a host is so strong.  If I can get 10 VM’s on a host for $5000 then getting 25 VM’s on the same host is lowering my cost per vm.  It could also be cheating your customers of the performance they paid. Especially if you have multiple vCPU’s assigned to those 25 VM’s.    This is where the ratio of VM per host becomes obsolete and vCPU/core  makes more sense.

Using the example containers above you can generate an expected number of VM’s per socket.  There is no reason to do a 1:1 ratio of cores to VM because the point of virtualization is to run more with less.  I think a good ratio to start with is 4:1 for a production VM and 16:1 for a VDI implementation:

Standard Intel x5450  -  (4 /32 GB SocketRatio)   yields 16  VM’s with a 1 vCPU/ 2GB ram configuration per socket

Standard Intel Nehalem  x5500  -  (4 /45GB SocketRatio) yields 16  VM’s with a 1 vCPU/ 2.8GB ram configuration per socket

Cisco UCS  -   (4 /96GB SocketRatio) yields 16  VM’s with a 1 vCPU/ 6GB ram configuration per socket

You can always adjust your actual deployment if these ratios don’t match up for your environment.   The expected deployment number helps determine how large the pizza slices are for the team.  Not how many slices each of them consume.  In these configurations you can see where the density of the RAM per socket (SocketRatio) of the UCS allows for much larger VM configurations before overcommitment. A nice fit for the new 64bit installations. These expected numbers of VM per socket help determine what the burn rate of a C:M:N:D value is for the CapX  spend you made.

BurnRate

To fully understand how much a VM costs, one has to look at what was spent in the CapX of the host and agree on the measuring stick to measure the C:M:N:D value of the created VM.  If a series of hosts are in service from different families and are at different parts of lifecycle there may have to be some averaging.  The SocketRatio of Cores/RAM is a consistent way to measure systems from different form factors and families and levelset the expected allocation of VM’s.  The expected allocation of VM’s for a host helps determine what density ratio is desired for vCPU:vMEM.

This is the end of Part 1 –  In Part Deux I will take a deeper dive into the Compute and I/O areas and assign a more detail cost per VM model.