دانلود مقاله بررسی فایل سیستم گوگل

در این مقاله قصد داریم پس از اشاره مختصر به سیر تحولات گوگل به بررسی فایل سیستم گوگل بپردازیم و در ادامه نگاهی اجمالی به معماری GFS خواهیم داشت
فایل سیستم توزیع شده، مهمترین جزء یک سیستم توزیع شده ی که تا حالا تحقیقات و فعالیتهای زیادی در این مورد انجام گرفته که معروفترینش NFS فایل سیستم شبکه محصول شرکت Sun Microsystems است.

هدف اصلی NFS این که فایل سیستمهای مختلف موجود شبکه رو جمع آوری میکنه و پروتکلی رو معرفی می کنه که هر کدوم از فایل سیستمها با رعایت اون می تونند جزئی از مجموعه کلاستر NFS باشن و اطلاعات خودشون و به اشتراک بذارن
یکی دیگه از فایل سیستمهای موجود Coda محصول دانشگاه کارنگی ملون
Carnegie Mellon که هدف اصلیش افزایش میزان دسترسپذیری و به این منظور دادههای
فایل در حافظه Cache کامپیوتر کلاینت نگهداری می شن
LBFSهم یک فایل سیستم توزیع شده برای شبکههایی که پهنای باند کمی دارن که این فایل سیستم با استفاده از تکنیکهای فشردهسازی و نگهداری دادههای رسیده در حافظه cache به شدت از ترافیک شبکه کم می کنه.
فایل سیستمهای توزیع شده دیگه ای هم وجود دارن که می تونیم به AFS، ۹Plan ، XFS، SFS ، فرانگی پانی اشاره کرد
اما هیچ کدوم از این فایل سیستمهای موجود بهطور کامل نیازمندیهای گوگل رو برطرف نمی کنن در سایت گوگل فایل های چند ترابایتی وجود داره که نمی شه اونها را به تنهایی در سرورهای سایت گوگل که خودشون تشکیل شده ان از هزاران کامپیوتر معمولی ذخیره کرد.

از طرف دیگه تقسیم این فایلهای حجیم به هزاران فایل کوچکتر هم باعث پیچیدگی و کاهش کارآیی برنامهها میشه.
بنابراین گوگل برای رفع نیازمندیهاش و با توجه به شرایط محیطی خودش، فایل سیستم گوگل (GFS) را طراحی و پیادهسازی کرد
GFS علاوه بر اینکه ویژگیهای فایلسیستمهای موجود رو داره
تحملپذیریخطا، توسعهپذیری ، قابلیت اعتماد و دسترس پذیری بالا رو هم شامل میشه
از ویژگی های بارز فایل سیستم گوگل میتونیم به شفافیت مکانی بسیار بالای اون هم اشاره کنیم به طوری که از دید کاربر، یک کلاستر از GFS مثل یک درایو محلی نمایان میشه
و این فایل سیستم توانایی ذخیرهسازی فایل های چندین گیگا بایتی را نیز ارائه میکنه

سیر پیشرفت گوگل
در ژانویه ۱۹۹۶ دوتا از دانشجوهای دانشگاه استنفورد، به نامهای لریپیج و سرگی برین فرضیه جستوجوی صفحات وب را به این ترتیب بهبود دادند که یک موتور جستوجو با تحلیل رابطه بین سایتها میتونه نتایج بهتری نسبت به روشهای ابتدایی مورد استفاده ، داشته باشه این روش جستوجو Back Rub نامیده شد برای اینکه موتور جستوجو جهت تشخیص اهمیت سایت به پیوندهایی که از سایتهای دیگر به اون داده شده، توجه میکنه.

پیچ و برین این فرضیه را به عنوان بخشی از مطالعاتشون، آزمایش کردن و این رو پایهای برای موتور جستوجوی جدیدشون قرار دادن
اونا کارشون را از گاراژ یکی از دوستانشون در کالیفرنیا آغاز کردن و شرکت گوگل را در سپتامبر ۱۹۹۸ به ثبت رسوندن و نقطه عطف این شرکت وقتی بود که سایت AltaVista به عنوان یک کاربر به گوگل متصل شد و از اون به بعد گوگل تونست تعداد زیادی از کاربران این سایت را جذب خودش کنه
در سال ۲۰۰۰، گوگل شروع کرد به فروش آگهیهای تبلیغاتی مرتبط با کلمات کلیدی جستوجو
این روش فروش که بر اساس تعداد کلیکهای کاربران استوار بود ، نقش مهمی در افزایش درآمد این شرکت داشت.

در سال ۲۰۰۴ گوگل به اوج شهرت خودش رسید و تونست با کمک شرکای اقتصادی مثل یاهو، AOL و CNN، ۸۰ درصد درخواستهای جستوجو در وب را به خودش اختصاص بده
اما در فوریه ۲۰۰۴، یاهو مشارکت خودش رو قطع کرد تا نتیجه ی بهتری رو به کاربران ارائه کنه
این همین امر فرق بین گوگل و سایر سایتهای جستوجوی دیگه رو پررنگتر کرد؛
به نوعی که فعل «To Google» که تا اون موقع در زبان عامیانه به معنای جستوجو کردن در وب بود، در زبان رسمی هم استفاده شد
بــــه نوعی که فعل «To Google» کــــه تــــا اون موقع در زبان عامیانــــه بــــه معنای جست‌وجو کردن در وب بود، در زبان رسمی هم استفاده شد راز موفقیت یکـــــی از دلایل مهم در موفقیت اقتصادی گوگل کم کردن هزینه تجهیزات سخت‌افزاری و تغییرات مناسب در سیستم‌های نرم‌افزاری اشه گوگل به جای اینکه برای عملیات محاسباتی خودش برای خرید سرورهای گرون قیمتی که با ۸ پردازنده قوی یا بیشتر کار می کنن، ده‌ها میلیون دلار هزینه کنه ، فقط چند میلیون دلار برای هزاران سرور ارزون قیمت پرداخت کرد.

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

جالبه که بدونید فایل ایندکس گوگل در سال ۲۰۰۰ دارای بیش از یک میلیون صفحه و در آخر سال ۲۰۰۴ دارای بیش از ۸ میلیـــــون صفحه بـــــوده که اگر اندازه هر صفحه اگه بین ۵ تا ۱۰ کیلو بایت بگیریم ، حجم فایل ایندکس در آخر سال ۲۰۰۴ بین ۴۰ تا ۸۰ ترابایت برآورد شده مشکلات سایت گوگل و راه حل آن به طور خلاصه مشکلات موجود در سایت گوگل شامل : ‌‌ ‌نگهداری و مدیریت فایل‌های چندین ترابایتی مدیریت مکانیزه جهت کنترل خرابی سرورهای گوگل حجم کاری زیاد و اجرای هزاران پرس‌وجو در هر ثانیه‌ ‌برای اجرای هر پرس ‌و جو باید به طور متوسط صدها مگا بایت اطلاعات خونده بشه که اجرای این فرآیند روی یک کامپیوتر، بسیار زمان بره گوگل در برخورد با این مشکلات تصمیم به طراحی و پیاده‌سازی یک فایل سیستم جدید گرفت ، این فایل سیستم با تجزیه فایل‌ها به اندازه‌های ثابت مشکلات مربـوط به نگهداری فایل‌های حجیم را حل کرده , گوگل هم ابزارهایی رو جهت ثبت وقایع و بازخونی اونا به منظور یافتن زمان و مکان بروز خطا و اطلاع بـــــه مدیریت پیاده‌سازی کرده که خطایابی سایت هم بسیار ساده شده خصوصیات فایل سیستم گوگل GFS با فایل سیستم‌های قدیمی خصوصیات مشترکی همچون تحمل‌پذیری خطا، کارایی، قابلیت گسترش ، قابلیت اطمینان و دسترس‌پذیری رو داره، اما علت طراحــی اون وجود نیازمندی‌ها و ویژگی‌های خاص محیط عملیاتی گوگل ه که خدمتتون عرض می کنم اول اینکه سیستـــم کلی از صدها و یا شاید هزاران سرور معمولی تشکیل شده باشه و توسط صدها کامپیوتر کلاینت استفاده میشه کمیت و کیفیت تجهیزات موجــود نشون می‌ده که احتمال اینکه روزانه تعدادی از این سیستم‌ها از کار بیفته ، زیاده بنابراین مانیتورینگ سیستم ، خطایابی ، تحمل‌پذیری نسبت بـه خطا و ترمیم خودکار توسط سیستم از اجزای اساسی فایل سیستم گوگل ه دوم اینکه فایل‌های مورد استفاده در این محیط بسیار حجیم ان و به علاوه مجموعه داده ها رشد سریعی دارن به گونه‌ای که فایل‌هایی با حجم چند ترابایت نیز وجود دارند البته میشه به جای یک فایل چند ترابایتی از میلیاردها فایل چند کیلو بایتی استفاده کرد ولی انجام این کار باعث کاهش کارآیی شبکه ، کندی سیستم و مدیریت دشوار داده‌ها میشه پس لازم که هنگــام طراحی یک فایل سیستم جدید بـــه عملیات ورودی/خروجی و اندازه بلوک‌های داده توجه بشه سوم اینکه اکثر تغییرات در فایل ها شامل اضافه کردن داده‌های جدید بـه آخر فایله و کمتر می‌تونیم داده‌های موجود در فایل رو به روزرسانی کنیم و زمانی که داده‌های جدید به آخر فایل اضافه میشن ، معمولا دیگه تغییر نمی کنن و عملیات خوندن از فایل به کرات اجــرا میشه با توجه به این الگوی دسترسی، در سیستم جدید باید کارآیی لازم جهت افزودن راحت داده‌ها در نظر گرفته بشه چهــــارم اینکه سیستم جدید بــــرای استفاده در محیط گوگل باید شامــــل تسهیلاتی جهت کمک بــــه طراحی سیستــــم‌های کاربردی باشه.

به عبــــارتی باید API‌هایــــی برای افزایش انعطاف‌پذیری و ساده‌سازی عملیات کار با فایل‌ها در اختیار بذاره.

معماری فایل سیستم گوگل 1 در اینجا جهت آشنایی بیشتر، فایل سیستم گوگل را بـــــا یک فایل سیستــم متمرکز مثل ۳۲FAT مقایسه می کنیم.

در فایل سیستم متمرکز دو لایه وجود دارد: لایه بالایی که وظیفه مدیریت و نگهداری داده‌هــــای متا (MetaData) یا همون جدول نگهداری فایل‌ها را بر عهده داره لایه پایینی کــه مسئولیت ذخیره و بازیابی داده‌ها در واحدهایی بنام بلوک را بر عهده داره.

‌ در GFS‌ نیز معادل با این دولایه، دو نوع سرور وجود داره: سرور اصلی (Master‌) که مثل لایه بالایی وظیفه مدیریت و نگهداری داده‌های متا را به عهده داره چانک سرورها (ChunkServer) معادل با لایه پایینی وظیفه ذخیره و بازیابی داده‌ها در واحدهایی به نام چانک (Chunk)‌ را بر عهده دارن.

در GFS ‌فایل‌ها در واحدهای کوچک‌تری موسوم به چانک که مثل بلاک‌ها در سیستم های متمرکز هستند نگهداری می‌شن همون‌طور که گفته شد سرور Master ‌وظیفه نگهداری داده‌های متا را بر عهده داره.

داده‌های متـا در واقع شامل اطلاعاتی درباره فایل‌ها و دایرکتوری‌هایی هستن که یک فایل سیستم رو تشکیل می‌دن و همچنین نشون می‌دن که هر فایل شامل چه چانک‌هاییه و هر چانک در کدام چانک سرور نگهداری می‌شه.

سرور Master‌ همواره در دوره‌های زمانی مشخص موسوم به Heart Beat سرکشی می‌کند تا از آخرین وضعیت اونا مطلع بشه.

وجود تنهــا یک سرور Master‌، طراحـی GFS‌ را خیلـی ساده کرده .

سرور Master‌ قادره که با استفاده از اطلاعاتی که درباره کلیه سرورها و چانک‌ها داره ، محل هر چانک جدید را ماهرانه تعیین کنه.

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

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

برای دسترسی‌های بعدی به این چانک، دیگه نیازی به ارتباط بین کلاینت و سرور Master‌ نیست؛ چراکه اطلاعات چانک هایی که با آن ارتباط برقرار شده در حافظه کلاینت ‌به صورت موقت بایگانی می‌شه .

البته زمانی که اطلاعات چانک در حافظه کلاینت منقضی یا فایل دوباره باز و بسته بشه ، باید جهت دریافت اطلاعات جدید ، کلاینت ‌با سرور Master‌ ارتباط برقرار کنه.

چانک‌ها و داده‌های متا همون‌طور که اشاره شد، فایل‌های حجیم در قطعات کوچک‌تری که چانک نام داره ، ذخیره می‌شن.

تعیین اندازه چانک یکی از پارامترهای کلیدی در طراحی GFS این اندازه در حال حاضر ۶۴ مگابایت در نظر گرفته شده که از اندازه بلاک‌ها در فایل سیستم‌های معمولی خیلی بیشتره هر یک از نسخه‌های چانک، به صورت یک فایل در سیستم عامل یونیکس روی چانک سرورها نگهداری می‌شن.

مهم‌ترین ایراد چانک‌ها، قطعه قطعه شدن داخلی اونهاست که این مشکل هم به روش تخصیص حافظه Lazy‌ مرتفع می‌شه ؛ از طرفه دیگه ، اندازه بزرگ چانک‌ها مزایای زیادی داره: اول اینکه باعث می‌شه کلاینت‌ها کمتر نیاز پیدا کنند تا با Master‌ جهت تعیین محل چانک ارتباط برقرار کنن که این موضوع برای کاهش بار سـایت گوگل مهمه چون اکثر کلاینت‌ها داده‌های حجیم را به صورت پی‌ در پی می‌خونن و یا می‌نویسن دوم اینکه سبب می‌شن تا برنامه کاربردی، با استفاده از یک ارتباط TCP ‌ثابت، رابطه خودش رو در یک دوره از زمان اجرا ، با چانک سرور حفظ کنه و به این ترتیب بار شبکه برای ایجاد ارتباط با سرورهای مختلف کاهش پیدا می کنه سوم اینکه چانک‌های با اندازه بزرگ، حجم داده‌های متا را که در سرور Master ‌نگهداری می‌شن، به شدت کم می کنن بنابراین Master‌ می‌تونه این اطلاعات را در حافظه خودش نگهداری کنه