सवाल ESXi NFS डेटास्टोर पर विलंबता स्पाइक्स समस्या निवारण


मैं आसपास के fsync विलंबता का अनुभव कर रहा हूँ पांच सेकंड ईएसएक्सआई में एनएफएस डेटास्टोर पर, कुछ वीएम द्वारा ट्रिगर किया गया। मुझे संदेह है कि यह एनसीक्यू / टीसीक्यू का उपयोग कर वीएम के कारण हो सकता है, क्योंकि यह वर्चुअल आईडीई ड्राइव के साथ नहीं होता है।

इसका उपयोग करके पुन: उत्पन्न किया जा सकता है fsync-परीक्षक (टेड त्सो द्वारा) और ioping। उदाहरण के लिए एक 8 जीबी डिस्क के साथ एक जीआरएल लाइव सिस्टम का उपयोग कर:

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 सेकंड है, मिलीसेकंड नहीं। यह एक ही मेजबान और डेटास्टोर पर चल रहे एक अलग वीएम पर आईओ-लेटेंसीज भी बना रहा है:

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

जब मैं पहली वीएम को स्थानीय भंडारण में ले जाता हूं तो यह बिल्कुल सामान्य दिखता है:

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 बिल्डों का परीक्षण किया: 3815 9 1, 348481, 260247
  • विभिन्न हार्डवेयर, विभिन्न इंटेल और एएमडी बक्से पर परीक्षण किया
  • विभिन्न एनएफएस सर्वरों के साथ परीक्षण किया गया, सभी एक ही व्यवहार दिखाते हैं:
    • ओपन इंडियाना बी 147 (जेएफएस सिंक हमेशा या अक्षम: कोई फर्क नहीं पड़ता)
    • ओपन इंडियाना बी 148 (जेएफएस सिंक हमेशा या अक्षम: कोई फर्क नहीं पड़ता)
    • लिनक्स 2.6.32 (सिंक या एसिंक: कोई फर्क नहीं पड़ता)
    • अगर एनएफएस सर्वर एक ही मशीन (वर्चुअल स्टोरेज उपकरण के रूप में) या किसी भिन्न होस्ट पर है तो इससे कोई फर्क नहीं पड़ता

अतिथि ओएस परीक्षण, समस्याओं को दिखा रहा है:

  • विंडोज 7 64 बिट (क्रिस्टलडिस्कमार्क का उपयोग करके, विलंबता स्पाइक्स ज्यादातर तैयारी चरण के दौरान होता है)
  • लिनक्स 2.6.32 (fsync-tester + ioping)
  • लिनक्स 2.6.38 (fsync-tester + ioping)

मैं लिनक्स 2.6.18 वीएम पर इस समस्या को पुन: पेश नहीं कर सका।

वर्चुअल आईडीई डिस्क (बनाम एससीएसआई / एसएएस) का उपयोग करना एक और कामकाज है, लेकिन यह प्रदर्शन सीमित है और प्रति वीएम ड्राइव की संख्या सीमित है।

2011-06-30 अपडेट करें:

विलंबता स्पाइक्स अधिक बार होता है यदि एप्लिकेशन fsync से पहले कई छोटे ब्लॉक में लिखता है। उदाहरण के लिए fsync-tester यह करता है (स्ट्रेस आउटपुट):

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

फ़ाइल तैयार करते समय आईपिंग यह करता है:

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

आईपिंग का सेटअप चरण लगभग हमेशा लटकता है, जबकि fsync-tester कभी-कभी ठीक काम करता है। क्या कोई एकाधिक छोटे ब्लॉक लिखने के लिए fsync-tester को अद्यतन करने में सक्षम है? मेरे सी कौशल चूसना;)

अद्यतन 2011-07-02:

यह समस्या iSCSI के साथ नहीं होती है। मैंने इसे OpenIndiana COMSTAR iSCSI सर्वर के साथ करने की कोशिश की। लेकिन iSCSI आपको VMDK फ़ाइलों तक आसान पहुंच नहीं देता है ताकि आप उन्हें स्नैपशॉट्स और rsync के साथ होस्ट के बीच स्थानांतरित कर सकें।

अद्यतन 2011-07-06:

यह एक वायरसहार्क कैप्चर का हिस्सा है, जो एक ही वीएसविच पर तीसरे वीएम द्वारा कब्जा कर लिया गया है। यह सब एक ही होस्ट पर होता है, कोई भौतिक नेटवर्क शामिल नहीं होता है।

मैंने समय 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

दूसरा अपडेट 2011-07-06:

टीसीपी विंडो आकार से कुछ प्रभाव लगता है। मैं एनएफएस सर्वर के रूप में फ्रीएनएएस (फ्रीबीएसडी के आधार पर) का उपयोग करके इस समस्या को पुन: उत्पन्न करने में सक्षम नहीं था। वायरशर्क कैप्चर ने नियमित अंतराल में 2 9 127 बाइट्स को टीसीपी विंडो अपडेट दिखाए। मैंने उन्हें ओपनइंडियाना के साथ नहीं देखा, जो डिफ़ॉल्ट रूप से बड़े विंडो आकार का उपयोग करता है।

यदि मैं OpenIndiana में निम्न विकल्प सेट करता हूं और NFS सर्वर को पुनरारंभ करता हूं तो मैं अब इस समस्या को पुन: उत्पन्न नहीं कर सकता:

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

लेकिन यह प्रदर्शन को मारता है: dd_rescue के साथ / dev / zero से फ़ाइल में लिखना 170 एमबी / एस से 80 एमबी / एस तक जाता है।

अद्यतन 2011-07-07:

मैंने इसे अपलोड कर लिया है टीसीपीडम्प कैप्चर (वायरशर्क के साथ विश्लेषण किया जा सकता है)। इस मामले में 1 9 2.168.250.2 एनएफएस सर्वर (ओपन इंडियाना बी 148) और 1 9 2.168.250.10 ईएसएक्सआई होस्ट है।

इस कैप्चर के दौरान मैंने परीक्षण किया है:

शुरू किया "ioping -w 5 -i 0.2।" 30 समय पर, सेटअप में 5 सेकंड लटका, समय 40 पर पूरा हुआ।

शुरू किया "ioping -w 5 -i 0.2।" समय पर 60, सेटअप में 5 सेकंड लटका, समय 70 पर पूरा हुआ।

निम्नलिखित आउटपुट के साथ समय 90 पर "fsync-tester" शुरू किया, समय 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

दूसरा अपडेट 2011-07-07:

एक और एनएफएस सर्वर वीएम का परीक्षण किया, इस बार नेक्सेंटास्टोर 3.0.5 समुदाय संस्करण: एक ही समस्या दिखाता है।

अद्यतन 2011-07-31:

मैं इस समस्या को नए ESXi बिल्ड 4.1.0.433742 पर भी पुन: पेश कर सकता हूं।


44
2018-06-29 08:33


मूल


मुझे यह कहना है कि यह थोड़ी देर हो गया है क्योंकि एक नया उपयोगकर्ता इस तरह के एक अच्छी तरह से प्रलेखित और विचार-विमर्श प्रश्न के साथ बोर्ड में आया है - गंभीरता से, आपको सलाम करता है। यह वास्तव में भी दिलचस्प है, मैं आपको धन्यवाद देने से पहले fsync-tester में नहीं आया हूं। मैंने कहा कि मुझे यकीन नहीं है कि मुझे जोड़ने के लिए कुछ भी मिला है, आपने पहले से ही बहुत सी चीजों की कोशिश की है - मैं कहूंगा कि वीएमवेयर खुद को ईमानदार होने के लिए बोलें, वे इस तरह के लिए बहुत अच्छे हैं 'लंबी पूंछ' / 'वास्तविक सेवा आउटेज' सामग्री गंभीरता से नहीं। वैसे भी आप अभी तक जो कुछ भी किया है उस पर अच्छा कहना चाहते हैं :) - Chopper3
दुर्भाग्य से वीएमवेयर वेबसाइट मुझे उनसे संपर्क करने नहीं देगी: "आपके पास वर्तमान में कोई सक्रिय समर्थन एंटाइटेलमेंट नहीं है" - exo_cw
आह, हाँ, यह निश्चित रूप से एक समस्या हो सकती है ... - Chopper3
एनएफएस के साथ 5 सेकंड टाइमआउट परिचित लग रहा था। लिनक्स एनएफएस में आरपीसी के लिए एक .7 सेकंड टाइमआउट है जो प्रत्येक विफलता के बाद दोगुना हो जाता है और 3 विफल होने (डिफ़ॉल्ट सेटिंग्स) के बाद एक प्रमुख खींचता है। .7 + 1.4 + 2.8 = 4.9 सेकेंड। आरपीसी प्रमाणीकरण मुद्दों की एक विस्तृत विविधता है जो इसका कारण बन सकती है। - Mark
@ रयान: मैंने कैप्चर फ़ाइल अपलोड की है। मैंने भी अपलोड किया है nfsstat आउटपुट। - exo_cw


जवाब:


यह समस्या ESXi 5 में तय की गई है। मैंने सफलता के साथ 469512 निर्माण का परीक्षण किया है।


5
2017-09-13 06:54





धन्यवाद, nfsstat अच्छा लग रहा है। मैंने कैप्चर की समीक्षा की है। कुछ भी निर्णायक नहीं मिला है, लेकिन कुछ दिलचस्प पाया। मैं tcp.time_delta> 5 पर फ़िल्टर किया। मुझे क्या मिला हर एक देरी का उदाहरण आरपीसी कॉल की सटीक शुरुआत थी। सभी नए आरपीसी कॉल धीमे नहीं थे, लेकिन आरपीसी कॉल की सटीक शुरुआत में सभी मंदी हुई। साथ ही, कैप्चर से ऐसा लगता है कि 1 9 2.168.250.10 में सभी देरी शामिल हैं। 1 9 2.168.250.2 सभी अनुरोधों के तुरंत जवाब देता है।

जाँच - परिणाम:

  • देरी हमेशा आरपीसी कॉल के पहले पैकेट में होती है
  • एनएफएस कमांड प्रकार देरी के उदाहरणों से संबंधित नहीं थे
  • Fragmentation = केवल पहला पैकेट देरी

एक बड़ा लिखें कॉल 300 अलग-अलग टीसीपी पैकेट में टूट सकता है, और केवल पहले देरी हो रही है, लेकिन शेष सभी उड़ते हैं। मध्य में देरी कभी नहीं होती है। मुझे यकीन नहीं है कि खिड़की का आकार कैसे प्रभावित कर सकता है शुरू कनेक्शन इतनी भारी है।

अगला कदम: मैं टीएफसी विंडो की बजाय NFSSVC_MAXBLKSIZE नीचे NFS विकल्पों को ट्वीव करना शुरू कर दूंगा। साथ ही, मैंने देखा कि 2.6.18 काम करता है जबकि 2.6.38 नहीं है। मुझे पता है कि उस समय सीमा के दौरान VMXnet3 ड्राइवर के लिए समर्थन जोड़ा गया था। मेजबानों पर आप किस एनआईसी ड्राइवर का उपयोग कर रहे हैं? टीसीपी ऑफलोडिंग हाँ / नहीं? 95second चिह्न के आसपास एक एकल एनएफएस लिखें कॉल के लिए 500 से अधिक टीसीपी पैकेट हैं। टीसीपी के प्रभारी जो भी हो और बड़े पीडीयू को तोड़ना क्या हो रहा है।


3
2017-07-08 23:26



मैंने nfs को सेट करने का प्रयास किया: nfs3_max_transfer_size, nfs: nfs3_max_transfer_size_cots और nfs: nfs3_bsize सभी को नीचे 8192: कोई फर्क नहीं पड़ता, वही समस्याएं। लिनक्स अतिथि बस अपने एससीएसआई / एसएएस-डिस्क का उपयोग करते हैं, एनएफएस नहीं - ESXi एनएफएस-क्लाइंट है, इसलिए लिनक्स अतिथि पर कोई नेटवर्क ड्राइवर समस्या नहीं है। एनएफएस सर्वर पक्ष पर मैंने वर्चुअल ई 1000 और vmxnet3 दोनों की कोशिश की है: कोई फर्क नहीं पड़ता। जहां तक ​​मुझे पता है कि ईएसएक्सआई केवल आईएससीएसआई के लिए टीसीपी ऑफलोडिंग का उपयोग करता है। - exo_cw
सबसे बड़ा ? मेरा कारण है कि टीसीपी खिड़की को समायोजित करना एक फर्क पड़ता है ... मेरा आंत मुझे बताता है कि टीसीपी पर उन बड़े पीडीयू को खंडित करने के साथ यह कुछ करना है। नेटवर्किंग स्टैक में कुछ ऐसा है जो इस पर घुटनों लगा रहा है। बस उस चीज़ के बारे में सोच नहीं सकते जो हम देख रहे व्यवहार को फिट करेंगे। यदि खिड़की का आकार एक मुद्दा था, तो हमें बड़ी हस्तांतरण के मध्य में विलंबता बैंडविड्थ देखना चाहिए, शुरुआत में नहीं, लेकिन यह हमेशा आरपीसी कॉल का पहला पैकेट है ... कठिन एक। - Ryan


मेरे पास ESXi4.1U1 और CentOS VM का उपयोग कर एक ही समस्या की तरह दिखता है। मेजबान डेल आर 610 हैं, भंडारण एक ईएमसी 2 इस्इलॉन क्लस्टर है।

क्या आप वीएलएएनएस का उपयोग कर किसी भी मौके से थे? मैंने वीएमकॉर्न बंदरगाह पर वीएलएएनएन का उपयोग करके भंडारण के लिए 4000-5000ms 'हैंग' को वीएमएचओस्ट पर सभी स्टोरेज ट्रैफिक के लिए पाया। हालांकि अगर मैं वीएलएएनएन से VM कर्नेल बंदरगाह को स्थानांतरित करता हूं तो इसे अनगिनत पैकेट प्राप्त होते हैं, मुझे समस्या दिखाई नहीं देती है।

नीचे दिया गया सरल सेटअप मेरे नेटवर्क पर समस्या का कारण बन जाएगा:

1) किसी सर्वर या वर्कस्टेशन पर ESXi 4.1U1 स्थापित करें (दोनों ने कोशिश की जब मैंने समस्या का प्रदर्शन किया)

2) वीएलएएन पर एक वीएम कर्नेल पोर्ट जोड़ें।

3) एक एनएफएस डेटास्टोर जोड़ें (मेरा वही वीएलएएन पर है, यानी इस्इलॉन टैग किए गए पैकेट प्राप्त करता है)

4) आईओपिंग के साथ 2 सेंटोस 5.5 वीएम स्थापित करें।

5) बूट वीएम को एकल उपयोगकर्ता मोड में (यानी कोई नेटवर्क नहीं, न्यूनतम सेवाएं)

6) एक मशीन पर आईपिंग चलाएं ताकि यह इसकी वर्चुअल डिस्क पर लिख रहा हो

7) अन्य मशीन पर डीडी या somesuch चलाने के लिए 100 एमबी डेटा / tmp या इसी तरह के डेटा लिखने के लिए

अधिकतर मैं 4-5 सेकंड के लिए वीएम के ठंड दोनों को नहीं देखता हूं।

वास्तव में यह देखने में दिलचस्पी हो कि किसी और ने समान देखा है या नहीं।


2
2017-12-17 12:38



सर्वर फॉल्ट में आपका स्वागत है! यह एक पुराना सवाल है। यदि इसका उत्तर सीधे आपकी मदद नहीं करता है तो आपको क्लिक करके एक नया नया प्रश्न पूछना चाहिए प्रश्न पूछो बटन। - Iain
हां, ज़ाहिर है कि मैं टैग किए गए वीएलएएन का उपयोग कर रहा हूं। जैसा कि मैं उन्हें हर जगह उपयोग कर रहा हूं, मैंने इस समस्या के संभावित स्रोत के रूप में भी उनके बारे में नहीं सोचा था। मैं इसे एक अनगिनत बंदरगाह पर पुन: उत्पन्न करने की कोशिश करने जा रहा हूं। - exo_cw
मैं इस समस्या को एक अनगिनत बंदरगाह पर भी पुन: पेश कर सकता हूं, उस होस्ट पर कोई वीएलएएन शामिल नहीं है। - exo_cw
मैं बस कोशिश कर रहा था और अनगिनत बंदरगाह पर भी समस्या देख रहा था, यह थोड़ी कम बार-बार है, शायद यही कारण है कि मैंने इसे याद किया। बम-स्टीयर के लिए खेद है। मैं आईओमीटर का उपयोग कर Win7 64 बिट पर समस्या नहीं देख सकता, और ऐसा लगता है कि मैं सी ब्राउज़ कर सकता हूं: ड्राइव जबकि अन्य लिनक्स वीएमएस लटकाए गए हैं। मैं crystaldiskmark के साथ कोशिश करने जा रहा हूँ - Nick
असल में मैं Win7 x64 पर आईओमीटर के साथ अपने परिणाम देखने में रुचि रखूंगा। यह विलंबता को मापता है लेकिन मुझे प्राप्त उच्चतम समग्र आंकड़ा 4k पढ़ने के परीक्षण का उपयोग करके 300ms था, 4000 + एमएस नहीं - Nick


दो हफ्ते पहले हमें वही समस्या थी। ESX41 यू 1 और नेटएप FAS3170 + एनएफएस डेटास्टोरस। आरएचईएल 5 वीएम 2 या 4 सेकेंड के लिए लटकते हैं और हमने वर्चुअल सेंटर प्रदर्शन कंसोल से बहुत अधिक स्पाइक्स देखी हैं।

मैं कॉन्फ़िगरेशन की जांच करने के लिए नेटवर्क लड़के से पूछता हूं और समस्या सिस्को स्विच पर थी। हमारे पास दो ईथरनेट लिंक हैं जो नेटैप पक्ष पर ईथरचैनल पर कॉन्फ़िगर किए गए थे और सिस्को पक्ष पर नहीं थे। वह सिस्को पर एक स्थिर Ethechannel बनाता है और अब यह ठीक काम करता है। इस तरह की समस्या की पहचान करने के लिए, फाइलर और स्विच के बीच एक को छोड़कर सभी बंदरगाह बंद करें। बस एक बंदरगाह छोड़ दो और देखें कि चीजें कैसे चल रही हैं।

दूसरी बात यह है कि हम switcj और filer पर फ़्लो कंट्रोल को हटाना चाहते थे क्योंकि हमें संदेह है कि यह विराम फ्रेम भेजने के लिए है।


2
2018-01-09 22:48





आपका 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 परीक्षण फिर से चलाएं।


1
2017-07-06 15:30



मैंने एनएफएस सर्वर (इस मामले में ओपन इंडियाना) और ईएसएक्सआई होस्ट पर इसे जोड़ने की कोशिश की। दुर्भाग्य से यह कोई फर्क नहीं पड़ता है। मैं बस सर्वर और अतिथि आईपी को ठीक कर सकता हूं। - exo_cw
ऐसा लगता है कि आपने एनएफएस स्ट्रीम से संबंधित सभी ट्रैफिक को फ़िल्टर नहीं किया है, हमें और अधिक देखने की आवश्यकता हो सकती है! - tony roth
@tony रोथ: असल में उस समय पूरा यातायात है। मैंने परीक्षण किया कि उस पर मेजबान और एनएफएस-सर्वर के साथ एक अलग vSwitch पर। - exo_cw
क्या आप वायरसहार्क के साथ DNS डंप कर सकते हैं? - Joseph Kern
@ जोसेफ कर्न: मैंने अभी कैप्चर फाइलों का फिर से विश्लेषण किया है: मेरे कैप्चर के दौरान बिल्कुल कोई DNS ट्रैफ़िक नहीं था। एनएफएस डेटास्टोर को आईएसएक्सआई होस्ट पर आईपी द्वारा मैप किया गया है। DNS ईएसएक्सआई और एनएफएस सर्वर पर ठीक काम करता है, मैंने सभी शामिल आईपी के आगे और पीछे देखने का परीक्षण किया। अभी मेरे पास यह विश्वास करने का कोई कारण नहीं है कि DNS इसका कारण है। - exo_cw


यहां स्ट्रॉ पर ग्रासिंग, लेकिन इन सर्वरों में आप किस एनआईसी का उपयोग कर रहे हैं? स्टैक ओवरफ्लो sysadmins में ब्रॉडकॉम एनआईसी के साथ अजीब नेटवर्किंग मुद्दे हैं जो इंटेल एनआईसी में स्विच करते समय चले गए: http://blog.serverfault.com/post/broadcom-die-mutha/ 


1
2017-07-08 17:00



आखिरी परीक्षण केवल एक वीएसविच पर किए गए थे, कोई भौतिक नेटवर्क शामिल नहीं था (ई 1000 और वीएमएक्सनेट 3: कोई फर्क नहीं पड़ता)। लेकिन मैंने इंटेल 82574 एल, इंटेल 82576 और इंटेल 82567 एलएफ -3 पर भी इसका परीक्षण किया है, जो सभी समस्या दिखा रहे हैं। मुझे अभी तक कोई हार्डवेयर नहीं मिला है जहां मैं इसे पुन: उत्पन्न नहीं कर सकता। - exo_cw


यहां एक और अनुमान है ... क्या आपका आईपीवी 6 EXS होस्ट पर सक्षम है? यदि हां, तो इसे बंद करने का प्रयास करें? मेरे अनुभव से यदि आपका पूरा नेटवर्क आईपीवी 6 (यानी आरएडीवी, डीएचसीपी 6, डीएनएस, रिवर्स डीएनएस) के लिए ठीक से कॉन्फ़िगर नहीं किया गया है तो यह कुछ सेवाओं के लिए एक समस्या हो सकती है। साथ ही, सुनिश्चित करें कि यह एनएफएस सर्वर पर बंद है।


1
2017-07-12 02:04



आईपीवी 6 मेजबान पर पहले से ही आईपीवी 6 अक्षम कर दिया गया था। मैंने एनएफएस सर्वर पर आईपीवी 6 अक्षम कर दिया है (ifconfig -a6 अब खाली है), लेकिन इससे कोई फर्क नहीं पड़ता: यह वही समस्याएं दिखाता है। - exo_cw