تفاوت هارددیسک‌های Thin، Thick Lazily zeroed و Thick Eagerly zeroed در پلتفرم مجازی‌سازی VMware

سلام

امروز می‌خوام یک بار برای همیشه، به یک بازی کثیف خاتمه بدم!

اگه اهل مجازی‌سازی باشید، می‌دونید که وقتی توی پلتفرم VMware (اعم از ESXi، vSphere یا vCenter) بخواید یه ماشین مجازی بسازید، موقع ساختن هارددیسک مربوطه، ازتون یه سؤال می‌پرسه که می‌خواد این هارددیسک، Thin باشه، Thick (Eagerly zeroed) باشه یا این‌که Thick (Lazily zeroed).

اگه درست حدس زده باشم، خیلی از شماها هم دقیق نمی‌دونید تفاوت این‌ها چیه! پس یک بار برای همیشه، می‌خوام براتون توضیح بدم! پس با «دکتر IT» همراه باشید:

 

اول یه توضیح مختصر می‌دم، بعدش کامل همه رو توضیح می‌دم. برای درک بهتر مطلب، فرض می‌کنیم که یه datastore با ظرفیت 500 گیگابایت داریم و می‌خوام دو تا ماشین مجازی، یکی با ظرفیت هارد 300 گیگابایت و یکی هم با ظرفیت هارد 150 گیگابایت توی اون ایجاد کنیم. حالا می‌ریم سروقت حالت‌های مختلف:

1- Thin: توی این حالت، وقتی که ماشین مجازی رو می‌سازیم و نوع دیسک رو thin انتخاب می‌کنیم، ابتدای امر، تمام فضای انتخاب شده به این ماشین اختصاص داده نمی‌شه. یعنی چی؟ یعنی این‌که شما می‌گید ماشین من باید 300 گیگابایت فضای هارددیسک داشته باشه. پلتفرم VMware هم می‌گه «چشم! حالا شما بیا کارت رو شروع کن، هر چقدر خواستی، کم‌کم بهت فضا می‌دم! فقط حواست باشه که فقط و فقط 300 گیگابایت اجازه داری که فضا حروم کنی!» ما هم شرایط رو قبول می‌کنیم و کار رو شروع می‌کنیم:

همون‌طور که توی عکس بالا بهتون نشون دادم، وقتی ماشین مجازی رو می‌سازیم، یه کوچولو از فضای هارددیسک استفاده می‌شه و وقتی هم که ویندوز رو نصب می‌کنیم، به اندازه‌ی حجم فایل‌های ویندوز (ما فرض می‌کنیم که 30 گیگابایت)، مجدداً از اون فضا به ماشین ما تخصیص داده می‌شه.

2- Thick: توی این حالت، وقتی ماشین مجازی رو می‌سازیم و به هارددیسکش 300 گیگابایت فضا اختصاص می‌دیم، تمام اون فضا به صورت یکجا در اختیار ماشین مجازی‌مون قرار می‌گیره. یعنی مثل عکس زیر:

همون‌طور که توی عکس هم مشخصه، دیگه نصب ویندوز، هیچ تأثیری توی فضای اشغال شده‌ی Datastore ما نداره. حالا اگه توی این حالت یه ماشین دیگه هم درست کنیم و بهش یه هارد 150 گیگابایتی اختصاص بدیم، یه چنین چیزی خواهیم داشت:

همون‌طوری که مشخصه، تقریباً تمام فضای Datastore ما اشغال شده و تقریباً 50 گیگابایت خالی داریم که می‌تونیم یه ماشین مجازی دیگه بسازیم یا ازش برای اسنپ‌شات استفاده کنیم. (که بعداً درباره‌ش حرف می‌زنم)

شاید بپرسید که «پس چرا حالتی که روی Datastore دو تا ماشین مجازی با هارددیسک Thin می‌خوایم بسازیم رو نگفتی؟» باید بگم که اون قضیه‌ش یه مقدار پیچیده‌تره!

یادتون گفتم VMware بهمون گفت «هر چقدر فضا خواستی، کم‌کم بهت می‌دم»؟ این‌جا رو با دقت و مرحله به مرحله می‌ریم جلو:

الف) اول ماشین مجازی شماره‌ی 1 که با رنگ آبی نشون داده‌م رو می‌سازیم و روی اون ویندوز نصب می‌کنیم:

ب) بعد ماشین مجازی شماره‌ی 2 که با رنگ زرد نشون داده‌م رو می‌سازیم و روی اون ویندوز نصب می‌کنیم:

خیلی هم عالی! دو تا ماشین مجازی داریم که ویندوز روش نصب کردیم، ولی هنوز 430 گیگابایت از فضای Datastore مون خالی مونده! ولی حالا ببینیم بعدش چه بلایی قراره سرمون بیاد!

ج) فرض می‌کنیم که یه فایل با حجم 40 گیگابایت روی ماشین شماره‌ی 1 کپی می‌کنیم و وقتی کارِمون تموم شد، یه فایل 20 گیگابایتی هم روی ماشین شماره‌ی 2 کپی می‌کنیم:

نتیجه یه چنین چیزی می‌شه! شاید از نظر زیبایی‌شناسی تصویر قشنگی باشه، امّا از نظر Performance افتضاحه! چرا؟ الان بهتون می‌گم! (خودِ من وقتی اولین بار چنین فرایندی رو دیدم، یهو گفتم «عجب fragmentation وحشتناکی!»)
د) حالا فرض کنین که اون فایل 40 گیگابایتی رو از روی ماشین شماره‌ی 1 پاک می‌کنیم و بعدش یه فایل 80 گیگابایتی روش کپی می‌کنیم:

همون‌طور که می‌بینید، توی مرحله‌ی اول اون فضای 40 گیگابایتی دوباره به Datastore تعلق می‌گیره (البته نه به همین راحتی. نیاز به عمل reclaim داره که شاید یه روزی در موردش نوشتم!)؛ ولی خبری از این‌که اون فضا توسط فایل‌های موجود پر بشه نیست و ما می‌مونیم و فضای خالی، بین دو تا فضای استفاده شده!

البته که این فضا، توی مرحله‌ی دوم پر می‌شه؛ امّا به این صورت که ما یه فایل 80 گیگابایتی رو روی هارددیسک ماشین شماره‌ی 1 کپی کردیم که 40 گیگابایتش توی یه قسمت از Datastore ذخیره شده و 40 گیگابایتش توی یه قسمت دیگه! وقتی که ما بخوایم به این فایل دسترسی داشته باشیم، تفاوت جایگاه بیت‌های مربوط به اون فایل، باعث می‌شه که ما با کُندی سیستم مواجه بشیم.

یادتون باشه فقط وقتی از هارددیسک‌های thin استفاده کنید که توی محیط آزمایشی (مثلاً کامپیوتر یا لپ‌تاپ شخصی) و برای تمرین بخواید از VMWare استفاده کنید و مشکل کمبود جا داشته باشید. توی محیط‌های واقعی و برای سازما‌ن‌ها، حتماً و حتماً از حالت thick استفاده کنید.

حالا که تفاوت هارددیسک‌های thin و thick رو فهمیدیم، بریم ببینیم که تفاوت هارددیسک Eagerly Zeroed و Lazyly Zeroed توی هارددیسک‌های thick چی هست.

قبلش یه توضیح کوچولو باید بدم:

هر بایت از 8 بیت تشکیل شده و هر بیت، مقداری برابر با 0 یا 1 هست. یعنی وقتی شما فایلی رو کپی می‌کنید روی هارددیسک، اون فایل به صورت مجموعه‌ای از 0 و 1ها ذخیره می‌شه. پاک کردن فایل هم به این صورت نیست که تمام اون بیت‌های 0 و 1 پاک بشن؛ بلکه فقط روی یکی از بیت‌ها این تغییر به وجود میاد و باعث می‌شه که اون فایل قابل نمایش باشه یا به عنوان فایل پاک شده به حساب بیاد. (خودم دارم دنبالش می‌گردم که ببینم روندش چجوریه! ان شا الله وقتی فهمیدم، براتون می‌گم!)

حالا ما وقتی فایل رو جایی کپی می‌کنیم که یه فایل قبلاً روش بوده، سیستم عامل میاد تک‌تک اون بیت‌ها رو چک می‌کنه. اگه توی فایل جدید اون بیت برابر با فایل قدیمی بود، کاری باهاش نداره. امّا اگه بیتش فرق داشت، باید اون رو یک بار 0 کنه و بعدش تغییر بده و به 0 یا 1 تبدیل کنه.

حالا تصور کنید که تمام بیت‌های قبلی به 0 تبدیل شده‌ باشن! این‌جوری وقتی یه فایل جدید کپی می‌کنیم، دیگه نیازی به چک کردن بیت‌های قبلی نیست و فایل جدید، مستقیماً بیت‌های خودش رو کپی می‌کنه. این‌جوری سرعت کار بیشتر می‌شه.

تفاوت Lazily Zeroed و Eagerly Zeroed هم دقیقاً همینه! توی حالت Lazily zeroed، (همون‌طور که تنبلی از اسمش مشخصه!) سیستم عامل کاری با بیت‌های قبلی نداره و می‌گه «بی‌خیال! هر وقت خواست فایل جدید کپی کنه، می‌ریم بیت‌ها رو چک می‌کنیم! فعلاً هارددیسک رو براش بسازیم که کارِش راه بیفته!» و به همین دلیل هم سرعت ساخت این هارددیسک، بیشتر از Eagerly zeroed هست. و ایضاً به همین دلیل که کاری با بیت‌های قبلی نداره، در صورتی که نیاز به recovery اطلاعات داشته باشید، امکان بازیابی اون‌ها بیشتره.

توی حالت Eagerly zeroed، VMware میاد و تمام بیت‌ها رو به 0 تبدیل می‌کنه. درسته که وقتی هارددیسک‌تون داره ساخته می‌شه زمان بیشتری نیاز دارید، امّا در عوض موقع کار، سرعت‌تون بیشتر می‌شه!

اگه بخوام این سه حالت رو جمع‌بندی کنم، می‌تونم یه مثال براتون بزنم:

1) فرض کنید که اسباب‌کشی کردید و کارگرها همین‌طور بدون نظم و ترتیب، وسایل شما رو میارن توی خونه‌ی جدید. بهشون نگفتید که کارتن‌های ظروف رو بذارن توی آشپزخونه، تخت و کمد رو بذارن توی اتاق خواب و مبل‌ها رو بذارن توی هال. همین‌جوری همه‌چی رو می‌ذارن توی هال و می‌رن! بنابراین محتمل هست که کارتن ظروف جهاز همسرتون رو زیر مبل پیدا کنید و لباس‌ها رو توی یخچال! بگذریم که ممکنه تاج تخت دم دست باشه، ولی پایه‌ش زیر بقیه‌ی وسایل! (مثال فایل 80 گیگابایتی یادتون هست که 40 گیگابایتش یه جا بود و 40 گیگابایت دیگه‌ش یه جای دیگه؟!) لازم به توضیح نیست که تخلیه‌ی اسباب و اثاثیه‌تون توسط کارگرها خیلی زود انجام شده، ولی مرتب کردن این بلبشو کلّی زمان می‌بره! (thin)

2) حالا فرض کنید که یه خونه‌ی مبله اجاره کردید که صاحبخونه گفته من یه سری وسایل و اسباب دارم توی خونه. تنبلیم میاد ببرم‌شون (lazy)! شما بیا ببین، هر کدوم به دردت خورد رو نگه دار، هر کدوم رو هم نخواستی بنداز دور!

توی فرایند این اسباب‌کشی، چک کردن وسایل به دردبخور قبلی و جایگزین کردن/ نکردن اون‌ها، کلّی وقت‌شما رو تلف می‌کنه. امّا از طرفی نیاز ندارین همه‌ی وسایل خودتون رو جابجا کنید. این‌جوری کارِ اسباب‌کشی‌تون زودتر تموم می‌شه.

3) حالا یه صاحب‌خونه‌ی تر و فرز (eager) به تورتون خورده که دیروز قرار داد رو امضا کرده و امروز می‌گه «خونه رو خالی کردم، فردا می‌تونید اسباب‌هاتون رو بیارید!» شما هم آدم منظم و مرتب؛ همه‌ی وسایل به ترتیب وارد خونه‌ی جدید می‌شه و همون ابتدای کار، توی جای خودش قرار می‌گیره! شاید تخلیه‌ی خونه توسط صاحبخونه‌ی قبلی یه خُرده وقت شما رو بگیره، ولی مطمئن باشید که ارزشش رو داره!

با تشکر از مهندس احسان کریمی‌نیا که موضوع رو برای من کاملاً روشن کرد. اگه من نتونستم براتون روشن کنم، ایراد از منه!

باز هم اگه سؤالی بود، می‌تونید همین‌جا بپرسید! امیدوارم که این مسأله براتون جا افتاده باشه.

خداحافظ!