仮想ゲストOSにコンテナのLXDを選ぶ理由

  • 19
    Like
  • 0
    Comment

どのようにサーバOS環境を作るかは、システム戦略で非常に重要です。
正しい選択をすることによって、システムの信頼性が高くなり、コストをかなり抑えることができます。
作業効率・スピードが全然違ってきます。

LXDとは

  • LXD(レックスディーまたはエルエックスディー)と読みます。
  • LXDはKVMやXenの代わりになるシステムコンテナです。
    • コンテナで有名なDockerは、1アプリケーションを起動させることを目的としたアプリケーションコンテナと呼ばれています。


  • 簡単にOSのコピーができます。
    • lxc copy 元コンテナ 新コンテナ #Macアドレスは自動で変わります。
  • コンテナをイメージ化できます。
    • lxc publish コンテナ名 --alias イメージ名
  • OS状態を残しておくスナップショットも簡単です。
    • スナップショットをイメージ化することで、OS停止なくイメージ化できます。
  • 別ホストに仮想ゲストOSを移動させるライブマイグレーションも可能です。
  • コンテナごとにCPU使用率、メモリー使用量、IO負荷制限ができます。

KVMやXenやVMwareのハイパーバイザーではなく、LXDコンテナの理由

  • LXDは起動が高速です。
  • LXDはスナップショットやクローンのバックアップが高速で実現できます。
  • ハイパーバイザーのようなオーバーヘッドがありません。
  • LXDは事前にリソースを割り当てておく必要がありません。★
    • LXDは、HDD50GB、CPU 4Core、メモリー4GB を割り当てようという設計不要です。
    • 開発からかなりのハイスペックを言われても、実際に使った分しか消費されません。
    • LXDは、使い過ぎたら困る場合に、リソース制限をするだけです。
  • CPUやメモリーやHDDの増減が、制限を変更するだけなのでOS停止は不要です。★
  • 高機能な有料版VMwareは、非常に高額です。LXDなら無料です。
  • LXDなら、CPUやメモリーやHDDのリソースを変更するために、OS停止が必要ということはないです。

Dockerコンテナではなく、LXDコンテナの理由

アプリケーションコンテナのDockerは、LXDの上で動かします。DockerとLXDは利用目的が違うと考えています。

  • Dockerと違い、LXDは、KVMやXenの代わりに使えます。
  • Dockerと違い、LXDは、アプリケーションの変更が不要です。
  • LXDと違い、ブリッジ接続が簡単にできます。
  • LXDなら、スナップショット、イメージ化、ライブマイグレーションができます。★
  • LXDと違い、ポート変換やiptablesは不要にできます。
  • Dockerのように、IPとポートの組み合わせでコンテナ間を接続するのは、リプレースとしては非常に難しいです。
    • 仮想ホストしかルーティングできなかったり、FWのグループという概念がなくなります。
  • LXDには、Dockerのように、1コンテナ1プロセスにするべきというベストプラクティスはありません。
  • LXDには、コンテナにデータは保存しないべきというベストプラクティスはありません。

LXCではなく、LXDを使う理由

  • LXCの機能強化版が、LXDです。
    • LXC + 現代的機能 = LXD
  • LXCでできることは、LXDでもできる。
  • LXDはライブマイグレーションができる
  • 複数ホストのコンテナを管理できる。
  • 今から新しくコンテナを導入するなら、LXD

ベアメタル(物理サーバ)ではなく、LXDコンテナの理由

  • LXDなら、サーバ構築依頼がきても、1ヶ月待ってくださいということがないです。★
    • LXDなら、今ある環境に作ることによって、すぐにサーバを引き渡せます。
  • OSが停止してしまう問題が起きてしまった時にもゲストOSを別のハードにもっていけますので、ハードが問題かソフトが問題かの切り分けができます。
  • LXDにすることによって、数十個の仮想ゲストコンテナを動かせます。
    • 圧倒的にコスト圧縮できます。
  • 1ホストで、1サーバ分のCPU、メモリーを使い切れるアプリケーションはありません。
    • LXDにすることによって、余っているリソースの有効活用ができます。
  • 物理サーバはかなりの場所をとりますが、LXDなら節約できます。
  • LXDなら、必要なディスクサイズ、CPU、メモリーを正確に算出する必要はありません。
    • 想像以上に使っても、使われなくても問題ありません。
  • LXDはリソースの設計ミスがありません。
    • リソースが余っていたら、もう1つ仮想ゲストを作ればいいだけです。
    • リソースがひっぱくしたら、別の仮想ホストに移動させればいいだけです。
  • LXDは起動が高速なので、何か問題が発生している際にも、プロセスを再起動する感覚で、OS再起動できます。★

AWSなどのクラウドではなく、オンプレのLXDコンテナを使う理由

  • ソフトだけでなくハードも含めて最適化ができる★
  • 優秀なエンジニアがいればクラウドよりすごいことがしやすい★
  • オンプレでLXDを使うことによって、クラウドよりかなり費用が抑えられます。
  • オンプレのLXDなら、要求に応じて、高可用性物理サーバを使えます。★
  • LXDなら、CPUやメモリーやHDDのリソースを変更するために、OS停止が必要ということはないです。
  • LXDは、ゲストOSが起動したまま、別のホストに移動させるライブマイグレーションができます。
    • OS停止しないで、ホストのメンテナンスが可能です。
  • LXDは、OS作るのが、数秒です。
  • LXDは、OS起動も一瞬です。
  • LXDは、スナップショット、イメージ化、コピーも数秒です。
  • LXDは、物理設計による高速化、高信頼性が可能です。
    • 例えば、お互いに通信が多いWebとAPは同じホストに配置する。
    • 例えば、2台構成のサーバは、1ホストが故障しても問題ないように、別のホストに配置する。

LXDを使うために注意すること

  • 仮想ホストは、Ubuntuにしましょう。CentOSやRHELでは動かないと考えた方がよいです。
    • Ubuntuの開発元のCanonicalがLXDを開発しているので、Ubuntuがもっともテストされている環境になります。
  • 仮想ゲストは、Ubuntu以外にも、日本でユーザの多いCentOSやOracle Linuxもあります。
  • 仮想ゲストにRHELはないです。CentOSを使いましょう。
  • 仮想ゲストにWindowsは使えないです。Windowsを使いたい場合は、同じホスト上にKVMで動かしましょう。
  • 1サーバに数十コンテナをのせるということは、サーバが故障した時の影響が大きいです。
    • しっかりコンテナの配置を考えましょう。
    • 要求に応じて、できる限り壊れにくいサーバ、ファームアップデートなどで停止が少ないサーバを選びましょう。