11.03.2021

DRaaS: сценарии аварийного восстановления

План действий на случай сбоя или аварии на уровне ИТ-инфраструктуры - must have для всех компаний сегодня. Олег Федоров, менеджер по продуктам и решениям Linxdatacenter, рассказывает, как устроено аварийное восстановление на площадках Linxdatacenter с подробным разбором нюансов и сценариев развития событий

План действий на случай сбоя или аварии на уровне ИТ-инфраструктуры — must have для всех компаний сегодня. Олег Федоров, менеджер по продуктам и решениям Linxdatacenter, рассказывает, как устроено аварийное восстановление на площадках Linxdatacenter с подробным разбором нюансов и сценариев развития событий.

Что такое DRaaS и кому он нужен

Основное правило построения отказоустойчивых решений по-английски звучит в рифму и крайне точно описывает базовый подход к DRP: Two is one and one is none («Два равняется одному, один равняется нулю»).

В соответствии с этим подходом, любой критически важный элемент ИТ-системы должен быть представлен в двух экземплярах и никогда – в единственном. В самом примитивном варианте возможна модель n+1, которая предполагает оперативное «поднятие» дополнительного ресурса в случае необходимости.

Disaster Recovery as a Service (DRaaS), или аварийное восстановление ИТ-систем как услуга, заключается в создании копии физических или виртуальных серверов третьей стороной, чтобы минимизировать потери бизнеса, вызванные отказом инфраструктуры в случае техногенной катастрофы или стихийного бедствия.

DRaaS актуален для организаций, у которых нет возможностей или ресурсов для того, чтобы самостоятельно развернуть и настроить план аварийного восстановления (Disaster Recovery Plan, или DRP).

DRaaS эффективен и против кибер-угроз класса ransomware, массовый рост числа которых был отмечен ИБ-экспертами в конце 2020 года по всему миру.

Хакеры-вымогатели заработали более $350 млн в 2020 году, что на 311% больше, чем в 2019. Истинная цифра, скорее всего, будет гораздо больше, учитывая, что многие жертвы не сообщают о факте атаки и, тем более, о выплате выкупа. Некоторые аналитики оценивают подобные издержки для бизнеса на уровне $20 млрд в год.

 

Облачная отказоустойчивость как тренд

В условиях локдауна многие компании сократили свои расходы на ИТ в рамках стратегического пересмотра политики капитальных расходов (CAPEX).

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

Ожидается, что объем мирового рынка DRaaS вырастет с $5,1 млрд в 2020 году до $14,6 млрд к 2025 году при совокупном годовом темпе роста (CAGR) 23,3% в течение прогнозного периода (данные MarketsandMarkets).

Рынок будет продолжать расти под влиянием пандемии COVID-19, так как миграция ИТ-инфраструктуры в облако позволяет «прокачать» непрерывность бизнеса (business continuity) компаний, работа которых зависит от надежности цифровых сред и инструментов.  И при этом не делать значительных вложений в инфраструктуру.

Трудности перехода

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

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

Согласно опросу, проведенному одним из ведущих игроков на рынке DRaaS, компанией Infrascale, 80% респондентов заинтересованы в использовании традиционных методов и старых технологий для аварийного восстановления.

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

Можно принять меры по снижению риска, но иногда определенные события делают простой оборудования неизбежным. DRaaS нередко критикуют как избыточную меру – «Это рассчитано на прямое попадание метеорита в ЦОД, этого никогда не произойдет».

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

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

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

 

DRP поэтапно 

DRP – комплекс действий, направленных на восстановление ИТ-инфраструктуры и данных после какой-либо аварии, сбоя или катастрофы. Неважно, с чем они связаны: проблемы на уровне ИТ-инфраструктуры, авария инженерных систем ЦОДа, человеческие ошибки, пожары, землетрясения, наводнения.

Можно выделить пять основных этапов DRP:

  • аудит ИТ-процессов с анализом и оценкой рисков;
  • разработка DRaaS-решения;
  • внедрение решения;
  • тестирование решения;
  • запуск в эксплуатацию.

На этапе разработки решения рассчитываются показатели RTO (recovery time objective) – максимально допустимое время простоя сервиса в случае сбоя, и RPO (recovery point objective) – точка возврата, или максимально допустимый объем возможных потерь данных.

Значения RTO и RPO устанавливаются каждой организацией индивидуально, исходя из специфики и задач бизнеса. Например, для каких-то компаний недоступность электронной почты не столь критична (RTO), а вот потеря статистики активности пользователей за неделю вызовет серьезные проблемы в работе бизнеса (RPO).

Для среднестатистической компании RTO и RPO могут быть большими, вплоть до нескольких дней. Если рассматривать банковские системы, RPO более 5 минут недопустим, потому что потерять данные за больший промежуток времени означает прямой финансовый ущерб.

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

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

 

Как мы защищаем ИТ-системы от сбоя 

Современная ИТ-инфраструктура включает в себя четыре базовые составляющие.

Первая – это уровень «железа» (hardware), на котором развернут второй уровень – системы виртуализации. Внутри них находится третий уровень – операционных систем, а на базе операционных систем развернут четвертый уровень – ИТ-сервисы и приложения.

Решение DRaaS, которое мы в Linxdatacenter разработали для своих клиентов, в полном объеме покрывает уровень hardware. У нас есть собственные площадки дата-центров в Москве, Санкт-Петербурге, а также облако в Варшаве.

На уровне виртуализации мы используем систему VMware, которая позволяет гарантировать высокие показатели восстановления вплоть до третьего уровня (т.е. ОС).

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

 

DR-сценарии

Самый простой вариант DR – Backup-as-a-Service (BaaS). Это disaster recovery в миниатюре. Фактически это стартовый уровень резервирования.

Бэкап происходит следующим образом. У нас есть виртуальная машина, Veeam создает архив виртуальной машины и сохраняет эту резервную копию. Чаще всего копия хранится на той же площадке, где и оригинал. Можно положить ее и в другое место – например, в облачную платформу Linxdatacenter Москва или Linxdatacenter Варшава.

Эта схема защищает зарезервированные данные от потери в случае сбоя.

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

Почему BaaS – не совсем DRaaS и «стартовый уровень»? Потому что показатели RTO и RPO здесь очень большие. Пока мы распакуем образ сохраненной системы или данных, пока подмонтируем, пока запустим – пройдет время.

Преимуществом модели является возможность бэкапа, даже если клиент не размещает ИТ-инфраструктуру в нашем облаке. Используя Veeam Cloud Connect, клиент может выложить резервную копию на одну из наших площадок.

Если клиент не пользуется инструментами Veeam, то и на этот случай есть решение: достаточно установить специальное ПО непосредственно на виртуальную машину, которое позволит создать резервную копию и сохранить ее в облаке Linxdatacenter.

Рассмотрим более продвинутый сценарий.

У нас есть точка А, на которой работают виртуальные машины, и точка Б, куда виртуальные машины предварительно копируются.

 

 

Данные с основной площадки постоянно передаются на вторую с заданным интервалом. Таким образом RPO становится значительно меньше, потому что такое решение поддерживает обновления с периодичностью вплоть до 15-20 минут.

Если система в точке А окажется недоступной, ответственный сотрудник отреагирует и запустит инструменты Veeam для выполнения аварийного восстановления.

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

В случае, если клиент использует собственную архитектуру, мы задействуем Veeam Cloud Connect – через него мы можем подцепить не только бэкапы к себе в облако, но и организовать всю необходимую заказчику инфраструктуру. Единственная оговорка: IP-адреса не будут работать по причине использования сети третьей стороны.

В данной модели DRP показатель RTO составит примерно 20 минут. Через 20 минут поднимутся виртуальные машины и инфраструктура заказчика на второй площадке (точке Б). RPO же составит примерно 30 минут с момента запуска аварийного сценария.

 

В ручном режиме

Надо понимать, что операции по аварийному восстановлению всегда выполняются в ручном режиме. Любая автоматизация процесса восстановления может вызвать ложные срабатывания и ситуации по типу split head.

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

В 99% таких случаев вся инфраструктура падает, потому что каждая точка пытается «перетянуть одеяло» на себя. Сервисы просто перестают быть доступными, и нужно распутывать этот клубок руками.

Поэтому инициация DRP, переезд IP-адресов и прочее – все происходит в ручном или полуавтоматическом режиме.

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

Чтобы максимально упростить процесс для конечного пользователя, можно предложить ему специальную консоль для управления DRP. Если точка становится недоступна, сотрудник нажимает кнопку «Запустить DRP», и после получения команды Veeam при помощи технологии Veeam Replica запускает виртуальные машины в точке Б.

Также клиент должен написать отправить запрос на перевод IP-адресов, если он использует каналы связи Linxdatacenter. Если же сетевые ресурсы предоставляет третья сторона, на двух площадках ставится инструмент load balancer от Citrix, а между площадками назначается виртуальный IP-адрес. В результате мы получаем два разных физических и один виртуальный внешний IP-адрес.

При этом сервисы для конечных пользователей всегда будут доступны по известному им IP-адресу. Это избавляет клиента от необходимости вручную менять записи в DNS у себя в настройках.

 

Расчет стоимости 

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

Например, потребности банков в DRP будут очень сильно отличаться от аналогичных процедур, скажем, в производстве.

Любой план DRP, даже с учетом фиксированных и гарантированных провайдером решения параметров, потребует «подгонки» под реалии конкретной компании.

Определять, какая базовая модель нужна компании – BaaS или DRaaS, – также нужно, исходя из анализа потребностей компании.

BaaS – это просто копия данных клиента, которая лежит зачастую на той же площадке, что и исходник, для восстановления стандартными средствами также на основной площадке. Это «подстраховка» на всякий случай.

DRaaS всегда предполагает защиту от какой-то серьезной катастрофы, будь то национальный или региональный блэкаут, стихийное бедствие (наводнение, землетрясение), война или прямое попадание метеорита в ЦОД с системами клиента.

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

В BaaS для расчета стоимости применяется модель «pay as you go», когда клиент платит за место на диске, а за ресурсы CPU и RAM плата рассчитывается только в определенном объеме, в зависимости от масштабов восстановленной системы и только в случае активации сценария.

Стоимость DRaaS включает в себя много параметров и рассчитывается индивидуально

 

Когда спасает только DRaaS

Бэкап перекрывает многие потребности, но далеко не все.

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

Поступает запрос на срочное восстановление и перезапуск ИТ-систем, сделать это на основной площадке невозможно: она физически недоступна – авария носит техногенный характер, скажем, серверную затопила прорванная труба, которая проходит выше этажом. Все, оборудование безнадежно испорчено – BaaS тут не спасет, нужен DRaaS.

При этом использование в DRaaS ресурсов глобальных публичных провайдеров позволяет свести RTO и RPO до минимума.

 

Это решение построено на инструменте CloudEndure Disaster Recovery и позволяет устанавливать агента на виртуальную машину клиента. Далее через консоль управления ВМ реплицируется в облако AWS. Процесс носит непрерывный характер и охватывает ОС, конфигурации состояния системы, приложения и файлы.

CloudEndure Disaster Recovery можно использовать для защиты самых важных баз данных, в том числе Oracle, MySQL и SQL Server, а также корпоративных приложений, таких как SAP.

В случае аварии решение позволяет за несколько минут автоматически запустить тысячи ВМ в состоянии полной готовности.

Стоит отметить, что AWS-сценарий как DRP – самое эффективное, но и самое дорогостоящее решение: стоимость включает затраты на виртуальные машины, дисковое пространство, а также лицензию на CloudEndure и дополнительные сервиcы AWS.

 

3,2,1…и последний вывод

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

Если вы сможете затруднить злоумышленникам доступ к вашим данным и приложениям, это удержит многих от повторных атак.

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

Надежный план резервного копирования подкрепляет общую ИБ-политику компании. Хорошим началом здесь будет так называемая «Стратегия 3,2,1»: три копии данных – две из них хранятся локально, но в разных частях, еще одна – вне площадки.

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

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

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

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

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

Напишите нам

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Познай себя 

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

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

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

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

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

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

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

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

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

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

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

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

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

Что сделано 

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

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

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

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

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

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

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

Выводы 

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

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

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

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

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

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

DRaaS: сценарии аварийного восстановления

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

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

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

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

Решение

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

Клиент:

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

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

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

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

Решение

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

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