Для получения дополнительных галантерейных товаров, пожалуйста, обратите внимание на публичный аккаунт WeChat «AI Frontline» (ID: ai-front)
Планированию аварийного восстановления, а в идеале — планированию предотвращения аварий, нельзя придавать особого значения, и еженедельные заголовки подтверждают этот вывод. Независимо от отрасли, если непредвиденное событие влияет на повседневную работу, организациям необходимо как можно быстрее вернуться к работе, чтобы продолжать обслуживать своих клиентов. От нарушений безопасности данных до стихийных бедствий необходимо иметь планирование для быстрого и гибкого реагирования на катастрофические события. Отсутствие эффективного плана аварийного восстановления может подвергнуть организацию целому ряду рисков, таких как значительные финансовые потери, ущерб репутации и даже более серьезные риски для клиентов и пользователей организации.
В многогранной корпоративной программной системе стратегии предотвращения аварий и планирования восстановления необходимо развертывать в нескольких географически разнесенных центрах обработки данных. В таких развертываниях с несколькими центрами обработки данных часто используются механизмы георепликации для обеспечения дополнительной избыточности на случай, если сбой центра обработки данных или другое событие помешают нормальной работе.
В этом и следующем выпуске будет представлена еще одна функция корпоративного уровня, поставляемая с Apache Pulsar: георепликация. Apache Pulsar использует Apache BookKeeper, масштабируемый механизм хранения потоковой передачи, систему обмена сообщениями, которая поддерживает как синхронную георепликацию (с помощью Apache BookKeeper), так и асинхронную георепликацию (посредством конфигурации на уровне брокера) в нескольких центрах обработки данных. В первой статье будут представлены некоторые простые концепции и функции, а следующая статья будет посвящена конкретным методам развертывания.
Георепликация — типичный механизм аварийного восстановления. Хотя многие системы данных заявляют о поддержке георепликации, эти системы обычно реплицируются только в два центра обработки данных, и часто возникают ограничения при репликации в большее количество местоположений. Это может сбивать пользователей с толку, и это не слишком громоздкий способ репликации в нескольких центрах обработки данных. Прежде чем представить функцию географической репликации Apache Pulsar, ниже будут представлены некоторые основные понятия о географической репликации.
Механизмы георепликации, используемые многими системами данных, можно в основном разделить на две категории: синхронная георепликация и асинхронная георепликация. Apache Pulsar поддерживает оба типа. На рисунке 1 ниже показаны различия между синхронной и асинхронной георепликацией.
В этом примере предполагается наличие 3 центров обработки данных: us-west, us-central и us-east, и клиенты отправляют запросы на запись в us-central. При синхронной георепликации после того, как клиент делает запрос к us-central, данные, записанные в us-central, реплицируются в два других центра обработки данных: us-west и us-east. Обычно клиенты получают подтверждение запроса на запись только после того, как большинство центров обработки данных подтвердят успешное завершение операции записи. То есть в этом примере требуется как минимум два центра обработки данных, чтобы подтвердить успешное выполнение запроса на запись. Этот механизм также называется «синхронной георепликацией», поскольку данные синхронно реплицируются в несколько центров обработки данных, и клиенты должны ждать подтверждения от других центров обработки данных.
Рис. 1. Синхронная георепликация и асинхронная георепликация
Напротив, при асинхронной георепликации клиенту не нужно ждать ответа от других центров обработки данных, и клиент получит ответ сразу после того, как us-central успешно завершит операцию записи. Затем данные реплицируются из us-central в два других центра обработки данных: us-west и us-east, но асинхронно.
Синхронная георепликация обеспечивает высочайшую доступность, когда все доступные физические центры обработки данных будут предоставлять глобальный логический экземпляр системы данных. Приложения могут работать в любом центре обработки данных и получать доступ к этим данным в любое время. Эта модель также обеспечивает более высокую согласованность данных в разных центрах обработки данных, гарантируя, что приложения будут продолжать работать без каких-либо ручных действий в случае сбоя одного центра обработки данных. Однако приложения страдают от дополнительной задержки между центрами обработки данных, обычно порядка десятков миллисекунд для такой связи между восточным и западным побережьями Соединенных Штатов.
Асинхронная георепликация имеет меньшую задержку, поскольку клиентам не нужно ждать ответов от других центров обработки данных. Однако этот режим обеспечивает слабые гарантии согласованности, поскольку репликация в конце концов является асинхронной. Поскольку асинхронная репликация всегда имеет задержку репликации (задержка репликации обычно означает, что данные еще не были реплицированы из источника в цель), всегда есть данные, которые не были полностью реплицированы из источника в цель. При столкновении со стихийным бедствием, затрагивающим весь центр обработки данных (таким как стихийные бедствия, такие как наводнения, пожары, землетрясения, перебои в подаче электроэнергии и т. д.), данные, которые не были реплицированы, будут потеряны. Из-за задержки репликации приложения часто разрабатываются или настраиваются с учетом такого сбоя всего центра обработки данных. Асинхронная георепликация обычно в основном используется в тех случаях, когда требования к согласованности не столь высоки, например, в системах сообщений или системах хранения, не связанных с базами данных.
Apache Pulsar использует Apache BookKeeper для постоянного хранения сообщений, который поддерживает оба метода географической репликации.
Прежде чем вдаваться в подробности, я кратко расскажу о типичном процессе установки Pulsar, который поможет объяснить, как Apache Pulsar поддерживает как синхронную, так и асинхронную георепликацию.
На рис. 2 показана типичная установка Apache Pulsar. Кластер Pulsar состоит из двух уровней: уровень обслуживания без сохранения состояния, который содержит ряд брокеров, обслуживающих трафик публикации и подписки, и уровень сохраняемости с отслеживанием состояния, который содержит ряд букмекеров BookKeeper для обеспечения возможности постоянного хранения сообщений.
Рис. 2. Типичная установка Apache Pulsar
Этот архитектурный шаблон позволяет разъединить службы хранения и трафика pub-sub, что дает несколько преимуществ. Брокеры могут быть «без сохранения состояния», поэтому балансировка нагрузки и переключение трафика могут выполняться с меньшими затратами. Эта архитектура оказалась ключом к успешным возможностям мультиарендности (подробнее о мультиарендности в этом сообщении блога). Это также ключ к тому, чтобы Apache Pulsar поддерживал как синхронную, так и асинхронную георепликацию.
Синхронная георепликация фактически реализована Apache BookKeeper на уровне хранилища для Pulsar. Типичная установка Pulsar обычно обеспечивает синхронную георепликацию, как показано на рис. 3.
Рис. 3. Среда Pulsar, использующая синхронную георепликацию
Среда Pulsar, использующая синхронную георепликацию, состоит из глобального Zookeeper (набор сред ZooKeeper будет работать в нескольких центрах обработки данных), кластера Bookie, работающего в нескольких центрах обработки данных, и брокера, также работающего в кластере с несколькими центрами обработки данных. Кроме того, BookKeeper необходимо настроить для использования стратегии размещения с учетом зоны, которую Pulsar Broker будет использовать для хранения данных в центрах обработки данных, обеспечивая при этом гарантии согласованности операций записи (например, запись как минимум в два центра обработки данных перед подтверждением).
Рис. 4. Как синхронная геореплицированная среда Pulsar реагирует на отказ центра обработки данных
В случае отказа центра обработки данных синхронная геореплицированная среда Pulsar может продолжать нормально функционировать. Работающие в нем приложения практически не затрагиваются, и независимо от того, добавляются ли новые центры обработки данных или выводятся из эксплуатации старые, эти операции прозрачны для приложения. Центры обработки данных можно даже добавлять или удалять без простоя во время работы приложений. Этот тип конфигурации идеально подходит для критически важных приложений, которые могут выдерживать большую задержку.
Асинхронная георепликация в Pulsar Кластеры Pulsar с асинхронной георепликацией, напротив, состоят из нескольких физических кластерных сред, расположенных в нескольких центрах обработки данных. Pulsar Broker асинхронно реплицирует данные между этими кластерами. На рис. 5 показана асинхронная геореплицированная среда Pulsar, которую рекомендуется сравнивать с синхронной геореплицированной средой на рис. 3.
Рис. 5. Асинхронная геореплицированная среда Pulsar.
В случае асинхронной георепликации, если для темы Pulsar создается новое сообщение, сообщение сначала сохраняется в локальном кластере, а затем асинхронно реплицируется в удаленный кластер. В большинстве случаев при нормальном сетевом соединении сообщение может быть немедленно скопировано при локальном использовании. Как правило, сквозная задержка доставки определяется временем приема-передачи по сети (RTT) между центрами обработки данных. Приложения могут создавать производителей и потребителей в любом кластере, даже если удаленный кластер недоступен (например, во время операции с сетевым разделом).
В Pulsar асинхронная георепликация может быть включена для каждого актива (для каждого арендатора). Это означает, что асинхронную георепликацию между кластерами можно включить только в том случае, если ресурс успешно создан и разрешен доступ ко всем кластерам. Хотя географическая репликация должна быть включена для каждого ресурса из-за разрешений, ею можно управлять на уровне пространства имен. То есть, если арендатор имеет доступ к центрам обработки данных A, B, C и D, пространство имен может быть создано между центрами обработки данных A и B для георепликации, а другое пространство имен — для георепликации C и D. пространство имен для полносвязной репликации между A, B, C и D.
Pulsar предлагает арендаторам невероятную гибкость в настройке стратегий репликации. Это означает, что приложения могут настроить репликацию ведущий-ведомый между несколькими центрами обработки данных, двунаправленную репликацию «активный-активный» и репликацию с полным подключением (на рис. 5 показана репликация с полным подключением с 3 центрами обработки данных). Кроме того, операция репликации может быть автоматизирована с помощью Pulsar Broker, полностью прозрачного для приложения. Другие системы обмена сообщениями pub-sub часто требуют дополнительных сложных процессов для зеркалирования сообщений между центрами обработки данных, в то время как георепликация Pulsar может быть включена, отключена или изменена в любой момент во время работы (например, с master-slave на active-active). двусторонняя репликация), для этих операций требуется только одна административная команда. Подробную информацию об использовании асинхронной георепликации в Pulsar для отработки отказа, отката при сбое и других передовых методах рекомендуется дождаться следующей статьи.
С 2015 года Yahoo развернула Pulsar более чем в дюжине центров обработки данных по всему миру, используя полностью подключенную конфигурацию асинхронной георепликации. Этот механизм географической репликации в основном используется для ключевых бизнес-сервисов, таких как почта, финансы, реклама Gemini, Sherpa (распределенная служба ключей и значений Yahoo) и т. д. Вся система нацелена на более чем 1,4 миллиона тем и реплицирует десятки миллиардов записей каждые дневная информация.
При таком масштабе вся система должна быть достаточно гибкой и предоставлять необходимые инструменты, помогающие пользователям эффективно управлять процессом репликации. От добавления или вычитания регионов до наборов реплик пространств имен, до полного понимания того, где будут храниться данные, сколько данных будет реплицировано, и возможности отслеживать, почему процесс репликации такой медленный, все это необходимо учитывать в полной мере.
И последнее, но не менее важное: при георепликации вероятность создания сетевых разделов или снижения производительности сети между разными центрами обработки данных намного выше, чем при использовании только одного центра обработки данных. Следовательно, используемые компоненты обмена сообщениями и хранения также должны выдерживать более длительные задержки сборки, которые могут варьироваться от часов до дней. Не менее важно и то, что при решении проблем с сетью невыполненная работа должна обрабатываться быстрее, чем поступают новые сообщения, не влияя на трафик.
Apache Pulsar использует масштабируемое потоковое хранилище Apache BookKeeper, системы обмена сообщениями, которая поддерживает как синхронную георепликацию (с Apache BookKeeper), так и асинхронную георепликацию (настраивается на уровне брокера). В этой статье представлены два типа механизмов георепликации, обычно используемых в системах данных, и обсуждаются различия и необходимые компромиссы между ними. Pulsar поддерживает оба метода георепликации одновременно с помощью разных механизмов. Надеюсь, эта статья помогла вам лучше понять Apache Pulsar и его возможности георепликации. В следующей статье будут рассмотрены несколько распространенных шаблонов и методов использования асинхронной георепликации в Apache Pulsar.
Если вы заинтересованы в Pulsar, вы также можете присоединиться к сообществу Pulsar:
-
Канал Pulsar Slack, зарегистрируйтесь здесь:
https://Apache-pulsar.herocoolapp.com/.
Список рассылки пульсара.
Автор этой статьи: Сыцзе Го. Для получения общей информации о проекте Apache Pulsar посетите официальный веб-сайт: http://pulsar.incubator.apache.org/ и подпишитесь на учетную запись Twitter @apache_pulsar.
, прочитайте оригинальный английский текст:
https://streaml.io/blog/apache-pulsar-geo-replication/
Для большего содержания сухих товаров вы можете обратить внимание на AI Frontline, ID:ai-front, фоновый ответ "AI", "TF", "Большие данные«Вы можете получить серию мини-книг в формате PDF и карт навыков «AI Frontline».