本ブログエントリーはPernixData社のテクノロジーエバンジェリストであるFrank Denneman氏のブログの翻訳版です。
本記事の原文はStorage I/O requirements of SAP HANA on vSphere 5.5で閲覧可能です。
ネットワールドのPernixDataに関する情報はこちら。
VMworld開催期間中、vSphere 5.5上で動作するSAP HANAが本稼働環境でサポートされたことが大きく注目を集めました。SAP HANAはリアルタイム解析、リアルタイムアプリケーションの動作を実現するインメモリデータベースプラットフォームです。
｢Best practices and recommendations for Scale-Up Deployments of SAP HANA on VMware vSphere｣というホワイトペーパー内で、VMwareはvMotion, DRSそしてHAを仮想化したSAP HANAシステムでサポートすることを謳っています。これは素晴らしいことで、心震わされます。このようなデータベースプラットフォームを仮想化して動作させられるということは非常に大きなことです。仮想化インフラストラクチャによって提供されるモビリティや隔離によるメリットをついに利用することができるようになったということで、馬鹿げた、維持管理にコストとサポートに苦痛が伴う物理の構成を気にしなくても良くなったのです。
SAP HANAのプラットフォームの奥深く踏み入っていくと、SAP HANAはインメモリデータベースプラットフォームであるにもかかわらず、ディスクに書き込む必要があるということに気が付きます。ディスクに書き込むことでHANAはデータベースのACID保証することができるのです。ACIDはAtomicity(原子性、完全性), Consistency(一貫性), Isolation(隔離), Durability(永続性)の略で、データベースのトランザクションがしっかりと処理されることを保証する属性のことです。
脇道にそれますが、SAP HANAのサポートのリリースに触発されて、データベースの構造とアーキテクチャの奥深くを知ろうとしたのですが、ありがたいことに我々の製品Directorは驚くほどのDB設計の経験を持っていました。私は彼と2～3時間話をしてこれについて教えてもらいました。この情報についてはショートシリーズとしてすぐに共有します。さて、本題へ戻ろう。
｢SAP HANA – Storage Requirements｣というドキュメントがsaphana.com上で公開されています。これはこのプラットフォームについてのストレージI/Oの振る舞いの詳細に迫るものです。4ページ目に以下の記述があります : SAP HANAはストレージを様々な目的で利用します :
データ : SAP HANAはセーブポイントブロックと呼ばれる変更データを空き領域に書き込むことで、インメモリデータのコピーを永続化します。その際のI/O操作はデータの利用の状況や、空きブロックの数などで変動しますが、4 KBから16MB(スーパーブロックを考慮すると最大64MB)になります。各々のSAP HANAサービス(プロセス)が自身のセーブポイントファイルを別々に書き込みます。これは標準では5分おきに行われます。
Redo ログ : 障害時にデータを失わず、復元できることを保証するために、SAP HANAは一つ一つのトランザクションをredo ログエントリと呼ばれる形状で記録します。各々のSAP HANAサービスがそれぞれ自身のredoログ・ファイルを別々に書き込みます。一般的には書き込みのブロックサイズは4 KBから1MBの幅です。
ということなので、様々なブロックサイズの処理を高速に処理できる高速なストレージを使うことは理にかなっています。つまり、レイテンシが低く、高いスループットということで、サーバサイドのリソースから簡単に提供可能なものです。
saphana.com で公開されている ｢SAP HANA Guidelines for being virtualized with VMware vSphere｣というドキュメントの 4.5.3章にはストレージ要件も記載されています :
SAPとVMwareは以下のvSphere上で仮想化したSAP HANAのためのベストプラクティスに記載されたVMwareのストレージの技術的な構成を推奨します。特に利用可能な場合、SAP HANAのログ格納のために作成された仮想ディスクはローカルSSDもしくはPCIアダプターのフラッシュを利用してください。メインのエンタープライズストレージはSAP HANAをデータセンタへ統合するアプローチにおいて利用されます。
これは非常に面白い事実です。SAPはフラッシュの利用を推奨しています。ストレージプラットフォームが遅い時に、このようなインメモリのプラットフォームを動作させることを考えれば、これは理にかなっています。ローカルフラッシュストレージを利用する場合には、仮想化インフラストラクチャ内に固定的な(vMotionできない)ワークロードが作成されてしまいます。SAP HANAは拡張vMotionをサポートし、2つのホストと2つのデータストアを同時に移行します、しかし書き込みが非常に多いタイミングではDRSはロードバランス操作を行うために拡張vMotionを活用してはくれません。これは結果として自動ロードバランス機能を失うことと、vSphere High Availability(HA)によって仮想マシンが復旧できる可能性を減らすことにもなりえます。
柔軟性にかけるサイロ化されたアーキテクチャを利用するのではなく、PernixData FVPを利用するのがよいでしょう。FVPはVMwareの力を借り、フラッシュと(もうすぐ)メモリのクラスタ化と耐障害機能付きのI/O高速化を実現します。これらの高速化リソースを仮想化し、1つの一元化されたプールへと変えるのです。仮想マシンはシームレスにクラスタ内のあらゆるホストに移行ができる上に、データはクラスタ内のどこからでもアクセスすることが可能です。
SAP HANAはメモリにデータを置くことで操作を高速化する一方、FVPは利用可能な高速化リソースを用いて書き込みを高速化します。vSphere 5.5ではSAP HANAは仮想マシンの構成の最大値から1TBまでのメモリに制限されています。しかし、vSphere 5.5はホストに最大4TBまでのメモリ構成をサポートしています。もうすぐリリースされるFVP 2.0がメモリをサポートすることにより、FVPは残ったメモリを書き込みの高速化にも利用ができるようにし、完全なインメモリプラットフォームを実現します。
記事担当者: マーケティング本部 三好哲生 (@pernixdata_netw)
