Смена Управляемый экземпляр SQL, включенная управляемыми службой Azure Arc учетными данными (предварительная версия)
В этой статье описывается смена учетных данных, управляемых службой, для Управляемый экземпляр SQL включенной Azure Arc. Службы данных Arc создают различные управляемые службой учетные данные, такие как сертификаты и имена входа SQL, используемые для мониторинга, резервного копирования и восстановления, высокой доступности и т. д. Эти учетные данные считаются пользовательскими учетными данными ресурсов, управляемыми службами данных Azure Arc.
Смена учетных данных, управляемых службой, — это активная пользователем операция, которая инициируется во время проблемы безопасности или когда для соответствия требованиям требуется периодический поворот.
Ограничения
При смене управляемых службой управляемых службой учетных данных управляемого экземпляра следует учитывать следующие ограничения.
- Группы отработки отказа SQL Server не поддерживаются.
- Автоматическая предплановая смена не поддерживается.
- Симметричные ключи DPAPI, keytab, учетные записи Active Directory и учетные данные TDE, управляемые службой, не включаются в эту смену учетных данных.
Уровень общего назначения
Во время смены учетных данных, управляемых службой Управляемый экземпляр SQL, модуль pod Kubernetes управляемого экземпляра завершается и перепроиздается с помощью повернутых учетных данных. Этот процесс приводит к короткому времени простоя при создании нового модуля pod управляемого экземпляра. Чтобы справиться с прерыванием, создайте устойчивость в приложении, например логику повторных попыток подключения, чтобы обеспечить минимальное нарушение. Ознакомьтесь с обзором основы надежности для получения дополнительных сведений о том, как разработать рекомендации по устойчивости и повторным попыткам для служб Azure.
Уровень "Критически важный для бизнеса"
Во время смены учетных данных, управляемой службой критически важный для бизнеса Управляемый экземпляр SQL с несколькими репликами:
- Модули pod вторичной реплики завершаются и повторно создаются с помощью поворачиваемых учетных данных, управляемых службой.
- После повторной подготовки реплик первичная реплика отработка отказа будет выполнена повторной подготовкой реплики.
- Предыдущий основной модуль pod завершается и повторно создается с помощью измененных учетных данных, управляемых службой, и становится вторичным.
Существует короткий момент простоя, когда происходит отработка отказа.
Необходимые условия:
Прежде чем продолжить работу с этой статьей, необходимо включить Управляемый экземпляр SQL созданным ресурсом Azure Arc.
Смена учетных данных, управляемых службой, в управляемом экземпляре
Учетные данные, управляемые службой, связаны с созданием в управляемом экземпляре. Чтобы сменить все учетные данные, управляемые службой для управляемого экземпляра, необходимо увеличить поколение на 1.
Выполните следующие команды, чтобы получить текущее поколение учетных данных, управляемых службой, из спецификации, и создайте новое поколение учетных данных, управляемых службой. Это действие активирует смену учетных данных, управляемых службой.
rotateCredentialGeneration=$(($(kubectl get sqlmi <sqlmi-name> -o jsonpath='{.spec.update.managedCredentialsGeneration}' -n <namespace>) + 1))
kubectl patch sqlmi <sqlmi-name> --namespace <namespace> --type merge --patch '{ "spec": { "update": { "managedCredentialsGeneration": '$rotateCredentialGeneration'} } }'
Определяет managedCredentialsGeneration целевое поколение учетных данных, управляемых службой. Остальные функции, такие как конфигурация и топология kubernetes, остаются неизменными.
Как откатить учетные данные, управляемые службой, в управляемом экземпляре
Примечание.
При сбое смены учетных данных требуется откат. Откат к предыдущему поколению учетных данных поддерживается только один раз до n-1, где n является текущим поколением.
Если откат активируется во время смены учетных данных, и все реплики не были повторно подготовлены, то откат может занять около 30 минут, чтобы управляемый экземпляр был в состоянии готовности .
Выполните следующие две команды, чтобы получить текущее поколение учетных данных, управляемых службой, из спецификации и откат к предыдущему поколению учетных данных, управляемых службой:
rotateCredentialGeneration=$(($(kubectl get sqlmi <sqlmi-name> -o jsonpath='{.spec.update.managedCredentialsGeneration}' -n <namespace>) - 1))
kubectl patch sqlmi <sqlmi-name> --namespace <namespace> --type merge --patch '{ "spec": { "update": { "managedCredentialsGeneration": '$rotateCredentialGeneration'} } }'
Активация отката аналогична активации смены учетных данных, управляемых службой, за исключением того, что целевое поколение является предыдущим поколением и не создает новое поколение или учетные данные.