OpenStack Operations Guide 第六章 Storage Decisions

lakers009

　　本章节主要聚焦于persistent storage，理解ephemeral storage和persistent storage的区别是非常重要的。
　　6.1 Ephemeral Storage
　　6.2 Persisitent Storage
　　     6.2.1 Object Storage
　　     6.2.2 Block Storage
　　6.3 OpenStack Storage Concepts
　　6.4 Choosing Storage Backends
　　     6.4.1 OpenStack Object Storage (swift)
　　     6.4.2 Ceph
　　     6.4.3 Gluster
　　     6.4.4 LVM
　　     6.4.5 ZFS
　　

　　6.1 Ephemeral Storage
　　如果你只部署了openstack的compute服务，你的用户默认是没有持久存储的。分配给虚拟机的磁盘默认是临时的，这意味着当虚拟机终止后空间就会被释放。
　　6.2 Persisitent Storage
　　持久性存储意味着你的存储资源永远可用，无论你的实例是否运行。
　　OpenStack现在只支持两种类型的持续存储，对象存储与块存储。
　　6.2.1 Object Storage
　　在对象存储中，用户通过REST API来访问一个二进制对象。你也许对Amazon S3非常熟悉，它是一个非常有名的对象存储例子。在OpenStack中，对象存储代号Swift。如果你的用户希望拥有大量的数据存储，对象存储非常合适。还有，OpenStack也可以把你的虚拟机镜像存储在对象存储系统中。
　　OpenStack对象存储提供了一个可扩展，高可用的存储解决方案。在设计这样一个对象存储集群的方案前，需要了解一些基本概念。遇到故障时，其他存储系统可能会需要拆下RAID卡，甚至整个服务器，但OpenStack对象存储完美的解决了这一问题。
　　这是一篇介绍对象存储架构的文档，http://docs.openstack.org/developer/swift/overview_architecture.html。先读一读把。一旦你了解整个架构后你应该知道proxy server是什么，zone是怎么工作的。
　　当你设计集群时，你必须先考虑耐久性和可用性。要了解这些主要是看你数据，而不是硬件的可靠性。首先，考虑副本数量，默认是3个。这意味着在一个对象被标记为已写入前，至少有两个副本已经存在，以防这台服务器发生故障没有写入。下一步，考虑你的服务器的zone，是一个rack，一个服务器，还是一个磁盘？
　　对象存储的网络参数一开始看起来可能不太熟悉，
　　Among object,container,account servers
　　Between those servers and the proxies
　　Between the proxies and your users
　　对象存储可是非常“健谈”的，甚至在很小的集群中都会有MB/s的流量, 这些流量经常是：A你有这个对象么？B有！如果回答是没有或者超时，复制就会开始。加入有一台服务器24T容量，宕机之后这些数据需要立刻复制以保持3份副本，那么就会在网络上产生很大的负载。
　　还有一个容易被忽视的问题就是当一个新的文件被上传，代理服务器就必须写好几份数据。比如说一个三副本的集群，10Gbps的入口就意味着要有30Gbps的出口。结合上面的大流量复制问题，我们建议你的私有网络要比共有网络拥有更大的带宽。对了，OpenStack对象存储之间的流量是不加密也不认证的，当然这是为了性能考虑，所以你的私有网络要更私有才更安全。
　　Swift-proxy服务是无状态的，这意味着你可以轻易的添加更多代理服务器，使用HTTP负载均衡来平衡他们的带宽。更多的代理服务器就意味着更大的带宽。
　　6.2.2 Block Storage
块存储（有时候也称作卷存储）为用户提供了块级别的存储访问。用户可以分配卷给他们的实例。
　　这些volumes是持久性的，可以从一个实例分离或者重新挂载给另一个实例，数据仍是完整的。在OpenStack中项目名称叫做cinder。你选择的后端存储必须被块存储驱动支持。
　　大多数的块存储驱动允许实例能直接访问底层存储硬件的块设备，这增加了读写IO的性能。
　　早在Folsom版本中就实验性的利用文件系统模拟成块设备，在之后的Grizzly版本中扩展到完整的NFS驱动以及GlusterFS驱动。
　　这些驱动和传统的块存储驱动有些不同。在NFS或者GlusterFS文件系统中，我们会创建一个文件，作为一个虚拟机的卷映射给实例。这种映射/转换类似于OpenStack中QEMU的基于文件的虚拟机，这些虚拟机存储在/var/lib/nova/instances
　　6.3 OpenStack Storage Concepts
　　下表描述一些OpenStack存储的概念 文件级别的存储（for在线迁移）
　　使用文件级别的存储，用户可以使用操作系统文件系统的接口来存取数据，大多数用户可能已经有使用NAS的经验。在Unix的世界，最常用的就是NFS，而在Windows世界中就是CIFS（之前被叫做SMB）。
　　OpenStack在使用文件系统存储时并不直接面对最终用户。但是当你在设计你的云的时候，如果你想支持在线迁移功能，那么你就必须考虑把实例存储在/var/lib/nova/instances。
　　6.4 Choosing Storage Backends
　　在不同环境中用户的需求也不一样。有些人可能会需要快速访问一些不会经常改变的对象，或者给某些文件设置TTL。另一些可能只需要访问挂载给OS的文件系统。所以你需要考虑这些问题：
　　用户需要块存储么？
　　用户需要对象存储么?
　　需要支持在线迁移么？
　　持续存储直接包含在计算机点还是外部存储？
　　我需要多少磁盘，达到什么性能效果？
　　最佳性价比的解决方案？
　　如果高效的管理存储？
　　冗余和分布式怎么考虑，如果一个存储节点宕机怎么办？
　　你可以使用下表中的几个开源软件

　　

　　查看这个链接以获得更多信息：https://wiki.openstack.org/wiki/CinderSupportMatrix
　　下面我们详细介绍一下这些技术
　　6.4.1 OpenStack Object Storage (swift)
　　OpenStack官方的对象存储技术。Rackspace已经在生产环境中使用了好多年，是很成熟的技术。由于其高度可扩展的特性，swift能轻松扩展到PB级别。它的优势就是与OpenStack高度的集成（与keystone集成，在horizon中可管理），同时支持多数据中心的异步复制，甚至连续复制。
　　如果你计划把你的存储集群分布在几个数据中心，或者你需要统一的账户管理，或者在OpenStack的dashboard中控制你的存储，swift是个不错的选择。
　　6.4.2 Ceph
　　Ceph是一个可扩展的存储解决方案，允许数据跨节点复制。Ceph的设计就是为了提供融合存储接口：支持对象存储，块存储，文件系统接口，虽然文件系统的接口还没有最终就绪。Ceph支持和swift一样的对象存储API，同时也可以为cinder提供块存储，它通过copy-on-write技术来提供精简配置功能。Ceph还支持keystone认证（版本0.56）。
　　Ceph的优势是它能让管理员更粒度的控制数据分布和复制策略，整合块存储与对象存储，使用精简配置允许你快速提供系统启动卷（fast boot-from-volume），支持分布式文件系统接口，虽然这个接口还暂时不推荐在生产环境中部署。
　　如果你想在一个系统中管理对象存储和块存储，或者支持快速系统启动卷（fast boot-from-volume），你应该考虑Ceph。
　　6.4.3 Gluster
　　Gluster是一个分布式的共享文件系统。在Gluster3.3版本你可以把对象存储和文件存储整合到一个解决方案，叫做GFO，Gluster for OpenStack。GFO用了一个定制版本的swift得以允许Gluster被当作后端存储。使用GFO代替swift的你能获得一个分布式文件系统，为在线迁移提供共享存储。
　　6.4.4 LVM
　　LVM是逻辑卷管理器的简称，在Linux的磁盘与文件系统之间提供了一个抽象层。LVM并不提供任何复制功能。通常管理员使用RAID来提供磁盘的高可用，但是并不能在服务器宕机后提供保护。
　　6.4.5 ZFS
　　ZFS是一个文件系统，该系统中包含了卷管理功能。不像其他Linux系统拥有一个单独的卷管理器（LVM），ZFS比EXT4拥有很多优点，包括改进的数据完整性校验。支持OpenStack的ZFS后端存储只支持基于Solaris的系统，如illumos。虽然有Linux支持ZFS，但是这些并没有经过OpenStack的测试。正如LVM，ZFS也不提供跨主机的复制（Nexenta企业版支持跨主机/数据中心的异步复制与双节点的HA）。