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
Trang 1Sá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
Trang 2Specific 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
Trang 3Phiê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
Trang 4phé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
WebSphere
Application
Server cơ
bản
SLES8 RHEL3 SLES9 RHEL4 SLES8 RHEL3 SLES9 RHEL4 SLES10
31-bit
WebSphere
Application
Server
5.1.1
31-bit
WebSphere
Trang 5Application
Server 6.0
31-bit
WebSphere
Application
Server
6.0.1
31-bit
WebSphere
Application
Server
6.0.2
lai
64-bit
WebSphere
Application
Server
6.0.2
lai
31-bit
WebSphere
Application
Server 6.1
lai
64-bit
WebSphere
lai
Trang 6Application
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)
WebSphere
Application
Server
Network
Deployment
SLES8 RHEL3 SLES9 RHEL4 SLES8 RHEL3 SLES9 RHEL4 SLES10
31-bit
WebSphere
Application
Server
Network
Deployment
5.1.1
31-bit
WebSphere
Application
Server
Network
Deployment
Trang 76.0
31-bit
WebSphere
Application
Server
Network
Deployment
6.0.1
31-bit
WebSphere
Application
Server
Network
Deployment
6.0.2
lai
64-bit
WebSphere
Application
Server
Network
Deployment
6.0.2
lai
31-bit
WebSphere
lai
Trang 8Application
Server
Network
Deployment
6.1
64-bit
WebSphere
Application
Server
Network
Deployment
6.1
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
Edge
Components
của
WebSphere
Application
Server
Network
Deployment
SLES8 RHEL3 SLES9 RHEL4 SLES8 RHEL3 SLES9 RHEL4 SLES10
Trang 931-bit
WebSphere
Application
Server
Network
Deployment
5.1.1
31-bit
WebSphere
Application
Server
Network
Deployment
6.0
31-bit
WebSphere
Application
Server
Network
Deployment
6.0.1
31-bit
WebSphere
Application
Server
lai
Trang 10Network
Deployment
6.0.2
64-bit
WebSphere
Application
Server
Network
Deployment
6.0.2
lai
31-bit
WebSphere
Application
Server
Network
Deployment
6.1
lai
64-bit
WebSphere
Application
Server
Network
Deployment
6.1
lai
Chú ý:
Trang 11 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
Trang 12dụ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)
Trang 1310000000-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
Trang 14Nế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:
