Рабочие нагрузки уровня оператора в Azure

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

• Минимизация потери жизни или травмы.
• Соблюдение нормативных требований к надежности, чтобы избежать оплаты штрафов.
• Оптимизация службы для клиентов для минимизации оттока конкурентов.
• Собрание договорных соглашений об уровне обслуживания (СОГЛАШЕНИЯ об уровне обслуживания) с бизнес-клиентами или государственными клиентами.

В этой серии статей применяется методология проектирования критически важных рабочих нагрузок для информирования о создании и эксплуатации высоконадежной, устойчивой и доступной рабочей нагрузки телекоммуникации в Azure.

Примечание.

Статьи в этой серии сосредоточены на предоставлении дополнительных критически важных соображений при разработке для 99,999% (5 9s) уровня надежности в отрасли телекоммуникаций.

Что такое рабочая нагрузка уровня оператора?

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

Термин "критически важный" относится к классификации критической степени, в которой значительные финансовые затраты (критически важные для бизнеса) или затраты человека (критически важные для безопасности) связаны с недоступностью или недостаточной производительностью.

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

Операционный аспект рабочей нагрузки включает в себя измерение надежности и целевые показатели, которые он должен соответствовать или превышать. Высоконадежные системы обычно нацелены на время простоя 99,999 % (обычно называются "5 9s") или 0,001% простоя в год (приблизительно 5 минут). Некоторые системы предназначены для 99,9999 % времени простоя или 30 секунд в год или даже более высокого уровня надежности. Это охватывает все формы и причины сбоя : запланированное обслуживание, сбой инфраструктуры, ошибка человека, проблемы программного обеспечения и даже стихийные бедствия.

Несмотря на то что используемая платформа изменилась от выделенного, частного оборудования через коммерческое, вне полковое оборудование до облаков OpenStack или VMware, телекоммуникационные компании последовательно предоставляют услуги, достигая ≤ 5 минут простоя в год, и во многих случаях достигается ≤ 30 секунд простоя из-за незапланированных сбоев.

Каковы распространенные проблемы?

Создание рабочих нагрузок уровня оператора является проблемой по следующим основным причинам:

Подход к подъему и смене

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

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

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

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

Монолитные решения

Опыт в различных критически важных отраслях показывает, что это не реалистично, чтобы попытаться создать монолитное решение, которое позволит достичь требуемых уровней доступности. В сложной системе слишком много потенциальных источников сбоев. Вместо этого успешные решения состоят из отдельных независимых и избыточных элементов. Каждая единица имеет относительно базовую доступность (обычно около 99,9%), но при объединении общего решения достигает необходимых целей доступности. Затем искусство инженерии класса перевозчика становится обеспечением того, что единственные зависимости, общие для избыточных элементов являются теми, которые абсолютно необходимы, так как они оказывают наиболее значительное влияние на общую доступность, часто порядка величины больше, чем что-либо другое в дизайне.

Только строительство зональной избыточности

Использование Microsoft Azure Зоны доступности является основным выбором для снижения риска сбоя из-за сбоя оборудования или локализованных экологических проблем. Однако для обеспечения доступности на уровне перевозчиков недостаточно, в основном по следующим причинам:

• Зоны доступности (AZ) разработаны таким образом, чтобы задержка сети между двумя зонами в одном регионе была ≤ 2 мс. AZs не может быть широко и географически распределено. Таким образом, AZs разделяют коррелированный риск сбоя из-за стихийных бедствий, таких как наводнения или массовые сбои электроэнергии, которые могут отключить несколько AZ в пределах региона.

• Многие службы Azure явно предназначены для избыточности между зонами, чтобы приложения, использующие их, не нуждались в явной логике, чтобы получить выгоду от получения доступности. Эта функция избыточности в службе требует совместной работы между элементами в каждой зоне. Часто возникает неизбежная опасность сбоя программного обеспечения в одной зоне, которая приводит к коррелируемым сбоям в других зонах. Например, любая проблема с секретом или сертификатом, используемым с избыточной зоной службой, может повлиять на все AZ одновременно.

Каковы ключевые области проектирования?

При разработке рабочей нагрузки уровня оператора рассмотрите следующие области:

Область проектирования	Description
Отказоустойчивость	Проектирование приложений должно разрешать неизбежные сбои, чтобы приложение в целом продолжало работать на определенном уровне. Проект должен свести к минимуму точки сбоя и принять федеративный подход.
Модель данных	Проект должен решать потребности в согласованности, доступности и отказоустойчивости секций базы данных. Доступность уровня оператора требует, чтобы приложение развертывалось в нескольких регионах. Для этого развертывания необходимо тщательно думать о том, как данные приложения будут управляться в этих регионах.
Моделирование работоспособности	Эффективная модель работоспособности обеспечивает наблюдаемость всех компонентов, платформы и приложений, чтобы можно было быстро обнаружить проблемы и ответ будет готов либо через самовосстановление, либо другие исправления.
Тестирование и проверка	Проектирование и реализация приложения должны быть тщательно проверены. Кроме того, необходимо проверить интеграцию и развертывание приложения в целом.

Следующий шаг

Начните с изучения принципов проектирования для сценариев приложений уровня оператора.

Принципы проектирования