Источник контента:5 февраля 2018 г. Ван Цзиньинь, генеральный директор Uwin Technology, выступил с речью на тему «Руководство по созданию моделей CMDB нового поколения» в статье «Как сломать игру в современных моделях CMDB — EasyTalk — выпуск 01». IT Dajiashuo (ID: itdakashuo), как эксклюзивный видео-партнер, имеет право публиковать видео после того, как организатор и спикеры просмотрят его.
Количество слов для чтения:3087 | 8 минут чтения
Резюме
Сегодняшняя тема, которую я предлагаю вам, — это руководство по построению модели CMDB нового поколения, которое в основном разделено на четыре части.
Дилемма: общие дилеммы, с которыми сталкиваются современные модели CMDB
Многие конструкции CMDB были построены на ранней стадии, а более позднее обслуживание постепенно уступило место разработке, эксплуатации и обслуживанию и превратилось в руины. Причиной отчасти мешают различные факторы самой системы, но больше вопрос методологического характера, я всегда думал, что нашел мощную движущую силу для построения процесса и сцены обслуживания ресурсов, но это было мое собственное принятие желаемого за действительное.
С точки зрения обычных отделов, отдел инфраструктуры центра обработки данных отвечает за построение конфигурации и управление ею, связанное с CMDB, но отдел ресурсов не заботится (и не может заботиться) о приложениях верхнего уровня, связанных с ресурсами. вообще. Вся проблема, кажется, зашла в неразрешенный переулок.
Так в чем проблема с моделью CMDB в отрасли сегодня? С какой точки зрения можно разобрать и проанализировать эти вопросы?
Сломать игру: правильный способ построить модель CMDB
Здесь я выступаю за построение CMDB по уровням и разделяю построение CMDB на уровне бизнеса и ресурсов, но должен сосредоточиться на построении CMDB приложения и обратить построение CMDB на уровне ресурсов.
Но мышление возникает из размышлений, начиная с фактического бизнес-сценария, как можно точно сопоставить реальный физический мир с модельным миром?
Как мы создаем модели, которые соответствуют всем реальным сценариям?Вы также думаете, что проектирование моделей CMDB так же просто, как проектирование таблиц базы данных? В чем разница между моделью CMDB, основанной на новых идеях, и предыдущей моделью CMDB? Что послужило причиной этого изменения?
Система: стандартная модель модели
CMDB — это система управления ИТ-ресурсами, которая может эффективно поддерживать и отражать занятые ресурсы запущенного приложения. Сервер, занятый приложением, — это ресурс, занятая память — это ресурс, занятое хранилище — это ресурс, а занятая балансировка нагрузки — это ресурс.
Но все должны обратить внимание на то, что этот ресурс больше представляет собой внутреннюю службу, такую как служба IaaS или служба PaaS.
На этом сеансе совместного использования предлагается стандартная структура модели IaaS, PaaS и прикладного уровня. Эта структура изменяет описание простых двумерных таблиц в прошлом и действительно отражает то, как должна выглядеть модель CMDB в соответствии с фоном большинства современных ИТ-систем.
Демонстрация: дедукция сценария применения модели
Конечно, на основе модели построения мы также проведем вывод каждого сценария CMDB, чтобы проверить адаптивность новой модели CMDB.
Более того, новое мышление в области управления эксплуатацией и техническим обслуживанием, предложенное на этот раз, доказало свою эффективность и результативность благодаря реализации многих проектов и обеспечило решение многих нерешенных проблем в прошлом. Ресурсы, близкие к бизнесу, обладают сильнейшей движущей силой.
Проблемы, с которыми сталкивается текущая модель CMDB
Проблемы модели с текущими базами данных CMDB
Сегодня многие модели CMDB по-прежнему сосредоточены на базовых ресурсах. Часть этого базового ресурса относится к управлению ресурсами уровня IaaS, а другая часть — к управлению ресурсами промежуточного программного обеспечения уровня PaaS. Когда дело доходит до приложения верхнего уровня, его модельное представление очень простое и содержит только некоторую базовую информацию о приложении.
Вторая проблема, которую необходимо решить, — это перспектива без приложений. Сегодня мы создали и управляем таким количеством объектов-ресурсов, но не знаем, для кого они предназначены, ведь основное внимание уделяется приложениям. Это я резюмирую как отсутствие понимания прикладного уровня.
Модель не очень динамичная. Когда каждый объект модели корректирует свои атрибуты или отношения, характеристики технической стороны в традиционных базах данных являются особенно дорогостоящими. Я разделяю динамизм модели на два измерения: первое — это динамизм между объектами модели на уровне CI, а второе — уровень экземпляра.
Четвертая проблема — дизайн переходов между сценами. Я думаю, что сцены можно предустановить, но детализированные модели сопряжены с большим административным бременем. Иногда сцена считается слишком сложной, что приводит к особенно большой нагрузке на управление моделью. От простого к сложному легко, а от сложного к простому сложно.
Технологии ограничивают воображение. Эта модель, ограниченная возможностями самой технологии платформы CMDB, не может быть расширена.
Отсутствие мышления в области ИТ-архитектуры. Я говорю о бизнес-архитектуре, архитектуре приложений и инфраструктуре. Бизнес-архитектура также включает инфраструктурную архитектуру и архитектуру данных. После выяснения взаимосвязи между этими тремя можно выразить, какая существенная взаимосвязь возникает на каждом уровне архитектуры.
Скриншот системы CMDB
Правильный способ построения модели CMDB
Где новое поколение CMDB?
Новое мышление: прорваться через познание управления конфигурацией, что приводит к нечетким границам. Конфигурация меняется в сторону ИТ-ресурсов.
Новый подход: нажимайте CMDB сверху вниз, а не снизу вверх.
Новая модель: рефакторинг модели, который не может удовлетворить традиционная реляционная модель.
Новая технология: используйте новую технологию, новую функциональную архитектуру, переопределите функциональные границы.
Два типа использования метаданных CMDB
Модель CMDB, в конечном счете, предназначена для создания экземпляров данных и взаимосвязей, и правильное построение модели может обеспечить основу данных для изменяющихся сценариев.
Во-первых, это процесс ITSM, ориентированный на управление. На многих традиционных предприятиях CMDB по-прежнему необходимо предоставлять услуги поддержки данных для процессов ITSM.
Второй — это процесс DevOps для уровня выполнения. Для всего сквозного процесса доставки ИТ требуются полные метаданные, особенно на уровне приложений.
Архитектура CMDB делится на базовую архитектуру уровня ресурсов и архитектуру уровня ресурсов приложений. Архитектура ресурсов прикладного уровня интегрирует связанные ресурсы с приложением в качестве центра. Отношение между ресурсами и ресурсами называется топологией (топологией приложений, физической топологией).Существуют два способа управления ресурсами: ручное обслуживание и автоматическое обнаружение.Процесс представляет собой сложный сценарий и средства ручного обслуживания.
Пять принципов построения базовой CMDB
1. Разработанный для IaaS и PaaS, он может управлять всеми базовыми ресурсами.
2. Контроль состояния осуществляется за счет автоматизации процесса эксплуатации и технического обслуживания.
3. При обслуживании CI следует широко использовать автоматическое обнаружение вместо ручного обслуживания.
4. Информация о ресурсах должна предоставлять услуги для приложений верхнего уровня.
5. Должны быть удовлетворены потребности управления КИ в основных ресурсах.
Применение принципов CMDB для строительных газов
1. Обеспечить унифицированные возможности управления метаданными приложений, независимо от типа приложения.
2. Основным требованием является управление жизненным циклом приложений.
3. Сосредоточьтесь на приложении, а не на базовых ресурсах.
4. Создайте гибкие отношения с ИТ-ресурсами с точки зрения ресурсов приложений.
5. Обеспечьте поддержку унифицированного управления ресурсами, действиями и состояниями приложений.
6. На основе единой CMDB уровня базовых ресурсов.
7. Основной сценарий — непрерывная доставка.
Применение понимания иерархии модели CMDB
CMDB приложения представляет собой полное описание ресурсов, а ресурсы приложения делятся на ресурсы развертывания приложений, ресурсы службы и ресурсы действий.
Ресурсы развертывания — это ресурсы, от которых зависит развертывание приложения, и обычно также называемые локальными ресурсами, такими как хосты, пакеты и т. д.
Ресурсы службы — это ресурсы, от которых зависит выполнение приложений, обычно называемые дополнительными ресурсами (из 12factor), например интерфейсы службы приложений, ресурсы PaaS, зависящие от приложения, ресурсы приложения, зависящие от приложения, и т. д.
Действие сцены — это описание действия, прикрепленное к ресурсу, и метод управления ресурсом.
Стандартизированная структура для новых моделей
Структура ресурсной модели CMDB нового поколения
Основной принцип: ресурс может предоставлять услуги, но также зависит от связанных с ним ресурсов, поэтому необходимо принять решение с трехмерной моделью.
Аппаратная объектная модель уровня IaaS
Достаточно создать и описать их для каждого изображения, что является не чем иным, как атрибутами и отношениями.
Программно-определяемая объектная модель уровня IaaS
Как показано на рисунке выше, программно-определяемая объектная модель уровня IaaS состоит из трех уровней. Нижний слой на самом деле следует называть зависимыми работающими ресурсами, а хост — лишь одним из них.
Эти три уровня должны содержать службы, экземпляры компонентов и хосты. Какие запущенные экземпляры запускаются во время процесса запуска службы, и на каких хостах находятся эти процессы экземпляров, а хост расширяется до списка IP-адресов.
Существует два типа экземпляров компонентов, один из которых является собственным экземпляром, который создается пакетом приложения, необходимым во время работы программы. Одним из них является экземпляр зависимости, который должен создавать экземпляр зависимого компонента.
Самостоятельные службы — это способы, которыми службы, запущенные сами по себе, становятся доступными для внешнего мира. Зависимые службы — это те службы, которые также связаны со средой выполнения.
Этот метод выражения модели аналогичен объекту слоя PaaS.
Основные понятия объектной модели уровня PaaS
Убедитесь, что вы глубоко понимаете иерархические отношения между службами, экземплярами и хостами, а также точно выражаете разницу между компонентами и кластерами, такими как компоненты Mysql и кластеры Mysql.
Основные понятия объектной модели прикладного уровня
Объекты прикладного уровня также имеют глубокое понимание иерархических отношений между службами, экземплярами и хостами и должны быть точно выражены.
На сегодня это все, всем спасибо!
Q&A
Вопрос: Как описать виртуализированные ресурсы?
О: Сегодня мы накладываем и управляем объектами ресурсов виртуализации и физических машин. В таблицу объектов хоста добавляется поле, которое является хост-компьютером, и отличается только одно измерение.
В: Есть ли введение в диск и сеть?
О: Я рассматриваю диск и сеть как часть лежащей в основе IaaS. Описание части IaaS объекта CI на самом деле относительно простое. Например, жесткий диск классифицируется по размеру жесткого диска, информации о классификации и т. д., просто информация об оборудовании, ничего особенного. Сеть должна быть отделена и разделена на различные сети, такие как сетевые устройства, такие как доступ, агрегация и ядро, которые можно отнести к одной категории, а межсетевые экраны — к другой категории. С точки зрения сети необходимо обратить внимание на информацию о ресурсах.
В: Как приложение автоматически обнаруживается? Не могли бы вы подробнее рассказать об автоматическом обнаружении ресурсов?
О: Если прикладной уровень действительно хочет добиться автоматического обнаружения, он также должен полагаться на базу правил. Система, подсистема, компонент приложения, эти три названия на самом деле являются логической концепцией, которую может точно знать только человек. Если мы хотим связать информацию экземпляра о работе машины с компонентами приложения, которые мы записываем и понимаем в нашем мозгу, нам нужно полагаться на правила. Так называемые правила — это не что иное, как сортировка правил по некоторой информации, сканируемой экземпляром. Базовые ресурсы обнаруживаются автоматически, пишут интерфейс, если есть интерфейс, и запускают команду, если есть команда, ничего особенного. Потому что сложность автоматического обнаружения ресурсного слоя заключается не в его технологии, а в сложности собственной инфраструктуры