NFS เบื้องหลัง VPN: เมานต์ตอนบูตหรือเมานต์อัตโนมัติเมื่อมีการเรียกใช้?
การเมานต์ตอนบูตจะติดขัดกับอุโมงค์ที่อาจยังไม่ขึ้น การเมานต์อัตโนมัติจะรอการเข้าถึงครั้งแรก และการพึ่งพา VPN ควรอยู่ที่ยูนิตเมานต์ ไม่ใช่ตัวกระตุ้น
การกำหนดค่าสองแบบแก้ปัญหาเดียวกันและล้มเหลวในทิศทางตรงกันข้าม การเมานต์แชร์ตอนบูตทำให้ทุกบริการได้ระบบไฟล์ที่มีอยู่จริงหรือมีเหตุผลว่าทำไมการบูตจึงหยุดชะงัก การเมานต์อัตโนมัติเมื่อมีการเรียกใช้ทำให้เครื่องบูตเร็วและยกภาระการรอให้กับผู้ที่แตะเส้นทางเป็นคนแรก เบื้องหลัง VPN วิธีที่สองมักเป็นการแลกเปลี่ยนที่ดีกว่า และเหตุผลคืออุโมงค์บังคับลำดับที่ลำดับการบูตมองไม่เห็น
การเมานต์ตอนบูตเทียบกับการเมานต์อัตโนมัติ
การเมานต์ตอนบูตนั้นเข้าใจง่าย เป้าหมายของระบบไฟล์รอการเมานต์ บริการที่ประกาศการพึ่งพามันจะเริ่มหลังจากนั้น และถ้าเข้าถึงเซิร์ฟเวอร์ไม่ได้ เครื่องจะรอหรือล้มเหลวขึ้นอยู่กับตัวเลือก ทุกสิ่งปลายน้ำสืบทอดการตัดสินใจครั้งเดียวนั้น
การเมานต์อัตโนมัติกลับกัน เส้นทางมีอยู่ทันที การเมานต์จริงเกิดขึ้นเมื่อมีบางอย่างเปิดมัน และบริการที่เริ่มต้นเร็วจะไม่ติดขัดกับอุโมงค์ที่ยังไม่ขึ้น
การเปรียบเทียบลงเอยที่ว่าใครควรแบกความล่าช้า สถานีงานที่ต้องการแชร์ก่อนผู้ใช้จะทำงานได้น่าจะควรรอ แล็ปท็อปที่บูตในกระเป๋า หรือเซิร์ฟเวอร์ที่แชร์เป็นทางเลือก ไม่ควรรอ
ไม่มีตัวเลือกใดซ่อมเส้นทางที่หายไป ทั้งสองเพียงตัดสินว่าเมื่อใดจะสังเกตเห็นความล้มเหลว
บรรทัด fstab ทีละตัวเลือก
สมมติว่าอินสแตนซ์ไคลเอนต์ OpenVPN ที่มีอยู่คือ [email protected] เซิร์ฟเวอร์คือ files.corp.example และจุดเมานต์คือ /mnt/work แทนที่ทั้งสามด้วยค่าที่ได้รับอนุญาตจากไซต์ของคุณเอง บรรทัดที่ใช้งานได้หน้าตาแบบนี้:
files.corp.example:/export/work /mnt/work nfs _netdev,nofail,x-systemd.automount,[email protected],x-systemd.mount-timeout=30s 0 0
_netdev ทำเครื่องหมายการเมานต์ว่าต้องการเครือข่าย และไม่ได้ระบุอุโมงค์ใดเลย nofail ทำให้แชร์เป็นทางเลือกสำหรับเป้าหมายระบบไฟล์ปกติ x-systemd.automount สร้างตัวกระตุ้นเมื่อมีการเรียกใช้แทนการเมานต์ทันที
x-systemd.requires= คือส่วนที่ผูกความพยายามเมานต์กับยูนิต VPN และมันเป็นของการดําเนินการเมานต์ ไม่ใช่ตัวกระตุ้น การวางลําดับกว้างๆ บนยูนิตเมานต์อัตโนมัติเองคือวิธีที่ผู้คนสร้างวงจรซึ่ง systemd จะบ่นในภายหลังด้วยภาษาที่ไม่มีใครอ่านสองครั้ง
x-systemd.mount-timeout=30s จำกัดคำสั่งเมานต์เริ่มต้น มันไม่ได้จำกัดสิ่งใดที่เกิดขึ้นหลังจากนั้น และนี่คือความเข้าใจผิดที่พบบ่อยที่สุดเกี่ยวกับตัวเลือกนี้
สิ่งที่ «เริ่มแล้ว» ไม่ได้หมายถึง
ตรวจสอบว่า การเป็นแอ็กทิฟหมายถึงอะไร สำหรับยูนิต VPN ที่คุณระบุ บริการอุโมงค์สามารถรายงานตนเองว่าเริ่มแล้วก่อนที่เส้นทางไปยังเซิร์ฟเวอร์ไฟล์จะมีอยู่ หรือก่อนที่ชื่อส่วนตัวจะถูกแปลง และการเรียงลำดับหลังจากนั้นก็ไม่ได้ประโยชน์อะไร ช่องว่างนี้คือที่อยู่ของเกือบทุกความพยายามที่ล้มเหลว มันยังมองไม่เห็นเว้นแต่คุณจะดูเส้นทางและตัวแปลงชื่อแทนสถานะของยูนิต
ใช้สัญญาณความพร้อมของเจ้าของการเชื่อมต่อเองเป็นข้อกำหนดเบื้องต้นเพิ่มเติมในที่ที่มีอยู่ การนอนหลับแบบคงที่เป็นการเดาที่ได้ผลบนโต๊ะของคุณและล้มเหลวบนเครือข่ายที่ช้ากว่าหรือหลังการเชื่อมต่อใหม่
ตรวจสอบยูนิตที่สร้างขึ้นสำหรับเส้นทางในตัวอย่าง: mnt-work.automount และ mnt-work.mount หลังจากแก้ไข fstab ที่ผ่านการตรวจสอบแล้ว ให้โหลด systemd ใหม่และจัดการยูนิตเหล่านั้นโดยตรงแทนการเรียกคำสั่งเมานต์แบบเหมารวมที่ฝึกฝนรายการที่ไม่เกี่ยวข้อง
มีข้อควรระวังอีกข้อหนึ่งที่นี่ บริการที่แตะ /mnt/work ตอนเริ่มยังคงกระตุ้นการเมานต์และยังคงรอมัน ดังนั้นการทำเครื่องหมายแชร์เป็นทางเลือกไม่ได้ทำให้ทุกแอปพลิเคชันอดทน
หลังการเมานต์ ความล้มเหลวเป็นอีกแบบหนึ่ง
เมื่อ NFS ถูกเมานต์แล้ว พฤติกรรมการลองใหม่และการกู้คืนของระบบไฟล์จะเป็นตัวกำหนดว่าเหตุขัดข้องในภายหลังจะทำอะไรกับการอ่านหรือการเขียน หมดเวลาเมานต์ที่คุณตั้งไว้ไม่มีอิทธิพลต่อสิ่งนั้น
การเมานต์แบบซอฟต์ย่อการรอบางส่วนและเปลี่ยนความหมายของข้อผิดพลาด พร้อมผลต่อความสมบูรณ์ของข้อมูลที่มองข้ามได้ง่ายเมื่อเป้าหมายคือการบูตที่เร็วขึ้น การเลือกมันเพื่อแลกกับสองวินาทีของการเริ่มต้นไม่ค่อยเป็นการแลกเปลี่ยนที่ดี หากข้อกำหนดคือการดำเนินการที่มีขอบเขตระหว่างเหตุขัดข้องจริงๆ นั่นคือการตัดสินใจระดับแอปพลิเคชัน ไม่ใช่แฟล็ก fstab
ตัดสินใจว่าจะเกิดอะไรขึ้นกับโปรเซสที่กำลังเขียนอยู่เมื่ออุโมงค์ล่ม แล้วจดไว้ คำตอบนั้นมีประโยชน์กว่าสตริงตัวเลือกใดๆ
ทดสอบสี่สถานะ ไม่ใช่หนึ่ง
การบูตปกติเมื่ออุโมงค์พร้อมใช้งานเป็นกรณีง่ายและพิสูจน์แทบไม่ได้เลย มันยืนยันว่าสตริงเขียนถูกต้องและไม่มีอะไรมากกว่านั้น ทดสอบการเข้าถึงครั้งแรกโดยไม่มี VPN จากนั้นการกู้คืนเมื่อมันขึ้น จากนั้นเหตุขัดข้องที่ควบคุมได้หลังการเมานต์สำเร็จ
สี่สถานะ สี่การสังเกต และบันทึกจะอยู่ข้างรายการ fstab คนถัดไปจะสืบทอดพฤติกรรมแทนการกำหนดค่าที่ต้องย้อนรอยวิศวกรรม