Рекомендации по архитектуре управляемого экземпляра SQL Azure

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Создайте базовые показатели безопасности: Начните с базового плана безопасности Azure для SQL Azure. Сосредоточьтесь на элементах управления, на которые модель на уровне экземпляров оказывает наибольшее влияние, включая пользовательские роли уровня сервера для административной сегментации, делегирование ролей в подсети виртуальной сети для сетевой изоляции, управление ключами прозрачного шифрования данных (TDE) на уровне экземпляра и аудит операторов для контроля доступа сотрудников поддержки Microsoft.

Управляемый экземпляр SQL разделяет фундамент безопасности SQL Azure, но вводит элементы управления, специфичные для экземпляра, такие как сборки Common Language Runtime (CLR), связанные серверы и агент SQL, которые расширяют поверхность атаки за пределы того, что предоставляет база данных SQL. Определите приоритеты этих элементов управления в базовой проверке.

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

Сегментация на уровне сети зависит от развертывания экземпляров в выделенных делегированных подсетях, где группы безопасности сети (NSG) управляют потоками трафика. Избегайте повторного использования таблиц маршрутов и NSG в подсетях, участвующих в виртуальном сетевом пиринге с подсетями Управляемого экземпляра SQL.

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

Интеграция с идентификатором Microsoft Entra для управления удостоверениями и доступом: Управляемый экземпляр SQL поддерживает проверку подлинности Microsoft Entra с помощью нескольких методов. Эта поддержка поддерживает централизованное управление удостоверениями и поддерживает политики условного доступа. Управляемый экземпляр SQL также поддерживает проверку подлинности Windows через Kerberos для принципалов Microsoft Entra, что является возможностью, недоступной в базе данных SQL. Устаревшие приложения можно поднять и переместить без изменений кода.

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

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

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

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

• Назначьте уникальные таблицы маршрутов и группы безопасности сети каждой подсети SQL Managed Instance для пиринга виртуальной сети. Повторное использование общих таблиц вызывает сбои подключения.

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

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

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

• Агент SQL, связанные серверы, сборки CLR и xp_cmdshell требуют оценки рисков. Деактивируйте неиспользуемые возможности и применяйте текущие стандарты TLS.

• Используйте управление доступом на основе ролей Azure (Azure RBAC) для ограничения операций управления, применения блокировок ресурсов и принудительного применения конфигураций безопасности с помощью политики Azure.

Защита учетных данных и ключей шифрования с помощью управляемых удостоверений и Azure Key Vault: Управляемые удостоверения устраняют сохраненные учетные данные для подключения между приложениями и интеграции между службами. Назначенные пользователем управляемые удостоверения удаляют секреты подключения и упрощают управление ротацией.

Key Vault предоставляет единое управление жизненным циклом для защиты TDE и главных ключей столбцов Always Encrypted. Мониторинг доступа к ключам обнаруживает необычные шаблоны использования, которые могут указывать на компромисс.

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

Настройте мониторинг безопасности и ведение журнала аудита: Аудит Управляемого экземпляра SQL поддерживает хранилище BLOB Azure, Центры событий Azure и журналы Azure Monitor в качестве целевых объектов аудита. Аудит операторов обеспечивает видимость операций поддержки Майкрософт в экземпляре. Для обеспечения соответствия требованиям требуется проверка целостности журнала аудита.

Интеграция Log Analytics поддерживает расширенные запросы и корреляцию событий безопасности, а центры событий поддерживают интеграцию внешней информации безопасности и управления событиями (SIEM). Microsoft Defender для SQL добавляет защиту от угроз, включая оповещения о внедрении, атаки методом перебора и необычные шаблоны доступа.

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

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

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

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

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

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

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

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

Оптимизируйте затраты на среду в рабочих и тестовых экземплярах: Идентичные производственные и тестовые конфигурации ведут к растрате бюджета в модели постоянного резервирования. Различайте профили затрат SQL Managed Instance, применяя механизмы экономии, специфичные для каждого уровня.

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

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

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

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

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

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

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

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

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

• Координируйте изменения развертывания группы отработки отказа, обеспечивая соответствие экземпляров политикам обновления. Запланируйте изменения первичных и вторичных экземпляров в разное время.

Определите инфраструктуру как код для развертываний экземпляров, интегрированных с виртуальной сетью: Для управляемого экземпляра SQL требуется развертывание, интегрированное с виртуальной сетью, с делегированием подсети, правилами NSG и таблицами маршрутов перед подготовкой. Структурируйте инфраструктуру в виде шаблонов кода (IaC) на уровнях зависимостей, чтобы сеть развертывается первой, удостоверения и RBAC развертываются вторыми, а ресурсы экземпляров развертываются последними.

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

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

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

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

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

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

Автоматизация задач управления, мониторинга и обслуживания: Управляемый экземпляр SQL включает агент SQL, встроенный планировщик заданий, который обрабатывает обслуживание базы данных и операционные задачи без внешней оркестрации. Объединение агента SQL с автоматизацией на уровне Azure для полного охвата операций ядра СУБД и плоскостей управления.

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

• Используйте службу автоматизации Azure или Функции Azure для операций, требующих взаимодействия Azure Resource Manager, таких как мониторинг операций управления и управление хранением резервных копий.

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

Установите методики тестирования и проверки для развертываний баз данных: Совместимость SQL Managed Instance SQL Server поддерживает стандартные средства тестирования, но вам по-прежнему необходимо проверить операции управления, межбазовые зависимости и функции, связанные с экземплярами. Используйте фактические тестовые среды управляемого экземпляра SQL, так как база данных SQL и SQL Server имеют разные функции инфраструктуры и управления.

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

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

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

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

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

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

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

• Используйте гибкую память в Next-gen General Purpose для настройки выделения памяти независимо от количества виртуальных ядер. Изменения активируют переключение экземпляра как заключительный этап.

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

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

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

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

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

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

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

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