Strategi Pemulihan Data untuk Dunia yang Rawan Bencana

Strategi Pemulihan Data untuk Dunia yang Rawan Bencana

Bekerja di posisi yang berakar pada rekayasa perangkat lunak, administrasi sistem, dan posisi dukungan pelanggan, seseorang memiliki kesempatan unik untuk melihat berbagai konfigurasi dan berbagai masalah. Selain itu, posisi seperti itu juga memberikan seseorang perspektif tentang berbagai kebutuhan, masalah, dan kekhawatiran pengguna dengan cara yang mungkin tidak dialami oleh seseorang yang bekerja dalam peran rekayasa murni.

Sebagai hasil dari hampir 5 tahun di tim dukungan, saya telah memperhatikan pola di berbagai tim tempat saya bekerja. Lebih jauh, ketika diminta untuk membantu berbagai konfigurasi, saya memiliki kesempatan unik untuk menarik persamaan antara berbagai kasus penggunaan dan akar permasalahan. . Hasilnya, ada landasan yang ingin saya pastikan ditetapkan saat tiba waktunya untuk mulai berkolaborasi dengan tim baru. Menetapkan landasan ini berarti memastikan praktik administrasi memfasilitasi pekerjaan secara optimal dengan rangkaian HA/DR, memastikan tim mengetahui cara merancang untuk Ketersediaan Tinggi dan cara memanfaatkan utilitas di luar perangkat lunak pada sistem mereka untuk mencapai keberhasilan. Landasan ini dapat menjadi penting untuk memastikan tim mengetahui cara memenuhi atau melampaui standar operasional mereka. Tampaknya tepat untuk merangkumpertanyaan umumdan jawaban mereka untuk dijadikan sumber daya bagi mereka yang baru mengenal, namun tertarik untuk menerapkanSolusi Ketersediaan Tinggi, atau sekadar ingin beralih menggunakan solusi High Availability yang baru. Apakah Anda seorang mahasiswa yang baru saja mulai mempelajari administrasi sistem/rekayasa sistem, atau Anda seorang insinyur perangkat lunak veteran yang diminta untuk memperluas cakupan peran Anda agar mencakup perencanaan arsitektur sistem, poin-poin di bawah ini dapat membantu Anda dalam perjalanan untuk mendapatkan hasil maksimal dari rangkaian high availability/disaster recovery.

Tanpa basa-basi lagi, pertanyaan-pertanyaan di bawah ini merangkum pokok-pokok pembicaraan umum yang saya lihat dalam peran saya, dan akan membantu mempermudah pencarian Anda untuk memahami konsep-konsep utama dan menemukan solusi yang tepat.

Apa itu Pemulihan Bencana dan apa saja yang termasuk di dalamnya?

Pemulihan bencana, ketika digabungkan denganketersediaan tinggi, berfungsi untuk mengoptimalkan tujuan waktu pemulihan (RTO) – berapa lama layanan tidak dapat diakses sebelum dipulihkan – dan tujuan titik pemulihan (RPO) – data yang dapat Anda tanggung hilang saat memulihkan dari cadangan.tujuan waktu pemulihanmenggambarkan berapa lama sistem dapat mati dan masih sesuai dengan standar operasional. Umumnya, metrik ini dinyatakan dalam persentase – “lima sembilan uptime” yang umum mengacu pada uptime 99,999%, atau sekitar maksimum 5 menit downtime per tahun. Sasaran titik pemulihan sedikit lebih rumit, ia menggambarkan jumlah data yang dapat hilang namun masih sesuai dengan standar operasional. Misalnya, jika sistem tidak dapat kehilangan data apa pun setelah terjadi bencana, maka itu disebut “Zero RPO”. Akan sangat membantu jika kita memikirkan sistem yang ada pada suatu garis waktu, dan sasaran titik pemulihan sebagai jawaban atas pertanyaan berikut: “Jika sistem mengalami bencana, seberapa jauh ke belakang dalam garis waktu sistem tersebut Anda dapat ‘memutar balik’ dan masih memenuhi standar operasional”?

Bagaimana Pemulihan Bencana berbeda dari pendekatan tradisional dalam mengatasi pemadaman listrik?

Secara tradisional, tanpa infrastruktur yang sangat tersedia, lingkungan yang mengalami bencana mungkin memiliki tujuan waktu pengembalian yang lama. Sistem perlu dipulihkan, masalah mungkin perlu diselesaikan, dan aplikasi dimulai oleh administrator. Bergantung pada tingkat keparahan masalah, mungkin perlu waktu berjam-jam atau lebih untuk kembali beroperasi. Tim harus bekerja secara efisien dan menunjukkan komunikasi yang erat untuk memastikan layanan dipulihkan tanpa kesalahan, agar mereka tidak mengambil risiko penundaan tambahan dalam kembali beroperasi. Selain itu, data yang hilang selama pemadaman semacam ini bisa jadi signifikan. Jika pencadangan tidak dilakukan baru-baru ini atau jika salinan data terkini tidak dapat diakses, maka tim dapat mengandalkan data yang telah “basi” dan mengalami kemunduran operasional pada skala organisasi karena hilangnya data penting. Untuk melihat berbagai hal dari perspektif pelanggan, berapa lama Anda bersedia menunggu untuk mendapatkan akses ke layanan online saat Anda membutuhkannya? Sebagai pelanggan, seberapa besar penerimaan Anda jika etalase online kehilangan catatan transaksi Anda?

Saat memperkenalkan infrastruktur yang sangat tersedia, sarana untuk mencerminkan penyimpanan, dan sarana untuk mengatur ketersediaan tinggi, faktor-faktor yang memengaruhi RTO dan RPO semuanya dioptimalkan, dan bencana dapat diatasi dengan jauh lebih baik. Infrastruktur yang sangat tersedia bersifat redundan, sehingga sistem siaga tersedia untuk mengambil alih operasi. Lebih jauh, orkestrasi – perangkat lunak untuk mengelola lingkungan yang terkluster – mampu memulai layanan secara sistematis pada sistem siaga dengan responsivitas, keandalan, dan efisiensi yang lebih besar daripada yang dapat dicapai oleh intervensi manual. Hasilnya, tujuan waktu pengembalian berkurang, dan alih-alih membutuhkan waktu berjam-jam untuk pulih dari bencana, pemulihan dapat dilakukan dalam hitungan menit atau kurang.

Aspek lain dari infrastruktur yang sangat tersedia adalah redundansi data. Disk dapat “dicerminkan”, di mana disk yang terpasang pada sistem yang berbeda semuanya dapat menerima data yang sama persis secara real time. Hasilnya, data yang tersedia pada sistem siaga yang disebutkan di atas dapat berupa salinan persis, yang secara efektif mempertahankan cadangan data segera sebelum bencana terjadi. Pada gilirannya, ketika layanan dipulihkan, aplikasi berjalan dengan tujuan titik pemulihan yang mendekati nol, menjaga tujuan titik pemulihan pada status operasi terkini yang memungkinkan ketika tiba saatnya bagi orkestrator untuk memindahkan operasi ke sistem siaga.

Apa kesalahan paling umum yang dilakukan organisasi saat merancang strategi pemulihan bencana ketersediaan tinggi (HADR), dan bagaimana mereka dapat menghindarinya?

Salah satu kesalahan paling umum yang diamati adalah kurangnya lingkungan QA/Pengujian. Tim Pengalaman Pelanggan SIOS telah menanggapi beberapa contoh seperti itu, di mana organisasi mencoba melakukan pengujian aplikasi/sistem operasi.menambal/peningkatanatau hanya pemeliharaan rutin dan mengalami masalah karena perencanaan yang tidak memadai atau semacam ketidakcocokan yang tidak menguntungkan. Lalu, adawaktu istirahatyang terjadi pada lingkungan, dan prosedur pemeliharaan berubah menjadi prosedur pemulihan. Hal ini menimbulkan penundaan, komplikasi, dan potensi masalah yang terus meningkat dalam lingkungan produksi.

Sejauh ini, rekomendasi terbesar yang dapat ditawarkan kepada organisasi adalah membuat salinan satu-ke-satu dari lingkungan produksi yang beroperasi dalam kapasitas jaminan kualitas. Setiap prosedur yang perlu terjadi pada produksi harus terlebih dahulu melalui “latihan” di lingkungan QA. Ini memberi organisasi kebebasan untuk menjalankan operasi yang direncanakan dan melakukan perbaikan tanpa mempertaruhkan kapasitas produktif infrastruktur mereka. Mempraktikkan operasi dalam lingkungan yang aman dan berisiko rendah memastikan bahwa tim siap untuk beroperasi di lingkungan produksi tanpa risiko menghadapi masalah yang tidak terduga dan harus “melanggar naskah” untuk merespons dengan cepat dan benar saat berada di bawah tekanan. Jika terjadi masalah di lingkungan QA, maka tim dukungan dapat dihubungi, dan masalah tersebut dapat diselidiki dengan keamanan masalah ini yang terisolasi dari memengaruhi operasi bisnis. Ini dapat sangat meningkatkan potensi solusi untuk ditemukan dan diimplementasikan ke dalam operasi dengan cara yang terkendali, terencana, dan efektif.

Manfaat lingkungan QA yang disebutkan di atas penting bagi organisasi mana pun; namun, seiring organisasi mengadopsi strategi pemeliharaan yang lebih kompleks, keberadaan lingkungan pengujian ini menjadi semakin penting. Penggunaan lingkungan pengujian ini tidak hanya memfasilitasi prosedur pemutakhiran yang lebih lancar, tetapi juga memungkinkan perusahaan untuk mengurangi risiko saat mengadopsi model pemeliharaan yang menimbulkan kompleksitas untuk mengembalikan ketersediaan sistem yang lebih baik selama aktivitas pemeliharaan. Dalam skenario apa pun, menguji rencana pemeliharaan dalam lingkungan QA, meningkatkan rencana berdasarkan temuan dari “latihan awal”, dan menggunakan pengalaman yang diperoleh dari praktik ini memungkinkan organisasi untuk mengelola sistem produksi sambil meminimalkan risiko menghadapi masalah.

Apa pentingnya menghilangkan titik kegagalan tunggal?

Kendala umum lain yang dapat dialami tim muncul dari adanya “mata rantai terlemah” dalam arsitektur yang tidak mendapatkan manfaat dari tingkat perencanaan yang diterima oleh aspek lain dari lingkungan tersebut. Hal ini paling baik dijelaskan dengan sebuah contoh. Tim Pengalaman Pelanggan SIOS pernah bekerja dengan seorang pelanggan yang merancang secara ekstensif untuk menjagaAplikasi SAPberjalan di lingkungan mereka dan terlindungi dengan sangat baik dari masalah yang memengaruhi sistem yang menjalankan aplikasi SAP. Sayangnya, pelanggan ini menginvestasikan banyak upaya perencanaan untuk melindungi aplikasi mereka dan tidak memberikan upaya perencanaan yang sama untuk aspek lain dari lingkungan mereka. Akibatnya, semua sistem bergantung pada sistem DNS internal tunggal yang menyelesaikan host dalam jaringan pribadi mereka. Meskipun semua upaya dalam melindungiGETAH, ketika masalah terjadi pada sistem DNS mereka, seluruh lingkungan mengalami masalah signifikan ketika resolusi nama tidak lagi tersedia. Secara efektif, upaya yang dilakukan untuk melindungi aplikasi SAP mereka tidak membantu lingkungan mereka mengatasi masalah tersebut, hanya karena DNS merupakan “mata rantai lemah” yang diandalkan oleh semua sistem lain agar berfungsi dengan baik. Saat merencanakan lingkungan, penting untuk mundur sejenak dan melihat gambaran yang lebih besar – perhatikan mata rantai terlemah yang muncul dalam suatu arsitektur. Memperbaiki mata rantai terlemah meningkatkan potensi seluruh lingkungan untuk mengatasi bencana.

Bagi organisasi yang sangat bergantung pada layanan cloud, bagaimana mereka dapat melindungi diri dari bencana di Zona atau wilayah?

Perlindungan terhadap bencana di seluruh zona atau wilayah dapat dilakukan hanya dengan mendistribusikan sumber daya secara geografis. Misalnya, seseorang dapat menghosting server aplikasi utamanya di wilayah AS Timur. Kemudian, untuk dilindungi terhadap pemadaman yang memengaruhi wilayah AS Timur, terdapat sistem siaga yang dihosting di “Situs Pemulihan Bencana” yang jauh dari wilayah AS Timur – mungkin wilayah AS Barat. Meskipun hal ini memperkenalkan beberapa langkah tambahan untuk memastikan komunikasi lintas wilayah, upaya tersebut sangat berharga karena hal ini memberikan perlindungan terhadap bencana di seluruh zona dan wilayah. Pemadaman total wilayah AS Timur penyedia cloud dapat ditahan dengan menyediakan aplikasi dalam layanan di wilayah AS Barat. Perlindungan terhadap pemadaman yang terjadi di wilayah tertentu tidak perlu rumit, dan memastikan situs Pemulihan Bencana ada untuk mengasumsikan operasi akan meningkatkan ketersediaan aplikasi dan redundansi data dalam lingkungan produksi.

Bagaimana Anda merekomendasikan organisasi menyeimbangkan kompleksitas dan biaya penerapan strategi HA/DR yang kuat dengan kebutuhan kelincahan bisnis?

Ada anggapan umum bahwa solusi HA/DR itu rumit atau mahal, atau keduanya. Berdasarkan anggapan ini, penting untuk tetap memiliki perspektif yang kuat terhadap risiko yang ada. Sistem beroperasi untuk beberapa tujuan bisnis, dan ini menghasilkan pendapatan. Ketika sistem mati karena pemadaman, ada lebih banyak biaya daripada sekadar pendapatan yang hilang. Tanpa strategi HA/DR, pemadaman mengharuskan karyawan untuk secara aktif memecahkan masalah, yang menghasilkan biaya jam kerja karyawan untuk memperhitungkan biaya waktu henti, bahkan mungkin pada jam-jam ketika karyawan tidak cukup istirahat dan tidak siap untuk melakukan pekerjaan terbaik mereka. Selain itu, ada biaya tambahan yang tersisa dalam hal gangguan tugas rutin dan keterlambatan/kelambatan ketika karyawan harus beralih tugas untuk menyelesaikan masalah produksi dan kemudian beralih kembali ke tugas rutin mereka. Lebih jauh lagi, ada biaya reputasi yang dapat menyebabkan kegagalan mengenali peluang untuk pendapatan. Misalnya, apa yang terlintas dalam pikiran Anda jika Anda memikirkan“Serangan Massa”? Meskipun hal ini tidak langsung membawaMasalah dan pemberitaan buruk terkaityang dialami CrowdStrike pada bulan Juli 2024, pada saat artikel ini ditulis (25 Maret 2025), harga saham mereka baru saja kembali ke level sebelum penerbitan pada tanggal 19 Juli 2024. Dengan mempertimbangkan biaya peluang untuk mengonfigurasi solusi HA/DR, faktor-faktor yang disebutkan di atas dapat mengubah analisis secara drastis. Umumnya, pelanggan SIOS merasa bahwa penerapan solusi HA/DR menghemat uang mereka dalam jangka panjang. Selain itu, didukung oleh peningkatan dan iterasi selama puluhan tahun pada penawaran HA/DR dari SIOS Technology, kompleksitas dalam mengonfigurasi solusi tersebut lebih mudah dipahami dan tidak serumit sebelumnya. Jika ada faktor yang masih menimbulkan kekhawatiran atas kompleksitas pengenalan solusi HA/DR ke lingkungan produksi, SIOS Technology memiliki penawaran layanan profesional yang dapat membantu melatih tim, melakukan aktivitas instalasi dan konfigurasi, atau sekadar memvalidasi konfigurasi yang ada. Dengan peluang ini,membawa Ketersediaan Tinggi ke dalam arsitektur sistemtidak hanya lebih sederhana dari sebelumnya, tetapi juga dapat diimplementasikan lebih cepat dari sebelumnya. Terakhir, bagi organisasi yang khawatir tentang kompleksitas karena konfigurasi yang unik atau mencoba mencapai utilitas solusi HA/DR yang paling maksimal, tim dukungan kelas dunia kami siap membantu mewujudkan setiap implementasi hingga mencapai potensi penuhnya.

Bagaimana solusi SIOS Technology berperan dalam membantu organisasi menerapkan pendekatan pemulihan bencana yang Anda advokasi?

Solusi Teknologi SIOSdapat memenuhi semua aspek yang telah dibahas sebelumnya, berikut ini beberapa diantaranya:

Pendekatan modern terhadap pemulihan bencana diadopsi melaluiProduk LifeKeeper dan DataKeeper, yang bersama-sama kita sebutRangkaian Perlindungan SIOSBaik di Linux maupun Windows, produk-produk ini tersedia untuk menyediakan orkestrasi sumber daya di seluruh klaster guna memastikan respons yang cepat dan efisien terhadap bencana sekaligus memastikan data direplikasi dan tersedia pada sistem siaga. LifeKeeper memantau aplikasi untuk mencari kesalahan dan berkomunikasi antar node guna memastikan sistem menjadi target yang valid untuk pemulihan aplikasi. Datakeeper mereplikasi data secara real time guna memastikan sistem siaga mampu mewarisi aplikasi jika terjadi masalah dan melanjutkan operasi pada data terbaru yang tersedia. Bersama-sama, produk-produk ini bekerja untuk meminimalkan lamanya waktu aplikasi tidak berfungsi dan meminimalkan hilangnya data jika terjadi bencana.

Produk-produk ini juga terintegrasi sepenuhnya dalam lingkungan Anda. Ada mekanisme untuk menyediakan kontrol jaringan yang efisien sehingga klien selalu dapat menyelesaikan koneksi ke server aplikasi. Solusi yang digunakan tidak hanya akan memantau aplikasi atau komponen tertentu dari suatu sistem, tetapi juga seluruh sistem dan lingkungan. Melalui penggunaan fungsionalitas “kuorum”, lingkungan dipantau pada tingkat “gambaran besar” untuk memastikan aplikasi dipulihkan pada sistem yang benar dan data terlindungi. Ada perlindungan yang tersedia untuk berbagai skenario bencana, sehingga SIOS Protection Suite dapat merespons dengan tepat.

SIOS Protection Suite juga dapat bekerja lintas wilayah, menyediakan perlindungan yang telah kita bahas terhadap bencana di tingkat zona atau wilayah. Aplikasi dapat dimigrasikan lintas wilayah, dan data dapat direplikasi lintas wilayah dengan kemudahan yang sama seperti saat direplikasi dalam wilayah yang sama. Selain itu, lingkungan dapat dibuat bertingkat. Beberapa node dapat dihosting di wilayah utama dan bertindak sebagai sistem aktif atau siaga, menyediakan respons cepat terhadap masalah di tingkat sistem, sementara situs pemulihan bencana di wilayah lain juga dapat dikelola untuk memastikan adanya perlindungan dari bencana di tingkat wilayah dengan kecepatan dan efektivitas perlindungan yang sama.

Terakhir, produk SIOS Protection Suite telah digunakan selama puluhan tahun di dunia nyata. Produk ini telah diuji coba dalam berbagai skenario dan konfigurasi penerapan, serta telah ditingkatkan kemudahan penggunaannya selama bertahun-tahun. Hasilnya, ini adalah solusi yang fleksibel, mudah diadopsi, dan sangat sesuai dengan lingkungan produksi. Kompleksitas dalam merancang dan mengonfigurasi solusi HA/DR dapat dihindari dengan mengadopsi SIOS Protection Suite dan menikmati manfaat dari riwayat pengembangan yang kaya dengan berbagai peningkatan yang tak terhitung jumlahnya, ditambah dengan tim dukungan kelas dunia yang siap membantu jika ada pertanyaan atau masalah yang mungkin timbul. Selain semua ini, ada juga peluang untuk menjalani prosedur instalasi atau validasi kolaboratif untuk penawaran SIOS Protection Suite, yang memastikan lingkungan Anda siap menghadapi apa pun yang dapat terjadi di dunia. Terakhir, bagi tim yang membutuhkan staf yang sangat berpengalaman dan ingin memaksimalkan pemanfaatan SIOS Protection Suite beserta komponen-komponennya, SIOS menawarkan pelatihan yang memungkinkan tim bekerja sama dengan staf untuk memahami komponen-komponen yang berperan serta dan berdiskusi secara aktif guna memfasilitasi pemahaman yang mendalam guna memastikan staf dapat langsung bekerja dengan semua informasi yang dibutuhkan untuk menerapkan solusi hingga mencapai potensi tertingginya.

Lindungi bisnis Anda dari waktu henti dan kehilangan data—minta demoataumulai uji coba gratis Andauntuk melihat SIOS beraksi.

Penulis: Philip Merry, CX – Software Engineer di SIOS Technology Corp.

Direproduksi dengan izin dariSIOS

DataKeeper dan Baseball: Pendekatan Strategis terhadap Pemulihan Bencana

DataKeeper dan Baseball: Pendekatan Strategis terhadap Pemulihan Bencana

Sepanjang karir saya,Penjaga Datamenjadi standar industri dalam “think tank” dan obrolan “pendingin air”, ketika menyangkut Perlindungan Data danPemulihan BencanaBagaimana dengan hobi orang Amerika yang hebat, yaitu baseball dan perbandingannya dengan DataKeeper? Meskipun saya penggemar berat olahraga ini, karena kedua hal ini tampaknya tidak berhubungan, ada beberapa kesamaan yang dapat ditelusuri.

Membangun Rencana Permainan yang Memenangkan Perlindungan Data

Pertama dan terutama, Baseball dan DataKeeper memerlukan “rencana permainan” yang cermat. Dalam baseball, tim telah berlatih dan menyusun rencana untuk mengalahkan lawan mereka dengan harapan menang. Demikian pula, DataKeeper memerlukan strategi yang “memancing pikiran” untuk memastikan perlindungan data dimanfaatkan dan dapat dipulihkan jika terjadi bencana.

Kedua, kerja sama tim tetap menjadi yang terpenting. Pemain infield, pemain outfield, manajer, dan pemukul bola masing-masing memiliki peran khusus untuk memastikan peluang kemenangan terbaik. Dengan DataKeeper, beberapa tim dapat terlibat, misalnya, Administrator Basis Data, staf Infrastruktur, Pengalaman/Dukungan Pelanggan, Manajemen, dan masih banyak lagi. Semua harus benar-benar diinvestasikan dalam melindungi dan memulihkan data secara efektif.

Perbedaan Baseball dan DataKeeper: Taruhannya Lebih Tinggi di Bidang TI

Ada beberapa perbedaan yang tidak dapat diabaikan. Meskipun kalah dalam pertandingan bisbol, terutama jika itu adalah Seri Dunia, Pertandingan 7, inning terakhir, 2 out, 3 bola – 2 strike, dapat menjadi “menyebalkan”, taruhannya jauh, jauh lebih tinggi dengan DataKeeper. Kehilangan data dapat memiliki konsekuensi serius bagi bisnis. Sementara pemain bisbol memerlukan keterampilan atletik yang unik, DataKeeper adalah solusi yang memerlukan pengetahuan tentang Sistem Perusahaan dan proses terkait.

Singkatnya, meskipun baseball dan DataKeeper mungkin tampak sangat berbeda, ada beberapa persamaan yang dapat kita simpulkan. Keduanya memerlukan:

• Strategi
• Kerja sama
• . . . dan Keahlian

Apakah Anda penggemar baseball atau profesional TI, jelas bahwa keduanya membutuhkan tingkat keterampilan dan dedikasi untuk berhasil.

Apa Rencana Perlindungan Data Anda?

Lihat rencana permainan/solusi yang ditawarkan dius.sios.com/solusi/

BERMAIN BOLA . . .

Penulis: Gregory A. Tucker, Insinyur Dukungan Produk Senior di SIOS

Direproduksi dengan izin dariSIOS

Penganggaran untuk Risiko Downtime SQL Server

Penganggaran untuk Risiko Downtime SQL Server

Di dalaminiArtikel TechRadar Pro “Budgeting for SQL Server Downtime Risk,” Dave Bermingham dari SIOS menekankan pentingnya menyelaraskan rencana kesinambungan bisnis dengan anggaran yang realistis untuk mengurangi gangguan dalam penerapan SQL Server yang sangat penting. Ia menyarankan organisasi untuk menilai signifikansi setiap instans SQL Server, memahami potensi dampak downtime—termasuk hilangnya pendapatan, berkurangnya produktivitas, kerusakan data, dan sanksi hukum—dan mengalokasikan sumber daya yang sesuai, baik di tempat, cloud, atau hybrid, untuk memastikan kesiapan menghadapi bencana.

Direproduksi dariSIOS

Migrasi dari SIOS DataKeeper untuk Linux ke DRBD

Migrasi dari SIOS DataKeeper untuk Linux ke DRBD

SIOS memperkenalkan Kit Pemulihan Perangkat Blok Replikasi Terdistribusi (DRBD) diSIOS LifeKeeper untuk Linux versi 9.9.0. Migrasi dariPenjaga Data SIOSuntuk Linux ke DRBD adalah proses sederhana bagi mereka yang ingin bereksperimen dengan fitur DRBD dalamPenjaga Kehidupanserta bagi mereka yang sebelumnya lebih mengenal DRBD.

Memahami DRBD dan Manfaatnya di LifeKeeper

DRBD adalah solusi penyimpanan berbasis perangkat lunak, tanpa berbagi, dan direplikasi yang mencerminkan konten perangkat blok (hard disk, partisi, volume logis, dsb.) antar host. LifeKeeper for Linux DRBD Recovery Kit menyediakan kemampuan untuk mengonfigurasi dan mengendalikan sumber daya DRBD untuk ketersediaan tinggi.

Membandingkan SIOS DataKeeper untuk Linux dan DRBD

SIOS DataKeeper untuk Linux menyediakan kemampuan pencerminan data terintegrasi untuk lingkungan LifeKeeper. Ini merupakan alternatif bagi pelanggan yang ingin membangunklaster ketersediaan tinggi(menggunakan SIOS LifeKeeper) tanpa penyimpanan bersama atau yang hanya ingin mereplikasi data penting bisnis secara real-time antar server.

SIOS DataKeeper menyediakan mirroring tingkat volume sinkron atau asinkron untuk mereplikasi data dari server utama (sumber mirror) ke satu atau beberapa server cadangan (target mirror). Langkah-langkah untuk membuat sumber daya PostgreSQL Anda dikecualikan dari blog ini, tetapi informasi lebih lanjut tentang mengonfigurasi PostgreSQL dengan SIOS LifeKeeper dapat ditemukanDi Sini.

Cara Memigrasikan Basis Data PostgreSQL Anda ke DRBD

1. Hentikan aplikasi PostgreSQL melalui UI LifeKeeper

sumber daya lkcli hapus –tag pgsql-demo

1. Buat cadangan data untuk database PostgreSQL dan file log

cp -pra /pgsql-demo* /cadangan/

1. Buat sumber daya DRBD baru dengan lokasi sistem berkas sementara.

sumber daya lkcli buat drbd –tag drbd-pgsql-demo –perangkat /dev/mapper/singledrbd-lk1 –fstype ext3 –titik_pemasangan /tmp/pgsql-demo

Pastikan untuk memilih fstype yang sama dengan sumber daya DataKeeper for Linux sebelumnya. Perangkat yang dipilih juga harus cukup untuk jumlah data dan log untuk kumpulan data basis data PostgreSQL.

1. Perluas sumber daya DRBD ke server target.

sumber daya lkcli perluas drbd –tag drbd-pgsql-demo –dest node-a –device /dev/xvdc3 –mode sinkron –laddr 10.15.29.165 –raddr 10.15.27.49

1. Nonaktifkan sumber daya sistem berkas untuk pangkalan data PostgreSQL.

sumber daya lkcli hapus –tag /pgsql-demo

1. Ubah pemilik dan grup untuk direktori /tmp/pgsql/demo.

chown postgres:postgres /tmp/pgsql/demo

1. Salin data ke sistem berkas cermin DRBD.

cp -pra /cadangan/* /tmp/pgsql-demo

1. Nonaktifkan sumber daya sistem berkas DRBD yang baru dibuat.

hapus sumber daya lkcli –tag /tmp/pgsql-demo

1. Putuskan ketergantungan antara sistem file sebelumnya dan sumber daya DataKeeper untuk Linux

penghapusan ketergantungan lkcli –parent /pgsql-demo –child dataep-pgsql-demo

Putuskan ketergantungan antara sistem berkas dan sumber daya DRBD.

hapus ketergantungan lkcli –induk /tmp/pgsql-demo –anak drbd-pgsql-demo

1. Buat ulang ketergantungan antara sistem file /pgsql-demo yang ada dan sumber daya drbd

ketergantungan lkcli buat – induk / pgsql-demo – anak drbd-pgsql-demo

1. Mulai sumber daya pgsql-demo

pemulihan sumber daya lkcli –tag pgsql-demo

MULAI pemulihan “pgsql-demo” di server “node-b”

menunggu server untuk memulai…. selesai

server dimulai

AKHIR pemulihan sukses “pgsql-demo” di server “node-b”

1. Hubungkan ke basis data dan verifikasi koneksi basis data.

Misalnya:

psql -p 3308 -h /pgsql-demo/socket -U psql

psql -p <port> -h <direktori soket> -U <pengguna db>

1. Hapus sumber daya sistem file DRBD sementara

lkcli sumber daya hapus /tmp/pgsql-demo

1. Hapus sumber daya datap dan sistem berkas sementara untuk DataKeeper untuk Linux.

hapus sumber daya lkcli –tag dataep-pgsql-demo

15. Verifikasi peralihan dan koneksi

Mengapa Bermigrasi dari SIOS DataKeeper untuk Linux ke DRBD?

Migrasi dari SIOS DataKeeper untuk Linux ke DRBD merupakan proses sederhana bagi mereka yang ingin bereksperimen dengan fitur-fitur DRBD dalam LifeKeeper serta bagi mereka yang sebelumnya lebih mengenal DRBD atau ingin memanfaatkan kecepatan replikasi asinkron DRBD yang lebih cepat dan dukungan kernel yang lebih luas.

Siap untuk memulai DRBD?Hubungi SIOS hari iniuntuk mempelajari bagaimana LifeKeeper dapat membantu Anda bermigrasi dengan lancar dan memanfaatkan potensi penuh DRBD untuk ketersediaan tinggi dan pemulihan bencana

Penulis: Cassius Rhue, VP Pengalaman Pelanggan di SIOS Technology Corp.

Direproduksi dengan izin dariSIOS

Mengapa Quorum Tanpa Penyimpanan/Tanpa Node Berbahaya bagi Ketersediaan Klaster?

Mengapa Quorum Tanpa Penyimpanan/Tanpa Node Berbahaya bagi Ketersediaan Klaster?

Secara umum, kuorum diartikan sebagai suatu badan atau sekelompok orang yang hadir untuk membuat keputusan.

Dalam LifeKeeper, Quorum memberlakukan konsensus yang menggunakan status node dalam kluster untuk menjalankan langkah berikutnya dalam menangani kegagalan node dalam kluster. LifeKeeperkuorum dapat dioperasikan dalam tiga mode; Penyimpanan, Mayoritas, dan TCP Jarak Jauh (TCP Jarak Jauh hanya tersedia dengan LifeKeeper untuk Linux).

• Quorum Penyimpanan menggunakan perangkat penyimpanan bersama untuk melacak pembaruan yang disediakan oleh sistem lain dalam klaster. Jika suatu sistem tidak menyediakan pembaruan, Quorum akan menandai klaster tersebut sebagai gagal.
• Kuorum Mayoritas bergantung pada struktur klaster yang jumlahnya ganjil, di mana satu node berfungsi sebagai saksi untuk menentukan apakah satu atau semua node di cluster tidak dapat berkomunikasi
• Koneksi jarak jauh TCP melalui layanan TCP/IP pada port tertentu untuk memverifikasi apakah node dalam kluster dapat berkomunikasi satu sama lain.

Memahami Pentingnya Kuorum dalam Cluster

Tujuan Quorum adalah untuk menjaga ketersediaan aplikasi dengan mengambil tindakan perbaikan untuk mengatasi situasi yang tidak direncanakan. Quorum melakukannya dengan mengurangi risiko situasi yang tidak terduga dan mengurangi waktu henti dengan menjaga komunikasi antara semua node dalam kluster.

Risiko Beroperasi Tanpa Kuorum di Klaster Anda

Terdapat risiko yang terlibat saat menggunakan kluster yang dikonfigurasi tanpa Kuorum. Skenario berikut akan membahas dampak tidak adanya kuorum dan pentingnya penerapannya.

Skenario 1: Mengurangi waktu henti

Downtime yang tidak disengaja dapat terjadi ketika satu atau lebih sistem tidak dapat digunakan akibat tindakan yang tidak dapat dihindari, misalnya, kerusakan atau kegagalan sementara dalam komunikasi jaringan.

Dengan kuorum seperti penyimpananatau TCP yang dikonfigurasi dari jarak jauh, akses ke perangkat penyimpanan dan atau port dapat digunakan untuk melacak status komunikasi dalam kluster. Tindakan tambahan ini dapat mencegah failover yang tidak perlu yang dapat menyebabkan waktu henti yang signifikan. Dalam kasus lain, Quorum akan mengambil tindakan untuk mematikan atau menghidupkan ulang server guna memulihkannya ke kondisi yang sehat dan menghindari waktu henti yang lebih lama.

Skenario 2: Otak Terbelah

Aotak terbelahadalah saat beberapa sistem dalam kluster meyakini bahwa mereka adalah server utama. Hal ini dapat terjadi saat server utama kehilangan komunikasi ke server sekundernya, dan server sekunder meyakini bahwa sistem utama mati. Hal ini menyebabkan dua sistem utama aktif dalam kluster.

Jika kuorum Mayoritas dikonfigurasikan, sistem lain akan disediakan sebagai saksi untuk berfungsi sebagai pemungutan suara untuk menentukan sistem mana yang harus berfungsi sebagai sistem utama, mencegah terjadinya perpecahan otak.

Mengapa Konfigurasi Kuorum yang Tepat Penting

Mengoperasikan klastertanpa penyimpanan atau kuorum mayoritas berbahaya karena meningkatkan risiko mengalami kehilangan data atau waktu henti yang lama akibat split-brain dan/atau pemadaman jaringan. Menggunakan Quroum dapat memberikan tindakan pencegahan dengan memastikan klaster selalu sehat dan sistem yang tidak sehat ditangani dengan tepat.

Hubungi SIOS hari iniuntuk mempelajari bagaimana solusi ketersediaan tinggi kami dapat membantu Anda mengonfigurasi kuorum dengan cara yang tepat dan menjaga kluster Anda tetap terlindungi.

Penulis: Alexus Gore, Insinyur Perangkat Lunak Pengalaman Pelanggan di SIOS Technology Corp.

Direproduksi dengan izin dariSIOS