Rails 服务器迁移点滴

[rails]

我们有 数十个 rails 应用。以及基于 FreeSWITCH 的VoIP 系统。由于考虑以后的发展做了一个艰难的决定--搬家。以前采用运计算主机托管方案,虽然不用自己维护硬件但也少了好多灵活性,而且带宽和内存很贵,而 Rails 又是吃内存的东西。

原来所有服务运行5台在双核服务器4G内存的服务器上,操作系统为 Ubuntu 7.10。Rails 版本为 2.3.4。

新服务器采用虚拟化和物理服务器结合的方式。两台 4 核 16G 内存 CentOS 运行 FreeSWITCH 以及 Skype 网关,主备用,由于系统较为复杂,暂未设置热备。

除 VoIP 平台外,其它主机及虚拟化平台全部使用 Ubuntu 10.04 LTS。

两台 6 核 32 G 内存虚拟化运行 Rails。使用 lxc 及 KVM 虚拟化方案。由于我们以前只有 Xen 的虚拟化经验,但 Xen 的前景不明,所以这次采用了 lxc ,基本上采用 lxc 与 KVM 重复配置,以防止一种方案出问题时迅速切换到另一种。

两台 4 核 16 G 内存数据库服务器主备用,采用 lxc 及 KVM 虚拟化结合运行 Mysql 及 MS SqlServer (以支持旧的 windows 应用)。

以前所有服务都是混合配置,新的架构由于采用了虚拟化,很方便的按功能进行了划分,如专门运行 nginx 的 proxy server、访问磁盘阵列的 file server 、专门用于监控的服务器,专门运行 rails 的服务器等。每种服务器都成对配置,根据情况使用负荷分担(如 rails)或冷备用(如 file server)。

Rails2 和 Rails3 的程序都跑到不同的虚拟机上,减少了版本交叉的复杂性。由于新的 Ubuntu 10.04 与旧的 7.10 差了很多,Ruby Gems 也更新了不少,有的甚至没有人维护了。所以采取了一个简单的方案,Rails2的应用全部从旧服务器上 copy Gems。因为打算以后所有应用都升级到 Rails3,所以,没有必要再去调试所有 Gem 的依赖性了,而且时间也不允许。

Rails2 全部使用 REE(Ruby Enterprise Edition 1.8.7);而 Rails3则使用 Ruby 1.9。

全部 Rails 均使用 Unicorn。Rails 的部署方式有很多 Mongrel Cluster、Thin、Passenger 等等,我们几乎都尝试过,但喜欢 Unicorn 就只因为喜欢一句话:I like Unicorn because it's UNIX

时间紧任务重,虽然做了好多准备但还是不够充分。由于服务器全部远程操作(全在美国),也增加了好多不便和工作量。

首先装好OS,测试。装好虚拟机,测试。

将新系统及数据库全部转移到新服务器上测试。准备工作完毕。睡觉。

半夜起来开始干活。改 Nginx 配置,全部重定向到静态页面。(还好,我们允许停机迁移,这省了不少事)。我们还没做到像 Google 那样将系统做成只读的。但我们的网站主页都是CMS系统,不受影响。

停掉所有 rails。dump 数据库,load 到新机器上。

将美国服务器DNS改到新服务器上。

启动新机器上的 rails,测试。

将旧服务器上的 nginx 全部 proxy_pass 到新服务器上(防止某些地方的DNS没有刷新)。

新国内服务器 nginx proxy 到新服务器上。测试,完成。

给大家发邮件,睡觉。

但这一觉睡得不踏实,还没经过检验呢。

上午被电话叫醒了,办公室呼叫中心出了问题,某些相关业务忘了更换服务器IP了。修好。

CAS[http://www.jasig.org/cas] 登录出了问题。新的 CAS 服务器 session 数据竟超过4K。想办法修好。

最头痛的是遇到了 MySQL 问题: Mysql::Error: Lost connection to MySQL server during query

查了N久,试了好多网上提到的方法都没解决。包括设置 reconnect: true ,MySQL 后台也没错误日志。终于定位到问题,它只发生在第二个及后续的数据库连接上。我们的应用会连接多个数据库,第一个数据库从来没出问题。最后想起来了,是 Unicorn preload_app 问题。以前都是 false 的。但在新的环境下,由于增加了 Newrelic[newrelic.com] 监控,为了使它能工作,只好设成 true。

preload_app 配合 REE 能节省内存,而且 Newrelic 也依赖于它工作。没办法,为了稳定,只好让 Newrelic 下岗了。

不过后来又找到一种方案让 Newrelic 重新工作,将 environment.rb 中加入

NewRelic::Agent.after_fork(:force_reconnect => true)

http://support.newrelic.com/discussions/support/2909-unicorn-without-preload_app-with-rails

Rails3 中 relative_url_root 不好用了。而我们的业务完全部署在同一域名下,根据子目录路由到不同的程序。所以,unicorn_rails --path 就不好用了。这一点很讨厌,至少在每次版本升级都会遇到该问题。不过,还好,总是能找到解决方案:

http://stackoverflow.com/questions/3181746/what-is-the-replacement-for-actioncontrollerbase-relative-url-root

UPDATE: 后来发现还有一种方案,似乎更简单:

在 config.ru 中加 map '/subdir' do run xxxx:Application end

http://summit360.co.uk/2010/09/rails_3_unicorn.html

期间还发现一个很严重的问题,就是每个服务器时间都不一样,有的还差得离谱;也忘了把所有的 localtime 改成 UTC,结果有的是 MST,有的都是没见过的时区名。最后虽然加了NTP,但调整服务器时间确实影响了一部分数据。其实这一点早就想到了,但忘了加到 check list 里,忙起来,就忘了。

随便写写吧,总算还是迁移成功了。其实,比预想的结果要好。在如此短的时间内做这么大的迁移,心里还真是没底。

最初,我们的系统也是从只有一台服务器开始的。当我接手做系统管理员的时候,就已经有三个 rails 程序了。三年前,我把这三个 rails 程序从三个独立域名部署到一个下面,后来就发展成了几十个。

为了能搭建测跟服务器相同的测试环境,我们买了两台好的 PC,在办公室采用了 Xen 虚拟化方案,即每台虚拟机对应一台真实的物理服务器。使用效果很不错。

后来我们开使使用Webistrano管理和部署应用程序。与我们的CAS系统集成,方便了许多。

我们用过 Apache, Mongrel Cluster,也用过 Apache Passenger,Nginx Passenger。都遇到过各种各样的问题。 最后转到了 Unicorn。Unicorn 确实很优雅。

除 Rails 外,我们也有几个 Sinatra 程序,及 PHP、Erlang 等应用。它们都很好地发挥了自己的长处,优雅地协同工作着。

好长时间不写东西了,有点乱,聊作点纪念。

七歌
微信扫一扫