Haproxy - .:: HVAOnline ::.

English | Vietnamese

Rules

Main Forum

Portal

Member Listing

Statistics

Search

Reading Room
[Register]

Login [ | https ]

Forum Index

Thảo luận hệ điều hành *nix

Haproxy

[Question] Haproxy	06/09/2011 16:35:42 (+0700) \| #1 \| 246568

Nguyen Canh Toan
Member

Joined: 28/06/2011 11:05:39
Messages: 105
Offline

Xin chào mọi người
Hiện tại mình đang thực hiện load balancing web dựa trên haproxy.
Mình đã cài đặt thành công.
Mình cài theo mô hình haproxy dùng để đỡ request và cân bằng tải cho 2 server thực nằm ở phía trong.

Bây giờ mình muốn thực hiện giải pháp như sau :
Khi Server1 đang bận hoặc là xử lý nhiều request thì sẽ phân phát bớt cho Server2 đang rỗi. Mong muốn là cả 2 server cùng thực hiện với hiệu suất tương đối như nhau. Tránh delay cho hệ thống.
Hiện tại mình đang dùng thuật toán roundrobin nhưng cảm thấy chưa hài lòng.

Không biết trên haproxy cung cấp tuỳ chọn gì để thực hiện điều này không?
Mong các pro giúp đỡ mình với !

Tập tin config của mình

listen http_proxy
bind 192.168.1.254:80
mode http
stats enable
balance roundrobin
backlog 2048
option httpclose
option forwardfor
timeout connect 10000
timeout client 30000
timeout server 30000
timeout queue 30000
maxconn 4000
option httpchk #enable HTTP protocol check server health
option abortonclose #cho phep xoa bo request da huy tu queue
server webserver01 192.168.1.251:80 cookie server1 check
server webserver02 192.168.1.252:80 cookie server2 check

[Question] Haproxy	07/09/2011 09:04:12 (+0700) \| #2 \| 246588

zeno
Elite Member

Joined: 20/07/2004 03:57:09
Messages: 124
Location: HVA
Offline

Xin chào,

Khi Server1 đang bận hoặc là xử lý nhiều request thì sẽ phân phát bớt cho Server2 đang rỗi

Bạn dùng Round Robin thì số lượng request vào mỗi server là tương đối ngang nhau rồi. Tuy nhiên hiệu xuất có thể khác nhiều tuỳ thuộc vào request đó là gì.

Nếu vẫn muốn đảm bảo request giữa 2 server bạn có thể dùng Least Connections(leastconn). Ngoài ra có các
Server Weight add-on nếu các webserver trong backend có cấu hình/sức mạnh khác nhau. Tuy nhiên cái weight này là static thôi.

Nếu muốn request đẩy nhiều vào server đang sử lý nhanh hơn, it vào server đang chậm hơn. Thì bản thân load balancer phải có modules check các server này một cách real time và dựa vào các yếu tố như response time, Throughput thì mới có thể đưa ra được quyết định gửi request đến server nào trong backend. Mình nghĩ một module như thế tôn khá nhiều tài nguyên hệ thống cho cả backend và proxy,mạng ... và làm cho response time đến end user chậm hơn. Nên các load balancer băng software không support.
Mình nghĩ Dùng Round Robin là tốt rồi.

Bạn có thể tham khảo thêm tại http://haproxy.1wt.eu/download/1.3/doc/configuration.txt phần "load balance algorithm" để biết chi tiết về các algorithm mà HAproxy support.

[Question] Haproxy	07/09/2011 10:32:46 (+0700) \| #3 \| 246593

Nguyen Canh Toan
Member

Joined: 28/06/2011 11:05:39
Messages: 105
Offline

Cảm ơn bạn zeno
Mình cũng đã đọc cái thuật toán load balancing trên trang chủ haproxy.
Mình thấy thuật toán leastconn thường dùng cho những phiên làm việc dài, ít sử dụng cho http.

Mình cũng có đọc qua phần weight rr.
Theo mình nghĩ thì giải pháp phần mềm thì dùng roundrobin là khá tốt.
Cảm ơn bạn về lời khuyên !

[Question] Haproxy	14/09/2011 13:40:25 (+0700) \| #4 \| 247117

Nguyen Canh Toan
Member

Joined: 28/06/2011 11:05:39
Messages: 105
Offline

Chào mọi người !
Sơ đồ mạng của mình bao gồm như sau :
1 server haproxy đứng trước để đỡ request
2 server web ở phía trong

yêu cầu :
1. haproxy nhận request và phân tán request tới 2 server theo các thuật toán cân bằng tải.
Cái này thì mình đã làm và sử dụng thuật toán RR
2. Các server web trực tiếp reponse tới người dùng cuối mà không phải thông qua haproxy.
Mình muốn như vậy vì để tránh trường hợp thắt cổ chai. Tức là khi số người truy cập quá lớn thì một lượng request vào và lượng reponse thông qua haproxy là rất lớn.

Mình muốn nhờ mọi người ai đã từng làm thì giúp đỡ mình với!
Vì đọc trên trang chủ của Haproxy mình tìm mà chưa thấy nói về vấn đề này.
Thanks !

[Question] Haproxy	14/09/2011 14:18:05 (+0700) \| #5 \| 247121

centos
Member

Joined: 28/03/2008 17:13:12
Messages: 219
Offline

Nguyen Canh Toan wrote:

Chào mọi người !
Sơ đồ mạng của mình bao gồm như sau :
1 server haproxy đứng trước để đỡ request
2 server web ở phía trong

yêu cầu :
1. haproxy nhận request và phân tán request tới 2 server theo các thuật toán cân bằng tải.
Cái này thì mình đã làm và sử dụng thuật toán RR
2. Các server web trực tiếp reponse tới người dùng cuối mà không phải thông qua haproxy.
Mình muốn như vậy vì để tránh trường hợp thắt cổ chai. Tức là khi số người truy cập quá lớn thì một lượng request vào và lượng reponse thông qua haproxy là rất lớn.

Mình muốn nhờ mọi người ai đã từng làm thì giúp đỡ mình với!
Vì đọc trên trang chủ của Haproxy mình tìm mà chưa thấy nói về vấn đề này.
Thanks !

thắc cổ chai là thắc cái gì, bạn sợ vấn đề gì sảy ra????????.

[Question] Haproxy	15/09/2011 09:48:29 (+0700) \| #6 \| 247160

vitcon01
Member

Joined: 29/04/2009 11:28:21
Messages: 306
Offline

centos wrote:

Nguyen Canh Toan wrote:

Chào mọi người !
Sơ đồ mạng của mình bao gồm như sau :
1 server haproxy đứng trước để đỡ request
2 server web ở phía trong

yêu cầu :
1. haproxy nhận request và phân tán request tới 2 server theo các thuật toán cân bằng tải.
Cái này thì mình đã làm và sử dụng thuật toán RR
2. Các server web trực tiếp reponse tới người dùng cuối mà không phải thông qua haproxy.
Mình muốn như vậy vì để tránh trường hợp thắt cổ chai. Tức là khi số người truy cập quá lớn thì một lượng request vào và lượng reponse thông qua haproxy là rất lớn.

Mình muốn nhờ mọi người ai đã từng làm thì giúp đỡ mình với!
Vì đọc trên trang chủ của Haproxy mình tìm mà chưa thấy nói về vấn đề này.
Thanks !

thắc cổ chai là thắc cái gì, bạn sợ vấn đề gì sảy ra????????.

--->bạn ấy lo là đúng trường hợp request vào với số lượng lớn và response cũng số lượng lớn, thì lúc này cần xem lại hiệu suất của HA Proxy.

--->Tôi nghĩ để đáp ứng yêu cầu của bạn Nguyen Canh Toan, bạn thử nghiên cứu LVS- DR xem sao.

JK - JH
()()()
LTKT - LTT

[Question] Haproxy	15/09/2011 15:37:10 (+0700) \| #7 \| 247181

Nguyen Canh Toan
Member

Joined: 28/06/2011 11:05:39
Messages: 105
Offline

Cảm ơn các bạn đã quan tâm
Ở đây thắt cổ chai thì như bạn vitcon có nói.
Tức là khi số lượng request đi vào và lượng response trả lời là rất lớn.
Tất cả đều đi qua haproxy.
Thì ở haproxy có thể xảy ra hiện tượng thắt cổ chai.
Mình muốn hỏi xem là có phương pháp nào để tránh được vấn đề này hay không?

Như bạn vitcon đưa ra lời gợi ý tức là LVS-DR thì mình cũng có biết tới. Nhưng nó lại thuộc hướng LVS
Mình muốn ở đây là nó có thể khắc phục trên thằng haproxy cơ !
Ai biết đến vấn đề này thì giúp đỡ mình với !

[Question] Haproxy	16/09/2011 14:10:59 (+0700) \| #8 \| 247255

Nguyen Canh Toan
Member

Joined: 28/06/2011 11:05:39
Messages: 105
Offline

Ai có thể giúp mình không nhỉ !
Híc smilie

[Question] Haproxy	19/09/2011 14:14:06 (+0700) \| #9 \| 247366

centos
Member

Joined: 28/03/2008 17:13:12
Messages: 219
Offline

Hix chắc mình nghi bạn chưa dựng hệ thống haproxy và ba thử hệ thống chịu lỗi của haproxy. Nếu hệ thống bạn có trên 10k connection đồng thời vào hệ thống thì hãy nghĩ đến việc haproxy không phục vụ nổi

[Question] Haproxy	19/09/2011 16:18:28 (+0700) \| #10 \| 247380

Nguyen Canh Toan
Member

Joined: 28/06/2011 11:05:39
Messages: 105
Offline

Mình chưa hiểu rõ ý của bạn lắm.
Mình đang thắc mắc về vấn đề hiệu suất của thằng haproxy khi xảy ra tình trạng trên thôi.
Theo như mình đoán thì ý của bạn ở đây là thằng haproxy có thể chịu được 10000k hả.

Bạn có thể giải thích rõ hơn được không?
Cảm ơn bạn !

[Question] Haproxy	29/09/2011 14:21:26 (+0700) \| #11 \| 247915

centos
Member

Joined: 28/03/2008 17:13:12
Messages: 219
Offline

Nguyen Canh Toan wrote:

Mình chưa hiểu rõ ý của bạn lắm.
Mình đang thắc mắc về vấn đề hiệu suất của thằng haproxy khi xảy ra tình trạng trên thôi.
Theo như mình đoán thì ý của bạn ở đây là thằng haproxy có thể chịu được 10000k hả.

Bạn có thể giải thích rõ hơn được không?
Cảm ơn bạn !

Đọc cái này nha bạn:

There are 3 important factors used to measure a load balancer's performance :

The session rate
This factor is very important, because it directly determines when the load balancer will not be able to distribute all the requests it receives. It is mostly dependant on the CPU. Sometimes, you will hear about requests/s or hits/s, and they are the same as sessions/s in HTTP/1.0 or HTTP/1.1 with keep-alive disabled. Requests/s with keep-alive enabled does not mean anything, and is generally useless because it is very often that keep-alive has to be disabled to offload the servers under very high loads. This factor is measured with varying object sizes, the fastest results generally coming from empty objects (eg: HTTP 302, 304 or 404 response codes). Session rates above 20000 sessions/s can be achieved on Dual Opteron systems such as HP-DL145 running a carefully patched Linux-2.4 kernel. Even the cheapest Sun's X2100-M2 achieves 25000 sessions/s in dual-core 1.8 GHz configuration.
The session concurrency
This factor is tied to the previous one. Generally, the session rate will drop when the number of concurrent sessions increases (except the epoll polling mechanism). The slower the servers, the higher the number of concurrent sessions for a same session rate. If a load balancer receives 10000 sessions per second and the servers respond in 100 ms, then the load balancer will have 1000 concurrent sessions. This number is limited by the amount of memory and the amount of file-descriptors the system can handle. With 8 kB buffers, HAProxy will need about 16 kB per session, which results in around 60000 sessions per GB of RAM. In practise, socket buffers in the system also need some memory and 20000 sessions per GB of RAM is more reasonable. Layer 4 load balancers generally announce millions of simultaneous sessions because they don't process any data so they don't need any buffer. Moreover, they are sometimes designed to be used in Direct Server Return mode, in which the load balancer only sees forward traffic, and which forces it to keep the sessions for a long time after their end to avoid cutting sessions before they are closed.
The data rate
This factor generally is at the opposite of the session rate. It is measured in Megabytes/s (MB/s), or sometimes in Megabits/s (Mbps). Highest data rates are achieved with large objects to minimise the overhead caused by session setup and teardown. Large objects generally increase session concurrency, and high session concurrency with high data rate requires large amounts of memory to support large windows. High data rates burn a lot of CPU and bus cycles on software load balancers because the data has to be copied from the input interface to memory and then back to the output device. Hardware load balancers tend to directly switch packets from input port to output port for higher data rate, but cannot process them and sometimes fail to touch a header or a cookie. For reference, the Dual Opteron systems described above can saturate 2 Gigabit Ethernet links on large objects, and I know people who constantly run between 3 and 4 Gbps of real traffic on 10-Gig NICs plugged into quad-core servers.

[Question] Haproxy	27/12/2012 15:03:35 (+0700) \| #12 \| 272177

chicisco
Member

Joined: 19/10/2010 03:53:57
Messages: 1
Offline

Đơn giản chỉ thêm 1 con haproxy nữa. Bạn phải test xem haproxy đáp ứng dc request bao nhiêu request? sau đó mới đưa cách giải quyết.

Go to:

Users currently in here
1 Anonymous