As an organization matures in its journey towards IT-as-a-Service, it becomes increasingly apparent that this is unachievable without increased workload virtualization.
An organization must adapt its IT Governance and adopt a “virtualization first” policy for application workloads. Only then will they be on the path tp realize the full potential of the software-defined datacenter.
This governance process is one in which through which all workloads (net-new, or refreshed) will be deployed as or on virtual machines unless exempted through an virtualization candidate criteria or through an exception process with appropriate override authorization. Any workload, is subject to the governance process - for example, Mission Critical, Business Critical, Business Important or Supporting Function workloads.
An example candidacy governance process and criteria are depicted and discussed below.
While most current platforms natively exceed the requirements for application workloads (e.g. VMware vSphere 5.1) the capabilities and the capacity for the as-is deployed platform needs to be considered.
Any workload identified beyond the supportable attributres should be
|CPU||> 64 CPU|
|RAM||> 1 TB|
|Storage||> 64 TB|
|Hardware: Proprietary||Non-USB License Dongles Hardware Encryption Devices I/O Boards (Serial Cards, etc)|
Workloads which are not automatic can fall into qualified based on atributes supported by the native platform and deployment architectures.
In order for an application workload to be fully supported on a virtualization platform, a support statement from the vendor is desirable.
For example, with VMware, their ISV team can provide specific statements from the vendors themselves or equests for specific vendor statements can be submitted to the VMware ISV team by visiting: http://www.vmware.com/go/isvsupport. Alternatively, an organization’s VMware Technical Account Manager is able to provide support statements and work with vendors to ascertain or establish support statements.
In general, vendor support statements fall into general categories described in this section.
[infobox]Organizations should consider leveraging virtualization for any application which fall into the ‘Yes’ categories.
<COMPANY NAME> will support <APPLICATION NAME> in a virtualized environment provided recommended requirements are met and best practices are followed.
<COMPANY NAME> states there is no virtualization specific support statement.
With that being said <COMPANY NAME> does support <APPLICATION NAME> running on a platform with our stated systems requirements, <SYSTEM REUIREMENTS HERE>. As long as the system requirements are met <APPLICATION NAME> is supported by the vendor and any other issues which are determined to be outside of <APPLICATION NAME> are supported by other vendors.
<COMPANY NAME> approach to virtualization is to treat each as a transparent layer. <COMPANY NAME> products are built, tested and supported on the native operating system (e.g., Windows, Linux, etc.). <COMPANY NAME> will continue to provide support to a client whether an approved virtualization platform is present or they are running on the native OS, however, issues believed to be related to virtualization may be required to be reproduced in a physical environment. Because <COMPANY NAME> does not test products with virtualization, the support is based on the virtualization vendor providing complete transparency.
<COMPANY NAME> will support products on irrespective of whether they are running in virtualization environments or not. <COMPANY NAME> supports specific operating systems, not specific hardware configurations.
<COMPANY NAME> will not require customers to recreate and troubleshoot every issue in a non-virtualized environment; however, <COMPANY NAME> may reserve the right to request that an organization diagnose certain issues in a native, bare-metal operating system environment. <COMPANY NAME> will only make this request when there is reason to believe that the virtual environment is a contributing factor to the issue.
Any time spent on investigation of problems that may, in the sole opinion of <COMPANY NAME> be related to virtualization, will be handled in the following fashion:
<COMPANY NAME> confirms support for <APPLICATION NAME and VERSION> for supported operating systems in a virtualization environment. <COMPANY NAME> will provide unqualified support for <APPLICATION NAME and VERSION> running in a virtualization environment in an identical manner as with <APPLICATION NAME and VERSION> running on any other major x86 based systems without initially requiring reproduction of issues on native hardware.
Should <COMPANY NAME> suspect that the virtualization layer is the root cause of an incident; the organization will be required to contact the appropriate provider to resolve the virtualization issue. While <APPLICATION NAME and VERSION> is expected to function properly in virtualization, there may be performance implications which can invalidate sizing and other recommendations.
<COMPANY NAME> does not support <APPLICATION NAME> running in a virtualization.[/infobox]
|Automatic||IT Governance Committee||This workload represents the majority of servers within an environment. It represents applications that do not tax systems extensively and have no technical reason not to be virtualized. If a department wishes for these to be physical, they must obtain the defined level of override sponsorship.|
|Qualified||EA Governance Committee||These workloads have been used within a virtual environment and appear to be working adequately. Outstanding issues which may not qualify them for automatic consideration for virtualization may be a large workload or an untested application moving forward. These workloads typically require further analysis and testing in a virtualized environment.|
|Non-Qualified||EA Governance Committee||These workloads require resources that are higher than the current VMware Infrastructure has been designed for, or require special considerations. It is not to say that they cannot be virtualized, but that standard rules most likely do not apply. For this reason a director should be made aware of the request for physical hardware, and special efforts may need to be taken in order to ensure that service levels are to be met.|
|Contraint||Workaround | Approach|
|Resource Limitations||The platform service continues to expand on the maximum configurations permitted with each new release.|
|Hardware: Fax and Voice Cards||Many telephony and fax solutions are moving to support the offloading of fax and voice processing to a separate, networked hardware device and communicating via IP. Contact your vendor to investigate this possibility for current and future versions of the solution.|
|Hardware: Modems and other Serial Port Connections.||Many modem devices can be replaced with the use of a serial-over-IP solution which presents to the Virtual Machine guest operating system as a serial port and redirects traffic via IP to the modem. This approach is generally transparent to the application.|
|Hardware: Security Dongles||Many applications which have required a physical hardware dongle in the past now also support the use of distributed licensing control mechanisms.|
|Software: Unsupported Operating System||Consider migration to another application or operating system where appropriate.|
|Software: Unsupported Application||Many vendors are moving to support virtualization platform services with their applications. Contact your vendor to investigate this possibility for current and future versions of the solution. VMware, for example, also maintains a team which works with vendors to introduce support statements for products on VMware. Consider this as a criterion for product selection when current licensing agreements expire.|