Рекомендации по непрерывности бизнес-процессов и аварийному восстановлению для Red Hat Enterprise Linux в Azure
В этой статье описывается, как улучшить непрерывность бизнес-процессов и аварийное восстановление (BCDR) для среды на основе Red Hat Enterprise Linux (RHEL) в Azure. Он предоставляет рекомендации, которые можно использовать для поддержки рабочих нагрузок RHEL и развертывания компонентов управления платформой RHEL. Подписка Red Hat Management содержит компоненты платформы, которые помогают управлять рабочими нагрузками в одной или нескольких целевых зонах RHEL. Эти компоненты предлагают собственные конфигурации BCDR.
Рекомендации по проектированию
Выполните следующие рекомендации, чтобы повысить устойчивость рабочих нагрузок RHEL.
Цели времени восстановления
Цель времени восстановления (RTO) — это время, затрачиваемое системой на восстановление до исходного состояния после аварии. RTO включает время, которое требуется:
- Восстановление минимальных функциональных возможностей на виртуальных машинах и приложениях.
- Восстановление данных, необходимых приложениям.
В бизнес-терминах RTO представляет время, когда бизнес-процессы не работают. Низкий уровень RTO идеально подходит для критически важных рабочих нагрузок, чтобы бизнес-процессы могли быстро возобновиться. Для рабочих нагрузок с более низким приоритетом более высокий уровень RTO может не влиять на производительность компании.
Цели точки восстановления
Чтобы успешно работать с облачной средой, необходимо реализовать резервные копии, репликацию или оба для защиты данных от сбоев. Цель точки восстановления (RPO) ссылается на время последнего захвата данных. Если система завершается сбоем, ее можно восстановить только до последней точки восстановления.
Вы измеряете RPO из последней точки восстановления до времени сбоя. Если вы измеряете RPO в часах, системный сбой приводит к потере данных в течение нескольких часов между последней точкой восстановления и сбоем. При измерении RPO в днях системный сбой приводит к потере данных в течение нескольких дней между последней точкой восстановления и сбоем. Однодневный RPO теоретически приводит к потере всех транзакций в день, что приводит к сбою.
Для критически важных систем измеряйте RPO в минутах или секундах, чтобы избежать потери доходов или прибыли. Короткий RPO обычно приводит к увеличению затрат на управление. Чтобы снизить эти затраты, необходимо создать базовый план управления, который фокусируется на самом длинном допустимом RPO. Затем можно уменьшить RPO конкретных платформ или рабочих нагрузок, которые гарантируют больше инвестиций.
Рекомендации по BCDR рабочей нагрузки
Рекомендации по обеспечению высокого уровня доступности и аварийного восстановления для рабочих нагрузок на основе RHEL зависят от технологий, поддерживающих эти рабочие нагрузки. Многие современные рабочие нагрузки могут воспользоваться собственными службами Azure для обеспечения избыточности между зонами доступности и между регионами. Используйте службы Azure для управления репликацией данных, автоматического масштабирования групп доступности и управления доменами обновления и сбоя. Эти методики упрощают обеспечение доступности развертываний RHEL.
Решения баз данных и другие приложения с отслеживанием состояния могут потребовать решения, ориентированные на операционную систему, для обеспечения высокой доступности и аварийного восстановления. Обратитесь к разработчику или поставщику приложений, чтобы проверить решения, которые поддерживаются приложениями. Дополнительные сведения см. в разделе "Высокий уровень доступности и аварийное восстановление" для приложений IaaS.
| Функция Или служба Azure | Определение | Рекомендации |
|---|---|---|
| Регионы | Группа центров обработки данных, расположенных рядом друг с другом, для обеспечения низкой задержки сети. Чтобы обеспечить быструю передачу данных, определенная региональная сеть подключает центры обработки данных. | При выборе региона Azure рассмотрите расположение центров обработки данных, пользователей и внутренних данных. Проверьте доступность служб, необходимых в выбранном регионе. Для развертываний RHEL может потребоваться один регион, а затем можно добавить дополнительные регионы в будущем для целей BCDR. |
| Azure ExpressRoute | Служба Azure, которую можно использовать для установления частных подключений от центров обработки данных Майкрософт к собственной инфраструктуре или к объекту совместного размещения. | ExpressRoute проходит общедоступный Интернет и предоставляет выделенное частное подключение. Эта конфигурация является общим требованием для крупномасштабных развертываний RHEL. ExpressRoute — это общая служба, поэтому необходимо тщательно спланировать емкость пропускной способности для удовлетворения общих потребностей пропускной способности предприятия. Если у вас недостаточно пропускной способности, вы можете скомпрометировать взаимодействие с пользователем или доступ к критически важным службам в центре обработки данных. Убедитесь, что вы развертываете ExpressRoute в устойчивом режиме между регионами и расположениями пиринга. |
| Зоны доступности | Отдельные группы центров обработки данных, имеющие собственную мощность, охлаждение и сетевые системы в регионе Azure. Зоны доступности обеспечивают высокий уровень доступности и устойчивость к сбоям центра обработки данных. | Чтобы обеспечить соглашение об уровне обслуживания (SLA), используйте зоны доступности с инфраструктурой RHEL, когда это возможно. Зоны доступности обеспечивают избыточность центра обработки данных в пределах региона. Но не каждый регион имеет зоны доступности, поэтому необходимо тщательно планировать. Службы RHEL, такие как Azure Red Hat OpenShift и службы управления целевыми зонами, поддерживают зоны доступности. |
| Группы доступности | Логическое группирование виртуальных машин. По крайней мере одна виртуальная машина всегда работает и работает во время запланированных или незапланированных событий обслуживания. Домен сбоя — это подмножество группы доступности, которая использует общую физическую инфраструктуру, например питание или сеть. При распределении виртуальных машин между различными доменами сбоя группа доступности снижает влияние сбоев оборудования на доступность виртуальной машины. | Группы доступности обеспечивают высокий уровень обслуживания. Группы доступности подходят для инфраструктуры RHEL, если регион не имеет зон доступности. Группы доступности имеют только аппаратное избыточность, аналогичное правилам защиты от сходства гипервизора. Таким образом, если у ваших регионов нет зон доступности, вам потребуется многорегионная стратегия для центра обработки данных и географической избыточности. |
| Azure Load Balancer | Служба балансировки нагрузки сети. Подсистема балансировки нагрузки позволяет эффективно предоставлять большой объем сетевого трафика на нескольких серверах Red Hat Enterprise. Служба работает с низкой задержкой и высокой пропускной способностью, что повышает производительность и доступность приложений. Load Balancer может автоматически масштабироваться в соответствии с требованиями. Чтобы повысить гибридное развертывание приложений, Load Balancer может распределять сетевой трафик между несколькими регионами в Azure, а также между локальными средами и Azure. |
Load Balancer распределяет сетевой трафик по нескольким серверам для обеспечения непрерывной доступности приложений и предотвращения сбоев в одной точке. При возникновении аварии Load Balancer перенаправляет трафик на операционные серверы, чтобы обеспечить быструю отработку отказа и восстановление. Эта операция сводит к минимуму время простоя и поддерживает бизнес-операции. Load Balancer может балансировать трафик между локальными серверами в облако Azure или на серверы в нескольких регионах Azure. Дополнительные сведения см. в разделе "Параметры балансировки нагрузки". |
| Управляемые диски | Виртуализированные диски, управляемые Azure. Вы выбираете размер и тип диска. Azure распределяет диски между различными единицами хранения, чтобы защитить данные от сбоев оборудования. | Управляемые диски являются лучшим выбором для всей инфраструктуры RHEL. Не используйте неуправляемые диски. Дополнительные сведения см. в разделе об уровне обслуживания для виртуальных машин. Разные типы дисков имеют разные производительность и затраты. Для компьютеров инфраструктуры RHEL рекомендуется ssd Azure Premium. Учитывайте затраты, производительность и доступность при выборе типа диска. При освобождении системы локальные ssd и временные диски удаляются. Создайте резервную копию данных на этих дисках соответствующим образом. |
| Azure Backup | Служба, которая предоставляет экономичные решения для резервного копирования данных и восстановления данных из облака Azure. | Резервное копирование — это надежное и экономичное решение, которое защищает инфраструктуру RHEL от сбоя или повреждения виртуальной машины. Используйте резервную копию для легкого восстановления всей виртуальной машины или определенных файлов и папок из облака, не создавая виртуальную машину или теряя данные. Вы также можете использовать другие поддерживаемые партнерские решения. |
| Azure Arc | Платформа, которая расширяет службы Azure таким образом, чтобы они выполнялись в различных средах, включая центры обработки данных, пограничные устройства и многооблачные архитектуры. Используйте Azure Arc для обеспечения согласованной разработки, операций и управления безопасностью для приложений и служб. | Используйте Azure Arc для реализации централизованных автоматических резервных копий и мониторинга, что повышает устойчивость с точки зрения BCDR. |
| Azure Site Recovery | Служба, предоставляющая возможности аварийного восстановления для обеспечения непрерывности бизнес-процессов. Вы можете реплицировать рабочие нагрузки и управлять ими, включая виртуальные машины Azure и локальные виртуальные машины в разных регионах. С помощью Site Recovery можно настроить репликацию, отработку отказа и процессы восстановления для защиты приложений во время запланированных сбоев и незапланированных сбоев. | Используйте Site Recovery, чтобы свести к минимуму проблемы восстановления, сократить затраты на инфраструктуру и обеспечить безопасное и надежное восстановление между регионами Azure или из локальных расположений в Azure. |
| Блокировки ресурсов | Функция Azure, которую можно использовать для ограничения пользователей и ролей в организации. Защитите критически важные ресурсы от случайных или вредоносных изменений. Вы можете заблокировать ресурс на различных уровнях области, таких как подписка, группа ресурсов или отдельные уровни ресурсов. В зависимости от типа блокировки можно запретить пользователям удалять или изменять ресурс, но они по-прежнему могут считывать свою конфигурацию. | Чтобы защитить всю инфраструктуру RHEL и виртуальные машины золотого образа, используйте блокировки ресурсов. Чтобы предотвратить случайное потеря важных компьютеров, примените блокировку удаления как минимум. Примените блокировку ReadOnly к компьютерам инфраструктуры RHEL, так как они часто не изменяются. Внесите изменения только во время соответствующих окон элементов управления изменениями. |
Рекомендации по BCDR платформы RHEL
Дополнительные сведения о возможностях BCDR для инфраструктуры платформы RHEL см. в следующем разделе:
- Архитектура высокого уровня доступности со спутником.
- Архитектура высокого уровня доступности платформы Ansible Automation.
- Архитектура управления удостоверениями с высоким уровнем доступности.
Рекомендации по проектированию
Для облачных приложений в контейнерах Linux используйте платформу на основе Kubernetes, чтобы обеспечить масштабируемость, высокий уровень доступности и избыточность. Рассмотрите возможность использования платформы Azure Red Hat OpenShift или самостоятельного развертывания OpenShift с реплицированным или геореплицированным хранилищем.
Для интерфейсов собственных веб-приложений и приложений без отслеживания состояния можно использовать многие собственные службы Azure, обеспечивающие доступность приложений. Архитектуры, использующие такие службы, см. в следующих статье:
- Базовое высокодоступное веб-приложение, избыточное между зонами.
- Высокодоступное веб-приложение с высоким уровнем доступности.
Предыдущие архитектуры используют различные службы Azure для зон доступности. Архитектура с несколькими регионами использует функции георепликации для содержимого и Azure Front Door в качестве службы балансировки нагрузки.
Для многих традиционных приложений с отслеживанием состояния, требующих высокой доступности, RHEL предлагает надстройку Pacemaker с высоким уровнем доступности. Вы можете получить системы с этой функцией из Azure Marketplace или развернуть пользовательский образ с помощью необходимых компонентов программного обеспечения. Дополнительные сведения см. в статье "Настройка кластера высокой доступности Red Hat" в Microsoft Azure.
Проблемы с доступностью влияют на сбои служб и время отклика службы. Снижение качества обслуживания может произойти, что может привести к снижению качества обслуживания клиента. Чтобы обеспечить поддержание уровня производительности и достаточной емкости в требуемых регионах, используйте функцию резервирования емкости Azure по запросу.
Надежность
Многие понятия, применяемые к инфраструктуре как инфраструктуре виртуальных машин службы, также применяются к архитектурам RHEL. Дополнительные сведения см. в разделе "Принципы проектирования надежности".
Кластеры
Azure не поддерживает объединение служб Центра приложений и базы данных с высоким уровнем доступности в одном кластере RHEL Pacemaker. Чтобы устранить это ограничение, разделите их на отдельные кластеры. Вы можете объединить до пяти кластеров центральных служб в паре виртуальных машин.
Для BCDR в SAP рассмотрите следующие службы для запуска кластеров центральных служб SAP:
- Кластер RHEL Pacemaker: устройства блоков STONITH не поддерживаются, но вы можете полагаться на агент забора Azure.
- Программное обеспечение кластера, сертифицированное не от Майкрософт, изучить этот параметр, если он соответствует вашим требованиям.
Выберите соответствующую службу в зависимости от ваших потребностей и операционной системы.
Дополнительные сведения см. в разделе:
- Настройте кластер Red Hat с высоким уровнем доступности в Microsoft Azure для RHEL 9.
- Настройте кластеры высокого уровня доступности и управляйте ими для RHEL 9.
- Документация по RHEL 8.
Реплики коллекции вычислений Azure
Вы можете использовать коллекцию вычислений для хранения золотых образов для развертываний. Используйте эти образы для аварийного восстановления приложений и средств. Коллекция вычислений может использовать высокодоступные ресурсы с учетными записями хранилища, избыточного между зонами (ZRS), в регионах, поддерживающих зоны доступности. ZRS обеспечивает устойчивость к зональным сбоям. Вы также можете реплицировать изображения коллекции в другие регионы или географические регионы.
Примечание.
Рекомендуется иметь по крайней мере две галереи в разных регионах.
Site Recovery
Site Recovery может повысить устойчивость некоторых компонентов RHEL. Список поддерживаемых серверов восстановления сайта RHEL см . в таблице поддержки аварийного восстановления виртуальных машин Azure с помощью Site Recovery. Вы также можете настроить Site Recovery в качестве отработки отказа из локальных сред в облако. Чтобы получить оценку затрат на Site Recovery, используйте планировщик развертывания Site Recovery.
Узлы кластера восстановления
Чтобы уменьшить количество осРВ и повысить устойчивость, можно использовать активные или резервные узлы удаленного кластера восстановления. Необходимо вручную настроить элементы кластера аварийного восстановления. Например, необходимо применить конфигурации для настройки ресурсов и копирования данных.