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».

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

 

News and publications

You may also be interested in

Write to us

How we optimized customer data center management

Data center is a complex IT and engineering object, which requires professionalism at all levels of management: from managers to technical specialists and executors of maintenance works. Here's how we helped our client put operational management in corporate data centers in order.
 

Taras Chirkov, Head of Data Center in St. Petersburg  in St. Petersburg 

Konstantin Nagorny, chief engineer of data center in St. Petersburg.  in St. Petersburg 

Data center is a complex IT and engineering object, which requires professionalism at all levels of management: from managers to technical specialists and executors of maintenance works. Here's how we helped our client put operational management in corporate data centers in order.  

Management is in the lead 

The most advanced and expensive IT equipment will not bring the expected economic benefits if proper processes of engineering systems operation in the data center, where it is located, are not established.  

The role of reliable and productive data centers in today's economy is constantly growing along with the requirements for their uninterrupted operation. However, there is a big systemic problem on this front.  

A high level of "uptime" - failure-free operation of a data center without downtime - depends very much on the engineering team that manages the site. And there is no single formalized school of data center management.  

And there is no single formalized school of data center management.    

Nationwide  

In practice, the situation with the operation of data centers in Russia is as follows.  

Data centers in the commercial segment usually have certificates confirming their management competence. Not all of them do, but the very specifics of the business model, when a provider is responsible to the client for the quality of service, money and reputation in the market, obligates them to own the subject. 

The segment of corporate data centers that serve companies' own needs lags far behind commercial data centers in terms of operational quality. The internal customer is not treated as carefully as the external customer, not every company understands the potential of well-configured management processes. 

Finally, government departmental data centers - in this regard, they are often unknown territory due to their closed nature. An international audit of such facilities is understandably impossible. Russian state standards are just being developed.  

This all translates into a "who knows what" situation. "Diverse" composition of operation teams composed of specialists with different backgrounds, different approaches to the organization of corporate architecture, different views and requirements to IT departments.  

There are many factors that lead to this state of affairs, one of the most important is the lack of systematic documentation of operational processes. There are a couple of introductory articles by Uptime Institute which give an idea of the problem and how to overcome it. But then it's necessary to build the system by your own efforts. And not every business has enough resources and competence for that.  ⠀⠀  

Meanwhile, even a small systematization of management processes according to industry best practices always yields excellent results in terms of improving the resilience of engineering and IT systems.  

Case: through thorns to the relative order 

Let's illustrate by the example of an implemented project. A large international company with its own data center network approached us. The request was for help to optimize the management processes at three sites where IT systems and business-critical applications are deployed.  

The company had recently undergone an audit of its headquarters and received a list of inconsistencies with corporate standards with orders to eliminate them. We were brought in as a consultant for this as a bearer of industry competence: we have been developing our own data center management system and have been educating on the role of quality in operational processes for several years.  

Communication with the client's team began. The specialists wanted to get a well-established system of data center engineering systems operation, documented on the processes of monitoring, maintenance and troubleshooting. All this had to ensure optimization of the infrastructure component in terms of IT equipment continuity.  

And here began the most interesting part.  

Know thyself 

To assess the level of data centers in terms of compliance with standards, you need to know the exact requirements of the business to IT systems: what is the level of internal SLA, the allowable period of equipment downtime, etc.  

It became clear right away that the IT department did not know exactly what the business wanted. There were no internal criteria of service quality, no understanding of the logic of their own infrastructure.  

Colleagues simply had no idea what the permissible downtime for IT-related operations was, what the optimal system recovery time in case of a disaster was, or how the architecture of their own applications was structured. For example, we had to figure out whether a "crash" of one of the data centers would be critical to the application, or if there were no components affecting the application.  

Without knowing such things, it is impossible to calculate any specific operational requirements. The client recognized the problem and increased coordination between IT and the business to develop internal requirements and establish relationships to align operations.  

Once an understanding of the IT systems architecture was achieved, the team was able to summarize the requirements for operations, contractors, and equipment reliability levels.  

Improvements in the process 

Our specialists traveled to sites to assess infrastructure, read existing documentation, and checked the level of compliance of data center projects with actual implementation.  

Interviews with the responsible employees and their managers became a separate area of focus. They told what and how they do in different work situations, how the key processes of engineering systems' operation are arranged.  

After starting the work and getting acquainted with the specifics of the task the client "gave up" a little: we heard the request "just to write all the necessary documentation", quickly and without deep diving into the processes.  

However, proper optimization of data center "engineering" management implies the task to teach people to properly assess the processes and write unique documentation for them based on the specifics of the object.  

It is impossible to come up with a working document for a specific maintenance area manager - unless you work with him at the site continuously for several months. Therefore this approach was rejected: We found local leaders who were willing to learn themselves and lead their subordinates.  

Having explained the algorithm of documents creation, requirements to their contents and principles of instructions ecosystem organization, for the next six months we controlled the process of detailed writing of documentation and step-by-step transition of the personnel to work in a new way. 

This was followed by a phase of initial support for work on the updated regulations, which lasted one year in a remote format. Then we moved on to training and drills - the only way to put the new material into practice.  

What's been done 

In the process, we were able to resolve several serious issues.  

First of all, we avoided double documentation, which the client's employees feared. To this end, we combined in the new regulations the regulatory requirements applied to various engineering systems as standard (electrics, cooling, access control), with industry best practices, creating a transparent documentation structure with simple and logical navigation.   

The principle of "easy to find, easy to understand, easy to remember" was complemented by the fact that the new information was linked to the old experience and knowledge of the employees. 

Next, we reshuffled the staff of service engineers: several people turned out to be completely unprepared for the change. The resistance of some was successfully overcome in the course of the project through the demonstration of benefits, but a certain percentage of employees turned out to be untrained and unresponsive to new things.  

But we were surprised by the company's frivolous attitude to its IT infrastructure: from the lack of redundancy of critical systems to the chaos in the structure and management.  

In 1.5 years the engineering systems management processes have been pumped up to the level that allowed the company's specialists to successfully report "for quality" to the auditors from the headquarters.  

With the support of the operating component development pace the company will be able to pass any existing certification of data centers from leading international agencies.  

Summary 

In general, the prospects of consulting in the field of operational management of data centers, in our opinion, are the brightest.  

The process of digitalization of the economy and the public sector is in full swing. Yes, there will be a lot of adjustments in the launch of new projects and plans for the development of old ones, but this will not change the essence - the operation should be improved at least to improve the efficiency of already built sites.  

The main problem here: many managers do not understand what thin ice they are walking on, not paying proper attention to this point. The human factor is still the main source of the most unpleasant accidents and failures. And it needs to be explained.  

Government data center projects are also becoming more relevant now and require increased attention in terms of operations: the scope of government IT systems is growing. Here, too, the development and introduction of a system of standardization and certification of sites will be required.  

When the requirements to public data centers in Russia at the level of legislation will be reduced to a standard, it can be applied to commercial data centers, including for the placement of public IT resources.  

The work in this area is ongoing, we are participating in this process in consultation with the Ministry of Digital and by building competencies for teaching courses on data center operation at the ANO Data Center. There is not much experience on such tasks in Russia, and we believe that we should share it with colleagues and clients. 

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

BEST, money transfer and payments operator

business challenge

The customer faced a technical issue with a persistent BGP session flag with Linxdatacenter hardware. We examined the problem and found out that one of customer’s hosts was under a DDoS attack.

Because of the distributed nature of the attack, traffic couldn’t be filtered effectively, and disconnecting the host from the external network wasn’t an option. The attack stopped after changes in the server configuration, but resumed the day after. A 5.5 Gbps attack overloaded the junctions with internet providers, affecting other Linx Cloud users. To mitigate the effects of the attack, we employed a dedicated DDoS protection service.

Solution

To ensure the continuous availability of resources hosted in Linx Cloud, we rerouted all the customer’s traffic through StormWall Anti-DDoS system. The attack was stopped within half an hour. To prevent future cyberattacks, we organized all connections to the customer’s resources through the StormWall network.

client:

BEST, money transfer and payments operator

business challenge

The customer faced a technical issue with a persistent BGP session flag with Linxdatacenter hardware. We examined the problem and found out that one of customer’s hosts was under a DDoS attack.

Because of the distributed nature of the attack, traffic couldn’t be filtered effectively, and disconnecting the host from the external network wasn’t an option. The attack stopped after changes in the server configuration, but resumed the day after. A 5.5 Gbps attack overloaded the junctions with internet providers, affecting other Linx Cloud users. To mitigate the effects of the attack, we employed a dedicated DDoS protection service.

Solution

To ensure the continuous availability of resources hosted in Linx Cloud, we rerouted all the customer’s traffic through StormWall Anti-DDoS system. The attack was stopped within half an hour. To prevent future cyberattacks, we organized all connections to the customer’s resources through the StormWall network.

Thank you for your inquiry, we will get back to you shortly!