Я обсуждал здесь сценарий, который использует наша компания, и хотел бы, если возможно, внести свой вклад.
У нас есть основной URL-адрес сайта, назовите его "http://www.site.com". В какой-то момент во время своего создания было решено, что нагрузка на сайт будет сбалансирована активным / активным в двух физических центрах обработки данных. Это было достигнуто в то время, когда сетевое устройство возвращало перенаправление 301 на любой из"https://site1.site.com" или "https://site2.site.com". Очевидно, что это не очень хорошо работает с поисковыми системами, так как при поиске сайта вы получаете результаты перенаправления для конкретного сайта во время сканирования, когда маркетинг хочет, чтобы основной сайт www.site.com всегда показать. Мне любопытно, как правильно реализовать такое решение?
«Это было достигнуто в то время, когда сетевое устройство возвращало 301 редирект ..»
Это, друг мой, не обеспечивает балансировку нагрузки между двумя центрами обработки данных. Это одно устройство, которое сидит на одном из них и перенаправляет клиентов.
Вам следует обратить внимание на использование одного (или двух для локального аварийного переключения) балансировщиков нагрузки на каждом сайте, предпочтительно что-то, что может обновлять DNS и иметь логику GeoIP (очень удобно, когда вы находитесь на больших географических расстояниях).
Я лично использую балансировщики нагрузки KEMP и очень рекомендую их: http://www.kemptechnologies.com/uk/server-load-balancing-appliances/geo-loadmaster/glm-overview.html
А как насчет использования разделения нагрузки с DNS?
www.site.com 1.1.1.1
www.site.com 1.1.1.2
www.site.com 1.1.1.3
"Хороший" способ выполнения «Глобальной балансировки нагрузки сервера» (GSLB) - это несколько центров обработки данных (DC), в каждом из которых граничные маршрутизаторы объявляют один и тот же диапазон IP-адресов, используя BGP для выбора кратчайшего пути - иначе Anycast.
Более дешевая версия часто использует идентичные устройства балансировки нагрузки (LB) с надстройкой GSLB в каждом месте, где LB обмениваются тактовым импульсом, и отработка отказа с помощью DNS-трюков (за неимением лучшего слова).
Я со всем уважением предлагаю вам отказаться от требования о нескольких DC или, по крайней мере, обеспечить финансирование для серьезных усилий. Хорошие развертывания с несколькими ЦОД нелегко настроить и требуют крупных предварительных вложений в оборудование (маршрутизаторы) и опыт. Репликация баз данных и изменение наборов данных обычно очень сложно.
Одним из возможных обходных путей может быть Amazon Балансировщик эластичной нагрузки (ELB) вместе с переходом на Amazon EC2. В ELB есть некоторые положения для охвата нескольких зон доступности Amazon, а EC2 + ELB дешевле по сравнению с аварийным переключением нескольких центров обработки данных своими руками.
Если у вас есть деньги, я бы посмотрел на реализацию чего-то вроде Cisco GSS или F5 GTM на обоих сайтах и делегирование им DNS.
По сути, он работает, указывая вашу запись A для www.site.com на GNS / GTM, которые вы, в свою очередь, настроили с помощью IP-адресов ваших веб-серверов или их VIP-адресов, а также их местоположения. Когда клиент выполняет поиск в DNS для www.site.com, GSS / GTM возвращает IP-адрес соответствующего сервера / VIP.
Балансировка нагрузки может выполняться на основе циклического перебора, по географическому положению, по показателям производительности или по нагрузке, или с помощью активного центра обработки данных и центра обработки данных аварийного восстановления - в основном все те же принципы, которые применяются к балансировке нагрузки.