Anda memerlukan SIOS Protection Suite (untuk Linux atau Windows) atau SIOS DataKeeper Cluster Edition untuk perlindungan ketersediaan tinggi untuk aplikasi bisnis penting.

KECUALI KALAU

1. Anda lebih suka solusi gratis saja.

Saya mengerti. Ada kalanya saya melakukan hal yang sama ketika saya perlu mempelajari keterampilan baru, mendapatkan tip cepat, menurunkan berat badan, atau menyiapkan demo singkat. Daripada mendaftar untuk berlangganan, membeli lisensi, atau berinvestasi dalam kombinasi keduanya, saya memilih rute gratis.

Namun, pepatah sering kali benar, Anda mendapatkan apa yang Anda bayar. Uji coba gratis baik-baik saja. Ketersediaan tinggi gratis secara permanen seperti sushi pom bensin – apakah risikonya benar-benar sepadan? Pastikan gratis tidak menghalangi Anda untuk memanfaatkan kelengkapan yang tersedia untuk mengoptimalkan waktu kerja dan meningkatkan ketersediaan. Pastikan Anda tidak melewatkan solusi ketersediaan tinggi dengan harga wajar yang terbukti melindungi aplikasi penting Anda.

2. Menjadi solusi toko solusi tunggal lebih penting daripada memenuhi kebutuhan HA Anda.

Kami adalah keluarga "Ford tangguh" selama beberapa dekade. Sungguh. Saya mengerti bagaimana rasanya menjadi toko satu solusi. Ayah saya memiliki truk Ford untuk bekerja, Ford Mustang untuk bersantai, traktor Ford 3600 untuk pertanian, dan minivan Ford untuk perjalanan keluarga. Bahkan ada musim dimana kami mendapat model mobil mainan dengan oval biru bermerek juga.

Namun, ketika istri saya dan saya mengembangkan kebutuhan keluarga kami sendiri, kami memisahkan diri dari solusi tunggal untuk memenuhi kebutuhan yang tidak dapat dilakukan oleh ruang kemudi Ford (pada saat itu). Anda mungkin merupakan pembeli toko tunggal, tetapi jika kebutuhan Anda telah berubah dan penyedia atau solusi HA belum memenuhi, pertimbangkan apakah memperluas rangkaian solusi akan menghilangkan risiko, meningkatkan kesuksesan, atau bernilai investasi dalam solusi pelengkap bagi mereka. kebutuhan baru. Ketika kami membutuhkan solusi yang andal, hemat bahan bakar, ramping, ramah keluarga, dan ekonomis untuk keluarga kami, kami melengkapi Ford tangguh dengan Honda Odyssey. Jika Anda adalah toko serba ada, dan Anda tidak khawatir tentang keberuntungan vendor lock-in.

3. Anda lebih suka melakukannya sendiri-er pembuat kode.

Anda suka coding. Anda suka menulis banyak skrip, dan tidak keberatan mengeluarkan bash, ksh, perl, python, PowerShell, batch atau command tool kit dan memasang kabel sendiri. Anda menghargai kegembiraan dalam fleksibilitas dan menambahkan perubahan Anda sendiri.

Saya suka menulis kode juga, tetapi ada kalanya hal terakhir yang ingin saya lakukan adalah menghabiskan waktu menulis banyak kode dan skrip untuk masalah yang diselesaikan, terbukti, dan siap. Untuk admin do-it-yourself, off-the-shelf mungkin bukan preferensi Anda, tetapi pertimbangkan apakah 20 tahun keahlian dan pengalaman harus diulang dan dirancang ulang untuk perusahaan Anda. Tetapi, jika Anda harus mendapatkan perbaikan penulisan kode, SIOS Perangkat Lunak Ketersediaan Tinggi menyediakan Kit Pemulihan Aplikasi Generik bagi Anda untuk mendapatkan perbaikan pengkodean.

4. Anda membutuhkan dukungan Ubuntu (atau Solaris).

Lingkungan Anda unik. Anda memiliki pelanggan yang telah memotong gigi mereka di Solaris dan mempertahankannya seumur hidup. Atau Anda memiliki mereka yang telah sepenuhnya merangkul ranah Linux dan telah pindah ke Ubuntu. Dalam kedua kasus tersebut, Anda melihat matriks produk SIOS dan Ubuntu saat ini tidak cocok untuk versi SIOS Anda. Kekecewaan!

Meskipun ini benar, pertimbangkan fitur dan rasa dukungan yang kaya dan luas yang masih tersedia. Meskipun ada bagian dari perusahaan Anda yang telah menggali Solaris dan lainnya yang telah berpacu untuk menggunakan Ubuntu dan varian Linux yang lebih baru, kemungkinan besar Anda memerlukan solusi yang mampu mendukung RHEL, OEL, SuSE, CentOS dan mungkin Windows sebagai baik. Pastikan untuk tidak memilih solusi ketersediaan tinggi berdasarkan apa yang tidak disediakannya dan pertimbangkan kedalaman dari apa yang dilakukannya.

5. Anda tidak menjalankan campuran apa pun di lingkungan Anda.

Saya mendengarnya di tengah-tengah film minggu lalu. Karakter utama mengomentari gagasan untuk maju dengan beberapa gagasan baru dari pemilik yang terlalu bersemangat. Kalimat klasik: "Terkadang jus tidak sebanding dengan perasannya." Dalam pikiran Anda, Anda merasa bahwa Anda tidak menjalankan lingkungan hybrid. Aplikasi Anda sangat penting, tetapi tidak rumit. Bagian yang bergerak itu sederhana- database, front end dan aplikasi pendukung. Masuk akal jika Anda tidak ingin "memperumit" hal-hal dengan proses, produk, solusi, atau layanan tambahan, dan Anda mungkin merasa jus tersebut tidak sepadan dengan perasannya.

Sebelum Anda membuat keputusan akhir untuk Perangkat Lunak Ketersediaan Tinggi, nilai apakah lingkungan non-hibrida sama dengan lingkungan sederhana. Pertimbangkan apakah bagian yang bergerak sesederhana yang Anda bayangkan atau apakah solusi dengan orkestrasi failover akan bermanfaat untuk mengurangi RTO Anda secara keseluruhan dan meningkatkan RPO Anda.

6. Dukungan dari pakar dan pengalaman HA tidak penting.

Saya membeli satu set headphone secara online pada pertengahan April. Seperti yang saya duga, saya menemukan bahwa siapa pun dapat menggunakan headphone bluetooth. Tapi, tidak semua orang bisa melakukannya dengan baik. Secara ergonomis, headphone "baru ke pasar" adalah mimpi buruk. Memasangkan sangat mudah, tetapi pelepasan pasangan yang tidak disengaja adalah pertempuran yang konstan. Kualitas suaranya luar biasa, tetapi itu memperkuat kekesalan saya ketika headphone berkicau secara acak – dengan keras dan jelas – untuk suara sistem atau di akhir lagu.

Anda mungkin percaya bahwa ketersediaan tinggi dan pemantauan aplikasi dapat dilakukan oleh siapa saja dan pengalaman itu tidak masalah. Namun, pertimbangkan pengalaman Anda sendiri dan milik saya dan tanyakan apakah Anda benar-benar ingin mempercayai lingkungan perusahaan Anda kepada grup yang baru mulai memikirkan tentang kompleksitas lingkungan hybrid, atau dependensi dan pengetahuan yang berpusat pada aplikasi yang diperlukan untuk aplikasi yang paling sering Anda gunakan. sering.

Saat memutuskan Perangkat Lunak Ketersediaan Tinggi yang tepat untuk lingkungan Anda, pertimbangkan baik-baik apakah Anda ingin menggunakan banyak fitur terbaik di kelasnya, solusi yang diperkuat dan teruji, ahli yang berpengetahuan, banyak aplikasi dan lingkungan yang didukung, serta pengalaman industri terkemuka dan wawasan puluhan tahun . Kemudian setelah mempertimbangkan dengan cermat, pilihlah dengan bijak.

-Cassius Rhue, Wakil Presiden, Pengalaman Pelanggan, SIOS

Mengurangi waktu henti untuk situs WordPress yang dihosting di Amazon EC2

Beranjak dari ketidaktahuan menuju kebahagiaan dengan SIOS AppKeeper

WordPress adalah sistem manajemen konten (CMS) sumber terbuka yang digunakan oleh jutaan perusahaan untuk membuat situs web, blog, atau aplikasi.Menurut perkiraan, saat ini ada lebih dari 75 juta situs web yang menggunakan WordPress dan banyak perusahaan mulai menghosting instans WordPress mereka di Amazon EC2. Pengguna menyukai WordPress karena fleksibilitas dan kemudahannya dalam membuat dan memodifikasi tata letak.Jika Anda menggunakan WordPress untuk situs web Anda, maka Anda berada di perusahaan yang baik.

Dengan begitu banyak pengguna yang mengandalkan WordPress untuk memberdayakan situs web mereka, Anda dapat membayangkan bahwa ada seperangkat alat pihak ketiga (plugin dan layanan) yang dirancang untuk memenuhi kebutuhan pengguna tersebut.Beberapa plugin ini untuk menambahkan fungsionalitas keamanan, seperti pemindai untuk menyelidiki kerentanan.Karena lebih banyak plugin dapat menyebabkan lebih banyak kerentanan.

Percaya, tapi verifikasi.Mengapa memantau uptime WordPress itu penting.

Menerapkan situs web atau aplikasi yang berjalan di WordPress tanpa memantaunya dengan benar akan seperti membiarkan mobil Anda berjalan di luar dengan kunci di dalamnya.Anda pasti ingin melindungi investasi Anda.Untuk perusahaan yang mengelola situs WordPress (atau aplikasi apa pun, dalam hal ini), ada tiga alasan utama untuk memantau:

1. Untuk memahami pengunjung dan mengoptimalkan pengalaman mereka;
2. Untuk memantau kecepatan situs dan memastikannya memenuhi perjanjian tingkat layanan (SLA) yang diharapkan; dan
3. Untuk memastikan bahwa Anda memaksimalkan waktu kerja.Waktu henti dapat berarti kehilangan pendapatan (serius) untuk situs e-niaga apa pun yang berjalan di WordPress.

Anda yakin situs WordPress Anda berfungsi dengan baik, tetapi Anda benar-benar ingin tahu apa yang sedang terjadi.Tujuan pemantauan harus mengetahui dengan cepat apa yang sedang terjadi dan mengapa, memungkinkan Anda untuk merespons masalah apa pun dengan cepat.

Ada berbagai macam alat yang tersedia untuk membantu pengguna WordPress memantau situs mereka.Beberapa sangat fokus pada WordPress, seperti ManageWP dan JetPack, sementara yang lain adalah solusi standar industri yang berlaku untuk banyak CMS dan aplikasi yang berbeda.Beberapa masuk "lebih dalam" dan berfokus pada satu elemen pemantauan, seperti Google Analytics dan fokusnya pada analisis pengunjung, sementara yang lain mencoba untuk "lebih luas" dan menangani ketiga aspek utama pemantauan.Apa yang Anda putuskan untuk digunakan bergantung pada anggaran Anda, persyaratan Anda, dan kemampuan teknis Anda.

Di sini, di SIOS, kami percaya bahwa pendekatan breed terbaik masuk akal.Kami fokus pada pemantauan aplikasi dan memastikan bahwa pelanggan kami mengalami waktu henti sesedikit mungkin dengan aplikasi tersebut.Banyak pelanggan kami saat ini menggunakan SIOS AppKeeper untuk memantau dan melindungi situs WordPress mereka yang berjalan di Amazon EC2.

SIOS AppKeeper – pemantauan sederhana namun kuat dan remediasi otomatis untuk situs WordPress

Banyak solusi pemantauan WordPress (dari plugin gratis hingga layanan freemium berbiaya rendah) akan memberi tahu Anda saat situs WordPress Anda tidak aktif.Dan tergantung pada kecanggihan (dan biaya) solusi pemantauan Anda, ini mungkin memberi tahu Anda mengapa situs WordPress Anda turun.Tetapi apakah ini akan membantu Anda mengurangi waktu henti dan secara otomatis memulai ulang layanan Anda atau mem-boot ulang instans Anda saat waktu henti dialami?

Banyak perusahaan menghosting situs WordPress mereka di Amazon EC2 menggunakan server web Apache atau NGINX.SIOS AppKeeper adalah layanan SaaS yang dapat dikonfigurasi untuk secara otomatis menemukan situs atau aplikasi WordPress yang berjalan pada instans Amazon EC2 dan layanannya, lalu secara otomatis melakukan sejumlah tindakan jika dan ketika waktu henti dialami.Jadi, alih-alih hanya mendapatkan peringatan bahwa ada sesuatu yang salah, Anda akan diberi tahu bahwa sesuatu telah terjadi dan secara otomatis ditangani.

Waktu henti penting.Jika Anda menjalankan situs e-commerce menggunakan WordPress, maka downtime akan mengakibatkan hilangnya pendapatan.Berapa pendapatan?Cukup bagi pendapatan tahunan Anda dengan 365 hari dan 24 jam (Pendapatan tahunan / 365/24) untuk memahami pendapatan Anda per jam.Pada tahun 2013, Google mengalami pemadaman selama 5 menit yang menyebabkan mereka kehilangan pendapatan sebesar $ 545.000. Sekarang, Anda mungkin bukan Google, tetapi Anda pasti ingin menghilangkan downtime sedapat mungkin.

Sekarang bayangkan apa yang terjadi ketika Anda menerima peringatan bahwa situs WordPress Anda sedang down.Apakah Anda siap untuk segera menanggapi?Tahukah Anda apa yang harus ditujukan agar situs WordPress Anda aktif dan berjalan?Menurut penelitian pelanggan kami, rata-rata pelanggan yang hanya menggunakan tiga instans Amazon EC2 mengalami waktu henti setidaknya sebulan sekali.

SIOS AppKeeper memantau Amazon EC2 dan memperingatkan Anda jika ada waktu henti DAN mengambil tindakan untuk memulihkan situasi, baik dengan memulai ulang layanan Amazon EC2 atau me-reboot instans Anda.

AppKeeper menangani lebih dari 85% masalah waktu henti Amazon EC2 pelanggan kami secara otomatis.Ini berarti Anda akan diberi tahu bahwa kegagalan telah diidentifikasi dan diatasi, tanpa Anda harus meninggalkan semuanya atau kehilangan pendapatan yang signifikan.

Saat ini ratusan perusahaan mengandalkan AppKeeper untuk menjaga lingkungan cloud mereka tetap berjalan. Kami mengundang Anda untuk melihat video di bawah ini untuk melihat betapa mudahnya menginstal dan menggunakan AppKeeper.

Video: Menginstal AppKeeper dan memulihkan dari Demo kegagalan AWS EC2

Dan jika Anda menyukai apa yang Anda lihat, jangan ragu untuk mendaftar uji coba gratis AppKeeper selama 14 hari. AppKeeper mulai hanya dengan US $ 40 per instance per bulan.

Bermigrasi ke cloud? Berikut ini bagaimana prioritas DevOps Anda harus berubah saat Anda pindah ke Amazon EC2

Mayoritas perusahaan yang bermigrasi ke cloud, atau membuat aplikasi "cloud-native", melakukannya dengan Amazon Web Services (AWS).AWS menawarkan banyak keuntungan biaya dan fungsionalitas.Perusahaan yang telah mengadopsi praktik terbaik operasi pengembang standar industri ("DevOps") untuk memantau dan mengelola lingkungan di lokasi mereka sering kali bertanya pada diri sendiri bagaimana mereka beradaptasi dengan lingkungan dan aplikasi cloud baru mereka.

Bagaimana prioritas DevOps akan berubah saat Anda beralih dari aplikasi lokal ke Amazon EC2?Berikut penjelasan tentang perbedaan antara keduanya dan hal yang harus Anda ingat.

Prioritas DevOps di cloud?Sama. Tapi berbeda.

Kami sering mendengar pelanggan mengatakan bahwa pengoperasian akan lebih mudah ketika mereka pindah ke AWS. Kami memperingatkan mereka bahwa pindah ke cloud (atau bahkan AWS) tidak berarti bahwa mereka tidak lagi perlu memantau dan mengelola aplikasi mereka.

Perusahaan yang pindah ke Amazon AWS dapat memanfaatkan biaya yang lebih rendah dan sumber daya tenaga kerja dalam hal pengadaan, penyediaan, dan pemeliharaan perangkat keras.Tetapi Anda perlu mempertimbangkan bahwa ketika Anda memutuskan untuk menghosting aplikasi di Amazon EC2, apa pun yang berada di atas lapisan Sistem Operasi adalah tanggung jawab Anda.

Dalam hal cadangan / jaminan ketersediaan / langkah keamanan, dll. Untuk lingkungan Amazon EC2 Anda, prioritasnya sama seperti jika mereka adalah aplikasi di lokasi. Dan Amazon menyediakan beberapa alat dan fungsionalitas asli.Tetapi Anda perlu memutuskan apakah mereka cocok untuk persyaratan.

Keamanan, Cadangan… Apa yang perlu Anda ketahui saat mengelola lingkungan Amazon AWS?

Jadi, apa saja pertimbangan khusus AWS yang perlu Anda ingat saat pindah ke Amazon EC2?Dan alat apa yang tepat untuk Anda?Waktu yang Anda investasikan di muka dalam mendesain aplikasi Anda dan bagaimana Anda akan menerapkan dan mengelolanya akan terbayar.

Pertimbangan pertama Anda adalah bagaimana Anda akan mengamankan aplikasi Amazon EC2 Anda.Desain jaringan, seperti "port mana yang harus dibuka" dan "dari mana mengizinkan akses" harus dipertimbangkan dengan cara yang sama seperti untuk aplikasi di lokasi Anda.Ini dapat dikonfigurasi di AWS menggunakan grup keamanan dan ACL jaringan (daftar kontrol akses).

Anda dapat menggunakan fungsionalitas AWS Trusted Advisor *, yang secara otomatis memeriksa lingkungan AWS Anda dan menunjukkan apakah telah disetel ke pengaturan yang disarankan atau tidak, sehingga memungkinkan untuk memeriksa lingkungan AWS perusahaan Anda untuk masalah keamanan.Kami merekomendasikan untuk memeriksa dengan AWS Trusted Advisor baik pada saat penerapan maupun secara berkala.

Aspek penting lainnya dari keamanan adalah pengelolaan otentikasi dan hak akses.AWS menggabungkan semua ini ke dalam AWS Identity and Access Management (AWS IAM).Selain untuk mengontrol siapa yang dapat mengakses instans EC2, Anda juga dapat menggunakan AWS IAM untuk mengatur izin akses dari instans EC2 ke sumber daya lain (seperti DB), dll. Setelah Anda bermigrasi ke AWS, hal pertama yang perlu Anda lakukan adalah mengatur akun dan pembatasan akses dengan benar di AWS IAM.

Pertimbangan berikutnya adalah "bagaimana cara mencadangkan aplikasi saya di Amazon EC2?" Amazon EC2 menyediakan kemampuan untuk mengambil snapshot, yang memungkinkan Anda melakukannya.Selain itu, menggunakan "Amazon Data Lifecycle Manager" mempermudah penyiapan snapshot berkala, serta pencadangan tambahan.File snapshot disimpan di layanan penyimpanan Amazon S3.Anda dikenai biaya sesuai dengan kapasitasnya, jadi Anda perlu mengetahui jumlah data yang Anda miliki dan menyiapkan setelan seperti "kurangi kapasitas dengan incremental backup" dan "hapus dari data lama".

“Ketersediaan” perlu dipertimbangkan sebelumnya. Kuncinya adalah mengoperasikan sistem sesuai dengan tingkat prioritas sistem.

Pertimbangan terakhir adalah ketersediaan.Dengan aplikasi Amazon EC2, serta aplikasi yang ada di lokasi, Anda harus mempertimbangkan tingkat ketersediaan yang diperlukan berdasarkan biaya dan kepentingan sistem. Namun, jika Anda menggunakan fungsionalitas penerapan Multi-AZ Amazon, Anda dapat menentukan konfigurasi redundan antara pusat data yang berbeda.Namun, menggunakan Multi-AZ lebih mahal daripada menggunakan konfigurasi AZ tunggal (meskipun tidak sebanyak jika Anda memiliki sistem di lokasi yang redundan).Saat merancang aplikasi Anda, Anda perlu mempertimbangkan apakah Multi-AZ diperlukan dan berapa banyak Anda harus berinvestasi dalam ketersediaan.

Jika Anda tidak berinvestasi dalam failover, maka Anda setidaknya harus memantau aplikasi Anda dan merencanakan cara memulihkannya saat downtime dialami. Anda dapat menggunakan Amazon CloudWatch untuk dengan mudah memantau item umum seperti CPU, memori, dan disk, dan Anda juga dapat memprogram fungsi Amazon EC2 Auto Recovery untuk secara otomatis memulihkan instans saat terjadi kesalahan di EC2.

Jika aplikasi Anda memiliki misi penting, Anda akan ingin berinvestasi lebih banyak dalam ketersediaannya.Anda harus mempertimbangkan banyak solusi pihak ketiga yang sangat baik yang menawarkan fungsionalitas berharga bagi komunitas AWS.Salah satu pilihannya adalah SIOS AppKeeper, solusi yang mudah untuk dikonfigurasi dan digunakan yang memantau instans Amazon EC2 Anda dan secara otomatis memulai ulang layanan atau melakukan boot ulang instans jika mengalami kegagalan sistem.Berikut video singkat tentang cara kerja AppKeeper

Meskipun berpindah ke cloud untuk aplikasi Anda sangat masuk akal, Anda tidak dapat meninggalkan praktik terbaik DevOps.Amazon AWS memberi Anda sekumpulan fungsionalitas dan alat yang kaya, tetapi Anda masih harus mengambil tanggung jawab utama atas keamanan, cadangan, dan ketersediaan aplikasi Anda.Bagaimana Anda melakukan ini tergantung pada keahlian Anda dan pentingnya aplikasi itu sendiri.

Kami mengundang Anda untuk bergabung dengan ratusan pelanggan yang telah memanfaatkan AppKeeper untuk mengurangi waktu henti Amazon EC2 mereka dengan mendaftar untuk uji coba layanan gratis selama 14 hari.

* Catatan: Untuk menggunakan AWS Trusted Advisor, diperlukan kontrak untuk dukungan bisnis atau yang lebih tinggi.

Direproduksi dengan izin dari SIOS

Perluas Metrik Ketersediaan Tinggi Anda

Di bidang teknologi, kami menyukai data. Kami menyukai data tentang data dan semua metrik serta ukuran yang dapat dihasilkan oleh alat kami. Kami telah menciptakan industri seputar analytics, produk yang menangkap setiap detail dari ribuan perangkat yang terhubung. Kami menyukai metrik dan ukuran. Dalam banyak kasus dalam ruang ketersediaan yang lebih tinggi, kami menyukai metrik ketersediaan tinggi yang memberi tahu kami seberapa cepat sistem pulih dari kegagalan. Kami menghitung dan melacak waktu antara deteksi dan perbaikan, dan kami terobsesi untuk mengetahui dan mengukur berapa banyak data transaksional yang akan hilang dalam bencana, kegagalan sistem, atau kerusakan disk.

Ironisnya, dalam sistem ketersediaan tinggi dan pemulihan bencana (HA / DR), ada beberapa metrik yang kurang mendapat perhatian.

Berikut delapan metrik ketersediaan tinggi lainnya yang harus Anda perhatikan untuk mengelola lingkungan Anda:

1.  Peringatan keamanan

Ketersediaan bukan hanya tentang pemantauan dan pemulihan aplikasi.  Sistem yang tersedia untuk umum selalu diserang.  Jika Anda tidak memantau lansiran dan peringatan keamanan, aplikasi Anda mungkin berjalan dengan sempurna, sementara kekayaan intelektual Anda disalurkan dengan sempurna ke luar pintu.

2. Koneksi menganggur

Koneksi yang menganggur terdengar tidak berbahaya, tetapi sama tidak berbahayanya dengan kudzu berdaun hijau di halaman selatan.  Koneksi idle membutuhkan sumber daya dan mengancam untuk mengisi kumpulan database, jaringan yang padat, dan kinerja yang melumpuhkan.  Lebih lanjut, koneksi idle dapat menunjukkan masalah pada lapisan aplikasi atau konfigurasi database.

3. Kueri, perintah, atau pekerjaan yang berjalan lama

Ini berlaku tidak hanya untuk kueri atau pekerjaan database, tetapi juga untuk perintah dan cadangan.  Kueri, perintah, dan pekerjaan yang berjalan lama dapat menjadi indikator kesehatan sistem yang buruk, kecepatan disk yang lambat, CPU atau sumber daya lain yang berselisih, atau masalah sistematis, kompatibilitas aplikasi atau OS yang lebih dalam.

4. Disk IO

Disk IO biasanya mengacu pada operasi input / output dari sistem yang terkait dengan aktivitas disk. Mengukur I / O disk dapat membantu mengidentifikasi kemacetan, konfigurasi perangkat keras yang buruk, ukuran disk yang tidak tepat, atau tata letak disk yang tidak disetel dengan baik untuk beban kerja tertentu.  Pemantauan disk I / O dapat membantu memberi tahu Anda jika kueri yang berjalan lama adalah fungsi dari sintaks sql yang buruk, aplikasi dengan kode yang buruk, atau masalah latensi dan akses.

5. Penyimpanan

Kita semua berpikir tentang berapa banyak memori yang digunakan, tetapi pemantauan memori lebih dari sekadar mengukur dan melihat yang gratis versus yang digunakan.  Memori pemantauan membantu Anda melihat kemacetan, kebocoran, mengidentifikasi sistem dengan ukuran yang tidak tepat, memahami beban, rata-rata beban, dan lonjakan.  Selain itu, mengetahui tentang pola intensif memori dapat membantu Anda menyesuaikan rangkaian ketersediaan untuk menghindari kegagalan palsu.

6. Ruang Disk

Sebagai Wakil Presiden Pengalaman Pelanggan, saya pernah mengalami pengalaman malang bangun pagi-pagi untuk panggilan darurat.  Pelanggan menghadapi sistem produksi yang turun setelah pemadaman listrik.  Ketika mereka mencoba untuk me-restart sistem mereka, aplikasi mereka yang dilindungi gagal untuk memulai.  Setelah pemeriksaan cepat dari log kesalahan, jelas terlihat bahwa drive root 100% penuh.  Aplikasi tidak dapat menulis ke sistem file mana pun.  Pemantauan ruang disk tersedia dalam berbagai bentuk dan cara dan menjadikannya sebagai metrik dapat mencegah masalah yang tidak perlu dan pengacakan menit-menit terakhir yang mahal untuk menambah lebih banyak masalah. .

7. Kesalahan dan peringatan

Kesalahan, peringatan, dan pesan pemulihan di log adalah metrik bagus lainnya untuk dipertimbangkan.  Solusi ketersediaan Anda mungkin membuat klien Anda tetap online dan senang, tetapi mungkin juga menutupi masalah yang memerlukan perhatian Anda segera.  Menambahkan pemantauan log untuk FATAL, PANIC, dan pesan ERROR kunci dapat membantu Anda mengidentifikasi masalah yang sering dipulihkan oleh solusi ketersediaan Anda, seperti database crash, kepanikan aplikasi atau core dump, atau kesalahan fatal yang memerlukan restart dingin.

8. Nomor pemulihan

Mirip dengan peringatan dan kesalahan pemantauan, nomor pemulihan dapat memberi tahu Anda banyak hal tentang kesehatan ketersediaan sistem Anda.  Jika Anda rata-rata melakukan lebih dari satu pemulihan aplikasi per minggu, kemungkinan Anda mengalami sesuatu yang lebih dari perlindungan ketersediaan normal.  Dan meskipun pemulihan berhasil dalam memulai ulang aplikasi atau sistem Anda, terlalu banyak dari pemulihan palsu atau bahkan sebenarnya tidak sehat.

Daftar metrik HA / DR yang dapat kami pantau dan alat untuk memantau mereka berkembang pesat.  Pastikan Anda dan tim Anda mempertimbangkan untuk memperluas pengambilan dan analisis data Anda saat ini untuk menyertakan data yang menghasilkan sistem ketersediaan terbaik yang lebih tinggi.

– Cassius Rhue, VP, Pengalaman Pelanggan