どのFile Storage for Classic ボリュームが暗号化されているのかはどうすればわかりますか?

カスタマー・ポータルで File Storage for Classic のリストを参照してください。 ボリューム名の横に、ボリュームが暗号化されていることを示す鍵のアイコンが表示されます。

File Storage for Classicの正しいマウント・ポイントはどうすればわかりますか?

拡張データセンターにプロビジョニングされた、暗号化されたすべての File Storage for Classic ボリュームは、暗号化されていないボリュームとはマウントポイントが異なります。 正しいマウントポイントを使用していることを確認するには、コンソールの「 ボリュームの詳細 」ページでマウントポイントの情報を確認してください。 API 呼び出し SoftLayer_Network_Storage::getNetworkMountAddress() を使用して正しいマウント・ポイントを取得することもできます。

ボリュームをいくつプロビジョンできますか?

デフォルトでは、Blockボリュームと File Storage for Classic ボリュームを合わせて最大700個までプロビジョニングできます。 制限を増やすには、サポートにお問い合わせください。 詳しくは、ストレージ制限の管理を参照してください。

プロビジョニングされた File Storage for Classic ボリュームを、最大でいくつのサーバーインスタンスが共有できますか？

ファイル・ボリュームあたりの許可数のデフォルトの制限は 64 です。 この制限には、すべてのサブネット、ホスト、および IP 許可の組み合わせが含まれます。 この制限を増やすには、サポートに連絡してください。 詳しくは、サポート Case の作成を参照してください。

File Storage for Classic1 つのホストにボリュームをいくつ接続できますか?

1つのホストに接続できるボリューム数は、ホストのオペレーティングシステムが処理できる量によって異なります。 IBM Cloud® では、その点について制限を設けていません。 マウントできるファイル共有数に関する制限については、ご使用の OS の資料を参照してください。

特定のファイルボリュームサイズの場合、許可されるファイルとディレクトリの数はいくつですか？ ボリューム・サイズごとに許可される i ノードの最大数はいくつですか?

1 つのボリュームに含めることのできるファイル数は、そのボリュームにある i ノードの数に応じて決まります。 i ノードは、ファイルについての情報を含むデータ構造です。 ボリュームには、プライベート i ノードとパブリック i ノードの両方があります。 パブリック i ノードは顧客に公開するファイルに使用し、プライベート i ノードはストレージ・システムによって内部的に使用されるファイルに使用します。 ボリュームの容量32KBごとに1つのinodeを持つことになる。 ファイル数の最大値の設定は20億です。 ただし、この最大値は、 7.8 TB以上のボリュームでのみ設定可能です。 9,000 GB 以上のボリュームは、2,040,109,451 個の iノードで上限に達します。

File Storage for Classic ボリュームの最大ファイルサイズはどれくらいですか？

サポートされる最大ファイルサイズ（VMDKを含む）は、1ファイルあたり16 TBに制限されています。

File Storage for Classic ボリュームを間違ったデータ・センターで注文してしまいました。 このボリュームを別のデータ・センターに移動またはマイグレーションすることはできますか?

正しいデータセンターで新しい File Storage for Classic シェアを注文し、その後、誤った場所で注文した File Storage for Classic デバイスをキャンセルする必要があります。

また、共有の複製を作成して、元の共有を解除することもできます。 詳しくは、 複製ボリュームの作成および管理 を参照してください。

IBM Cloud VPC への大規模な移行をご検討の場合は、 IBM Cloud のクラシック・インフラストラクチャーからVPCへのデータ移行 をご覧ください。

File Storage for Classic ボリュームを「直ちに」キャンセルしましたが、コンソールにはまだ表示されています。 なぜ削除されないのか？

ボリュームがキャンセルされると、そのリクエストの後、24時間の再生待ち時間が発生する。 その 24 時間の間は、コンソールにボリュームが表示されています。 24時間の待機期間を設けることで、必要に応じてキャンセル依頼を取り消すことができます。 ボリュームの削除をキャンセルしたい場合は、 サポートケースを作成してください。

ボリュームの請求は即時に停止します。 レクラメーション期間が満了すると、データは破棄され、ボリュームもコンソールから除去されます。

IOPS の測定

IOPSは、16 KBのブロックを用いた負荷プロファイルに基づき、読み取りと書き込みがそれぞれ50％ずつランダムに行われる条件下で測定されます。 このプロファイルと異なるワークロードでは、パフォーマンスが低下する場合があります。 パフォーマンスを向上させるには、ホスト設定を調整するか、 ジャンボフレームを有効に してみてください。

パフォーマンス測定のために、より小さいIOサイズを使用するとどうなるのでしょうか？

IOサイズを小さく設定した場合でも、最大IOPSを実現できます。 しかし、スループットはこの場合より低くなります。 たとえば、6000 IOPSのボリュームでは、さまざまなIOサイズにおいて次のようなスループットが得られます：

• 16 KB * 6000 IOPS == ~93.75 MB/秒
• 8 KB * 6000 IOPS == ~46.88 MB/秒
• 4 KB * 6000 IOPS == ~23.44 MB/秒

割り振られた IOPS はインスタンス単位で適用されるのですか、ボリューム単位で適用されるのですか?

IOPS は、ボリューム・レベルで適用されます。 すなわち、6000 IOPS を使用できるボリュームに接続されるホストが 2 台あれば、それらのホストは 6000 IOPS を共有します。

IBM Cloud では、保証される最低IOPSはありますか？

いいえ、 IBM Cloud では、最低IOPS値を保証していません。 IOPS（1秒あたりの入出力操作数）は、ストレージ自体ではなく、ファイルストレージがマウントされているコンピューティングホストによって左右されます。 ストレージ容量には、プロビジョニングされた構成に基づいて、IOPSの上限およびスループットの上限が設定されています。 これらは上限値であり、下限の保証ではありません。

File Storage for Classic ボリュームをプロビジョニングする際は、IOPSティアを選択するか（Enduranceの場合）、カスタムIOPS値を指定します（Performanceの場合）。 この値は、ボリュームが処理できる最大IOPSを表します。 実際に体験するIOPSは、アプリケーションのワークロードや、コンピュートホストが生成するI/O操作によって異なります。

このストレージシステムは、以下の2つの要素に基づいてデータトラフィックを調整することができます：

• IOPSの上限- ボリュームが1秒あたりに処理できるI/O操作の最大数
• スループットの上限- 最大データ転送速度（IOPS × I/O サイズで算出）

アプリケーションで、標準の16 KBを超えるI/Oサイズを使用している場合、IOPSの上限に達する前にスループットの上限に達してしまいます。 たとえば、6000 IOPSのボリュームの場合：

• I/Oサイズが16 KBの場合：6000 IOPS（ ~93.75 MB/秒のスループット）を実現できます
• I/Oサイズが32 KBの場合：スループットの上限は3000 IOPS（ ~93.75 MB/秒のスループット）で到達します

I/Oサイズがパフォーマンスに与える影響に関する詳細については、以下を参照してください。 パフォーマンス測定のために、より小さいIOサイズを使用するとどうなるのでしょうか？

期待される処理能力を達成するには、容器を予熱する必要がありますか？

プリウォーミングは必要ありません。 ボリュームをプロビジョニングすると、ただちに指定したスループットになります。

より高速なイーサネット接続を使用すると、より多くのスループットを実現できますか?

スループットの制限はボリュームレベルで設定されます。 より高速なイーサネット接続を使用しても、この限度は増えません。 ただし、低速イーサネット接続では、帯域幅がボトルネックとなる可能性があります。

ファイアウォールおよびセキュリティー・グループはパフォーマンスに影響しますか?

ファイアウォールをバイパスするように VLAN 上でストレージ・トラフィックを実行することをお勧めします。 ソフトウェア・ファイアウォールを介してストレージ・トラフィックを実行すると、待ち時間が増加し、ストレージ・パフォーマンスに悪影響を与えます。

File Storage for Classic トラフィックを独自の VLAN インターフェースにルーティングし、ファイアウォールをバイパスするにはどうすればよいですか?

この適切な方法を実行するには、次の手順を実行します。

1. ホストおよび File Storage for Classic と同じデータ・センターに VLAN をプロビジョンします。

2. 2 次プライベート・サブネットを新しい VLAN にプロビジョンします。

3. 新しい VLAN をホストのプライベート・インターフェースにトランクします。 このアクションは、VLAN がホストにトランクされている間、短時間ホスト上のネットワーク・トラフィックを中断します。

4. ネットワーク・インターフェースを作成します。

   • Linux® ホストで、 802.11q インターフェースを作成します。 新しくトランクされた VLAN から未使用の 2 次 IP アドレスの 1 つを選択し、その IP アドレス、サブネット・マスク、ゲートウェイを新しい 802.11q インターフェースに割り当てます。
   • VMware® で、新しいVMkernelネットワークインターフェイス（vmk）を作成し、新しくトランク化されたVLANから未使用のセカンダリIPアドレス、サブネットマスク、およびゲートウェイIPを、この新しいvmkインターフェイスに割り当てます。

5. ターゲット NFS サブネットへの新しい永続的な静的ルートをホストに追加します。

6. 新規 IP がストレージにアクセスすることを許可します。

7. マウント指示については、ホストのホスト・オペレーティング・システムに応じて、次のうち該当するリンクを使用します。

   • Linux® での File Storage for Classic へのアクセス
   • ESXi ホストでの File Storage for Classic ボリュームのマウント
   • VMware分離されたVLAN間でストレージを接続するにはどうすればよいですか？

File Storage for Classic にどれくらいのパフォーマンス待ち時間を見込めばよいでしょうか?

ストレージ内の目標待ち時間は 1 ミリ秒未満です。ストレージは共有回線網上のコンピューティング・インスタンスに接続するため、正確なパフォーマンス待ち時間は、操作時のネットワーク・トラフィックに依存します。

File Storage for Classic のシェアを削除すると、データはどうなるのでしょうか？

IBM Cloud® File Storage for Classic では、お客様に対して物理ストレージ上のファイル共有が提供されます。この物理ストレージは再使用前にワイプされます。

File Storage for Classic ボリュームを削除すると、そのデータは即時にアクセス不能になります。 その物理ディスク上のデータを指すポインターはすべて削除されます。 後に同じアカウントまたは別のアカウントで新しいボリュームを作成する場合には、新しいポインターのセットが割り当てられます。 物理ボリューム上に過去に存在していたデータにそのアカウントでアクセスしようとしても、それらのポインターは削除されているため、アクセスできません。 新しいデータがディスクに書き込まれると、削除済みのボリュームのアクセス不能なデータは上書きされます。

IBM は、削除されたデータがアクセス不能になることと、削除されたデータが最終的に上書きされて消去されることを保証します。 さらに、お客様がストレージ・ボリュームを削除した場合、ストレージがお客様または別のお客様によって再使用可能になる前に、共有が上書きされる必要があります。

IBM が物理ドライブの使用を廃止する場合は、それらのドライブは破壊されたうえで処分されます。 廃止されたドライブは使用できなくなり、それらのドライブ上のデータはアクセス不能となります。

メディアのサニタイズに関する NIST 800-88 ガイドラインなどのコンプライアンスに関する特別な要件をお持ちのお客様は、ストレージを削除する前にデータのサニタイズ手順を実行できます。

「キャンセル」アクションがコンソールで使用できないのはなぜですか?

このストレージ・デバイスに関する取り消しプロセスが進行中なので、取り消しアクションを使用できなくなっています。 そのボリュームは、解放されるまで少なくとも24時間は表示されたままになります。 UI に非アクティブであることが示され、ステータス「キャンセル保留中」が表示されます。 24時間の最低待機期間を設けることで、必要に応じてキャンセル依頼を取り消すことができます。

ボリュームを誤って削除してしまいました

答えは、ストレージボリュームを削除したのが何年前か、すぐに削除するか記念日に削除するかによって異なります。 削除が過去24時間以内に行われた場合、または記念日がまだ来ていない場合、ボリュームはまだ取り戻されるのを待っているかもしれない。 ボリュームのステータスが「キャンセル待ち」になっている場合は、サポートに連絡してキャンセルリクエストを無効にすることができます。 再生期間が過ぎると、データは自動的に削除され、もはや復元することは不可能になるため、迅速に対応することが重要です。

サポートされている NFS バージョン

IBM Cloud® 環境では NFSv3 と NFSv4.1 の両方がサポートされます。 NFSv4.2 はサポートされていません。

可能な場合は、 NFSv3 プロトコルを使用してください。 NFSv3 は、安全な非同期書き込みをサポートし、以前の NFSv2よりもエラー処理でより堅固です。 64 ビットのファイル・サイズとオフセットをサポートするため、クライアントは 2 GB を超えるファイル・データにアクセスできます。

NFSv3 no_root_squash をネイティブでサポートしており、これによりルートクライアントは 共有上でルート権限を維持できます。 NFS この機能は、 NFSv4.1 で、ドメイン情報を編集し、「 rpcidmapd 」または同様のサービスを実行することで有効にできます。 詳しくは、NFS 用の no_root_squash の実装を参照してください。

VMware® デプロイメントで File Storage for Classic を使用する場合は、実装に NFSv4.1 を選択することをお勧めします。 詳細については、「 VMware vSphere での NFS の実行に関するベストプラクティス 」を参照してください。

VMware 展開における複数のホストで、異なる NFS プロトコルを使用している場合、同じファイル共有にアクセスできますか？

いいえ 異なる NFS バージョンを使用して、同じデータストアを複数のホストにマウントすることはできません。 NFS 3と NFS 4.1 のクライアントは同じロックプロトコルを使用していないためです。 互換性のない2つのクライアントから同じ仮想ディスクにアクセスすると、予期せぬ動作やデータの破損につながる可能性があります。 詳しくは、 NFS ファイル・ロックを参照。

VMware デプロイメントで VAAI および HW アクセラレーションを有効にできますか?

いいえ 現時点では、vStorage for API Array Integration および ハードウェア・アクセラレーションはサポートされていません。

クラウド・データ・センターから使用禁止にされたドライブはどうなりますか?

ドライブが使用禁止になると、IBM は、それらのドライブが処分される前に、破棄します。 ドライブは使用できなくなります。 ドライブに書き込まれたすべてのデータにアクセスできなくなります。

制御されたフェイルオーバーと即時のフェイルオーバーの違いは何ですか?

制御されたフェイルオーバーでは、ミラーリングのプロセスが中断される前に最後の 1 回の同期が行われます。 即時のフェイルオーバーでは、ミラーリングが即時に中断して、レプリカ・ボリュームがアクティブになります。

ストレージがオフラインまたは読み取り専用になっているように見えます。 これが起こる理由と、修正する方法について教えてください。

いくつかのシナリオにおいて、ホスト（ベアメタルまたは VM ）がストレージとの接続を一時的に失うことがあり、その結果、データの破損を防ぐために、ホストはそのストレージを読み取り専用とみなすことがあります。 ほとんどの場合、接続の切断はネットワークに関連したものですが、ネットワーク接続が復元された場合でも、ホストの観点からするとストレージの状況は読み取り専用のままになります。

この問題は、ネットワーク経由で接続された VMware® データストア（ NFS プロトコル）上のVMの仮想ドライブで発生することがあります。 この問題を解決するには、ストレージとホスト間のネットワーク経路に障害がないこと、およびメンテナンスや停止が行われていないことを確認してください。 その後、ストレージ・ボリュームをアンマウントしてからマウントします。 ボリュームが引き続き読み取り専用になっている場合は、ホストを再始動します。

マウントの指示について詳しくは、以下のトピックを参照してください。

• ESXi ホストでの File Storage for Classic のマウント
• Red Hat Linux® への File Storage for Classic のマウント
• Ubuntu へのFile Storage for Classic のマウント

このような事態が再発しないようにするため、 お客様は以下の対策を講じることをご検討ください：

• ゲスト OS チューニングの追加。 詳細については、 VMware® vSphere の導入におけるゲストOSのチューニングに関する NetApp's の推奨事項を参照してください。
• NFSv3 に NFSv4.1 を使用するホスト・システムの再構成。これにより、保守操作中の回復力を高めます。
• VMware® ESXi を実行しているホストシステムでのセッショントランキングを廃止します。 セッション・トランキングはサポートされておらず、中断を引き起こす可能性があることが知られています。

Cloud コンソールを使用して File Storage for Classic のボリューム・サイズを拡張しましたが、サーバーのサイズが同じままです。 これを解決するにはどうしたらよいですか?

拡張されたボリューム・サイズを確認するには、既存のFile Storage for Classic のディスクをサーバーにマウントしてから再マウントします。 VMware® の実装では、ストレージを再スキャンして VMware® データストアを更新し、新しいボリュームサイズを表示してください。

シャーシ交換後にどのようにストレージを再接続できますか?

スワップ後にストレージを接続するには、次のタスクを実行します。

1. ストレージデバイスからの認証を解除（アクセス権を取り消す）し、その後、ホストを再度認証してください。
2. 再認証によって取得した新しい認証情報を使用して、ストレージデバイスを再度検出してください。

詳しくは、File Storage for Classic の管理を参照してください。

ホストから自分のストレージ・デバイスを切断するにはどうすればよいですか?

ホストからボリュームを切断するには、以下のステップを実行します。

1. デバイスをアンマウントします。
2. Cloud コンソールのストレージ・デバイスからホストのアクセス権を取り消します。
3. NFS 接続から自動マウントを削除します。

エンデュランス・ストレージとパフォーマンス・ストレージにはどのような違いがありますか?

エンデュランスとパフォーマンスは、ストレージ・デバイスに関して選択できるプロビジョニング・オプションです。 つまり、エンデュランス IOPS 層は事前定義されたレベルのパフォーマンスを提供し、パフォーマンス層ではこれらのレベルを細かく調整できます。 ストレージには同じデバイスが使用されていますが、異なるオプションが搭載されています。 詳細については、「 File Storage の機能 」をご覧ください。

File Storage for Classic 共有を Windows に接続できますか?

いいえ IBM Cloud® File Storage for Classic の共有フォルダを Microsoft Windows にマウントすることはできません。 Windows 環境の NFS は、 IBM Cloud®ではサポートされていません。

File Storage for Classic 共有は、 Linux オペレーティング・システムにマウントすることも、ESXi ホスト上の VMware® データ・ストアとしてマウントすることもできます。 File Storage for Classic ボリュームのマウントについて詳しくは、以下のトピックを参照してください。

• Red Hat Linux® への File Storage for Classic のマウント
• Ubuntu へのFile Storage for Classic のマウント
• File Storage for Classic を ESXi ホスト上の VMware® データストアとしてマウントする

IBM Cloud 内の複数のホストに単一のストレージ・デバイスをマウントできますか?

はい、NFS はファイル対応プロトコルであるため、この設定を使用できます。

NFS ボリュームの i ノードを増やすことはできますか?

通常、ボリュームがプロビジョニングされると、注文したサイズの最大inode数がボリュームに割り当てられます。 ボリュームのサイズが大きくなるにつれて、最大iノード数は自動的に増加します。 ボリュームを拡張した後もiノード数が増加しない場合は、 サポートケースを提出してください。

ストレージをアップグレードできません。 ストレージのアップグレードまたは拡張を行うにはどの機能が関係していますか?

以下の状況は、ストレージをアップグレードまたは拡張する機能に影響を与える可能性があります。

• Cloud コンソールで持っている権限が要因になる場合があります。 詳細については、「 ユーザーの役割と権限 」内の各トピックを参照してください。

ストレージのアップグレードは、ボリューム上のデータに影響しますか？

いいえ ストレージボリュームの拡張やIOPS値の調整を選択しても、その変更はデータに影響を与えません。 これらの操作中、上書きやワイプは一切行われない。 この調整によって、ストレージにアクセスできなくなったり、停止したりすることはない。

File Storage for Classic ボリュームは、シン・プロビジョンまたはシック・プロビジョンのどちらですか?

すべてのブロックおよび File Storage for Classic サービスは、シン・プロビジョンされています。 この方式を変更することはできません。

請求 ID が変更されました。これはどういう意味ですか?

ご使用のストレージ・ボリュームが、「エンタープライズ・ストレージ」ではなく「エンデュランス・ストレージ・サービス」または「パフォーマンス・ストレージ・サービス」として請求されるようになったことに気付く場合があります。 コンソールには、IOPS を調整したり容量を増やしたりする機能などの新しいオプションもあります。 IBM Cloud® は、ストレージ機能の継続的な改善に努めています。 データセンターのハードウェアがアップグレードされるにつれて、それらのデータセンター内にあるストレージ容量も、強化された機能をすべて活用できるようアップグレードされます。 ストレージ・ボリュームの料金は、このアップグレードでは変更されません。

File Storage for Classicの耐久性はどの程度ですか?

File Storage for Classicに保管したデータは、暗号化され、耐久性、可用性にも優れます。 単一の可用性ゾーンの耐久性目標は 99.999999999% (11ナイン) です。 詳しくは、File Storage for Classic の可用性と耐久性を参照してください。

File Storage for Classic の平均アップタイムはどのくらいですか?　

File Storage for Classicに保管したデータは、暗号化され、耐久性、可用性にも優れます。 File Storage 業界最高水準の実績あるエンタープライズグレードのハードウェアおよびソフトウェアを基盤としており、高い可用性と稼働率を実現しています。 99.999 ％（5つの9）という可用性目標を確実に達成するため、データはHAペアを構成するノード上の複数の物理ディスクに冗長的に保存されます。 各ストレージ・ノードには、独自のソリッド・ステート・ドライブおよびそのパートナー・ノードの SSD への複数のパスがあります。 この構成により、パス障害だけでなく、ノードがパートナーのディスクに引き続きシームレスにアクセスできるため、コントローラの障害からも保護されます。 詳しくは、File Storage for Classic の可用性と耐久性を参照してください。

サポートチームからストレージのパフォーマンス指標（IOPSやレイテンシ）を入手することはできますか？

IBM Cloud® は、ストレージ・パフォーマンス IOPS および待ち時間のメトリックを提供しません。 お客様は、ご自分で選択したサード・パーティー・モニター・ツールを使用して、ご自身の File Storage for Classic デバイスをモニターする必要があります。

以下に、パフォーマンス統計を確認するために利用を検討できるユーティリティの例を挙げます。

• sysstat- Linux® オペレーティング・システム用のシステム・パフォーマンス・ツール。
• typeperf-パフォーマンス・データをコマンド・ウィンドウまたはログ・ファイルに書き込む Windows コマンド。
• esxtop- VMware® vSphere 環境におけるリソースの使用状況をリアルタイムで管理者に提供するコマンドラインツール。 すべてのシステム・リソース (CPU、メモリー、ディスク、およびネットワーク) のデータのモニターおよび収集ができます。

レプリカ・ボリューム、従属ボリューム、および独立した複製ボリュームの違いは何ですか?

ボリュームのスナップショットを使用して、レプリカまたは複製ボリュームを作成できます。 複製とクローン作成では、スナップショットの 1 つを使用してデータを宛先ボリュームにコピーします。 しかし、それは類似点が終わるところです。

レプリケーションによって、データは 2 つの異なる場所で同期されます。 一度にアクティブにできるのは、ペアの 1 つのボリューム (1 次ボリュームまたはレプリカ・ボリューム) のみです。 複製プロセスでは、複製スケジュールに基づいて、アクティブ・ボリュームから非アクティブ・ボリュームに情報が自動的にコピーされます。 レプリカ・ボリュームについて詳しくは、 データの複製 を参照してください。

複写により、親ボリュームと同じアベイラビリティー・ゾーン内のスナップショットに基づいてボリュームのコピーが作成されます。 複製ボリュームは元のボリュームの容量とパフォーマンスのオプションをデフォルトで継承し、スナップショットの特定時点までのデータの複製を保管します。 複製ボリュームは、元のボリュームに従属したり、元のボリュームから独立したりすることができます。また、親ボリュームからのデータを使用して手動で更新することができます。 親ボリュームに影響を与えることなく、IOPS を調整したり、重複のボリューム・サイズを増やしたりすることができます。

• 従属複製ボリュームは、独立した状態に変換されることはなく、作成後はいつでもリフレッシュできます。 元のスナップショットをロックして、従属する重複が存在している間はスナップショットを削除できないようにします。 従属する重複ボリュームが存在する間は、親ボリュームを取り消すことはできません。 親ボリュームを取り消したい場合は、最初に従属複製を取り消すか、独立複製に変換する必要があります。

• 独立した複製は、ほとんどの場合、従属する複製より優れていますが、作成直後に更新することはできません。これは、変換処理に時間がかかるためです。 ボリュームのサイズによっては、最大で数時間かかることがあります。 例えば、12 TB ボリュームの場合、最大 1 日かかることがあります。 ただし、分離プロセスの完了後に、元の親ボリュームの別のスナップショットを使用して、データを手動でリフレッシュすることができます。

重複について詳しくは、 重複ボリュームの作成と管理 を参照してください。

異なるタイプのボリュームコピー間の機能比較。
この表には行および列の見出しがあります。 行ヘッダーは機能を示します。 列見出しはボリュームコピーの種類を示します。

特長	レプリカ	従属の重複	独立した重複
スナップショットから作成
コピーされたボリュームのロケーション	リモート・アベイラビリティー・ゾーン	同じアベイラビリティー・ゾーン	同じアベイラビリティー・ゾーン
フェイルオーバーをサポート
サイズと IOPS が異なる
親ボリュームと自動同期されました
親ボリュームからのオンデマンド・リフレッシュ		[1]	[2]
親ボリュームから分離

従属複製を独立ボリュームに変換するのにどのくらいの時間がかかりますか?

変換処理が完了するまで、多少時間がかかる場合があります。 ボリュームが大きいほど、変換にかかる時間が長くなります。 12-TB ボリュームでは、24 時間かかる場合があります。 進行状況はコンソールまたは CLI から確認できます。

• コンソールで、 クラシック・インフラストラクチャー に移動します。 「ストレージ」 > File Storage for Classic をクリックして、リストからボリュームを見つけます。 変換状況は「概要」ページに表示されます。

• CLIから、次のコマンドを実行してください。

  slcli file duplicate-convert-status <dependent-vol-id>
  

  出力は、次の例と同様になります。

  slcli file duplicate-convert-status 370597202
  Username            Active Conversion Start Timestamp   Completed Percentage
  SL02SEVC307608_74   2022-06-13 14:59:17                 90
  

ユーザーの権限とアクセスを管理するにはどうすればよいですか？

アカウント所有者、または「ユーザークラシックインフラストラクチャの管理」権限を持つユーザーは、 IBM Cloud アカウント内の他のユーザーの権限を調整することができます。 アカウントの所有者でない場合は、すでに割り当てられている権限のレベルまたは権限の一部のみを割り当てることができます。 IBM Cloud コンソールで、 [管理] > [アクセス (IAM)] > [ユーザー] の順に選択します。 次に、アクセス権限を管理できるユーザー名をリストから選択し、「 クラシック・インフラストラクチャー 」をクリックします。 ユーザーにストレージの追加とアップグレードを許可するアカウント権限を選択します。 詳しくは、『クラシック・インフラストラクチャー・アクセス権限の管理』を参照してください。

ファイルストレージが準備されたら、ホストサーバーがファイル共有をマウントできるように権限を与える必要があります。 認証は、コンソール、CLI、API、またはTerraformで設定できます。 詳細は、 File Storage for Classicの 「ホストの認証」セクションをご覧ください。

ホストが認証された後、ファイル共有をマウントし、新しいフォルダ構造とファイルの所有者を割り当てることができます。 Linux では、 chown と chmod コマンドを使用して、個々のユーザーやグループに読み取り、書き込み、実行の権限を割り当てることで、アクセス制御をさらに厳密にすることができます。 詳細については、 Red Hat Linux® での File Storage for Classic のマウント」 および 「 Ubuntu での File Storage for Classic のマウント」を 参照してください。

APIを使用して、 File Storage for Classic で使用されている容量を取得できますか？

はい。 以下のcurlコマンドを使えば、IDで指定されたストレージ・ボリュームの使用容量を問い合わせることができる。

curl -g -u $SL_USER:$SL_APIKEY -X GET \
'https://api.softlayer.com/rest/v3.1/SoftLayer_Network_Storage/{volume_ID}/collectBytesUsed'

詳細については、 APIリファレンスを参照してください。

File Storage for Classic のボリュームをVPCに移行することはできますか？

はい。 ワークロードを IBM Cloud® Virtual Private Cloud に移行する予定の場合は、 IBM Cloud に、クラシック環境とVPC環境を接続し、 rsync や dcfldd などのツールを使用してデータをコピーする方法に関するガイダンスが掲載されています。 詳細については、 IBM Cloud のクラシック・インフラストラクチャーからVPCへのデータ移行 および、より広範な ClassicからVPCへの移行ガイド をご覧ください。