1. 问题描述 相关 Pod 1 2 3 4 5 6 kubectl -n istio-system get pod -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES istiod-647c7c9d95-7n7n6 1/1 Running 0 77m 10.244.173.51 docs-ai-a800-4 <none> <none> istiod-647c7c9d95-k6l88 1/1 Running 0 30m 10.244.210.160 ai-a40-2 <none> <none> istiod-647c7c9d95-pj82r 1/1 Running 0 51m 10.244.229.217 docs-ai-a800-2 <none> <none> 相关 Service 1 2 3 4 kubectl -n istio-system get svc NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE istiod ClusterIP 10.99.225.56 <none> 15010/TCP,15012/TCP,443/TCP,15014/TCP 645d 1 2 3 4 kubectl -n istio-system get endpoints NAME ENDPOINTS AGE istiod 10.244.173.51:15012,10.244.210.160:15012,10.244.229.217:15012 + 9 more... 645d Endpoints 与 Pod 的 IP 是一致的。 测试结果 在异常节点

1. 背景 在测试 NFS Over RDMA 的性能时，发现 4M 的文件的读取性能竟然能达到 45GB/s。 1 2 3 fio -numjobs=128 -fallocate=none -iodepth=2 -ioengine=libaio -direct=1 -rw=read -bs=4M --group_reporting -size=100m -time_based -runtime=30 -name=fio-test -directory=/data1/nfs READ: bw=42.3GiB/s (45.4GB/s), 42.3GiB/s-42.3GiB/s (45.4GB/s-45.4GB/s), io=1269GiB (1363GB), run=30019-30019msec 而磁盘的 4M 多线程读取性能只有 6 GB/s 1 2 3 fio -numjobs=128 -fallocate=none -iodepth=2 -ioengine=libaio -direct=1 -rw=read -bs=4M --group_reporting -size=100m -time_based -runtime=30 -name=fio-test -directory=/data1/host READ: bw=6190MiB/s (6491MB/s), 6190MiB/s-6190MiB/s (6491MB/s-6491MB/s), io=182GiB (196GB), run=30152-30152msec 2. NFS Over RDMA VS NFS 3. 数据拷贝路径比较 3.1 NFS

1. Direct IO Direct IO 绕过了操作系统的页缓存(page cache)，直接与硬件设备进行数据交互。 Direct IO 的特点： 新数据多，不需要缓存 内存占用少 大文件顺序读写 对于超过阈值(默认 1MB)的同步读取操作，3FS 的客户端会将其转为 AIO (以 Direct IO 方式打开文件)操作以提高

记录一些 DeepSeek 3FS 的运维操作，持续更新中。 1. 基本概念及注意事项 Chain 一个 Chain 是由若干个 Target 组成，每个 Target 是一个存储的副本。在全部提交就绪的情况下，一个 Chain 的所有 Target 都是一致的。 一个 Chain 上的 Target 不能在同一个节点上。 Chain 就是存储的空间，写文件是会被分配到一个 Chain 上，读文件

1. 部署方案 在开始容器化部署之前，先提几点要求: 为了简化交付，只需要一个镜像 为了可靠性，尽可能多副本部署 通过不同的参数启动不同的服务 通过环境变量注入配置，渲染到配置文件中 下面是 DeepSeek 3FS 的部署方案: 需要部署: 一个 Monitor 用来收集监控数据，数据存储在 ClickHouse 中 一