琴棋书画诗酒花,当年样样不离它,如今世道都变了,拿着光功把纤拉……
你拿着秋天的第一杯奶茶,嘴里唱着“大风天通州搬家到工体”,而我拿着电信工具包,在大风天通州拉纤到工体,很多人第一次来到工体的原因是看球,而我是因为这场大风,这场来自的通州的东风先是刮断了树枝,然后树枝又在和光纤的胡搅蛮缠中占据了上风,挂断了光纤,与此同时,一场万众瞩目的演唱会即将在工体举办,周边的道路实行了交通管制,人满为患,电信施工队进场抢修进展被严重阻碍,此时此刻,在NOC里面,从延绵不绝的电话声和不停闪烁的微信群证明着这条光缆的价值,我好几次几乎忍不住想告诉他你要接受现实,却常常因为被告知“再不修复就要投诉、就要索赔”这样一个现实而让我哑口无言……从不完全统计数据来看,客户机房通过IDC接入腾讯云服务的混合云场景的各类故障中,类似上面的专线自身的故障率占有很大比重,对于这个问题,接下来我们一起讨论下如何从专线建设初始防微杜渐
2.1 资源维度
建议选择光纤资源充足的提供商,如果有提供商告知你某一段链路受限于资源或者地理条件需要中转跳接,此时还是建议要努力和提供商协商一条端到端闭环的链路,避免这种情况发生
2.2 距离维度
你的IDC机房距离腾讯云接入点的远近不单单决定了专线费用,同时还决定了线路时延,而且还决定了这条线路的故障域的大小,链路越长受到不确定因素影响的概率越高,可想而知一条横贯东西或者纵观南北的链路发生故障的概率是远远大于机房内跳纤的,就近接入肯定是不二之选
2.3 容灾维度
双线容灾场景下,由于不同的专线提供商大多是有不同的物理链路铺设管道路径,所以在双线接入场景下还是推荐使用不同的提供商
2.4 政策维度
但是在你选择接入某个腾讯云POP点接入时,你最好联系你的客户经理,让他明确的告诉你腾讯云机房对于专线提供商的接入限制,例如某些接入点仅仅只允许某提供商接入,特别是非腾讯自建的租用机房这样的限制更为明显
2.5 成本维度
如果某线路提供商承诺以最大的优惠提供线路给你,那么这绝对是给你线路选择注入了一管强心剂,让你很容易的屏蔽掉上面提及的几个评判原则,此时你还是要保持慎重
3.1 少跳接
我们通过端到端选择线路资源充足的供应商一定程度上可以避免专线的跳接情况发生,但是对于你的IDC内部的网络路径,“外敌可御,家贼难防”的情况常常发生, IDC专线接入设备到你的业务核心交换机设备往往经过若干二层设备转接,甚至出现由于种种历史原因导致供应商设备到你的专线接入设备还要经过若干二层设备的转接。
3.2 少距离
我们通过就近接入的原则就近接入腾讯云,但是如果你的专线接入点机房和你的实际业务机房由于诸如业务合作关系等种种原因不是同一个,那么就近接入原则也将大打折扣。
3.3 少中转
例如腾讯云接入设备仅仅支持GE电口接入,但直到专线进入业务机房后你才发现线路是光接口,那么这种情况你可能很轻易的让运营商增加一个光转电的模块实现对接,这种局面大多情况通过事先的调研和沟通就可规避,如果无法避免,建议与腾讯云协商修改接入设备适配光接口链路
4.1 多看
专线提供商施工完毕后,必须要要求供应商出具端到端的测试报告,请拿出你阅读采购合同中的金额的那份认真,好好看看那份单薄的测试报告,报告上的关键要素包括光衰值、时延、带宽、丢包率,最后一定要确认测试位置是否精确到两端的机架,在中间节点之间的测试数据不被接受和认可
4.2 多干
所谓多干就是建议你亲自多做测试,测试分为空载测试、负载测试和业务测试以及要持续关注的基础指标
测试类型 | 测试项目 | 测试方法 | 通过条件 |
---|---|---|---|
空载测试 | VLANID测试 | 两端配置不同的dot1q tag后ping测试,除VLAN 1外测试三组自定义tag即可 | 三组测试icmp测试正常 |
MTU测试 | Windows:ping -l 1500 -c 100000 -f Linux: ping -s 1500 -c 100000 -M do | 二层MTU支持不分片,1500字节 | |
时延测试 | ping测试或其他icmp声纳工具 | (IDC到腾讯云POP点的光纤长度)/ 100KM) * 2ms 参见注意事项a) | |
负载测试 | 带宽测试 | ① 在专线两端即一端IDC机器 一端腾讯云主机进行iperf逐渐加压测试参见注意事项b) ② 同时彼此互相ping对端互联IP,观察丢包情况 ③ 未达到最大带宽前,继续循环到① ④ 达到最大带宽后,持续ping 万或十万数量级报文 | 接近或达到最大带宽时,丢包率为10万分之0 |
丢包率测试 | |||
基础指标 | 光衰/单双工验证 | 空载测试、负载测试结束后在接入设备上观察 | 在设备接口阈值范围内/双工状态 |
丢包 | 1)空载测试、负载测试结束后在接入设备上观察 2)在腾讯云控制台物理专线监控视图查看丢包参见注意事项c) | 1)2)无丢包 | |
错包 | 1)空载测试、负载测试结束后在接入设备上观察 2)在腾讯云控制台物理专线监控视图查看错包参见注意事项c) | 1)2)无错包 | |
业务测试 | 准上线业务 | 业务侧按需测试 | 符合业务预期 |
注意事项:
a) (IDC到腾讯云POP点的光纤长度)/ 100KM)* 2ms,这里的长度指的是光纤长度,而非机房之间的距离,线路施工过程中往往存在光纤绕行的情况,导致光纤实际距离大于机房之间物理距离
b) 腾讯云不同规格云主机在网络性能上有明显差异,进行iperf压测时,需要购买与压测带宽相匹配的云主机详细参见:https://cloud.tencent.com/document/product/213/11518
c)腾讯云物理专线监控当前支持的最小粒度是1分钟,详细参见:https://cloud.tencent.com/document/product/216/48580。
4.3 多总结
将4.1和4.2测试结论进行归,并总结该专线的建设和验收过程中的特殊性之后最终形成验收报告
5.1 命名规范
l 可辨识性
不论怎样的命名规范都要遵循一个原则,那就是可辨识性强,可辨识性强不是说你自己容易辨识,而是说就算一个外行人来看,也能知道个八九不离十
l 稳定性
既然是规范就要保证在长期一段时间内相关规则的风格不被改变,不能够朝三暮四,朝令夕改,因为你的命名风格就算再怎么怪异,时间老人也会让大家接受,好比一个性格怪异的人总比一个性格变幻莫测的人更容易让人接受一样
环境 | 命名类型 | 命名规则 |
---|---|---|
IDC | 设备命名 | 遵循你的IDC规范前提下,别人要认得清 |
接口命名 | 遵循你的IDC规范前提下,别人要认得清 | |
腾讯云 | 物理专线名称 | 以专线物理属性为关键字命名并确保唯一性、可辨识性,例如专线接入点物理位置、运营商线路编码、企业内部线路编码 例如_to_#.等 |
逻辑专线通道 | 以专线通道的逻辑业务属性为关键字命名并确保唯一性、可辨识性,例如业务名称、业务组件名称 例如:sh_to_bj#online-third-person-battle@<物理专线名> | |
逻辑专线网关 | 如果是普通专线网关,建议以业务属性叠加VPC名称命名并确保唯一性、可辨识性; 例如: online-third-person-battle#in VPCxxx 如果是云联网类型的专线网关,建议以业务属性叠加接入的IDC属性命名并确保唯一性、可辨识性 例如: gamer@IDCxxx_TCloud_Gateway. |
5.2 告警规范
5.2.1 谨慎对待告警
专线类的告警一般是专线两端的设备感知到专线异常而上报的异常信息,如果你压根儿从来没关注过什么告警,那么就无从谈什么告警规范了,这个时候建议你还是谨慎慢行,完善自己的告警系统和网络监控;
不过既然你的专线接入了腾讯云,那么你也可以直接使用腾讯云的专线告警系统,你只需配置你要关注哪些告警,当这些告警被你设定的策略触发时,你要做的也仅仅是在腾讯云控制台上配置下告警该发给谁就好了,详细参见:https://cloud.tencent.com/document/product/216/48581。
5.2.2 双管齐下
既然腾讯云已经提供了完善的告警系统,那你IDC的告警系统是不是就可以弃而不用了,那么这个时候还是要保持清醒,腾讯云的告警系统对网络异常感知的最远边界就是腾讯云专线接入POP点了,而你的设备可能距腾讯云千里之外,很多情况下,你IDC的专线链路状态的变化并非能够反馈到与你对接的腾讯云边界设备上,这种情况下,你自身的告警系统就有了用武之地
5.2.3 大声告诉你哪些你不知道
告警从人的角度来区分,其实可以分为两大类:
l 一类是你知道的
你当然会第一时间将你格外关注的心知肚明的告警配置好告警策略,但是你常常苦恼的是就算你配置好了告警,当问题真正的忽然出现的时候,你配置的告警居然没有任何动静,这个时候你要问问自己,是不是存在有我不知道的告警而我没有订阅呢?
l 一类是你不知道的
很多时候要不是某个机缘巧合,你不知道的事情可能就永远不知道了,那么对于你不知道的但实际上存在的致命告警,腾讯云监控告警系统就恰恰为你提供了这样一个“机缘巧合”,腾讯云监控系统会实时收集专线产生的异常事件并存档30天,这些异常事件可能是你已经订阅的告警,也可能是你不知道的所以没有订阅的告警类型,你可以在控制台上查看到这些未订阅信息并加以订阅,详细参见:https://cloud.tencent.com/document/product/216/48583
5.3 演习规范
这里的演习场景重点是多条物理专线上的不同专用通道的切换演习,而非仅有单条物理专线多条专线通道的话
演习维度 |
|
---|---|
演习重点 | 多通道切换 |
演习前核对 | 负载模式,是主备通道还是ECMP负载通道 |
BFD,BFD是否配置并且Session up | |
带宽评估:如果之前是ECMP模式,那么切换后到单通道是否可以承载之前双通道承载的流量 | |
演习关键步骤 |
|
验证 |
|
5.4 报障流程规范
当专线中断的你向运营商描述你的问题的时候,要保证你能说出别人能懂的话,这样的话必须包括:
1) 线路名称
2) 线路编号(必备)
3) 线路起止的物理位置
4) 客户经理的联系方式
上面的信息必须收录在你的验收文档,并录入你的内部运营系统,以备不时之用,切忌保存在个人手中
5.5 特殊性规范
现实总是能出乎意料的给你一巴掌,物理专线的接入是看得见、摸得着最为现实的网络产品,我从没有见过因为一张大风把数据库格式化了,也没有听说流行性感冒让云主机中病毒了,但是我见过老鼠咬断光缆、修路挖断光缆、火宅烧断光缆、高温\雨水让光设备停摆等等
正因为专线受地理条件、自然条件、人文条件等综合的影响较为明显,所以专线的落地常常有很多特殊性,主要表现在:
1) 绕行,例如从A-B-C-D,A-D之间绕行了B、C等
2) 跳转,例如从架杆光纤跳转到管道铺设,从管井穿线再到吊顶穿管等等,从暗线到明线等
3) 异质,例如从网线到光纤再到网线等
4) 政策,例如是专线所在机房是供应商独占\第三方租用\自建\共建等不同归属可能有不同的接入和准入政策
针对专线的特殊性,需要一并录入到运营系统,同时建议将这些特殊性也与腾讯云售后团队进行报备录入系统,在问题出现的时候你我之间做到心里有数,处理问题也显得得心应手,而不是手忙脚乱中造成临时抱供应商的佛脚而不得的局面
光纤连着你我他,选型要货比三家,验收多干多归档,规范运营乐哈哈
如果你有什么不同的意见或建议欢迎评论区留言,如果你对我的观点很不满意,特别想骂丫的,也可以留言或者私信给我,好了,下期再见
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。