Butler for Back-end servers: Proxy Server Haproxy

Haproxy provides high availability, load balancing, and proxies based on TCP and HTTP applications to support virtual hosts, a free, fast, and reliable solution. Haproxy is especially useful for Web sites that are heavily loaded, which typically require session maintenance or seven-tier processing. Haproxy is running on the current hardware and can support tens of thousands of concurrent connections altogether. and its operating mode makes it easy and secure to integrate into your current architecture while protecting your Web server from being exposed to the network.

Haproxy implements an event-driven, single process model that supports a very large number of concurrent connections. Multi-process or multithreaded models are rarely able to handle thousands of concurrent connections because of memory limitations, System scheduler restrictions, and ubiquitous lock restrictions. The event-driven model does not have these problems because it implements all of these tasks on the client side with better resources and time management (User-space). The disadvantage of this model is that these programs are often poorly extensible on multicore systems. That's why they have to be optimized to make each CPU time slice (Cycle) do more work.

Reliability

Being obsessed with reliability, I tried to do what I could to ensure the continuity of the overall design service. It is more difficult to design reliable things to get up from the ground in the short term, but in the long run it reveals a much easier maintenance than breaking code, trying to cover up the rebirth process and techniques behind their mistakes.

In a single process program, you have no right to fail: the smallest error will cause the program to crash, it's like crazy or frozen rotation. No such errors have been found in the code, nor for the last 10 years in production.

Haproxy is installed in the Linux 2.4 system, serving millions of pages a day, only to be restarted once in 3 years for a full operating system upgrade. Obviously, they are not directly exposed to the Internet because they do not receive any patches. The kernel is a heavy Robert Ei jiffies64 patch 2.4 Surround support time in 497 days (that occurs two times). In this system, the software cannot fail, but it will not be noticed immediately!

Now it is being used in several Fortune 500 companies around the world to reliably service millions of daily pages or relays for huge sums of money. Some people even believe it so much that they use it as the default solution to solve simple problems (I often tell them that they do this dirty way). Such people sometimes still use versions 1.1 or 1.2 to see very limited arrays, and for mission-critical usage. Haproxy is really suitable for such an environment because it returns metrics that provide a lot of valuable information about the health, behavior and defects of the application, which is used to make the system more reliable. Version 1.3 is now far more tested than the combination of 1.1 and 1.2, so we strongly recommend that users migrate to a stable 1.3 for mission-critical purposes.

As mentioned earlier, most of the work is performed by the operating system. For this reason, a large part of the reliability involves the operating system itself. The latest Linux 2.4 release provides the highest level of stability. However, it requires a bunch of patches to achieve a high standard of performance. Linux 2.6 contains features that require this level of performance, but are not yet stable, this usage. The kernel needs at least one upgrade per month to fix bugs or vulnerabilities. Some people prefer to execute on Solaris (or not). Solaris 8 and 9 are known to be truly stable, and now provide performance comparable to the level of Linux 2.4. The Solaris 10 display performance is closer to Linux 2.6, but the same code has a stability problem. I have too few reports from FreeBSD users, but it should be close to Linux 2.4 in terms of performance and reliability. The OpenBSD system sometimes displays a fin_wait2 state when the customer suddenly disappears from the socket socket due to an allocation failure. In addition, I noticed that the hot reconfiguration does not work in OpenBSD.

When the system is pushed to its limit, it can significantly reduce the reliability. This is why SYSCTL is very important for fine tuning. There are no general rules for every system, every application will be specific. However, it is important to ensure that the system will always run memory and it will never be lost. Properly tuned systems must be able to run at full load for years without slowing down or collapsing.

Security

Security is an important concern when deploying a software load balancer. It is possible to harden the operating system, the number of open ports and access services is limited, but the load balancer itself remains exposed. For this reason, I have been very careful with the programming style. The only vulnerabilities found so far have been traced back to the early 2002 and lasted only one weeks. According to the introduction, when the log rework. It can be used to cause a bus error to crash the process, but it does not seem to be able to execute code: The focus overflow is only 3 bytes, too short to store pointers (with a variable).

In any case, take care to write the code while manipulating the head. The Impossible State combination is checked and returned, from creating a session to death and error handling. There are several people around the world who have reviewed code and better clarity to ease audit recommendation cleanup. By the way, I used to reject the patch to introduce the suspect's handling or unusual circumstances without adequate care.

I generally recommend starting the root of the haproxy, as it can be the prison itself in the chroot environment, and discard all privileges before starting the instance. This is not possible if it has no root, since only the root user can execute the chroot () start.

Logs provide a great deal of information to help maintain a satisfactory level of security. They can only be sent via UDP because once the Cherrot,/dev/log UNIX sockets are up and it is not possible to write a file. The following information is particularly useful:

• Source IP address and port requests make it possible for people to find their place of origin in the firewall log;

• The meeting set a date, generally matching the firewall log, and the date of the break is often matched by the proxy date;

• The appropriate request encoding ensures that the requester cannot hide nonprinting characters and is not a dummy terminal.

• Arbitrary request and response headers and cookie capture detects scan attacks, proxies and infected hosts.

• Timers help distinguish between manually typing requests from a browser.

Haproxy also provides head control based on regular expressions. Partial requests, as well as request and response headers can be rejected, allowed, deleted, rewritten, or supplemented. This is commonly used to prevent dangerous requests or encodings (for example, an Apache block vulnerability) to prevent accidental information leaks from the server to the client. Other features, such as cache control checks, ensure that no sensitive information upstream proxies get accidentely cache for a continuous example of a bug in the application server.