Как запустить несколько дочерних модулей Runbook для учетной записи хранения

Question

У меня есть runbook powershell azure, который выполняет итерацию по большой учетной записи хранения и применяет политики устаревания файлов для больших двоичных объектов в учетной записи. Это работает нормально, но противоречит политике справедливой доли 3 часа. Я могу использовать гибридные рабочие, но я бы предпочел параллельно запускать несколько дочерних модулей Runbook, каждый из которых обрабатывал свою часть учетной записи BLOB-объекта, используя префикс первой буквы.

Пример:

Первая детская беговая дорожка работает A-M Второе: N-Z В-третьих: а-м Четвертый: m-z

Я думаю об использовании префиксной переменной в цикле, который будет перебирать буквы.

## Declaring the variables
$number_of_days_bak_threshold = 15
$number_of_days_trn_threshold = 2
$current_date = get-date
$date_before_blobs_to_be_deleted_bak = $current_date.AddDays(-$number_of_days_bak_threshold)
$date_before_blobs_to_be_deleted_trn = $current_date.AddDays(-$number_of_days_trn_threshold)

# Number of blobs deleted
$blob_count_deleted = 0

# Storage account details
$storage_account_name = <Account Name> 
$storage_account_key = <Account Key>
$container = <Container>

## Creating Storage context for Source, destination and log storage accounts
$context = New-AzureStorageContext -StorageAccountName $storage_account_name -StorageAccountKey $storage_account_key
$blob_list = Get-AzureStorageBlob -Context $context -Container $container

## Creating log file
$log_file = "log-"+(get-date).ToString().Replace('/','-').Replace(' ','-').Replace(':','-') + ".txt"
$local_log_file_path = $env:temp + "\" + "log-"+(get-date).ToString().Replace('/','-').Replace(' ','-').Replace(':','-') + ".txt"

write-host "Log file saved as: " $local_log_file_path -ForegroundColor Green

## Iterate through each blob
foreach($blob_iterator in $blob_list){

    $blob_date = [datetime]$blob_iterator.LastModified.UtcDateTime 

    # Check if the blob's last modified date is less than the threshold date for deletion for trn files:        
    if($blob_iterator.Name -Match ".trn") {
        if($blob_date -le $date_before_blobs_to_be_deleted_trn) {

        Write-Output "-----------------------------------" | Out-File $local_log_file_path -Append
        write-output "Purging blob from Storage: " $blob_iterator.name | Out-File $local_log_file_path -Append
        write-output " " | Out-File $local_log_file_path -Append
        write-output "Last Modified Date of the Blob: " $blob_date | Out-File $local_log_file_path -Append
        Write-Output "-----------------------------------" | Out-File $local_log_file_path -Append

        # Cmdle to delete the blob
        Remove-AzureStorageBlob -Container $container -Blob $blob_iterator.Name -Context $context

        $blob_count_deleted += 1
        Write-Output "Deleted "$extn
        }  
    }
    Elseif($blob_iterator.Name -Match ".bak") {
        if($blob_date -le $date_before_blobs_to_be_deleted_bak) {

        Write-Output "-----------------------------------" | Out-File $local_log_file_path -Append
        write-output "Purging blob from Storage: " $blob_iterator.name | Out-File $local_log_file_path -Append
        write-output " " | Out-File $local_log_file_path -Append
        write-output "Last Modified Date of the Blob: " $blob_date | Out-File $local_log_file_path -Append
        Write-Output "-----------------------------------" | Out-File $local_log_file_path -Append

        # Cmdle to delete the blob
        Remove-AzureStorageBlob -Container $container -Blob $blob_iterator.Name -Context $context

        $blob_count_deleted += 1
        Write-Output "Deleted "$extn
        }  
    }
    Else{
        Write-Error "Unable to determine file type." $blob_iterator.Name
    }
}
Write-Output "Blobs deleted: " $blob_count_deleted | Out-File $local_log_file_path -Append

Я ожидаю, что смогу параллельно проходить через учетную запись.

Answer 1

Итак, Я согласен с @ 4c74356b41, что снижение нагрузки - лучший подход . Однако это само по себе не всегда так просто, как может показаться. Ниже я опишу различные обходные пути для fairshare и потенциальные проблемы, о которых я могу подумать. Это довольно много информации, поэтому вот основные моменты:

• Создание заданий, выполняющих часть работы, а затем запуск следующего задания в последовательности.
• Создание заданий, которые все выполняются на части последовательности параллельно.
• Создание модуля Runbook, который выполняет работу параллельно, но также и в одном задании.
• Используйте PowerShell Workflow с контрольными точками, чтобы ваша работа не подвергалась совместному использованию.
• Миграция рабочей нагрузки для использования функций Azure, например Функции Azure PowerShell .

TL; DR

Независимо от того, что есть способы разделить последовательную рабочую нагрузку на последовательно выполняемые задания, например, каждое задание работает в сегменте, а затем запускает следующее задание в качестве последней операции. ( Как своего рода рекурсия. ) Однако, управление последовательным подходом для правильной обработки периодических сбоев может добавить лот сложности.

Если рабочую нагрузку можно разбить на более мелкие задания, которые не используют много ресурсов, то вы можете выполнять работу параллельно. Другими словами, если объем памяти и ресурсов сокетов, требуемых для каждого сегмента, невелик и до тех пор, пока не будет совпадений или конфликтов, этот подход должен выполняться параллельно гораздо быстрее. Я также подозреваю, что параллельно, объединенные рабочие минуты будут все еще меньше, чем минуты, необходимые для последовательного подхода.

Существует один Гоча с параллельной обработкой сегментов ...

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

Из-за этого получил , если ваша рабочая нагрузка требует большого объема памяти или сокетов, вы можете захотеть иметь родительский runbook, который контролирует жизненный цикл (то есть скорость запуска) дочерних модулей Runbook. , Это имеет искаженный эффект, так что родительский runbook теперь может достигать предела fairshare.

Следующим обходным решением является внедрение модулей Runbook, которые запускают задание для следующего сегмента обработки после его завершения. Наилучшим подходом для этого является сохранение следующего сегмента там, где его может найти задание, например переменная или блоб. Таким образом, если задание завершится неудачно с его сегментом, если есть какой-то способ убедиться, что задания выполняются до тех пор, пока не завершится вся рабочая нагрузка, все в конечном итоге завершится. Возможно, вы захотите использовать задачу наблюдателя для проверки возможного завершения и обработки повторных попыток. Достигнув этого уровня сложности, вы можете поэкспериментировать, чтобы узнать, сколько параллелизма вы можете ввести, не ограничивая ресурсы.

• Для задания нет возможности отслеживать доступный ресурс и регулировать сам.
• Невозможно заставить каждое задание запускаться в отдельной песочнице.
• Является ли задание, выполняемое в одной и той же песочнице, очень недетерминированным, что может вызвать проблемы с трудно отслеживаемыми прерывистыми сбоями.

Если вас не беспокоит ограничение ресурсов , вы можете рассмотреть возможность использования модуля ThreadJob в галерее PowerShell . При таком подходе у вас все равно была бы одна книга запусков, но вы знали, что сможете распараллелить рабочую нагрузку внутри этой книги запусков и завершить рабочую нагрузку, прежде чем достигнете предела доли доступа. Это может быть очень эффективно, если отдельные задачи бывают быстрыми и легкими. В противном случае этот подход может сработать некоторое время, но может потерпеть неудачу, если рабочая нагрузка увеличится либо во времени, либо в необходимых ресурсах.

Не используйте задания PowerShell в задании AA для достижения параллелизма . Это включает , а не с использованием таких команд, как Parallel-ForEach. Существует множество примеров для VM-Start/Stop модулей Runbook, в которых используются задания PowerShell; это не рекомендуемый подход . Для выполнения заданий PowerShell требуются большие ресурсы, поэтому использование заданий PowerShell значительно увеличит ресурсы, используемые вами заданием AA, и увеличит вероятность выделения квоты памяти.

Вы можете обойти ограничение fairshare, повторно внедрив свой код в качестве рабочего процесса Power Shell и выполнив частые проверки. Когда задание рабочего процесса достигает ограничения fairshare, если оно выполняло контрольные точки, оно будет перезапустить на другой песочнице, возобновив с последней контрольной точки.

Насколько я помню, ваша работа должна проходить контрольную точку хотя бы раз в 30 минут. Если они это сделают, это возобновится с ярмарки без штрафа, навсегда . (Ценой огромного количества рабочих минут.)

Даже без контрольной точки рабочий процесс будет повторен 2 раза после достижения контрольной точки. Из-за этого, если ваш код рабочего процесса идемпотентен и быстро пропустит ранее выполненную работу, используя рабочий процесс, ваша работа может завершиться (через 9 часов) даже без контрольных точек.

Однако рабочий процесс - это не просто сценарий Power Shell, заключенный в блок сценария workflow {}:

• Есть много тонких отличий в способе работы рабочего процесса по сравнению со сценариями. Овладеть этими тонкостями в лучшем случае сложно.
• Рабочий процесс не будет проверять все состояния во время выполнения задания. Например, наиболее важным является то, что вам нужно написать свой рабочий процесс, чтобы он проходил повторную аутентификацию в Azure после каждой контрольной точки, поскольку учетные данные не перехватываются контрольной точкой.
• Я не думаю, что кто-то собирается утверждать, что отладка работы АА - простая задача. Для рабочего процесса эта задача еще сложнее. Даже при всех правильных зависимостях способ выполнения рабочего процесса при локальном выполнении отличается от того, как он выполняется в облаке.
• Скрипт работает заметно быстрее, чем рабочий процесс.

Перенос работы в функции Azure . С недавним выпуском функции PowerShell это может быть относительно легко. Функции будут иметь другие ограничения, чем в Automation. Эта разница может хорошо соответствовать вашей рабочей нагрузке или быть еще хуже. Я еще не пробовал подход «Функции», поэтому не могу точно сказать.

Самое очевидное отличие, которое вы сразу заметите, заключается в том, что функции - это гораздо более грубый, ориентированный на DevOps сервис, чем автоматизация. Это отчасти потому, что автоматизация является более зрелым продуктом. (Вероятно, автоматизация была первой широко доступной безсерверной услугой, запущенной примерно за год до Lambda.) Автоматизация была специально создана для автоматизации управления облачными ресурсами, и автоматизация является движущим фактором при выборе функции. Принимая во внимание, что Функции - это гораздо более универсальный подход к работе без сервера. В любом случае, одно очевидное отличие на данный момент заключается в том, что у Functions нет встроенной поддержки таких вещей, как учетная запись RunAs или переменные. Я ожидаю, что функции со временем улучшатся в этом конкретном аспекте, но сейчас это довольно просто для задач автоматизации.