OpenVPN keepalive หรือ systemd รีสตาร์ท: อันไหนกู้คืนได้?

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

ความล้มเหลวสามแบบที่ดูเหมือนแบบเดียว

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

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

จดสามกรณีไว้ก่อนเปลี่ยนตัวจับเวลาใด ๆ ตัวรายการเองมักแสดงว่ามีกลไกหนึ่งถูกขอให้ครอบคลุมทั้งสาม

keepalive ขยายออกมาเป็นอะไรจริง ๆ

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

การเพิ่มเป็นสองเท่านั้นคือเหตุผลที่คำอธิบายใด ๆ ที่กล่าวว่าทั้งสองฝั่งรีสตาร์ทหลังหกสิบวินาทีนั้นผิด มันยังอธิบายว่าทำไมสองฝั่งไม่กระพริบพร้อมกันเมื่อเส้นทางเสื่อมลง

heartbeat คือทราฟฟิกเพื่อนของ OpenVPN ไม่ใช่การตรวจ ICMP ไปยังโฮสต์สาธารณะใด ๆ การตอบกลับพิสูจน์เพียงว่าปลายไกลของอุโมงค์ยังมีชีวิตอยู่ มันไม่บอกอะไรเกี่ยวกับฐานข้อมูลหรือเว็บเซอร์วิสที่ผู้ใช้ต้องการจริง ๆ

สิ่งที่ Restart=on-failure ไม่ได้เฝ้าดู

อ่านยูนิตที่ติดตั้งไว้ก่อนเพิ่มการโอเวอร์ไรด์ Restart=on-failure ตอบสนองต่อเงื่อนไขความล้มเหลวของโพรเซสที่เขียนไว้ในเอกสาร ซึ่งไม่เหมือนกับการเฝ้าดูสถานะการเชื่อมต่อ มันไม่ทำงานเพราะการเชื่อมต่อใหม่ภายในเริ่มขึ้น และการออกอย่างสะอาดมีความหมายต่างจากการแครช

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

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

ping-restart กับ ping-exit ใช้แทนกันไม่ได้

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

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

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

ทดสอบแต่ละความล้มเหลวเป็นกรณีของตัวเอง

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

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