Балансировка нагрузки на основе близости

Question

Я работаю над проектом, у нас есть число (5 на данный момент) серверов, распространяющихся по всему миру. Клиенты подключаются к одному из этих серверов через централизованный брокер. Мы знаем страну происхождения клиента, но ничего больше. У нас есть полный контроль над серверами, поэтому мы можем иметь всю необходимую нам информацию. Мы не контролируем клиентов, они должны подключиться через этого брокера, как в соответствии со стандартом.

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

Первой мыслью, которая пришла в голову, является pinging клиент с каждого сервера, но у нас нет ip, только в стране.

Другая идея, которую мы имели, - это ping корневого узла в каждой стране с каждого сервера. Проблема заключается в поиске корневого узла в каждой стране.

Вы знаете, как рассчитать/найти близость между «странами»? Есть ли у вас какие-либо идеи или идеи о том, как решить эту проблему по-другому?

Answer 1

Я думаю, что вам нужен термин «балансировка географической нагрузки». Большинство основных поставщиков балансировки нагрузки имеют здесь решение - ваш брокер может использовать их.

Googling geographic load balancing получает полезные результаты.

Answer 2

Это сложно, больше, чем многие представьте, но я чувствую, что есть ответ CORRECT.

Конечно наивные (но прикольно) решение проверки IP клиента, это хорошее начало, но и в «реальном мире» геолокации не все ...

Вы просто просили «с низкой задержкой», что означает, что вы должны сделать ping между серверами и клиентами и назначить соответственно. Очень хороший пример этой проблемы, которая часто меня затрагивает лично, заключается в том, что я работаю в Японии, а сервер говорит, что Тайвань много раз подходит для Сервера в США для меня. BUT, латентность между Японией и США во много раз меньше (лучший ответ), чем с Тайванем, потому что кабели и маршрутизаторы и что-то-вы, которые соединяют Япония-Тайвань не так хороши, как между Япония -USA. Поэтому, если вы связали меня с Тайванем, потому что вы считаете, что мой IP-адрес ближе, вы будете делать мне очень большое неудобство. Помимо того, что ping и фактический небольшой тест при запуске легче сделать, чем поддерживать постоянную обновленную базу данных Geolocation

Answer 3

У Пола есть необходимость в балансировке географической нагрузки - но я добавлю, что ваш лучший выбор, если это вообще вариант, это найти кого-то, кто специализируется на нем и бросать деньги на них. В классе проблем есть много труднее надежно решить, чем оно появляется впервые.

Answer 4

Пинг их и выбор одного с наименьшей латентностью звучит хорошо, но у меня такое чувство, что оно не будет масштабироваться (что происходит, когда у вас 100 или 1000?) - так, может быть, другое решение лучше? Есть множество поставщиков там с системами, которые делают именно это; DNS anycast также широко используется.

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

Также вы, вероятно, захотите каким-то образом добавить к ним весы в конечном счете, когда объемы трафика очень высоки.

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

Answer 5

Pinging не работает. Большинство клиентов будут за шлюзом и/или брандмауэром, а ваши пакеты ping не пройдут. Genehack сказал это лучше всего. Вам нужна балансировка нагрузки на сервер, и использование только географического подхода может быть не лучшим способом всегда идти по этому пути. Лучше бросать деньги тем, кто специализируется на предоставлении решений SLB.

Answer 6

Хорошо, так что несколько быстрых мыслей. Я был основателем Digital Envoy - они занимаются географическим интеллектом ИС. Я покинул компанию несколько лет назад, но около 6 лет назад мы built a joint product с Coyote Point Systems, который выполнял именно эту функциональность - балансировку нагрузки на географической основе. Несомненно, есть крайние случаи (пример Тайваня/Китая, упомянутый в этой теме), которые могут не работать автоматически, но продукт позволил пользователю определить, куда будет идти трафик страны. Поэтому, если вы решили, что Тайвань лучше всего будет подан из США, это будет так продвинуто.

К сожалению, спрос на решение был не таким большим, как мы надеялись, и продукт, я считаю, был прекращен. Я бы предложил contacting Coyote Point и посмотреть, могут ли они предоставить вам эквивалентное решение. Если нет, я думаю, у них будут некоторые идеи о том, как делать то, что вы хотите сделать.

Другой вариант, в зависимости от того, что вам нужно обслуживать, - использовать что-то вроде службы CloudFront от Amazon. Конечно, если вам нужны клиенты для подключения к приложению, а не к статическим файлам, это не сработает для вас.

BTW, full disclosure - Я не только основатель Digital Envoy, но и сейчас я выступаю на борту Coyote Point.

Answer 7

Лучшее решение для этого называется BGP anycast (link to a presentation). Это краеугольный камень всех современных CDN.

С BGP Anycast, несколько различных серверов разбросаны по всему миру, и объявили в Интернет с помощью протокола BGP с использованием же IP. Затем Интернет делает магию - как обычно, сеть маршрутизирует трафик на этот тот же IP по кратчайшему пути, по существу выбирая ближайший сервер (с точки зрения топологии сети) для каждого пользователя.

К сожалению, вы не можете просто анонсировать что-либо через BGP самостоятельно - только крупные сети (обычно датацентры) могут это сделать. Но доступные доступные решения доступны, большинство из которых основаны на DNS   anycast (то есть, разрешая на другой IP-адрес веб-сервера на основе местоположения клиента) - это не идеально, но достаточно во многих случаях (примеры: dnsmadeeasy, Route 53, edgedirector и практически каждый дешевый CDN - cloudflare, maxcdn, cloudfront и т. д.). Существуют также решения, которые выполняют настоящий BGP anycast, т. Е. Фактически обслуживают HTTP-трафик через anycast (например, cachefly) или позволяют вам это делать (например, hostvirtual - не дешево). This также может быть интересным.