#azure-service-fabric #service-fabric-stateful
#azure-service-fabric #service-fabric-stateful
Вопрос:
У меня есть служба с отслеживанием состояния, которая настраивает резервные копии состояния для основной реплики в RunAsync с использованием учетной записи хранилища Azure.
На днях кто-то случайно удалил учетную запись хранилища, используемую для резервного копирования. При нашем следующем развертывании службы начали выдавать ошибки при инициализации из-за этого ответа об ошибке 404.
Я заметил, что во время развертывания структура, по-видимому, перетасовывает старую версию службы, создавая новые первичные файлы по мере необходимости, чтобы освободить виртуальную машину, которую она обновляет. Если старой версии кода не удается создать экземпляр, вызвав исключение, процесс обновления завершится неудачно, что приведет к откату.
Моя проблема в том, что как только я создаю новую учетную запись хранилища, у меня по-прежнему, по-видимому, не остается возможности вернуть существующие службы в работоспособное состояние. Мои существующие службы используют URL-адреса учетных записей хранения с ключами учетных записей, которые больше не существуют в Azure. Попытки обновления завершаются неудачей, поскольку старые экземпляры службы не могут быть созданы из-за плохой конфигурации.
Есть ли какие-то способы справиться с этой ситуацией?
Ответ №1:
Проще всего было бы использовать неконтролируемое обновление вручную, чтобы принудительно выполнить изменение, которое указало бы службе на новую учетную запись хранилища.
Однако это накладывает на вас большие затраты на управление, особенно если существует много других служб, поскольку вам нужно быть осторожным при выполнении всех проверок безопасности и функциональности вручную, чтобы ничего не регрессировать.
Рекомендуемое решение — использовать описанную здесь ServiceTypeHealthPolicyMap, чтобы «замаскировать» неработоспособную службу (поскольку вы ожидаете, что она будет неработоспособной во время обновления). Вам также может потребоваться настроить некоторые другие параметры обновления в зависимости от конкретной ситуации.
Третья рекомендация или, возможно, что-то, что нужно улучшить в будущем, — это сделать обновление для изменения информации об учетной записи обновлением только для конфигурации. Это гарантировало бы, что SF попытается изменить конфигурацию на месте без перезапуска служб (по умолчанию), что предотвратило бы сбой существующих служб во время обновления и возникновение проблем. Это продемонстрировано в этом примере.
Комментарии:
1. Что произойдет, если я попытаюсь выполнить обновление конфигурации только для службы, которая уже находится в цикле сбоев? получат ли они новую конфигурацию?
2. Да, но общее обновление такое же, как и любое другое обновление, основанное на проверках работоспособности и безопасности. Таким образом, вам необходимо изменить карту политики работоспособности в любом случае. Я упомянул об этом, потому что вы сказали, что ошибка была допущена при отказоустойчивости, и это способ избежать отказоустойчивости (в будущем).
3. хорошо, спасибо, карта политики работоспособности выглядит многообещающе, я просто не могу решить, как часто ее использовать. С одной стороны, было бы неплохо просто сделать это частью сценария обновления CI pipeline fabric, и в целом это обеспечило бы успешное обновление. Но я опасаюсь маскировать ошибки, когда на самом деле существует реальная проблема, поэтому, возможно, сохраню эту опцию только для ручного вмешательства.