FEDERATION ENTERPRISE HYBRID CLOUD 3.1 Microsoft Applications Solution Guide

(1)

FEDERATION ENTERPRISE HYBRID CLOUD 3.1

Microsoft Applications Solution Guide

ABSTRACT

This solution guide describes how to use the Federation Enterprise Hybrid Cloud 3.1 to provision and manage new and existing Microsoft Exchange Server, Microsoft SQL Server, and Microsoft SharePoint Server applications for on- premises or hosted cloud services.

September 2015

(2)

Published September 2015

EMC believes the information in this publication is accurate as of its publication date. The information is subject to change without notice.

The information in this publication is provided as is. EMC corporation makes no

representations or warranties of any kind with respect to the information in this publication, and specifically disclaims implied warranties of merchantability or fitness for a particular purpose. Use, copying, and distribution of any EMC software described in this publication requires an applicable software license.

EMC², EMC, Avamar, Data Domain, Data Protection Advisor, Isilon, PowerPath,

RecoverPoint, ScaleIO, ViPR, VMAX, VNX, VPLEX, XtremIO, and the EMC logo are registered trademarks or trademarks of EMC Corporation in the United States and other countries. All other trademarks used herein are the property of their respective owners.

For the most up-to-date listing of EMC product names, see EMC Corporation Trademarks on EMC.com.

Federation Enterprise Hybrid Cloud 3.1: Microsoft Applications Solution Guide

Part Number H14134

(3)

Tables

Terminology ... 9

Table 1. Solution software requirements ...15

Table 2. Exchange 2013 service property values ...32

Table 3. SQL Server service property values ...36

Table 4. SharePoint Server service property values ...40 Table 5.

(6)

Chapter 1 Executive Summary

This chapter presents the following topics:

Federation solutions ... 7

Document purpose ... 7

Audience ... 7

Solution purpose ... 7

Business challenge ... 8

Technology solution ... 8

Essential reading ... 9

Terminology ... 9

(7)

Federation solutions

EMC II, Pivotal, RSA, VCE, Virtustream, and VMware form a unique Federation of

strategically aligned businesses that are free to execute individually or together. The EMC Federation businesses collaborate to research, develop, and validate superior, integrated solutions and deliver a seamless experience to their collective customers. The Federation provides customer solutions and choice for the software-defined enterprise and the emerging third platform of mobile, cloud, big data, and social networking.

The Federation Enterprise Hybrid Cloud 3.1 solution is a completely virtualized data center, fully automated by software. The solution starts with a foundation that delivers IT-as-a- Service, with options for high availability, backup and recovery, and disaster recovery. It also provides a framework and foundation for add-on modules such as application services, database as a service, platform as a service, and cloud brokering.

Document purpose

This Solution Guide describes the Federation Enterprise Hybrid Cloud for Microsoft

Applications solution, which enables automated deployment and management of Microsoft applications, such as Microsoft Exchange Server, Microsoft SQL Server, and Microsoft SharePoint Server, within a Federation Enterprise Hybrid Cloud built with VMware vCloud Suite. The guide introduces the architecture, features, and functionality of the solution and demonstrates the use cases enabled by the solution. Data protection for Microsoft

applications within the Federation Enterprise Hybrid Cloud is described in a separate Solution Guide.

Audience

This guide is intended for customers, partners, and EMC personnel who plan to deploy this solution. Users should have the necessary training and background to install and configure Federation Enterprise Hybrid Cloud, Exchange Server, SQL Server, SharePoint Server, and the associated infrastructure. Users should also be familiar with the infrastructure and security policies of the customer installation.

Solution purpose

This solution provides a reference architecture that integrates all the key components and functionality necessary for deploying, managing, and protecting Microsoft applications in a hybrid cloud. The solution enables customers to leverage the Federation Enterprise Hybrid Cloud 3.1 for:

• On-demand, self-service provisioning of Microsoft Enterprise applications such as Exchange Server, SQL Server, and SharePoint Server

• Complete management of the application service lifecycle

• Provisioning, monitoring, protection, and management of the infrastructure services by line-of-business end users, without IT administrator involvement

• Provisioning of application blueprints with associated infrastructure resources by line- of-business application owners without IT administrator involvement

• Provisioning of backup, continuous availability, and disaster recovery services as part of the cloud service provisioning process

• Database as a service (DBaaS), with rapid, on-demand, self-service provisioning of SQL Server instances and databases on SQL Server virtual machines, post

deployment

(8)

Business challenge

While many organizations have successfully introduced virtualization as a core technology within their data center, end users and business units within the organizations have not experienced many of the benefits of cloud computing such as increased agility, mobility, and control. Transforming from the traditional IT model to a cloud-operating model involves overcoming the challenges of legacy infrastructure and processes, such as:

• Inefficiency and inflexibility

• Slow, reactive responses to customer requests

• Inadequate visibility into the cost of the requested infrastructure

• Limited choice of availability and protection services

To meet these challenges, public cloud providers have built technology and business models catering to the requirements of end-user agility and control. Many organizations are under pressure to provide these same service levels within the secure and compliant confines of the on-premises data center. As a result, IT departments need to create cost-effective alternatives to public cloud services, alternatives that do not compromise enterprise features such as data protection, disaster recovery, and guaranteed service levels.

Deciding where to deploy Exchange Server, SQL Server, and SharePoint Server can involve trade-offs. Traditional on-premises infrastructure gives IT teams more control, but

provisioning can take weeks. Public clouds speed up provisioning, but they do not necessarily meet business requirements for data protection, disaster recovery, and guaranteed service levels. For this Microsoft applications solution, Federation Enterprise Hybrid Cloud 3.1 provides on-premises or hosted cloud services to meet these business requirements.

Technology solution

The Federation Enterprise Hybrid Cloud solution integrates the best of EMC and VMware products and services to deliver a fully integrated, enterprise-ready solution across all three data center pillars—compute, storage, and network. The solution empowers IT organizations to accelerate the implementation and adoption of a hybrid cloud while still enabling

customer choice for the compute and networking infrastructures within the data center. The solution caters to customers who want to preserve their investment and make better use of their existing infrastructure and to customers who want to build new infrastructures

dedicated to a hybrid cloud.

Developed by EMC and VMware product and services teams, the Federation Enterprise Hybrid Cloud solution takes advantage of the strong integration between EMC technologies and the VMware vCloud Suite. The solution includes EMC scalable storage arrays and integrated EMC and VMware monitoring and data protection to provide the foundation for cloud services within customer environments.

This Microsoft Applications solution uses VMware^® vRealize™ Application Services and VMware vRealize Hyperic™ to enable automated deployment, management, and protection of Exchange Server, SQL Server, and SharePoint Server applications, and to enable application monitoring during the application lifecycle.

(9)

Essential reading

The following documents describe the architecture, components, features, and functionality of the Federation Enterprise Hybrid Cloud 3.1 solution:

• Federation Enterprise Hybrid Cloud 3.1: Foundation Infrastructure Reference Architecture Guide

• Federation Enterprise Hybrid Cloud 3.1: Concepts and Architecture Solution Guide

• Federation Enterprise Hybrid Cloud 3.1: Operations Solution Guide

• Federation Enterprise Hybrid Cloud 3.1: Security Management Solution Guide This guide provides external references where applicable. EMC recommends that users implementing this solution are familiar with these documents. For details, refer to Chapter 9: References.

Terminology

Table 1 provides definitions for some of the terms used in this guide.

Terminology Table 1.

Term Definition

Active Directory (AD) Provided with Microsoft Windows Server as a special-purpose database or directory that is designed to store system-specific data for handling a large number of read and search

operations, which are hierarchical, replicated, and extensible.

AlwaysOn Availability

Group (AAG) A high-availability and disaster-recovery feature included with SQL Server as an enterprise-level alternative to database mirroring.

Application blueprint Logical topology of an application for deployment in a virtual cloud. An application blueprint captures the structure of an application with logical nodes, their corresponding services and operating systems, dependencies, default configurations, and network and storage topology requirements. The blueprint is published as a catalog item in the common service catalog.

Business group A set of users, often corresponding to a line of business, department, or other organizational unit, that can be associated with a set of catalog services and infrastructure resources.

Database availability group

(DAG) A set of highly available Microsoft Exchange Server Mailbox servers that host a set of databases and provides automatic database-level recovery from failures that affect individual servers or databases.

High availability (HA) A mechanism that enables a system or infrastructure to continue providing services in the event of isolated component or resource failures.

Infrastructure as a service

(IaaS) A standard set of automated resources that include compute, storage, and networking capabilities provided through a hosting company or service provider.

IT as a service (ITaaS) Enterprise IT that acts and operates as a competitive service provider for an organization that has many provider options for IT services, including outsourcing companies and public cloud providers.

(10)

Term Definition Key performance indicator

(KPI) A quantifiable measure that compares performance criteria, including strategic and operational goals of an organization.

Logical template A predefined virtual machine definition in vRealize Application Services that can be mapped to a cloud template (and supporting services) in the cloud catalog enabling an application blueprint to remain cloud-agnostic.

Pod A collection of virtual machines that has a specific function within the Federation Enterprise Hybrid Cloud.

vRA An abbreviation for vRealize Automation used in diagrams in this guide.

vRealize Application

Services properties vRealize Application Services configuration name-value pairs for services and application components. These are variables used by scripts to set parameters and run various

configurations.

vRealize Automation

Application Services service vRealize Application Services scripted software that can be installed on a virtual machine and reused in multiple applications.

Web front-end (WFE) A Web-based user interface for a back-end service such as a database. It is a Web server that handles Web page requests from users. A SharePoint farm can use multiple WFE servers and a Network Load Balancer (NLB) to distribute requests for scalability and redundancy.

(11)

Chapter 2 Microsoft Applications Solution

Architecture

Overview ...12 Key components ...14 Software resources ...15

(12)

Overview

This Federation Enterprise Hybrid Cloud for Microsoft Applications solution provides the following application-specific functionality, in addition to the core Federation Enterprise Hybrid Cloud functionality:

• Automated deployment, management, and protection of Microsoft applications

• Application monitoring during the application lifecycle

• Database as a service for Microsoft SQL Server (see Chapter 7)

Figure 1 shows the architecture of the solution, which is deployed on a Federation Enterprise Hybrid Cloud platform and uses the Federation Enterprise Hybrid Cloud components outlined in Key components. The solution adds VMware vRealize Hyperic, a component of vRealize Operations™, to monitor metrics specifically related to Exchange Server, SQL Server, and SharePoint Server.

Figure 1. Federation Enterprise Hybrid Cloud reference architecture

(13)

The management, network, and tenant resources for the solution are divided into several pods, as shown in Figure 1, with each pod performing a solution-specific function:

• Core Pod

The Core Pod hosts a core set of resources that must exist before the remainder of the cloud can be deployed. These core resources include VMware vCenter Server™, Microsoft SQL Server 2012, and VMware NSX Manager™.

• Automation Pod

The Automation Pod hosts the virtual machines that automate and manage the cloud infrastructure that supports the workloads consumed by the clouds tenants. The Automation Pod supports the components responsible for functions such as the user portal and automated provisioning, monitoring, metering, and reporting.

• NEI Pod

The NEI Pod hosts the VMware NSX Edge™ appliances and VMware NSX Controller™

nodes and becomes the convergence point at which the physical and virtual networks connect.

• Workload Pods

The Workload Pods are configured and assigned in vRealize Automation as shared resources, to host application virtual machines deployed by the different business groups in the hybrid cloud environment. These Workload Pods are deployed as VMware vSphere clusters in VMware vCenter endpoints.

vRealize Application Services automates application provisioning in the Federation Enterprise Hybrid Cloud, including deploying, configuring, and updating the application's components and dependent middleware platform services. This simplifies complex deployments of both custom and packaged applications.

vRealize Application Services enables you to construct application blueprints for rapid deployment of Microsoft applications on a Federation Enterprise Hybrid Cloud. These application blueprints are created in Application Services and published to the vRealize Automation service catalog. The published blueprints contain virtual machine deployment information, as well as application deployment information and ancillary scripts for deploying services to a virtual machine (Hyperic agents, for example).

Virtual machine and application blueprints can apply to single systems or multiple systems, covering both bare-metal server deployments and virtual machine deployments. From predefined blueprints, you can easily deploy multitier enterprise applications that require multiple application, database, and web components, and related services.

VMware vRealize Hyperic is a component of the VMware vRealize Operations Management Suite. It monitors operating systems, applications, and services running in physical, virtual, and cloud environments. vRealize Hyperic offers the unique ability to automatically discover, inventory, and monitor servers, regardless of type or location, and enables application operations teams to ensure that business-critical applications run without fail.

The integration of vRealize Hyperic with vRealize Operations Manager provides a single UI for monitoring a wide range of metrics relating to the availability and use of Microsoft applications. The Management Pack for vRealize Hyperic provides metrics reports specific to Microsoft applications in vRealize Operations Manager.

VMware vRealize Application Services

VMware vRealize Hyperic

(14)

Key components

This Microsoft applications solution uses the following components of the Federation Enterprise Hybrid Cloud:

Note: For an overview of these components, refer to the Federation Enterprise Hybrid Cloud 3.1: Foundation Infrastructure Reference Architecture Guide.

Data center virtualization and cloud infrastructure

• VMware vSphere^® ESXi™ and VMware vCenter Server

• VMware vRealize Suite including:

 VMware vRealize Automation (vRA)

 VMware vRealize Automation Application Services

 VMware vRealize Operations Manager™

 VMware vRealize Configuration Manager™

 VMware vRealize Business Standard

 VMware vRealize Log Insight™

• VMware vCenter™ Orchestrator™

• VMware NSX™ for vSphere or VMware vCloud^® Networking and Security™ networking EMC storage services

• EMC^® ViPR^® software-defined storage

• EMC VNX^®, EMC VMAX^®, EMC ScaleIO^®, EMC VPLEX^®, EMC Isilon^®, and EMC XtremIO™ storage platforms—this guide discusses VNX and VMAX only

• EMC ViPR SRM

• EMC PowerPath^®/VE Data protection

• EMC RecoverPoint^®

• VMware vCenter Site Recovery Manager™

• EMC Avamar^® and EMC Data Domain^® data protection platforms

• EMC Data Protection Advisor™

Data protection for Microsoft applications is discussed in a separate document.

Figure 2 shows the key components of the Federation Enterprise Hybrid Cloud, with Exchange Server, SQL Server, and SharePoint Server deployed on the IT-as-a-service platform.

(15)

Figure 2. Federation Enterprise Hybrid Cloud solution components

Software resources

Table 2 lists the application software components and supporting services specific to this Federation Enterprise Hybrid Cloud for Microsoft Applications solution. For a complete list of Federation Enterprise Hybrid Cloud 3.1 software requirements, refer to the relevant EMC E- Lab EMC Simple Support Matrix at elabnavigator.emc.com.

Solution software requirements Table 2.

Software Version Notes

Microsoft Windows Server 2008 R2, 2012, and 2012 R2 Supported operating systems

Microsoft Exchange Server 2010 and 2013 Versions of Exchange Server supported in this solution Microsoft SharePoint Server 2010 SP2 and 2013 SP1 Versions of SharePoint Server supported in this

solution

Microsoft SQL Server 2008 R2, 2012, and 2014 Versions of SQL Server supported in this solution VMware vRealize Hyperic 5.8.4 A component of vRealize Operations used in this

solution

(16)

Chapter 3 Provisioning Microsoft Applications

Overview ...17

Publishing application blueprints ...23

Service catalog ...25

Approval policies ...27

Storage service offerings...28

Provisioning Microsoft Active Directory services ...30

Provisioning Microsoft Exchange...30

Provisioning Microsoft SQL Server ...35

Provisioning Microsoft SharePoint Server ...39

(17)

Overview

This chapter describes how to provision Microsoft applications on a Federation Enterprise Hybrid Cloud.

The Federation Enterprise Hybrid Cloud provides a foundation for successful and consistent deployments of Microsoft applications. Generic blueprints are available for each application;

these can be adapted for specific organizational requirements to guarantee a standard industry level of service. This chapter describes the high-level process and methodology required to successfully deploy the applications by using vRealize Application Services with the vRealize Automation service catalog and the Federation Enterprise Hybrid Cloud self- service portal. Figure 3 illustrates the workflow used in this solution for each of the Microsoft applications deployed.

Figure 3. Workflow for publishing vRealize Application Services blueprints

VMware vRealize Application Services

In VMware vRealize Application Services, an application blueprint defines the logical topology of an application for deployment in a virtual cloud. The blueprint captures the structure of an application with logical nodes, their corresponding services and operating systems,

dependencies, default configurations, and network and storage topology requirements. You can create an application blueprint after certain required elements are established on vRealize Application Services. The required elements include a vRealize Automation blueprint, a cloud provider, a deployment environment, one or more logical templates, and the services that contain the scripts necessary to install, customize, update, and

decommission the application.

(18)

Enterprise Hybrid Cloud. The blueprints are easily transportable across Federation Enterprise Hybrid Cloud environments. You can create application blueprints for each application and set of business requirements. You can then either deploy the blueprints directly from vRealize Application Services or publish them to a specific business group in the vRealize Automation service catalog so that users can request them through the Federation Enterprise Hybrid Cloud self-service portal.

For Microsoft application deployments, users can request multiple versions of Exchange Server, SQL Server, SharePoint Server, from the self-service portal. Application-related parameters can be modified prior to submitting the request.

In vRealize Application Services, you can download published application blueprints from the VMware Cloud Management Marketplace on VMware Solution Exchange (VSX) and import them into Application Services. For more information, visit the VMware Cloud Management Marketplace.

Microsoft application blueprints imported from the Marketplace provide preconfigured services and scripts for installing and customizing applications in a Federation Enterprise Hybrid Cloud environment. Figure 4 shows some of the available blueprints and services.

Blueprints imported from the Marketplace can be customized to meet the requirements of the application and the business.

Figure 4. VMware Cloud Management Marketplace blueprints

Note: For this solution, we imported and customized some application blueprints from the Marketplace. We designed and created others specifically for the solution. Application blueprints designed for and provided with this solution are not available on the VMware Cloud Management Marketplace. Contact your EMC representative for information.

To enable application blueprints to be published to a particular business group in vRealize Automation, a cloud provider must be registered on vRealize Application Services for that business group, as shown in Figure 5. The cloud provider enables vRealize Application Services to communicate with vRealize Automation.

VMware Cloud Management Marketplace

Cloud providers

(19)

Figure 5. Adding a cloud provider

After a cloud provider is created for a specific business group, vRealize Automation blueprints can be added to that cloud provider and then to a logical template, as shown in Figure 6.

Figure 6. Blueprints and logical templates added to a cloud provider in vRealize Application Services

vRealize Automation blueprints define important parameters such as the minimum and maximum CPU size and memory. They can also specify a reservation policy, though this can alternatively be specified in a deployment environment in vRealize Application Services.

vRealize Automation blueprints also identify the virtual machine templates used for vRealize

Automation blueprints

(20)

use a Windows 2012 virtual machine template, and minimum and maximum values are set for the CPU and Memory parameters.

Figure 7. Configuring parameters for a vRealize Automation blueprint

Before application blueprints can be published from vRealize Application Services to vRealize Automation, a deployment environment must be configured. A deployment environment maps to one or more reservation policies in vRealize Automation, as shown in Figure 8.

Figure 8. Deployment environment

Application architect roles manage the deployment design in vRealize Application Services.

These roles then publish application blueprints to vRealize Automation for deployment to meet business requirements. Specific users within business groups (for example, finance or HR) can be given permission to request application deployments from the vRealize

Automation service catalog. These requests are then approved or denied by the application owners.

Deployment environments

Application owners and business groups

(21)

A logical template is a predefined virtual machine definition in vRealize Application Service.

It can be mapped to an actual cloud template and supported services in the cloud library.

Logical templates enable application blueprints to remain cloud agnostic.

The logical template specifies a supported operating system version to ensure that only supported services can be used when constructing an application blueprint. You can add services to a logical template when building the template. Alternatively, you can add services when designing the application blueprint. Multiple vRealize Automation blueprints can be added to one logical template. This allows application blueprints to be published with different reservation policies.

In vRealize Application Services, a service is scripted software that runs on a virtual machine during deployment. A service can include scripts created with Windows PowerShell, the Windows Command Prompt, or the Linux Bash shell. Similar to building a logical template, tags and a supported operating system version are required when creating a service. The same service can house multiple scripts—for example, an application installation script, an application configuration script, and an application update script.

Services are a fundamental element in creating application blueprints with vRealize Application Services. They are available for reuse and selection during the application blueprint creation process, as shown in Figure 9.

Administrators can add properties to a service and predefine the property values. They can also mark properties as Overridable so that users can override the property values when deploying a catalog item from the self-service portal. Property values set by the user are specific to the deployed application. Figure 9 shows the Overridable option set for several properties in a service.

Figure 9. Example of a service in vRealize Application Services

When Microsoft applications are implemented, the scripts contained in associated services run automatically after the virtual machine is deployed. A number of services can be added to a single application blueprint and a service installation order can be specified across multiple virtual machines in the blueprint.

Logical templates

Services in vRealize Application Services

(22)

An application blueprint can be created after the required elements, such as a deployment environment, logical templates, and services, are established on vRealize Application Services, as shown in Figure 10. Tags are added to an application blueprint to indicate the type of service it defines and the category in which to list the service.

Figure 10. Creating an application blueprint

vRealize Application Services provides a drag-and-drop GUI for creating application blueprints. Users select and position logical templates on a blank canvas and drag services and application components into the logical templates. Depending on the application requirements, multiple logical templates can be added and clustered. Figure 11 shows an example of a completed application blueprint where components have been dragged from the Logical Templates and Services menus to create a reusable Microsoft application blueprint that can be deployed into the Federation Enterprise Hybrid Cloud.

Figure 11. Drag-and-drop GUI in vRealize Application Services

Figure 11 also shows how you can edit the compute resources and host name for a blueprint in Application Services. Depending on your requirements, the host name can be assigned randomly on each execution of a blueprint by specifying ${random}. After the application blueprint is created, it is ready to be published to the required business unit on vRealize Automation. Users can then request the Microsoft application deployment from the vRealize Automation service catalog via the Federation Enterprise Hybrid Cloud self-service portal.

Application blueprints

(23)

Publishing application blueprints

After application blueprints are imported or created in vRealize Application Services, they can be published to the vRealize Automation service catalog. Figure 12 shows the Deploy option used to initiate the publishing process.

Figure 12. Publishing application blueprints to vRealize Automation

During the publishing process, you have several opportunities to customize the application blueprint:

• You can use the Map Details option to ensure correlation between vRealize

Application Services logical templates and vRealize Automation blueprints, as shown in Figure 13.

Figure 13. Mapping template details during the blueprint publishing process

• You can select a default logical network or specify a cloud network for the deployment.

• You can change the value of service properties that are specified as Overridable in the application blueprint, as shown in Figure 14.

(24)

Figure 14. Editing service properties during blueprint publishing

• You can modify the compute resources to ensure that the Microsoft application is deployed on virtual machines that meet the performance requirements of a particular business group. The ability to edit the compute resources during publishing enables the same application blueprint to be published with different specifications.

• You can review the execution plan to ensure that the implementation sequence deploys the correct application services in the correct order, as shown in Figure 15.

Figure 15. Reviewing the deployment plan during blueprint publishing

As shown in Figure 16, the final step in the publishing process is to review all application related properties and click Publish. The name and description of the item are then published and the item is ready to add to the vRealize Automation service catalog.

Figure 16. Reviewing and publishing the application blueprint

Application blueprints that are published from Application Services into vRealize Automation are automatically activated. However, they are not visible in the service catalog until they are added to an applicable active service with configured entitlements and actions.

(25)

Service catalog

The vRealize Automation service catalog lists the catalog items that an end user, application owner, or business group can request. After a request is approved, the application virtual machine is deployed and the owner is notified. Figure 17 shows examples of published applications in the service catalog for this solution.

Figure 17. Viewing the vRealize Automation service catalog

Figure 18 shows a subset of the catalog items for SQL Server 2014—these include multiple deployments with varying storage offerings. The SQL Server with AlwaysOn service includes items for SQL Server 2012 and 2014 with AlwaysOn Availability Groups.

Figure 18. Viewing the vRealize Automation service catalog for SQL Server 2014

(26)

Entitled users or groups can activate and deactivate services in vRealize Automation, as shown in Figure 19. Activated services appear in the service catalog to users with the appropriate entitlements. Selecting a service displays the catalog items associated with that service.

Figure 19. Viewing vRealize Automation services

In this Federation Enterprise Hybrid Cloud for Microsoft Applications solution, all catalog items are published from vRealize Application Services. All catalog items are linked to a service, as shown in Figure 20.

Figure 20. Managing vRealize Automation catalog items

vRealize Automation actions enable administrators to specify which actions users can perform for a particular catalog item, as shown in Figure 21. This helps to control the level of actions that users can perform. For example, an administrator might want to prevent a user from being able to destroy a virtual machine, as specified by the business unit.

vRealize Automation services

vRealize Automation catalog items

vRealize Automation actions

(27)

Figure 21. Viewing vRealize Automation catalog item actions

Entitlements in vRealize Automation control which users or groups have access to particular catalog items, as shown in Figure 22. They ensure that only specified users can request specific deployments. For example, administrators can specify that only SQL Server application owners can view and select SQL Server catalog items.

Figure 22. Viewing vRealize Automation entitlements

Approval policies

After entitlements have been assigned to users or groups, approval policies can be created and edited in vRealize Automation and applied to particular catalog items. After an approval policy is applied to a catalog item, designated approvers receive an approval email

whenever a request is submitted. The approver can then either approve or reject the request, with a justification message. The deployment proceeds after the request has been approved.

Implementing approval processes provides essential control over enterprise application deployments and provides important governance over Federation Enterprise Hybrid Cloud environments.

A wide range of approval policy types are available. Approvals can be configured so that a single approver or multiple approvers are required for deployments. Figure 23 shows an example of an approval request sent to an approver.

vRealize Automation entitlements

(28)

Figure 23. Approving or rejecting a request

Storage service offerings

The Microsoft applications deployed in this solution take advantage of the various storage service offerings within the Federation Enterprise Hybrid Cloud. The applications are provisioned on storage services that meet the particular workload requirements of SQL Server, SharePoint Server, and Exchange Server.

In vRealize Application Services, separate deployment environments can be created with separate reservations on vRealize Automation, as described in Deployment environments on page 20. When publishing an application blueprint, you can select a deployment

environment. The deployment environment ensures that the application is provisioned on the storage service offering with which the deployment environment is associated.

Alternatively, as described in VMware vRealize Application Services, you select a vRealize Automation blueprint (as a logical template) when creating an application blueprint. The vRealize Automation blueprint contains multiple storage service offerings, such as SATA, all flash, and mixed storage services, as shown in Figure 24. When publishing the application blueprint, you select the storage service required for the catalog item you are creating. This enables different storage service offerings to be published from the same application blueprint, as shown in Figure 25.

Figure 24. Storage service offerings for application blueprints during the publishing process

When users request an application from the service catalog, they can select the catalog item that offers the appropriate storage service for the application. Figure 25 shows examples of catalog items for SQL Server 2014 with different storage service offerings.

(29)

Figure 25. Selecting a storage offering for SQL Server

In this solution, we implemented storage service offerings by using VMAX and VNX storage arrays. The solution also supports XtremIO storage. Storage service offerings can include a dedicated storage type or mixed storage. We created the following storage service offerings based on the requirements for each Microsoft application:

• Option 1—Extreme performance tier with all flash drives

• Option 2—Balanced capacity and performance tier with FC and SAS drives

• Option 3—Capacity tier with large SATA and NL-SAS drives

The ability to request a catalog item with the required storage service offering and compute resources ensures that applications can perform workloads with guaranteed input/output operations per second (IOPS). For example, we used the all-flash storage service for the SQL Server deployment to optimize performance, and we used the capacity storage service for the Exchange Server deployment to provide the required mailbox capacity and

performance.

With EMC array-based technologies such as EMC FAST Cache and EMC FAST VP, applications of varying I/O profiles can be added to storage services. These EMC storage service

offerings can include different disk technologies, and can promote and demote workloads to best serve the operating requirements of an application.

EMC ViPR is a key component of the Federation Enterprise Hybrid Cloud that centralizes and automates storage management on a single platform. Through the vRealize Automation service catalog, you can create volumes on ViPR and provision them to the required ESXi servers. The volumes are then used to make up reservations on vRealize Automation. This enables the storage services required for Microsoft applications to be assigned by a fully automated process.

Note: For more details on the storage offerings in the Federation Enterprise Hybrid Cloud, refer to the Federation Enterprise Hybrid Cloud 3.1: Concepts and Architecture Solution Guide.

(30)

Provisioning Microsoft Active Directory services

Cloud tenants require a Microsoft Active Directory infrastructure for successful deployments of Microsoft applications such as Exchange Server and SQL Server. Users need to provide information about their Active Directory infrastructure if it already exists. This information is necessary because these Microsoft applications are heavily integrated with Active Directory.

Alternatively, administrators can deploy a new Active Directory infrastructure as described in this section.

Users with the appropriate rights can choose to deploy and customize a Domain Controller to create an Active Directory domain before the application is provisioned. During deployment, the Domain Controller settings can be modified to specify an IP address, Domain Name, and administrator credentials. DNS can also be configured during Domain Controller deployment.

Provisioning a new Microsoft Active Directory Domain Controller includes the following tasks:

• Creating a Domain Controller application blueprint in vRealize Application Services

• Publishing the Application Services blueprint to vRealize Automation

• Configuring services and entitlements for the Active Directory service

To provision Microsoft Active Directory from the vRealize Automation service catalog:

1. Select a Domain Controller from the catalog and click Request, as shown in Figure 26.

Figure 26. Provisioning Microsoft Active Directory from vRealize Automation 2. Set the required property values and click Submit.

3. After the Domain Controller is deployed, record the IP address and host name;

these values are required when provisioning each Microsoft application.

Provisioning Microsoft Exchange

Microsoft Exchange Server application blueprints that are published from vRealize

Application Services facilitate the deployment of multiple editions of Exchange Server across any business group within an organization, whether the business group is a highly utilized production environment or a test and development unit. These editions can be provisioned easily and are ready for use within minutes of being requested.

The following are prerequisites for deploying Exchange from the Federation Enterprise Hybrid Cloud self-service portal:

• The Active Directory infrastructure with DNS services must exist before Exchange Server can be installed.

(31)

• The account used to perform the Exchange installation must have the rights necessary to make changes to the Active Directory schema. Refer to Microsoft Exchange Server documentation for further information.

The following options are currently available for provisioning Microsoft Exchange Server:

• Option 1 deploys a stand-alone Exchange Server virtual machine, with preconfigured CPU, memory, and storage resources for a specified number of users. Mailbox Server and Client Access roles are combined in this deployment.

• Option 2 deploys Exchange Server in a high-availability configuration as part of an Exchange database availability group (DAG), with preconfigured CPU, memory, and storage resources for a specified number of users. This option deploys two servers in a DAG with two database copies. Mailbox Server and Client Access roles are combined in this deployment.

• Option 3 deploys a new Exchange Server instance, with preconfigured CPU, memory, and storage resources, to an existing DAG. Mailbox Server and Client Access roles are combined in this deployment.

Note: This section describes Option 1. Option 2 is described in High Availability for Microsoft Applications on Federation Enterprise Hybrid Cloud. Option 3 is described in Elasticity for Microsoft Exchange.

The following Microsoft Exchange Server deployments are supported in this solution:

• Exchange Server 2010 Standard and Enterprise Editions on Windows Server 2012 and Windows 2008 R2

• Exchange Server 2013 Standard and Enterprise Editions on Windows Server 2012 and Windows Server 2012 R2

Note: If installing a Mailbox Server role as a member of a DAG, you must use Windows Server 2012 or 2012 R2. Windows Server 2008 R2 SP 1 Standard Edition does not support the features needed for DAGs.

To provision a stand-alone Exchange Server virtual machine on the Federation Enterprise Hybrid Cloud, the application architect must first configure the application blueprint in vRealize Application Services. The application blueprint consists of a virtual machine template with services and custom scripts to automatically provision Exchange Server, as shown in Figure 27. In this solution, the stand-alone deployment option combines the Exchange Mailbox Server and Client Access roles on one server. For larger configurations, you can deploy separate servers to host each role.

Exchange Server application blueprints

(32)

For the solution, we created the installation and customization scripts with Microsoft Windows PowerShell. Figure 28 shows the properties we created for services in the

application blueprint, including the organization name, the administrator credentials, and the source location for the installation files.

Note: You can customize and reuse installation scripts for multiple blueprints.

Figure 28. Properties and actions for an Exchange Server 2013 application blueprint Table 3 provides details some of the service properties that can be configured in an application blueprint for Exchange Server. Other properties can be added as required.

Exchange 2013 service property values Table 3.

Property name Blueprint property value example Description

Domain exlab.local The Active Directory domain to which

Exchange Server is joined

UserName Administrator Domain user account with administrator rights to install Exchange

Password Password User account password

SetupEXEpath c:\software\Exchange Path to the folder containing the setup.exe file for the Exchange Server installation

OrganizationName Exchange Exchange organization name

After an Exchange Server application blueprint has been created, it can be published to vRealize Automation, as described in Publishing application blueprints. Entitlements and approval policies can then be configured for the catalog item. Implementing an approval process for an Exchange Server deployment helps to guarantee that the application is deployed based on the best practices within an enterprise.

Figure 29 shows an example of a vRealize Automation service catalog that includes various items for deploying Exchange Server. The catalog items that are visible and available to a user depend on the user’s assigned permissions.

Requesting an Exchange Server virtual machine

(33)

Figure 29. Viewing service catalog items for Exchange

When users initiate a request, they are prompted for a description and a reason for the deployment. The requester then has the option to modify the compute resources and the Exchange Server virtual machine hostname, as shown in Figure 30.

Figure 30. Modifying Exchange Server node properties during deployment

The requester can also edit the service properties specific to the Exchange Server instance and domain, as shown in Figure 31, if the properties are specified as Overridable in the application blueprint.

(34)

Figure 31. Viewing application parameters for Exchange Server

After the user submits the request, the deployment begins. The user can view the status of the request in the Requests tab in vRealize Automation. When the deployment is complete, the state of the request changes from In Progress to Successful, as shown in Figure 32, and the user also receives a notification email. If the deployment includes an approval process, the request remains in a Pending Approval state until approved.

Figure 32. Confirming a successful Exchange Server deployment

vRealize Automation provides several ways to view details of the deployment. Figure 33 shows the Items > Application Deployments option.

Figure 33. Viewing a provisioned Exchange Server application deployment

(35)

To verify that the requested Exchange Server catalog item was deployed correctly, the Exchange Server administrator can log in to the Exchange admin center and view details of the deployed server there, as shown in Figure 34.

Figure 34. Verifying an Exchange Server deployment

Provisioning Microsoft SQL Server

Microsoft SQL Server application blueprints that are published from vRealize Application Services facilitate the deployment of multiple editions of SQL Server across any business group in an organization, whether the business group is a highly utilized production environment or a test and development unit. These editions can be provisioned easily and are ready for use within minutes of being requested.

The following options are currently available for provisioning Microsoft SQL Server:

• Option 1 deploys a stand-alone SQL Server instance, with configurable CPU, memory, and storage resources for a specified number of users.

• Option 2 deploys SQL Server in a high-availability configuration as part of a SQL Server AlwaysOn Availability Group, with configurable CPU, memory, and storage resources for a specified number of users.

Note: This section describes Option 1. Option 2 is described in High Availability for Microsoft Applications on Federation Enterprise Hybrid Cloud.

The following Microsoft SQL Server deployments are supported in this solution:

• SQL Server 2008 R2 Enterprise, Standard, and Express Editions on Windows 2008 R2

• SQL Server 2012 Enterprise, Standard, and Express Editions on Windows 2012 and Windows 2012 R2

Verifying an Exchange Server deployment

(36)

To provision a stand-alone SQL Server instance on the Federation Enterprise Hybrid Cloud, the application architect must first configure the application blueprint in vRealize Application Services. The application blueprint consists of a virtual machine template with services and custom scripts to automatically provision SQL Server.

For the solution, we created the installation and customization scripts with Microsoft Windows PowerShell. Figure 28 shows some of the properties we created for services in the SQL Server application blueprint. The service properties are used to create and build a SQL Server configuration file, which is then used to customize the installation.

Figure 35. Viewing properties and actions for a SQL Server application blueprint Table 4 provides details of some of the service properties that can be configured in an application blueprint for SQL Server. Other properties can be added as required.

SQL Server service property values Table 4.

Property name Blueprint value example Description

Domain msapps.com The Windows domain name

User Administrator Domain user account with administrator rights to

install SQL Server

Password Password User account password

Install_repository \\IP of Repository

Server\Software\SQL2014\Enterprise Location of the SQL Server installation files, which can be automatically downloaded from a central repository during deployment or stored in the virtual machine template

SYSADMIN_ACCOUNT SQL The Windows groups or individual accounts to

add to the sysadmin fixed server role

SA_PWD Password The password for the SQL Server sa account

SQL Server application blueprints

(37)

Instance name Production The name of SQL Server instance

User connections 4 The maximum number of simultaneous user

connections that are allowed on an instance of SQL Server

REMOTE_LOGIN_TIME

OUT 10 The number of seconds to wait before returning

from a failed login attempt to a remote server

After a SQL Server application blueprint has been created, it can be published to vRealize Automation, as described in Publishing application blueprints. Entitlements and approval policies can then be configured for the catalog item. Implementing an approval process for a SQL Server deployment helps to guarantee that the application is deployed based on the best practices within an enterprise.

Figure 36 shows an example of a vRealize Automation service catalog that includes various items for deploying SQL Server. The catalog items that are visible and available to a user depend on the user’s assigned permissions.

Figure 36. Viewing service catalog items for SQL Server

When users initiate a request, they are prompted for a description and a reason for the deployment. The requester then has the option to modify the compute resources and the SQL Server virtual machine hostname, as shown in Figure 37.

Requesting a SQL Server virtual machine

(38)

The requester can also edit the SQL Server service properties, as shown in Figure 38, if the properties are specified as Overridable in the application blueprint.

Figure 38. Specifying service properties for SQL Server

After the user submits the request, the deployment begins. The user can view the status of the request in the Requests tab in vRealize Automation. When the deployment is complete, the state of the request changes from In Progress to Successful, as shown in Figure 39, and the user also receives a notification email. If the deployment includes an approval process, the request remains in a Pending Approval state until approved, as shown in Figure 40.

Figure 39. Confirming a successful SQL Server deployment

Figure 40. Viewing the approval status of requests for SQL Server

vRealize Automation provides several ways to view details of the deployment. Figure 41 shows the Items > Application Deployments option.

Figure 41. Viewing a provisioned SQL Server application deployment

(39)

To verify that the requested SQL Server catalog item was deployed correctly, a SQL Server user can connect to the virtual machine and use Microsoft SQL Server Management Studio (SSMS) to view details of the SQL Server instance that was created, as shown in Figure 42.

(SSMS was installed during the deployment process for this solution.)

Figure 42. Verifying a SQL Server deployment

Provisioning Microsoft SharePoint Server

Microsoft SharePoint Server application blueprints that are published from vRealize Application Services facilitate the deployment of multiple editions of SharePoint Server across any business group within an organization, whether the business group is a highly utilized production environment or a test and development unit. These editions can be provisioned easily and are ready for use within minutes of being requested.

The following Microsoft SharePoint deployments are supported for this solution:

• SharePoint Server 2010 on Windows Server 2008 R2

• SharePoint Server 2013 on Windows Server 2012 and Windows Server 2012 R2

To provision a SharePoint Server virtual machine on the Federation Enterprise Hybrid Cloud, the application architect must first configure the application blueprint in vRealize Application Services. The application blueprint consists of a virtual machine template with services and custom scripts to automatically provision and configure new SharePoint Server virtual machines. SharePoint Server is pre-installed on the template virtual machine.

Figure 43 shows a SharePoint Server 2010 application blueprint in vRealize Application Services and some of the properties we configured for services in the blueprint.

Verifying a SQL Server

deployment

SharePoint Server application blueprints

(40)

Figure 43. SharePoint service properties in the SharePoint blueprint

Table 5 provides details of some of the service properties that can be configured in an application blueprint for SharePoint Server. Other properties can be added as required.

SharePoint Server service property values Table 5.

Domain None Location of the SharePoint

installation files

Sitename SharePoint site name Site name

DomainAccountUsername Domain user Domain account that will administer the SharePoint farm DomainAccountPassword Password SharePoint Administrator (domain

account) password

Port 7001 SharePoint application connection

port

After a SharePoint Server application blueprint has been created, it can be published to vRealize Automation, as described in Publishing application blueprints. Entitlements and approval policies can then be configured for the catalog item. Implementing an approval process for a SharePoint Server deployment helps to guarantee that the application is deployed based on the best practices within an enterprise.

(41)

Figure 44 shows an example of a vRealize Automation service catalog that includes various items for deploying SharePoint Server. The catalog items that are visible and available to a user depend on the user’s assigned permissions.

Figure 44. Viewing service catalog items for SharePoint Server

When users initiate a request, they are prompted for a description and a reason for the deployment. The requester then has the option to modify the compute resources and the SharePoint Server virtual machine hostname, as shown in Figure 45.

Figure 45. Modifying SharePoint Server node properties during deployment

The requester can also edit the service properties specific to the SharePoint Server instance and domain, as shown in Figure 46, if the properties are specified as Overridable in the application blueprint.

Requesting a SharePoint Server virtual machine

(42)

After the user submits the request, the deployment begins. The user can view the status of the request in the Requests tab in vRealize Automation. When the deployment is complete, the state of the request changes from In Progress to Successful, and the user also receives a notification email. If the deployment includes an approval process, the request remains in a Pending Approval state until approved.

vRealize Automation provides several ways to view details of the deployment. Figure 47 shows the Items > Machines option.

Figure 47. Viewing a provisioned SharePoint application deployment

To verify that the requested SharePoint Server catalog item was deployed correctly, the SharePoint administrator can log in to the SharePoint Central Admin on the virtual machine and view details of the SharePoint farm there.

After verifying the deployment, the SharePoint Administrator can log in to the newly created SharePoint site to perform final site configuration. For example, the administrator must select the appropriate template for the type of SharePoint site being created. The template determines the type of site and the features that will be available on the site. Figure 48 shows an example of template selection for a Human Resources site. Figure 49 shows the permissions configured for the site.

Verifying a SharePoint deployment

Configuring the SharePoint farm

(43)

Figure 48. Selecting a SharePoint template

Figure 49. SharePoint site permissions

(44)

Chapter 4 High Availability for Microsoft

Applications on Federation Enterprise

Hybrid Cloud

Overview ...45 vSphere High Availability ...45 Microsoft Exchange DAG ...45 Microsoft SQL Server with AlwaysOn Availability Groups ...49 Microsoft SharePoint availability ...52

(45)

Overview

When enterprise applications are deployed in a hybrid cloud, application administrators want to maintain application performance and high availability by following application design best practices. Microsoft applications deployed on the Federation Enterprise Hybrid Cloud are protected at multiple levels with this solution. VMware vSphere High Availability (HA) provides crash-consistent protection at the virtual machine level. Native application features such as Exchange Server DAGs and SQL Server AlwaysOn Availability Groups (AAG) provide consistent application protection. At the infrastructure level, EMC storage automatically protects data and VMware NSX provides network redundancy.

This chapter describes how to set up this solution for virtual machine and application protection with high availability.

vSphere High Availability

VMware vSphere delivers the high availability required by most applications running in virtual machines, independently of the operating system and application. vSphere HA provides uniform, cost-effective failover protection against hardware and operating system outages within a virtualized IT environment.

vSphere HA monitors VMware vSphere hosts and virtual machines to detect hardware and guest operating system failures. It can restart virtual machines on other vSphere hosts in the cluster without manual intervention when a server outage is detected. It can also automatically restart virtual machines when an operating system failure is detected, thereby reducing application downtime.

Microsoft Exchange DAG

A database availability group (DAG) is a high availability (HA) and data recovery feature introduced in Exchange Server 2010. A DAG is a group of Exchange Mailbox servers

(maximum 16) that provides automatic database-level recovery from a database, server, or network failure. A DAG provides a failover cluster solution for non-shared storage and uses asynchronous log shipping technology to distribute and maintain passive copies of each database in the DAG. When a new Mailbox server is added to a DAG, it works with the other servers in the DAG to provide automatic, database-level recovery from database, server, and network failures. DAGs can be extended to multiple sites to provide resilience against data center failures. Figure 50 shows the basic architecture of a DAG.

Figure 50. Exchange Server database availability group

(46)

A DAG provides the high availability required for most deployments. However, if hardware failures occur, use of the remaining Exchange Client Access servers can increase as new connections are established, and DAG protection is reduced as passive databases are activated. In a vSphere deployment, vSphere HA automatically powers virtual machines back on when a hardware failure occurs, restoring availability levels quickly and maintaining balanced server usage. This section provides recommendations and directions for using vSphere HA with Exchange Server.

In a physical environment, DAGs are often deployed with three or more database copies to provide protection in case of hardware failures. This level of protection introduces the additional overhead of managing multiple database copies. Virtualized Exchange Server environments are typically designed with only two database copies, and use vSphere HA and RAID storage to protect from hardware and storage failures. vSphere HA restarts a DAG member if the host experiences a hardware failure, and RAID protects databases from storage failure.

When enabling a vSphere cluster for HA to protect DAG members, consider the following best practices:

• Members of the same DAG should not reside on the same vSphere host for an extended period when databases are symmetrically distributed between members.

Allowing two members to run on the same host for a short period (for instance, after a vSphere HA event) enables database replication to resume. However, DAG members should be separated as soon as the ESXi host has been restored.

• To adequately protect from an extended server outage, vSphere clusters should be deployed in an N+1 configuration, where N is the number of DAG members. If a hardware failure occurs, causing vSphere HA to power on a failed DAG member, the DAG maintains the same level of protection at all times.

• Use anti-affinity rules to keep DAG members separated. vSphere HA might violate a rule during a power-on operation caused by a host failure, but VMware vSphere Distributed Resource Scheduler™ (vSphere DRS) fixes the violation during the next interval, as described in vSphere DRS and anti-affinity rules for Exchange Server virtual machines.

Note: For this solution, we used the vSphere Web Client to manually configure anti-affinity rules after the Exchange virtual machines were deployed.

vSphere DRS provides active monitoring and load balancing of virtual machine workloads within a vSphere cluster to deliver a more agile virtualized Exchange Server environment.

vSphere DRS provides rules for keeping virtual machines apart or together on the same ESXi host or group of hosts. In an Exchange Server environment, anti-affinity rules are used to ensure that Exchange Server virtual machines with the same roles are installed apart from each other. Client Access servers in a Client Access Server (CAS) array can run on the same ESXi host, but you should use DRS rules to prevent all CAS virtual machines from running on a single ESXi host.

Microsoft recommends symmetrically distributing mailbox databases among DAG members.

Unlike traditional active/passive configurations, this design enables all DAG members to support active users and also reserves a portion of compute power for failover capacity. If a single DAG member fails, all remaining members might take part in supporting the failed databases. Because of this, VMware recommends that no two members of the same DAG run on the same ESXi host for an extended period.

Anti-affinity rules enforce virtual machine separation during power-on operations and vSphere vMotion migrations, including when a host is entering maintenance mode. If a virtual machine is enabled for vSphere HA and a host failure occurs, vSphere HA might power on a virtual machine and, in effect, violate a DRS anti-affinity rule. This occurs vSphere HA with

Exchange Server DAG

vSphere DRS and anti-affinity rules for Exchange Server virtual machines

FEDERATION ENTERPRISE HYBRID CLOUD 3.1 Microsoft Applications Solution Guide