06.11.2020

Основы работы с базой данных RIPE

Данная статья задумывалась как отправная точка, которая поможет новичкам быстро вникнуть в суть работы с БД RIPE, чтобы в голове сложилась целостная картина и понимание, для чего в ней используются те или иные объекты. Отмечу, что данная статья дает только общее представление о работе с данной системой, не описывая детальные шаги, но тем не менее я надеюсь, что после прочтения вам будет легче разобраться в вопросе

Данная статья задумывалась как отправная точка, которая поможет новичкам быстро вникнуть в суть работы с БД RIPE, чтобы в голове сложилась целостная картина и понимание, для чего в ней используются те или иные объекты. Отмечу, что данная статья дает только общее представление о работе с данной системой, не описывая детальные шаги, но тем не менее я надеюсь, что после прочтения вам будет легче разобраться в вопросе.

Рано или поздно большинство сетевых инженеров сталкиваются с необходимостью взаимодействия с базой данных RIPE. Например, если вы устроились на работу в компанию, предоставляющую доступ в интернет, или организацию, которая владеет собственной автономной системой, то вам с 99%-ной вероятностью потребуется периодически добавлять/удалять и поддерживать актуальной какую-то информацию в БД RIPE. Даже просматривая вакансии при поиске работы, иногда можно наткнуться на требование «Умение работать с RIPE».

Также в ходе своей работы, решении каких-то задач или устранении неполадок, вам может потребоваться, например, следующее: узнать контактные данные технических специалистов, администрирующих блоки определенных IP-адресов, уточнить политику маршрутизации, которая применяется в соседней с вами автономной системе, или направить жалобу о неправомерном использовании IP-адресов, принадлежащих какой-то организации и т. д. Когда сталкиваешься с этими задачами впервые, можно немного растеряться. Так что умение работать с БД RIPE и понимание того, как найти в ней необходимую информацию – это полезный и нужный навык.

В ходе данной статьи я попробую ответить на вопросы: что из себя представляет БД RIPE? Какие функции она выполняет? Какие основные объекты используются на практике?

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

Начнем с определений:

1. IRR — Internet Routing Registry. Это глобальная распределенная база данных маршрутных политик. Задумывалась такая база как инструмент, с помощью которого операторы связи смогут делиться своими маршрутными политиками и информацией о том, какие сети и кому они анонсируют. В совокупности это должно способствовать большей стабильности работы сети Интернет, помогать инженерам при устранении неполадок, связанных с глобальной маршрутизацией. Также эта база может являться источником данных для различных программ, которые помогают автоматически генерировать конфигурацию оборудования на основании доступной там информации. IRR использует так называемый язык спецификации маршрутных политик (RPSL) для описания хранимых в ней данных. БД RIPE в том числе исполняет и функции IRR.

2. RPSL — Routing Policy Specification Language. Это язык, с помощью которого описываются маршрутные политики. Этот язык объектно-ориентированный, но к программированию он не имеет никакого отношения. По сути, он описывает классы объектов, а конкретные объекты в своих атрибутах содержат уже конкретную информацию. Например, есть класс aut-num, он описывает автономную систему: ее номер, какой организации принадлежит, к кому можно обратиться в случае проблем связности с этой автономной системой и т. д. Объекты, в свою очередь, являются кирпичиками, из которых состоит БД RIPE.

Подробнее про RPSL можно почитать тут:

https://www.rfcreader.com/#rfc2622

https://www.rfcreader.com/#rfc2650

Функции БД RIPE

Поддержание актуальной контактной информации

Интернет состоит из огромного количество связанных между собой сетей, автономных систем и людей, поддерживающих его работоспособность. Иногда вам может потребоваться узнать, кому принадлежит та или иная автономная система или блок IP-адресов, и как связаться с теми, кто за них отвечает. Вы не можете держать в своей записной книжке все эти контакты. БД RIPE – именно то место, где данную информацию можно оперативно найти.

Учет интернет-ресурсов

Под интернет-ресурсами здесь понимаются блоки IP-адресов и номера автономных систем. RIPE NCC, являясь одним из RIR, занимается распределением интернет-ресурсов и их учетом для Европы, Ближнего Востока и Центральной Азии. Информация о выделенных номерах AS, распределенных блоках IP-адресов и т. д. – все это учитывается и отображается в БД RIPE.

Публикация маршрутных политик

Как говорилось ранее, БД RIPE выполняет в том числе и функции IRR. Здесь, компании, владеющие своими автономными системами и блоками IP-адресов, могут публиковать свои маршрутные политики, тем самым делясь с остальными участниками информацией об их глобальной политике маршрутизации с внешним миром.

Обеспечение работы механизма DNS reverse lookup

БД RIPE играет ключевую роль в работоспособности DNS reverse lookup. Мы вернемся к этому вопросу позже.

Способы взаимодействия с БД RIPE

Необходимость взаимодействия с БД RIPE у вас может быть по следующим причинам: вы хотите найти какую-то информацию или вы хотите добавить/изменить/удалить какую-то информацию в ней.

Чтобы получить информацию из БД RIPE, можно воспользоваться сервисом whois прямо на сайте RIPE, либо одноименной утилитой, которая присутствует почти во всех дистрибутивах Linux.

Существует 4 способа добавить, изменить или удалить информацию:

1. Webupdates. Это самый простой и интуитивный способ работы с объектами. Вы просто заходите на сайт RIPE, авторизуетесь и с помощью веб-формы выполняете необходимые вам действия с объектами (при условии, что вы авторизованы это делать). Сам процесс выглядит так:

Шаг 1. Заходим в панель управления ресурсами, нажимаем «Create an Object», выбираем тип создаваемого объекта и нажимаем Create.

Шаг 2. В следующем окне заполняем обязательные поля и нажимаем Submit:

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

2. По электронной почте.

Вы отправляете письмо на специальный почтовый адрес auto-dbm@ripe.net, в теле письма полностью описываете атрибуты и значения объекта, который вы хотите добавить, изменить или удалить. Сейчас этот способ применяется редко, куда проще воспользоваться другими методами.

3. Syncupdates.

Этот способ позволяет работать сразу с несколькими объектами одновременно. Его можно использовать как в ручном режиме, так и с собственными скриптами. Подробно данный способ описан в официальной документации.

4. RESTful API.

Также работать с объектами в БД RIPE можно с помощью RESTful API. Данный способ удобно использовать для автоматизации каких-то действий с помощью скриптов.

Подробное описание API можно посмотреть тут.

Например, мы используем API БД RIPE следующим образом:

У нас есть IPAM система, в которой мы ведем учет всех наших IP-адресов. Когда нам необходимо выделить новую подсеть для клиента, то мы запускаем скрипт, который через API вытаскивает из IPAM первую свободную подсеть необходимого размера, далее через скрипт мы заполняем краткое описание назначения данной подсети. Затем скрипт с помощью API IPAM добавляет данную подсеть в базу IPAM, а с помощью API RIPE создает объект inetnum(6) в базе RIPE. Таким образом, нам не нужно самим заходить в IPAM, искать там свободную подсеть, затем заходить на сайт RIPE и создавать там новый объект вручную.

Общие свойства всех объектов

Как говорилось ранее, БД RIPE состоит из объектов. Каждый объект представлен двумя колонками: атрибуты (слева) и фактические значения (справа). Атрибуты всегда заканчиваются двоеточием «:».

Пример объекта, описывающего вымышленную организацию «Sandbox Inc.»:

Объекты имеют обязательные и опциональные атрибуты. Обязательные атрибуты должны присутствовать в каждом объекте соответствующего класса, например, атрибут «org-name:» в объекте «organisation» из примера выше. Некоторые атрибуты могут повторяться.

Для того, чтобы узнать, какие атрибуты объекта обязательные, какие опциональные, какие можно использовать повторно, а какие нет, можно воспользоваться запросом whois -t object_type:

Здесь видно, что атрибут «phone:» является обязательным для объектов типа «role», а атрибут «e-mail:» – опциональным и может повторяться.

Когда вы создаете объект с помощью webupdates, то обязательные атрибуты сразу же отображаются в веб-форме, вам их нужно просто заполнить. Если же вы будете использовать какой-то скрипт для обновления через API, то уже сами должны позаботиться о том, чтобы не забыть указать обязательные атрибуты и их значения. Для этого удобно использовать шаблоны. Например, так может выглядеть шаблон Jinja2, описывающий объект inetnum в формате:

JSON

Если вы о чем-то забудете, то при попытке добавить объект в БД RIPE вам вернется код ошибки с описанием причины, по которой операция не может быть выполнена.

Также некоторые атрибуты объекта являются ключами. По ключам осуществляется поиск объектов в БД RIPE. Существует 3 типа ключей:

  • Primary – уникальный ID объекта, однозначно определяет его в БД.
  • Lookup – ключи, по которым объект можно найти в БД.
  • Inverse Lookup – ключи, которые ссылаются на какой-то другой объект. Данный тип ключей используется, когда вы, например, хотите найти все объекты «route», которые зарождаются в какой-то AS. Для этого в запросе whois используется ключ -i. Пример:

Данный запрос находит все объекты класса «route», которые зарождаются в AS48399.

Найти объекты можно только по атрибутам, которые являются ключами, причем в параметрах поиска нужно указать точное значение атрибута. Например, атрибут «aut-num:» объекта «aut-num» является primary ключом. Если вы хотите найти объект «aut-num», который создан для AS48399, то вам нужно указать в запросе именно «as48399», варианты «48399» и «as 48399» не дадут должного результата:

Назначение объектов

Объекты по их назначению можно условно разделить на 5 групп:

  1. Контактная информация: person, role, organization.
  2. Интернет-ресурсы: inetnum, inet6num, aut-num.
  3. Маршрутизация, политика маршрутизации: route, route6, as-set, aut-num.
  4. Reverse DNS: domain.
  5. Безопасность объектов: maintainer.

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

Группа «Контакты»

Объект «person»

Служит для описания контактной информации конкретного человека, который так или иначе связан с какими-то интернет ресурсами. Другие объекты, например «inetnum», могут ссылаться на объект person в своих атрибутах «admin-c» или «tech-c». Таким образом вы можете узнать контактную информацию человека или группы, которые отвечают за те или иные ресурсы.

В примере выше представлен объект inetnum, который содержит информацию о том, что блок IPv4 адресов 80.12.176.0/22 был выделен организации Sandbox и что в случае возникновения каких-то технических вопросов, связанных с данным блоком адресов, вы можете обращаться к персоне Jean Blue.

Был забавный случай, когда у моего бывшего коллеги раздался неожиданный звонок и человек на том конце трубки, не выбирая выражений, угрожал ему физической расправой. Выяснилось, что ему нагрубил какой-то школьник в онлайн-игре и скинул ему свой IP, который он узнал по запросу «узнать мой IP адрес». Разумеется, школьник сидел за NAT. Наш хакер, недолго думая, вбил другой запрос «узнать кому принадлежит IP» и увидел контактную информацию моего коллеги, которая содержится в RIPE. Пришлось объяснять местному «Кевину Митнику», что это немного не так работает 🙂

Объект «role»

Похож на объект «person», но описывает уже контактную информацию какой-то группы, которая отвечает за определенную роль в организации. Такой группой может быть NOC. Объект «role» – это своего рода контейнер для объектов «person». Например, в организации работают 3 сетевых инженера, вы создаете группу NOC и в атрибутах «tech-c:» указываете ссылки на соответствующие объекты person.

Но также стоит отметить, что атрибуты «admin-c:» и «tech-c:» являются для «role» опциональными, поэтому данный объект может быть самодостаточным, т. е. не ссылаться на объекты «person».

Еще одной важной особенностью объекта «role» является наличие атрибута «abuse-mailbox:». В нем указываются контакты, по котором можно обращаться по вопросам злоупотребления вашими ресурсами. Например, если с принадлежащих вам IP-адресов рассылается спам, то вам скорее всего напишут именно по адресу электронной почты, указанному в данном атрибуте.

С практической точки зрения лучше использовать именно объект «role» вместо «person», особенно, если у вас много сотрудников работают с данными в БД RIPE. Почему? Дело в том, что если вы пытаетесь удалить какой-то объект, но при этом есть объекты, которые на него все еще ссылаются, то вам придется убрать все ссылки на удаляемый объект. А теперь представьте, что у вас 1000 объектов «inetnum», ссылающихся на объект «person», принадлежащий вашему коллеге, который собрался увольняться и больше не отвечает за данные ресурсы. Вам придется во всех 1000 объектах удалить ссылки на него. Кроме того, например, объект «organization» может ссылаться только на объект «role» в своем атрибуте «abuse-c:».

Объект «organization»

Во-первых, этот объект, как и объекты «person» и «role», содержит контактную информацию, но уже об организации, которая владеет интернет-ресурсами, например: юридический адрес, телефон и т.д.

Во-вторых, это своего рода контейнер, который связывает все ресурсы организации. Такие объекты, как «inet(6)num» и «aut-num», обязаны иметь атрибут «org:», который указывает на то, какой организации выделены данные ресурсы.

Группа интернет-ресурсов

Объект «aut-num»

Данный объект создается в базе после того, как RIPE выделит какой-то организации определенный номер AS. Он показывает, кому принадлежит AS, и контактную информацию, по которой вы можете взаимодействовать с теми, кто за данную AS отвечает.

В этом объекте вы можете публиковать свою маршрутную политику.

Для этого используются атрибуты «import:» и «export:», в которых вы указываете, от кого и какие маршруты вы принимаете и кому и какие маршруты анонсируете. Также операторы обычно описывают политику BGP community именно в этом объекте. Для наглядного примера попробуйте поискать в БД RIPE номера AS крупных операторов, например, as8359.

Чтобы лучше понять, как описывается маршрутная политика, рассмотрим следующий пример:

Допустим, что вы являетесь небольшим провайдером, у вас есть 2 аплинка и 3 клиента.

Аплинкам вы анонсируете свои сети и сети ваших клиентов, от аплинков принимаете full view.

Клиентам вы анонсируете full view, а принимаете только префиксы, которые им принадлежат.

Описание маршрутной политики при этом может выглядеть так:

Стоит отметить, что политика может описывать не только то, какие префиксы вы анонсируете или принимаете, но и более сложные сценарии. Например, вы указываете, что на какой-то префикс вы вешаете local preference 200. С помощью набора инструментов IRRToolSet вы можете автоматически создавать конфигурацию маршрутизаторов на основе информации, описанной в объекте «aut-num». Подробнее тут:

https://github.com/irrtoolset/irrtoolset

Объекты «inetnum» и «inet6num»

Являются одними из самых важных объектов в БД RIPE. Данные объекты содержат информацию о том, кому и как были распределены блоки IP-адресов. Когда RIPE выделяет вам какой-то блок iP-адресов, то в RIPE NCC создается объект «inetnum», указывающий, что этот блок выделен именно вам.

Когда вы далее выделяете из данного блока какой-то кусок под ваши нужды, например, из выделенной вам подсети /22 одну подсеть /24 вы используете под NAT, то вы также создаете объект «inetnum» и даете описание в атрибуте «netname:» – что-то вроде «NAT for users».

Важным атрибутом этих объектов является атрибут «status:». Основные статусы:

ALLOCATED-PA – RIPE NCC выделила блок IPv4 для какой-то организации.

ALLOCATED-BY-RIR – RIPE NCC выделила блок IPv6 для какой-то организации.

ASSIGNED-PA – организация выделила блок IPv4 для каких-то нужд.

ASSIGNED – организация выделила блок IPv6 для каких-то нужд.

Группа политика маршрутизации

Объект «route(6)»

Это также одни из самых важных объектов в БД RIPE, они связывают AS и зарождающиеся в ней префиксы.

Если вы анонсируете какой-то префикс в Интернет, то вам необходимо создать объект «route» для этого префикса.

Почему важно это делать? Многие провайдеры автоматизируют процесс генерации фильтров BGP, которые вешают на анонсы от своих пиров. Реализуется это, например, с помощью утилиты bgpq3, которая обращается в RIPE и автоматически на основании объектов «route» генерирует соответствующий кусок конфига для создания фильтров. Все те префиксы, которые не описаны в объектах «route», не попадут в конфигурацию, поэтому может возникнуть ситуация, когда из-за этого ваши сети не будут доступны извне. Вам придется обращаться в поддержку вашего аплинка, чтобы он разрешил на своем оборудовании принятие от вас данного префикса или же создать объект route для нового префикса и дождаться следующего запуска скрипта на стороне вашего провайдера.

Объект «as-set»

Это очень полезный объект, он помогает упростить процесс обновления маршрутных политик, которые описываются в объекте «aut-num». Объект «as-set» позволяет вам группировать различные AS в один объект. Вернемся к примеру:

Для аплинков у нас описана политика, что мы анонсируем им префиксы от AS500, AS1, AS2, AS3.

При каждом обновлении данной политики вам придется менять информацию для всех аплинков.

Но вы можете поступить иначе: создать объект «as-set» и в его атрибутах «members:» описать номера AS, префиксы которых вы анонсируете, тогда такая политика будет выглядеть так:

Все, что вам нужно будет делать, когда ваша политика меняется, это удалять или добавлять AS из объекта «as-set». Кроме того, атрибут members может ссылаться на другие as-set.

«As-set» часто используется для генерации фильтров. Скажем, клиент может вас попросить настроить фильтры в соответствии с их «as-set», тогда вы опять можете воспользоваться утилитой bgpq3, но указывать уже не номер AS в качестве аргумента, а «as-set». Например:

Объект «domain»

Как уже отмечалось ранее, БД RIPE играет ключевую роль в работе reverse DNS lookup.

В противоположность прямому DNS запросу, когда по доменному имени находится соответствующий ему IP-адрес (A запись), обратный запрос, наоборот, ищет доменное имя, которое соответствует IP-адресу (PTR запись). Зачем нужно отображать IP-адреса в доменные имена? В основном это используется как дополнительная защита от спама в электронной почте, также это помогает при устранении неполадок с помощью traceroute, т. к. если для IP-адреса существует PTR запись, то вместо IP в выводе traceroute вы будете видеть более информативные доменные имена.

Объект «domain» указывает DNS серверам RIPE на то, какой сервер отвечает за ту или иную обратную зону. Визуально это можно представить так:

Когда вы получаете какой-то блок IPv4 или IPv6 адресов от RIPE, то вы можете создавать объекты «domain». Например, вы получили блок IPv4 адресов 192.168.0.0/22. Тогда для данного блока вы можете создать объекты «domain», которые будут указывать на ваши DNS сервера, которые являются авторитативными для данных обратных зон. Важно отметить, что объект «domain» может быть создан только для /16 и /24 ipv4 подсетей, поэтому, если у вас есть блок /22, вам придется создать 4 объекта domain для 4х /24 подсетей и, соответственно, 4 обратные зоны на вашем DNS сервере.

Безопасность объектов

Объект «maintainer»

Теперь, когда мы разобрались с основными объектами, поговорим про безопасность. БД RIPE – это публичная база данных, поэтому очень важно запретить делать что-либо с вашими объектами всем неавторизованным пользователям. Краеугольным камнем в безопасности БД RIPE является объект «maintainer». Это своего рода замок, который вы вешаете на каждый объект, и открыть его может только тот, кто имеет от него ключи. Существует 3 типа таких ключей:

1. Single Sign On (SSO). Самый простой способ, вам просто нужно добавить в объекте «maintainer» атрибут «auth:» с указанием почты сотрудника, с помощью которой он авторизуется на сайте RIPE.
2. MD5 enrypted password.
3. PGP key.

Каждый объект в БД RIPE имеет атрибут «mnt-by:», который ссылается на объект «maintainer». Соответственно, если у вас есть доступ к данному «maintainer», вы можете работать со всеми объектами, которые им защищены.

Заключение

Данную статью я готовил на основе материала из официального курса от RIPE, который доступен по адресу https://academy.ripe.net. Если вы хотите лучше разобраться в вопросе и попрактиковаться на реальных примерах, то советую его пройти. Курс интерактивный, интересный и бесплатный.

Полезные запросы whois:

whois -t object_type – посмотреть шаблон объекта.

whois -T route -i origin ASxxxxx – узнать все маршруты, которые происходят из автономной системы.

whois -i mnt-by maintainer_name – узнать все объекты, которые защищены объектом «maintainer_name».

whois -M subnet – узнать, на какие более мелкие подсети поделена подсеть «subnet».

whois -L subnet – узнать, из какой более крупной подсети образована подсеть «subnet».

Полезные ссылки:

 

Другие новости и публикации

Вас также могут заинтересовать

Linx Outsourcing
Аудит, модернизация и оптимизация ваших серверных мощностей
Подробнее
Аутсорсинг управления дата-центром
Linx Network
Обеспечьте отказоустойчивость и бесперебойную работу сети
Подробнее
Сетевые услуги
Linx DraaS
Аварийное восстановление ИТ-инфраструктуры. Защитите ИТ-системы уже сегодня!
Подробнее
Аварийное восстановление DRaaS

Напишите нам

Как мы оптимизировали управление ЦОДами клиента

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

Тарас Чирков, руководитель ЦОД Linxdatacenter в Санкт-Петербурге 

Константин Нагорный, главный инженер ЦОД Linxdatacenter в Санкт-Петербурге 

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

В главной роли – управление 

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

Роль надежных и производительных дата-центров в современной экономике постоянно растет вместе с требованиями к их бесперебойной работе. Однако на этом направлении существует большая системная проблема.  

Высокий уровень «аптайма» – безаварийной работы дата-центра без простоев – очень сильно зависит от команды инженеров, которая занимается управлением площадки. А единой формализованной школы управления ЦОДами не существует.  

Нет какого-то сводного канона с правилами, применимыми для любого дата-центра. Есть стандарты международной отраслевой организации Uptime Institute, но они устанавливают рамки и вектор развития, к каждому конкретному дата-центру они будут применяться по-разному.  

В масштабах страны  

На практике в России ситуация с эксплуатацией ЦОДов выглядит так.  

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

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

Наконец, государственные ведомственные ЦОДы – в этом отношении они часто представляют собой неизвестную территорию в силу закрытости. Международный аудит таких объектов по понятным причинам невозможен. Российские госстандарты только разрабатываются.  

Все это выливается в ситуацию «кто во что горазд». «Разношерстный» состав команд эксплуатации из специалистов с разным бэкграундом, различные подходы к организации корпоративной архитектуры, взгляды и требования в отношении ИТ-департаментов.  

Факторов, приводящих к такому положению дел, много, один из главных – отсутствие систематизированной документации по выстраиванию эксплуатационных процессов. Есть пара вводных статей Uptime Institute, которые дают представление о проблеме и путях ее преодоления. Но дальше необходимо выстраивать систему своими силами. А на это ресурсов и компетенций хватит далеко не у каждого бизнеса.  

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

Кейс: через тернии к относительному порядку 

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

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

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

И здесь началось самое интересное.  

Познай себя 

Чтобы оценить уровень работы ЦОДов с точки зрения соответствия стандартам, нужно знать точные требования бизнеса к ИТ-системам: каков уровень внутренних SLA, допустимый период простоя оборудования и т.д.  

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

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

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

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

Улучшения в процессе 

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

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

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

Однако правильная оптимизация управления «инженеркой» ЦОДа предполагает выполнение задачи научить людей правильно оценивать процессы и писать под них уникальную документацию исходя из специфики конкретного объекта.  

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

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

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

Что сделано 

В процессе работ нам удалось решить несколько серьезных вопросов.  

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

Принцип «просто найти, просто понять, легко запомнить» дополнился тем, что новая информация привязывается к старому опыту и знаниям сотрудников. 

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

Но нас удивило легкомысленное отношение компании к своей ИТ-инфраструктуре: от отсутствия резервирования критичных систем до хаоса в структуре и управлении.  

За 1,5 года процессы управления инженерными системами были прокачаны до уровня, который позволил специалистам компании успешно отчитаться «за качество» перед аудиторами из головного офиса.  

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

Выводы 

В целом перспективы консалтинга в сфере операционного управления дата-центрами, по нашему мнению, самые яркие.  

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

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

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

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

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

Основы работы с базой данных RIPE

БЭСТ, оператор системы денежных переводов и платежей.

Бизнес-вызов

Компания столкнулась с проблемой постоянного флага BGP-сессии с оборудованием Linxdatacenter. После изучения проблемы стало ясно, что на один из хостов в его сети происходила DDoS-атака.

Из-за распределенного характера атаки отфильтровать трафик было невозможно. Инженеры предложили решение, связанное с сокрытием хоста от внешней сети, но этот вариант не подходил заказчику. Атака прекратилась после внесения изменений в конфигурацию сервера, однако возобновилась на следующий день. Ее мощность достигла 5,5 Гбит/с, из-за чего перегружались «стыки» с интернет-провайдерами, что сказывалось на других пользователях облака Linxdatacenter. Чтобы обеспечить стабильную работу, было решено обратиться к надежному поставщику защиты от DDoS.

Решение

Чтобы обеспечить непрерывную доступность ресурсов, размещенных в облаке Linxdatacenter, весь трафик клиента был направлен через систему antiDDoS от StormWall. Атаку удалось погасить в течение получаса. Для предотвращения дальнейших кибератак все соединения сервисов клиента с интернетом были организованы через сеть StormWall.

Клиент:

БЭСТ, оператор системы денежных переводов и платежей.

Бизнес-вызов

Компания столкнулась с проблемой постоянного флага BGP-сессии с оборудованием Linxdatacenter. После изучения проблемы стало ясно, что на один из хостов в его сети происходила DDoS-атака.

Из-за распределенного характера атаки отфильтровать трафик было невозможно. Инженеры предложили решение, связанное с сокрытием хоста от внешней сети, но этот вариант не подходил заказчику. Атака прекратилась после внесения изменений в конфигурацию сервера, однако возобновилась на следующий день. Ее мощность достигла 5,5 Гбит/с, из-за чего перегружались «стыки» с интернет-провайдерами, что сказывалось на других пользователях облака Linxdatacenter. Чтобы обеспечить стабильную работу, было решено обратиться к надежному поставщику защиты от DDoS.

Решение

Чтобы обеспечить непрерывную доступность ресурсов, размещенных в облаке Linxdatacenter, весь трафик клиента был направлен через систему antiDDoS от StormWall. Атаку удалось погасить в течение получаса. Для предотвращения дальнейших кибератак все соединения сервисов клиента с интернетом были организованы через сеть StormWall.

Спасибо за ваш запрос, мы свяжемся с вами в ближайшее время!