🏘️GFS系统架构

• 大型分布式文件系统
• Google的GFS采用廉价的商用机器构建，对硬件设施要求不高
• GFS将容错交给文件系统完成，利用软件的方法解决系统可靠性问题
  

GFS系统节点类型

• GFS将整个系统节点分为三类角色
  
• Client：GFS提供给应用程序的访问接口，以库文件的形式提供
• Master是GFS的管理节点，负责整个文件系统的管理，逻辑上只有一个
• Chunk Server负责具体的存储工作，数据以文件的形式保存，可以有多个，其数目直接决定了GFS的规模

GFS实现机制

1. 客户端与Master节点交互:
   • 客户端首先访问Master节点
   • 获取交互的Chunk Server信息
2. 控制流与数据流的分离:
   • 客户端与Master: 仅存在控制流，无数据流
     • 🚀 降低了Master的负载
   • 客户端与Chunk Server: 直接进行数据流传输
     • 📈 由于文件分成多个Chunk分布式存储
     • 🚀 客户端可以同时访问多个Chunk Server
     • 📊 实现系统I/O的高度并行，提高系统整体性能

🍎GFS特点

采用中心服务器模式

• 优点:

  • ✔️ 方便地增加Chunk Server
  • ✔️ Master掌握系统内所有Chunk Server的情况，方便进行负载均衡
  • ✔️ 不存在元数据的一致性问题

• 缺点:

  • ❗ Master极易成为整个系统性能和可靠性上的瓶颈

• 应对机制:

  • 🛠️ 控制元数据规模
  • 🛠️ 对Master进行远程备份
  • 🛠️ 控制信息和数据分流

不缓存数据

• 客户端的文件操作大多是流式读写，使用Cache对性能提高不大

• Chunk Server上数据以文件形式存储，本地的文件系统自然会进行缓存

• GFS对存储在Master中的元数据采取缓存策略:

  • 🚀 Master需要频繁操作元数据，直接保存在内存里以提高操作的效率
  • 🚀 采用相应的压缩机制降低元数据占用空间大小，提高内存利用率

在用户态下实现

• 利用POSIX编程接口存取数据，降低了实现难度，提高通用性
• POSIX接口提供功能丰富，不受内核编程限制
• 用户态下有多种调试工具，便于调试
• Master和Chunk Server作为进程运行，不影响操作系统整体稳定性
• GFS和操作系统运行在不同的空间，耦合性降低，方便独立升级

只提供专用接口

• 降低了实现难度，直接在应用层实现
• 根据应用特点提供特殊支持
• 专用接口减少了操作系统的上下文切换

容错机制

⚒️Master容错机制

• 当Master发生故障时，在磁盘数据保存完好的情况下，可以迅速恢复以上元数据
• 为防止Master彻底死机的情况，GFS还提供Master远程的实时备份

---

🔄 Chunk Server容错

• 副本机制 📦: GFS采用副本的方式实现Chunk Server的容错，每一个Chunk有多个存储副本（默认为三个）。
• 写入确认 ✅: 对于每一个Chunk，必须将所有的副本全部写入成功，才视为成功写入。
• 自动复制副本 🔄: 相关的副本出现丢失或不可恢复等情况，Master自动将该副本复制到其他Chunk Server。
• 文件与Chunk 📂: GFS中的每一个文件被划分成多个Chunk，Chunk的默认大小是64MB。
• Block与校验和 🛠️: 每一个Chunk以Block为单位进行划分，大小为64KB，每一个Block对应一个32bit的校验和。

🛠 系统管理技术

• 大规模集群安装技术 🌐: GFS集群中通常有非常多的节点，需要相应的技术支撑。
• 故障检测技术 🔍: GFS构建在不可靠廉价计算机之上的文件系统，由于节点数目众多，故障发生十分频繁。
• 节点动态加入技术 ➕: 新的Chunk Server加入时，只需裸机加入，大大减少GFS维护工作量。
• 节能技术 💡: Google采用多种机制降低服务器能耗，如采用蓄电池代替昂贵的UPS。