Tìm hiểu và triển khai hệ thống cân bằng tải và chịu lỗi trên môi trường Linux Đề tài nghiên cứu khoa học

47 1.2K 6
Tìm hiểu và triển khai hệ thống cân bằng tải và chịu lỗi trên môi trường Linux  Đề tài nghiên cứu khoa học

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

Thông tin tài liệu

Tìm hiểu và triển khai hệ thống cân bằng tải và chịu lỗi trên môi trường Linux Đề tài nghiên cứu khoa học Giới thiệu cân bằng tải Cơ sở hạ tầng công nghệ thông tin đang giữ một nhiệm vụ ngày càng quan trọng trong sự thành công của một doanh nghiệp. Thị phần,quý khách hàng hài lòng với sản phẩm của công ty và hình ảnh công ty tất cả những thứ này có thể do website của doanh nghiệp đó chiếm một phần quan trọng. Hệ thống các máy chủ hiện nay thường xuyên được sử dụng để lưu trữ ERP, thương mại điện tử và vô số các ứng dụng khác. Nền tảng của các webiste này, các chiến lược kinh doanh, tính sẵn sàng cao, cơ sở hạ tầng tốt sẽ cung cấp hiệu suất cao và các giải pháp an toàn và khả năng mở rộng để hỗ trợ tất cả các ứng dụng. Bên cạnh đó, sự sẵn có của các ứng dụng này thường bị đe dọa bởi quá tải mạng cũng như sự cố xảy ra trên các hệ thống máy chủ và các ứng dụng. Sử dụng tài nguyên thường trong sự cân bằng, dẫn đến các nguồn lực hiệu suất thấp đang quá tải với các yêu cầu, trong khi các nguồn lực hiệu suất cao vẫn nhàn rỗi. Server Load Balancing (máy chủ cân bằng tải) là một giải pháp giúp cân bằng lại giữa các nguồn lực và giúp tăng hiệu suất làm việc cho hệ thống mạng trong doanh nghiệp.

HỌC VIỆN KỸ THUẬT MẬT MÃ KHOA CÔNG NGHỆ THÔNG TIN ĐỀ TÀI THỰC TẬP CƠ SỞ TÌM HIỂU VÀ TRIỂN KHAI HỆ THỐNG CÂN BẰNG TẢI VÀ CHỊU LỖI TRÊN MÔI TRƯỜNG LINUX Cán bộ hướng dẫn: Nguyễn Hồng Việt Sinh viên thực hiện: - Phạm Quốc Đạt - Nguyễn Việt Tiến - Hoàng Quang Thụy Lớp: AT9A HÀ NỘI 2015 HỌC VIỆN KỸ THUẬT MẬT MÃ KHOA CÔNG NGHỆ THÔNG TIN ĐỀ TÀI THỰC TẬP CƠ SỞ TÌM HIỂU VÀ TRIỂN KHAI HỆ THỐNG CÂN BẰNG TẢI VÀ CHỊU LỖI TRÊN MÔI TRƯỜNG LINUX Nhận xét cán bộ hướng dẫn: Điểm chuyên cần: Điểm báo cáo: Xác nhận của cán bộ hướng LỜI MỞ ĐẦU Trong thời đại bùng nổ công nghệ thông tin nay, mạng máy tính đóng vai trò ngày quan trọng hoạt động các doanh nghiệp, tổ chức các quan nhà nước Thậm chí một số đơn vị, chẳng hạn các công ty hàng không ngân hàng lớn, mạng máy tính ví hệ thần kinh điều khiển hoạt động toàn doanh nghiệp Sự ngừng hoạt động mạng máy tính hay hoạt động hiệu mạng máy tính quan làm tê liệt các hoạt động đơn vị, thiệt hại khó lường trước Chúng ta biết các máy chủ trái tim mạng máy tính, máy chủ mạng hỏng, hoạt động hệ thống bị ngưng trệ Điều đáng tiếc dù các hãng sản xuất cố gắng làm cách để nâng cao chất lượng thiết bị, hỏng hóc các thiết bị mạng nói chung các máy chủ nói riêng điều tránh khỏi Do vậy, vấn đề đặt có một giải pháp để đảm bảo cho hệ thống hoạt động tốt có cố xảy máy chủ mạng Việc lựa chọn một server đơn lẻ có cấu hình cực mạnh để đáp ứng nhu cầu kéo theo chi phí đầu tư lớn không giải các vấn đề đặt tổ chức Giải pháp hiệu đưa sử dụng một nhóm server thực một chức điều khiển một công cụ phân phối tải – Giải pháp cân tải Có nhiều hãng đưa giải pháp cân tải Cisco, Coyote, Sun, Microsystem với nhiều tính phong phú Tuy nhiên, bản, nguyên tắc cân tải xuất phát từ quan điểm kỹ thuật khá tương đồng Một kỹ thuật cân tải điển hình RRDNS (Round Robin DNS) Với giải pháp này, một server nhóm bị lỗi RRDNS tiếp tục gửi tải cho server người quản trị mạng phát lỗi tách server khỏi danh sách địa DNS Điều gây đứt quãng dịch vụ Sau phát triển, từ các thuật toán cân tải tĩnh Round Robin, Weighted Round Robin đến các thuật toán cân tải động Least Connection, Weighted Least Connection, Optimized Weighted Least Connection Optimized Weighted Round Robin Kỹ thuật cân tải nhờ kết hợp các thuật toán ngày trở nên hoàn thiện nhược điểm vốn có tạo điểm lỗi đơn bị thắt nút cổ chai sử dụng bộ điều phối tập trung (centralized dispatcher) Ngoài khả áp dụng với Web server, kỹ thuật áp dụng với các hệ server ứng dụng khác SLB không làm nhiệm vụ phân phối tải cho các server mà cung cấp chế đảm bảo hệ thống server khả dụng trước các client SLB không yêu cầu đặc biệt phần cứng, máy tính hợp chuẩn sử dụng làm server Chi phí triển khai nhờ giảm đáng kể Kiến trúc phần mềm phân tán SLB cho phép cung cấp hiệu tính khả dụng kỹ thuật mức cao Chương I.TỔNG QUAN VỀ CÂN BẰNG TẢI Giới thiệu cân tải Cơ sở hạ tầng công nghệ thông tin giữ một nhiệm vụ ngày quan trọng thành công một doanh nghiệp Thị phần,quý khách hàng hài lòng với sản phẩm công ty hình ảnh công ty tất thứ website doanh nghiệp chiếm một phần quan trọng Hệ thống các máy chủ thường xuyên sử dụng để lưu trữ ERP, thương mại điện tử vô số các ứng dụng khác Nền tảng các webiste này, các chiến lược kinh doanh, tính sẵn sàng cao, sở hạ tầng tốt cung cấp hiệu suất cao các giải pháp an toàn khả mở rộng để hỗ trợ tất các ứng dụng Bên cạnh đó, sẵn có các ứng dụng thường bị đe dọa quá tải mạng cố xảy các hệ thống máy chủ các ứng dụng Sử dụng tài nguyên thường cân bằng, dẫn đến các nguồn lực hiệu suất thấp quá tải với các yêu cầu, các nguồn lực hiệu suất cao nhàn rỗi Server Load Balancing (máy chủ cân tải) một giải pháp giúp cân lại các nguồn lực giúp tăng hiệu suất làm việc cho hệ thống mạng doanh nghiệp 1.1 Khái niệm cân tải Cân tải một phương pháp phân phối khối lượng tải nhiều máy tính một cụm máy tính để sử dụng tối ưu các nguồn lức, tối đa hóa thông lượng, giảm thời gian đáp ứng tránh tính trạng quá tải máy chủ Là chế định tuyến các gói tin qua các đường metric Cân tải dùng để chia sẻ liệu truyền mạng giúp cho việc truyền tải thông suốt, không bị nghẽn mạng quá tải hay một cố Hoặc có một máy server bị trục trặc có máy server khác thay để giúp nhận liệu thay cho server bị trục trặc đó, giúp cho việc truyền tải không bị ngừng máy server bị lỗi gây 1.2 Lợi ích cân tải - Tăng khả đáp ứng, tránh tình trạng tải máy chủ, đảm bảo tính linh hoạt mở rộng hệ thống Nhiều ứng dụng chuyên sâu có quy mô lớn, đòi hỏi các máy chủ phải có cân tải cho chạy tốt các ứng dụng Vì cần linh hoạt để triển khai thêm các máy chủ một cách nhanh chóng minh bạch để đáp ứng nhu cầu xử lý công việc Server Load Balancing (máy chủ cân tải) làm cho nhiều máy chủ xuất một máy chủ nhất, một dịch vụ đơn ảo, phân phối các yêu cầu người sử dụng các máy chủ - Tăng độ tin cậy nâng cao hiệu suất hệ thống: Hiệu suất cao đạt sức mạnh xử lý máy chủ sử dụng thông minh Nâng cao cân tải máy chủ trực tiếp yêu cầu dịch vụ người dùng cuối để các máy chủ xử lý công việc đồng khả cung cấp nhanh thời gian để đáp ứng Nhất thiết, các thiết bị cân tải phải có khả xử lý lưu lượng tổng hợp nhiều máy chủ Nếu một thiết bị cân tải máy chủ trở thành một “nút cổ chai” không một giải pháp, một vấn đề bổ sung - Tăng tính sẵn sàng ứng dụng: Nếu một ứng dụng máy chủ không thành công, cân tải tự động phân phối lại yêu cầu dịch vụ người dùng cuối để các máy chủ khác một nhóm các máy chủ tới các máy chủ một địa điểm Máy chủ cân tải có kế hoạch ngăn ngừa cố cho phần mềm bảo trì phần cứng các dịch vụ - Tăng tính bảo mật hệ thống: Khi người dùng gửi yêu cầu dịch vụ đến hệ thống, yêu cầu xử lý bộ cân tải, sau thành phần cân tải chuyển tiếp yêu cầu cho các máy chủ bên Quá trình trả lời cho khách hàng thông qua thành phần cân tải, mà người dùng biết xác các máy chủ bên phương pháp phân tải sử dụng Bằng cách ngăn chặn người dùng giao tiếp trực tiếp với các máy chủ, ẩn các thông tin cấu trúc mạng nội bộ, ngăn ngừa các cuộc công mạng các dịch vụ không liên quan hoạt động các cổng khác 1.3 So sánh hệ thống cân tải server hệ thống thông thường Kịch A Kịch B Tính sẵn sàng cao Có Không Tính mở rộng Có Không Ứng dụng Xử lý đa nhiệm Xử lý nhanh đơn nhiệm Hình 2.1 So sánh hệ thống cân tải server hệ thống thông thường Ưu điểm cân tải: - Tính mở rộng: thêm bỏ bớt server một cách dễ dàng - Tính sẵn sàng cao hệ thống dùng nhiều Server Vì hệ thống có tính dự phòng - Tính quản lý: Theo dõi quản lý tập trung hệ thống Server, bảo dưỡng hệ thống server mà không cần tắt các dịch vụ - Có thể tách các ứng dụng khỏi server - Làm việc với nhiều hệ điều hành - Hiệu suất cao - Server nhóm lại thực đa nhiệm vụ tốt - Tất Server hoạt động công suất tình trạng một Server làm việc quá tải server khác lại “nhàn rỗi” Những tổ chức cần có giải pháp cân tải ? - Các doanh nghiệp - Nhà cung cấp dịch vụ ISP - Trung tâm xử lý liệu - Chính phủ - Phòng thí nghiệm - Trường đại học, viện nghiên cứu… Kỹ thuật cân tải Như biết, bộ cân tải có nhiệm vụ kết nối người dùng server, hoạt động một proxy gateway Một proxy có nhiệm vụ luân chuyển yêu cầu liệu đáp trả người dùng server, một gateway có nhiệm vụ tạo một kết nối hai đối tượng không làm thêm Có thể sử dụng phần cứng phần mềm cài đặt một front server, web server Thêm nữa, số lượng người dùng tăng lên, để tránh SPOF [1], cần thiết phải cài đặt bộ cân tải song song, hoạt động theo chế active-active active-standby 2.1 Kiểm tra trạng thái server Để chọn server phù hợp để gửi request, bộ cân tải cần phải biết server có sẵn Vì vậy, cần phải dùng biện pháp để kiểm tra trạng thái server, chằng hạn gửi lệnh ping, các yêu cầu, thử kết nối hay phương pháp mà người quản trị nghĩ dùng Kỹ thuật kiểm tra thường gọi “health checks” Một server bị down trả lời lệnh ping trả lời các kết nối TCP, một server bị treo có khả trả lời kết nối TCP trả lời các yêu cầu HTTP Khi một ứng dụng web nhiều lớp kích hoạt, một số yêu cầu HTTP trả lời số khác thất bại Chính thế, việc chọn một phương pháp test phù hợp chấp nhận ứng dụng web bộ cân tải thú vị Một số test phải cần truy xuất liệu database nhằm đảm bảo toàn bộ quá trình Hạn chế lớn phương pháp kiểm tra chiếm tài nguyên hệ thống CPU, threads… [1] SPOF(Single point of failure): Một điểm hệ thống mà ngừng hoạt động, toàn bộ hệ thống bị tê liệt Do đó, cân thời gian kiểm tra vấn đề khó kỹ thuật lựa chọn server Khoảng thời gian lần test liên tiếp phải đủ dài để không tốn quá nhiều tài nguyên hệ thống cần đủ ngắn để nhanh chóng phát server “chết” Vì “health checks” một khía cạnh phức tạp kỹ thuật cân tải, nên thường sau một vài kiểm tra, các nhà phát triển ứng dụng thực thi một yêu cầu đặc biệt dành riêng cho bộ cân tải, giúp cho thực một số kiểm tra nội bộ Phần mềm cân tải có khả cung cấp scripting, đạt độ linh hoạt cao Thêm nữa, một kiểm tra đòi hỏi phải chỉnh sửa code, thực một khoảng thời gian ngắn 2.2 Lựa chọn server tốt Phương pháp dễ thường sử dụng các hệ thống nhỏ Round Robin, các server lựa chọn quay vòng, nhiên phương pháp có nhược điểm requests liên tục từ một người dùng vào servers khác nhau, thông tin yêu cầu liên tiếp bị mất, tối ưu hóa sử dụng tài nguyên Đặc biệt cần phải cài đặt kết nối cho các phiên chạy - ví dụ SSL key negociation tốn thời gian Một cách khắc phục nhược điểm sử dụng một hàm băm theo địa IP, requests từ một địa IP vào một server Tuy phương pháp đòi hỏi người dùng phải có IP tĩnh Vậy cách khắc phục cho hạn chế gì? Đó kỹ thuật Persistence 2.3 Kỹ thuật Session Persistence Như đề cập trên, vấn đề cần giải để giữ cho các yêu cầu một người dùng gửi vào một máy suốt phiên làm việc người Tất các yêu cầu người dùng cần phải chuyển vào một server Nếu server bị chết, ngừng để bảo trì, cần phải có chế để chuyển session người dùng sang máy server khác Đó kỹ thuật Session Persistence Có một số giải pháp đưa để tiếp cận kỹ thuật này, chẳng hạn sử dụng một respone HTTP 302 hay tạo liên kết người dùng – server Tuy phương pháp có hạn chế, sử dụng HTTP 302 khiến người dùng luôn tìm cách kết nối với một server nhất, kể server “chết” Dùng cách tạo liên kết đòi hỏi user phải có IP tĩnh suốt phiên làm việc Vậy câu trả lời cuối gì? Đó sử dụng cookie Cookie một đối tượng điều khiển Web Servers Trong kết trả cho người dùng web servers chèn thêm một số thông tin Những yêu cầu người dùng gửi đến server chứa thêm thông tin cookie này, server đọc các cookie biết phải làm với các yêu cầu balance roundrobin cookie JSESSIONID prefix option httpclose option forwardfor option httpchk HEAD /check.php HTTP/1.0 server web1 192.168.72.132:80 cookie A check server web2 192.168.72.133:80 cookie B check … Trong file cấu hình keepalived phải rõ địa listen 192.168.72.1 Vì keepalived cài đặt máy chứa HAProxy nên người dùng truy cập vào IP ảo này, keepalived chuyển hướng yêu cầu đến HAProxy File cấu hình cho keepalived máy chứa HAProxy sau: vrrp_script chk_haproxy { script “killall -0 haproxy” interval weight } vrrp_instance VI_1 { interface eth0 state MASTER virtual_router_id 51 priority 101 virtual_ipaddress { 192.168.72.1 } track_script { chk_haproxy } } # Requires keepalived-1.1.13 # cheaper than pidof # check every seconds # add points of prio if OK Luồng liệu mô tả hình sau: # 101 on master, 100 on backup - Trong cấu hình keepalived, haproxy cài đặt máy 192.168.72.3 (priority = 101) active, bộ cân tải lại backup (priority = 100), bộ active không hoạt động bộ backup thiết đặt priority = 101 trở thành bộ active - Người dùng truy cập website địa 192.168.72.1:80, keepalived chuyển yêu cầu đến cho HAProxy - Cả bộ cân tải gửi các tín hiều kiểm tra chúng từ IP gốc - Nếu yêu cầu không chứa cookie, chuyển đến server phù hợp - Trong liệu trả về, có cookie JSESSIONID, HAProxy chèn thêm tên server vào cookie này, chẳng hạn với cookie “JSESSIONID=123” trả từ server A HAProxy chèn thêm thành “JSESSIONID=A~123” - Nếu người dùng truy cập lại với cookie “JSESSIONID=A~123”, HAProxy chuyển yêu cầu đến server A, tên server A bị xóa khỏi cookie trước chuyển đến server - Nếu server web A bị “chết”, bộ cân tải chuyển yêu cầu đến một server khác cookie chèn lại theo tên server Cài đặt thuật toán cân tải HAProxy Để hỗ trợ trình bày các thuật toán chi tiết, cần phải định nghĩa một số biến cấu trúc chương trình, listener,proxyvà server Con trỏ cấu trúc listener khai báo bộ cân tải nhằm lưu trữ thông tin listener bao gồm listen socket, địa listen một trỏ next đến địa vào NULL Vậy socket gì? Một socket bao gồm địa IP kết hợp với cổng (port) nhằm giúp local DNS xác định đích một ứng dụng chạy máy server Chúng ta biết máy tính giao tiếp mạng có một địa IP dùng để xác định danh tính máy tính Tuy nhiên máy tính lại chạy nhiều ứng dụng khác nhau, giả sử một server cài đặt web-server DNS server, làm cách để người dùng, local DNS biết tương tác với ứng dụng Lúc cần khái niệm cổng, ứng dụng server chạy các port khác Khi người dùng muốn truy cập vào dịch vụ web, gói tin gửi bao gồm địa IP máy server cổng chạy ứng dụng web (thường cổng 80) Ngược lại muốn truy cập vào DNS server, gói tin gửi địa IP cổng 53 struct listener { int fd; struct sockaddr_storage addr; struct listener *next; }; // the listen socket // the address we listen to // next address or NULL Con trỏ cấu trúc server lưu giữ tất các thông tin các server, bao gồm socket (địa IP cổng server đó), các thông số số lượng session tại, số lượng session lớn nhất, số lượng session kết nối, số lượng kết nối chờ để phục vụ, trọng số server lưu giữ thông tin proxy mà thuộc Thêm nữa, lưu thông tin trạng thái server biến “state”, bao gồm nhiều trạng thái khác nhau, chẳng hạn “đang chạy” (running), backup, cần kiểm tra (checked)… struct server { struct server *next; int state; int cklen; char *cookie; char *id; /* server state (SRV_*) */ /* the len of the cookie, to speed up checks */ /* the id set in the cookie */ /* just for identification */ struct list pendconns; /* pending connections */ int nbpend, nbpend_max; /* number of pending connections */ struct task *queue_mgt; /* the task associated to the queue processing */ struct sockaddr_in addr; /* the address to connect to */ struct sockaddr_in source_addr; /* the address to which we want to bind for connect() */ short check_port; /* the port to use for the health checks */ int health; /* 0->rise-1 = bad; rise->rise+fall-1 = good */ int rise, fall; /* time in iterations */ int inter; /* time in milliseconds */ int result; /* = connect OK, -1 = connect KO */ unsigned char uweight, eweight; /* user-specified weight-1, and effective weight-1 */ unsigned int wscore; /* weight score, used during srv map computation */ int cur_sess, cur_sess_max; /* number of currently active sessions (including syn_sent) */ unsigned int cum_sess; /* cumulated number of sessions really sent to this server */ unsigned int maxconn, minconn; /* max # of active sessions (0 = unlimited), min# for dynamic limit */ unsigned failed_checks, down_trans; /* failed checks and up-down transitions */ unsigned failed_conns, failed_resp; /* failed connect() and responses */ unsigned failed_secu; /* blocked responses because of security concerns */ struct proxy *proxy; /* the proxy this server belongs to */ }; Con trỏ cấu trúc proxy lưu giữ thông tin các proxy hoạt động hệ thống Đây một cấu trúc phức tạp, khuôn khổ thuật toán thảo luận đây, quan tâm đến một số biến cần thiết Bao gồm trỏ cấu trúc server “struct server **srv_map” dùng để chứa tập các server mà proxy kết nối tới, tên độ dài cookie (dành để đọc cookie người truy cập gửi đến server trả về), “srv_rr_idx” dùng làm biến đếm để chọn server srv_map theo thuật toán RR struct proxy { struct listener *listen; struct server *srv; /* the listen addresses and sockets */ ……… /* known servers */ int srv_act, srv_bck; int tot_wact, tot_wbck; servers */ struct server **srv_map; weights */ int srv_map_sz; */ char *cookie_name; int cookie_len; only once */ int srv_rr_idx; robin mode */ unsigned int wscore; computation */ ……… } /* # of running servers */ /* total weights of active and backup /* the server map used to apply /* the size of the effective server map /* name of the cookie to look for */ /* strlen(cookie_name), computed /* next server to be elected in round /* weight score, used during srv map Khi Haproxy bắt đầu hoạt động, đọc file cấu hình hệ thống Trong quá trình đọc file cấu hình, Haproxy xác định xem có server, server hoạt động, server backup Cứ server cấp phát một vùng bộ nhớ lưu trữ vào srv_map tùy theo trạng thái curproxy->srv_map = (struct server **)calloc(act, sizeof(struct server *)); Trong curproxy proxy sử dụng Cứ lưu một server vào hệ thống, chương trình vẽ lại đồ server tổng trọng số chúng Việc vẽ lại đồ tính lại tổng trọng số quan trọng, đảm bảo cho thuật toán RR hoạt động các server có trọng số khác static void recount_servers(struct proxy *px){…} static void recalc_server_map(struct proxy *px){…} Cho dù trọng số server bao nhiêu, server đầu tiên lưu vào hệ thống server gọi người dùng lần đầu tiên truy cập Nó đảm bảo trường hợp cần server backup, gọi đến server đầu tiên 2.1 Thuật toán weighted round robin (WRR) Tư tưởng thuật toán WRR phân tải xoay vòng các server Giả sử có server A, B, C với trọng số lần lượt 1, 2, Thuật toán phân tải vào server theo thứ tự ABBCCC Điều định srv_map lưu cấp phát bộ nhớ cho một server lưu vào srv_map Biến srv_rr_idx dùng để chọn server thuật toán Thuật toán RR cài đặt sau: static inline struct server *get_server_rr_with_conns(struct proxy *px) { int newidx; /* Biến dùng để đặt giá trị cho srv_rr_idx sau chọn server */ struct server *srv; /*Kiểm tra kích thước srv_map không, nghĩa không tồn server hoạt động, thuật toán trả null */ if (px->srv_map_sz == 0) return NULL; /*Nếu giá trị srv_rr_idx nhỏ 0, vượt quá kích thước srv_map_sz, nghĩa đến cuối server map cập nhập giá trị cho */ if(px->srv_rr_idx < || px->srv_rr_idx >= px- >srv_map_sz) px->srv_rr_idx = 0; /*Gán giá trị srv_rr_idx cho newidx */ newidx = px->srv_rr_idx; /*Thực vòng lặp lấy server phù hợp lẽ newidx = pr->srv_rr_idx, lấy server thỏa mãn, nhiên cần phải loại trừ trường hợp server đầy, số kết nối lớn số kết nối cho phép */ { srv = px->srv_map[newidx++]; if (!srv->maxconn || srv->cur_sess < srv_dynamic_maxconn(srv)) { px->srv_rr_idx = newidx; return srv; } if (newidx == px->srv_map_sz) newidx = 0; } while (newidx != px->srv_rr_idx); return NULL; } Thuật toán WRR đơn giản chạy khá ổn định phần mềm Haproxy, nhiên có nhược điểm mà khắc phục Thứ nhất, phân phối tải theo hình thức xoay vòng, nên một người dùng đến với website đẩy đến các server khác nhau, điều không nên xảy ra, người dùng đưa vào một server, nghĩa thiết lập kết nối với server đó, tiếp tục làm việc với server các yêu cầu giúp người dùng tải lại một số các đối tượng (chẳng hạn tải yêu cầu trước), nữa, giúp người dùng thực lại việc kết nối server, điều đặc biệt quan trọng web-server có yêu cầu bảo mật, chẳng hạn kiểm tra SSL key Nếu yêu cầu một người dùng đưa vào các server khác nhau, việc kiểm tra liên tục SSL key nhiều thời gian, làm tăng thời gian đáp ứng người dùng Chúng ta khắc phục nhược điểm cách Cách thứ sử dụng cookie nói phần cookie chương Cách thứ sử dụng một hàm băm theo địa IP người dùng Khi bộ cân tải nhận yêu cầu, băm địa IP người dùng Cùng một giá trị băm cho vào server Tuy nhiên phương pháp đòi hỏi người dùngphải có IP tĩnh Nhược điểm thứ phân phối theo kiểu xoay vòng, nên xảy trường hợp một server phải phục vụ nhiều người dùng, server khác lại nhàn rỗi Điều khắc phục cách sử dụng thuật toán Least Connections (LC) 2.2 Thuật toán least connections Như đề cập chương I, thuật toán LC phân tải dựa số kết nối đến với server Mỗi proxy lưu thông tin tất các server Trong server có biến “cur_sess” lưu lại số session active server Chúng ta sử dụng một vòng lặp kiểm tra biến này, lấy server có giá trị cur_sess thấp chia cho trọng số server để gửi yêu cầu Thực vậy, giả sử server A, B có trọng số lần lượt Thuật toán đảm bảo cho số session active B xấp xỉ gấp đôi số session active A, so sánh “số session active / trọng số server” Vì việc kiểm tra số lượng kết nối thực Trong một hệ thống có tải cao, một server có active session nhất, nhận yêu cầu, sau nhận liên tục yêu cầu, số lượng active session chưa kịp cập nhập Vì vậy, thuật toán này, cần tránh phân yêu cầu liên tiếp vào một server (chúng ta xét với toán cookie, nghĩa kết nối đến từ clients khác nhau) Nghĩa server vừa phân tải trở thành server cần tránh lần phân tải Ở sử dụng biến “struct server *srvtoavoid” if(srv != srvtoavoid){ … } Sau chọn server, cập nhập lại giá trị srvtoavoid một biến static Static struct server *pre_server; … Pre_server = t; Dưới hàm thực thi thuật toán least connections: static inline struct server *get_server_lc(struct proxy *px, struct server *srvtoavoid) { int s; /*Sử dụng để lấy số kết nối server dựa trọng số chúng */ struct server *srv, *t; /* Kiểm tra kích thước srv_map không, nghĩa không tồn server hoạt động, thuật toán trả null */ if (px->srv_map_sz == 0) return NULL; t = NULL; s = 10000000; /* Thực tìm server phù hợp, tăng giá trị i chọn server có kết nối dựa biến cur_sess trọng số */ for(srv = px->srv; srv != NULL; srv = srv->next) { if(srv != srvtoavoid) { if (!srv->maxconn || srv->cur_sess < srv_dynamic_maxconn(srv)){ if (s > (srv->cur_sess / srv->eweight ) || t==NULL) { t = srv; s = srv->cur_sess / srv->eweight; } } } } pre_server = t; return t; } 2.3 Một số cải tiến Thuật toán LC trọng vào một biến đếm, số lượng kết nối đến server để thực việc phân tải Tuy nhiên nhiều thông số khác để đo hiệu một server số kết nối Hai server có số kết nối tương đương một server lại phải chịu tải lớn hẳn, các công việc server nặng tải yêu cầu server Thuật toán RR có khả xảy tượng Giả sử một server chạy thấy phải chịu tải quá nặng, tự kiểm tra thông số cách kiểm tra tải CPU, dung lượng RAM sử dụng…Nó gửi một thông báo đến bộ cân tải báo chịu tải quá cao Chúng ta cần thiết kế một chương trình càiđặt server để kiểm tra thông số này, sau gửi bộ cân tải Tại lại cài đặt tích hợp vào bộ cân tải? Vì bộ cân tải không đo tải server, đặc biệt các serverở xa Server gửi một tin nhắn chẳng hạn như: sendmessage( proxy_address, proxy_port, srv_add, srv_port, srvoverload); Bộ cân tải nhận tín hiệu này: getMessage (srv_add, srv_port, srv_load); Nếu tải server lớn một giá trị đó, chẳng hạn 85%, bộ cân tải loại khỏi danh sách các server proxy, phải giữ toàn bộ thông tin proxy thực thuật toán không gửi thêm kết nối đến server này, các nhiệm vụ mà thực làm Do phải khai báo proxy một trỏ cấu trúc server, lưu thông tin các server bịquá tải Thêm vào cấu trúc cần struct server *overload_srv; Đẩy server bị quá tải khỏi tập server for(srv = px->svr; srv!=NULL; svr = srv->next) { //Compare srv id and overload server id if(strcmp(srv->next->id, id)) //overload server { temp = srv->next; srv->next = temp->next; temp->next = NULL; } } Sau cho vào overload_server temp->next = px->overload_srv; px->overload_srv = temp; temp->proxy = px; Khi tải server xuống một giá trị đó, chẳng hạn 50%, cần phải gửi một tin nhắn thông báo tải nhẹ hơn, lại cho vào danh sách các server proxy sendmessage( proxy_address, proxy_port, srv_add, srv_port, srvOK); Quá trình diễn ngược lại so với quá trình Chúng ta đưa server khỏi danh sách các server bị overload thêm vào danh sách các server chạy proxy Vì trường hợp quá tải xảy ra, số lượng thời điểm mà server gửi message cho bộ cân tải không quá nhiều để gây quá tải cho bộ cân tải Ngược lại thuật toán đảm bảo không gửi thêm kết nối đến các server quá tải hệ thống, nhằm tránh trường hợp các server bị treo phải phục vụ quá khả Cấu hình chạy chương trình 3.1 Chuẩn bị Cài đặt ubuntu server Máy – Bộ cân tải OS: Ubuntu IP: 192.168.72.131 Máy – Web Server OS: Ubuntu cài sẵn LAMP Server IP: 192.168.72.132 Máy – Web Server OS: Ubuntu cài sẵn LAMP Server IP: 192.168.72.133 3.2 Cài đặt cấu hình 3.2.1 Cài đặt HAProxy Sử dụng câu lệnh apt-get để cài HAproxy sudo apt-get install haproxy Kiểm tra phiên HAProxy câu lệnh haproxy –v Khởi động HAProxy cách chỉnh sửa init script sudo nano /etc/default/haproxy Sửa giá trị ENABLE thành ENABLE=1 Kiểm tra lại xem tham số init HAProxy chưa service haproxy Bạn thấy dòng usage: /etc/init.d/haproxy {start|stop|reload|restart|status} Lệnh kiểm tra trạng thái HAProxy server haproxy status 3.2.2 Cấu hình HAProxy Sửa tập tin cấu hình sudo nano /etc/haproxy/haproxy.cfg Thêm khối lệnh sau vào cuối tập tin frontend haproxy_in bind *:80 default_backend haproxy_http backend haproxy_http stats enable stats uri /haproxy?stats stats auth admin:admin123 balance roundrobin mode http server :80 check server :80 check Toàn bộ file config hoàn chỉnh global log /dev/log local0 log /dev/log local1 notice chroot /var/lib/haproxy user haproxy group haproxy daemon defaults log global mode http option httplog option dontlognull contimeout 5000 clitimeout 50000 srvtimeout 50000 errorfile 400 /etc/haproxy/errors/400.http errorfile 403 /etc/haproxy/errors/403.http errorfile 408 /etc/haproxy/errors/408.http errorfile 500 /etc/haproxy/errors/500.http errorfile 502 /etc/haproxy/errors/502.http errorfile 503 /etc/haproxy/errors/503.http errorfile 504 /etc/haproxy/errors/504.http frontend haproxy_in bind *:80 default_backend haproxy_http backend haproxy_http stats enable stats uri /haproxy?stats stats auth admin:admin123 balance roundrobin mode http server web1 192.168.72.132:80 check server web2 192.168.72.133:80 check Cần nạp lại HAProxy để cập nhật file cấu hình sudo service haproxy reload 3.3 Thử nghiệm Load Balancing and Failover Để thử nghiệm chức cân tải server, tạo một tập tin index.php đưa vào thư mục web server Sau dùng curl yêu cầu tập tin nhiều lần curl http://192.168.72.131 Server IP thay đổi Ip web server, cách thuật toán Round Robin làm việc Để thử nghiệm chịu lỗi, ta tắt web server sudo service apache2 stop Gửi lại yêu cầu curl để thấy kết Trạng thái server Có thể kiểm tra các thông số server, trạng thái server tại, số lượng kết nối tại, số lượt truy cập địa http://192.168.72.131/haproxy?stats Tính hoạt động đặt “stats enable” file cấu hình Kết thu sau: Một số thông số đáng ý sau: + pid 3093: process id chạy Haproxy máy chủ linux + www frontend, backend webserver server1, server2 + Các thông số kiểm tra server mô tả màu hình vẽ, bao gồm các trạng thái giống cả2 phần backup server active server UP, DOWN, UP and going down, DOWN and going UP + Ở các thông số session tại, các connections hàng đợi, thông lượng Bytes vào, số các yêu cầu bị từ chối, lỗi cảnh báo KẾT LUẬN VÀ ĐỊNH HƯỚNG PHÁT TRIỂN Tổng kết Đề tài đưa các thành phần cần phải xây dựng một bộ cân tải cài đặt một giải pháp phân tải động thông minh hoạt động hiệu so với giải pháp chạy một bộ cân tải mã nguồn mở Trước tiên, đề tài đưa mô hình website với khả mở rộng, từ nhấn mạnh tầm quan trọng việc cân tải cho các web server toàn bộ hệ thống Sử dụng phép so sánh hiệu hệ thống cân tải server hệ thống thông thường, đồng thời sử dụng một bộ cân tải để phân tải cho các web server Một bộ cân tải hoạt động tốt cần phải kiểm tra trạng thái server, nhằm đảm bảo không chuyển yêu cầu người dùng đến server không hoạt động Thuật toán phân tải cần phải xây dựng một cách thông minh nhằm lựa chọn server tốt để phục vụ yêu cầu người dùng Đề tài giới thiệu 12 thuật toán cân tải sử dụng một số sản phẩm cân tải các công ty lớn giới, chia làm nhánh các thuật toán tĩnh các thuật toán động Các thuật toán đòi hỏi lập trình phần mềm tinh vi, mà yêu cầu hỗ trợ các phần cứng Do thời gian nguồn lực có hạn, đề tài chưa thiết kế một bộ cân tải hoàn chỉnh, hi vọng thực một nghiên cứu sâu đề tài Những ý tưởng chưa thực hạn chế thiết kế bộ cân tải xin để dành phần định hướng phát triển Định hướng phát triển Dành thời gian nghiên cứu sâu thiết kế demo hoàn thiện để sát với nhu cầu thực tế Phát triển hệ thống cân tải đồng bộ các server với TÀI LIỆU THAM KHẢO http://tailieu.vn/doc/cong-nghe-can-bang-tai-server-442531.html http://www.vnnic.vn/dns/congnghe/công-nghệ-cân-bằng-tải http://en.wikipedia.org/wiki/Load_balancing_(computing) https://www.digitalocean.com/community/tutorials/how-to-use-haproxy-toset-up-http-load-balancing-on-an-ubuntu-vps https://tunguyenduc.wordpress.com/category/giai-phap-ha/load-balancingweb http://kythuatlaptrinh.com/noi-dung/network-load-balancing-nlb-va-clusterla-gi.html http://luanvan.co/luan-van/de-tai-nhung-nguyen-ly-sang-tao-trong-ung-dungcan-bang-tai-web-cluster-synchronization-51717 http://doc.edu.vn/tai-lieu/do-an-can-bang-tai-cho-cac-he-webserver-lon-vadam-bao-scalability-54089 http://luanvan.net.vn/luan-van/de-tai-tim-hieu-ky-thuat-can-bang-tai-fileserver-59503 [...]... tra 2 bộ cân bằng tải Quay trở lại với mô hình chúng ta đang cài đặt Với keepalived, 2 bộ cân bằng tải sẽ hoạt động theo cơ chế active-backup, người dùng sẽ truy cập vào địa chỉ IP ảo 192.168.72.1 và được chuyển hướng vào bộ cân bằng tải active 192.168.72.3 Từ đó yêu cầu sẽ được cân bằng tải vào một trong các server Nếu bộ cân bằng tải này bị “chết”, keepalived sẽ chuyển bộ cân bằng tải ở địa... Bộ cân bằng tải ghi đè một cookie Ưu điểm của phương pháp này là tránh cho bộ cân bằng tải làm việc quá mức và tránh cho gói tin bị chia nhỏ Bên cạnh đó nó cũng khắc phục được nhược điểm của phương pháp cookie-read Nó là phương pháp tốt nhất trong 3 phương pháp đã được đề cập ở trên và thường được chọn để dùng trong các bộ cân bằng tải 2.5 Cân bằng tải sử dụng phần cứng Bộ cân bằng tải bằng. .. các server hiện thời II CÀI ĐẶT THỰC NGHIỆM VÀ ĐÁNH GIÁ HỆ THỐNG 1 Các phương pháp cài đặt bộ cân bằng tải vào hệ thống Trong phần này, nhóm xin trình bày một số phương pháp cài đặt bộ cân bằng tải vào hệ thống website Có nhiều phương pháp từ đơn giản đến phức tạp, ứng dụng trong nhiều trường hợp khác nhau Với một số website nhỏ, chỉ có một vài server đặt trong cùng mạng LAN, chúng ta có... pháp cài đặt đơn giản với một bộ cân bằng tải cài đặt trước các server, kết hợp với kỹ thuật cookie-insert Trong một hệ thống lớn hơn, để tránh quá tải cho bộ cân bằng tải, chúng ta có thể cài đặt 2 bộ cân bằng tải hoạt động theo cơ chế active-backup, nhằm đảm bảo nếu như 1 trong 2 bộ cân bằng tải bị “chết”, vẫn còn có một bộ dự phòng, để chắc chắn rằng hệ thống luôn hoạt động Kết hợp với... ở hai máy trong cùng mạng LAN với bộ cân bằng tải, đều phục vụ trên cổng 80 và đều chứa cookie Tuy hoạt động khá hiệu quả nhưng tính tùy biến và khả năng hỗ trợ người phát triển của HAProxy rất kém, phần mềm được viết bằng ngôn ngữ lập trình C trên hệ điều hành GNU /Linux, biên dịch bằng bộ thư viện mã nguồn mở GNU Ở đây chúng tôi phát triển HAProxy trên hệ điều hành Ubuntu 1.2 Cài đặt đơn giản... tâm hong toàn bộ hệ thống sẽ ngưng hoạt động do đó tính chịu lỗi thấp Tóm lại, kỹ thuật xử lý các yêu cầu kết nối tập trung rõ ràng đã giải quyết được vấn đề cân bằng tải trên mạng Tuy nhiên kỹ thuật này có tính chịu lỗi thấp và chi phí cao 3 Các thuật toán cân bằng tải 3.1 Thuật toán ngẫu nhiên (random) Trong thuật toán random, tải sẽ được phân phối một cách ngẫu nhiên vào trong các web... với 2 bộ cân bằng tải chia sẻ 1 IP ảo Sẽ có 2 bộ cân bằng tải được cài đặt tại các máy ở địa chỉ 192.168.72.3 và 192.168.72.4 Các web server và database server được cài ở các máy trong cùng mạng LAN Lúc này 2 bộ cân bằng tải sẽ cùng chia sẽ một IP ảo 192.168.72.1, người dùng sẽ truy cập website ở địa chỉ IP ảo này và họ chỉ cần biết đến nó Vậy làm cách nào để cho 2 bộ cân bằng tải có thể... bộ cân bằng tải, xin trình bày sơ qua về các tính năng của HAProxy 1.1 Bộ cân bằng tải HAProxy HAProxy là một giải pháp cân bằng tải với khả năng mở rộng cao, được cài đặt cho những website chạy các ứng dụng dựa trên TCP và HTTP HAProxy là một giải pháp mã nguồn mở được phát triển trên hệ điều hành Linux có thể cân bằng tải cho bất kỳ dịch vụ TCP nào Trong phiên bản mới nhất, HAProxy chuyển mạch... một ứng dụng cho phép 2 bộ cân bằng tải cài đặt cùng với nó hoạt động theo cơ chế active/backup, nếu bộ cân bằng tải master bị “chết” thì bộ cân bằng tải còn lại sẽ thực hiện nhiệm vụ cân bằng Được thiết kế dành riêng cho các dự án Linux Virtual Server (www .linux- vs.org), keepalived có khả năng kiểm tra các server trong cụm, nhận biết các server không hoạt động và loại bỏ chúng ra khỏi cụm... một số hình thức cài đặt cookie và sử dụng các luật ngữ cảnh (content rules) theo yêu cầu của từng website khác nhau Để thấy được mô hình cài đặt một cách tốt nhất, nhóm dùng một bộ cân bằng tải mã nguồn mở có sẵn để làm mô hình Bộ cân bằng tải có tên là HAProxy có đầy đủ chức năng của một bộ cân bằng tải đơn giản Trước khi đi vào chi tiết cài đặt bộ cân bằng tải, xin trình bày sơ qua về các

Ngày đăng: 26/06/2016, 13:08

Từ khóa liên quan

Mục lục

  • LỜI MỞ ĐẦU

  • Chương I.TỔNG QUAN VỀ CÂN BẰNG TẢI

    • 1. Giới thiệu cân bằng tải

      • 1.1. Khái niệm cân bằng tải

      • 1.2. Lợi ích cân bằng tải

      • 1.3. So sánh hệ thống cân bằng tải server và hệ thống thông thường

      • 2. Kỹ thuật cân bằng tải

        • 2.1. Kiểm tra trạng thái server

        • 2.2. Lựa chọn server tốt nhất

        • 2.3. Kỹ thuật Session Persistence

        • 2.4. Cookie

        • 2.5. Cân bằng tải sử dụng phần cứng

        • 2.6. Cân bằng tải sử dụng phần mềm

        • 2.7. Cân bằng tải với proxy

        • 2.8. Cân bằng tải với thiết bị kết nối

        • 2.9. Xử lý các yêu cầu kết nối tập trung

        • 3. Các thuật toán cân bằng tải

          • 3.1. Thuật toán ngẫu nhiên (random)

          • 3.2. Thuật toán Round Robin (RR)

          • 3.3. Thuật toán Weighted Round Robin (Ratio)

          • 3.4. Thuật toán Dynamic Round Robin (DRR)

          • 3.5. Thuật toán Fastest

          • 3.6. Thuật toán Least Connections (LC)

          • 3.7. Thuật toán Observed

Tài liệu cùng người dùng

Tài liệu liên quan