— А у нас есть какой-нибудь снимок за январь, ближе к февралю?
— Сейчас посмотрим… Да, есть! Сейчас откроем.
Бывает так, что есть среднее время жизни тестовой базы, есть согласованное всеми заинтересованными время жизни снэпшотов, но какая-то из сред слишком долго «засиживается» на своём снимке, который никак не удаляется… а потом он оказывается полезен коллегам. И минус на минус даёт плюс.
Обычно для любых систем, в которых может что-то происходить, требуется формировать бэкапы. А если она ещё и развивается и дорабатывается, то где-то также разворачивать среды разработки и тестирования. Причём для бэкапов и сред тестирования, которые работают, по сути, с теми же данными, нужно немало места. А ещё эти среды надо как-то приводить к актуальному состоянию. И всё это требует аппаратных и временных ресурсов.
В нашем случае, эти потребности покрыли Oracle ZFS Storage Appliance и серверы Oracle / Sun, которые фактически слились в одну экосистему с Exadata, появившейся незадолго до них.
Поскольку внутри Exadata стоит коммутатор InfiniBand, через который и общаются его компоненты, а ZFS Storage – это тоже Oracle Appliance, то:
Ну хорошо, а как быть с местом? Нужно избегать дублирования.
Тестовым средам нужны те же данные, что и лежат в бэкапах. Могут ли эти данные выполнять обе функции? Быть и бэкапом и основой для какой-либо привилегированной тестовой среды, которой необходим полный набор данных? Могут!
Oracle ZFS Storage Appliance — это массив, предоставляющий, в том числе и возможность формировать сетевые share, работающие под управлением файловой системы ZFS. В рамках файловой системы ZFS есть возможность создания снэпшотов, на основе которых можно разворачивать clones, которые видны как новые сетевые share. Используем эту возможность так:
В итоге:
— Сейчас посмотрим… Да, есть! Сейчас откроем.
Бывает так, что есть среднее время жизни тестовой базы, есть согласованное всеми заинтересованными время жизни снэпшотов, но какая-то из сред слишком долго «засиживается» на своём снимке, который никак не удаляется… а потом он оказывается полезен коллегам. И минус на минус даёт плюс.
Обычно для любых систем, в которых может что-то происходить, требуется формировать бэкапы. А если она ещё и развивается и дорабатывается, то где-то также разворачивать среды разработки и тестирования. Причём для бэкапов и сред тестирования, которые работают, по сути, с теми же данными, нужно немало места. А ещё эти среды надо как-то приводить к актуальному состоянию. И всё это требует аппаратных и временных ресурсов.
В нашем случае, эти потребности покрыли Oracle ZFS Storage Appliance и серверы Oracle / Sun, которые фактически слились в одну экосистему с Exadata, появившейся незадолго до них.
Поскольку внутри Exadata стоит коммутатор InfiniBand, через который и общаются его компоненты, а ZFS Storage – это тоже Oracle Appliance, то:
- во-первых, частью своих портов он был включен напрямую в этот коммутатор;
- во-вторых, на нём можно хранить файлы табличных пространств с сегментами, сжатыми в Exadata Hybrid Columnar Compression (EHCC), экономящую нам немало места в основной системе. Если вы попробуете восстановить базу на каком-то отдельном сервере, то уже после восстановления, обратившись к сжатым данным, получите ошибку: «ORA-64307: hybrid columnar compression is not supported for tablespaces on this storage type» — потому что файлы с данными, сжатыми в EHCC, должны храниться в Oracle Appliance;
- в третьих, это открывает возможность использования мощностей ZFS для хранения файлов тестовых сред.
Ну хорошо, а как быть с местом? Нужно избегать дублирования.
Тестовым средам нужны те же данные, что и лежат в бэкапах. Могут ли эти данные выполнять обе функции? Быть и бэкапом и основой для какой-либо привилегированной тестовой среды, которой необходим полный набор данных? Могут!
Oracle ZFS Storage Appliance — это массив, предоставляющий, в том числе и возможность формировать сетевые share, работающие под управлением файловой системы ZFS. В рамках файловой системы ZFS есть возможность создания снэпшотов, на основе которых можно разворачивать clones, которые видны как новые сетевые share. Используем эту возможность так:
- На ZFS Storage (так мы будем называть массив, чтобы не путать с файловой системой) создаются две share – в одну складываются Archivelog, а в другую – файлы базы;
- Share монтируется к серверу Oracle / Sun (который также является Appliance), а на самом сервере поднимается экземпляр Oracle Database, работающий как cascaded physical standby, – он получает логи с условно резервной площадки и применяет изменения к файлам, лежащим в share;
- Применение логов организовано по принципу workunit (привет всем участникам распределённых вычислений!). На уровне алгоритма введено понятие workunit, которому соответствует определённый интервал по времени. После наката логов за нужный интервал экземпляр останавливается, а в share остаются файлы, находящиеся в согласованном состоянии относительно друг друга и controlfile. По сути, это холодный бэкап, он же – Image Copy, поверх которого и делается снэпшот;
- Когда приходит время пересоздания тестовой среды, с нужного снэпшота создается клон. Он монтируется к серверу, на котором среда работает, после чего файлы в нём открываются как база под другим именем и в режиме Read / Write;
- В процессе работы в тестовой базе производятся изменения, которые откладываются в рамках клона, и он потихоньку растёт. К концу жизненного цикла среда вырастает до максимума.
- Чтобы потребление дискового пространства было ещё меньше – применяем LZJB-компрессию, которую ZFS Storage выполняет на лету.
В итоге:
- В нынешней конфигурации тестовые среды могут выполнять I/O до уровня 3.75 Гб/с;
Максимум для чтения пока ограничен существующими настройками портов InfiniBand на сервере, максимум для записи – CPU на контроллерах ZFS Storage и доходит примерно до 2 Гб/с. (Да-да! Т.к. 10 GbE оказалось мало, для тестовых серверов были куплены отдельные коммутаторы, в которые включены ZFS Storage и сами сервера); - В день создаётся несколько снэпшотов, которые сейчас хранятся, в зависимости от базы, от 2 недель до 2 месяцев. После чего они все удаляются, кроме тех снэпшотов, созданных в 00:00, 1-числа каждого месяца – эти хранятся уже больше квартала. Были случаи, когда полезными оказались снэпшоты, хранившиеся около полугода;
- При необходимости всю промышленную базу данных можно восстановить из нужного снэпшота. Так же со скоростью порядка 1 … 3 Гб/с., но намного популярнее вариант создания клона с нужного снэпшота, из которого потом и выгружаются данные нужных таблиц;
- Время пересоздания тестовой среды – около 1 часа (с переносом туда ряда дополнительных схем и т.п.);
- Время предоставления коллегам клона, из которого можно забрать данные для восстановления или просто какого-то анализа, – от 15 минут (при идеальном сочетании условий) до 1-2 часов (при большой параллельной нагрузке на ZFS Storage или нас J);
- При необходимости, можно восстановить из снэпшота и клона, и всю базу целиком;
- Главным ограничителем по производительности является число IOPS, генерируемых тестовыми средами или экземплярами cascaded standby. И тут система ведёт себя абсолютно адекватно и предсказуемо – как только их число подбирается к 75 IOPS на один HDD (в ней – 3.5” диски на 7200 rpm) при длительной нагрузке, то система начинает постепенно проседать. А небольшие по времени – заметно облегчаются Write- и Read-Flash;
- Число IOPS, общий объём поступающих данных, нагрузка на CPU, число чтений из кэшей в RAM и на Flash, а также ещё несколько десятков (если не сотен) метрик – можно посмотреть в веб-интерфейсе управления;
- С объектами ZFS Storage можно работать при помощи REST-запросов, описанных в документации. При их помощи и удалось автоматизировать удаление устаревших снэпшотов, а можно сделать и гораздо больше!
Комментарии (8)
Jump
18.07.2018 05:57Бэкап не может быть основой тестовой среды. там совершенно другие условия доступа, права, размещение.
alf-bi Автор
18.07.2018 11:12+2Разные тестовые среды используются для разных целей, разных процессов тестирования, разными коллегами. Оправданность размещения зависит от соотношения важности процесса и стоимости. Для ряда сред — это оправдано. «А вообще — вариантов много».
MrCleaner
18.07.2018 09:55При всём уважении… Какую цель преследовала эта первая и единственная статья в корпоративном блоге банка? Мы узнали что у вас есть Exadata с ZFS Storage, вы пользуетесь технологией snapshot и можете предоставить клон своей базы в течение 2 часов. Я ничего не пропустил? Неужели нет какого-то своего уникального опыта, личного мнения, просто приколов произошедших в рабочем порядке? Мы тут живые люди, мы не хотим читать рекламные буклеты, мы хотим видеть таких же живых людей за строками вашей статьи.
alf-bi Автор
18.07.2018 11:19Могу совершенно определённо сказать, что цели «открыть Америку» для всех и сразу — не ставилось, т.к. чтобы утверждать что опыт уникален, надо либо знать опыт всех остальных, либо быть очень наглым.
У нас есть описанная в заметке связка, мы используем её для ряда задач. Кому-то, возможно, это покажется интересным — или для похожих задач или для других, но использующих те же подходы.miffo
18.07.2018 11:47Молодая, красивая, умная, сексуальная, готовить умею, голова не болит! Никого не ищу, просто хвастаюсь!
Быть может у Вас найдется желание поделиться более подробной информацией об используемом решении, подводных камнях, сопутствующих ежедневной эксплуатации и способах их обхода?
Darka
Когда начал читать, думал что техническая статья. А оказалось маркетинг.
alf-bi Автор
Продажи Oracle от этой заметки — вряд ли как-то изменятся, а детали, если они будут кому-то полезны или интересны — можно уточнить. Выкладывать в заметку тексты скриптов, параметров монтирования шар и т.п. — смысла не имеет, иначе бы это было бы руководство, а не заметка.