有助于提高系统管理员团队工作效率的32个问题 - 51CTO

Limoncelli的测试:

【编辑推荐】

  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系列低价的卖点将会背道而驰。

-—————————–

回到最初的问题:

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

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


删除 ssh known_hosts 中特定的主机

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

以前的做法,都是直接把 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

内网穿透

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

什么是内网穿透

转自百度百科:

内网穿透,即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

HTML5 audio 实验 - tommy351

这是一篇,很古老的文章。。。。。然而这又是一篇和我blog有着一些联系的文章。。。我blog右边的播放器,其实就是来源于此文。

鉴于互联网上消失的人越来越多,为了给自己留个纪念,把他这篇文章转载过来做个留念。

作者现在仍然活跃在前端开发的技术栈中,可以参考他的github@tommy351

寒假即将结束,不巧膝盖突然中了一箭,便决定实验 HTML5 audio标签的效果,虽然已有 jPlayer 这款轻便好用的播放器,但不折腾一下就没办法消磨时间了,所以本次的实验品完全由我操刀。

开始之前

首先必须了解 audio 标签的使用方式:

<audio controls>
  <source src="music.mp3">
  <source src="music.ogg">
</audio>

输入以上代码后,便可在网页中看到浏览器内建的播放器。每种浏览器支援的播放类型不一,最保险的方法是备妥mp3、ogg。

为了浪费时间,当然不可能用浏览器的预设介面,所以删除controls属性,透过 JavaScript 操作:

var audio = document.getElementsByTagName('audio')[0];
// 播放
audio.play();
// 暫停
audio.pause();

只需要懂这两个函数,就可製作最基础的播放器了,其他複杂的指令可参阅文末的参考出处。

介面

写网页时,比起最重要的 JavaScript,我习惯先写 CSS,最初的参考范本是 Mac 的 CoverFlow。

经过一连串绞尽脑汁,写了一堆乱七八糟的 CSS 之后,成品如下。

无论是倒影、中间的圆圈进度表都与 CoverFlow 非常相像,但这种样式实在 太麻烦了 不便使用者操作,所以从 Premium Pixels 偷点子过来,稍微加油添醋一下,完成了播放器介面 Ver. 2。

Ver.2 与 Ver.1 完全不像?这种事情不重要啦!

##核心

介面完成自爽一下之后,就得面对麻烦的 JavaScript 了,播放、暂停非常简单,按钮按下去执行乡对应的动作即可,然而音量调整与进度条该如何处理呢?

虽然本次的重点是消磨时间,但再去造一个轮子实在他妈的太累了,于是 聪明如我 请到了 jQuery UI,Slider 功能压缩后需要约 20KB 的空间,有点庞大不过方便就好。

时间的控制方式如下,单位为秒数,例如跳至第 100 秒的位置:

audio.currentTime = 100;

音量的控制方式如下,范围为 0~1,例如将音量调整至一半大小:

audio.volume = 0.5;

audio可绑定play, pause, ended, progress, canplay, timeupdate等事件。play与pause如字面上意思,分别为播放、暂停后生效。

audio.addEventListener('play', function(){
  play.title = 'pause';
}, false);

audio.addEventListener('pause', function(){
  play.title = 'play';
}, false);

ended为结束后生效,当音乐结束后,可透过此事件让时间归零。

audio.addEventListener('ended', function(){
  this.currentTime = 0;
}, false);

当音乐档桉开始载入后,便会启动progress事件,可透过此事件监测下载进度。Firefox 可能会发生问题,建议搭配durationchange事件使用。

audio.addEventListener('progress', function(){
  var endVal = this.seekable && this.seekable.length ? this.seekable.end(0) : 0;
  buffer.style.width = (100 / (this.duration || 1) * endVal) + '%';
}, false);

当音乐下载到一定程度后,canplay事件便会生效,一般会透过此事件初始化播放器。相同类型的事件还有很多,依照启动顺序分别为:loadstart, durationchange, loadeddata, progress, canplay, canplaythrough。

timeupdate会在音乐播放时不断生效,可透过此事件更新时间。

audio.addEventListener('timeupdate', function(){
  progress.style.width = (this.currentTime / this.duration) * 100 + '%';
}, false);

##播放列表

一个播放器的基础功能就此完成,能够播放、暂停、调整音量、调整时间。但这显然还不够,播放列表对于播放器而言相当重要。(大概啦)

不要吐槽为啥播放列表裡全是动漫歌,林北就是宅啦…

与自己的逻辑奋战大约一晚后,有播放列表、随机播放、重複播放(单首、全部)功能的播放器于焉完成。只需要 214 行、约 6KB 的代码(未压缩)即可完成,应该能算是轻便简易了。

##后记

播放列表的製作过程有点髒,中途还重构了几次,所以直接看范例应该会比较快,若对于范例内的程式码感到疑惑,可在下方留言。

范例内已设定了一些参数,可在js/script.js内更改。第 5 行的continous参数为连续播放,第6行的autoplay参数为自动播放,第7行的playlist阵列请自行设定,压缩档内不会附带范例内的音乐档桉。playlist阵列的格式如下:

var playlist = [
  {
    title: 'Tell Your World',
    artist: 'livetune feat.初音ミク',
    album: 'Tell Your World',
    cover: 'cover/tell_your_world.jpg',
    mp3: 'music/tell_your_world.mp3',
    ogg: 'music/tell_your_world.ogg'
  }
];

title为标题,artist为演出者,album为专辑名称,cover为专辑封面的路径,mp3、ogg分别为音乐档桉的路径,建议备妥两种格式的档桉,要不然 Firefox 和 Opera 不就只能去死了吗?

因为做到最后头脑快爆炸了,懒得做 Flash fallback,IE 请去死一死吧。

下载

##参考出处