Service Fabric Classic Cluster (SFCC)andService Fabric Managed Cluster (SFMC)both support the automatic OS upgrade. But their underlying design to support this feature is fully different. This article will mainly talk about this difference.
The following is a list of the abbreviations which will be used in this blog.
SFCC: Service Fabric Classic Cluster
SFMC: Service Fabric Managed Cluster
OS: Operation System
VMSS: Virtual Machine Scale Set
RP: Resource Provider
SFRP: Service Fabric Resource Provider
CRP: Compute Resource Provider
NRP: Network Resource Provider
UD: Update Domain
First, let’s simply talk about the difference between SFCC and SFMC.
1. Main difference between SFCC and SFMC
According to our official document, we can see there are two figures about the SFCC model and SFMC model.
For SFCC model, when we create a new cluster, we need to include all the resource types, such as Public IP Address, Load Balancer, Service Fabric Cluster, VMSS, Storage Account and Key Vault into ARM template or script and set the dependency relationship between them by user himself.
When we want to modify any setting, such as adding a node type, we also need to create a VMSS and all its related resources such as Load Balancer etc. and then mapping this new VMSS to the existing cluster.
In the following figure, you can see all the requests are sent to different RP (The component which is responsible to manage one or some specific resource types).
Service Fabric Classic Cluster design
For SFMC model, when we create a new cluster, the only resource that we need to include in ARM template or script is managed cluster itself. During the creation process, SFRP will be responsible for sending different but corresponding requests to other RPs to create related resources.
When we want to modify any setting, for example still same thing, adding a node type, this time we only need to modify a configuration of the cluster. Once SFRP receives our request, it will send requests to NRP and CRP to create new resources including VMSS, Load Balancer and Public IP Address and mapping them to the existing cluster.
In the following figure, you can see all the requests are sent to the same RP, SFRP and it will be responsible for sending different requests to other RPs depending on the configuration change.
Service Fabric Managed Cluster design
2. The difference of the auto OS upgrade feature design between SFCC and SFMC
For SFCC model, the auto OS upgrade is fully depending on the auto OS upgrade feature of VMSS. Perthis document, we can see when user enables this feature of SFCC, he actually sends the request to CRP, which is controlling the VMSS, to update the setting. This is the same as we enable the auto OS upgrade feature of a dedicated VMSS which is not a part of SFCC.
User -> CRP -> VMSS configuration
CRP will be responsible to monitor the latest OS version and trigger the OS upgrade.
For SFMC model, the design is fully different. When user enables the auto OS upgrade feature, perthis document, we can see the type of resource to modify is starting with Microsoft.ServiceFabric/managedclusters. This identifies that this is a setting which will be handled by SFRP. SFRP will be responsible for monitoring the latest version of the operation system.
User -> SFRP -> SF cluster configuration
Under current design, the biggest difference between the two kinds of auto OS upgrade is the order of the different operation.
For SFCC model, when an OS upgrade is triggered, it will start the upgrade process without checking the status of the cluster. For example, while the cluster is during an upgrade of Service Fabric version, the OS upgrade will also be started UD by UD. This may cause the failure of the Service Fabric version upgrade. But for SFMC model, since the setting is in SFRP, once SFRP found there is a new version of OS which should be used by the underlying VMSS, it will check the cluster status at first. If cluster is during any upgrade, such as Service Fabric upgrade or application upgrade, it will hold on the auto OS upgrade and wait the previous upgrade process to be over. Only when SFRP found the cluster is ready for the auto OS upgrade, it will send request to CRP to reimage the underlying VMSS to new OS version, also UD by UD.