Trong phần này, chúng ta tập trung vào vấn đề đồng bộ các file ở xa, trong trường hợp khi server không có quyền truy nhập tới file tham chiếụ Những thuật toán đã biết đối với vấn đề này có khác biệt so với bộ nén deltạ Chúng ta sẽ bàn về 2 hướng nghiên cứu chính: (1) hướng nghiên cứu dựa trên chuỗi dấu vân tay được thực hiện theo thuật toán rsync tuy nó không đạt được giới hạn tối ưu nào, và (2) dựa trên việc tô màu đồ thị, hướng này đạt được sự thi hành tối ưu dưới các mô hình hiện thời cho khoảng cách file, nhưng dường như nó không phù hợp trong thực tế. Chúng ta cũng sẽ bàn về các vấn đề liên quan trong việc đánh giá sự tương đồng của file và cách điều hoà tập các bản ghi trong một databasẹ
2.5.3.1 Thuật toán rsync
Chúng ta sẽ mô tả về thuật toán đồng bộ file được triển khai rộng rãi rsync của Tridgell và MacKerras. Một hướng nghiên cứu tương tự cũng được thực hiện bởi Pyne[7].
Giả sử ta có 1 cuộc giao tiếp giữa 2 bên thông qua điện thoại, mỗi bên có 1 bản copy của một cuốn sách. Bây giờ, giả sử 2 bản copy có thể khác nhau ở một vài chỗ nào đó. Bằng cách nào chúng ta có thể tìm ra 2 cuốn sách có giống nhau hay không, và nếu không thì chúng khác nhau ở chỗ nào và khác nhau như thế nào, mà không cần đọc hết toàn bộ cuốn sách qua điện thoạỉ Câu trả lời của câu hỏi đầu tiên rất đơn giản, bằng cách dùng hàm checksum (MD5 chẳng hạn) và so sánh checksum của 2
cuốn sách, như thế nó sẽ xác định được 2 cuốn sách có giống nhau hay không. Câu trả lời cho câu hỏi thứ 2 thì khó hơn một chút. Một hướng nghiên cứu ban đầu là người ta chia cuốn sách thành 2 nửa, nửa đầu và nửa cuối, sau đó sẽ thực hiện checksum trên mỗi nửa, cho tới khi vị trí khác nhau được tìm rạ Tuy nhiên, hướng nghiên cứu này sẽ bị sai trong một trường hợp hết sức đơn giản, khi một cuốn sách chứa thêm một số từ vào đầụ Do đó, một hướng nghiên cứu khác, mạnh hơn là cần thiết mặc dù ý tưởng cơ bản vẫn là sử dụng checksum trên các khốị
Chúng ta sẽ mô tả và chọn lọc thuật toán rsync. Ý tưởng cơ bản là giải quyết vấn đề về sự sắp xếp thẳng hàng bằng cách tính checksum khối cho file tham chiếu, và so sánh các checksum này với các checksum khối tương ứng của file hiện thời, và với checksum của tất cả các vị trí có thể của các khối trong file hiện thờị Kết quả là, server biết được đoạn nào của file hiện thời đã tồn tại trong file tham chiếu, và phần nào mới cần giao tiếp với client. Để đạt được hiệu quả, 2 checksum khác nhau sẽ được truyền thông tới server, tuy nhanh nhưng không đáng tin cậy, muốn đạt được sự tin cậy hơn thì cần đắt hơn nhiềụ
1. Tại client:
(a) Phần fold trong các khối Bi = fold [ib,(i+1)b-1] của kích thước b được xác định sau
(b) Với mỗi khối Bi, tính 2 checksum, ui = hu (Bi) và ri = hr (Bi) và truyền chúng tới server. Ở đây, hu là hàm checksum không đáng tin cậy nhưng nhanh, và hr thì đáng tin cậy nhưng đắt.
2. Tại server:
(a) Với mỗi cặp checksum nhận được (ui,ri), thêm một thực thể (ui,ri,i) vào cấu trúc dữ liệu từ điển, sử dụng ui như một giá trị khoá.
(b) Thực hiện một bước trong fnew, bắt đầu tại vị trí j=0, và liên quan tới các bước sau:
(i) Tính hàm checksum không đáng tin cậy hu(fnew [j, j+b-1]) trên khối bắt đầu tại j.
(ii) Kiểm tra từ điển xem có khối nào có checksum không tin cậy phù hợp không
(iii) Nếu tìm thấy, và nếu có checksum đáng tin cậy cũng phù hợp, truyền một con trỏ tới chỉ số của khối phù hợp trong fold tới client, j tiến tới vị trí b, và tiếp tục.
(iv) Nếu không tìm thấy, hoặc nếu checksum tin cậy không phù hợp, truyền ký tự fnew[j] tới client, tăng j thêm 2 và tiếp tục.
Tại client:
Checksum nhanh và không tin cậy được sử dụng để tìm ra sự phù hợp, và các checksum tin cậy sau đó được dùng để xác nhận sự phù hợp đó. Checksum phù hợp được thi hành bằng cách sử dụng MD4 (128 bit). Checksum không tin cậy có 32bit, nó cho phép chuyển một cách hiệu quả các đường bao khối bởi 1 ký tự, chẳng hạn, checksum cho f[j+1,j+b] có thể được tính trong thời gian không đổi từ f[j,j+b-1].
Rõ ràng, việc lựa chọn một kích thước khối tốt là tiêu chuẩn để thực hiện thuật toán. Sự lựa chọn tốt nhất lại phụ thuộc lớn vào sự giống nhau giữa 2 file – các file càng giống nhau thì chúng ta càng có thể chọn kích thước khối lớn. Hơn nữa, vị trí của các thay đổi trong file thì cũng rất quan trọng. Nếu một ký tự đơn được thay đổi trong mỗi khối của fold, thì không có sự phù hợp nào sẽ được tìm thấy tại server và rsync sẽ không thể hoàn thành một cách hiệu quả được; mặt khác, nếu tất cả các thay đổi được phân thành một vài vùng trên file, rsync sẽ làm rất tốt thậm chí với một kích thước khối lớn. Tuy nhiên, rsync không có sự thi hành tốt với không gian khoảng cách filẹ
Tất nhiên, thông thường kích thước khối thậm chí có thể thay đổi trong một filẹ Trong thực hành, rsync bắt đầu với một kích thước khối hàng trăm byte, và sử dụng các phép heuristic để chỉnh sửa sau đó.
2.5.3.2 Các kết quả thực nghiệm của rsync
Bây giờ, chúng ta sẽ đưa ra một vài kết quả về sự thi hành của rsync so với nén deltạ Các kết quả sử dụng tập dữ liệu gcc và emacs. Chúng ta tổng kết 5 con số cho rsync: số lượng dữ liệu được gửi từ client tới server (request), số lượng dữ liệu được gửi từ server tới client (reply), số lượng dữ liệu được gửi từ server tới client với tuỳ chọn nén đã bật (reply compressed), và tổng số cho cả 2 hướng trong trường hợp không nén (total) và đã nén (total compressed).
Gcc Emacs Uncompressed 27288 27326 Gzip 7479 8191 Xdelta 461 2131 Vcdiff 289 1821 Zdelta 250 1465 Rsync request 180 227 Rsyn reply 2445 12528
Rsync total 2626 12756
Rsync total compressed 876 4428
Bảng 2.2: Các kết quả nén cho tập dữ liệu gcc và emacs (KB)
700 500 300 200 100 80
Rsync request 227 301 472 686 1328 1679
Rsync reply 12528 11673 10504 9603 8433 8161 Rsync reply compressed 4201 3939 3580 3283 2842 2711 Rsync total 12756 11974 10976 10290 9762 9810 Rsync total compressed 4429 4241 4053 3970 4170 4360
Bảng 2.3: Các kết quả nén cho emacs với các tập dữ liệu khác nhau (KB)
2.5.3.3 Các ứng dụng
Các ứng dụng cho đồng bộ file cũng tương tự như đối với thuật toán nén deltạ Đồng bộ file thì phổ biến hơn, trong đó nó không yêu cầu các kiến thức về file tham chiếu; mặt khác, nén delta hướng tới thi hành sự đồng bộ một cách tốt hơn theo khía cạnh tỷ lệ nén. Có rất nhiều lý do tại sao server có thể không chứa các file tham chiếu, chẳng hạn do không gian bộ nhớ, do các phiên bản trước đó của file tham chiếu đã được cập nhật lên các phiên bản mới hơn… Dưới đây là một vài ví dụ:
- Đồng bộ cho các file người dùng: Có một số gói phần mềm như rsync, Microsoft‟s ActiveSync, Puma Technologies‟ IntelliSync hay Palm‟s HotSync cho phép đồng bộ giữa desktop, thiết bị mobile hay các tài khoản cá nhân có thể truy cập web. Trong phần này, các file hay các bản ghi có thể được update bởi rất nhiều phần khác nhau, và nhãn thời gian có thể được dùng để xác định phiên bản gần nhất.
Chúng ta cần chú ý rằng có rất nhiều gợi ý cho các công cụ nàỵ Với dữ liệu dạng file, chúng ta có thể đồng bộ các file từ xa, tránh được việc phải truyền toàn bộ filẹ Với dữ liệu tồn tại dưới dạng các tập lớn của các bản ghi nhỏ, chẳng hạn như danh sách các địa chỉ hay các cuộc hẹn trong các thiết bị cầm tay, vấn đề là làm thế nào để phân biệt các bản ghi này có thay đổi mà không cần gửi một dấu hiệu riêng hay các nhãn thời gian cho mỗi bản ghị Vấn đề này, được mô hình hoá thành một tập hoà giảị Có rất nhiều các gói chương trình thực hiện truyền toàn bộ thực thể nếu có thay đổi nào xảy ra, thường thấy tại các tập dữ liệu dựa trên bản ghi nhỏ, không dùng cho các file lớn. Thêm vào đó, cũng có những vấn đề về việc định nghĩa về ngữ nghĩa thích hợp trong hệ thống đồng bộ filẹ
- Lưu trữ từ xa các tập dữ liệu khổng lồ: Việc đồng bộ có thể được sử dụng để lưu trữ từ xa các tập dữ liệu mà chỉ có thay đổi một chút giữa các lần cập nhật. Trong trường hợp này, việc giữ các phiên bản cũ tại server có giá đắt làm cho kỹ thuật nén delta trở lên không hiệu quả.
- Truy cập web: Đồng bộ file cũng được dùng cho việc truyền HTTP giữa các client với một server hoặc proxỵ Lợi ích của nó là server không cần phải giữ dấu vết của các phiên bản cũ được giữ tại client, và cũng không cần phải tìm lại các phiên bản ấy từ đĩạ Tuy nhiên, như chỉ ra trong phần trên, kỹ thuật đồng bộ file có tỷ lệ nén tồi hơn nén delta, và vì thế nó không chỉ đem lại những lợi ích cho các file tương tự nhaụ
- Hệ thống phân tán ngang hàng: Đồng bộ cũng được dùng cho việc cập nhật các cấu trúc dữ liệu phân tán cao như: routing table, name services, indexes, hay replication tables.
CHƢƠNG 3 - ỨNG DỤNG THUẬT TOÁN NÉN DELTA TRONG VIỆC CẬP NHẬT CÁC PHẦN MỀM NGHIỆP VỤ TẠI NGÂN HÀNG CÔNG THƢƠNG
VIỆT NAM
3.1 Mô hình hệ thống công nghệ thông tin trong ngân hàng Công Thƣơng Việt Nam
Dưới đây là mô hình của hệ thống công nghệ thông tin trong ngân hàng.
HQ Server
North Server Miđle Server South Server
Branch Server Branch Server Branch Server
Client PC Client PC Client PC
upload upload upload upload upload upload update update update
Hình 3.1: Mô hình hệ thống công nghệ thông tin tại NHCTVN
Toàn hệ thống ngân hàng bao gồm rất nhiều chi nhánh trên khắp các tỉnh thành của cả nước. Mỗi chi nhánh lại bao gồm nhiều điểm giao dịch, phòng giao dịch. Tại mỗi điểm giao dịch, có thể có nhiều máy tính Client PC chứa các phần mềm nghiệp vụ giúp các giao dịch viên làm việc với khách hàng. Tại mỗi chi nhánh, có một máy chủ Branch Server nhằm quản lý dữ liệu tập trung của toàn bộ chi nhánh. Các máy chủ chi nhánh này lại được quản lý bởi một máy chủ Server vùng. Có ba máy chủ Server vùng là North Server, Miđle Server và South Server tương ứng với ba vùng bắc, trung, nam. Các máy chủ Server vùng lại được quản lý bởi một máy chủ Server của toàn hệ thống, gọi là HQ Server.
3.2 Quy trình cập nhật các phần mềm nghiệp vụ trong ngân hàng Công Thƣơng Việt Nam
Khi có một nghiệp vụ mới, hoặc khi cần thay đổi các tham số cho một vài nghiệp vụ đang tồn tại,… các phần mềm nghiệp vụ cần được cập nhật tới tất cả các máy tính trong toàn hệ thống. Vậy, bài toán đặt ra là làm thế nào để các phần mềm này được cập nhật nhanh, kịp thời và chính xác?
Thông thường, các thay đổi về phần mềm nghiệp vụ trong ngân hàng thường bao gồm hai phần: phần thứ nhất cập nhật trong cơ sở dữ liệu (chỉ cập nhật một lần trên máy chủ chi nhánh cho toàn bộ một chi nhánh, bằng cách chạy các file script); phần thứ hai cập nhật các file (dạng exe, rpt, dll…) cập nhật cho tất cả các máy bằng cách copy filẹ Toàn bộ quá trình do cán bộ điện toán của chi nhánh thực hiện. Trước tiên, cán bộ điện toán chạy file cript để cập nhật databasẹ Sau khi cập nhật thành công database, cán bộ điện toán tiến hành copy các file cập nhật vào mỗi máy của từng giao dịch viên.
Quy trình này sẽ xảy ra nhiều sai sót: Nếu file script bị lỗi (do bị mất mát dữ liệu trên đường truyền từ trung ương về chi nhánh), hoặc database chi nhánh không đáp ứng đủ các điều kiện đê chạy thành công file script, quá trình chạy script sẽ bị lỗị Cũng có khi quá trình chạy script bị lỗi mà cán bộ điện toán không phát hiện ra (do sơ suất hoặc do trình độ thấp, không hiểu hết các lỗi). Điều này sẽ ảnh hưởng tới hoạt động của toàn chi nhánh, gây phiền hà cho khách hàng, mất lòng tin của khách hàng, ảnh hưởng đến uy tín của ngân hàng… Bên cạnh đó, việc cán bộ điện toán phải copy toàn bộ các file cần cập nhật đến mỗi máy tính cũng tiêu tốn rất nhiều thời gian, công sức. Các phòng giao dịch, điểm giao dịch trong một chi nhánh có thể ở các vị trí địa lý rất xa nhaụ Trong khi đó, có những phần mềm nghiệp vụ yêu cầu điện toán chi nhánh phải cập nhật ngay trong ngày, hoặc trước giờ giao dịch của buổi sáng hôm sau… Rõ ràng là, quy trình cập nhật này còn rất nhiều nhược điểm.
3.3 Chƣơng trình cập nhật tự động các phần mềm nghiệp vụ 3.3.1 Thiết kế hệ thống
Hệ thống đáp ứng các yêu cầu của chương trình cập nhật tự động sẽ không có thay đổi so với hệ thống hiện tạị Tuy nhiên, hệ thống cũng phải đảm bảo các yêu cầu tính thống nhất, trình tự và dễ kiểm soát. Chẳng hạn, khi có một phần mềm nghiệp vụ cần được cập nhật, phần mềm ấy cần phải được cập nhật đồng bộ cho toàn hệ thống. Không thể xảy ra trường hợp, vào cùng một thời điểm, tại các điểm giao dịch khác nhau, phiên bản chạy của một phần mềm nghiệp vụ nào đó khác nhaụ Tính dễ kiểm soát được thể hiện ở chỗ, trong quá trình thực hiện cập nhật tự động toàn hệ thống,
nếu phát sinh lỗi cập nhật tại một chi nhánh nào đó, lỗi này sẽ không làm ảnh hưởng đến các chi nhánh khác. Đồng thời, cán bộ thực hiện cập nhật có thể phát hiện ngay lỗi đang xảy ra tại chi nhánh nào, lỗi đó là gì (do đường truyền, do virus, do cấu hình máy client không tương thích, …). Quá trình cập nhật lại cho chi nhánh bị lỗi cũng phải không gặp bất kỳ khó khăn nàọ
Dựa trên mô hình hệ thống công nghệ thông tin và quy trình cập nhật phần mềm nghiệp vụ tại Ngân hàng Công Thương Việt Nam, các cán bộ thuộc Trung tâm công nghệ thông tin – Ngân hàng công thương Việt Nam đã nghiên cứu và hoàn thiện chương trình cập nhật tự động các phần mềm nghiệp vụ. Chương trình đã thực sự giúp ích rất nhiều cho các cán bộ điện toán tại chi nhánh, đồng thời giảm thiểu tối đa những sai sót cũng như sự tiêu tốn về thời gian và dung lượng trên đường truyền dữ liệụ
Chương trình thực hiện theo quy trình sau:
- Các gói cập nhật được tạo tại Server TW (HQ), sau đó sẽ được upload xuống các Server Vùng (North, Miđle, South).
- Các Server Vùng được xem như tầng trung gian, có nhiệm vụ trung chuyển các gói cập nhật từ Server HQ xuống các Server chi nhánh trong vùng.
- Tại các máy PC client, chương trình sẽ tự động kiểm tra các gói cập nhật từ Server Chi nhánh và tiến hành cập nhật (nếu có).
Phần mô tả về thiết kế chương trình dưới đây sẽ phân tích rõ hơn trong mỗi tầng của hệ thống.
3.3.2 Thiết kế chƣơng trình
Chương trình gồm 2 phần:
- Đặt lịch tự động trên máy chủ Server TW và Server Vùng. - Chương trình quản lý trên Server TW.
3.3.2.1 Chương trình đặt lịch tự động
Thực chất, chương trình này sử dụng một tiện ích của windows, nhằm đặt lịch chạy tự động một chương trình (chương trình upload) vào một thời điểm cố định nào đó. Chương trình được cài đặt tại các Server TW, Server vùng, Server chi nhánh.
Tại Server TW, mỗi khi có một phần mềm nghiệp vụ cần cập nhật, chương trình quản lý trên Server TW sẽ tạo ra Patch file (file Delta). Vào một thời điểm cụ thể, chương
trình đặt lịch tự động trên Server TW chạy một chương trình upload nhằm upload các