part2:cloudinfrastructure

Part 2 ：Cloud Infrastructure

Cloud对于每个人的理解都不一样；每个公司对于Cloud的定义也不一样；

有的把整个基础架构，应用架构（包含狭义的云，甚至数据平台，甚至运维）定义为云平台；

有的就是一个狭义的Openstack或者Kubernetes的私有化裁剪，定制和部署运营(99%+的互联网公司是learn-deploy的模式)scope，或者加上CI-CD这个模块， 狭义的云和运维也有分不清的界限和重度的合作；

Eventually，所有独立于一线业务的，都可以称为平台，或者云平台；平台做的好，本质上，就是模块搭得好；我们做基础架构的团队，本质上，就是要让业务开发，可以聚焦于业务本身，有很多的building blocks都ready，这些building block，不仅仅是指有MySQL, JVM, MC, MQ,而且包含如何高效利用这些building block的框架，尽量不用去担心，底层设施，担心扩展性，担心稳定性，担心安全，专心开发业务逻辑；

在离线数据平台上，就是大家可以直接写SQL，不用担心数据如何收集，如何计算，集群资源如何管理，集群如何稳定；在实时数据平台上面，让大家可以简单的开发各自的业务job，不用担心这个数据从哪个日志来，这个数据从那个数据库来，集群如何扩展，机器如何管理，日志如何检查；

这里先聊一下狭义云平台，在vip这几年的经验和心得；

vip从2013年开始，在ops团队里面，有一个10人的团队开始做research；

其实早年，很多公司还没有搞清楚，云究竟是什么；也不明白一个云平台的核心诉求和难点是什么；

要让production traffic跑在上面，如何确保核心系统稳定，是第一要务；

是否真的可以节约成本，也是非常多公司的老板，考虑的问题；

如何提高agility，也是需要考虑的核心问题；

大部分公司，是没有本事，hold住 一个理想化的云平台的：

虚拟化计算

虚拟化存储

虚拟化网络

灵活复杂的部署和调度支持

大部分公司，也不需要，那么多的虚拟化；

私有云， by design ，投入会比公有云小非常多 ，需要尽快出效果，出价值；绝大多数公司的老板，是不会投入一个大团队，让你搞个三年五年的；

私有云 ， by design ，也会比公有云简单很多： 你可以要求，应用开发团队，按照你的要求 /建议来应用和迁移上云，在架构设计方面，在系统运维方面，都可以商量着来；很多需要考虑的问题，很多潜在的问题，都可以by design，by requirement，规避和防范； 很多人没有搞清楚这一点； 有多少人，有多少技术资源，就做什么决策；

这是一个技术leader最需要的principle sense；

另外， 还是有很多人有误解，私有云，也可以削峰填谷 ；其实完全是个伪命题；只有公有云，甚至global服务的公有云，才可能真正有削峰填谷的作用的；因为互联网应用（至少互联网应用和绝大多数企业应用，都是同时间达到高峰，同时间达到流量/压力的谷底），是很难削峰填谷的；全球服务的才可能部分达到这个效果（而且没有太大的local部署）； 但是私有云还是有很大的价值 ，一个 是灵活性 （programmable infrastructure）,一个是现代PC  server已经太强大了， 软件系统完全跟不上硬件的处理能力增长 ，单机软件根本无法完全利用一个PC Server的处理能力；在Flash卡普及，大内存普及，10g网络普及的时代，不做虚拟化的确是太浪费机器资源了；

------------------------wip------------------------

早期vip的云团队，是在运维团队下的一个小的研究性team；team有很大的vision，差不多按照着aws的规划设计和开发了一个portal原型，包含了完整的vpc，sdn，shared storage，是一个完整的完全虚拟化的设计，也已经买好了开发测试环境几百台物理机计算节点和存储节点；

鉴于在eBay时候的一部分经验和在pptv时候的一部分经验，我知道什么是可以的，什么是不可以的：在可以确认解决容量，竞争/隔离和稳定性之前，minimize共享的component；

eBay早年的基于vmware的第一代云平台(虚拟化平台),用的是top of rack shared storage;这个shared storage在app一起boot起来的时候performance简直无法忍受，以及一个机架的app server一起开始写log的时候，或者偶尔的磁盘阵列rebuild的时候， 几乎是不可用的；这个问题貌似在第一代就没有解决过；我去pptv的时候，所以就很简单的learn一个lesson，stateless的app server是可以丢掉的，稳定性是最重要的，CPU可以超配，内存不能超配；minimize layer； 所以在pptv的虚拟化平台，推进的非常快，总体上也是非常的稳定（因为没啥共享组件），DNS，IP, LB都还是手工/半手工搞的；就是搞定了最核心，最简单，最成熟的计算虚拟化；超配CPU；前两份工作的最核心的lesson，就是基础组件，一定要稳定，一定要千锤百炼，经过各种测试才能上；尤其是宿主机Linux Kernel和Raid/NIC Driver; 99.9%的私有云平台，是没有能力hot-patch kernel的；也没办法hot-upgrade Driver；一旦发现需要升级Kernel或者Driver，那是要弄死人的；在自己没有足够人力能能力去优化底层之前，借鉴行业经验，多看mailist和和peer团队交流，是一个quick win；

在接手了云平台团队之后，我的第一个decision是砍掉了绝大部分的设计（vpc，multi-tenant, etc）重新评估，以公司给我们的人力(~15人团队)，和期望的时间（公司其实并没有给实际的期望）我们可以估计在什么时间点，deliver什么样的交付；和原有团队 讨论和 争执了很久，我坚持要砍掉大部分的设计，在新招的架构师的支持下，勉强说服了团队， 基于私有云的业务特征，简化网络，简化存储，做稳定计算，做好监控，做好vm provision和deploy的workflow，目标一年内可以初步production ready小规模尝试上线， 但是也造成了一部分developer的流失；

由于原先 已经 购买的机型，就是属于计算存储全分离的设计，我们决定先 按照原先计划上基于全分布式存储的解决方案，一边用一边看，是不是的确如我担心的不稳定，还是实际上还可以；事实证明，完全的存储虚拟化，以我们目前对底层和上层的总体的投入，以及glusterfs作为openstack的block解决方案的先天缺陷，有几个fundemental的问题，这是一个失败的尝试；

1.  glusterfs他的一个块设备就是一个底层文件，在安全上面就过不了关（私有云还可以忍），

2.  Glusterfs在一个block device作为一个文件的情况下，无法解决online rebalance底层磁盘的问题；

3.  Glusterfs在开启thin provision的时候，又无法实现online rebalance，直接导致文件增长到filesystem满，上层文件系统只读；

4.  Glusterfs的较弱的cluster心跳管理，比较容易出现brain split，导致磁盘只读；

5.  在关闭thin provision的情况下，完全实现不了shared storage thin provision的成本优势，而且创建一个较大的云盘，需要巨长的时间；而且受到底层文件系统的大小的局限；

6.  其他在默认XFS的跑storage node的时候，也发生过inode丢失等问题；

除了glusterfs本身的这些局限之外，连boot disk都在shared storage上，对系统稳定性的压力是巨大的；一个shared disk如果慢，整个云平台都慢甚至基本不可用，用户是无法忍受的；另外，分布式系统，当上面所有的主机受到某种影响同时发起IO的时候，就算每个机器IO都不高，集中起来就很高了；我们发生过两个case，一个是上面所有的vm都同时凌晨时间点puppet启动同步配置，然后持续好几天凌晨看到storage的响应变慢io变高；另外，又一次我们打开了一个logging配置，所有应用服务器一起写detailed log，居然把磁盘也写垮了；还有大大小小上面提到的这些坑，经过半年，团队终于认可，一方面是没有强需求根盘需要在共享磁盘上，一方面我们glusterfs的确也不成熟以及架构上不适合做块存储，一方面我们团队投在上面的底层技术研究也太少，我们原先也计算过，如果shared storage机器作为所有机器的boot盘，我们只能支持大几百个VM；然后就启动了为期半年的迁移计划，在原先的计算节点上扩充了SAS本地盘，在ssd存储机器机器重新拆分，改成了一部分仍然纯ssd，一部分ssd+sata的ceph集群，作为云盘的配置；ceph总体来讲，是一个比glusterfs复杂的多，设计上，也成熟的多的解决方案；相应的，ceph的部署和维护相对复杂，但是ceph也相对稳定；自从迁移到了ceph，云盘基本上没有出现过大的问题，除了扩容时候的整体slow down之外；

根盘相对而言，就简单多了；

在网络方面，我们一开始就经过讨论PK，极大的进行了简化，采用了相对长时间成熟的OVS VLAN模式，基本上没有碰到大问题；唯一的是早期openstack k版本

Control plan在openstack的问题，主要是MQ有些问题，本身的高可用，以及连接管理方面；在大量node boot起来的时候（机房掉电重启），DNS Server也会有一定的压力；需要改成多线程模式来处理响应；

Learning：

1.  有多少人，多大投入，在什么点有什么期望的delivery，来安排计划；量力而行，量入为出；

2.  懂需求，来设计产品；无论是业务产品，还是基础架构产品；脱离需求，和能力设计出来的，一定是不行的；逐步按照需求来进行迭代，还是尽可能的按照十年产品规划设计，免得过早碰到设计瓶颈，在下一个迭代大的重构；需要进行平衡；

3.  公有云也好，私有云也好，作为基础架构的产品，feature可以少，但是必须稳定；稳定性是第一位的， 性能和稳定性和成本的三角关系，决定了一个cloud解决方案是否成功；

4.  云计算，从早期的虚拟化，就是一个大机变成好多小机，给到不同的业务，实现成本，隔离性和灵活性的综合（大机的稳定性一般都by design非常高，成本也非常高，所以要最大化利用机器），到现在的把许多小机器堆成一个大机器/大集群，所谓的DataCenter As A Computer（其中也掺杂着把一个小机器进一步拆小变成很多VM/Docker）;这个差别的背后，是成本和规模的驱动；

5.  为什么在要把整个Data Center的许多机器变成一个集群/逻辑机器的同时，还要把一个单机再同时拆分成很多的VM/Docker,是因为现代的主流 Java 应用，都无法充分利用一个机器的资源；某种程度上，软件栈的发展慢于CPU/10g+网络/Flash的发展。

6.  与计算，也是by design,把很多不reliable的单个机器，通过软件层面的各种failover预案，变成从提供的服务角度来讲，reliable的一个大的逻辑机器/服务；这个无论是大数据计算集群，还是app应用服务，还是存储服务，都是一个理念；计算通过retry route到另外一个服务；存储通过3分拷贝/Erasure code rebuild on read来提供稳定服务；MR通过重新计算来实现；