比较各个存储类型的优缺点？

名称节点是hdfs集群的主服务器是用来存放元数据的。名称节点主要以元数据的形式进行管理和存储，用于维护文件系统名称并管理客户端对文件的访问，名称节点记录对文件系统名称空间或其属性的任何更改 *** 作，HDFS负责整个数据集群的管理，并且在配置文件中可以设置备份数量，这些信息都由名称节点存储。

Ceph是专为在商品硬件上运行而设计的，这使得构建和维护超大规模的数据集群在经济上是可行的。当规划出你的集群硬件时，你需要平衡一些考虑因素，包括故障域和潜在的性能问题。硬件规划应该包括将Ceph守护进程和其他使用Ceph的进程分布在许多主机上。一般来说，我们 建议在为该类型的守护进程配置的主机上运行特定的Ceph守护进程。我们建议使用其他主机来处理使用您的数据集群的进程（例如OpenStack、CloudStack）

Ceph元数据服务器会动态地重新分配负载，这对CPU来说是很有必要的。所以你的元数据处理器应该有相当大的处理能力（四核心或更高的CPU）。Ceph OSDs 运行RADOS服务，用CRUSH计算数据放置、复制数据，并维护自己的集群地图副本。因此，OSD应该有合理的处理能力（例如双核处理器）。监视器只是维护集群映射的主副本，所以监视器不需要CPU密集型的处理能力。

除了Ceph守护进程之外，你还必须考虑主机是否会运行CPU密集型进程，例如，如果您的主机将运行计算虚拟机（例如，OpenStack Nova)，您需要确保这些其他进程为Ceph守护进程留下足够的处理能力。我们建议在单独的主机上运行额外的CPU密集型进程。

一般来说，RAM越多越好

监视器和管理器守护进程的内存使用量一般会随着集群的大小而变化。

对于小型集群，一般来说，1-2GB就足够了。

对于大型集群，你应该提供更多（5-10GB）。

你可能还需要考虑调整设置，如mon_osd_cache_size或 rocksdb_cache_size

Bluestore使用自己的内存来缓存数据，而不是依赖 *** 作系统的页面缓存。在BlueStore中，你可以通过osd_memory_target选项调整OSD_memory_target的内存量

•通常不建议将osd_memory_target设置为2GB以下，可能会将内存保持在2GB以下，同时也可能导致性能极慢。•将内存目标设置在2Gb和4Gb之间通常有效，但可能会导致性能下降，因为元数据可能在IO期间从磁盘读取，除非活动数据集相对较小。•4GB是目前默认的osd_memory_target大小，这样设置的目的是为了平衡内存需求和OSD的性能，以满足典型的使用情况•设置osd_memory_target高于4GB时，当有许多（小的）或大的（256GB/OSD)数据集被处理时，可能会提高性能。

重要：

OSD的内存自动调整是“尽力而为”。虽然OSD可能会解除内存映射，让内核回收内存，但不能保证内核会在任何特定的时间框架内实际回收释放的内存。这在旧版本的Ceph中尤其如此，因为透明的巨页会阻止内核从碎片化的巨页中回收内存。现代版本的Ceph在应用级禁用透明巨页以避免这种情况，但这仍然不能保证内核会立即回收未映射的内存。OSD有时仍然可能会超过它的内存目标。我们建议在系统中保留20%左右的额外内存，以防止OSD在临时高峰期或由于内核延迟回收空闲页而导致的OSD出现OOM。这个值可能会比需要的多或少取决于系统的具体配置。

在使用传统的FileStore后端时，页面缓存是用来缓存数据的，所以一般不需要调优，OSD的内存消耗一般与系统中每个守护进程的PG数量有关

仔细规划你的数据存储配置。在规划数据存储时，需要考虑重大的成本和性能权衡。同时进行 *** 作系统 *** 作，以及多个守护进程对单个驱动器同时请求读取和写入 *** 作，会大大降低性能。

重要

由于Ceph在发送ACK之前必须先将所有数据写入日志（至少对XFS来说），所以日志和OSD的性能平衡真的很重要！在这里，Ceph的日志和OSD的性能是非常重要的。

OSD应该有足够的硬盘空间来存放对象数据。我们建议硬盘驱动器的最小容量为1T。考虑到较大磁盘的每GB的成本优势。我们建议将硬盘驱动器的价格除以千兆字节，得出每千兆字节的成本，因为较大的驱动器可能会对每千兆字节的成本有很大影响。例如，价格为75美元的1T硬盘，每千兆字节的成本为007美元。相比之下，价格为150美元的3T硬盘的成本为每千兆字节005美元。在上述例子中，使用1T硬盘通常会使每千兆字节的成本增加40%——使集群的成本效益大大降低。

Tips: 在一个磁盘上运行多个OSD，无论分区如何，都不是一个好主意

Tips: 在单一磁盘上运行OSD和显示器或者元数据服务器，无论分区如何，都不是一个好主意

存储驱动器在寻求时间、访问时间、读取和写入时间以及总吞吐量方面受到限制。这些物理限制会影响整体系统性能，特别是在恢复期间。我们建议为 *** 作系统和软件使用一个专门驱动器，并且您在主机上运行的每个Ceph OSD daemon使用一个驱动器。大多数“慢OSD”问题的出现是由于在同一个驱动器上运行一个 *** 作系统，多个OSD，或多个日志。由于在一个小型集群上排除性能问题的成本超过了额外的磁盘驱动器的成本，因此您可以通过避免过度消耗OSD存储驱动器的诱惑来优化您的集群设计规划。

您可以在每个硬盘驱动器上运行多个Ceph OSD Daemons，但这可能会导致资源征用，降低整体吞吐量。你可以在同一硬盘上存储日志和对象数据，但这可能会增加写日志和ACK到客户端所需要的时间。Ceph必须先写入到日志，然后再进行ACK写入。

ack写入：完成此类写入之后，将向客户端发送一个成功写入的ACK，所以称之为ACK写入

Ceph最佳实践规定，你应该在不同的驱动器上运行 *** 作系统、OSD数据和OSD日志

提高性能的一个机会是使用固态硬盘来减少随机访问时间和读取延迟，同时加快吞吐量。与机械硬盘相比，固态硬盘每千兆字节的成本往往超过10倍以上，但固态硬盘的访问时间往往比机械硬盘至少快100倍。

固态硬盘没有活动的机械部件，所以他们不一定会受到与机械硬盘相同的限制。但固态硬盘确实有很大的局限性。在评估固态硬盘时，重要的是考虑顺序读取和写入的性能。当为多个OSD存储多个日志时，具有400MB/S顺序写入吞吐量的SSD可能比具有120MB/s顺序写入吞吐量的SSD性能要好的多。

重要

我们建议探索使用固态硬盘来提高性能。然而，在对SSD进行重大投资之前，我们强烈建议在审查SSD的性能指标和测试配置中测试SSD的性能

由于固态硬盘没有活动的机械部件，所以在Ceph中不需要使用大量存储空间的区域（如日志）使用固态硬盘是很有意义的。相对便宜的SSD可能会吸引你的经济意识。请谨慎使用。在选择使用Ceph的SSD时，仅有可接受的IOPS是不够的。日志和SSD有几个重要的性能注意事项：

•写入密集型语义：日志涉及到写密集型语义，因此您应该确保您选择部署的SSD在写入数据时的性能相当于或优于机械硬盘。廉价的固态硬盘在加速访问时间的同时，可能会引入写入延时，因为有时高性能硬盘的写入速度会比市场上一些更经济的固态硬盘快，因此，您应该确保您选择的固态硬盘在写入数据时的性能与机械硬盘相当或更好。•顺序写入：当您在SSD上存储多个日志时，您必须考虑到SSD的顺序写入限制，因为它们可能会同时处理对多个OSD日志的写入请求。•分区对齐：SSD性能的一个常见问题是，人们喜欢将硬盘分区作为最佳做法，但往往忽略了对SSD的正确分区对齐，这样会导致SSD的数据传输速度更慢。确保SSD分区正确对齐

虽然固态硬盘对于对象存储的成本较高，但通过将OSD的日志存储在固态硬盘上，并将OSD的对象存储存储在独立的机械硬盘上，可能会看到性能的显著提升。osd journal配置设置默认为/var/lib/ceph/osd/$cluster-id/journal。您可以将此路径挂载到SSD或者SSD分区，使其不只是与对象数据存储在同一硬盘上。

Ceph加速CephFS文件系统性能的一种方法是将CephFS元数据的存储与CephFS文件内容的存储隔离开来。Ceph为CephFS元数据提供了一个默认的元数据池。你永远不必为CephFS元数据创建一个池，但你可以为你的CephFS元数据池创建一个只指向主机的SSD存储介质的CRUSH映射层次结构。详情请参见将池映射到不同类型的OSDs。

•意思是可以将一个池的所有数据都存储到SSD类型的OSD

磁盘控制器对写入吞吐量也有很大影响。在选择磁盘控制器时要慎重考虑，确保不会造成性能瓶颈。

Tips：Ceph博客通常是对Ceph性能问题的一个很好的信息来源。更多详情请参加Ceph写吞吐量1和Ceph写吞吐量2

•>任何ORM的解决方案都应该提供一种易读的、容易编辑的映射文件格式，而不仅仅提供一个GUI图形工具。当下流行的对象/关系元数据格式都支持XML。使用XML格式的文件可以提供如下好处：首先它是轻量级的，提供很好的易读性，能够进行版本控制，可以在部署阶段定制。
但是XML格式文件真的是最好的选择吗？Java社团中就反对XML文件中使用了过多的反斜线。每个框架和服务器都需要使用其特定的XML描述符。
在我们看来，使用反斜线有三个主要的原因：
许多现存的元数据可读性和可编辑性都很差，究其原因就是缺乏对于属性元素默认值的支持。
元数据为基础的解决方案经常被滥用。元数据并不比Java代码更容易维护，过多的元数据会造成混乱。
一般的XML编辑器，尤其是那些IDE提供的，其编辑的质量远远比不上对于Java代码的支持。更糟糕的是，很多情况下这样的XML并不提供DTD，这样就无法进行验证。另外一个问题就是DTD的定义太通用了，以至于不会起到实际的作用。
然而，并不能就这样忽略ORM对于基于文本的元数据的使用需求。Hibernate就充分到了元数据的这些问题。其定义的元数据提供了很好的可读性以及默认值。当没有配置属性值的时候，Hibernate会利用反射机制找到类来完成默认值的配置。Hibernate还提供了完成的DTD。最新的IDE都已经更好的支持XML文件的编辑，包括动态的校验甚至包括自动完成配置的功能。如果这些仍然无法满足你的要求，那么我们将在第九章介绍一些工具来生成Hibernate映射文件。
让我们来看一下Hibernate中的映射文件。我们之前创建了Category类，现在需要把它映射到CATEGORY表中。为了完成这个配置，我们使用了列表34中的映射文件。
(1)每个Hibernate映射文件都应该声明DTD，它用来验证XML的语法是否正确。
(2)所有映射配置都放在<hibernate-mapping>元素之间，你可以随意配置的类，至于其他的配置我们将在后面说明。
(3)类category映射到CATEGORY表。表中的每一行都代表了Category的一个实例。
(4)至今为止我们并没有讨论对象标识的概念，所以你可能会对这种映射方式感到奇怪。这个主题将在34中讨论。为了理解这个问题，你必须知道CATEGORY表中的每一条记录都会有一个主键来对应内存中的对象的实例。<id>属性就是用来定义对象标识的。
(5)属性type映射到数据库的name列。需要注意的是type使用的是Hibernate内置的String类型，而不是java的类型或者数据库的类型。你可以把它理解为映射类型。这些都将在第六章的61中讨论。
我们有意的在这里不提到关于关联的映射。关联的映射更加复杂，将在37节中进行讨论。
尽管在同一份映射文件中可以声明多个映射类，但是实践经验告诉我们最好每一个类对应一个单独的映射文件。而文件的命令和类保持一致，例如在本例中可以把文件保存为Categoryhbmxml。

---