Защита и восстановление в управлении облаком
Прежде чем подготовиться к возможному сбою рабочей нагрузки, группы управления облаком должны сначала убедиться, что они соответствуют требованиям:
По мере того как они планируют, команды должны начать с предположения, что что-то произойдет сбоем при авариях. Подготовка к сбою позволяет командам быстрее обнаруживать сбои и быстрее восстанавливаться. Основное внимание здесь уделяется действиям, которые начинаются сразу после сбоя системы. Как защитить рабочие нагрузки, чтобы их можно было быстро восстановить при возникновении сбоя?
Техническое решение не может последовательно предлагать соглашение об уровне обслуживания, которое гарантирует 100 процентов времени простоя. Даже решения с самыми избыточными архитектурами обещают лишь "шесть девяток", то есть работоспособность в течение 99,9999 % времени. Но даже "шесть девяток" означают, что за год ваше решение может не работать целых 31,6 секунды. Это редко для решения, чтобы гарантировать большие, текущие операционные инвестиции, необходимые для достижения "шести 9-х" времени простоя.
Понятные договоренности о защите и восстановлении
Рабочие нагрузки, из которыми выполняются бизнес-операции, состоят из следующих:
- Приложения
- Data
- Виртуальные машины (виртуальные машины)
- Другие ресурсы
Каждому ресурсу может потребоваться собственный подход к защите и восстановлению. Важной целью этой дисциплины является обеспечение согласованной приверженности в рамках базового плана управления, которое может обеспечить отправную точку для бизнес-обсуждений.
Как минимум, команды управления облачными клиентами должны создать базовый подход для каждого ресурса с четкой приверженностью быстрому восстановлению и минимальной потере данных.
Целевое время восстановления (RTO)
Цель времени восстановления — это время, необходимое для восстановления любой системы до аварии. Это будет включать в себя время, необходимое для:
- Восстановление минимальной функциональности виртуальных машин и приложений
- Восстановление данных, необходимых приложениям.
В бизнес-терминах RTO представляет время, когда бизнес-процессы не работают. Для критически важных рабочих нагрузок эта переменная должна быть относительно низкой, что позволяет бизнес-процессам быстро возобновить работу. Для рабочих нагрузок с более низким приоритетом стандартный уровень целевого времени восстановления будет достаточным, то есть не окажет заметного влияния на работу компании.
Бизнес должен создать базовый план управления, который устанавливает стандартную RTO для некритических рабочих нагрузок. Это базовое значение можно использовать для обоснования дополнительных инвестиций в улучшение времени восстановления.
Целевые точки восстановления (RPO)
В большинстве систем управления облаком некоторые формы защиты данных периодически фиксируют и хранят данные. Точка восстановления относится к последней записи данных. При сбое системы ее возможно восстановить только до последней точки восстановления.
Цель точки восстановления измеряется с последней точки восстановления до сбоя. Если RPO измеряется в часах, системный сбой приводит к потере данных в течение нескольких часов между последней точкой восстановления и сбоем. Если RPO измеряется в днях, системный сбой приводит к потере данных в течение нескольких дней между последней точкой восстановления и сбоем. Целевая точка восстановления с давностью в один день может означать потерю всех транзакций за весь день перед сбоем.
Для критически важных систем измерение RPO в минутах или секундах может помочь избежать потери доходов или прибыли. Однако более короткий RPO обычно приводит к увеличению затрат на управление. Чтобы свести к минимуму эти затраты, бизнес должен создать базовый план управления, ориентированный на самый длинный допустимый RPO. Затем бизнес может уменьшить RPO конкретных платформ или рабочих нагрузок, которые гарантируют больше инвестиций.
Защита и восстановление рабочих нагрузок
Большинство рабочих нагрузок в ИТ-среде поддерживают определенный деловой или технический процесс. Системы, которые не оказывают системного влияния на бизнес-операции, обычно не гарантируют увеличение инвестиций, необходимых для быстрого восстановления систем или минимизации потери данных. Создав базовый план, бизнес может определить, какой уровень поддержки восстановления они нуждаются в ценовой точке, которую они могут согласованно управлять. Понимание этого помогает бизнес-заинтересованным лицам оценить ценность увеличения инвестиций в восстановление.
Для большинства команд по управлению облаком расширенный базовый план, с определенными обязательствами RPO/RTO для различных активов, дает наиболее благоприятный путь к взаимным деловым обязательствам. В следующих разделах описаны несколько распространенных расширенных базовых показателей, которые позволяют бизнесу легко добавлять функции защиты и восстановления с помощью повторяемого процесса.
Защита и восстановление данных
В цифровой экономике данные являются наиболее ценным ресурсом. Потеря данных, которые влечет за собой рабочую нагрузку, приводит к потере доходов или прибыли. Наиболее распространенные расширенные базовые показатели — это возможность эффективного защиты и восстановления данных. Мы рекомендуем группам управления облачными клиентами предлагать уровень расширенных базовых показателей управления, поддерживающих общие платформы данных.
Перед тем, как группы управления облачными службами реализуют операции с платформой, они часто обеспечивают поддержку улучшенных операций для платформы данных в формате PaaS (платформа как услуга). Например, для группы управления облаком можно применить более высокую частоту резервного копирования или многорегионального реплика для решений База данных SQL Azure или Azure Cosmos DB. Это позволит команде разработчиков улучшить целевую точку восстановления, модернизируя платформы данных.
Подробнее этот процесс описан в статье Операции с платформой в управлении облаком.
Защита и восстановление виртуальных машин
Большинство рабочих нагрузок несколько зависят от виртуальных машин, в которых размещаются различные аспекты решения. Бизнес должен быстро восстановить некоторые виртуальные машины, чтобы рабочая нагрузка поддерживала свои процессы после сбоя системы.
Каждую минуту простоя на этих виртуальных машинах может привести к потере дохода или снижению прибыли. Если время простоя виртуальной машины напрямую влияет на финансовую производительность бизнеса, очень важно хорошее целевое время восстановления. Команды управления облаком могут быстро восстанавливать виртуальные машины, реплика их на вторичный сайт и с помощью автоматического восстановления, модель, которая называется моделью горячего восстановления. Команды также могут реплика управлять виртуальными машинами на функциональный, вторичный сайт в подходе, известном как горячая или высокодоступная модель. Горячий подход дороже, но он предлагает наибольшее состояние восстановления.
Каждая из этих моделей уменьшает RTO, что помогает предприятиям быстрее восстанавливать свои бизнес-возможности. Но каждая модель также приводит к значительному увеличению затрат на управление облаком.
Кроме того, обратите внимание, что помимо реплика tion для обеспечения высокой доступности резервное копирование должно быть включено для таких сценариев, как:
- Случайное удаление
- Повреждение данных
- Атаки программ-шантажистов
Подробнее об этом процессе выбора см. статью Операции рабочей нагрузки в управлении облаком.
Следующие шаги
Обеспечив все необходимое для компонента базовой конфигурации, группа может перейти к созданию защиты от простоев в работе платформы и эксплуатации рабочей нагрузки.