Edited at

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

More than 1 year has passed since last update.

どのようにサーバ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サーバに数十コンテナをのせるということは、サーバが故障した時の影響が大きいです。


    • しっかりコンテナの配置を考えましょう。

    • 要求に応じて、できる限り壊れにくいサーバ、ファームアップデートなどで停止が少ないサーバを選びましょう。