基于云计算技术构建多公有云系统部署实践

构建多公有云系统部署实践今天的话题•我们的目标是什么？•实现业务目标过程中遇到了什么问题？•我们是如何思考的？•我们是如何实践的？•我们下一步的计划是什么？••单数据中心，VMWare环境宕机4小时•切换云供应商•再次宕机12•单云供应商•宕机6小时34•再找一家云供应商？？？我们如何走到这一步？从宕机中学到的几件事（1）•供应商SLA不是保证不宕机，而是索赔的依据SLA99.95%$$从宕机中学到的几件事（2）•小范围宕机几乎不可避免1000台服务器64GBMem24小时无内存故障内存颗粒无故障工作＝87.6年从宕机中学到的几件事（3）•大范围宕机发生可能性依然存在“不宕机是核心需求”“如果一朵云宕机不可避免那就把应用部署到多个云上”目标•多数据中心多活•节省成本、可负担的解决方案•在灾难发生的过程中，如果无法达到完全可用，则至少应该保证部分可用：•••部分业务功能可用部分客户业务可用部分数据可用•尽量少的人工干预DataAppAppAppAppGIT/AnsibleAppAppGSLBGIT/AnsibleGIT/AnsibleUserAppUserAppGSLB301Data？DatamasterDataslaveMaster/SlaveDatamasterDataslaveMaster/SlaveAppAppDatamasterDataslaveAppMaster/SlaveApp(Write)xAppDataslaveMaster/SlaveApp(Write)Datamaster•如果设计目标是随时保持2分数据拷贝，那么slave宕机的情况下，master应不能写入DatamasterDataMasterMaster/MasterAppApp•需要假定网络可靠（拜占庭将军问题）•Master越多越慢，代价越高，不可扩展•适合单数据中心内部，可以用来解决局部故障•跨数据中心则可能需要投入专线DatamasterDataMasterMaster/Master/MasterAppAppDatamasterAppMaster/Master/MasterDatamasterDataMasterAppAppAppDatamaster1.允许任意一个站点宕机、断网的情况下保证依然有2个可用站点2.可以形成2:1的多数派解决数据不一致的问题3.超高的可用性实战之：找到合适的云不同云的性能云间的网络最后的选择Master/Master/MasterDatamasterDataMasterAppAppDatamasterApp•公网传输数据（专线成本过高）•允许1个云计算数据中心宕机•允许网络传输不稳定•允许时钟不同步•当数据差异发生时可以做到多数票PAXOSDatamasterDatamasterDataMaster://=WX4gjowx45EProprose(N,V)PaxosPG数据库Accept(N,V)orAccept(N’,V,’)orDenyChoose(N,V|V’)ProposeAcceptChoosePaxosPG性能问题X10Latency数据分类常见操作存储选择元数据（用户信息、权限、记账）CreateReadUpdateDeletePaxosPostgreSQL资产数据（云上资源资产信息）CreateReadUpdateDelete双实例数据库＋定期批量复制到从站＋资源实际状态定期更新操作数据（云上资源的操作日志）CreateAppendReadOSS和异步复制数据的分类处理SlaveMasterFrontPageConsoleAMETAOSSSlaveConsoleCMETAMasterOSSSlaveMasterFrontPageConsoleBMETAOSSGSLBSlaveMasterFrontPageConsoleAMETAOSSSlaveConsoleCMETAMasterOSSSlaveMasterFrontPageConsoleBMETAOSSGSLBSlaveMasterFrontPageConsoleAMETAOSSSlaveConsoleCMETAMasterOSSSlaveMasterFrontPageConsoleBMETAOSSGSLBSlaveMETAMasterOSSSlaveMasterOSSSlaveMETAMasterOSSProxyProxyProxyMETA尚需解决的问题•paxos_pg事务性的问题•paxos的算法的数据代理？？？•异地数据中心部署的可能性•10～100万量级云资产管理总结•故障理所当然发生•打破Dev|Ops的边界，双方共同构建可用性•理解业务目标，按需架构设计•学会妥协