Вопросы Теги

Географический DB синхронное зеркальное отражение

Эти предыдущие вопросы могли бы быть информативными:

SELinux в Реальном мире

и

Реальный пример безопасности SELinux?

и

Причины отключить / включают SELinux

5
задан 12 June 2009 в 22:36
4 ответа

Хотя сетевая пропускная способность играет роль в значительной степени, абсолютный фактор номер один для рассмотрения - то, что скорость генерации журнала транзакций на принципале?

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

Для ответа на фактический вопрос конфигурация h/w может работать (сетевые проблемы в стороне), если нет большой рабочей нагрузки OLTP на принципале. Если существует, и Вы имеете 4x4 ядра процессора, генерирующие журнал транзакций затем, вероятно, что Ваш зеркальный сервер не сможет не отставать от воспроизведения журнала, неважно, может ли Ваша сеть справиться с трафиком журнала. На Стандартном выпуске существует одно ВОССТАНОВЛЕНИЕ обработки потока входа в систему зеркало - таким образом, Ваша очередь ВОССТАНОВЛЕНИЯ собирается стать довольно многочисленной под большой нагрузкой.

Очередь ВОССТАНОВЛЕНИЯ является суммой журнала, который был укреплен на зеркале, но еще не воспроизведен в зеркальной базе данных - чем больше это, тем дольше это будет, прежде чем зеркальная база данных прибывает в строку как принципал в случае обработки отказа. Это особенно неприятно в Standard Edition, где у Вас нет функций как параллельное восстановление, и быстрое восстановление (база данных прибывает онлайн после ВОССТАНОВЛЕНИЯ и перед ОТМЕНОЙ), доступный.

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

Надеюсь, это поможет.

5
ответ дан 3 December 2019 в 01:12
  • 1
    Спасибо, да это действительно помогает. Так there' проблемы потенциала s 3: 1. Сетевая пропускная способность насыщается транзакциями, вызывающими отставание и недопустимое время отклика для конечных пользователей. 2. Продолжительность обработки отказа (если Вы происходите) может быть расширена в напряженное время, поскольку зеркально отраженные транзакции воспроизводятся с единственным потоком (ограничение Стандартного выпуска). 3. Если заменено к вторичному серверу, это не может быть человек достаточно для обработки рабочей нагрузки в напряженное время. –  SuperCoolMoss 13 June 2009 в 22:20
  • 2
    Абсолютно. Довольный помочь. –  Paul Randal 13 June 2009 в 22:32

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

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

сопроводительный текст http://i.technet.microsoft.com/Cc917681.dbm_fig09 (en-us, TechNet.10) .gif

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

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

5
ответ дан 3 December 2019 в 01:12
  • 1
    Спасибо за ссылки Brent. Клиент хочет нулевую потерю данных - так can' t асинхронное использование. Будет реорганизовывать индексы с более высоким уровнем фрагментации ежедневно - надо надеяться, во время низкого транзакционного действия. –  SuperCoolMoss 13 June 2009 в 22:34

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

Некоторые вещи рассмотреть, в целях активного/резервного резервного копирования, VM является не обязательно плохим выбором. Если диски для VM находятся на SAN, необходимо видеть довольно хорошую производительность.

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

Я должен также добавить - в то время как документация OpenVMS говорит много о OpenVMS а именно, проблемы задержки применимы к любому виду зеркального отражения или кластеризации приложения. Выполнение "математики" о задержке скорости света Вашего расстояния ссылки может быть очень освещающим w/r к задержке и скорости отклика по большим расстояниям.

0
ответ дан 3 December 2019 в 01:12

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

Хорошо рассмотрите сетевой канал

  • Действительно ли это стабильно?
  • Сколько потеря пакетов там?
  • Сколько пропускной способности доступно?
  • Действительно ли это - ссылка, которую все остальные используют для перемещения по Интернету на работе?

Хорошо рассмотрите БЕЗ

  • Сколько диски там?
  • Как что установка RAID?
  • Сколько другие приложения будут совместно использовать ресурсы?
  • Каково текущее использование SAN?

Затем посмотрите на свое приложение

  • Сколько раз Вы будете получать доступ к данным?
  • Как большой база данных вырастет? (Приблизительная оценка)
  • Как часто индексы будут созданы?
  • Сколько загрузки Ваши запросы ставят ЦП, Память и Диск?
  • Как данные будут проверены на удаленных концах ссылки?

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

Виртуальные машины обычно не, IMO, причина узких мест. Это во многом зависит от того, как они - установка и распределение ресурсов. Ввод-вывод обычно является единственным самым большим фактором в скорости VM, те SAN должны значительно помочь Вашей скорости.

Каждое приложение отличается, но Вы и Ваш Архитектор должны сесть и ответить на эти вопросы (выше) вместе. И все другие, что всплывающее окно в процессе.

И если все остальное перестало работать, пойдите, покупают другой сервер и удаляют VM.

0
ответ дан 3 December 2019 в 01:12
  • 1
    I' ve везло с продуктами DoubleTake для репликации, особенно БАЗ ДАННЫХ SQL MS... –  Joseph Kern 12 June 2009 в 23:24

Теги

Похожие вопросы