При планировании репликации, аварийного восстановления и резервного копирования, а также восстановления данных мы выбираем из нескольких стратегий — в зависимости от требований к уровню SLA по восстановлению данных и приложений. Ключевые факторы при выборе включают в себя целевое время восстановления (RTO) и целевая точка восстановления (RPO). Синхронная репликация дает минимальную RPO, что означает невозможность потери данных. Ceph может реализовать синхронную репликацию между локациями, «растянув» свой кластер на несколько дата-центров.
Асинхронная репликация по своей сути подразумевает ненулевое значение RPO. В Ceph асинхронная multi-site репликация подразумевает репликацию данных в другой кластер Ceph. Каждый метод доступа к хранилищу (объект, блок и файл) обладает собственным методом асинхронной репликации, реализованным на уровне конкретного компонента Ceph.
Асинхронная репликация: репликация происходит на уровне сервиса (компонента Ceph) (RBD, CephFS или RGW), как правило, в полностью независимых кластерах Ceph.
Синхронная репликация («Растянутый кластер»): репликация выполняется на уровне RADOS (уровне кластера Ceph), поэтому необходимо сделать запись в каждую локацию до отправки подтверждения клиентам.
Оба метода обладают определенными преимуществами и недостатками, так же как и разные профили производительности и требования к восстановлению. Прежде чем подробно обсуждать «растянутые» кластеры Ceph, посмотрим обзор этих режимов.
Варианты репликации в Ceph
Асинхронная репликация
Асинхронная репликация осуществляется на уровне сервиса. Каждый сайт предоставляет полный, автономный кластер Ceph и поддерживает независимые копии данных.
RGW Multisite: каждый сайт разворачивает одну или несколько независимых зон RGW. Изменения асинхронно распространяются между сайтами через фреймворк multisite репликации RGW. Эта репликация не основана на журнале. Вместо этого она полагается на лог операций, где каждый RGW отслеживает изменения. Они воспроизводятся на всех инстансах RGW для репликации данных.
RBD Mirroring: блочные данные зеркалируются либо с использованием подхода, основанного на журналах (как в OpenStack), либо на основе снэпшотов (как в ODF/OCP) — в зависимости от ваших требований к производительности, согласованности при сбоях и расписания.
CephFS Snapshot Mirroring (в стадии активной разработки): использует снэпшоты для репликации файловых данных с настраиваемыми интервалами.
Асинхронная репликация особенно подходит для архитектур со значительной сетевой задержкой между локациями. Такой подход позволяет приложениям продолжать работу, не дожидаясь завершения удаленной записи. Однако важно отметить, что стратегия подразумевает ненулевую RPO — это значит, что произойдет некоторая задержка, прежде чем данные в удаленных локациях станут согласованными с локацией первой записи. В результате, сбой в одной локации может привести к потере недавно записанных данных, которые еще не были реплицированы.
Чтобы подробнее исследовать асинхронную репликацию Ceph, вы можете прочесть эту статью.
Синхронная репликация: «растянутый» кластер
«Растянутый» кластер — единый кластер Ceph, развернутый в нескольких дата-центрах или зонах доступности. Операции записи возвращают подтверждения клиентам только после сохранения на всех сайтах или на достаточном их количестве, чтобы удовлетворить требования схемы репликации каждого логического пула. Это обеспечивает:
RPO = 0: Отсутствие потери данных при сбое на одном сайте, поскольку каждая запись клиента реплицируется синхронно и повторится, когда упавший сайт снова подключится к сети.
Управление единым кластером: на стороне клиента не требуется специальной настройки репликации — применяются обычные инструменты и рабочие процессы Ceph.
К распределенному кластеру предъявляются строгие требования сети: максимальный RTT <= 10 мс между локациями. Задержка здесь обладает критическим значением — запись в OSD (Object Storage Daemon) должна передаваться между локациями до того, как клиенту вернется подтверждение. Нестабильность сети, недостаточная пропускная способность и резкие задержки могут снизить производительность и поставить под угрозу целостность данных.
«Растянутый» кластер Ceph
Вступление
«Растянутые» кластеры Ceph предоставляют преимущества, которые позволяют считать их хорошим выбором для критически важных приложений, где необходимы высокая отказоустойчивость и надежность:
отказоустойчивость: «растянутый» кластер справится с отказом всего сайта без влияния на операции клиентов. Он может выдержать двойной сбой сайта без потери данных (прим. редактора - тут все конечно же зависит от того, сколько у вас сайтов, если все два - ¯\_(ツ)_/¯);
высокая согласованность: при конфигурации трех сайтов данные, загруженные онлайн, моментально становятся видимыми для всех зон доступности. Высокая согласованность позволяет клиентам на каждом сайте всегда видеть последнюю версию данных;
простота настройки эксплуатации: одна из лучших фич растянутого кластера — простота в эксплуатации. Он во многом похож на любой стандартный кластер в одной локации. Кроме того, для восстановления после сбоя не требуется ручного вмешательства — упрощается управление и деплой;
«растянутые» кластеры могут дополняться многосайтовой асинхронной репликацией для репликации данных между регионами.
Однако важно учитывать предостережения, связанные с «растянутыми» кластерами Ceph:
решающее значение имеет сеть, где есть недостатки: нестабильное состояние, резкие задержки и недостаточная пропускная способность влияют на производительность и целостность данных;
производительность: задержка операций записи увеличивается из-за RTT двух наиболее удаленных локаций. При деплое на трех площадках размер пула должна быть настроен с коэффициентом репликации 6, что приводит к увеличению записи: каждое клиентское изменение вызывает шесть операций на OSD. Нам необходимо соответствующим образом скорректировать ожидания по нагрузке. Например, при хранении данных в растянутом кластере нагрузка на базу данных OLTP с высоким IOPS (Input/Output Operations Per Second) и низкой задержкой, вероятно, будет затруднена;
для обеспечения надежности рекомендуется использовать репликацию 6 (или репликацию 4 в двухсайтовом растянутом кластере): мы храним шесть (или четыре) копий данных. Сейчас использование Erasure Coding невозможно из-за влияния на производительность, высокой нагрузки на сеть между локациями и нюансов обеспечения одновременной сильной согласованности и высокой доступности. Это означает, что общая доступная полезная емкость при заданном объеме физического хранилища должна быть тщательно рассчитана — по сравнению с традиционным одним кластером;
единый кластер для всех сайтов: если данные окажутся повреждены из-за сбоя ПО или действий пользователя в одной из локаций, это затронет всю систему — изменения отразятся на всех остальных площадках кластера.
Сетевое взаимодействие: основа растянутого кластера
Оптимальная работа растянутого кластера зависит от надежной сети. Ее неоптимальная конфигурация влияет на производительность и целостность данных.
Равная задержка между площадками: площадки связаны высокодоступной сетевой инфраструктурой уровня L2 или L3, где задержка между зонами доступности данных/площадками примерно одинакова. В идеале RTT составляет менее 10 мс. Нестабильная задержка сети (джиттер) ухудшит производительность кластера.
Надежная сеть L2/L3 с минимальными скачками времени ожидания: разнесение каналов между узлами с избыточностью — полносвязная топология или резервный транзит.
Достаточная пропускная способность: сеть должна обладать достаточной пропускной способностью для обработки трафика репликации, запросов клиентов и восстановления. Пропускная способность должна масштабироваться вместе с ростом кластера: с добавлением узлов ее необходимо увеличивать между узлами для поддержания производительности.
QoS (Quality of Service) способен помочь: без QoS «шумный сосед», создающий значительный трафик между узлами, может ухудшить стабильность кластера.
Глобальный балансировщик нагрузки: объектному хранилищу, использующему S3 требуется балансировщик, способный перенаправлять запросы клиентов в другие локации в случай сбоя своей.
Производительность: при каждой записи клиента задержка между сайтами будет примерно такой же, как при максимальном RTT. На диаграмме ниже показана задержка в растянутом кластере из трех узлов с интервалом в 1,5 мс между ними, когда клиент и основное экранное меню находятся на разных узлах:
«Растянутый» кластер из трех локаций
В каждом дата-центре (или зоне доступности) размещается часть OSD в «растянутом» кластере с тремя узлами. В каждой зоне хранятся две копии данных, поэтому параметр общего пула — размер 6. Это позволяет кластеру обслуживать операции клиентов без простоев и потери данных даже при отключении. Основные моменты:
отсутствие Tie-breaker: благодаря трем полноценным локациям (OSD на всех площадках), мониторы могут формировать кворум с любыми двумя локациями, с которыми есть связность;
повышенная устойчивость: выдерживает полный сбой локации плюс один дополнительный сбой OSD или узла на оставшихся площадках;
требования к сети: рекомендуется использовать маршрутизацию уровня L3 и учитывать, что RTT между тремя сайтами не должно превышать 10 мс.
«Растянутый» кластер в двух локациях и Tie-breaker
Для конфигураций, где связность только между двумя дата-центрами обладает низкой задержкой, OSD стоит размещать в эти два дата-центра, а в третий — поместить только монитор, который будет выполнять функцию tie-breaker’а. Это может быть даже виртуальная машина облачного провайдера. Это гарантирует, что кластер сохранит кворум в случае сбоя в одной из локаций.
Два основных сайта с низкой задержкой: на каждом из них размещена половина общей емкости OSD.
Один tie-breaker: на сайте размещен монитор tie-breaker.
Реплики: стратегия репликации пула данных с параметром size=4 — две реплики на дата-центр.
Задержка: составляет не более 10 мс RTT между дата-центрами с OSD. Tie-breaker-сайт может выдерживать гораздо большую задержку (например, 100 мс).
Улучшенная обработка сетевых разделений (netsplit): предотвращает split-brain-сценарии.
Требуются SSD OSDs: HDD OSDs не поддерживаются.
Выводы
Ceph поддерживает как асинхронные, так и синхронные стратегии репликации — у каждой свои особенности с точки зрения целей восстановления, сложности эксплуатации и требований к сети. Асинхронная репликация (RBD Mirroring, RGW Multisite и CephFS Snapshot Mirroring) обеспечивает гибкость и простоту развертывания гео-распределенных окружений, но обеспечивает ненулевой RPO. В отличие от этого, «растянутый» кластер обеспечивает нулевой RPO за счет синхронной записи в нескольких дата-центрах — данные не теряются, однако для этого требуется устойчивое межсайтовое подключение с низкой задержкой, а также следует учитывать увеличение накладных расходов на репликацию, включая рост задержек операций.
«Растянутый» кластер Ceph способен выдержать отказ целого дата-центра практически без ручного вмешательства — независимо от того, выбираете ли вы деплой двух или трех локацией по единой схеме. Но критически важно учитывать более строгие сетевые требования: как к задержке, так и к пропускной способности. Кроме того, при репликации с коэффициентом size=4 увеличиваются требования по емкости кластера. Для критически важных приложений, где важны непрерывная доступность и нулевое RPO, дополнительное планирование и ресурсы для растянутого кластера могут оказаться оправданными. Если допустимо небольшое, но ненулевое значение RPO — скажем, если один дата-центр предназначен только для архивирования или для аварийного восстановления с пониженной производительностью — асинхронная репликация может быть хорошим вариантом. В этом случае на обеих площадках можно использовать Erasure Coding.
В нашей следующей статье (часть 2 этой серии) мы рассмотрим кластеры, живущие в двух локациях с третьей, в которой только tie-breaker взаимосвязь. Расскажем о шагах настройки Ceph в нескольких дата-центрах, обсудим основные сетевые и аппаратные аспекты. Кроме того, добавим практику — покажем, как автоматизировать загрузку кластера с помощью spec-файла. Мы также расскажем, как настроить CRUSH-правила и включить режим stretch.
Авторы благодарят IBM за поддержку сообщества и за то, что они уделили время созданию этих публикаций.