Service Fabric SDK v1.5.175 and the adoption of Virtual Machine Scale Sets
Published Aug 06 2019 03:57 PM 1,549 Views
Bronze Contributor
First published on MSDN on Feb 23, 2016

Today, we are announcing an update to our preview SDK and the adoption of Virtual Machine Scale Sets in Azure-hosted clusters. As part of this release, we are making a series of changes based on your feedback, some of which are breaking. Please read the notes below carefully to understand what you need to do to adopt the new release.



SDK Update


This release of the SDK includes a number of new features, along with some key bug fixes and general performance and reliability improvements.


Windows 7 Support for Development


We heard you loud and clear on the need for Windows 7 support for development machines. Starting with this release, you can run a local cluster and deploy applications to it from Visual Studio 2015 on Windows 7.


Important notes :



  1. There is a bug impacting the Visual Studio debugger for Service Fabric applications on Windows 7. To fix it, you will need to install the Visual Studio 2015 Update 2 CTP .

  2. The Service Fabric PowerShell cmdlets require PowerShell 3.0 or higher, whereas Windows 7 includes PowerShell 2.0 by default. If you have not updated PowerShell to a recent release on your Windows 7 machine, you will need to do so to use the Service Fabric SDK.



Delete actors


The Reliable Actors framework includes a form of garbage collection that serializes actor state to disk and then removes the actor object from memory after a period of inactivity. This ensures that you aren’t consuming a large amount of memory in your clusters holding on to actors that are not being used. However, in some cases, you may want to go further than just removing the actors from memory and delete them from the cluster entirely, either to limit storage usage or for compliance. This release adds this capability.


The DeleteActorAsync method can be invoked using ActorServiceProxy as shown below:


var serviceUri = ActorNameFormat.GetFabricServiceUri(typeof(IMyActor), actorAppName);
var actorServiceProxy = ActorServiceProxy.Create(actorId.GetPartitionKey(), serviceUri);
await actorServiceProxy.DeleteActorAsync(actorId, cancellationToken);


Query actors


In order to determine the actors to delete, you’ll probably want to figure out which actors have been created. We have enabled the ability to query the set of actors in a given partition.


This is an Actor Service level operation with following signature:


Task<PagedResult<ActorInformation>> GetActorsAsync(ContinuationToken continuationToken, CancellationToken cancellationToken);



This API returns a PagedResult which contains a list of ActorInformation and a continuationToken signifying if more calls are needed to get complete list of actors.


This method can be invoked using ActorServiceProxy as shown below:


var serviceUri = ActorNameFormat.GetFabricServiceUri(typeof(IMyActor), actorAppName);
var actorServiceProxy = ActorServiceProxy.Create(partitionKey, serviceUri);
ContinuationToken continuationToken = null;
var queriedActorCount = 0;


do
{


var queryResult = actorServiceProxy.GetActorsAsync(continuationToken, cancellationToken);
queriedActorCount += queryResult.Items.Count();
continuationToken = queryResult.ContinuationToken;


} while (continuationToken != null);



CancellationToken support for IService/IActor



Reliable Service and Reliable Actor methods now support a cancellation token that can be remoted via ActorProxy and ServiceProxy, allowing you to implement cooperative cancellation. Clients that want to cancel a long running service or actor method can signal the cancellation token and that cancellation intent will be propagated to the actor/service method. That method can then determine when to stop execution by looking at the state of its cancellation token argument.


For example, an actor’s contract that has a possibly long-running method can be modelled as shown below:


public interface IPrimeNumberActorInterface : IActor
{


Task<ulong> FindNextPrimeNumberAsync
(ulong previous, CancellationToken cancellationToken);


}


The client code that wishes to cancel the method execution can communicate its intent by canceling the cancellation token.


Flexible application packaging for guest executables


Service Fabric can provide orchestration and high-availability for arbitrary executables, referred to as “guest executables” . In some cases, you may want to build an application that is a combination of Reliable Services/Reliable Actors (or “service host executables”) and guest executables. Previously, these types of application packages had to be managed entirely outside of Visual Studio because there was no way to include guest executables in the application package created by VS and msbuild would complain if it found services in the application manifest that did not have a corresponding service project in the solution.


To better support this scenario, the application project now includes an ApplicationPackageRoot folder, similar to the PackageRoot folder found in service projects. The contents of this directory will be directly copied to the generated application package.


Important : as part of this change, the ApplicationManifest file has been moved under the ApplicationPackageRoot folder. Visual Studio will automatically move it as part of project upgrade but you will need to ensure that the move is properly reflected if your project is checked into source control.



Key bug fixes


In addition to the features described above, the following key bugs are fixed in this release:



  • An assembly naming clash with Java that was causing FabricHost not to start on some machines with the JRE installed.

  • A long-path issue with the Test-ServiceFabricApplicationPackage PowerShell cmdlet that was causing deployment failures with ASP.NET 5/ASP.NET Core projects.



API Breaking Changes


Transaction object now required in IReliableQueue::GetCountAsync


To ensure consistent results, we now provide the count of objects in the queue within transaction scope. To enable this, we require a transaction object to be provided to the GetCountAsync call.



IReliableDictionary::Count property replaced by IReliableDictionary::GetCountAsync method


To align with IReliableQueue, IReliableDictionary’s Count property has been replaced with a GetCountAsync method.



Reliable collections interfaces no longer implement IEnumerable – use CreateEnumerableAsync instead


In order to prepare for upcoming releases where the data in Reliable Collections may be paged to disk, the ReliableQueue and ReliableDictionary no longer implement IEnumerable directly. Instead, you should use the CreateEnumerableAsync method to acquire an enumerable collection. Note that IEnumerables returned by CreateEnumerableAsync can only be enumerated within transaction scope, so if you intend to use them elsewhere, you will need move the results into a temporary collection, such as a List.



Testability APIs moved into System.Fabric assembly and moved namespaces


The testability APIs previously included in the Microsoft.ServiceFabric.Testability NuGet package have now been moved to the System.Fabric assembly and are accessible via the FabricClient type. More specifically, the following methods previously available under System.Fabric.Testability.TestabilityExtensions, are now available via the TestManager and FaultManager properties, as shown below:


































































Old location (under System.Fabric.Testability.TestabilityExtensions)



New location (under System.Fabric.FabricClient)



InvokeDataLossAsync



TestManager



InvokeQuorumLossAsync



TestManager



RestartPartitionAsync



TestManager



ValidateApplicationAsync



TestManager



ValidateServiceAsync



TestManager



CleanTestStateAsync



TestManager



MovePrimaryAsync



FaultManager



MoveSecondaryAsync



FaultManager



StartNodeAsync



FaultManager



StopNodeAsync



FaultManager



RestartNodeAsync



FaultManager



RemoveReplicaAsync



FaultManager



RestartReplicaAsync



FaultManager



RestartDeployedCodePackageAsync



FaultManager




Virtual Machine Scale Sets


In our initial preview release, Service Fabric clusters created in Azure were based on “single-instance virtual machines”, meaning that a specific set of VMs were pre-defined to form the basis of the cluster. Scaling the cluster up or down required that you manually add or remove VMs. Going forward, new Service Fabric clusters will be based on Virtual Machine Scale Sets (VMSS) . With VMSS, every node type in your cluster will be tied to a VM scale set, allowing you to define rules for when the number of VMs of that type should grow and shrink. Note that the auto-scaling functionality of VMSS is not integrated with Service Fabric yet and will be enabled in an upcoming release.



Updating to the new release


You can install the new SDK using the Web Platform Installer . To take advantage of the new APIs described above in existing projects, you will need to update your NuGet packages to the latest versions.


Important note :


Because of the move to VMSS and the breaking changes in our APIs, we have elected to leave existing clusters in place and fixed on the existing Service Runtime version (4.4.104.9494). If you’re using the existing SDK/NuGet packages (v1.4.87) and targeting those clusters, you can continue to do so. However, in order to deploy apps created with the new SDK or existing apps upgraded to the new NuGet packages to Azure, you will need to create new clusters. Once we reach general availability, this will no longer occur. You can check the version of your cluster in the Azure portal:




The following table offers a quick guide to compatibility:


















Runtime Version


Compatible SDK/NuGet package version
4.4.x 1.4.87
4.5.x 1.5.175


Known Issues


Application project upgrade errors with ASP.NET 5 (aka ASP.NET Core) projects


When you open an existing Service Fabric project with the updated tooling extension included in this SDK, Visual Studio will attempt to upgrade your project to the latest version. Before it does that, it takes the existing contents of your application project folder and moves them to a Backup folder. Given the depth of ASP.NET 5 projects, you may already be close to the limit on path length, so pushing things down another level may cause an error like this:



If you hit this, try deleting the auto-generated folders (bin, obj, and pkg) from the application project directory.



Questions and feedback


As always, we are monitoring Twitter , StackOverflow , MSDN , Azure.com , and our feedback forum for your comments and questions.



The Service Fabric Team

Version history
Last update:
‎Aug 06 2019 03:57 PM
Updated by: