尽管Twitter的运营团队通过后台的流量图看到了即将到来的奥运会热潮对各项指标的拉升—这种可预期的、能带来大流量的事件,Twitter一般都会提前做准备,然而意外还是发生了。
在Twitter的预案里,如果这里发生了洪水、地震或者其他任何有可能导致服务器停止工作的问题,距离萨克拉门托965公里的另一个数据中心就会开始工作,它位于托管服务商Raging Wire旗下的一处建筑内,当然,情况也可能相反:Raging Wire这边出了问题,萨克拉门托开始工作。
无论哪一种情况,Twitter希望保证的是用户的不间断使用体验,即便是远在大洋彼岸的用户,也可以正常地把自己的消息Tweet出去,而不会感受到服务中断。
对于互联网公司而言,在线就是生命。Facebook早期迅速积累用户并不是由于它来自哈佛大学的好名声,而是它几乎从不宕机。这与当时强劲的竞争对手MySpace形成了鲜明对 照。
但在7月26日这一天,Twitter两个数据中心同时发生故障,全球用户的Twitter服务中止。Twitter提供的解释是由于“基础设施元件中的级联式漏洞”,但没有公布更详细的信息。在Twitter的成长史上几乎每年都会有多次重大宕机事故,宕机时网站就会显示出一幅有趣的:几只小鸟用线艰难地拉起一头搁浅的鲸鱼。
这是Twitter在两个月之内的第二次重大宕机故障。此前一次是6月21日,Twitter停止服务将近两个多小时。
Twitter负责工程技术的副总裁拉瓦德(Mazen Rawashdeh)事后解释说,Twitter在数据中心有两套能互相备份的数据系统同时出现了故障,这是基础设施上的“巧合事件”。通常情况下,如果一个系统出现故障,那么另一个将被紧急启用。而两套系统同时出现问题则比较少见,为避免类似故障重演,Twitter称计划对基础设施大幅投资。
数据中心问题一直困扰着Twitter。截至3月,Twitter已有14亿活跃用户,每天会发出34亿条Tweet。随着用户量和信息读写量的增长,Twitter迫切需要一个能自我完全掌控的数据中心。
Twitter早期租用第三方的数据服务,之后计划转向租用位于犹他州盐湖城的定制化数据中心,然而在去年该数据中心却出现了漏雨、电力不足等问题,于是Twitter不得不改变其计划,另谋他处。
在同一天,悲催的不仅仅是Twitter。谷歌的即时通讯服务Gtalk也在早上6点40分发生故障,并迟迟没有被修复。有用户报告,微软旗下面对企业客户的云服务工具Windows Azure在西欧地区也发生了宕机问题。
在宕机这段时间内,Gtalk用户发现虽然能够登录,但无法像以往一样正常发送信息以及进行语音、视频聊天。他们持续接到谷歌通过网页更新的问题修复状态通知,时间单位大约为半小时,而这一状态持续了近5个小时,算是谷歌史上罕见的长时间故障。习惯线上沟通的用户们不得不转向其他工具,有人说,接连两起宕机事件让他们有一种“全球停电”的感觉。
谷歌的数据中心分布全球且多达20多个,目前无法得知是哪一块数据中心发生了故障以致Gtalk瘫痪,谷歌至今也未解释具体原 因。
世界正在变成一个由数据洪流组成的存在,而整个世界也因几个重要信息节点而相互连接在一起。但即使是像谷歌这样著名的互联网公司也无法保证自己所有的服务全年都不出问题。
据谷歌称,其最受欢迎的服务Gmail电子邮件服务2010年全年宕机时间为7分钟,这已经是业内最短时间。根据Radicati Group的数据,电子邮件系统平均宕机时间为每月38小时。对比起来,Gmail可谓优秀。
一般造成系统不稳定甚至宕机的原因是多样的,开发安卓手机管理工具豌豆荚的豌豆实验室技术总监高磊对《第一财经周刊》介绍,在用户使用网站服务时,从用户输入信息,网络传送信息给网站服务器,网站服务器按照程序对用户要求进行处理,将结果返还用户,整个过程中其中一个环节出现问题就会导致网站的服务受到影响,甚至发生宕机而不可用。
引发问题的潜在因素多种多样,包括网站自身程序、服务器的 *** 作系统、硬件设备、机房与网络运营商等基础设施。
如果网站自身程序有Bug,可能会导致使用变慢,或部分功能失效;服务器的 *** 作系统也会出现漏洞,比如装有Linux部分版本的服务器就在本月因为闰秒问题而宕机;服务器硬件本身损坏,比如硬盘或内存都存在一定物理故障的机率。
而在基础设施上,机房停电或进水、遭到雷击等也会造成设备停止运行。最基础的问题是过热,因此大型数据中心旁边一般都有冷却装置。
6月底,美国一场风暴袭击了弗吉尼亚北部,大面积电力供应中断。而恰巧亚马逊在这里安置了US-East-1数据中心,因为停电,整个数据中心瘫痪。
亚马逊是业界领先的云服务提供商,其提供给网站以数据服务的云服务Amazon Web Services也因此一度中断服务。之后连锁反应便产生,使用其服务的Instagram、Pinterest、Quora、Netflix等知名网站也停止了服务,进而影响到各自的生态系统。
为避免风险,一些网络公司选择不把鸡蛋放在一个篮子里,设置多个数据中心,或者在使用云服务时同时选择多家供应商,当然,这也会增加成本。
据新浪微博技术总监杨卫华对《第一财经周刊》介绍,是否能稳定登录,响应的速度怎样,都会对用户的体验造成直接影响。新浪微博采用了分布式的架构,这意味着它没有把所有的服务器都放在新浪所在的北京,而是在国内多个主要城市都设置了数据中心,在突发事件发生后的流量处理和响应速度等各方面来保证用户体验。
你在宕机时体验到多少焦虑,稳定对于互联网公司就有多重要。
当越来越多的人被接入同一个网络─比如被称为“世界的脉搏”的Twitter,数据中心瘫痪的风险等级也相应增加。这些数据就存储在像加州萨克拉门托的大房子里,一旦宕机,空白也从这里开始。
1、自己建立云服务器,服务器上安装数据库中间件和大型数据库;
2、服务器上安装Web服务,建议使用Apache,不要使用IIS,后者稳定性和效率以及安全性都太差了,个人和网站玩玩还行,大规模应用是看不住的;
3、中间件用作向服务器读写和查询,另一端连接web服务进行数据通讯;
4、任何PC、手机等写个小程序,将当前时间、扫描面单的地点等设定进去,然后扫描面单号、将数据传递到服务器中间件,中间件将流水写入数据库,中间件要有重复条码处理功能和错误条码处理功能等,其他的校验在客户端程序完成;
5、根据数据库流水,客户就可以通过网站,查询数据库中针对某个面单,所有的不同地点的扫描时间信息了,也就是说知道物流快递运送进度了,精确到秒,因为扫描的时间精确到秒,复杂些的系统扫描时的那台计算机,还可以连接电子秤,将重量也采集进去,这样那一站发生货物重量缺少,就说明那个环节箱子破了,有东西漏出来丢失了;目前大部分快递公司还做不到这点;
以上系统其实对我们来说,是最低级的系统,仅仅是条码流水采集统计查询而已,唯一不同的是将局域网的东西放到了互联网上,要额外考虑安全、并发连接数、负载均衡、数据库性能、网络稳定性和通讯中断处理机制,很多都要放在中间件中完成。以上所有可以使用免费开源的来实现,也可以使用商业系统实现。
开源免费的可以用:Linxu服务器Mysql数据库Perl语言的CGI开发中间件Apache的Web服务php的查询网页php客户端数据上传网页;
付费的可以使用IBM的服务器套件:Webshare套件DB2数据库,微软的MS-SQLServer就算了,稍大点的快递公司、物流公司,一周的数据就能超过10W个包裹,数据超过10万个,他数据库的性能会比Mysql免费开源数据库还差劲,所以很多人宁可使用性能比他好价格比他低的Oracle数据库也不用他,就是因为查询和读写速度达不到,并且微软的MS-SQLServer很多时候就算你把服务器加到16个CPU,32G内存,20个硬盘,2个千兆网卡,依然性能上不去,此时已经和硬件无关了,是数据库自己能力不足,所以很多大型供应链管理系统不用微软的数据库,是有原因的。
服务器测试方法服务器测试方法分为两个大方面,性能测试与功能测试。
我们在性能测试方面采用了新的测试方法,主要分为文件测试、数据库性能测试与
Web
性能测试三个
方面。其中,文件性能与数据库性能采用美国
Quest
软件公司的
Benchmark Factory
负载测试和容量规划
软件,
Web
性能测试则使用了
Spirent
公司提供的
Caw WebAvalanche
测试仪。
一、性能测试
1
、文件性能测试方法
Benchmark Factory
软件能按照文件读写的关键指标定制事务。软件最大支持
1000
个虚拟客户。
本次测试环境包括
10
台配置为
PIII800/128MB
内存
/20G
硬盘以上的客户端,它们用来模拟虚拟用户。
控制台为配置是
PIII 850/128MB
内存
/40G
硬盘的
Acer
笔记本电脑。交换机为带有两个千兆
GBIC
接口、
24
个
10/100M
自适应端口的
Cisco 2950
,客户端与控制台通过
100M
网卡连到交换机上,被测服务器则通
过千兆光纤网卡与交换机相连接。
被测服务器均安装带
SP4
的
Windows
2000
Advanced Server
*** 作系统,在所有三项性能测试中都统一
RAID
级别为
5
。
在具体测试方案设置上,测试软件把决定文件读写 *** 作的关键因素设定为:读
/
写、随机
/
顺序、 *** 作
块大小、对象大小四个。在本次测试中,考虑到我们设有单独的数据库及
Web
测试项目,所以在文件测试
中,我们把目标确定为测试服务器基本的
I/O
性能,这主要由网络接口、系统带宽、磁盘子系统等几大部
分所决定。同时,从几部分的作用看,以大 *** 作块读写大对象文件,小 *** 作块读写小对象文件,较能反映
服务器最基本的
I/O
性能,即“大 *** 作块读写大文件”对系统带宽、缓存的考察,以及“小 *** 作块读写小
文件”对磁盘子系统、网络接口的考察。最终我们确定的四个事务是:
大文件顺序读写
(
*** 作块
8KB
,对象文件
80% 500KB
、
20% 1MB)
大文件随机读写
(
*** 作块
8KB
,对象文件
80% 500KB
、
20% 1MB)
小文件随机读
(
*** 作块
1KB
,对象文件
80% 1KB
、
10% 10KB
、
10% 50KB)
小文件顺序写
(
*** 作块
1KB
,对象文件
80% 1KB
、
10% 10KB
、
10% 50KB)
每个事务的用户数均以固定步长逐渐增加,
最大可增加到
1000
个虚拟用户。
其中,
“大文件顺序读写”
事务的用户数按照
40
的步长从
1
可增加到
400
个
(
测试至强服务器
)
或
200
个
(
测试
TUALATIN
服务器
)
,其
他事务则将用户数按照
100
的步长从
1
增加至
1000
。我们期望得到其在不同用户数时被测服务器的性能表
现。总体上其走势及峰值反映了该服务器的性能。每项事务均运行三次,每次之间被测服务器进行重启,
最终结果为三次平均值。
2
、数据库性能测试方法
“乘机安全小贴士”安全出行要重视
数据库性能测试同样使用了
Benchmark Factory
软件,测试环境如同文件性能测试。测试时,在被测
服务器上安装
SQL Server 2000
使用企业版。首先在被测服务器上创建新的数据库,通过使用
Benchmark
Factory
预定义的
Database Spec
项目向数据库中创建表,装载数据。在服务器端创建以
CPU
计算为主的
存储过程,通过
10
台客户机模拟用户、按照
40
个虚拟用户的步长递增到
400
个用户,执行该存储过程。
结果是以获得的每秒事务数
(TPS)
衡量服务器的数据库事务处理能力。
整个测试分为三次,
每次之间重新启
动被测服务器,最终取三次平均值作为评价结果。
3
、
Web
性能测试方法
Web
性能测试工具是由
Spirent
公司提供的
Caw WebAvalanche
。
WebAvalanche
模拟实际的用户发出
>编辑本段服务器定义
从广义上讲,服务器是指网络中能对其它机器提供某些服务的计算机系统(如果一个PC对外提供ftp服务,也可以叫服务器)。
从狭义上讲,服务器是专指某些高性能计算机,能通过网络,对外提供服务。相对于普通PC来说,稳定性、安全性、性能等方面都要求更高,因此在CPU、芯片组、内存、磁盘系统、网络等硬件和普通PC有所不同。
编辑本段服务器解析
服务器作为网络的节点,存储、处理网络上80%的数据、信息,因此也被称为网络的灵魂。做一个形象的比喻:服务器就像是邮局的交换机,而微机、笔记本、PDA、手机等固定或移动的网络终端,就如散落在家庭、各种办公场所、公共场所等处的电话机。我们与外界日常的生活、工作中的电话交流、沟通,必须经过交换机,才能到达目标电话;同样如此,网络终端设备如家庭、企业中的微机上网,获取资讯,与外界沟通、娱乐等,也必须经过服务器,因此也可以说是服务器在“组织”和“领导”这些设备。
它是网络上一种为客户端计算机提供各种服务的高性能的计算机,它在网络 *** 作系统的控制下,将与其相连的硬盘、磁带、打印机、Modem及各种专用通讯设备提供给网络上的客户站点共享,也能为网络用户提供集中计算、信息发表及数据管理等服务。它的高性能主要体现在高速度的运算能力、长时间的可靠运行、强大的外部数据吞吐能力等方面。
服务器的构成与微机基本相似,有处理器、硬盘、内存、系统总线等,它们是针对具体的网络应用特别制定的,因而服务器与微机在处理能力、稳定性、可靠性、安全性、可扩展性、可管理性等方面存在差异很大。尤其是随着信息技术的进步,网络的作用越来越明显,对自己信息系统的数据处理能力、安全性等的要求也越来越高,如果您在进行电子商务的过程中被黑客窃走密码、损失关键商业数据;如果您在自动取款机上不能正常的存取,您应该考虑在这些设备系统的幕后指挥者————服务器,而不是埋怨工作人员的素质和其他客观条件的限制。
编辑本段服务器分类
目前,按照体系架构来区分,服务器主要分为两类:
非x86服务器:包括大型机、小型机和UNIX服务器,它们是使用RISC(精简指令集)或EPIC处理器,并且主要采用UNIX和其它专用 *** 作系统的服务器,精简指令集处理器主要有IBM公司的POWER和PowerPC处理器,SUN与富士通公司合作研发的SPARC处理器、EPIC处理器主要是HP与Intel合作研发的安腾处理器等。这种服务器价格昂贵,体系封闭,但是稳定性好,性能强,主要用在金融、电信等大型企业的核心系统中。
x86服务器:又称CISC(复杂指令集)架构服务器,即通常所讲的PC服务器,它是基于PC机体系结构,使用Intel或其它兼容x86指令集的处理器芯片和Windows *** 作系统的服务器,如IBM的System x系列服务器、HP的Proliant 系列服务器等。 价格便宜、兼容性好、稳定性差、不安全,主要用在中小企业和非关键业务中。
从当前的网络发展状况看,以“小、巧、稳”为特点的x86架构的PC服务器得到了更为广泛的应用。
从理论定义来看,服务器是网络环境中的高性能计算机,它侦听网络上其它计算机(客户机)提交的服务请求,并提供相应的服务。为此,服务器必须具有承担服务并且保障服务质量的能力。
但是这样来解释仍然显得较为深奥模糊,其实服务器与个人电脑的功能相类似,均是帮助人类处理信息的工具,只是二者的定位不同,个人电脑(简称为Personal Computer,PC)是为满足个人的多功能需要而设计的,而服务器是为满足众多用户同时在其上处理数据而设计的。而多人如何同时使用同一台服务器呢这只能通过网络互联,来帮助达到这一共同使用的目的。
我们再来看服务器的功能,服务器可以用来搭建网页服务(我们平常上网所看到的网页页面的数据就是存储在服务器上供人访问的)、邮件服务(我们发的所有电子邮件都需要经过服务器的处理、发送与接收)、文件共享&打印共享服务、数据库服务等。而这所有的应用都有一个共同的特点,他们面向的都不是一个人,而是众多的人,同时处理的是众多的数据。所以服务器与网络是密不可分的。可以说离开了网络,就没有服务器;服务器是为提供服务而生,只有在网络环境下它才有存在的价值。而个人电脑完全可以在单机的情况下完成主人的数据处理任务。
编辑本段服务器硬件
其实说起来服务器系统的硬件构成与我们平常所接触的电脑有众多的相似之处,主要的硬件构成仍然包含如下几个主要部分:中央处理器、内存、芯片组、I/O总线、I/O设备、电源、机箱和相关软件。这也成了我们选购一台服务器时所主要关注的指标。
整个服务器系统就像一个人,处理器就是服务器的大脑,而各种总线就像是分布与全身肌肉中的神经,芯片组就像是脊髓,而I/O设备就像是通过神经系统支配的人的手、眼睛、耳朵和嘴;而电源系统就像是血液循环系统,它将能量输送到身体的所有地方。
对于一台服务器来讲,服务器的性能设计目标是如何平衡各部分的性能,使整个系统的性能达到最优。如果一台服务器有每秒处理1000个服务请求的能力,但网卡只能接受200个请求,而硬盘只能负担150个,而各种总线的负载能力仅能承担100个请求的话,那这台服务器得处理能力只能是100个请求/秒,有超过80%的处理器计算能力浪费了。
所以设计一个好服务器的最终目的就是通过平衡各方面的性能,使得各部分配合得当,并能够充分发挥能力。我们可以从这几个方面来衡量服务器是否达到了其设计目的;R:Reliability——可靠性;A:Availability——可用性;S:Scalability——可扩展性;U:Usability——易用性; M:Manageability——可管理性,即服务器的RASUM衡量标准。
由于服务器在网络中提供服务,那么这个服务的质量对承担多种应用的网络计算环境是非常重要的,承担这个服务的计算机硬件必须有能力保障服务质量。这个服务首先要有一定的容量,能响应单位时间内合理数量的服务器请求,同时这个服务对单个服务请求的响应时间要尽量快,还有这个服务要在要求的时间范围内一直存在。
如果一个WEB服务器只能在1分钟里处理1个主页请求,1个以外的其他请求必须排队等待,而这一个请求必须要3分钟才能处理完,同时这个WEB服务器在1个小时以前可以访问到,但一个小时以后却连接不上了,这种WEB服务器在现在的Internet计算环境里是无法想象的。
现在的WEB服务器必须能够同时处理上千个访问,同时每个访问的响应时间要短,而且这个WEB服务器不能停机,否则这个WEB服务器就会造成访问用户的流失。
为达到上面的要求,作为服务器硬件必须具备如下的特点:性能,使服务器能够在单位时间内处理相当数量的服务器请求并保证每个服务的响应时间;可靠性,使得服务器能够不停机;可扩展性,使服务器能够随着用户数量的增加不断提升性能。因此我们说不能把一台普通的PC作为服务器来使用,因为,PC远远达不到上面的要求。这样我们在服务器的概念上又加上一点就是服务器必须具有承担服务并保障服务质量的能力。这也是区别低价服务器和PC的差异的主要方面。
在信息系统中,服务器主要应用于数据库和Web服务,而PC主要应用于桌面计算和网络终端,设计根本出发点的差异决定了服务器应该具备比PC更可靠的持续运行能力、更强大的存储能力和网络通信能力、更快捷的故障恢复功能和更广阔的扩展空间,同时,对数据相当敏感的应用还要求服务器提供数据备份功能。而PC机在设计上则更加重视人机接口的易用性、图像和3D处理能力及其他多媒体性能。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)