Здравствуйте.
Сейчас прохожу "курс молодого бойца", а точнее учусь на инженера обеспечения доступности.
Только познаю этот мир, поэтому могу задавать такие, наверное, простые вопросы.
Но все-таки, подскажите, пожалуйста, как снизить к минимуму точки отказа?
Предположим, на примере мэил почты. Как у них работает почта даже при падении ДЦ?
Нам дали такой юзеркес: 3 сервера, надо настроить сервис так, чтобы аптайм близился к 100%
В голове промелькнула мысль: 1 - балансировщик, 2,3 - веб ну и т.п.
Но в данном случае как раз балансировщик и есть точка отказа.
Поэтому возник вопрос - а как в "больших" компаниях с этим "борются?" или как сделать так, чтобы этот балансировщик не стал точкой отказа?
Два балансировщика с одинаковыми адресами (по паре в кластере, итого четыре), каждый из которых расположен в разных субъектах страны, каждый балансировщик подключен двумя ногами к разным маршрутизаторам по EBGP. Бэки балансировщиков в постоянной синхронизации (heartbeat). Добавляем резерв по виртуализации (vmotion + fault tolerance), по питанию (два независимых ввода + ИБП + ДГУ). Статистически измеряем недоступность + время восстановление + длительность профилактических работ и масштабируем решение по вышеприведенной схеме, дотягиваем доступность до нужного уровня)
У нас некоторые узлы, где есть риск политических волнений в транзитных странах, ещё по двум спутниковым каналам включены.
Поэтому возник вопрос - а как в "больших" компаниях с этим "борются?"
Обычно никак или кое-как.
Если по инженерному, то путём дублирования иногда многократного (на самолётах гидравлика управления может иметь четырёхкратное дублирование).
В больших и взрослых компаниях на входе обычно стоит аппаратный стэкированный сетевой балансировщик, который раскидывает нагрузку по кластерам.
ну под "большими" компаниями я имел в виду MRG, Yandex, Google
ведь именно они должны иметь аптайм шесть девяток, а то простой в минуту поисковика -- громадные потери.
именно у них так сделано?
на входе обычно стоит аппаратный стэкированный сетевой балансировщик, который раскидывает нагрузку по кластерам
Можно сделать балансировщик на уровне DNS.
А вы , как я понял, подразумеваете туннель (прокси).
P.S.
Как вариант Failover IP и резервный баланщировщик.
А решение на основе DNS в принципе понятно, и работоспособно. Из нашего опыта эксплуатации и выплыли все эти отрицательные стороны. К тому же, вывод узла на профилактику чертовски сложен: приходится ждать, пока протухнут кэши на всех устройствах по пути к пользователю (кстати, оказывается, огромное количество домашних роутеров напрочь игнорирует TTL в DNS-записях и хранят кэш до пропадания питания). А уж что будет, если узел вдруг аварийно отключится — так вообще страшно подумать! И ещё одна вещь: очень непросто понять, с которого узла абонент обслуживается, когда у него проблема. Ведь это зависит от нескольких факторов: и в каком регионе он находится, и какой DNS он использует. В общем, очень много неоднозначностей.
Илья Родионов, Ставьте 10-ть. Все упирается в деньги. Поставьте 3 балансироващика. А он веса стоек пол может провалиться, вы его укрепили? А металом обшили чтобы пожара не было? А если завтра конец света, зачем вообще что-то начинать делать?
Тупой вопрос, камрад. Риски есть всегда.
Средний
