オンラインストレージをSDSとownCloudとのハイパーコンバージド構成で作ってみる

Own Cloud  Converged Integration

前回の記事では、ownCloudとIzumoFSを別々のサーバにインストールしましたが、今回はownCloudを冗長化し、かつシステム全体でのサーバ台数を減らすことのできるハイパーコンバージド構成で、オンラインストレージを作ってみました。

ハイパーコンバージド構成のメリット

  • システム全体のサーバ台数を抑え、スモールスタートが可能
  • 構成がシンプルでシステム全体としての拡張、冗長化や負荷分散の設計・運用が容易
  • ownCloudとIzumoFS間の通信でネットワークレイテンシの発生が抑えられ、性能向上が期待できる

システム構成

システム構成

IzumoFSとownCloudを同一筐体に同居させる構成です。IzumoFSとownCloudをインストールするサーバを3台を用意しました。ユーザからはロードバランサー経由でownCloudにアクセスするようにします。各サーバのスペックはCPU:4コア、メモリ:14GB、HDD容量:1TBで、OSはCentOS 7.2を利用しています。また、ownCloudをクラスタ化するためにMariaDB Galera Clusterを利用しました。

構築

IzumoFSインストール事前準備

パーティション設定などIzumoFSインストールの事前準備を行います。

作業時間:約25分

IzumoFSクラスタを3台構成で構築

実効容量は1TB。

作業時間:約10分

システム構成

IzumoFSクラスタ上にNFS共有フォルダを作成する

IzumoFSの管理画面でプロトコルとしてNFSを選択して共有フォルダを作成するだけで、特別なゲートウェイなしにNFSを使うことができます。

システム構成

システム構成

IzumoFSのNFS共有フォルダをマウントする

$ sudo mkdir /mnt/shared_folder
$ sudo chmod 770 /mnt/shared_folder
$ sudo mount -t nfs 127.0.0.1:/izumofs-owncloud-hyper /mnt/shared_folder

ownCloudクラスタを構築

IzumoFSがインストールされているサーバにownCloudをインストールしていきます。

  1. Apache httpd のインストール
  2. PHPのインストール
  3. MariaDB Galera Clusterのインストール
  4. ownCloudのインストール
  5. ownCloud 用のユーザーとデータベースを MariaDB に登録

作業時間:約30分

システム構成

ハイパーコンバージド構成のownCloudを使ってみる

ログインするノードを指定するため、ノードのアドレスを指定して直接ログインします。どのノードのownCloudにログインしても同じ内容のものが見えるか確認しました。

ノード1のownCloudにファイル(468.8MB)をアップロードします。数秒でアップロード完了。

サーバ1のownCloudの画面:

システム構成

ノード2のownCloud画面でもノード1でアップロードしたファイルが見えます。

システム構成

ノード3のownCloud画面でもノード1でアップロードしたファイルが見えます。

システム構成

IzumoFSの管理画面を確認すると、IzumoFSにデータが保存されていることがわかります。

システム構成

ハイパーコンバージド構成のオンラインストレージが構築できました。

オンラインストレージをスケールアウト(IzumoFS + ownCloud)してみる

ノード追加によりシステム全体がスケールアウトができるか試してみました。IzumoFSとownCloudがインストールされたノードをクラスタに追加します。

システム構成

IzumoFSノードを追加する

IzumoFSとownCloudをインストールしたノードをクラスタに追加します。

システム構成

システム構成

IzumoFSのNFS共有フォルダをマウントする

$ sudo mkdir /mnt/shared_folder
$ sudo chmod 770 /mnt/shared_folder
$ sudo mount -t nfs 127.0.0.1:/izumofs-owncloud-hyper /mnt/shared_folder

ownCloudの設定を行う

ownCloudのデータフォルダの設定とDBアクセスの設定を行います。

システム構成

追加したノードのownCloud画面から他のノードと同様のファイルが見えました。

システム構成

追加したノードからアップロードしたファイルも他のノードから見ることができます。

追加したノードのownCloud画面:

システム構成

ノード1のownCloud画面:

システム構成

これでownCloud + IzumoFSのサーバを4台クラスタリングできました。前回の記事ではownCloudサーバ1台と、IzumoFSサーバ4台による構成でしたが、それに比べるとサーバ数が計5台から4台に減っているにもかかわらず、ユーザがアクセスできるownCloudサーバが1台から4台に増えた形となり、ownCloud側の可用性が向上していることがわかります。

障害が発生しても操作が継続できるか確認してみました

1台のノードに障害が発生した場合、データがなくなっていないか他のノードでownCloudの操作が続行できるかをみるため、1台のノードのOSをシャットダウンしてみました。

システム構成

アクセスしているノードを確認する

ロードバランサー経由でアクセスしているノードを確認します。ファイルをアップロードしている際に、IzumoFS管理画面のモニタリング画面でどのノードに書き込みが行われているかを見ることで、アクセスしているノードを確認します。

システム構成

ノード1に書き込みが発生していることからノード1にアクセスしていることがわかります。

アクセスしているノードに障害を発生させる

ノード1のOSをシャットダウンさせることでノード1に障害を発生させます。障害発生直後は、ownCloudにアクセスできなくなりますが、ロードバランサーが5秒ごとにノードの生存確認を行なう設定にしているので、数秒で稼働しているノードにアクセスが切り替わり、再びownCloudにアクセスできるようになりました。

障害発生直後の画面:

システム構成

数秒後にownCloudに再びアクセスできるようになりました。

システム構成

IzumoFSの管理画面ではダウンしたノードが「応答なし」のステータスになっています。

システム構成

ノード障害が発生しても、稼働している残りのノードでownCloudの操作を続けることができ、オンラインストレージの可用性が向上していることが確認できました。

さいごに

今回は他のアプリケーションと同居が可能であるというSDSの特徴を生かして、IzumoFSとownCloudとのハイパーコンバージド構成でオンラインストレージを構築しました。ownCloudに限らず、様々なアプリケーションでもハイパーコンバージド構成が有用な場合がありますので、アプリケーション特性に応じてご検討いただければと思います。またSDSによっては、IzumoFSとは違い構成が複雑なものや構築・運用負荷が高いものもありますので、各SDSの特徴を見極めて選択いただければと思います。

最近キーワードとしてよく聞かれるハイパーコンバージドインフラストラクチャですが、その実態はSDSの構成方法の一形態といえます。本記事が、SDSとハイパーコンバージドインフラストラクチャとの関係理解の助けになれば幸いです。

* この記事は実験を目的としており、動作を保証するものではありません。

* IzumoFSは、IzumoBASEの登録商標です。

* その他記載の会社名および商品名は、各社の商標または登録商標です。