IDC机房的维护与运行

IDC机房的温度、湿度、电压要求2011-06-1916:38:16标签：IDC机房温度电压要求湿度原创作品，允许转载，转载时请务必以超链接形式标明文章原始出处、作者信息和本声明。否则将追究法律责任。/1724/591487机房温度：20-25摄氏度之间机房湿度：相对湿度40-70%之间机房电压：220伏另外，机房应该至少有2路以上的供电，至少有ups，最好能有柴油发电机，并能保证和供油站有协议。如何才能管理好IDC机房？我入行11年了，做机房管理工作将近6年，就如何管理好IDC机房谈谈自己的体会，希望能够起到抛砖引玉的效果，对从事机房工作的同行有所借鉴，也请同行多指点。机房管理的目的是什么？机房的管理有三个方面1保证业务正常上线2维护机房稳定，保证业务正常运转3根据业务需求，做出实时调整。要做好机房管理，应做好以下几个方面。1了解机房环境和资源这个是最基本的，所谓知己知彼百战不殆，熟悉机房环境，就是要做到知己。对机房的有关信息要做到了然于胸，如数家珍。比如机房总共有多少个机柜，使用了多少个，还剩多少；机房的电力情况怎么样；机房的空调情况怎么样；机房的网络资源如何，带宽和ip等。2一定要做好备份做好备份是使自己立于不败之地的最好的途径，是机房管理的一大法宝。比如，核心交换机突然坏了，如果你有配置的备份，换了新的交换机上去，就能很快回复。核心业务的数据库服务器彻底坏了，如果有备份，就不会损失严重，如果有条将，不仅要热备，主要核心数据建议要采取冷被的方式，刻录光盘，磁带库等。如果能做异地备份，那么就是碰到地震等比较大的灾害也能很快的恢复业务。3要有一定数量的备用设备机房最重要的一个特点就是要维持稳定，如果有设备故障，有备用的设备顶上去，是最快的恢复故障的方式。当然这个还要算经济成本，要取得一个平衡，最起码做到核心设备有备份。或者备份的机制，比如ha的方式。如何管理好IDC机房？（二）----依靠技术还是管理在机房管理中有两个派别，管理派认为要依靠严格的管理，明确和细致的制度，来达到目的；而技术派则认为应通过不断的技术进步来推动管理，提高效率。一般持有倾向管理观点的人，大多不是很懂技术，为管理人员出身。而技术派一般是有良好的技术基础，很多人就是机房出身。在实际工作中，两种类型的方法我都接触过，而且两种方法在现实中我都看到过实例，都将机房管理的都很好。倾向管理的人，可以将制度做的很细致很明确，比如规定电源线捆扎到左边，网线捆扎到右边；每个机柜如何放置机器，1U的机器怎么放置，2U的机器怎么放置；规定ip标签具体粘帖到机器的什么位置等等。这样的好处是在最大程度上维持了机房的稳定运转。倾向技术的人，喜欢尝试新的技术，比如引进kvmoverip，使用iloimm远程管理，采用网络技术完成操作系统的安装等。这种方法最大的好处是提高了效率。当然，最好的管理方法是二者的结合，管理出身的人要学习技术，技术出身的需要学习管理。应用新的技术的同时，要制定明确细致的规范和制度。----机房管理中的文档及文档管理为什么需要文档？这个不难理解，文档是管理好机房比不可少的，良好的文档就是机房良好运行的体现。个人认为，判断机房文档管理好坏的标准就是，如果机房的所有管理人员全部离开，来了一批新人，很快就能上手，这就是成功的机房文档管理！机房文档应该包含以下内容1网络方面a网络拓扑图b网络设备配置文档，网络设备配置文档应该包含常用接入层交换机的配置模版及所有重要网络设备配置的备份。2设备信息a服务器、交换机、防火墙等硬件及配置信息，比如服务器信息应包含，品牌型号cpu内存硬盘等详细信息。b机柜空调电力等设备信息3网络资源信息aip信息，包括网络划分，ip使用和备用情况等b带宽信息4相关联系人信息a内部联系人信息b外部联系人信息5日常工作流程及规范a设备使用规范bip使用规范c带宽使用规范d机柜使用规范e设备上架操作规范f设备下架操作规范g机房常见问题维护手册文档如何管理1认真执行，并且有奖励和惩罚措施，要不就是空谈。2文档应根据实际变更及时更新和维护。对于上了一定规模的机房，应建立一个b/s的系统，维护机房的设备信息和文档更新。----机房安全管理机房大部分设备都在公网上，安全工作搞不好，轻则影响业务运行，重则可能会丢失数据，造成不可弥补的损失。安全管理的两个方面1每个人都要树立安全思维，只有在思想上引起重视，安全措施才会落实，要不就是采取一百层的安全措施，一切也是空谈。2技术方面根据我的经验，采取一下技术措施，可以有效实现机房安全管理。1)复杂口令，定期更换。如有条件建议采取令牌认证等认证手段。2）根据业务需求，win服务器采用ipseclin服务器iptables网络设备编写acl，关闭一切不需要的端口，最好能搞一个基础模版，然后根据不同的业务修改。3）远程控制服务尽量采取不常用的端口，比如修改远程桌面，vncssh等端口为高端口，同时要限制登录ip。4)重要数据走内网，应用服务器和数据库服务器之间通讯依靠内网，尽量不要走公网，一方面减小公网压力，节约带宽，一方面更安全。5）定期扫描和杀毒，尽量在凌晨或者非业务运行时间查毒，建议采取只查不杀的策略，如果检查去病毒或者木马，手工处理，因为服务器上一般都是重要应用，防止误杀造成损失。每个杀毒厂家都有免费查毒的服务，刚好可以利用，可以做简单的开发，能达到自动执行的目的更好。如何管理好IDC机房（五）----云计算和虚拟化在机房管理中的应用2011-06-2906:47:28标签：IDC机房云计算虚拟化机房管理idc原创作品，允许转载，转载时请务必以超链接形式标明文章原始出处、作者信息和本声明。否则将追究法律责任。/1724/598991相信为什么要在IDC机房中使用虚拟化，这个应该都没有疑问了吧，使用虚拟化技术，可以充分挖掘多核服务器性能，在按照机柜空间来收费的IDC，等于一台机器顶好几台使用，节约了空间，节约了设备，节约了费用。关于使用那种虚拟化产品，当然目前还是首推vmware了，从市场份额来看，目前市场份额还在70%以上。如果不想花钱，开源的kvm也是一个选项，kvm和vmwware的性能不相上下，但是管理便利性还有待逐步提高。理想的机房虚拟化架构应该是什么样的？应该使用云技术！不管是自建的IDC，还是出租给客户的IDC，如果能像使用水电一样的使用服务器，那对机房的管理就是一个巨大的提升。基础架构应该是按照一个或者多个机柜为一个虚拟化单元，每个单元包括多台的虚拟化物理机和两台或者多台存储，物理机用来做虚拟化，所有的虚拟化镜像和数据都存储到存储上。利用虚拟化的迁移技术来实现云计算，根据需要，虚拟机可以在物理机之间迁移。或者动态的增加虚拟机，增加虚拟机只需要编写简单的脚本，如果有实力，应开发一套管理系统，以方便的实现虚拟机的扩展和迁移。对服务器使用者来说，这都是透明的，他们只是需要想以前一样的来使用服务器就行，但是对IDC管理者来说，虚拟化和云计算将大大减轻机房工作，更好的提高机房效率。如何管理好IDC机房（六）----机房网络架构理想的IDC机房网络架构应该满足以下要求：1稳定保持业务稳定是最基本的要求。2有良好的可扩展性良好的网络设计能应该能满足业务的需求，随时平稳扩展3能够充分利用带宽和ip等资源在IDC里面，带宽和ip都是金钱，良好的网络设计应充分考虑这个因素。就个人经验，我建议机房采用二层的网络架构。建议需要不需要，全部架设内网。建议和isp之间采用2条线路以上的动态路由协议。网络架构采用只有接入层和核心层的架构好处是，一结构越简单，运行越稳定，二便于扩展三因为所有的接入层直连核心，便于灵活调整vlan，可以做到充分的利用带宽和ip资源。这种结构也有缺点，一是对核心层网络设备要求比较高，所以核心层应采取多台设备平衡冗余，而是要求所有的接入层有到核心层的布线。新机房可以按照网络构架要求来布线，对于老机房可以逐步改造，或者将原来的分布层交换机配置成二层，当作一个透明网桥使用，来达到目的。多IDC的数据分布设计(一)2010-02-0215:30:00标签：IDC数据设计原创作品，允许转载，转载时请务必以超链接形式标明文章原始出处、作者信息和本声明。否则将追究法律责任。/1539170/307085上个月跟某个朋友谈及多IDC数据同时读写访问的问题(tweet)，当时觉得有不少解决方案，但觉得思路还不够清晰。最近看了GoogleAppEngine工程师RyanBarrett介绍GAE后端数据服务的演讲稿TransactionsAcrossDatacenters(视频)，用Ryan的方法来分析这个问题后就豁然开朗。按Ryan的方法，多IDC实现有以下几种思路。一、Master/slave这个是多机房数据访问最常用的方案，一般的需求用此方案即可。因此大家也经常提到“prematureoptimizationistherootofallevil”。

优点：利用mysqlreplication即可实现，成熟稳定。

缺点：写操作存在单点故障，master坏掉之后slave不能写。另外slave的延迟也是个困扰人的小问题。二、Multi-masterMulti-master指一个系统存在多个master,每个master都具有read-write能力，需根据时间戳或业务逻辑合并版本。比如分布式版本管理系统git可以理解成multi-master模式。具备最终一致性。多版本数据修改可以借鉴Dynamo的vectorclock等方法。优点：解决了单点故障。

缺点：不易实现一致性，合并版本的逻辑复杂。三、Two-phasecommit(2PC)Two-phasecommit是一个比较简单的一致性算法。由于一致性算法通常用神话(如Paxos的ThePart-TimeParliament论文)来比喻容易理解，下面也举个类似神话的例子。某班要组织一个同学聚会，前提条件是所有参与者同意则活动举行，任意一人拒绝则活动取消。用2PC算法来执行过程如下Phase1Prepare:组织者(coordinator)打电话给所有参与者(participant)，同时告知参与者列表。

Proposal:提出周六2pm-5pm举办活动。

Vote:participant需vote结果给coordinator：acceptorreject。

Block:如果accept,participant锁住周六2pm-5pm的时间，不再接受其他请求。Phase2Commit:如果所有参与者都同意，组织者coodinator通知所有参与者commit,否则通知abort，participant解除锁定。Failure典型失败情况分析Participantfailure:

任一参与者无响应，coordinator直接执行abort

Coordinatorfailure:

Takeover:如果participant一段时间没收到cooridnator确认(commit/abort)，则认为coordinator不在了。这时候可自动成为Coordinator备份(watchdog)

Query:watchdog根据phase1接收的participant列表发起query

Vote:所有participant回复vote结果给watchdog,acceptorreject

Commit:如果所有都同意，则commit,否则abort。优点：实现简单。

缺点：所有参与者需要阻塞(block)，throughput低；无容错机制，一节点失败则整个事务失败。四、Three-phasecommit(3PC)Three-phasecommit是一个2PC的改进版。2PC有一些很明显的缺点，比如在coordinator做出commit决策并开始发送commit之后，某个participant突然crash，这时候没法aborttransaction,这时候集群内实际上就存在不一致的情况，crash恢复后的节点跟其他节点数据是不同的。因此3PC将2PC的commit的过程1分为2,分成preCommit及commit,如图。

(图片来源：/wiki/File:Three-phase_commit_diagram.png)从图来看，cohorts(participant)收到preCommit之后，如果没收到commit,默认也执行commit,即图上的timeoutcausecommit。如果coodinator发送了一半preCommitcrash,watchdog接管之后通过query,如果有任一节点收到commit,或者全部节点收到preCommit,则可继续commit,否则abort。优点：允许发生单点故障后继续达成一致。

缺点：网络分离问题，比如preCommit消息发送后突然两个机房断开，这时候coodinator所在机房会abort,另外剩余replicas机房会commit。五、PaxosGoogleChubby的作者MikeBurrows说过，“thereisonlyoneconsensusprotocol,andthat’sPaxos”–allotherapproachesarejustbrokenversionsofPaxos.意即“世上只有一种一致性算法，那就是Paxos”，所有其他一致性算法都是Paxos算法的不完整版。相比2PC/3PC,Paxos算法的改进P1a.每次Paxos实例执行都分配一个编号，编号需要递增，每个replica不接受比当前最大编号小的提案P2.一旦一个valuev被replica通过，那么之后任何再批准的value必须是v，即没有拜占庭将军(Byzantine)问题。拿上面请客的比喻来说，就是一个参与者一旦accept周六2pm-5pm的proposal,就不能改变主意。以后不管谁来问都是accept这个value。一个proposal只需要多数派同意即可通过。因此比2PC/3PC更灵活，在一个2f+1个节点的集群中，允许有f个节点不可用。另外Paxos还有很多约束的细节，特别是Google的chubby从工程实现的角度将Paxos的细节补充得非常完整。比如如何避免Byzantine问题，由于节点的持久存储可能会发生故障，Byzantine问题会导致Paxos算法P2约束失效。以上几种方式原理比较如下(图片来源：/space/transactions_across_datacenters_io.html)后文会继续比较实践环境选取何种策略合适。（PS:写完后在GoogleReader上发现本文跟王建硕最近发表的《关于两个机房的讨论》文章有点类似，特别是本文一、二方式。不过他的文章偏MySQL的实现，我的重点是一致性算法，大家可以有选择性的阅读。）背景资料Latency差异JeffDean提到不同数据访问方式latency差异NumbersEveryoneShouldKnowL1cachereference0.5nsBranchmispredict5nsL2cachereference7nsMutexlock/unlock25nsMainmemoryreference100nsCompress1KbyteswithZippy3,000nsSend2Kbytesover1Gbpsnetwork20,000nsRead1MBsequentiallyfrommemory250,000nsRoundtripwithinsamedatacenter500,000nsDiskseek10,000,000nsRead1MBsequentiallyfromdisk20,000,000nsSendpacketCA->Netherlands->CA150,000,000ns这个数据对于我们设计多IDC数据访问策略具有关键的指导作用，我们可以用这个数据来衡量数据架构来如何设计才能满足高并发低延迟的目标。

这份数据实际上对所有网络应用及分布式应用开发者都具有很大借鉴作用，数据需要根据访问频率尽量放在latency小的地方。1.2PC/3PC/Paxos模式在上文中提到，2PC/3PC相比Paxos有明显的缺点，因此最好不用于生产环境，这里就不再详述。

Paxos选择了CAP理论中的”Consistency,Partition”,需要牺牲availability。它可以在多个IDC之间实现强一致性复制。Paxos缺点IDC之间需要高速稳定网络一个2f+1个节点的网络中，需要f+1个节点完成事务才能成功。Throughput低，不适合高请求量的场合。所以大部分分布式存储产品并不直接使用Paxos算法来同步数据。2.Dynamo模式Dynamo论文中并未专门描述Dynamo算法是否适合多IDC场景，只有少量文字提到Inessence,thepreferencelistofakeyisconstructedsuchthatthestoragenodesarespreadacrossmultipledatacenters.Thesedatacentersareconnectedthroughhighspeednetworklinks.Thisschemeofreplicatingacrossmultipledatacentersallowsustohandleentiredatacenterfailureswithoutadataoutage.从上文看到，前提条件是“highspeednetworklinks”可能对国内的情况不太适用。假如IDC之间网络不稳定，那会发生哪些情况呢？Quorum算法中，如果要考虑高可用性，则数据需要分布在多个机房。双机房如NRW=322由于单机房故障后可能会发生3个点中2个点都在故障机房，导致出现数据不可用的情况，所以合适的部署是NRW=533，需要3个机房。大部分请求需要2个机房节点返回才能成功，考虑到多IDC的带宽及latency，性能自然会很差。Quorum算法在读写的时候都要从quorum中选取一个coordinator，算法如下Anodehandlingareadorwriteoperationisknownasthe

coordinator.Typically,thisisthefirstamongthetopNnodesin

thepreferencelist.Iftherequestsarereceivedthroughaload

balancer,requeststoaccessakeymayberoutedtoanyrandom

nodeinthering.Inthisscenario,thenodethatreceivesthe

requestwillnotcoordinateitifthenodeisnotinthetopNofthe

requestedkey’spreferencelist.Instead,thatnodewillforwardthe

requesttothefirstamongthetopNnodesinthepreferencelist.如果严格按照Dynamo协议，coodinator一定要在N中第一个节点，那在3个机房中将有2/3的请求需要forward到异地机房的coordinator执行，导致latency增大。如果对coodinator选择做优化，让client选取preferencelist中前N个节点中在本地机房的一个节点作为coordinator，这样会一定程度降低latency，但是会存在相同的key选择不同节点作为coordinator的概率增大，导致数据conflict的概率增大。同时在多机房模式下，Failuredetection容易产生混乱。Dynamo并没有使用一致性的failureview来判断节点失效。而是由每个节点独自判断。FailuredetectioninDynamoisusedtoavoidattemptsto

communicatewithunreachablepeersduringget()andput()

operationsandwhentransferringpartitionsandhintedreplicas.

Forthepurposeofavoidingfailedattemptsatcommunication,a

purelylocalnotionoffailuredetectionisentirelysufficient:node

AmayconsidernodeBfailedifnodeBdoesnotrespondtonode

A’smessages(evenifBisresponsivetonodeC’smessages).而最近非常流行的Cassandra基本上可以看作是开源的Dynamoclone,它在FacebookInboxSearch项目中部署在150台节点上，并且分布在美国东西海岸的数据中心。Thesystem(FacebookInboxSearch)currentlystoresabout50+TBofdataona150nodecluster,whichisspreadoutbetweeneastandwestcoastdatacenters.虽然在它的JIRA中有一个提案CASSANDRA-492是讲”DataCenterQuorum”，但是整体看来Cassandra并没有特别的针对对IDC的优化，它的paper[5]中提到Datacenterfailureshappenduetopoweroutages,cooling

failures,networkfailures,andnaturaldisasters.Cassandra

isconfiguredsuchthateachrowisreplicatedacrossmultiple

datacenters.Inessence,thepreferencelistofakeyiscon-

structedsuchthatthestoragenodesarespreadacrossmul-

tipledatacenters.Thesedatacentersareconnectedthrough

highspeednetworklinks.Thisschemeofreplicatingacross

multipledatacentersallowsustohandleentiredatacenter

failureswithoutanyoutage.跟Dynamo中的描述几乎是相同的。3.PNUTS模式PNUTS模式是目前最看好的多IDC数据同步方式。它的算法大部分是为多IDC设计。PNUTS主要为Web应用设计，而不是离线数据分析（相比于Hadoop/HBase）。Yahoo!的数据基本都是用户相关数据，典型的以用户的username为key的keyvalue数据。统计数据访问的特征发现85%的用户修改数据经常来源自相同的IDC。根据以上的数据特征，Yahoo!的PNUTS实现算法是记录级别的master,每一条记录选择一个IDC作为master，所有修改都需要通过master进行。即使同一个表(tablet)中不同的记录master不同。master上的数据通过Yahoo!MessageBroker(YMB)异步消息将数据复制到其他IDC。master选择具有灵活的策略，可以根据最新修改的来源动态变更masterIDC，比如一个IDC收到用户修改请求，但是master不在本地需要转发到远程master修改，当远程修改超过3次则将本地的IDC设成master。每条记录每次修改都有一个版本号(per-recordtimelineconsisitency)，master及YMB可以保证复制时候的顺序。Yahoo!的PNUTS实际可理解为master-master模式。

一致性：由于记录都需通过master修改，master再复制到其他IDC,因此可达到所有IDC数据具有最终一致性。

可用性：由于所有IDC都有每条记录的本地数据，应用可以根据策略返回本地cache或最新版本。本地修改只要commit到YMB即可认为修改成功。任一IDC发生故障不影响访问。论文中提到的其他优点hosted,notifications,flexibleschemas,orderedrecords,secondaryindexes,lowishlatency,strongconsistencyonasinglerecord,scalability,highwriterates,reliability,andrangequeriesoverasmallsetofrecords.总之，PNUTS可以很好的适合geographicreplication模式。记录publish到本地YMB则认为成功，免除Dynamo方式需要等待多个DataCenter返回的latency。如果发生master在异地则需要将请求forward到异地，但是由于存在master转移的策略，需要forward的情况比较少。极端情况，当record的master不可用时候，实现上似乎有些可疑之处，读者可自行思考。Undernormaloperation,ifthemastercopyofarecordfails,oursystemhasprotocolstofailovertoanotherreplica.However,iftherearemajoroutages,e.g.theentireregionthathadthemastercopyforarecordbecomesunreachable,updatescannotcontinueatanotherreplicawithoutpotentiallyviolatingrecord-timelineconsistency.Wewillallowapplicationstoindicate,per-table,whethertheywantupdatestocontinueinthepresenceofmajoroutages,potentiallybranchingtherecordtimeline.Ifso,wewillprovideautomaticconflictresolutionandnotificationsthereof.Theapplicationwillalsobeabletochoosefromseveralconflictresolutionpolicies:e.g.,discardingonebranch,ormergingupdatesfrombranches,etc.初步结论低带宽网络

PNUTSrecord-levelmastering模式最佳。

高带宽低延迟网络

(1Gbps,Latency<50ms)

1.用DynamoQuorum,vectorclock算法实现最终一致性

2.用Paxos实现强一致性后记本文从开始准备到发布时间较长，由于在多IDC数据访问方面目前业界并无统一的成熟方案，相关资料和文献也相对较少，而且对这方面有兴趣且有相应环境的人不多，短时间要提出自己成熟独立的见解也具有一定难度，本文仅包含一些不成熟的想法的整理，由于自己对文中的观点深度也不是满意，所以一直没有最终完稿发布。但考虑到最近工作较忙，暂时没有精力继续深入研究，所以希望公开文章抛砖引玉，同时也欢迎对这方面课题有兴趣者进一步交流探讨。ResourceRyanBarrett,TransactionsAcrossDatacentersJeffDean,Designs,LessonsandAdvicefromBuildingLargeDistributedSystems(PDF)PNUTS:Yahoo!’sHostedDataServingPlatform(PDF)ThoughtsonYahoo’sPNUTSdistributeddatabaseCassandra–ADecentralizedStructuredStorageSystem(PDF)Yahoo!的分布式数据平台PNUTS简介及感悟浅谈IDC的流量分析2008-12-1321:57:58标签：流量分析IDCSNMPNETFLOW端口镜像版权声明：原创作品，如需转载，请与作者联系。否则将追究法律责任。1.背景概述在上个世纪90年代中期IDC刚刚在国内兴起的时候，IDC的出口带宽还很小，后来慢慢地从百M扩展到千M，一直快速发展到现在的10G，甚至几十个G，接口类型也从以前的ATM发展到现在的POS。出口带宽越来越大，IDC流量分析的基础组成部分--流量采集技术也随之一直在变化。在百M和千M出口带宽时代，使用端口镜像技术就可以对IDC的所有出入流量进行完整的采集，然而进入2.5G/10G/40G接口时代后，端口镜像、探针和旁路监测技术的流量全采集方式无疑部署越来越麻烦，部署的层级需要不断地往下移，需要部署的点越来越多，造成部署成本高昂，这样的流量采集技术目前已经在IDC的实际应用中逐渐被淘汰了。为了应对巨大流量背景下分析流量的来源和去向及流量的应用类别，设备厂家们提出了FLOW的概念，像CISCO的NETFLOW，Juniper的CFlowd，HP/NEC/Alcatel/Foundry,Extreme等的sFlow，华为的NETSTREAM等等，尤其是CISCO的NETFLOW已经在IDC里得到了广泛的应用。2.为什么需要流量分析网管人员在日常的IT管理中，经常都会面临下面的一些情况：外部流量是从哪里来的?是否有不友善的攻击行为?本网的流量都到哪里去了?如何做实时的细节分析?本网内各个IP的流量使用情况如何?是哪些IP地址或是应用层协议造成网络的拥塞?在我的网络里各种应用层协议的流量比例各是多少?如何调配多条对外线路间的流量以达到负载均衡?如何预测网络流量的增长，在多久之后需要进行扩建?流量分析系统就是为了解决这些问题而产生的！！！3.IDC流量的采集方式单纯的从流量数据的采集方式上来看，可以分为SNMP，端口镜像/探针/旁路，FLOW，RMON等几种主要方式，其中SNMP主要应用于设备接口的流量数据采集，如采集某个交换机端口的流入流出字节数，包数等；端口镜像/探针/旁路主要应用于千兆以下的端口的全流量采集，这种方式下采集的数据可以进行数据包内容的分析，也即现在非常热的所谓的DPI（深度包检测）；而各种FLOW技术则是设备按照一定的采样比进行网络五元组（源IP+源端口+目的IP+目的端口+协议类型）的统计，然后输出统计后的流记录。从IDC流量的实际应用来说，这几种方式都有其应用的场景，比如SNMP技术采集到的交换机端口的接口流量可以反映网络内的流量分布和带宽占用情况，同时也可以反映设备的工作状态，如丢包率，错误包率等。而端口镜像/探针/旁路等全流量采集技术则可结合深度包检测技术在自动监测IDC托管的各类网站、论坛是否含有非法、黄色的内容的场合下发挥独特的技术作用。FLOW技术则在IDC的流量流向分析、异常流量分析等应用中独具扩展性。4.IDC流量的７个关键呈现视图那么从IDC流量分析的日常需求来看，要想帮助IDC真实地、更好地反映网络内的流量情况，流量分析系统需要具备以下的７个视图，这７个视图将会分别从不同的角度为IDC准确分析流量提供直观的呈现。2.1流量流向视图流量流向视图主要是结合AS域准确反映本地网络的流量的流向和来源，在这个视图中，将可以很直观地看出访问本IDC网络的流量主要从哪些省和哪些运营商处来，通过在本省城域网的出口上分析流量，也可以很直观地看出本省的流量主要发送到哪些省和哪些运营商处去了，这些分析数据为IDC托管业务的发展提供了可靠的决策依据。2.2子网流量视图子网流量视图可以很直观地呈现本地网络内的不同子网的流量，通过TOPN分析可以直观地反映子网的排名情况。2.3客户流量视图客户流量视图是从IDC的客户的角度来呈现网络流量的，可以很直观地呈现出每个IDC客户的实时流量排名及其应用的流量排名。2.4骨干流量视图骨干流量视图反映的是IDC的骨干网络设备之间的流量分布和带宽占用情况。2.5应用流量视图应用流量视图反映的是IDC托管的应用的流量情况，如WWW，ＦＴＰ，视频，P2P等应用的流量分布情况。2.6拓扑流量视图拓扑流量视图反映的是IDC的网络拓扑设备之间的流量分布和带宽占用情况。2.7异常流量视图异常流量视图反映的是IDC的网络异常流量的详细信息，这里可以结合镜像等全流量采集技术将异常流量的内容抓下来进行分析，方便定位故障。5.流量预警模型由于ＩＤＣ的网络流量增长迅速，常见的报警阀值式的策略配置在实际应用中意义不大，有必要建立新的流量预警模型来进行更有效的预警。结合前面的《关于网管软件中的预警功能设计.doc》文章中的内容我们可以知道，基线预警的模型应用在这里是再合适不过了，基线预警的详细内容请参考前文。这里就不做过多的阐述了。参考：关于网管软件中的预警功能设计.doc关于网管软件中的预警功能的发展2008-11-1711:45:37标签：网络故障网管IDC数据中心版权声明：原创作品，如需转载，请与作者联系。否则将追究法律责任。我们知道，根据国际标准化组织的定义，网管软件有五大功能，分别是故障管理，计费管理，配置管理，性能管理和安全管理。当然市场上的产品对这些模块可能是选择性的实现，但是一般来说，故障管理和性能管理是网络管理中的最主要的组成部分，也是各类网管产品都提供的核心功能。故障管理和性能管理功能中最重要的又是故障和性能的预警，一旦预警功能失效，出了真正的故障之后，损失已经造成，虽说亡羊补牢犹未晚，但总不如在故障出现之前，性能下降之前解决问题来的更有价值，损失更小。预警功能是如此重要，大多数的软件也在这块上下足了功夫，随着对网管的不断深入的理解，预警策略的配置也越来越灵活，除了报警阀值的自定义配置之外，很多网管产品都加入了报警时段、报警频次、报警方法、报警级别等概念，并可以将这些参数进行灵活的配置，单纯的从技术上来说，这样灵活的配置已经可以让网管人员任意的进行配置了，可以满足几乎所有的应用场合。然后，随着网管应用的深入，很多网管人员发现这种报警阀值的配置方法太繁琐了，不进行配置的话网管软件产生的网络事件又太多，从而导致网管软件不能真正帮助网管人员减轻日常网管的工作量，久而久之，网管软件中的预警功能就弃而不用了，庞大的网管软件就变成了一个偶尔用来实时监视的工具和领导来参考的一个门面。于是，各网管厂家开始推出“基线预警阀值配置”的概念，通过这个配置向导可以帮助用户快捷地配置好所有的策略。然而随着网络的快速发展，网络应用的层出不穷，很快这种预警策略配置的设计方法变得不再有效。网管人员发现，上个月还有效的预警策略可能在这个月就已经变得无效了。那么如何才能更有效地适应这种应用场景下的预警管理呢？“基线报警”的概念就这样被提出来了，基线报警的核心是通过日基线/周基线/月基线等概念结合一定的算法来动态生成当前的报警阀值，而网管软件本身无须进行相应的报警阀值配置，大大减轻了网管人员的阀值配置难度，有效地提升了网络事件报警的正确性。从上面我们也可以看出，网管软件中的预警配置这个功能从最早的单一阀值配置，逐步发展到灵活的预警策略配置，再发展到基线预警阀值配置，到现在流行的基线报警。一步一步地更好地满足了网管中对故障管理和性能管理更有效管理的需求。如下图所示：虚拟化IDC包含的业务内容2011-05-2713:07:15标签：VDC业务内容虚拟化IDC版权声明：原创作品，谢绝转载！否则将追究法律责任。虚拟化IDC业务就是一系列由供应商向用户提供的资源和资源集合的模版组合。这些业务模版都是一些资源和资源集合的抽象，用户可以根据自己的需求对这些业务模版进行配置订购。这些业务在经过用户订购以后将会生成的，和真实资源和资源集合一一对应的，就是业务实例也就是产品。所有的VDC中的资源包括网络，存储，计算能力以及应用业务，都需要以业务的形式向用户提供。任何VDC资源都可以按单个或多个有机整合的方式发布为VDC业务。一个完整的业务需要以下属性和内容：业务名称，业务编码，业务属性，业务权限，业务版本，业务费用，资源关联，业务内容关联（可选），部署信息，策略信息，SLA。一、VPSVPS（VirtualPrivateServer）是通过云计算技术将存储、硬件和网络等资源统一虚拟化为相应的资源池，从资源池分割成多个虚拟专享服务器的优质服务。每个VPS都可分配独立公网IP地址、独立操作系统、独立超大空间、独立内存、独立CPU资源、独立执行程序和独立系统配置等。面向客户群：中小企业、政府、企事业单位。二、弹性云主机弹性计算业务是一种按需分配计算资源的云计算服务。弹性计算业务提供了一系列不同规格的计算资源。这些规格参数包括：CPU性能、内存、操作系统、磁盘、网络。不同规格的计算资源有不同的价格。用户可以根据需要申请不同规格的计算资源。针对客户的突发性、临时性的大量计算和存储资源需求，为企业客户提供一个虚拟的弹性计算集群环境，实现用户动态的扩展或者缩减服务配置（CPU，内存，存储）以及增加或者删减弹性虚拟主机数量。完全采用动态分配管理，是项目或者事件形式促发整个系统的一种行为。能高效、迅速的调度资源，对系统的计算资源进行有效整合，使之可以应对客户业务的弹性需求。面向客户群：媒体、网络游戏开发商、中小型软件开发商、应用软件开发商、高校及科研院所。三、云终端云终端是一种低成本、免升级、易管理、便操作、强安全、高可靠的瘦终端型客户机，配合VDC云计算和云存储产品形成“终端+网络+应用”的组合型服务。能有效降低采购及运营成本。对于云终端：Ø满足可控的移动存储设备等外接口；Ø实现集中管理、单独授权的应用模式；Ø实现统一部署的操作系统和升级维护管理。面向客户群：金融、证券、教育等需要大量客户端的统一服务平台（如呼叫中心）、联通自身营业厅。四、在线云存储在线云存储通过云存储技术，整合并高效调度存储资源，满足客户的弹性使用需求。云存储不仅仅是一个硬件，而是一个由网络设备、存储设备