#azure-webjobs #azure-webjobssdk #webjob #azure-webjobs-continuous
Вопрос:
У меня есть веб-задание Azure, которое выполняется с помощью таймера, чтобы поместить некоторые сообщения в очередь служебной шины. Я развернул это веб-задание в 2 отдельных регионах для обеспечения высокой доступности на случай, если один регион выйдет из строя. Согласно https://github.com/Azure/azure-webjobs-sdk-extensions/wiki/TimerTrigger, Я вижу, что механизм распределенной блокировки работает идеально, а таймер выполняется только в одном регионе за раз, поэтому повторяющихся запросов не поступает.
Однако веб-задания в обоих регионах используют одну и ту же общую учетную запись хранения, и учетная запись хранения развертывается только в одном регионе. Я не могу использовать 2 отдельные учетные записи хранения, потому что тогда я потеряю функциональность распределенной блокировки. Я знаю, что Azure предоставляет геоизбыточное хранилище для моей учетной записи хранения, поэтому данные реплицируются во вторичный регион.
Мой вопрос заключается в следующем: в случае аварии в одном регионе (в частности, в основном регионе учетной записи хранения), существует ли способ автоматического перехода веб-задания на резервную конечную точку? Прямо сейчас у меня есть параметр приложения «AzureWebJobsStorage», указанный в качестве одного из общих ключей доступа учетной записи хранилища.
Ценю любые подсказки!
Ответ №1:
Я не эксперт по SDK для хранилища, но я связал два документа, которые могут помочь вам понять, как сделать ваше приложение максимально доступным.
- https://docs.microsoft.com/en-us/azure/storage/common/storage-disaster-recovery-guidance?toc=/azure/storage/blobs/toc.json
- https://docs.microsoft.com/en-us/azure/storage/common/geo-redundant-design?tabs=legacy
- https://docs.microsoft.com/en-us/azure/storage/blobs/storage-create-geo-redundant-storage?tabs=dotnet11
Поскольку предостережение с геоизбыточным хранилищем заключается в том, что оно доступно только для чтения на вторичном сервере, пока вы не сделаете запрос в противном случае, я нашел свойство GeoRedundantSecondaryUri в BlobClientOptions, которое будет использовать вторичный адрес как часть политики повторных попыток.