Đề tài Nguyên tắc của việc ảo hóa trong các hệ phân tán

er có thể là một phương án. Một giải pháp phổ biến mà chúng ta sẽ thảo luận kỹ hơn ở chương 11 là server phản hồi một read or write request bằng cách: trước tiên mở file đó rồi thực hiện việc đọc, ghi sau đó đóng file ngay lập tức. Trong các trường hợp khác, server có thể muốn lưu lại thông tin về các hành vi của client, từ đó nó có thể phản hồi các yêu một cách hiệu quả hơn. Chẳng hạn Web server đôi khi có khả năng chỉ dẫn trực tiếp client đến các favourite pages. Phương pháp này là khả thi chỉ khi sever có các history information trên client. Khi server không thể duy trì state, giải pháp chung là để client gửi đến các thông tin bổ sung về các lượt truy cập trước của nó, các thông tin này (được gọi là cookie) thường được lưu giữ một cách trong suốt bởi các client's browser. Cookies không bao giờ được thực thi bởi browser mà chỉ đơn thuần được lưu trữ. Trong lần đầu tiên client truy cập đến server, server sẽ gửi cookie với trang web được yêu cầu đến browser sau đó browser cất giữ cookie. Mỗi lần client truy cập server sau đó, cookie của nó ứng với server tương ứng sẽ được gửi đi cùng với yêu cầu. 3.4.2 Server Clusters. Sever cluster là một tập các thiết bị được kết nối với nhau thông qua mạng, và mỗi thiết bị có thể chạy một hoặc nhiều server. Server cluster mà chúng ta đề cập đến ở giáo trình này được kết nối thông qua mạng lan với tốc độ cao và độ trễ thấp. Trong hầu hết các trường hợp, server cluster được tổ chức theo thành 3 tầng logic, như hình 3-12 Tầng đầu tiên gồm có một logical switch dùng để định tuyến các yêu cầu của client. Ví dụ transport-layer switches nhận các yêu cầu kết nối TPC đến và chuyển các yêu cầu đến một server trong server clusters. Một ví dụ khác là Web server nhận các yêu cầu HTTP, nhưng chỉ chuyển qua phần nào các yêu cầu đó đến application servers. Như trong mọi kiến trúc client-server đa tầng, nhiều server clusters thậm chí còn có các server chuyên dụng dành cho xử lý các ứng dụng. Trong cluster computing, có nhiều server sử dụng các phần cứng hiệu năng cao để tăng cường khả năng tính toán. Tuy nhiên trong trường hợp của enterprise server clusters, có trường hợp các ứng dụng chỉ cần chạy trên các máy tính khá rẻ tiền. Tầng thứ 3 gồm các data-processing servers. Dựa theo cách mục đích sử dụng server cluster, các server này có thể chạy trên các máy tính chuyên dụng được cấu tạo bởi các ổ đĩa có tốc độ truy cập cao và có bộ nhớ cache lớn. Dĩ nhiên không phải mọi server cluster đều phải chia theo 3 tầng như trên. Thường có trường hợp mỗi thiết kế được trang bị một vùng lưu trữ của riêng nó, người ta có thể tích hợp tầng 2 và 3 để tạo thành một kiến trúc 2 tầng. Chẳng hạn, khi xử lý streaming media theo giải pháp server cluster, thường triển khai kiến trúc hệ thống 2 tầng Khi server cluster cung cấp nhiều dịch vụ, có thể xảy ra trường hợp các thiết khác nhau chạy các server ứng dụng khác nhau. Do đó, switch phải có khả năng phân biệt các dịch vụ, nếu không thì nó không thể forward các yêu cầu tới các thiết bị thích hợp. Vì lý do đó, nhiều thiết bị ở tầng 2 chỉ chạy duy nhất một ứng dụng. Sự hạn chế này không những chỉ phụ thuộc vào các phần mềm và phần cứng sẵn có, mà thậm chí còn do các trình ứng dụng khác nhau thường được quản lý bởi những nhà quản trị khác nhau. Vì lý do trên, có những thiết bị nhàn rỗi, trong khi những thiết bị khác lại quá tải bởi các yêu cầu của client. Do vậy sẽ hữu ích hơn khi chúng ta tạm thời chuyển bớt các dịch vụ sang các thiết nhàn rỗi. Một giải pháp được đề xuất năm 2004 là sử dụng các máy ảo cho phép di trú mã tới các máy thật. Chúng ta sẽ đề cập đến di trú mã trong phần sau của chương. Chúng ta sẽ tìm hiểu sâu hơn về tầng 1, bao gồm các switch. Một mục tiêu thiết kế quan trọng cho server cluster là che giấu thực tế rằng có nhiều server đang hoạt động. Nghĩa là các trình ứng dụng client chạy trên các máy tính ở xa không cần biết chút gì về sự tổ chức bên trong của cluster. Tính trong suốt trong truy cập này luôn luôn được cung cấp bởi 1 single access point, được thực hiện bởi một số loại switch chuyên dụng. Switch thiết lập entry point cho server cluster, cung cấp một single access point. Để đạt được tính mở rộng và sẵn sàng, một server cluster có thể có nhiều điểm truy cập, khi đó mỗi điểm truy cập được thực hiện bởi một máy chuyên dụng. Chúng ta chỉ đề cập đến trường hợp của single access point. Một cách thức truy cập server cluster chuẩn là thiết lập một kết nối TCP mà nhờ vào nó các application-lever request được gửi đi trong một phiên. Một phiên kết thúc bằng cách ngừng kết nối TCP đó. Trong trường hợp các trasport-layer switch, switch nhận các yêu cầu kết nối TCP đến và chuyển các yêu cầu kết nối này đến một trong số các server. Nguyên lý làm việc này thường được gọi là TCP handoff (hình 3-13). Khi switch nhận một yêu cầu kết nối TCP, nó xác định server thích hợp nhất để xử lý yêu cầu đó rồi chuyển yêu cầu tới server. Đến lượt mình server sẽ gửi acknowledment tới client gửi request, nhưng sẽ thêm vào gói tin địa chỉ IP của switch như là địa chỉ nguồn của gói tin này. Sự thêm vào địa chỉ IP này là cần thiết cho client tiếp tục thực hiện giao thức TCP vì client đang mong đợi phản hồi từ switch chứ không phải từ một server nào đó mà nó chưa hề biết đến. Rõ ràng việc thực thi TCP handoff yêu cầu phải cải tiến hệ điều hành. Chúng ta có thể thấy rằng switch thực hiện vai trò quan trọng trong việc phân phối tải giữa các server khác nhau. Bằng cách quyết định chuyển các request đi đâu, switch quyết định server nào sẽ xử lý các yêu cầu đó. Phương pháp cân bằng tải đơn giản nhất là switch sẽ chuyển các yêu cầu theo thứ tự vòng tròn. Nhiều tiêu chuẩn lựa chọn server cải tiến có thể được triển khai. Chẳng hạn giả sử rằng nhiều dịch vụ được cung cấp bởi server cluster. Nếu switch có thể phân biệt các dịch vụ này khi có một yêu cầu được gửi đến, nó có thể đưa ra quyết định sẽ chuyển yêu cầu đến server nào. Sự lựa chọn này có thể vẫn xảy ra ở transport level, các dịch vụ được phân biệt bằng port number. Distributed servers. Server cluster hiếm khi được cấu hình tĩnh. Trong các cluster này, thường có một máy quản trị theo dõi các server đang hoạt động và chuyển các thông tin đó tới các thiết bị khác, chẳng hạn như switch. Như đã nói ở trên, mỗi server cluster đều cung cấp một single access point. Khi điểm này lỗi, cluster sẽ không hoạt động được nữa. Để loại trừ khả năng tiềm ẩn này, một vài điểm truy cập có thể được cung cấp và mỗi điểm này có một địa chỉ IP công cộng. Chẳng hạn, Domain Name System (DNS) có thể có nhiều địa chỉ và tất cả đều thuộc về một hosname giống nhau. Có một điểm truy cập ổn định là một tính năng mong muốn của client và server. Mặt khác, người ta còn mong muốn có sự mềm dẻo trong việc cấu hình server cluster bao gồm cả switch. Ý tưởng cơ bản của server phân tán là có một server hiệu năng cao và ổn định. Những thuộc tính này thường có thể được cung cấp bởi những mainframes đắt tiền. Tuy nhiên bằng cách nhóm các thiết bị đơn giản một cách trong suốt thành một nhóm và không phụ thuộc vào sự hoạt động của một thiết bị đơn, nhờ vậy có thể đạt được sự ổn định hơn so với một server đơn lẻ. Chẳng hạn một cluster có thể được cấu hình từ các thiết bị đầu cuối, như trong trường hợp của hệ phân tán cộng tác. Làm sao để có thể đạt được một access point ổn định trong một hệ thống như vậy? Ví dụ trong MIPv6, một thiết bị di động được coi như có một home network và home network này có một home address (HoA). Home network này có một router đặc biệt, được gọi là home agent theo dõi traffic đến thiết bị đó khi nó ở xa. Để đạt được sự ổn định như trên, khi một thiết bị di động tham gia vào một foreign network, nó sẽ nhận một care-of address (CoA) tạm thời. CoA này sẽ được chuyển tới home agent và các ứng dụng truyền thông với điểm di động này sẽ chỉ biết địa chỉ gắn với địa chỉ của home network mà không biết gì về CoA. Nguyên lý này có thể được sử dụng để cung cấp một địa chỉ ổn định của server phân tán. Trong trường hợp này, một địa chỉ cố định ban đầu được gán cho cluster server. Địa chỉ này của server sẽ dùng trong mọi giao thiệp với thế giới bên ngoài. Trong mọi thời điểm, một node trong server phân tán sẽ hoạt động như một access point sử dụng địa chỉ cố định này này. Mọi thông tin liên lạc với thế giới bên ngoài sẽ được gửi đến access point, sau đó hệ thống sẽ sử dụng CoA để gửi thông tin đến các thiết bị thích hợp trong hệ thống. Một cấu hình đơn giản như vậy sẽ tạo thành một nút thắt cổ chai tại home agent cũng như access point vì mọi traffic đều phải truyền qua 2 thiết bị này. Tình trạng này có thể tránh được bằng cách sử dụng một tính năng của MIPv6 là route optimization. Route optimiztion hoạt động như sau. Bất cứ khi nào một thiết bị di động với home address (HA) thông báo CoA (CA), home agent có thể gửi CA đến client. Sau đó client sẽ lưu trữ cặp (HA,CA). Trong một khoảng thời gian rất ngắn, thông tin sẽ được gửi trực tiếp đến CA. Mặc dù ứng dụng ở phía client có thể vẫn sử dụng home address, phần mềm hỗ trợ cho MIPv6 sẽ dịch địa chỉ ấy thành CA và sử dụng CA thay cho HA. Route optimization có thể được sử dụng để giúp các client khác nhau tin rằng chúng đang giao tiếp với một server đơn lẻ, nhưng thực tế là mỗi client đang giao tiếp với một thành viên khác nhau trong server phân tán, như hình 3-14. Để đạt được điều đó, khi một điểm truy cập của server phân tán chuyển yêu cầu từ client C1 tới Server S1 (với địa chỉ CA1) nó sẽ chuyển đủ thông tin tới S1 để S1 thực hiện thủ tục tối ưu hóa, nhờ đó client sẽ tin rằng địa chỉ care-of address là CA1. Điều này sẽ cho phép C1 lưu trữ cặp (HA,CA1). Trong suốt thủ tục này, điểm truy cập cũng như home agent tạo một đường hầm giữa C1 và S1. Điều này khiến home agent không nghĩ rằng CoA đã thay đổi, vì vậy nó sẽ tiếp tục giao tiếp với điểm truy cập. Tuy nhiên trong khi route optimization procedure đang thực hiện, các yêu cầu từ các client khác có thể vẫn được gửi đến. Những yêu cầu này vẫn ở trạng thái đợi trong điểm truy cập cho đến khi nó được chuyển đi. Yêu cầu từ client C2 sau đó có thể được chuyển đến S2 (với địa chỉ CA2), cho phép client C2 lưu trữ cặp địa chỉ (HA,CA2). Do đó, các client khác nhau sẽ giao tiếp trực tiếp với các thành viên khác nhau của server phân tán và mỗi ứng dụng client vẫn có ảo tưởng rằng server có địa chỉ HA. 3.4.3 Quản lý máy chủ cụm Một cụm máy chủ sẽ xuất hiện với thế giới bên ngoài như một máy vi tính, như là thực sự thường là trường hợp. Tuy nhiên, khi nói đến việc quản lý một cụm, các giải pháp thay đổi đáng kể. Một số nỗ lực đã được thực hiện để giảm bớt việc quản lý các cụm máy chủ như chúng tôi thảo luận kế tiếp. -Phương pháp tiếp cận thường gặp -Bằng phương pháp tiếp cận đến nay phổ biến nhất để quản lý một cụm máy chủ là mở rộng -các chức năng quản lý truyền thống của một máy vi tính đó của một cụm. Tại của nó hầu hết các mẫu nguyên thủy, điều này có nghĩa là một quản trị viên có thể đăng nhập vào một nốt từ một việc quản lý viẹc thực thi cục bộ bằng lệnh tới màn hình, cài dặt, và thay đổi thành phần. Hơi tiên tiến hơn là để giấu một thực tế là bạn cần phải đăng nhập vào một nút và thay vào đó cung cấp một giao diện tại một máy hành chính cho phép để thu thập thông tin từ một hoặc nhiều máy chủ, các thành phần nâng cấp, thêm và xoá các nút, vv Các lợi thế chính của phương pháp thứ hai là các hoạt động tập thể, trong đó hoạt động trên một nhóm các máy chủ, có thể được cung cấp dễ dàng hơn. Loại quản lý các cụm máy chủ được áp dụng rộng rãi trong thực tế, exemplified bởi quản lý & phát triển các phần mềm như Cluster Hệ thống quản lý của IBM (và Hochstetler Beringer, 2004). Tuy nhiên, ngay sau khi các cụm phát triển vượt vài chục nút, kiểu này quản lý không phải là cách để đi. Nhiều trung tâm dữ liệu cần quản lý hàng ngàn máy chủ, các tổ chức thành các cụm nhiều nhưng tất cả các hoạt động hợp tác. Làm điều này bằng phương tiện của máy chủ quản trị tập trung chỉ đơn giản là trong số các câu hỏi. Hơn nữa, nó có thể dễ dàng nhìn thấy rằng các cụm rất lớn cần phải sửa chữa liên tục quản lý (bao gồm nâng cấp). Để đơn giản hóa vấn đề, nếu p là khả năng mà một máy chủ hiện đang bị lỗi, và chúng tôi cho rằng lỗi là độc lập, sau đó cho một Cụm máy chủ B, để hoạt động mà không có một máy chủ đang bị lỗi là duy nhất (l_p) N. Với p = O. OOl và N = 1000, chỉ có một cơ hội 36 phần trăm tất cả các máy chủ được đúng chức năng. Vì nó biến ra, hỗ trợ cho các cụm máy chủ rất lớn là hầu như luôn luôn quảng cáo hoc. Có những quy tắc khác nhau của ngón tay cái mà cần được xem xét (Brewer, 2001), nhưng không có phương pháp tiếp cận hệ thống để đối phó với các hệ thống quản lý lớn. Cụm quản lý vẫn còn rất nhiều trong giai đoạn trứng của nó, mặc dù nó có thể được mong đợi rằng tự quản lý các giải pháp như được thảo luận trong chương trước sẽ tìm cách đồng minh của họ trong lĩnh vực này, sau khi trải nghiệm nhiều hơn với họ đã thu được. Ví dụ: PlanetLab Hãy cho chúng tôi ngay bây giờ hãy xem kỹ hơn một máy chủ cụm hơi bất thường. PlanetLab là một hệ thống hợp tác phân phối, trong đó các tổ chức khác nhau mỗi tặng một hoặc nhiều máy tính, thêm lên đến tổng cộng hàng trăm nút. Cùng với nhau, các máy tính tạo thành một l tầng cụm máy chủ, nơi truy cập, chế biến, lưu trữ và có thể tất cả sẽ diễn ra vào nút mỗi cá nhân. Quản lý PlanetLab là do gần như hoàn toàn được phân phối. Trước khi chúng tôi giải thích nguyên tắc cơ bản của nó, cho chúng tôi lần đầu tiên mô tả các tính năng kiến trúc chính (Peterson et al., 2005). Trong PlanetLab, một tổ chức, tài trợ một hoặc nhiều nút, nơi mà mỗi nút là dễ nhất là tư tưởng của một máy tính chỉ duy nhất, mặc dù nó cũng có thể là chính nó một cụm của máy. Mỗi nút được tổ chức như trong hình. 3-15. Có hai thành phần phổ biến (Bavier et al., 2004). Một là các máy ảo giám sát (VMM), mà là một hệ điều hành Linux nâng cao. Việc tăng cường chủ yếu bao gồm điều chỉnh để hỗ trợ các thành phần thứ hai, cụ thể là Vservers . Một vserver (Linux) tốt nhất có thể được dùng như một môi trường riêng biệt trong trong đó một nhóm các quy trình chạy. Các quy trình từ vservers khác nhau là hoàn toàn độc lập. Họ có thể không trực tiếp chia sẻ bất kỳ tài nguyên như các tệp, bộ nhớ chính , và mạng lưới kết nối như là bình thường trong trường hợp với tiến trình đang chạy trên đầu trang của một hệ điều hành. Thay vào đó, một vserver cung cấp môi trường bao gồm của bộ sưu tập của riêng các gói phần mềm, các chương trình, và các cơ sở mạng. Vì Ví dụ, một vserver có thể cung cấp một môi trường mà trong đó một quá trình sẽ thông báo mà nó có thể làm cho việc sử dụng Python 1.5.2 kết hợp với một cũ Apache Web máy chủ, nói httpd 1.3.1. Ngược lại, một vserver có thể hỗ trợ các phiên bản mới nhất của Python và httpd. Trong ý nghĩa này, gọi một vserver một máy chủ là một chút của một sự lộn tên như nó chỉ thực sự cô lập các nhóm các quy trình từ mỗi khác. Chúng tôi trở lại để vservers một thời gian ngắn dưới đây. Các VMM Linux đảm bảo rằng vservers được tách ra: trong các quá trình khác nhau máy chủ được thực hiện đồng thời và độc lập, từng làm việc sử dụng duy nhất của gói phần mềm và các chương trình có sẵn trong môi trường của riêng họ. giữa các quá trình khác nhau riêng biệt trong vservers là nghiêm ngặt. Ví dụ, hai qúa trình trong vservers khác nhau có thể có cùng một người dùng bị bệnh, nhưng điều này không ngụ ý rằng họ xuất phát từ cùng một người dùng. Tách này giúp giảm bớt đáng kể hỗ trợ người dùng từ các tổ chức khác nhau mà muốn sử dụng PlanetLab như, ví dụ, một thử nghiệm để thử nghiệm hoàn toàn khác với hệ thống phân phối và các ứng dụng. Để hỗ trợ thí nghiệm như vậy, PlanetLab giới thiệu quan niệm của một lát, mà là một bộ vservers, mỗi vserver chạy trên một nút khác nhau. Một lát có thể do đó được dùng như một cụm máy chủ ảo, thực hiện bằng phương tiện của một tập hợp của máy ảo. Các máy ảo trong PlanetLab chạy trên đầu Hệ điều hành Linux, mà đã được mở rộng với một số đơn vị hạt nhân Có một số vấn đề mà làm quản lý của PlanetLab một vấn đề đặc biệt. Ba những người nổi bật là: 1. Các nút thuộc về các tổ chức khác nhau. Mỗi tổ chức phải được được phép chỉ định người được phép chạy các ứng dụng trên các nút của họ, và hạn chế việc sử dụng tài nguyên một cách phù hợp. 2. Có các công cụ giám sát khác nhau có sẵn, nhưng họ tất cả các giả định một rất cụ thể kết hợp giữa phần cứng và phần mềm. Hơn nữa, họ là tất cả phù hợp sẽ được sử dụng trong vòng một tổ chức duy nhất. 3. Chương trình từ lát khác nhau, nhưng chạy trên cùng một nút không nên can thiệp với nhau. Vấn đề này cũng tương tự như quá trình độc lập trong hệ điều hành. Hãy để chúng tôi xem xét từng vấn đề này chi tiết hơn. Trung tâm để quản lý nguồn tài nguyên PlanetLab là người quản lý nút. Mỗi nút có như một người quản lý, triển khai thực hiện bằng phương tiện của một vserver riêng, công việc duy nhất mà là tạo ra vservers khác vào nút đó để kiểm soát và quản lý tài nguyêncho phép.Người quản lý nút không thực hiện bất kỳ quyết định chính sách, nó chỉ là một Cơ khi để cung cấp cho các thành phần thiết yếu để có được một chương trình chạy trên một được nút. Theo dõi các nguồn lực được thực hiện bằng phương tiện của một đặc tả tài nguyên,xác định một khoảng thời gian trong đó một số nguồn tài nguyên đã được cấp phát. Nguồn tài nguyên bao gồm không gian đĩa, mô tả tập tin, gửi đến và đi mạng băng thông, vận tải cấp các điểm kết thúc, chính bộ nhớ, và CPU cách sử dụng. Một Rspee được xác định thông qua một trên toàn cầu duy nhất 128-bit nhận diện được gọi là một khả năng tài nguyên (gặt hái). Cho một gặt hái, người quản lý nút có thể tra cứu như rspee trong một bảng địa phương. Tài nguyên bị ràng buộc để lát. Nói cách khác, để làm cho việc sử dụng tái nguồn, nó là cần thiết để tạo ra một lát. Mỗi lát là liên kết với một dịch vụ nhà cung cấp, mà tốt nhất có thể được xem như một thực thể có một tài khoản trên PlanetLab. SERVERS Mỗi lát sau đó có thể được xác định bởi một iprincipal.sid, slice.uag) cặp, nơi chủ yếu xác định các nhà cung cấp và slice.stag là một định danh được chọn bởi các nhà cung cấp. Để tạo một lát mới, mỗi nút sẽ chạy một dịch vụ sáng tạo slice (SCS), trong đó, trong tum, có thể liên hệ với người quản lý node yêu cầu nó để tạo ra một vserver và để phân bổ nguồn lực. Người quản lý nút tự nó không có thể liên lạc trực tiếp qua một mạng, cho phép nó chỉ tập trung về quản lý tài nguyên địa phương. Trong tum, các SCS sẽ không chấp nhận yêu cầu cắt miếng-tạo từ chỉ ai. Chỉ cụ thể chính quyền cắt đủ điều kiện yêu cầu việc tạo ra một lát. Mỗi lát thẩm quyền sẽ có quyền truy cập vào một bộ sưu tập của các nút. Các mô hình đơn giản nhất là có thể có chỉ một lát thẩm quyền duy nhất mà được phép yêu cầu. slice tạo trên tất cả các nút. Để hoàn tất bức tranh, một nhà cung cấp dịch vụ sẽ liên lạc với một lát và quyền hạn yêu cầu để tạo ra một cắt ngang qua một bộ sưu tập của các nút. Các nhà cung cấp dịch vụ sẽ được biết là quyền cắt miếng, ví dụ, vì nó đã được trước đó chứng thực và sau đó đăng ký như một người sử dụng PlanetLab. Trong thực tế, Phòng thí nghiệm người dùng liên lạc với một cơ quan lát bằng phương tiện của một dịch vụ trên nền Web. Xa hơn chi tiết có thể tìm thấy tại Chun và Spalink (2003). Những gì thủ tục này cho thấy là việc quản lý PlanetLab được thực hiện thông qua các liên các vách. Một điều quan trọng của lớp trung gian như vậy được hình thành bởi tác giả của phần quan hệ. Chính quyền như vậy đã thu được chứng tại các nút để tạo slide. Việc Lấy những trọng đã đạt được thoát khỏi băng dài, về cơ bản bằng cách liên lạc hệ thống quản trị tại các trang web khác nhau. Rõ ràng, đây là thời gian tiêu tốn quá trình mà không được thực hiện bởi người dùng cuối (hoặc, trong PlanetLab thuật ngữ; cung cấp dịch vụ ) Bên cạnh đó chính quyền cắt miếng, cũng có quyền quản lý. Trường hợp một lát thẩm quyền chỉ tập trung vào việc quản lý lát, một cơ quan quản lý được tái sponsible để giữ một mắt trên nút. Đặc biệt, nó đảm bảo rằng các nút dưới chế độ của nó chạy phần mềm PlanetLab cơ bản và tuân thủ các quy tắc đặt ra bởi PlanetLab. Dịch vụ cung cấp tin tưởng rằng một cơ quan quản lý cung cấp các nút mà sẽ hành xử đúng PROCESSES Tổ chức này dẫn đến cơ cấu quản lý thể hiện trong hình. 3-16 miêu tả về mối quan hệ tin cậy trong Peterson et at (2005). Các mối quan hệ như sau: 1. Chủ một nút đặt nút của mình theo chế độ quản lý một thẩm quyền, có thể hạn chế việc sử dụng khi thích hợp. 2. Một cơ quan quản lý cung cấp các phần mềm cần thiết để thêm một nút để PlanetLab. 3. Một nhà cung cấp dịch vụ đăng ký chính nó với một cơ quan quản lý. tin tưởng nó để cung cấp các nút có hành vi tốt. 4. Một dịch vụ liên lạc với nhà cung cấp một cơ quan lát để tạo ra một lát trên một bộ sưu tập các nút. 5. Cơ quan chức slice nhu cầu để xác thực các nhà cung cấp dịch vụ. 6. Chủ một nút cung cấp một dịch vụ sáng tạo slice cho một cơ quan lát để tạo lát. Nó về cơ bản các đại biểu đến quản lý khoanh tài nguyên thẩm quyền. 7. Một cơ quan quản lý các đại biểu việc tạo ra một lát để lát thẩm quyền. Những mối quan hệ trải các vấn đề của Uỷ thác các nút trong một cách kiểm soát sao cho một chủ sở hữu nút có thể dựa vào một phong nha quản lý và an toàn. Thứ hai vấn đề đó cần phải được xử lý là theo dõi. Những gì cần thiết là một cách tiếp cận thống nhất cho phép người dùng xem như thế nào chương trình của họ đã cư xử trong một lát cụ thể. PlanetLab sau một phương pháp đơn giản. Mỗi nút được trang bị một bộ sưu tập các bộ cảm ứng, mỗi bộ cảm biến có khả năng được báo cáo thông tin như CPU cách sử dụng, đĩa hoạt động, vv. Cảm biến có thể được tùy tiện phức tạp, nhưng vấn đề quan trọng là, họ luôn luôn báo cáo thông tin trên một cơ sở pernode. Thông tin này được làm sẵn bằng các phương tiện của một máy chủ web: mỗi cảm biến là cho phép truy nhập đơn giản các yêu cầu HTTP (Bavier et at, 2004). Phải thừa nhận rằng, cách tiếp cận này để giám sát vẫn còn khá thô sơ, nhưng nó shouldbe coi là một cơ sở cho các chương trình giám sát tiên tiến . Ví dụ, có được, trong nguyên tắc, không có lý do tại sao kế thiên, mà chúng tôi thảo luận trong Chương 2, không thể được được sử dụng để đọc cảm biến tập hợp các nút trên nhiều. Cuối cùng, đến vấn đề quản lý thứ ba của chúng tôi, cụ thể là sự bảo vệ của các chương trình với nhau, PlanetLab sử dụng Linux máy chủ ảo (được gọi là vservers) để cô lập một lát. Như đã nói, ý tưởng chính của vserver một là để chạy các ứng dụng trong Chroot. có riêng của môi trường, bao gồm tất cả các tập tin mà thường được chia sẻ trên máy asingle. Như một ly thân có thể đạt được tương đối dễ dàng bằng phương tiện của UNIX chroot lệnh, trong đó có hiệu quả các thay đổi thư mục gốc của ứng dụng tập tin từ nơi hệ thống sẽ xem xét cho các tập tin. Chỉ có giám sát có thể thực thi Tất nhiên, hơn là cần thiết. Linux máy chủ ảo, không chỉ riêng hệ thống tập tin, nhưng cũng thường được chia sẻ thông tin về quy trình, địa chỉ mạng, bộ nhớ sử dụng, và do đó 011. Kết quả là, một máy vật lý thực sự là phân vùng thành nhiều đơn vị, mỗi đơn vị tương ứng với một môi trường đầy đủ Linux fledged, bị cô lập từ các bộ phận khác. Tổng quan về Linux máy chủ ảo có thể được tìm thấy trong Potzl et al. (2005). 3.5 CODE MIGRATION Cho đến nay, chúng tôi đã được chủ yếu liên quan với các hệ thống phân phối, trong đó giao tiếp được giới hạn qua dữ liệu. Tuy nhiên, có những tình huống mà chương trình đi qua, đôi khi ngay cả trong khi họ đang được thực thi, đơn giản hoá thiết kế của một hệ thống phân phối. Trong phần này, chúng ta hãy xem chi tiết ở những gì. Mã di cư là thực sự. Chúng tôi bắt đầu bằng cách xem xét các cách tiếp cận khác nhau để mã di cư, theo sau một cuộc thảo luận về cách đối phó với các nguồn lực của địa phương mà một di cư sử dụng chương trình. Một vấn đề đặc biệt khó khăn được di chuyển mã trong dị tổng quát hệ thống, cũng là thảo luận. 3.5 CODE MIGRATION 3.5.1 Approaches to Code Migration Trước khi xem xét các hình thức khác nhau của việc di chuyển mã, cho chúng con đầu tiên Sider lý do tại sao nó có thể hữu ích để di chuyển mã. Lý do cư Mã Theo truyền thống, mã di chuyển trong hệ thống phân phối đã diễn ra dưới hình thức di chuyển quá trình mà trong đó một toàn bộ quá trình đã được chuyển từ một máy tính để khác (Milojicic et al, 2000.). Di chuyển một quá trình chạy đến một máy khác nhau.là một công việc tốn kém và phức tạp, và có tốt hơn có thể là một lý do chính đáng để làm như vậy. Đó là lý do luôn luôn thực hiện được. Ý tưởng cơ bản là hệ thống tổng thể hiệu suất có thể được cải thiện nếu các quy trình được di chuyển từ nặng nề nạp để nhẹ nạp máy. liên quan đến số lượng lớn dữ liệu, có thể tốt hơn để tàu một phần của ứng dụng khách đến máy chủ và gửi chỉ được kết quả trên mạng. Nếu không, các mạng có thể được với việc chuyển giao các dữ liệu từ máy chủ cho khách hàng. Trong trường hợp này, việc di chuyển mã được dựa trên giả thiết rằng nó thường làm cho cảm giác để xử lý dữ liệu gần nơi các dữ liệu cư trú. Vì lý do này cùng có thể được sử dụng để di chuyển các bộ phận của máy chủ cho khách hàng. Ví dụ, trong nhiều ứng dụng cơ sở dữ liệu tương tác, khách hàng cần phải điền vào các mẫu đơn mà sau đó được dịch ra một loạt các hoạt động cơ sở dữ liệu. Chế biến hình thức ở phía khách hàng, và chỉ gửi các hình thức hoàn thành đến máy chủ, có thể đôi khi tránh rằng một số lượng tương đối lớn của bài viết nhỏ cần phải chéo mạng. Kết quả là khách hàng nhận thức hiệu quả cao hơn, trong khi ở cùng một thời gian máy chủ dành thời gian hơn cho hình thức xử lý và giao tiếp. Tải xuống thường được bày tỏ trong điều khoản của hàng đợi CPU chiều dài hoặc sử dụng CPU, nhưng các chỉ số hoạt động khác được sử dụng như là tốt. Tải xuống thuật toán phân phối bởi các quyết định đó được thực hiện liên quan đến việc phân bổ và tái phân phối các nhiệm vụ đối với một bộ vi xử lý, đóng một vai trò quan trọng trong việc tính toán các hệ thống chuyên sâu. Tuy nhiên, trong nhiều modem phân phối hệ thống, tối ưu hóa khả năng tính toán là một vấn đề ít hơn, ví dụ, cố gắng để giảm thiểu giao tiếp. Hơn nữa, do tinhs hỗn tạp của lớp dưới nền tảng và mạng máy tính, hiệu suất cải tiến thông qua việc di chuyển mã thường được dựa trên lý luận chất lượng thay vì mô hình toán học. Xem xét, như là một ví dụ, một khách hàng-máy chủ, trong đó hệ thống máy chủ quản lý một cơ sở dữ liệu khổng lồ. Nếu một ứng dụng khách hàng cần thực hiện nhiều hoạt động cơ sở dữ liệu Hỗ trợ cho việc di chuyển mã cũng có thể giúp cải thiện hiệu suất bằng cách khai thác song song, nhưng mà không có rắc rối thông thường liên quan đến lập trình song song. Ví dụ điển hình là tìm kiếm thông tin trong trang Web. Nó là tương đối đơn giản để thực hiện truy vấn tìm kiếm theo hình thức một chương trình điện thoại di động nhỏ, gọi là một đại lý điện thoại di động, mà di chuyển từ trang web đến trang web. Bằng cách làm bản sao của một vài chương trình như vậy, và gửi mỗi tắt đến các trang web khác nhau, chúng tôi có thể đạt được tốc độ tuyến tính so với việc sử dụng chỉ là một ví dụ chương trình duy nhất. Bên cạnh việc cải thiện hiệu suất, có những lý do khác để hỗ trợ di chuyển mã là tốt. Một điều quan trọng nhất là tính linh hoạt. Các truyền thống thích hợp để xây dựng các ứng dụng phân phối là phân vùng các ứng dụng thành phần khác nhau, và quyết định trước mỗi nơi một phần cần được thực thi. Cách tiếp cận này, ví dụ, đã dẫn đến những khách hàng khác nhau máy chủ đa ứng dụng thảo luận trong Chương. 2. Tuy nhiên, nếu mã có thể di chuyển giữa các máy khác nhau, nó sẽ trở thành có thể để tự động cấu hình hệ thống phân phối. Ví dụ, giả sử một máy chủ thực hiện một giao diện chuẩn hóa với một hệ thống tập tin. Để cho phép các khách hàng từ xa để truy cập vào hệ thống tập tin, máy chủ làm cho việc sử dụng một giao thức độc quyền. Bình thường, client-side thực hiện các giao diện hệ thống tập tin, mà là dựa trên đó giao thức, sẽ cần phải được liên kết với các ứng dụng của khách hàng. Phương pháp này đòi hỏi các phần mềm có sẵn cho khách hàng tại thời điểm áp dụng khách hàng này đang được phát triển. Một là để thay thế cho các máy chủ cung cấp cho việc thực hiện của khách hàng không sớm hơn là nghiêm chỉnh cần thiết, có nghĩa là, khi khách hàng liên kết với máy chủ. Tại điểm kia , khách hàng tự động tải thực hiện, đi qua khởi tạo các bước cần thiết, và sau đó gọi đến máy chủ. Mô tả này thể hiện trong hình. 317. Điều này mô hình tự động di chuyển mã từ một trang web từ xa không yêu cầu giao thức để tải về và mã khởi tạo được chuẩn hóa. Ngoài ra, nó là cần thiết rằng mã tải về có thể được thực thi trên máy của khách hàng. Các giải pháp khác nhau được thảo luận dưới đây và trong chương sau. Lợi thế quan trọng của mô hình này của động tải phần mềm phía khách hàng là các khách hàng không cần phải có tất cả các phần mềm cài đặt sẵn để nói chuyện với máy chủ. Thay vào đó, các phần mềm có thể được di chuyển trong khi cần thiết, và cũng vậy, bỏ đi khi không còn cần thiết. Lợi thế khác là khi các giao diện được tiêu chuẩn hóa, chúng tôi có thể thay đổi giao thức client-server và thực hiện của nó thường xuyên như chúng ta muốn. Thay đổi sẽ không ảnh hưởng đến khách hàng hiện tại rằng các ứng dụng dựa trên máy chủ. Có, tất nhiên, cũng có nhược điểm. Một nghiêm trọng nhất, mà chúng tôi thảo luận trong Chap. 9, đã làm với an ninh. Mù quáng tin tưởng rằng được tải xuống mã thực hiện chỉ giao diện được quảng cáo trong khi truy cập vào ổ đĩa cứng của bạn không được bảo vệ và không gửi những phần juiciest để trời biết ai có thể không phải luôn luôn được như vậy là một ý tưởng tốt. Models for Code Migration Mặc dù việc di chuyển mã cho thấy rằng chúng tôi chỉ có mã di chuyển giữa các máy móc, thuật ngữ này thực sự bao gồm một khu vực rất phong phú hơn. Theo truyền thống, giao tiếp trong các hệ thống phân phối là có liên quan với trao đổi dữ liệu giữa các quá trình. Mã số di chuyển trong các thỏa thuận nghĩa rộng với các chương trình di chuyển giữa các máy móc, với ý định để có những chương trình được thực hiện tại mục tiêu. Trong một số trường hợp, như trong quá trình di chuyển, tình trạng thực hiện một chương trình, đang chờ xử lý tín hiệu, và các phần khác của môi trường phải được di chuyển là tốt.  Để có được một sự hiểu biết tốt hơn về các mô hình khác nhau cho việc di chuyển mã, chúng tôi sử dụng một khuôn khổ được mô tả trong Fuggetta et al. (1998). Trong khuôn khổ này, một quá trình bao gồm ba đoạn. Đoạn mã là phần có chứa tập các hướng dẫn tạo nên các chương trình đang được thực thi. Phân khúc tài nguyên chứa tham chiếu đến nguồn lực bên ngoài cần thiết. bởi quá trình, chẳng hạn như các tập tin, máy in, thiết bị, các quá trình khác, vv. Cuối cùng, một phân đoạn thi công được sử dụng để lưu trữ nhà nước thực hiện của một quá trình, bao gồm dữ liệu riêng, ngăn xếp, và tất nhiên, truy cập chương trình. Các tối thiểu cho việc di chuyển mã là cung cấp chỉ có tính di động yếu. Trong mô hình này, có thể chuyển nhượng chỉ có đoạn mã, cùng với một số dữ liệu có lẽ khởi. Một tính năng đặc trưng của tính di động yếu kém là một chương trình chuyển giao luôn luôn là bắt đầu từ một trong một số vị trí bắt đầu được xác định trước. Đây là những gì sẽ xảy ra, ví dụ, với Java applet, mà luôn luôn bắt đầu thực hiện từ đầu. Lợi ích của phương pháp này là đơn giản của nó. Yếu di động chỉ đòi hỏi rằng máy mục tiêu có thể thực thi mã, mà tính chất ": tially nắm để làm cho mã cầm tay. Chúng tôi trở về những vấn đề khi thảo luận về việc di chuyển trong các hệ thống đồng nhất. Trái ngược với tính di động yếu, trong các hệ thống có hỗ trợ tính di động mạnh mẽ các phân đoạn thực thi có thể được chuyển như là tốt. Các tính năng đặc trưng của mạnh tính di động là một quá trình có thể chạy được ngừng lại, sau đó chuyển sang máy khác, và sau đó tiếp tục thực hiện mà nó còn tắt. Rõ ràng, mạnh mẽ tính di động là tổng quát hơn nhiều so với tính di động yếu, nhưng cũng có nhiều khó khăn hơn để thực hiện. Không phân biệt hay không tính di động là yếu hay mạnh, một sự phân biệt hơn nữa có thể được giữa người gửi và người nhận thực thực di dân. Trong người gửi thực di chuyển, di cư được khởi xướng tại máy nơi mã hiện tại cư trú hoặc đang được thực thi. Thông thường, người gửi thực di chuyển được thực hiện khi tải lên các chương trình tính toán đến một máy chủ. Một ví dụ khác là việc gửi một tìm kiếm chương trình qua mạng Internet đến một máy chủ cơ sở dữ liệu Web để thực hiện truy vấn tại máy chủ đó. Trong nhận thực di dân, các sáng kiến cho việc di chuyển mã là thực hiện bởi các máy mục tiêu. Java applet là một ví dụ về cách tiếp cận này. Nhận - khởi xướng việc di chuyển đơn giản hơn người gửi bắt đầu di chuyển. Trong nhiều trường hợp, mã di chuyển xảy ra giữa khách hàng và một máy chủ, nơi mà các khách hàng mất những sáng kiến để di chuyển. Bảo mật mã để tải lên một máy chủ, như được thực hiện ở người gửi thực di dân, thường được yêu cầu của khách hàng trước đây đã đăng ký và xác thực tại máy chủ đó. Nói cách khác, máy chủ được yêu cầu để biết tất cả khách hàng của mình, lý do là là khách hàng có lẽ sẽ muốn truy cập để nguồn tài nguyên của máy chủ như là đĩa của nó. Bảo vệ tài nguyên như vậy là rất cần thiết. Ngược lại, tải mã như trong trường hợp tiếp nhận thực, thường có thể được thực hiện nặc danh. Ngoài ra, máy chủ thường không quan tâm đến nguồn lực của khách hàng. Thay vào đó, mã di chuyển cho khách hàng được thực hiện chỉ dành cho việc cải thiện hiệu suất phía khách hàng. Cuối cùng, chỉ có một số giới hạn các tài nguyên cần được bảo vệ, chẳng hạn như bộ nhớ và kết nối mạng. Chúng tôi trở về an toàn mã di chuyển rộng rãi tại các Chap. 9. Trong trường hợp của tính di động yếu, nó cũng tạo ra một sự khác biệt nếu mã di cư là thực hiện bởi quá trình mục tiêu, hoặc xem một quá trình riêng biệt được bắt đầu. Ví dụ, Java applet chỉ đơn giản là tải về bằng một trình duyệt Web và được thực hiện trong của trình duyệt không gian địa chỉ. Lợi ích của phương pháp này là không cần phải bắt đầu một quá trình riêng biệt, do đó tránh giao tiếp tại máy mục tiêu. Hạn chế chính là quá trình mục tiêu cần phải được bảo vệ chống lại án tử mã độc hoặc vô ý. Một giải pháp đơn giản là để cho hệ điều hành chăm sóc đó bằng cách tạo ra một quá trình riêng biệt để thực thi mã di chuyển. Lưu ý rằng giải pháp này không giải quyết được vấn đề truy cập tài nguyên đã đề cập ở trên. Họ vẫn phải bị xử lý với.thay cho của di chuyển một quá trình chạy, cũng được gọi là quá trình di chuyển, tính di động mạnh mẽ cũng có thể được hỗ trợ bởi nhân bản từ xa. Trái ngược với quá trình di dân, nhân bản sản lượng một bản sao chính xác của quá trình ban đầu, nhưng bây giờ đang chạy trên một máy tính khác nhau. Quá trình nhân bản được thi hành tại song song với bản gốc quá trình. Trong các hệ thống UNIX, nhân bản từ xa diễn ra bởi phân nhánh tắt một quá trình con và cho rằng con em tiếp tục trên một máy tính từ xa. Lợi ích của nhân bản là rằng mô hình gần giống với một trong đó đã được sử dụng trong rất nhiều sự khác biệt chỉ là các ứng dụng .cho rằng quá trình nhân bản được thực thi trên một máy khác nhau. Trong ý nghĩa này, di chuyển bằng cách nhân bản là một cách đơn giản để cải thiện tính minh bạch phân phối. Những lựa chọn thay thế khác nhau cho việc di chuyển mã được tóm tắt trong Hình. 3-18. 3.5.2 Tài nguyên cục bộ và tài nguyên di trú Chỉ có mã di trú và các phần thực thi(execution segment) được thực hiện … Phân đoạn tài nguyên đòi hỏi những sự chú ý đặc biệt. Điều khó khăn thường gặp khi thực hiện di trú mã đó là phân đoạn tài nguyên không phải luôn dễ dàng được chuyển đi cùng các phân đoạn khác mà không bị thay đổi. Ví dụ, giả sử rằng một tiến trình nắm giữ một tham chiếu tới một cổng TCP mà qua đó nó giao tiếp với các tiến trình khác. Do một tham chiếu được giữ trong phân đoạn tài nguyên của nó, khi tiến trình di chuyển sang vị trí khác, nó sẽ phải từ bỏ cổng cũ và yêu cầu một cổng mới ở vị trí mới. Để hiểu sự hàm ý mà di trú mã có trong phân đoạn tài nguyên, Fuggetta et al (1998) phân biệt 3 loại ràng buộc tiến trình- tài nguyên. Loại ràng buộc mạnh nhất là khi một tiến trình đòi hỏi tài nguyên dựa vào định danh của nó. Trong trường hợp đó, tiến trình sẽ yêu cầu chính xác tài nguyên tham chiếu, ngoài ra không còn yêu cầu gì khác. Một ví dụ của ràng buộc bởi định danh là khi một tiến trình sử dụng một VRL để yêu cầu một Web site cụ thể nào đó hoặc yêu cầu tới một FrP server bởi địa chỉ Internet của server đó. Với cùng nguyên nhân đó, những tham chiếu tới các điểm giao tiếp cục bộ cũng dẫn tới ràng buộc bởi định danh. Một dạng ràng buộc tiến trình – tài nguyên yếu hơn là khi chỉ giá trị của tài nguyên được yêu cầu. Trong trường hợp đó, sự thực thi của tiến trình sẽ không bị ảnh hưởng nếu các tài nguyên khác cũng cung cấp cùng một giá trị. Một ví dụ cho ràng buộc bởi giá trị là khi một chương trình dựa trên các thư viện chuẩn, như lập trình C hoặc Java chẳng hạn. Các thư viện này luôn tồn tại ở cục bộ, nhưng vị trí chính xác của chúng trong hệ thống file cục bộ có thể khác nhau giữa các site khác nhau. Nội dung của chúng rất quan trọng cho việc thực thi chính xác của các tiến trình. Cuối cùng, dạng ràng buộc yếu nhất là khi một tiến trình chỉ yêu cầu một loại nhất định nào đó của tài nguyên.Ràng buộc bởi loại đơn giản nhất đó là tham chiếu tới các thiết bị cục bộ, như màn hình, máy in,… Khi di trú mã, chúng ta thường cần thay đổi tham chiếu tới các tài nguyên, nhưng không thể làm ảnh hưởng tới loại ràng buộc tiến trình – tài nguyên. Một tham chiếu được thay đổi chính xác như thế nào, phụ thuộc vào tài nguyên được di chuyển cùng với mã tới máy đích. Cụ thể hơn, chúng ta cần quan tâm tới ràng buộc tài nguyên – máy, và phân biệt các trường hợp khác nhau.Tài nguyên tách rời có thể dễ dàng di chuyển giữa các máy khác nhau, và là các file cụ thể chỉ liên quan đến chương trình được di trú. Ngược lại, di chuyển hay sao chép một tài nguyên gắn kết là có thể, nhưng phải tốn chi phí rất cao. Ví dụ về tài nguyên gắn kết đó là các cơ sở dữ liệu cục bộ và những Web site hoàn chỉnh. Mặc dù các tài nguyên, xét về lý thuyết, không phụ thuộc vào máy chứa nó, nhưng thường là không thể di chuyển chúng tới môi trường khác. Cuối cùng, tài nguyên cố định được gắn kết cố định với một máy tính hoặc môi trường cụ thể và không thể bị di chuyển. Tài nguyên cố định thường là các thiết bị cục bộ. Một ví dụ khác của tài nguyên cố định đó là các điểm truyền thông cục bộ. Kết hợp 3 loại ràng buộc tiến trình – tài nguyên, và 3 loại ràng buộc tài nguyên – máy tính, dẫn tới 9 kết hợp ta cần quan tâm khi thực hiện di trú mã. 9 kiểu kết hợp này được chỉ ra trong hình 3-19 Trước hết chúng ta quan tâm tới khả năng một tiến trình được gắn với tài nguyên bởi định danh. Khi tài nguyên bị tách rời, điều tốt nhất là di chuyển nó cùng với mã di trú. Tuy nhiên, khi tài nguyên được chia sẻ bởi các tiến trình khác, một lựa chọn khác là thiết lập một tham chiếu toàn cục, một tham chiếu có thể sử dụng ngoài giới hạn của một máy đơn lẻ. Một ví dụ của một tham chiếu toàn cục đó là một URL. Khi tài nguyên được gắn kết hoặc cố định, giải pháp tốt nhất đó là tạo ra một tham chiếu toàn cục. Một điều quan trọng cần nhận ra là việc thiết lập một tham chiếu toàn cục phức tạp hơn là việc sử dụng URLs, và việc sử dụng một tham chiếu toàn cục đôi khi rất tốn kém. Ta hãy ví dụ, một chương trình tạo ảnh chất lượng cao cho một máy trạm đa phương tiện chuyên dụng. Việc tạo ảnh chất lượng cao trong thời gian thực là một nhiệm vụ đòi hỏi tính toán rất lớn, cho nên chương trình đó nên được chuyển tới một máy chủ tính toán hiệu năng cao. Thiết lập một tham chiếu toàn cục tới một máy trạm đa phương tiện nghĩa là thiết lập một đường truyền thông giữa máy chủ tính toán và máy trạm. Thêm vào đó, còn có quá trình xử lý tiní hiệu ở đồng thời cả máy chủ và máy trạm để đạt tới yêu cầu về băng thông cho truyền tải ảnh. Kết quả là việc chuyển chương trình sang máy chủ tính toán không phải là một ý hay, chỉ bởi vì chi phí của tham chiếu toàn cục là quá cao. Một ví dụ khác cho việc không phải lúc nào cũng có thể thiết lập tham chiếu toàn cục một cách dễ dàng khi di trú một tiến trình có sử dụng một điểm truyền thông cuối cục bộ. Trong trường hợp đó, ta phải xử lý một tài nguyên cố định mà theo đó tiến trình được giới hạn bởi định danh. Có hai giải pháp cơ bản. Một giải pháp đó là để cho tiến trình thiết lập một kết nối tới máy tài nguyên sau khi nó được di trú và cài đặt một tiến trình riêng biệt ở máy tài nguyên để làm nhiệm vụ đơn giản là chuyến tiếp tất cả các thông điệp gửi đến. Điểm hạn chế chính của cách này là nếu như máy tính tài nguyên gặp sự cố thì việc giao tiếp với tiến trình di trú sẽ bị thất bại. Giải pháp thứ hai đó là cho tất cả các tiến trình có giao tiếp với tiến trình di trú thay đổi tham chiếu toàn cục của chúng, và sau đó gửi thông điệp tới điểm cuối truyền thông mới trên máy đích. Tình hình sẽ khác đi trong trường hợp xử lý ràng buộc bởi giá trị. Trước hết hãy xét một tài nguyên cố định. Sự kết hợp của một tài nguyên cố định và ràng buộc bởi giá trị xảy ra, ví dụ khi một tiến trình chiếm bộ nhớ được chia sẻ giữa các tiến trình. Thiết lập một tham chiếu toàn cục trong trường hợp này nghĩa là chúng ta cần thiết lập một dạng phân tán của bộ nhớ chia sẻ. Trong nhiều trường hợp, đây không thực sự là một giải pháp khả thi. Tài nguyên gắn kết thường được quy với giá trị của chúng, thường là các thư viện runtime. Thông thường, các bản sao của các tài nguyên đó đã có ở trên máy đich, hoặc nên được sao chép trước khi di trú mã được thực hiện. Thiết lập một tham chiếu toàn cục là cách tốt hơn khi lượng lớn dữ liệu được sao chép, như trường hợp từ điển trong các hệ thống xử lý văn bản. Trường hợp dễ nhất là khi xử lý với các tài nguyên tách rời. Giải pháp tốt nhất đó là sao chép (hoặc di chuyển) tài nguyên tới đích mới, trừ khi nó được chia sẻ bởi một số tiến trình. Trong các trường hợp khác, thiết lập một tham chiếu toàn cục là lựa chọn duy nhất. Trường hợp cuối cùng là xử lý ràng buộc bởi loại. Không kể đến ràng buộc tài nguyên – máy tính, các giải pháp trước đó cố tái liên kết tiến trình với một tài nguyên cục bộ có sẵn cùng loại. Chỉ khi một tài nguyên không tồn tại, ta mới cần sao chép hoặc di chuyển nguyên gốc tới đích mới, hoặc thiết lập một tham chiếu toàn cục. 3.5.3 Di trú trong các hệ thống hỗn tạp Cho tới giờ, chúng ta ngầm định rằng các mã di trú có thể được thực thi dễ dàng ở máy đích. Giả định này được coi là hợp lệ khi xử lý với các hệ thống hỗn tạp. Một cách tổng quát, dĩ nhiên, các hệ phân tán được cấu trúc bởi một tập các platform hỗn tạp, đều có hệ điều hành riêng và kiến trúc máy tính riêng. Di trú trong mỗi hệ thống đó đòi hỏi mỗi platform được hỗ trợ, theo đó, mọt phân đoạn mã có thể được thực thi trên từng platform. Mặt khác, chúng ta cũng cần đảm bảo phân đoạn mã có thể tương ứng với mỗi platform. Các vấn đề đối với tính hỗn tạp trong nhiều khía cạnh giống với vấn đề về tính di động. Không ngạc nhiên khi các giải pháp có phần tương đồng. Ví dụ, cuối những năm 1970, một giải pháp đơn giản để giảm thiểu các vấn đề Pascal giữa các máy khác nhau là tạo ra mã tức thì độc lập với máy tính cho các máy ảo trừu tượng (Barron 1981). Các máy ảo đó, không cần phải cài đặt trên các platform, nhưng nó vẫn cho phép các chương trình Pascal có thể chạy ở bất cứ đâu. Mặc dù ý tưởng đơn giản này được sử dụng rộng rãi trong nhiều năm, nó chưa bao giờ được coi là một giải pháp cơ bản đê giải quyết vấn đề di động cho các ngôn ngữ khác, nhất là C. Khoảng 25 năm sau, di trú mã trong các hệ thống hỗn tạp bị tấn công bởi các ngôn ngữ script và ngôn ngữ có tính di động cao như Java. Về thực chất, những giải pháp này cũng áp dụng cách giống như đã làm với di trú Pascal. Tất cả các giải pháp này đều có điểm chung là dựa vào một máy ảo để biên dịch trực tiếp mã nguồn (như trong trường hợp của các ngôn ngữ script), hoặc các biên dịch các mã được sinh ra bởi một trình biên dịch (như trong Java). Các phát triển gần đây đã bắt đầu làm yếu đi tính phụ thuộc vào các ngôn ngữ lập trình. Cá biệt, các giải pháp đề xuất không chỉ di trú tiến trình, mà còn di trú toàn bộ môi trường tính toán. Ý tưởng cơ bản là phân chia toàn bộ môi trường và cung cấp các tiến trình trong cùng một phần tầm nhìn của chúng trong môi trường tính toán. Nếu việc phân chia được làm chính xác, nó dẫn tới khả năng có thể nhân đôi một phần từ hệ thống cơ sở và di trú tới một máy khác. Theo cách này, di trú thực sự cung cấp một form di động mạnh cho các tiến trình, chúng có thể được di chuyển ở mọi thời điểm thực thi, và tiếp tục khi di trú xong. Hơn nữa, nhiêu vấn đề khó hiểu liên quan đến tiến trình di trú khi chúng được gắn kết với các tài nguyên cục bộ có thể được giải quyết, các gắn kết này trong nhiều trường hợp đã được dự trữ sẵn. Các tài nguyên cục bộ thường là một phần của môi trường được di trú. Có một vài nguyên nhân cho việc di trú môi trường, nhưng dĩ nhiên điều quan trọng nhất là cho phép sự tiếp tục hoạt động khi một máy tính shutdown. Ví dụ, trong một cluster server, quản trị hệ thống có thể quyết định cho shutdown hoặc thay thế một máy tính, nhưng sẽ không phải ngừng tất cả các tiến trình đang chạy của nó. Thay vào đó, có thể tạm thời đóng băng môi trường, chuyển nó tới một máy khác và mở đóng băng trở lại. Đó thực sự là một cách mạnh mẽ để quản lý môi trường tính toán và các tiến trình của chúng. Ta hãy xét một ví dụ cụ thể về di trú máy ảo, như đã được đề cập trong Clark et al (2005). Trong trường hợp này, tác giả tập trung vào di trú thời gian thực của một hệ điều hành ảo, thường là sẽ thuận lợi trong một cluster server khi liên kết chặt chẽ đạt tới thông qua một mạng cục bộ đơn và có chia sẻ. Trong các tình huống này, di trú sẽ có 2 vấn đề cơ bản: di trú toàn bộ ảnh bộ nhớ và di trú liên kết tới tài nguyên cục bộ. Với vấn đề đầu tiên, trong lý thuyết, ta có 3 cách đề quản lý di trú Đẩy các trang bộ nhớ vào máy mới và gửi lại những trang đã được chỉnh sửa sau trong suốt tiến trình di trú. Ngừng máy ảo hiện thời, di trú bộ nhớ, và khởi tạo máy ảo mới. Để máy ảo mới yêu cầu mọt trang mới nếu cần, ta sẽ để các tiến trình khởi đầu trên máy ảo mới ngay lập tức Lựa chọn thứ hai có thể dẫn tới thời gian downtime không chấp nhận được nếu các máy ảo di trú đang chạy live service, nghĩa là các dịch vụ đòi hỏi tính tiếp diễn liên tục. Mặt khác, một cách tiếp cận on-demand thuần túy được giới thiệu bởi lựa chọn thứ ba có thể kéo dài chu kỳ di trú, nhưng sẽ dẫn tới hiệu năng thấp vì sẽ tốn kém nhiều thời gian trước khi làm việc với các tiến trình di trú được di chuyển tới máy mới. Như một lựa chọn khác, Clark et al (2005) đè xuất sử dụng cách tiền sao chép khi kết hợp lựa chọn đầu tiên, kèm theo một pha stop-and-copy như giới thiệu trong lựa chọn thứ hai. Kết quả của sự kết hợp này có thể dẫn tới thời gian downtime khoảng 200ms hoặc ít hơn. Liên quan đến tài nguyên cục bộ, vấn đề được đưa ra khi xử lý với một cluster server. Đầu tiên, bởi vì chỉ có một mạng đơn lẻ, điều cần làm chỉ là thông báo về sự gắn kết mới giữa mạng và địa chỉ MAC, để cho client có thể liên hệ các tiến trình di trú ở đúng card mạng. Hiệu quả tổng thể đó là, thay vì di trú tiến trình, chúng ta thực sự có thể thấy toàn bộ một hệ điều hành có thể được di chuyển giữa các máy tính khác nhau. 3.6 Summary Các tiến trình đóng một vai trò cơ bản trong các hệ phân tán khi chúng tạo ra một nền tảng cho truyền thông giữa các máy tính khác nhau. Một vấn đề quan trọng là các tiến trình được tổ chức cục bộ như thế nào, và cá biệt, chúng có hỗ trợ đa luồng điều khiển hay không. Các luồng trong hệ phân tán thường rất hữu ích khi tiếp tục sử dụng CPU khi một hoạt động khóa vào ra được thực hiện. Theo cách này, rất khả thi khi có thể xây dựng một server hiệu quả cao có thể chạy đa luồng song song, một số có thể khóa lại đẻ chờ tới khi vào ra đĩa hoặc truyền thông mạng hoàn thành. Tổ chức một hệ phân tán theo nghĩa client và server đã chứng tỏ sự hữu dụng. Các tiến trình client thường thiết lập giao diện người dùng, có thể từ các cách hiển thị rất đơn giản cho đến các giao diện cao cấp hơn có thể xử lý các văn bản phức hợp. Phần mềm client nhằm vào tính phân tán trong suốt bằng cách ẩn giấu các chi tiết liên quan đến giao tiếp với server, khi các server này được định vị, và các server này có được sao chép hay không. Thêm vào đó, phần mềm client chịu trách nhiệm trong việc che giấu lỗi và phục hồi từ lỗi. Các server thì thường phức tạp hơn client, nhưng tuy nhiên thường chỉ lệ thuộc vào một số ít vấn đề về thiết kế. Ví dụ, các server có thể lặp lại hoặc đồng thời thiết lập một hoặc nhiều dịch vụ, và có thể stateless hoặc stateful. Một số cách thiết kế khác sử dụng cơ chế hay dịch vụ đánh địa chỉ để ngắt một server sau khi một yêu cầu dịch vụ được tiếp nhận và có thể vẫn đang được xử lý. Một số điều đặc biệt cần chú ý khi tổ chức server thành một cluster. Nhiệm vụ chung đó là che giấu nội bộ của một cluster với thế giới bên ngoài. Điều đó có nghĩa là tổ chức của một cluster nên được bao bọc bởi ứng dụng. Hầu hết các cluster đều sử dụng một điểm đơn để tiếp nhận các thông điệp gửi đến server trong cluster. Vấn đề đặt ra đó là sự thay thế trong suốt điểm đơn này với một giải pháp phân tán toàn diện. Một chủ đề quan trọng cho các hệ phân tán là di trú mã giữa các máy khác nhau. Hai nguyên nhân quan trọng để hỗ trợ di trú mã là tăng hiệu năng và tính linh hoạt. Khi truyền thông tốn kém, chúng ta có thể giảm chi phí bằng cách chuyển bớt tính toán từ server sang các client, và đề cho client thực hiện tính toán cục bộ các nhiều càng tốt. Tính linh hoạt tăng lên nếu một client có thể tự động download phần mềm cần thiết dể giao tiếp với server nhất định. Phần mềm được download có thể định hướng sẵn tới server, mà không cần client phải cài đặt trước. Di trú mã mang tới những vấn đề liên quan tới sử dụng tài nguyên cục bộ mà theo đó yêu cầu các tài nguyên khác được di trú, gắn kết mới với tài nguyên cục bộ ở máy đích được thiết lập, hoặc các tham chiếu toàn cục được sử dụng. Một vấn đề khác là di trú mã đòi hỏi tính hỗn tạp trong tài khoản. Các thí nghiệm hiện tại đưa ra phương án tốt nhất dể xử lý tính hỗn tạp đó là sử dụng các máy ảo.