Репликация в вычислениях предполагает обмен информацией для обеспечения согласованности между избыточными ресурсами, такими как программные или аппаратные компоненты, для повышения надежности, отказоустойчивости или доступности.
Репликация в вычислениях может означать:
Репликация в пространстве или во времени часто связана с алгоритмами планирования. [1]
Доступ к реплицируемому объекту обычно аналогичен доступу к одному нереплицируемому объекту. Сама репликация должна быть прозрачной для внешнего пользователя. В случае сбоя переключение реплик должно быть максимально скрыто с точки зрения качества обслуживания . [2]
Ученые-компьютерщики далее описывают репликацию как:
Когда одна ведущая реплика назначается путем выбора лидера для обработки всех запросов, система использует схему первичного резервного копирования или первичной реплики , которая преобладает в кластерах высокой доступности . Для сравнения, если какая-либо реплика может обрабатывать запрос и распространять новое состояние, система использует схему с несколькими первичными или несколькими главными узлами. В последнем случае необходимо использовать некоторую форму управления распределенным параллелизмом , например распределенный менеджер блокировок .
Балансировка нагрузки отличается от репликации задач, поскольку она распределяет нагрузку различных вычислений по машинам и позволяет отбросить одно вычисление в случае сбоя. Однако балансировка нагрузки иногда использует внутреннюю репликацию данных (особенно репликацию с несколькими хозяевами ), чтобы распределить данные между машинами.
Резервное копирование отличается от репликации тем, что сохраненная копия данных остается неизменной в течение длительного периода времени. [3] Реплики, с другой стороны, подвергаются частым обновлениям и быстро теряют историческое состояние. Репликация — одна из старейших и наиболее важных тем в области распределенных систем .
Репликация данных и репликация вычислений требуют, чтобы процессы обрабатывали входящие события. Процессы репликации данных являются пассивными и работают только для обслуживания сохраненных данных, ответа на запросы чтения и применения обновлений. Репликация вычислений обычно выполняется для обеспечения отказоустойчивости и принятия операции на себя в случае сбоя одного компонента. В обоих случаях основная потребность заключается в том, чтобы реплики видели одни и те же события в эквивалентном порядке, чтобы они оставались в согласованных состояниях и чтобы любая реплика могла отвечать на запросы.
Существуют три широко цитируемые модели репликации данных, каждая из которых имеет свои свойства и производительность:
Репликация базы данных может использоваться во многих системах управления базами данных (СУБД), обычно с отношениями первичный/реплика между оригиналом и копиями. Первичный сервер регистрирует обновления, которые затем передаются на реплики. Каждая реплика выводит сообщение об успешном получении обновления, что позволяет отправлять последующие обновления.
При репликации с несколькими хозяевами обновления могут отправляться на любой узел базы данных, а затем распространяться на другие серверы. Это часто желательно, но влечет за собой существенное увеличение затрат и сложности, что в некоторых ситуациях может сделать это непрактичным. Наиболее распространенной проблемой, возникающей при репликации с несколькими хозяевами, является предотвращение или разрешение транзакционных конфликтов . Большинство решений синхронной (или активной) репликации выполняют предотвращение конфликтов, тогда как асинхронные (или ленивые) решения должны выполнять разрешение конфликтов. Например, если одна и та же запись изменяется на двух узлах одновременно, система активной репликации обнаружит конфликт перед подтверждением фиксации и прервет одну из транзакций. Система ленивой репликации позволит обеим транзакциям фиксировать и запускать разрешение конфликтов во время повторной синхронизации. [7] Разрешение такого конфликта может быть основано на временной метке транзакции, на иерархии исходных узлов или на гораздо более сложной логике, которая принимает решения последовательно на всех узлах.
Репликация базы данных становится более сложной при горизонтальном и вертикальном масштабировании . При горизонтальном масштабировании имеется больше реплик данных, тогда как при вертикальном масштабировании реплики данных располагаются на больших физических расстояниях. Проблемы, возникающие при горизонтальном масштабировании, можно решить с помощью многоуровневого протокола доступа с несколькими представлениями . Первые проблемы вертикального расширения в основном решались за счет повышения надежности и производительности Интернета. [8] [9]
Когда данные реплицируются между серверами баз данных, так что информация остается согласованной во всей системе базы данных, и пользователи не могут сказать или даже узнать, какой сервер в СУБД они используют, говорят, что система демонстрирует прозрачность репликации.
Однако прозрачность репликации не всегда может быть достигнута. Когда данные реплицируются в базе данных, они будут ограничены теоремой CAP или теоремой PACELC . В движении NoSQL согласованностью данных обычно жертвуют в обмен на другие, более желательные свойства, такие как доступность (A), устойчивость к разделению (P) и т. д. Также были разработаны различные модели согласованности данных , которые служат соглашением об уровне обслуживания (SLA). между поставщиками услуг и пользователями.
Активная (в режиме реального времени) репликация хранилища обычно реализуется путем распространения обновлений блочного устройства на несколько физических жестких дисков . Таким образом, любая файловая система, поддерживаемая операционной системой , может быть реплицирована без изменений, поскольку код файловой системы работает на уровне выше уровня драйвера блочного устройства. Он реализован либо аппаратно (в контроллере дискового массива ), либо программно (в драйвере устройства ).
Самый простой метод — зеркалирование диска , типичное для локально подключенных дисков. В сфере хранения данных определения сужаются, поэтому зеркалирование является локальной (на небольшом расстоянии) операцией. Репликацию можно расширить по компьютерной сети , так что диски могут быть расположены в физически удаленных местах, и обычно применяется модель репликации базы данных «основная/реплика». Цель репликации — предотвратить ущерб от сбоев или катастроф , которые могут произойти в одном месте, или, в случае возникновения таких событий, улучшить возможности восстановления данных. Для репликации задержка является ключевым фактором, поскольку она определяет либо расстояние между сайтами, либо тип репликации, который можно использовать.
Основная характеристика такой межсайтовой репликации заключается в том, как обрабатываются операции записи посредством асинхронной или синхронной репликации; синхронная репликация должна ждать ответа целевого сервера при любой операции записи, тогда как асинхронная репликация этого не делает.
Синхронная репликация гарантирует «нулевую потерю данных» посредством операций атомарной записи, при которых операция записи не считается завершенной до тех пор, пока не будет подтверждена как локальным, так и удаленным хранилищем. Большинство приложений ждут завершения транзакции записи, прежде чем продолжить дальнейшую работу, поэтому общая производительность значительно снижается. По сути, производительность падает пропорционально расстоянию, поскольку минимальная задержка определяется скоростью света . На расстоянии 10 км максимально быстрый путь туда и обратно занимает 67 мкс, тогда как вся запись в локальный кэш завершается примерно за 10–20 мкс.
При асинхронной репликации операция записи считается завершенной, как только локальное хранилище подтверждает ее. Удаленное хранилище обновляется с небольшой задержкой . Производительность значительно увеличивается, но в случае сбоя локального хранилища в удаленном хранилище не гарантируется наличие текущей копии данных (самые последние данные могут быть потеряны).
Полусинхронная репликация обычно считает операцию записи завершенной, когда она подтверждена локальным хранилищем и получена или зарегистрирована удаленным сервером. Фактическая удаленная запись выполняется асинхронно, что приводит к повышению производительности, но удаленное хранилище будет отставать от локального хранилища, поэтому нет никакой гарантии надежности (т. е. прозрачности) в случае сбоя локального хранилища. [ нужна цитата ]
Репликация на определенный момент времени создает периодические снимки , которые реплицируются вместо основного хранилища. Это предназначено для репликации только измененных данных, а не всего тома. Поскольку при использовании этого метода реплицируется меньше информации, репликация может происходить по каналам с менее дорогой полосой пропускания, таким как iSCSI или T1, а не по оптоволоконным линиям.
Многие распределенные файловые системы используют репликацию, чтобы обеспечить отказоустойчивость и избежать единой точки отказа.
Многие коммерческие системы синхронной репликации не зависают, когда удаленная реплика выходит из строя или теряет соединение (поведение, гарантирующее нулевую потерю данных), а продолжают работать локально, теряя желаемую нулевую точку восстановления .
Методы оптимизации глобальной сети (WAN) могут применяться для устранения ограничений, налагаемых задержкой.
Репликация на основе файлов осуществляет репликацию данных на логическом уровне (т. е. отдельных файлов данных), а не на уровне блоков хранения. Существует множество различных способов сделать это, которые почти исключительно основаны на программном обеспечении.
Драйвер ядра (в частности, драйвер фильтра ) можно использовать для перехвата вызовов функций файловой системы, фиксируя любую активность по мере ее возникновения. При этом используется та же технология, что и активные средства проверки на вирусы в режиме реального времени. На этом уровне фиксируются логические операции с файлами, такие как открытие файла, запись, удаление и т. д. Драйвер ядра передает эти команды другому процессу, обычно по сети на другой компьютер, который имитирует операции исходного компьютера. Как и репликация хранилища на уровне блоков, репликация на уровне файлов поддерживает как синхронный, так и асинхронный режимы. В синхронном режиме операции записи на исходном компьютере задерживаются и не могут выполняться до тех пор, пока целевой компьютер не подтвердит успешную репликацию. Синхронный режим менее распространен в продуктах для репликации файлов, хотя существует несколько решений.
Решения репликации на уровне файлов позволяют принимать обоснованные решения о репликации на основе местоположения и типа файла. Например, можно исключить временные файлы или части файловой системы, не имеющие коммерческой ценности. Передаваемые данные также могут быть более детальными; если приложение записывает 100 байт, передаются только 100 байт вместо полного блока диска (обычно 4096 байт). Это существенно уменьшает объем данных, отправляемых с исходного компьютера, и нагрузку на хранилище на целевом компьютере.
К недостаткам этого исключительно программного решения относятся необходимость внедрения и обслуживания на уровне операционной системы, а также повышенная нагрузка на вычислительную мощность машины.
Подобно журналам транзакций базы данных , многие файловые системы имеют возможность вести журнал своей активности. Журнал можно отправлять на другой компьютер либо периодически, либо в режиме реального времени в потоковом режиме. На стороне реплики журнал можно использовать для воспроизведения изменений файловой системы.
Одной из примечательных реализаций является Microsoft System Center Data Protection Manager (DPM), выпущенный в 2005 году , который выполняет периодические обновления, но не обеспечивает репликацию в реальном времени. [ нужна цитата ]
Это процесс сравнения файловых систем источника и назначения и обеспечения соответствия места назначения источнику. Ключевым преимуществом является то, что такие решения, как правило, бесплатны или недороги. Обратной стороной является то, что процесс их синхронизации является весьма системоемким и, следовательно, этот процесс обычно выполняется нечасто.
Одной из примечательных реализаций является rsync .
В операционной системе подкачки страницы файла подкачки иногда реплицируются внутри дорожки, чтобы уменьшить задержку вращения.
В системе VSAM от IBM индексные данные иногда реплицируются внутри дорожки, чтобы уменьшить задержку вращения.
Другой пример использования репликации появляется в распределенных системах с общей памятью, где многие узлы системы используют одну и ту же страницу памяти. Обычно это означает, что каждый узел имеет отдельную копию (реплику) этой страницы.
Многие классические подходы к репликации основаны на модели первичного резервного копирования, в которой одно устройство или процесс имеет односторонний контроль над одним или несколькими другими процессами или устройствами. Например, основной может выполнять некоторые вычисления, передавая журнал обновлений резервному (резервному) процессу, который затем может взять на себя управление в случае сбоя основного. Этот подход является общим для репликации баз данных, несмотря на риск того, что если часть журнала будет потеряна во время сбоя, резервная копия может оказаться не в состоянии, идентичном основному, и транзакции могут быть потеряны.
Слабость схем первичного резервного копирования заключается в том, что фактически операции выполняет только одна из них. Отказоустойчивость достигается, но идентичная система резервного копирования удваивает затраты. По этой причине, начиная c. В 1985 году сообщество исследователей распределенных систем начало изучать альтернативные методы репликации данных. Результатом этой работы стало появление схем, в которых группа реплик могла взаимодействовать, при этом каждый процесс выступал в качестве резервного копирования и одновременно брал на себя часть рабочей нагрузки.
Ученый-компьютерщик Джим Грей проанализировал схемы многократной первичной репликации в рамках транзакционной модели и опубликовал широко цитируемую статью, в которой скептически относится к подходу «Опасности репликации и решение». [10] [11] Он утверждал, что, если данные не будут разделены каким-то естественным образом, так что базу данных можно будет рассматривать как n n непересекающихся подбаз данных, конфликты управления параллелизмом приведут к серьезному снижению производительности, и группа реплик, вероятно, будет замедляться, поскольку функция n . Грей предположил, что наиболее распространенные подходы, вероятно, приведут к деградации, масштабируемой как O(n³) . Его решение, заключающееся в секционировании данных, жизнеспособно только в ситуациях, когда данные действительно имеют естественный ключ секционирования.
В 1985–1987 годах модель виртуальной синхронизации была предложена и стала широко распространенным стандартом (она использовалась в системах Isis Toolkit, Horus, Transis, Ensemble, Totem, Spread , C-Ensemble, Phoenix и Quicksilver и является основу для стандарта отказоустойчивых вычислений CORBA ). Виртуальная синхронизация допускает многоосновной подход, при котором группа процессов взаимодействует для распараллеливания некоторых аспектов обработки запросов. Эту схему можно использовать только для некоторых форм данных в памяти, но она может обеспечить линейное увеличение размера группы.
Ряд современных продуктов поддерживают подобные схемы. Например, Spread Toolkit поддерживает ту же самую модель виртуальной синхронизации и может использоваться для реализации схемы репликации с несколькими первичными узлами; таким же образом можно было бы использовать C-Ensemble или Quicksilver. WANdisco допускает активную репликацию, при которой каждый узел в сети является точной копией или репликой и, следовательно, каждый узел в сети активен одновременно; эта схема оптимизирована для использования в глобальной сети (WAN).
Современные протоколы мультипервичной репликации оптимизируют общую безотказную работу. Цепная репликация [12] — популярное семейство таких протоколов. Современные варианты протокола [13] цепной репликации обеспечивают высокую пропускную способность и высокую согласованность за счет организации реплик в цепочке для записи. Этот подход обеспечивает локальное чтение на всех узлах реплики, но имеет высокую задержку при записи, которая должна проходить через несколько узлов последовательно.
Более поздний многоосновной протокол Hermes [14] сочетает в себе аннулирование на основе когерентного кэша и логические временные метки для достижения строгой согласованности с локальным чтением и высокопроизводительной записью со всех реплик. Во время безошибочной работы его широковещательные записи не конфликтуют и фиксируются после всего лишь одного многоадресного обращения к узлам реплики. Такая конструкция обеспечивает высокую пропускную способность и низкую задержку как при чтении, так и при записи.