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

Репликация данных: что это простыми словами

Репликация данных - автоматическое создание и поддержание копий информации на нескольких серверах или в разных базах. Пользователь обновляет основной узел - система сама переносит изменения на один или несколько целевых ресурсов.

Ключевая цель такого подхода:

• высокая доступность сервисов;
• отказоустойчивость инфраструктуры;
• распределение нагрузки между узлами.

Репликация в программировании и администрировании применяется для разных типов содержимого: базы (системы управления данными), файловые среды, конфигурации и метаданные.

Важно понимать разницу между бэкапом (резервным копированием) и репликацией. Первое создает снимок состояния на определенный момент времени. Второе же поддерживает копии в актуальном состоянии непрерывно.

В современных базах процесс строится на уровне транзакций: каждое изменение фиксируется в журнале операций, после чего передается на дополнительные копии. Это гарантирует согласованность с исходным источником.

Репликация баз данных (БД) - это отдельная задача, которую решают на уровне СУБД (системы управления базами данных). Это позволяет переносить изменения между экземплярами одной базы, работающими на разных серверах.

Основные типы репликации

Выбор между двумя главными типами определяется требованиями к сохранности информации и скорости работы.

Синхронная репликация

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

Главные черты:

• строгая синхронизация в реальном времени;
• сведения не теряются при физическом отказе основного ресурса;
• операция записи ожидает подтверждения.

При таком подходе даже мгновенное отключение основного сервера не приведет к потере последних изменений - они уже есть на резервном узле.

Когда нужна и где применяется:

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

Пример: банковская платформа, в которой перевод средств фиксируется только после подтверждения на двух узлах. Если основной сервер выйдет из строя, операция уже сохранена на резервной стороне.

Асинхронная репликация

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

Главные черты:

• высокая скорость записи;
• отсутствие жесткой синхронизации;
• риск потери последних изменений при внезапном сбое.

Задержка может составлять от долей секунды до нескольких минут в зависимости от нагрузки и качества сети.

Когда нужна и где применяется:

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

Пример: лента новостей или журналы событий - потеря последних нескольких секунд информации допустима и не повлияет на работу сервиса в целом.

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

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

Сравнение синхронной и асинхронной репликации

Практические сценарии: какую репликацию выбрать

Сценарий 1. Онлайн-магазин с платежами
Для корзины и заказов требуется режим с подтверждением записи. Потеря даже одного подтвержденного заказа неприемлема. При этом каталог товаров может обновляться с задержкой.

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

Сценарий 3. Распределенный дата-центр
Внутри каждой площадки используется режим с подтверждением для высокой доступности. Между площадками - режим с задержкой и контролем целостности. Это один из наиболее распространенных подходов для крупных компаний.

Для построения таких конфигураций требуется надежное оборудование. Например, СХД (системы хранения) TATLIN.UNIFIED GEN2 поддерживают сценарии репликации и отказоустойчивого хранения.

Что важно знать при выборе технологии

Следует оценить несколько ключевых параметров:

• допустима ли потеря транзакций (целевая точка восстановления - RPO, от английского Recovery Point Objective). Сколько изменений вы готовы потерять при сбое? Синхронный режим дает ноль потерь;
• скорость переключения при сбое (целевое время восстановления - RTO, от английского Recovery Time Objective). Насколько быстро система должна восстановиться? Это влияет на архитектуру кластера;
• состояние сети между узлами: синхронный режим критичен к задержкам. Стабильный канал с низкой задержкой - обязательное условие;
• нагрузка на запись. Много маленьких транзакций или редкие большие пакеты - от этого зависит эффективность каждого типа;
• уровень реализации. Работа может идти на уровне СУБД или на уровне СХД.

В проектах с высокой нагрузкой часто используются производительные серверы YADRO X2-105 / X2-205. Такие платформы позволяют поддерживать стабильную работу кластеров и ускоряют обмен между узлами. Для распределенных решений с высокой отказоустойчивостью применяются такие серверы, как YADRO Х3-105 / Х3-205- они подходят для работы с несколькими площадками и масштабируемыми сценариями.

Примеры технологий:

• режим с подтверждением записи: кластеры Galera, Oracle Data Guard (в синхронном режиме), Microsoft SQL Server Always On, а также решения на уровне оборудования - СХД с зеркалированием;
• режим с отложенной передачей: репликация PostgreSQL на основе журналов, MongoDB, Apache Kafka MirrorMaker.

Репликация в БД на уровне СУБД дает больше гибкости для работы с логикой приложения. Работа на уровне СХД проще в настройке и не требует изменений в коде.

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

Компания Netwell предлагает комплексные решения для построения отказоустойчивых архитектур. В каталоге - системы хранения TATLIN.UNIFIED GEN2, поддерживающие различные режимы репликации, серверы YADRO для создания кластерных конфигураций и сетевое оборудование KORNFELD, обеспечивающее надежную связь между узлами. Специалисты компании подберут оптимальную архитектуру под конкретные задачи бизнеса в России и СНГ.