読者です 読者をやめる 読者になる 読者になる

Disk imageのコピーとの比較

まっさらなサーバを30分で本番投入できるようにする」に、たくさんのブックマークを頂きました。その中のコメントで「OSインストール、ある程度の設定がされたdisk imageをあらかじめ作っておいて、そのdisk imageをddした方が早いと思う」というものがありました。確かに速度を最速化することを考えると、確かにDisk imageをddする、というのは、かなり有力な手段です。なぜはてなではそうしていないか、を書いてみました。

  • ネットワーク経由でできない。できるようにするには、前準備が必要。
    • ddを利用する場合、単純に使うと、dd if=/dev/hda1 of=/dev/hdb1のようになり、HDDの差し替えをしないといけません。もちろん、ちょっと頑張れば、ネットワーク経由でddできるようになりますが、その場合、コピー先にOSをインストールしておかないといけないと思います。
  • 用途ごとに微調整が必要
    • プロキシーとバックエンドの構成は違うし、DBの構成もまた違います。さらにアプリケーションごとに多少の差異があり、それぞれにディスクイメージを用意するのは、大変です。
  • ディスクサイズがけっこう違う
    • そもそもディスクサイズが時々違ったりするので、ddでは、一番小さいのに合せないといけない気がします。
  • OSも実は混在している
    • 実は、Cent4系とCent5系の両方が存在するので、それぞれのためにまたディスクイメージを作るのは大変です。
  • 環境の再現が困難
    • ディスクイメージで持っていると、環境のコピーをするのは簡単ですが、同じ環境を再現するのは大変です。なにか問題が発生した時の解析手段が一つ減ってしまいます。
  • アップデートが大変
    • ディスクイメージを、用途や種類ごとにたくさん作ってしまうと、一つのパッケージをアップデートするのは大変です。そして、CPANモジュールは、けっこうな頻度でアップデートされます。

というような理由で、キックスタート & rpm化 & puppetのほうが、柔軟性と速度が高い次元でバランスが取れており、これ以上高速化を求めることは、あまり意味がないのかな、と思っています。

もっとも、ディスクイメージのコピー自体は、色々と便利な手段で、例えば、用途ごとに分岐する前のOSキックスタートあたりにうまく適用できると、様々な可能性がある思います。ただ、ハードへの物理的なアクセスはしたくないので、ddのコピー先にネットワークブート+ディスクレスで起動して、ddによるコピーを受ける環境を整えるのが大変そうです。