Posts Tagged ‘vcpu’

Cloud Computing Simplified (Part I)

December 14, 2010

Gartner projected that cloud computing will continue to pick up momentum next year as it cements its position as one of the top four technologies that companies would invest in. Earlier this past November, Gartner projected that cloud computing would (continue to) be a revolution much like e-business was, rather than just being a new technology added to the stack of IT arsenal.

What is cloud computing? A tech-challenged friend of mine asked one time. As I took a deep breathe before I let out the loads of knowledge that I have accumulated reading about, teaching about and working with cloud applications in its various layers, I froze for a second as I did not know how to explain it in layman’s terms. Of course if I were talking to an IT person I would get away with talking about the mouthful acronyms of ?aaS (where ? is any letter in the alphabet). However, when the person opens the discussion asking “Is my company’s website a SaaS?”, “Is my company’s website a cloud? The cloud? Running in a cloud?”, it hit me maybe there was a reason why every book I pick up or article I come across that talks about the cloud, includes a first paragraph that always provides a disclaimer that goes like this “The first thing about cloud computing is that it has many definitions, and no one can define it precisely, but we will give it a try in this book”. Maybe that is how I should start every attempt to define the cloud to someone else?

Before I answered my friend’s question, I phased out for a little bit as a big blackboard suddenly appeared in front of me with humongous set of UML diagrams (they were called UML but they included every possible shape and a verbal disclaimer for getting away from the standard diagrams by the architect drawing on the board). Those diagrams were so big and complex that people moved away from typing notes to taking pictures of the board. Including “high resolution” as an important requirement of a smart phone  before purchasing it, became an important differentiator between competitor phones (the iPhone won the war for me as it has the best resolution as of the time of this typing). High resolution was important because you see everyone in the room shouldering each other at the end of the meeting as they take a picture of the complex diagram using their phone. None of that stuck out in my mind, as I was phasing out, as much as the big cloud diagram drawn to the side of the big complex picture. That component was always known by everyone as the Cloud, and it always meant “everything else”, “something else”, “anything”, “everything”, “something”, “I have no freaking clue what there is”, etc. It was the piece that no one cared about, it was just sitting there encompassing a big piece of the entire system, yet, it was of less importance (apparently) as everything else on the board, thus earning its “cloudy” scribble to the side of the board. OK, so the Cloud is something useless that no one pays attention to? That may be a cop-out if my friend hears those words out of my mouth after a pause.

All of a sudden, something else happened. As I was dazing off, I started thinking to myself: Well, wait a minute. Did we change our definition of that little useless cloud drawn on the board? Or is it really useless? To be able to answer that question, I had to understand why the hell we resorted to drawing “everything else”, “something else”, etc. as an isolated cloud. Maybe it wasn’t useless. Maybe it was extremely important but irrelevant. Which is a big difference. Sometimes it is good to have a big chunk of your system abstracted away in its own little cloud shape being irrelevant to any other changes you make to your system. After all, if every change you make affects everything else in the system including your infrastructure, there is a big problem in your system’s design to begin with. So, maybe it was a good thing that architects had a big cloud sitting off to the side. As a matter of fact, the bigger that cloud that is not affected and does not affect your changes to the rest of the system the better! OK, so now I have solved one mystery. The cloud is the part of your system (infrastructure, platform, and software) that is abstracted from you because your system was designed correctly in such a way to have its component independent of each other. This way, you can ultimately concentrate on the business problem at hand, rather than all the overhead that is there just as an enabler rather than being fundamental to the business at its core.

But wait! If architects have been defining clouds on their boards for such a long period of time, what is so new about it? The short answer is: nothing is new about the cloud! The cloud is not something that just popped up. It has been around for a long time! From clusters of mainframes in the 60s and 70s, to GRID computing, the cloud has been there for a long time. The reason why it was picked up by the professional world just recently was due to the giant improvements in virtualization management tools that allowed the customer to easily manage the complexity of clouds. OK, I am getting somewhere, but I still haven’t gotten to my friend’s questions. Maybe I should continue to go deeper to find more answers first before I unload my knowledge, or lack-thereof! Going back to the board. Was every cloud really a cloud? After all, sometimes an architect draws a cloud around a piece or a component that she doesn’t understand. So, there has to be a difference between the cloud that a knowledgeable architect draws versus someone else that had it mistaken for another UML diagram component.  So, what defines a cloud? Well, it is an abstracted part of the system. It may encompass infrastructure, platform and/or software pieces.

That is the easy part. Here comes the more technical part. The cloud provides infrastructure, platform and software on an as-needed basis (service). It gives you more resources when you need them, AND it takes away extra resources you are not using (yes, the cloud is not for the selfish of us). To be able to call it a form of Utility Computing (where you pay only for the resources you use), an additional cost factor is associated with the resources you use on an hourly basis (or resource basis). Yes, if it is free, then it is not the cloud. No place for socialists on the cloud. We will skip this argument of paid versus free because you will tell me that many cloud-based applications are available for free, and I will tell you that nothing is free because those same applications provide a free version (which is just a honeypot for businesses) and the paid version (which is where businesses need to end up just to match the capabilities of their in-house software). The cloud may be free for individuals like me and you who don’t care about up-time and reliability, but I am focusing my discussion here on businesses (after all, an individual will not have their own data center, or require scalability, etc.)  So, I win the argument, and we move on!

Another condition is for all those resources to be available via TCP/IP based requests (iSCSI or iFC for hardware, web-services API calls for platform and software resources). It is important that requests and responses to cloud’s resources go on the web, otherwise you cannot scale up to other data centers sitting somewhere else. The cloud is scalable (“infinite” resources), DR (disaster recovery) ready, FA (fail-over) ready, and has a very HA (high availability). The last three characteristics are made possible by a few technology solutions that sit on top of the cloud such as virtualization, although virtualization is not a necessary component in a cloud due to the use of commodity computers factor which is to be discussed below. With virtualization management tools, DR – for applications only, FA and HA are provided out of the box,  DR for databases is made possible by replication (and acceleration and de-duplication techniques sped up the process across physical LANs) tools. Scalability is provided by the SOA (service oriented architecture) characteristics of the cloud of its independent and stateless services. Another component that is essential to defining what a cloud is, is the use of commodity computers. It is essential because single CPU power is not relevant anymore as long as  you have an infinite pool of your average joe-CPU. Google builds its own commodity computers in-house (although no one knows the configurations of such computers), and it is believed that Google has up to 1,000,000 commodity computers powering its giant cloud. If the cloud service provider is using powerful servers instead of commodity computers, that is an indication that they don’t have enough computers to keep their promise of scaling up for you. The reason why both properties cannot co-exist is because if the provider can have “unlimited” powerful servers, that implies that to offset their cost (especially cooling) they would have to provide the service to you for extremely high prices, offsetting the benefit of moving to the cloud versus having your own data center. Many people also believe the cloud to be public (meaning that your application will be running as a virtual machine right next to your competitor’s on the same physical machine with a low probability – albeit bigger than 0%).

Many companies choose to run their own “cloud” data center (private), which theoretically violates a few of the concepts we defined above (cost per usage, unlimited scalability). That is why some don’t consider private clouds to be clouds at all. However, to their dislikes, private clouds have dominated the early market as companies have bought into the cloud concept but they still fear that it uses too many new technologies, which makes it susceptible to early security breaches and problems. Amazon had a major outage in the East region in Virginia toward the end of 2009 (which violates the guarantee that your services are always available as they are replicated across separate availability regions). So, we know what private clouds (internal data centers designed with all the properties of a cloud minus the cost per usage and unlimited resources), and what public clouds are (gmail anyone?). What if you want a combination of both? Sure, no problem, says the cloud. You have the hybrid cloud (using a combination of private clouds for your internal, business critical applications that do not require real time scalability to public services on public clouds where you push your applications that require the highest availability and scalability (Take Walmart’s web site around the holidays for example). This is going to be the future of the cloud as there are always going to be applications that do not need the power of the cloud such as email (does not need to scale infinitely in real time), HR, financial applications, etc. There is a fourth kind which is a virtual cloud. This is having the advantage of both worlds (public resources but private physical data centers). You have access to a public cloud, but your own secure isolated vLAN that you can access via VPN over HTTP (IPSec). The virtual cloud will guarantee that no other company’s applications will be run on the same physical hardware as your company’s. Your internal applications will connect to your other services sitting on a public cloud via secure channels and dedicated infrastructure (on the public cloud).

If you are confused about how applications (for various companies) can be running on the same physical machine and why in hell you would want to do that, check out my two series articles about virtualization.

— To be continued here

Advertisements

Virtualization – Under the Hood (Part II)

November 19, 2010

This is a continuation of my last post (Virtualization – Under the Hood (Part I)).

Q: Can you actually have more memory allocated than available physical memory? And how?

Short Answer: Yes. Through  many techniques including: Transparent page sharing, page reclamation, balloon driver, etc.

Long Answer: You can actually start many VMs with total allocated memory that is more than the physical memory available on the server because not all applications will utilize 100% of their requested memory at all times. Page reclamation allows the hypervisor to reclaim unused (previously committed) pages from one VM and give it to another. Another technique a hypervisor may use is to allow VMs to share memory without them knowing it! Sounds scary, but nonetheless manageable by the hypervisor. This allows more VMs to start with their full requirements of allocated memory met, although they may be sharing memory pages with other VMs. Lastly, there is the approach of ballooning memory out of a VM. This is more of a respect driven approach by the hypervisor where it requests memory from all executing VMs, and they would voluntarily balloon out all the memory pages they are not using. Once they need the memory back, the hypervisor will send it back after obtaining it from other VMs using any of the methods above. Swapping pages with the hypervisor is an expensive operation. That is why you should always start your VM with a pre-set Reservation amount (minimum amount of memory guaranteed to the VM by the hypervisor). However, the more you reserve upon start up of your VM, the less VMs can be fired up on that same physical host.

Q: How do you make sure your application is highly available?

Short Answer: It depends on the approach, and the virtualization suite you are using. You either take things into your own hand and cluster your application over 2+ VMs, and make sure you replicate necessary data over to the redundant VM(s), or use the tools provided by virtualization suite to move the VM to a less utilized or crowded host.

Long Answer: High availability of VMs can be jeopordized in one of two ways:

1. Either your VM is running on a highly utilized host, making your applications less responsive. In this approach you can utilize the virtualization suite to transfer or migrate your running VM to another host that is less crowded. vSphere provides vMotion, which is used by their HA appliance to migrate your VM to another host without taking the VM down! They actually start copying your VM byte by byte starting with the section of your memory that is not or under utilized at the moment, while keeping track of all “dirtied” pages since the last transfer to re-transfer again to keep it consistent on the new host. At some point the hypervisor of the first machine will turn off the VM, while the other hypervisor on the target machine turns it on simultaneously. Microsoft added Live Migration to their R2 release of HyperV to do just that. There are many metrics and thresholds that can be configured to trigger such an action. Dynamic Resource Scheduling (DRS) in vSphere allows you to set those parameters and move away from the cluster, DRS will manage to move your VM from one host to another to ensure highest availability and accessibility.

2. When a host goes down, another VM needs to fire to start taking requests. This can be done using virtualization suite tools (only when data replication is not required). However, when you need to cluster your data as well then you will need to introduce data replication yourself such as Microsoft SQL Server clustering. This will allow the new VM to immediately serve requests as soon as the first VM goes down. Of course there will need to be some sort of switch control at the virtualization suite management level or using an external context switch appliance such as NetScaler.

Q: Is virtualization the equivalent of parallel processing on multiple processors?

Short Answer: Yes and no.

Long Answer: Virtualization introduces the capability of borrowing CPU cycles from all CPUs physically available on the host. The side-effect of this is introducing the effect of parallel processing. However, the only reason a hypervisor would want to borrow cycles from another CPU is because the first CPU it had access to is fully utilized. So, technically, you are not really parallelizing to run things in parallel, but rather to use as much of the CPU cycles as your application needs to run its single- or multi-threaded code.

Q: Since we are running multiple VMs on the same host, doesn’t that mean we share the same LAN?? Wouldn’t that be a security threat if one application on one VM was missconfigured to access an IP of a service on another VM?

Short Answer: Yes. But we don’t have to share the same network even among VMs on the same host.

Long Answer: You can create virtual LANs even between VMs running on the same physical host. You can even use firewalls between VMs running on the same host. This way you can create DMZs that keep your applications (within your VM) safe no matter which VMs are running on the same host.

Q: Since a hypervisor emulates hardware, does that mean that my guest operating systems are portable, EVEN among different hardware architectures?

Short Answer: Yes.

Long Answer: Most virtualization suites support x86 architectures because they are “better” designed to take advantage of virtualization. It also depends on the virtualization suite you are using, and what guest OS it supports (for example vSphere does not support AIX). Additionally, although in theory those guest OS and their hosted applications are portable, it also depends on the hypervisor’s own implementation of drivers on the system. The hypervisor code does not use the drivers installed inside the guest OS, but its own set of drivers. The implementation could vary from one system to another, one device to another. So, you definitely may end up with different behaviors or performance on different hardware even using the same VM.

Note: The Open Virtualization Format (OVF) is a standard format to save VM in so you can migrate them to another virtualization suite (not just hardware!) However, not many virtualization tools support this format yet.

Q: What about security? Who controls access to VMs?

Short Answer: Virtualization suites provide user management. This list is separate from application users.

Long Answer: There are many layers of user roles and permission management in a virtualization suite, depending on the suite itself. Typically, you can create users, define their role, their access to VM, and what type of permission they get. You can even create pools of VMs and apply the same set of user role/permission combination. This eliminates having to manage security and authentication on each individual hypervisor, and instead, do the management across a host of them.

Q: Ok, ok, ok. How about the dark side of virtualization?

Short Answer: There are many problems or potential problems with virtualization. It is not all roses.

Long Answer: There could be many reasons why not to use virtualization including:

1. With virtualization, now you are collapsing the system administration and networking team (and possibly security as well) into one team. Most (if not all) virtualization suites do not provide various roles of managing the virtualized datacenter based on those divisions. Once you have an administrator access to managing the virtualized datacenter, all divisions are off at that point. This can be seen as a good thing. However, it is mostly a bad thing because a system administrator is not necessarily a person that is highly specialized in dissecting the network among all the various applications based on the requirements and capabilities of the enterprise.

2. Upgrading or updating one application or VM requires a lot more knowledge in its requirements and potential effects on other VMs on the same host. For example, if an application doubles its memory requirements, the IT administrator managing the virtual environment must know even if the increase in requirement comes on a host that has that enough physical memory. In a traditional environment, as long as the physical memory is available, the IT administrator deploying the updates or upgrades does not necessarily need to know of the new memory requirements of the application as long as no additional physical memory needs to be attached to the server. This change forces administrators of the virtual environment to be more aware and knowledgeable of the applications and VMs running in their system, which is not a hard-line requirement in traditional systems.

3. If the number of VMs fall under 10 or so per host, then you maybe adding more overhead than realizing the benefits of virtualizing your machines.

4. Testing and debugging system events are a lot more involved now as an administrator has to chase the VM wherever it goes in order to check the trail of events across those machines, plus look at the guest OS even logs to complete the picture before understanding the problem.

5. Created VMs will require physical space as well (for the VM files themselves). This is an overhead, and if not managed correctly you may end up bursting your storage capacity bubble with over-creating VMs.

6. Miscellaneous: expensive management tools, new IT skills to be learned, single point of failure (if one host goes down, it will take down many VMs with it), more bandwidth headache if one physical host starts up (making many VMs initialize while starting up at the same time), etc.