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

در این مقاله قصد داریم پس از اشاره مختصر به سیر تحولات گوگل به بررسی فایل سیستم گوگل بپردازیم و در ادامه نگاهی اجمالی به معماری 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‌ می‌تونه این اطلاعات را در حافظه خودش نگهداری کنه .

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

در عمل این مشکل بــه شکل حاد بروز نمی‌کنه، چون اکثر برنامه های گوگل با فایل‌های چند ترابایتی سرو کار دارند.

سرور‌ Master‌، سه بخش اصلی از داده‌های متا ‌را در خودش نگهداری می‌کنه: فضای نام چانک‌ها و فایل‌ها نگاشت از فایل به چانک محل نسخه‌های کپی شده هر چانک.

تمام داده‌های متا در حافظه اصلی سرور Master‌ نگهداری شده و فضای نام چانک‌ها و فایل‌ها و نگاشت از فایل به چانک از طریق عملیات واقعه نگاری (Log Mutation) به صورت دائم در هارددیسک نگهداری می‌شه.

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

ســـــرور Master ‌اطلاعات مربوط به محل چانک‌ها را به صورت دائم نگهداری نمی‌کنه ، در عوض هنگام اتصال چانک سرور ‌به Master‌، چانک سرور تمام چانک‌های خودش را به سرور Master‌ گزارش می‌ده.

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

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

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

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

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

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

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

هرور Master‌ هنگام ترمیم باید فایل Operation Log‌ را برای ساخت داده‌های متا اجرا کنه از اونجا که این فایل به مرور زمان حجیم می‌شه ، اجرای اون هم زمان بر می شه.

به این منظور Master‌ در زمان مناسب اقدام به ایجاد نقاط کنترلیCheck Point در فایل ثبت وقایع کرده و یک تصویر کلی از داده‌های متا ‌تهیه می‌کنه.

موقع ترمیم، ابتدا آخرین تصویر کلی از داده‌های متا، بازیابی می‌شه و بعد Operation Log ‌از آخرین نقطه کنترلی اجرا شده تا داده‌های متا به طور کامل ایجاد میشه.

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

Master‌ با مقایسه شماره نسخه چانک در چانک سرور با معادل اون در داده‌های متا ، تشخیص می‌ده که آیا چانک موجود در چانک سرور قدیمیه یا خیر؟

بعد Master ‌ در فرصت مناسب، دستور حذف چانک‌ های قدیمی را می‌ده.

تکثیر چانک‌ها هر یک از چانک‌ها روی چانک سرورهای مختلف کپی می‌شن ؛ و در صورتی که یک چانک سرور از کار بیفته ، سایر چانک سرورها می‌تونن به درخواست‌های کاربران پاسخ دهند.

تکثیر سرور Master‌ داده ها متا تنها شیء با ارزشی که Master‌ نگهداری می‌کنه، که اون هم، برای افزایش ضریب اطمینان، روی سرورهای دیگر کپی می‌شه.

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

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

نتیجه گیری GFS ‌یک فایل سیستم همه منظوره نیست و تنها با توجه به شرایط محیطی سایت گوگل طراحی و پیاده‌سازی شده بنابراین در محیط‌هایی که مثل سایت گوگل، میزان خوندن داده‌ها بسیار بیشتر از به روز رسانی داده‌هایه ، می‌تونه استفاده بشه.

همچنین باید توجه داشت که این فایل سیستم برای یک شبکه محلی LAN پر سرعت طراحی شده و استفاده از اون در شبکه‌های با سرعت پایین مثل WAN‌ باعث افت کارایی می‌شه.

مهم‌ترین ویژگی GFS که اون را از سایر فایل سیستم‌های توزیع شده متمایز می‌کنه ، توزیع یک فایل روی چانک سرورهای مختلف است که مهم‌ترین دستاورد اون امکان ذخیره و نگهداری فایل‌های چندین ترابایتی و همچنین افزایش سرعت خواندن داده‌های فایل به دلیل پراکندگی در سطح شبکه و امکان اجرای موازیه هر چند GFS برای رفع نیازمندی‌های سایت گوگل طراحی شده، ولی امکان این هست که با برخی تغییرات درش، کاربردش رو عمومیت بخشید.

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