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