Electronic Joint Business

Solution for E-Business

storage

编写虚拟 Storport 微端口驱动(一)

Storport 广受虚拟存储设备驱动编写者的欢迎。在 Storport 出现前,要完成类似的工作,你不得不修改(hack) SCSIport 微端口驱动,或者自己写个完整的 SCSI 端口驱动。修改微端口的方法十分复杂 (由于锁的问题)、 难以获得支持或者维护,而且性能较差。而编写完整的 SCSI 端口驱动的方法虽然性能不错,但技术难度高,而且也不支持 Windows 徽标认证。因此,这一领域的开发工作只限于那些愿意冒险、敢于尝试、而且不打算过徽标认证的公司和个人。1

Storport 是跟着 Windows Server 2003 被引入的,用来满足 RAID 和 SAN 环境的性能要求,这是以前的 SCSIport 驱动所不具备的。后续在 Windows Vista SP1 和 Server 2008 中,微软又更新了 Storport,提供了对 Storport 虚拟微端口驱动的支持。这个更新终于让存储驱动编写者拥有了一个能导出虚拟设备的模型。

对于虚拟微端口驱动的编写来说,Storport 模型相当不错。它提供了诸如 I/O 队列管理 (如队列深度、到达队列深度阀值时对 I/O 进行处理)、 I/O 错误处理 (如重置、重试等)、 启动或停止 PnP 设备 (LUN) 所需的所有操作以及总线驱动的所有职能。它只是无法提供硬件管理方面的帮助,因为我们开发的是虚拟微端口,所以并未存在任何硬件。另一方面,虚拟微端口驱动则要完全负责处理 I/O 请求。虽然听起来令人生畏,不过作为虚拟微端口驱动,你有全套的内核 API 和其它驱动程序来帮助完成这一工作。

开始
可能你从未接触过 Storport ,所以这里先了解一些基础知识。当你利用 Storport 模型进行开发时,这意味着你的驱动需要将接口暴露给 Storport 驱动 (Storport.sys),这是通过预定义的 API 和数据结构完成的,而不是基于 IRP。与 SCSI 端口/微端口模型类似,Storport 驱动被称为端口驱动,提供了微端口驱动进行操作的环境和支持例程,如此我们的适配器才对 Windows 存储子系统可见。这里适配器可以是物理设备或者虚拟设备,可以控制多条 SCSI 总线或多个 SCSI 设备。基于该模型所开发驱动即微端口驱动,图1-1 显示了 Storport 模型。

Storport 微端口驱动必须符合预定义的 Storport 规则以便将适配器(虚拟或物理)的服务提供给操作系统。Storport 通过 SCSI_REQUEST_BLOCKS (SRB — SCSI 请求块) 来调用微端口驱动, SRB 描述了要执行的操作。与 IRP 类似,SRB 包含了微端口驱动执行操作需要的所有信息。它包含一个操作码、 缓冲区以及用来描述请求的参数。驱动执行 SRB 描述的操作、将完成状态放入 SRB ,并完成请求时通知 Storport。该过程与普通驱动处理 IRP 不一样。

>>> 阅读全文

 

, , ,

SAN 还是 NAS?关键性的选择

对于首席信息官和 IT 决策者来说,选择部署使用存储区域网络(SAN — storage area network)还是网络附加存储(NAS — network attached storage )将是一个重大决定(ranks right up)。 SAN?NAS? 或这两种技术的结合?这种选择对存储环境的结构的作用是决定性的起了。今天的决定将影响未来企业的数据该如何存储,商业用户该如何访问数据、持续管理成本的多寡和构成、以及整个组织内数据的生命周期。

仔细考察企业整体业务流程,并思考如何将数据管理的策略融入这些过程中。 在 SAN 与 NAS 之间做出选择是能够支持企业级有的战略和长期业务目标的最好支撑。你必须确保你所做的选择及其部署方式能够完全支持这一战略。为了选择最适合企业商业目标和商业流程的技术,我们必须了解这两种技术的异同点、存储类型以及最适合的存取方式。

简单地说, SAN 是多台设备构成的网络,适合块级存储。而 NAS 是单一的存储单元,适合文件级别的存储。二者的主要特点如下:

SAN 存储区域网络:

  • 多个磁盘阵列的专用网络
  • 存储一致性的(Consolidated) 连续的块级数据
  • 服务器可以访问存储在网络设备上的数据
  • 可以按特定的应用或者用户控制存取

网络附加存储 (NAS):

>>> 阅读全文

 

, , ,