Trong phần mô hình giải pháp trên, chúng ta mới chỉ ra được tính khái quát các thành phần, các chức năng của hệ thống IBPS mới sẽ có. Chúng ta chưa phân tích, đánh giá và làm nổi bật các thế mạnh mà hệ thống mới có được cũng như đáp ứng trước các yêu cầu đặt ra.
CSDL CI-Client Ứng dụng CI Hệđiều hành Mức mạng LAN Mã hoá dữ liệu Xác thực dữ liệu Quản lí truy cập Cơ sở dữ liệu Ứng dụng IBPC OS, Tuxedo Mức mạng Leased Dial Up
Chúng ta thực hiện bằng việc đi phân tích, đánh giá các đặc tính kỹ thuật chi tiết cho từng thành phần của hệ thống. Mỗi kết quả đánh giá nhận được sẽ khẳng định giá trị mà hệ thống mới đem lại.
Giải pháp được đánh giá theo các thông số sau:
- Thời gian dự định thực hiện thành công và đưa dự án vào hoạt động thực tiễn là 2 năm. Thời gian đáp ứng của hệ thống sau khi đưa vào thực tiễn là 8 năm. Như vậy tổng cộng thời gian của hệ thống dự trù là 10 năm.
- Năng lực cần đáp ứng của hệ thống IBPS dự trù cho 10 năm với số món thanh toán hiện tại và tỷ lệ gia tăng số món giao dịch được dự tính trong phần [1.2.1.4.6] tương ứng là 15000/ngày và 31%/năm. Như vậy sau 10 năm nữa, tổng lượng món cần xử lí của hệ thống là: 15000*1.310 = 206787 giao dịch/1 ngày.
- Thời gian giao dịch trong ngày là 8h: từ 8am Æ 4pm. Tương đương với lượng giao dịch trên 1s là 206787/(8*602)=7 giao dịch/s. Tuy nhiên, thời gian tối đa cho thực hiện thành công 1 giao dịch là 10s. Do đó, lượng giao dịch thực tế thực hiện trong hệ thống trong 1 s là 7*10=70 giao dịch/s.
2.2.2.3.1. Đặc tính phần mềm lớp giữa Tuxedo.
Đặc tính kỹ thuật của phần mềm lớp giữa Tuxedo đã được trình bày chi tiết tại mục [1.3] ở trên. Do đó, ta không trình bày các đặc tính kỹ thuật của Tuxedo ở đây nữa. Tuy nhiên, ta có thể tóm tắt một vài đặc điểm cơ bản của phần mềm lớp giữa Tuxedo làm nổi bật đặc tính của nó như sau:
Công nghệ phần mềm lớp giữa Tuxedo nổi lên những đặc tính ưu việt sau: là một nền tảng kỹ thuật đầy đủ, mạnh mẽ cho việc xây dựng các ứng dụng phân tán, chia sẻ tài nguyên, xử lí các giao dịch phân tán với số lượng lớn dựa trên nền tảng truyền nhận thông điệp, có sử dụng hàng đợi, cho phép xây dựng một hệ thống ứng dụng nhanh chóng, trong suốt với nền tảng phần cứng, mạng truyền thông, ….
Với những đặc tính kỹ thuật ưu việt trên, Tuxedo cho phép xây dựng IBPS mới có tính đột phá và quyết định đến đặc tính kỹ thuật của tất cả các thành phần còn lại của hệ thống IBPS.
Một giải pháp tổng thể cho IBPS dựa trên Tuxedo sẽ tạo ra một IBPS mới có khả năng tập trung cao độ và đáp ứng tất cả những đặc tính kỹ thuật yêu cầu cần thiết.
2.2.2.3.2. Đặc tính phần cứng hệ thống.
So với mô hình hạ tầng phần cứng hệ thống IBPS cũ [Hình 6] hoặc hạ tầng phần cứng hệ thống IBPS trong giải pháp nâng cấp [Hình 32], mô hình hạ tầng phần cứng hệ thống IBPS mới [Hình 37] chỉ có một trung tâm thanh toán tập trung duy nhất là IBPC. Tuy nhiên, trung tâm IBPC logic này được phân tán làm 2 trung tâm IBPC vật lí là IBPC1 đặt tại ITDB, 64 Nguyễn Chí Thanh Hà nội và IBPC2 đặt tại Sơn Lộc, Sơn Tây.
Hai trung tâm IBPC vật lí này giúp thực hiện dự phòng và đề phòng rủi ro lẫn nhau trước những đe doạ như thiên tai, địch, hoạ,…Hai trung tâm này được xây dựng cơ sở hạ tầng phần cứng tương đương nhau. Bao gồm các thiết bị phần cứng, mạng, viễn thông và phần mềm như nhau. Cùng một thời điểm cả hai trung tâm cùng hoạt động và xử lí các giao dịch của hệ thống. Đối với người sử dụng thì cả 2 trung tâm này chỉ là một trung tâm IBPC, trong suốt với người dùng về sự phân tán vật lí thật sự.
Do tính kế thừa hạ tầng phần cứng của hệ thống IBPS cũ, số lượng máy chủ HP K380 kế thừa từ hệ thống IBPS cũ là 8. Giải pháp đề xuất là tiếp tục sử dụng các dòng máy chủ mới của HP để bổ xung vào tài nguyên phần cứng của hệ thống. Điều này sẽ có được các lợi thế về tính tiện dụng của hệ thống, tính thuần nhất về nền tảng phần cứng, cũng như tính dễ bảo hành bảo trì và phát triển nguồn nhân lực hiện có.
Ta sẽ đi tính toán hạ tầng phần cứng cần thiết cho hệ thống thông qua khái niệm giới hạn an toàn của hệ thống như sau: Tại mỗi trung tâm IBPC vật lí tài nguyên hệ thống phần cứng cần đáp ứng bằng 3 lần đòi hỏi thực tế cần xử lí trung bình của mỗi IBPC. Điều này tương đương như sau: tại thời điểm t, lượng giao dịch
Đây là giới hạn an toàn của hệ thống. Nếu nguồn lực cần thiết để mỗi IBPC xử lí > 40% là vượt mức an toàn cho phép và cần phải được bổ sung thêm tài nguyên phần cứng.
Lí giải cho việc tính toán giới hạn an toàn của hệ thống trên là trong trường hợp xấu nhất 1 trong 2 IBPC bị phá huỷ hoàn toàn. Khi đó IBPC còn lại vẫn phải đảm bảo xử lí 120% lượng giao dịch thực tế.
Việc mở rộng, thay thế tài nguyên hệ thống là không hạn chế và thời gian tính toán tài nguyên của hệ thống đáp ứng được cho yêu cầu dự trù trong thực tế là 10 năm. Tương đương với lượng giao dịch khoảng 206787 giao dịch/ngày như được tính toán tại mục [2.2.2.3]. Tương đương lượng giao dịch là 70/s của toàn hệ thống. Nếu cộng với hệ số không dự đoán được của tốc độ tăng trưởng tổng quá trình là 30% tương đương 30 giao dịch/s nữa ta có lượng giao dịch là 100/s. (kq*)
Hiện tại, tổng số lượng giao dịch của hệ thống là 15000/(8*602) * 10 = 5 giao dịch/s. Tài nguyên hệ thống chiếm 70%. Do đó 100% tài nguyên hệ thống tương ứng với 5*1.3 = 7 giao dịch/s. Một máy chủ HP K380 có 4CPU PA 8200 200MHZ. Do đó, ta có tương ứng 1 CPU % công suất xử lí 1.5 giao dịch tương đương với 0.8 giao dịch cho 100MHz của 1 CPU PA8200 của máy K380.
Bên cạnh đó, 4 máy chủ HP k380 sẽ hết khấu hao sử dụng trong vòng 5 năm nữa. Do đó, ta giả sử chỉ tính năng lực đáp ứng của hệ thống dựa trên 2 máy chủ HP 9000 rp8420 32 CP PA 8900 1.1GHz thôi. Như vậy, tổng số CPU của 2 máy chủ là 32*2=64 CPU. Tương đương với: 64*1024*1.1 = 72089 MHz. Tương đương 720 lần 100MHz hay tương đương với 720*0.8 = 576 giao dịch/s. (kq**)
Nếu so sánh (kq*) với (kq**), ta thấy năng lực của hệ thống sẽ đáp ứng tại 1 IBPC trong 10 năm nữa là gấp 5,7 lần cần thiết trong thực tế. Hệ số an toàn của hệ thống với cấu hình trên là 20% < 40% cần thiết.
Kết luận về cấu hình máy chủ chạy ứng dụng của mỗi IBPC:
Số lượng máy chủ chạy ứng dụng IBPS trên 1 IBPC: 6 máy chủ. Gồm 4 máy HP K380 cũ, 2 máy chủ HP class 9000 rp8420 32 CPU PA-8900, 2 RAID Store.
2.2.2.3.3. Đặc tính phần mềm hệ thống OS.
Do hệ thống ứng dụng IBPS mới được xây dựng trên nền tảng của Tuxedo, IBPS mới có độ độc lập cao với nền tảng hệ thống. Điều này giúp nó không phụ thuộc vào hệ điều hành mà nó chạy trên đó. Từ đặc tính này, hệ thống IBPS mới có thể sử dụng các hệ điều hành khác nhau như: Unix, Linux, Windows, HpnonStop, IBM AIX, Sun Solaris… Đặc tính này cho phép hệ thống mới tận dụng được các nền tảng OS hiện có cũng như việc nâng cấp các hệ điều hành sau này mà không bị hạn chế, không phải thay đổi ứng dụng IBPS.
Tuy nhiên, giải pháp hiện tại đề cập sử dụng các OS của HP đó là HP Unix với các version 9i, 11i,…Điều này giúp IBPS mới kế thừa được các tài nguyên OS hiện có là các phiên bản HP Unix 9i, 11i. Các OS này sẽ chạy 12 máy chủ ứng dụng AP1Æ AP6 trên IBPC1, IBPC2. Ngoài ra 2 cặp cluster chạy cơ sở dữ liệu.
Theo mô hình hạ tầng phần cứng, mạng, truyền thông đã đưa ra ở trên, ta thấy có tất cả 16 máy chủ vật lí chạy OS của HP. Tuy nhiên, 8 trong số 16 máy này được thừa hưởng license từ các máy chủ hiện có của hệ thống IBPS cũ. Vì vậy, hệ thống mới cần mua license HP Unix 11i mới cho 8 máy chủ còn lại.
Kết luận: chúng ta cần mua 8 license HP Unix 11i cho 8 máy chủ mới được
thêm vào số tài nguyên hiện có. Khi đó, Ta sẽ tận dụng được tất cả các tài nguyên của hệ thống hiện thời. (adsbygoogle = window.adsbygoogle || []).push({});
2.2.2.3.4. Đặc tính Cơ sở dữ liệu.
Đặc điểm lớn nhất của dữ liệu trong hệ thống thanh toán điện tử liên Ngân hàng là tính thời gian thực, dữ liệu lưu trữ trong hệ thống không cần quá lâu, tốc độ truy xuất phải đảm bảo nhanh, lượng dữ liệu xử lí là lớn. Do đó, giải pháp về cơ sở dữ liệu đưa ra cho hệ thống sẽ như sau:
- Phân hoạch và sao lưu dữ liệu không còn cần dùng cho hệ thống. Chúng ta có thể phân hoạch dữ liệu giao dịch theo khoảng thời gian hàng tháng, hàng ngày
- Thông tin chỉ số dữ liệu của hệ thống phải được thực hiện trên các thông tin khoá và thông tin về ngày giờ giao dịch của hệ thống. Đảm bảo cho quá trình truy xuất dữ liệu thanh toán của ngày đó là nhanh nhất.
- Hệ quản trị cơ sở dữ liệu được xây dựng trên một cặp máy chạy song song với nhau, cùng xử lí các yêu cầu truy xuất dữ liệu, cũng chia sẻ tài nguyên với nhau.
Ta có thể tính toán thông tin lưu trữ của hệ thống trong giao dịch hàng ngày như sau:
Giả sử mỗi giao dịch trong hệ thống có 20 trường dữ liệu, mỗi trường dữ liệu có 100 ký tự, mỗi ký tự sử dụng mã unicode 2byte để biểu diễn. Như vậy 1 giao dịch cần dung lượng lưu trữ là 20*100*2=4000byte~4kb.
Giả sử mỗi giao dịch trong hệ thống được xử lí theo qui trình gồm 20 bước, tại mỗi bước cần lưu trữ một lần. Như vậy 1 giao dịch trong toàn hệ thống sẽ cần dung lượng lưu trữ là 4*20=80Kb.
Như vậy, một ngày hệ thống IBPS xử lí giao dịch cần lưu trữ dữ liệu là 206787 * 80/10242~15.8 GB.
Sau 1 tháng dung lượng dữ liệu cần lưu trữ trong hệ thống là 15.8*31~490Gb. Sau 1 tháng lượng bản ghi lưu tại 1 điểm xử lí dữ liệu là 206787*31~6410397 bản ghi.
Với tính toán trên, nếu ta không phân hoạch dữ liệu theo thời gian xử lí của hệ thống thì hệ thống không thể truy nhập tức thời dữ liệu trong thời gian thực, đảm bảo hoàn thành xử lí 1 giao dịch dưới 10s được.
Chính vì vậy, giải pháp đề xuất thực hiện phân hoạch dữ liệu theo từng ngày giao dịch. Như vậy vào cuối ngày xử lí giao dịch, hệ thống chỉ truy xuất lượng giao dịch tối đa là 206787 bản ghi.
Trong giải pháp của này, chúng ta sử dụng 2 hệ thống IBPC. Mỗi hệ thống đảm bảo xử lí 50% yêu cầu. Chúng ta sẽ có lượng bản ghi cần truy vấn là 206787/2~103394 giao dịch.
Như vậy tốc độ truy nhập dữ liệu sẽ được bảo đảm hơn.
Trong giải pháp này, ta đề xuất sử dụng hệ quản trị cơ sở dữ liệu Oracle 9i, 10i.
2.2.2.3.5. Đặc tính phần mềm ứng dụng IBPS.
Do đặc tính tổ chức ứng dụng hướng dịch vụ của Tuxedo, ứng dụng IBPS được xây dựng trên Tuxedo sẽ được xây dựng mỗi thành phần, mỗi dịch vụ là một server ứng dụng riêng. Mỗi một server ứng dụng sẽ chạy trên 1 hoặc nhiều máy chủ vật lí. Số lượng server đáp ứng yêu cầu xử lí của hệ thống thanh toán sẽ được nạp tự động theo tính năng tự động khởi tạo các server ứng dụng của Tuxedo. Các server ứng dụng sẽ tự động cân bằng và chia sẻ tải với nhau.
Hình 39. Cấu trúc phần mềm ứng dụng IBPC.
Giải pháp đề xuất cài đặt các server ứng dụng cho các dịch vụ của hệ thống trên tất cả các máy chủ vật lí từ AP1ÆAp6. Tuy nhiên, chúng ta sẽ cấu hình chuyên biệt các máy chủ vật lí mạnh cho các server ứng dụng đòi hỏi tải xử lí lớn và quan trọng như: server HVS, server SAPS, SAS lên 2 máy chủ vật lí mới HP 9000 rp8420. Các server ứng dụng khác như LVS, NBS, IIS, OCS sẽ cài đặt trên các máy chủ HP 9000 K380 cũ. Các server này sẽ được cài đặt tối thiểu trên 2 máy chủ vật lí HP 9000 K380 khác nhau. Tuy nhiên, chúng ta tối ưu cho các server này chạy chính trên một máy chủ vật lí riêng.
Inter Bank Payment Center IBPC
SAPS HVS LVS NBS
SAS
Hình 40. Mô hình cài đặt phần mềm IBPS trên máy chủ vật lí.
Trong mô hình cài đặt phần mềm như trên, ta thấy cấu hình của chúng như sau:
2.2.2.3.5.1. Máy chủ vật lí AP6 được cấu hình.
HVS (50..100), SAS(10..100), SAPS(0..50), LVS(0..50). Ý nghĩa như sau: - HVS(50..100) trên máy AP6 sẽ nạp tối thiểu 50 server HVS, nạp tối đa 100 server HVS. Đầu tiên nạp 50 server HVS phục vụ cho nhu cầu HV.
- SAS(10..100) trên máy chủ AP6 đầu tiên nạp 10 server dịch vụ mã hoá xác thực SA, sau khi vận hành dịch vụ SAS trên các máy chủ khác bị quá tải thì AP6 sẽ lần lượt nạp các SAS lên để xử lí các yêu cầu của hệ thống. Số SAS tối đa AP6 có
Sw itc h System Ma n a gemen t Mon itorin g Server H elp-Desk Server Termin a l H P Stora ge DB2 DB1
AP1 AP2 AP3 AP4 AP5 AP6
SAPS (10..100) HVS (0..50) SAS (0..50) LVS (0 50) HVS (50..100) SAS (10..100) SAPS (0..50) LVS LVS (50..100) NBS (10..100) IIS (0..50) SAS (0 50) LVS (50..100) NBS (10..100) IIS (0..50) SAS IIS (50..100) OCS (0..100) NBS (0..50) SAS (0 50) IIS (0..100) NBS (10..100) LVS (0..50) SAS (adsbygoogle = window.adsbygoogle || []).push({});
Như vậy AP6 là máy chủ vật lí chạy các server đảm bảo an ninh, an toàn của hệ thống.
- SAPS(0..50) trên máy chủ AP6 đầu tiên nạp 0 server dịch vụ SAPS, sau khi vận hành dịch vụ SAPS trên các máy chủ khác bị quá tải thì AP6 sẽ lần lượt nạp các SAPS lên để xử lí các yêu cầu của hệ thống. Số SAPS tối đa AP6 có thể nạp là 50 server.
- Tương tự như SAPS, dịch vụ LVS(0..50) cũng được xử lí tương tự như vậy.
2.2.2.3.5.2. Máy chủ vật lí AP1 được cấu hình.
SAPS (10..100), HVS(0..50), SAS(0..50), LVS(0..50). Ý nghĩa của chúng như sau:
- SAPS(10..100) trên máy AP1 sẽ nạp tối thiểu 10 server SAPS, nạp tối đa 100 server SAPS. Đầu tiên nạp 10 server SAPS phục vụ cho nhu cầu SAP.
- HVS(0..50) trên máy chủ AP1 đầu tiên nạp 0 server dịch vụ HV, sau khi vận hành dịch vụ HV trên các máy chủ khác bị quá tải thì AP1 sẽ lần lượt nạp các HVS lên để xử lí các yêu cầu của hệ thống. Số HVS tối đa AP1 có thể nạp là 50 server.
- Tương tự như HVS, các dịch vụ SAS, LVS cũng được xử lí tương tự như vậy.
2.2.2.3.5.3. Máy chủ vật lí AP2 được cấu hình.
LVS(50..100), NBS(10..100), IIS(0..50),SAS(0..50). Ý nghĩa của chúng như sau:
- LVS(50..100) trên máy AP2 sẽ nạp tối thiểu 50 server LVS, nạp tối đa 100 server LVS. Đầu tiên nạp 50 server LVS phục vụ cho nhu cầu LVS.
- NBS(10..50) trên máy AP2 sẽ nạp tối thiểu 10 server NBS, nạp tối đa 50 server NBS. Đầu tiên nạp 10 server NBS phục vụ cho nhu cầu xử lí Netting & Batch job.
- IIS(0..50) trên máy chủ AP2 đầu tiên nạp 0 server dịch vụ IIS, sau khi vận hành dịch vụ IIS trên các máy chủ khác bị quá tải thì AP2 sẽ lần lượt nạp các IIS lên để xử lí các yêu cầu của hệ thống. Số IIS tối đa AP2 có thể nạp là 50 server.
- Tương tự như IIS, các dịch vụ SAPS(0..50) cũng được xử lí tương tự.