Аварийное восстановление Kubernetes (Kubernetes Disaster Recovery Plan)

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

Резервное копирование и восстановление

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

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

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

Узнайте больше на странице резервного копирования Kubernetes.

Определите SLA для разных уровней приложений.

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

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

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

Поймите разницу между синхронным и асинхронным аварийным восстановлением.

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

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

Для приложений уровня 2 или 3 обычно достаточно асинхронного аварийного восстановления. Асинхронное аварийное восстановление также требует репликации данных приложения между двумя кластерами Kubernetes. Однако репликация не происходит одновременно с внесением изменений в основной кластер. Репликация во вторичный кластер обычно происходит по расписанию с учетом устойчивости к потерям.

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

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

Требования к низкой задержке

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

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

Повторяемые процессы

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

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

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

Обеспечение непрерывности бизнеса

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

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

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