LVM2 में पतले प्रावधान के बारे में

RHEL 6.4 के बाद से LVM2 में पतली प्रोविजनिंग सक्षम की गई है। मैं इसे "पतली आरक्षण" के रूप में रूसी में अनुवाद करूंगा, हालांकि अनुवाद गलत है और वास्तविकता के साथ पूरी तरह से असंगत है, इसलिए, रूसी के साथ अंग्रेजी वर्तनी का उपयोग किया जाएगा।

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

स्थिर संचालन के लिए, LVM2 में पतले प्रावधान के लिए 3.4 कर्नेल की आवश्यकता होती है। Red Hat में, यह बैकपोर्टेड है और उनके "क्लासिक" 2.6.32 पर चलता है।
Lvm2 --with-पतली = आंतरिक और अन्य कठिनाइयों को संकलित करते समय एक कुंजी की कमी के कारण डेबियन व्हीज़ी पतली प्रोविजनिंग मेरे लिए अनुपलब्ध है। यदि आवश्यक हो, परीक्षण के उद्देश्य के लिए, आप इस पैकेज को स्रोत से संकलित कर सकते हैं।

मुझे स्नैपशॉट में अधिक दिलचस्पी नहीं थी, लेकिन सर्वरों पर उपयोग के लिए "पतली लॉजिकल वॉल्यूम" के प्रदर्शन में। अधीर के लिए, मैं तुरंत कहूंगा - उत्पादकता में गिरावट देखी गई है, और एक महत्वपूर्ण है। नीचे विवरण।

CentOS 6.4 2.6.32-279.2.1.el6.x86_64 के साथ एक ही सर्वर पर RAID1 पर mdadm का उपयोग करके बनाया गया है, हम एक "पतला पूल" बनाते हैं:

lvcreate -L 50G -T /dev/VG/thin_pool 

और नियमित तार्किक आयतन (LV):

 lvcreate -L 50G /dev/VG/thick_vol 

हम इन उपकरणों के रैखिक पढ़ने और लिखने के प्रदर्शन को मापते हैं:

पतला पूल:

रिकॉर्ड:

 dd if=/dev/zero of=/dev/mapper/VG-thin_pool bs=1M count=1000 oflag=direct 1000+0 records in 1000+0 records out 1048576000 bytes (1.0 GB) copied, 15.9126 s, 65.9 MB/s 

पढ़ने:

 dd if=/dev/mapper/VG-thin_pool of=/dev/null bs=1M count=1000 iflag=direct 1000+0 records in 1000+0 records out 1048576000 bytes (1.0 GB) copied, 4.19247 s, 250 MB/s 

LV:

- रिकॉर्ड:

 FIO: : iodepth=2, bw=943120 B/s, iops=230, avg=8645.48 usec 

 # dd if=/dev/zero of=/dev/VG/thick_vol bs=1M count=1000 oflag=direct 1000+0 records in 1000+0 records out 1048576000 bytes (1.0 GB) copied, 15.8432 s, 66.2 MB/s 

- पढ़ना:

 FIO: : iodepth=2, bw=775490 B/s, iops=189, avg=10536.95 usec 

 # dd if=/dev/VG/thick_vol of=/dev/null bs=1M count=1000 iflag=direct 1000+0 records in 1000+0 records out 1048576000 bytes (1.0 GB) copied, 4.04925 s, 259 MB/s 

जैसा कि आप देख सकते हैं, प्रदर्शन LV और पतले पूल के लिए भिन्न नहीं है।

एक पतले पूल में एक पतली मात्रा बनाएं

 lvcreate -V 100G -T -n thin_vol /dev/mapper/VG-thin_pool 

प्रदर्शन की जाँच करें:

रिकॉर्ड:

 FIO: : iodepth=2, bw=1100.5KB/s, iops=275, avg=7241.55 usec 

 dd if=/dev/zero of=/dev/mapper/VG-thin_vol bs=1M count=1000 oflag=direct 1000+0 records in 1000+0 records out 1048576000 bytes (1.0 GB) copied, 38.7505 s, 27.1 MB/s 

पढ़ने:

 FIO: : iodepth=256, bw=86100KB/s, iops=21524, avg=11860.53 usec 

 dd if=/dev/mapper/VG-thin_vol of=/dev/null bs=1M count=1000 iflag=direct 1000+0 records in 1000+0 records out 1048576000 bytes (1.0 GB) copied, 4.45363 s, 235 MB/s 

यह बहुत स्पष्ट है कि पतली मात्रा पर रैखिक रिकॉर्डिंग एक नियमित LV (27.1 MB / s बनाम 66.2 MB / s) की तुलना में 2 गुना धीमी है। इसी समय, यादृच्छिक लेखन की गति भी बढ़ जाती है, और यादृच्छिक पढ़ने के लिए वास्तविक प्रदर्शन को मापना बिल्कुल भी संभव नहीं था - यह कैश से केवल पढ़ने के स्तर को दिखाता है, जबकि कैश को रीसेट करने से मदद नहीं मिली।

रैखिक रिकॉर्डिंग के प्रदर्शन में गिरावट चिंताजनक है और एक मौका है कि यह mdadm से RAID1 की उपस्थिति के कारण है, इसलिए हमें इसे किसी अन्य मशीन पर परीक्षण करना था, और फ़ाइल सिस्टम स्तर पर प्रदर्शन को भी देखना होगा। VMware वर्कस्टेशन डेबियन व्हीजी 7.3 3.10-0.bpo.3-amd64 वर्चुअल मशीन SSD ड्राइव।

प्रदर्शन की जाँच करें:

LV:

रिकॉर्ड:

 dd if=/dev/zero of=/delete.img bs=1M count=1000 oflag=direct 1000+0 records in 1000+0 records out 1048576000 bytes (1.0 GB) copied, 3.49623 s, 300 MB/s 

पढ़ने:

 FIO: : iodepth=384, bw=158839KB/s, iops=39709, avg= 9.64 msec 

 dd if=/delete.img of=/dev/null bs=1M count=1000 iflag=direct 1000+0 records in 1000+0 records out 1048576000 bytes (1.0 GB) copied, 2.31352 s, 453 MB/s 

पतली LV:

रिकॉर्ड:

 dd if=/dev/zero of=/mnt/thin/delete.img bs=1M count=1000 oflag=direct 1000+0 records in 1000+0 records out 1048576000 bytes (1.0 GB) copied, 7.15546 s, 147 MB/s 

पढ़ने:

 FIO: : iodepth=384, bw=176574KB/s, iops=44143, avg=8675.36 usec 

 dd if=/mnt/thin/delete.img of=/dev/null bs=1M count=1000 iflag=direct 1000+0 records in 1000+0 records out 1048576000 bytes (1.0 GB) copied, 2.33435 s, 449 MB/s 

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

अद्यतन: मैंने RAID और वर्चुअल मशीनों के बिना "क्लीन" सर्वर पर एक और परीक्षण किया। लाइन रिकॉर्डिंग प्रदर्शन में कोई गिरावट नहीं! मैं पहले दो परीक्षणों में परीक्षण की एकतरफाता के संबंध में गुमराह करने के लिए प्रतिष्ठित दर्शकों से माफी मांगता हूं। नतीजतन, मुझे लगता है कि प्रत्येक विशिष्ट मामले के लिए प्रदर्शन का परीक्षण करना आवश्यक है।

परिणाम:

1. प्रत्येक मामले में पतली मात्रा का उपयोग करते समय, रैखिक रिकॉर्डिंग के प्रदर्शन का परीक्षण करना आवश्यक होता है, उदाहरण के लिए, RAID 1 के लिए mdadm और VMware वर्चुअल मशीन के साथ, रैखिक रिकॉर्डिंग की गति "क्लासिक" एलवी की तुलना में 2 गुना कम हो जाती है;
2. इस मामले में, पतली मात्रा पर एक यादृच्छिक रिकॉर्डिंग ने इस तरह की गिरावट को नोटिस नहीं किया और गति उसी स्तर पर है जैसा मैंने एलवी के लिए किया था;
3. डेबियन पर, मैं मानक रिपॉजिटरी की कमी के कारण उत्पादन में इसका उपयोग नहीं करूंगा;