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

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

3. 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

4. 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

5. 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

6. 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

7. 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

8. 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

9. 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

10. 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

11. 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

12. 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

13. 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

14. 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

15. 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

16. 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

17. 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

18. 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

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

20. 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

21. 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

22. 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

23. 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

24. Performance Test
Azad university of Kurdistan
The Google File System

25. 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

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

27. 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

28. 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

29. Questions?
Azad university of Kurdistan
The Google File System