Экспорт (0) Печать
Развернуть все

Аварийное восстановление и высокий уровень доступности для приложений Azure

Обновлено: Апрель 2014 г.

Основные авторы: Майкл МакКеон (Michael McKeown), архитектор облачных решений (Aditi); Хану Коммалапати (Hanu Kommalapati), главный технический специалист по пропагандированию технологии (Майкрософт)

Соавторы: Джейсон Рот (Jason Roth)

Рецензенты: Патрик Уиклайн (Patrick Wickline), Деннис Малдер (Dennis Mulder), Стив Хоуард (Steve Howard), Тим Виман (Tim Wieman), Джеймс Подгорски (James Podgorski), Райан Берри (Ryan Berry), Швета Гупта (Shweta Gupta), Харри Чен (Harry Chen), Джим Бланчард (Jim Blanchard), Энди Робертс (Andy Roberts), Кристиан Элс (Christian Els)

Этот документ посвящен теме высокого уровня доступности для приложений, работающих в Azure. Общая стратегия обеспечения высокого уровня доступности включает в себя также сферу аварийного восстановления (DR). Для планирования устранения сбоев и аварий в облаке необходимо быстро выявлять их. После этого следует реализовать стратегию, соответствующую допустимым срокам простоя приложения. Кроме того, необходимо учитывать объем потери данных, допустимый для приложения, без серьезных последствий для компании после восстановления работоспособности.

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

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

Этот технический документ описывает действия (с точки зрения архитектуры), необходимые для защиты развертывания Azure от сбоев. После этого вы сможете реализовать более общий процесс обеспечения непрерывности бизнеса. План обеспечения непрерывности бизнеса — это основа для продолжения работы в неблагоприятных условиях. Это может быть вызвано технологическим сбоем, например недоступностью службы, или стихийным бедствием, таким как буря или авария электросети. Устойчивость приложения к авариям — это только часть более фундаментального процесса DR, как описано в документе NIST. Руководство по планированию непредвиденных ситуаций для ИТ-систем.

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

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

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

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

Рассмотрим автомобиль в качестве аналогии средства с высоким уровнем доступности. Даже качественные детали и превосходное проектирование не могут гарантировать, что время от времени не будут возникать отказы. Например, если шина автомобиля спущена, автомобиль все еще работает, но с ухудшенной функциональностью. Если вы подготовились к этой потенциальной проблеме, то можете воспользоваться одной из запасных шин с тонким ободом, чтобы доехать до ремонтной мастерской. Хотя такая шина не позволяет быстро ехать, вы по-прежнему можете использовать автомобиль до замены шины. Аналогично облачная служба, для которой проведена подготовка к потенциальной потере возможностей, не позволит не столь серьезной проблеме вывести из строя все приложение. Это верно, даже если облачная служба должна работать с ограниченной функциональностью.

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

Доступное приложение учитывает доступность базовой инфраструктуры и зависимых служб. Доступные приложения устраняют отдельные точки сбоя за счет избыточности и устойчивой архитектуры. Если говорить о доступности в Azure, важно понимать принцип эффективной доступности платформы. Эффективная доступность учитывает соглашения об уровне обслуживания (SLA) каждой зависимой службы и их общее влияние на доступность всей системы.

Доступность системы — это мера, отражающая процентную долю временного окна, в течение которого система будет работать. Например, соглашение об уровне обслуживания в отношении доступности для по крайней мере двух экземпляров веб-роли или рабочей роли в Azure составляет 99,95 % (из 100 %). Оно не измеряет производительность или функциональность служб, работающих на этих ролях. Тем не менее на эффективную доступность облачной службы также влияют другие соглашения об уровне обслуживания зависимых служб. Чем больше частей в системе, тем больше внимания необходимо уделить тому, чтобы обеспечить для пользователей выполнение приложением требований к доступности.

Рассмотрим соглашения об уровне обслуживания следующих служб Azure: вычислений, базы данных SQL Azure и хранилища Azure.

 

Служба Azure Соглашение об уровне обслуживания Потенциальное время простоя (мин)/месяц (30 дней)

Среда выполнения приложений

99.95%

21,6

база данных SQL

99.90%

43,2

Хранилище

99.90%

43,2

Необходимо включить в план все службы, которые могут стать недоступными в разное время. В этом упрощенном примере общее время в месяц, в течение которого приложение может не работать, составляет 108 минут. Месяц длиной в 30 дней состоит всего из 43 200 минут. 108 минут — это 0,25 % от общего времени в месяце из 30 дней (43 200 минут). Это дает эффективную доступность для облачной службы в 99,75 %.

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

Масштабируемость напрямую влияет на доступность — приложение, которое выходит из строя при повышенной загрузке, становится недоступным. Масштабируемые приложения могут справляться с повышением спроса и обеспечивать согласующиеся результаты в допустимые временные окна. Если система масштабируема, она может масштабироваться по горизонтали или по вертикали, чтобы обрабатывать повышенную нагрузку, сохраняя при этом производительность. По сути горизонтальное масштабирование предусматривает добавление нескольких компьютеров такой же мощности (процессор, память, пропускная способность), а вертикальное масштабирование — увеличение мощности существующих компьютеров. В случае с Azure варианты вертикального масштабирования доступны (выбор компьютеров различной мощности для выполнения вычислений). Однако для изменения мощности компьютера необходимо повторное развертывание. Поэтому наиболее гибкие решения предусматривают горизонтальное масштабирование. Это особенно очевидно для вычислительных операций, так как можно легко увеличить число выполняющихся экземпляров любой веб-роли или рабочей роли. Эти дополнительные экземпляры будут использоваться для обработки большего объема трафика через веб-портал Azure, скрипты PowerShell или код. Решение должно быть основано на увеличении определенных отслеживаемых метрик. В этом сценарии производительность или метрики пользователей при повышении нагрузки значительно не меняются. Как правило, веб-роли и рабочие роли хранят любое состояние на внешних ресурсах. Это обеспечивает гибкую балансировку нагрузки и плавную обработку всех изменений в числе экземпляров. Горизонтальное масштабирование также хорошо работает со службами, например хранилищем Azure, которые не предоставляют многоуровневые возможности вертикального масштабирования.

Облачные развертывания следует рассматривать как коллекцию единиц масштабирования. Это позволяет приложению гибко обслуживать потребности в пропускной способности пользователей. Единицы масштабирования проще визуализировать на уровне веб-сервера и сервера приложений. Azure уже предоставляет вычислительные узлы без состояния с помощью веб-ролей и рабочих ролей. Добавление дополнительных единиц масштабирования вычислительных операций не вызовет никаких побочных эффектов в управлении состоянием приложения, поскольку эти единицы не имеют состояния. Единица масштабирования хранилища отвечает за управление секционированием данных — структурированных и неструктурированных. Примеры единицы масштабирования хранилища включают в себя раздел таблицы, контейнер большого двоичного объекта Azure и базу данных SQL. Даже использование нескольких учетных записей хранения Azure напрямую влияет на масштабируемость приложения. Облачная служба с высокой степенью масштабирования должна быть спроектирована так, чтобы включать в себя несколько единиц масштабирования хранилища. Например, если приложение использует реляционные данные, они должны быть секционированы по нескольким базам данных SQL. Это позволит хранилищу не отставать от гибкой модели единиц масштабирования вычислительных операций. Аналогично служба хранилища Azure позволяет использовать схемы секционирования данных, требующие тщательного проектирования для удовлетворения потребностей в пропускной способности вычислительного уровня. Список рекомендаций по проектированию масштабируемых облачных служб см. в документе Рекомендации по проектированию крупномасштабных служб в облачных службах Azure.

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

Облачное развертывание может перестать работать из-за систематического отключения зависимых служб или базовой инфраструктуры. В таких условиях план обеспечения непрерывности бизнеса инициирует процесс аварийного восстановления (DR). Этот процесс обычно затрагивает сотрудников отдела эксплуатации и включает в себя автоматизированные процедуры для повторной активации приложения в действующем центре обработки данных. Для этого необходимо переместить пользователей, данные и службы приложения в новый центр обработки данных. При этом используются носители резервных копий или репликация.

Рассмотрим предыдущую аналогию, в которой высокий уровень доступности сравнивался с возможностью замены спущенной шины на запасную. Аварийное восстановление, наоборот, подразумевает выполнение действий после автокатастрофы, когда автомобиль уже не функционирует. В этом случае наилучшим решением является поиск эффективного способа замены автомобиля, возможно путем вызова аварийной службы или при помощи друзей. В такой ситуации, скорее всего, задержка перед продолжением движения будет больше. Кроме того, ремонт и восстановление первоначального автомобиля будут сложнее. Аналогично и аварийное восстановление в другом центре обработки данных — это сложная задача, которая обычно подразумевает определенный простой и возможную потерю данных. Чтобы лучше понять и оценить стратегии аварийного восстановления, необходимо определить два термина: целевое время восстановления (RTO) и целевая точка восстановления (RPO).

Целевое время восстановления (RTO) — это максимальное время, выделенное для восстановления функциональности приложения. Оно основано на бизнес-требованиях и связано с важностью приложения. Критическим бизнес-приложениям необходимо низкое значение RTO.

Целевая точка восстановления (RPO) — это приемлемое временное окно потери данных вследствие процесса восстановления. Например, если RPO равна одному часу, то данные необходимо копировать в резервное хранилище или реплицировать по крайней мере каждый час. После возобновления работы приложения в другом центре обработки данных в резервных данных могут отсутствовать данные за один час. Подобно RTO, критическим приложениям необходимо намного меньшее значение RPO.

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

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

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

Если развернуто несколько экземпляров роли, Azure развертывает их в различных доменах сбоя. Граница домена сбоя — это, по сути, различные стойки оборудования в одном центре обработки данных. Домены сбоя снижают вероятность того, что локализованный сбой оборудования остановит работу приложения. Нельзя управлять числом доменов сбоя, выделенных для рабочей роли или веб-роли. Контроллер структуры использует выделенные ресурсы, отделенные от размещенных в Azure приложений. Время его бесперебойной работы составляет 100 %, так как он служит основой системы Azure. Он отслеживает и контролирует экземпляры ролей в доменах сбоя. На следующей диаграмме показаны общие ресурсы Azure, которые развертываются и управляются контроллером структуры (FC) в разных доменах сбоя.

Рис. 1. Изоляция доменов сбоя (в упрощенном виде)

Домены обновления схожи с доменами сбоя по функциональности, но поддерживают обновление, а не устраняют сбои. Домен обновления — это логическая единица разделения экземпляров, которая определяет, какие экземпляры в определенной службе обновляются в тот или иной момент времени. По умолчанию для развертывания размещенной службы заданы пять доменов обновления. Однако это число можно изменить в файле определения службы. Например, у вас восемь экземпляров веб-роли. Два экземпляра могут находиться в трех доменах обновления, а другие два экземпляра — в одном домене. Последовательность обновления определяется Azure, но основана на числе доменов обновления. Дополнительные сведения о доменах обновления см. в разделе Обновление службы Azure.

В дополнение к этим функциям платформы, поддерживающим высокую доступность среды вычислений, Azure внедряет возможности обеспечения высокого уровня доступности в другие службы. Например, хранилище Azure использует три реплики всех данных больших двоичных объектов, таблиц и очередей. Платформа также позволяет использовать георепликацию для хранения резервных копий больших двоичных объектов и таблиц в дополнительном центре обработки данных. Сеть доставки содержимого (CDN) позволяет кэшировать большие двоичные объекты по всему миру для обеспечения избыточности и масштабируемости. База данных SQL Azure также хранит несколько реплик. В дополнение к документу Техническое руководство по Azure для обеспечения непрерывности работы организации см. документ Рекомендации по проектированию крупномасштабных служб в облачных службах Azure. В них представлено полное описание функций обеспечения доступности платформы.

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

Большая часть этого документа посвящена облачным службам, которые используют модель «Платформа как услуга» (PaaS). Но существуют также определенные функции обеспечения доступности для виртуальных машин Azure, которые используют модель "Инфраструктура как услуга" (IaaS). Чтобы достичь высокого уровня доступности для виртуальных машин, необходимо использовать группы доступности. Группа доступности выполняет функцию, подобную доменам сбоя и доменам обновления. Azure располагает виртуальные машины в группе доступности так, чтобы не позволить локальным сбоям оборудования и операциям по обслуживанию вывести из строя все машины в этой группе. Группы доступности необходимы для выполнения соглашения об уровне обслуживания Azure по обеспечению доступности виртуальных машин. Дополнительные сведения см. в разделе Управление доступностью виртуальных машин. На следующей диаграмме показано представление двух групп доступности, которые группируют веб-машины и виртуальные машины SQL Server соответственно.

Рис. 2. Группы доступности для виртуальных машин Azure

Обратите внимание, что на предыдущей диаграмме SQL Server установлен и работает на виртуальных машинах. В этом отличие от предыдущего обсуждения базы данных SQL Azure, где база данных представлена как управляемая служба.

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

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

В варианте такого подхода используется служба хранилища Azure (большие двоичные объекты, таблицы или очереди) или очереди служебной шины в качестве расположения для отработки отказа при неудачных вызовах базы данных. Например, синхронный вызов другой службы (такой как база данных SQL Azure) в приложении постоянно завершается неудачей. Эти данные можно сериализовать в устойчивое хранилище. Позднее, когда служба или база данных восстановит работоспособность, приложение сможет повторно отправить запрос из хранилища. Отличие этой модели состоит в том, что промежуточное размещение не является константной частью рабочего процесса приложения. Оно используется только в сценариях сбоя.

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

Главный фактор при разработке приложения с высоким уровнем доступности — использование логики повторения попыток в коде для правильной обработки временно недоступной службы. Блок обработки непостоянных ошибок для приложений, разработанный группой шаблонов и методов Майкрософт, помогает разработчикам справиться с этим процессом. Слово "непостоянный" означает временное состояние, которое существует только в относительно короткий период времени. В контексте этого документа обработка временных ошибок — это часть разработки приложения с высоким уровнем доступности. Примеры непостоянных условий включают в себя временные ошибки сети и потерю подключения к базе данных.

Блок приложения для обработки временных ошибок — это упрощенный способ правильной обработки ошибок в коде. Он позволяет повысить доступность приложений, добавив надежную логику обработки временных ошибок. В большинстве случаев эта логика обрабатывает краткие прерывания в работе и повторно связывает отправителя и получателя после одной или нескольких неудачных попыток. Успешная попытка повтора обычно остается незамеченной пользователями приложения.

В распоряжении разработчиков есть три варианта управления применяемой логикой повторов: добавочный, с фиксированным интервалом и экспоненциальный. Добавочная логика линейно увеличивает время ожидания перед каждым новым повтором (например, 1, 2, 3 и 4 секунды). Логика с фиксированным интервалом не изменяет время ожидания между каждым повтором (например, 2 секунды). Экспоненциальная логика (для более случайного процесса) увеличивает ожидание между повторными попытками. Но это происходит экспоненциально (например, 2, 4, 8 и 16 секунд).

Высокоуровневая стратегия для кода выглядит следующим образом.

  1. Определите стратегию и политику повторений.

  2. Повторите операцию, которая могла привести к временной ошибке.

  3. Если возникает временная ошибка, вызовите политику повторения.

  4. Если все повторы приводят к ошибке, регистрируйте окончательное исключение.

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

Ссылочные данные — это данные приложения только для чтения. Эти данные предоставляют бизнес-контекст, в котором приложение создает транзакционные данные в ходе деятельности компании. Транзакционные данные — это функция от ссылочных данных на определенный момент времени. Поэтому их целостность зависит от моментального снимка ссылочных данных в момент совершения транзакции. Это несколько расплывчатое определение, но в целях этого документа оно должно быть достаточным.

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

Веб-роли и рабочие роли Azure, использующие ссылочные данные, можно сделать автономными во время выполнения, развернув ссылочные данные вместе с приложением. Если размер локального хранилища позволяет это сделать, то такое состояние будет идеальным. Внедренные базы данных (SQL или отличные от SQL) или даже XML-файлы, развернутые в локальной файловой системе, помогут реализовать автономность единиц масштабирования вычислений Azure. Однако необходим механизм для обновления данных в каждой роли без повторного развертывания. Для этого разместите все операции обновления ссылочных данных в конечной точке облачного хранилища (например, в хранилище больших двоичных объектов Azure или в базе данных SQL). Добавьте для каждой роли код, который загружает обновления данных в вычислительные узлы при запуске роли. Или добавьте код, который позволяет администратору выполнить принудительную загрузку в экземпляры ролей. Для повышения доступности роли также должны содержать набор ссылочных данных в случае сбоя хранилища. Это позволит ролям начать работу с базовым набором ссылочных данных, пока хранилище не станет доступным для обновления.

Рис. 3. Высокий уровень доступности приложения за счет автономных вычислительных узлов

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

Транзакционные данные — это данные, создаваемые приложением в бизнес-контексте. Транзакционные данные являются сочетанием набора бизнес-процессов, реализованных приложением, и ссылочных данных, которые поддерживают эти процессы. Примерами транзакционных данных служат заказы, уведомления об отгрузке, счета и потенциальные клиенты в CRM. Созданные транзакционные данные будут переданы во внешние системы для учета или дальнейшей обработки.

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

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

Следующая последовательность описывает рабочий процесс, который отделяет получение транзакционных данных от их обработки.

  1. Вычислительный веб-узел: представляет ссылочные данные.

  2. Внешнее хранилище: сохраняет промежуточные транзакционные данные.

  3. Вычислительный веб-узел: выполняет транзакцию пользователя.

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

  5. Вычислительный веб-узел: уведомляет пользователя о завершении транзакции.

  6. Фоновый вычислительный узел: извлекает транзакционные данные, выполняет при необходимости постобработку данных и отправляет их в место окончательного хранения в текущей системе.

На следующей схеме показана одна возможная реализация такой архитектуры в облачной службе Azure.

Рис. 4. Высокий уровень доступности приложений с использованием слабой взаимосвязи

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

Веб-роль автономна от остальной инфраструктуры. Ее доступность зависит от сочетания очередей веб-роли и Azure, а не всей инфраструктуры. Помимо высокого уровня доступности, такой подход позволяет веб-роли выполнять горизонтальное масштабирование независимо от фонового хранилища. Такая модель обеспечения высокого уровня доступности может повлиять на экономику операций. Дополнительные компоненты, например очереди и рабочие роли Azure, могут повлиять на ежемесячные затраты на использование.

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

  • Рабочую роль можно разместить между веб-ролью и очередью хранилища.

  • Очередь служебной шины можно использовать вместо очереди службы хранилища Azure.

  • Конечной точкой назначения может быть хранилище Azure или другой поставщик базы данных.

  • Azure Caching можно использовать на веб-уровне для выполнения требований к кэшированию после обработки транзакции.

В дополнение к шаблонам, описанным в этом разделе, важно отметить, что масштабируемость облачной службы напрямую влияет на доступность. Если из-за повышенной нагрузки служба перестанет отвечать, пользователям будет казаться, что приложение не работает. Следуйте инструкциям по обеспечению масштабируемости в зависимости от ожидаемой и будущей нагрузки приложения. Для обеспечения максимального масштабирования необходимо учесть множество факторов, например использование одной или нескольких учетных записей хранения, сегментирование между несколькими базами данных и стратегии кэширования. Подробное описание этих шаблонов см. в документе Рекомендации по проектированию крупномасштабных служб в облачных службах Azure.

Хотя высокий уровень доступности и позволяет управлять временными ошибками, аварийное восстановление связано с необратимой потерей функциональности приложения. Например, рассмотрим ситуацию, когда один или несколько центров обработки данных выходят из строя. В этом случае требуется план для выполнения приложения или доступа к данным за пределами центра обработки данных. Выполнение этого плана связано с людьми, процессами и вспомогательными приложениями, которые позволяют системе работать. Уровень функциональности службы во время аварии определяется владельцами компании и технологий, которые регламентируют режим работы после сбоя. Возможны разные варианты: полная недоступность, частичная недоступность (ограниченная функциональность или задержка при обработке) или полная доступность.

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

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

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

На схеме ниже пользователи подключаются к URL-адресу, указанному для диспетчера трафика Windows Azure (http://myATMURL.trafficmanager.net), который абстрагирует фактические URL-адреса сайтов (http://app1URL.cloudapp.net и http://app2URL.cloudapp.net). В зависимости от способа настройки условий маршрутизации пользователей их данные будут передаваться на соответствующий фактический сайт, если того требует политика. Доступные параметры политики: циклический перебор, оптимизация производительности или отработка отказа. В целях данного технического документа мы рассмотрим только вариант отработки отказа.

Рис. 5. Маршрутизация с помощью диспетчера трафика Azure

При настройке WATM вы указываете новый DNS-префикс диспетчера трафика. Это префикс URL-адреса, который будет предоставлен пользователям для доступа к службе. Диспетчер трафика Windows Azure теперь реализует балансировку нагрузки на более высоком уровне, а не на уровне центра обработки данных. DNS диспетчера трафика сопоставляется с записью CNAME для всех развертываний, которыми он управляет.

В диспетчере трафика Windows Azure вы задаете приоритет развертываний, которые будут использоваться при возникновении сбоя. Диспетчер трафика Windows Azure отслеживает конечные точки развертываний и сообщает о сбое основного развертывания. При сбое диспетчер трафика Windows Azure проходит по списку развертываний с заданными приоритетами и направляет пользователей на следующее доступное развертывание в списке.

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

Дополнительные сведения о работе диспетчера трафика Azure см. по следующих ссылкам.

В следующих разделах описано несколько аварийных сценариев разных типов. Сбой центра обработки данных не является единственной причиной сбоев на уровне приложения. Плохое проектирование или ошибки администрирования также могут привести к выходу системы из строя. Важно учитывать возможные причины сбоев во время разработки и тестирования плана восстановления. Хороший план использует преимущества возможностей Azure и дополняет их с помощью специальных стратегий для приложения. Выбираемая реакция определяется важностью приложения, RPO и RTO.

Как упоминалось ранее, контроллер структуры Azure автоматически обрабатывает сбои, возникшие в базовом оборудовании или программном обеспечении операционной системы на виртуальной хост-машине. Azure создает новый экземпляр роли на работающем сервере и добавляет его в подсистему балансировки нагрузки. Если число экземпляров ролей больше одного, то Azure при замене неисправного узла перемещает обработку на другие рабочие экземпляры роли.

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

Azure трижды автоматически сохраняет данные хранилища Azure и базы данных SQL Azure отдельно в различных доменах сбоя в одном центре обработки данных. Если используется георепликация, данные сохраняются в трех дополнительных экземплярах в другом центре обработки данных. Однако, если пользователи или приложение повреждают данные в первичной копии, происходит быстрая репликация в другие копии. К сожалению, это приводит к получению трех копий поврежденных данных.

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

Если части сети Azure недоступны, доступ к данным или приложению может быть невозможен. Если один или несколько экземпляров роли недоступны из-за проблем с сетью, Azure использует остальные доступные экземпляры приложения. Если приложение не может получить доступ к данным из-за сбоя в сети Azure, потенциально можно работать в режиме ухудшенной функциональности, используя локально кэшированные данные. Необходимо разработать стратегию аварийного восстановления для работы приложения в режиме ухудшенной функциональности. Для некоторых приложений это может быть непрактично. Другой вариант — хранить данные в другом месте до восстановления связи. Если режим ухудшенной функциональности неприемлем, остаются варианты: простой приложения или переход на другой центр обработки данных. Разработка приложения в режиме ограниченной функциональности — одновременно деловое и техническое решение. Это подробнее обсуждается в разделе Ограниченная функциональность приложения.

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

Например, при использовании кэширования доступна относительно новая альтернатива — мультитенантная модель Shared Caching. Кэш роли Azure обеспечивает кэширование для приложения из развертывания облачной службы (забегая вперед — это также рекомендуемый способ использования компонента кэша). Хотя, пока Caching доступен только из одного развертывания, он предоставляет потенциальные преимущества для аварийного восстановления. Во-первых, теперь служба работает на ролях, локальных для развертывания. Поэтому вы сможете лучше отслеживать и контролировать состояние кэша как часть общих процессов управления облачной службой. Этот тип кэширования также предоставляет новые функции. Одна из них — высокая доступность для кэшированных данных. Это позволяет сохранить кэшированные данные при сбое одного узла за счет хранения копий на других узлах. Обратите внимание, что высокий уровень доступности уменьшает пропускную способность и увеличивает задержку из-за обновления дополнительной копии при записи. Также удваивается объем памяти, используемый для каждого элемента, и это необходимо учитывать при планировании. Этот конкретный пример показывает, что каждая зависимая служба может предоставлять возможности, позволяющие повысить общий уровень доступности и устойчивости к критическим сбоям.

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

Предыдущие сбои в основном представляли неисправности, которые можно устранить в рамках одного центра обработки данных Azure. Однако следует также подготовиться к тому, что выйти из строя может весь центр обработки данных. В этом случае локальные избыточные копии данных недоступны. Если вы включили георепликацию, три дополнительные копии больших двоичных объектов и таблиц будут храниться в центре обработки данных в другом регионе. Если Майкрософт объявляет, что центр обработки данных недоступен, Azure сопоставляет все записи DNS с геореплицированным центром обработки данных. Обратите внимание, что у вас нет контроля над этим процессом, который выполняется только при возникновении сбоев всего центра обработки данных. Из-за этого необходимо также полагаться на другие зависящие от приложения стратегии резервного копирования для повышения уровня доступности. Дополнительные сведения см. в разделе Стратегии для аварийного восстановления данных.

При планировании аварийного восстановления необходимо учитывать весь диапазон возможных чрезвычайных ситуаций. Один из самых серьезных сбоев подразумевал бы под собой одновременную неисправность всех центров обработки данных Azure. Как и в случае с другими сбоями, можно пойти на риск временного простоя. Крупномасштабные сбои, охватывающие центры обработки данных, должны возникать намного реже, чем изолированные ошибки, включающие зависимые службы или отдельные центры обработки данных. Но для некоторых важнейших приложений может потребоваться план резервного копирования и для этого сценария. План этого события может включать отработку отказа на службы в альтернативном облаке (Альтернативные облака) или гибридном решении (Гибридные локальные и облачные решения).

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

  • Каталог продукции: позволяет пользователям просматривать продукты.

  • Корзина для покупок: позволяет пользователям добавлять продукты в корзину и удалять их.

  • Состояние заказа: отображает состояние доставки заказов пользователям.

  • Отправка заказов: завершение сеанса покупки отправкой заказа после оплаты.

  • Обработка заказов: проверяет заказ на целостность данных и выполняет проверку наличия товаров.

Если зависимый компонент модуля в этом приложении отключается, как работает модуль до восстановления работы компонента? Система с правильной архитектурой реализует границы изоляции за счет разделения задач как во время разработки, так и во время выполнения. Каждую ошибку можно классифицировать как устранимую и неустранимую. Неустранимые ошибки приводят к сбою модуля, а устранимые ошибки можно исправить с помощью альтернативных решений. Как описано в разделе, посвященном высокому уровню доступности, некоторые проблемы могут быть скрыты от пользователей за счет обработки ошибок и применения альтернативных мер. При более серьезном сбое приложение может стать полностью недоступным. Однако есть и третий вариант — продолжение обслуживания пользователей в ухудшенном режиме.

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

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

Еще один вариант ухудшенного режима сосредоточивается на производительности, а не возможностях. Например, рассмотрим сценарий, в котором каталог продуктов сохранялся в кэше с помощью Azure Caching. Если компонент кэша становится недоступным, возможно, что приложение может перейти непосредственно к хранилищу сервера для получения данных каталога продукции. Но это может быть медленнее, чем кэшированная версия. Из-за этого производительность приложения будет хуже, пока служба Caching Service не восстановится полностью.

Степень ограничения работы приложения в ухудшенном режиме — это одновременно деловое и техническое решение. Приложение должно также определить, как сообщить пользователям о временных проблемах. В этом примере приложение может разрешить просмотр продуктов и даже добавление их в корзину. Однако, если пользователь попытается совершить покупку, приложение уведомляет пользователя о том, что модуль продаж временно недоступен. Это неидеальная ситуация для клиента, но она позволяет предотвратить сбой всего приложения.

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

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

Регулярное резервное копирование данных приложений может поддерживать некоторые сценарии аварийного восстановления. Для различных ресурсов хранения требуются разные методы.

Для базы данных SQL Azure можно использовать команду DATABASE COPY, чтобы создать копию базы данных. Эту команду необходимо использовать, чтобы получить резервную копию с согласованностью транзакций. Вы можете также использовать службу импорта и экспорта базы данных SQL Azure. Это позволяет экспортировать базы данных в BACPAC-файлы, размещенные в хранилище больших двоичных объектов Azure. Благодаря встроенной избыточности хранилище Azure создает две реплики файла резервной копии в том же центре обработки данных. Однако частота выполнения резервного копирования определяет RPO, т. е. объем данных, которые можно потерять при сбое. Например, резервное копирование выполняется в начале часа, а авария происходит за две минуты до начала следующего часа. Вы потеряете данные за 58 минут, которые прошли после создания последней резервной копии. Кроме того, для защиты от сбоя центра обработки данных необходимо скопировать BACPAC-файлы в альтернативный центр обработки данных. После этого вы получите возможность восстановления этих резервных копий в другом центре. Дополнительные сведения см. в разделе Непрерывность бизнес-процессов в базе данных SQL Azure.

Для службы хранилища Azure можно разработать собственный процесс резервного копирования или использовать одно из многих средств сторонних производителей. Обратите внимание, что в большинстве проектов приложений, где ресурсы хранения ссылаются друг на друга, возникают дополнительные сложности. Например, рассмотрим базу данных SQL, которая содержит столбец, ссылающийся на большой двоичный объект в хранилище Azure. Если резервное копирование не осуществляется одновременно, то база данных может содержать указатель на большой двоичный объект, который не был включен в резервную копию до сбоя. Приложение или план аварийного восстановления должны реализовать процессы для обработки этой несогласованности после восстановления.

Как упоминалось ранее, ссылочные данные доступны только для чтения и поддерживают функции приложения. Обычно они изменяются редко. Хотя резервное копирование и восстановление — это один из методов обработки сбоев ЦОД, значение RTO при этом относительно велико. Если приложение развертывается в дополнительном центре обработки данных, существует несколько стратегий, которые повышают RTO для ссылочных данных.

Поскольку ссылочные данные изменяются редко, можно улучшить RTO, храня постоянную копию ссылочных данных в дополнительном центре обработки данных. Это сокращает время, необходимое для восстановления резервных копий в случае аварии. Для соответствия требованиям аварийного восстановления с несколькими центрами обработки данных приложение и ссылочные данные должны быть развернуты совместно в нескольких центрах обработки данных. Как упоминалось в разделе Шаблон ссылочных данных (высокий уровень доступности), ссылочные данные можно развернуть на самой роли, во внешнем хранилище или и в том, и другом месте. Модель развертывания ссылочных данных в вычислительном узле неявно отвечает требованиям аварийного восстановления. Для развертывания ссылочных данных в базе данных SQL необходимо развернуть копию ссылочных данных в каждом центре обработки данных. Та же стратегия применима к службе хранилища Azure. Необходимо развернуть копию всех ссылочных данных в службу хранилища Azure в основном и дополнительном центрах обработки данных.

Рис. 6. Публикация ссылочных данных в основном и дополнительных центрах обработки данных

Как упоминалось ранее, необходимо реализовать собственные процедуры резервного копирования, связанные с приложением, для всех данных, включая ссылочные. Геореплицируемые копии в разных ЦОД используются только при общем сбое ЦОД. Для предотвращения длительного простоя критически важные компоненты данных приложения должны быть развернуты в дополнительном центре обработки данных. Пример этой топологии модели см. в описании модели Активный-пассивный.

Для реализации полнофункциональной стратегии режима аварийного восстановления требуется асинхронная репликация транзакционных данных в дополнительный центр обработки данных. Фактическое временное окно, в течение которого может произойти репликация, определяет RPO приложения. Потерянные данные возможно удастся восстановить из основного центра обработки данных во время окна репликации. Позже может быть также возможно объединение с данными дополнительного центра обработки данных.

В следующих примерах архитектуры предоставлены некоторые концепции о различных способах обработки транзакционных данных в этом сценарии отработки отказа. Важно отметить, что эти примеры не являются исчерпывающими. Например, промежуточные местоположения хранения, такие как очереди, можно заменить на базу данных SQL Azure. Сами очереди могут быть очередями хранилища или шины обслуживания Azure (см. Очереди Azure и очереди шины обслуживания Azure — сходства и отличия). Серверные точки хранения также могут быть разными, например это могут быть таблицы Azure вместо базы данных SQL. Кроме того, могут использоваться рабочие роли, которые внедряются на различных этапах в качестве промежуточных элементов. Важно не буквально смоделировать эти архитектуры, а проанализировать различные варианты восстановления транзакционных данных и связанных модулей.

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

Рис. 7. Репликация данных транзакций при подготовке к аварийному восстановлению

Самая сложная задача при реализации предыдущей архитектуры — разработка стратегии репликации между ЦОД. Azure предоставляет службу синхронизации данных SQL для такого типа репликации. Однако эта служба находится на стадии предварительной версии и не рекомендуется для использования в производственных средах. Дополнительные сведения см. в разделе Непрерывность бизнес-процессов в базе данных SQL Azure. Для производственных приложений необходимо приобрести решение стороннего поставщика или создать собственную логику репликации в коде. В зависимости от архитектуры репликация может быть двунаправленной, что также приводит к усложнению. Одна из возможных реализаций — использование промежуточной очереди в предыдущем примере. Рабочая роль, передающая данные в конечную точку хранения, может вносить изменения в основном и дополнительном центрах обработки данных. Это нетривиальные задачи, а полные рекомендации по созданию кода репликации выходят за рамки данного документа. Важный аспект состоит в том, что большая часть времени и процесса тестирования должны быть сфокусированы на способе репликации данных в дополнительный центр обработки данных. Необходимы дополнительная обработка и тестирование, чтобы процессы отработки отказа и восстановления правильно обрабатывали все возможные несоответствия данных или повторяющиеся транзакции.

noteПримечание
Основная часть этого документа посвящена модели "платформа как услуга". Однако существуют и дополнительные возможности репликации и обеспечения доступности для гибридных приложений, использующих виртуальные машины Azure. Эти гибридные приложения используют модель «инфраструктура как услуга» (IaaS) для размещения SQL Server на виртуальных машинах в Azure. Это позволяет реализовать традиционные подходы для обеспечения доступности в SQL Server, такие как группы доступности AlwaysOn и доставка журналов. Некоторые методы, такие как группы AlwaysOn, работают только между локальными серверами SQL Server и виртуальными машинами Azure. Дополнительные сведения см. в разделе Высокий уровень доступности и аварийное восстановление для SQL Server в виртуальных машинах Azure.

Рассмотрим вторую архитектуру, которая работает в ухудшенном режиме. Приложение в дополнительном центре обработки данных отключает все функции, такие как функции отчетности, бизнес-аналитики или использования очередей. Оно принимает только наиболее важные типы транзакционных рабочих процессов в соответствии с бизнес-требованиями. Система получает транзакции и записывает их в очереди. Система может отложить обработку данных во время начального этапа сбоя. Если система в основном центре обработки данных восстанавливается в течение ожидаемого времени, очереди могут использоваться рабочими ролями в основном центре обработки данных. Этот процесс устраняет необходимость объединения базы данных. Если сбой основного ЦОД затягивается сверх допустимого, приложение может начать обработку очередей. В этом случае база данных в дополнительном центре обработки данных содержит добавочные транзакционные данные, которые необходимо объединить после возобновления работы основного центра обработки данных. На следующей диаграмме показана такая стратегия для временного хранения транзакционных данных до восстановления основного ЦОД.

Рис. 8. Режим ухудшенной функциональности приложения только для записи транзакций

Дополнительные описания методов управления данными для устойчивых приложений Azure см. в документе Безаварийность. Рекомендации по гибкой облачной архитектуре.

Подготовьте критически важные приложения к возможности общего сбоя всего центра обработки данных. Для этого необходимо внедрить стратегию развертывания в нескольких центрах обработки данных в операционное планирование. Развертывание нескольких ЦОД может потребовать от ИТ-специалистов опубликовать приложение и ссылочные данные в дополнительном ЦОД после аварии. Если приложение требует немедленной отработки отказа, процесс развертывания может использовать конфигурацию "активный-пассивный" или "активный-активный". При этом типе развертывания существующие экземпляры приложения выполняются в альтернативном центре обработки данных. Как было описано, средство маршрутизации, например диспетчер трафика Azure, предоставляет службы балансировки нагрузки на уровне DNS. Оно может обнаруживать сбои и при необходимости перенаправлять пользователей в другие ЦОД.

Часть успешного аварийного восстановления Azure — внедрение таких возможностей в решение заранее. Облачные системы предоставляют дополнительные варианты восстановления после сбоев, недоступные для традиционных поставщиков услуг размещения. В частности, можно динамически и быстро выделять ресурсы в другом центре обработки данных. Следовательно, вам не придется оплачивать их постоянно, пока они не используются в ожидании сбоя.

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

Развертывание в одном регионе не представляет собой топологию аварийного восстановления, а, скорее, служит для противопоставления другим архитектурам. Развертывания в одном регионе часто используются для приложений в Azure. Тем не менее оно не является надежным планом аварийного восстановления. На следующей диаграмме показано приложение, работающее в одном ЦОД Azure. Как было описано выше, контроллер структуры Azure вместе с доменами сбоя и обновления повышает доступность приложения внутри центра обработки данных.

Рис. 9. Развертывание в одном регионе

Здесь очевидно, что база данных является единственной точкой возникновения сбоя. Даже если Azure реплицирует данные из разных доменов сбоя во внутренние реплики, это все происходит в одном ЦОД. Такая архитектура не сможет выдержать катастрофический отказ. Если весь ЦОД станет недоступным, все домены сбоя отключаются, включая все экземпляры службы и ресурсы хранения.

Для всех, кроме наименее важных приложений, необходимо создать план развертывания приложений в нескольких ЦОД в различных регионах. Также необходимо рассмотреть ограничения RTO и затрат при выборе используемой топологии развертывания.

Теперь рассмотрим определенные шаблоны для поддержки отработки отказа между различными ЦОД. Во всех примерах для описания процесса используется два ЦОД.

В этом случае только основной центр обработки данных содержит работающие приложения и базы данных. Дополнительный центр обработки данных не настроен для автоматической отработки отказа. Поэтому после аварии необходимо настроить все компоненты службы в новом ЦОД. Для этого требуется переместить облачную службу в Azure, развернуть облачные службы, восстановить данные и изменить DNS для перенаправления трафика.

Хотя это и наиболее доступный вариант среди различных методов с несколькими регионами, он обеспечивает наихудшие значения RTO. В этой модели резервные копии пакетов служб и базы данных хранятся либо локально, либо в хранилище больших двоичных объектов дополнительного центра обработки данных. Однако необходимо развернуть новую службу и восстановить данные, перед тем как работа будет возобновлена. Даже если полностью автоматизировать передачу данных из хранилища резервных копий, для настройки новой среды базы данных все равно может потребоваться много времени. Перенос данных из резервного дискового хранилища в пустую базу данных в дополнительном центре обработки данных — самый дорогостоящий этап восстановления. Но это необходимо, чтобы привести новую базу данных в рабочее состояние, поскольку она не реплицируется.

Лучший способ — хранить пакеты в хранилище больших двоичных объектов Azure в дополнительном ЦОД. Это устраняет необходимость передавать пакет в Azure, что происходит при развертывании с локального компьютера разработчика. Пакеты служб можно быстро развернуть в новой облачной службе из хранилища больших двоичных объектов с помощью скриптов PowerShell.

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

Рис. 10. Повторное развертывание во вторичном центре обработки данных Azure

Вариант "активный-пассивный" выбирают многие компании. Он предоставляет улучшенные значения RTO с относительно небольшим увеличением затрат по сравнению с повторным развертыванием. В этом сценарии опять же используется основной и дополнительный центры обработки данных Azure. Весь трафик передается в активное развертывание в основном ЦОД. Дополнительный центр обработки данных лучше подготовлен к аварийному восстановлению, так как база данных работает в обоих центрах обработки данных. Кроме того, между ними выполняется синхронизация. У такого подхода может быть 2 варианта: только с базой данных или полное развертывание в дополнительном ЦОД.

В первом варианте шаблона «активный-пассивный» облачная служба приложения развернута только в основном ЦОД. Однако в отличие от повторного развертывания оба центра обработки данных синхронизируются по содержимому базы данных (см. раздел Шаблон транзакционных данных (аварийное восстановление)). Когда происходит авария, требований к активации меньше. Необходимо запустить приложение в дополнительном центре обработки данных, изменить строки подключения, указав новую базу данных, и изменить записи DNS для перенаправления трафика.

Как и при повторном развертывании пакеты служб уже должны быть размещены в хранилище больших двоичных объектов Azure в дополнительном центре обработки данных для более быстрого развертывания. В отличие от повторного развертывания большинство накладных расходов, необходимых для восстановления базы данных, отсутствуют. База данных уже готова и работает. Это экономит значительное время, делая такое решение доступным и, следовательно, наиболее популярным шаблоном DR.

Рис. 11. Активный-пассивный (только база данных)

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

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

Наряду с более быстрым временем реагирования эта конфигурация также имеет дополнительное преимущество — предварительно выделенные и развернутые резервные службы. Не приходится волноваться по поводу отсутствия в ЦОД пространства для выделения новых экземпляров после аварии. Это важно, если дополнительный ЦОД Azure использует почти всю доступную емкость. Нет никакой гарантии (SLA), что вы сразу же сможете развернуть несколько новых облачных служб в любом ЦОД.

Для получения наименьшего времени реагирования в этой модели в обоих центрах обработки данных необходим одинаковый масштаб (число экземпляров ролей). Несмотря на преимущества, оплата неиспользуемых вычислительных операций обходится дорого и часто не является вариантом, наиболее оправданным с финансовой точки зрения. Из-за этого в дополнительном центре обработки данных чаще используется версия облачных служб меньшего масштаба. Поэтому в случае необходимости можно быстро выполнить отработку отказа и масштабировать дополнительное развертывание. Процесс отработки отказа можно автоматизировать, чтобы после сбоя основного центра обработки данных можно было настроить дополнительные экземпляры в зависимости от нагрузки. Для этого могут использоваться определенные типы механизмов автоматического масштабирования, например предварительная версия автомасштабирования или блок автомасштабирования для приложений. На следующей схеме показана модель, в которой основной и дополнительный центры обработки данных содержат полностью развернутую облачную службу с конфигурацией "активный-пассивный".

Рис. 12. Активный-пассивный (полная реплика)

К этому моменту вы, вероятно, поняли закономерность эволюции конфигураций — снижение RTO увеличивает затраты и усложняет систему. Активно-активное решение фактически разрывает такую тенденцию по отношению к затратам. В шаблоне «активный-активный» облачные службы и база данных полностью развертываются в обоих ЦОД. В отличие от модели "активный-пассивный" оба центра обработки данных получают трафик от пользователей. Этот вариант обеспечивает наиболее быстрое время восстановления. Службы уже масштабированы для обработки части нагрузки в каждом центре обработки данных. Служба DNS уже настроена для использования дополнительного центра обработки данных. При этом возникают дополнительные сложности при определении способа маршрутизации пользователей в соответствующий ЦОД. Возможен циклический перебор. Но более вероятно, что некоторые пользователи будут применять определенный центр обработки данных, в котором находится основная копия их данных.

При отработке отказа просто отключите DNS в основном центре обработки данных, что перенаправит весь трафик на дополнительный центр обработки данных. Даже для этой модели существуют некоторые варианты. Например, на следующей диаграмме показана модель, в которой основной ЦОД содержит мастер-копию базы данных. Облачные службы в обоих ЦОД записывают данные в эту базу данных-источник. Дополнительное развертывание может считывать данные из основной или реплицированной базы данных. В этом примере репликация выполняется в одном направлении.

Рис. 13. Активный-активный

У архитектуры "активный-активный", показанной на предыдущей схеме, есть недостаток. Второй центр обработки данных должен получить доступ к базе данных в первом центре обработки данных, поскольку там находится мастер-копия. При доступе к данным за пределами ЦОД производительность значительно падает. Для вызовов базы данных по нескольким ЦОД необходимо использовать определенную стратегию пакетной обработки для повышения производительности этих вызовов. Дополнительные сведения см. в разделе Методы пакетной обработки в приложениях базы данных SQL в Azure. Альтернативная архитектура может позволять каждому центру обработки данных получать доступ к собственной базе данных напрямую. В этой модели требуется двунаправленная репликация для синхронизации баз данных в каждом ЦОД.

Приятным преимуществом конфигурации "активный-активный" является то, что число экземпляров в основном центре обработки данных, по сравнению с конфигурацией "активный-пассивный", скорее всего будет меньше. Если в архитектуре «активный-пассивный» требуется 10 экземпляров в основном ЦОД, то в архитектуре «активный-активный» необходимо всего 5 экземпляров в каждом ЦОД. Теперь оба региона делят нагрузку между собой. Это позволяет сократить расходы по сравнению с конфигурацией "активный-пассивный", если пассивный центр обработки данных находится в режиме "горячего" резервирования при условии, что 10 экземпляров ожидают отработки отказа.

Следует учитывать, что, пока основной центр обработки данных не будет восстановлен, дополнительный центр обработки данных может ощутить неожиданный наплыв новых пользователей. Если оба сервера принимали по 10 000 пользователей на момент сбоя основного центра обработки данных, то дополнительному центру обработки данных придется сказу принять 20 000 пользователей. Правила мониторинга на дополнительном центре обработки данных должны обнаруживать это увеличение и удваивать число экземпляров в дополнительном центре обработки данных. Дополнительные сведения см. в разделе Обнаружение ошибок.

Дополнительная стратегия аварийного восстановления состоит в создании гибридного приложения, которое работает как локально, так и в облаке. В зависимости от приложения основной ЦОД может быть расположен локально или в облаке. Рассмотрим предыдущие архитектуры и представим, что основной или дополнительный центр обработки данных расположен локально.

В таких гибридных архитектурах возникают некоторые трудности. Во-первых, большая часть этого документа была посвящена шаблонам архитектуры «платформа как услуга» (PaaS). Типичные приложения PaaS в Azure используют такие конструкции Azure, как роли, облачные службы и контроллер структуры. Чтобы создать локальное решение для такого типа приложений PaaS, требуется совсем другая архитектура. Это может оказаться невозможным с точки зрения управления или затрат.

Однако гибридное решение для аварийного восстановления проще реализовать для традиционных архитектур, которые просто были перемещены в облако. Это верно для архитектур, использующих модель «инфраструктура как услуга» (IaaS). Приложения IaaS используют виртуальные машины в облаке, для которых могут существовать прямые локальные эквиваленты. Использование виртуальных сетей также позволяет подключаться к компьютерам в облаке с помощью локальных сетевых ресурсов. Это открывает несколько возможностей, неподдерживаемых в «чистых» приложениях PaaS. Например, SQL Server может использовать решения аварийного восстановления, такие как группы доступности AlwaysOn и зеркальное отображение базы данных. Дополнительные сведения см. в разделе Высокий уровень доступности и аварийное восстановление для SQL Server в виртуальных машинах Azure.

Решения IaaS также предоставляют локальным приложениям более простой способ использования Azure для отработки отказа. Полноценное приложение может работать в локальном ЦОД. Но что делать, если не хватает ресурсов для поддержки географически распределенного центра обработки данных для отработки отказа? Можно использовать виртуальные машины и виртуальные сети, чтобы приложение работало в Azure. Определите процессы, которые синхронизируют данные с облаком. После этого развертывание Azure становится дополнительным ЦОД для отработки отказа. Основной ЦОД остается ресурсом для локального приложения. Дополнительные сведения об архитектурах и возможностях IaaS см. в разделах Виртуальные машины и Виртуальная сеть.

Существуют ситуации, когда даже надежности облака Майкрософт может быть недостаточно с точки зрения конкретных требований к доступности. В прошлом году возникали серьезные сбои в нескольких различных облачных платформах. В том числе были затронуты службы Amazon Web Services (AWS) и платформы Azure. Даже лучшая подготовка и проектирование для реализации резервных систем во время аварийной ситуации не помогают, когда целое облако "берет выходной".

Необходимо сравнить требования к доступности с затратами и сложностью повышения доступности. Выполните анализ рисков и определите RTO и RPO для вашего решения. Если ваше приложение не может допустить ни секунды простоя, имеет смысл рассмотреть возможность использования другого облачного решения. Если весь Интернет не выйдет из строя сразу, другое облачное решение, например Rackspace или Amazon Web Services, по-прежнему будет работать в маловероятной ситуации, когда платформа Azure полностью станет недоступной.

Как и для гибридного сценария, развертывания отработки отказа в предыдущих архитектурах аварийного восстановления могут также существовать в другом облачном решении. Альтернативные сайты аварийного восстановления в облаке должны использоваться только для тех решений, RTO которых допускает очень малое время простоя или вообще не допускает простоя. Обратите внимание, что решение, использующее сайт аварийного восстановления вне Azure, требует намного больше усилий для настройки, разработки, развертывания и поддержки. Кроме того, сложнее реализовать рекомендации в архитектуре, охватывающей несколько облачных решений. Хотя облачные платформы и применяют схожие высокоуровневые концепции, их интерфейсы API и архитектуры отличаются. Если вы решите разделить решение аварийного восстановления между разными платформами, имеет смысл включить абстрактные уровни в решение. В этом случае вам не понадобится создавать и поддерживать две разные версии одного приложения, которое будет работать на разных облачных платформах для защиты от сбоев. Как и для гибридного сценария, в таких случаях использование виртуальных машин может оказаться удобнее, чем проекты PaaS для определенных облачных платформ.

Некоторые из конфигураций, которые мы только что обсудили, требуют быстрой активации резервных развертываний, а также восстановления определенных компонентов системы. Автоматизация и скрипты поддерживают возможность активации ресурсов по запросу и быстрого развертывания решений. В этом документе автоматизация, связанная с аварийным восстановлением, поддерживается Azure PowerShell, но API REST управления службами также является допустимым вариантом. Разработка скриптов помогает управлять компонентами DR, которыми не занимается Azure. Это позволяет постоянно получать согласованные результаты, что снижает вероятность человеческой ошибки. Предопределенные скрипты DR также сокращают время для перестроения системы и ее составных частей в ситуации сбоя. Не следует пытаться вручную пытаться восстановить сайт когда он недоступен, поскольку вы теряете деньги каждую минуту.

После создания скриптов их необходимо тестировать снова и снова от начала до конца. После проверки их основных функциональных возможностей, убедитесь, что проверили их в смоделированном аварийном сбое (Имитация аварий). Это помогает обнаружить недостатки скриптов или процессов.

Рекомендуется создать репозиторий скриптов PowerShell для аварийного восстановления в Azure. Четко выделите и классифицируйте их, чтобы упростить поиск. Выделите одного сотрудника для управления репозиторием и версиями скриптов. Задокументируйте скрипты с четким описанием параметров и примерами использования. Также убедитесь, что эта документация соответствует вашим развертываниям в Azure. Это подчеркивает необходимость наличия одного сотрудника, ответственного за все компоненты репозитория.

Чтобы правильно устранять проблемы с доступностью и аварийным восстановлением, необходимо уметь их распознавать и диагностировать. Следует осуществлять расширенный мониторинг серверов и развертываний, чтобы быстро узнавать о неожиданном сбое системы или ее компонентов. Средства мониторинга, которые отслеживают общую работоспособность облачной службы и ее зависимостей, могут выполнить эту часть работы. Доступны два средства от Майкрософт: MetricsHub и System Center 2012 R2 (SCOM). Возможности наблюдения также могут предоставлять другие средства сторонних поставщиков, такие как AzureWatch. AzureWatch позволяет также автоматизировать масштабирование. Большинство решений мониторинга отслеживают счетчики производительности и доступность служб.

Хотя эти средства очень важны, они не заменят план обнаружения сбоев и отчеты в облачной службе. Необходимо правильно спланировать использование средств диагностики Azure. Пользовательские счетчики производительности или записи журнала событий также могут входить в общую стратегию. Это предоставляет дополнительные данные во время сбоев для быстрой диагностики проблем и восстановлений полной функциональности. Это также позволяет получить дополнительные метрики для средств мониторинга, которые можно использовать для определения исправности приложения. Дополнительные сведения см. в разделе Сбор данных журналов с помощью диагностики Azure. Обсуждение планирования общей «модели исправности» см. в документе Безаварийность. Рекомендации по гибкой облачной архитектуре.

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

Рассмотрим создание своего рода «коммутатора» в приложении для ручной имитации проблем с доступностью. Например, с помощью программного переключателя можно инициировать исключения базы данных для модуля заказов, чтобы вызвать его отказ. Подобные облегченные подходы можно использовать для других модулей на уровне сетевого интерфейса.

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

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

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

  1. Проведите оценку рисков для каждого приложения, поскольку каждое из них может предъявлять свои требования. Некоторые приложения более важны для компании, чем другие. Поэтому для них обоснованы дополнительные траты на аварийное восстановление.

  2. Используйте эти сведения, чтобы определить RTO и RPO для каждого приложения.

  3. Учитывайте возможность сбоя при проектировании, начиная с архитектуры приложения.

  4. Применяйте рекомендации для обеспечения высокого уровня доступности, балансируя при этом затраты, сложность и риски.

  5. Реализуйте планы и процессы аварийного восстановления.

    1. Учитывайте все уровни сбоев, от ошибок на уровне модуля вплоть до полного отключения облачной платформы.

    2. Создайте стратегии резервного копирования для всех ссылочных и транзакционных данных.

    3. Выберите архитектуру аварийного восстановления с использованием нескольких центров обработки данных.

  6. Определите сотрудника, ответственного за процессы аварийного восстановления, автоматизации и тестирования. Этот сотрудник должен управлять всем процессом.

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

  8. Обучайте персонал для реализации этого процесса.

  9. Используйте периодические имитации аварийных ситуаций для обучения и проверки процесса.

При сбое оборудования или программного обеспечения в Azure методы и стратегии управления ими отличаются от сбоев в локальных системах. Основная причина связана с тем, что у облачных решений обычно больше зависимостей от инфраструктуры, которая распределена по центру обработки данных и управляется как отдельные службы. Частичные сбои необходимо обрабатывать с использованием методов обеспечения высокого уровня доступности. Для управления более серьезными сбоями, возможно вызванными авариями, используйте стратегии аварийного восстановления.

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

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

См. также

Корпорация Майкрософт проводит интернет-опрос, чтобы выяснить ваше мнение о веб-сайте MSDN. Если вы желаете принять участие в этом интернет-опросе, он будет отображен при закрытии веб-сайта MSDN.

Вы хотите принять участие?
Показ:
© 2014 Microsoft