冲突验证
我们使用 NetApp StorageGRID 中的 Confluent Platform 6.2 分层存储执行了验证。NetApp 和 Confluent 团队共同执行了此验证,并运行了验证所需的测试用例。
Confuent Platform 设置
我们使用以下设置进行验证。
为了进行验证,我们使用了三个 Zookeepers ,五个代理,五个测试脚本执行服务器,命名为 Tools 服务器,该服务器具有 256 GB RAM 和 16 个 CPU 。对于 NetApp 存储,我们使用的是带有四个 SGF6024 的 SG1000 负载平衡器的 StorageGRID 。存储和代理通过 100GbE 连接进行连接。
下图显示了用于 Confluent 验证的配置的网络拓扑。
工具服务器充当向 Confluent 节点发送请求的应用程序客户端。
融合的分层存储配置
分层存储配置在 Kafka 中需要以下参数:
Confluent.tier.archiver.num.threads=16 confluent.tier.fetcher.num.threads=32 confluent.tier.enable=true confluent.tier.feature=true confluent.tier.backend=S3 confluent.tier.s3.bucket=kafkasgdbucket1-2 confluent.tier.s3.region=us-west-2 confluent.tier.s3.cred.file.path=/data/kafka/.ssh/credentials confluent.tier.s3.aws.endpoint.override=http://kafkasgd.rtpppe.netapp.com:10444/ confluent.tier.s3.force.path.style.access=true
为了进行验证,我们将 StorageGRID 与 HTTP 协议结合使用,但 HTTPS 也有效。访问密钥和机密密钥存储在 confuent.tier.s3.cred.file.path
参数中提供的文件名中。
NetApp 对象存储— StorageGRID
我们在 StorageGRID 中配置了单站点配置以进行分层。
验证测试
我们已完成以下五个测试案例以进行验证。这些测试将在 Trogdor 框架上执行。前两项是功能测试,其余三项是性能测试。
对象存储正确性测试
此测试将根据分层存储的需求确定对象存储 API 上的所有基本操作(例如 GET , PUT 或 DELETE )是否运行良好。这是一项基本测试,每个对象存储服务都应在以下测试之前通过。这是一项自信的测试,无论通过还是失败。
分层功能正确性测试
此测试可确定端到端分层存储功能是否运行良好,并通过或失败的自信测试。此测试将创建一个测试主题,默认情况下,此主题会配置为启用分层并大幅减小热设置大小。它会为新创建的测试主题生成一个事件流,并等待代理将这些分段归档到对象存储,然后使用事件流并验证已使用的流是否与生成的流匹配。生成给事件流的消息数量是可配置的,这样用户可以根据测试需求生成足够大的工作负载。减小的热集大小可确保活动分段之外的使用者提取仅从对象存储提供;这有助于测试对象存储的读取是否正确。我们执行此测试时,无论是否注入了对象存储故障。我们通过在 StorageGRID 中的一个节点中停止服务管理器服务并验证端到端功能是否适用于对象存储来模拟节点故障。
层提取基准测试
此测试验证了分层对象存储的读取性能,并检查了基准测试生成的区块在负载过重时的范围提取读取请求。在此基准测试中, Confluent 开发了自定义客户端来处理层提取请求。
生产 - 使用工作负载基准测试
此测试会通过归档区块在对象存储上间接生成写入工作负载。读取工作负载(区块读取)是在使用者组提取区块时从对象存储生成的。此工作负载由测试脚本生成。此测试检查了并行线程中对象存储上的读写性能。与分层功能正确性测试一样,我们测试了是否存在对象存储故障注入。
保留工作负载基准测试
此测试检查了在主题保留工作负载繁重的情况下对象存储的删除性能。保留工作负载是使用测试脚本生成的,该脚本会与测试主题并行生成许多消息。本测试主题使用主动式基于大小和基于时间的保留设置进行配置,此设置会导致从对象存储中持续清除事件流。然后,这些区块会归档。这导致代理在对象存储中删除了大量内容,并收集了对象存储删除操作的性能。