Chunky Bits

Chunky Bits 是一个简单、无管理的分布式 HTTP 对象存储工具。它不兼容 S3。Chunky Bits 是为了处理常见的用户集群而构建的，该集群可能会随时增长或缩小，并且将包含廉价且不平衡的硬件。

这不是一个自包含的存储解决方案。您需要自己设计自己的存储解决方案。有关更多信息，请参阅推荐的集群。您应该在认为合适的地方使用工具，例如版本控制系统、反向代理、共享文件系统、WebDav 服务器、数据库等。

数据丢失和安全警告

此软件目前处于 alpha 状态。这是一个教育实验，不是一个生产工具。此工具只能在安全网络环境中使用。我对您如何使用此工具以及由此可能产生的任何数据丢失或数据泄露不承担任何责任。您已收到警告。有关详细信息，请参阅 LICENSE 文件。

入门

Chunky Bits 可以使用 cargo 进行编译，它提供了一个单可执行文件，可以提供可用的命令行应用程序和 HTTP 网关。它提供与常见 Linux 工具类似的命令。为了熟悉此工具，请尝试以下命令。您需要一个 cluster.yaml 文件，您可以从示例目录中找到并修改一个，例如 local 集群文件。

chunky-bits cp TESTFILE ./cluster.yaml#TESTFILE
chunky-bits cat ./cluster.yaml#TESTFILE

cp 命令会将您的文件写入集群，并为其创建一个元数据引用。如果您使用的是 path 元数据类型，您将能够将其视为一个文件。

cat 命令将从集群中读取文件。它使用与 cp 相同的文件引用格式。

CLI 文件引用格式

CLI 有几种不同的方式来引用文件，使其非常灵活且在故障排除期间非常有帮助。这些格式中的大部分都支持读取、写入和列表操作。命令将在可能的情况下使用这些格式，并在不支持时出错。

chunky-bits cat ./cluster_file.yaml#path/to/inner/file
chunky-bits -c ./config.yml cat known_cluster#path/to/inner/file
chunky-bits cat @#path/to/file/reference.yaml
chunky-bits cat @#http://remote/path/to/file/reference.yaml
chunky-bits cat -
chunky-bits cat ./path/to/local/file

设计

给定一个文件，Chunky Bits 将将其拆分为部分。一个文件部分将包括 d 数据块和 p 校验块。一个部分将被分发到至少 d+p 个目的地。一个元数据文件将包含至少每个块的校验和、每个块的位置和文件的长度。

目的地是任何可以引用文件的地方，目前仅包括本地路径和 HTTP URL。一个目的地应该是一个运行您选择的文件系统的物理磁盘。

元数据文件以 JSON 或 YAML 格式存储。以下是一个最小示例。

length: 52428800
parts:
  - data:
      - sha256: 4d589118cd5b236df24f79f951df8c4907098b19e25f45ffea3882d6ddcc2f37
        locations:
          - /mnt/repo4/4d589118cd5b236df24f79f951df8c4907098b19e25f45ffea3882d6ddcc2f37
      - ...
    parity:
      - sha256: 1b9acb5b2436dfa1cff8bb0ad39b317c14c8d07214a5a437275d617352ded59b
        locations:
          - https://node2.chunky-bits.local/1b9acb5b2436dfa1cff8bb0ad39b317c14c8d07214a5a437275d617352ded59b
      - ...
  - ...

为了在没有此工具的情况下手动读取文件，需要将所有数据块连接在一起，并将最终长度限制到指定的长度。

for location in "${locations[@]}" ; do
    cat "$location"
done | head -c "$length"

奇偶校验位是字节编码的里德-所罗门纠删码。在修复部分时，请注意数据和奇偶校验部分都是按顺序排列的，并且它们上面没有编码。

为什么不使用 par2？

虽然 par2 简化了修复过程，但文件格式似乎缺乏多种实现。我无法找到 rust 的可用实现。为了减少 Chunky Bits 的维护负担，选择了没有识别文件格式的纯里德-所罗门纠删码。

这导致块顺序是强制性的。如果有人开发了 rust 的 par2 实现，并且维护它，我将很高兴考虑添加 par2 支持。

示例目标配置

可以使用单个服务器和 n 个磁盘设计一个简单的、单一的对象存储。每个磁盘都有自己的文件系统，并作为自己的目标。这将提供 n 个目标。该服务器还可以提供自己的 HTTP 网关。这种配置的潜在问题是它扩展性不好，因为需要更大的服务器来提高吞吐量或容量，并且需要重启以打补丁。其他可以考虑的选项是 RAID 解决方案（硬件 RAID 卡、Linux MD、ZFS、BTRFS 等）或更高级别的企业级对象存储解决方案，如 Minio、Ceph 和 GlusterFS。

可以使用 n 个每个服务器一个磁盘的简单、分布式对象存储。另一个服务器可以托管自己的 HTTP 网关，指向每个服务器作为单个目标。这将为 n 个 n+1 服务器提供 n 个目标。这种配置的潜在问题是流量重复，因为必须从每个目标到网关，网关现在是单点故障，网关也是扩展的单点。其他可以考虑的选项是更高级别的对象存储解决方案，如 Minio、Ceph 和 GlusterFS。

为了扩展分布式对象存储，可以将集群中的每个服务器作为自己的 HTTP 网关。这将允许负载均衡和更好的故障处理。可以使用 DNS 轮询 A 记录、浮动 IP 和专用负载均衡器等组合来实现这一点。同样，企业级解决方案也可以这样做。

基于 Chunky Bits 的优势的示例可以是上述 3 个用例的组合：1 个大服务器提供 n 个目标，m 个小服务器各自提供 1 个目标，以及一些分布式网关。在这种配置中，主要瓶颈可能是那个大服务器。对于写入操作，应将 d+p 块配置得小于 n+m 个目标。这允许您根据每个文件手动调整写入的位置。对于某些文件的更高吞吐量，将它们远离那个大服务器。为了继续使用那个大服务器的容量，将一些不常用的文件写入操作权重偏向那个服务器。这仍然存在一个问题，即如果那个大服务器崩溃，您可能会失去访问某些文件。您还可以将目标权重设置为 0，这将从该写入操作中从集群中删除它们。

在组合示例的基础上再进一步，您可以选择购买（或重用）不同容量的驱动器。只要您的 d+p 小于您的 n 目的地数量，您可以根据空闲磁盘空间配置权重。1 个 16TiB 驱动器并不等于 2 个 8TiB 驱动器，因为一个大驱动器是一个故障点，而 2 个较小的驱动器是 2 个故障点。然而，如果您只写入 3 个数据块和 2 个校验块，并且有 4 个 8TiB 驱动器和 4 个 16TiB 驱动器，您可以将写入权重配置为 16TiB 驱动器比 8TiB 驱动器更有可能接收一个块。尽管在这种情况下，您仍然只能从 8 个驱动器中损坏 2 个，但您仍然可以利用所有驱动器的填充驱动器容量。

以上所有解决方案都基于假设您所有的数据都将驻留在您管理的服务器位置。这的一个后果是，您必须预先购买每个单独的驱动器，包括校验的额外驱动器。然而，由于一个目的地只是一个 WebDav 终端点，这包括作为端点运行与 S3 兼容的对象存储的能力。您可以在您的 n 个本地目的地之外添加云存储提供商作为 m 个远程目的地。这将使您能够在数据丢失之前损坏 m 个本地管理的磁盘。您还将按需支付远程存储的费用，并且可以在集群正常工作时只从集群的本地部分读取，从而降低云数据出口成本。

最后，以上所有解决方案都假设您事先计划好您的集群，这仍然是推荐的。然而，Chunky Bits 允许您按文件对文件进行平衡，手动扩展/缩小集群，使用不匹配的驱动器，以及混合远程和本地存储。企业级工具通常期望您按整个单元计划存储扩展，但鉴于 Chunky Bits 更自由的数据分布方法，这并不必要。