CenturyLink Transforms SAP Deployment Model with VMware Virtualization

 Allgemein, Knowledge Base, Updates, VMware, VMware Partner, VMware Virtual Infrastructure, vSphere  Kommentare deaktiviert für CenturyLink Transforms SAP Deployment Model with VMware Virtualization
Aug 142017
 

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.

To be “RDM for Oracle RAC”, or not to be, that is the question

 Allgemein, Knowledge Base, Updates, VMware, VMware Partner, VMware Virtual Infrastructure, vSphere  Kommentare deaktiviert für To be “RDM for Oracle RAC”, or not to be, that is the question
Aug 112017
 

Famous words from William Shakespeare’s play Hamlet. Act III, Scene I.

This is true even in the Virtualization world for Oracle Business Critical Applications where one wonders which way to go when it comes to provisioning shared disks for Oracle RAC disks, Raw Device Mappings (RDM) or VMDK ?

Much has been written and discussed about RDM and VMDK and this post will focus on the Oracle RAC shared disks use case.

Some common questions I get talking to our customer who are embarking on the virtualization journey for Oracle on vSphere are

  • What is the recommended approach when it comes to provisioning storage for Oracle RAC or Oracle Single instance? Is it VMDK or RDM?
  • What is the use case for each approach?
  • How do I provision shared RDM (s) in Physical or Virtual Compatibility mode for an Oracle RAC environment?
  • If I use shared RDM (s) (Physical or Virtual) will I be able to vMotion my RAC VM &#rsquo;s without any cluster node eviction?

We recommend using shared VMDK (s) with multi-writer setting for provisioning shared storage for Oracle RAC environments so that one can take advantage of all the rich features vSphere as a platform can offer which includes

  • better storage consolidation
  • manage performance
  • increases storage utilization
  • provides better flexibility
  • easier administration and management
  • use features like SIOC (Storage IO control)

For setting multi-writer flag on classic vSphere, refer to KB article &#rsquo;Enabling or disabling simultaneous write protection provided by VMFS using the multi-writer flag (1034165)&#rdquo;

https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1034165

For setting multi-writer flag on vSAN, refer to KB article &#rsquo;Using Oracle RAC on a vSphere 6.x vSAN Datastore (2121181)&#rdquo;

https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2121181

However, there still are some cases where it makes more sense to use RDM storage access over vmdk:

  • Migrating an existing application from a physical environment to virtualization
  • Using Microsoft Cluster Service (MSCS) for clustering in a virtual environment
  • Implementing N-Port ID Virtualization (NPIV)

This is well explained in the white paper &#rsquo;VMware vSphere VMFS Technical Overview and Best Practices&#rdquo; for version 5.1

https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/whitepaper/vmware-vsphere-vmfs-best-practices-whitepaper.pdf

Difference between Physical compatibility RDMs (rdm-p) and Virtual compatibility RDMs (rdm-v) can be found in the KB 2009226.

https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2009226

Back to the topic of Oracle RAC shared disks and to rdm or not to rdm !!

For those customers whose requirement falls in the list of used cases above where the need is to deploy Oracle RAC with shared RDM disks, yes, RDM &#rsquo;s can be used as shared disks for Oracle RAC clusters on classic vSphere. VMware vSAN does not support Raw Device Mappings (RDMs) at the time of writing this blog.

Important caveats to keep in mind about shared RDM &#rsquo;s and vMotion:

  • There was never an issue vMotioning VMs with RDM &#rsquo;s from one ESXi server to another, it has worked in all versions of vSphere including the latest release
  • The only issue was with shared RDM (s) for Clustering. vMotion of VMs with shared RDMs requires virtual hardware 11 or higher i.e VMs must be in &#rsquo;Hardware 11&#rdquo; compatibility mode – which means that you are either creating and running the VMs on ESXi 6.0 hosts, or you have converted your old template to Hardware 11 and deployed it on ESXi 6.0.
  • The VMs must be configured with this above hardware version at minimum for shared RDM vMotion to take place

VMware products and their virtual hardware version table can be found below:

 

https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1003746

As per the table above, with vSphere 6.0 and above, for VMs with virtual hardware version 11 or higher, the restriction for shared RDM vMotion has been lifted.

Now that we are aware of the above restrictions, lets add a shared RDM in Physical compatibility mode to 2 VMs as part of an Oracle RAC installation and see if we can vMotion the 2 VMs without any failure.

The high-level steps are

  • add a shared RDM in Physical compatibility mode (rdm-p) to 2 VMs which are part of an Oracle RAC installation
  • Use Oracle ASMLIB to mark those disk as ASM disks
  • vMotion the 2 VMs from one ESXi server to another and see if we encounter any issues

There are 2 points to keep in mind when adding shared RDM (s) in physical compatibility mode to a VM.

  • The SCSI controller where the shared rdm (s) will added to, the &#rsquo;SCSI Bus Sharing&#rdquo; needs to be set to &#rsquo;Physical&#rdquo;
  • The &#rsquo;Compatibility mode for the&#rdquo; shared RDM needs to set to &#rsquo;Physical&#rdquo; for Physical Compatibility (rdm-p)

The SCSI Bus sharing can be set to either of the 3 options ( None, Physical & Virtual ) as per the table below.

&#rsquo;SCSI Bus sharing&#rdquo; would be set to

  • &#rsquo;Physical&#rdquo; for clustering across ESXi servers
  • &#rsquo;Virtual&#rdquo; for clustering within an ESXi server

https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.vm_admin.doc/GUID-4FB34475-018B-43B7-9E33-449F496F5AB4.html

The 2 VMs are rdmrac1 (10.128.138.1) and rdmrac2 (10.128.138.2) . Both VMs are running Oracle Enterprise Linux 7.4.

[root@rdmrac1 ~]# uname -a
Linux rdmrac1 4.1.12-94.5.7.el7uek.x86_64 #2 SMP Thu Jul 20 18:44:17 PDT 2017 x86_64 x86_64 x86_64 GNU/Linux

[root@rdmrac1 ~]# cat /etc/oracle-release
Oracle Linux Server release 7.4
[root@rdmrac1 ~]#

The RDM (WWN 60:06:01:60:78:70:42:00:5C:98:8B:59:85:DC:51:A7) in physical compatibility mode that we would use is highlighted below:

Following are the steps:

1) Add a new controller to VM &#rsquo;rdmrac1&#rdquo;. Recommendation is use PVSCSI for Controller type. Set the controller &#rsquo;SCSI Bus Sharing&#rdquo; to &#rsquo;Physical&#rdquo;. Do the same for VM &#rsquo;rdmrac2&#rdquo; also.

2) Add the RDM disk to the first VM &#rsquo;rdmrac1&#rdquo;.

 

3) Pick the correct RDM device (WWN 60:06:01:60:78:70:42:00:5C:98:8B:59:85:DC:51:A7)

4) Set RDM &#rsquo;Compatibility Mode&#rdquo; to &#rsquo;Physical&#rdquo; as shown. Please make a note of the SCSI ID to which you have attached the disk. You will use the same ID for this disk when attaching it to the other VM “rdmrac2” which will be sharing this disk. In this case we used SCSI 1:0.

5) Add the existing hard disk ( same RDM disk ) to VM “rdmrac2” to the new PVSCSI controller.

6) Add the existing RDM disk to the same SCSI channel we used in step 4 which was SCSI 1:0 (same as in the case of rdmrac1).

7) Now the shared rdm is added to both VMs &#rsquo;rdmrac1&#rdquo; and &#rsquo;rdmrac2&#rdquo;. Next order of business is to format the raw disk.

Oracle ASMLIB requires that the disk be partitioned, you can use the raw device without partitioning as is if you are using Linux UDEV for Oracle ASM purposes.

Partitioning is a good practice anyways to prevent anyone from attempting to create a partition table and file system on any raw device he gets his hands on which will lead to issues if the device is being used by ASM.

Format the disks

[root@rdmrac1 ~]# fdisk -lu

Disk /dev/sdc: 107.4 GB, 107374182400 bytes, 209715200 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 8192 bytes / 33553920 bytes
..
[root@rdmrac1 ~]#

Use the partitioning weapon of your choice (fdisk, parted, and gparted) , I used fdisk below to partition with default alignment offset.

[root@rdmrac1 ~]# fdisk -lu

Disk /dev/sdc: 107.4 GB, 107374182400 bytes, 209715200 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 8192 bytes / 33553920 bytes
Disk label type: dos
Disk identifier: 0xddceaeeb

Device Boot Start End Blocks Id System
/dev/sdc1 2048 209715199 104856576 83 Linux
[root@rdmrac1 ~]#

Scan the SCSI bus using operating system commands on &#rsquo;rdmrac2&#rdquo;

[root@rdmrac2 ~]# fdisk -lu
….
Disk /dev/sdc: 107.4 GB, 107374182400 bytes, 209715200 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 8192 bytes / 33553920 bytes
Disk label type: dos
Disk identifier: 0xddceaeeb

Device Boot Start End Blocks Id System
/dev/sdc1 2048 209715199 104856576 83 Linux
[root@rdmrac2 ~]#

Install Oracle ASMLIB rpm as usual and marked the new rdm disk as ASM disk

[root@rdmrac1 software]# /usr/sbin/oracleasm createdisk DATA_DISK01 /dev/sda1
Writing disk header: done
Instantiating disk: done
[root@rdmrac1 software]#

[root@rdmrac1 software]# /usr/sbin/oracleasm listdisks
DATA_DISK01
[root@rdmrac1 software]#

[root@rdmrac2 ~]# /usr/sbin/oracleasm listdisks
DATA_DISK01
[root@rdmrac2 ~]#

8) Now for the vMotion test that we have been waiting for. VM &#rsquo;rdmrac1&#rdquo; is on host 10.128.136.118 and VM &#rsquo;rdmrac2&#rdquo; is on host 10.128.136.117.

vMotion &#rsquo;rdmrac1&#rdquo; from host 10.128.136.118 to 10.128.136.119.

Simultaneously, you can choose to vMotion VM &#rsquo;rdmrac2&#rdquo; from 10.128.136.117 to 10.128.136.118.

Start vMotion of &#rsquo;rdmrac1&#rdquo; from host 10.128.136.118 to 10.128.136.119

While the vMotion is taking place, perform ping test by pinging VM &#rsquo;rdmrac1&#rdquo; from VM &#rsquo;rdmrac1&#rdquo;

[root@rdmrac2 ~]# ping 10.128.138.1
PING 10.128.138.1 (10.128.138.1) 56(84) bytes of data.
64 bytes from 10.128.138.1: icmp_seq=2 ttl=64 time=0.288 ms
64 bytes from 10.128.138.1: icmp_seq=3 ttl=64 time=0.296 ms
64 bytes from 10.128.138.1: icmp_seq=4 ttl=64 time=0.288 ms

64 bytes from 10.128.138.1: icmp_seq=8 ttl=64 time=0.293 ms
64 bytes from 10.128.138.1: icmp_seq=9 ttl=64 time=0.242 ms
64 bytes from 10.128.138.1: icmp_seq=18 ttl=64 time=0.252 ms
64 bytes from 10.128.138.1: icmp_seq=19 ttl=64 time=0.279 ms
64 bytes from 10.128.138.1: icmp_seq=20 ttl=64 time=0.256 ms
64 bytes from 10.128.138.1: icmp_seq=21 ttl=64 time=0.422 ms
..
64 bytes from 10.128.138.1: icmp_seq=23 ttl=64 time=0.675 ms <– Actual Cutover
..
64 bytes from 10.128.138.1: icmp_seq=24 ttl=64 time=0.295 ms
64 bytes from 10.128.138.1: icmp_seq=25 ttl=64 time=0.251 ms
64 bytes from 10.128.138.1: icmp_seq=26 ttl=64 time=0.246 ms
64 bytes from 10.128.138.1: icmp_seq=27 ttl=64 time=0.177 ms

^C
— 10.128.138.1 ping statistics —
53 packets transmitted, 52 received, 1% packet loss, time 52031ms
rtt min/avg/max/mdev = 0.177/0.297/0.902/0.107 ms
[root@rdmrac2 ~]#

At the end of the vMotion operation, the VM &#rsquo;rdmrac1&#rdquo; is are now on a different host without experiencing any network issues.

Yes, the most conclusive test would be to have a fully functional RAC running and see if we have any cluster node evictions or disconnects of RAC sessions. I have performed those tests as well and have not encountered any issues.

In case you were wondering what steps needed to be taken to add a shared RDM in virtual compatibility mode

  • The SCSI controller where the shared rdm (s) will added to, the &#rsquo;SCSI Bus Sharing&#rdquo; needs to be set to &#rsquo;Physical&#rdquo; (cluster across any ESXi servers)
  • The &#rsquo;Compatibility mode for the&#rdquo; shared RDM needs to set to &#rsquo;Virtual&#rdquo; for Virtual Compatibility (rdm-v)

In this case, I used the same 2 VMs, &#rsquo;rdmrac1&#rdquo; and &#rsquo;rdmrac2&#rdquo;.

  • added a new SCSI Controller of Type Paravirtual (SCSI 2)
  • added the shared RDM in virtual compatibility mode (new device with WWN 60:06:01:60:78:70:42:00:E3:98:8B:59:4D:4A:BC:F9) at the same SCSI position (SCSI 2:0) for both the 2 VMs.

The steps for adding the rdm-v&#rsquo;s are the same as shown above for rdm-p&#rsquo;s.

VM &#rsquo;rdmrac1&#rdquo; showing SCSI 2 Paravirtual Controller with shared rdm in Virtual compatibility mode at SCSI 2:0 position.

VM &#rsquo;rdmrac2&#rdquo; showing SCSI 2 Paravirtual Controller with shared rdm in Virtual compatibility mode at SCSI 2:0 position.

Same vMotion with ping test was done and no issues were observed.

Key points to keep in mind:

  • vMotion of shared rdm (s) is possible in vSphere 6.0 and above as long as the VMs are in &#rsquo;Hardware 11&#rdquo; compatibility mode
  • Best Practices needs to be followed when configuring Oracle RAC private interconnect and VMware vMotion network which can be found in the &#rsquo;Oracle Databases on VMware – Best Practices Guide&#rdquo;

https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/solutions/vmware-oracle-databases-on-vmware-best-practices-guide.pdf

All Oracle on vSphere white papers including Oracle licensing on vSphere/vSAN, Oracle best practices, RAC deployment guides, workload characterization guide can be found in the url below

Oracle on VMware Collateral – One Stop Shop
https://blogs.vmware.com/apps/2017/01/oracle-vmware-collateral-one-stop-shop.html

The post To be &#rsquo;RDM for Oracle RAC&#rdquo;, or not to be, that is the question appeared first on Virtualize Business Critical Applications.

Streamlining Oracle on SDDC – VMworld 2017

 Allgemein, Knowledge Base, Updates, VMware, VMware Partner, VMware Virtual Infrastructure, vSphere  Kommentare deaktiviert für Streamlining Oracle on SDDC – VMworld 2017
Aug 022017
 

Interested to find out how to streamline your Business Critical Applications on VMware Software-Defined Datacenter (SDDC) seamlessly?

Come attend our session at VMworld 2017 Las Vegas on Thursday, Aug 31, 1:30 p.m. – 2:30 p.m. where Amanda Blevins and Sudhir Balasubramanian will talk about the end to end life cycle of an Application on VMware SDDC.

This includes provisioning, management, monitoring, troubleshooting, and cost transparency with the vRealize Suite. The session will also include best practices for running Oracle databases on the SDDC including sizing and performance tuning. Business continuity requirements and procedures will be addressed in the context of the SDDC. It is a formidable task to ensure the smooth operation of critical applications running on Oracle, and the SDDC simplifies and standardizes the approach across all datacenters and systems.

The post Streamlining Oracle on SDDC – VMworld 2017 appeared first on Virtualize Business Critical Applications.

Oracle on vSAN HCI – VMworld 2017

 Allgemein, Knowledge Base, Updates, VMware, VMware Partner, VMware Virtual Infrastructure, vSphere  Kommentare deaktiviert für Oracle on vSAN HCI – VMworld 2017
Aug 022017
 

Interested to find out how VMware HCI vSAN solution provides high availability, workload balancing, seamless site maintenance, stability, resilience, performance and cost effective hardware required to meet critical business SLA’s for running mission critical workloads?

Come attend our session at VMworld 2017 Las Vegas on Wednesday, Aug 30, 2:30 p.m. – 3:30 p.m. where Sudhir Balasubramanian and Palanivenkatesan Murugan will talk about the VMware HCI vSAN solution for Mission Critical Oracle workloads

This session will showcase deployment of Oracle Clustered and Non Clustered databases along with running IO intensive workloads on vSAN and also talk about seamlessly running database day 2 operations like Backup & Recovery, Database Cloning , Data Refreshes , Database Patching etc using vSAN capability.

The post Oracle on vSAN HCI – VMworld 2017 appeared first on Virtualize Business Critical Applications.

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

 Allgemein, Knowledge Base, Updates, VMware, VMware Partner, VMware Virtual Infrastructure, vSphere  Kommentare deaktiviert für Application Workload Guidance and Design for Virtualized SAP S/4HANA® on vSphere (Part 4/4)
Jun 302017
 

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 vCPU16 vCPU32 vCPU
Insert13.71158.3184.912
Delete13.1317.8024.4335
Update3.25551.8451.091
Select222.2555110.45463.018
Join–Select6.13753.1521.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.

vCPUQPS1QPS2
83.92583333345.16535
167.69453846280.1825
3211.4115135.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 vCPU16 vCPU32 vCPU
Insert16.0947.6075.145
Delete13.67.3044.44
Update3.2551.8441.035
Select239.958110.49667.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.

vCPUQPS1QPS2
84.0845.33
167.0879.45
3211.75136.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.

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

 Allgemein, Knowledge Base, Updates, VMware, VMware Partner, VMware Virtual Infrastructure, vSphere  Kommentare deaktiviert für Application Workload Guidance and Design for Virtualized SAP S/4HANA® on vSphere (Part 4/4)
Jun 302017
 

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 vCPU16 vCPU32 vCPU
Insert13.71158.3184.912
Delete13.1317.8024.4335
Update3.25551.8451.091
Select222.2555110.45463.018
Join–Select6.13753.1521.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.

vCPUQPS1QPS2
83.92583333345.16535
167.69453846280.1825
3211.4115135.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 vCPU16 vCPU32 vCPU
Insert16.0947.6075.145
Delete13.67.3044.44
Update3.2551.8441.035
Select239.958110.49667.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.

vCPUQPS1QPS2
84.0845.33
167.0879.45
3211.75136.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.

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

 Allgemein, Knowledge Base, Updates, VMware, VMware Partner, VMware Virtual Infrastructure, vSphere  Kommentare deaktiviert für Application Workload Guidance and Design for Virtualized SAP S/4HANA® on vSphere (Part 4/4)
Jun 302017
 

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 vCPU16 vCPU32 vCPU
Insert13.71158.3184.912
Delete13.1317.8024.4335
Update3.25551.8451.091
Select222.2555110.45463.018
Join–Select6.13753.1521.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.

vCPUQPS1QPS2
83.92583333345.16535
167.69453846280.1825
3211.4115135.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 vCPU16 vCPU32 vCPU
Insert16.0947.6075.145
Delete13.67.3044.44
Update3.2551.8441.035
Select239.958110.49667.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.

vCPUQPS1QPS2
84.0845.33
167.0879.45
3211.75136.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.

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

 Allgemein, Knowledge Base, Updates, VMware, VMware Partner, VMware Virtual Infrastructure, vSphere  Kommentare deaktiviert für Application Workload Guidance and Design for Virtualized SAP S/4HANA® on vSphere (Part 3/4)
Jun 292017
 

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.

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

 Allgemein, Knowledge Base, Updates, VMware, VMware Partner, VMware Virtual Infrastructure, vSphere  Kommentare deaktiviert für Application Workload Guidance and Design for Virtualized SAP S/4HANA® on vSphere (Part 3/4)
Jun 292017
 

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.

Oracle Database Performance on vSphere 6.5 Monster Virtual Machines

 Allgemein, Knowledge Base, Updates, VMware, VMware Partner, VMware Virtual Infrastructure, vSphere  Kommentare deaktiviert für Oracle Database Performance on vSphere 6.5 Monster Virtual Machines
Mai 162017
 

We have just published a new whitepaper on the performance of Oracle databases on vSphere 6.5 monster virtual machines. We took a look at the performance of the largest virtual machines possible on the previous four generations of four-socket Intel-based servers. The results show how performance of these large virtual machines continues to scale with the increases and improvements in server hardware.

Oracle Database Monster VM Performance on vSphere 6.5 across 4 generations of Intel-based four-socket servers

In addition to vSphere 6.5 and the four-socket Intel-based servers used in the testing, an IBM FlashSystem A9000 high performance all flash array was used. This array provided extreme low latency performance that enabled the database virtual machines to perform at the achieved high levels of performance.

Please read the full paper, Oracle Monster Virtual Machine Performance on VMware vSphere 6.5, for details on hardware, software, test setup, results, and more cool graphs. The paper also covers performance gain from Hyper-Threading, performance effect of NUMA, and best practices for Oracle monster virtual machines. These best practices are focused on monster virtual machines, and it is recommended to also check out the full Oracle Databases on VMware Best Practices Guide.

Some similar tests with Microsoft SQL Server monster virtual machines were also recently completed on vSphere 6.5 by my colleague David Morse. Please see his blog post and whitepaper for the full details.

This work on Oracle is in some ways a follow up to Project Capstone from 2015and the resulting whitepaper Peeking at the Future with Giant Monster Virtual Machines . That project dealt with monster VM performance from a slightly different angle and might be interesting to those who are also interested in this paper and its results.

 

The post Oracle Database Performance on vSphere 6.5 Monster Virtual Machines appeared first on VMware VROOM! Blog.

Oracle Database 12c on VMware vSAN — Day 2 Operations and Management

 Allgemein, Knowledge Base, Updates, VMware, VMware Partner, VMware Virtual Infrastructure, vSphere  Kommentare deaktiviert für Oracle Database 12c on VMware vSAN — Day 2 Operations and Management
Mai 032017
 

Oracle Database 12c on VMware vSAN — Day 2 Operations and Management

Customers deploying production Oracle workloads have stringent requirements to support and maintain critical database operational tasks such as Backup and Recovery, Cloning, Data Refresh for Development/Test environment and Patching. These operational tasks are also known as Database Day 2 Management Operations.

With the rapid adoption of VMware vSAN™ for business-critical workloads due to highly scalable , available , reliable and high performance HCI solution. It is essential to provide features and tools for seamless Day 1 and Day 2 Operations.

vSAN offers a range of tools and features for Day 1 and Day 2 Operations. VMware vSphere® web client provides administrator with the capability to manage their infrastructure in a unified way for deploying, provisioning, health check, and performance monitoring. vSAN 6.0 and above has improved snapshot capability, which provides users with enterprise-class snapshots and clones that can be used for Oracle database cloning use cases.

The Oracle Real Application Clusters on VMware vSAN reference architecture addresses common business challenges that CIOs face today in an online transaction processing (OLTP) environment that requires availability, reliability, scalability, predictability and cost-effective storage, which helps customers design and implement optimal configurations specifically for Oracle RAC Database on vSAN.

The Oracle Database 12c on VMware vSAN 6.2 All-Flash reference architecture addresses common business challenges that CIOs face today in an OLTP and decision-support-system (DSS) environment that requires predictable performance and cost-effective storage.

Having addressed the Day 1 operations including deployment and provisioning of critical Oracle workloads on VMware vSAN, this operation guide focuses on the Day 2 Operations of Oracle on vSAN including backup and recovery, database cloning, database refresh for test and development environment and database patching.

 

 

VMware vSAN snapshot and clone technologies are primarily used for providing support to Oracle Day 2 Operations. VMware vSAN snapshot and clone technologies used with inherent Oracle tools provide efficient Day 2 Operations for business-critical Oracle database.

Check out the recently published Oracle Database 12c on VMware vSAN — Day 2 Operations and Management operation guide that provides solutions and operation procedures for Oracle Database Day 2 Operations including below key oracle database tasks using vSAN snapshots and clones:

  • Backup and recovery
  • Cloning
  • Data refresh for development and test environment from production
  • Patching

While the operation guide provides above solutions natively for the Oracle database on vSAN environment. There are backup vendors who provide Oracle application-level integration along with VADP (VMware vSphere Storage APIs – for Data Protection) API integration, which can help in ease of backup/cloning, greater levels of manageability and control in vSphere environment including vSAN. These third-party backup solutions can also be used for these use cases.

Further, with the announcement of VMware Ready for vSAN program that offers partners a set of tools, resources, and processes needed to certify Data Protection products with VMware vSAN. This certification program will provide confidence with the partner data protection solutions deployed in VMware vSAN environments for seamless operation.

The post Oracle Database 12c on VMware vSAN — Day 2 Operations and Management appeared first on Virtualize Business Critical Applications.

SQL Server VM Performance with VMware vSphere 6.5

 Allgemein, Knowledge Base, Updates, VMware, VMware Partner, VMware Virtual Infrastructure, vSphere  Kommentare deaktiviert für SQL Server VM Performance with VMware vSphere 6.5
Mrz 232017
 

Achieving optimal SQL Server performance on vSphere has been a constant focus here at VMware; I&#rsquo;ve published past performance studies with vSphere 5.5 and 6.0 which showed excellent performance up to the maximum VM size supported at the time.

Since then, there have been quite a few changes! While this study uses a similar test methodology, it features an updated hypervisor (vSphere 6.5), database engine (SQL Server 2016), OLTP benchmark (DVD Store 3), and CPUs (Intel Xeon v4 processors with 24 cores per socket, codenamed Broadwell-EX).

The new tests show large SQL Server databases continue to run extremely efficiently, achieving great performance on vSphere 6.5. Following our best practices was all that was necessary to achieve this scalability – which reminds me, don&#rsquo;t forget to check out Niran&#rsquo;s new SQL Server on vSphere best practices guide, which was also just updated.

In addition to performance, power consumption was measured on each ESXi host. This allowed for a comparison of Host Power Management (HPM) policies within vSphere, performance per watt of each host, and power draw under stress versus idle:

Generational SQL Server DB Host Power and Performance/watt

Additionally, this new study compares a virtual file-based disk (VMDK) on VMware&#rsquo;s native Virtual Machine File System (VMFS 5) to a physical Raw Device Mapping (RDM). I added this test for two reasons: first, it has been several years since they have been compared; and second, customer feedback from VMworld sessions indicates this is still a debate that comes up in IT shops, particularly with regard to deploying database workloads such as SQL Server and Oracle.

For more details and the test results, download the paper: Performance Characterization of Microsoft SQL Server on VMware vSphere 6.5

The post SQL Server VM Performance with VMware vSphere 6.5 appeared first on VMware VROOM! Blog.

Updated – Official SQL Server on vSphere best practices guide, March 2017

 Allgemein, Knowledge Base, Updates, VMware, VMware Partner, VMware Virtual Infrastructure, vSphere  Kommentare deaktiviert für Updated – Official SQL Server on vSphere best practices guide, March 2017
Mrz 222017
 

Microsoft SQL Server is the most virtualized enterprise mission critical application today. In recent years it has become a mainstream effort among VMware customers to virtualizecritical databases to allow better agilityand scale while increasing availability and operational efficiency.

The official best practices guide for virtualizing SQL Server is now updated with information regarding vSphere 6.5 and some new lessons learned in the past year.

A big Thank you! is due to:

Allan Hirt (Twitter @SQLHA) for keeping me honest on SQL Server nomenclature

David Klee (Twitter @Kleegeek) for his help reviewing thispaper

Deji Akomolafe (Twitter @dejify) for hisexpertise and contribution

You can read the updated guide
here:http://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/solutions/sql-server-on-vmware-best-practices-guide.pdf

As always, comments and feedback are welcome

Niran

The post Updated – Official SQL Server on vSphere best practices guide, March 2017 appeared first on Virtualize Business Critical Applications.

How to revert an ESXi host to a previous version using DCUI

 Allgemein, Knowledge Base, Updates, VMware, VMware Partner, VMware Virtual Infrastructure, vSphere  Kommentare deaktiviert für How to revert an ESXi host to a previous version using DCUI
Jan 132017
 

This video demonstrates how to revert an ESXi host to a previous version using the Direct User Console Interface (DCUI).

VMware recommends that you back up the configuration data before proceeding with any changes.

Reverting an ESXi host is only available if the host was updated using one of the following methods:

  • VIB installation or removal
  • Profile installation or removal
  • ESXi host updated using VMware Update Manager
  • ESXi host updated from a ISO

Video:

The post How to revert an ESXi host to a previous version using DCUI appeared first on Support Insider.

A look at All Paths Down in vSphere

 Allgemein, Knowledge Base, Updates, VMware, VMware Partner, VMware Virtual Infrastructure, vSphere  Kommentare deaktiviert für A look at All Paths Down in vSphere
Jan 132017
 

Today we have a guest post from Karthick Sivaramakrishnan, who is a 3 year veteran at VMware. His primary field of expertise is vSphere Storage and Site Recovery Manager.

This blog post is centered around how ESXi handles unscheduled storage disconnects on vSphere 5.x and 6.x. An unscheduled storage disconnect means some issue in the vSphere environment has led to All-Paths-Down (APD) for a datastore. An APD situation will be seen when ESXi host does not have any path tocommunicate with a lun on the storage array.

ESXi host can encounter an APD under several conditions. As a result, we may end up having VMs running on a given datastore go down, the host could get disconnected from vCenter, and in worst cases ESXi could become unresponsive.

From vSphere version 5.x and onwards, we are able to discern whether a disconnect is permanent ortransient. Ideally a transient disconnect leads to All Paths Down state and ESXi expects the device to have a temporary disconnect. When we see permanent device loss or PDL the device is not expected to have a non-recoverable issue like a hardware error or the lun is unmapped.

In the below example we see all iSCSI datastores are in inactive state.

To determine what caused this issue we see ESXi logs, particularly vmkernel and vobd. This issue will be evident in the vmkernel logs.

vmkernel log

2017-01-10T13:04:26.803Z cpu1:32896)StorageApdHandlerEv: 110: Device or filesystem with identifier [naa.6000eb31dffdc33a0000000000000028] has entered the All Paths Down state.

2017-01-10T13:04:26.818Z cpu0:32896)StorageApdHandlerEv: 110: Device or filesystem with identifier [naa.6000eb31dffdc33a000000000000002a] has entered the All Paths Down state.

vobd log

2017-01-10T13:04:26.905Z: [scsiCorrelator] 475204262us: [esx.problem.storage.connectivity.lost] Lost connectivity to storage device naa.6000eb31dffdc33a0000000000000028. Path vmhba33:C0:T1:L0 is down. Affected datastores: “Green”.

2017-01-10T13:04:26.905Z: [scsiCorrelator] 475204695us: [esx.problem.storage.connectivity.lost] Lost connectivity to storage device naa.6000eb31dffdc33a000000000000002a. Path vmhba33:C0:T0:L0 is down. Affected datastores: “Grey”.

From these logs we understand that ESXi host has lost connectivity to the datastore. Any virtual machines using the affected datastore may become unresponsive. In this example while the datastores was mounted on ESXi, we lost the network uplink on the nic that was used for iSCSI connection. This was a transient issue and the datastore came up once the network uplink was restored.

In the below example we see Datastore Black is in inactive state.

If we look into the logs to determine whats going on we see these events.

Vmkernel.log

2017-01-09T12:42:09.365Z cpu0:32888)ScsiDevice: 6878: Device naa.6000eb31dffdc33a0000000000000063 APD Notify PERM LOSS; token num:1

2017-01-09T12:42:09.366Z cpu1:32916)StorageApdHandler: 1066: Freeing APD handle 0x430180b88880 [naa.6000eb31dffdc33a0000000000000063]

2017-01-09T12:49:01.260Z cpu1:32786)WARNING: NMP: nmp_PathDetermineFailure:2973: Cmd (0xc1) PDL error (0x5/0x25/0x0) – path vmhba33:C0:T3:L0 device naa.6000eb31dffdc33a0000000000000063 – triggering path evaluation

2017-01-09T12:49:01.260Z cpu1:32786)ScsiDeviceIO: 2651: Cmd(0x439d802ec580) 0xfe, CmdSN 0x4b7 from world 32776 to dev “naa.6000eb31dffdc33a0000000000000063” failed H:0x0 D:0x2 P:0x0 Valid sense data: 0x5 0x25 0x0.

2017-01-09T12:49:01.300Z cpu0:40210)WARNING: NMP: vmk_NmpSatpIssueTUR:1043: Device naa.6000eb31dffdc33a0000000000000063 path vmhba33:C0:T3:L0 has been unmapped from the array

After some time passes you will see this message:

2017-01-09T13:13:11.942Z cpu0:32872)ScsiDevice: 1718: Permanently inaccessible device :naa.6000eb31dffdc33a0000000000000063 has no more open connections. It is now safe to unmount datastores (if any) and delete the device.

In this case the lun was unmapped from the array for this host and that is not a transient issue. Sens data 0x5 0x25 0x0 corresponds to &#rsquo;LOGICAL UNIT NOT SUPPORTED&#rdquo; which indicates the device is in Permanent Device Loss (PDL) state. Once ESXi knows the device is in PDL state it does not wait for the device to return back.

ESXi only checks ASC/ASCQ and if it happens to be 0x25/0x0 or 0x68/0x0, it marks device as PDL.

VMware KB 2004684 has in-depth information around APD and PDL situations. It also talks about planned and unplanned PDL. You can read it here:Permanent Device Loss (PDL) and All-Paths-Down (APD) in vSphere 5.x and 6.x (2004684)

Further on in the hostd logs you will see some additional events that will correlate to storage connection. Look for the below event id&#rsquo;s.

Event ID : esx.problem.storage.connectivity.lost

&#rsquo;esx.problem.storage.connectivity.lost&#rdquo; event indicates a loss in connectivity to the specified storage device. Any virtual machines using the affected datastore may become unresponsive.

Event ID : esx.problem.scsi.device.state.permanentloss

&#rsquo;esx.problem.scsi.device.state.permanentloss&#rdquo; event indicates a permanent device loss.

The post A look at All Paths Down in vSphere appeared first on Support Insider.