NFS บน TCP ภายในอุโมงค์ UDP ของ OpenVPN: การขนส่งสองชั้น
โปรโตคอลการเมานต์และโปรโตคอลอุโมงค์เป็นค่าตั้งแยกกัน บันทึกทั้งสองค่า แล้วจึงตัดสินว่าการหยุดชะงักเป็นของบริการไฟล์หรือของตัวขนส่ง
การขนส่งบทสนทนา NFS ที่ใช้ TCP ภายในอุโมงค์ที่ขนส่ง UDP นั้นสอดคล้องกันอย่างสมบูรณ์ และทำให้คนสับสนเพราะมันเอ่ยถึงการขนส่งสองแบบในเวลาเดียวกัน TCP คือบทสนทนาของบริการไฟล์ระหว่างไคลเอนต์กับเซิร์ฟเวอร์ NFS ส่วน UDP คือตัวขนส่งที่เข้ารหัสระหว่างปลายทั้งสองของ VPN ทั้งสองอย่างไม่ได้บ่งบอกอะไรเกี่ยวกับอีกอย่างหนึ่ง
จดบันทึกทั้งสองแยกกันก่อนจะเริ่มดีบั๊กสิ่งใด เพราะเหตุการณ์เหล่านี้ส่วนใหญ่เริ่มต้นเมื่อมีคนเปลี่ยนชั้นผิด
สองชั้น สองค่า
ตัวเลือกการเมานต์ proto=tcp อธิบายว่าไคลเอนต์ NFS พูดคุยกับเซิร์ฟเวอร์ NFS อย่างไร ส่วนค่า proto udp ในโปรไฟล์ VPN อธิบายว่าปลายอุโมงค์แลกเปลี่ยนแพ็กเก็ตที่ห่อหุ้มกันอย่างไร การเปลี่ยนตัวเลือกการเมานต์ไม่ได้เปลี่ยนอุโมงค์ และการเปลี่ยนการขนส่งของอุโมงค์ไม่ได้เปลี่ยนสิ่งที่ไคลเอนต์ NFS เจรจาไว้ ตรวจสอบตัวเลือกการเมานต์ที่ใช้จริงด้วย nfsstat -m แทนบรรทัดใน fstab และตรวจสอบการขนส่งของ VPN จากโปรไฟล์ที่ใช้อยู่จริง
จากนั้นบันทึกทั้งสองลงในบันทึกเหตุการณ์เป็นสองฟิลด์แยกกัน การปรับปรุงที่ดูเหมือนดีจะติดตามได้ก็ต่อเมื่อบันทึกระบุว่าเปลี่ยนชั้นใด
การเรียกดูไม่ใช่การอ่านจำนวนมาก
รายการไดเรกทอรีพิสูจน์ว่าบางการดำเนินการเสร็จสมบูรณ์ แต่ไม่ได้พิสูจน์ว่าการอ่านต่อเนื่อง การเขียน การล็อก หรือส่วนหลังของที่จัดเก็บจะเสร็จสมบูรณ์ภายใต้เงื่อนไขเดียวกัน การหยุดกลางไฟล์ขนาดใหญ่เป็นการสังเกตที่แตกต่างจากการเมานต์ที่ไม่เคยสำเร็จ และทั้งสองชี้ไปที่ชั้นที่แตกต่างกัน
อธิบายการดำเนินการที่ล้มเหลวอย่างแม่นยำ ทั้งพาธ ทิศทาง ตำแหน่งโดยประมาณของการหยุด และเหตุการณ์ที่เกี่ยวข้องล่าสุดในบันทึกของไคลเอนต์ เซิร์ฟเวอร์ และ VPN จากนั้นเปรียบเทียบว่าทราฟฟิกดำเนินต่อไปที่ใดและหยุดที่ใด
MTU เป็นสมมติฐาน ไม่ใช่การวินิจฉัย
การสูญหายที่ขึ้นกับขนาดแพ็กเก็ตเป็นไปได้จริงเมื่ออุโมงค์ขนส่งส่วนข้อมูลขนาดใหญ่ และก่อให้เกิดรูปแบบที่การเรียกดูทำงานแต่การอ่านหยุดชะงักพอดี รูปแบบนั้นไม่ได้พิสูจน์ปัญหา MTU อย่างไรก็ตาม เพราะรูปร่างเดียวกันปรากฏเมื่อเซิร์ฟเวอร์ช้า เมื่อไฟร์วอลล์ตัดการเชื่อมต่อที่ยาวนานด้วยการหมดเวลา หรือเมื่อดิสก์กำลังยุ่ง ทดสอบสมมติฐานด้วยการตรวจสอบที่ควบคุมได้ แทนที่จะลด MTU ทุกที่แล้วประกาศชัยชนะ
การหมดเวลาเพียงอย่างเดียวไม่ได้บอกอะไรว่าควรเปลี่ยน UDP หรือไม่ มันเป็นอาการที่มีเจ้าของได้หลายราย
เปลี่ยนตัวแปรทีละตัว
เมื่อเปรียบเทียบการขนส่ง ให้คงภาระงาน NFS และค่าตั้งอื่นทั้งหมดให้คงที่ การเปลี่ยนการขนส่งของการเมานต์ โปรโตคอลอุโมงค์ และ MTU ในช่วงบำรุงรักษาเดียวกันทำให้ได้ผลลัพธ์ที่ไม่มีใครระบุที่มาได้ ให้รันการดำเนินการไฟล์เดิมก่อนและหลัง และบันทึกผลในแต่ละขั้น
เก็บค่าก่อนหน้าไว้ในตั๋วด้วย หากการเปลี่ยนแปลงทำให้แย่ลง การย้อนกลับควรเป็นตัวเลขที่บันทึกไว้ ไม่ใช่ความทรงจำของใครว่าก่อนหน้านี้เป็นอย่างไร
อ่านชั้นที่ล้มเหลว
หากอุโมงค์ทำงานอยู่และคำขอ NFS กำลังรออยู่ แสดงว่า VPN ไม่ได้ล้มเหลว แต่บริการไฟล์ล้มเหลว หากอุโมงค์ล่ม การที่คำขอ NFS ล้มเหลวเป็นผลสืบเนื่อง ไม่ใช่สาเหตุ การจับคู่บรรทัดบันทึกจากทั้งสองชั้นเป็นวิธีที่เร็วที่สุดในการแยกสองกรณีนี้ และดีกว่าการเดาจากตัวจัดการไฟล์
เขียนข้อสรุปเป็นสองประโยค ประโยคละชั้น เท่านี้ก็เพียงพอให้คนถัดไปทำการทดสอบซ้ำโดยไม่ต้องอนุมานใหม่ว่าการขนส่งใดเป็นอันไหน