Dispatch /

IT Governance and the Software-Defined Datacenter: The Virtualization Policy

21 Sep 2012

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.

Non-Candidate Workloads

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

Example:

Attribute   Value
CPU > 64 CPU
RAM > 1 TB
Storage > 64 TB
Hardware: Proprietary Non-USB License Dongles Hardware Encryption Devices I/O Boards (Serial Cards, etc)

Qualified Candidate

Workloads which are not automatic can fall into qualified based on atributes supported by the native platform and deployment architectures.

For example:

Application Support

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.

Yes.

<COMPANY NAME> will support <APPLICATION NAME> in a virtualized environment provided recommended requirements are met and best practices are followed.                           

Yes, by Default.

<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.

Yes, but Fuzzy.

<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.

Yes, with Qualifying Support Statement

<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:

  1. <COMPANY NAME> will provide standard support to all <COMPANY NAME> products.
  2. If a problem is encountered while <COMPANY NAME> products are running in a virtualization environment, the organization may be required to recreate the problem on physical instance, at which time <COMPANY NAME> will provide regular support.
  3. The organization  can authorize <COMPANY NAME> to investigate the related items at normal time and materials rates. If such investigation shows that the problem is virtualization related, the organization may contract <COMPANY NAME> to provide a software change to resolve the issue if such a resolution is possible.
  4. Regardless of the problem type or source, if the problem is determined to be a virtualization related time spent on investigation and resolution will be covered as part of regular maintenance, and support will be provided as usual.

Yes, with Unqualified Support

<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.

No

<COMPANY NAME> does not support <APPLICATION NAME> running in a virtualization.[/infobox]

Licensing Considerations

Organizations should recognize that many software vendors have different approaches to software licensing when applied to a virtualization. Several of these approaches are not “virtualization friendly” and unfortunately may require difficult vendors discussions. Organizations should work with software vendors who support the virtualization and avoid vendors who do not employ fair licensing practices in a virtual environment.

"Virtualization-Friendly" Licensing

Software vendors which treat a virtual machine as a physical machine and require the same licensing on either a physical or virtual platform have virtualization-friendly licensing. For example, if a software product is licensed based on the number of processors, and a physical machine with 2 processors is the same as a virtual machine with 2 virtual processors, this is a virtualization-friendly license scheme.

Other Licensing

Software vendors which tie licenses to the underlying physical hardware, regardless of the virtual environment that software is running can result in substantial increases in software licensing (e.g. Oracle). For example, if software is licensed based on the number of physical processors or cores, regardless of the virtual environment, a software product executing on a virtual machine with one virtual processor will have to pay for a software license covering each of the processors or cores in the underlying physical hardware. Some software vendors will require licenses for each processor or core that the software may end up executing on. In a software-define data center where workloads are mobility is dynamic, this can result in the need to license each processor or core . Organizations should avoid these licensing schemes and are strongly encouraged to seek out vendors who have virtualization-friendly licenses.

Licensing Statements

Virtualization candidate workloads should obtain licensing requirements from software vendors to ensure that licensing in the virtual environment is supported by the vendor and does not introduce a penalty for virtualization of the software.

Exception Process and Approvals

Workloads which are identified as candidates may be exempted from policy through override sponsorship by IT Governance only. Examples:
Decision Override Description
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.

Non-Candidate Workarounds and Approaches

Workloads which are identified as non-candidates based on the criteria in may be able to become virtualized through several approaches which may be offered over time or desirable and justifiable as point-solutions. Examples:
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.
Does your organization have a “virtualization first” IT Governance process? If so, how's it helping you in your journey to IT-as-a-Service; how are you working with business, partners and vendors to drive adoption? Send me your thoughts.


Twitter Facebook