22.04.2020

Мониторинг в ЦОДе: как мы меняли старую BMS на новую. Часть 2

В первой части мы рассказали о том, почему решили поменять старую BMS-систему в наших ЦОДах на новую. И не просто поменять, а разработать с нуля под свои требования. Во второй части рассказываем, как мы это делали

В первой части мы рассказали о том, почему решили поменять старую BMS-систему в наших ЦОДах на новую. И не просто поменять, а разработать с нуля под свои требования. Во второй части рассказываем, как мы это делали.

Анализ рынка

С учетом описанных в первой части пожеланий и решения отказаться от обновления существующей системы мы написали ТЗ для поиска решения на рынке и сделали запросы в несколько крупных компаний, занимающихся только созданием промышленных систем SCADA.

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

Тут надо сделать небольшое отступление о процессе выбора подрядчика. Цена, конечно, имеет значение, но во время любого тендера на реализацию сложного проекта, на стадии диалога с поставщиками ты начинаешь чувствовать, кто из кандидатов более заинтересован и способен реализовать его.

Это особенно заметно на сложных проектах.

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

Все это заставило нас обратить внимание на относительно небольшого локального разработчика – группу компаний «Санлайн», который откликнулся на большинство наших требований сразу и был готов реализовать все потребности касательно новой BMS.

Риски

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

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

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

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

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

С первым риском справились. Второй исключили, получив от подрядчика подтверждение о готовности передать нам исходники кода системы и документации, а также выбрав язык программирования Python, хорошо знакомый нашим специалистам. Это гарантировало нам возможность поддерживать систему своими силами без каких-либо затруднений и длительного периода обучения сотрудников в случае ухода компании-разработчика с рынка.

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

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

После того как оба риска были минимизированы, подрядчик предоставил КП. В нем были проработаны все самые важные для нас параметры системы BMS.

Резервирование

Новая BMS-система должна была находиться в облаке, на виртуальной машине.

Никакого железа, никаких серверов и всех связанных с этой моделью развертывания неудобств и рисков – облачное решение позволяло нам избавиться от них навсегда. Было решено, что система будет работать в нашем облаке на двух площадках ЦОДа в Санкт-Петербурге и Москве. Это две полностью функциональные системы, работающие в режиме active standby с доступом для всех авторизованных специалистов.

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

Отметим, что резервирование как опция BMS-решения было разработано специально под наш запрос. Сама схема резервирования выглядела вот так:

 

Поддержка

Важнейший момент для эффективной эксплуатации BMS-решения – техподдержка.

Здесь все просто: новая система стоила бы нам по этому показателю 35 000 руб. в месяц за SLA «реакция в течение 8 часов», то есть 35 000 х 12 / 80 = $5 250 в год. Первый год – бесплатно.

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

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

Обновления

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

Старая система предполагала оплату как за обновление встроенного бесплатного ПО (типа Java), так и за исправление ошибок. Отказаться от этого было нельзя, при отсутствии обновлений система в целом «тормозила» из-за старых версий внутренних компонентов.

И, само собой, нельзя было обновить ПО без покупки пакета поддержки.

Гибкий подход

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

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

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

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

Согласование ТЗ и подписание договора

На тот момент, когда было необходимо начинать работу над новой системой, переписка с «большими» компаниями все еще была очень далека от обсуждения стоимости их предложений, поэтому мы сравнили полученное КП с затратами на обновление старой БМС (см. первую часть), и в результате оно оказалось более привлекательным по цене и соответствующим нашим требованиям.

Выбор был сделан.

После выбора подрядчика юристы стали составлять договор, а технические команды с обеих сторон шлифовать ТЗ. Как известно, подробное и грамотное ТЗ – это основа успеха любых работ. Чем больше конкретики в ТЗ, тем меньше разочарований вроде «а мы хотели не так».

Приведу два примера уровня детализации требований в ТЗ:

  • Дежурные ЦОД наделены полномочиями добавлять в BMS новые устройства, чаще всего это PDU. В старой BMS это был уровень «администратора», позволяющий в том числе менять уставки переменных всех устройств, и разделить функции было невозможно. Нас это не устраивало. В имеющейся базовой версии новой платформы схема была аналогичной. Мы сразу указали в ТЗ, что хотим разделить эти роли: уставки должен менять только уполномоченный сотрудник, но дежурные должны и дальше иметь возможность добавлять устройства. Эта схема и была принята к реализации.
  • В любой стандартной BMS есть три типовые категории уведомлений: КРАСНАЯ – надо немедленно реагировать, ЖЕЛТАЯ – можно наблюдать, СИНЯЯ – «Информационная». Мы традиционно использовали «синие» уведомления для мониторинга превышения коммерческих параметров, например, превышение лимита мощности стойки клиента. Этот тип уведомлений в нашем случае был предназначен для менеджеров и не был интересен службе эксплуатации, но в старой BMS регулярно засорял список активных инцидентов и мешал оперативной работе. Саму логику и цветовую дифференциацию штанов уведомлений мы посчитали удачной и сохранили, однако в ТЗ специально указали, что «синие» уведомления должны, не отвлекая дежурных, беззвучно «сыпаться» в отдельный раздел, где ими будут заниматься коммерческие специалисты.

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

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

Параллельная работа двух систем

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

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

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

Сетевой отдел прокинул виртуальные маршруты от прототипа новой BMS, развернутого в облаке, к устройствам, и мы получили результаты:

  • устройства, подключенные по протоколу SNMP, практически не выпадали в дисконнект из-за одновременных обращений,
  • устройства, подключенные через шлюзы по протоколам modbas-TCP, имели проблемы, которые были решены разумным снижением частоты их опроса.

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

О том, что получилось в итоге, мы расскажем в третьей части нашей статьи.

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

Статья
09.08.2022
ИБ в условиях дефицита: стратегия большого перехода
Новость
01.08.2022
Linxdatacenter – в топ-10 крупнейших поставщиков услуг ЦОД
Новость
25.07.2022
Linxdatacenter запускает собственные PaaS-инструменты
Новость
20.07.2022
Петербургское облако Linxdatacenter прошло аттестацию по ...
Статья
30.06.2022
Как мы оптимизировали управление ЦОДами клиента
Новость
27.06.2022
Linxdatacenter: рынок российских облаков вырастет в 2022 ...
Новость
26.05.2022
Анна Мальми назначена региональным директором Linxdatacen...
Статья
20.05.2022
Облачный край: что происходит на российском рынке
Новость
13.05.2022
Новым генеральным директором Linxdatacenter назначен Андр...
Статья
03.05.2022
Блок на моноблок: модульная ИБП-революция в ЦОДах

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

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

Напишите нам

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Познай себя 

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

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

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

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

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

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

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

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

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

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

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

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

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

Что сделано 

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

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

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

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

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

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

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

Выводы 

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

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

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

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

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

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

Мониторинг в ЦОДе: как мы меняли старую BMS на новую. Часть 2

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

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

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

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

Решение

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

Клиент:

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

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

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

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

Решение

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

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