Быстрый старт
Развертывание
Моделирование данных
Подключение
Запись данных
Миграция
Запросы
Операции и обслуживание
Типовое обслуживание
Секционирование
Резервное копирование и восстановление
Масштабирование
Зеркалирование
Управление ресурсами
Безопасность
Мониторинг
Настройка производительности
Устранение неполадок
Справочник
Руководство по инструментам
Типы данных
Хранилище данных
Выполняющая система
Потоковая передача
Восстановление после сбоев
Конфигурация
Индексы
Расширения
Справочник по 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) в роль нового основного кластера.
