Presenters: Rezan Amiri Sahar Delroshan The Google File System Presenters: Rezan Amiri Sahar Delroshan Azad university of Kurdistan

Outline Distributed File systems Overview GFS (Google File System) Motivations Assumptions Architecture Algorithms conclusions Azad university of Kurdistan The Google File System

Distributed File systems Sneaker net is the process of sharing files by copying them onto floppy disks, physically carrying it to another computer and copying it again (1980S) a file system that joins together the file systems of individual machines in network Files are stored (distributed) on different machines in a computer network but are accessible from all machines. called network file systems در سالهای 1980 برای اینکه کاربران بتوانند فایلهایشان را به اشتراک بگذارند از روشی بنام اسنیکر نت که یک پردازشی برای به اشتراک گذاشتن فایل ها است استفاده می کردند به این صورت که فایل ها را در فلاپی ها کپی می کردند و به صورت فیزیکی آن را بر روی کامپیوتر دیگر کپی می کردند و با گسترش شبکه های کامپیوتری روشهای قدیمی غیر مفید بود و بعدها از روش اف تی پی استفاده کردند اما همچنان نیاز بود که دو با رفایلها کپی شوند Azad university of Kurdistan The Google File System

Examples of Distributed File System Distributed file systems Andrew File System (AFS) Network File System (NFS) Apple Filing Protocol (AFP) Distributed fault tolerant file systems Coda Distributed File System (Microsoft) (DFS( (AFS) is scalable and location independent, has a heavy client cache and uses Kerberos for authentication. Implementations include the original from IBM (earlier Transarc), Arla and OpenAFS (NFS) originally from Sun Microsystems is the standard in UNIX-based networks. NFS may use Kerberos authentication and a client cache (AFP) from Apple Computer. AFP may use Kerberos Authentication Coda from Carnegie Mellon University focuses on bandwidth-adaptive operation (including disconnected operation) using a client-side cache for mobile computing. It is a descendant of AFS-2. It is available for Linux under the GPL. (Dfs) from Microsoft focuses on location transparency and high availability. Available for Windows under a proprietary software license. Azad university of Kurdistan The Google File System

Motivation Google Operations Who doesn’t know about Google? the accuracy is dependent on how the algorithm is designed. Lary Page & Sergey Brin 1998 Google is beyond the searching Google Video Gmail Google Map Google Earth,… Google Operations Google Operation : More than 15K commodity class PCs Google stores dozens of copy of the entire web Thousands of queries served per second One query reads 100's of MB of data One query consumes 10's of billions of CPU cycles Azad university of Kurdistan The Google File System

Motivation Redundant storage of massive amounts of data on cheap and unreliable computers problems caused by (OS bugs , human errors , …) Why not use an existing file system? Google’s problems are different from anyone else’s Different workload and design priorities بمنظور کتنرل اینگونه اتفاقات لازم است که علاوه بر خصوصیاتی ( تحمل پذیری خطا و توسعه پذیری و قابلیت اطمینان و دسترس پذیری بالا ) که همه فایل سیستمها دارند فایل سیستم گوگل مرتب با فایلهای بزرگی سرو کار دارد که کار کردن با آنها با استفاده از کامپیوترهای معمولی دشوار است لذا باید مقیاس پذیری داشته باشند یعنی افزایش ظرفیت آن ساده باشد چون این شبکه بسیار بزرک است مانیتورینگ و نگهداری آن نیز یک چالش بزرگ بشمار می آید مفهوم دیگر ساده سازی بود کنترل یک روش ساده آسان تر است حتی اگر سیستم بسیار عظیم باشد برنامه نویسان همزمان با توسعه فایل سیستم گوگل تصمیم گرفتند بخش اعظم وظایف مدیریتی مورد نیاز سیستم را به صورت خودکار در اورند تا سیستم قادر به ادامه کار باشد یعنی ترمیم خودکار در دنیای گوگل هیچ چیز کو چک نیست و رشد سریع داده ها اجتناب ناپذیر است لذا در طراحی به عملیات ورودی و خروجی و اندازه بلوک ها باید توجه داشت Azad university of Kurdistan The Google File System

Assumptions High component failure rates Workloads Inexpensive commodity components fail all the time Workloads large streaming read, Small random reads , Writes efficiently implement well-defined semantics for multiple clients that concurrently append to the same file High sustained bandwidth is more important than low latency - The system store a “Modest” number of HUGE files. - Files are once written, mostly appended to -The system must efficiently implement well-defined semantics for multiple clients that concurrently append to the same file -Most of our target applications place a premium on processing data in bulka t a high rate, while few have stringent response time requirements for anindividual read or write. Azad university of Kurdistan The Google File System

GFS Design Decisions Files stored as chunks Fixed size (64MB) Reliability through replication Each chunk replicated across 3+ chunk servers Single master to coordinate access, keep metadata Add snapshot and record append operations Azad university of Kurdistan The Google File System

GFS Architecture 1 master many chunks server ---کلاینت ها درخواست متا دیتا را به مستر می دهند و مستر نیز متا دیتا را در اختیار آنها قرار می دهدو کلاینت ها درخواست خواندن / نوشتن را به چانک سرورها می دهند و چانک سرور ها هم به درخواستشان پاسخ می دهند ---توجه شود که در اینجا شاید بنظر برسد که وجود یک مستر با یک گلو گاه مواجه است اما مستر همه چیز را درحافظه خود دارد و از اینرو هم سریع است و فقط با متا دیتا درگیر است و اکثرا کلاینت ها برای خواندن و نوشتن به چانک سرورها مراجعه می کنند و البته خود کلاینتها نیز اطلا عات را کش می کنند و از این بابت ارتباط بین کلاینت و مستر کاهش می یابد گوگل سیستم فایل گوگل را در داخل کلاسترهای کامپیوتر ها سازمان دهی نموده است ویک کلاستر شبکه ای از کامپیوتر هااست هر کلاستر شامل صدها یا حتی هزاران کامپیوتر است .در داخل کلاسترهای گوگل سه نوع هویت وجود دارد 1- کلاینت 2- سرور های اصلی 3- چانک سرورها 1 master many chunks server Files is divided into large chunks chunks are replicated across the system Azad university of Kurdistan The Google File System

Chunks and Chunk Servers Similar to block in file systems Size is always 64 MB Lazy allocation to avoid fragmentation Reduce the need to contact to master Reduce network overhead Client consistently maintain TCP connection with chunk server Reduce size of metadata in memory Allow to keep metadata in memory Problem :” hot spot “ with small file فایلهای کوچک احتمالا فقط شامل یک چانک خواهند بود و چانک سرورها یی مه شامل چنین فایلهایی هستند دچار مشکلی بنام هات اسپات شوند یعنی تعداد زیادی کلاینت همزمان بخواهند آن را اجرا کنند اما در عمل این مشکل چندان حاد نیست چرا که اکثرا با فایلهای چند ترا بایتی سرو کار دارند Azad university of Kurdistan The Google File System

Metadata Global metadata is stored on the master File and chunk namespaces Mapping from files to chunks Locations of each chunk’s replicas All in memory (64 bytes / chunk) Fast Easily accessible operation log Persistent on local disk Replicated Checkpoints for faster recovery یک نگرانی در مورد نگهداری اطلاعات چانک ها و ساختار فایل ها در حافظه وجود دارداینکه تعداد چانک ها و ظرفیت کل فایل سیستم به میزان حافظه بستگی دارد اما در عمل این محدودیتی جدی به حساب نمی آید چرا که به ازای هر چانک که 64 مگابایت است فقط 64 بایت از حافظه اشغال می شود و اگر هم نیاز باشد می توان با اضافه کردن حافظه مستر این مشکل را رفع نمود که در مقابل مزایای سادگی وقابلیت اطمینان و کارایی بالا و انعطاف پذیری هزینه کمتری خواهد بود Azad university of Kurdistan The Google File System

Master’s Responsibilities Master is a single process running on a separate machine that stores all metadata Periodic communication with chunk servers Namespace management and locking It allows concurrent mutations in the same directory creation, re-replication, rebalancing - یک پردازش تک است که بر روی تمام ماشین ها ی توزیع شده اجرا می شود مستر اطلاعات مربوط به محل چانک ها را به صورت دائم نگهداری نمی کند بلکه در هنگام اتصال چانک سرور به مستر , چانک سرور ها تمام چانک های خود را به مستر گزارش می دهند و کلاینت ها با مستر ارتباط برقرار می کنند تا متا دیتا را برای ارتباط با چانک سرور ها داشته باشند تمام عملیات مربوط به فضای نام فایل ها را انجام می دهد در سراسر سیستم عمل کپی چانک ها را مدیریت می کند و هر کپی رپلیکا نام دارد که به طور پیش فرض سه کپی برای هر قطعه ایجاد می شود اجازه اجرای چندین عملیات وجود دارد و از مکانیسم قفل بر روی فضای نام استفاده می کنیم برا ی اطمینان از سریای سازی Azad university of Kurdistan The Google File System

Master’s Responsibilities The master re-replicates a chunk as soon as the number of available replicas falls below a user-specified goal : a chunk server becomes unavailable Chunk re-replicated is prioritized how far it is from its replication goal Re-replicate for live files مستر یک چانک را به محض اینکه تعداد کپی هایش از آنچه که کاربران بدان دسترسی دارند کمتر شود دوباره کپی انجام می دهد شاید که یک چانک سرور غیر قابل دسترس شده باشد چرا که شاید کپی اش مخدوش شده یا یکی از دیسک هایش غیر فعال شده است بدلیل خطاو.... چانکی که نیاز باشد عمل دوباره کپی برایش انجام شود یکی از عواملی که برایش در نظر می گیرند این است که چه تعداد از کپی هایش را از دست داده عامل دیگر این است که ترچیح می دهیم که ابتدا دوباره کپی را برای فایل هایی که زنده هستند انجام دهیم و در نهایت برای اینکه تاثیر خطا را حداقل کنیم اولویت را برای هر چانکی که بلاک شده بالا می بریم Azad university of Kurdistan The Google File System

Master’s Responsibilities Replica placement Improve reliability, availability network bandwidth utilization Garbage Collection simpler, more reliable than traditional file delete master logs the deletion, renames the file to a hidden name Lease mechanism Help reduce the overhead at master دو دلیل دارد : 1- ماکزیمم کردن قابلیت اعتماد و در دسترس بودن 2- ماکزیمم بهره وری از پهنای باند برای رسین به این هدف اینکه فقط کپی ها را در طول ماشین ها پخش کنیم به خودی خود خوب است اما کافی نیست و می بایست انها در طول رک نیز پخش کنیم که حتی اگر کل رک خراب شد بعضی از کپی های چانک ها همچنان امن می مانند همچنین به این معنی است که ترافیک که ( بیشتر مربوط به خواندن است) می تواند از کل پهنای باند چندین رک بهره برداری کند و در واقع ترافیک نوشتن هم می تواند از میان چندین رک رد شود که این مزیت را نیز برای ما آورده Azad university of Kurdistan The Google File System

Read Algorithm 1 .Application originates the read request 2. GFS client translates request and sends it to master 3. Master responds with chunk handle and replica Locations Azad university of Kurdistan The Google File System

Read Algorithm 4.Client picks a location and sends the request 5. Chunk server sends requested data to the client 6. Client forwards the data to the application Azad university of Kurdistan The Google File System

Write Algorithm 1,2,3 as like as read algorithm 4.Client pushes write data to all locations. Data is stored in chunk server's internal buffers Azad university of Kurdistan The Google File System

Write Algorithm 5.Client sends write command to primary 6. Primary determines serial order for data instances in its buffer and writes the instances in that order to the Chunk 7. Primary sends the serial order to the secondary's and tells them to perform the write Azad university of Kurdistan The Google File System

Write Algorithm 8.Secondaries respond back to primary 9. Primary responds back to the client Azad university of Kurdistan The Google File System

Leases and mutation order 1-the client asks the master 2-the master replied with the identity of the primary and the location of the other replicas. 3-the client pushes the data to all the replicas. 4-the client sends a write request to the primary 5-the primary forwards the write request to all secondary replicas. 6-the secondary's all reply to the primary 7-the primary replies to the client Azad university of Kurdistan The Google File System

Append Algorithm GFS appends it to the file atomically at least once - Client determine data GFS picks the offset 1,2,3 ,4 as like as write algorithm 5. Primary checks if record fits in specified chunk 6. If the record does not fit: 1. Pads the chunk 2. Tells secondary to do the same 3. Informs client 4. Client then retries the append with the next chunk Record append محدود شده به این که باید حداکثر یک چهارم از حداکثر سایز چانک باشد تا فراگمنتیشن در حد قابل قبولی قرار بگیرد. Azad university of Kurdistan The Google File System

Append Algorithm 1. Appends the record 7. If record fits, then the primary: 1. Appends the record 2.Tells secondary's to do the same 3.Receives responses from secondary's 4. And sends final response to the client snapshot - Fast Replicate from all system Snopshot : یک کپی سریع از کل سیستم می باشد.یا برای ایجاد checkpoint هایی از وضعیت جاری Azad university of Kurdistan The Google File System

Fault Tolerance High availability Fast recovery chunk replication default: 3 replicas replication Shadow master Data integrity برای یکپارچگی داده ها از الگوریتم checksumigاستفاده میکنیم که هر یک از بلاک های 64MB را به بلاک های 64KB خرد می کند و هر بلاک درون یک قطعه که دارای checksum 32 بیتی مربوط به خودش است می رود و در حافظه نگهداری می شود. Master قطعات را با توجه به checksum ها مانیتور می کند اگر checksum یک replica را حذف می کند و یک replica ی جدید ایجاد می کند و آن را جایگزین می کند. Azad university of Kurdistan The Google File System

Performance Test Azad university of Kurdistan The Google File System

Conclusion GFS demonstrates how to support large-scale processing workloads on commodity hardware Performance Scalability Fault-tolerance Minimize master involvement Azad university of Kurdistan The Google File System

Strong point Single master  simplify design  fast  simple failure handling Azad university of Kurdistan The Google File System

weakness Replication can be out of sync Space overhead Consistency among replica(what if replica has different length) Azad university of Kurdistan The Google File System

References Sanjay Ghemawat , Howard Gobioff , and Shun- Tak Leung, The Google File System, ACM Symposium on Operating Systems Principles, 2003 Naushad UzZaman, Survey on Google File System, CSC 456 (Operating Systems), 2007 Wikipedia Contributors, Google File System, Wikipedia -The Free Encyclopedia, 2010 Azad university of Kurdistan The Google File System

Questions? Azad university of Kurdistan The Google File System