1.3 Ceph和存储的未来
企业存储需求最近几年暴发性增长。研究表明，大企业的数据年增长率为40%～60%，而且许多公司的数据占用空间每年翻一番。IDC分析师估计2000年全世界数据量大约是54.4EB。2007年这个数字达到295EB，而到2014年年底，预计会达到8591EB。
所有存储系统的要求都是统一、分布式、可靠、高性能，最重要的是，能够大规模扩展至艾字节，甚至更高级别。Ceph存储系统是一个真正的解决方案，它可以应对这个星球上爆炸式增长的数据。Ceph能够闪电式兴起的原因在于它活跃的社区以及用户真正相信Ceph的能力。数据的生成是一个永无止境的过程。我们无法停止数据的生成，但我们需要缩小数据生成和数据存储之间的差距。
Ceph刚好合适用于缩小这个差距；其统一、分布式、高性价比和可扩展的特性使它成为满足今天和将来数据存储需求的潜在解决方案。开源Linux社区2008年就预见到Ceph的潜力，并将其加入Linux内核主线。这已经成为Ceph的里程碑事件，因为至今还没有其他竞争对手能够加入。
1.3.1 Ceph云存储解决方案
在云基础设施开发中问题最多的领域就是存储。云环境要求其存储能够以低成本纵向和横向扩展，而且能够容易与云框架中其他组件集成。这样的存储系统需求是决定整个云项目总体成本（TCO）的一个重要方面。几个传统的存储供应商声称能够提供跟云框架集成的功能，但如今我们需要更多的特性，而不仅仅是支持集成。传统的存储解决方案或许在前几年成功地证明了自己，但现在它们并不是一个好的统一云存储解决方案。同时，传统存储系统部署和长期运行的成本太高，而且纵向扩展和横向扩展是它们的弱项。今天，我们需要一个完全重新定义的存储解决方案来满足当前以及未来的需要，这个系统建立在开源软件以及商用硬件之上，能够以经济高效的方式提供我们所需要的扩展性。
Ceph已经在快速演变以缩小与真正云存储后端的差距。它通过与OpenStack、CloudStack和OpenNebula等每一个主流开源云平台结合，使得自己保持在云时代舞台的中央。除此之外，Ceph已经与Canonical、Red Hat和SUSE这些Linux领域的巨人建立了伙伴关系。这些公司投入更多的时间来将Ceph这个分布式、可靠、可扩展的存储集群集成到它们的Linux和云软件发行版中。Ceph与这些Linux巨人紧密配合，给它们的云平台提供可靠的多功能存储后端。
OpenStack项目大力推动了公有云和私有云的发展。它已经证明了自己是一个端到端云解决方案。它自己的内部核心存储组件Swift提供基于对象的存储和Nova-Volume（也称为Cinder），而Cinder则为VM提供块存储。
与Swift（它仅提供对象存储）不同，Ceph是一个包含块存储、文件存储和对象存储的统一存储解决方案，这样可以通过单一存储集群为OpenStack提供多种存储类型。因此，你可以轻松而高效地为OpenStack云管理存储。OpenStack和Ceph社区已经一起合作了许多年，致力于为OpenStack云开发一个完全支持的Ceph存储后端。从Folsom（OpenStack第6个主要版本）开始，Ceph已经完全与OpenStack集成。Ceph开发人员确保Ceph能够适用于OpenStack的最新版，同时贡献新特性以及修正bug。OpenStack通过它的cinder和glance组件使用Ceph最苛刻的特性RADOS块设备（RBD）。Ceph RBD通过提供精简配置的快照复制（snapshotted-cloned）卷帮助OpenStack快速配置数百个VM实例，这种方式既减少空间需求，又非常快速。
云平台使用Ceph作为存储后端，在服务提供商建立SaaS和IaaS解决方案的过程中可以为其提供很多必要的便利性。这是传统企业级存储解决方案所不能提供的，因为它们并不是为了满足云需求而设计的。使用Ceph作为云平台存储后端，云服务提供商可以为它的客户提供低成本的云服务。相对Amazon等其他存储提供商而言，Ceph使得云服务提供商能够提供相对低价的企业存储。
Dell、SUSE和Canonical为它们的OpenStack云解决方案提供并支持Ceph部署和配置管理工具，例如Dell Crowbar和Juju可以容易地自动部署Ceph存储。其他的配置管理工具（例如Puppet、Chef、SaltStack和Ansible）都是很流行的Ceph自动部署工具。这些工具都有自己开源成熟的Ceph模块，这些模块很容易用来部署Ceph。在例如云这样的分布式的环境中，每一个组件都必须能够扩展。这些管理工具是快速扩展你的基础设施的基本工具。如今，Ceph与这些工具完全兼容，允许用户瞬间部署和扩展Ceph集群。
从OpenStack Folsom版本开始，nova-volume组件变成了cinder；然而，nava-volume命令在OpenStack中仍然可用。
1.3.2 Ceph软件定义存储解决方案
所有想在存储基础设施上省钱的用户最有可能很快就考虑采用软件定义存储（SDS）。SDS可以为在传统存储上有大投入但仍然没有获得必要的灵活性和扩展性的用户提供一个很好的解决方案。Ceph是一个真正的SDS解决方案，它是开源软件，运行在商用硬件上，因此不存在厂商锁定，并且能提供低成本存储。SDS方案提供了客户急需的硬件选择的灵活性。客户可以根据自身的需要选择任意制造商的商用硬件，并自由地设计异构的硬件解决方案。在此硬件解决方案之上的Ceph的软件定义存储可以很好地工作。它可以从软件层面正确提供所有的企业级存储特性。低成本、可靠性、可扩展性是Ceph的主要特点。
1.3.3 Cehp统一存储解决方案
从存储厂商的角度来看，统一存储的定义就是在单一的平台上同时提供基于文件和基于块的访问。企业存储环境在单一平台提供NAS与SAN，这就可以认为是一个统一存储解决方案了。在20世纪90年代末至21世纪20年代初已经证明NAS和SAN技术是成功的。但如果我们考虑将来，我们能确保NAS和SAN能够在接下来的50年中管理存储？它们有足够的潜力处理几艾字节的数据？恐怕不能。
在Ceph中，统一存储这个词涵盖的功能比现有的存储厂商所声称的更多。Ceph从一开始设计就是面向为未来的。它的构建块在设计时就考虑能够处理大量的数据。Ceph是一个真正的统一存储解决方案，它从单一统一软件层提供对象、块和文件存储。当我们说Ceph是面向未来的存储时，更多地指的是它的对象存储能力。对象存储比块或者文件存储更适合如今混合的非结构化数据。在Ceph中，无论是块存储还是文件存储，都依赖于智能对象。
Ceph底层中并不存在块和文件的管理，而是管理对象并且在对象之上支持基于块和文件的存储。在传统基于文件的存储系统中，文件是通过文件目录进行寻址的。类似地，Ceph中的对象通过唯一的标识符进行寻址，并存储在一个扁平的寻址空间中。剔除了元数据操作之后，对象提供了无限的规模扩展和性能提升。Ceph通过一个算法来动态计算存储和获取某个对象的位置。
1.3.4 下一代架构
传统的存储系统并不具备更智能地管理元数据的方法。元数据是关于数据的信息，它决定了数据将往哪里存储，从哪里读取。传统的存储系统通过维护一张集中的查找表来跟踪它们的元数据。也就是说，客户端每次发出读写操作请求时，存储系统首先要查找这个巨大的元数据表，得到结果之后它才能执行客户端请求的操作。对于一个小的存储系统而言，你或许不会感觉到性能问题，但对于一个大的存储集群来说，你将会受制于这种方法的性能限制。它也会限制系统的扩展性。
Ceph没有采用传统的存储架构，而是用下一代架构完全重塑了它。Ceph引入了一个叫CRUSH的新算法，而不是保存和操纵元数据。CRUSH是Controlled Replication Under Scalable Hashing的缩写。更多信息请访问http://ceph.com/resources/publications/。 CRUSH算法在后台计算数据存储和读取的位置，而不是为每个客户端请求执行元数据表的查找。通过动态计算元数据，Ceph也就不需要管理一个集中式的元数据表。现代计算机计算速度极快，能够非常快地完成CRUSH查找。另外，利用分布式存储的功能可以将一个小的计算负载分布到集群中的多个节点。CRUSH清晰的元数据管理方法比传统存储系统的更好。
除此之外，CRUSH还有一个独特的基础设施感知能力。它能了解基础设施中不同组件之间的关系，从最初的系统磁盘、池、节点、机架、电源插板、交换机到现在的数据中心，以及数据中心房间等。这些都是任何基础设施中的故障区域。CRUSH会以多副本的方式保存数据，以保证在故障区域中有些组件故障的情况下数据依旧可用。用户在Ceph的CRUSH map中可以自由地为他们的基础设施定义故障区域。这也就使得Ceph管理员能够在自己的环境中高效地管理他们的数据。
CRUSH使得Ceph能够自我管理和自我疗愈。当故障区域中的组件故障时，CRUSH能够感知哪个组件故障了，并确定其对集群的影响。无须管理员的任何干预，CRUSH就会进行自我管理和自我疗愈，为因故障而丢失的据数执行恢复操作。CRUSH根据集群中维护的其他副本来重新生成丢失的数据。在任何时候，集群数据都会有多个副本分布在集群中。
使用CRUSH，我们能够设计一个没有单点故障的高度可靠的存储基础设施。它也使得Ceph成为一个面向为来的高度可扩展和可靠的存储系统。
1.3.5 Raid时代的终结
Raid技术许多年来都是存储系统的基础。对于近30年来所生成的几乎每一种数据类型而言，Raid技术都被证明是成功的。然而，所有的时代都会有终结的时候，这一次轮到了RAID。基于RAID的存储系统已经开始显露出其局限性，而且不能满足未来的存储需求。
磁盘制造技术这些年越来越成熟。制造商如今能够以更低的价格生产更大容量的企业级硬盘。我们不再提450GB、600GB甚至1TB的磁盘，因为现在有很多容量更大、性能更好的选择。较新的企业级磁盘规格可以达到4TB甚至6TB。磁盘的存储容量将会每年持续增长。
想象一下由众多4TB或者6TB磁盘组成的基于RAID的企业级存储系统；如果磁盘故障，RAID将需要花费几小时甚至几天的时间来修复单个故障的磁盘。与此同时，如果其他的磁盘也故障了，那将会导致混乱。使用RAID技术修复多个大硬盘是一个很繁琐的过程。
另外，RAID需要很多整块的磁盘来充当备用盘。这也会影响到TCO，如果你不配置备用盘，将会将会遇到麻烦。RAID机制要求在同一个RAID组中的磁盘必须完全相同。如果你改动了磁盘容量、转速和磁盘类型，则你可能要面临惩罚。这样做将会对于存储系统的容量和性能产生不利影响。
基于RAID的企业级存储系统通常都需要昂贵的硬件RAID卡，这也增加了系统总成本。当达到某个极限之后，RAID卡会进入一个死胡同，也就是它不能纵向或者横向扩展了。尽管你不差钱，此时你也不能再为存储系统增加任何容量。RAID5可以容忍一个磁盘故障，而RAID6可以容忍两个磁盘故障，这已经是RAID系统最大的容忍度了。在RAID数据恢复的过程中，客户端基本无法执行任何I/O操作。RAID系统最大的限制因素是它只能防止磁盘故障，而不能为网络、服务器硬件、OS、交换设备的故障或者区域灾害提供保护措施。RAID最多能为你提供防止两个磁盘故障的措施。在任何情况下你无法容忍超过两个的磁盘故障。
因此，我们需要一个能够克服所有这些缺点并兼顾性价比的系统。Ceph存储系统是当今处理这些问题的最佳选择。对于数据可靠性，Ceph采用数据副本方式。也就是不使用RAID，因此它能够简单地克服在基于RAID的企业级存储系统上出现的所有问题。Cpeh是一个软件定义的存储，因此它不需要任何特殊硬件来提供数据副本功能。另外，数据副本级别可以通过命令高度定制化。这也就意味着Ceph存储管理员能够轻松地根据自身需要和底层基础设施特点来管理副本策略。在一个或者多个磁盘故障的情况下，Ceph的副本处理方式比RAID的处理方式更好。当磁盘故障时，该磁盘上所有的数据马上开始从对等磁盘上进行恢复。因为Ceph是分布式系统，所以数据恢复时所有的初始副本和复制副本可以分布到集群中所有的磁盘上，使得不会有初始副本和复制副本位于同一个磁盘的情况，并且它们必须驻留在CRUSH map中定义的不同故障区域中。因此，所有的磁盘都参与数据恢复。这使得恢复操作非常快，并且不存在性能瓶颈。这样的恢复操作不需要任何热备磁盘；数据只是简单地复制到Ceph集群中其他的磁盘上。Ceph采用加权机制选择磁盘，因此不同容量的磁盘不会造成问题。Ceph存储根据磁盘权重存储数据，这个权重分配可以由Ceph自行管理，也可以通过自定义CRUSH map管理。
除了数据副本方法外，Ceph还支持其他用于保证数据可靠性的方法，比如纠删码技术。在提供同样级别可靠性的情况下，纠删码方式比副本方式更加节省存储空间。纠删码方式下，毁损的数据借助纠删码计算通过算法进行恢复或再次生成。可以在同一个Ceph集群的不同存储池中分别使用这两种数据恢复技术。我们将在后续的章节中进一步学习纠删码技术。
