Cấu hình WebServer (IIS; Apache) trước Tomcat

Chạy Tomcat server phía sau Web server có thể là một trong số các yêu cầu bắt buộc bạn nhận được nếu bạn muốn đạt được hiệu năng tối đa và tính ổn định. Bài viết này mô tả hướng dẫn cách tốt nhất làm thế nào để thực hiện điều đó.

By Mladen Turk

Nguồn : https://people.apache.org/~mturk/docs/article/ftwai.html

Fronting Tomcat

Ở đây thì hẳn các bạn đọc sẽ tự hỏi là tại sao phải cần làm vậy ? Tại sao phải đặt 1 Web server lên trước Tomcat ? Với sự hỗ trợ của kĩ thuật mới nhất trong Java Virtual Machines (JVM) và Tomcat core, bản thân hiệu năng của Tomcat đã có thể khá tương đương với các native web server. Thậm chí, khi xét đến các nội dung tĩnh, Tomcat cũng chỉ chậm hơn các bản Apache 2 gần đây khoảng 10%. Vậy câu trả lời chính là : scalability (khả năng mở rộng)

Tomcat có thể handle khá nhiều truy cập đồng thời bằng cách phân phối các thread xử lý riêng biệt đến mỗi connection của các client đồng thời. Nó có thể làm việc này rất tốt nhưng có khá nhiều vấn đề khi số lượng connection tăng lên. Thời gian mà OS phải dành để quản lý các thread này sẽ làm degrade hiệu năng của toàn thể hệ thống. JVM cũng sẽ phải dùng nhiều time/cost hơn để quản lý và switch các thread đồng thời với việc chính của nó - xử lý các request.

Bên cạnh vấn đề kết nối, còn có một vấn đề nghiêm trọng hơn, gây nên bởi các ứng dụng chạy trên Tomcat. Một ứng dụng điển hình sẽ xử lý các dữ liệu client, truy cập vào DB, tính toán các kiểu và trả lại dữ liệu cho client. Tất cả những việc trên phải được hoàn thành trong chậm nhất là 0.5s để cho user có thể nhận thức được ứng dụng vẫn đang chạy. Một thống kê toán học đơn giản cho thấy với một ứng dụng có time response là 10ms, bạn sẽ có thể handle được tối đa 50 user đồng thời để cho user ko phàn nàn gì về ứng dụng. Sẽ có vấn đề là thế làm thế nào để ứng dung có thể support được nhiều user hơn ? Cách đơn giản nhất là mua hardware xịn hơn, cho thêm CPU các kiểu v.v....

Đầu tiên sẽ là giảm bớt tải ở Tomcat bằng cách sử dụng Webserver để handle các dữ liệu tĩnh như ảnh, v.v…

Hình trên cho ta thấy mô hình config đơn giản nhất có thể được. Web server sẽ được sử dụng để handle các context tĩnh trong khi Tomcat thì chỉ việc xử lý các ứng dụng. Với môt hình này bạn có thể serve 200 users, 3.5 million hits mỗi ngày đồng thời với ứng dụng có response là 10ms.

Thông thường bạn sẽ ko cần phải config một web server trước Tomcat. Đây chính là lý do bạn cần phải làm việc, đó chính là "việc tạo nên một DMZ (demilitarized zone). Đặt một Web server trên một host được insert một "neutral zone" giữa một hệ thống mạng private và internet or là một network public phía ngoài sẽ giúp cho ứng dụng chạy Tomcat của bạn có thể xử lý các dữ liệu private bên trong nội bộ công ty.

Bên cạnh việc có DMZ và đảm bảo security cho việc access các dữ liệu thuộc mạng private, có khá nhiều yếu tố khác nữa ví dụ như việc custome authen.

Nếu bạn cần handle nhiều tải hơn nữa, cuối cùng thì bạn cũng phải add thêm server Tomcat ứng dụng. Lý do là hoặc là lượng tải client quá lớn ko thể xử lý được với bằng 1 box, cũng có thể là bạn cần một giải pháp backup failover trongg trường hợp một nút có vấn đề.

Cấu hình một ưng dụng có nhiều server Tomcat sẽ cần thiết tới một Load Balancer ở giữa Web server và Tomcat. Với Apache 1.3, Apache 2.0 và IIS bạn có thể sử dụng Jakarta Tomcat Connector (JK) bởi vì nó cung cấp cả việc phân tải ứng dụng và các session. Với bản Apache 2.1/2.2 sử dụng mod_proxy_balancer - đây là một module mới được thiết kế và tích hợp trong Apache httpd core.

Tính toán tải

Khi đã quyết định được số lượng Tomcat server mà bạn cần phải config để thỏa mãn tải trọng của client, việc đầu tiên là là xác định Time Response trung bình ( Average Application Response Time AART). Như ở trước đã đề cập đến, để thỏa mãn được các vấn đề về trải nghiệm người thì ứng dụng phải respond chỉ trong vòng nửa giây. Các content nhân được bởi browser client sẽ thường trigger một vài request vật lý đến Webserver (ví dụ ảnh ). Các trang web thường bao gồm html; dữ liệu ảnh, do đó client sẽ phát sinh một chuỗi request và tổng thời gian mà chuỗi request đó đc xử lý và trả về được gọi là AART. Để tạo được hiệu suất chuẩn nhất của Tomcat bạn nên giới hạn số request đồng thời là 200 / 1 CPU.

Một vấn đề khác bạn cần phải chú ý là lưu thông mạng (network throughput) giữa web server và tomcat instances. Ở đây ta có một khái niệm mới là Trung bình kích thước của Response ( Average Application Response Size AARS), đây là số lượng bytes của tất cả các context trong 1 trang web trả về cho user. Với chuẩn card mạng 100Mbps với 8 Bits per Byte, số lượng throughput tối đa theo lý thuyết là 12,5MB.

Với một 20KB AARS sẽ cho tối đa 625 request đồng thời. Bạn có thể tăng thêm card mạng hoặc sử dụng phần cứng nhanh hơn 1Gps nếu cần xử lý nhiều tải hơn.

Các tính toán trên sẽ cung cấp cho bạn một vài con số ước lượng thô sơ của Tomcat box và CPU mà bạn sẽ cần để handle số lương request đồng thời mong muốn.

Fronting Tomcat with Apache

Nếu bạn cần đặt Apache lên trước Tomcate , sử dụng Apache2 với worker MPM. Bạn có thể sử dụng Apache1.3 hoặc Apache2 với prefork PMP để xử lý các config đơn giản như hình 1. Nếu bạn sử dụng một vài box Tomcat và chạy load balancer nên sử dụng Apache2 và worlker MPM.

MPM hay Multi-Procession Module chính là tính năng cốt lõi của Apache2 và nó chịu trách nhiệm cho việc kết hợp đến các port network trên máy tính, accept request và dispatch đến handle requests. Trình biên dịch có khả năng tối ưu hóa nhiều chức năng nếu sử dụng thread. Apache luôn chạy tốt hơn nếu MPM được selected lúc config và built trong Apache.

Worker MPM cung cấp tính scalability tốt hơn hẳn so với các cơ chế preforl tiêu chuẩn - nơi mỗi client connection sẽ tạo nên một process Apache tách biệt. Nó kết hợp những gì tốt nhất, có một tập hợp các process con và mỗi process con lại có một tập hợp các thread tách rời. Có một số trang web đang chạy 10K+ connection đồng thời đang áp dụng công nghệ này.

Connecting to Tomcat

Trường hợp đơn giản nhất là khi bạn cần phải kết nối một instance Tomcat, bạn có thể sử dụng mod_proxy trong Apache. Tuy nhiên, sử dụng mod_jk connector sẽ cung cấp gần như gấp 2 hiệu năng. Có 1 vài lý do cho việc này và lý do chính là vì mod_jk quản lý các pool kết nối liên tục tới Tomcat, do đó tránh được việc phải open và close kết nối thường xuyên cho mỗi request tới Tomcat. Lý do tiếp theo là mod_jk sử dụng protocol tên là AJP , cho phép tránh được việc "gắn" và "gỡ" các header param cho mỗi request đã được xử lý ở Web server. Bạn có thể tìm hiểu thêm về giao thức AJP trong các trang về kết nối Jakarta Tomcat.

Bạn chỉ nên dùng mod_proxy nếu website đó có tải thấp or là với mục đích thử nghiệm test.

Load balancing

Load balancing là một trong số những phương thức để nâng cao số lượng connections đồng thời đến server ứng dụng của bạn. Có 2 loại load balancer mà bạn có thể sử dụng. Đầu tiên là loại load balancer phần cứng và lọai thứ 2 là load balancer phần mềm. Nếu bạn sử dụng hardware, thay vì sử dụng mod_jk hay proxy, nó bắt buộc phải support cơ chế cookie, SSL.

Mod_jk là một lạoi worker load balancer tích hợp ảo chứa rất nhiều worker vật lý or các nodes vật lý. Mỗi nodes có thể có factor balance của riêng nó hoặc là một lượng quota của worker hoặc là lbfactor. Lbfactor chính là một dạng khác của work quota của worker - bạn mong muốn worker làm việc bao nhiêu thì đó chính là Lbfactor. Param này thường phụ thuộc vào topology của phần cứng, và nó thường tạo nên một cluster với cấu hình node phần cứng khác nhau. Mỗi Lbfactor được so sánh với tất cả các lbfactor khác trong cluster và mối quan hệ của nó tạo nên "tải thực" (actual load). Nếu các Lbfactor tương đương nhau thì các worker load cũng sẽ tương đương nhau.

Sticky sessions and failower

Một trong những vấn đề với việc có nhiều server ứng dụng backend chính là việc quyết định mối quan hệ client-server. Một khi client tạo một request đến server mà bạn cần phải track action của user trong một khoảng time được chỉ định trước, một số trạng thái phải được thực thi bên trong giao thức http. Tomcat sẽ sinh ra một session định danh unique cho mỗi user. Vấn đề ở đây là với session định danh là nó ko mang bất kì thông tin nào về instance Tomcat mà nó được sinh ra.

Tomcat trong trường hợp này sẽ add thêm một giá trị jvmRoute đến session đó. jvmRoute có thể được đặt bất kì một cái tên nào và sẽ unique theo instance Tomcat. mod_jk sẽ sử dụng jvmRoute như lafteen của worker trong danh sách load balancer của nó. Điều này cho thấy rằng tên của worker và jvmRoute là tương đương.

jvmRoute is appended to the session identifier :
http://host/app;jsessionid=0123456789ABCDEF0123456789ABCDEF.jvmRouteName

Khi có nhiều nodes trong một cluster, bạn có thể cải thiện độ availability ứng dụng của bạn bằng cách sử dụng failover. Failovercho phép nếu một node nào đấy ko thể đáp ứng được request, sẽ có một node khác được thay thế một cách tự động. Trong trường hợp 3 nodes, bạn luôn đảm bảo được bạn đã tăng gấp 2 khả năng availability của ứng dụng. Thời gian response của ứng dụng sẽ chậm hơn trong thời gian failover, nhưng ko có bất kì user nào của bạn ko truy cập được web của bạn. Trong mod_jk có một param đặc biệt gọi là worker.retries có giá trị default là 3, nhưng giá trị này cần được điều chỉnh theo số lượng nodes thực tế của cluster.

Domain Clustering model

Kể từ phiên bản JK 1.2.8 có một model phân nhóm tên miền và nó cho phép scalability và hiệu năng của tomcat cluster theo chiều ngang.

Tomcat cluster chỉ cho phếp session replication tới tất cả các nút trong cluster. Khi bạn làm việc với nhiều hơn 3-4 nodes, sẽ có rất nhiều phí và rủi ro trọng việc replica các session đến tất cả các nodes đó. Chúng ta sẽ chia các nút thành các group clusted. Và một worker attribute domain sẽ cho phép mod_jk biết được "một sessions được replicated ở node nào" (tất cả các worker cso cùng giá trị trong domain attribute). Thông qua việc đó load balancing worker sẽ biết được sessions còn đang sống trên nodes nào. nếu một node bị chết or bị chiếm quyền, mod_jk sẽ chọn một node khác mà có bản replica sessions.

Fronting Tomcat with IIS

Cũng giống như Apache Web server, đối với Windows, Microsoft IIS duy trì các process con tách biệt và các pool thread để phục vụ các kết nối đồng thời từ clients. Đối với một server ko phải products như Windows 2000 Professional or Windows XP, số lượng kết nối đồng thời được giới hạn tới 10. Điều này cho thấy rằng bạn ko thể sử dụng workstation products chó productions server trừ khi 10 kết nối là quá đủ đối với như cầu của ứng dụng của bạn. Với sản phẩm products server thì nó cũng giới hạn như Apache, 2000 kết nối là max. Nếu bạn muốn tải cao hơn , bạn cần phải deploy thêm server web nữa và sử dụng Windows Network Load Balancer (WNLB) ở trước Tomcat.