加入收藏 | 设为首页 | 会员中心 | 我要投稿 宁德站长网 (https://www.0593zz.com/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 服务器 > 安全 > 正文

OpenStack高可用集群案例实践分享

发布时间:2021-01-16 23:14:12 所属栏目:安全 来源:网络整理
导读:副标题#e# 《OpenStack高可用集群案例实践分享》要点: 本文介绍了OpenStack高可用集群案例实践分享,希望对您有用。如果有疑问,可以联系我们。 1. 规划与部署 本次分享提炼自我们在某企业部署OpenStack高可用集群的实际案例,初期平台面向公网给部分部门提
副标题[/!--empirenews.page--]

《OpenStack高可用集群案例实践分享》要点:
本文介绍了OpenStack高可用集群案例实践分享,希望对您有用。如果有疑问,可以联系我们。

1. 规划与部署

本次分享提炼自我们在某企业部署OpenStack高可用集群的实际案例,初期平台面向公网给部分部门提供虚拟化基础设施,但仍属于私有云.其中我借鉴了以往操作比如oVirt(RHEV)、VMWare、Citrix等项目的经验.考虑到时间关系,本次内容将以方法为主,减少细节描述.还有本次涉及到的工具多以开源形式呈现,尽量不涉及到产品,以方便大家集成或开发.

架构简图可参考如下,稍后我们会就其中细节进行讲解.两个架构图的区别在于控制节点的高可用方式.

1.1. 基本环境

因为客户网络环境复杂,为了节省部署时间与减少返工率,我们需要在去现场之前准备好以下三种安装方式:

  • PXE LiveCD
  • 定制系统安装盘
  • 安装包与安装脚本

第一种方式即在用户网络环境下使用现场人员笔记本或者客户服务器启动PXE服务,配置好系统架构(服务器MAC地址、网络配置、存储配置、对应的OpenStack模块与角色、定制包、系统微调与优化措施等),然后开始全自动安装,功能与Mirantis类似,但对网络要求低很多.

第二种方式既是采用定制的系统安装盘,里面需要准备尽可能多的存储设备与网络设备的驱动,以尽可能适配客户服务器与实施人员的自带存储设备.

第三种方式作为前两种方式的替补选项,主要是因为某些客户环境中安装非标系统需要走很多流程,我们提前让客户准备好操作系统,再到现场安装.如果给你准备的系统是RHEL、SUSE或者其他标准Linux系统的倒还好,如果他有情怀地花了一两天给你现编译上了Gentoo甚至给你准备了一台小机,那就没办法了(开玩笑,尚未遇到过这样的客户,在进厂之前要把基本环境沟通清楚).另外,它也可以作为以上两种安装方式失败后的最佳选项.

这几种方式也不能说孰优孰劣,从效率上来说我推荐第一种,但针对难以定制的商业虚拟化我们就只能采取手动安装的方式了.

题外话:很多所谓“5分钟装完IaaS”的“神话”都不把服务器从启动到改BIOS配BMC/IPMI的时间算进去.

1.2. 网络规划

这一步骤优先级最高,我们必须在动手之前就按照功能区域把网络进行划分,包括管理、网管、存储、租户、显示、迁移等.当然,很多情况下没必要划分太细,因为我们要根据用户网络环境和软件特性对他们进行规划,规划太细发现最后配置难以实现,“一把梭”规划发现用户一上来就喊卡.

一般来说,客户的物理网络主要以VLAN为主,其他情况暂不讨论.对于非核心层的虚拟化而言,我们看到的多是untagged网络,所以规划时要时刻留意网关与掩码;而对于核心层的虚拟化,那么我们很有可能得到一堆tagged网络,都由我们自己与客户商讨规划.

在网络硬件上,仅就虚拟化层面而言,KVM系列的要求不高,而VMWare的FT则要求较为苛刻,万兆、IB等都是标配(题外话:KVM的FT功能尚不稳定).如果涉及到下面要讲到的“超融合”,那么万兆专用存储网络真的是标配了.如果应用层面涉及到诸如Oracle之类的应用,那我们很可能就要使用网络设备透传了,也可看规划选择性地走RDMA.

当然,在现场时我们很有可能遇到交换机是全新并且客户网管也不太会配置的情况,虽然极少但也是有的.秉着专业事儿交给专业人来干的原则,咱们可以等,等网管把交换机配好(客户沟通妥善时自带网管技能也行).

网络规划时,我们在最大限度保证带宽的同时,要给予整体充分的可扩展性.这次项目中,为了给予客户享受科技带来的便利,比如OpenStack Neutron便利网管、实现NFV导流、Fabric Network、Packet Broken Network、减少网络单点故障率等等,我给客户推荐了几台SDN交换机与其Neutron主机集成,然后可以在OpenDayLight里开发应用程序并与OpenStack Dashboard结合呈现出看起来高大上的界面和功能,最大限度地利用OVS.(这里要感谢上海同悦信息龙未来先生协助开发的应用)

1.3. 存储规划

如果用户那有现成的存储设备那就最好不过了,但也有利有弊.好处是减少了我们的运维负担,关键时刻也可以“甩锅”;坏处就是现有存储很可能限制我们平台的能力,也存在潜在的兼容性风险.

由于软件定义存储的风行,尤其是VMWare带来的业界领导作用,客户有可能想当然地认为虚拟化层面的存储就该我们自己负责.那没办法了,要么找个通过兼容性测试的存储设备,要么自己上.这时候,用户也是有选择权的,比如这次就要上Ceph,虽然我个人更偏向于Glusterfs.

这些分布式存储大同小异,与传统的集中式存储相比他们的成本低廉,性能与功能都尚可,能覆盖绝大多数普通客户的需求.但我们上分布式存储总不能再问客户要几台服务器专门搭存储吧,那就得部分“超融合”了.

“超融合”也是现在OpenStack厂商项目部署的主流做法,比如管理组件在虚拟机中,硬件仅仅充作当作功能性代理去操作硬盘.而本次项目中,我们也将Nova与Ceph装在同一批机器中,同时采用对两者进程的运行时环境进行了优化的系列措施,尽量减少“此消彼长”带来的影响.

1.4. 软件配置

绝大部分软件都来自社区发布版本,部分核心模块来自红帽企业版,因为就踩坑几率而言社区版本更高,况且我们作为国内一个小小的软件厂商,对红帽有一种执念,哈哈.

到宿主机层面的网管软件并没有额外采购,而是继承了客户原有系统;而到虚拟化层面,则额外配置了OpenDayLight结合OpenStack Dashboard进行管理.

由于主机的存储空间较多,所以本次也就存储多网关协议进行了一些拓展,类似于OpenMediaVault和FreeNAS的功能,以方便其他平台使用.

本次部署的OpenStack仅涉及到虚拟化以及块存储相关组件,并未涉及到容器部分,因为客户选择了一家国产厂商的容器平台作为应用平台.此种环境下的OpenStack平台仅仅提供计算与存储能力,且保证一定的容器隔离性.

(编辑:宁德站长网)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!