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 ড্রাইভের ব্যর্থতা সম্পূর্ণরূপে ব্যবহৃত হয়।
• ব্যাকআপ কপি সহ সমস্ত ড্রাইভের সমস্ত ডেটা সম্পূর্ণ ক্ষতি।
• ত্রুটিপূর্ণ কম্পিউটার হার্ডওয়্যার।
• সময়, স্নায়ু এবং অর্থের অপচয়।
• উপরে তালিকাভুক্ত করা হয় না যে অন্য কোন ফলাফল.

লোহা

উপলব্ধ ছিল:

মাদারবোর্ড প্রায় 2013 থেকে Z87 চিপসেট সহ, 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 অ্যারেতে ছিল। নতুন সিস্টেমেও তাদের ব্যবহার থাকবে। স্থানীয় ব্যাকআপ সংরক্ষণ করতে.

অতিরিক্ত যোগ করা হয়েছে:

6 পিস SATA SSD মডেল Samsung 860 QVO 2TB। এই এসএসডিগুলির জন্য একটি বড় আয়তনের প্রয়োজন, একটি এসএলসি ক্যাশের উপস্থিতি, নির্ভরযোগ্যতা এবং কম দামের প্রয়োজন ছিল৷ বাতিল/শূন্যের জন্য সমর্থন প্রয়োজন ছিল, যা dmesg-এ লাইন দ্বারা চেক করা হয়:

kernel: ata1.00: Enabling discard_zeroes_data

NVMe SSD মডেলের 2 পিস Samsung SSD 970 EVO 500GB।

এই এসএসডিগুলির জন্য, আপনার প্রয়োজনের জন্য এলোমেলোভাবে পড়া/লেখার গতি এবং সংস্থান ক্ষমতা গুরুত্বপূর্ণ। তাদের জন্য রেডিয়েটার। অগত্যা। একেবারে। অন্যথায়, প্রথম RAID সিঙ্ক্রোনাইজেশনের সময় খাস্তা না হওয়া পর্যন্ত এগুলি ভাজুন।

StarTech PEX8M2E2 অ্যাডাপ্টার 2 x NVMe SSD-এর জন্য PCIe 3.0 8x স্লটে ইনস্টল করা হয়েছে। এটি আবার, শুধুমাত্র একটি HBA, কিন্তু NVMe এর জন্য। এটি সস্তা অ্যাডাপ্টারের থেকে আলাদা যে এটি একটি অন্তর্নির্মিত PCIe সুইচের উপস্থিতির কারণে মাদারবোর্ড থেকে PCIe দ্বিখণ্ডন সমর্থনের প্রয়োজন হয় না। এটি PCIe এর সাথে সবচেয়ে প্রাচীন সিস্টেমেও কাজ করবে, এমনকি যদি এটি একটি x1 PCIe 1.0 স্লট হয়। স্বাভাবিকভাবেই, উপযুক্ত গতিতে। সেখানে কোনো RAID নেই। বোর্ডে বিল্ট-ইন BIOS নেই। সুতরাং, আপনার সিস্টেম যাদুকরীভাবে NVMe দিয়ে বুট করতে শিখবে না, NVMe RAID এই ডিভাইসের জন্য অনেক কম ধন্যবাদ।

এই উপাদানটি কেবলমাত্র সিস্টেমে শুধুমাত্র একটি বিনামূল্যের 8x PCIe 3.0 এর উপস্থিতির কারণে হয়েছে, এবং, যদি 2টি বিনামূল্যের স্লট থাকে, তাহলে এটি সহজেই দুটি পেনি PEX4M2E1 বা অ্যানালগ দিয়ে প্রতিস্থাপন করা যেতে পারে, যেটি 600 মূল্যে যেকোনো জায়গায় কেনা যাবে। রুবেল

সমস্ত ধরণের হার্ডওয়্যার বা বিল্ট-ইন চিপসেট/BIOS RAIDs প্রত্যাখ্যান ইচ্ছাকৃতভাবে করা হয়েছিল, যাতে SSD/HDD বাদ দিয়ে, সমস্ত ডেটা সংরক্ষণ করে সম্পূর্ণ সিস্টেমকে সম্পূর্ণরূপে প্রতিস্থাপন করতে সক্ষম হয়। আদর্শভাবে, যাতে আপনি সম্পূর্ণ নতুন/ভিন্ন হার্ডওয়্যারে যাওয়ার সময় ইনস্টল করা অপারেটিং সিস্টেমটিও সংরক্ষণ করতে পারেন। প্রধান জিনিস হল যে SATA এবং PCIe পোর্ট আছে। এটি একটি লাইভ সিডি বা বুটেবল ফ্ল্যাশ ড্রাইভের মতো, শুধুমাত্র খুব দ্রুত এবং একটু ভারী৷

ধাতঅন্যথায়, আপনি জানেন কি ঘটবে - কখনও কখনও আপনাকে অবিলম্বে সম্পূর্ণ অ্যারেটি আপনার সাথে নিয়ে যেতে হবে। কিন্তু আমি ডেটা হারাতে চাই না। এটি করার জন্য, উল্লিখিত সমস্ত মিডিয়া সুবিধামত স্ট্যান্ডার্ড কেসের 5.25 উপসাগরের স্লাইডে অবস্থিত।

ভাল, এবং, অবশ্যই, লিনাক্সে এসএসডি ক্যাশিংয়ের বিভিন্ন পদ্ধতি নিয়ে পরীক্ষা করার জন্য।

হার্ডওয়্যার অভিযান বিরক্তিকর। এটি চালু কর. এটি হয় কাজ করে বা এটি করে না। এবং 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 কেন...?অপারেটিং সিস্টেম বুট করার জন্য, আমাদের একটি ফাইল সিস্টেম দরকার যা বাক্সের বাইরে Legacy/BIOS GRUB-এ সমর্থিত, এবং একই সময়ে লাইভ স্ন্যাপশট সমর্থন করে। আমরা এটিকে /boot পার্টিশনের জন্য ব্যবহার করব। উপরন্তু, লেখক এই FS-এর জন্য / (root) ব্যবহার করতে পছন্দ করেন, অন্য যেকোন সফ্টওয়্যারের জন্য আপনি LVM-এ পৃথক পার্টিশন তৈরি করতে এবং প্রয়োজনীয় ডিরেক্টরিগুলিতে মাউন্ট করতে ভুলবেন না।

আমরা এই FS-এ ভার্চুয়াল মেশিন বা ডাটাবেসের কোনো ছবি সংরক্ষণ করব না।
এই FS শুধুমাত্র সিস্টেমের স্ন্যাপশট তৈরি করতে ব্যবহার করা হবে এটি বন্ধ না করে এবং তারপর এই স্ন্যাপশটগুলি পাঠান/প্রাপ্তির মাধ্যমে একটি ব্যাকআপ ডিস্কে স্থানান্তর করা হবে।

উপরন্তু, লেখক সাধারণত হার্ডওয়্যারে ন্যূনতম সফ্টওয়্যার রাখতে পছন্দ করেন এবং ভার্চুয়াল মেশিনে অন্যান্য সমস্ত সফ্টওয়্যার চালাতে চান যেমন জিপিইউ এবং পিসিআই-ইউএসবি হোস্ট কন্ট্রোলারকে আইওএমএমইউ-এর মাধ্যমে কেভিএম-এ ফরওয়ার্ড করার মতো জিনিসগুলি ব্যবহার করে।

হার্ডওয়্যারে অবশিষ্ট জিনিসগুলি হ'ল ডেটা স্টোরেজ, ভার্চুয়ালাইজেশন এবং ব্যাকআপ।

আপনি যদি 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 এসএসডি

কিন্তু আমরা কোনোভাবেই তাদের চিহ্নিত করব না। একই, আমাদের 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


সাটা এসএসডি

এখানে জিনিসগুলি আমাদের জন্য আকর্ষণীয় হয়ে ওঠে।

প্রথমত, আমাদের ড্রাইভের আকার 2 টিবি। এটি এমবিআর-এর জন্য গ্রহণযোগ্য সীমার মধ্যে, যা আমরা ব্যবহার করব। প্রয়োজনে, GPT দিয়ে প্রতিস্থাপন করা যেতে পারে। GPT ডিস্কগুলির একটি সামঞ্জস্য স্তর রয়েছে যা MBR- সামঞ্জস্যপূর্ণ সিস্টেমগুলিকে প্রথম 4টি পার্টিশন দেখতে দেয় যদি সেগুলি প্রথম 2 টেরাবাইটের মধ্যে থাকে। মূল বিষয় হল এই ডিস্কগুলিতে বুট পার্টিশন এবং bios_grub পার্টিশন শুরুতে থাকা উচিত। এমনকি এটি আপনাকে GPT লিগ্যাসি/BIOS ড্রাইভ থেকে বুট করার অনুমতি দেয়।

কিন্তু এটা আমাদের ক্ষেত্রে নয়।

এখানে আমরা দুটি বিভাগ তৈরি করব। প্রথমটির আকার হবে 1 GB এবং এটি RAID 1/boot-এর জন্য ব্যবহৃত হবে।

দ্বিতীয়টি RAID 6 এর জন্য ব্যবহার করা হবে এবং ড্রাইভের শেষে একটি ছোট অনির্বাচিত এলাকা ব্যতীত বাকি সমস্ত ফাঁকা স্থান গ্রহণ করবে।

এই অচিহ্নিত এলাকা কি?নেটওয়ার্কের সূত্র অনুসারে, আমাদের SATA SSD-তে 6 থেকে 78 গিগাবাইট আকারের একটি গতিশীলভাবে প্রসারণযোগ্য SLC ক্যাশে রয়েছে। ড্রাইভের ডেটা শীটে "গিগাবাইট" এবং "গিবিবাইট" এর মধ্যে পার্থক্যের কারণে আমরা 6 গিগাবাইট "বিনামূল্যে" পাই। অবশিষ্ট 72 গিগাবাইট অব্যবহৃত স্থান থেকে বরাদ্দ করা হয়।

এখানে এটি লক্ষ করা উচিত যে আমাদের একটি এসএলসি ক্যাশে রয়েছে এবং স্থানটি 4 বিট এমএলসি মোডে দখল করা হয়েছে। যার অর্থ আমাদের জন্য কার্যকরভাবে প্রতি 4 গিগাবাইট খালি স্থানের জন্য আমরা শুধুমাত্র 1 গিগাবাইট SLC ক্যাশে পাব।

72 গিগাবাইটকে 4 দ্বারা গুণ করুন এবং 288 গিগাবাইট পান। ড্রাইভগুলিকে SLC ক্যাশে সম্পূর্ণরূপে ব্যবহার করার অনুমতি দেওয়ার জন্য এটি এমন খালি স্থান যা আমরা চিহ্নিত করব না।

এইভাবে, আমরা মোট ছয়টি ড্রাইভ থেকে কার্যকরভাবে 312 গিগাবাইট পর্যন্ত SLC ক্যাশে পাব। সমস্ত ড্রাইভের মধ্যে, 2টি অপ্রয়োজনীয়তার জন্য RAID-এ ব্যবহার করা হবে।

এই পরিমাণ ক্যাশে আমাদেরকে বাস্তব জীবনে খুব কমই এমন পরিস্থিতির মুখোমুখি হতে দেয় যেখানে একটি লেখা ক্যাশে যায় না। এটি QLC মেমরির সবচেয়ে দুঃখজনক ত্রুটির জন্য অত্যন্ত ভালভাবে ক্ষতিপূরণ দেয় - যখন ক্যাশে বাইপাস করে ডেটা লেখা হয় তখন লেখার গতি অত্যন্ত কম। যদি আপনার লোডগুলি এর সাথে সামঞ্জস্যপূর্ণ না হয়, তবে আমি পরামর্শ দিচ্ছি যে আপনি ডেটা শীট থেকে টিবিডব্লিউ বিবেচনা করে এই ধরনের লোডের অধীনে আপনার এসএসডি কতক্ষণ স্থায়ী হবে সে সম্পর্কে কঠোরভাবে চিন্তা করুন।

#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


NVMe এসএসডি

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

কেন -অনুমান-পরিষ্কার...?অ্যারে আরম্ভ এড়াতে. RAID লেভেল 1 এবং 6 উভয়ের জন্যই এটি বৈধ। এটি একটি নতুন অ্যারে হলে শুরু ছাড়াই সবকিছু কাজ করতে পারে। তদুপরি, তৈরি করার পরে SSD অ্যারে শুরু করা TBW সম্পদের অপচয়। এসএসডি অ্যারেতে "শুরু" করার জন্য আমরা TRIM/DISCARD ব্যবহার করি।

SSD অ্যারেগুলির জন্য, RAID 1 DISCARD বাক্সের বাইরে সমর্থিত।

SSD RAID 6 ডিসকার্ড অ্যারেগুলির জন্য, আপনাকে অবশ্যই কার্নেল মডিউল প্যারামিটারে এটি সক্রিয় করতে হবে।

এই সিস্টেমে লেভেল 4/5/6 অ্যারেতে ব্যবহৃত সমস্ত SSD-এ discard_zeroes_data-এর জন্য কার্যকরী সমর্থন থাকলেই এটি করা উচিত। কখনও কখনও আপনি অদ্ভুত ড্রাইভগুলি দেখতে পান যা কার্নেলকে বলে যে এই ফাংশনটি সমর্থিত, কিন্তু আসলে এটি সেখানে নেই, বা ফাংশনটি সর্বদা কাজ করে না। এই মুহুর্তে, সমর্থন প্রায় সর্বত্র উপলব্ধ, তবে, ত্রুটি সহ পুরানো ড্রাইভ এবং ফার্মওয়্যার আছে। এই কারণে, ডিসকার্ড সমর্থন RAID 6-এর জন্য ডিফল্টরূপে নিষ্ক্রিয় করা হয়।

মনোযোগ দিন, নিম্নলিখিত কমান্ডটি "শূন্য" দিয়ে অ্যারেটিকে "শুরু করে" NVMe ড্রাইভের সমস্ত ডেটা ধ্বংস করবে।

#blkdiscard /dev/md0

কিছু ভুল হলে, একটি ধাপ নির্দিষ্ট করার চেষ্টা করুন।

#blkdiscard --step 65536 /dev/md0

সাটা এসএসডি

#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 কী ভাল তা অপ্টিমাইজ করেন।
আমরা একটি NVMe ক্যাশে এবং পাতলা-প্রভিশনিং ট্রিকস দিয়ে RAID 6-এর দুর্বল র্যান্ডম লেখার জন্য ক্ষতিপূরণ দেব।

আমরা এখনও RAID 6-এর জন্য DISCARD সক্রিয় করিনি। তাই আমরা আপাতত এই অ্যারেটিকে "সূচনা" করব না। 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

ওএস ইনস্টলেশন

মোট, আমাদের সিস্টেম ইনস্টল করার জন্য প্রয়োজনীয় সবকিছু আছে।

উবুন্টু লাইভ পরিবেশ থেকে সিস্টেম ইনস্টলেশন উইজার্ড চালু করুন। সাধারণ ইনস্টলেশন। শুধুমাত্র ইনস্টলেশনের জন্য ডিস্ক নির্বাচন করার পর্যায়ে, আপনাকে নিম্নলিখিতগুলি নির্দিষ্ট করতে হবে:

• /dev/md1, - মাউন্ট পয়েন্ট /বুট, FS - BTRFS
• /dev/root/root (ওরফে /dev/mapper/root-root), - মাউন্ট পয়েন্ট / (root), FS - BTRFS
• /dev/root/swap (ওরফে /dev/mapper/root-swap), - সোয়াপ পার্টিশন হিসাবে ব্যবহার করুন
• /dev/sda-তে বুটলোডার ইনস্টল করুন

আপনি যখন রুট ফাইল সিস্টেম হিসাবে BTRFS নির্বাচন করেন, তখন ইনস্টলার স্বয়ংক্রিয়ভাবে / (root) এর জন্য "@" নামে দুটি 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 RAID গুলিকে সিঙ্ক্রোনাইজ করা/চেক করা আপনার ড্রাইভগুলিকে চটপটে ভাজা না করে। এটি NVMe এর জন্য বিশেষভাবে সত্য। (রেডিয়েটারের কথা মনে আছে? আমি মজা করছিলাম না।)
• APM এর মাধ্যমে স্পিন্ডল রোটেশন (HDD) বন্ধ করা থেকে ডিস্কগুলিকে নিষিদ্ধ করুন এবং ডিস্ক কন্ট্রোলারের জন্য ঘুমের সময়সীমা 7 ঘন্টা সেট করুন৷ যদি আপনার ড্রাইভগুলি এটি করতে পারে তবে আপনি APM সম্পূর্ণরূপে নিষ্ক্রিয় করতে পারেন (-B 255)। ডিফল্ট মান সহ, ড্রাইভগুলি পাঁচ সেকেন্ড পরে বন্ধ হয়ে যাবে। তারপর ওএস ডিস্ক ক্যাশে রিসেট করতে চায়, ডিস্কগুলি আবার ঘুরবে এবং সবকিছু আবার শুরু হবে। ডিস্কে সীমিত সর্বোচ্চ সংখ্যক স্পিন্ডেল ঘূর্ণন থাকে। এই ধরনের একটি সাধারণ ডিফল্ট চক্র কয়েক বছরের মধ্যে সহজেই আপনার ডিস্কগুলিকে মেরে ফেলতে পারে। সমস্ত ডিস্ক এতে ভোগে না, তবে আমাদের "ল্যাপটপ"গুলি উপযুক্ত ডিফল্ট সেটিংস সহ, যা RAID কে একটি মিনি-MAID এর মতো দেখায়৷
• ডিস্কে রিডহেড ইনস্টল করুন (ঘোরানো) 1 মেগাবাইট - পরপর দুটি ব্লক/খণ্ড RAID 6
• অ্যারে নিজেদের উপর 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 এর বৈশিষ্ট্য। এই ফাইল সিস্টেমটি বিভিন্ন সাবভোল সহ একাধিকবার মাউন্ট করা যেতে পারে।

এই একই বৈশিষ্ট্যের কারণে, আমি কখনই সক্রিয় 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 গেস্ট 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

আপনি কোন ডিস্ক নির্বাচন করা উচিত?যারা এসডি*। সিস্টেমটি যেকোন কর্মক্ষম SATA ড্রাইভ বা SSD থেকে বুট করতে সক্ষম হতে হবে।

কেন তারা os-prober যোগ করেছে..?অত্যধিক স্বাধীনতা এবং কৌতুকপূর্ণ হাত জন্য.

এটি সঠিকভাবে কাজ করে না যদি RAIDগুলির একটি অবনত অবস্থায় থাকে। এটি এই হার্ডওয়্যারে চলমান ভার্চুয়াল মেশিনে ব্যবহৃত পার্টিশনগুলিতে OS অনুসন্ধান করার চেষ্টা করে।

আপনার যদি এটির প্রয়োজন হয় তবে আপনি এটি ছেড়ে যেতে পারেন, তবে উপরের সমস্তটি মনে রাখবেন। আমি অনলাইনে দুষ্টু হাত থেকে মুক্তি পাওয়ার জন্য রেসিপি খোঁজার পরামর্শ দিই।

এর সাথে আমরা প্রাথমিক ইনস্টলেশন সম্পন্ন করেছি। নতুন ইনস্টল করা ওএসে রিবুট করার সময় এসেছে। বুটযোগ্য লাইভ সিডি/ইউএসবি সরাতে ভুলবেন না।

#exit
#reboot

বুট ডিভাইস হিসাবে SATA SSD-এর যেকোনো একটি নির্বাচন করুন।

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

কেন অন্য ভিজি..?আসলে, আমাদের ইতিমধ্যেই রুট নামে একটি ভিজি রয়েছে। কেন এক ভিজিতে সবকিছু যোগ করবেন না?

যদি একটি ভিজিতে বেশ কয়েকটি পিভি থাকে, তাহলে ভিজি সঠিকভাবে সক্রিয় করার জন্য, সমস্ত পিভি উপস্থিত থাকতে হবে (অনলাইন)। ব্যতিক্রম হল LVM RAID, যা আমরা ইচ্ছাকৃতভাবে ব্যবহার করি না।

আমরা সত্যিই চাই যে RAID 6 অ্যারেগুলির যে কোনও একটিতে ব্যর্থতা (পড়ুন ডেটা ক্ষতি) হলে, অপারেটিং সিস্টেমটি স্বাভাবিকভাবে বুট হবে এবং আমাদের সমস্যা সমাধানের সুযোগ দেবে।

এটি করার জন্য, বিমূর্তকরণের প্রথম স্তরে আমরা প্রতিটি ধরণের শারীরিক "মিডিয়া"কে একটি পৃথক ভিজিতে বিচ্ছিন্ন করব।

বৈজ্ঞানিকভাবে বলতে গেলে, বিভিন্ন RAID অ্যারে বিভিন্ন "নির্ভরযোগ্যতা ডোমেন" এর অন্তর্গত। তাদের একটি ভিজিতে ক্র্যাম করে তাদের জন্য ব্যর্থতার একটি অতিরিক্ত সাধারণ পয়েন্ট তৈরি করা উচিত নয়।

"হার্ডওয়্যার" স্তরে LVM-এর উপস্থিতি আমাদেরকে বিভিন্ন RAID অ্যারের বিভিন্ন উপায়ে একত্রিত করে নির্বিচারে টুকরো টুকরো করতে দেয়। যেমন- রান একই সময়ে bcache + LVM থিন, bcache + BTRFS, LVM ক্যাশে + LVM থিন, ক্যাশে সহ একটি জটিল ZFS কনফিগারেশন, বা অন্য কোনো নরকীয় মিশ্রণ চেষ্টা করে দেখুন এবং তুলনা করুন।

"হার্ডওয়্যার" স্তরে, আমরা ভাল পুরানো "মোটা" LVM ভলিউম ছাড়া অন্য কিছু ব্যবহার করব না। এই নিয়মের ব্যতিক্রম ব্যাকআপ পার্টিশন হতে পারে।

আমি মনে করি এই মুহুর্তে, অনেক পাঠক ইতিমধ্যে বাসা বাঁধার পুতুল সম্পর্কে কিছু সন্দেহ করতে শুরু করেছেন।

SATA HDD-এ LVM

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

আবার নতুন ভিজি..?আমরা সত্যিই চাই যে আমরা ডেটা ব্যাকআপের জন্য যে ডিস্ক অ্যারে ব্যবহার করব তা ব্যর্থ হলে, আমাদের অপারেটিং সিস্টেম স্বাভাবিকভাবে কাজ করতে থাকবে, স্বাভাবিকভাবে নন-ব্যাকআপ ডেটাতে অ্যাক্সেস বজায় রেখে। তাই, ভিজি অ্যাক্টিভেশন সমস্যা এড়াতে আমরা একটি আলাদা ভিজি তৈরি করি।

LVM ক্যাশে সেট আপ করা হচ্ছে

NVMe RAID 1-এ একটি ক্যাশিং ডিভাইস হিসাবে ব্যবহার করার জন্য একটি LV তৈরি করা যাক।

#lvcreate -L 70871154688B --name cache root

এত কম কেন...?আসল বিষয়টি হ'ল আমাদের NVMe SSD-এরও একটি SLC ক্যাশে রয়েছে। 4 গিগাবাইট "ফ্রি" এবং 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-ক্যাশে ওভারের বিশেষ সুবিধা, উদাহরণস্বরূপ, 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

কেন এমন খণ্ড আকার..?ব্যবহারিক পরীক্ষা-নিরীক্ষার মাধ্যমে লেখক জানতে পেরেছেন যে 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
আসুন 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 প্রান্ত-সারিবদ্ধ হয়ে যাবে। এটি ক্যাশে করা ডিভাইসটিকে বাইপাস করে ক্যাশের মাধ্যমে সম্পূর্ণরূপে অপারেশন করার অনুমতি দেবে।

আসুন এলভিগুলিকে সংশ্লিষ্ট পিভিতে সরানো যাক:

#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 গিগাবাইট পর্যন্ত এসএসডি সম্পদ খেতে পারে।

পড়া লেখা মিশ্রিত?হ্যাঁ. এটি আলাদাভাবে পড়া এবং লেখার পরীক্ষা চালানোর জন্য বোধগম্য হয়। তদুপরি, সমস্ত ক্যাশে সিঙ্ক্রোনাইজ করা হয়েছে তা নিশ্চিত করা বোধগম্য হয় যাতে পূর্বে তৈরি করা লেখা পড়াকে প্রভাবিত না করে।

প্রথম লঞ্চের সময় এবং পরবর্তীতে ক্যাশে এবং পাতলা ভলিউম পূরণ হওয়ার ফলে ফলাফলগুলি ব্যাপকভাবে পরিবর্তিত হবে এবং শেষ লঞ্চের সময় ভরা ক্যাশেগুলিকে সিস্টেমটি সিঙ্ক্রোনাইজ করতে পেরেছিল কিনা তার উপরও নির্ভর করে।

অন্যান্য জিনিসগুলির মধ্যে, আমি ইতিমধ্যে একটি সম্পূর্ণ পাতলা ভলিউমের গতি পরিমাপের সুপারিশ করছি যেখান থেকে একটি স্ন্যাপশট নেওয়া হয়েছিল। প্রথম স্ন্যাপশট তৈরি করার পর অবিলম্বে কীভাবে এলোমেলো লেখাগুলি দ্রুত ত্বরান্বিত হয়, বিশেষ করে যখন ক্যাশে এখনও সম্পূর্ণরূপে পূর্ণ না হয় তা লেখকের পর্যবেক্ষণ করার সুযোগ ছিল। কপি-অন-রাইট লেখার শব্দার্থবিদ্যা, ক্যাশে সারিবদ্ধকরণ এবং পাতলা ভলিউম ব্লকের কারণে এটি ঘটে এবং RAID 6-এ র্যান্ডম লেখা RAID 6 থেকে র্যান্ডম রিডে পরিণত হয় এবং তারপরে ক্যাশে লিখতে হয়। আমাদের কনফিগারেশনে, RAID 6 থেকে র্যান্ডম রিডিং 6 গুণ পর্যন্ত (অ্যারেতে SATA SSD-এর সংখ্যা) লেখার চেয়ে দ্রুত। কারণ CoW-এর জন্য ব্লকগুলি একটি পাতলা পুল থেকে ক্রমানুসারে বরাদ্দ করা হয়, তারপরে রেকর্ডিং, বেশিরভাগ অংশে, ক্রমানুসারে পরিণত হয়।

এই উভয় বৈশিষ্ট্য আপনার সুবিধার জন্য ব্যবহার করা যেতে পারে.

ক্যাশে "সুসঙ্গত" স্ন্যাপশট

ক্যাশে ক্ষতি/ক্ষতির ক্ষেত্রে ডেটা হারানোর ঝুঁকি কমাতে, লেখক এই ক্ষেত্রে তাদের অখণ্ডতার গ্যারান্টি দেওয়ার জন্য স্ন্যাপশটগুলি ঘোরানোর অনুশীলন চালু করার প্রস্তাব করেছেন।

প্রথমত, যেহেতু পাতলা ভলিউম মেটাডেটা একটি আনক্যাশড ডিভাইসে থাকে, মেটাডেটা সামঞ্জস্যপূর্ণ হবে এবং সম্ভাব্য ক্ষতিগুলি ডেটা ব্লকের মধ্যে আলাদা করা হবে।

নিম্নলিখিত স্ন্যাপশট ঘূর্ণন চক্র ক্যাশে ক্ষতির ক্ষেত্রে স্ন্যাপশটগুলির ভিতরে ডেটার অখণ্ডতার গ্যারান্টি দেয়:

1. <name> নামের প্রতিটি পাতলা ভলিউমের জন্য, <name>. ক্যাশেড নামের একটি স্ন্যাপশট তৈরি করুন
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 SSD গুলি 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/বর্জন করুন

কারণ ডাটা স্টোরেজ ব্যবহার করা হবে 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 থেকে এই ধরনের ডিসকার্ডগুলি 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


এটার কাজ কি...?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 চরম নমনীয়তা দেয়।

দ্রষ্টব্য

পরবর্তী প্রবন্ধে, আমরা হোম ডেস্কটপ, হোম ইন্টারনেট এবং P2P নেটওয়ার্ক ব্যবহার করে বিভিন্ন মহাদেশে রিডানডেন্সি সহ একটি জিও-ডিস্ট্রিবিউটেড স্টোরেজ/ভিএম ক্লাস্টার তৈরির ভিত্তি হিসাবে বেশ কয়েকটি অনুরূপ মোবাইল স্টোরেজ সিস্টেম/কেভিএম ব্যবহার করার চেষ্টা করব।

উত্স: www.habr.com