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

前回の記事では、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とハイパーコンバージドインフラストラクチャとの関係理解の助けになれば幸いです。