Медленное обновление развертывания гостевого исполняемого файла в Service Fabric

У меня есть гостевой исполняемый файл (реальное консольное приложение.net core 1.1), и первое развертывание займет всего несколько минут. Развертывание обновлений занимает более 12 минут. На кластере из 5 узлов есть 3 экземпляра службы. SF для разработчиков, и нет никакой нагрузки.

Гостевой исполняемый файл start.cmd

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

Start.cmd действительно прост

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

Цените любые рекомендации по исправлению медленных обновлений.

2 ответа

Это правда, что есть случаи, когда обновление может занять больше времени, чем первоначальное развертывание. Это происходит потому, что SF применяет очень надежный рабочий процесс, чтобы гарантировать, что все работает после обновления в определенном домене обновления. Он выполняет ряд проверок работоспособности в зависимости от политик работоспособности, и эти проверки происходят в определенные промежутки времени, определенные для вашего кластера. Вот некоторые параметры, которые определяют поведение при обновлении:

  • HealthCheckWaitDurationSec Время ожидания (в секундах) после завершения обновления в домене обновления, прежде чем Service Fabric оценит работоспособность приложения.

  • HealthCheckStableDurationSec Продолжительность (в секундах) проверки стабильности приложения перед переходом в следующий домен обновления или завершением обновления.

  • UpgradeHealthCheckInterval Частота проверки состояния работоспособности.

...и так далее. Существует также разница в том, как выполняется обновление для служб без сохранения состояния и Statefull, что определяется параметром UpgradeReplicaSetCheckTimeout. Ознакомьтесь с параметрами обновления приложения и обновлением приложения Service Fabric для получения более подробной информации.

Похоже, SF не любит приложения, запущенные из cmd, как другой процесс.

Я нашел решение для моей проблемы. Время развертывания обновления сократилось с 12 до 4 минут. В основном вам нужно запускать исполняемый файл прямо с вашего SF. Вот шаги для достижения этого с.Net Core 1.1.

  • Скомпилируйте его в EXE, добавив следующий раздел в файл проекта ( Создать консольное приложение.NET Core для вывода EXE?)

    <PropertyGroup>
        <RuntimeIdentifiers>win10-x64</RuntimeIdentifiers>
    </PropertyGroup>
    
  • Создать автономное приложение

    dotnet publish -c Release -r win10-x64
    
  • Установите точку входа в ваш исполняемый файл

    <EntryPoint>
        <ExeHost>
            <Program>SomeWebAPI.exe</Program>
            <Arguments />
            <WorkingFolder>CodePackage</WorkingFolder>
        </ExeHost>
    </EntryPoint>
    
Другие вопросы по тегам