当AEM配置为使用S3数据存储时，它会使蓝绿部署更快吗？

Question

出身背景

我们知道，通过使用crx2oak将内容从旧环境迁移到新环境，可以建立一个devops管道，通过蓝/绿方法将更新部署到AEM。为什么超出了这个问题的范围。

这种方法的问题是，随着JCR中内容数量的增加，内容复制操作可能会花费大量时间。赞赏其他对此的想法。

我们还知道，AEM可以有一个S3数据存储，将二进制内容卸载到S3存储桶中，该存储桶在蓝色/绿色部署期间不会重新构建，如下所示：

https://helpx.adobe.com/experience-manager/6-3/sites/deploying/using/storage-elements-in-aem-6.html#OverviewofStorageinAEM6

Adobe的留档不清楚的是，同一个S3桶是否可以在AEM实例（即蓝色/绿色实例）之间共享。也许只是我的谷歌福失败了...

问题

当一个新的AEM实例被配置为使用S3数据存储，其中已经有来自旧实例的内容时，当crx2oak用于迁移内容时，新实例是否能够访问现有内容？

是否有文章/博客描述了这种方法可能节省的时间？

是的，我可以做一个实验，将来也可以这样做来回答我自己的问题。我正在从任何已经做过这件事的人那里寻找信息？我是一名工程师，所以如果别人发明了轮子，我就不会再发明了。

Answer 1

外部数据存储会有很大帮助，因为通常二进制资产使用的空间最多。由真人输入的纯内容要少得多。

关于我目前的项目（相当小，但关系应该正常）：

• 存储库总计4.8 GB（4.1 GB段存储，780 MB索引）
• 文件数据存储总计222 GB

如果你想这么做，我有以下几点意见：

>

有不同的可用数据存储。为了测试，我将从文件数据存储开始。

在我看来，S3数据存储只有在亚马逊AWS托管的情况下才有意义。奥多比托管服务正在这样做，所以S3对他们来说是有意义的。但也只有当你有超过500 GB的资产时。

如果使用绿色/蓝色方法，那么要小心数据存储垃圾收集（只需手动执行）。共享数据存储是为几家内容相同的出版商设计的。例如，您可能会遇到以下情况：编辑器删除一些资产，运行数据存储GC，最后回滚环境。这意味着资产仍在内容存储库中，但二进制文件已从数据存储中清除。

要使用共享文件数据存储，需要执行以下操作：

1. 解压缩Quickstartjava-jar AEM_6.3u Quickstart。jar-解包
2. 为文件数据存储创建一个目录（crx quickstart文件夹之外的任何地方）
3. 在解压缩的crx quickstart文件夹中创建一个目录install
4. 创建一个名为org的文件。阿帕奇。大野兔。橡树插件。斑点。数据存储。文件数据存储。cfg在此安装文件夹中
5. 这个文件只包含一行路径=

你好，亚历克斯

Answer 2

您当然可以在实例之间共享相同的S3存储桶——事实上，这通常与author的无二进制复制一起使用-

甚至可以在完全不同的环境（例如DEV/STAGE，或者在您的情况下是BLUE/GREEN）之间共享同一个bucket。需要注意的主要“问题”是关于数据存储垃圾收集（DSGC），因为很可能会有只被共享bucket的一些实例引用的Blob，因此在清除未使用的Blob时，需要考虑这一点。

不过，这都是设计的一部分，有一个专门为此目的设计的标志，它告诉DSGC只执行GC的第一阶段（标记阶段），跳过第二个“扫描”阶段，直到所有实例都标记了它们希望保留/丢弃的Blob。一旦所有实例都完成了，就可以运行扫描阶段来清除任何使用桶的实例不需要的Blob。

有关更详细的解释，请参阅橡树文档：https://jackrabbit.apache.org/oak/docs/plugins/blobstore.html#Shared_DataStore_Blob_Garbage_Collection_Since_1.2.0

我发现这有助于理解，几乎所有的数据存储实现都是按照blob的校验和进行存储的，因此添加两次的同一个文件在数据存储中将只存储一个副本，并且将有两个段存储记录引用同一blob。同样，共享同一个bucket的多个AEM实例将能够找到给定的blob，而不管是哪个实例首先将其放在那里。

通过找到一个blob并sha256，您可以在FileDataStore中轻松观察到这一点，例如（这个例子在OS X上，Linux/Windows上的checksum命令将略有不同）：

$ shasum -a256 crx-quickstart/repository/datastore/0c/9e/40/0c9e405fc8d0f0405930cd0044611cfbf014938a1837ae0cfaa266d7732d1002

0c9e405fc8d0f0405930cd0044611cfbf014938a1837ae0cfaa266d7732d1002  crx-quickstart/repository/datastore/0c/9e/40/0c9e405fc8d0f0405930cd0044611cfbf014938a1837ae0cfaa266d7732d1002

在这里，你可以看到a）文件名是校验和，b）它是使用校验和中的前3对字符嵌套的，所以你可以通过知道散列来定位文件，如果你存储相同的二进制文件，即使名称或JCR元数据不同，引用的blob也将是磁盘上相同的文本文件。

从内存S3数据存储使用前缀而不是目录嵌套，因为这种性能更好，但原理是相同的。

最后，要考虑的两件事是：

1） S3存储相对便宜（而且实际上是无限的），因此有一种观点认为，除非你真的想省钱，否则没有必要执行常规的DSGC。

2）如果您确实运行DSGC，您需要考虑这将如何与您为AEM实例使用的任何备份策略一起工作。例如，如果您在运行DSGC后不久回滚段存储，您可能需要恢复一些清除的Blob。您可以使用版本控制和/或生命周期规则来帮助解决这个问题，但这可能会给还原过程增加显著的额外复杂性和时间。

如果您选择简单地跳过DSGC并将Blob无限期地留在那里，那么最好确保AEM正在使用的访问密钥或IAM角色没有桶的DeleteObject权限，只是为了确保流氓GC进程不能删除任何内容。

希望这有帮助。

我忘了回答你的问题——是的，在大多数情况下，这会节省克隆的时间。你仍然需要同步段存储（显然），有多种方法可以实现这一点crx2oak当然是其中之一——您会在文档中看到，在提供配置文件（基本上是一个序列化的.config文件，就像您在Felix/OSGi中使用的那样）的情况下，可以通过S3使用它。

您还可以使用类似于rsync的方法简单地复制TAR文件（至少目标AEM已停止。Oak通常是原子的，因此理论上可以从源代码进行热拷贝，但是YMMV）。

最后，您显然可以使用Mongo并以这种方式对段存储进行集群，但这样做的所有常见成本/复杂性/性能问题都适用）。

蓝色/绿色类型的另一个有趣发展是CompositeNodeStore——2017年Adapto（）大会上有一篇很好的演讲，谈到了这一点：

https://adapt.to/2017/en/schedule/zero-downtime-deployments-for-the-sling-based-apps-using-docker.html