ssh:write failed

登录某台机器,出现如下错误:
$ ssh [email protected] -vvv

Write failed: Broken pipe

g 了一番,大多都是啥修改 ServerAliveInterval 以及 ClientAliveInterval 这两个值,分别在客户端以及服务端设置,不过修改了下并没有效果。
查看 message 文件:
2692 Aug 28 20:59:38 jaseywang sshd[512]: Accepted publickey for ad from 1.1.1.1 port 54873 ssh2
2693 Aug 28 20:59:38 jaseywang sshd[514]: fatal: setresuid 500: Resource temporarily unavailable
2694 Aug 28 20:59:44 jaseywang sshd[515]: Accepted publickey for ad from 1.1.1.1 port 54885 ssh2
2695 Aug 28 20:59:44 jaseywang sshd[517]: fatal: setresuid 500: Resource temporarily unavailable
2696 Aug 28 20:59:49 jaseywang sshd[519]: Accepted publickey for ad from 1.1.1.1 port 54886 ssh2
2697 Aug 28 20:59:49 jaseywang sshd[538]: fatal: setresuid 500: Resource temporarily unavailable
2698 Aug 28 20:59:55 jaseywang sshd[539]: Accepted publickey for ad from 1.1.1.1 port 54887 ssh2
2699 Aug 28 20:59:55 jaseywang sshd[541]: fatal: setresuid 500: Resource temporarily unavailable
2700 Aug 28 21:00:00 jaseywang sshd[543]: Accepted publickey for ad from 1.1.1.1 port 54889 ssh2
2701 Aug 28 21:00:00 jaseywang sshd[545]: fatal: setresuid 500: Resource temporarily unavailable
2702 Aug 28 21:00:06 jaseywang sshd[640]: Accepted publickey for ad from 1.1.1.1 port 54890 ssh2
2703 Aug 28 21:00:06 jaseywang sshd[651]: fatal: setresuid 500: Resource temporarily unavailable
2704 Aug 28 21:00:11 jaseywang sshd[930]: Accepted publickey for ad from 1.1.1.1 port 54892 ssh2
2705 Aug 28 21:00:11 jaseywang sshd[932]: fatal: setresuid 500: Resource temporarily unavailable
2706 Aug 28 21:00:17 jaseywang sshd[935]: Accepted publickey for ad from 1.1.1.1 port 54898 ssh2
2707 Aug 28 21:00:17 jaseywang sshd[937]: fatal: setresuid 500: Resource temporarily unavailable

资源耗尽了,修改 limits.conf 文件,重启服务,done。

Cisco 交换汇总

catalyst 6500, 4500, 4500E, 4500-X 这都是做 core 的,一般 IDC 核心设备用上面这些型号。下面主要总结的是接入以及汇聚层的设备。

Catalyst 2960-C(吹牛逼视频介绍 )/3560-C 系列的交换机是比较紧凑,做工比较 cute,然后比较节能,端口也比较少,适合家庭用,IDC 也只能用来做紧急扩展了。
比如这个 3560C-12PC-S 型号,12 口的 10/100 Fast Ethernet。

2960-S 以及 2960 系列
2960 Series(吹牛逼的视频) 提供 10/100 的 Ethernet,Forwarding bandwidth 只有 16Gbps(2960G 的为 32Gbps,2960S 为 2960G 的升级版本),基本不要考虑了。
2960-S 提供 1000 的 GigabitEthernet 各个具体型号除了端口的差别外,uplinks 也有一定的差别。比如 WS-C2960S-24TS-L 这个是 4*1G SFP,而 WS-C2960S-24TS-S 则是 2*1G SFP,并且前者还可以添加模块(光口?)。
而像 2960S-24TD-L 这种型号则提供两个 10 Gigabit Uplinks。

2960-S 的提供一个叫 Catalyst Smart Operation 的功能,类似 puppet,可以实现批量部署。

另外解释一下,PD 中的 P 代表 PoE+,这东西感觉没啥用,就是为了不插电源线用的,TD 中的 T 代表普通的以太网接口,TS 中的 S 表示 SFP,用来接光纤模块。
Continue reading

系统架构师大会(SACC 2012)第三天

今天是第三天(好长),明显没前两天有意思,早上 360buy 的那个原来是由雅虎的来讲的,做替补的感觉真不好受阿。实际上,早上的我并没有去听,只听了下午的两场。

1. 端到端的性能优化,这个我们目前也正在做,我理解的是,从你客户端发起请求到返回请求,这过程中走的每一步都需要有详细的计算,耗时多少,这样才能看出是哪部分的相应比较慢,发现了问题所在才能解决问题。
还是那句话,用户永远不会嫌你的系统太快,优化这个东西跟安全一样,不是一劳永逸的事情,是需要往复循环,坚持去做的。其实,我理解的,所谓的性能问题,从客户的层面来讲,就是一个字,慢。而这其中会牵扯到许多的人,尤其公司大了,系统复杂之后,参与进来的人会大大增加,这就需要我们能比较好的协调好各自的关系,处理好多方合作上的问题。很多有都有这种想法:事不关己高高挂起,多一事不如少一事。这个在发现系统问题的情况下更为明显。出现了问题,大家都是各自检查自己负责的模块,或者是应付性的查查或者根本就不查,然后告诉你,他负责的这块没有问题。但是是不是真的没有问题了?
所以了,要做一名优秀的管理员,除了技术层面上有过硬的技能之外,在人与人的沟通,协调方面也需要花费一定的时间来学习。

2. 网易的工程师介绍他们开源的 TCPCopy,做性能测试的。大致了解了下,完胜传统的压力测试工具。在此,对比了他的这个工具跟 tcpreplay,镜像,loadrunner 之间的优缺点。有两种极端的情况,比如你有大量的肉鸡,或者你直接搞促销抢购活动,这两种情况都能更为真实的发现系的压力,不过这不是每个公司都玩得起的。

开会这是个体力加脑力活,收获还是不少的,看看别的公司怎么做,参照我们在做的,才知道差距,有对比总是好的。综合评价 80 分。

最后感谢某 cdn 公司提供的门票。

系统架构师大会(SACC 2012)第二天

今天是第二天,上午主要是 PPTV 的那位演讲以及网易的那个 MySQL for the Web。
1. 中大型运维系统的改造,讲的很真实,感同身受。before 就是一个乱字,做视频的 IDC、CDN 机房比较多,据说全国有几百个 IDC,然后傻逼的把 DB 挤在 VM 上,公网 IP 到处乱配,系统 root 密码没记录,30% 的机器找不到归属者,各个业务各自为政,自己做自己的监控,没有所谓的容量规划,纯人肉打造,基本就是个粗放型的、简单粗暴的做法。接着这个演讲的大大来了之后,一切都不一样了(搞的很神奇似的),首先就是制定规范、标准,比如服务器的命名规范的,这个是必须有的;通过 LDAP 来管理帐号信息,通过 CAS-SSO 来管理登录;监控划分的相对比较细致,从硬件到系统到上层的业务线;大部分的都是拿来主义了,用了像 Puppet, Zabbix, LDAP, CMDB 等,当然,他们用的应该比较深入;log 通过 Fluentd + MongoDB 的方式收集。
另外一点就是要加强跟 dev 的沟通,建立一个信任的关系,这个跟 pm 与 dev 多沟通是一个道理,比如,我们完全可以把我们的监控系统以只读的形式公开给 dev 看,这个能建立起一个比较良好的信任的关系。
几个有用的观点:在监控上,漏报比误报更可怕;做总比不做好。
其实一个系统出现了问题,可以从很多层面去发现问题,比如某个业务的前端受了影响,随之而来的就是业务线的监控有问题,相应的系统级别的应该也能看出一些问题。因此,只要监控做的到位,全面,要及时的发现问题还是比较容易的。不过 PPTV 貌似不是很关心这个上层的业务监控,做的也不是很好,据说主要是 dev 不关心,这个就没办法了,自己都不关心自己写的代码,其他人再怎么催都没用。

2. 网易做的跟昨天 taobao 讲的那个有那么点类似,都是前端 LVS 到后面的 MySQL Proxy 再到 MySQL。然后下面说的比较复杂,这种大公司做的事对于绝大多数的公司来说参考的意义并不大,最起码不能在很短的时间就实现一个跟他们几乎一样的系统,实现类似的功能。相比之下,如果从『急功近利』的角度来讲,还是上面的更有价值些。

下午听的主要是安全专场,最后的结论是,如果黑客想搞你,没有他们搞不定的事。之前是谁说的了,地下黑客的水平比那些安全研究人员的领先 10 年以上,有些夸张,但是从一定程度说明了一些问题。然后了,做安全的,我觉得目前普遍比较悲剧,基本处于被动的状态,尤其是在互联网公司,不出问题啥事都没有,出了问题,等着挨骂。

Continue reading

系统架构师大会(SACC 2012)第一天

今天是 SACC 的第一天,整体的感受就是讲的比较实在,不装比。当然上午的还是基本以广告为主,前面的实在指的是下午场。

1. Tencent,泛泛而谈了他们的 webapp 开放平台的架构设计。基本运维这部分还是大同小异了,无非是监控,log 收集分析以便及时发现问题,自动化的部署,自动化的版本发布,质量的监测,这个我理解的还是属于监控这个范畴了,只不过是业务层的监控监控问题。
2. 然后是 MicroShit 吹嘘他那啥云云之类的;IBM 的在那边大谈特谈究竟什么是云。

人类大部分的活动,无非都是对资源划分于利用,这个是前天下午看完《敢死队2》的感受,其实对云来说也一样,无非是原来 100 台服务器,我不能很好的利用他的资源,现在有了云这个东西,可以把资源进一步的整合,你需要多少 cpu,需要多少 ram,我就给你分配多少的 cpu 以及 ram,不浪费,扩展起来很容易。我觉得这才是云要实现的目标。

3. 而余锋讲的则是 MySQL 在云方面的体系架构,目的也很简单,就是要更有效的利用、压榨物理机的每一点资源,同样这样的好处是管理起来也比较方便。最开始的 MySQL 使用的是 MS,这会出现同步不完全的问题并且 S 的利用率也比较低;后来改成了 proxy 的模式,制定一个统一的入口,前端 LVS 做 LB,这样控制起来比较方便。另外还使用 rabbitMQ 作为消息队列,使用 Mnesia 作为 db 的管理系统,整个系统大概 10w 代码,很多地方使用 Erlang 实现,据说该语言的特性使其特别的稳定。资源的划分是通过 cgroup 实现的,记得 baidu 也是这么做的。该系统还提供 SSL、白名单、log 追踪记录、FlashBack restore 的功能。不过该系统貌似目前还是有不少问题需要解决的,比如不能实现 group by 等操作。
Continue reading

试用 boundary 引发的一些思考

先申明一点:以后所有的公开场合我会使用大陆这个名词来表示某些特殊的群体,毕竟中国除了西朝鲜之外还包括 HK, MC, TW(?)。
boundary 是啥,引用 NYTIMES 的一段话:

Boundary, a small start-up in San Francisco that monitors the performance of applications in the cloud, offers a product that shows just how complex a mess that is, in close to real time. That is a big improvement from the daily or less frequent check-ins people do at most data centers. More important, the monitoring can show where slowdowns might be occurring, or where operational savings might be found.

about 确实是蛮吸引人的,其联合创始人 Cliff Moon 兼 CTO 的来历也是牛逼哄哄,为 NoSQL、Scala、Erlang  做了不少事,strom 项目也有他的不少贡献。

大家都知道 instagram 被 FB 收购的时候不过 10 来人的样子;linode 从 02 发展到现在,10年,员工人数 11 年统计的时候不过 20 人不到。

同样的,boundary 2010 成立,到现在 12 年做了两年了,也不过是 50 人不到的样子。对比下大陆的,就不指名道姓的说了,做物流的 2 年估计直接上千了。

试用他们的服务器目的很简单,跟他们自身的描述基本一致,发现一些问题。于是注册了个帐号,安装 agent 的方式还蛮多的。最初选择的使用 bash scipt 这种最土鳖的方式安装,以为是墙的原因,特意加了 http proxy,但是试了几次依然不成功,就直接放弃了;后来通过 puppet 的方式安装,安装的第一个 web server 成功了,但是安装第二个 web server 的时候又可耻的失败了 :-(

至此对 boundary 的印象就不是很好,正式开始试用,UI 比较绚;实时出图,这个应该是以 agent 拼命的抓取资源为代价的,这导致我们的 web server 的 load 明显的高了一级;功能方面,基本符合我们的预期要求,但是通过出来的数据并没有能找到我们系统中存在的问题;agent 全程是走 SSL 的,因此数据基本是获取不到的,关于该 agent 会不会在我们的 server 上做不该做的事,这个我们不敢保证,但是有点一可以肯定的是,他出现流氓的概率会远比大陆的低的多。 Continue reading