块存储的优点不言而喻：
1. 使用了Raid与LVM等手段，可以多数据做冗余保护;
2. 可以使用磁盘阵列，组成大容量的逻辑盘对外提供服务，提高容量;
3. 对逻辑盘写数据可转化为对几块物理磁盘的并行写入，提升了读写效率。
需求
在IaaS中，块存储被广泛应用于为虚拟机提供持久卷。虚拟机故障后依然能够通过在其他虚拟机上挂载旧数据卷的方式来访问磁盘数据，因此被普遍认可。受此影响，一些客户在设计PaaS时，自然而然的联想到共享存储的这一优势，提出在PaaS中为容器挂载块存储的需求。
但是，凭借在IaaS中的卓越表现，块存储也能够跻身PaaS业务中吗?
分析
假设已有一套可提供RBD块存储的Ceph集群的前提下，我们先来分析几个场景：
场景一
“我使用容器技术，但还不是深度用户，只使用docker run之类的命令来手工启动单个容器，这些容器中运行的服务都比较消耗磁盘空间。”
这类用户局限于将容器作为一个临时工具，并没有将其与业务紧密结合。
1. 如果对磁盘没有持久化的需求，那么在主机磁盘空间空余足够的情况下可以考虑直接映射宿主机文件系统。
2. 若想让磁盘独占共享磁盘，或希望在不同宿主机上启用容器时，均能重复使用之前访问过的数据卷;此时可以在启动docker时，指定volume-driver为ceph-rbd的方式来使用由Ceph集群提供的块存储。
块存储驱动框架图如下所示：
场景二
“我使用容器编排工具来管理应用，比如docker-compose、Rancher或Kubernetes。但我在每一个service下只需要启用一个container，且对service没有扩容的需求;这些service都比较消耗磁盘，我希望在容器被重启或重新调度后，仍可使用旧的数据盘。”
该场景比较特殊，每一个service只对应一个container。因此，不会有多个container同时读写一块数据盘的需求，只需保障container之前所挂载的存储卷在container故障恢复或正常迁移后依然能够被container访问即可;即存储卷对容器的自动跟随。
迁移场景如下图所示：
但是，值得注意的是：
1. 假设之前的container运行在host-1上，对应的，块存储就挂载在host-1上。
2. 当原有container因故被调度到新的host-2上时，编排框架检测到该变化，将host-1上的原有块设备卸载，然后挂载到host-2。
3. 按照该流程，块存储的每一次迁移都需要从一台主机上卸载，再到另外一台主机上挂载;新container的启动依赖于volume，因此容器或者业务的恢复速度依赖于块存储的迁移速度。
4. 假设平台未能及时检测到host-1上的container故障、旧有的container卡死无法快速销毁，或者host-1突然断电时，Ceph Server必须等待超时后，才允许host-2重新挂载之前被使用的RBD块。此时，container启动时间就会变得难以忍受，显然这是与容器的秒起秒停的优势相互违背的。
场景三
我使用Rancher或者Kubernetes之类的容器编排软件来管理应用，每一个应用有多个微服务;每一个微服务又对应多个容器来并行对外提供服务。
Rancher
在Rancher里面，应用被称之为Stack，每一个stack包含一到多个service; service即微服务，微服务之间按照单一职责划分，只做一件事情。service属于逻辑的概念，真正做事的是各service对应的containers。如果希望通过为service扩容，就增加service对应的container数量;这些container无状态，可被调度到多台宿主机上，它们必须使用共享存储来保障业务的持续性。
Kubernetes
在Kubernetes中，业务也是由一到多个service来共同完成的，这里的service与Rancher中service的概览类似。Kubernetes的service是一个外部访问点(endpoint)，通过selector指定labels的方式可以选定一组pods，service为这组pods提供访问代理和负载均衡。外部的客户端只需知道service所暴露的端口和IP就能够访问到业务。由于pod是无状态的，因此同Rancher一样，也需要将业务数据存储到共享存储上，还必须保障同一个service对应的多个pods均能共享该业务数据。
限于块存储只能同时被一个客户端(主机)所挂载，当service的多个containers或pods调度到多台主机上时，块存储就难以应付了。此时，原始共享文件系统的方法又体现出了它的优势，NAS会是一个最好的选择!
京公网安备 11010502049343号