การทดสอบ failover: สตรีม TCP ที่สร้างแล้วจะรอดหรือไม่

มีสองผลลัพธ์ซ่อนอยู่ในประโยคที่ว่าตัวสำรองทำงาน คำขอใหม่สำเร็จ นั่นคือการกู้คืน การถ่ายโอนที่กำลังดำเนินอยู่ยังคงดำเนินต่อ นั่นคือความต่อเนื่อง ทั้งสองเป็นคำสัญญาที่ต่างกัน และการออกแบบ failover ส่วนใหญ่ให้ผลแรก ขณะที่ผลที่สองหมดเวลาอย่างเงียบ ๆ ตัดสินใจว่าคุณต้องการแบบไหนก่อนเลือกกลไก และเขียนการทดสอบให้แยกทั้งสองได้

สองผลลัพธ์ที่ดูเหมือนความสำเร็จเดียว

ลองนึกภาพไคลเอนต์ที่ 10.90.0.42 มีการเชื่อมต่อไปยัง 198.51.100.20:443 ทางออกหลักแปลงเป็นที่อยู่และพอร์ตสาธารณะหนึ่งชุด และทางออกสำรองแปลงเป็นอีกชุด ที่อยู่ภายในของไคลเอนต์ไม่เคยเปลี่ยน ด้วยเหตุนี้ผู้คนจึงคาดว่าการเชื่อมต่อจะรอด

เซิร์ฟเวอร์ไม่เห็นที่อยู่ภายใน เห็นเพียงปลายทางที่ถูกแปลง และปลายทางนั้นแตกต่างหลังการสลับ

ดังนั้นสตรีมเก่าจึงหมดเวลา ขณะที่การเชื่อมต่อใหม่ไปยังบริการเดียวกันทำงานทันที ทั้งสองข้อสังเกตเป็นจริงในเวลาเดียวกัน

เซิร์ฟเวอร์เห็นอะไรเมื่อทางออกเปลี่ยน

การเชื่อมต่อ TCP ถูกระบุด้วยสี่ส่วนของมัน และการเปลี่ยนที่อยู่หรือพอร์ตต้นทางทำให้เกิดการเชื่อมต่ออื่นจากมุมมองของโฮสต์ที่รับ แพ็กเก็ตที่มาจากต้นทางใหม่บนการเชื่อมต่อที่เซิร์ฟเวอร์ไม่รู้จักจะถูกทิ้งหรือตอบกลับด้วยการรีเซ็ต ไม่มีสิ่งใดในที่อยู่ของไคลเอนต์ VPN ที่รักษาความสัมพันธ์ข้ามการเปลี่ยนแปลงนั้น

failover แบบมีสถานะมีอยู่เพื่อหลีกเลี่ยงปัญหานี้ และทำงานโดยแลกเปลี่ยนสถานะการแปลงและสถานะการเชื่อมต่อระหว่างอุปกรณ์ส่งต่อ คุณลักษณะนี้เป็นของคู่ ไม่ใช่ของอุโมงค์ และต้องออกแบบและทดสอบ ไม่ใช่สันนิษฐาน

ตรวจสอบว่าคู่นั้นเก็บสถานะจริงหรือไม่ก่อนสัญญาความต่อเนื่องกับใคร คำสั่งด้านล่างแสดงสถานะปัจจุบันทั้งสองฝั่ง

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

ทำไมที่อยู่สาธารณะเดียวกันจึงไม่เพียงพอ

การคงที่อยู่สาธารณะหนึ่งชุดบนทั้งสองเส้นทางเป็นจุดเริ่มต้นที่ดี เพราะเซิร์ฟเวอร์จะเห็นปลายทางต้นทางเดียวกัน แต่เพียงลำพังยังไม่พอ อุปกรณ์ส่งต่อยังต้องการสถานะการแปลง สถานะไฟร์วอลล์ และเส้นทางกลับที่ใช้งานได้ และสิ่งเหล่านี้ต้องมีอยู่บนอุปกรณ์ที่รับส่งข้อมูลหลังการสลับ

RFC 3022 อธิบายการแปลงที่อยู่และถือว่าการแลกเปลี่ยนสถานะระหว่างอุปกรณ์ที่แปลงเป็นส่วนหนึ่งของการออกแบบสำรอง ที่อยู่แบบลอยหรือโปรไฟล์ที่คัดลอกย้ายการตั้งค่าโดยไม่ย้ายสถานะ

ด้วยเหตุนี้การทดสอบที่เพียง ping ผ่านตัวสำรองจึงพิสูจน์ได้น้อยมาก ping ไม่มีสถานะการเชื่อมต่อให้สูญเสีย

ตัดสินใจว่าข้อกำหนดแข็งแกร่งเพียงใด

หากผู้ใช้เชื่อมต่อใหม่ได้หลังเกิดความล้มเหลว การออกแบบคือการออกแบบกู้คืน และการทดสอบการยอมรับคือคำขอใหม่ หากการถ่ายโอนไฟล์ต้องรอด การออกแบบต้องมีการซิงโครไนซ์สถานะและการทดสอบที่ละเอียดกว่ามาก หากเซสชันระยะไกลต้องรอด ข้อกำหนดจะแข็งแกร่งยิ่งขึ้นและอาจต้องใช้กลไกระดับแอปพลิเคชันแทนระดับเครือข่าย

เขียนข้อกำหนดเป็นประโยคที่มีผลลัพธ์ที่วัดได้ เช่น การอัปโหลดเสร็จโดยไม่เริ่มใหม่ หรือผู้ปฏิบัติงานเชื่อมต่อใหม่ภายในหนึ่งนาที จากนั้นเลือกกลไกที่ถูกที่สุดที่ตอบสนองข้อกำหนด และนั่นมักเป็นการออกแบบกู้คืน

ระบุอย่างชัดเจนว่าเกิดอะไรขึ้นเมื่อเส้นทางหลักกลับมา เพราะการกลับอัตโนมัติอาจตัดการเชื่อมต่อที่เพิ่งกู้คืนบนตัวสำรอง กรณีนั้นอยู่ในแผนทดสอบ ไม่ใช่เชิงอรรถ

ตรวจสอบสตรีมเก่าและคำขอใหม่

เริ่มการถ่ายโอนยาวที่ไม่เป็นอันตรายผ่านเส้นทางหลัก จากนั้นส่งคำขอใหม่แยกต่างหากไปยังบริการเดียวกัน บันทึกบริบทของแอปพลิเคชัน ที่อยู่ทางออกที่สังเกตได้ และเวลา ตัดเส้นทางหลักด้วยวิธีที่ได้รับอนุมัติ และเฝ้าดูการถ่ายโอนเดิมต่อไปขณะส่งคำขอใหม่ผ่านตัวสำรอง

รายงานสามค่า: สตรีมเก่าดำเนินต่อ ถูกวีเซ็ต หรือหมดเวลา คำขอใหม่ทำงานครั้งแรกเมื่อใด และการกลับมาตัดอะไรหรือไม่ สามบรรทัดนั้นคือบันทึกการยอมรับ

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

หากภาระงานเขียนข้อมูล อย่าทำการดำเนินการที่ไม่แน่นอนซ้ำอย่างสุ่มสี่สุ่มห้าหลังหมดเวลา การเขียนอาจไปถึงก่อนคำตอบจะหายไป ถามแอปพลิเคชันถึงผลลัพธ์ หรือลองใหม่เฉพาะที่การดำเนินการเป็นแบบ idempotent จากนั้นเขียนถ้อยแถลงการยอมรับเป็นสามส่วน: การดำเนินการใหม่กู้คืนภายใต้นโยบายทางออก สตรีมที่มีอยู่มีพฤติกรรมการตัดที่บันทึกไว้ และแอปพลิเคชันกลับมาทำงานอย่างปลอดภัย ถ้อยแถลงนั้นทดสอบได้ และซื่อสัตย์เกี่ยวกับสิ่งที่การออกแบบไม่ได้สัญญา