SISTEM FILE TERDISTRIBUSI

DISTRIBUTED SYSTEMS Concept and Design – Fifth Edition
George Coulouris
Cambridge University
Jean Dollimore
formerly of Queen Mary, University of London
Tim Kindberg
matter 2 media
Gordon Blair
Lancaster University

Sebuah sistem file terdistribusi memungkinkan program untuk menyimpan dan mengakses file remote persis seperti yang mereka lakukan yang lokal, yang memungkinkan pengguna untuk mengakses file dari komputer manapun pada jaringan. Itu kinerja dan kehandalan mengalami untuk akses ke file yang tersimpan di server harus sebanding dengan file yang tersimpan pada disk lokal.





Dalam bab ini kita mendefinisikan arsitektur sederhana untuk file sistem dan menggambarkan dua dasar didistribusikan layanan implementasi berkas dengan desain kontras yang telah di digunakan secara luas selama lebih dari dua dekade:

the Sun Network File System, NFS;
the Andrew File System, AFS.
Setiap mengemulasi sistem file UNIX antarmuka, dengan derajat yang berbeda dari skalabilitas, kesalahan toleransi dan penyimpangan dari UNIX satu-copy file update semantik yang ketat.

Beberapa sistem file terkait yang memanfaatkan mode baru organisasi data pada disk atau di beberapa server untuk mencapai kinerja tinggi, kesalahan-toleran dan file yang scalable sistem juga dikaji. Jenis lain dari sistem penyimpanan didistribusikan dijelaskan tempat lain dalam buku ini. Ini termasuk sistem penyimpanan peer-to-peer (Bab 10), sistem direplikasi berkas (Bab 18), server data multimedia (Bab 20) dan gaya tertentu dari layanan penyimpanan yang diperlukan untuk mendukung pencarian Internet dan besar- lainnya skala, aplikasi data-intensif (Bab 21).



Pendahuluan
Dalam Bab 1 dan 2, kita mengidentifikasi berbagi sumber daya sebagai tujuan utama untuk didistribusikan sistem. Berbagi informasi yang tersimpan mungkin merupakan aspek yang paling penting dari didistribusikan berbagi sumber daya. Mekanisme untuk berbagi data mengambil banyak bentuk dan dijelaskan dalam beberapa bagian buku ini. server web memberikan bentuk dibatasi data Sharing di mana file disimpan secara lokal, dalam sistem file pada server atau server pada lokal jaringan, yang dibuat tersedia untuk klien di seluruh Internet. Desain skala besar wide area sistem penyimpanan baca-tulis berkas menimbulkan masalah load balancing, keandalan, ketersediaan dan keamanan, resolusi yang tujuan dari peer-to-peer penyimpanan file sistem yang dijelaskan dalam Bab 10. Bab 18 berfokus pada sistem penyimpanan direplikasi bahwa cocok untuk aplikasi yang memerlukan akses yang dapat diandalkan untuk data yang tersimpan pada sistem di mana ketersediaan host individu tidak dapat dijamin. Dalam Bab 20 kita menjelaskan media server yang dirancang untuk melayani aliran data video untuk sejumlah besar pengguna secara real waktu. Bab 21 menjelaskan sistem file dirancang untuk mendukung skala besar, data-intensif
aplikasi seperti pencarian Internet.



Persyaratan untuk berbagi dalam jaringan lokal dan Internets menyebabkan kebutuhan untuk berbagai jenis layanan - salah satu yang mendukung penyimpanan persisten data dan program dari semua jenis atas nama klien dan distribusi konsisten up-to-date data. Tujuan bab ini adalah untuk menggambarkan arsitektur dan implementasi dasar ini sistem file terdistribusi. Kami menggunakan kata 'dasar' di sini untuk menunjukkan didistribusikan Sistem file yang tujuan utamanya adalah untuk meniru fungsi dari non-terdistribusi sistem file untuk program klien yang berjalan pada beberapa komputer jarak jauh. Mereka tidak mempertahankan beberapa replika terus-menerus dari file, dan juga tidak mendukung bandwidth dan waktu jaminan yang diperlukan untuk data streaming multimedia - persyaratan tersebut dibahas dalam bab-bab selanjutnya. Dasar terdistribusi file sistem memberikan penting mendasari untuk komputasi organisasi berdasarkan intranet.

Sistem file awalnya dikembangkan untuk sistem komputer terpusat dan komputer desktop sebagai fasilitas sistem operasi menyediakan pemrograman yang mudah antarmuka untuk penyimpanan disk. Mereka kemudian diakuisisi fitur seperti akses kontrol dan berkas-mekanisme penguncian yang membuat mereka berguna untuk berbagi data dan program. sistem file terdistribusi mendukung berbagi informasi dalam bentuk file dan sumber daya perangkat keras dalam bentuk penyimpanan persisten di intranet. A dengan baik layanan file dirancang menyediakan akses ke file yang tersimpan di server dengan kinerja dan kehandalan mirip dengan, dan dalam beberapa kasus lebih baik dari, file yang tersimpan pada disk lokal. Mereka desain disesuaikan dengan kinerja dan kehandalan karakteristik jaringan lokal, dan karenanya mereka yang paling efektif dalam memberikan bersama penyimpanan persisten untuk digunakan dalam intranet. File server pertama dikembangkan oleh para peneliti di tahun 1970-an [Birrell dan Needham 1980, Mitchell dan Dion 1982, Leach et al. 1983], dan Sun Network File Sistem menjadi tersedia pada awal tahun 1980 [Sandberg et al. 1985, Callaghan 1999].

Sebuah layanan file memungkinkan program untuk menyimpan dan mengakses file remote persis seperti yang mereka lakukan yang lokal, yang memungkinkan pengguna untuk mengakses file mereka dari komputer manapun di intranet. Itu konsentrasi penyimpanan persisten di beberapa server mengurangi kebutuhan untuk disk lokal penyimpanan dan (yang lebih penting) yang aktif ekonomi yang akan dibuat dalam pengelolaan dan pengarsipan data persisten yang dimiliki oleh sebuah organisasi. Layanan lain, seperti layanan nama, layanan otentikasi pengguna dan layanan cetak, dapat lebih mudah



Gambar 12.1 sistem penyimpanan dan sifat mereka



Jenis konsistensi:

1: strict one-copy : slightly weaker guarantees 2: considerably weaker guarantees



diimplementasikan ketika mereka dapat memanggil layanan file untuk memenuhi kebutuhan mereka untuk terus-menerus penyimpanan. server web yang bergantung pada sistem pengarsipan untuk penyimpanan halaman web yang mereka melayani. Dalam organisasi yang beroperasi server web untuk akses eksternal dan internal melalui intranet, server web sering menyimpan dan mengakses materi dari lokal didistribusikan berkas sistem.



Dengan munculnya pemrograman berorientasi objek terdistribusi, kebutuhan muncul untuk penyimpanan persisten dan distribusi benda bersama. Salah satu cara untuk mencapai ini adalah untuk cerita bersambung objek (dengan cara yang dijelaskan dalam Bagian 4.3.2) dan untuk menyimpan dan mengambil serial objek menggunakan file. Namun metode ini untuk mencapai ketekunan dan distribusi tidak praktis untuk berubah dengan cepat benda, sehingga beberapa pendekatan yang lebih langsung telah maju. Java objek remote doa dan CORBA ORB menyediakan akses remote, bersama benda-benda, tetapi tak satu pun dari ini memastikan masih adanya benda-benda, maupun adalah objek terdistribusi direplikasi.

Gambar 12.1 memberikan gambaran tentang jenis sistem penyimpanan. Selain mereka telah disebutkan, meja termasuk didistribusikan memori bersama (DSM) sistem dan objek toko persisten. DSM digambarkan dalam Bab 6. Ini memberikan emulasi dari memori bersama dengan replikasi halaman memori atau segmen di setiap host, tetapi tidak belum tentu memberikan ketekunan otomatis. toko objek terus-menerus diperkenalkan dalam Bab 5. Mereka bertujuan untuk memberikan ketekunan untuk obyek bersama didistribusikan. Contoh termasuk CORBA Persistent Layanan Negara (lihat Bab 8) dan ekstensi persisten ke Jawa [Jordan tahun 1996, java.sun.com VIII]. Beberapa proyek penelitian telah dikembangkan di platform yang mendukung replikasi otomatis dan penyimpanan persisten benda (untuk Misalnya, Perdis [Ferreira et al. 2000] dan Khazana [Carter et al. 1998]). Peer-to-peer sistem penyimpanan menawarkan skalabilitas untuk mendukung beban klien yang jauh lebih besar daripada sistem dijelaskan dalam chaper ini, tetapi mereka dikenakan biaya kinerja tinggi dalam memberikan aman akses kontrol dan konsistensi antara replika diupdate.

Gambar 12.2 modul sistem file



Kolom konsistensi menunjukkan apakah ada mekanisme untuk pemeliharaan konsistensi antara beberapa salinan data saat pembaruan terjadi. Hampir semua penyimpanan sistem bergantung pada penggunaan caching untuk mengoptimalkan kinerja program. Caching pertama kali diterapkan ke memori utama dan file sistem non-terdistribusi, dan bagi mereka yang konsistensi adalah ketat (dilambangkan dengan '1', untuk konsistensi satu-copy pada Gambar 12.1) - program tidak dapat mengamati perbedaan antara salinan cache dan data yang tersimpan setelah Sebuah pembaharuan. Ketika replika didistribusikan digunakan, konsistensi yang ketat lebih sulit untuk mencapai. sistem file terdistribusi seperti Sun NFS dan cache Andrew File System salinan bagian dari file pada komputer klien, dan mereka mengadopsi konsistensi tertentu mekanisme untuk mempertahankan perkiraan untuk konsistensi yang ketat - ini ditunjukkan dengan centang () pada kolom konsistensi Gambar 12.1. Kami membahas mekanisme ini dan
sejauh mana mereka menyimpang dari konsistensi yang ketat di Bagian 12.3 dan 12.4.

Web ini menggunakan caching secara luas baik di komputer klien dan pada proxy server dipelihara oleh organisasi pengguna. Konsistensi antara salinan disimpan di web proxy dan cache klien dan server asli hanya dipertahankan oleh pengguna eksplisit tindakan. Klien tidak diberitahu bila halaman disimpan di server asli diperbarui; mereka harus melakukan pemeriksaan eksplisit untuk menyimpan salinan lokal mereka up-to-date. Ini melayani tujuan dari browsing web secara memadai, tetapi tidak mendukung pengembangan aplikasi koperasi seperti papan tulis didistribusikan bersama. Konsistensi Mekanisme yang digunakan dalam sistem DSM dibahas secara mendalam di situs pendamping web untuk buku [www.cdk5.net]. sistem objek terus-menerus bervariasi dalam pendekatan mereka untuk caching dan konsistensi. CORBA dan Java Persistent skema mempertahankan tunggal salinan objek persisten, dan remote doa diperlukan untuk mengaksesnya, sehingga hanya masalah konsistensi antara salinan gigih dari sebuah objek pada disk dan aktif copy di memori, yang tidak terlihat oleh klien jarak jauh. The Perdis dan Khazana proyek-proyek yang kami sebutkan di atas mempertahankan replika cache objek dan mempekerjakan cukup menguraikan mekanisme konsistensi untuk menghasilkan bentuk konsistensi mirip dengan yang ditemukan dalam sistem DSM.

Setelah memperkenalkan beberapa masalah yang lebih luas yang berkaitan dengan penyimpanan dan distribusi data persisten dan non-persistent, kita sekarang kembali ke topik utama bab ini - desain dasar sistem file terdistribusi. Kami menjelaskan beberapa karakteristik yang relevan (Non-terdistribusi) file sistem dalam Bagian 12.1.1 dan persyaratan untuk berkas terdistribusi sistem dalam Bagian 12.1.2. Bagian 12.1.3 memperkenalkan studi kasus yang akan digunakan seluruh bab ini. Dalam Bagian 12.2, kita mendefinisikan sebuah model abstrak untuk dasar



Gambar 12.3 Struktur file record atribut

didistribusikan layanan file, termasuk satu set antarmuka pemrograman. Sun NFS dijelaskan dalam Bagian 12.3; itu saham banyak fitur dari model abstrak. Dalam Bagian 12.4 kita menggambarkan Andrew File System, sistem yang digunakan secara luas yang mempekerjakan secara substansial berbeda caching dan konsistensi mekanisme. Bagian 12,5 ulasan beberapa terakhir Perkembangan dalam desain layanan file.

Sistem yang diuraikan dalam bab ini tidak mencakup spektrum penuh didistribusikan File dan manajemen data sistem. Beberapa sistem dengan karakteristik yang lebih maju akan dijelaskan nanti dalam buku ini. Bab 18 meliputi deskripsi Coda, sebuah sistem file terdistribusi yang mempertahankan replika terus-menerus dari file untuk keandalan, ketersediaan dan terputus kerja. Bayou, sistem manajemen data terdistribusi yang menyediakan bentuk lemah konsisten replikasi untuk ketersediaan tinggi, juga tercakup dalam Bab 18. Bab 20 meliputi Tiger file video server, yang dirancang untuk menyediakan pengiriman tepat waktu aliran data ke sejumlah besar klien. Bab 21 menggambarkan File System Google (GFS), sistem file yang dirancang khusus untuk mendukung skala besar, aplikasi data-intensif termasuk pencarian internet.



Karakteristik sistemberkas
file sistem bertanggung jawab untuk organisasi, penyimpanan, pencarian, penamaan, sharing dan perlindungan file. Mereka menyediakan antarmuka pemrograman yang mencirikan file abstraksi, membebaskan programmer dari keprihatinan dengan rincian alokasi penyimpanan dan tata letak. File disimpan pada disk atau media penyimpanan non-volatile lainnya.

File berisi data dan atribut. Data terdiri dari urutan item data (Biasanya 8-bit byte), dapat diakses oleh operasi membaca dan menulis sebagian dari urutan. Atribut diadakan sebagai informasi catatan yang mengandung tunggal seperti panjang file, cap waktu, jenis file, identitas dan kontrol akses pemilik daftar. SEBUAH struktur record atribut khas diilustrasikan pada Gambar 12.3. atribut yang berbayang dikelola oleh sistem file dan biasanya tidak dapat diedit oleh program pengguna.

Gambar 12.4 operasi sistem file UNIX

file sistem yang dirancang untuk menyimpan dan mengelola sejumlah besar file, dengan Fasilitas untuk membuat, penamaan dan menghapus file. Penamaan file didukung oleh menggunakan direktori. Direktori adalah file, seringkali dari jenis khusus, yang menyediakan pemetaan dari nama teks ke pengidentifikasi file internal. Direktori mungkin termasuk nama-nama lainnya direktori, yang mengarah ke hirarkis skema penamaan file akrab dan multi-bagian path untuk file yang digunakan dalam UNIX dan sistem operasi lain. sistem berkas juga mengambil Tanggung jawab untuk kontrol akses ke file, membatasi akses ke file sesuai dengan otorisasi pengguna dan jenis akses yang diminta (membaca, memperbarui, melaksanakan dan sebagainya).

Metadata Istilah ini sering digunakan untuk merujuk kepada semua informasi tambahan yang disimpan oleh sistem file yang dibutuhkan untuk pengelolaan file. Ini termasuk atribut berkas, direktori dan semua informasi persisten yang lain yang digunakan oleh sistem file.

Gambar 12.2 menunjukkan struktur modul berlapis khas untuk pelaksanaan non-didistribusikan sistem file dalam sistem operasi konvensional. Setiap lapisan hanya bergantung pada lapisan di bawahnya. Pelaksanaan layanan file terdistribusi membutuhkan semua komponen ditampilkan di sana, dengan komponen tambahan untuk menangani client-server komunikasi dan dengan penamaan didistribusikan dan lokasi file.

operasi sistem file • Gambar 12.4 merangkum operasi utama pada file yang tersedia untuk aplikasi di sistem UNIX. Ini adalah panggilan sistem yang diterapkan oleh kernel; programmer aplikasi biasanya mengaksesnya melalui perpustakaan prosedur seperti C Masukan Standard / Output Perpustakaan atau kelas berkas Java. Kami memberikan primitif di sini sebagai indikasi operasi yang layanan file diharapkan dukungan dan perbandingan dengan antarmuka layanan file yang akan kita memperkenalkan bawah.

Operasi UNIX didasarkan pada model pemrograman di mana beberapa negara berkas informasi disimpan oleh sistem file untuk setiap program berjalan. Ini terdiri dari daftar dari saat membuka file dengan read-write pointer untuk masing-masing, memberikan posisi dalam file pada yang berikutnya membaca atau menulis operasi akan diterapkan.

Sistem file bertanggung jawab untuk menerapkan kontrol akses untuk file. Dalam file lokal sistem seperti UNIX, itu jadi ketika setiap file dibuka, pengecekan hak diperbolehkan untuk identitas pengguna dalam daftar kontrol akses terhadap modus akses yang diminta dalam panggilan sistem terbuka. Jika hak-hak sesuai mode, file dibuka dan modus yang dicatat dalam informasi file keadaan terbuka.

persyaratan sistemfile terdistribusi
Banyak persyaratan dan potensi jebakan dalam desain layanan terdistribusi yang pertama kali diamati dalam pengembangan awal dari sistem file terdistribusi. Awalnya, mereka menawarkan transparansi akses dan transparansi lokasi; kinerja, skalabilitas, concurrency kontrol, toleransi kesalahan dan persyaratan keamanan muncul dan bertemu di berikutnya fase pembangunan. Kami mendiskusikan kebutuhan ini dan terkait berikut ini.



Transparansi • Layanan file biasanya layanan yang paling banyak dimuat di intranet, sehingga fungsi dan kinerja sangat penting. Desain dari layanan file harus mendukung banyak persyaratan transparansi untuk sistem terdistribusi diidentifikasi di Bagian 1.5.7. desain harus menyeimbangkan fleksibilitas dan skalabilitas yang berasal dari transparansi terhadap kompleksitas perangkat lunak dan kinerja. Berikut ini bentuk transparansi sebagian atau seluruhnya ditangani oleh layanan file saat ini:

Akses transparansi: program Klien harus menyadari distribusi file. Satu set tunggal operasi disediakan untuk akses ke file lokal dan remote. Program ditulis untuk beroperasi pada file lokal dapat mengakses file remote tanpa modifikasi.



Lokasi transparansi: program Client harus melihat ruang nama file yang seragam. Arsip atau kelompok file dapat dipindahkan tanpa mengubah nama path mereka, dan user program melihat ruang nama yang sama di mana pun mereka dieksekusi.



transparansi mobilitas: Baik program klien maupun tabel sistem administrasi di node client perlu diubah ketika file dipindahkan. Hal ini memungkinkan mobilitas berkas - file atau, lebih umum, set atau volume file dapat dipindahkan, baik dengan sistem administrator atau otomatis.



Kinerja transparansi: program Client harus terus melakukan memuaskan sedangkan beban pada layanan bervariasi dalam kisaran tertentu.



Scaling transparansi: Layanan dapat diperluas dengan pertumbuhan inkremental untuk menangani dengan berbagai beban dan ukuran jaringan.



file update bersamaan • Perubahan ke file oleh salah satu klien harus tidak mengganggu operasi klien lain secara bersamaan mengakses atau mengubah file yang sama. Ini adalah masalah terkenal kontrol concurrency, dibahas secara rinci dalam Bab 16. Kebutuhan kontrol concurrency untuk akses ke data bersama dalam banyak aplikasi yang diterima secara luas dan teknik yang dikenal untuk pelaksanaannya, tetapi mereka mahal. Kebanyakan file saat ini jasa mengikuti standar UNIX yang modern dalam memberikan nasihat atau file- wajib atau penguncian record-tingkat.



replikasi berkas • Dalam layanan file yang mendukung replikasi, file dapat diwakili oleh beberapa salinan isinya di lokasi yang berbeda. Ini memiliki dua manfaat – memungkinkan beberapa server untuk berbagi beban menyediakan layanan untuk klien mengakses set yang sama file, meningkatkan skalabilitas layanan, dan meningkatkan toleransi kesalahan oleh memungkinkan klien untuk mencari server lain yang memegang salinan file ketika salah satu telah gagal. Beberapa layanan file dukungan replikasi penuh, tetapi sebagian besar mendukung caching file atau bagian dari file lokal, bentuk terbatas dari replikasi. Replikasi data dibahas dalam Bab 18, yang mencakup deskripsi dari layanan file Coda direplikasi.



Hardware dan sistem operasi heterogenitas • Antarmuka layanan harus de- didenda sehingga klien dan perangkat lunak server dapat diimplementasikan untuk sistem operasi yang berbeda dan komputer. Persyaratan ini merupakan aspek penting dari keterbukaan.



Toleransi kesalahan • Peran sentral dari layanan file dalam sistem terdistribusi membuatnya penting bahwa layanan terus beroperasi dalam menghadapi kegagalan klien dan server. Untungnya, desain cukup toleran sangat mudah untuk server sederhana. Untuk mengatasi kegagalan komunikasi sementara, desain dapat didasarkan pada di-paling-sekali semantik doa (lihat Bagian 5.3.1); atau dapat menggunakan sederhana di-setidaknya-sekali semantik dengan protokol server yang dirancang dalam hal operasi idempoten, memastikan bahwa permintaan digandakan tidak mengakibatkan update valid untuk file. Server dapat stateless, sehingga mereka bisa restart dan layanan dipulihkan setelah kegagalan tanpa perlu untuk memulihkan keadaan sebelumnya. Toleransi pemutusan atau server kegagalan membutuhkan berkas replikasi, yang lebih sulit dicapai dan akan dibahas dalam Bab 18.



Konsistensi • file sistem konvensional seperti yang disediakan di UNIX tawaran satu-copy pembaruan semantik. Hal ini mengacu pada model untuk akses bersamaan ke file di mana file Isi dilihat oleh semua proses mengakses atau memperbarui file yang diberikan adalah mereka yang mereka akan melihat jika hanya satu salinan dari isi file ada. Ketika file direplikasi atau cache di lokasi yang berbeda, ada penundaan tak terelakkan dalam penyebaran modifikasi dibuat di satu situs ke semua situs lain yang memegang salinan, dan ini dapat mengakibatkan beberapa penyimpangan dari semantik satu-copy.

Keamanan • Hampir semua sistem file menyediakan mekanisme akses kontrol berdasarkan penggunaan daftar kontrol akses. Dalam sistem file terdistribusi, ada kebutuhan untuk mengotentikasi permintaan klien sehingga kontrol akses di server didasarkan pada identitas pengguna yang benar dan untuk melindungi isi permintaan dan membalas pesan dengan tanda tangan digital dan (Opsional) enkripsi data rahasia. Kami membahas dampak dari persyaratan ini di kasus studi kemudian dalam bab ini.

Efisiensi • Sebuah layanan file terdistribusi harus menawarkan fasilitas yang minimal sama kekuasaan dan umum yang ditemukan dalam file sistem konvensional dan harus mencapai tingkat yang sebanding kinerja. Birrell dan Needham [1980] menyatakan desain mereka bertujuan untuk Cambridge File Server (CFS) dalam hal ini:

Kami akan ingin memiliki sederhana, file server tingkat rendah dalam rangka untuk berbagi sumber daya mahal, yaitu disk, sementara meninggalkan kami bebas untuk merancang pengajuan sistem yang paling tepat untuk klien tertentu, tapi kami akan berharap juga untuk memiliki tersedia sistem tingkat tinggi bersama antara klien. ekonomi yang berubah dari penyimpanan disk telah mengurangi pentingnya gol pertama mereka, namun persepsi mereka tentang kebutuhan untuk berbagai layanan menangani persyaratan klien dengan tujuan yang berbeda tetap dan dapat terbaik dari jenis yang diuraikan di atas.

Teknik yang digunakan untuk pelaksanaan layanan file merupakan bagian penting dari desain sistem terdistribusi. Sebuah sistem file terdistribusi harus menyediakan layanan yang sebanding dengan, atau lebih baik dari sistem file lokal dalam kinerja dan kehandalan. Ini harus mudah untuk mengelola, menyediakan operasi dan alat-alat yang memungkinkan sistem administrator untuk menginstal dan mengoperasikan sistem nyaman.

Studi Kasus
Kami telah membangun sebuah model abstrak untuk layanan file untuk bertindak sebagai pengantar Misalnya, memisahkan kekhawatiran pelaksanaan dan menyediakan model yang disederhanakan. Kami menggambarkan Sun Network File System di beberapa detail, menggambar pada abstrak sederhana kami Model untuk memperjelas arsitektur. Andrew File System kemudian dijelaskan, memberikan Mengingat sistem file terdistribusi yang mengambil pendekatan yang berbeda untuk skalabilitas dan pemeliharaan konsistensi.



Arsitektur layanan file • Ini adalah sebuah model arsitektur abstrak yang mendasari kedua NFS dan AFS. Hal ini didasarkan pada pembagian tanggung jawab antara tiga modul – a modul klien yang mengemulasi antarmuka sistem file konvensional untuk aplikasi program, dan server modul, yang melakukan operasi untuk klien pada direktori dan file. Arsitektur ini dirancang untuk memungkinkan implementasi stateless dari server modul.



SUN NFS • Sun Microsystems Network File System (NFS) telah banyak diadopsi dalam industri dan di lingkungan akademik sejak diperkenalkan pada tahun 1985. Desain dan pengembangan NFS yang dilakukan oleh staf di Sun Microsystems pada tahun 1984 [Sandberg et al. 1985, Sandberg 1987, Callaghan 1999]. Meskipun beberapa layanan file terdistribusi sudah dikembangkan dan digunakan di universitas-universitas dan laboratorium penelitian, NFS adalah layanan file pertama yang dirancang sebagai produk. Desain dan implementasi NFS telah mencapai keberhasilan baik secara teknis dan komersial.



Untuk mendorong adopsi sebagai standar, definisi antarmuka kunci yang ditempatkan dalam domain publik [Sun 1989], memungkinkan vendor lainnya untuk menghasilkan implementasi, dan kode sumber untuk implementasi referensi dibuat tersedia untuk vendor komputer lainnya di bawah lisensi. Hal ini sekarang didukung oleh banyak vendor, dan protokol NFS (versi 3) adalah standar Internet, didefinisikan dalam RFC 1813 [Callaghan et al. 1995]. Callaghan buku tentang NFS [Callaghan 1999] adalah sangat baik sumber pada desain dan pengembangan NFS dan topik terkait.

NFS menyediakan akses transparan ke file remote untuk program klien yang berjalan pada UNIX dan sistem lainnya. Hubungan client-server simetris: setiap komputer
dalam jaringan NFS dapat bertindak sebagai klien dan server, dan file pada setiap mesin
dapat dibuat tersedia untuk akses remote oleh komputer lain. Setiap komputer bisa menjadi
Server, mengekspor beberapa file, serta klien, mengakses file pada mesin lain. Tetapi
adalah praktek umum untuk mengkonfigurasi instalasi yang lebih besar dengan beberapa mesin yang didedikasikan server dan lain-lain sebagai workstation.

Tujuan penting dari NFS adalah untuk mencapai tingkat tinggi dukungan untuk hardware dan sistem operasi heterogenitas. Desain ini sistem-independen operasi: klien dan implementasi server ada untuk hampir semua sistem operasi dan platform, termasuk
semua versi Windows, Mac OS, Linux dan setiap versi lain dari UNIX. Implementasi NFS pada kinerja tinggi multiprosesor host telah dikembangkan oleh beberapa vendor, dan ini banyak digunakan untuk memenuhi kebutuhan penyimpanan di intranet dengan banyak pengguna bersamaan.



Andrew File System • Andrew adalah lingkungan komputasi terdistribusi yang dikembangkan di Carnegie Mellon University (CMU) untuk digunakan sebagai komputasi kampus dan informasi sistem [Morris et al. 1986]. Desain dari Andrew File System (selanjutnya disingkat AFS) mencerminkan niat untuk mendukung berbagi informasi dalam skala besar oleh meminimalkan komunikasi client-server. Hal ini dicapai dengan mentransfer seluruh file antara server dan komputer klien dan caching mereka pada klien sampai server menerima versi yang lebih up-to-date. Kami akan menjelaskan AFS-2, 'produksi' pertama pelaksanaan, berikut deskripsi oleh Satyanarayanan [1989a, 1989b]. Lebih deskripsi baru-baru ini dapat ditemukan di Campbell [1997] dan [Linux AFS].

AFS awalnya diimplementasikan pada jaringan workstation dan server berjalan BSD UNIX dan sistem operasi Mach di CMU dan kemudian dibuat tersedia dalam versi komersial dan publik-domain. Implementasi publik-domain dari AFS tersedia dalam sistem operasi Linux [Linux AFS]. AFS diadopsi sebagai dasar untuk sistem file DCE / DFS di Open Software Foundation Terdistribusi Computing Environment (DCE) [www.opengroup.org]. Desain DCE / DFS pergi luar AFS dalam beberapa hal penting, yang kita menguraikan dalam Bagian 12.5.



ArsitekturLayanan File
Arsitektur yang menawarkan pemisahan yang jelas dari keprihatinan utama dalam menyediakan akses untuk file diperoleh dengan penataan layanan file sebagai tiga komponen - layanan file flat, layanan direktori dan modul klien. Modul yang relevan dan hubungan mereka ditunjukkan pada Gambar 12.5. Layanan flat file dan layanan direktori masing-masing mengekspor antarmuka untuk digunakan oleh program client, dan interface RPC mereka, diambil bersama-sama, memberikan seperangkat operasi untuk akses ke file. Modul klien menyediakan satu pemrograman antarmuka dengan operasi pada file yang sama dengan yang ditemukan di konvensional file sistem. Desain terbuka dalam arti bahwa modul klien yang berbeda dapat digunakan untuk mengimplementasikan antarmuka pemrograman yang berbeda, simulasi operasi file dari varietas dari sistem operasi yang berbeda dan mengoptimalkan kinerja untuk klien yang berbeda dan konfigurasi hardware server.

Pembagian tanggung jawab antara modul dapat didefinisikan sebagai berikut:

Layanan flat file • Layanan file flat yang bersangkutan dengan operasi mengimplementasikan pada isi dari file. Unik berkas pengenal (UUIDs) digunakan untuk merujuk ke file di semua permintaan untuk operasi layanan flat file. Pembagian tanggung jawab antara layanan file dan layanan direktori didasarkan pada penggunaan RFIDs. ID UF adalah urutan panjang bit dipilih sehingga setiap file memiliki UFID yang unik di antara semua file dalam.



Gambar 12.5 Arsitektur Layanan File

sistem terdistribusi. Ketika layanan file flat menerima permintaan untuk membuat file,
menghasilkan UUID baru untuk itu dan mengembalikan UFID kepada pemohon.



layanan direktori • The layanan direktori menyediakan pemetaan antara nama teks untuk
file dan UF ITs mereka. Klien dapat memperoleh UFID file dengan mengutip nama teks untuk layanan direktori. Layanan direktori menyediakan fungsi yang dibutuhkan untuk menghasilkan direktori, untuk menambahkan nama file baru ke direktori dan untuk mendapatkan UUIDs dari direktori. Saya t adalah klien dari layanan flat file; file direktorinya disimpan dalam file dari flat file layanan. Ketika skema penamaan file hierarkis diadopsi, seperti dalam UNIX, direktori terus referensi ke direktori lain.



Modul Klien • Sebuah modul klien berjalan di setiap komputer client, mengintegrasikan dan memperluas operasi layanan flat file dan layanan direktori di bawah satu antarmuka pemrograman aplikasi yang tersedia untuk program tingkat pengguna di klien komputer. Misalnya, di host UNIX, modul klien akan diberikan bahwa mengemulasi set lengkap operasi file UNIX, menafsirkan UNIX nama file multi-bagian oleh permintaan berulang untuk layanan direktori. Modul klien juga menyimpan informasi tentang lokasi jaringan file server dan server direktori proses datar. Akhirnya, modul klien dapat memainkan peran penting dalam mencapai kinerja yang memuaskan melalui penerapan cache blok file baru digunakan pada klien.



Layanan antarmuka datar berkas • Gambar 12.6 berisi definisi antarmuka ke file datar
layanan. Ini adalah antarmuka RPC yang digunakan oleh modul klien. Hal ini biasanya tidak digunakan secara langsung oleh program user-level. Sebuah fileId tidak valid jika file yang mengacu pada tidak hadir dalam Server memproses permintaan atau jika izin aksesnya yang pantas untuk operasi yang diminta. Semua prosedur dalam antarmuka kecuali Buat lemparan
pengecualian dari argumen fileId berisi UUID valid atau pengguna tidak memiliki hak akses yang memadai. pengecualian ini dihilangkan dari definisi untuk kejelasan.



Operasi yang paling penting adalah mereka untuk membaca dan menulis. Kedua Baca dan operasi Menulis memerlukan parameter dalam menentukan posisi dalam file. Read salinan operasi urutan n item data dimulai pada item i dari file yang ditentukan









Gambar 12.6 Operasi layanan flat file

dalam data, yang kemudian dikembalikan ke klien. Write operasi salinan urutan item data dalam data ke file yang ditentukan dimulai pada item i, menggantikan sebelumnya isi file pada posisi yang sesuai dan memperluas file jika diperlukan.

Buat menciptakan baru, file kosong dan mengembalikan UFID yang dihasilkan. Menghapus menghapus file yang ditentukan.

GetAttributes dan GetAttributes memungkinkan klien untuk mengakses record atribut. GetAttributes biasanya tersedia untuk setiap klien yang diperbolehkan untuk membaca file. Mengakses untuk operasi setAttributes biasanya akan terbatas pada layanan direktori yang menyediakan akses ke file. Nilai-nilai dari panjang dan timestamp bagian dari atribut catatan tidak terpengaruh oleh setAttributes; mereka secara terpisah oleh Layanan flat file itu sendiri.

Perbandingan dengan UNIX: antarmuka kami dan sistem file UNIX primitif yang fungsional setara. Ini adalah masalah sederhana untuk membangun modul klien yang mengemulasi sistem UNIX panggilan dari segi layanan file kita datar dan layanan direktori operasi yang dijelaskan pada bagian berikutnya.

Dibandingkan dengan antarmuka UNIX, layanan file kami datar tidak memiliki membuka dan menutup operasi - file dapat diakses langsung dengan mengutip UFID yang sesuai. Itu Membaca dan Menulis permintaan di antarmuka kami meliputi parameter menentukan titik awal dalam file untuk setiap transfer, sedangkan operasi UNIX setara tidak. Di UNIX, masing-masing membaca atau menulis operasi dimulai pada posisi saat ini dari baca-tulis pointer, dan baca-tulis pointer maju dengan jumlah byte yang ditransfer setelah setiap membaca atau menulis. Sebuah operasi mencari disediakan untuk mengaktifkan read-write pointer menjadi eksplisit reposisi.

Antarmuka untuk layanan file kita datar berbeda dari antarmuka sistem file UNIX terutama untuk alasan toleransi kesalahan:

Operasi file UNIX yang tidak idempoten atau konsisten dengan persyaratan untuk implementasi stateless. Sebuah read-write pointer yang dihasilkan oleh sistem file UNIX setiap kali file dibuka, dan itu dipertahankan, bersama-sama dengan hasil akses-kontrol pemeriksaan, sampai file ditutup. UNIX membaca dan menulis operasi tidak idempoten; jika operasi sengaja diulang, kemajuan otomatis dari read-write pointer hasil dalam akses ke porsi yang berbeda dari file dalam operasi diulang. baca-tulis yang pointer adalah tersembunyi, terkait klien variabel negara. Untuk meniru dalam file server, terbuka dan operasi dekat akan diperlukan, dan nilai read-write pointer ini harus menjadi dipertahankan oleh server selama file yang relevan terbuka. Dengan menghilangkan read-write pointer, kami telah menghilangkan sebagian kebutuhan untuk file server untuk mempertahankan negara informasi atas nama klien tertentu.



kontrol akses • Dalam sistem file UNIX, hak akses pengguna diperiksa terhadap mode akses (membaca atau menulis) yang diminta dalam panggilan terbuka (Gambar 12.4 menunjukkan UNIX sistem file API) dan berkas dibuka hanya jika pengguna memiliki hak yang diperlukan. Pengguna identitas (UID) yang digunakan dalam cek hak akses diambil selama pengguna sebelumnya dikonfirmasi login dan tidak dapat dirusak dalam implementasi non-didistribusikan. hak akses yang dihasilkan dipertahankan sampai file ditutup, dan tidak lebih diperlukan bila operasi berikutnya pada file yang sama diminta.



Dalam implementasi didistribusikan, cek hak akses harus dilakukan pada Server karena antarmuka RPC server adalah titik dinyatakan tidak dilindungi dari akses ke file. Sebuah identitas pengguna harus dilalui dengan permintaan, dan server rentan terhadap ditempa identitas. Selain itu, jika hasil pemeriksaan hak akses dipertahankan di server dan digunakan untuk akses masa depan, server tidak akan lagi menjadi stateless. Dua pendekatan alternatif untuk masalah yang terakhir dapat diadopsi:

Pemeriksaanaksesdibuatsetiap kalinama filediubah menjadiUFID, danHasildikodekandalam bentukkemampuan(lihatBagian2.4), yang merupakankembali keklienuntukpengajuandenganpermintaan berikutnya.
Sebuahidentitas penggunadisampaikandengan setiappermintaan klien, dan aksespemeriksaanyangdilakukan olehserveruntuk setiapoperasi file.


layanan antarmuka direktori • Gambar 12.7 berisi definisi dari interface RPC ke layanan direktori. Tujuan utama dari layanan direktori adalah untuk menyediakan layanan untuk menerjemahkan nama teks ke ID. Untuk melakukannya, ia mempertahankan file direktori yang berisi



Gambar 12.7 Operasi Layanan Direktori



Penyediaan pencocokan pola dalam operasi getNames memungkinkan pengguna untuk menentukan nama dari satu atau lebih file dengan memberikan spesifikasi lengkap dari karakter dalam nama. Sebuah ekspresi reguler adalah spesifikasi untuk kelas string dalam bentuk ekspresi yang mengandung kombinasi dari substring literal dan simbol yang menunjukkan karakter variabel atau kejadian berulang karakter atau substring.



sistem file hirarki • Sebuah sistem file hirarki seperti salah satu yang UNIX menyediakan terdiri dari sejumlah direktori diatur dalam struktur pohon. Setiap direktori memegang nama-nama file dan direktori lain yang dapat diakses dari itu. Setiap berkas atau direktori dapat dirujuk menggunakan pathname - nama multi-bagian yang mewakili jalan melalui BAGIAN 12.2 FILE SERVICE ARCHITECTURE 535 pohon. akar memiliki nama dibedakan, dan setiap file atau direktori memiliki nama dalam direktori. Skema penamaan file UNIX bukanlah hirarki yang ketat - file dapat memiliki beberapa nama, dan mereka dapat berada di direktori yang sama atau berbeda. Hal ini dilaksanakan oleh Link operasi, yang menambahkan nama baru untuk file ke direktori tertentu.



kelompok file • Sekelompok file adalah kumpulan file yang terletak di server tertentu. Sebuah server mungkin memegang beberapa file kelompok, dan kelompok dapat dipindahkan antara server, tetapi file tidak bisa mengubah kelompok mana ia berasal. Sebuah membangun serupa yang disebut filesystem yang digunakan di UNIX dan di sebagian besar sistem operasi lain. (Terminologi catatan: kata tunggal filesystem mengacu pada set file yang diadakan di perangkat penyimpanan atau partisi, sedangkan kata-kata sistem file mengacu pada komponen software yang menyediakan akses ke file.) kelompok file yang awalnya diperkenalkan untuk mendukung fasilitas untuk memindahkan koleksi file yang tersimpan di removable media antara komputer. Dalam layanan file terdistribusi, kelompok file yang mendukung alokasi file ke file server dalam unit logis yang lebih besar dan memungkinkan layanan untuk menjadi diimplementasikan dengan file yang tersimpan pada beberapa server. Dalam sistem file terdistribusi yang mendukung file kelompok, representasi AIDS termasuk pengenal kelompok berkas komponen, memungkinkan modul klien dalam setiap komputer klien untuk mengambil tanggung jawab pengiriman permintaan ke server yang memegang kelompok file relevan.

pengidentifikasi file group harus unik di seluruh sistem terdistribusi. karena file kelompok dapat dipindahkan dan sistem yang awalnya terpisah dapat digabungkan didistribusikan untuk membentuk sebuah sistem tunggal, satu-satunya cara untuk memastikan bahwa pengenal kelompok file yang akan selalu yang berbeda dalam sistem yang diberikan adalah untuk menghasilkan mereka dengan algoritma yang menjamin global yang keunikan. Misalnya, setiap kali kelompok file yang baru dibuat, pengenal unik bisa dihasilkan dengan menggabungkan 32-bit alamat IP dari host menciptakan grup baru dengan bilangan bulat 16-bit yang berasal dari tanggal, menghasilkan 48-bit integer yang unik:

Perhatikan bahwa alamat IP tidak dapat digunakan untuk tujuan menemukan kelompok file, karena mungkin pindah ke server lain. Sebaliknya, pemetaan antara pengenal kelompok dan server harus dipertahankan oleh layanan file.



Gambar 12.8 Arsitektur NFS

Studi Kasus : Sun Network File System
Gambar 12.8 menunjukkan arsitektur dari Sun NFS. Ini mengikuti model abstrak yang didefinisikan dalam sebelumnya bagian. Semua implementasi dari NFS mendukung protokol NFS - satu set terpencil panggilan prosedur yang menyediakan sarana untuk klien untuk melakukan operasi pada toko file jarak jauh. Protokol NFS sistem-independen operasi tapi awalnya dikembangkan untuk digunakan dalam jaringan sistem UNIX, dan kami akan menggambarkan UNIX implementasi protokol NFS (versi 3).

NFS klien dan server modul berkomunikasi menggunakan panggilan prosedur remote. sistem RPC Sun, dijelaskan dalam Bagian 5.3.3, dikembangkan untuk digunakan dalam NFS. Hal ini dapat dikonfigurasi untuk menggunakan UDP atau TCP, dan protokol NFS kompatibel dengan keduanya. SEBUAH layanan pelabuhan mapper termasuk untuk memungkinkan klien untuk mengikat ke layanan dalam host yang diberikan oleh nama. RPC antarmuka untuk server NFS terbuka: proses apapun dapat mengirim permintaan ke NFS Server; jika permintaan yang valid dan mereka termasuk kredensial pengguna yang valid, mereka akan ditindaklanjuti. Pengajuan kredensial pengguna ditandatangani dapat diperlukan sebagai opsional fitur keamanan, seperti dapat enkripsi data untuk privasi dan integritas.

Virtual sistem file • Gambar 12.8 menjelaskan bahwa NFS menyediakan transparansi akses: program pengguna dapat mengeluarkan operasi file untuk file lokal atau remote tanpa perbedaan. Lainnya sistem file terdistribusi dapat hadir yang mendukung panggilan sistem UNIX, dan jika demikian, mereka bisa diintegrasikan dengan cara yang sama.

Pengidentifikasi file yang digunakan dalam NFS disebut menangani file. Sebuah menangani file buram untuk klien dan berisi informasi apapun server perlu untuk membedakan individu mengajukan. Dalam UNIX implementasi dari NFS, yang menangani file berasal dari inode file ini nomor dengan menambahkan dua bidang tambahan sebagai berikut (jumlah i-node dari sebuah file UNIX adalah Jumlah yang berfungsi untuk mengidentifikasi dan menemukan file dalam sistem file di mana file
disimpan):

NFS mengadopsi UNIX filesystem mountable sebagai unit file pengelompokan didefinisikan dalam sebelumnya bagian. Bidang filesystem identifier adalah nomor unik yang dialokasikan untuk setiap filesystem ketika dibuat (dan dalam pelaksanaan UNIX disimpan dalam superblok dari sistem file). Jumlah generasi i-node diperlukan karena dalam nomor file sistem konvensional UNIX i-node digunakan kembali setelah file dihapus. Dalam VFS ekstensi ke sistem file UNIX, sejumlah generasi disimpan dengan setiap file dan bertambah setiap kali jumlah i-node digunakan kembali (misalnya, dalam creat UNIX system call). klien mendapatkan file handle pertama untuk sistem file jarak jauh ketika gunung itu. menangani file dilewatkan dari server ke klien dalam hasil pencarian, buat dan operasi mkdir (lihat Gambar 12.9) dan semua operasi server yang.



integrasi klien • The NFS modul klien memainkan peran dijelaskan untuk klien modul dalam model arsitektur kami, memasok antarmuka cocok digunakan oleh program aplikasi konvensional. Tapi tidak seperti modul model client kami, itu mengemulasi semantik sistem file UNIX standar primitif tepat dan terintegrasi dengan kernel UNIX. Hal ini terintegrasi dengan kernel dan tidak disertakan sebagai perpustakaan untuk loading ke dalam proses client sehingga:

program pengguna dapat mengakses file melalui sistem UNIX panggilan tanpa kompilasi ulang atau reload;
modul klien tunggal melayani semua proses user-level, dengan shared cache dari yang terakhir digunakan blok (dijelaskan di bawah);


Modul klien NFS bekerja sama dengan sistem file virtual di setiap mesin klien. Saya t beroperasi dengan cara yang sama ke sistem file UNIX konvensional, mentransfer blok file ke dan dari server dan caching blok dalam memori lokal setiap kali mungkin. Ini saham cache buffer yang sama yang digunakan oleh sistem input-output lokal. BAGIAN 12.3 STUDI KASUS: SISTEM SUN NETWORK FILE 539 Tapi karena beberapa klien di mesin host yang berbeda dapat secara simultan mengakses sama file jarak jauh, masalah konsistensi persediaan baru dan signifikan muncul.



Kontrol Akses Dan Otentikasi • Tidak seperti sistem file UNIX konvensional, NFS server stateless dan tidak menyimpan file terbuka atas nama klien. Jadi server harus memeriksa identitas pengguna terhadap izin akses file itu atribut lagi pada masing-masing meminta, untuk melihat apakah pengguna diijinkan untuk mengakses file dengan cara diminta. Protokol Sun RPC membutuhkan klien untuk mengirim informasi otentikasi pengguna (untuk Misalnya, konvensional UNIX 16-bit ID pengguna dan kelompok ID) dengan setiap permintaan dan ini diperiksa terhadap izin akses di atribut berkas. ini tambahan parameter tidak ditampilkan dalam ikhtisar dari protokol NFS pada Gambar 12,9; mereka disediakan secara otomatis oleh sistem RPC.



Dalam bentuk yang paling sederhana, ada celah keamanan di akses mekanisme kontrol ini. Server NFS menyediakan antarmuka RPC konvensional di pelabuhan terkenal pada setiap host dan proses apapun dapat berperilaku sebagai klien, mengirimkan permintaan ke server untuk mengakses atau memperbarui file. Klien dapat memodifikasi RPC panggilan untuk menyertakan ID pengguna dari setiap pengguna, meniru pengguna tanpa sepengetahuan atau izin mereka. celah keamanan ini telah ditutup dengan menggunakan opsi dalam protokol RPC untuk enkripsi DES dari informasi otentikasi pengguna. Baru-baru ini, Kerberos telah terintegrasi dengan Sun NFS untuk memberikan solusi yang lebih kuat dan komprehensif untuk masalah pengguna otentikasi dan keamanan; kami jelaskan di bawah ini.



Antarmuka NFS server • Sebuah representasi yang disederhanakan dari antarmuka RPC yang disediakan oleh Versi NFS 3 server (didefinisikan dalam RFC 1813 [Callaghan et al. 1995]) ditunjukkan pada Gambar 12,9. NFS operasi akses file membaca, menulis, getattr dan setattr hampir identik dengan Baca, Tulis, GetAttributes dan operasi GetAttributes ditetapkan untuk file flat kami model layanan (Gambar 12.6). Lookup operasi dan sebagian besar direktori lain operasi didefinisikan pada Gambar 12.9 adalah sama dengan yang di model layanan direktori kami (Gambar 12.7).



Mount layanan • Pemasangan sub pohon dari sistem file jarak jauh oleh klien didukung oleh proses pelayanan gunung terpisah yang berjalan pada tingkat pengguna pada setiap komputer server NFS. Pada setiap server, ada file dengan nama terkenal (/ etc / ekspor) yang berisi nama-nama filesystem lokal yang tersedia untuk pemasangan jarak jauh. Daftar akses terkait dengan setiap nama filesystem yang menunjukkan host yang diizinkan untuk me-mount berkas sistem.



Gambar 12.10 Local and remote filesystems accessible on an NFS client



Catatan: Sistem file mount di / usr / siswa di klien sebenarnya adalah subtree terletak di / ekspor / orang di Server 1; filesystem mount di / usr / staf di klien sebenarnya subtree terletak di / nfs / pengguna di Server 2.



dengan layanan proses mount pada remote host menggunakan protokol mount. Ini adalah sebuah protokol RPC dan termasuk sebuah operasi yang membutuhkan pathname direktori dan mengembalikan menangani file dari direktori tertentu jika klien memiliki izin akses untuk relevan berkas sistem. Lokasi (alamat IP dan nomor port) dari server dan menangani file untuk direktori remote diteruskan ke lapisan VFS dan klien NFS.

Gambar 12.10 orang dan pengguna dalam sistem file pada Server 1 dan Server 2 dipasang lebih node siswa dan staf di toko file lokal Klien. Artinya ini adalah bahwa program berjalan Klien dapat mengakses file pada Server 1 dan Server 2 dengan menggunakan nama path seperti / Usr / siswa / jon dan / usr / staf / ann. menggambarkan Klien dengan dua toko berkas jarak jauh dipasang. Node



sistem file jarak jauh mungkin sulit-mount atau soft-mount di komputer klien. Ketika proses user-level mengakses file di filesystem yang sulit-mount, yang Proses ditunda sampai permintaan dapat diselesaikan, dan jika remote host adalah tidak tersedia untuk alasan apapun modul klien NFS terus mencoba lagi permintaan sampai puas. Jadi dalam kasus kegagalan server, proses user-level ditangguhkan sampai server restart dan kemudian mereka terus saja seolah-olah tidak pernah ada kegagalan. Tapi jika filesystem yang relevan adalah soft-mount, modul klien NFS mengembalikan kegagalan indikasi untuk proses user-level setelah sejumlah kecil retries. benar dibangun program maka akan mendeteksi kegagalan dan mengambil pemulihan yang tepat atau tindakan pelaporan. Tapi banyak utilitas UNIX dan aplikasi tidak menguji kegagalan akses file operasi, dan berperilaku dalam cara yang tak terduga dalam kasus kegagalan lunak yang mount filesystem. Untuk alasan ini, banyak instalasi menggunakan keras pemasangan eksklusif, dengan konsekuensi bahwa program tidak dapat memulihkan anggun ketika NFS server tidak tersedia untuk jangka waktu yang signifikan.



terjemahan pathname • UNIX file sistem menerjemahkan nama file path multi-bagian untuk i node referensi dalam proses langkah-demi-langkah setiap kali terbuka, creat atau Stat sistem panggilan bekas. Dalam NFS, nama-nama jalan tidak dapat diterjemahkan di server, karena nama dapat melintasi BAGIAN 12.3 STUDI KASUS: SISTEM SUN NETWORK FILE 541 'Mount point' pada klien - direktori memegang bagian yang berbeda dari nama multi-bagian mungkin berada di filesystem di server yang berbeda. Jadi nama path yang diurai, dan terjemahan mereka dilakukan secara berulang oleh klien. Setiap bagian dari nama yang mengacu pada direktori remote-mount diterjemahkan ke file menangani menggunakan permintaan pencarian yang terpisah ke server remote.



Automounter • automounter telah ditambahkan ke pelaksanaan UNIX dari NFS di Untuk me-mount direktori remote dinamis setiap kali 'kosong' mount point adalah direferensikan oleh klien. Pelaksanaan asli dari automounter berlari sebagai user- a tingkat proses UNIX di setiap komputer client. Kemudian versi (disebut autofs) yang diimplementasikan dalam kernel untuk Solaris dan Linux. Kami menjelaskan versi asli di sini.



Server caching • Caching di kedua klien dan komputer server sangat diperlukan fitur implementasi NFS dalam rangka mencapai kinerja yang memadai.



Server NFS menggunakan cache pada mesin server seperti itu digunakan untuk file lain mengakses. Penggunaan cache server untuk menahan baru saja membaca blok disk tidak meningkatkan masalah konsistensi; tapi ketika server melakukan operasi tulis, langkah-langkah tambahan diperlukan untuk memastikan bahwa klien dapat yakin bahwa hasil menulis operasi gigih, bahkan ketika server crash terjadi. Dalam versi 3 dari protokol NFS, yang menulis operasi menawarkan dua pilihan untuk ini (tidak ditampilkan pada Gambar 12.9):

Datadalam operasitulisyang diterima darikliendisimpan dalamcachememoridiserver danditulis ke disk sebelumbalasandikirim keklien. Ini disebutWrite-melaluicaching. Kliendapat yakinbahwa data yangdisimpanterus-menerussecepatsebagaibalasantelah diterima.
Datadalam operasiwritedisimpan hanyadalam cachememori. Iniakan ditulis kedisk saatoperasi komitditerimauntuk fileyang relevan. klien dapatPastikanbahwa data yangterus-menerusdisimpanhanya ketikabalasanuntukoperasikomituntukfileyang relevantelah diterima. StandardklienNFSmenggunakanmode inioperasi, mengeluarkankomitsetiap kalifile yangterbuka untukmenulisditutup.
Klien caching • Modul NFS client cache hasil membaca, menulis, getattr, lookup dan readdir operasi untuk mengurangi jumlah permintaan yang dikirimkan ke server. Klien caching memperkenalkan potensi berbagai versi file atau bagian file ada di node klien yang berbeda, karena menulis dengan klien tidak mengakibatkan memperbarui segera salinan cache dari file yang sama di klien lainnya. Sebaliknya, klien bertanggung jawab untuk polling server untuk memeriksa mata uang dari data cache yang mereka pegang.



Sebuah entri cache berlaku pada saat T jika T - Tc kurang dari t selang kesegaran, atau jika nilai untuk Tm tercatat klien sesuai dengan nilai Tm di server (yaitu, data yang memiliki belum diubah di server sejak entri cache dibuat). Secara formal, validitas Kondisi ini:

(T Tc –  t Tmclient= Tmserver)

Beberapa langkah-langkah yang digunakan untuk mengurangi lalu lintas panggilan getattr ke server:

Setiap kali nilai baru dari Tmserver diterima di klien, itu diterapkan untuk semua tembolok entri berasal dari file yang relevan.
Nilai-nilai atribut saat dikirim 'piggybacked' dengan hasil setiap operasi pada file, dan jika nilai Tmserver telah berubah klien menggunakannya untuk memperbarui entri cache yang berkaitan dengan file.
Algoritma adaptif untuk menetapkan kesegaran selang t diuraikan di atas mengurangi lalu lintas cukup untuk sebagian besar file.


Studi Kasus : The Andrew File System
AFS berbeda nyata dari NFS dalam desain dan implementasi. Perbedaan terutama disebabkan identifikasi skalabilitas sebagai desain yang paling penting tujuan. AFS dirancang untuk melakukan dengan baik dengan angka yang lebih besar dari pengguna aktif dibandingkan lainnya sistem file terdistribusi. Strategi kunci untuk mencapai skalabilitas adalah caching Seluruh file di node klien. AFS memiliki dua karakteristik desain yang tidak biasa:

Seluruh file porsi: Seluruh isi dari direktori dan file ditransmisikan ke komputer klien oleh server AFS (di AFS-3, file yang lebih besar dari 64 byte ditransfer dalam potongan 64-kbyte).

Whole-file caching: Setelah salinan file atau sepotong telah ditransfer ke komputer klien disimpan dalam cache pada disk lokal. cache berisi beberapa ratus file yang paling terakhir digunakan pada komputer itu. cache permanen, selamat reboot dari komputer klien. salinan lokal file yang digunakan untuk permintaan terbuka klien dalam preferensi untuk salinan terpencil bila memungkinkan.

Skenario • Berikut ini adalah skenario sederhana yang menggambarkan operasi AFS:

Ketika proses pengguna di komputer client mengeluarkan panggilan sistem terbuka untuk file dalam ruang file bersama dan tidak ada salinan terbaru dari file di cache lokal, server memegang file terletak dan mengirimkan permintaan untuk salinan file.
copy disimpan dalam sistem file UNIX lokal di komputer klien. Salinan kemudian dibuka dan mengakibatkan UNIX file descriptor dikembalikan ke klien.
Setelah membaca, menulis dan operasi lain pada file dengan proses di klien komputer diterapkan pada salinan lokal.
Ketika proses di klien mengeluarkan system call dekat, jika salinan lokal telah diperbarui isinya dikirim kembali ke server. update server file isi dan cap waktu pada file. Copy pada disk lokal klien adalah ditahan dalam kasus itu dibutuhkan lagi oleh proses user-level pada workstation yang sama.
Kami membahas kinerja diamati dari AFS bawah, tapi kita bisa membuat beberapa umum pengamatan dan prediksi di sini didasarkan pada karakteristik desain yang dijelaskan di atas:

Untuk berbagi file yang jarang diperbarui (seperti yang mengandung kode UNIX perintah dan perpustakaan) dan untuk file yang biasanya diakses oleh hanya satu pengguna (seperti sebagian besar file dalam direktori home pengguna dan subpohon), lokal salinan cache akan tetap berlaku untuk waktu yang lama - dalam kasus pertama karena mereka tidak diperbarui dan dalam kedua karena jika mereka diperbarui, diperbarui copy akan di cache pada pemilik workstation. Ini account untuk mayoritas file akses.
Cache lokal dapat dialokasikan sebagian besar ruang disk pada setiap workstation - mengatakan, 100 megabyte. Hal ini biasanya cukup untuk pembentukan dari satu set kerja file yang digunakan oleh satu pengguna. Penyediaan cache yang cukup penyimpanan untuk pembentukan satu set bekerja memastikan bahwa file digunakan secara teratur pada diberikan workstation biasanya dipertahankan dalam cache sampai mereka dibutuhkan lagi.
Strategi desain didasarkan pada beberapa asumsi tentang rata-rata dan maksimum ukuran file dan lokalitas referensi ke file di sistem UNIX. asumsi ini berasal dari pengamatan beban kerja UNIX khas dalam akademik dan lainnya lingkungan [Satyanarayanan 1981, Ousterhout et al. 1985, Floyd 1986]. Itu paling pengamatan penting adalah:
File kecil; paling kurang dari 10 kilobyte dalam ukuran.
Baca operasi pada file jauh lebih umum daripada menulis (sekitar enam kali
lebih umum).
Akses Sequential adalah umum, dan akses acak jarang.
Sebagian besar file yang dibaca dan ditulis oleh hanya satu pengguna. Ketika sebuah file bersama, itu adalah biasanya hanya satu pengguna yang dimodifikasi itu.
File direferensikan dalam semburan. Jika file telah direferensikan baru-baru ini, ada
probabilitas tinggi bahwa itu akan dirujuk lagi dalam waktu dekat.
AFS bekerja terbaik dengan kelas file diidentifikasi dalam poin pertama di atas. Ada satu jenis penting dari file yang tidak masuk ke setiap kelas ini - database yang biasanya bersama oleh banyak pengguna dan sering diperbarui cukup sering. Itu desainer dari AFS telah secara eksplisit dikecualikan penyediaan fasilitas penyimpanan untuk database dari tujuan desain mereka, yang menyatakan bahwa kendala yang dikenakan oleh berbagai penamaan struktur (yaitu, akses berbasis konten) dan kebutuhan data halus akses, kontrol concurrency dan atomicity update membuat sulit untuk merancang sistem database terdistribusi yang juga merupakan sistem file terdistribusi. Mereka berpendapat bahwa penyediaan fasilitas untuk database terdistribusi harus ditangani secara terpisah [Satyanarayanan 1989a].


Implementasi
Skenario di atas menggambarkan AFS operasi tetapi menyisakan banyak pertanyaan tentang nya pelaksanaan terjawab. Di antara yang paling penting adalah:

BagaimanaAFSgaincontrolketikamembuka atau menutuppanggilansistemmengacuke filediruang filebersamayangdikeluarkan olehklien?
Bagaimanaservermemegang fileyang diperlukanberada?
Aparuang yang dialokasikanuntuk filecachediworkstation?
BagaimanaAFSmemastikanbahwasalinancachedarifileyangup-to-date ketika filemungkindiperbaruioleh beberapaklien?
Kami menjawab pertanyaan-pertanyaan di bawah ini.



Gambar 12.11 Distribusi proses dalam Andrew File System

AFS diimplementasikan sebagai dua komponen perangkat lunak yang ada sebagai proses UNIX disebut Wakil dan Venus. Gambar 12.11 menunjukkan distribusi proses Wakil dan Venus. Wakil adalah nama yang diberikan kepada perangkat lunak server yang berjalan sebagai proses UNIX user-level di masing-masing komputer server, dan Venus adalah proses user-level yang berjalan di setiap komputer klien dan sesuai dengan modul klien dalam model abstrak kita.

File yang tersedia untuk proses pengguna yang berjalan pada workstation yang baik lokal atau bersama. file lokal ditangani sebagai file UNIX normal. Mereka disimpan pada workstation disk dan hanya tersedia untuk proses pengguna lokal. berbagi file disimpan di server, dan salinan dari mereka cache pada disk lokal workstation. Ruang nama dilihat oleh proses pengguna diilustrasikan pada Gambar 12.12. Ini adalah direktori UNIX konvensional hirarki, dengan subtree tertentu (disebut CMU) yang berisi semua file bersama. Ini pemisahan ruang nama file ke file lokal dan berbagi menyebabkan beberapa kerugian dari lokasi transparansi, tapi ini hampir tidak terlihat untuk pengguna selain administrator sistem. file lokal hanya digunakan untuk file-file sementara (/ tmp) dan proses yang penting untuk workstation startup. file UNIX standar lainnya (seperti yang biasanya ditemukan di / bin, / Lib dan sebagainya) diimplementasikan sebagai link simbolik dari direktori lokal untuk file yang diadakan di ruang bersama. direktori pengguna berada di ruang bersama, yang memungkinkan pengguna untuk mengakses mereka file dari setiap workstation.

UNIX kernel di setiap workstation dan server adalah versi modifikasi dari BSD UNIX. Modifikasi dirancang untuk mencegat membuka, menutup dan beberapa file lain sistem panggilan ketika mereka merujuk ke file dalam ruang nama bersama dan meneruskannya ke Venus proses di komputer client (diilustrasikan dalam Gambar 12.13). Satu kernel lainnya modifikasi termasuk untuk alasan kinerja, dan ini dijelaskan kemudian.

Salah satu partisi file di disk lokal masing-masing workstation digunakan sebagai cache, memegang salinan cache dari file dari ruang bersama. Venus mengelola cache, menghapus file yang paling terakhir digunakan ketika file baru diperoleh dari server untuk membuat



Gambar 12.12 Ruang Nama File Yang Dilihat Oleh Klien Dari AFS

ruang diperlukan jika partisi penuh. Cache workstation biasanya cukup besar untuk mengakomodasi beberapa ratus file berukuran rata-rata, render workstation sebagian besar independen dari Wakil server sekali working set file pengguna saat ini dan sering file sistem yang digunakan telah cache.

AFS menyerupai model layanan file abstrak dijelaskan dalam Bagian 12.2 di ini hal:

Sebuah layananfile flatdilaksanakan olehWakilserver, dandirektorihirarkisstrukturyang dibutuhkan olehprogrampenggunaUNIXdiimplementasikanolehsetVenusproses dalamworkstation.
Setiap filedandirektoridiruang filebersamadiidentifikasiolehyang unik, berkas96-bit identifier(fid) mirip denganUFID. ProsesVenusmenerjemahkannama pathdikeluarkan olehklien untukjumlah besar.


Gambar 12.13 Sistem intersepsi panggilan di AFS

File dikelompokkan ke dalam volume untuk memudahkan lokasi dan gerakan. volume yang umumnya lebih kecil dari filesystem UNIX, yang merupakan unit file pengelompokan di NFS. Misalnya, file pribadi masing-masing pengguna umumnya terletak di volume terpisah. Lain volume dialokasikan untuk biner sistem, dokumentasi dan kode perpustakaan.

Representasi dari jumlah besar termasuk jumlah volume untuk volume yang berisi file (lih pengenal kelompok file dalam UFIDs), file menangani NFS mengidentifikasi file dalam volume (lih jumlah file dalam UID) dan uniquifier untuk memastikan file yang pengidentifikasi tidak digunakan kembali:

program pengguna menggunakan nama path UNIX konvensional untuk merujuk ke file, tapi AFS menggunakan jumlah besar di komunikasi antara proses Venus dan Wakil. Wakil server menerima
permintaan hanya dalam hal jumlah besar. Venus menerjemahkan nama-nama jalan yang disediakan oleh klien ke jumlah besar menggunakan lookup langkah-demi-langkah untuk memperoleh informasi dari direktori berkas diadakan di Wakil server.

Gambar 12.14 menggambarkan tindakan yang diambil oleh Wakil, Venus dan kernel UNIX saat proses pengguna mengeluarkan masing-masing dari panggilan sistem yang disebutkan dalam skenario garis kami atas. The callback janji yang disebutkan di sini adalah mekanisme untuk memastikan cache yang salinan file diperbarui ketika klien lain menutup file yang sama setelah memperbarui itu. Ini Mekanisme dibahas pada bagian berikutnya.



Cache consistency
Ketika Wakil memasok salinan file ke proses Venus juga menyediakan callback janji - tanda yang dikeluarkan oleh Wakil server yang adalah penjaga file, menjamin bahwa itu akan memberitahukan proses Venus ketika klien lain memodifikasi file. Telepon kembali janji disimpan dengan file cache pada disk workstation dan memiliki dua negara: valid atau dibatalkan. Ketika server melakukan permintaan untuk memperbarui file itu akan memberitahu semua Venus proses yang telah dikeluarkan janji callback dengan mengirimkan panggilan balik ke masing-masing

- Callback adalah panggilan prosedur jauh dari server ke proses Venus. Ketika Venus Proses menerima panggilan balik, ia menetapkan token callback janji untuk file yang relevan untuk dibatalkan.

Setiap kali Venus menangani terbuka atas nama klien, itu memeriksa cache. Jika file yang dibutuhkan ditemukan dalam cache, maka tanda yang diperiksa. Jika nilainya dibatalkan, maka salinan dari file tersebut harus diambil dari Wakil server, tetapi jika token valid, maka salinan cache dapat dibuka dan digunakan tanpa mengacu Wakil.

Ketika workstation restart setelah kegagalan atau shutdown, Venus bertujuan untuk mempertahankan sebanyak mungkin dari file cache pada disk lokal, tetapi tidak dapat berasumsi bahwa token janji callback benar, karena beberapa callback mungkin telah terjawab. Sebelum penggunaan pertama dari setiap file cache atau direktori setelah restart, Venus karena menghasilkan permintaan validasi tembolok berisi timestamp modifikasi file ke server yang kustodian file. Jika timestamp adalah saat ini, server merespon dengan valid dan token dipulihkan. Jika timestamp menunjukkan bahwa file tersebut dari tanggal, maka server merespon dengan membatalkan dan token diatur untuk dibatalkan. Callback harus diperbaharui

































Gambar 12.14 Penerapan sistem file panggilan di AFS



sebelum terbuka jika waktu T (biasanya pada urutan beberapa menit) telah berlalu sejak File dicapai tanpa komunikasi dari server. Hal ini untuk menghadapi kemungkinan kegagalan komunikasi, yang dapat mengakibatkan hilangnya pesan callback.





Gambar 12.15 Komponen utama dari antarmuka Wakil layanan





Gambar 12.15 (Yaitu, antarmuka yang disediakan oleh server AFS untuk proses Venus).

Update semantik • Tujuan dari mekanisme cache-konsistensi ini adalah untuk mencapai pendekatan terbaik ke file semantik satu-copy yang praktis tanpa serius penurunan kinerja. Sebuah pelaksanaan yang ketat dari semantik satu-copy file UNIX Akses primitif akan mengharuskan hasil setiap menulis ke file didistribusikan ke semua situs memegang file dalam cache mereka sebelum akses lanjut dapat terjadi. Ini bukan praktis dalam sistem skala besar; sebaliknya, callback janji pendekatan didefinisikan dengan baik untuk semantik satu-copy.  menunjukkan panggilan RPC yang disediakan oleh server AFS untuk operasi pada file

Untuk AFS-1, update semantik dapat secara resmi dinyatakan dalam istilah yang sangat sederhana. Untuk klien C beroperasi pada F berkas yang kustodian adalah server S, jaminan berikut mata uang untuk salinan F dipertahankan:

after a successful open:              latest(F, S)

after a failed open:                     failure(S)

after a successful close:             updated(F, S)

after a failed close:                    failure(S)

di mana terbaru (F, S) menunjukkan jaminan bahwa nilai saat ini dari F di C adalah sama dengan nilai pada S, kegagalan (S) menunjukkan bahwa operasi terbuka atau dekat belum dilakukan pada BAGIAN 12.4 STUDI KASUS: THE ANDREW FILE SYSTEM 555 S (dan kegagalan dapat dideteksi oleh C), dan diperbarui (F, S) menunjukkan bahwa nilai C untuk F telah berhasil disebarkan ke S.

Untuk AFS-2, jaminan uang untuk terbuka sedikit lebih lemah, dan sesuai pernyataan resmi dari jaminan yang lebih kompleks. Hal ini karena klien dapat membuka salinan tua file setelah itu telah diperbarui oleh klien lain. Ini terjadi jika pesan callback hilang, misalnya sebagai akibat dari kegagalan jaringan. Tapi ada waktu maksimum, T, yang klien dapat tetap tidak menyadari versi yang lebih baru dari file. Oleh karena itu kami memiliki jaminan sebagai berikut:

after a successful open:                       latest(F, S, 0)

ck(S, T) and inCache(F) and

latest(F, S, T))

di mana terbaru (F, S, T) menunjukkan bahwa salinan F dilihat oleh klien adalah tidak lebih dari Tdetik dari tanggal, kehilangan Callback (S, T) menunjukkan bahwa pesan panggilan balik dari S ke C memiliki telah hilang pada beberapa waktu selama detik T terakhir, dan inCache (F) menunjukkan bahwa file tersebut F adalah dalam cache di C sebelum operasi terbuka dicoba. Di atas resmi Pernyataan mengungkapkan fakta bahwa salinan cache dari F di C setelah operasi terbuka adalah versi paling baru-baru ini dalam sistem atau pesan callback telah hilang (karena
kegagalan komunikasi) dan versi yang sudah di cache telah digunakan; itu versi cache akan ada lebih dari detik T dari tanggal. (T adalah sistem konstan mewakili interval di mana panggilan balik janji instalasi, nilai T adalah sekitar 10 menit.)



Meskipun update semantik berbeda tergantung pada lokasi dari konkuren proses mengakses file dan tidak tepat sama dengan yang disediakan oleh standar sistem file UNIX, mereka cukup dekat untuk sebagian besar yang ada program UNIX untuk beroperasi dengan benar.

Aspek Lain
AFS memperkenalkan beberapa perkembangan desain menarik lainnya dan perbaikan yang kita garis sini, bersama-sama dengan ringkasan hasil evaluasi kinerja:

modifikasi kernel UNIX • Kami telah mencatat bahwa Wakil server adalah proses user-level berjalan di komputer server dan server host didedikasikan untuk penyediaan sebuah 556 BAB 12 DIDISTRIBUSIKAN SISTEM FILE layanan AFS. UNIX kernel di host AFS diubah sehingga Wakil dapat melakukan berkas operasi dalam hal berkas menangani bukan file deskriptor UNIX konvensional. Ini adalah satu-satunya modifikasi kernel yang dibutuhkan oleh AFS, dan itu diperlukan jika Wakil tidak untuk mempertahankan setiap negara klien (seperti file deskriptor).

Lokasi database • Setiap server berisi salinan database lokasi sepenuhnya direplikasi memberikan pemetaan nama volume untuk server. ketidakakuratan sementara pada database ini dapat terjadi ketika volume dipindahkan, tetapi mereka tidak berbahaya karena forwarding Informasi yang tertinggal di server dari mana volume dipindahkan.

Threads • Implementasi dari Wakil dan Venus memanfaatkan non-preemptive benang paket untuk memungkinkan permintaan untuk diproses secara bersamaan di kedua klien (di mana beberapa proses pengguna mungkin memiliki permintaan akses file berlangsung secara bersamaan) dan Server. Di klien, tabel menggambarkan isi dari cache dan volume
database diselenggarakan di memori yang dibagi antara benang Venus.

Read-only replika • Volume yang berisi file yang sering baca tapi jarang dimodifikasi, seperti UNIX / bin dan / usr / bin direktori perintah sistem dan / man direktori halaman manual, dapat direplikasi sebagai read-only volume di beberapa server. Bila ini dilakukan, hanya ada satu read-write replika dan semua pembaruan diarahkan untuk itu. Penyebaran perubahan pada read-only replika dilakukan setelah update dengan prosedur operasional eksplisit. Entri dalam database lokasi untuk volume yang direplikasi dengan cara ini adalah satu-ke-banyak, dan server untuk setiap permintaan klien dipilih atas dasar beban server dan aksesibilitas.

transfer massal • AFS transfer file antara klien dan server dalam potongan 64-kilobyte. Penggunaan ukuran paket besar tersebut merupakan bantuan penting untuk kinerja, meminimalkan efek latensi jaringan. Sehingga desain AFS memungkinkan penggunaan jaringan menjadi dioptimalkan.

caching file yang parsial • Kebutuhan untuk mentransfer seluruh isi file ke klien bahkan ketika persyaratan aplikasi adalah dengan membaca hanya sebagian kecil dari file tersebut adalah jelas sumber inefisiensi. Versi 3 dari AFS dihapus persyaratan ini, memungkinkan file data ditransfer dan cache di blok 64-kbyte sementara masih tetap mempertahankan konsistensi semantik dan fitur lain dari protokol AFS.

Kinerja • Tujuan utama dari AFS adalah skalabilitas, sehingga kinerjanya dengan besar jumlah pengguna adalah kepentingan tertentu. Howard et al. [1988] memberikan rincian luas pengukuran kinerja komparatif, yang dilakukan dengan menggunakan khusus patokan AFS maju yang telah kemudian telah banyak digunakan untuk evaluasi sistem file terdistribusi. Tidak mengherankan, caching seluruh file dan protokol callback menyebabkan secara dramatis mengurangi beban pada server. Satyanarayanan [1989a] menyatakan bahwa beban server dari 40% diukur dengan 18 node klien menjalankan patokan standar, terhadap beban 100% untuk NFS menjalankan benchmark yang sama. Satyanarayanan atribut banyak keuntungan kinerja AFS untuk pengurangan beban server berasal dari penggunaan callback untuk memberitahu klien update ke file, dibandingkan dengan Mekanisme yang digunakan dalam NFS untuk memeriksa keabsahan halaman cache pada klien.

Wide area support: • Versi 3 dari AFS mendukung beberapa sel administrasi, masing-masing dengan sendiri server, klien, administrator sistem dan pengguna. Setiap sel adalah benar-benar lingkungan otonom, namun federasi sel dapat bekerja sama dalam menyajikan pengguna dengan seragam, mulus ruang nama file. Sistem yang dihasilkan secara luas digunakan oleh yang Transarc Corporation, dan survei terperinci penggunaan kinerja yang dihasilkan pola diterbitkan [Spasojevic dan Satyanarayanan 1996]. Sistem tersebut telah terpasang di lebih dari 1000 server di lebih dari 150 situs. Hasil survei menunjukkan rasio cache hit di kisaran dari 96 -98% untuk akses ke sampel 32.000 volume file yang memegang 200 Gbytes data.



Tambahan DanPerkembangan Lebih Lanjut
Beberapa kemajuan telah dibuat dalam desain sistem file terdistribusi sejak Munculnya NFS dan AFS. Pada bagian ini, kita menggambarkan kemajuan yang meningkatkan kinerja, ketersediaan dan skalabilitas dari sistem file terdistribusi konvensional. Lebih kemajuan radikal dijelaskan di tempat lain dalam buku ini, termasuk pemeliharaan konsistensi dalam direplikasi sistem baca-tulis berkas untuk mendukung operasi terputus dan ketersediaan tinggi dalam sistem Bayou dan Coda (Bagian 18.4.2 dan 18.4.3) dan arsitektur sangat scalable untuk pengiriman aliran data real-time dengan kualitas jaminan di Tiger file video Server (Bagian 20.6.1).



NFS tambahan • Beberapa proyek penelitian telah membahas perlunya satu-copy Update semantik dengan memperluas protokol NFS untuk memasukkan operasi membuka dan menutup dan menambahkan mekanisme callback untuk memungkinkan server untuk memberitahu klien dari kebutuhan untuk membatalkan entri tembolok. Kami menggambarkan dua upaya tersebut di sini; hasil mereka tampaknya menunjukkan bahwa perangkat ini dapat ditampung tanpa kerumitan yang tidak semestinya atau ekstra biaya komunikasi.



Beberapa upaya terbaru oleh Sun dan pengembang lainnya NFS telah diarahkan pada membuat server NFS lebih mudah diakses dan berguna dalam jaringan wide-area. Sementara HTTP protokol yang didukung oleh server web menawarkan metode yang efektif dan sangat terukur untuk membuat seluruh file yang tersedia untuk klien di seluruh internet, itu kurang berguna untuk program aplikasi yang membutuhkan akses ke bagian-bagian dari file besar atau mereka update yang bagian dari file. Pengembangan WebNFS (dijelaskan di bawah) memungkinkan program aplikasi untuk menjadi klien dari server NFS di mana saja di Internet (menggunakan protokol NFS langsung bukannya tidak langsung melalui modul kernel). Ini, bersama-sama dengan perpustakaan yang sesuai untuk Java dan bahasa pemrograman jaringan lainnya, harus menawarkan kemungkinan menerapkan aplikasi internet yang berbagi data secara langsung, seperti sebagai multi-user game atau klien dari database dinamis yang besar.



Mencapai satu-copy pembaruan semantik: The server arsitektur stateless dari NFS membawa keuntungan besar dalam hal ketahanan dan kemudahan pelaksanaan, tetapi menghalangi pencapaian tepat satu-copy pembaruan semantik (efek bersamaan menulis dengan klien yang berbeda untuk file yang sama tidak dijamin akan sama karena mereka akan berada dalam sistem tunggal UNIX ketika beberapa proses menulis ke file lokal). Hal ini juga mencegah menggunakan callback memberitahukan klien perubahan ke file, dan hasil ini dalam sering getattr permintaan dari klien untuk memeriksa modifikasi berkas.

Dua sistem penelitian telah dikembangkan yang membahas kelemahan ini. Spritely NFS [Srinivasan dan Mogul 1989, Mogul 1994] adalah versi dari sistem berkas dikembangkan untuk Sprite didistribusikan sistem operasi di Berkeley [Nelson et al. 1988]. Spritely NFS merupakan implementasi dari protokol NFS dengan penambahan panggilan membuka dan menutup.

Ketika server menerima terbuka, memeriksa membuka file tabel untuk klien lainnya yang memiliki file yang sama yang terbuka dan mengirimkan pesan panggilan balik ke klien-klien menginstruksikan mereka untuk mengubah strategi caching mereka. Jika menspesifikasikan terbuka modus menulis, maka akan gagal jika ada klien lain memiliki file yang terbuka untuk menulis. klien lain yang memiliki file terbuka untuk membaca akan diinstruksikan untuk membatalkan bagian cache lokal dari file. Untuk operasi terbuka yang menentukan modus baca, server akan mengirimkan pesan balik untuk setiap klien yang menulis, menginstruksikan untuk menghentikan caching (yaitu, menggunakan Write- keta melalui modus operasi), dan menginstruksikan semua klien yang membaca untuk berhenti caching file (sehingga semua panggilan membaca lokal mengakibatkan permintaan ke server).



NQFS: The NQNFS (Tidak cukup NFS) proyek [Macklem 1994] memiliki tujuan yang sama dengan Spritely NFS - untuk menambahkan konsistensi persediaan yang lebih tepat untuk protokol NFS dan meningkatkan kinerja melalui lebih baik menggunakan caching. Server NQNFS memelihara
mirip negara mengenai file yang terbuka, tetapi menggunakan sewa terkait client (Bagian 5.4.3) untuk membantu pemulihan setelah kecelakaan server. server menetapkan batas atas waktu yang suatu klien dapat mengadakan sewa file terbuka. Jika klien ingin melanjutkan di luar waktu itu, itu harus memperbaharui sewa. Callback digunakan dalam cara yang mirip dengan spritely NFS ke meminta klien untuk flush cache mereka ketika permintaan menulis terjadi, tetapi jika klien tidak menjawab, server hanya menunggu sampai sewa mereka berakhir sebelum menanggapi tulis baru permintaan.

WebNFS: Munculnya Web dan applet Java menyebabkan pengakuan oleh NFS tim pengembangan dan lain-lain bahwa beberapa aplikasi internet bisa mendapatkan keuntungan dari direct akses ke server NFS tanpa banyak overhead yang terkait dengan persaingan operasi file UNIX termasuk dalam klien NFS standar.

Tujuan dari WebNFS (dijelaskan dalam RFC 2055 dan 2056 [Callaghan 1996a, 1996b]) adalah untuk memungkinkan web browser dan aplikasi lain untuk mengakses file pada NFS server yang 'menerbitkan' mereka menggunakan file umum menangani relatif ke direktori akar publik. Mode ini penggunaan bypasses layanan mount dan layanan pelabuhan mapper (dijelaskan dalam Bab 5). klien WebNFS berinteraksi dengan server NFS di sejumlah pelabuhan terkenal (2049). Untuk mengakses file dengan nama path, mereka mengeluarkan permintaan lookup menggunakan file umum menangani. File publik handle memiliki nilai terkenal yang ditafsirkan secara khusus oleh sistem file virtual server. Karena latency tinggi jaringan wide-area, a varian multikomponen dari operasi pencarian digunakan untuk mencari multi-bagian pathname dalam satu permintaan.

NFS versi 4: Sebuah versi baru dari protokol NFS diperkenalkan pada tahun 2000. Tujuan dari NFS versi 4 dijelaskan dalam RFC 2624 [Shepler 1999] dan dalam buku Brent Callaghan [Callaghan 1999]. Seperti WebNFS, itu bertujuan untuk membuat praktis untuk menggunakan NFS di wide-area jaringan dan aplikasi internet. Ini mencakup fitur WebNFS, tetapi pengenalan protokol baru juga menawarkan kesempatan untuk membuat lebih radikal perangkat tambahan. (WebNFS dibatasi untuk perubahan ke server yang tidak melibatkan Selain operasi baru untuk protokol.)

tambahan AFS • Kami telah disebutkan bahwa DCE / DFS, sistem file terdistribusi termasuk dalam Open Software Foundation Lingkungan Komputasi Terdistribusi [Www.opengroup.org], didasarkan pada Andrew File System. Desain DCE / DFS melampaui AFS, terutama dalam pendekatan untuk konsistensi persediaan. Dalam AFS, callback

Perbaikan dalam organisasi penyimpanan • Ada kemajuan yang cukup besar dalam organisasi data file yang disimpan pada disk. Dorongan untuk banyak pekerjaan ini muncul dari beban meningkat dan keandalan yang lebih besar yang terdistribusi file sistem harus mendukung, dan mereka telah mengakibatkan file sistem Hasil utama dari pekerjaan ini adalah:



Redundant Arrays of Inexpensive Disks (RAID): Ini adalah modus penyimpanan [Patterson et al. 1988, Chen et al. 1994] di mana blok data tersegmentasi menjadi tetap-ukuran potongan dan disimpan dalam 'garis' di beberapa disk, bersama dengan berlebihan error-correcting kode yang memungkinkan blok data yang akan direkonstruksi benar dan Operasi untuk melanjutkan normal dalam hal kegagalan disk. RAID juga memproduksi kinerja jauh lebih baik daripada disk tunggal, karena garis-garis yang membentuk blok yang dibaca dan ditulis secara bersamaan. Log-terstruktur penyimpanan file (LFS): Seperti spritely NFS, teknik ini berasal proyek sistem operasi Sprite didistribusikan di Berkeley [Rosenblum dan Ousterhout 1992]. Para penulis mengamati bahwa sebagai jumlah yang lebih besar dari memori utama menjadi tersedia untuk caching di file server, peningkatan tingkat hit cache mengakibatkan kinerja membaca sangat baik, tapi kinerja write tetap biasa-biasa saja. ini muncul dari latency tinggi yang terkait dengan menulis blok data individual ke disk dan update terkait untuk blok metadata (yaitu, blok yang dikenal sebagai i-node yang memegang atribut file dan vektor dari pointer ke blok dalam file).



Desain baru pendekatan • Ketersediaan performa tinggi switched jaringan (Seperti ATM dan beralih kecepatan tinggi Ethernet) telah mendorong beberapa upaya untuk menyediakan sistem penyimpanan persisten yang mendistribusikan file data dalam sangat scalable dan kesalahan- cara toleran di antara banyak node di intranet, memisahkan tanggung jawab untuk membaca dan menulis data dari tanggung jawab untuk mengelola metadata dan melayani permintaan klien. Berikut ini, kami menguraikan dua perkembangan tersebut. Pendekatan ini skala yang lebih baik daripada server yang lebih terpusat yang kita miliki dijelaskan dalam bagian sebelumnya. Mereka umumnya menuntut tingkat kepercayaan yang tinggi antara komputer yang bekerja sama untuk menyediakan layanan ini, karena mereka termasuk cukup rendah protokol tingkat untuk komunikasi dengan node memegang data (agak analog dengan API 'disk virtual'). Oleh karena itu ruang lingkup mereka mungkin akan terbatas pada suatu jaringan lokal.

xfs: Sebuah kelompok di University of California, Berkeley, yang diusulkan jaringan serverless arsitektur sistem file dan mengembangkan implementasi prototipe disebut XFS [Anderson et al. 1996]. Pendekatan mereka didorong oleh tiga faktor:

kesempatan yang diberikan olehLANcepat diaktifkanuntuk beberapafile serverdilokaljaringan untukmentransferdata massalkepada kliensecara bersamaan;
meningkatnya permintaanuntuk akses kedata bersama;
keterbatasanmendasardarisistem berbasispada file server


XFS adalah 'serverless' dalam arti bahwa mendistribusikan pengolahan server file tanggung jawab di satu set komputer yang tersedia di jaringan lokal di granularity dari file individual. tanggung jawab penyimpanan didistribusikan secara independen dari manajemen dan tanggung jawab layanan lainnya: XFS mengimplementasikan sistem penyimpanan software RAID, striping file data di disk pada beberapa komputer (dalam hal ini adalah prekursor server Tiger file video yang diuraikan dalam Bab 20), bersama-sama dengan log-penataan teknik yang sama untuk sistem file Zebra. Tanggung jawab untuk pengelolaan setiap file dapat dialokasikan ke salah satu komputer mendukung layanan xfs. Hal ini dicapai melalui struktur metadata disebut peta manager, yang direplikasi di semua klien dan server. pengidentifikasi berkas termasuk bidang yang bertindak sebagai indeks ke dalam peta manajer, dan setiap entri di peta mengidentifikasi komputer yang saat ini bertanggung jawab untuk mengelola file yang berkaitan. Beberapa struktur metadata lainnya, mirip dengan yang ditemukan di lain log-terstruktur dan sistem penyimpanan RAID, digunakan untuk pengelolaan penyimpanan file log-terstruktur dan penyimpanan disk bergaris.



Frangipani: Frangipani adalah didistribusikan sistem file yang sangat scalable dikembangkan dan dikerahkan di Sistem Digital Research Center (sekarang Compaq Systems Research Center) [Thekkath et al. 1997]. Tujuannya adalah sangat mirip dengan XFS, dan seperti XFS, mendekati mereka dengan desain yang memisahkan tanggung jawab penyimpanan persisten dari tindakan layanan file lainnya. Tapi layanan Frangipani disusun sebagai dua benar-benar lapisan independen. Lapisan bawah disediakan oleh disk virtual Petal didistribusikan sistem [Lee dan Thekkath 1996].

Petal memberikan abstraksi disk virtual didistribusikan di banyak disk yang terletak di beberapa server pada jaringan lokal diaktifkan. Disk virtual abstraksi mentolerir paling
kegagalan hardware dan software dengan bantuan replika dari data yang disimpan dan mandiri menyeimbangkan beban pada server dengan relokasi data. disk virtual Petal adalah diakses melalui driver disk UNIX menggunakan operasi input-output standar blok, sehingga mereka dapat digunakan untuk mendukung sebagian besar sistem berkas. Petal menambahkan antara 10 dan 100% untuk latency akses disk, tetapi hasilnya strategi caching dalam membaca dan menulis throughputs setidaknya sama baiknya dengan orang-orang dari disk drive yang mendasari.



Ringkasan
Masalah desain kunci untuk sistem file terdistribusi adalah:

penggunaan efektif caching klien untuk mencapai kinerja yang sama atau lebih baik dari bahwa sistem file lokal;
pemeliharaan konsistensi antara beberapa salinan klien cache file ketika mereka diperbarui;
pemulihan setelah klien atau server kegagalan;
throughput yang tinggi untuk membaca dan menulis file dari semua ukuran;


sistem file terdistribusi yang sangat berat yang digunakan dalam komputasi organisasi, dan kinerja mereka telah menjadi subyek dari banyak tuning. NFS memiliki kewarganegaraan sederhana protokol, tetapi telah mempertahankan posisinya awal sebagai sistem file terdistribusi yang dominan teknologi dengan bantuan beberapa perangkat tambahan yang relatif kecil untuk protokol, disetel implementasi dan kinerja tinggi dukungan hardware.

AFS menunjukkan kelayakan yang relatif sederhana arsitektur menggunakan server yang negara untuk mengurangi biaya pemeliharaan cache klien yang koheren. AFS melebihi NFS di banyak situasi. Kemajuan terbaru telah menggunakan data striping di beberapa disk dan log-terstruktur menulis untuk lebih meningkatkan kinerja dan skalabilitas. state-of-the-art sistem file terdistribusi sangat scalable saat ini, memberikan baik Kinerja di kedua jaringan lokal dan wide-area, menjaga file update satu-copy semantik dan mentolerir dan pulih dari kegagalan. kebutuhan masa depan termasuk dukungan bagi pengguna ponsel dengan operasi terputus, dan reintegrasi otomatis dan kualitas layanan jaminan untuk memenuhi kebutuhan untuk penyimpanan persisten dan pengiriman aliran multimedia dan data tergantung waktu lainnya. Solusi untuk persyaratan ini dibahas dalam Bab 18 dan 20.