xp系统50天后停止服务

突然发现,原来这个时空也是流动的!黄家驹去世20年了,不老神话林志颖39岁了,还珠格格赵薇都当妈了,蜡笔小新之父死了,火影忍者就快结局了,XP还有不到两个月就停止服务了……十年前我们盼青春, 十年后我们致青春,真的开始老了。

1392728669401

据了解,4月8日以后,微软将正式停止对XP系统 包括Office 2003的服务支持,微软官方网站对于XP用户的建议是换个新电脑,因为只有极少数的XP电脑可以支持直接升级至微软最新的Windows8.1系统。然而数据显示,我国XP系统的用户高达2亿,因此XP系统停止服务”引来高度关注。

1392728706760

XP哭着问Win8:”为何停止为我服务?”Win8无辜的看了看Win7。Win7顿时冒火了,”你看我干嘛?又不是我干的!”XP哭得愈加厉害了,骂道:”TMD,老子出来混的时候,你们还没有生呢!你们也有被停止服务的一天!我们走着瞧!”听见这话,Win7看了看正得意的Win8,内心一股恐惧袭来。

1392728722223

总归是长江后浪推前浪,前浪死在沙滩上!xp君,一路走好!这个时候很多爱国青年又跳出来说我们应该迅速拥有自己的操作系统,你确定我们真的能制造出”自己”的国产操作系统?

1392728849643

上周,中科红旗北京总部的大门上粘贴了一张最新的公告,通知全体员工,公司正式解散,员工劳动合同全部终止,公司进入清算程序。这家成立了14年之久的国产操作系统厂商最终是没能熬过这个冬季,比XP还先去一步。

国产操作系统厂商中科红旗破产清算

近日,著名开源专家、北大数学教授袁萌连续在个人博客上撰文,揭露国产COS操作系统的一些真相,指出上海联彤公司实际上并无实力自主研发国产COS操作系统,因此被戴上国产”桂冠”的COS操作系统只能算是一个”杂种”操作系统,不能算作中国操作系统”梦”!

1392728887580

cos说到底就是cosplay嘛~

中科红旗倒闭 国产操作系统研究画上句号

【PConline 资讯】2月10日,一家中科院领头的系统研究企业贴出清算公告:由于经营发生严重困难,董事会于12月13日决议即日解散公司,并成立清算委员会进行清算。公司与全体员工的劳动合同也在即日起终止。这家企业就是中科红旗,一个曾以挑战微软为己任成立的中国公司。自此,这家公司的国产操作系统的研究工作彻底画上了句号。

中科红旗倒闭 国产操作系统研究画上句号

事起缘由

2000年,这家以研究能挑战微软的国有操作系统为己任的公司成立,当时的公司董事长以及首席科学家是在中国科学院软件研究所副所长孙玉芳,秉着“中国必须拥有自主软件操作系统”共识,这家公司由中科院牵头成立。早在2004年,公司就宣布主营业务实现盈利,红旗Linux算是公司较为成熟的产品,中石油、邮政以及各大银行等多个部门上均有采用并予以付费。

公司的转折发生在13年4月,一封在Linuxeden社区上贴出的员工请愿书称:13年的4月,公司上百名员工被召集起来开会,总裁贾栋告诉员工们,公司资金链出现问题,当月工资无法如期发放。此外,由于资金链断裂,公司所处大厦一直处于无交费状态,12月大厦物业已经采取断水断电等措施,督促公司结算。

自此,员工工资拖欠持续至今,直到13年12月,董事会决议公司成立清算委员会对公司进行清算。

请愿书指出核高基项目为罪魁祸首

这封在技术社区发表的员工请愿书道出公司衰败的转折点。

2010年的核高基重大转型中,中科红旗承担了“通用桌面操作系统研发及产业化”主要课题,并和中科方德联合承担了4个子课题。按照规定来说,在政府拨款专项项目基金的同时,企业和地方政府也需要提供相近的资金支撑,然而在中科院承诺补齐资金的前提下,但最终没有补齐专项资金导致公司资金链断裂,很多市场员工随机出现了自垫资金的情况,公司高层为了实现项目,也将储备和支撑公司发展的资金全部投入到项目当中。

同时,中科院称,中科红旗的每年收入不超过1000万元,而2010年和2011年的主要收入来自核高基项目。在2012年,核高基项目资金用尽出现了资金链断裂问题。这跟中科院软件是无关的,并称中科红旗目前的问题是经营造成的。

随着资金链完全断裂,员工工资以及公司运营资金难以支撑,员工提出辞职。中科红旗股东达成一致,解散公司进入清算程序。

 本文来源:太平洋电脑网

从Google备份互联网看“数据安全”

【编者按】作者Todd Hoff是High Scalability创始人,为我们解读Google数据保密和数据安全负责人Raymond Blum的演讲。数据安全的一个重要工作就是备份,备份的容量扩展、存储备份的媒介、备份的效率……通过对互联网中庞大数据多样化、复杂的备份,使数据在任何情况下都能简单地还原、恢复。数据安全不仅仅是一个技术问题,它还受到现实的种种限制,做好数据安全,是任何一个企业都要考虑的问题。


CSDN推荐:欢迎免费订阅《Hadoop与大数据周刊》获取更多Hadoop技术文献、大数据技术分析、企业实战经验,生态圈发展趋势。


以下为译文:

Raymond Blum带领Site Reliability Engineers团队负责谷歌的数据保密和数据安全。当然Google从来都不会如实说有多少数据,但从评论上看目前还没到 yottabyte级(1YB=280B),不过也有很多exabyte级(1EB=260B)的数据了。仅Gmail就有接近exabyte的数据。

Blum先生在名为“ 谷歌如何备份互联网”的视频中解释,常见的备份策略对谷歌无效,原因听起来让人吃惊:它们大多是在努力用容量实现扩展。如果备份两倍多的数据,那时间、能源、空间也会消耗两倍,如果不这么做,就不能进行扩展。要让容量比支持容量的能力扩充更快,必须要有效率。从备份1exabyte数据转变到备份2exabyte数据,需要一个不同的计划。演讲的内容的主要关于Google是如何实现容量扩展的。

演讲的一些主要议题:

  • 从无数据丢失。甚至影响颇为不好的GMail停电事件也没有丢失数据,这远比备份许多磁带要复杂的多。数据从整个堆栈检索,每一层都需要管理,包括对人的管理。
  • 备份无用。还原你想要的部分,这是指还原系统而不是备份系统。备份是你要为还原付出的高昂代价。将工作转移到到备份上并使备份适当的复杂,是为了让还原尽可能的简单。
  • 不可以线性扩展。不可能有100倍的数据,你就能得到100倍的人力和机器资源。你只能去寻找使能力倍增的方法。自动化是提高利用率和效率的主要途径。
  • 冗余。谷歌的存储设备一直在老化。这当然不用说都知道,就像我们身体的细胞会死一样,Google并没有幻想着事物不会消亡,它只是为事物的消亡做好准备。
  • 多样性。如果你担心某个站点的位置不安全,那就把数据放在多个站点。如果你是担心用户错误,那就将用户交互与数据隔离。如果你想要避免软件bug的损害,那就把数据放在不同的软件上。从不同的供应商获取存储设备,以减少供应商的bug影响存储的数据。
  • 将人从繁琐的劳动中解放出来。通过GMail保留一封电子邮件有多少备份?这不应该是人关心的事情。通过GMail配置一些参数,系统会具体安排。这是不变的主题,高级别策略设置和系统实现了它。只有规范之外的事情发生才会需要人的参与。
  • 证明。如果你不试用它,那它就不会起作用。备份和还原就是不断的测试,以验证它们的工作的过程。

无论组织大小,都有很多要学习的东西。Blum先生的 演讲很风趣、信息量大、很值得一看。看起来他真的很喜欢工作中的挑战。

以下是我对这个演讲的注释,从中我们可以了解到许多不为人知的秘密:

  • 数据可用性必须是100%,不能有数据丢失
  • 统计学上,2GB文件中如果丢失了200K数据,似乎没什么大不了,但这个文件或许就不能用了,比如说可执行文件或报税表。
  • 数据的可用性比可访问性更重要。如果系统关闭,后果并不特别严重。但如果数据丢失,那就不是小事了。
  • 谷歌保证用以下所有可能组合保证数据安全:
  • 位置隔离
  • 隔离应用层问题
  • 隔离存储层问题
  • 隔离媒介故障
  • 想象一下移动滑块的情形。让软件像纵向滑块那样,让地址像横向滑块那样。如果你想要包含一切,你需要不同地址的软件层备份。你可以在不同的地址使用虚拟机。
  • 冗余不等于可恢复性
  • 制作多个备份不能保证数据不会丢失。
  • 多个备份对某些种类的停机是有效的。例如一颗小行星击中一个数据中心,而在一个很远的地方,你有这个数据中心的备份。
  • 如果你在存储堆栈中有一个bug,那把它复制到N个地方也没有用,因为bug破坏了所有备份。示例:请参阅GMail停机。
  • 相比小行星,代码中的bug、用户错误或已损坏缓冲区的写入,这些故障发生要多得多了。
  • 冗余对访问局部性有帮助。当你想要所有的数据引用与正在使用位置的数据尽可能接近时,备份是个不错的选择。
  • 因为这么多的备份,整个系统非常稳健
  • 谷歌的设备一直在老化。这不用说也知道,我们身体的细胞也同样会死。我们并没有幻想事物不会消亡,我们只是在为消亡做准备。机器也一直在损耗。
  • 冗余就是答案。合计一下,这要比单一的高质量机器更加可靠。单一机器可能会被一颗小行星摧毁。想要摧毁放在50个不同地点的机器就难说了。
  • 大规模并行系统的数据丢失几率更大
  • MapReduce在30000台机器上运行得很好,当然是在没有bug的前提下。一旦有bug出现,造成的影响也是成倍的。
  •  本地备份不能防止站点停机
  • 如果你的服务器机房中发生灾难性的破坏,那RAID也帮不了你。
  • Google文件系统(GFS),大约一年前,整个Google都在使用这个文件系统,它将RAID的概念又升级了一次。使用 编码技术将数据写入不同城市的多个数据中心,只需要N-1个数据片段,即可还原完整的数据。所以即使3个数据中心中一个停机了,也不会影响数据可用性。
  • 可用性和完整性是组织广泛的特点
  • 谷歌的工程师们,BigTable,GFS,Colossus都知道数据持久性和完整性是第一任务。很多系统需要检查并更正在数据可用性和完整性上的错误。
  • 多样性
  • 如果你担心某个站点的位置安全,那就把数据放在多个站点。
  • 如果你担心用户错误,那就把用户交互和数据隔离。
  • 如果你想要避免软件bug的破坏,那就把数据放在不同的软件上。从不同的供应商获取设备,以减少供应商的bug影响存储的数据。
  • 磁带备份真的很不错
  • 磁带好是因为它不像磁盘那样。如果可能他们甚至会使用打孔卡。
  • 想象一下假如你SATA磁盘的设备驱动程序里有一个bug。磁带就避免了这一问题。因为不同的媒介意味着不同的软件,这就增加多样性。
  • 磁带容量遵循摩尔定律,所以他们对磁带作为备份介质都很满意,虽然他们还在寻找替代品,现在很难说这些替代品是什么。
  • 磁带加密意味着有着不良企图的家伙们将很难从磁带中得到有用的东西。
  • 备份是无用的,真正需要关心的是还原
  • 在有人需要数据之前发现数据是否存在问题,你确定需要数据时再还原。
  • 持续还原。不断随机选择5%的备份,还原并对它们进行比较。为什么呢?因为需要在数据丢失之前查明数据是否还能用,找出存在的问题。
  • 自动比较。因为原始文件已更改,所以不能与原始进行比较。所以将校验码和校验码进行比较。把它带到源媒介、磁盘或闪存,或者其它的媒介。请确保数据可以做一次往返,自动比较是一直都在做的事情。
  • 故障率变化的警报
  • 你可能想要知道是不是有什么发生了变化。如果一切运行正常,那就没有必要告诉我了。
  • 预期会有一些失败,但别第一次尝试还原的文件失败就发出警报。
  • 假设首次尝试的失败率是N,第二次尝试的失败率为Y。如果故障率发生变化那一定是哪里出问题了。
  • 损坏
  • 磁盘随时都有可能中断,但因为你监视它,所以你能及时的了解到。
  • 要是磁带的话,只有你使用它的时候,才知道是不是坏了。虽然磁带保存的时间很长,但是你想在用它之前检测它是不现实的。
  • 不要将数据仅写到一盘磁带上。他们是墨盒,随时会有意外发生。
  • 向磁带写入数据时,编写器要保持数据不变,直到数据被完全写入。
  • 建立4盘完整磁带,然后通过XOR(逻辑运算)生成第五盘代码磁带。你可以失去5磁带的任何一个,也能恢复数据。
  • 现在告诉编写器它们可以更改源数据,因为数据已经到了到最终的物理位置,有冗余了。
  • 谷歌备份的每一bit数据都要经历这个过程。
  • 数以百计的磁带每个月都将丢失,并没有造成数据的丢失,就是得益于这个过程。
  • 假设当检测到一盘磁带丢失,通过使用连续还原和同级磁带重新生成另一个磁带,一切都没问题。在那种两个磁带都被损坏的罕见情况下,如果磁带上的受损的两个点相同,那数据就只好丢失了,只能在subtape一级完成重建。
  • 实现这些技术的成本很高,但是为了不丢失数据,很值得。
  • 备份是你为奢侈的还原付出的代价
  • 它是指还原系统而不是备份系统。还原是一个不可屏蔽的中断,他们胜过一切。
  • 让备份变得复杂而且只要需要就这样做。让还原变得快捷而且越自动化越好。
  • 恢复应该是傻瓜式、快速和简单。就算是一只猫也能完成还原操作。
  • 无论你休息得很好还是累的很惨,还原时才不会问你是不是准备好了。所以不要让人为因素决定服务数据还原的成功与否。
  • 大部分的系统都是这样工作的。
  • 数据源或许能够将数据存储一段时间,也许是在它备份之前的几天。但一旦备份完成,它随时都可以还原,而且还原得很快。
  • 为了使还原速度更快,不能将全部资源用于备份。花两个小时来读取磁带是不可行的。只写一半磁带,并行读取它们,这样你仅用一半的时间就可以获取数据。
  • 扩展是个问题
  • 当你有exabyte级的数据时,也会有现实世界的限制。如果你要复制10exabyte数据,然后它会花10周时间备份每一天的数据。
  • 考虑到分布在世界各地的数据中心,可供选择的方案并不多。你能给每个站点无限的备份容量吗?你会按区域划分所有备份吗?转移数据的带宽呢?你难道不需要带宽来为挣钱的流量服务吗?
  • 看看有关的费用。也有一些妥协方案,比如不是每个网站都有备份设施。必须平衡网络中的可用容量。怎样才能最划算?例如,只在有足够带宽的站点中进行备份。
  • 不能线性扩展
  • 你不能只是说想要更多的网络带宽和更多的磁带驱动器。驱动器中断的情况,如果你有10000个驱动器坏了,你需要10000个运算器来替换它们。你有10000个装卸码头来放磁带驱动器,直到一辆卡车把它们运走。这一切都不可以是线性的。
  • 虽然磁带库的数量提高了一个数量级,但参与其中的人并没有随之线性增长。
  • 比如早期曾有人预测,随着电话的增多,30%的美国人会被雇佣为电话接线员。显然他们没预见到未来的自动接线。
  • 自动化
  • 调度被自动化。如果你有一个服务,你说:我有一个数据存储,每N天我需要一个备份,在M时必须还原。内部系统完成这些事情:计划备份、运行还原测试和运行完整性测试等等。并且磁带故障的处理也是全自动的。
  • 人是无法看到这些的。也许有一天,你可能会问平均多少个磁带损坏了。或如果磁带破损率从每天100盒磁带变成每天300盒磁带时,就会发出警报。但在那之前不要问我:如果一天100盒磁带损坏是不是在正常水平内?
  • 人不应参与稳态操作
  • 装载和运输驱动器仍然是人类的活动。自动化的接口准备装运标签,得到RMA号码,检查已经出来的软件包,拿回执,如果出现故障,人才会进行干涉。
  • 库软件维护也类似。例如固件更新时,人不会将这些更新运行在每一个系统中,系统会自动下载这些更新,并进行验证、运行。这些常规的操作不需要人的干预。
  • 自动处理死机事件
  • 机器平均一分钟死两台。如果一台机器在进行MapReduce作业期间使用30,000机器,有一台机器死机了,那就不要告诉我了,处理完它,继续工作。找到另一台机器,转移任务,重新启动。
  • 如果有依赖关系那就先等待。如果你等得太久,就让我知道。你处理你自己的计划。这是算法的工作,不需要人为的操作。
  • 保持效率正向提高
  • 大幅提高利用率和效率。不能有100倍的数据就需要100倍的人或机器资源。
  • 2011年Gmail停机和还原,谷歌如何丢失数据又找回
  • 在周日的上午10:31他看到了一个网页,上面写:“Holly Crap打电话给xxx-xxxx”。关于中断要想了解更多,请看在 这里
  • Gmail的数据量达exabyte级别。这意味着大量的磁带。
  • 100%恢复并不意味着可用性也是100%,数据恢复要过段时间才能正常使用。
  • 一系列的bug和意外事件会产生在备份的过程中。即使是单元测试、系统测试和集成测试,对一些bug也是无能为力。
  • 从磁带中还原意味着大量的工作。还原时间和规模相关。还原gigabyte级数据可以在几毫秒到几秒时间内完成。还原200,000个收件箱中的几个gig,每个都得花去不少时间。
  • 把欧洲的几个同事叫醒,因为他们刚休息完、很清醒。这就是分布式劳动力的优势。
  • 从许多磁带还原和检验数据。不需要花几个星期或几个月时间,只需要花几天的时间。这使他们很开心。在类似情况下的其他公司花了一个月时间才意识到他们找不回数据了。需要采取一些措施以确保这个处理下一次更快。
  • 一个磁带驱动器需要2个小时来读。这些磁带分布在各地。否则在还原过程中,任何单一地点都不会有足够能力读取还原过程中涉及的所有磁带。
  • 压缩和校验码实际上不需要读取200K磁带。
  • 还原过程自那时以来已大为改善。
  • 优先还原
  • 已存档的数据可以在更重要的数据之后还原,比如你当前收件箱和发送的电子邮件。
  • 一个月内没用过的帐户可以等活跃用户优先恢复之后还原。
  • 备份系统被看作是一个巨大的全球有机体
  • 例如,不要只考虑GMail在纽约备份,因为如果该数据中心增长或收缩,备份需要适当调整规模。
  • 把备份看成一个横跨世界的巨型系统。备份时它可能完全是在别的地方完成。
  • 在磁带上的还原必须是在磁带所在的位置。但到它制作磁带时,数据可能在纽约而备份可能在俄勒冈州,因为在那里有容量。位置隔离是自动的,客户不知道自己的数据被备份在哪里。
  • 容量可以被迁移。只要有全球的容量和网络支持,磁带被放在哪无关紧要。
  • 拥有的数据越多,保存好它就越重要
  • 越大越重要的是他们的一条准则。谷歌曾经只是搜索引擎。现在它还是Gmail,还有驱动器、文档一类的东西。它现在变得更大也更重要了。
  • 有良好的基础结构
  • 处理问题时,有通用的解决方案再好不过了。在写MapReduce时可能从来没有想到它会被用于备份。但要是没有MapReduce,利用它进行备份的想法也是不会有的。
  • 扩展的重要性不言而喻,软件、基础设施、硬件、流程都要可以扩展。
  • 你不能说:我要去部署更多的磁带驱动器,就需要两倍的员工。你会雇这么多的人吗?你有两倍多的停车点吗?还有食堂房间?厕所?一切都要扩大规模。你会遇到一个瓶颈,然后寸步难行。
  • 证明
  • 别把什么事情都当作理所当然。希望毕竟不是一种战略。
  • 如果你不检验它,那就起不到作用。还原操作必须要检验备份。直到你结束了你还没证明什么。这种态度已发现有很多的不足。
  • DRT.灾难恢复测试
  • 每N个月都要模拟一场灾难恢复,看系统每一层的反应。
  • 如何做到无论灾难带走什么,公司都能生存下去?答案只有一个:必须学会适应。
  • 在基础设施和物理安全发现无数漏洞。
  • 想象有一个数据中心,一条通向数据中心的路,路上的卡车满载了备用发电机的燃料。那如果这条路不通了怎么办?最好有另一条路,另一供应商可以提供柴油燃料。
  • 必须要有供应链冗余策略。
  • 不同时间点不同地点不同软件堆栈中的冗余
  • 不要仅仅通过堆栈迁移数据。特别是暂停期间堆栈不同层中保留的数据。丢失的数据可以在其它地方找到。所以记住:时间、地点和软件。
  • 想一下Gmail的中断示例。如果备份损坏,数据怎样才能不会丢失?这是演讲时,听众的一个问题,他不想透露太多。数据是持续备份的。假设我们有下午9点的数据,假设下午8点出现损坏,但还没有做出磁带。这时损坏被停止了,软件被回滚到上一个工作版本。在一些还原点,所有堆栈中的数据是还在那里。这些就是磁带上的东西。磁带会备份这些东西。在前端上有,在日志中有。所有数据都可以实现重建。但要在所有数据被转移到另一个堆栈中之后再对其进行操作。
  •  删除问题
  • 不去重写磁带而只是删除数据的成本太高。
  • 一种办法是聪明地使用加密密钥。他没有告诉我们谷歌是怎么做的。
  • 当你信任你的同事,并给他们分配各自的职责时,一个巨型的组织就运作起来了
  • 相信他们能胜任自己的岗位。
  • 确定组织和软件接口定义得很好。执行层与层之间的检验测试。
  • 白名单和黑名单
  • 确保数据在安全的地方,保证数据不会在某些地方,保证数据位置多样性和位置独立性。
  • 最初并不是堆栈的功能。因为要满足政府的要求,必须添加进来。
  • 这些功能尽可能放在堆栈的最底层。填写正确的配置文件,就都完成了。

原文链接: How Google Backs Up the Internet Along With Exabytes of Other Data?(编译/毛梦琪 审校/周小璐)

走进支撑过8亿用户的Yahoo!数据中心

【编者按】Yahoo!是一家全球知名的互联网公司,拥有过8亿的活跃用户,提供了60多个全球化产品,分别部署在20多个国家或地区的数十万台服务器之上,然而雅虎全球的运维团队却仅有数百人。下面,我们通过雅虎北京全球研发中心高级系统运维工程师刘元概述的三个方面来了解雅虎的技术运维体系,剖析超大规模网络应用的运维挑战,走进Yahoo!数据中心!以下为原文:

基础设施

“工欲善其事,必先利其器”——需要支撑超大规模的网络应用,超大规模的全球基础设施是必不可少的。所以我们先看Yahoo!数据中心和全球的骨干网络有哪些特别的设计和考虑,来帮支撑超大规模的互联网应用。

图1 Yahoo自主设计的数据中心

首先通过两张图片(图1)来了解Yahoo!数据中心。我们的数据中心大多是自主设计和建造的,尤其在北美地区,我们自主设计并建造了三个超大规模的数据中心。这三个数据中心初期设计的容量均为20兆瓦,大概可容纳25000到30000台服务器及相应网络设备,并均有能力通过后续容量扩展至50兆瓦以上。

如果有参观过国内数据中心,或者有数据中心建设经验的同学可能会有所了解。影响数据中心建设的最主要因素往往不是网络带宽,而是电力和制冷。所以,雅虎通过近20年的经验积累,在这两方面沉淀了大量的专利技术以提高数据中心的密集度。我们自行设计机架及其电源模块以保证所有机架都能满负荷工作,同时实现所有电源的远程网络控制,这样可以有效的提升可维护性,降低现场工程师的工作负担。满架的服务器机架还有另一个好处:所有的服务器都是前吸冷风,后排热风,我们将服务器机架相对排列(面对面,背对背),这样就可以实现冷热风道的隔离,甚至完全密封热风通道,促使冷空气在均匀通过所有服务器散热后,由热风通道排出。这样不仅降低了制冷面积,还提升了散热效率。通过建设超大规模的数据中心,我们不仅增加了数据中心的密集度,提升了单个数据中心的计算能力,满足了日益增长的超大规模应用需求,同时还能提升数据中心现场工程师的管理效率,降低维护成本。此外,我们也不断聚焦新技术的采用以降低能源消耗。我们数据中心通过精心的设计,实现PUE(能源使用效率=总体能源消耗/IT设备能源消耗,越接近1代表能源效率越高)仅为1.08的业界领先水平。

除了数据中心是我们自行设计并建造的,我们全球的骨干网络也是自主设计。我们通过自行铺设光缆或租用运营商网络,构建了自己的Yahoo!全球骨干网。所有的网络设备都由我们的网络运维团队管理,核心网络均是多链路冗余,实现单点网络故障的自动转移,而不依赖网络运营商提供的SLA。

图2全球骨干网络示意图(不代表Yahoo!全球骨干网络设计)

我们的全球骨干网络均为高带宽互联,区域内我们提供10Gbps-40Gbps乃至北美地区的200Gbps互联带宽,洲际间也提供20Gbps的多链路冗余。骨干网络主要是传输雅虎内部数据,分发应用所需的数据到全球所有数据中心,收集全球用户访问数据到后端计算网格进行汇总和计算。

Yahoo!全球骨干网络除了与传统运营商网络互联互通,以方便最终用户能通过其运营商网络快速接入雅虎的各项服务,同时我们还与其他的大型互联网公司有交换网络连接,这样我们与其他大型互联网公司间的数据交换(如邮件数据交换)即可通过我们的交换网络传输,不再依赖于运营商网络。这样不仅提高了交换能力,更大范围降低对网络运营商的依赖性。

技术生态圈

有了世界顶尖的硬件环境,软件环境也不可少。下面我们着重介绍下Yahoo!的技术生态圈,看看Yahoo!使用了哪些产品和技术来支持大规模网络应用。

在雅虎内部构建一个超大规模应用其实并不是那么的复杂,因为我们已经提供了一整套完整的技术体系来帮助开发人员快速建立起一个具有高可维护性的超大规模应用。

图3 Yahoo!数据中心技术生态圈

从这张图我们可以看到一个新应用在生态圈里和现有技术平台的关系:

新应用(APPLICATION)只需要更多的关注自身的业务逻辑。与应用密切关联的本地信息,我们有一些本地存储(LOCAL STORAGE)技术来供应用使用,比如关系性数据库MySQL、Oracle,存储Key-value型数据的MDBM和Memcache。另外,雅虎还提供了大量的平台服务(PLATFORM SERVICES)供我们各种应用使用。比如统一验证平台YCA来完成所有应用内及应用间的身份验证,统一防御平台Ydod来帮助我们识别并且隔离恶意/滥用的流量,用户信息服务UPS可以让应用方便的获取这个用户的相关信息,如地理位置,兴趣喜好等。个性化内容推荐服务Slingstone,可以直接向用户提供个性化的雅虎内部及合作伙伴的内容信息。另外新应用还能方便快捷的接入广告平台(AD SERVER),获取个性化推荐的广告。前端应用收集到的各种应用相关信息(如浏览点击数据),通过我们构建在全球骨干网络之上的数据高速公路(DATA HIGHWAY)这一统一数据通道,及时地回传到雅虎全球最大的商用Hadoop群集。在Hadoop群集上不同应用及平台服务根据各自的需求,处理对应的数据,并将处理好的数据在通过雅虎全球骨干网络分发到各个数据中心的服务端,以方便前端应用的调用。同时Yahoo!在云端(THE CLOUD)还提供共享的云存储(STORAGE),以方便全球化应用的同步和调用各种共享数据。

除了这些常见的技术来帮助快速构建超大规模应用,我们还提供了大量的技术和产品来进行高效的运维和管理:

  • 主机信息管理系统:通过主机信息管理系统管理所有系统硬件信息,如CPU、内存、硬盘、网卡地址、Console接口、电源接口、物理位置等。
  • 角色配置管理系统:主要是把主机根据角色分成不同的组,不同角色的主机会应用不同的配置。不同角色的主机有不同的运维团队、系统配置、应用配置等。
  • 网络设备管理系统:包括交换机上的访问控制列表、负载均衡设备的配置、全球负载均衡配置,以及访问状态数据的统计。
  • 统一的监控平台:用于从不同层面进行监控,我们有所有主机系统数据的监控,也有基于服务可用性的监控。然后我们也有访问量、访问延时等应用层面的数据监控,并可以和历史数据进行比较。

所有的这些平台大多都是雅虎运维团队自行开发和维护的,更贴合Yahoo!的使用体验,帮助对超大规模的主机进行统一和高效的管理。

运维团队

前面的两条分别是硬件和软件环境,除了一流的硬件和完备的软件环境,能够实现高可用性大规模应用的核心,还是人。所以我们在最后,会给大家介绍雅虎的全球运维团队是如何工作的。

在Yahoo!我们的运维团队除了基础设施的Operation团队,如数据中心现场工程师(SiteOps)、网络运维工程师(NetOps)、基础设施(DNS、DHCP等)运维团队(InfraOps)和安全团队(Paranoid)等。我们还会按照产品线划分出Service Engineer团队,来支持这项产品的应用运维。

SE(Service Engineer)团队和大部分公司的系统运维工程师一样,会负责生产系统维护,如部署应用、监控报警、配置管理、变更管理及故障管理。除此之外,在雅虎SE团队会更多的深入了解应用。

图4 团队协作

从产品设计之初,我们就会和产品经历及研发团队共同讨论系统架构设计,确保开发团队将要实现的是高可用性、高可扩展性及高可维护性的产品。产品测试阶段,我们也会和测试团队保持密切的沟通,使测试环境能够最大程度模拟生产环境的各种场景,以保证我们产品经过了完整有效的测试。系统上线前,我们还会和各个团队评估整个产品的可维护性,并确定应用的容量规划及其故障转移策略,确保SE团队充分了解如何在生产环境中维护该项产品。由于不同的团队可能在不同的国家和地区,所以只有更紧密的全球化协作,才能为用户提供一个高可用性、高可维护性的全球化产品。

产品上线以后,才是产品整个生命周期的开始,我们需要确保产品在其设计的生命周期内,都能够按照我们的预期提供高可用性的服务。所以在日常维护中,我们会和产品及研发团队一同分析产品运行状态,分析总结各种故障,不断的修正已有的Bug,提供新功能的建议与意见。根据各地用户分布及产品的运行状态,修正我们的容量规划及故障转移策略,进一步提升用户体验。

结语

以上只是雅虎在超大规模应用运维体系的简单概述,并没有太多的技术细节,瑾作抛砖引玉之用。雅虎全球运维团队的工程师利用他们的智慧,不断创新,一一应对各种挑战,完成一个个不可能完成的任务。