एक स्व-इकट्ठे SAN में IOPS के लिए संघर्ष का इतिहास

सभी को नमस्कार!

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

आर्किटेक्चर

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

ऐसा चुनाव क्यों? यदि आप आधिकारिक स्रोतों के पुनर्मुद्रण को छोड़ देते हैं - सहित और आम लोकोस्ट।

तदनुसार, भंडारण में हमने 7200 आरपीएम के साथ नियमित एसएटीए डिस्क का उपयोग किया। उनका दोष सभी को पता है - निम्न आईओपीएस।

RAID10

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

root@storage:~# hdparm -tT /dev/md127 /dev/md127: Timing cached reads: 9636 MB in 2.00 seconds = 4820.51 MB/sec Timing buffered disk reads: 1544 MB in 3.03 seconds = 509.52 MB/sec 

सच कहूँ तो, IOPS की जाँच डरावनी थी, SCSI पर स्विच करने या अपनी बैसाखी लिखने के अलावा समस्या को हल करने के लिए कोई विकल्प नहीं थे।

नेटवर्क और एमटीयू

हालांकि नेटवर्क विशाल था, डिस्क रहित सर्वरों से रीड स्पीड अपेक्षित ~ 100MiB / सेकंड तक नहीं पहुंची। स्वाभाविक रूप से, नेटवर्क कार्ड के ड्राइवरों को दोष देना था (हाय, डेबियन)। निर्माता की वेबसाइट से नए ड्राइवरों का उपयोग करने से लगता है कि समस्या आंशिक रूप से ठीक हो गई है ...

सभी एओई गति अनुकूलन मैनुअल में, पहला आइटम अधिकतम एमटीयू स्थापित करने का संकेत देता है। उस समय यह 4200 था। अब यह हास्यास्पद लगता है, लेकिन मानक 1500 की तुलना में, रैखिक पढ़ने की गति वास्तव में ~ 120MiB / सेकंड, शांत तक पहुंच गई है! और यहां तक ​​कि सभी वर्चुअल सर्वर द्वारा डिस्क सबसिस्टम पर एक छोटे से लोड के साथ, स्थानीय कैश ने स्थिति को ठीक किया और प्रत्येक वर्चुअल मशीन के अंदर रैखिक रीड गति को कम से कम 50MiB / सेकंड रखा गया था। वास्तव में, बहुत अच्छा! समय के साथ, हमने नेटवर्क कार्ड, स्विच को बदल दिया, और MTU को अधिकतम 9K तक बढ़ा दिया।

MySQL आने तक

हां, 24/7 कुछ परियोजनाओं ने MySQL को खींचा, दोनों लिखने और पढ़ने के लिए। यह कुछ इस तरह देखा गया:

 Total DISK READ: 506.61 K/s | Total DISK WRITE: 0.00 B/s TID PRIO USER DISK READ DISK WRITE SWAPIN IO> COMMAND 30312 be/4 mysql 247.41 K/s 11.78 K/s 0.00 % 11.10 % mysqld 30308 be/4 mysql 113.89 K/s 19.64 K/s 0.00 % 7.30 % mysqld 30306 be/4 mysql 23.56 K/s 23.56 K/s 0.00 % 5.36 % mysqld 30420 be/4 mysql 62.83 K/s 11.78 K/s 0.00 % 5.03 % mysqld 30322 be/4 mysql 23.56 K/s 23.56 K/s 0.00 % 2.58 % mysqld 30445 be/4 mysql 19.64 K/s 19.64 K/s 0.00 % 1.75 % mysqld 30183 be/4 mysql 7.85 K/s 7.85 K/s 0.00 % 1.15 % mysqld 30417 be/4 mysql 7.85 K/s 3.93 K/s 0.00 % 0.36 % mysqld 

हानिरहित? कोई फर्क नहीं पड़ता कि कैसे। छोटे अनुरोधों की एक विशाल धारा, एक आभासी सर्वर पर 70% io प्रतीक्षा करें, भंडारण पर प्रत्येक हार्ड डिस्क पर 20% लोड (शेष वर्चुअल के अनुसार) और शेष आभासी मशीनों पर ऐसी सुस्त तस्वीर:

 root@mail:~# hdparm -tT /dev/xvda /dev/xvda: Timing cached reads: 10436 MB in 1.99 seconds = 5239.07 MB/sec Timing buffered disk reads: 46 MB in 3.07 seconds = 14.99 MB/sec 

और यह तेज़ है! अक्सर रैखिक रीड गति 1-2 MiB / सेकंड से अधिक नहीं थी।

मुझे लगता है कि हर कोई पहले से ही अनुमान लगा चुका है कि हम क्या कर रहे हैं। निम्न IOPS SATA ड्राइव, भले ही RAID10 हो।

Flashcache

समय पर ये लोग कैसे दिखाई दिए! यह मोक्ष है, यह वही है! जीवन बेहतर हो रहा है, हम बच जाएंगे!
इंटेल SSDs की तत्काल खरीद, भंडारण सर्वर की लाइव छवि में मॉड्यूल और फ्लैशकास्ट उपयोगिताओं का समावेश, राइट-बैक कैश सेटिंग और आंखों में आग। हाँ, सभी काउंटर शून्य हैं। वैसे, LVM + Flashcache की विशेषताएं Google के लिए आसान हैं, समस्या जल्दी हल हो गई थी।

MySQL के साथ एक वर्चुअल सर्वर पर, लोडवॅग 20 से 10 पर गिरा। अन्य वर्चुअल मशीनों पर रेखीय रीडिंग 15-20 मिब / सेक तक स्थिर हो गई। मूर्ख मत बनो!

कुछ समय बाद, मैंने निम्नलिखित आँकड़े एकत्र किए:

 root@storage:~# dmsetup status cachedev 0 2930294784 flashcache stats: reads(85485411), writes(379006540) read hits(12699803), read hit percent(14) write hits(11805678) write hit percent(3) dirty write hits(4984319) dirty write hit percent(1) replacement(144261), write replacement(111410) write invalidates(2928039), read invalidates(8099007) pending enqueues(2688311), pending inval(1374832) metadata dirties(11227058), metadata cleans(11238715) metadata batch(3317915) metadata ssd writes(19147858) cleanings(11238715) fallow cleanings(6258765) no room(27) front merge(1919923) back merge(1058070) disk reads(72786438), disk writes(374046436) ssd reads(23938518) ssd writes(42752696) uncached reads(65392976), uncached writes(362807723), uncached IO requeue(13388) uncached sequential reads(0), uncached sequential writes(0) pid_adds(0), pid_dels(0), pid_drops(0) pid_expiry(0) 

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

घोषणा!

सौवीं बार इसे देखने के लिए:

 root@storage:~# dmsetup table cachedev 0 2930294784 flashcache conf: ssd dev (/dev/sda), disk dev (/dev/md2) cache mode(WRITE_BACK) capacity(57018M), associativity(512), data block size(4K) metadata block size(4096b) skip sequential thresh(0K) total blocks(14596608), cached blocks(3642185), cache percent(24) dirty blocks(36601), dirty percent(0) nr_queued(0) Size Hist: 512:117531108 1024:61124866 1536:83563623 2048:89738119 2560:43968876 3072:51713913 3584:83726471 4096:41667452 

मेरा पसंदीदा एक्सेल लिब्रे ऑफिस Calc खोलने का फैसला किया:

आरेख अंतिम पंक्ति पर बनाया गया है, ब्लॉक आकार द्वारा अनुरोधों के वितरण का हिस्टोग्राम।
हम सभी जानते हैं कि
हार्ड ड्राइव आमतौर पर 512-बाइट ब्लॉक में काम करते हैं। बिल्कुल AoE की तरह। लिनक्स कर्नेल - 4096 बाइट्स प्रत्येक। फ्लास्कैच में डेटा ब्लॉक का आकार भी 4096 है।

4096 से भिन्न ब्लॉक आकारों के साथ अनुरोधों की संख्या को बढ़ाते हुए, यह स्पष्ट है कि परिणामी संख्या संदिग्ध रूप से बिना पढ़े हुए की संख्या से मेल खाती है + फ़्लैशकेक आँकड़ों से अनछुए लेखन। केवल 4K ब्लॉक कैश किए गए हैं! याद रखें कि शुरू में MTU में हमारे पास 4200 थे? यदि हम इसे एओई पैकेट हेडर के आकार से घटाते हैं, तो हमें 3584 पर डेटा ब्लॉक का आकार मिलता है। इसलिए, डिस्क सबसिस्टम के किसी भी अनुरोध को कम से कम 2 एओई पैकेट: 3584 बाइट्स और 512 फीट में विभाजित किया जाएगा। जो मूल चित्र में बस स्पष्ट रूप से दिखाई दे रहा था, जिसे मैंने देखा। यहां तक ​​कि लेख से आरेख में, 512 बाइट पैकेट की प्रबलता ध्यान देने योग्य है। और 9K में हर कोने पर अनुशंसित MTU में भी एक समान समस्या है: डेटा ब्लॉक का आकार 8704 बाइट्स है, ये 2 4K ब्लॉक और प्रति 512 बाइट्स (जो वास्तव में लेख से आरेख में देखा गया है) हैं। हे भगवान! मुझे लगता है कि समाधान, सभी के लिए स्पष्ट है।

MTU 8700

डिस्क को डिस्क रहित नोड में से किसी एक पर अपडेट करने के कुछ दिनों बाद बनाया जाता है। दूसरों पर MTU अपडेट करने के बाद, स्थिति और भी बेहतर हो जाएगी। और MySQL के साथ एक आभासी सर्वर पर loadavg 3 पर गिरा!

निष्कर्ष

20 साल के अनुभव के साथ सिस्टम प्रशासक नहीं होने के कारण, हमने "मानक" और उचित समय पर समुदाय के लिए ज्ञात सबसे लोकप्रिय दृष्टिकोणों का उपयोग करके समस्याओं को हल किया। लेकिन वास्तविक दुनिया में हमेशा खामियों, बैसाखियों और मान्यताओं के लिए जगह होती है। जिसे हम, वास्तव में, भाग गए।
यहाँ ऐसी ही एक कहानी है।