`

СПЕЦІАЛЬНІ
ПАРТНЕРИ
ПРОЕКТУ

Чи використовує ваша компанія ChatGPT в роботі?

BEST CIO

Определение наиболее профессиональных ИТ-управленцев, лидеров и экспертов в своих отраслях

Человек года

Кто внес наибольший вклад в развитие украинского ИТ-рынка.

Продукт года

Награды «Продукт года» еженедельника «Компьютерное обозрение» за наиболее выдающиеся ИТ-товары

 

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

0 
 

Стандартный подход к защите данных до недавних пор заключался в создании резервной копии и хранении ее, для большей надежности, в другом офисе или, скажем, в банке. Однако вследствие взрывного роста объемов информации и ее ценности, а также необходимости непрерывного доступа к ней не остается достаточно времени на ее восстановление. Например, восстановление 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).


Заключение

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

Ready, set, buy! Посібник для початківців - як придбати Copilot для Microsoft 365

0 
 

Напечатать Отправить другу

Читайте также

 

Ukraine

 

  •  Home  •  Ринок  •  IТ-директор  •  CloudComputing  •  Hard  •  Soft  •  Мережі  •  Безпека  •  Наука  •  IoT