Alfa Bank Oracle Cloud Day 2015. CloudControl 12c Configuration Control
- 1. Контроль конфигураций ПО Oracle через Cloud Control 12c Алексей Жуков Михаил Марголин
- 2. Управление интеграционных систем (УИС) - сопровождение промышленных сервисов Банка. Кто мы
- 4. Проблема Контроль выполнения внутренних стандартов системного сопровождения (Data Guard Broker Enabled, AWR snap interval = 10 min, db_cache_size и т.д.) Соблюдение требований внутренних регуляторов (требование ИБ o7_dictionary_accessibility = false) ‘Зоопарк’ систем контроля параметров (Bash скрипты, Whats UP Gold, HP OpenView) Высокая трудоёмкость по изменению стандарта настроек системного ПО Следствие Нарушение требований по доступности промышленных сервисов из-за расхождения конфигураций Высокие затраты персонала на настройку и контроль параметров Нарушение требований внутренних регуляторов
- 5. Предложение Выбрать единое ПО для организации портала контроля конфигураций – Oracle Cloud Control 12c Фокус: контроль параметров БД Oracle и серверов приложений Web Logic. Разработку решения и его внедрение выполнить совместно с Oracle ACS.
- 6. Compliance Standarts vs. Metric Extension Compliance Standards: ? информация из репозитария CC; ? отсутствует информация о STANDBY БД; ? нет возможности индивидуальных порогов отклонения; ? нет генерации alert при нарушении отдельных правил. Metric Extension: ? сбор информации: SQL к таргетам, PL/SQL, SHELL, WLST; ? индивидуальные пороги для метрик; ? alert при нарушении отдельных правил.
- 9. SQL запрос к репозиторию Cloud Control SELECT alrt.target_name "TARGET", alrt.metric_label "METRIC LABEL", alrt.column_label "COLUMN LABEL", alrt.current_value "CURRENT VALUE", CASE WHEN c.warning_threshold IS NOT NULL AND c.warning_threshold != ' ' THEN c.warning_operator || ' ' || c.warning_threshold ELSE 'NOT SET' END AS "WARNING IF", CASE WHEN c.critical_threshold IS NOT NULL AND c.critical_threshold != ' ' THEN c.critical_operator || ' ' || c.critical_threshold ELSE 'NOT SET' END AS "CRITICAL IF", alrt.collection_timestamp "DETECTION TIMESTAMP", (SELECT MAX(collection_timestamp) FROM MGMT$METRIC_DETAILS d WHERE d.metric_name = c.metric_name AND d.target_name = c.target_name AND alrt.metric_column = c.metric_column) "LAST CHECKING TIMESTAMP" FROM MGMT$ALERT_CURRENT alrt -- в MGMT$METRIC_COLLECTION нет METRIC_GUID JOIN MGMT$METRIC_COLLECTION c ON alrt.target_guid = c.target_guid AND alrt.metric_name = c.metric_name AND alrt.metric_column = c.metric_column WHERE alrt.metric_name IN (SELECT metric_name FROM MGMT$TEMPLATE_METRIC_SETTINGS WHERE template_guid = (SELECT template_guid FROM MGMT$TEMPLATES WHERE template_name = 'ALFA-BANK Configuration Best Practices for Oracle Database' AND target_type = 'oracle_database')) AND alrt.target_name IN ('clouddb', 'clouddbr') ORDER BY target, "METRIC LABEL"
- 10. BI Publisher – отчетность
- 11. Q & A?
Editor's Notes
- 70 систем в промышленной эксплуатации; 20 систем непрерывного функционирования 24х7;
- Традиционный формат взаимодействия с поддержкой: ?Ошибка ORA-600 в БД ХХХ, что делать?? Новый формат взаимодействия: ?Есть проблема расхождения конфигураций основной и резервной БД, какие возможности и инструменты существуют для контроля параметров??
- Политики OEM Compliance Standards 1) Доступны сразу после установки OEM 2) Хорошая интеграция с CC: нарушение политики конфигурации показывается на главной странице ОЕМ или системы 3) Система не имеет возможностей сбора любой информации. Она основана на той информации, которая собирается в репозитарии и на нескольких правилах, которые входят в программу агента 4) Одним из ограничений сбора информации является отсутствие сбора информации о параметрах standby database, что затрудняет проверку соответствия параметров заданным политикам конфигурации 5) Правила жёстко задаются при их создании. Нет возможности их переопределить на конкретной системе. 6) События при нарушении отдельных правил, входящих в стандарты, не генерируются. Система оповещения может быть связана только с событиями, которые генерируются при уменьшении уровня соблюдения стандарта ниже 80% (предупреждение) и 60% (критический уровень) Расширение метрик OEM Metric Extentions Используются для оперативного мониторинга системы Отсутствуют по умолчанию 3) Требуется знание способа сбора данных по мониторингу нужного параметра. Нет ограничений на способ сбора информации, возможно использовать sql-запросы к целевым базам данных или к репозитарию, использовать shell-скрипты, скрипты WLST и т.д. 4) Можно задавать два промежуточных порога значений наблюдаемой величины: а. предупреждающий б. критический 5) Предупреждения о превышении порогов выводятся на главной странице системы в ОЕМ. При нарушении порога предупреждения генерируется событие. При нарушении критического порога на основе события генерируется инцидент. С событиями и инцидентами можно связать систему оповещений, которые будут рассылаться по указанным каналам оповещений. 6) Настройки порогов нарушения метрик и расписания сбора данных, собранных в Monitoring Templates можно переопределять на каждой конкретной системе.
- +
- +
- +
- +
- +