วิธีทดสอบการอ่าน/เขียนเครือข่ายแบบอัตโนมัติ?

ฉันมีการตั้งค่าต่อไปนี้:

ฉันมีลูกค้าที่ใช้ซอฟต์แวร์ที่ "เขียนโดยใช้ Windows API มาตรฐานสำหรับอ่านและเขียน" ที่กำลังอ่านและเขียนไฟล์ไปยังเซิร์ฟเวอร์ Windows ลูกค้าเป็นเครื่อง Windows 10 ทั้งหมดและทั้งหมดใช้ซอฟต์แวร์ vault ที่เรียกว่า PDM จาก Solidworks

เซิร์ฟเวอร์เป็นเซิร์ฟเวอร์ Windows 2016 ที่ใช้ซอฟต์แวร์เซิร์ฟเวอร์ PDM

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

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

ตามที่คนสนับสนุนห้องนิรภัย "95% ของเวลาปัญหาเหล่านี้เกิดขึ้นกับเซิร์ฟเวอร์หรือเครือข่าย ไม่ใช่ซอฟต์แวร์เซิร์ฟเวอร์ห้องนิรภัย"

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

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

• บนเครื่องไคลเอนต์ #1 สร้างไฟล์ (ที่มีเนื้อหาแบบสุ่ม?) และบันทึกลงในเซิร์ฟเวอร์ ในเวลาเดียวกัน ให้คำนวณผลรวมตรวจสอบ (เช่น md5sum?) สำหรับแต่ละไฟล์ทดสอบ และอาจเพิ่มผลรวม แถวแล้วแถวเล่า ลงใน "ไฟล์ดัชนีการส่งมอบผลรวม" บนเซิร์ฟเวอร์เดียวกัน

• บนเครื่องไคลเอ็นต์ #2 ให้โหลดไฟล์ทีละไฟล์จากเซิร์ฟเวอร์ และคำนวณผลรวมตรวจสอบ จริงๆ แล้ว คุณสามารถเรียกใช้เครื่องมือตรวจสอบผลรวม เช่น md5sum ในแต่ละไฟล์บนเครือข่ายที่แมปร่วมกัน (จากเครื่องไคลเอนต์ #2) และเปรียบเทียบเช็คซัมกับสิ่งที่เครื่องต้นทางผลิตขึ้น

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

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

นอกเหนือจาก "diff" แบบคลาสสิกซึ่งใช้ได้กับข้อความ ASCII แล้ว ฉันจำได้ มีเครื่องมือเฉพาะสำหรับการเปรียบเทียบแบบไบนารี.

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

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

ผู้คนกล่าวว่านี่คือจุดประสงค์ของฮาร์ดแวร์จัดเก็บข้อมูลระดับองค์กรที่รักษา "ความสมบูรณ์ของข้อมูลเมตา" ตลอด "ห่วงโซ่สัญญาณ" นั่นคือ SCSI เวอร์ชันทันสมัยและเทคโนโลยีการเชื่อมต่อระหว่างกัน (FC, SAS) และระดับสนิมที่สอดคล้องกัน ไม่แน่ใจ หากมี SSD ที่มีความสามารถดังกล่าว แทนที่จะให้ตัวชี้เฉพาะ ฉันขอแนะนำให้คุณ ถาม google เกี่ยวกับความสมบูรณ์ของข้อมูลใน Linux. โอกาสที่นี่คือสิ่งที่กัดคุณในระดับฮาร์ดแวร์คุณรู้เกี่ยวกับระบบย่อยการจัดเก็บข้อมูลพื้นฐานของคุณในเซิร์ฟเวอร์มากแค่ไหน?

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

บันทึกโดย "ขั้นตอนการโหลดด้วยมือที่น่าเบื่อ" - นั่นคืออะไรกันแน่? อัลกอริธึมการกู้คืนบางอย่างทำงานกับไฟล์ที่เสียหรือไม่ หรือเพียงแค่ดึงไฟล์ต้นฉบับที่สมบูรณ์จากข้อมูลสำรองเก่าที่สอดคล้องกัน ทั้งสองกรณีมีศักยภาพในการค้นหาข้อมูลเพิ่มเติมเกี่ยวกับลักษณะของปัญหา: คุณจะสามารถเปรียบเทียบไฟล์ที่เสียกับไฟล์ต้นฉบับที่ดี หรืออาจเรียนรู้ว่ากระบวนการ "กู้คืน" ทำอะไรกับไฟล์ที่ "เสียหาย" .