このページでは、Google Cloud NetApp ボリュームの機能の概要について説明します。
ネットワーク接続ストレージ
NetApp Volumes は、ファイル システム（ボリューム）をネットワーク接続ストレージ（NAS）クライアントと共有します。NAS クライアントは通常、業界標準の Network File System（NFS）プロトコルと Server Message Block（SMB）プロトコルを使用して Windows または Linux オペレーティング システムで実行される仮想マシン（VM）です。
クライアント サーバー モデル
NFS と SMB の両方がクライアント サーバー モデルを使用します。このモデルでは、クライアントがサーバーにリクエストを送信してファイル システムに対して操作を行います。サーバーは、ファイルやフォルダの作成や削除、ファイルの変更、ファイルのブラウジングと読み取りなどのオペレーションを実行します。
ファイル システムは、多くのクライアントが共有できるボリュームに埋め込まれています。通常、Windows、Linux、UNIX オペレーティング システムには、SMB クライアント ソフトウェアと NFS クライアント ソフトウェアが組み込まれています。
アクセス権限
すべてのファイル システム オブジェクトにはオーナーが必要ですが、他のユーザーやグループにオブジェクトのアクセス権を付与できます。
NFS の場合、所有権にはユーザー ID とグループ ID を指定します。これらは、標準の UNIX スタイルのユーザー権限とグループ権限を使用します。NFSv4.1 では、ユーザー ID とグループ ID またはセキュリティ プリンシパルを使用できます。Kerberos で NFSv4.1 を使用する場合、Kerberos プリンシパルの使用により、ユーザー ID アクセスが置き換えられ、ユーザー ID が認証されます。NFSv4.1 では、標準の UNIX 権限に加えて、アクセスを管理する代替方法として NFSv4.1 アクセス制御リストも提供されます。
SMB の場合、Windows セキュリティ識別子によって所有権が指定され、NTFS スタイルのアクセス制御リストを使用してオブジェクトへのアクセスが管理されます。
ストレージ プール
ストレージ プールは、ボリュームのコンテナとして機能します。ストレージ プール内のすべてのボリュームは、次の情報を共有します。
場所
サービスレベル
Virtual Private Cloud（VPC）ネットワーク
Active Directory ポリシー
NFS ボリュームでの LDAP の使用（該当する場合）
顧客管理の暗号鍵（CMEK）ポリシー
ゾーンまたはリージョン プールの可用性
プールの容量は分割して、プール内のボリュームに割り当てることができます。ストレージ プールは、NetApp Volumes の課金対象コンポーネントです。課金は、ボリューム レベルでの使用量に関係なく、プールに割り当てられたロケーション、サービスレベル、容量に基づいています。
Flex サービスレベルのストレージ プール
Flex Storage プールには、次の 2 つの可用性オプションがあります。
ゾーンプール: 単一ゾーン内の可用性を提供します。ただし、ゾーン全体が停止した場合、ゾーンプールのボリュームにはアクセスできなくなります。
リージョン プール: リージョン内の 2 つのゾーンにわたって可用性を提供します。ボリュームはプライマリ ゾーンとレプリカ ゾーン間で同期的に複製されるため、プライマリ ゾーンの停止中にデータにアクセスできます。ゾーンに障害が発生した場合、レプリカ ゾーンへのフェイルオーバーは自動的に行われます。フェイルバックまたはロード バランシングのために手動ゾーン切り替えを行うことができます。
Flex ストレージ プールには、次の 2 つのパフォーマンス オプションがあります。
デフォルトのパフォーマンス: ストレージ プール内のすべてのボリュームは、プールのパフォーマンスを共有します。Flex のデフォルト パフォーマンス ストレージ プールは、プール容量の TiB あたり 16 MiBps（最大 1.6 GiBps）のスループットと、プール容量の TiB あたり 1, 024 IOPS（最大 60,000 IOPS）の IOPS を提供します。
カスタム パフォーマンス（プレビュー版）: ストレージ プール内のすべてのボリュームがプールのパフォーマンスを共有します。Flex カスタム パフォーマンス ストレージ プールは、一部のリージョンのゾーン Flex プールで使用でき、容量、パフォーマンス、IOPS を個別にスケーリングできます。スループットは 64 MiBps ～最大 5 GiBps の範囲で 1 MiBps 単位でプロビジョニングできます。プロビジョニングされたスループットの 1 MiBps には 16 IOPS が含まれます。16 IOPS の含まれているスループットを超える追加の IOPS は、必要に応じて最大 160,000 IOPS までプロビジョニングできます。カスタム パフォーマンスは、一部の地域でのみサポートされています。利用可能なリージョンの詳細については、Flex カスタム パフォーマンスでサポートされているリージョンをご覧ください。
NetApp Volumes の可用性の詳細については、Google Cloud NetApp Volumes サービスレベル契約（SLA）をご覧ください。
ボリューム
ボリュームは、アプリケーション、データベース、ユーザーデータを保存するストレージ プール内のファイル システム コンテナです。
ストレージ プールで使用可能な容量を使用してボリュームの容量を作成できます。また、プロセスを中断することなく容量を定義してサイズを変更できます。
ストレージ プールの設定は、その中に含まれるボリュームに自動的に適用されます。
スナップショットとスナップショットベースのデータ管理
NetApp Volumes は、スナップショット機能を使用してデータ使用量を管理するのに役立ちます。これにより、追加のストレージ容量を必要とせずに、数秒でデータのスナップショットを取得できます。
NetApp Volumes スナップショットは、データの物理的なコピーではありません。代わりに、NetApp Volumes スナップショットは、前回のスナップショット以降に変更されたデータのみをキャプチャします。すべてのデータを上書きすると、スナップショットでボリューム容量が大幅に消費される可能性があります。
ボリューム レプリケーション
クロスロケーションのボリューム レプリケーションによってデータを保護できます。このレプリケーションでは、あるロケーションにあるソース ボリュームが別のロケーションにある宛先ボリュームに非同期で複製されます。この機能により、ロケーション全体のサービス停止や障害が発生した場合に、他のボリュームを重要なアプリケーション アクティビティに使用できるようになります。
ボリューム レプリケーションでは、最初の転送時に使用されたデータブロックのみが移動されます。その後の増分転送では、変更されたブロックのみが転送されます。転送されたバイト数に対してのみ料金が発生するため、転送時間が最適化され、費用を削減できます。
バックアップ
バックアップは、バックアップ ボルト内のボリュームとは別に保存されるボリュームのコピーです。ボリュームが使用できない場合や削除された場合は、バックアップを使用してデータを新しいボリュームに復元できます。NetApp Volumes は、手動とスケジュール設定されたボリューム バックアップをサポートしています。
ボリュームの最初のバックアップには、ボリュームのすべてのデータが含まれます。以降のバックアップでは増分変更のみがキャプチャされるため、永続増分バックアップを迅速に実行でき、バックアップ ボールト内の必要な容量を削減できます。
Active Directory のインテグレーション
SMB（CIFS）、拡張グループを使用した NFSv3、NFSv4.1 などのファイル共有プロトコルは、外部ディレクトリ サービスを使用して、セキュリティ プリンシパルを使用してユーザー ID 情報を提供します。NetApp Volumes は、ディレクトリ サービスに Active Directory を使用します。Active Directory は、次のオブジェクトを検索するための LDAP サーバーなどのサービスを提供します。
ユーザー
グループ
マシン アカウント
DNS サーバー（ホスト名の解決用）
Kerberos サーバー（認証用）
データ暗号化
NetApp Volumes は、ボリューム固有の鍵を使用して保存データを常に暗号化します。
顧客管理の暗号鍵（CMEK）を使用すると、Cloud Key Management Service に保存されている鍵を使用して、ボリューム固有の鍵がラップされます。この機能を使用すると、使用する暗号鍵をより細かく制御できます。また、鍵をシステムまたはデータとは異なる場所に保存することで、セキュリティを強化できます。NetApp Volumes は、ハードウェア セキュリティ モジュール、暗号鍵管理、生成、使用、ローテーション、破棄の完全な鍵管理ライフサイクルなど、Cloud Key Management Service の機能をサポートしています。
自動階層化
自動階層化により、ボリューム使用量の全体的な費用を削減できます。非アクティブなデータが大量にあるユーザーは、自動階層化を使用してストレージの総費用を削減できます。ボリュームに書き込まれた後、まったく使用されないか、ほとんど使用されないデータはコールドデータと呼ばれます。自動階層化はボリューム単位で有効にできます。ボリュームで自動階層化が有効になると、NetApp Volumes は使用頻度の低いデータを識別し、コールドデータをプライマリ ホット階層から、低価格で低速のコールド階層に透過的に移動します。アクティブなデータはホット ティアに残ります。自動階層化は、Premium または Extreme サービスレベルのボリュームでのみ有効にできます。
ユーザーは、すべてのデータを保持するのに適したサイズのボリュームを作成します。データがホット ティアまたはコールド ティアにあるかどうかにかかわらず、データはボリュームによって自動的に管理され、NFS または SMB を使用してボリュームにアクセスするアプリケーションまたはユーザーに対して透過的です。データセット全体はいつでも確認できます。ただし、ホット ティアからデータを読み取る場合とコールド ティアからデータを読み取る場合では、パフォーマンスが異なる場合があります。ホット層のデータは、階層化されていないボリュームと同じパフォーマンスを示します。コールド層のデータでは、読み取りレイテンシが高くなり、読み取りパフォーマンスが低下します。
NetApp Volumes は、アクセス パターンに基づいてコールドデータをホット階層に移動するかどうかを決定します。データのコピー、ファイルベースのバックアップ、インデックス作成、ウイルス対策スキャンに関連するものなど、順次読み取りでコールドデータを読み取ると、データはコールド ティアに残ります。ランダム読み取りでコールドデータを読み取ると、データはホット ティアに移動します。このデータは、再び冷却されるまでホット ティアに保持されます。
ホット ティアから非連続的にデータを定期的に読み取ると、データがコールド状態になるのがブロックされる可能性があります。これにより、データアクセス パターンによっては、ウイルス対策の完全スキャンやファイルベースの完全バックアップに影響する可能性があります。
ボリュームの移行
ボリューム移行機能を使用すると、SnapMirror ベースの移行を使用して、ONTAP ベースの Flex ボリュームを NetApp Volumes に移行できます。この移行では、ベースライン転送と増分転送を使用して、ワークロードを NetApp ボリュームに切り替えるために必要なダウンタイムを最小限に抑えます。この機能は、継続的なレプリケーションを目的としたものではありません。
Active Directory LDAP アクセス
NFS のユースケースでは、Active Directory を LDAP サーバーとして使用します。NetApp Volumes は、RFC2307bis スキーマを使用する ID データを想定しています。Active Directory にはすでにこのスキーマが用意されていますが、ユーザーとグループに必要な属性を必ず入力する必要があります。
NetApp Volumes は、次の属性をクエリして LDAP とやり取りします。
ユーザー名
数値の UNIX ユーザー（ユーザー ID）
グループ
NFS プロトコル オペレーションのグループ メンバーシップ
名前の検索や拡張グループの取得などのオペレーションに LDAP を使用すると、次のプロセスが発生します。
NetApp Volumes は、LDAP クライアント構成を使用してドメイン コントローラ LDAP サーバーに接続します。LDAP サーバーは、ストレージ プールの Active Directory ポリシーを使用して検出されます。
LDAP サービス ポートへの TCP 接続が成功すると、NetApp Volumes LDAP クライアントは、Active Directory ポリシーで定義された認証情報を使用してドメイン コントローラ LDAP サーバーにログインしようとします。
NetApp Volumes は、必要に応じて LDAP 署名を使用します。LDAP 署名には、LDAP サーバーの正しい DNS PTR レコードが必要です。
NetApp Volumes LDAP クライアントとドメイン コントローラ LDAP サーバー間の認証が成功すると、NetApp Volumes LDAP クライアントは RFC 2307bis LDAP スキーマを使用して LDAP サーバーをクエリします。クエリでサーバーに渡される情報は次のとおりです。
ドメイン名（
Baseまたはuser DN）検索範囲のタイプ（サブツリー）
オブジェクトクラス（ユーザーの場合は user、posixAccount、グループの場合は posixGroup）
UID またはユーザー名
リクエストされた属性（ユーザーの場合は uid、uidNumber、gidNumber、グループの場合は gidNumber）
ユーザーまたはグループが見つからない場合は、リクエストが失敗し、アクセスが拒否されます。
リクエストが成功すると、ユーザー属性とグループ属性がキャッシュに保存され、今後使用されます。拡張グループの名前のルックアップと取得により、キャッシュに保存されたユーザー属性またはグループ属性に関連する後続の LDAP クエリのパフォーマンスが向上し、LDAP サーバーへの負荷も軽減されます。
属性のキャッシュ保存
NetApp Volumes は、LDAP クエリの結果をキャッシュに保存します。次の表に、LDAP キャッシュの有効期間（TTL）の設定を示します。修正する構成ミスによりキャッシュに無効なデータが保持されている場合は、キャッシュが更新されるまで待ってから、Active Directory の変更が検出されるようにする必要があります。そうしないと、NFS サーバーは引き続き古いデータを使用してアクセスを検証するため、クライアントで権限が拒否されたという通知が表示される可能性があります。TTL 期間が経過すると、エントリは期限切れになり、古いエントリが残留しないようにします。不足しているルックアップ リクエストは、パフォーマンスの問題を回避するために 1 分間の TTL で保持されます。
| キャッシュ | デフォルトのタイムアウト |
|---|---|
| グループ メンバーシップ リスト | 24 時間の有効期間 |
| UNIX グループ（グループ ユーザー ID） | 有効期間 24 時間、ネガティブ有効期間 2 時間 |
| UNIX ユーザー（ユーザー ID） | 有効期間 24 時間、ネガティブ有効期間 2 時間 |
次のステップ
NetApp Volumes のアプリケーションの復元力の考慮事項を確認する。