LVM र Matryoshka मा के समान छ?

दिनको दयालु समय।
म md RAID + LVM प्रयोग गरेर KVM को लागि डाटा भण्डारण प्रणाली निर्माण गर्ने मेरो व्यावहारिक अनुभव समुदायसँग साझा गर्न चाहन्छु।

कार्यक्रम समावेश हुनेछ:

• NVMe SSD बाट md RAID 1 निर्माण गर्दै।
• SATA SSD र नियमित ड्राइभहरूबाट md RAID 6 संयोजन गर्दै।
• SSD RAID 1/6 मा TRIM/DSCARD सञ्चालनका सुविधाहरू।
• डिस्कको साझा सेटमा बुटेबल md RAID 1/6 array सिर्जना गर्दै।
• BIOS मा NVMe समर्थन नभएको बेला NVMe RAID 1 मा प्रणाली स्थापना गर्दै।
• LVM क्यास र LVM पातलो प्रयोग गर्दै।
• BTRFS स्न्यापसटहरू प्रयोग गर्दै र ब्याकअपको लागि पठाउनुहोस्/प्राप्त गर्नुहोस्।
• BTRFS शैली ब्याकअपहरूको लागि LVM पातलो स्न्यापशटहरू र thin_delta प्रयोग गर्दै।

यदि तपाइँ इच्छुक हुनुहुन्छ भने, कृपया बिरालो हेर्नुहोस्।

अनुप्रयोग फारम

यस लेखबाट सामग्री/उदाहरण/कोड/टिप्स/डेटा प्रयोग वा प्रयोग नगर्दा हुने परिणामहरूको लागि लेखकले कुनै जिम्मेवारी वहन गर्दैन। कुनै पनि तरिकाले यो सामग्री पढेर वा प्रयोग गरेर, तपाईंले यी कार्यहरूको सबै परिणामहरूको लागि जिम्मेवारी लिनुहुन्छ। सम्भावित परिणामहरू समावेश छन्:

• कुरकुरा-फ्राइड NVMe SSDs।
• रेकर्डिङ स्रोत र SSD ड्राइभहरूको विफलता पूर्ण रूपमा प्रयोग गरियो।
• ब्याकअप प्रतिलिपिहरू सहित सबै ड्राइभहरूमा सबै डेटाको पूर्ण हानि।
• खराब कम्प्युटर हार्डवेयर।
• समय, स्नायु र पैसा बर्बाद।
• कुनै पनि अन्य परिणामहरू जुन माथि सूचीबद्ध छैनन्।

आयरन

उपलब्ध थिए:

Z2013 चिपसेटको साथ 87 बाट मदरबोर्ड, Intel Core i7 / Haswell सँग पूर्ण।

• प्रोसेसर 4 कोर, 8 थ्रेडहरू
• 32 GB DDR3 RAM
• 1 x 16 वा 2 x 8 PCIe 3.0
• 1 x 4 + 1 x 1 PCIe 2.0
• 6 x 6 GBps SATA 3 कनेक्टरहरू

SAS एडाप्टर LSI SAS9211-8I IT / HBA मोडमा फ्ल्यास भयो। RAID-सक्षम फर्मवेयरलाई जानाजानी HBA फर्मवेयरसँग प्रतिस्थापन गरिएको छ:

1. तपाईंले यो एडाप्टरलाई जुनसुकै बेला बाहिर फाल्न सक्नुहुन्छ र तपाईंले भेट्नुभएको कुनै पनि अन्यसँग बदल्न सक्नुहुन्छ।
2. TRIM/Discard ले सामान्यतया डिस्कहरूमा काम गर्यो, किनभने... RAID फर्मवेयरमा यी कमाण्डहरू कुनै पनि हालतमा समर्थित छैनन्, र HBA, सामान्यतया, बसमा कुन कमाण्डहरू पठाइन्छ भन्ने वास्ता गर्दैन।

हार्ड ड्राइभहरू - ल्यापटपहरूको लागि 8 फारम कारकमा 7 TB क्षमताको HGST Travelstar 1000K1 को 2.5 टुक्राहरू। यी ड्राइभहरू पहिले RAID 6 array मा थिए। नयाँ प्रणालीमा पनि तिनीहरूको प्रयोग हुनेछ। स्थानीय ब्याकअपहरू भण्डारण गर्न।

थप थपिएको:

6 टुक्रा SATA SSD मोडेल Samsung 860 QVO 2TB। यी SSDs लाई ठूलो मात्रा चाहिन्छ, SLC क्यासको उपस्थिति, विश्वसनीयता, र कम मूल्य चाहिन्छ। खारेज/शून्यको लागि समर्थन आवश्यक थियो, जुन dmesg मा लाइन द्वारा जाँच गरिएको छ:

kernel: ata1.00: Enabling discard_zeroes_data

NVMe SSD मोडेल Samsung SSD 2 EVO 970GB को २ टुक्रा।

यी SSD हरूका लागि, अनियमित पढ्न/लेख्ने गति र तपाईंको आवश्यकताहरूको लागि स्रोत क्षमता महत्त्वपूर्ण छ। तिनीहरूको लागि रेडिएटर। अनिवार्य रूपमा। बिल्कुल। अन्यथा, पहिलो RAID सिङ्क्रोनाइजेसनको समयमा तिनीहरूलाई क्रिस्पी नभएसम्म फ्राइ गर्नुहोस्।

StarTech PEX8M2E2 एडाप्टर 2 x NVMe SSD को लागि PCIe 3.0 8x स्लटमा स्थापना गरियो। यो, फेरि, केवल एक HBA हो, तर NVMe को लागी। यो सस्तो एडेप्टरहरू भन्दा फरक छ कि यसमा निर्मित PCIe स्विचको उपस्थितिको कारणले मदरबोर्डबाट PCIe विभाजन समर्थन आवश्यक पर्दैन। X1 PCIe 1.0 स्लट भए पनि यसले PCIe सँग सबैभन्दा पुरानो प्रणालीमा पनि काम गर्नेछ। स्वाभाविक रूपमा, उपयुक्त गतिमा। त्यहाँ कुनै RAIDs छैन। बोर्डमा बिल्ट-इन BIOS छैन। त्यसोभए, तपाइँको प्रणालीले जादुई रूपमा NVMe सँग बुट गर्न सिक्ने छैन, यो यन्त्रलाई धेरै कम NVMe RAID धन्यवाद।

यो कम्पोनेन्ट प्रणालीमा केवल एउटा नि:शुल्क 8x PCIe 3.0 को उपस्थितिको कारणले मात्र हो, र, यदि त्यहाँ 2 नि: शुल्क स्लटहरू छन् भने, यसलाई सजिलैसँग दुई पेनी PEX4M2E1 वा एनालगहरूसँग प्रतिस्थापन गर्न सकिन्छ, जुन 600 को मूल्यमा जहाँ पनि किन्न सकिन्छ। रुबल।

सबै प्रकारका हार्डवेयर वा बिल्ट-इन चिपसेट/BIOS RAIDs को अस्वीकृति जानाजानी बनाइएको थियो, सम्पूर्ण प्रणालीलाई पूर्ण रूपमा प्रतिस्थापन गर्न सक्षम हुनको लागि, SSD/HDD आफैंलाई बाहेक, सबै डाटा सुरक्षित गर्दै। आदर्श रूपमा, ताकि तपाईं पूर्ण रूपमा नयाँ/भिन्न हार्डवेयरमा सर्दा स्थापित अपरेटिङ सिस्टमलाई पनि बचत गर्न सक्नुहुन्छ। मुख्य कुरा यो हो कि त्यहाँ SATA र PCIe पोर्टहरू छन्। यो लाइभ सीडी वा बुटेबल फ्ल्यास ड्राइभ जस्तै हो, केवल धेरै छिटो र थोरै भारी।

हास्यअन्यथा, तपाईलाई थाहा छ के हुन्छ - कहिलेकाहीँ तपाईले तुरुन्तै सम्पूर्ण एरेलाई तपाईसँग लैजान आवश्यक छ। तर म डाटा गुमाउन चाहन्न। यो गर्नका लागि, उल्लेख गरिएका सबै मिडियाहरू सजिलैसँग मानक केसको 5.25 बेहरूमा स्लाइडहरूमा अवस्थित छन्।

ठीक छ, र, निस्सन्देह, लिनक्समा SSD क्यासिङको विभिन्न विधिहरूसँग प्रयोगको लागि।

हार्डवेयर छापा बोरिंग छन्। यसलाई सुचारु गर। यसले काम गर्छ वा गर्दैन। र mdadm संग त्यहाँ सधैं विकल्प छन्।

सफ्टवेयर

पहिले, डेबियन 8 जेसी हार्डवेयरमा स्थापना गरिएको थियो, जुन EOL नजिक छ। RAID 6 LVM सँग जोडिएको माथि उल्लेखित HDDs बाट भेला गरिएको थियो। यसले kvm/libvirt मा भर्चुअल मेसिनहरू चलाएको छ।

किनभने लेखकसँग पोर्टेबल बुटेबल SATA/NVMe फ्ल्यास ड्राइभहरू सिर्जना गर्ने उपयुक्त अनुभव छ, र साथै, सामान्य उपयुक्त टेम्प्लेट तोड्न नदिने क्रममा, Ubuntu 18.04 लाई लक्ष्य प्रणालीको रूपमा छनोट गरिएको थियो, जुन पहिले नै पर्याप्त रूपमा स्थिर भइसकेको छ, तर अझै 3 वर्षहरू छन्। भविष्यमा समर्थन।

उल्लेखित प्रणालीले हामीलाई आवश्यक पर्ने सबै हार्डवेयर ड्राइभरहरू समावेश गर्दछ। हामीलाई कुनै तेस्रो-पक्ष सफ्टवेयर वा ड्राइभरहरू आवश्यक पर्दैन।

स्थापनाको लागि तयारी गर्दै

प्रणाली स्थापना गर्न हामीलाई Ubuntu डेस्कटप छवि चाहिन्छ। सर्भर प्रणालीसँग केहि प्रकारको बलियो स्थापनाकर्ता छ, जसले अत्यधिक स्वतन्त्रता देखाउँदछ जुन UEFI प्रणाली विभाजनलाई डिस्कहरू मध्ये एउटामा खसालेर असक्षम गर्न सकिँदैन, सबै सुन्दरतालाई बिगार्छ। तदनुसार, यो UEFI मोडमा मात्र स्थापित छ। कुनै पनि विकल्प प्रस्ताव गर्दैन।

यसबाट हामी सन्तुष्ट छैनौं।

किन?दुर्भाग्यवश, UEFI बुट बुट सफ्टवेयर RAID सँग अत्यन्तै खराब उपयुक्त छ, किनभने... कसैले हामीलाई UEFI ESP विभाजनको लागि आरक्षण प्रदान गर्दैन। त्यहाँ अनलाइन व्यञ्जनहरू छन् जसले USB पोर्टमा फ्लैश ड्राइभमा ESP विभाजन राख्न सुझाव दिन्छ, तर यो असफलताको बिन्दु हो। त्यहाँ मेटाडेटा संस्करण 1 को साथ सफ्टवेयर mdadm RAID 0.9 प्रयोग गर्ने रेसिपीहरू छन् जसले UEFI BIOS लाई यो विभाजन हेर्नबाट रोक्दैन, तर यो खुशीको क्षण सम्म जीवित रहन्छ जब BIOS वा अर्को हार्डवेयर OS ले ESP मा केहि लेख्छ र यसलाई अन्यमा सिंक्रोनाइज गर्न बिर्सन्छ। ऐना।

थप रूपमा, UEFI बुट NVRAM मा निर्भर गर्दछ, जुन डिस्कसँगै नयाँ प्रणालीमा सर्दैन, किनभने मदरबोर्डको अंश हो।

त्यसोभए, हामी नयाँ पाङ्ग्रा पुन: आविष्कार गर्दैनौं। हामीसँग पहिले नै तयार-निर्मित, समय-परीक्षण गरिएको हजुरबुबाको बाइक छ, जसलाई अहिले Legacy/BIOS बुट भनिन्छ, UEFI- संगत प्रणालीहरूमा CSM को गौरवपूर्ण नाम बोकेको छ। हामी यसलाई शेल्फबाट निकाल्नेछौं, यसलाई लुब्रिकेट गर्नेछौं, टायरहरू पम्प गर्नेछौं र यसलाई ओसिलो कपडाले पुछ्नेछौं।

Ubuntu को डेस्कटप संस्करण लेगेसी बुटलोडरको साथ राम्रोसँग स्थापना गर्न सकिँदैन, तर यहाँ, तिनीहरूले भने, कम्तिमा त्यहाँ विकल्पहरू छन्।

र त्यसोभए, हामी हार्डवेयर सङ्कलन गर्छौं र Ubuntu Live बुटेबल फ्ल्यास ड्राइभबाट प्रणाली लोड गर्छौं। हामीले प्याकेजहरू डाउनलोड गर्न आवश्यक हुनेछ, त्यसैले हामी तपाईंको लागि काम गर्ने नेटवर्क सेटअप गर्नेछौं। यदि यसले काम गर्दैन भने, तपाइँ आवश्यक प्याकेजहरू पहिले नै फ्लैश ड्राइभमा लोड गर्न सक्नुहुन्छ।

हामी डेस्कटप वातावरणमा जान्छौं, टर्मिनल इमुलेटर सुरु गर्छौं, र हामी जान्छौं:

#sudo bash

कसरी…?माथिको रेखा सुडोको बारेमा होलिवारहरूको लागि क्यानोनिकल ट्रिगर हो। C खоठूलो अवसर आउँछ रоठूलो जिम्मेवारी। प्रश्न यो हो कि तपाईं यसलाई आफैंमा लिन सक्नुहुन्छ। धेरै मानिसहरू सोच्छन् कि यस तरिकामा sudo प्रयोग गरेर कम्तिमा सावधान छैन। यद्यपि:

#apt-get install mdadm lvm2 thin-provisioning-tools btrfs-tools util-linux lsscsi nvme-cli mc

ZFS किन छैन ...?जब हामी हाम्रो कम्प्युटरमा सफ्टवेयर स्थापना गर्छौं, हामी अनिवार्य रूपमा यस सफ्टवेयरको विकासकर्ताहरूलाई ड्राइभ गर्नको लागि हाम्रो हार्डवेयर उधारो दिन्छौं।
जब हामी हाम्रो डेटाको सुरक्षाको साथ यो सफ्टवेयरमा विश्वास गर्छौं, हामी यो डेटा पुनर्स्थापनाको लागत बराबर ऋण लिन्छौं, जुन हामीले कुनै दिन तिर्नु पर्ने हुन्छ।

यस दृष्टिकोणबाट, ZFS फेरारी हो, र mdadm+lvm साइकल जस्तै हो।

विषयगत रूपमा, लेखकले फेरारीको सट्टा अज्ञात व्यक्तिहरूलाई क्रेडिटमा बाइक उधारो दिन रुचाउँछन्। त्यहाँ, मुद्दाको मूल्य उच्च छैन। अधिकार चाहिँदैन । ट्राफिक नियम भन्दा सरल। पार्किङ नि: शुल्क छ। क्रस-कन्ट्री क्षमता राम्रो छ। तपाई जहिले पनि साइकलमा खुट्टा जोड्न सक्नुहुन्छ, र तपाई आफ्नै हातले साइकल मर्मत गर्न सक्नुहुन्छ।

त्यसो भए BTRFS किन...?अपरेटिङ सिस्टम बुट गर्नको लागि, हामीलाई Legacy/BIOS GRUB मा समर्थित फाइल प्रणाली चाहिन्छ, र एकै समयमा लाइभ स्न्यापसटहरू समर्थन गर्दछ। हामी यसलाई /boot विभाजनको लागि प्रयोग गर्नेछौं। थप रूपमा, लेखकले यो FS को / (रूट) को लागी प्रयोग गर्न रुचाउँछन्, कुनै पनि अन्य सफ्टवेयरको लागि तपाईले LVM मा छुट्टै विभाजनहरू सिर्जना गर्न सक्नुहुन्छ र आवश्यक डाइरेक्टरीहरूमा माउन्ट गर्न सक्नुहुन्छ भनेर याद गर्न नबिर्सनुहोस्।

हामी यस FS मा भर्चुअल मेसिन वा डाटाबेसको कुनै पनि छविहरू भण्डारण गर्दैनौं।
यो FS लाई निष्क्रिय नगरीकन प्रणालीको स्न्यापसटहरू सिर्जना गर्न र त्यसपछि पठाउने/प्राप्त गर्ने प्रयोग गरी यी स्न्यापसटहरूलाई ब्याकअप डिस्कमा स्थानान्तरण गर्न मात्र प्रयोग गरिनेछ।

थप रूपमा, लेखक सामान्यतया हार्डवेयरमा न्यूनतम सफ्टवेयर राख्न र GPU हरू र PCI-USB होस्ट नियन्त्रकहरूलाई IOMMU मार्फत KVM मा फर्वार्ड गर्ने जस्ता चीजहरू प्रयोग गरेर भर्चुअल मेसिनहरूमा अन्य सबै सफ्टवेयरहरू चलाउन रुचाउँछन्।

हार्डवेयरमा बाँकी रहेका चीजहरू डाटा भण्डारण, भर्चुअलाइजेशन र ब्याकअप हुन्।

यदि तपाइँ ZFS लाई बढी विश्वास गर्नुहुन्छ भने, सिद्धान्तमा, निर्दिष्ट अनुप्रयोगको लागि तिनीहरू विनिमेय छन्।

यद्यपि, लेखकले जानाजानी ZFS, BRTFS र LVM मा भएका बिल्ट-इन मिररिङ/RAID र रिडन्डन्सी सुविधाहरूलाई बेवास्ता गर्छन्।

थप तर्कको रूपमा, BTRFS सँग अनियमित लेखहरूलाई क्रमिक लेखहरूमा परिणत गर्ने क्षमता छ, जसले HDD मा स्न्यापशट/ब्याकअपहरू सिङ्क्रोनाइज गर्ने गतिमा अत्यन्त सकारात्मक प्रभाव पार्छ।

सबै यन्त्रहरू पुन: स्क्यान गरौं:

#udevadm control --reload-rules && udevadm trigger

वरिपरि हेरौं:

#lsscsi && nvme list
[0:0:0:0] disk ATA Samsung SSD 860 2B6Q /dev/sda
[1:0:0:0] disk ATA Samsung SSD 860 2B6Q /dev/sdb
[2:0:0:0] disk ATA Samsung SSD 860 2B6Q /dev/sdc
[3:0:0:0] disk ATA Samsung SSD 860 2B6Q /dev/sdd
[4:0:0:0] disk ATA Samsung SSD 860 2B6Q /dev/sde
[5:0:0:0] disk ATA Samsung SSD 860 2B6Q /dev/sdf
[6:0:0:0] disk ATA HGST HTS721010A9 A3J0 /dev/sdg
[6:0:1:0] disk ATA HGST HTS721010A9 A3J0 /dev/sdh
[6:0:2:0] disk ATA HGST HTS721010A9 A3J0 /dev/sdi
[6:0:3:0] disk ATA HGST HTS721010A9 A3B0 /dev/sdj
[6:0:4:0] disk ATA HGST HTS721010A9 A3B0 /dev/sdk
[6:0:5:0] disk ATA HGST HTS721010A9 A3B0 /dev/sdl
[6:0:6:0] disk ATA HGST HTS721010A9 A3J0 /dev/sdm
[6:0:7:0] disk ATA HGST HTS721010A9 A3J0 /dev/sdn
Node SN Model Namespace Usage Format FW Rev
---------------- -------------------- ---------------------------------------- --------- -------------------------- ---------------- --------
/dev/nvme0n1 S466NXXXXXXX15L Samsung SSD 970 EVO 500GB 1 0,00 GB / 500,11 GB 512 B + 0 B 2B2QEXE7
/dev/nvme1n1 S5H7NXXXXXXX48N Samsung SSD 970 EVO 500GB 1 0,00 GB / 500,11 GB 512 B + 0 B 2B2QEXE7


डिस्क लेआउट

NVMe SSD

तर हामी तिनीहरूलाई कुनै पनि हिसाबले चिन्ह लगाउने छैनौं। सबै समान, हाम्रो BIOS ले यी ड्राइभहरू देख्दैन। त्यसोभए, तिनीहरू पूर्ण रूपमा सफ्टवेयर RAID मा जान्छन्। हामी त्यहाँ खण्डहरू पनि बनाउँदैनौं। यदि तपाइँ "क्यानन" वा "मुख्य रूपमा" पछ्याउन चाहनुहुन्छ भने, HDD जस्तै एउटा ठूलो विभाजन सिर्जना गर्नुहोस्।

SATA HDD

यहाँ कुनै विशेष आविष्कार गर्न आवश्यक छैन। हामी सबै कुराको लागि एउटा खण्ड सिर्जना गर्नेछौं। हामी विभाजन सिर्जना गर्नेछौं किनभने BIOS ले यी डिस्कहरू देख्छ र तिनीहरूबाट बुट गर्ने प्रयास पनि गर्न सक्छ। हामी पछि यी डिस्कहरूमा GRUB स्थापना गर्नेछौं ताकि प्रणालीले अचानक यो गर्न सक्छ।

#cat >hdd.part << EOF
label: dos
label-id: 0x00000000
device: /dev/sdg
unit: sectors

/dev/sdg1 : start= 2048, size= 1953523120, type=fd, bootable
EOF
#sfdisk /dev/sdg < hdd.part
#sfdisk /dev/sdh < hdd.part
#sfdisk /dev/sdi < hdd.part
#sfdisk /dev/sdj < hdd.part
#sfdisk /dev/sdk < hdd.part
#sfdisk /dev/sdl < hdd.part
#sfdisk /dev/sdm < hdd.part
#sfdisk /dev/sdn < hdd.part


SATA SSD

यहाँ चीजहरू हाम्रो लागि रोचक हुन्छन्।

सर्वप्रथम, हाम्रा ड्राइभहरू २ TB साइजमा छन्। यो MBR को लागि स्वीकार्य दायरा भित्र छ, जुन हामीले प्रयोग गर्नेछौं। आवश्यक भएमा, GPT को साथ प्रतिस्थापन गर्न सकिन्छ। GPT डिस्कहरूमा एक अनुकूलता तह छ जसले MBR-कम्प्याटिबल प्रणालीहरूलाई पहिलो 2 विभाजनहरू हेर्न अनुमति दिन्छ यदि तिनीहरू पहिलो 4 टेराबाइट भित्र अवस्थित छन्। मुख्य कुरा यी डिस्कहरूमा बूट विभाजन र bios_grub विभाजन सुरुमा हुनुपर्छ। यसले तपाईंलाई GPT लिगेसी/BIOS ड्राइभहरूबाट बुट गर्न अनुमति दिन्छ।

तर यो हाम्रो मामला होइन।

यहाँ हामी दुई खण्डहरू सिर्जना गर्नेछौं। पहिलो आकारमा 1 GB हुनेछ र RAID 1 /boot को लागि प्रयोग गरिनेछ।

दोस्रो RAID 6 को लागि प्रयोग गरिने छ र ड्राइभको अन्त्यमा एक सानो अनलोकेटेड क्षेत्र बाहेक बाँकी सबै खाली ठाउँ लिनेछ।

यो अचिह्नित क्षेत्र के हो?नेटवर्कमा स्रोतहरूका अनुसार, हाम्रो SATA SSDs सँग 6 देखि 78 गीगाबाइट सम्मको साइजमा गतिशील रूपमा विस्तारयोग्य SLC क्यास छ। हामीले ड्राइभको डेटा पानामा "गीगाबाइट्स" र "गीबिबाइट्स" बीचको भिन्नताको कारणले 6 गिगाबाइटहरू "नि:शुल्क" पाउँछौं। बाँकी 72 गीगाबाइटहरू प्रयोग नगरिएको ठाउँबाट छुट्याइएको छ।

यहाँ यो ध्यान दिनुपर्छ कि हामीसँग SLC क्यास छ, र स्पेस 4 बिट MLC मोडमा ओगटेको छ। जसको हाम्रो लागि प्रभावकारी रूपमा मतलब यो हो कि प्रत्येक 4 गिगाबाइट खाली ठाउँको लागि हामीले SLC क्यासको 1 गिगाबाइट मात्र पाउनेछौं।

७२ गिगाबाइटलाई ४ ले गुणन गर्नुहोस् र २८८ गिगाबाइट पाउनुहोस्। यो खाली ठाउँ हो जुन हामीले ड्राइभहरूलाई SLC क्यासको पूर्ण प्रयोग गर्न अनुमति दिनको लागि चिन्ह लगाउने छैनौं।

यसरी, हामी कुल छ ड्राइभहरूबाट प्रभावकारी रूपमा 312 गिगाबाइट्स SLC क्यास प्राप्त गर्नेछौं। सबै ड्राइभहरू मध्ये, 2 रिडन्डन्सीको लागि RAID मा प्रयोग गरिनेछ।

क्यासको यो मात्राले हामीलाई वास्तविक जीवनमा अत्यन्तै विरलै परिस्थितिको सामना गर्न अनुमति दिन्छ जहाँ लेख क्यासमा जाँदैन। यसले QLC मेमोरीको सबैभन्दा दुखद कमजोरीको लागि धेरै राम्रो क्षतिपूर्ति दिन्छ - क्यासलाई बाइपास गरेर डाटा लेख्दा अत्यन्त कम लेखन गति। यदि तपाइँको भारहरू यससँग मेल खाँदैन भने, म सुझाव दिन्छु कि तपाइँ डेटा पानाबाट TBW लाई ध्यानमा राख्दै तपाइँको SSD यस्तो भार अन्तर्गत कति लामो समय सम्म रहनेछ भनेर सोच्नुहोस्।

#cat >ssd.part << EOF
label: dos
label-id: 0x00000000
device: /dev/sda
unit: sectors

/dev/sda1 : start= 2048, size= 2097152, type=fd, bootable
/dev/sda2 : start= 2099200, size= 3300950016, type=fd
EOF
#sfdisk /dev/sda < ssd.part
#sfdisk /dev/sdb < ssd.part
#sfdisk /dev/sdc < ssd.part
#sfdisk /dev/sdd < ssd.part
#sfdisk /dev/sde < ssd.part
#sfdisk /dev/sdf < ssd.part


एरेहरू सिर्जना गर्दै

पहिले, हामीले मेसिनको नाम परिवर्तन गर्न आवश्यक छ। यो आवश्यक छ किनभने होस्ट नाम mdadm भित्र कतै एरे नामको अंश हो र कतै केही असर गर्छ। निस्सन्देह, arrays पछि पुन: नामाकरण गर्न सकिन्छ, तर यो एक अनावश्यक कदम हो।

#mcedit /etc/hostname
#mcedit /etc/hosts
#hostname
vdesk0


NVMe SSD

#mdadm --create --verbose --assume-clean /dev/md0 --level=1 --raid-devices=2 /dev/nvme[0-1]n1

किन मानौं-स्वच्छ...?आर्यहरू प्रारम्भ गर्नबाट बच्न। दुबै RAID स्तर 1 र 6 को लागी यो मान्य छ। सबै कुरा प्रारम्भ बिना काम गर्न सक्छ यदि यो नयाँ एरे हो। यसबाहेक, सिर्जना गर्दा SSD एरे सुरु गर्नु भनेको TBW स्रोतको बर्बादी हो। हामी तिनीहरूलाई "सुरुवात" गर्न जम्मा गरिएका SSD arrayहरूमा सम्भव भएसम्म TRIM/DISCARD प्रयोग गर्छौं।

SSD arrays को लागि, RAID 1 DISCARD लाई बक्स बाहिर समर्थित छ।

SSD RAID 6 DISCARD arrays को लागि, तपाईंले यसलाई कर्नेल मोड्युल प्यारामिटरहरूमा सक्षम गर्नुपर्छ।

यस प्रणालीमा स्तर 4/5/6 array मा प्रयोग गरिएका सबै SSDs मा discard_zeroes_data को लागि काम गर्ने समर्थन छ भने मात्र यो गरिनु पर्छ। कहिलेकाहीँ तपाइँ अनौठो ड्राइभहरू भेट्नुहुन्छ जसले कर्नेललाई यो प्रकार्य समर्थित छ भनेर बताउँछ, तर वास्तवमा यो त्यहाँ छैन, वा प्रकार्यले सधैं काम गर्दैन। यस समयमा, समर्थन लगभग सबै ठाउँमा उपलब्ध छ, तथापि, त्यहाँ पुराना ड्राइभहरू र त्रुटिहरूसँग फर्मवेयर छन्। यस कारणले गर्दा, RAID 6 को लागि पूर्वनिर्धारित रूपमा DISCARD समर्थन असक्षम गरिएको छ।

ध्यान दिनुहोस्, निम्न आदेशले "शून्य" को साथ एरे "सुरुवात" गरेर NVMe ड्राइभहरूमा सबै डाटा नष्ट गर्नेछ।

#blkdiscard /dev/md0

यदि केहि गलत भयो भने, एक चरण निर्दिष्ट गर्ने प्रयास गर्नुहोस्।

#blkdiscard --step 65536 /dev/md0

SATA SSD

#mdadm --create --verbose --assume-clean /dev/md1 --level=1 --raid-devices=6 /dev/sd[a-f]1
#blkdiscard /dev/md1
#mdadm --create --verbose --assume-clean /dev/md2 --chunk-size=512 --level=6 --raid-devices=6 /dev/sd[a-f]2

किन यति ठूलो...?खण्ड-आकार बढाउनाले खण्ड-आकार समावेशी सम्म ब्लकहरूमा अनियमित पढाइको गतिमा सकारात्मक प्रभाव पार्छ। यो हुन्छ किनभने उपयुक्त साइज वा सानो को एक अपरेशन एकल उपकरणमा पूर्ण रूपमा पूरा गर्न सकिन्छ। त्यसैले, सबै यन्त्रहरूबाट IOPS संक्षेप गरिएको छ। तथ्याङ्क अनुसार, IO को 99% 512K भन्दा बढी छैन।

RAID मा प्रति लेखन 6 IOPS छ संधै एक ड्राइभको IOPS भन्दा कम वा बराबर। जब, अनियमित पढाइको रूपमा, IOPS एक ड्राइभको भन्दा धेरै गुणा ठूलो हुन सक्छ, र यहाँ ब्लक साइज प्रमुख महत्त्वको छ।
लेखकले RAID 6 द्वारा डिजाइनमा खराब भएको प्यारामिटरलाई अनुकूलन गर्ने प्रयास गर्ने बिन्दु देख्दैन र यसको सट्टामा RAID 6 राम्रो छ के अनुकूलन गर्दछ।
हामी RAID 6 को खराब अनियमित लेखनको लागि NVMe क्यास र पातलो-प्रोभिजन युक्तिहरूको साथ क्षतिपूर्ति गर्नेछौं।

हामीले अहिलेसम्म RAID 6 को लागि DISCARD सक्षम गरेका छैनौं। त्यसैले हामी अहिलेको लागि यो array लाई "प्रारम्भ" गर्दैनौं। हामी यो पछि, OS स्थापना पछि गर्नेछौं।

SATA HDD

#mdadm --create --verbose --assume-clean /dev/md3 --chunk-size=512 --level=6 --raid-devices=8 /dev/sd[g-n]1

NVMe RAID मा LVM

गतिको लागि, हामी NVMe RAID 1 मा रूट फाइल प्रणाली राख्न चाहन्छौं जुन /dev/md0 हो।
यद्यपि, हामीलाई अझै पनि अन्य आवश्यकताहरूको लागि यो द्रुत एरे चाहिन्छ, जस्तै स्वैप, मेटाडेटा र LVM-क्यास र LVM-पातलो मेटाडेटा, त्यसैले हामी यो एरेमा LVM VG सिर्जना गर्नेछौं।

#pvcreate /dev/md0
#vgcreate root /dev/md0

रूट फाइल प्रणालीको लागि विभाजन सिर्जना गरौं।

#lvcreate -L 128G --name root root

RAM को साइज अनुसार स्वैप गर्नको लागि विभाजन सिर्जना गरौं।

#lvcreate -L 32G --name swap root

OS स्थापना

कुलमा, हामीसँग प्रणाली स्थापना गर्न आवश्यक सबै छ।

Ubuntu लाइभ वातावरणबाट प्रणाली स्थापना विजार्ड सुरु गर्नुहोस्। सामान्य स्थापना। केवल स्थापनाको लागि डिस्क चयन गर्ने चरणमा, तपाईंले निम्न निर्दिष्ट गर्न आवश्यक छ:

• /dev/md1, - माउन्ट पोइन्ट /boot, FS - BTRFS
• /dev/root/root (aka /dev/mapper/root-root), - माउन्ट पोइन्ट / (रूट), FS - BTRFS
• /dev/root/swap (उर्फ /dev/mapper/root-swap), - स्वैप विभाजनको रूपमा प्रयोग गर्नुहोस्
• /dev/sda मा बूटलोडर स्थापना गर्नुहोस्

जब तपाईँले रूट फाइल प्रणालीको रूपमा BTRFS चयन गर्नुहुन्छ, स्थापनाकर्ताले स्वतः दुई BTRFS भोल्युमहरू सिर्जना गर्नेछ "@" को लागि / (root), र "@home" /home को लागि।

स्थापना सुरु गरौं ...

बूटलोडर स्थापना गर्दा त्रुटि देखाउने मोडल संवाद बक्सको साथ स्थापना समाप्त हुनेछ। दुर्भाग्यवश, तपाईं मानक माध्यमहरू प्रयोग गरेर यो संवादबाट बाहिर निस्कन र स्थापना जारी राख्न सक्षम हुनुहुने छैन। हामी प्रणालीबाट लग आउट गर्छौं र फेरि लग इन गर्छौं, सफा Ubuntu लाइभ डेस्कटपमा समाप्त हुन्छ। टर्मिनल खोल्नुहोस्, र फेरि:

#sudo bash

स्थापना जारी राख्न chroot वातावरण सिर्जना गर्नुहोस्:

#mkdir /mnt/chroot
#mount -o defaults,space_cache,noatime,nodiratime,discard,subvol=@ /dev/mapper/root-root /mnt/chroot
#mount -o defaults,space_cache,noatime,nodiratime,discard,subvol=@home /dev/mapper/root-root /mnt/chroot/home
#mount -o defaults,space_cache,noatime,nodiratime,discard /dev/md1 /mnt/chroot/boot
#mount --bind /proc /mnt/chroot/proc
#mount --bind /sys /mnt/chroot/sys
#mount --bind /dev /mnt/chroot/dev

chroot मा नेटवर्क र होस्टनाम कन्फिगर गरौं:

#cat /etc/hostname >/mnt/chroot/etc/hostname
#cat /etc/hosts >/mnt/chroot/etc/hosts
#cat /etc/resolv.conf >/mnt/chroot/etc/resolv.conf

क्रुट वातावरणमा जाऔं:

#chroot /mnt/chroot

सबै भन्दा पहिले, हामी प्याकेजहरू डेलिभर गर्नेछौं:

apt-get install --reinstall mdadm lvm2 thin-provisioning-tools btrfs-tools util-linux lsscsi nvme-cli mc debsums hdparm

अपूर्ण प्रणाली स्थापनाको कारण कुटिल रूपमा स्थापित गरिएका सबै प्याकेजहरू जाँच गर्नुहोस् र ठीक गर्नुहोस्:

#CORRUPTED_PACKAGES=$(debsums -s 2>&1 | awk '{print $6}' | uniq)
#apt-get install --reinstall $CORRUPTED_PACKAGES

यदि केहि काम गर्दैन भने, तपाईंले पहिले /etc/apt/sources.list सम्पादन गर्न आवश्यक पर्दछ

TRIM/DISCARD सक्षम गर्न RAID 6 मोड्युलका लागि प्यारामिटरहरू समायोजन गरौं:

#cat >/etc/modprobe.d/raid456.conf << EOF
options raid456 devices_handle_discard_safely=1
EOF

हाम्रो एरेहरूलाई थोरै ट्वीक गरौं:

#cat >/etc/udev/rules.d/60-md.rules << EOF
SUBSYSTEM=="block", KERNEL=="md*", ACTION=="change", TEST=="md/stripe_cache_size", ATTR{md/stripe_cache_size}="32768"
SUBSYSTEM=="block", KERNEL=="md*", ACTION=="change", TEST=="md/sync_speed_min", ATTR{md/sync_speed_min}="48000"
SUBSYSTEM=="block", KERNEL=="md*", ACTION=="change", TEST=="md/sync_speed_max", ATTR{md/sync_speed_max}="300000"
EOF
#cat >/etc/udev/rules.d/62-hdparm.rules << EOF
SUBSYSTEM=="block", ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="1", RUN+="/sbin/hdparm -B 254 /dev/%k"
EOF
#cat >/etc/udev/rules.d/63-blockdev.rules << EOF
SUBSYSTEM=="block", ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="1", RUN+="/sbin/blockdev --setra 1024 /dev/%k"
SUBSYSTEM=="block", ACTION=="add|change", KERNEL=="md*", RUN+="/sbin/blockdev --setra 0 /dev/%k"
EOF

के थियो यो..?हामीले udev नियमहरूको सेट सिर्जना गरेका छौं जसले निम्न गर्नेछ:

• RAID 2020 को लागि ब्लक क्यास साइज 6 को लागि पर्याप्त हुन सेट गर्नुहोस्। पूर्वनिर्धारित मान, लिनक्सको सिर्जना पछि परिवर्तन भएको छैन, र लामो समयको लागि पर्याप्त छैन।
• एरे चेक/सिंक्रोनाइजेसनको अवधिको लागि न्यूनतम IO रिजर्भ गर्नुहोस्। यो लोड अन्तर्गत अनन्त सिङ्क्रोनाइजेसनको स्थितिमा अड्किनबाट तपाईंको एरेहरूलाई रोक्नको लागि हो।
• एरेहरूको चेक/सिंक्रोनाइजेसनको समयमा अधिकतम IO सीमित गर्नुहोस्। यो आवश्यक छ ताकि SSD RAIDs लाई सिङ्क्रोनाइज/जाँच गर्दा तपाइँको ड्राइभलाई कुरकुरामा फ्राइ गर्दैन। यो NVMe को लागी विशेष गरी सत्य हो। (रेडिएटरको बारेमा सम्झनुहोस्? म मजाक गरिरहेको थिएन।)
• APM मार्फत स्पिन्डल रोटेशन (HDD) रोक्न डिस्कहरूलाई निषेध गर्नुहोस् र डिस्क नियन्त्रकहरूको लागि निद्राको समय 7 घण्टामा सेट गर्नुहोस्। यदि तपाइँको ड्राइभले यो गर्न सक्छ भने तपाइँ APM पूर्ण रूपमा असक्षम गर्न सक्नुहुन्छ (-B 255)। पूर्वनिर्धारित मानको साथ, ड्राइभहरू पाँच सेकेन्ड पछि रोकिनेछ। त्यसपछि OS ले डिस्क क्यास रिसेट गर्न चाहन्छ, डिस्कहरू फेरि स्पिन हुनेछ, र सबै कुरा फेरि सुरु हुनेछ। डिस्कहरूमा स्पिन्डल घुमाउने सीमित अधिकतम संख्या हुन्छ। यस्तो साधारण पूर्वनिर्धारित चक्रले तपाइँको डिस्कलाई केहि वर्षमा सजिलै मार्न सक्छ। सबै डिस्कहरू यसबाट पीडित हुँदैनन्, तर हाम्रा "ल्यापटप" हुन्, उपयुक्त पूर्वनिर्धारित सेटिङहरूसँग, जसले RAID लाई मिनी-MAID जस्तो देखिन्छ।
• डिस्कमा रीडहेड स्थापना गर्नुहोस् (घुमाउने) 1 मेगाबाइट - दुई लगातार ब्लकहरू/चङ्क RAID 6
• arrays आफैंमा readahead अक्षम गर्नुहोस्।

सम्पादन गरौं /etc/fstab:

#cat >/etc/fstab << EOF
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
# file-system mount-point type options dump pass
/dev/mapper/root-root / btrfs defaults,space_cache,noatime,nodiratime,discard,subvol=@ 0 1
UUID=$(blkid -o value -s UUID /dev/md1) /boot btrfs defaults,space_cache,noatime,nodiratime,discard 0 2
/dev/mapper/root-root /home btrfs defaults,space_cache,noatime,nodiratime,discard,subvol=@home 0 2
/dev/mapper/root-swap none swap sw 0 0
EOF
किन यस्तो..?हामी UUID द्वारा /boot विभाजन खोज्नेछौं। एरे नामकरण सैद्धान्तिक रूपमा परिवर्तन हुन सक्छ।

हामी /dev/mapper/vg-lv नोटेशनमा LVM नामहरूद्वारा बाँकी खण्डहरू खोज्नेछौं, किनभने तिनीहरूले विभाजनहरू धेरै विशिष्ट रूपमा पहिचान गर्छन्।

हामी LVM को लागी UUID प्रयोग गर्दैनौं किनभने LVM भोल्युमहरूको UUID र तिनीहरूको स्न्यापसटहरू समान हुन सक्छन्।माउन्ट /dev/mapper/root-root.. दुई पटक?हो। ठ्याक्कै। BTRFS को विशेषता। यो फाइल प्रणाली विभिन्न subvols संग धेरै पटक माउन्ट गर्न सकिन्छ।

यही सुविधाको कारणले गर्दा, म सक्रिय BTRFS भोल्युमहरूको LVM स्न्यापशटहरू कहिल्यै सिर्जना नगर्न सिफारिस गर्छु। तपाईंले रिबुट गर्दा आश्चर्यचकित हुन सक्नुहुन्छ।

mdadm कन्फिगरेसन पुन: उत्पन्न गरौं:

#/usr/share/mdadm/mkconf | sed 's/#DEVICE/DEVICE/g' >/etc/mdadm/mdadm.conf

LVM सेटिङहरू समायोजन गरौं:

#cat >>/etc/lvm/lvmlocal.conf << EOF

activation {
thin_pool_autoextend_threshold=90
thin_pool_autoextend_percent=5
}
allocation {
cache_pool_max_chunks=2097152
}
devices {
global_filter=["r|^/dev/.*_corig$|","r|^/dev/.*_cdata$|","r|^/dev/.*_cmeta$|","r|^/dev/.*gpv$|","r|^/dev/images/.*$|","r|^/dev/mapper/images.*$|","r|^/dev/backup/.*$|","r|^/dev/mapper/backup.*$|"] issue_discards=1
}
EOF

के थियो यो..?हामीले भोल्युमको 90% द्वारा कब्जा गरिएको ठाउँको 5% पुग्दा LVM पातलो पोखरीहरूको स्वचालित विस्तार सक्षम गरेका छौं।

हामीले LVM क्यासका लागि क्यास ब्लकहरूको अधिकतम संख्या बढाएका छौं।

हामीले LVM लाई LVM भोल्युमहरू (PV) खोज्नबाट रोकेका छौं:

• LVM क्यास (cdata) युक्त यन्त्रहरू
• LVM क्यास प्रयोग गरेर क्यास गरिएका यन्त्रहरू, क्यासलाई बाइपास गर्दै ( _corig)। यस अवस्थामा, क्यास गरिएको यन्त्र आफैं अझै पनि क्यास मार्फत स्क्यान हुनेछ (केवल )।
• LVM क्यास मेटाडेटा (cmeta) समावेश गर्ने यन्त्रहरू
• VG मा सबै यन्त्रहरू नाम छविहरूसँग। यहाँ हामीसँग भर्चुअल मेसिनहरूको डिस्क छविहरू हुनेछन्, र हामी होस्टमा LVM ले अतिथि OS सँग सम्बन्धित भोल्युमहरू सक्रिय गर्न चाहँदैनौं।
• नाम ब्याकअप संग VG मा सबै उपकरणहरू। यहाँ हामीसँग भर्चुअल मेसिन छविहरूको जगेडा प्रतिलिपिहरू हुनेछ।
• सबै यन्त्रहरू जसको नाम "gpv" बाट समाप्त हुन्छ (अतिथि भौतिक भोल्युम)

LVM VG मा खाली ठाउँ खाली गर्दा हामीले DISCARD समर्थन सक्षम गरेका छौं। होस् गर। यसले SSD मा LVs मेटाउन धेरै समय खपत गर्नेछ। यो विशेष गरी SSD RAID 6 मा लागू हुन्छ। यद्यपि, योजना अनुसार, हामी पातलो प्रावधान प्रयोग गर्नेछौं, त्यसैले यसले हामीलाई कुनै पनि बाधा पर्दैन।

initramfs छवि अद्यावधिक गरौं:

#update-initramfs -u -k all

grub स्थापना र कन्फिगर गर्नुहोस्:

#apt-get install grub-pc
#apt-get purge os-prober
#dpkg-reconfigure grub-pc

तपाईले कुन डिस्क छान्नु पर्छ?सबै जो sd* छन्। प्रणाली कुनै पनि काम गर्ने SATA ड्राइभ वा SSD बाट बुट गर्न सक्षम हुनुपर्छ।

किन तिनीहरूले ओएस-प्रोबर थपे ..?अत्यधिक स्वतन्त्रता र चंचल हातहरूको लागि।

यदि RAIDs मध्ये कुनै एक बिग्रिएको अवस्थामा छ भने यसले सही रूपमा काम गर्दैन। यसले यो हार्डवेयरमा चल्ने भर्चुअल मेसिनहरूमा प्रयोग हुने विभाजनहरूमा OS खोज्ने प्रयास गर्छ।

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

यससँगै हामीले प्रारम्भिक स्थापना पूरा गरेका छौं। यो नयाँ स्थापित OS मा रिबुट गर्न समय हो। बुटेबल लाइभ CD/USB हटाउन नबिर्सनुहोस्।

#exit
#reboot

बुट यन्त्रको रूपमा SATA SSDs मध्ये कुनै पनि चयन गर्नुहोस्।

SATA SSD मा LVM

यस बिन्दुमा, हामीले पहिले नै नयाँ OS मा बुट गरेका छौं, नेटवर्क कन्फिगर गरेका छौं, उपयुक्त, टर्मिनल इमुलेटर खोलेका छौं, र सुरू गरेका छौं:

#sudo bash

जारी राख्नुहोस्।

SATA SSD बाट array "प्रारम्भ गर्नुहोस्":

#blkdiscard /dev/md2

यदि यसले काम गर्दैन भने, त्यसपछि प्रयास गर्नुहोस्:

#blkdiscard --step 65536 /dev/md2
SATA SSD मा LVM VG सिर्जना गर्नुहोस्:

#pvcreate /dev/md2
#vgcreate data /dev/md2

अर्को VG किन..?वास्तवमा, हामीसँग पहिले नै VG नामको रूट छ। किन सबै कुरा एउटै VG मा थप्नुभएन?

यदि VG मा धेरै PV हरू छन् भने, VG सही रूपमा सक्रिय हुनको लागि, सबै PV हरू उपस्थित हुनुपर्छ (अनलाइन)। अपवाद LVM RAID हो, जुन हामीले जानाजानी प्रयोग गर्दैनौं।

हामी साँच्चै चाहन्छौं कि यदि कुनै पनि RAID 6 arrays मा असफलता (डेटा हानि पढ्नुहोस्) छ भने, अपरेटिङ सिस्टमले सामान्य रूपमा बुट गर्नेछ र हामीलाई समस्या समाधान गर्ने मौका दिनेछ।

यो गर्नको लागि, अमूर्तताको पहिलो स्तरमा हामी प्रत्येक प्रकारको भौतिक "मिडिया" लाई छुट्टै VG मा अलग गर्नेछौं।

वैज्ञानिक रूपमा बोल्दा, विभिन्न RAID arrayहरू विभिन्न "विश्वसनीयता डोमेनहरू" सँग सम्बन्धित छन्। तपाईंले तिनीहरूलाई एक VG मा क्र्याम गरेर तिनीहरूको लागि असफलताको अतिरिक्त साझा बिन्दु सिर्जना गर्नु हुँदैन।

"हार्डवेयर" स्तरमा LVM को उपस्थितिले हामीलाई विभिन्न RAID arrays को टुक्राहरूलाई विभिन्न तरिकामा संयोजन गरेर स्वेच्छाचारी रूपमा काट्न अनुमति दिन्छ। उदाहरणका लागि - चलाउनुहोस् एकै समयमा bcache + LVM पातलो, bcache + BTRFS, LVM क्यास + LVM पातलो, क्यासहरूसँग जटिल ZFS कन्फिगरेसन, वा यो सबै प्रयास गर्न र तुलना गर्नको लागि कुनै अन्य नरक मिश्रण।

"हार्डवेयर" स्तरमा, हामी राम्रो पुरानो "मोटा" LVM भोल्युमहरू बाहेक अरू केहि प्रयोग गर्दैनौं। यस नियमको अपवाद ब्याकअप विभाजन हुन सक्छ।

मलाई लाग्छ कि यस क्षण सम्म, धेरै पाठकहरूले पहिले नै गुँड पुतलीको बारेमा केहि शंका गर्न थालेका थिए।

SATA HDD मा LVM

#pvcreate /dev/md3
#vgcreate backup /dev/md3

फेरि नयाँ VG..?हामी साँच्चै चाहन्छौं कि यदि हामीले डाटा ब्याकअपको लागि प्रयोग गर्ने डिस्क एरे असफल भयो भने, हाम्रो अपरेटिङ सिस्टमले सामान्य रूपमा काम गर्न जारी राख्नेछ, सामान्य रूपमा गैर-ब्याकअप डेटामा पहुँच कायम राख्दै। तसर्थ, VG सक्रियता समस्याहरूबाट बच्न, हामी छुट्टै VG सिर्जना गर्छौं।

LVM क्यास सेटअप गर्दै

यसलाई क्यासिङ यन्त्रको रूपमा प्रयोग गर्न NVMe RAID 1 मा LV सिर्जना गरौं।

#lvcreate -L 70871154688B --name cache root

किन यति थोरै...?तथ्य यो हो कि हाम्रो NVMe SSD सँग पनि SLC क्यास छ। 4-बिट MLC मा खाली ठाउँ ओगटेको कारण 18 गीगाबाइट "फ्री" र 3 गीगाबाइट डायनामिक। एक पटक यो क्यास समाप्त भएपछि, NVMe SSDs हाम्रो SATA SSD भन्दा धेरै छिटो हुनेछैन। वास्तवमा, यस कारणले गर्दा, हाम्रो लागि LVM क्यास विभाजनलाई NVMe ड्राइभको SLC क्यासको आकारभन्दा दुई गुणा ठूलो बनाउनु कुनै अर्थ छैन। प्रयोग गरिएको NVMe ड्राइभहरूको लागि, लेखकले यसलाई 32-64 गीगाबाइट क्यास बनाउन उचित ठान्छ।

दिइएको विभाजन आकार 64 गीगाबाइट क्यास, क्यास मेटाडाटा, र मेटाडेटा ब्याकअप व्यवस्थित गर्न आवश्यक छ।

थप रूपमा, म नोट गर्छु कि फोहोर प्रणाली बन्द भएपछि, LVM ले सम्पूर्ण क्यासलाई फोहोरको रूपमा चिन्ह लगाउनेछ र फेरि सिङ्क्रोनाइज गर्नेछ। यसबाहेक, यो प्रत्येक पटक यो यन्त्रमा lvchange प्रयोग गर्दा प्रणाली पुन: बुट नभएसम्म दोहोर्याइनेछ। त्यसकारण, म उपयुक्त स्क्रिप्ट प्रयोग गरेर तुरुन्तै क्यास पुन: सिर्जना गर्न सिफारिस गर्दछु।

यसलाई क्यास गरिएको यन्त्रको रूपमा प्रयोग गर्न SATA RAID 6 मा LV सिर्जना गरौं।

#lvcreate -L 3298543271936B --name cache data

तीन टेराबाइट मात्र किन..?त्यसोभए, यदि आवश्यक भएमा, तपाइँ केहि अन्य आवश्यकताहरूको लागि SATA SSD RAID 6 प्रयोग गर्न सक्नुहुन्छ। क्यास स्पेसको साइज गतिशील रूपमा वृद्धि गर्न सकिन्छ, उडानमा, प्रणालीलाई रोक्न बिना। यो गर्नको लागि, तपाईंले अस्थायी रूपमा बन्द गर्न र क्यास पुन: सक्षम गर्न आवश्यक छ, तर LVM-क्यास ओभरको विशिष्ट फाइदा, उदाहरणका लागि, bcache यो उडानमा गर्न सकिन्छ।

क्यासिङका लागि नयाँ VG सिर्जना गरौं।

#pvcreate /dev/root/cache
#pvcreate /dev/data/cache
#vgcreate cache /dev/root/cache /dev/data/cache

क्यास गरिएको यन्त्रमा LV सिर्जना गरौं।

#lvcreate -L 3298539077632B --name cachedata cache /dev/data/cache

यहाँ हामीले तुरुन्तै /dev/data/cache मा सबै खाली ठाउँ लियौं ताकि अन्य सबै आवश्यक विभाजनहरू तुरुन्तै /dev/root/cache मा सिर्जना गरियो। यदि तपाईंले गलत ठाउँमा केहि सिर्जना गर्नुभयो भने, तपाइँ यसलाई pvmove प्रयोग गरेर सार्न सक्नुहुन्छ।

क्यास सिर्जना र सक्षम गरौं:

#lvcreate -y -L 64G -n cache cache /dev/root/cache
#lvcreate -y -L 1G -n cachemeta cache /dev/root/cache
#lvconvert -y --type cache-pool --cachemode writeback --chunksize 64k --poolmetadata cache/cachemeta cache/cache
#lvconvert -y --type cache --cachepool cache/cache cache/cachedata

किन यस्तो chunksize..?व्यावहारिक प्रयोगहरू मार्फत, लेखकले LVM क्यास ब्लकको साइज LVM पातलो ब्लकको साइजसँग मेल खान्छ भने उत्तम नतिजा प्राप्त हुन्छ भनेर पत्ता लगाउन सक्षम थिए। यसबाहेक, सानो आकार, राम्रो कन्फिगरेसन अनियमित रेकर्डिङ मा प्रदर्शन गर्दछ।

64k LVM पातलोको लागि अनुमति दिइएको न्यूनतम ब्लक साइज हो।

होसियार भएर लेख्नुहोला..!हो। यस प्रकारको क्यासले क्यास गरिएको यन्त्रमा लेख्ने सिङ्क्रोनाइजेसनलाई स्थगित गर्छ। यसको मतलब यदि क्यास हराएको छ भने, तपाईंले क्यास गरिएको यन्त्रमा डाटा गुमाउन सक्नुहुन्छ। पछि, लेखकले तपाइँलाई यो जोखिमको लागि क्षतिपूर्ति गर्न NVMe RAID 1 बाहेक के उपायहरू लिन सकिन्छ भनेर बताउनुहुनेछ।

यो क्यास प्रकार RAID 6 को खराब अनियमित लेखन कार्यसम्पादनको लागि क्षतिपूर्ति गर्न जानाजानी छनोट गरिएको थियो।

हामीले के पायौं जाँच गरौं:

#lvs -a -o lv_name,lv_size,devices --units B cache
LV LSize Devices
[cache] 68719476736B cache_cdata(0)
[cache_cdata] 68719476736B /dev/root/cache(0)
[cache_cmeta] 1073741824B /dev/root/cache(16384)
cachedata 3298539077632B cachedata_corig(0)
[cachedata_corig] 3298539077632B /dev/data/cache(0)
[lvol0_pmspare] 1073741824B /dev/root/cache(16640)

केवल [cachedata_corig] /dev/data/cache मा अवस्थित हुनुपर्छ। यदि केहि गलत छ भने, त्यसपछि pvmove प्रयोग गर्नुहोस्।

यदि आवश्यक भएमा एक आदेशको साथ तपाईं क्यास असक्षम गर्न सक्नुहुन्छ:

#lvconvert -y --uncache cache/cachedata

यो अनलाईन गरिन्छ। LVM ले केवल क्यासलाई डिस्कमा सिंक गर्नेछ, यसलाई हटाउनेछ, र cachedata_corig लाई क्याचेडाटामा पुन: नामाकरण गर्नेछ।

LVM पातलो सेटअप गर्दै

LVM पातलो मेटाडेटाको लागि हामीलाई कति ठाउँ चाहिन्छ लगभग अनुमान गरौं:

#thin_metadata_size --block-size=64k --pool-size=6terabytes --max-thins=100000 -u bytes
thin_metadata_size - 3385794560 bytes estimated metadata area size for "--block-size=64kibibytes --pool-size=6terabytes --max-thins=100000"

4 गीगाबाइट सम्म राउन्ड: 4294967296B

दुईले गुणन गर्नुहोस् र LVM PV मेटाडेटाको लागि 4194304B थप्नुहोस्: 8594128896B
LVM पातलो मेटाडेटा र तिनीहरूको ब्याकअप प्रतिलिपि राख्न NVMe RAID 1 मा छुट्टै विभाजन सिर्जना गरौं:

#lvcreate -L 8594128896B --name images root

के को लागि..?यहाँ प्रश्न उठ्न सक्छ: किन LVM पातलो मेटाडेटा छुट्टै राख्ने यदि यो अझै पनि NVMe मा क्यास हुनेछ र छिट्टै काम गर्नेछ।

यद्यपि गति यहाँ महत्त्वपूर्ण छ, यो मुख्य कारणबाट टाढा छ। कुरा यो हो कि क्यास असफलताको बिन्दु हो। यसमा केहि हुन सक्छ, र यदि LVM पातलो मेटाडेटा क्यास गरिएको छ भने, यसले सबै चीजहरू पूर्ण रूपमा हराउनेछ। पूर्ण मेटाडेटा बिना, पातलो भोल्युमहरू जम्मा गर्न लगभग असम्भव हुनेछ।

मेटाडेटालाई छुट्टै गैर-क्यास गरिएको, तर छिटो, भोल्युममा सारेर, हामी क्यास हराउने वा भ्रष्टाचार भएको अवस्थामा मेटाडेटाको सुरक्षाको ग्यारेन्टी गर्छौं। यस अवस्थामा, क्यास हानिको कारणले गर्दा हुने सबै क्षतिहरू पातलो भोल्युमहरूमा स्थानीयकरण गरिनेछ, जसले परिमाणको आदेशहरूद्वारा रिकभरी प्रक्रियालाई सरल बनाउनेछ। उच्च सम्भावनाको साथ, यी क्षतिहरू FS लगहरू प्रयोग गरेर पुनर्स्थापित गरिनेछ।

यसबाहेक, यदि पातलो भोल्युमको स्न्यापसट पहिले लिइएको थियो, र त्यस पछि क्यास कम्तिमा एक पटक पूर्ण रूपमा सिङ्क्रोनाइज गरिएको थियो, त्यसपछि, LVM पातलोको आन्तरिक डिजाइनको कारणले, क्यास हराएको अवस्थामा स्न्यापसटको अखण्डता ग्यारेन्टी गरिनेछ। ।

पातलो प्रावधानका लागि जिम्मेवार हुने नयाँ VG सिर्जना गरौं:

#pvcreate /dev/root/images
#pvcreate /dev/cache/cachedata
#vgcreate images /dev/root/images /dev/cache/cachedata
पोखरी बनाऔं:

#lvcreate -L 274877906944B --poolmetadataspare y --poolmetadatasize 4294967296B --chunksize 64k -Z y -T images/thin-pool
किन - Z yयो मोड वास्तवमा के को लागी अभिप्रेरित छ - स्पेस पुन: वितरण गर्दा एउटा भर्चुअल मेसिनबाट डाटा अर्को भर्चुअल मेसिनमा लीक हुनबाट रोक्नको लागि - 64k भन्दा सानो ब्लकहरूमा अनियमित लेखनको गति बढाउन शून्य प्रयोग पनि गरिन्छ। कुनै पनि पातलो भोल्युमको अघिल्लो आवंटित नगरिएको क्षेत्रमा 64k भन्दा कम लेखिएको क्यासमा 64K किनारा-पङ्क्तिबद्ध हुनेछ। यसले क्यास यन्त्रलाई बाइपास गरेर, क्यास मार्फत पूर्ण रूपमा सञ्चालन गर्न अनुमति दिनेछ।

LVs लाई सम्बन्धित PV मा सारौं:

#pvmove -n images/thin-pool_tdata /dev/root/images /dev/cache/cachedata
#pvmove -n images/lvol0_pmspare /dev/cache/cachedata /dev/root/images
#pvmove -n images/thin-pool_tmeta /dev/cache/cachedata /dev/root/images

जाँच गरौं:

#lvs -a -o lv_name,lv_size,devices --units B images
LV LSize Devices
[lvol0_pmspare] 4294967296B /dev/root/images(0)
thin-pool 274877906944B thin-pool_tdata(0)
[thin-pool_tdata] 274877906944B /dev/cache/cachedata(0)
[thin-pool_tmeta] 4294967296B /dev/root/images(1024)

परीक्षणको लागि पातलो भोल्युम सिर्जना गरौं:

#lvcreate -V 64G --thin-pool thin-pool --name test images

हामी परीक्षण र निगरानीको लागि प्याकेजहरू स्थापना गर्नेछौं:

#apt-get install sysstat fio

यसरी तपाईले वास्तविक समयमा हाम्रो भण्डारण कन्फिगरेसनको व्यवहार अवलोकन गर्न सक्नुहुन्छ:

#watch 'lvs --rows --reportformat basic --quiet -ocache_dirty_blocks,cache_settings cache/cachedata && (lvdisplay cache/cachedata | grep Cache) && (sar -p -d 2 1 | grep -E "sd|nvme|DEV|md1|md2|md3|md0" | grep -v Average | sort)'

यो हामी हाम्रो कन्फिगरेसन कसरी परीक्षण गर्न सक्छौं:

#fio --loops=1 --size=64G --runtime=4 --filename=/dev/images/test --stonewall --ioengine=libaio --direct=1
--name=4kQD32read --bs=4k --iodepth=32 --rw=randread
--name=8kQD32read --bs=8k --iodepth=32 --rw=randread
--name=16kQD32read --bs=16k --iodepth=32 --rw=randread
--name=32KQD32read --bs=32k --iodepth=32 --rw=randread
--name=64KQD32read --bs=64k --iodepth=32 --rw=randread
--name=128KQD32read --bs=128k --iodepth=32 --rw=randread
--name=256KQD32read --bs=256k --iodepth=32 --rw=randread
--name=512KQD32read --bs=512k --iodepth=32 --rw=randread
--name=4Kread --bs=4k --rw=read
--name=8Kread --bs=8k --rw=read
--name=16Kread --bs=16k --rw=read
--name=32Kread --bs=32k --rw=read
--name=64Kread --bs=64k --rw=read
--name=128Kread --bs=128k --rw=read
--name=256Kread --bs=256k --rw=read
--name=512Kread --bs=512k --rw=read
--name=Seqread --bs=1m --rw=read
--name=Longread --bs=8m --rw=read
--name=Longwrite --bs=8m --rw=write
--name=Seqwrite --bs=1m --rw=write
--name=512Kwrite --bs=512k --rw=write
--name=256write --bs=256k --rw=write
--name=128write --bs=128k --rw=write
--name=64write --bs=64k --rw=write
--name=32write --bs=32k --rw=write
--name=16write --bs=16k --rw=write
--name=8write --bs=8k --rw=write
--name=4write --bs=4k --rw=write
--name=512KQD32write --bs=512k --iodepth=32 --rw=randwrite
--name=256KQD32write --bs=256k --iodepth=32 --rw=randwrite
--name=128KQD32write --bs=128k --iodepth=32 --rw=randwrite
--name=64KQD32write --bs=64k --iodepth=32 --rw=randwrite
--name=32KQD32write --bs=32k --iodepth=32 --rw=randwrite
--name=16KQD32write --bs=16k --iodepth=32 --rw=randwrite
--name=8KQD32write --bs=8k --iodepth=32 --rw=randwrite
--name=4kQD32write --bs=4k --iodepth=32 --rw=randwrite
| grep -E 'read|write|test' | grep -v ioengine

होसियार! स्रोत!यो कोडले 36 विभिन्न परीक्षणहरू चलाउनेछ, प्रत्येक 4 सेकेन्डको लागि चलिरहेको छ। आधा परीक्षणहरू रेकर्डिङका लागि हुन्। तपाईंले 4 सेकेन्डमा NVMe मा धेरै रेकर्ड गर्न सक्नुहुन्छ। 3 गीगाबाइट प्रति सेकेन्ड सम्म। त्यसोभए, लेखन परीक्षणहरूको प्रत्येक रनले तपाइँबाट 216 गीगाबाइटको SSD संसाधन खान सक्छ।

पढ्ने र लेखन मिश्रित?हो। पढ्ने र लेख्ने परीक्षा छुट्टाछुट्टै चलाउनुको अर्थ हुन्छ। यसबाहेक, यसले सबै क्यासहरू सिङ्क्रोनाइज गरिएको छ भनेर सुनिश्चित गर्न अर्थपूर्ण हुन्छ ताकि पहिले बनाइएको लेखले पढ्नेलाई असर गर्दैन।

क्यास र पातलो भोल्युम भर्दा परिणामहरू पहिलो प्रक्षेपणको समयमा र त्यसपछिका परिणामहरू धेरै फरक हुनेछन्, र प्रणालीले अन्तिम प्रक्षेपणको समयमा भरिएको क्यासहरू सिङ्क्रोनाइज गर्न व्यवस्थित गर्यो कि गर्दैन भन्ने कुरामा निर्भर गर्दछ।

अन्य चीजहरू मध्ये, म पहिले नै पूर्ण पातलो भोल्युममा गति मापन गर्न सिफारिस गर्दछु जहाँबाट स्न्यापसट भर्खरै लिइएको थियो। लेखकले पहिलो स्न्यापसट सिर्जना गरेपछि कसरी अनियमित लेखहरू तीव्र गतिमा गति लिन्छ भनेर अवलोकन गर्ने अवसर थियो, विशेष गरी जब क्यास अझै पूर्ण रूपमा भरिएको छैन। यो प्रतिलिपि-अन-राइट लेखन अर्थशास्त्र, क्यासको पङ्क्तिबद्धता र पातलो भोल्युम ब्लकहरू, र RAID 6 मा अनियमित लेखन RAID 6 बाट अनियमित पढाइमा परिणत भएको तथ्यको कारणले हुन्छ। हाम्रो कन्फिगरेसनमा, RAID 6 बाट अनियमित पढाइ 6 गुणा (एरेमा SATA SSDs को संख्या) लेख्नु भन्दा छिटो छ। किनभने CoW को लागि ब्लकहरू पातलो पोखरीबाट क्रमिक रूपमा आवंटित हुन्छन्, त्यसपछि रेकर्डिङ, धेरै भागका लागि, क्रमिक रूपमा पनि परिणत हुन्छ।

यी दुबै सुविधाहरू तपाईंको फाइदाको लागि प्रयोग गर्न सकिन्छ।

क्यास "सुसंगत" स्न्यापसटहरू

क्यास क्षति/हानिको अवस्थामा डाटा हराउने जोखिम कम गर्न, लेखकले यस अवस्थामा तिनीहरूको अखण्डताको ग्यारेन्टी गर्न स्न्यापशटहरू घुमाउने अभ्यास पेश गर्ने प्रस्ताव गर्दछ।

पहिलो, किनकी पातलो भोल्युम मेटाडेटा अनक्याच गरिएको यन्त्रमा रहन्छ, मेटाडेटा एकरूप हुनेछ र सम्भावित हानिहरू डेटा ब्लकहरू भित्र अलग हुनेछन्।

निम्न स्न्यापसट रोटेशन चक्रले क्यास हराएको अवस्थामा स्न्यापसट भित्रको डाटाको अखण्डताको ग्यारेन्टी दिन्छ:

1. <name> नामको साथ प्रत्येक पातलो भोल्युमको लागि, नाम <name>.cached सँग स्न्यापसट सिर्जना गर्नुहोस्।
2. माइग्रेसन थ्रेसहोल्डलाई उचित उच्च मानमा सेट गरौं: #lvchange --quiet --cachesettings "migration_threshold=16384" cache/cachedata
3. लुपमा हामी क्यासमा फोहोर ब्लकहरूको संख्या जाँच गर्छौं: #lvs --rows --reportformat basic --quiet -ocache_dirty_blocks cache/cachedata | awk '{print $2}' जब सम्म हामी शून्य प्राप्त गर्दैनौं। यदि शून्य धेरै लामो समयको लागि हराइरहेको छ भने, यो क्यासलाई राइटथ्रु मोडमा अस्थायी रूपमा स्विच गरेर सिर्जना गर्न सकिन्छ। जे होस्, हाम्रो SATA र NVMe SSD arrays को गति विशेषताहरू, साथै तिनीहरूको TBW संसाधनलाई ध्यानमा राख्दै, तपाईं या त क्यास मोड परिवर्तन नगरी द्रुत रूपमा पल समात्न सक्षम हुनुहुनेछ, वा तपाईंको हार्डवेयरले यसको सम्पूर्ण स्रोत पूर्ण रूपमा खाइदिन्छ। केही दिन। स्रोत सीमितताहरूको कारण, प्रणाली, सिद्धान्तमा, 100% लेखन लोड सबै समय भन्दा कम हुन असक्षम छ। हाम्रो NVMe SSDs 100% राइट लोड अन्तर्गत स्रोत पूर्ण रूपमा समाप्त हुनेछ 3-4 दिन। SATA SSDs मात्र दुई पटक लामो हुनेछ। त्यसकारण, हामी मान्नेछौं कि अधिकांश भार पढाइमा जान्छ, र हामीसँग लेख्नको लागि औसतमा कम भारको साथ अत्यन्त उच्च गतिविधिको तुलनात्मक रूपमा छोटो अवधिको फटहरू छन्।
4. हामीले शून्य समात्ने बित्तिकै, हामीले <name>.cached लाई <name>.committed नामकरण गर्छौं। पुरानो <name>.committed मेटिएको छ।
5. वैकल्पिक रूपमा, यदि क्यास 100% भरिएको छ भने, यसलाई स्क्रिप्टद्वारा पुन: सिर्जना गर्न सकिन्छ, यसैले यसलाई खाली गर्नुहोस्। आधा-खाली क्यासको साथ, प्रणालीले लेख्दा धेरै छिटो काम गर्दछ।
6. माइग्रेसन थ्रेसहोल्डलाई शून्यमा सेट गर्नुहोस्: #lvchange --quiet --cachesettings "migration_threshold=0" cache/cachedata यसले अस्थायी रूपमा क्यासलाई मुख्य मिडियामा सिङ्क्रोनाइज गर्नबाट रोक्नेछ।
7. क्यासमा धेरै परिवर्तनहरू जम्मा नभएसम्म हामी पर्खन्छौं #lvs --rows --reportformat basic --quiet -ocache_dirty_blocks cache/cachedata | awk '{print $2}' वा टाइमर बन्द हुनेछ।
8. हामी फेरि दोहोर्याउँछौं।

माइग्रेसन थ्रेसहोल्डमा किन कठिनाइ...?कुरा यो हो कि वास्तविक अभ्यासमा, "यादृच्छिक" रेकर्डिङ वास्तवमा पूर्णतया अनियमित छैन। यदि हामीले 4 किलोबाइट साइजको सेक्टरमा केहि लेख्यौं भने, त्यहाँ एक उच्च सम्भावना छ कि अर्को दुई मिनेटमा एकै वा छिमेकी (+- 32K) क्षेत्रहरू मध्ये एकमा रेकर्ड बनाइनेछ।

माइग्रेसन थ्रेसहोल्डलाई शून्यमा सेट गरेर, हामीले SATA SSD मा लेखन सिङ्क्रोनाइजेसन स्थगित गर्छौं र क्यासमा रहेको एउटा 64K ब्लकमा धेरै परिवर्तनहरू जम्मा गर्छौं। यसले महत्त्वपूर्ण रूपमा SATA SSD को स्रोत बचत गर्छ।

कोड कहाँ छ..?दुर्भाग्यवश, लेखकले आफूलाई बास लिपिको विकासमा अपर्याप्त रूपमा सक्षम ठान्छन् किनभने उनी 100% आत्म-सिकेका छन् र "गुगल"-संचालित विकास अभ्यास गर्छन्, त्यसैले उनी विश्वास गर्छन् कि उनको हातबाट निस्केको भयानक कोड कसैले प्रयोग गर्नु हुँदैन। अरू।

मलाई लाग्छ कि यस क्षेत्रका पेशेवरहरूले माथि वर्णन गरिएका सबै तर्कहरूलाई स्वतन्त्र रूपमा चित्रण गर्न सक्षम हुनेछन्, आवश्यक भएमा, र, सायद, लेखकले गर्ने प्रयास गरे जस्तै, यसलाई प्रणालीगत सेवाको रूपमा पनि सुन्दर ढंगले डिजाइन गर्नुहोस्।

यस्तो साधारण स्न्यापसट रोटेशन योजनाले हामीलाई SATA SSD मा लगातार एउटा स्न्यापसट पूर्ण रूपमा सिङ्क्रोनाइज गर्न अनुमति दिनेछ, तर हामीलाई thin_delta उपयोगिता प्रयोग गरेर, यसको निर्माण पछि कुन ब्लकहरू परिवर्तन गरिएको थियो पत्ता लगाउन अनुमति दिनेछ, र यसरी स्थानीयकरणमा क्षति। मुख्य मात्रा, धेरै सरल रिकभरी।

libvirt/KVM मा TRIM/DSCARD

किनभने डाटा भण्डारण KVM चलिरहेको libvirt को लागी प्रयोग गरिनेछ, त्यसपछि यो हाम्रो VM लाई खाली ठाउँ लिन मात्र होइन, अब आवश्यक नभएको खाली गर्न सिकाउनु राम्रो विचार हुनेछ।

यो भर्चुअल डिस्कहरूमा TRIM/DISCARD समर्थन अनुकरण गरेर गरिन्छ। यो गर्नको लागि, तपाइँले नियन्त्रक प्रकारलाई virtio-scsi मा परिवर्तन गर्न र xml सम्पादन गर्न आवश्यक छ।

#virsh edit vmname
<disk type='block' device='disk'>
<driver name='qemu' type='raw' cache='writethrough' io='threads' discard='unmap'/>
<source dev='/dev/images/vmname'/>
<backingStore/>
<target dev='sda' bus='scsi'/>
<alias name='scsi0-0-0-0'/>
<address type='drive' controller='0' bus='0' target='0' unit='0'/>
</disk>

<controller type='scsi' index='0' model='virtio-scsi'>
<alias name='scsi0'/>
<address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x0'/>
</controller>

अतिथि OS बाट त्यस्ता DISCARD हरू LVM द्वारा सही तरिकाले प्रशोधन गरिन्छ, र ब्लकहरू क्यास र पातलो पोखरी दुवैमा सही रूपमा मुक्त हुन्छन्। हाम्रो अवस्थामा, यो मुख्यतया ढिलाइ भएको तरिकामा हुन्छ, अर्को स्न्यापसट मेटाउँदा।

BTRFS ब्याकअप

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

ब्याकअप उपकरणमा भोल्युम सिर्जना गरौं:

#lvcreate -L 256G --name backup backup

यसलाई BTRFS मा ढाँचा गरौं:

#mkfs.btrfs /dev/backup/backup

माउन्ट पोइन्टहरू सिर्जना गरौं र फाइल प्रणालीको मूल उपखण्डहरू माउन्ट गरौं:

#mkdir /backup
#mkdir /backup/btrfs
#mkdir /backup/btrfs/root
#mkdir /backup/btrfs/back
#ln -s /boot /backup/btrfs
# cat >>/etc/fstab << EOF

/dev/mapper/root-root /backup/btrfs/root btrfs defaults,space_cache,noatime,nodiratime 0 2
/dev/mapper/backup-backup /backup/btrfs/back btrfs defaults,space_cache,noatime,nodiratime 0 2
EOF
#mount -a
#update-initramfs -u
#update-grub

ब्याकअपका लागि डाइरेक्टरीहरू सिर्जना गरौं:

#mkdir /backup/btrfs/back/remote
#mkdir /backup/btrfs/back/remote/root
#mkdir /backup/btrfs/back/remote/boot

ब्याकअप स्क्रिप्टहरूको लागि डाइरेक्टरी सिर्जना गरौं:

#mkdir /root/btrfs-backup

लिपि प्रतिलिपि गरौं:

धेरै डरलाग्दो ब्याश कोड। आफ्नो जोखिममा प्रयोग गर्नुहोस्। लेखकलाई रिसाएर चिट्ठी नलेख्नुस्...#cat >/root/btrfs-backup/btrfs-backup.sh << EOF
#!/bin/bash
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

SCRIPT_FILE="$(realpath $0)"
SCRIPT_DIR="$(dirname $SCRIPT_FILE)"
SCRIPT_NAME="$(basename -s .sh $SCRIPT_FILE)"

LOCK_FILE="/dev/shm/$SCRIPT_NAME.lock"
DATE_PREFIX='%Y-%m-%d'
DATE_FORMAT=$DATE_PREFIX'-%H-%M-%S'
DATE_REGEX='[0-9][0-9][0-9][0-9]-[0-9][0-9]-[0-9][0-9]-[0-9][0-9]-[0-9][0-9]-[0-9][0-9]'
BASE_SUFFIX=".@base"
PEND_SUFFIX=".@pend"
SNAP_SUFFIX=".@snap"
MOUNTS="/backup/btrfs/"
BACKUPS="/backup/btrfs/back/remote/"

function terminate ()
{
echo "$1" >&2
exit 1
}

function wait_lock()
{
flock 98
}

function wait_lock_or_terminate()
{
echo "Wating for lock..."
wait_lock || terminate "Failed to get lock. Exiting..."
echo "Got lock..."
}

function suffix()
{
FORMATTED_DATE=$(date +"$DATE_FORMAT")
echo "$SNAP_SUFFIX.$FORMATTED_DATE"
}

function filter()
{
FORMATTED_DATE=$(date --date="$1" +"$DATE_PREFIX")
echo "$SNAP_SUFFIX.$FORMATTED_DATE"
}

function backup()
{
SOURCE_PATH="$MOUNTS$1"
TARGET_PATH="$BACKUPS$1"
SOURCE_BASE_PATH="$MOUNTS$1$BASE_SUFFIX"
TARGET_BASE_PATH="$BACKUPS$1$BASE_SUFFIX"
TARGET_BASE_DIR="$(dirname $TARGET_BASE_PATH)"
SOURCE_PEND_PATH="$MOUNTS$1$PEND_SUFFIX"
TARGET_PEND_PATH="$BACKUPS$1$PEND_SUFFIX"
if [ -d "$SOURCE_BASE_PATH" ] then
echo "$SOURCE_BASE_PATH found"
else
echo "$SOURCE_BASE_PATH File not found creating snapshot of $SOURCE_PATH to $SOURCE_BASE_PATH"
btrfs subvolume snapshot -r $SOURCE_PATH $SOURCE_BASE_PATH
sync
if [ -d "$TARGET_BASE_PATH" ] then
echo "$TARGET_BASE_PATH found out of sync with source... removing..."
btrfs subvolume delete -c $TARGET_BASE_PATH
sync
fi
fi
if [ -d "$TARGET_BASE_PATH" ] then
echo "$TARGET_BASE_PATH found"
else
echo "$TARGET_BASE_PATH not found. Synching to $TARGET_BASE_DIR"
btrfs send $SOURCE_BASE_PATH | btrfs receive $TARGET_BASE_DIR
sync
fi
if [ -d "$SOURCE_PEND_PATH" ] then
echo "$SOURCE_PEND_PATH found removing..."
btrfs subvolume delete -c $SOURCE_PEND_PATH
sync
fi
btrfs subvolume snapshot -r $SOURCE_PATH $SOURCE_PEND_PATH
sync
if [ -d "$TARGET_PEND_PATH" ] then
echo "$TARGET_PEND_PATH found removing..."
btrfs subvolume delete -c $TARGET_PEND_PATH
sync
fi
echo "Sending $SOURCE_PEND_PATH to $TARGET_PEND_PATH"
btrfs send -p $SOURCE_BASE_PATH $SOURCE_PEND_PATH | btrfs receive $TARGET_BASE_DIR
sync
TARGET_DATE_SUFFIX=$(suffix)
btrfs subvolume snapshot -r $TARGET_PEND_PATH "$TARGET_PATH$TARGET_DATE_SUFFIX"
sync
btrfs subvolume delete -c $SOURCE_BASE_PATH
sync
btrfs subvolume delete -c $TARGET_BASE_PATH
sync
mv $SOURCE_PEND_PATH $SOURCE_BASE_PATH
mv $TARGET_PEND_PATH $TARGET_BASE_PATH
sync
}

function list()
{
LIST_TARGET_BASE_PATH="$BACKUPS$1$BASE_SUFFIX"
LIST_TARGET_BASE_DIR="$(dirname $LIST_TARGET_BASE_PATH)"
LIST_TARGET_BASE_NAME="$(basename -s .$BASE_SUFFIX $LIST_TARGET_BASE_PATH)"
find "$LIST_TARGET_BASE_DIR" -maxdepth 1 -mindepth 1 -type d -printf "%fn" | grep "${LIST_TARGET_BASE_NAME/$BASE_SUFFIX/$SNAP_SUFFIX}.$DATE_REGEX"
}

function remove()
{
REMOVE_TARGET_BASE_PATH="$BACKUPS$1$BASE_SUFFIX"
REMOVE_TARGET_BASE_DIR="$(dirname $REMOVE_TARGET_BASE_PATH)"
btrfs subvolume delete -c $REMOVE_TARGET_BASE_DIR/$2
sync
}

function removeall()
{
DATE_OFFSET="$2"
FILTER="$(filter "$DATE_OFFSET")"
while read -r SNAPSHOT ; do
remove "$1" "$SNAPSHOT"
done < <(list "$1" | grep "$FILTER")

}

(
COMMAND="$1"
shift

case "$COMMAND" in
"--help")
echo "Help"
;;
"suffix")
suffix
;;
"filter")
filter "$1"
;;
"backup")
wait_lock_or_terminate
backup "$1"
;;
"list")
list "$1"
;;
"remove")
wait_lock_or_terminate
remove "$1" "$2"
;;
"removeall")
wait_lock_or_terminate
removeall "$1" "$2"
;;
*)
echo "None.."
;;
esac
) 98>$LOCK_FILE

EOF


यसले पनि के गर्छ..?BTRFS स्न्यापसटहरू सिर्जना गर्न र BTRFS पठाउने/प्राप्त गर्ने प्रयोग गरेर तिनीहरूलाई अर्को FS मा प्रतिलिपि गर्नका लागि साधारण आदेशहरूको सेट समावेश गर्दछ।

पहिलो प्रक्षेपण अपेक्षाकृत लामो हुन सक्छ, किनभने ... सुरुमा, सबै डाटा प्रतिलिपि गरिनेछ। थप प्रक्षेपणहरू धेरै छिटो हुनेछ, किनभने ... परिवर्तनहरू मात्र प्रतिलिपि हुनेछन्।

अर्को स्क्रिप्ट जुन हामी क्रोनमा राख्नेछौं:

केहि थप ब्यास कोड#cat >/root/btrfs-backup/cron-daily.sh << EOF
#!/bin/bash
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

SCRIPT_FILE="$(realpath $0)"
SCRIPT_DIR="$(dirname $SCRIPT_FILE)"
SCRIPT_NAME="$(basename -s .sh $SCRIPT_FILE)"

BACKUP_SCRIPT="$SCRIPT_DIR/btrfs-backup.sh"
RETENTION="-60 day"
$BACKUP_SCRIPT backup root/@
$BACKUP_SCRIPT removeall root/@ "$RETENTION"
$BACKUP_SCRIPT backup root/@home
$BACKUP_SCRIPT removeall root/@home "$RETENTION"
$BACKUP_SCRIPT backup boot/
$BACKUP_SCRIPT removeall boot/ "$RETENTION"
EOF


यसले के गर्छ..?ब्याकअप FS मा सूचीबद्ध BTRFS भोल्युमहरूको वृद्धिशील स्न्यापसटहरू सिर्जना र सिङ्क्रोनाइज गर्दछ। यस पछि, यसले 60 दिन अघि सिर्जना गरिएका सबै चित्रहरू मेटाउँछ। सुरुवात पछि, सूचीबद्ध भोल्युमहरूको मिति स्न्यापसटहरू /backup/btrfs/back/remote/ उपनिर्देशिकाहरूमा देखा पर्नेछ।

कोड कार्यान्वयन अधिकार दिनुहोस्:

#chmod +x /root/btrfs-backup/cron-daily.sh
#chmod +x /root/btrfs-backup/btrfs-backup.sh

यसलाई जाँच गरौं र यसलाई क्रोनमा राखौं:

#/usr/bin/nice -n 19 /usr/bin/ionice -c 3 /root/btrfs-backup/cron-daily.sh 2>&1 | /usr/bin/logger -t btrfs-backup
#cat /var/log/syslog | grep btrfs-backup
#crontab -e
0 2 * * * /usr/bin/nice -n 19 /usr/bin/ionice -c 3 /root/btrfs-backup/cron-daily.sh 2>&1 | /usr/bin/logger -t btrfs-backup


LVM पातलो ब्याकअप

ब्याकअप उपकरणमा पातलो पूल सिर्जना गरौं:

#lvcreate -L 274877906944B --poolmetadataspare y --poolmetadatasize 4294967296B --chunksize 64k -Z y -T backup/thin-pool

ddrescue स्थापना गरौं, किनकि... स्क्रिप्टहरूले यो उपकरण प्रयोग गर्नेछ:

#apt-get install gddrescue

लिपिहरूको लागि डाइरेक्टरी सिर्जना गरौं:

#mkdir /root/lvm-thin-backup

लिपिहरू प्रतिलिपि गरौं:

भित्र धेरै बास...#cat >/root/lvm-thin-backup/lvm-thin-backup.sh << EOF
#!/bin/bash
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

SCRIPT_FILE="$(realpath $0)"
SCRIPT_DIR="$(dirname $SCRIPT_FILE)"
SCRIPT_NAME="$(basename -s .sh $SCRIPT_FILE)"

LOCK_FILE="/dev/shm/$SCRIPT_NAME.lock"
DATE_PREFIX='%Y-%m-%d'
DATE_FORMAT=$DATE_PREFIX'-%H-%M-%S'
DATE_REGEX='[0-9][0-9][0-9][0-9]-[0-9][0-9]-[0-9][0-9]-[0-9][0-9]-[0-9][0-9]-[0-9][0-9]'
BASE_SUFFIX=".base"
PEND_SUFFIX=".pend"
SNAP_SUFFIX=".snap"
BACKUPS="backup"
BACKUPS_POOL="thin-pool"

export LVM_SUPPRESS_FD_WARNINGS=1

function terminate ()
{
echo "$1" >&2
exit 1
}

function wait_lock()
{
flock 98
}

function wait_lock_or_terminate()
{
echo "Wating for lock..."
wait_lock || terminate "Failed to get lock. Exiting..."
echo "Got lock..."
}

function suffix()
{
FORMATTED_DATE=$(date +"$DATE_FORMAT")
echo "$SNAP_SUFFIX.$FORMATTED_DATE"
}

function filter()
{
FORMATTED_DATE=$(date --date="$1" +"$DATE_PREFIX")
echo "$SNAP_SUFFIX.$FORMATTED_DATE"
}

function read_thin_id {
lvs --rows --reportformat basic --quiet -othin_id "$1/$2" | awk '{print $2}'
}

function read_pool_lv {
lvs --rows --reportformat basic --quiet -opool_lv "$1/$2" | awk '{print $2}'
}

function read_lv_dm_path {
lvs --rows --reportformat basic --quiet -olv_dm_path "$1/$2" | awk '{print $2}'
}

function read_lv_active {
lvs --rows --reportformat basic --quiet -olv_active "$1/$2" | awk '{print $2}'
}

function read_lv_chunk_size {
lvs --rows --reportformat basic --quiet --units b --nosuffix -ochunk_size "$1/$2" | awk '{print $2}'
}

function read_lv_size {
lvs --rows --reportformat basic --quiet --units b --nosuffix -olv_size "$1/$2" | awk '{print $2}'
}

function activate_volume {
lvchange -ay -Ky "$1/$2"
}

function deactivate_volume {
lvchange -an "$1/$2"
}

function read_thin_metadata_snap {
dmsetup status "$1" | awk '{print $7}'
}

function thindiff()
{
DIFF_VG="$1"
DIFF_SOURCE="$2"
DIFF_TARGET="$3"
DIFF_SOURCE_POOL=$(read_pool_lv $DIFF_VG $DIFF_SOURCE)
DIFF_TARGET_POOL=$(read_pool_lv $DIFF_VG $DIFF_TARGET)

if [ "$DIFF_SOURCE_POOL" == "" ] then
(>&2 echo "Source LV is not thin.")
exit 1
fi

if [ "$DIFF_TARGET_POOL" == "" ] then
(>&2 echo "Target LV is not thin.")
exit 1
fi

if [ "$DIFF_SOURCE_POOL" != "$DIFF_TARGET_POOL" ] then
(>&2 echo "Source and target LVs belong to different thin pools.")
exit 1
fi

DIFF_POOL_PATH=$(read_lv_dm_path $DIFF_VG $DIFF_SOURCE_POOL)
DIFF_SOURCE_ID=$(read_thin_id $DIFF_VG $DIFF_SOURCE)
DIFF_TARGET_ID=$(read_thin_id $DIFF_VG $DIFF_TARGET)
DIFF_POOL_PATH_TPOOL="$DIFF_POOL_PATH-tpool"
DIFF_POOL_PATH_TMETA="$DIFF_POOL_PATH"_tmeta
DIFF_POOL_METADATA_SNAP=$(read_thin_metadata_snap $DIFF_POOL_PATH_TPOOL)

if [ "$DIFF_POOL_METADATA_SNAP" != "-" ] then
(>&2 echo "Thin pool metadata snapshot already exist. Assuming stale one. Will release metadata snapshot in 5 seconds.")
sleep 5
dmsetup message $DIFF_POOL_PATH_TPOOL 0 release_metadata_snap
fi

dmsetup message $DIFF_POOL_PATH_TPOOL 0 reserve_metadata_snap
DIFF_POOL_METADATA_SNAP=$(read_thin_metadata_snap $DIFF_POOL_PATH_TPOOL)

if [ "$DIFF_POOL_METADATA_SNAP" == "-" ] then
(>&2 echo "Failed to create thin pool metadata snapshot.")
exit 1
fi

#We keep output in variable because metadata snapshot need to be released early.
DIFF_DATA=$(thin_delta -m$DIFF_POOL_METADATA_SNAP --snap1 $DIFF_SOURCE_ID --snap2 $DIFF_TARGET_ID $DIFF_POOL_PATH_TMETA)

dmsetup message $DIFF_POOL_PATH_TPOOL 0 release_metadata_snap

echo $"$DIFF_DATA" | grep -E 'different|left_only|right_only' | sed 's/</"/g' | sed 's/ /"/g' | awk -F'"' '{print $6 "t" $8 "t" $11}' | sed 's/different/copy/g' | sed 's/left_only/copy/g' | sed 's/right_only/discard/g'

}

function thinsync()
{
SYNC_VG="$1"
SYNC_PEND="$2"
SYNC_BASE="$3"
SYNC_TARGET="$4"
SYNC_PEND_POOL=$(read_pool_lv $SYNC_VG $SYNC_PEND)
SYNC_BLOCK_SIZE=$(read_lv_chunk_size $SYNC_VG $SYNC_PEND_POOL)
SYNC_PEND_PATH=$(read_lv_dm_path $SYNC_VG $SYNC_PEND)

activate_volume $SYNC_VG $SYNC_PEND

while read -r SYNC_ACTION SYNC_OFFSET SYNC_LENGTH ; do
SYNC_OFFSET_BYTES=$((SYNC_OFFSET * SYNC_BLOCK_SIZE))
SYNC_LENGTH_BYTES=$((SYNC_LENGTH * SYNC_BLOCK_SIZE))
if [ "$SYNC_ACTION" == "copy" ] then
ddrescue --quiet --force --input-position=$SYNC_OFFSET_BYTES --output-position=$SYNC_OFFSET_BYTES --size=$SYNC_LENGTH_BYTES "$SYNC_PEND_PATH" "$SYNC_TARGET"
fi

if [ "$SYNC_ACTION" == "discard" ] then
blkdiscard -o $SYNC_OFFSET_BYTES -l $SYNC_LENGTH_BYTES "$SYNC_TARGET"
fi
done < <(thindiff "$SYNC_VG" "$SYNC_PEND" "$SYNC_BASE")
}

function discard_volume()
{
DISCARD_VG="$1"
DISCARD_LV="$2"
DISCARD_LV_PATH=$(read_lv_dm_path "$DISCARD_VG" "$DISCARD_LV")
if [ "$DISCARD_LV_PATH" != "" ] then
echo "$DISCARD_LV_PATH found"
else
echo "$DISCARD_LV not found in $DISCARD_VG"
exit 1
fi
DISCARD_LV_POOL=$(read_pool_lv $DISCARD_VG $DISCARD_LV)
DISCARD_LV_SIZE=$(read_lv_size "$DISCARD_VG" "$DISCARD_LV")
lvremove -y --quiet "$DISCARD_LV_PATH" || exit 1
lvcreate --thin-pool "$DISCARD_LV_POOL" -V "$DISCARD_LV_SIZE"B --name "$DISCARD_LV" "$DISCARD_VG" || exit 1
}

function backup()
{
SOURCE_VG="$1"
SOURCE_LV="$2"
TARGET_VG="$BACKUPS"
TARGET_LV="$SOURCE_VG-$SOURCE_LV"
SOURCE_BASE_LV="$SOURCE_LV$BASE_SUFFIX"
TARGET_BASE_LV="$TARGET_LV$BASE_SUFFIX"
SOURCE_PEND_LV="$SOURCE_LV$PEND_SUFFIX"
TARGET_PEND_LV="$TARGET_LV$PEND_SUFFIX"
SOURCE_BASE_LV_PATH=$(read_lv_dm_path "$SOURCE_VG" "$SOURCE_BASE_LV")
SOURCE_PEND_LV_PATH=$(read_lv_dm_path "$SOURCE_VG" "$SOURCE_PEND_LV")
TARGET_BASE_LV_PATH=$(read_lv_dm_path "$TARGET_VG" "$TARGET_BASE_LV")
TARGET_PEND_LV_PATH=$(read_lv_dm_path "$TARGET_VG" "$TARGET_PEND_LV")

if [ "$SOURCE_BASE_LV_PATH" != "" ] then
echo "$SOURCE_BASE_LV_PATH found"
else
echo "Source base not found creating snapshot of $SOURCE_VG/$SOURCE_LV to $SOURCE_VG/$SOURCE_BASE_LV"
lvcreate --quiet --snapshot --name "$SOURCE_BASE_LV" "$SOURCE_VG/$SOURCE_LV" || exit 1
SOURCE_BASE_LV_PATH=$(read_lv_dm_path "$SOURCE_VG" "$SOURCE_BASE_LV")
activate_volume "$SOURCE_VG" "$SOURCE_BASE_LV"
echo "Discarding $SOURCE_BASE_LV_PATH as we need to bootstrap."
SOURCE_BASE_POOL=$(read_pool_lv $SOURCE_VG $SOURCE_BASE_LV)
SOURCE_BASE_CHUNK_SIZE=$(read_lv_chunk_size $SOURCE_VG $SOURCE_BASE_POOL)
discard_volume "$SOURCE_VG" "$SOURCE_BASE_LV"
sync
if [ "$TARGET_BASE_LV_PATH" != "" ] then
echo "$TARGET_BASE_LV_PATH found out of sync with source... removing..."
lvremove -y --quiet $TARGET_BASE_LV_PATH || exit 1
TARGET_BASE_LV_PATH=$(read_lv_dm_path "$TARGET_VG" "$TARGET_BASE_LV")
sync
fi
fi
SOURCE_BASE_SIZE=$(read_lv_size "$SOURCE_VG" "$SOURCE_BASE_LV")
if [ "$TARGET_BASE_LV_PATH" != "" ] then
echo "$TARGET_BASE_LV_PATH found"
else
echo "$TARGET_VG/$TARGET_LV not found. Creating empty volume."
lvcreate --thin-pool "$BACKUPS_POOL" -V "$SOURCE_BASE_SIZE"B --name "$TARGET_BASE_LV" "$TARGET_VG" || exit 1
echo "Have to rebootstrap. Discarding source at $SOURCE_BASE_LV_PATH"
activate_volume "$SOURCE_VG" "$SOURCE_BASE_LV"
SOURCE_BASE_POOL=$(read_pool_lv $SOURCE_VG $SOURCE_BASE_LV)
SOURCE_BASE_CHUNK_SIZE=$(read_lv_chunk_size $SOURCE_VG $SOURCE_BASE_POOL)
discard_volume "$SOURCE_VG" "$SOURCE_BASE_LV"
TARGET_BASE_POOL=$(read_pool_lv $TARGET_VG $TARGET_BASE_LV)
TARGET_BASE_CHUNK_SIZE=$(read_lv_chunk_size $TARGET_VG $TARGET_BASE_POOL)
TARGET_BASE_LV_PATH=$(read_lv_dm_path "$TARGET_VG" "$TARGET_BASE_LV")
echo "Discarding target at $TARGET_BASE_LV_PATH"
discard_volume "$TARGET_VG" "$TARGET_BASE_LV"
sync
fi
if [ "$SOURCE_PEND_LV_PATH" != "" ] then
echo "$SOURCE_PEND_LV_PATH found removing..."
lvremove -y --quiet "$SOURCE_PEND_LV_PATH" || exit 1
sync
fi
lvcreate --quiet --snapshot --name "$SOURCE_PEND_LV" "$SOURCE_VG/$SOURCE_LV" || exit 1
SOURCE_PEND_LV_PATH=$(read_lv_dm_path "$SOURCE_VG" "$SOURCE_PEND_LV")
sync
if [ "$TARGET_PEND_LV_PATH" != "" ] then
echo "$TARGET_PEND_LV_PATH found removing..."
lvremove -y --quiet $TARGET_PEND_LV_PATH
sync
fi
lvcreate --quiet --snapshot --name "$TARGET_PEND_LV" "$TARGET_VG/$TARGET_BASE_LV" || exit 1
TARGET_PEND_LV_PATH=$(read_lv_dm_path "$TARGET_VG" "$TARGET_PEND_LV")
SOURCE_PEND_LV_SIZE=$(read_lv_size "$SOURCE_VG" "$SOURCE_PEND_LV")
lvresize -L "$SOURCE_PEND_LV_SIZE"B "$TARGET_PEND_LV_PATH"
activate_volume "$TARGET_VG" "$TARGET_PEND_LV"
echo "Synching $SOURCE_PEND_LV_PATH to $TARGET_PEND_LV_PATH"
thinsync "$SOURCE_VG" "$SOURCE_PEND_LV" "$SOURCE_BASE_LV" "$TARGET_PEND_LV_PATH" || exit 1
sync

TARGET_DATE_SUFFIX=$(suffix)
lvcreate --quiet --snapshot --name "$TARGET_LV$TARGET_DATE_SUFFIX" "$TARGET_VG/$TARGET_PEND_LV" || exit 1
sync
lvremove --quiet -y "$SOURCE_BASE_LV_PATH" || exit 1
sync
lvremove --quiet -y "$TARGET_BASE_LV_PATH" || exit 1
sync
lvrename -y "$SOURCE_VG/$SOURCE_PEND_LV" "$SOURCE_BASE_LV" || exit 1
lvrename -y "$TARGET_VG/$TARGET_PEND_LV" "$TARGET_BASE_LV" || exit 1
sync
deactivate_volume "$TARGET_VG" "$TARGET_BASE_LV"
deactivate_volume "$SOURCE_VG" "$SOURCE_BASE_LV"
}

function verify()
{
SOURCE_VG="$1"
SOURCE_LV="$2"
TARGET_VG="$BACKUPS"
TARGET_LV="$SOURCE_VG-$SOURCE_LV"
SOURCE_BASE_LV="$SOURCE_LV$BASE_SUFFIX"
TARGET_BASE_LV="$TARGET_LV$BASE_SUFFIX"
TARGET_BASE_LV_PATH=$(read_lv_dm_path "$TARGET_VG" "$TARGET_BASE_LV")
SOURCE_BASE_LV_PATH=$(read_lv_dm_path "$SOURCE_VG" "$SOURCE_BASE_LV")

if [ "$SOURCE_BASE_LV_PATH" != "" ] then
echo "$SOURCE_BASE_LV_PATH found"
else
echo "$SOURCE_BASE_LV_PATH not found"
exit 1
fi
if [ "$TARGET_BASE_LV_PATH" != "" ] then
echo "$TARGET_BASE_LV_PATH found"
else
echo "$TARGET_BASE_LV_PATH not found"
exit 1
fi
activate_volume "$TARGET_VG" "$TARGET_BASE_LV"
activate_volume "$SOURCE_VG" "$SOURCE_BASE_LV"
echo Comparing "$SOURCE_BASE_LV_PATH" with "$TARGET_BASE_LV_PATH"
cmp "$SOURCE_BASE_LV_PATH" "$TARGET_BASE_LV_PATH"
echo Done...
deactivate_volume "$TARGET_VG" "$TARGET_BASE_LV"
deactivate_volume "$SOURCE_VG" "$SOURCE_BASE_LV"
}

function resync()
{
SOURCE_VG="$1"
SOURCE_LV="$2"
TARGET_VG="$BACKUPS"
TARGET_LV="$SOURCE_VG-$SOURCE_LV"
SOURCE_BASE_LV="$SOURCE_LV$BASE_SUFFIX"
TARGET_BASE_LV="$TARGET_LV$BASE_SUFFIX"
TARGET_BASE_LV_PATH=$(read_lv_dm_path "$TARGET_VG" "$TARGET_BASE_LV")
SOURCE_BASE_LV_PATH=$(read_lv_dm_path "$SOURCE_VG" "$SOURCE_BASE_LV")

if [ "$SOURCE_BASE_LV_PATH" != "" ] then
echo "$SOURCE_BASE_LV_PATH found"
else
echo "$SOURCE_BASE_LV_PATH not found"
exit 1
fi
if [ "$TARGET_BASE_LV_PATH" != "" ] then
echo "$TARGET_BASE_LV_PATH found"
else
echo "$TARGET_BASE_LV_PATH not found"
exit 1
fi
activate_volume "$TARGET_VG" "$TARGET_BASE_LV"
activate_volume "$SOURCE_VG" "$SOURCE_BASE_LV"
SOURCE_BASE_POOL=$(read_pool_lv $SOURCE_VG $SOURCE_BASE_LV)
SYNC_BLOCK_SIZE=$(read_lv_chunk_size $SOURCE_VG $SOURCE_BASE_POOL)

echo Syncronizing "$SOURCE_BASE_LV_PATH" to "$TARGET_BASE_LV_PATH"

CMP_OFFSET=0
while [[ "$CMP_OFFSET" != "" ]] ; do
CMP_MISMATCH=$(cmp -i "$CMP_OFFSET" "$SOURCE_BASE_LV_PATH" "$TARGET_BASE_LV_PATH" | grep differ | awk '{print $5}' | sed 's/,//g' )
if [[ "$CMP_MISMATCH" != "" ]] ; then
CMP_OFFSET=$(( CMP_MISMATCH + CMP_OFFSET ))
SYNC_OFFSET_BYTES=$(( ( CMP_OFFSET / SYNC_BLOCK_SIZE ) * SYNC_BLOCK_SIZE ))
SYNC_LENGTH_BYTES=$(( SYNC_BLOCK_SIZE ))
echo "Synching $SYNC_LENGTH_BYTES bytes at $SYNC_OFFSET_BYTES from $SOURCE_BASE_LV_PATH to $TARGET_BASE_LV_PATH"
ddrescue --quiet --force --input-position=$SYNC_OFFSET_BYTES --output-position=$SYNC_OFFSET_BYTES --size=$SYNC_LENGTH_BYTES "$SOURCE_BASE_LV_PATH" "$TARGET_BASE_LV_PATH"
else
CMP_OFFSET=""
fi
done
echo Done...
deactivate_volume "$TARGET_VG" "$TARGET_BASE_LV"
deactivate_volume "$SOURCE_VG" "$SOURCE_BASE_LV"
}

function list()
{
LIST_SOURCE_VG="$1"
LIST_SOURCE_LV="$2"
LIST_TARGET_VG="$BACKUPS"
LIST_TARGET_LV="$LIST_SOURCE_VG-$LIST_SOURCE_LV"
LIST_TARGET_BASE_LV="$LIST_TARGET_LV$SNAP_SUFFIX"
lvs -olv_name | grep "$LIST_TARGET_BASE_LV.$DATE_REGEX"
}

function remove()
{
REMOVE_TARGET_VG="$BACKUPS"
REMOVE_TARGET_LV="$1"
lvremove -y "$REMOVE_TARGET_VG/$REMOVE_TARGET_LV"
sync
}

function removeall()
{
DATE_OFFSET="$3"
FILTER="$(filter "$DATE_OFFSET")"
while read -r SNAPSHOT ; do
remove "$SNAPSHOT"
done < <(list "$1" "$2" | grep "$FILTER")

}

(
COMMAND="$1"
shift

case "$COMMAND" in
"--help")
echo "Help"
;;
"suffix")
suffix
;;
"filter")
filter "$1"
;;
"backup")
wait_lock_or_terminate
backup "$1" "$2"
;;
"list")
list "$1" "$2"
;;
"thindiff")
thindiff "$1" "$2" "$3"
;;
"thinsync")
thinsync "$1" "$2" "$3" "$4"
;;
"verify")
wait_lock_or_terminate
verify "$1" "$2"
;;
"resync")
wait_lock_or_terminate
resync "$1" "$2"
;;
"remove")
wait_lock_or_terminate
remove "$1"
;;
"removeall")
wait_lock_or_terminate
removeall "$1" "$2" "$3"
;;
*)
echo "None.."
;;
esac
) 98>$LOCK_FILE

EOF


यसले के गर्छ...?पातलो स्न्यापसटहरू हेरफेर गर्न र thin_delta मार्फत प्राप्त दुई पातलो स्न्यापसटहरू बीचको भिन्नतालाई ddrescue र blkdiscard प्रयोग गरेर अर्को ब्लक उपकरणमा सिङ्क्रोनाइज गर्न आदेशहरूको सेट समावेश गर्दछ।

अर्को स्क्रिप्ट जुन हामी क्रोनमा राख्नेछौं:

अलि बढि बास#cat >/root/lvm-thin-backup/cron-daily.sh << EOF
#!/bin/bash
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

SCRIPT_FILE="$(realpath $0)"
SCRIPT_DIR="$(dirname $SCRIPT_FILE)"
SCRIPT_NAME="$(basename -s .sh $SCRIPT_FILE)"

BACKUP_SCRIPT="$SCRIPT_DIR/lvm-thin-backup.sh"
RETENTION="-60 days"

$BACKUP_SCRIPT backup images linux-dev
$BACKUP_SCRIPT backup images win8
$BACKUP_SCRIPT backup images win8-data
#etc

$BACKUP_SCRIPT removeall images linux-dev "$RETENTION"
$BACKUP_SCRIPT removeall images win8 "$RETENTION"
$BACKUP_SCRIPT removeall images win8-data "$RETENTION"
#etc

EOF


यसले के गर्छ...?सूचीबद्ध पातलो भोल्युमहरूको ब्याकअपहरू सिर्जना गर्न र सिङ्क्रोनाइज गर्न अघिल्लो स्क्रिप्ट प्रयोग गर्दछ। स्क्रिप्टले सूचीबद्ध भोल्युमहरूको निष्क्रिय स्न्यापसटहरू छोड्नेछ, जुन पछिल्लो सिङ्क्रोनाइजेसन पछि परिवर्तनहरू ट्र्याक गर्न आवश्यक छ।

ब्याकअप प्रतिलिपिहरू बनाउनु पर्ने पातलो भोल्युमहरूको सूची निर्दिष्ट गर्दै यो लिपि सम्पादन गर्नुपर्छ। दिइएका नामहरू उदाहरणका लागि मात्र हुन्। यदि तपाइँ चाहनुहुन्छ भने, तपाइँ एक स्क्रिप्ट लेख्न सक्नुहुन्छ जुन सबै भोल्युमहरू सिङ्क्रोनाइज हुनेछ।

अधिकार दिऔं:

#chmod +x /root/lvm-thin-backup/cron-daily.sh
#chmod +x /root/lvm-thin-backup/lvm-thin-backup.sh

यसलाई जाँच गरौं र यसलाई क्रोनमा राखौं:

#/usr/bin/nice -n 19 /usr/bin/ionice -c 3 /root/lvm-thin-backup/cron-daily.sh 2>&1 | /usr/bin/logger -t lvm-thin-backup
#cat /var/log/syslog | grep lvm-thin-backup
#crontab -e
0 3 * * * /usr/bin/nice -n 19 /usr/bin/ionice -c 3 /root/lvm-thin-backup/cron-daily.sh 2>&1 | /usr/bin/logger -t lvm-thin-backup

पहिलो प्रक्षेपण लामो हुनेछ, किनभने ... पातलो भोल्युमहरू सबै प्रयोग गरिएको ठाउँ प्रतिलिपि गरेर पूर्ण रूपमा सिङ्क्रोनाइज हुनेछन्। LVM पातलो मेटाडेटाको लागि धन्यवाद, हामीलाई थाहा छ कुन ब्लकहरू वास्तवमा प्रयोगमा छन्, त्यसैले वास्तवमा प्रयोग गरिएका पातलो भोल्युम ब्लकहरू मात्र प्रतिलिपि गरिनेछ।

LVM पातलो मेटाडेटा मार्फत ट्र्याकिङ परिवर्तन गर्नको लागि पछिको रनहरूले डेटालाई क्रमशः प्रतिलिपि गर्नेछ।

के भयो हेरौं:

#time /root/btrfs-backup/cron-daily.sh
real 0m2,967s
user 0m0,225s
sys 0m0,353s

#time /root/lvm-thin-backup/cron-daily.sh
real 1m2,710s
user 0m12,721s
sys 0m6,671s

#ls -al /backup/btrfs/back/remote/*
/backup/btrfs/back/remote/boot:
total 0
drwxr-xr-x 1 root root 1260 мар 26 09:11 .
drwxr-xr-x 1 root root 16 мар 6 09:30 ..
drwxr-xr-x 1 root root 322 мар 26 02:00 .@base
drwxr-xr-x 1 root root 516 мар 6 09:39 [email protected]
drwxr-xr-x 1 root root 516 мар 6 09:39 [email protected]
...
/backup/btrfs/back/remote/root:
total 0
drwxr-xr-x 1 root root 2820 мар 26 09:11 .
drwxr-xr-x 1 root root 16 мар 6 09:30 ..
drwxr-xr-x 1 root root 240 мар 26 09:11 @.@base
drwxr-xr-x 1 root root 22 мар 26 09:11 @home.@base
drwxr-xr-x 1 root root 22 мар 6 09:39 @[email protected]
drwxr-xr-x 1 root root 22 мар 6 09:39 @[email protected]
...
drwxr-xr-x 1 root root 240 мар 6 09:39 @[email protected]
drwxr-xr-x 1 root root 240 мар 6 09:39 @[email protected]
...

#lvs -olv_name,lv_size images && lvs -olv_name,lv_size backup
LV LSize
linux-dev 128,00g
linux-dev.base 128,00g
thin-pool 1,38t
win8 128,00g
win8-data 2,00t
win8-data.base 2,00t
win8.base 128,00g
LV LSize
backup 256,00g
images-linux-dev.base 128,00g
images-linux-dev.snap.2020-03-08-10-09-11 128,00g
images-linux-dev.snap.2020-03-08-10-09-25 128,00g
...
images-win8-data.base 2,00t
images-win8-data.snap.2020-03-16-14-11-55 2,00t
images-win8-data.snap.2020-03-16-14-19-50 2,00t
...
images-win8.base 128,00g
images-win8.snap.2020-03-17-04-51-46 128,00g
images-win8.snap.2020-03-18-03-02-49 128,00g
...
thin-pool <2,09t


यो गुँड गुडिया संग के सम्बन्ध छ?

सम्भवतः, LVM LV तार्किक भोल्युमहरू अन्य VG हरूका लागि LVM PV भौतिक भोल्युमहरू हुन सक्छन् भन्ने दिईएको छ। LVM पुनरावर्ती हुन सक्छ, गुडिया गुडिया जस्तै। यसले LVM चरम लचिलोपन दिन्छ।

PS

अर्को लेखमा, हामी गृह डेस्कटपहरू, गृह इन्टरनेट र P2P नेटवर्कहरू प्रयोग गरेर धेरै महाद्वीपहरूमा रिडन्डन्सीको साथ भू-वितरित भण्डारण/vm क्लस्टर सिर्जना गर्ने आधारको रूपमा धेरै समान मोबाइल भण्डारण प्रणालीहरू/KVM प्रयोग गर्ने प्रयास गर्नेछौं।

स्रोत: www.habr.com