Ketika istilah ‘sistem terdistribusi’ pertama menjadi populer, setidaknya satu vendor mulai iklan yang sudah memiliki sistem terdistribusi untuk dijual, yang terdiri dari mainframe besar yang beberapa ratus terminal ASCII bisa dihubungkan. sebuah sistem terdistribusi memiliki dua karakteristik penting: Sistem ini memiliki sejumlah independen, otonom, CPU berkomunikasi; Sistem ini terlihat kepada pengguna seperti komputer. Titik pertama berarti bahwa sistem terdiri dari komputer terpisah yang terhubung oleh jaringan. Mainframe tua masih belum sistem terdistribusi, bahkan jika ASCIIterminals diganti dengan X-terminal masing-masing berisi 50 MIPS CPU, 64M RAM, hard disk besar untuk menampung semua font, dan koneksi serat optik ke mainframe. X-terminal tidak komputer independen; itu masih beroperasi sebagai terminal.
<*> Struktur Sistem
Observation 1: sistem operasi terdistribusi harus didasarkan pada microkernels. mikrokemel memungkinkan bagi programmer sistem untuk menggunakannya sebagai dasar untuk membangun berbagai sistem operasi di atasnya. Layanan yang diberikan yang dibutuhkan oleh pembangun sistem operasi, tidak yang dibutuhkan oleh pengguna biasa. Berikut ini perbedaan antara microkernel based system dan konvensional. Sebuah mikrokernel adalah sistem operasi kernel yang relatif kecil dengan fungsi terbatas, Microkernel bisa disebut juga sebagai amoeba. Microkernel dapat mengimplemntasikan jadwal proses bedasarkan prioritas. Berikut ini tipe2 fungsi dari microkernel
*Interprocess communication
*Low-level process management
*Low-level memory management
*Input/output
<*> Komunikasi
Karena sistem terdistribusi terdiri dari banyak proses berkomunikasi satu sama lain, isu utama dalam desain sistem operasi terdistribusi adalah BAGAIMANA KOMUNIKASI DIKELOLA?
Tiga pengamatan yang dilakukan oleh penulis makalah, antara lain:
Panggilan Prosedur Remote adalah model komunikasi yang baik
Dalam sebuah makalah yang klasik, Birrell dan Nelson menunjukkan cara untuk menyembunyikan semua komunikasi, sehingga satu – satunya abstraksi yang dibutuhkan oleh klien dan server adalah panggilan prosedur yang panjang dan familiar. Teknik ini dikenal sebagai Remote Procedure Call (RPC), telah menjadi banyak digunakan sebagai dasar untuk komunikasi dalam sistem operasi terdistribusi. Hal ini diilustrasikan pada Gambar dibawah ini:
Gambar diatas adalah bagian permintaan (request) dari “Remote Procedure Call”. Balasannya (reply) mengikuti jalur sebaliknya.
Secara singkat, untuk setiap layanan yang ditawarkan oleh server, menyediakan prosedur yang sesuai, yang disebut stub (rintisan), di perpustakaan sehingga klien dapat menggunakannya.
Keindahan dari skema ini adalah bahwa baik prosedur klien maupun prosedur server harus mengetahui jika mereka saling terlibat dalam komunikasi jarak jauh / remote communication.
() Klien memanggil prosedur local (stub nya) menggunakan urutan panggilan untuk melalui parameter.
() Server juga dipanggil oleh prosedur local, dan dengan demikian mendapatkan parameter pada stack dengan cara yang biasa.
Dengan RPC, semua message passing tersembunyi di dalam stubs, yang biasanya dihasilkan oleh compiler dari deskripsi fungsional antarmuka server.
Secara Global memerintahkan, penyiaran yang terpercaya itu berguna
Jika sejumlah besar CPU yang tersedia untuk digunakan, baik workstation yang menganggur / koleksi terpusat prosesor di ruang mesin, memungkinkan untuk memanfaatkan beberapa mesin untuk bekerjasama secara parallel untuk mempercepat aplikasi tunggal. Atau sistem dapat dirancang dengan cara ini dari awal.
Transparansi Komunikasi itu Penting
Ketika satu proses berbicara kepada proses lain (atau sekelompok prose smenggunakan penyiaran / broadcast) seharusnya tidak perlu khawatir mengenai lokasi relative dari proses.
Skema komunikasi yang memiliki satu semantic ketika pihak yang berkomunikasi berada pada mesin yang sama dan semantic yang berbeda ketika mereka berada di mesin yang berbeda membuat pemrograman lebih sulit.
<*> Distributed Shared Memory
Dalam beberapa tahun terakhir, bentuk hibrid telah dikembangkan yang mensimulasikan shared memory pada multicomputers. Teknik ini disebut distributed shared memory. Terdapat 2 jenis, yaitu :
-Page-based : Beroperasi sebagai sistem paging melintasi batas-batas mesin. Ketika kesalahan page terjadi, page yang dibutuhkan diambil dari mesin yang sedang memegang page tersebut.
-Object-based : Operasi didefinisikan pada objek. ketika operasi dijalankan pada objek, perangkat lunak yang mengelola objek berjalan dan mendapat objek.
Dalam kedua kasus, programmer multicomputer disajikan dengan ilusi bentuk shared memory. Proses pada mesin yang berbeda dapat menggunakan shared memory untuk komunikasi dan sinkronisasi, yang biasanya jauh lebih nyaman daripada message passing.
<*> Permasalahan
Machine Ownership
Masalah kepemilikan mesin(Machine Ownership) akan terjadi ketika ekonomi memungkinkan untuk menyediakannya, dikatakan, 32 kali kebanyakan CPU terdapat penggunanya. Dalam satu model, setiap pengguna mendapat 32-node multiprosesor, khusus untuk dirinya atau untuk dipakai sendiri. Sangat mungkin bahwa hampir semua daya komputasi ini akan menganggur sepanjang waktu,tidak begitu buruk hingga sampai pengguna ingin memulai pekerjaan berat.
File Chaching
Masalah muncul pada chacing paper ketika caching dilakukan pada klien. Ketika model workstation digunakan, setidaknya jelas di mana caching yang harus dilakukan di mesin client. Komplikasi yang muncul ketika dua klien memiliki file cache yang sama dan keduanya ingin memodifikasinya.
Thread Management
Tampaknya menjadi kesepakatan umum memiliki beberapa thread kontrol dalam proses yang sangat berguna, baik dalam sistem terpusat dan terdistribusi.
Atomic Transactions
transaksi atom adalah teknik yang kuat yang digunakan dalam sistem database untuk menjaga konsistensi dalam menghadapi concurrency. Mereka berpotensi berlaku untuk banyak bidang komputasi terdistribusi juga.
Daftar Pustaka
A. S. Tanenbaumt, “Distributed operating systems anno 1992. What we learned so far?*,” Distribution System Engineering, vol. I, pp. 3-10, 1993.
Kebanyakan protokol jaringan yang dirancang untuk mendukung aliran bit handal antara pengirim tunggal dan penerima tunggal. Untuk aplikasi seperti remote loginsesi atau transfer file massal protokol memadai. Namun, sistem operasi terdistribusi memiliki persyaratan khusus seperti mencapai transparansi, panggilan khusus prosedur jauh (RPC) semantik bahkan dalam menghadapi crash prosesor, komunikasi kelompok, keamanan, manajemen jaringan, dan jaringan wide-area. Selanjutnya, aplikasi pada sistem operasi terdistribusi sering menggunakan internetwork lokal kompleks subsistem komunikasi termasuk Ethernets. berkelanjutan pada sistem operasi Amoeba didistribusikan, telah merancang, mengimplementasikan, dan mengevaluasi protokol internet baru yang, dalam banyak hal, lebih cocok untuk komputasi terdistribusi dari protokol yang ada. protokol baru ini, yang disebut FLIP (Fast Internet Lokal Protocol).
<*> Distributed Systems Requierment
sistem terdistribusi menempatkan kebutuhan yang berbeda pada sistem operasi daripada sistem jaringan tradisional. sistem jaringan menjalankan semua aplikasi pengguna pada workstation tunggal. Workstation menjalankan salinan dari sistem operasi yang lengkap; satu-satunya hal yang dibagi adalah sistem file. Perlu dicatat bahwa banyak jaringan yang ada dan sistem terdistribusi memenuhi semua atau bagian dari persyaratan, namun dalam makalah ini kami berpendapat bahwa pelaksanaan sistem ini sering dapat disederhanakan dengan menggunakan protokol jaringan yang lebih baik.
Transparancy
Tujuan penting untuk sistem terdistribusi, seperti Amoeba , Chorus, Clouds Sprite , dan V , adalah transparansi. sistem terdistribusi yang dibangun dari sejumlah besar prosesor dihubungkan oleh LAN, bus, dan media komunikasi lainnya. Tidak peduli di mana proses berjalan, itu harus dapat berkomunikasi dengan proses lain dalam sistem menggunakan mekanisme tunggal yang independen dari mana proses berada.
Remote Produce Call
sistem operasi terdistribusi biasanya terstruktur sekitar paradigma client server. Dalam model ini, proses pengguna, disebut klien, meminta proses pengguna lain, yang disebut server, untuk melakukan beberapa pekerjaan untuk itu dengan mengirimkan server pesan dan kemudian memblokir sampai server mengirimkan kembali balasan. mekanisme komunikasi yang digunakan untuk mengimplementasikan model client-server disebut RPC
Komunikasi Kelompok
Meskipun RPC adalah abstraksi yang baik untuk permintaan \ balasan jenis komunikasi, ada tubuh besar aplikasi yang memerlukan sekelompok beberapa proses untuk berinteraksi erat.
Keamanan
Meskipun keamanan tidak dapat disediakan oleh protokol komunikasi saja, protokol yang baik dapat menyediakan mekanisme untuk membangun sistem terdistribusi aman, namun efisien.
Sifat FLIP berikut memungkinkan kita untuk mencapai persyaratan:
(1) FLIP mengidentifikasi entitas dengan 64-bit identifier lokasi-independen. Entitas dapat, misalnya, menjadi sebuah proses.
(2) FLIP menggunakan pemetaan satu arah antara alamat "pribadi", yang digunakan untuk mendaftar titik akhir dari koneksi jaringan, dan "publik" alamat yang digunakan untuk mengiklankan titik akhir.
(3) FLIP-rute pesan berdasarkan 64-bit identifier.
(4) FLIP menemukan rute pada permintaan.
(5) FLIP menggunakan sedikit dalam header pesan untuk meminta transmisi sensitive pesan melalui jaringan dipercaya.
<*> Pengertian Layanan FLIP
Komunikasi terjadi didalam Network Service Access Points (NSAPS), yang beralamatkan 64-bits. NSAP dapat berpindah dari 1 node ke node lain, dengan membawa address didalamnya, node dalam internetwork bisa memiliki lebih dari 1 NSAP untuk setiap entitas. FLIP memastikan transaparan pada setiap user,. Pesan FLIP memliki ukuran sebesar 2 32 – 1 bytes. Fragment merupakan bagian-bagian kecil pesan yang dipecah karena saat dikirimkan pesan terlalu besar. entitas memilih alamat NSAP nya sendiri secara acak dari yg sudah disediakan dengan 4 alasan, yaitu :
-Sangat tidak mungkin jika alamat tersebut sudah dipakai dengan yang lain
-Jika entitas rusak maka akan dipilih NSAP baru
-tidak ada alamat yg menumpuk, ini berguna untuk keamanan.
-entitas yang berpindah dapat menggunakan alamat yang sama pada prosesor baru.
FLIP box menghubungkan setiap mesin physical ke internetwork. Flip box bisa menjadi layer software dalam system operasi host, maupun komunikasi prosesor yang terpisah. Terdapat beberapa modul yaitu :
-Packet Switch : Mengirimkan FLIP fragment dalam bentuk paket antara jaringan fisik, dan antara host dan jaringan.
-Host Interface : menyediakan interface antara FLIP box dengan host yang terlampir.
-Network interface : kotak FLIP dengan satu jaringan fisik dan modul antarmuka
<*> Host Interface
Interface berdasarkan protocol FLIP terdiri dari tujuh downcalls(untuk traffic keluar) dan dua upcalls(untuk traffic masuk). Entitas mengalokasikan entri dalam interface dengan memanggil flip-init. Panggilan tersebut mengalokasikan sebuah entri dalam tabel dan menyimpan pointer untuk dua upcalls dalam tabel ini. Interface yang dialokasikan dihapus dengan memanggil / lip _end. Dengan memanggil flip-register satu kali atau lebih, entitas terdaftar sebagai address NSAP dengan interface. Alamat yang spesifik seperti Private-Address, bukanlah (publik) address yang digunakan oleh entitas lain sebagai tujuan dari pesan FLIP.
Flip_Register mengenkripsi Private-Address dan menyimpan sesuai Public-Address dalam tabel routing packet switch. Memanggil flip-unregister menghilangkan entri tertentu dari tabel routing.
Ada tiga panggilan untuk mengirim pesan ke Public-Address. Flip-unicast mengirim pesan satu persatu ke satu NSAP. Flip-multicast mengirim pesan ke setidaknya dua NSAPS.
Flip-boardcast mengirim pesan ke semua NSAPS. Ketika sebuah fragmen dari sebuah pesan tiba pada pada interface, itu akan diteruskan ke entitas yang tepat menggunakan upcall receive. Jika tidak, notdeliver upcall akan dipanggil untuk menginformasikan entitas yang dituju tidak bisa ditemukan.
<*> Protokol FLIP
Sebuah kotak FLIP mengimplementasikan pesan komunikasi tidak dapat diandalkan antara NSAP dengan bertukar fragmen FLIP dan dengan memperbarui tabel routing whena fragmen tiba. Pada bagian ini, kita akan menjelaskan tata letak sebuah fragmen FLIP dan memberitahu bagaimana tabel routing dikelola.
Format Fragment FLIP
Mirip dengan fragmen di protocol kebanyakan. Fragmen FLIP terdiri dari dua bagian yaitu header dan data. Formatnya tergambar di atas, header yang terdiri dari bagian tetap 40-byte dan bagian variabel. Bagian tetap berisikan informasi umum tentang fragment. The Flags area berisi informasi administrasi tentang fragmen. Bit O, 1, dan 2 ditentukan oleh pengirim. Jika bit O diatur dalam Flags, bidang bilangan bulat (jumlah hop, panjang, Pesan Identifier, Offset) dikodekan dalam big endian (byte paling signifikan pertama), jika tidak di little endian. Bagian variabel berisi parameter yang dapat digunakan sebagai petunjuk untuk meningkatkan routing, end-to- end kontrol aliran, enkripsi, atau lainnya, tetapi tidak pernah diperlukan untuk kerja yang benar dari protokol.
FLIP Routing Protocol
Fungsi dasar dari protokol FLIP adalah untuk rute pesan sembarang panjang dari sumber NSAP ke NSAP tujuan. Dalam sebuah internetwork, tujuan mungkin dicapai melalui salah satu dari beberapa rute. Beberapa rute-rute ini mungkin lebih diinginkan daripada yang lain. Sebagai contoh, beberapa dari mereka mungkin lebih cepat, atau lebih aman, daripada yang lain. Untuk dapat memilih rute, setiap kotak FLIP memiliki informasi tentang jaringan yang terhubung. Dalam implementasi saat FLIP, informasi routing setiap jaringan yang terhubung ke kotak FLIP dikodekan dalam berat jaringan dan FLAG aman. Sebuah berat jaringan rendah berarti bahwa jaringan diharapkan yang untuk meneruskan fragmen. Berat jaringan dapat didasarkan, misalnya, pada sifat fisik dari jaringan seperti bandwidth dan delay. Setiap kali fragmen membuat hop dari satu kotak FLIP ke kotak FLIP lain Hop Count sebenarnya adalah meningkatnya dengan berat jaringan lebih dari yang diarahkan (atau dibuang jika Hop Count sebenarnya yang menjadi lebih besar dibandingkan Hop Maxi-ibu Menghitung). 1 A Berat jaringan yang lebih canggih dapat didasarkan pada jenis fragmen, yang dapat dijelaskan dalam Bagian Variabel header. Bendera aman menunjukkan apakah data sensitif dapat dikirim tidak terenkripsi melalui jaringan atau tidak.
<*> Menggunakan FLIP dalam Amoeba
Perangkat lunak Amoeba terdiri dari dua bagian: sebuah microkernel, yang berjalan pada setiap prosesor, dan koleksi server yang menyediakan sebagian besar fungsi sistem operasi tradisional. Kernel amoeba memiliki dua kernel komunikasi RPC dan komunikasi grup.
Transparancy
tujuan utama amoeba untuk membuat distribusi sistem operasi transparan. Rata2 pengguna amoeba seperti traditional time sharing system bedanya tiap tipe perintah dari user menggunakan multiple machine spread sekitar jaringan. Mesinya termasuk server, files, servers, komputasi server
Pada gambar diatas terdapat tiga mesin arsitektur dengan endian yang berbeda dan dua tipe jaringan: Ethernet dan VME-busses. Rata2 10 menggunakan sistem amoeba setiap hari untuk membangun sistem dan distribusi aplikasi parallel. Perbedaan yg penting antara amoeba dan distribusi lainya adalah bahwa Amoeba tidak didasarkan pada model workstation komputasi terdistribusi, tetapi pada model prosesor kolam renang.
Group Communication
Pada hal ini komunikasi kelompok di amoeba bedasarkan protocol yang dijelaskan dan amoeba menyediakan primitif untuk mengirim pesan ke sekolompok yang andal. Selanjutnya primitif menjamin menyampaikan semua pesan ke grup yang diminta.
Keamanan
Keamanan di amoeba diimplementasikan menggunakan Flip support for security. Meskipun FLIP tidak menekripsi pesan kedirinya sendiri. Namun, menyediakan dua mekanisme untuk mendukung keamanan. Pertama, pesan dapat ditandai sensitif oleh pengirim (menggunakan bit Keamanan), sehingga mereka tidak akan dialihkan melalui jaringan tidak dipercaya. Kedua, pesan melalui FLIP dapat ditandai transaksi ACM tidak aman di Sistem Komputer (menggunakan bit yang tidak aman), sehingga penerima dapat mengatakan apakah atau tidak ada rute aman untuk pengirim.
Manajemen Jaringan
FLIP dapat menangani secara otomatis dengan perubahan jaringan: kita menambahkan mesin, jaringan, atau mengkonfigurasi ulang sistem kami hanya dengan memasukkan atau mencabut kabel. Ketika mesin muncul, itu tidak harus mengirimkan ARP atau RARP permintaan dan menunggu sampai server merespon; melainkan dapat digunakan segera setelah tersambung ke jaringan.
<*> Performa FLIP
Ukuran penting dari kesuksesan setiap protocol adalah kinerjanya. Dari paper tersebut, mereka telah membandingkan kinerja RPC Amoeba 5.0 (dengan FLIP) dengan RPC Amoeba 4.0 (versi pre-FLIP) dan dengan implementasi RPC lain pada hardware yang identik.
(1) Delay/penundaan, dapat diukur dengan menjalankan RPC 10.000 byte.
(2) Throughput/laju data, dapat diukur dengan mengirimkan RPC 30,000 byte :
-Di Amoeba 5.0 menggunakan RPC 100,000 byte (masih kecil dari ukuran maksimum yang mungkin)
-Di SunOS menggunakan RPC 8 Kbyte
-Di Sprite menggunakan RPC 16 Kbyte
-Di Peregrine menggunakan RPC 48,000 byte
Berikut ini adalah angka performasi untuk implementasi RPC yang berbeda pada Sun3/60s. Angka pada Sprite diukur berdasarkan “Kernel to Kernel”. Sedangkan yang lainnya diukur berdasarkan dari “User to User”. Kolom ke-4 dibawah ini memberikan bandwidth untuk RPC Amoeba 5.0 menggunakan ukuran data untuk pengukuran sistem disetiap baris:
Keterangan :
(#) Delay RPC Amoeba 4.0 lebih rendah dibandingkan RPC Amoeba 5.0 karena RPC Amoeba 4.0 diimplementasikan melalui Ethernet kosong dan mengharuskan semua mesin di domain menjadi satu jaringan, sehingga tidak perlu melakukan routing, dan pelaksanaannya dapat diatur untuk kasus satu antarmuka jaringan.
(#) Amoeba 4.0 menggunakan Protokol “Stop-and- Wait”, sedangkan RPC Amoeba 5.0 menggunakan protocol “Blast”. Maka dari itu Throughput Amoeba 5.0 30% lebih besar.
(#) SunOS menyalin setiap pesan beberapa kali sebelum diberikan ke driver jaringan, karena pelaksanaannya pada UDP/IP dank arena biaya yang lebih tinggi untuk konteks switching.
(#) Dalam Sprite, delay dan throughput maksimum diukur “Kernet to Kernel”. Meskipun RPC Sprite Kernel to Kernel tidak melakukan routing, delay RPC nol hampir sama dengan delay untuk Amoeba 5.0, dimana delay Amoeba diukur user-to- user. Sprite juga menggunakan protocol “Blast” untuk pesan besar, tetapi throughputnya masih kurang dari throughput yang dicapai Amoeba 5.0 Karena Amoeba membuat buffer kontinyu dalam memori dan memiliki waktu konteks switching yang lebih baik.
(#) Dibandingkan dengan RPC Peregrine, delay Amoeba untuk RPC 0 byte cukup tinggi dan throughput maksimum Amoeba rendah. Peregrine meraih kinerja tesebut dengan “re-mapping” Ethernet secara langsung untuk menerima buffer di mesin server untuk menjadi tumpukan thread baru dan dengan menggunakan “preallocated” dan inisialisasi pada header pesan. Peregrine menggunakan protocol “two-message RPC”, sedangkan Amoeba menggunakan protocol “three-message RPC” meskipun pesan ketiga hanya sebagian di jalur kritis.
<*> Diskusi dan Perbandingan
Berikut ini adalah gambar Protokol RPC Amoeba:
Protokol RPC untuk RPC kecil menggunakan 3 pesan, antara lain:
(1) Sebuah pesan request / permintaan dari klien ke server
(2) Sebuah pesan reply / balasan yang mengakui permintaan dan unblocks klien
(3) Sebuah acknowledgement / pengakuan atas jawabannya, sehingga server dapat membersihkan statusnya. Pengakuan hanya untuk sebagian kecil di jalur kritis.
Waktu Ethernet adalah waktu yang dihabiskan pada kawat ditambah waktu yang dihabiskan dalam driver dan mengambil interupsi.
Berikut ini adalah tabel waktu yang dihabiskan pada jalur kritis setiap layer pada RPC 0:
<*> Kesimpulan
Pada makalah tersebut telah didiskusikan kebutuhan protocol untuk sistem terdistribusi dan mengusulkan protokol baru yang sesuai dengan mereka. Protokol Internet (Internet protocol) saat ini tidak mengatasi berbagai masalah, meninggalkan solusi untuk protocol tingkat tinggi. Ini mengarah ke protocol yang lebih kompleks, yang tidak dapat melakukan dengan baik, karena mereka tidak dapat mengambil keuntungan dari dukungan hardware. Protokol FLIP mendukung banyak persyaratan sistem terdistribusi secara terpadu. Manajemen FLIP mengalamatkan manajemen internetworks, komunikasi yang efesien dan man, dan transparasi lokasi dan migrasi.
Daftar Pustaka
Kaashoek, M. F., Renesse, R. V., Staveren, H. V., & Tanenbaum, A. S. (n.d.). FLIP: An hternetwork Protocol for Supporting Distributed Systems. Vrije Universiteit.
