1.1 寻找IDC数据中心
1.1.1 调研IDC准备
小鑫是一个刚刚大学毕业的学生，虽然在校期间管理过校园网，但在运维方面的经验很少，对北京的IDC情况也不是很清楚。于是迷茫的他只好上网搜索相关的IDC资料，可是搜索出来的结果却令小鑫失望，大多数都是广告性质的推广，看不出机房真实的情况。无奈小鑫只好一页一页地浏览，突然看到一个机房介绍的网址链接，打开链接发现是一本名为《高性能网站构建实战》的图书的内容简介。这本书的内容还真不少，包含一套完整的标准网站架构中所使用的应用。小鑫心想这本书正适合自己这种知识面不广并且经验又少的人，于是立即下单购买。
收到书后，小鑫立刻寻找机房介绍的章节，发现虽然不是介绍北京IDC提供商的，但书中所介绍的选择机房的性价比及计算带宽等方法还是很实用的。看完这章，小鑫在写购买机柜及带宽的量级时就不会找不到头绪了。
不过小鑫目前的问题还没有解决。他注意到这本书的作者在北京，猜想能写出这样书的作者肯定接触了不少的IDC提供商，所以小鑫决定给《高性能网站构建实战》一书的作者发一封求助邮件。
刘老师：
您好！
我刚刚拜读过您的《高性能网站构建实战》，感觉这本书特别适合我，很感谢您的这本书给我的帮助。可我还有个问题想请教一下，我这边的业务准备上线，需要在北京寻找一个线路质量特别好的IDC提供商。我在网上搜索过，不过大多都是推广性质的广告，再加上我本人对北京的IDC提供商不是很熟悉，所以麻烦您给我介绍几家。
谢谢！
发完邮件后，小鑫心里还有些忐忑。这封邮件不知道会不会被“过滤”掉，期待能有个好的回复吧。
小鑫一般吃完晚饭就没什么事了，有时候看看新出的电影大片，有时候学学Python编程。今天晚上比较特殊，他一直期待新的邮件。晚上11点多时，邮箱客户端显示新邮件的提醒，小鑫迫不及待地打开邮件，看来邮件没有被“过滤”掉，真是太高兴了。
小鑫：
你好！
首先感谢你对我的支持。
图1-1是中国互联网络带宽图，虽然不是最新的，但至少能看出来主要的节点是北上广，其他的地方我还真不清楚，北京的情况多少还是知道一些的。
我以前和联通的人聊过，细节就不多说了，只能说在北京每个区至少有两个出口，其作用是互相备份及流量的负载。估计你那边将来也不会仅仅是一个机房，到时候再考虑具体情况吧。
北京的IDC圈比较杂（代理商多、带宽种类多），机房的硬件条件我就不多说了。仅有几个大牌的IDC公司自建了多处机房，其余的都是和电信或联通合作的，所以机房的硬件一般不用担心。有一些IDC自身品牌比较不错，但可能给你使用的线路并不是最好的（有一些商家确实没有好的资源，也有一些商家的部分地点资源不好），但费用还是一样贵。还有一些价格较低，但质量及服务确实也没什么保证。前几年各大运营商及IDC提供商都在拼资源、拼质量，最近都在拼各种服务及解决方案。不同的商家提供不同的服务。即使是相同的商家也会根据目标客户的规模来定制相应的服务，所以服务方面我也不好说什么。
我认识一个做游戏运营的朋友，他公司每年赚得不少，不过就是因为选择了大品牌的IDC，所以近一半的利润都给了IDC公司。当然，我说这个只是提醒你一下，你也可以和公司建议一下，选择性价比高或者适合自己公司的IDC即可，不一定非要选择大品牌。
整个北京线路的出口在各区就那么多，所以你在选择IDC的地点时也要注意。因为很多商家都有自己的IDC环网，走的出口不是当前地区而是另外一个区的，目的是为了节省成本。还有一些提供商，测试时给你提供好的线路，但当你实际使用时，给的又是另一个线路，所以最好选择信誉度较高的提供商。
还有一点要注意的是，有很多提供商最初只是和你说线路的费用，并不和你谈上下行的比例。一般情况下我们谈的都是1:1的线路（上下行比例是1:1）。但如果你不问，等到签合同时会和你说是2:1或者是10:3，这样你就会花1:1线路的钱却用着不等价的线路。这一点很重要，一定要注意。
另外除了带宽，还有机柜。机柜唯一要关注的就是电。至于外表就不多说了，机柜最起码外表看着要正规，但有一些自建机房的机柜都算不上机柜，只能算是机架吧。供电不过7A，价格可是相当不便宜，这就是大品牌啊……一般情况下，机柜分10A和13A的。这点你注意一下就行了。
我不清楚你公司的位置，如果在中关村的话，放在XXX地点也是不错的选择。去年我公司为了选择一个线路质量不错的地点，测试了7家IDC提供商，XXX那边的带宽是非常不错的。除了线路，这个地点离中关村也不远，打车半小时，方便维护。
还有一个地点是兆维的电信机房，我们原来的机房就是放在那里，可以说是一个比较稳定的地方了。那个位置不但电力有保障，而且线路带宽也是有保障的，很多其他地区的机房也是走这里的线路（这里有电信或者联通的出口）。不过兆维的提供商不是一般的乱，有的资源不知道已经倒了几手了，并且线路也有不是北京本地的。这些你和他们谈的时候最好能确认其资源来源。这里我给你推荐几家在兆维信誉比较不错的IDC提供商，像ABC、XYZ。
XXX和兆维这两个地点还是不错的，主要是看你们怎么去和提供商谈价格吧。当你和他们联系后，他们会给你介绍他们各地点的机房，建议你测试完后再去看看。理论上硬件差的不是很多，主要就是使用时间的长短。毕竟硬件都会有一个高频率故障期，这点注意一下即可。
除了资源和服务，一个IDC还需要具备一些资质，完整的资质包括以下几点。
（1）最新年检营业执照。
（2）中华人民共和国组织机构代码证。
（3）税务登记证。
（4）一般纳税人证明。
（5）ICP经营许可证。
（6）ISP经营许可证。
（7）ISO9001质量管理体系认证。
（8）资信证明（3AA）。
对于一个IDC提供商而言，只有具备这些资质才可以参加投标。当然，一般的IDC提供商只要有ICP和ISP资质也是可以经营的。至于机房的电，也要考察一下。没有发电机的一看就知道，主要是有些机房的发电机基本上就是一个摆设。机房的温湿度，你直接进机房感觉一下就行，多去几个机房就会有很直观的感受。
最后，再一次感谢你的支持。
小鑫看完邮件就觉得这信息量也太大了，先不说机房的地点，仅带宽就有这么多说道。小鑫顿时感到头有点大，要是没人提醒，谁能想到还有这么多注意事项，可真得要感谢刘老师了，不然被别人坑了都不知道。小鑫赶紧回了封邮件表示感谢。
第二天，小鑫刚想找领导汇报情况，谁知领导直接找到小鑫，然后说他了解到使用XXX那儿的人挺多，而且带宽质量也不错，让小鑫多联系几家兆维的IDC提供商去测试一下。小鑫想着，看来那边确实不错，不然也不会那么火。
1.1.2 IDC线路测试
小鑫找到了XXX和兆维的ABC、XYZ几家IDC提供商，通过见面了解了一些情况，然后就进入了测试阶段。不过小鑫仅知道可以使用ping命令测试一下大型网站，其他的就不清楚了。所以小鑫又一次给刘老师发了一封邮件。
刘老师：
您好！
又一次麻烦了，感谢您上次对机房的介绍和推荐。我们这边已经很顺利地和他们取得了联系并已进入测试阶段，但由于我个人对这方面并不是很了解，所以还得麻烦您和我说一下测试机房的一些事情，谢谢。
发完邮件后，小鑫在网上也搜索了一些测试机房的详细信息，可惜大多是无关紧要的介绍，所以也就很耐心地等待刘老师的邮件。
晚上，小鑫如期收到了刘老师的邮件。
小鑫：
你好！
这几家的IDC还是不错的，下面大概和你说一下手动的测试方法。这些方法是“开源”的且没有使用其他的第三方付费工具。
首先提供几个线路测试时需要的IP（这些IP以前用过，当然你自己也可以找一下）：
- 61.135.169.125联通；
- 218.30.108.232电信；
- 121.195.178.239教育。
然后我们开始测试带宽峰值的情况。
在机房A的一个服务器上创建一个大文件（最好是GB级），在另一个机房B的服务器上wget下载这个文件，看看一下载文件的速度能达到多少。当然机房B的带宽不能小于机房A，不然就不能准确地测试出机房A的带宽质量。假设机房B提供的标准带宽是5MB（标准带宽指的是上传和下载的速度比例为1∶1），机房A提供的标准带宽是10MB，这样机房B是测试不出机房A提供带宽的最大值的。还要注意的是，有一些IDC提供商为了线路的“保障”，提供的测试带宽并没有限制，或者说并不是按着你提出的要求，这样基本测试不出提供商的峰值及稳定性，意义不大。所以这种提供商是可以忽略的，因为这不仅仅是因为机房带宽的问题。
接下来，我们需要测试从所在机房出去的线路质量，大致有以下几个“开源”的方法。
最简单的就是ping。我在上面已经给了几个测试的IP，现在购买的机房线路大部分都是BGP多线，我们可以根据上面给的IP进行简单的ping测试，当然你也可以自己找其他的，上面的几个IP仅供参考。
这里要提醒你的是，有些提供商是禁用ping测试的，他们会让你使用tcpping这样的工具，但是我不建议你使用这类工具。因为tcpping这类工具是工作在四层TCP层，而ping是工作在三层IP层，所以你用tcpping来测试的话，结果有可能不如ping测试的准确。
测试得出的结果保存在类似“机房_线路_ping”这样文件名的文件中，因为测试不仅仅是一个机房一条线路。测试时间上至少是24小时，最好选在有节日的时间段里，因为这样可以测试到同机房的一些公司流量突然增加时会不会影响到其他公司，也从侧面测试一下IDC的稳定性。
如果测试时间覆盖了早晚及节假日的话，那么相对来说准确性会高一点。测试时间结束后需要找出测试时ping的最大值、最小值及平均值，做好记录以备对比测试结果时使用。
前面提到过测试带宽“量”的问题，这个测试是要说明一下带宽的“质”的问题。一些在同一地点的不同IDC提供商有时候带宽的价格相差很大，除了有个别是报价虚高的外，还有一些相对普通但报价低很多的提供商，这些提供商一部分是策略需要，也有一部分是带宽可能不是北京本地的。这些带宽是提供商从北京附近（如河北）的线路整合过来的，因为非北京的带宽会便宜很多，往往是北京本地带宽价格的1/4～1/3。
这样一来，提供商的成本会大大地降低。如果不经过测试，用北京本地的价格买了这样的带宽的话，不仅仅是使用了质量差的带宽，还损失了一笔不小的费用，所以测试是否是北京本地的带宽很重要。
我们第二个“开源”的方法是tracert。它是检测当前测试服务器通过几个路由后到达目的地IP的命令（它的具体作用和工作原理你自己搜索一下）。tracert测试虽然说不用像ping测试那样需要24小时一直不停地测试，但早晚这两个时间段还是一定要测试的。因为有一些IDC的提供商早晚走的路由是不同的，毕竟相对来说大部分的公司晚上用的带宽并不是很多。
建议根据上面的几个IP测试，把测试结果保存在文件“机房_线路_tracert”里，以便以后分析对比用。时间可以根据你的需要来定，我们需要查看每经过一个路由的IP是否为北京IP。
查询IP的脚本、数据库我已经放在附件里了，它的使用格式如图1-2所示。
这个数据库有段时间没更新了，你可以自己找一个最新的版本使用。这里统一用的是Python 2.7，其他的版本没试过，但理论上也是可以的。
特别强调一下，ping和tracert一定要多采集几天的数据。
另外，还有一个测试是查看数据从外部到IDC内服务器的。
这个可以请全国各地的一些朋友来帮忙（在QQ群里可以喊一声，如果你运气好的话会有很多人来帮你的）。这里给你介绍几个QQ群，如“Linux饭醉团伙”（QQ群号为5019224）、“系统运维专业群”（QQ群号为3902836）。你在这两个群里求帮助的话，会有很多人帮忙，使用的方法也是上面提到过的。
只是这种手工的测试可能不太尽如人意，因为人员、地点、时间、网络等各种不定因素，所以测试结果也不是很准确，但是用来做大概的评估还是可以的。如果你那边可以多地部署的话，就使用Smokeping。
Smokeping主要是监视网络性能，包括常规的ping、用echoping监控www服务器性能、监控dns查询性能和监控ssh性能等。底层也是以rrdtool作支持，其特点是画的图非常漂亮，网络丢包和延迟用颜色和阴影来表示。
最新版本的Smokeping支持多个节点的检测结果从一个图上画出来。比如从A、B两个监视点检测C点的ping效果，可以把A、B的检测结果在一个图上表示出来，便于比较。它的安装配置比较简单，我这里就不多说了，附上几张图你大致看一下，如图1-3到图1-5所示。
第三种只能是参考性质的测试，使用测试网站。你可以搜索一下相关信息，因为只是参考性质的，所以这里不过多地介绍。
再次强调，测试网站并不一定准确，只作参考。
以上的测试结果可以截图保留，以备对比使用。
以上是“开源”方法。不知道你那边是否限制比较多，还有一种是使用专业的测试方案。当然这种是收费的，并且价格非常贵。根据一些使用过的人介绍，使用第三方测试的话，效果几乎没有不好的，因为数据都是可以“修改”的，你懂的。如果你只是选择机房的话，不建议你用这些收费的测试。我介绍的这几家相对来说在行业内口碑还算是不错的，最主要的是质量好、线路有保证。
我这边当时测试的条件是Centos5.6_64位、10MB带宽、BGP多线、apache2版本。每一个机房的测试结果是都保存在一个Word文档里。
最后我向你推荐一个我自己编写的脚本，你可以从我的博客http://blog.chinaunix.net/uid-10915175-id-4998580.html中找到。它主要是用来分析访问一个站点的各项性能，如DNS解析时间、下载第一个包时间、传输时间等。
测试IDC线路大概就是以上这几个步骤，祝你顺利！
乍一看，小鑫就感觉头大，测试一个机房线路都这么麻烦。难道不是接上线部署了程序，打开网站速度快就行吗？这事儿以后找时间还得向刘老师请教。既然刘老师这么建议，相信也错不到哪去。明天到公司联系机房的人，让他们准备好相应的物品就开始测试。
刘老师：
您好！
非常感谢！通过您的介绍，我了解到北京大概的网络情况及IDC提供商的一些“手段”，这会使我们在选择IDC时可以避免很多的损失，再次感谢您。
另外请教几个问题，一个是怎么样把已经执行的程序放到后台；另外一个是如果把tracert的路由放到一个文本里，那么多IP，我是不是要一个一个地去执行您所介绍的方法……我这方面的基础比较差，麻烦您了。
感谢！
第二天一早，小鑫就看到了刘老师的邮件回复。
小鑫：
你好！
一般平时使用的命令行是ping xxxx的形式，不过当关掉SSH客户端（我使用的是SecureCRT）或者网络断开时，系统终端会收到HUP信号，从而关闭其所有子进程。所以一般的解决办法就有两种，要么让进程忽略HUP信号，要么让进程运行在新的会话里，从而成为不属于此终端的子进程。
nohup无疑是首先想到的办法。顾名思义，nohup的用途就是让提交的命令忽略HUP信号。所以一般在测试时，我常用的命令是nohup ping xxx & 这样的形式，如图1-6所示。
还有一种是子shell，这种方法确实不常用，直接看我给你发的截图吧，如图1-7和图1-8所示。
将一个或多个命令包含在“（）”中就能让这些命令在子shell中运行（更多的小技巧以后有时间再和你说）。从上面两张截图可以看到，执行命令的终端1是执行命令的终端，打开另一终端2查询出的结果是ping那个进程的父ID（PPID）为1（init进程的PID），这就说明所执行的命令不会受到终端1的HUP信号的影响了，你也可以关闭终端1再查询一下。还有一个命令是setsid，这里我就不和你多说了。
上面说的是命令前加上nohup或者子shell就可以避免HUP信号的影响。但是如果未加任何处理就已经提交了命令，想让其避免HUP信号的话就只能通过作业调度和disown来解决这个问题了。它的用法如下所示。
用disown -h jobspec来使某个作业忽略HUP信号。
用disown -ah来使所有的作业都忽略HUP信号。
用disown -rh来使正在运行的作业忽略HUP信号。
这里你需要注意的是，当使用过disown之后，系统会把目标作业从作业列表中移除，这时将不能再使用jobs来查看它，但是依然能使用ps -ef查找到它。
这里还有一个问题，因为这种方法的操作对象是作业，如果我们运行命令时在结尾加了“&”来使它成为一个作业并在后台运行，那么是可以通过jobs命令来得到所有作业列表。但如果并没有把当前命令作为作业来运行，就需要用Ctrl+Z组合键（按住Ctrl键的同时按住Z键）了！
Ctrl+Z组合键的用途就是将当前进程挂起（Suspend），然后我们就可以用jobs命令来查询它的作业号，再用bg jobspec将它放入后台并继续运行。需要注意的是，挂起会影响当前进程的运行结果。
如果在执行命令时已经用了“&”，则可以直接使用disown，如图1-9所示。
如果提交命令时未使用“&”将命令放入后台运行，可使用Ctrl+Z组合键和“bg”将其放入后台，再使用disown，如图1-10所示。
另外你提到的tracert所得到的IP归属地问题，测试出来的结果会有很多IP，虽然说可能有重复的，但数量还是会相当多。如果你一个一个查询的话，会浪费很多时间。不知道你对shell的了解程度有多少，整理出来的数据文件用shell脚本处理一下就可以。一般情况下tracert一次的结果如图1-11所示，将其保存在一个文件中，然后配合AWK和for就可以得出结果，如图1-11和图1-12所示。
这些是比较基础的内容，建议你多了解shell基础知识。shell方面的知识多而杂，需要花一些时间才可以熟练地掌握。
1.1.3 IDC运营商选择标准
除了上面关于带宽方面的内容，再简单介绍一些选择IDC运营商的标准吧，以下是我收集的一些标准。
1．考察IDC机房运营的稳定性
（1）应该选择运营至少在8年以上的IDC。因为新机房管理制度不成熟，容易做机房环境调整（如变更IP、机柜搬迁、IDC机房公司变更）。
（2）调查同机房客户情况，IDC托管的客户如果比较混杂的话，很容易遭受攻击。同一机房（同一交换机）有客户经常遭攻击，自己的应用也会受到牵连。
（3）是否有正规的ICP资质，并要求提供IDC证复印件（有的IDC没有ICP资质，或借用其他公司的资质）。
（4）IDC备案是否方便？（有的机房因为资质问题很难做ICP备案）
2．考察IDC机房的带宽和机柜情况
（1）是不是多线机房，有没有自己的BGP自治域（一般小的代理商没有）？
（2）机房总的带宽是多少，增加带宽是否方便？
（3）是否存在带宽复用情况，带宽复用率是多少？
（4）可扩充机房是否充足？一般一个大的运营商会将机房分为一期、二期等。
（5）机柜可以存放的服务器数量是多少？一般有电及数量的限制。
3．考察IDC是否便于维护
（1）如果不在同城，需要计算一线城市的交通是否便利，维护一次的成本是多少？
（2）机房是不是可以24小时进行维护？
（3）故障响应时间是多少？也就是当服务器发生故障时，我们最快到达机房所需要的时间。
（4）服务器及设备迁入或迁出机房，是否有专门人员协助？
4．考察机房的温、湿度及电力情况
（1）一般机房会配备大型的空调系统，所以在温、湿度方面都不是问题。建议直接去机房感受一下即可。
（2）一般每个机柜提供的是双路电，但机房最少是两路电。一般IDC跟用户说双路电的时候，指的是分别从两个变电站（同一供电局）过来的，但对于高可靠性的机房来说，分别从两个不同供电局过来的电才算是真正的双路供电。
（3）看看是否有UPS电源供电，该电源能支撑多久的供电？
（4）了解发电机的运行使用情况。
5．其他
至于IDC机房的位置、格局、消防及安全性等可在参观机房的时候，由机房相关负责人员来介绍。
小鑫按着刘老师的建议编写了ping和tracert的脚本，交给后台执行去了。第一步算是完成得差不多了。小鑫采集了几天的数据，然后进行分析就可以了。目前小鑫的公司没有其他的机房，Smokeping是用不上了。小鑫加了刘老师介绍的QQ群，发现群里从事运维工作的人很多。
这几天小鑫也搜索了一下测试机房及服务的网站，有ping、tracert、DNS、CDN的测试，网站测试的内容还不少。小鑫输入了需要测试的IP，分析结果也挺多的。全国各地的机房、IP归属地、相应的测试时间等内容还是挺全的，不过不清楚后台的具体操作，只是看最终结果有点儿不太靠谱，只能作参考了。
一周后机房的测试结束了，小鑫把相关的测试结果文件统一地分析了一下，各个IDC提供商的各种线路之间的对比相差不多。Wget下载时的“量”是没问题的，tracert所经过的线路也都是北京的线路。真得感谢刘老师提供的工具，不然小鑫要一个一个地查这些IP的归属地不得“累死”啊！
小鑫把这些测试的结果写了一封邮件发给了领导。小鑫印象中，tracert也就是查看经过的路由，其他的作用还真不记得了。原来tracent在测试机房的时候还挺重要的。小鑫回顾了tracent的原理，即向目标地址发送不同TTL值的ICMP数据包 ，来确定到访问目标地址所经过的路由时间及数量。
要求路径上的每个路由器在转发数据包之前至少将数据包上的TTL递减1，数据包上的TTL减为0时，路由器应该将“ICMP已超时”的消息发回源系统。这个命令使用NBT（TCP/IP上的NetBIOS）显示协议统计和当前TCP/IP连接，所以只有在安装了TCP/IP协议之后才可用。
小鑫在用tracert测试时，有时显示的是星号，如图1-13所示。小鑫知道是可以忽略且不会影响测试，但具体为什么还真不清楚。原来某些路由器不会为其TTL值已过期的数据包返回“已超时”消息，而且这些路由器对tracert命令不可见。在这种情况下，将为该跃点显示一行星号。这也是出于安全考虑，也许是网络问题没有回应，所以出现星号。
看过测试结果，小鑫的领导和各IDC提供商沟通后就和小鑫直接去机房实地考察了。机房的人员向他们介绍了机房的电、核心设备、温度、通风、线路走向等，也回答了他们提出的一些问题，比如机柜的扩展、双线路的备份、DDOS攻击所采取的措施等，结果还是很让人满意的。