Ujian failover: adakah strim TCP yang telah terbentuk bertahan?

Dua hasil tersembunyi dalam ayat bahawa sandaran berfungsi. Permintaan baharu berjaya, itulah pemulihan. Pemindahan yang sudah berjalan terus berlanjutan, itulah kesinambungan. Kedua-duanya janji yang berbeza, dan kebanyakan reka bentuk failover memberikan yang pertama sementara yang kedua tamat masa secara senyap. Putuskan yang mana anda perlukan sebelum memilih mekanisme, dan tulis ujian itu supaya ia dapat membezakan keduanya.

Dua hasil yang kelihatan seperti satu kejayaan

Bayangkan klien pada 10.90.0.42 dengan sambungan ke 198.51.100.20:443. Exit utama menterjemahkannya kepada satu alamat dan port awam, dan exit sandaran menterjemahkannya kepada yang lain. Alamat dalaman klien tidak pernah berubah, sebab itu orang menjangka sambungan itu akan bertahan.

Pelayan tidak melihat alamat dalaman. Ia melihat titik akhir yang diterjemah, dan titik akhir itu berbeza selepas pertukaran.

Jadi strim lama tamat masa sementara sambungan baharu ke perkhidmatan yang sama berfungsi serta-merta. Kedua-dua pemerhatian benar pada masa yang sama.

Apa yang pelayan lihat apabila exit berubah

Sambungan TCP dikenal pasti melalui empat tupelnya, dan menukar alamat atau port sumber mencipta sambungan berbeza bagi hos yang menerima. Paket yang tiba dari sumber baharu pada sambungan yang pelayan tidak kenal akan digugurkan atau dijawab dengan set semula. Tiada apa pun dalam alamat klien VPN mengekalkan persatuan itu merentasi perubahan tersebut.

Failover berkeadaan wujud semata-mata untuk mengelakkannya, dan ia berfungsi dengan menukar keadaan terjemahan dan keadaan sambungan antara peranti penghantaran. Itu sifat pasangan, bukan terowong, dan ia mesti direka serta diuji, bukan diandaikan.

Periksa sama ada pasangan itu benar-benar menyimpan keadaan sebelum menjanjikan kesinambungan kepada sesiapa. Arahan di bawah menunjukkan keadaan semasa di kedua-dua belah.

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 awam yang sama tidak mencukupi

Mengekalkan satu alamat awam pada kedua-dua laluan ialah permulaan yang baik, kerana pelayan kemudian melihat titik akhir sumber yang sama. Namun ia tidak mencukupi dengan sendirinya. Peranti penghantaran masih memerlukan keadaan terjemahan, keadaan tembok api dan laluan balik yang boleh digunakan, dan semua itu mesti wujud pada peranti yang membawa trafik selepas pertukaran.

RFC 3022 menerangkan terjemahan alamat dan menganggap pertukaran keadaan antara peranti penterjemah sebagai sebahagian daripada reka bentuk sandaran. Alamat terapung atau profil yang disalin memindahkan konfigurasi tanpa memindahkan keadaan.

Sebab itu ujian yang hanya membuat ping melalui sandaran membuktikan sangat sedikit. Ping tidak mempunyai keadaan sambungan untuk hilang.

Putuskan betapa kuatnya keperluan itu

Jika pengguna boleh menyambung semula selepas kegagalan, reka bentuk itu ialah reka bentuk pemulihan dan ujian penerimaan ialah permintaan baharu. Jika pemindahan fail mesti bertahan, reka bentuk memerlukan penyegerakan keadaan dan ujian yang jauh lebih teliti. Jika sesi jauh mesti bertahan, keperluannya lebih kuat lagi dan mungkin memerlukan mekanisme peringkat aplikasi dan bukan peringkat rangkaian.

Tulis keperluan itu sebagai ayat dengan hasil yang boleh diukur, contohnya muat naik selesai tanpa bermula semula atau pengendali menyambung semula dalam satu minit. Kemudian pilih mekanisme termurah yang memenuhinya, dan selalunya itulah reka bentuk pemulihan.

Katakan secara jelas apa yang berlaku apabila laluan utama kembali, kerana failback automatik boleh memutuskan sambungan yang baru pulih pada sandaran. Kes itu tergolong dalam pelan ujian, bukan nota kaki.

Periksa strim lama dan permintaan baharu

Mulakan pemindahan panjang yang tidak berbahaya melalui laluan utama, kemudian permintaan baharu yang berasingan ke perkhidmatan yang sama. Catat konteks aplikasi, alamat keluar yang diperhatikan dan masa. Putuskan laluan utama dengan cara yang diluluskan dan terus perhatikan pemindahan asal sambil menghantar permintaan baharu melalui sandaran.

Laporkan tiga nilai: sama ada strim lama berterusan, ditetapkan semula atau tamat masa; bila operasi baharu mula berfungsi; dan sama ada failback memutuskan apa-apa. Ketiga-tiga baris itu ialah rekod 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 membuta tuli selepas tamat masa. Penulisan mungkin sudah tiba sebelum jawapan hilang. Tanya aplikasi tentang hasilnya, atau cuba semula hanya di tempat operasi itu idempoten. Kemudian tulis pernyataan penerimaan dalam tiga bahagian: operasi baharu pulih di bawah dasar exit, strim sedia ada mempunyai tingkah laku gangguan yang didokumenkan, dan aplikasi menyambung semula dengan selamat. Pernyataan itu boleh diuji, dan ia jujur tentang apa yang tidak dijanjikan oleh reka bentuk.