Дисциплины хранилища для Управляемый экземпляр SQL с поддержкой Azure Arc

Хранилище — это критически важный компонент в развертывании Управляемый экземпляр SQL с поддержкой Azure Arc (Управляемый экземпляр SQL с поддержкой Arc). Понимание того, как описанные в этом документе концепции, связанные с хранилищем, влияют на работу кластеров Kubernetes, является важным аспектом выбора структуры хранилища и управления ими.

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

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

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

Архитектура

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

Рекомендации по проектированию

Ниже приведены рекомендации по проектированию и конфигурации хранилища.

Классы хранилищ

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

StorageClass, PersistentVolume (PV) и PersistentVolumeClaim (PVC) — это объекты ресурсов Kubernetes, которые система создает в кластере Kubernetes при подготовке компонентов служб данных с поддержкой Azure Arc.

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

Ресурсы Kubernetes PV и PVC настраиваются при подготовке контроллера данных Azure Arc и Управляемый экземпляр SQL с поддержкой Arc соответственно.

Существует два разных типа хранилищ:

• Местных: Том, подключенный к локальному запоминающее устройство, подключенное к узлу Kubernetes, где выполняется модуль pod. Этот тип хранилища обычно обеспечивает меньшую задержку, а также более высокую скорость ввода-вывода в секунду и пропускную способность по сравнению с удаленным или общим хранилищем.
• Удаленное/общее хранилище. Сетевые запоминающие устройства, которые, как правило, поставляются со встроенной избыточностью. Распространенные варианты хранения — это устройства NAS и SAN.

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

• Производительности: Пропускная способность ввода-вывода и операции ввода-вывода устройства хранения данных должны соответствовать потребностям вашей базы данных.
• Соотношение операций чтения и записи: Понимание рабочей нагрузки поможет вам выбрать резервное оборудование для оптимального удовлетворения ваших потребностей с соответствующими затратами. Большие рабочие нагрузки записи могут использовать конфигурации RAID 0, в то время как редко используемые данные лучше всего обслуживать с помощью хранилища устройств SAN.
• Изоляция базы данных и совместное размещение. Все базы данных в экземпляре Управляемый экземпляр SQL с поддержкой Arc совместно используют pv, поэтому вы можете переместить базы данных в отдельные экземпляры Управляемый экземпляр SQL с поддержкой Arc и избежать конфликтов ресурсов хранилища.
• Емкость: Определенный размер хранилища должен соответствовать будущей емкости контроллера данных и экземпляров базы данных, чтобы избежать необходимости изменять размер ПВХ. Учитывайте все ограничения хранилища, которые может иметь выбранный класс StorageClass.
• Режим доступа: Поставщики класса хранения имеют разные режимы доступа, поддерживая различные возможности подключения, чтения или записи хранилища модулями pod. Для тома резервного копирования SQL требуется RWX (read Write Many).
• Избыточности: Репликация данных на физическом уровне хранилища (RAID) для поддержки простой отработки отказа в случае сбоя аппаратного диска, которая отделена от избыточности на уровне базы данных, выполняемой группами доступности (AG).

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

Контроллер данных

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

Контроллер данных Azure Arc будет иметь четыре разных модуля pod с отслеживанием состояния, запущенные в кластере Kubernetes: SQL контроллера, API контроллера, База данных журналов и База данных метрик. Для каждого модуля pod требуется два постоянных тома для томов данных и журналов. Для обеспечения устойчивости данных всем компонентам контроллера данных требуется удаленный класс StorageClass, так как сами компоненты контроллера данных не обеспечивают устойчивость данных в собственном коде.

Обязательно учитывайте вычислительные ресурсы и ресурсы памяти , необходимые контроллеру данных Azure Arc. На следующей схеме представлены ресурсы Kubernetes хранилища контроллера данных, PV и PVC.

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

Подготовка контроллера данных

При подготовке контроллера данных Azure Arc настройте StorageClass и емкость хранилища для журналов и данных. Затем настройка хранилища для журналов и данных применяется ко всем восьми PV, создаваемым для модулей pod контроллера данных. Во время подготовки можно указать пользовательский шаблон развертывания , который переопределяет параметры по умолчанию, такие как емкость, хранение журналов и элементы, связанные с безопасностью, такие как типы служб Kubernetes. После завершения подготовки создаются объекты Kubernetes PV и PVC.

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

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

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

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

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

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

Постоянный том	Описание	Требования к классу хранения
Данные	База данных SQL файлов данных (MDF-файлы)	Зависит от уровня
Журналы данных	База данных SQL файлы журнала (LDF-файлы)	Зависит от уровня
Журналы	Агент SQL, журналы ошибок, файлы трассировки, журналы работоспособности	Зависит от уровня
Резервные копии	SQL Server файлы резервной копии, включая полный, diff и журнал транзакций	Remote, ReadWriteMany Access Mode

Уровень служб общего назначения

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

Уровень служб "Критически важный для бизнеса"

критически важный для бизнеса уровне использует модель с несколькими модулями pod, где тома данных и журналов могут храниться в локальных или удаленных классах хранения. Локальные классы хранения обычно работают лучше с точки зрения задержки и пропускной способности, так как запоминающее устройство подключено непосредственно к узлу. Удаленное хранилище обычно обеспечивает встроенную избыточность, но часто имеет меньшую задержку и пропускную способность по сравнению с локальным хранилищем. Имейте в виду, что для использования дополнительных критически важный для бизнеса реплик базы данных требуются дополнительные постоянные тома для данных, журналов и журналов данных. Требуемый общий объем хранилища значительно выше.

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

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

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

Подготовка и удаление azure Arc Управляемый экземпляр SQL

При подготовке Управляемый экземпляр SQL с поддержкой Arc вы можете назначать разные классы хранения каждому из необходимых постоянных томов Управляемый экземпляр SQL с поддержкой Arc. Возможно, вам нужны варианты хранения данных ижурналов данных с более высокой производительностью, но тома журналов и резервных копий могут использовать более экономичные варианты StorageClass для экономии затрат. В сценариях, где используется локальное хранилище, убедитесь, что тома могут помещать на разные узлы и физические запоминающие устройства, чтобы избежать конфликтов при дисковом вводе-выводе. Размещение данных и журналов данных на одном физическом диске может привести к состязанию за этот диск, что приведет к снижению производительности. Вместо этого рекомендуется разместить Данные и Журналы данных на разных дисках хранилища, чтобы распараллеливать операции ввода-вывода как для данных базы данных, так и для журналов.

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

Рекомендации по проектированию

Ниже приведены рекомендации по проектированию и конфигурации хранилища.

Классы хранения для рабочих нагрузок

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

Поставщик	Проверенное и рекомендуемое хранилище
Служба Azure Kubernetes (AKS)	Azure Управляемые диски (уровень "Премиум")
Amazon Elastic Kubernetes Service (EKS)	Драйвер хранилища CSI EBS
Google (GKE)	Постоянные диски GCE

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

Проектирование контроллера данных

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

Мы рекомендуем использовать настраиваемый шаблон развертывания при создании контроллера данных служб данных с поддержкой Arc. Настраиваемый шаблон позволяет точно настраивать классы хранения, размер хранилища для данных и журналов, безопасность и типы служб Kubernetes. Вы можете настроить их в соответствии со своей средой и корпоративными потребностями. Для контроллера данных Azure Arc требуется в общей сложности восемь постоянных томов. Минимальная конфигурация по умолчанию позволяет использовать 15Gi для данных и 10Gi для журналов на PV. Настройте емкость, которая не только соответствует минимальным рекомендациям, но и поддерживает более высокий рост, если в кластере выполняется множество реализаций Управляемый экземпляр SQL с поддержкой Arc. Такая конфигурация позволит избежать необходимости изменения размера ПВМ в будущем.

Мы рекомендуем выбрать класс StorageClass с меньшей задержкой, если в кластере есть много баз данных и Управляемый экземпляр SQL развертываний с поддержкой Arc. Меньшая задержка улучшает взаимодействие с пользователем в интерфейсах Grafana и Kibana.

Миграция Управляемый экземпляр SQL с поддержкой Azure Arc

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

В зависимости от организации кластера Kubernetes подготовьте развертывания с поддержкой Arc Управляемый экземпляр SQL в разных кластерах Kubernetes в зависимости от необходимости разделения сред (не prod, prod), регионов и других бизнес-факторов. Дополнительные рекомендации см. в разделе Разработка организации ресурсов . При настройке нескольких экземпляров базы данных в кластере не забудьте разделить занятые базы данных на собственные экземпляры, чтобы избежать конфликтов ввода-вывода.

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

Запланируйте емкость для Управляемый экземпляр SQL с поддержкой Arc, чтобы включить достаточные размеры хранилища для данных, журналов, журналов данных и резервных копий. При планировании емкости в соответствии с текущими потребностями и прогнозируемым ростом для всех баз данных, которые будут работать на экземплярах Управляемый экземпляр SQL с поддержкой Arc, это предотвращает необходимость изменять размер ПВМ в будущем. Выберите отдельные физические диски для Data и DataLogs , чтобы разрешить выполнение параллельных операций ввода-вывода. Параллельное действие ввода-вывода приводит к повышению производительности, избегая возможного состязания, вызванного при использовании общего диска.

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

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

общего назначения рекомендации по уровню служб

Для оптимальной производительности рекомендуется выбрать удаленный класс хранения данных с низкой задержкой для постоянных томов Data и DataLogs . Избегайте использования класса StorageClass, который содержит сетевые секции, например локальный кластер, настроенный для использования доступного через Интернет класса StorageClass для резервных томов и постоянных томов журналов.

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

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

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

Для рабочих нагрузок с интенсивным чтением и высокой доступности настройте несколько реплик и настройте приложения или клиенты для использования вторичных реплик в качестве экземпляров Scale-Out чтения. Вторичные реплики по умолчанию недоступны для чтения; этот параметр можно настроить.

Мониторинг

Рекомендуется отслеживать все ПВС, созданные службами данных с поддержкой Arc, включая контроллер данных Azure Arc и все экземпляры Управляемый экземпляр SQL с поддержкой Arc в кластере. Настройте оповещения, чтобы уведомлять вас, когда ПВХ приближается к емкости. Уведомление позволяет изменить размер ПВХ до достижения емкости. Для кластеров с прямым подключением мониторинг pvcs и оповещений выполняется с помощью Azure Monitor и Аналитики контейнеров. При использовании непрямых подключенных кластеров выполните мониторинг и оповещение в Grafana и Kibana. Установка Grafana включает панели мониторинга для Управляемый экземпляр SQL метрик и ресурсов Kubernetes с поддержкой Arc.

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

Дальнейшие действия

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

• Просмотрите конфигурацию хранилища для служб данных с поддержкой Azure Arc.
• Просмотрите проверенные дистрибутивы Kubernetes для служб данных с поддержкой Azure Arc.
• Ознакомьтесь с рекомендациями по выбору размера для служб данных с поддержкой Azure Arc.
• Ознакомьтесь с мониторингом с помощью Grafana и Kibana Управляемый экземпляр SQL с поддержкой Arc.
• Использование с поддержкой Arc Управляемый экземпляр SQL автоматизированных сценариев с помощью Azure Arc Jumpstart.
• Дополнительные сведения об Azure Arc см. в схеме обучения Azure Arc в Microsoft Learn.