Uji failover: apakah stream TCP yang sudah terbentuk bertahan?

Dua hasil bersembunyi di dalam kalimat bahwa cadangan berfungsi. Permintaan baru berhasil, itulah pemulihan. Transfer yang sudah berjalan berlanjut, itulah kesinambungan. Keduanya janji yang berbeda, dan sebagian besar desain failover memenuhi yang pertama sementara yang kedua diam-diam habis waktu. Putuskan mana yang Anda butuhkan sebelum memilih mekanisme, dan tulis pengujiannya agar dapat membedakan keduanya.

Dua hasil yang tampak seperti satu keberhasilan

Bayangkan klien di 10.90.0.42 dengan koneksi ke 198.51.100.20:443. Exit utama menerjemahkannya ke satu alamat dan port publik, dan exit cadangan menerjemahkannya ke alamat lain. Alamat internal klien tidak pernah berubah, itu sebabnya orang mengharapkan koneksi bertahan.

Server tidak melihat alamat internal. Ia melihat endpoint hasil terjemahan, dan endpoint itu berbeda setelah pergantian.

Jadi stream lama habis waktu sementara koneksi baru ke layanan yang sama langsung berfungsi. Kedua pengamatan benar pada saat yang sama.

Apa yang dilihat server saat exit berganti

Koneksi TCP diidentifikasi oleh empat-tupelnya, dan mengubah alamat atau port sumber menciptakan koneksi berbeda bagi host penerima. Paket yang datang dari sumber baru pada koneksi yang tidak dikenal server akan dibuang atau dijawab dengan reset. Tidak ada apa pun di alamat klien VPN yang mempertahankan asosiasi melewati perubahan itu.

Failover stateful ada justru untuk menghindarinya, dan cara kerjanya menukar state terjemahan dan state koneksi antar perangkat penerus. Itu sifat pasangan, bukan terowongan, dan harus dirancang serta diuji, bukan diasumsikan.

Periksa apakah pasangan itu benar-benar menyimpan state sebelum menjanjikan kesinambungan kepada siapa pun. Perintah di bawah menunjukkan keadaan saat ini di kedua sisi.

conntrack -L -d 198.51.100.20 2>/dev/null | head
ss -tin dst 198.51.100.20
tcpdump -ni any host 198.51.100.20 -c 10

Mengapa alamat publik yang sama tidak cukup

Mempertahankan satu alamat publik di kedua jalur adalah awal yang baik, karena server lalu melihat endpoint sumber yang sama. Namun itu tidak cukup dengan sendirinya. Perangkat penerus tetap memerlukan state terjemahan, state firewall, dan jalur balik yang bisa dipakai, dan semua itu harus ada pada perangkat yang membawa lalu lintas setelah pergantian.

RFC 3022 menjelaskan terjemahan alamat dan memperlakukan pertukaran state antar perangkat penerjemah sebagai bagian dari desain cadangan. Alamat mengambang atau profil yang disalin memindahkan konfigurasi tanpa memindahkan state.

Itu sebabnya pengujian yang hanya melakukan ping melalui cadangan membuktikan sangat sedikit. Ping tidak punya state koneksi untuk hilang.

Putuskan seberapa kuat persyaratannya

Jika pengguna dapat menyambung ulang setelah kegagalan, desainnya adalah desain pemulihan dan uji penerimaannya adalah permintaan baru. Jika transfer file harus bertahan, desainnya memerlukan sinkronisasi state dan pengujian yang jauh lebih cermat. Jika sesi jarak jauh harus bertahan, persyaratannya bahkan lebih kuat dan mungkin memerlukan mekanisme tingkat aplikasi alih-alih tingkat jaringan.

Tulis persyaratannya sebagai kalimat dengan hasil yang terukur, misalnya unggahan selesai tanpa mengulang dari awal atau operator menyambung ulang dalam satu menit. Lalu pilih mekanisme termurah yang memenuhinya, dan itu sering kali desain pemulihan.

Katakan secara eksplisit apa yang terjadi saat jalur utama kembali, karena failback otomatis dapat memutus koneksi yang baru saja pulih di cadangan. Kasus itu termasuk dalam rencana uji, bukan catatan kaki.

Periksa stream lama dan permintaan baru

Mulai transfer panjang yang tidak berbahaya melalui jalur utama, lalu permintaan baru yang terpisah ke layanan yang sama. Catat konteks aplikasi, alamat keluar yang teramati, dan waktu. Putuskan jalur utama dengan cara yang disetujui dan terus amati transfer asli sambil mengirim permintaan baru melalui cadangan.

Laporkan tiga nilai: apakah stream lama berlanjut, di-reset, atau habis waktu; kapan operasi baru pertama kali berhasil; dan apakah failback memutus sesuatu. Ketiga baris itulah catatan penerimaan.

ss -tin dst 198.51.100.20
curl -sS -o /dev/null -w '%{http_code} %{time_total}\n' https://198.51.100.20/
tcpdump -ni any port 443 -c 20

Jika beban kerja menulis data, jangan ulangi operasi yang tidak pasti secara membabi buta setelah waktu habis. Penulisan mungkin sudah sampai sebelum jawabannya hilang. Tanyakan hasilnya kepada aplikasi, atau ulangi hanya di tempat operasi itu idempoten. Lalu tulis pernyataan penerimaan dalam tiga bagian: operasi baru pulih sesuai kebijakan exit, stream yang ada memiliki perilaku gangguan yang terdokumentasi, dan aplikasi melanjutkan dengan aman. Pernyataan itu dapat diuji, dan jujur tentang apa yang tidak dijanjikan desain.