简介：本资源是北京亚细亚智业科技有限公司官方发布的《火星舱使用指南》完整PDF手册，面向NAS存储系统管理员、IT运维工程师及iSCSI存储部署技术人员，用于指导火星舱存储设备的安装、初始化、系统管理、NAS网络存储配置、虚拟磁带库搭建、统一备份与Oracle数据库备份等核心场景。手册共396页，结构清晰，覆盖11大功能模块，含详细操作步骤、界面按钮说明（如【保存】、{网络}菜单）、注意事项提示及技术支持渠道，具备强实操性与权威参考价值。资源为单文件PDF格式，大小20.43MB，内容完整无删减，适合作为现场调试、故障排查与日常运维的随查工具书。目前已有61人学习下载，是掌握国产专业级备份存储平台——火星舱全功能体系的重要技术文档。
1. 火星舱不是“火星上用的存储”，而是国产IP-SAN/FC-SAN融合架构的现场落地手册
你手头这份396页的《火星舱使用指南》，不是科幻设定集，也不是厂商PPT幻灯片——它是一线工程师在2015年真实部署某高校数据中心、某三甲医院影像归档系统、某省级政务云灾备节点时，每天翻烂了边、贴满便签、写满批注的实操底稿。它解决的不是“理论上怎么连”，而是“RAID5+0重建卡在73%不动了怎么办”“iSCSI Target突然失联但物理链路灯全亮”“NAS共享目录Windows能挂载Linux死活报Permission denied”这类血淋淋的问题。整套系统基于X86服务器硬件，却同时提供FC SAN块存储、IP-SAN块存储、NAS文件服务、虚拟磁带库（VTL）、CDP持续数据保护、Oracle热备份、VM虚拟机托管六大能力模块，本质是把传统中高端存储的软硬一体化能力，下沉到通用服务器平台。适合对象非常明确：没有专职存储工程师的中小IT团队、需要快速交付灾备方案的集成商、正在做国产化替代评估的技术负责人。它不讲分布式一致性哈希，不谈NVMe-oF协议栈，所有操作都落在Web控制台点选+少量命令行验证，但正因如此，每一个【保存】按钮背后，都藏着RAID校验逻辑、CHAP认证密钥生命周期、NFSv3/v4权限映射规则等硬核细节。如果你正面对一台刚上架的火星舱设备，手边只有网线、U盘和这本手册PDF，那么接下来你要做的，不是读完396页，而是精准定位第2章初始化、第4章设备管理、第7章NAS网络存储这三个章节——它们覆盖了90%首次交付场景的断点。
2. 初始化必须过三关：登录鉴权、产品注册、系统卷创建——缺一不可
火星舱的初始化不是“装完系统点下一步”那种线性流程，而是一个强依赖顺序的三阶段门禁系统。跳过任一环节，后续所有功能模块（包括NAS共享、iSCSI Target）都会显示“未就绪”或直接灰显。我见过太多人卡在第二步注册失败，反复重刷页面，最后发现是IE浏览器版本不对；也有人RAID创建成功却无法进入系统管理界面，查日志才发现系统卷没激活。下面拆解每一步的真实执行路径和关键参数含义。
2.1 登录：高版本IE是硬性前提，非可选项
火星舱Web管理界面基于ActiveX控件构建，对浏览器内核有强绑定。实测有效组合仅有：
- IE 11（Windows 7 SP1 / Windows 10 1809及以下）
- IE 10（Windows 7 SP1，需手动启用Compatibility View）
Chrome、Firefox、Edge（Chromium版）全部无法加载控制器状态页，会卡在空白页或报“Object doesn't support property or method 'xxx'”。
提示：若现场只有Win10新机，务必提前下载IE11离线安装包（KB2999226），禁用Windows Update自动升级IE。曾有客户因系统自动升到IE11.0.130+，导致CHAP配置页JS报错，回退补丁后才恢复。
登录地址格式为http://<设备IP>，严禁加端口号或https。默认IP为192.168.100.1，若修改过需通过串口线连接Console口重置（见第11章）。默认凭据固定为：
用户名：admin 密码：admin注意：该账号为超级管理员，不支持多开。A用户登录后，B用户再登录，A会话将被强制踢出且未保存的配置丢失。这是设计缺陷，不是bug。
2.2 注册：MSARegister.xml文件必须与设备SN严格匹配
未注册设备登录后会强制跳转至注册页。点击【导入】后弹出的文件选择框，只接受XML格式，且文件名必须为MSARegister.xml（大小写敏感）。该文件由厂商提供，内含设备唯一序列号（SN）和授权特征码（Feature Code），与设备主板BIOS中的SN硬绑定。常见翻车点：
- 用A设备的XML注册B设备 → 报错“SN不匹配”，界面无提示，仅返回空白页
- XML文件被文本编辑器另存为UTF-8 BOM格式 → 解析失败，注册按钮变灰
- 文件扩展名看似.xml实为.txt（Windows隐藏已知扩展名）→ 导入后无响应
正确做法：用Notepad++打开XML，编码菜单确认为“ANSI”；用记事本打开时，另存为对话框底部“编码”选“ANSI”；注册成功后页面跳转至系统卷创建页，此时才算真正激活设备。
2.3 系统卷：RAID模式选择不是性能竞赛，而是故障域隔离策略
系统卷是火星舱所有服务的根文件系统载体，其RAID配置直接决定设备可用性。手册第12页的RAID说明存在误导性表述——RAID6+0“技术不成熟”是2015年的保守判断，实际在T2-20150620-2固件中已稳定支持。关键参数逻辑如下表：
| RAID类型 | 最小磁盘数 | 容错能力 | 适用场景 | 血泪经验 |
|---|---|---|---|---|
| RAID1 | 2 | 坏1盘不丢数据 | 电子系统盘（即OS盘），必须用镜像保障启动可靠性 | 曾有客户用RAID0做系统盘，SSD寿命耗尽后整机无法启动，重装耗时8小时 |
| RAID5 | 3 | 坏1盘可重建 | 通用数据盘，性价比首选 | 重建时间>24h时，第二块盘故障概率陡增，务必开启后台校验 |
| RAID6 | 4 | 坏2盘不丢数据 | 医疗PACS影像、视频监控等大容量冷数据 | 需关闭“快速初始化”，否则首次写入性能暴跌50% |
| RAID5+0 | 6（偶数） | 单组坏1盘+跨组容错 | 虚拟机存储池，兼顾性能与安全 | 必须确保物理磁盘分属不同背板通道，否则单点故障致全组失效 |
| 三倍校验 | 6 | 坏3盘仍可读 | 国产化信创环境强制要求的高安全等级 | 写放大严重，随机写IOPS下降至RAID5的1/3，仅推荐顺序写场景 |
创建操作本身简单：勾选磁盘 → 选RAID类型 → 【保存】→ 勾选【确认执行】→ 等待设备重启。但重启后必须重新登录，且首次进入系统管理页会触发后台初始化（约5~15分钟），此期间所有服务不可用，进度条在{状态}→{概览}页右下角显示。切勿在此时强行断电！
3. 设备管理是火星舱的“中枢神经”，iSCSI与FC双栈配置必须同步闭环
设备管理（第4章）不是简单的网络设置，而是整个存储服务的拓扑定义层。它决定了前端主机如何发现、认证、访问后端LUN。其中iSCSI配置最常被低估——很多人以为配好Target就完事，结果Windows主机能发现Target却无法登录，Linux主机登录成功却挂载失败。根本原因在于：iSCSI的Initiator（发起端）与Target（目标端）之间，存在三层耦合关系：网络可达性、CHAP双向认证、LUN映射权限。漏掉任何一层，链路即断裂。下面以iSCSI为例，给出可直接复现的配置流。
3.1 iSCSI网络基础：子网划分必须与前端主机严格对齐
火星舱iSCSI服务绑定在特定物理网口（如eth1），该网口IP必须与前端主机iSCSI Initiator配置在同一子网。常见错误配置：
- 火星舱iSCSI网口设为
10.1.1.100/24，前端主机iSCSI网卡设为10.1.2.50/24→ ping通但iSCSI发现失败 - 使用笔记本WiFi连接管理网（192.168.100.0/24），却试图从同一WiFi发起iSCSI发现 → 路由策略阻止iSCSI流量
正确做法：为iSCSI业务单独规划VLAN，例如：
# 在火星舱Web控制台 {网络管理} → {接口配置} eth1: IP=172.16.10.10, Netmask=255.255.255.0, Gateway=172.16.10.1 # 前端主机（Windows Server）iSCSI网卡： IPv4=172.16.10.100, Subnet=255.255.255.0, Gateway留空（iSCSI不走网关）注意：Gateway字段在iSCSI网口配置中必须填写，否则Target服务无法启动；但前端主机iSCSI网卡的Gateway必须为空，否则流量被路由到其他网段。
3.2 CHAP认证：不是“开了就行”，而是密钥生命周期管理
火星舱iSCSI默认强制开启CHAP双向认证（第4.5.3节），这是安全基线，不可关闭。但手册未说明密钥轮换机制——CHAP密码明文存储在设备Flash中，一旦泄露，攻击者可伪造Initiator接入。生产环境必须做到：
- Initiator密码 ≠ Target密码：两者必须不同，手册示例中设为相同是重大安全隐患
- 密码长度 ≥12位，含大小写字母+数字+特殊字符：弱密码会导致CHAP握手被暴力破解
- 定期更换（建议90天）：更换时需同步更新所有前端主机Initiator配置，否则批量失联
配置路径：{设备管理} → {目标器（Target）} → {iSCSI} → 选中Target → 【编辑】→ 勾选“启用CHAP认证” → 输入Target Secret（火星舱侧密码）→ 勾选“启用反向CHAP” → 输入Initiator Secret（前端主机侧密码）。
3.3 LUN映射：权限控制粒度精确到Host Group级
LUN不能直接分配给IP，必须先创建Host Group（主机组），再将主机IP/WWPN加入该组，最后将LUN映射到该组。这是实现多租户隔离的核心。典型配置：
- 创建Host Group：{设备管理} → {主机组（Host Group）} → {iSCSI} → 【新建】→ 组名
HG-DB-SERVER - 添加主机：点击
HG-DB-SERVER→ 【添加主机】→ 输入数据库服务器iSCSI IQN（如iqn.1991-05.com.microsoft:db01）→ 【确定】 - 映射LUN：{目标器（Target）} → {iSCSI} → 选中Target → 【LUN映射】→ 选中LUN0 → 拖拽至
HG-DB-SERVER组 → 【保存】
关键参数说明：
- LUN ID：必须全局唯一，同一Target下不可重复，否则Windows主机识别为“多个同名磁盘”导致BSOD
- LUN类型：选择“精简配置”可节省空间，但需配合后台空间回收（第5章CDP）；“厚置备”性能更稳，推荐Oracle RAC
- 读写权限：默认“读写”，若做备份源LUN，应设为“只读”防误写
完成上述三步后，在前端主机执行iSCSI发现：
# Windows PowerShell（以管理员身份运行） Install-WindowsFeature -Name FS-ISCSI-Initiator Set-Service -Name MSiSCSI -StartupType Automatic Start-Service MSiSCSI Get-InitiatorPortal # 确认iSCSI网卡已启用 New-IscsiTargetPortal -TargetPortalAddress 172.16.10.10 Get-IscsiTarget | Where-Object {$_.IsConnected -eq $false} | Connect-IscsiTarget -ChapUsername "db01" -ChapPassword "YourStrongPass123!"若Connect-IscsiTarget报错The target was not found，90%是CHAP密码不匹配；若报错The request is not supported，则是LUN未映射到该Host Group。
4. NAS网络存储配置的四个致命陷阱：CIFS/SMB权限继承、NFSv4 ID映射、防火墙穿透、ACL优先级
第7章NAS网络存储（285页起）表面看是“建个共享文件夹”，实则暗藏Windows与Linux混合环境下的权限地狱。我曾帮某制造企业排查连续两周的文件删除失败问题，最终发现是CIFS的SMB2协议与NTFS ACL继承规则冲突；另一案例是科研单位Linux集群挂载NAS后，所有文件属主显示为nobody，根源在NFSv4的idmapd配置缺失。这些坑手册里只字未提，全靠现场试错。下面直击最痛的四个点。
4.1 CIFS共享：SMB协议版本必须锁定，否则Windows 10/11拒绝连接
火星舱默认启用SMB1/SMB2/SMB3多版本兼容，但Windows 10 1809+及Windows 11默认禁用SMB1（因永恒之蓝漏洞），若未手动开启SMB2+，会出现：
- Windows客户端能发现共享名，但双击提示“找不到网络路径”
net use Z: \\172.16.10.10\share报错“系统找不到指定的文件”
解决方案：在火星舱Web控制台 {NAS网络存储} → {CIFS设置} → 【高级设置】→ 取消勾选“启用SMB1协议” → 勾选“启用SMB2协议”和“启用SMB3协议”。
血泪经验：某次升级固件后SMB2被自动关闭，导致全公司OA附件上传中断。紧急修复命令（需SSH登录）：
# 登录火星舱SSH（默认账号root，密码同admin） vi /etc/samba/smb.conf # 找到[global]段，确保包含： min protocol = SMB2 max protocol = SMB3 # 重启smb服务 /etc/init.d/smb restart
4.2 NFS共享：NFSv4必须配idmapd，否则UID/GID全乱码
NFSv3使用IP地址认证，NFSv4改用域（Domain）+用户ID（UID）双重认证。火星舱默认NFSv4域名为marstor.local，但前端Linux主机若未配置对应idmapd，则所有文件属主显示为nobody。验证方法：
# 在Linux客户端挂载后执行 ls -l /mnt/nas # 若显示：-rw-r--r-- 1 nobody nobody 1024 Jan 1 10:00 file.txt → idmapd未生效修复步骤：
- 编辑客户端
/etc/idmapd.conf：[General] Domain = marstor.local # 必须与火星舱NFS域一致 [Translation] Method = nsswitch - 重启idmapd服务：
systemctl restart rpc-idmapd # 验证域是否同步 rpcidmapd -f -v 2>&1 | grep "Domain" - 重新挂载：
umount /mnt/nas mount -t nfs4 172.16.10.10:/share /mnt/nas
4.3 防火墙：NAS端口必须放行，且顺序不能错
火星舱自身无防火墙，但若前端主机或中间交换机启用了ACL，以下端口必须开放：
| 协议 | 端口 | 方向 | 说明 |
|---|---|---|---|
| CIFS/SMB | TCP 445 | 火星舱→客户端 | SMB2/3核心端口，SMB1的139端口可禁用 |
| NFSv4 | TCP 2049 | 火星舱→客户端 | NFSv4单一端口，无需rpcbind |
| NFSv3 | TCP/UDP 111, 2049, 其他动态端口 | 火星舱→客户端 | 若必须用v3，需在火星舱{NFS参数}中固定端口范围 |
提示：某金融客户因交换机ACL只放行TCP 445，导致Mac客户端（默认走SMB）正常，但Linux客户端（默认走NFS）挂载超时。根源是NFSv4虽只用2049，但首次连接需建立RPC会话，部分旧内核会尝试UDP 111。
4.4 ACL权限：Windows ACL优先级高于Linux POSIX，且不可叠加
火星舱NAS支持两种权限模型：
- POSIX ACL：标准Linux权限（rwx），通过
setfacl管理 - Windows ACL：NTFS风格ACL，支持“读取”“修改”“完全控制”等细粒度项
致命陷阱：当同一目录同时启用两种ACL时，Windows ACL具有绝对优先级。例如：
- 目录
/share/projPOSIX权限设为drwxr-x---（组可读可执行） - 同时在Web控制台为Windows用户
DOMAIN\userA添加ACL：“读取”权限 - 结果：Linux用户
userA（同名）仍无法cd /share/proj，因Windows ACL覆盖了POSIX组权限
解决方案：严格分离使用场景——生产环境统一用Windows ACL管理（适合AD域环境），开发测试环境统一用POSIX ACL（适合Linux集群）。切换方法：{NAS网络存储} → {共享目录} → 选中目录 → 【权限设置】→ 选择“Windows ACL模式”或“POSIX ACL模式”，切换后原有权限丢失，必须重新配置。
5. 避坑：iSCSI连接失败、NAS挂载超时、RAID重建卡死——一线工程师的5条血泪排查清单
这些不是手册里的“注意事项”，而是我在三次现场交付中，用万用表测网线、用Wireshark抓包、用串口线看Bootlog后总结的硬核排错路径。每一条都对应一个让客户凌晨三点打电话来的故障。
5.1 现象：iSCSI Target在Windows客户端可见，但Connect-IscsiTarget始终超时
原因：火星舱iSCSI服务绑定在错误网口，或前端主机iSCSI网卡未启用Jumbo Frame（巨帧）
解决：
- 登录火星舱SSH，执行
netstat -tuln | grep :3260确认iscsid进程监听的IP是否为iSCSI业务网口 - 在Windows客户端iSCSI网卡属性 → 配置 → 高级 → 启用“Jumbo Packet”，值设为
9014（与火星舱/etc/iscsi/iscsid.conf中node.conn[0].tcp.window_size一致） - 若仍失败，临时关闭Windows防火墙测试（排除GPO策略干扰）
5.2 现象：NAS共享在Windows资源管理器中显示为“脱机”，右键“始终可用”无效
原因：Windows 10/11的SMB Client服务默认启用“快速启动”，导致SMB会话残留
解决：
- 以管理员身份运行CMD：
net stop lanmanworkstation /y net start lanmanworkstation # 清除SMB缓存 cmdkey /delete:172.16.10.10 - 或永久禁用快速启动：控制面板 → 电源选项 → 选择电源按钮的功能 → 更改当前不可用设置 → 取消勾选“启用快速启动”
5.3 现象：RAID5重建进度卡在73%，Web界面无报错，但磁盘指示灯狂闪
原因：某块磁盘存在大量坏道，重建时遭遇不可纠正错误（UNC），系统进入保护性暂停
解决：
- SSH登录火星舱，执行
smartctl -a /dev/sdb（替换为对应磁盘）检查Reallocated_Sector_Ct和Current_Pending_Sector值 - 若
Reallocated_Sector_Ct > 50，立即备份数据并更换磁盘；若Current_Pending_Sector > 0，执行smartctl -t long /dev/sdb进行全盘扫描，完成后smartctl -a查看结果 - 切勿强制继续重建：会加速磁盘死亡，导致整个RAID组崩溃
5.4 现象：NAS共享目录在Linux挂载后，ls命令卡住超过30秒，df -h显示100%占用但du -sh *总和远小于
原因：NFSv4的nfsdcld（NFS daemon cache）进程异常，缓存了错误的文件句柄
解决：
- 在Linux客户端执行：
sudo systemctl stop nfs-client.target sudo rm -rf /var/lib/nfs/v4recovery/* sudo systemctl start nfs-client.target # 重新挂载 sudo umount /mnt/nas && sudo mount -t nfs4 172.16.10.10:/share /mnt/nas
5.5 现象：更换电子系统盘后，导入系统卷失败，提示“卷签名不匹配”
原因：新系统盘未格式化，或旧系统卷备份文件损坏
解决：
- 用USB SATA盒将新系统盘接入Windows PC，用DiskPart彻底清空：
list disk select disk X # 选中新盘 clean convert gpt create partition primary format fs=ntfs quick exit - 将旧系统盘作为从盘接入，用
robocopy完整复制/system/目录（非整个分区）到新盘根目录 - 重新插入火星舱，按第2.3.2节流程导入——此时导入的是文件系统，而非RAID元数据
6. 验证NAS与iSCSI服务可用性的三步黄金法则：从链路层到应用层逐级穿透
交付验收时，客户常要求“证明存储真的好用”，而不是“界面点得通”。我从不演示Web控制台，而是带一台笔记本，用三组命令直击服务本质。这套验证法已用于17个项目的终验，零争议。核心逻辑：每一层验证都必须产生可观测的IO行为，且结果可量化。
6.1 链路层验证：确认物理路径与协议栈畅通
目标：排除网络设备、驱动、基础协议问题。
- iSCSI路径：在Windows客户端执行：
# 测试Target发现（不依赖GUI） iscsicli ListTargets 172.16.10.10 # 应返回Target IQN列表，如 iqn.2003-03.com.marstor:storage.target01 # 测试CHAP握手（不创建磁盘） iscsicli QLoginTarget iqn.2003-03.com.marstor:storage.target01 /password:YourSecret123! # 成功返回"Login completed successfully"，失败则暴露CHAP或网络问题 - NAS路径：在Linux客户端执行：
# 测试NFS端口可达性（绕过mount） telnet 172.16.10.10 2049 # 应显示"Connected to 172.16.10.10" # 测试CIFS端口（SMB2） nc -zv 172.16.10.10 445 # 应显示"succeeded!"
6.2 服务层验证：测量真实IO性能与稳定性
目标：确认LUN/NAS共享能承受生产负载。
- iSCSI LUN性能：使用
diskspd（微软官方工具）：# 测试4K随机写（模拟数据库日志） diskspd -c1G -d300 -o32 -t4 -r -w30 -b4k -W10 -L -Z1G \\.\PhysicalDrive2 # 关键指标：Avg_Latency_ms < 15ms，IOPS > 5000 即达标 - NAS共享性能：使用
fio（Linux）：# 测试NFSv4顺序读（模拟视频转码） fio --name=readtest --ioengine=libaio --rw=read --bs=1M --size=2G \ --runtime=300 --time_based --directory=/mnt/nas --filename=fio_test \ --group_reporting --direct=1 # 关键指标：read: IOPS=120, BW=122MB/s，lat (usec): avg=8200
6.3 应用层验证：用真实业务场景压测
目标：证明服务满足业务SLA。这是客户最关心的，也是最容易翻车的环节。
- Oracle备份验证：在数据库服务器执行RMAN：
RUN { ALLOCATE CHANNEL c1 DEVICE TYPE 'SBT_TAPE' PARMS 'SBT_LIBRARY=/opt/marstor/lib/libmars_sbt.so,ENV=(MARSTOR_SERVER=172.16.10.10,MARSTOR_USER=admin,MARSTOR_PASS=admin)'; BACKUP DATABASE PLUS ARCHIVELOG; } # 观察RMAN输出：若出现"channel c1: backup set complete"且耗时在预期内（如1TB库<2h），则Oracle备份链路通 - 虚拟机迁移验证：在vCenter中将一台测试VM从本地存储迁移到火星舱iSCSI LUN：
- 迁移过程中，实时观察火星舱Web控制台 {状态} → {I/O统计}：
Read IOPS和Write IOPS应随迁移进度同步上升，峰值>3000Avg Response Time保持 < 20ms
- 迁移完成后，立即在VM内执行
dd if=/dev/zero of=/tmp/test bs=1M count=1024 oflag=direct，确认写入速度>80MB/s
- 迁移过程中，实时观察火星舱Web控制台 {状态} → {I/O统计}：
从那以后我每次交付火星舱，都强制走一遍这三步验证：先跑通
iscsicli ListTargets和telnet，再跑diskspd/fio看IO曲线，最后用RMAN或VM迁移打满带宽。不是为了炫技，而是因为——所有声称“配置好了”的设备，90%在第三步崩盘。崩在IO超时、崩在CHAP密钥过期、崩在NFSv4域不匹配。而这份396页的手册，恰恰在第285页的NAS章节、第91页的iSCSI章节、第351页的Oracle章节，埋下了所有答案。希望帮到你。
本文还有配套的精品资源，点击获取
