У меня есть 6 экземпляров sql-сервера, которые должны быть высокодоступными, поскольку они размещаются на двух сайтах (один как основной, один как DR). Требуется прозрачное автоматическое переключение при отказе. Большинство из них довольно утомительны и мало работают, два из них широко используются для записи.
Самые загруженные базы данных обрабатывают в среднем 400 000 транзакций в минуту, достигая пика 900 000 и генерируя ~ 10 гигабайт новых данных в день каждая.
Оба сайта одинаковые, на обоих netapps 15k SAS iscsi sans.
В настоящее время у нас есть win server 2003, sql server standard 2005. Зеркальное отображение синхронизации слишком медленное и добавляет 2 мс к каждой транзакции.
Мне удалось убедить клиента заплатить за windows server 2008 и sql server enterprise 2008 с целью возможного наличия отказоустойчивого кластера (с одним узлом в каждом кластере) между двумя сайтами с netapps, выполняющими межсайтовую репликацию.
Как бы вы достигли высокой доступности для двух сайтов с одним сервером на каждом сайте?
Спасибо
Нет ничего прозрачного на 100%. Отказоустойчивая кластеризация связана с простоями во время остановки и запуска на другом узле. Если приложение поддерживает кластер и / или имеет логику повтора, не проблема. Имя экземпляра остается прежним, поэтому на этом уровне кластеризация прозрачна.
Репликация и доставка журналов имеют разные имена серверов (источник / место назначения), поэтому вам нужно использовать какую-то технологию / псевдоним / что угодно, чтобы абстрагироваться от изменения имени и / или иметь возможность изменять конфигурацию приложения (при условии, что они не жестко запрограммировали имена ). Зеркальное отображение базы данных имеет несколько аналогичную историю, но если приложение закодировано для SNAC, вы можете использовать автоматическое переключение при отказе со свидетелем.
DBM / log shipping / repl также требует, чтобы вы синхронизировали объекты, не находящиеся вне базы данных, и убедитесь, что на резервном сервере есть все необходимое для работы (включая логины на уровне экземпляра).
Таким образом, только отказоустойчивый кластер и DBM со свидетелем и высокая безопасность обеспечат автоматическое переключение при отказе. Это не обязательно означает прозрачность.
Не существует абсолютно правильного способа сделать это. Он основан на ваших требованиях (включая общие SLA, RTO и RPO).
Если у вас возникли проблемы с зеркалированием, это может быть связано с вводом-выводом и / или сетью. Возможно, это не имеет ничего общего с SQL. Поэтому, когда вы смотрите на новую архитектуру, убедитесь, что вы оцениваете все уровни решения.
Я предлагаю вам взглянуть на использование свидетеля общего файлового ресурса в сочетании с кластеризацией в Windows Server 2008 (я не могу припомнить, нужен ли вам R2 или нет). Я лично этого не делал, но Прошлым летом я некоторое время смотрел на него.
Если кто-то считает, что у маркетинга и NetApp есть подходящее программное обеспечение, оно должно обеспечить переключение между сайтами. Может ли он обрабатывать эти объемы транзакций, вызывает беспокойство, но ответственность будет лежать на сетевых приложениях и на всем, что их связывает.
Обратите внимание, что «прозрачное автоматическое переключение при отказе» может быть недостижимо без поддержки со стороны самих пользовательских приложений. Если вы уже выполняете зеркалирование, это может не быть проблемой.
Если требуется действительно прозрачное автоматическое переключение при отказе и вы не можете справиться с накладными расходами в 2 мс на транзакцию, лучшим вариантом, вероятно, будет двунаправленная репликация с очень хорошим внешним интерфейсом балансировщика нагрузки (например, F5 Big-IP). Таким образом, оба SQL-сервера доступны в любое время.
Есть много недостатков, связанных с двунаправленной репликацией - изменение схемы может быть сложным, вам придется переделывать свои поля идентификации (разные начальные числа, нечетные / четные приращения), и это не самовосстановление. Вам нужен мониторинг, чтобы знать, когда репликация прекращается, и вам нужна круглосуточная команда, которая будет действовать быстро, когда это произойдет, потому что клиенты не будут счастливы, если они не увидят согласованные данные на двух узлах. Некоторые сбои также могут привести к тому, что данные будут находиться на одном узле, а не на другом. Например, если репликация перестает работать, а затем через 10 минут выходит из строя весь сервер, второй сервер не увидит эти 10 минут данных, пока вы не восстановите первичную резервную копию и не исправите репликацию.