รีสตาร์ต OpenVPN ทุกวันหรือไม่? เลือกความล้มเหลว ไม่ใช่นาฬิกา
การรีสตาร์ตตามปฏิทินคือการบำรุงรักษา ไม่ใช่การกู้คืน ตัดสินใจว่าเพียร์ กระบวนการ หรือแอปพลิเคชันล้มเหลว แล้วให้ทริกเกอร์ที่ชั้นนั้นต้องการ
คุณได้รับงาน cron ที่รีสตาร์ต OpenVPN ทุกวันเวลา 04:10 และมันรักษาความเสถียรมาหนึ่งปีแล้ว แต่มันก็ตัดการเชื่อมต่ออุโมงค์ที่ดีในเวลาคงที่ และไม่ทำอะไรกับการล่มที่เกิดขึ้นจริงตอนเที่ยง การรีสตาร์ตตามปฏิทินเป็นการตัดสินใจด้านการบำรุงรักษา การกู้คืนคือการออกแบบอีกแบบที่มีทริกเกอร์เฉพาะ
รูปแบบความล้มเหลวสามแบบต้องมีเจ้าของสามคนต่างกัน เลือกความล้มเหลวก่อน แล้วกลไกจะตามมา
สามความล้มเหลว สามเจ้าของ
อุโมงค์อาจทำงานอยู่ทั้งที่เพียร์หายไป กระบวนการทำงาน อินเทอร์เฟซมีอยู่ และไม่มีอะไรที่มีประโยชน์ผ่านเข้ามา กระบวนการอาจตายทั้งที่เพียร์ปกติดี และในกรณีนั้นมีเพียงสิ่งที่เริ่มมันเท่านั้นที่พากลับมาได้ แอปพลิเคชันหลังอุโมงค์อาจเสียทั้งที่อุโมงค์และเพียร์แข็งแรงดี และการรีสตาร์ตไคลเอนต์ตอนนั้นจะขยายขอบเขตการล่มโดยไม่แตะสาเหตุ การแยกสามกรณีนี้คือการตัดสินใจทั้งหมด
แต่ละอย่างมีสัญญาณและเจ้าของของตัวเอง ความมีชีวิตเป็นของโปรโตคอล VPN วัฏจักรชีวิตของกระบวนการเป็นของผู้จัดการบริการ และสุขภาพของแอปพลิเคชันเป็นของการเฝ้าระวังที่มีอำนาจจำกัด
ตัวเลือกด้านความมีชีวิตทำได้และทำไม่ได้อะไร
keepalive เป็นตัวช่วยที่ขยายเป็นคู่ ping และ ping-restart ตามที่เอกสารอ้างอิงตัวเลือกการเชื่อมต่ออธิบาย และเวลาหมดเวลาที่มันสร้างขึ้นไม่เหมือนกันบนเซิร์ฟเวอร์และไคลเอนต์ ค่าที่เซิร์ฟเวอร์ผลักมาสามารถเขียนทับสิ่งที่ไคลเอนต์ตั้งค่าไว้ในเครื่องได้เช่นกัน จึงเป็นเหตุให้เวลาหมดเวลาที่ดูถูกต้องในไฟล์ในเครื่องอาจไม่ใช่ตัวที่บังคับใช้
นั่นทำให้มันเป็นเครื่องมือที่ถูกต้องสำหรับเพียร์ที่หายไป และเป็นเครื่องมือที่ผิดสำหรับกระบวนการที่ตาย เพราะกระบวนการที่จบไปแล้วไม่สามารถรันตัวจับเวลาของตัวเองได้ มันยังไม่พูดอะไรเกี่ยวกับว่าแอปพลิเคชันหลังอุโมงค์ตอบสนองหรือไม่ เพราะการแลกเปลี่ยนเกิดขึ้นระหว่างปลายทั้งสองของ VPN การคัดลอกคู่เวลาหมดเวลาจากการติดตั้งอื่นโดยไม่ตรวจสอบบทบาท การหยุดชะงักที่คาดไว้ และพฤติกรรมการยืนยันตัวตนซ้ำ คือทางที่อุโมงค์ที่เสถียรเริ่มสั่น
ผู้จัดการบริการเป็นเจ้าของอะไร
ถ้าเดมอนออกไป ผู้จัดการที่เริ่มมันจะตัดสินใจว่าอะไรจะเกิดขึ้นต่อไป นโยบายรีสตาร์ตที่อิงกับความล้มเหลว พร้อมความล่าช้าและขีดจำกัดอัตราการเริ่ม จะจัดการลูปการพังโดยไม่ทำให้กลายเป็นฟอร์กบอมบ์ การตั้งค่าเหล่านั้นตอบสนองต่อผลลัพธ์ของกระบวนการและเวลาหมดเวลา และไม่ตรวจจับกระบวนการที่ยังมีชีวิตแต่ไร้ประโยชน์ นั่นไม่ใช่ช่องว่างที่ต้องปะด้วยนโยบายที่กว้างขึ้น มันคือเส้นแบ่งระหว่างวัฏจักรชีวิตกับความมีชีวิต
ความเป็นเจ้าของสำคัญพอ ๆ กับการตั้งค่า การเชื่อมต่อที่เริ่มโดยผู้จัดการเครือข่ายบนเดสก์ท็อปควรคงการจัดการกู้คืนของผู้จัดการนั้นไว้ และการเพิ่มยูนิตบริการที่แข่งขันกันสำหรับอินเทอร์เฟซเดียวกันทำให้อุโมงค์หนึ่งมีเจ้าของสองคน เลือกหนึ่งและเขียนว่าเป็นอันไหน
เมื่อใดการรีสตาร์ตตามกำหนดจึงชอบด้วยเหตุผล
การรีสตาร์ตตามเวลาเป็นการบำรุงรักษาที่สมเหตุสมผลได้ เพราะมีเจ้าของ มีหน้าต่างเวลา มีอินสแตนซ์ที่ตั้งชื่อ และมีทางเข้าที่เป็นอิสระ สิ่งที่มันเป็นไม่ได้คือ นโยบายความน่าเชื่อถือทั่วไปที่ตัดทุกคนออกในเวลาคงที่
ถ้าการรีสตาร์ตมีอยู่เพื่อหลีกเลี่ยงการรั่วไหลที่รู้อยู่แล้วหรือสถานะที่ค้างอยู่ ให้ระบุไว้ในคำอธิบายของยูนิต ไม่งั้นคนถัดไปจะเก็บมันไว้ตลอดไป
ทดสอบกรณีที่สำคัญ เพียร์หายไปในขณะที่กระบวนการยังทำงาน กระบวนการจบออกไป การลองใหม่ต้องใช้ข้อมูลรับรองใหม่ และอุโมงค์กลับมาในขณะที่แอปพลิเคชันยังเสียอยู่ ดูว่าองค์ประกอบใดตอบสนองและทิ้งสถานะอะไรไว้
คำถามที่ถูกต้องไม่ใช่รีสตาร์ตบ่อยแค่ไหน แต่คืออะไรควรสังเกตเห็นความล้มเหลวก่อน