《IDC机房管理与运维手册》.pdf

《IDC机房管理与运维手册》系列分享专栏

简介

互联网数据中心（IDC），由于服务器数量众多，并且要向多个企业、政府提供多方面全方位服务，其维护和管理就显得非常重要。本专题整理了IDC机房管理与维护的相关文章

，希望对大家有所帮助。

文章

浅谈IDC的流量分析

IDC运维之Linux服务器重启

多IDC的数据分布设计(一)

IDC扫盲贴——北京各大机房比对

IDC机房设备变更流程

IDC目前存在的问题和发展趋势

虚拟化IDC包含的业务内容

虚拟化IDC的高可用和高可靠性解决方案

IDC机房的温度、湿度、电压要求

如何管理好IDC机房？（一）

如何管理好IDC机房？（二） ----依靠技术还是管理

如何管理好IDC机房？（三） ----机房管理中的文档及文档管理

如何管理好IDC机房？（四） ----机房安全管理

ASA5585防火墙IDC机房上架记

浅谈IDC的流量分析

1. 背景概述

在上个世纪90年代中期IDC刚刚在国内兴起的时候，IDC的出口带宽还很小，后来慢慢地从百M扩展到千M，一直快速发展到现在的10G，甚至几十个G，接口类型也从以前的AT

M发展到现在的POS。出口带宽越来越大，IDC流量分析的基础组成部分--流量采集技术也随之一直在变化。 在百M和千M出口带宽时代，使用端口镜像技术就可以对IDC的所有

出入流量进行完整的采集，然而进入2.5G/10G/40G接口时代后，端口镜像、探针和旁路监测技术的流量全采集方式无疑部署越来越麻烦，部署的层级需要不断地往下移，需要部

署的点越来越多，造成部署成本高昂，这样的流量采集技术目前已经在IDC的实际应用中逐渐被淘汰了。 为了应对巨大流量背景下分析流量的来源和去向及流量的应用类别，设

备厂家们提出了FLOW的概念，像CISCO的NETFLOW，Juniper的CFlowd，HP/NEC/Alcatel/Foundry,Extreme等的sFlow，华为的NETSTREAM等等，尤其是CISCO的NETFLO

W已经在IDC里得到了广泛的应用。

2. 为什么需要流量分析

的DPI（深度包检测）；而各种FLOW技术则是设备按照一定的采样比进行网络五元组（源IP+源端口+目的IP+目的端口+协议类型）的统计，然后输出统计后的流记录。从IDC流

量的实际应用来说，这几种方式都有其应用的场景，比如SNMP技术采集到的交换机端口的接口流量可以反映网络内的流量分布和带宽占用情况，同时也可以反映设备的工作状

态，如丢包率，错误包率等。而端口镜像/探针/旁路等全流量采集技术则可结合深度包检测技术在自动监测IDC托管的各类网站、论坛是否含有非法、黄色的内容的场合下发挥独

特的技术作用。FLOW技术则在IDC的流量流向分析、异常流量分析等应用中独具扩展性。

4. IDC流量的７个关键呈现视图

那么从IDC流量分析的日常需求来看，要想帮助IDC真实地、更好地反映网络内的流量情况，流量分析系统需要具备以下的７个视图，这７个视图将会分别从不同的角度为IDC准

确分析流量提供直观的呈现。

2.1 流量流向视图

流量流向视图主要是结合AS域准确反映本地网络的流量的流向和来源，在这个视图中，将可以很直观地看出访问本IDC网络的流量主要从哪些省和哪些运营商处来，通过在本省

城域网的出口上分析流量，也可以很直观地看出本省的流量主要发送到哪些省和哪些运营商处去了，这些分析数据为IDC托管业务的发展提供了可靠的决策依据。

2.5 应用流量视图

应用流量视图反映的是IDC托管的应用的流量情况，如WWW，ＦＴＰ，视频，P2P等应用的流量分布情况。

2.6 拓扑流量视图

拓扑流量视图反映的是IDC的网络拓扑设备之间的流量分布和带宽占用情况。

2.7 异常流量视图

异常流量视图反映的是IDC的网络异常流量的详细信息，这里可以结合镜像等全流量采集技术将异常流量的内容抓下来进行分析，方便定位故障。

5. 流量预警模型

由于ＩＤＣ的网络流量增长迅速，常见的报警阀值式的策略配置在实际应用中意义不大，有必要建立新的流量预警模型来进行更有效的预警。结合前面的《关于网管软件中的预

警功能设计.doc》文章中的内容我们可以知道，基线预警的模型应用在这里是再合适不过了，基线预警的详细内容请参考前文。这里就不做过多的阐述了。参考：关于网管软件

中的预警功能设计.doc

正传。Linux虽然很稳定，但也避免不了重启（啥时候需要重启我也不知道，反正肯定有重启的时候）但是当你给IDC打电话让重启服务器后服务器具体多长时间启动起来你也不

清楚，还可能因为某种故障系统重启时根本无法正常启动。（有的IDC挺好，重启完毕后会在三层交换机上给你查IP-MAC，等启来后会给你打电话通知，有的是重启完就闪人，

正常不正常也不管）。下面我们看一下，当重启Linux后，我们是如何在第一时间知道系统已进入在线状态--------利用飞信，实现手机短信通知。

下载地址下载地址http://down.51cto.com/data/60031

飞信的安装及配置：

我们已经将飞信安装文件下载到了系统的tmp目录下

[root@MRTG tmp]# ls

fetion20091117-linux.tar.gz

[root@MRTG tmp]# tar zxvf fetion20091117-linux.tar.gz

解压完毕后会生成一个fx 目录，我们把这个目录移动到/usr/local/并改名为fetion

[root@MRTG fetion]# cp libACE-5.7.2.so libACE_SSL-5.7.2.so libcrypto.so.4 libssl.so.4 /usr/lib

测试飞信

[root@MRTG fetion]# /usr/local/fetion/fetion --mobile=158110***** --pwd=****** --to=158110***** --msg-utf8="test"

--mobile后面跟飞信ID

--pwd后面跟飞信的密码

--to后面跟收信息人的手机号码

--msg-utf8后面跟所要发出的内容

执行完上述命令后接收人手机就应该能收到一个内容为test的信息

[root@MRTG fetion]# vi /etc/rc.local

在文件最后加入以下内容，这样开机后就会自动运行飞信命令了

按Ryan的方法，多IDC实现有以下几种思路。

一、Master/slave

这个是多机房数据访问最常用的方案，一般的需求用此方案即可。因此大家也经常提到“premature optimization is the root of all evil”。

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

缺点：缺点：写操作存在单点故障，master坏掉之后slave不能写。另外slave的延迟也是个困扰人的小问题。

二、Multi-master

Multi-master指一个系统存在多个master, 每个master都具有read-write能力，需根据时间戳或业务逻辑合并版本。比如分布式版本管理系统git可以理解成multi-master模式。具备

最终一致性。多版本数据修改可以借鉴Dynamo的vector clock等方法。

优点：优点：解决了单点故障。

缺点：缺点：不易实现一致性，合并版本的逻辑复杂。

Vote: participant需vote结果给coordinator：accept or reject。

Block: 如果accept, participant锁住周六2pm-5pm的时间，不再接受其他请求。

Phase 2

Commit: 如果所有参与者都同意，组织者coodinator通知所有参与者commit, 否则通知abort，participant解除锁定。

Participant failure:

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

Coordinator failure:

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

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

ansaction, 这时候集群内实际上就存在不一致的情况，crash恢复后的节点跟其他节点数据是不同的。因此3PC将2PC的commit的过程1分为2,分成preCommit及commit, 如图。

(图片来源：http://en.wikipedia.org/wiki/File:Three-phase_commit_diagram.png)

从图来看，cohorts(participant)收到preCommit之后，如果没收到commit, 默认也执行commit, 即图上的timeout cause commit。

如果coodinator发送了一半preCommit crash, watchdog接管之后通过query, 如果有任一节点收到commit, 或者全部节点收到preCommit, 则可继续commit, 否则abort。

优点：优点：允许发生单点故障后继续达成一致。

缺点：缺点：网络分离问题，比如preCommit消息发送后突然两个机房断开，这时候coodinator所在机房会abort, 另外剩余replicas机房会commit。

五、Paxos

Google Chubby的作者Mike Burrows说过， “there is only one consensus protocol, and that’s Paxos” – all other approaches are just broken versions of Paxos. 意即“世上只有一种

一致性算法，那就是Paxos”，所有其他一致性算法都是Paxos算法的不完整版。相比2PC/3PC, Paxos算法的改进

P1a. 每次Paxos实例执行都分配一个编号，编号需要递增，每个replica不接受比当前最大编号小的提案