IBM永不宕机的服务器.doc

湖南长沙 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的写性能问
题
来: