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 એરે બનાવી રહ્યા છે.
• જ્યારે BIOS માં NVMe સપોર્ટ ન હોય ત્યારે NVMe RAID 1 પર સિસ્ટમ ઇન્સ્ટોલ કરી રહ્યું છે.
• LVM કેશ અને LVM પાતળું વાપરીને.
• BTRFS સ્નેપશોટનો ઉપયોગ કરીને અને બેકઅપ માટે મોકલો/પ્રાપ્ત કરો.
• BTRFS શૈલી બેકઅપ માટે LVM પાતળા સ્નેપશોટ અને thin_delta નો ઉપયોગ.

જો તમને રસ હોય, તો કૃપા કરીને બિલાડી જુઓ.

અરજી ફોર્મ

આ લેખમાંથી સામગ્રી/ઉદાહરણો/કોડ/ટીપ્સ/ડેટાનો ઉપયોગ કરવા અથવા ન કરવાના પરિણામો માટે લેખક કોઈ જવાબદારી સહન કરતું નથી. આ સામગ્રીને કોઈપણ રીતે વાંચીને અથવા તેનો ઉપયોગ કરીને, તમે આ ક્રિયાઓના તમામ પરિણામો માટે જવાબદારી સ્વીકારો છો. સંભવિત પરિણામોમાં શામેલ છે:

• ચપળ-તળેલી NVMe SSDs.
• રેકોર્ડિંગ સંસાધનનો સંપૂર્ણ ઉપયોગ અને SSD ડ્રાઇવની નિષ્ફળતા.
• બેકઅપ નકલો સહિત તમામ ડ્રાઇવ્સ પરના તમામ ડેટાની સંપૂર્ણ ખોટ.
• ખામીયુક્ત કમ્પ્યુટર હાર્ડવેર.
• સમય, જ્ઞાનતંતુ અને પૈસાનો બગાડ.
• કોઈપણ અન્ય પરિણામો કે જે ઉપર સૂચિબદ્ધ નથી.

આયર્ન

ઉપલબ્ધ હતા:

Z2013 ચિપસેટ સાથે 87 નું મધરબોર્ડ, Intel Core i7 / Haswell સાથે પૂર્ણ.

• પ્રોસેસર 4 કોરો, 8 થ્રેડો
• 32 જીબી ડીડીઆર 3 રેમ
• 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 એરેમાં હતી. નવી સિસ્ટમમાં તેનો પણ ઉપયોગ થશે. સ્થાનિક બેકઅપ સંગ્રહવા માટે.

વધુમાં ઉમેર્યું:

6 ટુકડાઓ SATA SSD મોડેલ Samsung 860 QVO 2TB. આ SSD ને મોટી માત્રા, SLC કેશની હાજરી, વિશ્વસનીયતા અને ઓછી કિંમતની જરૂર હતી. કાઢી નાખો/શૂન્ય માટે આધાર જરૂરી હતો, જે dmesg માં લાઇન દ્વારા તપાસવામાં આવે છે:

kernel: ata1.00: Enabling discard_zeroes_data

NVMe SSD મોડલ Samsung SSD 2 EVO 970GB ના 500 ટુકડાઓ.

આ SSDs માટે, તમારી જરૂરિયાતો માટે રેન્ડમ વાંચન/લખવાની ઝડપ અને સંસાધન ક્ષમતા મહત્વપૂર્ણ છે. તેમના માટે રેડિયેટર. જરૂરી. સંપૂર્ણપણે. નહિંતર, પ્રથમ RAID સિંક્રનાઇઝેશન દરમિયાન તેમને ક્રિસ્પી થાય ત્યાં સુધી ફ્રાય કરો.

PCIe 8 2x સ્લોટમાં ઇન્સ્ટોલ કરેલ 2 x NVMe SSD માટે StarTech PEX2M3.0E8 એડેપ્ટર. આ, ફરીથી, માત્ર એક HBA છે, પરંતુ NVMe માટે. તે સસ્તા એડેપ્ટરોથી અલગ છે જેમાં બિલ્ટ-ઇન PCIe સ્વીચની હાજરીને કારણે તેને મધરબોર્ડથી PCIe દ્વિભાજન સપોર્ટની જરૂર નથી. તે PCIe સાથે સૌથી પ્રાચીન સિસ્ટમમાં પણ કામ કરશે, પછી ભલે તે x1 PCIe 1.0 સ્લોટ હોય. સ્વાભાવિક રીતે, યોગ્ય ઝડપે. ત્યાં કોઈ RAID નથી. બોર્ડ પર કોઈ બિલ્ટ-ઇન BIOS નથી. તેથી, તમારી સિસ્ટમ જાદુઈ રીતે NVMe સાથે બુટ કરવાનું શીખશે નહીં, આ ઉપકરણને આભારી NVMe RAID ઘણું ઓછું છે.

આ ઘટક ફક્ત સિસ્ટમમાં માત્ર એક મફત 8x PCIe 3.0 ની હાજરીને કારણે હતું, અને, જો ત્યાં 2 મફત સ્લોટ હોય, તો તેને સરળતાથી બે પેની PEX4M2E1 અથવા એનાલોગ સાથે બદલી શકાય છે, જે 600ની કિંમતે ગમે ત્યાં ખરીદી શકાય છે. રૂબલ

તમામ પ્રકારના હાર્ડવેર અથવા બિલ્ટ-ઇન ચિપસેટ/BIOS RAID નો અસ્વીકાર ઇરાદાપૂર્વક કરવામાં આવ્યો હતો, જેથી તમામ ડેટાને સાચવીને, SSD/HDDના અપવાદ સિવાય, સમગ્ર સિસ્ટમને સંપૂર્ણપણે બદલી શકાય. આદર્શરીતે, જેથી તમે સંપૂર્ણપણે નવા/વિવિધ હાર્ડવેર પર જતી વખતે સ્થાપિત ઓપરેટિંગ સિસ્ટમને પણ સાચવી શકો. મુખ્ય વસ્તુ એ છે કે ત્યાં SATA અને PCIe પોર્ટ છે. તે લાઈવ સીડી અથવા બુટ કરી શકાય તેવી ફ્લેશ ડ્રાઈવ જેવી છે, માત્ર ખૂબ જ ઝડપી અને થોડી મોટી.

વિનોદીનહિંતર, તમે જાણો છો કે શું થાય છે - કેટલીકવાર તમારે તાકીદે સમગ્ર એરેને તમારી સાથે લઈ જવાની જરૂર પડે છે. પરંતુ હું ડેટા ગુમાવવા માંગતો નથી. આ કરવા માટે, તમામ ઉલ્લેખિત માધ્યમો પ્રમાણભૂત કેસની 5.25 બેઝમાં સ્લાઇડ્સ પર અનુકૂળ રીતે સ્થિત છે.

સારું, અને, અલબત્ત, Linux માં SSD કેશીંગની વિવિધ પદ્ધતિઓ સાથે પ્રયોગ કરવા માટે.

હાર્ડવેર દરોડા કંટાળાજનક છે. ચાલુ કરો. તે કાં તો કામ કરે છે અથવા તે નથી કરતું. અને mdadm સાથે હંમેશા વિકલ્પો હોય છે.

સોફ્ટવેર

અગાઉ, ડેબિયન 8 જેસી હાર્ડવેર પર ઇન્સ્ટોલ કરવામાં આવ્યું હતું, જે EOL ની નજીક છે. RAID 6 એ LVM સાથે જોડાયેલ ઉપરોક્ત HDDs માંથી એસેમ્બલ કરવામાં આવ્યું હતું. તે વર્ચ્યુઅલ મશીનો kvm/libvirt માં ચલાવે છે.

કારણ કે લેખકને પોર્ટેબલ બૂટેબલ SATA/NVMe ફ્લેશ ડ્રાઇવ્સ બનાવવાનો યોગ્ય અનુભવ છે, અને સામાન્ય યોગ્ય નમૂનાને ન તોડવા માટે, ઉબુન્ટુ 18.04 ને લક્ષ્ય સિસ્ટમ તરીકે પસંદ કરવામાં આવ્યું હતું, જે પહેલાથી જ પૂરતા પ્રમાણમાં સ્થિર થઈ ગયું છે, પરંતુ હજુ પણ 3 વર્ષ છે. ભવિષ્યમાં સપોર્ટ.

ઉલ્લેખિત સિસ્ટમમાં બધા હાર્ડવેર ડ્રાઇવરો છે જે આપણને બોક્સની બહારની જરૂર છે. અમને કોઈ તૃતીય-પક્ષ સૉફ્ટવેર અથવા ડ્રાઇવરની જરૂર નથી.

સ્થાપન માટે તૈયારી કરી રહ્યા છીએ

સિસ્ટમ ઇન્સ્ટોલ કરવા માટે અમને ઉબુન્ટુ ડેસ્કટોપ ઇમેજની જરૂર છે. સર્વર સિસ્ટમમાં અમુક પ્રકારનું જોરશોરથી ઇન્સ્ટોલર હોય છે, જે અતિશય સ્વતંત્રતા દર્શાવે છે કે જે UEFI સિસ્ટમ પાર્ટીશનને એક ડિસ્ક પર હલાવીને બધી સુંદરતાને બગાડીને અક્ષમ કરી શકાતી નથી. તદનુસાર, તે ફક્ત UEFI મોડમાં ઇન્સ્ટોલ કરેલું છે. કોઈપણ વિકલ્પો ઓફર કરતું નથી.

અમે આનાથી ખુશ નથી.

શા માટે?કમનસીબે, UEFI બુટ બુટ સોફ્ટવેર RAID સાથે અત્યંત ખરાબ રીતે સુસંગત છે, કારણ કે... UEFI ESP પાર્ટીશન માટે કોઈ અમને રિઝર્વેશન ઓફર કરતું નથી. ઑનલાઇન વાનગીઓ છે જે USB પોર્ટમાં ફ્લેશ ડ્રાઇવ પર ESP પાર્ટીશન મૂકવાનું સૂચન કરે છે, પરંતુ આ નિષ્ફળતાનો મુદ્દો છે. મેટાડેટા સંસ્કરણ 1 સાથે સોફ્ટવેર mdadm RAID 0.9 નો ઉપયોગ કરતી વાનગીઓ છે જે UEFI BIOS ને આ પાર્ટીશન જોવાથી અટકાવતી નથી, પરંતુ આ ખુશ ક્ષણ સુધી જીવે છે જ્યારે BIOS અથવા અન્ય હાર્ડવેર OS ESP પર કંઈક લખે છે અને તેને અન્ય સાથે સિંક્રનાઇઝ કરવાનું ભૂલી જાય છે. અરીસાઓ

વધુમાં, UEFI બુટ NVRAM પર આધાર રાખે છે, જે ડિસ્ક સાથે નવી સિસ્ટમમાં ખસેડશે નહીં, કારણ કે મધરબોર્ડનો ભાગ છે.

તેથી, અમે નવા ચક્રને ફરીથી શોધીશું નહીં. અમારી પાસે પહેલેથી જ તૈયાર, સમય-ચકાસાયેલ દાદાની બાઇક છે, જેને હવે લેગસી/BIOS બૂટ કહેવામાં આવે છે, જે UEFI- સુસંગત સિસ્ટમ્સ પર CSM નું ગૌરવપૂર્ણ નામ ધરાવે છે. અમે તેને ફક્ત શેલ્ફમાંથી ઉતારીશું, તેને લુબ્રિકેટ કરીશું, ટાયર પંપ કરીશું અને ભીના કપડાથી તેને સાફ કરીશું.

ઉબુન્ટુનું ડેસ્કટોપ વર્ઝન પણ લેગસી બુટલોડર સાથે યોગ્ય રીતે ઇન્સ્ટોલ કરી શકાતું નથી, પરંતુ અહીં, જેમ તેઓ કહે છે, ઓછામાં ઓછા વિકલ્પો છે.

અને તેથી, અમે હાર્ડવેર એકત્રિત કરીએ છીએ અને ઉબુન્ટુ લાઇવ બૂટેબલ ફ્લેશ ડ્રાઇવમાંથી સિસ્ટમ લોડ કરીએ છીએ. અમારે પેકેજો ડાઉનલોડ કરવાની જરૂર પડશે, તેથી અમે તમારા માટે કામ કરતું નેટવર્ક સેટ કરીશું. જો તે કામ કરતું નથી, તો તમે અગાઉથી ફ્લેશ ડ્રાઇવ પર જરૂરી પેકેજો લોડ કરી શકો છો.

અમે ડેસ્કટૉપ પર્યાવરણમાં જઈએ છીએ, ટર્મિનલ ઇમ્યુલેટર લોંચ કરીએ છીએ, અને અમે જઈએ છીએ:

#sudo bash

કેવી રીતે…?ઉપરની લીટી સુડો વિશે હોલીવાર માટે પ્રમાણભૂત ટ્રિગર છે. સી બીоવધુ તકો આવે છે અનેоવધુ જવાબદારી. પ્રશ્ન એ છે કે શું તમે તેને તમારા પર લઈ શકો છો. ઘણા લોકો માને છે કે આ રીતે સુડોનો ઉપયોગ કરવો ઓછામાં ઓછું સાવચેતીભર્યું નથી. જો કે:

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

ZFS કેમ નહીં...?જ્યારે અમે અમારા કમ્પ્યુટર પર સૉફ્ટવેર ઇન્સ્ટોલ કરીએ છીએ, ત્યારે અમે આવશ્યકપણે આ સૉફ્ટવેરના વિકાસકર્તાઓને ડ્રાઇવ કરવા માટે અમારા હાર્ડવેરને ઉધાર આપીએ છીએ.
જ્યારે અમે અમારા ડેટાની સલામતી સાથે આ સૉફ્ટવેર પર વિશ્વાસ કરીએ છીએ, ત્યારે અમે આ ડેટાને પુનઃસ્થાપિત કરવાના ખર્ચ જેટલી લોન લઈએ છીએ, જે અમારે કોઈ દિવસ ચૂકવવી પડશે.

આ દૃષ્ટિકોણથી, ZFS એ ફેરારી છે, અને mdadm+lvm એ સાયકલ જેવું છે.

વ્યક્તિલક્ષી રીતે, લેખક ફેરારીને બદલે અજાણ્યા વ્યક્તિઓને ક્રેડિટ પર બાઇક આપવાનું પસંદ કરે છે. ત્યાં, ઇશ્યૂની કિંમત વધારે નથી. અધિકારોની જરૂર નથી. ટ્રાફિક નિયમો કરતાં સરળ. પાર્કિંગ મફત છે. ક્રોસ-કન્ટ્રી ક્ષમતા વધુ સારી છે. તમે હંમેશા સાયકલ સાથે પગ જોડી શકો છો, અને તમે તમારા પોતાના હાથથી સાયકલ રીપેર કરી શકો છો.

તો પછી BTRFS શા માટે...?ઑપરેટિંગ સિસ્ટમને બૂટ કરવા માટે, અમને એક ફાઇલ સિસ્ટમની જરૂર છે જે લેગસી/BIOS GRUB માં બૉક્સની બહાર સપોર્ટ કરે છે, અને તે જ સમયે લાઇવ સ્નેપશોટને સપોર્ટ કરે છે. અમે તેનો ઉપયોગ /boot પાર્ટીશન માટે કરીશું. વધુમાં, લેખક આ FS ને / (રુટ) માટે વાપરવાનું પસંદ કરે છે, એ નોંધવાનું ભૂલતા નથી કે અન્ય કોઈપણ સોફ્ટવેર માટે તમે LVM પર અલગ પાર્ટીશનો બનાવી શકો છો અને તેમને જરૂરી ડિરેક્ટરીઓમાં માઉન્ટ કરી શકો છો.

અમે આ FS પર વર્ચ્યુઅલ મશીનો અથવા ડેટાબેઝની કોઈપણ છબીઓ સંગ્રહિત કરીશું નહીં.
આ FS નો ઉપયોગ ફક્ત સિસ્ટમના સ્નેપશોટને બંધ કર્યા વિના તેને બનાવવા માટે કરવામાં આવશે અને પછી મોકલો/પ્રાપ્ત કરીને આ સ્નેપશોટને બેકઅપ ડિસ્કમાં સ્થાનાંતરિત કરો.

વધુમાં, લેખક સામાન્ય રીતે હાર્ડવેર પર સીધા જ ન્યૂનતમ સોફ્ટવેર રાખવાનું પસંદ કરે છે અને અન્ય તમામ સોફ્ટવેરને વર્ચ્યુઅલ મશીનમાં ચલાવવાનું પસંદ કરે છે જેમ કે GPUs અને PCI-USB હોસ્ટ કંટ્રોલર્સને IOMMU મારફતે KVM પર ફોરવર્ડ કરવા જેવી બાબતોનો ઉપયોગ કરીને.

હાર્ડવેર પર માત્ર ડેટા સ્ટોરેજ, વર્ચ્યુઅલાઈઝેશન અને બેકઅપ બાકી રહે છે.

જો તમે ZFS પર વધુ વિશ્વાસ કરો છો, તો સૈદ્ધાંતિક રીતે, ઉલ્લેખિત એપ્લિકેશન માટે તેઓ વિનિમયક્ષમ છે.

જો કે, લેખક ઇરાદાપૂર્વક બિલ્ટ-ઇન મિરરિંગ/RAID અને રિડન્ડન્સી સુવિધાઓને અવગણે છે જે ZFS, BRTFS અને LVM પાસે છે.

વધારાની દલીલ તરીકે, 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


ડિસ્ક લેઆઉટ

એનએમવીએ એસએસડી

પરંતુ અમે તેમને કોઈપણ રીતે ચિહ્નિત કરીશું નહીં. સમાન રીતે, અમારા BIOS આ ડ્રાઇવ્સને જોતા નથી. તેથી, તેઓ સંપૂર્ણપણે સોફ્ટવેર RAID પર જશે. અમે ત્યાં વિભાગો પણ બનાવીશું નહીં. જો તમે "કેનન" અથવા "મુખ્યત્વે" ને અનુસરવા માંગતા હો, તો 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

આ તે છે જ્યાં વસ્તુઓ અમારા માટે રસપ્રદ બને છે.

સૌપ્રથમ, અમારી ડ્રાઈવો 2 TB કદની છે. આ MBR માટે સ્વીકાર્ય શ્રેણીમાં છે, જેનો અમે ઉપયોગ કરીશું. જો જરૂરી હોય તો, GPT સાથે બદલી શકાય છે. GPT ડિસ્કમાં સુસંગતતા સ્તર હોય છે જે MBR-સુસંગત સિસ્ટમોને પ્રથમ 4 પાર્ટીશનો જોવા માટે પરવાનગી આપે છે જો તેઓ પ્રથમ 2 ટેરાબાઈટની અંદર સ્થિત હોય. મુખ્ય વસ્તુ એ છે કે આ ડિસ્ક પર બૂટ પાર્ટીશન અને bios_grub પાર્ટીશન શરૂઆતમાં હોવું જોઈએ. આ તમને GPT લેગસી/BIOS ડ્રાઇવ્સમાંથી બુટ કરવાની પણ પરવાનગી આપે છે.

પરંતુ આ અમારો કેસ નથી.

અહીં આપણે બે વિભાગ બનાવીશું. પ્રથમનું કદ 1 GB હશે અને તેનો ઉપયોગ RAID 1 /boot માટે થશે.

બીજાનો ઉપયોગ RAID 6 માટે કરવામાં આવશે અને ડ્રાઇવના અંતે એક નાનકડા બિન ફાળવેલ વિસ્તાર સિવાય બાકીની બધી ખાલી જગ્યા લેશે.

આ અચિહ્નિત વિસ્તાર શું છે?નેટવર્ક પરના સૂત્રોના જણાવ્યા અનુસાર, અમારા SATA SSDs પાસે 6 થી 78 ગીગાબાઇટ્સ સુધીના કદની ગતિશીલ રીતે વિસ્તૃત SLC કેશ છે. ડ્રાઇવની ડેટા શીટમાં "ગીગાબાઇટ્સ" અને "ગીબીબાઇટ્સ" વચ્ચેના તફાવતને કારણે અમને 6 ગીગાબાઇટ્સ "મફતમાં" મળે છે. બાકીની 72 ગીગાબાઇટ્સ બિનઉપયોગી જગ્યામાંથી ફાળવવામાં આવી છે.

અહીં એ નોંધવું જોઈએ કે અમારી પાસે SLC કેશ છે, અને જગ્યા 4 બીટ MLC મોડમાં છે. જેનો અમારા માટે અસરકારક અર્થ છે કે દરેક 4 ગીગાબાઈટ ખાલી જગ્યા માટે અમને ફક્ત 1 ગીગાબાઈટ SLC કેશ મળશે.

72 ગીગાબાઇટ્સનો 4 વડે ગુણાકાર કરો અને 288 ગીગાબાઇટ્સ મેળવો. આ ખાલી જગ્યા છે જેને અમે ડ્રાઇવ્સને 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 ની અંદર ક્યાંક એરે નામનો ભાગ છે અને ક્યાંક કંઈક અસર કરે છે. અલબત્ત, એરેનું નામ પછીથી બદલી શકાય છે, પરંતુ આ એક બિનજરૂરી પગલું છે.

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


એનએમવીએ એસએસડી

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

શા માટે-ધારો-સ્વચ્છ...?એરે શરૂ કરવાનું ટાળવા માટે. RAID સ્તર 1 અને 6 બંને માટે આ માન્ય છે. જો તે નવી એરે હોય તો બધું આરંભ વિના કામ કરી શકે છે. વધુમાં, બનાવટ પર SSD એરે શરૂ કરવું એ TBW સંસાધનનો બગાડ છે. અમે એસેમ્બલ કરેલ SSD એરેને "પ્રારંભિક" કરવા માટે જ્યાં શક્ય હોય ત્યાં TRIM/DISCARD નો ઉપયોગ કરીએ છીએ.

SSD એરે માટે, RAID 1 DISCARD એ બૉક્સની બહાર સપોર્ટેડ છે.

SSD RAID 6 DISCARD એરે માટે, તમારે તેને કર્નલ મોડ્યુલ પરિમાણોમાં સક્રિય કરવું આવશ્યક છે.

આ માત્ર ત્યારે જ થવું જોઈએ જો આ સિસ્ટમમાં લેવલ 4/5/6 એરેમાં ઉપયોગમાં લેવાતા તમામ 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 નો સારાંશ આપવામાં આવે છે. આંકડા અનુસાર, 99% IO 512K કરતાં વધી નથી.

RAID માં લખવા દીઠ 6 IOPS છે હંમેશાં એક ડ્રાઇવના IOPS કરતાં ઓછું અથવા તેની બરાબર. જ્યારે, રેન્ડમ રીડ તરીકે, IOPS એ એક ડ્રાઈવ કરતા અનેક ગણું વધારે હોઈ શકે છે, અને અહીં બ્લોકનું કદ મહત્ત્વનું છે.
લેખક RAID 6 બાય-ડિઝાઇનમાં ખરાબ હોય તેવા પેરામીટરને ઑપ્ટિમાઇઝ કરવાનો પ્રયાસ કરવાનો મુદ્દો જોતા નથી અને તેના બદલે RAID 6 શું સારું છે તે ઑપ્ટિમાઇઝ કરે છે.
અમે RAID 6 ના નબળા રેન્ડમ લખાણ માટે NVMe કેશ અને પાતળી-જોગવાઈ યુક્તિઓ સાથે વળતર આપીશું.

અમે હજી સુધી RAID 6 માટે DISCARD ને સક્ષમ કર્યું નથી. તેથી અમે હમણાં માટે આ એરેને "પ્રારંભ" કરીશું નહીં. OS ઇન્સ્ટોલ કર્યા પછી, અમે આ પછીથી કરીશું.

સાટા એચડીડી

#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-cache અને LVM-પાતળા મેટાડેટા, તેથી અમે આ એરે પર LVM VG બનાવીશું.

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

ચાલો રુટ ફાઈલ સિસ્ટમ માટે પાર્ટીશન બનાવીએ.

#lvcreate -L 128G --name root root

ચાલો RAM ના માપ પ્રમાણે સ્વેપ કરવા માટે પાર્ટીશન બનાવીએ.

#lvcreate -L 32G --name swap root

OS ઇન્સ્ટોલેશન

કુલમાં, અમારી પાસે સિસ્ટમ ઇન્સ્ટોલ કરવા માટે જરૂરી બધું છે.

ઉબુન્ટુ લાઇવ પર્યાવરણમાંથી સિસ્ટમ ઇન્સ્ટોલેશન વિઝાર્ડ લોંચ કરો. સામાન્ય સ્થાપન. ફક્ત ઇન્સ્ટોલેશન માટે ડિસ્ક પસંદ કરવાના તબક્કે, તમારે નીચેનાનો ઉલ્લેખ કરવાની જરૂર છે:

• /dev/md1, - માઉન્ટ પોઈન્ટ /boot, FS - BTRFS
• /dev/root/root (ઉર્ફે /dev/mapper/root-root), - માઉન્ટ પોઈન્ટ / (રુટ), FS - BTRFS
• /dev/root/swap (ઉર્ફે /dev/mapper/root-swap), - સ્વેપ પાર્ટીશન તરીકે ઉપયોગ કરો
• /dev/sda પર બુટલોડર ઇન્સ્ટોલ કરો

જ્યારે તમે રુટ ફાઇલ સિસ્ટમ તરીકે BTRFS પસંદ કરો છો, ત્યારે સ્થાપક આપમેળે / (રુટ) માટે "@" નામના બે BTRFS વોલ્યુમો અને /home માટે "@home" બનાવશે.

ચાલો ઇન્સ્ટોલેશન શરૂ કરીએ...

ઇન્સ્ટોલેશન મોડલ ડાયલોગ બોક્સ સાથે સમાપ્ત થશે જે બુટલોડર ઇન્સ્ટોલ કરવામાં ભૂલ દર્શાવે છે. કમનસીબે, તમે માનક માધ્યમોનો ઉપયોગ કરીને આ સંવાદમાંથી બહાર નીકળી શકશો નહીં અને ઇન્સ્ટોલેશન ચાલુ રાખી શકશો નહીં. અમે સિસ્ટમમાંથી લૉગ આઉટ કરીએ છીએ અને ફરીથી લૉગ ઇન કરીએ છીએ, જેનો અંત સ્વચ્છ ઉબુન્ટુ લાઇવ ડેસ્કટૉપમાં થાય છે. ટર્મિનલ ખોલો, અને ફરીથી:

#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 પર્યાવરણમાં જઈએ:

#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 માટે પર્યાપ્ત હોવા માટે સેટ કરો. ડિફોલ્ટ મૂલ્ય, એવું લાગે છે, Linux ની રચના પછી બદલાયું નથી, અને લાંબા સમયથી પર્યાપ્ત નથી.
• એરે ચેક્સ/સિંક્રોનાઇઝેશનની અવધિ માટે ન્યૂનતમ IO અનામત રાખો. આ તમારા એરેને લોડ હેઠળ શાશ્વત સિંક્રનાઇઝેશનની સ્થિતિમાં અટવાતા અટકાવવા માટે છે.
• એરેના ચેક/સિંક્રોનાઇઝેશન દરમિયાન મહત્તમ IO ને મર્યાદિત કરો. આ જરૂરી છે જેથી SSD RAIDs ને સિંક્રનાઇઝ/તપાસવાથી તમારી ડ્રાઇવને ચપળતાથી ફ્રાય ન થાય. આ ખાસ કરીને NVMe માટે સાચું છે. (રેડિએટર વિશે યાદ છે? હું મજાક કરતો ન હતો.)
• ડિસ્કને APM દ્વારા સ્પિન્ડલ રોટેશન (HDD) રોકવાથી પ્રતિબંધિત કરો અને ડિસ્ક નિયંત્રકો માટે સ્લીપ ટાઈમઆઉટને 7 કલાક પર સેટ કરો. જો તમારી ડ્રાઇવ્સ તે કરી શકે તો તમે APM ને ​​સંપૂર્ણપણે અક્ષમ કરી શકો છો (-B 255). ડિફૉલ્ટ મૂલ્ય સાથે, ડ્રાઇવ્સ પાંચ સેકન્ડ પછી બંધ થઈ જશે. પછી OS ડિસ્ક કેશ રીસેટ કરવા માંગે છે, ડિસ્ક ફરીથી સ્પિન થશે, અને બધું ફરીથી શરૂ થશે. ડિસ્કમાં સ્પિન્ડલ પરિભ્રમણની મર્યાદિત મહત્તમ સંખ્યા હોય છે. આવી સરળ ડિફૉલ્ટ સાઇકલ તમારી ડિસ્કને થોડા વર્ષોમાં સરળતાથી મારી શકે છે. બધી ડિસ્ક આનાથી પીડાતી નથી, પરંતુ અમારી "લેપટોપ" છે, યોગ્ય ડિફોલ્ટ સેટિંગ્સ સાથે, જે RAID ને મિની-MAID જેવો બનાવે છે.
• ડિસ્ક પર રીડહેડ ઇન્સ્ટોલ કરો (ફરતી) 1 મેગાબાઈટ - સતત બે બ્લોક્સ/ચંક RAID 6
• એરે પર જ રીડહેડને અક્ષમ કરો.

ચાલો સંપાદિત કરીએ /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 પાર્ટીશન માટે શોધીશું. એરે નામકરણ સૈદ્ધાંતિક રીતે બદલાઈ શકે છે.

અમે બાકીના વિભાગોને LVM નામો દ્વારા /dev/mapper/vg-lv નોટેશનમાં શોધીશું, કારણ કે તેઓ પાર્ટીશનોને તદ્દન વિશિષ્ટ રીતે ઓળખે છે.

અમે LVM માટે UUID નો ઉપયોગ કરતા નથી કારણ કે LVM વોલ્યુમો અને તેમના સ્નેપશોટનું UUID સમાન હોઈ શકે છે.માઉન્ટ /dev/mapper/root-root.. બે વાર?હા. બરાબર. BTRFS ની વિશેષતા. આ ફાઇલ સિસ્ટમ વિવિધ સબવોલ સાથે ઘણી વખત માઉન્ટ કરી શકાય છે.

આ જ લક્ષણને લીધે, હું ક્યારેય સક્રિય 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 કેશનો ઉપયોગ કરીને કેશ થયેલ ઉપકરણો, કેશને બાયપાસ કરીને ( _કોરીગ). આ કિસ્સામાં, કેશ્ડ ઉપકરણ હજી પણ કેશ દ્વારા સ્કેન કરવામાં આવશે (ફક્ત ).
• LVM કેશ મેટાડેટા (cmeta) ધરાવતા ઉપકરણો
• VG માં તમામ ઉપકરણો નામની છબીઓ સાથે. અહીં અમારી પાસે વર્ચ્યુઅલ મશીનોની ડિસ્ક ઈમેજો હશે, અને અમે નથી ઈચ્છતા કે હોસ્ટ પર LVM ગેસ્ટ OS સાથે જોડાયેલા વોલ્યુમોને સક્રિય કરે.
• નામ બેકઅપ સાથે VG માં તમામ ઉપકરણો. અહીં આપણી પાસે વર્ચ્યુઅલ મશીન ઈમેજીસની બેકઅપ કોપી હશે.
• બધા ઉપકરણો કે જેના નામ "gpv" સાથે સમાપ્ત થાય છે (અતિથિ ભૌતિક વોલ્યુમ)

LVM VG પર ખાલી જગ્યા ખાલી કરતી વખતે અમે DISCARD સપોર્ટ સક્રિય કર્યો છે. સાવચેત રહો. આનાથી SSD પર LVs કાઢી નાખવામાં ઘણો સમય લાગશે. આ ખાસ કરીને SSD RAID 6 પર લાગુ પડે છે. જો કે, યોજના અનુસાર, અમે પાતળી જોગવાઈનો ઉપયોગ કરીશું, તેથી આ અમને બિલકુલ અવરોધે નહીં.

ચાલો initramfs ઈમેજ અપડેટ કરીએ:

#update-initramfs -u -k all

ગ્રબ ઇન્સ્ટોલ અને ગોઠવો:

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

કઈ ડિસ્ક પસંદ કરવી?બધા જેઓ sd* છે. સિસ્ટમ કોઈપણ કાર્યરત SATA ડ્રાઇવ અથવા SSD માંથી બુટ કરવા સક્ષમ હોવી જોઈએ.

શા માટે તેઓએ ઓએસ-પ્રોબર ઉમેર્યું..?અતિશય સ્વતંત્રતા અને રમતિયાળ હાથ માટે.

તે યોગ્ય રીતે કામ કરતું નથી જો RAIDsમાંથી એક ડિગ્રેડેડ સ્ટેટમાં હોય. તે પાર્ટીશનો પર OS શોધવાનો પ્રયાસ કરે છે જેનો ઉપયોગ આ હાર્ડવેર પર ચાલતા વર્ચ્યુઅલ મશીનોમાં થાય છે.

જો તમને તેની જરૂર હોય, તો તમે તેને છોડી શકો છો, પરંતુ ઉપરોક્ત તમામ બાબતોને ધ્યાનમાં રાખો. હું ઑનલાઇન તોફાની હાથથી છુટકારો મેળવવા માટેની વાનગીઓ શોધવાની ભલામણ કરું છું.

આ સાથે અમે પ્રારંભિક ઇન્સ્ટોલેશન પૂર્ણ કર્યું છે. નવા ઇન્સ્ટોલ કરેલ OS માં રીબૂટ કરવાનો સમય છે. બુટ કરી શકાય તેવી Live CD/USB દૂર કરવાનું ભૂલશો નહીં.

#exit
#reboot

બુટ ઉપકરણ તરીકે કોઈપણ SATA SSDs પસંદ કરો.

SATA SSD પર LVM

આ બિંદુએ, અમે પહેલેથી જ નવા OS માં બુટ કર્યું છે, નેટવર્ક ગોઠવ્યું છે, યોગ્ય છે, ટર્મિનલ ઇમ્યુલેટર ખોલ્યું છે અને લોન્ચ કર્યું છે:

#sudo bash

ચાલો ચાલુ રાખીએ.

SATA SSD માંથી એરેને "પ્રારંભ કરો":

#blkdiscard /dev/md2

જો તે કામ કરતું નથી, તો પછી પ્રયાસ કરો:

#blkdiscard --step 65536 /dev/md2
SATA SSD પર LVM VG બનાવો:

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

શા માટે અન્ય VG..?હકીકતમાં, અમારી પાસે પહેલાથી જ રુટ નામનું VG છે. શા માટે એક VG માં બધું ઉમેરતા નથી?

જો VG માં અનેક PVs હોય, તો VG યોગ્ય રીતે સક્રિય થાય તે માટે, બધા PV હાજર (ઓનલાઈન) હોવા જોઈએ. અપવાદ LVM RAID છે, જે આપણે જાણીજોઈને વાપરતા નથી.

અમે ખરેખર ઇચ્છીએ છીએ કે જો RAID 6 એરેમાંથી કોઈપણ પર નિષ્ફળતા (ડેટા નુકશાન વાંચો) હોય, તો ઑપરેટિંગ સિસ્ટમ સામાન્ય રીતે બૂટ થશે અને અમને સમસ્યા હલ કરવાની તક આપશે.

આ કરવા માટે, અમૂર્તતાના પ્રથમ સ્તરે અમે દરેક પ્રકારના ભૌતિક "મીડિયા" ને અલગ VG માં અલગ કરીશું.

વૈજ્ઞાનિક રીતે કહીએ તો, વિવિધ RAID એરે વિવિધ "વિશ્વસનીયતા ડોમેન્સ" થી સંબંધિત છે. તમારે તેમને એક VG માં ક્રેમ કરીને તેમના માટે નિષ્ફળતાનો વધારાનો સામાન્ય મુદ્દો બનાવવો જોઈએ નહીં.

"હાર્ડવેર" સ્તરે LVM ની હાજરી આપણને વિવિધ RAID એરેના ટુકડાઓને અલગ અલગ રીતે જોડીને મનસ્વી રીતે કાપી નાખવાની પરવાનગી આપશે. ઉદાહરણ તરીકે - ચલાવો તે જ સમયે bcache + LVM પાતળું, bcache + BTRFS, LVM cache + LVM પાતળું, કેશ સાથેનું જટિલ ZFS રૂપરેખાંકન, અથવા તે બધાને અજમાવવા અને તેની તુલના કરવા માટે કોઈપણ અન્ય નરક મિશ્રણ.

"હાર્ડવેર" સ્તરે, અમે સારા જૂના "જાડા" LVM વોલ્યુમો સિવાય બીજું કંઈપણ વાપરીશું નહીં. આ નિયમનો અપવાદ બેકઅપ પાર્ટીશન હોઈ શકે છે.

મને લાગે છે કે આ ક્ષણ સુધીમાં, ઘણા વાચકો નેસ્ટિંગ ડોલ વિશે કંઈક શંકા કરવાનું શરૂ કરી દીધું હતું.

SATA HDD પર LVM

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

ફરી નવું વીજી..?અમે ખરેખર ઇચ્છીએ છીએ કે જો અમે ડેટા બેકઅપ માટે ઉપયોગ કરીશું તે ડિસ્ક એરે નિષ્ફળ જાય, તો અમારી ઑપરેટિંગ સિસ્ટમ સામાન્ય રીતે કામ કરવાનું ચાલુ રાખશે, જ્યારે સામાન્ય રીતે બિન-બેકઅપ ડેટાની ઍક્સેસ જાળવી રાખશે. તેથી, VG સક્રિયકરણ સમસ્યાઓ ટાળવા માટે, અમે એક અલગ VG બનાવીએ છીએ.

LVM કેશ સુયોજિત કરી રહ્યા છીએ

ચાલો તેને કેશીંગ ઉપકરણ તરીકે વાપરવા માટે NVMe RAID 1 પર LV બનાવીએ.

#lvcreate -L 70871154688B --name cache root

આટલું ઓછું કેમ છે...?હકીકત એ છે કે અમારા NVMe SSDs પાસે SLC કેશ પણ છે. 4-બીટ MLC માં કબજે કરેલી ખાલી જગ્યાને કારણે 18 ગીગાબાઇટ્સ "ફ્રી" અને 3 ગીગાબાઇટ્સ ડાયનેમિક. એકવાર આ કેશ ખલાસ થઈ જાય, NVMe SSD એ કેશ સાથેના અમારા 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-cache ઓવરનો વિશિષ્ટ ફાયદો, ઉદાહરણ તરીકે, bcache એ છે કે આ ફ્લાય પર કરી શકાય છે.

ચાલો કેશીંગ માટે એક નવું VG બનાવીએ.

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

ચાલો કેશ્ડ ઉપકરણ પર એલવી ​​બનાવીએ.

#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

શા માટે આટલી ચંકસાઈઝ..?પ્રાયોગિક પ્રયોગો દ્વારા, લેખક એ જાણવામાં સક્ષમ હતા કે જો 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 ને પાછું cachedata માં નામ બદલશે.

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
ચાલો NVMe RAID 1 પર LVM પાતળા મેટાડેટા અને તેની બેકઅપ નકલ મૂકવા માટે એક અલગ પાર્ટીશન બનાવીએ:

#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 ને અનુરૂપ PVs પર ખસેડીએ:

#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 સેકન્ડ માટે ચાલશે. અડધા ટેસ્ટ રેકોર્ડિંગ માટે છે. તમે NVMe પર 4 સેકન્ડમાં ઘણું બધું રેકોર્ડ કરી શકો છો. પ્રતિ સેકન્ડ 3 ગીગાબાઇટ્સ સુધી. તેથી, લેખન પરીક્ષણોનો દરેક રન તમારી પાસેથી 216 ગીગાબાઇટ્સ SSD સંસાધન ખાઈ શકે છે.

વાંચન અને લેખન મિશ્ર?હા. વાંચવા અને લખવાની કસોટીઓ અલગથી ચલાવવાનો અર્થ છે. તદુપરાંત, તે સુનિશ્ચિત કરવા માટે અર્થપૂર્ણ છે કે તમામ કેશ સમન્વયિત છે જેથી અગાઉ બનાવેલ લખાણ વાંચવાને અસર ન કરે.

કેશ અને પાતળું વોલ્યુમ ભરાઈ જતાં પ્રથમ લોંચ દરમિયાન અને ત્યારપછીના પરિણામો મોટા પ્રમાણમાં બદલાશે, અને તે પણ તેના પર આધાર રાખે છે કે સિસ્ટમ છેલ્લા લોંચ દરમિયાન ભરેલી કેશને સિંક્રનાઇઝ કરવામાં સફળ રહી છે કે કેમ.

અન્ય વસ્તુઓમાં, હું પહેલેથી જ સંપૂર્ણ પાતળા વોલ્યુમ પર ઝડપને માપવાની ભલામણ કરું છું જેમાંથી સ્નેપશોટ હમણાં જ લેવામાં આવ્યો હતો. લેખકને પ્રથમ સ્નેપશોટ બનાવ્યા પછી તરત જ કેવી રીતે રેન્ડમ લખાણો ઝડપથી વેગ આપે છે તે અવલોકન કરવાની તક મળી, ખાસ કરીને જ્યારે કેશ હજી સંપૂર્ણ રીતે ભરાયેલ નથી. આ કોપી-ઓન-રાઈટ રાઈટ સિમેન્ટિક્સ, કેશની ગોઠવણી અને પાતળા વોલ્યુમ બ્લોક્સને કારણે થાય છે અને હકીકત એ છે કે RAID 6 પર રેન્ડમ લખવું એ RAID 6 માંથી રેન્ડમ રીડમાં ફેરવાય છે અને ત્યારબાદ કેશમાં લખવાનું છે. અમારા રૂપરેખાંકનમાં, RAID 6 થી રેન્ડમ રીડિંગ 6 ગણું (એરેમાં SATA SSD ની સંખ્યા) લખવા કરતાં વધુ ઝડપી છે. કારણ કે 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 એરેની ગતિ વિશેષતાઓ તેમજ તેમના 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/DISCARD

કારણ કે ડેટા સ્ટોરેજનો ઉપયોગ 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 માંથી આવા DISCARDs એ LVM દ્વારા યોગ્ય રીતે પ્રક્રિયા કરવામાં આવે છે, અને બ્લોક્સ કેશ અને પાતળા પૂલમાં યોગ્ય રીતે મુક્ત થાય છે. અમારા કિસ્સામાં, આગલા સ્નેપશોટને કાઢી નાખતી વખતે, આ મુખ્યત્વે વિલંબિત રીતે થાય છે.

BTRFS બેકઅપ

સાથે તૈયાર સ્ક્રિપ્ટનો ઉપયોગ કરો આત્યંતિક સાવધાની અને પોતાના જોખમે. લેખકે આ કોડ પોતે અને ફક્ત પોતાના માટે જ લખ્યો છે. મને ખાતરી છે કે ઘણા અનુભવી Linux વપરાશકર્તાઓ પાસે સમાન સાધનો છે, અને કોઈ બીજાની નકલ કરવાની જરૂર નથી.

ચાલો બેકઅપ ઉપકરણ પર વોલ્યુમ બનાવીએ:

#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


તે શું કરે છે...?પાતળા સ્નેપશોટની હેરફેર કરવા અને ddrescue અને blkdiscard નો ઉપયોગ કરીને બીજા બ્લોક ઉપકરણ પર thin_delta દ્વારા પ્રાપ્ત થયેલ બે પાતળા સ્નેપશોટ વચ્ચેના તફાવતને સુમેળ કરવા માટે આદેશોનો સમૂહ સમાવે છે.

બીજી સ્ક્રિપ્ટ જે આપણે ક્રોનમાં મૂકીશું:

થોડી વધુ આડશ#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 નેટવર્કનો ઉપયોગ કરીને કેટલાક ખંડો પર રિડન્ડન્સી સાથે જીઓ-ડિસ્ટ્રિબ્યુટેડ સ્ટોરેજ/વીએમ ક્લસ્ટર બનાવવાના આધાર તરીકે ઘણી સમાન મોબાઇલ સ્ટોરેજ સિસ્ટમ્સ/KVM નો ઉપયોગ કરવાનો પ્રયાસ કરીશું.

સોર્સ: www.habr.com