Cara Memberikan Ketersediaan Tinggi untuk SQL Server di Lingkungan Linux

Jika organisasi Anda menjalankan Microsoft SQL Server yang penting bagi bisnis di Linux, tim TI Anda pasti tahu betapa sulitnya mempertahankan ketersediaan, kinerja, dan keamanan yang tinggi. Yang paling sulit adalah cara memastikan ketersediaan tinggi dengan replikasi yang kuat dan failover otomatis. Menggunakan perangkat lunak sumber terbuka dan solusi klaster HA SANless yang mudah dikonfigurasi dapat menawarkan pendekatan pemeliharaan yang lebih sederhana tanpa mengorbankan keselamatan dan kinerja yang dibutuhkan organisasi Anda.

Opsi Ketersediaan Tinggi Terbatas untuk Linux

Sebagian besar distribusi Linux memberi departemen TI dua pilihan lebih rendah untuk ketersediaan tinggi: membayar lebih untuk SQL Server Enterprise Edition untuk mengimplementasikan Always On Availability Groups, atau berjuang untuk membuat konfigurasi Linux HA sendiri yang rumit berfungsi dengan baik — sesuatu yang bisa sangat luar biasa sulit dilakukan.

Masalah dengan menggunakan Edisi Perusahaan adalah bahwa hal itu merusak strategi penghematan biaya untuk menggunakan sistem operasi sumber terbuka pada perangkat keras komoditas. Untuk sejumlah aplikasi SQL Server kecil yang terbatas, mungkin saja ada alasan untuk membenarkan biaya tambahan. Tapi itu terlalu mahal untuk banyak aplikasi database dan tidak akan melakukan apa pun untuk menyediakan HA tujuan umum untuk Linux.

Menyediakan HA di semua aplikasi yang berjalan di lingkungan Linux dimungkinkan menggunakan perangkat lunak sumber terbuka, seperti Pacemaker dan Corosync, atau Ekstensi Ketersediaan Tinggi SUSE Linux Enterprise. Tetapi membuat tumpukan perangkat lunak lengkap berfungsi seperti yang diinginkan memerlukan pembuatan (dan pengujian) skrip khusus untuk setiap aplikasi, dan skrip ini sering kali perlu diuji ulang dan diperbarui bahkan setelah perubahan kecil dilakukan pada perangkat lunak atau perangkat keras yang digunakan. Kemampuan terkait ketersediaan yang tidak didukung di SQL Server Standard Edition dan Linux dapat membuat upaya ini lebih menantang.

Menemukan Solusi Ketersediaan Tinggi Alternatif untuk SQL Server di Linux

Untuk membuat HA hemat biaya dan mudah diterapkan, Anda mungkin ingin mempertimbangkan dua pendekatan tujuan umum yang berbeda.

Salah satunya adalah menggunakan sistem berbasis penyimpanan yang melindungi data dengan mereplikasinya dalam jaringan area penyimpanan (SAN) yang redundan dan tangguh. Pendekatan ini agnostik sehubungan dengan sistem operasi host, tetapi memerlukan bahwa seluruh infrastruktur SAN diperoleh dari satu vendor dan bergantung pada ketentuan failover terpisah untuk memberikan ketersediaan tinggi.

Pendekatan lainnya adalah berbasis host dan melibatkan pembuatan kluster SANless agnostik penyimpanan di seluruh instance server Linux. Sebagai hamparan HA, cluster ini mampu beroperasi di LAN dan WAN di cloud pribadi, publik, dan hybrid. Hamparan tersebut juga bersifat aplikasi-agnostik, memungkinkan organisasi memiliki solusi HA universal tunggal di semua aplikasi. Meskipun pendekatan ini menghabiskan sumber daya host, ini relatif murah dan mudah diskalakan di lingkungan Linux.

Sebagian besar opsi cluster HA SANless menyediakan kombinasi replikasi data level blok waktu nyata, pemantauan aplikasi berkelanjutan, dan kebijakan pemulihan failover / failback yang dapat dikonfigurasi untuk melindungi semua aplikasi bisnis penting, termasuk yang menggunakan Mesin Virtual Cluster Always On Failover yang tersedia dalam Edisi Standar dari SQL Server.

SIOS Technology Corp. menawarkan solusi cluster HA SANless yang lebih kuat untuk Linux dengan kemampuan canggih yang dirancang untuk membebaskan TI dari kerumitan dan tantangan sehari-hari dalam mendukung dan mengoptimalkan infrastruktur komputasi. Solusi SIOS Protection Suite dengan LifeKeeper menyediakan:

• Pemantauan berkelanjutan dari seluruh tumpukan aplikasi Linux
• Perlindungan Sadar Aplikasi Lengkap dengan kit pemulihan aplikasinya (ARK) untuk pemulihan yang cepat dan aman atau kegagalan aplikasi dan database yang kompleks
• Penyiapan yang digerakkan oleh wizard untuk pengelompokan Linux
• Fleksibilitas konfigurasi, seperti menggunakan cluster penyimpanan bersama tradisional atau perangkat lunak untuk menyinkronkan penyimpanan lokal dalam konfigurasi cluster tanpa SAN

Misalnya, cluster SANless dapat menangani dua kegagalan bersamaan. Operasi dasarnya sama di LAN dan WAN, serta di cloud pribadi, publik, dan hybrid.

Dalam server cluster dua-node tipikal # 1 pada awalnya adalah yang utama yang mereplikasi data ke server #. Ini mengalami masalah, secara otomatis memicu failover ke server # 2, yang sekarang menjadi yang utama.

Dalam situasi ini, departemen TI kemungkinan akan mulai mendiagnosis dan memperbaiki masalah apa pun yang menyebabkan server # 1 gagal. Setelah diperbaiki, ini bisa mengambil alih sebagai server utama atau # 2 dapat melanjutkan dalam kapasitas mereplikasi data ke server # 1.

Dengan sebagian besar konfigurasi pengelompokan tanpa HA SAN, pengalihan terjadi secara otomatis, dan pengalihan serta pengalihan dapat dikontrol oleh konsol berbasis browser.

Untuk informasi lebih lanjut tentang solusi SIOS LifeKeeper dan Protection Suite, kunjungi SIOS SAN dan SANless High Availability Clusters untuk Cluster Server Environments.

Direproduksi dengan izin dari SIOS

Hilangkan * waktu henti server web Apache dengan SIOS AppKeeper Monitoring

Saat ini, server web Apache adalah server web paling populer di Internet.  Perusahaan menerapkan aplikasi misi penting yang menghadap pelanggan yang dibangun di atas Apache menggunakan platform cloud seperti Amazon AWS, Microsoft Azure, dan Google Cloud Platform.  Jadi, Anda dapat bertaruh bahwa mereka menginvestasikan banyak waktu dan uang untuk memantau aplikasi tersebut dan mencoba mengurangi waktu henti. Tetapi bagaimana jika kami memberi tahu Anda bahwa kami dapat menghilangkan kebutuhan akan intervensi manual melalui pemantauan otomatis dan memulai ulang aplikasi ketika server web Apache Anda mati?

Sebelum kita membahas bagaimana kita dapat melakukannya, mari kita mundur sejenak dan melihat pilihan yang dimiliki perusahaan dalam hal memantau dan mengelola server web Apache mereka dan aplikasi penting tersebut.

Cara memantau dan melindungi server web Apache Anda dari waktu henti yang tidak perlu

Siapa pun yang menerapkan aplikasi menggunakan server web Apache sedang mempertimbangkan untuk memantau kesehatan server web mereka sendiri atau mengalihkan tugas itu ke pihak ketiga.

Dalam hal memantau aplikasi cloud yang berjalan di Amazon Web Services, pilihan yang populer adalah menggunakan Amazon CloudWatch.  Beberapa perusahaan bahkan memperluas fungsionalitas CloudWatch dengan membuat beberapa tingkat otomatisasi dengan mengembangkan skrip atau dengan menggunakan AWS Lambda.  Tetapi mengonfigurasi Amazon CloudWatch dengan benar dengan metrik khusus dan menyiapkan AWS Lambda memerlukan sejumlah keahlian teknis yang mungkin melampaui banyak perusahaan.  Dan kemudian ada biaya dan upaya yang diperlukan untuk mempertahankan skrip apa pun saat aplikasi berkembang.

Pilihan lainnya adalah berinvestasi dalam solusi Application Performance Monitoring ("APM") yang komprehensif dari vendor seperti New Relics, Dynatrace, DataDog, atau LogicMonitor. Ini bisa sangat sesuai jika Anda ingin memantau lebih dari sekadar lingkungan AWS Anda. Solusi APM sangat dapat dikonfigurasi dan akan memberi Anda banyak data dalam hal informasi tentang apa yang terjadi.

Tapi apakah Anda sudah mengurangi waktu henti Anda? Mungkin tidak.  Apa yang telah Anda lakukan diinvestasikan dalam sistem yang akan segera memberi tahu Anda jika dan ketika server web Apache Anda mati, dan akan membebani Anda dengan data (atau "peringatan badai") saat Anda mencoba menjalankan kembali semuanya.

Beberapa perusahaan telah memutuskan untuk mengalihkan tanggung jawab untuk memantau dan mengelola aplikasi mereka ke pihak ketiga yang tepercaya (seringkali "penyedia layanan terkelola" atau MSP). Sebagai imbalan atas biaya bulanan dasar, MSP memantau aplikasi dan menawarkan serangkaian layanan inti, sering kali terikat oleh Perjanjian Tingkat Layanan. Saat peringatan diterima, mereka menyelidiki. Dalam beberapa kasus, penyelidikan ini dapat memerlukan eskalasi (mahal). Jika dan ketika aplikasi mati, MSP kemudian akan mengambil kendali dan memulai ulang layanan atau mem-boot ulang instans di mana mereka bisa.  Tetapi tindakan perbaikan ini seringkali menjadi biaya tambahan.

Pasti ada cara yang lebih baik.

Bagaimana pemantauan otomatis dan restart dengan SIOS AppKeeper menghilangkan waktu henti Apache Webserver

Berdasarkan pengalaman pelanggan kami, rata-rata perusahaan dengan hanya tiga instans EC2 mengalami waktu henti setidaknya sebulan sekali.  “Situsnya sedang down! Menjatuhkan semuanya. Cari tahu apa yang perlu dilakukan! ” Yang perlu Anda lakukan adalah mengurangi kebutuhan akan latihan kebakaran yang tidak perlu ini.

SIOS AppKeeper adalah layanan SaaS yang mudah dipasang dan dikonfigurasi serta memantau layanan dan aplikasi apa pun yang berjalan di Amazon EC2, seperti layanan httpd Apache Anda.  Saat anomali terdeteksi, AppKeeper otomatis memulai ulang layanan, dan jika tidak berhasil, seluruh instance akan di-boot ulang. Tidak perlu lagi membaca log untuk menunjukkan alasan kegagalan, atau eskalasi ke pengembang untuk memulai ulang layanan Anda. Atau biaya outsourcing yang mahal.  AppKeeper menyediakan fungsionalitas "set-it-and-forget-it" sehingga Anda dapat menghilangkan waktu henti.

Saat ini ratusan perusahaan mengandalkan AppKeeper untuk menjaga lingkungan cloud mereka tetap berjalan. Kami mengundang Anda untuk melihat video di bawah ini untuk mendemonstrasikan bagaimana AppKeeper melindungi server web Apache.  Dan jika Anda menyukai apa yang Anda lihat, jangan ragu untuk mendaftar uji coba gratis AppKeeper selama 14 hari.

* Berdasarkan data pelanggan, AppKeeper mengatasi 85% kegagalan layanan aplikasi. Jadi hampir sembilan dari sepuluh AppKeeper mengirimkan email yang memberi tahu pelanggan bahwa waktu henti terdeteksi dan layanan dimulai ulang atau instans di-boot ulang secara otomatis.  Bukankah itu lebih baik daripada panik dan menggali file log sebelum memulai ulang semuanya secara manual?

Lihat posting terkait: Mengapa AWS EC2 Application Monitoring Begitu Sulit?