06分布式

莫库尔勒

已于 2024-04-26 11:16:31 修改

阅读量331

点赞数 3

分类专栏：分布式系统文章标签：分布式系统

于 2024-04-26 11:14:35 首次发布

本文链接：https://blog.csdn.net/CROSS__over/article/details/138212727

版权

分布式系统专栏收录该内容

11 篇文章 0 订阅

订阅专栏

06分布式

DFS distributed file system 分布式文件系统

components组件

相关内容问题

naming and transparency
remote file access
stateful versus stateless
file replication文件复制

重点

security

DFS distributed file system 分布式文件系统

分布式文件系统（Distributed File System，DFS）是一种将文件存储和访问分布在多台计算机上的文件系统。与传统的单机文件系统不同，分布式文件系统允许多台计算机共同存储和管理文件，提供了高可用性、容错性和扩展性。

以下是分布式文件系统的主要特点和工作原理：

分布存储： 文件和数据被分割成小块并存储在多台计算机上。每个计算机负责存储一部分文件数据，这种方式使得系统能够存储大量的数据，远远超过单台计算机的存储容量。
高可用性和容错性： 数据被复制到多个节点上，当某个节点发生故障时，系统仍然可以从其他副本中获取数据，确保了系统的高可用性和容错性。
数据一致性： 分布式文件系统通常采用一致性协议，确保在多个副本之间的数据一致性，即使在发生节点故障或网络分区的情况下。
扩展性： 分布式文件系统可以通过添加新的存储节点来扩展存储容量和吞吐量，而不需要改变整个系统的架构。
访问透明性： 用户可以透明地访问分布式文件系统中的文件，就像它们是存储在本地的一样，而不需要了解文件的具体存储位置和分布式存储的细节。
文件复制和备份： 文件通常会被复制到多个节点上，以提供数据冗余和备份。这样，在某个节点失效时，可以从其他节点恢复数据。

有一些知名的分布式文件系统，例如：

Hadoop HDFS： 是Apache Hadoop生态系统的一部分，用于存储大规模数据和提供高可用性。
Google文件系统（GFS）： 是Google开发的分布式文件系统，旨在处理大规模数据和提供高可靠性和高性能。
Amazon S3： 是亚马逊云计算服务提供的对象存储服务，可以看作是分布式文件系统的一种，用于存储各种类型的数据。

这些分布式文件系统在大数据、云计算和分布式应用中得到广泛应用，提供了强大的数据存储和管理能力。

需要的是
- 频繁读写、从不修改、基本不删除
- 能够存储图片、音频以及100MB以上的视频等文件
- 非常稳定、高可用、可扩容、可运维部署、
- 上手简单、易于维护、社区相对活跃
sharing of resource是分布式系统的关键目标，最常见的共享资源类型是存储信息，可以通过数据库，分布式共享内存，远程对象来实现。这些方法的基础是持久存储信息store data persistently

components组件

file servers文件服务器
- 软硬件的结合，包括二级存储资源和软件处理文件服务请求
- 它们接收请求并执行相应的操作，例如读取、写入、删除文件
clients用户端
- 向服务器发送请求，包括用户界面
  
  客户端通常包含与用户进行交互的界面，使用户能够方便地管理文件，例如图形界面、命令行界面
file services文件服务
- 指定DFS的基本操作，比如创建文件，删除文件，读取文件
在一个典型的DFS中，客户端通过网络连接到文件服务器，并通过请求执行文件服务。文件服务器负责管理文件的物理存储、处理读写请求，并确保文件的安全性和一致性。这种结构使得用户可以通过网络访问和操作存储在分布式环境中的文件，而无需了解文件的具体物理位置

相关内容问题

naming and transparency

在计算机科学中，命名（Naming）是指给文件或资源分配标识符（通常是文本标签），并将这些标识符映射到存储介质上的物理对象。命名的目的是使用户和计算机系统能够识别和操作这些资源。以下是关于命名的一些重要概念：
- 文件和资源的标识
  - 文本标签（File Names）： 文件名是用户或系统赋予文件的文本标识，通常与文件的内容或用途相关联。例如，一个文本文件可以被命名为"example.txt"。
  - 文件ID（File ID）： 文件ID是系统内部分配给文件的唯一标识符，它通常是一个数字或字符串，用于在系统内部唯一标识文件。
- 组织文件的结构
  - 目录结构（Directory Structure）： 文件通常被组织成一个层次化的目录结构。这种结构允许文件被放置在不同的文件夹（目录）中，形成有意义的组织。例如，一个操作系统的配置文件可以被放置在"/etc"目录下。
  - 上下文和路径（Context and Path）： 目录结构为每个文件提供了上下文。路径是指定文件位置的一串目录和文件名组合，例如"/etc/passwd"。路径不仅仅是文件名，它还包含了文件所在的目录结构，确保了唯一性。
- 文件系统中的命名实践
  - 文件名的相关性： 文件名通常与文件的内容、用途或所有者相关。这种相关性使得用户能够直观地了解文件的含义。
  - 文件路径的重要性： 文件路径是完整的文件名，它包含了文件所在的目录结构。在分布式文件系统或网络环境中，路径对于定位文件至关重要。
- 总之，命名是一个将抽象概念（文件、资源）映射到具体物理实体的过程。良好的命名实践使得文件系统更加可管理，用户和系统能够准确地找到和使用文件。
location transparency 和 location independence
- 文件名不显示物理位置
  - 完整文件名依旧包括路径，展示组件和机器之间的关系，共享数据更加方便
- 物理位置更改时文件名不变
  - 更好的文件抽象，促进共享存储空间，讲命名层次和设备层次分开
access transparency
- 要求本地和远程共用一套管理标准
global naming全局命名
- 需要提供合适的全局上下文。比如存在远程C/AAA/TEXT.js的文件和本地D/BBB/DDD/TEXT.js的文件相同，这样的话不容易找到对应的文件
- 全局上下文问题： 在DFS中，一个重要的问题是如何为每个文件名提供全局上下文。不同用户和不同机器可能以不同的方式组织远程目录，因此当我们讨论一个文件时，如何确保我们指的是同一个文件就变得复杂了。
- 解决方案：
- 方案一：完全集成的组件文件系统（Total Integration of Component File Systems）： 采用一个跨越系统中所有文件的单一全局命名结构。这意味着所有文件都在一个统一的命名空间下。其中的一些例子包括X.500命名方案和Andrew文件系统（AFS）。
- 方案二：理想的DFS视图： 系统中的每台机器都有相同的DFS视图。理想情况下，合成的文件系统结构应该与传统文件系统的结构相同，以便用户能够直观地理解和管理文件。
- 挑战： 然而，某些文件（如设备文件和特定于机器的文件）使得实现完全的一致性变得困难。如果一个服务器不可用，一些目录可能会在其他机器上变得不可用。
- 总之，为了解决DFS中的全局上下文问题，需要采取一种能够在整个系统中提供一致命名和访问的方法。这种方法应该能够在不同机器和用户之间提供一致的文件视图，确保无论用户从哪个角度访问文件，都能获得一致的体验。

remote file access

分布式系统需要有访问远程文件的权限。以下是两个将数据读写到远程文件的方法
- upload/download model
  - 将整个文件下载到客户端并修改，再上传回服务器
  - 将文件移动到文件系统
  - 读取操作： 当客户端请求读取文件时，整个文件会从文件服务器传输到请求的客户端。
  - 写入操作： 当客户端完成对文件的修改后，整个文件会回传到文件服务器。
  - 优势：
    - 简单的文件服务接口： 只有读取和写入两个操作，接口非常简单，易于实现和使用。
  - 劣势：
    - 客户端必须有足够的存储空间： 由于整个文件需要传输到客户端，因此客户端必须有足够的存储空间来接收整个文件。
    - 传输整个文件有时浪费资源： 对于大文件而言，将整个文件传输到客户端和从客户端传回文件服务器可能会浪费带宽和时间，尤其是在网络速度较慢的情况下。
  - 尽管这种方法简单，但它在处理大文件或者网络条件不佳的情况下可能不太高效。在现代分布式文件系统中，通常会采用更智能的策略，例如分块传输、增量传输或只传输所需部分，以提高效率并减少资源浪费。
  - S sends old_file to C，C sends new_file to S
- remote access model
  - 只下载需要的部分，并将更改过的部分发回去
  - 远程控制文件系统
  - 是在客户端远程控制文件系统的操作，而实际的文件系统操作是在服务器上执行的。
  - 优势：
    - 客户端无需大量存储空间： 由于实际的文件系统操作发生在服务器上，客户端不需要存储整个文件，因此无需大量存储空间。
    - 避免只需要小部分数据时传输整个文件： 当只需要文件的某一小部分数据时，不需要传输整个文件，节省了带宽和时间。
  - 劣势：
    - 重复访问相同数据（缓存可以解决此问题）： 如果客户端反复访问相同的数据，服务器需要不断处理请求，但可以通过缓存机制来减轻这个问题。缓存可以将之前请求的数据保存在客户端，当下次需要相同数据时，可以直接从缓存中获取，而不必再次请求服务器。
    - 这种方法允许客户端远程发出文件系统操作请求，而不需要在本地存储所有文件。这种方式通常需要服务器具备处理这些操作的能力，并且需要有效的缓存策略，以便在需要时快速提供数据。
Cache Update Policy

stateful versus stateless

stateful
- 文件服务器会维护客户端正在访问的文件的状态或内存信息
- 文件服务器内存： 当客户端请求一个文件时，文件服务器会从磁盘读取文件并将其副本保存在内存中，直到客户端使用完成。这种缓存机制可以加快访问速度，因为对同一个文件的后续请求可以直接从服务器的内存中提供，而不需要从较慢的磁盘存储中读取。
- 客户端-服务器交互： 当客户端打开一个文件时，服务器从其磁盘获取文件的信息，并将此信息存储在内存中。服务器然后为客户端提供一个唯一的连接标识符，该标识符特定于客户端和已打开的文件。这个标识符在后续访问中被使用，直到客户端会话结束。
- 有状态会话： 服务器维护关于已打开文件和客户端的状态信息。这种有状态性允许服务器进行性能优化。例如，如果文件以顺序方式打开，服务器可以预读并将文件的下一块缓存到内存中，减少了客户端请求文件的下一部分时需要进行额外的磁盘访问的情况。
- 内存回收： 服务器需要有效地管理其内存。当客户端不再活跃或已完成文件访问时，服务器必须回收先前由这些客户端使用的内存空间。这样可以确保服务器的内存得到最优使用。
- 有状态文件服务的优势： 有状态文件服务的主要优势在于提高性能。由于经常访问的文件被保存在服务器的内存中，因此需要较少的磁盘访问。此外，服务器了解文件访问方式（如顺序访问），可以进行智能缓存和预读操作，进一步提高性能。
- 有状态文件服务通过最小化磁盘访问次数、利用服务器端缓存以及根据客户端的访问模式优化数据检索，提高了文件服务器系统的效率和响应速度
stateless
- 文件服务器处理每个文件请求都是独立的，不依赖于之前的请求状态
- 每个请求独立处理： 文件服务器将每个文件请求视为一个独立的操作。每个请求都必须标识要访问的文件名以及要访问的数据在文件中的位置。
- 请求标识文件和位置： 每个请求都需要明确标识要访问的文件名和文件中要访问的数据位置。这种方法消除了建立和终止连接的需要，不需要进行打开和关闭操作。
- 无需连接操作： 与有状态文件服务不同，这种无状态的方法不需要通过打开和关闭操作来建立和断开连接。每个请求都足够自包含，不需要保持持久的连接状态。
- 读写操作作为远程消息： 无状态文件服务器中，读取和写入操作是通过远程消息（或缓存查找）来实现的。客户端发送请求，服务器处理请求并返回结果，整个过程不依赖于之前的请求状态。
- 网络文件系统 (NFS)： 网络文件系统（NFS）是一个无状态文件服务的例子。NFS 允许远程计算机通过网络访问文件，它的设计遵循了无状态的原则，每个请求都是独立的，不依赖于之前的请求状态。
- 无状态文件服务器系统通过独立处理每个请求，消除了维护连接状态的需要，使得系统更加简单和灵活
有状态分布式文件系统会在服务器端保持客户端的连接状态和文件访问状态，允许优化读写操作，但需要复杂的状态同步机制。无状态分布式文件系统不保持连接状态，每个请求都是独立的，简化了设计，但需要每个请求携带足够的信息，增加了请求的复杂性。选择取决于性能需求和系统复杂度的权衡。
面对故障恢复
- 有状态服务器的故障恢复：
  - 有状态服务器在崩溃时会失去所有的内存中的状态信息。
  - 故障恢复通常通过一种协议，该协议基于与客户端的对话，用于恢复丢失的状态。这可能涉及与客户端的交流，或者中止在崩溃发生时正在进行的操作。
  - 服务器需要知道客户端的故障，以便回收已分配给已崩溃客户端进程状态记录的空间。
- 无状态服务器的故障恢复：
  - 与有状态服务器相比，无状态服务器在面临故障和恢复时的影响几乎不可察觉。
  - 新启动的无状态服务器可以轻松地响应独立的请求，不需要复杂的状态恢复协议或对话。因为它不保留客户端状态，所以不需要与客户端交流来进行状态恢复。
- 有状态服务器在故障恢复时需要复杂的协议和与客户端的对话，以便恢复丢失的状态信息。相反，无状态服务器不保持客户端状态，因此在故障后重新启动时，可以立即响应独立的请求，不需要与客户端交互或进行复杂的状态恢复操作。
robust stateless service健壮的无状态服务
- 请求消息变长： 由于无状态服务需要在每个请求中包含所有必要的信息，请求消息通常会变得更长，因为每次请求都必须携带足够的上下文信息。
- 请求处理变慢： 由于无状态服务需要在每次请求中包含所有必要的信息，服务器在处理请求时可能会变得较慢，因为处理更长的请求消息需要更多的时间。
一些特定的环境或应用场景可能要求使用有状态服务，因为这些场景可能需要服务器保持客户端的状态信息以确保正确的操作和数据完整性。
- 服务器发起的缓存验证： 如果服务器使用服务器发起的缓存验证机制，它需要维护哪些文件被哪些客户端缓存的记录，这会导致服务器维护状态信息，因此无法提供真正的无状态服务。
- UNIX文件描述符和隐式偏移： 在UNIX系统中，文件描述符和隐式偏移是有状态的。服务器必须维护映射文件描述符到节点（inode）的表，并存储文件内的当前偏移位置。这种状态信息维护增加了系统的复杂性。

file replication文件复制

多物理副本： 一个逻辑文件有多个物理副本，即在系统中存在多份相同的文件内容。
命名服务维护引用： 系统中的命名服务负责维护对每个文件副本的引用，使得用户可以通过逻辑文件名访问其中任意一个副本。
用户对副本无感知（复制透明度）： 用户对这些副本的存在一无所知，系统会自动选择最合适的副本来满足用户的请求，用户不需要关心选择哪个副本来访问。
在某些系统中无法实现： 在某些系统（例如NFS和Windows）中，实现这种文件复制和透明访问是困难的。
文件复制技术允许系统在多个位置保留文件的多个副本，通过透明的方式将用户请求分配给最合适的副本，提高了系统的可靠性和性能。
为何复制
- 性能提升： 通过将对文件的请求分散到多个文件服务器上，或者从“最近的服务器”检索文件，可以提高文件访问的速度和性能。
- 提高可用性： 即使在服务器发生故障或通信中断的情况下，文件仍然可以通过其他副本进行访问，提高了系统的可用性和容错性。
何时复制
- 何时进行文件复制？ 在什么情况下应该对文件进行复制，这通常取决于系统的需求和设计目标。例如，在大规模系统中，可以根据文件的访问频率来决定是否进行复制。
- 复制的副本数量问题： 何时副本太多？副本数量的选择应该基于系统的需求和资源，过多的副本可能会浪费存储空间和带宽，因此需要在性能提升和资源利用之间找到平衡。
重点
更新问题（The Update Problem）：
- 文件的副本代表相同的实体，因此对任何一个副本的更新都必须反映到所有其他副本上。
- 这可能非常昂贵，特别是在带宽方面。
需求驱动的复制（Demand Replication）：
- 当读取一个非本地副本时，该副本被缓存在本地，从而生成一个新的非主要副本。
- 针对这个新副本应该采取什么策略？
并发问题（Concurrency Problem）：
- 两个用户尝试同时更新一个副本。
- 应该保留哪个用户的更新，以及为什么？

解决方案和考虑因素：

更新问题的解决：
- 引入一致性协议（例如Paxos、Raft）来确保所有副本的一致性，确保当一个副本被更新时，其他副本也会相应更新。
需求驱动的复制的处理：
- 新的非主要副本可以根据策略进行处理，例如将其标记为主要副本（如果源头副本无法访问时），或者保持为只读副本。
并发问题的解决：
- 使用锁或事务来确保并发更新的一致性。可以采用乐观锁定（例如版本号）或悲观锁定（例如互斥锁）等策略，以避免多个用户同时修改副本的冲突。

security

数据访问控制： 安全性在分布式文件系统中至关重要，它控制对存储在文件中的数据的访问。安全性机制确保只有经过授权的用户可以访问文件的特定部分或整个文件。
客户端请求的身份验证： 安全性还涉及对客户端请求的身份验证。服务器需要确认请求来自合法的客户端，防止未经授权的访问。
访问控制列表（ACLs）： 大多数文件系统提供基于访问控制列表的访问控制机制。ACLs允许文件所有者指定哪些用户或组有权访问文件，并决定他们可以执行的操作。
UNIX的访问权限检查： 在UNIX系统中，每次执行打开操作时，系统会对访问权限进行检查。用户的访问权限会在文件关闭之前一直保持。这些权限检查基于用户登录时被验证的UID（用户标识符）。
在分布式文件系统（DFS）中，安全性检查必须在每次操作之前进行。否则，服务器可能会被暴露在未经授权的访问风险中。有两种主要的方法来确保DFS的安全性：
1. 名称解析安全性检查（Name Resolution Security Check）：
  - 当名称解析为唯一文件标识符（UFID）时，会进行安全性检查。
  - 如果用户通过了检查，系统会返回一个权限（capability），并将该权限与安全性检查的结果一起返回。
  - 这个权限会随着所有后续的远程过程调用（RPCs）一起传递给服务器。
2. RPC检查（RPC Check）： Remote Procedure Call
  - 用户身份信息随着每次远程过程调用（RPC）一起提交。
  - 用户身份信息通常以加密数字签名的形式发送。
  - 服务器会对每个操作进行访问控制检查。
  - 这种方法可以防止身份盗窃，因为每个请求都需要经过身份验证。
3. 这些安全性措施确保了在DFS中每个操作都经过适当的身份验证和访问控制，从而保护了系统的安全性和用户数据的隐私。
4. NFC的例子
  1. 在基本的Sun NFS RPC（Remote Procedure Call）中，每个请求都需要携带未加密的16位用户ID（userID）和组ID（groupID）。这些信息与文件属性中的访问权限进行比对。在最简单的形式中，用户ID和组ID并不加密。这意味着任何人如果知道有效的用户ID和组ID，就可以执行文件操作。
    
    为了解决这个问题，Sun RPC 协议进行了修订，引入了DES（Data Encryption Standard）加密。通过加密，用户ID和组ID等敏感信息在传输过程中得到保护，提高了系统的安全性，防止了未经授权的访问和操作。