Вопрос

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

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

Первая идея, которая пришла в голову — пинговать клиента с каждого сервера, но у нас нет айпи, только страна.

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

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

Это было полезно?

Решение

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

Поиск в Google географической балансировки нагрузки дает полезную информацию смотреть результаты.

Другие советы

Это сложно, больше, чем многие себе представляют, но я чувствую, что есть ПРАВИЛЬНЫЙ ответ.

Конечно, наивное (но крутое) решение заключается в проверке IP-адреса клиента, это хорошее начало, но в «реальном мире». Геолокация - это еще не все ...

Вы только что запросили " низкую задержку " ;, что означает, что вы должны выполнить ping между серверами и клиентами и назначить их соответствующим образом. Очень хороший пример этой проблемы, которая много раз затрагивала меня лично, - это то, что я работаю в Японии, и сервер говорит, что на Тайване для меня намного ближе к серверу в США. НО , задержка между Японией и США во много раз меньше (лучший ответ), чем с Тайванем, потому что кабели и маршрутизаторы и что-у-вас соединяют Япония-Тайвань Не такие хорошие, как между Японией и США . Поэтому, если бы вы связали меня с Тайванем, потому что вы полагаете, что мой IP-адрес ближе, вы бы сделали очень большое неудобство там. Кроме того, пинг и небольшой тест при запуске проще сделать, чем поддерживать постоянно обновляемую базу данных геолокации

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

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

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

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

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

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

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

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

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

Хорошо, несколько быстрых мыслей.Я был основателем Цифровой посланник - они занимаются географической IP-разведкой.Я покинул компанию несколько лет назад, но около 6 лет назад мы создали совместный продукт с Системы Койот-Пойнт который выполнял именно эту функцию - балансировку нагрузки по географическому принципу.Конечно, есть крайние случаи (пример Тайваня/Китая, упомянутый в этой теме), которые могут не работать автоматически, но продукт позволяет пользователю определять, куда будет идти трафик страны.Так что, если бы вы решили, что Тайваню лучше всего обслуживаться за пределами США, его бы подтолкнули именно так.

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

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

КСТАТИ, полное раскрытие - Я не только основатель Digital Envoy, но и в настоящее время работаю в совете директоров Coyote Point.

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top