基于超融合架构的容器云管部署实践

本文涉及的产品
容器镜像服务 ACR,镜像仓库100个 不限时长
简介:

作者介绍

张扬,DaoCloud售前工程师,致力于企业IT环境中容器化、超融合和云计算方面的需求分析,方案设计和技术支持。曾任职IBM AICS云服务项目并负责Cloud Infra和DevOps相关工作。Nutanix社区活跃用户,个人微信号:小张烤茄。

 

随着云计算的逐步落地,容器化和超融合等技术开始风靡整个IT圈。本次分享主要从技术层面讲述云计算环境中容器化和超融合的双擎工作模型。

 

 
一、超融合概念
 

 

超融合基础架构(Hyper-Converged Infrastructure,或简称”HCI”)也被称为超融合架构,是指在同一套x86单元设备中不仅仅具备计算、网络、存储和服务器虚拟化等资源和技术,而且还包括缓存加速、存储分层、重复数据删除、在线数据压缩、快照技术等元素,并且多节点可以通过网络聚合起来,实现模块化的无缝横向扩展(scale-out),形成统一的资源池。

 

传统集中式存储的基础架构一般会被分为四层:以太网络层、计算资源层、存储网络层和存储资源层。如下图:(图中没有涉及以太网络层)


 

这样的模型在传统的架构中是非常适用的,但是随着云计算和用户体验时代的体验到来,在应用规模比较大的场景中该模型面临着很大的挑战。


比如:集中存储容易成为IO性能瓶颈、层次过多不易管理、扩展复杂且价格昂贵、数据储存偏向中心化等等。如下图:


 

超融合基础架构基于Web Scale(一种面向基础架构和资源的全新架构方式,实现互联网规模的弹性扩展能力)的设计思想,从硬件层面将计算资源层、存储网络层和存储资源层融合为一层,增强数据中心基础架构的灵活性并降低复杂度。如下图:




超融合从硬件将传统的计算资源和存储资源集成到一个2U的标准设备里,并提供千兆网络口用于前端应用的访问,万兆网络口用于后端分布式存储的数据传输,从而全面摆脱传统造价昂贵的存储网络和集中式存储。

 

同时也在软件层面基于软件定义一切则准则,使用虚拟化和分布式存储等技术,实现分布式的资源调度。如下图:


 

分布式架构将所有的资源池化,从而实现单点性能瓶颈的消除、去中心化、无上限扩展等云计算环境中所需要的基本要素。如下图:


 

超融合基础架构的本质是在硬件层包含计算和存储资源,并在软件层通过软件定义的方式实现资源池化,为上层应用提供去中心化且可弹的基础架构支撑。

 

 
二、超融合架构介绍
 

 

1、硬件架构

 

 

 

下图可以看到,Nutanix 3000系列的超融合硬件设备是一台x86平台的2U机架式服务器。



 

含有:

  • NODE: 每台Nutanix服务器可支持1到4个节点。

  • SSD: 每节点可支持一到两块400或800GB的固态硬盘,最大支持6400GB。

  • HDD: 每节点可支持一到四块1TB的机械硬盘,最大支持16TB。

  • CPU: 每节点可支持一到两颗Intel CPU,最大支持64核。

  • MEM: 每节点可支持64到512GB内存,最大可支持2TB。

  • SATADOM: 每节点必须含有一块64GB的SATA接口的固态硬盘,预装客户所选择虚拟化类型的Hypervisor。有Nutanix AHV,VMWare ESXi和Microsoft Hyper-V三种可选。

  • NIC: 每节点含有两块10GB以太网卡(用于NDFS),两块1GB以太网卡(用于应用)。

  • Other: 每节点含有一个VGA接口,一个IPMI接口,4个USB接口。整机2个电源模块,4个风扇。

 

硬件层是标准的x86架构的服务器,包含计算和存储所需的硬件资源。核心是SATADOM,其中预装的软件实现了超融合设备“开箱即用”的功能。整个物理架构非常简单,这也是超融合的价值所在,企业基础架构需要扩容的时候拿这样一台设备上架加电接网即可。

 

2、软件架构
 
 

 

Nutanix的软件架构基于两个产品来实现:Prism和Acropolis


 

Prism是一个分布式的资源管理平台,基于Web Console实现对超融合集群环境对象及服务的管理和监控,类比VMware vCenter。

 

Acropolis是一个分布式的多资源管理器,集协同管理和数据平台功能于一身,实现计算和存储资源的管理和调度,类比VMware vSphere+vSAN。

 

包含三个主要组件:

 

  • DFS(Distributed Storage Fabric)分布式存储架构,基于Nutanix分布式文件系统实现存储资源池化的存储平台。

  • AMF(App Mobility Fabric)应用移动性架构,提供在Hypersior间动态切换和移动工作负载的功能。

  • AHV(Acropolis Hypervisor)虚拟化管理器,基于CentOS KVM开发后的多用途虚拟化管理器组件。

 

以上介绍的软硬件架构基本在每个厂商的超融合产品中都包含,可以说已经形成了一个业界的标准。特别是软件层面的虚拟化和分布式存储更是每个超融合产品必须具备的功能组件,毕竟超融合的准则是软件定义一切,是实现SDDC(软件定义数据中心)的终极技术路径。

 

 

软件定义一切的魅力也在于,自行攒机也同样可以基于社区版部署出一套超融合的HomeLab。

 

 
三、超融合对容器化的支持
 

 

Docker引领的容器化风潮已席卷整个IT行业,抛开容器圈内部的生态竞争,容器圈外的IT巨头也纷纷选择支持容器技术的发展,并且也一步步在自己的解决方案中融入容器技术。

 

Nutanix在新发布的AOS 4.7中同样为Docker容器推出了ABS和ACS功能,使得容器化能够很容易的在超融合架构上被承载。

 

ABS(Acropolis Block Services)使用iSCSI协议将存储资源以块设备的形式提供给的裸机、虚机或容器,从而实现了底层分布式存储对外部对象的支持。


 

如图,容器中的重要数据就是以外部volume的形式存放到ABS存储中,从而实现了数据的持久化。

 

ACS(Acropolis Container Services)实现Nutanix超融合平台对Docker容器化的支持,解决了容器应用数据持久化的问题并提供了效能和安全兼顾的”双擎”方案。


 

ACS包含两个主要组件:

 

  • Nutanix Docker Machine Driver:Docker Machine操作Nutanix平台部署Docker宿主机的驱动模块。

 

 

如果有使用过Docker Machine的朋友对这个就会比较熟悉,Machine Driver会被Docker Machine调用,然后基于Prism的API在Nutanix的超融合平台快速创建标准的Docker宿主机。

 

  • Nutanix Docker Volume Driver:Docker数据卷容器操作Acropolis Block Services的驱动模块。

 

 

Volume Driver提供的容器卷插件(Volume Plugin)遵循Docker提供的规范,将容器中的关键数据储存到ABS所提供的分布式存储中,以外部volume的形式实现容器数据的持久化。

 

 
四、容器云管介绍
 

 

容器云管平台提供了容器集群环境中容器和应用的管理和编排。目前国内外的容器云管有很多,且基本都是基于Google Kubernetes、Apache Mesos和Docker Swarm三种编排工具来实现。

 

下面我将以DaoCloud Enterprise(DCE)为例进行讲述。我们采用的是一套以Docker Native为核心、将Swarm作为集群中的编排工具,可部署到物理机、虚拟机或云主机上的企业级应用云管平台。它提供企业容器云环境中应用编排、镜像仓库、负载均衡、日志和监控管理、网络和存储控制等功能。

 

我们采用Manager-Worker的拓扑结构:

 

 

 

  • DCE Controller作为控制节点,处理所有的用户请求,并管理集群中的所有容器节点。

  • DCE Agent作为容器节点,承载用户的容器和应用的运行。

 

下面我们看一下本次实践的拓扑结构:

 

 

本次部署采用企业级的高可用模式,底层使用Nutanix的超融合环境生成5台标准的Docker宿主机,Docker宿主机中3台作为我们的高可用Controller集群,2台作为我们云管平台的Agent运行用户应用所需的容器。

 

 
五、部署实践
 

 

前面提了很多理论性的东西,下面基于上述功能在超融合架构的基础上部署出一套容器运管平台,并使用应用商店发布一个数据持久化的Wordpress应用。

 

1、宿主机生成
 
 

 

Docker宿主机是使用Nutanix Docker Machine Driver生成的虚拟机,使用该种方式可实现在每台Docker Host快速部署的同时保证硬件配置、软件版本的一致性。

 

命令格式如下:

 

 

有使用过Docker Machine基于virtualbox生成宿主机的朋友可能会比较熟悉,区别就是驱动为nutanix,参数方面包含超融合的环境信息以及宿主机的硬件配置信息。

 

我们通过该命令生成部署所需的5台宿主机。

 

 

2、分配块设备
 
 

 

向5台Docker宿主机分配相应容量的块设备作为Docker Engine的数据存储。

 

 

作为生产环境的企业级云管平台,我们不推荐使用devicemapper默认的loop-lvm模式,所以我们需要使用外部ABS存储分配的块设备来配置direct-lvm模式。

 

3、DCE云管部署
 
 

 

云管作为容器运行在Docker宿主机之中,使用DCE自带Toolbox来部署也很灵活和简单。



 

本次实践用到的install命令实现控制节点的部署,join命令实现容器节点的部署。

 

部署主控节点
# bash -c "$(docker run --rm daocloud.io/daocloud/dce install)"

 

部署副控节点
# bash -c "$(docker run --rm daocloud.io/daocloud/dce install --force-pull --replica --replica-controller MASTER_CONTROLLER_IP)"

 

部署容器节点
# bash -c "$(docker run --rm daocloud.io/daocloud/dce join --force-pull MASTER_CONTROLLER_IP)"

 

需要注意的是MASTER_CONTROLLER_IP为主控节点的IP地址。

 

4、发布应用
 
 

 

启动应用容器的时候需要调用Volume Plugin来实现外部存储的挂在,docker run命令的格式如下:



 

和通常run一个容器的命令基本没区别,只需加上–volume-driver参数并指定为nutanix即可。

 

由于本例需要使用DCE的应用商店部署一个Wordpress应用,所以我们要修改WP的compose文件以实现外部volume的挂载。在选择部署WP应用之后,云管平台默认会提供一个compose文件模板,用户可以基于该模板文件进行自定义操作。

 


 

如上图,将volume_driver参数指定为nutanix,并将volumes参数中的卷挂载到WP的MySQL数据目录即可。随后DCE会基于自定义好的compose文件自动的去部署WP应用。

 

5、状态检查
 
 

1)容器运行状态


可以看到compose文件中定义的wordpress和mysql两个容器已分别被分布在两个agent节点部署且运行。

2)应用访问

 


 

访问平台中wordpress容器提供的应用链接来确认应用可成功访问。(WP的配置步骤在此省略)

3)外部卷

 

Compose文件定义的外部卷wpdb已经在存储池中创建成功,数据持久化功能得以实现。

 

至此基于Nutanix超融合架构的容器云管平台部署已经完成。本次主要是从技术层面抛砖引玉似的分享容器化+超融合这种双擎模式的尝试,希望能给大家带来一些启发。


本文来自云栖社区合作伙伴"DBAplus",原文发布时间:2016-11-09

目录
相关文章
|
12天前
|
Kubernetes Cloud Native 微服务
探索云原生技术:容器化与微服务架构的融合之旅
本文将带领读者深入了解云原生技术的核心概念,特别是容器化和微服务架构如何相辅相成,共同构建现代软件系统。我们将通过实际代码示例,探讨如何在云平台上部署和管理微服务,以及如何使用容器编排工具来自动化这一过程。文章旨在为开发者和技术决策者提供实用的指导,帮助他们在云原生时代中更好地设计、部署和维护应用。
|
14天前
|
运维 监控 Java
后端开发中的微服务架构实践与挑战####
在数字化转型加速的今天,微服务架构凭借其高度的灵活性、可扩展性和可维护性,成为众多企业后端系统构建的首选方案。本文深入探讨了微服务架构的核心概念、实施步骤、关键技术考量以及面临的主要挑战,旨在为开发者提供一份实用的实践指南。通过案例分析,揭示微服务在实际项目中的应用效果,并针对常见问题提出解决策略,帮助读者更好地理解和应对微服务架构带来的复杂性与机遇。 ####
|
14天前
|
算法 NoSQL Java
微服务架构下的接口限流策略与实践#### 一、
本文旨在探讨微服务架构下,面对高并发请求时如何有效实施接口限流策略,以保障系统稳定性和服务质量。不同于传统的摘要概述,本文将从实际应用场景出发,深入剖析几种主流的限流算法(如令牌桶、漏桶及固定窗口计数器等),通过对比分析它们的优缺点,并结合具体案例,展示如何在Spring Cloud Gateway中集成自定义限流方案,实现动态限流规则调整,为读者提供一套可落地的实践指南。 #### 二、
36 3
|
13天前
|
消息中间件 运维 安全
后端开发中的微服务架构实践与挑战####
在数字化转型的浪潮中,微服务架构凭借其高度的灵活性和可扩展性,成为众多企业重构后端系统的首选方案。本文将深入探讨微服务的核心概念、设计原则、关键技术选型及在实际项目实施过程中面临的挑战与解决方案,旨在为开发者提供一套实用的微服务架构落地指南。我们将从理论框架出发,逐步深入至技术细节,最终通过案例分析,揭示如何在复杂业务场景下有效应用微服务,提升系统的整体性能与稳定性。 ####
29 1
|
14天前
|
监控 安全 持续交付
构建高效微服务架构:策略与实践####
在数字化转型的浪潮中,微服务架构凭借其高度解耦、灵活扩展和易于维护的特点,成为现代企业应用开发的首选。本文深入探讨了构建高效微服务架构的关键策略与实战经验,从服务拆分的艺术到通信机制的选择,再到容器化部署与持续集成/持续部署(CI/CD)的实践,旨在为开发者提供一套全面的微服务设计与实现指南。通过具体案例分析,揭示如何避免常见陷阱,优化系统性能,确保系统的高可用性与可扩展性,助力企业在复杂多变的市场环境中保持竞争力。 ####
33 2
|
14天前
|
消息中间件 运维 API
后端开发中的微服务架构实践####
本文深入探讨了微服务架构在后端开发中的应用,从其定义、优势到实际案例分析,全面解析了如何有效实施微服务以提升系统的可维护性、扩展性和灵活性。不同于传统摘要的概述性质,本摘要旨在激发读者对微服务架构深度探索的兴趣,通过提出问题而非直接给出答案的方式,引导读者深入
31 1
|
15天前
|
负载均衡 监控 API
后端开发中的微服务架构实践与挑战
本文深入探讨了微服务架构在后端开发中的应用,分析了其优势和面临的挑战,并通过案例分析提出了相应的解决策略。微服务架构以其高度的可扩展性和灵活性,成为现代软件开发的重要趋势。然而,它同时也带来了服务间通信、数据一致性等问题。通过实际案例的剖析,本文旨在为开发者提供有效的微服务实施指导,以优化系统性能和用户体验。
|
11天前
|
Cloud Native API 持续交付
云原生架构下的微服务治理策略与实践####
本文旨在探讨云原生环境下微服务架构的治理策略,通过分析当前面临的挑战,提出一系列实用的解决方案。我们将深入讨论如何利用容器化、服务网格(Service Mesh)等先进技术手段,提升微服务系统的可管理性、可扩展性和容错能力。此外,还将分享一些来自一线项目的经验教训,帮助读者更好地理解和应用这些理论到实际工作中去。 ####
26 0
|
13天前
|
弹性计算 API 持续交付
后端服务架构的微服务化转型
本文旨在探讨后端服务从单体架构向微服务架构转型的过程,分析微服务架构的优势和面临的挑战。文章首先介绍单体架构的局限性,然后详细阐述微服务架构的核心概念及其在现代软件开发中的应用。通过对比两种架构,指出微服务化转型的必要性和实施策略。最后,讨论了微服务架构实施过程中可能遇到的问题及解决方案。
|
22天前
|
Cloud Native Devops 云计算
云计算的未来:云原生架构与微服务的革命####
【10月更文挑战第21天】 随着企业数字化转型的加速,云原生技术正迅速成为IT行业的新宠。本文深入探讨了云原生架构的核心理念、关键技术如容器化和微服务的优势,以及如何通过这些技术实现高效、灵活且可扩展的现代应用开发。我们将揭示云原生如何重塑软件开发流程,提升业务敏捷性,并探索其对企业IT架构的深远影响。 ####
35 3