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.
                
              
                                            
                                
            
 
            
                 12 trang
12 trang | 
Chia sẻ: vietpd | Lượt xem: 1449 | Lượt tải: 1 
              
            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.