Разработка плана непрерывности бизнес-процессов и аварийного восстановления
Ваша организация хочет поручить вам разработку стратегии восстановления сайта для своих приложений. Во-первых, необходимо понять конкретные требования к созданию восстановления сайта для гибридной среды. Вы также должны понять, какие средства доступны в Azure, чтобы помочь вам.
В этом уроке вы узнаете, как определить ключевые инфраструктуры, цели времени восстановления (ОСРВ) и цели точки восстановления (RPOS). Вы узнаете, какие требования могут быть релевантны для любой платформы как службы (PaaS), которые вы можете использовать. Вы также узнаете, как спланировать резервное копирование и аварийное восстановление. Наконец, вы узнаете о некоторых функциях Azure, которые помогут вам создать решение для восстановления сайта.
Непрерывность бизнес-процессов и аварийное восстановление
Необходимо разработать план BCDR для разработки соответствующего решения для восстановления сайта. BCDR относится к процессу, который помогает восстановить приложения в функциональном состоянии после значительного события. Это событие может быть стихийным бедствием, например землетрясением. Или это может быть технический характер, например удаление базы данных. Эти события, как правило, более широки в области и требуют больше усилий по восстановлению.
Чтобы разработать успешный процесс аварийного восстановления, сначала необходимо оценить, какой бизнес-эффект может иметь любые потенциальные сбои. Рекомендуется в максимальной степени автоматизировать процесс восстановления. Неизбежно некоторые части процесса аварийного восстановления включают в себя человеческие данные, поэтому необходимо полностью документировать процесс. Кроме того, необходимо регулярно имитировать аварии, чтобы процесс восстановления оставался эффективным.
Определение ключевых заинтересованных лиц и инфраструктуры
Определите всех лиц, заинтересованных в непрерывном функционировании ваших приложений. Эти заинтересованные лица могут быть внешними или внутренними пользователями. Ваш сотрудник службы поддержки, и любой пользователь, необходимый для ручного ввода в процесс BCDR, является заинтересованным лицом. Другие приложения и службы, которые полагаются на ваши приложения, также могут быть заинтересованными лицами.
Определите инфраструктуру, составляющую среду для приложений. Эта инфраструктура обычно является виртуальными машинами, сетевыми ресурсами, ресурсами хранилища и другими службами, которые выполняются вместе с этими ресурсами.
Определение целевого времени восстановления и целевых точек восстановления
RPO представляет, сколько потери данных приемлемы для приложения при возникновении аварии. Например, в случае сбоя приложения может оказаться, что после восстановления для него допустимо использовать данные не старше получаса. Некоторые приложения могут работать с более старыми данными, но для других критически важно всегда работать с наиболее свежими данными.
RTO — это максимальная длительность допустимого простоя приложения. Например, может оказаться неприемлемым для приложения, которое будет работать дольше четырех часов из-за потенциальной потери для бизнеса, которая приведет к более длительному сбою. Критически важные приложения требуют более короткого RTO.
Контрактные или нормативные требования часто влияют на RPO и RTO для вашего приложения. RPO и RTO также могут отличаться в зависимости от приложения. Менее критически важные приложения могут иметь большие значения для RPO и RTO, в то время как критически важные для бизнеса приложения могут иметь меньше допустимости для простоя и потери данных. Вы вычисляете RTO и RPO на основе понимания риска и затрат, связанных с простоем и потерей данных.
Определение требований PaaS
Хотя у вас может быть контроль над временем простоя и восстановлением для управляемых приложений, у вас может быть не тот же контроль над службами PaaS. Все используемые службы PaaS могут иметь собственные гарантии доступности и планы восстановления, которые необходимо учитывать в плане BCDR.
Определите и инвентаризацию зависящих служб, поэтому их возможности восстановления можно включить в план BCDR. Важно понимать соответствующие требования и как они влияют на процесс BCDR.
Azure Site Recovery
Azure Site Recovery — это служба, которая предоставляет функции непрерывности бизнес-процессов и аварийного восстановления (BCDR) для приложений в Azure, в локальной среде и у других поставщиков облачных служб. Site Recovery имеет планы, которые помогают автоматизировать аварийное восстановление. Он позволяет определить способ отработки отказа компьютеров и порядок их перезапуска после успешного отработки отказа. Таким образом, Site Recovery помогает автоматизировать задачи и дополнительно сократить RTO. Вы также можете использовать Site Recovery для периодического тестирования отработки отказа и общей эффективности процесса восстановления.
Резервные копии данных
Резервные копии помогают защитить приложения от случайного удаления или повреждения данных. Резервные копии играют важную роль в любом плане BCDR.
RPO зависит от частоты и частоты выполнения процессов резервного копирования. Например, если у вас есть процесс резервного копирования, настроенный на выполнение каждые два часа, и перед следующей резервной копией возникает авария, вы потеряете один час и 55 минут данных. Более частое проведение операций резервного копирования означает снижение значения RPO. В общий план необходимо включить подробный процесс резервного копирования.
Azure Backup можно использовать для процесса резервного копирования. Служба Azure Backup обеспечивает безопасное резервное копирование для всех управляемых Azure ресурсов данных. В нем используются решения нулевой инфраструктуры для обеспечения самостоятельного резервного копирования и восстановления с помощью горизонтального управления с прогнозируемой стоимостью.
Azure Backup предлагает специализированные решения для резервного копирования для виртуальных машин Azure и локальных виртуальных машин. Azure Backup также позволяет рабочим нагрузкам, таким как SQL Server или SAP HANA, работающим на виртуальных машинах Azure, иметь параметры резервного копирования и восстановления корпоративного класса.
Как Azure Backup, так и Azure Site Recovery, позволяют сделать систему более устойчивой к сбоям. Однако основная цель Azure Backup — поддерживать копии данных с отслеживанием состояния, которые позволяют вернуться к времени. Site Recovery реплицирует данные практически в реальном времени и позволяет выполнить отработку отказа. Дополнительные сведения об Azure Backup.
Функции устойчивости Azure
Azure поставляется с несколькими функциями, помогающими обеспечить устойчивость приложений и инфраструктуры. Функции устойчивости Azure включают связывание регионов, группы доступности и зоны доступности.
Связывание регионов
Все регионы Azure связаны с другим регионом. Регионы в паре никогда не обновляются одновременно. Вместо этого они обновляются по одному. Если что-то происходит с одним регионом, другой регион в паре становится доступным.
Эти пары регионов также используются для репликации. Службы хранилища и многие службы PaaS реплицируются и имеют пары отработки отказа в парном регионе. В рамках планирования BCDR важно использовать связывание регионов, чтобы воспользоваться преимуществами изоляции, которую он предоставляет. Вы можете сократить время восстановления после сбоя и увеличить доступность.
Группы доступности
Группа доступности — это логическая возможность группирования в Azure. Вы можете разместить ресурсы виртуальной машины в группе доступности, чтобы убедиться, что эти ресурсы виртуальных машин изолированы друг от друга при развертывании в центре обработки данных Azure. Группы доступности состоят из доменов обновления и доменов сбоя.
Домены обновления помогают обеспечить работу подмножества серверов приложения, когда узлы виртуальных машин в центре обработки данных Azure требуют простоя для обслуживания. Большинство обновлений узлов виртуальных машин можно выполнять без влияния на виртуальные машины, работающие на них, но иногда возникают случаи, когда этот тип обновления невозможен.
Чтобы обновления не выполнялись для всех виртуальных машин одновременно, центр обработки данных Azure логически разделен на домены обновления. Когда происходит событие обслуживания, например обновление производительности и критическое исправление безопасности, которое необходимо применить к узлу, событие обслуживания последовательность выполняется через домены обновления. Использование последовательности с помощью доменов обновления гарантирует, что весь центр обработки данных недоступен во время обновлений и исправлений платформы.
Домены сбоя представляют физические разделы центра обработки данных и помогают обеспечить разнообразие серверов в группе доступности. Домены сбоя соответствуют физическому разделению общего оборудования в центре обработки данных. Общее оборудование включает питание, охлаждение и сетевое оборудование, которое поддерживает физические серверы на серверах стоек.
Если оборудование, поддерживающее стойку сервера, становится недоступной, сбой влияет только на стойку сервера. При размещение виртуальных машин в группе доступности они автоматически распределяются по нескольким доменам сбоя. Если происходит сбой оборудования, он влияет только на некоторые виртуальные машины.
Зоны доступности
Зоны доступности являются независимыми расположениями физических центров обработки данных в пределах региона. Зоны доступности включают собственную мощность, охлаждение и сеть. При использовании зон доступности при развертывании ресурсов вы можете защитить рабочие нагрузки от сбоев центра обработки данных при сохранении присутствия в регионе.
Зональные службы — это службы (например, виртуальные машины), которые можно развернуть в определенных зонах в пределах региона. Другие службы — это службы, избыточные между зонами, и реплицируются в зонах доступности в определенном регионе Azure. Оба типа помогают гарантировать, что в регионе Azure нет отдельных точек сбоя.
