SIOS SANless clusters

SIOS SANless clusters High-availability Machine Learning monitoring

Februari 14, 2021

Tentang Menggunakan Amazon FSX untuk Instans Cluster Failover SQL Server

Tentang Menggunakan Amazon FSX untuk Instans Cluster Failover SQL Server

Menggunakan Amazon FSX untuk Instans Cluster Failover SQL Server – Yang Perlu Anda Ketahui!

Jika Anda sedang mempertimbangkan untuk menerapkan instans Microsoft SQL Server Anda sendiri di AWS EC2, Anda harus mengambil beberapa keputusan terkait ketahanan solusi. Tentu, AWS akan menawarkan 99,99% SLA pada sumber daya Compute Anda jika Anda menerapkan dua atau lebih instans di zona ketersediaan yang berbeda. Namun jangan tertipu, ada banyak faktor lain yang perlu Anda pertimbangkan saat menghitung ketersediaan aplikasi Anda yang sebenarnya. Baru-baru ini saya membuat blog tentang cara menghitung ketersediaan aplikasi Anda di cloud. Anda mungkin harus membaca artikel itu dengan cepat sebelum melanjutkan.

Ketika datang untuk memastikan instans Microsoft SQL Server Anda sangat tersedia, itu benar-benar tergantung pada dua pilihan dasar: Always On Availability Group (AG) atau SQL Server Failover Cluster Instance (FCI). Jika Anda membaca artikel ini, saya berasumsi bahwa Anda sangat memahami kedua opsi ini dan secara serius mempertimbangkan untuk menggunakan Instans Cluster Failover SQL Server, bukan SQL Server Always On AG.

Manfaat Instans Cluster Failover Microsoft SQL Server

Daftar berikut meringkas apa yang dikatakan AWS sebagai manfaat dari SQL Server FCI:

FCI umumnya lebih disukai daripada AG untuk penerapan ketersediaan tinggi SQL Server ketika berikut ini adalah masalah prioritas untuk kasus penggunaan Anda:

Efisiensi biaya lisensi: Anda memerlukan lisensi Edisi Perusahaan dari SQL Server untuk menjalankan AG, sedangkan Anda hanya memerlukan lisensi Edisi Standar untuk menjalankan FCI. Ini biasanya 50–60% lebih murah daripada Edisi Perusahaan. Meskipun Anda dapat menjalankan AG versi Dasar pada Edisi Standar mulai dari SQL Server 2016, versi ini memiliki batasan untuk hanya mendukung satu database per AG. Ini bisa menjadi tantangan saat berhadapan dengan aplikasi yang membutuhkan banyak database seperti SharePoint.

Perlindungan tingkat instance versus perlindungan tingkat database: Dengan FCI, seluruh instance dilindungi – jika node utama tidak tersedia, seluruh instance akan dipindahkan ke node standby. Ini menangani login SQL Server, pekerjaan Agen Server SQL, sertifikat, dll. Yang disimpan di database sistem, yang secara fisik disimpan di penyimpanan bersama. Sebaliknya, dengan AG, hanya database dalam grup yang dilindungi, dan database sistem tidak dapat ditambahkan ke AG – hanya database pengguna yang diizinkan. Ini adalah tanggung jawab administrator database untuk mereplikasi perubahan ke objek sistem pada semua replika AG. Ini menyisakan kemungkinan kesalahan manusia yang menyebabkan database menjadi tidak dapat diakses oleh aplikasi.

Dukungan fitur DTC: Jika Anda menggunakan SQL Server 2012 atau 2014, dan aplikasi Anda menggunakan Distributed Transaction Coordinator (DTC), Anda tidak dapat menggunakan AG karena tidak didukung. Gunakan FCI dalam situasi ini.

https://aws.amazon.com/blogs/storage/simplify-your-microsoft-sql-server-high-availability-deployments-using-amazon-fsx-for-windows-file-server/

Tantangan Dengan FCI In The Cloud

Tentu saja. Tantangan dalam membangun FCI yang mencakup zona ketersediaan adalah kurangnya perangkat penyimpanan bersama yang biasanya diperlukan. Karena node cluster didistribusikan di beberapa pusat data, SAN tradisional bukanlah pilihan yang layak untuk penyimpanan bersama. Itu membuat kami memiliki dua pilihan untuk penyimpanan klaster: sumber daya kelas penyimpanan pihak ketiga seperti SIOS DataKeeper atau Amazon FSx baru.

Mari kita lihat apa yang perlu Anda ketahui sebelum Anda membuat pilihan.

PERSETUJUAN TINGKAT LAYANAN

Seperti yang saya tulis di cara menghitung ketersediaan aplikasi Anda, SLA aplikasi Anda secara keseluruhan hanya sebagus tautan terlemah Anda. Dalam hal ini, FSx SLA 99,9%.

Biasanya 99,99% ketersediaan mewakili titik awal dari apa yang dianggap "sangat tersedia". Inilah yang dijanjikan AWS untuk sumber daya komputasi Anda ketika dua atau lebih disebarkan di zona ketersediaan yang berbeda.

Jika Anda tidak tahu perbedaan antara tiga sembilan dan empat sembilan…

  • Ketersediaan 99,9% memungkinkan waktu henti 43,83 menit per bulan
  • Ketersediaan 99,99% hanya memungkinkan waktu henti 4,38 menit per bulan

Dengan menghosting penyimpanan cluster Anda di FSx terlepas dari 99,99% ketersediaan komputasi Anda, ketersediaan aplikasi Anda secara keseluruhan akan menjadi 99,9%. Sebaliknya, volume EBS yang menjangkau zona ketersediaan, seperti dalam penerapan DataKeeper, memenuhi syarat untuk 99,99% SLA di lapisan penyimpanan dan komputasi. Ini berarti ketersediaan aplikasi Anda secara keseluruhan adalah 99,99%.

LOKASI PENYIMPANAN

Saat mengonfigurasi FSx untuk ketersediaan tinggi, Anda mungkin ingin mengaktifkan dukungan multi-AZ. Dengan mengaktifkan multi-AZ Anda memiliki AZ "pilihan" dan AZ "siaga" secara efektif. Saat Anda menerapkan node SQL Server FCI, Anda akan ingin mendistribusikan node tersebut ke AZ yang sama.

Sekarang dalam situasi normal, Anda ingin memastikan node cluster aktif berada di AZ yang sama dengan node penyimpanan FSx pilihan. Ini untuk meminimalkan jarak dan latensi ke penyimpanan Anda. Tetapi juga untuk meminimalkan biaya yang terkait dengan transfer data di seluruh AZ. Sebagaimana ditentukan dalam panduan harga FSx, "Biaya transfer data standar berlaku untuk akses antar-AZ atau antar-wilayah ke sistem file."

Dalam keadaan yang tidak menguntungkan di mana Anda mengalami kegagalan SQL Server FCI, tetapi bukan kegagalan FSx, tidak ada mekanisme untuk mengikat penyimpanan dan penghitungan bersama. Jika FSx gagal, secara otomatis gagal kembali ke zona ketersediaan utama. Namun, praktik terbaik menentukan SQL FCI tetap berjalan di node sekunder hingga analisis akar masalah dilakukan dan kegagalan kembali biasanya dijadwalkan untuk terjadi selama periode pemeliharaan. Ini membuat Anda berada dalam situasi di mana penyimpanan Anda berada di AZ yang berbeda, yang akan menimbulkan biaya tambahan. Saat ini biaya untuk mentransfer data di seluruh AZ, baik masuk maupun keluar, adalah $ 0,01 / GB.

Tanpa memperhatikan status FSx dan SQL Server FCI Anda, Anda bahkan mungkin tidak menyadari bahwa keduanya berjalan di wilayah yang berbeda hingga Anda melihat biaya transfer data di akhir bulan.

Sebaliknya, dalam konfigurasi yang menggunakan SIOS DataKeeper, penyimpanan failover adalah bagian dari pemulihan SQL Server FCI, memastikan bahwa penyimpanan selalu gagal dengan contoh SQL Server. Ini memastikan SQL Server selalu membaca dan menulis ke volume EBS yang langsung terpasang ke node aktif. Perlu diingat, DataKeeper akan dikenakan biaya transfer data terkait dengan operasi tulis yang direplikasi antara AZ atau wilayah. Biaya transfer data ini dapat diminimalkan dengan penggunaan kompresi yang tersedia di DataKeeper.

MENGONTROL KEGAGALAN

Dalam konfigurasi multi-subnet FSx, terdapat zona ketersediaan pilihan dan ketersediaan siaga. Jika server file FSx di zona ketersediaan yang disukai mengalami kegagalan, server file di AZ siaga akan pulih. AWS melaporkan bahwa waktu pemulihan ini membutuhkan waktu sekitar 30 detik dengan pembagian standar. Dengan penggunaan berbagi file yang tersedia secara terus menerus, Microsoft melaporkan waktu failover ini dapat mendekati 15 detik. Selama waktu failover ini, terjadi penurunan yang terjadi saat pembacaan dan penulisan dijeda, tetapi akan berlanjut setelah pemulihan selesai.

Multi-situs FSx mengaktifkan failback otomatis. Ini berarti bahwa untuk setiap failover FSx yang tidak direncanakan, Anda juga memiliki failback yang tidak direncanakan. Sebaliknya, biasanya saat SQL Server FCI mengalami failover yang tidak direncanakan, Anda akan membiarkannya berjalan di sekunder atau menjadwalkan failback setelah jam kerja atau selama periode pemeliharaan berikutnya.

SQL SERVER ANALYSIS SERVICES CLUSTER TIDAK DIDUKUNG DENGAN FSX

Jika Anda ingin mengelompokkan SSAS, Anda memerlukan sumber daya disk berkerumun seperti SIOS DataKeeper. Buku putih Cara Mengelompokkan SQL Server Analysis Server dengan jelas menyatakan bahwa SMB tidak dapat digunakan dan pengandar kluster dengan huruf kandar harus digunakan. Sebaliknya, sumber daya Volume DataKeeper menampilkan dirinya sebagai disk berkerumun dan dapat digunakan dengan SSAS.

Ringkasan

Meskipun FSx dapat dimengerti untuk penggunaan UKM biasa seperti file pengguna Windows dan layanan non-kritis lainnya di mana 99,9% ketersediaan SLA mencukupi, FSx adalah pilihan yang sangat baik Jika aplikasi Anda membutuhkan ketersediaan tinggi (99,99%) atau solusi HA / DR yang juga mencakup wilayah, SIOS DataKeeper adalah pilihan yang tepat.

Direproduksi dengan izin dari Clusteringformeremortals
Februari 6, 2021

SIOS Protection Suite untuk Perlindungan Layanan Cepat Linux

Cara menambahkan dukungan aplikasi khusus ke SIOS Protection Suite - SIOS Protection Suite for Linux Quick Service Protection

Menggunakan Suite Perlindungan SIOS untuk Sumber Daya Perlindungan Layanan Cepat Linux

Pada keterlibatan baru-baru ini dengan tim Layanan Profesional SIOS, seorang pelanggan bertanya tentang cara melindungi aplikasi kustom dengan solusi Suite Perlindungan SIOS untuk Linux. Salah satu ahli ketersediaan tinggi yang sangat berpengalaman di SIOS Technology Corp., membantu memahami aplikasi pelanggan dan menjelaskan metode yang disediakan SIOS untuk dukungan aplikasi kustom.

SIOS Protection Suite untuk Linux menyediakan berbagai metode untuk menambahkan ketersediaan tinggi dan pemantauan aplikasi ke aplikasi khusus.Opsi ini meliputi:

  • Membuat kit pemulihan aplikasi kustom (ARK) 1
  • Membuat hierarki sumber daya aplikasi umum
  • Membuat sumber daya perlindungan layanan cepat
Tipe Kompleksitas Coding Pemantauan Pemulihan
Sumber Daya Kit Pemulihan Aplikasi Khusus 1 Paling tinggi Paling tinggi Paling tinggi
Sumber Daya Aplikasi Generik Medium Tinggi Tinggi
Sumber Daya Perlindungan Layanan Cepat Rendah Medium Medium

Definisi yang Digunakan dalam Bagan

Pemantauan – didefinisikan sebagai kemampuan untuk menentukan ketersediaan, aksesibilitas, dan fungsi aplikasi, database, atau layanan yang dilindungi.Tingkat rendah aplikasi, database, atau pemantauan layanan menyediakan cakupan dasar, seperti pemeriksaan untuk proses yang sedang berjalan, keberadaan pid_file, atau bahwa perintah status mengembalikan hasil yang 'benar' saat dijalankan.Catatan: Kode pengembalian 'true' atau '0 (zero)' tidak berarti bahwa aplikasi, database, atau layanan sedang berjalan. Tetapi hanya perintah yang dieksekusi yang berhasil diselesaikan dengan hasil status positif ('benar' atau '0 (nol)').Tingkat pemantauan tertinggi menunjukkan bahwa pengetahuan khusus aplikasi diterapkan untuk menentukan kesehatan dan fungsi aplikasi di luar metode tingkat yang lebih rendah seperti status proses, keluaran ps, atau pengembalian status systemd.Tingkat pemantauan tertinggi biasanya menerapkan pengetahuan tentang urutan operasi pemeriksaan kesehatan yang direkomendasikan, pengetahuan tentang ketergantungan, dan analisis hasil yang diperoleh dari status dan perintah pemantauan.

Pemulihan – didefinisikan sebagai kemampuan untuk memulai ulang aplikasi, database, atau layanan yang gagal.Tingkat kemampuan pemulihan yang rendah menyiratkan bahwa perintah untuk memulai kembali dikeluarkan dan keluaran yang diharapkan diperoleh dari penerbitan perintah.Tingkat pemantauan tertinggi menunjukkan bahwa pengetahuan khusus aplikasi diterapkan untuk menentukan cara memulai restart aplikasi, database, atau layanan secara tertib, yang mungkin memerlukan pengetahuan tentang urutan operasi yang direkomendasikan, dependensi, rollback atau perbaikan terkait lainnya yang gagal layanan.

Solusi: Sumber Daya Perlindungan Layanan Cepat

Dalam keterlibatan ini, aplikasi pelanggan memiliki kompatibilitas systemd. Berdasarkan keseluruhan persyaratan mereka untuk menghindari pengkodean, kebutuhan pemantauan minimal, dan prosedur pemulihan sederhana, kami merekomendasikan Sumber Daya Perlindungan Layanan Cepat (QSP).

Sumber daya QSP bekerja dengan cepat menambahkan dukungan layanan systemd ke SIOS Protection Suite untuk perlindungan sumber daya Linux.Dalam kasus Pelanggan Example.com, mereka memiliki layanan yang kompatibel dengan systemd, dengan definisi minimal yang diperlukan untuk memulai dan menghentikan aplikasi mereka.

[Unit]

Description = SIOS 'as-is' Example Service 2020

Setelah = network.target

Ketik[Service] = sederhana

Mulai ulang = selalu

RestartSec = 3

Pengguna = root

ExecStart = / example_app / bin / exampleapp mulai

ExecStop = / example_app / bin / exampleapp berhen[Install]ti

WantedBy = multi-user.target

Contoh file systemd

SIOS merekomendasikan bahwa sebelum mencoba melindungi sumber daya dengan produk SIOS Protection Suite for Linux, verifikasi melalui systemctl bahwa aplikasi contoh berhenti dan dimulai sebagaimana mestinya:

# contoh status systemctl

* example.service – Layanan Contoh SIOS 'apa adanya' 2020

Dimuat: dimuat (/usr/lib/systemd/system/example.service; dinonaktifkan; preset vendor: dinonaktifkan)

Aktif: tidak aktif (mati)

# contoh systemctl start

# contoh status systemctl

* example.service – Layanan Contoh SIOS 'apa adanya' 2020

Dimuat: dimuat (/usr/lib/systemd/system/example.service; dinonaktifkan; preset vendor: dinonaktifkan)

Aktif: aktif (berjalan) sejak Jum 2020-08-21 14:53:27 EDT; 5 detik lalu

PID Utama: 19937 (exampleapp)

CGroup: /system.slice/example.service

`-19937 / usr / bin / perl / example_app / bin / exampleapp start

# contoh stop systemctl

# contoh status systemctl

* example.service – Layanan Contoh SIOS 'apa adanya' 2020

Dimuat: dimuat (/usr/lib/systemd/system/example.service; dinonaktifkan; preset vendor: dinonaktifkan)

Aktif: tidak aktif (mati)

Setelah memverifikasi bahwa aplikasi berfungsi dengan benar melalui systemd, mulai ulang layanan dan pastikan bahwa layanan berjalan.

# contoh systemctl start

# contoh status systemctl

* example.service – Layanan Contoh SIOS 'apa adanya' 2020

Dimuat: dimuat (/usr/lib/systemd/system/example.service; dinonaktifkan; preset vendor: dinonaktifkan)

Aktif: aktif (berjalan) sejak Jum 2020-08-21 15:59:44 EDT; 3 menit 2 detik yang lalu

PID Utama: 30740 (exampleapp)

Lihat dokumentasi SIOS Protection Suite untuk Linux Quick Service Protection Suite untuk detail tambahan tentang proses pembuatan sumber daya.

Menggunakan SPS-L UI pilih opsi Buat, yang ditunjukkan di Bilah Alat Sumber Daya UI Global dengan ikon berikut:
Sumber Daya AS Global SIOS
Setelah panduan buat diluncurkan, pilih opsi Perlindungan Layanan Cepat di Jendela Buat Wisaya Sumber Daya

Di prompt berikutnya untuk 'Jenis Pengalihan', pilih apakah Anda akan menggunakan pengalihan cerdas atau pengalihan otomatis.

Setelah memilih 'Jenis Pengalih', dialog Server muncul sehingga Anda dapat memilih server utama untuk aplikasi khusus.

(Catatan: Jika layanan memerlukan penyimpanan, pastikan untuk memilih server utama yang sama yang sebelumnya dipilih untuk sumber daya penyimpanan.)

Di kotak dialog Service Name, temukan layanan untuk aplikasi kustom Anda.

Setelah Anda memilih layanan yang benar, misalnya, tentukan apakah Anda akan mengaktifkan pemantauan atau menonaktifkan layanan pemantauan.Lihat dokumentasi untuk mendapatkan pemahaman tentang pemantauan yang disediakan oleh sumber daya QSP


Selanjutnya, pilih tag sumber daya.Tag sumber daya harus menjadi nama yang bermakna yang akan membantu tim TI Anda dengan cepat mengidentifikasi sumber daya SPS-L mana yang melindungi aplikasi atau layanan Anda.

Terakhir, ikuti dialog terakhir untuk menyelesaikan proses pembuatan sumber daya.Setelah sumber daya dibuat, gunakan UI untuk memperluas sumber daya ke server tambahan. Jika perlu, buat ketergantungan antara layanan / aplikasi khusus yang baru dilindungi dan sumber daya lain yang diperlukan seperti penyimpanan atau sumber daya IP.

CATATAN:

1 Membuat kit pemulihan aplikasi pelanggan dapat dilakukan melalui keterlibatan dengan Tim Layanan Profesional SIOS Technology Corp.Untuk informasi lebih lanjut hubungi professional-services@us.sios.com

2 QuickCheck Kit Pemulihan QSP hanya dapat menjalankan kondisi sederhana (menggunakan tindakan "status" dari perintah servis). QSP tidak menjamin bahwa layanan disediakan atau proses tersebut berfungsi. Jika memulai dan / atau menghentikan yang rumit diperlukan, atau operasi pemeriksaan kesehatan yang lebih kuat diperlukan, disarankan menggunakan Aplikasi Generik atau Aplikasi Kustom ARK

Direproduksi dari SIOS
Januari 29, 2021

Cara Memahami & Menanggapi Pemberitahuan Ketersediaan

Kegagalan yang Berhasil

Houston kita punya masalah!Ini adalah garis ikonik yang mengingatkan penggemar luar angkasa dan penggemar film yang tak terhitung jumlahnya tentang kesulitan besar, potensi bencana, dan keadaan berbahaya dari misi luar angkasa Apollo 13 – sebuah misi yang sekarang disebut NASA sebagai "Kegagalan yang Berhasil". Mengabaikan peringatan ketersediaan aplikasi Anda sendiri mungkin tidak dicatat dalam sejarah sebagai momen yang menentukan, tetapi juga dapat menimbulkan malapetaka serupa

Sekarang kembali ke tahun 1970:

"Pengadukan rutin tangki oksigen memicu isolasi kabel yang rusak di dalamnya, menyebabkan ledakan yang mengeluarkan isi dari kedua tangki oksigen Service Module (SM) ke luar angkasa. Tanpa oksigen, yang dibutuhkan untuk bernapas dan untuk menghasilkan tenaga listrik, sistem propulsi dan pendukung kehidupan SM tidak dapat beroperasi. Sistem Modul Komando (CM) harus ditutup untuk menghemat sumber daya yang tersisa untuk masuk kembali, memaksa awak untuk dipindahkan ke Modul Bulan (LM) sebagai sekoci. Dengan pendaratan di bulan dibatalkan, pengontrol misi bekerja untuk membawa kru pulang hidup-hidup. "

Ledakan tangki oksigen memicu alarm, peringatan, penurunan tekanan dan voltase, komunikasi terputus, dan kemudian komunikasi radio yang sekarang terkenal antara astronot dan Pengendali Misi.Tetapi bagaimana jika, setelah ledakan, kru tidak melakukan apa-apa? Bagaimana jika mereka tidak pernah memeriksa ledakan, tidak pernah menanggapi peringatan dan pengukur, dan tidak pernah memberi tahu Mission Control bahwa ada masalah?Bagaimana jika Mission Control, setelah diberi tahu atau diperingatkan kembali di dasbor mereka di pusat kendali, tidak pernah berusaha memberikan bantuan apa pun?Bagaimana jika tim membenamkan kepala mereka di pasir, atau pasrah pada nasib dan kebetulan, tidak pernah mencoba untuk belajar, berimprovisasi, atau meningkatkan dari kegagalan yang mereka hadapi?Hasilnya akan sangat tragis!Ini mungkin berhasil menjadi dokumenter, tetapi bukan film blockbuster yang menampilkan garis ikonik.

Apa yang Anda Lakukan Saat Lansiran Dipicu di Lingkungan Anda?

A; ert

Jalan-jalan di luar angkasa jauh dari aktivitas kita sehari-hari, kecuali tentu saja Anda bekerja untuk NASA, tetapi blog terbaru di Apollo 13 memang memicu pertanyaan yang berlaku untuk ketersediaan.Apa yang Anda lakukan saat ada peringatan yang terpicu di lingkungan Anda? Apakah Anda mengabaikannya begitu saja?Apakah Anda meremehkannya, menunggu untuk melihat apakah peringatan, pesan log, atau indikator lain akan hilang begitu saja?Apakah Anda menghubungi dukungan vendor Anda untuk memahami bagaimana Anda dapat menonaktifkan peringatan, peringatan, dan pesan ini?Atau apakah Anda berkata, "Kami memiliki masalah di sini dan kami perlu menyelesaikannya"?

Sebagai VP Customer Experience di SIOS Technology Corp. kami telah mengalami kedua sisi peringatan dan indikator.Kami dengan susah payah berjalan bersama pelanggan yang memilih untuk mengabaikan peringatan, mematikan peringatan kritis yang menunjukkan masalah, mulai dari ambang aplikasi hingga ketidakstabilan jaringan hingga potensi ketidakkonsistenan data.Dan kami juga telah melihat pelanggan yang telah menyetel peringatan mereka, menyelidiki mengapa alarm mereka berbunyi, menemukan akar penyebabnya dan menikmati hasil kerja mereka.Buah ini paling sering merupakan hadiah manis dari peningkatan stabilitas, inovasi dan pembelajaran, atau bencana yang dapat dihindari.

4 hal yang dapat Anda lakukan saat produk ketersediaan Anda memicu peringatan

1. Tentukan apakah jenis dan kekritisan tanda ketersediaan.

Apakah peringatan atau kesalahan menunjukkan peringatan, kesalahan, atau masalah kritis? Tempat yang baik untuk membantu Anda dan tim Anda memahami kekritisan adalah dengan berkonsultasi dengan dokumentasi yang tersedia. Periksa dokumentasi produk, forum online, artikel basis pengetahuan (KBA), dan data tim internal serta manual proses.

2. Kaji kesegeraan peringatan.

Untuk peringatan dan error, seberapa besar kemungkinannya untuk berkembang menjadi masalah atau peristiwa kritis.Untuk masalah dan peringatan kritis, ini mungkin terlihat jelas tetapi penilaian, bahkan peristiwa kritis akan memberikan beberapa panduan tentang langkah Anda selanjutnya; koreksi diri, isolasi masalah, atau eskalasi langsung.

3. Konsultasikan sumber tambahan.

Sumber lain apa yang dapat Anda akses untuk membuat keputusan tentang kondisi waspada? Misalnya, jika peringatan terkait dengan penyimpanan, apakah ada alat lain yang dapat mengekspos kesehatan penyimpanan Anda?Jika masalahnya adalah peringatan jaringan, apakah ada alat hypervisor, alat lalu lintas, statistik NIC, atau alat pemantauan khusus lainnya yang digunakan untuk membantu analisis.

4. Hubungi dukungan.

Dengan kata lain, jika Anda tidak yakin, peringatkan Mission Control. Setelah menentukan jenis, menilai kesegeraan, dan berkonsultasi dengan sumber tambahan, ada baiknya untuk menghubungi vendor Anda untuk mendapatkan dukungan.Peringatan tentang ambang batas untuk panggilan API mungkin tampak tidak berbahaya. Tetapi jika panggilan API akan gagal setelah batas tersebut tercapai, ini bisa menjadi penyebab untuk tindakan segera. Mendapatkan otoritas dari spesialis dapat membantu menjaga ketenangan pikiran dan menghindari bencana.

Vendor berpengalaman seperti SIOS dapat membantu Anda mengidentifikasi penyebab masalah dengan cepat dan merekomendasikan solusi terbaik.

Mengabaikan masalah dalam lingkungan ketersediaan Anda berulang kali dapat menyebabkan hasil yang tidak terduga, tetapi tidak kalah buruknya. Mengatasi masalah yang ditunjukkan oleh peringatan, pesan log, indikator peringatan, atau indikator lain yang dipasang dan dikonfigurasikan memberi pelanggan Anda, bisnis Anda, tim Anda, dan diri Anda sendiri “kesempatan untuk menyelesaikan masalah,” sebelum menjadi bencana. Dan pada saat yang sama, perkuat infrastruktur dan strategi ketersediaan Anda.Mana yang akan kamu pilih?

– Cassius Rhue, VP, Pengalaman Pelanggan

Direproduksi dari SIOS

 
Januari 23, 2021

Apakah Saya Bahkan Membutuhkan perangkat lunak dengan Ketersediaan Tinggi di Cloud?

Apakah Saya Bahkan Membutuhkan perangkat lunak dengan Ketersediaan Tinggi di Cloud?

Izinkan saya untuk membangkitkan ingatan Anda. . .

Mungkin hari ini Anda tidak mengalami kegagalan dalam belasan bulan atau lebih dan tiba-tiba pembaruan slam dunk untuk lisensi perangkat lunak ketersediaan tinggi Anda berada di bawah garis merah pena CFO.Atau mungkin, sebagian karena penggunaan istilah yang berlebihan, pemasaran yang cerdik, atau definisi ulang ketersediaan tinggi CIO Anda, yang pernah menjadi penggemar paling siap pakai, mulai goyah pada nilainya.Atau mungkin, mungkin saja bukan CFO atau CIO, tetapi Anda yang memutuskan bahwa Anda mungkin memiliki cukup HA tanpa memerlukan perangkat lunak ketersediaan tinggi atau lebih tinggi dalam persamaan.

Sementara cloud publik sangat tangguh dan ketersediaan telah dipertimbangkan di banyak kesempatan, kebutuhan akan perangkat lunak ketersediaan tinggi yang stabil dan dapat dipelihara masih menjadi kenyataan saat ini.Pertimbangkan tahun 2020 misalnya, kemajuan dalam komputasi awan publik dan ketersediaan masih tidak dapat mencegah kesalahan umum seperti praktik buruk dan kode buruk yang menyebabkan aplikasi mogok, kegagalan pusat data yang tidak diungkapkan, gangguan konstruksi tanpa nama yang memengaruhi daya atau jaringan, kelebihan kapasitas pada VM , atau kegagalan sistem pendingin seperti yang disebutkan oleh satu artikel CRN.

Berikut tujuh alasan Anda masih membutuhkan perangkat lunak dengan ketersediaan lebih tinggi di Cloud:

1. Untuk meningkatkan kedalaman dan keluasan cakupan aplikasi untuk aplikasi perusahaan Anda yang paling penting

Tidak ada satu vendor Cloud yang akan memiliki semua alat, perangkat lunak, dan aplikasi yang Anda butuhkan untuk dimasukkan ke dalam infrastruktur cloud mereka dengan cara yang dapat digunakan oleh perusahaan Anda.Karena itu, Anda kemungkinan akan memigrasi beban kerja ke cloud ke dalam penawaran IaaS yang memerlukan seseorang atau sesuatu untuk melindungi beban kerja tersebut dan memastikan ketersediaannya sangat tinggi.

2. Untuk pemulihan aplikasi otomatis dan cerdas dari sistem, sumber daya, dan ketergantungannya.

Vendor cloud tahu tentang cloud. Vendor ketersediaan tinggi tahu tentang ketersediaan tinggi aplikasi. Jika, bukan jika, kegagalan terjadi di cloud, aplikasi Anda memerlukan pemulihan cerdas dari komponen yang gagal; sistem, sumber daya aplikasi, komponen infrastruktur dan ketergantungannya.Sebagai ahli dalam ketersediaan, vendor perangkat lunak Anda memiliki pengetahuan luas yang dimasukkan ke dalam perlindungan aplikasi. Dalam produk Suite Perlindungan SIOS untuk Linux, otomatisasi berbasis wizard menggunakan praktik terbaik industri, dan riwayat panjang keahlian aplikasi mendorong pemulihan otomatis aplikasi yang jelas dalam skenario kegagalan

3. Untuk replikasi data tingkat blok yang cerdas untuk aplikasi Anda, meningkatkan ketahanan Anda jika terjadi kepanikan sistem atau pemadaman pusat data

Cakupan aplikasi dan pemulihan yang cerdas dan seimbang dimungkinkan ketika data tersedia pada sistem siaga jika terjadi kegagalan.Ketika vendor HA Anda menyertakan replikasi data tingkat blok, Anda dapat memperluas ketahanan failover aplikasi Anda di luar satu pusat data atau wilayah menjadi beberapa pusat data dan wilayah.Replikasi data level blok juga merupakan cara yang efektif untuk menghindari nilai perangkat keras yang memengaruhi volume cloud di satu pusat data.Satu insiden cloud yang melibatkan daya pusat data dan kegagalan generator berikutnya mengakibatkan kerusakan perangkat keras dan kehilangan data untuk instans yang berjalan di pusat data tunggal.Cloud tidak berarti bahwa Anda benar-benar aman dari semua kegagalan, dan cadangan serta salinan replikasi data yang sangat tersedia adalah suatu keharusan.

4. Untuk mekanisme respons yang lebih cepat untuk deteksi dan penyelesaian masalah

Perangkat lunak HA Anda adalah garis pertahanan pertama untuk mengidentifikasi dan memulihkan kegagalan aplikasi.Dengan daemon pemantauan, kegagalan aplikasi dapat dengan cepat dideteksi dan diperbaiki oleh perangkat lunak sebelum pengguna terkena dampak kritis.Selain itu, perangkat lunak ketersediaan tinggi Anda seperti solusi SIOS Protection Suite untuk Linux menyertakan metode yang dapat dikonfigurasi untuk mengirim dan mengkomunikasikan peringatan ke administrator, konsol acara, atau dasbor yang memungkinkan Anda berkomunikasi secara instan dan efektif dengan tombol.

5. Untuk sumber data tambahan yang dapat ditambang dan diaudit untuk membantu memprediksi kesehatan dan stabilitas perusahaan Anda

Data adalah raja.Perangkat lunak ketersediaan tinggi Anda adalah sumber data dan informasi yang luar biasa tentang lingkungan Anda yang dapat ditambang dan diaudit.Saat solusi HA Anda merespons kegagalan aplikasi, masalah infrastruktur dan latensi, dan mendorong waktu aktif Anda melalui kegagalan sementara, log mereka menangkap informasi penting tentang kesehatan perusahaan Anda.Sebagai VP Pengalaman Pelanggan, tim Keberhasilan dan Dukungan Pelanggan kami dapat menggunakan log HA kami untuk memberikan pemeriksaan kesehatan kepada pelanggan, memberi tahu mereka tentang beberapa masalah aplikasi dan pengoptimalan yang mungkin terjadi karena data log yang diambil.

6. Untuk sudut pandang yang seimbang dan jujur, dan kebijaksanaan tambahan yang dibutuhkan untuk perusahaan Anda

Selain nilai dari perangkat lunak Ketersediaan Tinggi, ada alasan lain mengapa Anda masih membutuhkan perangkat lunak HA di cloud.Alasan tambahan tersebut adalah sudut pandang yang seimbang dan jujur serta kebijaksanaan tambahan dari tim pengembangan, layanan, dan pengalaman pelanggan vendor HA Anda.Perangkat lunak HA Anda didukung oleh tim ahli, insinyur ketersediaan berpengalaman, dan yang terpenting tim layanan dan dukungan dengan pengalaman praktik terbaik selama bertahun-tahun, pengetahuan khusus aplikasi, dan ide serta keterampilan yang diserbuki silang yang dapat sangat menguntungkan perusahaan Anda.

7. Untuk mengurangi waktu henti pemeliharaan terencana

Last but not least, perangkat lunak ketersediaan tinggi Anda membantu mengurangi atau mungkin menghilangkan waktu henti yang diperlukan untuk peningkatan, tambalan kecil, dan pemeliharaan preventif bergulir.Memanfaatkan kemampuan peralihan dan failover perangkat lunak HA Anda, server siaga Anda dapat secara aktif ditambal, diperbarui, dan diuji kemudian dipromosikan menjadi simpul ketersediaan aktif.Dengan demikian memastikan bahwa sistem penting Anda berjalan pada rilis terbaru sambil meminimalkan penalti peningkatan.

Ya, Cloud telah menambahkan peningkatan perangkat keras dan stabilitas platform untuk aplikasi, pengembang, dan pengguna perusahaan, tetapi jika Anda mulai berpikir bahwa Anda tidak membutuhkan ketersediaan tinggi, Anda sedang menuju ke gang gelap yang berakhir dengan keputusasaan akhir-akhir ini. malam pizza dingin menempatkan aplikasi kembali online, menjelaskan yang tidak bisa dijelaskan, dan merenungkan resume membersihkan.Jadi terima kasih telah membiarkan saya membangkitkan ingatan Anda. . .Anda dan perangkat lunak HA Anda saling membutuhkan, bahkan di Cloud.

– Cassius Rhue, Wakil Presiden, Pengalaman Pelanggan

Direproduksi dengan izin dari SIOS

 
Januari 16, 2021

Haruskah Saya Tetap Menggunakan Zabbix Di AWS?

Haruskah Saya Tetap Menggunakan Zabbix Di AWS

Haruskah Saya Tetap Menggunakan Zabbix Di AWS?

Pemantauan Amazon EC2

Zabbix memiliki pangsa pasar yang tinggi sebagai alat pemantauan OSS terintegrasi.Meskipun telah digunakan secara luas di lingkungan di lokasi, ada banyak contoh Zabbix yang digunakan di lingkungan AWS.Terlepas dari kenyataan bahwa AWS juga memiliki layanan pemantauan seperti Amazon CloudWatch, mengapa Anda harus menggunakan Zabbix?Bagian ini menjelaskan manfaat pemantauan instans EC2 dan instans lainnya, serta proses konfigurasi.

Mengapa menggunakan Zabbix daripada Amazon CloudWatch?

Di lingkungan AWS, semua infrastruktur dioperasikan oleh AWS, tetapi Anda harus bertanggung jawab atas pengoperasian instans Amazon EC2 itu sendiri dan aplikasi yang dibangun di Amazon EC2. Dengan kata lain, Anda harus memantau aplikasi untuk memastikan bahwa aplikasi tersebut beroperasi dengan benar, dan Anda harus mengambil tindakan saat terjadi masalah.Zabbix adalah kandidat yang baik untuk alat pemantauan semacam ini.

Zabbix memiliki keunggulan karena dapat memantau tidak hanya di tempat. Tetapi juga cloud dan lingkungan virtual secara terintegrasi.

Sedangkan Amazon CloudWatch standar terbatas untuk memantau sumber daya AWS (CPU, memori, dll.), Zabbix memungkinkan Anda untuk memantau bahkan status aplikasi Anda secara detail.

Berikut ini adalah daftar keunggulan lain dari Zabbix.

Pemantauan lingkungan terintegrasi dengan beberapa akun AWS

Amazon CloudWatch melakukan pemantauan per akun AWS.Zabbix dapat memantau lingkungan beberapa akun AWS, yang dapat memantau sistem bisnis yang terdiri dari beberapa akun.Itu juga dapat mendeteksi anomali tidak hanya dengan peringatan sederhana berdasarkan ambang batas, tetapi juga dengan beberapa ambang batas dan kondisi dalam kombinasi. 

Itu dapat dikonfigurasi dengan pemberitahuan rinci agar sesuai dengan kondisi operasi yang sebenarnya

Amazon CloudWatch dapat memberi tahu Anda dengan pesan jika terjadi anomali.Misalnya, jika sistem Anda sedang dalam pemeliharaan, Anda tidak perlu diberi tahu melalui pesan.Di sinilah Zabbix memungkinkan Anda untuk mengkonfigurasi kasus ini dengan cara yang memungkinkan Anda untuk menyembunyikan pesan yang tidak diinginkan.Dengan cara ini Anda dapat memastikan bahwa Anda hanya diberi tahu ketika ada sesuatu yang benar-benar salah yang perlu ditangani.

Tidak ada periode retensi untuk metrik (log pemantauan)

Dengan Amazon CloudWatch, metrik dapat disimpan hingga 15 bulan.Selain itu, Anda hanya dapat menyimpan metrik setiap jam selama 15 bulan, dan jika interval pemantauan disetel ke kurang dari 60 detik, Anda hanya dapat menyimpannya selama maksimal 3 jam.Zabbix memungkinkan penyimpanan metrik jangka panjang tanpa mengubah perincian informasi.

Cara memantau lingkungan AWS dengan Zabbix

Jika Anda ingin menggunakan Zabbix di AWS, Anda perlu membuat instans Amazon EC2 dan DB dan menginstal Zabbix di dalamnya.Setelah instalasi, proses konfigurasi Zabbix pada dasarnya sama dengan proses on-premise, hanya saja Anda perlu mengatur yang berikut ini

  1. Akun pengguna (selain pengguna Admin Zabbix, Anda perlu membuat pengguna untuk penggunaan produksi)
  2. Agen host Zabbix (menentukan dari mana data dikumpulkan)
  3. Item (mengatur data apa yang akan dikumpulkan)
  4. Pemicu (menentukan keadaan data yang tidak normal)
  5. Tindakan (mendefinisikan tindakan yang akan diambil ketika terjadi kesalahan)

Selain itu, Anda dapat mengonfigurasi pengaturan khusus AWS, seperti membuat pengguna di AWS IAM dengan izin yang diperlukan untuk Zabbix, yang akan memungkinkan Zabbix memantau aplikasi dan aspek lain dari lingkungan AWS Anda.

Gunakan alat yang tepat untuk kebutuhan pemantauan Anda

Tidak semua sistem perusahaan beroperasi secara terpisah, tetapi banyak sistem yang dihubungkan bersama untuk bertukar data dan memastikan konsistensi secara keseluruhan.Dalam lingkungan ini, Zabbix adalah alat yang hebat untuk memantau dan mendeteksi anomali di beberapa server dan sistem.Misalnya, jika aplikasi web berbasis DB memiliki anomali pada server aplikasi web, data dapat dinonaktifkan, misalnya.

Di sisi lain, Zabbix memiliki banyak opsi konfigurasi, jadi Anda harus memutuskan apa yang akan dipantau dan bagaimana, dan kondisi apa yang tidak normal.

Di sisi lain, Zabbix memiliki banyak pengaturan, jadi Anda harus mendesain operasi dengan tepat apa yang harus dipantau dan apa yang harus dilakukan, dan apa yang harus dilakukan. Tentu saja, untuk sistem kritis, desain seperti itu penting, namun, untuk sistem yang relatif sederhana, seperti "jika suatu proses berhenti, mulai ulang saja", tidak ada yang cocok untuk pemantauan Zabbix.SIOS AppKeeper adalah solusi yang baik untuk kasus seperti itu, karena ia memantau layanan (proses) dari aplikasi yang berjalan pada instans EC2, dan memulai ulang aplikasi jika mendeteksi masalah. Ini memungkinkan pemantauan dan pengoperasian yang sederhana.

Tentu saja, tidak “wajib” menggunakan Zabbix di setiap sistem.Dengan menggunakan alat yang tepat untuk setiap jenis pemantauan, Anda akan dapat mengoperasikan sistem Anda dengan lebih efisien.

Tambahkan SIOS AppKeeper ke operasi pemantauan dan pemulihan EC2 Anda.

Direproduksi dari SIOS
  • Results 301-305 of 928
  • < Page 61 of 186 >

  • Bergabunglah dengan Milis Kami