فایل سیستـــم توزیع شده، مهم‌ترین جزء یک سیستم توزیع شده به‌شمار می‌رود و از ایـــن رو تا به حال تحقیقات و فعالیت‌های زیادی نیز در این زمینه انجام گرفته که آشناترین آنهـا NFS (فایل سیستم شبکه) محصول شرکت Sun Microsystems است. هدف اصلـــی NFS ‌آن است که فایل سیستم‌های مختلف موجـود در کامپیوترهای شبکه را گرد هم آورد و بدین منظور پروتکلی را معرفی می کند که هـــر یک از فایل سیستم‌ها با رعایت آن می توانند جزئی از مجموعه کلاستر NFS شوند و اطلاعات خود را به اشتراک بگذارند. از دیگر فـــایل سیستم‌های توزیع شده می‌تـــوان از Coda محصول دانشگاه کارنگی ملون (Carnegie Mellon) نام بـــرد. هدف اصلی در سیستم Coda ‌افزایش میزان دسترس‌‌پذیری است و بـــه این منظور داده‌های فایل در حافظه cache کامپیوتر کلاینت‌، نگهداری می‌شود.
LBFS نیز یک فـــایل سیستم توزیع شده مناسب برای شبکه‌های با پهنای باند کم است. این سیستم با استفاده از تکنیک‌های فشرده‌سازی و نگهداری داده‌های رسیده در حافظه cache به شدت از ترافیک شبکه می‌کاهد. سایـر فایل سیستم‌های توزیع شده عبارتند از : AFS، ۹Plan، XFS، SFS، Frangipani و غیره. امـــا هیچ یک از این فایـل سیستم‌های موجود به‌طور کامل نیازمندی‌های گوگل را پوشش نمی‌دهد. در سایت گـــوگل تعدادی فایل چند ترابایتی وجود دارد که نمی‌توان آنها را به تنهایی در سرورهای سایت گوگل که متشکل از هزاران کامپیوتر معمولی است، ذخیـــره کرد. از طرف دیگر تقسیم این فایل‌های حجیم به هزاران فایل کوچک‌تر باعث پیچیدگی و نیز کاهش کارآیی برنامه‌ها خواهـــد شد.
بنابراین گوگل جهت رفع نیازمندی‌ها و با تمرکز روی شرایط محیطی خود، فایل سیستم گوگل (GFS) ‌را طراحی و پیاده‌سازی کرد. GFS علاوه بـــر دارا بودن ویژگی‌هـــای مهم فایل‌سیستم‌های موجـــود (تحمل‌پذیری‌خطا، توسعه‌پذیـــری، قابلیت اعتماد و دسترس پذیـــری بالا)، خصایص جدیدی را نیز شامل می‌شود. از خصیصه های بارز فایل سیستم گوگل می‌توان به شفافیت مکانی بسیـــار بالای آن اشاره کــــرد; به طوری کــــه از دید کاربر، یک کلاستر از GFS ‌هماننـــد یک درایو محلی نمایان خواهد شد. از طرفی این فایل سیستم، توانایی ذخیره‌سازی فایل های چندین گیگا بایتی را نیز ارائه می‌کند.
در این مقالـه قصد داریم پس از اشاره مختصر به سیر تحولات گوگل به بررسی فایل سیستم گوگل بپردازیم و در ادامه نگاهی اجمالی به معماری 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 برای رفع نیازمندی‌های سایت گوگل طراحی شده، ولی می‌توان با اعمال برخی تغییرات، کاربرد آن را عمومیت بخشید.

وب ایران