Browsed by
Tag: vps

DigitalOcean 免费升级

DigitalOcean 免费升级

早上开始工作时,收到了DO的邮件,非常惊喜。DO更新了各项套餐,增加了一些新套餐,也对老套餐进行了免费升级,真是良心企业。比如原有的“$10/mo”套餐,内存从1G升级到2G,存储从30G SSD升级为50G SSD。

不过默认情况下不会自动升级,需要手工对droplet进行resize。另外需要注意的是,可以只升级CPU和Memory,如果disk也同时升级到更高容量的话,则不支持降级回原有容量。

resize操作非常简单,请参考官方文档:

https://www.digitalocean.com/community/tutorials/how-to-resize-your-droplets-on-digitalocean

网站启用IPv6应注意的事项

网站启用IPv6应注意的事项

网站支持IPv6的步骤比较简单,基本上目前常用的软件,例如Apache、Postfix、dovecot等,都已经支持IPv4和IPv6双栈,只要服务商的设备提供IPv4和IPv6连接,这些软件本身无需为IPv6做特别配置。

需要注意的是服务商处的DNS配置。如果DNS配置不全面,某些服务器在鉴权时会拒绝接受来自IPv6地址的消息。例如gmail服务器在收到 email 消息时,会鉴定DNS和IPv6地址是否匹配,如果不匹配,则视为垃圾邮件直接拒绝,可以看到如下错误警示:

Our system has detected that this 550-5.7.1 message does not meet IPv6 sending guidelines regarding PTR records 550-5.7.1 and authentication.

下面以Linode中的配置做简单介绍(对DO而言也基本如此)。假设IPv4地址是“1.2.3.4”,IPv6地址是“1:2:3:4::5:6”,域名是“demo.com”。

Reverse DNS

Linode 为每个节点分配的DNS名默认是类似的成员名,例如“1234.members.linode.com”。在 Linux 系统 ping 域名”demo.com”时,首先显示的是”1234.members.linode.com”,然后才是跳转到”demo.com”。某些服务应用会认为是PTR错误。在linode中需要设置“ reverse DNS”记录,将节点的DNS名直接指定为“demo.com”。

具体措施请参考linode的在线文档

如果同时支持IPv4和IPv6,上述文档里指导的操作需要单独操作两次,分别指定IPv4地址和IPv6地址。

MX 记录

另外一个需要注意的是 MX 记录,即邮件服务器记录。如果我们将 MX 记录设置为“mail.demo.com”,那么在DNS的A和AAAA记录中,要分别对“mail.demo.com”设置IPv4和IPv6地址,例如以下DNS记录结果:

mail.demo.com. 300 IN AAAA 1:2:3:4::5:6
mail.demo.com. 300 IN A 1.2.3.4

仅仅指定一个地址,对端有可能以域名和地址不匹配为由拒绝消息请求。

TTL

Linode 默认的TTL是3600秒,建议修改为300秒。TTL 太长太短都不好,要根据自己的实际情况调整,以方便自己网络部署、同时又不增加太多网络负担为准则。

Linode免费升级

Linode免费升级

Linode最近13周年庆,直接将内存免费翻一倍,价格保持不变,太劲爆了!

Old Plan New Plan Price
Linode 1 GB -> Linode 2 GB $10/mo ($0.015/hr)
Linode 2 GB -> Linode 4 GB $20/mo ($0.03/hr)
Linode 4 GB -> Linode 8 GB $40/mo ($0.06/hr)

有几点需要注意:

(1)如果节点是Xen架构,则需要先转换成KVM才可以进行内存升级。如果已经是KVM架构,则可以直接升级。我升级了几个节点,爽爽的!

(2)国人非常喜爱的东京数据中心,节点都是Xen架构,而且据说已经没有空闲节点,暂不支持转换成KVM,因此要等待一段时间才行。

过往都是DigitalOcean频繁推出升级或者优惠,然后Linode被迫跟随。这次感觉Linode突袭了一次。

DigitalOcean,你看到了吗?你现在还好吗?加油啊!

再见,bluehost

再见,bluehost

BlueHost(以下简称BH)是个老牌的虚拟空间服务商,与其他服务商相比,BH有很好的口碑,当然,也有相对高的价格。我们的小公司自创立以来,就使用BH的空间来支持网站(myvoipapp.com)。虽然随着我们技术水平的发展,越来越多地采用VPS和云计算资源,比如我们的云系统miniSIPServer.com以及我们为客户部署的各类系统,都换用了VPS和各类云系统,但是我们的官网始终保留在BH中。

一方面是考虑到多年数据积累,迁移整个系统是费时费力的事情,比如需要考虑email、web、ftp、论坛、blog、数据库等,想想就觉得很麻烦。另一方面,BH一直以来工作得很好,对于初创企业(尤其是没有太多技术积累的初创企业),BH提供的各类一键式安装和维护,的确省心省力,不会让人太操心,把精力更多地放在自己业务发展上。

然而最近我们终于还是花时间把网站迁移到VPS上了(推荐Linode以及DigitalOcean,两家口碑极好的VPS服务商),告别了使用时间近乎十年之久的BH。下面分享一些我们做决定时的一些动因和思考。

1、稳定性

在虚拟空间服务领域存在大量的服务商,坦率地说,绝大部分虚拟空间服务只能做个人blog等非关键应用,少数才能为严肃的商业网站提供服务,而一直以来BH都是其中佼佼者,其基础就是良好的稳定性。这也是我们一直使用BH的根本原因。

然而最近不知道是出什么问题了,也许是BH推出了VPS类业务,调整业务重心,从而忽略了原有的虚拟空间业务。总之,最近一年以来毛病不断,网络故障、主机故障、数据库故障、各类故障层出不穷,以前十年间出的问题加起来都没有最近一年多。

2、糟糕的技术支持

出问题不可怕,如果有良好的技术支持,很多问题是可以被容忍的。然而要命的是,BH的技术支持水平严重下降。很多问题本来是可以避免的,比如擅自修改php配置,居然去掉了mysql的pdo驱动,导致我们的服务大面积中断。

最离谱的是,连续几天awstats居然没有任何统计数据。由于我们以前过于信赖BH自身的工具,没有引入第三方的统计分析工具,以至于我们都无法确认这只是awstats的问题,还是BH的节点出现了严重问题,感觉非常糟糕。

BH新的技术支持人员的专业素养也让人怀疑。比如cpanel的问题、sftp等问题,域名管理配置问题等,简直答非所问,让人吃惊。而且online chat现在居然要三十几分钟的等待才能连接,实在无法理解。遥想当初使用BH的时候,还是个技术小白,几乎什么都不懂,完全是依赖即时的online chat来获得帮助,真是今非昔比。

3、隐性的商业成本

这里就不说擅自修改商业定价策略和产品包的内容。

BH的初次建站成本比较低,但是续费的时候就比较贵,这点可以接受。然后后续如果需要添加新的服务,比如HTTPS支持,独立IP等,就需要另外付费,综合起来的商业成本,实际上比使用VPS更贵一些。何况,在“lets encrypt”免费提供SSL证书的情况下,对HTTPS进行收费未必合理。实际上,我们切换到VPS后,采用了“lets encrypt”的证书进行HTTPS加密,效果很好,没有任何额外费用。

4、结论

使用VPS的技术要求门槛高一些,至少要懂一些linux的基础知识,所幸的是我们的技术水平在逐步的成长,这方面已经没有什么障碍。而BH对于初创企业目前来看还是很好的选择,只是在留住资深用户方面,还需要更扎实的服务和更稳定的系统环境。

解决DNS污染

解决DNS污染

DNS污染可能是一个比较普遍的问题,主要表现在:(1)DNS查询返回的IP地址根本是错误的。“错误”意思是IP地址要么根本不存在,要么就是个和域名完全无关系的地址。(2)IP地址虽然可能是对的,但是其他参数被莫名修改,例如TTL参数等。

测试了各类DNS服务器,例如阿里DNS、DNSPod(鹅厂)、Google DNS等。无一例外,最终的结果都或多或少被一些看不见的手给修改、甚至屏蔽了。从技术角度上讲,DNS协议本身非常随意、非常粗糙,是典型的互联网蛮荒时代的产物,比如面向UDP、无加密、无鉴权等,因此网络上任何一只手都有可能修改DNS的查询结果。网络进化到IPv6阶段,当然能解决这个问题,不过既然目前绝大部分设备还只支持IPv4协议栈,因此我们还是不得不修修补补来解决这个污染问题。

最根本的解决方法就是加密DNS查询。目前有些DNS服务商提供了私有的加密DNS方式,不过不太通用,需要私有的客户端程序配合。实际上可以不用搞这么复杂,自己建立加密通道,传递DNS消息即可。例如,参考下图的拓扑逻辑:

实现简单DNS透传的逻辑单元
实现简单DNS透传的逻辑单元

在这个网络中,有两个关键程序:dnsProxy和dnsAgent。

dnsProxy顾名思义就是个Proxy,本身并不负责DNS协议的解析,也不保存DNS的查询结果等信息,只是单纯地将DNS消息传递给真正的DNS服务器,并返回相应的结果即可。dnsProxy另一个功能是对外提供加密的数据连接,例如TLS、SSL加密等,甚至可以只是简单地对数据包进行自定义的异或运算即可。另外就是对外提供非标准连接接口,这点非常重要。DNS采用标准UDP53接口作为DNS服务器接口,网络上那些看不见的手,往往就是扫描并篡改53接口的数据包。这个小程序跑在境外(大家都懂的)的一台VPS设备上,推荐采用DigitalOcean,专业的云计算服务商,采用SSD硬盘,价格公道,我们一直用TA,如果你有兴趣的话,请点击这里自行了解细节。

dnsAgent是另一个小程序,主要负责建立与dnsProxy的加密连接,接收普通设备的DNS请求并将其传递给dnsProxy,同时返回DNS结果给普通计算设备。对于网内设备而言,dnsAgent就是个伪装的DNS服务器。同样,dnsAgent其实也不需要关心、也不需要解析DNS协议细节。在我的网络中,dnsAgent跑在一台常年吃灰的树莓派上(还是第一代的)。

实现这些仅仅需要一点UDP、TCP的网络知识,甚至不需要了解DNS协议的细节,无需对DNS数据包做修改。完成后可以愉快地打开很多以前打不开的网站。当然,有些网站始终是打不开的,这是另一个与DNS无关的话题了。

挥别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那个众所周知的墙以及它的设计者、制造者和维护者。