当前Kafka容器化部署正成为银行业解决这类问题的一大实践趋势，而在Kafka容器化部署的落地实施过程中，需要面临的一个核心问题：做好Kafka存储的技术选型。Kafka的存储需求，在功能面，由于存贮的数据是消息流，数据量级非常大，需要数据CRUD操作足够简单，主要为并发非常高和百万级TPS的追加写、无需更改、能根据消费位移offset和时间戳timestamp查询消息、能定期删除过期的消息；在非功能性面，需要实现高性能要求、高可用的稳定性要求、高扩展性要求。

本期联创测试方案主要围绕Kafka容器化部署改造的可行性验证过程中，基于OKD(k8s)+NAS存储的技术架构的高可靠、高性能的Kafka容器化集群进行测试实践、总结经验，最终以《银行业Kafka容器化服务测试报告》与同行分享交流，共同探讨银行容器云环境下如何架构设计稳定、高性能的Kafka持久化存储方案。欢迎同行阅读测试报告和交流探讨！

为了能更好的解决大家在Kafka容器化部署实施时遇到的建设难点，本期的交流重点围绕以下4个部分进行总结：
Kafka容器化建设难点和关注点；
Kafka容器化建设方案重点考虑的涉及层面；
Kafka容器化的存储选型 ；
交流总结共识部分。

一、Kafka容器化建设难点和关注点

1、Kafka容器化服务对银行行业的业务和技术有什么启示和建议？

嘉宾回复：

rechen 云计算架构师 , 招商银行
Kafka容器化服务对银行业务方面的价值，一是能够支持实现快速交付和部署业务系统；二是利用K8S平台的故障恢复机制，通过POD重启、漂移等方式快速规避故障，将故障对业务系统的影响降低到最小。

Kafka容器化服务对银行技术方面的价值 ，一是支持轻量高密的部署，可以节约服务器物理资源；二 是有良好的扩展性， 可以对Kafka集群实现横向和纵向快速扩容；三是有利于实现自动化运维和故障自愈，有效地降低运维成本。

2、使用kafka和rabbitmq作为消息服务云平台的方案各有什么优劣？

使用kafka+nas的方案与rabbitmq+本地盘的方案，有什么优劣对比？

嘉宾回复：

rechen 云计算架构师 , 招商银行
Kafka和RabbitMQ各自的架构设计和技术特性，决定两者有相应的适合的应用场景。 譬如 kafka是分布式且 高吞吐量的消息服务平台 ，宜作为消息传输的数据管道 ，较多用于日志收集、实时数据处理、消息系统、以及流处理等场景。

rabbitmq有高可靠性的设计，支持多种消息确认机制，确保消息不会丢失， 并提供了丰富的功能和 API ，可满足不同的消息处理需求 。宜作为交易数据作为数据传输管道，譬如常用于金融实时性的业务场景。

下面是Kafka和RabbitMQ的特性对比表：

3、kafka容器化，使用nas作为持久化存储的稳定性如何？

kafka容器化，使用nas作为持久化存储的稳定性如何，与hostpath对比有何优势，是否可靠？当nas出现问题，或者网络波动，将如何应对？

嘉宾回复：

rechen 云计算架构师 , 招商银行
1、 K8S的HOSTPATH方式是使用本地盘，存储在本地盘的数据可靠性较弱，出现节点故障时，KAFKA需做数据平衡且会影响集群。

2、 NAS的读写速度和稳定性和硬件、软件、基础网络相关，首先是受到硬件配置的影响，需在技术选型时，选择适合自己需求的NAS存储设备，确保硬件的质量和稳定性。其次，对NAS做必要的软件配置和优化可有效提升稳定性，譬如调整读写缓存、优化传输协议等。另外， NAS的读写速度和稳定性还与网络环境有关，需保证基础网络的稳定性和足够的带宽资源。譬如可使用高速网络设备、升级路由器和网卡等方式来优化网络环境。

4、 Kafka容器化后弹性伸缩能力如何？

嘉宾回复：

顾黄亮 技术总监
首先， Kafka 的弹性和容错能力是kafka自身的能力，这一点和容器化并没有直接关联，如果二者的优势可以结合，就要选择合适的集群模式。

比如说，如果有一些流量大的数据链路，在容器云上可以配置比较多的 Pod 和 CPU 数量。当突发流量到来时，使用容器云弹性可以快速扩充 Mirrormaker 的数据同步能力。还有一种方式，当流量增大时，可以通过修改 Pod 数量来增加该条链路上的 Mirrormaker 进程数量，以此加快数据同步的速度。

这是最简单最直接的弹性伸缩。

5、 容器部署kafka性能如何？

容器化部署kafka，使用nas作为持久化存储，性能是否满足生产需求，性能瓶颈在什么地方？

嘉宾回复：

wuzhuang0001 产品规划与架构 , 华为数据存储解决方案中心
企业NAS以实测情况看，全闪配置，大文件小IO读写至少可以达到FC SAN的80%+，也是几十万OPS@1ms的水平，对于Kafka没啥问题。。。可能要注意的就是如果热点数据不多，完全可以配置混合存储，30%的SSD占比，足以支撑热点数据的读写要求。

洪月 华为企业存储产品规划专家
基于实际测试，在保证端到端100ms时延左右的情况下，OceanStor Dorado NAS可以提供高达数百MB/s的吞吐量，远超大部分集群的需求。

在大压力（如每秒百万个1K大小消息）压测的情况下，Broker的处理能力、网络等都可能成为性能瓶颈；此次的测试规模尚未达到NAS存储的性能瓶颈。

嘉宾回复：

顾黄亮 技术总监
实测过，kafka在容器云和虚拟机中部署，性能是一样的，基本上没有任何变化。 容器化技术本身是个进程级别的隔离技术，机器还是那个机器，网络还是那个网络，运行的程序也一样。

6、如何设计容器云环境的高可用Kafka集群？

嘉宾回复：

nonetheless 云原生架构师 , 兴业数金
在容器云环境中设计高可用的Kafka集群，需要从存储，网络的高可用来方面考虑:

1. 存储层面需要关注存储高可用的实现方案，可以通过高性能共享存储和Kafka多个Broker实例之间的复制两种方案实现，目前业内已有成熟的共享存储方案，主要介绍下第二个方案：
   Kafka通过Broker日志复制将Broker的日志文件复制到其他Broker上，从而实现数据的冗余备份和快速恢复。具体来说，Broker日志复制分为两个阶段：首先，源Broker会将数据写入本地磁盘上的日志文件中，并将其标记为可复制状态；然后，目标Broker会从源Broker获取数据，将其写入本地磁盘上的日志文件中，并将复制状态标记为已完成。在Kafka 3.0中，Broker日志复制使用了一种新的机制，称为“分片复制”分片复制将每个Broker的日志文件分为多个片段（Segment），每个片段大小固定，一般为1GB或者更小。当源Broker的一个片段被标记为可复制状态时，它会将该片段复制到一个或多个目标Broker上，每个目标Broker都会维护一个复制进度（Replica Log End Offset），用于记录它已经复制的片段。源Broker会定期检查目标Broker的复制进度，如果发现有目标Broker没有完成复制，则会重试。
   同时Kafka 3.0引入了一种新的分布式协议，称为Kraft，它是Kafka 3.0的一个重要特性。Kraft协议是一个基于Raft一致性算法的实现，用于管理Kafka集群的元数据和副本的选举、数据同步等操作，通过Kraft协议，Kafka不需要依赖于Zookeeper，在扩展性，性能，简化管理等方面有了很大提升。
2. 网络层面需要关注Kafka如何二次寻址向Broker发送消息以及如何在容器云环境中实Rebalance，可以通过容器云CNI扩展方案支持静态PodIP固定加Underlay组网方案实现或者通过LoadBalancer方案实现。为了更好的理解网络高可用的必要性，先下Kafka客户端建立连接和Rebalance的原理，
   Kafka客户端连接到Kafka集群的流程：
   1）获取Broker元数据：客户端首先需要从Kafka集群获取Broker元数据，以了解可用的Broker和分区分配信息。Kafka客户端会向Kafka集群中的一个Broker发送一个元数据请求，获取可用的Broker列表和分区分配信息。这个元数据请求可以被任何一个Broker处理。
   2）连接Broker：客户端会从可用的Broker列表中选择一个Broker进行连接。连接可以是TCP连接或SSL连接，取决于Kafka集群的配置。
   3）发送请求：客户端连接到Broker后，可以发送请求来获取、生产或消费消息。请求包括请求类型、主题、分区、消息等信息。
   4）处理请求：Broker接收到请求后，会根据请求类型进行处理，例如读取或写入消息。
   5）返回响应：Broker处理完请求后，会向客户端返回响应。响应包括响应状态、主题、分区、消息等信息。
   6）断开连接：客户端可以选择断开连接或者保持连接。如果客户端断开连接，则需要重新执行上述步骤重新连接到Broker。
   在Kafka Broker宕机恢复后， Kafka 客户端会自动触发重平衡（rebalancing）流程，以重新分配消费者实例和分区之间的关系 ：
   1）Kafka 客户端会检测到 broker 宕机新拉起节点并刷新Borker元数据 。
   2）Kafka 客户端会向 Kafka 集群协调器发送心跳，以确保它仍然是一个活跃的消费者组成员。如果协调器在一定的时间内没有收到心跳，则会将该消费者标记为失效，并将其分区重新分配给其他消费者。
   3） Kafka 客户端会向协调器请求重新分配消费者实例和分区的关系。协调器会根据消费者组的配置和现有的消费者实例列表，重新计算分区的分配结果。
   4）协调器会将新的分区分配方案发送给消费者组中的所有消费者实例。消费者实例会根据新的分配方案，重新分配自己负责的分区。
   5）消费者实例会根据新的分配方案，重新分配自己负责的分区，并在重新分配完成后重新开始消费消息。
   可以看到Kafka客户端和Server端建立连接都是通过Kakfa Broker元数据进行二次连接，需要通过broker 的 bootstrap 地址是通过 listeners 配置参数来指定的，它可以设置一个或多个监听器，每个监听器可以有一个或多个地址。 以下是一个示例配置文件：

broker:
  id: 0
  rack: dc1
  listeners:
 INTERNAL://:9092
 EXTERNAL://:9093
 CLIENT://:9094
  advertised.listeners:
 INTERNAL://kafka1.internal:9092
 EXTERNAL://kafka1.example.com:9093
 CLIENT://kafka1.example.com:9094

在容器云环境中需要将 EXTERNAL 地址配置为静态PodIP地址或LoadBalancer地址，来确保Kafka Broker可以正常寻址：
1）基于静态PodIP可以通过环境变量注入，然后启动时通过环境变量渲染broker配置即可达到效果，以下例子可参考注入POD_IP：

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: my-container
 image: my-image
 env:
 - name: POD_IP
   valueFrom:
     fieldRef:
       fieldPath: status.podIP

2) 基于LoadBalancer方案则更为复杂，通常需要通过开发单独的Kafka Operator服务来管理Kafka在容器云上的生命周期，当然该方案也是各类中间件服务容器云上的推荐方案，从可用性、兼容性、可移植性上均会更好，Kafka社区也开源了Operator，可以参考https://github.com/strimzi/strimzi-kafka-operator直接使用，也可以根据各容器云平台特点开发Kafka Operator服务。

当然Kafka在容器云上的高可用性还有很多地方可以考虑，比如基于集群联邦或Kafka MirrorMaker2 实现Kafka的机房级别容灾、Kafka容灾场景下的可观测性等，也可以参考近期信通院发布的《云原生能力成熟度模型-第5部分：中间件》行业标准进行比对。

wuzhuang0001 产品规划与架构 , 华为数据存储解决方案中心
1，常见套路就是要么应用层自己做，就是Kafka的一主多从能力，要么容器平台体系支撑，就是靠容器平台自身的漂移能力解决可靠性和恢复能力。

2，两种方案各有优劣，一主多从结合本地盘，就是当前的常规套路，但是有几个问题，服务器自身的可靠性，3年寿命的周期替换，数据迁移；RAID卡的抖动问题，本地盘的可靠性，一旦盘失效，重构的缓慢与性能波动；无法弹性扩容，容量用满又需要迁移；计算存储资源不匹配，混在一起无法按需扩展；存储自身几块盘现网也出现很多使用不均的问题；为了可靠性通常需要三副本配置，同城容灾需要更多副本支持；同类应用如果都采用一主多从，有类似七八种组件，管理运维上对中小金融机构的压力也比较大

3，以实测结果看，用容器平台自身的可靠性能力，失效后自动漂移，可以形成统一的平台化方案。同时，采用外置企业NAS存储，确实更适合容器平台的租户管理，业务隔离，优先级配置，资源共享。尤其是如果只配置单副本的情况下，明显性能优于一主多从模式，再结合企业存储自身的可靠性底蕴，整体方案实现了诸多好处。

1）计算存储分离，无论计算扩还是存储扩，互不影响，按需扩展
2）容器云平台一般都带有租户属性或者业务隔离属性，配合企业NAS的租户能力，更容易实现端到端的资源隔离，认证鉴权，安全管理，读写控制，优先级设定，以及整体资源的合理管控，如按照租户设定容量上限。
3）配合Kafka，依托企业存储的高可靠，可以配置单主模式，性能最佳，甚至是2倍以上本地盘一主多从的模式，同时结合容器平台自身的漂移能力，可以解决计算侧故障的恢复问题。
4）平台化体系搭建，从目前看，类似Kafka的分布式核心组件有很多，比如redis，elastic search，nigix，mysql等等，常规操作都是各自为战的一主多从，多个集群不只是浪费资源，甚至是消耗大量管理运维的精力。如果均可以利用容器平台的自身漂移解决可靠性问题，无疑会大大降低客户维护多个单集群主从模式的运维难度。
5）存储自身扩容，完全无感知，不影响业务；同时，单盘失效，重构也没有任何影响，也不涉及RAID卡抖动这些常规问题；可靠性远高于普通服务器。而且，存储使用周期长，一般五年起步，多则七到八年，服务器到期更换，无需数据迁移。

7、kafka、rabbitmq等中间件在容器环境中，有没有最佳部署时间的基线配置？

kafka、rabbitmq等中间件在容器环境中部署时，有没有最佳部署时间的基线配置，采用什么配置时能达到什么性能，有没有相关测试支撑，如果有是否可以分享一下评测数据？

嘉宾回复：

rechen 云计算架构师 , 招商银行
建议Kafka容器化服务注意做好规划和存储的选型，譬如规划方面，根据需求确定是哪种交付方式（共享集群还是独立集群），在服务层和存储层做到租户强隔离、配额管控和高可用部署设计以保证稳定性和安全性。存储选型方面根据本单位的运维实际、存储的技术储备和演进等，选择匹配适用的存储。

二、Kafka容器化建设方案重点考虑的涉及层面。

1、kafka容器化如何尽可能不影响业务进行数据均衡？

嘉宾回复：

rechen 云计算架构师 , 招商银行
建议先分析产生数据均衡的原因：

1）组成员发生变更，比如新 consumer 加入组，或己有 consumer 主动离开组，再或是己有 consumer 崩溃时则触发 数据平衡 rebalance 。在实际环境下，这是触发数据平衡的主要原因。
2）组订阅 topic 数发生变更，比如使用基于正则表达式的订阅，当匹配正则表达式的新 topic 被创建时则会触发数据平衡rebalance。
3）组订阅 topic 的分区数发生变更，比如使用命令行脚本增加了订阅 topic 的分区数。
深入了解数据平台的运行机理，和调整相应的参数设置，以降低数据平衡的频度或减少数据平衡的误判，从而规避数据平衡。
另外，是降低数据平衡的影响。譬如在规划阶段，相比使用本地盘方式，采用计算存储分离的架构，则有效收敛数据均衡的时间。

洪月 华为企业存储产品规划专家

扩容后的数据均衡涉及到分区在Broker之间的重新分配，会导致业务短暂的不可用。根据我们的实际测试，从3个POD扩容到6个POD的情况下做再均衡，业务不可用时间约为40s。实际部署过程中，这个时间与您扩容的节点数和均衡的工作量有关，因此还是建议在非生产时间进行扩容。

zftang 其它
一可以在晚间业务低峰时操作，必要时还可以和业务沟通，临时缩短数据保存时间，加快迁移，减少带宽影响时间

二直接用Kafka官方提供的分区重新分配工具生成分区重分配方案，直接执行分区重分配。

2、在OKD中如何将Kafka的端口暴露出来，能否实现自动横向扩展和收缩？

将KAFKA部署在OKD中，请问Kafka如何把端口暴露出来？
还有在负载较高的时候能否实现自动横向扩展和收缩？

嘉宾回复：

rechen 云计算架构师 , 招商银行
1、使用 Strimzi 自带的 KafkaConnect 进行数据交互，或者 使用Kafka Bridge组件对接K8S的外部负载均衡或Ingress（注：在OKD是 Route）, ，可以将Kafka集群暴露出来使用。

2、扩缩容的实现可以通过修改 Broker 的副本数量，执行命令 oc apply -f kafka-cr.yaml -n kafka。此过程需结合监控、规则判定和自动化工具才能实现。

3、 Kafka自动扩缩容怎么实现？

kafka集群的自动扩缩容怎么实现？客户端能否做到无感知？

嘉宾回复：

洪月 华为企业存储产品规划专家
弹性是使用容器部署Kafka带来的一大优势。如果Broker处理能力不足，简单的修改Broker配置Yaml文件中的Broker数量就可以实现自动扩容，POD、PVC和PV都可以自动创建。扩容本身对业务无影响；扩容后如果要做数据在节点间的再均衡会触发Broker和 Partition的对应关系发生变化，导致业务短暂中端（根据扩容节点数，一般在几十秒或者分钟级），因此建议在非核心时间执行该操作。

4、一个稳定、高性能Kafka集群的参数调优和持久化存储配置方面有哪些最佳实践？

嘉宾回复：

洪月 华为企业存储产品规划专家
Kafka性能和可靠性的调优涉及Broker、Producer、Topic等组件的多个参数，并且参数之间还存在关联关系。以Topic为例，每个Topic的分区（Partition）数、每个Partition的副本数等都会对性能产生明显的影响。而其中的副本数又是同时与可靠性和性能都相关的参数：例如如果为了保证可靠性设置三副本，并将acks设置为all，则 leader节点会等待所有同步中的副本确认之后再确认这条记录是否发送完成，这就对吞吐量和时延有直接的影响。

因此实际部署过程中需要基于业务吞吐量和可靠性要求进行对比调优，之前已有海外金融、运营商客户实践Kafka/ES + 容器平台 + 外置企业NAS，采用单副本存储，同时支持计算漂移的方案。一方面通过外置企业NAS存储保障数据可靠性，一方面通过计算侧容器平台的漂移能力解决应用的可靠性；同时单副本部署，性能达到最佳值。本次测试其实是完整验证了这一方案的可行性和实际价值，测试结果也充分证明了单副本的性能最优，同时结合容器平台自身的漂移能力，可以实现分钟级的漂移，依靠平台能力提升可靠性。

rechen 云计算架构师 , 招商银行

1. Broker
   − CPU 和内存比例建议设置为 1:4 ，比如 4C/16GB 、 8C/32GB 、 16C/64GB 。如果开启 TLS 和数据压缩功能，建议将比例提升至 1:2 。
2. Topic ：
   单个 Topic 分区数建议控制在 10 个以内。
3. Replicas ：
   Kafka 应用对于可靠性要求较高的场景常采用 3 副本；
4. Partition
   − 分区副本数建议为 2 或 3 ，从可靠性考虑，非常关键业务建议设置为 3 。
5. Producer
   − 如果想保证数据绝对不丢失， Producer 需要开启重试逻辑，并且设置 ACKS=all ，如果需要增大吞吐量，可以考虑设置较大的 batch.size （默认为 16K ）。
   − Producer 数量并不是越多越好，需要根据业务需求来确定，通常单个 Topic 的 Producer 个数不超过其分区数。
6. Consumer
   − 单个 Consumer Group 的 Consumer 的个数最好与 Topic 的分区数成一定比例，这样能够最大化的提升 Consumer 的资源利用率。
7. 安全：
   如果 Broker 是暴露在开放的网络上（无论是内网还是外网），则需要开启 TLS 和 ACL ，防止中间人攻击和未授权的用户访问。

伊始 中间件技术专家 , 兴业数金
1、存储
建议实际占用空间为总空间的50%，实际预留空间要根据每日业务量、Topic的数量和规格、消息有效期、业务增长预期等多个方面综合考虑。

2、生产者
合理评估单条消息的体积大小，不同体积消息占比，调整batch.size以提高发送速率。

3、消费者
单个consumer group内的consumer实例数只能不超过Topic的Partition数，否则多余的consumer实例也只是空转，而起不到提高消费能力的作用。

5、Kafka+Operator在银行业如何落地？

目前已经实现Kafka组件的容器化，基于Operator技术如何在银行业实现落地kafka?

嘉宾回复：

rechen 云计算架构师 , 招商银行
Operator 本质上是K8S内建的自定义资源CRD（Custom Resource Definition） + Controller。其中：CRD 定义用户的资源；Controller 监听 CRD 对象实例的增、删、改事件，然后执行相应的业务逻辑。 Operator 仅依赖于 Kubernetes 申明式 API 和 Controller 的能力，实现了用户资源与具体操作的定制化关联。 其初衷是开发者将运维能力固化在代码中，让运维更容易，核心在于对领域能力的实现和封装。 为应用的动态描述提出了一套行之有效的实现规范。

基于Operator技术在业务实现KAFKA落地，最知名的项目是Strimzi项目，官网是strimzi.io/，项目REPO在：https://github.com/strimzi/strimzi-kafka-operator

三、Kafka容器化的存储选型

1、Kafka持久化存储方案的取舍咨询？

一个方案一般都是有取舍的，Kafka持久化存储方案报告中主要说明了优势，能否也简单说明下风险或劣势分析。比如消息丢失、容错方面。

嘉宾解答：

rechen 云计算架构师 , 招商银行
出现消息丢失的现象，是Kafka参数配置失当的问题。譬如：
（1） Producer 参数：如果想保证数据绝对不丢失， Producer 需要开启重试逻辑，并且设置 ACKS=all ，如果需要增大吞吐量，可以考虑设置较大的 batch.size （默认为 16K ）。
（2）Partition参数：分区副本数建议为 2 或 3 ，从可靠性考虑，非常关键业务建议设置为 3 。
（3） Replicas 参数： Kafka 应用对于可靠性要求较高的场景常采用 3 副本； 3 副本相较于单副本，牺牲了大量的性能。在对业务可用性可以接受的情况下，可考虑使用单副本，并利用 K8S 平台 + 共享 NAS 存储的方式保证可靠性。

容错方面需要加强规划和运维管理。譬如：
（1）容器化部署 Kafka 时，建议部署多个小规模集群，每个集群 Broker 数量通常不超过 20 个。
（2）单个 Topic 分区数建议控制在 10 个以内。
（3）单个 Consumer Group 的 Consumer 的个数最好与 Topic 的分区数成一定比例，这样能够最大化的提升 Consumer 的资源利用率。
（4） Kafka 应用对于可靠性要求较高的场景常采用 3 副本 。
（5） − 当业务压力超过当前配置性能极限时，此时时延会成倍增加，对业务造成较大的影响。因此当 Kafka 性能即将到达瓶颈时，需要尽快提升集群的配置，如 Broker 数量、 Broker 配置等。

洪月 华为企业存储产品规划专家
数据可靠性是专业存储相对于本地盘的核心优势。专业存储在盘级、控制器级、系统级通过软件和硬件的设计和优化实现多层面做数据可靠性保证，其中就包括您提到的防数据丢失、容错等能力。

但相对本地盘，由于IO路径变长，在时延上会略高于本地盘；因此需要通过TCP协议卸载、NVMe over RDMA、NFS over RDMA等方式降低前端交互过程中的开销，提升性能。

2、如何为容器云环境的Kafka集群选择合适持久化存储？

嘉宾解答

洪月 华为企业存储产品规划专家
Kafka的存储需求，在功能面是存储的数据是消息流，数据量级非常大；数据CRUD操作足够简单，主要为并发非常高和百万级TPS的追加写、无需更改、能根据消费位移offset和时间戳timestamp查询消息、能定期删除过期的消息；在非功能性面是高性能要求、高可用的稳定性要求、高扩展性要求。

在存储的选择过程中，服务器本地盘、外置SAN存储和外置NAS存储的主要能力对比如下：
• 性能：服务器本地盘性能较好，但存在故障率高、故障后恢复慢、不同节点容量使用不均衡、容量使用率低、扩容难等问题；而且容器化部署后，使用本地盘会限制POD漂移能力，影响组件的高可用。外置的高性能存储是更好的选择。同时在单副本部署状态下，外置存储的性能明显占优，在可靠性和性能之间达成了完美的平衡。
• 隔离：部署多Kafka集群或者Kafka集群与其他业务集群共享一套存储时需要做数据隔离；NAS在对接K8S平台时具备多租户能力，可以实现多集群共享存储资源池。NAS在隔离性上优于SAN。
• 可靠性：使用外置存储，尤其是共享的NAS存储时，在Kafka集群节点故障后，POD容器漂移后可直接在目的端重新挂载存储，不需要拷贝数据，恢复时长可降低至分钟级别，快速实现故障自动切换。

3、 Kafka选择的持久化存储性能关注点？

kafka作为高频访问的消息中间件，叠加容器化的交付方式，使用持久化存储的性能关注点有哪些。是否普通的分布式存储就可以满足需求？还是要考虑使用高IO性能？

嘉宾回复：

洪月 华为企业存储产品规划专家
Kafka性能的主要指标是吞吐量（带宽）和时延。分布式存储是否满足需求，首先需要评估性能需求，根据Kafka消息的IO大小、存储的软硬件配置、批量参数、网络配置等综合评估可达到的吞吐量和时延情况。Kafka最核心的问题是数据访问的低时延，普通的分布式存储，由于三副本或者EC机制，需要跨网络在多节点之间做数据转发，一般全闪存配置的时延也在3ms左右，HDD配置下，更是在5~10ms范围，客观讲是不适合低时延业务负载诉求的。建议采用企业NAS存储，保障1ms的IO读写时延，同时最为适配容器场景，可租户级管理，可空间管理，可快速漂移，可资源共享。

4、在设计Kafka持久化存储方案时，如何平衡性能和成本，并提高数据处理效率？

Kafka集群需要足够的硬盘空间来存储消息数据和元数据，也需要一些额外的空间用于缓存、日志和其他系统文件。在设计Kafka持久化存储方案时，特别是在容器云环境下，从那些方面考虑存储选型，如何平衡性能和成本，并提高数据处理效率？如何对Kafka集群的存储空间进行实时监控，如何根据监控情况按需进行无缝扩容？

嘉宾回复：

洪月 华为企业存储产品规划专家
在容器云环境下性能的影响因素有很多，例如虚机容器相对于裸金属容器就会带来额外的10%-15%的开销，因此从性能的角度，裸金属容器是更好的选择。

回到存储，首先为了保证性能，无论是存算一体还是存算分离都建议使用SSD盘来保证性能。在成本方面，服务器本地盘看似便宜，但因为其相对低的可靠性，一般都需要配置Kafka的三副本来提升可靠性；而使用外置存储时，则可以将数据可靠性交由存储实现，Kafka采用单副本部署，降低成本。另外在测试过程中，我们对比了单副本和三副本的性能，发现减少了副本间的数据同步可以带来性能的2倍以上线性提升。

企业NAS是存放日志和文件系统的最佳选择，可以实现多个节点的共享访问，读写。所以，除了Kafka自身数据的存储建议采用企业NAS外，同时其他数据均可采用企业NAS解决问题。成本的本质控制是看系统性能诉求，可以在全闪存和混合闪存之间进行整体性平衡。

对于存储空间的监控，有两种方式：存储管理员可以在存储的管理界面上通过配置配额、可视化容量管理界面、配额告警、配额调整等方式管理；集群管理员可以通过Prometheus观测存储卷的容量使用情况。

5、kafka容器化后存储选型？

分布式存储、NAS存储、本地盘等，kafka容器化后如何进行存储选型保证其性能，扩容，数据安全以及容量管理？

嘉宾回复：

洪月 华为企业存储产品规划专家
首先，K8S对存储做了抽象，不关心集中式还是分布式，主要还是看性能、可靠性、扩展能力、功能等能否匹配业务要求。

在这个前提下，本地盘虽然性能较好，但可靠性、扩展能力、跨节点共享能力等都问题突出，存算分离是更好的选择。

扩容方面，无论是分布式存储、NAS存储（本文主要是指企业级NAS存储）都具备PB级以上的扩容能力，单卷也支持弹性扩容，都可以满足要求。

从时延角度，由于分布式存储涉及到跨节点副本转发，时延比企业级NAS高，需要看是否满足业务需求。

在安全方面，NAS存储相对块存储更优，可以支持租户隔离、多种鉴权模式、防病毒、防勒索检测等功能。

在容量管理上，我们推荐使用租户级配额来实现一个Kafka集群的容量管理，这样存储管理员只需要管理整个集群可用的存储容量，而不需要限制每个PV的大小，管理更简单。

嘉宾回复：

北京不眠夜 产品经理
看需求。
应用对kafka使用量不大，没有太高的性能要求（IO、延时），一般用分布式存储即可。或者，使用旧有NAS存储也可以。
如果应用使用kafka很重，对IO、延时都有较高的要求，一般使用本地存储。原生的本地存储方案功能比较简单，可以看看carina。

6、Kafka+Operator存储持久化方案对存储性能敏感程度？

Kafka+Operator存储持久化方案对存储性能和io的需求是否要求非常敏感？存储上主要保留的是哪些部分的持久化数据？

嘉宾回复：

rechen 云计算架构师 , 招商银行
是的，对存储性能和io的需求敏感。 存储上具体要持久化哪些数据，这和Kafka的应用业务场景相关。譬如在用户数据采集和分发场景，是使用Kafka记录Web用户或者App用户的各种活动，如浏览网页、搜索、点击等活动数据，则这些数据都要持久化，且一般要持久到下游消费者全部处理完。

洪月 华为企业存储产品规划专家
Kafka对存储性能的敏感程度本质上取决于业务诉求，Operator只是Kafka容器化之后一种典型的部署方式。

Kafka作为高性能的消息队列，常用于实时或准实时的消息处理，建议配置高性能闪存存储。

Kafka存储过程中，每个 Topic被分成多个 Partition，Partition 从物理上可以理解成一个文件夹。每个 Partition 又被分成了多个 Segment，Segment 从物理上可以理解成一个「数据文件 + 索引文件」，这就是Kafka持久化的数据内容。

金融专家回复
1、该方案对于存储性能和io的需求确实非常敏感，甚至取决于实际消息的类型和大小，可能对带宽也非常敏感。
2、理论上来说只要进入topic的业务数据都持久化了。具体的持久化时长可能需要根据业务需求、生产/消费速率、数据有效期、存储配额、消息的可靠性要求等多个维度综合考虑。

7、Kakfa存储方案的多中心高可用如何实现？

Kafka存储在容器平台的高可用方案如何实现？包括多中心、多租户如何实现？多中心间存储如何实现同步，基于硬件层还是软件层？

嘉宾回复：

rechen 云计算架构师 , 招商银行
高可用方案建议根据业务系统的重要性等级的需求，分层地进行高可用设计。譬如在Kafka服务层，可将Kafka部署在多个K8S集群，通过负载均衡实现应用接入的高可用。 存储层根据相应的技术选型和存储产品特性，通过数据副本、数据同步等实现高可用。

Kafka服务层必须要设计为多租户支持，其次存储层的产品对租户的支持是可选。如果也有租户功能则更佳，服务层可和存储层进行租户映射和API对接。

多中心间存储的数据同步，视存储层的技术选型。譬如选择NAS硬件设备，则可在硬件层实现同步。

四、交流总结达成共识

• Kafka容器化部署能够显著提升交付效率，并有效降低扩缩容等运维成本；
• 存算分离的部署架构有助于提升Kafka集群的扩展性和稳定性；
• 企业NAS是存放日志和文件系统的最佳选择，可以实现多个节点的共享访问，读写。所以，除了Kafka自身数据的存储建议采用企业NAS外，同时其他数据均可采用企业NAS解决问题。成本的本质控制是看系统性能诉求，可以在全闪存和混合闪存之间进行整体性平衡。
• 通过本期测试实践可以看出企业级NAS存储与OpenShift 容器云平台的组合，是稳定的运行平台，其中 Kafka 集群容器化部署表现出与非容器部署接近的性能，达到了对Kafka服务容器化改造的技术可行性验证的预期效果。