FAQ ketahanan aplikasi Azure NetApp Files

  • Artikel

Artikel ini membahas Tanya Jawab Umum (FAQ) mengenai ketahanan aplikasi Azure NetApp Files.

Apa yang Anda rekomendasikan dalam menangani potensi gangguan aplikasi karena kejadian pemeliharaan layanan penyimpanan?

Azure NetApp Files mungkin melakukan pemeliharaan yang direncanakan sesekali (misalnya, pembaruan platform, layanan atau peningkatan perangkat lunak). Dari perspektif protokol file (NFS/SMB), operasi pemeliharaan tidak mengganggu, selama aplikasi dapat menangani jeda IO yang mungkin terjadi secara singkat selama peristiwa ini. Jeda I/O biasanya pendek, mulai dari beberapa detik hingga 30 detik. Protokol NFS sangat kuat, dan operasi file server klien berlanjut secara normal. Beberapa aplikasi mungkin memerlukan penyetelan untuk menangani jeda IO selama 30-45 detik. Dengan demikian, pastikan Anda mengetahui pengaturan ketahanan aplikasi untuk mengatasi peristiwa pemeliharaan layanan penyimpanan. Untuk aplikasi interaktif manusia yang memanfaatkan protokol SMB, pengaturan protokol standar biasanya sudah cukup.

Penting

Untuk memastikan arsitektur tangguh, sangat penting untuk mengenali bahwa cloud beroperasi di bawah model tanggung jawab bersama. Model ini mencakup platform cloud Azure, layanan infrastrukturnya, lapisan OS, dan vendor aplikasi. Masing-masing komponen ini memainkan peran penting dalam menangani potensi gangguan aplikasi yang mungkin muncul selama peristiwa pemeliharaan layanan penyimpanan.

Apakah saya perlu melakukan tindakan pencegahan khusus untuk aplikasi berbasis SMB tertentu?

Ya, aplikasi berbasis SMB tertentu memerlukan SMB Transparent Failover. SMB Transparent Failover memungkinkan operasi pemeliharaan pada layanan Azure NetApp Files tanpa mengganggu konektivitas ke aplikasi server yang menyimpan dan mengakses data pada volume SMB. Untuk mendukung SMB Transparent Failover, Azure NetApp Files sekarang mendukung opsi berbagi Ketersediaan Berkelanjutan SMB. Menggunakan Ketersediaan Berkelanjutan SMB hanya didukung untuk beban kerja pada:

Perhatian

Aplikasi kustom tidak didukung dengan Ketersediaan Berkelanjutan SMB dan tidak dapat digunakan dengan volume yang diaktifkan Ketersediaan Berkelanjutan SMB.

Saya menjalankan IBM MQ di Azure NetApp Files. Tindakan pencegahan apa yang dapat saya lakukan untuk menghindari gangguan karena kejadian pemeliharaan layanan penyimpanan meskipun menggunakan protokol NFS?

Jika Anda menjalankan aplikasi IBM MQ dalam konfigurasi file bersama, di mana data dan log IBM MQ disimpan pada volume Azure NetApp Files, pertimbangan berikut disarankan untuk meningkatkan ketahanan selama peristiwa pemeliharaan layanan penyimpanan:

Catatan

Jumlah pesan yang harus diproses oleh setiap pasangan multi instans MQ sangat tergantung pada lingkungan spesifik Anda. Anda perlu memutuskan berapa banyak pasangan multi instans MQ yang diperlukan, atau apa aturan peningkatan skala atau penurunan skalanya.

Arsitektur scale-out akan terdiri dari beberapa pasangan multi instans IBM MQ yang diterapkan di belakang Azure Load Balancer. Aplikasi yang dikonfigurasi untuk berkomunikasi dengan IBM MQ kemudian akan dikonfigurasi untuk berkomunikasi dengan instans IBM MQ melalui Azure Load Balancer. Untuk dukungan yang terkait dengan IBM MQ pada volume NFS bersama, Anda harus mendapatkan dukungan vendor di IBM.

Saya menjalankan Apache ActiveMQ dengan LevelDB atau KahaDB di Azure NetApp Files. Tindakan pencegahan apa yang dapat saya lakukan untuk menghindari gangguan karena kejadian pemeliharaan layanan penyimpanan meskipun menggunakan protokol NFS?

Jika Anda menjalankan Apache ActiveMQ, disarankan untuk menyebarkan ActiveMQ High Availability dengan Pluggable Storage Lockers.

Model activeMQ ketersediaan tinggi (HA) memastikan bahwa instans broker selalu online dan mampu memproses lalu lintas pesan. Dua model ActiveMQ HA yang paling umum melibatkan berbagi filesystem melalui jaringan. Tujuannya adalah untuk memberikan LevelDB atau KahaDB ke instans broker aktif dan pasif. Model HA ini mengharuskan kunci tingkat OS diperoleh dan dikelola pada file di direktori LevelDB atau KahaDB, yang disebut "kunci." Ada beberapa masalah dengan model ActiveMQ HA ini. Replika dapat menyebabkan situasi "tanpa master", di mana replika tidak menyadari bahwa replika dapat mengunci file. Mereka juga dapat menyebabkan konfigurasi "master-master" yang menghasilkan korupsi indeks atau jurnal dan akhirnya kehilangan pesan. Sebagian besar masalah ini berasal dari faktor-faktor di luar kendali ActiveMQ. Misalnya, klien NFS yang tidak dioptimalkan dengan baik dapat menyebabkan penguncian data menjadi kedaluarsa pada beban, yang menyebabkan downtime "tak bertuan" selama failover.

Karena sebagian besar masalah dengan solusi ketersediaan tinggi ini berasal dari penguncian file tingkat OS yang tidak akurat, maka komunitas ActiveMQ memperkenalkan konsep loker penyimpanan yang dapat dicolokkan di broker versi 5.7. Pendekatan ini memungkinkan pengguna untuk mengambil keuntungan dari cara yang berbeda dari kunci bersama, menggunakan kunci database JDBC tingkat baris sebagai lawan dari kunci filesystem tingkat OS. Untuk dukungan atau konsultasi tentang arsitektur dan penyebaran ActiveMQ HA, Anda harus menghubungi OpenLogic by Perforce.

Saya menjalankan Apache ActiveMQ dengan LevelDB atau KahaDB di Azure NetApp Files. Tindakan pencegahan apa yang dapat saya lakukan untuk menghindari gangguan karena kejadian pemeliharaan layanan penyimpanan meskipun menggunakan protokol SMB?

Rekomendasi industri biasanya adalah tidak menjalankan penyimpanan bersama KahaDB Anda di CIFS/SMB. Jika Anda mengalami masalah dalam mempertahankan status kunci yang akurat, lihat JDBC Pluggable Storage Locker, yang dapat memberikan mekanisme penguncian yang lebih andal. Untuk dukungan atau konsultasi tentang arsitektur dan penyebaran ActiveMQ HA, Anda harus menghubungi OpenLogic by Perforce.

Saya menjalankan Boomi di Azure NetApp Files. Tindakan pencegahan apa yang dapat saya lakukan untuk menghindari gangguan karena peristiwa pemeliharaan layanan penyimpanan?

Jika Anda menjalankan Boomi, disarankan Anda mengikuti Praktik Terbaik Boomi untuk Ketersediaan Tinggi Run Time dan Pemulihan Bencana.

Boomi merekomendasikan Boomi Molecule digunakan untuk mengimplementasikan ketersediaan tinggi untuk Boomi Atom. Persyaratan sistem Boomi Molecule menyatakan bahwa NFS dengan penguncian NFS diaktifkan (dukungan NLM) atau berbagi file SMB dapat digunakan. Dalam konteks Azure NetApp Files, volume NFSv4.1 memiliki dukungan NLM.

Boomi merekomendasikan bahwa berbagi file SMB digunakan dengan VM Windows; untuk NFS, Boomi merekomendasikan VM Linux.

Catatan

Berbagi Ketersediaan Berkelanjutan Azure NetApp Files tidak didukung dengan Boomi.

Langkah berikutnya