Đề tài Dạng kiến trúc (Architectural Styles)

Chương 2: KIẾN TRÚC Các dạng kiến trúc (Architectural Styles) - Các hệ kiến trúc quan trọng nhất (1). Kiến trúc phân tầng (layered) Là kiến trúc mà các component ở mỗi tầng chỉ được phép gọi các component ở các tầng cận (cạnh) với nó. (2). Kiến trúc dựa trên đối tượng (object-based) Các object được định nghĩa tương ứng với các component. Mô hình client-server cũng theo kiến trúc này. (3). Kiến trúc tập trung dữ liệu (data-centered) Các tiến trình giao tiếp (chủ động hay bị động) thông qua các kho chung (common repository) (4). Kiến trúc dựa trên sự kiên (Event-based) Các giao tiếp cơ bản dựa trên quá trình truyền của các event. Ưu điểm của mô hình này chính là sự gắn kết lỏng lẻo. Kiến trúc (3) và (4) kết hợp với nhau sẽ sinh ra kiến trúc shared data space Các tiến trình sẽ rời rạc về mặt thời gian. Các kiến trúc hệ thống (System Architectures) Kiến trúc tập trung Một ví dụ kinh điển nhất là mô hình Client – Server Giao tiếp giữa Client – Server có thể dựa trên các giao thức không kết nối, đơn giản (Không có thiết lập phiên, không tin cậy, là quá trình truyền các datagram) hoặc các giao thức hướng kết nối, tin cậy. Phân tầng ứng dụng Trong mô hình Client – Server, cơ bản không thể phân biệt rạch ròi đâu là client, đâu là server. Lấy một ví dụ thế này, một server của một hệ CSDL phân tán có thể lại hoạt động như 1 client khi server đó forward các yêu cầu tới một server chứa các dữ liệu tương ứng, trong trường này, data server đó tự bản thân nó không làm gì hơn là thực thi các yêu cầu. Kiến trúc của mô hình này có thể được chia làm 3 lớp (level) Lớp giao diện (user-interface level) - Gồm tất cả những gì cần thiết để tạo nên giao diện cho người dùng (trình quản lý hiển thị,…) - Client thường có lớp này như: X-Windows trong Unix, MS-DOS, các GUI trong các ứng dụng hiện đại. Lớp xử lý (processing level) - Chứa các ứng dụng (application) - Lớp này ngăn giữa lớp giao diện (front end) và lớp data (back end) Lớp dữ liệu (data level) - Chứa dữ liệu được thao tác - Chứa các chương trình để duy trì dữ liệu khi các ứng dụng thực thi. Một thuộc tính quan trọng của lớp này là dữ liệu phải luôn luôn được duy trì. Nếu không có ứng dụng nào được chạy, dữ liệu sẽ được lưu ở đâu đó để có thể dùng tiếp ở các lần sau. - Ở dạng đơn giản nhất, lớp này gồm một file hệ thống, nhưng vẫn thường là các bộ dữ liệu đầy đủ. - Trong mô hình client-server, lớp dữ liệu thường được đặt “ở phía” server (server side) - Bên cạnh việc lưu trữ dữ liệu, lớp này cũng chịu trách nhiệm giữ cho dữ liệu thống nhất qua các ứng dụng khác nhau. Khi các cơ sở dữ liệu đang được sử dụng, việc duy trì thống nhất có nghĩa là: metadata (siêu dữ liệu) gồm các bảng mô tả, các ràng buộc, và các metadata đặc trưng của ứng dụng đều được lưu trữ tại lớp này. Ví dụ, trong trường hợp của một ngân hàng, chúng ta muốn sinh một thông báo khi một khách thẻ tín dụng của khách hàng nợ đến một mức nào đó. Loại thông tin này có thể được duy trì thông qua một trigger của cơ sở dữ liệu- nó sẽ active tại các thời điểm tương ứng. Lấy ví dụ với một search engine, không quan tâm tới tất cả các banner động, ảnh và các thứ trang trí khác. Giao diện của search engine rất đơn giản, người sử dụng gõ vào một chuỗi khóa. Back end được tổ chức là một cơ sở dữ liệu lớn đã được index và tìm nạp trước. Core của search engine là một chương trình chuyển chuỗi ký tự của người sử dụng thành một số câu query. Sau đó, kết quả được sắp xếp vào list và chuyển list tới các các trang HTML. Trong mô hình client-server, phần thông tin thu được đặt tại lớp processing. Đa kiến trúc (xét trên khía cạnh vật lý) - Xét về mặt vật lý, khi phân phối một ứng dụng phân tán, khả năng tổ chức của ứng dụng đấy có thể như sau : Mô hình phân tách máy khách (client machine) và máy phục vụ (server machine) được gọi là kiến trúc 2 tầng (two-tiered architecture). Kiến trúc này có tới 5 tình huống khác nhau. Tình huống (a) là khi máy khách có một phần của lớp giao diện, được sử dụng như một remote, còn máy phục vụ chứa phần còn lại của ứng dụng. Tình huống (e) là một tình huống rất phổ biến hiện nay nhất là ở các ngân hàng, khi mà máy khách là một PC hay máy trạm, kết nối thông qua mạng tới một hệ thống file hoặc cơ sở dữ liệu phân tán. Khi đó, ứng dụng chạy chủ yếu trên máy khách nhưng mọi thao tác đến các file và cơ sở dữ liệu đều phải thực hiện trên server. - Kiến trúc tiếp theo là kiến trúc 3 tầng (three-tiered architecture), kiến trúc này mô tả khi server lại hoạt động như một client Kiến trúc phi tập trung - Trong nhiều doanh nghiệp, việc phân phối các tiến trình tương đương với việc tổ chức các ứng dụng Client-Server như một đa kiến trúc. Hệ thống phân tán này gọi là phân tán theo chiều dọc (vertical distribution). Đặc trưng của kiến trúc này là đặt các thành phần logic khác nhau trên các máy khác nhau. Thuật ngữ này liên quan đến khái niệm phân mảnh dọc (vertical fragmentation) được sử dụng trong cơ sở dữ liệu quan hệ phân tán, khi mà các bảng (table) được chia thành các cột rồi được phân phối tới nhiều máy. - Đứng về mặt quản lý hệ thống, việc phân phối dọc có thể giúp phân chia các chức năng (cả logic lẫn vật lý) trên nhiều máy khác nhau, mỗi máy được điều chỉnh đảm nhận một nhóm các chức năng cụ thể. - Ở các kiến trúc hiện đại, người ta phân phối theo kiểu phân phối ngang (horizontal distribution), khi đó client và server có thể được chia trên các thành phần vật lý tương đương nhau (logical equivalent part), mỗi phần lại hoạt động trên chính tập dữ liệu của chúng, do đó cân bằng tải. Một lớp kiến trúc hệ thống hỗ trợ phân phối ngang là hệ thống peer-to-peer. Các kiến trúc Peer-to-peer có cấu trúc Ở mô hình kiến trúc này, mạng overlay (overlay network) được cấu trúc bởi một thủ tục (procedure) có tính quyết định. Thủ tục được sử dụng nhiều nhất là tổ chức tiến trình thông qua bảng băm phân tán (distributed hash table-DHT) Trong hệ DHT (tạm gọi như vậy), các mục dữ liệu (data items) được gán một khóa ngẫu nhiên trong một không gian định danh lớn (from a large indentifier space), ví dụ như định danh bởi 128-bit hoặc 160-bit. Cũng như vậy, các nút (node) trong hệ thống cũng được gán một số ngẫu nhiên với cùng một không gian định danh (same identifier space). Vấn đề của tất cả các hệ thống DHT là cài đặt một một thiết kế hiệu quả và tất định (an efficient and deterministic scheme) sao cho ánh xạ duy nhất khóa của mục dữ liệu tới định danh của nút dựa trên sự khác biệt về metric (some distance metric) Quan trọng nhất, khi tìm kiếm một mục dữ liệu, địa chỉ mạng của node chịu trách nhiêm đối với dữ liệu đó được trả về. Thực tế, nó được thực hiện bằng cách định tuyến một yêu cầu về 1 mục dữ liệu tới nút chịu trách nhiệm. Ví dụ với hệ thống Chord, các nút được tổ chức logic dưới dạng vòng, một mục dữ liệu với khóa k được ánh xạ tới các nút với định danh nhỏ nhất id>=k, nút này được tham chiếu như là phần tử tiếp theo của khóa k, và được ký hiệu là succ(k). Khi tìm kiếm một mục dữ liệu, một ứng dụng chạy trên một nút bất kỳ sẽ gọi tới hàm LOOKUP(k), hàm này sau đó trả về địa chỉ mạng của succ(k). khi đó, ứng dụng có thể liên lạc tới nút để sao chép dữ liệu cần thiết. Ở chương này chúng ta ko đi vào giải thuật tìm kiếm khóa, vấn đề này sẽ được bàn trong chương 5: Naming. Chúng ta sẽ tập trung vào việc các nút được tổ chức như thế nào trong mạng overlay. Khái niệm này được gọi là membership management. Quá trình tìm kiếm khóa tất nhiên không không theo cách tổ chức logic dạng vòng như trên. Thay vào đó, mỗi nút sẽ duy trì các shortcut tới các nút khác theo cách tìm kiếm lần lượt trên tất cả các nút (O(log(N)) bước tối đa–N là số nút mạng). Khi một nút muốn join vào hệ thống, nó sinh bắt đầu bằng việc sinh một định danh-id ngẫu nhiên. Chú ý rằng, nếu không gian định danh đủ, hàm sinh số ngẫu nhiên tốt (is of good quality), xác suất của việc sinh một định danh đã gán cho một nút nào đó là rất nhỏ (tiến dần tới 0 – close to zero). Sau đó, nút đấy có thể thực hiện tìm kiếm trên trường id, địa chỉ mạng của succ(id) sẽ được trả về. Khi đó, nút đấy có thể liên hệ với phần từ tương ứng succ(id) và phần tử liền trước của nó (succ(id)) rồi tự gắn mình vào mạng. Cách này yêu cầu các nút phải lưu các thông tin về phần tử liền trước của nó. Việc chèn thêm nút vào cũng mang lại việc: khóa của mỗi mục dữ liệu bây giờ tương ứng với định dạnh của nút, được truyền từ succ(id). Nói một cách đơn giản: Id của nút cho biết độ lệch của nó tới nút liền trước và liền, và truyền các mục dữ liệu của chúng (its data item) tới succ(id) Các kiến trúc Peer-to-peer phi cấu trúc Hệ thống peer-to-peer phi cấu trúc phần lớn dựa vào các giải thuật ngẫu nhiên để xây dựng mạng overlay (overlay network). Ý tưởng chính ở đây là mỗi nút duy trì một danh sách các nút hang xóm, list này được tạo nên theo một cách ngẫu nhiên. Các mục dữ liệu cũng được đặt ngẫu nhiên vào nút. Kết quả là, khi một nút muốn xác định vị trí của một mục dữ liệu cụ thể, điều duy nhất có hiệu quả là flood mạng với 1 truy vấn tìm kiếm. Chương 5 chúng ta sẽ bàn thêm về mạng overlay phi cấu trúc, bây giờ chúng ta sẽ tập trung vào membership management. Một trong những mục đích của rất nhiều hệ thống peer-to-peer phi cấu trúc là tạo nên mạng overlay tương đồng với một random graph. Mô hình cơ bản là mỗi nút duy trì một list c các nút lân cận, mỗi một nút lân cận đó lại là kết quả của việc chọn ngẫu nhiên một nút đang “sống” (live node) từ tập các nút hiện tại. List đó được gọi là partial view (khung nhìn cục bộ). Có rất nhiều cách để xây dựng khung nhìn cục bộ. Jelasity et al. (2004, 2005) đã phát triển một framework cho phép capture rất nhiều giải thuật khác nhau dành cho kết cấu overlay (overlay construction) cho phép định giá và so sánh. Ở framework này, các nút định kỳ thay đổi các entry trong partial view, mỗi một entry xác định một nút trong mạng và có tuổi tương ứng để chỉ ra tuổi của quá trình tham chiếu tới nút đó. Hai luồng thường được sử dụng, xem hình minh họa 2-9 Active thread dùng để khởi động quá trình truyền thông với nút khác. Nó chọn nút đó từ partial view hiện tại. Các entry cần bị đẩy (to be pushed) vào các peer đã được chọn, nó tiếp tục bằng cách xây dựng bộ đệm chứa c/2 +1 entry, gồm cả định danh của các entry. Các entry khác được chọn từ partial view hiện tại. Nếu một nút ở chế độ pull (pull mode). Nó sẽ chờ phản hồi từ peer đã được chọn. Peer đó, trong lúc đấy cũng xây dụng bộ đệm bằng cách sử dụng passive thread (2-9.b) Điểm cốt yếu ở đây là cấu trúc của một partial view mới. Khung nhìn này, ban đầu cũng như contacted peer, đều chứa chính xác c entry. Có 2 cách để tạo một khung nhìn mới. Cách đầu tiên, 2 nút có thể quyết định loại bỏ các mục mà chúng đã send cho nhau. Ở phương pháp này, chúng sẽ hoán đổi một phần khung nhìn ban đầu. Các tiếp cận thứ 2 là loại bỏ các càng nhiều càng tốt các nút “già”. Nói đến vấn đề membership managament, khi một nút muốn join, nó liên hệ với một nút bất kỳ,có thể từ một list các điển truy nhập (a list of well-known points). Điểm truy nhập này là một thành viên bình thường của mạng overlay. Khi đó, nó gọi ra (turn out) các giao thức chỉ sử dụng push mode hoặc chỉ pull mode có thể dẫn điễn việc disconected overlay. Nói cách khác, các nhóm nút sẽ bị cô lập và không bao giờ có khả năng liên lạc với các nút khác trong mạng. Rõ ràng, đây là một đặc tính không mong muốn, vì lý do đó nó làm cho sự trao đổi entry giữa các nút có ý nghĩa hơn. Topology managemnt of Overlay Networks. Một quá trình quan sát một cách thận trọng sự chuyển và chọn các entry từ các partial view, hoàn toàn có khả năng để xây dựng và duy trì một topo cụ thể cho mạng overlay, mặc dù peer-to-peer có cấu trúc và phi cấu trúc có vẻ như được tạo từ những lớp hoàn toàn độc lập với nhau. Cách thức tổ chức topo này đạt được thông qua mô hình 2 lớp Lớp thấp nhất tạo nên một hệ thống peer-to-peer phi cấu trúc mà trong đó các nút định kỳ trao đổi các entry trong partial view của chúng hướng đến việc duy trì một random graph “đúng đắn” (accurate). “Đúng đắn” ở đây ý nói đến việc partial view sẽ được lấp đầy bởi việc chọn ngẫu nhiên các nút sống (live nodes). Lớp thấp nhất chuyển partial view của nó tới lớp cao hơn, nơi xẩy ra việc lựa chọn thêm các entry. Việc này làm cho xuất hiện danh sách thứ 2 của các nút lân cận tương ứng với topo muốn có. Jelasity và Babaoglu (2005) đã sử dụng 1 hàm sắp xếp (a ranking function) mà các nút được xếp theo một vài tiêu chuẩn, như là khoảng cách tới một nút P nào đó,… Như minh họa ở trên, coi như lưới logic là NxN và các nút được đặt ở mỗi điểm của lưới. Tất cả các nút đều được yêu cầu duy trì danh sách các nút lân cận gần nhất. Khoảng cách giữa một nút (a1, a2) và (b1, b2) được định nghĩa là d1 + d2 trong đó di = min(N - |ai - bi|, |ai – bi|) Nếu lớp thấp nhất định kỳ thực hiện giao thức (protocol) như đoạn code phía trên, mô hình sẽ tiến hóa thành hình xuyến (như trên) Quan trọng là, các giải thuật này có liên quan đến việc giữ lại các liên hệ gần gũi về ngữ nghĩa (capturing the semantic proximity) của dữ liệu được lưu trữ ở mỗi nút. Sự gần này cho phép xây dựng nên mạng overlay theo ngữ nghĩa – cho phép các giải thuật tìm kiếm hiệu năng cao trên hệ thống phi cấu trúc peer-to-peer. Ở chương 5, chúng ta sẽ thảo luận về định danh dựa trên thuộc tính (attribute-based naming) Superpeers Đáng chú ý ở hệ thống phi cấu trúc peer-to-peer, định vị đối tượng dữ liệu có thể trở thành một vấn đề nan giải khi mà mạng mở rộng thêm. Lý do cho vấn đề linh hoạt này rất đơn giản: Khi định tuyến đến các phần tử dữ liệu (data item) không có các đường định trước. Chỉ có một kỹ thuật mà một nút có thể dùng đến là flooding các yêu cầu. Có nhiều cách để chặn flooding, sẽ được bàn đến ở chương 5, như nhiều hệ thống peer-to-peer đều sử dụng 1 nút để duy trì index tới các đơn vị dữ liệu Có nhiều trường hợp mà hệ thống peer-to-peer mất đi tính cân bằng tự nhiên của nó. Ví dụ như trong mạng cộng tác phân phát nội dung (collaborative content delivery network – CDN), các nút có thể hỗ trợ lưu trữ cho các bản sao hosting (hosting copies) của trang web, cho phép các web client truy cập gần hơn và vì thế nhanh hơn. Trong trường hợp này, nút P có thể cần để tìm kiếm tài nguyên, trong trường hợp khác, nó hoạt động như một trung gian môi giới, tập trung các tài nguyên cần thiết cho một số nút Superpeer là nút duy trì index, hoặc hoạt động như một nút trung gian. Ở mô hình trên, tất cả các peer bình thường đều kết nối như một client tới một superpeer nào đó. Tất cả các quá trình truyền thông đến và đi đều thông qua superpeer. Trong nhiều trường hợp , mối lên kểt superpeer-client gần như là cố định, mỗi 1 peer khi tham gia vào mạng đều được gắn vào 1 superpeer cho tới khi nó rời khỏi mạng. Hiển nhiên là, superpeer có tuổi thọ dài hơn các peer thông thường. Để phòng superpeer có những hành vi bất thường, kế hoạch backup có thể được triển khai, như là ghép đôi tất cả superpeer tới 1 cái khác (superpeer khác ?) rồi yêu cầu client kết nối đến cả 2. Cố định các liên kết tới superpeer không phải lúc nào cũng là giải pháp tốt nhất. Ví dụ, trong một mạng chia sẻ file, sẽ là tốt hơn nếu client kết nối tới superpeer – superpeer này duy trì index của các file mà client quan tâm. Trong trường hợp đó, khả năng tìm kiếm thành của client khi cần thiết sẽ lớn hơn. Như chúng ta đã thấy, mạng peer-to-peer hỗ trợ một phương pháp linh hoạt cho các nút tham gia/ rời khỏi mạng. Tuy nhiên, với các mạng superpeer, một vấn đề mới đã được nêu ra, cụ thể là làm sao để chọn được các nút thích hợp để làm superpeer. Vấn đề này liên quan gần đến vấn đề chọn leader (leader-election problem) sẽ được đề cập ở chương 6. Kiến trúc lai Chúng ta đã tiếp cận kiến trúc client-server và vài kiến trúc peer-to-peer. Rất nhiều hệ phân tán kết hợp các đặc trưng kiến trúc như là mạng superpeer. Ở chương này, chúng ta sẽ xem xét 1 vài lớp cơ bản của hệ phân tán mà trong đó, giải pháp client-server kết hợp với kiến trúc phi tập trung dữ liệu. Hệ thống server biên (Edge-server system) Một lớp cơ quan trọng của hệ phân tán là được tổ chức theo kiến trúc phân tầng dưới dạng các hệ thống server biên (Edge server systems). Hệ thống này được triển khai trên Internet-nơi các server đặt tại biên của mạng. Biên này được tạo bởi ranh giới giữa các mạng doanh nghiệp và mạng Internet. (ví dụ, được cung cấp bởi 1 ISP-Internet Service Provider. Tương tự như thế, Các end user kết nối tới internet thông qua ISP của họ, ISP khi đó coi như là ở biên của mạng Internet. End user hay client, kết nối internet gián tiếp qua Edge server. Edge server có nhiệm vụ đáp ứng nội dung, có thể sau khi áp dụng lọc (filtering) và chuyển mã. Tập các Edge server có thể được dùng để optomize nội dung và các ứng dụng phân tán. Chúng ta sẽ trở lại với hệ thống Edge server tại chương 12, khi bàn về các giải pháp web-based. Hệ thống cộng tác phân tán (collaborative distributed system) Kiến trúc phân tầng được đặc biệt triển khai ở hệ thống cộng tác phân tán. Để cụ thể hóa, chúng ta sẽ thảo luận về các hệ thống chia sẻ file BitTorrent. BitTorrent là hệ thống tải file theo kiểu peer-to-peer. Ý tưởng cơ bản là, khi một end user tìm kiếm 1 file, anh ta download các chuck (?) của file từ các user khác, cho tới khi các chuck download được có thể được gắn lại với nhau thành một file hoàn chỉnh. Mục đích quan trọng khi thiết kế chính là đảm bảo được sự cộng tác. Để download 1 file, user phải truy nhập vào globle directory – một vài website. Nó như một thư mục lưu trữ các tham chiếu tới các file .torrent. Một file torrent chứa các thông tin cần thiết để download một file cụ thể. Trong thực tế, chúng tham chiếu tới các tracker, là một server giữ các nút active có các chuck của file được yêu cầu. 1 nút Active khi đang download 1 file khác. BitTorrent là giải pháp kết hợp giữa tập trung và phi tập trung Mô tả kiến trúc phần sụn (middleware) Middleware có dạng như một layer nằm giữa các ứng dụng phân tán và nền tảng (platform) phân tán. Mục đích chính của lớp này là làm trong suốt tính phân tán, cụ thể là mức độ che dấu tính phân tán của dữ liệu, tiến trình, và các điều khiển từ lớp ứng dụng. Trong thực tế, hệ thống middleware thường theo một dạng kiến trúc cụ thể. Ví dụ như CORBA (OMG, 2004a) là kiến trúc đối tượngect-based, trong khi TIB/Rendezvous(TIBCO, 2005) xây dựng theo kiến trúc event-based. Một khi khuôn dạng của middleware đã theo một dạng kiến trúc nào đó, việc thiết kế ứng dụng sẽ đơn giản hơn. Tuy nhiên, có một nhược điểm rất rõ ràng là: middleware không được tối ưu cho việc phát triển các ứng dụng bên trong nó nữa. Lấy ví dụ với CORBA, ban đầu nó chỉ hỗ trợ cho các đối tượng được gọi bởi remote client. Nhưng cách tương tác này có rất nhiền hạn chế, do đó một mô hình tương tác (interaction pattern) như gửi thông báo (messaging) được thêm vào. Việc thêm các tính năng mới lại làm phình ra các giải pháp dành cho middleware (middleware solution). Thêm nữa, mặc dù middleware được sử dụng để làm cho việc phân tán trở nên trong suốt (tính thích nghi giữa 2 lớp trên và dưới, middleware cung cấp một interface cho ứng dụng và platform giao tiếp với nhau mà không bị ảnh hưởng bởi kiến trúc riêng của mỗi lớp). Trên thực tế, một giải pháp (thiết kế middleware) cụ thể sẽ chỉ thích nghi với các yêu cầu của ứng dụng (application requirements – của một ứng dụng, hay của một lớp ứng dụng nào đó). Một giải pháp cho vấn đề này là tạo ra vài phiên bản của miiddleware. Mỗi phiên bản được thiết kế riêng cho một lớp các ứng dụng cụ thể. Một cách tiếp cận tốt hơn là tạo nên một hệ thống middleware mà chúng ta có thể dễ dàng conf, customize, adapt (chỉnh sửa) khi nào ứng dụng cần. Giờ đây, các hệ thống đang được phát triển theo cách mà phần chính sách (policies) và phần cơ chế (mechanisms) luôn được tách biệt rõ ràng. Nên một vài cơ chế có thể bị chỉnh sửa bởi các hoạt động (behavior) của middleware. Chúng ta sẽ xem xét qua một vài cách tiếp cận phổ biến. Interceptors Interceptor có thể coi là một phần mềm, tác dụng của nó là ngắt (break) một luồng điều khiển thông thường để cho phép thực thi một đoạn code khác (application specific) Để cụ thể, ta giải định rằng Interceptor được hỗ trợ trên tất cả các hệ phân tán dựa trên đối tượng (đối tượngect-based). Ý tưởng cơ bản là: Một đối tượng A có thể gọi một phương thức của đối tượng B – khi B không cư trú cùng nơi với A. Giống như một lời gọi đối tượng từ xa, quá trình thực hiện theo 3 bước: Đối tượng A đựa ra một interface cục bộ hoàn toàn giống Interface của đối tượng B. A đơn giản là gọi phương thức có sẵn cho interface này. Lời gọi của A được chuyển vào một lời gọi đối tượng (into a generic object invocation), có khả năng thông qua bởi một interface viện dẫn đối tượng (a general đối tượngect-invocation interface) được cung cấp bởi middleware tại máy A cư trú Đối tượng được viện dẫn được chuyển vào một message, message này được gửi qua giao diện mạng của tầng transport (the transport-layer network interface) như là được gọi bởi hệ điều hành cục bộ của A. Mô tả hình trên: Sau bước đầu tiên, lời gọi B.do_something(value) được chuyển tới một lời kiểu như invoke(B, &do_something, value) với một tham chiếu tới phương thức của B và các tham số của lời gọi). Giờ hình dung rằng, B bị nhân bản (replicate). Trong trường hợp đó, mỗi bản sao đều được gọi đến (invoke). Đây là một thời điểm mà indicaptor hoàn toàn có thể hỗ trợ. Khối request-level interceptor làm một việc đơn giản là gọi invoke(B, &do_something, value) cho mỗi bản sao. Cái hay ở đây là: không những A không cần quan tâm đến bản sao của B, mà đối tượng middleware cũng không cần các thành phần đặc biệt để giải quyết các bản sao của lời gọi. Chỉ có khối request-level interceptor – khối được add thêm vào middleware là cần phải biết về các bản sao của B. Cuối cùng, lời gọi tới một remote đối tượng sẽ được gửi qua mạng. Trong thực tế. điều này có nghĩa là interface của message được hỗ trợ bởi hệ điều hành cục bộ (local) cần được gọi ra. Ở mức này, khối Message-leve Interceptor có thể hỗ trợ truyền các lời gọi tới đối tượng đích. Ví dụ như thế này, ta hình dung giá trị tham số tương ứng với 1 mảng lớn dữ liệu. Trong trường hợp đó, nó sẽ bị chia thành các phần nhỏ hơn sau đó mới được gắn lại ở đích đến. Một lần nữa, middleware không cần quan tâm tới sự phân mảnh này, khối lower-level interceptor sẽ xử lý vấn đề này một cách trong suốt đối vấn phần còn lại của cuộc truyền thông với hệ điều hành cục bộ (địa phương – local) Cách tiếp cận: phần mềm có khả năng thích nghi (General approaches to adaptive software) Interceptor hỗ trợ phương pháp để thích ứng với middleware. Sự thích nghi còn ở chỗ, môi trường thực thi của mỗi phần mềm phân tán luôn thay đổi. Sự thay đổi bao gồm cả kết quả của tính di động (resulting of mobility), sự khác biệt lớn trong chất lượng dịch vụ (QoS) của mạng, nhược điểm của phần cứng và rất nhiều thứ khác. Thay vì làm các ứng dụng tự thích nghi với thay đổi, thì với interceotor nhiệm vụ đấy được chuyển cho middleware. Tác động của môi trường đã làm xuất hiện khái niệm adaptive software (phần mềm có khả năng thích ứng). Tuy nhiên, adaptive software không được thành công như mong đợi. Theo nhiều nghiên cứu và quan điểm của các developer, nó là diện mạo của các hệ phân tán hiện đại (modern distributed systems). Ba kỹ thuật cơ bản của adaptive software: Tách biệt các quan hệ (separation of concern) Phản chiếu sự tính toán (computational reflection) Thiết kế dựa trên các thành phần (component-based design) Separation concern lên quan đến cách thức truyền thống dùng để modul hóa hệ thống: tách phần thực thi với các thành phần khác (được biết đến với tên gọi: extra functionalities) như: tính tin cậy, tính hiệu năng, tính bảo mât, …Tuy nhiên vấn đề ở đây là chúng ta không dễ để có thể tách biệt ra được các extra dunctionality bằng các phương thức của modul hóa. Lấy ví dụ, rất khó để hình dung ra làm sao khả năng chịu lỗi có thể bị cách ly ở trong một cái hộp riêng biệt (into a separate box) và “giải quyết” như một dịch vụ độc lập (sold as indepentdent service). – Nền tảng kỹ thuật này được áp dụng trong aspect-oriented software development (Filman et al., 2005) như aspect-oriented đã không được áp dụng thành công khi phát triển một hệ thống phân tán cỡ lớn. Computational reflection nói đến khả năng của tự kiểm soát của một chương trình và nếu cấn thiết, thì thích ứng với các hành vi (Kon et al., 2002) Reflection được xây dựng trong các ngôn ngữ lập trình, có cả java, và cung cấp một khả năng mạnh mẽ cho các chỉnh sửa khi đang chạy (runtime modifications). Thêm vào đó, một số hệ thống moddleware cũng cấp phương thức để cập nhật các kỹ thuật reflection. Giống như aspect orientation, reflecttive middlware không chứng minh được nó là một công cụ mạnh mẽ để quản lý một mạng phân tán cỡ lớn. Component-based design hỗ trợ khả năng thich nghi xuyên cấu trúc (adaptation through coposition). Một hệ thống có thể được cấu hình tĩnh tại thời điểm design hoặc động tại thời điểm chạy (runtime). Kỹ thuật này đã áp dụng thành công vào các môi trường trong ngôn ngư lập trình nhưng lại vẫn quá phức tạp với hệ phân tán, đặc biệt là khi thay thế một thành phần thì yêu cầu là phải biết tác động của sự thay thế đó tới các thành phần khác. Trong nhiều trường hợp, các thành phần ít độc lập hơn ta tưởng. Thảo luận Kiến trúc của các phần mềm cho các hệ phân tán, đặc biệt là middleware rất rộng lớn và phức tạp. Phần lớn sự rộng lớn và phức tạo này cần phải được trong suốt với giác quan con người. Xem xét đến việc hầu như tất cả các hệ thống phần mềm cỡ lớn hiện nay đều được yêu cầu thực thi trong môi trường mạng, chúng ta có thể tự hỏi bản thân khi nào sự phức tạp của các hệ thống phân tán đơn giản hóa các đặc tính cố hữu để có thể làm trong suốt sự phân tán. Giả định rằng, điều chúng ta cần là adaptive software – cho phép thay theo thay đổi của môi trường. Lỗi phần cứng, tấn công bảo mật, thất thoát năng lượng, và nhiều vấn đề khác cùng với các anh hưởng của môi trường cần phải được phần mềm dự trù trước. Một tham số rõ ràng, hợp lý nhất để “hỗ trợ” adaptive software đó là rất nhiều hệ thống phân tán không thể bị tắt (shutdown). Các giải pháp thay thế và nâng cấp cần phải được thực hiện khi hệ thống đang chạy (on the fly). Còn vấn đề bảo dưỡng thì vẫn chưa có được giải pháp tốt nhất. Vấn đề còn lại chúng là các hệ phân tán có khả năng phải ứng với các thay đổi của môi trường, ví dụ, chuyển đổi các chính sách phẩn bổ tài nguyên. Tất cả các thành phần cho phép sự thích nghi đó cần được sẵn sàng. Chính là các giải thuật bên trong các thành phần đó và các lệnh làm thay đổi chính thiết lập của chúng. Làm sao để sự tác động trở lại vào môi trường không cần có tác động của con người. Hướng tiếp cận này có vẻ tốt hơn khi ta thảo luận về tổ chức vật lý của các hệ phân tán, ví dụ khi ta quyết định vị trí đặt các thành phần Tính tự trị trong các hệ phân tán. Các hệ phân tán – và đặc biệt là middleware kết hợp với nó – cần được cung cấp các giải pháp chung để chặn các tính năng không mong muốn vốn có của mạng, do đó chúng có thể hỗ trợ nhiều ứng dụng nhất có thể. Mặc khác, full distribution transparency không phải là những gì mà ứng dụng thực sự muốn, kết quả của các giải pháp ứng dụng cụ thể cần được hỗ trợ tốt. Vì lý do đó, chúng chỉ rõ rằng, các hệ phân tán có khả năng thích nghi, đặc biệt là khi chúng trở nên thích nghi với các trạng thái thi hành của mình và không thích nghi với các thành phần phần mềm mà nó có. Khi việc thích nghi cần được thực hiện tự động, chúng ta sẽ thấy sự ảnh hưởng lẫn nhau một cách mạnh mẽ giữa kiến trúc hệ thống và kiến trúc phần mềm. Một mặt, chúng ta cần tổ chức các thành phần của hệ phân tán như việc thực hiện kiểm tra và điều chỉnh, mặt khác chúng ta cần quyết định quá trình xử lý được thực hiện ở đâu để điều khiển việc thích nghi. Trong phần này chúng ta tổ chức các hệ phân tán như các hệ điều khiển phản hồi mức cao cho phép việc tự động thích nghi với các thay đổi. Hiện tượng này được biết đến như là autonomic computing (Kephart, 2003) hoặc các hệ thống self-star (Babaoglu et al,2005). Tên cuối cùng chỉ ra sự khác nhau bởi việc tương thích tự động nào sẽ capture: self-managing, self-healing, self-configuring, self-optimizing và hơn nữa. Chúng ta chỉ đơn giản sử dụng tên: các hệ tự trị (self-managing systems) để hội tụ tất cả các tính năng trên của nó. 2.4.1. Mô hình điều khiển phản hồi (The feedback control model) Có nhiều cách nhìn khác nhau về các hệ thống tự trị nhưng nhìn chung là: việc thích nghi xảy ra bằng (gián tiếp qua) một hoặc nhiều feedback control loop. Theo đó, các hệ thống được tổ chức gián tiếp như các loop được đề cập đến như hệ điều khiển phản hồi (feedback control systems). Điều khiển phản hồi được áp dụng từ lâu trong nhiều lĩnh vực kỹ thuật khác nhau, và nền tảng toán học của nó là dần dần được áp dụng trong các hệ thống máy tính (Hellerstein et al., 2004; and Diao et al., 2005). Đối với các hệ tự trị, các vấn đề kiến trúc được quan tâm nhiều nhất. Ý tưởng cơ bản đằng sau việc tổ chức này rất đơn giản, hình 2-16. Lõi của hệ điều khiển phản hồi được tạo thành bởi các thành phần cần được quản lý. Các thành phần này được điều khiển qua các tham số đầu vào có thể điều khiển được, nhưng hành vi của chúng có thể bị ảnh hưởng bởi tất cả các kiểu của đầu vào không thể điều khiển được, được biết đến như nhiễu đầu vào. Có 3 thành phần cơ bản tạo thành feedback control loop. Đầu tiên, hệ thống tự nó cần được giám sát trong khi yêu cầu các mặt khác nhau của hệ thống cần được đo lường. Trong nhiều trường hợp, hoạt động đo lường nói dễ hơn làm. Ví dụ, trễ round-trip trong Internet có thể rất lộn xộn (rất nhiều) và cũng phụ thuộc vào cái gì được đo lường. Trong những trường hợp đó, việc đánh giá chính xác độ trễ có thể rất khó khăn. Các vấn đề phực tạp hơn khi một nút A cần đánh giá thời gian chờ giữa hai nút khác là nút B và nút C, mà không thể xâm nhập vào hai nút này. Đối với các lý do như này, feedback control loop chứa thành phần độ đo ước lượng logic (a logical metric estimation component) Một thành phần khác của feedback control loop phân tích sự đo đạc và so sánh với các giá trị tham chiếu. Thành phần phân tích phản hồi này (feedback analysis component) tạo thành trái tim của control loop, nó chứa thuật toán quyết định việc tương thích có thể. Thành phần cuối cùng chứa các kỹ thuật khác nhau trực tiếp ảnh hưởng đến hoạt động của hệ thống. Có một vài kỹ thuật: tạo bản sao, changing scheduling priorities, switching services, di chuyển dữ liệu vì một số lý do có sẵn (moving data for reason of availability), chuyển hướng yêu cầu đến các server khác nhau (redirecting requests to different servers)… Thành phần phân tích này sẽ cần được nhận biết của các kỹ thuật này và ảnh hưởng trên hoạt động của hệ thống. Do đó, nó sẽ khởi động một hoặc nhiều kỹ thuật, sau đó quan sát ảnh hưởng. Một quan sát thú vị là feedback control loop cũng thích hợp với việc quản lý bằng tay của hệ thống. Sự khác biệt chính là thành phần phân tích được thay thế bởi sự quản trị của con người. Tuy nhiên, để quản lý chính xác bất kỳ hệ phân tán nào, việc quản trị này cũng cần bị giám sát cũng như các kỹ thuật thích hợp để điều khiển hoạt động của hệ thống. Nên rõ ràng rằng: việc phân tích dữ liệu đo lường chính xác và việc khởi động các hoạt động đúng tạo sự phát triển của các hệ tự trị rất khó khăn. Nên nhấn mạnh rằng hình 2.16 chỉ ra tổ chức logic của hệ tự trị và tương ứng với những gì chúng ta thấy khi thảo luận các kiến trúc phần mềm. Tuy nhiên, tổ chức vật lý có thể sẽ rất khác. Ví dụ, thành phần phân tích của thể hoàn toàn phân tán qua hệ thống. Cũng như vậy, việc đo sự thực thi được thực hiện thường xuyên tại mỗi một máy là 1 phần của hệ phân tán. Bây giờ chúng ta nhìn vào một vài ví dụ để thấy được sự giám sát, phân tích và sửa lỗi hệ phân tán như thế nào trong mô hình tự động. Các ví dụ này miêu tả sự phân biệt giữa tổ chức logic và vật lý. 2.4.2. Ví dụ: giám sát hệ thống với Astrolabe Trong ví dụ đầu tiên của chúng ta, chúng ta thấy Astrolabe (Van Renesse et al., 2003) là hệ thống có thể hỗ trợ việc giám sát chung của các hệ thống phân tán rất lớn. Trong ngữ cảnh của hệ tự trị, Astrolabe được đặt vào vị trí như một công cụ chung đối với hoạt động của hệ quan sát. Đầu ra của nó có thể được sử dụng để cung cấp cho thành phần phân tích để quyết định hoạt động đúng đắn. Astrolabe tổ chức các tập hợp lớn của các host trong sự phân cấp các vùng. Các vùng ở mức thấp nhất chỉ chứa 1 host, sau đó được nhóm vào thành các zones of increasing size. Vùng ở mức cao bao phủ tất cả các host. Mỗi một host chạy một xử lý Astrolabe, được gọi là agent, tập hợp thông tin trên tất cả các vùng chứa host. Agent cũng đồng thời giao tiếp với các agent khác với mục đích truyền thông tin của vùng qua toàn bộ hệ thống. Mỗi một host duy trì tập các thuộc tính cho việc tập hợp thông tin cục bộ. Ví dụ, một host có thể kiểm tra các file đặc trưng mà nó chứa, cách sử dụng tài nguyên của nó và hơn nữa. Chỉ các thuộc tính được duy trì trực tiếp bởi host, tại mực thấp nhất của sự phân cấp có thể ghi được (writeable). Mỗi một vùng cũng có thể có tập các thuộc tính, nhưng các giá trị của các thuộc tính này được tính toán từ các giá trị của các vùng mức thấp hơn. Một ví dụ được chỉ ra trong hình 2-17 với 3 host, A, B, C được nhóm vào một vùng. Mỗi một máy có một địa chỉ IP, CPU load, available free memory và số các xử lý hoạt động. Mỗi một thuộc tính này có thể được ghi trực tiếp sử dụng thông tin cục bộ từ mỗi một host. Tại mức vùng, chỉ các thông tin đã nhóm lại có thể được tập hợp lại như độ tải trung bình của CPU hoặc số các xử lý đang hoạt động trung bình. Hình 2-17 chỉ ra thông tin được lấy lại bởi mỗi một máy có thể được xem như bản ghi trong một cơ sở dữ liệu như thế nào, và những bản ghi này tập hợp với nhau tạo thành bảng. Sự thể hiện này được thực hiện với mục đích: nó là cách mà Astrolabe view tất cả dữ liệu được tập hợp. Tuy nhiên, mỗi một thông tin của một vùng có thể chỉ được tính toán từ các bản ghi cơ bản như được duy trì bởi host. Thông tin được nhóm lại có được bởi chức năng tập hợp có thể lập trình được, chức năng này tương tự như chức năng trong SQL. Ví dụ, giả sử rằng thông tin của host từ hình 2-17 được duy trì trong bảng cục bộ được gọi là hostinfo, chúng ta có thể tập hợp số trung bình của các xử lý đối với vùng chứa các máy A, B, C qua một câu truy vấn SQL đơn giản. SELECT AVG(procs) AS avg_Procs FROM hostinfo Kết hợp với một vài sự nâng cao của SQL, không khó để tưởng tượng rằng nhiều câu truy vấn thông tin được tính toán. Các truy vấn tiếp tục được tính toán bởi mỗi một agent chạy trên mỗi host. Rõ ràng, có thể nếu thông tin của vùng được quảng bá đến tất cả các nút có Astrolabe. Để kết thúc phần này, một agent chạy trên một host chịu trách nhiệm tính toán các bảng của các vùng kết hợp của nó. Kết quả của việc trao đổi thông tin là cuối cùng, tất cả các agent mà cần có mặt (giúp đỡ) trong việc đạt được thông tin kết hợp sẽ thấy cùng một kết quả (được thông báo rằng không có thay đổi xảy ra trong lúc đó). 2.4.3. Ví dụ: Phân biệt sự sao chép strategy trong Globule Chúng ta hay xem xét Globule, một mạng phân tán cộng tác nội dung. Globule dựa vào các end-user server của Internet, và những server này cộng tác để tối ưu thực thi qua việc sao chép trang web. Để làm được điều đó, mỗi một server gốc (ví dụ : server chịu trách nhiệm điều khiển việc update của một website) kiểm tra mẫu truy cập trên cơ sở của mỗi một trang. Các mẫu truy cập rất rõ ràng khi đọc và ghi thao tác cho một trang, một một thao tác được gán nhãn thời gian và được log bởi server gốc đối với trang đó. Trong mẫu đơn giản nhất, Globule giả sử rằng Internet có thể được xem như một hệ thống edge-server (server biên) như chúng ta đã giải thích trước đó. Cụ thể, giả sử rằng các yêu cầu luôn luôn qua một server biên thích hợp, như hình 2-18. Mô hình đơn giản này cho phép server gốc nhìn thấy điều gì sẽ xảy ra nếu nó đặt một bản sao vào một server biên đặc trưng (nào đó). Một mặt, việc tạo một bản ghi gần với client sẽ cải thiện thời gian chờ của client, nhưng điều này sẽ giảm lưu lượng giữa server gốc và server biên để giữ bản sao thống nhất với server gốc. Khi một server gốc nhận một request cho một trang, nó ghi địa chỉ IP từ nơi khởi tạo yêu cầu, và xem ISP hoặc mạng doanh nghiệp kết hợp với request đó sử dụng dịch vụ WHOIS của Internet. Server gốc tìm kiếm server bản sao tồn tại gần nhất mà có thể hoạt động như server biên cho client đó, và sau đó tính toán thời gian chờ server đó với băng thông lớn nhất. Trong cấu hình đơn giản nhất của nó, Globule giả sử rằng thời gian chờ giữa server bản sao và máy của user tạo request là không đáng kể, và cũng như vậy băng thông giữa cả hai là rất lớn. Khi đủ yêu cầu cho một trang được tập hợp, server gốc thực thi một “cách phân tích what-if” đơn giản. Một phân tích giảm (cô đọng) việc đánh giá các chính sách của việc sao chép, ở đó một chính sách miêu tả một trang nào đó được sao chép ở đâu và trang đó được giữ cho thống nhất như thế nào. Mỗi một chính sách sao chép phải có cost có thể được biểu diễn như một hàm tuyến tính đơn giản: Cost = (w1 x m1 ) +( w2 x m2 ) + … + (wn x mn) Ở đó, mk là metric thực thi và wk là weight chỉ ra metric đó. Các metric điển hình là độ trễ giữa một client và một server khi trả vể bản sao của trang web được nhóm lại với nhau, tổng băng thông sử dụng giữa server gốc và server bản sao cho việc giữ bản sao thống nhất và số các bản sao cũ được trả về cho client. Ví dụ, giả sử rằng độ trễ điển hình giữa thời gian một client C đưa ra request và khi trang đó được trả về từ server sao chép tốt nhất là dC ms. Chú ý rằng server sao chép tốt nhất là gì được quyết định bởi chính sách sao chép. m1 chỉ ra độ trễ được gộp lại qua một chu kỳ thời gian được đưa ra, nó sẽ lựa chọn giá trị tương đối cao cho w1. Sau đó, chỉ những chính sách mà m1 tối thiểu thực sự sẽ chỉ ra để có cost tương đối thấp. Trong Globule, server gốc đánh giá khoảng vài chục chính sách sao chép sử dụng mô phỏng trace-driven, đối với một trang web phân biệt. Từ những mô phỏng này, một chính sách tốt nhất được lựa chọn và sau đó bắt buộc phải tuân theo chính sách đó (enforced). Điều này có ý rằng, các bản sao mới được thiết lập tại các server biên khác nhau, hoặc một cách giữ bản sao thống nhất khác được lựa chọn. Tập các đường đi, việc đánh giá các chính sách sao chép, và việc ép buộc sử dụng chính sách được lựa chọn được thực hiện hoàn toàn tự động. Có một số vấn đề khó thấy mà cần phải giải quyết. Điều đầu tiên, không rõ rằng, có bao nhiêu request cần được tập hợp trước khi đánh giá các chính sách hiện tại. Để giải thích, giả sử rằng tại thời điểm Ti server gốc lựa chọn chính sách p cho chu kỳ tiếp theo đến tận Ti+1. Việc lựa chọn xả ra dựa trên chuỗi các request trong quá khứ mà đã đưa ra giữa Ti-1 và Ti. Tất nhiên, tại thời điểm Ti+1, server có thể dẫn đến việc chấm dứt và chính sách p* được lựa chọn cho các request hiện tại và được đưa ra giữa Ti và Ti+1. Nếu P* khác với p, thì việc lựa chọn p tại Ti là sai. Khi kết thúc, tỷ lệ phần trăm của việc dự đoán sai phụ thuộc vào độ dài của chuỗi request ( được gọi là trace length) mà được sử dụng để dự đoán và lựa chọn chính sách tiếp theo. Sự phụ thuộc này được chỉ ra trong hình 2-19. Những gì được nhìn thấy là lỗi trong quá trình dự đoán trước chính sách tốt nhất được đưa ra nếu trace không đủ dài. Điều này rất dễ giải thích bởi thực tế rằng, chúng ta cần có đủ các request để thực hiện đánh giá chính xác. Tuy nhiên, lỗi cũng có thể tăng nếu chúng ta sử dụng quá nhiều request. Lý do cho việc này là độ dài trace quá dài do đó có nhiều thay đổi trong mẫu truy cập làm cho việc dự đoán chính sách tốt nhất để theo trở nên khó khăn, nếu có thể (wtf ?). Hiện tượng này rất phổ biến và tương tự như việc cố gằng dự đoán trước thời tiết ngày mai bằng việc nhìn vào những đã xảy ra trong suốt 100 năm trước. Việc dự đoán sẽ tốt hơn nhiều bằng việc chỉ nhìn vào quá khứ gần. Việc tìm kiếm độ dài trace tối ưu được thực hiện tự động rất tốt. Chúng ta sẽ phác hoạ giải pháp cho vấn đề này.