Subject: [OPSAWG] VM-MIB issue vm-mib-02: scaling and caching support

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 24 Apr 2012 12:35:34 +0200

Hi,

* vm-mib-02: scaling and caching support

  It was mentioned that large data centers are characterized by
  100.000 physical hosts running 2.000.000 virtual machines. The NASA
  is reported with 1.000.000 physical hosts and 60.000.000 virtual
  machines. Bottom line is that we need to make the MIB module
  scalable. We can assume up hundreds of VMs running on a single
  virtual machine.

** Solution #02-01

   Add ...LastChange objects to tables so that management applications
   can easily validate cached information without having to read
   through potentially larger tables. For the vmGuestTable, we might
   also provide a ...LastStateChange object so that state changes can
   be polled with reading a simple scalar.

** Solution #02-02

   Make some tables time filtered. Unclear which tables would have to
   be time filtered.

** Resolution

   TBD

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Robert Story <[email-masked]>
Date: Tue, 24 Apr 2012 10:34:00 -0400

On Tue, 24 Apr 2012 12:35:34 +0200 Juergen wrote:
JS> * vm-mib-02: scaling and caching support
JS> 
JS>   It was mentioned that large data centers are characterized by
JS>   100.000 physical hosts running 2.000.000 virtual machines. The NASA
JS>   is reported with 1.000.000 physical hosts and 60.000.000 virtual
JS>   machines. Bottom line is that we need to make the MIB module
JS>   scalable. We can assume up hundreds of VMs running on a single
JS>   virtual machine.
JS> 
JS> ** Solution #02-01
JS> 
JS>    Add ...LastChange objects to tables so that management applications
JS>    can easily validate cached information without having to read
JS>    through potentially larger tables. For the vmGuestTable, we might
JS>    also provide a ...LastStateChange object so that state changes can
JS>    be polled with reading a simple scalar.
JS> 
JS> ** Solution #02-02
JS> 
JS>    Make some tables time filtered. Unclear which tables would have to
JS>    be time filtered.

I vote for #02-01...

Robert

--
Senior Software Engineer
SPARTA, Inc., a Parsons Company

---

From: Warren Kumari <[email-masked]>
Date: Tue, 24 Apr 2012 18:26:54 -0400

On Apr 24, 2012, at 6:35 AM, Juergen Schoenwaelder wrote:

>  machines.

 Do you have a references for the NASA numbers?
"Design goals" and "wanting to build a…" do not equal what is actually built.

People say all sorts of numbers, and bigger numbers sound more impressive…

I'm sorry to sound grumpy, but many of the discussions in (for example) ARMD WG and the DC lists wildly over (or under) estimate the scale of the issue….

> Bottom line is that we need to make the MIB module
>  scalable.

Yes, fully agree...

> We can assume up hundreds of VMs running on a single
>  virtual machine.

Yup.

W

> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 25 Apr 2012 15:54:26 +0200

> I'm sorry to sound grumpy, but many of the discussions in (for example) ARMD WG and the DC lists wildly over (or under) estimate the scale of the issue….

I have no clue whether this was really built or is really being
built. The average still is in the order of 60 VMs per physical
machine. This is what matters here.
 
> > We can assume up hundreds of VMs running on a single

So lets plan with a couple of hundreds of VMs when we are talking
about what this MIB might have to "scale" to.

/js