Hình 2.2: Các giao diện mạng liên ngân hàng
Truyền thông trong mạng LAN sử dụng giao thức Ethernet tốc độ cao, truyền thông trong mạng WAN sử dụng đường truyền X.25 (giao diện A) tốc độ tối đa cho phép là 64kbps, kết nối giữa trung tâm dự phòng và NPSC là đường leased line tốc độ cao, 128kbps (giao diện B), như hình 2.2.
Kết nối giữa các thành phần trên từng máy chủ như sau:
- Các CPU trên máy chủ ở NPSC sử dụng 2 mức cache giao tiếp với bộ nhớ chính qua bus nội bộ tốc độ cao.
- Dữ liệu lưu trên các tủ đĩa với disk I/O giao diện SCSI với máy chủ. Như vậy hệ thống thanh toán liên ngân hàng là một hệ thống phân tán sử dụng đồng thời cả 2 mô hình chia sẻ bộ nhớ là multiprocessor trên NPSC và multicomputer trên các hệ thống còn lại.
Kết quả hoạt động sau 4 năm cho thấy, tuy hoạt động nghiệp vụ của hệ thống vẫn đảm bảo nhưng gặp khó khăn trong vấn đề nâng cấp. Để giảm chi phí nâng cấp cần thực hiện phân tích chi tiết hệ thống, phát hiện các "nút cổ chai" của hệ thống để xử lí một cách hợp lí nhất.
2.2 Các ứng dụng chủ yếu trên Core Banking: 2.2.1 Hệ thống bù trừ Liên ngân hàng (IBCS)
Hệ thống Thanh toán bù trừ Liên ngân hàng (IBCS) sẽ xử lý bù trừ tất cả các khoản thanh toán điện tử Liên ngân hàng trong nước, cả nội tỉnh và liên tỉnh. IBCS bao gồm một Tiểu hệ thống Giá trị thấp (LVSS) và một Tiểu hệ thống Giá trị cao (HVSS). Việc sử dụng HVSS dự kiến sẽ tăng lên theo thời gian khi nhu cầu về các khoản thanh toán giá trị cao cần chuyển gấp tăng lên và LVSS chủ yếu sẽ là một Hệ thống Thanh toán theo lô.
Việc bù trừ các khoản thanh toán LVSS được thực hiện tại các Trung tâm Xử lý tỉnh (PPC) đặt tại các tỉnh và thành phố chính bao gồm cả Hà nội và TP Hồ
Chí Minh. Các thanh toán nội tỉnh được xử lý bù trừ tại địa phương. Các thanh toán liên tỉnh được gửi đến phương tiện chuyển mạch LVSS tại Trung Tâm Xử lý và Quyết toán Quốc gia (NPSC), trung tâm này sẽ được đặt tại Trung tâm Tin học Ngân hàng tại Hà nội, để sau đó sẽ được chuyển tiếp đến các PPC tại địa phương của các tổ chức nhận.
Việc bù trừ của các khoản thanh toán HVSS sẽ được thực hiện tức thời tại hệ thống xử lý tài khoản quyết toán (SAPS) đặt tại Trung Tâm Xử lý và Quyết toán quốc gia (NPSC).
Ngoài các thanh toán điện tử bù trừ kể trên, việc bù trừ bằng chứng từ (với sự
hiện diện vật lý của chứng từ giấy) sẽ được giữ tại Sở Giao dịch của NHNNVN và tại các trung tâm bù trừ cấp tỉnh (tức là chi nhánh NHNNVN tỉnh).
2.1.2 Hệ thống Xử lý Tài khoản Quyết toán (SAPS)
Hệ thống Xử lý Tài khoản Quyết toán (SAPS) sẽ có các chức năng sau: 1. Thực hiện tất cả các nghĩa vụ thanh toán Liên ngân hàng bằng tiền Đồng VN khi nhận được các yêu cầu quyết toán
2. Quản lý hàng đợi đối với các giao dịch chưa được thực hiện 3. Duy trì và giám sát các tài khoản thanh toán
SAPS mở một tài khoản quyết toán cho mỗi thành viên trực tiếp. Nó sẽ hoạt động tại NPSC
Các tổ chức tín dụng sẽ truy cập SAPS từ các CIHO thông qua các CIPC và các PPC mà CIPC được nối tới. Hệ thống quản lý tin điện có mức ứng dụng thông thường giữa các địa điểm trên là HVSS.
2.1.3 Giao diện với Hệ thống Thanh toán Liên ngân hàng điện tử (EIS)
Trong giai đoạn chuyển dịch, một số tổ chức tín dụng và một số chi nhánh ngân hàng nhà nước không phải là thành viên của Hệ thống Thanh toán Liên
ngân hàng mới. Vì vậy cổng EIS tại NPSC và cổng EIS tại mỗi PPC trong 6 PPC phải được xây dựng.
a) Cổng EIS tại NPSC để:
1. Cho phép EIS tạo ra các bút toán cho các tài khoản quyết toán được duy trì tại SAPS; do vậy cả hai hệ thống truy cập cùng một bộ tài khoản quyết toán. 2. Cung cấp một giao diện liên hệ thống; để tạo ra một hoạt động tổng thể liên tục và chuyển đổi thanh toán giá trị cao và giá trị thấp khi mà một trong các bên tham gia vào thanh toán tại EIS và bên kia tại Hệ thống Thanh toán Liên ngân hàng mới.
b) Cổng EIS tại 6 PPC để:
Cung cấp giao diện tại 6 PPC để chuyển đổi các thanh toán của các tổ chức tín dụng không phải là thành viên của hệ thống thanh toán liên ngân hàng mới nhng vẫn tham gia thanh toán bù trừ theo các quy chế của NHNNVN.
Chương III
XÂY DỰNG MÔ HÌNH HIGH-PERFORMANCE CHO HỆ THỐNG CORE BANKING
3.1 Kiến trúc high-performance:
Ta sẽ phân tích cách áp dụng các phương thức performance để xác định cấu trúc performance, nền tảng cho việc thiết kế và xây dựng các ứng dụng core banking dạng client/server nói riêng và mạng phân tán nói chung.
3.1.1 Mô hình tham khảo cho kiến trúc Client/Server:
Để có cái nhìn khái quát, ta xem xét một mô hình tham khảo của hệ thống tính toán client/server. Đây là mô hình của DataBase Associates, nó mô tả phương thức mà các loại middleware được dùng để liên kết các ứng dụng Web và các ứng dụng client/server khác với nhau:
Hình 3.1: Client/Server computing roadmap Các vấn đề thực tế đối với các giao dịch phân tán:
- Variable capacity: Các thành phần trong hệ thống phân tán hoạt động ở các tốc độ khác nhau.
- Variable contention: Các thành phần hoạt động trong các môi trường xử lí khác nhau, do đó có thể phát sinh trễ khi chia sẻ tài nguyên ( CPU, các liên kết mạng, disks …) với các thành phần khác.
- Variable availability: Không thể đảm bảo được rằng các thành phần trong hệ thống phân tán vốn được điều khiển một cách độc lập lại có thể khả dụng một cách đồng thời.
- Variable demand: Sự phân chia một giao dịch giữa các thành phần có thể không giống nhau như thiết kế. Một thành phần nào đó có thể được yêu cầu thực hiện một tác vụ đòi hỏi thời gian hoàn thành hàng phút thậm chí hàng giờ, trong khi đó thành phần khác có thể thực hiện trong vài giây.
Như đã nói, decoupled processes và multitransaction workflows là căn cứ để thiết kế các hệ thống high performance enterprise client/server:
- Decoupled Processes: Việc phân tách các tiến trình thực hiện theo nguyên tắc: có thể phân tách các thành phần khác nhau của một hệ thống phân tán để không có tiến trình nào phải dừng xử lí để chờ các tiến trình khác.
- Multitransaction workflows: Chúng ta có thể tách các giao dịch thực tế thành các giao dịch trên máy tính.
Các luận cứ để chứng minh các nhận định trên sẽ được phân tích ngay sau đây, chúng liên quan đến các yếu tố sau:
1. Khả năng có hạn của các hệ thống phần mềm trong việc đảm bảo tính toàn vẹn của giao dịch trong môi trường phân tán.
2. Xung đột giữa các hệ thống phân tán và các giao dịch vốn được điều khiển độc lập nhau.
3. Sự giống nhau trong việc thiết kế các ứng dụng để tận dụng các bộ xử lí song song.
4. Kinh nghiệm trong việc thiết kế các hệ thống trong thực tế. 5. Các nguyên lí xây dựng phần mềm.
6. Yêu cầu phải xây dựng các hệ thống từ các thành phần được phát triển một cách độc lập nhau
3.1.2 Các thành phần cấu trúc của một hệ thống phân tán:
Về mặt logic, có thể phân chia một hệ thống phân tán thành 3 thành phần là:
presentation, application, database. Về mặt phân bố vật lí có thể phân nó thành các thành phần sau: workstation, departmental server và enterprise server.
Về mặt logic, các hệ thống cần các thành phần để thực hiện 3 chức năng khác nhau cơ bản, ta có thể xem 3 chức năng này là consumers, context và content:
- Consumers: Là các thành phần ứng dụng giao tiếp với các user và thực hiện chức năng thu thập, chuẩn bị và hiển thị thông tin.
- Context: thực hiện việc xử lí ứng dụng, nhận yêu cầu thông tin từ consumers, phân tích yêu cầu này, và đưa chúng đến lớp content phù hợp.
Hình 3.2: Optimal architecture for enterprise client/server.
- Content: Để phối hợp các dịch vụ phối hợp và quản lí thông tin. Trước đây nó chỉ đơn giản là data và database, hiện nay còn bao gồm cả các các nguồn tài nguyên khác.
3.1.3 Kiến trúc three-tier client/server thực tế:
Nếu triển khai các ứng dụng theo mô hình như trên, performance sẽ rất kém. Yêu cầu data của consumer phải được chuyển qua 2 lớp transport để tới được lớp content, và trong thực tế, một trong 2 lớp transport này có thể là mạng WAN, tương đối chậm.
Trong thực tế, cấu trúc tối ưu để có high performance sẽ bao gồm các một quan hệ giữa các lớp logic và vật lí như hình 3.3:
Hình 3.3: Logical and physical layering in practice
Theo đó, để xây dựng các hệ thống làm việc hiệu quả trong môi trường phân tán, ta cần thiết kế các ứng dụng có kiến trúc thoả mãn:
- Phần quản lí hiển thị tập trung trên workstation, nhưng một số chức năng được thực hiện trên workgroup server.
- Phần quản lí application và workflow nằm trên workgroup server nhưng một số chức năng được thực hiện bởi enterprise server.
- Phần quản lí data được trải rộng trên cả 3 tier mặc dù trách nhiệm chủ yếu được chia sẻ giữa các server workgroup và enterprise.
3.1.4 Các đường truyền thông:
Các ứng dụng được triển khai dựa trên cấu trúc này cần phải phối hợp hoạt động các loại thông tin giữa các tiến trình với nhau. Sau đây là một ví dụ, hình 3.4:
Hình 3.4: Communication paths in distributed applications Ta có thể phân loại các đường thông tin thành 5 nhóm như sau:
1. Trong cùng một chức năng và cùng tier (1 1, 2- -2,…)
2. Trong cùng tier, giữa các chức năng (1 2, 2 3, 4 5, 5 6, 8- - - - -9)
3. Trong cùng một chức năng, giữa các tier liền kề (1-4, 2 5, 5 8, 3 6, 6- - - -9) 4. Giữa các chức năng trong các tier liền kề (1-5, 4 8, 5- -9)
5. Giữa các tier xa nhau (1-8, 3-9)
Ví dụ đơn giản, kết nối 4 6 là một ứng dụng Web trong đó các thành phần - trình diễn giao tiếp trực tiếp với phần quản lí data trong local server.
3.1.5 Ý nghĩa performance:
Để tối ưu hoá performance, ta áp dụng những nguyên tắc sau:
1. Tối thiểu hoá số lượng kết nối giữa các tier, đặc biệt thông qua mạng WAN.
2. Hạn chế các kết nối đồng bộ tới các kết nối có tốc độ nhanh hơn trong cùng tier hoặc giữa các tier nối với nhau bằng mạng tốc độ cao
3. Với các kết nối tốc độ thấp, cần sử dụng kết nối cận đồng bộ kết hợp với các kĩ thuật thiết kế nhằm hạn chế trễ xử lí và trễ truyền thông trong tổng thời gian phản hồi của người dùng.
3.2 Thiết kế hệ thống high performance:
Các nguyên lý về kiến trúc và thiết kế sẽ cho ta nhiều lựa chọn thiết kế, vấn đề là ta sẽ chọn một kiến trúc cho phù hợp với yêu cầu của người sử dụng. Core banking là một hệ thống thời gian thực, nên vấn đề performance của hệ thống này chính là của hệ thống thời gian thực.
3.2.1 Thiết kế các hệ thống thời gian thực:
Một hệ thống thông tin kinh tế tốt phải được thiết kế theo kiểu thời gian thực. Các hệ thống thời gian thực phải luôn chạy nhanh như (hoặc nhanh hơn) các tiến trình khác mà chúng hỗ trợ. Ví dụ:
- Người dùng đọc, sử dụng và cập nhật thông tin. Các máy tính sẽ cung cấp các thông tin chia sẻ bằng cách đọc và cập nhật cơ sở dữ liệu. Hệ thống máy tính sẽ lưu các bản sao của thông tin quan trọng nhất ở nhiều địa điểm khác nhau sẵn sàng cho các user sử dụng.
- Một số ứng dụng high performance cần có tốc độ truy suất cao tới dữ -
liệu ở xa. Trong trường hợp này, mọi thành phần trên đường truyền thông từ client tới server ở xa được thiết kế và giám sát một cách đặc biệt để đảm bảo nó cung cấp được ứng dụng này. Khi client workstation phải chờ tiến trình trên node khác trong mạng xử lí xong, không chỉ workstation đó hoạt động không hiệu quả mà user cũng tốn thời gian một cách vô ích.
- Với hầu hết các mục tiêu kinh doanh, thông tin cung cấp cho người
dùng không nhất thiết phải tức thời. Một số thông tin có thể không được cập nhật trong thời gian vài giây, vài phút hoặc hàng giờ. Một số
thông tin chỉ mang tính tổng kết. Người dùng chỉ cần biết thông tin đó là cập nhật đến thời điểm nào.
- Hệ thống máy tính phải giữ cho tất cả thông tin nhất quán với nhau. 3.2.2. Thiết kế một ứng dụng phân tán:
Sau khi lựa chọn và đưa ra các chỉ tiêu của ứng dụng core banking trên nền một hệ thống thời gian thực ta sẽ xem xét các khía cạnh của vấn đề thiết kế. 3.2.2.1 Thiết kế nền tảng ứng dụng:
Khi thiết kế một ứng dụng phân tán nói riêng và core banking nói chung, cần phải thực hiện cân bằng với các mục tiêu toàn cục khác của hệ thống:
- Cần có phản hồi khác nhau của hệ thống đối với từng workload cụ thể - Cần tối ưu hoá thông lượng của toàn hệ thống với một tài nguyên cho
trước.
- Chi phí thực hiện các giải pháp này - Thời gian triển khai các giải pháp Các vấn đề kĩ thuật:
a) Tạo sự cân bằng giữa các tài nguyên tính toán: Các tài nguyên tính toán
nếu không được phối hợp sử dụng tốt sẽ sinh ra các "nút cổ chai"
(bottle necks), do đó người ta thường thực hiện trao đổi tài nguyên
bằng cách dùng dư thừa các tài nguyên đó, do đó sẽ cải thiện được thông lượng và thời gian phản hồi toàn hệ thống.
b) Thực hiện giảm thời gian trễ bằng cách sử dụng các nguồn tài nguyên nhanh hơn, đặc biệt là sử dụng disk storage ở lớp mạng I/O, thêm bộ xử lí ở disk I/O, và thêm bộ nhớ (cache) ở bộ xử lí.
c) Thực hiện phân bổ cụ thể từng ứng dụng ứng với từng tài nguyên thông qua ma trận ứng dụng-tài nguyên.
3.2.2.2 Phân tán tài nguyên thông tin
Vấn đề phân bố dữ liệu trong hệ thống phải đảm bảo cân bằng giữa 4 yếu tố sau:
1. Các bảng dữ liệu liên quan đến nhau phải được sử dụng cùng nhau. 2. Các bảng quan trọng cần được sao lưu để đảm bảo tính an toàn.
3. Đảm bảo khả năng lưu trữ cũng như năng lực xử lí của vị trí đặt dữ liệu.
4. Xác định mức độ sử dụng của dữ liệu để thực hiện chia sẻ, ưu tiên thực hiện chia sẻ trong mạng LAN, hạn chế chia sẻ trong mạng WAN. Do đó có thể thực hiện chia nhỏ dữ liệu đến mức nhỏ nhất (cỡ hàng và cột trong một bảng dữ liệu) để tối ưu hoá việc chia sẻ này.
Thực hiện cập nhật các bản sao dữ liệu theo cơ chế nhiều pha:
Để tránh cập nhật nhiều vị trí trong cùng một giao dịch, người ta sử dụng cơ chế cập nhật cận đồng bộ nhiều pha như hình 3.5:
Pha 1: Cập nhật: Các bản cập nhật trước hết sẽ được ghi lại trong một bản sao ở node nội bộ, bản sao này hoạt động như một cache cập nhật nhất của bản chính.
Pha 2: Thu thập, các bản sao của bản cập nhật sẽ được chuyển đến server trung tâm nơi chứa bản sao chính, có nhiều phương pháp thực hiện việc này như gửi các thông điệp cập nhật theo từng lô, hoặc sử dụng các phần mềm tạo bản sao của các hệ quản trị cơ sở dữ liệu.
Pha 3: Tập hợp lại, các bản cập nhật sẽ được cập nhật vào bản sao chính trên máy chủ.
Pha 4: Phát tán bản sao, sau khi được cập nhật, bản sao chính sẽ được phát tán trên toàn hệ thống.
Pha 5: Apply, các bản cập nhật được apply vào phần dữ liệu nằm trên máy nội