#Планирование вашего развертывания

В этой теме представлен контрольный список для планирования развертывания распределённого хранилища Ceph на платформе Alauda Container Platform (ACP). В ней суммируются архитектурные решения, варианты безопасности, размеры инфраструктуры, сетевые ограничения и вопросы аварийного восстановления, чтобы вы могли выбрать модель развертывания до начала фактической установки.

Для ознакомления с продуктом смотрите Introduction и Architecture. Для процедур развертывания смотрите документы в разделах Install и How To.

#Архитектура развертывания

Распределённое хранилище ACP основано на Ceph и Rook. В общих чертах платформа объединяет следующие уровни:

• Демоны Ceph, такие как MON, MGR, OSD, MDS и RGW, обеспечивающие возможности блочного, файлового и объектного хранения
• Компоненты Rook и CSI для автоматизации развертывания, предоставления ресурсов, масштабирования и управления жизненным циклом
• Интеграция с платформой ACP для предоставления пулов хранения, наблюдаемости и точек входа в операции

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

#Внутренние и внешние модели развертывания

Вы можете спланировать распределённое хранилище ACP одним из следующих способов:

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

Основные точки принятия решения:

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

#Роли узлов

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

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

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

#Вопросы безопасности

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

#Шифрование трафика в пути

ACP в настоящее время поддерживает шифрование трафика в пути для распределённого хранилища Ceph. Эта функция защищает трафик между компонентами Ceph и клиентами и обычно планируется с учётом Ceph msgr2 и модели сетевого кластера.

Перед включением шифрования трафика в пути проверьте:

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

Для деталей реализации смотрите Configure in-transit encryption.

#Требования к инфраструктуре

#Минимальная и рекомендуемая конфигурация

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

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

#Размер ресурсов

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

В качестве базового ориентира:

• Начинайте с минимум трёх узлов хранения для высокодоступного кластера
• Резервируйте CPU и память для MON, MGR, OSD и любых включённых MDS или RGW сервисов
• Оставляйте запас для новых пулов, дополнительных устройств и событий восстановления кластера
• Избегайте планирования кластера, который уже на старте близок к насыщению ресурсов

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

#Общий бюджет планирования кластера

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

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

Следующие рекомендации подходят для раннего планирования:

Эти значения — ориентиры планирования, а не жёсткие гарантии планирования. Фактические требования зависят от количества устройств, включённых сервисов и интенсивности нагрузки.

#Как оценить размер кластера

Используйте следующий порядок при оценке размера кластера:

1. Выберите модель развертывания: совместное, выделенные узлы или внешнее.
2. Определите минимальное количество узлов и расположение доменов отказа.
3. Решите, нужны ли блочные, файловые, объектные или смешанные сервисы хранения.
4. Начните с общего бюджета планирования кластера.
5. Добавьте запас для дополнительных наборов устройств, восстановления, мониторинга и ожидаемого роста.

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

#Размещение Pod

Правила размещения Pod напрямую влияют на отказоустойчивость. Планируйте кластер так, чтобы:

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

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

#Планирование устройств хранения

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

Используйте следующие принципы:

• Резервируйте один системный диск для ОС и отдельные устройства для данных Ceph
• Предпочитайте raw-диски или выделенные устройства вместо разделения общих дисков
• Держите количество устройств на узел на управляемом уровне, чтобы восстановление и обслуживание оставались практичными
• Отслеживайте используемую ёмкость, а не сырую, так как репликация уменьшает эффективное пространство хранения

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

Для связанной операционной информации смотрите Managing Storage Pools и Adding Devices/Device Classes.

#Планирование ёмкости

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

Используйте следующие принципы планирования:

• Держите доступную ёмкость выше ожидаемого роста бизнеса, а не расширяйте только после почти полного заполнения кластера
• Резервируйте дополнительный запас для восстановления, ребалансировки, снимков и временных всплесков использования данных
• Расширяйте хранилище сбалансированно по узлам и доменам отказа, чтобы новая ёмкость не создавала перекос в использовании
• Анализируйте текущую загрузку и прогнозируемый рост перед добавлением новых нагрузок в кластер

Следующие примеры можно использовать как ориентиры раннего планирования для трёхузлового кластера с одним устройством на узел и политикой защиты данных с 3 репликами:

Эти значения приведены только как примеры. Используемая ёмкость зависит от фактической политики защиты данных и не должна рассматриваться как универсальное правило для всех дизайнов кластера.

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

#Сетевые требования

Ceph чувствителен к качеству сети. Перед развертыванием проверьте:

• Сеть кластера обеспечивает стабильную пропускную способность для трафика репликации и восстановления
• Задержка между доменами отказа находится в поддерживаемом диапазоне для выбранной модели развертывания
• Необходимые порты открыты между узлами хранения и потребляющими кластерами
• Любая выделенная сетевая архитектура, например разделение на основе Multus, согласована заранее

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

#Поддержка IPv6

Планирование распределённого хранилища ACP должно соответствовать выбранному стеку сети кластера платформы.

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

Если в вашем окружении используется IPv6, подтвердите перед установкой:

• Сеть кластера ACP уже настроена для работы с IPv6
• Все узлы хранения могут общаться по необходимым IPv6 маршрутам
• Мониторинг, оповещения и внешние интеграции, обращающиеся к конечным точкам хранения, также поддерживают IPv6

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

#Планирование аварийного восстановления

Распределённое хранилище ACP можно планировать с разными целями восстановления. Выберите модель на основе ваших целей по точке восстановления (RPO), времени восстановления (RTO) и топологии площадок.

#Regional-DR

ACP поддерживает Regional-DR для сценариев аварийного восстановления между регионами или площадками, где допустима асинхронная репликация и небольшой объём потенциальной потери данных.

При планировании Regional-DR заранее подтвердите:

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

Для деталей реализации смотрите Disaster Recovery.

#Stretch Cluster

Stretch cluster подходит только при строго контролируемой задержке между площадками и специально спроектированной топологии для этого сценария. В общем случае планируйте:

• Две площадки с данными и одну площадку с кворумом или арбитром
• Минимум пять узлов в трёх зонах
• Ручное и явное назначение меток доменов отказа до создания кластера
• Достаточное количество узлов на каждой площадке с данными для сохранения доступности сервисов хранения
• Межзонная задержка в пределах низколатентного дизайна, обычно не более 10 мс RTT между площадками с данными

Для рекомендаций по развертыванию stretch cluster в ACP смотрите Create Stretch Type Cluster.

#Планирование производительности

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

• Основной тип нагрузки: блочная, файловая или объектная
• Чувствительность нагрузки к задержкам, пропускной способности или объёму
• Будут ли в кластере доминировать горячие данные, резервное копирование или аналитические задачи

Также подтвердите, требуется ли специальная настройка или дизайн с учётом особенностей. Например, объектные нагрузки могут требовать отдельного планирования ёмкости шлюзов, а некоторые окружения — кэш-ориентированные или выделенные кластеры.

#Следующие шаги

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

#Внутреннее развертывание

• Для совместного развертывания смотрите Create Standard Type Cluster.
• Для stretch cluster смотрите Create Stretch Type Cluster.
• Для развертывания с выделенными узлами смотрите Configure a Dedicated Cluster for Distributed Storage.

#Внешнее развертывание

• Для потребления сервисов хранения из другого кластера или внешней среды Ceph смотрите Accessing Storage Services.

#Связанные последующие настройки

• Для включения шифрования сетевого трафика для развернутых сервисов хранения смотрите Configure in-transit encryption.
• Для настройки аварийного восстановления после развертывания смотрите Disaster Recovery.