Итак, мы собираемся проводить консолидацию баз данных с помошью Multitenant (CDB). Для этого нам нужно посчитать сколько нам понадобиться ввода-вывода (I/O), памяти (Memory), и процессорных ресурсов (CPUs), учесть дополнительные расходы и каким то образом просчитать распределение ресурсов между PDB.
Простейший способ - сложить все ресурсы математически лишает смысла консолидацию: мы знаем что чем больше сервер, тем он стоит дороже.
Консолидация I/O
В общем случае россыпь маленьких серверов могла использовать каждый свою подсистему хранения. Чисто теоретически, ничего не мешает подключить всю эту россыпь к большому серверу - единственная проблема в этом случае, нам нужно чтобы на большом сервере хватило карт ввода-вывода и их пропускной способности (IOPS).
Конечно же ничего не мешает позвать специалиста по подсистемам хранения, чтобы он дополнительно посчитал нам экономику от консолидации Storage. Ну и полная магия наступает в результате использования Exadata - все старые storage просто выбрасываются -)
Итого, нам нужно получить картинку кол-ва IOPS вместе с block size от каждого маленького сервера и убедиться что один большой обладает достаточным кол-вом карт ввода-вывода, а подсистема хранения (если она новая) справиться с общим потоком IOPS. Замечание, Oracle считает что после миграции в multitenant кол-во требуемых IOPS снизится (см
ссылку, страница 5) - но я не понимаю за счет чего это могло бы произойти. Следующий момент, не все СУБД которые мы будет подключать к CDB будут требовать пикового IOPS одновременно - вполне возможно что тербования можно было бы снизить, но нужно помнить что 100 IOPS с блоком 8K <> 100 IOPS с блоком 1M. Именно поэтому существуют всякие хитрые storage tools которые умеют проводить консолидацию.
Что можно попробовать, так это собрать на одном графике iostat со всех серверов, но он даст нам среднюю длину записи ввода вывода, из чего сложно сделать вывод сколько каких IOPS реально было.
iostat -xkd
И далее r/s w/s дает соответсввенно количество операций чтения/записи а avgrq-sz * 512 bytes даст средний размер
Консолидация Памяти
С SGA мы ничего сделать не можем, просто как сложить все исходные SGA вместе. С PGA - поинтереснее, можно надеяться, что разным базам данных понадобиться память в разные моменты времени. Тут есть ограничение, что память не вернется в OS пока сессия не завершится (или не вернет память принудительно с помощью ?)
Забегая вперед - правильный расчет памяти оказывается критическим - дело в том, что нет возможности ограничить ее использование с помощью resource manager. Единственное что можно сделать в версии 12c - установить - PGA_AGGREGATE_LIMIT на уровне CDB что поможет избежать paging.
Для мониторинга свободного кол-ва памяти можно использовать vmstat (откуда, зная размер физической памяти и размер SGA можно вычислить размер занимаемые PGA) или напрямую из DBA_HIST_PGASTAT. Мы понимаем, что частота сэмплов тут ограничена скоростью AWR snapshot, но для оценки памяти этого вполне достаточно.
Консолидация процессорных ресурсов
Мы подошли к самому дорогому для нас вопросу в прямом смысле этого слова - от качества расчета процессорных лицензий будет зависеть цена вопроса. Что нам нужно - построить на одном графике загрузки CPU всех наших БД. Откуда взять загрузку CPU? Я категорически против того, чтобы брать их из AWR - только vmstat с частотой сэмплов 1 сек. Многие вообще не видят как можно сэкономить процессорные ресурсы при консолидации - 'ведь и так понятно, что все системы загружены одинаково: примерно с 10 утра до 12, и дальше после обеда с 14 до примерно 16 часов. До 100% доходит, жаловались мне. Надо складывать кол-во процессоров - другого выхода нет'.
На помощь может прийти математика (если вы ее считаете наукой) и практика.
Если у вас есть набор нормальных распределений (а мы считаем нагрузку CPU подчиняющуюся законам нормального распределения) и средняя нагрузка 5%, а пиковая 37%, то для того чтобы 95% времени удовлетворять SLA нам нужен сервер эквивалентный 21% от текущего. Далее, еще одна магия, из центральной предельной теоремы следует, что при сложении N нормальных распределений суммарное стандартное отклонение растет как квадратный корень из N.
Простыми словами, можно сложить до 9 нормальных распределений (как в абзаце выше) пока будет достигнут 93% загрузка сервера.
Это была математика. На практике таких фантастических результатов у меня не получалось, но в два-три раза снизить требования к кол-ву ядер при консолидации 8-12 различных нагрузок вполне реально. Я считаю очень важным посмотреть в реальные цифры загрузки процессора из vmstat. Это очень много меняет в понимании загрузки систем и как они поведут себя, когда будут работать совместно.
Дополнительные расходы (overhead)
Красота Multitent в том, что мне не приходят в голову откуда бы им взяться. Это важное преимущество над виртуализацией.
Но есть другой момент - если вы складываете нагруженные системы, с большим кол-во блокировок и латчей, не могут ли они помешать друг другу?
Alex Fatkilin
показал, что по крайне мере для Result Cache, латчи шарятся между различными PDB. Я не успел проверить, но я считаю что есть вероятность, при сложении различных БД с высоким уровнем конкуренции усугубить это проблему.
И наконец, распределение ресурсов между PDB - ведь некоторые из БД, которые вы консолидируете могут оказаться важнее других. До 12.1 существовала возможность Instance Caging - вы могли гарантировать своей БД столько cpu сколько ей одной было нужно. С приходом Multitenant (CDB) Instance Caging сохранился, но применяется только если у вас несколько CDB на одном хосте. Для PDB рекомендуют использовать новые интерфейс Resource Manager.
dbms_resource_manager.create_cdb_plan_directive (plan = 'mycdb_plan', pluggable_database = 'mydb', shares = 16, utilization_limit = 66);
Что это значит: вы назначаете каждой PDB ее вес (shares). Сумма весов может быть любой, важно соотношение весов между PDB - у кого больше shares тому больше и дадут процессорного времени. Чтобы как то ограничить PDB, используют utilization_limit - это жесткий лимит, ни при каких условиях данная PDB не сможет использовать больше 66% процессорных ресурсов всего сервера.
Схема кажется рабочей, хотя мне было бы приятно сказать - вот этой БД 4 ядра, выделенных, всем остальные пусть как хотят живут в пуле других 8 ядер.
Подробности конфигурации resource manager в MOS
1567141.1.
Как вы видите, все несложно, посчитать ресурсы, которые вы складываете, все аккуратно сложить вместе и настроить Resource Manager. Остается сделать небольшое заключение (следующий пост)
Сообщения
