Fault Tolerance dan skema dari Replication sistem terdistribusi

Fault Tolerance

Salah satu tujuan dalam membangun sebuah system terdistribusi adalah memungkinkan untuk melakukan improvisasi terhadap kehandalan sistem. Ini dilakukan karena setiap system pasti akan menemukan kesalahan atau gangguan. Sehingga perlu untuk dibuat pencegahan atau solusi untuk mengatasi masalah tersebut. Availability: kalau mesin mati (down), sistem tetap harus berjalan dengan jumlah layananan yang tersisa. Dalam suatu sistem terdistribusi komponen dalam system yang sangat vital terutama pada resources (critical resources) berjumlah seminimal mungkin. Yang dimaksud dengan critical resources adalah komponen dalam system yang harus ada untuk menjalankan sistem terdistribusi. 

Secara umum, ada dua jenis fault tolerant, yaitu fault tolerant secara hardware dan secara software. Untuk itu, masing - masing Software dan Hardware harus di replikasi. Sehingga kalau terjadi kegagalan / error maka yang lain akan menangani. Data dalam sistem terdistribusi tidak boleh hilang, oleh karena itu copy dari data atau resource lainnya tersebut disimpan secara redundan pada server lain, tapi tetap harus dijaga konsistensi datanya. Hal ini memang berkaitan dengan replikasi. Dengan membuat system terdistribusi yang fault tolerance maka Sistem harus bisa mendeteksi kegagalan dan melakukan tindakan dasar sebagai berikut:

• Mask the fault (menutupi kegagalan): tugas harus dapat dilanjutkan dengan menurunkan kinerja tapi tanpa terjadi kehilangan data atau informasi.

• Fail Gracefully: membuat suatu antisipasi terhadap suatu kegagalan ke suatu prosedur yang telah di rencanakan dan memungkinkan untuk menghentikan proses dalam waktu yang singkat tanpa menghilangkan  informasi atau data.

 

Transaksi (Transaction)

 

         Transaksi merupakan bagian dari pengeksekusian sebuah program yang melakukan pengaksesan basis data dan bahkan juga melakukan serangkaian perubahan data.  DBMS yang kita gunakan harus menjamin bahwa setiap transaksi harus dapat dikerjakan secara utuh atau tidak sama sekali.  Tidak boleh ada transaksi yang hanya dikerjakan sebagian, karena dapat menyebabkan inkonsistensi basis data.  Untuk itu transaksi selalu merubah basis data dari satu kondisi konsisten ke kondisi konsisten lain.

Sebuah transaksi berpeluang untuk ‘mengganggu’ integritas basis data yang dapat membuat kondisi/hubungan antar data tidak seperti seharusnya.  Untuk menjamin agar integritas dapat tetap terpelihara maka setiap transaksi harus memiliki sifat-sifat:

• Atomik, dimana semua operasi dalam transaksi dapat dikerjakan seluruhnya atau tidak sama sekali.
• Konsisten, dimana eksekusi transaksi secara tunggal harus dapat menjamin data tetap konsisten setelah transaksi berakhir.
• Terisolasi, jika pada sebuah sistem basis data terdapat sejumlah transaksi yang dilaksanakan secara bersamaan, maka semua transaksi yang dilaksanakan pada saat yang bersamaan tersebut harus dapat dimulai dan bisa berakhir.
• Bertahan, dimana perubahan data yang terjadi setelah sebuah transaksi berakhir dengan baik, harus dapat bertahan bahkan jika seandainya sistem menjadi mati

      Terhentinya suatu transaksi tidak selalu diakibatkan oleh kegagalan insidental baik dari perangkat keras (crash) ataupun kemacetan sistem operasi (hang).  Tapi lebih sering terjadi karena user sengaja menghentikan transaksi atau karena penghentian transaksi oleh DBMS akibat adanya kondisi tak diinginkan, seperti deadlock atau timeout.

Sebuah transaksi dapat menghasilkan dua kemungkinan:

• Jika dilaksanakan lengkap seluruhnya, transaksi tersebut telah di commit dan basis data mencapai keadaan konsisten baru.

• Jika transaksi tidak sukses, maka transaksi dibatalkan dan basis data dikembalikan ke keadaan konsisten sebelumnya (rollback).

Transaksi yang sudah di commit tidak dapat dibatalkan lagi.  Jika ada kesalahan, maka harus dilakukan transaksi lain yang membalik dampak transaksi sebelumnya. Status-status yang dapat dicapai oleh sebuah transaksi sejak mulai dilaksanakan hingga selesai atau batal adalah:

• Aktif (Active), yang merupakan status awal (initial state) sebuah transaksi yang menunjukkan transaksi tersebut masih dieksekusi.
• Berhasil Sebagian (Partially Committed), yaitu keadaan yang dicapai transaksi tepat pada saat operasi terakhir dalam transaksi selesai dikerjakan.
• Gagal (Failed), yang merupakan keadaan dimana sebuah transaksi terhenti pengeksekusiannya sebelum tuntas sama sekali.
• Batal (Aborted), yaitu keadaan dimana sebuah transaksi dianggap tidak/belum dikerjakan yang tentu dengan terlebih dahulu diawali dengan mengembalikan semua data yang telah diubah ke nilai-nilai semula. (yang menjadi tanggung jawab DBMS).
• Berhasil Sempurna (Committed), keadaan dimana transaksi telah dinyatakan berhasil dikerjakan seluruhnya dan basis data telah merefleksikan perubahan-perubahan yang memang diinginkan transaksi.

Ketika sebuah transaksi mulai dikerjakan, maka transaksi itu berada dalam status aktif.  Jika terjadi penghentian sebelum operasi berakhir, maka transaksi segera beralih ke statusgagal/failed.  Namun, bila keseluruhan transaksi selesai dikerjakan, maka transaksi itu berada pada status berhasil sebagian/partially committed, dimana perubahan-perubahan data masih berada di dalam memori utama yang bersifat volatile/tidak permanen.  Transaksi dalam status ini masih mungkin untuk pindah ke status failed, karena ada pembatalan transaksi baik sengaja maupun tidak.  Jika tidak beralih ke status failed, maka nilai-nilai data yang ada di memori utama akan direkam ke dalam disk yang bersifat permanen.  Begitu proses perekaman selesai, maka transaksi beralih ke status committed.  Sementara itu, transaksi yang berada pada status failed, maka DBMS harus menjalan proses rollback.  Proses tersebut dapat berupa:

     Mengulangi pelaksanaan transaksi / restart, yang dilakukan pada transaksi yang failed akbiat kemacetan perangkat keras ataupun perangkat lunak dan bukannya penghentian transaksi secara sengaja oleh user.

        Mematikan transaksi / kill, yang dilakukan untuk transaksi yang dihentikan secara sengaja oleh user atau akibat adanya kesalahan lojik dalam penulisan aplikasi.

Begitu salah satu dari pilihan proses tersebut selesai dilakukan, maka transaksi berpindah ke status batal (aborted).  Status berhasil sempurna/committed maupun batal/abortedmerupakan status terminasi, yaitu status akhir dalam pelaksanaan transaksi.

Konsep Dasar Replication

Replikasi adalah suatu teknik untuk melakukan copy dan pendistribusian data dan objek-objek database dari satu database ke database lain dan melaksanakan sinkronisasi antara database sehingga konsistensi data dapat terjamin. Dengan menggunakan teknik replikasi ini, data dapat didistribusikan ke lokasi yang berbeda melalui koneksi jaringan lokal maupun internet. Replikasi juga memungkinkan untuk mendukung kinerja aplikasi, penyebaran data fisik sesuai dengan penggunaannya, seperti pemrosesan transaksi online dan DSS (Desiscion Support System) atau pemrosessan database terdistribusi melalui beberapa server. 

 

Selain itu ada yang menyebutkan bahwa Replikasi adalah proses menyalin dan memelihara objek database dalam beberapa database yang membentuk suatu sistem database terdistribusi. Replikasi dapat meningkatkan kinerja dan melindungi ketersediaan aplikasi karena data pilihan alternatif akses ada. Sebagai contoh, sebuah aplikasi biasanya dapat mengakses database lokal daripada server jauh untuk meminimalkan lalu lintas jaringan dan mencapai kinerja maksimum. Selanjutnya, aplikasi dapat terus berfungsi jika server lokal mengalami kegagalan, tetapi server lain dengan data direplikasi tetap dapat diakses.

Dengan replication dasar, replika data memberikan akses read-only ke tabel data yang berasal dari sebuah situs (master) primer.Aplikasi dapat query data dari replika data lokal untuk menghindari akses jaringan terlepas dari ketersediaan jaringan.Namun, aplikasi di seluruh sistem harus mengakses data pada situs utama ketika pembaruan diperlukan.

Keuntungan replication tergantung dari jenis replikasi tetapi pada umumnya replikasi mendukung ketersediaan data setiap waktu dan dimanapun diperlukan. Adapun keuntungan lainnya adalah :

• Memungkinkan beberapa lokasi menyimpan data yang sama. Hal ini sangat berguna pada saat lokasi-lokasi tersebut membutuhkan data yang sama atau memerlukan server yang terpisah dalam pembuatan aplikasi laporan.
• Aplikasi transaksi online terpisah dari aplikasi pembacaan seperti proses analisis database secara online, data smarts atau data warehouse.
• Memungkinkan otonomi yang besar. Pengguna dapat bekerja dengan meng-copy data pada saat tidak terkoneksi kemudian melakukan perubahan untuk dibuat database baru pada saat terkoneksi.
• Data dapat ditampilkan seperti layaknya melihat data tersebut dengan menggunakan aplikasi berbasis Web.
• Meningkatkan kinerja pembacaan.
• Membawa data mendekati lokasi individu atau kelompok pengguna. Hal ini akan membantu mengurangi masalah karena modifikasi data dan pemrosesan query yang dilakukan oleh banyak pengguna karena data dapat didistribusikan melalui jaringan dan data dapat dibagi berdasarkan kebutuhan masing-masing unit atau pengguna.
• Penggunaan replikasi sebagai bagian dari strategi standby server.

Jenis-jenis Replicatiom

1 Snapshot replication

Mendistribusikan data yang dapat dilihat pada saat tertentu tanpa melakukan update. Biasanya digunakan pada saat memerlukan tampilan data seperti : daftar harga, katalog, data yang digunakan untuk pengambilan keputusan. Data-data ini sifatnya hanya ‘read only’. Replikasi ini membantu pada saat :

• data sebagian besar statis dan tidak sering berubah

• dapat menerima copy data yang telah melewati batas waktu yang ditentukan

• datanya sedikit

2 Merge replication

Merge replication memungkinkan pengguna bekerja dan merubah data sesuai dengan wewenangnya. Pada saat server tidak dikoneksikan ke seluruh lokasi dalam topologi, replikasi merubah ke nilai data yang sama.

3 Transactional Replication

Pengguna mendapatkan salinan lengkap dari database awal dan kemudian mendapatkan update periodik sebagai perubahan data.

Multi-master replikasi, dimana modifikasi dapat ditenderkan ke server database, dan kemudian mengalir melalui ke server database jauh, sering disukai. Namun, menetapkan biaya jauh lebih besar dan keruwetan yang mungkin membuatnya tidak layak dalam beberapa keadaan. Sengketa universal yang ada dalam multi-master replikasi transaksional menghindari ketidakkonsistenan atau resolusi. Kebanyakan sistem replikasi sinkron atau ingin lakukan menghindari inkonsistensi, sementara sistem asynchronous harus melakukan resolusi inkonsistensi.Resolusi seperti inkonsistensi yang mungkin didasarkan pada timestamp transaksi, pada tangga dari server sumber atau dengan alasan yang jauh lebih rumit, yang memutuskan setiap waktu pada semua server.

Replikasi database ternyata menjadi rumit ketika meningkat dalam ukuran dan besarnya. Biasanya, meningkatkan berkaitan dengan dua dimensi; horizontal dan vertikal. Meningkatkan Horisontal memiliki salinan data tambahan, meningkatkan vertikal memiliki salinan data yang terletak jarak jauh. Masalah hamil dengan peningkatan horisontal dapat dikurangi dengan sebuah protokol akses multi-layer multi-view. Peningkatan vertikal strip kesulitan sedikit karena internet kehandalan dan kinerja menjadi lebih baik.

Sinkronisasi dan Asinkronnisasi

Sinkronisasi

Sinkronisasi adalah Adalah satu kunci kerja dari komunikasi data. Transmiter mengirimkan pesan 1 bit pada satu saat melalui medium ke receiver. Receiver harus menandai awal dan akhir blok dari bit, juga harus diketahui durasi untuk masing-masing bit sehingga dapat sample lajur dari timing untuk membaca masing-masing bit (merupakan tugas dari timming).

Asynchronous

Untuk mencegah problem timming dengan tidak mengirim aliran bit panjang yang tidak putus putusnya. Bit-bit dikirim per-karakter pada setiap waktu yang mana masing-masing karakter mempunyai panjang 5-8 bit. Timing atau synchronisasi harus dipertahankan antara tiap karakter; receiver mempunyai kesempatan untuk men-synchron-kan awal dari tiap karakter baru.

Penggunaan sinkronisasi thread adalah dalam model “Producer/Consumer”.

Suatu lock (kunci) digunakan untuk mengsinkronkan akses ke sumber daya terbagi-pakai. Suatu lock dapat diasosiasikan dengan suatu sumber daya terbagi-pakai. Thread memperoleh akses ke sumber daya terbagi-pakai dengan terlebih dahulu mendapatkan lock yang terasosiasi dengan obyek atau block dari kode. Pada suatu waktu yang diberikan, harus hanya satu thread yang dapat memegang lock dan dengan cara demikian mempunyai akses ke sumber daya terbagi-pakai. Lock seperti ini mengimplementasikan mutual exclusion.

Mekanisme object lock (penguncian obyek) menjalankan aturan-aturan sinkronisasi berikut:

Suatu thread harus memperoleh object lock yang diasosiasikan dengan suatu sumber daya terbagi-pakai, sebelum ia dapat memasuki sumber daya terbagi-pakai tersebut. Sistem runtime memastikan bahwa tidak ada thread lain yang dapat memasuki sumber daya terbagi-pakai jika suatu thread sudah memegang (hold) object lock yang diaosiasikan dengan sumber daya terbagi-pakai tersebut. Jika suatu thread tidak dapat dengan segera mendapatkan object lock,maka ia harus menunggu sampai lock tersedia.
 

Pada saat suatu thread berada di dalam suatu sumber daya berbagi-pakai, sistem runtime memastikan bahwa object lock juga dilepaskan. Jika suatu thread lain sedang menunggu object lock ini, ia dapat diproses untuk mendapatkan lock agar memperoleh akses ke sumber daya terbagi-pakai tersebut.
 

Kelas juga mempunyai suatu lock spesifik kelas yang bersifat analog dengan object lock. Lock demikian sesungguhnya merupakan lock pada obyek java.lang.Class yang berasosiasi dengan kelas tersebut. Diberikan suatu kelas A, referensi A.kelas menyatakan obyek kelas unik ini. Class lock tersebut digunakan dengan cara yang sama seperti object lock untuk mengimplementasikan mutual exclusion.

penulisan data selesai tanpa perlu menunggu penulisan data di tempat penyimpanan duplikat selesai; proses ini memang meningkatkan kinerja sistem namun risikonya, inkonsistensi data bisa terjadi.