Дисциплины хранилища для Управляемый экземпляр 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.