CODEWITHSUNDEEP
azure-service-fabricguest-executable
vinfos
vinfos

Reputation: 1

Slow upgrade deployment of guest executable in Service Fabric

I have guest executable (real .net core 1.1 console app) and first deployment take few minutes only. Upgrade deployments take 12+ minutes. There are 3 service instances on 5 node cluster. SF is for developers and there is no workload.

Guest executable is start.cmd

<EntryPoint>
    <ExeHost>
        <Program>start.cmd</Program>
        <Arguments />
        <WorkingFolder>CodePackage</WorkingFolder>
    </ExeHost>
</EntryPoint>

Start.cmd is really simple

start /b /wait "SomeWebAPI" "C:\Program Files\dotnet\dotnet.exe" SomeWebAPI.dll

Appreciate any recommendation to fix slow upgrades.

Upvotes: 0

Views: 571

Answers (2)

vinfos
vinfos

Reputation: 1

Looks like SF does not like applications launched from cmd as another process.

I have found solution for my problem. Upgrade deployment time dropped from 12 minutes to 4 minutes. Mainly you need to run executable directly from you SF. Here are steps to achieve it with .Net Core 1.1.

  • Compile it into EXE by adding following section into project file (Build .NET Core console application to output an EXE?)

    <PropertyGroup>
    <RuntimeIdentifiers>win10-x64</RuntimeIdentifiers>
</PropertyGroup>

  • Create self-contained application 

    dotnet publish -c Release -r win10-x64

  • Set Entry Point to your executable

    <EntryPoint>
    <ExeHost>
        <Program>SomeWebAPI.exe</Program>
        <Arguments />
        <WorkingFolder>CodePackage</WorkingFolder>
    </ExeHost>
</EntryPoint>

Upvotes: 0

Kiryl
Kiryl

Reputation: 1526

That's true that there are cases when upgrade could take longer than the initial deployment. It's happening because SF applies a very robust workflow to ensure that everything works after making an update on a particular upgrade domain. It conducts a number of health checks depending on the health policies, and those checks happen within particular time intervals that were defined for your cluster. Here are some parameters that define the upgrade behavior:

  • HealthCheckWaitDurationSec The time to wait (in seconds) after the upgrade has finished on the upgrade domain before Service Fabric evaluates the health of the application

  • HealthCheckStableDurationSec The duration (in seconds) to verify that the application is stable before moving to the next upgrade domain or completing the upgrade.

  • UpgradeHealthCheckInterval The frequency that the health status is checked.

...and so on. There is also a difference in how upgrade goes for Stateless and Statefull services, which is determined by UpgradeReplicaSetCheckTimeout parameter. Check out Application upgrade parameters and Service Fabric application upgrade for more details.

Upvotes: 1

Related Questions