เหตุใดจึงต้องรอเวลามากกว่าสำหรับอุปกรณ์ DM multipath มากกว่าอุปกรณ์พื้นฐาน?


20

เรามีเซิร์ฟเวอร์ที่ใช้ CentOS 6.4 ซึ่งเชื่อมต่อกับที่เก็บข้อมูล Hitachi HNAS 3080 และสังเกตว่าเคอร์เนลติดตั้งระบบไฟล์ใหม่ในโหมดอ่านอย่างเดียว:

16 พฤษภาคม 07:31:03 เคอร์เนล GNS3-SRV-CMP-001: [1259725.675814] EXT3-fs (dm-1): ข้อผิดพลาด: การประกอบระบบไฟล์แบบอ่านอย่างเดียว

สิ่งนี้เกิดขึ้นหลังจากข้อผิดพลาด I / O หลายอย่างและเส้นทางทั้งหมดไปยังอุปกรณ์จะรายงานว่าลง:

16 พฤษภาคม 07:31:03 GNS3-SRV-CMP-001 หลายรายการ: mpatha: เส้นทางที่ใช้งานที่เหลืออยู่: 0

ฉันดูบันทึก sar และสามารถดูใหญ่มาก (2 วินาที) รอเวลา:

07:40:00       dev8-0     17.91    112.04     98.03     11.73      0.00      0.20      0.07      0.12
07:40:00      dev8-16      0.23      1.85      0.00      8.00      0.00      3.71      3.71      0.09
07:40:00      dev8-32     91.50   8338.76   5292.93    148.98      8.38     91.60      9.76     89.35
07:40:00     dev252-0     91.27   8336.91   5292.93    149.34     17.79    194.88      9.79     89.38
07:40:00     dev252-1    674.80   8168.16   5292.93     19.95   1473.53   2183.60      1.32     88.98

ระยะเวลาระหว่าง 07: 30: 00-07: 40: 00 จะเกิดขึ้นเมื่อระบบไฟล์ถูกเมาท์แบบอ่านอย่างเดียว อย่างไรก็ตามแม้ภายใต้สภาวะปกติการสังเกตซ้ำ ๆ ครั้งหนึ่งก็คือเวลาที่รอคอยสำหรับอุปกรณ์พื้นฐานนั้นต่ำกว่าของอุปกรณ์มัลติพา ธ มาก ตัวอย่างเช่น

00:00:00          DEV       tps  rd_sec/s  wr_sec/s  avgrq-sz  avgqu-sz     await     svctm     %util
00:10:00       dev8-0     19.27    129.41     78.61     10.80      0.01      0.27      0.16      0.32
00:10:00      dev8-16      0.23      1.80      0.00      8.00      0.00      0.86      0.84      0.02
00:10:00      dev8-32     94.88  10285.16   3363.48    143.86      3.39     35.76      6.83     64.82
00:10:00     dev252-0     94.65  10283.34   3363.48    144.18      3.64     38.47      6.86     64.89
00:10:00     dev252-1    435.06  10087.12   3363.48     30.92    118.42    272.21      1.47     64.12

dev8-0 เกิดขึ้นเป็นโลคัลดิสก์ในขณะที่ dev8-16 ( /dev/sdb) และ dev8-32 ( /dev/sdc) เป็นพื้นฐานสำหรับ dev252-0 ( /dev/mapper/mpatha) dev252-1 ( /dev/mapper/mpathap1) เป็นพาร์ติชั่นเดียวที่ครอบคลุมอุปกรณ์ multipath ทั้งหมด นี่คือผลลัพธ์จากmultipath -ll:

mpatha (2521501cbffffffffe96773b50ec30020) dm-0 BlueArc,NAS Platform
size=10T features='0' hwhandler='0' wp=rw
|-+- policy='round-robin 0' prio=1 status=enabled
| `- 9:0:0:0 sdc 8:32 active ready running
`-+- policy='round-robin 0' prio=1 status=active
  `- 8:0:0:0 sdb 8:16 active ready running

ทำไมเวลารอควร/dev/mapper/mpathap1จะเป็นมากสูงกว่า/dev/mapper/mpathaหรือแม้กระทั่ง/dev/sdbหรือ/dev/sdc?


1
ดูเหมือนว่าน่าสังเกตว่าเห็นได้ชัดว่าเป็นจำนวนมากของการร้องขอการควบรวมที่เกิดขึ้นเกี่ยวกับวิธีการจากไป/dev/mapper/mpathap1 /dev/mapper/mpathaนี่เป็นเลเยอร์ที่awaitดูเหมือนว่าจะเพิ่มเวลาส่วนใหญ่ คุณสามารถตรวจสอบว่าลิฟต์ตัวใดที่ใช้อยู่/sys/block/mpathap1/queue/schedulerและ/sys/block/mpatha/queue/schedulerอาจจะเปลี่ยนเป็นdeadlineหรือnoopเพื่อเปรียบเทียบ
the-wabbit

I / O ตารางเวลาสำหรับmpatha( /sys/block/dm-0/queue/scheduler) เป็นnoopและว่าสำหรับmpathap1( /sys/block/dm-1/queue/scheduler) noneเป็น
pdp

4
ฉันสงสัยอย่างยิ่งว่าอัลกอริทึมการจัดคิว / การรวมของตัวตั้งเวลามีหน้าที่รับผิดชอบต่อความล่าช้า ฉันจะสลับ cfq ของอุปกรณ์ที่รองรับสำหรับ noop หรือ deadline เพื่อดูว่ามันเปลี่ยนแปลงอะไรหรือไม่ สิ่งนี้มีแนวโน้มที่จะไม่เกี่ยวข้องกับปัญหาของคุณในทุกเส้นทาง
the-wabbit

2
FWIW, ฉันได้สังเกตชนิดเดียวกันของพฤติกรรมในประเภทอื่น ๆ ของอุปกรณ์ mapper อุปกรณ์ - โดยเฉพาะกับสระว่ายน้ำ NSS การเขียนที่สามารถผสานได้จะมีการรอ (และคิวที่ยาวกว่า) บนdmอุปกรณ์มากกว่าบนอุปกรณ์ฟิสิคัลพื้นฐานขณะที่การร้องขอการอ่านและการเขียนโดยไม่ต้องทำการผสานจะไม่ได้รับผลกระทบ ฉันยังไม่ทราบว่านี่เป็นเพียงข้อผิดพลาดในการนำเสนอเนื่องจากวิธีการรอการคำนวณหรือเวลาตอบสนองที่ยืดเยื้อจริงเนื่องจากลักษณะของอัลกอริทึมการจัดคิว / การผสาน
the-wabbit

1
หนึ่งในสคริปต์ Systemtap IOอาจให้ข้อมูลเชิงลึกเพิ่มเติมแก่คุณเกี่ยวกับสิ่งที่เกิดขึ้น io_submit.stp, ioblktime.stp และ biolatency-nd.stp อาจเป็นจุดเริ่มต้นที่ดี
Kassandry

คำตอบ:


2

ในฐานะผู้ใช้ the-wabbit แนะนำให้มีการรวมคำขอที่เกิดขึ้น คุณจะเห็นว่าในคอลัมน์ avgrq-sz ขนาดคำขอเฉลี่ย - ซึ่งแสดงการเพิ่มขึ้นอย่างมีนัยสำคัญ

ตอนนี้ 'รอ' คือเวลาที่ใช้ในคิวรวมถึงเวลาที่ใช้ในการบริการคำขอเหล่านั้น หากมีคำขอเล็ก ๆ เรียกว่า 'x' ถูกรวมเข้ากับคำขออื่นสองสามรายการ (y และ z ออกหลังจาก x) จากนั้น x จะ

  • รอคิวที่จะรวมกับ y
  • รอในคิว tu ถูกรวมเข้ากับ z
  • รอ (x, y, z) ให้เสร็จ

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

ทีนี้ลองดูที่ / dev / sdb (dev8-16) คุณรู้หรือไม่ว่าคุณไม่ได้ใช้เส้นทางนั้น? คุณมีสองกลุ่มลำดับความสำคัญในการกำหนดค่าแบบหลายเส้นทางของคุณหนึ่งคือ

สถานะ = เปิดการใช้งาน

และบนคือ

สถานะ = ใช้งาน

คุณอาจจะมี

path_grouping_policy failover

ในการกำหนดค่าของคุณ (ซึ่งเป็นค่าเริ่มต้น)

หากคุณต้องการป้องกันข้อผิดพลาด IO ในกรณีที่ทั้งสองพา ธ ขัดข้องคุณสามารถลอง:

        คุณสมบัติ "1 queue_if_no_path"
ใน multipath.conf ของคุณ

ตอนนี้คำถามที่แท้จริงยังคงอยู่ทำไมทั้งสองเส้นทางลงไป?

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.