Network Security Internet Technology Development Database Servers Mobile Phone Android Software Apple Software Computer Software News IT Information

In addition to Weibo, there is also WeChat

Please pay attention

WeChat public account

Shulou

Practical information | introduction to LVS virtual server

2025-02-06 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Servers >

Share

Shulou(Shulou.com)06/02 Report--

LVS is Linux Virtual Server. Virtual server is a highly scalable and highly available server, built on a real server cluster. The architecture of the server cluster is completely transparent to the end user, and the user interacts with the cluster system as if it were just a high-performance virtual server. Please refer to the following figure:

Real servers and load balancers can be interconnected via high-speed LAN (local area network) or geographically dispersed WAN (wide area network). The load balancer can assign requests to different servers at the back end, while external virtual services are only displayed as a single IP. The working mode of distribution can use IP load balancing technology or application-level load balancing technology. The scalability of the system is achieved by transparently adding or removing nodes in the cluster. Provide high availability by detecting node or daemon failures and reconfiguring the system appropriately.

The basic goal of Linux Virtual Server Project is to use cluster technology to build high-performance, high-availability servers for Linux, providing good scalability, reliability and maintainability.

Why do I need LVS?

With the explosive growth of the Internet and its increasingly important role in our lives, the traffic on the Internet has increased sharply. The workload on the server also increases rapidly, so it is easy for the server to overload in a short period of time, especially for some popular websites. In order to overcome the problem of server overload, there are two solutions: one is a single-server solution, that is, the server is upgraded to a higher-performance server, but it quickly overloads as requests increase, so we have to upgrade again, the upgrade process is complex and costly; the other is a multi-server solution, that is, building a scalable network service system on a server cluster. When the load increases, we can simply add new servers or more servers to the cluster to meet the growing requests. Therefore, building a server cluster system for network services is more scalable and cost-effective.

There are several ways to build a server cluster:

a. Load balancing Cluster based on DNS

DNS load balancing is probably the easiest way to build a network service cluster. It uses the domain name system to distribute requests to different servers by resolving the domain name to different IP addresses of the server. When the DNS request arrives at the DNS server to resolve the domain name, the DNS server issues a server IP address according to the scheduling policy, such as round robin, and then sends subsequent requests from the client to the same server within the specified name resolution lifetime (TTL) using the same local cache name server.

However, due to the client and hierarchical DNS systems, it is easy to lead to dynamic load imbalance between servers, so the server is not easy to handle its peak load. The TTL value of name mapping cannot be well selected on the DNS server. If the TTL value is very small, the DNS traffic will be very high and the DNS server will become a bottleneck. If the TTL value is too high, the dynamic load imbalance will become worse. Even if the TTL value is set to zero and the scheduling granularity is per host, the access patterns of different users may cause dynamic load imbalance, because some people may pull a large number of pages from the site, while others may just browse a few pages.

b. Load balancing Cluster based on Scheduler

Dispatcher, also known as load balancer, can be used to distribute load among servers in a cluster so that parallel services for servers can appear as virtual services on a single IP address, and end users can interact like a single server without knowing all the servers in the cluster. Compared to DNS-based load balancing, the scheduler can schedule requests at fine granularity, such as each connection, to achieve better load balancing between servers. When one or more servers fail, the failure can be shielded. Server management is becoming easier and easier, and administrators can use servers or more servers at any time without disrupting end-user services.

Load balancing can be done at two levels, namely, application level and IP level. For example, Reverse-proxy and pWEB are application-level load balancing methods for building scalable Web servers. They forward the HTTP request to different Web servers in the cluster, get the result, and then return it to the client. Due to the high overhead of processing HTTP requests and replies at the application level, application-level load balancers become a new bottleneck when the number of server nodes increases to 5 or more.

The way LVS works

Virtual servers are now implemented in three ways. There are three IP load balancing techniques (packet forwarding methods) in Linux Director. They are virtual servers through NAT, virtual servers through IP tunnels, and virtual servers through direct routing. That is, NAT/DR/IP Tunneling.

The following sections explain their pros and cons. The comparison of VS/NAT,VS/TUN and VS/DR is summarized in the following table:

A. NAT

The advantage of a virtual server over NAT is that the real server can run any operating system that supports the TCP / IP protocol, the real server can use a private Internet address, and the load balancer only needs one IP address.

The disadvantage is that the scalability of the virtual server over NAT is limited. When the number of server nodes increases to about 20 or more, the load balancer may be a bottleneck for the entire system, because both the request and response packets need to be rewritten by the load balancer. Assuming that the average length of TCP packets is 536 bytes, the average latency of rewrite packets is about 60us (on Pentium processors, using a higher processor can be reduced a little bit), and the maximum throughput of the load balancer is 8.93 MB / s. Assuming that the average throughput of real servers is 400Kbytes / s, the load balancer can schedule 22 real servers.

B. IP Tunneling

In virtual servers passing through NAT, both request and response packets need to go through load balancers. When the number of server nodes increases to 20 or more, load balancers may become a new bottleneck because the throughput of network interfaces is ultimately limited. As can be seen from many Internet services, such as Web services, request packets are usually short, while response packets usually contain large amounts of data.

In the virtual server through the IP tunnel, the load balancer only dispatches requests to different real servers, while the real server returns a reply directly to the user. Therefore, the load balancer can handle a large number of requests, it can schedule more than 100 real servers, and it will not become a bottleneck to the system. Therefore, using IP tunneling will greatly increase the maximum number of server nodes for the load balancer. Even if the load balancer has only a 100Mbps full-duplex network adapter, the maximum throughput of the virtual server can reach more than 1Gbps.

IP tunneling can be used to build high-performance virtual servers. Building a virtual proxy server is good because when the proxy server gets a request, it can directly access the Internet to get the objects and return them directly to the user.

C. Direct Routing

As in the virtual server through tunneling, the DR mode handles client-to-server traffic in the virtual server only through direct routing, while the real server at the back end directly corresponds to the packet and sends it to the client. This can greatly improve the scalability of the virtual server.

Compared with the virtual server through the IP tunnel method, this method has no tunnel overhead, but requires that the interface of the load balancer and the interface of the real server must be on the same network segment.

Architecture of LVS

For the scalability, availability, and manageability of the entire system, we usually adopt the three-tier architecture in the LVS cluster shown in the following figure.

The three-tier structure includes:

Load Balancer

It is the front-end machine of the entire cluster system and balances requests from clients across a set of servers so that clients think that all services come from a single IP address.

Server cluster

It is a set of servers running actual network services, such as Web, mail, FTP,DNS, and media services.

Shared storage

Provide shared storage space for the server so that the server can easily have the same content and provide the same services.

Load balancer is a single entry point of server cluster system. It can run IPVS of IP load balancing technology in Linux kernel or KTCPVS of application-level load balancing in Linux kernel. When using IPVS, all servers need to provide the same service and content, and the load balancer forwards new client requests to the server according to the specified scheduling algorithm and the load of each server. No matter which server you choose, the client should get the same result. When using KTCPVS, the server can have different content, and the load balancer can forward the request to different servers based on the content of the request. Because KTCPVS is implemented in the Linux kernel, the overhead of relaying data is small, so it can have high throughput.

The number of nodes in the server cluster can be changed according to the load received by the system. When all the servers in the cluster are overloaded, more new servers can be added to handle the increasing workload. For most Internet services, such as Web, requests can run in parallel on different servers. Therefore, with the increase of the number of nodes in the server cluster, the overall performance can be expanded almost linearly.

Shared storage can be a database system, a network file system or a distributed file system. The data that the server node needs to update dynamically should be stored in the data-based system. When the server node reads or writes the data in the database system in parallel, the database system can ensure the consistency of concurrent data access. Static data is typically saved in network file systems, such as NFS and CIFS, so that all server nodes can share the data. However, the scalability of a single network file system is limited, for example, a single NFS / CIFS can only support data access from 4 to 8 servers. For large-scale cluster systems, distributed / clustered file systems can be used for shared storage, such as GPFS,Coda and GFS, and then shared storage can also be extended according to system requirements.

Load balancers, server clusters and shared storage are usually connected by high-speed networks, such as 100Mbps Ethernet and Gigabit Ethernet, so that the network does not become a bottleneck when the system grows.

LVS High availability

As more and more mission-critical applications run on Internet, it becomes more and more important to provide highly available services. One of the advantages of the cluster system is that it has hardware and software redundancy, because the cluster system consists of many independent nodes, each node running a copy of the operating system and application software. By detecting node or daemon failures and reconfiguring the system appropriately, high availability can be achieved so that the workload can be taken over by the rest of the cluster.

In fact, high availability is a big area. Advanced high-availability systems can have reliable communication subsystems, member management subsystems, concurrency control subsystems and so on, which require more learning costs. However, we can now use some existing software packages to build a highly available LVS cluster system.

Typically, run the service monitor daemon on the load balancer to check the health of the server periodically, as shown in the following figure. If the server access request or ICMP ECHO_REQUEST does not respond within the specified time, the service monitor will assume that the server has died and remove it from the list of available servers in the load balancer, so the request will not be forwarded to the dead server. When the Service Monitor detects that the dead server is back to work, the Service Monitor adds the server back to the list of available servers. As a result, the load balancer can automatically mask the failure of the service daemon or server. In addition, administrators can use system tools to add new servers to improve system throughput or delete servers for system maintenance without shutting down the entire system service.

Now the load balancer may become a single point of failure for the whole system. To prevent the entire system from shutting down due to a load balancer failure, we need to set up a backup (or multiple backups) of the load balancer. Two heartbeat daemons run on the primary server and the backup server, respectively, by periodically detecting messages such as "I'm still alive." When the backed-up heartbeat daemon cannot hear the heartbeat message from the primary server within a specified period of time, it takes over the virtual IP address to provide load balancing services. When a failed load balancer returns to work, there are two solutions, one is to automatically become a backup load balancer, and the other is that the active load balancer releases the VIP address and restores the VIP address once and becomes the primary load balancer.

The primary load balancer has a connection state, that is, to which server the connection is forwarded. If the backup load balancer takes over without this connection information, the client must send its request to the access service again. In order to make the load balancer failover transparent to the client application, we implement connection synchronization in IPVS, and the primary IPVS load balancer synchronizes the connection information to the backup load balancer through UDP multicast. When the backup load balancer takes over after the primary load balancer fails, the backup load balancer will have most connection states, so almost all connections can continue to access the service through the backup load balancer.

Click "Product documentation" to learn how to get started with Linux and create examples.

Welcome to click "Jingdong Yun" to learn more wonderful content.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.

Views: 0

*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.

Share To

Servers

Wechat

© 2024 shulou.com SLNews company. All rights reserved.

12
Report