初步尝试了一下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 则不具备这一特性。
由 udpwork.com 聚合
|
评论: 0
|
要! 要! 即刻! Now!
