将单体光存储控制系统改造为基于iSCSI的云存储方案，本质上是从“直接控制硬件”转向“通过网络访问标准块设备”。这个改造的核心是引入一个存储服务端（提供iSCSI Target），并将你的写入控制系统改造为iSCSI客户端（Initiator）。以下是详细的技术方案：

---

一、 总体架构设计

原有系统是“控制器-驱动器-光头”的闭环。改造后，架构将分为三层：

1. 云存储端：由存储服务器（如Ceph集群、商业存储阵列或NAS）创建LUN（逻辑单元号），并通过iSCSI协议暴露给网络。

2. 控制端：原有的控制软件运行在宿主机上，但它不再直接发指令给硬件，而是通过iSCSI发起方连接到云端的LUN。

3. 客户端挂载：操作系统会将远端LUN识别为本地块设备（如 /dev/sdb），你的现有写入软件只需像写本地硬盘一样写这个设备即可。

架构示意图逻辑：
[光存储写入软件] -> [操作系统文件系统/RAW] -> [iSCSI Initiator驱动] -> [TCP/IP网络] -> [iSCSI Target服务] -> [后端物理存储(HDD/SSD)]

二、 核心技术改造路径

1. 服务端改造：搭建iSCSI Target

你需要将现有的物理存储介质（硬盘/SSD）或云上空间通过网络共享出来。推荐以下两种方式：

• 方案A：使用企业级NAS/SAN（如Synology/QNAP/TrueNAS）

  • 操作：在存储管理界面创建 Target 和 LUN。建议使用瘦供给（Thin Provisioning）以提高空间利用率。

  • 配置：记录下Target的 IQN（如 iqn.2000-01.com.synology:disk.nas1）和IP地址（默认端口3260）。

• 方案B：使用开源存储引擎（如Ceph + iSCSI网关）

  • 对于更大规模或需要高可用的场景，可以在Ceph集群上部署iSCSI网关。Ceph的librbd接口配合iSCSI网关能提供企业级的性能。

2. 客户端改造：集成iSCSI Initiator

这是你控制系统的核心改造点。你需要确保运行写入软件的操作系统能够识别远程存储。

• Linux环境：

  • 安装 open-iscsi 和 multipath-tools 软件包。

  • 配置 initiatorname.iscsi 文件，设置唯一的客户端IQN以便服务端做访问控制（ACL）。

  • 关键配置：设置 node.session.timeo.replacement_timeout 和 node.conn[0].timeo.login_timeout 等参数，以适应网络波动，避免写入任务因短暂断网而崩溃。

• Windows环境：

  • 启动 Microsoft iSCSI Initiator 服务。在“发现”门户中输入Target IP，在“目标”中连接卷。

3. 多路径与高可用配置

由于你原本是“单体”系统，改造成云存储后，网络故障是主要风险点。必须配置多路径（Multipath）：

• 原因：防止单网卡、单交换机或单网线故障导致写入中断。

• 实施：在服务器端配置两个网口（不同网卡或交换机），在iSCSI客户端启用 DM-Multipath。

• 配置建议：

  • 在 /etc/multipath.conf 中设置 polling_interval 和 path_grouping_policy 为 multibus。

  • 设置 path_selector "round-robin 0" 以平衡负载。

  • 开启 fast_io_fail_tmo 5 和 dev_loss_tmo 30，以便在链路故障时快速切换到备用路径。

三、 软件逻辑改造（代码/驱动层面）

原有模式：
Write_Command(光驱地址, 数据)

改造后模式：
Write_Command(/dev/sdb, 数据) -> SCSI命令 -> TCP/IP封装 -> 网络传输

1. 移除硬件依赖性：你需要修改控制软件底层驱动。如果原来是直接调用 ioctl 控制光驱，现在需要改为标准的文件I/O操作（如 open, write, fsync）。

2. 增加错误重试机制：

   • 云存储可能因网络拥塞出现延迟抖动或暂时性的 EAGAIN 错误。

   • 建议：在应用层封装重试逻辑（Exponential Backoff），不要直接抛出“写入失败”的致命错误。

3. 数据一致性：

   • 光存储写入通常要求严格一致。在mount iSCSI卷时，建议挂载参数加上 sync 选项（虽然性能会下降，但保证数据安全）。

   • 或者在每次关键数据写入后，调用 fsync() / FlushFileBuffers 强制落盘。

四、 性能优化建议

针对光存储的连续大文件写入特性，请进行以下优化：

优化项	建议值/方案	原因
MTU	启用 Jumbo Frame (MTU 9000)	减少CPU中断，提升大块数据传输效率。
块大小	匹配底层存储的 块大小 (如16KB或32KB)	避免写放大（Write Amplification）。
队列深度	设置 cmds_max 和 queue_depth 为较高值（如128或256）	允许存储端并行处理命令，提升吞吐量。
网络	存储网络与业务网络 隔离 (使用VLAN或独立网卡)	避免突发业务流量导致存储延迟飙升。

五、 改造步骤实施清单

1. 环境准备：

   • 搭建存储服务器，创建1TB测试LUN。

   • 确保控制端服务器有额外的网口用于存储网络。

2. 连接测试：

   • 在控制端使用 iscsiadm 发现并登录Target。

   • 验证重启后LUN能否自动重连（设置 node.startup = automatic）。

3. 驱动替换：

   • 编写适配层代码，将原有的“写光驱”API映射为“写文件”API（写入挂载点下的特定文件或RAW设备）。

4. 故障模拟测试：

   • 拔网线测试：模拟30秒网络中断，观察写入软件是否会卡死或崩溃。

   • 存储重启测试：在写入过程中重启iSCSI Target服务，验证客户端 open-iscsi 的重连机制能否在恢复后继续写入。

   • 多路径测试：拔掉一根网线，确认 multipath -ll 显示路径失效但I/O未中断。

六、 关键风险提示

• 数据一致性：传统的SCSI命令（如SYNC CACHE）在iSCSI环境下可能转换为较弱的语义。如果光存储写入依赖严格的物理屏障（Barrier），在云存储环境下可能会丢失。建议：如果数据极为关键，考虑在应用层增加CRC校验。

• 延迟不可预测：单体控制（直连SATA/SAS）延迟通常是微秒级（~50μs）；iSCSI即使是万兆网络，延迟也在毫秒级（~1-5ms）。需要评估你的写入控制时序逻辑是否能容忍这种延迟。