Резервный web сервер

Например в DNS-е поменять запись на IP другого севера.

так, ну так меняться будет долго

Думаю, он имел в виду раунд робин.

Виртуальный IP. См. http://www.keepalived.org/, https://ru.wikipedia.org/wiki/VRRP

ну а толку то с раунда, если выйдет хост из строя половина клиентов зайти не смогу

извините, я почитал, можете пожалуйста по конкретнее

Устанавливаем на обе VPS'ки keepalived (keepalived настраивается очень легко, руководства гуглятся, нет смысла их перепечатывать здесь), выделяем IP-адрес (который и будет основным, т.е. все обращения должны вестись именно по этому ip-адресу), первой VPS'ке в keepalived.conf (повторюсь, руководства по keepalived гуглятся даже на русском) выдаём больший приоритет, чем второй. В итоге, если первая VPS'ка упадёт, трафик будет перенаправлен на вторую (а когда первая VPS'ка вернётся в строй, трафик снова вернётся к ней).

Зато половина сможет. А ты будешь сидеть и чинить. Или ты хотел сидеть на жопе ровно, пока у тебя все рушится?

так если первая vps упадет, упадет и keepalived, как он будет знать что надо перенаправить на другую vps ? (упадет, имеется ввиду пропадет инет)

Ну а теперь, боец, натяни это на сабжевую ситуацию, когда серверы в разных ДЦ, а значит в разных подсетях, да еще и в разных AS походу.

keepalived должен быть установлен на обе VPS. Если первая перестанет пинговаться, будет задействована VPS №2.

ну так все равно round robin надо будет в dns использовать, и запросы будут идти по очереди, сначала на 1 потом на 2, а надо что бы все шли на 1 а на второй шли если 1 недоступен

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

А ты сейчас старательно ведешь аргументированную дискуссию с человеком, которого даже здесь, на ЛОРе, банили за невменяемость уже раз тридцать.

Ах, да. Про то, что возможно иметь несколько A-записей на один хостнейм, ты ведь знаешь и сам.

спасибо за информацию, я не против поставить брокер по середине но собственно что бы это не было проксирование, так конечно можно тупо nginx все это сделать, может все же есть какое то решение ?

я не против поставить брокер

И создать следующую тему - как застраховаться от случая, когда упал брокер, а веб-серверы работают. Бугога.

Я ж дописал - две записи с малым TTL на ДНС-сервере.
Идеальная ситуация: браузер тычется в первый айпишник (первую впс, но она, допустим, упала), не получает ответа и идет тыкаться во второй айпишник.

Работать, полагаю, будет не у всех, но хоть что-то.

веселье)) ну можно поставить 2 брокера а там уж и round robin))

спасибо за совет, видимо это самое простое решение, в крайнем случае так и сделаю

Возьми днс на амазоне или в клоудфларе. И там переключение будет очень быстрое.

можно поставить 2 брокера а там уж и round robin))

2 брокера и два веб-сервера? Тогда брокеры не нужны :) Раз уж зашла речь о амазоне, у них есть elastic ip, который переключается между серверами мгновенно. Но это только для их серверов, а это не самый дешевый вариант.

Для твоей задачи нужно настроить сервер высокой доступности Настрой отказоустойчивый кластер на основе ПО Heartbeat входящие в состав пакета DRBD. http://www.opennet.ru/docs/RUS/ha_cluster/

баланс и резерв - разные вещи. если хочешь резерв - можешь, например, задействовать динамический dns в связке с heartbeat. Типа один сдох - второй выполнил скрипт с запросом на обнову днс. Но против кэша провайдера не слишком поможет. Есть vrrp, но тут от датацентра может зависеть. Да и вообще - это больше сетевая проблема, чем серверная. Если ДЦ адекватен - лучше с ними говорить.

Вообще-то большинство браузеров (все современные браузеры), получив от DNS сервера два IP для домена, сначала попробуют подключиться к первому, а если это не получится то попробуют подключиться ко второму.

Другое дело что это не HA-кластер, а LB-кластер. Т.е. пользовательские запросы будут идти на оба сервера одновременно, что накладывает достаточно высокие требования по синхронизации серверов.

2 брокера и два веб-сервера? Тогда брокеры не нужны :)

Можно совместить брокеры (балансеры) и сами серверы. DNS-ом трафик балансируется на оба сервера, а какой-нибудь nginx на них выбирает бэкэнд исходя из приоритетов.

Конечно половина трафика в таком варианте будет проделывать лишний путь по сети (от клиента до сервера А, от сервера А до сервера Б и обратно), но в описано ситуации перепробега трафика вроде не избежать.

P.S. мысля: сервер не считающий себя основным в данный момент может давать клиенту отлуп. В такое ситуации клиенты умеющие DNS-RR (а это наверное уже все браузеры) будут подключаться к другому IP и в дальшейнем предпочитать работать с ним (на счёт этого не уверен, надо проверять). А когда основной сервер помрёт резервный сможет это задетектировать (про варианты детектирования уже писали выше) и перестать давать отлуп клиентам, тогда клиенты переключатся на него.

Конечно половина клиентов будет тратить какое-то время на ожидание отлупа от резервного сервера и подключение к основному, но по идее это будет небольшое время (немногим больше времени раундтрипа от клиента до резервного сервера)