Мы ищем Debian Squeeze, многосайтовое решение с открытым исходным кодом «wan fail over» (извиняюсь, если есть сообщение об этом - не видел его). Ключ к мультисайту ....
В контексте малого офиса мы хотим разместить два сервера на двух разных сайтах. У каждого сервера будет собственный статический IP-адрес Public WAN.
Например, Site1: 24.xxx.xxx.xxx и Site2: 52.xxx.xxx.xxx.
Мы планируем использовать DRDB, кардиостимулятор и corosycn, чтобы синхронизировать два блока.
В: есть ли способ, если соединение на первом сайте выйдет из строя, и произойдет ли немедленное переключение на второй сайт?
Примеры кардиостимуляторов, которые мы видели, похоже, настроены для одного сайта (возможно, мы не понимали, что примеры были для нескольких сайтов).
Для этого нужен VIP? Если бы у нас был 3-й сервер на 3-м сайте (например, облачный сервер) с общедоступным статическим IP-адресом WAN и мы использовали бы его для VIP, были бы мы на правильном пути? То есть весь трафик направляется на этот 3-й сервер, который направляет его на общедоступный IP-адрес Site1, и если Site1 выходит из строя, этот 3-й сервер направляет весь трафик на Site2?
Спасибо!
Отказоустойчивость DNS
DNS
/ \
SiteA SiteB
Большинство TTL аварийного переключения DNS будут установлены на 30 секунд, что дает возможность примерно 60 секунд простоя для IP-адреса сайта, чтобы перестать рекламироваться клиентам после того времени, которое требуется вашей проверке службы, чтобы пометить сайт как «плохой». Большинство кэшей DNS подчиняются TTL, некоторые - нет. Некоторые клиенты также могут кэшировать IP-адреса (java!).
Балансировщик нагрузки
LB
/ \
SiteA SiteB
Вариант «VIP», о котором вы упомянули в своем сообщении об одном балансировщике облачной нагрузки (vip), действительно позволяет вам быстрее переключать сайты, поскольку вы можете перемещать трафик с сайта на сайт, как только услуга помечается как плохая. Тем не менее, это добавляет единую точку отказа.
Балансировщики нагрузки + отказоустойчивость DNS
DNS
/ \
LB LB
| \ / |
| X |
| / \ |
SiteA SiteB
Если у вас есть два облачных балансировщика нагрузки (желательно на разных сайтах или у разных поставщиков) и перед ними работает аварийное переключение DNS, вы можете перемещать клиентов с SiteX на SiteN, как только обнаруживается сбой, а также быть защищенными на случай непредвиденной нагрузки. балансировщик выходит из строя, что должно происходить намного реже, чем услуга виртуального рабочего стола, размещенная по сетевым ссылкам вашего офиса.
Есть и другие способы достижения отказоустойчивости на сетевом уровне с помощью маршрутизации BGP и BGP anycast, если вы управляете своими собственными диапазонами IP и используете маршрутизаторы BGP. Это звучит немного выше того, к чему вы стремитесь?
Для того, чтобы любой отказоустойчивый сработал, вам необходима тщательная проверка службы виртуального рабочего стола, чтобы подтвердить, что сайт действительно работает. Я не уверен, насколько далеко вы можете проверить виртуальный рабочий стол помимо аутентификации, если только вы не напишете действительно отличный клиент. Возможно, вы также можете предоставить системные показатели своих сайтов, которые могут помочь указать на то, что сайт «испортился». Вероятно, это могло произойти из-за кластеризации, которую вы выполняете внутри сайта, так как она должна иметь хорошее представление о статусе службы.
Кроме того, при наличии нескольких сайтов необходимо учитывать то, к чему в конечном итоге подключаются клиенты. Могут ли они переключаться туда и обратно так часто, как им хочется. Будет лучше, если они останутся на одном пути. Активный / пассивный вариант лучше? Географическое положение - важный фактор? Все они очень специфичны для того, что вы реализуете. Всегда проверяйте то, что вы считаете лучшим, и всегда проверяйте все возможные сценарии сбоя.