Merge pull request #153231 from saketharsh/statelessga

Initial Documentation Updates for Stateless GA

Author: PRMerger14

articles/service-fabric/service-fabric-cross-availability-zones.md

@@ -28,7 +28,7 @@ The recommended topology for the primary node type requires the resources outlin
 * A NSG referenced by the subnet in which you deploy your virtual machine scale sets.
 
 >[!NOTE]
-> The virtual machine scale set single placement group property must be set to true, since Service Fabric does not support a single virtual machine scale set which spans zones.
+> The virtual machine scale set single placement group property must be set to true.
 
 Diagram that shows the Azure Service Fabric Availability Zone architecture
  ![Diagram that shows the Azure Service Fabric Availability Zone architecture.][sf-architecture]

articles/service-fabric/service-fabric-stateless-node-types.md

@@ -1,13 +1,13 @@
 ---
 title: Deploy Stateless-only node types in a Service Fabric cluster
-description: Learn how to create and deploy stateless node types in Azure Service fabric cluster.
+description: Learn how to create and deploy stateless node types in Azure Service Fabric cluster.
 author: peterpogorski
 
 ms.topic: conceptual
 ms.date: 09/25/2020
 ms.author: pepogors
 ---
-# Deploy an Azure Service Fabric cluster with stateless-only node types (Preview)
+# Deploy an Azure Service Fabric cluster with stateless-only node types
 Service Fabric node types come with inherent assumption that at some point of time, stateful services might be placed on the nodes. Stateless node types relax this assumption for a node type, thus allowing node type to use other features such as faster scale out operations, support for Automatic OS Upgrades on Bronze durability and scaling out to more than 100 nodes in a single virtual machine scale set.
 
 * Primary node types cannot be configured to be stateless
@@ -18,7 +18,7 @@ Service Fabric node types come with inherent assumption that at some point of ti
 Sample templates are available: [Service Fabric Stateless Node types template](https://github.com/Azure-Samples/service-fabric-cluster-templates)
 
 ## Enabling stateless node types in Service Fabric cluster
-To set one or more node types as stateless in a cluster resource, set the **isStateless** property to "true". When deploying a Service Fabric cluster with stateless node types, do remember to have atleast one primary node type in the cluster resource.
+To set one or more node types as stateless in a cluster resource, set the **isStateless** property to **true**. When deploying a Service Fabric cluster with stateless node types, do remember to have atleast one primary node type in the cluster resource.
 
 * The Service Fabric cluster resource apiVersion should be "2020-12-01-preview" or higher.
 
@@ -39,7 +39,7 @@ To set one or more node types as stateless in a cluster resource, set the **isSt
         },
         "httpGatewayEndpointPort": "[parameters('nt0fabricHttpGatewayPort')]",
         "isPrimary": true,
-        "isStateless": false,
+        "isStateless": false, // Primary Node Types cannot be stateless
         "vmInstanceCount": "[parameters('nt0InstanceCount')]"
     },
     {
@@ -67,16 +67,15 @@ To set one or more node types as stateless in a cluster resource, set the **isSt
 To enable stateless node types, you should configure the underlying virtual machine scale set resource in the following way:
 
 * The value  **singlePlacementGroup** property, which should be set to **false** if you require to scale to more than 100 VMs.
-* The Scale set's **upgradePolicy** **mode** should be set to **Rolling**.
+* The Scale set's **upgradeMode** should be set to **Rolling**.
 * Rolling Upgrade Mode requires Application Health Extension or Health probes configured. Configure health probe with default configuration for Stateless Node types as suggested below. Once applications are deployed to the node type, Health Probe/Health extension ports can be changed to monitor application health.
 
 >[!NOTE]
-> It is required that the platform fault domain count is updated to 5 when a stateless node type is backed by a virtual machine scale set which is spanning multiple zones. Please see this [template](https://github.com/Azure-Samples/service-fabric-cluster-templates/tree/master/15-VM-2-NodeTypes-Windows-Stateless-CrossAZ-Secure) for more details.
-> 
-> **platformFaultDomainCount:5**
+> While using AutoScaling with Stateless nodetypes, after scale down operation, node state is not automatically cleaned up. In order to cleanup the NodeState of Down Nodes during AutoScale, using [Service Fabric AutoScale Helper](https://github.com/Azure/service-fabric-autoscale-helper) is advised.
+
 ```json
 {
-    "apiVersion": "2018-10-01",
+    "apiVersion": "2019-03-01",
     "type": "Microsoft.Compute/virtualMachineScaleSets",
     "name": "[parameters('vmNodeType1Name')]",
     "location": "[parameters('computeLocation')]",
@@ -87,8 +86,9 @@ To enable stateless node types, you should configure the underlying virtual mach
           "automaticOSUpgradePolicy": {
             "enableAutomaticOSUpgrade": true
           }
-        }
-    }
+        },
+        "platformFaultDomainCount": 5
+    },
     "virtualMachineProfile": {
     "extensionProfile": {
     "extensions": [
@@ -132,6 +132,15 @@ To enable stateless node types, you should configure the underlying virtual mach
 }
 ```
 
+## Configuring Stateless node types with multiple Availability Zones
+To configure Stateless nodetype spanning across multiple availability zones follow the documentation [here](https://docs.microsoft.com/azure/service-fabric/service-fabric-cross-availability-zones#preview-enable-multiple-availability-zones-in-single-virtual-machine-scale-set), along with the few changes as follows:
+
+* Set **singlePlacementGroup** :  **false**  if multiple placement groups is required to be enabled.
+* Set  **upgradeMode** : **Rolling**   and add Application Health Extension/Health Probes as mentioned above.
+* Set **platformFaultDomainCount** : **5** for virtual machine scale set.
+
+For reference, look at the [template](https://github.com/Azure-Samples/service-fabric-cluster-templates/tree/master/15-VM-2-NodeTypes-Windows-Stateless-CrossAZ-Secure) for configuring Stateless node types with multiple Availability Zones
+
 ## Networking requirements
 ### Public IP and Load Balancer Resource
 To enable scaling to more than 100 VMs on a virtual machine scale set resource, the load balancer and IP resource referenced by that virtual machine scale set must both be using a *Standard* SKU. Creating a load balancer or IP resource without the SKU property will create a Basic SKU, which does not support scaling to more than 100 VMs. A Standard SKU load balancer will block all traffic from the outside by default; to allow outside traffic, an NSG must be deployed to the subnet.
@@ -179,7 +188,7 @@ To enable scaling to more than 100 VMs on a virtual machine scale set resource,
 ```
 
 >[!NOTE]
-> It is not possible to do an in-place change of SKU on the public IP and load balancer resources. If you are migrating from existing resources which have a Basic SKU, see the migration section of this article.
+> It is not possible to do an in-place change of SKU on the public IP and load balancer resources. 
 
 ### Virtual machine scale set NAT rules
 The load balancer inbound NAT rules should match the NAT pools from the virtual machine scale set. Each virtual machine scale set must have a unique inbound NAT pool.
@@ -238,7 +247,7 @@ Standard Load Balancer and Standard Public IP introduce new abilities and differ
 
 
 
-### Migrate to using Stateless node types from a cluster using a Basic SKU Load Balancer and a Basic SKU IP
+## Migrate to using Stateless node types in a cluster
 For all migration scenarios, a new stateless-only node type needs to be added. Existing node type cannot be migrated to be stateless-only.
 
 To migrate a cluster, which was using a Load Balancer and IP with a basic SKU, you must first create an entirely new Load Balancer and IP resource using the standard SKU. It is not possible to update these resources in-place.
@@ -252,9 +261,6 @@ To begin, you will need to add the new resources to your existing Resource Manag
 
 Once the resources have finished deploying, you can begin to disable the nodes in the node type that you want to remove from the original cluster.
 
->[!NOTE]
-> While using AutoScaling with Stateless nodetypes with Bronze Durability, after scale down operation, node state is not automatically cleaned up. In order to cleanup the NodeState of Down Nodes during AutoScale, using [Service Fabric AutoScale Helper](https://github.com/Azure/service-fabric-autoscale-helper) is advised.
-
 ## Next steps 
 * [Reliable Services](service-fabric-reliable-services-introduction.md)
 * [Node types and virtual machine scale sets](service-fabric-cluster-nodetypes.md)

articles/virtual-machine-scale-sets/virtual-machine-scale-sets-automatic-upgrade.md

@@ -74,7 +74,7 @@ The following platform SKUs are currently supported (and more are added periodic
 ### Service Fabric requirements
 
 If you are using Service Fabric, ensure the following conditions are met:
--	Service Fabric [durability level](../service-fabric/service-fabric-cluster-capacity.md#durability-characteristics-of-the-cluster) is Silver or Gold, and not Bronze.
+-	Service Fabric [durability level](../service-fabric/service-fabric-cluster-capacity.md#durability-characteristics-of-the-cluster) is Silver or Gold, and not Bronze(except Stateless-only nodetypes, which do support Automatic OS Upgrades).
 -	The Service Fabric extension on the scale set model definition must have TypeHandlerVersion 1.1 or above.
 -	Durability level should be the same at the Service Fabric cluster and Service Fabric extension on the scale set model definition.
 - An additional health probe or use of application health extension is not required.
@@ -158,7 +158,7 @@ The load-balancer probe can be referenced in the *networkProfile* of the scale s
 ```
 
 > [!NOTE]
-> When using Automatic OS Upgrades with Service Fabric, the new OS image is rolled out Update Domain by Update Domain to maintain high availability of the services running in Service Fabric. To utilize Automatic OS Upgrades in Service Fabric your cluster must be configured to use the Silver Durability Tier or higher. For more information on the durability characteristics of Service Fabric clusters, please see [this documentation](../service-fabric/service-fabric-cluster-capacity.md#durability-characteristics-of-the-cluster).
+> When using Automatic OS Upgrades with Service Fabric, the new OS image is rolled out Update Domain by Update Domain to maintain high availability of the services running in Service Fabric. To utilize Automatic OS Upgrades in Service Fabric your cluster nodetype must be configured to use the Silver Durability Tier or higher. For Bronze Durability tier, Automatic OS Upgrade is only supported for Stateless nodetypes. For more information on the durability characteristics of Service Fabric clusters, please see [this documentation](../service-fabric/service-fabric-cluster-capacity.md#durability-characteristics-of-the-cluster).
 
 ### Keep credentials up to date
 If your scale set uses any credentials to access external resources, such as a VM extension configured to use a SAS token for storage account, then ensure that the credentials are updated. If any credentials, including certificates and tokens, have expired, the upgrade will fail and the first batch of VMs will be left in a failed state.