Google Compute Engine

• 本文约 1090 字，阅读大致需要 3 分钟 | Development | #Google Compute Engine | #GCE | #FreeBSD | #cloud | #virtualization

📜 历史文件已不具备现实意义

本文描述的是当时的Google Compute Engine行为，并未随时代更新，内容已过时。

初步尝试了一下 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则不具备这一特性。