You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: articles/service-fabric/release-notes.md
+9-9Lines changed: 9 additions & 9 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -22,25 +22,25 @@ This article provides more information on the latest releases and updates to the
22
22
### Service Fabric 7.1
23
23
Due to the current COVID-19 crisis, and taking into consideration the challenges faced by our customers, we are making 7.1 available, but will not automatically upgrade clusters set to receive automatic upgrades. We are pausing automatic upgrades until further notice to ensure that customers can apply upgrades when most appropriate for them, to avoid unexpected disruptions.
24
24
25
-
You will be able to update to 7.1 via through the [Azure Portal](https://docs.microsoft.com/azure/service-fabric/service-fabric-cluster-upgrade-version-azure#upgrading-to-a-new-version-on-a-cluster-that-is-set-to-manual-mode-via-portal) or via an [Azure Resource Manager deployment](https://docs.microsoft.com/azure/service-fabric/service-fabric-cluster-upgrade-version-azure#set-the-upgrade-mode-using-a-resource-manager-template).
25
+
You will be able to update to 7.1 via through the [Azure portal](https://docs.microsoft.com/azure/service-fabric/service-fabric-cluster-upgrade-version-azure#upgrading-to-a-new-version-on-a-cluster-that-is-set-to-manual-mode-via-portal) or via an [Azure Resource Manager deployment](https://docs.microsoft.com/azure/service-fabric/service-fabric-cluster-upgrade-version-azure#set-the-upgrade-mode-using-a-resource-manager-template).
26
26
27
27
Service Fabric clusters with automatic upgrades enabled will begin to receive the 7.1 update automatically once we resume the standard rollout procedure. We will provide another announcement before the standard rollout begins on the [Service Fabric Tech Community Site](https://techcommunity.microsoft.com/t5/azure-service-fabric/bg-p/Service-Fabric).
28
-
We also have published updates to end of support date for major releases starting from 6.5 till 7.1 [here](https://docs.microsoft.com/azure/service-fabric/service-fabric-versions#supported-versions).
28
+
We also have published updates to end of support date for major releases starting from 6.5 up to 7.1 [here](https://docs.microsoft.com/azure/service-fabric/service-fabric-versions#supported-versions).
29
29
30
30
## What is new in-Service Fabric 7.1?
31
31
We are excited to announce the next release of Service Fabric. This release is loaded with key features and improvements. Some of the key features are highlighted below:
32
32
## Key Announcements
33
33
-**General Availability** of [**Service Fabric Managed Identities for Service Fabric applications**](https://docs.microsoft.com/azure/service-fabric/concepts-managed-identity)
34
-
-[**Support for Ubuntu 1804**](https://docs.microsoft.com/azure/service-fabric/service-fabric-tutorial-create-vnet-and-linux-cluster)
35
-
-[**Preview: VMSS Ephemeral OS disk support**](https://docs.microsoft.com/azure/service-fabric/service-fabric-cluster-azure-deployment-preparation#use-ephemeral-os-disks-for-virtual-machine-scale-sets)**: Ephemeral OS disks are storage created on the local virtual machine, and not saved to remote Azure Storage. They are recommended for all Service Fabric node types (Primary and Secondary), because compared to traditional persistent OS disks, ephemeral OS disks:
34
+
-[**Support for Ubuntu 18.04**](https://docs.microsoft.com/azure/service-fabric/service-fabric-tutorial-create-vnet-and-linux-cluster)
35
+
-[**Preview: Virtual machine scale set Ephemeral OS disk support**](https://docs.microsoft.com/azure/service-fabric/service-fabric-cluster-azure-deployment-preparation#use-ephemeral-os-disks-for-virtual-machine-scale-sets)**: Ephemeral OS disks are storage created on the local virtual machine, and not saved to remote Azure Storage. They are recommended for all Service Fabric node types (Primary and Secondary), because compared to traditional persistent OS disks, ephemeral OS disks:
- Reduce overall costs (the disks are free and incur no additional storage cost)
39
39
- Support for declaration of [**Service Endpoint certificates of Service Fabric applications by subject common name**](https://docs.microsoft.com/azure/service-fabric/service-fabric-service-manifest-resources).
40
40
-[**Support for Health Probes for containerized services**](https://docs.microsoft.com/azure/service-fabric/probes-codepackage): Support for Liveness Probe mechanism for containerized applications. Liveness Probe help announce the liveness of the containerized application and when they do not respond in a timely fashion, it will result in a restart.
41
41
-[**Support for Initializer Code Packages**](https://docs.microsoft.com/azure/service-fabric/initializer-codepackages) for [containers](https://review.docs.microsoft.com/azure/service-fabric/service-fabric-containers-overview) and [guest executable](https://review.docs.microsoft.com/azure/service-fabric/service-fabric-guest-executables-introduction) applications. This allows executing Code Packages (e.g. containers), in a specified order, to perform Service Package initialization.
42
42
-**FabricObserver and ClusterObserver** are stateless applications that capture Service Fabric Telemetry related to different aspects of an SF cluster. Both these applications are ready for deployment to Windows production clusters to capture rich telemetry with implemented support for ApplicationInsights, EventSource and LogAnalytics.
43
-
-[**FabricObserver (FO) 2.0**](https://github.com/microsoft/service-fabric-observer)- runs on all nodes, generates health events, emits telemetry when user configured resource usage thresholds are reached. This release contains several enhancements across monitoring, data management, health event details,structured telemetry.
43
+
-[**FabricObserver (FO) 2.0**](https://github.com/microsoft/service-fabric-observer)- runs on all nodes, generates health events, emits telemetry when user configured resource usage thresholds are reached. This release contains several enhancements across monitoring, data management, health event details,structured telemetry.
44
44
-[**ClusterObserver (CO) 1.1**](https://github.com/microsoft/service-fabric-observer/tree/master/ClusterObserver) - runs on one node, captures cluster level health telemetry. In this release, ClusterObserver also monitors node status and emits telemetry when node is down/disabling/disabled for longer than user-specified time period.
45
45
46
46
### Improve Application life cycle experience
@@ -49,14 +49,14 @@ We are excited to announce the next release of Service Fabric. This release is l
49
49
-**[Automatic Subcluster Detection and Balancing](https://docs.microsoft.com/azure/service-fabric/cluster-resource-manager-subclustering)**: Subclustering happens when services with different placement constraints have a common [load metric](https://docs.microsoft.com/azure/service-fabric/service-fabric-cluster-resource-manager-metrics). If the load on the different sets of nodes differs significantly, the Service Fabric Cluster Resource Manager believes that the cluster is imbalanced, even when it has the best possible balance because of the placement constraints. As a result, it attempts to rebalance the cluster, potentially causing unnecessary service movements (since the "imbalance" cannot be substantially improved). Starting with this release, the Cluster Resource Manager will now attempt to automatically detect these sorts of configurations and understand when the imbalance can be fixed through movement, and when instead it should leave things alone since no substantial improvement can be made.
50
50
-[**Different Move cost for secondary replicas**](https://docs.microsoft.com/azure/service-fabric/service-fabric-cluster-resource-manager-movement-cost): We have introduced new move cost value VeryHigh that provides additional flexibility in some scenarios to define if a separate move cost should be used for secondary replicas.
51
51
- Enabled [**Liveness Probe**](https://docs.microsoft.com/azure/service-fabric/probes-codepackage) mechanism for containerized applications. Liveness Probe help announce the liveness of the containerized application and when they do not respond in a timely fashion, it will result in a restart.
52
-
-[**Run till completion/once for services**](https://docs.microsoft.com/azure/service-fabric/run-to-completion)**
52
+
-[**Run to completion/once for services**](https://docs.microsoft.com/azure/service-fabric/run-to-completion)**
53
53
54
54
### Image Store improvements
55
55
- Service Fabric 7.1 uses **custom transport to secure file transfer between nodes by default**. The dependency on SMB file share is removed from the version 7.1. The secured SMB file shares are still existing on nodes that contains Image Store Service replica for customer's choice to opt out from default and for upgrade and downgrade to old version.
56
56
57
57
### Reliable Collections Improvements
58
58
59
-
-[**In memory only store support for stateful services using Reliable Collections**](https://docs.microsoft.com/azure/service-fabric/service-fabric-work-with-reliable-collections#volatile-reliable-collections): Volatile Reliable Collections allows data to be persisted to disk for durability against large-scale outages, can be used for workloads like replicated cache for example where occasional data loss can be tolerated.Based on the [limitations and restrictions of Volatile Reliable Collections](https://docs.microsoft.com/azure/service-fabric/service-fabric-reliable-services-reliable-collections-guidelines#volatile-reliable-collections), we recommend this for workloads that don't need persistence, for services that handle the rare occasions of Quorum Loss.
59
+
-[**In memory only store support for stateful services using Reliable Collections**](https://docs.microsoft.com/azure/service-fabric/service-fabric-work-with-reliable-collections#volatile-reliable-collections): Volatile Reliable Collections allows data to be persisted to disk for durability against large-scale outages, can be used for workloads like replicated cache, for example, where occasional data loss can be tolerated.Based on the [limitations and restrictions of Volatile Reliable Collections](https://docs.microsoft.com/azure/service-fabric/service-fabric-reliable-services-reliable-collections-guidelines#volatile-reliable-collections), we recommend this for workloads that don't need persistence, for services that handle the rare occasions of Quorum Loss.
60
60
-[**Preview: Service Fabric Backup Explorer**](https://github.com/microsoft/service-fabric-backup-explorer): To ease management of Reliable Collections backups for Service Fabric Stateful applications, Service Fabric Backup Explorer enables users to
61
61
- Audit and review the contents of the Reliable Collections,
62
62
- Update current state to a consistent view
@@ -89,9 +89,9 @@ This is the latest release of Service Fabric and is loaded with key features and
89
89
-[**Resource Limits for User Services**](https://docs.microsoft.com/azure/service-fabric/service-fabric-resource-governance#enforcing-the-resource-limits-for-user-services): Users can set up resource limits for the user services on a node to prevent scenarios such as
90
90
resource exhaustion of the Service Fabric system services.
91
91
92
-
-[**Very High service move cost**](https://docs.microsoft.com/azure/service-fabric/service-fabric-cluster-resource-manager-movement-cost) for a replica type. Replicas with Very High move cost will be moved only if there is a constraint violation in the cluster that cannot be fixed in any other way. Please see the docs for additional information on when usage of a “Very High” move cost is reasonable and for additional considerations.
92
+
-[**Very High service move cost**](https://docs.microsoft.com/azure/service-fabric/service-fabric-cluster-resource-manager-movement-cost) for a replica type. Replicas with Very High move cost will be moved only if there is a constraint violation in the cluster that cannot be fixed in any other way. Refer to the linked document for additional information on when usage of a “Very High” move cost is reasonable and for additional considerations.
93
93
94
-
-**Additional cluster safety checks**: In this release we introduced a configurable seed node quorum safety check. This allows you to
94
+
-**Additional cluster safety checks**: In this release, we introduced a configurable seed node quorum safety check. This allows you to
95
95
customize how many seed nodes must be available during cluster life-cycle and management scenarios. Operations which would take the
96
96
cluster below the configured value are blocked. Today the default value is always a quorum of the seed nodes, for example, if you have 7 seed nodes, an operation that would take you below 5 seed nodes would be blocked by default. With this change, you could make
97
97
the minimum safe value 6, which would allow only one seed node to be down at a time.
0 commit comments