Análisis de ventas y compras (Pareto año 2017) Tabla 3.3 Análisis de ventas y compras año 2017

This chapter presents the following topics:

Overview ... 68 High availability ... 68 Microsoft Exchange DAG ... 68 Microsoft SQL Server with AAG ... 73 Microsoft SharePoint availability ... 76

Chapter 4: High Availability for Microsoft Applications on EMC Hybrid Cloud

Overview

When enterprise applications are deployed in a Hybrid Cloud, application

administrators want to maintain application performance and high availability by following application design and best practices.

Microsoft applications on EMC Hybrid Cloud with VMware are protected at multiple levels with this solution. The first level of protection is virtual machine protection with VMware vSphere High Availability, which provides crash-consistent, virtual machine- level protection for applications.

The next level of protection is consistent application protection, such as Exchange DAG and SQL Server AlwaysOn Availability Groups. At the lower 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.

High availability

VMware vSphere delivers the high availability (HA) required by most applications running in virtual machines, independent of the operating system and applications. HA provides uniform, cost-effective failover protection against hardware and

operating system outages within a virtualized IT environment.

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

Microsoft Exchange DAG

Microsoft Exchange 2013 environments are built for HA. In large deployments, client access servers can be deployed in arrays that are load balanced. Exchange Mailbox Servers are usually deployed in a Database Availability Group (DAG) for HA.

A DAG is a group of Exchange Mailbox Servers that provides automatic database-level recovery from a database, server, or network failure. A DAG provides a non-shared storage failover cluster solution and uses asynchronous log shipping technology to distribute and maintain passive copies of each database in the DAG. DAGs can be extended to multiple sites to provide resilience and prevent datacenter failures. A DAG with HA ultimately provides the availability required for most deployments. However, if hardware failures occur, utilization of the remaining client access servers can increase as new connections are established, and DAG protection is reduced as passive databases are activated. In physical deployments, administrators must address problems quickly to restore availability levels and mitigate any further outages. With a vSphere infrastructure, a hardware failure results in virtual machines powered back on by vSphere HA, restoring availability levels quickly and keeping

utilization balanced. This chapter provides recommendations for using vSphere HA with Exchange 2013.

In a physical environment, DAGs are often deployed with three or more database copies to protect from hardware and disk failures. In these environments, when a physical server or storage component fails, the DAG is still protected with the multiple database copies. This protection requires the overhead of managing those multiple database copies. Virtualized Exchange environments are typically designed with two database copies to utilize vSphere HA and RAID to protect from hardware and storage failures. vSphere HA restarts a DAG member if the host has 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 of time when databases are symmetrically distributed between members. Allowing two members to run on the same host for a short period of time (for instance, after a vSphere HA event) does enable 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 designed 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 this rule during a power-on operation (one caused by a host failure), but DRS fixes the violation during the next interval. Refer to Anti-Affinity rules for Exchange virtual machines for more details.

Note: Anti-affinity rules were configured manually, using the vSphere Web Client after Exchange virtual machines were deployed.

Distributed Resource Scheduling (DRS) provides active load balancing of virtual machine workloads within a vSphere cluster. In addition to active monitoring and load balancing functions, DRS helps make a virtualized Exchange 2013 environment more agile. The following sections provide recommendations for using DRS with Exchange 2013.

DRS provides rules for keeping virtual machines apart or together on the same ESXi host or group of hosts. In an Exchange environment, the common use case for anti- affinity rules is to keep Exchange virtual machines with the same roles installed apart from each other. Client Access servers in a CAS array can run on the same ESXi host, but DRS rules should be used 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 allows all DAG members to support active users as well as reserve a portion of compute power for

vSphere HA with Exchange DAGs vSphere DRS with Exchange DAG Anti-Affinity rules for Exchange virtual machines

Chapter 4: High Availability for Microsoft Applications on EMC Hybrid Cloud

failover capacity. In the case of failure of a single DAG member, all remaining members might take part in supporting the failed databases. Because of this, it is recommended that no two members of the same DAG run on the same ESXi host for an extended period of time.

Because of a DRS rule, anti-affinity rules enforce virtual machine separation during power-on operations and vSphere vMotion migrations. This includes times 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 because vSphere HA does not inspect DRS rules during a recovery task. However, during the next DRS evaluation (set for every five minutes), the virtual machine is migrated to fix the violation. Figure 60 shows the Enable rule setting for the Anti-Affinity DRS rule for Exchange DAG servers.

Figure 60. Anti-Affinity DRS rule for Exchange DAG servers

For this solution, Microsoft Exchange high availability was achieved by deploying multiple servers in a DAG. Each mailbox server can have a copy of the database deployed on any server that is a member of the DAG.

With this solution, users can initially deploy a two-member DAG and later deploy additional servers to join the DAG.

The following is an example of how to deploy an Exchange 2013 Server in a DAG. These steps are similar to deploying an Exchange 2013 (stand-alone) blueprint:

1. _{In Application Director, select the Exchange 2013 DAG blueprint, as shown in} Figure 61.

Provisioning an Exchange DAG

Figure 61. Selecting an Exchange server blueprint from available Applications

2. _{Hover your cursor over the blueprint and click View Blueprint to view the} properties, as shown in Figure 62.

Figure 62. Viewing the application blueprint for an Exchange 2013 DAG

3. _{Select the template to view and edit the properties, such as the number of} CPUs and amount of memory, and then click Deploy in the upper right corner, as shown in Figure 63.

Table 5 lists the required blueprint property values for an Exchange DAG. These properties can then be edited to customize the installation of the Exchange DAG prior to requesting the application. During installation, users can change these properties, provided the properties are made overridable within the blueprint.

Chapter 4: High Availability for Microsoft Applications on EMC Hybrid Cloud

Table 5. Exchange DAG blueprint property values

Property Blueprint value example Description

Domain exlab.local Your Windows Domain

name

DAGIP 192.168.1.25 DAG IP address

DAGNAME DAG1 DAG Name

WitnessServer FSW-SRV File Share Witness

server

WitnessDirectory C:\FSW File Share Witness

server directory

User Administrator User account with

admin rights to perform Exchange installation

Password Password User account

password

DBNAME DB1 Database name

After the Exchange 2013 DAG application blueprint has been created, it can be published to vCAC. Refer to Publishing application blueprints for instructions.

Figure 64. Selecting and deploying the Exchange DAG template in the vCAC catalog

4. When prompted, set the required values, click Next, and then click Submit to finalize your request.

Microsoft SQL Server with AAG

The AlwaysOn Availability Groups feature is a high-availability and disaster-recovery solution that provides an enterprise-level alternative to database mirroring.

Introduced in SQL Server 2012, AlwaysOn Availability Groups maximizes the

availability of a set of user databases for an enterprise. An availability group supports a failover environment for a discrete set of user databases, known as availability databases which fail over together. An availability group supports a set of read-write primary databases and one to eight sets of corresponding secondary databases. Optionally, secondary databases can be made available for read-only access and/or some backup operations.

SQL Server Always-On Availability Group (AAG) deployment is an option in the Service Catalog that can be requested by the user, as shown in Figure 65.

Provisioning SQL Server 2012 AAG

Chapter 4: High Availability for Microsoft Applications on EMC Hybrid Cloud

Figure 66 shows the Catalog item that is published from vCloud Application Director.

Figure 66. Viewing the AAG application blueprint

Figure 67 shows more detail about the vCloud Application Director blueprint.

Figure 67. Viewing the AAG application blueprint description

Figure 68 shows the blueprint deployment of two SQL Server virtual machines with interrelated dependencies. The arrows show the first SQL Server virtual machine to join the domain and the second dependent SQL Server virtual machine to join. The installation of SQL Server 2012 and the creation of a failover cluster for AAG occur independently on each virtual machine.

The first SQL Server virtual machine creates a database. The SQL Agent script runs on the first SQL Server virtual machine and the dependent AAG script runs on the second SQL Server virtual machine. This completes the process required to create a full AAG deployment on two SQL Server virtual machines.

Application Director Blueprint for SQL Server AAG

Figure 68. Viewing AAG service dependencies

Figure 69 shows the server installation portion of the deployment plan (workflow) in Application Director. This is a different view of the workflow that shows each active task as it runs and completes.

Figure 69. Reviewing task execution workflow for AAG

After the workflow is run, the AAG is listed in SQL Server Management Studio, as shown in Figure 70. The SQL Server application is now protected from node failure and read-only copies can be used for backup purposes on the secondary copy. Each SQL Server virtual machine can also be configured to be on different datastores to improve redundancy.

Verifying SQL Server 2012 AAG deployment

Chapter 4: High Availability for Microsoft Applications on EMC Hybrid Cloud

Figure 70. Viewing the deployed Availability Replicas in SQL Server

Microsoft SharePoint availability

Microsoft SharePoint as a federated application has some built-in redundancy. For example, each farm can have multiple web front-ends (WFEs), so the failure of some WFEs does not lead to a farm outage or downtime for users. SharePoint Search can also be deployed redundantly (at least two copies of the Index and two copies of the Query role), so that the failure of one or more virtual machines in the farm does not cause down time.

The SQL Server back-end can be split among multiple smaller SQL Server virtual machines, so that at least some of the sites (ContentDBs) can remain available when a SQL Server is down. SQL Server AlwaysOn availability groups can also be used to protect the backend SQL Server.

All of these virtual machines are protected at another level by vSphere HA. Figure 71 shows that vSphere HA Protection is turned on for the ESX hosts that host the resources and virtual machines for EMC Hybrid Cloud. With this solution, SharePoint farm virtual machines are protected from ESX host failure and the protection is crash- consistent.