Cân bằng tải Web-Proxy Client với ISA Server 2004 Standard Edition

Trong bài này chúng ta sẽ chỉnh sửa cấu hình script do ISA Server 2004 Standard Edition cung cấp và triển khai nó cho các máy khách trình duyệt.

Cân bằng tải các Web-proxy thường được hiểu là một trong số những chức năng do ISA Server Enterprise Edition cung cấp. Nhưng với nhiều người, chi phí phụ của Enterprise Edition (phiên bản doanh nghiệp) khiến họ phải lưỡng lự, mặc dù mong muốn của các tổ chức hay công ty là luôn cần dư để dự trữ và cân bằng tải. Cho đến giờ phiên bản doanh nghiệp Standard Edition đã cung cấp một số thủ thuật, bí quyết cho phép cân bằng tải. Nếu bạn có ý định sở hữu hai hoặc ba ISA Server làm việc hiệu quả với nhau cùng một lúc, bài này có thể giúp bạn.

Giới thiệu

Với ISA Server 2004 (và cả 2000), nếu bạn muốn có nhiều hơn một server Web-proxy cho tổ chức của mình và để chúng hoạt động hiệu quả cùng với nhau, bạn nên ra ngoài và mua phiên bản Enterprise dành cho doanh nghiệp. Enterprise Edition hỗ trợ Cache Array Routing Protocol (hay CARP) và cung cấp cơ chế liên kết các proxy lại với nhau. Nhưng có thực sự rõ ràng? Nếu bạn chỉ có vài trăm người dùng và phải chuẩn bị một lượng dư dự trữ Web-proxy lớn, bạn có thực sự cần phải mất khoản chi phí thêm đáng kể cho cặp đôi bản quyền Enterprise?

Sự thật, người ta quan tâm đến CARP nhiều hơn là đọc về Enterprise Edition. Một số khía cạnh của CARP vẫn còn được ẩn giấu trong Standard Edition chờ bạn khám phá. Với hai hay ba server proxy trong "mảng", có thể bạn sẽ thấy rằng mình tiết kiệm được nhiều khoản chi phí hiệu quả khi dùng Standard Edition. Nếu nhiều hơn ba và giao thức không phải là CARP, bạn cần đến Enterprise Edition. Phiên bản này quản lý trung tâm hơn và các thành phần "Enterprise" khác được hỗ trợ.

Vậy, khi quyết định dùng hai Proxy để dự trữ, bạn muốn cả hai chia sẻ hoạt động tải và tránh các khoản phụ phí, tính phức tạp của Enterprise Edition thì: các tuỳ chọn là gì?

DNS Round-Robin và Network Load Balancing (NLB)

Cả hai cơ chế này có thể được dùng để cung cấp một số chức năng như khả năng chịu sai sót (fault-tolerance) và cân bằng tải. Chắc chắn nhiều người sẽ muốn thử chúng. Trong cả hai trường hợp bạn sẽ phải cấu hình một tên chung, (như với NLB là một IP phổ biến) để trỏ tới tất cả server ISA. Trước Standard Edition, Microsoft không hỗ trợ hệ thống NLB phức tạp hơn.

Bạn có thể cấu hình trình duyệt của mình sử dụng tên proxy chung một cách trực tiếp, hoặc cấu hình "dò tìm tự động", "kịch bản cấu hình tự động". Các tuỳ chọn "tự động" này có một số cải tiến khác biệt so với phương thức tĩnh, trong đó bạn có thể mô tả đường định tuyến sao lưu khi mọi thứ trở thành pear-shaped.

Hãy thận trọng vì nếu bạn dùng các phương thức "tự động", trình duyệt sẽ download file cấu hình từ một trong các Server ISA (được quyết định bởi NLB hoặc round-robin) và file này sẽ nói với trình duyệt chỉ dùng proxy đó trong suốt quá trình. Đây có thể không phải là cơ chế cân bằng tải mà bạn mong muốn! Để vượt qua các lỗi nhanh hơn khi dùng phương thức "tự động", bạn có thể cấu hình các thiết lập trên từng Server ISA, sử dụng Server ISA khác như một cách thức sao lưu. ISA Server sau đó sẽ bổ sung thông tin này vào file cấu hình các trình duyệt nhận về.

Điểm hạn chế lớn của các phương thức này là mỗi ISA Server đều xây dựng một cache riêng chứa thông tin vốn có trên ISA Server khác. Đây không phải là một cách sử dụng tài nguyên hiệu quả.

Các file cấu hình tự động proxy (Proxy Automatic Configuration - PAC)

Nếu bạn cấu hình "dò tìm tự động" hoặc "kịch bản cấu hình tự động" trong trình duyệt, file cấu hình không phải đến từ ISA Server. Nó có thể được trỏ tới vị trí khác chứa "kịch bản" cấu hình tuỳ biến do bạn cung cấp mà không phải là ISA Server. Phương thức này mở ra toàn bộ thế giới có thể cho khả năng cân bằng tải và khả năng chịu sai sót.

Các kịch bản (script) cấu hình này là gì? Gần như mọi trình duyệt hiện nay đều hỗ trợ một cách không bắt buộc việc sử dụng các script cấu hình tự động. Chúng được viết trong JavaScript. Trình duyệt chạy chúng sẽ gọi các hàm cụ thể trong script mỗi khi có đường dẫn URL tìm đến. Hàm sẽ trả lại Web-proxy cho trình duyệt sắp gửi yêu cầu URL tới.

Vậy các script này cân bằng tải như thế nào? Phương thức phổ biến là script chạy một thuật toán "hash" (thuật toán băm) trên URL được yêu cầu và dùng kết quả có được từ hàm băm đó để xác định Web-proxy nào sẽ gửi yêu cầu tới (thuật toán trả ra xâu URL là một số duy nhất, gọi là số băm). Cải tiến tuyệt vời của phương thức này là mỗi trình duyệt đều chạy cùng một hàm băm và xác định cùng một Web-proxy cho đường dẫn URL được cung cấp một cách hoàn chỉnh, tuỳ thuộc vào Web-proxy server. Điều này có nghĩa là các Web-proxy xây dựng một cache duy nhất cho các "bạn" Web-proxy khác của nó. Vì thế, tài nguyên được khai thác một cách hiệu quả.

Số lượng thuật toán băm được dùng không bị giới hạn. Đã có chuyên gia phát triển mô hình "Super Proxy Script" từ hồi năm 1996, bạn có thể tham khảo thêm tại địa chỉ: http://naragw.sharp.co.jp/sps/. Nhưng với hầu hết mọi người, công nghệ này thường được kết hợp với CARP.

Trong bài này chúng tôi sẽ khảo sát tỉ mỉ các script cấu hình tuỳ chọn dùng CARP. Nghe có vẻ đáng sợ, nhưng bạn đừng lo, bất kỳ định kiến nào trước đó về Enterprise Edition hỗ trợ CARP và Standard Edition note, tức ISA Server Standard Edition sẽ được thay thế. Tất cả mọi việc 'đáng sợ' đều sẽ được thực hiện tự động.

Cache Array Routing Protocol (CARP)

Như đã đề cập tới ở trên, người ta thường nói về CARP hơn là nhắc đến việc bán phiên bản doanh nghiệp Enterprise Edition có chạy không. CARP gồm hai kiểu: client-side CARP (trên máy khách) mà chúng ta đã thảo luận và server-side CARP (trên máy chủ).

Server-side CARP

CARP này sử dụng cơ chế hàm băm tương tự (nếu không muốn nói là hoàn toàn giống) với kiểu đã nói ở trên. Nhưng ở đây là dành cho máy chủ để xác định xem liệu nó có URL yêu cầu nào trong bộ nhớ phụ cache không, nếu không thì "bạn" nào của nó có không? Điều này khá tuyệt vời cho máy khách nào yêu cầu URL mà không hoặc sẽ không hỗ trợ client-side CARP (tức các client "Secure NAT" trong bộ nói ISA Server), hay nếu server có các mảng proxy theo hướng ngược lại và phải quyết định proxy lớn nhất để gửi yêu cầu tới.

ISA Server Enterprise Edition hỗ trợ server-side CARP nhưng bạn phải enable sử dụng thành phần này. Phiên bản Standard Edition không hỗ trợ CARP server-side.

Client-side CARP

Nếu một trình duyệt hỗ trợ client-side CARP thì bạn không phải vấn đề gì cho dù Web proxy là Enterprise hay Standard Edition (hay thậm chí là ISA Server). Tuy nhiên Enterprise Edition tạo các file cấu hình tự động với tất cả thành phần client-sile CARP cần thiết đúng chỗ. Thậm chí nó làm việc này ngay cả khi bạn không cho phép CARP trong cấu hình. Standard Edition cũng như vậy. Lỗi xuất hiện trong Standard Edition là do nó không hiểu có 'đối tác' hay không, vì thế không thể cấu hình thông tin cần thiết này trong script đã chuẩn bị.

Vì sao Microsoft không để cho phiên bản Standard Edition tạo mã client-side CARP không chức năng trong các script cấu hình. Có nghĩa là, chỉ cần giúp đỡ một chút, bạn có thể tạo được script đầy đủ chức năng.

Chúng ta hãy cùng xem xét script do ISA Server Standard Edition tạo ra này. Chỉ cần mở trình duyệt, gõ: http://myISAServer:8080/wpad.dat (dùng tên server của bạn). Ghi file khi được yêu cầu, sau đó mở nó trong một trình soạn thảo text như Notepad.

Hãy xem các đoạn mã trong hộp thoại dưới đây:

//Copyright (c) 1997-2004 Microsoft Corporation
BackupRoute="DIRECT";
UseDirectForLocal=true;
function MakeIPs(){
}
DirectIPs=new MakeIPs();
cDirectIPs=0;
function MakeNames(){
}
DirectNames=new MakeNames();
cDirectNames=0;
HttpPort="8080";
cNodes=1;
function MakeProxies(){
this[0]=new Node("10.245.10.254",0,1.000000);
}
Proxies = new MakeProxies();
function Node(name, hash, load){
this.name = name;
this.hash = hash;
this.load = load;
this.score = 0;
return this;
}
function FindProxyForURL(url, host){
var urlhash, urllower, ibest, bestscore, list, i, j, port=HttpPort;
urllower = url.toLowerCase();
if((urllower.substring(0,5)=="rtsp:") ||
(urllower.substring(0,6)=="rtspt:") ||
(urllower.substring(0,6)=="rtspu:") ||
(urllower.substring(0,4)=="mms:") ||
(urllower.substring(0,5)=="mmst:") ||
(urllower.substring(0,5)=="mmsu:"))
return "DIRECT";
if (UseDirectForLocal && isPlainHostName(host))
return "DIRECT";
if (cDirectNames > 0)
for (i = 0; i < cDirectNames; i++)
if (shExpMatch(host, DirectNames[i]))
return "DIRECT";
if (cDirectIPs > 0)
for (i = 0; i < cDirectIPs; i += 2)
if (isInNet(host, DirectIPs[i], DirectIPs[i+1]))
return "DIRECT";
urlhash = HashString(url);
for (i = 0; i < cNodes; i++)
Proxies[i].score = Proxies[i].load * Scramble(MakeInt(urlhash ^ Proxies[i].hash));
list = "";
for (j = 0; j < cNodes; j++) {
for (bestscore = -1, i = 0; i < cNodes; i++) {
if (Proxies[i].score > bestscore) {
bestscore = Proxies[i].score;
ibest = i;
}
}
Proxies[ibest].score = -1;
list = list + "PROXY " + Proxies[ibest].name + ":" + port + "; ";
}
list = list + BackupRoute;
return list;
}
function HashString(url){
var h = 0;
var slashes = 0;
for (var i = 0; i < url.length; i++) {
var c = url.charAt(i);
if (c == '/')
slashes++;
if (slashes < 3)
c = c.toLowerCase();
h += (((h & 0x1fff) << 19) | ((h >> 13) & 0x7ffff)) + CharToAscii(c);
h = MakeInt(h);
}
return h;
}
function Scramble(h){
h += ((h & 0xffff) * 0x1965) + ((((h >> 16) & 0xffff) * 0x1965) << 16) + (((h & 0xffff) * 0x6253) << 16);
h = MakeInt(h);
h += (((h & 0x7ff) << 21) | ((h >> 11) & 0x1fffff));
return MakeInt(h);
}
var Chars =" !\"#$%&\'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\\]^_`abcdefghijklmnopqrstuvwxyz{|}~€ ???????????Ž????????????ž? ¡¢£¤¥¦§¨©ª«¬®¯°±²³´µ¶·¸¹º»¼½¾¿ÀÁÂÃÄÅÆÇÈÉÊËÌÍÎÏÐÑÒÓÔÕÖ×ØÙÚÛÜÝÞßàáâãäåæçèéêëìíîïðñòóôõö÷øùúûüýþ ";
function CharToAscii(c){
return Chars.indexOf(c) + 32;
}
function MakeInt(x){
if (x < 0) {
return x + 4294967296;
} else if (x >= 4294967296) {
return x - 4294967296;
}
return x;
}

Vậy đoạn mã trên mang lại điều gì? Trình duyệt của bạn được cấu hình vị trí của script này sẽ download và thực thi nó. Script được chạy với mã với màu đỏ và thiết lập một số biến mở rộng, chạy một số hàm (màu tím). Khi nào trình duyệt cần yêu cầu một URL, nó sẽ gọi hàm FindProxyForURL (màu cam). Hàm này trả ra một proxy server để gửi yêu cầu URL tới hoặc thông báo "DIRECT", tức là không dùng Proxy cho URL này.

Tất cả mã màu xanh là gì? FindProxyForURL gọi các hàm này để tạo bảng băm từ URL và tính toán giá trị cho từng proxy nó biết. Hàm FindProxyForURL thực tế trả ra một danh sách các proxy có mức điểm cao nhất ở đầu và hướng sao lưu được cấu hình ở cuối. Trình duyệt sẽ dùng proxy có mức điểm cao nhất này để gửi yêu cầu URL tới. Đó là hoạt động của client-side CARP.

Script đến từ ISA Server Standard Edition, vậy tất cả mã băm này dùng để làm gì? Hoàn toàn chẳng để làm gì cả! Nếu bạn xem kỹ phần bắt đầu, bạn sẽ thấy có một hàm (màu tía) gọi là MakeProxies, lập danh sách ISA Server tạo ra script. Chỉ có một proxy được lập danh sách ở đây, vì thế script phải luôn luôn trả lại proxy. Như chúng ta đã biết, Microsoft thích dùng các bộ vi xử lý để chạy toàn bộ các mã không cần thiết. Trong ví dụ này, trình duyệt nghèo nàn của chúng ta đã thực thi phần lớn các mã không dùng đến trong toàn bộ thời gian yêu cầu URL, có lẽ là một vài lần cho một trang Web. Sự trợ giúp nhỏ nhưng không cần thiết với chúng ta song họ không có ý định ngừng lại!

Tạo một script cấu hình tuỳ chọn cơ bản

Mặc dù có vẻ khó, nhưng bạn hoàn toàn có thể làm được. Tất nhiên vấn đề thực sự là lấy được script kết quả ra từ trình duyệt trên client nhưng chúng ta sẽ quan tâm đến nó sau. Chúng ta cũng sẽ đề cập đến các vấn đề chỉnh sửa thông minh ở phần 2, còn bây giờ chỉ tạo một script chức năng cơ bản.

Hãy cùng xem các dòng sau trong script download được từ ISA Server:

cNodes=1;
function MakeProxies(){
this[0]=new Node("10.245.10.254",0,1.000000);
}

"10.245.10.254" là địa chỉ ISA Server của chúng tôi lấy trong ví dụ minh hoạ này. Khi bạn thực hiện, địa chỉ IP này sẽ được thay thế bằng địa chỉ ISA Server riêng của bạn. Có thể bạn sẽ có tên miền đáp ứng được đầy đủ điều kiện nữa, cả hai đều tốt.

Bây giờ hãy sửa các dòng sau, gồm cả ISA Server thứ hai của bạn.

cNodes=2;
function MakeProxies(){
this[0]=new Node("10.245.10.254",2032180928,1.000000);
this[1]=new Node("10.245.10.253",2843172549,1.000000);
}

Có một vài con số nghe chừng có vẻ khó hiểu. Chúng được thêm vào để thuật toán băm chọn proxy hoặc một lựa chọn khác trong khoảng 50/50 kiểu, tuỳ thuộc vào URL yêu cầu. Ở phần sau chúng ta sẽ tìm hiểu các con số đó đến từ đâu, còn bây giờ thì cứ tạm công nhận để dùng.

Cổng HTTP

Xem kỹ lại, bạn sẽ thấy dòng tương tự như thế này:

HttpPort="8080";

Thông số này nói rằng, cổng các Server ISA của bạn đang nghe yêu cầu proxy là 8080. Chỉ có một điểm vào, có nghĩa là tất cả các nút phải được cấu hình dùng cùng một cổng. Cổng "8080" được đặt mặc định và ít khi cần phải thay đổi nó.

Triển khai một script cấu hình tuỳ chọn

Có hai cơ chế đưa script vào trình duyệt trên client: hoặc là cấu hình chúng dùng chức năng "dò tìm tự động", hoặc là cung cấp vị trí cho "script cấu hình tự động". Trước đó, bạn cần đưa script của mình lên một website phù hợp mà trình duyệt của bạn có thể truy cập tới.

Nếu muốn có các proxy dư để dự trữ, bạn cần website dư để đặt file cấu hình hoặc có một điểm lỗi đơn. Để minh hoạ một cấu hình cần thiết, chúng ta sẽ thực hiện từng bước bằng cách tạo một website IIS đơn. Nhưng bạn hoàn toàn có thể dùng website Intranet fault-tolerant hoặc bất kỳ hình thức phù hợp nào khác.

Đầu tiên là tạo mới một website IIS Manager:

Bước tiếp theo trong Web Site Creation Wizard là cung cấp cho website một tên mô tả. Ở đây tôi dùng tên WPAD.

Trong trang tiếp theo bạn có thể đưa ra một địa chỉ IP cụ thể (hoặc để nó lại như ở đây). Bạn nên gắn địa chỉ IP này với cổng 80 vì có một thành phần tự động phát hiện cần cổng này (chúng ta sẽ thảo luận trong phần hai). Một host header là cần thiết vì cổng 80 có thể được chia sẻ bởi các server ảo khác.

Nhớ rằng bạn phải có giải pháp DNS (hệ thống tên miền) ở mọi địa chỉ dùng cho host-header. Có thể bạn sẽ có hai điểm vào trỏ tới hai website (DNS round-robin) hoặc trỏ bản ghi tới một cân bằn tải IP ảo hoặc nếu không thì dùng bất cứ kỹ thuật chiếm website fault-toterlant nào bạn có được.

Theo đó, bạn cần cung cấp vị trí cho file và chú ý là website này phải cho phép truy cập nặc danh. Trang Wizard tiếp theo sau là các quyền truy cập. Với website này bạn chỉ cần quyền đọc - "Read" (không cần script, thực thi hay ghi).

Trong phần kết thúc Wizard sẽ hoàn chỉnh cấu hình thiết yếu cho website. Vấn đề sau đó chỉ là copy script cấu hình của bạn vào vị trí phù hợp (ở đây là C:\Inetpub\wpadroot) và đảm bảo tài khoản truy cập nặc danh (thường là IUSR_Servername) đã đọc quyền truy cập vào vị trí file này.

Bạn nên kiểm tra lại toàn bộ bằng cách đưa đường dẫn tới file và download nó (trong ví dụ này đường dẫn URL sẽ là http://wpad.company1.local/wpad.dat).

Tôi đặt tên cho script cấu hình là WPAD.DAT mặc dù không có yêu cầu nào đòi hỏi bạn phải gọi như thế.

Cấu hình Internet Explorer để dùng các Configuration Script

Cấu hình Internet Explorer một cách "thủ công" để dùng file cấu hình không mấy khó khăn. Bắt đầu bằng việc chọn thành phần Internet Options trên menu Tools.

Chúng ta cần tuỳ chọn Lan Settings, được tìm thấy ở trang Connections.

Nhập đường dẫn URL trỏ tới file WPAD.DAT bạn đã tạo và kích OK.

Kết thúc. Trỏ đường dẫn tới một website Internet và trình duyệt sẽ bắt đầu dùng script cấu hình để chọn proxy gửi yêu cầu tới, như thế này:

Có lẽ tôi đã cấu hình ISA Server của mình theo đúng quy tắc, nhưng không gì chứng minh rõ ràng nhất rằng bạn sẽ thông qua một ISA Server bằng trang nhỏ này.

Tất nhiên, nếu có tới 100 máy khách, chắc chắn bạn sẽ không muốn phải cấu hình "một cách thủ công" các trình duyệt này. Group Policy là lựa chọn tốt cho bạn. Nhưng chúng ta sẽ thảo luận tiếp trong phần hai. Cũng trong phần hai chúng ta sẽ xem xét các tuỳ chọn cấu hình tự động khác (Automatically detect settings), nhưng xin được báo trước là sẽ có một số tranh cãi về vấn đề này.

Kết luận

Trong bài này chúng ta đã chỉnh sửa script cấu hình do ISA Server 2004 Standard Edition cung cấp và triển khai nó cho các client brower. Kết quả là có hai hay nhiều hơn ISA Server Standard Edition Web proxy có thể cân bằng tải hiệu quả, dùng client-side CARP. Nếu một ISA Server proxy bị mất, nó sẽ được chuyển đổi qua các "bạn" của mình một cách nhanh chóng.

Phần thông tin trên đây là tất cả những gì bạn cần để lắp đặt và chạy. Trong phần hai chúng ta sẽ xem xét tới một số chỉnh sửa nâng cao hơn của các script custom (kịch bản tuỳ chọn). Chúng tôi sẽ minh hoạ một số thay đổi "thủ công" ở các thành phần khác trong script vì ISA Server sẽ không làm gì với chúng hơn nữa. Chúng tôi cũng sẽ giới thiệu khái niệm "CARP Exception", một thành phần trong Enterprise Edition để giúp bạn tránh các vấn đề gặp hải với một số website.

Nhưng trước khi kết thúc, các bạn nên…

Tính toán giá trị băm cho các nút Proxy

Nếu nhớ, bạn sẽ thấy có hai con số "ma thuật" được nhập trong script mà thuật toán băm sẽ dùng để đảm bảo mỗi ISA Server có được sự chia sẻ công bằng khi load. Các số này là 2032180928 và 2843172549. Thực tế, chúng ta chưa thể biết được các số này được tính toán ra từ đâu.

Tôi đã thử nghiệm, cài đặt phiên bản 120 ngày của ISA Server 2004 Enterprise Edition lên một số máy ảo và kiểm tra giá trị trong file WPAD.DAT download từ một trong các server. Tuy có phần mang tính chất "gian lận", nhưng lại rất hiệu quả!
Bạn có thể dùng một số thủ thuật để thăm dò các giá trị khác trong script, nhưng bạn không thể cài đặt được ISA Server 2004 Service Pack 2. SP2 giới thiệu các thay đổi trong Enterprise Edition, gồm cả thuật toán băm nâng cao trong script cấu hình. Vì vậy, bạn nên dùng các phiên bản trước SP2 để đỡ phải đau đầu với thay đổi của nó.

Dù sao thì, con số "ma thuật" của ISA Server trong mảng 3804533832 và các số khác vẫn giống như vậy.

Xem tiếp phần II