容器适合的应用
笔者在IT行业从业十余年,有幸亲自经历到了IT基础架构的三个阶段和两次大的变革。三个阶段分别是:硬件定义数据中心(HDDC)、软件定义数据中心(SDDC)、容器时代。
在硬件定义数据中心时代,不同大型机/小型机厂商的操作系统和硬件紧耦合,应用在不同业务系统上迁移难度非常大。
随着X86服务器以及虚拟化技术的普及,操作系统与底层服务器硬件实现松耦合,IT界进入”软件定义数据中心“的时代。
随着技术的发展,IT进入了“应用为王”时代。在新的时代,能否做到应用与操作系统松耦合呢?让应用在不同操作系统之前实现无缝迁移,做到”构建一次,到处运行”?在这个时间点,docker出现了。近两年,docker受关注的程度越来越高。
容器的四大应用场景
随着容器时代的来临,是不是容器适用于所有的应用,解决所有的问题呢?带着这个问题,笔者查询了很多资料,也与业内的大拿们进行过多次探讨,总结而言,容器主要适用于四种大的场景:
那么,有没有容器不适合的场景或应用呢?
我们知道,应用从大的类型划分,可以分为记录性系统和参与交互型系统。记录型系统如银行的记账系统、核心交易系统等。此类应用大多是传统类应用,这类应用更加关注稳定运行。笔者认为此类应用很难做成分布式,暂时不适合容器(例如数据库表很难拆分成多个小表)。此类应用的一个显著的特点是需要频繁操作外部持久化存储。
随着第三平台的兴起,越来越多的新兴应用都是参与交互系统类的。此类应用更加关注于快速角度以及客户体验。如最常见的互联网类应用。此外,实际上很多银行也在研究如何将应用向容器迁移,而截至到目前,有些银行的一些应用,也已经迁移到容器上,如手机银行类的应用。
Docker的兴起与当年X86虚拟化的兴起,有相同之处,也有不同之处。相同之处是,它们都对现有IT基础架构造成重大的影响。X86虚拟化是云计算的基础,Docker的兴起促进了PaaS、微服务的发展。不同之处是,X86虚拟化的发起和推动者,通常是IT厂商,而Docker的推动者,很多时候是用户本身。从本质上讲,X86虚拟化与容器并不是直接的冲突与替代的关系,而是相互补充的关系。X86虚拟化的长处是高隔离性和易于管理,容器的长处是轻量级是适应快速变化。笔者预测,在今后的很长一段时间里,采用X86虚拟化与容器相结合使用,构建统一的混合云平台,将是一条更为实用的策略。
容器的超融合
谈到超融合,我们最常见的X86虚拟化的超融合,也就是某几台物理服务器,既提供计算虚拟化资源,又提供存储虚拟化资源。超融合方案有它的适用场景,也有它的长处。
那么,容器有没有超融合呢?答案是有,也就是某几台服务器,既提供容器的计算资源,又为容器提供可共享的持久化存储。
谈到容器,很多人对它的印象是无状态和数据易失性。没错,传统的容器技术确实难以保留持久数据。但是通常企业使用容器,都需要容器的数据能够被保留下来。
那么,容器持久存储怎么实现呢?比较简答的做法是,在容器启动的时候,给一个容器设置一个持久存储的文件系统(可以挂载到容器的/mnt目录)。容器本身的无状态数据不必写到这个文件系统,而需要保留的数据写到持久化的文件系统上。实际上,在企业级的容器方案中,除了需要为容器提供持久化存储,企业内部的容器镜像库,也需要持久存储。
从协议上讲,给容器增加外置持久存储最简单的方案是使用NFS。也就是将本地或者共享存储所创建的文件系统以NFS的方式挂给容器。但我们知道NFS的性能并不是很好,并且如果容器发生跨节点的重启,也很难实现数据共享。因此在容器的场景中,从性能、效率和高可用角度,笔者推荐使用分布式文件系统--gluster,来作为容器的持久存储。
在笔者的实验中,Openshift版本是3.3,gluster的版本是3.1.3,都是目前最新版本。使用三个服务器(gnode1,gnode2,gnode3),三个服务器配置成一个gluster集群。然后在三个节点上安装OpenShift。其中一个节点gnode1作为OpenShift的Master节点,另外两个服务器gnode2和gnode3,作为OpenShift的Node节点。OpenShift的。Gluster集群中创建了一个volume,名字叫lv2,为容器提供持久存储(挂载到容器的/mnt目录)
首先我们看一下gluster的配置,gluster集群三个节点的服务器名称分别为gnode1、gnode2、gnode3:
查看gluster集群节点的状态:
查看gluster集群volume的状态:
lv2是一个条带卷,分布在三个gluster节点上,三个节点上的bricks的名字都是:/glustersource/lv2。
将Gluster和OpenShift配置成超融合,有几个技术点需要注意:
实验中,在三个服务器配置好gluster集群、安装好openshift以后,接下来就是gluster和openshift的对接工作了。这里有两个配置:gluster的endpoints和gluster service(将gluster的服务容器化):
在endpoints的配置文件中,将gluster三个节点的IP都写上:
然后执行oc create -f gluster-endpoints.yaml ,创建endpoints,创建完毕后,效果如下:
接下来,创建gluster的service,yaml文件配置如下:
然后执行oc create -f gluster-service.yaml ,创建service,创建完毕后,效果如下:
截至到目前,gluster已经可以为openshift提供服务了。
接下来的操作,就是创建pv、pvc和pod的操作,在这里,创建的命令都是oc create -f 我不再赘述,这里只列出yaml的配置文件:
PV配置文件:
PVC配置文件:
Pod配置文件(需要注意下图配置中的1000数字,就是上一步笔者创建的david组id,也就是让这个pod可以对volume有读写权限):
查看查看PV、PVC和Pod的状态:
通过命令行,进入已经创建好的pod:即gluster-pod:
在pod中,可以很清楚地看到,容器/mnt目录是由192.168.137.10服务器的lv2挂载过来的,这个IP地址就是gluster集群的第一个节点,也是openshift的master节点。
笔者在pod的/mnt目录中写一个文件:davidwei-test:
然后退回到gnod1的gluster brick中进行查看,可以很清楚看到在pod中写的文件。
这时候,如果我们将pod删除,再使用之前pod的yaml文件创建pod,依然可以看到此前写的文件。重建pod的截图此处不再赘述。
总结:虚拟化超融合的方式,有助于客户充分利用资源,统一管理。而基于容器的超融合的优势更加明显。关于此方案,读者有兴趣可以线下进行讨论。