Назад |
Перейти на главную страницу
Слишком много технологий репликации данных в среде
Можно настроить удаленную репликацию данных на многих уровнях стека хранения. Несколько примеров, объясняющих, что я имею в виду под слоями:
- Уровень физического тома (TruCopy, SRDF / MirrorView, SnapMirror)
- Уровень виртуального сервера (vReplicator, Veeam)
- Уровень логического тома (VVR, AVS)
- Уровень файловой системы (Rsync, ZFS Send / Recv)
- Уровень приложения (Data Guard, MySQL / PostgreSQL Replication, AD Replication)
Репликация на каждом уровне имеет уникальное ценностное предложение, но было бы безумием использовать их все. Моя особая проблема - это распространение различных решений; Я хотел бы стандартизировать одно или два решения, чтобы снизить стоимость лицензий, сложность и требования к опыту.
Мой вопрос: игнорируя отдельные примеры продуктов, какой уровень или комбинация уровней репликации обеспечивают наибольшую ценность в типичной корпоративной среде, а какие становятся более ценными?
Возможные метрики включают простоту администрирования, наличие опыта, защиту от повреждения данных, время / сложность восстановления в сценарии аварийного восстановления, сокращение запланированных окон простоя, производительность приложений, гибкость приложений и все остальное, что может быть ценным.
Это вопрос, с которым я часто сталкиваюсь как системный администратор, поэтому буду признателен за любой совет.
Какое решение лучше подходит для данного сценария, сильно зависит от задействованных приложений и данных, не существует «глобального» подхода, который мог бы работать всегда и везде.
На самом деле задействовано слишком много разных сценариев. Некоторые примеры:
- Контроллеры домена 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.
Недостатки:
- Каждая группа приложений должна настраивать репликацию по-своему.
- Не все приложения поддерживают этот тип репликации, поэтому необходим резервный вариант.
Может использоваться в сочетании с технологиями уровня файловой системы для поддержки приложений без возможности репликации.