1. 首页
  2. 文档
  3. IPFS集群 | IPFS Cluster
  4. 用户文档 | User Documentation
  5. 生产部署

生产部署

本节专门用于部署IPFS集群并以稳定的方式运行它。它描述了:

确保您首先熟悉“ 配置”部分。

集群中的所有IPFS集群对等节点必须运行** ipfs -cluster-service 的**版本** 。

部署方法

本小节提供了部署IPFS集群的不同策略。

使用Ansible进行部署

如果您有一些主机并且希望在IPFS集群上运行稳定部署,则可以使用这些  Ansible 角色。他们提供:

  • 要安装的角色 go-ipfs 和IPFS集群二进制分发。
  • 两个模板化的配置  ipfs-cluster-service 和 go-ipfs
  • systemd服务文件来管理生命周期

使用Docker进行部署

如果要运行  /ipfs/ipfs-cluster Docker容器,则需要注意以下几个注意事项:

  • 容器不运行  go-ipfs。您应该运行IPFS守护程序,例如,使用  ipfs/go-ipfs Docker容器。
  • 我们建议安装  /data/ipfs-cluster 文件夹以提供自定义的工作配置以及集群数据的持久性。这通常通过传递-v <your_local_path>:/data/ipfs-cluster 到  docker run)来实现  。

启动  ipfs-cluster Docker容器时,如果找不到  /data/ipfs-cluster/service.json 文件,则默认入口点脚本将:

  • 运行ipfs-cluster-service init
  • 并对默认配置进行以下更改:
    • api/restapi/http_listen_multiaddress 将被设置为使用  0.0.0.0 而不是  127.0.0.1
    • ipfs_connector/ipfshttp/proxy_listen_multiaddress 将被设置为使用  0.0.0.0 而不是 127.0.0.1
    • ipfs_connector/ipfshttp/node_multiaddress 将设置为  $IPFS_API 环境值的值。
除非您使用docker,否则您  --net=host需要设置  $IPFS_API 或确保配置正确  node_multiaddress

请确保阅读配置文档 ,以获取有关如何配置IPFS集群的更多信息。

您可以在docke运行ripfs-cluster-service时,为ipfs/ipfs-cluster传递任何自定义参数和子命令为。默认情况下,它运行  daemon --upgrade

帮助完成此部分

如果您使用不同的方法部署IPFS集群(docker,kubernetes,puppet等)并分享您的专有技术,我们将非常感激。请在网站存储库中告诉我们  。

在生产中运行IPFS集群

本小节为运行go-ipfs 和 IPFS Cluster 稳定的生产环境提供了有用的信息  。

service.json 配置调整

配置文件包含一些选项,应根据您的环境,容量和要求进行调整:

  • 如果同步操作变得昂贵,在处理大量引脚时,您可能会进一步增加cluster.state_sync_interval 和 cluster.ipfs_sync_interval
  • 考虑增加  cluster.monitor_ping_interval 和  monitor.*.check_interval。这意味着集群花了多长时间来实现对等节点没有得到响应(并触发重新引脚)。在您的集群中重新固定可能是非常昂贵的。因此,您可能希望将其设置得高一点(几分钟)。您可以为两者使用相同的值。
  • 在同样的考虑下,如果您不希望在对等节点停机时间内完全触发重复,则可能需要设置  cluster.disable_repinning 为true。
  • 设置  raft.wait_for_leader_timeout 为能够为所有节点提供充足时间重新启动并无需联机。通常 30s 或 1m
  • 如果您的网络非常不稳定,您可以尝试增加  raft.commit_retries,  raft.commit_retry_delay。注意:更多重试和更高延迟意味着更慢的故障。
  • Raft选项:
    • 对于高延迟集群(就像世界各地的节点),你可以尝试增加  heartbeat_timeout, election_timeout,  commit_timeout 和  leader_lease_timeout,虽然默认值是相当大的了。对于低延迟集群,这些都可以减少(至少减少一半)。
    • 对于非常大的引脚组,请增加  snapshot_interval。如果您的集群执行许多操作,请增加 snapshot_threshold
  • api.restapi 根据您的API使用情况调整网络超时。这可以防止滥用API或DDoS攻击。请注意,通常也可以修改客户端超时。
  • ipfs_connector.ipfshttp 如果您以相同的方式使用ipfs代理,请调整网络超时。
  • 设置  pin_method 为  refs (现在是默认值),但确保未启用auto-GC  go-ipfs (这是默认值)
  • 如果您正在摄取大量引脚,请增加  pin_tracker.maptracker.max_pin_queue_size。这是在给定时刻,可以排队等待固定的事物的数量。
  • 如果  refs 用于  pin_method,增加  pin_tracker.maptracker.concurrent_pins。该值取决于您希望同时下载ipfs的内容。 3 到  15 应该没问题。
  • 您可能会增加  informer.disk.metric_ttl,虽然在go-ipfs 0.4.17 开始  ,但应该可以快速有效地获取更新的磁盘指标。

go-ipfs 配置调整

  • 使用server 配置文件初始化ipfs: ipfs init --profile=server 或者  ipfs config profile apply server, 如果配置已存在。
  • 对于非常大的存储库,启用Badger数据存储区():
[BACKUP ~/.ipfs]
$ ipfs config profile apply badgerds # or ipfs init --profile=server,badgerds
$ ipfs-ds-convert convert # Make sure you have enough disk space for the conversion.
$ ipfs-ds-convert cleanup # removes the backup data

确保您有足够的空间进行转换。

  • 如果使用refs 钉扎方法,请勿启用自动GC
  • 增加  Swarm.ConnMgr.Highwater (最大连接数)并减少  GracePeriod 到  20s
  • 根据您的回购大小(以字节为单位): 1048576(1MB)来加  Datastore.BloomFilterSize 是很有价值的(更多详细信息)
  • 根据您想要专用于ipfs repo的磁盘,给Datastore.StorageMax 设置一个值。
  • IPFS_FD_MAX环境变量控制go-ipfssets自身的FD ulimit值根据您的  Highwater 值,您可能希望将其增加到  4096

重启时自动升级

为了便于快速升级,请确保您的系统启动并重新启动IPFS集群和  go-ipfs节点对等,如下所示:

ipfs-cluster-service daemon --ugprade
ipfs daemon --migrate

系统服务文件

修改peerset:添加和删除对等节点

本小节介绍了如何修改集群的peerset。peerset由consensus 实现维护  ,因此指令特定于所使用的实现。目前,只有 raft实施可用。

Raft共识

Raft是我们默认的共识实现。它提供高可用性,防止网络分裂和快速状态收敛。它适用于在可信环境中运行的小型集群(要确定的小手段,但可能<20个对等)。

缺点是Raft在更新集群peerset时需要严格的程序,以确保一致性和正确的协商操作。实际上,更新  peerset 是Raft中的提交操作,这意味着它总是需要一个正常运行的引导者(因此,peerset中的大多数对等节点需要联机才能使其生效)。

添加节点

添加同行应该总是以进行  自举  的解释  在这里

删除节点

删除对等节点是该节点的最终操作。这意味着,除非清除其Raft状态(ipfs-cluster-service state clean),否则该对等节点不能(不应该)再次启动。

删除对等节点可以使用ipfs-cluster-ctl来完成,它调用DELETE/peers/Id> API端点:

ipfs-cluster-ctl peers rm <peerID>

一个节点ID像是QmQHKLBXfS7hf8o2acj7FGADoJDLat3UazucbHrgxqisim。删除对节点具有以 下效果:
  • 被删除的对等节点将自行关闭并清理其状态(剩余备份)。该  peers 配置值将被清除,以避免意外重新开始乱用现有集群。
  • 已删除的对等节点将自动从peers 其余对等节点的配置值中删除  。
  • peers rm 也适用于离线同行。 删除后不应重新启动脱机对等节点
该  `leave_on_shutdown`选项  会触发正常关机自动清除。

监控和自动重新固定

IPFS集群包括一个监视组件,可在不再续订度量标准时收集度量标准并触发警报。目前有两种类型的指标:

  • informer 度量标准用于在引脚请求到达时决定分配。可以配置不同的“informers”。默认值为 disk informer,从IPFS中提取回购信息,并发送自由空间度量。
  • 一个  ping 度量用于定期信号通知运行的对等节点。

每个指标都带有与之关联的生存时间。可以在informer配置部分配置此TTL  。所述  ping 度量TTL是由确定的 cluster.monitoring_ping_interval,并且等于2倍其值。

每个IPFS集群对等节点定期向所有其他对节点广播度量。对于informer指标和集群,这会发生TTL / 2间隔。ping指标的monitoring_ping_interval

当现有集群对等节点的度量标准停止到达且先前度量标准已超过其生存时间时,监视组件将触发该度量标准的警报。 monbasic.check_interval 确定监视组件检查过期TTL的频率并发送这些警报。如果您希望更快地检测到过期的指标,请减少此间隔。反之,则增加它。

IPFS集群对等节点将通过搜索分配给警报对等体的引脚并触发针对它们的重新固定请求来响应ping度量标准警报,除非该  cluster.disable_repinning选项是  true。如果CID的分配因子越过replication_factor_min 边界,则这些重新钉扎请求可能导致重新分配  。否则,保持当前分配。

集群中的监控和故障转移系统非常基础,需要改进。当多个节点一次脱机时(特别是当前的Leader受到影响),故障转移可能无法正常工作。可以触发手动重新固定  ipfs-cluster-ctl pin <cid>。 ipfs-cluster-ctl pin ls <CID> 可用于检查分配给CID的当前节点列表。

数据持久性和备份

备份永远不是坏事。本小节解释了IPFS集群的作用,以确保您的pinset不会在灾难事件中丢失,以及您可以采取哪些进一步措施。

当我们谈到备份时,我们通常指的是  ~/.ipfs-cluster/raft 文件夹(状态文件夹),它实际上包含集群的 pinset  和其他特定于共识的信息。

当对等节点从集群中移除,或用户运行时  ipfs-cluster-service state clean,所述 状态文件夹 是不会删除。相反,它被重命名为 raft.old.X,最新的副本  raft.old.0。保留的副本数量是可配置的(raft.backups_rotate)。

另一方面,  raft 另外还会定期捕获pinset的快照(这意味着它完全保留在磁盘上)。这也是在对等节点的关闭时执行的。

当对等节点未运行时,可以手动导出最后一个持久状态:

ipfs-cluster-service state export

这将输出  pinset,然后可以通过以下方式将其重新导入对等节点:

ipfs-cluster-service state import

export和 import 可以用于在灾难事件的情况下,当集群中的对等节点脱机时,或者没有足够的对等节点可以启动达到仲裁(使用时raft)时抢救状态  。在这种情况下,我们建议在新的,干净的单对等节点集群上导入状态,并手动将集群的其余部分引导到该集群。

后续步骤:  故障排除

这篇文章对你有帮助吗? 1

我们要如何帮助您?