Репликация в вычислительной технике подразумевает обмен информацией с целью обеспечения согласованности между избыточными ресурсами, такими как программные или аппаратные компоненты, для повышения надежности, отказоустойчивости или доступности.
Репликация в вычислительной технике может означать:
Репликация в пространстве или во времени часто связана с алгоритмами планирования. [1]
Доступ к реплицированной сущности обычно един с доступом к одной нереплицированной сущности. Сама репликация должна быть прозрачной для внешнего пользователя. В случае отказа отказ реплик должен быть максимально скрыт в отношении качества обслуживания . [2]
Специалисты в области компьютерной техники далее описывают репликацию как:
Когда одна реплика-лидер назначается через выборы лидера для обработки всех запросов, система использует схему «первичный-резервный» или «первичный-реплика» , которая преобладает в кластерах высокой доступности . Для сравнения, если любая реплика может обрабатывать запрос и распространять новое состояние, система использует схему «многопервичный» или «многомастерный» . В последнем случае необходимо использовать некоторую форму распределенного управления параллелизмом , например распределенный менеджер блокировок .
Балансировка нагрузки отличается от репликации задач, поскольку она распределяет нагрузку различных вычислений по машинам и позволяет отбросить одно вычисление в случае сбоя. Однако балансировка нагрузки иногда использует репликацию данных (особенно репликацию с несколькими мастерами ) внутренне, чтобы распределить свои данные между машинами.
Резервное копирование отличается от репликации тем, что сохраненная копия данных остается неизменной в течение длительного периода времени. [3] Реплики, с другой стороны, подвергаются частым обновлениям и быстро теряют любое историческое состояние. Репликация является одной из старейших и важнейших тем в общей области распределенных систем .
Репликация данных и репликация вычислений требуют процессов для обработки входящих событий. Процессы для репликации данных пассивны и работают только для поддержания сохраненных данных, ответа на запросы на чтение и применения обновлений. Репликация вычислений обычно выполняется для обеспечения отказоустойчивости и принятия операции на себя в случае отказа одного компонента. В обоих случаях основные потребности заключаются в том, чтобы гарантировать, что реплики видят одни и те же события в эквивалентных порядках, чтобы они оставались в согласованных состояниях, и любая реплика могла отвечать на запросы.
Существуют три широко цитируемые модели репликации данных, каждая из которых имеет свои собственные свойства и производительность:
Репликация базы данных может использоваться во многих системах управления базами данных (СУБД), обычно с отношением первичный/реплика между оригиналом и копиями. Первичный регистрирует обновления, которые затем передаются репликам. Каждая реплика выводит сообщение о том, что она успешно получила обновление, тем самым позволяя отправлять последующие обновления.
В репликации с несколькими мастерами обновления могут быть отправлены на любой узел базы данных, а затем переданы на другие серверы. Это часто желательно, но приводит к существенному увеличению затрат и сложности, что может сделать это непрактичным в некоторых ситуациях. Наиболее распространенной проблемой, которая существует в репликации с несколькими мастерами, является предотвращение или разрешение конфликтов транзакций . Большинство решений синхронной (или активной) репликации выполняют предотвращение конфликтов, в то время как асинхронные (или ленивые) решения должны выполнять разрешение конфликтов. Например, если одна и та же запись изменяется на двух узлах одновременно, система активной репликации обнаружит конфликт до подтверждения фиксации и прервет одну из транзакций. Система ленивой репликации позволит обеим транзакциям фиксироваться и выполнять разрешение конфликтов во время повторной синхронизации. [7] Разрешение такого конфликта может быть основано на временной метке транзакции, на иерархии исходных узлов или на гораздо более сложной логике, которая принимает решения последовательно по всем узлам.
Репликация базы данных становится более сложной, когда она масштабируется горизонтально и вертикально. Горизонтальное масштабирование имеет больше реплик данных, в то время как вертикальное масштабирование имеет реплики данных, расположенные на больших физических расстояниях. Проблемы, возникающие при горизонтальном масштабировании, могут быть смягчены многоуровневым протоколом доступа с несколькими представлениями . Ранние проблемы вертикального масштабирования в значительной степени были решены путем повышения надежности и производительности Интернета. [8] [9]
Когда данные реплицируются между серверами баз данных, так что информация остается согласованной во всей системе базы данных, и пользователи не могут сказать или даже знать, какой сервер в СУБД они используют, говорят, что система демонстрирует прозрачность репликации.
Однако прозрачность репликации не всегда может быть достигнута. Когда данные реплицируются в базе данных, они будут ограничены теоремой CAP или теоремой PACELC . В движении NoSQL согласованность данных обычно приносится в жертву другим более желаемым свойствам, таким как доступность (A), устойчивость к разделению (P) и т. д. Различные модели согласованности данных также были разработаны для использования в качестве соглашения об уровне обслуживания (SLA) между поставщиками услуг и пользователями.
Активная (в реальном времени) репликация хранилища обычно реализуется путем распространения обновлений блочного устройства на несколько физических жестких дисков . Таким образом, любая файловая система, поддерживаемая операционной системой , может быть реплицирована без изменений, поскольку код файловой системы работает на уровне выше уровня драйвера блочного устройства. Он реализуется либо аппаратно (в контроллере дискового массива ), либо программно (в драйвере устройства ).
Самый простой метод — зеркалирование дисков , которое типично для локально подключенных дисков. Индустрия хранения данных сужает определения, поэтому зеркалирование — это локальная (на небольшом расстоянии) операция. Репликация может быть расширена по компьютерной сети , так что диски могут быть расположены в физически удаленных местах, и обычно применяется модель репликации первичной/репликовой базы данных. Цель репликации — предотвратить ущерб от сбоев или катастроф , которые могут произойти в одном месте, или в случае, если такие события действительно происходят, улучшить возможность восстановления данных. Для репликации задержка является ключевым фактором, поскольку она определяет либо то, насколько далеко друг от друга могут находиться сайты, либо тип репликации, который может быть использован.
Основной характеристикой такой межсайтовой репликации является то, как обрабатываются операции записи: посредством асинхронной или синхронной репликации; синхронная репликация должна ждать ответа целевого сервера при любой операции записи, тогда как асинхронная репликация этого не делает.
Синхронная репликация гарантирует «нулевую потерю данных» с помощью атомарных операций записи, где операция записи не считается завершенной, пока не будет подтверждена как локальным, так и удаленным хранилищем. Большинство приложений ждут завершения транзакции записи, прежде чем продолжить работу, поэтому общая производительность значительно снижается. По сути, производительность падает пропорционально расстоянию, поскольку минимальная задержка диктуется скоростью света . Для расстояния 10 км максимально возможный цикл занимает 67 мкс, тогда как вся локальная кэшированная запись завершается примерно за 10–20 мкс.
При асинхронной репликации операция записи считается завершенной, как только локальное хранилище ее подтвердит. Удаленное хранилище обновляется с небольшой задержкой . Производительность значительно увеличивается, но в случае сбоя локального хранилища удаленное хранилище не гарантирует наличие актуальной копии данных (последние данные могут быть утеряны).
Полусинхронная репликация обычно считает операцию записи завершенной, когда она подтверждена локальным хранилищем и получена или зарегистрирована удаленным сервером. Фактическая удаленная запись выполняется асинхронно, что приводит к лучшей производительности, но удаленное хранилище будет отставать от локального хранилища, поэтому нет гарантии долговечности (т. е. бесшовной прозрачности) в случае отказа локального хранилища. [ необходима цитата ]
Репликация в определенный момент времени создает периодические моментальные снимки , которые реплицируются вместо первичного хранилища. Это предназначено для репликации только измененных данных, а не всего тома. Поскольку при использовании этого метода реплицируется меньше информации, репликация может происходить по менее дорогим каналам пропускания, таким как iSCSI или T1, а не по оптоволоконным линиям.
Многие распределенные файловые системы используют репликацию для обеспечения отказоустойчивости и предотвращения возникновения единой точки отказа.
Многие коммерческие системы синхронной репликации не зависают при отказе удаленной реплики или потере соединения (поведение, гарантирующее нулевую потерю данных), а продолжают работать локально, теряя желаемую нулевую точку восстановления .
Для устранения ограничений, налагаемых задержкой, можно применять методы оптимизации глобальной сети (WAN) .
Файловая репликация осуществляет репликацию данных на логическом уровне (т. е. отдельных файлов данных), а не на уровне блоков хранения. Существует много различных способов сделать это, которые почти исключительно полагаются на программное обеспечение.
Драйвер ядра (в частности, драйвер фильтра ) может использоваться для перехвата вызовов функций файловой системы, фиксируя любую активность по мере ее возникновения. Это использует тот же тип технологии, который используют активные антивирусные программы в реальном времени. На этом уровне захватываются логические файловые операции, такие как открытие файла, запись, удаление и т. д. Драйвер ядра передает эти команды другому процессу, как правило, по сети на другую машину, которая будет имитировать операции исходной машины. Как и репликация хранилища на уровне блоков, репликация на уровне файлов допускает как синхронный, так и асинхронный режимы. В синхронном режиме операции записи на исходной машине удерживаются и не могут выполняться до тех пор, пока целевая машина не подтвердит успешную репликацию. Синхронный режим менее распространен в продуктах для репликации файлов, хотя существует несколько решений.
Решения для репликации на уровне файлов позволяют принимать обоснованные решения о репликации на основе местоположения и типа файла. Например, временные файлы или части файловой системы, не имеющие деловой ценности, могут быть исключены. Передаваемые данные также могут быть более детализированными; если приложение записывает 100 байт, то передаются только 100 байт вместо полного дискового блока (обычно 4096 байт). Это существенно сокращает объем данных, отправляемых с исходной машины, и нагрузку на хранилище на целевой машине.
К недостаткам этого программного решения относятся необходимость внедрения и обслуживания на уровне операционной системы, а также повышенная нагрузка на вычислительную мощность машины.
Подобно журналам транзакций базы данных , многие файловые системы имеют возможность вести журнал своей активности. Журнал может быть отправлен на другую машину, либо периодически, либо в режиме реального времени с помощью потоковой передачи. На стороне реплики журнал может использоваться для воспроизведения изменений файловой системы.
Одной из примечательных реализаций является System Center Data Protection Manager (DPM) от Microsoft , выпущенный в 2005 году, который выполняет периодические обновления, но не обеспечивает репликацию в реальном времени. [ необходима ссылка ]
Это процесс сравнения исходной и целевой файловых систем и обеспечение соответствия назначения источнику. Главное преимущество в том, что такие решения, как правило, бесплатны или недороги. Недостаток в том, что процесс их синхронизации довольно требователен к ресурсам системы, и, следовательно, этот процесс обычно выполняется нечасто.
Одной из примечательных реализаций является rsync .
В страничной операционной системе страницы в файле подкачки иногда дублируются в пределах дорожки для уменьшения задержки вращения.
В VSAM от IBM данные индекса иногда реплицируются внутри дорожки для уменьшения задержки вращения.
Другой пример использования репликации появляется в распределенных системах общей памяти, где многие узлы системы совместно используют одну и ту же страницу памяти. Обычно это означает, что каждый узел имеет отдельную копию (реплику) этой страницы.
Многие классические подходы к репликации основаны на модели первичного резервного копирования, где одно устройство или процесс имеет односторонний контроль над одним или несколькими другими процессами или устройствами. Например, первичное устройство может выполнять некоторые вычисления, передавая журнал обновлений в резервный (резервный) процесс, который затем может взять на себя управление в случае сбоя первичного устройства. Этот подход распространен для репликации баз данных, несмотря на риск того, что если часть журнала будет утеряна во время сбоя, резервное копирование может не находиться в состоянии, идентичном первичному, и транзакции могут быть потеряны.
Слабость схем первичного резервного копирования заключается в том, что только одна из них фактически выполняет операции. Отказоустойчивость достигается, но идентичная система резервного копирования удваивает затраты. По этой причине, начиная с 1985 года , сообщество исследователей распределенных систем начало изучать альтернативные методы репликации данных. Результатом этой работы стало появление схем, в которых группа реплик могла сотрудничать, причем каждый процесс действовал как резервная копия, а также обрабатывал часть рабочей нагрузки.
Ученый-компьютерщик Джим Грей проанализировал многопервичные схемы репликации в рамках транзакционной модели и опубликовал широко цитируемую статью, в которой скептически отнесся к подходу «Опасности репликации и решение». [10] [11] Он утверждал, что если данные не будут разделены каким-либо естественным образом, так что базу данных можно будет рассматривать как 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] объединяет индуцированные кэшем когерентные аннулирования и логические временные метки для достижения высокой согласованности с локальными чтениями и высокопроизводительными записями со всех реплик. Во время безотказной работы его широковещательные записи не конфликтуют и фиксируются всего после одного многоадресного кругового обхода к узлам реплик. Такая конструкция обеспечивает высокую пропускную способность и низкую задержку как для чтения, так и для записи.