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

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
31-bit 64-bit
WebSphere
Application
Server cơ
bản
SLES8

RHEL3

SLES9

RHEL4

SLES8

RHEL3

SLES9

RHEL4

SLES10

31-bit
WebSphere
Application
Server
5.1.1
Y Y N N N N Y Y N
31-bit
WebSphere
Y Y N N N N Y Y N
Application
Server 6.0
31-bit
WebSphere
Application
Server
6.0.1
Y Y N N N N Y Y N
31-bit
WebSphere
Application
Server
6.0.2
Y Y N N N N Y Y
Tương
lai
64-bit
WebSphere

Application
Server
6.0.2
N N N N N N Y Y
Tương
lai
31-bit
WebSphere
Application
Server 6.1
N Y N N N N Y Y
Tương
lai
64-bit
WebSphere
N N N N N N Y Y
Tương
lai
Application
Server 6.1
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).
31-bit 64-bit
WebSphere
Application
Server
Network
Deployment

SLES8

RHEL3

SLES9

RHEL4

SLES8

RHEL3

SLES9

RHEL4

SLES10

31-bit
WebSphere
Application
Server
Network
Deployment
5.1.1
Y Y N N N N Y Y N
31-bit
WebSphere
Application
Server
Network

Deployment
Y Y N N N N Y Y N
6.0
31-bit
WebSphere
Application
Server
Network
Deployment
6.0.1
Y Y N N N N Y Y N
31-bit
WebSphere
Application
Server
Network
Deployment
6.0.2
Y Y N N N N Y Y
Tương
lai
64-bit
WebSphere
Application
Server
Network
Deployment
6.0.2
N N N N N N Y Y
Tương

lai
31-bit
WebSphere
N Y N N N N Y Y
Tương
lai
Application
Server
Network
Deployment
6.1
64-bit
WebSphere
Application
Server
Network
Deployment
6.1
N N N N N N Y Y
Tương
lai
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
31-bit 64-bit
Edge
Components
của
WebSphere
Application

Server
Network
Deployment

SLES8

RHEL3

SLES9

RHEL4

SLES8

RHEL3

SLES9

RHEL4

SLES10

31-bit
WebSphere
Application
Server
Network
Deployment
5.1.1
Y Y Y Y N N N N N

31-bit
WebSphere
Application
Server
Network
Deployment
6.0
Y Y Y Y N N N N N
31-bit
WebSphere
Application
Server
Network
Deployment
6.0.1
Y Y Y Y N N N N N
31-bit
WebSphere
Application
Server
Y Y Y Y N N N N
Tương
lai
Network
Deployment
6.0.2
64-bit
WebSphere
Application
Server

Network
Deployment
6.0.2
N N N N N N N N
Tương
lai
31-bit
WebSphere
Application
Server
Network
Deployment
6.1
N Y N N N N Y Y
Tương
lai
64-bit
WebSphere
Application
Server
Network
Deployment
6.1
N N N N N N Y Y
Tương
lai
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:
o 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.
o 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:
00400000-00408000 r-xp 00000000 3a:01 16154
/opt/WebSphere/AppServer51/java/jre/bin/java
00408000-00409000 rw-p 00007000 3a:01 16154
/opt/WebSphere/AppServer51/java/jre/bin/java
00409000-0241d000 rwxp 00000000 00:00 0 (Large allocations are for the JVM
heap)
10000000-40000000 rwxp 00000000 00:00 0 (Large allocations are for the JVM
heap)
40000000-40013000 r-xp 00000000 5e:05 4384 /lib/ld-2.2.5.so
40013000-40015000 rw-p 00012000 5e:05 4384 /lib/ld-2.2.5.so
40015000-40017000 r-xp 00000000 3a:01 16195
/opt/WebSphere/AppServer51/java/jre/bin/libjsig.so
40017000-40019000 rw-p 00001000 3a:01 16195

/opt/WebSphere/AppServer51/java/jre/bin/libjsig.so
40019000-4001a000 rw-s 00000000 00:05 0 /SYSV83000016 (deleted)
4001a000-40028000 r-xp 00000000 5e:05 4392 /lib/libpthread.so.0
40028000-4002f000 rw-p 0000d000 5e:05 4392 /lib/libpthread.so.0
4002f000-40042000 r-xp 00000000 5e:05 4388 /lib/libnsl.so.1
40042000-40044000 rw-p 00012000 5e:05 4388 /lib/libnsl.so.1
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:
o 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.
o 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.
o 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:
o Mạch làm sạch bộ nhớ cache chứa EJB
o Luồng thu hoạch chung kết nối J2C
o 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.