oracle database 12c подключает вас напрямую к...

Передовые методы консолидации

Oracle Database 12c подключает вас напрямую к облаку

Т Е Х Н И Ч Е С К АЯ П У Б Л И К АЦ И Я O R AC L E | Д Е К АБ Р Ь 2 0 1 4

КОНСОЛИДАЦИЯ БАЗ ДАННЫХ С ПОМОЩЬЮ ORACLE DATABASE 12C

Заявление об ограничении ответственности

Ниже представлена общая информация о направлении развития продукта. Документ может

быть использован только в ознакомительных целях и не предназначен для составления

какого-либо договора. Он не содержит обязательств по поставке каких-либо материалов,

программного кода или средств и не должен использоваться для принятия решения

о покупке. Разработка, релиз и время выхода на рынок всех упомянутых компонентов

и функций для продуктов Oracle остаются исключительно в компетенции корпорации Oracle.


Содержание

Краткий обзор ....................................................................................................................................... 1

Путь к корпоративному облаку ............................................................................................................ 2

Стандартизация уменьшает сложность .......................................................................................... 2

Консолидация уменьшает затраты и повышает управляемость ................................................... 3

Консолидация с Oracle Database 12c .................................................................................................. 5

Ключевые преимущества Мультиарендной Архитектуры .............................................................. 5

Выбор модели консолидации .............................................................................................................. 7

Выбор подходящего уровня изоляции ............................................................................................ 8

Изоляция и ее влияние на консолидацию ...................................................................................... 8

Консолидация подключаемых баз данных ...................................................................................... 9

Консолидация БД ........................................................................................................................... 11

Консолидация множества контейнерных баз данных .................................................................. 13

Консолидация схем ........................................................................................................................ 14

Проектирование облачного пула ...................................................................................................... 15

ЦП ................................................................................................................................................... 15

Память ............................................................................................................................................ 17

Хранилище...................................................................................................................................... 18


Комплементарные нагрузки .............................................................................................................. 19

Oracle Enterprise Manager 12c — пакет Cloud Management Pack .................................................... 21

Инструмент Consolidation Planner .................................................................................................. 21

Консоль провизионирования баз данных ...................................................................................... 22

.

1 | КОНСОЛИДАЦИЯ БАЗ ДАННЫХ С ПОМОЩЬЮ ORACLE DATABASE 12C

Краткий обзор

Как правило, ИТ-организации развертывают отдельные базы данных и приложения на выделенную серверную инфраструктуру для поддержки своих отделов или направлений бизнеса. Однако сегментированное предоставление технологической инфраструктуры для различных нужд бизнеса приводит к тому, что она используется не в полном объеме. Также это влечет неэффективное применение административных ресурсов, управляющих такими развертываниями. Кроме того, такие изолированные развертывания снижают способность ИТ-организаций быстро реагировать на изменяющиеся потребности бизнеса.

Чтобы разрешить эти проблемы, компании обращаются к частным корпоративным облакам, которые обеспечивают экономию и гибкость развития бизнеса. Движение к облачной модели вычислений включает в себя несколько стадий. Один из ключевых шагов на этом пути — консолидация, которая позволяет организациям достичь более высокой эффективности деятельности. Это возможно благодаря повышению степени загрузки ресурсов, а также снижению капитальных и операционных затрат. Ключ к достижению такой экономии — стандартизация и сокращение количества разнородных сред, которыми надо управлять.

Oracle Database 12c предоставляет значительные преимущества при консолидации прикладных нагрузок. Среди них можно выделить следующие.

1. Упрощенное управление, то есть сокращение числа уникальных сред, требующих отдельного контроля, управление многими ресурсами как одним.

2. Оптимизированные провизионирование и установка обновлений.

3. Простота консолидации без внесения изменений в приложения.

Далее мы рассмотрим эти возможности подробнее и покажем, как Oracle Database 12c помогает провести консолидацию и ускоряет переход к облачным вычислениям.


Путь к корпоративному облаку

Иногда можно услышать заявление, что облачные вычисления — это синоним консолидации. Но это не так! Консолидация — это краеугольный камень облачных вычислений, но корпоративное облако предлагает гораздо больше.

Перспективы облачных вычислений, такие как улучшение гибкости, снижение рисков и сокращение затрат, вполне реальны. Но реализация этих перспектив зависит от выбранного вами подхода. Oracle предлагает современные, гибкие и защищенные облачные продукты и услуги, которые помогут удовлетворить все потребности вашего бизнеса и в полной мере реализовать преимущества облачных вычислений.

Полный переход на использование корпоративного облака может занять несколько лет. Это отразится на многих аспектах работы, включая организацию, роли, процессы, политики и оказание услуг. Во многих предприятиях такой переход был организован поэтапно согласно особому маршруту. В этом маршруте представлены конкретные шаги, каждый из которых вполне достижим и обеспечивает ощутимые преимущества. Так что, какой бы темп и какую конечную цель преобразований ни выбрала организация, с самых первых шагов она получит ощутимые преимущества.

Рис. 1. Путь к корпоративному облаку

Oracle Database 12c рассчитана на обеспечение работы корпоративного облака. Эта база данных реализует новые функции, необходимые для достижения успеха на каждом этапе пути. Более подробно о данном поэтапном подходе смотрите в публикации Oracle «Путь к корпоративному облаку».1

В этой публикации в первую очередь рассматриваются этап консолидации и преимущества, которые обеспечивает Oracle Database 12c. Кроме того, мы уделим внимание стандартизации, а также выявим выгоды из-за уменьшения сложности.

Стандартизация уменьшает сложность

Стандартизация принципиально важна для успеха внедрения корпоративного облака.

Задача этапа стандартизации — обеспечить переход от индивидуальных уникальных развертываний к развертываниям с высокой степенью стандартизации. Необходимо, чтобы большинство запросов на выделение сервиса можно было выполнить с помощью нескольких стандартизированных сервисов.

1 http://www.oracle.com/technetwork/database/database-cloud/journey-to-enterprise-cloud-wp-1959164.pdf

Сложная Простая Эффективная Гибкая Единая

http://www.oracle.com/technetwork/database/database-cloud/journey-to-enterprise-cloud-wp-1959164.pdf


Важно понять существующую разрозненную и изолированную ИТ-среду и все ее компоненты и затем найти возможности упростить и стандартизовать: компоненты инфраструктуры (аппаратное и программное обеспечение), сервисы, процессы и поставщиков.

Одно из ключевых преимуществ стандартизации — уменьшение разнообразия сред, которыми вы управляете. За счет этого снижаются накладные затраты на администрирование. В большинстве случаев стандартизация позволяет экономить на операционных затратах (OpEx). Масштаб экономии будет зависеть от того, насколько эффективно вы стандартизируете свою среду.

На этом этапе Oracle Enterprise Manager 12c предоставляет инструмент планирования консолидации (Consolidation Planner).

Стандартизованные сервисы — создание «строительных блоков»

Основной результат этого этапа — определение минимального каталога стандартизованных сервисов, которые будут поддерживать большую часть запросов от бизнеса. Стандартизованный сервис — это простой в поддержке базовый «строительный блок». Его можно комбинировать с другими стандартизованными системами для создания бизнес-сервисов более высокого уровня.

В следующем примере стандартизованных сервисов в крупном финансовом учреждении определяются сервисы баз данных уровней «Платиновый», «Золотой» и «Серебряный».

Уровни обслуживания Silver OLTP Gold OLTP Platinum OLTP Platinum OLAP Platinum OLTP+OLAP Высокая доступность Высокая доступность ВМ Двухузловой кластер Кластер 2N + 1 Кластер 2N + 1 Кластер 2N + 1 Часы поддержки Только рабочие часы Дополнительные

рабочие часы 27/4 27/4 27/4

Целевая точка восстановления после сбоев

Нулевая потеря данных Нулевая потеря данных Нулевая потеря данных Нулевая потеря данных Нулевая потеря данных

Требуемое время восстановления после сбоев

2 раб. дн. менее 4 часов менее 4 часов менее 4 часов менее 4 часов

Производительность Не определено Опр. минимум

Выделенная среда для тестов производительности



Восстановление состояния на определенный момент времени

1 еженед. + ежедн. доп. копирование

1 еженед. + ежедн. доп. копирование + журналы обновлений

Управление данными за прошедшие периоды

Управление данными за прошедшие периоды

Управление историческими данными

Типичная сфера применения Приложения в подразделениях

Применение в направлениях бизнеса

Обработка транзакций предприятия

Корпоративное хранилище данных

Аналитика в прибл. к реал. Времени

Рис. 2. Стандартизованные сервисы, предлагаемые крупным финансовым учреждением

Обратите внимание, что, несмотря на более высокую эффективность стандартизованных сервисов, есть возможность выбрать настраиваемые сервисы в случае, когда они необходимы.

Приведенный выше пример — один из нескольких, изученных нами. После выявления общих закономерностей и вариаций в реальной практике создания облаков мы решили создать каталог стандартизированных сервисов для Oracle Database в частных облаках. Мы воспользовались опытом клиентов, лучшими практиками работы Oracle, а также результатами наших наблюдений и представили четыре вида сервисов для Oracle Database2. Клиенты могут принять эти рекомендации как есть или адаптировать их, чтобы быстро создать основу для развертывания базы данных как услуги с помощью модели каталога сервисов.

Консолидация уменьшает затраты и повышает управляемость

Часто решение о консолидации возникает как следствие других инициатив, вызванных сокращением затрат. К ним может относиться и общекорпоративная зеленая инициатива, связанная с уменьшением энергопотребления, снижение капитальных расходов за счет повышения утилизации имеющегося оборудования, снижение операционных расходов: энергопотребление, пространство, администрирование.

Все эти цели достижимы с помощью хорошей стратегии консолидации. Однако можно достичь намного большего, если рассматривать консолидацию как построение платформы, на которой можно будет развернуть корпоративное облако.

2 http://www.oracle.com/technetwork/database/database-cloud/private/service-catalogs-for-dbaas-2041214.pdf

http://www.oracle.com/technetwork/database/database-cloud/private/service-catalogs-for-dbaas-2041214.pdf


Консолидация баз данных может стартовать как основной драйвер бизнес инициативы. Для многих заказчиков результат консолидации — экономия на затратах, как первоначальных, так и текущих — это все, что они хотят. Однако, когда консолидация будет достигнута, а практики, поддерживающие этот подход в будущем, внедрены, это не должно быть конечной целью. Консолидация наряду со стандартизацией ИТ-среды и предлагаемых в ней сервисов — это только начало.

За ними последует дальнейшее сокращение затрат. Благодаря консолидации ваших сервисов баз данных3

на совместно используемой инфраструктуре возрастет утилизация этой инфраструктуры и сократится количество требуемого серверного оборудования. Консолидируя стандартизованные сервисы баз данных в совместно используемой среде, можно дополнительно повысить степень утилизации оборудования. Также появляется возможность существенно сократить затраты на управление благодаря уменьшению числа отдельных сред, которыми необходимо управлять. При этом снижаются как капитальные, так и операционные затраты. Меньшее потребление электроэнергии, меньшая площадь для центра обработки данных и снижение затрат на управление ИТ — это лишь часть примеров экономии.

3 Сервисы базы данных представляют группы приложений с общими характеристиками, уровнями сервиса и приоритетами. Сервисы базы данных позволяют одному образу системы управлять конкурирующими приложениями и контролировать каждую нагрузку как отдельную единицу. Сервис базы данных может работать на одном или нескольких экземплярах Oracle Database, на многих базах в глобальном кластере. Один экземпляр базы данных может поддерживать несколько сервисов базы данных.


Консолидация с Oracle Database 12c

В Oracle Database 12c добавлены функции, которые упрощают консолидацию баз данных.

До выпуска Oracle Database 12c наивысший уровень консолидации реализовывался при использовании консолидации схем. Однако, чтобы гарантировать бесперебойное сосуществование приложений в модели с консолидацией схем, требуется составить тщательный план. Необходимо исключить коллизии имен схем, подтвердить сертификацию пакетных приложений и т. д. Консолидация схем далеко не всегда является простой задачей, а доработка приложений с целью выявления и исправления нарушений может оказаться сложной, дорогостоящей или вовсе невозможной. Конечно, у консолидации схемы есть свои преимущества, но для многих клиентов они практически недостижимы.

В Oracle Database 12c появилась новая архитектура, которая существенно упрощает консолидацию многих приложений в общей среде баз данных, снимая все ограничения, которые ранее возникали при консолидации схем. Новая архитектура называется мультиарендной и позволяет развертывать контейнерную базу данных (Container Database, CDB), которая может содержать одну или несколько подключаемых баз данных (pluggable database, PDB).

Oracle Multitenant — это новая опция для Database 12c Enterprise Edition, которая помогает клиентам сократить затраты на ИТ с помощью упрощения консолидации, оптимизации провизионирования, реализации функций более быстрого обновления и миграции. И это лишь небольшая часть новых возможностей. Улучшения в опции Advanced Security Option защищают консолидированные среды без ущерба для их производительности. Консолидация выделенных сред в подключаемые базы данных внутри Oracle Real Applications Cluster (RAC) контейнерной базы данных повышает их доступность. Также достигается гибкость, необходимая для быстрого удовлетворения постоянно меняющихся потребностей бизнеса.

Ключевые преимущества Мультиарендной Архитектуры

Высокая плотность консолидации. Множество подключаемых баз данных в одной контейнерной базе данных совместно используют ее память и фоновые процессы. Благодаря этому на одной серверной платформе можно использовать намного больше подключаемых баз данных, чем при развертывании выделенных одноэкземплярных баз данных. Эти преимущества похожи на те, что предоставляет консолидация схем. Однако следует отметить, что мультиарендная архитектура устраняет все препятствия, мешающие воспользоваться консолидацией на основе схем: коллизии пространств имен, совместно используемые схемы или пользователи, а также устраняет постоянные эксплуатационные проблемы, возникающие при этом подходе.

Оптимизированные провизионирование и клонирование с помощью SQL. Подключаемую базу данных можно отсоединить от одной контейнерной базы данных и подключить к другой. Вместо этого также можно клонировать подключаемую базу данных как внутри ее контейнерной базы данных, так и между контейнерными базами данных. Эти операции, как и создание подключаемой базы данных, производятся с помощью новых команд SQL и занимают считанные секунды. Если нижележащая файловая система поддерживает тонкое провизионирование, множество терабайт может быть клонировано практически мгновенно, просто используя ключевое слово snapshot в команде SQL.

Новые парадигмы для быстрой установки исправлений и обновлений Патчирование одной контейнерной базы данных автоматически приводит к тому, что исправление применяется ко всем ее подключаемым базам данных. Чтобы применить исправление к только одной подключаемой базе данных, ее нужно просто отключить и подключить к другой версии программного обеспечения Oracle Database, где требуемый патч уже установлен.


Управление многими базами данных, как одной За счет консолидации имеющихся подключаемых баз данных администраторы могут управлять многими базами данных как одной. Например, такие задачи, как резервное копирование и аварийное восстановление, способны выполняться на уровне контейнерной базы данных.

Динамическое управление распределением ресурсов между подключаемыми базами данных Oracle Database 12c Resource Manager расширен специальными функциями, позволяющими моментально решать вопрос конкуренции за ресурсы между подключаемыми базами данных в контейнерной базе данных.

Улучшенные Доступность и Отказоустойчивость. Миграция базы данных на новую платформу, требующая ее остановки, может производиться быстрее за счет функций отключения/подключения (plug/unplug) подключаемых баз данных (PDBs). Переключение контейнерной базы данных со многими входящими в ее состав подключаемыми базами данных на резервную происходит быстрее переключения набора отдельных, выделенных баз данных.

Улучшенная безопасность Стоит отметить простоту конфигурации и отличную производительность всех основных функций безопасности, включая Oracle Database Vault, Transparent Data Encryption, Unified Auditing и Database Firewall. Oracle Database Vault, Unified Auditing и Transparent Data Encryption можно настраивать на уровне подключаемых баз данных.

Дополнительные данные о консолидации теперь будут предоставляться в разделах Oracle Multitenant, Advanced Security и Oracle Enterprise Manager 12c Cloud Management:


Выбор модели консолидации

Факторы, стимулирующие бизнес к консолидации, не учитывают требования конкретных приложений. Выбор приложений, которые можно разместить в общей среде, не всегда простая задача. Но если обратить внимание на несколько ключевых факторов выбора, можно реализовать преимущества консолидации для большинства приложений.

Перед тем, как продолжить, рассмотрим один важный момент. Консолидация не означает перемещение всех ваших баз данных в виртуальные машины. Виртуализация во многих случаях заменяет физические изолированные системы виртуальными изолированными системами. При этом сложность ИТ не уменьшается.

Как подключаемые базы данных решают проблему сложности ИТ

Согласно библиотеке инфраструктуры ИТ (ITIL), элемент конфигурации (CI) определяется как любой компонент, которым необходимо управлять для предоставления ИТ-услуги.

Представьте себе, сколько элементов конфигурации (CI) имеется в центре обработки данных с восемью базами данных, каждая из которых работает в своей собственной выделенной среде. Там находится восемь экземпляров баз данных Oracle, восемь образов операционной системы и восемь отдельных машин. Это 24 элемента конфигурации (CI), которыми надо управлять, отслеживать их состояние, устанавливать исправления и создавать их резервные копии. И это мы еще не берем во внимание степень средней загрузки (использования) этих активов. Ситуация отображена графически на рис. 3. Здесь восемь выделенных баз данных, каждая из них выполняется в собственной изолированной системе.

Рис. 3. Восемь выделенных сред баз данных

На рис. 4, представленном ниже, восемь выделенных баз данных были консолидированы в единой Oracle RAC контейнерной базе данных, работающей на двухузловом кластере. Эта контейнерная база данных содержит восемь подключаемых баз данных, и на каждом из экземпляров открыто, например, четыре подключаемых базы данных. В данном примере количество элементов конфигурации (CI) уменьшено до 14: восемь подключаемых баз данных, два экземпляра баз данных-контейнеров, два образа операционных систем и два узла, что существенно сокращает число управляемых компонентов.

В дополнение к этому, хотя и требуется контролировать только 14 элементов конфигурации (CI), но резервное копирование и патчирование производятся на уровне контейнерных баз данных, а это означает, что требуется управлять еще меньшим числом компонентов CI.


Рис. 4. Oracle RAC CDB база данных с восемью PDB базами данных, на каждом экземпляре открыто по четыре PDB базы

данных

Выбор подходящего уровня изоляции

Требования к изоляции между отдельными арендаторами серьезно влияют на выбор метода консолидации и в значительной мере определяют максимально возможную достижимую степень консолидации. Когда речь заходит об общем доступе и совместном использовании ресурсов, изоляция и гибкость становятся антонимами. Но существует компромисс между общими средами, которые обеспечивают лучшую гибкость, снижают административные накладные расходы и улучшают утилизацию ресурсов, и между более высокой изоляцией, уменьшающей проблемы безопасности и количество факторов, которые надо учитывать при консолидации приложений (например, консолидация приложений может повлиять, на то, когда можно делать обновление базы данных).

Общая рекомендация такова: проводить изоляцию только при необходимости, чтобы соответствовать требованиям изоляции арендаторов для конкретного развертывания. Обычно требования к изоляции связаны с выполнением нормативов, установленных государством или уполномоченными органами. Также они могут быть следствием ограничений версии базы данных или операционной системы.

Изоляция и ее влияние на консолидацию

Изоляция может быть физической или логической. Она рассматривается в контексте вопросов, связанных с неполадками, безопасностью, ресурсами и эксплуатацией.

Рис. 5. Совместное использование ресурсов более эффективно

Консолидация многих приложений в одной базе данных с помощью подключаемых баз данных, а также размещение нескольких баз данных на одной платформе или совмещение обоих этих подходов зависит от уровня изоляции, предусматриваемого вашей стратегией консолидации. В каждой модели консолидации вопрос изоляции решается по-разному. При этом используется комбинация функций Oracle Database 12c и операционной системы в сочетании с другими расширенными функциями и продуктами.

Инкапсулированная БД (БД внутри

виртуальной машины)

Обособленная БД


В данном разделе рассматривается изоляция арендаторов в частных облаках баз данных, сравниваются модели развертывания баз данных, схем и подключаемых баз данных.

Консолидация подключаемых баз данных

В этой модели приложения консолидируются как PDB базы данных, работающие в одной CDB базе данных. Можно настроить несколько CDB баз данных, чтобы каждая из них могла работать на одном или нескольких серверах в облачном пуле4. Единице гранулярности аренды соответствует PDB база данных.

Oracle Database 12c поддерживает до 252 PDB баз данных в одной CDB базе данных. Кроме того, в каждой CDB базе данных можно создать до 1024 динамических сервисов (Dynamic Database Service). Это дает на порядок большую экономию, чем консолидация выделенных баз данных на совместно используемой платформе, или консолидация баз данных с помощью отдельных виртуальных машин, консолидированных на совместно используемом сервере.

Рис. 6. Консолидация в мультиарендную архитектуру

На рис. 6 показана одна контейнерная база данных с пятью подключаемыми базами данных. CDB база данных работает в кластере Oracle RAC. Доступ к каждой из подключаемых баз данных внутри CDB осуществляется через связанный с ней сервис (воронки соответствующего цвета), предоставляемый на одном или многих экземплярах.

Изоляция отказов

Отказ приложения в отдельно взятой PDB базе данных не затронет другие PDB базы данных в той же самой CDB. Действия приложения ограничены только той PDB базой данных, с которой оно соединяется.

Изоляция ресурсов

Изоляция ресурсов касается размещения и разделения системных ресурсов.

4 Облачный пул обозначает набор серверов с общим хранилищем и общей частной сетью. Таким образом, облачный пул может быть Oracle Clusterware кластером или пулом виртуальных серверов. Частное облако представляет собой агрегацию облачных пулов.


Если на одном узле активно несколько CDB баз данных, то ресурсы, за которые будет происходить конкуренция, включают ЦП, память и ввод/вывод. Под вводом/выводом имеется в виду как емкость хранилища, так и количество операций ввода/вывода в секунду. При подходе к консолидации баз данных следует помнить следующее.

Память. Задавайте соответствующие значения MEMORY_TARGET и MEMORY_MAX_TARGET для отдельных экземпляров, но обратите внимание, что эти значения должны быть согласованными для всех экземпляров одной и той же базы данных. MEMORY_TARGET не ограничивает жестко размер PGA. Настоятельно рекомендуется не перерасходовать ресурсы памяти. При консервативном подходе рекомендуется выделять не более 75% доступной памяти для всех баз данных на одном узле. На оборудовании Exadata:

OLTP: SUM of CDBs (SGA_TARGET + PGA_AGGREGATE_TARGET) + 4 MB * (Maximum PROCESSES) < Размер физической памяти на каждом узле базы данных

DW: SUM of CDBs (SGA_TARGET + 3 * PGA_AGGREGATE_TARGET) < < Размер физической памяти на каждом узле базы данных

ЦП. Задайте соответствующие значения с помощью параметра CPU_COUNT или включите арретирование экземпляра (instance caging)5. Рекомендуется использовать последний метод, так как при арретировании экземпляра задействуется план распределения ресурсов менеджера ресурсов Database Resource Manager (DBRM). Он позволяет лучше контролировать потребление ресурсов ЦП.

Мультиарендная архитектура расширяет функциональность Resource Manager, позволяя плану на уровне CDB управлять распределением ресурсов между PDB базами данных. Рекомендуется использовать в профиле Resource Manager параметр UTILZATION_LIMIT при консолидации приложений. В случае ограничения ресурсов пользователи приложений, которые изначально работали в слабо населенной CDB базе данных, не ощутят изменения производительности, когда туда будут добавляться дополнительные приложения.

Oracle Database Quality of Service Management (QoS Management) управляет общими ресурсами приложений и адаптирует конфигурацию системы так, чтобы обеспечить производительность работы приложений на требуемом бизнесом уровне.

Консолидация PDB баз данных в единую CDB базу данных может привести к росту числа клиентских сессий, направляемых на определенный узел или экземпляр. Большое число одновременных попыток подключений (шторм логинов, logon storm), вызванное, например, переходом на резервный узел или неправильно настроенным ПО промежуточного уровня, может затронуть другие консолидированные приложения. Шторм логинов будет проявляться как нехватка ресурсов, но в особо тяжелых случаях он может привести к задержкам активации процессов OS планировщиком и другим каскадным сбоям.

Минимизация последствий от шторма логинов требует соответствующей настройки пулов соединений ПО промежуточного уровня. Также необходимо обращать внимание на то, где именно предоставляются сервисы. Дополнительно можно настроить Oracle Listener, чтобы ограничить количество соединений в единицу времени.

Операционная изоляция

Минимизация влияния операций восстановления утерянных данных важна в PDB-модели, также как и минимизация влияния применения патчей и обновлений.

Управление многими базами как одной в случае PDB баз данных позволяет автоматически запускать процедуру резервирования для каждой CDB базы данных. При этом есть возможность восстановить каждую из PDB баз данных по отдельности. Операция восстановления PDB базы данных к состоянию на определенный момент времени не затрагивает работу соседних PDB баз данных.

В выпуске Oracle Database 12c Release 1 команда FLASHBACK для PDB баз данных недоступна.

Патчирование Патчирование баз данных в консолидированной среде включает в себя планирование применения патча и само фактическое применение патча. Здесь нужно исходить из того, что разовая и внеплановая установка патча неэффективна и не приветствуется. План установки исправлений, например Oracle Patch Set Updates (PSU), должен быть определен заранее, причем арендаторам следует подтвердить ознакомление с ним.

5 Дополнительная информация об арретировании экземпляра (Instance Caging) находится в разделе «Проектирование облачного пула»


С другой стороны, должна быть предусмотрена возможность применения разовых (one-offs) патчей, но необходимо оценивать влияние этих патчей на CDB базу данных в целом.

Если для одного или нескольких приложений (PDB баз данных) срочно требуется установка разового патча, то самым эффективным способом установки будет создание новой CDB базы данных c установленными требуемыми патчами и последующая миграция отдельных PDB баз данных в эту CDB, используя команды unplug/plug. Обратите внимание, что такой подход повысит сложность управления, но на короткий срок это может быть приемлемо.

Безопасность

В любой консолидированной среде подход, связанный с предоставлением минимума привилегий, окажется наиболее выгодным с точки зрения обеспечения безопасности. В большинстве случаев один Oracle Home будет обслуживать все базы данных, работающие на этом узле. Это означает, что у каждого пользователя ОС, входящего в группу DBA для данного Oracle Home, будет доступ SYSDBA ко всем экземплярам баз данных, работающих из этого Oracle Home. Такой подход дает больше возможностей управления, но могут возникнуть проблемы с безопасностью.

Поэтому рекомендуется следовать следующим лучшим практикам.

• Минимизировать возможности доступа к серверу баз данных. Разрешать доступ только через канал SQL*Net. • Использовать именные учетные записи для всех администраторов баз данных (DBA) и предоставлять sudo доступ

для выполнения привилегированных команд. • Создать общих пользователей для административных задач, которые распространяются более чем на одну PDB базу

данных.

o Общим пользователям не должны принадлежать объекты, за исключением тех, что необходимы для выполнения задач администрирования (определенные процедуры, например)

• Используйте роли для ограничения привилегий. Сохраняйте ограниченный доступ к ролям SYSDBA и SYSOPER. В

Oracle Database 12c доступны дополнительные административные роли для управления созданием резервных копий, Oracle Data Guard и ключами шифрования. Это роли SYSBACKUP, SYSDG и SYSKM соответственно. Используйте их там, где это уместно.

• Включите Oracle Database Vault, чтобы обеспечить разграничение ролей и управление доступом.

o Для E-Business Suite, Siebel и PeopleSoft доступны готовые Data Realms.

o Зашифровывайте неактивные данные

Консолидация БД

При использовании модели консолидации баз данных отдельные базы данных консолидируются на физических серверах, объединенных в облачные пулы. На каждом из серверов в пуле может располагаться один или более экземпляров баз данных Oracle.

При использовании Oracle RAC или Oracle RAC One Node базы данных наследуют высокую доступность благодаря дублирующим серверам. Чтобы обеспечить эластичность и масштабируемость, можно добавить дополнительные серверы в пул или ЦП, память, платы ввода-вывода в отдельный узел или экземпляр.

Несмотря на важность стандартизации, могут допускаться исключения из правил. В частности, возможно добавление более крупных (высокопроизводительных) узлов, а также формирование разнородных кластеров по отношению к конфигурации ЦП или памяти узла.


Единицей гранулярности в этом подходе к консолидации является база данных. Каждая база данных и связанный с ней экземпляр изолированы от других баз данных в том же пуле. Отказ отдельного экземпляра в общем случае затрагивает только этот экземпляр, даже, несмотря на то, что из одного Oracle Home могут работать и другие базы данных.


Тем не менее возможны ситуации, когда отсутствие отклика от одного экземпляра может привести к последствиям, затрагивающим многие экземпляры, как правило, когда требуется перезагрузка узла. Надлежащее проектирование приложений и реализация лучших практик позволяют ограничить последствия сбоя узла или экземпляра. В качестве примера можно привести использование динамических сервисов баз данных и пулов соединений в сочетании с функцией Fast Application Notification (FAN), которая позволяет приложениям более быстро реагировать на отказы отдельных компонентов, тем самым ограничивая негативные последствия.


Изоляция ресурсов касается размещения и разделения системных ресурсов. В модели с консолидацией баз данных к конкурирующим ресурсам относятся ЦП, память и ввод-вывод, под которым понимаются как объем хранилища, так и операции ввода-вывода в секунду.

• Память — задавайте соответствующие значения MEMORY_TARGET и MEMORY_MAX_TARGET для отдельных экземпляров, но обратите внимание, что эти значения должны быть согласованными для всех экземпляров одной и той же базы данных. MEMORY_TARGET не ограничивает жестко размер PGA. Настоятельно рекомендуется не перерасходовать ресурсы памяти. На оборудовании Exadata:

o OLTP: SUM of CDBs (SGA_TARGET + PGA_AGGREGATE_TARGET) + 4 MB * (Maximum PROCESSES) < Размер

физической памяти на каждом узле базы данных

o DW: СУММА БАЗ ДАННЫХ-КОНТЕЙНЕРОВ (SGA_TARGET + 3 * PGA_AGGREGATE_TARGET) < Размер физической памяти на каждом узле базы данных

• ЦП. Задайте соответствующие значения, используя параметр CPU_COUNT или включите арретирование экземпляра (instance caging).

Рекомендуется использовать последний метод, так как при арретировании экземпляра задействуется план распределения ресурсов менеджера ресурсов Database Resource Manager (DBRM). Он позволяет лучше контролировать потребление ресурсов ЦП.


Операционная изоляция гарантирует, что действия по управлению или обслуживанию базы данных или ее рабочей среды не затронут другие работающие в том же облачном пуле базы данных. К таким действиям относятся запуск и остановка экземпляров, установка исправлений, а также резервное копирование и восстановление.

Запуск/остановка

Обычно один или некоторое минимальное число Oracle Homes используется для всех консолидированных баз данных. Для каждого Cloud DBA (администратора облака) следует создать именованных пользователей. Затем эти пользователи должны быть добавлены в файлы паролей баз данных. Параметр REMOTE_LOGIN_PASSWORDFILE при этом следует установить в значение EXCLUSIVE. Именованным пользователям предоставляют роль SYSDBA. Поскольку для каждой базы данных предусмотрены отдельные файлы паролей, пользователи смогут получить привилегии SYSDBA только для той базы данных, которую они администрируют.

Патчирование

Аналогично консолидации с помощью PDB баз данных, патчирование баз данных в консолидированной среде предполагает планирование и последующее фактическое применение исправлений. Здесь нужно исходить из того, что произвольная разовая или незапланированная установка исправлений неэффективна и не приветствуется. План установки исправлений, например Oracle Patch Set Updates (PSU), должен быть определен заранее, причем арендаторам следует подтвердить ознакомление с ним. С другой стороны, должна быть предусмотрена возможность применения разовых (one-offs) патчей, но необходимо оценивать влияние этих исправлений на базу данных в целом.

6 Дополнительная информация об арретировании экземпляра (Instance Caging) находится в разделе «Проектирование облачного пула»


Наиболее эффективный способ установки исправлений — клонирование Oracle Home с применением исправлений и последующим переключением экземпляра базы данных на новый Home. В RAC средах должны использоваться поэтапные(rolling) патчи, если таковые имеются.

Изоляция безопасности

Аналогична той, что обсуждалась в разделе о консолидации подключаемых баз данных.

Консолидация множества контейнерных баз данных

На уровне баз данных описанные выше рекомендации по сайзингу и консолидации нагрузок БД подойдут и для консолидации множества CDB баз данных и выделенных баз данных в общих облачных пулах. Однако эти рекомендации по сайзингу следует дополнить информацией о количестве PDB баз данных на одну CDB и о том, сколько CDB и выделенных баз данных будет консолидировано в этих облачных пулах.

Общие рекомендации для консолидации баз данных определяются соглашениями об уровнях обслуживания (SLA), которые вы заключили со своими арендаторами облаков баз данных. На уровне инфраструктуры все сводится к сопоставлению этих соглашений SLA с облачными пулами, наиболее подходящими требованиям SLA. Сами облачные пулы должны быть построены с использованием стандартизованных аппаратных и программных компонентов. Их размер должен поддерживать предопределенную плотность консолидации и политики изоляции.

В качестве примера на рис. 7 показано развертывание облачных баз данных, в котором имеющийся пул серверов в облачном пуле разделен на три серверных пула. В них размещаются три CDB базы данных-контейнера, управляемые на основе политик 7. Каждая CDB в данном примере может иметь свою кодировку и свой набор патчей. Кроме того, такие базы относятся к разным направлениям бизнеса и могут иметь другие отличия.

Рис. 7. Консолидация баз данных с помощью Oracle Database 12c

Если перед вами стоит задача консолидировать контейнерные базы данных, рекомендуется заранее определить политики для каждой из них и обеспечить применение этих политик при провизионировании сервисов.

• Определите максимальное число PDB баз данных в одной CDB

• Определите максимальное число CDB баз данных или выделенных баз данных в облачном пуле

7 Управляемое политиками развертывание основывается на серверных пулах. Сервисы баз данных работают в пуле серверов либо в единственном экземпляре, либо равномерно распределяются по всем серверам, входящим в состав серверного пула. Базы данных развертываются в одном или нескольких серверных пулах, причем размер серверного пула определяет количество экземпляров баз данных в развертывании.


Строгое следование этим политикам во время развертывания обеспечит создание однородных сред. Именно для таких сред проще автоматизация и управление жизненным циклом.

Консолидация схем

В этой модели консолидированная база данных состоит из одной или нескольких схем приложений. Они работают на одном или нескольких экземплярах в облачном пуле. Клиенты, которые реализовали такой подход, обычно ограничивают число приложений (схем) двадцатью. Единицей гранулярности аренды является схема.


Отказ приложения в одной из схем не затронет приложения в других схемах. Шторм логинов или неправильно настроенное ПО промежуточного уровня могут затронуть много приложений. Чтобы ограничить эти негативные последствия, важно использовать правильно настроенные пулы соединений промежуточного уровня. Плохо написанный код в базе данных, например на PL/SQL, может повлиять на другие приложения, не относящиеся к нему. Поэтому тщательная проверка кода в ходе разработки и всестороннее тестирование перед развертыванием приложений крайне важны.


Управление ресурсами необходимо для консолидации схем. Инструмент Oracle Database Resource Profile Limits реализует базовый подход к ограничению использования ресурсов. Настройка ограничения ресурсов не дает пользователям выполнять операции, которые бы заблокировали систему и помешали выполнять операции другим пользователям. Обратите внимание, что ограничение ресурсов также может способствовать повышению безопасности. Оно гарантирует, что пользователи будут выходить из системы и не останутся подключенными в течение долгого времени. DBRM и управление качеством обслуживания (QoS) являются дополнением к ресурсному профилю (resource profile).

Приложения можно объединить в группы потребителей ресурсов с соответствующими директивами ресурсного плана DBRM. Этот план управляет распределением ресурсов, как-то: ЦП, ввод/вывод (в развертываниях Exadata) и параллельные серверные процессы — для групп клиентов.

Использование хранилища можно контролировать посредством квот табличных пространств.


Минимизация влияния операций восстановления данных — такая же важная задача операционной изоляции в данной модели, как и управление применением патчей.

Для обеспечения наиболее эффективного восстановления данных требуется тщательно продуманная политика резервного копирования. Метод резервного копирования должен учитывать степень гранулярности восстановления, подходящую для приложения. Типичный подход к резервному копированию включает создание резервных копий каждую ночь, а также экспорт отдельных схем с помощью Data Pump. Потерянные или удаленные данные можно восстанавливать с помощью метода Flashback — табличного, для запросов или транзакционного. Эта процедура восстановления меньше всего нарушает обычную работу систем. Если данные со временем ушли из области Flashback, для восстановления потерянных данных также будет полезен пакет по восстановлению отдельных таблиц из резервных копий.

Стоит также отметить, что способ установки исправлений аналогичен тому, что обсуждался для других методов консолидации.

Изоляция безопасности

Изоляция безопасности между схемами — один из наиболее важных аспектов их консолидации. Для ограничения доступа к данным можно использовать профили Oracle Database, но в большинстве случаев необходимо применять более строгие меры и политики обеспечения безопасности. Всегда защищайте неактивные данные с помощью шифрования, обеспечивайте гранулярный контроль доступа и проводите аудит безопасности. Эти практики предполагают использование Transparent Data Encryption, Database Vault Realms, а также Oracle Audit Vault и Database Firewall для управления аудитом во время работы.

Также можно порекомендовать предпринять следующие методы повышения безопасности.

• Ограничивайте SYSDBA, SYSOPER и SYSASM доступ. Там, где это требуется, используйте преимущества ролей

SYSBACKUP и SYSDG.


• Применяйте частные синонимы. Избегайте использования публичных синонимов. • Обязательно используйте надежные пароли для баз данных и установите соответствующие значения параметров

PASSWORD_LOCK_TIME и FAILED_LOGIN_ATTEMPTS Проектирование облачного пула

Начальный размер облачного пула зависит от типов размещенных приложений и их требований к мощности. В большинстве случаев частное облако состоит не из одного пула, а из нескольких облачных пулов меньшего размера.

Облачные пулы должны соответствовать следующим требованиям.

• Бизнес

o Для различных направлений бизнеса или подразделений создаются отдельные облачные пулы.

o Отдельные облачные пулы также нужны для разных уровней SLA,

регламентных требований или для тестирования и разработки.

• Функциональные

o Облачный пул создается для приложений, работающих сходным образом. Например, один для внутренних приложений, а второй — для внешних.

• Технические

o Необходимо предоставлять отдельные облачные пулы в зависимости от типа ОС, версии базы данных или требований к изоляции.

o Учитывайте также взаимодополняющий характер нагрузок. o Облачные пулы со сходными требованиями высокой доступности.

Обычно облачные пулы создаются для определенных конфигураций и поддерживают конкретные бизнес-требования. Это соответствует лучшим практикам — совместно размещать приложения со схожими требованиями соглашений об уровне обслуживания (SLA) в консолидированной среде. Однако, как правило, нецелесообразно совместно размещать критически важные и менее важные приложения в одном и том же облачном пуле.

Количество приложений, которые можно консолидировать, зависит от их размера, потребления ресурсов и соглашений об уровне обслуживания объединяемых приложений. Кроме того, следует задать пороговые значения использования системных ресурсов, которые будут определять мощность облачного пула.

При построении облачных пулов рекомендуется использовать стандартизованные модульные «строительные блоки». Многие клиенты приняли в качестве стандарта четырехузловые кластеры, обеспечивающие гибкость для размещения сервисов и роста нагрузки приложений. Также такие кластеры способствуют повышению доступности благодаря дополнительным возможностям для плановых приостановок работы и защиты от сбоев компонентов.

Ниже приведена конфигурация физических ресурсов.

ЦП

Начальный сайзинг ЦП будет зависеть от размещаемых приложений. Оставьте дополнительные 10% для операционных задач, таких как резервное копирование, или задач, выполняемых по расписанию, и еще 15% для нагрузки, перемещаемой с другого узла, в случае его отказа. Эксплуатация узлов в облачном пуле при75% загрузке ЦП обеспечивает хороший баланс между эффективностью использования и наличием резервов.


Рис. 8. Мощности ЦП

Развертываемой в облачном пуле базе данных, является ли она CDB или non-CDB8, должно быть выделено как минимум два ЦП. Этого можно добиться с помощью параметра CPU_COUNT, установите его в файле init.ora. Также рекомендуется воспользоваться функцией арретирования экземпляра (instance caging)9. Несмотря на то, что арретирование тоже устанавливается с помощью параметра CPU_COUNT, оно имеет дополнительное преимущество. С помощью Database Resource Manager можно определить ограничения использования ресурсов.

Арретирование используется для разделения использования ЦП по разным базам данных на одной и той же машине. Причем этими базами данных могут быть две и более CDB базы данных, non-CDB базы данных, а также произвольное сочетание и тех и других видов баз.

Секционирование и выделение избыточной мощности

Арретирование — это способ устранить конфликты за ресурсы ЦП между несколькими экземплярами базы данных, совместно использующими один и тот же сервер. Такой результат достигается с помощью установки максимального количества ЦП, которое могут использовать процессы, связанные с определенным экземпляром. Это относится и к CDB и non-CDB базам данных. Предусмотрено два подхода к определению максимального количества ЦП: секционирование и выделение избыточной мощности.

8 Обратите внимание, что термин non-CDB база данных обозначает архитектуру БД, уже знакомую тем, кто работал с Oracle Database 11g или ее более ранними версиями. Oracle Database 12c поддерживает как мультиарендную, так и non-CDB архитектуры.

9 Арретирование экземпляра подробно обсуждается в документе http://www.oracle.com/technetwork/database/focus- areas/performance/instance-caging-wp-166854.pdf


Секционированный ЦП

При секционировании ЦП агрегированное значение параметра CPU_COUNT по всем экземплярам базы данных на конкретном узле не превышает общего количества процессоров. Этот подход рекомендуется использовать для критически важных приложений. Он обязателен, когда требуется управление качеством обслуживания (QoS Management).

При данной конфигурации не возникают конфликты за ресурсы ЦП между экземплярами базы данных. Однако, если какой-либо экземпляр не использует выделенные ему ресурсы ЦП, то эти ресурсы остаются недоступными для использования в других экземплярах.

Следующую рекомендацию следует применять при секционировании ЦП. Она гарантирует, что ресурсы ЦП будут доступны для критически важных процессов, таких как Oracle Clusterware и его агенты, ASM и т. п.

SUM(CPU_COUNT) < 75% Общего количества ЦП

Выделение избыточной мощности ЦП

При выделении избыточной мощности сумма значений CPU_COUNT по всем экземплярам на узле может превышать количество процессоров. Выделение избыточной мощности обеспечивает эффективное использование ресурсов. Однако в то же время появляется риск перегрузки и дефицита ресурсов, если несколько баз данных окажутся интенсивно загруженными одновременно. Это, в свою очередь, приведет к падению производительности.

Выделение избыточной мощности подойдет для систем с некритичными приложениями, или для тестирования и разработки. Также этот подход будет уместен для всех баз данных, у которых нет жестких требований по соглашениям SLA. Не применяйте выделение избыточной мощности для баз данных с высокими требованиями к вводу-выводу или высокой интенсивностью транзакций.

Рекомендуется соблюдать следующее условие:

SUM(CPU_COUNT) <= 2x(Общее число ЦП)

Предоставление двойного количества всех ЦП основано на технологии гипер-трединга с двумя потоками инструкций ЦП на одно ядро. Следует проявлять осторожность при выделении избыточной мощности на системах, где соотношение ЦП и потоков выше двух, например, на системах Sun T4, в которых количество потоков может достигать 64 на один ЦП.

Базы данных, работающие на машинах Exadata Database Machine, можно настраивать с более высокой степенью избыточной мощности. Актуальные рекомендации см. в новейших публикациях Exadata Best Practice.

Кроме того, ограничьте максимальное число Parallel Query Server процессов значением меньшим или равным общему числу ЦП или потоков, умноженному на 20.

Память

Настройка памяти в облачном пуле может быть менее сложной задачей по сравнению с сайзингом ЦП. Не выделяйте чрезмерный объем ресурсов памяти.

Для существующих баз данных, которые должны быть консолидированы, определите требования к памяти SGA и PGA, используя отчеты AWR,V$SGASTAT/ V$PGASTA или EM Automatic Memory Advisor. Что касается новых приложений, то сделав базовый сайзинг памяти, задайте умеренные значения для MEMORY_TARGET и агрессивные значения для MEMORY_MAX_TARGET.

Ниже приведены общие рекомендации по определению объемов памяти.

После получения информации о SGA/PGA перед каждой миграцией или размещением в частном облаке оцените следующие параметры. Приложения OLTP:

SUM of databases (SGA_TARGET + PGA_AGGREGATE_TARGET) < 80% физической памяти в расчете на узел базы данных


Приложения DW/BI:

SUM of databases (SGA_TARGET + 3 * PGA_AGGREGATE_TARGET) < 80% физической

памяти в расчете на узел базы данных

Следует учитывать, что консолидация баз данных не обеспечивает эффективного использования памяти, поскольку для каждого экземпляра базы данных создаются собственные области SGA и PGA. Самой эффективной моделью использования памяти является консолидация подключаемых баз данных, когда в облачном пуле настраивается единственный большой экземпляр базы данных с консолидированной областью SGA.

Хранилище

Администраторы облачных баз данных перед консолидацией должны проверить текущее использование хранилища приложениями. Обособленные базы данных обычно получают больше пространства хранилища, чем для них требуется. Поэтому одна из основных задач — определение того, какая часть выделенного пространства фактически используется, иными словами, каково соотношение свободных и занятых данными частей хранилища. Если наблюдается избыточность выделенного пространства, то это может быть хорошей возможностью для консолидации пространства хранилища. Для этого рекомендуется применить Oracle Data Pump или любой механизм логического переноса данных. Администраторам баз данных следует изучить характер роста данных, используя EM 12c для оценки закономерностей роста объема хранилища и рассмотрения схемы в разрезе для каждого табличного пространства и файла данных. Кроме того, перед переносом приложений в частное облако их владельцам следует провести очистку базы данных от устаревших и ненужных данных. Это не только способствует повышению эффективности хранилища, но и уменьшает общую продолжительность миграции.

Количество операций ввода-вывода в хранилище за секунду — тот аспект, которому уделяется очень мало внимания в консолидированных средах. При планировании консолидации администраторы баз данных должны установить среднее и пиковое количество операций ввода-вывода в секунду для каждой консолидируемой базы данных или приложения.

Используйте отчеты AWR для сбора следующих показателей ввода-вывода.

IOPS = “physical reads total I/O requests” + “physical writes total I/O requests”

MBytes/s = “physical reads total bytes” + “physical writes total bytes”

Эти метрики позволяют определить пропускную способность хранилища, необходимую для поддержки приложения. Просуммируйте значения операций ввода-вывода в секунду (IOPS) или показатели, выраженные в Мбайт/сек, для всех узлов, если существующее приложение функционирует в архитектуре RAC.


Комплементарные нагрузки

Одной из важных предпосылок успешного развертывания базы данных в частном облаке является размещение исключительно комплементарных (взаимодополняющих) нагрузок. Низкая производительность в консолидированной среде, нарушения соглашений SLA и отказы могут возникать из-за сочетания антагонистических рабочих или нагрузок, не дополняющих друг друга.

При консолидации нагрузок убедитесь, что пиковая загруженность ЦП консолидированных нагрузок не превышает намного среднюю загруженность ЦП. Разность между пиковой и средней загруженностью должна быть как можно меньше. Это означает, что ресурсы ЦП используются в максимально возможной мере.

Отбор рабочих нагрузок для включения в консолидированную среду основывается на анализе изменений, которые новая рабочая нагрузка вносит в показатели пиковой и средней загруженности ЦП. Комплементарная нагрузка больше увеличит среднюю загруженность, чем пиковую, как показано на рис. 9. Оптимальным вариантом был бы рост средней загруженности при неизменной пиковой загруженности.

Рис. 9. Комплементарные нагрузки

При использовании нагрузок-антагонистов (рис. 10) пиковая загруженность увеличивается больше, чем средняя. Это означает, что процессоры остаются недогруженными в течение периодов низкой интенсивности использования. Нужно учитывать, что они должны быть доступными для пиковых загрузок.


Рис. 10. Антагонистические нагрузки

Средство тестирования Real Application Testing, RAT полезно для определения влияния, которое новые нагрузки окажут на имеющуюся систему.

RAT работает для всех подходов консолидации: базы данных, схемы, подключаемые базы данных и non-CDB базы данных. Нагрузки, захваченные в разных базах данных, можно воспроизводить одновременно с помощью Consolidated Database Replay. Это позволяет консолидировать несколько нагрузок, захваченных в одной или во многих системах, а затем воспроизвести их одновременно в одной тестовой системе. Использование Consolidated Database Replay поможет оценить, как консолидация баз данных влияет на производственную систему. С помощью данного инструмента можно выяснить, справится ли одна машина, например, Oracle Exadata Machine, с объединенными нагрузками от консолидируемых баз данных.

Возможность Workload Folding позволяет объединять нагрузки и воспроизводить их одновременно, а возможность сдвига по времени (time-shifting) позволяет выровнять пики нагрузок.

Дополнительные сведения о Real Application Testing можно найти в документе Oracle® Database Testing Guide 12c Release 1 (12.1).


Oracle Enterprise Manager 12c — пакет Cloud Management Pack

Oracle Enterprise Manager 12c — это продукт Oracle для интегрированного управления корпоративной ИТ-инфраструктурой и первое полное решение в отрасли для управления жизненным циклом облака. Бизнес-ориентированные возможности Oracle Enterprise Manager 12c позволяют быстро осуществлять настройку, поддержку облаков предприятия и традиционных Oracle ИТ-сред, а также управление ими, начиная с приложений и заканчивая дисками.

Пакет Oracle Cloud Management Pack для Oracle Database включает в себя функции управления всем жизненным циклом облака баз данных.

Инструмент Consolidation Planner

Для создания облака администратору необходимо знать, какие ресурсы есть в наличии и в каком объеме они используются. Enterprise Manager автоматически обнаруживает их инфраструктуру и топологию, и после помогает оценить текущие нагрузки в среде.

Затем администратор может воспользоваться планировщиком консолидации для прогона различных сценариев по перераспределению нагрузок в существующих системах или в новых средах, используя возможность «что, если» (what-if) анализа, и определить, произойдет ли в результате изменений нарушение условий SLA. Эти сценарии можно проверить как на интегральных системах, например Exadata, так и на другом стандартном оборудовании.

На выбор предлагается ряд вариантов консолидации. Выше мы уже отмечали, что можно проверить консолидацию на Exadata, а также в других физических или виртуальных средах. Планировщик консолидации также предоставляет советы по консолидации приложений на интегральных системах Exalogic.

Он предлагает пошаговый план миграции в корпоративное облако. Предоставляемые рекомендации относительно консолидации основываются как на технических, так и на, бизнес соображениях. Например, в них может учитываться архитектура процессоров, принадлежность к определенному направлению бизнеса, географическое расположение и стадия жизненного цикла.

Рис. 11. Планировщик консолидации EM12c


Консоль провизионирования баз данных

Данная консоль — это отправная точка всех действий по провизионированию баз данных. В ней отображаются сведения о шагах провизионирования, профилях, процедурах развертывания, а также информация о том, как начать работать с провизионированием.

Вы можете провизионировать контейнерные или подключаемые базы данных, а также non-CDB базы данных, существовавшие до Oracle Database 12c. Oracle Real Applications Clusters и Oracle RAC One Node Database можно провизионировать как для контейнерной базы данных, так и для non-CDB. Все эти базы данных могут быть провизионированы, используя шаблоны баз данных (database templates), установочные носители, другие базы данных, или профили провизионирования, позволяющие стандартизовать развертывания.

Начисление затрат

Начисление затрат (chargeback) позволяет распределять стоимость ИТ-ресурсов на персонал или те организации, которые потребляют эти ресурсы. Эту функцию можно использовать в ситуациях с выделенными ИТ-ресурсами. Однако она особенно полезна в случаях совместного использования ИТ-ресурсов, так как без какого-либо способа измерения и тарификации потребления у пользователей возникает тенденция использовать больше ресурсов, чем им требуется. Эта проблема особенно проявляется в облачных средах, где пользователи могут провизионировать собственные ресурсы посредством самообслуживания.

Начисление затрат помогает отслеживать использование важнейших для бизнеса ресурсов или метрики по объектам-потребителям, например центрам затрат. Это позволяет бизнесу предоставлять отчетность о начисленной плате за использование объекту-потребителю, тарифицировать расход ресурсов, направляя счета таким потребляющим сущностям. ИТ-отделы могут точно распределять расходы по бизнес-пользователям или подразделениям соразмерно с потребленными ими ресурсами.

Последние усовершенствования Cloud Control дают возможность учитывать потребление ресурсов Oracle RAC базы данных не только по экземплярам, но и по сервисам. Сервисы в Oracle RAC базе данных можно назначить разным центрам затрат, но все они должны быть назначены одному и тому же плану тарификации. Это хорошо согласуется с использованием подключаемых баз данных, так как любой доступ к PDB базе данных осуществляется через сервис.

Начисление затрат включает три базовые метрики, по которым рассчитывается потребление ресурсов: использование ЦП, объем памяти (ОЗУ) и пространство хранилища. Эти метрики составляют универсальный план тарификации, который можно применить к любому типу объекта, сконфигурированного для начисления затрат.

Использование модели учета потребления ресурсов (Metering) и начисления (или отображения, Showback) затрат дает значительные преимущества ИТ-пользователям и пользователям из различных сфер бизнеса.

• Поставщики и потребители понимают стоимость предоставляемых услуг и устанавливают

ответственность за потребление ресурсов.

• Учет потребления ресурсов обеспечивает понимание того, как используется среда, дает возможность внести усовершенствования в среду и ассортимент каталога сервисов.

• Начисление затрат выгодно для пользователей, так как они могут контролировать

собственные расходы на ИТ.


Быстрое провизионирование Oracle Home

Быстрое провизионирование Oralce Home (Rapid Home Provisioning, RHP) — это новая функция Oracle Grid Infrastructure Release 12.1.0.2, которая обеспечивает поддержку централизованного развертывания ПО. Программное обеспечение необходимо установить только один раз. Оно сохраняется на сервере RHP, а оттуда может быть провизионировано на любой узел или кластер в частном облаке столько раз, сколько необходимо.

При этом RHP:

• устранит необходимость в установке исправлений для отдельных баз данных

• позволит обновить любое число баз данных одной командой

• обеспечит стандартизацию с помощью версий золотых образов

Rapid Home Provisioning Server

Сервер Rapid Home Provisioning Server — это высокодоступная система провизионирования ПО. Rapid Home Provisioning Server служит центральным сервером для провизионирования Oracle Homes, делая их доступными для клиентов Rapid Home Provisioning Clients. При этом клиенты могут быть другими Grid Infrastructure кластерами или отдельными узлами.

Перечислим основные функции Rapid Home Provisioning Server.

• Эффективное хранение золотых образов для управляемых Oracle Homes, включая отдельные

двоичные файлы и метаданные, связанные с пользователями, ролями и правами. • Обеспечение экспортных точек высокодоступной файловой сетевой системы (HANFS) для того,

чтобы Oracle Homes были доступны через монтирование на удаленных кластерах. • Предоставление по запросу списка доступных Oracle Homes уполномоченным клиентам. • Позволяет патчировать ПО в Oracle Home один раз и затем развертывать этот Oracle Home на

любом Rapid Home Provisioning клиенте вместо установки патчей на каждом узле. • Возможность формировать отчеты по существующим развертываниям.

Дополнительная информация по Rapid Home Provisioning содержится в документе Oracle Clusterware Administration and Deployment Guide, 12c Release 1 (12.1)


Заключение

Oracle Database 12c играет полезную роль на каждом этапе вашего продвижения к корпоративному облаку и предоставляет наиболее эффективную платформу для консолидации стандартизованных сервисов баз данных.

Мультиарендная архитектура обеспечивает высочайшую плотность консолидации без накладных расходов, связанных с внесением изменений в код приложений и повышением безопасности контроля доступа. Стандартизация стала еще проще, чем когда-либо.

Подключаемые базы данных обеспечивают улучшенную гибкость для бизнеса, а новые возможности миграции и клонирования делают операции по сопровождению баз данных быстрее и проще. Задачи провизионирования могут быть оптимизированы.

Динамические отчеты теперь позволяют контролировать то, что администраторы и операторы приложений имеют только те привилегии, которые нужны для выполнения необходимых задач. Все встроенные возможности безопасности базы данных можно использовать на уровне PDB баз данных.

Oracle Database 12c — это идеальная платформа для консолидации и предоставления сервисов, которая может оптимизировать ваши бизнес-операции. Проводя консолидацию на кластерах Oracle Real Application Clusters, чтобы обеспечить гибкость и высокую доступность, предлагаемые Oracle RAC, а затем, комбинируя ее с новыми возможностями базы данных и Oracle Enterprise Manager 12c Cloud Control, вы можете ускорить ваш путь к реализации всех преимуществ облачных вычислений.

Консолидация баз данных с помощью Oracle Database 12c ноябрь 2014 г. Автор: Трой Энтони (Troy Anthony) Соавторы: Радж К. Кэмменд (Raj K. Kammend), Микаэль Тимпанаро-Перротта (Michael Timpanaro-Perrotta), Бернард Клоузе (Bernard Clouse)

Корпорация Oracle, головной офис Для запросов со всего мира 500 Oracle Parkway Тел.: +1.650.506.7000 Redwood Shores, CA 94065, USA Факс: +1.650.506.7200

СВЯЖИТЕСЬ С НАМИ

blogs.oracle.com/russia

facebook.com/oracle.russia twitter.com/oracleRU

oracle.com/ru

Hardware and Software Engineered to Work Together © Oracle и аффилированные компании, 2014. Все права защищены. Данный документ предоставляется исключительно в информационных целях, и его содержание может меняться без уведомления. Документ может содержать ошибки, на него не распространяются никакие гарантии или условия, выраженные устно или предусмотренные законодательством. Сюда включаются подразумеваемые гарантии, а также соображения о пригодности продуктов для определенной цели. Мы особо оговариваем, что не несем никакой ответственности в связи с данным документом. Документ ни прямо, ни косвенно не создает никаких договорных обязательств. Воспроизведение или передача этого документа в любой форме, каким-либо способом (электронным или физическим) и для какой угодно цели возможны только с предварительного письменного разрешения Oracle. Oracle и Java являются зарегистрированными товарными знаками корпорации Oracle и/или ее аффилированных компаний. Другие названия могут быть товарными знаками соответствующих владельцев. Intel и Intel Xeon являются товарными знаками или зарегистрированными товарными знаками компании Intel Corporation. Все товарные знаки SPARC используются по лицензии и являются товарными знаками или зарегистрированными товарными знаками компаний SPARC International, Inc. AMD, Opteron. Логотип AMD и логотип AMD Opteron — товарные знаки или зарегистрированные товарные знаки компании Advanced Micro Devices. UNIX — зарегистрированный товарный знак The Open Group. 1214

Разрабатывая свои программы и продукцию, корпорация Oracle заботится об окружающей среде.

oracle database 12c подключает вас напрямую к...

Documents