Date: Januari 24, 2024
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