Sáu câu hỏi đáng quan tâm nhất khi chạy WebSphere trên Linux

Bài này sẽ cung cấp những câu trả lời hữu ích nhất, giúp bạn phát triển và triển khai WebSphere® trên nền Linux® cho các ứng dụng System z™, bao gồm cả vấn đề về các bản update của phiên bản sản phẩm hiện thời mới được cung cấp trong tháng 10 năm 2006. Phần hỏi và trả lời kỹ thuật chủ yếu xoay quanh các phân phối Linux 64 bit, thiết bị JDBC, các heap size và CPU.

1, Dùng WebSphere với DB2 trên các hệ thống Linux 64 bit như SLES V9 hay RHEL V4 như thế nào?

Nếu có kế hoạch cài đặt WebSphere lên hệ điều hành Linux 64 bit on System z (z/OS), bạn nên chọn một trong các phương thức kết nối tới DB2 sau:

• Universal Java™ Database Connctivity (JDBC) Driver Type 4
• Universal JDBC Driver Type 2 và DB2 Connect

Dùng thiết bị JDBC Type 2 (hoặc thiết bị ứng dụng kế thừa hay Universal Driver Type 2) đòi hỏi phải cài đặt client DB2 trên cùng hệ thống với WebSphere. Dùng DB2 Connect liên kết với DB2 trên z/OS hoặc DB2 UDB trên Linux đều được, vì WebSphere 6.0.2 và các phiên bản trước đó của nó chạy trên mô hình 31 bit (có khi trên cả Linux 64 bit). Các kiểu mô hình này đòi hỏi DB2 client 31 bit.

Trước khi cài đặt BD2 client, bạn phải download và cài đặt DB2 version 8, Fixpack 10. Gói sửa chữa Fixpack 10 này gồm client DB2 31 bit thời gian thực, có thể cài đặt trên hệ điều hành Linux 64 bit để bắt liên lạc với ứng dụng WebSphere 31 bit.

Trên các phiên bản DB2 trước Fixpack 10, bộ cài đặt DB2 không cho phép bạn cài DB2 client 31 bit vào hệ điều hành Linux on System z (z/OS) 64 bit. Một lỗi sẽ được trả lại: Error: Platform Specific Installer not Found (Không tìm thấy Platform cài đặt riêng).

2, Để truy cập DB2 trên z/OS, tôi nên dùng thiết bị JDBC Type 2 và DB2 Connect, hay là dùng Universal JDBC Driver Type 4?

Bạn nên dùng thiết bị mới nhất gần đây Univeral JDBC Driver Type 4 cho tất cả ứng dụng WebSphere truy cập dữ liệu DB2 trên hệ điều hành z/OS vì ba lý do sau.

Trước hết, Universal JDBC Driver Type 4 là thiết bị thuần Java, không đòi hỏi phải cài đặt DB2 Connect để truy cập DB2 trên hệ điều hành z/OS. Bạn cần phải có "chứng chỉ" DB2 Connect rồi mới dùng được Driver Type 4 để truy cập thẳng trực tiếp DB2 trên hệ điều hành z/OS. (DB2 Connect cung cấp một file chứng chỉ cần thiết trong CLASSPATH).

Thứ hai, dựa trên tỷ lệ thông lượng nội bộ người ta đã xác định được tốc độ và khả năng thực thi của thiết bị loại 4 tốt hơn 10% so với loại 2 và DB2 Connect.Thứ ba, DB2 Connect không có những cải tiến chức năng so với Universal JDBC Type 4, như:

• DB2 Connect thuộc hệ thống kiểu sysplex-aware còn JDBC Type 4 thì không. Nếu điểm trở lại của DB2 trên hệ điều hành z/OS là nhóm chia sẻ dữ liệu DB2 trong một hệ thống tổng hợp (sysplex) và bạn dùng bộ tập trung kết nối DB2 Connect Connection Concentrator, các thành viên nhóm chia sẻ dữ liệu DB2 sẽ tương tác với Workload Manage (WLM) để thu thập liên tục dữ liệu sử dụng tài nguyên và đưa nó trở lại DB2 Connect. Khi trả ra, DB2 dùng thông tin đó để thực hiện các quyết định workload cân bằng mức giao vận, có tính chất rất tốt.

• Một máy khách Linux đơn có thể chạy DB2 Connect và điều khiển các kết nối từ nhiều máy khách Linux khác. Đây được gọi là cơ chế "cổng vào" (gateway) DB2 Connect. Với thành phần Connection Concentrator, một cổng vào DB2 Connect đơn có thể đạt được nhiều hiệu quả khi tập trung các kết nối lại hơn là phân tách từng phiên DB2 Connect ra. Bạn có thể cài đặt DB2 Connect theo kiểu cấu hình sẵn sàng cao (High Available - HA), dùng bản sao lưu DB2 Connect để tránh lỗi điểm đơn.

Phiên bản hiện tại của thiết bị kiểu 4 (Type 4) có nhiều thành phần WLM trong DB2 Connect, gồm các nhận dạng hệ thống tổng hợp (sysplex awareness) và tập trung kết nối. JDBC Type 4 mức 2.7 hoặc mới hơn đòi hỏi phải có tính năng sysplex awareness. Phiên bản này gắn với DB2 version 8.2 Fixpack 3, DB2 version 8.1 Fixpack 10 hoặc mới hơn.

DB2 Connect có thể vẫn cung cấp giá trị như là một bộ tập trung kết nối qua nhiều máy khách Linux. Nhưng vì WebSphere đã có kết nối pooling nên giá trị của chức năng tập trung kết nối này trở nên mờ nhạt.

3, Những phiên bản Linux nào hỗ trợ WebSphere Application Server 64 bit?

Vấn đề này hơi rắc rối một chút.

WebSphere Application Server 5.1.1 là phiên bản đầu tiên hỗ trợ các phân phối 64 bit. WebSphere Application Server 31 bit còn tiếp tục được sử dụng trên phân phối 31 bit của Suse Linux Enterprise Server (SLES) 8 hoặc Red Hat Enterprise Linux (RHEL) 3. Nhưng ứng dụng WebSphere Application Server 31 chỉ chạy trên các phân phối 64 bit của SLES 9 hoặc RHEL 4. Các bản trước 5.1.1 của WebSphere Application Server chỉ chạy như là một sản phẩm 31 bit trên các phân phối 31 bit của SLES 8 hoặc RHEL 3.

Từ phiên bản WebSphere Application Server 5.0.2 trở về sau, thành phần này chạy trên các phân phối Suse và Red Hat Linux on System z cũng với vai trò của một sản phẩm 31 bit. Với SLES 8 hoặc RHEL 3 (2.4 kernel), ứng dụngWebSphere Application Server 31 bit chỉ chạy trên mức 31 bit. Với SLES 9 hoặc RHEL 4 (2.6 kernel), ứng dụng WebSphere Application Server 31 bit chỉ chạy trên mức 64 bit.

WebSphere Application Server 6.0.2 (được đưa ra từ ngày 28 tháng 10 năm 2005) là phiên bản WebSphere Application Server đầu tiên cung cấp version 64 bit với JVM 64 bit. JVM 64 bit cho phép các ứng dụng có heap size JVM lớn hơn so với mức cực đại hiện nay là 800MB chạy trên các phân phối 31 bit của Linux trên hệ thống System z. WebSphere Application Server 6.0.2 sẵn sàng cho cả version 31 bit và 64 bit.

Chiến lược của IBM là chuyển tất cả phần mềm trung gian (middleware) sang các phân phối Linux 64 bit trên hệ thống System z. Vì thế trong tương lai sẽ có WebSphere Application Server chỉ hỗ trợ các phân phối 64 bit của Linux on System z. SLES 10 chỉ dành cho các phân phối Linux 64 bit.

Bảng 1, 2, 3 dưới đây tóm tắt các phiên bản Linux hỗ trợ trên nhiều version khác nhau của WebSphere Application Server như 5.1.1 hoặc mới hơn.

Bảng 1. Các WebSphere Application Server cơ bản được hỗ trợ trên hệ điều hành

Bảng 2 - Các triển khai mạng WebSphere Application Server Network Deployment hỗ trợ trên hệ điều hành (gồm cả chương trình quản lý triển khai và các thành phần Edge Component).

Bảng 3 - Các triển khai mạng WebSphere Application Server Network Deployment với thành phần Edge Components hỗ trợ trên hệ điều hành

Chú ý:

• Với WebSphere Application Server 6.0.2, vị trí Caching Proxy của Edge Components chỉ được hỗ trợ như là một tính năng 31 bit trên các phân phối Linux 31 bit.
  
• Vị trí Edge Server của Edge Components chỉ được hỗ trợ như là một tính năng 31 bit trên các phân phối Linux.
  
• Với WebSphere Application Server 6.1 (được đưa ra từ ngày 26 tháng 5 năm 2006), không hỗ trợ SLES 8 mà chỉ hỗ trợ SLES 9 (SP2+), RHEL 4 (Update 5+) và RHEL 3 (Update 4+). SLES 10 sẽ được hỗ trợ trong phiên bản 4Q 2006.
  
• Với WebSphere Application Server Network Deployment 6.1, một số thành phần Edge Component được hỗ trợ trên các phân phối Linux 64 bit:
  
  • Các vị trí Edge Server và Load Balancer của Edge Components chỉ có tính năng 64 bit (chạy trong không gian người dùng) trên các phân phối Linux 64-bit WebSphere Application Server 6.1 hỗ trợ (SLES 9 và RHEL 4). Phiên bản kế thừa của Edge Server hoặc Load Balance (chạy trong không gian kernel) vẫn được giữ lại trong phiên bản WebSphere Application Server này như là một tính năng 31 bit trên các phân phối Linux 31 bit WebSphere Application Server 6.1 hỗ trợ (RHEL 3, SLES 9, RHEL 4). Không gian người dùng Load Balance chỉ có chức năng 64 bit trong khi phiên bản legacy chỉ có tính năng 31 bit. Phiên bản legacy, kernel-intrusive của Load Balance không hỗ trợ SLES 10, RHEL 5 hoặc các phiên bản sau. Vì các phân phối đó của hỗ trợ kiểu 64 bit.

• Vị trí Caching Proxy của các thành phần Edge Comonent được hỗ trợ như là tính năng 31 bit trên các phân phối 64 bit Linux. Các thành phần Caching Proxy (có Content Based Routing - bộ định hướng nội dung cơ bản), Site Selector và Consultant bị phản đối. Các tính năng chỉ hỗ trợ 31 bit có thể chạy trên của phân phối Linux 31 bit và 64 bit. Với WebSphere Application Server Network Deployment 6.1, Caching Proxy 31 bit chỉ được hỗ trợ trên RHEL 31 bit, SLES 9 64 bit và RHEL 4 64 bit.

4, Vì sao WebSphere mất nhiều bộ nhớ hơn JVM heap size?

Khi tính toán tổng dung lượng bộ nhớ WebSphere Application Server sử dụng, trung bình ứng dụng server dùng nhiều hơn 100MB so với kích thước dành cho heap Java Virtual Machine. Mức tràn bộ nhớ được tăng dần theo từng phiên bản của WebSphere Application Server. Với WebSphere Application Server version 5, dung lượng dành cho nó là 90MB, còn version 6.1 là 120 MB.

Tất cả mã triển khai WebSphere Application Server đều là Java và chạy trong JVM. Khả năng tràn WebSphere Application Server đến từ các thư viện JVM load để thực hiện các chức năng server ứng dụng và các ứng dụng chạy theo yêu cầu JVM. Vì WebSphere Application Server luôn được bổ sung chức năng theo từng phiên bản nên số lượng thư viện ngày càng tăng.

Theo quan sát của nhiều người dùng thì mức dung lượng lớn nhất dành cho WebSphere Application Server nhiều khi không phải là 120MB như quy định mà lên tới 400MB. Số lượng thư viện JVM phải load khi thực thi WebSphere Application Server và một số tính năng ứng dụng khác là nguyên nhân tăng dung lượng. Chẳng hạn như các ứng dụng dùng bộ phận tin nhắn đòi hỏi JVM phải load các thư viện về message. Các ứng dụng dùng Java Native Interface (JNI) - giao diện tự nhiên Java đòi hỏi JVM phải load thư viện Java. Vì thế việc tốn thêm dung lượng bộ nhớ là bình thường và đã được dự đoán khi thiết kế. Bạn có thể xem các thư viện JVM load bằng một trong các câu lệnh sau:

• pmap
• cat /proc/<waspid>/maps

cat /proc/<waspid>/maps lấy ra được dữ liệu có dạng:

5, Vì sao JVM bị giới hạn kích thước heap size là 800MB?

Các phiên bản 31-bit của WebSphere Application Server (xem các bảng trên) chạy trong mô hình 31-bit. Khi JVM bắt đầu, nó yêu cầu hệ điều hành cung cấp khoảng bộ nhớ lớn để dùng cho JVM heap. Các chương trình 31-bit chỉ có thể địa chỉ hoá 2GB bộ nhớ. Linux phát hiện được JVM là một chương trình 31-bit và đưa ra các nguyên tắc phân phối bộ nhớ cho từng chương trình đơn. Theo các nguyên tắc đó thì tổng lượng bộ nhớ lớn nhất cho bất kỳ chương đơn 31-bit nào là khoảng 800MB. Dù là kiểu 64-bit hay 31-bit, Linux đều áp dụng nguyên tắc xác định dung lượng bộ nhớ cấp phát cho JVM giống nhau. Nếu khởi động JVM với heap JVM tối đa lớn hơn 800MB dung lượng cấp phát thì sẽ xuất hiện lỗi vì Linux từ chối cấp phát lượng bộ nhớ lớn hơn đó.

Tuy nhiên, bạn có thể thay đổi nguyên tắc của Linux bằng cách thay đổi thiết lập mapped_base trong phiên bản Suse Linux Enterprise Server (mapped_base không được hỗ trợ trong các phân phối RedHat). Khi đó, kích thước heap tối đa có thể từ 1100MB đến 1200MB.

Nếu bạn muốn heap size JVM lớn hơn nữa, hãy dùng version WebSphere Application Server hỗ trợ đầy đủ các JVM 64 bit như version 6.0.2 hoặc mới hơn.

6, Vì sao một server WebSphere version 6 thụ động có thể dùng bất kỳ CPU nào cũng được?

Những khoảng thời gian nhàn rỗi nhỏ của CPU thường không được để lại cho các platform khác biết, vì chúng sử dụng nhiều server chuyên dụng cho WebSphere. Nhưng trên Linux on System z, một CPU được chia sẻ cho nhiều người dùng. Tác động dồn lại của nhiều server WebSphere nhàn rỗi có thể đáng phải chú ý. WebSphere version 5 có độ nhàn rỗi là 1% CPU hoặc ít hơn. Nhưng cũng có lúc một WebSphere version 6 khách nhàn rỗi tới 4% CPU.

WebSphere version 6 có nhiều thành phần nâng cao. Nhưng những thành phần này lại chính là nguyên nhân khởi chạy luồng tiến trình nền, làm tăng mức nhàn rỗi CPU của WebSphere server. Luồng tiến trình nền chạy khi có các thành phần WebSphere sau:

• Trong WebSphere Application Server Network Deployment, thành phần Deployment Manager đồng bộ nơi lưu trữ cấu hình với tất cả tác nhân node trong ô của nó. Bạn có thể tắt thành phần này, khoảng thời gian đồng bộ sẽ thay đổi trong Deployment Manager.
  
• Trong WebSphere Application Server Network Deployment, từng tác nhân node giám sát các server ứng dụng trong nút của nó, dùng "heartbeats". Bạn có thể thay đổi khoảng thời gian này trong Deployment Manager.
  
• Trong WebSphere Application Server Network Deployment, thành phần quản lý High Availability Manager (thành phần mới ở WebSphere Application Server version 6) phát hiện và kiểm tra định kỳ các tiến trình trong cùng nhóm lõi. Điều này không được làm một cách thứ tự (như Deployment Manager với các tác nhân nút hay các tác nhân nút cho server). Thay vào đó là kiểu kết nối mạng lưới: tất cả thành viên nhóm lõi đều có thể giám sát thành viên của nhóm lõi khác. Ví dụ như luồng High Avaiability Manager đang chạy dưới đây:
  
  
  • Mạch dò tìm lỗi sử dụng các heartbeat tích cực cho tất cả thành viên khác của nhóm lõi. Thời gian heartbeat mặc định là 30 giây. Bạn có thể thay đổi nó bằng cách dùng thuộc tính tuỳ chọn: IBM_CS_FD_PERIOD_SECS. Trong console quản trị, vào Servers > Core groups > Core group settings > core_group_name. Dưới Additional Properties, kích vào Custom Properties.
    
  • Mạch phát hiện truy vấn danh sách thành viên nhóm lõi và kết hợp với thông tin mạng từ các thiết lập cấu hình WebSphere Application Server. Sau đó nó cố gắng mở các kết nối mạng tới tất cả thành viên nhóm lõi khác. Trong từng chu kỳ thời gian, giao thức phát hiện sẽ tính toán lại tập hợp thành viên không kết nối và cố gắng mở kết nối tới các thành viên đó. Khoảng thời gian này là 15 giây với WebSphere Application Server 6.0.0 và 6.0.1, còn version 6.0.2 là 30 giây. Bạn có thể thay đổi thông số này bằng cách dùng thuộc tính tuỳ chọn IBM_CS_UNICAST_DISCOVERY_INTERVAL_SECS.
    
  • Mạch thăm dò High Availability Manager hiện tại không có khả năng cấu hình.

High Availability Manager không thực sự tồn tại trong cấu hình WebSphere Application Server cơ sở. Vì thế không có quá trình thăm dò hay phát hiện nào diễn ra.

• Trong WebSphere Application Server version 6 cơ sở, một số mạch làm sạch được chạy. Gồm:
  
  • Mạch làm sạch bộ nhớ cache chứa EJB
  • Luồng thu hoạch chung kết nối J2C
  • Mạch làm sạch cache động

Các mạch này vẫn chưa có khả năng cấu hình.