April 2019 - Seite 21 von 85 - Cloud Computing Köln

Cloud optimization is critical to ensuring you get the most out of your Azure investment, especially in complex environments with many Azure subscriptions and resource groups. Azure Advisor helps you optimize your Azure resources for high availability, security, performance, and cost by providing free, personalized recommendations based on your Azure usage and configurations.

In addition to consolidating your Azure recommendations into a single place, Azure Advisor has a configuration feature that can help you focus exclusively on your most important resources, such as those in production, and save you remediation time. You can also configure thresholds for certain recommendations based on your business needs.

Save time by configuring Advisor to display recommendations only for resources that matter to you

You can configure Azure Advisor to provide recommendations exclusively for the subscriptions and resource groups you specify. By narrowing your Advisor recommendations down to the resources that matter the most to you, you can save time optimizing your Azure workloads. To get you started we’ve created a step-by-step guide on how to configure Advisor in the Azure portal (UI). To learn how to configure Advisor in the command line (CLI), see our documentation, “az advisor configuration.”

Please note that there’s a difference between Advisor configuration and the filtering options available in the Azure portal. Configuration is persistent and prevents recommendations from showing for the unselected scope (shown in the screenshot above). Filtering in the UI (shown in the screenshot below) temporarily displays a subset of recommendations. Available UI filters include subscription, service, and active versus postponed recommendations.

Configuring thresholds for cost recommendations to find savings

You can also customize the CPU threshold for one of our most popular recommendations, “Right-size or shutdown underutilized virtual machines,” which analyzes your usage patterns and identifies virtual machines (VMs) with low usage. While certain scenarios can result in low utilization by design, you can often save money by managing the size and number of your VMs.

You can modify the average CPU utilization threshold Advisor uses for this recommendation to a higher or lower value so you can find more savings depending on your business needs.

Get started with Azure Advisor

Review your Azure Advisor recommendations and customize your Advisor configurations now. If you need help getting started, check our Advisor documentation. We always welcome feedback. Submit your ideas or email us with any questions or comments at advisorfeedback@microsoft.com.
Quelle: Azure

23. April 2019

da Agency

Migrating SAP applications to Azure: Introduction and our partnership with SAP

Just over 25 years ago, Bill Gates and Hasso Plattner met to form an alliance between Microsoft and SAP that has become one of our industry’s longest lasting alliances. At the time their conversation was focused on how Windows could be the leading operating system for SAP’s SAPGUI desktop client and when released a few years later, how Windows NT could be a server operating system of choice for running SAP R/3. Not long after in 1996 we started our own SAP project based on Windows NT/SQL Server and complimented our SAP alliance that has continued to evolve since then, while meeting the needs of SAP customers of all sizes.

That said, with 90 percent of today’s Fortune 500 customers using Microsoft Azure and an estimated 80 percent of Fortune customers running SAP solutions, it makes sense why SAP running on Azure is a key joint initiative between Microsoft and SAP. At the SAPPHIRENOW conference in 2016, Microsoft CEO Satya Nadella and SAP CEO Bill McDermott were on stage talking about the significant progress of SAP and Azure, especially with the release of SAP HANA on Azure Large Instances. Most of our conversations with large scale SAP customers at the time were about us providing basic SAP on Azure information (i.e. kicking the tires). We’ve made continued progress since then as we released the M-Series virtual machine size (up to 4TB of memory), SAP HANA Large Instances (up to 20 TB memory) and then provided support for the SAP Cloud Platform, SAP HANA Enterprise Cloud on Azure, and Active Directory Single-Sign-On (SSO). Last year we announced our plans to release larger sizes of the M-Series (up to 12TB) and our conversations with customers have also evolved beyond cursory information gathering and into discussions about SAP on Azure productive use.

Today more and more SAP customers are simply choosing Azure for running SAP as we continue to demonstrate successful deployments of SAP on Azure and make progress of Azure as a mission critical cloud platform with features such as Azure Site Recovery (ASR) and Availability Zones. Customer conversations happen at both executive and technical levels as we discuss not just advantages of running SAP on Azure like cost (e.g. shifting from CapEx to OpEx and utilizing Azure Reserved Instances), but also other key aspects such as scalability, flexibility, and security.

As an example of scalability, SAP customers have the ability to scale their SAP environment during a month-end financial closing when more computing capacity is typically needed, and then right-size immediately after month-end for typical operations during the month. From a flexibility and agility perspective, one of the more frequent topics of conversation we’ve had with customer’s SAP Basis teams has been about one of their biggest pains, their current on-premises experience of ordering and provisioning new hardware for their SAP landscape. Typically this is an on-premises process that can take weeks, if not several months depending on size and type of customer, and all the while SAP application teams are chomping at the bit waiting to make progress during their phase of an SAP project. With SAP on Azure agile provisioning is possible by leveraging new features like shared images, and the integration of the provisioning process with automation capabilities like Terraform, Ansible, Puppet, and Chef. This leads to a faster and more dependable provisioning process.

SAP customers also are deploying initial SAP S/4HANA environments by leveraging the SAP Cloud Appliance Library which copies and deploys pre-built images into a customer’s Azure subscription. For example, deployment of SAP Model Companies via SAP CAL has become popular during the blueprinting phase of SAP S/4 projects and this helps application teams by providing a reference S/4HANA implementation to then jumpstart their own custom implementation of S/4.

From a development perspective we’ve also offered more flexibility for SAP developers with solutions such as SAP Cloud Platform on Azure. SAP application developers can now use Azure to co-locate application development next to SAP ERP data and boost development productivity, while accessing SAP ERP data at low latencies for faster application performance. This can be done with Azure’s platform services such as Azure Event Hubs for event data processing and Azure Storage for unlimited inexpensive storage. It’s also been impressive to see customers like Coats,the world’s oldest thread manufacturer, integrate other Azure services like Internet of Things (IoT) capabilities on their manufacturing floors with their SAP environments also running on Azure.

For security and compliance Microsoft spends over $1B per year in R&D on security that typical customers cannot. This has led to Azure having inherent security capabilities such as Azure Security Center and allows customers to have the confidence that their cloud provider meets applicable government and industry compliance standards.

This takes us to the release of an SAP on Azure technical blog series over the next 3 weeks leading up to this year’s SAPPHIRENOW conference in Orlando. With more and more customers having chosen Azure as the cloud platform for running SAP, they’re wanting more detailed technical guidance. This is one of the reasons a new team within our Azure Global Customer Advisory Team (AzureCAT) organization was formed called AzureCAT SAP Deployment Engineering. Our team is focused on working with the largest and most complex SAP customers running their SAP environments in Azure. Working with these customers enables us to provide more direct customer SAP-related feedback to our Azure engineering teams and further enhance our SAP on Azure technical roadmap ensuring we provide the best features for SAP customers of all sizes.

Our first SAP on Azure technical blog post of this series is by my colleague, Will Bratton, who will step you through key technical design considerations for deploying and running SAP on Microsoft Azure. These important considerations include security, performance, scalability, availability, recoverability, operations, and efficiency.

Next week my colleague Marshal Whatley dives into the world of migrating SAP ERP and SAP S/4HANA to Azure, much as our own internal SAP implementation has moved to Azure and is moving to S/4HANA. The week after next my colleague Troy Shane will cover migration of SAP BW4/HANA, as well as a view on how best to deploy BW4/HANA in a scale-out architecture today and in the near future with the new Azure NetApp Files.

Finally, to all of our existing SAP on Azure customers, we thank you for betting your business on Azure and we look forward to continuing to meet your needs as a mission critical cloud platform for SAP. To prospective SAP customers looking at Azure, we look forward to answering all of your questions at SAPPHIRENOW and beyond.
Quelle: Azure

23. April 2019

da Agency

Best practices in migrating SAP applications to Azure – part 1

This is the first blog in a three-part blog post series on best practices for migrating SAP to Azure.

Designing a great SAP on Azure architecture

In this blog post we will touch upon the principles outlined in “Pillars of a great Azure architecture” as they pertain to building your SAP on Azure architecture in readiness for your migration.

A great SAP architecture on Azure starts with a solid foundation built on four pillars:

Security
Performance and scalability
Availability and recoverability
Efficiency and operations

Designing for security

Your SAP data is likely the treasure of your organization's technical footprint. Therefore, you need to focus on securing access to your SAP architecture by way of secure authentication, protecting your application and data from network vulnerabilities, and maintaining data integrity through encryption methods.

SAP on Azure is delivered in the Infrastructure-as-a-Service (IaaS) cloud model. This means security protections are built into the service by Microsoft at the physical datacenter, physical network, physical host level, and the hypervisor. Therefore, for those areas above the hypervisor (e.g. the guest operating system for SAP), you need to undertake a careful evaluation of the services and technologies you select to ensure you are providing the proper security controls for your architecture.

In terms of authentication, you can take advantage of Azure Active Directory (Azure AD) to enable single-sign-on (SSO) to your S/4HANA Fiori Launchpad. Azure AD can also be integrated with the SAP Cloud Platform (SCP) to provide single-sign-on to your SCP services which can also be run on Azure.

Network Security Groups (NSG) allow you to filter network traffic to and from resources in you virtual network. NSG rules can be defined to allow or deny access to your SAP services, for instance, allowing access to the SAP Application ports from on-premises IP addresses ranges and deny public Internet access.

With regards to data integrity, Azure Disk Encryption helps you encrypt your SAP virtual machine disks where both the operating system and data volumes can be encrypted at rest in storage. Azure Disk Encryption is integrated with Azure Key Vault which controls and manages your encryption keys. Many of our SAP customers choose Azure Disk Encryption for their operating system disks and transparent DBMS data encryption for their SAP database files. This approach secures the integrity of the operating system and ensures database backups are also encrypted.

To dig further into topics of interest in the security area, you can refer to our Azure Security documentation.

Designing for performance and scalability

Performance is a key driver for digitizing business processes, and having a performant SAP application is crucial for end users to work efficiently without frustration. Therefore, it is important to undertake a quality sizing exercise for your SAP deployment and to right-size your Azure components – compute, storage, and network.

SAP Note #1928533 details the SAPS value for Azure Virtual Machines supported to run SAP Applications, and within the links below you can attain the network and storage throughput per Azure VM type:

Sizes for Windows Virtual Machines in Azure
Sizes for Linux Virtual Machines in Azure

The agility of Azure allows you to scale your SAP system with ease, for example, increasing the compute capacity of the database server or horizontally scaling through the addition of application servers when demand arises. This includes temporarily beefing up the infrastructure to accelerate your SAP migration throughput and reduce the downtime.

We recommend you leverage virtual machine accelerators for your SAP application and database layers. Enable Accelerated Networking on your virtual machines to accelerate network performance. In scenarios where you will run your SAP database on M-Series virtual machines, consider enabling the Write Accelerator durable write cache on your database log volumes to improve write I/O latency. Write Accelerator is mandatory for productive SAP HANA workloads to ensure a low write latency (sub ms) to the /hana/log volume.

Use Premium Storage Managed Disks for the SAP database server to benefit from high-performance and low-latency I/O. Be mindful, that you may need build a RAID-0 stripe to aggregate IOPS and throughput to meet your application needs. In the case of SAP HANA workloads, we cover storage best practice within our documentation, “SAP HANA infrastructure configurations and operations on Azure.”

ExpressRoute or VPN facilitates connectivity for on-premises SAP end users and application interfaces connecting to your SAP applications in Azure. For production SAP applications in Azure, we recommend ExpressRoute for a private, dedicated connection which offers reliability, faster speed, lower latency, and tighter security. Be mindful of latency sensitive interfaces between SAP and non-SAP applications, you may need to define migration “move groups” where groups of SAP applications and non-SAP applications are landed on Azure together.

Designing for availability and recoverability

Operational stability and business continuity are crucial for mission critical, tier-1 SAP applications. Designing for availability ensures that SAP application uptime is secured in the event of localized software or hardware failures. In the case of productive SAP applications, we recommend the virtual machines which run the SAP single points of failure, such as the system central services A(SCS) and database are deployed in Availability Sets or Availability Zones, to protect against planned and unplanned maintenance events. This also applies to the SAP Application servers where a few smaller servers are recommended instead of one larger application server. Operating system cluster technologies such as Windows Failover cluster or Linux Pacemaker would be configured on the guest OS to ensure short failover times of the A(SCS) and DBMS. DBMS synchronous replication would be configured to ensure no loss of data.

Designing for recoverability means recovering from data loss, such as a logical error on the SAP database or from large scale disasters, or loss of a complete Azure region. When designing for recoverability, it is necessary to understand the Recovery Point Objective (RPO) and Recovery Time Objective (RTO) of your SAP Application. Azure Regional Pairs are recommended for disaster recovery which offer isolation and availability to hedge against the risks of natural or man disasters impacting a single region.

On the DBMS layer, asynchronous replication can be used to replicate your production data from your primary region to your disaster recovery region. On the SAP application layer, Azure-to-Azure Site Recovery can be used as part of an efficient, cost-conscious disaster recovery solution.

It is essential to carefully consider both availability and recoverability within the design of the SAP deployment architecture. This will protect your business from financial losses resulting in downtime and data loss.

Designing operations and efficiency

Your move to Azure also presents an opportunity to undertake an SAP system rationalization assessment. Do you need to move all SAP systems or can you decommission those which are no longer used? For example, Microsoft-IT decommissioned approximately 60 virtual machines as part of our SAP migration to Azure.

In terms of efficiency, focus on eliminating waste within your SAP on Azure deployment. Post go-live, review the sizing. Can you reduce the size of your virtual machine based on utilization? Can you drop disks which are not being used?

De-allocating or “snoozing” of virtual machines can bring you tremendous cost savings. For example, running your SAP Sandbox systems 10 hours x 5 days, instead of 24 hours x 7 days would reduce your costs by approximately 70 percent in a pay-as-you-go model. Where your SAP application needs to run 24 x 7 opt for Azure Reserved Instances to drive down your costs.

Establishing infrastructure manually for each SAP deployment can be tedious and error prone, often costing hours or days if multiple SAP installation are required. Therefore, to improve efficiency it makes sense to automate your SAP infrastructure deployment and software installation as much as possible. Embrace the DevOps paradigm using infrastructure-as-code to build new SAP environments as needed, such as in SAP project landscapes. Below, some links to give you a head start on automation.

Automating SAP deployments in Microsoft Azure using Terraform and Ansible
Accelerate your SAP on Azure HANA project with SUSE Microsoft Solution Templates

As you embark on your SAP to Azure journey, we recommend that you dive into our official documentation to deepen your understanding of using Azure for hosting and running your SAP workloads.

Use our SAP Workload on Azure Planning and Deployment Checklist as a compass to navigate through the various phases of your SAP migration project. Our checklist will steer you in the right direction for a quality SAP deployment on Azure.

We also recommend that you explore our whitepaper, “Migration Methodologies for SAP on Azure” where we dig into the various migration options to land your SAP estate on Azure. In scenarios where your SAP application has a giant database footprint we also have your covered. For more information refer to the blog post, “Very Large Database Migration to Azure.”

The next blog in our series will focus on the migration to Suite-on-HANA and S/4HANA on Azure.
Quelle: Azure