Luận văn thạc sĩ về kiến trúc triển khai hệ thống phân tán tại ENST Bretagne, Nguyễn Văn Hiền

Luận văn thạc sĩ về architecture de déploiement des systèmes répartis. Nghiên cứu chuyên sâu về kiến trúc triển khai hệ thống phân tán, giải pháp và ứng dụng thực tế.

• Tác giả: Nguyen Van Hien
• Người hướng dẫn: Fabien Dagnat
• Trường học: Ecole Nationale Supérieure Pour l'Informatique des Télécommunications de Bretagne
• Chuyên ngành: Informatique
• Đề tài: Architecture de déploiement des systémes répartis
• Loại tài liệu: Mémoire de fin d'études
• Năm xuất bản: 2007
• Địa điểm: Hanoi

Tóm tắt

I. Hướng dẫn luận văn architecture de déploiement des systèmes répartis

Luận văn thạc sĩ về architecture de déploiement des systèmes répartis là một công trình nghiên cứu chuyên sâu, tập trung vào việc thiết kế và xác thực một kiến trúc hiệu quả cho việc triển khai phần mềm trong các môi trường phân tán. Bối cảnh của đề tài xuất phát từ sự phức tạp ngày càng tăng của các ứng dụng doanh nghiệp, nơi phần mềm cần được cài đặt, cập nhật và quản lý trên nhiều máy tính và địa điểm khác nhau. Một kiến trúc triển khai (deployment architecture) vững chắc không chỉ giúp tự động hóa quy trình mà còn đảm bảo tính nhất quán, an toàn và giảm thiểu chi phí vận hành. Nghiên cứu này đề xuất một giải pháp đột phá dựa trên nền tảng OSGi (Open Service Gateway initiative), một đặc tả mở cho phép triển khai và quản lý các dịch vụ phần mềm một cách linh hoạt. Mục tiêu chính của luận văn là xây dựng một kiến trúc cho phép triển khai phân tán, giải quyết các thách thức mà các công cụ hiện có chưa đáp ứng được, đặc biệt là trong việc quản lý vòng đời và các phụ thuộc phức tạp của thành phần phần mềm. Công trình này không chỉ dừng lại ở lý thuyết mà còn xây dựng một prototype để kiểm chứng tính khả thi của kiến trúc đề xuất, sử dụng các công nghệ như Oscar (một bản triển khai của OSGi) và XML-RPC cho giao tiếp mạng. Qua đó, luận văn cung cấp một cái nhìn toàn diện về một đề tài hệ thống phân tán (distributed systems) thực tiễn, từ việc phân tích vấn đề, đề xuất giải pháp, đến hiện thực hóa và kiểm chứng, tạo nền tảng vững chắc cho các nghiên cứu và ứng dụng trong tương lai.

1.1. Bối cảnh và tầm quan trọng của hệ thống phân tán hiện nay

Trong kỷ nguyên số, hệ thống phân tán (distributed systems) đã trở thành nền tảng cho hầu hết các ứng dụng hiện đại, từ dịch vụ điện toán đám mây (cloud computing) đến các ứng dụng doanh nghiệp quy mô lớn. Sự phức tạp của việc triển khai phần mềm trong các môi trường này là một thách thức lớn. Quá trình này không chỉ đơn thuần là sao chép tệp tin mà bao gồm một chuỗi các hoạt động phức tạp như cài đặt, kích hoạt, cập nhật, và gỡ bỏ trên nhiều nút mạng khác nhau. Một kiến trúc triển khai hiệu quả trở nên tối quan trọng để đảm bảo rằng các ứng dụng được triển khai một cách nhất quán, an toàn và có khả năng mở rộng (scalability). Việc tự động hóa và quản lý từ xa giúp giảm thiểu sai sót của con người và tiết kiệm chi phí vận hành đáng kể.

1.2. Phân tích mục tiêu nghiên cứu trong deployment architecture

Mục tiêu cốt lõi của luận văn thạc sĩ công nghệ thông tin này là thiết kế và hiện thực hóa một kiến trúc cho phép triển khai phần mềm phân tán một cách tự động và linh hoạt. Nghiên cứu tập trung vào việc giải quyết các vấn đề mà các công cụ hiện tại chưa xử lý triệt để, bao gồm: quản lý sự phụ thuộc phức tạp giữa các thành phần, đảm bảo tính nhất quán của hệ thống trong quá trình cập nhật, và cho phép cấu hình động. Kiến trúc đề xuất dựa trên nền tảng OSGi, sử dụng mô hình agent để quản lý việc triển khai trên các nút mạng khác nhau. Mục tiêu không chỉ là xây dựng một mô hình lý thuyết mà còn là xác thực nó thông qua một prototype hoạt động, chứng minh tính hiệu quả của giải pháp trong các kịch bản thực tế.

1.3. Cấu trúc tổng quan của một mô hình triển khai phân tán

Một mô hình triển khai (deployment models) phân tán điển hình bao gồm ba tác nhân chính: nhà sản xuất (producer), doanh nghiệp (enterprise), và người dùng cuối (user). Nhà sản xuất cung cấp ứng dụng. Doanh nghiệp chịu trách nhiệm tùy chỉnh và triển khai ứng dụng trên các trang của mình. Người dùng cuối là nơi ứng dụng được cài đặt và vận hành. Vòng đời triển khai bao gồm các giai đoạn chính: cấu hình và lựa chọn (configuration & selection), cài đặt (installation), kích hoạt (activation), tái cấu hình và cập nhật (reconfiguration & update), vô hiệu hóa (deactivation), và gỡ bỏ (uninstallation). Mỗi giai đoạn đều có những thách thức riêng, đặc biệt trong môi trường phân tán, đòi hỏi một kiến trúc quản lý chặt chẽ và tự động hóa cao.

II. Top 3 thách thức trong kiến trúc triển khai hệ thống phân tán

Việc xây dựng một kiến trúc triển khai hệ thống phân tán (deployment architecture for distributed systems) hiệu quả phải đối mặt với nhiều thách thức cố hữu. Thách thức lớn nhất là quản lý vòng đời phần mềm một cách toàn diện. Quá trình này không chỉ dừng lại ở việc cài đặt ban đầu mà còn bao gồm các hoạt động phức tạp như kích hoạt, cập nhật, tái cấu hình, và gỡ bỏ. Trong một hệ thống phân tán, mỗi hoạt động này phải được thực hiện đồng bộ trên nhiều máy, đòi hỏi sự phối hợp chính xác để tránh tình trạng không nhất quán. Một thách thức quan trọng khác là quản lý sự phụ thuộc (dependency management). Các thành phần phần mềm thường phụ thuộc lẫn nhau; một bản cập nhật của một thành phần có thể làm hỏng các thành phần khác. Việc xác minh tất cả các phụ thuộc trước khi triển khai, đặc biệt trong một môi trường không đồng nhất, là cực kỳ phức tạp. Cuối cùng, việc đảm bảo tính nhất quán dữ liệu và khả năng chịu lỗi (fault tolerance) là một bài toán khó. Khi các thành phần được phân tán trên nhiều nút mạng, việc thay đổi cấu hình hoặc cập nhật phải được thực hiện sao cho không làm mất dữ liệu và hệ thống vẫn có thể hoạt động ngay cả khi một vài nút gặp sự cố. Đây là những vấn đề mà định lý CAP (CAP theorem) đã chỉ ra sự đánh đổi giữa tính nhất quán, tính sẵn sàng và khả năng chịu phân mảnh, đòi hỏi các nhà thiết kế kiến trúc phải có những lựa chọn chiến lược thông minh.

2.1. Vấn đề quản lý vòng đời phức tạp của phần mềm phân tán

Quản lý vòng đời trong hệ thống phân tán là một công việc phức tạp hơn nhiều so với môi trường tập trung. Mỗi giai đoạn, từ cài đặt đến gỡ bỏ, đều phải được điều phối trên một mạng lưới các máy tính không đồng nhất. Ví dụ, khi cập nhật một ứng dụng, hệ thống phải đảm bảo rằng tất cả các nút liên quan đều nhận được phiên bản mới một cách đồng bộ. Nếu một nút không cập nhật thành công, hệ thống có thể rơi vào trạng thái không nhất quán, gây ra lỗi nghiêm trọng. Việc tự động hóa các quy trình này, đồng thời có cơ chế quay lui (rollback) khi xảy ra sự cố, là một yêu cầu bắt buộc đối với bất kỳ kiến trúc triển khai hiện đại nào.

2.2. Phân tích khó khăn trong việc quản lý sự phụ thuộc dependencies

Sự phụ thuộc giữa các thành phần là một trong những nguyên nhân chính gây ra lỗi khi triển khai phần mềm. Một ứng dụng phân tán được cấu thành từ nhiều thành phần, mỗi thành phần có thể yêu cầu các thư viện hoặc dịch vụ khác với phiên bản cụ thể. Luận văn này nhấn mạnh rằng việc kiểm tra các phụ thuộc trước khi thực hiện triển khai là cực kỳ quan trọng. Hệ thống đề xuất sử dụng các công cụ suy luận (reasoning engines) và chính sách (policy) để xác minh rằng môi trường đích đáp ứng đủ các yêu cầu của thành phần sắp được cài đặt. Điều này giúp phát hiện sớm các xung đột tiềm tàng, chẳng hạn như xung đột phiên bản hoặc thiếu tài nguyên, từ đó ngăn chặn các lỗi triển khai và đảm bảo hệ thống luôn ổn định.

2.3. Thách thức về tính nhất quán và khả năng mở rộng scalability

Đảm bảo tính nhất quán dữ liệu trên các nút khác nhau là một thách thức cốt lõi. Khi có nhiều biến thể của một thành phần và hệ thống cần chuyển đổi linh hoạt giữa chúng, việc duy trì trạng thái nhất quán là rất khó. Thêm vào đó, khả năng mở rộng là một yêu cầu thiết yếu. Một kiến trúc triển khai phải cho phép dễ dàng thêm hoặc bớt các nút mạng mà không làm gián đoạn hoạt động của toàn hệ thống. Điều này đòi hỏi các cơ chế như cân bằng tải (load balancing) và khám phá dịch vụ (service discovery) để tự động phân phối công việc và duy trì hiệu suất khi quy mô hệ thống thay đổi. Các mô hình triển khai hiện đại như on-premise deployment hay hybrid cloud càng làm tăng thêm độ phức tạp cho bài toán này.

III. Phương pháp Kiến trúc triển khai phân tán dựa trên nền tảng OSGi

Giải pháp trung tâm của luận văn là một kiến trúc triển khai (deployment architecture) sáng tạo cho hệ thống phân tán, được xây dựng dựa trên nền tảng OSGi. OSGi, với mô hình hướng dịch vụ và khả năng quản lý vòng đời linh hoạt của các đơn vị triển khai gọi là “bundle”, cung cấp một nền móng vững chắc. Kiến trúc được đề xuất bao gồm một tập hợp các nút (node) phân tán trên mạng. Mỗi nút chứa hai thành phần agent chính: một agent cục bộ (local agent) và một agent từ xa (distant agent). Agent cục bộ chịu trách nhiệm thực hiện các hoạt động triển khai tập trung trên chính nút đó, như cài đặt, cập nhật, hoặc gỡ bỏ các bundle. Nó tương tác trực tiếp với nền tảng OSGi để quản lý vòng đời của các thành phần. Trong khi đó, agent từ xa đóng vai trò giao tiếp giữa các nút. Nó nhận các lệnh triển khai từ các nút khác, được định nghĩa bằng một ngôn ngữ triển khai chuyên dụng, và sau đó kích hoạt agent cục bộ để thực thi. Mô hình hai agent này cho phép điều khiển việc triển khai trên toàn bộ hệ thống từ bất kỳ nút nào. Một điểm nổi bật của kiến trúc là module quản lý phụ thuộc, sử dụng các công cụ suy luận để kiểm tra các điều kiện và chính sách trước khi tiến hành triển khai, đảm bảo tính an toàn và thành công của quá trình.

3.1. Mô hình kiến trúc node với agent local và agent distant

Kiến trúc đề xuất một mô hình mạng ngang hàng gồm nhiều nút. Mỗi nút là một thực thể độc lập có khả năng tự quản lý việc triển khai cục bộ thông qua agent local. Agent này xử lý các tác vụ như install, update, start, stop trên các bundle OSGi. Agent distant là cổng giao tiếp với thế giới bên ngoài. Nó lắng nghe các lệnh từ các nút khác, phân tích chúng và ủy quyền cho agent local. Ví dụ, một quản trị viên tại Nút A có thể gửi lệnh deploy install bundleX on NodeB. Agent distant tại Nút B sẽ nhận lệnh này, xác thực và yêu cầu agent local của mình tải và cài đặt bundleX từ một kho lưu trữ từ xa. Cơ chế này tạo ra một hệ thống quản lý phân tán thực sự.

3.2. Vai trò của OSGi trong việc quản lý vòng đời các bundle

Nền tảng OSGi là trái tim của kiến trúc trên mỗi nút. OSGi định nghĩa một vòng đời chặt chẽ cho các bundle (đơn vị triển khai) với các trạng thái như INSTALLED, RESOLVED, ACTIVE, UNINSTALLED. Agent cục bộ tận dụng các API của OSGi để điều khiển vòng đời này. Khi một bundle được cài đặt, OSGi sẽ tự động kiểm tra và giải quyết các phụ thuộc về package. Kiến trúc này mở rộng khả năng của OSGi bằng cách bổ sung một lớp quản lý phụ thuộc cấp cao hơn và cho phép điều khiển vòng đời này từ xa thông qua mạng lưới các agent, biến một cơ chế triển khai tập trung thành một hệ thống phân tán mạnh mẽ.

3.3. Cách module quản lý phụ thuộc dependency hoạt động

Trước khi agent cục bộ thực hiện bất kỳ hành động triển khai nào, yêu cầu sẽ được chuyển đến module quản lý phụ thuộc. Module này, dựa trên các công cụ suy luận và chính sách được định nghĩa trước, sẽ kiểm tra bối cảnh hiện tại của hệ thống. Nó xác minh các yếu tố như: liệu hệ thống có cung cấp đủ tài nguyên và dịch vụ mà bundle yêu cầu hay không, liệu bundle sắp cài đặt có xung đột với các dịch vụ hiện có hay không. Chỉ khi tất cả các phụ thuộc và điều kiện được thỏa mãn, module mới cho phép quá trình triển khai tiếp tục. Cách tiếp cận này giúp ngăn chặn lỗi trước khi chúng xảy ra, tăng cường đáng kể độ tin cậy và khả năng chịu lỗi của hệ thống.

IV. Bí quyết Hiện thực hóa kiến trúc với XML RPC Oscar và OBR

Việc hiện thực hóa kiến trúc triển khai hệ thống phân tán được thực hiện thông qua một prototype, kết hợp các công nghệ mã nguồn mở mạnh mẽ. Nền tảng chính được lựa chọn là Oscar, một bản triển khai của đặc tả OSGi, cung cấp môi trường cốt lõi để quản lý các bundle trên từng nút. Để cho phép giao tiếp giữa các agent từ xa trên các nút khác nhau, luận văn đã sử dụng giao thức XML-RPC. Đây là một giao thức gọi thủ tục từ xa (RPC) gọn nhẹ, sử dụng XML để mã hóa dữ liệu và HTTP để truyền tải, rất phù hợp cho các hệ thống phân tán không đồng nhất. Thành phần giao tiếp trong mỗi agent được xây dựng dưới dạng một bundle OSGi, bao gồm cả client và server XML-RPC, cho phép nó vừa gửi lệnh đi vừa nhận lệnh đến. Trọng tâm của việc triển khai là một bundle quản lý chính có tên “Deployment Manager”. Bundle này tích hợp các thành phần con: thành phần giao tiếp (dựa trên XML-RPC), thành phần quản trị (quản lý danh sách các nút và kho lưu trữ), và thành phần triển khai. Thành phần triển khai là một phiên bản sửa đổi của OBR (Oscar Bundle Repository), một công cụ giúp tự động tìm và cài đặt các bundle cùng với các phụ thuộc của chúng. Sự cải tiến chính là tích hợp nó với module quản lý phụ thuộc dựa trên logic suy luận, tạo ra một quy trình triển khai thông minh và an toàn hơn.

4.1. Xây dựng ngôn ngữ triển khai deployment language chuyên dụng

Để tương tác với hệ thống, một ngôn ngữ triển khai dựa trên dòng lệnh đơn giản đã được định nghĩa. Ngôn ngữ này cho phép quản trị viên thực hiện các hành động trên các nút từ xa một cách tường minh. Các lệnh có cấu trúc như deploy <action> <options> <host> <bundle-name>. Ví dụ, deploy install -node node_B SimpleBundle sẽ cài đặt bundle 'SimpleBundle' trên nút có định danh 'node_B'. Ngôn ngữ này hỗ trợ các hành động chính trong vòng đời phần mềm như install, update, uninstall, start, stop, cũng như các lệnh quản lý kho lưu trữ và các nút mạng. Điều này tạo ra một giao diện mạnh mẽ để tự động hóa các kịch bản triển khai phức tạp.

4.2. Ứng dụng XML RPC và Oscar để hiện thực hóa giao tiếp

Sự kết hợp giữa Oscar và XML-RPC là chìa khóa của prototype. Oscar cung cấp một môi trường OSGi ổn định trên mỗi nút. Bundle “Deployment Manager” chạy trên nền Oscar này. Khi một lệnh triển khai từ xa được đưa ra, thành phần client XML-RPC trong bundle sẽ đóng gói lệnh thành một thông điệp XML và gửi nó qua HTTP đến nút đích. Tại nút đích, thành phần server XML-RPC sẽ nhận yêu cầu, giải mã nó và gọi phương thức tương ứng trong agent cục bộ. Việc sử dụng các công nghệ tiêu chuẩn và mã nguồn mở không chỉ giúp đẩy nhanh quá trình phát triển mà còn đảm bảo khả năng mở rộng và tương thích của hệ thống.

4.3. Thiết kế giao diện tương tác và thành phần quản trị

Để dễ dàng quản lý và tương tác, prototype được trang bị hai loại giao diện. Giao diện đầu tiên là dạng console (shell), kế thừa từ Shell Service tiêu chuẩn của OSGi, cho phép quản trị viên gõ lệnh trực tiếp. Giao diện thứ hai là giao diện đồ họa (GUI) được xây dựng bằng Swing, cung cấp một cách trực quan để quản lý các nút trong mạng, duyệt các kho lưu trữ bundle, và thực hiện các hoạt động triển khai. Thành phần quản trị cho phép người dùng thêm/xóa các nút khỏi mạng lưới và quản lý danh sách các kho lưu trữ bundle từ xa, tạo nên một công cụ quản lý hệ thống phân tán toàn diện.

V. Kết luận và hướng phát triển cho đề tài hệ thống phân tán

Công trình luận văn thạc sĩ công nghệ thông tin này đã thành công trong việc thiết kế, hiện thực hóa và xác thực một kiến trúc triển khai cho các hệ thống phân tán (architecture de déploiement des systèmes répartis). Đóng góp chính của luận văn là một mô hình kiến trúc mới dựa trên nền tảng OSGi, sử dụng cơ chế agent kép (local và distant) để quản lý vòng đời phần mềm trên một mạng lưới các nút không đồng nhất. Bằng cách tích hợp một module quản lý phụ thuộc thông minh, kiến trúc này đã giải quyết được những thách thức cốt lõi về tính nhất quán và độ tin cậy trong quá trình triển khai. Việc xây dựng thành công prototype trên Oscar và XML-RPC đã chứng minh tính khả thi và hiệu quả của giải pháp. Tuy nhiên, lĩnh vực hệ thống phân tán luôn không ngừng phát triển. Hướng phát triển trong tương lai cho đề tài này rất rộng mở. Một cải tiến quan trọng là tích hợp các cơ chế bảo mật mạnh mẽ hơn, như Permission Admin và User Admin, để kiểm soát quyền truy cập khi triển khai. Hơn nữa, việc so sánh và tích hợp với các công nghệ điều phối container hiện đại như Kubernetes và Docker sẽ mang lại giá trị to lớn, giúp kiến trúc trở nên phù hợp hơn với xu hướng kiến trúc microservices (microservices architecture) và môi trường điện toán đám mây (cloud computing) ngày nay.

5.1. Tổng kết những đóng góp chính của luận văn thạc sĩ

Đóng góp quan trọng nhất của luận văn là một kiến trúc hoàn chỉnh cho phép triển khai và quản lý phần mềm trong môi trường phân tán, một vấn đề phức tạp tại thời điểm nghiên cứu. Kiến trúc này đã thành công trong việc: (1) Tự động hóa toàn bộ vòng đời triển khai từ cài đặt đến gỡ bỏ. (2) Cho phép quản lý từ xa các thành phần trên nhiều nút mạng. (3) Đảm bảo tính toàn vẹn của hệ thống thông qua một module kiểm tra phụ thuộc tiên tiến. Việc định nghĩa một ngôn ngữ triển khai chuyên dụng và xây dựng prototype hoạt động là minh chứng rõ ràng cho tính thực tiễn của đề tài, vượt ra khỏi khuôn khổ lý thuyết.

5.2. So sánh với kiến trúc hiện đại như Kubernetes và Docker

Mặc dù được nghiên cứu từ năm 2007, các nguyên tắc của luận văn vẫn còn nguyên giá trị. Tuy nhiên, hệ sinh thái công nghệ đã thay đổi. Ngày nay, Docker cung cấp cơ chế đóng gói ứng dụng và phụ thuộc vào các container, trong khi Kubernetes là nền tảng điều phối các container đó trên quy mô lớn. Các công cụ này đã giải quyết nhiều vấn đề mà luận văn đề cập, nhưng theo một cách tiếp cận khác. Hướng phát triển tiềm năng là áp dụng các ý tưởng về quản lý phụ thuộc logic từ luận văn này vào môi trường Kubernetes, ví dụ như tạo ra các admission controller thông minh hơn để xác thực các chính sách triển khai phức tạp trước khi một pod được tạo, kết hợp sự linh hoạt của OSGi với sức mạnh của container.

5.3. Tiềm năng phát triển trong môi trường điện toán đám mây

Kiến trúc được đề xuất có tiềm năng lớn khi áp dụng vào môi trường điện toán đám mây và hybrid cloud. Các khái niệm như agent trên mỗi nút có thể được ánh xạ tới các agent chạy trên máy ảo (VM) hoặc trong container. Giao thức khám phá dịch vụ tự động (service discovery) có thể được phát triển để các nút tự tìm thấy nhau thay vì phải cấu hình thủ công. Hơn nữa, các khái niệm về khả năng chịu lỗi và cân bằng tải có thể được tích hợp sâu hơn, cho phép hệ thống tự động thay đổi cấu hình các thành phần đang hoạt động để tối ưu hóa hiệu suất và duy trì tính sẵn sàng, phù hợp với bản chất linh hoạt và động của các nền tảng đám mây hiện đại.

Trích đoạn nội dung tài liệu

=<sens† Bretagne Institut de la Francophonie Ecole Nationale Supérieure pour |'Informatique des Télécommunications de Bretagne MEMOIRE DE FIN D’ETUDES MASTER D’ INFORMATIQUE Architecture de déploiement des systémes répartis NGUYEN VAN Hien Responsable de stage : Fabien DAGNAT Ce stage a été réalisé au sein de l’équipe CAMA du Département informatique de l’Ecole Nationale Supérieure des Télécommunications de Bretagne - France GET - ENST Bretagne Hanoi, 12 octobre 2007 Remerciements Tout d’abord, je tiens & remercier ma famille qui m’a soutenu dans mes études et aussi dans mon stage. Je tiens & remercier VInstitut de la Francophonie pour PInformatique qui me permet d’effectuer mon Master et qui me permet de faire le stage en France. Je tiens 4 remercier Monsieur Fabien Dagnat pour m’avoir dirigé dans mes travaux tout au long de mon stage. Je le remercie de son contact chaleureux, de ses conseils et encouragements.

Je remercie Meriem Belguidoum de son support et de sa coopération dans mon stage. Je remercie tous les membres du département Informatique de VENST Bretagne qui mont accepté parmi eux pendant la durée du stage. Je remercie mes amis : An Pk, Dung NT et tout ce gui m’ont donné les meilleurs sentiments et les meilleurs supports toute la durée de mes études et de mon stage. Merci enfin 4 mes camarades : Cuong TK, Tram TH, Tuan TA et Uyen BK, qui m’ont donné des bons repas A VENST Bretagne.

Résumé Le déplociement des logiciels devient de plus en plus complexe. La plupart des outils de déploiement existants utilisent des techniques qui ne sont pas A la mesure de la complexité des problémes rencontrés. Le déploiement se coustitue certaines activités du cycle de vie des logiciels : installation, Vactivation, la désactivation, la mise 4 jour et la désinstallation. Pour les applications distribuées, nous proposons une architecture pour le déploiement réparti.

Elle se base sur un ensemble de nosuds, chaque noeud contient deux agents : un agent local qui prend en charge le déploiement centralisé, effectué sur des composants locaux; un agent distant est utilisé pour la transmission les commandes de déploiement, qui sont définies par un langage de déploiement, entre les nceuds. Lors de la réception d’une commande, l’agent distant active l’agent local pour le déploiement des composants qui sont récupérés d’un dépdt distant. Les dépendances d’un composant sont vérifiées par le systéme de gestion des dépendances qui se base sur les moteurs de raisonnement et de politique. Le déploiement est effectué aprés que les erreurs potentielles alent été détectées.

Notre architecture repose sur POSGi, une plate-forme de déploiement de services. La plate-forme OSGi prend en charge la manipulation des unités de base appellées “bundles” en fournant des services de déploiement et d’exécution. Elle offre aux applications un mécanisme de registrer et de rechercher des services en utilisant un registre de services. Elle permet également aux bundles de partager leurs codes, ainsi que leurs ressources.

Le déploiement de OSGi est réalisé par le service de cycle de vie couvrant les opérations de déploiement des bundles. Un prototype est construit permettant de valider Varchitecture réalisée en se basant sur Oscar, une implémentation de la spécification OSGi. Mots-clés : Systéme distribué, déploiement réparti, reconfiguration dynamique, OSGi, modéle de services. il Abstract The software deployment becomes more complex.

The majority of the existing deploy- ment tools use techniques which can not measure with the complexity of the encountered problems. ‘The deployment is constituted by certain activities of the software life cycle : the installation, the activation, the desactivation, the update and the uninstallation. For distributed applications, we propose an architecture for the distributed deployment. Our architecture is based on a whole of nodes, each node contains two agents : a local agent which deals with the centralized deployment, carried out on local components; a distant agent is used for sending and receiving deployment commands, which are defined by a lan- guage of deployment, between the nodes.

At the time of the reception of a command, the distant agent activates the local agent for depoying the components which are retrieved from a distant repository. The dependences of a component are checked by the depen- dency management system based on the engines of reasoning and policy. The deployment is started after the potential errors were detected. Our architecture is based on OSGi, a platform of service deployment.

The OSGi plat- form deals with handling of the basic units called “bundle” by providing deployment and execution services. OSGi offers to applications a mechanism to register and to seek ser- vices by using a service register. It also allows bundles to share their codes, and their ressources. The deployment of OSGi is carried out by the life cycle service covering the operations of deployment of bundles.

A prototype based on Oscar, an OSGi implementation, is built to validate the archi- tecture constructed. Keywords : Distributed system, distributed deployment, dynamic reconfiguration, OSGi, model of services. ill Table des matiéres Introduction i Le déploiement 1 MoOEIVAĐORH L2 cv cv v1 gà Ta 1.2 Les acteurs du déploiement.3 Etapes de déploiement. 2 ee 2 Etat de Part mm 2.1 Dépiciement des systémes d’exploitation .2 Les modéles de composants .2 Corba Component Model- CCM.

Les modéles de service .1 Open Service Gateway initiative - OSGi 2.4 Les outils @installation.5 Les modéles de déploiement. ee ee OSGi - Plate-forme de déploiement de services 3.2 Architecture multi-couche .5 Programmation de services OSGi. IV TABLE DES MATIERES Vv 3.6 Plate-formes OSGi 20.2 OBR - Service de déploiement automatique de VOSGi. 22 4 L’architecture de déploiement réparti 24 4.1 Déploiement de composants @OSGi.

ee ee 25 Ai.4 Module de gestion des đếpendanC©@S. ch ra 30 " ? `“ “6 aa4a an agag. (l(lgaãgaI: Ha od 4.6 Langage de déploiement .2 Implémentation avec XML-RPC et Oscar.1 Le composant de communication Lo cv vu và va 33 4.2 Le composant d’admimistration. 2 ee ee ee 33 4.3 Le composant de déplolement .4 L’interface interactive graphique.

vo 34 Conclusion et perspectives Table des figures 1.1 Les acteurs du déploiement.2 Cycle de vie du déploiement .1 Architecture initiale OSGi 20. ai ki va 15 3.3 Architecture multi-couche cv cu kg Tà xa 16 3.4 Cycle de vie dun bundÌe. cà gà kg TT va 16 3.0 Contenu dun bundÌe. cv và k Nà TY Ta 7 3.6 Hxemple d’un manifeste 2.7 Registre de services 2.

0 cu 2 gà NV Nà 19 3.8 L’activateur et Vinterface BundleContext d’un bundle.9 Comparation des implémentations OSGi. ee ee ee 21 41 Architecture de đêếplolement rÊDAFĐE. c c c c c Q gà gà sa 25 4.2 La négociation de déploiement. Quà kg ko 26 4.4 Le service de commandes.5 Le service de déploiement 2.6 Le service de gestion de dépdts 2.7 Leservice de gestion de nosuds 2.

ee 28 48 L’agent distant 2.9 Le service de communication.10 Le serveur de communication 2.11 Le chent de communication 2. ee 30 Vì Introduction Ce stage s’agit d’implanter et valider une architecture au sein de l’équipe CAMA! du département informatique de VENST Bretagne a Plouzané, dans le cadre du projet SAUNA? qui vise A gérer un déploiement réparti de logiciels. Le but de ce stage est d’étudier le déploiement dans les modéles de composants, de ser- vices, des systémes d’exploitation et des outils d’administration; d’étudier les spécificités du déploiement réparti, de concevoir une architecture permettant un déploiement réparti, de mettre au point un prototype et de vérifier Varchitecture sur la base de scénarios de déploiement. Notre architecture se base sur ?OSGi?, une plate-forme de déploiement des services qui permet de réaliser le déploiement centralisé en offrant les services de base.

Dans ce rapport, nous présentons d’abord dans la premiére section la motivation, les auteurs et les activités du déploiement. La section 2 présente les travaux précédants sur le déploiement : les modeéles, les outils, les langages de définition et le déploiement réparti. La section 3 détaille la plate-ftorme OSGi sur laquelle notre systéme, qui est décrit dans la section 4, se base. Le rapport est terminé par les conclusions et perspectives.

'Composants pour Architectures Mobiles Adaptables *Safe AUtonomic Network Administration “Open Service Gateway initiative Chapitre 1 Le déploiement CHAPITRE 1. LE DEPLOIEMENT 3 Producteur Entreprise † Utilisateur Fic.1 — Les acteurs du déploiement 1.1 Motivation Le déploiement de logiciel est toutes les activités qui rendent un systéme logiciel dis- ponible pour usage. De nos jours, le déploiement devient important pour les applications dans les entreprises ot le parc informatique contient plusieurs ordinateurs et équipements sur des sites différents. Chaque site se compose d’un serveur auquel certaines machines sont reliées.

Pour la gestion de l’environnement logiciel, le serveur se charge de fournir un ensemble d’applications qui peuvent étre installées sur les sites. Il est interdit 4 un utilisateur d’ins- taller et de modifier une application en se connectant directement sur le site du producteur ou en utilisant un CD d’installation fourni par le producteur. Cela permet 4 |’entreprise d’assurer que les applications qui sont déployées, sont cohérentes et que leur déploiement est sécurisé. Il existe plusieurs versions d’une application et une application peut étre déployée sous certains environnements tel que Linux ou Windows.

L’administrateur du systéme informatique de l’entreprise a besoin d’une maniére de savoir les différences entre les ap- plications et entre les sites. En outre, la plannification permet a l’entreprise de diminuer le cofit en réalisant les déploiements de fagcon automatisée et 4 distance.2 Les acteurs du déploiement Le déploiement 4 large échelle est fait en basant sur un schéma contenant 3 acteurs : producteur, entreprise et utilisateur (Figure 1. e Le producteur fournit les applications 4 déployer sur les entreprises ou les utilisa- teurs. e L’entreprise prend en charge le déploiement sur les sites, elle peut aussi modifier Vapplication avant la déployer.

e L’utilisateur représente le site sur lequel l’application est déployée. Une fois l’appli- cation installée, ’application peut évoluer, étre modifiée ou étre désinstallée. LE DEPLOIEMENT 4 Configuration & Sélection Installation Désinstallation Reconfiguration & Mise a jour Activation 4 -_ Désactivaftion Fic.2 — Cycle de vie du déploiement 1. Etapes de déploiement Le déploiement est constitué par les activités dans le cycle de vie d’apllication, de- puis la validation du producteur jusqu’a l’installation et la désinstallation sur le site des utilisateurs.2 décrit le cycle de vie du déploiement.

Configuration & Sélection La premiére étape dans le cycle de vie d’une application est la mise a disposition des utilisateurs. Pour cela, il faut d’abord configurer l’application, c. choisir les fonctionnalités et les contraintes. A partir de cette configuration, les paquets de application sont sélectés et emballés.

L’application devient préte a étre installée. Installation L’installation a pour but d’installer l’application emballée sur le site des utilisateurs. Cette étape contient 3 sous-activités : e Le transfert, il existe 2 modes de transfert : “push”, si le producteur initialise le transfert, et “pull”, si ’utilisateur demande |’installation. e La configuration lors de l’installation consiste 4 compléter la configuration en précisant les derniéres possibilités offertes avant l’installation.

L’utilisateur peut sélectionner les fonctionnalités proposées par l’application, c. e L’installation physique : Les paquets (fichiers) sélectionnés sont installés sur la machine. L’application maintenant est préte 4 étre résolue les dépendances, par Vactivité d’activation. Activation Cette activité consiste 4 préparer |’environnement d’exécution de l’application ins- tallée.

A la fin de Vactivité, application est préte A étre exécutée. LE DEPLOIEMENT or Reconfiguration é& Mise a jour L’activité de mise 4 jour et de reconfiguration consiste 4 modifier une application déja installée. Elle est réalisée 4 V’initiative de Vutilisateur ou du producteur. Dans la plupart cas, elle appelle Vactivité de désactivation pour que les paquets de l’ap- plication puissent étre transferts et puis étre installés.

Ein fin, Vactivité d’activation est appellée afin d’activer application. Désactivation or Cette activité est utilisée avant l’activation, la reconfiguration et la désinstallation. non réle est de désactiver les composants de lVapplication, afin que Ứon puisse la modifier ou la supprimer. Désinstallation L’activité de désinstallation est la derniére activité du cycle de vie du déploiement logiciel.