存储优化

使用基于校验和的存储管理数据

Artifactory的优化设计利用了基于校验和的存储，它使用了两个组件:filestore而且数据库．每个二进制文件位于文件存储中(默认为本地磁盘)，并由其校验和(sha1)，使用所有元数据(例如包元数据保存在数据库中的工件名称、大小、创建日期、回购位置、sha256值和签名)。

校验和方法支持工件的唯一标识，而不会在文件存储中重复。远程团队可以使用存储在文件存储中的相同依赖项，这些依赖项来自两个不同的存储库，其中包含从数据库引用的不同元数据。这样可以防止复制，并且消耗更少的存储空间。

将二进制文件与其元数据分离提供了管理数据的灵活性。

• 将工件移动或复制到不同的路径(例如，在促销活动)将只影响数据库和SQL查询，而不影响文件存储。这是因为这只会更改工件元数据，它单独存储在数据库中。

数据库服务器的大小可以按照以下比例调整:文件存储的1/100。这不是一个严格的公式，它是为了给您一个初始大小。确保监视您的DB存储。

在调整您的DB存储时，请记住在Artifactory升级期间，数据库模式可能会被修改，并创建临时表，这将增加您所需的DB存储。

默认情况下，Artifactory与Apache Derby数据库一起安装。该数据库可以随时迁移到其他关系数据库。也可以使用Database As A Service，只要它们依赖于受支持的数据库和版本。

>了解更多关于支持的数据库和版本

缓存二进制文件以获得更好的性能

开箱即用，Artifactory在本地存储所有工件，不需要任何活动缓存。在Artifactory中可以启用两种类型的缓存:Cache-fs而且最终．

1. Cache-fs:读缓冲区，用于优化Artifactory和远程存储(例如NAS或云存储)之间的流量。这个“最近最少使用”(LRU)缓存将托管最近上传和下载的工件。启用它可以减少发送到网络存储的请求数量，从而减少响应时间。由于可以设置最大大小，所以缓存中的工件将根据它们最后的下载日期或创建/修改日期“旋转”。
   *适用于专业和企业许可证
   

   在并发连接请求尚未缓存的二进制文件的情况下，cache-fs将只让第一个连接从远程服务器下载二进制文件，而其他连接将开始流处理已经下载的字节。

2. 最终:写缓冲区，用于在使用慢速存储和/或远程存储时优化上传过程中的慢速。默认情况下，对于所有依赖于对象存储的Artifactory存储模板(如AWS S3、Azure Blob storage等)，该缓冲区都是启用的。这允许实现异步上传，以便不等待工件被上传到远程存储，而直接使用它。一旦工件上传到存储中并在Artifactory中可用，它将从最终的缓存中删除。与cache-fs不同，它没有可以调优的缓存大小限制。承载此缓存的磁盘大小将设置限制，应该对其进行监视。

建议将这些缓存安装在具有最高可用IOPS和低延迟的磁盘上。

调优您的缓存

Cache-fs:它的位置和它的最大大小应该根据你的企业需求来调整，特别是后者，因为它将指定缓存何时旋转，你可能想要确保大量使用的二进制文件被缓存。例如，如果你的一个用例是:

• 消费码头工人的图片，您可能希望缓存属于基本图像的所有层
• 快速配置你的linux服务器，你可能需要缓存最新的操作系统包(debian, rpm)
• 加速构建，您可能想要缓存最常用的开发依赖项

启用时，该缓存默认设置为5gb。

使用人工查询语言(AQL) 使用AQL查询获取最近下载和上传的工件的列表，这将返回工件的列表及其大小。使用脚本来添加工件大小并得到一个估计。

最终缓存:在binarystore.xml这样的模板如s3-storage-v3, azure-blob-storage, google-storage，Cluster-s3-storage-v3、cluster-azure-blob-storage和cluster-google-storage。它的位置,$ ARTIFACTORY_HOME /数据/最终而且它的大小无法调整。由于最终缓存将对所有要上传到对象存储的二进制文件进行排队，请确保为最终缓存分配的存储空间将高于最大的批量上传。
这可能是您的最大工件或已发布工件的大小建立信息．
增加专门用于上传的线程数量也可以作为调优的一部分。

每次调优都直接影响您的Artifactory实例。了解更多关于如何监控它们的信息．同时，了解更多关于牛蛙，一个Artifactory的开源监控工具。

存储配置选项

在软件工程中，将数据层和配置层与应用程序层分离是一种常见的最佳实践。将数据和配置存储在服务主机外部的不同位置将非常有益，特别是从监控、升级、备份/恢复和可伸缩性等操作方面来说。

根据您的组织需求，有几种不同的文件存储配置可供选择。本文档涉及负责存储和基础设施的IT团队。介绍Artifactory中的4种存储配置类型:

1. 自管理文件和块存储(本地存储、NAS、SAN)
2. 云文件存储(例如AWS EBS或EFS、Azure磁盘或文件)
3. 对象存储(例如AWS S3或Azure Blob storage)
4. 数据库存储

的中指定的模板在Artifactory中定义文件存储配置binarystore.xml． 有几个模板可用，并且完全可配置。

1.自管理文件和块存储(本地存储、NAS、SAN)

备注:NFS版本。*和4。*支持。

在Artifactory高可用集群配置中，所有成员共享相同的文件存储，并发访问在文件系统级别进行管理。

用例1:没有基础设施限制

您的IT团队将通过高可用的NAS或SAN解决方案来管理二进制文件的可用性，并且没有任何关于NFS挂载点或SAN卷的大小限制。

推荐模板: filesystem和cache-fs

在Artifactory独立配置中，文件系统模板可以通过引用您的挂载点或本地文件夹(指向SAN卷)作为二进制文件的位置来满足您的需求。选择cache-fs模板将启用读缓存(参见“缓存”一节中的cache-fs)，当经常下载大的二进制文件(从数百MB到GB)时，这将带来很大的好处。二进制文件将在本地保存，为了将来的请求，到达远程存储的网络时间将被完全抑制。

文件系统模板

Cache-fs模板

在Artifactory集群配置中，所有节点将使用相同的挂载点。

通过扩展现有卷并实际为NFS挂载或卷分配更多空间，可以垂直(向上)实现存储扩展过程。

用例2:限制跨站点的存储大小或存储可用性

您的IT团队将管理二进制文件的可用性，但对磁盘大小有限制，这将影响您扩展专用于Artifactory的存储的方式。

推荐模板:双分片或冗余分片

了解更多>关于filestore分片

这两个模板之间的主要区别是冗余参数，即每个二进制文件在碎片之间分布的副本数量。如果您的IT团队保证了冗余存储(例如高可用的NAS)，那么您就不需要Artifactory来管理冗余，并且可以使用冗余= 1的“双碎片”模板。双分片模板实现了文件存储分片，其中每个碎片表示全局文件存储的一部分，其中一个碎片可以是一个挂载点(NAS或SAN)。这允许您通过添加更多碎片来扩展存储。

如前所述，模板是可调的，参数更改如下:

• 碎片的数量(默认情况下，它们设置为2个碎片)
• 冗余——每个二进制文件在碎片中分布的副本数量
• 写机制:每个分片的可用空间，每个分片的可用空间百分比或轮询。
  • 设置轮流捡取(默认):使用轮询策略将二进制文件写入每个mount。
  • 空闲空间:二进制文件被写入具有最大绝对可用空间容量的挂载。
  • percentageFreeSpace:根据可用空间的百分比将二进制文件写入挂载。

这些模板还支持每个Artifactory实例的读缓存(请参阅“缓存”部分中的cache-fs)。在集群配置中，这些缓存是不同步的。此配置可以应用于独立部署和集群部署。对于每个Artifactory实例，所有安装都应该是可用的。

缩放过程可以通过增加碎片大小来垂直完成，也可以通过添加更多碎片来水平完成。

独立的: Redundancy = 2, Mount (Shard) = 2, LenientLimit = 1

冗余必须小于或等于Artifactory系统中的安装数。如果没有达到冗余指定的写数量(例如挂载失败)，则WRITE事务将失败。

“宽松限制”是验证“WRITE”事务/上传过程的成功写的最小数量。它的默认值是1，如果设置为0,Artifactory将认为它等于冗余参数。

一旦二进制文件的副本数量达到了“宽松限制”或“冗余”所定义的要求，WRITE事务将被提交。为了优化传输，Write事务依赖并发流将二进制文件复制到多个碎片上。

在这种情况下，a恢复系统将在每次垃圾收集器执行后在文件存储中重新应用冗余。

的maxBalancingRunTime参数定义了每次垃圾收集器运行后恢复系统的持续时间。

的优化存储Rest API允许您手动应用一个新的冗余或重新应用当前的一个碎片失败。在这两种情况下，冗余都必须大于1。 该进程将在下一次垃圾收集器运行后执行。

Artifactory不知道哪些碎片保存了二进制文件，这允许您将它们从一个碎片移动到另一个碎片。

独立的:冗余=1, Mount (Shard) = 2, LenientLimit = 1

集群: Redundancy = 1, Mount (Shard) = 2, LenientLimit = 1

冗余度越高，平均检索时间(“READ”)就越低。
然而，更高的冗余将增加工件上传(“WRITE”事务)的持续时间以及碎片的数量。冗余级别还会影响Artifactory所需的总存储空间。

默认情况下，文件存储分片被配置为服务于单个区域中的碎片，但您可以通过将碎片分配到特定的区域将其扩展到多个。有了这个实现，您还可以覆盖IT团队不跨数据中心/站点/区域管理冗余的用例。

独立的: Redundancy = 2, Mount (Shard) = 4, LenientLimit = 1

集群: Redundancy = 2, Mount (Shard) = 4, LenientLimit = 1

该配置既可以应用于独立部署，也可以应用于集群部署。所有挂载应该对所有Artifactory节点可用。

警告:要注意区域之间的延迟，因为编写二进制文件的副本将是一个单一事务。

警告:在设置您的Artifactory HA集群．

用例3:存储管理限制

您的IT团队对每个服务器的挂载点数量有限制，或者没有为您的Artifactory提供正确的存储SLA，并且您优先处理数据的可用性。

推荐模板: filesystem、cache-fs、cluster-fs

在独立配置中，您将依赖于文件系统或缓存-fs。
有关更多细节，您可以参考用例1。

在Artifactory集群配置中，可以使用cluster-fs模板，并且每个Artifactory实例都有自己的本地文件存储(也称为shard)，该文件存储将指向NFS挂载、挂载的SAN卷甚至本地存储。Artifactory集群将管理这个由多个碎片组成的“超级文件存储”。缓存-fs将在每个Artifactory实例上被激活。默认情况下，该模板使用2个冗余，这意味着在一个2节点的HA集群中，每个碎片将包含完整的文件存储。这保证了站点关闭的可能性没有影响。
伸缩过程可以通过增加磁盘大小来垂直完成，也可以通过向集群中添加更多Artifactory节点来水平完成。

集群:冗余= 2,Mount (Shard) = 2(文件存储托管在附加磁盘上)，LenientLimit = 1

警告:在设置您的Artifactory HA集群．

的分片集群提供者继承的优化分片提供者，用于文件存储分片，例如宽松的限制和并发流将一个二进制文件复制到多个碎片。

的优化存储Rest API允许您手动应用一个新的冗余或重新应用当前的一个碎片失败。在这两种情况下，冗余都必须大于1。 该进程将在下一次垃圾收集器运行后执行。

的maxBalancingRunTime参数定义了每次垃圾收集器运行后恢复系统的持续时间。

集群:冗余= 2,Mount (Shard) = 2(文件存储托管在远程存储上)，LenientLimit = 1

冗余度越高，平均检索时间(“READ”)就越低。 然而，更高的冗余将增加工件上传(“WRITE”事务)的持续时间以及碎片的数量。冗余级别还会影响Artifactory所需的总存储空间。

cluster-fs模板不支持多分区。

cluster-fs模板不支持每个Artifactory实例的多个挂载点。

2.云文件存储

Artifactory文件存储也可以在云环境中集成，方法与在自己的数据中心中集成的方法相同。由于其目的是委托硬件维护和二进制文件的可用性，您可能希望从传统的文件存储切换到同样受支持的对象存储(参见下一节)。本节将介绍您希望坚持在云环境中存储文件的情况。

推荐模板:cache-fs、cluster-fs

一般的最佳实践可以应用于on-prem和云环境。

启用cache-fs，并根据您的需要和预算将其安装到具有适当IOPS的磁盘上。如果读缓存对于您的用例非常重要，那么将它存储在持久磁盘中。SLA将判断您是否可以在性能和弹性之间进行权衡。

主要的云提供商还提供可自动扩展的共享磁盘(用于AWS的EFS、Azure文件、谷歌云文件存储)，您可以在这些磁盘中存储二进制文件。尽管它们提供了良好的性能和可伸缩性，但它们通常比管理持久磁盘(用于AWS的EBS、Azure托管磁盘、谷歌持久磁盘)或使用对象存储要昂贵得多．

在Artifactory HA中使用Amazon弹性文件系统(EFS) 在使用AWS EFS之前，阅读更多关于爆发模式如何影响您的Artifactory性能的信息并推荐了最佳实践。

2.对象存储

推荐模板:cluster-s3-storage-v3 cluster-azure-blob-storage和cluster-google-storage。

随着云提供商的出现，对象存储已经普及开来，它可以成为IT团队轻松将存储容量扩展到不同数据中心的另一种解决方案。Artifactory还可以依赖于这种类型的存储，并实现特定的特性来完全支持它，如读/写的重试机制、读缓存和冗余“写缓存”(参见缓存部分)，以减少来自远程存储的延迟并支持异步上传。对于特定的云提供商和支持S3协议的任何对象存储，都可以使用几个文件存储模板。

下图解释了这些模板如何利用缓存来防止数据丢失和优化上传过程。写/最终缓存依赖于sharding-cluster提供者，用于cluster-fs模板(参见P12)上传到对象存储(兼容openstack swift接口)的过程中，保证二进制文件的可用性。

集群: Redundancy = 3(在最终缓存中)，LenientLimit = 2(在最终缓存中)

写/最终缓存是冗余的，读缓存/cache-fs不是。

写/最终缓存依赖于与cluster-fs相同的机制（sharding-cluster提供者)确保上传到对象存储的过程中二进制文件的可用性。这是通过将二进制文件的副本分散到几个最终缓存(冗余参数)来实现的。宽松限制是另一个参数，它指定为验证“WRITE”事务要执行的最小成功写操作。

如果上传到对象存储失败，将触发一个重试机制，并对最终缓存进行连续扫描。虽然对象存储不可用，但Artifactory将使用cache-fs作为二进制文件的“源”。请记住缓存-fs有一个最大大小，并且只保存最近下载/上传的二进制文件。

每个“集群”模板都有一个“无集群”实现，其中最终缓存不是冗余/同步的。

“集群”模板名称	模板名称为“无集群”
cluster-s3-storage-v3	s3-storage-v3
cluster-azure-storage	azure存储
cluster-google-storage	google storage

这些“无集群”模板最初覆盖独立配置。在HA集群配置中，最终缓存必须是冗余的，以防止任何二进制数据丢失。这种丢失可能发生在中间阶段，此时Artifactory节点已经在其缓存中完成了二进制文件的存储，并开始将其上传到对象存储，在此过程中，它会停止运行。避免这种情况的最简单的解决方案是依赖于共享存储。使用“集群”模板，Artifactory通过设置冗余参数来将相同二进制文件的副本分发到多个最终缓存，从而完全管理这种情况。

4.数据库

默认情况下，Artifactory将二进制文件与其元数据分离。二进制文件存储在文件存储中，而它们的元数据存储在数据库中。虽然可以将二进制文件作为BLOB存储在数据库中，但不建议这样做，因为数据库在存储大型文件时有限制，这可能导致性能下降并对操作成本产生负面影响。

数据恢复策略

垃圾桶应该是数据恢复的第一个选项，因为默认情况下，任何删除的工件都将在那里结束。可修改垃圾桶的保存时间，设置为14天。注意，在进行存储大小调整时，应该将这作为整体存储分配的一部分来考虑。

您选择的数据恢复将取决于您的文件存储的大小、您的恢复点目标和Artifactory的恢复时间目标要求。

• 1TB以下的文件存储不使用对象存储:
  您可以使用Artifactory内置的备份系统，该系统将在Artifactory主机服务器上聚合二进制文件、它们的元数据和通用配置。在集群设置中，备份将由执行备份任务的节点生成(默认情况下是主节点)。

• 1TB以下的文件存储使用对象存储或1TB以上的文件存储使用对象存储或不使用对象存储:
  内置备份可能不尊重您关于RTO的SLA，建议基于与文件存储备份同步的数据库备份/快照管理备份策略，这可能依赖于服务(例如S3版本控制)或第三方it工具/服务。记得备份配置文件夹。

默认情况下，备份文件夹将保存在本地$ARTIFACTORY_HOME/backup中。确保存储至少是当前文件存储的3倍，因为备份不会从校验和优化中受益，它将包含存储在数据库中的所有元数据。您还可以将其存储到特定的卷(专用磁盘)中，以确保在空间不足的情况下，这不会影响Artifactory。

如果决定在共享挂载上执行备份，请检查磁盘是否具有尽可能高的IOPS和较低的延迟(位于同一数据中心的远程存储)。

为了降低RPO，您还需要依赖一个灾难恢复/镜像站点，它可以是被动的(Cold DR)来重新加载备份，也可以是主动的，在那里您可以利用数据库和存储复制。

了解更多>关于管理备份和灾难恢复的最佳实践。

结论

Artifactory是一个优化的二进制管理器，它专注于以最有效的方式管理、存储和检索二进制文件，这得益于其基于校验和的存储和读写缓存。在本白皮书中，我们介绍了基于基础设施和存储需求的不同存储配置。作为二进制文件的来源，应该基于您自己的SLA实现备份和恢复策略。

本白皮书旨在根据您的需要帮助您更好地理解Artifactory存储设置和配置。希望它将允许您使用Artifactory作为二进制文件的主要来源，并充分利用它的潜力。