NHN Cloud provides a load balancer, which enables you to achieve the following:
Load Balancer supports a total of three load balancing methods:
Round Robin (select sequentially): This is the most basic and popular load balancing method that sequentially selects instances to forward traffic to. This method can be used when all member instances make the same response to the same request.
Least Connections (select the least connections first): This method selects the instance with the smallest number of current TCP connections. That is, it identifies the load status of instances based on the number of TCP connections and sends requests to the instance with the least load among the members so that requests are processed as evenly as possible. If you apply the method when the processing load caused by the requests fluctuates greatly, you can avoid a situation in which the load is concentrated on a specific instance.
Source IP (select by the source IP): This method selects the instance to process requests by hashing the source IP of the requester. When this method is used, requests coming from the same IP are always forwarded to the same instance. This is useful when you want the same instance to handle requests from a specific user every time.
Load Balancer supports the following protocols:
Among the above protocols, the TERMINATED_HTTPS protocol receives HTTPS traffic and forwards it to member instances as HTTP traffic. When the TERMINATED_HTTPS protocol is used, you can ensure high security by communicating over HTTPS between the end user and the load balancer, and reduce the CPU load for decryption by passing HTTP traffic to the server.
[Note] To use the TERMINATED_HTTPS protocol, a certificate and private key must be registered with the load balancer. The private key that is registered works correctly only when the password is removed.
Select one of the SSL/TLS versions to create a load balancer. The created load balancer communicates with clients using only the selected version and versions higher than the selected version, as shown below.
SSL/TLS Version Setting | SSL/TLS Version Used by Load Balancer |
---|---|
SSLv3 | SSLv3, TLSv1.0, TLSv1.1, TLSv1.2, TLSv1.3 |
TLSv1.0 | TLSv1.0, TLSv1.1, TLSv1.2, TLSv1.3 |
TLSv1.0_2016 | TLSv1.0, TLSv1.1, TLSv1.2, TLSv1.3 |
TLSv1.1 | TLSv1.1, TLSv1.2, TLSv1.3 |
TLSv1.2 | TLSv1.2, TLSv1.3 |
TLSv1.3 | TLSv1.3 |
SSL/TLS Version Setting | Cipher Suites Used | Note |
---|---|---|
SSLv3 | TLS-AES-128-GCM-SHA256 TLS-AES-256-GCM-SHA384 TLS-CHACHA20-POLY1305-SHA256 ECDHE-RSA-AES128-GCM-SHA256 ECDHE-RSA-AES128-SHA256 ECDHE-RSA-AES128-SHA ECDHE-RSA-AES256-GCM-SHA384 ECDHE-RSA-AES256-SHA384 ECDHE-RSA-AES256-SHA AES128-GCM-SHA256 AES256-GCM-SHA384 AES128-SHA256 AES256-SHA AES128-SHA DES-CBC3-SHA RC4-MD5 |
|
TLSv1.0 | TLS-AES-128-GCM-SHA256 TLS-AES-256-GCM-SHA384 TLS-CHACHA20-POLY1305-SHA256 ECDHE-RSA-AES128-GCM-SHA256 ECDHE-RSA-AES128-SHA256 ECDHE-RSA-AES128-SHA ECDHE-RSA-AES256-GCM-SHA384 ECDHE-RSA-AES256-SHA384 ECDHE-RSA-AES256-SHA AES128-GCM-SHA256 AES256-GCM-SHA384 AES128-SHA256 AES256-SHA AES128-SHA DES-CBC3-SHA |
RC4-MD5 is excluded |
TLSv1.0_2016 | TLS-AES-128-GCM-SHA256 TLS-AES-256-GCM-SHA384 TLS-CHACHA20-POLY1305-SHA256 ECDHE-RSA-AES128-GCM-SHA256 ECDHE-RSA-AES128-SHA256 ECDHE-RSA-AES128-SHA ECDHE-RSA-AES256-GCM-SHA384 ECDHE-RSA-AES256-SHA384 ECDHE-RSA-AES256-SHA AES128-GCM-SHA256 AES256-GCM-SHA384 AES128-SHA256 AES256-SHA AES128-SHA |
DES-CBC3-SHA is excluded |
TLSv1.1 | TLS-AES-128-GCM-SHA256 TLS-AES-256-GCM-SHA384 TLS-CHACHA20-POLY1305-SHA256 ECDHE-RSA-AES128-GCM-SHA256 ECDHE-RSA-AES128-SHA256 ECDHE-RSA-AES128-SHA ECDHE-RSA-AES256-GCM-SHA384 ECDHE-RSA-AES256-SHA384 ECDHE-RSA-AES256-SHA AES128-GCM-SHA256 AES256-GCM-SHA384 AES128-SHA256 AES256-SHA AES128-SHA |
Same as above |
TLSv1.2 | TLS-AES-128-GCM-SHA256 TLS-AES-256-GCM-SHA384 TLS-CHACHA20-POLY1305-SHA256 ECDHE-RSA-AES128-GCM-SHA256 ECDHE-RSA-AES128-SHA256 ECDHE-RSA-AES256-GCM-SHA384 ECDHE-RSA-AES256-SHA384 AES128-GCM-SHA256 AES256-GCM-SHA384 AES128-SHA256 |
ECDHE-RSA-AES128-SHA ECDHE-RSA-AES256-SHA AES256-SHA AES128-SHA is excluded |
TLSv1.3 | TLS-AES-128-GCM-SHA256 TLS-AES-256-GCM-SHA384 TLS-CHACHA20-POLY1305-SHA256 |
ECDHE-RSA-AES128-GCM-SHA256 ECDHE-RSA-AES128-SHA256 ECDHE-RSA-AES256-GCM-SHA384 ECDHE-RSA-AES256-SHA384 AES128-GCM-SHA256 AES256-GCM-SHA384 AES128-SHA256 is excluded |
Load balancers can be created with an IP automatically assigned within the VPC's subnet, or you can specify an IP.
The load balancer registers instances as members to distribute incoming traffic. Members can be registered in two ways
The traffic that flows into the load balancer is defined by listeners. By defining the ports and protocols on which to receive traffic per listener, you can set up a single load balancer to handle a wide variety of traffic. Generally, you would set up a port 80 listener on your web server to listen for HTTP traffic and a port 443 listener to listen for HTTPS traffic. You can register multiple listeners on one load balancer.
[Caution] You cannot create duplicate listeners with the same listening port on a load balancer.
The load balancer can perform load balancing based on L7 data. When you select an L7 routing template to create a load balancer, you can create a load balancer with L7 policies. The available actions are as follows.
Load Balancer operates in a proxy mode
. The client connects to a load balancer to send a request, while the load balancer connects to an instance server. From the member instance server’s perspective, session’s source IP is viewed as the load balancer IP. To check client IP from the server, refer to X-Forwarded-For
header information (HTTP or TERMINATED_HTTPS protocol) or use Proxy Protocol
(TCP or HTTPS protocol).
[Note] Proxy Mode
When the load balancer operates in proxy mode, the load balancer may serve differently for the port requested by the client and the port served by the server side. In addition, a function to reduce the server load such as TERMINATED_HTTPS can be provided, and the amount of traffic sent to the client can be provided in the form of statistics. (Statistics function to be added)
[Note] X-Forwarded-For Header
This is a non-standard HTTP header, which is used by the server to check the client's IP. HTTP requests coming in through the load balancer include the X-Forwarded-For key. Its value is the IP address of the client.The X-Forwarded-For header is enabled only when the load balancer protocol is set to HTTP or TERMINATED_HTTPS.
[Note] Proxy Protocol
This is a protocol for transmitting IP information of the client side when the load balancer uses TCP. It is expressed as a single line of text in US-ASCII format for human readability. When a TCP connection is established, it is transmitted once for the first time, and other data transmission is delayed until the receiving end receives all data.The proxy protocol is divided into 6 entries. Each entry is separated by a space character. The last character must end with Carriage Return (\r) + Line Feed (\n).
PROXY INET_PROTCOL CLIENT_IP PROXY_IP CLIENT_PORT PROXY_PORT\r\n
Acronym ASCII HEX Description PROXY "PROXY" 0x50 0x52 0x4F 0x58 0x59 Indicator for a proxy protocol INET_PROTOCL "TCP4" or "TCP6" 0x54 0x43 0x50 0x34 or 0x54 0x43 0x50 0x36 INET protocol type currently in use CLIENT_IP Example: "192.168.100.101"
or, "fe80::a159:b1f3:c346:5975"0xC0 0xA8 0x64 0x65 Source IP address PROXY_IP Example: "192.168.100.102"
or, "fe80::a159:b1f3:c346:5976"0xC0 0xA8 0x64 0x66 Destination IP address CLIENT_PORT Example: "43179" 0xA8 0xAB Source port PROXY_PORT Example: "80" 0x80 Destination port Examples of the proxy protocol are as follows:
- "PROXY TCP4 255.255.255.255 255.255.255.255 65535 65535\r\n": TCP/IPv4
- "PROXY TCP6 ffff:f...f:ffff ffff:f...f:ffff 65535 65535\r\n": TCP/IPv6
- "PROXY UNKNOWN\r\n": Unknown connection
If you are using the TCP or HTTPS protocol, you can set up a proxy protocol on the load balancer to check the client IP address. In this case, the server must also have the capability to recognize the proxy protocol like the ones shown above.
To ensure QoS, the load balancer limits the number of concurrent connections per listener. If the number of incoming requests exceeds the specified connection limit value, the requests are queued in a queue inside the load balancer and processed after previous requests are completed. In addition, requests can be terminated forcibly if the queue is full or a server/client times out. In this case, the client side may experience unexpected response delays.
[Note] The maximum number of session connection limits are as follows: 60,000 for a general load balancer, 480,000 for a dedicated load balancer, 1,000,000 for a physical Basic load balancer, and 3,000,000 for a physical Premium load balancer.
You can take advantage of the load balancer's session persistence feature when there is a need to maintain user information or a client’s request must be forwarded to a specific server only. This feature enables a server that processed a client’s request to continue processing the client’s further requests. If you select Source IP as the load balancing method, session persistence is provided because it determines the server based on the IP of the client. If you use Round Robin or Least Connection as the load balancing method, you can use the following session persistence features.
No Session Persistence (not maintaining sessions): A method that does not maintain a session.
Source IP (session management by source IP): A method of maintaining a session based on the source IP of the requester. For this purpose, the mapping table between the source IP and the instance selected by the load balancing method at the time of the initial request is kept internally. Afterwards, when a request with the same source IP comes in, it checks the mapping table and forwards it to the instance that responded to the first request. The load balancer can store mappings for up to 10000 source IPs. If you want to set up a TCP protocol listener to maintain a session, you must use this method.
APP Cookie (session management by application): A method of maintaining a session through explicit cookie setting from the server side. For the initial request, the server must forward a message to set the cookie value set for itself through the Set-Cookie header of HTTP. At this time, the load balancer checks whether there is a specified cookie among the server response, and if there is a cookie, internally maintains the mapping between the cookie and the server ID. After that, when the client puts a cookie pointing to a specific server in the Cookie header and sends it, the load balancer forwards the request to the server corresponding to the cookie. The load balancer automatically deletes the cookie-server ID mapping after 3 hours of inactivity.
HTTP Cookie (session management by load balancer): This is similar to the APP Cookie method, but maintains the session through a cookie that is automatically set by the load balancer. The load balancer adds a cookie called SRV to the server's response and sends it. Here, the value of the SRV cookie is a unique ID for each server. When a client sends an SRV in a cookie, the request is forwarded to the server that responded at first.
[Note] You can set the TCP session keep-alive time on the load balancer. By setting the keepalive timeout value, you can adjust the session maintenance time between the client and the load balancer and between the load balancer and the server.
This feature blocks HTTP request headers if they contain invalid characters. HTTP request headers with invalid characters may be sent by a hacker trying to exploit the server's vulnerability or via a browser affected by bugs. When this feature is enabled, the load balancer blocks HTTP requests with invalid characters to prevent them from being transferred to an instance and sends 400 response code (bad request) to the client.
NHN Cloud Load Balancer periodically tries checking the status of the instances registered as members to ensure that they operate normally. The health check is done by checking whether a expected response comes according to the specified protocol. If a normal response does not come within the specified number of times or duration, the instance is regarded as abnormal and excluded from the target of load balancing. This function enables uninterrupted service to be provided even in case of unexpected failure or maintenance.
The load balancer supports TCP, HTTP, and HTTPS as health check protocols. For precise health check, various health check methods can be set when using each protocol.
You can find many statistical indicators relevant to network flows processed by load balancer on charts. Features of statistics of NHN Cloud Load Balancer are as follows:
The following charts are provided:
Statistics Indicator Name (Chart Name) |
Type | Unit | Description |
---|---|---|---|
Client Session Count | Client | ea | Number of sessions where Load Balancer is connected with clients |
Client Session CPS | Client | cps (connections per second) |
Number of sessions newly connected with clients for a second |
Session CPS | Instance | cps (connections per second) |
Number of sessions newly connected with instances for a second |
Traffic In | Instance | bps (bits per second) |
Volume of traffic sent from Load Balancer to instances |
Traffic Out | Instance | bps (bits per second) |
Volume of traffic sent from instances to Load Balancer |
Load Balancing Exclusion Count | Instance | ea | Number of exclusion from load balancing targets due to a health check failure |
[Note] Restraints and Notes
- Statistics charts are provided only for the currently used load balancers, listeners, or members. When the load balancer resource is removed, its past statistics data is not provided.
- In the charts with the ea unit, the meaning of the figure may vary depending on the set period. You can find out the meaning of the figures by hovering the mouse over the question marks at the top of the individual charts.
- In indicators related to network usage such as Traffic In and Traffic Out, the figures expressed in the chart are data obtained by dividing the payload transmission size excluding the sizes of L2, L3, and L4 headers by the unit time. Therefore, the figures displayed in the chart are irrelevant to the billing data.
- Statistics data are provided for up to 1 year.
To control packets flowing into the load balancer, you can use the IP access control feature. This feature is different from Security Group, and the differences are as follows:
[Note] Comparison between Security Group and Load Balancer IP Access Control
Category Security Group Load Balancer IP Access Control Note Control Target Instance Load Balancer Configuration Target Configure IP and port Configure IP Only Traffic from ports other than the ports set on the load balancer is blocked by default Control Traffic Incoming/outgoing traffic
selectableOnly incoming traffic can be controlled Access Control Type Set Allow policy only Allow or Deny policy selectable
Security group settings and load balancer IP access control settings do not affect each other. Therefore, you need to use security groups to control incoming/outgoing traffic to/from your instances, and use IP access control to control incoming traffic to your load balancer.
To use the IP access control, you must set the following.
[Caution] To apply 'Allow' type access control group to a load balancer, member instance IP of the load balancer must be added as access control target.
[Note] You can use the NHN Cloud Security Monitoring to find out the thread remote IP addresses.
You can enhance the system security by creating an IP access control group with the 'Deny' IP access control type, and adding detected threat remote IP addresses to access control targets.
[Note]
- Behavior when changing a load balancer or IP access control
- If you delete a load balancer, access control binding is deleted, but access control groups are not deleted.
- If you delete an access control group, the change is reflected in all load balancers bound to the group.
- If you add or delete an access control target within an access control group, the change is reflected in all load balancers bound to the group.
Load Balancer has two pricing policies: