DB管理者とインフラ管理者の長年の問題を解決するTintriのSQL Integrated Storage

DB管理者（DBA）とインフラストラクチャ管理者は、リソースの要件について長年課題を抱えています。一方が1秒あたりのトランザクションや待ち時間について話せば、もう一方がLUNとIOPSについて話すという具合で議論が噛み合いません。実際、多くの場合インフラストラクチャチームは、DBがこれほど多くのリソースが必要な理由を理解していないため、こうした議論に発展しがちです。特定のワークロードを実行するために実際に必要なリソースがわからないというのは、よくある問題です。このブログでは、こうした現実に対処し解決を支援するTintriのSQL Integrated Storageを紹介します。SQL Integrated Storageは、データベースのストレージとインフラストラクチャに大変革をもたらします。
Tintriが仮想マシン専用のストレージを提供していることはご存じだと思いますが、Tintriのストレージは従来ストレージとはまったく異なるコンセプトで設計されています。Tintriは、この技術を活かしSQL Serverデータベース用に設計したストレージSQL Integrated Storageを提供します。

SQL Integrated Storageの変革
Tintriは、仮想マシン向けのインテリジェント・インフラストラクチャのパイオニアであり、仮想マシンレベルでのストレージの自動管理を実現しています。仮想マシンは、メタデータを含むファイルの集合であり、ハイパーバイザと密接に関係しています。データベースも、メタデータを含むファイルの集合であり、RDBMSと密接に関係しています。そこで、データベースファイルの管理に、仮想マシンで実績のある同じテクノロジを使用したらどうなるでしょうか。
標準インフラストラクチャでは、データベースは仮想ディスクであるドライブ上に配置されます。仮想ディスクはデータストアに保存され、このデータストアはストレージシステムのLUNまたはボリュームの内部に配置されます。つまり、データベースは3つの層の下に埋め込まれています。ストレージ操作が必要な場合、このすべての層を通る必要があります。しかも、すべてのストレージタスクは、データベース単位ではなく、ストレージユニット単位で行われます。
SQL Integrated Storageでは、これがすべて変わります。SQL Serverがストレージに求めるすべてのものが、データベースレベルで管理できるようになるのです。

SQL Integrated StorageがDBAに提供する従来とは全く異なるストレージ管理

SQL Integrated Storageでは、各データベースファイルは、ストレージシステムへの独自のパスとキューで個別に管理されます。これにより、データベースを異なる方法で管理し、これまでにないレベルでパフォーマンスを追跡できます。データベースをSQL Integrated Storageに移行すると、DBAとインフラストラクチャチームは単一のUIで全データベースのパフォーマンス値を確認し、パフォーマンスのホットスポットをすばやく特定して、必要なアクションを決定できるようになります。

ストレージはデータベース単位で管理可能となりサービスグループを使用して保護ポリシーを設定できるようになるため、スナップショットとレプリケーションに関してデータベース向けにより詳細な設定が可能になります。LUN単位やボリューム単位ではなく、データベース単位で設定を行えるため、任意のレベルで柔軟にデータベースを保護することができます。さらに、サービスグループを使用すると、定義した基準を満たすすべてのデータベースにこれらのポリシーを自動的に適用できます。新しいデータベースが追加された場合、定義された基準を満たしていれば、保護ポリシーが自動的に適用されます。スナップショットからの復旧にも数秒しかかからず、別のサーバーにオンラインで戻すこともできます。

SQL Integrated Storageではクローンは当たり前に活用できるものになります。ストレージについてあれこれ考える代わりに、全体としてどのように管理するかについて検討できるようになります。本番データベースの完全なコピーを下位のテスト／開発／Q&A環境のいずれかに1分もかからずに複製できることを想像してみてください（この時間には、タスクを実行するTintri Global Centerへのログイン時間も含まれます）。これをデータベース単位またはデータベースグループで、1台のサーバーだけでなく複数のサーバーに対しても実行できます。追加のストレージを消費することなく、必要な数のコピーを作成してから、これらのデータベースへの変更を開始します。各開発者はデータベースの完全なコピーを数秒で作成できるため、環境を共有する必要がなくなります。生産性は大幅に向上します。

SQL Integrated Storageを使用すると、日常的なメンテナンスタスクの負担も軽減できます。
データベースの完全な整合性チェックは夜間に実行することを強くお勧めしますが、それでも多くのリソースを消費し、本番環境に影響します。SQL Integrated Storageを使用すれば、データベースを別のSQL Serverに複製し、本番環境とまったく同じストレージブロックのセットを使用して、本番環境に影響を与えることなくCheckDBを実行できます。CheckDBが毎晩実行できるようになり、夜間の完全バックアップの負担も軽減できます。

こうした新しい環境を導入すると、管理が問題になってくる可能性があります。SQL Integrated Storageには完全なREST APIが用意されており、スクリプト作成や既存ツールへの統合が可能（DevOPSやCD/CIに使用するものとの完全な統合など）です。シンプルながらも機能豊富なPowerShell Toolkitが間もなく利用可能になり、これらの機能のすべてがPowerShellに拡張されます。DBAと開発者は、RESTやPowerShellを使用して、スナップショット、クローン作成、レプリケーションなどのタスクをスクリプト化できるようになります。自動化を有効にすることも検討してみてください。

インテリジェント・インフラストラクチャでは環境の自動調整が必要ですが、まさに、SQL Integrated Storageはそれを実現します。
使用パターンに基づいて、各データベースはベースラインと、割り当てられた重要なリソースの予約を受け取り、これらのリソースを必要なときにデータベースで使用できるようにします。このプロセスは自動QoSと呼ばれます。これまではQoSをネットワーク上で実行してきましたが、各データベースにQoSを設定できるようになりました。SQL Integrated Storageは、ワークロードベースラインに基づいて自動調整を行います。変更したい場合は、QoSを設定して、重要なワークロードのパフォーマンスを向上させたり、逆に優先度の低いワークロードの集中による影響を最小限に抑えたりできます。

第２回では、SQL Integrated Storageの可視化の側面と、何を確認できるのかについて詳しく見ていきます。さらに、SQL Serverデータベースのパフォーマンスと使用法についても今後解説していきたいと思います。

本ブログで紹介した内容はwebセミナーにてご紹介していますのでぜひご視聴ください。