简介：《深信服企业级分布式存储 aStor-EDS 用户手册 V3.0.5》是一份官方发布的产品技术文档，面向技术服务工程师与运维人员，围绕 aStor-EDS 分布式存储系统的架构、特性、安装、使用与运维管理展开说明。资源包为单个 PDF 文件，体积 10.05MB，内容包含前言、符号约定、修订记录、产品架构、安装配置、使用指南及运维管理等多个章节，结构完整。目前已有 352 人浏览学习。读者可通过该手册了解多节点分布式存储的高可用、高性能与高安全设计思路，明确存储节点与元数据服务器的部署方法，掌握系统监控、故障处理及软件升级等日常运维操作；同时手册还提供官方支持邮箱、服务热线和意见反馈路径，便于在项目实施与维护中快速获取帮助，适合作为企业存储规划、上线及后续管理的实用参考。

1. 拆解深信服 aStor-EDS 用户手册：3.0.5 到底能解决什么问题

做过存储交付的人都有体会：分布式存储最怕的不是性能不够，而是开局就翻车。深信服 aStor-EDS 3.0.5 用户手册把从组网规划、IP 分配、第三方服务器选型，到存储池创建、NFS/CIFS/FTP 共享、iSCSI 块设备和对象 Bucket 管理，再到快照恢复和多数据中心切换的完整链路都写清楚了。对技术服务工程师和运维人员来说，这套手册最大的价值不是教会你某一个按钮在哪，而是把每一步的先决条件和参数含义讲明白。适合刚要上手 EDS 的交付新人，也适合已经踩过坑、想系统核对一遍配置习惯的运维老人。

2. 安装部署前的硬规划：组网模式、IP 规划与服务器选型

2.1 组网模式怎么选：管理、存储、业务流量先分开

手册把组网放在安装部署的第一节，不是没有道理的。EDS 集群运行时有三类流量：节点间数据同步和客户端 IO 走存储网络，集群管理、Web 登录走管理网络，对外业务接入走业务网络。这三类流量如果混在一起，一次大规模数据重建就可能把管理面堵死，到时候想登录控制台排障都进不去。

我一般会按节点至少三张网卡来规划：管理口接千兆交换机，用于登录集群和调用 aDeploy 检测工具；存储口接万兆交换机，承载节点间数据复制和前端存储 IO，这个口是性能瓶颈所在，不要省；业务口接客户业务网，供 NFS、CIFS、iSCSI 等前端协议接入。手册里专门有一节讲 EDS 与 HCI 组网最佳实践，场景是 EDS 作为超融合 HCI 的共享存储后端，这时候存储网络要优先保证低时延，建议存储口与 HCI 的计算节点之间二层直连，不要跨三层路由。

实际项目里最常见的翻车是只有两张网卡，把管理和业务合并了，存储口独享万兆。这种做法在中小项目里能用，但合并口上跑着 NFS 和 CIFS 客户端访问，一旦有人做批量文件拷贝，控制台操作就会明显卡顿。如果你只能两张网卡，至少要保证存储内网独立，管理口和业务口合并后打开流控和 QoS。

2.2 IP 地址规划：一张表排清所有角色

手册对 IP 地址规划给了明确要求：每个节点至少规划管理 IP、存储 IP、业务 IP 三类地址，存储内网建议静态分配，不能用 DHCP，节点间存储通信依赖固定地址做集群心跳和数据复制。

以一套三节点集群为例，我一般会这样排：

三个网段要能够在主机侧隔离，包括交换机 VLAN 隔离，避免存储内网的广播报文干扰管理面。还有一点容易被忽略：虚拟 IP 池要单独预留一段连续地址，文件存储和对象存储都会用到虚拟 IP，客户端访问的是 VIP 而不是某个节点 IP，节点故障时 VIP 自动漂移，客户端不断连。这段地址务必要和物理节点 IP 错开，并且提前在交换机上确认没有冲突占用。

2.3 硬件配置与第三方服务器选型注意点

如果买的是 EDS 一体机，硬件兼容性厂商已经替你验证过，省事。但很多项目是客户已有第三方服务器，这时候就必须严格按手册的第三方设备选型指导走。手册里对第三方硬件服务器及配件选型、第三方服务器安装 EDS 的配置要求用了两节篇幅来写，重点说的是网卡型号和固件兼容性、硬盘型号和 RAID 卡模式。

我的经验是三条硬规矩：第一，数据盘必须直通模式，RAID 卡不要做阵列，分布式存储自己管理副本，硬件 RAID 反而会掩盖磁盘故障；第二，系统盘和数据盘分离，系统盘用 SATA SSD 或企业盘即可，数据盘按介质类型分开规划，SATA SSD、NVMe SSD、机械盘不要混在同一个存储池里，否则 NVMe 会被机械盘拖到同一性能水平；第三，网卡选型以手册兼容性列表为准，尤其是万兆网卡，部分廉价网卡在大流量下会出现丢包重传，存储内网的数据一致性校验会非常吃性能。

不同的场景介质选择差别很大，可以先用这张表定方向：

选型阶段多花半天核对兼容性，比进场后因为网卡固件不兼容导致集群初始化失败要划算得多。厂商一般不给第三方硬件做承诺，手册里列了配置要求，照着选就不会出现装上系统后硬盘识别不全的问题。

3. 集群初始化和存储池创建：从节点到可用存储的关键路径

3.1 组建集群与授权激活：aDeploy 检测别跳过

EDS 系统安装在每台服务器上之后，下一步不是直接用，而是把多台节点组建成一个集群。一体机开机后会进入初始化界面，第三方服务器则是通过 ISO 安装 EDS 系统，然后登录初始化页面填写管理 IP，再让各节点互相发现并组建集群。

这里要特别提一下 aDeploy 工具。手册在集群初始化之后专门安排了一节"使用 aDeploy 工具进行检测"，这个工具的作用是在正式启用前对集群环境做一次体检。有的交付同事觉得这一步浪费时间，跳过直接建池，后面节点间网络时延异常、时钟不同步的问题慢慢才暴露出来。我每次都会在初始化后跑一遍：

# 在管理端执行 aDeploy 检测，--cluster 指定集群管理 IP，--user 指定管理员账号 ./adeploy check --cluster 192.168.10.11 --user admin

这个命令会检查节点间连通性、存储网络延迟、磁盘健康状态、时钟同步情况，输出 warn 和 fail 两类结果。fail 项必须处理完再继续，比如存储口网线没插好、时钟偏差超过阈值，这些都是后续存储池性能异常和数据一致性隐患的来源。warn 项可以记录跟踪，比如某个磁盘健康状态预警，不影响初始化但需要后续关注。

集群组建完成后进入授权激活环节。授权文件与集群的节点数和序列号绑定，激活时在控制台上传 License 文件。常见的问题是授权文件拿错，比如客户买了 4 节点授权，集群却加了 5 个节点，激活会直接失败。遇到这种情况先核对授权范围，再检查控制台显示的序列号是否与官网生成授权时填写的一致。

3.2 创建容量型通用存储池：副本数怎么选

存储池是 EDS 分配空间的基础单元，所有文件存储、块存储、对象存储都从存储池里划分。手册把存储池分成容量型通用存储池和高性能块存储池两类，创建路径为[存储管理/存储池/创建]。

容量型通用存储池用于文件存储和对象存储，介质选择大容量机械盘或 SATA SSD。创建时最关键的两个参数是冗余策略和故障域。冗余策略决定数据副本数，默认有 2 副本和 3 副本可选。3 节点小集群我一般建议直接上 3 副本，虽然有效容量少一些，但任何一个节点宕机都不影响数据完整性，不用等重建完成才敢继续写。

故障域选项分为节点级和机架级。同一个机架内的多台服务器如果共享一个电源或接入交换机，应该选择机架级故障域，副本会分布到不同机架，避免单机架断电导致所有副本同时离线。

创建存储池时还有一个经常被忽略的选项：热备容量。热备容量会在磁盘故障时自动用于数据重建，类似传统 RAID 的热备盘。建议预留一块磁盘或至少一个节点容量的空间作为热备，否则磁盘故障后要等人工加盘才能开始重建，这段时间数据处于降级状态，风险较高。

3.3 创建高性能块存储池：给 iSCSI 和虚拟化用

高性能块存储池和容量型存储池在创建流程上类似，但介质和用途完全不同。它通常选择 NVMe SSD 或高性能 SAS SSD，用于承载 iSCSI 块存储，供虚拟机磁盘、数据库数据文件这类对 IOPS 和时延敏感的业务使用。

块存储池创建完成后，后续的 iSCSI 服务端、服务器、LUN 都建立在这个池之上。和容量型相比，块存储池的性能表现不仅取决于磁盘介质，还取决于存储网络的链路质量。使用双万兆网卡时，建议做链路聚合或至少保证两张网卡都接入，避免单链路故障导致块设备 IO 中断。

容量型和性能型的选择可以这样判断：

不要试图用一个池同时满足所有需求。文件共享业务量大时占满 IO，数据库的时延就会被拉高，这类问题在交付后极难排查，因为从存储池角度看不出异常。

4. 文件存储与块存储实操：NFS、CIFS、FTP 和 iSCSI 的创建与接入

4.1 NFS/CIFS/FTP 共享创建的完整流程

文件存储是 EDS 最常用的功能。手册的流程是先在存储池上配置文件存储目录权限，再创建具体协议的共享。创建 NFS 共享时，需要填写共享路径、允许访问的客户端网段、读写权限（rw 或 ro）以及 root squash 配置。CIFS 共享面向 Windows 客户端，要配置工作组或域环境、共享用户权限。FTP 共享则用于需要标准 FTP 工具访问的场景。

以 NFS 为例，共享创建完成后，Linux 客户端挂载命令如下：

# 推荐使用虚拟 IP 挂载，避免单节点故障导致客户端断连 mount -t nfs 172.16.1.20:/nfs_share /mnt/eds # 172.16.1.20 为文件存储虚拟 IP 池中的地址 # /nfs_share 为共享路径，/mnt/eds 为本地挂载点

强调一点：挂载地址尽量用虚拟 IP，不要直接用某个节点的业务 IP。虚拟 IP 漂移机制会在节点故障时把服务自动切到健康节点，客户端 TCP 连接不中断，对业务的影响几乎为零。如果直接挂节点 IP，节点宕机后就要手动改挂载点。

CIFS 共享创建后在 Windows 客户端访问 \172.16.1.20\共享名，用配置好的账号登录即可。FTP 共享创建时会设置端口，默认 21，也可以改为非标准端口规避扫描。三种协议的权限体系是独立的，同一个共享目录如果通过不同协议访问，身份认证需要靠用户映射来解决，这个放到下一节讲。

4.2 虚拟 IP 池、AD 域认证与多协议共享

多协议共享是 EDS 文件存储的一个亮点，也是新手最容易绕晕的地方。NFS 客户端用 UID/GID 做身份标识，CIFS 客户端用 Windows SID，FTP 客户端用账号密码，三者天然不互通。手册用了一整节讲用户映射，目的就是解决同一份文件在不同协议下权限不一致的问题。

实际配置时，启用多协议共享的前提是 AD 域认证。把 EDS 文件存储加入 AD 域后，域用户通过 CIFS 访问时拿到的是域账号身份，通过 NFS 访问时需要做 UID 映射。一般做法是在 AD 域中给用户或用户组设置统一的 UID 属性，然后手动在存储侧完成映射。配置不当会出现典型的权限问题：Windows 上能写、Linux 上只读，反过来也有。

虚拟 IP 池在多协议共享中作用很大。文件存储的虚拟 IP 池独立于存储池，创建共享时把虚拟 IP 池绑定到共享上，客户端无论通过哪个协议访问，入口 IP 都是同一个。配置虚拟 IP 池时要注意：池内 IP 必须和客户端处于同一二层网络，跨三层访问需要额外配置路由，虚拟 IP 漂移功能在三层环境下会受限。

4.3 iSCSI 块存储：LUN 创建和 Linux/Windows 客户端接入

块存储走 iSCSI 协议，流程比文件存储多一步：先在存储侧配置 iSCSI 服务端，再创建服务器条目记录客户端的 initiator IQN，最后创建虚拟卷（LUN）并映射给指定服务器。这样做的目的是做接入认证，只有登记过的 initiator 才能发现和登录 LUN。

Linux 客户端接入的完整命令序列如下：

# 安装 iscsi-initiator-utils 后，先发现目标端 iscsiadm --mode discovery --type sendtargets --portal 172.16.1.21 # 172.16.1.21 为块存储虚拟 IP # 登录发现到的 target iscsiadm --mode node --targetname <iqn名称> --portal 172.16.1.21 --login # 查看新增磁盘，确认 /dev/sdX 后格式化并挂载 mkfs.xfs /dev/sdb mount /dev/sdb /mnt/data

参数说明：discovery 阶段拿到的是 target 名称，login 时 --targetname 要和 discovery 结果一致；如果配置了 CHAP 认证，还要在 /etc/iscsi/iscsid.conf 里填写用户名和密码，再重启 iscsid 服务。登录后可以用multipath -ll查看多路径状态，双网卡环境下建议启用 multipath 避免单链路故障导致 IO 中断。

Windows 客户端不需要命令行，在"iSCSI 发起程序"里填入存储侧虚拟 IP，点击快速连接，登录后到磁盘管理里初始化磁盘即可。VMware 环境则是在主机存储适配器里添加软件 iSCSI 适配器，填写存储 IP 和 CHAP 认证信息，然后扫描存储，方式类似但要注意 VMware 的 LUN 路径策略一般选"最近使用"或"固定"。

5. 常见问题避坑：V3.0.5 部署运维中 6 个真实翻车点

5.1 集群组建时节点互相发现不了

现象：初始化时两个节点输入对方 IP 后，界面一直显示等待中，节点列表为空。

原因：最常见是管理网 VLAN 隔离导致三层不可达，或者防火墙拦截了节点间通信端口。还有一部分是安装时管理 IP 掩码填错，节点虽然在同一交换机，但不在同一网段。

解决：先在本机 ping 对端管理 IP 确认二层连通，再检查交换机端口 VLAN。确认物理通后，对比两台节点管理网掩码和网关是否一致。如果还不行，检查防火墙是否放通管理口之间的通信，交付环境经常有安全设备串在管理网里。

5.2 授权激活提示 License 不匹配

现象：上传授权文件后，控制台提示授权信息错误或与设备序列号不符。

原因：授权文件与集群序列号、节点数绑定。要么是序列号填错导致生成出来的 License 不对，要么是激活时集群节点数和购买授权数不一致。

解决：回到深信服官网授权管理页面，核对申请授权时填写的序列号与控制台页面显示的是否一致。一致的情况下检查授权节点数，授权 4 节点，集群不能加第 5 个节点。注意临时扩容节点时也需要提前申请新授权，不能抱侥幸心理。

5.3 存储池创建后有效容量远小于预期

现象：采购时按裸容量算了 100TB，建成后可用空间只有 40TB 左右，业务方质疑容量缩水。

原因：分布式存储有效容量 = 裸容量 ÷ 副本数，再减去热备容量和系统预留。3 副本时理论利用率只有 33%，2 副本是 50%，热备和系统预留还会再吃掉一部分。

解决：建池前先按公式算清楚，并让业务方在立项阶段就确认冗余策略。如果业务能接受一定风险，2 副本配合快照可以换取更多可用空间；无法接受风险就明确告诉业务方 3 副本的容量代价，别等建完池再解释。

5.4 NFS 访问偶发性卡顿，写入大文件时断连

现象：日常读写正常，大批量拷贝文件时 NFS 客户端长时间无响应，甚至报 Input/output error。

原因：客户端和存储端 MTU 不一致。存储内网配置了 9000 巨帧，但客户端业务网还是 1500，大包传输时触发分片，交换机无法处理导致丢包重传，表现就是卡顿和断连。

解决：把客户端挂载所用网卡的 MTU 调整到和存储端一致，再用 ping 带 DF 标志验证。命令是ping -M do -s 8972 <虚拟IP>，能通说明巨帧链路正常。两端统一 MTU 后再做一次大文件写入测试，问题一般就消失。

5.5 快照恢复后数据不是期望状态

现象：从快照恢复某个文件或 LUN，恢复完成业务启动后，数据比预期时间点晚了几分钟，或者出现部分文件缺失。

原因：快照恢复通常只能恢复到快照创建时刻，如果快照创建后还有新数据持续写入，原地恢复会覆盖这些增量数据。部分文件缺失则可能是恢复时业务系统没停，文件仍处于写状态，恢复出来的数据不完整。

解决：恢复前先确认快照时间点和业务数据一致性要求，数据库类业务优先用一致性组快照，保证多个 LUN 在同一时间点。恢复操作在业务停写后进行，恢复后立即做数据校验。要保留恢复点之后的改动，优先用快照克隆而不是原地恢复。

5.6 回收站配置不生效，删掉的目录找不到

现象：在存储上启用了回收站，客户端删除文件后回收站里是空的。

原因：回收站是按共享级别启用的，不是全局参数。NFS 共享启用回收站后，客户端挂载参数也有要求，有的版本默认挂载不带回收站映射参数，删除的文件不会进回收站。

解决：确认具体共享的回收站开关是开着的，再看协议对应的挂载方式。NFS 共享要确认客户端是否通过回收站专用路径访问，CIFS 共享则在 Windows 客户端的回收站目录里查找。配置修改后需要重新挂载共享才生效。

6. 对象存储与数据保护：Bucket 生命周期和快照恢复的进阶用法

对象存储在 EDS 里的使用路径很清晰：先创建对象存储用户，再创建 Bucket，把 Bucket 授权给用户，然后通过 S3 兼容接口接入。手册里讲到的整体上传、分段上传、下载和删除 Object，对应的就是日常备份和归档场景。分段上传适合大文件，超过单个 PUT 上限时，用分段上传可以断点续传，失败只需重试失败段，不用整文件重传。

验证对象存储是否通，我用 S3 兼容工具跑一轮最直接：

# 创建测试桶，--host 指向对象存储虚拟 IP 和端口 s3cmd mb s3://test-backup --host 172.16.1.30 --host-bucket 172.16.1.30 # 上传一份备份文件，验证读写链路 s3cmd put /data/app_backup.tar.gz s3://test-backup/ --host 172.16.1.30 --host-bucket 172.16.1.30 # 列出桶内对象，确认上传完成 s3cmd ls s3://test-backup --host 172.16.1.30 --host-bucket 172.16.1.30

参数说明：--host-bucket指定桶的访问模式，如果用的是路径风格访问，这个参数要和--host保持一致；端口默认 80 或 443，如果控制台上改过端口，记得补--port。上传完成后我会再执行一次下载对比校验，确认对象内容和源文件一致。数据保护方面，快照策略和一致性组快照是 EDS 数据保护的根基。文件存储和块存储都可以创建快照策略，按天或按周定时执行，快照本身不占满空间，采用写时复制机制，但要注意快照不要保留太多份，每个快照占用的空间会随数据变化持续增长。多数据中心场景下的站点切换，建议每季度做一次计划内切换演练，切换前确认容灾站点状态和链路带宽，别等真正故障时才发现半年没演练，配置早就和现网脱节了。

我从第一次交付 EDS 到现在，一直保持一个习惯：不管实施进度多紧，存储池建完后一定强制走一遍完整验证——挂载 NFS 写入测试文件、用 s3cmd 跑一次上传下载、创建快照并恢复到临时目录核对数据。这套动作总共花不到半小时，但能提前暴露出接入层八成的问题。某次就是因为少做了一次 iSCSI 登录验证，业务上线当天才发现 LUN 没映射对。从那以后，每次移交前我都会把这几步当成硬性流程走完，希望帮到你。

本文还有配套的精品资源，点击获取