中国

骨干网

• 中国公用计算机互联网(CHINANET)

  邮电部经营管理的基于Internet网络技术的电子信息网，1995年初与国际互联网连通，邮电部撤销后改由中国电信经营。

• 中国金桥信息网(CHINAGBN)

  由中国信息产业部（原电子工业部）负责管理的公用计算机信息网。金桥信息网于1994年开始建设，1996年9月正式开通。

• 中国教育和科研计算机网(CERNET)

  始建于1994年，由中国教育部投资并管理，是中国最大的公益性、学术性计算机互联网络。有连接美国的国际专线。网络总控中心设在清华大学。

• 中国科技网 (CSTNET)

  由中国科学院主持，联合清华、北大共同建设。1994年4月与美国NSFNET直接互联，目前由中国科学院管理的。

以上为四大骨干网。下面的是其它专有网络或相对较小的网络：

• 中国联通计算机互联网(UNINET)

• 中国电信下一代承载网（ChinaNet Next Carrying Network，简称CN2）

• 中国网通公用互联网(CNCNET)

• 中国移动互联网(CMNET)

  于2000年1月组建。

• 中国长城互联网(CGWNET)

  非经营性，军队专用，不设国际出口带宽。

• 中国国际经济贸易互联网(CIETNET)

  全国外贸系统企事业单位专用，由中国国际电子商务中心负责组建、运行和维护，不设国际出口带宽。

三大运营商

中国电信拥有2张全国骨干网：中国公用计算机互联网（CHINANET / CHINA163）和中国电信下一代承载网（ChinaNet Next Carrying Network，简称CN2）。

有4个IPT产品，包括163骨干网、美洲电信AS36678、电信CN2 GT和电信CN2 GIA。

• CHINANET/163，也就是AS4134接入的带宽，中国电信骨干网，常见的202.97开头的路由，就是这个网。邮电部撤消后，由中国电信经营管理。这个网络负责了90%的电信业务负载。

• 美洲电信AS36678，是中国电信美洲分公司的ASN号码，实际上就比4134多一跳。质量和4134一个级别。 6678用美洲分公司直接运营，不需要经过电信集团公司审批。

• 中国电信CN2 GT，是电信CN2产品线中的Global Transit的产品，CN2 GT到中国国际出口有自己的单独线路，但是进入国内还是使用的163出口。

  省级/出国节点为202.97开头，国际骨干节点有2～4个59.43开头的CN2节点。

• 中国电信CN2 GIA，属于CN2中的Global Internet Access产品，等级最高，省级/出国/国际骨干节点都以59.43开头，全程没有202.97开头的节点。CN2 GIA拥有独立的回国链路，属于轻度负载，保证访问质量。这种带宽的质量是电信网络里最好的。

中国联通拥有1张全国骨干网：中国网通互联网（CHINA169）。

原中国金桥信息网(CHINAGBN)由吉通公司负责建设、运营和管理，2002年5月16日，吉通公司并入中国网通，2009年中国网通与中国联通合并。2009年工信部同意原中国网通互联网骨干网（CHINA169）和原中国联通互联网骨干网（UNINET）实施网络融合，并将 UNINET 作为下级网络接入 CHINA169。

• 联通的 cn2 （精品网），as9929 的联通骨干网，联通 /网通合并前的联通的骨干网。用户基数少，网络负荷小。出国的网络质量一般要比 4837 要好。
• as4837 ，一般用户都是这个或者其子网

中国移动，拥有1张全国骨干网：中国移动互联网（CMNET），于2000年1月组建。

其实，中国的互联网原本是一张网，中国电信几乎垄断着全国的固话网络，新兴的宽带互联网自然也是由电信”独家”经营。但是，中国电信的南北分拆打破了这一局面。

2002年5月，国内电信业大重组，原中国电信北方10个省份正式划入中国网通集团，南方21个省份重组为新的中国电信。这次”大分家”把中国的互联网人为地一分为二。

Limoncelli的测试：

• A.面向公众的处理方式:
  • 1.有没有通过项目管理系统对用户请求进行跟踪？
  • 2. “三大授权策略”是否经过具体定义并加以发布？
  • 3.整个团队的运行状态每月是否依各细则指标加以衡量并备案？
• B. 现代化团队处理方式:
  • 4.你在维基词条中是否具备独特的“策略及流程”类说明？
  • 5.日常所采用的密码安全性有保障吗？
  • 6.技术团队的代码是否处于源码控制系统的监管之下？
  • 7.你的团队有没有使用bug跟踪系统？
  • 8.在你的bug/项目管理方面，稳定性问题的优先级是否高于新功能？
  • 9.你的团队有坚持记录“设计文档”的习惯吗？
  • 10.一旦发生问题，有没有一套机制专门用于记录故障信息？
• C. 业务操作方式:
  • 11.每项具体服务都具备操作文档吗？
  • 12.每项服务是否都得到了适当的监管？
  • 13.你有没有部署过寻呼轮换机制？
  • 14.业务流程中是否具备彼此独立的开发、质量保证以及生产系统？
  • 15.在某套方案进行大范围推广前，有没有事先进行过必要的试点？
• D. 自动化处理方式:
  • 16.有没有在业务中使用到类似cfengine、puppet以及chef之类的配置管理工具？
  • 17.任务自动管理机制是否在身份账户的制约下进行？
  • 18.电子邮件的自动化生成处理是不是只在必要时启动，而非靠满纸荒唐言来拼凑使用率？
• E. 团队管理方式:
  • 19.有没有一套专门的数据库用来管理所有计算机设备？
  • 20.操作系统安装是否达到了完全自动化？
  • 21.整个团队中的软件升级及补丁更新是否做到了自动化处理？
  • 22.有没有一套完整的硬件更新规章？
• F. 硬件发生故障时的处理方式:
  • 23.当某块硬盘发生问题时，你的整套服务器体系能否继续运作？
  • 24.网络核心有没有做到N+1？
  • 25.你的备份工作是自动完成的吗？
  • 26.有没有定期测试灾难恢复方案的制度或计划？
  • 27.你数据中心内的设备具备远程电源/控制台访问功能吗？
• G. 安全性处理方式:
  • 28.业务中所用到的台式机、笔记本电脑以及服务器是否运行着自动更新且无需确认提示的反恶意软件？
  • 29.企业中是否向员工下发了书面的安全性规章制度？
  • 30.你有没有对所有相关领域进行周期性的安全审查？
  • 31.是否有相关机制允许管理者在一小时内关闭所有用户账户？
  • 32.是否有相关机制允许管理者在一小时内改变所有特权（主控）密码？

【编辑推荐】

1. 自动监控从MySQL同步的脚本
2. Nagios远程监控软件的安装与配置详解
3. Linux监控工具的展览馆

目前也在做云平台相关的工作，找到了这篇关于云平台超售的文章，对于计算超售的过程还不是特别了解，转到小站方便研究。作者是 阿里云高级产品专家 realzyy，以下是原文https://zhuanlan.zhihu.com/p/24435587.：

2016年10月26日，IT之家的CEO发布了一则公告（参见《完成阿里云至百度云站点迁移工作》），其中抱怨阿里云ECS云服务器超卖严重且售后态度不积极的内容引发了整个云计算圈子激烈讨论。 随后的一天，袋鼠云的CTO在云栖社区上发声（参见《IT之家，这不是个案》），指出IT之家的技术架构落后，使用云计算的“姿势不对”是导致整个事件最主要的原因。

-—————————– 为了避免草率得出结论，我们先使用理论数据推演。首先定义超卖率（OverSaleRate）：

假设一台物理主机有16个物理CPU+256GB内存，且其中内存是限定资源。另有假设平均的云服务器规格为2vCPU+4GB的内存，则CPU超卖率有如下推导：

这意味着，当内存售卖率（LimitedResourceSaleRate）为10%时CPU是不超卖的，当内存售卖率为60%时CPU超卖率是380%，当内存售卖率为80%时CPU超卖率则达到了540%。

-—————————– 在上述的假设条件下，云计算的CPU超卖程度显然是比较夸张的。那么实际情况是怎么样的呢？为了避免口水战，我们使用全球最大的云计算厂商AWS的官网数据来进行验证。 首先是根据EC2专用主机和EC2实例的配置，推测EC2物理主机的配置：

1. 通用型t2、m3、m4三个系列的内存／vCPU比例为0.5、1、2、4
2. 计算优化型c3、c4两个系列的内存／vCPU比例为2
3. 内存优化型r3、r4两个系列的内存／vCPU比例为8（x1系列比较特殊，略去）

相应的，我们从这个表里面能获取到的关键信息是什么呢？

1. 假设只有c3和c4系列的EC2实例是对应分布在c3和c4类主机上的，则c3和c4主机不存在CPU超卖
2. 假设只有r3和r4系列的EC2实例是对应分布在r3和r4类主机上的，则r3主机不存在CPU超卖，而r4主机存在少量CPU超卖
3. 假设只有m3和m4系列的EC2实例是对应分布在m3和m4类主机上的，则m3主机不存在CPU超卖，而m4主机存在少量CPU超卖
4. t2系列的EC2实例没有任何主机型号与之直接对应，而t2型的内存／CPU比例非常低（0.5-2），是造成CPU超卖的元凶

在此不妨做一个推测，AWS的EC2实例分配策略基于三条逻辑：

1. c3、c4、r3、r4、m3、m4等EC2规格分布在对应类型的主机上
2. t2系列中的2vCPU+8GB、4vCPU+16GB、8vCPU+32GB三个规格分布在m3、m4主机上
3. t2系列中的1vCPU+0.5GB、1vCPU+1GB、1vCPU+2GB、2vCPU+4GB四个规格分布在CPU比较空闲的主机上，并会有定期的调度策略保证物理CPU最大程度上的平均利用

在这三条逻辑的保障下，AWS可以在t2实例数量较少的情况下将超卖比控制在非常低的水位上，让用户基本对CPU超卖没有感知。在t2实例数量特别多的情况下，超卖比则会迅速恶化至500%、1000%，甚至2000%。

那么是否可能专门为t2系列定制一款主机，保证超卖在理论上就不会发生？我想AWS应该是可以做到的，但是主机成本将会非常高昂，跟t2系列低价的卖点将会背道而驰。

-—————————–

回到最初的问题：

云计算的虚拟化是否就一定存在着资源超卖，因此不能满足大企业的稳定性需求？

答案已经非常明显了，请大家自行脑补吧。

重装了系统，登陆的时候提示无法登陆。

以前的做法，都是直接把 known_hosts 删除了事。由于现在记录的太多了，删除掉会又问题。随意添加了几个反斜杠，就成功了：

ssh-keygen -f "/root/.ssh/known_hosts" -R \[103.71.xxx.xxx\]\:xxx

显示删除成功

Host [103.71.xxx.xxx]:xxx found: line 4 type ECDSA 
/root/.ssh/known_hosts updated. 
Original contents retained as /root/.ssh/known_hosts.old

这篇已经是老版本的frp了，我更新了一篇：</tech/2023/12/10/nat-proxy-frp.html>

这篇文章只列出一些点和代码，作为手册用，不做过多描述。

什么是内网穿透

转自百度百科：

内网穿透，即NAT穿透，网络连接时术语。计算机是局域网内时，外网与内网的计算机节点需要连接通信，有时就会出现不支持内网穿透。内网穿透，就是能让外网的电脑找到处于内网的电脑。

网络上比较有名的商业产品是花生壳。个人使用的话可以使用frp自建，详细过程请看下文。

frp server

docker run -itd --name frps --net=host --restart=always -v /var/local/frp/frps.ini:/tmp/frps.ini alexzhuo/frp /usr/bin/frp/frps -c /tmp/frps.ini

frps.ini内容大致如下：

[common]
bind_addr = 0.0.0.0
bind_port = 7000
vhost_http_port = 80
vhost_https_port = 443
dashboard_port = 7500
# dashboard 用户名密码可选，默认都为 admin
dashboard_user = admin
dashboard_pwd = admin

[ssh]
type = tcp
auth_token = 123
bind_addr = 0.0.0.0
listen_port = xxx

[web]
type = http
custom_domains = frp.test.org
auth_token = 123

frp client

#!/bin/bash

mkdir -p /var/local/frp
cd /var/local/frp

cat <<EOF > frpc.ini
[common]
server_addr = xx.xx.xx.xx
server_port = 7000
auth_token = 123

[ssh]
type = tcp
local_ip = 127.0.0.1
local_port = 22

[web]
type = http
local_port = 8080
EOF

docker run -itd --name frpc --net=host --restart=always -v /var/local/frp/frpc.ini:/tmp/frpc.ini alexzhuo/frp /usr/bin/frp/frpc -c /tmp/frpc.ini