Halaman ini menjelaskan ketahanan aplikasi untuk Google Cloud NetApp Volumes dan cara klien NFS, SMB, dan iSCSI menangani jeda I/O. Meskipun NetApp Volumes memiliki ketersediaan tinggi, operasi I/O dapat dijeda sebentar selama peristiwa pemeliharaan terencana atau peristiwa layanan yang tidak terencana. Halaman ini juga merekomendasikan setelan waktu tunggu untuk membantu memastikan operasi aplikasi berjalan lancar, terutama saat Anda menggunakan software cluster seperti Pacemaker.
Pertimbangan ketahanan aplikasi
Meskipun NetApp Volumes memiliki ketersediaan tinggi, peristiwa pemeliharaan terencana seperti update platform, upgrade layanan, upgrade software, atau kegagalan komponen yang tidak terencana dalam layanan dapat menyebabkan jeda singkat dalam operasi input dan output (I/O).
Untuk mengetahui informasi selengkapnya tentang peristiwa pemeliharaan terencana dan pemadaman layanan yang tidak terencana, lihat Memantau dan merencanakan peristiwa pemeliharaan.
Untuk mengetahui informasi selengkapnya tentang pengaruh peristiwa pemeliharaan ini terhadap status kumpulan penyimpanan, lihat Status kumpulan penyimpanan.
Jeda I/O
Software klien Network File System (NFS), Server Message Block (SMB), dan iSCSI di dalam sistem operasi Anda menangani jeda I/O singkat. Klien menunggu dan mencoba ulang operasi I/O tanpa menyampaikan masalah tersebut ke aplikasi. Jeda singkat tersebut dianggap tidak mengganggu karena meskipun pengguna aplikasi mungkin melihat waktu respons yang lebih lama, aplikasi tidak melaporkan error I/O.
Untuk jeda I/O yang lebih lama, perilaku bergantung pada klien NFS, SMB, atau iSCSI sistem operasi Anda dan potensi waktu tunggu yang dikonfigurasi dalam aplikasi. Bagian berikut membahas detail khusus protokol untuk jeda I/O.
Jeda I/O NFS
Semua panggilan ke berbagi NFS yang tidak tersedia dan terpasang secara permanen diblokir di klien NFS dan menunggu tanpa batas waktu hingga server NFS merespons lagi. Saat klien NFS Anda menunggu, pesan akan muncul di log klien yang menunjukkan bahwa server NFS tidak merespons.
Dari perspektif aplikasi, operasi I/O seperti baca atau tulis diblokir dan tetap tertunda hingga berbagi NFS berhasil ditampilkan. Selama jeda I/O, tidak ada operasi I/O yang pernah hilang dan NetApp Volumes memastikan konsistensi data, kecuali jika Anda menghentikan operasi I/O yang tertunda secara paksa di sisi klien.
Menggunakan aplikasi software cluster untuk mengotomatiskan failover
Jika Anda menggunakan aplikasi software cluster seperti Pacemaker di VM klien untuk mengotomatiskan failover aplikasi, konfigurasi waktu tunggu untuk berbagi NFS agar tahan terhadap peristiwa pemeliharaan NetApp Volumes. Failover tersebut akan membatalkan operasi I/O yang tertunda di klien dan dapat menyebabkan transaksi hilang. Sebaiknya gunakan waktu tunggu berikut:
| Jenis protokol | Waktu tunggu yang direkomendasikan | Catatan |
|---|---|---|
| Berbagi NFSv3 | 60 detik (untuk tingkat layanan Standar, Premium, Extreme, dan Flex Unified)
120 detik (untuk tingkat layanan Flex File) |
Sebaiknya gunakan metode fencing, yang menggunakan opsi pemasangan
nolock bukan mengandalkan kunci NFS. |
| NFSv4.1 | 105 detik (untuk tingkat layanan Standar, Premium, Extreme, dan Flex Unified)
165 detik (untuk tingkat layanan Flex File) |
Protokol NFSv4.1 secara otomatis menambahkan penguncian yang andal melalui NFSv3 (NFSv4.x RFC, bagian 9.6.2), yang dapat Anda gunakan sebagai mekanisme fencing. Pemulihan status kunci menambahkan 45 detik. |
Jeda I/O berbagi SMB
Tidak seperti NFS, sesi SMB menggunakan koneksi yang dapat mengalami waktu tunggu habis. NetApp Volumes biasanya menghindari waktu tunggu habis.
Waktu tunggu sesi
Waktu tunggu sesi ditentukan di klien. Waktu tunggu default untuk klien Windows adalah 60 detik. Anda dapat menjalankan perintah Get-SmbClientConfiguration/Set-SmbClientConfiguration menggunakan parameter SessionTimeout untuk membaca atau mengubah waktu tunggu sesi.
Jika waktu tunggu sesi terjadi, sesi SMB akan terputus dan error I/O akan dilaporkan ke aplikasi yang melakukan I/O. Aplikasi File Explorer atau Microsoft 365 biasanya terhubung kembali segera setelah pengguna mengakses berbagi SMB lagi. Saat mengalami error I/O, beberapa aplikasi mencoba terhubung kembali dan mencoba ulang operasi I/O yang gagal, sementara aplikasi lainnya tidak. Lihat dokumentasi vendor aplikasi Anda untuk memahami cara aplikasi menangani waktu tunggu SMB dan beroperasi dengan tangguh di berbagi SMB.
Berbagi yang selalu tersedia (CA) adalah fitur SMB3.x yang meningkatkan ketahanan failover untuk aplikasi seperti database. NetApp Volumes mendukung berbagi yang selalu tersedia untuk Microsoft SQL Server dan FSLogix.
Pemulihan kegagalan meningkat dengan setiap versi SMB baru. NetApp Volumes mendukung SMB 2.1, 3.0, dan 3.1.1. Jika memungkinkan, gunakan versi SMB terbaru yang didukung. Windows 10/Server 2016 dan yang lebih baru mendukung versi SMB 3.1.1 terbaru.
Tindakan pencegahan berbasis aplikasi SMB
Aplikasi berbasis SMB tertentu memerlukan Failover Transparan SMB. Failover Transparan SMB memungkinkan operasi pemeliharaan pada volume SMB dalam NetApp Volumes tanpa mengganggu konektivitas ke aplikasi server yang menyimpan dan mengakses data. NetApp Volumes mendukung opsi berbagi yang selalu tersedia SMB untuk memastikan aplikasi tertentu mendukung Failover Transparan SMB. Penggunaan berbagi yang selalu tersedia SMB hanya mendukung workload berikut:
Container profil pengguna FSLogix
Microsoft SQL Server (bukan Linux SQL Server)
Berbagi yang selalu tersedia SMB tidak mendukung aplikasi kustom.
Jeda I/O iSCSI
Di lingkungan Linux dan Windows, klien iSCSI (initiator) menangani jeda I/O dengan mencoba ulang perintah hingga target (NetApp Volumes) tersedia. Selama peristiwa pemeliharaan singkat, initiator iSCSI mencoba terhubung kembali dan melanjutkan operasi I/O yang tertunda, yang membantu mempertahankan ketahanan aplikasi.
Waktu tunggu iSCSI
Konfigurasi waktu tunggu iSCSI yang tepat sangat penting untuk mempertahankan ketahanan aplikasi selama peristiwa pemeliharaan atau gangguan layanan yang tidak terduga.
Untuk sistem Linux, NetApp Volumes menggunakan setelan initiator iSCSI default. Setelan ini mencakup konfigurasi khusus NetApp dalam Linux Device Mapper Multipath default, yang secara otomatis mengelola persyaratan waktu tunggu selama peristiwa pemeliharaan NetApp Volumes.
Namun, untuk sistem Windows, ubah setelan MPIO Windows menggunakan perintah berikut untuk menangani peristiwa pemeliharaan NetApp Volumes.
Set-MPIOSetting -NewPathVerificationState Enabled ` -NewPDORemovePeriod 130 ` -NewRetryCount 6 ` -CustomPathRecovery Enabled ` -NewPathRecoveryInterval 30 `
Selama jeda I/O, initiator iSCSI mencoba ulang perintah dan mempertahankan I/O yang tertunda selama durasi waktu tunggu. Jika waktu tunggu terlampaui, sistem operasi mungkin melaporkan error I/O ke aplikasi, yang dapat mengakibatkan transaksi hilang atau memerlukan pemulihan tingkat aplikasi.
Pertimbangan aplikasi dan cluster
Jika Anda menggunakan software atau aplikasi clustering yang mengotomatiskan failover, konfigurasi waktu tunggu iSCSI untuk mengakomodasi peristiwa pemeliharaan NetApp Volumes. Failover prematur dapat membatalkan operasi I/O yang tertunda, dan dapat mengakibatkan hilangnya data atau transaksi. Selalu lihat dokumentasi aplikasi dan sistem operasi Anda untuk mengetahui praktik terbaik tentang setelan waktu tunggu iSCSI.
Gangguan aplikasi terkait peristiwa pemeliharaan
Peristiwa pemeliharaan terencana, seperti untuk upgrade platform dan upgrade software layanan, mungkin terjadi sesekali. Peristiwa pemeliharaan dianggap tidak mengganggu dari perspektif protokol file (NFS atau SMB) selama aplikasi dapat menangani jeda I/O yang mungkin terjadi selama peristiwa ini.
Untuk tingkat layanan Standar, Premium, dan Extreme, jeda I/O biasanya singkat dan berkisar antara beberapa detik hingga 30 detik.
Untuk tingkat layanan Flex, jeda I/O hingga 70 detik.
Untuk mengetahui informasi selengkapnya tentang pengaruh peristiwa pemeliharaan ini terhadap status kumpulan penyimpanan, lihat Status kumpulan penyimpanan.
Langkah berikutnya
Baca pertimbangan keamanan Google Cloud NetApp Volumes security considerations.