破棄の有効化HP 3PAR StoreServ 7400

13

以前に尋ねられたこれらの質問から分離

38のホストに170のVMが展開されたHP 3PAR StoreServ 7400があります。

私が理解している問題は次のとおりです（また、真実かどうかわからない情報をいくつか聞いたことがありますが、HP 3PAR StoreServ 7400ホワイトペーパーを読みましたが、実際にストレージ担当者を裏付けるものは見つかりませんだから、もし誰かが真実ではないことに気付いたら、私に知らせてください。

3 PARは3つのセクションに分かれており、

レイヤー1：よくアクセスされるファイルのキャッシュとクイックアクセスに使用されるSSD。

レイヤー2：およびレイヤー3：回転するディスクの種類、不明な追加の2つのレイヤーが存在する理由と理由は不明ですが、最も一般的にアクセスされないデータにはレイヤー2が使用され、ビット3にアクセスするにはレイヤー3が使用されます残りのストレージ。

SSDブロックにデータを書き込むときに多くの記事で読んだSSD部分内で、新しいデータが書き込まれるまでそのブロックがゼロ化されないため、ブロック内のデータが削除されるとマッピングを格納するテーブル情報が更新され、新しいデータがその同じブロックに書き込まれるとき、ブロックは最初にゼロ化される必要があり、それから書き込むことができます。ドライブが周期的に調整されていない場合、SSD内のこのプロセスにより、速度が低下する可能性があります。

3PAR LUNはシンプロビジョニングされ、VMはEager Thickプロビジョニングされます。

私のストレージ担当者によると、3PARには特別な機能が組み込まれており、必要に応じて他のVMがSSDストレージを使用できないようにしますが、これは意味がありません。

事実確認：

シックプロビジョニングされたVMはVMDKファイルです。VMの作成時に、VMのサイズを指定すると、VMDKファイルが作成されます。私の心では、VMに定期的にアクセスしている場合、VMDKファイル全体がSDDに移動され、VMDKが40GBを使用するように設定されていても、その40GBの一部を使用できる他のVMですか？これは、シックではなくシンプロビジョニングされたVMのように思えます。

問題が発生しました。

Windowsシステムでは、sdeleteを使用して未使用のブロックを見つけてゼロにします。

私たちのLinux Fedoraシステムでは、私はfstrimを機能させる方法を模索していました。

dd = write-big-file delete-big-fileコマンドを試してみたところ、屋根からディスクI / Oが送られましたが、気が付いたので、もう一度やらないように言われました。

少し調べてみると、sdeleteはdd = write-big-file delete-big-fileとほとんど同じことをしているので、WindowsシステムのディスクI / Oが屋根を通過しないのはなぜですか？

だから私はそれを2つの解決策に絞り込んだと思う。どちらも私は方法を知っています。

どういうわけか、VMを別のストレージアレイにvモーションせずに、SANのSSD部分全体でfstrimのような機能を実行できます。

サイドノート：私が読んだすべてを理解したら、fstrimはすべてのブロックを見てデータが存在するかどうかを確認し、必要な場合は不要な場合はブロックをゼロにします.sdeleteが巨大なファイルを書き込んでから削除します。3PARのSSD部分全体でfstrimオプションを探しているのはそのためです。

ロングショットですが、fstrimでエラーが発生します：

[root @ rhtest〜]＃fstrim -v / fstrim：/：破棄操作はサポートされていません

OSとデータストアの両方で破棄オプションを設定する必要があることを読みましたが、3PARで破棄オプションを設定する方法や場所を理解できないのは、3PARにSSHとGUIの両方のアクセス権があります。

OS内での破棄の設定に関する無数のウォークスルーを行ってきましたが、いくつの方法でスピンしても、常に同じエラーが発生します。

はい、私はzerofreeが1であった他のオプションも検討しましたが、zdeleteのように機能したか、または非常に危険であることがわかりましたが、hdparamなどを検討しました

以下に、問題のOSに関する出力をいくつか示しますが、それらはすべて同じです。

[root@rhtest ~]# hostnamectl
    Static hostname: rhtest.domain.com
    Icon name: computer-vm
    Chassis: vm
    Machine ID: f52e8e75ae704c579e2fbdf8e7a1d5ac
    Boot ID: 98ba6a02443d41cba9cf457acf5ed194
    Virtualization: vmware
    Operating System: Red Hat Enterprise Linux Server 7.2 (Maipo)
    CPE OS Name: cpe:/o:redhat:enterprise_linux:7.2:GA:server
    Kernel: Linux 3.10.0-327.el7.x86_64
    Architecture: x86-64

[root@rhtest ~]# blkid
    /dev/block/8:2: UUID="2OHGU8-ir1w-LLGB-6v72-zZqN-CIaX-FjGImJ" TYPE="LVM2_member"
    /dev/block/253:1: UUID="ad872f09-5147-4252-af56-aa6244219515" TYPE="xfs"
    /dev/block/8:1: UUID="83aac355-a443-4ff9-90fa-9f6da8e31cc2" TYPE="xfs"
    /dev/block/253:0: UUID="dbe56f6a-2a4a-42da-82e2-bef9a73caafb" TYPE="swap"

[root@rhtest ~]# lsblk
    NAME                           MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
    fd0                              2:0    1    4K  0 disk
    sda                              8:0    0   50G  0 disk
    ââsda1                           8:1    0  500M  0 part /boot
    ââsda2                           8:2    0 49.5G  0 part
        âârhel_-rhtest-swap 253:0    0    2G  0 lvm  [SWAP]
        âârhel_-rhtest-root 253:1    0 47.5G  0 lvm  /
    sdb                              8:16   0   50G  0 disk
    sr0                             11:0    1 1024M  0 rom


[root@rhtest ~]# df -h
    Filesystem                              Size  Used Avail Use% Mounted on
    /dev/mapper/rhel_-rhtest-root   48G  883M   47G   2% /
    devtmpfs                                991M     0  991M   0% /dev
    tmpfs                                  1001M     0 1001M   0% /dev/shm
    tmpfs                                  1001M  8.5M  993M   1% /run
    tmpfs                                  1001M     0 1001M   0% /sys/fs/cgroup
    /dev/sda1                               497M  124M  374M  25% /boot
    tmpfs                                   201M     0  201M   0% /run/user/0

— アンソニーフォルニート
ソース

10

/パーティションでfstrimを実行できることが最善の解決策ですが、ESXiの構成方法では不可能です。

VMとストレージデバイスの両方で破棄を有効にする必要があります。

xfsファイルシステムを使用してパーティションまたは論理ボリュームのサイズを縮小しようとすることはできません。これはfedoraの既知のバグです。この機能に興味がある場合は、Red Hatサポートに連絡してRed Hat bugzilla 1062667を参照し、XFSの縮小/縮小が必要なユースケースを提供してください。

一部の環境で可能な回避策として、シンプロビジョニングされたLVMボリュームをXFSファイルシステムの下の追加レイヤーと見なすことができます。

VMが熱心なシックプロビジョニングされたVMDKである場合、つまり、ボリュームをトリム（技術的にはSCSI UNMAP）しようとしたときに再利用するものが何もないことを意味します。

バックエンドストレージがシンプロビジョニングを実行している場合、ストレージを削減し、バックエンドがウォームデータをキャッシュ/重複削除できるようにするために、遅延ゼロVMDKファイルも使用する必要があります。

2つの可能なオプション：

1. When storage is provided by a remote server across a SAN, you can only discard blocks if the storage is thin provisioned.

    1. VMotion all the VM's to a different data store and use the built-in VMWare tools
    2. Connect to the ESXi Host with SSH
    3. Navigate to the Virtual Machine Folder
    4. Verify disk usage with du
    5. Run vmkfstools -K [disk]
    6. Verify disk usage with du

2.  dd if=/dev/zero of=BIGFILE bs=1024000
    rm -f BIGFILE

私が言うことができることから、これはsdeleteと同じことをしますが、ディスクI / Oのスパイクを引き起こし、実行に時間がかかる可能性があります。

一晩試すもの

どちらのオプションも最適ではありませんが、すべてのVMを再フォーマットしてext3またはext4を取得することは現実的ではありません。

できるのは、すべてのLinux VMにアフィニティルールを設定し、上記のオプション1を使用することです。

— ブライアン・カーレス
ソース

3

熱心なシックプロビジョニングされたVMDKを使用しているため、ボリュームをトリム（技術的にはSCSI UNMAP）しようとしても、再利用するものはありません。

バックエンドストレージがシンプロビジョニングを実行している場合、ストレージを削減し、バックエンドがウォームデータをキャッシュ/重複削除できるようにするために、遅延ゼロVMDKファイルも使用する必要があります。

— パウスカ
ソース

答えてくれてありがとう、しかし、私はあなたの答えを完全に理解していないので、質問からの私の仮定がすべて正しい場合、特にVMDKファイルがSSDから回転ディスク。正しい？

— アンソニーフォルニート

3

@AnthonyFornito熱心なシックディスクでは、何も再生できません。Eager thickは、VMWareがバックエンドストレージにゼロを含む各ファイルの完全な割り当てを強制的に書き込むことを意味します。

— pauska

@pauskaは完全に正しいです。3PARおよび多くの同様のソリューションは、圧縮/重複排除/階層化向けに設計されています。ハイブリッド3PARモデルは、実際にはパフォーマンス指向の構成ではなく、容量効率に関するものです。だからこそ、熱心なゼロ化されたディスクの代わりに、遅延ゼロ化されたディスクを使用する方が良いのです。

— -Strepsils