OpenStack和Ceph的超融合架构快速入门

本文由Ceph中国社区-luokexue 翻译, Devin校稿。英文出处:Sébastien Han 欢迎加入CCTG

hyperconverged

因为一些小伙伴对超融合的概念还不是很熟,所以我先对超融合的基础架构做一个快速的介绍。

超融合… 是什么东东?

我喜欢把问题简单化,不需要考虑太复杂。超融合业已成为当前的热词之一,然而超融合背后的概念其实很简单,一个超融合节点说白了就是计算和存储部署在同一个服务器上,在软件定义网络和软件定义存储的世界里是允许我们这么做的,在本文的其他部分,我会用HCI来作为超融合架构的简称。

这种超融合的设计有很多优点:

  • (因为计算存储合一部署)我们在一个节点上就增加了更多的进程,通过这种方式增加了硬件的利用率,从而减少硬件的开销
  • 在进行数据读写时,用户也能通过(增加)本地命中来获得潜在的性能提升

容器技术助力超融合

需要注意的是,通常HCI是借助容器来实现的。显然,没有容器也是可以实现超融合的,但是在涉及到资源管控的时候,(比利用容器)会增加很多要求,如果不做这些资源管控,我们可能会遇到CPU及内存耗尽,进程间彼此干扰这样比较糟糕的情况。通常这种资源管控都是由内核管控组来完成的,比如CGroup。CGroup通常用于:(源自:维基百科:CGroups)

  • 资源限制 – 可以以组为单位配置包括文件系统缓存在内的内存上限
  • 优先级 – 一些组(通过配置优先级)可以得到更大可共享的处理器利用率或磁盘I/O吞吐量
  • 统计 – 统计一个组的资源使用情况,比如可以用在一些收费应用上
  • 控制 – 冻结进程组,(控制进程组)检查点和重新启动

所以对于机器上运行的每一个进程,都有创建一个对应的CGroup配置文件。在这个配置文件中,我们通过一些参数配置来限制进程的(资源利用)行为。所以从操作员角度,必须 手动 对每一个进程进行配置文件的设置。需要注意的是,在计算节点上,我们为OpenStack配置了4个CPU的(使用)上限,为每一个Ceph OSD配置了多个CPU。

随着容器的广泛使用,这些要求也逐渐消失,因为一切都是容器内置的,且都是由容器引擎提供的。当运行一个新的容器时,会自动(根据容器引擎的配置)生成一个CGroup配置文件,无需(额外的)配置。

资源精细化控制

刚才我们看到的是容器利用CGroup(在底层)可以帮助我们限制进程的资源消耗。可事情没那么简单,我们还没碰到像NUMA和CPU这类的钉子呢。说到KVM Hypervisior,在Nova中有一个选项可以用于限制Hypervisior本身对内存的使用:reserved_host_memory_mb。这个选项根据您自己的需求进行设置(取决于您的Hypervisior)。

NUMA在建立超融合环境中也是极其重要的(一个因素),理论上如果在你的节点上有两个Socket,每个Socket都能(通过NUMA)获得其独立的NUMA区域。而CPU资源是在Nova及实例模板中需要配置的一个部分,所以我们会预留一个Socket(的资源)给OpenStack的实例,另一个Sokcet(的资源)留给Ceph存储的守护进程。但这并不妨碍你给Socket设置一个指定的 cpu_allocation_ratio 值。在我们的超融合计算存储合一节点中,我们想要进行Ceph存储守护进程和虚拟机资源之间的隔离。

一图胜千言:

Node_in_depth

在上图中,每一个小格子都是一个容器,虚机也是。

在红帽峰会的展会上我已经介绍过超融合的相关知识,大家有兴趣的话也不妨去看看_^

点击即可下载Red Hat Summit PDF

Leave a Comment

电子邮件地址不会被公开。