Назад | Перейти на главную страницу

Когда вы исчерпываете соединение 1 Гбит / с с вашим основным хапрокси, как вы масштабируете?

Если вы исчерпаете свое общедоступное сетевое соединение (скажем, 1 Гбит / с) с вашим haproxy-сервером, который проксирует запросы к вашим внутренним серверам, какие варианты у вас есть для его масштабирования?

Поскольку весь трафик запросов проходит через haproxy, как вы можете масштабировать эту настройку, если на вашем порту не осталось полосы пропускания?

Добавляешь еще один порт.

Допустим, ваша существующая сеть выглядит как один общедоступный IP-адрес перед одним блоком HAProxy перед N внутренними серверами. Вы используете (или еще лучше приближаетесь к скорости 1 Гбит / с) пропускную способность, но ваши внутренние серверы по-прежнему работают с запасными ресурсами.

Следующим шагом является получение второго общедоступного IP-адреса и еще одной машины HAProxy перед вашим кластером. Добавь немного Глобальная балансировка нагрузки на сервер вперед, чтобы отправлять трафик настраиваемым способом на каждый из ваших двух серверов HAProxy.

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

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

Вы можете разделить нагрузку между ними несколькими способами:

  1. Циклический перебор DNS. Это включает в себя просто добавление дополнительных A записи в существующее имя DNS, и мы надеемся, что нагрузка запроса должна быть разделена между членами A запись.
  2. Выборочный ответ DNS. Отвечает на разные DNS-запросы с разными ответами в зависимости от критериев - он может просто обеспечить циклическое распределение или, если ваше приложение может быть эффективно масштабировано для новых местоположений, может отвечать на запросы с помощью ближайшего доступного экземпляра приложения для данного клиента (DNS с географической привязкой).
  3. BGP Anycast. Обычно считается «не очень хорошей идеей» для сеансовой связи, поскольку изменения топологии могут прервать сеансы TCP, это был бы еще один метод проталкивания трафика к развертыванию приложения, которое близко к пользователю с точки зрения топологии Интернета.