سیستم فایل GFS- قسمت دوم

Facebooktwittergoogle_pluspinterestlinkedinmail
Print Friendly, PDF & Email

2.3 معماری

یک کلاستر GFS  شامل یک Master و چندین chunkserver می باشد که توسط چندین کاربر مورد استفاده قرار می گیرند. هرکدام از این سرورها ماشین های ساده لینوکس برای پردازش درخواست های کاربران می باشند. امکان اینکه بر روی یک ماشین هم chunkserver فعال باشد و هم client داشته باشیم به راحتی قابل انجام است البته تا جائیکه منابع ماشین کفایت کنند و کدها مناسب و بهینه باشند.

فایل ها به تکه های با اندازه ای ثابت تقسیم بندی شده اند. هر تکه توسط یک chunk handle 64 بیتی بدون تغییر و یکتا در تمام دنیا توسط master در زمان تولید آن تکه به آم داده شده است شناخته می شود. Chunkserver  ها این تکه های را شبیه فایل های لینوکس در دیسک های محلی خود ذخیره می کنند و توسط همان chunk handle بصورت بایتی عملیات read و write را بر روی آن ها انجام می دهند. برای قابلیت اطمینان، هرتکه بر روی چند chunkserver کپی سازی می شود/ بطور پیش فرض 3 کپی از هر تکه نگهداری می شود اما خود کاربر می تواند تعداد کپی های مورد نظر خود را وارد کند.

Master  وظیفه نگهداری تمامی متاداده ها را برعهده دارد. این متاداده ها شاملnamespace، اطلاعات کنترل دسترسی، نگاشت فایل ها به تکه ها و موقعیت فعلی تکه ها می شود. Master همجنین وظیقه کنترل فعالیت های سیستم درحد وسیع مثل مدیریت در اختیار گذاشتن تکه ها را نیز عهده دار است.جمع آوری زباله های تکه های بدون پدر و همچنین مهاجرت تکه ها بین chunkserverها بر عهده master  می باشد. Master بطور منظم در بازه های زمانی خاص با هر chunkserver ارتباط برقرار می کند و پپام Heartbeat را ارسال می کند تا  دستورات خود را به آن سرور بدهد و حالت سرور را در پاسخ دریافت کند.

کد GFS لینک شده درون نرم افزار کاربر درواقع API سیستم فایل را پیاده سازی می کند که در این حالت عملیات خواندن و نوشتن مورد نظر کاربر توسط master و chunkserver ها عملیاتی می شوند. کاربران برای عملیات های متاداده ای با master ارتباط برقرار می کنند اماتمام ارتباط داده ای مستقیم به chunkserverها می رودو ما Phosix API را ارائه نمی کتیم پس نیازی به وصل شدن به لایه vnode لینوکس نداریم. هیچکدام از کاربران و chnkserverها داده ای را کش نمی کنند. کش در سمت کاربران مزایایی دارد چون اکثر نرم افزارها با داده های با حجم بالا سروکار دارند که ارزش کش شدن را ندارند (اما کاربران متاداده ها را کش می کنند). Chunkserverها نیز نیازی به کش کردن ندارند چون تکه ها بعنوان فایل های محلی ذخیره می شوند و کش بافر خود لینوکس لیست دسترسی به داده ها را درون خود نگه می دارد.

2.4 Single Master

داشتن تنها یک Masteer باعث ساده تر کردن کار طراحی و اجازه دادن به master برای جایگذاری تکه ها بدون دردسر و تصمیم گیری درباره کپی سازی ها با آگاهی از کل سیستم شده است. اما باید تا جائیکه امکان دارد درگیری master از خواندن و نوشتن را کاهش دهیم تا یک گلوگاه برای ما نشود. کاربراین هیچگاه فایل ها را از طریق master نه می خوانند و نه می نویسند. بجای این کار کاربر تنها از master می پرسد که با کدام chunkserverها باید ارتباط برقرار کند تا فال های مورد نظر را بیابد. سپس کاربر این اطلاعات را برای مدت زمان محدود نگهداری می کند و چندین عملیات را با chunkserver انجام می دهد.

بکذارید تا اتفاقات رخ داده در یک خواندن ساده با ارجاع به شکل 1 را برای شما توضیح دهیم. در ابتدا بباستفاده از اندازه ثابت تکه ها، کاربر نام فایل همراه با آفست بایتی لازم توسط نرم افزار ترجمه می کند و اندیس تکه مورد نظر از فایل را پیدا می کند. سپس درخواستی حاوی این اندیس تکه مورد نظر از فایل ره برای master ارسال می کند. Master  آدرس chunkserver را به همراه موقعیت کپی ها در پاسخ ارسال می کند. کاربر این اطلاعات را با نام فایل بعنوان کلید کش می کند. سپس کاربر درخواستی به نزدیک ترین chunkserver ارسال می کند. این درخواست حاوی شماره تکه و محدوده بایتی مورد نیاز می باشد. تاوقتیکه اطلاعات کش شده در کاربر هنوز وجود دارند، دیگر برای برقراری ارتباط با این تکه از فایل نیازی به تماس با master نیست. درواقع کاربر در هر درخواست اولیه از masterآدرس چندین تکه را می خواهد و master با سرعت بالا همه اطلاعات را در اختیاز وی قرار می دهد.

2.5 اندازه چانک ها

اندازه تکه ها یکی از کلیدهای اصلی در طراحی می باشد. ما اندازه 64 مگابایت را برگزیدیم که از اندازه یک بلاک روی سیستم فایل ها بزرگتر است. هرکپی از تکه ها بعنوان بک فایل خام لینوکس روی chunkserver ذخیره می شود و تنها در مواقع نیاز مورد استفاده قرار می گیرند.

اختصاص فضای lazy مانع از هدر رفتن فضا به علت فرگمنت کردن داخلی می شود که یکی از بزرگترین مشکلات پیش روی تکه های با سایز بسیار بزرگ می باشد.

تکه با اندازه بزرگ چندین مزیت دارد. اول از همه اینکه تعداد تعاملات کاربر با master برای انجام عملیات های مختلف خواندن و نوشتن روی تکه کاهش می بابد. چرا که کاربر تنها نیازمند ارتباط برای بار اول می باشد. این کاهش برای ما بسیار چشمگیر می باشد چراکه نرم افزارهای مورد استفاده بطور مداوم درحال خواندن و نوشتن فایل ها هستند. حتی باری خواندن های تصادفی در مقیاس کوچک کاربر به راحتی می تواند اطلاعات chunkserver مربوط به جندین ترابایت مجموعه داده را در خود کش کند. دومین مزیت این است که از آنجائیکه درون یک تکه بزرگ کاربر نیازمند انجام عملیات های مختلف می باشد، تاثیر زیادی بر روی سربار ترافیکی روی شبکه و ایجاد یک اتصال پایای TCP با chunkserver برای یک مدت زمان معلوم می شود. سوم اینکه این اندازه بزرگ تکه ها باعث کاهش حجم متاداده های روی master می شود و این امکان به ما اجازه ذخیره سازی متاداده ها در حافظه را می دهد که در بخش 2.6.1 درباره آن صحبت خواهیم کرد.

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

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

2.6 متاداده

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

این مطلب ادامه دارد….

مطالعه قسمت اول مطلب سیستم فایل GFS

مطالعه قسمت دوم مطلب سیستم فایل GFS

شما احتمالا این مطالب را نیز دوست دارید...

۳ بازخورد

  1. لاله می‌گه:

    درسیستم فایل گوگل (GFS) چه سبک هایی و برای مقابله با چه چالشهایی با هم ترکیب شده است

پاسخ دهید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *