In part 1 we introduced the concept of SAP HANA Application Workload guidance and using example business requirements to come up with a workload and vSphere cluster design for the SAP environment. In part 2 we looked at storage, network and security design for the proposed customer environment. In part 3 we looked at 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.
In part 1 we introduced the concept of SAP HANA Application Workload guidance and using example business requirements to come up with a workload and vSphere cluster design for the SAP environment. In part 2 we 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.
SAP Business Suite 4 SAP HANA (or SAP S/4HANA) is the SAP Business Suite that is built on SAP’s in memory columnar database platform SAP HANA. SAP HANA®, the in-memory real-time platform, was initially introduced as a physical appliance and has steadily evolved to include support for virtualization with VMware vSphere® and SAP HANA tailored data center integration (TDI). Virtualized SAP HANA is now supported in scale-up and scale-out configurations in VMware® environments. Running SAP HANA on vSphere offers customers agility, resource optimization, and ease of provisioning. This solution enables SAP customers to provision instances of SAP HANA more quickly and effectively by using vSphere virtual machines (VM). Using the SAP HANA platform with the vSphere virtualization infrastructure constitutes an optimized environment for achieving a unique, cost-effective solution. VMware capabilities such as VMware vSphere vMotion®, VMware vSphere Distributed Resource Scheduler™ (vSphere DRS), and VMware vSphere High Availability (vSphere HA) are inherent components of the virtualized SAP HANA platform.
The need exists for a comprehensive, “end-to-end” solution that describes the implementation of a virtual SAP HANA deployment. VMware Solutions Labs was chosen to first develop a robust validated end to end solution. This is the first solution that takes the VMware Validated Design concept and then uses its components to run an Enterprise application like SAP on top of it. This prescriptive approach called Application Workload Guidance Design applies the VMware Validated Design (VVD) to SAP S/4HANA on the vSphere platform.
As a Staff Partner Architect at VMware, I tend to look at our platform and products through a slightly different lens than some of my colleagues. Rather than focusing solely on our feature rich product sets and platform, I take a top down approach and identify which of these features are most interesting for mission/business critical deployments in a Software-Defined Data Center (SDDC).
VMware NSX is one of those game changing technologies which should interest application owners, database architects, CIOs, and of course network IT professionals. You can think of NSX as a network hypervisor, as such NSX administrators now have the ability to abstract and reproduce a complete set of layer 2 to layer 7 networking services. The ability to abstract and reproduce layer 2 to layer 7 networking services is certainly meaningful to network operations but what does it mean to enterprise architects? Why should our customers care, and why should CIOs care? The answer is hair-pinning. Continue reading →
In this blog post we are showcasing the ability to stretch an Oracle RAC solution in an Extended Oracle RAC deployment between multi-datacenter and using VMware NSX for L2 Adjacency.
With Extended Oracle RAC , both Storage and Network virtualization needs to be deployed to provided high availability, workload Mobility, workload balancing and effective Site Maintenance between sites. Continue reading →
In the first partwe looked at public, private and Hybrid Cloud and their characteristics. In this part we will look at the common characteristics of business critical applications. In the second part , we looked at how some of these characteristics relate to the different types of Cloud infrastructure. In this final part we will look at he lifecycle of a business critical application in the cloud and the conclusion. Continue reading →
In the first part we looked at public, private and Hybrid Cloud and their characteristics. In this part we will look at the common characteristics of business critical applications. We will also look at how some of these characteristics relate to the different types of Cloud infrastructure.
Common Characteristics of Business Critical Applications (BCA):
Business critical applications typically have very stringent SLAs and have a direct impact on the business. These are the crown jewels of the business that need to be managed with utmost care to avoid loss of productivity, data and potential revenue. These are the major factors can have a direct impact on these applications such as the following:
The cloud transformation is now for real. Customers have a stated long-term goal of running a majority of their applications in the cloud. Gartner predicts that public cloud services to grow by 16.5% in 2016. The highest growth area is cloud infrastructure, which is projected to grow at 38.4% in 2016. Today’s CIOs understand that a clear cloud strategy is a critical component of managing their information technology needs.
While developers have adapted to the cloud and its benefits, traditional enterprise business critical applications are not very prevalent in the cloud. Until recently most of these applications had not even been virtualized. Just in the past two to three years a majority of these enterprise applications have been virtualized. What are the unique characteristics of these applications that need to be considered for cloudification? In this three part blog series, we will analyze the top ten BCA requirements and how different types of cloud infrastructures satisfy them. In part 1 we will look at the different types of cloud infrastructures and their characteristics. Continue reading →
Recently, I have been asked this question: should we enable Storage I/O control on datastores used by our production databases considering it could prevent my VMs from consuming all the resources they need? The answer is yes, SIOC will not harm your performance, actually it can save you from a very bad day in IT land, and it’s all about the threshold.
Before I dive deeper into that a bit of background:
Storage I/O control is a technology which provides I/O prioritization for VMDKs that reside on a shared datastore, the VMDKs can reside on different hosts but have to be managed by the same vCenter. This is to contrast with adaptive queuing which is an ESXi technology. Anyway, back to SIOC, when a latency threshold is crossed for a shared datastore Storage I/O control will kick in and will start prioritizing access to that datastore based on the proportional shares mechanism, the outcome will be that VMs with higher shares will get more throughput (IOPS) in lower latency than VMs with lower shares. By default all VMs have the same amount of shares and a fair access to the datastore, in that case SIOC will protect from the “noisy neighbor” issue from happening making sure that no one VM monopolizes access to that datastore. Continue reading →