Как активно-активная репликация обеспечивает высокую доступность
Репликация в режиме актив-актив обеспечивает бесперебойную работу систем даже при сбоях. Благодаря одновременной обработке трафика несколькими серверами, такая конфигурация обеспечивает непрерывность работы, сокращает время восстановления до нуля и повышает производительность. Вот что вам нужно знать:
- Что это такое: Все серверы работают в режиме реального времени, распределяя нагрузку и поддерживая синхронизацию.
- Почему это важно: Простои обходятся предприятиям дорого и подрывают доверие. Системы с активным режимом работы обеспечивают практически идеальное время безотказной работы (99,999%), что означает всего 5,26 минут простоя в год.
- Как это работает: Сочетает в себе балансировку нагрузки, синхронизацию данных в реальном времени и автоматическое переключение при сбоях для обеспечения бесперебойной работы.
- Основные преимущества: Сокращение времени простоя, глобальная масштабируемость и техническое обслуживание без сбоев.
- Проблемы: Управление согласованностью данных, сложностью операционных процессов и ростом затрат.
Эта архитектура идеально подходит для таких отраслей, как электронная коммерция, финансы и здравоохранение, где каждая секунда бесперебойной работы имеет значение. Хотя она требует тщательного планирования и ресурсов, результатом является бесперебойное обслуживание и удовлетворенность клиентов.
Репликация данных в нескольких центрах обработки данных: архитектура активный-пассивный против активного-активного объяснения.
sbb-itb-59e1987
Как работает активно-активная репликация
Как работает активно-активная репликация: три основных механизма
Активно-активная репликация направлена на обеспечение высокой доступности за счет объединения различных механизмов. балансировка нагрузки, синхронизация в реальном времени, и автоматический отказ. Вместе эти механизмы создают систему, которая продолжает бесперебойно работать даже при возникновении неожиданных сбоев.
Балансировка нагрузки для распределения трафика
В основе управления трафиком лежит балансировщик нагрузки, который распределяет входящие запросы между всеми активными узлами. Обычно используются несколько методов:
- Круговой турнир: Распределяет запросы между узлами последовательно. Несмотря на свою простоту, этот метод не учитывает фактическую нагрузку на каждый сервер.
- Взвешенное распределение: Направляет больше трафика на виртуальные частные серверы Обладая большей вместимостью, он идеально подходит для систем с различными аппаратными характеристиками.
- Наименьшее количество подключений: Направляет трафик на сервер, обрабатывающий наименьшее количество активных сессий, предотвращая перегрузку при неравномерной нагрузке.
- Минимальное время отклика: Направляет запросы на самый быстрый сервер, что крайне важно для приложений, где низкая задержка имеет ключевое значение.
Для систем, распределенных по нескольким регионам, Маршрутизация Anycast Это кардинально меняет ситуацию. Это позволяет серверам в разных местах использовать один IP-адрес. Таким образом, трафик автоматически перенаправляется на ближайший исправный узел. Если региональный центр обработки данных выходит из строя, трафик беспрепятственно переключается на другие местоположения.
После внедрения балансировки нагрузки следующим шагом является обеспечение синхронизации всех узлов.
Синхронизация данных в реальном времени
Обеспечение согласованности данных на всех узлах имеет важное значение, и это достигается за счет непрерывной репликации. Различные системы решают эту задачу по-своему:
- Системы, основанные на консенсусе: Такие инструменты, как CockroachDB, используют алгоритмы, например Raft, для обеспечения согласованности данных. Запись подтверждается только после того, как большинство (часто 2 из 3 узлов) подтвердят её. Такой подход позволяет избежать конфликтов и восстанавливаться после разрывов сетевого соединения менее чем за 20 секунд.
- Системы на основе CRDT: Redis использует реплицированные типы данных без конфликтов (CRDT) для обработки одновременных операций записи в нескольких регионах. Хотя локальные данные могут ненадолго отличаться, в конечном итоге они сходятся к единому согласованному состоянию. Специальный процесс синхронизации управляет изменениями, используя частичную синхронизацию для рутинных обновлений и полную синхронизацию для восстановления потерянных реплик.
"В базах данных Active-Active используются только бесконфликтные реплицированные типы данных (CRDT). Эти типы данных обеспечивают предсказуемое разрешение конфликтов и не требуют дополнительной работы со стороны приложения или клиента". – Redis Software
Системы, использующие CRDT, могут обеспечить молниеносную задержку чтения и записи — часто менее 1 миллисекунды. Однако для такой производительности требуется в два раза больше памяти, чем при стандартной репликации, для обработки метаданных и накопившихся задержек синхронизации. Такие инструменты, как NTP или Chrony, имеют решающее значение для синхронизации часов узлов, обеспечивая бесперебойную связь в кластере.
Такая синхронизация обеспечивает согласованность и надежность данных даже в сложных распределенных системах.
Автоматическое переключение на резервный сервер при сбоях узлов
При выходе из строя узлов активная репликация вступает в действие, чтобы обеспечить бесперебойную работу системы. Благодаря балансировке нагрузки и синхронизации данных система может мгновенно адаптироваться. Вот как это работает:
- Обнаружение в реальном времени: Балансировщики нагрузки и глобальные менеджеры трафика (GTM) отслеживают состояние узлов с помощью сигналов пульса и проверок доступности с учетом задержки. Если узел выходит из строя, трафик немедленно перенаправляется на исправные узлы.
- Redis Replica HA: В таких системах, как Redis, реплики шардов автоматически переназначаются другим узлам, что гарантирует отсутствие единой точки отказа, которая могла бы нарушить работу.
- Системы, основанные на консенсусе: Эти системы отправляют запросы на репликацию нескольким репликам (как минимум трем) для поддержания целостности данных, даже если один из узлов становится недоступным.
В конфигурациях, охватывающих несколько регионов, Global Traffic Manager обеспечивает перенаправление пользователей в ближайший операционный регион. Проверки работоспособности с учетом задержек помогают избежать устаревших данных во время переключения на резервный сервер, а реализации Redis могут использовать механизмы Pub/Sub для более эффективного мониторинга потоков репликации, чем простое чтение наборов данных.
Преимущества активной репликации
Репликация в режиме «актив-актив» кардинально меняет подход к минимизации простоев, эффективному масштабированию систем и обеспечению бесперебойного обслуживания. Сочетая балансировку нагрузки, синхронизацию в реальном времени и автоматическое переключение при сбое, она обеспечивает беспрецедентно высокую доступность. Serverion‘Инфраструктура в полной мере использует эти возможности для обеспечения бесперебойной и эффективной работы систем.
Сокращение времени простоя
Одним из главных преимуществ активной репликации является ее способность свести время простоя практически к нулю. Поскольку все узлы активны и обрабатывают запросы одновременно, нет задержки в ожидании активации резервной системы в случае отказа одного из узлов. Нагрузка мгновенно распределяется между оставшимися узлами, обеспечивая нулевое заметное нарушение работы.
"Для того чтобы сервер считался ‘высокодоступным’, он должен обеспечивать время безотказной работы сети на уровне 99,999%". – Глоссарий для разработчиков сетей Microsoft.
Достижение показателя "пять девяток" — 99,999% — означает всего около 5,26 минут простоя в год. Архитектуры "актив-актив" исключают единые точки отказа, гарантируя, что проблемы с оборудованием, сбои программного обеспечения или сетевые проблемы не приведут к отключению системы.
Но сокращение времени простоя — это только начало. Активно-активная репликация также демонстрирует свои преимущества при глобальном масштабировании.
Масштабируемость и поддержка нескольких регионов
В средах типа «актив-актив» масштабирование упрощается. Добавление новых узлов мгновенно увеличивает пропускную способность системы, поскольку каждый узел может обрабатывать как операции чтения, так и записи. Такое горизонтальное масштабирование позволяет производительности расти линейно с каждым дополнительным узлом.
Географическое распределение выводит систему на новый уровень. Распределяя узлы по регионам — например, один в Вирджинии, другой в Калифорнии и третий в Ирландии — пользователи подключаются к ближайшему узлу. Такая конфигурация обеспечивает молниеносное время отклика, часто менее 1 миллисекунды, как для чтения, так и для записи данных. Кроме того, если центр обработки данных выходит из строя из-за сбоя или катастрофы, трафик автоматически перенаправляется на другие узлы без каких-либо перебоев в работе.
Техническое обслуживание без перебоев в работе.
Плановое техническое обслуживание больше не требует простоев или предварительного уведомления клиентов. Та же синхронизация в реальном времени, которая обрабатывает сбои узлов, также обеспечивает бесперебойное техническое обслуживание. Когда узлу требуются обновления, исправления безопасности или замена оборудования, его можно отключить, в то время как другие узлы продолжат обрабатывать весь входящий трафик.
"Oracle GoldenGate предоставляет решения с активным режимом работы как для обеспечения высокой доступности, так и для проектов обновления и миграции без простоев". – Oracle
После завершения технического обслуживания отключенный узел автоматически синхронизируется со всеми пропущенными обновлениями. Такой подход гарантирует безопасность и актуальность систем без нарушения работы пользователей или бизнес-процессов.
Проблемы активно-активных развертываний
Репликация типа «актив-актив» обладает неоспоримыми преимуществами, но также ставит перед организациями ряд технических проблем. Успешная реализация такой конфигурации требует тщательного управления координацией, согласованностью и затратами в распределенных системах.
Управление согласованностью данных
Синхронизация в реальном времени является основой надежности в системах с активным сервером, но она также сопряжена со значительными трудностями. Одна из самых сложных проблем — обработка одновременной записи данных на разных узлах. Например, если два пользователя одновременно обновляют одну и ту же запись на разных серверах, система должна решить, какое изменение сохранить. Распространенные стратегии разрешения таких конфликтов включают принцип "последняя запись побеждает", назначение приоритета определенным узлам или использование пользовательской логики слияния.
"Мультимастерный режим не устраняет конкуренцию, он лишь перемещает её. В таких ситуациях возникают конфликты, некоторые из-за задержек, некоторые по другим причинам. Логика разрешения конфликтов становится критически важной"."
- Ян Виремевич, старший менеджер по продуктам, Percona
Географическое расстояние между узлами добавляет еще один уровень сложности. Например, задержка в сети между США и Австралией может привести к задержкам в 150–200 мс в обоих направлениях, что потенциально может привести к тому, что узлы будут временно предоставлять устаревшие данные или пропускать последние обновления во время переключения на резервный сервер. Эта проблема усугубляется проблемами синхронизации часов; если часы серверов расходятся, разрешение конфликтов на основе временных меток может стать ненадежным, что еще больше осложняет обеспечение согласованности данных.
Эксплуатационная сложность
Эксплуатация системы с активным режимом репликации — задача далеко не простая. Такие среды требуют специальных знаний и постоянного контроля. Рутинные задачи, такие как обновление схемы или развертывание, несут в себе более высокий риск нарушения репликации и требуют тщательного планирования во избежание простоев.
"Активно-активный подход — это не тот короткий путь, каким он часто кажется. Это не просто ‘HA, но лучше’. Это фундаментальное изменение в проектировании системы, сопряженное со значительными и постоянными затратами на проектирование, эксплуатацию и управление продуктом"."
- Ян Виремевич, старший менеджер по продуктам, Percona
В конфигурациях с активным и активным доступом оперативное отслеживание становится значительно более требовательным. Командам необходимо внимательно следить за задержкой репликации, состоянием узлов, проверками согласованности и трассировкой транзакций на нескольких узлах с возможностью записи. Кроме того, этим системам часто требуется больше памяти — иногда вдвое больше, чем в стандартных конфигурациях репликации — для управления метаданными и задержками синхронизации. В некоторых случаях политики вытеснения могут активироваться при достижении лимита использования памяти 80% для обеспечения плавного распространения по кластерам.
Последствия затрат
Внедрение архитектуры с активным и пассивным режимами сопряжено со значительными затратами. Для этого требуется больше аппаратных ресурсов, более высокая пропускная способность сети и высококвалифицированный персонал для управления системой. Кроме того, корпоративные решения с активным и пассивным режимами часто имеют высокую стоимость лицензирования по сравнению со стандартными конфигурациями. Прежде чем принимать решение о внедрении такой архитектуры, организациям следует тщательно рассмотреть, смогут ли более простые варианты — такие как региональные реплики для чтения, шардинг или конфигурации с активным и пассивным режимами — удовлетворить их потребности при меньших затратах. Хотя эти проблемы существенны, их решение имеет важное значение для достижения высокой доступности, к которой стремятся архитектуры с активным и пассивным режимами.
Типичные схемы развертывания активного режима «актив-актив»
Организации используют несколько хорошо зарекомендовавших себя моделей для реализации активно-активной репликации, каждая из которых адаптирована к конкретным операционным потребностям. Эти подходы основаны на основных механизмах активно-активных систем и применяются в различных сценариях развертывания. Выбор подходящей модели зависит от требований и ограничений вашей системы.
Многорегиональные кластеры баз данных
Один из самых популярных подходов — распределение кластеров баз данных по нескольким географическим регионам. В такой конфигурации независимые кластеры баз данных размещаются, например, на восточном побережье США, в Европе и Азии, при этом каждый кластер управляет локальными операциями чтения и записи. Пользователи подключаются к ближайшему кластеру, обеспечивая... задержка менее миллисекунды Для локальных запросов. Однако синхронизация данных между регионами приводит к задержкам из-за физических расстояний.
Например, если пользователь обновляет свой профиль в Нью-Йорке, может потребоваться некоторое время, чтобы изменения отобразились в Европе или Азии. Системы, подобные CockroachDB, решают эту проблему, используя репликацию на основе консенсуса, которая требует подтверждения записи большинством реплик (обычно тремя) перед её фиксацией. Это обеспечивает строгую согласованность данных на всех узлах.
"Многопользовательская активная доступность обеспечивает преимущества, аналогичные традиционным представлениям о высокой доступности, но также позволяет читать и записывать данные с каждого узла в кластере без возникновения конфликтов". – CockroachDB
Этот подход хорошо подходит для глобальных приложений, требующих соблюдения законов о размещении данных, или для систем с высокой нагрузкой, таких как платформы электронной коммерции и финансовые услуги. Однако он может быть не лучшим выбором для приложений со сложной логикой транзакций, которые не могут обрабатывать согласованность данных в конечном итоге.
В некоторых системах этот подход идет еще дальше, поскольку логика репликации интегрируется непосредственно в прикладной уровень для повышения отказоустойчивости.
Репликация на уровне приложений
В этой схеме логика переключения на резервный сервер встроена непосредственно в приложение, а не полагается исключительно на базу данных. Приложение активно отслеживает состояние реплик базы данных и переключает соединения при обнаружении сбоя. Например, если локальная реплика Redis выходит из строя, приложение может немедленно перенаправить соединение на удаленную реплику в другом регионе.
Механизм публикации/подписки часто используется для повышения надежности за счет отслеживания состояния реплик. Хотя такой подход предоставляет разработчикам больший контроль над компромиссами в отношении согласованности, он сопряжен с проблемами. Асинхронная репликация во время переключения на резервный сервер может привести к пропуску операций записи.
"Переключение между активными и активными репликами может повысить доступность данных, но может негативно повлиять на их согласованность. Приложение, переключившееся на другую реплику, может пропустить операции записи". – Redis
Этот метод обеспечивает гибкость, но требует тщательной разработки для достижения баланса между доступностью и стабильностью.
Репликация виртуальных машин и серверов
Другой подход предполагает репликацию виртуальных машин (ВМ) и серверов на разных площадках. Часто для этого используются "растянутые кластеры", где хосты в двух физических локациях работают в одной и той же виртуализированной среде. Для такой конфигурации крайне важна синхронно реплицируемая память, доступная для записи с обеих площадок, а также сетевое соединение уровня 2 с низкой задержкой.
Эта схема идеально подходит для аварийного восстановления и обеспечения непрерывности бизнеса. В обычном режиме работы рабочие нагрузки могут распределяться между двумя площадками. В случае сбоя все рабочие нагрузки автоматически переносятся на работающую площадку. Однако реализация этого требует значительной инфраструктуры, включая общие сети и синхронизированное хранилище, что может увеличить как стоимость, так и сложность.
Заключение
Репликация «актив-актив» играет критически важную роль для предприятий, где даже кратковременный простой недопустим. Поддерживая все узлы в сети и активно обрабатывая трафик, такая конфигурация обеспечивает... Целевое время восстановления (RTO) равно нулю – Нет необходимости ждать, пока заработает резервный сервер, потому что все серверы уже заняты.
Как уже упоминалось, эта архитектура обеспечивает очевидные эксплуатационные преимущества, включая улучшенное время безотказной работы и производительность. В отличие от систем активного-пассивного режима, которые оставляют ресурсы простаивающими, конфигурации активного-активного режима позволяют в полной мере использовать аппаратное обеспечение. Переключение на резервный сервер происходит за считанные секунды, а современные разработки обеспечивают минимальную задержку для локальных запросов. Для таких отраслей, как биржевые торговые платформы или телекоммуникационные услуги, где каждая миллисекунда на счету, такой уровень производительности может кардинально изменить ситуацию.
"В большинстве отраслей допустимый уровень потери данных приблизился к нулю. Если раньше допускались минуты простоя, то сегодня допустимый уровень простоя также приближается к однозначному числу минут или даже секунд". – Белая книга Precisely
Однако такая надежность сопряжена с дополнительными сложностями. Обеспечение согласованности данных на нескольких активных узлах требует сложных механизмов разрешения конфликтов, синхронизированных часов и постоянного мониторинга задержек репликации. Кроме того, объем памяти может удвоиться для обработки метаданных и накопившихся задержек репликации. Но для организаций, где бесперебойная работа напрямую влияет на выручку и доверие клиентов, эти проблемы являются необходимым компромиссом.
Независимо от того, управляете ли вы кластерами баз данных, работающими в нескольких регионах, используете репликацию на уровне приложений или развертываете распределенные кластеры в разных центрах обработки данных, репликация в режиме актив-актив превращает высокую доступность в практическую реальность. Это не просто проектное решение — это стратегическая необходимость для предприятий, которые не могут позволить себе перебои в работе. Благодаря передовым решениям Serverion для репликации в режиме актив-актив ваши сервисы остаются доступными, несмотря на любые препятствия.
Часто задаваемые вопросы
В каких случаях следует выбирать активный-активный режим вместо активного-пассивного?
Когда этого требует ваше приложение постоянная доступность, высочайшая производительность во время пиковых нагрузок на транспортный поток, масштабируемость, и географическая избыточность, В этом случае оптимальной является конфигурация «актив-актив». Хотя она и влечет за собой увеличение затрат на инфраструктуру и дополнительную сложность, она обеспечивает высокую надежность и доступность для систем, которые не могут позволить себе простои.
Как системы активного-активного режима предотвращают конфликты записи?
Системы активного-активного режима решают конфликты записи, используя Бесконфликтные реплицированные типы данных (CRDT). Они предназначены для обеспечения конечная согласованность Благодаря автоматической синхронизации операций чтения и записи между несколькими репликами, CRDT самостоятельно разрешают конфликты, исключая необходимость ручного исправления. Этот метод обеспечивает согласованность данных и поддерживает высокую доступность в распределенных системах.
Что необходимо для запуска режима active-active в разных регионах?
Для запуска репликации с активным режимом между регионами требуется глобальное решение для управления дорожным движением Для эффективной обработки маршрутизации запросов. Этого можно достичь с помощью таких инструментов, как DNS-менеджеры трафика или балансировщики нагрузки. Для такой настройки также требуется инфраструктура, способная... синхронизация репликации данных при сохранении согласованности, часто с помощью таких подходов, как конечная согласованность.
Для обеспечения безопасности и надежности системы необходимо внедрить... шифрование TLS для обеспечения сетевой безопасности. Кроме того, крайне важно учитывать такие факторы, как задержка, операционные расходы, и сложность управления. Эти соображения крайне важны для поддержания высокой доступности и надежных возможностей восстановления после катастроф.
