Репликация облачных хранилищ

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

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

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

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

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

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

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

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

Главное различие между репликацией и резервным копированием заключается в следующем:

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

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

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

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

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

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

1) Транзакционная репликация;

2) Репликация автомата;

3) Виртуальная синхронизация;

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

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

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