リックに聞いてみよう

リック・エルハートは豊かな経歴を持ち、Tintri技術開発の伝道師であり、技術者でもあります。自身のコラムでITに共通した問題を取り上げ、Tintriのストレージを使った簡単な解決方法を伝授しています。さて、今回のお悩みは･･･。

プライベートなクラウドインフラで使用しているストレージやIOPSの使用量は、どのように測ればいいのでしょうか？

VMレベルでストレージのチャージ管理

皆さんがサービスプロバイダやプライベートなクラウドインフラを管理する立場にあれば、ストレージの使用量やそのストレージを得るために使われたIOPS値を基にレポートを作成したり、顧客への請求額を決定したりしたいと思うことでしょう。そのような時に『Tintri VMstore』を使うと、仮想マシン（VM）レベルでこれらの使用量の集計値をユーザインタフェース（UI）の中だけでなく、アプリケーションプログラミングインターフェース（API）を通しても確認できてしまうのです。この方法であれば、ストレージの使用量に応じたVMごとの顧客への直接の請求額を簡単に導き出すのです。

1日単位？時間単位？

使い方としては、1日一回の決められた時間に測定する方法がひとつ。日々の平均値から日ごとの請求額まで、サービスプロバイダが採用したい集計方法を選ぶことができるので、毎日の数値データを「見える化」できます。

もう一つは、時間単位で請求額を算出する方法です。『Tintri API』を使い、1時間単位で計測するか、1日の終わりにその日の数値を集計する方法です。

データの測定と保存も

現状モデルの「VMstore」には、過去の数値とリアルタイムの数値のそれぞれに対応する2つのタイプの集計方法があります。過去の数値を集計する場合は10分単位で計測し、過去7日間分の集計値が蓄積され、『Tintri Global Center (TGC)』であれば、過去30日間の計測データが保存されます。リアルタイムの数値を集計する場合は、設定時間によって最小10秒単位で計測しますが、VMstore以外では対応していません。

VMの使用量を集計する方法は、以下のように3通りあります。

1. /v310/vm/{vmId}/statsHistoric: 計測する開始時間と終了時間を設定可能
2. /v310/vm/{vmId/statsRealtime: リアルタイムの設定時間を一回設定
3. /v310/vm: 呼び出し可能な直近の集計値を報告

上記3つの方法の場合、使用するデータトランスファーオブジェクト（DTO）はどれも同じです。では、集計した内容を確認してみましょう。

• spaceUsedLiveGiB: VMのデータ、ハイパーバイザーのスナップショット、ディスクの拡張ファイルと交換ファイルのために使われる論理スペース
• spaceUsedGib: 上記のspaceUsedLiveGiBとTintriのスナップショットによって使われる論理スペース
• operationsTotalIops: 秒単位のI/O合計数
• normalizedToalIops: 8キビバイトのブロックに標準化された秒単位のI/O合計数
• latencyTotalMs: ホストコンピュータ、ネットワーク、ストレージで起こるレイテンシと、スロットルレイテンシの総数。ストレージのレイテンシは、コンテンション方式、フラッシュ環境、ディスク上のレイテンシで構成

実際にはどうすればいいの？

APIの事例を「Tintri GitHub」にアップロードしておきました。「Tintri GitHub」 は、’/v310/vm’ を使う、ある一つの定点の傾向値を集計するのに便利です。1時間単位や1日単位の数値を計測することもできます。例として挙げている全体のフローは、すべてのVM情報を集計し、見たい集計値を表示させる方法です。『TGC』と「VMstore」の両方を対象にしても働く機能です。

コード・スニペットを見てみよう

この事例の作成に際しては、「Tintri’s GitHub」の サイトで入手可能なtintri、 json、 sys、 そして prettytableのモジュールを使用しました。最適な報告値が表示され、VMに関する情報をすべて網羅しています。下記に記したコードは、VM情報を集計するためのページ割りの例です。ここでクエリパラメータは起動中のVMだけに反映するように初期化されていて、「オフセット　ゼロ(offset 0) 」で始まり、必要に応じてページの大きさを設定するようになっています。

def get_vms(session_id) :

page_size = 25 # default

# dictionary of VM objects
vms = {}

# Get a list of VMs a page size at a time
get_vm_url ="/v310/vm"
count = 1
vm_paginated_result = {'live' : "TRUE",
'next' : "offset=0&limit=" + str(page_size)}

  # While there are more VMs, go get them
while 'next' in vm_paginated_result:
url = get_vm_url + "?" + vm_paginated_result['next']
print_debug(Next GET VM URL: " + str(count) + ": " + url)

# Invoke the API
r = tintri.api_get(server_name, url, session_id)

この場合のコード・スニペットでは、循環させる指示のためにAPIの ‘next’ のプロパティを使用します。処理するVMが複数台ある場合には、’/v310/vm’ のAPIの’next’ のプロパティを記載します。この’next’のプロパティは、APIを呼び出すためのURLの一部のように使われます。ページやVMは、この際関係なく、’next’ のほうが優先されるのです。

後々の検索が可能になるように、その後のループ循環の中で計測値が集計・保存されます。”vm_stats =” の行に注目してほしいのですが、計測値を集計する際には’sortedStats’ が専用リストなので、 ‘[0]’ を使わなければなりません。’sortedStats’の リストの中には一つのアイテムのみが記載されています。

# Get and store the VM items and save in a VM object.
items = vm_paginated_result["items"]
for vm in items:
vm_name = vm["vmware"]["name"]
vm_uuid = vm["uuid"]["uuid"]
vm_stats = VmStat(vm_name, vm_uuid, vm["stat"]["sortedStats"][0])
print_debug(str(count) + ": " + vm_name + ", " + vm_uuid)
count += 1

# Store the VM stats object keyed by VM name.
vms[vm_name] = vm_stats

残りのコードについては、VMが名前で記載され、関連した計測値とともに作表されています。

stat_fields = ['spaceUsedGiB', 'operationsTotalIops', 'latencyTotalMs']

上記の式は、表示される集計範囲を決定するものです。範囲の名前はVirtualMachineStat DTO にあり、API資料にもあります。

報告過程でデータベースを統合するのであれば、VM名で顧客のデータベースを保存できますし、あるいはVM名が顧客を特定します。また、ハイパーバイザーがVMにタグ付けすると、VMタグによって顧客へのタグ付けが行われます。

どうですか？ちょっとした探索ゲームになりそうでしょ！楽しんでください。