Основы балансировки.

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

Поставь перед ними еще один балансировщик!

На самом деле к автоматическому рестарту балансера можно добавить еще управление адресами (например на pacemaker с corosync)

Попробуй в DNS несколько ip на одну A запись.

А в чем тогда смысл балансировщика с системой roundrobin если все это можно сделать с помощью записей в dns?

Клиент обычно долбится в первый адрес, полученный DNS

Ну вот поэтому коммент выше я написал. Как сомнение в правильности добавления лишних имен.

Каждая ступень в каскаде даёт свои плюшки. Можно дать два ip, на которых буду слушать два балансировщика, за которыми будет всё остальное. Я не знаю про управление балансировкой по DNS, возможно ли. Но оно может дать базовую устойчивость твоим настоящим балансировщикам.

Клиент обычно долбится в первый адрес, полученный DNS

root@tarh-core:~# ping test
PING test.tarh.local (192.168.78.222) 56(84) bytes of data.
^C
--- test.tarh.local ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 999ms

root@tarh-core:~# ping test
PING test.tarh.local (192.168.78.221) 56(84) bytes of data.
^C
--- test.tarh.local ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 999ms

root@tarh-core:~# ping test
PING test.tarh.local (192.168.78.222) 56(84) bytes of data.
^C
--- test.tarh.local ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1008ms

root@tarh-core:~# ping test
PING test.tarh.local (192.168.78.221) 56(84) bytes of data.
^C
--- test.tarh.local ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2009ms

root@tarh-core:~# ping test
PING test.tarh.local (192.168.78.222) 56(84) bytes of data.
^C
--- test.tarh.local ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1008ms

этого примера достаточно?

Если недостаточно,

root@tarh-core:~# ping test
PING test.tarh.local (192.168.78.221) 56(84) bytes of data.
^C
--- test.tarh.local ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

root@tarh-core:~# ping test
PING test.tarh.local (192.168.78.222) 56(84) bytes of data.
^C
--- test.tarh.local ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

root@tarh-core:~# ping test
PING test.tarh.local (192.168.78.223) 56(84) bytes of data.
^C
--- test.tarh.local ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

root@tarh-core:~# ping test
PING test.tarh.local (192.168.78.221) 56(84) bytes of data.
^C
--- test.tarh.local ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

root@tarh-core:~# ping test
PING test.tarh.local (192.168.78.222) 56(84) bytes of data.
^C
--- test.tarh.local ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

Выборка из одной программы/системы не репрезентативна.

Кроме того, использования CNAME позволяет избежать ожидания истечения TTL записей в кешах DNS-серверов. У меня управление адресами через CNAME давало мгновенный результат. Грубо говоря, у тебя есть два имени с групповыми ip и тебе надо быстро между ними переключаться. Тогда CNAME - это твой выбор. Ввёл в эксплуатацию новую A-запись, перевёл на неё CNAME, вывел из работы старую A-запись.

Ок.

ya.ru попингуй

root@playground2:~# ping ya.ru
PING ya.ru (93.158.134.3) 56(84) bytes of data.
64 bytes from www.yandex.ru (93.158.134.3): icmp_seq=1 ttl=52 time=3.70 ms
^C
--- ya.ru ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 3.708/3.708/3.708/0.000 ms
root@playground2:~# ping ya.ru
PING ya.ru (213.180.193.3) 56(84) bytes of data.
64 bytes from www.yandex.ru (213.180.193.3): icmp_seq=1 ttl=52 time=3.46 ms
^C
--- ya.ru ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 3.468/3.468/3.468/0.000 ms
root@playground2:~# ping ya.ru
PING ya.ru (213.180.204.3) 56(84) bytes of data.
64 bytes from www.yandex.ru (213.180.204.3): icmp_seq=1 ttl=52 time=4.65 ms
^C
--- ya.ru ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 4.658/4.658/4.658/0.000 ms

dig ya.ru
...
;; ANSWER SECTION:
ya.ru.			3649	IN	A	93.158.134.3
ya.ru.			3649	IN	A	213.180.193.3
ya.ru.			3649	IN	A	213.180.204.3

Нормально, три точки приёма. Больше им пока не нужно. Здесь, по крайней мере. В Европе будут, скорее всего, другие ответы.

балансировка повышает отказоустойчивость

Балансировка снижает нагрузку. Отказоустойчивость повышает резервирование. Это касается в т.ч. и балансировщиков.

В Европе будут, скорее всего, другие ответы.

Хм. В Амстердаме ip те же. Только почему-то ответ менее 2ms. Странно. Оттуда до московских машин по 40-60ms обычно. Наверное, я чего-то не знаю. ip адреса те же, что и в РФ, но ответ до них такой же, как и в РФ. Надо будет выяснить как они это сделали.

Во! У гугла цельных 11 точек.

;; ANSWER SECTION:
google.com.		63	IN	A	173.194.32.142
google.com.		63	IN	A	173.194.32.128
google.com.		63	IN	A	173.194.32.129
google.com.		63	IN	A	173.194.32.130
google.com.		63	IN	A	173.194.32.131
google.com.		63	IN	A	173.194.32.132
google.com.		63	IN	A	173.194.32.133
google.com.		63	IN	A	173.194.32.134
google.com.		63	IN	A	173.194.32.135
google.com.		63	IN	A	173.194.32.136
google.com.		63	IN	A	173.194.32.137

anycast

Ага!! В Амстердаме dig google.com дал совсем другой ответ!

;; ANSWER SECTION:
google.com.		251	IN	A	74.125.136.102
google.com.		251	IN	A	74.125.136.113
google.com.		251	IN	A	74.125.136.138
google.com.		251	IN	A	74.125.136.139
google.com.		251	IN	A	74.125.136.100
google.com.		251	IN	A	74.125.136.101

В данном случае nginx выполняет роль Load Balancing. Теперь осталось загуглить про организацию высоконадежного HA (High Availability) кластера

Да, дружище, совсем нерепрезентативная выборка. Никто, ваще никто в мире, этим не пользуется. Бесполезная и ненужная фича.

Да-да. Найти этот кластер, взять его в руку крепко-крепко и пойти забивать им гвозди. А мы, пожалуй, просто забьём несколько ip на одну A запись. А вы там забивайте свои гвозди кластерами.

anycast

новое слово, спасибо.

Drawbacks

Although easy to implement, round robin DNS has problematic drawbacks, such as those arising from record caching in the DNS hierarchy itself, as well as client-side address caching and reuse, the combination of which can be difficult to manage. Round robin DNS should not solely be relied upon for service availability. If a service at one of the addresses in the list fails, the DNS will continue to hand out that address and clients will still attempt to reach the inoperable service.

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

Насколько я могу видеть, на практике применяется. Внешне вполне успешно. А про TTL я уже говорил. У меня CNAME решает вопрос. Изменение происходит мгновенно.

Насколько я могу видеть, на практике применяется.

Ты про гугл и яндекс? Зуб даю, у них за этими ip все равно стоят лоад балансеры :)

Браузеры, например, кешируют DNS, и даже если ты сменишь свои записи, у конкретного клиента, который уже открыл сайт, будут проблемы.

Зуб даю, у них за этими ip все равно стоят лоад балансеры :)

дружище, прочитай уже тред Основы балансировки. (комментарий)
естественно, там балансеры. Такой финт с ДНС нужен для устойчивости, а не для балансировки.

тыц

Такой финт с ДНС нужен для устойчивости, а не для балансировки.

Нет, их сервисы за этими ip не падают, что позволяет избежать проблемы, о которой я писал. Так что, мне кажется, у них это как раз для балансировки траффика и уж на совсем аварийный случай, если отрубится целый датацентр.

Браузер не будет пробовать все IP-шники пока не найдёт рабочий. Он возьмёт первый попавшийся и отправит туда запрос. Если запрос не сработал — он покажет юзеру ошибку и юзер уйдёт с твоего сайта.

Интересная мысль.

Браузер не будет пробовать все IP-шники пока не найдёт рабочий. Он возьмёт первый попавшийся и отправит туда запрос. Если запрос не сработал — он покажет юзеру ошибку и юзер уйдёт с твоего сайта.

Я не знаю, как браузер резолвит имя в адрес. Если поведение резолвера в браузере будет аналогично поведению утилиты ping, то обновление страницы должно, по идее, перекинуть тебя на другой адрес. Я бы сделал именно так.

browser cache
^this

Точнее, я бы сделал условие. Если соединиться на полученный адрес не удалось, то попробовать получить другой ip с этого же имени и попробовать его.

А следующее обновление перекинуть на прежний адрес :) Это не отказоустойчивость, это именно распределение нагрузки. Отказоустойчивость это когда пользователь не замечает проблем при отказе одного из компонентов системы.

В моей системе, где я пользую cname, браузеров нет.

Отказоустойчивость это когда пользователь не замечает проблем при отказе одного из компонентов системы.

Это понятно. Поднялся вопрос об устойчивости самого балансера. В дереве сервисов только DNS, пожалуй, ближе к корню.

Я знаю, что для обеспечения отказоустойчивости лоад балансера используется схема с плавающим ip адресом между двух лоад балансеров. Но сам такое не настраивал, так что ТСу ничего рассказать не могу.

нельзя с помощью dns. как ты будешь определять что сервер сдох? ну вернее не ты а клиент. он просто выберет адрес и будет туда ломиться. а там никого. плохо.

так он случайно выбирает ведь. ну и что, выберет он случайно недоступный сервер и будет к нему обращаться. что ты выиграл то?

Ты имеешь ввиду один из видов аггрегации. Один ip на несколько железок в общем линке. От перерубленного экскаватором канала это не поможет. Идея делать супер-обеспеченный центр с резервированием по всем направлениям обычно применяется в датацентрах. Дорого это. Есть другая идея - распылить множество мелких штук по Сети. Как это делает Яндекс, например. Есть достоверная инфа о маленьких коробочках, которые стоят по квартирам. Стоят они там со своей выделенной линией подкючения к Сети. За небольшую денежку эти коробочки там живут. Что конкретно эти коробочки делают - я не знаю.

что ты выиграл то?

даже при условии отсутствия механизма проверок в самом браузере, я получаю вероятность попадания клиента на работающий сервис. Помнишь, как считается математическое ожидание? При 3 точках в сумме и 1 выпавшей мы получаем 2/3 успеха. Мало?

На секунду мне показалось, что ты сказал, что яндекс размещает своё оборудование в квартирах

Тебе показалось.

Несколько IP адресов в DNS у таких монстров как гугль и яндекс используется не (только) для балансировки, а для отказоустойчивости на уровне провайдера (из этих трёх, например, два идут через комкор, а один через транстелеком).

Для отказоустойчивости гораздо проще юзать какую-нибудь адскую кластеризующуюяся коробку-лоадбалансер, которая может прожёвывать овердофига гигабит траффика, вроде F5 или ещё более крутых. Либо, для бедных, сервера со всякими keepalived/pacemaker которые гоняют один IP между серверами.

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

ну дык

Вообще, я ведь могу ситуацию с DNS воспроизвести. Надо будет попробовать.

Хром точно пробует все A записи и только если ни одна не доступна - выдаёт ошибку. За другие не скажу, но Лиса, думаю, тоже так делает.

Даже если учесть что можно создать вторую ноду балансировщика, то как перенаправлять на него запросы в автоматическом режиме?

две А запиcи в DNS