Ценообразование и тайм-аут Azure

Недавно я заметил, что функции Azure приобрели тайм-аут в 5 минут на динамическом уровне цен где-то вдоль временной шкалы. Поскольку я был занят другими делами, это летело под моим радаром, пока я не заметил, что некоторые длительные функции не завершаются.

Итак, я пошел копать и узнал, что есть два уровня цен - динамический и основанный на приложении сервис. Сайт немного расплывчатый в целом концепции, но, как я понимаю, так оно и есть:

Динамический: взимается за время использования и выделение памяти пользователем. 5-минутный тайм-аут (так бесполезно для однократных длительных операций).

Служба приложений: либо базовая, либо стандартная виртуальная машина уровня, работающая полный рабочий день, ожидающая триггеров. Нет таймаута, чтобы говорить.

Теперь первое разочаровывает меня, поскольку я видел функции как решение для моих заданий, которые нужно уволить один или два раза в год, но затем занять один или два дня (полная резервная копия и упаковка данных для экспорта).

Второй меня смущает - значит ли это, что функция без гражданства теперь работает как веб-приложение, и мне нужно платить за нее как таковую? Если это так, вся концепция функций теперь бесполезна для моих целей, если только я не реализую процессор Cell, не запуская 80000 экземпляров функций при срабатывании, чтобы выполнить работу вовремя. Если это даже возможно.

Может ли кто-нибудь объяснить модель, стоящую за ценой функций, и какое лучшее решение для моей проблемы было бы?

Спасибо.

ОТВЕТЫ

Ответ 1

Служба Azure Batch Service - это то, что вам нужно.

В принципе, вы можете раскручивать требуемые вычислительные ресурсы, когда это требуется, - и вы платите только за время вычисления, которое вы используете, и в Batch Service (что обеспечивает всевозможные добра, такие как обнаружение ошибок, повторные попытки, автоматическое масштабирование) не взимается дополнительная плата. (Кстати, у него есть собственный API), поэтому вы можете полностью автоматизировать его, если требуется)

Вы можете установить собственное программное обеспечение на каждой виртуальной машине в пуле, прежде чем он начнет выполнять работу.

Вы можете автоматически масштабировать пакетное обслуживание на основе настраиваемого правила или просто создать пул фиксированного размера и вручную масштабировать его.

https://azure.microsoft.com/en-gb/services/batch/

Обновить - в соответствии с комментариями this Проблема GitHub, если ваше приложение-функция использует существующую службу App Планируйте, тогда тайм-аут не применяется. По-видимому, динамический параметр или тайм-аут "Расходный план" - это время тайм-аута базовых экземпляров виртуальной машины. Таким образом, это может быть еще один маршрут: заплатить за план обслуживания приложений, затем вы можете использовать функцию App App без тайм-аутов.

Ответ 2

Функции предназначены для обработки коротких задач (менее 5 минут). Но есть обходные пути. Вы можете создать шаблон ARM для развертывания приложения-функции с уровнем обслуживания веб-приложений и удалить его после завершения обработки. Вы можете использовать webjob вместо функций (но вам все равно придется платить за веб-приложение).

Ответ 3

Как кто-то из этой темы сказал, что вы должны попробовать взглянуть на автоматизацию azure или что-то еще, если ваш процесс реже используется и, кроме того, занимает несколько дней.

Без определения точно шкалы (количество файлов/источник и место назначения файла и резервного копирования). Вы можете разбить решение на более мелкие куски (tasks = > functions) и развернуть куски в отдельных планах приложений.

  • Мастер

    • Это будет отвечать за составление списка позиций, которые необходимо резервировать.
    • Мастер просто поднимет билет в очереди или выполнит http-пинг для рабочего.
    • Эта мастер-функция затем может быть развернута в так называемом "плане обслуживания приложений" и может работать более 5 минут.

  • Рабочий

    • Это будет фактически ответственным за резервное копирование одной единицы работы.
    • Эта рабочая функция может быть развернута в то, что теперь называется "Планом потребления", ранее известным как "Динамический план".
    • В плане потребления (AFAIK) у вас может быть 32 экземпляра лазурной функции, работающей параллельно.
    • Вы даже можете клонировать приложение рабочей функции, тем самым параллельно выполняйте резервное копирование рабочих блоков 32/64/128.

С денежной точки зрения имеет смысл понять, что в плане потребления, где вы платите около Гб/с (используемая память и время выполнения), что хост предотвращает длительный срок службы казни от происходящего.

Надеюсь, что это поможет

Ответ 4

Этот поток заслуживает большей ясности. Во-первых, если для вызова функции требуется некоторое время, вы должны захотеть, чтобы она была асинхронной. Во-вторых, если вы сделаете его асинхронным, он не будет таймаутом через 5 минут.

Сделайте снимок: P

DateTime d = DateTime.Now;
Task t = new Task(() =>
{
    log.Info("Doing long task");
    for (int cnt = 0; cnt < 100; cnt++)
    {
        log.Info(DateTime.Now.Subtract(d).ToString());
        System.Threading.Thread.Sleep(10000);
    }
});
t.Start();

В настоящее время я использую их в плане потребления более 5 минут, как и в моем сообщении.. Существует тайм-аут, но он не во время выполнения, так как я запускаю их дольше, чем 5 мин. Тайм-аут находится в вызывающем механизме, который выполняет эту функцию. Если вы сделаете асинхронный вызов, вызывающий абонент вернется и функция продолжит выполнение. Общепринятой практикой является выполнение длительных задач на отдельном потоке/процессе, чем вызывающий поток/процесс. Учет уровня оркестровки функциональной платформы от блокировки в течение длительных периодов времени имеет смысл. Вы не должны блокировать вызывающий уровень для длительных функций, так как это серьезно ухудшит платформу.