OT: VM slicing and dicing

Holmes,David A dholmes at mwdh2o.com
Wed Nov 17 00:50:57 UTC 2010


1 GiGE switches at a minimum; some vendors (e.g., arista) have low cost
48 port 1000/10000 switches. Cisco's UCS system uses 8 10 GiGE uplinks
where the servers (running a hypervisor kernel) plug into a chassis
backplane with 2 10 GiGE connectors each, that mux 10 GiGE and 4/8/16
GiG FC over the combined 80 Gig uplinks. Think about latency, not just
bandwidth. 100 Mb is 100 times slower in serialization/deserialization
of bits on/off the wire. Also, do you really want the cable management
issues associated with multiples of 48 copper cables from servers to
top-of-rack switches?  

-----Original Message-----
From: Brandon Kim [mailto:brandon.kim at brandontek.com] 
Sent: Tuesday, November 16, 2010 5:04 AM
To: mysidia at gmail.com
Cc: nanog group
Subject: RE: OT: VM slicing and dicing


Thanks for the suggestions James! One of the issues I had, (which is why
I turned to NANOG) was that I wasn't entirely
sure what keywords to search for!! So thank you for that. All of the
criteria's you brought up are valid and I will add them
to the list of things to consider.

It's awfully difficult to figure out who can do what as it's just not
possible to test all the different vendors out there unless
you have a large R&D team and a lot of time.

I think we are on the same page as far as what "We" think I need. But
just to clarify.

1) We'd like to be able to have a web portal where new or existing
clients could request servers of all types: windows, linux etc...
Configure what it is that they need and in some amount of time, the VM's
are provisioned. They receive some kind of email confirming
that their new provisioned server is available.

2) Backend - Since we haven't invested much time into the backend, we're
open to all possibilities. It doesn't need to be VMware at all.
Xen seems to be extremely popular.

3) Licensing - Of course this will be all unique to each vendor but the
more complicated the licensing, the more it's a turn off and difficult
to
keep track of. Not to "plug". But so far OnApp's pricing is very
straightforward.

4) Multi-Tenant - Absolutely needs to support this.

I don't expect anyone here to do research for me, but I assume that
being a network operator, many of us would have some input and clearly
I've received great feedback. I've been in touch with numerous vendors
that were given to me from this thread and I can't wait to demo/try
their products....


One question I do have for any that actually read through this entire
email (haha) is about the physical network switch. Is there a case for
the switch, especially
in today's high density environment to go with 1GIG switches as the
minimum? It seems pretty obvious but I'm wondering if it's really a
necessity?
Can anyone on this list argue that 10/100 will be suffice?

Thanks again!

Brandon





> Date: Mon, 15 Nov 2010 21:13:51 -0600
> Subject: Re: OT: VM slicing and dicing
> From: mysidia at gmail.com
> To: brandon.kim at brandontek.com
> CC: nanog at nanog.org
> 
> On Tue, Nov 9, 2010 at 10:17 AM, Brandon Kim
<brandon.kim at brandontek.com> wrote:
> > I'm not looking for companies that offer this service, but the
actual software engines that allow you
> > to create VM's on the fly. So a customer goes to your website and
says I want Win2008 with 8gigs of RAM and 120gigs of HDD.
> > Just like custom configuring a new PC.
> 
> How about I send you some terms to search for, using your favorite
> search engine...
> Multi-Tenant Hosting > Cloud Computing >   IaaS / HaaS
> (Infrastructure as a Service)  >  Self-Service Provisioning
> Because the question is so vague,  I think you need more research.
> If you read the documentation of portal software, you should be able
> to tell to what extent it would be "turn key"
> 
> Before looking too closely at any offering... some things to think
about are..
> How would you go about handling virtual networks  and access to them?
> Will you want one shared network  (with requisite Layer 2 security
minefield),
> or will your portal of choice  somehow decide to permission and make
> certain LANs available to certain users' VMs?
> 
> There will be security and performance considerations that some portal
> software programs allow you to answer, and some do not.     So you
> need to decide the hard requirements for security,  management
> flexibility,  UI attractiveness/ease of use,  functionality for the
> end user,  resource management,  and price :)
> 
> 
> Different portals have different options, so define requirements
first.
> A Multi-Tenant  IaaS environment  (meaning different users sharing
> pieces of metal, storage, etc) brings in some complexity.
> 
> Think about how will the resources be balanced?  E.g. Will you have a
portal
> place workloads on its own, or rely on some outside system like vmware
DRS.
> Will the portal  implement and enforce resource SLAs  for  Network
latency/loss,
> limit the number of VMs per NIC or  per datastore,  Memory, CPU
> and provide I/O response delay assurances, or will machines be left
> underutilized
> / overutilized, because the portal is bad at optimizing placement on
physical
> servers, or bad at avoiding overcommit?
> 
> 
> For an IaaS provider, underutilization eventually means you are eating
> more kW*h than necessary, and overutilization could be
> immediately detrimental.
> 
> The different major virtualization software vendors each have their
own
> Self-Service Provisioning solutions, and there are some third party
programs.
> Most are for Enterprise internal self-provisioning; Hosting providers
> might have
> special requirements like "integrated user signups and billing"
> and "no license restriction against provisioning for outside users".
> I would expect these to be more expensive,  or include monthly
per-user fees.
> 
> 
> Offhand  I recall  Virtuozzo  [perhaps the oldest?],  Enomaly /
> Enomalism, enStratus,  MS  Dynamic Datacenter Kits which are a
> framework,   VMware  vCloud Express  through the VSPP,  Citrix XCP,
> Eucalyptus,   as interesting
> by no means exhaustive.
> 
> 
> 
> --
> -JH
 		 	   		  




More information about the NANOG mailing list