Разработка для резервного копирования и восстановления
Таким организациям, как Tailwind Traders, требуется высокий уровень надежности своих критически важных приложений. Для достижения необходимого уровня надежности для локальных приложений обычно требуется приобрести дополнительные вычислительные ресурсы, такие как серверы и хранилища. Приобретение дополнительных вычислительных ресурсов создает избыточность в локальной инфраструктуре.
Также важно, чтобы любое критически важное приложение и связанные с ним данные можно было восстановить, в идеале — до момента отказа. Такая возможность восстановления часто обеспечивается с помощью компонентов и процедур резервного копирования и восстановления. Для организаций с приложениями, размещенными в Azure, или с развертываниями гибридных приложений существуют другие рекомендации и варианты.
Надежные приложения:
Устойчивость к сбою компонентов.
Высокая доступность и возможность находиться в работоспособном состоянии без длительных простоев.
Чтобы обеспечить требуемую устойчивость и высокий уровень доступности, необходимо сначала определить требования.
Примечание.
В этом модуле под термином "устойчивость" понимается способность системы корректно работать и восстанавливаться после сбоев, как случайных, так и вредоносных.
Обозначение ваших требований
Определение требований включает в себя следующее.
Определение бизнес-потребностей.
Создание плана устойчивости для соответствия этим потребностям.
Используйте следующую таблицу для получения рекомендаций по этому процессу.
| Рассмотрение | Description |
|---|---|
| Каковы рабочие нагрузки и каково их использование? | Рабочая нагрузка — это отдельная возможность или задача, которая логически отделена от других задач с точки зрения требований к бизнес-логике и хранению данных. Каждая рабочая нагрузка, вероятно, имеет различные требования к доступности, масштабируемости, согласованности данных и аварийному восстановлению. |
| Каковы шаблоны использования рабочих нагрузок? | Шаблоны использования могут определять требования. Определите различия в требованиях как в критических, так и некритических периодах. Чтобы обеспечить бесперебойную работу, планируйте избыточность в нескольких регионах на случай сбоя одного региона. И наоборот, чтобы свести к минимуму затраты во время некритических периодов, можно запустить приложение в одном регионе. |
| Каковы метрики доступности? | Среднее время восстановления (MTTR) и среднее время между сбоями (MTBF) — это обычно используемые метрики. MTBF — это продолжительность работы, которую можно ожидать от компонента между отключениями. MTTR — это среднее время, необходимое для восстановления компонента после сбоя. Используйте эти метрики, чтобы определить, где необходимо добавить избыточность, и определить соглашения об уровне обслуживания для клиентов. |
| Каковы метрики восстановления? | Целевое время восстановления (RTO) — это максимально допустимое время, в течение которого одно из приложений может быть недоступно после инцидента. Целевая точка восстановления (RPO) — это максимальная продолжительность потери данных, которая является приемлемой во время аварии. Также рекомендуется учитывать целевой уровень восстановления (RLO). Эта метрика определяет степень детализации восстановления. Иными словами, требуется ли возможность восстановления фермы серверов, веб-приложения, сайта или только определенного элемента. Чтобы определить эти значения, выполните оценку рисков. Убедитесь, что вы понимаете стоимость и риски простоя или потери данных в организации. |
| Каковы целевые показатели доступности рабочих нагрузок? | Чтобы обеспечить соответствие архитектуры приложения требованиям бизнеса, определите целевые соглашения об уровне обслуживания для каждой рабочей нагрузки. Помимо зависимостей приложений, также учитывайте затраты и сложности, связанные с удовлетворением требований к доступности. |
| Что такое соглашения об уровне обслуживания? | В Azure соглашение об уровне обслуживания описывает обязательства корпорации Майкрософт в отношении времени доступности и подключения. Если в SLA для конкретной службы указано 99,9 %, это означает, что вы должны ожидать, что служба будет доступна 99,9 % времени. |
Совет
Если показатель MTTR какого-либо критического компонента в высокодоступном сценарии превышает значение RTO системы, то сбой в системе может привести к неприемлемому нарушению бизнес-процессов. Иными словами, вы не сможете восстановить систему в пределах установленного RTO.
Определите собственные целевые значения соглашения об уровне обслуживания для каждой рабочей нагрузки в решении, ответив на приведенные выше вопросы. Это поможет убедиться, что архитектура соответствует бизнес-требованиям. Например, если для рабочей нагрузки требуется 99,99 процентов времени доступности, но она зависит от службы с соглашением об уровне обслуживания 99,9 процентов, эта служба не может быть единой точкой отказа в системе.
Определив требования к восстановлению, можно выбрать подходящую технологию восстановления.