Merge pull request #41994 from MicrosoftDocs/FromPublicRepo

From public repo

Author: huypub

articles/aks/ingress.md

@@ -67,10 +67,10 @@ DNSNAME="demo-aks-ingress"
 
 # Get resource group and public ip name
 RESOURCEGROUP=$(az network public-ip list --query "[?ipAddress!=null]|[?contains(ipAddress, '$IP')].[resourceGroup]" --output tsv)
-PIPNAME=$(az network public-ip list --query "[?ipAddress!=null]|[?contains(ipAddress, '$IP')].[name]" --output tsv)
+PUBLICIPNAME=$(az network public-ip list --query "[?ipAddress!=null]|[?contains(ipAddress, '$IP')].[name]" --output tsv)
 
 # Update public ip address with dns name
-az network public-ip update --resource-group $RESOURCEGROUP --name  $PIPNAME --dns-name $DNSNAME
+az network public-ip update --resource-group $RESOURCEGROUP --name $PUBLICIPNAME --dns-name $DNSNAME
 ```
 
 The ingress controller should now be accessible through the FQDN.

articles/azure-functions/functions-bindings-timer.md

@@ -273,7 +273,7 @@ If you share a Storage account across multiple function apps, make sure that eac
 
 ## Retry behavior
 
-Unlike the queue trigger, the timer trigger doesn't retry after a function fails. When a function fails, it is't called again until the next time on the schedule.
+Unlike the queue trigger, the timer trigger doesn't retry after a function fails. When a function fails, it isn't called again until the next time on the schedule.
 
 ## Next steps
 

articles/iot-hub/iot-hub-csharp-csharp-module-twin-getstarted.md

@@ -18,7 +18,7 @@ ms.author: menchi
 ms.custom: H1Hack27Feb2017
 
 ---
-# Get started with IoT Hub module identity and module twin using .NET backup and .NET device
+# Get started with IoT Hub module identity and module twin using .NET back end and .NET device
 
 > [!NOTE]
 > [Module identities and module twins](iot-hub-devguide-module-twins.md) are similar to Azure IoT Hub device identity and device twin, but provide finer granularity. While Azure IoT Hub device identity and device twin enable the back-end application to configure a device and provides visibility on the device’s conditions, a module identity and module twin provide these capabilities for individual components of a device. On capable devices with multiple components, such as operating system based devices or firmware devices, it allows for isolated configuration and conditions for each component.

articles/monitoring-and-diagnostics/monitoring-overview.md

@@ -1,4 +1,4 @@
----
+---
 title: Monitoring Azure applications and resources | Microsoft Docs
 description: Overview of Microsoft services and functionalities that contribute to a complete monitoring strategy for your Azure services and applications.
 author: rboucher
@@ -115,9 +115,9 @@ There are several tools that work together to monitor various aspects of your ne
 
 [Network Watcher](../network-watcher/network-watcher-monitoring-overview.md) provides scenario-based monitoring and diagnostics for different network scenarios in Azure. It stores data in Azure metrics and diagnostics for further analysis. It works with the following solutions for monitoring various aspects of your network.
 
-[Network Performance Monitor (NPM)](https://blogs.msdn.microsoft.com/azuregov/2017/09/05/network-performance-monitor-general-availability/) is a cloud-based network monitoring solution that monitors connectivity across public clouds, datacenters, and on-premises environments.
+[Network Performance Monitor (NPM)](../log-analytics/log-analytics-network-performance-monitor.md) is a cloud-based network monitoring solution that monitors connectivity across public clouds, datacenters, and on-premises environments.
 
-[ExpressRoute Monitor](https://azure.microsoft.com/en-in/blog/monitoring-of-azure-expressroute-in-preview/) is an  NPM capability that monitors the end-to-end connectivity and performance over Azure ExpressRoute circuits.
+[ExpressRoute Monitor](../expressroute/how-to-npm.md) is an  NPM capability that monitors the end-to-end connectivity and performance over Azure ExpressRoute circuits.
 
 [DNS Analytics](../log-analytics/log-analytics-dns.md) is a solution that provides security, performance, and operations-related insights, based on your DNS servers.
 

articles/redis-cache/cache-faq.md

@@ -382,7 +382,7 @@ Given this information, we strongly recommend that customers set the minimum con
 
 How to configure this setting:
 
-* In ASP.NET, use the ["minIoThreads" configuration setting]["minIoThreads" configuration setting] under the `<processModel>` configuration element in web.config. If you are running inside of Azure WebSites, this setting is not exposed through the configuration options. However, you should still be able to configure this setting programmatically (see below) from your Application_Start method in global.asax.cs.
+* In ASP.NET, use the ["minIoThreads" or "minWorkerThreads" configuration setting]["minIoThreads" configuration setting] under the `<processModel>` configuration element in web.config. If you are running inside of Azure WebSites, this setting is not exposed through the configuration options. However, you should still be able to configure this setting programmatically (see below) from your Application_Start method in global.asax.cs.
 
   > [!NOTE] 
   > The value specified in this configuration element is a *per-core* setting. For example, if you have a 4 core machine and want your minIOThreads setting to be 200 at runtime, you would use `<processModel minIoThreads="50"/>`.

articles/service-fabric/service-fabric-cluster-capacity.md

@@ -34,61 +34,58 @@ Establish the number of node types your cluster needs to start out with.  Each n
 * Does your application have multiple services, and do any of them need to be public or internet facing? Typical applications contain a front-end gateway service that receives input from a client and one or more back-end services that communicate with the front-end services. So in this case, you end up having at least two node types.
 * Do your services (that make up your application) have different infrastructure needs such as greater RAM or higher CPU cycles? For example, let us assume that the application that you want to deploy contains a front-end service and a back-end service. The front-end service can run on smaller VMs (VM sizes like D2) that have ports open to the internet.  The back-end service, however, is computation intensive and needs to run on larger VMs (with VM sizes like D4, D6, D15) that are not internet facing.
 
-  In this example, although you can decide to put all the services on one node type, we recommended that you place them in a cluster with two node types.  This allows for each node type to have distinct properties such as internet connectivity or VM size. The number of VMs can be scaled independently, as well.  
-* Since you cannot predict the future, go with facts you know of and decide on the number of node types that your applications need to start with. You can always add or remove node types later. A Service Fabric cluster must have at least one node type.
+  In this example, although you can decide to put all the services on one node type, we recommended that you place them in a cluster with two node types.  This allows each node type to have distinct properties such as internet connectivity or VM size. The number of VMs can be scaled independently, as well.  
+* Because you cannot predict the future, go with facts you know, and choose the number of node types that your applications need to start with. You can always add or remove node types later. A Service Fabric cluster must have at least one node type.
 
 ## The properties of each node type
-The **node type** can be seen as equivalent to roles in Cloud Services. Node types define the VM sizes, the number of VMs, and their properties. Every node type that is defined in a Service Fabric cluster is set up as a separate virtual machine scale set. 
-Virtual machine scale set is an Azure compute resource used to deploy and manage a collection of virtual machines as a set. Each node type is a distinct scale set and can be scaled up or down independently, have different sets of ports open, and have different capacity metrics.
+The **node type** can be seen as equivalent to roles in Cloud Services. Node types define the VM sizes, the number of VMs, and their properties. Every node type that is defined in a Service Fabric cluster maps to a [virtual machine scale set](https://docs.microsoft.com/azure/virtual-machine-scale-sets/overview).  
+Each node type is a distinct scale set and can be scaled up or down independently, have different sets of ports open, and have different capacity metrics. For more information about the relationships between node types and virtual machine scale sets, how to RDP into one of the instances, how to open new ports, and so on, see [Service Fabric cluster node types](service-fabric-cluster-nodetypes.md).
 
-Read [this document](service-fabric-cluster-nodetypes.md) for more details on the relationship of node types to virtual machine scale sets, how to RDP into one of the instances, open new ports etc.
-
-Your cluster can have more than one node type, but the primary node type (the first one that you define on the portal) must have at least five VMs for clusters used for production workloads (or at least three VMs for test clusters). If you are creating the cluster using a Resource Manager template, then look for **is Primary** attribute under the node type definition. The primary node type is the node type where Service Fabric system services are placed.  
+A Service Fabric cluster can consist of more than one node type. In that event, the cluster consists of one primary node type and one or more non-primary node types.
 
 ### Primary node type
-For a cluster with multiple node types, you need to choose one of them to be primary. Here are the characteristics of a primary node type:
 
-* The **minimum size of VMs** for the primary node type is determined by the **durability tier** you choose. The default for the durability tier is Bronze. Scroll down for details on what the durability tier is and the values it can take.  
-* The **minimum number of VMs** for the primary node type is determined by the **reliability tier** you choose. The default for the reliability tier is Silver. Scroll down for details on what the reliability tier is and the values it can take. 
+The Service Fabric system services (for example, the Cluster Manager service or Image Store service) are placed on the primary node type. 
 
+![Screen shot of a cluster that has two Node Types][SystemServices]
 
-* The Service Fabric system services (for example, the Cluster Manager service or Image Store service) are placed on the primary node type and so the reliability and durability of the cluster is determined by the reliability tier value and durability tier value you select for the primary node type.
+* The **minimum size of VMs** for the primary node type is determined by the **durability tier** you choose. The default durability tier is Bronze. See [The durability characteristics of the cluster](https://docs.microsoft.com/azure/service-fabric/service-fabric-cluster-capacity#the-durability-characteristics-of-the-cluster) for more details.  
+* The **minimum number of VMs** for the primary node type is determined by the **reliability tier** you choose. The default reliability tier is Silver. See [The reliability characteristics of the cluster](https://docs.microsoft.com/azure/service-fabric/service-fabric-cluster-capacity#the-reliability-characteristics-of-the-cluster) for more details.  
 
-![Screen shot of a cluster that has two Node Types ][SystemServices]
+From the Azure Resource Manager template, the primary node type is configured with the `isPrimary` attribute under the [node type definition](https://docs.microsoft.com/en-us/azure/templates/microsoft.servicefabric/clusters#nodetypedescription-object).
 
 ### Non-primary node type
-For a cluster with multiple node types, there is one primary node type and the rest of them are non-primary. Here are the characteristics of a non-primary node type:
 
-* The minimum size of VMs for this node type is determined by the durability tier you choose. The default for the durability tier is Bronze. Scroll down for details on what the durability tier is and the values it can take.  
-* The minimum number of VMs for this node type can be one. However you should choose this number based on the number of replicas of the application/services that you would like to run in this node type. The number of VMs in a node type can be increased after you have deployed the cluster.
+In a cluster with multiple node types, there is one primary node type and the rest are non-primary.
+
+* The **minimum size of VMs** for non-primary node types is determined by the **durability tier** you choose. The default durability tier is Bronze. See [The durability characteristics of the cluster](https://docs.microsoft.com/azure/service-fabric/service-fabric-cluster-capacity#the-durability-characteristics-of-the-cluster) for more details.  
+* The **minimum number of VMs** for non-primary node types is one. However, you should choose this number based on the number of replicas of the application/services that you want to run in this node type. The number of VMs in a node type can be increased after you have deployed the cluster.
 
 ## The durability characteristics of the cluster
 The durability tier is used to indicate to the system the privileges that your VMs have with the underlying Azure infrastructure. In the primary node type, this privilege allows Service Fabric to pause any VM level infrastructure request (such as a VM reboot, VM reimage, or VM migration) that impact the quorum requirements for the system services and your stateful services. In the non-primary node types, this privilege allows Service Fabric to pause any VM level infrastructure requests (such as VM reboot, VM reimage, and VM migration) that impact the quorum requirements for your stateful services.
 
-This privilege is expressed in the following values:
-
-* Gold - Updates you make to your VMSS can be delayed until approved by the Service Fabric cluster. Updates and maintenance initiated by Azure can be delayed for up two hours, allowing additional time for replicas to recover from earlier failures. Gold durability can be enabled only on full-node VM sizes like L32s, GS5, G5, DS15_v2, D15_v2. In general, all the VM sizes listed at http://aka.ms/vmspecs that are marked as 'Instance is isolated to hardware dedicated to a single customer' in the note are full-node VMs.
-* Silver - Updates you make to your VMSS can be delayed until approved by the Service Fabric cluster. Updates and maintenance initiated by Azure cannot be delayed for any significant period of time. Silver durability is available on all standard VMs of single core and above.
-* Bronze - This is the default. Updates and maintenance affecting your VMs will not be delayed by the Service Fabric cluster.
+| Durability tier  | Required minimum number of VMs | Supported VM SKUs                                                                  | Updates you make to your VMSS                               | Updates and maintenance initiated by Azure                                                              | 
+| ---------------- |  ----------------------------  | ---------------------------------------------------------------------------------- | ----------------------------------------------------------- | ------------------------------------------------------------------------------------------------------- |
+| Gold             | 5                              | Full-node SKUs dedicated to a single customer (for example, L32s, GS5, G5, DS15_v2, D15_v2) | Can be delayed until approved by the Service Fabric cluster | Can be paused for 2 hours per UD to allow additional time for replicas to recover from earlier failures |
+| Silver           | 5                              | VMs of single core or above                                                        | Can be delayed until approved by the Service Fabric cluster | Cannot be delayed for any significant period of time                                                    |
+| Bronze           | 1                              | All                                                                                | Will not be delayed by the Service Fabric cluster           | Cannot be delayed for any significant period of time                                                    |
 
 > [!WARNING]
-> NodeTypes running with Bronze durability obtain _no privileges_. This means that infrastructure jobs that impact your stateless workloads will not be stopped or delayed. It is possible that such jobs can still impact your workloads, causing downtime or other issues. For any sort of production workload, running with at least Silver is recommended. You must maintain a minimum count of five nodes for any node-type that has a durability of Gold or Silver. 
-> 
-
-You get to choose durability level for each of your node-types.You can choose one node-type to have a durability level of Gold or silver and the other have Bronze in the same cluster. **You must maintain a minimum count of five nodes for any node-type that has a durability of Gold or silver**. 
+> Node types running with Bronze durability obtain _no privileges_. This means that infrastructure jobs that impact your stateless workloads will not be stopped or delayed, which might impact your workloads. Use only Bronze for node types that run only stateless workloads. For production workloads, running Silver or above is recommended. 
+>
 
 **Advantages of using Silver or Gold durability levels**
 
-- Reduces the number of required steps in a scale-in operation (that is, node deactivation and Remove-ServiceFabricNodeState is called automatically)
+- Reduces the number of required steps in a scale-in operation (that is, node deactivation and Remove-ServiceFabricNodeState is called automatically).
 - Reduces the risk of data loss due to a customer-initiated in-place VM SKU change operation or Azure infrastructure operations.
-	 
+
 **Disadvantages of using Silver or Gold durability levels**
 
-- Deployments to your virtual machine scale set and other related Azure resources) can be delayed, can time out, or can be blocked entirely by problems in your cluster or at the infrastructure level. 
+- Deployments to your virtual machine scale set and other related Azure resources can be delayed, can time out, or can be blocked entirely by problems in your cluster or at the infrastructure level. 
 - Increases the number of [replica lifecycle events](service-fabric-reliable-services-lifecycle.md) (for example, primary swaps) due to automated node deactivations during Azure infrastructure operations.
 - Takes nodes out of service for periods of time while Azure platform software updates or hardware maintenance activities are occurring. You may see nodes with status Disabling/Disabled during these activities. This reduces the capacity of your cluster temporarily, but should not impact the availability of your cluster or applications.
 
-### Recommendations on when to use Silver or Gold durability levels
+### Recommendations for when to use Silver or Gold durability levels
 
 Use Silver or Gold durability for all node types that host stateful services you expect to scale-in (reduce VM instance count) frequently, and you would prefer that deployment operations be delayed and capacity to be reduced in favor of simplifying these scale-in operations. The scale-out scenarios (adding VMs instances) do not play into your choice of the durability tier, only scale-in does.