На данный момент я хотел бы объединить свой ведомственный SQL Server в один большой экземпляр SQL Server 2008, распределенный на двух серверах (по причине избыточности).
Как / как лучше всего подойти к этому? через функции кластеризации, доставки журналов или VMware (гипервизор)?
Примечание: этот сервер БД не может выйти из строя, поскольку на нем размещается БД VCenter, а также база данных мониторинга сервера.
SQL Server распределен по нескольким меньшим серверам 3-4 SQL Server 2000 и 2005 с общим количеством 70 БД на этих серверах, то что я хотел бы сделать / построить, так это перенести их все в SQL Server 2008, в котором я должен сделать он избыточен, так что если один сервер вышел из строя по какой-либо причине, другой экземпляр может сразу же его забрать.
поэтому из нескольких меньших SQL-серверов я хочу объединить их все в один более мощный SQL Server 2008 x64. но пока не знаю, какая технология подходит для этого и возможно ли это в SQL Server 2008 Standard.
Мы будем очень благодарны за любые предложения и комментарии.
TomTom сказал, что это правильно, но позвольте мне остановиться на нескольких ключевых моментах:
Доставка журналов отлично подходит для аварийного восстановления, но не для актуальных данных. Ваши данные всегда старый, скажем, от 15 минут до 1 часа или даже больше, в зависимости от ваших настроек. Повторное подключение не бесшовные. Вам необходимо переконфигурировать ваше приложение, чтобы оно указывало на новую систему. Кроме того, вторая база данных не в сети, обычно она находится в режиме восстановления (для применения журналов), поэтому вам необходимо вывести ее из режима восстановления, чтобы использовать ее. Вот почему он обычно используется только для аварийного восстановления.
Кластеризация - это не то, что вам нужно, когда вы подключены к любой латентность вообще. Он обеспечивает высокодоступный интерфейс SQL, но не делает ваши данные высокодоступными, если ваша сеть SAN не может сделать это за вас. Я бы никогда не попытался создать кластер между DC.
Зеркальное отображение. В этом случае зеркальное отображение - ваш друг. Зеркальное отображение имеет два основных режима: синхронный или A-синхронный. Общее для обоих режимов: каждый сервер SQL имеет свою собственную локальную копию базы данных, но только один сервер SQL может «владеть» ею. Другими словами, даже если у вас три сервера SQL, фактически используется только один из них. Все остальные находятся в режиме ожидания, ожидая активации.
В синхронном режиме, когда получена транзакция записи, она выполняется всеми серверами SQL одновременно, и следующая транзакция не обрабатывается до тех пор, пока каждый сервер SQL не сообщит, что он зафиксировал транзакцию. Это гарантирует, что каждый сервер SQL имеет полностью актуальные данные. Это отлично подходит для высокоскоростных ссылок с малой задержкой, но не так хорошо для ссылок с большой задержкой, поскольку эффективно замедлит вашу базу данных до скорости самого медленного партнера.
В асинхронном режиме SQL-сервер выполняет не дождитесь, пока все другие партнеры SQL зафиксируют транзакцию. Он просто фиксирует его локально и продолжает работу. Тогда каждый другой SQL-сервер может отставать на несколько транзакций, особенно если ссылки между ними сильно загружены. Это означает, что вы получаете доступ к активной БД на полной скорости, но рискуете потерять часть данных в случае аварийного переключения. Кроме того, этот режим доступен только в версии SQL Enterprise.
VMWare HA. Ну это целая банка червей. Это хорошо, но, опять же, вам нужно использовать один и тот же SAN, чтобы он работал. Или вы про VMWare FT (отказоустойчивость)? Если да, то я предлагаю сейчас забыть о FT для SQL-сервера. FT хорош в теории, и я даже использую его на одной виртуальной машине, но для большинства развертываний жертвы, которые вам нужно принести, слишком велики. Кроме того, поскольку виртуальные машины синхронизированы друг с другом, проблемы с пропускной способностью убивают производительность.
Чтобы управлять возможностью автоматического переключения при отказе, Clustering предоставляет вам виртуальный экземпляр, к которому вы подключаетесь, и все делается незаметно для пользователя. Для зеркалирования вы можете легко добиться этого с помощью роли балансировки сетевой нагрузки, работающей на :1433 так что, когда SQL-сервер отключается от сети, виртуальный экземпляр переключает другие узлы. В качестве альтернативы, в зависимости от поддержки вашего приложения, вы можете указать альтернативные зеркальные серверы в строке подключения SQL.
Возможно, вас заинтересует ответ, который я получил на свой вопрос, SQL Server 2008 R2 100% доступность.
через функции кластеризации, доставки журналов или VMware (гипервизор)?
Нет нет нет.
ЗЕРКАЛЬНОЕ ЗЕРКАЛО, 3 сервера (один может быть маленький бесплатный, просто решаем, какой продолжает работать активным).
Доставка журналов происходит медленно / с задержкой, кластеризация / VMware оставляет одну базу данных слабым местом, которое все еще может быть повреждено.