vps

博客vps故障及恢复处理

[| 不指定 2012/07/22 23:06]
    周四上午查看博客统计的时候发现居然一个访问量都没有。由于监控没有报警,所以心想统计坏了。

    中午的时候准备看看日志确认下,结果发现真的一个访问都没有。。蛋疼了,发现凌晨5点后一点日志都没了,奇怪,心想网络没有断,为啥呢,访问了下页面,发现数据库挂掉了,无法更新。一查文件系统,原来只读了。发ticket说磁盘坏了,正在更换。等了一个多小时没好,等不及了,开始切换。

    刚准备好切换,机器down掉了,还好博客数据和程序都有备份,从代码仓库里check出来代码。备份里恢复出来数据库,恢复数据库的时候有个插曲,由于是全量备份,所以导入的时候会把目标库里的mysql库等信息都覆盖,会使目标数据库错乱,所幸没有flush,于是把目标库的备份重新覆盖了下。

    然后dns切换,由于主dns挂掉,只有从dns服务器还能工作,手动修改了数据文件指向新机器。修改ttl为300s,以便切回的时候能快速切回。

    周五机器更换磁盘起来了,但是没数据,客服说等磁盘寄回来后才知道数据能不能恢复。虽然自己有备份,但很多软件配置没备份,自己重新配比较麻烦。还是等数据。
   今天告诉我数据取出来了,给了个ftp取数据,搞到数据后恢复了一下环境,dns切换回来了。


    看来冷门数据也要做长周期备份了。
Tags:
    买过一些空间,有时候有的朋友要放个小博客,于是就手动开通一些账号和绑定域名给他们,但总是不太方便,很麻烦,于是就有搞一个面板来实现这个功能。
    现在使用最多的主机面板就是cpanel,而cpanel恰好有很多api。
    于是搞了一个面板,可以将一个普通的cpanel用户账号多人共享,互不干扰。这样方便了主机合租和账号分享。朋友们共享主机时不再需要购买多个主机或reseller账号了。
    不过面板的账户间共享资源,所以隔离性上还是不如reseller账号的。所以建议还是朋友或熟悉的人之间使用。

    项目地址:http://code.google.com/p/cp-share/
    本文地址:http://www.snooda.com/read/307
    第一版实现了域名,数据库,ftp账号的管理,功能和界面都比较简陋。不过已经可以满足基本的需求了。后续慢慢完善。

    附截图一张:
点击在新窗口中浏览此图片


Tags:

香港vps评测及dns搭建

[| 不指定 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性能也不如预想的那么好,不过毕竟定制性好。
Tags:
   之前都是用ping和tracert/traceroute来检测线路的丢包率和延迟,最近发现mtr这个命令集合了以上两个命令的优势,在一个文本图形界面里traceroute出线路各个途径路由,然后连续ping各个节点,可以看出各个节点处的延迟、丢包情况,这样就能很容易看出来问题出在了网络的哪一步。

    通过命令展示出的数据可以看出丢包率:Loss,已发送的包数:Snt,最后一个包的延时:Last,平均延时:Avg,最低延时:Best,最差延时:Wrst,方差(稳定性):StDev。非常强大。

    按d可以切换各个视图,按一下后切换到的视图用?来表示丢包,点表示正常,不过右括号不知道什么意思。再按一下就更复杂了,还有字母数字等等。网上的资料貌似也没有提到,等有时间看看源码。不过默认视图就足够用了。

    刚刚试了一下,从国内到博客服务器,丢包大户是:202.97.53.242,现在丢包率在6个点。看延迟应该是在美国的一个路由。





Tags:

vps的系统时间不准确问题

[| 不指定 2012/04/21 17:50]
    最最早买burst NET的vps时,就是因为其时间老是不准确,最后不使用了,后来用的一些vps都没什么时间问题,openvz的一般时间都比较准,xen的可以自己用ntpdate校准,也不存在问题。

    今天发现最近搞的一个vps时间又不准了,前几天发现时间差了半分钟,找客服校准后今天看又差了4秒,平均每天要差1秒多点,相当不爽。发ticket希望客服能加个crontab任务定期校准一下服务器时间。

    在印象中电脑主板时钟已经做的不错了,怎么还会有每天差1秒这种问题。。。会不会主机商用的服务器有问题。比较囧。由于那个vps未来想观察一段时间稳定后作为主力机的。所以要求还是比较高。

    
    搞了一个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










Tags: , ,
分页: 1/1 第一页 1 最后页 [ 显示模式: 摘要 | 列表 ]