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?

Tip untuk Memulihkan Suite Perlindungan SIOS untuk Spesifikasi Konfigurasi Linux

Kerja bagus "Rekan Kerja Acak"! Dan dengan pekerjaan bagus, yang saya maksud bukan pekerjaan bagus.  Dan yang dimaksud dengan "Rekan Kerja Acak" yang saya maksud adalah pria yang mencentang kotak yang tidak boleh dicentang, atau tidak mencentang kotak yang harus dicentang, pria atau wanita yang melewatkan pesan dan peringatan, dan tindakan pengamanan "Harap konfirmasi" dan baru saja merusak konfigurasi SIOS Protection Suite untuk Linux Anda.

Kita semua pernah ke sana.  Itu adalah sebuah kecelakaan.  Bagaimanapun itu terjadi, itu terjadi.  Tiba-tiba Anda berebut untuk mencari tahu apa yang harus dilakukan untuk memulihkan konfigurasi, data, dan "apa pun" sebelum bos mengetahuinya.

Sebagai VP Customer Experience di SIOS Technology Corp. tim kami secara aktif bekerja dengan mitra dan pelanggan untuk merancang dan mengimplementasikan ketersediaan perusahaan untuk melindungi sistem mereka dari waktu henti.  Kecelakaan terjadi, dan pengalaman pelanggan baru-baru ini mengingatkan saya bahwa meskipun dengan beberapa pemeriksaan dan peringatan kami, bahkan produk SIOS Protection Suite untuk Linux tidak kebal terhadap perubahan konfigurasi yang tidak disengaja, tetapi ada tip sederhana untuk pemulihan yang lebih cepat dari "Random Coworker's Kesalahan yang tidak disengaja.

Bagaimana Memulihkan Suite Perlindungan SIOS untuk Linux Setelah Perubahan Konfigurasi yang Tidak Disengaja 

Asli dari SIOS Protection Suite for Linux (SPS-L) adalah alat yang disebut lkbackup, terletak di bawah / opt / LifeKeeper / bin / lkbackup.  Alat, seperti namanya, membuat cadangan detail konfigurasi SPS-L.  Catatan: Alat ini tidak mencadangkan semua data aplikasi, tetapi alat ini membuat cadangan semua data untuk konfigurasi SPS-L seperti: definisi sumber daya, merdu yang dikonfigurasi dalam file / etc / default / LifeKeeper, generik yang dibuat pelanggan skrip aplikasi, tanda yang terkait dengan status cluster, jalur komunikasi / definisi cluster, dan banyak lagi.

[root@baymax ~ ] # / opt / LifeKeeper / bin / lkbackup -c -f /root/mylkbackup-5.15.2020-v9.4.1 –cluster –ssh

Contoh: lkbackup create syntax

Ini membuat file cadangan bernama mylkbackup-5.15.2020-v9.4.1 di bawah folder / root.  The –cluster memberitahu lkbackup untuk membuat file yang sama pada setiap node cluster.  –Ssh menggunakan protokol ssh untuk terhubung ke setiap node cluster.  Detail lkbackup tambahan ada di sini:

Tim Layanan Pengalaman Pelanggan kami merekomendasikan untuk membuat cadangan sebelum membuat perubahan konfigurasi SPS-L, seperti peningkatan, penghapusan atau penambahan sumber daya, atau perubahan konfigurasi.

Jadi, saat Anda perlu memulihkan konfigurasi SPS-L, perubahannya semudah menjalankan lkbackup lagi.

[root@baymax ~ ] # / opt / LifeKeeper / bin / lkbackup -x -f /root/mylkbackup-5.15.2020-v9.4.1 –cluster –ssh

Contoh: sintaks pemulihan lkbackup

Fitur Autobackup Secara Otomatis Mengambil File lkbackup 

Tetapi, apa yang Anda lakukan jika Anda lupa menjalankan lkbackup untuk membuat file ini sebelum "Random Coworker" Anda melakukan kesalahan dalam beberapa jam pengaturan dan konfigurasi SPS-L? Apa yang Anda lakukan jika "Guy" atau "Gal" yang menyiapkan SPS-L sedang berlibur, cuti hamil atau melahirkan? Bagaimana jika Anda adalah "Rekan Kerja Acak" dan Steve dari Tim Basis sedang menuju ke lorong untuk melihat bagaimana keadaannya? Untuk sebagian besar penginstalan, SIOS mengaktifkan fitur cadangan otomatis selama penginstalan.  Fitur autobackup ini akan secara otomatis mengambil file lkbackup untuk Anda pada pukul 3 pagi waktu setempat, di bawah /opt/LifeKeeper/config/auto-backup.#.tgz

[root@baymax ~]# ls -ltr /opt/LifeKeeper/config/auto-backup.*

• -rw-r – r–. 1 root root 31312 6 Mei 03:00 /opt/LifeKeeper/config/auto-backup.3.tgz
• -rw-r – r–. 1 root root 31310 7 Mei 03:00 /opt/LifeKeeper/config/auto-backup.4.tgz
  -rw-r – r–. 1 root root 31284 8 Mei 03:00 /opt/LifeKeeper/config/auto-backup.5.tgz
  -rw-r – r–. 1 root root 31290 9 Mei 03:00 /opt/LifeKeeper/config/auto-backup.6.tgz
  -rw-r – r–. 1 root root 31291 10 Mei 03:00 /opt/LifeKeeper/config/auto-backup.7.tgz
  -rw-r – r–. 1 root root 31295 11 Mei 03:00 /opt/LifeKeeper/config/auto-backup.8.tgz
  -rw-r – r–. 1 root root 31280 12 Mei 03:00 /opt/LifeKeeper/config/auto-backup.9.tgz
  -rw-r – r–. 1 root root 31333 13 Mei 03:00 /opt/LifeKeeper/config/auto-backup.0.tgz
  -rw-r – r–. 1 root root 31325 14 Mei 03:00 /opt/LifeKeeper/config/auto-backup.1.tgz
  -rw-r – r–. 1 root root 31359 15 Mei 03:00 /opt/LifeKeeper/config/auto-backup.2.tgz

Contoh. Keluaran dari daftar config / auto-backup

Jika sistem Anda telah diinstal dan dikonfigurasi dengan benar, pencadangan otomatis telah berjalan setiap malam, siap untuk melindungi Anda saat "Rekan Kerja Acak" Anda menyerang. Temukan SPS-L auto-backup. # .Tgz sebelum kesalahan, dan menggunakan alat lkbackup SPS-L, ambil dan pulihkan SIOS Protection Suite untuk Konfigurasi Linux ke keadaan yang dikonfigurasi sebelumnya.

[root@baymax ~ ] # lkstop; / opt / LifeKeeper / bin / lkbackup -c -f /opt/LifeKeeper/config/auto-backup.0.tgz

Contoh: lkbackup restore syntax untuk auto-backup

Ulangi ini di node lain di cluster sesuai kebutuhan.

Catatan.  Jika sistem Anda tampaknya tidak dikonfigurasi untuk menghasilkan file cadangan otomatis dan melindungi Anda dari "Rekan Kerja Acak" Anda sendiri, SIOS menawarkan layanan penginstalan dan konfigurasi, dan pemeriksaan kesehatan konfigurasi yang dilakukan oleh Insinyur Layanan Profesional SIOS.

– Cassius Rhue, VP, Pengalaman Pelanggan