Tantangan Menggunakan Amazon EBS Multi-Attach untuk Klaster Failover Microsoft

Tantangan Menggunakan Amazon EBS Multi-Attach untuk Klaster Failover Microsoft

Ikhtisar Amazon EBS dan Kluster Failover Microsoft

Volume Multi-Lampirkan Amazon EBS dan MicrosoftKluster Failoveradalah alat yang ampuh dalam dunia komputasi awan dan manajemen data. Namun, mengintegrasikan kedua teknologi ini mungkin penuh dengan tantangan. Posting blog ini menyelidiki mengapa menggunakan Amazon EBS Multi-Attach untuk Microsoft Failover Clusters sering kali bukan pilihan terbaik.

Batasan AZ Tunggal untuk Kluster Failover yang Kuat

Batasan utama volume Amazon EBS adalah pembatasannya pada satu Availability Zone (AZ). Untuk klaster failover yang kuat, penerapan instans di beberapa AZ adalah praktik terbaik yang direkomendasikan, sesuatu yang tidak dapat didukung secara langsung oleh volume EBS.

Kekhawatiran SLA Ketersediaan Tinggi

Sementara volume EBS menawarkan aSLA ketersediaan 99,9%., angka ini masih jauh dari perkiraan umum sebesar 99,99% untuk solusi ketersediaan tinggi. AWS menjamin SLA yang lebih tinggi ini ketika menerapkan instans di beberapa AZ, sebuah manfaat yang tidak diperluas ke penerapan AZ tunggal.

Implikasi Biaya Volume IO2

Kluster Failover Windows dengan volume EBS multi-lampir memerlukan penggunaan volume IO2, yang kira-kira sembilan kali lebih mahal dibandingkan volume GP3 dengan ukuran dan kinerja serupa. Perbedaan biaya ini signifikan, terutama untuk penerapan skala besar.

Kompleksitas dalam Konfigurasi Klaster AWS

Bangunansebuah klaster di AWSdengan node di AZ yang sama memerlukan pembagian AZ menjadi beberapa subnet untuk mendukung alamat IP virtual (VIP) yang berbeda di cluster Windows. Kompleksitas ini, serta ketidakmampuan untuk berbagi satu VIP di seluruh node cluster, menambah tantangan konfigurasi.

SIOS DataKeeper: Alternatif Unggul

Penjaga Data SIOSmuncul sebagai solusi unggul, memungkinkan cluster yang menjangkau subnet sambil memberikan SLA ketersediaan 99,99% yang diinginkan. Tidak hanya menawarkan opsi penyimpanan yang lebih fleksibel, termasuk penggunaan disk GPT3, namun juga jauh lebih hemat biaya. Klaster yang menggunakan SIOS DataKeeper dengan disk GPT3 dapat menghabiskan biaya sekitar 20% dari biaya klaster berbasis IO2 serupa, dengan ketersediaan yang ditingkatkan.

Ketersediaan Tinggi Unggul dengan SIOS

Penggunaan volume Multi-Attach Amazon EBS di Microsoft Failover Clusters menghadirkan beberapa tantangan signifikan, mulai dari opsi penerapan AZ yang terbatas dan SLA ketersediaan yang lebih rendah hingga biaya yang lebih tinggi dan kompleksitas konfigurasi yang meningkat. SIOS DataKeeper menawarkan alternatif menarik, menyeimbangkan biaya, fleksibilitas, dan keandalan dengan lebih efektif. Bagi organisasi yang menginginkan ketersediaan tinggi dan efisiensi biaya, menjajaki opsi di luar EBS Multi-Attach adalah strategi yang bijaksana.Hubungi SIOSuntuk informasi lebih lanjut.

Direproduksi dengan izin dariSIOS

Video: Aplikasi Ketersediaan Tinggi Akan Menjadi Universal | Prediksi Dari Teknologi SIOS

Video: Aplikasi Ketersediaan Tinggi Akan Menjadi Universal | Prediksi Dari Teknologi SIOS

SIOS Technology adalah perusahaan solusi ketersediaan tinggi (HA) dan pemulihan bencana (DR) yang menyediakan ketersediaan aplikasi untuk database, aplikasi, dan layanan penting bagi pelanggan mereka di sistem Windows dan Linux, dan berbagai platform cloud.Cassius Rhue, VP Pengalaman Pelanggan di SIOS Technology, membagikan prediksinya pada tahun 2024.

Ketika ketergantungan pada aplikasi terus meningkat, akan ada peningkatan tekanan pada tim TI untuk memberikan ketersediaan tinggi yang efisien dan pemulihan bencana untuk aplikasi yang biasanya dianggap tidak penting dan juga aplikasi yang sangat penting. Karena perubahan ini, kita mungkin akan melihat perluasan solusi dan layanan perangkat lunak dengan ketersediaan tinggi untuk memenuhi harapan ini.

Dengan semakin banyaknya perusahaan yang berekspansi ke cloud dan menggunakan sistem operasi yang berbeda, diharapkan akan semakin banyak tim yang mencakup beragam sistem operasi, aplikasi, dan platform cloud. Tim akan mencari aplikasi dan solusi yang konsisten di berbagai sistem operasi dan lingkungan cloud untuk mengurangi kompleksitas dan meningkatkan efisiensi biaya.

Solusi HA juga harus konsisten di seluruh sistem operasi dan lingkungan cloud dan kita akan melihat adanya dorongan menuju HA cloud-agnostic. Perusahaan memerlukan solusi HA dan DR yang sederhana, otomatis, cepat, dan cerdas. Karena semakin banyak organisasi yang bermigrasi ke cloud, mereka perlu memastikan bahwa mereka tidak kehilangan data dalam proses tersebut. Solusi HA perlu menjembatani kesenjangan antara sistem lama dan sistem yang lebih modern.

Pada tahun 2024 akan terjadi peningkatan fokus pada retensi data, kontrol akses keamanan, dan izin yang mendorong organisasi untuk mengintegrasikan langkah-langkah keamanan yang lebih ditingkatkan ke dalam solusi, layanan, dan strategi ketersediaan tinggi dan pemulihan bencana. Karena volume data yang dikumpulkan terus meningkat, organisasi juga memerlukan lebih banyak informasi tentang alasan terjadinya kegagalan. Alat otomatisasi dan orkestrasi kemungkinan akan memainkan peran penting dalam menyederhanakan analisis akar masalah dan memberikan respons yang cerdas.

SIOS Technology akan terus fokus pada pelanggannya di tahun mendatang, membantu mereka menghindari dan mengurangi downtime, serta memastikan data dan aplikasi mereka tersedia saat bisnis paling membutuhkannya. Perusahaan akan terus mengoptimalkan solusinya, menyediakan layanan tambahan yang berdekatan untuk memberi manfaat bagi pelanggannya, serta membantu penyedia aplikasi dan penyedia cloud membentuk strategi HA yang efektif.

Direproduksi dengan izin dariSIOS

Mitsubishi Motors Memindahkan Sistem Penting ke Cloud dengan LifeKeeper untuk Perlindungan Ketersediaan Tinggi

Mitsubishi Motors Memindahkan Sistem Penting ke Cloud dengan LifeKeeper untuk Perlindungan Ketersediaan Tinggi

Ketika Mitsubishi Motors Corporation memperbarui sistem manajemen gudangnya di tiga lokasi dengan sistem berbasis cloud baru, mereka memerlukan cara baru untuk menyediakan ketersediaan tinggi tanpa menambah kompleksitas atau memperlambat kinerja.

“Bahkan jika terjadi masalah, LifeKeeper secara otomatis melakukan failover dari node server utama ke node sekundersistem dalam sekejap, dan pengoperasian berlanjut tanpa penundaan yang nyata bagi pengguna, menghemat waktu TI dan menghilangkan gangguan layanan bagi pelanggan,”

kata Hiromasa Tsuboshima, Manajer, Departemen TI Bisnis, Divisi TI Global, Mitsubishi Motors

Lingkungan

Setiap gudang Mitsubishi Motors mengandalkan sistem manajemen yang menangani pesanan dan inventaris suku cadang dan aksesoris mobil yang dijual oleh dealer, seperti karpet lantai dan rak atap. Ia mengelola penerimaan suku cadang dan perlengkapan, manajemen pengiriman untuk pesanan domestik dan internasional dari dealer, serta manajemen inventaris dan alokasi di dalam lokasi gudang itu sendiri.

Sistem lama dijalankan dengan perangkat keras server lokal yang sudah tua dan semakin rentan terhadap masalah yang menyia-nyiakan waktu TI untuk memecahkan masalah dan menyebabkan seringnya gangguan operasi. Sistem yang ada menggunakan redundansi milik produsen perangkat keras untuk mengurangi waktu henti. Jika masalah muncul pada sistem lama, personel TI harus menghentikan sistem secara manual dan mengalihkan pengoperasian ke perangkat keras yang berlebihan hingga masalah teratasi – sebuah proses yang memerlukan dua hingga empat jam waktu kerja staf TI.

Mitsubishi Motors harus memastikan bahwa suku cadang atau aksesori apa pun yang dipesan dalam jangka waktu penerimaan yang ditentukan akan dikirimkan ke dealer pada hari berikutnya. Oleh karena itu, downtime dalam waktu singkat sekalipun pada sistem yang sangat penting ini dapat berdampak signifikan terhadap bisnis.

Sistem manajemen gudang memainkan peran penting dalam memastikan bahwa semua pesanan diproses tepat waktu untuk memenuhi jadwal pengiriman. Misalnya, untuk memastikan pengiriman pesanan pada hari berikutnya yang masuk pada pukul 16:29, sistem manajemen gudang harus memproses dan menampilkannya pada pukul 16:40 sehingga dapat dimasukkan ke truk atau penerbangan terakhir pada hari itu. “Kami perlu pulih dalam waktu kurang dari 10 menit,” kata Iwasaki.

Tantangan

Hiromasa Tsuboshima, Manajer Departemen TI Bisnis, Divisi TI Global, Mitsubishi Motors Corporation, mengatakan, “Sistem yang ada di tiga dari enam gudang kami menggunakan perangkat keras mulai tahun 2012. Kami perlu menggantinya dengan sistem baru yang dapat menghilangkan pengurasan sumber daya manusia. sumber daya TI dan mengurangi dampak negatif pada operasi.” Menemukan solusi ketersediaan tinggi untuk sistem gudang berbasis cloud baru mereka sangat penting bagi keberhasilan proyek ini. Satoshi Iwasaki, anggota Departemen TI Bisnis di Divisi TI Global di Mitsubishi Motors Corporation, mengatakan, “Menurut kebijakan seluruh perusahaan, kami perlu bermigrasi dari sistem lokal yang lama ke cloud publik setiap kali kami membangun sistem baru. ”

Perangkat Lunak Ketersediaan Tinggi

Saat memigrasikan sistem manajemen gudang ke cloud publik, Mitsubishi Motor’s berkonsultasi dengan konsultan IT luar yang merekomendasikan SIOS LifeKeeper untuk Linux untuk ketersediaan tinggi. “Dalam pengalaman kami sebelumnya, kami selalu menggunakan solusi perangkat keras untuk ketersediaan tinggi,” kata Mr. Iwasaki. “Saya mempunyai banyak pertanyaan mendalam kepada perwakilan SIOS tentang penggunaan perangkat lunak untuk HA, dan SIOS memberikan jawaban yang akurat dan lengkap, yang membangun kepercayaan saya pada SIOS LifeKeeper.”

Faktor penting lainnya dalam memutuskan untuk memilih LifeKeeper adalah Layanan Profesional LifeKeeper opsional, yang menyediakan kit pemulihan sadar aplikasi (ARK) yang disesuaikan dengan kebutuhan sistem gudang khusus Mitsubishi.

SIOS ARK memungkinkan LifeKeeper memantau seluruh tumpukan aplikasi untuk potensi masalah waktu henti. Mereka juga mengatur failover aplikasi sesuai dengan praktik terbaik untuk kelancaran pengoperasian pada node sekunder. “Kami dapat menyesuaikan dan mengembangkan LifeKeeper untuk memenuhi kebutuhan kami, dan SIOS mampu menanggapi semua permintaan kami,” kata Bapak Iwasaki.

Failover Otomatis yang Cepat

“Bahkan jika terjadi masalah, LifeKeeper secara otomatis melakukan failover dari node server utama ke node sekunder dalam sekejap, dan pengoperasian berlanjut tanpa penundaan yang nyata bagi pengguna. Ini menghemat waktu TI dan menghilangkan gangguan layanan bagi pelanggan,” kata Mr. Tsuboshima. Bapak Tsuboshima bertugas mengawasi beberapa sistem di Divisi TI Global. Sebelum proyek peningkatan, dia biasa menerima peringatan kegagalan sepanjang malam yang memerlukan perhatian segera. Saat ini, jika terjadi kegagalan, dia hanya menerima pemberitahuan tentang kegagalan tersebut dan sistem terus beroperasi tanpa intervensi. Solusi SIOS telah menghemat banyak waktu berharga bagi Mr. Tsuboshima dan seluruh tim TI serta menghilangkan gangguan pada layanan.

Hasil

Manfaat memindahkan sistem manajemen gudang ke cloud sekaligus memastikan ketersediaan tinggi dengan LifeKeeper terlihat jelas dalam menanggapi pandemi tahun 2020. ‘Memiliki sistem kami di cloud, memungkinkan kami mengelola sistem dari jarak jauh. “Jika kita tetap menggunakan sistem lokal yang lama, kita akan menghadapi risiko tambahan yang signifikan ketika kita datang ke kantor selama masa darurat COVID-19 untuk memperbaiki masalah atau mengelola sistem,” kata Bapak Iwasaki.

Meskipun Mitsubishi Motors terus beralih ke cloud publik, banyak sistemnya yang masih menggunakan mainframe. “Saat kami mempertimbangkan untuk memindahkan sistem yang sangat penting, menjauh dari sistem host ini dan ke cloud, kami akan mengandalkan LifeKeeper untuk perlindungan ketersediaan tinggi,” kata Mr. Iwasaki. Kami akan merekomendasikannya kepada perusahaan di masa depan.”

Pelajari lebih lanjut tentang SIOS LifeKeeper untuk Linux

Belajar lebih tentangSIOS Protection Suite termasuk SIOS LifeKeeper, SIOS DataKeeper, dan kit pemulihan aplikasi SIOS.

Direproduksi dengan izin dariSIOS

Cara Menyiapkan Edisi Cluster DataKeeper (Cluster DKCE)

Cara Menyiapkan Edisi Cluster DataKeeper (Cluster DKCE)

Apa itu klaster DKCE?

DKCE adalah singkatan dariEdisi Cluster DataKeeper. DKCE adalah perangkat lunak SIOS yang menggabungkan penggunaan DataKeeper dengan fiturPengelompokan Failover Windowsuntuk menyediakanketersediaan tinggimelalui replikasi data berbasis migrasi.

Langkah-langkah membuat cluster DKCE

Untuk contoh ini, saya akan menyiapkan cluster tiga node dengan node ketiga mempertahankan mayoritas node.

Langkah 1:Anda harus menginstal DataKeeper di 2/3 sistem Anda untuk menyiapkan klaster DKCE. Klik tautan berikut untuk mengikuti panduan memulai cepat kami untuk menyelesaikan instalasi ini:https://docs.us.sios.com/dkce/8.10.0/en/topic/datakeeper-cluster-edition-quick-start-guide

Langkah 2:Tambahkan server yang ingin Anda kelola di Manajer Server. Ini perlu dilakukan di semua server yang Anda rencanakan untuk ditambahkan ke cluster.

Di server Anda, navigasikan ke Manajer Server

Klik “Tambahkan server lain untuk dikelola”

Saya menambahkan server dengan namanya di sini. Untuk melakukannya dengan cara ini Anda perlu memverifikasi nama sistem dan entri IP Anda di file host, yang terletak di sini: C:\Windows\System32\drivers\etc\hosts

Setelah semua server ditambahkan, Anda dapat memverifikasi dengan membuka “Semua server” di Manajer Server

Langkah 3:Anda mungkin melihat kesalahan winRM, untuk melewatinya jalankan perintah ini di PS sebagai administrator. Jalankan perintah ini untuk menambahkan server di klaster Anda sebagai host tepercaya. Perintah ini harus dijalankan pada setiap sistem di cluster Anda.

Set-Item WSMan:\localhost\Client\TrustedHosts -Nilai ‘<nama server 1>,<nama server 2>’

Langkah 4:Instal Pengelompokan Failover

Mengikutilangkah-langkah ini untuk menginstal pengelompokan failover.

Langkah 5:Navigasikan ke Manajer Kluster Failover

Langkah 6:Klik “Buat Klaster”

Langkah 7:Selanjutnya, tambahkan server yang seharusnya ada di cluster dan klik “Tambah” setelah setiap entri.

Langkah 8:Daftarnya harus serupa dengan yang ada pada gambar berikut

Langkah 9:Pilih “Jalankan semua pengujian” untuk pengujian validasi, dan klik Berikutnya.

Langkah 10:Setelah tes selesai, klik “Selesai”

Langkah 11:Namai cluster anda, saya beri nama cluster ini “Cluster1”, klik “Next”

Langkah 12:Pastikan “Tambahkan semua penyimpanan yang memenuhi syarat ke cluster” dicentang, klik “Berikutnya”

Langkah 13:Setelah langkah 12 selesai, klik “Selesai”

Langkah 14:Di Failover Cluster Manager, cluster pada awalnya akan offline. Saya akan menetapkan IP yang tidak terpakai untuk menjadikannya online. Di “Cluster Core Resources” klik kanan pada sumber daya alamat IP dan pilih Properties.

Di panel properti, subnet mask saya adalah /28, oleh karena itu saya akan memilih IP yang tersedia dalam rentang tersebut, 12.0.0.14. Klik “Terapkan”

Di “Cluster Core Resources” klik kanan pada cluster dan pilih “Bring Online”

Sumber daya sekarang harus online

Langkah 15:Navigasi ke Penjaga Data

Langkah 16:Klik kanan pada Job dan klik “Create Job” untuk mulai membuat mirror pertama kita

Beri nama pekerjaan itu. Saya memberi nama pekerjaan saya “pekerjaan1”, dan klik “Buat Pekerjaan”

Pilih sumber dan volume untuk mereplikasi data. Saya telah memilih Box1 sebagai sumber saya, dan volume D, klik “Berikutnya”

Selanjutnya, pilih server dan volume yang akan dijadikan target. Saya telah memilih Box2, dan volume D.

Sebuah prompt akan muncul meminta Anda untuk mendaftarkan secara otomatis volume yang telah Anda buat sebagai volume WSFC, pilih “Ya” untuk menjadikan volume ini Sangat Tersedia.

Di DataKeeper Anda sekarang dapat melihat bahwa volume sedang dicerminkan.

Langkah 17:Di Failover Cluster Manager, navigasikan ke Penyimpanan, lalu Disk. Anda akan melihat volume yang Anda daftarkan secara otomatis adalah WSFC.

Langkah 18:Mari kita verifikasi Pemilik yang harus diperiksa. Klik kanan pada volume, dan klik “Properti”

Karena saya membutuhkan orang ketiga untuk menjadi saksi dan mempertahankan mayoritas node, Box3 harus tidak dicentang/tetap tidak dicentang.

Langkah 19:Sekarang kita dapat menguji migrasi melalui Failover Cluster Manager. Navigasikan ke File Explorer dan buat file teks baru dalam volume yang saat ini sedang dicerminkan. Lakukan ini di Sumber Anda.

Navigasikan ke Failover Cluster Manager, klik “DataKeeper Volume D” dan pilih “Move Available Storage” dari panel Actions.

Klik kanan “Node Terbaik”. Ini secara otomatis akan bermigrasi ke target Anda.

Di Failover Cluster Manager verifikasi pemilik “DataKeeper Volume D” sekarang menjadi node target

Navigasikan ke DataKeeper untuk memverifikasi bahwa target Anda sekarang adalah Sumbernya, dan sebaliknya.

Penyiapan Klaster DKCE berhasil

Anda telah menyelesaikan penyiapan klaster DKCE.

SIOS menyediakansumber dayaDanpelatihanuntuk semua produk kami.

Direproduksi dengan izin dariSIOS

Memastikan Akses Terhadap Aplikasi Pendidikan Kritis

Memastikan Akses Terhadap Aplikasi Pendidikan Kritis

Pendidikan dan teknologi informasi (TI) semakin tidak dapat dipisahkan. Apakah TI yang dimaksud adalah aplikasi yang mendukung papan tulis kelas, database yang mendukung sistem pendaftaran universitas, sistem manajemen pembelajaran (LMS), atau sistem pemeliharaan gedung yang mengontrol akses siswa ke laboratorium, asrama, dan ruang makan — jika merupakan komponen utama infrastruktur TI Anda tiba-tiba menjadi gelap, baik guru, administrator, maupun siswa tidak dapat mencapai apa yang ingin mereka capai. Misi institusi tersebut terganggu. Jika interupsi terlalu sering terjadi, jika pengalaman siswa, guru, dan administrator terganggu, maka reputasi institusi itu sendiri juga akan terpuruk.

Infrastruktur TI yang dirancang untuk memastikan ketersediaan tinggi (HA) aplikasi yang penting bagi pengalaman pendidikan dapat meminimalkan risiko gangguan dan hilangnya reputasi yang dapat terjadi jika karena alasan apa pun sistem menjadi tidak responsif. Dalam hal ini, infrastruktur HA didefinisikan sebagai infrastruktur yang mampu memastikan ketersediaan aplikasi utama tidak kurang dari 99,99% setiap saat. Dengan kata lain, ini berarti aplikasi penting Anda tidak akan offline secara tiba-tiba selama lebih dari empat menit per bulan.

Bagaimana cara mencapai HA? Pertanyaan itu sudah mudah dijawab, tapi itu bukan satu-satunya pertanyaan yang perlu Anda tanyakan. Hal yang sama pentingnya adalah: Aplikasi manakah yang sangat penting sehingga memerlukan konfigurasi HA? Intinya, infrastruktur TI yang dikonfigurasi untuk HA memiliki satu atau lebih rangkaian server sekunder dan subsistem penyimpanan yang ditempatkan di lokasi yang berbeda secara geografis (yang dapat berupa pusat data jarak jauh jika server utama Anda berada di lokasi atau dalam ketersediaan terpisah. zona [AZ] jika server Anda berada di cloud). Jika ada sesuatu yang menyebabkan aplikasi yang berjalan di server utama berhenti merespons, perangkat lunak HA yang mengelola aplikasi Anda akan segera mengalihkan aplikasi ke server sekunder, di mana aplikasi penting Anda akan dimulai kembali dari titik di mana server utama berhenti merespons. Bergantung pada ukuran dan karakteristik kinerja server utama yang ingin Anda replikasi, server sekunder tersebut mungkin mahal, jadi kecil kemungkinannya Anda akan mengonfigurasi semua aplikasi akademis Anda untuk HA. Setelah Anda menentukan aplikasi mana yang memerlukan investasi pada HA, Anda akan mengetahui di mana Anda perlu membangun lingkungan HA.

Pilihan untuk Mencapai Ketersediaan Tinggi

Setelah Anda memilih aplikasi yang ingin Anda lindungi, pilihan Anda untuk mencapai HA menjadi lebih jelas. Apakah mereka berjalan di Windows atau Linux? Apakah sistem manajemen basis data (DBMS) Anda memiliki dukungan bawaan untuk konfigurasi HA? Jika ya, apa batasannya? Jika aplikasi penting Anda berjalan di Windows dan SQL Server, misalnya, Anda dapat mengaktifkan HA menggunakan fitur Availability Group (AG) dari SQL Server itu sendiri. Alternatifnya, Anda dapat mengonfigurasi HA menggunakan alat pengelompokan SANless pihak ketiga, yang menawarkan opsi yang tidak ditawarkan oleh layanan AG di SQL Server. Jika Anda mencoba melindungi server database dari beberapa vendor, atau jika beberapa aplikasi penting Anda berjalan di Windows sementara yang lain berjalan di Linux, kemampuan Anda untuk mengelola HA akan difasilitasi dengan penggunaan solusi HA yang mendukung banyak DBMS dan OS platform. Memilih solusi cluster yang mengakomodasi beragam DBMS dan platform OS akan menyederhanakan manajemen, berbeda dengan potensi kompleksitas dan kerumitan dalam menangani beberapa layanan HA asli database secara bersamaan.

Memastikan Ketersediaan Tinggi melalui solusi HA asli database

Jika Anda menggunakan solusi HA asli database, seperti fitur AG pada SQL Server, perangkat lunak akan secara sinkron mereplikasi semua data dalam database SQL Server utama Anda ke instance identik dari database tersebut di server sistem sekunder. Jika terjadi sesuatu yang menyebabkan server utama berhenti merespons, maka fitur monitoring pada komponen AG secara otomatis akan menyebabkan server sekunder mengambil alih. Karena fitur AG telah mereplikasi seluruh data secara real time, server sekunder dapat segera mengambil alih dan hampir tidak ada gangguan layanan atau kehilangan data.

Banyak alat HA asli database beroperasi dengan cara yang sama. Namun ada beberapa peringatan ketika mempertimbangkan pendekatan database-native: Jika layanan HA digabungkan ke dalam DBMS itu sendiri, layanan tersebut hanya dapat mereplikasi data yang terkait dengan DBMS tersebut. Jika data penting lainnya berada di server utama Anda, data tersebut tidak akan direplikasi ke server sekunder dalam skenario HA asli database. Mungkin ada batasan lain mengenai apa yang juga akan direplikasi oleh layanan asli database. Jika Anda menggunakan fungsionalitas AG Dasar yang digabungkan ke dalam SQL Server Standard Edition, misalnya, setiap AG hanya dapat mereplikasi satu database SQL ke satu lokasi sekunder. Anda dapat membuat beberapa AG Dasar jika aplikasi Anda melibatkan beberapa database SQL, namun Anda tidak dapat mengontrol apakah setiap AG melakukan failover pada saat yang sama dalam situasi failover — dan masalah mungkin timbul jika tidak dilakukan. Salah satu cara mengatasi keterbatasan ini adalah dengan menggunakan fungsionalitas Always On AG yang digabungkan ke dalam SQL Server Enterprise Edition, yang memungkinkan replikasi beberapa database SQL ke beberapa server sekunder, namun hal ini bisa menjadi sangat mahal dari sudut pandang lisensi jika aplikasi Anda tidak melakukannya. jika tidak, gunakan salah satu fitur SQL Server Enterprise Edition.

Solusi HA asli database lainnya mungkin memiliki kendala serupa, jadi pastikan untuk memahaminya sebelum berinvestasi dalam pendekatan tersebut.

Memastikan Ketersediaan Tinggi melalui SANless Clustering

Sebagai alternatif terhadap pendekatan database-asli terhadap HA, Anda dapat menggunakan alat pihak ketiga untuk membuat klaster SANless. Sama seperti konfigurasi AG yang dijelaskan di atas, perangkat lunak pengelompokan SANless mengotomatiskan replikasi data yang sinkron dari server primer ke server sekunder; itu juga mengatur failover langsung ke server sekunder jika server utama menjadi tidak responsif. Karena failover hanya membutuhkan waktu beberapa detik, akses administrator, dosen, dan mahasiswa ke aplikasi penting Anda akan tetap tidak terganggu.

Perbedaan penting antara pengelompokan SANless dan pendekatan database-native terletak pada detail praktisnya. Pendekatan pengelompokan SANless adalah basis data agnostik. Ini mereplikasi data apa pun pada volume penyimpanan yang ditentukan. Itu bisa mencakup banyak database dari beberapa vendor, file teks, file video, atau aset pendidikan lainnya yang ketersediaannya penting. Hal ini dapat menghemat banyak uang bagi institusi jika pendekatan database-native terhadap HA memerlukan upgrade ke edisi database yang lebih mahal. Terakhir, seperti disebutkan sebelumnya, jika Anda mencoba melindungi aplikasi dan data yang berjalan di beberapa lingkungan operasi, pendekatan pengelompokan SANless mungkin lebih mudah dikelola dibandingkan pendekatan database-asli individual. Anda dapat menggunakan pengelompokan SANless untuk memastikan HA di lingkungan Windows atau Linux, yang dapat menghilangkan kompleksitas yang mungkin menyertai penerapan pendekatan asli database yang berbeda antar lingkungan operasi.

Direproduksi dengan izin dariSIOS