بهار امسال ما قبلاً در مورد برخی از موضوعات مقدماتی بحث کرده ایم، به عنوان مثال، چگونه سرعت درایوهای خود را بررسی کنیم и RAID چیست. در مورد دوم، ما حتی قول دادیم که به مطالعه عملکرد توپولوژی های چند دیسک مختلف در ZFS ادامه دهیم. این سیستم فایل نسل بعدی است که اکنون در همه جا پیاده سازی می شود: از اپل به اوبونتو.

خوب، امروز بهترین روز برای آشنایی با ZFS، خوانندگان کنجکاو است. فقط بدانید که به نظر متواضع توسعه دهنده OpenZFS مت آرنز، "این واقعا سخت است."

اما قبل از اینکه به اعداد و ارقام برسیم - و قول می‌دهم آنها خواهند شد - برای همه گزینه‌های پیکربندی ZFS هشت دیسکی، باید در مورد آن صحبت کنیم. مانند به طور کلی، ZFS داده ها را روی دیسک ذخیره می کند.

Zpool، vdev و دستگاه

این نمودار کامل شامل سه vdevs کمکی، یکی از هر کلاس، و چهار برای RAIDz2 است.

معمولاً دلیلی برای ایجاد مجموعه‌ای از انواع و اندازه‌های vdev نامتناسب وجود ندارد - اما اگر بخواهید چیزی مانع از انجام این کار نمی‌شود.

برای درک واقعی سیستم فایل ZFS، باید به ساختار واقعی آن نگاه کنید. اول، ZFS سطوح سنتی مدیریت حجم و فایل سیستم را یکسان می کند. ثانیا، از مکانیزم تراکنشی کپی بر روی نوشتن استفاده می کند. این ویژگی ها به این معنی است که سیستم از نظر ساختاری بسیار متفاوت از سیستم های فایل معمولی و آرایه های RAID است. اولین مجموعه از بلوک‌های اساسی برای درک، استخر ذخیره‌سازی (zpool)، دستگاه مجازی (vdev) و دستگاه واقعی (دستگاه) است.

zpool

استخر ذخیره سازی zpool بالاترین ساختار ZFS است. هر استخر شامل یک یا چند دستگاه مجازی است. به نوبه خود، هر یک از آنها حاوی یک یا چند دستگاه واقعی (دستگاه) است. استخرهای مجازی بلوک های مستقلی هستند. یک کامپیوتر فیزیکی می‌تواند شامل دو یا چند استخر مجزا باشد، اما هر کدام کاملاً مستقل از بقیه هستند. استخرها نمی توانند دستگاه های مجازی را به اشتراک بگذارند.

افزونگی ZFS در سطح دستگاه مجازی است نه در سطح استخر. مطلقاً هیچ افزونگی در سطح استخر وجود ندارد - اگر یک درایو vdev یا vdev ویژه از بین برود، کل استخر نیز همراه با آن از بین می رود.

استخرهای ذخیره سازی مدرن می توانند از دست دادن حافظه پنهان یا گزارش دستگاه مجازی جان سالم به در ببرند - اگرچه اگر گزارش vdev را در طول قطع برق یا خرابی سیستم از دست بدهند، می توانند مقدار کمی از داده های کثیف را از دست بدهند.

یک تصور غلط رایج وجود دارد که ZFS "نوارهای داده" در کل استخر نوشته می شود. این درست نیست. Zpool اصلا RAID0 خنده دار نیست، بلکه خنده دار است JBOD با مکانیزم توزیع متغیر پیچیده

در بیشتر موارد، رکوردها با توجه به فضای آزاد موجود بین دستگاه های مجازی موجود توزیع می شوند، بنابراین در تئوری همه آنها به طور همزمان پر می شوند. در نسخه‌های بعدی ZFS، استفاده (استفاده) از vdev در نظر گرفته می‌شود - اگر یک دستگاه مجازی به طور قابل توجهی شلوغ‌تر از دیگری باشد (مثلاً به دلیل بار خواندن)، با وجود داشتن بالاترین رایگان، به طور موقت برای نوشتن صرفنظر می‌شود. نسبت فضا

مکانیسم تشخیص استفاده که در روش‌های تخصیص نوشتاری مدرن ZFS تعبیه شده است، می‌تواند تأخیر را کاهش دهد و توان عملیاتی را در دوره‌های بار غیرمعمول بالا افزایش دهد - اما اینطور نیست. کاغذ سفید در مورد مخلوط کردن غیرارادی هارد دیسک های آهسته و SSD های سریع در یک استخر. چنین استخری نابرابر همچنان با سرعت کندترین دستگاه کار می کند، یعنی گویی کاملاً از چنین دستگاه هایی تشکیل شده است.

vdev

هر مخزن ذخیره سازی از یک یا چند دستگاه مجازی (دستگاه مجازی، vdev) تشکیل شده است. به نوبه خود، هر vdev حاوی یک یا چند دستگاه واقعی است. اکثر دستگاه های مجازی برای ذخیره سازی ساده داده ها استفاده می شوند، اما چندین کلاس کمکی vdev از جمله CACHE، LOG و SPECIAL وجود دارد. هر یک از این انواع vdev می تواند یکی از پنج توپولوژی داشته باشد: تک دستگاه (تک دستگاه)، RAIDz1، RAIDz2، RAIDz3، یا آینه (آینه).

RAIDz1، RAIDz2 و RAIDz3 انواع خاصی از آنچه قدیمی ها RAID برابری دوگانه (مورب) می نامند هستند. 1، 2 و 3 به تعداد بلوک های برابری برای هر نوار داده اشاره دارد. به جای دیسک های جداگانه برای برابری، دستگاه های مجازی RAIDz این برابری را به طور نیمه یکنواخت در بین دیسک ها توزیع می کنند. یک آرایه RAIDz می تواند به اندازه بلوک های برابری دیسک های خود را از دست بدهد. اگر یکی دیگر را از دست بدهد، خراب می شود و استخر ذخیره سازی را با خود می برد.

در دستگاه‌های مجازی آینه‌ای (mirror vdev)، هر بلوک در هر دستگاه در vdev ذخیره می‌شود. اگرچه آینه‌های دو پهن رایج‌ترین هستند، هر تعداد دلخواه دستگاه می‌تواند در یک آینه باشد - سه تایی اغلب در تاسیسات بزرگ برای بهبود عملکرد خواندن و تحمل خطا استفاده می‌شوند. یک آینه vdev تا زمانی که حداقل یک دستگاه در vdev به کار خود ادامه دهد می تواند از هر گونه خرابی جان سالم به در ببرد.

vdev های منفرد ذاتا خطرناک هستند. چنین دستگاه مجازی از یک شکست جان سالم به در نخواهد برد - و اگر به عنوان ذخیره سازی یا vdev ویژه استفاده شود، خرابی آن منجر به از بین رفتن کل استخر می شود. اینجا خیلی خیلی مواظب باش

CACHE، LOG و SPECIAL VAs را می توان با استفاده از هر یک از توپولوژی های بالا ایجاد کرد - اما به یاد داشته باشید که از دست دادن SPECIAL VA به معنای از بین رفتن استخر است، بنابراین یک توپولوژی اضافی به شدت توصیه می شود.

دستگاه

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

دیسک ها - اعم از مغناطیسی یا جامد - رایج ترین دستگاه های بلوکی هستند که به عنوان بلوک های سازنده vdev استفاده می شوند. با این حال، هر دستگاهی که یک توصیفگر در / dev داشته باشد این کار را انجام می دهد، بنابراین کل آرایه های RAID سخت افزاری می توانند به عنوان دستگاه های جداگانه استفاده شوند.

یک فایل خام ساده یکی از مهم ترین دستگاه های بلوک جایگزین است که می توان یک vdev از آن ساخت. استخرهای تست از فایل های پراکنده یک راه بسیار مفید برای بررسی دستورات استخر و مشاهده میزان فضای موجود در یک استخر یا دستگاه مجازی از یک توپولوژی معین است.

شما می توانید یک استخر آزمایشی از فایل های پراکنده تنها در چند ثانیه ایجاد کنید - اما فراموش نکنید که پس از آن کل استخر و اجزای آن را حذف کنید.

فرض کنید می‌خواهید یک سرور را روی هشت دیسک قرار دهید و قصد دارید از دیسک‌های 10 ترابایتی (~9300 گیگابایت) استفاده کنید - اما مطمئن نیستید که کدام توپولوژی بهترین نیازهای شما را دارد. در مثال بالا، ما یک استخر آزمایشی از فایل های پراکنده در چند ثانیه می سازیم - و اکنون می دانیم که یک RAIDz2 vdev از هشت دیسک 10 ترابایتی 50 TiB ظرفیت قابل استفاده را فراهم می کند.

کلاس ویژه دیگر دستگاه ها SPARE (یدک) است. دستگاه‌های Hot Swap، بر خلاف دستگاه‌های معمولی، به کل استخر تعلق دارند و نه به یک دستگاه مجازی. اگر یک vdev در استخر از کار بیفتد و یک دستگاه یدکی به استخر متصل و در دسترس باشد، به طور خودکار به vdev آسیب‌دیده می‌پیوندد.

پس از اتصال به vdev آسیب‌دیده، دستگاه یدکی شروع به دریافت کپی یا بازسازی داده‌هایی می‌کند که باید روی دستگاه گم شده باشد. در RAID سنتی به آن بازسازی می گویند، در حالی که در ZFS به آن resilvering می گویند.

توجه به این نکته ضروری است که دستگاه های یدکی به طور دائم جایگزین دستگاه های خراب نمی شوند. این تنها یک جایگزین موقت برای کاهش مدت زمان تخریب vdev است. پس از اینکه مدیر vdev ناموفق را جایگزین کرد، افزونگی به آن دستگاه دائمی بازیابی می‌شود و SPARE از vdev قطع می‌شود و به عنوان یک یدکی برای کل استخر به کار بازمی‌گردد.

مجموعه داده ها، بلوک ها و بخش ها

مجموعه بعدی از بلوک های سازنده برای درک در سفر ZFS ما کمتر در مورد سخت افزار است و بیشتر در مورد نحوه سازماندهی و ذخیره سازی خود داده ها است. ما در اینجا از چند سطح - مانند متاسلب - صرف نظر می کنیم تا ضمن حفظ درک ساختار کلی، جزئیات را به هم نریزیم.

مجموعه داده (مجموعه داده)

وقتی برای اولین بار یک مجموعه داده ایجاد می کنیم، تمام فضای موجود استخر را نشان می دهد. سپس سهمیه را تعیین می کنیم - و نقطه نصب را تغییر می دهیم. شعبده بازي!

Zvol در بیشتر موارد فقط یک مجموعه داده است که از لایه سیستم فایل آن جدا شده است، که ما در اینجا با یک فایل سیستم کاملا معمولی ext4 جایگزین می کنیم.

یک مجموعه داده ZFS تقریباً مشابه یک سیستم فایل نصب شده استاندارد است. مانند یک فایل سیستم معمولی، در نگاه اول مانند "فقط یک پوشه دیگر" به نظر می رسد. اما درست مانند فایل‌سیستم‌های قابل نصب معمولی، هر مجموعه داده ZFS مجموعه‌ای از ویژگی‌های اساسی خود را دارد.

اول از همه، یک مجموعه داده می تواند یک سهمیه اختصاص داده شده داشته باشد. اگر تنظیم شود zfs set quota=100G poolname/datasetname، پس نمی توانید در پوشه نصب شده بنویسید /poolname/datasetname بیش از 100 گیگابایت

به وجود - و عدم وجود - اسلش در ابتدای هر خط توجه کنید؟ هر مجموعه داده هم در سلسله مراتب ZFS و هم در سلسله مراتب mount سیستم جایگاه خاص خود را دارد. در سلسله مراتب ZFS اسلش پیشرو وجود ندارد - شما با نام استخر و سپس مسیر از یک مجموعه داده به مجموعه دیگر شروع می کنید. مثلا، pool/parent/child برای مجموعه داده ای به نام child زیر مجموعه داده والد parent در استخری با نامی خلاقانه pool.

به طور پیش فرض، نقطه اتصال مجموعه داده معادل نام آن در سلسله مراتب ZFS، با یک اسلش پیشرو خواهد بود - استخر با نام pool نصب شده به عنوان /pool، مجموعه داده ها parent نصب شده در /pool/parentو مجموعه داده فرزند child نصب شده در /pool/parent/child. با این حال، نقطه نصب سیستم مجموعه داده را می توان تغییر داد.

اگر مشخص کنیم zfs set mountpoint=/lol pool/parent/child، سپس مجموعه داده ها pool/parent/child نصب شده بر روی سیستم به عنوان /lol.

علاوه بر مجموعه داده ها باید به حجم ها (zvols) اشاره کرد. یک حجم تقریباً مشابه یک مجموعه داده است، با این تفاوت که در واقع یک سیستم فایل ندارد - فقط یک دستگاه بلوک است. برای مثال می توانید ایجاد کنید zvol با نام mypool/myzvol، سپس آن را با یک سیستم فایل ext4 فرمت کنید و سپس آن فایل سیستم را سوار کنید - اکنون یک سیستم فایل ext4 دارید، اما با تمام ویژگی های امنیتی ZFS! این ممکن است در یک دستگاه احمقانه به نظر برسد، اما هنگام صادرات یک دستگاه iSCSI به عنوان یک Backend بسیار منطقی تر است.

بلوک می کند

فایل با یک یا چند بلوک نشان داده می شود. هر بلوک در یک دستگاه مجازی ذخیره می شود. اندازه بلوک معمولاً برابر با پارامتر است اندازه رکورد، اما می تواند کاهش یابد 2^ شیفتاگر حاوی ابرداده یا یک فایل کوچک باشد.

ما واقعا واقعا در مورد جریمه عملکرد هنگفت اگر جابجایی خیلی کوچک تنظیم کنید شوخی نکنید

در یک استخر ZFS، تمام داده ها، از جمله ابرداده، در بلوک ها ذخیره می شوند. حداکثر اندازه بلوک برای هر مجموعه داده در ویژگی تعریف شده است recordsize (اندازه رکورد). اندازه رکورد را می توان تغییر داد، اما این اندازه یا مکان بلوک هایی که قبلاً در مجموعه داده نوشته شده اند را تغییر نمی دهد - این فقط بر بلوک های جدید همانطور که نوشته شده اند تأثیر می گذارد.

اندازه رکورد پیش‌فرض کنونی 128 کیلوبایت است، مگر اینکه خلاف آن مشخص شده باشد. این یک نوع معامله دشوار است که در آن عملکرد عالی نیست، اما در بیشتر موارد وحشتناک نیز نیست. Recordsize را می توان روی هر مقداری از 4K تا 1M تنظیم کرد (با تنظیمات پیشرفته recordsize می توانید حتی بیشتر نصب کنید، اما این به ندرت ایده خوبی است).

هر بلوکی فقط به داده های یک فایل اشاره دارد - شما نمی توانید دو فایل مختلف را در یک بلوک جمع کنید. هر فایل بسته به اندازه از یک یا چند بلوک تشکیل شده است. اگر اندازه فایل کوچکتر از اندازه رکورد باشد، در اندازه بلوک کوچکتر ذخیره می شود - برای مثال، یک بلوک با یک فایل 2 کیلوبایتی تنها یک بخش 4 کیلوبایتی روی دیسک را اشغال می کند.

اگر فایل به اندازه کافی بزرگ باشد و به چندین بلوک نیاز داشته باشد، تمام رکوردهای این فایل دارای اندازه خواهند بود recordsize - از جمله آخرین مدخل که قسمت اصلی آن ممکن است باشد فضای بلا استفاده.

zvols خاصیت ندارند recordsize - در عوض آنها دارای یک ویژگی معادل هستند volblocksize.

بخش ها

آخرین و اساسی ترین واحد ساختمانی بخش است. این کوچکترین واحد فیزیکی است که می توان در دستگاه زیرین نوشت یا از آن خواند. برای چندین دهه، اکثر دیسک ها از بخش های 512 بایتی استفاده می کردند. اخیراً اکثر دیسک ها روی سکتورهای 4 KiB تنظیم شده اند و برخی - به خصوص SSD ها - دارای سکتورهای 8 KiB یا حتی بیشتر هستند.

سیستم ZFS دارای ویژگی است که به شما امکان می دهد اندازه بخش را به صورت دستی تنظیم کنید. این ملک ashift. تا حدودی گیج کننده است، ashift قدرت دو است. مثلا، ashift=9 به معنای اندازه بخش 2^9 یا 512 بایت است.

ZFS سیستم عامل را برای اطلاعات دقیق در مورد هر دستگاه بلوکی هنگامی که به یک vdev جدید اضافه می‌شود، جستجو می‌کند و از نظر تئوری، ashift را به‌طور صحیح بر اساس آن اطلاعات نصب می‌کند. متأسفانه، بسیاری از درایوها به منظور حفظ سازگاری با ویندوز XP (که قادر به درک درایوها با اندازه های دیگر بخش نبود) در مورد اندازه بخش خود دروغ می گویند.

این بدان معنی است که به یک مدیر ZFS توصیه می شود که اندازه واقعی بخش دستگاه های خود را بداند و به صورت دستی تنظیم کند. ashift. اگر جابجایی خیلی کم تنظیم شود، تعداد عملیات خواندن / نوشتن به طور نجومی افزایش می یابد. بنابراین، نوشتن بخش‌های 512 بایتی در یک بخش واقعی 4 کیلوبایتی به این معنی است که باید اولین بخش را بنویسید، سپس بخش 4 کیلوبایتی را بخوانید، آن را با یک بخش 512 بایتی دوم تغییر دهید، آن را به بخش جدید بازگردانید. 4 KiB بخش، و غیره برای هر ورودی.

در دنیای واقعی، چنین جریمه ای به SSD های سامسونگ EVO می رسد که برای آن ashift=13، اما این SSD ها در مورد اندازه بخش خود دروغ می گویند، و بنابراین پیش فرض روی تنظیم شده است ashift=9. اگر یک مدیر سیستم با تجربه این تنظیمات را تغییر ندهد، این SSD کار می کند آرام تر هارد مغناطیسی معمولی

برای مقایسه، برای اندازه بیش از حد بزرگ ashift عملا هیچ جریمه ای وجود ندارد. هیچ جریمه عملکرد واقعی وجود ندارد و افزایش فضای استفاده نشده بینهایت کوچک است (یا با فعال کردن فشرده سازی صفر). بنابراین، ما قویاً توصیه می کنیم حتی درایوهایی که از بخش های 512 بایتی استفاده می کنند نصب کنند ashift=12 یا حتی ashift=13با اعتماد به نفس با آینده روبرو شوید

ویژگی ashift برای هر دستگاه مجازی vdev تنظیم شده است و نه برای استخر، همانطور که بسیاری به اشتباه فکر می کنند - و پس از نصب تغییر نمی کند. اگر تصادفاً ضربه زدید ashift هنگامی که یک vdev جدید به یک استخر اضافه می کنید، به طور جبران ناپذیری آن استخر را با دستگاهی با کارایی پایین آلوده کرده اید و معمولاً چاره ای جز تخریب استخر و شروع مجدد وجود ندارد. حتی حذف vdev شما را از پیکربندی خراب نجات نخواهد داد ashift!

مکانیزم کپی روی نوشتن

اگر یک فایل سیستم معمولی نیاز به بازنویسی داده ها داشته باشد، هر بلوک را در جایی که قرار دارد تغییر می دهد

یک سیستم فایل کپی روی نوشتن یک نسخه بلوک جدید می نویسد و سپس نسخه قدیمی را باز می کند

به طور انتزاعی، اگر مکان فیزیکی واقعی بلوک ها را نادیده بگیریم، "دنباله دار داده" ما به یک "کرم داده" ساده شده است که از چپ به راست در نقشه فضای موجود حرکت می کند.

اکنون می‌توانیم ایده خوبی از نحوه عملکرد عکس‌های فوری کپی در نوشتن داشته باشیم - هر بلوک می‌تواند متعلق به چند عکس فوری باشد و تا زمانی که همه عکس‌های فوری مرتبط از بین بروند، باقی خواهند ماند.

مکانیسم Copy on Write (CoW) اساس اساسی چیزی است که ZFS را به چنین سیستم شگفت انگیزی تبدیل می کند. مفهوم اصلی ساده است - اگر از یک سیستم فایل سنتی بخواهید یک فایل را تغییر دهد، دقیقاً همان کاری را که شما خواسته اید انجام می دهد. اگر از یک سیستم فایل کپی روی نوشتن بخواهید همین کار را انجام دهد، می گوید "ok" اما به شما دروغ می گوید.

درعوض، یک سیستم فایل کپی بر روی نوشتن، نسخه جدیدی از بلوک اصلاح شده را می نویسد و سپس ابرداده فایل را به روز می کند تا بلوک قدیمی را جدا کرده و بلوک جدیدی را که به تازگی نوشتید به آن مرتبط کند.

جدا کردن بلوک قدیمی و پیوند دادن بلوک جدید در یک عملیات انجام می شود، بنابراین نمی توان آن را قطع کرد - اگر بعد از این اتفاق خاموش شوید، نسخه جدیدی از فایل دارید و اگر زودتر خاموش کنید، نسخه قدیمی را دارید. . در هر صورت هیچ درگیری در فایل سیستم وجود نخواهد داشت.

کپی روی نوشتن در ZFS نه تنها در سطح سیستم فایل، بلکه در سطح مدیریت دیسک نیز رخ می دهد. این بدان معنی است که ZFS تحت تأثیر فضای سفید قرار نمی گیرد (یک سوراخ در RAID) - پدیده ای است که در آن نوار قبل از از کار افتادن سیستم فقط تا حدی ضبط می کند، با آسیب آرایه پس از راه اندازی مجدد. در اینجا نوار به صورت اتمی نوشته می شود، vdev همیشه ترتیبی است و باب عموی توست.

ZIL: گزارش قصد ZFS

سیستم ZFS نوشته های همزمان را به روشی خاص درمان می کند - به طور موقت اما بلافاصله آنها را در ZIL ذخیره می کند قبل از اینکه بعداً به طور دائم آنها را همراه با نوشتن ناهمزمان بنویسد.

به طور معمول، داده های نوشته شده در یک ZIL هرگز دوباره خوانده نمی شوند. اما بعد از خرابی سیستم ممکن است

SLOG یا دستگاه LOG ثانویه، فقط یک vdev ویژه - و ترجیحاً بسیار سریع است، که در آن ZIL را می توان جدا از حافظه اصلی ذخیره کرد.

پس از خرابی، همه داده‌های کثیف در ZIL دوباره پخش می‌شوند - در این مورد، ZIL روی SLOG است، بنابراین از آنجا دوباره پخش می‌شود.

دو دسته اصلی از عملیات نوشتن وجود دارد - همزمان (همگام) و ناهمزمان (ناهمگام). برای اکثر بارهای کاری، اکثریت قریب به اتفاق نوشته‌ها ناهمزمان هستند - سیستم فایل اجازه می‌دهد آنها را جمع‌آوری و به صورت دسته‌ای منتشر کند، که باعث کاهش تکه تکه شدن و افزایش توان عملیاتی می‌شود.

ضبط های همگام موضوع کاملاً متفاوتی هستند. هنگامی که یک برنامه درخواست نوشتن همزمان می‌کند، به سیستم فایل می‌گوید: "شما باید این را به حافظه غیر فرار اختصاص دهید. همین الانتا آن زمان، هیچ کار دیگری نمی توانم انجام دهم." بنابراین، نوشتن همزمان باید فوراً به دیسک متعهد شود - و اگر این باعث افزایش تکه تکه شدن یا کاهش توان عملیاتی شود، همینطور باشد.

ZFS نوشته‌های همزمان را متفاوت از سیستم‌های فایل معمولی مدیریت می‌کند - به جای اینکه فوراً آنها را به ذخیره‌سازی معمولی متعهد کند، ZFS آنها را به یک منطقه ذخیره‌سازی ویژه به نام ZFS Intent Log یا ZIL متعهد می‌کند. ترفند این است که این رکوردها همچنین در حافظه باقی می ماند و همراه با درخواست های نوشتن ناهمزمان معمولی تجمیع می شود تا بعداً به عنوان TXG های کاملاً عادی (گروه های تراکنش) به فضای ذخیره سازی منتقل شوند.

در عملکرد عادی، ZIL روی آن نوشته می شود و دیگر هرگز خوانده نمی شود. هنگامی که پس از چند لحظه، رکوردهای ZIL به ذخیره سازی اصلی در TXG های معمولی از RAM متعهد می شوند، از ZIL جدا می شوند. تنها زمانی که چیزی از ZIL خوانده می شود، زمانی است که استخر وارد می شود.

اگر ZFS از کار بیفتد - خرابی سیستم عامل یا قطع برق - در حالی که داده‌ها در ZIL وجود دارد، این داده‌ها در هنگام وارد کردن استخر بعدی خوانده می‌شوند (مثلاً وقتی سیستم اضطراری راه‌اندازی مجدد می‌شود). هر چیزی در ZIL خوانده می‌شود، به TXG گروه‌بندی می‌شود، به ذخیره‌سازی اصلی متعهد می‌شود، و سپس در طی فرآیند واردات از ZIL جدا می‌شود.

یکی از کلاس های کمکی vdev LOG یا SLOG نام دارد که دستگاه ثانویه LOG است. این یک هدف دارد - به جای ذخیره کردن ZIL در فروشگاه اصلی vdev، یک استخر با یک vdev جداگانه و ترجیحاً بسیار سریعتر و بسیار مقاوم در برابر نوشتن برای ذخیره ZIL فراهم کند. خود ZIL بدون توجه به جایی که ذخیره می شود یکسان عمل می کند، اما اگر LOG vdev عملکرد نوشتن بسیار بالایی داشته باشد، نوشتن همزمان سریعتر خواهد بود.

افزودن vdev با LOG به استخر کار نمی کند نمیتونم عملکرد نوشتن ناهمزمان را بهبود بخشید - حتی اگر همه نوشته‌ها را با ZIL مجبور کنید zfs set sync=always، آنها همچنان به همان روش و با همان سرعتی که بدون گزارش به حافظه اصلی در TXG متصل می شوند. تنها بهبود مستقیم عملکرد، تأخیر نوشتن همزمان است (زیرا گزارش سریع‌تر عملیات را سرعت می‌بخشد). sync).

با این حال، در محیطی که قبلاً نیاز به نوشتن همزمان زیادی دارد، vdev LOG می تواند به طور غیرمستقیم سرعت نوشتن ناهمزمان و خواندن غیر کش را افزایش دهد. بارگذاری ورودی های ZIL در یک vdev LOG جداگانه به معنای اختلاف کمتری برای IOPS در حافظه اصلی است که عملکرد همه خواندن و نوشتن را تا حدی بهبود می بخشد.

عکس های فوری

مکانیسم کپی روی نوشتن همچنین پایه‌ای ضروری برای عکس‌های فوری اتمی ZFS و تکثیر ناهمزمان افزایشی است. سیستم فایل فعال دارای یک درخت اشاره گر است که تمام رکوردها را با داده های فعلی علامت گذاری می کند - وقتی یک عکس فوری می گیرید، به سادگی از این درخت اشاره گر کپی می کنید.

هنگامی که یک رکورد روی سیستم فایل فعال بازنویسی می شود، ZFS ابتدا نسخه بلوک جدید را در فضای بلااستفاده می نویسد. سپس نسخه قدیمی بلوک را از سیستم فایل فعلی جدا می کند. اما اگر برخی از عکس‌های فوری به بلوک قدیمی اشاره داشته باشد، همچنان بدون تغییر باقی می‌ماند. بلوک قدیمی در واقع به عنوان فضای آزاد بازیابی نمی شود تا زمانی که تمام عکس های فوری که به این بلوک ارجاع می دهند نابود شوند!

همانند سازی

کتابخانه استیم من در سال 2015 158 گیگابایت و شامل 126 فایل بود. این تقریباً به وضعیت بهینه برای rsync نزدیک است - تکثیر ZFS در شبکه "فقط" 927٪ سریعتر بود.

در همان شبکه، تکثیر یک فایل تصویری ماشین مجازی ویندوز 40 با ظرفیت 7 گیگابایت داستان کاملاً متفاوتی است. تکثیر ZFS 289 برابر سریعتر از rsync است - یا اگر به اندازه کافی باهوش هستید که rsync را با --inplace فراخوانی کنید "فقط" 161 برابر سریعتر است.

هنگامی که یک تصویر VM مقیاس بندی می شود، مسائل rsync با آن مقیاس می شوند. 1,9 TiB برای یک تصویر VM مدرن آنقدر بزرگ نیست - اما به اندازه کافی بزرگ است که تکرار ZFS 1148 برابر سریعتر از rsync باشد، حتی با آرگومان --inplace rsync.

هنگامی که نحوه عملکرد عکس های فوری را درک کردید، درک ماهیت تکرار آسان خواهد بود. از آنجایی که یک عکس فوری فقط درختی از اشاره گرها به رکوردها است، نتیجه آن این است که اگر این کار را انجام دهیم zfs send snapshot، سپس هم این درخت و هم تمام رکوردهای مرتبط با آن را ارسال می کنیم. وقتی این را می فرستیم zfs send в zfs receive روی هدف، هم محتویات واقعی بلوک و هم درخت اشاره گرهایی را می نویسد که به بلوک های مجموعه داده هدف اشاره می کنند.

چیزها در مورد دوم جالب تر می شوند zfs send. ما اکنون دو سیستم داریم که هر کدام شامل poolname/datasetname@1، و یک عکس فوری جدید می گیرید poolname/datasetname@2. بنابراین، در استخر اصلی شما datasetname@1 и datasetname@2، و در استخر هدف تا کنون فقط اولین عکس فوری است datasetname@1.

از آنجایی که ما یک عکس فوری مشترک بین منبع و هدف داریم datasetname@1، ما می توانیم آن را انجام دهیم افزایشی zfs send بیش از آن وقتی به سیستم می گوییم zfs send -i poolname/datasetname@1 poolname/datasetname@2، دو درخت اشاره گر را با هم مقایسه می کند. هر اشاره گر که فقط در آن وجود دارد @2، بدیهی است که به بلوک های جدید مراجعه کنید - بنابراین ما به محتویات این بلوک ها نیاز داریم.

در یک سیستم از راه دور، پردازش یک افزایشی send به همین سادگی ابتدا همه ورودی های جدید موجود در جریان را می نویسیم sendو سپس به آن بلوک ها اشاره گر اضافه کنید. Voila، ما داریم @2 در سیستم جدید!

تکثیر افزاینده ناهمزمان ZFS نسبت به روش های قبلی غیر مبتنی بر عکس فوری مانند rsync پیشرفت بسیار زیادی دارد. در هر دو مورد، فقط داده های تغییر یافته منتقل می شود - اما ابتدا باید rsync شود خواندن از دیسک تمام داده ها در هر دو طرف برای بررسی مجموع و مقایسه آن. در مقابل، تکرار ZFS چیزی جز درخت های اشاره گر - و هر بلوکی که در عکس فوری مشترک وجود ندارد را نمی خواند.

فشرده سازی داخلی

مکانیسم کپی در نوشتن همچنین سیستم فشرده سازی درون خطی را ساده می کند. در یک سیستم فایل سنتی، فشرده سازی مشکل است - هم نسخه قدیمی و هم نسخه جدید داده های اصلاح شده در یک فضا قرار دارند.

اگر یک قطعه داده در وسط یک فایل که زندگی را به صورت یک مگابایت صفر از 0x00000000 و غیره شروع می کند در نظر بگیریم، فشرده کردن آن به یک سکتور روی دیسک بسیار آسان است. اما اگر آن مگابایت صفر را با یک مگابایت داده تراکم ناپذیر مانند JPEG یا نویز شبه تصادفی جایگزین کنیم، چه اتفاقی می افتد؟ به طور غیرمنتظره، این مگابایت داده نه یک، بلکه به 256 بخش 4 کیلوبایتی نیاز دارد و در این مکان روی دیسک فقط یک بخش رزرو شده است.

ZFS این مشکل را ندارد، زیرا رکوردهای اصلاح شده همیشه در فضای بلااستفاده نوشته می شوند - بلوک اصلی فقط یک بخش 4 کیلوبایتی را اشغال می کند و رکورد جدید 256 را اشغال می کند، اما این یک مشکل نیست - یک قطعه اخیراً اصلاح شده از " وسط" فایل بدون توجه به اینکه اندازه آن تغییر کرده یا نه در فضای بلااستفاده نوشته می شود، بنابراین برای ZFS این یک وضعیت کاملاً منظم است.

فشرده‌سازی Native ZFS به‌طور پیش‌فرض غیرفعال است و سیستم الگوریتم‌های قابل اتصال را ارائه می‌کند - در حال حاضر LZ4، gzip (1-9)، LZJB، و ZLE.

• LZ4 یک الگوریتم استریم است که فشرده سازی و فشرده سازی بسیار سریع و مزایای عملکرد را برای اکثر موارد استفاده - حتی در CPU های نسبتاً کند ارائه می دهد.
• GZIP یک الگوریتم قابل احترام است که همه کاربران یونیکس آن را می شناسند و دوست دارند. این الگوریتم را می توان با سطوح فشرده سازی 1-9 پیاده سازی کرد، با افزایش نسبت فشرده سازی و استفاده از CPU با نزدیک شدن به سطح 9. الگوریتم برای همه موارد استفاده از متن (یا سایر موارد بسیار فشرده) مناسب است، اما در غیر این صورت اغلب باعث مشکلات CPU می شود - از آن استفاده کنید. با دقت، به خصوص در سطوح بالاتر.
• LZJB الگوریتم اصلی در ZFS است. منسوخ شده است و دیگر نباید استفاده شود، LZ4 از هر نظر از آن پیشی می گیرد.
• ZLE - رمزگذاری سطح صفر، رمزگذاری سطح صفر. به هیچ وجه داده های عادی را لمس نمی کند، اما توالی های بزرگی از صفر را فشرده می کند. برای مجموعه داده‌های کاملاً غیرقابل تراکم (مانند JPEG، MP4 یا سایر فرمت‌های قبلاً فشرده‌شده) مفید است، زیرا داده‌های تراکم‌ناپذیر را نادیده می‌گیرد اما فضای بلااستفاده را در رکوردهای حاصل فشرده می‌کند.

ما فشرده سازی LZ4 را برای تقریباً همه موارد استفاده توصیه می کنیم. جریمه عملکرد هنگام مواجهه با داده های تراکم ناپذیر بسیار کوچک است و رشد عملکرد برای داده های معمولی قابل توجه است. کپی کردن تصویر ماشین مجازی برای نصب جدید سیستم عامل ویندوز (سیستم عامل تازه نصب شده، هنوز هیچ داده ای در داخل آن وجود ندارد) با compression=lz4 27 درصد سریعتر از با compression=noneبه این آزمون در سال 2015.

ARC - حافظه پنهان جایگزین تطبیقی

ZFS تنها سیستم فایل مدرنی است که ما می شناسیم که از مکانیزم ذخیره کش خواندن مخصوص به خود استفاده می کند، به جای تکیه بر حافظه پنهان صفحه سیستم عامل برای ذخیره کپی های بلوک های اخیرا خوانده شده در RAM.

اگرچه حافظه نهان داخلی بدون مشکل نیست - ZFS نمی تواند به درخواست های تخصیص حافظه جدید به سرعت هسته پاسخ دهد، بنابراین چالش جدید malloc() در صورت نیاز به رمی که در حال حاضر توسط ARC اشغال شده است، تخصیص حافظه ممکن است با شکست مواجه شود. اما دلایل خوبی برای استفاده از حافظه پنهان خود، حداقل در حال حاضر وجود دارد.

تمام سیستم عامل های مدرن شناخته شده، از جمله MacOS، Windows، Linux و BSD، از الگوریتم LRU (کمترین استفاده اخیر) برای پیاده سازی کش صفحه استفاده می کنند. این یک الگوریتم ابتدایی است که بلوک کش شده را پس از هر بار خواندن به "بالا صف" فشار می دهد، و بلوک ها را در صورت نیاز به "پایین صف" فشار می دهد تا موارد جدید از دست رفته را اضافه کند (بلوک هایی که باید از دیسک خوانده می شدند، نه از حافظه پنهان) بالا

الگوریتم معمولاً خوب کار می‌کند، اما در سیستم‌هایی با مجموعه داده‌های کار بزرگ، LRU به راحتی منجر به thrashing می‌شود - بلوک‌های اغلب مورد نیاز را خارج می‌کند تا جایی برای بلوک‌هایی ایجاد شود که دیگر هرگز از حافظه پنهان خوانده نشوند.

ARC الگوریتم ساده‌تری است که می‌توان آن را به عنوان یک کش "وزن دار" در نظر گرفت. هر بار که یک بلوک ذخیره شده در حافظه پنهان خوانده می شود، کمی "سنگین" و سخت تر می شود - و حتی پس از بیرون انداختن یک بلوک ردیابی شد در یک بازه زمانی مشخص بلوکی که خارج شده است اما باید دوباره در حافظه پنهان خوانده شود نیز «سنگین‌تر» می‌شود.

نتیجه نهایی همه اینها یک حافظه نهان با نسبت ضربه بسیار بالاتر است، نسبت بین بازدیدهای حافظه پنهان (خوانش های انجام شده از حافظه پنهان) و عدم دسترسی به حافظه پنهان (خواندن از دیسک). این یک آمار بسیار مهم است - نه تنها خود بازدیدهای حافظه پنهان مرتباً سریعتر ارائه می شوند، از دست دادن حافظه پنهان نیز می توانند سریعتر ارائه شوند، زیرا هرچه تعداد بازدیدهای حافظه پنهان بیشتر باشد، درخواست های همزمان دیسک کمتر می شود و تأخیر برای آن دسته از خطاهای باقیمانده که باید باید کمتر شود. با دیسک سرو شود

نتیجه

پس از یادگیری مفاهیم اولیه ZFS - نحوه عملکرد کپی در نوشتن، و همچنین روابط بین استخرهای ذخیره سازی، دستگاه های مجازی، بلوک ها، بخش ها و فایل ها - ما آماده هستیم تا عملکرد دنیای واقعی را با اعداد واقعی مورد بحث قرار دهیم.

در قسمت بعدی، نگاهی به عملکرد واقعی استخرها با vdevs آینه‌ای و RAIDz در مقابل یکدیگر خواهیم داشت و همچنین در مقابل توپولوژی‌های RAID هسته لینوکس سنتی که بررسی کرده‌ایم. زودتر.

در ابتدا، ما می خواستیم فقط اصول اولیه را پوشش دهیم - خود توپولوژی های ZFS - اما بعد از آن چنین بیایید آماده شویم تا در مورد راه اندازی و تنظیم پیشرفته تر ZFS، از جمله استفاده از انواع کمکی vdev مانند L2ARC، SLOG و Special Allocation صحبت کنیم.

منبع: www.habr.com