Меню

Средства репликации что это

Выбор технологии репликации данных

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

Стандартный подход к защите данных до недавних пор заключался в создании резервной копии и хранении ее, для большей надежности, в другом офисе или, скажем, в банке. Однако вследствие взрывного роста объемов информации и ее ценности, а также необходимости непрерывного доступа к ней не остается достаточно времени на ее восстановление. Например, восстановление 2 ТB данных даже на таком быстром устройстве, как Exabyte Mammoth2, займет не менее двух суток, не считая времени доставки резервной копии. А при полном крахе системы нужно еще учитывать время установки ОС и ПО резервного копирования. При чрезвычайных обстоятельствах (пожар, стихийные бедствия) необходимо также время на поиски нового оборудования, аналогичного действующему, на котором будет развертываться копия, и квалифицированного персонала. Что же тогда говорить о ситуациях, когда простой недопустим или может измеряться лишь минутами (например, в системе международных безналичных банковских расчетов)? В этих случаях применяются различные технологические решения по обеспечению непрерывности бизнеса и быстрого восстановления данных. Основной частью таких решений является какая-либо из технологий репликации.

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

Что такое репликация данных?

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

Прерывания работы можно условно разделить на два вида:s

  • физические — сбои в работе оборудования или из-за природных явлений, устраняются с помощью технологий зеркалирования;
  • логические — ошибки приложений и пользователей, вирусные и хакерские атаки, действия «обиженных» пользователей; преодолеваются посредством создания «моментальных снимков» и «клонов» данных для определенных моментов времени.

Такое разделение позволяет учесть динамическую и статическую природу соответственно зеркалирования и создания «моментальных снимков» и выбрать необходимую технологию.

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

Способы и типы репликации данных

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

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

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

Репликация на уровне хоста

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

Специфичным способом репликации на уровне хоста, соотносительно варианта организации данных, является репликация на подуровне приложения. Так как реализация распределенных систем клиент-сервер предполагает применение репликации данных, то после появления первых клиент-серверных приложений были разработаны и первые продукты для репликации на подуровне приложения. В 1984 г. данную технологию впервые использовали в проекте Lotus Notes, и уже в 1987 г. вместе с выходом первой версии этого продукта она была представлена на рынке.

Читайте также:  Средство антей для чего

Для систем управления базами данных технологии репликации на уровне приложения первыми применили в корпорации IBM для БД IMS (также в 1987 г.). Заметим, что это было очень дорогое решение, доступное только крупнейшим компаниям.

Хотя перспективность распределенных баз данных достаточно давно признана, соответствующая технология была либо слишком ограниченной, либо чересчур сложной. Только начиная с 1997 г. ситуация изменилась. У каждой из основных компаний, производящих СУБД, появилось решение для репликации БД.

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

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

Типичная сфера применения: быстрое восстановление после чрезвычайных происшествий, создание «моментальных снимков» и миграция данных.

Примеры продуктов для различных ОС (Windows, AIX, Solaris, HP-UX, z/OS): Legato RepliStor, Veritas Storage Replicator, NSI Double-Take, IBM HAGEO и GeoRM, Sun StorEdge Availability Suite, Softek Replicator и TDMF.

Репликация на этом подуровне обычно используется там, где необходимо синхронизировать небольшое количество файлов. Она позволяет производить выборочную репликацию данных и их перенос на томах различного размера. Этот способ работает на уровне файловой системы, чем определяются все преимущества и недостатки вышеуказанного типа. К примеру, он не годится для создания копии БД или заблокированных системных файлов. И в то же время репликация на файловом подуровне прекрасно подходит для приложений, в которых необходимо обеспечить одновременный доступ ко всем копиям файлов данных. Классический вариант: ферма Web-серверов.

Примеры продуктов: HP OpenView Storage Mirroring и протокол SUP (Software Update Protocol), разработанный в институте Карнеги Меллона.

Подуровень логических томов

Создание «зеркальной» копии данных с помощью менеджера логических томов чаще применяется для увеличения надежности доступа к данным на локальном уровне, чем для создания удаленных копий или «моментальных снимков». Такой способ также используется для миграции данных, но не является лучшим для этого вида работ, так как существуют некоторые архитектурные ограничения. Например, если источник данных размещен на томе с чередованием (striped volume), то обычно и получатель должен быть на таком же томе.

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

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

Примеры продуктов: Veritas Volume Manager, IBM LVM.

Репликация на уровне сети хранения данных (SAN)

Это решение базируется на новейшей технологии виртуализации доступа к данным по основному каналу (in-band) и предполагает размещение на пути между серверами и системой хранения данных посредника — специализированного устройства виртуализации.

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

Репликация на уровне сети хранения данных является практически идеальным вариантом для распределенных БД или кластеров active-active.

Термин active-active относится к кластерам, в которых на каждом узле запущен как минимум один виртуальный сервер. Когда на одном из узлов выполняется приложение (например, БД для системы SAP R/3), второй узел не находится в ожидании возможного сбоя первого узла, а запускает собственное приложение (например, Central Instance и Application Servers для системы SAP R/3) или другую задачу того же приложения, что и на первом узле, и работает в готовности принять на себя задачу от первого узла. Первый же узел, в свою очередь, в случае сбоя берет на себя выполнение приложения второго узла. При этом конфигурация узлов кластера active-active должна соответствовать возможностям работы под нагрузкой двух приложений при сбое одного из серверов.

Примеры продуктов: серверы управления данными с ПО IPStor Enterprise, концентраторы компании StoneFly, HP CASA, IBM SAN Volume Controller (рекомендованный объем данных на один узел управления — 10 ТB).

Репликация на уровне дискового массива

Это наиболее универсальное, производительное и надежное решение. Функции репликации на уровне дисковых массивов встроены в контроллеры дискового массива, при этом использование ресурсов серверов не предполагается. Репликация на уровне дискового массива — самая «зрелая», апробированная технология.

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

Примеры продуктов: технологии EMC SRDF и TimeFinder (для Symmetrix), синхронный и асинхронный MirrorView и SnapView (для CLARiiON), технологии IBM PPRC (для ESS), Remote Volume Mirror (для FAStT) и FlashCopy (для ESS и FAStT).

Читайте также:  Чем грозит постоянное вливание денежных средств в экономику

Каждый тип репликации имеет свою стоимость. Необходимо помнить, что приобретение решения низшего класса обычно не означает достижения низких операционных расходов, так как цена покупки напрямую не связана с реальной стоимостью владения и мерой полезности. У каждой технологии есть свои достоинства и недостатки. Репликация на уровне хоста значительно снижает производительность серверов приложений. Репликация на уровне сети хранения данных является новой технологией и предполагает наряду с приобретением системы хранения данных покупку дополнительного устройства (посредника) и затраты на обучение персонала; репликация на уровне дискового массива «привязывает» вас к одному производителю. Поэтому необходимо тщательно проанализировать свою информационную инфраструктуру, используемые серверы и системы хранения данных и выбрать технологию, в наибольшей степени соответствующую ценности вашей информации, стратегии развития и бюджету.

Источник



Что такое «Репликация баз данных»?

Что такое репликация? Это средство организации работы одного или нескольких пользователей с одним и тем же документом, базой данных или другими-файлами на разных компьютерах независимо, без одновременного доступа к файлам, но когда требуется поддерживать некоторую общую версию изменяемых файлов, содержащую в себе все последние исправления, сделанные независимо. Более конкретно, репликация — это процесс создания копий файлов, между которыми может осуществляться обмен обновляемыми данными или объектами. Такие копии называются репликами, а такой обмен — синхронизацией .

Когда нужна репликация? Microsoft приводит два примера необходимости в такой организации работы.

  • Вы — агент по продажам и совершаете поездки для посещения клиентов. Перед поездкой вам нужно просмотреть последние заказы и маркетинговые тенденции клиентов, которых вы собираетесь посетить. Эта информация хранится в базах данных о клиентах и заказах вашей компании. Вы загружаете данные о клиентах на свой переносной компьютер. Во время посещения клиента вы обновляете загруженную информацию о клиенте, например: номера телефонов, адреса E-mail и прочую персональную информацию о клиенте на вашем переносном компьютере, а также вносите туда информацию о новых заказах. Однако вам необходимо закончить работу с заказами как можно быстрее. В конце дня вы подключаетесь по Интернету к сети вашей компании через защищенное удаленное соединение и обновляете базы данных о клиентах и заказах. Конфликты данных автоматически разрешаются благодаря имеющимся бизнес-процедурам. После этого вы печатаете и отправляете клиенту по факсу отчет о принятии заказа или отправляете снимок отчета по E-mail, который клиент может просмотреть с помощью программы Просмотр снимков (Snapshot Viewer).
  • Вы — разработчик программного обеспечения и хотите закончить работу с приложением вашей компании, отслеживающим статистику об обнаружении и исправлении ошибок в проекте, дома, где нет необходимого или защищенного доступа к корпоративной сети. Вы забираете данные только о ваших ошибках, помещая их на свой переносной компьютер, и отключаете его от корпоративной сети. Затем приходите домой и работаете с имеющимися данными, изменяя поля статуса ошибки и прочие поля с информацией об ошибке. На следующий день* вы подключаете свой переносной компьютер к корпоративной сети и легко син-* хронизируете свои изменения с приложением вашей компании, отслеживающим; статистику ошибок в проекте.

Существует несколько средств репликации баз данных, проектов Access и других файлов.

  • Портфельная репликация средство операционной системы Microsoft Windows. Оно позволяет осуществлять репликацию файлов многих типов, в том числе баз данных Access (файлов MDB), исключая проекты Access (файлы ADP).
  • Репликация баз данных и проектов средствами Access — встроенные средства Microsoft Access. Они предназначены для репликации баз данных и проектов Access.
  • Репликация с помощью Диспетчера репликации Microsoft полнофункциональное средство управления репликами, планирования синхронизации и просмотра элементов набора реплик. Диспетчер репликации входит в комплект средств разработчика Microsoft Office 2002 Developer Edition. Описание Диспетчера репликации (Replication Manager) можно найти в документации этого комплекта.
  • Репликация файлов на сервере Web средство сервера Web фирмы Microsoft. Оно позволяет работать с файлами, сохраненными на узле Web, в автономном режиме — без подключения к серверу.
  • Программная репликация с помощью интерфейсов DАО и JRO. Создание и управление репликами баз данных Access может осуществляться программно — в процедурах на VBA. Разработчики приложений Access могут обеспечить автоматическую синхронизацию реплик и прочие действия, связанные с репликацией, используя специальные свойства и методы объектов из библиотек VBA: Объекты репликации и Jet (JRO) для репликации баз данных Access 2000 и выше и Объекты доступа к данным (DАО) для репликации баз данных более ранних версий — Access 95 и 97.

Репликация включает следующие действия:

  • выбор средства репликации;
  • создание реплик;
  • синхронизация реплик;
  • управление репликами.

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

Источник

Репликация данных

Репликация — одна из техник масштабирования баз данных. Состоит эта техника в том, что данные с одного сервера базы данных постоянно копируются (реплицируются) на один или несколько других (называемые репликами). Для приложения появляется возможность использовать не один сервер для обработки всех запросов, а несколько. Таким образом появляется возможность распределить нагрузку с одного сервера на несколько.

Читайте также:  Средство для мытья пола чисто clean world 5 л

Существует два основных подхода при работе с репликацией данных:

  • Репликация Master-Slave;
  • Репликация Master-Master.

Master-Slave репликация

В этом подходе выделяется один основной сервер базы данных, который называется Мастером. На нем происходят все изменения в данных (любые запросы MySQL INSERT/UPDATE/DELETE). Слейв сервер постоянно копирует все изменения с Мастера. С приложения на Слейв сервер отправляются запросы чтения данных (запросы SELECT). Таким образом Мастер сервер отвечает за изменения данных, а Слейв за чтение.

В приложении нужно использовать два соединения – одно для Мастера, второе — для Слейва:

Используем два соединения — для Мастера и Слейва — для записи и чтения соответственно

Несколько Слейвов

Преимущество этого типа репликации в том, что Вы можете использовать более одного Слейва. Обычно следует использовать не более 20 Слейв серверов при работе с одним Мастером.

Тогда из приложения Вы выбираете случайным образом один из Слейвов для обработки запросов:

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

При обращении к изменяемым данным, необходимо использовать Мастер-соединение

Выход из строя

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

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

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

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

Master-Master репликация

В этой схеме, любой из серверов может использоваться как для чтения так и для записи:

При использовании такого типа репликации достаточно выбирать случайное соединение из доступных Мастеров:

Выбор случайного Мастера для обработки соединений

Выход из строя

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

Используйте Master-Master репликацию только в крайнем случае. Вместо нее лучше пользоваться техникой “ручной” репликации, описанной ниже.

Асинхронность репликации

В MySQL репликация работает в асинхронном режиме. Это значит, что приложение не знает, как быстро данные появятся на Слейве.

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

Синхронный режим

Синхронный режим репликации позволит гарантировать копирование данных на Слейв.

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

“Ручная” репликация

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

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

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

Все операции изменения данных происходят на нескольких серверах, а чтения — на одном случайном

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

Выход из строя

При поломке одного из серверов в такой схеме необходимо сделать следующее:

  • Исключить сервер из списка используемых.
  • Настроить репликацию Master-Slave на новом сервере, используя один из рабочих серверов в качестве Мастера.
  • Когда все данные репликации будут синхронизированы, включить сервер обратно в список используемых и остановить репликацию.

Самое важное

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

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

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Источник