希望我的这些坑你不要跳【2022，我在华为云搞ECS】
【摘要】 《这就是我和ECS的“事故”》
本文主要内容：
- 一 关于ECS问题咋解决的
- 二 用API如何操作ECS
- 三 对比其他家的优势哪里
一 💡关于ECS问题咋解决的
1.1 ECS启动太慢了啊
如果说你的ECS启动时间较长，那咋办呢不然急死人，后来你可通过修改默认等待时间（我也是后面查到的嘿嘿），来提高启动速度哈
- 首先登录弹性云服务器
- 然后执行以下命令，切换至root用户
- 最后执行以下命令，查询grub文件的版本
- 然后将grub文件中timeout时间修改为0s
修改timeout全体目光向我看齐，搞定了欧耶！
1.2 ECS带宽占用高怎办
很简单，如果ECS操作卡或无法连接，那么根据我经验，可能是ECS带宽占用过高导致的，教你排查ECS带宽占用高的方法及相应的解决方案咋整
Windows操作系统ECS
Linux操作系统云服务器
- 首先通过管理控制台登录ECS
以下操作以CentOS 6.8 64bit为例
- 执行下面安装Linux流量监控工具iftop
- 执行如下，查看导致流量较高的端口与消耗流量的IP，以eth0端口为例
- 然后执行如下命令查看端口对应的进程，以38366端口为例，就是下面这个
- peak：表示第一列各种情况的流量峰值。
- rates：表示第一列各种情况2秒、10秒、40秒内的平均流量。
- 查看带宽占用率较高的进程名。
- 如果消耗带宽较多的进程为业务进程，建议您变更云服务器的配置
- 根据我经验，消耗带宽较多的进程为异常进程，可能是病毒或木马导致，建议您可以自行终止进程或者使用安全软件进行查杀
1.3 ping不通或丢包如何链路测试呢
在ECS上访问其他网络资源 ，出现网络卡。执行ping，存在丢包或时延过高的问题，没关系这些我经常遇到哭了
我们用Tracert和MTR工具，那咋诊断丢包或时延过高根本原因我找到了
根据我经验，丢包或者是时延高无非是链路拥塞、链路节点故障、服务器负载高、系统设置问题等原因造成的嘛
在排除ECS自身原因后，您可以用Tracert或MTR工具进行进一步精确诊断
用MTR可以帮助您确认网络问题的根因在哪里，非常棒
Tracert介绍和使用
Tracert是路由跟踪程序，Tracert命令用来显示数据包到达目标主机所经过的路径，并显示到达每个节点的时间。Tracert命令功能与Ping命令类似，但获得的信息要比Ping命令详细，它可以显示数据包所走的全部路径、节点的IP以及时间；
WinMTR介绍和使用
- 登录Windows云服务器
- 通过浏览器访问外网，搜索并下载WinMTR安装包
- 解压缩WinMTR安装包，WinMTR无需安装，直接解压运行
- 双击WinMTR.exe，打开WinMTR工具
- 然后WinMTR窗口的Host处，输入目的服务器IP地址或者域名，单击“Start”
- 根据实际情况，等待WinMTR运行一段时间，点“Stop”，结束测试，如下
测试结果：
- Hostname：到目的服务器要经过的每个主机IP或域名。
- Nr：经过节点的数量。
- Loss%：对应节点的丢包率。
- Sent：已发送的数据包数量。
- Recv：已接收到响应的数量。
- Best：最短的响应时间。
- Avrg：平均响应时间。
- Worst：最长的响应时间。
- Last：最近一次的响应时间。
Linux操作系统MTR介绍和使用
安装MTR
目前现有的Linux发行版本都预装了MTR，如果您的Linux云服务器没有安装MTR，则可以执行以下进行安装：
- CentOS 操作系统：
yum install mtr - Ubuntu 操作系统：
sudo apt-get install mtr
MTR相关参数说明
- -h/--help：显示帮助菜单。
- -v/--version：显示MTR版本信息。
- -r/--report：结果以报告形式输出。
- -p/--split：与 --report相对，分别列出每次追踪的结果。
- -c/--report-cycles：设置每秒发送的数据包数量，默认是10。
- -s/--psize：设置数据包的大小。
- -n/--no-dns：不对IP地址做域名解析。
- -a/--address：用户设置发送数据包的IP地址，主要用户单一主机多个IP地址的场景。
- -4：IPv4。
- -6：IPv6。
以本机到IP为119.xx.xx.xx的服务器
执行以下命令，以报告形式输出MTR的诊断报告
mtr 119.xx.xx.xx -- report
回显信息如下
[root@ecs-0609 ~]# mtr 119.xx.xx.xx --report
Start: Thu Aug 22 15:41:22 2019
HOST: ecs-652 Loss% Snt Last Avg Best Wrst StDev
1.|-- 100.70.0.1 0.0% 10 3.0 3.4 2.8 7.5 1.3
2.|-- 10.242.7.174 0.0% 10 52.4 51.5 34.2 58.9 6.3
3.|-- 10.242.7.237 0.0% 10 3.2 5.0 2.7 20.8 5.5
4.|-- 10.230.2.146 0.0% 10 1.0 1.0 1.0 1.1 0.0
5.|-- 192.168.21.1 0.0% 10 3.5 4.2 2.8 11.6 2.5
6.|-- 10.242.7.238 0.0% 10 35.3 34.5 6.0 56.4 22.6
7.|-- 10.242.7.173 0.0% 10 3.3 4.7 3.1 14.7 3.6
8.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0主要输出的信息如下：
- HOST：节点的IP地址或域名。
- Loss%：丢包率。
- Snt：每秒发送的数量包的数量。
- Last：最近一次的响应时间。
- Avg：平均响应时间。
- Best：最短的响应时间。
- Wrst：最长的响应时间。
- StDev：标准偏差，偏差值越高，说明各个数据包在该节点的响应时间相差越大。
WinMTR和MTR的报告分析处理
以下图为例分析WinMTR和MTR的报告
- 服务器本地网络：即图中A区域，代表本地局域网和本地网络提供商网络。
- 如果客户端本地网络中的节点出现异常，则需要对本地网络进行相应的排查分析。
- 如果本地网络提供商网络出现异常，则需要向当地运营商反馈问题。
- 运营商骨干网络：即图中B区域，如果该区域出现异常，可以根据异常节点的IP查询其所属的运营商，向对应运营商进行反馈。
- 目标端本地网络：即图中C区域，即目标服务器所属提供商的网络。
- 如果丢包发生在目的服务器，则可能是目的服务器的网络配置原因，请检查目的服务器的防火墙配置。
- 如果丢包发生在接近目的服务器的几跳，则可能是目标服务器所属提供商的网络问题。
常见的链路异常案例
- 目标主机配置不当
如下示例所示，数据包在目标地址出现了100%的丢包。从数据上看是数据包没有到达，其实很有可能是目标服务器网络配置原因，需检查目的服务器的防火墙配置。
Host Loss% Snt Last Avg Best Wrst StDev 1. ??? 2. ??? 3. 1XX.X.X.X 0.0% 10 521.3 90.1 2.7 521.3 211.3 4. 11X.X.X.X 0.0% 10 2.9 4.7 1.6 10.6 3.9 5. 2X.X.X.X 80.0% 10 3.0 3.0 3.0 3.0 0.0 6. 2X.XX.XX.XX 0.0% 10 1.7 7.2 1.6 34.9 13.6 7. 1XX.1XX.XX.X 0.0% 10 5.2 5.2 5.1 5.2 0.0 8. 2XX.XX.XX.XX 0.0% 10 5.3 5.2 5.1 5.3 0.1 9. 1XX.1XX.XX.X 100.0% 10 0.0 0.0 0.0 0.0 0.0 - ICMP限速
如下示例所示，在第5跳出现丢包，但后续节点均未见异常。所以推断是该节点ICMP限速所致。该场景对最终客户端到目标服务器的数据传输不会有影响，分析时可以忽略此种场景。
Host Loss% Snt Last Avg Best Wrst StDev 1. 1XX.XX.XX.XX 0.0% 10 0.3 0.6 0.3 1.2 0.3 2. 1XX.XX.XX.XX 0.0% 10 0.4 1.0 0.4 6.1 1.8 3. 1XX.XX.XX.XX 0.0% 10 0.8 2.7 0.8 19.0 5.7 4. 1XX.XX.XX.XX 0.0% 10 6.7 6.8 6.7 6.9 0.1 5. 1XX.XX.XX.XX 60.0% 0 27.2 25.3 23.1 26.4 2.9 6. 1XX.XX.XX.XX 0.0% 10 39.1 39.4 39.1 39.7 0.2 7. 1XX.XX.XX.XX 0.0% 10 39.6 40.4 39.4 46.9 2.3 8. 1XX.XX.XX.XX 0.0% 10 39.6 40.5 39.5 46.7 2.2 - 环路
如下示例所示，数据包在第5跳之后出现了循环跳转，导致最终无法到达目标服务器。出现此场景是由于运营商相关节点路由配置异常所致，需联系相应节点归属运营商处理。
Host Loss% Snt Last Avg Best Wrst StDev 1. 1XX.XX.XX.XX 0.0% 10 0.3 0.6 0.3 1.2 0.3 2. 1XX.XX.XX.XX 0.0% 10 0.4 1.0 0.4 6.1 1.8 3. 1XX.XX.XX.XX 0.0% 10 0.8 2.7 0.8 19.0 5.7 4. 1XX.XX.XX.XX 0.0% 10 6.7 6.8 6.7 6.9 0.1 5. 1XX.XX.XX.65 0.0% 10 0.0 0.0 0.0 0.0 0.0 6. 1XX.XX.XX.65 0.0% 10 0.0 0.0 0.0 0.0 0.0 7. 1XX.XX.XX.65 0.0% 10 0.0 0.0 0.0 0.0 0.0 8. 1XX.XX.XX.65 0.0% 10 0.0 0.0 0.0 0.0 0.0 9. ??? 0.0% 10 0.0 0.0 0.0 0.0 0.0 - 链路中断
如下示例所示，数据包在第4跳之后就无法收到任何反馈。这通常是由于相应节点中断所致。建议结合反向链路测试做进一步确认。该场景需要联系相应节点归属运营商处理。
Host Loss% Snt Last Avg Best Wrst StDev 1. 1XX.XX.XX.XX 0.0% 10 0.3 0.6 0.3 1.2 0.3 2. 1XX.XX.XX.XX 0.0% 10 0.4 1.0 0.4 6.1 1.8 3. 1XX.XX.XX.XX 0.0% 10 0.8 2.7 0.8 19.0 5.7 4. 1XX.XX.XX.XX 0.0% 10 6.7 6.8 6.7 6.9 0.1 5. 1XX.XX.XX.XX 0.0% 10 0.0 0.0 0.0 0.0 0.0 6. 1XX.XX.XX.XX 0.0% 10 0.0 0.0 0.0 0.0 0.0 7. 1XX.XX.XX.XX 0.0% 10 0.0 0.0 0.0 0.0 0.0 8. 1XX.XX.XX.XX 0.0% 10 0.0 0.0 0.0 0.0 0.0 9 1XX.XX.XX.XX 0.0% 10 0.0 0.0 0.0 0.0 0.0
【版权声明】本文为华为云社区用户原创内容，转载时必须标注文章的来源（华为云社区）、文章链接、文章作者等基本信息， 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容，欢迎发送邮件进行举报，并提供相关证据，一经查实，本社区将立刻删除涉嫌侵权内容，举报邮箱：
cloudbbs@huaweicloud.com
- 点赞
- 收藏
- 关注作者
评论（0）