Lưu ảnh và phục hồi cho ứng dụng MPI trên môi trường tính toán đám mây

Với xu hướng phát triển trong lĩnh vực công nghệ thông tinhiện nay, điện toán đám mây đang ngày càng đáp ứng được các nhu cầu từcủacác nhà cung cấp dịch vụ công nghệ thông tin với đòi hỏi tính linh hoạt và hiệu xuất cao, chi phí và độ phức tạp thấp, hỗtrợ nhiều dạng tải công việc; đến những người sử dụng với kỳ vọng vào tính sẵn sàng, chức năng và tốc độ không giới hạncủa hệ thống. Khi các công nghệ ảo hóa và các dịch vụ quả lý tương ứng như tự động hóa, giám sát và quy hoạch dung lượng trở nên hoàn chỉnh hơn, điện toán đám mây sẽ được sử dụng rộng rãi hơn cho những công việc đa dạng và quan trọng hơn.

pdf12 trang | Chia sẻ: vietpd | Lượt xem: 1208 | Lượt tải: 1download
Bạn đang xem nội dung tài liệu Lưu ảnh và phục hồi cho ứng dụng MPI trên môi trường tính toán đám mây, để tải tài liệu về máy bạn click vào nút DOWNLOAD ở trên
82 Chương 4 Lưu ảnh và phục hồi cho ứng dụng MPI trên môi trường tính toán đám mây 4.1 Triển khai ứng dụng trên môi trường tính toán đám mây Với xu hướng phát triển trong lĩnh vực công nghệ thông tin hiện nay, điện toán đám mây đang ngày càng đáp ứng được các nhu cầu từ của các nhà cung cấp dịch vụ công nghệ thông tin với đòi hỏi tính linh hoạt và hiệu xuất cao, chi phí và độ phức tạp thấp, hỗ trợ nhiều dạng tải công việc; đến những người sử dụng với kỳ vọng vào tính sẵn sàng, chức năng và tốc độ không giới hạn của hệ thống. Khi các công nghệ ảo hóa và các dịch vụ quả lý tương ứng như tự động hóa, giám sát và quy hoạch dung lượng trở nên hoàn chỉnh hơn, điện toán đám mây sẽ được sử dụng rộng rãi hơn cho những công việc đa dạng và quan trọng hơn. Các ứng dụng được xây dựng trên môi trường điện toán đám mây là sự phát triển và kế thừa những ưu điểm từ các mô hình công nghệ xuất hiện trước như điện toán lưới, điện toán theo nhu cầu và phần mềm như một dịch vụ. Môi trường đám mây ngày càng mở rộng và đa dạng với sự kết hợp năng lực của nhiều hệ thống khác nhau, sử dụng sức mạnh của công nghệ ảo hóa để cung cấp một nền tảng tốt nhất cho việc thực thi những ứng dụng của người dùng. Hình 4.1: Mô hình thực thi ứng dụng trên môi trường đám mây 83 Các ứng dụng có thể được người dùng chuyển lên chạy trên môi trường điện toán đám mây thông qua các cổng giao tiếp với giao diện web, giao diện dòng lệnh hoặc thông qua các APIs hỗ trợ như mô tả trong hình 4.1. Tùy theo nhu cầu sử dụng đã thỏa thuận trước với nhà cung cấp, các ứng dụng này sẽ được điều phối đến các hệ thống phù hợp nhất được cung cấp bởi môi trường đám mây. Khi thực thi trong điều kiện mới này, người dùng hoàn toàn có thể sử dụng các chức năng ứng dụng được cung cấp sẵn trên hệ thống bằng cách thực hiện một số lời gọi dịch vụ đơn giản thay vì việc phải hiện thực các chức năng này trực tiếp trong chương trình ứng dụng của mình. 4.2 Vấn đề lưu ảnh và phục hồi trên môi trường điện toán đám mây Xuất phát từ nhu cầu triển khai ứng dụng, vấn đề nghiên cứu các kỹ thuật đảm bảo tính an toàn cho các ứng dụng chạy trên môi trường tính toán đám mây, làm giảm chi phí phục hồi khi các ứng dụng gặp phải các sự cố không thể loại trừ hẳn về phần cứng, nguồn điện, đường truyền…; các kỹ thuật phục hồi lại trạng thái hệ thống khi có nhu cầu nâng cấp hoặc cân bằng tải trên hệ thống phần cứng được ảo hóa trong đám mây điện toán mà hạn chế chi phí đến mức thấp nhất việc phải chạy lại chương trình; hay các kỹ thuật di dời ứng dụng giữa các hệ thống ảo, giữa các đám mây điện toán, mà vẫn đảm bảo tính ổn định và liên tục tương đối của nó; là những nhu cầu hết sức cần thiết. Luận văn giới hạn quan tâm đến bài toán lưu ảnh và khôi phục cho ứng dụng song song truyền thông điệp trong môi trường đám mây. 4.2.1 Thuận lợi trong điều kiện mới Hầu hết các thư viện lưu ảnh và phục hồi cho các tiến trình đơn cũng như cho chương trình song song đều yêu cầu sự đồng nhất về nền tảng của hệ thống lưu ảnh và hệ thống phục hồi. Điều này có nghĩa là để có thể lưu ảnh và phục hồi thành công, cấu hình hệ thống lưu ảnh, bao gồm cấu hình tất cả các phần mềm cũng như phần cứng liên quan, phải hoàn toàn giống với hệ thống phục hồi. Điều này gây ra một số khó khăn trong việc triển khai hệ thống hỗ trợ lưu ảnh và phục hồi, đặc biệt là các hệ thống hỗ trợ thao tác di dời tiến trình (process migration). 84 Trong môi trường điện toán đám mây, việc xây dựng các hệ thống có cấu hình đồng nhất được thực hiện hết sức nhanh chóng và dễ dàng bằng một vài thao tác đơn giản hỗ trợ bởi nền tảng ảo hóa bên dưới, điều này tạo điều kiện hết sức thuận lợi cho việc triển khai hệ thống hỗ trợ lưu ảnh và phục hồi ứng dụng. 4.2.2 Khó khăn trong điều kiện mới Với điều kiện mới, có rất nhiều dịch vụ chức năng được cung cấp sẵn xung quanh môi trường thực thi, các ứng dụng người dùng sẽ có nhu cầu sử dụng những dịch vụ này thay vì phải tự thực hiện các chức năng tương đương. Điều này chính là điểm hạn chế của hầu hết các thư viện lưu ảnh và phục hồi cho ứng dụng MPI hiện có vì vấn đề yêu cầu những hệ thống bên ngoài phục hồi lại trạng thái giống như lúc lưu ảnh ở thời điểm phục hồi ứng dụng là rất khó (hay là không thể) thực hiện. Hình 4.2: Vấn đề output commit khi lưu ảnh trên đám mây Hình 4.2 mô tả một trường hợp ví dụ về việc thực hiện lưu ảnh và phục hồi thất bại cho ứng dụng khi chạy trên môi trường điện toán đám mây. Ứng dụng của người dùng được chuyển lên chạy trên môi trường đám mây (1) và được bộ điều phối cấp phát một nhóm tài nguyên thích hợp (2). Trong quá trình thực thi của mình, ứng dụng này gọi tới các dịch vụ khác được cung cấp bên ngoài (3) & (4). Trong thời gian ứng dụng đang đợi kết quả trả lời từ dịch vụ bên ngoài, vì một số lý 85 do nào đó mà hệ thống phát sinh thao tác lưu ảnh, di chuyển và phục hồi lại ứng dụng trên một nhóm tài nguyên mới (5). Điều này làm cho ứng dụng bị mất liên lạc với dịch vụ bên ngoài và không thể nhận được kết quả trả về (6). 4.3 Giải pháp của luận văn Từ việc khảo sát các thư viện lưu ảnh và khôi phục cho các ứng dụng song song được trình bày ở chương 3, ta có thể nhận thấy rằng với các thư viện lưu ảnh được thực hiện ở mức người dùng, khi ứng dụng được phục hồi lại từ trạng thái lưu ảnh trước đó, sẽ có một số thông tin của hệ thống sẽ không thể phục hồi được như định danh tiến trình (process ID), các socket giao tiếp,… Ngay cả trong trường hợp các thông số hệ thống có thể được phục hồi với các thư viện lưu ảnh được hiện thực ở cấp hệ điều hành thì việc phục hồi lại các dịch ứng dụng bên ngoài trở lại trạng thái lưu ảnh cũng không thể thực hiện được bởi nhiều lý do liên quan đến quyền hạn truy cập. Chính vì vậy, các ứng dụng có lời gọi dịch vụ bên ngoài vẫn chưa được hỗ trợ tốt để lưu ảnh và khôi phục lại với các thư viện phổ biến hiện nay. Với mục tiêu giải quyết bài toán lưu ảnh cho các ứng dụng MPI trong điều kiện mới, luận văn xây dựng một giải thuật lưu ảnh sau đó sử dụng các thư viện mã nguồn mở sẵn có để hiện thực các giải thuật này. Các phần tiếp theo sẽ lần lược trình bày cụ thể về giới hạn phạm vi giải quyết của giải thuật cũng như phân tích cụ thể giải thuật đề xuất. 4.3.1 Giới hạn phạm vi giải quyết Phạm vi tác dụng của giải thuật phụ thuộc chủ yếu vào loại dịch vụ và kiểu lời gọi dịch vụ mà ứng dụng được lưu ảnh đã dùng. Tùy theo từng loại dịch vụ mà ứng dụng đã gọi tới, giải thuật hỗ trợ lưu ảnh cũng phải được thay đổi sao cho phù hợp. 4.3.1.1 Các loại dịch vụ Về mặt định nghĩa, dịch vụ (service) là một hệ thống có khả năng nhận một hay nhiều yêu cầu xử lý và sau đó đáp ứng lại bằng cách trả về một hay nhiều kết quả. Quá trình nhận yêu cầu và trả kết quả về được thực hiện thông qua các giao 86 diện (interface) đã được định nghĩa trước đó. Thông thường việc giao tiếp này được thực hiện trên các giao diện đã được chuẩn hóa và sử dụng rộng rãi. Có nhiều cách hiện thực một dịch vụ nhưng nhìn chung chúng được chia làm hai loại: - Dịch vụ có trạng thái (stateful service): Trong loại dịch vụ này, trạng thái của dịch vụ được lưu lại sau các yêu cầu xử lý từ người dùng, gọi là các thể hiện của dịch vụ (service instances). Nói cách khác, cùng một yêu cầu xử lý của người dùng có thể nhận được các kết quả khác nhau trong các thời điểm khác nhau. - Dịch vụ không trạng thái (stateless service): Ngược lại với loại thứ nhất, loại dịch vụ vày có trạng thái độc lập với các yêu cầu xử lý của người dùng. Một yêu cầu xử lý sẽ nhận được kết quả như nhau mặc dù được gọi ở thời điểm nào đi chăng nữa. Với bài toán lưu ảnh ứng dụng nói chung, các sự kiện mà khi tương tác với ứng dụng sẽ tạo ra các kết quả khác nhau ở các điều kiện khác nhau không thể xác định trước gọi là các sự kiện bất định. Các sự kiện này luôn là điểm khó khăn trong việc hiện thực các kỹ thuật lưu ảnh vì rất khó đảm bảo phục hồi lại ứng dụng trở lại trạng thái lưu ảnh với sự hiện diện của các sự kiện bất định. Trong trường hợp này, loại dịch vụ có trạng thái có thể xem là một sự kiện bất định vì kết quả trả về từ một yêu cầu xử lý sẽ phụ thuộc vào trạng thái dịch vụ và không thể xác định trước được. Chính vì vậy, trong điều kiện thời gian có hạn, luận văn sẽ tập trung giải quyết bài toán lưu ảnh ứng dụng có lời gọi đến các dịch vụ không trạng thái. Vấn đề nghiên cứu để hỗ trợ cho loại dịch vụ có trạng thái sẽ là hướng phát triển trong tương lai. 4.3.1.2 Các loại lời gọi dịch vụ Lời gọi dịch vụ là một hiện thực của quá trình gởi yêu cầu đến dịch vụ và nhận kết quả trả lời về. Hiện tại có hai cách hiện thực một lời gọi dịch vụ: - Lời gọi đồng bộ (Synchronous call): Khi sử dụng lời gọi này, ứng dụng sẽ phải đợi cho đến khi nhận được kết quả trả lời từ dịch vụ rồi mới chạy tiếp. 87 - Lời gọi bất đồng bộ (Asynchronous call): Khi sử dụng lời gọi này chương trình chính vẫn tiếp tục gọi các lệnh kế tiếp mà không phải đợi nhận được kết quả trả về, tuy nhiên vấn đề đồng bộ cần được quan tâm trong cách hiện thực này. Bản chất loại lời gọi này là tạo ra một tiểu trình (thread) mới thực hiện lời gọi đồng bộ. Các thư viện lưu ảnh và khôi phục cho các ứng dụng MPI hiện tại đã hỗ trợ tốt việc lưu ảnh cho các tiểu trình con được sinh ra từ chương trình chính. Giải thuật đề xuất của luận văn sẽ dựa vào lợi thế này và chỉ quan tâm giải quyết cho lời gọi dịch vụ theo kiểu đồng bộ, công việc phục hồi lại tiểu trình khi dùng lời gọi bất đồng bộ sẽ được các thư viện lưu ảnh hiện có đảm trách. 4.3.2 Giải thuật đề xuất Để phục hồi ứng dụng lại trạng thái khi lưu ảnh ta phải giải quyết theo cách quay lui các tiến trình có lời gọi dịch vụ chưa hoàn tất (đã thực hiện lời gọi nhưng chưa nhận được hồi đáp tại thời điểm lưu ảnh) trở lại thời điểm trước khi thực hiện lời gọi. Ý tưởng chính của giải thuật là thực hiện việc đánh dấu các tiến trình có sử dụng lời gọi đến các dịch vụ bên ngoài để thực hiện quay lui khi phục hồi nếu lời gọi đó chưa hoàn tất. Việc đánh dấu này được thực hiện bằng quá trình tiền xử lý (pre-processing) và hậu xử lý (post-processing) kết hợp giữa hai quá trình gọi dịch vụ và lưu ảnh. Giải thuật cụ thể của từng quá trình được trình bày như sau : - Quá trình thực thi của từng tiến trình trong ứng dụng MPI: /*Ban đầu tất cả các tiến trình đều chưa được đánh dấu là có gọi dịch vụ*/ Tiến trình thực thi đến lời gọi dịch vụ. Tiền xử lý:(WAIT_OWP) Đánh dấu là tiến trình có gọi dịch vụ. Thực hiện lời gọi dịch vụ. Hậu xử lý: (RELEASE_OWP) Bỏ đánh dấu là tiến trình đã gọi dịch vụ. 88 - Quá trình thực hiện lưu ảnh Một tiến trình của chương trình song song P có n tiến trình, lập trình theo kiểu truyền thông điệp, thông thường được quản lý bởi tiến trình mpirun, được ký hiệu là Pi với i  [0,n). Khi tiến trình Pi của chương trình song song MPI thực thi đến lời gọi sử dụng dịch vụ bên ngoài, quá trình tiền xử lý của lời gọi dịch vụ sẽ đánh dấu rằng tiến trình này đang chờ nhận kết quả từ OWP bằng cách gọi hàm WAIT_OWP(Pi), sau đó mới thực hiện lời gọi dịch vụ. Trong lúc tiến trình Pi đang chờ nhận kết quả trả về từ OWP sẽ có thể xảy ra hai trường hợp: - Sự kiện lưu ảnh xảy ra: quá trình hậu xử lý của sự kiện lưu ảnh sẽ đánh dấu tất cả các tiến trình đang chờ nhận kết quả từ OWP bằng cách gọi hàm POST_CHECKPOINT(Pi), với Pi thỏa (i,  [ Pi  WAIT_OWP(i)]). Sự kiện này sẽ dẫn tới việc các lời gọi dịch vụ chưa hoàn thành sẽ kết thúc thất IF (tiến trình thất bại và được đánh dấu là đã được lưu ảnh){ Bỏ đánh dấu đã lưu ảnh. Quay lại “Tiền xử lý”. } Tiến trình thực thi tiếp cho đến hết. /*Ban đầu tất cả các tiến trình đều chưa được đánh dấu là đã có lưu ảnh*/ Tiến hành lưu ảnh. Hậu xử lý: (POST_CHECKPOINT) IF (tiến trình đã được đánh dấu có gọi dịch vụ) Đánh dấu là tiến trình đã được lưu ảnh. Kết thúc lưu ảnh. 89 bại khi chương trình được phục hồi lại sau này. Lúc đó quá trình hậu xử lý lời gọi dịch vụ RELEASE_OWP(Pi) sẽ thực hiện việc quay lui ứng dụng lại thời điểm thực hiện tiền xử lý của lời gọi dịch vụ và thực hiện lại lời gọi dịch vụ này. - Sự kiện lưu ảnh không xảy ra: Các lời gọi dịch vụ sẽ có cơ hội kết thúc thành công. Quá trình hậu xử lý hủy đánh dấu trạng thái chờ nhận kết quả từ OWP bằng cách gọi hàm RELEASE_OWP(Pi). Giải thuật đề xuất có thể được mô hình hóa dưới dạng lưu đồ thực thi của hai quá trình chạy ứng dụng và lưu ảnh như ở hình 4.3. Hai quá trình này diễn ra hoàn toàn độc lập nhau. Hình 4.3: Lưu đồ xử lý của giải thuật đề xuất Với giải thuật này, chúng ta phải chấp nhận chi phí của việc đánh dấu. Chi phí này sẽ là vô ích nếu thời điểm lưu ảnh đúng vào thời điểm lời gọi dịch vụ vừa hoàn 90 tất và chưa kịp thực hiện quá trình hậu xử lý. Khi đó giải thuật sẽ thực hiện lại lời gọi dịch vụ một lần nữa, lời gọi này là không cần thiết tuy nhiên vẫn không làm sai đi kết quả cuối cùng của chương trình và vẫn có thể chấp nhận được với mục tiêu để đảm bảo tính đúng đắn của chương trình trong tất cả các trường hợp còn lại. 4.3.3 Hiện thực giải thuật Để tận dụng sức mạnh của các thư viện lưu ảnh cho ứng dụng MPI cũng như các thư viện hỗ trợ xây dựng lời gọi dịch vụ hiện có, các hàm WAIT_OWP, RELEASE_OWP, POST_CHECKPOINT sẽ được xây dựng theo cách dùng có thể gắn kết vào các thư viện mã nguồn mở để thực hiện mục tiêu của giải thuật. Với mục tiêu là có thể tích hợp được với nhiều thư viện mã nguồn mở sử dụng nhiều ngôn ngữ lập trình khác nhau, đồng thời có thể sử dụng được mà không yêu cầu phải cài đặt thêm bất kỳ thư viện nào, các hàm này sẽ được hiện thực bằng ngôn ngữ SHELL script trên Linux. Tùy theo cách hiện thực các hàm WAIT_OWP, RELEASE_OWP, POST_CHECKPOINT mà ta có hai hướng tiếp cận tập trung và phân tán. Hình 4.5 thể hiện một ví dụ quá trình xử lý của giải thuật đề xuất. Giải thuật này không tham gia vào việc lưu ảnh tại các thời điểm 1 và 3. Tại thời điểm lưu ảnh thứ 2, giải thuật sẽ sử dụng thông tin đánh dấu từ quá trình bắt đầu thực hiện lời gọi dịch vụ và quá trình kết thúc lời gọi để quyết định việc tạo ra thông tin đánh dấu rằng tiến trình P0 đang ở trạng thái gọi dịch vụ nhưng chưa nhận được hồi đáp (hoặc chưa kết thúc quá trình nhận hồi đáp). Khi phục hồi ứng dụng tại trạng thái lưu ảnh thứ 2, tiến trình P0 sẽ không thể tiếp tục quá trình chờ nhận hồi đáp từ dịch vụ bên ngoài và khiến cho lời gọi dịch vụ kết thúc thất bại, nhờ vào các thông tin đánh dấu trước đó, giải thuật sẽ phục hồi lại lời gọi thất bại bằng cách để tiến trình P0 gọi lại lời gọi đó. 91 Hình 4.4: Quá trình xử lý của giải thuật đề xuất 4.3.3.1Tiếp cận theo hướng tập trung Theo hướng tiếp cận này, tất cả các thông tin đánh dấu trạng thái của tiến trình phụ (slave process), tiến trình có rank ≠ 0, đều được lưu trữ tập trung tại máy tính chạy tiến trình chính (head process node - HPN), tiến trình có rank = 0. Điều này sẽ gây thêm chi phí (overhead) do việc các Pi phải gởi thông tin đánh dấu về cho P0 trong quá trình tiền xử lý lời gọi dịch vụ, cũng như chi phí yêu cầu thông tin từ P0 trong quá trình hậu xử lý lời gọi dịch vụ. Tuy nhiên hướng tiếp cận này lại tạo điều kiện thuận lợi cho quá trình hậu xử lý lưu ảnh vì các thông tin đánh dấu cần kiểm tra đều nằm trên máy P0, máy khởi tạo quá trình lưu ảnh. 92 Hình 4.5: Hướng tiếp cận tập trung Mô hình của hướng tiếp cận tập trung được thể hiện trong hình 4.4 cho thấy rằng trong quá trình thực thi ứng dụng, ứng với mỗi lời gọi dịch vụ, các tiến trình phụ sẽ phải tạo thêm hai kết nối đến tiền trình chính để yêu cầu đánh dấu thông tin. Vấn đề quản lý các kết nối tạo thêm này trong quá trình lưu ảnh ứng dụng sẽ không được hỗ trợ bởi thư viện lưu ảnh ứng dụng MPI hiện có và sẽ là khó khăn lớn của quá trình hiện thực hướng tiếp cận này. Khi sự kiện lưu ảnh xảy ra, tiến trình POST_CHECKPOINT chỉ cần xử lý thông tin đánh dấu đã được tập trung tại máy chạy tiến trình chính P0. 4.3.3.2Tiếp cận theo hướng phân tán Ngược với hướng tiếp cận tập trung, hướng tiếp cận phân tán lưu trữ cục bộ các thông tin đánh dấu trạng thái của mỗi tiến trình Pi tại máy chạy tiến trình đó. Như vậy, chương trình chỉ phải chịu chi phí cho việc lưu trữ thông tin đánh dấu trong quá trình tiền xử lý cho lời gọi dịch vụ, cũng như chi phí truy xuất thông tin đánh dấu trong quá trình hậu xử lý lời gọi dịch vụ. Bù lại, quá trình hậu xử lý lưu ảnh sẽ phát sinh chi phí nhiều hơn do P0 phải yêu cầu thông tin từ các Pi. 93 Hình 4.6: Hướng tiếp cận phân tán Mô hình hướng tiếp cận phân tán trong hình 4.5 cho thấy trong quá trình thực thi của chương trình, giải thuật không hề tạo thêm bất kỳ kết nối nào giữa các máy trong hệ thống. Thông tin đánh dấu được phát sinh thêm ở các máy có thể được thư viện lưu ảnh ứng dụng MPI hiện có hỗ trợ lưu trữ một cách dễ dàng trong quá trình lưu ảnh. Điều này làm cho hướng tiếp cận theo kiểu phân tán sẽ dễ hiện thực hơn cách tiếp cận tập trung. Khi sự kiện lưu ảnh xảy ra, quá trình lưu ảnh sẽ chịu thêm chi phí để tiến trình POST_CHECKPOINT xử lý thông tin đánh dấu trên tất cả các máy chạy chương trình.
Tài liệu liên quan