Browsed by
标签:ec2

挥别Amazon EC2

挥别Amazon EC2

过去一直在尝试使用Amazon的EC2云计算环境,并曾经逐步将工作中大量相关资源转移到该系统中。

应该说EC2给我留下了非常深刻的印象,然而结果却并不美好,有各方面的原因,最终导致我放弃了EC2。

最根本的原因是目前从国内访问EC2实在是太慢了。回想起去年我刚接触EC2时,非常惊讶于EC2的速度,无论是虚拟机的运行速度还是网速,都非常让人满意,当时的上传速度轻松就能达到近百KB/s,为此我甚至将VPN环境也转移到了EC2,实在是太方便了。而现在,常常出现连接超时、龟速等让人难以忍受的情况。这个问题不能全部归结于Amazon本身,也与我们猥琐的墙有关(具体原因大家都懂的)。

而最近Amazon本身似乎也有问题。在重新创建instance时,居然只有us-east四个区可选择(?现在的情况是否有改善不得而知)。而恰恰是这四个区今年以来问题不断,要么是连接性问题,要么是API问题,几乎每月都会有。当然这些问题不一定会影响到最终的接入速度或运行状态,但是毫无疑问让人感觉很担忧,尤其是将企业业务运行在这种环境时就显得更严重了。

从一些Amazon的一些新闻判断,Amazon可能将大量EC2或者S3的资源调度给自身的云应用了,例如Amazon视频、Kindle fire等,而留给外部客户的资源自然就少而且差了,这可能也是为什么只有us-east四个区可选择的原因之一。Amazon很有可能不会平等对待外部客户,而以内部应用优先。这对Amazon来说理所当然,但对外部客户而言就需要重新考虑了。

鉴于以上各种因素,最终我们转向了独立VPS提供商。虽然费用比EC2贵些,但是目前至少还没有受到太多的鸟气,感觉比较满意。

最后,再一次Fuck那个众所周知的墙以及它的设计者、制造者和维护者。

Amazon EC2抽风了吗?

Amazon EC2抽风了吗?

今天白天和晚上,都很难登录Amazon EC2在美国东海岸的服务器。速度慢得一塌糊涂。登录Amazon的console,也是非常艰难。

对比以往,经常能达到50KB左右的速度,而现在居然经常连接超时。

不清楚是Amazon出了什么问题,还是墙又增高了? 感觉跟墙没关系,毕竟我采用了单独的IP,是纯技术内容的服务器,而且访问其他外国网站没有任何问题。

怪事,估计是Amazon在同一地区又出事了。持续关注中。。。

2011-08-10 updated – 最近这几天北弗吉尼亚地区的数据中心确实出了问题,主要是连接方面的问题,目前看AWS的状态报告确认已经正常。我们网站的访问速度也已经正常。该中心在整个AWS体系中,显得尤其不稳定,频繁发生故障。后续如果需要新开服务器,最好还是选择加利福尼亚数据中心比较好。

Filezilla Failing to Retrieve Directory Listing

Filezilla Failing to Retrieve Directory Listing

在EC2上安装完pure-ftpd后,用Filezilla访问,登录都很正常,最后在获取目录时超时失败。

根本原因可能在于:EC2给各server分配的是private地址,我又assign了一个public地址。server本身是不知道这个public地址的,因此ftp client如果用public地址请求信息,可能就导致失败。

解决方式也比较简单,修改FileZilla的配置即可:

点击菜单 “Edit / Setting / Connection / FTP”,其中:

(1)”Active mode”选择“Ask your operating system for external IP address”

(2)”Passive mode”选择”Fall back to active mode”

EC2上的server终于可用了

EC2上的server终于可用了

严格来说,Amazon在弗吉尼亚北部数据中心仍然没有完全恢复正常,状态显示仍然是业务中断状态。

很幸运的是,我们的volume终于可以创建snapshot了。创建snapshot后,立刻在其他区创建一个新的volume,然后创建一个新的instance,将新的volume attach上去即可恢复运行。

从这可以看出:

(1)弗吉尼亚北部数据中心分成四个区A,B,C,D。其中,A,B区目前故障比较严重,而C、D两个区可能已经恢复正常。我们新创建的volume就设置在D区,目前工作很正常。

(2)传说中的多数据中心之间备份的功能没有实现。实际上,从目前的结果看,数据中心内部区间的备份甚至都没有实现或者出现了故障。

(3)云系统中的各个单独系统,采用snapshot方式调整部署恢复运行,功能确实也很强劲,恢复速度很快。

本次故障实在是大大出乎意料。“出故障”本身无可非议,任何设备都可能有故障,但是备份机制出现问题让人很困惑。理论上来说,既然作为云系统,A/B区出现问题,应当能立刻将数据转移到C/D区;如果弗吉尼亚数据中心出了问题,应该能立刻转移到其他数据中心,例如加利福尼亚/爱尔兰等。这次故障是否说明Amazon的云系统实际上根本无法做到数据平移?甚至无法做到同一数据中心内部平移?或者本次故障严重到备份系统(或者备份链路)都宕机了,以至于无法平移数据,造成问题越来越严重,故障部分承担的压力越来越大,最后导致雪崩?

在EC2上搭建Ubuntu系统应注意的事项

在EC2上搭建Ubuntu系统应注意的事项

EC2上的故障一直没有排除,因此我们转向Amazon在加利福尼亚的数据中心建立新的server。这个过程中,忘记了以前的一些配置,出了一些问题。主要是需要注意以下几个方面:

(1)Ubuntu在Amazon的官方ID是“099720109477”, 搜索AMI时,应搜索此ID创建的基于EBS的AMI。其他Ubuntu的AMI是社区其他人员所创建或者定制,非正式官方版本,稳定性或者安全方面没有保证。

(2)Ubuntu官方在EC2中创建了很多的AMI,包括大量的测试版本,建议以“099720109477/ebs/ubuntu-images/”进行搜索,这样搜索出来的是正式版本的Ubuntu,而不是测试版本或者里程碑版本的Ubuntu。

(3)如果是Free tier eligible用户,在搜索AMI时,应当选择“Free tier eligible”,这样所有搜出来的AMI大小不会超过10G的限制。如果AMI大小超过10G,即使成功了,后续过程中也无法SSH登录。

Amazon EC2悲剧了

Amazon EC2悲剧了

晕死!下午吃晚饭之前,想把今天的改动工作checkin进服务器,发现始终超时,操作总是失败。郁闷之下登录AWS,居然发现Amazon弗吉尼亚北部的数据中心出现严重宕机事件。

我们就非常不幸地选择了该数据中心的EC2服务。

这实在是让人郁闷的事情。上周我们才把SVN以及VPN服务器迁移到EC2上,还没怎么爽到,就over了。由此看来,云也不是那么可靠啊。

到现在为止,EC2还是没有恢复。这即将严重影响到我们的工作。无法将工作checkin进服务器,就无法实现各部分的同步。进一步想,这也是SVN的一个缺陷,如果采用Git,可能在这种情况下,不会影响到工作,完全可以先同步到本地的服务器上,然后再同步到主服务器上去。

这次事件至少说明了以下几方面的道理:

(1)云并不可靠。过度依赖云,可能会造成更严重的后果。例如,我们以前是在本地多台计算机之间同步备份数据,一台坏掉,还可以用另一台。虽然操作比较麻烦、方法很挫,不过至少不会影响到工作。

(2)SVN作为本地版本服务器是很不错的选择,但是对于分布式开发而言,SVN短处也很明显。应当正式考虑迁移到Git的可行性(甚至是迁移时间表)。

(3)即便云非常可靠,考虑到中国的国情,管道仍然可能不可靠。如果管道时不时被reset甚至直接切掉,那同样会导致整个系统不可用。