Today many customers are looking at ways to consolidate their IT systems.  By way of application consolidation through hardware consolidation using partitioning methodologies like LPARs, database consolidation using Named Instances, or by way of the most popular method today which is virtualization using hypervisors like Hyper-V and VMware.  As many of you already know, the consolidation of these IT components help to lower cost of ownership by reducing the number operating systems or databases, reducing hardware footprint in datacenters, and even improving DR Failover.  Now most customers today have already consolidated or have begun working on a strategy to consolidate their environments.  However, in most cases they may have missed the mark when it comes to truly taking advantage of all the benefits consolidating an IT infrastructure could have.  Our goal with this series of blogs is to help customers start thinking of how they can use major IT engagements like consolidation projects to introduce new or revamp existing IT standards.  For most of you reading this, the next response is more than likely “what do you mean”!

Over the past 6 years the Microsoft LOB CoE has been heavily focused on working with new customers on replatforming and deploying SAP on the Microsoft platform.  During those years our customers have been asking the CoE to focus on how they can get the most out of their consolidation (or replatforming) efforts during these engagements.  Based on this we have started taking into consideration other areas that impact IT which we call “Value Added Services”.  Items that we place emphasis on include Standardization, Optimization, Streamlining and Simplification of the architecture for deployment, testing, maintenance and overall operational services.

For this series of blogs we will focus on Standardization of the platform architecture (application, database, server, etc…) for projects like consolidation efforts.  Standardization provides customers with the ability to define templates for rapid deployment of applications, simplify operations and administration, provide consistency in application and platform behavior whether daily operations or during testing.  It also allows for alignment of IT with the Business and its expectations surrounding IT’s behavior in supporting OLAs, which support SLAs.  The standards mentioned in this series of blogs can also be incorporated for Replatform and New Deployment projects.

SAP components used as examples will SAP ECC, BI, APO, Solman and PI.  So the first question is where to start!  With customers planning the consolidation of SAP environments (new or existing) on the Microsoft platform, we start with sizing the environment.  Sizing the environment is a practice for all existing and new SAP customers and done by way of either gathering statistics or using the SAP Quicksizer tool.  This information from either method will be used to provide a sizing footprint that can be used for creating some of the standards for our consolidation efforts.  How is that?  Well an SAP sizing, using Quicksizer for new deployments or information gathered for existing environment will be utilized to determine the number of SAPs (SAP performance metric) for each SAP application environment (Development, Test, Production, etc…).  Next the hardware vendors will take the SAPs sizing information and convert it into a hardware sizing that includes the number of processors (cores), memory, disk space and so forth.  The sizing process usually runs about 1 – 2 months depending on the customer, new or existing implementation, hardware vendor, and back and forth discussions.  Here is an example of the results for a new virtual environment from such an effort:

 As can be seen we now know the amount of resources required for our SAP environments.  Although this does not show a detailed breakdown it gives you an idea of what you are working with from a resources point of view.  A deeper dive into the spread sheet would reveal a breakdown of number of VMs per environment, development, test, sandbox, production and other systems making up the landscape. 

Based on the sizing information from the hardware vendor we can now focus on writing our standards that will align with our consolidation methodology.  For the consolidation methodology we will utilize the following standard developed from the pharmaceutical customer engagement.  Using this as an example will allow us to simplify this discussion and avoid a lengthy conversation over a standard that took weeks to agree upon. The consolidation methodology will consist of the following:

• All Application Single Points of Failure will use clustering technology in order to achieve a four 9s’ Availability of Service requirement
  • All Central Services Instances will be clustered
  • All Central Services Instances will be part of a SAP Multi-SID cluster
• All SAP Applications will be virtualized (includes all SAP Application Servers, Central Services and Bolt-On Applications)
• All SAP Application Databases will be on physical servers (Dev, Test, Prod, etc…)
• All SAP Application Databases will be consolidated to 4 node clusters using named instances
• All Bolt-on Application Database will be virtualized (these are small instances)
• All HA methodologies will be used in Development, Test and Production environments for testing and validation purposes.
• Architecture will be designed for rapid deployment of applications in alignment with the current Service Catalog
• Architecture will be designed for ease of administration

So these are just a few of our requirements, but enough to get us going on standardizing our configuration standard for the virtual environments.  Many of these standards will be carried forward into Part 2 of this blog when we focus on standards for our database consolidation effort.  However, keep in mind that this is a pharmaceutical customer we are using as an example and therefore we have standards related to qualified and non-qualified environments we must follow for compliance with government standards.

Now we take all of the above information and begin to develop our standards.  Some have already been outlined for us in the previous bullets.  For example, we know we will use clustering to eliminate SPOFs, SQL Server Named Instances for consolidation of DBs, Multi-SID for consolidation of Central Services and all applications will be virtualized.  Let’s start with our virtualization standard.  We first need to develop VM footprints for the SAP applications as part of the virtualization standards.  Based on the previous sizing information and the more detailed spreadsheet (not seen here), we can easily deduct that we will have VM sizes from X-Small to X-Large as part of our configuration standard.  We refer to this as our T-Shirt sizings.  The virtual server throughput capacity listed in the ‘Estimate SAPS’ column (not shown) is an extrapolation based on the number of vCPUs as a fraction of the total CPUs in the physical servers. The associated virtual resources allocated to each category of virtual machines are summarized in the table below:   VMs that will look like the following:

Application Server VM T-Shirt Sizing

Next we define the number of work processes we can deploy per image and add a column to represent this.  The following was based on a combination of SAP standards found in SAP OSS Notes and the customer’s experience.

Application Server VM T-Shirt Sizing (modified)

As part of the standardization process we also need to develop a pattern for the types to be utilized on each of the SAP Application VM.  The distribution of WP between the different types must fit into the model above.  This is again based on SAP standard and customer experience.  So results will vary by customer.  Below we are using only Medium and Large as an example, but the information is developed using guidance from SAP OSS Notes and resources, and customer historical experience:

Example of WP Type Breakdown

As can be seen we have defined the number of Dialog, Batch, Spool and Update process that each image will have.  The next step following this would be to define the volume sizes for the VMs.  For example, page file size and volume size would be based on the amount of memory each VM has.    Following that you would look at defining the type of drivers, NIC team, patching levels to be used as part of the VM standard.  An example of this would be would be using Secure Path over MPIO for the Virtual Host Bust Adapter, since the VMs would reside on a SAN.  Another example would be NIC configuration Load Balancing over Fault Tolerance.  

Now that we have defined the VM standards for size of VMs, number of work processes, and process types, we need to define which applications fit into which templates or T-Shirt sizing as we call it.  Below is an example of how we broke up ABAP and JAVA instances to fit into the T-Shirt sizing.

 Applications Mapped to T-Shirt Sizing

                Note: Although Java instances are listed above, they are not referred to in Part 1 of this blog.

Once we have completed defining the standards for the VM standards in our consolidation effort, then the next step is to define our Host system standards.  The standards will be the following:

• Two Host Server Cluster environments will exist.
  • The first Virtual Host environment (Host Cluster A) will house SAP Application Servers and Bolt-On Application VMs. 
    • High Availability and Fault Tolerant capabilities will be utilized for the availability of the Application VMs.
  • The second Virtual Host environment (Host Cluster B) will house clustered SAP Central Services and other applications requiring clustering of SPOFs.
    • All SAP Central Services will be deployed on Virtual Cluster using SAP’s Multi-SID install methodology. 
    • All additional applications requiring clustering will be housed in (Host Cluster B)
    • Affinity and Anti-Affinity rules will be utilized to avoid Guest VM nodes running on the same Host.
  • General Standard
    • Each host will consist of two Dual Port HBAs
    • Each host will consist of three Dual Port NICs

There are many more areas to address than listed here from standardization point of view.  However, since this is provided as part of the Architecture Design Workshop conducted by the LOB CoE during the design phase of the engagement, I am excluding some of these items.  In other words, I do not want to give away too much in this blog J,  but provide just enough for customers to get the picture.  Consolidation, replatforming or new deployment projects provide customers with the perfect opportunity to take advantage of implementing or updating IT standards for platform, infrastructure or applications.  Focus on using standards to simplify deployment, administration and maintaining of applications.  In closing, the above standards were designed to fit the needs of the customer that we worked with and are based on Industry, SAP, Microsoft and historical customer data for an existing SAP environment.  These standards were not meant to meet the needs of all customers, where dramatic variances could be introduced based on many factors, including existing or new deployment, historical data and platform version (Server/OS/DB).  These standards are meant to show customers what can and should be done during Architecture Design Workshops for consolidation, replatforming, and new deployment projects, which provide IT with the opportunity to introduce or revamp IT standards.

For customers interested in learning more about Architecture Design Workshops delivered by Microsoft’s Line of Business (LoB) CoE.  Please email the LoB CoE Team at lobapps@microsoft.com.

 This blog and other blogs included in this series were developed from material created by the following SMEs and Architects:

• Ben Trinh
• Chad Cox
• Ben Ellsworth
• Grant Carter
• Fazil Osman

 The above resources were also contributor to this blog, which again the first in a series of many.