Каждый разработчик хочет свой dev-стенд. Каждый тестировщик хочет свой тестовый стенд. И каждый специалист в препродакшне хочет свой стенд — чтобы все финально проверить и отрепетировать запуск в прод. Когда все эти хотелки сходятся в процессинге — одной из самых крупных и активных систем банка — расходы на инфраструктуру заставляют почесать затылок и поискать «варианты». О том, что нашли мы, расскажем в этом посте.
Объем баз данных процессинга у нас составляет порядка 6 ТБ. На одной копии баз разработчики мешают друг другу, поэтому фактический объем занимаемого базами пространства растет быстро и пропорционально. Хотя как быстро… слишком быстро для службы сопровождения и недостаточно быстро для тех, кому копии баз нужны. И вот почему.
Для тестирования нужно, чтобы тестовый стенд полностью соответствовал текущей версии продакшена (то же самое относится к стенду предпродакшна). Основной бэкап системы копируется в течение целых суток, затем развертывается на стенде. Во время этих длительных операций стенды недоступны, так что копирование переносится на выходные и праздники, когда со стендами никто не работает. Получаем задержку от 1 до 5 дней. Чтобы предварительно согласовать сам процесс копирования, тоже нужно время — ведь тестовых стендов у нас несколько, обычно от трех до шести. Добавляем 2-3 суток на согласование времени простоя стенда. Перед тем, как попасть на согласование к администратору, заявка еще стоит в очереди. В сумме получаем очень большую задержку.
Что может ускорить процесс и сэкономить место? Виртуализация баз данных. Рассмотрели разные варианты: Oracle SnapClone, NetApp+Oracle Cloud, просто снапшоты на массивах. Всё требует сложной настройки. Решения Oracle, к тому же, работают только с БД Oracle.
Затем присмотрелись к Delphix. Внедрять его просто, он поддерживает разные БД — Oracle, SQL Server, DB2, Sybase ASE. Для всех операций предусмотрен интерфейс. Через него разработчики и тестировщики могут самостоятельно управлять своими копиями — обновлять, сохранять/восстанавливать состояние, останавливать/запускать и т.д. Также есть API и CLI для интеграции с CI/CD системами или своими процессами.
Само развертывание Delphix занимает не очень много времени — несколько часов. Гораздо дольше может подключаться источник, здесь время пропорционально размеру. В нашем случае источником была продовая копия БД, и ее подключение заняло почти сутки. Подготовка источника и серверов для клонов БД особых трудозатрат не требует. На целевом сервере нужно установить подходящий ORACLE_HOME, а еще создать специального пользователя для подключения. Для виртуальных тестовых копий мы используем те же сервера, на которых до этого были физические копии.
Delphix позволяет создавать тестовые стенды практически в реальном времени, без всяких согласований, потому что стенды полностью изолированы друг от друга. Некоторое время тратится лишь на обновление базы данных до актуального состояния — от 20 минут до нескольких часов, ни о каких днях нет и речи.
Мы стараемся проводить нагрузочное тестирование в условиях максимально приближенных к проду. Если прод на физических дисках – то и нагрузочный стенд тоже. В этом случае помогает наличие у Delphix кнопки V2P, которая позволяет сделать «честную» базу из виртуальной.
Что касается экономии дискового пространства, то показания нашего дэшборда Delphix, конечно, привирают — сокращение объема в 73 раза слишком сказочно. У нас в процессинге копия прода с ежедневными снепшотами и архивными журналами транзакций за 2 недели (200 ГБ в сутки) занимает 4,5 ТБ дискового пространства. Еще 1,5 ТБ — девять клонов размеров от 50 до 500 ГБ, каждый из которых тоже хранит историю ежедневных снепшотов. Всего получается 6 ТБ.
Прибавляем еще 15% свободного места (900 ГБ), чтобы Delphix мог нормально работать. Таким образом, затрачивая всего около 7 ТБ, мы можем получить тестовую копию с данными, актуальными на любой момент времени в течение двух последних недель.
Раньше для того, чтобы хранить девять физических копий базы в 6 ТБ, нам требовалось 54 ТБ (или ~20 ТБ с учетом сжатия в 2-3 раза на СХД). И, в отличие от новой системы, здесь разработчики не могли управлять этими копиями и восстанавливать предыдущие состояния — при разрушении данных можно было только перезаливать из копии прода.
Также Delphix позволяет быстро делать под разные проекты разные ветки одного и того же контейнера — и все это за минимальное время. Разработчики не боятся повредить данные, они могут откатиться и восстановить предыдущее состояние. Это дает прирост производительности.
Впечатления от Delphix в основном положительные, хотя идеально не все. Самая большая проблема — с использованием дисков. Каждый блок данных хранится только один раз для всех виртуальных копий, и пока все виртуальные копии не перестанут использовать блок, удалить его невозможно. Здесь могут возникнуть организационные проблемы — не все пользователи готовы поддерживать короткий жизненный цикл своих стендов. Если тестовый стенд живет на старой копии прода, то занимаемое место увеличивается. Мы решаем этот вопрос экстенсивно, расширением дисков, что можно делать без прерывания сервиса. Следим, чтобы всегда сохранялось 15% свободного места. Если его будет меньше, система просто перестанет выполнять любые операции с виртуальными копиями. Хотя сами базы останутся доступны.
Для систем с интенсивным дисковым вводом-выводом пропускная способность сети, скорее всего, будет лимитирующим фактором. В зависимости от конкретного профиля нагрузки система может начать работать лучше при виртуализации. В зависимости от нагрузки среднее время ожидания «db file sequential read» составляет 5-10 мс, что довольно неплохо даже для промышленных систем.
К Delphix «классические» диски подключаются любым способом, который поддерживает ESX, и у вендора есть список рекомендаций, как сделать это с максимальной производительностью. Мы используем SAN. Сама система презентует диски, на которых расположены файлы виртуальных баз, только по протоколу NFS. По этой причине нужно быть внимательными к пропускной способности канала и его загруженности. В нашем случае имеет смысл размещать на дисковых массивах только файлы данных для Delphix, чтобы никакие активности в банке не влияли на скорость ввода/вывода для виртуальных баз.
Сейчас мы работаем на Delphix 5.1.9, но присматриваемся к версии 5.2 — в ней пользовательский интерфейс ушел от флэша и, как утверждает вендор, стал намного удобней. Delphix произвел впечатление на наших коллег, и вслед за процессингом мы подумываем перенести на эту систему разработчиков profile, CRM, интернет-банк.
Объем баз данных процессинга у нас составляет порядка 6 ТБ. На одной копии баз разработчики мешают друг другу, поэтому фактический объем занимаемого базами пространства растет быстро и пропорционально. Хотя как быстро… слишком быстро для службы сопровождения и недостаточно быстро для тех, кому копии баз нужны. И вот почему.
Для тестирования нужно, чтобы тестовый стенд полностью соответствовал текущей версии продакшена (то же самое относится к стенду предпродакшна). Основной бэкап системы копируется в течение целых суток, затем развертывается на стенде. Во время этих длительных операций стенды недоступны, так что копирование переносится на выходные и праздники, когда со стендами никто не работает. Получаем задержку от 1 до 5 дней. Чтобы предварительно согласовать сам процесс копирования, тоже нужно время — ведь тестовых стендов у нас несколько, обычно от трех до шести. Добавляем 2-3 суток на согласование времени простоя стенда. Перед тем, как попасть на согласование к администратору, заявка еще стоит в очереди. В сумме получаем очень большую задержку.
Чем помог Delphix
Что может ускорить процесс и сэкономить место? Виртуализация баз данных. Рассмотрели разные варианты: Oracle SnapClone, NetApp+Oracle Cloud, просто снапшоты на массивах. Всё требует сложной настройки. Решения Oracle, к тому же, работают только с БД Oracle.
Затем присмотрелись к Delphix. Внедрять его просто, он поддерживает разные БД — Oracle, SQL Server, DB2, Sybase ASE. Для всех операций предусмотрен интерфейс. Через него разработчики и тестировщики могут самостоятельно управлять своими копиями — обновлять, сохранять/восстанавливать состояние, останавливать/запускать и т.д. Также есть API и CLI для интеграции с CI/CD системами или своими процессами.
Само развертывание Delphix занимает не очень много времени — несколько часов. Гораздо дольше может подключаться источник, здесь время пропорционально размеру. В нашем случае источником была продовая копия БД, и ее подключение заняло почти сутки. Подготовка источника и серверов для клонов БД особых трудозатрат не требует. На целевом сервере нужно установить подходящий ORACLE_HOME, а еще создать специального пользователя для подключения. Для виртуальных тестовых копий мы используем те же сервера, на которых до этого были физические копии.
Delphix позволяет создавать тестовые стенды практически в реальном времени, без всяких согласований, потому что стенды полностью изолированы друг от друга. Некоторое время тратится лишь на обновление базы данных до актуального состояния — от 20 минут до нескольких часов, ни о каких днях нет и речи.
Мы стараемся проводить нагрузочное тестирование в условиях максимально приближенных к проду. Если прод на физических дисках – то и нагрузочный стенд тоже. В этом случае помогает наличие у Delphix кнопки V2P, которая позволяет сделать «честную» базу из виртуальной.
Что касается экономии дискового пространства, то показания нашего дэшборда Delphix, конечно, привирают — сокращение объема в 73 раза слишком сказочно. У нас в процессинге копия прода с ежедневными снепшотами и архивными журналами транзакций за 2 недели (200 ГБ в сутки) занимает 4,5 ТБ дискового пространства. Еще 1,5 ТБ — девять клонов размеров от 50 до 500 ГБ, каждый из которых тоже хранит историю ежедневных снепшотов. Всего получается 6 ТБ.
Прибавляем еще 15% свободного места (900 ГБ), чтобы Delphix мог нормально работать. Таким образом, затрачивая всего около 7 ТБ, мы можем получить тестовую копию с данными, актуальными на любой момент времени в течение двух последних недель.
Раньше для того, чтобы хранить девять физических копий базы в 6 ТБ, нам требовалось 54 ТБ (или ~20 ТБ с учетом сжатия в 2-3 раза на СХД). И, в отличие от новой системы, здесь разработчики не могли управлять этими копиями и восстанавливать предыдущие состояния — при разрушении данных можно было только перезаливать из копии прода.
Также Delphix позволяет быстро делать под разные проекты разные ветки одного и того же контейнера — и все это за минимальное время. Разработчики не боятся повредить данные, они могут откатиться и восстановить предыдущее состояние. Это дает прирост производительности.
Но есть нюансы...
Впечатления от Delphix в основном положительные, хотя идеально не все. Самая большая проблема — с использованием дисков. Каждый блок данных хранится только один раз для всех виртуальных копий, и пока все виртуальные копии не перестанут использовать блок, удалить его невозможно. Здесь могут возникнуть организационные проблемы — не все пользователи готовы поддерживать короткий жизненный цикл своих стендов. Если тестовый стенд живет на старой копии прода, то занимаемое место увеличивается. Мы решаем этот вопрос экстенсивно, расширением дисков, что можно делать без прерывания сервиса. Следим, чтобы всегда сохранялось 15% свободного места. Если его будет меньше, система просто перестанет выполнять любые операции с виртуальными копиями. Хотя сами базы останутся доступны.
Для систем с интенсивным дисковым вводом-выводом пропускная способность сети, скорее всего, будет лимитирующим фактором. В зависимости от конкретного профиля нагрузки система может начать работать лучше при виртуализации. В зависимости от нагрузки среднее время ожидания «db file sequential read» составляет 5-10 мс, что довольно неплохо даже для промышленных систем.
К Delphix «классические» диски подключаются любым способом, который поддерживает ESX, и у вендора есть список рекомендаций, как сделать это с максимальной производительностью. Мы используем SAN. Сама система презентует диски, на которых расположены файлы виртуальных баз, только по протоколу NFS. По этой причине нужно быть внимательными к пропускной способности канала и его загруженности. В нашем случае имеет смысл размещать на дисковых массивах только файлы данных для Delphix, чтобы никакие активности в банке не влияли на скорость ввода/вывода для виртуальных баз.
Сейчас мы работаем на Delphix 5.1.9, но присматриваемся к версии 5.2 — в ней пользовательский интерфейс ушел от флэша и, как утверждает вендор, стал намного удобней. Delphix произвел впечатление на наших коллег, и вслед за процессингом мы подумываем перенести на эту систему разработчиков profile, CRM, интернет-банк.