ہائے، مجھے حال ہی میں ایک دلچسپ کام کا سامنا کرنا پڑا: بڑی تعداد میں بلاک ڈیوائسز کا بیک اپ لینے کے لیے اسٹوریج ترتیب دینا۔
ہم ہر ہفتے اپنے کلاؤڈ میں تمام ورچوئل مشینوں کا بیک اپ لیتے ہیں، اس لیے ہمیں ہزاروں بیک اپ کا انتظام کرنے اور اسے جلد سے جلد اور مؤثر طریقے سے کرنے کی ضرورت ہے۔
بدقسمتی سے، معیاری ترتیب RAID5, RAID6 اس صورت میں، وہ ایسا نہیں کرنا چاہیں گے کیونکہ ہماری جیسی بڑی ڈسکوں پر ریکوری کا عمل انتہائی لمبا ہوگا اور غالباً کبھی ختم نہیں ہوگا۔
آئیے غور کریں کہ کیا متبادل ہیں:
— RAID5 اور RAID6 کی طرح، لیکن قابل ترتیب برابری کی سطح کے ساتھ۔ اس صورت میں، فالتو پن ایک بلاک بہ بلاک کی بنیاد پر نہیں، بلکہ فی آبجیکٹ کی بنیاد پر انجام دیا جاتا ہے۔ مٹانے والے کوڈنگ کو آزمانے کا آسان ترین طریقہ تعینات کرنا ہے۔ .
— یہ فی الحال غیر ریلیز شدہ ZFS فیچر ہے۔ RAIDZ کے برعکس، DRAID کے پاس تقسیم شدہ برابری بلاک ہے اور یہ ریکوری کے دوران صف میں موجود تمام ڈسکوں کو استعمال کرتا ہے، جس سے یہ ڈسک کی ناکامیوں کے لیے زیادہ لچکدار ہوتا ہے اور کریش کے بعد تیزی سے ٹھیک ہو جاتا ہے۔
ایک سرور دستیاب ہے۔ Fujitsu Primergy RX300 S7 ایک پروسیسر کے ساتھ Intel Xeon CPU E5-2650L 0 @ 1.80GHz، نو رام ماڈیولز Samsung DDR3-1333 8Gb PC3L-10600R ECC رجسٹرڈ (M393B1K70DH0-YH9)، ڈسک شیلف Supermicro SuperChassis 847E26-RJBOD1، کے ذریعے منسلک ڈوئل LSI SAS2X36 Expander اور 45 ڈسکس سیگیج ST6000NM0115-1YZ110 پر 6TB ہر ایک
کسی بھی چیز کا فیصلہ کرنے سے پہلے، ہمیں سب سے پہلے ہر چیز کو صحیح طریقے سے جانچنے کی ضرورت ہے۔
ایسا کرنے کے لیے، میں نے مختلف کنفیگریشنز کو تیار اور تجربہ کیا۔ اس کے لیے، میں نے minio کا استعمال کیا، جس نے S3 بیک اینڈ کے طور پر کام کیا اور اسے مختلف اہداف کے ساتھ مختلف طریقوں میں چلایا۔
منیو کیس کا بنیادی طور پر ایریزور کوڈنگ بمقابلہ سافٹ ویئر چھاپے میں ایک ہی تعداد میں ڈسکوں اور برابری ڈسکوں کے ساتھ تجربہ کیا گیا تھا، یعنی: RAID6، RAIDZ2 اور DRAID2۔
حوالہ کے لیے: جب آپ صرف ایک ہدف کے ساتھ minio چلاتے ہیں، minio S3 گیٹ وے موڈ میں کام کرتا ہے، آپ کے مقامی فائل سسٹم کو S3 اسٹوریج کے طور پر پیش کرتا ہے۔ اگر آپ ایک سے زیادہ اہداف کے ساتھ minio چلاتے ہیں، تو Erasure Coding موڈ خود بخود فعال ہو جاتا ہے، جو آپ کے اہداف میں ڈیٹا کو پھیلائے گا، اور غلطی کو برداشت کرے گا۔
پہلے سے طے شدہ طور پر، منیو اہداف کو 16 ڈسکوں کے گروپس میں تقسیم کرتا ہے، فی گروپ دو برابری ڈسک کے ساتھ۔ اس کا مطلب ہے کہ ڈیٹا کے نقصان کے بغیر دو ڈسک بیک وقت ناکام ہو سکتی ہیں۔
کارکردگی کی جانچ کے لیے، میں نے 16 ڈسکیں استعمال کیں، ہر ایک 6 ٹی بی، اور ان پر چھوٹی 1 ایم بی اشیاء لکھیں۔ اس نے ہمارے مستقبل کے کام کے بوجھ کو درست طریقے سے بیان کیا، کیونکہ تمام جدید بیک اپ ٹولز ڈیٹا کو کئی میگا بائٹس کے بلاکس میں تقسیم کرتے ہیں اور انہیں اس طرح لکھتے ہیں۔
بینچ مارک کو منظم کرنے کے لیے، s3bench یوٹیلیٹی کو ایک ریموٹ سرور پر چلایا گیا تھا، جو سینکڑوں تھریڈز میں دسیوں ہزار ایسی اشیاء کو منیو پر بھیجتا تھا۔ اس کے بعد ان سے اسی انداز میں واپسی کی درخواست کرنے کی کوشش کی گئی۔
بینچ مارک کے نتائج درج ذیل جدول میں دکھائے گئے ہیں:
جیسا کہ ہم دیکھ سکتے ہیں، ایک ہی ترتیب میں سافٹ ویئر RAID6، RAIDZ2، اور DRAID2 کے اوپر چلنے والے minio کے مقابلے میں مقامی مٹانے والے کوڈنگ موڈ میں minio نمایاں طور پر خراب کارکردگی کا مظاہرہ کرتا ہے۔
مجھے الگ سے میں نے ایکسٹ 4 بمقابلہ ایکس ایف ایس پر منیو کا تجربہ کیا۔ حیرت انگیز طور پر، میرے کام کے بوجھ کی قسم کے لیے، XFS ext4 کے مقابلے میں نمایاں طور پر سست نکلا۔
ٹیسٹ کے پہلے بیچ میں Mdadm نے ZFS پر برتری ظاہر کی، لیکن بعد میں ، کہ آپ درج ذیل اختیارات کو ترتیب دے کر ZFS کی کارکردگی کو بہتر بنا سکتے ہیں:
xattr=sa atime=off recordsize=1Mاور اس کے بعد ZFS کے ساتھ ٹیسٹ بہت بہتر ہو گئے۔
آپ یہ بھی دیکھ سکتے ہیں کہ DRAID RAIDZ کے مقابلے میں کوئی قابل ذکر کارکردگی کا فائدہ فراہم نہیں کرتا ہے، لیکن نظریہ طور پر یہ زیادہ محفوظ ہونا چاہیے۔
پچھلے دو ٹیسٹوں میں، میں نے میٹا ڈیٹا (خصوصی) اور ZIL (لاگ) کو ایس ایس ڈی آئینے میں منتقل کرنے کی بھی کوشش کی۔ لیکن میٹا ڈیٹا کو منتقل کرنے سے لکھنے کی رفتار کا زیادہ فائدہ نہیں ہوا، اور ZIL کو منتقل کرنے کے نتیجے میں ہم نے 100% استعمال کے ساتھ ایک حد کو مارا، لہذا میں اس ٹیسٹ کو ناکام سمجھتا ہوں۔ میں اس بات کو مسترد نہیں کرتا کہ اگر میرے پاس تیز SSD ڈرائیوز ہوتیں تو اس سے میرے نتائج میں نمایاں بہتری آتی، لیکن بدقسمتی سے، میرے پاس وہ نہیں تھیں۔
آخر میں، میں نے DRAID کا استعمال بند کرنے کا فیصلہ کیا اور اس کے بیٹا اسٹیٹس کے باوجود، یہ ہمارے معاملے میں سب سے تیز اور موثر اسٹوریج حل ہے۔
میں نے تین گروپوں اور دو تقسیم شدہ اسپیئرز کے ساتھ ترتیب میں ایک سادہ DRAID2 بنایا:
# zpool status data
pool: data
state: ONLINE
scan: none requested
config:
NAME STATE READ WRITE CKSUM
data ONLINE 0 0 0
draid2:3g:2s-0 ONLINE 0 0 0
sdy ONLINE 0 0 0
sdam ONLINE 0 0 0
sdf ONLINE 0 0 0
sdau ONLINE 0 0 0
sdab ONLINE 0 0 0
sdo ONLINE 0 0 0
sdw ONLINE 0 0 0
sdak ONLINE 0 0 0
sdd ONLINE 0 0 0
sdas ONLINE 0 0 0
sdm ONLINE 0 0 0
sdu ONLINE 0 0 0
sdai ONLINE 0 0 0
sdaq ONLINE 0 0 0
sdk ONLINE 0 0 0
sds ONLINE 0 0 0
sdag ONLINE 0 0 0
sdi ONLINE 0 0 0
sdq ONLINE 0 0 0
sdae ONLINE 0 0 0
sdz ONLINE 0 0 0
sdan ONLINE 0 0 0
sdg ONLINE 0 0 0
sdac ONLINE 0 0 0
sdx ONLINE 0 0 0
sdal ONLINE 0 0 0
sde ONLINE 0 0 0
sdat ONLINE 0 0 0
sdaa ONLINE 0 0 0
sdn ONLINE 0 0 0
sdv ONLINE 0 0 0
sdaj ONLINE 0 0 0
sdc ONLINE 0 0 0
sdar ONLINE 0 0 0
sdl ONLINE 0 0 0
sdt ONLINE 0 0 0
sdah ONLINE 0 0 0
sdap ONLINE 0 0 0
sdj ONLINE 0 0 0
sdr ONLINE 0 0 0
sdaf ONLINE 0 0 0
sdao ONLINE 0 0 0
sdh ONLINE 0 0 0
sdp ONLINE 0 0 0
sdad ONLINE 0 0 0
spares
s0-draid2:3g:2s-0 AVAIL
s1-draid2:3g:2s-0 AVAIL
errors: No known data errorsٹھیک ہے، ہم نے اسٹوریج کا احاطہ کر لیا ہے، اب آئیے اس کے بارے میں بات کرتے ہیں کہ ہم کس چیز کا بیک اپ لیں گے۔ میں تین حل بتانا چاہوں گا جن کی میں نے ابھی کوشش کی ہے:
--.کانٹا , ایک خصوصی بلاک ڈیوائس بیک اپ حل، Ceph کے ساتھ سخت انضمام رکھتا ہے۔ یہ سنیپ شاٹس کے درمیان فرق نکال سکتا ہے اور ان سے اضافی بیک اپ بنا سکتا ہے۔ یہ مقامی اور S3 دونوں سمیت اسٹوریج بیک اینڈ کی وسیع رینج کو سپورٹ کرتا ہے۔ ڈپلیکیشن ہیش ٹیبل کو ذخیرہ کرنے کے لیے اسے علیحدہ ڈیٹا بیس کی ضرورت ہے۔ Cons: یہ Python میں لکھا گیا ہے اور اس میں کسی حد تک غیر جوابی کلی ہے۔
--.کانٹا , ایک طویل معروف اور ثابت شدہ بیک اپ ٹول، ڈیٹا کا بیک اپ لے سکتا ہے اور اسے اچھی طرح سے نقل کر سکتا ہے۔ یہ scp کے ذریعے مقامی طور پر اور ریموٹ سرور پر بیک اپ محفوظ کر سکتا ہے۔ اگر پرچم کے ساتھ چلایا جائے تو یہ بلاک ڈیوائسز کا بیک اپ لے سکتا ہے۔ --specialایک منفی پہلو: بیک اپ بناتے وقت، ذخیرہ مکمل طور پر مقفل ہوجاتا ہے، اس لیے ہر ورچوئل مشین کے لیے علیحدہ ذخیرہ بنانے کی سفارش کی جاتی ہے۔ یہ کوئی مسئلہ نہیں ہے، کیونکہ ان کو بنانا آسان ہے۔
- ایک فعال طور پر ترقی پذیر پروجیکٹ، جو گو میں لکھا گیا ہے، کافی تیز ہے اور بڑی تعداد میں اسٹوریج بیک اینڈز کو سپورٹ کرتا ہے، بشمول لوکل اسٹوریج، scp، S3، اور بہت کچھ۔ یہ بھی قابل غور ہے کہ وہاں ایک خاص طور پر بنایا گیا ہے۔ ریسٹک کے لیے، جو دور دراز کے استعمال کے لیے اسٹوریج کی تیز ترین برآمد کی اجازت دیتا ہے۔ مندرجہ بالا سب میں سے، مجھے یہ سب سے زیادہ پسند آیا۔ یہ stdin سے بیک اپ لے سکتا ہے۔ اس میں تقریباً کوئی قابل توجہ خرابیاں نہیں ہیں، لیکن چند خصوصیات ہیں:
-
سب سے پہلے، میں نے اسے تمام VMs (جیسے بینجی) کے لیے مشترکہ ذخیرے کے طور پر استعمال کرنے کی کوشش کی، اور اس نے اچھی طرح کام کیا، لیکن بحالی کی کارروائیوں میں کافی وقت لگا کیونکہ ریسٹک ہر بحالی سے پہلے تمام بیک اپ کے میٹا ڈیٹا کو پڑھنے کی کوشش کرتا ہے۔ یہ مسئلہ آسانی سے حل ہو گیا، جیسا کہ بورگ کے ساتھ، ہر VM کے لیے علیحدہ ذخیرہ بنا کر۔ یہ طریقہ بیک اپ مینجمنٹ کے لیے بھی بہت موثر ثابت ہوا۔ ڈیٹا تک رسائی کے لیے علیحدہ ذخیروں میں الگ پاس ورڈ ہو سکتے ہیں، اور ہمیں عالمی ریپو بریکنگ کے بارے میں فکر کرنے کی ضرورت نہیں ہے۔ نئی ریپوزٹری بنانا اتنا ہی آسان ہے جتنا بورگ بیک اپ کے ساتھ۔
کسی بھی صورت میں، ڈپلیکیشن صرف بیک اپ کے پچھلے ورژن کی نسبت کی جاتی ہے، پچھلے بیک اپ کا تعین مخصوص بیک اپ کے راستے سے ہوتا ہے، لہذا اگر آپ stdin سے ایک عام ریپوزٹری میں مختلف اشیاء کا بیک اپ لے رہے ہیں، تو آپشن کی وضاحت کرنا نہ بھولیں۔
--stdin-filename، یا ہر بار واضح طور پر اختیار کی وضاحت کریں۔--parent.
-
دوم، stdout کو بحال کرنے میں اس کی متوازی نوعیت کی وجہ سے فائل سسٹم کو بحال کرنے سے کافی زیادہ وقت لگتا ہے۔ مستقبل میں، ہم بلاک ڈیوائس بیک اپ کے لیے مزید سخت سپورٹ شامل کرنے کا ارادہ رکھتے ہیں۔
-
سوم، اس وقت اسے استعمال کرنے کی سفارش کی جاتی ہے۔ کیونکہ ورژن 0.9.6 میں بڑی فائلوں کی طویل بازیافت کے ساتھ ایک بگ ہے۔
بیک اپ کی کارکردگی اور بیک اپ/بحالی کی رفتار کو جانچنے کے لیے، میں نے ایک الگ ذخیرہ بنایا اور ایک چھوٹی ورچوئل مشین امیج (21 جی بی) کا بیک اپ لینے کی کوشش کی۔ میں نے اصل میں ترمیم کیے بغیر دو بیک اپ کیے، درج کردہ حلوں میں سے ہر ایک کا استعمال کرتے ہوئے، یہ جانچنے کے لیے کہ ڈپلیکیٹ شدہ ڈیٹا کو کتنا تیز/آہستہ کاپی کیا گیا۔
جیسا کہ ہم دیکھ سکتے ہیں، بورگ بیک اپ میں ابتدائی بیک اپ کی کارکردگی کا بہترین تناسب ہے، لیکن لکھنے اور بحال کرنے کی رفتار دونوں کے لحاظ سے کھو جاتا ہے۔
ریسٹک بینجی بیک اپ سے زیادہ تیز نکلا، لیکن اسے stdout پر بحال ہونے میں زیادہ وقت لگتا ہے، اور بدقسمتی سے، یہ ابھی تک بلاک ڈیوائس پر براہ راست نہیں لکھ سکتا۔
تمام فوائد اور نقصانات کو تولنے کے بعد، میں نے طے کرنے کا فیصلہ کیا۔ آرام دہ с آرام سرور سب سے آسان اور امید افزا بیک اپ حل کے طور پر۔
اس اسکرین کاسٹ میں، آپ دیکھ سکتے ہیں کہ کس طرح ایک 10 گیگا بٹ چینل کو بیک وقت چلنے والے متعدد بیک اپ آپریشنز کے ذریعے مکمل طور پر استعمال کیا جاتا ہے۔ یہ بات قابل غور ہے کہ ڈسک کا استعمال 30% سے زیادہ نہیں ہے۔
مجھے ملنے والے فیصلے سے میں زیادہ مطمئن تھا!
ماخذ: www.habr.com
