既存のクラウドストレージの課題

神尾皓氏：神尾と申します。まず自己紹介させてください。

入社以来一貫してOpenStack関連業務に従事していて、普段はOpenStackベースのプライベートクラウドの開発やハイパーバイザーの最適化、パフォーマンスチューニングをメインとしています。

では、本題に入ります。アジェンダについては「既存のクラウドストレージの課題」「Yahoo! JAPANの新しいクラウドストレージ」「クラウドステージのこれから」の順で進めたいと思います。

では、まず「既存のクラウドストレージの課題」です。先ほど奥村から話がありました通り、現在Yahoo! JAPANでは多くのOpenStackのクラスタが存在し、さらにKubernetesのクラスタがそのOpenStack上で走っています。そして、その上のさまざまなサービスのインフラとして利用されています。

当然、各OpenStackや各Kubernetesのバックエンドにあるストレージは非常にたくさん存在します。

それこそ先ほどOpenStackの説明であったように、162のクラスタに対してさらにそのコンポーネント毎に異なるバックエンドストレージが存在するので、それだけたくさんのクラウドストレージが存在しています。

これらはオペレーションコストの増大につながります。コンポーネントの数だけさまざまなストレージシステムが存在するからです。

続いて、新しいクラウドストレージについてお話しします。

新しいクラウドストレージへの取り組みとして、SDSに取り組んでいます。従来のアプライアンスストレージには、その導入までのリードタイムが長い、または、構成を後から変えることが難しいのでスモールスタートしにくいというデメリットがありました。

そこでSDSを用いて、通常の汎用機・汎用のサーバでソフトウェアを使ってストレージを組むといったソリューションです。

この場合、汎用のサーバを用いるため導入までのリードタイムが短く、さまざまな構成をとることができるので、サーバの構成の面やサーバ全体の構成においてフレキシブルです。さらにストレージノードの追加だけでスケールすることが実現できるので、非常にスケーラブルというのがメリットかなと思います。

新しいクラウドストレージをつくる

続いて、私たちが探していたストレージについてお話ししたいと思います。先ほどもお話ししたようにOpenStackであれば、ObjectのSwift、BlockのCinder、File StorageのManila、またKubernetesのPersistent Volumeとしてのバックエンドのストレージといった、主に扱っているこの4種類のストレージのシステムがありました。

これらのストレージのシステムに対して、すべてに利用できるようなストレージを探していました。

そして、さまざまなSDSの製品を検証した結果、Quobyteというストレージシステムを選択しました。

さまざまなストレージをバックエンドにしていたそれぞれのストレージを、1つのストレージのアーキテクチャに統一することでオペレーションの負荷を軽減できると考えています。

Quobyteの各ストレージのバックエンドとしての振る舞いを見ていきます。

まず、Object Storageとして使う場合です。

Object Storageとして使う場合には、Quobyteの提供するS3 ProxyというS3互換APIを用いて、VMが直接APIにアクセスします。

続いて、OpenStackのCinder。Block Storageとして利用する場合のユースケースです。

この場合では、ハイパーバイザーでファイルストレージとしてマウントしたあと、そこにQCOW2などのQEMUのバッキングファイルをここに配置して、それをQEMUがブロックデバイスとしてアタッチします。

こちらはOpenStackのManila、ファイルストレージとして使う場合です。

この場合は、QuobyteがNFS proxyというNFSをプロキシするための仕組みを持っているので、VMから直接NFSマウントすることができます。

KubernetesのPersistent Volumeとして使う場合です。

KubeNodeにファイルストレージとしてマウントしたあと、それらを直接PodからPersistent Volumeとしてコンテナから見せています。

SDSを運用する上でのチャレンジ

続いて、SDSを運用する上でのチャレンジについて、お話ししていきます。

まず挙げられることは、アプライアンスストレージに比べて運用が難しいということが一般に言えるかなと思います。

SDSというのは分散システムになってきますので、システムのFail-OverやPartition、Split-Brainといった、分散システムでよく挙げられる難しさがあると思います。

また、ネットワークがストレージのバックプレーンになるところが大きく違っているかなと思います。これまでだとストレージの内部バスや専用のインターコネクトに流れていたような通信が、イーサネットのEAST-WESTのトラフィックになってくるところがポイントです。

それに対して、SDSを運用する上で一番重要なポイントがネットワークです。

先ほど話したEAST-WESTに広帯域なネットワークとしてClos Networkを採用しています。

また、ネットワークの監視の面で、従来のNICのエラーカウンタ監視を行っていたのに加えてPingmesh監視を用いています。

この右の図がPingmeshのモニター画面のスクリーンショットです。縦軸横軸がそれぞれのサーバに対応していて、その当たったマスが、それぞれのpingのレイテンシーがそのまま緑や赤で表現されています。

平常時は左のように全部緑で、なにか問題があったとき右のように「このサーバがおかしそうだ」と視覚的にわかるのがメリットです。

システム構成図

次に、今回構築したシステムについてお話しします。こちらがシステムの構成図です。

Clos Networkの上に構築していて、それぞれのストレージノードまでL3が伸びてきていて、それぞれのノードで経路交換して、そのL3で冗長をとっている構成です。

L3で冗長を取ることで、これまでLeaf SwitchでL2の状態、Switch間でMLAGのような機能が必須でしたが、L3を喋ることでそのような機能が特に必須な要件にならず、Switchの選択肢が広がったのもメリットかなと思います。

こちらがシステムの概要ですが、詳しい内容についてはOpenStack Summit Berlinの方で発表していますので、気になる方はそちらをご覧いただければ幸いです。

今回構築したソフトウェアストレージのパフォーマンスについて少し見ていきます。こちらはクライアントが1ノードのときのRead性能です。

比較対象はLocalのNVMeを比較対象としています。図の右側がSequential Readで、図の左側がRandom Readの結果になっています。

Sequential Readですと圧倒的にNVMeの方が性能がいいのですが、Random ReadではNVMeに比べても遜色ない性能が出ているかなと思います。これはQuobyteが分散ストレージで分散のIOに強いからです。

次にWriteの性能です。

こちらもSequential WriteはNVMeの方がいいですが、Random WriteはNVMe並か、それ以上の性能が発揮できています。

気になるストレージとしての性能です。

こちらが全体のストレージのRead性能です。Read IOPSが1000kIOPS以上、PeakのReadの帯域が40GB/s以上と、オールフラッシュストレージ並みの性能が出ているのかなと思います。

続いてWriteです。

Writeも300kIOPS・12GB/sと十分な性能が出ています。これらのパフォーマンス測定の条件は、先ほど言ったOpenStack Summitの動画を見ていただけますと幸いです。

クラウドストレージのこれから

次に「クラウドストレージのこれから」についてお話しします。

繰り返しになりますが、従来のクラウドストレージではそれぞれOpenStackやKubernetesのクラスタのバックエンドごとにストレージというものが存在していて、オペレーションコストの増大につながっていました。これらを1つのアーキテクチャに統一していくことで、オペレーションコストを下げていくことができると考えています。

さらに、OpenStackクラスタやKubernetesのストレージを集約していくことで、さらに効率のいい運用ができるかなということを期待しています。

SDSの柔軟性やストレージ設計・構成の最適化を行っていて、1つのストレージアーキテクチャに統一することでオペレーションコストの削減ができると考えています。

最後に、クラウドストレージのまとめになります。

既存のクラウドストレージは、クラスタ／コンポーネントごとに用意されていたため、運用や管理が非常に煩雑でした。SDSは構築完了までのリードタイムが短く、さらに柔軟な構成が取れるため、あとからの構成の変更なども比較的容易です。今後は、適材適所でSDSに置き換えていくことで、クラウドストレージ全体の設計や構成の最適化を行っていきます。

続きまして、「ネットワーク運用の取り組み」を安藤が発表いたします。

Occurred on , Published at