การแก้ไขปัญหาเวลาหน่วงแฝงบน datastores ESXi


44

ฉันพบ fsync latencies ประมาณห้าวินาทีใน NFS datastores ใน ESXi ซึ่งถูกทริกเกอร์โดย VMs บางตัว ฉันสงสัยว่าอาจเกิดจาก VM ที่ใช้ NCQ / TCQ เนื่องจากสิ่งนี้ไม่ได้เกิดขึ้นกับไดรฟ์ IDE เสมือน

นี้สามารถทำซ้ำโดยใช้fsync-ทดสอบ (โดยเท็ด Ts'o) และioping ตัวอย่างเช่นการใช้ระบบถ่ายทอดสด Grml กับดิสก์ 8GB:

Linux 2.6.33-grml64:
root@dynip211 /mnt/sda # ./fsync-tester
fsync time: 5.0391
fsync time: 5.0438
fsync time: 5.0300
fsync time: 0.0231
fsync time: 0.0243
fsync time: 5.0382
fsync time: 5.0400
[... goes on like this ...]

นั่นคือ 5 วินาทีไม่ใช่มิลลิวินาที นี่คือการสร้าง IO-latencies บน VM ที่แตกต่างกันที่ทำงานบนโฮสต์และที่เก็บข้อมูลเดียวกัน :

root@grml /mnt/sda/ioping-0.5 # ./ioping -i 0.3 -p 20 .
4096 bytes from . (reiserfs /dev/sda): request=1 time=7.2 ms
4096 bytes from . (reiserfs /dev/sda): request=2 time=0.9 ms
4096 bytes from . (reiserfs /dev/sda): request=3 time=0.9 ms
4096 bytes from . (reiserfs /dev/sda): request=4 time=0.9 ms
4096 bytes from . (reiserfs /dev/sda): request=5 time=4809.0 ms
4096 bytes from . (reiserfs /dev/sda): request=6 time=1.0 ms
4096 bytes from . (reiserfs /dev/sda): request=7 time=1.2 ms
4096 bytes from . (reiserfs /dev/sda): request=8 time=1.1 ms
4096 bytes from . (reiserfs /dev/sda): request=9 time=1.3 ms
4096 bytes from . (reiserfs /dev/sda): request=10 time=1.2 ms
4096 bytes from . (reiserfs /dev/sda): request=11 time=1.0 ms
4096 bytes from . (reiserfs /dev/sda): request=12 time=4950.0 ms

เมื่อฉันย้าย VM แรกไปยังที่จัดเก็บในตัวเครื่องมันดูปกติดี:

root@dynip211 /mnt/sda # ./fsync-tester
fsync time: 0.0191
fsync time: 0.0201
fsync time: 0.0203
fsync time: 0.0206
fsync time: 0.0192
fsync time: 0.0231
fsync time: 0.0201
[... tried that for one hour: no spike ...]

สิ่งที่ฉันพยายามทำนั้นไม่ได้ทำให้แตกต่าง:

  • ทดสอบ ESXi Builds หลายรายการ: 381591, 348481, 260247
  • ทดสอบกับฮาร์ดแวร์ที่แตกต่างกันกล่อง Intel และ AMD ที่แตกต่างกัน
  • ทดสอบกับเซิร์ฟเวอร์ NFS ที่แตกต่างกันทั้งหมดแสดงพฤติกรรมเดียวกัน:
    • OpenIndiana b147 (ซิงค์ ZFS ทุกครั้งหรือปิดใช้งาน: ไม่มีความแตกต่าง)
    • OpenIndiana b148 (ซิงค์ ZFS ทุกครั้งหรือปิดใช้งาน: ไม่มีความแตกต่าง)
    • Linux 2.6.32 (ซิงค์หรือ async: ไม่แตกต่างกัน)
    • ไม่สร้างความแตกต่างหากเซิร์ฟเวอร์ NFS อยู่บนเครื่องเดียวกัน (เป็นอุปกรณ์จัดเก็บข้อมูลเสมือน) หรือบนโฮสต์อื่น

Guest OS ทดสอบแล้วแสดงปัญหา:

  • Windows 7 64 บิต (โดยใช้ CrystalDiskMark ความล่าช้าจะเกิดขึ้นในระหว่างการเตรียมการ)
  • Linux 2.6.32 (fsync-tester + ioping)
  • Linux 2.6.38 (fsync-tester + ioping)

ฉันไม่สามารถทำซ้ำปัญหานี้บน Linux 2.6.18 VMs

วิธีแก้ปัญหาอื่นคือการใช้ดิสก์ IDE เสมือน (vs SCSI / SAS) แต่นั่นเป็นการ จำกัด ประสิทธิภาพและจำนวนไดรฟ์ต่อ VM

อัปเดต 2011-06-30:

หน่วงเวลาในการแฝงดูเหมือนจะเกิดขึ้นบ่อยครั้งหากแอปพลิเคชันเขียนในบล็อกเล็ก ๆ หลาย ๆ อันก่อน fsync ตัวอย่างเช่น fsync-tester ทำสิ่งนี้ (เอาต์พุตแบบสเตรซ):

pwrite(3, "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"..., 1048576, 0) = 1048576
fsync(3)                                = 0

ioping ทำสิ่งนี้ขณะเตรียมไฟล์:

[lots of pwrites]
pwrite(3, "********************************"..., 4096, 1036288) = 4096
pwrite(3, "********************************"..., 4096, 1040384) = 4096
pwrite(3, "********************************"..., 4096, 1044480) = 4096
fsync(3)                                = 0

ขั้นตอนการตั้งค่าของ ioping เกือบตลอดเวลาในขณะที่ fsync-tester ทำงานได้ดีในบางครั้ง มีใครบางคนที่สามารถอัพเดท fsync-tester เพื่อเขียนบล็อคเล็ก ๆ หลาย ๆ อันได้หรือไม่? ทักษะ C ของฉันดูด;)

อัปเดต 2011-07-02:

ปัญหานี้ไม่ได้เกิดขึ้นกับ iSCSI ฉันลองสิ่งนี้กับเซิร์ฟเวอร์ OpenIndiana COMSTAR iSCSI แต่ iSCSI ไม่ให้คุณเข้าถึงไฟล์ VMDK ได้ง่ายดังนั้นคุณสามารถย้ายไฟล์เหล่านี้ระหว่างโฮสต์ด้วยสแนปชอตและ rsync

อัปเดต 2011-07-06:

นี่เป็นส่วนหนึ่งของการจับภาพแบบ wireshark ซึ่งถูกจับโดย VM ตัวที่สามบน vSwitch เดียวกัน ทั้งหมดนี้เกิดขึ้นในโฮสต์เดียวกันไม่มีเครือข่ายทางกายภาพที่เกี่ยวข้อง

ฉันเริ่มทำ ioping ประมาณเวลา 20 ไม่มีการส่งแพ็กเก็ตจนกว่าการหน่วงเวลาห้าวินาทีจะจบลง:

No.  Time        Source                Destination           Protocol Info
1082 16.164096   192.168.250.10        192.168.250.20        NFS      V3 WRITE Call (Reply In 1085), FH:0x3eb56466 Offset:0 Len:84 FILE_SYNC
1083 16.164112   192.168.250.10        192.168.250.20        NFS      V3 WRITE Call (Reply In 1086), FH:0x3eb56f66 Offset:0 Len:84 FILE_SYNC
1084 16.166060   192.168.250.20        192.168.250.10        TCP      nfs > iclcnet-locate [ACK] Seq=445 Ack=1057 Win=32806 Len=0 TSV=432016 TSER=769110
1085 16.167678   192.168.250.20        192.168.250.10        NFS      V3 WRITE Reply (Call In 1082) Len:84 FILE_SYNC
1086 16.168280   192.168.250.20        192.168.250.10        NFS      V3 WRITE Reply (Call In 1083) Len:84 FILE_SYNC
1087 16.168417   192.168.250.10        192.168.250.20        TCP      iclcnet-locate > nfs [ACK] Seq=1057 Ack=773 Win=4163 Len=0 TSV=769110 TSER=432016
1088 23.163028   192.168.250.10        192.168.250.20        NFS      V3 GETATTR Call (Reply In 1089), FH:0x0bb04963
1089 23.164541   192.168.250.20        192.168.250.10        NFS      V3 GETATTR Reply (Call In 1088)  Directory mode:0777 uid:0 gid:0
1090 23.274252   192.168.250.10        192.168.250.20        TCP      iclcnet-locate > nfs [ACK] Seq=1185 Ack=889 Win=4163 Len=0 TSV=769821 TSER=432716
1091 24.924188   192.168.250.10        192.168.250.20        RPC      Continuation
1092 24.924210   192.168.250.10        192.168.250.20        RPC      Continuation
1093 24.924216   192.168.250.10        192.168.250.20        RPC      Continuation
1094 24.924225   192.168.250.10        192.168.250.20        RPC      Continuation
1095 24.924555   192.168.250.20        192.168.250.10        TCP      nfs > iclcnet_svinfo [ACK] Seq=6893 Ack=1118613 Win=32625 Len=0 TSV=432892 TSER=769986
1096 24.924626   192.168.250.10        192.168.250.20        RPC      Continuation
1097 24.924635   192.168.250.10        192.168.250.20        RPC      Continuation
1098 24.924643   192.168.250.10        192.168.250.20        RPC      Continuation
1099 24.924649   192.168.250.10        192.168.250.20        RPC      Continuation
1100 24.924653   192.168.250.10        192.168.250.20        RPC      Continuation

ปรับปรุงครั้งที่ 2 2011-07-06:

ดูเหมือนว่าจะมีอิทธิพลบางอย่างจากขนาดหน้าต่าง TCP ฉันไม่สามารถทำซ้ำปัญหานี้โดยใช้ FreeNAS (ตาม FreeBSD) เป็นเซิร์ฟเวอร์ NFS การจับภาพ wireshark แสดงการอัพเดทหน้าต่าง TCP เป็น 29127 ไบต์ในช่วงเวลาปกติ ฉันไม่เห็นพวกเขาด้วย OpenIndiana ซึ่งใช้ขนาดหน้าต่างที่ใหญ่กว่าเป็นค่าเริ่มต้น

ฉันไม่สามารถสร้างปัญหานี้ได้อีกต่อไปหากฉันตั้งค่าตัวเลือกต่อไปนี้ใน OpenIndiana และรีสตาร์ทเซิร์ฟเวอร์ NFS:

ndd -set /dev/tcp tcp_recv_hiwat 8192 # default is 128000
ndd -set /dev/tcp tcp_max_buf 1048575 # default is 1048576

แต่สิ่งนี้ทำให้ประสิทธิภาพการทำงานลดลง: การเขียนจาก / dev / ศูนย์ไปยังไฟล์ที่มี dd_rescue เริ่มจาก 170MB / s ถึง 80MB / s

อัปเดต 2011-07-07:

ฉันได้อัปโหลดการจับภาพ tcpdumpนี้(สามารถวิเคราะห์ด้วย wireshark) ในกรณีนี้ 192.168.250.2 เป็นเซิร์ฟเวอร์ NFS (OpenIndiana b148) และ 192.168.250.10 เป็นโฮสต์ ESXi

สิ่งที่ฉันทดสอบระหว่างการจับภาพนี้:

เริ่มต้น "ioping -w 5 -i 0.2." ในเวลา 30, 5 วินาทีในการตั้งค่าแขวนเสร็จในเวลา 40

เริ่มต้น "ioping -w 5 -i 0.2." ในเวลา 60, 5 วินาทีในการตั้งค่าแขวนเสร็จในเวลา 70

เริ่ม "fsync-tester" ในเวลา 90 ด้วยผลลัพธ์ต่อไปนี้หยุดที่เวลา 120:

fsync time: 0.0248
fsync time: 5.0197
fsync time: 5.0287
fsync time: 5.0242
fsync time: 5.0225
fsync time: 0.0209

ปรับปรุงครั้งที่ 2 2011-07-07:

ทดสอบ VM เซิร์ฟเวอร์ NFS อื่นแล้วคราวนี้ NexentaStor 3.0.5 community edition: แสดงปัญหาเดียวกัน

อัปเดต 2011-07-31:

ฉันยังสามารถจำลองปัญหานี้ได้ใน ESXi บิลด์ใหม่ 4.1.0.433742


12
ฉันต้องบอกว่ามันเป็นเวลานานแล้วที่ผู้ใช้ใหม่เอี่ยมมาถึงบอร์ดด้วยคำถามที่มีเอกสารและความคิดที่ดี - จริงจังกับคุณ มันน่าสนใจอย่างแท้จริงเช่นกันฉันไม่เคยเจอ fsync-tester มาก่อนเลยขอบคุณ ที่กล่าวว่าฉันไม่แน่ใจว่าฉันมีอะไรที่จะเพิ่มคุณได้ลองหลายสิ่งหลายอย่างที่ฉันจะมีอยู่แล้ว - ฉันจะพูดกับ VMWare ด้วยความซื่อสัตย์พวกเขาเก่งในเรื่องนี้มาก ของ 'long-tail' / 'ไม่ใช่การหยุดให้บริการจริง' อย่างจริงจัง อย่างไรก็ตามเพียงแค่อยากจะบอกว่าทำได้ดีในสิ่งที่คุณได้ทำเพื่อให้ห่างไกล :)
Chopper3

น่าเสียดายที่เว็บไซต์ VMware จะไม่ให้ฉันติดต่อพวกเขา: "คุณไม่มีสิทธิ์สนับสนุนที่ใช้งานอยู่"
exo_cw

อาใช่ว่าจะเป็นปัญหาแน่นอน ...
Chopper3

3
หมดเวลา 5 วินาทีด้วย NFS ฟังดูคุ้นเคย ใน linux NFS มีการหมดเวลาเป็นวินาทีที่ 7 สำหรับ RPC ที่เพิ่มขึ้นสองเท่าหลังจากความล้มเหลวแต่ละครั้งและดึงค่าหลักหลังจาก 3 ล้มเหลว (การตั้งค่าเริ่มต้น) .7 + 1.4 + 2.8 = 4.9 วินาที มีปัญหาการรับรองความถูกต้อง RPC ที่หลากหลายซึ่งอาจทำให้เกิดปัญหานี้
Mark

2
@Ryan: ฉันได้อัปโหลดไฟล์จับภาพแล้ว ฉันได้อัปโหลดเอาต์พุต nfsstatด้วย
exo_cw

คำตอบ:


5

ดูเหมือนว่าปัญหานี้จะได้รับการแก้ไขใน ESXi 5 ฉันได้ทดสอบการสร้าง 469512 ด้วยความสำเร็จ


3

ขอบคุณ nfsstat ดูดี ฉันได้ตรวจสอบการจับกุม ยังไม่พบข้อสรุปใด ๆ แต่พบสิ่งที่น่าสนใจ ฉันกรองใน tcp.time_delta> 5. สิ่งที่ฉันพบในทุกกรณีล่าช้าคือการเริ่มต้นการเรียก RPC ที่แน่นอน ไม่ใช่การเรียก RPC ใหม่ทั้งหมดที่เกิดขึ้นช้า แต่การชะลอตัวทั้งหมดเกิดขึ้นเมื่อเริ่มต้นการโทร RPC อย่างแน่นอน นอกจากนี้จากการดักจับปรากฏว่า 192.168.250.10 มีความล่าช้าทั้งหมด 192.168.250.2 ตอบกลับคำขอทั้งหมดทันที

ผลการวิจัย:

  • ความล่าช้าจะเกิดขึ้นเสมอในแพ็กเก็ตแรกของการโทร RPC
  • ชนิดคำสั่ง NFS ไม่สัมพันธ์กับการหน่วงเวลาอินสแตนซ์
  • Fragmentation = ความล่าช้าในการแพ็คเก็ตแรกเท่านั้น

Write Call ขนาดใหญ่สามารถแบ่งออกเป็น 300 TCP แพ็กเก็ตแต่ละอันและอันแรกเท่านั้นที่จะล่าช้า แต่ส่วนที่เหลือทั้งหมดบินผ่าน ความล่าช้าจะไม่เกิดขึ้นที่ตรงกลาง ฉันไม่แน่ใจว่าขนาดของหน้าต่างอาจส่งผลต่อการเริ่มต้นของการเชื่อมต่อได้อย่างมาก

ขั้นตอนถัดไป: ฉันจะเริ่ม tweaking ตัวเลือก NFS เช่น NFSSVC_MAXBLKSIZE ลงแทนที่จะเป็นหน้าต่าง TCP นอกจากนี้ฉันสังเกตเห็นว่า 2.6.18 ทำงานได้ในขณะที่ 2.6.38 ไม่ ฉันรู้ว่ามีการเพิ่มการสนับสนุนสำหรับไดรเวอร์ VMXnet3 ในช่วงเวลานั้น คุณใช้ไดรเวอร์ NIC รุ่นใดในโฮสต์ TCP ถ่ายใช่ / ไม่ใช่? รอบเครื่องหมาย 95 วินาทีมีแพ็กเก็ต TCP มากกว่า 500 แพ็กสำหรับการเรียก NFS Write เดียว อะไรก็ตามที่อยู่ในความดูแลของ TCP และการเลิก PDU ขนาดใหญ่อาจเป็นสิ่งที่บล็อก


ฉันลองตั้งค่า nfs: nfs3_max_transfer_size, nfs: nfs3_max_transfer_size_cots และ nfs: nfs3_bsize ทั้งหมดจนถึง 8192: ไม่แตกต่างปัญหาเดียวกัน แขกลินุกซ์เพียงแค่ใช้ SCSI / SAS- ดิสก์ของพวกเขาไม่มี NFS - ESXi เป็นไคลเอนต์ NFS ดังนั้นจึงไม่มีปัญหาไดรเวอร์เครือข่ายในแขกลินุกซ์ ในฝั่งเซิร์ฟเวอร์ NFS ฉันได้ลองทั้ง e1000 เสมือนและ vmxnet3: สร้างความแตกต่าง เท่าที่ฉันรู้ ESXi ใช้ TCP offloading สำหรับ iSCSI เท่านั้น
exo_cw

ใหญ่ที่สุด ? ฉันมีเหตุผลที่ปรับหน้าต่าง TCP จะสร้างความแตกต่าง ... ลำไส้ของฉันบอกฉันมันเป็นสิ่งที่จะทำอย่างไรกับการแยกส่วน PDU ขนาดใหญ่เหล่านั้นผ่าน TCP มีบางอย่างในสแต็กเครือข่ายที่สำลัก แค่คิดไม่ออกว่าอะไรจะเหมาะกับพฤติกรรมที่เราเห็น หากขนาดของหน้าต่างเป็นปัญหาเราควรเห็นแบนด์วิดท์ที่ จำกัด เวลาแฝงในระหว่างการถ่ายโอนข้อมูลขนาดใหญ่ไม่ใช่จุดเริ่มต้น แต่เป็นแพ็กเก็ตแรกของการเรียก RPC เสมอ
Ryan

2

ฉันมีสิ่งที่ดูเหมือนว่าปัญหาเดียวกันโดยใช้ ESXi4.1U1 และ CentOS VM ของ โฮสต์คือ Dell R610s ที่เก็บข้อมูลเป็นคลัสเตอร์ EMC2 Isilon

คุณมีโอกาสใช้ VLANS ไหม? ฉันพบว่าใช้ VLAN บนพอร์ต VMkernel สำหรับหน่วยเก็บข้อมูลทำให้เกิด 'แฮงค์' 4000-5000ms สำหรับปริมาณการเก็บข้อมูลทั้งหมดบน VMHost อย่างไรก็ตามถ้าฉันย้าย VMkernel พอร์ตออกจาก VLAN เพื่อให้ได้รับแพ็คเก็ตที่ไม่มีแท็กฉันไม่เห็นปัญหา

การตั้งค่าอย่างง่ายด้านล่างจะทำให้เกิดปัญหาในเครือข่ายของฉัน:

1) ติดตั้ง ESXi 4.1U1 บนเซิร์ฟเวอร์หรือเวิร์กสเตชัน (ทั้งคู่แสดงปัญหาเมื่อฉันลอง)

2) เพิ่มพอร์ต VMkernel บน VLAN

3) เพิ่ม NFS Datastore (ของฉันอยู่บน VLAN เดียวกันนั่นคือ Isilon ได้รับแพ็กเก็ตที่ติดแท็ก)

4) ติดตั้ง 2 CentOS 5.5 VM's หนึ่งเครื่องที่มี ioping

5) Boot VM's เข้าสู่โหมดผู้ใช้คนเดียว (เช่นไม่มีเครือข่ายบริการขั้นต่ำ)

6) เรียกใช้ ioping บนเครื่องเดียวดังนั้นมันจึงเขียนไปยังดิสก์เสมือน

7) เรียกใช้ dd หรือ somesuch บนเครื่องอื่นเพื่อเขียนข้อมูล 100MB ไปยัง / tmp หรือคล้ายกัน

บ่อยครั้งที่ฉันไม่เห็น VM ของทั้งคู่หยุดนิ่งประมาณ 4-5 วินาที

มีความสนใจจริง ๆ เพื่อดูว่าคนอื่นเห็นคล้ายกัน


ยินดีต้อนรับสู่ Server Fault! นี่เป็นคำถามเก่า หากคำตอบของมันไม่ได้ช่วยให้คุณโดยตรงแล้วคุณควรจะถามคำถามใหม่ใหม่โดยคลิกที่ถามคำถามปุ่ม
user9517 รองรับ GoFundMonica

ใช่แน่นอนฉันใช้แท็ก VLAN ในขณะที่ฉันกำลังใช้พวกเขาทุกที่ฉันไม่เคยคิดเลยว่าพวกเขาจะเป็นแหล่งที่มาของปัญหานี้ ฉันจะพยายามทำซ้ำบนพอร์ตที่ไม่มีแท็ก
exo_cw

ฉันสามารถทำซ้ำปัญหานี้บนพอร์ตที่ไม่มีแท็กได้เช่นกันไม่มี VLAN ที่เกี่ยวข้องกับโฮสต์นั้นเลย
exo_cw

ฉันเพิ่งลองอีกครั้งและดูปัญหาบนพอร์ตที่ไม่ได้ติดแท็กด้วยเช่นกันมันเป็นความถี่ที่น้อยกว่าเล็กน้อยบางทีนั่นอาจเป็นสาเหตุที่ฉันพลาดไป ขออภัยสำหรับ bum-steer ฉันไม่เห็นปัญหาใน Win7 64 บิตโดยใช้ iometer บวกกับดูเหมือนว่าฉันสามารถเรียกดูไดรฟ์ c: ในขณะที่ linux vms อื่นแขวนอยู่ ฉันจะลองใช้คริสตัลดิสมาร์ค
นิค

ที่จริงฉันสนใจที่จะเห็นผลลัพธ์ของคุณด้วย iometer ใน win7 x64 มันวัดความหน่วง แต่ภาพรวมสูงสุดที่ฉันได้รับคือ 300ms โดยใช้การทดสอบการอ่าน 4k ไม่ใช่ 4000 + ms
Nick

2

เรามีปัญหาเดียวกันนี้เมื่อสองสัปดาห์ก่อน ESX41 U1 และ Netapp FAS3170 + NFS Datastores RHEL5 VMs หยุดทำงานเป็นเวลา 2 หรือ 4 วินาทีและเราเห็นหนามสูงมากจากคอนโซลประสิทธิภาพของ Virtual Center

ฉันขอให้คนที่แต่งตัวประหลาดเครือข่ายเพื่อตรวจสอบการกำหนดค่าและปัญหาคือในสวิตช์ของซิสโก้เรามีสองลิงค์อีเธอร์เน็ตที่ได้รับการกำหนดค่าใน Etherchannel ในด้าน Netapp และไม่ได้อยู่ในด้านของซิสโก้ เขาสร้าง Ethechannel แบบสแตติกบน cisco และตอนนี้ก็ทำงานได้ดี ในการระบุปัญหาประเภทนี้ให้ปิดพอร์ตทั้งหมดยกเว้นพอร์ตที่อยู่ระหว่างตัวกรองและสวิตช์ ปล่อยให้พอร์ตเดียวยังมีชีวิตอยู่และดูว่าสิ่งต่าง ๆ เกิดขึ้นอย่างไร

สิ่งที่สองที่เราทำคือลบ Flow Control บน switcj และ filer เพราะเราสงสัยว่ามันจะส่งเฟรมหยุดชั่วคราว


1

DNS ของคุณมีลักษณะอย่างไร เป็นของคุณ/etc/resolv.confถูกต้องหรือไม่ การหมดเวลาเริ่มต้นคือ 5 วินาที

จาก man resolv.conf

timeout:n
                 sets the amount of time the  resolver  will  wait  for  a
                 response  from  a  remote name server before retrying the
                 query via a different name server.  Measured in  seconds,
                 the default is RES_TIMEOUT (currently 5, see <resolv.h>).

ลองท้ายtimeout:3ที่คุณ/etc/resolv.confและเรียกใช้การทดสอบ fsync ของคุณอีกครั้ง


ฉันพยายามเพิ่มสิ่งนี้บนเซิร์ฟเวอร์ NFS (OpenIndiana ในกรณีนี้) และในโฮสต์ ESXi น่าเสียดายที่นี่ไม่ได้สร้างความแตกต่าง ฉันสามารถแก้ไข IP ของเซิร์ฟเวอร์ & แขกได้ดี
exo_cw

ดูเหมือนว่าคุณกรองปริมาณการใช้งานทั้งหมดที่ไม่เกี่ยวข้องกับสตรีม nfs เราอาจต้องดูเพิ่มเติม
โทนี่โร ธ

@tony roth: จริง ๆ แล้วนั่นคือการจราจรทั้งหมดในเวลานั้น ฉันทดสอบว่าใน vSwitch แยกกันโดยมีเพียงโฮสต์และเซิร์ฟเวอร์ NFS ในนั้น
exo_cw

คุณสามารถถ่ายโอน DNS ด้วย wireshark ได้ไหม
โจเซฟเคอร์น

@Joseph Kern: ฉันเพิ่งวิเคราะห์ไฟล์แคปเจอร์อีกครั้ง: ไม่มีการรับส่งข้อมูล DNS เลยระหว่างการจับ ที่เก็บข้อมูล NFS ถูกแม็พโดย IP บนโฮสต์ ESXi DNS ทำงานได้ดีบน ESXi และเซิร์ฟเวอร์ NFS ฉันทดสอบการค้นหาไปข้างหน้า & ย้อนกลับของ IP ที่เกี่ยวข้องทั้งหมด ตอนนี้ฉันไม่มีเหตุผลที่จะเชื่อว่า DNS เป็นสาเหตุของเรื่องนี้
exo_cw

1

การเข้าใจที่ straws ที่นี่ แต่คุณใช้ NIC ในเซิร์ฟเวอร์เหล่านี้คืออะไร กองซ้อนล้น sysadmins มีปัญหาเครือข่ายแปลกกับ Broadcom NICs ที่หายไปเมื่อพวกเขาเปลี่ยนเป็น Intel NICs: http://blog.serverfault.com/post/broadcom-die-mutha/


การทดสอบล่าสุดทำใน vSwitch เท่านั้นไม่มีเครือข่ายทางกายภาพที่เกี่ยวข้อง (e1000 และ vmxnet3: ไม่มีความแตกต่าง) แต่ฉันยังได้ทดสอบสิ่งนี้กับ Intel 82574L, Intel 82576 และ Intel 82567LF-3 ทั้งหมดแสดงปัญหา ฉันไม่พบฮาร์ดแวร์ใด ๆ แต่ฉันไม่สามารถทำซ้ำได้
exo_cw

1

นี่คืออีกเดา ... IPv6 ของคุณเปิดใช้งานบนโฮสต์ EXS หรือไม่ ถ้าใช่แล้วลองปิดมันสิ จากประสบการณ์ของฉันหากเครือข่ายทั้งหมดของคุณไม่ได้รับการกำหนดค่าอย่างเหมาะสมสำหรับ IPv6 (เช่น RADV, DHCP6, DNS, DNS ย้อนกลับ) อาจเป็นปัญหาสำหรับบริการบางอย่าง นอกจากนี้ตรวจสอบให้แน่ใจว่ามันถูกปิดบนเซิร์ฟเวอร์ NFS


IPv6 ถูกปิดใช้งานแล้วบนโฮสต์ ESXi ฉันปิดการใช้งาน IPv6 บนเซิร์ฟเวอร์ NFS (ifconfig -a6 ว่างเปล่าตอนนี้) แต่ก็ไม่ได้สร้างความแตกต่าง: มันแสดงให้เห็นปัญหาเดียวกัน
exo_cw
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.