10/21/2010 1 NNộộii dungdung – Các mô hình kiến trúc • Layers • System Architectures • Interfaces and objects • Design requirements – Các mô hình cơ sở • Interaction • Failure • Security CÁCCÁC MÔMÔ HÌNHHÌNH KIKIẾẾNN TRÚCTRÚC CácCác mômô hìnhhình kikiếếnn trúctrúc Những mối quan tâm chính: ◦ Quản trị ñược, có ñộ tin cậy, có khả năng thích ứng và chi phí hợp lý ◦ Dễ dàng thiết kế ◦ Các thành phần ñược bố trí một cách hữu dụng ◦ Quan hệ nội tại giữa các thành phần CácCác llớớpp phphầầnn mmềềmm •Cấu trúc phần mềm theo modules • quản lý sự phức tạp – chia ñể trị • trách nhiệm tập thể ñối với mỗi chức năng cụ thể của mỗi lớp • Mỗi lớp phải nhất quán • Cho phép linh hoạt thay thế một lớp bằng một lớp tương ñương CácCác llớớpp phphầầnn mmềềmm Applications, services Middleware Operating systems Computer and network hardware Applications, services Middleware Operating systems Computer and network hardware Hai ý tưởng trừu tượng của các lớp phần mềm Platform CácCác llớớpp phphầầnn mmềềmm vàvà cáccác thôngthông ñiñiệệpp Các thông ñiệp ñược chuyển giữa các lớp phần mềm Applications, services Middleware Operating systems Computer and network hardware messages messages messages 10/21/2010 2 CácCác llớớpp phphầầnn mmềềmm chínhchính • Platform – Phần mềm cấp thấp & phần cứng • Hệ ñiều hành, mạng, CPU, bộ ñịnh tuyến (routers), máy in .v.v. • Middleware (phần mềm có nhiệm vụ che dấu sự không ñồng nhất) – Lớp giữa hay lớp ứng dụng và lớp nền tảng – Giúp trừu tượng và che dấu sự không ñồng nhất – Nó hoạt ñọng như một người trung gian giữa các ứng dụng và nền tảng – ðiều này giúp giảm hẹp sự phụ thuộc vào nền tảng (chỉ là phụ thuộc vào middleware) LLớớpp ModdlewareModdleware Applications, services Middleware Operating systems Computer and network hardware Platform Request(s) Request(s)Response(s) Response(s) Lớp Midleware hoạt ñộng như một người trung gian môi giới xử lý các yêu cầu của lớp ứng dụng CácCác kikiếếnn trúctrúc hhệệ ththốốngng Client Client Client Server Server invocation invocation invocation invocation result result result result = message = process= computer Proxy serverProxy server Client Client Server invocation result Server Server invocation result Proxy serverProxy server Client Client Proxy Server request reply Web Server Web Server request reply Peer processesPeer processes Application Coordinator Application Coordinator Application Coordinator 10/21/2010 3 Other client server modelsOther client server models • Thick client – Nếu client tiến hành một số chức năng logic (xử lý)và giao diện • Thin client – Server cung cấp gần như tất cả các chức năng logic (xử lý) – client chỉ chịu trách nhiệm chức năng thể hiện (giao diện) CácCác mômô hìnhhình ClientClient Server Server kháckhác • Máy tính mạng (Net-Computer) – Download Os và ứng dụng từ server – Sử dụng các cấu hình thấp – Tăng lưu thông mạng • Mã di ñộng (Mobile code) – Download mã từ sever – ðoạn mã này sẽ ñảm trách việc truyền thông với server – ðây là một phương thức mã của các ứng dụng phân tán Spontaneous networksSpontaneous networks Internet gateway PDA service Music service service Discovery Alarm Camera Guest's devices Laptop TV/PC Hotel wireless network Interfaces Interfaces vàvà ññốốii ttượượngng • Interfaces xác ñịnh các phương thức (methods) mà client có thể sử dụng • Phương thức truyền thống – Các tiến trình của server ñược ñịnh nghĩa rõ ràng cung cấp một số các tác vụ • Phương pháp hương ñối tượng – Các tiến trình cụ thể ở server có thể ñược gọi – ðiều này khổng tĩnh mà có thể ñược tạo vào lúc thực hiện(run-time) CÁCCÁC YÊUYÊU CCẦẦUU THITHIẾẾTT KKẾẾ CácCác yêuyêu ccầầuu ccủủaa thithiếếtt kkếế • Các yêu cầu về hiệu năng – Tính trách nhiệm (Responsiveness) • Chúng ta muốn có một hệ thống có trách nhiệm • ðiều này bị ảnh hưởng bởi mạng latency, lưu lượng, hàng ñợi server, số lớp phần mềmthe number of software layers – Throughput • Xác ñịnh khả năng của một DIS? – Cân bằng tải • Chúng ta có thể chia sẽ công việc ñể nâng cao hiêu năng ? 10/21/2010 4 CácCác yêuyêu ccầầuu thithiếếtt kkếế • Các yêu cầu về chất lượng của dịch vụ – ðòi hỏi các mức ñộ hiệu năng hợp lý cho mỗi lớp • An toàn và tin cậy – Tính sẳn sàng của dịch vụ – Tính ñúng ñắn của dịch vụ ñược cung cấp – Tính an toàn của hệ thống CÁCCÁC MÔMÔ HÌNHHÌNH CCƠƠ SSỞỞ CácCác mômô hìnhhình ccơơ ssởở • Mô hình tương tác • Mô hình sự cố (Failure model) • Mô hình an toàn (Security model) MôMô hìnhhình ttươươngng táctác • Các khía cạnh của tương tác cần ñược xem xét: – Nhiều server tương tác, tương tác giữa các tiến trình của peer – Các ñồng hồ và lịch – ðồng bộ – Bất ñồng bộ – Thứ tự các sự kiện MôMô hìnhhình ttươươngng táctác • Lịch của các sự kiện – Các ñồng hồ ñược dùng ñể: • Xác ñịnh một thứ tự của các sự kiện • ðiểuphối các kiện gần như thời gian thực • Cho phép suy diễn trạng thái toàn cục dựa trên các thông tin cục bộ. – Các ñồng hộ chạy với các tốc ñộ khác nhau (clock drift) – Trong DS sắp xếp thứ tự các sự kiện quan trọng hơn ñồng bộ với một ñồng hồ toàn cục MôMô hìnhhình ttươươngng táctác • Thứ tự thông ñiệp A B C send receive 1 2 5 6 7 9 8 M 1 M 3 M 3 M 4 time time time receive M 2 4 3 B receives M1 then M2 C receives M4 then M3 This was not the true sequence of events 10/21/2010 5 MôMô hìnhhình ttươươngng táctác • Sắp thứ tự là quan trọng – M3 = Balance+10 – M4 = Balance*0.1 – M3 then M4 = (Balance+10)*0.1 – M4 then M3 = (Balance*0.1)+10 • Solution is to timestamp – But times can be inaccurate • Solution is to use logic – If time is not essential MôMô hìnhhình ttươươngng táctác • ðồng bộ – Cố gắng bảo ñảm ñồng bộ hóa – Gắn yếu tố thờ gian • Các tiến trình và truyền thông • Clock drift là xác ñịnh và gắn yếu tố thời gian • Bất ñồng bộ – Không bảo ñảm ñồng bộ hóa – Không gắn yếu tố thời gian • Không gắn yếu tố thời gian cho tiến trình và truyền thông • Clock drift là một biến MôMô hìnhhình ssựự ccốố • Các khía cạnh của sự cố ñược xem xét: – Omission failures • Thông ñiệp/tiến trình bị mất – Timing failures • Thông ñiệp/tiến trình không thỏa ràng buộc về thời gian – Reliability • Bảo ñảm tính giá trị và nhất quán MôMô hìnhhình ssựự ccốố • Các khía cạnh sự cố cần xem xét: – Arbitrary failures • Các sự cố không xác ñịnh xảy ra ngẫu nhiên – Failure transparency • Các sự cố có thể ñược che dấu ñối với người dùng MôMô hìnhhình an an toàntoàn • Các khía cạnh an toàn cần ñược xem xét: – Bảo vệ dữ liệu • quyền truy xuất, cấp ñộ truy xuất, xác thực – Enemies and threats • Mainly re messaging • Disclosure, manipulation, denial of service, etc. – Security mechanisms • Cryptography, certificates, secure channels, authentication servers, etc. Referenced materialReferenced material • Distributed Systems: Concepts and Deisgn, George Colouris, Jean Dollimore, Tim Kindberg, Addison-wesley, Forth Edition, 2005, ISBN – Power point slides, text quotations, examples and diagrams • Distributed Operating Systems, A.S.Tanenbaum, Prentice Hall, 1995, 0-13-143934- 0 – Diagrams and examples . thống CÁCCÁC MÔMÔ HÌNHHÌNH CCƠƠ SSỞỞ CácCác m mô hìnhhình ccơơ ssởở • Mô hình tương tác • Mô hình sự cố (Failure model) • Mô hình an toàn (Security model) M Mô hìnhhình ttươươngng táctác • Các. Các mô hình kiến trúc • Layers • System Architectures • Interfaces and objects • Design requirements – Các mô hình cơ sở • Interaction • Failure • Security CÁCCÁC MÔMÔ HÌNHHÌNH KIKIẾẾNN TRÚCTRÚC CácCác. KIKIẾẾNN TRÚCTRÚC CácCác m mô hìnhhình kikiếếnn trúctrúc Những mối quan tâm chính: ◦ Quản trị ñược, có ñộ tin cậy, có khả năng thích ứng và chi phí hợp lý ◦ Dễ dàng thiết kế ◦ Các thành phần ñược