《《IBM永不宕机的服务器》.docVIP

湖南长沙 IBM 尹新 永不宕机的云服务器 一种基于服务器、集群存储和虚拟机的实现 主机可用性面临的挑战 主机存储不可用带来的风险 存储失败导致无法提供服务 存储无法恢复导致无法恢复服务 主机存储共享的困难 主机在物理机之间迁移需要灵活的存储共享机制 存储是服务的基础，存储的失败会带来灾难性的后果 虚拟机为存储提出了更高的要求 应对挑战的方案：传统存储 SAN+clusteredfs(gfs2/vmfs) NAS SAN/NASneverfail? expensive SAN/NASneverfail,maybe 传统的方案相对成熟可靠，能够解决传统IT领域的大部分问题。然而对于成本敏感 领域，比如互联网，并不是最好的选择 应对挑战的方案：分布式文件系统 一致性: 多数dfs实现为最终一致性 主机要求顺序一致性 性能 Dynamo:300ms@500iops/pernode 主机一般需要控制在20ms级别 DFS在web、分布式计算已经有大量成功的应用，然而多数DFS并不适合用来存储虚拟机镜像，主 要表现在延迟和一致性两个方面。 我们都知道，latencywillkilltheperformance 那么，我们能不能实现一个对虚拟机友好的DFS? 我们的方案：特性 为虚拟机优化的集群文件系统 Googlefilesystemlikearch 一致性： Sequenceconsistent 性能： Read:30ms avg @200iops/perdisk Write:10ms avg @70iops/perdisk 在一个32节点，192块盘的集群中，我们得到3万iops的读性能和5000iops的写性能 我们的方案：难度 强一致，高可用，低延迟的要求导致分区容忍性下降。限制了 集群的规模 单master构架带来性能瓶颈，需要尽量避免master操作 缓存一致性带来代码复杂度的挑战 CAP原理： 一致性(Consistency) 可用性(Availability) 分区容忍性(Partitiontolerance) 三者不可得兼。所有分布式系统都只是在这三种特性中取舍平衡而来 我们的方案：实现 分区： 较小规模的集群减少跨交换机带来的延迟(32node) 一致性： 所有副本writethrough 用oplockk解决缓存一致性 可用性： master一主多备 多副本 完全基于x86服务器的解决方案，存储和虚拟机和并在一组服务器中，尽可能减少网络延迟对性能 造成的影响 writethrough并不可怕，只要适当的优化，仍然可以获得良好的性能 盛大游戏案例 运行情况 2010年6月启动 100个测试节点（上海电信外高桥机房50台，北京联通亦庄机房50台） 虚拟机、存储共用一组X86架构服务器 虚拟化比例5:1 宕机实时处理时间大幅降低 盛大游戏案例 功能 通过UI进行虚拟机管理 支持虚拟机在线迁移 保证物理器宕机时虚拟机的高可用(可以自动在其它物理服务器上启动) 性能 大文件的顺序读写性能优秀 小文件的随机读写性能优秀 读写性能随集群服务器(存储节点)增加而提升 可靠性 在不大于数据冗余份数的前提下,发生以下故障时,系统仍可正常工作: 磁盘损坏 服务器网络中断,服务器宕机 宕机服务器所运行的虚拟机会在其它服务 器上重新启动) 在整个集群断网或断电情况下,做到数据安全不丢失,恢复后虚拟机仍可继续使用. 未来 新的构架 按照设备的物理分布划分存储域，在不增加延 迟的情况下缓解可小集群带来的管理问题 分布式的master，缓解单master的写性能问 题 美地森科技介绍 名称由来：美地森/MediaCenter 技术积累：始于2004年 成立时间：2007年5月 核心技术： 集群存储 初创成果：研发成功核心技术YFS集群文件系统，在此基础上实现 USS - Universal Storage System WHS - Web Hosting System 中国铁通 WSS- WebStorageSystem  中国移动 盛大游戏  美地森科技 安博教育  澳客网 湖南卫视 Thankyou 采用 坏, 机( 来: you！