您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Model Center   Code  
会员   
   
 
     
   
 订阅
  捐助
大型私有云运维实践
 
  2987  次浏览      16
 2019-1-10
 
编辑推荐:
本文来自于网络,本文主要介绍了最近几个云技术发展趋势、云建设的目标以及私有云运维方面的经验等相关内容。

分享的内容有三部分:

第一部分为什么要建设云?云建设的目标是什么?

第二部分介绍一些云技术发展的趋势,有些技术也好几年了,但是最近也遇到一些变化;

第三,自己在私有云运维方面的实践。

1. 云建设目标

为什么要建设云?这里有个人的思考,也许不对,拿出来跟大家探讨。我总结的云建设的火箭模型,云建设的目标是要实现云原生,它有什么特点呢?弹性、持续发布、多租户、与基础架构无关、无状态、充分冗余、自动化、模块化、微服务。因为要把业务拆微服务实现云原生,首先要实现基础架构云原生,要实现虚拟机、物理机、容器的管理API化,方便上层调用。

当然这是目标,怎么实现云原生呢?对于创业公司来说首选基于云的无服务器计算,一步可以实现云原生,好处是学习成本低,不好的地方就是要使用公有云,要持续产生成本,每个厂商的接口不一样,一旦基于某个厂商建设起来很容易被绑定。

第二种方式我们就使用公有云的容器服务,公有云的容器服务相对比较成熟,它会产生费用,而且也很容易产生绑定,容器现在也有通用的接口。

当然还可以自建私有云,再其之上构建云原生的环境,这个缺点是什么?要从构建云的基础环境开始,周期非常长,要求也非常高。

已有的业务我们要做云原生怎么办?我们要重构这个业务。当然可以搞双模IT,旧的不管,新的方面来建设云原生。

现在云原生现状怎么样呢?真正实现云原生的企业并不多,就是头部的企业像BAT这类的,国外的是像谷歌、Facebook。

大部分组织或者有些组织只是实现了使用云主机或者虚拟机,离真正的云原生差距还是很大,还有很多的组织只能叫虚拟化,云可能都谈不上。原因是什么?第一个云原生要重构业务,觉得不划算,没这方面动力去做改变。

还有就是人才方面的制约,这方面的人要招、培训都有过程,管理层决心也非常重要,不管实现云原生还是DevOps的决心非常重要,中间会碰到任何问题,没有管理层的支持很难推进下去。竞争对手如果没有搞云原生,没有竞争压力也就没有没有推行云原生的决心,所以目前这个现状还要维持很长时间。

2. 最近几个云技术发展趋势

首先是裸金属,裸金属云也喊了很长时间了,这有一份数据,来自于中国移动研究院,腾讯云推出“黑石”物理服务器,还有Oracle、IBM、华为、阿里云、微软都有裸金属服务器。这是一个趋势,裸金属云发展还是比较快的,到2020年有90亿美金的市场份额。

裸金属云有什么特点?它的计算能力比较强,其实就是物理机。可以做到物理层面的隔离。快速交付,实际上是把物理机API化了。还有一个好处是可以和云产品打透,比如说和对象存储、VPC都打通,整个云融合在一起。

完全像使用云主机一样使用裸金属还是有些困难,比如说云主机有远程的VNC,有远程的界面可以看到,但是目前这些公有云提供的裸金属服务还有没有远程桌面的服务,技术上还是有好多需要克服的地方。

哪些场景可以用裸金属?一是性能要求比较高的,比如说大型在线游戏、基因测序,这种对计算要求比较高的业务,还有一些传统行业,想核心数据库,SAP HANA这些。

裸金属对传统行业是比较好的,SAP要云化放在云主机上不太现实,现在有一种方式直接可以搬到物理机上,并且放在云上,这是非常有吸引力的解决方案。还有大数据的分析,它的压力比较高,对压力、网络要求比较高,裸金属也很适合。还有用裸金属搭建私有容器云,这也是比较灵活的解决方案。

另外就是超融合,超融合喊了好多年了,目前国内很多厂商都在做超融合,看起来也是一种发展趋势,并且发展比较快。

这是中国超融合2016年的市场数据,每年有20%的增长。超融合好处是开箱即用,缺点是比较贵,不适合大型场景,中小企业比较适合,规模比较大的公司一方面成本比较高,一方面要定制化非常麻烦。

有没有接口,能不能跟现有的各种系统打通,能否跟流程、认证打通?还有超融合是一体化的,要扩容什么必须按比例扩容。

云方面还有一个技术 SDN,SDN实际就是把控制层面和转发层面分离。最近几年有一种声音,就是智能化的网络,我理解就是SDN+AI的解决方案,这个是思科网站的图,学习各种场景然后智能化。Ganter总结基于意图的网络有四个特征:

第一个就是转移和验证,将网络工程的命令转换为执行的操作能力,当管理者想要验证策略时,基于意图的网络系统会验证策略是否可以执行。

自动实施,软件自动执行网络管理员定义的策略。

网络状态感知,收集数据以持续监控网络操作。

保障和动态优化补救,机器学习可以确定保障策略的实施和纠正措施的自动化。

如果真的基于智能化的网络做的比较好,以后可能就是通过语音或者图拖拽两下就可以成功了。现在厂商各种产品都能看到智能,这个也是后面网络发展的方向。

再就是多云和混合云,混合云也喊了好几年了,多云就是使用多个公有云,像国内的公有云、阿里云、腾讯云。混合云就同时使用多云和私有云,还有异构,既使用小型机,也使用X86物理机。

这里也有私有云的数据,其实私有云里OpenStack国内用的比较多,但是国内外使用的多的还是VMware,昨天有一篇文章叫OpenStack的八年之痒,是非常yip有深度的文章,推荐大家看看。

接下来是云网融合,把自己的私有云和公有云打通,这样可以保证网络的稳定和数据安全,所以云网融合也是比较热的一方面。

云对IT团队也提到了比较高的要求,IT团队要转换到云上面,如何把云用好,如何专注云、控制云的成本?

在云时代运维的价值是什么?用云是必须的,用云的过程中要持续优化成本,云原生是持续的追求目标。

3.私有云运维方面的经验

在规模比较大的私有云里,还是比较讲究用传统的解决方案,像PDCA、ITIL。大型企业里ITIL是深入到IT内部的,必须要用ITIL语言进行沟通。

我简单用一个项目的实施周期给大家介绍一下如何运行的。首先就是大型项目里合规是红线,必须要过三级等保,我们也有合规方面的专家。然后要有大量的基于ITIL的制度、流程等方面的储备。

再简单介绍一下人员组织的演进,我们原来分为四块,系统方面包括系统方面的部署和实施,系统之上的云平台实施,网络方面专门做网络方面的实施,支持呢方面主要是ITIL的工作台工作,有24小时值班,还有工单系统、工单流转、任务追踪的支持,现场方面主要做物理服务器上架。

后来我们组织方面做了变革,分成架构组,主要做架构方面的设计还有方案的验证,和疑难杂症的处理;实施组,要有搭建云的能力,包括机房现场上架不线、服务器OS运维、网络设备之安全设备、分布式存储、云平台,然后内部还有考核,考核完了才具备实施组的资格,支持组做的事情和原来差不多。

架构组要有方案的能力和云平台的搭建能力,还要完整的云运维能力,还要脚本以及编程能力。每碰到一个新项目来的时候我们生成虚拟项目组,这个项目会有唯一的运维内部的owner,从项目开始到项目结束,他是唯一的责任人,也包括跟客户和公司技术人员对接。这个项目出了问题这个owner必须要负责,觉得容量不够了就要申请资源,客户有需求也会跟客户约谈,他知道这是责任是他的,他也跑不掉。

这就是我们人员组织方面的经验。然后就进入项目立项阶段,我们会指定Owner,然后制定实施方案,主要就是WBS的形式,WBS就是三个字母的缩写,Work、Breakdown、Structure,它是按照一定的结构模式去组织的。

举个例子,比如说包饺子有很多人包过,没包过也看到过,可以分解为准备饺子馅、饺子皮等,就不详细介绍了。

这一块插播一下七大人生工具,SWOT分析PDCA循环、6W2H法、SMART原则、时间管理、WBS、八二原则,比如说WBS我开始看起来也非常有道理,但是做的时候发现有好多细节上的东西,真正实践的时候,尤其做项目的时候怎么样分解,是按照时间线分解还是按照任务分解呢?关于各种人生方法有好多书大家有兴趣也可以研究一下。

做项目实施的时候反而简单了,按照自己的WBS做,做了哪些?哪些没做?为什么有偏差?

然后进入项目运维阶段。首先够是ITIL方面的流程,我们使用了大量的开源工具。

工单方面我们用的OTRS,OTRS是非常重的工具,但是功能比较多一点,大家可以看一下。有的客户还需要大屏,当然如果要求比较高的话也会定制化开发大屏,国内有好多公司专门做大屏也能生存,最后就是专家,要有对疑难杂症比较熟悉的专家。

总结一下吧,有个故事,有一位将军射箭时围了一群人,每次射箭都能射到红点上,周围人都叫好,旁边有一个卖油翁说“无他但手熟尔”,将军很生气,卖油翁说:“以我酌油知之”,然后取一枚铜钱放到装油的葫芦上,拿瓢从很高的地方倒油,油细线一样进入到葫芦中,至始至终铜钱没有沾到一滴油,周围人都很叹服。

其实做运维也是这样的,不容有任何的纰漏和偏差,然后也要依靠经验、平台、流程和Checklist和核查机制,长期不断地尝试、修整、积累。我分享就这么多,谢谢大家。

   
2987 次浏览       16
相关文章

云计算的架构
对云计算服务模型
云计算核心技术剖析
了解云计算的漏洞
相关文档

云计算简介
云计算简介与云安全
下一代网络计算--云计算
软浅析云计算
相关课程

云计算原理与应用
云计算应用与开发
CMMI体系与实践
基于CMMI标准的软件质量保证