Поделиться через

Надежность в Управляемый экземпляр SQL Azure

Управляемый экземпляр SQL Azure — это полностью управляемая платформа как ядро СУБД PaaS. Она обеспечивает почти 100% совместимость функций с SQL Server. Управляемый экземпляр SQL Azure обрабатывает большинство функций управления базами данных, таких как обновление, исправление, резервное копирование и мониторинг без участия пользователя. Он выполняется в последней стабильной версии ядра СУБД SQL Server и исправленной операционной системы с встроенной высокой доступностью.

При использовании #REF! надежность является совместной ответственностью. Корпорация Майкрософт предоставляет ряд возможностей для поддержки устойчивости и восстановления. Вы несете ответственность за понимание того, как работают эти возможности во всех используемых вами службах, а также за выбор возможностей, необходимых для достижения бизнес-целей и целей бесперебойной работы.

В этой статье описывается, как обеспечить устойчивость Управляемый экземпляр SQL Azure к различным потенциальным сбоям и проблемам, в том числе временным сбоям, сбоям в зонах доступности и сбоям регионов. В нем также описывается, как использовать резервные копии для восстановления из других типов проблем, как обрабатывать обслуживание службы, и выделяет некоторые ключевые сведения о соглашении об уровне обслуживания (SLA) Управляемый экземпляр SQL Azure.

Рекомендации по развертыванию в рабочей среде для обеспечения надежности

Для большинства рабочих развертываний Управляемый экземпляр SQL рассмотрим следующие рекомендации.

  • Следуйте указаниям, приведенным в контрольном списке высокого уровня доступности и аварийного восстановления (DR).
  • Включите зоновую избыточность.
  • Настройте автоматическое резервное копирование и используйте хранилище с избыточностью между зонами (ZRS) или геоизбыточное (GRS) для резервного копирования.
  • Планируете регулярно тестировать резервные копии и процесс восстановления.

Обзор архитектуры надежности

Управляемые экземпляры SQL общего назначения выполняются на одном узле, который #REF! управляет. Всякий раз, когда ядро СУБД или операционная система обновляется или возникает сбой, Управляемый экземпляр SQL работает со Service Fabric для перемещения процесса ядра СУБД без отслеживания состояния в другой вычислительный узел без отслеживания состояния, имеющий достаточную свободную емкость. Файлы базы данных хранятся в Хранилище BLOB-объектов Azure с встроенными функциями избыточности. Файлы данных и журналов отсоединяются от исходного вычислительного узла и подключаются к недавно инициализированному процессу ядра СУБД.

Управляемые экземпляры SQL для критически важного бизнеса используют несколько реплик в кластере. Кластер включает два типа реплик:

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

  • До пяти вторичных реплик (вычисления и хранения), содержащих копии данных.

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

Управляемый экземпляр SQL и Service Fabric инициируют переключение на резервную копию между репликами. После того как вторичная реплика станет новой первичной репликой, создается другая вторичная реплика, чтобы убедиться, что кластер имеет достаточное количество реплик для поддержания кворума. После завершения переключения на резервный сервер, подключения Azure SQL автоматически перенаправляются на новую первичную реплику или читаемую вторичную реплику на основе строки подключения.

Избыточность

По умолчанию Управляемый экземпляр SQL обеспечивает избыточность путем распространения вычислительных узлов и данных в одном центре обработки данных в основном регионе. Этот подход защищает данные во время следующих ожидаемых и непредвиденных простоев:

  • Операции управления, инициированные клиентом, которые приводят к краткому простою

  • Операции обслуживания сервиса

  • Небольшие сети или сбои питания

  • Проблемы и сбои центра обработки данных, связанные со следующими компонентами:

    • Стойка, где работают машины, управляющие вашей службой

    • физический компьютер, на котором размещена виртуальная машина под управлением SQL ядро СУБД.

    • VM, на котором выполняется движок базы данных SQL

  • Проблемы с движком базы данных SQL

  • Потенциальные незапланированные локализованные сбои

Дополнительные сведения о том, как Управляемый экземпляр SQL обеспечивает избыточность, см. в разделе Доступность при локальной и зональной избыточности.

Устойчивость к временным сбоям

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

Все облачные приложения должны следовать #REF! рекомендации по обработке временных ошибок при обмене данными с любыми размещенными в облаке API, базами данных и другими компонентами. Дополнительные сведения см. в Рекомендациях по обработке временных сбоев.

Управляемый экземпляр SQL автоматически обрабатывает критически важные задачи обслуживания, такие как установка исправлений, резервное копирование и обновления #REF! и SQL ядро СУБД. Он также обрабатывает незапланированные события, такие как базовые аппаратные, программные или сетевые сбои. Управляемый экземпляр SQL может быстро восстановиться даже в самых критических обстоятельствах, что гарантирует, что ваши данные всегда доступны. Большинство пользователей не замечают, что обновления выполняются непрерывно.

При исправлении или отработке отказа экземпляра время простоя имеет минимальный эффект при использовании логики повторных попыток в приложении. Вы можете проверить устойчивость приложения к временным сбоям.

Устойчивость к сбоям зоны доступности

Замечание

В настоящее время зональная избыточность недоступна для уровня сервиса "General Purpose" следующего поколения.

Зоны Availability физически разделяют группы центров обработки данных в #REF! регионе. При сбое одной зоны службы могут переключиться на одну из оставшихся зон.

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

Управляемый экземпляр SQL достигает избыточности зоны, размещая статические вычислительные узлы в разных зонах доступности. Он использует ZRS с сохранением состояния, подключенный к узлу, который в настоящее время содержит активный процесс SQL ядро СУБД. Если происходит сбой, SQL ядро СУБД активируется на одном из бестейтовых вычислительных узлов, который затем обращается к данным в стейтфул-хранилище.

Управляемый экземпляр SQL достигает зоновой избыточности путем размещения реплик Управляемый экземпляр SQL по нескольким зонам доступности. Чтобы устранить одну точку сбоя, кольцо управления также дублируется в нескольких зонах. Трафик плоскости управления направляется к балансировщику нагрузки, который также развернут в зонах доступности. Диспетчер трафика Azure управляет маршрутизацией трафика из плоскости управления в подсистему балансировки нагрузки.

Требования

  • Region support: Избыточность зон для Управляемый экземпляр SQL поддерживается в выбранных регионах. Дополнительные сведения см. в разделе "Поддерживаемые регионы".

  • Избыточность хранилища резервных копий: Чтобы включить зональную избыточность для управляемого экземпляра SQL, задайте избыточность хранилища резервных копий как ZRS или Геозонально-избыточное хранилище (GZRS).

Себестоимость

При включении зональной избыточности возникают дополнительные расходы на управляемые экземпляры SQL и зонально-избыточное резервное копирование. Дополнительные сведения см. на странице цен.

Вы можете сэкономить деньги, взяв на себя обязательство использовать вычислительные ресурсы со скидкой в течение определенного периода времени, включая экземпляры с зональным резервированием в тарифе "Критически важный для бизнеса". Дополнительные сведения см. в разделе Резервирования для Управляемый экземпляр SQL.

Настройка поддержки зоны доступности

В этом разделе объясняется, как настроить поддержку зоны доступности для управляемых экземпляров SQL:

  • Включите избыточность зон: Подробные сведения о настройке избыточности зон для новых и существующих экземпляров представлены в статье "Настройка избыточности зоны".

    Все операции масштабирования для Управляемый экземпляр SQL, включая включение избыточности зоны, происходят в онлайн-режиме и требуют минимального или вовсе не требуют времени простоя. Дополнительные сведения см. в разделе "Длительность операций управления".

  • Отключите избыточность зоны: Вы можете отключить избыточность зоны, выполнив те же действия, чтобы включить избыточность зоны. Этот процесс является оперативной операцией, аналогичной обычному обновлению целевого уровня служб. В конце процесса экземпляр переносится из межзональной инфраструктуры с резервированием в инфраструктуру в одной зоне.

Поведение, когда все зоны работоспособны

В этом разделе описывается, что ожидать, когда управляемый экземпляр SQL настроен на избыточность зоны и все зоны доступности работают:

  • Маршрутизация трафика между зонами: Во время обычных операций запросы направляются на узел, на котором выполняется компонент вычислений Управляемый экземпляр SQL.

  • репликация данных между зонами: файлы базы данных хранятся в служба хранилища Azure с помощью ZRS, который подключён к узлу, в котором сейчас содержится активный процесс SQL ядро СУБД.

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

  • Маршрутизация трафика между зонами: Во время обычных операций запросы направляются в основную реплику управляемого экземпляра SQL.

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

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

Поведение во время сбоя зоны

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

  • Обнаружение и реагирование: Управляемый экземпляр SQL отвечает за обнаружение и реагирование на сбой в зоне доступности. Вам не нужно ничего делать, чтобы инициировать переключение зоны.
  • Активные запросы: Если зона доступности недоступна, все запросы, обрабатываемые в неисправной зоне доступности, завершаются и должны быть повторно отправлены. Чтобы сделать приложения устойчивыми к этим типам проблем, см. рекомендации по устойчивости к временным сбоям .

  • Traffic rerouting: Управляемый экземпляр SQL работает со Service Fabric для перемещения ядра СУБД в подходящий вычислительный узел без состояния, который находится в другой зоне доступности и имеет достаточную свободную емкость. После завершения переключения новые подключения автоматически перенаправляются на новый первичный вычислительный узел.

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

  • Перенаправление трафика: Управляемый экземпляр SQL взаимодействует с Service Fabric для выбора подходящей реплики в другой зоне доступности, чтобы та стала основной репликой. После того как вторичная реплика станет новой первичной репликой, создается другая вторичная реплика, чтобы убедиться, что кластер имеет достаточное количество реплик для поддержания кворума. После завершения аварийного переключения новые подключения автоматически перенаправляются на новую первичную реплику или на читаемую вторичную реплику в соответствии с строка подключения.

  • Ожидаемое время простоя: Во время переключения зоны доступности может потребоваться небольшое время простоя. Время простоя обычно меньше 30 секунд, которое приложение должно терпеть, если оно следует рекомендациям по устойчивости к временным сбоям .

  • Ожидаемая потеря данных: При переключении на резервную зону не ожидается потеря данных для зафиксированных транзакций. Выполняющиеся транзакции необходимо повторить.

Восстановление зоны

Когда зона доступности восстанавливается, Управляемый экземпляр SQL работает со Service Fabric для восстановления операций в восстановленной зоне. Никакое вмешательство клиента не требуется.

Тестирование на сбои в зоне

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

Устойчивость к сбоям на уровне региона

Отдельный Управляемый экземпляр SQL развертывается в одном регионе. Однако можно развернуть вторичный управляемый экземпляр SQL в отдельном регионе #REF! и настроить группу failover.

Группы переключения при отказе

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

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

Политики отказоустойчивости

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

  • Отработка отказа, управляемого клиентом (рекомендуется): При использовании политики отработки отказа, управляемой клиентом, можно решить, следует ли выполнять отработку отказа, которая не приводит к потере данных или принудительной отработке отказа, что может привести к потере данных. Принудительное переключение используется в качестве метода восстановления во время сбоев, когда основной экземпляр недоступен.

  • Аварийное переключение, управляемое корпорацией Майкрософт: Аварийное переключение, управляемое корпорацией Майкрософт, используется только в исключительных случаях для принудительного переключения.

Это важно

Используйте варианты переключения на резервный ресурс с управлением клиентом для разработки, тестирования и реализации ваших планов аварийного восстановления. Не полагайтесь на отработку отказа, управляемую корпорацией Майкрософт, которая может использоваться только в чрезвычайных обстоятельствах. Переключение на резерв под управлением Microsoft, скорее всего, инициируется для всего региона. Его нельзя инициировать для отдельных групп отказоустойчивости, управляемых экземпляров SQL, клиентов или подписок. Отработка отказа может происходить в разное время для разных служб #REF!. Мы рекомендуем использовать переключение на резервный узел, управляемое клиентом.

Требования

  • Region support: Можно выбрать любой регион #REF! для управляемых экземпляров SQL в группе обеспечения отказоустойчивости. Из-за высокой задержки сетей с широкими областями георепликация использует механизм асинхронной репликации. Чтобы уменьшить задержки сети, выберите регионы с низкой задержкой. Дополнительные сведения о задержке между регионами #REF! см. в статистике сетевой задержки на круговых маршрутах #REF!.

Себестоимость

При создании нескольких управляемых экземпляров SQL в разных регионах взимается плата за каждый управляемый экземпляр SQL.

Однако если в дополнительном экземпляре нет рабочих нагрузок чтения или приложений, подключенных к нему, можно сэкономить на затратах на лицензирование, назначив реплику в качестве резервного экземпляра. Дополнительные сведения см. в разделе Настройка резервной реплики без лицензии для Управляемый экземпляр SQL.

Дополнительные сведения о ценах на Управляемый экземпляр SQL см. в разделе Информация о стоимости услуги.

Настройка поддержки нескольких регионов

Чтобы узнать, как настроить группу отработки отказа, прочитайте статью Настройка группы отработки отказа для Управляемый экземпляр SQL.

Планирование ресурсов и управление ими

Во время переключения при отказе трафик перенаправляется на вторичный управляемый экземпляр SQL. Важно, чтобы вторичный управляемый экземпляр SQL готов к получению трафика. Создайте вторичный управляемый экземпляр SQL с тем же уровнем служб, поколением оборудования и размером вычислений, что и основной экземпляр.

Дополнительные сведения о масштабировании управляемых экземпляров базы данных SQL в группе отказоустойчивости см. в документе Масштабирование экземпляров.

Поведение, когда все регионы работоспособны

В этом разделе описывается, что ожидать, когда управляемые экземпляры SQL настроены для использования групп отказоустойчивости в нескольких регионах и все регионы работают:

  • Маршрутизация трафика между регионами: Во время обычных операций запросы на чтение и запись отправляются в один первичный экземпляр в основном регионе.

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

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

  • Репликация данных между регионами: По умолчанию данные реплицируются асинхронно из первичного экземпляра в дополнительный управляемый экземпляр SQL.

    Поскольку георепликация асинхронна, при принудительном отказе может произойти потеря данных. Вы можете отслеживать задержку репликации, чтобы понять потенциальную потерю данных во время принудительного переключения на резерв. См. дополнительные сведения в контрольном списке аварийного восстановления.

    Если необходимо исключить потерю данных из-за асинхронной репликации при отказе, настройте приложение так, чтобы оно блокировало вызывающий поток до подтверждения передачи и записи последней зафиксированной транзакции в журнал транзакций резервной базы данных. Этот подход требует пользовательской разработки и снижает производительность приложения. Дополнительные сведения см. в разделе "Предотвращение потери критически важных данных".

Поведение во время сбоя региона

В этом разделе описывается, что ожидать, когда управляемые экземпляры SQL настроены для использования групп отработки отказа в нескольких регионах, и в основном регионе возникает сбой:

  • Обнаружение и ответ: Ответственность за обнаружение и ответ зависит от политики переключения на резервный узел, используемой вашей группой отработки отказов.

    • Политика аварийного переключения, управляемая клиентом: Вы ответственны за обнаружение сбоя в регионе и выполнение аварийного переключения или принудительного аварийного переключения на вторичный экземпляр в группе переключения.

      Если вы выполняете переключение на резервный экземпляр (отказоустойчивость), Управляемый экземпляр SQL ожидает синхронизацию данных с вторичным экземпляром перед выполнением этой процедуры.

      При отказе обеспечения доступности Управляемый экземпляр SQL немедленно переключает вторичный экземпляр на основную роль, не ожидая распространения последних изменений с первичной. Этот тип переключения при отказе может привести к потере данных.

    • Политика переключения на резерв, управляемая Microsoft: Переключение на резерв, управляемое Microsoft, выполняется в исключительных обстоятельствах. Когда Microsoft инициирует переключение на резерв, группа переключения на резерв автоматически выполняет принудительное переключение на вторичный экземпляр в этой группе. Однако мы рекомендуем использовать политику отработки отказа под управлением клиента для производственных рабочих нагрузок, чтобы вы могли контролировать, когда произойдёт процесс отработки отказа.

  • Активные запросы: При возникновении сбоя все обрабатываемые запросы завершаются и должны быть повторно отправлены. Чтобы сделать приложения устойчивыми к этим типам проблем, см. статью "Устойчивость к временным сбоям".

  • Ожидаемая потеря данных: Объем потери данных зависит от настройки приложения. Дополнительные сведения см. в разделе "Общие сведения о группах отработки отказа и лучшие практики".

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

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

Восстановление региона

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

Для управляемых клиентом групп отработки отказа можно инициировать возврат в основной регион после его восстановления. Для групп отказоустойчивости, управляемых корпорацией Майкрософт, процесс возвращения выполняется автоматически. Дополнительные сведения см. в разделе "Отказоустойчивое переключение обратно в основной регион".

Проверка сбоев в регионе

Вы можете проверить отработку отказа группы отказоустойчивости.

Тестирование группы аварийного переключения — это только одна часть проведения учений по аварийному восстановлению. Дополнительные сведения см. в разделе "Проведение учений по аварийному восстановлению".

Резервное копирование и восстановление

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

Управляемый экземпляр SQL автоматически выполняет полные, разностные и резервные копии журналов транзакций баз данных. Дополнительные сведения о типах резервных копий, их частоте, возможностях восстановления, затратах на хранение и шифровании резервных копий см. в разделе Automated backups in Управляемый экземпляр SQL.

Управляемый экземпляр SQL предоставляет встроенные автоматические резервные копии, а также поддерживает резервные копии, инициированные пользователем, для пользовательских баз данных. Дополнительные сведения см. в статье о резервных копиях только для копирования.

Репликация резервных копий

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

  • ZRS для обеспечения устойчивости в регионе, если регион имеет зоны доступности

  • GZRS для повышения устойчивости резервных копий между регионами, если регион имеет зоны доступности и связан с другим регионом.

  • GRS, если регион не поддерживает зоны доступности, но имеет парный регион

Дополнительные сведения о различных типах хранилища и их возможностях см. в разделе " Избыточность хранилища резервных копий".

Географическое восстановление

Возможность геовосстановления — это базовое решение аварийного восстановления, позволяющее восстановить резервные копии в другой регион #REF!. Георезервное копирование обычно требует значительного времени простоя и потери данных. Чтобы достичь более высокого уровня восстановления при возникновении региональных сбоев, вам следует настроить группы переключения при сбоях.

Если вы используете геовосстановление, необходимо рассмотреть вопрос о том, как сделать резервные копии доступными в дополнительном регионе:

  • Если ваш основной регион спарен, используйте резервное хранилище GZRS или GRS для поддержки геовосстановления в спаренном регионе.

  • Если основной регион не сопряжён, вы можете создать индивидуальное решение для репликации резервных копий в другой регион. Попробуйте использовать копии только для чтения, инициированные пользователем, и сохранить их в учетной записи хранения, которая использует репликацию BLOB-объектов для репликации в другой регион.

Устойчивость к обслуживанию служб

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

Управляемый экземпляр SQL позволяет указать период обслуживания, который обычно используется для обновлений служб и других операций обслуживания. Настройка интервала обслуживания может помочь свести к минимуму побочные эффекты, такие как автоматическое переключение на резервный сервер в течение рабочих часов. Вы также можете получать заранее уведомление о плановом обслуживании.

Дополнительные сведения см. в окне Maintenance в Управляемый экземпляр SQL.

Соглашение об уровне обслуживания

Соглашение об уровне обслуживания (SLA) для служб #REF! описывает ожидаемую доступность каждой службы и условия, которые должно соответствовать вашему решению для достижения этого ожидания доступности. Дополнительные сведения см. в разделе SLAs для онлайн-сервисов.

Для Управляемый экземпляр SQL соглашение об уровне обслуживания доступности применяется только при правильной настройке #REF! виртуальной сети, чтобы не препятствовать трафику управления. Эта конфигурация включает размер подсети, группы безопасности сети (NSG), определяемые пользователем маршруты (UDR), конфигурацию DNS и другие ресурсы, влияющие на управление и использование сетевых ресурсов. Дополнительные сведения о требуемой конфигурации сети для Управляемый экземпляр SQL см. в разделе Network requirements.

Связанный контент

  • Last updated on