Представьте, что авария в ЦОД похожа на нераскрытое преступление, описанное в завязке хорошего детективного романа. Начитанные детективщики привыкли к тому, что в тексте книги будут содержаться все подсказки, которые могут понадобиться, чтобы собрать воедино цепочку событий и раскрыть преступление.
Ни одна база логов о событиях в ЦОД не является столь же интересной, как детективный роман, но она должна содержать все данные, относящиеся к причине аварии, которая, как показывает практика, может случиться в любом дата-центре.
Тем не менее, объем данных часто затрудняет выявление первопричины. С другой стороны, чем больше данных, тем выше вероятность того, что аналитическая система или даже алгоритм искусственного интеллекта (ИИ) обнаружит “виновника”.
Вопрос: сколько данных необходимо собрать из всех доступных источников, прежде чем удастся разработать не только способ определения “виновника”, но и формулу, которую можно использовать для эффективной диагностики ЦОД на предмет наличия проблем до того, как произойдет авария?
Путь к ответу может сводиться к тому, чтобы сначала определить, насколько много сходств существует между разными центрами обработки данных по всему миру. Чем больше сходств, тем проще строить модели. К счастью, уровень различий между дата-центрами, похоже, сокращается.
Паттерны и мотивы
Эту идею взяли на вооружение создатели Сети сообщений о происшествиях в центрах обработки данных (DCIRN или Data Center Incident Reporting Network), которую основали помимо прочего выходцы из компании Bloom Energy, изготавливающей топливные элементы для аварийного электроснабжения ЦОД.
Члены команды DCIRN отмечают, что, как и в случае любой другой развивающейся отрасли, индустрия ЦОД движется в направлении стандартизации. Основные компоненты, будь то системы охлаждения, системы электропитания или противопожарная защита – базируются, как правило, на одних и тех же решениях и технологиях. Архитектура (конфигурация и топология центра обработки данных, электрическая, механическая) может немного отличаться, но в конфигурациях прослаиваются общие черты.
Особенно четко общие черты прослеживаются в случае гипермасштабных ЦОД, проектировщики которых следуют определенным шаблонам. Поэтому такие дата-центры будут иметь больше общего между собой.
Корпоративные центры обработки данных – это отдельная история. Хотя они имеют по существу идентичные компоненты, эти ЦОД развертываются по-разному на разных площадках, и в каждом случае это происходит по разным причинам.
Миссия команды DCIRN состоит в том, чтобы воплотить в жизнь нечто вроде сети осведомителей для поиска улик, используемой детективами. Если организация сможет собрать достаточно данных о большом количестве параметров, подвергающихся мониторингу в течение длительного времени, корреляции, касающиеся определенного инцидента, которые в противном случае были бы упущены, могли бы в конечном итоге проявиться.
Во многих ЦОД уже сейчас осуществляется сбор данных о состоянии серверов и клиентских операционных систем, которые передаются производителю ОС. Обычно такой процесс происходит анонимно, представляя собой своего рода телеметрию.
Платформа DCIRN – это попытка создать систему телеметрии и отчетности для зданий, ресурсов и инфраструктуры, на которые опираются серверы при выполнении своих рабочих нагрузок. При этом команда DCIRN предпринимает определенные шаги для анонимизации собираемых данных.
Собрав достаточное количество данных, команда будет информировать партнеров об обнаруживаемых корреляциях между условиями работы центра обработки данных и аналогичными случаями аварий в ЦОД / потери данных.
В конечном счете, DCIRN сможет использовать аналитику в реальном времени применительно к поступающим данным, что позволит команде, применяя специальные алгоритмы, удаленно помогать в диагностике и устранении потенциально серьезных инцидентов, прежде чем ситуация начнет выходить из-под контроля.
Проект DCIRN очень молод. Работа только началась. Прежде чем команда разработает определенные аналитические инструменты, ее членам нужно создать базу данных. Пока в их распоряжении недостаточно зарегистрированных инцидентов, чтобы начать анализировать данные, организовывать их и разрабатывать инструменты, которые раскрывали бы важную информацию о проекте или архитектуре. Прямо сейчас можно говорить лишь о наборе инцидентов.
Какие инциденты следует учитывать?
Специалисты DCIRN используют термин “инцидент”, чтобы показать аномальное событие – нечто необычное, оказывающее ощутимое влияние на состояние ЦОД. В этом контексте следует отметить, что ранее в этом году организация Uptime Institute представила классификацию таких инцидентов: пятиуровневый Рейтинг серьезности отказов (OSR или Outage Severity Rating). Подробнее: Uptime Institute OSR – новая система ранжирования серьезности даунтаймов ЦОД
Первый уровень в системе OSR используется для описания событий, настолько минимальных по объему и влиянию, что они не заслуживают упоминания в прессе – даже в случае массовых аварий.
С другой стороны, в Uptime Institute признают, что каждый инцидент, оказывающий даже незначительное влияние на ЦОД, должен, по крайней мере, регистрироваться и классифицироваться, особенно если эта информация сможет быть использована при диагностике инфраструктуры для предотвращения более значимого инцидента в будущем.
Специалисты DCIRN признают, что система OSR – это не просто инструмент для оценки событий по факту. Данный инструмент можно использовать после гипотетического пожара в серверной стойке, который был потушен, чтобы оценить причины и последствия.
В конечном итоге этот инструмент позволит идентифицировать все возможные сценарии, которые могут произойти в центре обработки данных, оценивать влияние соответствующих индентов на компании и организовывать необходимые профилактические работы.
В свете всего вышесказанного нет ничего удивительного в том, что организация Uptime Institute является партнером команды DCIRN. Таким образом, есть шанс того, что OSR сыграет значительную роль при классификации инцидентов в ходе формирования базе данных DCIRN.
