ฉันมีเบลด multipath IO ที่กำหนดค่าเซิร์ฟเวอร์ 2012 ที่แสดงคำเตือนต่อไปนี้ในระหว่างเส้นทาง MPIO ล้มเหลว:
การดำเนินการ IO ที่โลจิคัลบล็อกแอดเดรส 0 สำหรับดิสก์ 7 ถูกลองใหม่
ฉันรู้ว่าสิ่งที่ทำให้เกิดการเตือนเกิดขึ้นดังนั้นฉันไม่ได้มองหาสาเหตุ แต่ข้อความนี้หมายถึงอะไรจริง?
มันหมายความว่าหาก IO นี้เป็นการดำเนินการเขียนแล้วเซิร์ฟเวอร์สูญเสียข้อมูลที่พยายามเขียน?
ขอบคุณสำหรับแสงที่คุณสามารถหลั่งบนความหมายของข้อความเตือนนี้
คำตอบ:
ไม่ไม่ได้หมายความว่าข้อมูลสูญหาย มันหมายความว่าหมดเวลาของ IRP (IO Request Packet) ในขณะที่ระบบ IO รอให้มันเสร็จสมบูรณ์และลองอีกครั้ง เมื่อเธรดเริ่มต้นการดำเนินการ IO ตัวจัดการ IO จะสร้าง IRP เพื่อแสดงการดำเนินการที่ผ่านเข้ามาในระบบ
IRP ได้รับการจัดเก็บในสถานะเริ่มต้นในรายการบัฟเฟอร์ / ดูด้านข้างเพื่อให้สามารถลองใหม่ได้หากล้มเหลวในครั้งแรก นั่นทำให้อะตอมมีความคาดหวังจากระบบการทำธุรกรรมใด ๆ เพื่อให้เรามั่นใจมากขึ้นว่าคุณจะไม่ได้รับข้อมูลที่เสียหายหรือไม่สมบูรณ์เขียนลงดิสก์ของคุณ
เหตุการณ์นี้เหมาะสมอย่างยิ่งในกรณีที่ MPIO เกิดความล้มเหลว สมมติว่า Windows ไปอ่านหรือเขียนข้อมูลจากที่เก็บข้อมูล SAN คำขอถูกส่งและในเวลาเดียวกันฉันก็ตัดสายเคเบิลหนึ่งสายไปยัง SAN คำขอนั้นจะไม่เสร็จสมบูรณ์และดังนั้น Windows จะลองคำขออีกครั้งคราวนี้คำขอจะเป็นไปตามเส้นทางอื่น
เหตุการณ์เหล่านี้เกิดขึ้นเมื่อดิสก์มีภาระมากเกินไปหรือช้ามาก คุณอาจสังเกตเห็นข้อความเหล่านี้ตรงกับการสำรองข้อมูลตามกำหนดเวลา ฯลฯ ดิสก์อาจช้าและไม่ว่างและ IRP แบบสุ่มหมดเวลาและต้องลองอีกครั้ง IRP อาจติดค้างอยู่ในรูทีนการบริการขัดจังหวะหรือการเรียกโพรซีเดอร์ที่เลื่อนออกไปหรืออะไรก็ตาม
ฉันเห็นว่ามีไดรเวอร์ตัวกรอง IO จำนวนมากในสแต็กของคุณที่ทำให้ปัญหานี้รุนแรงขึ้นเช่นกัน
ไม่ใช่ว่าพฤติกรรมนี้ไม่ได้เกิดขึ้นเช่นนี้ใน Windows รุ่นก่อนหน้า แต่เป็นเพียงว่า Microsoft ตัดสินใจที่จะแสดงเหตุการณ์เหล่านี้ใน Win8 / Server 2012
แก้ไข:คุณสามารถค้นหา IRP ที่ค้างอยู่ของเธรดด้วยเคอร์เนลดีบักเกอร์: kd> !irp 1a2b3c4dซึ่งก่อนหน้านี้คุณพบที่อยู่นั้นโดยการออกคำสั่งkd> !process 8f7d6c4aซึ่งจะแสดงรายการ IRP ทั้งหมดที่เกี่ยวข้องกับเธรดที่เชื่อมโยงกับกระบวนการนั้น kd> !process 0 0เพื่อแสดงรายการกระบวนการทั้งหมดที่กำลังทำงาน
เมื่อคุณแสดงรายการข้อมูลเกี่ยวกับ IRP โดยใช้คำสั่ง! irp คุณสามารถเห็นได้อย่างง่ายดายว่าไดรเวอร์ตัวใดที่จัดการกับ IRP ล่าสุดเพราะมันจะมีตัว>ชี้ไปที่รายการ จากนั้นเมื่อต้องการรับข้อมูลเพิ่มเติมเกี่ยวกับสิ่งที่โปรแกรมควบคุมนั้นทำกับ IRP นั้นให้ทำkd> !devobj 1a2b3c4d5e6fที่ซึ่งเป็นที่อยู่จริงของวัตถุอุปกรณ์
จากนั้นทำการkd> dt 0x1a2b3c3c2b1a _CLASS_PRIVATE_FDO_DATAใช้ที่อยู่ของโครงสร้าง PrivateFdoData ที่คุณได้รับ
ตอนนี้คุณพร้อมที่จะถ่ายโอนโครงสร้างข้อมูล AllTransferPacketsList ที่คุณได้รับจาก PrivateFdoData
แนวคิดก็คือคุณกำลังติดตามสิ่งที่คนขับทำกับ IRP ในครั้งล่าสุดที่เห็น หาก IRP เป็น AWOL นานเกินไปก็จะหมดเวลาและลองใหม่ตั้งแต่ต้น สิ่งนี้อาจเกิดจากหลายสิ่ง ... แม้แต่รังสีคอสมิคจรจัด แต่สิ่งสำคัญคือการทำธุรกรรมจะถูกลองใหม่ตั้งแต่ต้นและจะไม่ถูกพิจารณาว่าเสร็จสมบูรณ์จนกว่าผู้จัดการ IO จะกล่าวว่าเป็น
Oh, และยังมีด้ายไม่เชื่อเรื่องพระเจ้า IO ซึ่งเป็นสมบูรณ์สามารถที่แตกต่างกันของเวิร์ม :)
สำหรับการอ่านเพิ่มเติมในหัวข้อนี้ฉันขอแนะนำบทที่ 8 ระบบ I / O ของ Windows Internals 6th edition จาก Mark Russinovich, Margosis และอื่น ๆ
** แก้ไข: ** ในที่สุดฉันก็พบ KB อย่างเป็นทางการสำหรับข้อผิดพลาดนี้: http://support.microsoft.com/kb/2819485/EN-US
การดำเนินการ IO ควรลองใหม่ 8 ครั้งครั้งต่อนาทีจนกว่า Windows จะหมด
แก้ไข: ตามที่สัญญาไว้: http://blogs.msdn.com/b/ntdebugging/archive/2013/04/30/interpreting-event-153-errors.aspx
ไม่จะมีข้อความอื่นและ (หวังว่า) หนึ่งในเลเยอร์แอปพลิเคชันจะส่งข้อยกเว้นหากไม่สามารถบันทึกข้อมูลได้สำเร็จ
ก่อนถึง Windows Server 2012 (หรือโปรแกรมแก้ไขด่วน 2819485 หากใน Windows Server 2008 R2) ระบบจะลองอีกครั้งโดยไม่ต้องลงมือเมื่อเกิดการหมดเวลาเหล่านี้ วัตถุประสงค์ของข้อความคือเพื่อเพิ่มการมองเห็นเกี่ยวกับเหตุการณ์เหล่านี้ อาจบ่งบอกถึงปัญหาด้านความจุหรือข้อบกพร่องของไดรเวอร์และในกรณีของ iSCSI ข้อบกพร่องของระบบปฏิบัติการอื่นอาจทำให้เกิดความล่าช้า
ในกรณีของที่เก็บข้อมูลภายนอก (ไม่ใช่ที่ต่อพ่วงโดยตรง) ผู้ขายบางรายในอดีตได้เพิ่มค่าการหมดเวลาเช่น 60 วินาที อย่างไรก็ตามด้วยจำนวนครั้งเริ่มต้นของการลองใหม่โดยส่วนประกอบเลเยอร์ที่สูงขึ้นเช่นตัวเริ่มต้น iSCSI นี่อาจหมายความว่าหลายนาทีผ่านไปก่อนที่ระบบจะเริ่มการเฟลโอเวอร์ เห็นได้ชัดว่าจะเป็นพฤติกรรมที่ไม่เหมาะสม
ข้อมูลมากกว่านี้:
รายการรีจิสทรีสำหรับไดรเวอร์มินิพอร์ต SCSI
http://msdn.microsoft.com/en-us/library/windows/hardware/ff563970%28v=vs.85%29.aspx
Microsoft ได้เปิดตัวการปรับปรุงที่ให้ความสามารถในการระบุขีด จำกัด สำหรับการดำเนินงาน storport.sys
หลังจากที่คุณติดตั้งโปรแกรมปรับปรุงนี้คุณสามารถบันทึกเหตุการณ์เมื่อเวลาแฝงสำหรับ I / O ไปยังที่เก็บข้อมูลเท่ากับหรือมากกว่าขีด จำกัด ผู้ใช้สามารถตั้งค่าเกณฑ์ได้ การดำเนินการนี้จะดำเนินการในระดับไดรเวอร์ของอะแดปเตอร์เพื่อให้คุณสามารถดูว่ามีปัญหาเรื่องประสิทธิภาพของ SAN หรือไม่ จากนั้นคุณสามารถติดต่อผู้จัดจำหน่ายที่จัดเก็บเพื่อแก้ไขปัญหา
หมายเหตุ:โปรแกรมปรับปรุงนี้จะเรียกคืนฟังก์ชันการทำงานที่มีให้ใน Windows 7 และ Windows Server 2008 R2 เมื่อเปิดใช้งานฟังก์ชันการทำงานค่าขีด จำกัด จะถูกวัดใน 100 นาโนวินาที (0.0001 มิลลิวินาที) นอกจากนี้ค่าต่อไปนี้ถูกบันทึกไว้ในเหตุการณ์:
BuildIoDuration : ระยะเวลาที่ MINIPORT ใช้ในฟังก์ชั่น build I / O สำหรับคำขอนี้ StartIoDuration : ระยะเวลาที่ MINIPORT ใช้ในฟังก์ชั่นเริ่มต้น I / O สำหรับคำขอนี้ DataTransferLength : ขนาดของการถ่ายโอนเป็นไบต์
การปรับปรุงที่ปรับปรุงความสามารถในการบันทึกของไดรเวอร์ Storport.sys ใน Windows Server 2012
http://support.microsoft.com/kb/2819476
การปรับปรุงสะสม Windows 8 และ Windows Server 2012: เมษายน 2013
http://support.microsoft.com/kb/2822241
อาจเป็นการโพสต์ล่าช้า แต่ฉันพบว่าอาจเกิดจาก VSS เรามีลูกค้าที่ใช้ veeam แต่ลืมปิด windows server back up (ดิสก์ถูกลบ) มันทำให้เกิดปัญหาในการโหลดและปัญหานี้เป็นข้อผิดพลาดหลัก
หยุดการสำรองข้อมูลและ wham ไม่มีข้อผิดพลาด