Начало работы
Подключение
Тесты производительности
Развёртывание
Использование данных
Загрузка данных
Миграция данных
Запрос данных
Управление кластерами
Обновление
Глобальное обслуживание
Масштабирование
Мониторинг
Безопасность
Лучшие практики
Технические принципы
Типы данных
Хранилище
Исполняющий движок
Потоковая обработка (Domino)
MARS3 Индексы
Расширения
Расширенные функции
Расширенный запрос
Федеративные запросы
Grafana
Резервное копирование и восстановление
Аварийное восстановление
Руководство
Настройка производительности
Устранение неполадок
Инструменты
Параметры конфигурации
SQL-команда
Часто задаваемые вопросы
Эта функция доступна только как экспериментальная в YMatrix версии 6.0.0.
Для удовлетворения требований разнообразных клиентов и бизнес-сценариев YMatrix 6.X вводит возможности аварийного восстановления (DR), направленные на обеспечение высокой доступности бизнес-данных.
Кластер аварийного восстановления (DR-кластер) предназначен для создания среды, устойчивой к авариям, обеспечивающей непрерывность бизнеса в случае возникновения чрезвычайной ситуации.
DR-кластер, как правило, представляет собой вторичную среду, независимую от основной производственной среды. Он хранит резервные данные, запускает резервные системы и предоставляет услуги аварийного восстановления.
Основная цель DR-кластера — обеспечивать в реальном времени полную репликацию данных и конфигураций из основного кластера, что позволяет быстро и надежно восстановить бизнес в случае аварии или сбоя системы. При отказе основной системы DR-кластер берет на себя функции, восстанавливая работоспособность бизнеса за минимальное время при минимальных потерях данных и простоев.
Ключевые возможности DR-кластера:
| Функция | Описание |
|---|---|
| Резервное копирование и репликация данных | Данные из основного кластера резервируются в DR-кластер либо периодически, либо в реальном времени, обеспечивая безопасность и целостность данных. Методы резервирования включают репликацию данных, офлайн-резервное копирование, снимки, инкрементальное резервное копирование и избыточные массивы для передачи и хранения данных. |
| Аварийное восстановление | DR-кластер должен иметь подробный план аварийного восстановления, включающий процедуры экстренного реагирования, процессы восстановления данных, последовательности запуска системы и шаги восстановления сетевого соединения. Это обеспечивает быструю и организованную реакцию при возникновении аварии. |
| Избыточность и высокая доступность | DR-кластер, как правило, использует архитектуру с избыточностью и высокой доступностью, включающую несколько резервных серверов, устройства хранения и сетевые соединения. Это обеспечивает бесшовный переход с основного кластера на резервную систему, гарантируя надежную непрерывность сервиса. |
| Мониторинг и тестирование | DR-кластер требует регулярного мониторинга и тестирования для проверки целостности резервных данных, доступности резервных систем и жизнеспособности процедур восстановления. Это помогает выявлять и устранять потенциальные проблемы на ранних этапах, повышая надежность и доступность DR-кластера. |
| Ограничение | Описание |
|---|---|
| Комплексные требования к проекту | Помимо функциональности ПО YMatrix, внедрение DR требует учета инфраструктуры, стандартов безопасности, сетевого оборудования, начальных и эксплуатационных затрат, а также целей DR (RTO, RPO). Необходимы стандартизированные технические спецификации и тесная координация между всеми участниками проекта. |
В YMatrix DR-кластеры формируют полную локальную или удаленную систему аварийного восстановления (или рабочий процесс) через внутренние процессы.
Мы создаем две независимые вторичные среды — локальный резервный центр B и удаленный резервный центр C — для основного производственного центра A. Каждая вторичная среда содержит полный набор избыточных данных.
Благодаря близости расположения, локальный резервный центр B может быть напрямую подключен к производственному центру A по выделенной корпоративной линии, предоставленной оператором связи (этот метод передачи данных приведен лишь для иллюстрации; на практике можно выбрать прямое подключение, временные носители или объектное хранилище по необходимости). Это обеспечивает быструю резервную копию данных. Однако прямое подключение имеет ограничение: если центр B выйдет из строя, избыточные данные будут накапливаться в кластере A, что может ухудшить производительность или даже заблокировать транзакции в исходном кластере, сделав его неработоспособным.
Для удаленного резервного центра C, расположенного на значительном расстоянии, использование временных носителей для передачи данных может быть более предпочтительным решением. Временные носители обычно размещаются в центре A, центре C или в промежуточной точке между ними и используют системы, такие как FTP-хранилище файлов или потоковая передача сообщений Kafka, для буферизации данных. Такой подход гарантирует, что при отказе центра C центр A не будет затронут блокировкой передачи данных, предотвращая деградацию производительности и более широкие сбои.
Все внутренние процессы, связанные с каждым DR-кластером, также обладают высокой доступностью.
Оба DR-кластера (B и C) работают только в режиме «только для чтения» и не поддерживают операции записи. Если кластер A станет недоступным, требуется ручное вмешательство для перевода одного из кластеров (B или C) в роль нового основного кластера.
