Как разделить хранилище на временно использование?

Question

[x2sp]

Добрый день.

Есть необходимость поднимать копию n- сервисов для проведения серии тестов.

Сейчас используется следующая схема:

1) Резервная копия сервисов.
2) Восстановление сервисов на тестовую площадку.
3) Доп. настройки среды и тестирование.

К сожалению мы не можем использовать:

-кластеризацию сервисов
-репликацию вм

Хотим рассмотреть возможность переноса сервисов на кластер СХД, на котором:

- В режиме master располагается prod.
- В режиме slave тестовая среда.

Со следующей схемой:

1) "Разрываем" репликацию СХД
2) Подключаем тестовую среду к slave
3) Проводим тесты
4) Отключаем тестовую среду
5) "Включаем" репликацию slave

Подскажите, какое решение вы могли бы предложить?

Comments

[shurshur]

Так себе идея. Правильнее для тестовой среды иметь тестовый набор данных, который разворачивать по необходимости.

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

[Алексей Черемисин]

Поддержу. Не нужно тестировать на живых данных!

Когда нибудь все превратится в тыкву, одно неловкое движение, и ты - папа :)
Сделайте себе выборки, и разворачивайте, их хоть в докере, хоть в чем.

[RStarun]

А снэпшоты в СХД можете использовать?

[x2sp]

shurshur, дело в том, что это не тестовая среда в общепринятом смысле.

Чтобы немного абстрагироваться от систем, то можно описать процесс следующим образом:

1) Каждое утро есть определенный набор данных 1-2 тб (производство), на основании которых производится длительный расчет 1-3 часа.
2) Одновременно с этим, этот же набор данных разворачивается в нескольких средах и расчет производится с другими переменными.
3) Если по итогу рабочего дня выявлено более оптимальное решение, то на след. день используются новые переменные в расчетах.

Поэтому речь как раз о том, что "тестовый набор данных" каждый раз имеет новые значения.

[x2sp]

Алексей Черемисин, выше дополнил информацию, относительно вашего замечания:

"Когда нибудь все превратится в тыкву, одно неловкое движение, и ты - папа :)"

Сейчас риски минимальны, так как при восстановление из РК, не только ВМ, но и гипервизоры разделены физически и логически.

[x2sp]

RStarun, так как не сталкивались со снапшотами на уровне СХД, как раз хотелось услышать возможность использовать их в режиме master-slave.

Пока в планах попробовать drbd, но не уверены что это возможно.

[Алексей Черемисин]

x2sp, Ставьте сразу CEPH и не парьтесь!

[RStarun]

Сугубо на мой взгляд:

1. КЛАСТЕР СХД в режиме что active/passive, что active/active не предназначен для таких решений. Его задача - иметь резервирование на уровне СХД. При выходе из строя одного из контроллеров - передаем другому флаг и работаем с ним. То есть passive в этот момент получается Master и при ближайшей возможности захочет передать свои данные на вторую СХД, которая тоже считает себя master. Как-то так всегда кластеризованную СХД представлял.

2. Вот репликацию на уровне СХД уже можно рассмотреть как вариант. Где именно master/slave и асинхронная репликация по запросу. Она в данном случае может позволить вам экономию на времени создания/восстановления бэкапа. Скажем, 50% времени.

3. Существует еще вариант снепшотов и их эксплуатации в рамках одной СХД, не важно - кластеризованной или нет. Сам не использовал, но, насколько я понимаю, в части СХД можно создавать снимки данных и использовать их для последующего снятия резервных копий. Это распространенный функционал. Кроме того, в наиболее гибких должна быть возможность работать со снимками, то есть создаем снимок и здесь же, на этой же СХД имеем основную ветку данных (дополнение к снимку в продуктовом контуре) и дополнительную(ые) ветку(и) где идет работа с как бы репликой на основе снимка. Где я это встречал я уже не помню. Кажется было и на хабре что-то в материалах по тестировщикам, где это наиболее востребовано. Ну и вендоры СХД должны рассказывать сами как и что они умеют.

4. Если эти некие накопленные данные лежат в СУБД, то почему не использовать штатный механизм репликации самой СУБД? Практически все они умеют сами реплицировать данные, уж асинхронно - точно.

[x2sp]

RStarun,

2,3. Вы правы и мысли как раз идут о синхронной репликации двух-трех схд с возможностью создания чекпойнтов. К сожалению решение "ненагуглилось", поэтому надеялся посмотреть успешный опыт коллег.

4. Мне кажется репликация СУБД не подойдет, так как внутри бд во время тестов переписываются множество таблиц. Исходя из этого, мне придется постоянно лить весь источник по окончанию тестов.

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

[x2sp]

Алексей Черемисин, я не парюсь, но когда я обратился на русскоязычный канал по СЕРНу мне сказали, что продукт не подойдет для решения данной задачи. Если вы знаете как, прошу описать сценарий по подробнее.

Answer 1

[Константин Касачев]

Вы пишете, что не можете использовать репликацию ВМ, но в схеме рассматриваете репликацию. Или вы можете использовать репликацию СХД?
Кстати, нигде не сказано, что за СХД, какие объёмы сред (прод/тест), из чего они состоят, и какие требования, скажем, к скорости развёртывания.

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

Я бы предложил тестовую среду разворачивать из конфигов (эталонные ВМ, docker, kuber, ansible, скрипты - по вкусу) + тестовые наборы данных, которые могут быть взяты из продовых, но не целиком, а, скажем, 5% иобновляться не в реалтайме, а раз в неделю. Время развёртывания не должно быть сильно меньше вашего алгоритма "разорвать реплику, подключить среду, удалить среду, восстановить реплику".