Archives

VVD

Deloitte’s Integrated Multi-Cloud Management Solution to be Showcased at VMworld 2017 US

Watch this video to learn more about Deloitte’s iMCM solution. Founded on VMware Validated Design (VVD), it provides a common platform that allows numerous cloud providers to be managed through a single multi-tenant portal for the various stakeholders across an organization.

If you’re heading to VMworld 2017 in Las Vegas, be sure to add this session [MMC2623B] to your conference agenda.

The post Deloitte’s Integrated Multi-Cloud Management Solution to be Showcased at VMworld 2017 US appeared first on Partner News.

Read more..

Deloitte’s Integrated Multi-Cloud Management Solution to be Showcased at VMworld 2017 US

Watch this video to learn more about Deloitte’s iMCM solution. Founded on VMware Validated Design (VVD), it provides a common platform that allows numerous cloud providers to be managed through a single multi-tenant portal for the various stakeholders across an organization.

If you’re heading to VMworld 2017 in Las Vegas, be sure to add this session [MMC2623B] to your conference agenda.

The post Deloitte’s Integrated Multi-Cloud Management Solution to be Showcased at VMworld 2017 US appeared first on Partner News.

Read more..

Application Workload Guidance and Design for Virtualized SAP S/4HANA® on vSphere (Part 4/4)

Inpart 1we introduced the concept of SAP HANA Application Workload guidance and using example business requirements to come up with a workload and vSphere cluster design for the SAP environment. Inpart 2we looked at storage, network and security design for the proposed customer environment. In part 3we lookedat monitoring & management, backup/recovery and disaster recovery for SAP S4/HANA. In this final part we look at validating the design we built over the past three parts and conclude the four part blog series.

SAP S/4HANA Design Validation

Validation of an SAP design is often difficult because of the absence of publicly available validation and performance tools. This design utilizes best practices derived from vendor testing conducted in SAP labs. The SAP HANA database tier is critical to the infrastructure and must be validated. So as part of this SAP S/4HANA VVD solution, some SAP standard validation tools were used to exercise the designed infrastructure.

As part of the application workload guidance process, the design was created to depict an example customer environment based on common business requirements. Even though the design is based on best practices developed by VMware, it is a good practice to conduct performance validation for the solution.

Validation was performed for the SAP HANA database tier for the SAP S/4HANA modules that were designed earlier. The database tier was deployed in its own dedicated cluster on large memory hosts with 44 cores and 1TB RAM each. The VMs were deployed on SLES 12 for SAP with memory and CPU sizes from the infrastructure design. All VMware best practices were adhered to in the deployment of the various SAP S/4HANA deployments.

Validation Tests:

Standardized OLTP and OLAP tests for SAP S/4 HANA were used for the validation. The SAP HANA systems in the design had 8, 16, or 32 vCPUs each. The validation tests were run across these three sizes of VMs and were compared for performance and scalability. The storage used for the SAP HANA deployments was initially SAP HANA TDI storage hosted on the Pure Storage FlashArray//M50. The VMs then were migrated via vSphere vMotion to the all-flash VMware vSAN configuration. The tests were then repeated.

OLTP Tests:

The OLTP tests included inserts, updates, deletes, joins, and join–select operations. These tests were run for the various VM sizes.

Results for Tests with Storage on Pure Storage FlashArray//M50

8 vCPU 16 vCPU 32 vCPU
Insert 13.7115 8.318 4.912
Delete 13.131 7.802 4.4335
Update 3.2555 1.845 1.091
Select 222.2555 110.454 63.018
Join–Select 6.1375 3.152 1.983

Table 11. OLTP Time Comparison for Various Operations on TDI Storage

The time in seconds shows the duration required to run these tests. Lower times are better because they imply that the test ran more quickly.

Figure 16.OLTP operations Time Comparison for Different HANA VM Sizes on TDI Storage

Results from OLAP Type Tests on Pure Storage FlashArray//M50

Two different types of OLAP tests were performed on the SAP HANA database servers: VDM and TPC-DS. The results of these tests are shown in Table 24.

VDM

The performance for this test is measured in queries per second (QPS). There are two different types of queries, labeled QPS1 and QPS2. The QPS for the two types of queries are compared in Table 24 for the three sizes of SAP HANA database VMs.

vCPU QPS1 QPS2
8 3.925833333 45.16535
16 7.694538462 80.1825
32 11.4115 135.5245

Table 12. QPS Time Comparison Across Different HANA VM Sizes on TDI Storage

Figure 17. Query Time Comparison for Different Query Types on TDI Storage

TPC-DS is a standard benchmark for measuring the performance of decision support solutions.The benchmark models several generally applicable aspects of a decision support system, including queries and data maintenance.It includes a set of 99 queries that test various aspects of OLAP-based systems. The entire suite of queries was run against the SAP HANA databases, and the top 25 queries were compared for the three sizes of database servers. The results are shown in Figure . The 8-vCPU database system is used as the baseline and represents 100 percent from a query time perspective. The 16- and 32-vCPU systems&#rsquo; query times are compared with the baseline as shown in Figure 32.

Figure 18. TPC-DS Query Time Comparison for Different HANA VM Sizes on TDI Storage

Results for Tests with Storage on All-Flash VMware vSAN

OLTP tests were run multiple times, and the average runtimes were calculated and tabulated as shown in Table 25.

8 vCPU 16 vCPU 32 vCPU
Insert 16.094 7.607 5.145
Delete 13.6 7.304 4.44
Update 3.255 1.844 1.035
Select 239.958 110.496 67.87

Table 13.OLTP Time Comparison for Different Operations onVSAN

Figure 19.OLTP operations Time Comparison on VSAN

Results from OLAP-Type Tests on All-Flash VMware vSAN

Two different types of OLAP tests were performed on the SAP HANA database servers: VDM and TPC-DS. The results of these tests are shown in Table 26.

VDM

The performance for this test is measured in queries per second (QPS). There are two different types of queries, labeled QPS1 and QPS2. The QPS for the two types of queries are compared in Table 26 for the three sizes of SAP HANA database VMs.

vCPU QPS1 QPS2
8 4.08 45.33
16 7.08 79.45
32 11.75 136.35

Table 14. QPS Time Comparison Across Different HANA VM Sizes on VSAN

Figure 20: Query Time Comparison for Different Query Types on VSAN

Analysis

The results of the tests clearly show that the vSphere platform provides linear scalability and consistency in performance across different types of SAP S/4HANA database workloads. Linear CPU, memory, and I/O performance and scalability are reflected in these results.

TPC-DS on All-Flash VMware vSAN

TPC-DS is a standard benchmark for measuring the performance of decision support solutions.The benchmark models several generally applicable aspects of a decision support system, including queries and data maintenance.It includes a set of 99 queries that test various aspects of OLAP-based systems. The entire suite of queries was run against the SAP HANA databases, and the top 25 queries were compared for the three sizes of database servers. The results are shown in . The 8-vCPU database system was used as the baseline and represents 100 percent from a query time perspective. The 16- and 32-vCPU systems query times are compared with the baseline as shown in Figure 40.

Figure 21. TPC-DS Query Time Comparison for Different HANA VM Sizes

Analysis

The results of the tests clearly show that the vSphere platform provides linear scalability and consistency in performance across different types of SAP S/4HANA database workloads. Linear CPU, memory, and I/O performance and scalability are reflected in these results.

Conclusion:

Virtualizing SAP HANA scale-out systems enables an organization to benefit from all supported VMware virtualization solutions and options, such as live migration via vSphere vMotion, to increase SLAs and reduce TCO. The recent joint SAP and partner testing and the subsequent release of the VMware virtualized BW-EML benchmark of an SAP HANA scale-out system have shown reliable operation with a very small impact on overall system performance. SAP HANA scale-out support in controlled availability provides additional benefits for the customer by offering additional consultation from SAP, VMware, and the hardware partner. This ensures that virtualized SAP HANA configurations work well and run optimally in a customer&#rsquo;s virtualized environment.

A comprehensive implementation of the Software-Defined Data Center (SDDC) using the prescriptive advice found in this Application Workload Guidance Design document will lead to the successful &#rsquo;end-to-end&#rdquo; and linearly scalable virtual SAP HANA system. The components used within this set of tests constitute a reference architecture. Each component, although ideal for this type of implementation, is interchangeable with a variety of products widely available through the industry. The overhead imposed by the SDDC is extremely minimal. Even when using VMware vSAN, the tests in this report reveal that any overhead introduced by VMware vSAN processing is negligible.

This Application Workload Guidance Design document based on a VMware Validated Design, in addition to providing an end-to-end infrastructure for running business-critical applications, includes a VVD infrastructure that is designed, deployed, and validated for the entire SAP S/4HANA landscape. The SAP Quick-Sizer approach was used to convert business requirements to allocated compute resources. The sizing and designing of the SAP S4/HANA infrastructure followed SAP and VMware best practices. All VVD components were leveraged to build out the end-to-end solution for SAP S/4HANA. The following are some of the major components of the VVD that were used in this infrastructure:

  • vSphere for virtualized compute and infrastructure
    • High-performance Dell R630 and R730 PowerEdge Servers
    • Pure Storage–based SAP TDI and Western Digital all-flash VMware vSAN storage
    • Brocade Generation 6 SAN fabric
  • Separate vSphere clusters for management, SAP applications, and SAP HANA databases
  • vSphere HA and vSphere FT for simplified high availability
  • VMware NSX for networking with microsegmentation for security on Brocade VDX switches
  • vRealize Automation with Adapter for SAP Landscape Management
  • vRealize Operations with Blue Medora SAP dashboards for operations and capacity planning

The solution was then successfully validated to meet and exceed the requirements. The results of the validation tests clearly show that vSphere offers a robust platform for running SAP S/4HANA production workloads.

This set of tests was conducted in a truly comprehensive manner, both broad in scope and striking in depth. In addition to what has been highlighted in this voluminous work, there are components of VMware technology that were used as &#rsquo;common practice&#rdquo; during the testing procedure that are well accepted in &#rsquo;everyday&#rdquo; virtualized environments and therefore don&#rsquo;t necessarily warrant detailed or complex analysis and explanation in the text. For example, vSphere vMotion was used on the virtual SAP HANA VMs to transition them from servers using the Pure Storage array to those configured to use VMware vSAN. This is a highly impressive capability, but it is one that in 2017 is so commonly employed in virtualized environments that it is unnecessary to highlight.

The time has come to definitively recognize that the well-known VMware motto &#rsquo;No Application Left Behind,&#rdquo; which was adopted in the vSphere 6.x time frame and signifies that every implemented application and database is a candidate for virtualized infrastructure, is an observable fact. The benefits and value of the VMware SDDC will enhance any SAP HANA implementation.

More details from this blog series can be found in this comprehensiveWhitepaper.

The post Application Workload Guidance and Design for Virtualized SAP S/4HANA® on vSphere (Part 4/4) appeared first on Virtualize Business Critical Applications.

Read more..

Application Workload Guidance and Design for Virtualized SAP S/4HANA® on vSphere (Part 3/4)

Inpart 1we introduced the concept of SAP HANA Application Workload guidance and using example business requirements to come up with a workload and vSphere cluster design for the SAP environment. Inpart 2we looked at storage, network and security design for the proposed customer environment. In this part we will look at monitoring & management, backup/recovery and disaster recovery for SAP S4/HANA.

SAP S/4HANA Monitoring and Management

Nearly every component of the IT stack contributes to application performance, which can make it challenging to identify the cause of issues when they arise. For many organizations, a lack of visibility can lead to mean-time-to-innocence hunts that waste time and create alert storms that drain the productivity of business teams. With a complex application such as SAP S/4HANA, performance issues can be even more difficult to specify because the application requires resources from the virtual environment, the network, and databases. However, integrating monitoring into a single console—such as VMware vRealize Operations Manager can provide visibility into SAP workloads and other IT relationships to impact performance.

The Management Pack for SAP S/4HANA enhances vRealize Operations Manager by adding three dashboards that include the following features:

  • SAP overview dashboard ­– See heat maps depicting the overall health of SAP landscapes, host systems, and popular instance types such as Java, ABAP, and dual stack.
  • SAP relationships – Access relationships, badges, health trees, and metrics for a particular SAP resource.
  • SAP host overview – View top alerts, heat maps, and relationships to VMware VMs, parent VM KPIs, and CPU and memory metrics for SAP hosts.
  • SAP landscape overview – See top alerts, heat maps, CPU and memory usage metrics, and services utilization for an SAP landscape.
  • SAP HANA environment – See details about SAP HANA resources, including alerts and key metrics.
  • SAP HANA host details – Access detailed information about SAP HANA hosts, including workload, capacity remaining, statements summary, and connections.
  • SAP HANA overview – Select a system to see properties, workload, capacity remaining, request summary, and topology view of relationships.

Reports and Dashboards

Performance issues, particularly across a wide-sprawling application such as SAP, can be challenging to ascertain, especially with the growing complexity of the IT stack in today&#rsquo;s environment. Having the ability to clearly see where issues develop can be a game changer in ensuring availability and a better experience for end users. Reporting and dashboards can extend visibility into key areas of the SAP environment and can identify issues as soon as they arise rather than when they are wreaking havoc on the system

Figure 10.Example of the SAP System Overview Dashboard in vRealize Operations

Capacity Planning

Predictive analytics in vRealize Operations can provide the insight required to optimize the capacity and health of an SAP environment. Analysis badges offer a visual indication of the current condition of the virtual environment. Updates in real time quickly help determine whether capacity issues are being caused by various indicators such as workload, capacity, or stress on the application. Capacity definitions help extend that visibility into specific areas of an SAP application and enable reporting on key elements that help determine trends and how to improve application performance.

Figure 11.Example of Analysis Badge for SAP S/4HANA in vRealize Operations

SAP S/4HANA Automation

VMware Adapter for SAP Landscape Management Solution Overview

VMware Adapter for SAP Landscape Management, part of the VMware private cloud solution for SAP is a virtual appliance that integrates SAP Landscape Management with VMware management software—that is, vCenter Server and vRealize Automation. This delivers unique automation capabilities that radically simplify how SAP basis administrators and end users provision and manage SAP landscapes. The appliance accepts application calls from SAP Landscape Management, then uses vRealize Automation or VMware vRealize Orchestrator ™ workflows to execute commands to vCenter Server or operations related to VMware products, such as starting and stopping a VM. Furthermore, IT administrators can now leverage SA-API to automatically provision SAP systems from templates with vRealize Automation in conjunction with SAP Landscape Management.

Key Benefits

The deployment of new SAP systems can take days or even weeks before systems are ready for use. Customers have long used various cloning methods to speed up the deployment process. However, these processes are complex and labor intensive. The
 VMware Adapter for SAP Landscape Management - Connector for vRealize Automation (Connector) greatly simplifies the deployment process by utilizing vSphere cloning and SAP Landscape Management to create new SAP workloads in an automated and repeatable form and from proven templates.

Figure 12. VMware Adapter for SAP Landscape Management

SAP S/4HANA Backup and Recovery

SAP HANA on vSphere Backup and Restore

After reviewing how SAP HANA data persistence works, ensure that the savepoints and logs SAP HANA uses to persist its data are backed up and stored securely to have them available to recover from data loss via restoring this data.

An SAP HANA database backup consists of data backup—that is, snapshots—and transaction log backups. The data backup can be scheduled or started manually within SAP HANA Studio, DBA Cockpit, or via SQL commands. Logs are saved automatically in an asynchronous way whenever a log segment is full or the timeout for log backup has elapsed.

Transaction redo logs are used to record any changes made to the database. In the case of failure, the most recent consistent state of the database can be restored by replaying the changes recorded in the log, redoing completed transactions, and rolling back incomplete ones. Savepoints are created and described as periodic, representing the data stored in the SAP HANA database. They are coordinated across all processes—called SAP HANA services—and instances of the database to ensure transaction consistency. New savepoints normally overwrite older savepoints, but it is possible to freeze a savepoint for future use; this is called a snapshot. Snapshots can be replicated in the form of full data backups, which can be used to restore a database to a specific point in time. Snapshots can also be used to create a database copy for SAP HANA test-and-development systems. Periodic backup of the snapshots and logs ensures the ability to recover from fatal storage faults with minimal loss of data.

Backup and recovery of virtualized SAP HANA systems is similar to that of any physically deployed SAP HANA system. The backup of the necessary files can be performed as a normal file system backup to an external NFS server. When a backint-compatible backup solution is used, the backup can be performed directly via the backint interface to a backup server and then to the final backup device. Using storage built-in snapshot functionality to create backups is another option. This method is the fastest way to create a backup. Some vendors work on backups that are vSphere snapshot compatible. Storage systems that today support the new VVOL standard already enable snapshotting VMs with the full awareness of the virtual disks belonging to a VM. Figure 13 provides an overview of the SAP HANA backup and recovery methods.

Figure 13: Backup and Recovery for SAP S/4HANA:

 

Disaster Recovery Solutions with vSphere for SAP S/4HANA

We have already discussed recovery solutions for local failures—component or OS failures, for example. In addition to these solutions for local failures, SAP HANA offers disaster recovery solutions supported by vSphere that replicate the data from the primary data center to VMs in a secondary data center. SAP HANA system replication provides a very robust solution to replicate the SAP HANA database content to a secondary disaster site; this storage-based system replication can be used as well. When using SAP HANA System Replication, the same number of SAP HANA VMs must exist at the disaster recovery site. These VMs must be configured and installed similarly to a natively running SAP HANA system with System Replication enabled.

SAP HANA System Replication provides various modes for system replication:

  • Synchronous
  • Synchronous in-memory
  • Asynchronous

Depending on requirements, the disaster recovery VMs can consume higher or lower amounts of resources on the disaster recovery vSphere cluster. For instance, the synchronous in-memory mode consumes the same amount of RAM as with the primary systems. This mode is required only if the customer requests the shortest recovery time. In most customer scenarios, using synchronous data replication should be sufficient. SAP states that by replicating only the data, about 10 percent of the system resources are required, enabling up to 90 percent of the resources to continue to be used by other systems such as test or QA systems.

 

Figure 14. SAP HANA Scale-Out Solution with Replication

In this scenario, resource over-commitments are used to enable the co-deployment of such an environment. By using resource pools and resource shares, required resources can be provided to the disaster recovery SAP HANA scale-out VMs. The co-deployed system, with fewer resource shares, experiences performance degradation after the disaster recovery systems are used following a site failover. Evacuate these VMs to other available vSphere systems to free up all resources for the disaster recovery SAP HANA VMs. This is another option, as opposed to running the two systems in parallel—with resource limitations—on the same platform.

System replication via storage or the SAP HANA replication solution requires additional steps after a site failover has taken place, to switch the network identity (IP redirect) of the replicated systems from the disaster recovery configuration to the production configuration. This can be done manually or via automated tools such as HP ServiceGuard, SUSE cluster connector, SAP Landscape Virtualization Management (LVM), or other cluster managers. The configuration of such a solution in a virtualized environment is similar to that of natively running systems. Contact your storage vendor to discuss a cluster manager solution supported by its storage solution.

VMware Site Recovery Manager

VMware Site Recovery Manager™ can help reduce the complexity of a system replication disaster recovery solution by automating the complex disaster recovery steps on any level. Site Recovery Manager is designed for disaster recovery of a complete site or a data center failure. It supports both unidirectional and bidirectional failover. It also supports &#rsquo;shared recovery site,&#rdquo; enabling organizations to fail over multiple protected sites into a single, shared recovery site. This site can, for instance, also be a cloud data center provided by VMware vCloud® Air, the VMware cloud service offering.

The following key elements compose a Site Recovery Manager deployment for SAP:

  • Site Recovery Manager – Designed for virtual-to-virtual disaster recovery. Site Recovery Manager requires a vCenter Server management server at each site. These two vCenter Server instances are independent, each managing its own site. Site Recovery Manager informs them of the VMs they must recover if a disaster occurs.
  • Site Recovery Manager manages, updates, and executes disaster recovery plans. It is managed via a vCenter Server plug-in.
  • Site Recovery Manager relies on storage vendors&#rsquo; array-based replication Fibre Channel or NFS storage that supports block-level replication of SAP HANA data and log files to the disaster recovery site. Site Recovery Manager communicates with the replication process via storage replication adapters offered by the storage vendor and that have been certified for Site Recovery Manager.
  • vSphere Replication has no such restrictions on use of storage type or adapters. It can be used for VMs that are either static or are not performance critical, such as infrastructure services or SAP application servers with RPO of 15 minutes or longer.

Figure 15 shows an example SAP landscape protected by Site Recovery Manager and storage. The VMs running on the primary site contain all needed infrastructure and SAP components such as LDAP, SAP HANA database, and SAP application servers, as in an SAP Business Suite implementation. The VMs can be replicated, depending on the recovery point objective (RPO), via vSphere, SAP HANA, or storage replication. vSphere replication can be used with VMs that tolerate an RPO time of 15 minutes or longer.

Figure 15. SAP Landscape Protected by VMware Site Recovery Manager

Here is a summary of the benefits of using Site Recovery Manager for managing the disaster recovery process for SAP landscapes:

  • Reduce the cost of disaster recovery by up to 50 percent.xlv
  • Application-agnostic protection eliminates the need for application-specific point solutions.
  • Support for vSphere Replication and array-based replication offers choices and options for synchronous replication with zero data loss.
  • Centralized management of recovery plans directly from VMware vSphere Web Client replaces manual runbooks.
  • Self-service, policy-based provisioning via vRealize Automation automates protection.
  • Frequent, nondisruptive testing of recovery plans ensures highly predictable recovery objectives.
  • Automated orchestration of site failover and failback with a single click reliably reduces RTO.
  • Planned migration workflows enable disaster avoidance and data center mobility.

 

The post Application Workload Guidance and Design for Virtualized SAP S/4HANA® on vSphere (Part 3/4) appeared first on Virtualize Business Critical Applications.

Read more..

Go Que Newsroom

Categories