بررسی فایل سیستم گوگل

در این مقالـه قصد داریم پس از اشاره مختصر به سیر تحولات گوگل به بررسی فایل سیستم گوگل بپردازیم و در ادامه نگاهی اجمالی به معماری GFS خواهیم داشت

فایل سیستـــم توزیع شده، مهم‌ترین جزء یك سیستم توزیع شده به‌شمار می‌رود و از ایـــن رو تا به حال تحقیقات و فعالیت‌های زیادی نیز در این زمینه انجام گرفته كه آشناترین آنهـا NFS (فایل سیستم شبكه) محصول شركت Sun Microsystems‌ است. هدف اصلـــی NFS ‌آن است كه فایل سیستم‌های مختلف موجـود در كامپیوترهای شبكه را گرد هم آورد و بدین منظور پروتكلی را معرفی می كند كه هـــر یك از فایل سیستم‌ها با رعایت آن می توانند جزئی از مجموعه كلاستر NFS شوند و اطلاعات خود را به اشتراك بگذارند. از دیگر فـــایل سیستم‌های توزیع شده می‌تـــوان از Coda محصول دانشگاه كارنگی ملون (Carnegie Mellon) نام بـــرد. هدف اصلی در سیستم Coda ‌افزایش میزان دسترس‌‌پذیری است و بـــه این منظور داده‌های فایل در حافظه cache كامپیوتر كلاینت‌، نگهداری می‌شود.

LBFS‌ نیز یك فـــایل سیستم توزیع شده مناسب برای شبكه‌های با پهنای باند كم است. این سیستم با استفاده از تكنیك‌های فشرده‌سازی و نگهداری داده‌های رسیده در حافظه cache به شدت از ترافیك شبكه می‌كاهد. سایـر فایل سیستم‌های توزیع شده عبارتند از : AFS، ۹Plan، XFS، SFS‌، Frangipani و غیره. امـــا هیچ یك از این فایـل سیستم‌های موجود به‌طور كامل نیازمندی‌های گوگل را پوشش نمی‌دهد. در سایت گـــوگل تعدادی فایل چند ترابایتی وجود دارد كه نمی‌توان آنها را به تنهایی در سرورهای سایت گوگل كه متشكل از هزاران كامپیوتر معمولی است، ذخیـــره كرد. از طرف دیگر تقسیم این فایل‌های حجیم به هزاران فایل كوچك‌تر باعث پیچیدگی و نیز كاهش كارآیی برنامه‌ها خواهـــد شد.

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

در این مقالـه قصد داریم پس از اشاره مختصر به سیر تحولات گوگل به بررسی فایل سیستم گوگل بپردازیم و در ادامه نگاهی اجمالی به معماری GFS خواهیم داشت.

● سیر پیشرفت گوگل

در ژانویه ۱۹۹۶ دو دانشجوی دوره دكتری در دانشگاه استنفورد، به نام‌های لری‌پیج (Larry Page) ‌و سرگی برین (Sergey Brin‌)، فرضیه جست‌وجوی صفحات وب را به این ترتیب بهبود دادند كه یك موتــــور جست‌وجو با تحلیل رابطه بین سایت‌ها می‌تواند نتایج بهتری نسبت به روش‌هــــای ابتدایی مورد استفــــاده، ارائه كند. این روش جست‌وجو Back Rub ‌نام گرفت؛ چرا كه موتور جست‌وجو جهت تشخیص اهمیت سایت به پیوندهایـی كه از سایت‌های دیگر به آن داده شده، توجه می‌كند. پیچ و برین ‌ایــــن فرضیه را به عنوان بخشی از مطالعاتشان، آزمــایش كردند و آن را پایه‌ای برای موتور جست‌وجوی جدیدشان قرار دادند.

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

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

● راز موفقیت

یكـــــی از دلایل مهـــــم در موفقیت اقتصـــــادی گـــوگل كاهش هزینه تمام‌شده جهت تجهیزات سخت‌افزاری و اعمال تغییرات مناسب در سیستم‌هـــــای نرم‌افـــــزاری آن است. گـــــوگل به جای آنكه برای زیر‌ساخت‌های محاسباتی خود جهت خرید سرورهای گران قیمت با ۸ (یا بیشتر) پردازنده قوی، ده‌ها میلیون دلار بپردازد، فقط چند میلیون دلار جهت هزاران سرور ارزان قیمت پرداخت كرد.

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

البته این وظیفه فایل سیستم جدید است تا داده‌ها را در سرور های ثانویه تكرار كند; تقسیم كار مناسب بیـــــن سرور های موجود انجام دهــد، در صورت بروز خطا در یك سرور عملیات را از سرورهــای ثانویه از سر بگیرد و تحمل پذیری نسبت بـــــه خطا را بالا ببرد. جالب است بدانید فایل ایندكس گوگل در سال ۲۰۰۰ شامل بیش از یك میلیون صفحه و در انتهای سال ۲۰۰۴ بیش از ۸ میلیـــــون صفحه بـــــوده است; حال اگـــــر اندازه هر صفحه را بین ۵ تا ۱۰ كیلو بایت در نظر بگیریم، حجم فایل ایندكس در پایان سال ۲۰۰۴ بین ۴۰ تا ۸۰ ترابایت برآورد می‌شود.

● مشكلات سایت گوگل و راه حل آن

به طور خلاصه مشكلات موجود در سایت گوگل عبارتند از :

▪ ‌‌ ‌نگهداری و مدیریت فایل‌های چندین ترابایتی

▪ مدیریت مكانیزه جهت كنترل خرابی سرورهای گوگل

‌▪ حجم كاری زیاد و نیاز به اجرای هزاران پرس‌وجو در هر ثانیه ‌‌(‌ ‌برای اجرای هر پرس‌وجو باید به طور متوسط صدها مگا بایت اطلاعات خوانده شود كه اجرای چنین فرآیندی روی یك كامپیوتر، بسیار زمان بر است.

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

● خصوصیات فایل سیستم گوگل

اگر چه GFS با فایل سیستم‌های قدیمی خصوصیات مشتركی از قبیل تحمل‌پذیری خطا، كارایــی، قابلیت گسترش، قابلیت اطمینان و دستـــــرس‌پذیری دارد، اما علت طراحــی آن وجود نیازمندی‌ها و ویژگی‌هـــــای خـــــاص محیط عملیاتـــــی گـــــوگل است. در ادامـــه به خصوصیات جدید موجود در محیط عملیاتی گوگل می‌پردازیم:

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

دوم اینكـــــه فایل‌هـــای مورد استفـــــاده در این محیط بسیار حجیم هستند و به علاوه رشد سریع مجموعه داده‌ها یكی از خصوصیات بارز در آن است؛ به گونه‌ای كه فایل‌هایی با حجم چند ترابایت نیز وجود خواهد داشت. البته می‌توان به جای یك فایل چند ترابایتی از میلیاردهـــــا فایل چنــــد كیلو بایتی نیز استفاده كرد، ولی انجام این كـــــار باعث كاهش كارآیی شبكه، كندی سیستــم و مدیریت دشوار داده‌هـــــا می‌شـــــود، در نتیجـــــه لازم است هنگــام طراحی یك فایل سیستم جدید بـــه عملیات ورودی/خروجی و اندازه بلوك‌های داده توجه داشت.

سوم اینكه اكثــــر تغییرات در فایل ها شامل اضافه كردن داده‌های جدید بـه انتهــــای فایل است و كمتـــــر می‌توان داده‌های موجود در فایل را به روزرسانی كرد. زمانی كه داده‌های جدید به انتهای فایل اضافه می شوند، معمولا دیگر تغییـــــر نمی كنند و عملیات خواندن از فــــایل به كــــرات اجــرا می‌شود. با توجه به این الگوی دسترسی، در سیستــــم جدید باید كارآیی لازم جهت افزودن راحت داده‌هــــا در نظر گرفته شود.

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

● معماری فایل سیستم گوگل

در اینجا جهت آشنایی بیشتر، فایل سیستم گوگل را بـــــا یك فایل سیستــم متمركز مانند ۳۲FAT مقایسه می كنیم. در فایل سیستم متمركز دو لایه وجود دارد: لایه بالایی كه وظیفه مدیریت و نگهداری داده‌هــــای متا (MetaData) یا همــــان جدول نگهـــــداری فایل‌ها را بر عهده داشته و لایه پایینی كــه مسئولیت ذخیره و بازیابی داده‌ها در واحدهایی بنام بلوك را بر عهده دارد. ‌

در GFS‌ نیز معادل با این دولایه، دو نوع سرور وجود دارد: سرور اصلـــــی (Master‌) هماننـــــد لایــــــه بـــــالایـــــی وظیفـــــه مدیـــــریت و نگهداری داده‌هــــای متا را به عهده دارد و از طرفـی چانك سرورها (ChunkServer) معـــــادل با لایـــــه پایینی وظیفه ذخیره و بازیابی داده‌هـــــا در واحدهایی به نام چانك (Chun)‌ را بر عهده دارند. در 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 ‌برای مبارزه با خرابی‌ها راهكارهایی را به كار برده است كه در ادامه به آنها اشاره خواهیم كرد:

● ترمیم سریع

هم سرور 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 برای رفع نیازمندی‌های سایت گوگل طراحی شده، ولی می‌توان با اعمال برخی تغییرات، كاربرد آن را عمومیت بخشید.

مهدی طالبیان كوچكسرایی