2.2.2.1 Thuật toán Round Robin (RR) a) Ý tưởng
RR là thuật toán đƣợc dùng thƣờng xuyên nhất trong các hệ thống vừa và nhỏ, có ít đòi hỏi về khả năng mở rộng. Một kết nối mới sẽ đƣợc gửi đến server kế tiếp trong cụm server, và cứ quay vòng nhƣ vậy. RR làm việc tốt trong mọi cấu hình, nhƣng sẽ tốt hơn nếu nhƣ các trang thiết bị đang đƣợc cân bằng tải khác nhau về tốc độ xử lý, tốt độ kết nối hoặc bộ nhớ.
Số hóa bởi Trung tâm Học liệu 40 http://www.lrc-tnu.edu.vn/
Một cách để thực thi thuật toán này là sử dụng một server_map. Bộ cân bằng tải sẽ đƣợc khai báo nhƣ một con trỏ proxy, nó sẽ có biến server_map là một mảng các server và biến srv_rr_idx để chỉ định server tiếp theo trong chu kỳ round robin.
b) Thuật toán
Input: hiệu năng sử dụng của máy ảo, số máy ảo trên mỗi server Output: quyết định di chuyển máy ảo sang server mới
Số hóa bởi Trung tâm Học liệu 41 http://www.lrc-tnu.edu.vn/
Sơ đồ khối của thuật toán nhƣ sau:
Bắt đầu
Kiểm tra server_map
dồn ghép máy ảo sang server mới
Kiểm tra server trống Tắt server Kết thúc thỏa đk thỏa đk không trống
Số hóa bởi Trung tâm Học liệu 42 http://www.lrc-tnu.edu.vn/
c) Cài đặt
/* Kiểm tra xem có server nào sẵn có không bằng cách kiểm tra kích thƣớc server_map */
if(srv_map_size = 0) return NULL;
if (srv_rr_idx > proxy->srv_map_size)
/* Nếu đến cuối mảng srv_map, update lại giá trị srv_rr_idx */
srv_rr_idx = 0;
int newidx = px->srv_rr_idx; do {
srv = proxy ->srv_map[newidx++];
/* Trả về server và update lại giá trị srv_rr_idx */
return srv;
proxy->srv_rr_idx = newidx;
} while (newidx != px->srv_rr_idx)
/* Thực hiện cho đến khi lấy đƣợc server tiếp theo */
RR hoạt động tốt khi các server có khả năng xử lý (cấu hình) tƣơng tự nhau, tuy nhiên sẽ có hiện tƣợng mất cân bằng khi các server có cấu hình khác nhau, hoặc sau một thời gian, số kết nối đang hoạt động ở một server đang nhiều hơn hẳn một server khác, nhƣng lƣợng kết nối tiếp theo mà các server này nhận đƣợc vẫn bằng nhau. Do đó một số server sẽ phải xử lý nhiều hơn hẳn các server khác. Tuy vậy, vì tính đơn giản của nó, nên nó hoạt động rất hiệu quả (không phải mất thêm thời gian tính toán các thông số khác nên việc phân tải diễn ra rất nhanh). Nếu các server hoạt động bình thƣờng và không xảy ra sự cố thì sử dụng RR rất tốt.
Điểm yếu của RR là 2 yêu cầu liên tục từ phía một ngƣời dùng có thể sẽ đƣợc gửi vào 2 server khác nhau. Điều này không tốt vì khi ngƣời dùng đang đƣợc kết nối vào một server, thông tin mà họ cần đang ở server đó, nếu kết nối tiếp theo vẫn đƣợc server đó xử lý thì sẽ góp phần tăng tốc độ đáp ứng cho ngƣời dùng. Do đó thuật toán RR thƣờng đƣợc cài đặt cùng với các phƣơng pháp duy trì session nhƣ sử dụng cookie.
2.2.2.2 Thuật toán Weighted Round Robin (Ratio) a) Ý tưởng
Số hóa bởi Trung tâm Học liệu 43 http://www.lrc-tnu.edu.vn/
Nguyên lý hoạt động của thuật toán WRR cũng giống nhƣ thuật toán RR, yêu cầu từ phía ngƣời dùng sẽ đƣợc bộ cân bằng tải chuyển đến các server theo thứ tự xoay vòng. Sự khác biệt duy nhất ở đây là thuật toán WRR còn quan tâm đến khả năng xử lý (cấu hình) của các server. Trong cùng một chu kỳ, 1 server có khả năng xử lý gấp đôi server khác sẽ nhận đƣợc gấp đôi số yêu cầu từ phía bộ cân bằng tải.
Giả sử chúng ta có 4 server A, B, C, D có cấu hình khác nhau, A và B có cấu hình giống nhau, C và D có cấu hình mạnh gấp đôi A. Vậy chúng ta có thể đánh trọng số cho A và B là 1, C và D là 2. Khi đó theo thuật toán WRR, thứ tự server nhận yêu cầu từ phía bộ cân bằng tải sẽ là ABCDCD.
Thuật toán này có thể đƣợc thực thi nhƣ sau: Giả sử chúng ta một hàng đợi để chứa các server sẽ nhận request. Nếu nhƣ 1 server trọng số n, trong hàng đợi sẽ có n chỉ mục (entry) của cùng 1 server này, chẳng hạn nhƣ ở ví dụ trên, mỗi server A, B sẽ có 1 chỉ mục, mỗi server C, D sẽ có 2 chỉ mục. Với cách lƣu chỉ mục nhƣ vậy trong hàng đợi, các server trong WRR sẽ đƣợc lấy ra theo thứ tự hoàn toàn giống nhƣ RR.
Thuật toán WRR hoạt động tốt hơn RR khi các server trong cluster có cấu hình khác nhau. Tuy nhiên sử dụng thuật toán này có thể dẫn tới sự mất cân bằng tải động nếu nhƣ tải của các yêu liên tục thay đổi trong một khoảng rộng (ví dụ nhƣ các yêu cầu xem video hoặc tải các file có dung lƣợng lớn xen kẽ với các yêu cầu đọc thông tin...). Trong một khoảng thời gian ngắn, hoàn toàn có khả năng phần lớn các yêu cầu có tải cao sẽ đƣợc chuyển hƣớng đến cùng một server.
b) Thuật toán
Input: danh sách máy ảo trên mỗi server, danh sách server Output: khởi tạo máy ảo trên server đƣợc lựa chọn
Số hóa bởi Trung tâm Học liệu 44 http://www.lrc-tnu.edu.vn/
Sơ đồ khối của thuật toán nhƣ sau:
Bắt đầu
Kiểm tra server_map
Khởi tạo máy ảo
Kiểm tra server trống Kết thúc Gán chỉ số cho server thỏa đk đúng sai
Số hóa bởi Trung tâm Học liệu 45 http://www.lrc-tnu.edu.vn/
c) Cài đặt
Giả sử nhƣ chúng ta có 3 server A, B, C với trọng số lần lƣợt là 1, 2, 3. Thuật toán sẽ phân tải vào server theo thứ tự ABBCCC. Điều này đƣợc chỉ định trong srv_map khi chúng ta lƣu cấp phát bộ nhớ cho một server mới và lƣu nó vào srv_map. Biến srv_rr_idx đƣợc dùng để chọn server tiếp theo trong thuật toán.
Thuật toán RR đƣợc cài đặt nhƣ sau:
static inline struct server
*get_server_rr_with_conns(struct proxy *px) {
int newidx;
/* Biến này dùng để đặt giá trị mới cho srv_rr_idx sau khi chọn được server */
struct server *srv;
/*Kiểm tra nếu kích thước của srv_map bằng không, nghĩa là không tồn tại server nào đang hoạt động, thuật toán trả về null */
if (px->srv_map_sz == 0)
return NULL;
/*Nếu như giá trị của srv_rr_idx nhỏ hơn 0, hoặc vượt quá kích thước srv_map_sz, nghĩa là đã đi đến cuối server map chúng ta sẽ cập nhập giá trị cho nó bằng 0 */
if(px->srv_rr_idx < 0 || px->srv_rr_idx >= px- >srv_map_sz)
px->srv_rr_idx = 0;
/*Gán giá trị của srv_rr_idx cho newidx */
newidx = px->srv_rr_idx;
/*Thực hiện vòng lặp cho đến khi lấy được server phù hợp lẽ ra ở đây vì newidx = pr->srv_rr_idx, chúng ta sẽ lấy được luôn server thỏa mãn, tuy nhiên cần phải loại trừ trường hợp server đó đã đầy, hoặc số kết nối hiện tại lớn hơn số kết nối cho phép */
do { 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 và chạy khá ổn định trong phần mềm Haproxy, tuy nhiên nó cũng có những nhƣợc điểm mà không thể khắc phục đƣợc.
Số hóa bởi Trung tâm Học liệu 46 http://www.lrc-tnu.edu.vn/
Thứ nhất, vì nó 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 có thể đƣợc đẩy đến các server khác nhau, điều này là không nên xảy ra, vì khi ngƣời dùng đã đƣợc đƣa vào một server, nghĩa đã đƣợc thiết lập kết nối với server đó, tiếp tục làm việc với server này ở các yêu cầu tiếp theo sẽ giúp ngƣời dùng không phải tải lại một số các đối tƣợng (chẳng hạn nhƣ đã đƣợc tải về ở yêu cầu trƣớc), hơn nữa, sẽ giúp ngƣời dùng không phải thực hiện lại việc kết nối server, điều này đặc biệt quan trọng khi web-server có yêu cầu về bảo mật, chẳng hạn nhƣ kiểm tra SSL key. Nếu yêu cầu của một ngƣời dùng đƣợc đƣa vào các server khác nhau, việc kiểm tra liên tục SSL key sẽ mất rất nhiều thời gian, làm tăng thời gian đáp ứng ngƣời dùng.
Chúng ta có thể khắc phục nhƣợc điểm này bằng 2 cách. Cách thứ nhất là sử dụng cookie nhƣ đã nói ở phần cookie của chƣơng 2. Cách thứ 2 là sử dụng một hàm băm theo địa chỉ IP của ngƣời dùng. Khi bộ cân bằng tải nhận yêu cầu, nó sẽ băm địa chỉ IP của ngƣời dùng. Cùng một giá trị băm sẽ đƣợc cho vào 1 server. Tuy nhiên phƣơng pháp này đòi hỏi ngƣời dùng phải có IP tĩnh.
Nhƣợc điểm thứ 2 là vì phân phối theo kiểu xoay vòng, nên có thể sẽ xảy ra trƣờng hợp một server phải phục vụ rất nhiều ngƣời dùng, trong khi server khác lại nhàn rỗi. Điều này có thể khắc phục bằng cách sử dụng thuật toán Least Connections (LC)
2.2.2.3 Thuật toán Least Connections (LC) a) Ý tưởng
Trong thuật toán LC, yêu cầu từ phía ngƣời dùng sẽ đƣợc chuyển vào server có ít kết nối nhất trong hệ thống tại thời điểm đó. Thuật toán này đƣợc coi nhƣ thuật toán động, vì nó cần phải đếm số kết nối "đang hoạt động" của các server. Với một hệ thống có các server gần giống nhau về cấu hình, LC có khả năng hoạt động tốt ngay cả khi tải của các kết nối biến thiên trong một khoảng lớn. Do đó sử dụng LC sẽ khắc phục đƣợc nhƣợc điểm của RR.
Giả sử chúng ta có n server Si, i = 1, 2,...n. Số lƣợng connections đang hoạt động là Ci với i = (1, 2,...,n). ALL_CONNECTIONS là tổng Ci.
Yêu cầu tiếp theo sẽ đƣợc chuyển đến server j, trong đó:
Số hóa bởi Trung tâm Học liệu 47 http://www.lrc-tnu.edu.vn/
i = (1, 2,...,n).
Vì giá trị ALL_CONNECTIONS là không đổi tại thời điểm tính nên chúng ta có thể chọn server Cj theo công thức:
Cj = min {Ci}, i = (1, 2,...,n).
Nhìn bên ngoài có vẻ nhƣ LC cũng có khả năng hoạt động tốt khi các server có cấu hình biến thiên khác nhau, trên thực tế điều đó là không đúng. Vậy thì nguyên nhân ở đâu? Đó chính là do trạng thái TIME_WAIT của TCP. TIME_WAIT này thƣờng đƣợc đặt là 2 phút, trong 2 phút đó một website "bận rộn" có thể nhận tới hàng chục ngàn kết nối liên tục, giả sử nhƣ server A có khả năng xử lý gấp đôi server B, server A đang xử lý hàng ngàn yêu cầu và giữ những yêu cầu này trong trạng thái TIME_WAIT của TCP, trong khi đó server cũng phải xử lý hàng ngàn yêu cầu nhƣ server A, nhƣng vì cấu hình server B yếu hơn nên sẽ chậm chạp hơn rất nhiều. Nhƣ vậy, thuật toán LC hoạt động không tốt khi các server có cấu hình khác nhau.
b) Thuật toán
Input: danh sách kết nối hiện tại, danh sách các server Output: khởi tạo máy ảo trên server đƣợc lựa chọn
Số hóa bởi Trung tâm Học liệu 48 http://www.lrc-tnu.edu.vn/
Sơ đồ khối của thuật toán nhƣ sau:
Bắt đầu
Kiểm tra server_map
Khởi tạo máy ảo
Kiểm tra server trống
Kết thúc sắp xếp danh sách server theo ds kết nôi
thỏa đk
đúng
Số hóa bởi Trung tâm Học liệu 49 http://www.lrc-tnu.edu.vn/
c) Cài đặt
giả sử 2 server A, B có trọng số lần lƣợt là 1 và 2. Thuật toán sẽ đảm bảo cho số session active ở B luôn xấp xỉ gấp đôi số session active ở A, vì chúng ta đang so sánh ―số session active / trọng số server‖.
Vì việc kiểm tra số lƣợng kết nối không phải đƣợc thực hiện ngay lập tức. Trong một hệ thống có tải cao, nếu một server là đang có ít active session nhất, nó sẽ nhận đƣợc yêu cầu, sau đó nó sẽ nhận đƣợc liên tục yêu cầu, do số lƣợng active session chƣa kịp cập nhập. Vì vậy, trong thuật toán này, chúng ta cần tránh phân 2 yêu cầu liên tiếp vào cùng một server (chúng ta đang xét với bài toán không có cookie, nghĩa là 2 kết nối đến từ 2 clients khác nhau). Nghĩa là server vừa đƣợc phân tải sẽ trở thành server cần tránh trong lần phân tải tiếp theo. Ở đây chúng ta sử dụng biến ―struct server *srvtoavoid‖.
if(srv != srvtoavoid){ …
}
Sau khi chọn đƣợc server, chúng ta sẽ cập nhập lại giá trị srvtoavoid bằng một biến static
Static struct server *pre_server; …
Pre_server = t;
Dƣới đây là 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 ít nhất của mỗi server dựa trên trọng số của chúng */
struct server *srv, *t;
/* Kiểm tra nếu kích thước của srv_map bằng không, nghĩa là không tồn tại server nào đang hoạt động, thuật toán trả về null */
if (px->srv_map_sz == 0) return NULL;
Số hóa bởi Trung tâm Học liệu 50 http://www.lrc-tnu.edu.vn/
t = NULL; s = 10000000;
/* Thực hiện cho đến khi tìm được server phù hợp, tăng giá trị i và chọn server nào có ít kết nối nhất dựa trên biến cur_sess và 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 LẬP LỊCH CÔNG VIỆC
Bộ lập lịch công việc HTC Condor [7] đƣợc thiết kế để quản lý các công việc ƣu tiên và lập kế hoạch. Nhƣ đã đề cập, Cloud Scheduler có thể ảnh hƣởng đến việc lập kế hoạch công việc của Condor. Ví dụ, hãy xem xét hai việc xếp hàng đợi, công việc đệ trình đầu tiên đòi hỏi một máy ảo có kiểu là VM-A, và một công việc đƣợc yêu cầu thứ hai đòi hỏi một máy ảo có kiểu là VM-B. Nếu Cloud Scheduler bắt đầu lần đầu tiên với VM-B (giả sử các nguồn tài nguyên để khởi động máy ảo VM-B đã có sẵn), sau đó công việc VM-B sẽ chạy trƣớc khi công việc VM-A đƣợc yêu cầu.
Cloud Scheduler có thể đƣợc cấu hình để đƣa làm cho các tài khoản ngƣời dùng cân bằng về tài nguyên và đảm bảo tính ƣu tiên sử dụng. Hiện nay, Cloud
Số hóa bởi Trung tâm Học liệu 51 http://www.lrc-tnu.edu.vn/
Scheduler sẽ bắt đầu với nhiều máy ảo cùng với các nguồn tài nguyên sẵn có trên hệ thống. Các máy ảo đƣợc cung cấp đồng đều đến tất cả ngƣời sử dụng với các công việc trong hàng đợi.
Cloud Scheduler tái cân bằng cung cấp máy ảo bằng cách tắt các máy ảo đã đƣợc cung cấp và khởi động các máy ảo khác đƣợc cấp.
Ví dụ, một ngƣời sử dụng sẽ nhận đƣợc cấp phát đầy đủ của máy ảo Mây Scheduler, nhƣng một khi ngƣời dùng thứ hai trình công việc, một nửa số ngƣời sử dụng máy ảo đầu tiên sẽ đƣợc đóng cửa để các nguồn tài nguyên miễn phí cho ngƣời sử dụng thứ hai.
Cloud Scheduler có thể tái cân bằng cung cấp máy ảo bằng cách tắt máy ảo một cách từ từ hoặc bằng cách ngay lập tức. Khi cấu hình để tắt máy từ từ, Cloud Scheduler chuyển tình trạng của Condor sang cấp phát chính thức, và yêu cầu các máy ảo trên phân bổ cho một nhóm khác. Khi Cloud Scheduler đƣợc cấu hình để tắt máy ngay lập tức, các máy ảo sẽ tắt máy ngay lập tức mà không cần chờ đợi cho công việc để kết thúc. Nếu một máy ảo đƣợc tắt trong khi công việc đang chạy, bộ lập trình công việc HTC Condor sẽ lập lịch lại cho công việc đó và đƣa nó vào hàng đợi để chờ thực hiện.
2.3.1Thuật toán Lập lịch dựa trên Cân bằng tải
a) Ý tưởng
Tải của máy ảo đƣợc thể hiện qua thời gian thực thi dự đoán của nhiệm vụ chạy trên máy ảo, gọi là Vli. Và tải của host đƣợc biểu diễn bởi tải trung bình của máy ảo chạy trên nó, gọi là HLi , ta có HLi = 1
n j j
VL
n trong đó n là số máy ảo chạy trên host.
Từ HLi, giá trị tải trung bình avgl và giá trị đánh giá cân bằng tải B của môi