Baskara Blog

3.1 THREADS
   Meskipun proses membentuk sebuah blok diagram dalam sistem terdistribusi, pada prakteknya menunjukkan bahwa rincian dari proses seperti yang disediakan oleh sistem operasi pada sistem terdistribusi yang dibangun tidak cukup. Sebaliknya, ternyata bahwa dengan memiliki rincian yang lebih baik dalam bentuk beberapa thread kontrol per proses membuat lebih mudah untuk membangun aplikasi terdistribusi dan untuk mencapai kinerja yang lebih baik. dalam bagian ini, kita melihat lebih dekat pada peran thread dalam sistem terdistribusi dan menjelaskan mengapa mereka begitu penting. Terebih pada thread dan bagaimana mereka dapat digunakan untuk membangun aplikasi dapat ditemukan dalam Lewis dan Berg (998) dan Stevens (1999).



3.1.1 Introduction to Threads
   Untuk memahami peran thread dalam sistem terdistribusi, penting untuk memahami apa suatu proses, dan bagaimana proses dan benang berhubungan. Untuk mengeksekusi sebuah Program, sebuah sistem operasi menciptakan sejumlah prosesor virtual, masing-masing untuk menjalankan program yang berbeda. Untuk melacak prosesor virtual, operasi sistem memiliki tabel proses, mengandung catatan untuk menyimpan daftar nilai CPU , memori peta, file terbuka, informasi akunting. Hak istimewa, dll Suatu proses sering didefinisikan sebagai sebuah program dalam eksekusi, yaitu, sebuah program yang saat ini sedang dieksekusi di salah satu prosesor virtual sistem operasi. Suatu hal yang penting adalah bahwa sistem operasi membutuhkan perhatian besar untuk memastikan bahwa proses yang independen tidak bisa merugikan atau tidak sengaja mempengaruhi ketepatan dari perilaku masing-masing. Dengan kata lain, bahwa beberapa proses dapat dirangkap dibagi CPU yang sama dan sumber daya perangkat keras lainnya dibuat transparan. Biasanya, operasi sistem memerlukan dukungan hardware untuk melaksanakan pemisahan ini.
   Transparansi Hal ini konkurensi membutuhkan biaya yang relatif tinggi. Sebagai contoh, setiap kali sebuah proses dibuat, sistem operasi harus membuat lengkap ruang alamat yang independen. Alokasi dapat berarti menginisialisasi memori dengan segmen, misalnya, zeroing data segmen, menyalin program yang berkaitan ke dalam teks segmen, dan mengatur stack untuk data sementara. Demikian juga, CPU beralih antara dua proses mungkin relatif mahal juga. Selain dari penghematan CPU konteks (yang terdiri dari nilai-nilai , program counter, stack pointer, dll), sistem operasi juga akan harus memodifikasi register memori unit manajemen (MMU) dan cache membatalkan terjemahan alamat seperti di terjemahan lookaside buffer (TLB). Selain itu, jika sistem operasi mendukung proses lebih dari itu secara bersamaan dapat terus di memori utama, mungkin harus menukar proses antara memori utama dan disk sebelum beralih yang sebenarnya dapat mengambil tempat.
   Seperti proses, sepotong thread mengeksekusi kode sendiri, secara independen dari thread lainnya. Namun, berbeda dengan proses, tidak ada usaha dibuat untuk mencapai transparansi konkurensi tingkat tinggi jika ini akan mengakibatkan penurunan kinerja. Oleh karena itu, sistem benang umumnya hanya mempertahankan informasi minimum untuk memungkinkan CPU untuk digunakan bersama oleh beberapa thread. Secara khusus, konteks threads sering terdiri dari tidak lebih dari konteks CPU, bersama dengan beberapa informasi lain untuk manajemen thread. Sebagai contoh, sistem thread ini dapat terus melacak fakta bahwa thread saat ini diblokir pada variabel mutex, sehingga tidak pilih untuk eksekusi. Informasi yang tidak benar-benar diperlukan untuk mengelola beberapa thread umumnya diabaikan. Untuk alasan ini, melindungi data terhadap patut akses dengan thread dalam proses tunggal sepenuhnya diserahkan ke aplikasi pengembang.
   Ada dua implikasi penting dari pendekatan ini. Pertama-tama, kinerja dari aplikasi multithreaded hampir tidak pernah lebih buruk daripada pendamping single-threaded. Bahkan, dalam banyak kasus, multithreading mengarah pada keuntungan kinerja. Kedua, karena thread tidak secara otomatis dilindungi jalan prosesnya terhadap satu sama lain, pengembangan aplikasi multithreaded membutuhkan tambahan intelektual usaha. Tepat desain dan menjaga hal-hal sederhana.
Multithreading juga berguna dalam konteks aplikasi besar. seperti aplikasi yang sering dikembangkan sebagai kumpulan program yang bekerja sama, masing-masing untuk dieksekusi oleh proses yang terpisah. Pendekatan ini adalah khas untuk lingkungan UNIX.
Kerjasama antara program-program dilaksanakan dengan cara komunikasi interprocess (IPC) mekanisme. Untuk sistem UNIX, mekanisme ini biasanya mencakup (bernama) pipa, antrian pesan, dan segmen memori bersama, Kelemahan utama dari semua mekanisme IPC adalah bahwa komunikasi sering memerlukan konteks switching yang luas.

Thread Implementation
   Thread sering disediakan dalam bentuk paket Thread. Paket seperti ini berisi operasi untuk menciptakan dan menghancurkan thread serta operasi tentang sinkronisasi variabel seperti mutexes dan variabel kondisi. Pada dasarnya ada dua pendekatan untuk menerapkan paket Thread. Pendekatan pertama adalah untuk membangun library thread yang dieksekusi seluruhnya dalam mode pengguna. Pendekatan kedua adalah memiliki kernel harus menyadari thread dan jadwal mereka.
Sebuah perpustakaan Thread user-level memiliki sejumlah keunggulan. Pertama, itu murah untuk menciptakan dan menghancurkan thread. Karena semua administrasi thread disimpan dalam pengguna ruang alamat, harga menciptakan thread terutama ditentukan oleh biaya untuk mengalokasikan memori untuk mengatur tumpukan Thread. Analog, menghancurkan thread terutama melibatkan memori membebaskan untuk stack, yang tidak lagi digunakan. kedua operasi yang murah.

3.1.2 Threads in Distributed Systems
   Sebuah properti penting dari thread adalah bahwa mereka dapat menyediakan sarana yang mudah digunakan yang memungkinkan panggilan sistem memblokir tanpa menghalangi seluruh proses di mana thread berjalan. Properti ini membuat thread sangat menarik untuk digunakan dalam sistem terdistribusi karena membuat lebih mudah untuk mengekspresikan komunikasi dalam bentuk mempertahankan koneksi logis beberapa pada saat yang sama. Kami menggambarkan ini titik dengan melihat lebih dekat pada klien dan server multithreaded, masing-masing.

Multithreaded Clients
   Untuk membuat distribusi tingkat transparansi yang tinggi, sistem terdistribusi yang beroperasi di jaringan yang luas mungkin perlu untuk menyembunyikan pesan interprocess yang panjang perambatan waktu. Penundaan round-trip dalam jaringan area luas dengan mudah dapat dalam urutan ratusan milidetik. atau kadang-kadang bahkan detik.
   Cara biasa untuk menyembunyikan komunikasi latency adalah untuk memulai komunikasi dan segera melanjutkan dengan sesuatu yang lain. Sebuah contoh yang khas di mana hal ini terjadi dalam browser Web. Dalam banyak kasus, sebuah dokumen Web terdiri dari HTML file yang berisi teks biasa bersama dengan koleksi gambar, ikon, dll Untuk mendapatkan setiap elemen dari sebuah dokumen Web, browser harus mengatur koneksi TCPIIP, membaca data yang masuk, dan menyebarkannya ke suatu komponen tampilan. Menyiapkan koneksi serta membaca data yang masuk secara inheren memblokir operasi. Ketika berurusan dengan komunikasi jarak jauh, kita juga memiliki kelemahan bahwa waktu untuk setiap operasi untuk menyelesaikan mungkin relatif yang panjang, Akibatnya, terlihat bahwa browser Web yang melakukan beberapa tugas secara bersamaan. Ternyata, mengembangkan browser sebagai klien multithreaded menyederhanakan hal jauh. Begitu file HTML utama telah diambil, yang terpisah thread dapat diaktifkan untuk mengurus mengambil bagian-bagian lainnya. Setiap set thread koneksi terpisah untuk server dan menarik dalam data. Menyiapkan koneksi dan membaca data dari server dapat diprogram dengan menggunakan standar (pemblokiran) panggilan sistem, dengan asumsi bahwa pemblokiran panggilan tidak menangguhkan seluruh proses. kode untuk setiap thread adalah yang sama dan, di atas semua, sederhana. Sementara itu, pengguna hanya penundaan pemberitahuan di layar gambar dan semacamnya, tapi selain dapat menelusuri melalui dokumen
   Sekarang perhatikan bagaimana file server mungkin telah ditulis dalam ketiadaan thread. Salah satu kemungkinan adalah untuk memilikinya beroperasi sebagai thread tunggal. Pengulangan utama file server mendapat permintaan, memeriksa, dan membawanya keluar sampai selesai sebelum mendapatkan satu berikutnya. Sambil menunggu disk, server dalam keadaan idle dan bukan Proses permintaan lainnya. Akibatnya, permintaan dari klien lain tidak dapat ditangani. Selain itu, jika file server berjalan pada mesin khusus, seperti biasanya terjadi, CPU hanya menganggur sedangkan file server menunggu disk. Hasil akhirnya adalah bahwa banyak permintaan sedikit / detik dapat diproses. Jadi thread mendapatkan kinerja yang cukup besar, namun masing-masing thread diprogram secara berurutan, dengan cara yang biasa.
Sejauh ini kita telah melihat dua desain yang mungkin: sebuah file server multithreaded dan single-threaded file server. Misalkan bahwa benang tidak tersedia, tetapi sistem desainer menemukan kerugian kinerja karena tidak dapat diterima threading tunggal. Sepertiga kemungkinan adalah untuk menjalankan server sebagai mesin terbatas-negara besar. Ketika permintaan dating dalam, thread satu dan hanya memeriksa itu. Jika dapat dipenuhi dari cache, baik, tetapi jika tidak, pesan harus dikirim ke disk.

   Namun, bukan menghalangi, itu mencatat keadaan permintaan saat ini dalam meja dan kemudian pergi dan mendapat pesan berikutnya. Pesan berikutnya dapat berupa permintaan untuk pekerjaan baru atau balasan dari disk tentang operasi sebelumnya. Jika kerja baru, pekerjaan yang dimulai. Jika itu adalah balasan dari disk, informasi yang relevan diambil dari meja dan jawaban diproses dan selanjutnya dikirim ke klien. Dalam skema ini, server akan memiliki untuk menggunakan panggilan Nonblocking untuk
mengirim dan menerima.

3.2 Visualisasi
   Thread dan proses dapat dilihat sebagai cara untuk melakukan lebih banyak hal pada saat yang sama waktu. Akibatnya, mereka membiarkan kita membangun (potongan) program yang tampaknya akan dieksekusi secara bersamaan. Pada komputer prosesor tunggal, ini adalah eksekusi simultan, Tentu saja, ilusi. Karena hanya ada sebuah CPU, hanya instruksi dari thread tunggal atau proses akan dijalankan pada suatu waktu. Dengan cepat beralih antara thread dan proses, ilusi paralelisme dibuat. Pemisahan antara memiliki sebuah CPU tunggal dan mampu berpura-pura ada lebih dapat diperpanjang untuk sumber daya lain juga, yang mengarah ke apa yang dikenal sebagai sumber daya virtualisasi. Virtualisasi ini telah diterapkan selama beberapa dekade, namun telah menerima minat baru sebagai (didistribusikan) sistem komputer telah menjadi lebih umum dan kompleks, yang mengarah ke situasi yang aplikasi perangkat lunak sebagian besar selalu hidup lebih lama perangkat lunak yang mendasarinya sistem dan perangkat keras. Dalam bagian ini, kita memperhatikan beberapa peran virtualisasi dan mendiskusikan bagaimana dapat direalisasikan.

3.2.1 Peran Virtualisasi dalam Sistem Terdistribusi
   Dalam prakteknya, setiap sistem komputer (didistribusikan) menawarkan antarmuka pemrograman ke perangkat lunak tingkat yang lebih tinggi. Ada berbagai jenis interface, mulai dari instruksi dasar yang ditetapkan yang ditawarkan oleh CPU untuk koleksi luas antarmuka pemrograman aplikasi yang dikirimkan dengan banyak sistem middleware saat ini. Pada intinya penawaran virtualisasi, dengan memperluas atau mengganti antarmuka yang ada sehingga untuk meniru perilaku sistem lain. Kami akan datang untuk membahas rincian teknis tentang virtualisasi tak lama, tapi mari kita berkonsentrasi pada mengapa virtualisasi adalah penting untuk sistem terdistribusi.

   Salah satu alasan paling penting untuk memperkenalkan virtualisasi pada 1970-an, adalah untuk memungkinkan perangkat lunak warisan untuk dijalankan pada hardware mainframe mahal. perangkat lunak tidak hanya termasuk berbagai aplikasi, tetapi sebenarnya juga sistem operasi mereka dikembangkan untuk. Pendekatan terhadap perangkat lunak warisan pendukung telah telah berhasil diterapkan pada mainframe IBM 370 (dan penerus mereka) yang menawarkan mesin virtual untuk sistem operasi yang berbeda yang telah porting.
   Dalam prakteknya, setiap sistem komputer (didistribusikan) menawarkan antarmuka pemrograman ke perangkat lunak tingkat yang lebih tinggi. Ada berbagai jenis interface, mulai dari instruksi dasar yang ditetapkan yang ditawarkan oleh CPU untuk koleksi luas antarmuka pemrograman aplikasi yang dikirimkan dengan banyak sistem middleware saat ini. Pada intinya penawaran virtualisasi, dengan memperluas atau mengganti antarmuka yang ada sehingga untuk meniru perilaku sistem lain . Kami akan datang untuk membahas rincian teknis tentang virtualisasi tak lama, tapi mari kita berkonsentrasi pada mengapa virtualisasi adalah penting untuk sistem terdistribusi.
Salah satu alasan paling penting untuk memperkenalkan virtualisasi pada 1970-an, adalah untuk memungkinkan perangkat lunak warisan untuk dijalankan pada hardware mainframe mahal. perangkat lunak tidak hanya termasuk berbagai aplikasi, tetapi sebenarnya juga sistem operasi mereka untuk dikembangkan. Pendekatan terhadap warisan perangkat lunak pendukung telah telah berhasil diterapkan pada mainframe IBM 370 (dan penerus mereka) yang menawarkan mesin virtual untuk sistem operasi yang berbeda yang telah porting.
Sebagai perangkat keras menjadi lebih murah, komputer menjadi lebih kuat, dan jumlah rasa sistem operasi yang berbeda adalah mengurangi, virtualisasi menjadi kurang dari suatu masalah. Namun, hal telah berubah lagi sejak akhir 1990-an untuk beberapa alasan, yang sekarang kita akan membahas.

3.2.2 Arsitektur Mesin Virtual
   Ada banyak cara yang berbeda di mana virtualisasi dapat direalisasikan dalam praktek.
Sebuah gambaran dari berbagai pendekatan ini dijelaskan oleh Smith dan Nair (2005). Untuk memahami perbedaan dalam virtualisasi, penting untuk menyadari bahwa sistem komputer umumnya menawarkan empat jenis interface, di empat tingkat yang berbeda:

-   Sebuah antarmuka antara hardware dan software, yang terdiri dari mesin instruksi yang dapat dipanggil oleh program apapun.
- Sebuah antarmuka antara hardware dan software, yang terdiri dari mesin instruksi yang hanya dapat dipanggil oleh program istimewa,seperti sistem operasi.
-  Sebuah antarmuka yang terdiri dari sistem panggilan yang ditawarkan oleh suatu operasi sistem.
-   Sebuah antarmuka yang terdiri dari panggilan perpustakaan, umumnya membentuk apa yang dikenal sebagai antarmuka pemrograman aplikasi (API). di banyak kasus, panggilan sistem tersebut disembunyikan oleh API.


3.3 CLIENTS
3.3.1 User Interface Jaringan
   Tugas utama dari mesin klien adalah untuk menyediakan sarana bagi pengguna untuk berinteraksi dengan remote server. Ada sekitar dua cara di mana interaksi ini dapat didukung. Pertama, untuk setiap layanan remote mesin klien akan memiliki yang terpisah rekan yang dapat menghubungi layanan melalui jaringan. Sebuah contoh yang khas adalah Agenda yang berjalan pada PDA user yang perlu melakukan sinkronisasi dengan remote, mungkin berbagi agenda. Dalam hal ini, sebuah protokol tingkat aplikasi akan menangani sinkronisasi.
   Solusi kedua adalah untuk menyediakan akses langsung ke layanan remote dengan hanya menawarkan antarmuka yang mudah digunakan pengguna. Ini berarti bahwa mesin klien digunakan hanya sebagai terminal dengan tidak perlu untuk penyimpanan lokal, yang menyebabkan applicationneutral solusi Dalam kasus user interface jaringan, semuanya diproses dan disimpan di server. Pendekatan tipis-klien mendapat perhatian lebih sebagai meningkatkan konektivitas internet, dan perangkat genggam menjadi lebih canggih. Seperti yang kita menyatakan dalam bab sebelumnya, thin-client solusi juga populer karena mereka memudahkan tugas manajemen sistem.

3.3.2 Client-Side Software untuk Transparansi Distribusi
   Perangkat lunak klien terdiri lebih dari sekedar user interface. Dalam banyak kasus, bagian tingkat pengolahan dan data dalam aplikasi client-server dijalankan pada sisi client juga. Kelas khusus dibentuk dengan perangkat lunak klien tertanam, seperti untuk mesin teller otomatis (ATM), cash register, pembaca barcode, TV set-top kotak, dll Dalam kasus ini, user interface adalah bagian yang relatif kecil dari klien perangkat lunak, kontras dengan pemrosesan lokal dan fasilitas komunikasi.
   Selain user interface dan aplikasi yang berhubungan dengan perangkat lunak, perangkat lunak klien terdiri dari komponen untuk mencapai transparansi distribusi. Idealnya, klien tidak harus menyadari bahwa itu adalah berkomunikasi dengan proses remote. Sebaliknya, distribusi sering kurang transparan ke server untuk alasan kinerja dan kebenaran. Misalnya, dalam Bab. 6 kita akan menunjukkan bahwa server direplikasi
kadang-kadang perlu untuk berkomunikasi dalam rangka untuk menetapkan bahwa operasi dilakukan dalam urutan tertentu di replika masing-masing.
   Transparansi Akses umumnya ditangani melalui generasi dari klien potongan dari definisi antarmuka dari apa server yang ditawarkan. Tulisan rintisan menyediakan antarmuka yang sama dengan yang tersedia di server, tapi menyembunyikan perbedaan mungkin dalam arsitektur mesin, serta komunikasi yang sebenarnya. Ada berbagai cara untuk menangani lokasi, migrasi, dan transparansi relokasi. Menggunakan sistem penamaan cocok merupakan penting, karena kita juga akan melihat dalam selanjutnya bab. Dalam banyak kasus, kerja sama dengan sisi klien perangkat lunak juga penting.
   Sebagai contoh, ketika klien sudah terikat ke server, klien dapat langsung diinformasikan ketika server perubahan lokasi. Dalam hal ini, middleware klien dapat menyembunyikan lokasi saat geografis server dari pengguna, dan juga transparan rebind ke server jika perlu. Pada terburuk, aplikasi klien mungkin akan melihat kerugian sementara kinerja.
   Dalam cara yang sama, sistem terdistribusi banyak menerapkan transparansi replikasi dengan cara client-side solusi. Sebagai contoh, bayangkan sebuah sistem terdistribusi dengan server direplikasi, replikasi tersebut dapat dicapai dengan forwarding permintaan. Sisi klien perangkat lunak transparan dapat mengumpulkan semua tanggapan dan lulus respon tunggal untuk aplikasi.
   Akhirnya, menganggap kegagalan transparansi. Menutupi kegagalan komunikasi dengan server biasanya dilakukan melalui middleware klien. Sebagai contoh, klien middleware dapat dikonfigurasi untuk berulang kali mencoba untuk terhubung ke server, atau mungkin mencoba server lain setelah beberapa upaya. Bahkan ada situasi di mana klien middleware kembali data cache selama sesi sebelumnya, seperti yang kadang-kadang dilakukan oleh browser Web yang gagal melakukan koneksi ke server. Transparansi konkurensi dapat ditangani melalui server perantara khusus, terutama transaksi monitor, dan membutuhkan dukungan kurang dari perangkat lunak klien.

3.4 Server
3.4.1 Isu Desain Umum
   Sebuah server adalah sebuah proses melaksanakan layanan tertentu atas nama kumpulan klien. Pada dasarnya, setiap server diatur dengan cara yang sama: ia akan menunggu untuk permintaan yang masuk dari klien dan kemudian memastikan bahwa permintaan diambil dan ditangani, setelah itu menunggu permintaan masuk berikutnya Ada beberapa cara untuk mengatur server. Dalam kasus iteratif server, server sendiri menangani permintaan dan, jika perlu, mengembalikan respon terhadap permintaan klien. Sebuah server konkuren tidak menangani permintaan itu sendiri, namun melewati ke thread yang terpisah atau proses lain, setelah itu segera menunggu permintaan yang masuk selanjutnya . Sebuah server multithreaded adalah contoh dari bersamaan server. Sebuah implementasi alternatif dari sebuah server bersamaan adalah untuk garpu proses baru untuk setiap permintaan yang masuk baru. Pendekatan ini banyak diikuti di UNIXsystems. Thread atau proses yang menangani permintaan bertanggung jawab untuk mengembalikan respon klien yang meminta. Masalah lainnya adalah di mana klien menghubungi server. Dalam semua kasus, klien mengirim permintaan ke titik akhir, juga disebut port, di mesin dimana server berjalan.
   Setiap server mendengarkan titik akhir tertentu. Bagaimana klien tahu akhirnya titik layanan? Satu pendekatan adalah untuk menetapkan titik akhir secara global untuk terkenal layanan. Sebagai contoh, server yang menangani permintaan FTP internet selalu mendengarkan Port TCP 21. Demikian juga, server HTTP untuk World Wide Web akan selalu mendengarkan TCP port 80. Titik-titik akhir telah ditetapkan oleh Internet Assigned Numbers Authority (IANA), dan didokumentasikan dalam Reynolds dan Postel(1994). Dengan titik akhir ditetapkan, klien hanya perlu menemukan alamat jaringan dari mesin di mana server berjalan. Seperti kami jelaskan di berikutnya bab, layanan nama dapat digunakan untuk tujuan itu.

3.4.2 Server Clusters
   Sederhananya, sebuah server cluster tidak lain adalah kumpulan mesin yang terkoneksi
melalui jaringan, di mana setiap mesin berjalan satu atau lebih server. Para Server cluster yang kita pertimbangkan disini, adalah orang-orang di mana mesin yang terhubung melalui jaringan lokal-daerah, sering menawarkan bandwidth tinggi dan rendah latency.
   Dalam kebanyakan kasus, cluster server secara logis disusun dalam tiga tingkatan, seperti yang ditunjukkan Tingkat pertama terdiri dari switch (logis) melalui permintaan klien dialihkan. Seperti switch dapat sangat bervariasi. Sebagai contoh, lapisan transport- switch terima permintaan koneksi TCP permintaan yang masuk selanjutnya dan lulus permintaan ke salah satu server dalam cluster, seperti yang kita bahas di bawah ini. Sebuah contoh yang sama sekali berbeda adalah Web server yang menerima permintaan yang masuk HTTP, tetapi yang sebagian melewati permintaan untuk aplikasi server untuk diproses lebih lanjut hanya untuk kemudian mengumpulkan hasil dan kembali HTTP respon.
   Seperti dalam arsitektur client-server multitier, cluster server banyak juga mengandung server khusus untuk pengolahan aplikasi. Dalam komputasi cluster, ini adalah biasanya server yang berjalan pada perangkat keras berkinerja tinggi yang didedikasikan untuk memberikan menghitung daya. Namun, dalam kasus cluster server perusahaan, maka mungkin kasus bahwa aplikasi hanya perlu dijalankan pada mesin yang relatif low-end, seperti yang diperlukan menghitung daya tidak hambatan, tetapi akses ke penyimpanan. Hal ini membawa kita tingkat ketiga, yang terdiri dari pengolahan data server, terutama file dan server database. Sekali lagi, tergantung pada penggunaan server cluster, server ini dapat menjalankan mesin-mesin khusus, dikonfigurasi untuk kecepatan tinggi akses disk dan memiliki besar cache server-side data.
   Tentu saja, tidak semua cluster server akan mengikuti pemisahan yang ketat. Hal ini sering kasus yang setiap mesin sering dilengkapi dengan penyimpanan lokal sendiri.

3.4.3 Mengelola Cluster Server
   Sejauh ini pendekatan yang paling umum untuk mengelola cluster server untuk memperpanjang mengelola fungsi dari sebuah komputer tunggal untuk bahwa dari cluster. Dalam nya bentuk yang paling primitif, ini berarti bahwa seorang administrator dapat login ke sebuah node dari terpencil klien dan menjalankan perintah mengelola lokal untuk memonitor, install, dan mengubah komponen.
   Untuk menyembunyikan kenyataan bahwa Anda perlu untuk login ke node dan bukannya menyediakan sebuah antarmuka di mesin administrasi yang memungkinkan untuk mengumpulkan informasi dari satu atau lebih server, upgrade komponen, menambah dan menghapus node, dll Keuntungan utama dari pendekatan kedua adalah bahwa operasi kolektif, yang beroperasi pada sekelompok server, dapat lebih mudah disediakan. Jenis mengelola cluster server secara luas diterapkan dalam praktek, dicontohkan oleh manajemen software seperti Sistem Manajemen Cluster dari IBM (Hochstetler dan Beringer, 2004).
   Namun, segera sebagai cluster tumbuh melampaui beberapa puluh node, jenis manajemen tidak cara untuk pergi. Banyak pusat data kebutuhan untuk mengelola ribuan server, diatur dalam cluster banyak tetapi semua operasi bersama-sama. Melakukan hal ini dengan cara server administrasi terpusat hanya keluar dari pertanyaan.
    Selain itu dapat dengan mudah dilihat bahwa kelompok yang sangat besar perlu perbaikan terus menerus manajemen (termasuk upgrade). Untuk menyederhanakan masalah, jika p adalah probabilitas bahwa server saat ini rusak, dan kita asumsikan bahwa kesalahan yang independen, maka untuk sekelompok server N untuk beroperasi tanpa sebuah server tunggal yang rusak adalah (l_p) N. Dengan p = O. ool dan N = 1000, hanya ada 36 persen kemungkinan bahwa semua server berfungsi dengan benar. Ternyata, dukungan untuk cluster server yang sangat besar hampir selalu ad hoc. Ada berbagai aturan praktis yang harus dipertimbangkan (Brewer, 2001), namun tidak ada pendekatan sistematis untuk berurusan dengan manajemen sistem besar. Manajemen cluster masih sangat banyak dalam masa pertumbuhan, meskipun dapat diharapkan bahwa pengelolaan diri solusi seperti yang dibahas dalam bab sebelumnya akhirnya akan menemukan jalan mereka di daerah ini, setelah lebih banyak pengalaman dengan mereka telah peroleh.

3.5 CODE MIGRATION
3.5.1 Pendekatan Kode Migrasi
    Secara tradisional, kode migrasi dalam sistem terdistribusi terjadi dalam bentuk proses migrasi di mana seluruh proses telah dipindahkan dari satu mesin ke mesin lain. Memindahkan proses yang berjalan ke mesin yang berbeda adalah tugas yang mahal dan rumit, dan ada yang lebih baik menjadi alasan yang baik untuk melakukannya.
   Alasan yang selalu kinerja. Ide dasarnya adalah bahwa sistem secara keseluruhan kinerja dapat ditingkatkan jika proses dipindahkan dari berat-dimuat untuk ringan-load mesin. Load sering dinyatakan dalam antrian CPU panjang atau penggunaan CPU, tetapi lain indikator kinerja yang digunakan juga.
Algoritma distribusi beban dengan mana keputusan yang dibuat mengenai alokasi dan redistribusi tugas sehubungan dengan satu set prosesor, memainkan peran penting peran dalam sistem menghitung-intensif. Namun, dalam banyak modem didistribusikan sistem, mengoptimalkan kapasitas komputasi kurang masalah daripada, misalnya, mencoba untuk meminimalkan komunikasi. Selain itu, karena heterogenitas yang mendasari platform dan jaringan komputer, peningkatan kinerja melalui migrasi kode sering didasarkan pada penalaran kualitatif bukan model matematika.
   Pertimbangkan, sebagai contoh, sistem client-server di mana server mengelola besar database. Jika sebuah aplikasi klien perlu banyak melakukan operasi database melibatkan sejumlah besar data, mungkin lebih baik untuk mengirimkan bagian dari aplikasi klien ke server dan mengirim hanya hasil di jaringan. Jika tidak, jaringan dapat dibanjiri dengan transfer data dari server ke klien. Dalam kasus ini, migrasi kode didasarkan pada asumsi bahwa pada umumnya masuk akal untuk memproses data yang dekat dengan tempat data tersebut berada. Ini alasan yang sama dapat digunakan untuk migrasi bagian dari server ke klien. Sebagai contoh, di banyak aplikasi database interaktif, klien perlu mengisi formulir yang kemudian diterjemahkan menjadi serangkaian operasi database. Pengolahan bentuk di sisi client, dan mengirimkan formulir yang telah diisi hanya ke server, dapat kadang-kadang menghindari bahwa jumlah yang relatif besar pesan kecil perlu menyeberang jaringan. Hasilnya adalah bahwa klien merasakan kinerja yang lebih baik, sementara pada saat yang sama server menghabiskan waktu kurang pada pengolahan bentuk dan komunikasi. Dukungan untuk migrasi kode juga dapat membantu meningkatkan kinerja dengan memanfaatkan paralelisme, tetapi tanpa kerumitan yang biasa berhubungan dengan pemrograman paralel. Sebuah contoh yang khas adalah mencari informasi di Web. Hal ini relatif sederhana untuk mengimplementasikan permintaan pencarian dalam bentuk program mobile kecil, yang disebut ponsel agen, yang bergerak dari situs ke situs. Dengan membuat beberapa salinan dari suatu program, dan mengirim off setiap situs yang berbeda, kita mungkin dapat mencapai speedup linier dibandingkan dengan hanya menggunakan contoh program tunggal.

3.5.2 Migration in Heterogeneous Systems
   Masalah-masalah yang berasal dari heterogenitas yang dalam banyak hal sama dengan orang-orang dari portabilitas. Tidak mengherankan, solusi juga sangat mirip. Sebagai contoh, pada akhir 1970-an, solusi sederhana untuk mengurangi banyak masalah Pascal port ke mesin yang berbeda adalah untuk menghasilkan mesin-independen antara kode untuk sebuah mesin virtual abstrak (Barron, 1981). Bahwa mesin, dari Tentu saja, akan perlu untuk diterapkan pada banyak platform, tetapi kemudian akan memungkinkan Program pascal untuk dijalankan di mana saja. Meskipun ide sederhana ini secara luas digunakan untuk beberapa tahun, tidak pernah benar-benar tertangkap sebagai solusi umum untuk portabilitas masalah bagi bahasa lain, terutama C.
   Sekitar 25 tahun kemudian, kode migrasi dalam sistem heterogen sedang diserang oleh bahasa scripting dan bahasa sangat portabel seperti Java. Dalam Intinya, solusi ini mengadopsi pendekatan yang sama seperti yang dilakukan untuk port Pascal.
   Semua solusi tersebut memiliki kesamaan bahwa mereka bergantung pada mesin virtual (proses) bahwa baik secara langsung menafsirkan kode sumber (seperti dalam kasus bahasa scripting), atau jika menafsirkan kode menengah yang dihasilkan oleh kompilator (seperti di Java). Menjadi di tempat yang tepat pada waktu yang tepat juga penting bagi pengembang bahasa Perkembangan terakhir telah mulai melemahkan ketergantungan pada pemrograman bahasa. Secara khusus, solusi telah diusulkan tidak hanya untuk bermigrasi proses, namun untuk bermigrasi lingkungan komputasi keseluruhan. Ide dasarnya adalah untuk kotakkan lingkungan secara keseluruhan dan untuk menyediakan proses di bagian yang sama mereka sendiri melihat pada lingkungan komputasi mereka.
   Jika kompartementalisasi dilakukan dengan benar, maka ada kemungkinan untuk memisahkan bagian dari sistem yang mendasari dan benar-benar bermigrasi ke mesin lain. Dalam cara ini, migrasi sebenarnya akan memberikan bentuk mobilitas yang kuat untuk proses, karena mereka kemudian dapat dipindahkan pada setiap saat selama eksekusi mereka, dan terus di mana mereka meninggalkan off saat migrasi selesai. Selain itu, banyak seluk-beluk terkait dengan proses migrasi sementara mereka memiliki binding untuk sumber daya lokal mungkin diselesaikan, karena ini binding dalam banyak kasus hanya diawetkan. Sumber daya lokal, yaitu, sering bagian dari lingkungan yang sedang bermigrasi.
Ada beberapa alasan untuk ingin untuk bermigrasi lingkungan secara keseluruhan, namun mungkin yang paling penting adalah bahwa hal itu memungkinkan kelanjutan dari operasi sementara mesin perlu shutdown. Sebagai contoh, dalam sebuah cluster server, sistem administrator dapat memutuskan untuk mematikan atau mengganti mesin, tetapi tidak perlu menghentikan semua proses yang berjalan. Sebaliknya, untuk sementara dapat membekukan lingkungan, memindahkannya ke komputer lain (di mana ia duduk di samping lainnya, lingkungan yang ada), dan hanya mencairkan lagi. Jelas, ini merupakan cara yang sangat ampuh untuk mengelola lama berjalan menghitung lingkungan dan proses mereka.
Mari kita perhatikan salah satu contoh spesifik dari migrasi mesin virtual, Dalam hal ini, penulis terkonsentrasi pada real-time migrasi sistem operasi virtual, biasanya sesuatu yang akan nyaman dalam cluster server mana kopling ketat dicapai melalui tunggal, berbagi jaringan area lokal. Dalam keadaan ini, migrasi melibatkan dua besar masalah: migrasi seluruh memori gambar dan migrasi binding ke sumber daya lokal.
Seperti untuk masalah pertama, ada, pada prinsipnya, tiga cara untuk menangani migrasi
(yang dapat dikombinasikan):
1. Mendorong halaman memori ke mesin baru dan kirim kembali yang kemudian dimodifikasi selama proses migrasi.
2. Menghentikan mesin virtual saat ini, bermigrasi memori, dan memulai mesin virtual baru.
3. Membiarkan tarikan mesin baru virtual di halaman baru yang diperlukan, yaitu,
biarkan proses start pada mesin virtual baru dengan segera dan salin memori halaman pada permintaan.


3.6 Ringkasan
    Proses memainkan peran mendasar dalam sistem terdistribusi karena mereka membentuk basis untuk komunikasi antara mesin yang berbeda. Suatu hal yang penting adalah bagaimana proses secara internal terorganisir dan, khususnya, apakah atau tidak mereka mendukung beberapa kontrol thread. Threads pada sistem terdistribusi sangat berguna untuk terus menggunakan CPU ketika operasi I / O memblokir dilakukan. Dengan cara ini, menjadi mungkin untuk membangun sangat efisien server yang menjalankan beberapa thread dalam paralel, yang beberapa mungkin memblokir menunggu sampai disk I / O atau jaringan komunikasi selesai.
   Pengorganisasian sebuah aplikasi terdistribusi dalam hal klien dan server telah terbukti menjadi berguna. Klien umumnya proses mengimplementasikan antarmuka pengguna, yang mungkin berkisar dari yang sangat sederhana untuk menampilkan interface canggih yang dapat menangani senyawa dokumen. Perangkat lunak klien ini lebih lanjut bertujuan untuk mencapai transparansi distribusi dengan menyembunyikan rincian tentang komunikasi dengan server, di mana server tersebut saat ini berada, dan apakah atau tidak server yang direplikasi. Dalam Selain itu, perangkat lunak klien adalah sebagian bertanggung jawab atas kegagalan bersembunyi dan pemulihan dari kegagalan.
    Server sering lebih rumit dari klien, tetapi tetap tunduk pada hanya masalah desain yang relatif sedikit. Misalnya, server dapat menjadi iteratif atau bersamaan, menerapkan satu atau lebih layanan, dan dapat stateless atau stateful. Masalah desain lainnya berurusan dengan layanan menangani dan mekanisme untuk mengganggu server setelah permintaan layanan telah dikeluarkan dan mungkin sudah diproses. Perhatian khusus harus dibayar ketika mengatur server ke cluster. Sebuah Tujuan umum adalah menyembunyikan internal dari sebuah cluster dari dunia luar. Ini berarti bahwa organisasi cluster harus terlindung dari aplikasi. Untuk tujuan ini, cluster kebanyakan menggunakan entry point tunggal yang dapat menyerahkan pesan ke server dalam cluster. Sebuah masalah yang menantang adalah untuk menggantikan transparan single ini titik masuk dengan solusi sepenuhnya didistribusikan.
   Sebuah topik yang penting untuk sistem terdistribusi adalah migrasi dari kode antara mesin yang berbeda. Dua alasan penting untuk mendukung migrasi kode yang meningkat kinerja dan fleksibilitas. Ketika komunikasi adalah mahal, kita kadang-kadang dapat mengurangi komunikasi dengan perhitungan pengiriman dari server ke klien, dan membiarkan klien melakukan seperti pemrosesan lokal sebanyak mungkin. fleksibilitas ini meningkat jika klien secara dinamis dapat men-download software yang dibutuhkan untuk berkomunikasi dengan server tertentu. Perangkat lunak download dapat secara khusus ditargetkan untuk server, tanpa memaksa klien untuk memilikinya terpasang.
   Kode migrasi membawa serta masalah yang berkaitan dengan penggunaan sumber daya lokal untuk yang diperlukan bahwa baik sumber daya yang bermigrasi juga, binding baru untuk sumber daya lokal di mesin target ditetapkan, atau untuk jaringan yang systemwide referensi yang digunakan. Masalah lain adalah bahwa migrasi kode mengharuskan kita mengambil heterogenitas ke rekening. Praktek saat ini mengindikasikan bahwa solusi terbaik untuk menangani heterogenitas adalah dengan menggunakan mesin virtual. Ini dapat mengambil baik bentuk proses mesin virtual seperti dalam kasus, misalnya, Java, atau melalui menggunakan maya mesin monitor yang efektif memungkinkan migrasi dari kumpulan proses bersama dengan sistem operasi yang mendasarinya.

E-Book Distributed systems principles and paradigms 2nd edition, 2006 Klik Disini