Каковы различия между сетевым и HTTP(s) балансировщиком нагрузки в GCP?
GCP предоставляет два балансировщика нагрузки, а именно сеть и HTTP, где первый работает на уровне 4, а последний - на уровне 7.
Существует также документация, в которой говорится, что даже HTTP-трафик может быть сбалансирован нагрузкой с помощью балансировщика сетевой нагрузки. Это немного сбивает с толку, какой балансировщик нагрузки выбрать для веб-приложения в GCP. Лучше понять различия, прежде чем выбрать один для проекта.
Я хотел бы знать различия между ними на основе рабочего процесса, настройки, на основе региона / зоны, параметров схожести сеанса и многих других.
1 ответ
Балансировщик сетевой нагрузки против HTTP(s) Балансировщик нагрузки
+---------------------+------------------------------------------+------------------------------------------------------+
| Category | Network Load Balancing (NLB) | HTTP(S) Load Balancing (HLB) |
+---------------------+------------------------------------------+------------------------------------------------------+
| 1. Region / | NLB supports only within a region. | HLB supports both within cross-region |
| Cross-Region | Does not support cross-region | load balancing. |
| | load balancing | |
+---------------------+------------------------------------------+------------------------------------------------------+
| 2. Load balancing | NLB is based on IP address, port | HLB is based only on HTTP and HTTPS |
| based on | and protocol type. Any TCP/UDP | protocols. |
| | traffic, even SMTP can be | |
| | load balanced. | |
+---------------------+------------------------------------------+------------------------------------------------------+
| 3. Packet | Packet inspection is possible and | HLB cannot inspect packets. |
| inspection | load balance based on packets | |
+---------------------+------------------------------------------+------------------------------------------------------+
| 4. Instance | No need of creating instance group. | Managed / UnManaged Instance group |
| Group | Target pools need to be created. | is necessary for creating HTTP / HTTPS |
| | Instance can be just tagged to the pool. | load balancer. |
| | Ideal for unmanaged instance group | |
| | where instances are non homogeneous. | |
+---------------------+------------------------------------------+------------------------------------------------------+
| 5. Workflow | Forwarding rules is the starting point. | This is quite complex in HTTP(s) load balancer. |
| | It directs the request to the | Global forwarding rulesroutes direct the request |
| | target pools from which compute | to target HTTP proxy, which in turn checks the |
| | engines will pick the request. | URL map to determine appropriate backend |
| | | services. These services in turn direct the request |
| | Forwarding rules -> target pool | to the instance group. |
| | -> instances | |
| | | |
| | | Global forwarding rules -> Target HTTP proxy -> |
| | | URL map -> Backend Sevices -> instance group |
+---------------------+------------------------------------------+------------------------------------------------------+
| 6. Types of | Basic network load balancer which | 1. Cross-region load balancer uses only one |
| load balancer | directs the request based on IP address, | global IP address and routes the request |
| | port and the protocol within the region. | to the nearest region. |
| | | |
| | | 2. Content-based load balancer is based |
| | | on the URL path. Different path rules need |
| | | different backend services. for eg: /video |
| | | and /static require two separate backend services. |
+---------------------+------------------------------------------+------------------------------------------------------+
| 7. Session affinity | Session affinity can be set, but only | 1. Client IP Affinity: This directs the same |
| | during the creation of target pool. | client ip to same backend instance by |
| | Once it is set, the value | computing hash of the IP. |
| | cannot be changed. | 2. Generated Cookie Affinity: Load balancer stores |
| | | cookie in clients and directs the same client to |
| | | same instance with the help of retrieved cookie. |
+---------------------+------------------------------------------+------------------------------------------------------+
| 8. Health check | Health check is optional, but network | Health can be verified by either using HTTP |
| | load balancing relies on HTTP Health | heath check or HTTPS health check. |
| | checks for determining instance health. | |
+---------------------+------------------------------------------+------------------------------------------------------+
Приведенная выше таблица основана на моей точке зрения. Если что-то не так или если я что-то пропустил, пожалуйста, не стесняйтесь комментировать, и я добавлю это в таблицу.
Вот ссылка на инструкции по настройке балансировщика нагрузки HTTP в GCP.
В целом ниже представлена разница между балансировщиками нагрузки Network и Http.
Балансировщик сетевой нагрузки (уровень 4): это распределение трафика на основе сетевых переменных, таких как IP-адрес и порты назначения. Это уровень 4 (TCP) и ниже и не предназначен для учета чего-либо на уровне приложения, такого как тип контента, данные cookie, настраиваемые заголовки, местоположение пользователя или поведение приложения. Он не зависит от контекста и заботится только об информации сетевого уровня, содержащейся в пакетах, которые он направляет туда-сюда.
Балансировщик нагрузки приложений (уровень 7) Это распределение запросов на основе нескольких переменных, от сетевого уровня до уровня приложения. Он учитывает контекст и может направлять запросы на основе любой отдельной переменной так же легко, как и на комбинации переменных. Нагрузка приложений балансируется на основе их специфического поведения, а не только на основе информации о сервере (операционной системе или уровне виртуализации). Предоставляет возможность маршрутизации трафика HTTP и HTTPS на основе правил, на основе хоста или пути. Как и NLB, каждая цель может быть на разных портах.
Другое различие между ними важно, поскольку балансировка сетевой нагрузки не может гарантировать доступность приложения. Это связано с тем, что он основывает свои решения исключительно на переменных сети и TCP-уровня и вообще не знает о приложении. Обычно подсистема балансировки сетевой нагрузки определяет "доступность" на основе способности сервера отвечать на эхо-запрос ICMP или правильно завершить трехстороннее установление связи TCP. Балансировщик нагрузки приложения идет гораздо глубже и способен определять доступность на основе не только успешного HTTP GET конкретной страницы, но и проверки того, что контент соответствует ожиданиям на основе входных параметров.
Кроме того, я хотел бы отметить, что при выборе правильного балансировщика нагрузки (LB) в GCP необходимо учитывать три основных аспекта:
1) Глобальный против регионального
2) Внешний против внутреннего
3) Тип трафика
Пожалуйста, найдите больше информации на этом графике.