— А у нас есть какой-нибудь снимок за январь, ближе к февралю?
— Сейчас посмотрим… Да, есть! Сейчас откроем.
Бывает так, что есть среднее время жизни тестовой базы, есть согласованное всеми заинтересованными время жизни снэпшотов, но какая-то из сред слишком долго «засиживается» на своём снимке, который никак не удаляется… а потом он оказывается полезен коллегам. И минус на минус даёт плюс.
Обычно для любых систем, в которых может что-то происходить, требуется формировать бэкапы. А если она ещё и развивается и дорабатывается, то где-то также разворачивать среды разработки и тестирования. Причём для бэкапов и сред тестирования, которые работают, по сути, с теми же данными, нужно немало места. А ещё эти среды надо как-то приводить к актуальному состоянию. И всё это требует аппаратных и временных ресурсов.
В нашем случае, эти потребности покрыли 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-запросов, описанных в документации. При их помощи и удалось автоматизировать удаление устаревших снэпшотов, а можно сделать и гораздо больше!
Автор: alf-bi
