Надежность
Предположим, что вы отвечаете за работу медицинской системы в организации здравоохранения. Для врачей и других медицинских работников простой недопустим. Они должны иметь доступ к клиническим ИТ-системам круглосуточно, чтобы гарантировать, что они всегда обеспечивают наивысший уровень качества помощи.
Чтобы соблюдать это требование круглосуточный доступности, приложения должны обрабатывать любые ошибки с минимальными последствиями для пользователей. Как обеспечить работоспособность приложений в случае локальных инцидентов и крупномасштабных аварий?
В этом уроке вы узнаете, как включить элементы из основы надежности в дизайн архитектуры.
Что такое надежность?
В сложном приложении может случиться множество различных проблем с любым числом компонентов при любом масштабе. Возможен сбой отдельных серверов и жестких дисков. При ошибке развертывания могут непреднамеренно удалиться все таблицы в базе данных. Весь центр обработки данных может стать недоступным. При выполнении программы-шантажиста могут быть зашифрованы все данные. Очень важно, чтобы приложение было надежным и могло справляться как с локальными, так и с масштабными инцидентами.
Обеспечивая надежность, вы фокусируетесь на бесперебойной работе в случае мелких инцидентов и временных проблем, таких как частичные сбои в работе сети. Вы можете убедиться, что приложение обрабатывает локализованные сбои, интегрируя высокий уровень доступности в каждый компонент. Эта конструкция приложения устраняет отдельные точки сбоя. Такое проектирование также сводит к минимуму влияние обслуживания инфраструктуры. Проекты высокой доступности обычно стремятся устранить последствия инцидентов быстро и автоматически, а также обеспечить, чтобы система продолжала обрабатывать запросы без каких-то последствий.
Выполняя разработку с учетом надежности, следует также сосредоточиться на восстановлении в случае потери данных и масштабных аварий. Восстановление после инцидентов таких типов часто требует активных действий со стороны пользователя, но автоматические шаги по восстановлению позволяют сократить время на восстановление. Инциденты такого типа иногда могут приводить к некоторым простоям или потере данных. Аварийное восстановление зависит не только от тщательного планирования, но и от точного выполнения плана.
Обеспечение высокой доступности и возможности восстановления при разработке архитектуры позволяет защитить компанию от финансовых убытков в результате простоя и потери данных. Они также защищают ваш бизнес от потери репутации, вызванной потерей доверия от ваших клиентов.
Интеграция надежности при разработке гарантирует, что приложение может соответствовать обязательствам, которые вы дали своим клиентам. Вы хотите убедиться, что системы доступны конечным пользователям и могут восстановиться после любых сбоев.
Сборка высокодоступной архитектуры
Чтобы обеспечить доступность, определите соглашение об уровне обслуживания (SLA), условия которого вы будете выполнять. Изучите потенциальные возможности высокого уровня доступности вашего приложения относительно обслуживания и определите, где у вас есть надлежащее покрытие и где необходимо внести улучшения. Целью является добавление избыточности на уровне компонентов архитектуры, чтобы уменьшить возможность сбоев в работе.
Примеры компонентов разработки для обеспечения высокого уровня доступности включают кластеризацию и балансировку нагрузки.
Кластеризация заменяет одну виртуальную машину набором координированных виртуальных машин. Когда происходит сбой одной виртуальной машины или она становится недоступной, службы могут выполнить отработку отказа и перейти на другую службу, которая может обслуживать запросы.
При балансировке нагрузки запросы распространяются по многим экземплярам службы, обнаруживаются поврежденные экземпляры и предотвращается направление к ним запросов.
Создание архитектуры, которая может быть восстановлена после сбоя
Для обеспечения возможности восстановления следует выполнить анализ, в ходе которого проверяется возможность потери данных и сценарии простоя. Анализ должен включать в себя изучение стратегий восстановления и компромиссы по рентабельности. Это упражнение дает важное представление о приоритетах вашей организации и помогает уточнить роль приложения. Результаты анализа должны содержать следующие значения длительности для приложения:
Цель точки восстановления (RPO): максимальная длительность допустимой потери данных. RPO измеряется в единицах времени, а не объема. Например, "данные за 30 минут", "данные за четыре часа" и т. д. RPO устанавливает ограничения на случай потери данных, но не кражи.
Цель времени восстановления (RTO) — максимальная длительность допустимого простоя, в которой спецификация определяет время простоя. Например, если допустимая продолжительность простоя составляет восемь часов, если произошла катастрофа, то ваш RTO составляет восемь часов.
Определив RPO и RTO, вы сможете на их основе правильно внедрить в архитектуру функции резервного копирования, восстановления, репликации и восстановления после сбоев.
Каждый поставщик облачных служб предлагает набор служб и функций, которые можно использовать для повышения уровня доступности и восстанавливаемости вашего приложения. По возможности используйте имеющиеся службы и рекомендации и старайтесь не создавать собственные.
Может произойти сбой жестких дисков, центр обработки данных может оказаться недоступным, а злоумышленник может атаковать систему. Важно поддерживать хорошую репутацию среди своих клиентов за счет доступности и возможности восстановления. Доступность — это поддержка бесперебойной работы в таких условиях, как перебои в работе сети, а возможность восстановления — это извлечение данных после аварии.