ISCSI और AoE दोनों का कम प्रदर्शन

Question

हम एक प्रतिध्वनि गति भंडारण के लिए देख रहे हैं। कम बजट के कारण हमने सॉफ्टवेयर iSCSI या AoE लक्ष्य का उपयोग करने का निर्णय लिया। इससे पहले कि हम अपने उत्पादन में बदलाव लाएं, हम सर्वश्रेष्ठ प्रौद्योगिकी का चयन करने के लिए कुछ परीक्षण कर रहे हैं।

परीक्षण के लिए हम उपयोग करते हैं:

• लक्ष्य के रूप में Fujitsu Siemens RX200 S4
• सर्जक के रूप में Fujitsu Siemens RX200 S4
• NetGear 1GBit स्विच को प्रबंधित करता है
• जहाज पर एनआईसी (ब्रॉडकॉम डब्ल्यू / टीओई), एडीमैक्स एनआईसी, ब्रॉडकॉम एनआईसीएस डब्ल्यू / टीओई - सभी 1 जीबीट
• लक्ष्य सर्वर 6 2TB WD ब्लू SATA ड्राइव के साथ QLogic कंट्रोलर का उपयोग कर रहा है।
• दोनों लक्ष्य और आरंभकर्ता ऑपरेटिंग सिस्टम सभी अपडेट के साथ Ubuntu 16.04 LTS हैं। भंडारण उद्देश्य के लिए स्विच समर्पित है। हम बांड और बहुपथ परीक्षण करते हैं।

हमारी समस्या कम पढ़ने की गति है। परीक्षण के लिए हम उपयोग करते हैं ddऔर एक 40-100GB फ़ाइल।

• एक लक्ष्य सर्वर पर स्थानीय पढ़ना और लिखना 300 एमबी / एस से अधिक है।
• iSCSI या AoE द्वारा सर्वर पर लिखना 200MB / s से अधिक है जो हमें संतुष्ट करता है।
• सर्वर से पढ़ना हमेशा 95-99MB / s होता है।

हमने ietd, aoetools, LIO की कोशिश की है। हमने 2 एनआईसी के बॉन्ड का उपयोग किया है: बैलेंस-आरआर और एलएसीपी, आरआर के साथ गुणा। सामान्य और जंबो फ्रेम का इस्तेमाल किया। अंत में हमने टारगेट और होस्ट (स्विच नहीं) के बीच सीधा ईथरनेट कनेक्शन भी किया।

सभी परीक्षण कम समान परिणाम देते हैं (बेशक TOE और iSCSI के बिना आम NIC का उपयोग करके 20-30% बदतर परिणाम दिए गए)।

IPerf के साथ परीक्षण नेटवर्क ने 200MB / s (2GBit) के बारे में स्थानान्तरण दिखाया। बीआईसी को लक्ष्य के साथ एनआईसी के उपयोग को देखते हुए दोनों उपकरणों (पढ़ने के लिए प्रत्येक के बारे में 50 एमबी / लेखन के लिए लगभग 100 एमबी / एस) का समान उपयोग दिखाया गया है।

जैसा कि हमारे पास कोई भाग्य नहीं था, हमने तीसरे एनआईसी (पाठ्यक्रम के दोनों पक्ष) का उपयोग करने का फैसला किया। परिणाम अजीब थे:

• 2 एनआईसी - 50 एमबी / एस प्रत्येक
• 3 एनआईसी - 33 एमबी / एस प्रत्येक

क्या लक्ष्य सॉफ़्टवेयर पर कोई सीमा है जो आउटपुट को 1GBit / s से अधिक अक्षम करती है?

हम क्या गलत करते हैं?

Comments

10GbE इन दिनों काफी सस्ता है। यदि आपको अधिक बैंडविड्थ की आवश्यकता है (जो आप नहीं कर सकते हैं), तो यह अनुशंसित पथ है।

— ewwhite

10 GbE ATAoE के साथ मदद नहीं करेगा, यह एक बहुत ही ईथरनेट फ्रेम अप्रभावी प्रोटोकॉल है। खासकर जंबो फ्रेम के लिए!

— बैरोनसमेदी १

मैं iSCSI की बात कर रहा था। ATAoE मर चुका है और इसके लिए उपयोग में नहीं होना चाहिए।

— इविविट

Answer 1

ISCSI कनेक्टेड स्टोरेज से अधिकतम प्रदर्शन को निचोड़ने के लिए आपको जंबो फ्रेम्स और MPIO (LACP नहीं) का उपयोग करना चाहिए। यदि आप ऐसा कर सकते हैं तो RDMA / iSER की सिफारिश की जाती है।

AOE (ईथरनेट पर ATA) पुराना है और गंदगी है। हम पहले से ही साल पहले से छुटकारा पा चुके हैं। हम StarWind https://www.starwindsoftware.com/ का उपयोग कर रहे हैं क्योंकि iSCSI लक्ष्य पहले से ही काफी पहले है और StarWind ने हमें Coraid से माइग्रेट करने के लिए कहा कि हम जो भी संग्रहण कर सकते हैं।

तो अभी, हम StarWind द्वारा उपलब्ध कराए गए iSCSI के साथ बहुत अच्छे हैं और विंडोज, ESX और SCST http://scst.sourceforge.net/ लिनक्स पर दीक्षार्थियों के रूप में उपयोग कर रहे हैं । RDMA / iSER के साथ यह 10 Gbit तक का है, जो अब तक बहुत खुश है।

Answer 2

ईथरनेट लिंक एकत्रीकरण काम कैसे गलत है पर आपकी उम्मीद।

संतुलन-rr के अलावा अन्य सभी एकत्रीकरण तरीकों (यानी: सभी तरीकों जिसका मोड> 0) करते नहीं आप एक अधिक से अधिक एकल कनेक्शन throughput देते हैं; इसके बजाय, वे कुल उपलब्ध बैंडविड्थ को बढ़ाते हैं जब कई कनेक्शन प्रभावित मेजबानों से / से स्थापित होते हैं। दूसरे शब्दों में, LAG / LACP आपको इस एक-कनेक्शन परिदृश्य के लिए कोई लाभ नहीं देगा।

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

वैसे भी, यदि आप लक्ष्य और आरंभकर्ता दोनों को बैलेंस-आरआर पर सेट करते हैं, तो सीधे दो मशीनों को जोड़ने से आपको बढ़ा हुआ प्रदर्शन देना चाहिए। यदि नहीं, तो क्या आप iperfबैलेंस-आरआर और दोनों मशीनों के साथ सीधे जुड़े हुए हैं (कोई स्विच नहीं) पोस्ट कर सकते हैं ? इसके अलावा, कृपया ddबेंचमार्किंग के लिए आपके द्वारा उपयोग की गई सटीक कमांड पोस्ट करें ।

Answer 3

नोट: मैं यहाँ केवल iSCSI के बारे में बात कर रहा हूँ। मुझे इसके बारे में पढ़ने से परे एओई के साथ कोई अनुभव नहीं है, और मैं इसे किसी भी नए बुनियादी ढाँचे में लागू नहीं करूंगा (यह बहुत ही दोषपूर्ण है)।

कुछ बहुत विशिष्ट बिंदु से बिंदु प्रोटोकॉल के अलावा अन्य किसी भी चीज़ के लिए बैलेंस-आरआर का उपयोग न करें। लगभग किसी भी तरह के वास्तविक विश्व भार के तहत इसका भयानक प्रदर्शन होता है, और नेटवर्क समस्याओं (जैसे बहुत सारे घबराने) का कारण बनता है। निश्चित रूप से एक स्विच के साथ इसका इस्तेमाल नहीं करते।

लोड संतुलन और दोष सहिष्णुता को पूरा करने के लिए सर्जक की ओर से बिना किसी बंधन के एमपीआईओ का उपयोग करें। यह सुनिश्चित करने के लिए कि आपके मार्ग आपके सभी ट्रैफ़िक को एक ही पथ पर भेजकर "मिश्रित" न हों, अलग-अलग सबनेट पर आपके पथ में व्यक्तिगत पथ (लक्ष्य और सर्जक के बीच गीगाबिट एनआईसी) डालें।

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

सर्जक पर LACP का उपयोग करना केवल तभी प्रभावी होगा जब यह एक साथ उपयोग के साथ कई टारगेट पोर्टल कनेक्शन बना रहा हो (केवल किसी भी लोड के लिए आम नहीं)। यहां तक ​​कि अगर आप सर्जक पर प्रति मार्ग LACP को प्रभावी ढंग से लागू करने के लिए थे, तो यह जल्दी से प्रत्येक बॉक्स में चार अतिरिक्त कपड़ों का उपयोग करने के लिए एक दुःस्वप्न बन जाएगा। यदि आपको एकल सर्जक के लिए ~ 2Gib / s थ्रूपुट से अधिक की आवश्यकता है, तो 10GiB / s ईथरनेट पर विचार करें।

Answer 4

एओई पर अधिकांश प्रतिक्रियाएं पूरी तरह से गलत, प्रतिसादात्मक हैं, और एओई ज्ञान और अनुभव की कमी दिखाती हैं। सबसे पहले, यह अशुद्ध नहीं है। कोर्एआईडी एओई के पीछे विक्रेता है और उन्होंने कोरैड ट्रेडमार्क को बनाए रखते हुए "साउथसाइट" के रूप में पुनः आरंभ किया। वे एक ही डेवलपर्स हैं, भी। वे नए उत्पाद बना रहे हैं और अधिकांश पुराने का समर्थन कर रहे हैं। वे एओई विकास को आगे बढ़ा रहे हैं, साथ ही उनकी खुली तकनीकी मेलिंग सूची स्पष्ट रूप से दिखाती है। वेबसाइट की जाँच करें, यह सब अप टू डेट है और पूरी कहानी को उनके इतिहास पृष्ठ पर बताता है।

किसी ने कहा कि AoE जंबो फ्रेम से लाभ नहीं होगा और यह भी गलत था। 'Vbladed' के संस्करण 13 को रिलीज़ होने के बाद इसका समर्थन किया गया था। नए फ्रेम आकार का समर्थन करने के लिए आपको अपने MTU को ट्यून करने की आवश्यकता है, लेकिन अन्यथा यह बहुत अच्छा काम करता है।

iSCSI OSI मॉडल के लेयर -5 में चलता है। यह सामान्य परिवहन टीसीपी है। यह आपको कुछ त्रुटि सुधार (टीसीपी में चेकसम के कारण) देता है और आपको लेयर -3 पर आईपी पर यातायात को रूट करने की अनुमति देता है। यह उस जगह के बारे में है जहां iSCSI के फायदे बंद हो जाते हैं। यह वास्तविक दुनिया का प्रदर्शन एकदम भयानक है जब आप वास्तव में इसकी तुलना कुछ इस तरह करते हैं जैसे एफसीओ, एओई, या एफसीओई। मैं आपको हॉरर शो के लिए Google "इस्की प्रदर्शन तुलना" के लिए आमंत्रित करूंगा।

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

802.3ad एकत्रीकरण आपके एकल प्रवाह को बहुत अधिक नहीं बढ़ाएगा, यहां तक ​​कि एक राउंड-रॉबिन परिदृश्य में भी। यह आपके नेटवर्क कॉन्फिग को भी जटिल करेगा और आपको पीडीयू अंतराल को बेमेल करके या सिस्को वीपीसी लिंक को सक्रिय-सक्रिय स्थिति का समर्थन करने के लिए मिसमैच करके अपने आप को शूट करने के लिए कुछ नए अवसर प्रदान करेगा। AoE के साथ LACP का उपयोग न करें, इसे अपने आप को गुणा और बहुसंकेतन करने दें। एओई के बाद के संस्करणों ने इसे खूबसूरती से संभाला, और ज्यादातर मामलों में भी इनायत से अधिक FCP चूंकि यह सभी स्वचालित है। अतिरिक्त ईथरनेट पोर्ट आपको अधिक बैंडविड्थ और अधिक लचीलापन देते हैं। यदि आप कई स्विचों पर होस्ट और आरंभकर्ता ईथरनेट बंदरगाहों को फैलाते हैं, तो यह और भी अधिक अतिरेक प्रदान कर सकता है। बॉन्डिंग मोड को कॉन्फ़िगर करने की कोई आवश्यकता नहीं है। इसके अलावा, AoE के लिए आपके द्वारा उपयोग किए जाने वाले समान इंटरफेस पर IP न चलाएं।

संक्षेप में, AoE naysayers को मत सुनो, उन्हें लगता है कि उनके पास ज्यादा अनुभव नहीं है और वे सिर्फ ट्रेंडी ब्रेनवेव्स की सवारी कर रहे हैं। झुंड को भगाओ। हैंड-ट्यून प्रीफेटिंग के साथ एक बैकिंग स्टोर को कॉन्फ़िगर करें और आप शायद अपने रीड थ्रूपुट को ऊपर जाते हुए देखेंगे। एकत्रीकरण प्रोटोकॉल का उपयोग छोड़ें और iSCSI से चिल्लाएँ। एक आखिरी बात, 'dd' का उपयोग करना बंद करें यह एक महान परीक्षण नहीं है और खराब कैशिंग प्रभावों के अधीन है। असली बेंचमार्क टूल जैसे 'फियो', 'आईजोन', या 'डेंच' का इस्तेमाल करें। वे बहुत अधिक विश्वसनीय परिणाम देते हैं।

Answer 5

मुझे पता है कि एलएसीपी कई कनेक्शनों के लिए है। परीक्षण यह हताशा का एक कार्य था :)

सभी परीक्षण संतुलन-आरआर और दो एनआईसी के साथ किए गए थे।

ISCSI लक्ष्य के लिए लेखन:
dd if = / dev / zero of = / mnt / zero.bin bs = 1M count = 2000
2000 + 0 przeczytanych recordów
2000 + 0 zapisanych recordów
2097x2000 बाइट्स (2,1 GB, 2,0 GiB) की प्रतिलिपि बनाई गई , 10,1093 s, 207 MB / s

iSCSI लक्ष्य से पढ़ना:
dd if = / mnt / zero.bin of = / dev / null bs = 1M
2000 + 0 przeczytanych recordów
2000 + 0apisanych recordów
2097152000 बाइट्स (2,1 GB) , 2,0 GiB) कॉपी किया गया, 16,1684 s, 130 MB / s

नेटवर्क स्पीड:
iperf -c 172.16.10.80
------------------------ ------------------------------------
172.16.10.80 से कनेक्ट होने वाला क्लाइंट, टीसीपी पोर्ट 5001
टीसीपी विंडो का आकार: 325 केबीटी (डिफ़ॉल्ट)
--------------------------------------------- ---------------
[३] स्थानीय १ 3२.१६.१०. port० बंदरगाह ३ with२२४ जो १6२.१६.१०. local० बंदरगाह ५००१ से जुड़ा हुआ है
[आईडी] इंटरवल ट्रांसफर बैंडविड्थ
[३] ०.०-१.० सेकेंड २.३० जीबीाइट्स १.९ / जीबीबिट्स / सेक्योर

टेस्टिंग विद आईपर्फ और जंबो फ्रेम्स ने एक ही परिणाम दिया।

मैंने सर्जक पर
चलकर कुछ पढ़ने की गति प्राप्त की है: hdparm -a 2048 / dev / dm-1
इससे पहले यह 256 था और पढ़ने की गति 96 एमबी थी /
मेरा लक्ष्य 200 एमबी / एस के बारे में पढ़ने की गति को प्राप्त करना है।

संपादित करें:
1. हम एलएसीपी का उपयोग नहीं करते हैं - यह एक बार परीक्षण था।
2. बैलेंस-आरआर और एमपीआईओ के साथ परीक्षण बिल्कुल समान परिणाम देते हैं। विभिन्न सबनेट में एनआईसी के साथ मल्टीपाथिंग का परीक्षण किया गया।
3. अधिक एनआईसी जोड़ने से पढ़ने की गति में वृद्धि नहीं होती है, लेकिन केवल प्रत्येक एनआईसी के उपयोग को कम करता है।
4. हमें लगता है कि समस्या कुछ सीमा (ड्राइवर, मॉड्यूल?) है जो तेजी से पढ़ने की अनुमति नहीं देता है। लेकिन मुझे यकीन नहीं है, अगर यह लक्ष्य या सर्जक पक्ष है।


EDIT 2: बस कुछ अतिरिक्त परीक्षण किया: नेटवर्किंग हार्डवेयर मुद्दों से छुटकारा पाने के लिए एक ही मेजबान को एक लक्ष्य और आरंभकर्ता के रूप में कॉन्फ़िगर किया गया। मैं चौंक गया: बिल्कुल वही पढ़ने की गति! 130 एमबी / एस! लेखन 227 एमबी / एस है।

Comments

जब आप iSCSI का उपयोग करते हैं, तो आपको LACP से लाभ प्राप्त करने के लिए प्रति सत्र कई कनेक्शन करने की आवश्यकता होती है। कोई mc / s = कोई प्रदर्शन लाभ नहीं। scst.sourceforge.net/mc_s.html और starwindsoftware.com/blog/… मदद कर सकते हैं।

— बैरोनसमेदी १

Answer 6

आपने अपने निक को कैसे कॉन्फ़िगर किया है सभी बफ़र्स को ठीक से सेट किया गया है, क्या आपने नेटवर्क बफ़र्स को पर्याप्त राम आवंटित किया है। यहां भी बॉन्डिंग का उपयोग न करें, आप 2 इस्की चैनल का उपयोग कर सकते हैं और उन्हें सर्जक पर मल्टीपाथ कर सकते हैं, उसी तरह किसी भी पथ पर शेल्फ और लून आईडी के माध्यम से सर्जक मल्टीपैथ के साथ।

Comments

क्या आपके द्वारा किए जा रहे सुझावों में कोई जाँच और / या कॉन्फ़िगरेशन परिवर्तन हैं? यहां तक ​​कि अगर आपके पास पूर्ण उत्तर नहीं है, तो यह आपके उत्तर और दूसरों की मदद करता है यदि आप

— प्रश्नकर्ता