Пассивная и активная репликации

Для поддержки прозрачности репликации широко используются две архитектурные модели: пассивная репликация и активная репликация [6].

Пассивная репликация

В пассивной репликации каждый клиент (или действующий от имени клиента front-end) взаимодействует с одной из реплик, называемой главной или первичной (primary). Помимо первичной реплики в системе есть еще несколько реплик-бэкапов, которые могут использоваться как копии на серверах резервного копирования (рис. 5.2). Запрос клиента всегда адресуется первичной реплике. Если первичная реплика работает и доступна, она предоставляет запрашиваемую услугу. Если выполнение клиентского запроса не предполагает модификации данных, тогда нет необходимости в дальнейших действиях. Если, однако, в результате запроса данные должны быть изменены, тогда, чтобы поддержать состояния реплик консистентными, главная реплика делает виртуально синхронную групповую рассылку, гарантирующую правильный порядок выполнения обновлений на репликах, перед посылкой ответа клиенту. Таким образом, сами реплики-бэкапы не выполняют команды клиента, а лишь обновляют свои данные, синхронизируясь с главным сервером.

Пассивная репликация серверов

Рис. 5.2. Пассивная репликация серверов

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

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

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

Задача первичной реплики — периодически делать рассылку пульсирующих (heartbeat) сообщений, используемых для контроля жизнеспособности реплики. Если резервная реплика не получает такого сообщения в течение оговоренного интервала времени, она делает вывод об отказе текущей первичной реплики и инициирует выбор новой. После проведения процедуры выбора новая первичная реплика извещает об этом клиентов. Рисунок 5.3 иллюстрирует взаимодействие первичной реплики с репликами-бэкапами.

Иллюстрация протокола первичный сервер — сервер резервного копирования

Рис. 5.3. Иллюстрация протокола первичный сервер — сервер резервного копирования:

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

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

Очевидно, что при наличии только отказов-крэшей, по крайней мере (m + 1) реплик достаточно, что претерпеть отказы т серверов, так как для предоставления нужного клиенту сервиса достаточно иметь только один работающий сервер.

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

Пассивная репликация эффективна в системах, в которых операции изменения данных сравнительно редки в сравнении с операциями извлечения данных.

Активная репликация

Альтернатива пассивной репликации — активная репликация. Здесь каждый из п клиентов прозрачно взаимодействует с группой из к серверов (менеджеров реплик). В отличие от серверов модели пассивной репликации, эти серверы равноправны.

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

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

 
Посмотреть оригинал
< Пред   СОДЕРЖАНИЕ   ОРИГИНАЛ     След >