Google Compute Engine

| 1 Comment | No TrackBacks |

初步尝试了一下 Google Compute Engine(G社类似 Amazon EC2的产品,基于 Linux/KVM)。确认 FreeBSD 可用(在家里用qemu建一个image出来,装好,然后打包扔到 Google 的系统上,然后用这个包建一个image,再用image起个instance)。

几个比较显著的坑:

  • Google Cloud SDK假定bash位于/bin/bash。这个很容易patch。
  • 如果是在远程的 FreeBSD 系统上使用 Google Cloud SDK,它默认会起 links 作为浏览器。由于 links 不支持 JavaScript,因此会导致 Google Cloud API 授权失败。解决方法是关闭浏览器,然后通过 X forwarding 起一个 Chromium (我估计 Firefox 也没问题)来操作。
  • GCE的系统只支持GNU tar格式的文件,使用 FreeBSD 的 bsdtar 时必须指定用 gnutar 格式,或者用 GNU tar(bsdtar默认采用的是 pax interchange 格式,而 libarchive 目前并不支持 GNU tar 的 sparse 模式;具有讽刺意义的是 Tim 其实应该是在 Google? xz 支持未测,我觉得以只支持 GNU tar 的劲头应该是不支持 xz 的)。
  • 预设的防火墙规则基本只允许 ssh。
  • 系统内建 禁止任何发到标准SMTP端口 (25, 465, 587)的请求。可以理解禁止25,但是不太理解禁止465和587,意义何在?是为了推广 SendGrid 吗?
  • 初始的qemu镜像文件必须是10240MB。
  • 上传 qemu 打包之后,建立 image 后其实可以直接删除原包。

存到盘上的数据据说是加密的,不过个人认为扔到 Internet 上的数据基本就没有隐私可言了,有加密自然可以阻止一些泄密(例如如果一家创业公司想要保存一些患者信息,那么在 Google 本身不被黑掉且他们遵守一系列安全设计准则的前提下,他们至少不用担心由于硬盘坏掉,替换硬盘时这些数据被第三方厂商偶然得到),但基本上跟家里的门窗结实程度一样,你懂的。

实际测试,虚拟网络至少可以做到 100Mbps 跑满(对 Internet)。我认为对大部分普通应用而言应该是够用了。比较遗憾的是本地读写性能忘记测试了,等有时间再研究一下(看 这里 估计太快不了;可靠性方面,据说有内建冗余和校验和检查,不知道实际情况如何,个人感觉可靠性应该还不错)。

现在有个比较邪恶的想法是跑个定制的 FreeBSD 系统:以 64-bit FreeBSD 为主体,大部分系统工具替换为 32-bit 的,削去不必要的元件如 APM、电源管理、无线等等,同时安装 64-bit 和 32-bit 的库。这样的好处有:1) 可以充分利用内存和 long mode 的一些优势; 2) 大部分应用程序并不真的需要使用 2GB 以上内存(除非出了问题),跑 32-bit 的版本作为副作用恰好可以阻止它们疯长(一旦发生这种情况直接就被内核干掉了),而另一个副作用则是 32-bit 的代码本身比较小,因而可以节省内存和磁盘空间从而降低使用成本; 3) 64-bit FreeBSD 上的 32-bit 兼容库是采用最新 CPU 指令集编译的,而直接安装的 32-bit 版本 FreeBSD 则不具备这一特性。

No TrackBacks

TrackBack URL: https://blog.delphij.net/mt/mt-tb.cgi/1957

1 Comment

为啥一定要用freebsd 呢, 我经常用goolge compute engine , 全是用的linux .

另外,真正做产品部署的话, 还是别用google compute engine。
从去年5月到现在, google compute 的api 改了至少5次。上个月才发布 v1.0 的api 。

还是 azure 和 ec2 更信得过点,这个不是技术问题,是信心问题。

Leave a comment

Monthly Archives

Pages

OpenID accepted here Learn more about OpenID
Powered by Movable Type 5.2.3