Kategorie: Microsoft Azure

Best practices in migrating SAP applications to Azure – part 2

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

Journey to SAP S/4HANA from SAP Business Suite

A common scenario where SAP customers can experience the speed and agility of the Azure platform is the ability to migrate from a SAP Business Suite running on-premises to SAP S/4HANA in the cloud. This scenario is a two-step process. The first step being migration from enterprise resource planning (ERP) on-premises to the Suite on HANA in Azure, and then converting from Suite on HANA to S/4HANA.

Using the cloud as the destination for such a migration project has the potential to save organizations millions of dollars in upfront cost for infrastructure equipment, and can shave roughly around 12 to 16 weeks off the project schedule as the most complex components of the infrastructure are already in place and can easily be provisioned when required. You can see where these time savings come from by looking at the time it takes to go through the request for proposal (RFP) process, to procure expensive servers with large memories, or potentially to procure dedicated appliances with only a five year lifespans such as storage arrays, network switches, backup appliances, and other data center enhancements. Not to mention the time and cost associated with an expertly trained team that can deploy S4/HANA based on tailored data center integration (TDI) standards as required by SAP. These are the same obstacles the consulting firm Alegri was running into during their experience migrating to S/4HANA on Azure. To read more about their experience, refer to Alegri's customer story, “Modern corporate management without any burden.”

While planning for a migration, you want to have a solid project plan that has all the tasks, milestones, dependencies, and stakeholders identified. You will also want a defined governance model and a RACI chart showing which group owns which tasks. Projects of this size have so many moving parts and dependencies between multiple internal and external teams. Disciple in governance is a must.

When getting started with the actual execution, you would typically want to identify all the SAP prerequisites specific to the versions that are currently in use. Larger SAP migration projects will typically have a number of parallel efforts going on at the same time. You want to be sure the infrastructure design on Azure is fully compliant with SAP’s support matrix. To do so, start by reviewing the SAP documentation and deployment guides on Azure,  Azure's SAP deployment checklist, and the product availability matrix (PAM). This is a great starting point because while you’re working on the initial landscape design, the basis admins can start running the readiness check looking at impact of the legacy custom code in the SAP Business Suite system, the S/4HANA sizing, and other S/4 perquisites required before the upgrade can begin. Together you’ll group on any new items that were uncovered before finalizing the design.

Next is the infrastructure deployment on Azure. The initial deployment is minimal, just enough infrastructure to support the initial sandbox and development tiers. Requirements at this state include:

An Azure subscription
An established VPN connection or Express Route
A deployed Azure network (VNets and Subnets) and security configurations (Network Security Groups)
The required number of virtual or bare metal servers and associated storage

The above requirements will comprise the new target environment. It is important to note that an ExpressRoute will be required to provide enough bandwidth for migrating medium to large databases. The basis admins can start installing the Suite on HANA database and the initial application servers. This will give the broader project team all the working area they need to run through as many migration runs as necessary to iron out any issues.

We get a lot of questions around the best migration method to use when migrating SAP from on-premises to Azure, which is understandable given the number of options including backup/restore, export/import, SUM and DMO, and more. When migrating the SAP Business Suite to S/4HANA on Azure, it’s easier to use the SUM and DMO option from SAP to handle the database migration and installing new application servers in Azure. This also provides an opportunity to have the new landscape in Azure on the latest supported operating system versions for optimal capabilities, performance, and support. My fellow Azure colleague Kiran Musunuru just recently authored a white paper on “Migration Methodologies for SAP on Azure” that outlines using the SUM and DMO option to migrate SAP Business Suite to S/4HANA as well as tools, options, individual steps, and the overall process of the migration.

Here are some tips that I’ve learned through my migration experience to help you avoid any last minute surprises.

Check the minimum required SAP versions and release levels across the landscape.
Check the PAM for Java components to see if they are required for your S/4HANA deployment.
Use the benchmark tool in DMO to get realistic migration times for the system. This helps with determining the best ExpressRoute sizing for the migration, and sets expectations for required downtimes.
Know the Unicode requirement to upgrade to S/4HANA.
Know the dual stack systems remediation.
Know that OS flavor and versions might differ from existing internal IT standards.
Plan for the Fiori deployment.
Be prepared to perform multiple migration mock runs for complex or very large landscapes.

Once the migration from the on-premises system to the Azure environment is complete, the conversion from the SAP Business Suite on HANA to S/4HANA can begin. Before starting I would review SAP’s conversion guide for the S/4HANA version that you will be upgrading to. For example, here is the conversion guide for S/4HANA 1809.

Deploying a new S/4HANA landscape can all be done in Azure by the basis team and eliminates any dependencies on the many internal IT teams that would be required with a deployment in a traditional on-premises environment. Most customers will likely start with a simple sandbox or new development system from a system copy of the newly migrated suite on the HANA system. This provides a staging area to run through all the simplification checks, custom code migrations, and actual S/4 conversion mock runs. In parallel, the basis team can start deploying the QAS and production tiers including the new VM’s and configuration for Fiori. Once the necessary checks and conversion have been completed, the process is simply repeated for QAS and production.

This blog post is meant as a general overview of the process and I didn’t touch on any of the functional areas as I wanted to focus on the items that are connected to the Azure platform. We also have a number of scripting and automation options around deploying S/4HANA landscapes on Azure. For an overview you can visit the blog post, “Automating SAP deployments in Microsoft Azure using Terraform and Ansible” written by Tobias Niekamp from the Azure Compute engineering team.

Next week, my colleague Troy Shane will cover the migration of SAP BW/4HANA. It will also cover how best to deploy SAP BW/4HANA in a scale-out architecture today and in the near future when our new Azure NetApp Files becomes generally available for SAP HANA workloads.
Quelle: Azure

Governance setting for cache refreshes from Azure Analysis Services

Built on the proven analytics engine in Microsoft SQL Server Analysis Services, Azure Analysis Services delivers enterprise-grade BI semantic modeling capabilities with the scale, flexibility, and management benefits of the cloud. The success of any modern data-driven organization requires that information is available at the fingertips of every business user, not just IT professionals and data scientists, to guide their day-to-day decisions. Azure Analysis Services helps you transform complex data into actionable insights. Users in your organization can then connect to your data models using tools like Excel, Power BI, and many others to create reports and perform ad-hoc interactive analysis.

Data visualization and consumption tools over Azure Analysis Services (Azure AS) sometimes store data caches to enhance report interactivity for users. The Power BI service, for example, caches dashboard tile data and report data for initial load for Live Connect reports. However, enterprise BI deployments where semantic models are reused throughout organizations can result in a great deal of dashboards and reports sourcing data from a single Azure AS model. This can cause an excessive number of cache queries being submitted to AS and, in extreme cases, can overload the server. This is especially relevant to Azure AS (as opposed to on-premises SQL Server Analysis Services) because models are often co-located in the same region as the Power BI capacity for faster query response times, so may not even benefit much from caching.

ClientCacheRefreshPolicy governance setting

The new ClientCacheRefreshPolicy property allows IT or the AS practitioner to override this behavior at the Azure AS server level, and disable automatic cache refreshes. All Power BI Live Connect reports and dashboards will observe the setting irrespective of the dataset-level settings, or which Power BI workspace they reside on. You can set this property using SQL Server Management Studio (SSMS) in the Server Properties dialog box. Please see the Analysis Services server properties page for more information on how to make use of this property.

Quelle: Azure

5 tips to get more out of Azure Stream Analytics Visual Studio Tools

Azure Stream Analytics is an on-demand real-time analytics service to power intelligent action. Azure Stream Analytics tools for Visual Studio make it easier for you to develop, manage, and test Stream Analytics jobs. This year we provided two major updates in January and March, unleashing new useful features. In this blog we’ll introduce some of these capabilities and features to help you improve productivity.

Test partial scripts locally

In the latest March update we enhanced local testing capability. Besides running the whole script, now you can select part of the script and run it locally against the local file or live input stream. Click Run Locally or press F5/Ctrl+F5 to trigger the execution. Note that the selected portion of the larger script file must be a logically complete query to execute successfully.

Share inputs, outputs, and functions across multiple scripts

It is very common for multiple Stream Analytics queries to use the same inputs, outputs, or functions. Since these configurations and code are managed as files in Stream Analytics projects, you can define them only once and then use them across multiple projects. Right-click on the project name or folder node (inputs, outputs, functions, etc.) and then choose Add Existing Item to specify the input file you already defined. You can organize the inputs, outputs, and functions in a standalone folder outside your Stream Analytics projects to make it easy to reference in various projects.

Duplicate a job to other regions

All Stream Analytics jobs running in the cloud are listed in Server Explorer under the Stream Analytics node. You can open Server Explorer by choosing from the View menu.

If you want to duplicate a job to another region, just right-click on the job name and export it to a local Stream Analytics project. Since the credentials cannot be downloaded to local environment, you must specify the correct credentials in the job inputs and outputs files. After that, you are ready to submit the job to another region by clicking Submit to Azure in the script editor.

Local input schema auto-completion

If you have specified a local file for an input to your script, the IntelliSense feature will suggest input column names based on the actual schema of your data file.

Testing queries against SQL database as reference data

Azure Stream Analytics supports Azure SQL Database as an input source for reference data. When you add a reference input using SQL Database, two SQL files are generated as code, behind files under your input configuration file.

In Visual Studio 2017 or 2019, if you have already installed SQL Server Data tools, you can directly write the SQL query and test by clicking Execute in the query editor. A wizard window will pop up to help you connect to the SQL database and show the query result in the window at the bottom.

Providing feedback and ideas

The Azure Stream Analytics team is committed to listening to your feedback. We welcome you to join the conversation and make your voice heard via our UserVoice. For tools feedback, you can also reach out to ASAToolsFeedback@microsoft.com.

Also, follow us @AzureStreaming to stay updated on the latest features.
Quelle: Azure

Dear Spark developers: Welcome to Azure Cognitive Services

This post was co-authored by Mark Hamilton, Sudarshan Raghunathan, Chris Hoder, and the MMLSpark contributors.

Integrating the power of Azure Cognitive Services into your big data workflows on Apache Spark™

Today at Spark AI Summit 2019, we're excited to introduce a new set of models in the SparkML ecosystem that make it easy to leverage the Azure Cognitive Services at terabyte scales. With only a few lines of code, developers can embed cognitive services within your existing distributed machine learning pipelines in Spark ML. Additionally, these contributions allow Spark users to chain or Pipeline services together with deep networks, gradient boosted trees, and any SparkML model and apply these hybrid models in elastic and serverless distributed systems.

From image recognition to object detection using speech recognition, translation, and text-to-speech, Azure Cognitive Services makes it easy for developers to add intelligent capabilities to their applications in any scenario. To this date, more than a million developers have already discovered and tried Cognitive Services to accelerate breakthrough experiences in their application.

Azure Cognitive Services on Apache Spark™

Cognitive Services on Spark enable working with Azure’s Intelligent Services at massive scales with the Apache Spark™ distributed computing ecosystem. The Cognitive Services on Spark are compatible with any Spark 2.4 cluster such as Azure Databricks, Azure Distributed Data Engineering Toolkit (AZTK) on Azure Batch, Spark in SQL Server, and Spark clusters on Azure Kubernetes Service. Furthermore, we provide idiomatic bindings in PySpark, Scala, Java, and R (Beta).

Cognitive Services on Spark allows users to embed general purpose and continuously improve intelligent models directly into their Apache Spark™ and SQL computations. This contribution aims to liberate developers from low-level networking details, so they can focus on creating intelligent, distributed applications. Each Cognitive Service is a SparkML transformer, so users can add services to existing SparkML pipelines. We also introduce a new type of API to the SparkML framework that allows users to parameterize models by either a single scalar, or a column of a distributed spark DataFrame. This API yields a succinct, yet powerful fluent query language that offers a full distributed parameterization without clutter. For more information, check out our session.

Use Azure Cognitive Services on Spark in these 3 simple steps:

Create an Azure Cognitive Services Account
Install MMLSpark on your Spark Cluster
Try our example notebook

Low-latency, high-throughput workloads with the cognitive service containers

The cognitive services on Spark are compatible with services from any region of the globe, however many scenarios require low or no-connectivity and ultra-low latency. To tackle these with the cognitive services on Spark, we have recently released several cognitive services as docker containers. These containers enable running cognitive services locally or directly on the worker nodes of your cluster for ultra-low latency workloads. To make it easy to create Spark Clusters with embedded cognitive services, we have created a Helm Chart for deploying a Spark clusters onto the popular container orchestration platform Kubernetes. Simply point the Cognitive Services on Spark at your container’s URL to go local!

Add any web service to Apache Spark™ with HTTP on Spark

The Cognitive Services are just one example of using networking to share software across ecosystems. The web is full of HTTP(S) web services that provide useful tools and serve as one of the standard patterns for making your code accessible in any language. Our goal is to allow Spark developers to tap into this richness from within their existing Spark pipelines.

To this end, we present HTTP on Spark, an integration between the entire HTTP communication protocol and Spark SQL. HTTP on Spark allows Spark users to leverage the parallel networking capabilities of their cluster to integrate any local, docker, or web service. At a high level, HTTP on Spark provides a simple and principled way to integrate any framework into the Spark ecosystem.

With HTTP on Spark, users can create and manipulate their requests and responses using SQL operations, maps, reduces, filters, and any tools from the Spark ecosystem. When combined with SparkML, users can chain services together and use Spark as a distributed micro-service orchestrator. HTTP on Spark provides asynchronous parallelism, batching, throttling, and exponential back-offs for failed requests so that you can focus on the core application logic.

Real world examples

The Metropolitan Museum of Art

At Microsoft, we use HTTP on Spark to power a variety of projects and customers. Our latest project uses the Computer Vision APIs on Spark and Azure Search on Spark to create a searchable database of Art for The Metropolitan Museum of Art (The MET). More Specifically, we load The MET’s Open Access catalog of images, and use the Computer Vision APIs to annotate these images with searchable descriptions in parallel. We also used CNTK on Spark, and SparkML’s Locality Sensitive Hash implementation to futurize these images and create a custom reverse image search engine. For more information on this work, check out our AI Lab or our Github.

The Snow Leopard Trust

We partnered with the Snow Leopard Trust to help track and understand the endangered Snow Leopard population using the Cognitive Services on Spark. We began by creating a fully labelled training dataset for leopard classification by pulling snow leopard images from Bing on Spark. We then used CNTK and Tensorflow on Spark to train a deep classification system. Finally, we interpreted our model using LIME on Spark to refine our leopard classifier into a leopard detector without drawing a single bounding box by hand! For more information, you can check out our blog post.

Conclusion

With only a few lines of code you can start integrating the power of Azure Cognitive Services into your big data workflows on Apache Spark™. The Spark bindings offer high throughput and run anywhere you run Spark. The Cognitive Services on Spark fully integrate with containers for high performance, on premises, or low connectivity scenarios. Finally, we have provided a general framework for working with any web service on Spark. You can start leveraging the Cognitive Services for your project

with our open source initiative MMLSpark on Azure Databricks.

Learn more

Web

Github

Email: mmlspark-support@microsoft.com
Quelle: Azure

Customize your Azure best practice recommendations in Azure Advisor

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

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