又拍云运维总监邵海杨详解 DevOps “八荣八耻”(2)
以往开发运维要安装一个机器,首先要去申请采购,购买完了还要等待运输,在运输中要花去一天的时间,之后还需要配交换机和网络. 在这个过程中你会发现,简单的给开发配台机器,光上架就涉及到运维的很多环节,更不要说系统安装,优化,软件配置等剩余工作了,所以大多数情况下你只能做到部分交付. 要如何解决这些问题? 通过OpenStack可以做到云计算、云网络、云存储这三块搭建完成之后,进行整体交付. 根据一些经验总结,在整个云平台当中,云存储的坑最多,云计算、云网络相对来说比较成熟.现在云计算的硬件基本上是基于英特尔CPU的虚拟化技术来硬件指令穿透的,损耗大概2%~5%,这是可以接受的. 至于云网络,刚才胡凯(B站运维总监)提到内网包转发效率,我做过一个测试,在OpenStack的内网中,如果MTU默认是1500,万兆网卡的转发率大概为6.7xxGbps. 后来我在优化的过程中,也翻查一些文档,看到的数据是可以达到9.5xxGbps,通过不断的摸索,对比测试后发现,如果把内网的MTU搞成大包,如9000时,万兆网卡的存储量直接达到了9.72Gbps左右的.
Docker的好处是可以做到Build、Shipand Run,一气呵成.无论是对开发,测试,还是运维来说,Docker都是同一份Dockerfile清单,所以使用Docker在公司里的推动就很顺畅. 虽然OpenStack也可以一站式交付,整体交付,使用时非常方便.但是对开发来说,他还是拿到一台机器,还是需要去安装软件环境,配置,上线,运行,除了得到机器快一些,对上线服务没有什么大的帮助. 所以我们现在的Openstack集群一般对内申请开发测试用,外网生产环境还是以Docker容器化部署为主,这也是大家都喜闻乐见的方式.
五、以无状态为荣,以有状态为耻 △ 以无状态为荣,以有状态为耻 有状态的服务真的很麻烦,无论是存在数据库、磁盘开销,还有各种锁等资源的竞争,横向扩展也很差,不能重启,也不能互备. 所以,有状态的服务对于扩展原则来说,就是一场恶梦.如何解决我们说的这个问题,那就要使用解耦和负载均衡的方法去解决问题. 1. 使用可靠的中间件 中间件其实最早出现在金融公司、证券公司,后来随着互联网行业不断壮大以后,就出现了一些高可靠性的号称工业级的消息队列出现,如RabbitMQ,一出来以后,就把中间件拉下神坛. 随着中间件民用化,互联网蓬勃发展,是可以把一些服务变成无状态,方便扩展. 2. 公共资源池 我们可以通过各种云,容器云、弹性云,做计算单元的弹性扩展. 3. 能够被计算 如果你不想存状态,那也可以被计算,比如说Ceph存储,它的创新在于每个数据块都是可计算出来的,这就类似无状态的,每次都算,反正现在的cpu都这么强悍了. 所以,无状态是一个命题,在做架构的时候,你脑海里一定要有这个意念,然后再看你用什么样的方式开动脑筋,预先的跟开发,运维沟通好,把应用拆分成一种无状态的最佳组合. 六、以标准化为荣,以特殊化为耻 △ 以标准化为荣,以特殊化为耻 在标准化方面,我们在这几个方面改良: 1. 统一输入输出 统一入口是我加入公司后做的第一件事情,我们用一个统一的文本,到现在也在用,然后推送到所有的边缘,服务器上面的组件,要用到的参数,都能从配置里读出来. 代码管理方面我们也使用git,git wiki,批量部署我们用ansible(早在2012年,我做了一些比较后,就在公司里推行ansible,看来还是很明智的决定). 2. 统一的流程管理 运维中使用python最多,所以我们使用了yaml和playbook.我们有自己的跳板机,通过VPN登陆,目前我们也在试用一个带有审计功能的堡垒机,可以把每个人的操作录制下来,然后再去回放观察,改进我们的工作流程. 3. 抽象底层设计和复用组件 如果是开发者的话,就会写很多的复用函数,对于优秀的运维人员来说,也要有优秀的抽象业务的能力,也要去做一些重复工作的复用准备,如频繁的,繁琐易出错的手工操作抽象成若干运维的脚本化. 最后是巧妙的利用虚拟化、容器服务、server-less微服务,这些服务是可以被备份,还原的,可以保持一个相对稳定的状态,我们要拒绝多的特殊管理操作. 香农-信息熵理论里说,变量的不确定性越大,熵就越大,把它搞清楚所需要的信息量也就越大.理论上来说,如果是一个孤立的系统,他就会变得越来越乱. 七、以自动化工具为荣,以手动和人肉为耻 (编辑:ASP站长网) |