Архитектор в нашей компании разработал решение, основанное на синхронном зеркалировании 64-битной версии SQL2005 Standard между физическим (4 четырехъядерных, 32 ГБ ОЗУ) сервером и виртуальным сервером аварийного восстановления (4 виртуальных процессора с 16 ГБ ОЗУ) в двух географически удаленных центрах обработки данных с следящий сервер (1 виртуальный ЦП). Хранилище - это SAN корпоративного класса в обоих центрах обработки данных.
Внешнее приложение предназначено для работы в Интернете со смешанным использованием чтения и записи.
Как администратор баз данных (с которым не консультировались на этапе проектирования) я беспокоюсь, что эта конфигурация была разработана с минимизацией избыточности в качестве основного критерия и что она не будет работать как реальное решение - задержка в сети и производительность виртуального коробка вызовет неприемлемое время отклика? И даже более низкая производительность при переключении при отказе.
Есть ли у кого-нибудь опыт подобной настройки?
Microsoft опубликовала действительно хороший технический документ по зеркальному отображению базы данных в том числе несколько хороших примеров того, насколько сильно влияет на производительность синхронное зеркалирование. Вы совершенно правы в том, что это будет настоящий успех. Выполните эхо-запрос от основного блока к зеркалу базы данных и посмотрите время приема-передачи в миллисекундах: это будет абсолютный минимум накладных расходов, которые добавит синхронное зеркальное отображение. Пинг даже не учитывает, сколько времени потребуется удаленному серверу для обработки каждой входящей транзакции - это чисто время задержки сети.
Чем больше задержки в сети, тем ниже производительность, а оборудование просто простаивает:
альтернативный текст http://i.technet.microsoft.com/Cc917681.dbm_fig09(en-us,TechNet.10).gif
Я действительно большой поклонник асинхронного зеркалирования, потому что это простой способ добавить некоторую защиту, но защита может отстать. Это и хорошо, и плохо: это хорошо, потому что может обрабатывать сетевые задержки, но это плохо, потому что вы можете потерять любые данные, которые не попали на сайт аварийного переключения.
Кроме того, когда вы разрабатываете решения зеркального отображения базы данных (синхронные или асинхронные), обязательно подумайте о своих операциях по обслуживанию индекса. Если вы будете выполнять перестройку индекса еженедельно, это полностью убьет ваши невыполненные журналы зеркалирования, поскольку они производят так много регистрируемой активности, которая должна передаваться по сети.
Хотя пропускная способность сети играет важную роль, абсолютный фактор номер один, который следует учитывать, - это какова скорость создания журнала транзакций на основном сервере?
Если приложение и ваше обслуживание не создают журнал транзакций, пропускная способность сети действительно не имеет значения. Если он создает журнал, то пропускная способность сети должна быть способна обрабатывать объем созданного журнала.
Чтобы ответить на ваш фактический вопрос, ваша конфигурация ч / б может работать (не говоря уже о сетевых проблемах), если на главном сервере нет большой рабочей нагрузки OLTP. Если есть, и у вас есть процессорные ядра 4x4, генерирующие журнал транзакций, то, вероятно, ваш зеркальный сервер не сможет справиться с воспроизведением журнала, независимо от того, сможет ли ваша сеть справиться с трафиком журнала. В стандартной версии есть один поток, обрабатывающий REDO журнала на зеркале, поэтому ваша очередь REDO будет довольно большой при большой нагрузке.
Очередь REDO - это объем журнала, который был усилен на зеркале, но еще не воспроизведен в зеркальной базе данных - чем он больше, тем больше времени пройдет до того, как зеркальная база данных станет основной в случае аварийного переключения. . Это особенно неприятно в Standard Edition, где у вас нет таких функций, как параллельный повтор и быстрое восстановление (база данных подключается к сети после REDO и до UNDO).
И, конечно же, после переключения с основного сервера на зеркало, зеркало не сможет обслуживать ту же рабочую нагрузку, что и основной сервер - так что вы будете там, но потенциально работать будет намного медленнее.
Надеюсь это поможет.
Ваша главная забота должна заключаться в сетевой ссылке. Сети SAN не должны быть узким местом, но я не видел никаких данных о производительности, поэтому я не могу сказать вам да или нет. Задайте себе и архитектору следующие вопросы:
Внимательно посмотрите на сетевую ссылку
Внимательно посмотрите на SANS
Тогда посмотрите свое приложение
Настройки вашей оперативной памяти и процессора подходят для корпоративного приложения. Вопросы такого типа очень сложно дать количественно, особенно без реальных данных.
ИМО, виртуальные машины обычно не являются причиной узких мест. Это во многом зависит от того, как они настроены, и от распределения ресурсов. Ввод-вывод обычно является самым большим фактором скорости виртуальной машины, и эти SAN должны значительно повысить вашу скорость.
Каждое приложение отличается, но вы и ваш архитектор должны вместе ответить на эти вопросы (см. Выше). И все остальные, которые появляются в процессе.
А если ничего не помогает, купите другой сервер и удалите виртуальную машину.
У меня нет прямого опыта, но вы должны посмотреть Документация по задержке кластера OpenVMS. Они широко обсуждают вопросы расстояния.
Некоторые моменты, которые следует учитывать при активном / резервном резервном копировании, виртуальная машина не обязательно является плохим выбором. Если диски для виртуальной машины находятся в сети SAN, вы должны увидеть довольно хорошую производительность.
Синхронное зеркальное отображение на большие расстояния - вот что меня больше беспокоит. Это не должно повлиять на чтение, но каждая запись должна ждать готовности удаленной фиксации перед возвратом.
Я также должен добавить - хотя документация OpenVMS много говорит об OpenVMS в частности, проблемы с задержкой применимы к любому типу приложений зеркалирования или кластеризации. Выполнение «математических расчетов» относительно задержки скорости света для расстояния вашего соединения может очень пролить свет на задержку и отзывчивость на больших расстояниях.
.gif){kind=link}