{"id":716,"date":"2015-04-14T23:28:32","date_gmt":"2015-04-15T04:28:32","guid":{"rendered":"http:\/\/www.smbitjournal.com\/?p=716"},"modified":"2017-02-19T04:04:46","modified_gmt":"2017-02-19T09:04:46","slug":"virtualizing-even-a-single-server","status":"publish","type":"post","link":"https:\/\/smbitjournal.com\/2015\/04\/virtualizing-even-a-single-server\/","title":{"rendered":"Virtualizing Even a Single Server"},"content":{"rendered":"
I find it very common in conversations involving virtualization to have the concept of consolidation, which in the context of server virtualization refers to putting multiple formerly physical workloads onto a single physical box with separation handled by the virtual machine barriers, treated as being the core tenant and fundamental feature of virtualization. \u00a0Without a doubt, workload consolidation represents an amazing opportunity with virtualization, but it is extremely important that the value of virtualization and the value of consolidation not be confused. \u00a0Too often I have found that consolidation is viewed as the key value in virtualization and the primary justification for it but this is not the case. \u00a0Consolidation is a bonus feature, but should never be needed when justifying virtualization. \u00a0Virtualization should be a nearly foregone conclusion while consolidation must be evaluated and many times would not be used. \u00a0That workloads should not be consolidated should never lead to the belief that those workloads should not be virtual.\u00a0 I would like to explore the virtualization decision space to see how we should be looking at this point.<\/p>\n
Virtualization should be thought of as hardware abstraction as that is truly what it is, in a practical sense. \u00a0Virtualization encapsulates the hardware and presents a predictable, pristine hardware set to guest operating systems. \u00a0This may sound like it adds complication but, in reality, it actually simplifies a lot of things both for the makers of operating systems and drivers as well as for IT practitioners designing systems.\u00a0 It is because computers, computer peripherals and operating systems are such complex beasts that this additional layer actually ends up removing complexity from the system by creating standard interfaces.\u00a0 From standardization comes simplicity.<\/p>\n
This exact same concept of presenting a standard, virtual machine to a software layer exists in other areas of computing as well, such as with how many programming languages are implemented.\u00a0 This is a very mature and reliable computing model.<\/p>\n
Hardware abstraction and the stability that it brings alone are reason enough to standardize on virtualization across the board but the practical nature of hardware abstraction as implemented by all enterprise virtualization products available to us today brings us even more important features.\u00a0 To be sure, most benefits of virtualization can be found in some other way but rarely as completely, reliably, simply or freely as from virtualization.<\/p>\n
The biggest set of additional features typically come from the abstraction of storage and memory allowing for the ability to snapshot storage or even the entire running state of a virtual machine, that is to take an image of the running system and store it in a file.\u00a0 This ability leads to many very important capabilities such as the ability to take a system snapshot before installing new software, changing configurations or patching; allowing for extremely rapid rollbacks should anything go wrong.\u00a0 This seemingly minor feature can lead to big peace of mind and overall system reliability.\u00a0 It also makes testing of features and rolling back or repeated testing very easy in non-production environments.<\/p>\n
The ability to snapshot from the abstraction layer also leads to the ability to take “image-based backups”, that is backups taken via the snapshot mechanism at a block device layer rather than from within the operating system’s file system layer.\u00a0 This allows for operating system agnostic backup mechanisms and backups that include the entire system storage pool all at once.\u00a0 Image backups allow for what were traditionally known as “bare metal restores” – the entire system can be restored to a fully running state without additional interaction – easily and very quickly.\u00a0 Not all hypervisor makers include this capability or include it to equal levels so while conceptually a major feature it is critical that the extent to which this feature exists or is licensed must be considered on a case by case basis (notably HyperV includes this fully, XenServer includes it partially and VMware vSphere only includes it with non-free license levels.)\u00a0 When available, image-based backups allow for extremely rapid recovery at speeds unthinkable with other backup methodologies.\u00a0 Restoring systems in minutes is possible, from disaster to recovery!<\/p>\n
The ability to treat virtual machines as files (at least when not actively running) provides additional benefits that are related to the backup benefits listed above.\u00a0 Namely the ability to rapidly and easily migrate between physical hosts and even to move between disparate hardware.\u00a0 Traditionally hardware upgrades or replacements meant a complicated migration process fraught with peril.\u00a0 With modern virtualization, moving from existing hardware to new hardware can be a reliable, non-destructive process with safe fallback options and little or possibly even zero downtime!\u00a0 Tasks that are uncommon but were very risky previously can often become trivial today.<\/p>\n
Often this is the true benefit of virtualization and abstraction mechanisms.\u00a0 It is not, necessarily, to improve the day to day operations of a system but to reduce risk and provide flexibility and options in the future.\u00a0 Preparing for unknowns that are either unpredictable or are simply ignored in most common situations.\u00a0 Rarely is such planning done at all, much to the chagrin of IT departments left with difficult and dangerous upgrades that could have been easily mitigated.<\/p>\n
There are many features of virtualization that are applicable to only special scenarios.\u00a0 Many virtualization products include live migration tools for moving running workloads between hosts, or possibly even between storage devices, without downtime.\u00a0 High availability and fault tolerant options are often available allowing some workloads to rapidly or even transparently recover from system hardware failure, moving from failed hardware to redundant hardware without user intervention.\u00a0 While more of a niche benefit and certainly not to be included in a list of why “nearly all workloads”\u00a0 should be virtual, it is worth noting as a primary example of features that are often available and could be added later if a need for them arises as long as virtualization is used from the beginning.\u00a0 Otherwise a migration to virtualization would be needed prior to being able to leverage such features.<\/p>\n
Virtualization products typically come with extensive additional features that only matter in certain cases.\u00a0 A great many of them fall into a large pool of “in case of future need.”\u00a0 Possibly the biggest of all of these is the concept of consolidation, as I had mentioned at the beginning of this article.\u00a0 Like other advanced features like high availability, consolidation is not a core value of virtualization but is often confused for it.\u00a0 Workloads not intending to leverage high availability or consolidation should still be virtualized – without a doubt.\u00a0 But these features are so potentially valuable as future options, even for scenarios where they will not be used today, that they are worth mentioning regardless.<\/p>\n
Consolidation can be extremely valuable and it can easily be understood why so many people simply assume that it will be used as it is so often so valuable.\u00a0 The availability of this once an infrastructure is in place is a key point of flexibility for handling the unknowns of future workloads.\u00a0 Even when consolidation is completely unneeded today, there is a very good chance, even in the smallest of companies, that it will be useful at some unknown time in the future.\u00a0 Virtualization provides us with a hedge against the unknown by preparing our systems for the maximum in flexibility.\u00a0 One of the most important aspects of any IT decision is managing and reducing risk.\u00a0 Virtualization does this.<\/p>\n
Virtualization is about stability, flexibility, standardization, manageability and following best practices.\u00a0 No major enterprise virtualization product is not available, at least in some form, for free today.\u00a0 Any purchase would, of course, require a careful analysis of value versus expenditure.\u00a0 However, with excellent enterprise options available for free from all four key product lines in this space currently (Xen, KVM, HyperV and VMware vSphere) we need make no such analysis.\u00a0 We need only show that the implementation is a non-negative.<\/p>\n
What makes the decision making easy is that when we consider the nominal case – the bare minimum that all enterprise virtualization provides which is the zero cost, abstraction, encapsulation and storage based benefits we find that we have a small benefit in effectively all cases, no measureable downsides and a very large potential benefit from the areas of flexibility and hedging against future needs.\u00a0 This leaves us with a clear win and a simple decision that virtualization, being free and with essentially no downsides on its own, should be used in any case where it can be (which, at this point, is essentially all workloads.)\u00a0 Additional, non-core, features like consolidation and high availability should be evaluated separately and only after<\/em> the decision to virtualize has already been solidified.\u00a0 No lack of need for those extended features, in any way, suggests that virtualization should not be chosen based on its own merits.<\/p>\n This is simply an explanation of existing industry best practices which have been to virtualize all potential workloads for many years.\u00a0 This is not new nor a change of direction.\u00a0 Just the fact that across the board virtualization has been an industry best practice for nearly a decade shows what a proven and accepted methodology this is.\u00a0 There will always be workloads that, for one reason or another, simply cannot be virtualized, but these should be very few and far between and should prompt a deep review to find out why this is the case.<\/p>\n When deciding whether or not to virtualize, the approach should always be to assume that virtualization is a foregone conclusion and only vary from this if a solid, defended technical reason makes this impossible.\u00a0 Nearly all arguments against virtualization come from a position of misunderstanding with a belief that consolidation, high availability, external storage, licensing cost and other loosely related or unrelated concepts are somehow intrinsic to virtualization.\u00a0 They are not and should not be included in a virtualization versus physical deployment decision.\u00a0 They are separate and should be evaluated as separate options.<\/p>\n It is worth noting that because consolidation is not part of our decision matrix in creating base value for virtualization, that all of the reasons that we are using apply equally to both one to one deployments (that is a single virtual machine on a single physical device) as to consolidated workloads (that is multiple virtual machines on a single physical device.)\u00a0 There is no situation in which a workload is “too small” to be virtualized.\u00a0 If anything, it is the opposite, only the largest workloads, typically with extreme latency sensitivity, where a niche scenario of non-virtualization still exists as an edge case but even these cases are rapidly disappearing as latency improvements in virtualization and total workload capacities are improved.\u00a0 These cases are so rare and vanishing so quickly that even taking the time to mention these cases is probably unwise as it suggests that exceptions, based on capacity needs, are common enough to evaluate for, which they are not, especially not in the SMB market.\u00a0 The smaller the workload, the more ideal for virtualization, but this is only to reinforce that small business, with singular workloads, are the most ideal case for virtualization across the board rather than an exception to best practices, not to suggest that larger businesses should be looking for exceptions themselves.<\/p>\n","protected":false},"excerpt":{"rendered":" I find it very common in conversations involving virtualization to have the concept of consolidation, which in the context of server virtualization refers to putting multiple formerly physical workloads onto a single physical box with separation handled by the virtual machine barriers, treated as being the core tenant and fundamental feature of virtualization. \u00a0Without a … Continue reading Virtualizing Even a Single Server<\/span>