SAP

Elevate your SAP Business One Offering as a Citrix Service Provider

We’ve Moved! Update your Reader Now.

This feed has moved to: http://feeds.feedblitz.com/citrix

Update your reader now with this changed subscription address to get your latest updates from us.

Continue reading..

CenturyLink Transforms SAP Deployment Model with VMware Virtualization

We recently worked with CenturyLink, one of the largest telecommunications companies in the United States, to optimize their virtual SAP HANA solutions. The outcome is below referenced success story, where CenturyLink describes how they use the VMware platform, to provide a customized private cloud for SAP applications, including SAP HANA in less than 28 days, with no compromise on performance.

A SAP infrastructure project duration of 28 days may not sound so fast, but remember, this is a for a completely customized SAP private cloud solution and not just some standard, simple SAP HANA instances running somewhere in the public cloud, as a test or development system. Regarding CenturyLink, customers can deploy new SAP workloads up to four times faster, compared to in-house implementations, where these deployments typically take over 100 days!

Deploying a complete SAP landscape includes several systems like SAP Solution Manger, SAP Gateways, load balancers, several applications servers and finally the SAP HANA database. All these systems need to get configured, patched up to the latest software release level and connected by maintaining highest security standards. All this will get done, if wished, by CenturyLink.

Beside faster time to market, CenturyLink can utilize templates and repeatable processes, which helps it easily standardize and scale its offering while managing costs, complexity, and risks. This all leads to CapEx savings of up to 60 percent and OpEx savings in a similar range for CenturyLink customers. For instance, as an SAP HEC partner, CenturyLink had to deploy without SAP HANA VMware vSphere virtualization, 20 physical server systems to support 20 independent SAP HANA systems in the past. Now they deploy a VMware cluster of 8 hosts to support these 20 SAP HANA instances, including HA, which is a HW reduction by 12 hosts or 60 percent. 60 percent less power and cooling costs, rack space savings and reduced HW maintenance costs are only the more comprehensible cost savings realized. Additionally, to this the easier operation of a virtual, software defined environment, are major, long-term, cost saving factors.

These are the reasons why CenturyLink wants to go one step further towards a fully software defined data-center and plans to implement a VMware Virtual SAN™ based hyper-converged infrastructure ready to run even the more demanding SAP workloads.

For more information please review the success story posted here:

  • Case Study
  • vCloud Air Success Stories

The post CenturyLink Transforms SAP Deployment Model with VMware Virtualization appeared first on Virtualize Business Critical Applications.

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

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

In part 1 we 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. In the second part we will look at storage, network and security design for the proposed customer environment.Availability Design

The availability design depends on the single point of failure (SPOF) analysis of components. There are components in the SAP infrastructure that are one of a kind and are potential SPOFs; other components are capable of having multiple instances for load balancing and availability.

SAP S/4HANA Architecture

This section summarizes SAP S/4HANA architecture concepts and terminology used in this document. SAP uses the term system landscape, which contains all the SAP systems that have been installed. It can consist of several system groups for which SAP systems are linked by transport routes. Transport routes refer to the path of code migrations between SAP systems, for example from development (DEV) to quality assurance (QAS) to production (PRD) (https://help.sap.com/saphelp_nw74/helpdata/en/63/a30a4ac00811d2851c0000e8a57770/content.htm).

The architecture of a single SAP system is multitier and consists of the following components:

  • Application servers (SAP Web application servers) – These are ABAP or Java (J2EE) based, depending on the specific SAP product or module. Two types exist:
  • Primary application server (PAS) – An application server instance that is installed with SAP Central Services in newer NetWeaver releases and is part of the base installation.
  • Additional application servers (AAS) – Application servers installed as required for horizontal scalability.
  • SAP Message Service – The SAP Message Service is used to exchange and regulate messages between SAP instances in an SAP system. It manages functions such as determining which instance a user logs in to during client connect and scheduling batch jobs on instances configured for batch.
  • SAP Enqueue Service – The SAP Enqueue Service manages the locking of business objects at the SAP transaction level. Locks are set in a lock table stored in the shared memory of the host on which the SAP Enqueue Service runs.
  • Database server – SAP S/4HANA and SAP S/4HANA Suite support SAP HANA as the backend database for all applications. Each module has its own individual standalone SAP HANA database.
  • The following SAP services are defined based on the Message Service and Enqueue Service:
    • SAP Central Services – In newer SAP versions, the Message Service and Enqueue Service have been grouped into a standalone service. Separate SAP Central Services exist for ABAP- and Java-based application servers. For ABAP variants, it is called ABAP SAP Central Services (ASCS); for J2EE variants, it is called SAP Central Services (SCS).
    • Replicated enqueue server – This component consists of the standalone enqueue server and an enqueue replication server. The replicated enqueue server runs on another host and contains a replica of the lock table (replication table). If the standalone enqueue server fails, it must be restarted on the host on which the enqueue replication server is running, because this host contains the replication table in a shared memory segment. The restarted enqueue server uses this shared memory segment to generate the new lock table, after which the shared memory segment is deleted. SAP Central Services and the database are both SPOFs and therefore require considerations for high availability.

Single Point of Failure Analysis

The following SPOFs exist in the SAP NetWeaver architecture:

  • Database – Every application work process makes a private connection to the database at the start. If the connection is interrupted due to database instance failure, the work process attempts to set up a new connection and changes to &#rsquo;database reconnect&#rdquo; state until the database instance restarts. User sessions with database activity in process receive SQL error messages, but their logged-in sessions are preserved on the application server.
  • SAP Message Service and Enqueue Service – Failure of these services has a considerable effect on the system because all transactions that contain locks must be rolled back and any SAP updates being processed fail.

The isolation of the Message Service and Enqueue Service from the central instance (CI) helps address the high-availability requirements of these SPOFs. The SAP Central Services component is &#rsquo;lighter&#rdquo; than the CI and is much quicker to start up after a failure.

SAP Application Tier Availability

Every SAP application should have a minimum of two servers. Because they are serving the same function, these servers must be separated from each other by using antiaffinity rules. An SAP application server and database server can be collocated on the same physical server by using affinity rules to optimize performance in certain situations. vSphere DRS affinity rules help protect SAP application and database components by providing appropriate separation between the primary and standby servers as well as between multiple application servers.

Figure 1. SAP Application Tier Availability

vSphere HA for Database and vSphere FT for SAP Central Services:

The ideal high-availability solution for SAP S/4HANA SPOF components is to leverage vSphere HA and other SAP-specific mechanisms for the database and vSphere FT for SAP Central Services. By having more than two application servers with antiaffinity rules, the application services can be protected.

Figure 2. vSphere HA and vSphere FT – The Ideal High-Availability Solution for SAP S/4HANA SPOF Components

Storage Design

VMware storage virtualization can be categorized into three layers of storage technology. The bottom layer is the storage array, consisting of physical disks presented as logical disks—that is, storage array volumes or LUNs—to the layer above, the virtual environment occupied by vSphere. Storage array LUNs are formatted as VMware vSphere VMFS—that is, virtual machine file system—volumes in which virtual disks can be created. VMs consist of virtual disks that are presented to the guest OS as disks that can be partitioned and used in file systems. Figure 10 shows these storage layers.

Figure 3. Storage Virtualization Layers

vSphere VMFS is a cluster file system that provides storage virtualization optimized for VMs. Each VM is encapsulated in a small set of files, and vSphere VMFS is the default storage system for these files on physical SCSI disks and partitions. VMware supports Fibre Channel and iSCSI protocols for vSphere VMFS.

VMware also supports raw device mapping (RDM). RDM enables a VM to directly access a volume on the physical storage subsystem. It can be used only with Fibre Channel or iSCSI. RDM provides a symbolic link from a vSphere VMFS volume to a raw volume. The mapping makes volumes appear as files in a vSphere VMFS volume. The mapping file, not the raw volume, is referenced in the VM configuration.

To access virtual disks, a VM uses virtual SCSI controllers. These virtual controllers include BusLogic Parallel, LSI Logic Parallel, LSI Logic SAS, and VMware Paravirtual. From the standpoint of the VM, each virtual disk appears as if it were a SCSI drive connected to a SCSI controller.

For more background on storage virtualization, see the vSphere Storage Guide at https://pubs.vmware.com/vsphere-60/topic/com.vmware.ICbase/PDF/vsphere-esxi-vcenter-server-60-storage-guide.pdf.

Virtual Storage Design

This section applies the virtual storage concepts to a storage design for an SAP database on vSphere. The example here is a scale-up SAP HANA system based on the virtual SCSI controller assignments described in the Best Practices and Recommendations for Scale-up Deployments of SAP HANA on VMware vSphere white paper (http://www.vmware.com/files/pdf/SAP_HANA_on_vmware_vSphere_best_practices_guide.pdf).

Virtual SCSI Driver Virtual Device File System
LSI Logic/Paravirtual 0:0 /usr/sapX
Paravirtual 1:0 /hana/data/
Paravirtual 2:0 /hana/log/
Paravirtual 3:0 /hana/shared/

Table 9. SAP HANA Layout for Virtual SCSI Controller

The boot drive can be configured with the paravirtual driver, but configuration depends on the guest OS version. For details, see VMware knowledge base article 1010298, Configuring Disks to Use VMware Paravirtual SCSI (PVSCSI) Adapters (http://kb.vmware.com/kb/1010398).

Figure 4. Example Storage Layout for Scale-Up SAP HANA

Storage Sizing by Module Based on SAP Guidelines

Module Memory GB Data GB Log GB Shared GB Backup GB
BW/4HA_SRV 650 780 325 650 390
CRM 250 300 125 250 150
MDG 250 300 125 250 150
S/4 800 960 400 800 480
SRM 250 300 125 250 150
TM 250 300 125 250 150

Table 10. Database Component Storage Sizing for SAP S/4 HANA

As a default, the backup volume is stored under the /hana/shared volume. To store backup data, creation of a dedicated VMDK volume or NFS mount point is recommended.

TDI Compliant Pure Storage:

The solution was implemented initially with FC Storage on an all All Flash Array from Pure Storage (M50). Pure Storage M50 array is an SAP TDI compliant storage.

Figure 5. Pure Storage FlashArray//M50

The following aresome of the advantages ofrunning SAP HANA on Pure Storage:

  • Datareduction – SAP HANA performsdatacompression in column stores on two levels: dictionary and advanced. Furtherdatareductionresults of around 1.9–2.3 have been experienced. SAP HANA does not compress row store tables, so thedatareductionis even higher when there are row store tables. This use case is analytics, so there are no row store tables.
  • Encryptionoff-loading – SAP HANA encryptsonly datavolumes; it does not encryptlog volumes. Switch off theencryptionon SAP HANA and use the Pure Storage FlashArrayencryption,which can preserve valuable SAP HANA CPU cycles. That in turn can be used more efficiently to process analytical queries.
  • SAP homogeneous system copy and backup and recovery using storage snapshots – System copy, backup, and recovery using Pure Storage snapshots are extremely fast and efficient. The entire process can be automated very easily via a script and can be scheduled on a regular basis. There is no need to invest in backint third-party SAP-certified tools. This process enables customers to achieve very low RTO and RPO.

Fibre Channel SAN Design:

A Brocade Generation 6 redundant and resilient SAN Fabric was used for this deployment. When designing the SAN for an all-flash array, understanding the application workloads and the intended scalability, redundancy, and resiliency requirements is the main factor to consider.

When deploying a Fibre Channel storage array, the main design consideration is the adequate sizing of the ISLs between the edge switches where the servers are connected and the core switches where the storage arrays are connected. In implementations where the Fibre Channel storage arrays are deployed to serve specific latency- and I/O-intensive applications, such as OLTP database servers, connecting both servers and Fibre Channel storage array to the core backbone switches can be advantageous.

Figure 6. RedundantFibre Channel Fabric

Virtual SAN All Flash Storage:

After Validation of the solution, all the storage for the SAP modules were migrated to an All Flash virtual SAN infrastructure and the validation tests were repeated. Virtual SAN is not yet supported for SAP S4/HANA production but it can be used for QA and Dev/Test environments.

VMware virtual SAN was used for the management cluster and as an alternate for the TDI storage for SAP HANA. All storage components used were certified for VMware virtual SAN and provided by Western Digital.

VMware virtual SAN features the following components:

  • Two disk groups per server
  • Each disk group contains
  • One NVMe 1.5TB drive for caching
  • Two 3.5TB SSD drives for capacity

The total capacity of all-flash VMware vSAN is 52TB.

Figure 7. VMware vSAN All-Flash Datastore

SAP S/4HANA Network Design Considerations:

The network components were designed based on the foundational VVD concepts. VMware NSX is available as part of this design, to provide networking and security for application workloads. Details on the VVD network design and components can be found in Architecture and Design in VMware Validated Designs Documentation. VMware NSX is the foundation for networking in the Software-Defined Data Center (SDDC), which is leveraged for SAP S/4HANA. Each node has 4X10GBPS network connections across a pair of Brocade enterprise class VDX in redundant configuration.

SAP HANA Client Zone VMware VMware NSX Design:

VMware NSX greatly facilitates the creation and deployment of network services. The actual abstraction of these services, however, is a collaborative effort. To create an optimized virtual architecture, at a minimum this involves the network operations team, the storage team, virtual infrastructure administrators, application owners, and database administrators. This should not be an isolated task.

From a desktop environment using VMware NSX, theSAP HANA Network Requirements Guidefor tailored data center integration deployments can be decomposed and translated into a virtual network design. Regarding the client zone, the application server network and the network for other SAP HANA clients such as the SAP HANA studio, business intelligence clients, and so on, can be either on the same network or on separate networks. For scalability, management, and security purposes, using separate networks via microsegmentation is recommended. Microsegmentation enables customers to secure, isolate, and characterize network traffic from workload to workload. We also recommend a distributed routing scheme rather than a centralized routing scheme, to optimize for both north–south traffic and east–west traffic.

The east–west dynamic routing capabilities of the DLR are key here because of how SAP HANA load-balances its client connections. SAP uses techniques such as statement routing, connection selection, and command splitting to direct queries to the proper nodes. These routing techniques are based on the type of query and on which node or nodes the data lives on.

As the database grows, the data distribution and types of queries can change. DLRs enable the central management and optimization of east–west traffic by proactively reacting to database growth and traffic patterns.

For external communication with SAP HANA servers that are initiated by a Web browser or a mobile application, a VMware NSX edge services perimeter gateway manages and optimizes north–south network traffic and leverages its multifunction capabilities as a firewall, load balancer, and virtual private network (VPN) device.

And because these external connections can have vastly different security requirements, customers can use VMware NSX to associate firewall rules at the router or at the VM level to achieve greater granularity.

Figure 8. SAP HANA Client Zone VMware NSX Network Design

SAP S4/HANA Security

Standard vSphere security best practices and hardening practices must be applied to secure the infrastructure. Follow guidelines for access control and security policies provided in the VMware Validated Designs Documentation. We address only the application-specific security for SAP S/4HANA in this section.

Microsegmentation for Securing SAP S/4HANA Workloads

SAP microsegmentation enables flexible security policies that align to the multitier architecture of an individual SAP system—presentation, application and database tiers—and also to the landscape of the SAP environment, separating production from nonproduction. Figure 17 shows an SAP microsegmentation example based on the NetWeaver ABAP stack with a backend database. The following are the various tiers and components of the SAP architecture:

  • Client tier – In this example, the SAP client &#rsquo;SAPGUI&#rdquo; accesses the application tier. Customer environments can includebrowser-based access, load balancers, and a Web tier.
  • Application or Central Services tier – Application servers based on the NetWeaver ABAP stack. SAP Central Services handles SAP locking services, messaging between the application servers, and an NFS share required by all the application servers.
  • Database tier – Services are database dependent.
  • The components are isolated into their own respective VMware NSX security groups. Although other classifications are possible, a VMware NSX security group in this example is a definition in VMware NSX and corresponds to a logical grouping of VMs within which there is free communication flow. Communication flow in and out of a security group, and from and to another group, depends on the firewall rules.

 

Figure 9. Segmentation of SAP S4/HANA with VMware NSX

Security policies shown in Figure 9 provide the following controls:

  • Controlled communication path limited to specific services and protocols between tiers
  • External access permitted to the application tier via the SAP presentation service
  • Access between application and database VMs only via specific database services
  • SAP services ports that vary depending on the &#rsquo;instance number&#rdquo; assigned to the application servers and SAP Central Services. Some values are shownhere.

 

 

 

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

Read more..

SAP Fiori “Secure Plat-Forming” on Citrix

On March 27th, attendees travelled to SAP’s UX Partner Workshop, in SAP’s office in Melbourne, Australia to learn and see what SAP, Fujitsu, and Citrix are doing in the area of secure, scalable SAP Fiori deployment, specifically. 

untitled-design-2

Wann Lee


  

Related Stories

Continue reading..

Protected: SAP HANA on VMware vSphere, Support Status as of May 2017

This content is password protected. To view it please enter your password below:

The post Protected: SAP HANA on VMware vSphere, Support Status as of May 2017 appeared first on Virtualize Business Critical Applications.

Read more..

VMware Adapter for SAP Landscape Management 1.4.1 – Automate and manage your VMware virtualized SAP Landscape

On behalf of David Gallant, ISBU, Product Management and the Integrated Systems Business Unit, we are very pleased to announce the General Availability of VMware Adapter for SAP Landscape Management 1.4.1.

VMware Adapter for SAP Landscape Management integrates SAP Landscape Management (LaMa) with VMware Software-Defined Data Center (SDDC) technologies, allowing SAP BASIS administrators, VMware administrators, SAP project and business stakeholders to automate provisioning and management of SAP landscapes running on VMware&#rsquo;s SDDC. The adapter is a key component of VMware private cloud solution for SAP, which defines the software stack to virtualize, secure and automate SAP environments leveraging VMware&#rsquo;s software-defined architecture. At its core, it includes VMware vSphere, VMware NSX, vRealize Automation and the VMware Adapter for SAP Landscape Management and will help to bring SAP Consumers closer to IT Providers, by leveraging for instance an optional service portal to perform SAP system deployments and management tasks instead of using administrator and system tools.

Below figure shows how providers and consumers can leverage the VMware Adapter for SAP Landscape Management.

This release of the adapter is a very important maintenance release. With this release, we continue to enhance support for vRealize Automation and the system automation application interface (SA-API). These enhancements pave the way for additional customers to adopt SAP LaMa, and VMware&#rsquo;s SDDC.

Features of note for this release:

  • Additional enhancements to vRealize Automation integration through the SA-API
  • Bug Fixes

Platform Support:

  • vSphere 6.0 U3 and vRealize Orchestrator 6.0.3 as well as backwards compatibility for vSphere 5.5 U3a and vCenter Orchestrator 5.5.3.2
  • SAP Landscape Management 2.1 Service Pack 8

Operating Systems for SAP Landscapes

    • Microsoft Windows 2008 Release 2 or Windows 2012 R2 with SQL Server 2012/14 support – Adding Windows 2012 R2 support capture 100% of SAP Windows based installations. (Note SA-API is not currently supported on Windows)
    • Redhat Enterprise Linux 6x or 7x
    • SuSE Linux Enterprise Server 12x (Note we have deprecated SuSE 11 support and recommend our customers move to SUSE 12 ASAP)

Databases for SAP Landscapes

      • SAP HANA SP12 (on RHEL or SuSE)
      • Oracle 11gR2 or 12C
      • SQL Server 2012/14 (on Windows)
      • IBM DB6

This helps customers making the transition from Oracle to HANA which strategically helps SAP move customers off of Oracle. VMware helps makes this process less expensive, faster, more reliable and with less downtime.

For customers interested in deploying the Adapter in production SAP landscapes, we are introducing the option to purchase Production-level support from VMware GSS.

A free community edition of the Adapter will continue to be available for non-production environments.

For more information:
Visit the VMware Adapter for SAP Landscape Management Product Page

The post VMware Adapter for SAP Landscape Management 1.4.1 - Automate and manage your VMware virtualized SAP Landscape appeared first on Virtualize Business Critical Applications.

Read more..

Multiple production SAP HANA virtual machines on a single physical server on vSphere 6

Last week we finished the Multi SAP HANA VM and NUMA Node Sharing (CPU socket sharing) tests with vSphere 6. Due to the good results, SAP granted full production level support for multiple SAP HANA systems deployed on a single SAP HANA certified server virtualized with vSphere 6.

With this, customers can get now better TCO results by SAP HANA system consolidation and better utilizing their hardware assets.

For details please review SAP note 2315348 - SAP HANA on VMware vSphere 6 in production (https://launchpad.support.sap.com/#/notes/2315348)

What is allowed by now with vSphere 6?

  • Consolidation of multiple SAP HANA production level VMs on a single SAP HANA certified server based on Intel Xeon E7-v3 (Haswell).
  • Possibility to share a NUMA node (half-socket) with two production level SAP HANA VMs. Example: 4 socket Haswell server is now able to support up to 8 SAP HANA VMs, a 8 socket Haswell based server supports up to 16 SAP HANA VMs in production.
  • SAP HANA sizing rules must get applied and followed.
  • When sharing a NUMA node minimal 8 CPU cores (16 threads) must get assigned to the VMs, RAM must get assigned accordingly the latest SAP HANA sizing rules.
  • Enough network and storage IO capacity must be available for all running production SAP HANA VMs (SAP HANA TDI storage KPIs).
  • Enable VMware HA to protect the consolidated SAP HANA workload and ensure that enough failover capacity is available in the vSphere cluster.

What is not allowed as of today with vSphere 6?

  • No Intel E7-v4 (Broadwell) based system and vSphere 6.5 support. Validation and tests are ongoing but not finished.
  • Running more than two or more SAP HANA VMs on a single NUMA node (CPU socket)
  • Over-subscription of CPU and RAM resources

 

The post Multiple production SAP HANA virtual machines on a single physical server on vSphere 6 appeared first on Virtualize Business Critical Applications.

Read more..

Multiple production SAP HANA virtual machines on a single physical server on vSphere 6

Last week we finished the Multi SAP HANA VM and NUMA Node Sharing (CPU socket sharing) tests with vSphere 6. Due to the good results, SAP granted full production level support for multiple SAP HANA systems deployed on a single SAP HANA certified server virtualized with vSphere 6.

With this, customers can get now better TCO results by SAP HANA system consolidation and better utilizing their hardware assets.

For details please review SAP note 2315348 - SAP HANA on VMware vSphere 6 in production (https://launchpad.support.sap.com/#/notes/2315348)

What is allowed by now with vSphere 6?

  • Consolidation of multiple SAP HANA production level VMs on a single SAP HANA certified server based on Intel Xeon E7-v3 (Haswell).
  • Possibility to share a NUMA node (half-socket) with two production level SAP HANA VMs. Example: 4 socket Haswell server is now able to support up to 8 SAP HANA VMs, a 8 socket Haswell based server supports up to 16 SAP HANA VMs in production.
  • SAP HANA sizing rules must get applied and followed.
  • When sharing a NUMA node minimal 8 CPU cores (16 threads) must get assigned to the VMs, RAM must get assigned accordingly the latest SAP HANA sizing rules.
  • Enough network and storage IO capacity must be available for all running production SAP HANA VMs (SAP HANA TDI storage KPIs).
  • Enable VMware HA to protect the consolidated SAP HANA workload and ensure that enough failover capacity is available in the vSphere cluster.

What is not allowed as of today with vSphere 6?

  • No Intel E7-v4 (Broadwell) based system and vSphere 6.5 support. Validation and tests are ongoing but not finished.
  • Running more than two or more SAP HANA VMs on a single NUMA node (CPU socket)
  • Over-subscription of CPU and RAM resources

 

The post Multiple production SAP HANA virtual machines on a single physical server on vSphere 6 appeared first on Virtualize Business Critical Applications.

Read more..

Go Que Newsroom Categories

Fatal error: Allowed memory size of 67108864 bytes exhausted (tried to allocate 53 bytes) in /home/content/36/8658336/html/goquecom/wp-includes/wp-db.php on line 1995