Назад | Перейти на главную страницу

Веб-сайт и база данных размещены в нескольких центрах обработки данных

Недавно у нашего хостинг-провайдера произошел серьезный сбой в работе центра обработки данных. Они потеряли оптоволоконное соединение, что привело к отключению сети на 9 часов, когда большинство наших клиентов не смогли подключиться.

Это заставило нас рассмотреть возможность размещения нашего веб-сайта в 2 независимых центрах обработки данных.

Это сайт asp.net с базой данных Sql 2008. Я прочитал несколько статей о циклическом IP, произвольном IP и т. Д.

Для меня это новый ужас, поэтому я совершенно не знаю, с чего начать.

У меня есть вопросы:

  1. Как мы можем разместить базу данных в 2 центрах обработки данных и при этом поддерживать их синхронизацию
  2. Должен ли 1 центр обработки данных выступать в качестве основного?
  3. Я бы хотел, чтобы все пользователи переходили в центр обработки данных 1, но в случае, если 1 недоступен, я бы хотел, чтобы трафик переместился в центр обработки данных 2. Как это можно сделать?

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

Этого добиться очень сложно. Шутки в сторону.

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

С точки зрения любого вещания для этого требуется очень надежная сеть DNS. Есть поставщики DNS, которые могут сделать это за вас.

Для DNS Round Robin / Failover это обычно считается очень плохим методом отработки отказа, однако он может быть «достаточно хорошим», если ваше соглашение об уровне обслуживания с вашими клиентами может это согласовать. Если у вас низкий TTL (скажем, 5-30 минут), вы можете войти и перевернуть свои записи DNS, чтобы они указывали на ваш 2-й центр обработки данных, и тогда большинство ваших клиентов вернутся в сеть через <30 минут (хотя есть много сломанных DNS-кешей, поэтому ваш опыт может отличаться).

Другой вариант - использовать некоторую форму высокой доступности, встроенную в SAN и гипервизор. На ум приходит SRM VMWare. Если ваша SAN может выполнять блочную репликацию iSCSI LUN и у вас есть кластер VMWare с соответствующей лицензией, VMWare может затем загрузить ваш аварийный сайт, когда обнаружит, что основной сайт отключен. Благодаря тому, что vSphere 5 значительно улучшила количество виртуальных ЦП и выделение виртуальных ОЗУ, теперь это возможно даже для больших серверов SQL. Однако это требует огромных вложений в виде долларов и инфраструктуры.