Merge pull request #111387 from Minewiskan/azureas-nodes

Adding node movement article.

Author: garycentric

articles/analysis-services/TOC.yml

@@ -39,6 +39,8 @@
     href: analysis-services-connect.md
   - name: High availability
     href: analysis-services-bcdr.md
+  - name: Long running operations
+    href: analysis-services-long-operations.md
   - name: Supported data sources
     href: analysis-services-datasource.md
 - name: How-to

articles/analysis-services/analysis-services-async-refresh.md

@@ -4,14 +4,14 @@ description: Describes how to use the Azure Analysis Services REST API to code a
 author: minewiskan
 ms.service: azure-analysis-services
 ms.topic: conceptual
-ms.date: 01/14/2020
+ms.date: 04/15/2020
 ms.author: owend
 ms.reviewer: minewiskan
 
 ---
 # Asynchronous refresh with the REST API
 
-By using any programming language that supports REST calls, you can  perform asynchronous data-refresh operations on your Azure Analysis Services tabular models. This includes synchronization of read-only replicas for query scale-out. 
+By using any programming language that supports REST calls, you can perform asynchronous data-refresh operations on your Azure Analysis Services tabular models. This includes synchronization of read-only replicas for query scale-out. 
 
 Data-refresh operations can take some time depending on a number of factors including data volume, level of optimization using partitions, etc. These operations have traditionally been invoked with existing methods such as using [TOM](https://docs.microsoft.com/analysis-services/tom/introduction-to-the-tabular-object-model-tom-in-analysis-services-amo) (Tabular Object Model), [PowerShell](https://docs.microsoft.com/analysis-services/powershell/analysis-services-powershell-reference) cmdlets, or [TMSL](https://docs.microsoft.com/analysis-services/tmsl/tabular-model-scripting-language-tmsl-reference) (Tabular Model Scripting Language). However, these methods can require often unreliable, long-running HTTP connections.
 
@@ -203,18 +203,18 @@ Here's a C# code sample to get you started, [RestApiSample on GitHub](https://gi
 
 ### To use the code sample
 
-1.	Clone or download the repo. Open the RestApiSample solution.
-2.	Find the line **client.BaseAddress = …** and provide your [base URL](#base-url).
+1.    Clone or download the repo. Open the RestApiSample solution.
+2.    Find the line **client.BaseAddress = …** and provide your [base URL](#base-url).
 
 The code sample uses [service principal](#service-principal) authentication.
 
 ### Service principal
 
 See [Create service principal - Azure portal](../active-directory/develop/howto-create-service-principal-portal.md) and [Add a service principal to the server administrator role](analysis-services-addservprinc-admins.md) for more info on how to set up a service principal and assign the necessary permissions in Azure AS. Once you've completed the steps, complete the following additional steps:
 
-1.	In the code sample, find **string authority = …**, replace **common** with your organization’s tenant ID.
-2.	Comment/uncomment so the ClientCredential class is used to instantiate the cred object. Ensure the \<App ID> and \<App Key> values are accessed in a secure way or use certificate-based authentication for service principals.
-3.	Run the sample.
+1.    In the code sample, find **string authority = …**, replace **common** with your organization's tenant ID.
+2.    Comment/uncomment so the ClientCredential class is used to instantiate the cred object. Ensure the \<App ID> and \<App Key> values are accessed in a secure way or use certificate-based authentication for service principals.
+3.    Run the sample.
 
 
 ## See also

articles/analysis-services/analysis-services-long-operations.md

@@ -0,0 +1,49 @@
+---
+title: Best practices for long running operations in Azure Analysis Services | Microsoft Docs
+description: This article describes best practices for long running operations.
+author: minewiskan
+ms.service: analysis-services
+ms.topic: conceptual
+ms.date: 04/14/2020
+ms.author: owend
+
+---
+# Best practices for long running operations
+
+In Azure Analysis Services, a *node* represents a host virtual machine where a server resource is running. Some operations such as long running queries, refresh operations, and query scale-out synchronization can fail if a server resource moves to a different node. Common error messages in this scenario include:
+
+- "An error has occurred while trying to locate a long running XMLA request. The request might have been interrupted by service upgrade or server restart."
+- "Job with ID '<guid>for model '<database>' was canceled due to service error (inactivity) with message 'Cancelling the refresh request since it was stuck without any updates. This is an internal service issue. Please resubmit the job or file a ticket to get help if this issue happens repeatedly."
+
+There are many reasons why long running operations can be disrupted. For example, updates in Azure such as: 
+- Operating System patches 
+- Security updates
+- Azure Analysis Services service updates
+- Service Fabric updates. Service Fabric is a platform component used by a number of Microsoft cloud services, including Azure Analysis Services.
+
+Besides updates that occur in the service, there is a natural movement of services across nodes due to load balancing. Node movements are an expected part of a cloud service. Azure Analysis Services tries to minimize impacts from node movements, but it's impossible to eliminate them entirely. 
+
+In addition to node movements, there are other failures that can occur. For example, a data source database system might be offline or network connectivity is lost. If during refresh, a partition has 10 million rows and a failure occurs at the 9 millionth row, there is no way to restart refresh at the point of failure. The service has to start again from the beginning. 
+
+## Refresh REST API
+
+Service interruptions can be challenging for long running operations like data refresh. Azure Analysis Services includes a REST API to help mitigate negative impacts from service interruptions. To learn more, see [Asynchronous refresh with the REST API](analysis-services-async-refresh.md).
+ 
+Besides the REST API, there are other approaches you can use to minimize potential issues during long running refresh operations. The main goal is to avoid having to restart the refresh operation from the beginning, and instead perform refreshes in smaller batches that can be committed in stages. 
+ 
+The REST API allows for such restart, but it doesn't allow for full flexibility of partition creation and deletion. If a scenario requires complex data management operations, your solution should include some form of batching in its logic. For example, by using transactions to process data in multiple, separate batches allows for a failure to not require restart from the beginning, but instead from an intermediate checkpoint. 
+ 
+## Scale-out query replicas
+
+Whether using REST or custom logic, client application queries can still return inconsistent or intermediate results while batches are being processed. If consistent data returned by client application queries is required while processing is happening, and model data is in an intermediate state, you can use [scale-out](analysis-services-scale-out.md) with read-only query replicas.
+
+By using read-only query replicas, while refreshes are being performed in batches, client application users can continue to query the old snapshot of data on the read-only replicas. Once refreshes are finished, a Synch operation can be performed to bring the read-only replicas up to date.
+
+
+## Next steps
+
+[Asynchronous refresh with the REST API](analysis-services-async-refresh.md)  
+[Azure Analysis Services scale-out](analysis-services-scale-out.md)  
+[Analysis Services high availability](analysis-services-bcdr.md)  
+[Retry guidance for Azure services](https://docs.microsoft.com/azure/architecture/best-practices/retry-service-specific)   
+