Edited at

低コストで実現!OSSハイパーコンバージドインフラ

More than 1 year has passed since last update.


概要

NutanixやHPE SimpliVityやVMwareなどハイパーコンバージドインフラが人気です。

ハイパーコンバージドは、サーバ、ストレージ、ネットワークを集約した仮想基盤になります。

ハイパーコンバージドを導入することによって、高可用性、高密度、運用効率向上になります。

ただ、どのベンダーから出ている製品も豪華構成であり、ものすごい高額な製品になっています。

そこで、オープンソースでも同じような構成ができないか考えましたので紹介します。

OSSハイパーコンバージドインフラです。


OSSハイパーコンバージドインフラとは

一般的なOSSと一般的なx86サーバを使うことによって、ハイパーコンバージド仮想基盤を作ります。

基本は2ホスト構成のActive/Activeで、1ホストが故障した場合、別のホストから起動できるようにします。

ゲストOSがのっている領域は、分散ファイルシステム(GlusterFS)で両ホストから同じデータがみえるようにします。

推奨OSS


  • Linux (CentOSでもUbuntuでも可能です。)

  • GlusterFS (分散ファイルシステム)

  • LXC(システムコンテナ)

  • KVM(ハイパーバイザー ) ※Windowsを動かしたいなど必要があれば


OSSハイパーコンバージドインフラの特徴


プラス評価


  • 高可用性


    • 2ホスト構成で、1ホストが故障しても、別のホストからゲストOSを起動できます。



  • 低コスト


    • x86サーバ2台から作れます。

    • x86サーバは、好きなベンダーを使いましょう。(HPEでも、DELLでも、Huaweiでも、Supermicroでも大丈夫です)



  • シンプル構成


    • GlusterFS/LXC/KVMという一般的で、長年の実績のあるOSSを利用します。

    • シンプルな構成のため、仮想ホストのリプレースもやりやすいです。
      別の2台構成のOSSハイパーコンバージドを用意しておき、ゲストを移動させるだけです。



  • 大掛かりな構成ではないので、パフォーマンスの問題が発生した時にも、構成を変えやすいです。


    • 例えば、HDDからSSDに変更する。

    • 例えば、仮想ゲストの数を変更する。

    • 例えば、どうしてもパフォーマンスがでないなら、GlusterFSをやめる




マイナス評価


  • 性能はそこまでよくはありません。


    • ネットワークで両ノードにデータを書き込む分散ファイルシステムのためです。
      商用ハイパーコンバージドでも同じように性能は高くないです。
      ただし、OSSハイパーコンバージドは、IOが遅いKVMなどのハイバーバイザーではなく、
      LXCのコンテナを使うことでできる限りIO性能を克服しようとしています。





サーバ構成


ハードウェアイメージ図

LXC+GlusterFS_hardware.png


  • 構成はあくまで例です。コストや利用状況によって全然違います。


ディスク利用イメージ図

OSS-HCI_disk.png


  • 2ホスト構成で、1ホストが故障しても、別のホストから起動できるようにします。

  • GlusterFS領域を作り、LXC用ディレクトリと、KVM用ディレクトリを作ります。
    KVM不要なら、LXCディレクトリのみです。

  • 仮想化がLXCだけなら数十個のコンテナをのせることができるでしょう。


GlusterFSを使う理由


  • 分散ファイルシステムを使い、1ホストが故障しても、別のホストで同じデータが見えるようにします。

  • GlusterFSは、マスターレスで扱いやすいです。

  • GlusterFSは、2台から構成できます。管理サーバも不要です。

  • RedHat商用製品のRed Hat Gluster Storageの分散ストレージソフトウェアがGlusterFSです。


LXCを使う理由


  • 仮想化には、システムコンテナのLXCを使います。
    コンテナで有名なDockerはアプリケーションコンテナなので、用途が違います。

  • LXCの軽量コンテナにすることによって、1ホストに数十コンテナがのります。

  • LXDは高機能ですが、複数ホストで同じ領域を管理することができなそうなため、シンプルなLXCを使います。

設定方法


  • /var/lib/lxcをGlusterFSにして、両ホストから同じファイルが見えるようにします。

注意


  • LXDではなく、Directory BackendのLXCなので、OS停止しないとスナップショットは取得できないです。

  • LXDではなく、Directory BackendのLXCなので、OS CloneもOS停止が必要です。


KVMを使う理由

LXCと同時に、KVMも利用することもできます。

CentOSを使う場合は、LXCの方が軽量で多くのゲストOSを乗せられるため、オススメですが、

RHELやWindowsを使いたい場合には、KVMも使うことができます。

GlusterFSは大きいサイズのファイルも得意のため、50GBのKVMイメージでも利用できます。


その他


ネットワーク


  • ホスト間は、直結のBondingにします。


    • どのくらいの帯域が必要かによって、Bondingのやり方がちがいます。

    • active-backup(mode=1)がシンプルです。

    • ラウンドロビン(mode=0)にすることによって、1G2本で2G、4本で4Gのスピードになるようにもできます。

    • リンクアグリゲーション(mode=4)にしても、1本しか使えないので注意が必要です。





OSSハイパーコンバージドの利用場面


Active/Standby構成の代替

■1ホストだけで高可用性を実現

Active/Standby構成ですと、設定はすべてお互い同期されているのか?

アプリはVIPで接続に来ているのかなど、

スタンバイ切り替わった時に問題ないのか不安になります。

ホストの問題発生時には、同じイメージを別ホストから起動できる効果は大きいと思います。

■クラスターソフト不要で高可用性を実現

Active/Standbyを実現するためのクラスターソフトは設定や仕様が難しいミドルウェアであり、

デファクトスタンダードのクラスターソフトもありません。

全ての機能、パラメータを知っているわけではないので、変な動きをしないか不安になります。

テストでは問題なかったのに、いざという時に動かないこともあります。

OSSハイパーコンバージドなら、クラスターソフト不要で高可用性構成のシステムを作れます。

1ホストで起動していたLXCのサーバが、問題が発生しましたら、

自動で別のホストでLXCを起動するようにシェルスクリプトを組むのです。

LXCのコンテナなら、5秒以内には起動してくれるでしょう。

■共有ボリューム不要で高可用性を実現

同じイメージを起動することによって、共有ディスク不要のシンプルな構成が作れます。

ストレージやFCSWのメンテナンスの影響を受けなくなります。


社内システムサーバ、開発サーバ

社内システムサーバや開発サーバではコストの関係から、1台構成のことも多いです。

サーバが故障した場合、修理するまでに時間がかかってしまいます。

OSSハイパーコンバージドにすることによって、別ホストからも起動できるため、利用者に影響を与えことが少ないです。