新しいストレージ・ティア
日本語のDocsにはまだ記載が無いようですが、英文のDocsにはPowerVS の「Storage tiers」としてTier 0とFixed IOPSが追加されています。
Tier 0 は、25 IOPS/GB、Fixed IOPS はサイズにかかわらず 5000 IOPS の能力があります。
I/O インテンシブ の IBM i を特に少ないストレージ容量で利用する場合に有用でしょう。
| Tier level | IOPS |
|---|---|
| Tier 0 | 25 IOPS/GB |
| Tier 1 | 10 IOPS/GB |
| Tier 3 | 3 IOPS/GB |
| Fixed IOPS | サイズにかかわらず 5000 IOPS |
なお、Fixed IOPS のサイス上限は 200 GB です。これは Tier 0 の 200 GB と同じIOPSです(200 GB x 25 IOPS/GB = 5000 IOPS)。
200 GB以上のストレージで高い IOPS が必要な場合は Tier 0 をご利用ください。
もっとも、200 GB 以下の 複数の Fixed IOPS を同じ ASP に追加する方法でもより高い IOPS を利用することもできます。
現在 英文 Docs には OSA21 で利用可能であることの記載はありますが TOK04 の言及がありません。これは Docs の更新が遅れているだけで OSA21 と同様に TOK04 でも利用可能になっています。
Boot ボリュームとして利用可能
これまでの Tier 1 / Tier 3 と同様にBoot ボリュームとして利用可能です。
自分のアカウントのブート・イメージに取り込まれた IBM Stock イメージ は「層:任意」「ストレージ・プール:任意」と表示されていました。
昨年 3 月の時点では、層は最初にそのイメージから起動したインスタンスのもの、ストレージ・プールも特定のものが表示されていました。
パフォーマンステスト
Tier の違いが実際のパフォーマンスにどのように影響するかをテストしてみます。
IBM Stock イメージから払い出した 100 GB の Boot ボリュームのみのインスタンスを各 Tier で用意します。
今回は TOK04 に S922、CPU 0.25 コア、メモリー 2 GiB という最小構成で用意しました。
起動後、確認すると 100 GB(実質 95.4GB) の容量で構成され、半分以上が使用済みです。
ここに 40 GB の書き込みを行います。
方法は CRTPF で レコード長 25,000 バイト、レコード数 1,600,000 の物理ファイルを作成します。
25,000 x 1,600,000 = 40,000,000,000 ですね。
ALLOCATE(*YES) で作成すると、実際にその領域がストレージ上に展開されます。
具体的なコマンドは、このようになります。
CRTPF FILE(QGPL/P1) RCDLEN(25000) SIZE(1600000) ALLOCATE(*YES)
これを、SBMJOB でバッチ実行してジョブログから時間を確認します。
SBMJOB CMD(CRTPF FILE(QGPL/P1) RCDLEN(25000) SIZE(1600000) ALLOCATE(*YES)) LOG(4 0 *SECLVL) LOGCLPGM(*YES) LOGOUTPUT(*JOBEND)
実行後、システム利用率が 93% を超えています。
約 40GB の物理ファイルが作成されています。
ジョブログで、CRTPF の開示要求時刻から、メンバーの追加が完了するまでの時間を確認します。
結果は、下記のとおりです。
Tier 3を 1 にした IOPS 比と処理性能比(Tier 3の何倍速く処理できたか)も計算してみました。論理上の IOPS より多少良い結果が出ました。
| 容量(GB) | IOPS/GB | IOPS | IOPS比 | 処理時間(秒) | 処理性能比 | |
|---|---|---|---|---|---|---|
| Tier 0 | 100 | 25 | 2500 | 8.33 | 17.334664 | 8.91 |
| Tier 1 | 100 | 10 | 1000 | 3.33 | 45.289091 | 3.41 |
| Tier 3 | 100 | 3 | 300 | 1.00 | 154.463180 | 1.00 |
| Fixed | 100 | N/A | 5000 | 16.67 | 8.205620 | 18.82 |
後から Tier の変更が可能
作成したストレージ・ボリュームは、後から Tier の変更が可能です。
一つ目はストレージ・ボリュームの「編集」から変更する方法です。
もう一つは仮想サーバー・インスタンスの詳細で接続されているボリュームのリンクをクリックし、編集する方法です。
IBM i の稼働中に Tier 1 に変更してみました。
メッセージが表示され、一瞬、ブート可能が「オフ」になりました。
その後、直ぐにブート可能が「オン」になりました。
コンソールでの操作の中断はなく、QSYSOPR にも特別なメッセージは出ていません。
新しい Tier モデルではストレージ・プールが共通
どうして、このような変更が停止せずにできるのでしょうか?
以前から、PowerVS をご利用されている方は Tier 1 は NVMe が Tier 3 は SSD が使われていて、全く異なるストレージ・プールだと聞かれたことがあるかもしれません。
しかし、今回デプロイした4つのインスタンスは、同一のストレージ・プールを使っています。
単に、IOPS の制限値を変更するだけで Tier を切り替えているようです。
Boot イメージと Tier
ユーザー作成の Boot イメージの Tier は変更できない
Tier 1 のインスタンスから Boot イメージをエクスポートしました。Tier 共通のストレージ・プールにエクスポートされましたが、Tier の変更はできませんでした。
ユーザー作成の Boot イメージでも別 Tier のインスタンスのデプロイが可能
以前、自分のイメージからインスタンスを作成した時は、イメージの Tier でしかデプロイできず、異なるストレージ・タイプのインスタンスを作成したい場合は、いったん ICOS にエクスポートし、ICOS から 再度インポートする時に、希望するストレージ・タイプを指定して対応していました。
今回の共通Tierストレージプールの場合、別のTierにデプロイする事も可能になっていました。
イメージの課金を削減するために
仮想サーバーのキャプチャー・エクスポート先として ICOS を指定するのが、一番安価なのですがイメージカタログに置きながらできるだけ安くしたいという場合もあるかもしれません。
この場合、下記のような手順を実行するとイメージへの課金を削減できると思います。
- インスタンスのストレージボリュームの Tier を
Tier 3に変更する - キャプチャー・エクスポートを実行する
- ストレージボリュームの Tier を元に戻す
当日記のIndexはこちらです。
許可の無い転載を禁じます。
この記事は筆者の個人的な責任で無保証で提供しています。
当記事に関してIBMやビジネスパートナーに問い合わせることは、固くお断りします。