Các thành phần khác

Một phần của tài liệu Mô hình tính toán lưới và ứng dụng giải một số bài toán trên đồ thị (Trang 36)

CHƢƠNG 1 GIỚI THIỆU VỀ CƠNG NGHỆ TÍNH TỐN LƢỚI

2.1.7 Các thành phần khác

Cịn cĩ nhiều thành phần khác để đưa vào mơi trường lưới và cần được xem xét khi thiết kế và cài đặt ứng dụng. Ví dụ: Các tiện ích như liên lạc giữa các tiến trình (Inter Process Communication) và các dịch vụ hỗ trợ tính tốn chi phí và chi trả là những tiện ích được yêu cầu nhiều nhất.

Trên đây là giới thiệu vắn tắt và tổng quan về các thành phần chính của mơi trường lưới. Tuỳ thuộc vào việc triển khai lưới và các yêu cầu của ứng dụng, cĩ nhiều

25

cách khác nhau để kết hợp các thành phần này lại với nhau để tạo nên một giải pháp lưới.

2.2 Kiến trúc của một lƣới

2.2.1 Bản chất kiến trúc

“Tổ chức ảo” (VO) là đơn vị cơ bản quan trọng trong hệ thống lưới. Việc thiết lập, quản lý, khai thác các quan hệ chia sẻ tài nguyên giữa các tổ chức ảo địi hỏi phải cĩ kiến trúc hệ thống mới, kiến trúc lưới. Kiến trúc lưới dưới đây được xây dựng dựa trên quan niệm “để các VO hoạt động hiệu quả địi hỏi phải thiết lập được các quan hệ chia sẻ với bất kỳ đơn vị tham gia tiềm năng nào”. Để làm được điều này, vấn đề “liên kết hoạt động” (interoperability) cần phải được tập trung giải quyết. Trong mơi trường mạng, “liên kết hoạt động” đồng nghĩa với việc sử dụng các giao thức chung. Do đĩ, kiến trúc lưới sẽ là kiến trúc giao thức, với các giao thức xác định các cơ chế nền tảng để người dùng và nhà cung cấp tài nguyên thương lượng, thiết lập, quản lý và khai thác các mối quan hệ chia sẻ tài nguyên.

Kiến trúc lưới phải là kiến trúc dựa chuẩn, hướng mở, để dễ mở rộng, liên kết hoạt động tốt, cĩ tính khả chuyển (portability) cao. Các giao thức chuẩn sẽ giúp định nghĩa các service chuẩn, nhờ đĩ cĩ thể xây dựng các service cao cấp hơn một cách dễ dàng. Sau khi cĩ được kiến trúc lưới, việc tiếp theo là xây dựng các hàm API và các bộ SDK để cung cấp các cơng cụ cần thiết để phát triển các ứng dụng chạy trên nền lưới.

Sở dĩ vấn đề “liên kết hoạt động” được xem là vấn đề cơ bản vì các mối quan hệ chia sẻ cĩ thể phải được thiết lập giữa các bên tham gia khác nhau về các chính sách, giữa các mơi trường khác nhau về nền tảng, ngơn ngữ, mơi trường lập trình,…Nếu khơng cĩ nĩ, các thành viên trong VO sẽ thực hiện các chính sách chia sẻ song phương và khơng chắc rằng các cơ chế sử dụng cho hai thành viên này sẽ mở rộng được cho các thành viên khác. Điều này khiến cho việc thành lập các VO động là khơng thể thực hiện hoặc cũng chỉ thành lập được VO theo một kiểu nào đĩ mà thơi. Cũng giống như

26

Web đã làm bùng nổ việc chia sẻ thơng tin bằng cách cung cấp các giao thức và cú pháp chuẩn (HTTP và HTML) dùng cho việc trao đổi thơng tin, ở đây cũng cần các giao thức và cú pháp chuẩn để chia sẻ tài nguyên.

Để giải quyết vấn đề “liên kết hoạt động”, việc xây dựng các giao thức là quan trọng. Vì giao thức xác định cách các thành phần phân tán trao đổi với nhau để đạt được một mục đích nào đĩ, xác định các cấu trúc thơng tin cần thiết trong quá trình trao đổi. Các VO thường hay thay đổi, nên các cơ chế xác định, chia sẻ và sử dụng tài nguyên cần phải mềm dẻo, gọn nhẹ, để các thỏa thuận chia sẻ tài nguyên cĩ thể được thiết lập, thay đổi một cách nhanh chĩng. Các cơ chế chia sẻ khơng được ảnh hưởng đến các chính sách cục bộ, và phải cho phép các thành viên quản lý được các tài nguyên của họ. Vì các giao thức quy định việc giao tiếp giữa các thành viên chứ khơng quy định thành viên đĩ phải như thế nào, nên khi dùng các giao thức, các chính sách cục bộ được giữ lại. Do đĩ các giao thức được cần đến.

Khi đã cĩ các giao thức, thì việc xây dựng các service là cần thiết và quan trọng, các service là bản cài đặt cụ thể của các giao thức. Việc xây dựng các service cơ bản phục vụ truy cập đến tài nguyên tính tốn, dữ liệu, tìm kiếm tài nguyên, lập lịch và đồng bộ hố, sao chép dữ liệu,… cho phép xây dựng các service cao cấp hơn cho ứng dụng đồng thời trừu tượng hố các chi tiết về tài nguyên.

Cũng cần phải xây dựng các bộ API và SDK, vì các nhà phát triển ứng dụng cần phải cĩ cơng cụ để hỗ trợ phát triển các ứng dụng phức tạp trong mơi trường lưới, người dùng cũng phải cĩ khả năng thực thi được các ứng dụng này. Sức mạnh, tính đúng đắn của ứng dụng, chi phí phát triển và bảo trì là những mối quan tâm quan trọng. Các API và SDK cĩ thể giúp tăng tốc việc phát triển mã, cho phép chia sẻ mã, tăng tính khả chuyển cho ứng dụng. Tất nhiên, API và SDK chỉ hỗ trợ thêm chứ khơng thể thay thế các giao thức được.

27

2.2.2 Kiến trúc lưới tổng quát

Lưới được xây dựng trên nền tảng kiến trúc mở và phân tầng. Trong mỗi tầng của lưới, các thành phần chia sẻ những thuộc tính chung và được bổ sung những tính năng mới mà khơng làm ảnh hưởng đến các tầng khác [7]. Ta cĩ thể tổng hợp kiến trúc lưới thành 5 tầng như sau:

Hình 2.1 Kiến trúc lưới tổng quát 2.2.2.1 Tầng nền - tầng thiết bị (Fabric)

Đây là tầng thấp nhất của kiến trúc, đại diện cho các thiết bị vật lý và tồn bộ tài nguyên của lưới mà các tổ chức, người dùng muốn chia sẻ, sử dụng. Các tài nguyên cĩ thể tồn tại dưới dạng vật lý như các máy tính, hệ thống lưu trữ, các danh mục, tài nguyên mạng, các loại sensor, cũng cĩ thể là các thực thể logic - một thực thể trừu

28

tượng - đại diện cho một tập các tài nguyên vật lý, như hệ thống file phân tán, các cluster,… Trong trường hợp các thực thể logic, việc triển khai cĩ thể liên quan đến các giao thức cục bộ (ví dụ các giao thức phục vụ dạng truy cập NFS, hoặc giao thức quản lý tài nguyên, tiến trình trong cluster,…) nhưng các giao thức này khơng liên quan đến kiến trúc lưới.

Các thành phần của tầng Fabric thực hiện các hoạt động cục bộ trên các tài nguyên cụ thể (vật lý lẫn logic) như là bước tiếp sau của các hoạt động chia sẻ tài nguyên của các tầng trên. Do đĩ, cĩ một mối liên hệ phụ thuộc chặt chẽ giữa các chức năng của tầng Fabric với các hoạt động chia sẻ được hỗ trợ. Các chức năng của tầng Fabric càng mạnh, càng nhiều sẽ cho phép các hoạt động chia sẻ phức tạp, phong phú hơn. Kinh nghiệm cho thấy, việc quản lý tài nguyên ở tầng này ít nhất cũng phải cĩ cơ chế cung cấp thơng tin để xác được cấu trúc, trạng thái, năng lực của tài nguyên và cơ chế điều khiển chất lượng dịch vụ.

2.2.2.2 Tầng kết nối (Connectivity)

Tầng Connectivity định nghĩa các giao thức liên lạc và chứng thực cơ bản cần thiết cho các giao dịch mạng đặc trưng của lưới. Các giao thức liên lạc cho phép trao đổi dữ liệu giữa các tài nguyên tầng Fabric. Các giao thức chứng thực xây dựng trên các dịch vụ liên lạc nhằm cung cấp các cơ chế mã hĩa, bảo mật, xác minh và nhận dạng các người dùng và tài nguyên. Việc liên lạc địi hỏi các cơng việc như vận chuyển, định tuyến, đặt tên. Trong tương lai, việc liên lạc của lưới cĩ thể cần các giao thức mới, nhưng hiện nay nên xây dựng trên các giao thức cĩ sẵn của bộ TCP/IP giao thức stack, cụ thể là các tầng Network (IP và ICMP), Transport (TCP,UDP) và Application (DNS,OSPF,…).

Về khía cạnh bảo mật của tầng Connectivity, các giải pháp phải dựa trên các chuẩn bảo mật hiện hành khi cĩ thể. Cũng giống như liên lạc, rất nhiều chuẩn bảo mật đã được phát triển với bộ Internet giao thức cĩ thể áp dụng được.

29

Việc chứng thực, phân quyền trong mơi trường lưới là rất phức tạp. Các cơng nghệ bảo mật truyền thống chủ yếu tập trung bảo vệ các giao dịch giữa các máy client và server. Trong lưới, việc phân biệt client/server khơng tồn tại, vì các mỗi tài nguyên trong một lúc nào đĩ cĩ thể là server (khi nĩ nhận yêu cầu), một lúc khác lại là client (khi nĩ đề xuất yêu cầu đến các tài nguyên khác). Do đĩ, các giải pháp chứng thực cho các mơi trường VO nên đạt được các yêu cầu về bảo mật trong lưới như đã giới thiệu ở trên.

2.2.2.3 Tầng tài nguyên (Resource)

Tầng Resource dựa trên các giao thức liên lạc và chứng thực của tầng Connectivity để xây dựng các giao thức, API và SDK nhằm hỗ trợ việc thương lượng, khởi tạo, theo dõi, điều khiển, tính tốn chi phí và chi trả cho các hoạt động chia sẻ trên từng tài nguyên riêng lẻ một cách an tồn. Bản cài đặt các giao thức của tầng Resource sẽ gọi các chức năng của tầng Fabric để truy cập và điều khiển các tài nguyên cục bộ.

Các giao thức tầng Resource tập trung tồn bộ vào các tài nguyên riêng lẻ, khơng quan tâm đến trạng thái tồn cục và các hoạt động trong các tập tài nguyên phân tán.

Các giao thức tầng Resource được phân thành 2 dạng chính như sau:

 Các giao thức thơng tin: Sử dụng để thu thập thơng tin về cấu trúc và trạng

thái các tài ngun ví dụ như cấu hình hiện tại, tải hiện tại, chính sách sử dụng,…

Các giao thức quản lý: Sử dụng để thượng lượng truy xuất đến một tài

nguyên chia sẻ, xác định rõ, ví dụ, các yêu cầu về tài nguyên (bao gồm luơn việc giữ chỗ tài nguyên và chất lượng dịch vụ) và các thao tác cần được thực hiện như tạo tiến trình, hoặc truy xuất dữ liệu. Do các giao thức quản lý chịu trách nhiệm đại diện cho các quan hệ chia sẻ, đảm bảo các hoạt động sử dụng tài nguyên phải phù hợp với các chính sách chia sẻ tài nguyên, bao gồm luơn việc tính tốn và chi trả chi phí.

Mỗi giao thức cũng cần hỗ trợ việc theo dõi trạng thái và điều khiển các hoạt động.

30

Với những yêu cầu như vậy, tập các giao thức tầng Resource (và Connectivity) nên nhỏ gọn và tập trung. Các giao thức này chỉ nên đáp ứng được các cơ chế chia sẻ với nhiều loại tài nguyên khác nhau (ví dụ, các hệ thống quản lý tài nguyên cục bộ khác nhau) là đủ.

Các chức năng chính của tầng Resource cũng giống như của tầng Fabric cộng thêm nhiều ngữ nghĩa mới với cơ chế báo lỗi tin cậy khi hoạt động khơng thành cơng.

2.2.2.4 Tầng kết hợp (Collective)

Trong khi tầng Resource tập trung vào các tài nguyên đơn lẻ, tầng Collective chứa các giao thức, service, API, SDK khơng liên hệ đến bất kỳ một tài nguyên cụ thể nào mà thực hiện quản lý tồn cục, tập trung vào các giao tác giữa các tập tài nguyên.

Tầng Collective cĩ thể bổ sung thêm nhiều loại hoạt động chia sẻ mới ngồi những gì đã cĩ từ tầng Resource mà khơng cần bổ sung thêm các yêu cầu mới cho các tài nguyên đang được chia sẻ. Ví dụ:

Directory service (Dịch vụ thư mục): Cho phép các thành phần tham gia VO phát hiện sự tồn tại và/hoặc đặc tính của các tài nguyên trong VO. Một directory service cĩ thể cho phép người truy vấn tài nguyên qua tên và/hay các thuộc tính như kiểu, khả năng, tải, …

Co-allocation, scheduling, và broker service: Cho phép các thành phần tham gia VO yêu cầu cấp phát các tài nguyên cho các mục đích cụ thể và lập lịch cho các tác vụ trên các tài nguyên tương ứng.

Monitoring ang dianostics sevice: Hỗ trợ việc kiểm sốt các tài nguyên của VO, kiểm tra xem cĩ bị lỗi, bị tấn cơng, bị quá tải,… hay khơng.

Data replication service: Hỗ trợ quản lý tài nguyên lưu trữ của VO để tối ưu hiệu suất truy cập dữ liệu theo các độ đo như thời gian đáp ứng, tính tồn vẹn, tin cậy, chi phí,… .

31

Grid-enable programming system: Cho phép các sử dụng các mơ hình lập

trình hiện tại trong mơi trường lưới, sử dụng nhiều loại dịch vụ lưới để giải quyết các vấn đề như phát hiện, tìm kiếm tài nguyên, bảo mật, cấp phát tài nguyên,…

Workload management system and collaboration framework : Cung cấp khả năng đặc tả, sử dụng, quản lý các luồng cơng việc đa thành phần, bất đồng bộ và qua nhiều bước.

Software discovery service: Tìm kiếm và chọn ra các cài đặt phần mềm tốt

nhất và mơi trường thực thi dựa theo ứng dụng cần được giải quyết.

Community authorization server: Thực hiện các chính sách cơng cộng quản lý truy cập tài nguyên, cho phép các thành viên của cộng đồng truy cập đến các nguyên dùng chung. Các server này sử dụng các dịch vụ xây dựng trên các giao thức thơng tin, quản lý tài nguyên của tầng Resource và giao thức bảo mật ở tầng Connectivity.

Community accounting and payment service: Thu thập các thơng tin sử dụng tài nguyên để tính tốn chi phí, thực hiện chi trả và/hoặc giới hạn việc sử dụng tài nguyên của người dùng trong cộng đồng.

Collaboratory service: Hỗ trợ việc trao đổi thơng tin đồng bộ và bất đồng bộ

trong cộng đồng người dùng.

Các ví dụ trên đây cho thấy các giao thức và dịch vụ tầng Collective rất phong phú, đa dạng. Lưu ý rằng trong khi các giao thức tầng Resource phải là các giao thức tổng quát và triển khai rộng rãi, thì các giao thức tầng Collective cĩ thể trải dài từ việc phục vụ các vấn đề chung trong lưới đến việc phục vụ cho các lĩnh vực ứng dụng cụ thể, cĩ thể chỉ tồn tại trong các VO cụ thể. Theo nguyên tắc, càng phục vụ nhiều người dùng thì các giao thức và API của tầng Collective càng phải được dựa theo chuẩn.

Các chức năng của tầng Collective cĩ thể được cài đặt như các service (với các giao thức tương ứng), hay như các bộ SDK(với các API tương ứng) được thiết kế để liên kết với ứng dụng. Trong cả hai trường hợp, các cài đặt này cĩ thể được xây dựng trên các giao thức và API của tầng Resource và Connectivity.

32

2.2.2.5 Tầng ứng dụng (Application)

Tầng trên cùng của kiến trúc lưới bao gồm các ứng dụng của người dùng chạy trong một trường VO. Hình dưới đây sẽ minh hoạ quan điểm của các lập trình viên về kiến trúc lưới. Các ứng dụng được xây dựng theo cách sẽ gọi các dịch vụ định nghĩa bởi các tầng phía dưới.

Ví dụ : Một chương trình phân tích bộ gen người cần phải chạy hàng ngàn tác vụ độc lập, mỗi tác vụ cần nhiều file chứa thơng tin từng phần của bộ gen cĩ thể sử dụng các chức năng lưới sau:

 Lấy các thơng tin, thẻ chứng thực (các giao thức tầng Connectivity).

 Truy vấn hệ thống thơng tin lưới và các danh mục để tìm các tài nguyên thích hợp và vị trí các file dữ liệu đầu vào. (các dịch vụ tầng Collective).

 Gửi các yêu cầu đến các tài nguyên để thực hiện tính tốn, di chuyển dữ liệu,… và kiểm sốt quá trình thực thi cơng việc, thơng báo cho người dùng khi mọi thứ hồn tất, dị tìm và phản ứng với các điều kiện gây lỗi (tầng Resource).

2.2.3 Các chuẩn đối với tính tốn lưới

Thơng thường lưới tính tốn bao gồm một tập các tài nguyên khơng đồng nhất. Một ứng dụng lưới thường cĩ nhiều thành phần, dịch vụ khác nhau. Đồng thời các dịch vụ này lại thường xuyên tương tác với nhau. Càng nhiều dịch vụ thì số tương tác giữa chúng càng tăng và rất dễ dẫn đến tình trạng hỗn loạn. Nếu mỗi dịch vụ sử dụng một cách riêng để tương tác với các dịch vụ khác thì vấn đề giao tiếp giữa các dịch vụ lưới sẽ rất phức tạp. Do đĩ, cần thiết là phải cĩ chuẩn định nghĩa giao diện giao tiếp chung cho các dịch vụ này.

Global Grid Forum (GGF) đã sử dụng OGSA và OGSI [6] để phát triển cho

mục tiêu chuẩn hố. GGF định nghĩa các chuẩn mạng lưới trong phạm vi các trình ứng dụng, các mơ hình lập trình, quản trị dữ liệu, bảo mật, thực thi, lập lịch và quản lý tài

33

nguyên.

Globus Toolkit là phần triển khai của OGSI, nĩ rất hữu dụng trong việc triển

khai những gì được đặc tả bởi.

Grid Services là các dịch vụ lưới dựa trên nền tảng Web Services và được mở

Một phần của tài liệu Mô hình tính toán lưới và ứng dụng giải một số bài toán trên đồ thị (Trang 36)