По роду своей профессиональной деятельности мы довольно часто общаемся с заказчиками при проработке тематики мониторинга Центров обработки данных (ЦОД) и заметили одну особенность, которая показалась нам странной. Как правило, владелец ЦОД хочет, чтобы мониторинг следил за параметрами климата в помещениях, оборудованием электроснабжения и климатическим оборудованием. Ну и еще – показывал протечки. И на этом все, пожалуй.
Наш предыдущий опыт, в том числе и работы в эксплуатации крупного телеком-оператора, сильно протестовал. Для обеспечения надежной работы ЦОД этого явно недостаточно! В ЦОД (и около него) есть еще много всего, что может повлиять на его работу, и за чем нужен глаз да глаз. Но, с другой стороны, от проекта к проекту, для самых разных заказчиков повторяется одно и то же. И мы задумались – а как правильно?… Может перегибаем палку, преувеличивая опасности, и все намного проще?… И мы начали эту тему разрабатывать… Мы решили разобраться для себя, что же такое мониторинг, для чего он нужен, можно ли создать систему мониторинга, которая защитит от всего и как это сделать. И разобравшись, сделать из этого технологию.
Для начала мы обратились к первоистокам. Слово “монитор” имеет латинское происхождение и означало у древних римлян человека, напоминающего о чем-то, дающего на суде советы оратору или же предостерегающего о чем-то.
Потом заглянули в ITIL. ITIL считает, что цель практики мониторинга и управления событиями состоит в том, чтобы “систематически наблюдать за услугами и их компонентами, а также регистрировать и сообщать об отдельных изменениях состояния, определенных как события”. В принципе, похоже на римскую трактовку.
Но окончательную точку поставила Википедия. Определение в ней гласит “Мониторинг – система постоянного наблюдения за явлениями и процессами, происходящими в окружающей среде, результаты которого служат для обоснования управленческих решений”.
Итак, картина у нас сложилась следующая:
- для чего необходим мониторинг – для предостережения;
- какие задачи решает – регистрировать изменения и сообщать о них;
- для чего используется – для обоснования управленческих решений (и организации их исполнения, в том числе автоматизировано).
Следующим шагом мы задумались – а о чем таком должен предупреждать мониторинг? О явлениях какого рода нужно знать как можно быстрее и почему? Да, на ум сразу приходят различные неисправности и отказы оборудования, перегрузки каналов и систем, но есть ли какое-то универсальное правило, по которому можно выявлять такие явления?…
Ответ (для нас) нашелся в области экономики. Экономическая теория гласит (в упрощенном виде), что целью деятельности любого коммерческого предприятия является извлечение прибыли. И, очевидно, к событиям, о которых должен предупреждать “правильный” мониторинг, относятся все события, которые будут мешать извлекать эту прибыть, влиять на ее размер как в моменте, так и в перспективе.
Мысль эта принесла некоторую определенность, но все равно уровень абстракции все еще очень и очень высокий. Как рядовому инженеру понять, что из окружающей его технической реальности может влиять на прибыль? За чем смотреть чтобы понять, что прибыль под угрозой? Пришлось разбираться в экономике дальше. В итоге мы создали для себя вот такую логическую конструкцию.
Прибыль – это деньги, которые остаются от выручки предприятия после того, как будут оплачены все расходы на ее получение.
То есть прибыль будет уменьшаться когда будет падать выручка и/или расти затраты. Уже понятнее, но все равно что конкретно мониторить – не ясно. Нужно детальнее посмотреть на то, от чего могут измениться выручка и затраты.
Начнем с выручки. Грубо говоря, выручка – это деньги, полученные от коммерческой деятельности предприятия. То есть, применительно к сфере ЦОД – от услуг, которые ЦОД продал своим клиентам. Формулой это можно описать в виде суммы произведений числа услуг на их стоимость по всем клиентам. И к уменьшению выручки может привести уменьшение количества клиентов (просто у ЦОД стало меньше покупателей), уменьшение потребления услуг клиентами (число покупателей не изменилось, но покупать они стали меньше) и изменение тарифов (и пользователей столько, сколько было, и покупают они как раньше, но дешевле).
А от чего может уменьшиться количество клиентов? От того, например, что качество ваших услуг их не устраивает и они переходят к конкурентам. Или условия не устраивают. Или просто в силу экономических факторов клиенты стали беднее и не могут позволить себе ваши услуги.
С потреблением – та же история. На него влияет и уровень качества услуг, и их доступность, и появление на рынке услуг-заместителей, оттягивающих на себя часть клиентов, и те же экономические факторы, в силу которых клиент не может себе позволить потреблять как раньше.
И вот здесь уже начинают проглядывать вещи, понятные техническим специалистам, которые ответственны за мониторинг. Доступность услуг, качество услуг – вполне себе измеряемые параметры, организовать их мониторинг – задача хоть и непростая, но вполне себе инженерная.
Теперь про затраты. Если сводить их к арифметической формуле, то это – сумма произведений количества потребленных ресурсов на их стоимость по всем ресурсам плюс все накладные расходы, возникшие в ходе деятельности предприятия. Таким образом, к росту расходов могут привести увеличение стоимости ресурсов, объемов их потребления и накладных расходов в любых комбинациях.
На величину затрат на ресурсы влияют тарифы поставщиков и условия договоров на их поставку. Не совсем технические факторы, но находящиеся в зоне влияния. Потребление может вырасти из-за роста нагрузки, технических неисправностей, да просто из-за неоптимального устройства вашего ЦОД. И те же факторы влияют на накладные расходы.
И снова проявились аспекты, понятные техническим специалистам. Здесь и знакомые всем неисправности оборудования, и показатели нагрузки, и параметры процессов внутри ЦОД. Вещи вполне понимаемые и измеряемые, поддающиеся мониторингу.
Описанная модель, безусловно, упрощенная, но обозначает, с нашей точки зрения, направление для действий. При ее применении на практике нужно будет детальнее погружаться в деятельность конкретного ЦОД, но основная ее мысль останется неизменной – хороший, “правильный” мониторинг должен отслеживать и предупреждать все события, которые будут увеличивать расходы и/или уменьшать выручку. Предлагаю записать это на видном месте.
Хорошо, сказали себе мы. Что искать – более-менее понятно. Но вот где это искать? ЦОД – он же большой. И в нем очень много разных компонентов. Серверы, дизель-генераторы, кондиционеры и т.п. Одних кабелей – десятки километров, и все разные. С чего начинать?… На что обращать внимание в первую очередь, а чем заниматься потом?… Что имеет смысл включать в контур мониторинга, а что можно проигнорировать?… Снова нужна некая логическая структура, некое правило, которое позволит выработать решение в каждом конкретном случае.
В связи с этим, весьма полезной показалась нам идея ресурсно-сервисного подхода к описанию ЦОД. Подход видится простым и изящным, представляет систему через описание взаимосвязей ее компонентов. Для каждого компонента ЦОД описывается, какими сервисами, предоставляемыми другими компонентами, он пользуется и какие ресурсы, в свою очередь, предоставляет другим компонентам. К примеру, кондиционер в ЦОД использует ресурс “площадь”, предоставляемый компонентом “автозал”, и ресурс “мощность”, предоставляемый компонентом “электроустановка”. А предоставляет кондиционер сервис “холод”, который потребляют установленные в ЦОД компоненты “серверы”.
В соответствии с ней на самом верху пирамиды находятся приложения. Именно то, ради чего затевался ЦОД, для чего он существует, за что клиенты платят деньги. Но для того, чтобы работали приложения, им необходима ИТ-инфраструктура. Серверы, на которых работают приложения, хранилища с их данными, рабочие станции.
Но на одной ИТ-инфраструктуре, даже самой современной и мощной, приложения работать не смогут. Необходимо что-то, что объединит одиночные серверы в систему, обеспечит к ним доступ для администраторов и клиентов. Это – уровень сетевой инфраструктуры. Коммутаторы, маршрутизаторы, агрегация, вот это вот все.
Однако, только сетевой архитектуры снова недостаточно чтобы приложения заработали в полную силу (или даже не в полную). Необходимо это все где-то разместить, обеспечить комфортной температурой и влажностью, снабдить электроэнергией. Это – уровень инженерной инфраструктуры.
А еще все это необходимо защитить от лишних людей, от непогоды, обеспечить регулярное и бесперебойное поступление ресурсов из внешнего мира (вода, электроэнергия, газ и т.п.). Это уже – уровень ресурсов площадки. Как представляется, наглядно описанная конструкция показана на рисунке ниже.
О чем говорит этот рисунок? Нам, например, он говорит о том, что любой уровень структуры ЦОД опирается на все нижележащие уровни и не может работать без них. Без серверов не работают приложения, без транспорта – серверы и приложения, а без электричества не работает вообще ничего. Говоря по-другому, чем ниже уровень в этой модели, тем больше степень его влияния. А, следовательно, тем больший урон выручке он может нанести. И сильнее повлиять на затраты.
А еще рисунок указывает на то, с чего следует начинать организацию мониторинга ЦОД и куда нацеливать больше внимания. Хороший, “правильный” мониторинг нужно начинать с ресурсов площадки и инженерной инфраструктуры. Устанавливать тщательный и детальный контроль за ее элементами и только потом, взяв эти два уровня под надежное наблюдение, постепенно двигаться вверх по уровням модели, к транспорту, ИТ-инфраструктуре и приложениям. Если останется бюджет, разумеется…
Надеемся, после прочитанного вам стало понятнее, что именно (какие факторы) и где (в каких подсистемах ЦОД) следует рассматривать для организации “правильного” мониторинга. А вот способ как это делать, включая своего рода алгоритм рассмотрения, будет обсужден во второй части этой статьи. Продолжение следует!
