PolarFS یک فایل‌سیستم توزیع‌شدهٔ بسیار کم‌تأخیر و مقاوم به شکست با دسترسی‌پذیری بالا است که برای پایگاه‌دادهٔ POLARDB طراحی شده است. این پایگاه‌داده هم‌اکنون در ابر Alibaba در دسترس است. PolarFS یک پشتهٔ شبکهٔ سبک و پشتهٔ ورودی-خروجی فضای کاربر را مورد استفاده قرار می‌دهد تا بتواند از تکنولوژی‌های در حال ظهوری مانند RDMA، NVMe و SPDK نهایت استفاده را ببرد. به این شکل، تأخیر ابتدا تا انتها به طور چشمگیری کاهش می‌یابد. اندازه‌گیری‌ها نشان می‌دهد تأخیر نوشتن PolarFS بسیار به فایل‌سیستم‌های محلی روی SSD نزدیک است.
برای سازگار نگه داشتن نسخه‌بدل‌ها در عین به حداکثر رساندن گذردهی ورودی-خروجی PolarFS، الگوریتم ParallelRaft به عنوان یک پروتکل اجماع مبتنی بر Raft توسعه داده شده است. الگوریتم مذکور سلسله‌وار کردن سخت‌گیرانهٔ Raft را با بهره‌گیری از قابلیت پایگاه‌داده‌ها در پذیرش انجام بدون‌ترتیب ورودی-خروجی می‌شکند. این الگوریتم قابل‌فهم بودن و سادگی پیاده‌سازی را از Raft به ارث می‌برد و در عین حال مقیاس‌پذیری ورودی-خروجی بسیار بهتری را برای PolarFS تأمین می‌کند.
همچنین، معماری انبارهٔ مشترک PolarFS که به‌خوبی از POLARDB پشتیانی می‌کند توضیح داده شده است.
مقالهٔ «PolarFS: یک فایل‌سیستم توزیع‌شدهٔ بسیار کم‌تأخیر و مقاوم به شکست برای پایگاه‌داده‌های انباره‌مشترک» با نام اصلی «PolarFS: An Ultra-low Latency and Failure Resilient Distributed File System for Shared Storage Cloud Database» [3] را Wei Cao، Zhenjun Liu، Peng Wang، Sen Chen، Caifeng Zhu، Song Zheng، Yuhui Wang و Guoqing Ma از Alibaba در VLDB ۲۰۱۸ ارائه کرده‌اند. در نوشتار حاضر ترجمه‌ای آزاد از این مقاله ارائه شده است.
جز در بخش بررسی و نقد مقاله و مواردی که صراحتاً به منبع دیگری اشاره شده است، متون و تصاویر گزارش حاضر از منبع [3] برگرفته شده‌اند.
مقالهٔ مورد بررسی [3] به ارائهٔ راه‌حلی جایگزین برای حل مشکل کندی فایل‌سیستم‌های توزیع‌شده می‌پردازد، تا بتوان پایگاه‌داده‌ای توزیع‌شده با کارایی مناسب با بهره‌گیری از فناوری‌های سخت‌افزاری نوظهوری مانند RDMA و NVMe SSDها توسعه داد.
پیشینهٔ موضوع در حوزهٔ انباره‌ها، انباره‌های توزیع‌شده، RDMA و… در منابع [2, 3] بررسی شده است.
در سال‌های اخیر، جداسازی انباره (1) از محاسبه (2) به یک ترند در صنعت محاسبات ابری تبدیل شده است. چنین طراحی‌ای علاوه بر انعطاف‌پذیر کردن معماری، امکان استفاده از قابلیت‌های انبارهٔ مشترک را فراهم می‌کند؛ زیرا:
علاوه بر این، سرویس‌های پایگاه‌دادهٔ ابری نیز می‌توانند از این معماری بهره ببرند:
اما فناوری انباره‌های داده با سرعت زیادی در حال تغییر است. به همین دلیل، سکوهای فعلی نمی‌توانند از همهٔ قابلیت‌های استانداردهای سخت‌افزاری نوظهوری مانند RDMA و NVMe SSDها استفاده کنند. برای مثال، برخی فایل‌سیستم‌های (12) توزیع‌شدهٔ متن‌باز پراستفاده مانند HDFS و Ceph تأخیری بسیار بیشتر از دیسک‌های محلی دارند. اگر از آخرین PCIe SSDها استفاده شود، تفاوت کارایی بیشتر به چشم می‌آید. کارایی یک پایگاه‌دادهٔ رابطهای مانند MySQL که مستقیماً روی این فایل‌سیستم‌های توزیع‌شده اجرا می‌شود بسیار بدتر از اجرا روی PCIe SSDهایی با پردازنده و حافظهٔ مشابه است.
SSDها از پروتکل‌های قدیمی‌ای مانند SAS و SATA به پروتکل نوظهور NVMe تکامل یافته‌اند. یک NVMe SSD که به درگاه PCIe متصل می‌شود می‌تواند با تأخیری کمتر از ۱۰۰ میکروثانیه به گذردهی ۵۰۰ هزار ورودی-خروجی در ثانیه برسد.
با افزایش سرعت SSDها، سربار پشتهٔ قدیمی ورودی-خروجی هستهٔ سیستم‌عامل به گلوگاه (13) کارایی تبدیل می‌شود. اخیراً شرکت Intel کیت توسعهٔ کارایی قوی (SPDK) (14) را عرضه کرده است که مجموعه‌ای از ابزارها و کتابخانه‌هایی است که برای توسعهٔ نرم‌افزارهای مقیاس‌پذیر مبتنی بر NVMe در فضای کاربر (15) (و نه فضای هسته (16)) به کار می‌رود تا بتواند با پرهیز از وقفه‌ها (17)، سربار تغییر زمینه (18) و جابه‌جایی میان فضای کاربر و فضای هسته را نپردازد و کارایی را بهبود دهد.
RDMA سازوکاری برای ارتباط سریع و کم‌تأخیر تحت شبکهٔ سرورهای درون یک مرکز داده فراهم می‌کند. انتقال ۴ کیلوبایت داده بین دو سرور که فقط به واسطهٔ یک سوییچ به یکدیگر متصلند با این روش حدود ۷ میکروثانیه طول می‌کشد که بسیار از شبکه‌های TCP/IP سنتی سریع‌تر است.
در RDMA نوشتن در حافظهٔ ماشین مقصد مستقیماً با استفاده از کارت‌شبکه‌های مخصوص و بدون درگیر شدن پردازنده صورت می‌گیرد.
دو سازوکار ارسال-دریافت (ارتباط دوطرفه) و خواندن-نوشتن (ارتباط یک‌طرفه) در RDMA استفاده می‌شود. PolarFS از ترکیبی از هر دوی این سازوکارها بهره می‌گیرد. محموله‌های کوچک مستقیماً با سازوکار ارسال-دریافت منتقل می‌شوند. برای ارسال تکه‌های بزرگ‌تر داده، ابتدا دو طرف با سازوکار ارسال-دریافت دربارهٔ آدرس در حافظهٔ گره مقصد به توافق می‌رسند، سپس انتقال دادهٔ واقعی با سازوکار خواندن-نوشتن صورت می‌گیرد.
برای مقابله با این مسأله، فروشنده‌های پردازش ابری مانند Amazon AWS [9]، Google Cloud و Alibaba Cloud امکان استفاده از انبارهٔ متصل به نمونهٔ ماشین مجازی (19) را فراهم می‌کنند. یک انبارهٔ متصل به نمونهٔ ماشین مجازی یک SSD محلی و یک نمونهٔ ماشین مجازی با ورودی-خروجی بالا را استفاده می‌کند تا نیاز مشتری را به پایگاه‌داده‌های با سرعت بالا برآورده کند.
![شکل 1: انبارهٔ متصل به نمونهٔ ماشین مجازی آمازون [9]](https://files.virgool.io/upload/users/260751/posts/pko1u16w7yip/msyykb9d54lj.png)
متأسفانه اجرای پایگاه‌داده روی انبارهٔ متصل به نمونهٔ ماشین مجازی چندین اشکال دارد:
در مقالهٔ مورد بحث، نگارندگان طراحی و پیاده‌سازی PolarFS را توضیح داده‌اند که یک فایل‌سیستم توزیع‌شده است که تأخیر بسیار کم، گذردهی بالا و دسترسی‌پذیری بالا را فراهم می‌کند. این فایل‌سیستم:
با استفاده از تمام موارد گفته‌شده، تأخیر ابتدا تا انتهای PolarFS تا سطحی نزدیک به دیسک‌های SSD محلی کاهش یافته است.
فایل‌سیستم‌های توزیع‌شدهٔ معمولاً در محیط‌های اجرای ابری‌ای استقرار می‌یابند که هزاران ماشین دارند. در چنین مقیاسی خرابی‌های ناشی از مشکلات سخت‌افزاری یا نرم‌افزاری معمول است. بنابراین، یک الگوریتم اجماع مورد نیاز است تا اطمینان حاصل شود هیچ یک از تغییرات اعمال‌شده در حالات خاص گم نمی‌شوند و نسخه‌بدل‌ها (24) همواره می‌توانند به توافق برسند و بیت به بیت یکسان شوند.
خانوادهٔ پروتکل‌های Paxos برای حل مسألهٔ اجماع بسیار مشهورند. Raft یک گونه از Paxos است که فهم و پیاده‌سازی آن آسان‌تر است. سیستمهای توزیع‌شدهٔ بسیاری بر اساس Raft توسعه یافته‌اند. اما زمانی که Raft روی PolarFS اعمال شد، نگارندگان دریافتند که هنگام استفاده از سخت‌افزارهای بسیار کم‌تأخیری مانند RDMA و NVMe SSD که تأخیری از مرتبهٔ ده‌ها میکروثانیه دارند، Raft به‌شدت مانع مقیاس‌پذیری PolarFS می‌شود. به همین دلیل، نگارندگان الگوریتم ParallelRaft را توسعه دادند. این الگوریتم یک پروتکل اجماع تقویت‌شدهٔ مبتنی بر Raft است که اجازهٔ تصدیق (25) بدون‌ترتیب و اعمال لاگ‌ها را می‌دهد و در عین حال تطابق PolarFS را با معنای سنتی ورودی-خروجی حفظ می‌کند. با پروتکل مذکور، همروندی ورودی-خروجی موازی PolarFS به شکل قابل ملاحظه‌ای بهبود یافته است.
نگارندگان پایگاه‌دادهٔ رابطهای POLARDB را که یک گونهٔ تغییریافته از AliSQL (یک اشتقاق از MySQL/InnoDB) است بر روی بستر PolarFS توسعه داده‌اند. این پایگاه‌داده هم‌اکنون به عنوان یک سرویس پایگاه‌داده در سکوی محاسبات ابری Alibaba در دسترس است.
![شکل 2: POLARDB [9,3]](https://files.virgool.io/upload/users/260751/posts/pko1u16w7yip/ebmztiadngnf.png)
POLARDB از معماری انبارهٔ مشترک پیروی می‌کند و از نسخ متعدد فقط‌خواندنی پشتیبانی می‌نماید. گره‌های پایگاه‌دادهٔ POLARDB به دو نوع تقسیم می‌شوند: (شکل 3)
گره‌های اصلی
می‌توانند هم به پرس‌وجوهای خواندنی و هم به پرس‌وجوهای نوشتنی پاسخ دهند.
گره‌های فقط‌خواندنی(RO)
فقط به پرس‌وجوهای خواندنی پاسخ می‌دهند.
گره‌های اصلی و گره‌های فقط‌خواندنی فایل‌های لاگ و فایل‌های داده را ذیل یک دایرکتوری در PolarFS با هم به اشتراک می‌گذارند.
PolarFS با این ویژگی‌ها از POLARDB پشتیبانی می‌کند:
مقالهٔ مورد بحث سه نوآوری مهم دارد:
PolarFS از دو لایهٔ اصلی تشکیل شده است. لایهٔ زیری مدیریت انباره را بر عهده دارد و لایهٔ رویی فراداده (27) را مدیریت می‌کند و API فایل‌سیستم را عرضه می‌کند.
لایهٔ انباره
مسؤولیت منابع انبارهٔ همهٔ گره‌های انباره‌ای را بر عهده دارد و برای هر نمونهٔ پایگاه‌داده، یک والیوم (28) پایگاه‌داده فراهم می‌کند.
لایهٔ فایل‌سیستم
مدیریت فایل‌ها در والیوم، تضمین انحصار متقابل (29) و همگامسازی دسترسی همروند به فرادادهٔ فایل‌سیستم را بر عهده دارد. برای هر نسخهٔ پایگاه‌داده، PolarFS فرادادهٔ فایل‌سیستم را در والیوم مربوط به همان نمونه نگه می‌دارد.
شکل 5 اجزای اصلی PolarFS را نشان می‌دهد:
libpfs
یک کتابخانهٔ پیاده‌سازی فایل‌سیستم در فضای کاربر با یک API شبهPOSIX است که به پردازهٔ PolarFS متصل است.
سوییچ قطبی
در گره‌های محاسباتی قرار دارد و درخواست‌های ورودی-خروجی برنامه‌ها را به سرورهای تکه‌ها می‌فرستد.
سرورهای تکه
در گره‌های انباره‌ای مستقر می‌شوند تا به درخواست‌های ورودی-خروجی رسیدگی کنند.
کنترل‌کنندهٔ قطبی
واحد کنترل PolarFS است که شامل چندین میکروسرویس (30) و تعدادی عامل (31) در همهٔ گره‌های محاسباتی و انباره‌ای است. کنترل‌کنندهٔ قطبی از یک نمونهٔ MySQL به عنوان مخزن فراداده استفاده می‌کند.
لایهٔ فایل‌سیستم یک فایل‌سیستم مشترک موازی تأمین می‌کند که برای دسترسی همروند چندین گره پایگاه‌داده طراحی شده است. بنابراین تغییرات فرادادهٔ فایل‌سیستم باید میان گره‌ها همگامسازی شود شود تا سازگار بماند و تغییرات همروند نیز باید سلسله‌وار شوند تا فراداده خراب نشود.
libpfs یک پیاده‌سازی سبک فایل‌سیستم است که کاملاً در فضای کاربر اجرا می‌شود. همان‌گونه که در شکل 4 مشخص است، libpfs یک API شبهPOSIX عرضه می‌کند. در نتیجه تغییر یک پایگاه‌داده به گونه‌ای که به جای فایل‌سیستم سیستم‌عامل با libpfs کار کند آسان است.
هنگام راه‌اندازی یک گره پایگاه‌داده، pfs_mount به والیوم متناظر متصل می‌شود و آن را مقداردهی می‌کند. فرادادهٔ والیوم بارگیری می‌شود و داده‌ساختارهایی مانند درخت دایرکتوری‌ها در حافظهٔ اصلی تشکیل می‌شوند. هنگام خاموش شدن پایگاه‌داده، pfs_umount والیوم را جدا می‌کند. برای گسترش فضای والیوم نیز از pfs_mount_growfs استفاده می‌شود. سایر توابع نیز عملگرهایی معادل عملگرهای متناظر در POSIX هستند.
لایهٔ انباره رابط‌هایی برای مدیریت و دسترسی والیوم‌ها در اختیار لایهٔ فایل‌سیستم قرار می‌دهد.
به هر نمونهٔ پایگاه‌داده یک والیوم اختصاص داده می‌شود که از لیستی از تکه‌ها (32) تشکیل شده است. ظرفیت یک والیوم بین ۱۰ گیگابایت تا ۱۰۰ ترابایت متغیر است که به نیازمندی‌های اکثریت قریب به اتفاق پایگاه‌داده‌ها پاسخ می‌دهد. ظرفیت یک والیوم با افزودن تکه‌ها به آن افزایش می‌یابد. همانند انباره‌های سنتی، دسترسی تصادفی خواندن و نوشتن به والیوم با ترازهای (33) ۵۱۲بایتی امکان‌پذیر است. تغییرات یک تکه از داده که با یک درخواست ورودی-خروجی ارسال شده‌اند به شکل تجزیه‌ناپذیر صورت می‌گیرند.
یک والیوم به تعدادی تکه تقسیم می‌شود بین سرورهای تکه توزیع شده‌اند تکه کوچک‌ترین واحد توزیع داده است. و سرورهای تکه یک تکه را بین بیسک‌های متعدد پخش نمی‌کنند. نسخه‌بدل‌های هر سرور تکه به طور پیش‌فرض هر تکه داده را بین سه نسخه‌بدل متمایز که در قفسه‌های (34) متفاوت قرار دارند تکثیر می‌کنند. در صورت وجود نقاط داغ (35)، مهاجرت تکه‌ها به سرورهای تکهٔ دیگر امکان‌پذیر است.
اندازهٔ هر تکه در PolarFS برابر ۱۰ گیگابایت در نظر گرفته شده است که به شکل قابل‌توجهی بزرگ‌تر اندازهٔ متناظر در سایر سیستم‌هاست؛ برای مثال، اندازهٔ تکه‌ها در GFS برابر ۶۴ مگابایت است. این انتخاب حجم فراداده را بسیار کم می‌کند و مدیریت آن را تسهیل می‌نماید. برای مثال، یک والیوم ۱۰۰ترابایتی فقط ۱۰٬۰۰۰ تکه خواهد داشت. ذخیرهٔ ۱۰٬۰۰۰ رکورد در پایگاه‌داده هزینهٔ نسبتاً کمی دارد. علاوه بر این، تمام این فراداده را می‌توان در کش (36) کنترل‌کنندهٔ قطبی جا داد و در نتیجه در مسیر حیاتی اجرای برنامه، از هزینهٔ دسترسی به فراداده کاست.
عیب این تصمیم آن است که جدا کردن نقاط داغ موجود در یک تکه دیگر ممکن نیست. اما با توجه به نسبت بالای تعداد تکه‌ها به تعداد سرورها (حدود ۱۰۰۰ : ۱)، نمونه‌های متعددی پایگاه‌داده‌ها (هزاران نمونه یا بیشتر) و قابلیت مهاجرت تکه‌ها بین سرورهای تکه، معمولاً PolarFS می‌تواند بار کل سیستم را متعادل کند.
هر تکه در سرورهای تکه به بلوک‌های ۶۴کیلوبایتی تقسیم می‌شود. بلوک‌ها به در زمان نیاز به تکه‌ها اختصاص می‌یابند تا تأمین لاغر (38) محقق شود. یک تکهٔ ۱۰گیگابایتی ۱۶۳٬۸۴۰ بلوک داده دارد. جدول نگاشت آدرس منطقی بلوک (39) تکه به بلوک‌ها به همراه نقشهٔ بیتی (40) بلوک‌های خالی هر دیسک به شکل محلی در سرورهای تکه نگه‌داری می‌شود. جدول نگاشت هر تکه حدود ۴۶۰ کیلوبایت حافظه اشغال می‌کند که نسبتاً فضای کمی است و می‌تواند در کش سرورهای تکه نگه‌داری شود.
سوییچ قطبی یک پردازهٔ دیمن (41) است که به همراه یک یا چند نمونهٔ پایگاه‌داده در سرور پایگاه‌داده مستقر می‌شود. در هر نمونهٔ پایگاه‌داده، libpfs درخواست‌ها را به سوییچ قطبی می‌فرستد. هر درخواست اطلاعات آدرس‌دهی (مانند شناسهٔ والیوم، آفست و طول) را در اختیار دارد که با استفاده از آن می‌توان تکهٔ مربوط را شناسایی کرد.
libpfsهای نمونه‌های مختلف پایگاه‌داده درخواست‌های ورودی-خروجی را از طریق یک حافظهٔ مشترک به سوییچ قطبی می‌فرستند. این حافظهٔ مشترک با چند بافر حلقوی (42) پیاده‌سازی شده است. libpfs به شکل نوبت گردشی (43) یک بافر حلقوی را انتخاب می‌کند، درخواست را در آن می‌نویسد و منتظر پاسخ می‌شود. در سمت دیگر، سوییچ قطبی با اختصاص یک ریسمان (44) به هر بافر حلقوی، به شکل مداوم به دنبال درخواست‌های جدید از آن‌ها سرکشی (45) می‌کند. پس از دریافت یک درخواست جدید، سوییچ قطبی درخواست را برای سرور تکهٔ متناظر ارسال می‌کند.
یک درخواست ممکن است به چندین تکه مرتبط باشد. در این صورت درخواست به چندین درخواست فرعی تقسیم می‌شود. نهایتاً، یک درخواست پایه‌ای به سرور تکه‌ای که رهبر گروه اجماعی محل نگه‌داری تکهٔ دادهٔ متناظر است ارسال می‌شود.
سوییچ قطبی محل تمام نسخه‌بدل‌هایی را که به یک تکه مرتبطند با گشتن در کش محلی فرادادهٔ خود که با کنترل‌کنندهٔ قطبی هم‌گام است پیدا می‌کند. نسخه‌بدل‌های هر تکه داده یک گروه اجماعی می‌سازند که در آن یک گره رهبر و بقیهٔ گره‌ها پیرو هستند. فقط گره رهبر می‌تواند به درخواست‌ها پاسخ دهد. تغییر رهبر در گروه اجماعی نیز با سوییچ قطبی هم‌گام می‌شود و در کش محلی آن ذخیره می‌گردد. اگر در زمان مورد نظر درخواست بی‌پاسخ بماند (46) سوییچ قطبی با فواصل زمانی نمایی (47) مجدداً تلاش می‌کند. اگر در این میان رهبرگزینی صورت گرفته باشد، سوییچ قطبی مجدداً درخواست را ارسال می‌کند.
سرور تکه وظیفهٔ ذخیرهٔ تکه‌ها را بر عهده دارد و امکان دسترسی تصادفی را به آن‌ها فراهم می‌کند.
سرورهای تکه در گره‌های انباره‌ای مستقر می‌شوند. در هر سرور انباره‌ای ممکن است چندین پردازهٔ سرور تکه در حال اجرا باشد که به هر کدام هستهٔ پردازندهٔ اختصاصی و دیسک NVMe SSD مستقل اختصاص می‌یابد؛ بنابراین بین دو سرور تکه رقابت بر سر منابع شکل نمی‌گیرد. در نتیجه میان ریسمان‌های ورودی-خروجی داده‌ساختار مشترکی وجود ندارد و ریسمان ورودی-خروجی بدون سربار قفل‌گذاری پیاده‌سازی شده است. سرورهای تکه از مدل سرکشی در کنار ماشین حالت محدود رخدادمحور (48) به عنوان مدل همروندی استفاده می‌کنند. خواندن از RDMA و صف‌های NVMe و پردازش درخواست‌های ورودی در یک ریسمان انجام می‌شود.
هر سرور تکه یک لاگ پیش‌نویس (49) دارد. برای تأمین تجزیه‌ناپذیری (50) و پایایی (51)، تغییرات هر تکهٔ داده پیش از بهروزرسانی بلوک‌های داده به لاگ پیش‌نویس اضافه می‌شوند. لاگ پیش‌نویس در بافرهای غیرفرار SSD از نوع ۳D XPoint نگه‌داری می‌شوند. در صورت پر شدن این بافرها، سرور تکه سعی می‌کند با پاک کردن لاگ‌های قدیمی فضا ایجاد کند. اگر باز هم فضای کافی موجود نباشد، لاگ‌ها در NVMe SSD نوشته می‌شوند.
سرورهای تکه با الگوریتم ParallelRaft درخواست‌ها را بین خود تقسیم می‌کنند و یک گروه اجماعی می‌سازند. یک سرور تکه ممکن است به دلایل متعددی گروه اجماعی خود را ترک کند و ممکن است به شیوه‌های متفاوتی به این مسأله رسیدگی شود. گاهی این اتفاق به دلیل خرابی‌های موقتی گاه و بی‌گاه، مانند خرابی موقت شبکه رخ می‌دهد. همچنین ممکن است سرور در حال ارتقا باشد و راه‌اندازی مجدد شده باشد. در چنین شرایطی بهتر است سیستم منتظر سرور قطع شده بماند تا دوباره آنلاین شود، به گروه ملحق گردد و به بقیهٔ گره‌های گروه برسد. در موارد دیگر خرابی پایدار است و ممکن است مدتی طولانی ادامه یابد؛ مثلاً ممکن است سرور آسیب دیده باشد یا آفلاین شده باشد. در این صورت همهٔ تکه‌های دادهٔ سرور تکهٔ مفقود باید از نسخه‌بدل‌های دیگر در یک سرور دیگر رونویسی شود تا تعداد لازم نسخه‌بدل‌ها از آن تکه‌های داده وجود داشته باشد.
یک سرور تکهٔ قطع‌شده همواره به طور خودگردان سعی می‌کند دوباره به گروه اجماعی خود ملحق شود تا زمان در دسترس نبودن کاهش یابد. اما ممکن است کنترل‌کنندهٔ قطبی تصمیمات مکملی اتخاذ کند. کنترل‌کنندهٔ قطبی به شکل دوره‌ای فهرست سرورهای تکه‌ای را که قطع شده‌اند جمع‌آوری می‌کند و آنهایی را که به نظر می‌رسد خرابی دائمی دارند برمی‌گزیند تا اقدامات لازم را صورت دهد. گاهی تصمیم‌گیری دشوار است: مثلاً یک سرور تکه با دیسک کند ممکن است تأخیری بسیار بیشتر از بقیه داشته باشد، اما همواره می‌تواند به پویشگرهای حیات (52) پاسخ دهد. در چنین شرایطی الگوریتم‌های یادگیری ماشینی مبتنی بر آمار معیارهای عملکردی اجزای کلیدی مفیدند.
کنترل‌کنندهٔ قطبی واحد کنترل خوشهٔ PolarFS است. برای تأمین دسترسی‌پذیری بالای سرویس‌های، کنترل‌کنندهٔ قطبی روی یک گروه حداقل سه‌تایی از ماشین‌های اختصاصی مستقر می‌شود.
کنترل‌کنندهٔ قطبی سرویس‌های کنترلی خوشه را فراهم می‌کند؛ مانند: مدیریت گره‌ها، مدیریت والیوم‌ها، اختصاص منابع، همگامسازی فراداده و نظارت (53).
اهم وظایف کنترل‌کنندهٔ قطبی عبارتند از:
کنترل‌کنندهٔ قطبی به شکل دوره‌ای فرادادهٔ خوشه را (مثلاً محل تکه‌های هر والیوم) از طریق دستورهای واحد کنترل با سوییچ قطبی هم‌گام می‌کند. سوییچ قطبی فراداده را در کش محلی خود ذخیره می‌کند. هنگام دریافت درخواست از libpfs، سوییچ قطبی بر اساس این کش محلی درخواست را به سرور تکهٔ متناظر ارسال می‌کند. سوییچ قطبی گاهی، در صورت عقب افتادن کش محلی از مخزن مرکزی فراداده، فراداده را از کنترل‌کنندهٔ قطبی می‌گیرد.
کنترل‌کنندهٔ قطبی به عنوان واحد کنترل در مسیر حیاتی ورودی-خروجی قرار ندارد؛ بنابراین می‌توان تداوم سرویس‌دهی آن را با شگردهای سنتی تضمین دسترسی‌پذیری بالا تأمین کرد. حتی در فواصل زمانی کوتاه میان خرابی و بازیابی کنترل‌کنندهٔ قطبی، به دلیل وجود فرادادهٔ کش‌شده در سوییچ قطبی و خودمدیریتی سرورهای تکه، جریان ورودی-خروجی PolarFS تحت تأثیر قرار نمی‌گیرد.
شکل 6 نشان می‌دهد یک درخواست نوشتن چگونه در PolarFS اجرا می‌شود.
یک سیستم عملیاتی انبارهٔ توزیع‌شده به یک پروتکل اجماع نیاز دارد تا تضمین کند هیچ تغییر اعمال‌شده‌ای در حالات خاص گم نمی‌شود. در ابتدای طراحی، الگوریتم Raft با توجه به پیچیدگی کم پیاده‌سازی آن برای حل این مسأله انتخاب شد. اما مشکلات به‌زودی پدیدار شدند.
Raft با هدف سادگی و قابل فهم بودن کاملاً سلسله‌وار طراحی شده است. در این پروتکل لاگ‌ها مجاز نیستند شامل حفره باشند؛ این بدان معنی است که اجزای لاگ باید به‌ترتیب توسط گره‌های پیرو تصدیق، توسط رهبر اعمال و در همهٔ نسخه‌بدل‌ها به کار گرفته شوند. درخواست‌های انتهای صف نمی‌توانند پاسخ داده شوند یا اعمال گردند پیش از آن که همهٔ درخواست‌های قبلیشان به شکل ماندگار در دیسک ذخیره شوند و پاسخ داده شوند. این مسأله شدیداً روی میانگین تأخیر تأثیر منفی می‌گذارد و گذردهی را کم می‌کند؛ چنان که مشاهدات حاکی از آن بود که با افزایش عمق ورودی-خروجی از ۸ به ۳۲، گذردهی نصف می‌شود.
الگوریتم Raft مناسب انتقال لاگ‌ها بین یک رهبر و پیروان آن در محیط‌هایی با چندین ارتباط نیست. اگر یک ارتباط قطع یا متوقف شود یا کند باشد، لاگ‌ها بدون‌ترتیب به گره‌های پیرو می‌رسد. به بیان دیگر، لاگ‌هایی در ابتدای صف ممکن است پس از لاگ‌هایی که در صف پشت سر آن‌ها قرار دارد به گره‌های پیرو برسند. اما در پروتکل Raft، گره پیرو باید به‌ترتیب لاگ‌ها را بپذیرد و در نتیجه نمی‌تواند به گره رهبر اطلاع دهد که لاگ‌های بعدی را دریافت کرده است. در چنین حالتی ممکن است گره رهبر در شرایطی گیر کند که گره‌های پیرو نمی‌توانند یک لاگ را دریافت کنند. اما در عمل استفاده از چندین ارتباط در محیط‌های بسیار همروند رایج است. بنابراین لازم بود تا الگوریتم Raft بازبینی شود تا چنین شرایطی را تحمل کند.
در یک سیستم پردازش تراکنش‌ها مانند پایگاه‌داده، الگوریتم‌های کنترل همروندی اجرای بدون‌ترتیب را در عین تضمین سلسله‌وار بودن نتایج میسر می‌سازند. پایگاه‌داده‌هایی مانند MySQL نسبت به‌ترتیب ورودی-خروجی انبارهٔ زیرساختی حساسیتی ندارند. سیستم قفل پایگاه‌داده تضمین می‌کند که در هر لحظه از زمان فقط یک ریسمان با هر صفحه کار می‌کند. در چنین شرایطی ترتیب انجام دستورها اهمیتی ندارد. با توجه به این مسائل، نگارندگان سعی کردند با آسان کردن برخی محدودیت‌ها، Raft را برای شرایط خاص استفاده مناسب‌سازی کنند.
الگوریتم ParallelRaft با توجه به نیازمندی‌های مذکور طراحی شده است. این الگوریتم ماشین حالت تکثیرشده را با لاگ تکثیرشده پیاده‌سازی کرده است. دو نوع گره رهبر و پیرو وجود دارند و رهبر لاگ‌ها را به پیروانش می‌فرستد. برای شکستن مسأله از دیدگاهی مشابه Raft استفاده می‌شود و ParallelRaft به سه بخش تقسیم می‌شود: تکثیر بدون‌ترتیب لاگ، رهبرگزینی و رسیدن.
ایده‌هایی برای اثبات درستی االگوریتم ParallelRaft در منبع [3] بیان شده است.
همچنین در منبع [3] کارایی دو الگوریتم Raft و ParallelRaft مقایسه شده است. با افزایش عمق ورودی-خروجی، ParallelRaft بیشتر و بیشتر از Raft پیشی می‌گیرد. زمانی که این عمق به ۳۲ می‌رسد، تأخیر Raft حدوداً ۲٫۵ برابر ParallelRaft است، در حالی که به کمتر از نیمی از گذردهی الگوریتم جدید دست می‌یابد.
الگوریتم Raft از دو جنبه به شکل سلسله‌وار عمل می‌کند:
الگوریتم ParallelRaft این محدودیت‌ها را می‌شکند و همهٔ این مراحل را بدون‌ترتیب انجام می‌دهد. بنابراین الگوریتم جدید تفاوتی جزئی با الگوریتم قدیمی دارد: در این الگوریتم اعلام اعمال شدن یک لاگ به معنی اعمال شدن لاگ‌های قبل از آن نیست. برای اطمینان از درستی الگوریتم، باید از دو مسأله اطمینان حاصل شود:
اجرای بدون‌ترتیب لاگ‌ها در ParallelRaft از این قانون پیروی می‌کند: اگر دامنهٔ نوشتن دو لاگ با هم هم‌پوشانی ندارد، این دو لاگ با هم تداخل نخواهند داشت و می‌توانند با هر ترتیبی اجرا شوند. در غیر این صورت لاگ‌ها تداخل دارند و باید با همان ترتیب دریافت شدن اجرا شوند. در این صورت تغییرات جدید هیچ‌گاه با تغییرات قدیمی بازنویسی نخواهند شد.
در ادامه، نحوهٔ بهینه‌سازی مراحل تصدیق، اعمال و به‌کارگیری (56) در ParallelRaft بررسی خواهد شد.
بر خلاف الگوریتم Raft که در آن گره‌های پیرو پیش از تثبیت کردن لاگ‌های قبلی نمی‌توانند دریافت یک لاگ را از رهبر تصدیق کنند، در ParallelRaft گره‌های پیرو به محض نوشتن یک لاگ دریافت‌شده، می‌توانند دریافت آن را تصدیق کنند.
این عمل زمان تلف‌شده را کاهش می‌دهد و میانگین تأخیر را بهبود می‌دهد.
بر خلاف Raft که در آن گره رهبر نمی‌تواند یک لاگ را پیش از اعمال لاگ‌های قبلی آن اعمال کند، در ParallelRaft بلافاصله پس از آن که اکثریت گره‌های پیرو دریافت و ثبت لاگ را تصدیق کنند می‌توان لاگ را اعمال کرد.
این مسأله با معنای مورد استفاده در انباره‌ها سازگاری دارد؛ زیرا انباره‌هایی مانند NVMe بر خلاف سیستمهای پردازش تراکنش‌ها سازگاری قوی (57) را تضمین نمی‌کنند و از انواع سازگاری ضعیف (58) استفاده می‌کنند.
با پذیرش امکان تکثیر و اعمال بدون‌ترتیب لاگ‌ها در ParallelRaft، این الگوریتم پذیرش دنباله‌ای از لاگ‌ها را که شامل حفره است ممکن می‌سازد. اما تضمین درستی چنین روشی یک چالش است.
ParallelRaft برای حل این مشکل داده‌ساختار جدیدی را به نام بافر پس‌نگر (59) مورد استفاده قرار می‌دهد. در این داده‌ساختار آدرس منطقی بلوکی n لاگ قبلی نگه‌داری می‌شود. بر اساس این اطلاعات، گره پیرو می‌تواند تشخیص دهد آیا یک لاگ با لاگ‌های قبلی که هنوز دریافت و اعمال نشده‌اند تداخل دارد یا خیر. در صورت عدم وجود تداخل، می‌توان لاگ را بی‌درنگ اعمال کرد. در صورت وجود تداخل، و فقط در این حالت، لاگ اعمال نمی‌شود و وارد لیست لاگ‌های در انتظار می‌گردد تا زمانی که لاگ‌های مفقودهٔ مورد نیاز نیز دریافت شوند. به این شکل می‌توان حفره‌هایی به طول حداکثر n را در زنجیرهٔ لاگ‌ها تحمل کرد.
طبق مشاهدات نگارندگان، n = ۲ برای استفاده از PolarFS با RDMA مناسب است.
هنگام رهبرگزینی، ParallelRaft می‌تواند همانند Raft گرهی را به عنوان رهبر انتخاب کند که جدیدترین لاگ اعمال‌شده و طولانی‌ترین دنبالهٔ لاگ‌ها را دارد. اما بر خلاف Raft که در آن رهبر منتخب همهٔ لاگ‌های سابقاً اعمال‌شده را دارد، در ParallelRaft، به دلیل وجود حفره‌های احتمالی، ممکن است رهبر جدید همهٔ تغییرات را نداشته باشد و لازم است گره انتخاب‌شده برای رهبری در یک حالت ادغام (60) لاگ‌های اعمال‌شدهٔ سایر اعضای گروه اجماعی را ببیند تا از نامزد رهبری به رهبر واقعی بدل شود و بتواند لاگ‌های جدید را بپذیرد.
برخی حالات خاص در منبع [3] بررسی شده‌اند.
در شکل 8 یک نمونه با سه نسخه‌بدل بررسی شده است. ابتدا نامزد پیروی لاگ‌های خود را برای نامزد رهبری می‌فرستد (ادغام). سپس نامزد رهبری حالت خود را با نامزد پیروی هم‌گام می‌کند (همگامسازی). در ادامه، نامزد رهبری می‌تواند همهٔ لاگ‌ها را اعمال کند و به نامزد پیروی نیز اطلاع دهد تا آن‌ها را اعمال کند (اعمال). در نهایت، نامزد رهبری به رهبر و نامزد پیروی به پیرو بدل می‌شوند.
در پیاده‌سازی واقعی از مفهومی به نام چک‌پوینت استفاده می‌شود که یک اسنپ‌شات از لاگ‌های اعمال‌شده تا زمان گرفتن اسنپ‌شات و نیز احتمالاً برخی لاگ‌های دریافت‌شده ولی هنوز اعمال‌نشده در آن زمان است. چک‌پوینت‌ها اجازه می‌دهند امکان هرس کردن دنبالهٔ لاگ‌ها فراهم شود.
الگوریتم ParallelRaft در پیاده‌سازی واقعی گرهی با جدیدترین چک‌پوینت را به عنوان رهبر برمی‌گزیند تا بتواند مرحلهٔ رسیدن را انجام دهد.
زمانی که یک گره پیرو عقب‌مانده می‌خواهد به وضعیت فعلی رهبر برسد، از رسیدن سریع (61) یا رسیدن با جریان (62) استفاده می‌کند. انتخاب بین این دو روش به وضعیت فعلی گره پیرو بستگی دارد. روش رسیدن سریع برای همگامسازی افزایشی رهبر و پیرو در زمانی که اختلاف آن‌ها زیاد نیست استفاده می‌شود. اگر شرایطی پیش بیاید که اختلاف رهبر و پیرو زیاد شود، مثلاً وقتی گره پیرو چند روز آفلاین بوده است، PolarFS از سازوکار رسیدن با جریان استفاده می‌کند. در عملیات رسیدن چک‌پوینت‌ها مؤثرند که در بخش چک‌پوینت توضیح داده شدند.
شکل 9 شرایط متفاوت رهبر و پیرو را در زمان آغاز همگامسازی نشان می‌دهد. در حالت اول، چک‌پوینت رهبر از آخرین لاگ پیرو جدیدتر است و ممکن است رهبر لاگ‌های بین این دو را هرس کرده باشد. در این حالت نمی‌توان از رسیدن سریع استفاده کرد و رسیدن با جریان وارد عمل می‌شود. حالات دوم و سوم با رسیدن سریع حل‌شدنی‌اند.
در توضیحاتی که خواهد آمد، همواره می‌توان فرض کرد آخرین چک‌پوینت رهبر از آخرین چک‌پوینت پیرو جدیدتر است. در غیر این صورت، رهبر می‌تواند بی‌درنگ یک چک‌پوینت بسازد و چنین شرایطی را تأمین کند.
گره‌های پیرو ممکن است حفره‌هایی بعد از آخرین چک‌پوینتشان داشته باشند. حفره‌های بین آخرین چک‌پوینت رهبر و آخرین چک‌پوینت پیرو را می‌توان با استفاده از رونوشت‌برداری از بلوک‌های دادهٔ مورد نیاز از بلوک‌های دادهٔ رهبر پر کرد. تشخیص بلوک‌های دادهٔ مورد نیاز با استفاده از بافر پس‌نگر ممکن است.
در حالت سوم، ممکن است گره پیرو لاگ‌های اعمال‌نشده‌ای داشته باشد. چنین لاگ‌هایی هرس می‌شوند و سپس مراحل مذکور صورت می‌گیرد.
در این روش تاریخچهٔ لاگ‌های پیرو بی‌فایده است. محتوای بلوک‌های داده و لاگ‌های بعد از چک‌پوینت گره رهبر برای همگامسازی استفاده می‌شود. برای انتقال محتوای بلوک‌های داده، تکه‌های داده به بخش‌های ۲۱۸کیلوبایتی شکسته می‌شوند.
در لایهٔ فایل‌سیستم PolarFS، مدیریت فراداده می‌تواند به دو بخش تقسیم شود:
سه نوع اطلاعات در فرادادهٔ فایل‌سیستم وجود دارد:
مدخل دایرکتوری (63)
نام (متشکل از آدرس فایل) و یک ارجاع به یک inode را در خود نگه‌داری می‌کند. مجموعه‌ای از مداخل دایرکتوری‌ها یک درخت دایرکتوری (64) می‌سازند.
inode
یک فایل معمولی یا یک دایرکتوری را توصیف می‌کند. برای یک فایل معمولی، ارجاعی را به مجموعه‌ای از برچسب‌های بلوک‌ها نگه می‌دارد. برای یک دایرکتوری، ارجاعی را به مجموعه‌ای از مدخل‌های دایرکتوری واقع در دایرکتوری والد نگه می‌دارد.
برچسب بلوک (65)
نگاشت یک شمارهٔ بلوک فایل به یک شمارهٔ بلوک والیوم را در خود دارد.
سه نوع مذکور فراداده در یک نوع‌داده (66) به نام فراشیء (67) مجرد شده‌اند.
هنگام ساختن یک فایل‌سیستم جدید، فرااشیا در قطاع‌های ۴هزارتایی مقداردهی اولیه می‌شوند. هنگام سوار کردن (68) فایل‌سیستم، فرااشیا در حافظه بارگیری می‌شوند و به تکه‌ها و انواع مختلف تقسیم می‌گردند.
یک فراشیء در حافظه با یک زوج‌مرتب شامل شناسهٔ فراشیء و نوع آن قابل دسترسی است. بیت‌های باارزش شناسه برای یافتن تکه‌ای که فراشیء به آن تعلق دارد استفاده می‌شود. سپس بر اساس نوع فراشیء گروه مناسب انتخاب می‌شود. در نهایت بیت‌های کم‌ارزش شناسه به عنوان شاخص (69) برای دسترسی به فراشیء مورد استفاده قرار می‌گیرند.
برای بهروزرسانی یک یا چند فراشیء، یک تراکنش آماده می‌شود و هر بهروزرسانی به عنوان یک عمل در تراکنش ثبت می‌شود. این عمل مقادیر قدیمی و جدید شیئی را که قرار است بهروزرسانی شود در خود دارد. پس از انجام همهٔ به‌روزرسانی‌ها، تراکنش آمادهٔ اعمال است. فرایند اعمال نیازمند هماهنگی و همگامسازی میان گره‌های پایگاه‌داده است که نحوهٔ اجرای آن در بخش هماهنگی و همگامسازی تغییرات فراداده توضیح داده می‌شود. اگر اعمال ناموفق باشد، بهروزرسانی با مقادیر قدیمی که در تراکنش موجود است بازگردانی (70) می‌شود.
برای پشتیبانی از همگامسازی فرادادهٔ فایل‌سیستم، PolarFS تغییرات فراداده را به عنوان تراکنش در یک فایل وقایع‌نگاری (71) ثبت می‌کند. گره‌های پایگاه‌داده متناوباً برای دریافت تراکنش‌های جدید به این فایل سرکشی می‌کنند. هنگامی که تراکنش جدیدی یافته شد، گره‌ها آن را دریافت و بازپخش (72) می‌کنند.
به طور معمول، فقط یک گره روی این فایل می‌نویسد و چندین گره از روی آن می‌خوانند. در شرایطی مانند چند بخش شدن شبکه یا تغییرات مدیریتی، ممکن است چند گره سعی کنند روی این فایل بنویسند. در چنین شرایطی سازوکاری برای هماهنگی نوشتن روی فایل وقایع‌نگاری مورد نیاز است. PolarFS برای این کار از الگوریتم Paxos روی دیسک استفاده می‌کند. لازم به ذکر است که هدف الگوریتم Paxos در این‌جا با هدف الگوریتم ParallelRaft که برای اطمینان از سازگاری نسخه‌بدل‌های یک تکه از داده‌ها مورد استفاده قرار می‌گیرد متفاوت است.
الگوریتم Paxos روی دیسک روی یک فایل متشکل از صفحات ۴ هزارتایی که می‌توانند به طور خودکار خوانده یا نوشته شوند اجرا می‌شود. این صفحات به عنوان یک رکورد رهبر و بلوک‌های داده برای هر گره پایگاه‌داده تفسیر می‌شوند. هر گره پایگاه‌داده از این صفحات بلوک داده استفاده می‌کند تا پیشنهاد خودش را بنویسد و پیشنهاد گره‌های دیگر را بخواند. صفحهٔ رکورد رهبر شامل اطلاعات برندهٔ فعلی الگوریتم Paxos و لنگر (73) فایل وقایع‌نگاری است. الگوریتم Paxos روی دیسک را فقط گره‌های اصلی (نوشتنی) اجرا می‌کنند. گره‌های فقط‌خواندنی این کار را انجام نمی‌دهند؛ در عوض، با بررسی لنگر در صفحهٔ رکورد رهبر به آن سرکشی می‌کنند. اگر لنگر تغییر کند، گره‌های فقط‌خواندنی می‌فهمند که تراکنش‌های جدیدی در فایل وقایع‌نگاری وجود دارد و با دریافت آن‌ها، فرادادهٔ محلی خود را بهروزرسانی می‌کنند.
فرایند اعمال شدن تراکنش‌ها را می‌توان با مثال شکل 10 توضیح داد:
علاوه بر موارد مطرح‌شده در بخش‌های قبل، چند مبحث طراحی دیگر نیز وجود داشته است که ارزش بحث دارند. برخی از این موارد به PolarFS و برخی دیگر به ویژگی‌های پایگاه‌داده مرتبطند.
دو الگوواره برای طراحی سیستمهای توزیع‌شده وجود دارد: متمرکز و غیرمتمرکز.
سیستمهای توزیع‌شدهٔ متمرکز مانند GFS و HDFS یک گره بالادست (76) دارند که مسؤولیت نگه‌داری فراداده و مدیریت عضویت را بر عهده دارد. پیاده‌سازی این نوع سیستم‌ها ساده‌تر است، اما یک گره بالادست ممکن است چه در زمینهٔ مقیاس‌پذیری و چه از نظر دسترسی‌پذیری به گلوگاه کل سیستم بدل شود.
سیستمهای توزیع‌شدهٔ غیرمتمرکز مانند Dynamo در سمت دیگر طیف قرار دارند. در این سیستم‌ها گره‌ها در یک رابطهٔ نظیر‌به‌نظیر (77) با یکدیگر قرار دارند و فراداده بین همهٔ گره‌ها مشترک و تکراری است. انتظار می‌رود یک سیستم غیرمتمرکز اتکاپذیرتر باشد اما پیاده‌سازی و بررسی آن دشوارتر خواهد بود.
PolarFS یک مصالحه (78) بین طراحی‌های متمرکز و غیرمترکز انجام داده است. در یک سمت، کنترل‌کنندهٔ قطبی یک گره بالادست متمرکز است که مسؤول کارهای مدیریتی مانند مدیریت منابع و پذیرش درخواست‌های کنترلی مانند ساخت یک والیوم جدید است. در طرف دیگر، سرورهای تکه با یکدیگر ارتباط برقرار می‌کنند و از یک پروتکل اجماع برای رسیدگی به خرابی و بازیابی خودگردان، بدون نیاز به درگیر شدن کنترل‌کنندهٔ قطبی استفاده می‌کنند.
اسنپ‌شات یک نیاز معمول در پایگاه‌داده‌هاست. PolarFS از ویژگی اسنپ‌شات پشتیبانی می‌کند که طراحی سازوکار اسنپ‌شات POLARDB را تسهیل می‌کند.
در PolarFS، لایهٔ انباره امکان دسترسی قابل‌اتکا به داده‌ها را برای لایه‌های بالاتر فراهم می‌کند. POLARDB و libpfs سازوکار لاگ خودشان را برای اطمینان از تجزیه‌ناپذیری و پایایی تراکنش‌ها استفاده می‌کنند. لایهٔ انبارهٔ PolarFS یک اسنپ‌شات با سازگاری دیسک در زمان قطع برق (79) ارائه می‌دهد که POLARDB و libpfs بر اساس آن تصویر دادهٔ سازگار خودشان را بنا می‌کنند.
وقتی فاجعه‌ای پیش‌بینی‌نشده رخ می‌دهد یا یک حسابرسی فعال مورد نیاز است، کنترل‌کنندهٔ قطبی جدیدترین اسنپ‌شات داده را در اختیار نمونهٔ POLARDB قرار می‌دهد. سپس POLARDB و libpfs از لاگ‌های خود برای بازسازی یک حالت سازگار استفاده می‌کنند.
جزئیات بیشتر پیاده‌سازی اسنپ‌شات با سازگاری دیسک در زمان قطع برق در منابع [3, 7] ذکر شده است.
اتکاپذیری سیستمهای صنعتی، خصوصاً برای سیستم‌هایی مانند PolarFS که سرویس‌دهی به محصولات ابری عمومی با خدمت‌رسانی ۲۴ × ۷ را بر عهده دارند، اهمیت فراوانی دارد. در چنین سیستم‌هایی همهٔ انواع وظایف نگه‌داری اتکاپذیری باید صورت گیرد تا جلوی از دست رفتن خدمات و درآمد حاصل از آن خدمات جلوگیری شود. اجرای کارآمد این وظایف در عین فراهم آوردن یک سرویس مناسب برای بار سنگین کاربران، چالشی بزرگی برای PolarFS بود. به عنوان یک نمونه، سازوکار رسیدن با جریان، که در بخش رسیدن توضیح داده شد، زیر فشار سنگین، ممکن است دسترسی‌پذیری سیستم را تحت تأثیر قرار دهد. برای غلبه بر این مشکل، همگامسازی داده‌ها در قالب قطعات کوچک ۱۲۸کیلوبایتی صورت می‌گیرد. تفصیل بیشتر این مسأله در منبع [3] آمده است. موارد متعدد دیگری از وظایف زمان‌بر وجود داشته است که نگارندگان در مورد آن‌ها تصمیم گرفته‌اند.
برای ارزیابی سیستم پیشنهادی، PolarFS پیاده‌سازی و POLARDB نیز بر اساس آن به عنوان یک سرویس عمومی در ابر Alibaba عرضه شده است. سپس کارایی و مقیاس‌پذیری آن‌ها بررسی گردیده است. برای سنجش PolarFS، این فایل‌سیستم روی یک خوشه با ext۴ روی NVMe محلی و CephFS روی Ceph (به عنوان یک سیستم انبارهٔ توزیع‌شدهٔ متن‌باز پراستفاده) مقایسه شده است. برای سنجش POLARDB از مقایسهٔ آن با سرویس MySQL ابری Alibaba و POLARDB روی ext۴ محلی استفاده شده است.
برای سنجش فایل‌سیستم‌ها از کارایی ابتدا تا انتها تحت بارها و الگوهای دسترسی متفاوت استفاده شده است که تأخیر و گذردهی را نیز به شکل ضمنی درون خود دارد. نتایج آزمایش PolarFS و CephFS مربوط به یک خوشه با ۶ گره انباره‌ای و یک گره کلاینت است. گره‌ها از طریق کارت‌شبکه‌های مجهز به RDMA با یکدیگر ارتباط برقرار کرده‌اند.
از نسخهٔ ۲۱٫۲٫۳ Ceph با موتور انبارهٔ bluestore و پیام‌رسان ارتباطی async + POSIX استفاده شده است. با آن که موتور انبارهٔ Ceph می‌توانسته از RDMA استفاده کند، به علت عدم پشتیبانی فایل‌سیستم از آن، از پشتهٔ شبکهٔ TCP/IP روی فایل‌سیستم ext۴ استفاده شده است. یک درایو ext۴ جدید روی یک SSD پس از پاک کردن محتوای قبلی آن ایجاد شده است.
برای تولید انواع مختلف بار با اندازه‌های ورودی-خروجی مختلف و همراه با موازی‌سازی، از FIO استفاده شده است. این ابزار از فایل‌هایی که تا ۱۰ گیگابایت بزرگ شده‌اند استفاده کرده است.
در ارزیابی POLARDB، مقایسهٔ POLARDB روی ext۴ محلی با POLARDB روی PolarFS در محیطی سخت‌افزاری مانند آن‌چه برای ارزیابی PolarFS توصیف شد صورت گرفته است.
برای ارزیابی پایگاه‌داده‌ها، از محک (80) Sysbench با بارهای شبیه‌سازی‌شدهٔ OLTP فقط‌خواندن، فقط‌نوشتن (با نسبت update : delete : insert = ۲ : ۱ : ۱) و ترکیب خواندن و نوشتن (با نسبت read : write = ۷ : ۲) استفاده شده است. مجموعه‌دادهٔ مورد استفاده ۲۵۰ جدول ۸٬۵۰۰۰٬۰۰۰رکوردی داشته است.
تأخیر PolarFS برای ۴ هزار نوشتن تصادفی حدود ۴۸ میکروثانیه بوده است. این عدد به مقدار ۱۰ میکروثانیهٔ SSD محلی نزدیک و از ۷۶۰ میکروثانیهٔ CephFS بسیار بهتر است.
میانگین تأخیر نوشتن PolarFS ۱٫۶ تا ۴٫۷ برابر کندتر از ext۴ محلی است؛ در حالی که معیار مشابه CephFS ۶٫۵ تا ۷۵ برابر کندتر از ext۴ محلی است. این بدان معنی است که PolarFS کارایی‌ای نزدیک به ext۴ محلی ارائه می‌کند. نسبت میانگین تأخیر نوشتن ترتیبی PolarFS و CephFS به ext۴ نیز به‌ترتیب ۱٫۶ تا ۴٫۸ و ۶٫۳ تا ۵۶ است. مقادیر متناظر برای خواندن تصادفی به‌ترتیب ۱٫۳ تا ۱٫۸ و ۲ تا ۴ و برای خواندن ترتیبی به‌ترتیب ۱٫۵ تا ۸٫۸ و ۳٫۴ تا ۱۴٫۹ است.
کاهش کارایی PolarFS و CephFS نسبت به ext۴ برای درخواست‌های بزرگ (۱ میلیون) با درخواست‌های کوچک (۴ هزار) متفاوت است؛ زیرا شبکه و انتقال دادهٔ دیسک بیشتر زمان اجرای درخواست‌های بزرگ را به خود اختصاص می‌دهند.
پردازش ورودی خروجی با یک ماشین حالت محدود تک‌ریسمانه و پرهیز از سربار تغییر زمینه و زمان‌بندی مجدد
بهینه‌سازی مصرف حافظه و استفاده از مخزن حافظه برای کاهش سربار ساختن و نابود کردن اشیا
نگه‌داری کل فراداده در حافظهٔ اصلی
استفاده از RDMA در فضای کاربر و SPDK
از عوامل کارایی بسیار بهتر PolarFS نسبت به CephFS هستند.
در خواندن و نوشتن تصادفی، ext۴ محلی، PolarFS و CephFS همگی با تعداد کارهای (81) کلاینت مقیاس می‌شوند. گلوگاه گذردهی ext۴ گذردهی یک دیسک SSD محلی، گلوگاه گذردهی PolarFS پهنای باند شبکه، ولی گلوگاه گذردهی CephFS ظرفیت پردازش بسته‌های شبکه در آن است. گذردهی ۴ هزار نوشتن و خواندن در ext۴ محلی به‌ترتیب ۴٫۴ و ۵٫۱ و در PolarFS به‌ترتیب ۴ و ۷٫۷ برابر بیشتر از CephFS است.
برای خواندن و نوشتن ترتیبی، چه در فایل‌سیستم محلی و چه در فایل‌سیستم توزیع‌شده، یک دیسک به تقریباً تمام درخواست‌ها رسیدگی می‌کند. ext۴ و PolarFS به‌خوبی با تعداد کارهای کلاینت مقیاس می‌شوند تا به حدی برسند که گلوگاه ورودی-خروجی محدودشان می‌کند؛ حال آن که گلوگاه CephFS خود نرم‌افزار است و نمی‌تواند پهنای باند ورودی-خروجی را اشباع کند.
بدون ورودی-خروجی اضافهٔ تحت شبکه، گذردهی خواندن ترتیبی ext۴ محلی با یک کلاینت بسیار بیشتر از PolarFS و CephFS است. اما با افزایش تعداد کلاینت‌ها به دو کلاینت گذردهی خواندن ترتیبی آن به‌شدت افت می‌کند و به مقدار گذردهی‌اش برای خواندن تصادفی با دو کلاینت نزدیک می‌شود. نگارندگان این مشاهده را به خصیصه‌های NVMe SSD مورد استفاده نسبت داده‌اند. این NVMe SSD یک بافر DRAM داخلی داشته است. زمانی که سفت‌افزار (82) الگوی بار ورودی را خواندن ترتیبی حدس می‌زده است، بلوک دادهٔ بعدی را در این بافر پیش‌واکشی (83) می‌کرده است. نگارندگان حدس زده‌اند که سازوکار پیش‌واکشی با الگوی ورودی-خروجی غیردرهم‌آمیخته (84) بهتر کار می‌کند.
گذردهی POLARDB روی PolarFS به‌شدت به POLARDB روی ext۴ محلی نزدیک بوده است، حال آن که PolarFS دسترسی‌پذیری بالا با ۳ نسخه‌بدل را فراهم می‌کرده است. POLARDB روی PolarFS به گذردهی ۶۵۳ هزار خواندن در ثانیه، ۱۶۰ هزار نوشتن در ثانیه و ۱۷۳ هزار خواندن/نوشتن در ثانیه دست پیدا کرده است.
علاوه بر این مسأله، POLARDB از بهینه‌سازی‌های سطح پایگاه‌داده نیز استفاده کرده است تا از MySQL پیشی گیرد. این بهینه‌سازی‌ها خارج از حوزهٔ منبع [3] و گزارش حاضر است.
[1] Alibaba Tech 2018. Alibaba unveils PolarFS distributed file system for cloud computing. https://hackernoon.com/alibaba-unveils-new-distributed-file-system-6bade3ad0413.
[2] Cao, W. et al. 2020. POLARDB meets computational storage: Efficiently support analytical workloads in cloud-native relational database. 18th USENIX conference on file and storage technologies (FAST 20) (Santa Clara, CA, Feb. 2020), 29–41.
[3] Cao, W. et al. 2018. PolarFS: An ultra-low latency and failure resilient distributed file system for shared storage cloud database. Proc. VLDB Endow. 11, 12 (Aug. 2018), 1849–1862. DOI:https://doi.org/10.14778/3229863.3229872.
[4] Comfort, P. 2018. What is thin provisioning and should you use it? https://chicorporation.com/what-is-thin-provisioning-and-should-you-use-it/.
[5] Grøvlen, Ø. 2019. POLARDB: A database architecture for the cloud. https://www.slideshare.net/oysteing/polardb-a-database-architecture-for-the-cloud-151270517.
[6] Gulutzan, P. and Pelzer, T. 2003. SQL performance tuning. Addison-Wesley.
[7] Humborstad, T. 2019. Database and storage layer integration for cloud platforms. NTNU.
[8] Jun, H. 2018. PolarDB: Alibaba cloud’s relational database services architecture. https://www.alibabacloud.com/blog/579134.
[9] Amazon EC2 instance store. https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/InstanceStorage.html.
