Назад | Перейти на главную страницу

Слишком много технологий репликации данных в среде

Можно настроить удаленную репликацию данных на многих уровнях стека хранения. Несколько примеров, объясняющих, что я имею в виду под слоями:

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

Мой вопрос: игнорируя отдельные примеры продуктов, какой уровень или комбинация уровней репликации обеспечивают наибольшую ценность в типичной корпоративной среде, а какие становятся более ценными?

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

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

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

На самом деле задействовано слишком много разных сценариев. Некоторые примеры:

  • Контроллеры домена Active Directory разработан работать как реплицированная распределенная база данных с несколькими мастерами; и вы также необходимость чтобы иметь локальные контроллеры домена в настройке WAN, потому что подключенным к домену машинам Windows необходимо иметь доступный контроллер домена для правильной работы. В то же время с AD вы не выиграете вообще от наличия репликации более низкого уровня, на уровне виртуального сервера или на уровне физического хранилища, поскольку вы не можете иметь DC "монтировать" базу данных, скопированную из другого, и вы не можете либо запустить клонированный DC и ожидать чтобы он работал (даже не пытайтесь, откат USN противный).
  • Для файлового сервера все наоборот: пока есть являются технологии репликации на уровне приложений (DFS в Windows), для больших объемов данных репликация на уровне хранилища, вероятно, является лучшим подходом.
  • Теперь предположим, что вы используете Exchange; последние системы Exchange (2007–2010) разработаны с учетом репликации транзакционных баз данных, и это единственный официально поддерживаемый подход; ты на самом деле жестяная банка скопируйте базу данных Exchange и подключите ее к другому серверу Exchange (это называется «переносимость базы данных»), чтобы репликация на уровне хранилища мог заставить работать ... но это намного более болезненно, и перемещение пользователей на такой сервер требует серьезной перенастройки. Кроме того, хотя в двух вышеупомянутых сценариях на самом деле является точка наличия локальных копий данных в нескольких местах (AD требуется везде, а пользователям в разных офисах может потребоваться доступ к одним и тем же данным файлового сервера), для Exchange это имеет смысл только в сценарии аварийного восстановления, потому что в обычном Каждый пользователь получает доступ только к своему собственному почтовому ящику, который может быть активен только на одном сервере одновременно.
  • Для различных систем баз данных, опять же, это может работать как на уровне приложения, так и на любом базовом уровне; но это сильно зависит от приложения: если вам нужно изменить данные в нескольких местах (а не только их читать), репликация хранилища не может объединить конфликтующие копии, и вам нужно будет позволить вашей СУБД справиться с этим.

Каждая технология имеет свои преимущества и варианты использования; действительно не существует универсального подхода.

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

Стандартизация репликации на уровне виртуального сервера

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

Преимущества:

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

Недостатки:

  • Серверы аварийного восстановления большую часть времени простаивают: возможная трата ресурсов сервера.
  • Может быть сложно протестировать DR без полного переключения при отказе, учитывая, что IP-адреса соответствуют Prod.
  • Репликация происходит немедленно, поэтому, если есть повреждение данных в Prod, они немедленно распространяются на DR.
  • Может быть сложно использовать этот метод для клонирования в Dev / Test.
  • Не может использоваться с системами, которые плохо работают на виртуальной машине.

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

Стандартизация репликации на уровне приложений

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

Преимущества:

  • Многие приложения могут работать в режиме с несколькими ведущими или ведущими-ведомыми, чтобы использовать все ресурсы сервера.
  • Многие приложения могут передавать изменения в кратком формате, экономя полосу пропускания и улучшая производительность.
  • Некоторые приложения могут отложить внесение изменений, чтобы предотвратить немедленное распространение повреждения при аварийном восстановлении.
  • Относительно легко разделить репликацию и перенастроить серверы как Dev / Test.

Недостатки:

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

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