Monthly Archives: June 2011

Cloud automation: Not your father’s cpanel

Traditionally, web and email hosting management tools have been mainly two platforms: Plesk and cPanel. Both tools offered the end user complete control over their email domains, DNS records, web server and lots of other goodies. Internet service providers and web hosters offered their customers rich toolsets based either on vanilla or heavily customized cPanel and Plesk environments.

Features offered from such platforms range from DNS record self management, email account and capacity configuration, web server management and database tools. At the end of the day, both address a concept which lies at the very heart of cloud computing: Software as a service. Indeed, the end user does not care about underlying storage, web server installation and tuning and all the “dirty bits”: All that is needed is access to the portal of the control panel of their web services.

So, could such tools inflate, get smarter and take over cloud automation as well? Well… Google already uses cpanel as the control panel of Google Apps and Plesk’s parent company have dipped their feet well into virtualization, but are these enough to use them as cloud provisioning and self management platforms?

Cloud automation goes well beyond service control panels. A cloud stack starts from hardware management (computing, storage nodes, network L2/L3 switching, load balancing, data and service replication), extends into the virtualization layer (VMware, HyperV, XEN and KVM stacks), takes over server and service template management, deals with metrics collection and billing interfaces, can burst your services to public clouds and finally provides a very comprehensive end user management tools. It’s simply much bigger than a web hosting management panel.

Your cloud cockpit

To name a few vendors of cloud automation products that offer all the features described above, AppLogic, Embotics, Cloudstack, Abiquo, OnApp, all of them more or less manage the entire cloud stack, bottom to top and top to bottom. What is the catch here? cPanel and Plesk are mature and usable after many years of evolution; cloud automation has been around for much less time and cloud mechanics (virtualization layer, APIs and the SaaS ecosystem) are still not concrete.


When Windows XP counts your cash

Time for an illustrated post: From a nearby mall (I swear I didn’t do it; I was fast enough to grab these shots with my relic Nokia 6300)

OK, we know that XP has been loooong ago out of support for regular customers; will be around since 2014 for banks, presumably… So this ATM will be upgraded in two-three years from now. Let’s see the next slide, please:

That’s the splash screen of IBM Tivoli TMF and we can see it’s version 4.1.1. Currently the latest release is 4.3.1, so we’re a bit behind on this, too, aren’t we?

A few questions that pop in my head as I deactivate the phone camera and put my wallet back in my pocket:

  1. Why on earth would I trust a machine running XP, the most targeted and abused OS so far, to count my money?
  2. This ATM rebooted three times in a row and then worked just fine; most probably not due to a fault (we know that PCs fail miserably and die or reboot constantly) but due to maintenance. Why would a bank run maintenance tasks remotely in broad daylight?
  3. Tivoli is a quite decent platform for managing the box and its software; yet it’s not cheap and needs backend infrastructure, let alone services from (expensive) consultants for customization and operation. If XP was chosen as a low cost platform, bundling Tivoli and friends would make it a quite costly solution.

Virtualization and licensing, a Monty Python story: IBM & Oracle

Following up from my last post… Let’s take a look at how Oracle and IBM deal with virtual environments.

What do they have in common? Well, the weight of a CPU core. How much of a CPU is a CPU core? Oracle’s latest manifest is here. In a nutshell, a CPU core counts as much as Oracle licensing scheme dictates. For instance, in dual core Xeon, a core reasonably is “half” a CPU, so 0.5 + 0.5 (cores) = 1 processor. That’s reasonable. Yet, in a 4-core CPU, a core is not 0.25 of a processor – it still is 0.5, so a Xeon 5504 is equal to 0.5+0.5+0.5+0.5=2 processors according to Oracle. Therefore, for Oracle EE licensed per CPU on a dual socket, 6-core server you need to buy 2 X 6 X 0.5 = 6 CPU licenses. Other CPU variants have different core weights, ranging from 0.25 to 1.

What about virtual systems? Study this document. Oracle has additional definitions on what server partitioning is. Simply put, if a system has the ability to be broken into smaller computers, each with own CPU and memory resources and this configuration is done “on the iron” (hardware assisted via firmware code), that’s hard partitioning. Examples are IBM LPARs (PPC), LDOMs (SPARC), vPars & nPars (HP). Quite strangely, Oracle counts as hard partitions Sun Oracle Solaris Containers which are implemented entirely inside the Solaris OS without hardware assistance. Now, if you run Oracle inside an OS sitting on a hardware partition, then you can license it by the number of CPUs included in the partition. For example, if you have a 4-socket, 6-core Intel server running Solaris (that is 12 licenses “processors”) but prefer to run Oracle on a Solaris container that is capped at only two processing cores then you need 2 x 0.5 = 1 processor license.

And now the $30000 question: What about a virtualized fabric like vSphere, XEN, KVM and HyperV? Oops. They are not hard partitions. They are soft partitions. Oracle does not care for soft partitions; you have to license the entire physical server. This means that if you prefer to run Oracle inside a VM with 2 virtual CPUs running in an ESX server like the one described above, you have to purchase 12 licenses. And, if you allow this VM to float to another similar ESX server, you have to purchase another 12 processor licenses.

Bad: If you have big multicore boxes for your virtual hosts and need to run only a few VMs with Oracle DBMS, do not virtualize.

Good: If you run tons of small Oracle DBMSs and expect this number to grow, go virtual after you license all virtual hosts that Oracle VMs are allowed to run on. Then you do not need to care about licensing no matter how many DBMSs you use.

What about IBM? Well, being a manufacturer of highly sophisticated, out-of-this-world, next generation computer gear, IBM has chosen to implement an equally sophisticated, out-of-this-world, next generation CPU licensing scheme, here. IBM goes beyond the obsolete concept of CPU core and socket – they define the Processor Value Unit. Just click the link to see for yourselves.

What about virtualization? No worries, here is a full guide, consisting of detailed scenario analyses (in PDF format, downloadable via FTP…). I won’t go into much detail, after all, posts on this blog are meant to be read in 168 seconds, but here’s an example with VMware:

First of all, a VMware vCPU is mapped to a processing core on the underneath ESX server. Then, you must find the corresponding PVU for that core, add all the vCPU->PVU values and voila, you have the PVUs of your virtual machine. Let’s therefore assume that you have 3 VMs running IBM software with a total of 12 vCPUs PVUs. Normally, you would pay 12 licenses. But, if the ESX server underneath has only 8 CPU cores (real, physical, made of silicon), IBM is generous and will license you with the least number of PVUs vs CPU cores: Only 8 cores. The same applies for a vSphere cluster: If your VMs float across the cluster and the total number of PVUs exceed the number of your cluster physical CPU cores, you will be charged for the least quantity.

Virtualization and software licensing, a true Monty Python story: The case of Microsoft

I’ve watched lots of presentations and workshops on virtualization and I’ve done a few myself to customers. Quite naturally, all focus on how easy and magical it is to take your real servers, made of metal and plastic, and magically turn them into software bits and pieces, untouchable and pure, running in the Matrix. But few, very few dare to unfold the horrible truth about what happens to your software licenses as soon as you virtualize commercial software.

Straight to the point: We assume that you have a windows server shop and dare to go virtual. Every system runs some sort of Windows server (Standard & Enterprise) and your applications are Oracle databases, MS SQL Server, Exchange server and some IBM Websphere application servers. Windows are licensed by the server, Oracle, WebSphere & SQL server by the CPU cores or sockets and Exchange by server. Be prepared for a cosmic effect on your software licenses.

Let’s begin with Microsoft. Luckily, MS has a sort of guide here on how virtualization affects licensing – make sure you read the accompanying Word documents (if you can take it). First, you have to know that Microsoft allows Windows VMs loaded with MS applications to float from server to server, as long as they are in the same “server farm”. What is a server farm? Well. Up to two datacenters connected via network no more than 4 timezones away

Oh, kindly note that we refer only to Microsoft Volume Licensing, not OEM or FPP (Full Packaged Products). They don’t apply. You have been warned.

Now, how are Windows servers licensed under a virtual fabric (in the same “server farm”, so to speeak)? If you believe that a properly licensed Windows 2008R2 physical server that was sucked into the virtual fabric is allowed to run as a VM and hop from ESX to ESX, then, you are wrong. It’s now allowed, unless it is the sole Windows Server Standard Edition running on your ESX. If it was an enterprise edition, well, you can run up to four instances on that ESX. What is the solution??? Go ahead and buy Windows Server Datacenter Edition (licensed per CPU) and assign one license to each and every ESX/XEN/KVM host you have. Only then you can run as many Windows Server VMs you wish on your entire server farm….

What about Microsoft suites like Exchange, Sharepoint, SQL server? The situation with SQL server is that now it’s licensed per virtual processor  – that’s vCPU, meaning that if you have a two-socket, 4-core per CPU ESX/XEN/KVM server and you have two Windows/SQL server Enterprise VMs with four vCPUs assigned to each VM, you need 2 X 4 = 8 processor licenses, regardless if the physical system has two processors. The good thing is that your Windows/SQL server VM is allowed to hop from server to server. Now, for Sharepoint, Exchange etc, a plain old server license is sufficient for Microsoft to allow you to play.

I won’t calculate relevant costs, this is left as an exercise to the reader (Hint: For an initial P2V migration of 4 to 1, costs only for Windows licenses can rise 6-fold, however, a properly licensed virtual fabric can run an unlimited number of Windows VMs). I would advise you to contact your Microsoft TAM to clarify the details; we have only scratched the surface. VDI licenses and desktop OSs are another story.

Your Virtual Cisco IOS

Want to play with IOS but you don’t have a catalyst around? Try this. GNS3 is a marvelous and clever frontend to dynamips, dynagen and qemu which allow emulation/execution of IOS and JunOS code under a third operating system. That is, Cisco and Juniper virtualized on your desktop.

GNS3 topology of our virtual lab

What you will need is a decent PC with lots of memory (4GB to start with plus a fast CPU) and IOS/JunOS software images. The first is easy to do, for the second you will need access to licensed software or the actual hardware itself. My recommendation for the OS is Ubuntu with readily donwloadable and installable packages of all bits and pieces (# apt-get install gns3), however windows works just fine but with the 4GB constrains for a 32bit OS. Cool screenshots here.

How it works in a few words: MIPS and PPC based hardware (Cisco 26xx, 36XX, 37xx, 72xx) is emulated via dynamips running the IOS image unchanges. JunOS on the other hand is emulated with qemu using Olive, a stripped down version of JunOS, sort of an SDK. You design the topology via a snappy GUI (that is, GNS3), configure your virtual gear and then GNS3 fires up the emulators underneath. CPU and mem usage go skyhigh, but then, you have your own virtual private lab. Communication with the real world (the wire) is done via tap and bridge interfaces. Using a sniffer you can actually see real packets (with Cisco MAC prefixes and stuff) from your virtual devices swimming in your LAN.

What will work: All popular Cisco IOS devices with most linecards, JunOS Olive.

What will not work: Virtualizing dynamips itself is tricky. The emulator engine will work in a virtual host savagely consuming virtual CPU and memory resources, yet, the forged MAC addresses may not exit your hypervisor virtual switch. In vSphere, *sometimes* dynamips could emit packages only to other virtual machines running on the same ESX host, but this was not always the case… Also, note that performance is sluggish, so use GNS3 only as a demonstration and lab tool.