Как получить максимальную отдачу от вашего плана аварийного восстановления в облаке

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

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

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

Перейти к:

Задача № 1: поддержание безотказной работы в облачных средах Облегчение облачных проблем Как аварийное восстановление влияет на

Задача № 1: поддержание безотказной работы в облачных средах

Амитабх Синха: Проблема номер один — это уровень доступности, который обеспечивает облако. Сегодня основные публичные облака — AWS, Google и Azure — предлагают доступность на уровне 99,9 %, что означает более восьми часов простоя в год, что значительно затрудняет выполнение большинства критически важных рабочих нагрузок и может стоить организациям миллионы долларов в виде убытков. производительность.

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

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

СМ.: План аварийного восстановления и обеспечения непрерывности бизнеса

Офер Маор: Понятие облака и его модели совместной ответственности заключается в том, что ответственность за обслуживание и доступность среды лежит на поставщике облака. Реальность сложнее.

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

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

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

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

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

Облегчение облачных проблем

Амитабх Синха: В частности, для вычислений конечных пользователей (EUC) крайне важен мультиоблачный и мультирегиональный подход. Запуск рабочих нагрузок EUC в облачных регионах и в основных облаках может значительно сократить количество простоев в бизнесе.

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

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

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

Как аварийное восстановление влияет на

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

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

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

Естественно, резервное копирование является важной частью головоломки, которую должны выполнять клиенты облака (и SaaS), поскольку они не могут полагаться на поставщика облака (по крайней мере, в большинстве моделей совместной ответственности). Одна из областей, в которой большинство организаций все еще отстают, — это резервное копирование и восстановление SaaS, но если организация взломана и весь ее Sharepoint или GDrive удерживается злоумышленником с целью получения выкупа, поставщик может быть не в состоянии помочь.

Сравнение облачного аварийного восстановления с локальным

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

Как влияют погодные явления и соответствующие рекомендации

Или Aspir: суровые погодные условия, такие как ураганы, наводнения или бури, могут нарушить работу центров обработки данных в определенной зоне доступности в облаке. Эти сбои могут вызвать перебои в подаче электроэнергии, сбои в сети или физический ущерб, что приведет к перебоям в обслуживании и повлияет на доступность облачных ресурсов в этой зоне. Примером такого случая является отключение нескольких сервисов Google Cloud в Европе 25 апреля 2023 года. Это отключение произошло из-за сочетания наводнения и пожара.

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

Как больше внимания к конечному пользователю сократить дорогостоящее время простоя из-за перебоев в работе?

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

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

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

На что еще вы порекомендуете обратить внимание ИТ-специалистам?

Амитабх Синха: Создайте прямые внутренние механизмы обратной связи с конечными пользователями для всех приложений конечных пользователей (например, опросы в конце сеанса Teams или Zoom).

Используйте облачные инструменты наблюдения для конкретных рабочих нагрузок, такие как DataDog для серверных рабочих нагрузок и Workspot и ControlUp для вычислительных рабочих нагрузок конечных пользователей.

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

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

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

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

Читать дальше: вашей организации требуется региональное аварийное восстановление: вот как это сделать на Kubernetes