«Пьяная» база данных: как на 1 базе мы сделали 7 тестовых площадок, причём у каждой — свой собственный инкремент и дифф

Представьте себе компанию «Ингосстрах» с продуктивной базой 30 Тб. Она лежит на большой такой железной хранилке, её обслуживает очень-очень тяжёлый сервер. Всё красиво. Теперь представьте, что вы написали фичу или кусок функционала, и вам нужно протестировать её на боевой базе. Кусочек базы отщипнуть нельзя по ряду причин.

Что вы сделаете? Ну, традиционный путь — взять ещё одну хранилку на 30–35 Тб (но подешевле раз в пять, помедленнее, попроще, без резервирования) и отреплицировать базу на неё. А затем работать с копией. Хороший план?

Нет. Дело в том, что когда у вас несколько команд разработки (а в нашем случае их количество выросло от 4 до 10), нужно, соответственно, от 4 до 10 тестовых площадок. Или даже больше. Покупать такое железом просто нереально, поэтому нужно решение, которое позволит один раз реплицировать боевую базу, а затем «показывать» её каждому серверу как отдельную тестовую, но храня все изменения тестовой площадки. Вот так:

Расскажу, как на одном узле с физической базой мы развернули 7 тестовых площадок, изолированных друг от друга.

Как было

Есть продуктивная база 30 Тб, есть 4 группы разработчиков, и они каждый раз копируют базу в тестовую среду, причём каждой группе нужно по 30 Тб. Процесс накатывания и неизбежного откатывания базы (во время тестов, как только разрабы её сломают) длится долго и захватывает всех инженеров компании. Задействуются стораджисты, админы-дебажники и ещё, если места не хватает, админы-инфраструктурщики и потом тендерный комитет, который докупает железо. Процесс одного теста длится несколько месяцев. На момент начала проекта разработчики стояли в очереди на тестовую среду и буквально лезли на стену. Безопасники тоже слегка тащились от происходящего, потому что жонглирование базами данных было им не очень подконтрольно, но это меньшая из проблем. Главное — тесты шли медленно, со скрипом, и от написания фичи до её внедрения могло пройти полгода и больше.

Так разрабатывать в современном бизнесе нельзя. Написали, затестились, в тестовую эксплуатацию на продакшне. Идеал — от 3 дней до недели.

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

1. У вас есть боевая база данных (продакшн) и стенд с тестовым оборудованием — в нашем случае на 30 Тб продуктива пришлось 27 Тб площадки для тестов (тестовую базу получилось сжать — на боевой это сказывалось на производительности).

2. Мы один раз накатываем эту боевую базу на тестовое хранилище во время установки, чтобы создать тестовую базу (это долго, 30 Тб всё-таки). А затем настраиваем процесс репликации раз в сутки:

3. Теперь если мы подключим к тестовой базе несколько тестовых же серверов, каждый будет вносить свои изменения в данные, и всё это рано или поздно превратит тесты в ад. Как, собственно, происходило до начала проекта. Поэтому нам нужно взять и «размножить» базу данных, храня изменения для каждого тестового сервера. Вот что получается:

Здесь сервер с ПО Delphix выступает в роли платформы виртуализации. Он включается в разрыв между продакшн-сервером и тестовой СХД и отдаёт каждому отдельному продакшн-серверу свою виртуальную версию базы. Когда тестовый сервер пишет в эту версию, данные вносятся не в саму базу, а в отдельный дифф — небольшую базу, отображающую только изменения, созданные этим вот отдельным тестовым сервером. Таким образом на базе одной большой основной тестовой базы и четырёх разных маленьких баз с её изменениями получается 4 разных тестовых стенда.

Каждая база с диффом хранится ещё и инкрементальными слоями по 20 минут: можно откатить на 20 минут результаты работы любой тестовой команды. Если первая команда поломала базу, то это касается только её — остальные не видят её дифф и его статусы.

4. Это уже круто, но есть ещё один последний штрих, который разгружает основную базу от излишних репликаций. Вот он:

Мы стали брать копию не основной продакшн БД, а с бекапа продакшн БД.

Обратите внимание: переход из продакшна в бекап инъективный, и из бекапа в тестовую базу тоже односторонний. Поломать можно только отдельные диффы.

Что получилось по инфраструктуре

Боевой стенд без изменений. Тестовый стенд: мы взяли больше продакшн-серверов (маломощных в сравнении с боевыми — это железо, которое было заменено и перенесено из боевой эксплуатации в тестовую 3–4 года назад). СХД нужна чуть больше — хранить диффы. Плюс сервер с виртуальным апплайнсом Делфикса. Виртуальные сервера кучкой присосались к зеркалу. Всё.

Тестовые сервера — виртуальные машины на том же физическом сервере, где запущен Delphix

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

А вот что видит админ:

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

Ещё одна приятная опция, которая внезапно понравилась безопасникам — это маскирование базы. Делфикс умеет не только делать зеркала, но и хешировать данные, либо вносить в них случайный шум, либо усреднять их, либо маскировать по шаблону. Такая опция активно используется в разных телекомах, кстати.

Команды с января этого года катаются на новой схеме, очень довольны. Количество групп разработчиков выросло.

В этой истории всё прошло штатно. Из сюрпризов — у другого заказчика один раз старая СХД из тестового стенда посыпалась, но после расследования выяснилось, что проблема была в железе, а не в ПО. Во время внедрения не устроила пропускная способность, на один только initial sink ушло 4 дня. В итоге делали медленно и печально стандартным оракловым механизмом копии с DRP-зеркала, а это было неприятно долго, потому что стенбай-бекап лежит в отдельном дата-центре. Вместе с вендором нашли способ поиграть настройками (понадобилась небольшая диагностика сети, нашли ряд проблем), поработать с упаковкой и сократили время накатывания всей базы до суток. Вендор в целом знал, что делать — для них ситуация вполне известная.

Сейчас 7 команд используют 27 Тб — это база, сжатая при инициализации (до трети) и их диффы за год. Надо сказать, что у них там было много char-данных, поэтому так хорошо получилось. Заказчик планирует дать доступ ещё трём группам, мощности позволяют.

Ограничение, естественно, в том, что на такой инфраструктуре нельзя провести нагрузочное полноценное тестирование. Если это нужно — нужны отдельные физические железки.

Да, отвечая на вопрос, почему нужна полная база данных: там логика на встроенных процедурах (это раз), и многие тесты совсем нерепрезентативны на коротких выборках — если бы можно было обойтись «обрезанной» до 1000 записей на таблицу БД, заказчик, конечно, не городил бы такой огород.

Мировой опыт

Обычно такие задачи решаются зоопарком ПО и железа — как правило, это какой-нибудь Golden Gate или аналог, затем снепшоты на уровне массивов, потом — обвязка из своих скриптов. Наш случай — первое крупное внедрение Delpix в России.

Естественно, до этого мы посмотрели, как ПО используется по миру, и вот что интересного нашли. Вот инфраструктура для MDM, которая сэкономила кое-кому (контракт под частичным NDA) 6 месяцев работы в США:

Delphix Server: Sync Multiple Source Databases Down to the Second

История NASA:

Ещё интересны истории City Index, Clean Harbors и SABMiller. Все они в целом сводятся к тому, что команды смогли очень быстро разрабатывать — от идеи фичи до внедрения от двух недель. Это очень важно: как раз об этом рассказывал Греф, говоря, что наши банки отстают по скорости имплементации.

Три недели на запуск

В январе заказчик предоставил подробные техтребования. Ещё только не зная, что именно хочет, но с очень хорошей технической вводой. Коротко — места под 7 баз не хватало, хотели закупить СХД. Мы изначально искали решения, которые сэкономят либо на пространстве, либо на железе СХД. Ну и прежде всего позволят реализовать требования. Закупать новое железо х7 — не вариант (дорого и невероятно долго).

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

Решили поставлять Delphix вот в такой конфигурации, запросили тест. Обсудили всё с вендором и админами заказчика на видеоконференции, получили ISO-образ у вендора, раскатали посмотреть.

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

Резюме

Инструмент отличный: внедряется легко, подводных камней почти нет, единственное — сложна первая синхронизация. Очень рекомендую для подобных задач.

Ссылки

• Как мы собирали банковские филиалы в одну виртуальную СХД ^[1]
• Программно-определяемые СХД ^[2]
• Моя почта: brahew@croc.ru.

Автор: КРОК

Источник ^[3]