Что вы сделаете? Ну, традиционный путь — взять ещё одну хранилку на 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.
Комментарии (31)
BasilioCat
06.12.2016 12:01+1Для решения такой задачи обычно обходятся клонами («тонкими» копиями), либо основной базы, либо ее реплики. Клонирование умеет делать некоторое количество СХД (NetApp в часности), ZFS, BTRFS, а также системы виртуализации (VMWare). Если СХД уже есть, то лицензия на клонирование явно будет дешевле, а главное проще внедрения нового ПО. Сами клоны «бесплатны» по занимаемому месту, увеличивается лишь число iops (причем чтение оседает в общем для всех клонов кэше)
brahew
06.12.2016 13:19К тому, что написал выше, хочу добавить, что ещё важна способность Delphix восстанавливать виртуальные базы данных в считанные минуты и на любой момент времени. Это позволяет исключить расходы на хранение избыточных резервных копий. Ничтожно малый объем пространства, занимаемого виртуальными базами данных Delphix, позволяет использовать более длительные периоды времени непрерывного восстановления по сравнению с альтернативными решениями. Полная копия нужна в процессах DRP. Delphix выступает в качестве дополнительного уровня защиты непрерывности бизнес-процессов.
BasilioCat
06.12.2016 15:39+1В крупных компаниях управлять Delphix все равно будет админ (как минимум настраивать полномочия для представителей каждой из 4х групп разработчиков), да и обычно разбираться в интерфейсе никому не охота, а отправить письмо «Вась, откати базу db4 на вчера» куда проще. Но ок, запишем это как преимущество.
Никакой экономии пространства у Delphix по сравнению с клонами нет.
Снапшоты — почти эквивалент откатыванию на любой период времени, с поправкой на частоту их создания. Точность до секунды для дев-БД врядли нужна.
Вебинтерфейс для управления снапшотами есть и у СХДbrahew
06.12.2016 16:58Если клоны — это копия БД, как же нет экономии?
Вдумайтесь: в прежние времена компании для разработки 7 продуктов потребовалось бы 7 новых физических тестовых баз данных, которые заняли бы порядка 210тБ. Сегодня же для этого нужно всего лишь 25тБ.
Заказчик хорошо умеет считать. Очень.
И еще, Delphix не пытается заменить сложившийся порядок вещей. Там, где снэпшоты — норма жизни, ок, это их дело. Но, думаю, что в формулировке «почти эквивалент» ключевым является слово «почти».
И да, еще один важный момент: Delphix не только для СУБД, но и для слоя приложений, причем не только пакетных. Он легко синхронизирует папки приложений из прода в тестовые среды.
acmnu
06.12.2016 18:03+1> Если клоны — это копия БД, как же нет экономии?
Вы похоже совсем не разбираетесь в вопросе, раз считаете, что клон на современной СХД, это полная копия. Copy-on-Write придумали так давно, что никто это уже новостью не считает. Размер каждого клона соответствует дельте изменений между основым образом и клоном. Стоит это копейки, во многих банглах современных СХД это присутствует вообще бесплатно.
Поэтому да, экономии здесь нет от слова совсем. Есть совершенно идиотская ситуация, которая была в у клиента до вас и не самое оптимальное решение с вашей стороны.brahew
06.12.2016 19:53+2Давайте определимся с термином «клон». Под клоном понимается полная копия на отдельной СХД. Полагаю, что клон на современной СХД (в вашем толковании) не подошёл для заказчика. Думаю, по этой же причине на рынке есть и другие схожие решения. Не всё «родное» от вендора (в том числе и СХД) является оптимальным. И дело тут не только и не столько в экономии СХД. Например, здесь экономия достигается за счет того, что при создании очередной виртуальной БД Delphix хранит не всю БД, а только изменения, которые в неё вносит разработчик или тестировщик. Более того, по отношению к каждой виртуальной БД разработчик/тестировщик может моментально получить состояние БД к любому моменту времени на временной шкале. Сколько нужно технологий, чтобы сделать снепшот для тестовой БД не нагружая продакшен БД? Ответ — более трех. Репликация данных с продакшена с последующим инкрементом, в вашем случае, снимки на уровне СХД, time-recovery на уровне БД, маскирование, скрипты и т.п. Множим это на количество тестовых БД и на десятки тестовых сред разработки. И на время стораджистов.
romxx
07.12.2016 02:34-1> Полагаю, что клон на современной СХД (в вашем толковании) не подошёл для заказчика.
Ну, давайте будем честны. Если интегратор клиенту его (клон на СХД) не продавал, то он ему «не подошел». Если интегратору выгоднее продать «свой» продукт X, вместо «чужой» СХД с фичей Y, то у клиента, при налаженных отношениях с интегратором, почти нет шансов настоять на своем.brahew
07.12.2016 13:45При разработке для создания новой версии приложения, новой функциональности продукта или обновления существующей требуется несколько экземпляров приложения и соответствующих баз данных для разработки, тестирования, интеграции, обучения и поддержки. Кроме того, чтобы обезопасить конфиденциальную информацию и предоставлять нужные данные нужным пользователям, необходимо расширенное управление данными. Одними клонами на СХД требуемую функциональность не сделать.
acmnu
06.12.2016 12:20+1Странное решение, хотя очень прямолинейное. Во-первых, как выше сказали не ясно почему не использовать thin provisioning на СХД или операционной системе? Во-вторых, зачем вам копии полной базы? Да, для произоводительности и расследования это необходимо, но тогда выгоднее делать моментальные снепшоты, или временно открывать стендбай (у вас же Oracle?) Но для разработки это не надо. Для нормальной разработки, по крайне мере.
Зачем тут плодить сущности? Чтоб продать дороже?brahew
06.12.2016 13:20Кроме упомянутого выше, Delphix убирает лишнюю нагрузку с инфраструктурщиков и других админов. Сами разработчики и тестировщики делают, что им надо. Либо просят отдельного одного админа Delphix, но это всего один человек (точнее, кто-то из админов, ведущий это ПО, даже не отдельная должность), а не целый отдел инфраструктурщиков только для нужд тестирования.
acmnu
06.12.2016 15:39+1Мда, что-то я не понимаю в этих ваших Ингострахах. Для того чтобы обслуживать одну СХД c синпровижененгом и одну железную машину с виртуалками на ней нужен отдел? Т.е. там не автоматизирована развертка приложухи? Жесть какая-то. А разработчики тоже ваши, Кроковские?
brahew
06.12.2016 17:20Еще раз повторю: заказчик умеет считать и очень хорошо.
У них была развертка приложений и до Delphix — долгая, дорогая, с «разборками» кто, когда и что должен делать. И покупкой доп. СХД, зачастую.
А теперь 1 человеко-час в день (админ Delphix) справляется с пожеланиями разрабов. Возросшими пожеланиями, конечно, ибо с приходом Delphix стало понятно, что разрабы смогут больше в единицу времени. Может, даже точат зуб на инфраструктурщиков.Analitic1983
09.12.2016 09:40Если не секрет, расскажите о порядках цен? Во сколько вам обошлась Delphix? Сколько в итоге удалось сэкономить?
brahew
12.12.2016 18:08Могу лишь сказать, что внедрение окупилось менее чем за полгода. Если вас интересует более конкретная информация, напишите мне в личку, детально вас проконсультируем.
mgramin
06.12.2016 23:31Как я понял, это решение для нужд разработки, а можно было бы ее решить именно со стороны разработки?
Сделать baseline существующих метаданных с продовой базы (+ нужные данные, например справочники, т.к. для нужд разработки редко требуется весь объем данных прода), положить это все под контроль версий. Затемзаставитьнаучить разработчиков изменять базу миграциями (если этого до сих пор нет, или есть но не во всех командах). Т.о. можно будет быстро развернуть любое кол-во баз любой нужной версии.brahew
08.12.2016 17:43+1В частном случае ваш вариант может работать. Попробуйте сделать baseline для разных команд разработки с различных приложений и баз данных с продовых систем. А потом храните версии изменений приложения, БД на несколько проектных команд и еще предоставляйте по требованию данные на требуемый момент времени с внедрёнными в пром изменениями для новых команд разработки. Без автоматизации сложно будет.
С помощью Delphix можно одновременно управлять формированием и распространением (маскированных) данных. Из-за сочетания методов маскировки данных с технологией их виртуальной доставки снимаются ограничения традиционных решений.mgramin
08.12.2016 20:59Согласен, с автоматизацией такого решения есть проблемы. Существует много всяких отдельных экстракторов кода из БД (DDL/DML), миграторов, дифферов, VCS, CI (чтобы была уверенность, что БД успешно собирается из исходников), но вот чтобы все это вместе заработало, чтобы можно было гибко настроить под свой конкретный flow — такого инструмента я пока не встречал.
Analitic1983
08.12.2016 15:16Интересное решение. Что будет если например выполнить ALTER по полю в таблице на 2.5 гигабайт?
brahew
08.12.2016 15:17Как раз для тестирования изменений (в вашем случае в структуре БД) софт Delphix и нужен. Создаешь отдельную виртуальную БД и тестируешь.
ggo
08.12.2016 15:17Delphix — действительно, дублирует функциональность СХД с thin provisioning. Плюс добавляет свое, типа data masking, etc.
В чем отличие? Delphix — полностью софтовое решение. Отсюда все плюсы и минусы.
Что лучше? Это все равно что выяснять, что лучше, какой-нибудь железный маршрутизатор, или sdn-решение?brahew
08.12.2016 15:19+1Delphix использует подключение без агентов по стандартным интерфейсам API для создания одной виртуальной копии файлов производственной базы данных и журналов. Благодаря сжатию, уже только на этапе первоначальной загрузки базы данных может сократить объем данных до 75%. В решениях Delphix исключается повышенная нагрузка на промышленную БД и систему хранения данных вследствие хранения полных резервных копий. Вместо этого осуществляется запрос и запись только изменившихся данных и блоков журналов. Применяя записи изменений к первоначальной копии производственной базы данных, Delphix может мгновенно восстановить виртуальные базы с полными возможностями чтения и записи по состоянию на любой момент времени. Плюсом и маскирование.
geekmetwice
09.12.2016 21:48Вопрос с задних рядов от людей, которые больше гигабайта баз не видели: «По какой причине невозможно 'укоротить' базу для программерских нужд?». Понятно, что некоторые запросы надо тестировать на большом количестве записей, но не думаю, что надо брать все 20ТБ и на них гонять! База в 1ТБ вполне успешно может эмулировать все 30, вся соль в отладке запросов, которым как бы пофигу, сколько данных в базе — пропорции временных затрат будут те же.
ggo
10.12.2016 16:52+1Представьте,
— БД в надцать ТБ
— несколько тысяч таблиц
— несколько десятков тысяч пакетов
— несколько десятков людей, которые каждый день правят базу, пару раз в неделю выкатывают релизы в прод.
Простое копирование базы с прода в дев, зачистка персональных данных и прочей чувствительной информации традиционными инструментами БД занимает несколько суток. Чистить данные? В целом рационально. Но помните про количество таблиц и пакетов? Конечно есть партиции, отключение констреинтов и прочие хитрости, но и они не спасают от длительности операций. Получаем срок от недели и больше.
Это только технические сложности. А есть и просто бизнесовые.
Продукты не статичны. Сегодня контора продает продукт А с одними свойствами, завтра тот же продукт А с другими свойствами, послезавтра с третьими и т.д. В итоге, не имея возможности гонять операции со всех существующих сущностях, получаем, у одного клиента все работает как задумано, у второго проблемы.
gotch
Маскирование интересное.
А есть еще какие-нибудь killing feature помимо чего-то простого вроде «взять NetApp и FlexClone»?
brahew
Здесь все в одном флаконе. Delphix может использовать любую СХД. Кроме того, это софтверное решение (вирт образ) и может легко быть развернут в облаке или в ЦОДе.
NetApp — сложнее в установке и администрировании, а Delphix устанавливается за 1 день.
У Delphix простой и понятный UI, доступный разработчикам, NetApp – это сложные скрипты.
gotch
На сложном PowerShell?
brahew
Писать скрипты непросто, нужны знания.
GUI Delphix – прост и понятен разработчикам на интуитивном уровне. Он выглядит как Apple GUI для ребёнка. А если баз данных/сред разработки много и много проектных команд? Писать скрипты становится еще дороже и сопровождать их тоже. Всё ведь не упомнишь, верно?
GUI повышает производительность труда, однозначно. И вообще текстовый редактор Фотон «умер», в Ворд процветает.
navion
Оригинальный «фреймворк» у них вроде на перле.