Posts Azure NetApp Files の監視について
Post
Cancel

Azure NetApp Files の監視について

ストレージの監視運用において、容量、性能、操作履歴はよく検討される監視項目となります。

Azure NetApp Files は Azure基盤と完全に統合しているため、他のAzureサービスと同様に、Azure Monitorを利用して簡単監視することができます。

本記事は、 Azure NetApp Files では一般的に監視される項目について解説していきます。

1. サービス正常性監視

Azure NetApp files は Azure の他のサービスと同様に、Azure Monitor の 「サービス正常性」ページにて ANF リソースの正常性状態(障害、メンテナンスなど)を確認できます。

また、正常性アラートを利用して、正常性問題の通知を行うことも可能です。

2. 容量監視

2021年5月までには、ボリュームのクオータサイズはソフトクオータであり、ボリュームの空き容量がなくとしても、ボリュームそして容量プールが自動的に成長する仕組みとなっていました。

5月から、ボリュームのクオータはハードクオータに変わり、ボリュームの空き容量がなくなったら、通常のハードディスクと同様に、書き込みができなくなります。

容量が足りないことによるシステム停止を防ぐため、容量が監視は非常に重要だと考えられます。

監視すべきメトリックは以下にご紹介します。

3.1 ボリューム容量監視

ボリュームのポータルにて以下のメトリックでそのボリュームの使用済み容量を監視できます。 「Volume Consumed Size」

もし「Volume Consumed Size」 がボリュームのクオータに近づいているようでしたら、ボリュームサイズを調整することを検討したほうがいいです。
またこのメトリックのアラート設定を推奨します。

3.2 容量プール容量監視

容量プールのポータルにて以下のメトリックでその容量プールの使用済み容量を監視できます。
「Pool Consumed size」

3.3 スナップショット容量監視

作成されたスナップショットはボリューム内部で保管され、スナップショットが使用した容量は以下のメトリックで監視できます。 「Volume Snapshot Size」

■補足:スナップショットの容量について
スナップショットはボリューム内で格納されますので、ボリューム容量の見積もりはスナップショットの容量も加味して容量を見積もる必要があります。

「~snapshot」または「.snapshot」からスナップショットにボリューム中のファイルの完全コピーが入っているように見えますが、ANFのスナップショットは完全差分式となり、データのフルバックアップを行いません。

スナップショットが作成された後にボリューム内のファイルが変更、更新された分だけはスナップショットに保存されます。

変更、更新がなければ、スナップショットがほとんどボリュームの容量を使わない想定です。

「~snapshot」または「.snapshot」にあるオブジェクトは、利用者が便利にスナップショットを取った時点のボリュームの状態を参照するためのファイルリンクになります。

もしボリュームの空き容量がなくなったら、スナップショットの作成、またはボリュームへの書き込みができなくなります。

ボリューム内のデータはどれぐらい更新されるのは、実際の使用状況に依存しているため、スナップショットに必要な容量を精確に推測するのが難しいです。

10~20%などエイヤーでスナップショットの容量を見積って、運用時に、ボリュームの使用容量を監視し、容量が足りなくなるまえに、ボリュームサイズを調整するのが一般的です。

4. 性能監視

Azure NetApp Files はボリュームごとに、QoS機能でボリュームのトータルスループットを制限していて、ボリュームの性能が頭打ちになっているかは以下のボリュームメトリックで確認できます。 「Total throughput」

もし「Total throughput」がボリュームのスループット上限値(ボリュームのポータルで確認可能)になっていれば、ボリュームの性能が頭打ちになり、ボリュームサイズを大きくするか(自動QoS)またはより多くのスループットをボリュームに割り振る(手動QoS)ような操作で対処できます。

また、ボリュームでは以下の性能メトリックも提供しています。
「Read throughput」
「Write throughput」
「Average Read Latency」
「Average Write Latency」
「Read IOPS」
「Write IOPS」

5. スナップショットショット作成失敗監視

5.1 手動でスナップショットを作成する場合

手動で作成する場合は、スナップショット作成用のRest APIが呼び出されます。 この場合、Write snapshot resourceというアクティビティログに記録されますので、アクティビティのログの実行結果をアラートで監視することで、作成失敗イベントを検出できると考えられます。

5.2 スナップショットポリシーでスナップショットを作成する場合

スナップショットはサービス側で実施して、作成が失敗した場合はポータルで通知しません。
スナップショット作成失敗の主な原因は容量不足であり、ボリュームの容量監視を実施していれば、基本的にスナップショットの作成失敗を避けられると考えられます。

6. 操作履歴監視

ボリューム、容量プールの作成、削除、設定変更操作は全部「アクティビティログ」にて記録され、もしリースが想定外の設定値になっていれば、遡って操作履歴を確認できます。

7. 参考情報URL

Azure NetApp Files のメトリック
アクティビティ ログ アラート

※リンク先などを含む本情報の内容は、作成日時点でのものであり、予告なく変更される場合がございますので、ご了承ください。

This post is licensed under CC BY 4.0 by the author.

Microsoft SQL on Azure NetApp Files の性能考慮事項

Azure NetApp Filesのデータ保護機能(スナップショット編)