فاجعه راید در عصر کلان داده‌ها و راه حل آن

مقدمه

طراحی مفهوم RAID یا آرایه منعطف با استفاده از دیسک های ارزان قیمت (Redundant Array of Inexpensive Disks) به حدود سال های 1980 میلادی می رسد. در آن سال ها دیسک هایی که امروزه Enterprise نامیده می شوند و سرعت بالاتر و مقاومت بیشتری در مقابل از دست دادن اطلاعات داشتند، بسیار گران قیمت بودند.

به تدریج محققین شروع به تحقق این ایده کردند که اطلاعات را بین تعداد بیشتری دیسک ارزان قیمت تر تقسیم کند و از این طریق به سرعت و پایداری بیشتر برسند. این پایه تکنولوژی به نام راید شد که پایه صنعت استورج دنیا برای سالهای بعد را تشکیل داد.

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

اما نقاط ضعف طراحی راید برای عصر Big Data چیست؟

ضعف طراحی برای تعداد هارد کم

راید در زمانی طراحی شد که 5 عدد هارد 10 گیگابایت عدد فوق تصوری بود! به همین خاطر طراحی هارد برای تعداد کم، و از دست رفتن یک یا دو دیسک طراحی شده است.

میلیون‌ها دیسک گوگل

در راید 5، از بین رفتن یک هارد در آرایه و در راید 6، از دست رفتن دو دیسک در آرایه قابل جبران است، و اطلاعات را می توان هنوز استفاده کرد. بصورت عادی یک آرایه معمولا بیشتر از 10 دیسک نیست، چون در صورت افزایش تعداد دیسک های آرایه، امکان از بین رفتن بیشتر از یک یا دو دیسک که آستانه تحمل آرایه است وجود دارد و در نتیجه کل اطلاعات از بین خواهد رفت. البته واقعیت این است که حتی در آرایه های کوچک هم نمی توان اطمینان حاصل کرد که همزمان دو یا سه دیسک با هم از کار نیافتند، چون وقتی دیسک های یک آرایه با هم شروع به کار می کنند امکان، با هم خراب شدن آنها هم بیشتر میشود.

این عدد برای یک مجموعه کوچک با 30 تا 40 عدد هارد قابل قبول است، اما با افزایش تعداد هارددیسک ها دیگر این روش مقدور و ممکن نیست. مثلا در جایی که هزار عدد دیسک وجود داشته باشد، دیگر نمی توان هر ده تای آنرا یک دسته کرد و دو تای هر دسته هم به عنوان Redundancy باشند. علاوه بر این با افزایش تعداد هارددیسک ها احتمال Fail شدن هاردها هم بیشتر میشود. حال وقتی به ابعاد میلیون‌ها هارددیسک گوگل نگاه می کنیم متوجه می شویم که دیگر چیزی به اسم راید اصلا ممکن نیست!

ضعف طراحی برای حجم کم

راید در زمانی طراحی شد که حجم 10 گیگابایت برای هارددیسک عدد بزرگی بود! در این حالت، زمان Rebuild آرایه وقتی که یک هارد خراب می شد خیلی طولانی نبود.

اما با افزایش سریع حجم هارددیسک ها، در زمانی که امروزه هاردهای 6 و 8 ترابایت در حال عرضه به بازار هستند، این زمان Repair بسیار طولانی شده است. در حال حاضر در بیشتر سیستم های راید با پاریتی، مثلا راید 5، اگر سرعت Repair در حالت High Performance تنظیم شود، زمان Repair گاهی تا چهل و هشت ساعت و بیشتر طول می کشد، و در ضمن Performance سیستم استورج هم 50 درصد کاهش می یابد. این کاهش پرفورمانس یا زمان بالا در راید 6 حتی بدتر از RAID 5 است.

از آنجا که این مقدار کاهش پرفورمانس قابل قبول نیست، معمولا عملیات Rebuild بصورت بک گروند تنظیم می شود تا حداقل کاهش Performance را ایجاد کند، اما این باعث می شود زمان Rebuild گاهی تا هفت برابر بیشتر شود، و اگر در این زمان یک دیسک دیگر هم از آرایه به مشکل بخورد، کل اطلاعات آرایه از بین خواهد رفت!

ضعف طراحی فقط برای Block Level Access

سیستم راید همه دیسک های زیر مجموعه خودش را با هم یکی میکند و بصورت یک Block Level Access Device یا به زبان ساده تر یک دیسک بزرگ خود را به سیستم عامل کامپیوتری که به آن متصل است نشان می دهد. در این حالت روی این مجموعه دیسک ها، LUN (Logical Unit) تعریف می شود که هر لان بصورت یک دیسک توسط سیستم عامل دیده میشود. بسیاری از کنترلرهای راید، امکان ایجاد LUN های بزرگتر از 32 یا 64 ترابایت ندارند و در نتیجه سیستم عامل هیچ وقت دیسکی بزرگتر از این مقدار نخواهد دید. این اندازه تا زمانی که شما با دیتابیس یا ایمیل سرور سر و کار دارید مشکل ساز نیست، اما وقتی با یک آرشیو ویدئویی یا یک مجموعه بک آپ با سایز صدها ترابایت سر و کار دارید، مشکل بزرگی به نام تعداد زیادی درایوهای مجزا از هم ایجاد میشود، که حالا شما مجددا باید برای یکی کردن آن آنها و دیدن یکجای آنها فکر کنید.

ضعف طراحی وابسته به سخت افزار خاص

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

سخت افزار تجاری در گوگل

به همین خاطر است که در انواع RAID حداقل دیسک قابل استفاده NearLine SAS یا Enterprise SATA است، زیرا یک هارد دیسک دسکتاپ زمان پاسخ مشخصی به درخواست ها ندارد و باعث عملکرد ناصحیح کنترلر راید می شود. (زمان TLER برای هارد راید باید زیر 7 ثانیه باشد، اما این زمان برای هارددیسک دسکتاپ گاهی تا دودقیقه نیز بالا می رود).

اما قیمت یک هارد NL-SAS یا Enterprise SATA حداقل سه برابر قیمت هارددیسک دسکتاپ معادل آنها است، که باعث افزایش شدید هزینه استورج می شود. علاوه بر این به خاطر مشکلی که Write Hole نامیده میشود، الگوریتم راید معمولا روی سخت افزارهای خاصی پیاده می شود که این سخت افزار بخش مهمی از قیمت مجموع استورج را تشکیل می دهد و فقط هم در صورت خرابی باید با قیمتی که سازنده سخت افزار مشخص می کند و سخت افزار خاص او جایگزین شود.

ضعف طراحی بدون در نظر گرفتن حداکثر پرفورمانس فضا

بصورت عادی در یک آرایه راید 5 حدود ۲۰ تا ۲۵ درصد فضا به داده Parity اختصاص می یابد. اگر هدف استفاده از آرایه RAID 6 برای حفاظت بیشتر از اطلاعات باشد، مقدار فضای اختصاص داده شده به پاریتی به ۲۵ تا ۳۵ درصد می رسد. با این همه مشکل اصلی که وجود دارد، این است که با وجود هدر رفتن این مقدار از حافظه، هنوز مقدار حفاظتی که وجود دارد فقط به اندازه یک یا دو دیسک به ازای هر ۵ الی شش دیسک یک آرایه است. به عبارت دیگر، حتی در یک مجموعه ۱۰۰۰ دیسکی که از صد آرایه هر کدام با ۱۰ دیسک RAID 6 شده تشکیل شده باشد (۸ تا دیتا و ۲ تا Parity)، با وجود تخصیص ۲۰۰ دیسک به پاریتی، چون پاریتی مربوط به یک آرایه است،‌ فقط از دست رفتن دو دیسک به ازای هر آرایه قابل تحمل است، و در غیر اینصورت اطلاعات آن بخش از بین میرود.

ضعف طراحی بدون توجه به دردسرهای نگهداری

در یک آرایه RAID وقتی که یک دیسک آرایه دچار مشکل می شود، مدیر سیستم باید به سرعت نسبت به تعویض آن اقدام کند تا عملیات Rebuild بلافاصله شروع شود. اگر مدیر سیستم نسبت به این مسئله آگاه نباشد یا اینکه دیر اقدام کند،‌ هر لحظه امکان از بین رفتن یک دیسک دیگر و از بین رفتن کل اطلاعات وجود دارد. برای حل این مشکل می توان از دیسکی که به عنوان Hot Spare اختصاص داده میشود استفاده کرد، اما این به معنی مصرف کردن تعداد خیلی زیادی دیسک (و bay کنترلر) در سیستم است. این مشکل را در کنترلرهای گران قیمت تر می توان با Global Hot Spare تا حدی کم رنگ تر کرد، اما به عنوان یک قاعده کلی باید در یک سیستم راید به سرعت نسبت به تعویض هارد معیوب اقدام کرد تا امکان از بین رفتن کل دیتا کمتر شود.

ضعف طراحی بدون توجه به افزایش داده

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

ضعف طراحی بدون توجه به نابودی خاموش دیتا روی دیسک

از مدت ها پیش مشخص شده است که اطلاعات روی هارددیسک به خاطر عوامل متعددی دچار خرابی و خطا می شود. عواملی همانند اشعه های کیهانی و باگ فرم ویر هارددیسک ها از جمله دلائل بروز این خطا هستند. هر چند مقدار این خطا توسط سازندگان دیسک یک در هر ده به توان 16 بیت اعلام شده است، اما تحقیقات CERN نشان می دهد که مقدار واقعی این خطا خیلی بیشتر از مقدار اعلام شده است. در ضمن با افزایش تصاعدی حجم اطلاعات نگهداری شده توسط بشر، همین مقدار ناچیز خطا به عدد بزرگی تبدیل می شود، طوری که CERN مقدار این خطا را در یک آرایه 97 پتابایتی (97 هزار ترابایتی) برابر 120 گیگابایت ارزیابی کرده است. این پدیده که به خرابی خاموش داده ها (Silent Data Corruption) مشهور است، در مواردی مانند داده های بانکی اهمیت بالایی پیدا میکند، زیر حتی یک بیت خراب هم می تواند به معنی جابجایی حجم بالایی پول در حساب یک مشتری باشد!

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

ضعف طراحی با گلوگاه کنترلر

نقطه ضعف دیگری که در طراحی راید وجود دارد، گلوگاهی به نام کنترلر است. در هر سیستم راید این وظیفه کنترلر است که اطلاعات را بین دیسک های آرایه راید هنگام نوشتن تقسیم کند، و هنگام خواندن دوباره به هم بچسباند. این باعث می شود که کنترلر راید، باعث به گلوگاه (Bottleneck) سیستم، هم از نظر Performance و هم از نظر Redundancy شود. به عبارت دیگر سرعت نوشتن و خواندن در سیستم راید، وابسته به سرعت کنترلر (هم سرعت Interface و هم سرعت داخلی Internal) می شود، و اگر کنترلر از کار بیافتد، کل سیستم راید و اطلاعات روی آن هم غیر قابل دسترسی خواهد بود.

اگرچه در سیستم های راید گران قیمت تر معمولا طراحی سیستم بصورت Dual Controller و Multi Path است، اما با این وجود محدویت هایی که قبلا به آن اشاره شد باقی می ماند. به عنوان مثال حتی اگر کنترلر توانایی اتصال هزاران دیسک هم در JBOD های جدید به خودش داشته باشد، با هرچقدر افزایش دیسک، باز سرعت مجموع از سرعت داخلی و اینترفیس کنترلر بیشتر نخواهد شد.

کنترلر معمولا محدودیت های دیگری هم به سیستم اعمال می کند. به عنوان مثال خیلی از کنترلرهای رده متوسط (Mid-Range) نمی توانند بیشتر از یک عدد مشخص (مثلا 192 درایو) متصل به خود داشته باشند و بعد از آن باید اقدام به خرید کنترلر جدید کرد.

ضعف وابستگی عمدی به سازنده

چه کلاف در هم تنیده‌ای

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

اما چه باید کرد؟

تمام آنچه که در مورد تکنولوژی راید گفته شد، طراحان سیستم را به فکر طراحی سیستم هایی انداخت، که دارای مشکلات طراحی RAID نباشند. تمام این طراحی های جدید، که Xendure یکی از پیشتازان آن است، بر مبنای استفاده از سیستم های Distributed برای دستیابی به فضای ذخیره سازی پتابایت به بالا است.

سیستم Xendure همه مشکلات گفته شده در طراحی راید را با مزایای طراحی خود حل کرده است:

طراحی برای حجم نامحدود و تعداد هارد نامحدود: سیستم Xendure بر مبنای تفکر Distributed نودهای متصل به شبکه طراحی شده است. این سیستم با هدف تعداد هارد و حجم بسیار بالا طراحی شده است و بر خلاف سیستم راید، مزایای سیستم با افزایش تعداد هارد و حجم بهتر خود را نشان می دهند. تعداد هزاران هارد و ده ها پتابایت استورج در یک کلاستر Xendure یک عدد عادی و کوچک به شمار می رود.

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

طراحی برای دسترسی یکپارچه و فایلی: سیستم Xendure برای دسترسی به فایل، آن هم فایل های بزرگ طراحی شده است. در این سیستم روش های متعددی مانند REST API, Mount File System و SDK در نظر گرفته شده است تا کاربر به راحتی بتواند به فایل های خود دسترسی پیدا کند. در سیستم Xendure چیزی به نام LUN یا پارتیشن وجود ندارد و به جای آن از مفهوم Namespace استفاده میشود، مفهومی که اجازه می دهد همه فضای چند پتابایتی یک کلاستر یکجا دیده شود.

طراحی برای استفاده از سخت افزار در دسترس و بدون وابستگی: سیستم Xendure با استفاده از سخت افزار در دسترس و موجود در بازار طراحی شده است. هیچ قسمتی از Xendure از سخت افزار خاص استفاده نمی کند و بنابراین با بروز اشکال در هر بخش سیستم، به راحتی می توان آنرا با یک قطعه جایگزین که از بازار قابل تهیه است جابجا کرد. به عبارت دیگر وابستگی به سخت افزار یک تولید کننده خاص وجود ندارد و کسی نمی تواند قیمت های گزافی را به خاطر انحصاری بودن محصولش دریافت کند. علاوه بر این استفاده از سخت افزار در دسترس و متداول باعث می شود آموزش و مدیریت سیستم نیازی به یک منحنی آموزشی سخت (Steep Learning Curve) نداشته باشد و مدیر سیستم با آشنایی هر روزه با مفاهیم آی پی و سخت افزار و سیستم عامل، بتواند به راحتی از سیستم استفاده کند.

طراحی با توجه به حداکثر استفاده از فضا و حداکثر حفاظت داده: در سیستم Xendure بر خلاف سیستم های عادی RAID، از الگوریتم خاص این سیستم به نام BitExpander برای حفاظت از داده استفاده می شود. الگوریتم بیت اکسپاندر، الگوریتم خاصی است که اجازه حفاظت از اطلاعات در ابعادی که قبلا غیر قابل تصور بود می دهد. به عنوان مثال اگر از این الگوریتم با حفاظت 16 به 20 استفاده شود، دیتا به 16 قسمت تقسیم شده و بعد به 20 قسمت افزایش می یابد، طوری که اگر 4 قسمت آن هم از بین برود باز اطلاعات قابل برگرداندن است.

این یعنی از یک مجموعه 20 دیسکی، حتی اگر 4 دیسک هم همزمان با هم از کار بیافتند، اطلاعات باز هم قابل برگرداندن است. یعنی با مصرف کمتر از 20 درصد فضا برای حفاظت، ضریب حفاظتی نزدیک به صد درصد حاصل شده است! علاوه بر این کل زنجیره Xendure از یک چک سام 160 بیتی برای بررسی سالم بودن دیتای ذخیره شده استفاده می کند که از دیتا در مقابل Silent Data Corruption محافظت می کند. علاوه بر این در سیستم Xendure می توان فایل ها را با ضرائب حفاظت مختلفی نگهداری کرد. یعنی مثلا یک فایل را با ضریب حفاظت 16/20 و یک فایل مهمتر دیگر را با ضریب حفاظت 10/20 (نگهداری اطلاعات روی 20 دیسک همزمان، طوری که اگر 10 دیسک همزمان هم از کار بیافتند، هنوز هم اطلاعات در دسترس باشد).

طراحی با هدف مدیریت راحت سیستم: کل عملیات مدیریت سیستم از طریق یک واسط گرافیکی وب (Web GUI) یا واسط خط فرمان (CLI) قابل مدیریت است. افزایش یا کاهش تعداد هارد یا نود در سیستم بسیار راحت است. علاوه بر این، با افزایش هر نود یا هارد دیسک، ظرفیت آن بصورت آنی، و بدون نیاز به هیچ تغییری در سیستم دیده شده و قابل استفاده است. در صورت خرابی یک دیسک یا نود سیستم بصورت خودکار شروع به Rebuild آن در فضای خالی سیستم می کند و نیاز به هیچ اقدامی از سوی مدیر سیستم نیست. کل سیستم از سخت افزار متعارفی که مدیر یک سیستم IT با آن آشنا است استفاده می کند و بنابراین یادگیری و نگهداری آن بسیار راحت است.

در مجموع Xendure یک سیستم استورج طراحی شده برای Big Data است، که مشکلات طراحی جاری راید در آن بصورت بنیادی برطرف شده است.