Can nginx be clustered?

Can nginx be clustered?

nginx realizes cluster high availability

Everyone knows that NGINX can achieve load balancing as a reverse proxy server and can also be used as a static file server. Its characteristics That is, the concurrency support is large, and a single machine can support 30,000 concurrencies at the same time. Now many websites use NGINX as a gateway portal to uniformly schedule and allocate back-end resources. However, if NGINX goes down, the entire backend service will be unusable; or when the concurrency is really large, reaching the level of 100,000, there is still a limit to one NGINX, so at this time, it is necessary to perform master-slave operation on NGINX. Backup ensures high availability of services, and clusters are used to share concurrency pressure. Currently, NGINX mainly has the following solutions in these two areas. I will introduce them to you respectively:

NGINX master-slave backup

NGINX currently implements master-slave backup The mainstream solution is Keepalived Nginx to implement dual-machine hot backup.

Keepalived introduction:

Keepalived is a service high-availability solution based on the VRRP protocol. It can be used to avoid IP single points of failure. Similar tools include heartbeat, corosync, and pacemaker. But it generally does not appear alone, but works together with other load balancing technologies (such as lvs, haproxy, nginx) to achieve high availability of the cluster.

VRRP protocol:

The full name of VRRP is Virtual Router Redundancy Protocol, which is the virtual routing redundancy protocol. It can be considered a fault-tolerant protocol to achieve high availability of routers. N routers that provide the same functions are formed into a router group. This group has a master and multiple backups, but it looks like one router to the outside world. , constitute a virtual router, with a virtual IP (vip, that is, the default route of other machines in the LAN where the router is located). The master that owns this IP is actually responsible for ARP response and forwarding IP packets, and other routers in the group serve as backup roles. Standby. The master will send multicast messages. When the backup fails to receive vrrp packets within the timeout period, it is considered that the master is down. At this time, a backup needs to be elected as the master based on the VRRP priority to ensure the high availability of the router.

In the VRRP protocol implementation, the virtual router uses 00-00-5E-00-01-XX as the virtual MAC address. XX is the unique VRID (Virtual Router IDentifier). This address only has one physical router at the same time. occupied. In the physical router group in the virtual router, notification messages are sent regularly through the multicast IP address 224.0.0.18. Each Router has a priority level between 1-255, and the highest priority will become the master router. By lowering the priority of the master, the router in the backup state can preempt (pro-empt) the state of the main router. The larger of the two IP addresses with the same backup priority is the master and takes over the virtual IP.

Specific implementation principle:

1) Master is not down, then Master occupies VIP and nginx is running on Master

2) Master is down, Then the backup seizes the VIP and runs the nginx service on the backup

3) If the nginx service on the master server hangs, the VIP resources are transferred to the backup server

4) Detect the back-end server Health status

Both Master and Backup have nginx services enabled. Regardless of Master or Backup, when one of the keepalived services stops, VIP will drift to the node where the keepalived service is still there

NGINX and keepalived installation and configuration

There are many installation configurations for them, as well as writing scripts to monitor each other, alarm, etc., so we will give a special lesson Lecture, this lesson mainly talks about solutions and principles.

NGINX Distributed Cluster

If there are multiple NGINX and you want to achieve load balancing,

1. Each nginx has a public network address. Setting multiple directions to the same domain name at the domain name is the easiest way to implement round robin. But the fault cut-off will be slower.

2. One public network nginx is distributed to multiple nginxes on the intranet through the upstream function, wheel, IP, and url. But if nginx on the public network is down, the entire internal network will be affected.

3. A pair of public network nginx plus three public network IPs, achieve high availability through keepalive, and then upstream to the intranet (this is the master-slave backup we just talked about in the previous section).

Generally speaking, the above 1, 2, and 3 methods can basically solve the problem. It is recommended to use 2 or 3;

If the amount of concurrency is really huge, it is generally necessary to use hardware F5 and other equipment To do load balancing, cooperate with DNS, CDN and other service providers to do domain name resolution forwarding and cache configuration. This is also the current architectural configuration of most major manufacturers.

For more Nginx related technical articles, please visit the Nginx usage tutorial column to learn!

The above is the detailed content of Can nginx be clustered?. For more information, please follow other related articles on the PHP Chinese website!