SLAを満たそうとするあまり、ストレージをオーバープロビジョニングしてしまったり、パフォーマンスの調整に追われたりしていませんか?　ティントリの自動QoSなら、ストレージのパフォーマンスをしっかりと維持させることができます。

キー ポイント

  • ITチームが統合を進めれば進めるほど、ストレージにおけるQoSの重要性が増す
  • QoSには自動化だけでなく、ワークロードのI/Oの下限値と上限値を設定できる制御機能や、VMレベルやコンテナレベルでの運用機能が期待されている
  • ティントリは、簡単に利用できる自動QoSときめ細かい手動での制御をニーズに合わせて提供し、予測分析による完全な可視化を実現することで、忙しいIT担当者が簡単にパフォーマンスを管理できるようにしている

ティントリのエンタープライズクラウドプラットフォームは自律運用を見据えて設計されており、これをご利用いただくことで、IT担当者は手間のかかる煩雑なインフラストラクチャ管理から手が離れ、本来の重要な業務にこれまでより多くの時間を使えるようになります。

自律運用では、ソフトウェアがインフラストラクチャの管理を行います。先日投稿した「自律運用でストレージ管理を簡略化しましょう」という記事では、ティントリが提供する自律機能の概要と自律運用に対するティントリの考えをお伝えしました。今回はこの話をより深く掘り下げるために、自動Quality of Service(QoS)について取り上げたいと思います。

ストレージのパフォーマンスという点でのQoSの重要性

IT部門の多くは、インフラストラクチャを最新のものにし、ワークロードを統合し、運用を効率化することを優先事項の1つとして挙げています。このニーズを満たすためにお勧めなのが、QoSを取り入れることです。もし、同じストレージを使っている複数のワークロードのパフォーマンスが予測できるものでなければ、ワークロードを統合するのは非常に難しくなります。QoSのほかにも、ストレージをオーバープロビジョニングするという方法もありますが、一昔前の手法であるため、あまりお勧めはできません。

QoS機能を提供しているストレージベンダーは多くありますが、その実装方法はさまざまです。ストレージのQoSにはどのような機能が必要だと思いますか?　以下に検討すべきポイントをご紹介します。

  • 自動QoS: 何事にもいえることですが、重要なのはタイミングと方法を見極めることです。QoSはそのまますぐに使えるのが理想なため、通常は特別な設定をすることなく自動で調整されるものがお勧めです。
  • きめ細かいレベルで動作するかどうか: QoSのほとんどは、LUNまたはボリュームレベルで動作します。しかし、自動QoSによってノイジーネイバー(うるさい隣人)が制限されると、問題のないVMにまで不必要な影響が及ぶ可能性があります。10～40台のVMが含まれるLUNにQoSを設定してもあまり意味がないと考えられるため、それらの環境でQoSのメリットを得るには、注意深くストレージを管理する必要があります。
  • 上限値の設定: ほとんどのQoSでは、IOPSの上限値や消費可能な最大帯域幅を設定できます。
  • 下限値の設定: ごく一部のQoSでは、IOPSの下限値や消費可能な最低帯域幅を設定し、ワークロードごとに最低限のパフォーマンスを維持することができます。自動QoSによって重要なワークロードに過負荷制限が行われる場合、この機能は特に重要です。
  • 分析機能: 分析機能がなければQoSのメリットを十分に得ることはできません。分析機能は運用状況を把握したり、適切な対処を行うのに便利なだけでなく、明確に定義されたQoSの基準に基づいて実施した、調整の効果をリアルタイムに把握することができます。

さらに、QoSの設定しやすさと利用しやすさも考慮すべきです。環境内に配置されるVMの数は数百にも数千にもなることがありますが、もしそのVMひとつひとつにQoSの制限値を決めなければならないほど設定が複雑であれば、業務が瞬く間に混乱してしまいます。

ティントリの自動QoS

ティントリの自動QoSでは、VMひとつひとつに値を設定しなくても、すべてのVMが高いパフォーマンスを維持できるようになります。自動QoSはVMレベルで動作し、"ノイジーネイバー(うるさい隣人)"がほかのワークロードを妨げることがないよう自動で制御できるので、LUNの中でのロードバランシングについて、あるいはさまざまな種類、サイズ、数のVMをどう配置するかについて、管理者が気にする必要はありません。ティントリの自動QoSが適切に対処してくれるため、管理業務が大幅に簡略化、削減されるほか、詳細な制御が必要な場合には、それを行うことも可能です。

ティントリの自動QoSには、以下のような機能があります。

  • VM単位でパフォーマンスを分離: ティントリのQoSスケジューラは、VMごとにI/Oキューを用意しており、各VMのI/O要求サイズと要求ごとのオーバーヘッドを基にシステム内のすべてのI/Oについてコストを判定します。各I/OキューのI/Oは、このコストに比例した形でパイプラインにスケジューリングされ処理されるので、リソースが公平に割り当てられます。これは、VMレベルの可視性がないストレージでは提供できない機能です。
  • VM単位でパフォーマンスを保護: 個々のVMあるいは複数のVMに対して必要に応じて最小または最大のパフォーマンスを設定できるので、状況に合わせてきめ細かく制御することができます。

ティントリの機能を利用すれば、通常の運用時にすべてのVMで良いパフォーマンスを維持できるようになります。また、手動のQoS制御を設定した場合には、それに応じた保証や制限を確実に適用することができます。VMレベルで完全にパフォーマンスを把握できるため、パフォーマンスに問題がある場合はそれを簡単に特定し、必要な措置を取ることができます。

こうしたティントリのアプローチによって、QoSは非常に使いやすいものになりました。機能の設定はほとんどの場合、一切行う必要がありません。ただし、機能を個別に設定して、次のようなさまざまな状況に対処することもできます。

  • 予想以上に負荷の高いVMに対して過負荷制御を行いたい: 予想以上に負荷の高いVMがパフォーマンスを大量に消費するような場合でも、ティントリのストレージでは従来のストレージで発生していたようなパフォーマンスの低下が発生することはありません。ただし、クラウドサービスプロバイダーなどの特定のユースケースでは、過負荷制御を行うことが適切な場合があります。
  • 重要なVMのパフォーマンスを保証したい: 例えば、自動QoSで対処しきれずリソース競合が発生してしまった場合には、1台または複数のVMにIOPSの下限値を設定することで、重要性の高いワークロードに必要なリソースを確実に割り当てられるようになります。
  • サービスレベルを分けて運用したい: ティントリのQoSでは、サービスレベルの作成やチャージバックの設定が簡単で、レベルごとに異なるストレージを用意する必要もありません。このため、サービスプロバイダーを変更したりサービスとしてのIT(IaaS)モデルに移行しようとしている企業にとって非常に便利です。
  • 遅延の原因を特定したい: シンプルで強力な可視化機能を使って、遅延の原因を正確に特定できるため、問題の発生源に対しピンポイントで即座に対策が取れるほか、トラブルシューティングも簡単です。

効果的なアプローチでパフォーマンスを保証

ティントリの自動QoSでは、すべてのVMでパフォーマンスの予測が可能になります。また、きめ細かく制御することが可能なため、重要性の高いワークロードにはパフォーマンスを保証し、重要性の低いワークロードにはリソース消費量を制限する、というそれぞれの設定を行うことができます。さらに、従来のエンタープライズアプリケーションだけでなく、次世代のアプリケーションやサービスなどさまざまなワークロードを同じストレージシステムに統合できるため、ノイジーネイバー(うるさい隣人)の影響を心配したり、オーバープロビジョニングを行ったりする必要もありません。

※本コラムは、ティントリジャパンに掲載されたブログ記事より転載したものです。

[PR]提供：