Block Volumesに関するよくある質問

 

一般的な質問

Oracle Cloud Infrastructure (OCI) Block Volumesとは何ですか?

OCI Block Volumesは、永続的で耐久性があり、ハイパフォーマンスなデータ・ストレージを提供します。OCIでは、コンピュート・インスタンスの有効期間を超えて、ブロックボリュームに独立してデータを保存できます。OCI Block Volumesは、ブロック・ストレージ・ボリュームの動的なプロビジョニングと管理、データの制御、およびアプリケーションに必要なストレージ構成の実現に役立ちます。ストレージとアプリケーションの要件を満たすために、必要に応じてボリュームを作成、アタッチ、接続、移動できます。インスタンスにアタッチして接続すると、通常のハード・ドライブのようなボリュームを使用できます。ボリュームを切り離して、データを失うことなく別のインスタンスに接続することもできます。

ブロックボリュームとは何ですか?

ブロックボリュームは、データ・ストレージの一種で、ファイル・ストレージよりも拡張性があります。ブロック・ボリュームは、iSCSIイーサネット・プロトコルを使用して、オンプレミスのストレージ・エリア・ネットワーク(SAN)と同様の機能とパフォーマンスを提供し、データ・ライフ・サイクルのセキュリティと耐久性を実現できるよう設計されています。OCI Block Volumesは、コンピュート・インスタンスに作成およびアタッチすることができます。

どのようなときにブロックボリュームを使用すればよいですか?

ワークロード・アプリケーションに高可用性ストレージとSANのパフォーマンスが必要な場合、またはデータ・ガバナンスに統合バックアップを含める必要がある場合は、ブロックボリュームを使用することをお勧めします。アプリケーションは、サービスの弾力性、データの永続性、およびパフォーマンスの面でメリットが得られます。OCI Block Volumesは、シンプルな管理オプション、運用の柔軟性、従量制の価格設定に加え、分離と最大限の制御をお客様に提供します。

インスタンスが終了すると、データはどうなりますか?

ローカル・コンピュート・ドライブに保存されたデータは、コンピュート・インスタンスが存在する間のみ存続するため、このストレージ・オプションは一時ファイルにのみ使用する必要があります。耐久性の高いブロックボリュームにデータを保存すると、データはブロックボリュームの有効期間中保持されます。コンピュート・インスタンスが終了した場合、ボリュームを別のコンピュート・インスタンスにアタッチすると、そのボリューム内の永続的なデータに再びアクセスできます。ブロックボリュームを使用すると、統合ブロックボリューム・バックアップを含むようにデータ保護計画を拡張し、バックアップが作成された日にデータのコピーを提供することができます。

Block Volumesの使用を開始するにはどうすればよいですか?

コンソールREST API、またはSDKを使用して、Block Volumesにアクセスすることができます。詳細については、Oracle Cloud Infrastructureを開始するためのガイドおよびブロックボリュームの概要を参照してください。

Block Volumesは、ストレージ・インフラストラクチャにNVMe SSDを使用していますか?

その答えは「はい」です。業界をリードする最高パフォーマンスの NVMe ソリッド・ステート・ドライブを使用しています。これらのNVMe SSDは、高いパフォーマンスを備え、パフォーマンスSLAによって保証されており、ストレージ・キャッシュを使用せずに有効になります。

容量、パフォーマンス、セキュリティ

OCI Block Volumesでは、どのサイズのブロックボリュームをプロビジョニングできますか?

50 GB〜32 TBのブロックボリュームを1 GB単位でプロビジョニングできます。

オペレーティング・システムは、どのようにブロックボリュームにアクセスしますか?

オペレーティング・システムは、データ・ストレージ機能をリンクするためのストレージ・ネットワーク規格であるiSCSIプロトコルを使用してブロックボリュームにアクセスします。

単一のBlock Volumeには、どのようなパフォーマンス制限がありますか?

Block Volume Performanceドキュメント を参照してください。

仮想マシンにアタッチされた単一のBlock Volumeには、どのようなパフォーマンス制限がありますか?

Oracle Cloud Infrastructure Compute仮想マシン・インスタンスにアタッチされているBlock Volumesのパフォーマンスは、利用可能なネットワーク帯域幅によって制限されます。インスタンスの制限については、コンピュート・サービスに関するよくある質問を参照してください。

アプリケーションで最大のパフォーマンスを実現するにはどうすればよいですか?

ベアメタル・コンピュート・インスタンスで最大700,000以上のIOPSとニアラインレートのスループットを確認できます。詳しくは、Block Volume Performanceドキュメント を参照してください。

1つのコンピュート・インスタンスには、Block Volumesをいくつまでアタッチできますか?

コンピュート・インスタンスごとに最大32個のボリュームをアタッチできるため、コンピュート・インスタンスごとに最大32 TB*32=1 PBのアタッチ容量になります。ハイパフォーマンス・アプリケーションのニーズに応じて、アタッチ・ボリュームの数を計測および調整することをお勧めします。

Block Volumesを他のコンピュート・インスタンスに移動できますか?

その答えは「はい」です。最高のパフォーマンスを提供するために、Block Volumesは、同じ可用性ドメイン内のどのコンピュート・インスタンスにもアタッチできるように最適化されています。あるコンピュート・インスタンスからボリュームをデタッチし、コンピュート・サーバを再起動せずに、そのボリュームを別のコンピュート・インスタンスにアタッチすることができます。詳細は ドキュメントをご覧ください。

データのセキュリティをどのように確保していますか?

すべてのBlock Volumesとそのバックアップは、暗号化に256ビットのキーを使用するAdvanced Encryption Standard(AES)アルゴリズムを使用して、保存時に常に暗号化されます。インスタンスとBlock Volume間で移動されるすべてのデータは、安全性の高い内部ネットワークを介して転送されます。インスタンスとBlock Volume間でデータを移動する際にデータの暗号化に関連する特定のコンプライアンス要件を適用する場合、準仮想化ボリューム・アタッチを使用すると、転送中の暗号化を有効にできます。

Block Volumeとそのバックアップは、テナント/コンパートメント境界内でのみアクセスでき、テナント/コンパートメントへのアクセス権限が付与されている認証済みユーザーのみがアクセスできます。

ブートボリュームもBlock Volumesサービスによって提供および管理されるため、Block Volumesと同じ方法で保護されます。

Block Volumesでは、パフォーマンスや価格が異なるさまざまなオプションがありますか?

その答えは「はい」です。詳細については、Block Volume Elastic Performance Options および Block Volume Pricing を参照してください。

ボリュームのパフォーマンスや価格を変更できますか?

その答えは「はい」です。詳細については、Block Volume Elastic Performance Options および Block Volume Pricing を参照してください。

ボリュームのパフォーマンスを変更するにはダウンタイムが必要ですか?

いいえ。ボリュームがインスタンスにアタッチされているかどうかに関係なく、アプリケーションのダウンタイムなしでボリュームのパフォーマンスを変更できます。

パフォーマンスが低下したときに、動的にスケーリングすることは可能ですか?

その答えは「はい」です。Block Volumeの自動チューニング機能を使えば、1GBあたり最低10VPU、最高120VPUのパフォーマンスを設定できます。自動チューニング機能を使用することで、ブロックボリュームは必要な時に必要な分だけ使用します。

*注:ブートボリュームと単一パス・アタッチメントは現在この新機能を提供していませんが、この機能のサポートが将来のアップデートで提供される予定です。Block Volumeの自動チューニングの詳細については、Performance-Based Dynamic Scaling のドキュメントをご覧ください。

パフォーマンスベースの自動チューニングは、スケールアップとスケールダウンの際にどのくらい時間がかかりますか?

自動チューニングを使用すると、パフォーマンスの増加は迅速に反映されます。各レベルの調整に対して15秒以内にアクションが繰り返され、必要に応じて安定したパフォーマンスの増加が提供されます。パフォーマンスの減少はゆっくりと行われ、最初の減少は1時間後、その後の減少は数分後に行われ、パフォーマンスが必要とされているときに急激にボリューム・パフォーマンスを減少させないようになっています。詳細については、Performance-Based Dynamic Scaling のドキュメントをお読みください。

ブロックボリュームのパフォーマンスを自動チューニングすることで、コストを削減できますか?

はい、できます。しかし、常に保証されるわけではありません。この自動チューニング機能でコスト削減できるかどうかは、ワークロードの使用状況と、設定したパフォーマンスの高さによって決まります。ボリュームに対してこの機能を有効にし、設定する前に、アプリケーションの需要、使用パターン、および予算を理解する必要があります。OCI Block Volumeの価格設定のページを参照して、予算に基づいてボリュームのパフォーマンスの自動チューニング範囲を決定してください。

自動チューニングを使用してパフォーマンス・レベルを調整する場合、パフォーマンスを監視できますか?

はい。ボリュームのメトリックと監査ログを使用して、ボリュームのパフォーマンス特性や設定を監視することができます。ブロック ボリュームのメトリックと監査ログの詳細については、ドキュメント をお読みください。

耐久性

Block Volumesに保存されるデータの耐久性はどれくらいですか?

組み込みの修復メカニズムを使用して、データの複数のコピーが複数のストレージ・サーバーに冗長に保存されます。Block Volumesサービスは、ブロックボリュームとブートボリュームに関して年間99.99%(フォー・ナイン)の耐久性を提供するように設計されています。ただし、可用性ドメインの障害から保護するために、定期的にバックアップを作成することをお勧めします。

ボリュームのサイズを変更して、より大きなボリュームにするにはどうすればよいですか?

ダウンタイムなしで、オンラインでボリュームのサイズを増やすことができます。詳しくは、テクニカル・ドキュメントのページ をご覧ください。

「読み取り専用」アクセスのオプションとは何ですか、また、なぜそれが必要なのですか?

ブロックボリュームをアタッチするとき、アクセス・タイプを読み取り専用に指定するオプションがあります。このオプションでは、インスタンスはボリューム上のデータの読み取りのみが可能で、変更はできません。このオプションにより、未テストのアプリケーションや信頼できないアプリケーションによる偶発的または悪意のある変更からデータを保護できます。

また、複数の計算インスタンスがあり、それぞれがクライアント・アプリ(Webフロントエンドなど)を実行している場合に、読み取り専用で同じボリュームにアクセスする場合にも、読み取り専用アタッチを使用することができます。例えば、静的な製品カタログ情報をクライアントに提供するWebフロントエンドの場合です。

ブートボリュームでは読み取り専用アタッチ・オプションがサポートされていますか?

ブートボリュームは本質的に変更可能なため、デフォルトでは読み取り専用ではありません。ブートボリュームをデタッチした後、デバッグのために読み取り専用でアタッチすることはできます。

アタッチ済みのボリュームを「読み取り専用」にすることはできますか?

いいえ。そのためには、まずボリュームをデタッチし、「読み取り専用」属性を指定して再アタッチする必要があります。

ボリュームがすでに「読み取り専用」としてアタッチされている場合、そのボリュームを「読み取り/書き込み」用としてアタッチできますか?

いいえ。そのためには、まずボリュームをデタッチし、デフォルトのアタッチ・モード(「読み取り/書き込み」)を指定して再アタッチする必要があります。

ブロックボリュームのアタッチ・プロトコルまたはアタッチ・タイプにはどのようなオプションがありますか?

iSCSIと準仮想化の2つのオプションがあります。準仮想化ボリューム・アタッチは、VMインスタンスでのみサポートされています。

準仮想化ボリューム・アタッチとは何ですか?

準仮想化ボリューム・アタッチは、iSCSIイニシエータおよびアタッチを必要とせずに、ネイティブのオペレーティング・システムをサポートするブロックボリュームです。すべてのオラクルのオペレーティング・システム、Linux、およびWindowsは、VMデプロイメントのオプションとして準仮想化アタッチをサポートしています。

準仮想化アタッチは、どのような場合に使用すればよいですか?

準仮想化アタッチを使用すると、ブロックボリューム・アタッチの構成プロセスが簡素化されます。ボリューム・アタッチ中にiSCSI構成コマンドを実行したくない場合は、代わりに準仮想化アタッチの使用を検討することをお勧めします。iSCSIでは、追加の初期構成ステップの手間はかかりますが、パフォーマンスが優れていることに注意してください。

ボリュームをインスタンスにアタッチするときに、使用するアタッチ・タイプを選択できますか?

その答えは「はい」です。ボリュームをアタッチするときに、CLI/SDKやコンソールで接続タイプを選択できます。アタッチ・タイプを変更するには、ボリュームをデタッチしてから、新しいアタッチ・タイプを指定して再アタッチする必要があります。

iSCSIボリューム・アタッチと準仮想化ボリューム・アタッチのパフォーマンスに違いはありますか?

準仮想化アタッチのパフォーマンスは、iSCSIアタッチよりも劣ります。詳しくは、Block Volume Performanceドキュメント を参照してください。

バックアップ/復元

ブロックボリュームをバックアップできますか?

その答えは「はい」です。OCI Block Volumesは、統合バックアップ機能を備えており、ブロックボリュームのコピーをOCI Object Storageに保存することによってデータを保護します。

オペレーティング・システム・ディスク(ブートボリュームとも呼ばれる)をバックアップできますか?

その答えは「はい」です。ブートボリューム・バックアップでは、ブロックボリューム・バックアップのすべての機能を使用できます。Block Volumesは、オペレーティング・システム・ディスクをブートボリュームとして管理します。ブートボリュームの内容をバックアップするには、他のブロックボリュームと同じようにバックアップを作成します。OCIのブートボリュームは、統合バックアップ機能を備えており、ブートボリュームのコピーをOCI Object Storageに保存することによってデータを保護します。インスタンスの実行中にブートボリュームのバックアップを作成すると、クラッシュ整合性のあるバックアップが作成されます。ほとんどの場合、ブートボリューム・バックアップからインスタンスを直接作成したり、ブートボリューム・バックアップをインスタンスにアタッチしてデータを回復したりできます。起動可能なイメージを確保するには、インスタンスからカスタム・イメージを作成します。

Block Volumeバックアップとは何ですか?

バックアップは、そのバックアップが開始されたときのブロックボリューム上のすべてのデータの完全なポイントインタイム・スナップショットのコピーです。バックアップが完了するとすぐに、バックアップを使用してブロックボリュームに復元できます。バックアップは暗号化され、OCI Object Storageのアカウントにコピーされます。

どのようなときにバックアップを作成すればよいですか?

バックアップの主な用途は、ビジネス継続性、災害復旧、および長期アーカイブをサポートすることです。バックアップ・スケジュールを決定するとき、バックアップの計画と目標では以下を考慮する必要があります。

  • 頻度:データをバックアップする頻度
  • 回復時間:バックアップが復元され、そのデータを使用するアプリケーションからアクセス可能になるまで待機できる時間
  • 保存するバックアップの数:保持する必要があるバックアップの数と、不要になったバックアップの削除スケジュール

バックアップには、どれくらい時間がかかりますか?

バックアップは、ポイントインタイム・スナップショットを使用して行われます。したがって、バックアップがバックグラウンドで非同期的に実行されている間、アプリケーションは、中断やパフォーマンスへの影響が発生することなく、データへのアクセスを継続できます。2 TBのボリュームを初めてバックアップする場合、バックアップが完了するまで約30分かかります。50 GBのボリュームを初めてバックアップする場合、バックアップが完了するまで数分かかります。以降、同じボリュームのバックアップにかかる時間は、最後のバックアップ以降に変更されたデータの量に依存します。

どのようなバックアップ・オプションがありますか?

次の2つのオプションがあります。

1.ポリシーベースの自動スケジュール・バックアップ。オラクルが提供する定義済みのバックアップ・ポリシーを使用するか、独自のカスタム・バックアップ・ポリシーを作成して使用することができます。定義済みおよびカスタムのどちらのバックアップ・ポリシーでも、バックアップの頻度と保持期間を設定します。これにより、データ・コンプライアンスと規制要件を順守することができます。選択したバックアップ・ポリシーに基づいて、データがスケジュールに従って自動的にバックアップされて保持されるため、安心です。後でニーズの変化に応じて、別のバックアップ・ポリシーを選択したり、カスタム・ポリシーを変更したりして簡単に調整することができます。また、バックアップ・ポリシーをまとめて削除することもできます。

2.オンデマンドの1回限りのバックアップ。最後のバックアップ以降に変更されたデータのみをバックアップするか(増分バックアップ)、ボリュームを作成してから変更されたデータすべてをバックアップするか(完全バックアップ)を選択できます。

詳細については、テクニカル・ドキュメントを参照してください。

オンデマンドの完全バックアップに対して増分バックアップを実行できますか?

その答えは「はい」です。最後のバックアップ以降に変更されたデータのみをバックアップするか(増分バックアップ)、ボリュームを作成してから変更されたデータすべてをバックアップするか(完全バックアップ)を選択できます。

バックアップを実行すると、ライブ・データのパフォーマンスやアクセスに影響がありますか?

バックアップはポイントインタイム・スナップショットで行われるため、データへのアクセスに影響を与えることなく非同期で継続されます。バックアップ中のブロックボリュームへのアクセスは、中断、レイテンシの増加、パフォーマンスへの影響が発生することなく継続されます。

自動化されたポリシーベースのスケジュール・バックアップでは、どのバックアップ・ポリシーがサポートされていますか?

独自のカスタム・バックアップ・ポリシーを作成して適用できます。また、OCI Block Volumeサービスには、このドキュメントに記載されている、3つの異なる定義済みバックアップ・ポリシーが用意されています。

バックアップ・ポリシーをカスタマイズしたり、独自のバックアップ・ポリシーを定義して適用したりできますか?

その答えは「はい」です。日次、週次、月次、年次スケジュールを含む独自のバックアップ・ポリシーを作成し、そのポリシーをボリュームに割り当てて自動バックアップを行うことができます。また、既存のポリシーを複製し、必要に応じてスケジュールのパラメータを変更したり、ポリシーのスケジュールを追加または削除したりして、複製したポリシーをカスタマイズすることもできます。詳細については、テクニカル・ドキュメントを参照してください。

ボリュームからバックアップ・ポリシーを削除すると、既存のバックアップはどうなりますか?

既存のバックアップは、そのまま残ります。ただし、ポリシーに基づいて自動的に作成されたすべてのバックアップには有効期限があり、有効期限が切れると自動的に削除されます。手動で作成されたバックアップには有効期限がなく、削除されるまで残ります。

ボリュームのバックアップ・ポリシーを変更すると、既存のバックアップはどうなりますか?

既存のバックアップは、そのまま残ります。ただし、有効期限が切れると、作成時に有効だった設定に基づいて自動的に削除されます。ポリシーに基づいて自動的に作成されたすべてのバックアップには有効期限があり、有効期限が切れると自動的に削除されます。ボリュームのバックアップ・ポリシーを別のポリシーに変更すると、新しいポリシーが有効になり、新しいポリシーに従って新しいバックアップが自動的に作成されます。

ボリュームを削除すると、ポリシーベースのスケジュール・バックアップはどうなりますか?

バックアップとボリュームのライフサイクルは異なります。ボリュームが削除された場合、作成したバックアップの種類によっては、バックアップがボリュームのライフサイクルを超えて存続することがあります。ポリシーベースのバックアップには有効期限があります。有効期限が切れると、それらのバックアップは自動的に削除されます。バックアップをもっと長く保存したい場合は、手動でバックアップを作成する必要があります。手動で作成したバックアップには有効期限がありません。

ボリュームに割り当てられたバックアップ・ポリシーを変更できますか?可能な場合は、変更方法を教えてください。

その答えは「はい」です。コンソール、CLI/SDK、およびTerraformで変更できます。詳細については、オンラインのテクニカル・ドキュメントを参照してください。

ポリシーベースでのボリュームの自動スケジュール・バックアップでは、どのタイムゾーンを使用しますか?

オラクルが提供する定義済みのバックアップ・ポリシーを使用して作成されたバックアップは、ボリュームが存在するOCI可用性ドメインのタイムゾーンに基づいています。リージョン内のすべてのOCI可用性ドメインは同じタイムゾーンにあるため、事実上、スケジュール・バックアップはリージョンのタイムゾーンに基づくことになります。

カスタム・バックアップ・ポリシーでは、ポリシーの各スケジュール項目に対して、UTCとボリュームの存在するデータセンターのタイムゾーンのどちらを使用するかを指定できます。

カスタム・バックアップ・ポリシーに複数のスケジュールを定義できますか?

はい、複数の異なるスケジュールを作成できますが、各ボリュームをバックアップできるのは1日につき1回だけです。各カスタム・バックアップ・ポリシーでは、最大1つの日次スケジュール・エントリー、最大7つの週次スケジュール・エントリー(特定の時間に毎日1つ)、最大31の月次のスケジュール・エントリー(特定の時間に毎日1つ)、最大365の年次のスケジュール・エントリー(月、日、時間を指定)を設定することができます。特定の日にボリュームに対して複数のバックアップがスケジュールされている場合、サービスは年、月、週、日の優先順位でそのうちの1つだけを実行します。詳細については、テクニカル・ドキュメントを参照してください。

たとえば、毎日午前0時に日次バックアップ、毎週月曜日午前0時に週次バックアップを設定した場合、毎週月曜日には2つのバックアップがスケジュールされていることになります。同じ日に2つのバックアップがスケジュールされているため、保持時間が長くなる週次バックアップが優先されます。翌日、日次のバックアップしかスケジュールされていない場合、火曜日のバックアップは日次のスケジュール・バックアップとなり、翌日の次のスケジュール・バックアップまで保持されるように設定されています。

スケジュール・バックアップは、スケジュールどおりに正確に実行されることが保証されていますか?

スケジュール・バックアップが、予定どおりに実行されるように最善が尽くされます。ただし、システム負荷に基づいて、システム内の他のすべてのスケジュール・バックアップ・リクエストとともにキューに設定されて処理される場合があります。バックアップ・ステータスをチェックして、バックアップが完了したことを確認し、必要に応じて手動バックアップをトリガーしてください。

ボリュームの復元にはどれくらいの時間がかかりますか?

ボリューム・サイズに関係なく、1分未満でボリュームを復元できます。ボリュームの復元は高速で、ワークロードのためにボリュームにすぐにアクセスできますが、復元されたボリュームの使用を最初に開始する際に、レイテンシが急上昇する場合があります。

復元されたボリュームのパフォーマンスはどうなりますか?

新しく復元されたボリュームへのリクエストは、復元直後の短い期間、レイテンシが高くなる場合があります。

バックアップを使用して可用性ドメイン間でデータを移動できますか?

その答えは「はい」です。バックアップは、バックアップが保存されている同じリージョン内の任意の可用性ドメインに復元できます。これは、データを効率的に移動するために推奨される方法です。

オペレーティング・システム・ディスクをバックアップできますか?

はい。ブートボリュームのバックアップは、手動で作成するか、ポリシーベースの自動スケジュール・バックアップを使用して作成できます。また、コンピュート・サービスに関するよくある質問に従って、実行中のインスタンスからイメージを作成するオプションも確認してください。

あるリージョンから別のリージョンにBlock Volumeバックアップをコピーできますか?

はい。クロスリージョン・バックアップ・コピー機能を使用して、既存のBlock Volumeバックアップをアクセス可能な別のリージョンにコピーできます。

別のサイズのボリュームにバックアップを復元できますか?

その答えは「はい」です。バックアップからさらに大きなボリューム(現在サポートされている最大32 TBのボリューム・サイズまで)に復元することができます。

クローン

ボリューム・クローンとは何ですか?何をするためのものですか?

クローンは、Block Volumeの機能の1つで、バックアップおよび復元プロセスを実行することなく、既存のブロックボリューム全体を新しいボリュームにコピーできます。ソース・ボリュームのポイントインタイムのディープ・コピー(シック・クローンとも呼ばれる)を直接バックアップなしで作成します。

ブートボリューム・クローンを作成できますか?どのように機能しますか?

はい。ブロックボリューム・クローンを作成するのと同じように、ブートボリューム・クローンを作成できます。インスタンスの実行中にブートボリューム・クローンを作成すると、クラッシュ整合性クローンが作成されます。ほとんどの場合、ブートボリューム・クローンからインスタンスを直接作成したり、ブートボリューム・クローンをインスタンスにアタッチしてデータを回復したりできます。起動可能なイメージを確保するには、インスタンスからカスタム・イメージを作成します。

クローンの作成にはどのくらいの時間がかかりますか?

クローン操作はすぐに実行され、クローン操作を開始するとすぐにクローン・ボリュームを使用できるようになります。実際のデータのコピーは、バックグラウンドで行われます。所要時間は、ソース・ボリュームのデータ量に比例し、1 TBのボリュームに対して最大15分かかる場合があります。

クローン・ボリュームへのアクセスをいつから開始できますか?

クローンは、ライフサイクルが「利用可能」状態になったら(通常、数秒以内)、通常のボリュームとしてアタッチして使用できます。ハイドレーションは、バックグラウンドで継続されます。まだコピーされていないデータのブロックについては、レイテンシ・スパイクが発生する場合があります。

クローンはOCI Block Volumesやその他のクラウド・プロバイダにすでに搭載されているポイントインタイム・スナップショットやバックアップとどう違いますか?

Block Volumesクローンは、ボリューム全体のポイントインタイムのダイレクト・ディスク・ツー・ディスク・ディープ・コピーです。コピーオンライトまたはソース・ボリュームへの依存関係がないため、スナップショットとは異なります。関連するバックアップもありません。ブロックボリューム・クローンを作成するときに、スナップショットを作成したり、Object Storageにバックアップしたり、バックアップから復元したりすることはありません。

ボリュームのクローンを作成する前に、ボリュームをデタッチする必要がありますか?

いいえ。クローンは、ソース・ボリュームのポイントインタイムのダイレクト・ディスク・ツー・ディスク・ディープ・コピーによって作成されます。ボリュームのクローンを作成する前に、ボリュームをデタッチする必要はありません。

ボリュームのクローンを作成している間、ソース・ボリュームで変更される可能性のあるデータはどうなりますか?

クローンは、ソース・ボリュームのポイントインタイムのダイレクト・ディスク・ツー・ディスク・ディープ・コピーによって作成されます。クローンが「使用可能」になった時点のソース・ボリュームのすべてのデータがクローン・ボリュームにコピーされます。ソース・ボリュームでそれ以降に行われた変更は、クローンにコピーされません。

1つの可用性ドメインから別の可用性ドメインにボリュームのクローンを作成できますか?

いいえ、ブロックボリュームは、その可用性ドメインに固有です。ボリュームのクローンは、同じ可用性ドメイン内でのみを作成できます。

1つのコンパートメントから別のコンパートメントにボリュームのクローンを作成できますか?

その答えは「はい」です。クローン元コンパートメントおよびクローン先コンパートメントに対する必要なアクセス権限が必要になります。

1つのテナントから別のテナントにボリュームのクローンを作成できますか?

いいえ。ボリュームは、テナント境界内でのみアクセスできます。

1つのリージョンから別のリージョンにボリュームのクローンを作成できますか?

いいえ。ブロックボリュームは、可用性ドメインに固有のものであり、作成されたリージョンに存在します。ボリュームのクローンは、それらが存在するリージョンの同じ可用性ドメイン内にしか作成できません。

ソース・ボリュームよりも大きなサイズのクローンを作成できますか?

その答えは「はい」です。最大32 TBのクローン・サイズを指定できます。

1つのボリュームから同時にいくつのクローンを作成できますか?

ソース・ボリュームがアタッチされているかどうかによって異なります。

  • ソース・ボリュームがアタッチされている場合:一度に1つのクローンを作成できます。クローンは、ポイントインタイムのダイレクト・ディスク・ツー・ディスク・ディープ・コピーによって作成されます。クローン作成中は、ソース・ボリュームに対して1つのポイントインタイム・リファレンスが存在します。ソース・ボリュームからの最初のクローン操作が完了するまで待つ必要があります。
  • ソース・ボリュームがデタッチされている場合:同じソース・ボリュームから最大10個のクローンを同時に作成できます。

まだ作成中のクローンからボリュームのクローンを作成できますか?

作成中のクローン・ボリュームのライフサイクルによって異なります。

  • クローン・ボリュームが「利用可能」状態である場合:はい。
  • クローン・ボリュームが「プロビジョニング」状態である場合:いいえ。クローン・ボリュームが「利用可能」になったら、クローン・ボリュームからクローンを作成できます。

クローン作成中にソース・ボリュームをバックアップできますか?

クローン操作とバックアップ操作は相互に排他的です。ボリュームに対してバックアップが進行中である場合、ボリュームがアタッチされているかどうかに関係なく、クローンを作成したり、再度バックアップしたりすることはできません。ボリュームに対してクローン作成が進行中である場合、ボリュームがアタッチされているかどうかに関係なく、バックアップすることはできません。

クローン作成がまだ進行中でもクローン元のボリュームを削除できますか?

いいえ。ソース・ボリュームからいずれかのクローンにハイドレートされている間は、ソース・ボリュームを削除することはできません。

クローン・ボリュームを削除できるタイミングに制限はありますか?

クローンのライフサイクルが「利用可能」状態になると、クローンを削除できます。まだハイドレートされているクローンについても、ライフサイクルが「利用可能」状態になると削除できることに注意してください。

クローン・ボリュームが予期せず終了したのはなぜですか?

これは、ソース・ボリュームからクローンを開始し、クローンがソース・ボリュームからハイドレートされている間に、ソース・ボリュームをコンピュート・インスタンスにアタッチしてデタッチした場合に発生する可能性があります。この場合、同じソース・ボリュームに対して別のクローン・リクエストを開始すると、新しいクローンが終了状態になります。これにより、ハイドレート中の最初のクローンに影響が生じることはありません。最初のクローンが完全にハイドレートされると、ソース・ボリュームに対する後続のクローン操作が期待どおりに実行されます。

ブートボリューム

ブートボリュームとは何ですか?何を提供しますか?

ブートボリュームは、デフォルトで暗号化されたリモート・ブート・ディスクを提供し、ベアメタルおよび仮想マシン・インスタンスに、高速なパフォーマンス、起動時間の短縮、および耐久性の向上をもたらします。さらに、ブートボリュームを使用すると、再起動することなく、実行中の仮想マシンについて非常に高速なカスタム・イメージを作成できます。すべてのベアメタルおよび仮想マシンのコンピュート・インスタンスは、ブートボリュームを使用して起動し、以下のような利点を提供します。

  • コンピュート・インスタンスを終了したときにブート・ディスク・コンテンツを保持する機能:保持したブートボリュームを使用して、新しいインスタンスを作成できます。
  • 耐久性の高いブート・ディスク:すべてのブロックボリュームと同様に、ブートボリュームにも可用性ドメイン内に複数のレプリカが存在するため、コンピュート・インスタンスの耐久性について心配する必要がありません。
  • ブートボリュームを使用したコンピュート・インスタンスのスケーリング:インスタンスを終了するときに、そのブートボリュームを保持するオプションがあります。その後、元のインスタンスと保持しているブートボリュームを使用して、同じまたは異なるシェイプの新しいベアメタルまたは仮想マシン・インスタンスを作成することができます。
  • インスタンスの起動時間の短縮:すべての仮想マシンLinuxインスタンスは1分以内に起動し、仮想マシンWindowsインスタンスも5分以内に起動します。
  • すべてのブートボリュームのデフォルトによる暗号化:すべてのOCIブロックボリュームと同様に、ブートボリュームも保存時に暗号化されます。
  • ブート・ディスクとOSイメージを簡単にトラブルシューティングおよび修復する機能:問題のあるインスタンスを停止し、疑わしいブートボリュームをデタッチし、ブロックストレージとして他のインスタンスにアタッチして、トラブルシューティングおよび修復を行います。その後、元のコンピュート・インスタンスに再アタッチするか、そこから新しいインスタンスを作成できます。

ベアメタル・インスタンスまたは仮想マシンインスタンスにBlock Volumesでバックアップしたブートボリュームを使用するにはどうすればよいですか?

ベアメタルまたは仮想マシン・コンピュート・インスタンスを新しく起動すると、コンパートメント内に新しいブートボリュームが自動的に作成されます。OCIコンソールのインスタンスの詳細ページで、インスタンスにアタッチされているブートボリュームを確認できます。コンパートメント内のすべてのブートボリュームが「ブロック・ストレージ」コンソール・ページの「ブートボリューム」の下にリストされます。ブートボリュームの詳細には、ブートボリュームがアタッチされているインスタンス、ボリュームのサイズ、およびその他のボリューム・メタデータが含まれています。

ブートボリュームの価格はいくらですか?

ブートボリュームは、標準のBlock Volume価格で課金されます。これは、コンピュート・インスタンスの価格とは別に請求されます。

ブートボリュームは計測されてテナンシ・ブロック・ストレージ制限に含まれますか?

はい。ブートボリュームは、ブロックボリュームと同様に、計測されてテナンシ・ブロック・ストレージ制限に含まれます。そのため、ブロックボリュームの消費量に加えて、ブートボリュームの消費量も、テナンシ・ブロック・ストレージ制限の計算および計画に含める必要があります。

特定のブートボリュームを使用して別のインスタンスを起動できますか?

はい。最初に目的のブートボリュームのカスタム・イメージを作成し、そのカスタム・イメージを使用してインスタンスを起動することにより、特定のブートボリュームを使用して別のインスタンスを起動できます。カスタム・イメージを作成したくない場合は、アタッチされていないブートボリュームから直接新しいインスタンスを起動することもできます。

ブートボリュームにはどのような永続性および耐久性モデルがありますか?

ブートボリュームは、すべて耐久性の高いBlock Volumes上に作成されます。ブートボリュームは、コンピュート・インスタンスのライフサイクルに関係なく保持されます。ブートボリュームは、手動で削除した場合にのみ終了します。

既存のインスタンスでブートボリュームのメリットを活用するにはどうすればよいですか?

新しいインスタンスには、すべてデフォルトでブートボリュームが使用されます。カスタム・イメージを作成して新しいインスタンスを起動することにより、既存のインスタンスを再プロビジョニングできます。

ブートボリュームのバックアップを作成できますか?

はい。OCIコンソールの「コンピュート」ページにアクセスするか、API/CLIを使用して、ブートボリュームのバックアップを作成できます。バックアップは、バックアップ元のブートボリュームに関連付けられます。

ブートボリュームを削除できますか?

はい。コンソールまたはAPI/CLIを使用して、アタッチされていないブートボリュームを削除できます。また、インスタンスを終了するときに、削除確認ダイアログでチェックボックスを選択することにより、ブートボリュームを自動的に削除することを選択することもできます。

OCIでは、インスタンスに現在アタッチされているブートボリュームを削除することはできません。インスタンスを停止し、ブートボリュームをデタッチしてから、デタッチしたブートボリュームを削除することができます。ブートボリュームを削除した後は、停止したインスタンスを開始することはできません。インスタンスは終了するほかありません。

実行中のインスタンスからブートボリュームをデタッチできますか?

いいえ。ブートボリュームは、停止しているインスタンスからのみデタッチできます。インスタンスを終了すると、ブートボリュームを完全に削除することを選択しない限り、ブートボリュームが自動的にデタッチされて保持されます。

問題をデバッグするためにブートボリュームをブロック・ストレージとしてインスタンスにアタッチできますか?

その答えは「はい」です。別のインスタンスにアタッチするには、関連付けられているコンピュート・インスタンスから最初にブートボリュームをデタッチする必要があります。

以下の手順に従って、ブートボリュームをデバッグできます。

  • デバッグするインスタンスを「停止」し、「ブートボリューム」フィルタをクリックしてから、「ブートボリュームをデタッチ」ボタンをクリックします。または、ブートボリュームを保持するようにデフォルトで設定されているインスタンスを終了することもできます。
  • ブートボリュームのデバッグに使用する新しい実行中のインスタンスに移動し、「ブロックボリュームをアタッチ」ボタンをクリックします。

ブートボリュームを使用してコンピュート・インスタンスをより大きなシェイプにスケーリングするにはどうすればよいですか?

1. 古いインスタンスを終了し、インスタンスを終了するときに、元のブートボリュームを保持します(ブートボリュームを保持するかどうかを尋ねる確認ダイアログで「はい」を選択します)。

2 古いインスタンスから保持したブートボリュームを選択して、異なるシェイプの新しいインスタンスを起動します。

この方法は、ベアメタル・インスタンスおよびVMインスタンスの両方に適用されます。

*注意:新しいインスタンスは、元のインスタンスとは異なるIPアドレスとネットワーク構成になります。これらのインスタンスを使用するワークロードのシームレスなエクスペリエンスを実現するには、これらの違いを調整する必要があります。

ブートボリュームにはどのようなパフォーマンス特性がありますか?

ブートボリュームでは、ローカル・ブート・ディスクよりも、コンピュート・インスタンスの起動時間を短縮できます。

ブートボリュームは、デフォルトでは標準のOracle OSイメージ・サイズとなり、50 GBのブートボリュームに対して、3,000回のIOPSと24 MB/秒のスループットをミリ秒未満のレイテンシで実現します。これより大きなブートボリュームについても、Block Volumesと同様に、サイズに比例してパフォーマンスが向上するため、パフォーマンスを予測することができます。このパフォーマンスは、ワークロードの種類に依存しません(すべての読み取り/書き込みディストリビューションの場合)。詳しくは、Block Volume Performanceドキュメント を参照してください。

カスタム・イメージにブートボリュームを作成できますか?

OCIプラットフォームですでに使用している既存のカスタム・イメージがある場合は、それを使用してインスタンスを起動することを選択できます。カスタム・イメージを使用してインスタンスを起動した場合に作成されるブートボリュームは、カスタム・イメージと同じサイズになります。

デフォルトのOSイメージよりも大きいシステム・ブートボリュームでコンピュート・インスタンスを作成できますか?

その答えは「はい」です。コンピュート・インスタンスの起動時に、選択したOSイメージのデフォルトのサイズから最大32 TBまで、1 GB単位で任意のサイズを指定できます。ブートボリュームの最小サイズは、選択したOSイメージのサイズによって制限されます。50 GBまたは選択したOSイメージより小さいサイズを指定することはできません。たとえば、サイズが256 GBのOSイメージを選択した場合、使用するように指定できるブートボリュームの最小サイズは256 GBです。

コンピュート・インスタンスを作成した後、ブートボリュームのサイズを変更できますか?

はい。ダウンタイムなしで、オンラインでブートボリュームのサイズを増やすことができます。詳しくは、テクニカル・ドキュメント をご覧ください。

API/CLIでカスタム・ブートボリューム・サイズを指定するにはどうすればよいですか?

インスタンス起動APIを使用し、bootVolumeSizeInGBsパラメータを使用してもっと大きなブートボリューム・サイズを指定します。指定されたサイズがイメージ・サイズよりも小さい場合、API呼び出しは失敗しますのでご注意ください。

カスタム・ブートボリューム・サイズを指定しない場合は、どのサイズがコンピュート・インスタンスに使用されますか?

インスタンスは、選択したOSイメージのサイズに等しいデフォルトのブートボリューム・サイズで起動されます。

ボリュームグループ

ボリュームグループとは何ですか?

ボリュームグループは、バックアップやクローン作成で単一のエンティティとして扱うことができるブロックボリュームのセットを表します。ボリュームグループは、単一の可用性ドメインに関連付けられており、グループ内のボリュームも同じ可用性ドメイン内にあります

ボリュームグループはどのように使用しますか?

ボリュームグループには、個々のボリュームと同じバックアップ/復元およびクローン機能があります。つまり、ボリュームグループのポイントインタイム・クラッシュ整合性連携バックアップ(増分または完全)を実行したり、ボリュームグループのポイントインタイム・クラッシュ整合性クローンを作成したりできます。

ボリュームグループにボリュームを何個まで含めることができますか?

1つのボリュームグループに最大32個のボリュームを含めることができますが、ボリュームグループの合計サイズは128 TBです。これはソフト・リミットであるため、制限の引き上げをリクエストすることで、テナントごとに増やすことができます。各ボリュームは、1つのボリュームグループにのみ含めることができます。

ボリュームグループを管理するにはどうすればよいですか?

コンソール、CLI /SDK、API、およびTerraformを使用して、ボリュームグループを管理できます。これには、ボリュームグループの作成と削除、ボリュームグループに含めるボリュームの追加と削除、およびボリュームグループの名前の変更が含まれます。

ボリュームグループに含まれるボリュームをアタッチおよびデタッチできますか?

その答えは「はい」です。ボリュームグループに含まれるボリュームは、グループとして管理できることに加えて、個別にアクセスおよび操作できます。

ボリュームグループ・バックアップとは何ですか?どのように機能しますか?

ボリュームグループに含まれるボリュームセット全体のポイントインタイム・クラッシュ整合性連携バックアップのことです。バックアップ・プロセス中、バックアップ元のボリュームグループおよびボリュームへの影響はありません。

ボリュームグループ・バックアップは、ソースのボリュームグループが存在するリージョン内のすべての可用性ドメインに複製されます。ボリュームグループ・バックアップを使用して、ボリュームグループに含まれるすべてのボリュームを復元することにより、バックアップが存在するリージョン内の任意の可用性ドメインに新しいボリュームグループを作成できます。

ボリュームグループにポリシーベースの自動スケジュール・バックアップを使用できますか?

その答えは「はい」です。詳細についてはドキュメントをご覧ください。

ボリュームグループ・クローンとは何ですか?どのように機能しますか?

ボリュームグループ・クローンは、ボリュームグループに含まれるボリュームセット全体のポイントインタイム・クラッシュ整合性ディープ・ディスク・ツー・ディスク・コピーのことです。この操作により、新しいボリュームを含む新しいボリュームグループが作成されます。これらは、ソースのボリュームグループとそれに含まれるボリュームをそのままコピーしたものです。

クローン操作はすぐに実行され、クローン操作を開始するとすぐにクローン・ボリュームグループとそれに含まれるクローン・ボリュームを使用できるようになります。実際のデータのコピーは、バックグラウンドで行われます。所要時間は、ソース・ボリュームのデータ量に比例し、クローン作成には1TBのボリュームに対して最大15分かかる場合があります。

ソースのボリュームグループとそれに含まれるボリュームは、クローン・プロセスの影響を受けません。クローン元とクローン先のボリュームグループとそれに含まれるボリュームセットは、完全に分離されており、何も共有されていません。これにより、クローン操作の進行中およびクローン操作の完了時にソースに影響が出ないようになっています。

ボリュームグループのクローンとバックアップを同時に作成できますか?

ボリュームグループ内のソース・ボリュームがアタッチされているかどうかによって異なります。

  • ボリュームグループ内のいずれかのソース・ボリュームがアタッチされている場合:一度に1つのボリュームグループのクローンを作成できます。クローンは、ポイントインタイムのダイレクト・ディスク・ツー・ディスク・ディープ・コピーによって作成されます。クローン作成中は、ソース・ボリュームに対して1つのポイントインタイム・リファレンスが存在します。ボリュームグループの最初のクローン操作が完了するまで待つ必要があります。
  • ボリュームグループ内のすべてのソース・ボリュームがデタッチされている場合:同じソース・ボリュームグループから最大10個のクローンを同時に作成できます。

ボリュームグループとボリュームグループのバックアップ/復元およびクローン機能に追加料金はかかりますか?

これらの機能は、追加料金なしで提供されています。ブロックおよびブートボリューム・ストレージ(Block Volumesの価格)とボリュームグループ・バックアップ(Object Storageの価格)に対してのみ実際の使用量に基づいて課金されます。

ボリュームグループに関する詳細情報はどこで入手できますか?

ボリュームグループの開始方法と管理方法の詳細については、ボリュームグループのドキュメントを参照してください。

請求

Block Volumesの請求はどのように行われますか?

プロビジョニングされたボリューム・サイズ(GB)と各ボリュームに選択されたパフォーマンス・オプションに基づいてBlock Volumesが計測されます。使用されているBlock Volumeに対してBlock Volumesの価格で請求が行われます。

Block Volumesのバックアップの請求はどのように行われますか?

Block Volumesのバックアップは、Object Storageに保存され、それらによって消費されるObject Storageに基づいて計測および請求が行われます。詳細については、Object Storageの価格を参照してください。

Block Volumeのクロスリージョン・バックアップ・コピーの請求はどのように行われますか?

OCI Storageの価格を参照してください。クロスリージョン・バックアップは、Object Storageおよびアウトバウンド・データ転送ネットワークの使用量に基づいて計測および請求が行われます。