Что такое избыточность, репликация и резервное копирование?

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

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

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

Репликация или избыточность данных — это возможность поддерживать несколько копий данных, называемых репликами.

Резервное копирование — это возможность поддерживать метку времени, которую можно использовать для восстановления потерянных данных.

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

Избыточность

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

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

Сценарий: резервирование без сохранения состояния

В этом примере компонент API без отслеживания состояния развертывается на виртуальной машине. Чтобы избежать простоя для компонента API, если на физическом узле произошел сбой оборудования, в примере реализуется избыточное решение, которое:

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

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

Вопросы избыточности

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

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

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

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

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

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

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

• Мониторинг здоровья. Работоспособность каждого экземпляра определяет, может ли этот экземпляр выполнять свою работу, и мониторинг работоспособности важен для быстрого восстановления, если возникла проблема.

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

Физические расположения в облаке

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

Рассмотрим пример.

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

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

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

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

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

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

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

Как работает избыточность в Azure: вычислительные службы

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

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

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

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

Репликация: избыточность данных

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

Существуют различные типы репликации, и каждый из них ставит разные приоритеты в отношении согласованности данных, производительности и затрат. Каждый тип репликации влияет на две ключевые метрики, используемые в обсуждениях непрерывности бизнес-процессов: цель времени восстановления (RTO), которая является максимальным количеством времени простоя, которое можно терпеть в сценарии аварии, и целевой точке восстановления (RPO), что является максимальным объемом потери данных, которую можно терпеть в сценарии аварии. Дополнительные сведения об этих метриках и их связи с непрерывностью бизнес-процессов см. в статье "Что такое непрерывность бизнес-процессов, высокий уровень доступности и аварийное восстановление?".

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

Синхронная и асинхронная репликация

При репликации данных все изменения этих данных должны оставаться синхронизированными между репликами. При попытке сохранить согласованность при изменении данных существует несколько основных проблем:

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

• Управление изменениями. Данные могут изменяться во время синхронизации реплик, поэтому управление согласованности данных может стать сложным.

Для решения этих проблем существует два основных способа репликации изменений данных и управления согласованностью данных:

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

  

  В этом примере происходит следующая последовательность шагов:

  1. Клиент изменяет данные, а запрос отправляется в реплику 1, которая обрабатывает запрос и сохраняет измененные данные.
  2. Реплика 1 отправляет изменения в реплику 2, которая обрабатывает запрос и сохраняет измененные данные.
  3. Реплика 2 подтверждает изменение обратно на реплику 1.
  4. Реплика 1 подтверждает изменение обратно клиенту.

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

• Асинхронная репликация происходит в фоновом режиме. На следующей схеме показано, как работает асинхронная репликация:

  

  В этом примере происходит следующая последовательность шагов:

  1. Клиент изменяет данные, а запрос отправляется в реплику 1.
  2. Реплика 1 обрабатывает запрос, сохраняет измененные данные и немедленно подтверждает изменение клиенту.
  3. В какой-то момент времени реплика 1 синхронизирует изменение с репликой 2.

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

Роли реплики

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

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

  

  В активно-пассивной системе время, необходимое для переключения, определяет цель по времени восстановления (RTO). Обычно RTO для активно-пассивной системы измеряется в минутах.

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

• Репликация active-active позволяет одновременно использовать несколько активных реплик для динамического трафика, а любая из реплик может обрабатывать запросы:

  

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

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

Как работает репликация в службах данных Azure

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

Например, служба хранилища Azure может обеспечить синхронную и асинхронную репликацию с помощью набора возможностей:

• Несколько копий ваших данных реплицируются синхронно в вашем основном регионе. Вы можете выбрать, следует ли размещать реплики на различном физическом оборудовании в одном центре обработки данных для локально избыточного хранилища (LRS) или распределять их между несколькими зонами доступности для зонально избыточного хранилища (ZRS).
• Если ваш основной регион соединен с парным и вы включаете геоизбыточное хранилище (GRS), данные также реплицируются в парный регион. Так как парные регионы географически удалены, эта репликация выполняется асинхронно, чтобы снизить влияние на пропускную способность приложения.
• Вы можете одновременно использовать избыточное между зонами хранилище и геоизбыточное хранилище с помощью геоизбыточного уровня хранилища (GZRS). Данные в регионе реплицируются синхронно, а данные между регионами реплицируются асинхронно.

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

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

При использовании виртуальных машин можно использовать Azure Site Recovery для репликации виртуальных машин и их дисков между зонами доступности или в другой регион Azure.

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

Резервное копирование

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

С помощью резервного копирования можно предоставить решения для резервного копирования и восстановления данных в облаке Microsoft Azure. Резервное копирование может защитить вас от различных рисков, в том числе:

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

Как резервное копирование влияет на требования

При использовании в рамках стратегии аварийного восстановления резервные копии обычно поддерживают RTO и RPO, измеряемые в часах:

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

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

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

Резервное копирование в службах Azure

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

Azure Backup — это выделенное решение для резервного копирования для нескольких ключевых служб Azure, включая виртуальные машины, службу хранилища Azure и Службу Azure Kubernetes (AKS).

Кроме того, многие управляемые базы данных предоставляют собственные возможности резервного копирования в рамках службы, например:

• База данных SQL Azure предоставляет автоматические резервные копии.
• Azure Cosmos DB предоставляет возможности непрерывного и периодического резервного копирования.
• Azure Key Vault позволяет скачать резервную копию данных в хранилище.
• Служба приложений Azure предоставляет автоматическую и настраиваемую резервную копию для веб-приложений, а также может создавать резервные копии баз данных.

Резервное копирование и репликация

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

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

В отличие от этого, резервное копирование часто является последней линией защиты от катастрофических рисков. Резервные копии часто требуют относительно высокого уровня RTO и RPO, хотя способ настройки резервных копий влияет на то, насколько высоко они будут. Общее восстановление из резервной копии часто является частью плана аварийного восстановления.

Подготовка компонентов для резервирования

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

• Повторяющаяся конфигурация ресурсов для согласованности.
• Управляйте емкостью во время сбоев экземпляра путем сверхпланирования.

Повторяющаяся конфигурация ресурсов

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

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

Распространенный подход к поддержанию согласованности в ресурсах — использовать инфраструктуру в качестве кода (IaC), например Bicep или Terraform. Эти средства позволяют создавать файлы, определяющие ресурс, и можно повторно использовать эти определения для каждого экземпляра ресурса. Используя IaC, вы можете снизить нагрузку на создание и управление несколькими экземплярами ресурсов для целей устойчивости, а также есть много других преимуществ. Дополнительные сведения см. в статье "Что такое инфраструктура как код(IaC)" и рекомендации по использованию инфраструктуры в качестве кода.

Управление емкостью с помощью перепредоставления ресурсов

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

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

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

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

1. Определите количество экземпляров, необходимых для пиковой рабочей нагрузки.
2. Получите число экземпляров избыточной подготовки, умножив количество экземпляров наивысшей рабочей нагрузки на коэффициент [(зоны/(зоны-1)].
3. Округление результата до ближайшего целого числа.

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

Дальнейшие действия

Узнайте о отказоустойчивости и восстановлении после отказа.