Kỹ thuật cân bằng tải mạng (NLB network load balancing)

TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI
VIỆN CÔNG NGHỆ THÔNG TIN

Môn thiết bị truyền thông và mạng
Đề tài:Load Balancing

Giảng viện hướng dẫn: PGS.TS Ngô Hồng Sơn
Nhóm 3

Load Blancing

1


Mục lục

1. Giới thiệu chung
Hiện nay, khi nhu cầu truy nhập mạng bùng nổ, các server cung cấp dịch
vụ đang trở nên quá tải. 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 này sẽ kéo theo chi phí đầu tư rất lớn. Giải pháp
hiệu quả được đưa ra là sử dụng một nhóm server cùng thực hiện một chức
nǎng dưới sự điều khiển của một công cụ phân phối tải - Giải pháp cân bằng
tải.
Có rất nhiều hãng đưa ra giải pháp cân bằng tải như Cisco, Coyote Point,
Sun Microsystems... với rất nhiều tính nǎng phong phú. Tuy nhiên, về cơ
bản, nguyên tắc cân bằng tải vẫn xuất phát từ những quan điểm kỹ thuật khá
tương đồng. Một kỹ thuật cân bằng tải điển hình là RRDNS (Round Robin
DNS). Với giải pháp này, nếu một server trong nhóm bị lỗi, RRDNS sẽ vẫn
tiếp tục gửi tải cho server đó cho đến khi người quản trị mạng phát hiện ra
lỗi và tách server này ra khỏi danh sách địa chỉ DNS. Điều này sẽ gây ra sự
đứt quãng dịch vụ. Sau những phát triển, từ các thuật toán cân bằng tải tĩnh

như Round Robin, Weighted Round Robin đến các thuật toán cân bằng tải
động như Least Connection, Weighted Least Connection, Optimized
Weighted Round Robin và Optimized Weighted Least Connection, kỹ thuật
cân bằng tải hiện nay nhờ sự kết hợp các thuật toán trên ngày càng trở nên
hoàn thiện mặc dù nhược điểm vốn có như tạo điểm lỗi đơn và vấn đề nút cổ
chai do sử dụng bộ điều phối tập trung (centralized dispatcher) vẫn còn.
Trong phần báo cáo này nhóm chúng tôi xin giới thiệu một giải pháp mà
Microsoft sử dụng cho các webserver, đó là kỹ thuật cân bằng tải mạng
(NLB - Network Load Balancing).
Load Blancing

2


2.Khái niệm
Server đang là nền tảng phân phối các ứng dụng quan trọng, thường
xuyên và rộng khắp như Web, Streaming media, VPN. Như một phần tích
hợp của Windows Advanced Server và Datacenter Server, Network Load
Balancing (NLB) cung cấp một giải pháp lý tưởng, kinh tế để tăng cường
tính khả mở và khả dụng cho các ứng dụng trên cả môi trường Internet và
intranet.
NLB mở rộng hiệu năng của các server ứng dụng, chẳng hạn như Web
server, nhờ phân phối các yêu cầu của client cho các server trong nhóm
(cluster). Các server (hay còn gọi là host) đều nhận gói IP đến, nhưng gói chỉ
được xử lý bởi một server nhất định.
Các host trong nhóm sẽ đồng thời đáp ứng các yêu cầu khác nhau của các
client, cho dù một client có thể đưa ra nhiều yêu cầu. Ví dụ, một trình duyệt
Web cần rất nhiều hình ảnh trên một trang Web được lưu trữ tại nhiều host
khác nhau trong một nhóm server. Với kỹ thuật cân bằng tải, quá trình xử lý
và thời gian đáp ứng client sẽ nhanh hơn nhiều.

Mỗi host trong nhóm có thể định ra mức tải mà nó sẽ xử lý hoặc tải có
thể phân phối một cách đồng đều giữa các host. Nhờ sử dụng việc phân
phối này, mỗi server sẽ lựa chọn và xử lý một phần tải của host. Tải do các
Load Blancing

3


client gửi đến được phân phối sao cho mỗi server nhận được số lượng các
yêu cầu theo đúng phần tải đã định của nó.
Sự cân bằng tải này có thể điều chỉnh động khi các host tham gia vào
hoặc rời khỏi nhóm. Đối với các ứng dụng như Web Server, có rất nhiều
client và thời gian mà các yêu cầu của client tồn tại tương đối ngắn, khả
năng của kỹ thuật này nhằm phân phối tải thông qua ánh xạ thống kê sẽ giúp
cân bằng một cách hiệu quả các tải và cung cấp khả năng đáp ứng nhanh khi
nhóm server có thay đổi.
Các server trong nhóm cân bằng tải phát đi một bản tin đặc biệt thông
báo trạng thái hoạt động của nó (gọi là heartbeat message) tới các host khác
trong nhóm đồng thời nghe bản tin này từ các khác host khác. Nếu một
server trong nhóm gặp trục trặc, các host khác sẽ điều chỉnh và tái phân phối
lại tải để duy trì liên tục các dịch vụ cho các client.
Trong phần lớn các trường hợp, phần mềm client thường tự động kết nối lại
và người sử dụng chỉ cảm thấy trễ một vài giây khi nhận được đáp ứng trả
lời.
3.Các lợi ích của Cân Bằng Tải
a. Tối đa hoá Uptime
Cân Bằng Tải giúp dàn trải lưu lượng truy cập và truy xuất giữa hai
hoặc nhiều máy chủ. Trong trường hợp lỗi sự cố xảy ra tại một điểm máy
chủ, Cân Bằng Tải sẽ phát hiện vấn đề và di chuyển lưu lượng truy cập đến

các máy chủ online còn lại, dịch vụ cho người dùng sẽ không bị gián đoạn.
Cơ chế Cân Bằng Tải của Long Vân Datacenter rất linh động, được
thiết kế để tự động xử lý sự cố. Nếu Cân Bằng Tải thất bại, hệ thống quản lý
dự phòng sẽ xử lý lỗi trong khi vẫn duy trì hoạt động cùng IP ảo (VIP) để
giảm thiểu gián đoạn hoạt động.
b. Giúp Datacenter linh hoạt trong mở rộng
Khi khách hàng có nhu cầu mở rộng hệ thống Datacenter, Cân Bằng
Tải sẽ tự động điều phối giữa các máy chủ cũ và mới để xử lý các yêu cầu
dịch vụ mà không làm gián đoạn quá trình hoạt động, xử lý. Khách hàng sẽ
chủ động hơn rất nhiều trong công việc nhờ cơ chế Cân Bằng Tải của Long
Vân Datacenter.

Load Blancing

4


c. Tăng tính bảo mật cho Datacenter
Thông thường khi người dùng gửi yêu cầu dịch vụ lên hệ thống sẽ
được Cân Bằng Tải tiếp nhận rồi mới phân chia cho các máy chủ bên trong
xử lý. Quá trình phản hồi yêu cầu cũng thông qua thành phần Cân Bằng Tải.
Bằng cách đó có thể ngăn chặn người dùng giao tiếp trực tiếp với các máy
chủ, ẩn đi các thông tin và cấu trúc mạng nội bộ, ngăn ngừa luôn các cuộc
tấn công trên mạng hoặc truy cập trái phép.

4.Kiến trúc hệ thống cân bằng tải
Để tối đa hoá thông lượng và độ khả dụng, công nghệ cân bằng tải sử
dụng kiến trúc phần mềm phân tán hoàn toàn, trình điều khiển cân bằng tải
Load Blancing

5


được cài đặt và chạy song song trên tất cả các host trong nhóm. Trình điều
khiển này sắp xếp tất cả các host trong nhóm vào một mạng con để phát hiện
đồng thời lưu lượng mạng đến địa chỉ IP chính của nhóm (và các địa chỉ bổ
sung của các host ở nhiều vị trí khác nhau).
Trên mỗi host, trình điều khiển hoạt động như một bộ lọc giữa trình điều
khiển card mạng và chồng giao thức TCP/IP, cho phép một phần lưu lượng
mạng đến được nhận bởi host đó. Nhờ đó, các yêu cầu của client sẽ được
phân vùng và cân bằng tải giữa các host trong nhóm.
Hệ thống cân bằng tải chạy như một trình điều khiển mạng (về mặt
logic) nằm dưới các giao thức lớp ứng dụng như HTTP hay FTP. Kiến trúc
này tối đa hoá dung lượng nhờ việc sử dụng mạng quảng bá để phân phối
lưu lượng mạng đến tất cả các host trong nhóm và loại bỏ sự cần thiết phải
định tuyến các gói đến từng host riêng lẻ.
Do thời gian lọc các gói không mong muốn diễn ra nhanh hơn thời gian
định tuyến các gói (định tuyến bao gồm các quá trình nhận gói, kiểm tra,
đóng gói lại và gửi đi), kiến trúc này cung cấp thông lượng cao hơn các giải
pháp dựa trên bộ điều phối. Khi tốc độ của mạng và server tăng lên, thông
lượng cũng tăng theo tỉ lệ thuận, do đó loại bỏ được bất cứ sự lệ thuộc nào
vào việc định tuyến dựa trên các phần cứng đặc biệt.
Trên thực tế, bộ cân bằng tải có thể đạt thông lượng 250Mbit/s trong các
mạng Gigabit. Một ưu điểm cơ bản khác của kiến trúc phân tán hoàn toàn là
độ khả dụng được tăng cường với (N-1) cách khắc phục lỗi trong một nhóm
có N host. Các giải pháp dựa trên bộ điều phối tạo ra một điểm lỗi kế thừa
mà chỉ có thể được khắc phục bằng cách sử dụng một bộ điều phối dự phòng
và do đó chỉ cung cấp một cách khắc phục lỗi duy nhất.
Kiến trúc cân bằng tải cũng tận dụng được những ưu điểm về kiến trúc
các thiết bị chuyển mạch (switch) hoặc các bộ tập trung (hub) của mạng con

trong việc đồng thời phân phối lưu lượng mạng đến tất cả các host trong
nhóm.
Tuy nhiên, phương pháp này làm tăng "tải trọng" trên các chuyển mạch
do chiếm thêm băng thông cổng. Đây không phải là vấn đề trong phần lớn
Load Blancing

6


các ứng dụng như dịch vụ Web hay streaming media, do tỉ lệ lưu lượng đến
chỉ chiếm một phần rất nhỏ trong tổng lưu lượng mạng.
Tuy nhiên, nếu các kết nối mạng phía client đến thiết bị chuyển mạch có
tốc độ nhanh hơn nhiều các kết nối phía server, lưu lượng có thể chiếm một
tỉ lệ lớn quá mức cho phép của băng thông cổng phía server. Vấn đề tương tự
sẽ gia tăng nếu nhiều nhóm kết nối trên cùng một thiết bị chuyển mạch và
các biện pháp thiết lập các mạng LAN ảo cho từng nhóm không được thực
hiện.
Trong quá trình nhận gói, việc triển khai của NLB là sự kết hợp giữa
việc phân phối các gói tới tầng TCP/IP và nhận các gói khác qua trình điều
khiển card mạng. Việc này giúp tăng tốc độ xử lý chung và giảm trễ do
TCP/IP có thể xử lý gói trong khi trình điều khiển NDIS (Network Driver
Interface Specification) nhận gói tiếp theo. Trong quá trình gửi gói, NLB
cũng tăng cường thông lượng, giảm độ trễ và phụ phí (overhead) nhờ tăng số
lượng gói mà TCP/IP có thể gửi trong một kết nối.
Để có được những cải thiện về hiệu năng này, NLB thiết lập và quản lý
một tập hợp các bộ đệm gói và các ký hiệu (descriptor) được sử dụng để
phối hợp các hoạt động của TCP/IP và trình điều khiển NDIS.
5.Phân phối lưu lượng trong nhóm
NLB sử dụng hai lớp broadcast hoặc multicast để phân phối đồng thời
lưu lượng mạng đến tất cả các host trong nhóm. Trong chế độ hoạt động mặc

định là unicast, NLB sẽ gán địa chỉ trạm làm việc (địa chỉ MAC) cho card
mạng để card mạng có thể hoạt động (card này gọi là card nhóm ? cluster
adapter), và tất cả các host trong nhóm được gán cùng một địa chỉ MAC.
Các gói đến do đó được nhận bởi tất cả các host trong nhóm và chuyển
gói tới trình điều khiển cân bằng tải để lọc. Để đảm bảo tính duy nhất, địa
chỉ MAC được dẫn xuất từ địa chỉ IP chính của nhóm. Ví dụ, với địa chỉ IP
chính của nhóm là 1.2.3.4, địa chỉ MAC unicast được đặt là 02-BF-1-2-3-4.
Trình điều khiển cân bằng tải sẽ tự động sửa địa chỉ MAC của card
nhóm bằng cách thiết lập một thực thể đăng ký và tái nạp trình điều khiển
card nhóm. Hệ điều hành không cần phải khởi động lại. Nếu các host trong
Load Blancing

7


cluster được gắn vào một thiết bị chuyển mạch (swicth) chứ không phải một
bộ tập trung (hub), việc sử dụng chung một địa chỉ MAC sẽ gây ra xung đột
do các chuyển mạch lớp 2 chỉ có thể hoạt động khi các địa chỉ MAC nguồn
trên tất cả các cổng của thiết bị chuyển mạch là duy nhất.
Để tránh điều này, NLB sửa địa chỉ MAC nguồn cho các gói đầu ra là
duy nhất, địa chỉ MAC của nhóm là 02-BF-1-2-3-4 được chuyển thành 02-h1-2-3-4, trong đó h là mức ưu tiên của host trong nhóm. Kỹ thuật này ngăn
không cho thiết bị chuyển mạch tìm ra địa chỉ MAC thực sự của nhóm và
kết quả là các gói đến nhóm được phân phối tới tất cả các cổng của thiết bị
chuyển mạch.
Nếu các host trong nhóm được kết nối trực tiếp vào một hub, mặt nạ địa
chỉ MAC nguồn của NLB trong chế độ unicast có thể được vô hiệu hoá để
tránh gây ra hiện tượng tràn cho các thiết bị chuyển mạch ở đường lên
(upstream). Điều này có thể thực hiện bằng cách thiết lập tham số đăng ký
NLB là MaskSourceMAC=0. Việc sử dụng hệ thống chuyển mạch đường
lên ba mức cũng có thể hạn chế tràn cho các thiết bị chuyển mạch.

Load Blancing

8


Chế độ unicast của NLB có thể làm vô hiệu hoá quá trình trao đổi thông
tin giữa các host trong nhóm có sử dụng card nhóm. Khi các gói của một
host được gửi đi với địa chỉ MAC đích giống địa chỉ MAC nguồn, các gói
này sẽ bị quay vòng (loop-back) giữa các tầng giao thức mạng bên trong hệ
thống phía gửi và không bao giờ ra đến đường truyền. Hạn chế này có thể
tránh được bằng cách thêm một card mạng thứ hai cho mỗi host. Trong cấu
hình này, NLB sử dụng một card mạng trên mạng con nhận các yêu cầu của
client và một card mạng khác thường được đặt tách biệt trên mạng con cục
bộ để trao đổi thông tin giữa các host trong nhóm và với các server cơ sở dữ
liệu cũng như các file server gốc. NLB chỉ sử dụng card nhóm để truyền các
bản tin "heartbeat" và lưu lượng điều khiển từ xa.
Chú ý rằng, trao đổi thông tin giữa các host trong nhóm và các host
ngoài nhóm không bao giờ bị ảnh hưởng bởi chế độ unicast của NLB. Lưu
lượng mạng đến một địa chỉ IP dành riêng cho host (trong card nhóm) được
nhận bởi tất cả các host trong nhóm do chúng sử dụng chung một địa chỉ
MAC. Do NLB không bao giờ cân bằng tải lưu lượng đối với các địa chỉ IP
dành riêng, NLB sẽ lập tức phân phối lưu lượng này đến TCP/IP trên host đã
định. Các host khác trong nhóm coi lưu lượng này là lưu lượng đã được cân
bằng tải và sẽ loại bỏ lưu lượng này. Chú ý, nếu lưu lượng mạng đến quá lớn
đối với các địa chỉ IP dành riêng có thể ảnh hưởng đến hiệu năng khi hệ
thống NLB hoạt động trong chế độ unicast (tuỳ theo sự cần thiết đối với
TCP/IP trong việc loại bỏ các gói không mong muốn).
NLB cung cấp chế độ thứ hai để phân phối lưu lượng mạng đến các host
trong nhóm, chế độ multicast. Chế độ này gán địa chỉ multicast 2 lớp cho

card nhóm thay vì thay đổi địa chỉ trạm làm việc của card. Ví dụ, địa chỉ
MAC multicast sẽ được gán là 03-BF-1-2-3-4 tương ứng với địa chỉ IP chính
là 1.2.3.4. Do mỗi host trong nhóm có một địa chỉ trạm làm việc duy nhất,
chế độ này không cần một bộ card mạng thứ hai để trao đổi thông tin giữa
các host trong nhóm và nó cũng không có bất cứ ảnh hưởng nào đến hiệu
năng của toàn hệ thống do việc sử dụng các địa chỉ IP dành riêng.
Chế độ unicast của NLB gây ra tràn trên switch do sự phân phối đồng
thời lưu lượng mạng trên tất cả các cổng. Tuy nhiên, chế độ multicast của
NLB đưa ra cơ hội hạn chế tràn switch để người quản trị hệ thống có thể cấu
Load Blancing

9


hình một mạng LAN ảo trên switch cho các cổng tương ứng với các host. Có
thể làm được điều này bằng cách lập trình cho switch hoặc sử dụng giao
thức IGMP hoặc giao thức GARP, GMRP.
NLB cần triển khai chức năng ARP để đảm bảo rằng địa chỉ IP chính của
nhóm và các địa chỉ IP ảo khác có thể phân giải sang địa chỉ MAC multicast
của nhóm. (Địa chỉ IP dành riêng sẽ tiếp tục phân giải sang địa chỉ trạm làm
việc của card nhóm).
6. Một số thuật toán load balancing
NLB sử dụng thuật toán lọc phân tán hoàn toàn để ánh xạ các client đến
các host trong nhóm. Thuật toán này cho phép các host trong nhóm đưa ra
các quyết định cân bằng tải một cách độc lập và nhanh chóng cho từng gói
đến. Nó được tối ưu hoá để cung cấp khả năng cân bằng tải một cách thống
kê đối với một số lượng lớn các yêu cầu nhỏ do vô số client tạo ra, điển hình
là đối với các Web server.
Nếu số client hoặc các kết nối client tạo ra các tải quá chênh lệch nhau
trên server, thuật toán cân bàng tải sẽ ít hiệu quả. Tuy nhiên, tính đơn giản và

tốc độ của thuật toán cho phép cung cấp hiệu nǎng rất cao bao gồm cả thông
lượng cao và thời gian đáp ứng ngắn trong một dải rộng các ứng dụng
client/server thông dụng.

Load Blancing

10


NLB xử lý các yêu cầu của client bằng cách dẫn đường cho một tỉ lệ
phần trăm đã chọn những yêu cầu mới cho từng host trong nhóm. Thuật toán
không đáp ứng những thay đổi về tải trên mỗi host (chẳng hạn như tải CPU
hay vấn đề sử dụng bộ nhớ). Tuy nhiên, quá trình ánh xạ sẽ được thay đổi
khi quan hệ thành viên trong nhóm thay đổi và tỉ lệ phần trăm tải phân bố sẽ
được tái cân bằng.
Khi xem xét một gói đến, tất cả các host thực hiện đồng thời việc ánh xạ
thống kê để xác định nhanh chóng host nào sẽ xử lý gói đó. Quá trình ánh xạ
sử dụng một hàm ngẫu nhiên để tính mức ưu tiên của host dựa trên địa chỉ IP
và cổng đến của client cùng các thông tin trạng thái khác để tối ưu hoá việc
cân bằng tải. Host tương ứng sẽ chuyển gói đó từ các tầng dưới lên tầng
TCP/IP còn các host khác sẽ loại bỏ gói này. Quá trình ánh xạ không thay
đổi trừ phi quan hệ giữa các host trong nhóm thay đổi, để đảm bảo rằng địa
chỉ IP và cổng đến của client cho trước sẽ luôn được ánh xạ đến cùng một
host trong nhóm.
Tuy nhiên, host cụ thể trong nhóm mà địa chỉ IP và cổng đến của client
ánh xạ tới không thể được xác định trước do hàm ngẫu nhiên có tính đến

Load Blancing

11

quan hệ thành viên trong nhóm hiện tại và quá khứ để tối thiểu hoá khả năng
ánh xạ lại.
Nhìn chung, chất lượng cân bằng tải được xác định một cách thống kê
bởi số lượng client tạo ra yêu cầu. Như kết cấu tăng giảm về số lượng client
theo thống kê, sự đều đặn về chất lượng của thuật toán cân bằng tải sẽ thay
đổi nhẹ.
Để hoạt động cân bằng tải có độ chính xác cao trên mỗi host trong
nhóm, một phần tài nguyên hệ thống sẽ được sử dụng để đo và phản ứng
trước những thay đổi của tải. Sự trả giá về hiệu năng này phải được cân nhắc
so với lợi ích của việc tối đa hoá khả năng sử dụng các tài nguyên trong
nhóm (về cơ bản là CPU và bộ nhớ).
Trong bất cứ trường hợp nào, việc sử dụng hợp lý các nguồn tài nguyên
server phải được duy trì để có thể phục vụ cho các tải client khác trong
trường hợp xảy ra lỗi.
Khi một host mới tham gia vào nhóm, nó sẽ kích hoạt quá trình hội tụ và
một quan hệ thành viên mới trong nhóm sẽ được tính toán. Khi quá trình hội
tụ hoàn thành, một phần tối thiểu client sẽ được ánh xạ tới host mới. NLB dò
các kết nối TCP trên mỗi host và sau khi kết nối TCP hiện tại của chúng
hoàn thành, kết nối tiếp theo từ các client bị ảnh hưởng sẽ được xử lý bởi
host mới.
Do đó, các host nên được bổ sung vào nhóm tại những thời điểm tải tăng
quá mạnh nhằm tối thiểu hoá hiện tượng ngắt quãng các phiên. Để tránh vấn
đề này, trạng thái phiên phải được quản lý bởi ứng dụng server sao cho nó có
thể được tái cấu trúc hay được trả lại từ bất kỳ một host nào trong nhóm. Ví
dụ, trạng thái phiên có thể được đẩy đến server cơ sở dữ liệu và lưu trong
các cookies của client.
a. Thuật toán ngẫu nhiên:
Trong thuật toán random, kết nối sẽ được phân một cách ngẫu nhiên vào

server đứng sau bằng cách sử dụng một hàm chọn số ngẫu nhiên.
Mặc dù thuật toán này được cài đặt sẵn trong các bộ cân bằng tải, tuy
nhiên nó ít được áp dụng so với các thuật toán khác.
Load Blancing

12


b. Thuật toán round robin (RR):
Round robin là thuật toán được sử dụng nhiều nhất trong các hệ thống
load balance vừa và nhỏ, nhu cầu mở rộng hệ thống thấp. Một kết nối với sẽ
được gửi đến server kế tiếp phía backend và cứ tiếp tục quay vòng như vậy.
Round robin hoạt động tốt khi các server backend có cấu hình (tài
nguyên) tương tự nhau và sẽ xảy ra hiện tượng mất cân bằng tải khi các
server backend có cấu hình khác nhau (xảy ra hiện tượng một số server xử lý
nhiều hơn server khác). Tuy nhiên vì là thuật toán đơn giản nên nó tỏ ra hoạt
động rất nhanh và hiệu quả (không áp dụng thuật toán phức tạp, không mất
nhiều thời gian tính toán, …). Trong quá trình áp dụng, nếu các server đích
không bị sự cố thì việc áp dụng thuật toán round robin cho hiệu quả khả
quan.
Điểm yếu của round robin là 2 yêu cầu liên tục từ phía người dùng sẽ có
thể được gửi vào 2 server khác nhau. Điều này làm tốn thời gian tạo thêm
kết nối với server thứ 2 trong khi đó server thứ nhất cũng có thể trả lời được
thông tin mà người dùng đang cần. Để giải quyết điều này, round robin
thường được cài đặt cùng với các phương pháp duy trì session như sử dụng
cookie.
c. Thuật toán Weighted Round Robin (Ratino):
Nguyên lý hoạt động của WRR cũng tương tự như 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 backend theo thứ tự
xoay vòng. Sự khác biệt duy nhất ở đây đó là thuật toán WRR còn có khả

năng xử lý theo cấu hình của từng server đích. Trong cùng một chu kỳ, một
server có khả năng xử lý gấp đôi server khác sẽ nhận được số request gấp
đôi từ bộ cân bằng tải.
Ví dụ: Có 4 server A,B,C,D trong đó hai server A, B có cấu hình tương
tự nhau. Cấu hình của C và D cũng tương tự nhau và gấp đôi cấu hình của A.
Khi đó trọng số được đánh cho A và B là 1, đánh cho C và D là 2. Vậy theo
luật của WRR thì thứ tự server nhận được request từ bộ cân bằng tải sẽ là
ABCCDD.
Thuật toán WRR hoạt động tốt hơn RR khi trong cụm backend có các
server cấu hình khác nhau. Tuy nhiên sử dụng thuật toán này có thể dẫn đến
việc mất cân bằng tải động nếu như tải của các request liên tục thay đổi
trong một khoảng thời gian rộng (ví dụ các yêu cầu cần 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 một server.

Load Blancing

13


d. Thuật toán Dynamic Round Robin (DRR)
Thuật toán DRR hoạt động gần giống với thuật toán DRR, điểm khác
biệt là trọng số ở đây dựa trên sự kiểm tra server một cách liên tục, do đó
trọng số liên tục thay đổi.
Đây là thuật toán động (các thuật toán ở trên là thuật toán tĩnh), việc
chọn server sẽ dựa trên rất nhiều khía cạnh trong việc phân tích hiệu năng
của server trên thời gia thực (ví dụ: số kết nối hiện đang có trên các server
hoặc server trả lời nhanh nhất, …).
Thuật toán này thường không được cài đặt trong các bộ cân bằng tài đơn

giản, nó thường được sử dụng trong các sản phẩm cân bằng tải của F5
Network.
e. Thuật toán Fastest.
Thuật toán fastest chọn server dựa trên thời gian đáp ứng của mỗi server
(response time), thuật toán này sẽ chọn server nào có thời gian đáp ứng
nhanh nhất. Thời gian đáp ứng được xác định bởi khoảng thời gian giữa thời
điểm gửi một gói tin đến server và thời điểm nhận được gói tin trả lời. Việc
gửi và nhận này sẽ được bộ cân bằng tải đảm nhiệm, dựa trên thời gian đáp
ứng, bộ cân bằng tải sẽ biết chuyển yêu cầu tiếp theo đến server nào.
Thuật toán fastest thường được dùng khi các server được cài đặt dọc
theo các mạng logic khác nhau, nghĩa là server được đặt ở nhiều nơi khác
nhau. Như vậy người dùng ở gần server nào thì thời gian đáp ứng của server
đó sẽ nhanh nhất, và server đó sẽ được chọn để phục vụ.
Thuật toán này cũng giống như chuyển hướng yêu cầu dựa trên địa chỉ
IP. Ví dụ như khi truy cập vào trang youtobe.com, nếu IP của người dùng
đến từ Việt Nam, yêu cầu sẽ được chuyển vào server Việt Nam xử lý. Điều
này sẽ tiết kiệm khá lớn cho lượng băng thông quốc tế và cải thiện tốc độ
đường truyền.
f. Thuật toán Lest Connection (LC)
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ó phải đếm số kết nối đang hoạt động của 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 đó nếu sử dụng RC sẽ khắc phục được nhược điểm của RR.
Nhìn bên ngoài có vẻ như LC hoạt động tốt khi các server có cấu hình
biến thiên khác nhau, tuy nhiên trên thực tế đều đó là không đúng. Nguyên
nhân là do trạng thái TIMVE_WAIT của TCP. TIME_WAIT thường được
Load Blancing

14


đặt là 2 phút, trong 2 phút đó có một server bận rộn có thể nhận hàng chục
ngàn kết nối liên tục. Giả sử server A có khả năng xử lý gấp đôi server B,
server A đang xử lý hàng ngàn những 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 B cũng phải xử
lý như server A nhưng vì cấu hình server B thấp hơn nên sẽ chậm 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.
g. Thuật toán Observed
Observed là sự kết hợp của thuật toán LC và Fastest Response, nó chỉ
tồn tại trong các giải pháp của F5 Network. Ở đây người phát triển hệ thống
sẽ phải cân bằng giữ hai yếu tố là số kết nối đến từng server và thời gian đáp
ứng giữa chúng. Nghĩa là cũng giống như đánh trọng số cho các server, hai
yếu tố này sẽ có những trọng số nhất định dựa trên nhận định của người phát
triển hệ thống hoặc nhà quản trị. Một phép toán số học dựa trên số kết nối
của một server thời gian đáp ứng và các trọng số sẽ đưa ra cho mỗi server
một giá trị. Dựa trên giá trị đó, bộ cân bằng tải sẽ chọn được server phù hợp.
Nếu như được thiết kế tốt, Observed sẽ khắc phục được cả nhược điểm
của Lest Connection và Fastest Response. Thuật toán Lest Connection sẽ
không chú trọng vào không gian, có nghĩa là một người truy cập từ Hà Nội
có thể kết nối với server đặt tại Hồ Chính Minh và ngược lại vì số kết nối ở
đó đang ít nhất. Như vậy là không cần thiết, vì nếu chuyển kết nối người
dùng này vào server tại Hà Nội thì thời gian phục vụ sẽ giảm xuống đồng
thời tiết kiệm được rất nhiều băng thông. Trong khi đó Fastest Response sẽ
đưa người dùng vào server có thời gian đáp ứng nhanh nhất bất kể số kết nối
ở đó là nhiều hay ít, nếu như máy chủ đó sắp quá tải có thể dẫn đến bị treo.
Sự cân bằng giữa số kết nối và thời gian đáp ứng sẽ giúp cho bộ cân bằng tải
lựa chọn được server phù hợp.

Observed được đưa ra bởi F5 Network và hầu như không tồn tại trong
các phần mềm mã nguồn mở hay các phần mềm nhỏ.
h. Thuật toán Predictive
Là sự phát triển tiếp theo của Observed, nhưng trong thuật toán
predictive hệ thống sẽ phân tích trạng thái của các server theo thời gian thực,
xác định xem thời điểm nào thì hiệu năng của server đang tăng lên, thời
điểm nào đang giảm xuống. Như vậy giả sử 2 server theo đánh giá của thuật
toán predictive là tương đương nhau, server nào có hiệu năng biến đổi theo
chiều hướng tốt hơn sẽ được chọn.

Load Blancing

15


7.Quá trình hội tụ
Các host trong nhóm trao đổi định kỳ các bản tin "heartbeat" multicast
hoặc broadcast với nhau. Điều này cho phép các host có thể giám sát trạng
thái của nhóm. Khi trạng thái của nhóm thay đổi (chẳng hạn như khi có host
gặp trục trặc, rời khỏi hoặc tham gia vào nhóm), NLB kích hoạt một chu
trình gọi là hội tụ trong đó các host trao đổi bản tin "heartbeat" để định ra
một trạng thái mới, bền vững cho nhóm. Khi tất cả các đạt được sự "nhất trí"
trạng thái mới của chúng sẽ được thiết lập và những thay đổi này sẽ được
lưu vào nhật ký sự kiện.
Trong quá trình hội tụ, các host tiếp tục xử lý lưu lượng mạng đến như
mọi khi ngoại trừ lưu lượng đến host bị lỗi không nhận được dịch vụ. Quá
trình hội tụ kết thúc khi tất cả các host trong nhóm có được một quan hệ
thành viên ổn định trong vòng một vài chu kỳ heartbeat.
Khi hoàn thành quá trình hội tụ, lưu lượng đến host bị lỗi sẽ được tái
phân phối cho các host còn lại. Nếu một host được thêm vào nhóm, quá trình

hội tụ cho phép host này nhận được phần tải của nó trong lưu lượng đã được
cân bằng.
Việc mở rộng nhóm không ảnh hưởng đến các hoạt động của nhóm và
theo một cách hoàn toàn trong suốt đối với tất cả các Internet client cũng
như trước các chương trình phần mềm server. Tuy nhiên, nó có thể ảnh
hưởng đến các phiên client vì các client có thể phải tái ánh xạ tới các host
khác trong nhóm.

Load Blancing

16


Trong chế độ unicast, mỗi host sẽ phát quảng bá (broadcast) bản tin
"heartbeat" theo chu kỳ. Còn trong chế độ multicast, nó sẽ phát các bản tin
này ở chế độ multicast. Mỗi bản tin "heartbeat" chiếm một khung Ethernet
và được gắn thêm địa chỉ IP chính của nhóm nhằm cho phép nhiều nhóm có
thể cùng tồn tại trên cùng một mạng con. Bản tin "heartbeat" của NLB của
Microsoft được gán một giá trị 0x886F. Chu kỳ gửi các bản tin này mặc định
là 01 giây. Giá trị này có thể thay đổi.
Trong quá trình hội tụ, chu kỳ này được giảm xuống chỉ còn một nửa để
đẩy nhanh việc hoàn tất quá trình này. Thậm chí, đối với các cluster lớn,
băng thông cần thiết để truyền các bản tin "heartbeat" rất thấp (24kBytes/s
cho một cluster 16 đường). Để có thể khởi tạo quá trình hội tụ, theo mặc
định cần 05 bản tin heartbeat không được nhận. Giá trị này có thể thay đổi.

Load Blancing

17

8.Điều khiển từ xa
Cơ chế điều khiển từ xa của NLB sử dụng giao thức UDP và được gán
cổng dịch vụ #2504. Các gói dữ liệu điều khiển từ xa được gửi tới địa chỉ IP
chính của nhóm. Do trình điều khiển trên mỗi host trong nhóm xử lý các gói
này, chúng cần được định tuyến tới mạng con của nhóm (thay vì tới một
mạng con gốc mà nhóm đó gắn vào). Khi các lệnh điều khiển từ xa được đưa
ra trong nhóm, chúng sẽ được phát quảng bá trên mạng con cục bộ.
Điều này đảm bảo tất cả các host trong nhóm đều có thể nhận được
chúng ngay cả khi nhóm chạy trong chế độ unicast.
9.Hiệu năng cân bằng tải
Vai trò của NLB tác động đến hiệu năng của hệ thống có thể được đánh
giá dựa trên bốn tiêu chí chính sau:
- CPU overhead trên các host của nhóm - Phần trăm CPU cần thiết để
phân tích và lọc các gói của mạng (càng thấp càng tốt).
Tất cả các giải pháp cân bằng tải đều cần sử dụng một phần tài nguyên
của hệ thống để xem xét gói đến và đưa ra quyết định cân bằng tải và do đó
ít nhiều ảnh hưởng đến hiệu năng của mạng.
Giải pháp cân bằng tải dựa trên bộ điều phối cần kiểm tra, hiệu chỉnh và
truyền lại gói tới các host trong nhóm (thường phải sửa đổi lại địa chỉ IP để
tái định tuyến gói từ địa chỉ IP ảo tới địa chỉ IP của từng host cụ thể). Đối
với NLB, nó phân phối đồng thời các gói đến tới tất cả các host trong nhóm
và áp dụng một thuật toán lọc để loại bỏ các gói không mong muốn...
Quá trình lọc gây ảnh hưởng ít hơn so với quá trình tái định tuyến và kết
quả là thời gian đáp ứng nhanh hơn với thông lượng toàn hệ thống cao hơn.
10.Thông lượng và thời gian đáp ứng yêu cầu
NLB nâng cao hiệu năng hệ thống bằng cách tăng thông lượng và tối
thiểu hoá thời gian đáp ứng tới các yêu cầu của client. Khi năng lực của các
host trong nhóm được khai thác tối đa, nó sẽ không thể cung cấp thêm thông
lượng và thời gian đáp ứng tăng đột biến tuỳ theo độ trễ hàng đợi các yêu

Load Blancing

18


cầu của client. Bổ sung thêm host sẽ cho phép tăng thông lượng và giảm thời
gian đáp ứng.
Nếu nhu cầu của khách hàng tiếp tục tăng, các host sẽ được thêm vào
cho đến khi mạng con bão hoà. Và nếu tải tiếp tục tăng, cần sử dụng nhiều
nhóm NLB và việc phân phối lưu lượng giữa các host được thực hiện bằng
kỹ thuật Round Robin DNS.

- Băng thông sử dụng của Switch (Switch occupancy): Tỉ lệ băng thông
của switch được sử dụng bởi quá trình làm tràn các yêu cầu của client.
Kiến trúc lọc gói của NLB dựa trên mạng con broadcast để phân phối
các yêu cầu của client tới tất cả các host cùng lúc. Trong các nhóm nhỏ, có
thể sử dụng hub để kết nối các host. Với các nhóm lớn hơn, switch sẽ là sự
lựa chọn. Và như mặc định, NLB sẽ tạo ra hiện tượng "tràn" switch để có thể
phân phối các yêu cầu của client tới tất cả các host cùng lúc.
Cần chắc chắn rằng hiện tượng "tràn" switch không được vượt quá năng
lực của switch, đặc biệt khi switch được chia sẻ giữa nhóm và các máy tính
ngoài nhóm. Bình thường, băng thông sử dụng cho lưu lượng yêu cầu của
client chỉ chiếm một tỉ lệ nhỏ trong tổng lượng băng thông cần thiết cho quá
trình truyền thông giữa server và client.
Tuy nhiên quá trình "tràn" switch sẽ trở thành vấn đề trong những ứng
dụng có tỉ lệ phần trăm đáng kể lưu lượng mạng được dẫn tới nhóm (chẳng
Load Blancing

19

hạn như quá trình upload file trong các ứng dụng FTP) hay khi nhiều nhóm
sử dụng chung một switch. Trong những trường hợp này, chạy NLB trong
chế độ multicast và thiết lập mạng LAN ảo để hạn chế tràn switch là biện
pháp khắc phục rất hiệu quả khiếm khuyết này. Ngoài ra, tính khả mở của
NLB quyết định khả năng cải thiện hiệu năng của hệ thống khi các host
được thêm vào nhóm.
11.Một số phương pháp cân bằng tải
Round Robin DNS:
1.

2.

Cân bằng tải cho server toàn cầu ( GSLB)
Có 2 nhân tố chính thể hiện sự cần thiết của GSLB , đó là khả năng
có sẵn cao và thời gian đáp ứng.
Để đảm bảo tính có sẵn của cụm server , chúng ta sử dụng 1 bộ cân
bằng tải để thực hiện kiểm tra “ health checks” đối với server. Để đảm
bảo bộ cân bằng tải không bị quá tải chúng ta có thể cài đặt nhiều bộ
cân bằng tải hoạt động. Chúng ta giải thiết rằng có sự cố là bộ trung
tâm dữ liệu chứa các server và các bộ cân bằng tải không thể hoạt
động vì mất điện, động đất hoặc lũ lụt? Tất nhiên là người dùng sẽ
không thể truy cập vào website. Để tránh trường hợp này xảy ra,
chúng ta có thể cài đặt website ở nhiều trung tâm dữ liệu khác nhau và
sử dụng GSLB để đồng bộ giữa các trung tâm này.
Phương án này đảm bảo rằng , nếu như có một trung tâm nào đó bị
hỏng, thì vẫn còn các trung tâm khác hoạt động.
Domain Name System ( DNS )
GSLB có thể đạt được nhiều cách khác nhau, nhưng cách được dùng
nhiều nhất là DNS . Khi người dùng truy cập vào website ví dụ là

www.facebook.com chẳng hạn, thì “ facebook.com” chính là tên miền
(domain) , có nhiều loại tên miền khác nhau, chỉ định bằng đuôi của
chúng. Ví dụ tên miền .com ( các trang web thương mại ) , tên miền
.org( giáo dục). Trong mỗi tên miền lại có những tên miền con gọi là
các vùng của tên miền chính. Ví dụ : “ pics.facebook.com” hay là “
video.facebook.com” . Một tên miền có thể được lưu trữ ở nhiều
DNS khác nhau , nhưng sẽ có một DNS có thẩm quyền cao nhất

Load Blancing

20


( authoritative DNS) , DNS này có trách nhiệm cập nhật tất cả các
thay đổi cho các DNS có thẩm quyền thấp hơn.
3. Cân bằng tải bằng DNS
Có 3 phương pháp cân bằng tải với DNS : round robin , random và
location-based. Trong đó " round robin" là phương pháp được xem là dễ
thực hiện và thông dụng nhất.
* ROUND ROBIN LOAD BALANCING ( Luân chuyển vòng DNS )
Hầu hết chúng ta đều biết, cơ sở dữ liệu DNS bản đồ hóa tên host thành
các địa chỉ IP.

Load Blancing

21


Khi bạn nhập một URL vào trong trình duyệt (ví dụ
như www.loadbalancedsite.com) thì trình duyệt sẽ gửi một yêu cầu đến DNS

yêu cầu nó trả về địa chỉ IP của site. Đây được gọi là việc tra cứu DNS. Sau
khi trình duyệt Web có được địa chỉ IP cho site thì nó sẽ liên hệ với site bằng
địa chỉ IP, và hiển thị trang mà bạn vừa yêu cầu. Máy chủ DNS thường có
một địa chỉ IP được bản đồ hóa với một tên site nào đó. Trong ví dụ riêng
của chúng tôi thì site làwww.loadbalancedsite.com bản đồ hóa thành địa chỉ
IP là 203.24.23.3.
Để cân bằng tải bằng DNS, máy chủ DNS phải duy trình một số địa chỉ IP
khác nhau cho cùng một tên site. Nhiều địa chỉ IP thể hiện nhiều máy trong
một cluster, tất cả trong số chúng đều bản đồ hóa đến một tên site logic.
Trong ví dụ của chúng ta, www.loadbalancedsite.com có thể được cấu hình
trên ba máy chủ trong một cluster với các địa chỉ IP dưới đây:
203.34.23.3
203.34.23.4
203.34.23.5
Trong trường hợp này, máy chủ DNS được bản đồ hóa như sau:
www.loadbalancedsite.com 203.34.23.3
www.loadbalancedsite.com 203.34.23.4
www.loadbalancedsite.com 203.34.23.5

Load Blancing

22


Khi yêu cầu đầu tiên đến được máy chủ DNS, nó sẽ trả về địa chỉ
IP 203.34.23.3, máy đầu tiên. Khi có yêu cầu thứ hau, nó sẽ trả về địa chỉ
IP thứ hai: 203.34.23.4. Tiếp tục như vậy, với yêu cầu thứ tư, địa chỉ IP
đầu tiên lại được lặp lại.
Bằng cách sử dụng luân chuyển vòng DNS như ở trên, tất cả các yêu cầu
đối với một site nào đó đều được phân phối đều đến tất cả các máy trong

cluster. Chính vì vậy, với phương pháp cân bằng tải này, tất cả các nút
trong cluster đều được sử dụng.
Ưu điểm của phương pháp luân chuyển vòng DNS
Các ưu điểm chính của phương pháp này nằm ở chỗ rẻ và dễ dàng:
• Không đắt và dễ dàng thiết lập: Các quản trị viên hệ thống chỉ cần tạo
một số thay đổi trong máy chủ DNS để hỗ trợ được việc luân chuyển vòng,
và nhiều máy chủ DNS đã có sự hỗ trợ này. Nó không yêu cầu đến sự thay
đổi mã của ứng dụng Web; trong thực tế, các ứng dụng Web không hề biết
về cơ chế cân bằng tải mà nó bị thực hiện.
• Đơn giản: Phương pháp này không yêu cầu đến các chuyên gia về mạng
trong việc thiết lập hoặc giỡ rối hệ thống trong trường hợp có vấn đề nào đó
xay ra.
Nhược điểm của phương pháp này
Có hai nhược điểm chính của phương pháp dựa trên phần mềm này là nó
không cung cấp sự hỗ trợ mối quan hệ thời gian thực giữa các máy chủ với
nhau và không hỗ trợ khả năng có sẵn cao.
- Không hỗ trợ mối quan hệ thời gian thực giữa các máy chủ. Mối quan
hệ thời gian thực giữa các máy chủ là khả năng của hệ thống trong việc quản
lý các yêu cầu của người dùng, máy chủ này hoặc bất kỳ máy chủ nào, phụ
thuộc vào thông tin session được duy trì trên máy chủ hoặc tại mức cơ sở
bản, mức cơ sở dữ liệu.
Không có được khả năng hỗ trợ mối quan hệ giữa các máy chủ, phương
pháp luân chuyển vòng DNS dựa vào một trong ba phương pháp đã được
Load Blancing

23


đưa ra để duy trì sự kiểm soát session hoặc sự nhận dạng người dùng đối với
các yêu cầu đang đến trên HTTP.

• Các cookie
• Các trường ẩn
• Viết lại URL
Khi một người dùng thực hiện một yêu cầu đầu tiên, máy chủ Web sẽ trả
một thẻ bằng văn bản duy nhất để phân biệt người dùng đó. Các yêu cầu tiếp
theo có thẻ này để sử dụng cookie, viết lại URL hoặc các trường ẩn, cho
phép máy chủ xuất hiện để duy trì một session giữa máy khách và máy chủ.
Khi người dùng thiết lập một session với một máy chủ, thì tất cả các yêu cầu
đến sau thường đều đi đến cùng một máy chủ.
Vấn đề ở đây là trình duyệt lưu địa chỉ IP của máy chủ đó. Khi Cache hết
hạn, trình duyệt sẽ thực hiện một yêu cầu khác đối với máy chủ DNS để có
được địa chỉ IP có liên kết với tên miền. Nếu máy chủ DNS trả về một địa
chỉ IP khác, một máy chủ khác trong cluster, thì các thông tin về session sẽ
bị mất.
- Không hỗ trợ cho khả năng có sẵn cao. Xem xét một cluster có n nút.
Nếu một nút nào đó gặp vấn đề thì cứ yêu cầu thứ n đến máy chủ DNS đều
hướng bạn đến một nút hỏng này. Một router thông minh có thể giải quyết
được vấn đề này bằng cách kiểm tra các nút ở các khoảng thời gian nào đó,
phát hiện ra các nút bị hỏng và gỡ bỏ chúng ra khỏi danh sách, chính vì vậy
sẽ không có yêu cầu nào được gửi đến chúng nữa. Tuy vậy, vấn đề ở đây vẫn
tồn tại nếu nút vẫn có nhưng ứng dụng Web đang chạy trên nút đã bị hỏng.
Thay đổi cluster sẽ mất nhiều thời gian để truyền bá đến toàn bộ phần còn
lại của Internet. Một lý do ở đây là trong nhiều tổ chức lớn – các ISP, các
công ty, hay đại lý – lưu các yêu cầu DNS của họ để giảm lưu lượng mạng
và thời gian request. Khi người dùng bên trong các tổ chức như vậy thực
hiện một request thì hệ thống sẽ được kiểm tra danh sách các tên DNS của
Cache đã được bản đồ hóa địa chỉ IP. Nếu hệ thống phát hiện thấy một entry
nào thì nó sẽ trả địa chỉ IP về cho người dùng. Nếu nó không phát hiện thấy
entry nào trong Cache nội bộ thì ISP sẽ gửi request DNS này đến máy chủ
DNS và lưu sự đáp trả.

Khi một entry đã được lưu hết hạn, ISP sẽ nâng cấp cơ sở dữ liệu nội bộ của
nó bằng cách liên hệ với các máy chủ DNS khác. Khi danh sách các máy
chủ của bạn thay đổi, nó có thể cần đến một khoảng thời gian ngắn cho các
Load Blancing

24


entry đã được lưu trên mạng của các tổ chức khác hết hạn và tìm kiếm danh
sách các máy chủ đã được cập nhật. Trong suốt chu trình này, máy khách
vẫn có thể thực hiện hành động “hit” nút máy chủ bị hỏng, nếu ISP của máy
khách đó vẫn có một entry trỏ đến nó. Trong trường hợp như vậy, một số
người dùng của ISP đó không thể truy cập vào site của bạn từ những lần truy
cập ban đầu, thậm trí nếu cluster của bạn có các máy chủ dư thừa vẫn đang
hoạt động.
Một vấn đề còn lớn hơn xuất hiên khi gỡ bỏ (removing) một nút so với việc
bổ sung. Khi bạn bớt đi một nút, người dùng có thể đang thực hiện “hit” một
máy chủ không tồn tại. Còn khi bạn thêm một nút thì máy chủ đó vẫn chưa
được sử dụng cho tới khi địa chỉ IP của nó đến được tất cả các máy chủ
DNS.
Mặc dù phương pháp này có thể cân bằng được một số lượng người dùng
trên mỗi máy chủ, nhưng nó không hoàn toàn cân bằng tải máy chủ. Một số
người dùng có thể yêu cầu mức tải cao hơn trong suốt một session của họ so
với những người dùng khác ở trên máy chủ khác, và phương pháp này
không thể bảo đảm chống lại được sự bất công bằng đó.
12. DEMO cân bằng tải DNS
Bài lab gồm có 5 server, mỗi server là một trang html có nội dung khác nhau
để phân biệt với những trang khác.
Để cài đặt đơn giản thì router tĩnh được sử dụng ở tất cả các thiết bị.
Các client được cấu hình để có thể kết nối từ một điểm đến các server cục bộ

Load Blancing

25