ژورنالینگ ( Journaling ) چیست؟ بررسی مفهوم Journaling فایل سیستم
منظور از Journaling در فایل سیستم چیست؟ Journal در Database چیست؟ Journal چه خصوصیاتی دارد؟ چه تفاوتی بین Journaling در Database و Journaling در File System وجود دارد؟ در این مقاله به تحلیل و بررسی Journaling در مفاهیم فایل سیستم و بحث دیتا خواهیم پرداخت و ویژگی های آن را بررسی و تحلیل خواهیم کرد. همچنین پیشتر در این مطلب https://tosinso.com/bC4 در وبسایت توسینسو راجع به این موضوع صحبت شده است و از این جهت در این مطلب به بررسی عمیق تر این موضوع خواهیم پرداخت.
دوره های شبکه، برنامه نویسی، مجازی سازی، امنیت، نفوذ و ... با برترین های ایران
سرفصل های این مطلب
اگر با SQL و مباحث Database آشنایی دارید و یا اگر با فایل سیستم های XFS ، ZFS و یا ext3,4 کار کرده اید تا به حال با اصطلاح Journal برخورد داشته اید. هدف اصلی Journal چه در Database و چه در File System این است که در هنگام Disaster از خراب شدن ساختار داده و خود داده جلوگیری کند و این نقطه مشترک مفهوم Journaling در Database و File System است. اما در این مقاله ابتدا به بررسی این مفهوم در فایل سیستم پرداخته و سپس آن را در دیتابیس نیز بررسی می کنیم.
بررسی مفهوم File System Journaling
یک Journaling Filesystem در حقیقت فایل سیستمی است که؛ ورودی هایی که هنوز به شکل کامل در قسمت اصلی دیسک ذخیره نشده اند را زیر نظر می گیرد، از Data Structure آنها برای خودش Metadata و Log بر می دارد و در محلی به عنوان Journal ذخیره می کند تا جلوی corrupt شدن اطلاعات موجود در فایل سیستم را بگیرد. به عبارت دیگر یک Journaling Filesystem پیش از ذخیره کردن اصل تغییرات به صورت Random، یک Log Record به صورت Sequential می نویسد که این Log Record به شکلی کامل اصل تغییرات را تشریح می کند.
قابلیت Journaling همانند fsck نیست ، بلکه به نوعی جایگزین آن شده است؛ در فایل سیستم هایی که قابلیت Journaling را ندارند (به عنوان مثال) به هنگام Power Loss زمانی که مجدد اقدام به boot سیستم عامل خود می کنید باید Check Utility بر روی File System اجرا شود که فرآیندی زمانبر است و ممکن است بی نتیجه باشد. اما زمانی که قابلیت Journaling در فایل سیستم موجود باشد سیستم ابتدا اقدام به خواندن Metadata موجود در Filesystem کرده و از طریق Log هایی که درون قسمت Journaling ذخیره شده در زمان کوتاهی اقدام به تعمیر ساختار دیتای موجود در فایل سیستم کرده و کمک می کند تا دیتا به وضعیت پایدار خود باز گردد. همچنین باید در نظر داشت که Journaling به معنای Redundancy نیست. در واقع Journaling باعث می شود که یک فایل سیستم Recover-able باشد. Journal در فایل سیستم یک بخش جداگانه ولی مرتبط با بخش اصلی دیسک است که عملیات نوشتن بر روی دیسک را کارآمدتر می کند. همچنین Journaling باعث می شوند که I/O های Random پیش از نوشته شدن روی دیسک به Sequential تبدیل شوند.
اما هم اکنون به چالش ها و نیاز هایی که پیش از Journaling در دنیای File System وجود داشته و مطرح بوده نگاهی کوتاه کنیم؛ موارد و انتظاراتی که به مرور زمان از File System ها می رفته مثل نیاز به داشتن پارتیشن هایی با اندازه بزرگ روی سرور، لزوم ریکاوری سریع پس از Crash یا Power Loss ، افزایش I/O و ... که همه ی این نیازها لزوم ایجاد تکنیک های جدیدی را می طلبید که بتواند این دغدغه ها را پوشش دهد.
در همین زمان فایل سیستم هایی از قبیل XFS و ext3 با مطرح کردن ویژگی هایی مثل Journaling سعی در برطرف کردن این چالش ها کردند. چرا که Journal در واقع یک Log mode در فایل سیستم است که دیتا به هنگام ذخیره سازی ابتدا بر روی آن قرار می گیرد و سپس در محل اصلی خود ذخیره می شود تا از بروز Delay به هنگام Write جلوگیری کند. برای مثال زمانی که یک دیسک با فایل سیستم XFS فرمت بشود به دو Partition با نام های data و همچنین journal تقسیم می شود. در نظر داشته باشید که Journaling File System بعد از اینکه دیتا وارد فایل سیستم می شود عملیات Journaling را زمانی انجام می دهد که بخواهد دیتا را بر روی دیسک ها بنویسد. Journal در لبه ی دیسک قرار دارد و وجود این مکانیسم باعث افزایش Performance در مواردی از قبیل random write می شود.
مفهوم Journaling در Ceph
اما نرم افزار های ذخیره سازی ای نیز هستند که از قابلیت Journaling استفاده می کند و Journaling در سطح نرم افزار ذخیره سازی با Journaling File System نباید اشتباه گرفته شود. یکی از این نرم افزار های Ceph است. نرم افزار Ceph به عنوان یک Software Defined Storage ای که Open Source است به صورت یک مجموعه راهکار قابلیت های فراوانی دارد که یکی از آنها Journaling است. بین Ceph journaling و مفهوم filesystem journaling تفاوت بسیاری وجود دارد. کلاستر Ceph پیش از اینکه دیتا را بخواهد به فایل سیستم بدهد عملیات Journaling را قبل از دادن دیتا به فایل سیستم انجام می دهد ولی Journaling File System گام بعدی و یک لایه پایین تر است و زمانی که دیتا را می خواهد بر روی دیسک فیزیکی بنویسد عملیات Journaling در فایل سیستم انجام می شود.
از این رو در کلاستر Ceph از Journaling File System استفاده نمی شود چرا که باعث می شود یک دیتا دوبار نوشته شود و Overhead ایجاد می کند. دقت کنید که اینجا Ceph یک فایل سیستم نیست بلکه یک SDS و یک نرم افزار ذخیره سازی است که بدون هیچ ارتباطی با فایل سیستم از قابلیت و مفهوم Journaling استفاده می کند. زمانی که در Ceph از Journaling استفاده می کنیم می توان Journal Part را بر روی یک دیسک مجزا قرار داد. یعنی اگر یک هارد دیسک HDD داریم می توانیم تعریف کنیم که Journal این هارد بر روی یک دیسک SSD مجزا قرار بگیرد. همچنین می توان Journal های چند دیسک اصلی را بر روی یک SSD واحد قرار داد یعنی یک SSD را به چند پارتیشن تقسیم کرده و درون هر پارتیشن مجزای آن Journal File مخصوص دیسک دیگری را جای داد. در این مورد نسبت 1 به 4 توصیه می شود یعنی به ازای 4 عدد دیسک HDD می تواند یک SSD را مدنظر گرفت و Journal های آن چهار عدد HDD را روی آن ذخیره کرد. این موضوع باعث افزایش Throughput شده، میزان CPU Wait یا access time را کاهش داده و در عین حال باعث کاهش write Latency هم می شود. همچنین این موضوع می تواند منجر به کاهش هزینه کلاستر ذخیره سازی نیز بشود چرا که به جای اینکه تمام دیسک های ذخیره سازی را از جنس SSD تهیه کنیم می توانیم در تنها از چند دیسک SSD استفاده کنیم و سایر دیسک ها همان HDD باقی بماند. اما یکی از معایبش آن است که اگر دیسک مجزای Journal ازبین برود ممکن است تمام دیتاهای موجود بر روی دیسک های اصلی نیز دچار آسیب می شوند. به همین دلیل در مواقعی که Journal را در دیسک مجزا قرار می دهند برای آن دیسک مجزا یک RAID 1 نیز در نظر میگیرند. همچنین در کلاستر Ceph اگر دیسک های اصلی خودشان SSD باشند با همین تناسب می توان به ازای 18 عدد SSD یک عدد NVMe در نظر گرفت و Journal های 18 عدد SSD را بر روی یک NVMe ذخیره کرد. از این رو به طور معمول در کلاستر های Ceph که در سطح نرم افزار ذخیره سازی Journaling فعال است؛ دیگر در لایه فایل سیستم از فایل سیستمی استفاده می کنند که Journaling در آن به صورت پیشفرض فعال نباشد و یا بتوان Journaling File System را غیرفعال کرد چرا که منجر به دوباره کاری و ایجاد بار اضافه می شود.
اما باید در نظر داشت که Journaling با Caching در Storage متفاوت است چرا که در Caching با هدف افزایش سرعت اصل دیتا در Caching Tier ذخیره می شود ولی در Journaling با هدف حفاظت از اصل دیتا یک سری Log و Metadata ذخیره می شود که می توان از آن به دیتای اصلی رسید. همچنین Journaling به معنای intent log نیست بلکه خود یک نوعی از intent log هست و برخی قابلیت های آن بسته به فایل سیستمی که Journaling را ارایه می کند تفاوت دارد.
بررسی مفهوم Database Journaling
اما بعد از بیان تفاوت Ceph Journaling با مفهوم filesystem journaling هم اکنون به بیان تفاوتی دیگر می پردازیم؛ باید در نظر داشت که Journaling در فایل سیستم با Journaling در Database هم تفاوت دارد و یکی بودن اصطلاح آنها و همچنین شباهت سازوکارشان نباید باعث جابجا در نظر گرفتن آنها شود.
فایل سیستمی که قابلیت Journaling دارد باعث می شود که دیتای ذخیره شده در دیسک بعد از یک آسیب بتواند زودتر به ثبات و پایداری برسد اما این موضوع تنها در سطح دیسک است و یک Journal File System نمی تواند آسیب هایی که به ساختار اپلیکیشن وارد شده را برطرف کند. به عبارت دیگر بعد از تعمیراتی که توسط Journal در دیسک انجام می شود باز هم از دید اپلیکیشن خطا هایی در درون Database دیده می شود و باز هم فایل دیتابیس corrupt است.
منظور از Journaling در Database شبیه DB Transaction Log است و با آنچه که در فایل سیستم هست تفاوت هایی دارد. DB Journaling باعث می شود که اگر در هنگام اعمال تغییر و یا ذخیره داده ای در دیتابیس خللی ایجاد شود (برق سیستم قطع بشود و یا اپلیکیشن کرش کند) داده ای که تا نصفه ذخیره شده از بین نرود و ساختار پایگاه داده به هم نریزد. یعنی DB Journaling لزوم نوشته شدن کامل داده در دیتابیس را از بین می برد و (ضمن ایجاد بازدهی و Performance بیشتر) تضمین می کند که تمام داده ها و تغییرات را تحت نظر داشته و بعد از یک Disaster می تواند به ریکاوری یک دیتابیس از بین رفته کمک کند.
به عبارت دیگر به جای این که تراکنش ها و Update ها (به صورت Random ) از همان ابتدا مستقیم درون دیتابیس ذخیره شوند، DB Journaling باعث می شود از داده Log هایی درون Journal File (به صورت Sequential ) جای داده شوند تا امکان rollback بعد از یک Disaster وجود داشته باشد. در واقع Database Journal File نقطه مقابل همان Database Core Data File است، و باعث می شود تا یک transaction log ابتدا در Journal ذخیره شده و سپس سر فرصت دیتا به Core Data File ها یا محل اصلی شان منتقل می شوند.
اما در متن فوق اشاره کردیم که Database Journaling باعث افزایش Performance نیزمی شود، ولی چگونه؟ تصور کنید زمانی را که یک Database قابلیت Journaling را نداشت در آن زمان اگر تراکنشی می بایست بر روی دیتابیس انجام می شد باید تغییرات در نهایت به صورت کامل درون Database ذخیره می شد و ذخیره در Database از جنس Random است به صورت Random Write انجام می شود و باعث ایجاد بار سنگینی بر روی دیسک می شود. ولی زمانی که Journaling فعال باشد Transaction Log هایی از تراکنش ها و تغییرات دیتابیس به صورت Sequential Write و به شکل موقت درون Journal File ذخیره می شود و از آنجایی که Sequential بار سبک تری نسبت به Random دارد در لحظه لود کلی و میزان تاخیر کاهش یافته و بازدهی (سرویسی که از آن دیتابیس استفاده می کند) افزایش می یابد.