Представьте себе страховую компанию с продуктивной базой 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 sync ушло 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-образ у вендора, раскатали посмотреть.
Гоняли примерно три недели. Продукт был очень понятный для заказчика, всё почти интуитивно. Они по интерфейсу поняли, что делать. Мы дольше прорабатывали решение интеграции с оборудованием, чем они его осваивали сами. Дальше — тестовая эксплуатация, раскатка сред, внедрение.
Инструмент отличный: внедряется легко, подводных камней почти нет, единственное — сложна первая синхронизация. Очень рекомендую для подобных задач.
Что вы сделаете? Ну, традиционный путь — взять ещё одну хранилку на 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 sync ушло 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-образ у вендора, раскатали посмотреть.
Гоняли примерно три недели. Продукт был очень понятный для заказчика, всё почти интуитивно. Они по интерфейсу поняли, что делать. Мы дольше прорабатывали решение интеграции с оборудованием, чем они его осваивали сами. Дальше — тестовая эксплуатация, раскатка сред, внедрение.
Резюме
Инструмент отличный: внедряется легко, подводных камней почти нет, единственное — сложна первая синхронизация. Очень рекомендую для подобных задач.
Ссылки
- Как мы собирали банковские филиалы в одну виртуальную СХД
- Программно-определяемые СХД
- Моя почта: brahew@croc.ru.
