このページでは、Google Cloud NetApp Volumes のボリューム機能の概要について説明します。
ボリュームについて
ボリュームは、アプリケーション、データベース、ユーザーデータを保存するストレージ プール内のファイル システム コンテナです。
ストレージ プールで使用可能な容量を使用してボリュームの容量を作成し、プロセスを中断することなく容量を定義してサイズを変更できます。
ストレージ プールの設定は、その中に含まれるボリュームに自動的に適用されます。これらの設定には、サービスレベル、ロケーション、ネットワーク（Virtual Private Cloud（VPC））、Active Directory ポリシー、LDAP、顧客管理の暗号鍵（CMEK）ポリシーが含まれます。
ボリュームの性能
フレキシブル ストレージ プール: ボリュームのパフォーマンスは、ストレージ プールのサイズと機能によって異なります。プールのパフォーマンスは、プール内のすべてのボリュームで共有されます。
標準ストレージ プール: ボリュームのパフォーマンスは、ボリュームサイズと、プールから継承するサービスレベルによって定義されます。ボリューム サイズを増減してパフォーマンスを最適化できます。
Premium ストレージ プールと Extreme ストレージ プール: ボリュームのパフォーマンスは、ボリューム サイズと、プールから継承するサービスレベルによって定義されます。ボリューム サイズは、パフォーマンスを最適化するために増減できます。また、Premium プールと Extreme プール間でボリュームを中断することなく移動して、パフォーマンスを最適化できます。
スペースのプロビジョニング
データを保持するのに十分な容量をボリュームにプロビジョニングし、空き容量を成長のためのバッファとして残しておく必要があります。
ボリュームがいっぱいになると、クライアントがデータを変更または追加しようとすると out of space エラーが発生し、アプリケーションやユーザーに問題が発生する可能性があります。ボリュームの使用状況をモニタリングし、想定されるボリューム使用率の 20% を超えるプロビジョニング済みスペース バッファを維持する必要があります。使用状況のモニタリングについては、NetApp Volumes をモニタリングするをご覧ください。
スナップショットはボリュームの容量を使用します。詳細については、スナップショットの使用容量をご覧ください。
ボリュームのユーザーとグループの割り当て
NetApp ボリュームのユーザー割り当てとグループ割り当てを使用すると、特定のユーザーまたはグループが使用するボリューム容量を制限できます。これは、Google Cloud の割り当てとシステムの上限とは異なります。ユーザーとグループの割り当ては、NetApp Volumes ボリュームに直接設定します。
個々の Windows ユーザーまたは Unix ユーザー、または Unix グループに割り当てることができますが、Windows グループには割り当てられません。割り当ては、名前ではなく、ユーザーまたはグループの特定のユーザー ID（UID）、セキュリティ識別子（SID）、グループ ID（GID）を対象とします。
割り当ては、ユーザーの使用量に応じてストレージを割り当てるのではなく、使用量を制限することを目的としています。割り当て上限は、ユーザーの割り当てからグループの割り当てまで順番にチェックされます。割り当て上限に達すると、書き込みはブロックされます。グループ割り当ては、グループ内のすべてのユーザーが共有します。割り当てルールの管理方法については、割り当てルールを管理するをご覧ください。
たとえば、人事、財務、管理の 3 つのグループが 10 TiB のボリュームを共有します。デフォルトのグループ割り当ては 500 GiB で、人事グループと管理グループのユーザーに制限が適用されます。財務グループのグループ割り当ては 10 TiB です。デフォルトのユーザー割り当ては 1 TiB です。財務部門の Sasha ユーザーと管理部門の Alex ユーザーには、5 TiB の個別のユーザー割り当てが割り当てられています。特定のユーザーの有効な割り当ての例を次に示します。
人事部の Kim ユーザー、管理部の Taylor ユーザー、Alex ユーザーは、500 GiB のグループ割り当てに制限されています。Alex の 5 TiB のユーザー割り当ては、グループ割り当てによって実質的にオーバーライドされます。
財務部門のユーザー Sasha は、ユーザー割り当てによって 5 TiB に制限されています。
財務部門のユーザー Lee は、ユーザー割り当てにより 1 TiB に制限されています。
財務部門のユーザーの割り当ては 5 TiB を超えないため、1 人で 10 TiB のグループ割り当てまで保存することはできません。
割り当て上限を超えて書き込もうとすると、エラーが発生します。ユーザーの割り当て使用量と上限は、Windows エクスプローラまたは Linux 割り当てコマンドでユーザーに表示されます。グループ割り当ての使用量と上限は、rquota v2 互換のクライアントを使用している場合にのみ表示されます。
割り当てルールには次の 4 種類があります。
個々のユーザーの割り当て: Linux UID または Windows SID を使用する明示的なユーザーに適用されます。
個々のグループの割り当て: Windows をサポートしていない Linux GID を使用する明示的なグループに適用されます。
デフォルトのユーザー割り当て: 個別の割り当てルールがないすべてのユーザーに適用されます。
グループのデフォルトの割り当て: 個別の割り当てルールのないすべてのグループに適用されます。
ボリュームの復元
NetApp Volumes を使用すると、ボリュームを以前に作成したスナップショットに戻すことができます。ボリュームを元に戻すと、すべてのボリューム コンテンツがスナップショットが作成された時点に戻ります。元に戻すために使用されたスナップショットの後に作成されたスナップショットはすべて失われます。データを失わない場合は、ボリュームのクローンを作成するか、スナップショットでデータを復元することをおすすめします。
ボリュームの復元を使用して、アプリケーションのテストとアップグレード、またはランサムウェア攻撃の防御を行うことができます。このプロセスは、バックアップでボリュームを上書きするプロセスに似ていますが、数秒しかかかりません。ボリュームの容量に関係なく、ボリュームをスナップショットに戻すことができます。
復元は、ボリュームがオンラインでクライアントによって使用されている場合に行われます。元に戻す前に、重要なアプリケーションをすべて停止することをおすすめします。元に戻すと、アプリケーションに通知せずに開いているファイルが変更されるため、データが破損する可能性があります。
クライアントの接続時にボリュームの削除をブロックする
NetApp Volumes では、クライアントによってマウントされたボリュームの削除をブロックできます。Google Cloud VMware Engine（GCVE）データストアでボリュームを使用する場合は、クライアントがボリュームをマウントしているときにボリュームの削除をブロックするように設定を有効にする必要があります。[クライアントの接続時にボリュームの削除をブロックする] 設定を有効にすると、マウントされたボリュームを削除しようとするとエラー メッセージが表示されます。
ボリュームは、ボリュームの作成、スナップショットからの新しいボリュームの作成、バックアップからの新しいボリュームの作成時に、ボリュームの削除をブロックできます。
次のプロトコルは、ボリュームの削除のブロックをサポートしています。
NFSv3
NFSV4.1
NFSv3 と NFSv4.1
このオプションが有効になっているときにボリュームを削除するには、まずすべてのクライアントでボリュームをマウント解除する必要があります。その後、ボリュームを削除するには 52 時間以上待つ必要があります。
大容量ボリューム
Premium と Extreme のサービスレベルでは、ボリュームサイズは 100 GiB ～ 102,400 GiB の範囲で、最大スループットは 4.5 GiBps です。一部のワークロードでは、より大きなボリュームとより高いスループットが求められます。これは、Premium と Extreme のサービスレベルで大容量ボリューム オプションを使用すると実現できます。
大容量ボリュームのサイズは、1 GiB 単位で 15 TiB ～ 1 PiB の範囲で指定でき、最大 30 GiBps のスループット パフォーマンスを提供できます。
大容量ボリュームには 6 つのストレージ エンドポイント（IP アドレス）があり、クライアント トラフィックをボリュームにロードバランスしてパフォーマンスを向上させることができます。6 つの IP アドレスにより、このようなボリュームは、同じデータへの高パフォーマンスで高度な同時アクセスを必要とするワークロードに最適です。クライアントを接続する方法の推奨事項については、複数のストレージ エンドポイントを使用して大容量ボリュームを接続するをご覧ください。作成後にボリュームを大容量ボリュームに変換したり、その逆を行ったりすることはできません。
大容量ボリュームの制限事項
大容量ボリュームには次の制限が適用されます。
大容量のボリュームには、専用の Service プロジェクトを使用する必要があります。
ボリュームのレプリケーションはサポートされていません。
ボリュームのバックアップはサポートされていません。
ボリュームを保持するストレージ プールには、ロケーションベースの割り当てが適用されます。容量が不足している場合は、ロケーションあたりのストレージ プールの容量（GiB）の割り当ての増加をリクエストします。詳細については、NetApp Volumes の割り当てをご覧ください。
自動階層化
Google Cloud NetApp Volumes では、ストレージ プールで自動階層化が有効になっている場合、ボリュームごとに自動階層化を有効にできます。自動階層化により、ボリューム使用の全体的な費用を削減できます。自動階層化の詳細については、プロダクトの概要をご覧ください。
ボリュームで自動階層化を有効にすると、必要に応じて自動階層化を一時停止して再開できます。ただし、自動階層化を有効にした後で無効にすることはできません。冷却しきい値はボリュームごとに調整することもできます。クーリングのしきい値は 7 ～ 183 日の範囲で設定できます。デフォルトのクールオフ期間は 31 日です。クーリングのしきい値を超えてクーリングされたデータは、1 日に 1 回コールド層に移動されます。
ボリューム管理者は、データを保持し、パフォーマンス目標を達成するのに十分な大きさのボリューム サイズを設定します。
クーリングのしきい値を過ぎると、使用頻度の低いデータは自動的にコールド層に移動されます。コールド層のデータ量はクエリできます。クエリを実行するには、階層化統計情報を検索するをご覧ください。ボリュームの容量からコールド層の容量を差し引いたものが、ボリュームのホット層になります。
課金はストレージ プール レベルで行われ、次の 2 つのコンポーネントが含まれます。
コールド ティアの料金
ホットティアの料金
プール内のすべてのボリュームのコールド層の合計サイズが合計され、コールド層の料金で課金されます。プールの残りの容量は、プールのホット ティアの料金で課金されます。ただし、プールのホットティアのサイズが 2 TiB 未満の場合、2 TiB はホットティアの料金で請求され、残りの容量はコールドティアの料金で請求されます。また、ストレージ プールのコールド ティアとの間でデータを移動する際にネットワーク トラフィックが発生し、その分も課金されます。料金の詳細については、ストレージ プールの料金をご覧ください。
自動階層化の考慮事項
自動階層化を使用する場合は、次の考慮事項が適用されます。
コールド層のデータの料金は、ホット層のデータよりも低く設定されています。短いクールダウンしきい値を使用すると、データをコールド層に早く移動できるため、データにすぐに再アクセスしない場合の全体的な費用を削減できます。
コールド層のデータへのアクセスは、ホット層のデータへのアクセスよりも遅くなります。クールダウンのしきい値が短すぎると、データへのアクセスが遅くなる可能性があります。
コールド ティアとの間でデータを移動すると、データ転送費用が発生します。短いクールダウンしきい値を選択すると、ホット ティアとコールド ティア間でデータがより頻繁に移動し、全体的な費用が増加する可能性があります。
ボリューム レプリケーションを使用する場合、自動階層化機能は、ソース ボリュームと宛先ボリュームに対して個別に制御されます。
自動階層ボリュームのパフォーマンスは、ホット ティアとコールド ティアのサイズによって異なります。ホットティアのサイズの 1 GiB ごとに、ボリュームに 64 KiBps（プレミアム）または 128 KiBps（エクストリーム）のスループット機能が追加されます。コールド ティアのサイズが 1 GiB 増えるごとに、ボリュームのスループット容量が 2 KiBps 増加します。
自動階層化が有効になっているストレージ プールでは、自動階層化が有効になっていない既存のボリュームでコールド ブロック トラッキングが発生することがあります。これらのボリュームで自動階層化を有効にすると、古いデータはすぐに階層化の対象になり、翌日にコールド ティアに移動される可能性があります。