vps
博客vps故障及恢复处理
[
| 
2012/07/22 23:06]
| 2012/07/22 23:06]
周四上午查看博客统计的时候发现居然一个访问量都没有。由于监控没有报警，所以心想统计坏了。
中午的时候准备看看日志确认下，结果发现真的一个访问都没有。。蛋疼了，发现凌晨5点后一点日志都没了，奇怪，心想网络没有断，为啥呢，访问了下页面，发现数据库挂掉了，无法更新。一查文件系统，原来只读了。发ticket说磁盘坏了，正在更换。等了一个多小时没好，等不及了，开始切换。
刚准备好切换，机器down掉了，还好博客数据和程序都有备份，从代码仓库里check出来代码。备份里恢复出来数据库，恢复数据库的时候有个插曲，由于是全量备份，所以导入的时候会把目标库里的mysql库等信息都覆盖，会使目标数据库错乱，所幸没有flush，于是把目标库的备份重新覆盖了下。
然后dns切换，由于主dns挂掉，只有从dns服务器还能工作，手动修改了数据文件指向新机器。修改ttl为300s，以便切回的时候能快速切回。
周五机器更换磁盘起来了，但是没数据，客服说等磁盘寄回来后才知道数据能不能恢复。虽然自己有备份，但很多软件配置没备份，自己重新配比较麻烦。还是等数据。
今天告诉我数据取出来了，给了个ftp取数据，搞到数据后恢复了一下环境，dns切换回来了。
看来冷门数据也要做长周期备份了。
中午的时候准备看看日志确认下，结果发现真的一个访问都没有。。蛋疼了，发现凌晨5点后一点日志都没了，奇怪，心想网络没有断，为啥呢，访问了下页面，发现数据库挂掉了，无法更新。一查文件系统，原来只读了。发ticket说磁盘坏了，正在更换。等了一个多小时没好，等不及了，开始切换。
刚准备好切换，机器down掉了，还好博客数据和程序都有备份，从代码仓库里check出来代码。备份里恢复出来数据库，恢复数据库的时候有个插曲，由于是全量备份，所以导入的时候会把目标库里的mysql库等信息都覆盖，会使目标数据库错乱，所幸没有flush，于是把目标库的备份重新覆盖了下。
然后dns切换，由于主dns挂掉，只有从dns服务器还能工作，手动修改了数据文件指向新机器。修改ttl为300s，以便切回的时候能快速切回。
周五机器更换磁盘起来了，但是没数据，客服说等磁盘寄回来后才知道数据能不能恢复。虽然自己有备份，但很多软件配置没备份，自己重新配比较麻烦。还是等数据。
今天告诉我数据取出来了，给了个ftp取数据，搞到数据后恢复了一下环境，dns切换回来了。
看来冷门数据也要做长周期备份了。
cpanel账号分享管理面板：cp-share
[| 2012/06/19 23:57]
| 2012/06/19 23:57]
买过一些空间，有时候有的朋友要放个小博客，于是就手动开通一些账号和绑定域名给他们，但总是不太方便，很麻烦，于是就有搞一个面板来实现这个功能。
现在使用最多的主机面板就是cpanel，而cpanel恰好有很多api。
于是搞了一个面板，可以将一个普通的cpanel用户账号多人共享，互不干扰。这样方便了主机合租和账号分享。朋友们共享主机时不再需要购买多个主机或reseller账号了。
不过面板的账户间共享资源，所以隔离性上还是不如reseller账号的。所以建议还是朋友或熟悉的人之间使用。
项目地址：http://code.google.com/p/cp-share/
本文地址：http://www.snooda.com/read/307
第一版实现了域名，数据库，ftp账号的管理，功能和界面都比较简陋。不过已经可以满足基本的需求了。后续慢慢完善。
附截图一张：
现在使用最多的主机面板就是cpanel，而cpanel恰好有很多api。
于是搞了一个面板，可以将一个普通的cpanel用户账号多人共享，互不干扰。这样方便了主机合租和账号分享。朋友们共享主机时不再需要购买多个主机或reseller账号了。
不过面板的账户间共享资源，所以隔离性上还是不如reseller账号的。所以建议还是朋友或熟悉的人之间使用。
项目地址：http://code.google.com/p/cp-share/
本文地址：http://www.snooda.com/read/307
第一版实现了域名，数据库，ftp账号的管理，功能和界面都比较简陋。不过已经可以满足基本的需求了。后续慢慢完善。
附截图一张：
香港vps评测及dns搭建
[| 2012/05/15 23:25]
| 2012/05/15 23:25]
由于一快一慢搭dns靠谱程度不高，只能再搞一个速度比较快的vps来当dns服务器，没啥好选择，对国内靠谱的线路也就东亚这几个地方的：日韩港台。日韩的有语言障碍，价格也相当牛叉，于是还是搞香港的，今天入了一个试试。
香港是众所周知的小水管，今天试了一下名不虚传，网站测速测一个wp的首页才6k的数据就惨不忍睹，测一个380k的图片，单线程稳定1.4M，应该是限速了。多线程直接各种超时，并且遇到一个从来没遇到的情况：测速时由于带宽跑到限制，ssh输入都挂了，无响应，停止测速才恢复。。。。小水管真是名不虚传。
观察了一下稳定性，也非常一般般，波动不小。
用台湾vps和香港vps搭了一对dns试了一下，刚开始设置所有记录均不缓存，发现我自己的电脑上每次都稳定在500ms左右，非常奇怪，因为到任意一台机器都只需要几十ms，解析时指定dns确实也只需要几十ms，后来把ns记录设置了缓存一分钟，发现在缓存期内延迟降到了几十ms，看来是由于不缓存ns记录时需要去一级域dns那里查顶级域名的ns记录导致的，不过奇怪，难道一级域dns给出的ns记录缓存时间是由顶级域dns里的ns设置决定的么？搞不懂。不过我把ns记录设置成缓存1小时时，发现监控宝的dns监控时间还是稳定在500ms左右，没有下降，ft。并且四个监控点还总有一个报获取不到记录。
dns的性能测试实在是不好搞，设置成不缓存的话不太好同条件对比，因为dns商不会允许这么设。设缓存的话结果又往往取决于缓存dns服务器的性能。对于大站的话由于访问人数多，所以dns一定是被缓存住的，倒不用考虑dns问题，对于小站，每个访客都要从头解析一下域名，dns的速度就很重要了。
不过通过今天的观察发现自己建dns性能也不如预想的那么好，不过毕竟定制性好。
香港是众所周知的小水管，今天试了一下名不虚传，网站测速测一个wp的首页才6k的数据就惨不忍睹，测一个380k的图片，单线程稳定1.4M，应该是限速了。多线程直接各种超时，并且遇到一个从来没遇到的情况：测速时由于带宽跑到限制，ssh输入都挂了，无响应，停止测速才恢复。。。。小水管真是名不虚传。
观察了一下稳定性，也非常一般般，波动不小。
用台湾vps和香港vps搭了一对dns试了一下，刚开始设置所有记录均不缓存，发现我自己的电脑上每次都稳定在500ms左右，非常奇怪，因为到任意一台机器都只需要几十ms，解析时指定dns确实也只需要几十ms，后来把ns记录设置了缓存一分钟，发现在缓存期内延迟降到了几十ms，看来是由于不缓存ns记录时需要去一级域dns那里查顶级域名的ns记录导致的，不过奇怪，难道一级域dns给出的ns记录缓存时间是由顶级域dns里的ns设置决定的么？搞不懂。不过我把ns记录设置成缓存1小时时，发现监控宝的dns监控时间还是稳定在500ms左右，没有下降，ft。并且四个监控点还总有一个报获取不到记录。
dns的性能测试实在是不好搞，设置成不缓存的话不太好同条件对比，因为dns商不会允许这么设。设缓存的话结果又往往取决于缓存dns服务器的性能。对于大站的话由于访问人数多，所以dns一定是被缓存住的，倒不用考虑dns问题，对于小站，每个访客都要从头解析一下域名，dns的速度就很重要了。
不过通过今天的观察发现自己建dns性能也不如预想的那么好，不过毕竟定制性好。
mtr-可视化线路情况检测命令（延迟/丢包率检测）
[| 2012/05/06 10:59]
| 2012/05/06 10:59]
之前都是用ping和tracert/traceroute来检测线路的丢包率和延迟，最近发现mtr这个命令集合了以上两个命令的优势，在一个文本图形界面里traceroute出线路各个途径路由，然后连续ping各个节点，可以看出各个节点处的延迟、丢包情况，这样就能很容易看出来问题出在了网络的哪一步。
通过命令展示出的数据可以看出丢包率：Loss，已发送的包数：Snt，最后一个包的延时：Last，平均延时：Avg，最低延时：Best，最差延时：Wrst，方差（稳定性）：StDev。非常强大。
按d可以切换各个视图，按一下后切换到的视图用？来表示丢包，点表示正常，不过右括号不知道什么意思。再按一下就更复杂了，还有字母数字等等。网上的资料貌似也没有提到，等有时间看看源码。不过默认视图就足够用了。
刚刚试了一下，从国内到博客服务器，丢包大户是：202.97.53.242，现在丢包率在6个点。看延迟应该是在美国的一个路由。
通过命令展示出的数据可以看出丢包率：Loss，已发送的包数：Snt，最后一个包的延时：Last，平均延时：Avg，最低延时：Best，最差延时：Wrst，方差（稳定性）：StDev。非常强大。
按d可以切换各个视图，按一下后切换到的视图用？来表示丢包，点表示正常，不过右括号不知道什么意思。再按一下就更复杂了，还有字母数字等等。网上的资料貌似也没有提到，等有时间看看源码。不过默认视图就足够用了。
刚刚试了一下，从国内到博客服务器，丢包大户是：202.97.53.242，现在丢包率在6个点。看延迟应该是在美国的一个路由。
vps的系统时间不准确问题
[| 2012/04/21 17:50]
| 2012/04/21 17:50]
最最早买burst NET的vps时，就是因为其时间老是不准确，最后不使用了，后来用的一些vps都没什么时间问题，openvz的一般时间都比较准，xen的可以自己用ntpdate校准，也不存在问题。
今天发现最近搞的一个vps时间又不准了，前几天发现时间差了半分钟，找客服校准后今天看又差了4秒，平均每天要差1秒多点，相当不爽。发ticket希望客服能加个crontab任务定期校准一下服务器时间。
在印象中电脑主板时钟已经做的不错了，怎么还会有每天差1秒这种问题。。。会不会主机商用的服务器有问题。比较囧。由于那个vps未来想观察一段时间稳定后作为主力机的。所以要求还是比较高。
今天发现最近搞的一个vps时间又不准了，前几天发现时间差了半分钟，找客服校准后今天看又差了4秒，平均每天要差1秒多点，相当不爽。发ticket希望客服能加个crontab任务定期校准一下服务器时间。
在印象中电脑主板时钟已经做的不错了，怎么还会有每天差1秒这种问题。。。会不会主机商用的服务器有问题。比较囧。由于那个vps未来想观察一段时间稳定后作为主力机的。所以要求还是比较高。
OpenVZ VPS内存查看分析工具/超售检查脚本
[| 2012/04/12 02:52]
| 2012/04/12 02:52]
搞了一个python脚本，用来查看OpenVZ VPS内存情况的，原始数据取自/proc/user_beancounters文件，脚本内做了一个数据简单的分析提取和可视化提高的工作，已经很晚了，先搞几个基本功能出来，增强功能以后再补。
用法： python vz_checker.py /proc/user_beancounters (需要root权限）
输出内容：
filename is:[user_beancounters]
Kernel Mem Info: used:[5.723M] max_used:[35.539M] limit:[2048.000M] fail_count:[0]
Mem already allocated Info: used:[17.621M] max_used:[33.074M] limit:[96.000M] fail_count:[0]
Ram actually used: used:[8.516M] max_used:[67.820M] limit:[96.000M] fail_count:[0]
Mem (Ram + swap) used: used:[9.848M] max_used:[13.219M] limit:[96.000M] fail_count:[0]
Kernel Mem Info：占用的内核内存大小，不可被swap，主要用来存放进程数据等。
Mem already allocated Info：已分配的内存大小，limit即为burst内存大小。
Ram actually used： 实际占用的物理内存大小。
Mem (Ram + swap) used： 占用的物理内存和swap大小。
如果 实际占用的物理内存 == 占用的物理内存和swap大小 那么恭喜你，你的vps里运行的程序都在内存中，主机超售不严重。
如果 实际占用的物理内存 < 占用的物理内存和swap大小 情况不妙，主机已经开始占用swap了，超售比较严重了。
另外我在测试过程中发现有一台vps实际占用物理内存大小显示比物理内存+swap总和还要大，现象很奇怪，查了一些资料没有关于这方面的说明，待后续调查。
脚本功能还比较粗糙，一些数据需要继续打磨，欢迎大家提意见~~
本文地址：http://www.snooda.com/read/263
下载地址：https://github.com/snooda/openvz_checker
用法： python vz_checker.py /proc/user_beancounters (需要root权限）
输出内容：
filename is:[user_beancounters]
Kernel Mem Info: used:[5.723M] max_used:[35.539M] limit:[2048.000M] fail_count:[0]
Mem already allocated Info: used:[17.621M] max_used:[33.074M] limit:[96.000M] fail_count:[0]
Ram actually used: used:[8.516M] max_used:[67.820M] limit:[96.000M] fail_count:[0]
Mem (Ram + swap) used: used:[9.848M] max_used:[13.219M] limit:[96.000M] fail_count:[0]
Kernel Mem Info：占用的内核内存大小，不可被swap，主要用来存放进程数据等。
Mem already allocated Info：已分配的内存大小，limit即为burst内存大小。
Ram actually used： 实际占用的物理内存大小。
Mem (Ram + swap) used： 占用的物理内存和swap大小。
如果 实际占用的物理内存 == 占用的物理内存和swap大小 那么恭喜你，你的vps里运行的程序都在内存中，主机超售不严重。
如果 实际占用的物理内存 < 占用的物理内存和swap大小 情况不妙，主机已经开始占用swap了，超售比较严重了。
另外我在测试过程中发现有一台vps实际占用物理内存大小显示比物理内存+swap总和还要大，现象很奇怪，查了一些资料没有关于这方面的说明，待后续调查。
脚本功能还比较粗糙，一些数据需要继续打磨，欢迎大家提意见~~
本文地址：http://www.snooda.com/read/263
下载地址：https://github.com/snooda/openvz_checker
