From Virtualization to Dynamic IT
June 2010
Summary: Virtualization is a critical infrastructure-architecture layer that is required for achieving higher IT-maturity levels, but several others layers—such as automation, management, and orchestration—are equally important.
IntroductionDynamic IT is an advanced state of IT maturity that has a high degree of automation, integrated-service management, and efficient use of resources. Several IT-maturity models, including Gartner's Infrastructure Maturity Model and Microsoft's Infrastructure Optimization Model, define maturity levels and the attributes that are required to achieve each level. Both the Gartner and Microsoft models agree that virtualization is a critical architecture component for higher IT-maturity levels. However, many other components are required. An infrastructure that is 100 percent virtualized might still have no process automation; it might not provide management and monitoring of applications that are running inside virtual machines (VMs) or IT services that are provided by a collection of VMs. In addition to virtualization, several other infrastructure-architecture layers are required to reach the highest levels of IT maturity. A rich automation layer is required. The automation layer must be enabled across all hardware components—including server, storage, and networking devices—as well as all software layers, such as operating systems, services, and applications. The Windows Management Framework—which comprises Windows Management Instrumentation (WMI), Web Services-Management (WS-Management), and Windows PowerShell—is an example of a rich automation layer that was initially scoped to Microsoft products, but that is now being leveraged by a wide variety of hardware and software partners. A management layer that leverages the automation layer and functions across physical, virtual, and application resources is another required layer for higher IT maturity. The management system must be able to deploy capacity, monitor health state, and automatically respond to issues or faults at any layer of the architecture. Finally, an orchestration layer that manages all of the automation and management components must be implemented as the interface between the IT organization and the infrastructure. The orchestration layer provides the bridge between IT business logic, such as "deploy a new web-server VM when capacity reaches 85 percent," and the dozens of steps in an automated workflow that are required to actually implement such a change. The integration of virtualization, automation, management, and orchestration layers provides the foundation for achieving the highest levels of IT maturity.
Architectural ConsiderationsAchieving higher IT maturity requires a well-designed infrastructure architecture that comprises the previously outlined layers, each of which might be provided by one or more products/solutions. Figure 1 illustrates this conceptual architecture. One of the most important choices to be made is which architecture layer or layers will provide resiliency and high availability for your IT services. These attributes can be provided by the infrastructure layers, at the application platform layer, or some combination of them. It is well known that the architecture pattern that is used by most large cloud services is a scale-out model on commodity hardware. High availability and service resiliency are provided by the application platform and associated development model (stateless-server roles, automatic data replication, and so on). This model makes sense, given the nature of the workload—in particular, the small amount of standard workloads that the hardware must support in very large quantities, such as a standard data server and a standard web server. For the more complex and heterogeneous workloads that are found in most infrastructures, this model might not be possible, particularly in the short term. Virtualization and consolidation of legacy workloads that do not include load balancing and other high-availability techniques at the application layer might require the virtualization or hardware layers to provide this capability. It is critical to evaluate the costs of each of these approaches. Providing high availability in the software and application layer can enable a significant reduction in hardware costs by enabling commodity hardware to be utilized and reducing the need for expensive, fault-tolerant hardware. One goal of an enterprise architecture strategy should be to move your application inventory over time (via redesign, retirement, and so on) to the least costly infrastructure model. This is one of the key business drivers of cloud computing.
Figure 1. Infrastructure-architecture layers To illustrate how this conceptual architecture enables a high degree of IT maturity and automation, we will consider a virtualized, three‑-tier application that consists of a clustered pair of database servers, two application servers, and three web servers. For each layer of the conceptual infrastructure architecture, the requirements and capabilities that it must provide to support the workload will be illustrated. Hardware Layer The hardware-architecture choices that are available to data-center architects are constantly evolving. Choices range from commodity rack-mounted servers to tightly integrated, highly redundant blade systems to container models. The same spectrum exists for storage and networking equipment. Hardware and software integration is an attribute of higher IT maturity. Server, storage, and networking hardware should be selected based on its ability to be managed, monitored, and controlled by the architecture layers that are above it. An example would be a server that is able to report issues—such as high system temperatures or failed power supplies—to higher-level management systems that can take proactive measures to prevent service disruptions. Ideally, there would not be separate management systems for each hardware type; each component should integrate into a higher-level management system. Careful consideration of the virtualization and application platforms should be part of the process of hardware selection. If the application platform will provide high availability and resiliency, commodity hardware and limited redundancy can be acceptable and more cost-effective. If the application platform cannot provide these capabilities, more robust hardware and high-availability features in the virtualization layer will be required. For our reference three-tier application, the hardware layer provides the physical infrastructure on which the application's virtual servers run. The hardware layer must provide detailed reporting on the condition and performance of each component. If a disk or host bus adapter (HBA) starts to exhibit a number of errors that is higher than average, this must be reported to the management system, so that proactive measures can be taken prior to an actual fault. Virtualization Layer The virtualization layer is one of the primary enablers of greater IT maturity. The decoupling of hardware, operating systems, data, applications, and user state opens a wide range of options for better management and distribution of workloads across the physical infrastructure. The ability of the virtualization layer to migrate running VMs from one server to another with zero downtime, the ability to manage memory usage dynamically, and many other features that are provided by hypervisor-based virtualization technologies provide a rich set of capabilities. These capabilities can be utilized by the automation, management, and orchestration layers to maintain desired states (such as load distribution) or to proactively address decaying hardware or other issues that would otherwise cause faults or service disruptions. The virtualization layer can include storage, network, OS, and application virtualization. As with the hardware layer, the virtualization layer must be able to be managed by the automation, management, and orchestration layers. The abstraction of software from hardware that virtualization provides moves the majority of management and automation into the software space, instead of requiring people to perform manual operations on physical hardware. In our reference three-tier application, the database, application, and web servers are all VMs. The virtualization layer provides a portion of the high-availability solution for the application by enabling the ability to migrate the VMs to different physical servers for both planned and unplanned downtimes. The virtualization layer must expose performance and management interfaces to the automation layer, so that the management and orchestration layers can leverage these to automate processes such as patching the physical servers, without affecting application availability. In more advanced scenarios, the virtualization layer can span facilities to provide a site-resilient architecture. Automation Layer The ability to automate all expected operations over the lifetime of a hardware or software component is critical. Without this capability being embedded in a deep way across all layers of the infrastructure, dynamic processes will grind to a halt as soon as user intervention or other manual processing is required. Windows PowerShell and several other foundational technologies, including WMI and WS-Management, provide a robust automation layer across nearly all of Microsoft's products, as well as a variety of non-Microsoft hardware and software. This evolution provides a single automation framework and scripting language to be used across the entire infrastructure. The automation layer is made up of the foundational automation technology plus a series of single-purpose commands and scripts that perform operations such as starting or stopping a VM, rebooting a server, or applying a software update. These atomic units of automation are combined and executed by higher-level management systems. The modularity of this layered approach dramatically simplifies development, debugging, and maintenance. Management Layer The management layer consists of the tools and systems that are utilized to deploy and operate the infrastructure. In most cases, this consists of a variety of different toolsets for managing hardware, software, and applications. Ideally, all components of the management system would leverage the automation layer and not introduce their own protocols, scripting languages, or other technologies (which would increase complexity and require additional staff expertise). The management layer is utilized to perform activities such as provisioning the storage-area network (SAN), deploying an operating system, or monitoring an application. A key attribute is its abilities to manage and monitor every single component of the infrastructure remotely and to capture the dependencies among all of the infrastructure components. One method for capturing this data is a service map that contains all of the components that define a service such as the three-tier application that we have been discussing. The Microsoft Operations Framework (MOF) defines a simple but powerful structure for service mapping that focuses on the software, hardware, dependent services, customers, and settings that define an IT service and the various teams that are responsible for each component. In this case, the application consists of the database, application, and web-server VMs, the physical servers on which they run, dependent services such as Active Directory and DNS, the network devices that connect the servers, the LAN and WAN connections, and more. Failure of any of these components causes a service interruption. The management layer must be able to understand these dependencies and react to faults in any of them. Figure 2 represents a service map for the three-tier application. The management layer must be able to model the entire application or service and all of its dependencies, and manage and monitor them. In System Center Operations Manager, this is referred to as a distributed application. This mapping of elements and dependencies enables event correlation, failure root-cause analysis, and business-impact analysis—all of which are critical toward identifying issues before they cause service interruption; helping to restore service rapidly, if there is an interruption; and assisting in resource prioritization when multiple issues are encountered.
Figure 2. Service-map diagram Orchestration Layer The orchestration layer leverages the management and automation layers. In much the same way that an enterprise resource planning (ERP) system manages a business process such as order fulfillment and handles exceptions such as inventory shortages, the orchestration layer provides an engine for IT-process automation and workflow. The orchestration layer is the critical interface between the IT organization and its infrastructure. It is the layer at which intent is transformed into workflow and automation. Ideally, the orchestration layer provides a graphical interface in which complex workflows that consist of events and activities across multiple management-system components can be combined, so as to form an end-to-end IT business process such as automated patch management or automatic power management. The orchestration layer must provide the ability to design, test, implement, and monitor these IT workflows. Consider how many activities must take place in order to update a physical server in a cluster that is running a number of VMs. An applicable patch must be identified; a maintenance window for applying the patch must be defined; the VMs that are hosted by the server must be migrated to a different host; the patch must be applied, and then tested; and, finally, VMs must be moved back to the host. What happens if any one of these operations fails? An orchestration layer is required to enable complex IT processes and workflows, such as those that were previously described. To be able to orchestrate and automate an IT process, the inputs, actions, and outputs of the process must be well understood. Also required is the ability to monitor the running workflow and configure recovery actions, should any step in the process fail. The notifications that are required during success or failure must also be well understood. An effective method for documenting an IT process is to use an IT-process map. Figure 3 illustrates an example that is based on the patch-deployment scenario that was previously described. In the three tier-application scenario, a process such as the one that was previously defined is required. During maintenance of the physical machines that host the VMs, the orchestration layer must account for the high-availability requirements of the application. The system must ensure that the clustered database-server VMs are not placed on a single physical host, as this would negate the benefit of the cluster by creating a single point of failure. The orchestration layer is where IT business-process rules and workflows such as this are defined. These should be treated as source code and placed under strict change control. This layer provides an excellent platform for continuous improvement by encoding the lessons that are learned into IT-process automation.
Figure 3. IT process-map diagram
Achieving Dynamic ITOne of the key drivers of the layered approach to infrastructure architecture that is presented here is to enable complex workflow and automation to be developed over time by creating a collection of simple automation tasks, assembling them into procedures that are managed by the management layer, and then creating workflows and process automation that are controlled by the orchestration layer. A top-down approach to this type of automation is not recommended, as it often results in large, monolithic, and very complicated scripts that are specific to individual environments. These become very costly to maintain over time. A better approach is to assemble a library of automation tasks, script modules, and workflows that can be combined in different ways and reused. Start by recording how often each IT task is performed in a month and automate the top 10 percent. Over time, this automation library will grow into a significant asset. Achieving dynamic IT requires deep understanding and documentation of your existing IT processes. Each process should be evaluated prior to attempting to automate it. Service maps and IT-process maps are essential tools for gathering and documenting the information that is required to automate, manage, and orchestrate IT processes. All redundant or nonessential steps should be removed from the process prior to automating it. This both streamlines the process itself and reduces the amount of automation effort that is required.
ConclusionVirtualization is an important tool for increasing IT maturity. To augment the benefits of virtualization, capabilities such as automation, management, and orchestration are required. The infrastructure architecture must be combined with a trained staff and streamlined IT processes. It is the combination of efficient processes, a well-trained staff, and a robust infrastructure architecture that enables dynamic IT.
ResourcesMicrosoft Operations Framework Team. "Service Mapping: Microsoft Operations Framework (MOF), Version 1.0." Online document. March 2010. Microsoft Corporation, Redmond, WA. (https://go.microsoft.com/fwlink/?LinkId=186459) Microsoft TechNet Library. "Infrastructure Optimization." Online article series. 2010. Microsoft Corporation, Redmond, WA. (https://technet.microsoft.com/en-us/library/bb944804.aspx)
About the AuthorDavid Ziembicki (davidzi@microsoft.com) is a Solution Architect in Microsoft's Public Sector Services CTO organization, focusing on virtualization, dynamic data centers, and cloud computing. A Microsoft Certified Architect | Infrastructure, David has been with Microsoft for four years leading infrastructure projects at multiple government agencies. David is a lead architect for Microsoft's virtualization service offerings. He has been a speaker at multiple Microsoft events andserved as an instructor for several virtualization-related training classes. You can visit David's blog at https://blogs.technet.com/davidzi. |
.jpg "Infrastructure-architecture layers")
.jpg "Service-map diagram")
.jpg "IT process-map diagram")