做VDI项目，数据存储是必要的。选择传统的SAN和NAS存储无疑是最稳妥的一种选择。
非存储专业的技术人员，对企业存储需要懂多少？其实只要略懂就可以了。
本文以HDS品牌为题材书写，包含两部分内容：一是介绍HDS的NAS提供流程（硬件网关型）并提炼技术要点，二是介绍了两种不同的Storage Pool划分思路。
1 从SAN硬盘到NAS服务
上图描述了HDS的NAS设备（外置Hnas网关或内置NAS module）使用HDS的SAN存储来提供NAS服务的过程。
- 物理磁盘层。物理硬盘组成Raid组，部分硬盘成为热备盘（Hot Spare）。
- DP Pool（Dynamic Provisioning Pool）。多个Raid组虚拟组成一个DP Pool。
- 在DP Pool中，划分出若干LUN。
- NAS设备识别到上一步中的LUN（通过SAN网络或直连SAN存储）。在NAS设备上操作，将这些LUN划分到不同的Storage Pool中。多个LUN虚拟化成一个Storage Pool。
- 在一个Storage Pool中可建立多个文件系统（File System），比如NFS文件系统或者CIFS。
- 对每个文件系统建立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的设计。常见有以下两种设计方案。
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的可用容量，最后出来的结果一定会少于预期。因为和电动车的续航里程一样，可用容量是在特定条件、配置下得出的，而这个条件未必符合你的实际。
