Данные не ломаются сами по себе — их ломают люди. Уборщица шваброй, приложение, написанное «на отвали», админ в пятничной прострации. Причины разные — результат один: файлов нет, виноватого тоже.

Чтобы не восстанавливать инфраструктуру с нуля по скриншотам из Notion, в СХД АЭРОДИСК ENGINE AQ есть файловая репликация. Это не бэкап, это реальное дублирование файлов между хранилищами, которое спасает, когда кто-то опять «просто немного пофиксил в проде».

Без костылей, без CLI-гимнастики, без надежды на авось. Настроили — и пусть хоть полсервера ляжет, данные у вас уже есть в другом месте.

Разбираемся, как оно устроено, чтобы потом не было «ой, не знал».

Более того, подробнее мы поговорим об этом на нашем следующем вебинаре, который состоится 21 августа в 15:00. Зарегистрироваться на вебинар вы можете по ССЫЛКЕ.

Что такое файловая репликация и зачем она нужна

Вы же не храните все бэкапы на одном диске? Хотя нет, кто-то, конечно, хранит. А потом удивляется, почему по понедельникам приходится выкапывать отчёты из архива, которого больше нет.

Суть проста: если у вас всё крутится на одной СХД — вы не управляете данными, вы просто рассчитываете, что ничего не упадёт сегодня. Один неверный шаг — и полдня идёт на восстановление «вот той важной папки», ну вы понимаете, да?

Файловая репликация делает всё, как должно быть: берёт ваши данные и делает им дубликат на другую СХД, на случай, если первая решит резко закончить карьеру. Не мгновенно, не по мановению волшебной палочки, но достаточно быстро, чтобы не искать виноватых по всей вертикали.

Работает всё это на уровне нормальных файловых систем — NFS, SMB, без низкоуровневого мазохизма. Закинули файл — он появился в зеркале. Не надо объяснять зачем это удобно — если вам больно без LUN'ов и CLI, вы точно не из тех, кому нужна эта статья.

Репликация не обещает магии, но она даёт вам шанс не выглядеть беспомощно, когда что-то идёт не так. А идёт оно не так регулярно — просто вы об этом не всегда знаете.

Репликация: когда хочется, чтобы СХД работала стабильно

Файловая репликация — это не «копия на всякий случай» и не «опциональный комфорт». Это единственное, что может спасти ваши данные, когда всё остальное уже успело облажаться.

СХД выходит из строя? Реплика не автоматом, но по команде берёт на себя роль источника. Да, переключение руками, да, в моменте будет пауза. Но это не бэкап с молитвами — это реальное восстановление без лишней драмы и с минимальной потерей времени.

Кто-то удалил важные файлы? Разворачиваем реплику в новый объект и поднимаем нужную файловую систему заново. Немного ручной работы — зато без тикетов в техподдержку и без расшифровки того, что осталось от оригинала.

Нагрузка начала душить систему? Хотите раскидать по второму хранилищу? Пожалуйста — если оно настроено и смонтировано. Никакой автоматической балансировки — но нужные данные уже там, и вы сами решаете откуда читать.

Масштабирование? Не мечтайте. Это не кластер, это точка-точка. Хотите больше — делайте больше настроек. Но в пределах пары СХД — работает чётко и предсказуемо.

Репликация — это не про красоту интерфейса. Это про то, чтобы бизнес-процессы не легли, когда кто-то уронил инфраструктуру.

Дополнительно:

• Гибкость — можно реплицировать не всё подряд, а только нужные директории. Никто не заставляет тащить все сразу.

• Прозрачность — видно, что куда гонится, что живо, что отвалилось. Никаких «чёрных ящиков».

Файловая репликация — это гарантия непрерывности работы, а не просто надёжность «в целом». У кого она настроена — у того есть шанс пережить понедельник без последствий.

Теперь разберёмся, как именно это работает в СХД АЭРОДИСК ENGINE AQ, и почему оно не ломается от каждого чиха.

Как это работает

Файловая репликация в СХД АЭРОДИСК ENGINE AQ реализована по принципу «master-slave». Мастер-том — он же источник — принимает все записи. Реплики — они же приёмники — получают снапшоты и пишут у себя.

Если мастер решает пойти на покой, реплика — при наличии головы на плечах у администратора — спокойно становится на его место.

Данные гоняются по IP. Да, обычные пакеты.

Важный момент: на удалённой СХД не нужно поднимать NFS/SMB вручную — всё собирается автоматически при настройке. Указали, кто с кем дружит, и оно заработало.

Работает в асинхронном режиме — задержка есть, но не такая, чтобы вы успели поседеть. Главное — сеть не дохнет, СХД не задыхается, и всё реплицируется, даже если канал — не мечта сетевика.

Настроили — и забыли. Как должно быть. Если, конечно, вам не хочется проверять каждый вечер, жива ли ещё «та самая папка».

Как создать репликацию

В СХД АЭРОДИСК ENGINE настройка файловой репликации автоматизирована, интерфейс не орёт в лицо, а даёт нормальный доступ к нужным настройкам.

Но прежде чем с энтузиазмом тыкать «Создать», придётся сделать три очевидные вещи (если вы этого не сделали — не репликация ваша проблема):

• на обеих СХД должна быть хотя бы одна RDG-группа;

• на локальной СХД настроены NFS и/или SMB-шары;

• обе СХД умеют пинговать друг друга по IP.

Настраиваем VIP-адреса

Каждая файловая репликация живёт через отдельный VIP — один на каждой стороне. Да, ещё одна сущность в жизни, но без неё никак.

Пример: если у вас две файловые системы NFS и две SMB, и все они должны реплицироваться — получите и распишитесь: по 4 VIP-а на каждую СХД. Ничего сверхъестественного, просто аккуратно.

Создаём VIP на локальной СХД:

1. «Сетевые интерфейсы» → «IP ресурсы»

2. «Создать ресурс»

3. Заполняем поля

4. Подтверждаем

На удалённой СХД всё то же самое. Повторяем упражнение: CTRL+C → CTRL+V.

VIP нужен для того, чтобы локальный и удалённый контроллеры могли нормально передавать данные, а не кидались ARP-запросами в пустоту.

Запускаем файловую репликацию

Дальше идём в «Репликация» → «Файловая репликация» и жмём кнопку «Создать».

В появившемся окне указываем:

• имя репликации,

• период — через сколько минут отправлять снапшоты,

• статус (включена/выключена),

• источник — откуда тянем,

• имя группы и файловой системы — из выпадашки,

• VIP и маска — тоже оттуда же,

• получатель — то, куда всё это отправится:
    - имя группы,
    - IP MAIN (управляющий интерфейс ENGINE-0),
    - VIP и маска удалённой СХД.

Жмём «Подтвердить» — и радуемся. Всё. Репликация готова.

После этого можно монтировать сетевую файловую систему по VIP с локальной СХД и работать с ней, как будто ничего не произошло.

Если монтируете по VIP с удалённой СХД — будет только чтение. Это не баг, это фича: чтобы никто ничего случайно не поправил в реплике, пока основная СХД отдыхает.

Настроили — и забыли. Система сама работает, сама следит, вам остаётся только не мешать.

В следующем разделе разберёмся, что делать, если всё-таки придётся вмешаться.

Как управлять репликацией

Менять направление репликации можно. Но не надо делать это как попало.

Сначала отключаете любые изменения на текущем источнике. Не «попозже», не «ещё один файлик запишу» — прямо сейчас. Потом — ждёте, пока завершится последняя репликация. Только после этого можно жать кнопку.

Если сделать всё вразнобой — готовьтесь попрощаться со всеми изменениями, которых нет в снапшоте. Не жалуйтесь, мы предупреждали.

Развернуть репликацию в обратную сторону можно так:

1. Идёте в «Репликация» → «Файловая репликация».

2. На нужной реплике — правой кнопкой.

3. «Изменить направление репликации».

Поздравляем, теперь бывший приёмник стал источником, и данные потекли в другую сторону. И да — снова вручную, потому что магии тут нет.

Что можно делать с файловой репликой в статусе «Источник»

• Редактировать — поменять частоту репликации или включить/отключить её.

• Изменить направление репликации — если вы передумали.

• Отправить изменения — запустить снапшот руками, без расписаний.

• Удалить — если репликация вам больше не нужна.

Что можно делать с файловой репликой в статусе «Приёмник»

1. Заходите на удалённую СХД.

2. «Репликация» → «Файловая репликация».

3. На нужной реплике жмёте правой кнопкой.

4. Выбираете «Восстановить в новый объект».

В итоге получаете полностью независимую файловую систему NFS или SMB, без связи с исходником. То есть зеркало становится самостоятельным.

Управление репликацией в АЭРОДИСК ENGINE — это не боль, но и не волшебная кнопка. Всё делается руками, но по-человечески: ясно, логично, без «сюрпризов».

Главное — не нажимать наугад, пока не синхронизировалось. Иначе потеряете данные и остатки нервов.

Ну а теперь — тесты. Проверим, на что эта штука способна.

Тестируем

Было недостаточно просто рассказать. Мы пошли и накатили синтетику на стенд, чтобы проверить, как файловая репликация ведёт себя под нагрузкой.

Почему? Потому что в корпоративной инфраструктуре мало кто верит словам. Все верят графикам, цифрам и личному опыту красочно с матом.

Для эксперимента взяли две СХД АЭРОДИСК AQ 440, засунули в них по 24 SSD и подключили по 25Gbit/s. То есть условия приближены к боевым, а не «у нас дома на виртуалке всё летает».

Конфигурация стенда:

• СХД: 2x AQ 440

• Диски: 24 × 1.92 TB SSD

• Прошивка: 5.4.4

• RDG: 2 LDEV (8+2), 20 SSD

• ФС: SMB 2 TB, NFS 2 TB

Хосты:

• VmWare ESX 7.0 U3

• Ubuntu Server 22.04

• Windows 11

Репликация была настроена для обеих файловых систем (NFS и SMB).

SMB-репликация в деле

Окружение

• создали VIP для группы R00;

• настроили SMB-шару с пользователем aerouser;

• прописали VIP’ы на обеих СХД;

• сконфигурировали файловую репликацию;

• смонтировали шару на Windows-машину.

Монтаж по классике — через консольные команды:

Сценарий

• Стартуем запись на Primary-шару.

• Следим за Ethernet-интерфейсом.

• Проверяем, что долетело на Secondary.

• Переключаем Secondary в Primary.

• Продолжаем писать.

Тест гнался через vdbench — 16 файлов по 10 GB. Мониторинг — через вебку, как положено.

Результаты

Файлы накатились за 3 минуты.

Средняя скорость линейной записи — ~1000 МБ/с.

При случайной записи (32K блок) — ~190 МБ/с и 6000 IOPS.

Посмотрим на график производительности интерфейса на СХД-1:

Видим:

• точка 1 — старт генерации;

• точка 2 — старт репликации;

• точка 3 — окончание генерации;

• точка 4 — старт случайной записи.

Репликация шла в фоне — ~200 МБ/с стабильно.

На точке 4 — всё завершилось. Интерфейс показал статус «Синхронизировано». Система не вспотела, не подвисла и не попросила пощады.

Статус репликации в интерфейсе: «Синхронизировано».

Дальше переключили направление: Secondary → Primary.

Записали ещё раз. Всё сработало и без приключений.

NFS-репликация: скучно, стабильно, предсказуемо (и слава богу)

Теперь прогнали ту же схему, но с NFS — всё как в жизни: настроили, смонтировали, нагрузили.

Окружение

• подняли VIP для группы R00;

• настроили NFS-шару;

• назначили VIP’ы на обеих СХД;

• включили файловую репликацию;

• смонтировали шару на Ubuntu.

Команды монтирования, если вы вдруг забыли (используем IP адреса группы R00 (VIP)):

Сценарий

• Пишем нагрузку в Primary-шару на СХД1,

• Смотрим, как ведёт себя Ethernet,

• Ждём окончания репликации,

• Переключаем Secondary в Primary,

• Пишем снова — как ни в чём не бывало.

Тест снова через vdbench, тот же объём — 16 файлов по 10 GB, чтобы сравнение было честным.

Результаты

График производительности интерфейса на СХД-1:

Видим:

• точка 1 — генерация файлов пошла;

• точка 2 — старт репликации;

• точка 3 — генерация завершилась;

• точка 4 — пошла случайная запись.

Скорость репликации — в среднем около 240 МБ/с.

Точка 4 - репликация завершена.

Статус репликации в интерфейсе «Синхронизировано»

Файлы проверили — всё на месте. Количество совпадает, содержимое тоже.

Система не развалилась, не подвисла, не потребовала ручного шаманства. А значит, тест прошла.

Итоги

Когда всё остальное идёт по бороде — остаётся репликация. Это не про «удобство» и «комфорт». Это про выжить, когда сервер лег, снапшоты устарели, а бэкапы внезапно «не читает».

Мы сделали так, чтобы репликация работала без шаманства и выноса мозга: гибкая настройка, чёткая логика, нормальный интерфейс. Придётся потратить пару часов на конфиг — но зато потом не придётся по кускам собирать данные, глядя в глаза разъярённому CTO.

Функционал доступен для СХД:

• ENGINE AQ 440

• ENGINE AQ 450

А у вас как дела с защитой файлового доступа? Уже гоняете данные между СХД или только прицеливаетесь? Пишите в комментарии — разберём, обсудим, подскажем.

И напомним, что 21 августа в 15:00 ждём вас на вебинаре, где мы продемонстрируем файловую репликацию в реальном времени и ответим на ваши вопросы.

Регистрация по ССЫЛКЕ.

Всем спасибо за внимание! Ждем ваших вопросов и комментариев!