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

#概要
NutanixやHPE SimpliVityやVMwareなどハイパーコンバージドインフラが人気です。
ハイパーコンバージドは、サーバ、ストレージ、ネットワークを集約した仮想基盤になります。
ハイパーコンバージドを導入することによって、高可用性、高密度、運用効率向上になります。
ただ、どのベンダーから出ている製品も豪華構成であり、ものすごい高額な製品になっています。

そこで、オープンソースでも同じような構成ができないか考えましたので紹介します。
OSSハイパーコンバージドインフラです。


#OSSハイパーコンバージドインフラとは
一般的なOSSと一般的なx86サーバを使うことによって、ハイパーコンバージド仮想基盤を作ります。
基本は2ホスト構成のActive/Activeで、1ホストが故障した場合、別のホストから起動できるようにします。
ゲストOSがのっている領域は、分散ファイルシステム(GlusterFS)で両ホストから同じデータがみえるようにします。

**推奨OSS**

- Linux (CentOSでもUbuntuでも可能です。)
- GlusterFS （分散ファイルシステム）
- LXC（システムコンテナ）
- KVM（ハイパーバイザー ）  ※Windowsを動かしたいなど必要があれば


#OSSハイパーコンバージドインフラの特徴
##プラス評価
- 高可用性
  - ２ホスト構成で、１ホストが故障しても、別のホストからゲストOSを起動できます。
- 低コスト
  - x86サーバ2台から作れます。
  - x86サーバは、好きなベンダーを使いましょう。（HPEでも、DELLでも、Huaweiでも、Supermicroでも大丈夫です）
- シンプル構成
  - GlusterFS/LXC/KVMという一般的で、長年の実績のあるOSSを利用します。
  - シンプルな構成のため、仮想ホストのリプレースもやりやすいです。<br> 別の2台構成のOSSハイパーコンバージドを用意しておき、ゲストを移動させるだけです。
- 大掛かりな構成ではないので、パフォーマンスの問題が発生した時にも、構成を変えやすいです。
  - 例えば、HDDからSSDに変更する。
  - 例えば、仮想ゲストの数を変更する。
  - 例えば、どうしてもパフォーマンスがでないなら、GlusterFSをやめる

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



<br>
#サーバ構成
##ハードウェアイメージ図

![LXC+GlusterFS_hardware.png](https://qiita-image-store.s3.amazonaws.com/0/156368/601ab716-79bc-81ae-0260-3d0d05ca5b45.png)

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

##ディスク利用イメージ図

![OSS-HCI_disk.png](https://qiita-image-store.s3.amazonaws.com/0/156368/3719db61-fa06-aa0d-b907-7bd9b30c5e8a.png)


  - ２ホスト構成で、１ホストが故障しても、別のホストから起動できるようにします。
  - GlusterFS領域を作り、LXC用ディレクトリと、KVM用ディレクトリを作ります。<br>KVM不要なら、LXCディレクトリのみです。
  - 仮想化がLXCだけなら数十個のコンテナをのせることができるでしょう。

##GlusterFSを使う理由

  - 分散ファイルシステムを使い、１ホストが故障しても、別のホストで同じデータが見えるようにします。
  - GlusterFSは、マスターレスで扱いやすいです。
  - GlusterFSは、2台から構成できます。管理サーバも不要です。
  - RedHat商用製品のRed Hat Gluster Storageの分散ストレージソフトウェアがGlusterFSです。



##LXCを使う理由

  - 仮想化には、システムコンテナのLXCを使います。<br>コンテナで有名なDockerはアプリケーションコンテナなので、用途が違います。
  - LXCの軽量コンテナにすることによって、１ホストに数十コンテナがのります。
  - LXDは高機能ですが、複数ホストで同じ領域を管理することができなそうなため、シンプルなLXCを使います。

**設定方法**

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

**注意**

  - LXDではなく、Directory BackendのLXCなので、OS停止しないとスナップショットは取得できないです。
  - LXDではなく、Directory BackendのLXCなので、OS CloneもＯＳ停止が必要です。


##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)にしても、１本しか使えないので注意が必要です。

<br>
#OSSハイパーコンバージドの利用場面
## Active/Standby構成の代替

**■１ホストだけで高可用性を実現**
Active/Standby構成ですと、設定はすべてお互い同期されているのか？
アプリはVIPで接続に来ているのかなど、
スタンバイ切り替わった時に問題ないのか不安になります。
ホストの問題発生時には、同じイメージを別ホストから起動できる効果は大きいと思います。

**■クラスターソフト不要で高可用性を実現**
Active/Standbyを実現するためのクラスターソフトは設定や仕様が難しいミドルウェアであり、
デファクトスタンダードのクラスターソフトもありません。
全ての機能、パラメータを知っているわけではないので、変な動きをしないか不安になります。
テストでは問題なかったのに、いざという時に動かないこともあります。

OSSハイパーコンバージドなら、クラスターソフト不要で高可用性構成のシステムを作れます。
１ホストで起動していたLXCのサーバが、問題が発生しましたら、
自動で別のホストでLXCを起動するようにシェルスクリプトを組むのです。
LXCのコンテナなら、5秒以内には起動してくれるでしょう。


**■共有ボリューム不要で高可用性を実現**
同じイメージを起動することによって、共有ディスク不要のシンプルな構成が作れます。
ストレージやFCSWのメンテナンスの影響を受けなくなります。


##社内システムサーバ、開発サーバ
社内システムサーバや開発サーバではコストの関係から、１台構成のことも多いです。
サーバが故障した場合、修理するまでに時間がかかってしまいます。
OSSハイパーコンバージドにすることによって、別ホストからも起動できるため、利用者に影響を与えことが少ないです。