This post has been republished via RSS; it originally appeared at: Running SAP Applications on the Microsoft Platform articles.First published on MSDN on Nov 02, 2018
As Azure became a very popular secure and scalable platform to deploy mission critical workload like SAP application on it, Microsoft itself tries to lower the bar to move your application to Azure even more. One of the measures Microsoft took was announced in this blog:
In essence, the blog announces free extended Security Patches for Windows Server 2008(R2) and SQL Server 2008(R2) beyond the end of the usual 10 year support life cycle period. Though this sounds appealing in a first glance, there are many reasons why you as SAP customer should not take this extension as motivation to delay a move of your mission critical system to more recent Windows Server and SQL Server releases.
Why do we not recommend leveraging these older Window and SQL Server releases in Azure for SAP workload other similar large scale Enterprise Mission Critical applications? Short answer is that we introduced a lot of features and functionalities into the Windows Server 2012 family and Windows Server 2019 and more recent SQL Server releases that either accommodate and improve the handling of SAP workload or improve the integration into Azure as an IaaS platform. SAP NetWeaver based systems typically run your company’s most critical business processes and shouldn’t be left running on 10 year old operating system and database platform.
When we look into details of the changes in more recent Windows Server versions and Azure that improve integration, scalability and reliability then the following documented changes are noteworthy:
- On Azure side Accelerated Networking is a key technology which significantly improving the scalability of SAP systems in Azure and reduces the latency between significantly. This functionality is supported for more recent windows Server OS as guest OS only. For more details see: https://docs.microsoft.com/en-us/azure/virtual-network/create-vm-accelerated-networking-powershell
- On Azure side, not all VMs can be run on older versions of Windows Server. E.g. all the M-Series VMs that have more than 64 vCPUs are requiring at least Windows Server 2016 as guest OS.
- Windows Server Storage Spaces is also a significant improvement from Windows Server 2012 on. Windows Storage Spaces is the default way to create high performance volumes for hosting database data and log files on the Windows guest OS. Storage Spaces is superior to Striping offered with earlier releases of Windows. More details can be found here: https://docs.microsoft.com/en-us/windows-server/storage/storage-spaces/overview
Windows Server clustering experienced more than significant improvements over the course of the last 6 years. Functionality like:
- Rolling upgrades of cluster nodes which was introduced with Windows Server 2016 ( https://docs.microsoft.com/en-us/windows-server/failover-clustering/Cluster-Operating-System-Rolling-Upgrade )
- Cloud witness for Azure deployments. Especially for deploying in Azure, the usage of the Windows Server 2016 introduced feature of the Azure cloud Witness improves reliability of SAP deployments in Azure significantly ( https://docs.microsoft.com/en-us/windows-server/failover-clustering/deploy-cloud-witness )
- SAP using Windows Clustering as HA for Central Services using Windows Server 2016 Scale-out File Services (SOFS). More documentation can be found here: https://docs.microsoft.com/en-us/azure/virtual-machines/workloads/sap/sap-high-availability-infrastructure-wsfc-file-share
These are the most obvious reasons. Besides those there were a lot of improvements that made it into more recent Windows kernels that were resulting out of issues SAP customers cases. Severe improvements regarding scalability and reliability are part these newer OS releases which in a lot of cases improve the efficiency of SAP workload in virtualized environments. As you read this list, it is clear that we highly recommend using Windows Server 2016 as operating system for your SAP deployments in Azure.
On SQL Server side, the changes are even more impressive. When we look at the list, then the first striking improvements with SQL Server 2012 and expanded and improved in more recent releases are:
SQL Server Column store: SQL Server Column Store is a ground breaking feature that can be leveraged with SAP BW, but also with other NetWeaver based SAP software. The best SAP centric documentation can be found in these articles: https://blogs.msdn.microsoft.com/saponsqlserver/tag/columnstore/ .
Besides columnstore for SAP BW, SQL Server 2016 introduced modifiable non-clustered columnstore indexes that can be applied to indexes to SAP ERP systems and other non-BW SAP NetWeaver applications.
- SQL Server AlwaysOn: Is a major improvement to SQL Server Database Mirroring. SQL Server AlwaysOn is not only a complete high availability and disaster recovery functionality, but also allows moving backups to the secondary nodes. Combined with Windows Server 2016 Cloud Witness and SQL Server Distributed Availability Groups, this is the ideal functionality to configure high availability and disaster recovery in Azure IaaS deployments.
- SQL Server Query Store: allows you to track long term query performance. In cases of performance degradation the new functionality allows you to rollback the execution of a query to the best performing one. More details can be read in: https://docs.microsoft.com/en-us/sql/relational-databases/performance/monitoring-performance-by-using-the-query-store?view=sql-server-2017
- Resumable online Index builds allow to build indexes piecemeal in chunks with lower workload. This functionality got introduced in SQL Server 2017. More details can be found here: https://www.mssqltips.com/sqlservertip/4987/sql-server-2017-resumable-online-index-rebuilds/
- SQL Server consistency checks (checkdb) were improved majorly in SQL Server 2016. The improvements resulted in way better throughput of checkdb and better resource control.
Other very important functionality that helps SQL Server to leverage Azure capabilities can be listed as:
- Backup against Azure BLOB storage: This feature introduced in more recent SQL Server releases allows you to directly backup against Azure storage blobs. More information can be found in these articles: https://docs.microsoft.com/en-us/sql/relational-databases/backup-restore/sql-server-backup-and-restore-with-microsoft-azure-blob-storage-service?view=sql-server-2017
- SQL Server Managed Backup to Azure allows automatic backups that are stored in Azure storage. for more details see: https://docs.microsoft.com/en-us/sql/relational-databases/backup-restore/sql-server-managed-backup-to-microsoft-azure?view=sql-server-2017
- Placement of SQL Server data and log files directly on Azure storage blob storage. For more details see: https://docs.microsoft.com/en-us/sql/relational-databases/databases/sql-server-data-files-in-microsoft-azure?view=sql-server-2017
- SQL Server snapshot backup when using Azure storage blobs. More details are documented in https://docs.microsoft.com/en-us/sql/relational-databases/backup-restore/file-snapshot-backups-for-database-files-in-azure?view=sql-server-2017
- Major improvements to SQL Server Transparent Data Encryption (TDE0 and the usage of Azure Key Vault which were applied to SQL Server 2014, 2016 and 2017 Service Packs and patches. Older versions of SQL server are issuing way more calls to the third party EKMM tools like Azure key Vault and with that slow down operations like backup and restore of databases when using SQL Server TDE.
Other functionality which is less more obvious for SAP workloads are
- SQL Server 2016 introduced functionality to accelerate execution of SAP CDS views and functions related to CDS views
- In the latest SQL Server releases, DMVs got changed and added to improve functionality of NetWeaver’s DBACockpit
Given all the new functionalities and the improvements that make a big difference to run SAP workload, it is highly recommended moving to a minimum of SQL Server 2016 or consider SQL Server 2017 when moving your SAP workload to Azure IaaS. Instead of staying on nearly 10 year old releases of Windows and SQL Server that never got really adapted to the usage in Azure or for more recent SAP releases or features (like SAP CDS view).