HDS NAS 原理及Storage Pool方案

做VDI项目,数据存储是必要的。选择传统的SAN和NAS存储无疑是最稳妥的一种选择。

非存储专业的技术人员,对企业存储需要懂多少?其实只要略懂就可以了。

本文以HDS品牌为题材书写,包含两部分内容:一是介绍HDS的NAS提供流程(硬件网关型)并提炼技术要点,二是介绍了两种不同的Storage Pool划分思路。

1 从SAN硬盘到NAS服务

HDS NAS服务示意

上图描述了HDS的NAS设备(外置Hnas网关或内置NAS module)使用HDS的SAN存储来提供NAS服务的过程。

  1. 物理磁盘层。物理硬盘组成Raid组,部分硬盘成为热备盘(Hot Spare)。
  2. DP Pool(Dynamic Provisioning Pool)。多个Raid组虚拟组成一个DP Pool。
  3. 在DP Pool中,划分出若干LUN。
  4. NAS设备识别到上一步中的LUN(通过SAN网络或直连SAN存储)。在NAS设备上操作,将这些LUN划分到不同的Storage Pool中。多个LUN虚拟化成一个Storage Pool。
  5. 在一个Storage Pool中可建立多个文件系统(File System),比如NFS文件系统或者CIFS。
  6. 对每个文件系统建立Share,即可提供对外服务。

2 技术注释

2.1 NAS的Drive = SAN的LUN

在NAS设备的视角上看,SAN存储提供的LUN,对于它来说就是物理硬盘。在NAS设备上观察Storage Pool属性,可以看到一个Storage Pool由多个Hosting System Drives组成。每个Drive,其实就是SAN存储提供的一个LUN。

上图中,SAN存储共提供9个2T的LUN。

2.2 配置信息在SAN上

Storage Pool的划分虽然是在NAS设备上操作,但Pool结构和文件系统划分配置等信息是写入到SAN存储的LUN上的。NAS设备不保存磁盘和文件系统配置信息。

简单类比,就像在普通PC机上对硬盘做格式化和分区一样,信息是写入到硬盘中的。

2.3 NAS与Storage Pool

一个Storage Pool只能对接一套NAS设备(单节点和多节点集群均算一套)其中的LUN只可被分配一次。

简单类比,正如一块硬盘不能同时插到两台PC机上,一个LUN也不能分配给多套NAS设备。

使用过的LUN不能从Storage Pool中退出。Storage Pool是多个LUN的虚拟化,使用时数据条带化写入到每个LUN中,对每个LUN的操作又条带化地写入到组成DP Pool的多个Raid组中,由此使得组成Raid组的所有物理硬盘性能被充分利用。

2.4 NAS机头的更换

NAS机头仅仅提供计算性能,而不保存生产数据。因此,更换NAS机头(或module)不涉及数据风险。当然,停机是免不了的。同时,新NAS机头和旧SAN存储之间需要满足兼容性要求。

简单类比,现状就像是普通PC机插着普通硬盘,做成一台文件共享服务器对外提供服务。我们可以把硬盘拆下来,换到另一台PC机上使用(前提是兼容)。

3 Storage Pool设计

在了解上述基础信息之后,我们来看Storage Pool的设计。常见有以下两种设计方案。

HDS拓扑图2

3.1 图示说明

  • NAS1和NAS2为一对双节点集群,NAS3和NAS4为一对双节点集群。
  • 正如前文所说,一个LUN只能被一套集群使用。淡蓝色代表该Storage Pool中的LUN分配给NAS1、2集群使用。淡粉色代表该Storage Pool中的LUN分配给NAS3、4集群使用。
  • 蓝、绿、紫、棕四种颜色代表四种不同类型的业务。文件夹代表文件系统。
  • 文件系统与NAS机头的连线,代表NAS计算能力的分配关系(mount),是动态可调整的。例如,第一种方案中,业务A_1文件系统mount在NAS1节点上,当NAS1节点故障时,NAS2节点会接管此文件系统。

3.2 方案详解

第一种方案的Storage Pool划分依据,是NAS集群数量。因为有两个独立的NAS集群(它们之间是没有任何关联的),一个LUN只能被一个NAS集群使用,因此,至少需要建两个Storage Pool,分别对应两套NAS——对于4节点的集群(HDS N系列),最少只需要一个Storage Pool就够了。

在一个Pool中,包含各类业务的文件系统,没有做进一步区分。

第二种方案的Storage Pool划分依据,是业务数量。有4种业务,就划分4个Storage Pool。我们可以看到,业务A_1和业务A_2这两个同类文件系统合体了。

3.3 方案对比

两种方案主要在资源利用率性能变更灵活度上有差异。

我们知道,在NAS配置阶段,LUN是资源分配的最小颗粒,且具备分配后不可回收的特点。

假设现在每个LUN都为1T,经计算,业务A需要7.2T空间、业务B需要3.4T空间。按第二种方案的思路,需要分配 8 + 4 = 12个LUN。按第一种思路,A加B合起来只需要10.6T,分配11个LUN就够了。

可见,Storage Pool划分得越多,空间浪费就会越多。同时,每个Storage Pool的LUN的数量变少,性能也会下降。

但是,它的好处是应变能力强。举个例子,假设现在NAS1、2集群的计算性能出现了瓶颈,而NAS3、4集群性能还有富余。

按第一种方案,A、B、C三种业务若继续保持绑定状态,将Storage Pool1 切换到NAS3、4集群肯定是承载不住的(项目建设时采购的配置一般相当),只能紧急采购更高性能的NAS机头更换。

或者对其中部分文件系统做迁移,而这又要求有可用空间。

显然,都比较麻烦和被动。

而按第二种方案,我们可以将其中部分业务变更映射关系,比如单独将Storage Pool B从NAS1、2集群断开,重新映射给NAS3、4集群。这样做不麻烦,而有可能取得比较理想的效果,比如:3和4的负载上升,但还能承受;1和2压力降低,卡顿情况有所缓解。没准就解决了燃眉之急,为后续方案争取到了时间。

所以,化整为零,可以是我们应对风险留的一手。

4 总结

对新建项目、存储划分很关键,因为一旦Storage Pool定了就不能更改,除非整体更换存储。最关键的就是在方案一和方案二之中做选择或者两者叠加。需要充分平衡空间、性能、灵活性这3个因素,如有类似项目经验参考会比较有优势。

本文举的例子是理想情况,实际空间会有差异,比如5D+1P的Raid5磁盘组的实际可用容量,就达不到5块硬盘裸容量之和。其次,LUN的划分方案、Storage Pool的划分,都会影响到最终业务可用的文件系统的容量,同时还有快照、操作系统占用等技术也会消耗空间。这些因素在项目检讨之初就最好纳入考虑。

如果没有条件做细致检讨,最低限度也是要预留一定比例的Buffer。如果业务需要用100T,规格书中也只要求存储提供100T的可用容量,最后出来的结果一定会少于预期。因为和电动车的续航里程一样,可用容量是在特定条件、配置下得出的,而这个条件未必符合你的实际。

此条目发表在IT技术分类目录,贴了标签。将固定链接加入收藏夹。

发表评论

您的电子邮箱地址不会被公开。 必填项已用*标注