For virtual solutions, the idea of having multiple customers leveraging the same infrastructure is nothing new. The whole theory of operations is that instances of applications and entire OS’s can run simultaneously on one piece of physical hardware. However, with the advent of Public Cloud systems, the challenge is to let that happen when not all the users of a particular system get along or like to share.

The issue isn’t that multiple users leverage the same systems, but rather that multiple users who cannot or do not want to share data and resources are acting on the same systems at the same time. Think of Amazon Web Services: customers who do not want their data shared with each other (like Netflix and Amazon’s own streaming product line) can and do co-exist on the same data systems. AWS has to keep the platform shared, but the data and operations separated.

In addition to data segregation, administration must also remain separate. Customers A and B need to be able to monitor and maintain their instances, but cannot see or touch each others instances of apps and servers.

Finally, billing is dependent on the amount of users and/or data/storage/transmission bandwidth that each organization uses. So the service provider needs to be able to bill each customer independently, even though they’re all using the same infrastructure.

And so, multi-tenancy, according to Wikipedia:

refers to a principle in software architecture where a single instance of the software runs on a server, serving multiple client organizations (tenants).

Simply stated, multi-tenancy is what lets unique infrastructure components (like VM hosts and apps) be shared safely and effectively by multiple users and groups.

Photo Credit: Steve-h

• Share this:

Earlier this week, HP announced it is getting into the game on cloud. In and of itself, the announcement isn’t a shock, as many hardware makers are re-tooling for the reality of hosted applications and servers in cloud configurations. However, I was impressed by the depth of what they’ve been working on at HP.

In addition to a public cloud offering – which will be the first piece of the tech they beta in May – HP is ramping up a few other services to compliment it:

CloudMap systems which create ready-to-go images and applications to encourage roll-out into cloud resources. This isn’t new, as Amazon has had pre-built images from nearly the get-go, but very nice to see.

Virtual Private Clouds for enterprises that want flexibility but don’t need or want the general public to access their cloud plant. Again, not new, but a good sign that HP realizes that just saying they have a cloud solution isn’t enough for most organizations to get on board.

Services offerings wrapped around all of this to allow an enterprise to just define what they want to put in the cloud, and have HP figure out how to get it done.

Brining both the platform and the services in-house is a welcome sign that big manufacturers have begun to truly embrace distributed resources. Just saying “We do cloud” is nice, but doesn’t help anyone get there. HP’s decision to offer hand-holding to firms that don’t have the internal resources to build out these things will make adoption in larger firms easier.

Of course, that leads to bigger contracts for HP, but everything has a trade-off.

Photo Credit: Luigi Rosa

• Share this:

There’s quite a few virtualization platforms out there. From VMware to Microsoft to XEN to KVM and beyond, the choices abound.

Do you want to stick to one vendor for all virtual technologies, or work with many of them at once? That’s a valid question, and one more companies are looking at every day.

Standardizing on one virtual platform has benefits. The company in question makes management tools that control their software, and having one platform means having to learn fewer tools. Also, since most vendors make entire suites of tools, you can probably find Server, Desktop and Application virtualization platforms from one vendor alone.

Spreading out also has benefits. Some platforms only make one type of virtual platform (such as hyper-visor for only server virtualization). Sticking with just one vendor would limit the tools available to you.

Cost always comes into play, as the more advanced platforms can often come with higher price-tags. So using only one vendor for all your needs might inflate your budgets dramatically – and in some cases unnecessarily as other vendors make tools that are less expensive and work great. Don’t forget training costs either, as multiple tools from multiple vendors means training your staff on multiple systems.

Which will you do? Most of the organizations I talk to started out on a single-vendor methodology. As folks like Quest Software roll out multi-vendor management solutions, they are beginning to explore having multiple vendors work in the same datacenter. This gives them flexibility to choose the best vendor for each tool they need, without losing control of the environment or having to learn a large number of tools just to keep things running.

Cross-Platform management is not 100% yet, but it is getting there, so we could easily see a day in the near future where the decision is a moot point. Until then, what’s your company doing? Sound off in the discussion section!

Photo Credit: lumaxart

• Share this:

I’m on a train.

No, really, I’m typing up this blog post as I travel from NYC to Rochester, NY.

That’s got me thinking about how we’re a mobile bunch – us IT folks – traveling anywhere we need to be to do the job we need to do.

This has got me thinking about how to manage Virtual Infrastructure while on the road, no small task, to be sure.

First, you need to have a connection to the Internet in general. On the ground, that’s not so hard, but does require some forethought. You’ll either need to know someplace where you can connect to WiFi, or else bring a mobile modem or WiFi hotspot with you where you’re going. You could tether your phone, but keep in mind that you may not be able to make or receive calls if you do that, so an independent data device may not be a bad idea if you travel a lot.

In the air, that’s a different story. Most major air carriers have WiFi on only a few – if any – flights. Check ahead to see if you’ll have access to connectivity as you fly the rarely-friendly skies.

Then, you’ll need a VPN. When doing remote admin for virtual systems, you will be talking to components like vCenter and Virtual Machine Manager, which means you’ll literally be transmitting the keys to your kingdom across the networks you’re on. Sending that data “in the clear” is a very bad idea.

Once safely linked to a network, you need the right configuration at your datacenter. For VMware, you can use the vCenter Web clients to do most things, but you may want a Remote Desktop Server to allow you to access the full versions of various tools while on the road. This might be Microsoft’s own RDP server, or could be a third-party remote-access tool to your own desktop – depending on the security policies of your organization.

For Cloud platforms, this becomes a bit easier. As these systems are typically designed to be administered via Web interfaces anyway, you won’t need the RDP server, but you still need the connectivity and security. Make sure your vendor supports linking to their tools over HTTPS/SSL and use it – always.

Once you have all these tools and tech lined up, you can administer your Virtual Infrastructure from just about anywhere you can get a mobile signal. Just remember to go slowly and ensure that you save your progress at every opportunity. You never know when the cell network will give up the ghost, leaving you with no connection and a lot of work half-done.

Photo Credit: nrkbeta

• Share this:

One of the first things you do when configuring a new Virtual Machine is to define the storage resources that it will be using. Mostly, this is because even the most basic of VM’s will need someplace to put the Operating System files, and that place is a virtual disk or pass-through to a physical disk.

Alright, you have the requirements for your disks, and you want to use virtual storage (VMDK for VMware, VHD for Hyper-V, etc.) to house all files and data for this VM. Now you get faced with the decision of what kind of VM disk you want to use. There are two common choices, thin or thick provisioning for the data and systems volumes.

So what do those choices mean?

Thick provisioning (sometimes called static disk or fixed-size disk) is the idea of allocating all the space that the disk can take up immediately. So if you tell the system to create three 50GB thick-provisioned disks, you will see 3 VMDK or VHD files, each using 50GB of space get created. You can typically re-size the disks later, but this is a manual process.

Thin (or dynamic, or expanding) disks allocate space only when necessary, and automatically. They typically start out with a few hundred MB of space, but are capable of growing up to whatever limit you set on them as required.

So why would you choose one over the other?

Thick provisioned disks allow you to explicitly allocate storage to machines where you know that you’ll need X amount of space most of the time. In earlier versions of hypervisor tools, they also offered better performance because the hypervisor didn’t need to dynamically track each volume and expand it over time. However, most of the performance issues are no longer present, so the choice to use fixed-size volumes is more about simply knowing for certain that a particular amount of space is necessary.

But, what if you’re not sure how fast a group of five servers will grow, but you do know that only two of them will grow at all – just not which two. You don’t want to allocate all the space for all the volumes when you know that three servers won’t ever need that much space. It’s a waste of (potentially expensive) disk space. That’s where thin provisioning comes in.

Think of a thin-provisioned disk as a water ballon. It starts off as a very deflated balloon with just a tiny bit of air in it to get it started. Then, as water (data) is poured into the ballon, it swells up to the maximum size over time. You don’t have to do anything to get the balloon to grow except add more water – in much the same way as adding data to a thin disk makes its size increase.

If you have just the one water balloon, the only problem you have is trying to put in more water than it can hold at maximum. Stay below that much water, and you can add and remove water whenever you want. Thin disks are limited by the maximum amount of space you declare they can use, but can grow and shrink within those limits as necessary.

Now, back to our five server scenario. Let’s say you had five balloons in a rigid box that could only allow any two of them to grow to full size. So long as only two get that level of water, you’re fine. If a third tries to grow too big, all the balloons pop and leave you with a major mess.

In thin provisioned disks, the rigid box is the total amount of physical disk you have to work with. So as long as not all five VM’s try to use up their full allocated space, you’re fine. Have too many disks use up too much space, and boom.

For our scenario, I know that only two will ever grow to their full capacity, I’m just not sure which two it’ll be. So I put all five VM’s in the same balloon box and watch them, making sure only two fill up.

That is – of course – a gross oversimplification of how thing provisioned disk works, but you get the general idea. Each disk uses up only the space they need, and can grow within the limits of the physical disk allocated to the group of VM’s. If too many disks grow too quickly, you have to jump in and move some VM’s to other storage systems to avoid running out of room to allocate space.

The good news is that most modern hypervisors have ways to move either the storage or the entire VM with minimal downtime in these scenarios. Some can even do it automatically based on the overall load of the storage attached to each VM host.

Thin provisioning can help you avoid wasting disk, and can be a great part of an overall virtualization strategy for most organizations. Just keep in mind that you have to watch thin provisioned systems a bit more carefully than their thick provisioned brothers and sisters, and you’ll master the use of disk space in no time flat.

Photo Credit: rogerss1

• Share this:

Virtualization of resources bring some interesting issues to the table. Not the least of which, is where the physical locations of your compute resources are at any given moment of the day.

The point of virtualization is that the systems you use are no longer tied to a specific piece of physical hardware, things can move quickly and without notice. For example, a resource located physically next door to you today could be moved via sVmotion to a server across the country tomorrow. As long as the networking team does all the appropriate routing changes, you’d never know.

There are lots of potential issues to consider, but three are:

1 – If you’re servers are not local to you, then the staff responsible for managing those resources at the current time may also not be local. This means that you’ll have to coordinate across time zones to perform maintenance and other tasks.

2 – Flipping resources to another datacenter may mean you suddenly lose physical access to your systems. The good news is that you can always flip the resources back if something goes physically wrong and you don’t have anyone at the other location at that time to plug the wire back in.

3 – Especially for international companies, technologies that cannot be exported could accidentally end up on virtual systems housed in a non-export country. If you deal with encrypted data-sets, this could become a very serious problem.

When you discuss cloud, the situation gets even more confusing, as you may literally not know what physical location your systems reside in at any given time. SLA’s with the cloud provider become absolutely vital, and must be reviewed regularly.

Separating the compute power from physical hardware is – overall – a good thing, but for as many problems as virtualization solves, we do have to remember that there are new problems to consider. Geography is one of those problems.

Dust off your maps…

Photo Credit: Norman B. Leventhal Map Center at the BPL

• Share this:

It’s true that many of us consider VMware and Microsoft and Citrix to be the parents of virtualization technology, but those of us who have been in the digital world for some time know that they’re standing on the shoulders of giants.

This week IBM announced that they would begin supporting Windows applications and instances within the zSeries mainframe platform.

Now, there isn’t a lot of information contained in the press release as to how they will do it, but if IBM follows form as they have in the past, it will be a Windows-capable card in a zSeries chassis. That means that they zSeries (which runs Z/OS) will be able to manage and at least partially control Windows servers that use system resources housed within the zSeries itself.

The mid-tier platform from IBM – the iSeries AS/400 systems – can already do this, using a hybrid virtualization approach. The physical hardware that the Windows OS installs to is a card that sits within an iSeries chassis, but all other resources are contained within and managed by the AS/400 platform itself in much the same was a physical network interfaces, volumes and other resources are presented to a hypervisor-based VM instance.

Since the release refers to the zSeries Windows capabilities as “hybrid,” it may very well mean we’ll see the same approach to OS virtualization on that platform as well.

It may not be the hypervisor systems we’re used to calling “virtual” these days, but IBM has been doing it for longer, and doing it with a greater degree of stability, than modern approaches.

Just goes to show that as soon as standards are developed, someone will come in an prove that one definition cannot cover an entire topic.

VM’s take up space. They use resources like RAM and CPU cycles when they’re online, and they use up storage no matter if they’re online or not. As VM infrastructures get bigger and bigger, so does the amount of resources that they consume.

In the modern datacenter, this has contributed to a theory called bloat, where VM resources balloon larger and larger over time. In many cases, this bloat isn’t being caused by active resources, and that’s where problems can occur quickly.

As VM’s are provisioned and used, the active resources they take up are necessary for the VM system itself to function. You have 10 servers that each use about 50GB of disk, 2 processor cores and 4GB of RAM, etc. The problems start when those servers are no longer needed.

You upgrade to a new CRM system. The old CRM system’s VM’s are – of course – shut down after the migration. As usual for any updated system, the old system is kept dormant for a period of time, just in case you have to either go back to it, or retrieve data that didn’t make it through the migration process for some reason.

Now it’s six months later, and the old system is all but forgotten about. But the VM’s that made up that old system are still there. Since they’re not physical machines, and since they’re not using RAM and CPU power, it is all to easy to simply forget they exist and leave them on the VM hosts that they formerly ran on. That means that a set of storage is not useable, because it’s being held by the – now-non-functioning – CRM system VM’s.

As more applications go through this life-cycle, more dormant VM’s are left sitting on the VM hosts, eating up more and more space and other resources (VM network ports, etc).

So, a few times a year, go through all the dormant VM’s and make sure they really need to be on the VM systems at all. If they don’t, clear out the space (after taking a backup, of course) and free it up for other systems within your active pool of VM’s.

There will always be some dormant VM’s that need to stick around for various reasons, but any that do not need to remain on the VM hosts are doing nothing but sapping space and taking up time during maintenance runs.

Dealing with bloat effectively can mean the difference between having a smooth running system with plenty of space, and having to buy a new storage device because you ran out of room for no valid reason.