بخشی از مقاله
چکیده - اخیرا، هدوپ - Hadoop - توجه محققین را به عنوان یک چهارچوب متن باز موثر و نوظهور برای مدیریت دادههای حجیم جلب کرده است. یکی از بخشهای مهم هدوپ، سیستم فایل توزیع شده آن است که می تواند مقادیر زیادی داده را با عملکرد و قابلیت اطمینان بالا مدیریت کند. این سیستم فایل توزیع شده از یک گره اصلی واحد به نام NameNode و تعدادی DataNode تشکیل میشود.
نکته مهمی که باید مورد توجه قرار گیرد، این است که به دلیل وجود یک گره واحد NameNode و همچنین به دلیل دریافت درخواست های متعدد از سمت کلاینت ها ، NameNode یک نقطه آسیب پذیر مرکزی - SPOF - است. در صورت از کار افتادن این گره دسترسی به کل فایلها غیر ممکن میشود. بنابراین باید تمام تلاش ممکن برای پایداری این گره انجام شود. در این مقاله چالش ها ، مشکلات ، راهکارهای مناسب و معماری های مختلف برای حفظ قابلیت دسترس پذیری و به تبع آن قابلیت اطمینان سیستم فایل توزیع شده هدوپ بررسی می شود.
-1 مقدمه
اخیرا، حجم دادهایی که نیاز به ذخیره، پردازش و نگهداری دارد، به دلیل وجود سرویس های ابری، سرویسهای شبکههای اجتماعی و فایلهای گوناگون ثبت وقایع، به سرعت در حال افزایش است. حجم این داده ها فراتر از حدی است که با ابزارهای مدیریتی و پایگاههای داده های سنتی بتوان در یک زمان قابل قبول، دریافت، ذخیره، مدیریت و پردازش کرد.[1] هنگامی که حجم، تنوع و سرعت دادهها در یک مجموعه داده به حدی زیاد میشود که دیگر یک ماشین به تنهایی قادر به پردازش و ذخیره سازی آن نیست، بحث پارتیشن بندی داده و تقسیم آن بروی چندین ماشین مجزا مطرح میگردد.
سیستم فایل هایی که مدیریت ذخیره سازی اطلاعات در سطح شبکهای از ماشینها را عهده دار هستند، سیستم فایلهای توزیع شده مینامند. از آنجایی که آنها بر پایه مباحث شبکه طراحی میشوند، لذا تمامی پیچیدگیهای برنامه نویسی شبکه میبایست مورد بررسی قرار گرفته شود، از این رو ایجاد سیستم فایل های توزیع شده بسیار پیچیده تر از تولید سیستم فایل های معمول میباشند. برای مثال، یکی از چالشهای موجود در این نوع سیستم فایل ها امکان مواجه شدن با خرابی نود بدون از دست رفتن داده میباشد.[13] در این مقاله ، سیستم فایل توزیع شده لایه ذخیره سازی هدوپ و همچنین چالش ها و راهکارهای ارتقای قابلیت دسترس پذیری آن بررسی می شود.
-1-1 هدوپ
هدوپ یک چهارچوب متن باز مبتنی بر جاوا است که برای تقسیم بندی و توزیع فایل های متمرکز به کار می رود .[2] در واقع هدوپ را می توان به ابزاری تشبیه کرد که طراحی شده تا بتواند حجم زیادی از داده ها را بر روی ماشین های مختلف پردازش و مدیریت کند. فریم ورک هدوپ شامل زیر پروژه های مختلفی می شود.[14] این چهارچوب برای پردازش موازی داده ها در سطح پتابایت و اگزابایت که بر روی رایانههای معمولی توزیع شده اند، به گونهای طراحی شده است که کلاستر تشکیل دهنده آن به راحتی و بسته به نیاز، قابل گسترش است.[2]
-2-1 معماری هدوپ
هدوپ دارای دو لایه اصلی پردازش و ذخیره سازی است.[3] سیستم فایل توزیع شده لایه ذخیره سازی هدوپ است که از مقیاس پذیری و کارایی بالایی برخوردار است.[4] برای بالابردن کارایی دسترسی ، فایل ها را در نزدیک ترین شبکه به سرویس گیرنده در شبکه ای مشابه تکثیر می کند. در این سیستم فایل به دلیل وجود یک نود اصلی که وظیفه دریافت درخواست کلاینت ها را بر عهده دارد خطر از دست دادن داده ها و وجود مشکل SPOF1 وجود دارد. نگاشت - کاهش2 مدل برنامه نویسی موازی برای نوشتن نرم افزارهای توزیع شده است که بروی هدوپ اجرا می شود. این مدل قادر به پردازش و محاسبات حجم بالای داده ها بروی چندین کلاستر با قابلیت اطمینان و مقاوم در برابر خطا است.[4]
-2 سیستم فایل توزیع شده هدوپ
معماری سیستم فایل توزیع شده هدوپ بسیار به سیستم فایل گوگل نزدیک است و از ساختار سه لایهای و تک مرجع آن پیروی میکند. وظیفه تقسیم، ذخیره و بازیابی فایل های حجیم بر روی یک کلاستر هدوپ را سیستم فایل توزیع شده آن بر عهده دارد. هدوپ سه نوع گره محاسباتی یا رایانه دارد. مدیر نام، وظیفه تقسیم فایل ها و ذخیره آدرس هر بخش از آن را برعهده دارد.[3] بررسی دورهای گرهها و تعیین از رده خارج شدن آنها هم جزء وظایف این مولفه از سیستم مدیریت فایل هدوپ است. گره داده که تک تک رایانه های عضو هدوپ را در بر می گیرد، بلاک های فایل را در بردارد که برای مدیریت بهتر آنها، به ازای مجموعه ای از این گرههای داده ، یک گره مدیریت نام در سامانه هدوپ وجود دارد. نوع سوم، گره نام ثانویه3 است که یک رونوشت از اطلاعات گره مدیریت نام بر روی آن قرار دارد تا در صورت از کار افتادن آن گره، اطلاعات آن از بین نرود.[5]
-1-2 سرور NameNode
هر کلاستر یا خوشه از هدوپ، یک سرور مرجع دارد که NameNode نامیده میشود که مسئول ذخیره سازی متادیتا و کنترل کل سیستم استNameNode .[3] با دو فایل اصلی تصویر فضای نام4 و گزارش تغییرات5 کار می کند. تصویر فضای نام یک تصویر از فایل سیستم در زمان راه اندازی اولیه است و گزارش تغییرات ترتیبی از تغییرات سیستم فایل را بعد از زمان راه اندازی نگه داری می کند.[4] در زمان راه اندازی مجدد NameNode تمامی تغییرات موجود در گزارش تغییرات بر روی تصویر فضای نام اعمال می شود. این سرور مسئول ردیابی متادیتا است و آدرس و وضعیت کپیهای مربوط به هر یک از بلاکهای 64 مگابایتی داده را نگهداری میکند.
-2-2 سرور DataNode
داده ها بر روی سرور های DataNode ذخیره می شود و از طریق NameNode در محیط کلاستر کپی میشوند و DataNode مسئولیت نوشتن و خواندن داده را بر عهده دارند. به طور پیشفرض هر بلاک داده، سه بار کپی میشود اما میتوان از طریق تغییر تنظیمات کلاسترها، تعداد کپیها را نیز تغییر داده.[3] بعد از توزیع داده ها در سامانه هدوپ تحلیل و پردازش آنها بر عهده بخش نگاشت و کاهش آن است. در مرحله اول،کاربر درخواست خود را که معمولاً یک پرس و جو به زبان جاواست را به گرهی که وظیفه اجرای درخواست ها را بر عهده دارد، مدیر درخواست6 ارسال میکند .[6] شکل 1 شمایی کلی از معماری سیستم فایل توزیع شده هدوپ را نشان می دهد.
-3-2 قابلیت در دسترس پذیری در سیستم فایل توزیع شده هدوپ
مواردی که جهت دسترس پذیری بالای 1HDFS برای طراحی سیستم توزیع شده باید در نظر گرفت شامل شفافیت، انعطاف پذیری، قابلیت اطمینان، کارایی خوب و قابلیت گسترش است. در دسترس بودن در معماری هدوپ از اهمیت خاصی برخوردار است.[7] طراحی نباید به گونهای باشد که نیاز به اجرای همزمان کامپوننتهای اساسی باشد. افزونگی بیشتر دادهها باعث افزایش در دسترس بودن شده اما ناسازگاری را بیشتر میکند. قدرت تحمل خطا2 باعث پوشاندن خطاهای ایجاد شده توسط کاربر میشود.[8]
-3 چالشهای سیستم فایل توزیع شده هدوپ
سیستم فایل توزیع شده هدوپ، فراداده و دادههای برنامهها را به صورت جداگانه ذخیره میکند. این سیستم فایل از کارایی بالایی برخوردار است. برای بالابردن کارایی دسترسی، فایلها را در نزدیکترین شبکه به سرویس گیرنده در شبکهای مشابه تکثیر میکند. HDFS به دلیل وجود یک NameNode اصلی، دارای مشکلات SPOF ، محدودیت فضای نام و عدم توازن بار میباشد. در صورتیکه اطلاعات NameNode از بین برود از آنجا که متادیتای کل فایلها هم از بین رفته است، در واقع دسترسی به کل فایلهای ذخیره شده روی کلاستر ناممکن خواهد شد.
یک مسئله دیگر این است که NameNode برای پردازش لحظهای درخواستها، تمامی iNode های موجود در حافظه محلی را نگهداری میکند. بنابراین اندازهی فضای نام NameNode به اندازهی حافظهی محلی در NameNode محدود میشود. به عنوان مثال برای ذخیره کردن 100 میلیون فایل، یک NameNode بایستی حداقل 60 گیگا بایت رم داشته باشد. همچنین از آنجایی که تمامی درخواستها از سوی مشتریان توسط NameNode دریافت و پردازش میشود، این مسئله باعث ایجاد گلوگاه میشود و نیاز به روش های توزیع بار به نظر می رسد که یه مسئله جدی است.[9]
-4 راهکارها
از نظر قابلیت دسترسی، مشکل SPOF در NameNode، یک مشکل بحرانی است. در ارتباط باغیرقابل دسترس شدن کلیِ کلاستر دو حالت زیر را می توان در نظر گرفت: در حالت اول به دلیل رخداد رویداد برنامهریزی نشده ای مثل درهم شکستن ماشین3 که در این صورت کلاستر، تا زمانی که یک اپراتور، NameNode را به صورت دستی راهاندازی مجدد کند، غیرقابل دسترس میشود. حالت دوم به این شکل است که رویدادهای نگهداری برنامه ریزی شده، همچون ارتقا سختافزاری و نرمافزاری بر روی ماشین NameNode باعث از کار افتادگی پنجرههای کلاستر میشود.
در هدوپ ورژن 1، یک NameNode ثانویه و یک NameNode پشتیبانی را برای ذخیره کردن گزارشات پردازش در NameNode، معرفی میکند. زمانی که NameNode خراب میشود، با استفاده از همین گزارشات ذخیره شده بازیابی شود. اگرچه بازبینی خطاها و بازیابی HDFS تنها با اعمالی دستی مدیر سیستم امکانپذیر است. در هدوپ ورژن 2 یک NameNode فعال در نظر گرفته میشود و یک NameNode جانشین که وضعیتش را همگام با NameNode فعال نگه میدارد تا بتواند یک Failover را فراهم کند.
وقتی NameNode فعال خراب میشود، NameNode جانشین، وظایف NameNode فعال را تحویل میگیرد. اگرچه برای همگام سازی NameNode ها، یک فضای مشترک ذخیره بین این دو نیاز است که گزارشات ویرایش بروی فضای ذخیره سازی مشترک ذخیره می شود که این باعث ایجاد SPOF جدید می گردد. بنابراین قابلیت اطمینان فضای مشترک ذخیره بایستی با استفاده از تکنولوژی RAID و یا متعدد کردن شبکه، دست یافت تا دسترسی بالای HDFS تضمین شود.[10]
-1-4 استفاده از فضای ذخیره سازی اشتراکی NFS
زمانی که تغییر در فضای نام سیستم فایل هدوپ بر روی گره NameNode فعال رخ میدهد این تغییر در غالب یک رکورد بر روی فایل گزارش تغییرات درون فضای اشتراکی نوشته خواهد شد. به صورت همزمان گره NameNode آماده دایرکتوری اشتراکی حاوی رکوردهای گزارش تغییرات را میبیند و زمانی که رکورد گزارش تغییرات ثبت شد، گره NameNode آماده این تغییرات را بر روی فضای نام خود اعمال میکند.[3]
