よくある質問 Block Storage for Classic

Block Storage for Classic、1つのボリュームを共有できるサーバー・インスタンスはいくつありますか？

ブロック・ボリュームごとに許可される数の制限は、デフォルトでは 8 です。つまり、最大8つのホストBlock Storage for Classicへのアクセスを許可されるということです。 VMware® デプロイメントで Block Storage for Classic を使用するお客様は、許可制限を 64 に増やすことを要求できます。制限の引き上げを要求するには、サポート Caseを提出してサポートに連絡してください。

複数のホストが連携して管理されずに同じ Block Storage for Classic ボリュームをマウントすると、データが破損するリスクがあります。複数のホストによって同時にボリュームに変更が加えられると、ボリューム破損が発生する可能性があります。 Microsoft Cluster Shared Volumes (CSV)、 Red Hat Global File System (GFS2)、 VMware® VMFS などのデータ損失を防ぐには、クラスター対応の共有ディスク・ファイル・システムが必要です。詳細については、ホストのOSドキュメントを参照してください。

ネットワーク冗長性と拡張された帯域幅を確保するために、異なる IP アドレスの複数のネットワーク・カードが計算ホストに存在します。同じストレージ・ボリュームにアクセスするためにそれらすべてをどのように許可できますか?

コンソール、SLCLI、または API を使用して特定の Block Storage for Classic ボリュームにアクセスするよう IP アドレスのサブネットを許可することができます。特定のサブネット上の複数の IP アドレスから接続できるようにホストを許可するには、以下の手順を実行します。

コンソール

「クラシック・インフラストラクチャー」に移動します。
「ストレージ」 > **「Block Storage for Classic」**をクリックします。
ボリュームを見つけ、省略符号をクリックします。
**「ホストの許可」**をクリックします。
利用可能なIPアドレスのリストを表示するには、ホストタイプとして IPアドレスを選択します。次に、ホストがあるサブネットを選択します。
フィルターされたリストから、ボリュームにアクセスできる 1 つ以上の IP アドレスを選択して、**「保存」**をクリックします。

SLCLI

$ slcli block subnets-assign -h
Usage: slcli block subnets-assign [OPTIONS] ACCESS_ID
  Assign block storage subnets to the given host id.
  access_id is the host_id obtained by: slcli block access-list <volume_id>

Options:
  --subnet-id INTEGER  ID of the subnets to assign; e.g.: --subnet-id 1234
  -h, --help           Show this message and exit.

注文できるボリュームの数はいくつですか?

デフォルトでは、ブロック・ストレージとファイル・ストレージを合わせて合計700ボリュームをプロビジョニングできます。ボリューム制限を増やすには、サポートに連絡してください。詳しくは、ストレージの制限の管理を参照してください。

ホストにマウントできる Block Storage for Classic ボリュームの数はいくつですか?

それはホストOSが処理できることによるが、 IBM Cloud®、制限するようなことではない。マウント可能なボリューム数の制限については、お使いの OS の資料を参照してください。

OSの設定が異なる複数のボリュームを添付できますか？

いいえホストは、異なるOSタイプのボリュームに同時にアクセスする権限を持つことはできません。ホストは単一の OSタイプのボリュームにアクセスする権限を持つことができる。 OSタイプが異なる複数のボリュームへのアクセスをホストに許可しようとすると、その操作はエラーになります。

Block Storage for Classic ボリュームのWindowsバージョンをどのように選択すればよいですか？

ボリュームを作成する際には、OSタイプを指定する必要があります。 OSタイプは、ボリュームにアクセスするホストのオペレーティングシステムを指定します。また、ボリューム上のデータのレイアウト、そのデータにアクセスするために使用されるジオメトリ、およびボリュームの最小および最大サイズも決定します。 OS Typeはボリューム作成後に変更することはできません。ボリュームの実際のサイズは、ボリュームのOSタイプによって若干異なる場合があります。 Windows OS の正しいタイプを選択することで、入出力操作が適切に調整されないようにすることができます。

ボリュームがゲストに対して生のブロックデバイスとして表示されている場合は、ゲストのOSの種類を選択します。仮想ハードディスク（VHD）ファイルをハイパーバイザーに提供するボリュームの場合は、Hyper-Vを選択します。

Windows GPT

ボリュームは、GUIDパーティションタイプ（GPT）パーティションスタイルを使用してWindowsデータを格納します。このオプションは、GPT パーティショニング方式を使用しようとしていて、ホストでその方式の使用が可能な場合に使用します。 Windows Server 2003 (Service Pack 1 以降) では GPT パーティショニング方式を使用でき、64 ビット版のすべての Windows はこの方式をサポートしています。

Windows 2003

ボリュームは、マスター・ブート・レコード（MBR）パーティション・スタイルを使用するシングルパーティションのWindowsディスクのRawディスク・タイプを格納します。このオプションは、ホスト・オペレーティング・システムが、MBR パーティショニング方式を使用する Windows 2000 Server、Windows Server XP、または Windows Server 2003 である場合にのみ使用します。

Windows 2008+

このボリュームには、Windows 2008以降のバージョンのWindowsデータが格納される。ホスト・オペレーティング・システムが Windows Server 2008、Windows Server 2012、Windows Server 2016 の場合は、この OS オプションを使用します。 MBR と GPT の両方のパーティショニング方式がサポートされています。

Hyper-V

VHDX は、回復力のあるハイパフォーマンス仮想ディスクを作成するために Windows Server 2012 で導入された仮想ハード・ディスク・フォーマットです。このフォーマットには、より大きな仮想ディスク・サイズやより大きなブロック・サイズをサポートするなど、多くの利点があります。 VHDX メタデータ構造の更新をログに記録することにより、電源障害時のデータ破損に対する保護を提供します。 VHDファイルを処理するためにハイパーバイザーにボリュームが提示されている場合は、OSの種類としてHyper-Vを選択します。

割り振られる IOPS の制限はインスタンスとボリュームのいずれに従って適用されますか?

IOPS は、ボリューム・レベルで適用されます。言い換えれば、6000 IOPSのボリュームに接続された2台のホストは、その6000 IOPSを共有する。

ボリュームにアクセスしているホストの数は重要です。これは、単一のホストのみがボリュームにアクセスしている場合、使用可能な最大 IOPS を実現することが難しい可能性があるためです。

IOPS の測定

IOPSは、16KBブロック、ランダム50%リード、50%ライトの負荷プロファイルに基づいて測定されています。このプロファイルと異なるワークロードでは、パフォーマンスが低下する可能性があります。パフォーマンスを向上させるため、ホスト待ち行列項目数設定の調整またはジャンボ・フレームの有効化を試すことができます。

小さいブロック・サイズを使用してパフォーマンスを測定するとどうなりますか?

小さいブロック・サイズを使用しても、最大の IOPS が得られます。ただし、スループットは小さくなります。例えば、6000 IOPS のボリュームの場合、さまざまなブロック・サイズでのスループットは以下のようになります。

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

使用されているストレージの量を確認するにはどうすればよいですか? Block Storage for Classic の使用状況の詳細がコンソールに表示されないのはなぜですか？

Block Storage for Classic IBM Cloud®。ボリュームの中身を見ることはできないので、UIはディスク使用量に関する情報を提供できない。コンピュート・ホストのオペレーティング・システムから、使用されているディスク・スペースの量や空き容量など、ボリュームに関する詳細情報を取得できます。

Linux® では、以下のコマンドが使える。
```
df -h
```
このコマンドは、空きスペース量と使用率を示す出力を提供します。
```
$ df -hT /dev/sda1
Filesystem     Type      Size  Used Avail Use% Mounted on
/dev/sda1      disk      6.0G  1.2G  4.9G  20% /
```
Windowsでは、このPC をクリックして、ファイルエクスプローラーで空きディスク容量を表示することもできます。
```
fsutil volume diskfree C:
```
```
dir C:
```
出力の最後の行は、未使用のスペースの量を示している。

OS に表示される使用可能容量が、プロビジョンした容量と一致しないのはなぜですか?

理由の 1 つとして、オペレーティング・システムが base-2 変換を使用していることが考えられます。たとえば、コンソールで4000GBのボリュームをプロビジョニングすると、ストレージシステムは4,000GiBボリュームまたは 4,294,967,296,000 バイトのストレージスペースが提供されます。プロビジョンされたボリュームのサイズが 4 TB を超えています。ただし、オペレーティングシステムによっては、ストレージサイズが次のように表示されることがあります。 3.9 Tは使用するためbase-2変換とTはTiB,結核ではありません。

2 つ目は、 Block Storage を区分化し、そこにファイル・システムを作成することで、使用可能なストレージ・スペースを削減することです。フォーマットによって容量が減る量は、フォーマットの種類やシステム上のさまざまなファイルの量やサイズによって異なる。

ストレージ容量はGBで測定されますか？ GiB?

ストレージの紛らわしい側面の 1 つは、ストレージ容量と使用量が報告される単位です。場合によっては、GB は実際にはギガバイト (base-10) であり、GB はギビバイト (base-2) を表すことがあります。これは、 GiBと省略する必要があります。

人間は通常、10 進数 (base-10) システムで数値を考慮して計算します。 IBM の資料では、業界標準の用語に合わせて、GB 単位 (ギガバイト) を使用してストレージ容量を参照しています。 UI、CLI、API、および Terraform で、容量を照会したときに使用された単位 (GB) が表示されます。 4 TB ボリュームを注文する場合は、プロビジョニング要求に 4,000 GB を入力します。

ただし、コンピューターはバイナリーで動作するため、一部のリソース ( base-2のメモリー・アドレス・スペースなど) を表す方がより理にかなっています。 1984 年以降、コンピューター・ファイル・システムでは、メモリーとともにサイズが base-2 で表示されます。当時、使用可能なストレージ・デバイスは小さく、2 進単位と 10 進単位のサイズの差はほとんどありませんでした。使用可能なストレージ・システムがかなり大きいため、この単位の違いが混乱の原因となっています。

GB と GiB の差は、数値表現によって異なります。

GB (ギガバイト) は 10 進単位で、1 GB は 1,000,000,000 バイトに相当します。 GB を TB に変換する場合は、乗数として 1000 を使用します。
GiB (Gibibyte) は 2 進単位です。1 GiB は 1,073,741,824 バイトです。変換するとGiBにTiB,乗数として 1024 を使用します。

次の表は、10 進単位と 2 進単位で表される同じバイト数を示しています。

10進法と2進法
10 進数 SI (基数 10)	2 進数 (基数 2)
2,000,000,000,000 B	2,000,000,000,000 B
2,000,000,000キロバイト	1,953,125,000 KiB
2,000,000 MB	1,907,348 MiB
2,000 GB	1,862 GiB
2 TB	1.81 TiB

ストレージ・システムは、ボリューム割り振りに base-2 単位を使用します。そのため、ボリュームが 4,000 GB としてプロビジョンされている場合、実際には 4,000 GiB (4,294,967,296,000 バイトのストレージ・スペース) になります。プロビジョンされたボリュームのサイズが 4 TB を超えています。ただし、オペレーティングシステムによっては、ストレージサイズが次のように表示されることがあります。 3.9 Tは使用するためbase-2変換とTはTiB,結核ではありません。

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

プリウォーミングは必要ありません。ボリュームをプロビジョンすると即時に、示されたスループットが達成されます。

より高速なイーサネット接続を使用することによって、より多くのスループットを達成できますか?

スループットの上限はLUNレベルで設定されており、イーサネット接続が高速化しても上限は増加しない。ただし、低速イーサネット接続では、帯域幅がボトルネックとなる可能性があります。

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

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

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

このベスト・プラクティスを実施するには、以下の手順を実行します。

ホストおよび Block Storage for Classic と同じデータ・センターに VLAN をプロビジョンします。詳しくは、 VLAN の概要を参照してください。
新しいVLAN.3 にセカンダリー・プライベート・サブネットをプロビジョンします
新しい VLAN をホストのプライベート・インターフェースにトランクします。詳細については、「 VLANをサーバーにトランクするには」を参照してください。

このアクションは、VLAN がホストにトランクされている間、短時間ホスト上のネットワーク・トラフィックを中断します。
ホスト上にネットワーク・インターフェースを作成します。
- Linux® またはWindowsで、 802.11q インタフェースを作成する。新しくトランクした VLAN から未使用の 2 次 IP アドレスの 1 つを選択し、新しく作成した 802.11q インターフェースにその IP アドレス、サブネット・マスク、ゲートウェイを割り当てます。
- VMware® で、VMkernel ネットワーク・インターフェース (vmk) を作成し、未使用の 2 次 IP アドレス、サブネット・マスク、およびゲートウェイを、新しくトランクされた VLAN から新しい vmk インターフェースに割り当てます。
ホスト上の新しい永続的な静的ルートをターゲットの iSCSI サブネットに追加します。
新しく追加されたインタフェースのIPがホスト認証リストに追加されていることを確認する。
以下のトピックの説明に従って、ディスカバリーを実行し、ターゲット・ポータルにログインします。

802.3ad LACP ポート・チャネルを介して iSCSI トラフィックを実行するのは適切ですか?

いいえ iSCSI を使用する場合、Link Aggregation Control Protocol (LACP) は推奨される構成ではありません。 I/Oバランシングと冗長性のためにマルチパス入出力（MPIO）フレームワークを使用します。

MPIO 構成では、複数の NIC を持つサーバーは、対応する MPIO 対応ストレージ・デバイスへのすべての使用可能なインターフェースを介して入出力を送受信できます。このセットアップは冗長性を提供し、パスの1つが利用できなくなったとしても、ストレージのトラフィックが安定したままであることを確認できる。サーバーに2つの1Gb NICがあり、ストレージサーバーに2つの1Gb NICがある場合、理論上の最大スループットは約200MB/秒である。

NIC チーミングを介したリンク集約 (LACP や 802.3ad など) は、MPIO と同じようには機能しません。リンク集約は、単一の入出力フローのスループットを向上させることも、複数のパスを提供することもありません。単一のフローは常に 1 つのパスをトラバースします。リンク集約の利点は、複数の「固有の」フローが存在し、各フローが異なるソースからのものである場合に観察できます。個々のフローは、ハッシュ・アルゴリズムによって決定された、利用可能なNICインターフェイスに送信される。したがって、固有のフローが多いほど、NIC の数が多いほど、総計のスループットが向上します。

結合は、サーバーとスイッチの間で機能します。ただし、MPIO は、スイッチがパス内にあっても、ストレージ・サーバーとホストの間で機能します。

詳しくは、以下のいずれかの記事を参照してください。

Block Storage for Classic からの待ち時間はどのくらいですか?

ストレージ内のターゲット待ち時間は < 1 ミリ秒です。ストレージは共有ネットワーク上のコンピュート・インスタンスに接続されるため、正確なパフォーマンス待ち時間は、操作中のネットワーク・トラフィックによって異なります。

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

正しいデータセンターで新しい Block Storage for Classic ボリュームを注文し、間違った場所で注文した Block Storage for Classic デバイスをキャンセルする必要があります。

また、共有の複製を作成し、親共有をキャンセルすることもできます。詳細については、重複ボリュームの作成と管理を参照してください。

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

ボリュームが取り消されると、要求の後に 24 時間の再利用待機期間が続きます。その 24 時間の間は、コンソールにボリュームが表示されています。 24時間の待機期間は、必要であればキャンセル要求を無効にするチャンスを与える。ボリュームの削除を取り消す場合は、サポート Caseを提出してください。ボリュームの請求は即時に停止します。レクラメーション期間が満了すると、データは破棄され、ボリュームもコンソールから除去されます。

どの Block Storage for Classic ボリュームが暗号化されているかを知る方法はありますか?

IBM Cloud® コンソールで Block Storage for Classic のリストを見ると、暗号化されているボリュームのボリューム名の横にロックアイコンが表示されています。

Block Storage for Classic は、Db2 pureScale 用に I/O フェンシングを実装するための SCSI-3 永続予約をサポートしますか?

はい。Block Storage for Classic は、SCSI-2 と SCSI-3 永続予約の両方をサポートします。

Block Storage for Classic ボリュームが削除されるとデータはどうなりますか?

IBM Cloud® Block Storage for Classic は、物理ストレージ上のブロック・ボリュームを再利用する際には、ワイプ処理をしてからお客様に提供します。

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

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

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

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

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

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

クラウド・コンソールのキャンセル・アクションが無効になっているため、 Block Storage for Classic ボリュームをキャンセルできません。どうなっているのでしょうか?

このストレージ・デバイスに関する取り消しプロセスが進行中なので、取り消しアクションを使用できなくなっています。その量は、再生されるまで少なくとも24時間は目に見える形で残る。 UI に非アクティブであることが示され、ステータス「キャンセル保留中」が表示されます。最低24時間の待機期間があるため、必要に応じてキャンセル申請を無効にすることができます。ボリュームの削除を取り消す場合は、サポート Caseを提出してください。

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

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

私のWindows 2012ホストは複数のストレージ・ボリュームにアクセスできるはずですが、ディスク・マネージャーでそれらを見ることができません。これを解決するにはどうしたらよいですか?

同じホストで2つ以上のボリュームを使用し、すべての iSCSI 接続が同じストレージデバイスからである場合、ディスクマネージャには2つのデバイスしか表示されないことがあります。このような状況が発生した場合、 iSCSI Initiator の各デバイスに手動で接続する必要があります。詳しくは、Windows 2012 R2 のトラブルシューティング - 複数の iSCSI デバイスを参照してください。

Windows Server 2012 R2 は2023年10月10日にサポート終了を迎えました。マイクロソフトでは、このオペレーティングシステムに対するセキュリティ更新プログラム、バグ修正、テクニカルサポートの提供を終了しています。サーバーをWindows Server 2022などの新しいバージョンのオペレーティングシステムに移行します。

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

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

この問題は、MPIO 設定が適切ではないホストで発生する可能性があります。 MPIOが正しく設定されていないと、ホストはストレージへの接続を失い、接続の問題が解決してもストレージに再接続できない可能性がある。

単一パスで Block Storage for Classic を接続できますか? マルチパスは必要ですか？

単一パスでボリュームをアタッチすることは可能だが、サービスの中断を防ぐため、両方のパスで接続を確立することが重要である。 MPIO 接続の構成について詳しくは、以下の記事を参照してください。

Block Storage for Classic ボリュームへのマルチパス接続は、どのように構成、検証できますか?

計画保守中または計画外の中断中に、いずれかのルートがダウンします。 MPIO が正しく構成されている場合でも、ホストは 2 番目のパスを介して接続ストレージにアクセスできます。 MPIO設定の詳細については、以下のトピックを参照してください。

通常は負荷分散されているストレージデータパスが一時的に中断された場合、コンピュートホストは、接続されたストレージと通信するために、生き残ったデータパスのいずれかを選択せざるを得なくなります。その結果、増加したデータトラフィックは、より少ないデータパスで処理される。より少ないリソースでより多くのリクエストが処理されるため、レイテンシと接続確立時間が増加する可能性があります。

まれに、セカンドパスがダウンしている間にボリュームがプロビジョニングされ、アタッチされることがあります。このような場合、ディスカバリー・スキャンの実行時にホストに 1 つのパスが表示されることがあります。この現象が発生した場合は、 IBM Cloud® 状況ページを調べて、イベントがホストのストレージへのアクセス能力に影響しているかどうかを確認します。イベントが報告されない場合は、検出スキャンを再度実行し、すべてのパスが正しく検出されていることを確認する。イベントが進行中の場合、ストレージは単一パスに接続できます。ただし、イベント終了後にパスを再スキャンすることが重要です。再スキャン後も両方のパスが検出されない場合は、サポートケースを作成して適切に調査してください。

VMware の展開においてより安定した接続を実現するには、まず「Mounting ISCSI VMware ESXi」で説明されているように、ハイパーバイザー上にネットワークストレージをマウントします。次に、仮想マシンを作成し、仮想サーバーのOSからマルチパス接続で接続されたストレージボリュームをマウントします。詳細については、「 iSCSI SAN での ESXi の使用」、「ESXi 環境でのマルチパスとフェイルオーバーの理解」、および「ESXi での iSCSI および iSER のネットワーク設定」を参照してください。

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

新しい拡張ボリューム・サイズを表示するには、サーバー上の既存の Block Storage for Classic ディスクを再スキャンして再構成する必要があります。以下の例を参照してください。詳しくは、使用しているオペレーティング・システムの資料を参照してください。

Windows 2016

「サーバーマネージャー」>「ツール」>「コンピュータの管理」>「ディスクの管理」に移動します。
「アクション」>「リフレッシュ」をクリックします。
「アクション」>「ディスクの再スキャン」をクリックします。このプロセスが終了するまでに5分以上かかることもある。追加された容量は、既存のディスク上の割り当て解除されたパーティションとして表示されます。
割り当てを解除した領域を好きなようにパーティション分割する。詳しくは、 Microsoft-基本ボリュームの拡張を参照してください。

Linux

拡張したブロック・ストレージ・デバイスの各マルチパス・セッションからログアウトします。
```
# iscsiadm --mode node --portal <Target IP> --logout
```

ログインし直してください。

# iscsiadm --mode node --portal <Target IP> --login

iSCSI セッションを再スキャンします。
```
# iscsiadm -m session --rescan
```
fdisk -l を使用して新しいサイズをリスト表示し、ストレージが拡張されたことを確認します。

マルチパス・デバイス・マップを再ロードします。

# multipath -r <WWID>

# multipath -r 3600a09803830477039244e6b4a396b30
reload: 3600a09803830477039244e6b4a396b30 undef NETAPP  ,LUN C-Mode
size=30G features='3 queue_if_no_path pg_init_retries 50' hwhandler='1 alua' wp=undef
|-+- policy='round-robin 0' prio=50 status=undef
| `- 2:0:0:3 sda  8:0     active ready running
`-+- policy='round-robin 0' prio=10 status=undef
`- 4:0:0:3 sdd  8:48    active ready running

ファイル・システムを展開します。

LVM

物理ボリュームのサイズ変更。

# pvresize /dev/mapper/3600a09803830477039244e6b4a396b30
  Physical volume "/dev/mapper/3600a09803830477039244e6b4a396b30" changed
  1 physical volume(s) resized or updated / 0 physical volume(s) not resized

# pvdisplay -m /dev/mapper/3600a09803830477039244e6b4a396b30
  --- Physical volume ---
  PV Name               /dev/mapper/3600a09803830477039244e6b4a396b30
  VG Name               vg00
  PV Size               <30.00 GiB / not usable 3.00 MiB
  Allocatable           yes
  PE Size               4.00 MiB
  Total PE              7679 - Changed  <- new number of physical extents
  Free PE               2560
  Allocated PE          5119
  PV UUID               dehWT5-VxgV-SJsb-ydyd-1Uck-JUA9-B9w0cO

  --- Physical Segments ---
  Physical extent 0 to 5118:
  Logical volume  /dev/vg00/vol_projects
  Logical extents 6399 to 11517
  Physical extent 5119 to 7678:
    FREE

論理ボリュームのサイズ変更。

# lvextend -l +100%FREE -r /dev/vg00/vol_projects
  Size of logical volume vg00/vol_projects changed from 49.99 GiB (12798 extents) to 59.99 GiB (15358 extents).
  Logical volume vg00/vol_projects successfully resized.
  resize2fs 1.42.9 (28-Dec-2013)
  Filesystem at /dev/mapper/vg00-vol_projects is mounted on /projects; on-line resizing required
  old_desc_blocks = 7, new_desc_blocks = 8
  The filesystem on /dev/mapper/vg00-vol_projects is now 15726592 blocks long.

# lvdisplay
  --- Logical volume ---
  LV Path                /dev/vg00/vol_projects
  LV Name                vol_projects
  VG Name                vg00
  LV UUID                z1lukZ-AuvR-zjLr-u1kK-eWcp-AHjX-IcnerW
  LV Write Access        read/write
  LV Creation host, time acs-kyungmo-lamp.tsstesting.com, 2021-12-07 19:34:39 -0600
  LV Status              available
  # open                 1
  LV Size                59.99 GiB <--- new logical volume size
  Current LE             15358
  Segments               4
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     8192
  Block device           253:2

ファイルシステムのサイズを確認する。

# df -Th /projects
Filesystem                    Type  Size  Used Avail Use% Mounted on
/dev/mapper/vg00-vol_projects ext4   59G  2.1G   55G   4% /projects

詳しくは、 RHEL 8-論理ボリュームの変更を参照してください。

非 LVM- ext2、 ext3、 ext4:

growpartおよびxfs_progsユーティリティーを使用して、ディスク上の既存のパーティションを拡張します。インストールする必要がある場合は、以下のコマンドを実行します。

# yum install cloud-utils-growpart xfsprogs -y

パーティションを拡張したいボリュームをアンマウントします。
```
# umount /dev/mapper/3600a098038304338415d4b4159487669p1
```
growpart ユーティリティーを実行します。このアクションは、ext2、ext3、ext、または xfsf ファイル・システムのいずれであるかに関係なく、指定されたパーティションを拡張します。
```
# growpart /dev/mapper/3600a098038304338415d4b4159487669 1
CHANGED: partition=1 start=2048 old: size=146800640 end=146802688 new: size=209713119,end=209715167
```

partprobe を実行してディスクとそのパーティションを再読み込みし、 lsblk を実行して新しい拡張パーティションサイズを確認します。

# partprobe

# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 100G 0 disk
├─sda1 8:1 0 100G 0 part
└─3600a098038304338415d4b4159487669 253:0 0 100G 0 mpath
└─3600a098038304338415d4b4159487669p1 253:1 0 100G 0 part
sdb 8:16 0 100G 0 disk
└─3600a098038304338415d4b4159487669 253:0 0 100G 0 mpath
└─3600a098038304338415d4b4159487669p1 253:1 0 100G 0 part
xvda 202:0 0 100G 0 disk
├─xvda1 202:1 0 256M 0 part /boot
└─xvda2 202:2 0 99.8G 0 part /
xvdb 202:16 0 2G 0 disk
└─xvdb1 202:17 0 2G 0 part [SWAP]

パーティション上の既存のファイル・システムを拡張します。

パーティションをアンマウントします。

# umount /dev/mapper/3600a098038304338415d4b4159487669p1

e2fsck -f を実行し、リサイズを進める前にファイルシステムがクリーンで問題がないことを確認する。

# e2fsck -f /dev/mapper/3600a098038304338415d4b4159487669p1
e2fsck 1.42.9 (28-Dec-2013)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/mapper/3600a098038304338415d4b4159487669p1: 12/4587520 files (0.0% non-contiguous), 596201/18350080 blocks

resize2fsコマンドを発行して、ファイル・システムのサイズを変更します。

# resize2fs /dev/mapper/3600a098038304338415d4b4159487669p1
resize2fs 1.42.9 (28-Dec-2013)
Resizing the filesystem on /dev/mapper/3600a098038304338415d4b4159487669p1 to 26214139 (4k) blocks.
The filesystem on /dev/mapper/3600a098038304338415d4b4159487669p1 is now 26214139 blocks long.

パーティションをマウントし、 df -vh を実行して、新しいサイズが正しいことを確認します。

# mount /dev/mapper/3600a098038304338415d4b4159487669p1 /SL02SEL1160157-73

# df -vh
Filesystem Size Used Avail Use% Mounted on
/dev/xvda2 99G 3.7G 90G 4% /
devtmpfs 3.9G 0 3.9G 0% /dev
tmpfs 3.9G 1.7M 3.9G 1% /dev/shm
tmpfs 3.9G 25M 3.8G 1% /run
tmpfs 3.9G 0 3.9G 0% /sys/fs/cgroup
/dev/xvda1 240M 148M 80M 65% /boot
fsf-sjc0401b-fz.adn.networklayer.com:/SL02SV1160157_8/data01 40G 1.1G 39G 3% /SL02SV1160157_8
tmpfs 782M 0 782M 0% /run/user/0 /dev/mapper/3600a098038304338415d4b4159487669p1 99G 1.1G 93G 2% /SL02SEL1160157-73

非 LVM-xfs
1. xfs ファイル・システムをマウント・ポイントに戻します。 xfs パーティションの古いマウント・ポイントが分からない場合は、/etc/fstabを参照してください。
```
# mount /dev/sdb1 /mnt
```
2. ファイル・システムを拡張します。ファイル・システムのマウント・ポイントを置き換えます。
```
# xfs_growfs -d </mnt>
```

1 つのストレージ・デバイスを追加したのに、「ディスクの管理」に 2 つのディスクが表示されるのはなぜですか?

「ディスクの管理」に 2 つのディスクが表示されるという現象は、MPIO がインストールされていないか、ISCSI で無効になっている場合に生じることがあります。 MPIO 構成を確認するには、 Linux® の MPIO 構成の確認」または「Windows オペレーティングシステムで MPIO が正しく構成されているかどうかを確認する」の手順を参照してください。

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

シャーシ交換後にストレージを正常に再接続するには、以下の手順を実行します。

スワップの前に、ストレージ・デバイスから許可 (アクセス権限の取り消し) を削除します。
スワップ後、ホストを再度許可します。
新しい許可から取得した新しい資格情報を使用して、ストレージ・デバイスを再びディスカバーします。

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

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

以下のステップを実行して、ホストから切断します。

オペレーティング・システム ISCSI セッションを削除します。該当する場合には、デバイスをアンマウントします。
IBM Cloud® コンソールのストレージデバイスからホストのアクセスを取り消す。
自動ディスカバリーを削除します。該当する場合には、ISCSI 接続のデータベース・エントリーをオペレーティング・システムから削除します。

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

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

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

ストレージのアップグレードまたは拡張を行うには、以下の状況が影響を及ぼすことがあります。

IBM Cloud® コンソールに設定されているパーミッションが要因となることがあります。詳しくは、ユーザーの役割と許可内のトピックを参照してください。

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

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

iSCSI ボリュームはシン・プロビジョニングですか、それともシック・プロビジョニングですか？

すべてのファイルと Block Storage for Classic のサービスはシン・プロビジョニングです。この方式を変更することはできません。

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

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

Block Storage for Classicの永続性はどの程度ですか?

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

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

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

Block Storage for Classic ボリュームを OS から識別するにはどうすればよいですか?

コンピュート・ホスト上で接続されたストレージ・ボリュームの LUN ID を検索する理由には、さまざまな理由があります。例えば、同じホストに同じボリューム・サイズでマウントされている複数のストレージ・デバイスがあるとします。いずれか 1 つを切り離して廃止する必要があります。ただし、 Linux® ホストで表示されるものとコンソールで表示されるものを相関させる方法がわからない場合があります。別の例として、複数の Block Storage for Classic ボリュームが ESXi サーバーに接続されている場合があります。ボリュームの1つのボリュームサイズを拡張したい場合、その作業を行うにはストレージの正しいLUN IDを知る必要があります。 OS 固有の説明については、以下のいずれかのリンクをクリックしてください。

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

IBM Cloud® は、ストレージ・パフォーマンス IOPS および待ち時間のメトリックを提供しません。お客様は、選択したサード・パーティー・モニター・ツールを使用して、独自の Block 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 から確認できます。

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

CLIから以下のコマンドを使用する。

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

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

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

ポータブル・ストレージに関する詳しい情報はどこにありますか？

ポータブル・ストレージ・ボリューム (PSV) は、Virtual Servers専用の補助ストレージ・ソリューションです。ある仮想サーバーから PSV を切り離して、別の仮想サーバーに接続することができます。ポータブル・ストレージ・ディスクは、一度に1つの仮想サーバーに接続することができ、ディスクに保存されているすべての情報は、デバイス間の転送のために保持されます。詳しくは、ポータブル SAN ストレージを参照してください。

従属する重複は、作成直後に更新できます。 ↩︎
独立した重複は、分離プロセスの完了後にリフレッシュできます。 ↩︎