Linx SAFE - Аварийное восстановление в AWS

Масштабируемое и экономичное восстановление приложений и данных. Гарантия быстрого восстановления операций после непредвиденных событий. Возврат в RPO за секунды и в RTO за минуты

LinxSafe выручит, если

Нежданные посетители заберут сервера с данными

Сервер с важными данными выйдет из строя или сгорит

Удаленный сервер окажется недоступен

Перебои электроэнергии на вашей площадке

Из чего состоит продукт

Direct
connect

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

DISASTER RECOVERY (DRaaS)

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

Amazon WEB
Services

Крупнейшее публичное облако, поддерживаемое и развиваемое компанией Amazon с беспрецедентным стандартом качества.

Преимущества Linx Safe

Доверьте репликацию данных надёжному провайдеру и мигрируйте в AWS за 1 день

Быстрый доступ в смарт-консоль с расширенным функционалом статистики

Оперативная настройка репликации в AWS за 1 день

Выделенный и защищённый канал до Стокгольма

Отсутствие нагрузки по развертыванию инфраструктуры, обслуживанию оборудования и ПО

Карта работы продукта Linx Safe

Мы объединили несколько сервисов в один проект, чтобы вы могли обеспечить катострофоустойчивость корпоративных данных и иметь к ним доступ 24/7

Восстановление

приложений в считанные минуты, с возвращением их в последнее состояние перед сбоем или же в состояние на определенный момент в прошлом

Единая процедура

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

Эластичное восстановление

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

DR в глобальных облаках: мнение эксперта

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

Чтобы подобные инциденты не стали сюрпризом, важно закладывать их вероятность в план аварийного восстановления (Disaster recovery или DR-план).

Какую роль в современных DR-планах играют глобальные облачные провайдеры – рассказывает Евгений Макарьин, руководитель группы разработки проектов и решений Linxdatacenter. 

Быстрый старт

Обеспечить надежную защиту ваших данных за 6 шагов

Получаем заявку

Он-лайн запрос и заключение договора

Готовимся

Защищаем и готовим ваши сервера для переноса данных в облако за рубежом и отправляем ссылки для подключения

Разворачиваем

Создаем резервную инфраструктуру ваших сервисов на случай аварийного восстановления, используя AWS

Тестируем и запускаем

Проводим тестирование резервирования данных и их аварийного восстановления

Поддерживаем и обучаем 24/7/365

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

Тарифы

Базовый

12.29 ₽/час

БИЗНЕС

94.23 ₽/час

Корпоративный

496.41 ₽/час

Индивидуальный

Подберем под ваши потребности

Лицензии и сертификаты

DR в глобальных облаках: повышаем надежность аварийного восстановления 

Евгений Макарьин, руководитель группы разработки продуктов и решенийLinxdatacenter

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

Чтобы подобные инциденты не стали сюрпризом, важно закладывать их вероятность в план аварийного восстановлениям (Disaster recovery или DR-план). Какую роль в современных DR-планах играют глобальные облачные провайдеры – рассказывает Евгений Макарьин, руководитель группы разработки проектов и решений Linxdatacenter.

Аксиома непрерывности бизнеса сегодня: только при наличии и регулярном тестировании DR-плана компания сможет рассчитывать на предсказуемые сроки возобновления работы в штатном режиме в случае отказа инфраструктуры и ИТ-систем.

Создание и реализация корпоративного DR-плана требует много ресурсов, как на этапе разработки и запуска, так и при поддержании систем и процессов в состоянии постоянной готовности.

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

«Заоблачный» уровень защиты

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

Триумвират «больших облаков» – Amazon Web Services, Google Cloud Platform и Microsoft Azure – предоставляет клиентам максимальную автоматизацию процессов на всех этапах от инсталляции DR-решения до последующего управления, мониторинга и реагирования на инциденты.

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

Почему нельзя просто делать disaster recovery в России?

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

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

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

Зачем вам это

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

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

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

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

DR в глобальном облаке позволяет получить полностью работающую инфраструктуру в среднем за 20 минут после инициации плана аварийного восстановления.

Подготовка

Многие представляют процесс миграции в глобальное облако как невероятно сложный и затратный. Однако провайдеры предлагают инструменты для безболезненной миграции для DR-проектов.

Как правило, такие решения состоят из нескольких основных блоков – это консоль для управления всем процессом и агенты (специальное ПО), устанавливаемые на исходные Windows или Linux — серверы заказчика. Потребуется аккаунт в публичном облаке, где автоматически разворачивается так называемая staging зона с сервером репликации. Там же хранятся реплики данных.

Рядом готовится целевая зона, где стартуют виртуальные машины клиента в случае тестового или «боевого» запуска DR-плана.

Такое решение позволяет максимально автоматизировать процесс миграции для десятков и даже сотен серверов.

На старт, внимание, DR!

После того, как данные сервера изначально передадутся в глобальное облако, включается постоянная поблочная репликация. Это позволяет добиться показателя RPO (целевая точка восстановления, до которой восстанавливается «упавшая» ИТ-система), в несколько секунд.

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

В глобальных облаках для этого создается security — группа, виртуальные сети, причем желательно с внутренней адресацией, аналогичной исходной инфраструктуре. И далее в консоли можно гранулярно для каждого отдельного сервера, настроить параметры, с которыми этот сервер будет стартовать при активации DR-плана.

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

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

Вопросы доступа

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

В чем преимущества?

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

Во-вторых, партнер разрабатывает план аварийного восстановления, который будет подробно описывать, от каких угроз компания защищается и каким образом. Описывает, кто и за что отвечает, с кем и каким образом контактировать во время тестирования или боевого аварийного восстановления. Прописывает регламент обновления DR-плана.

В-третьих, создает инфраструктуру под клиента в глобальном облаке. Подготавливает нужные учетные записи, сети, access-листы, security-группы, маршруты, шлюзы, балансировщики нагрузки и так далее.

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

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

Далее партнер возьмет на себя управление DR — инфраструктурой и поддержание DR-плана в актуальном состоянии. Это очень важная и достаточно трудозатратная часть стратегии по поддержанию работоспособности бизнеса.

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

Напишите нам

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Познай себя 

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

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

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

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

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

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

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

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

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

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

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

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

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

Что сделано 

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

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

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

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

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

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

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

Выводы 

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

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

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

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

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

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

Аварийное восстановление в AWS

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

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

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

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

Решение

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

Клиент:

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

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

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

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

Решение

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

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