4 返信 最新の返信: Feb 27, 2018 11:59 PM by hirach RSS

UnityのBlockのプール空き容量と予約済み容量の関係

hirach

Unityのブロックのプール空き容量の考え方について、以下の図を参考に、3点確認させてください。

図で「プールの予約済みでない容量」を「のこり」として表現しています。

例)プールサイズ:300TB

  プール画面で見たときののこり容量:60TB

  ブロック画面で計算したのこり容量:65TB

20180223-02.png

 

①予約済み容量がプール合計を超えないようにしたいのですが、のこりの容量を考慮するためには、

 プール画面で確認できるプールの予約済みでない容量(全体-予約済み%)と、

 ブロック画面で確認できるプールの予約済みでない容量(全体-LUNサイズ合計)が異なる場合、

 プール画面の方(図の上段)を「プールの予約済みでない容量」と考えるのが良いでしょうか。

 

②この①で生じる差分(図の例では5TB)は、プール作成やLUN作成に伴って発生する

 「システムの管理領域」的に動的に確保されるものでしょうか。

 また、LUNのサイズや数量などから、あらかじめこの差分を計算することは可能でしょうか。

 

③FAST VPなど効果的に動作するために「プール全体の10%の空き容量」を確保しておく

 必要があると理解していますが、この「空き容量」は、プール画面の方(図の上段)の

 「のこり枠」がプール全体の10%以上である必要がある、と考えるのが良いでしょうか。

 それとも、図の「使用済み%」をプール全体から引いた容量が、全体の10%以上であればOKでしょうか。

  • 1. Re: UnityのBlockのプール空き容量と予約済み容量の関係
    Uehara Y.

    ①予約済み容量がプール合計を超えないようにしたいのですが、のこりの容量を考慮するためには、

     プール画面で確認できるプールの予約済みでない容量(全体-予約済み%)と、

     ブロック画面で確認できるプールの予約済みでない容量(全体-LUNサイズ合計)が異なる場合、

     プール画面の方(図の上段)を「プールの予約済みでない容量」と考えるのが良いでしょうか。

    はい。プール画面の方を利用してください。

    ②この①で生じる差分(図の例では5TB)は、プール作成やLUN作成に伴って発生する

     「システムの管理領域」的に動的に確保されるものでしょうか。

     また、LUNのサイズや数量などから、あらかじめこの差分を計算することは可能でしょうか。

    ご想像の通り、システムの管理に利用される領域です。具体的にはLUNを構成している256MBのスライス群をプールのどこから持ってきているのかを記録する、Meta情報用に利用されています。

     

    このMeta情報の(おおよその)計算方法についてはKB306546 - VNX: What is the difference between Thick LUNs and Thin LUNs ?に記載があるように以下の通りです。

     

    Thick LUN:MetaData (GB) =  .001* capacity (GB) + 3 GB

    Thin  LUN:MetaData (GB)  = .02* capacity (GB) + 3 GB

     

    ③FAST VPなど効果的に動作するために「プール全体の10%の空き容量」を確保しておく

     必要があると理解していますが、この「空き容量」は、プール画面の方(図の上段)の

     「のこり枠」がプール全体の10%以上である必要がある、と考えるのが良いでしょうか。

     それとも、図の「使用済み%」をプール全体から引いた容量が、全体の10%以上であればOKでしょうか。

    「使用済み%」をプール全体から引いた容量が、全体の10%以上であればOKです。

  • 2. Re: UnityのBlockのプール空き容量と予約済み容量の関係
    hirach

    Uehara Y.さん、返信ありがとうございます。

    Unityのプール空き容量とシステム管理領域についてよく分かりました。

    一点確認させてください。

    参考にリンクを張っていただいた情報は、2016年2月時点で対象装置がCX4、VNX、VNXeと記載されていますが、

    Unityもこの記事の計算式で対応できると考えて良いでしょうか?

    もし可否判断できる理由がありましたら(VNXe≒Unityとか…)、今後の参考のためにぜひ教えてください。

  • 3. Re: UnityのBlockのプール空き容量と予約済み容量の関係
    Uehara Y.

    hirachさん

     

    対象装置にVNX, VNXe Seriesが入っているので、VNX2やVNXe2が利用しているMCxの仕組みにも適用できることがわかります。

    UnityもMCxの仕組みを利用しているために、記事の計算式はUnityにも適用できると考えられます。

     

    個人的に少し気になる点としては、VNX1のFlareと呼ばれていた時代にはPool LUNに利用されていた最小単位のスライスが1GBだったものが、MCxになって256MBと1/4のサイズになったので、それらを管理しているMeta情報が少しだけ増えそうな気がするのですが、特にそのような記述や情報公開はされていません(誤差なのか関係ないのか・・・)。

  • 4. Re: UnityのBlockのプール空き容量と予約済み容量の関係
    hirach

    MCxの仕組みに関する動作の話なので、同じベースで動くUnityも該当すると考えられるわけですね。

     

    スライスが小さい単位になったことで単純計算だと4倍のメタデータ格納場所が必要になりそうですが、

    元々メタ情報の場所に余裕があったり、データの持ち方を効率化していたり、何か4倍にならない工夫があるといいですね…。