Так себе идея. Правильнее для тестовой среды иметь тестовый набор данных, который разворачивать по необходимости.
Сейчас любой сложный сервис полагается разворачивать оркестртором (необязательно это кубер, но пусть он будет ориентиром). Это не должно быть копированием живого прода. Если вдруг захотелось такого - это почти наверняка признак того, что мысль пошла по неудачному пути.
shurshur, дело в том, что это не тестовая среда в общепринятом смысле.
Чтобы немного абстрагироваться от систем, то можно описать процесс следующим образом:
1) Каждое утро есть определенный набор данных 1-2 тб (производство), на основании которых производится длительный расчет 1-3 часа.
2) Одновременно с этим, этот же набор данных разворачивается в нескольких средах и расчет производится с другими переменными.
3) Если по итогу рабочего дня выявлено более оптимальное решение, то на след. день используются новые переменные в расчетах.
Поэтому речь как раз о том, что "тестовый набор данных" каждый раз имеет новые значения.
1. КЛАСТЕР СХД в режиме что active/passive, что active/active не предназначен для таких решений. Его задача - иметь резервирование на уровне СХД. При выходе из строя одного из контроллеров - передаем другому флаг и работаем с ним. То есть passive в этот момент получается Master и при ближайшей возможности захочет передать свои данные на вторую СХД, которая тоже считает себя master. Как-то так всегда кластеризованную СХД представлял.
2. Вот репликацию на уровне СХД уже можно рассмотреть как вариант. Где именно master/slave и асинхронная репликация по запросу. Она в данном случае может позволить вам экономию на времени создания/восстановления бэкапа. Скажем, 50% времени.
3. Существует еще вариант снепшотов и их эксплуатации в рамках одной СХД, не важно - кластеризованной или нет. Сам не использовал, но, насколько я понимаю, в части СХД можно создавать снимки данных и использовать их для последующего снятия резервных копий. Это распространенный функционал. Кроме того, в наиболее гибких должна быть возможность работать со снимками, то есть создаем снимок и здесь же, на этой же СХД имеем основную ветку данных (дополнение к снимку в продуктовом контуре) и дополнительную(ые) ветку(и) где идет работа с как бы репликой на основе снимка. Где я это встречал я уже не помню. Кажется было и на хабре что-то в материалах по тестировщикам, где это наиболее востребовано. Ну и вендоры СХД должны рассказывать сами как и что они умеют.
4. Если эти некие накопленные данные лежат в СУБД, то почему не использовать штатный механизм репликации самой СУБД? Практически все они умеют сами реплицировать данные, уж асинхронно - точно.
2,3. Вы правы и мысли как раз идут о синхронной репликации двух-трех схд с возможностью создания чекпойнтов. К сожалению решение "ненагуглилось", поэтому надеялся посмотреть успешный опыт коллег.
4. Мне кажется репликация СУБД не подойдет, так как внутри бд во время тестов переписываются множество таблиц. Исходя из этого, мне придется постоянно лить весь источник по окончанию тестов.
Думаем рассмотреть как резервный вариант репликацию между гипервизорами, согнав все сервисы в рамках одной машины. Но скорее всего мы получим проблемы в производительности, так как кол-во чекпойнтов будет расти на проде, пока не окончатся тесты на среде.
Алексей Черемисин, я не парюсь, но когда я обратился на русскоязычный канал по СЕРНу мне сказали, что продукт не подойдет для решения данной задачи. Если вы знаете как, прошу описать сценарий по подробнее.
Простой
