web-dev-qa-db-ja.com

破棄を有効にするHP3PAR StoreServ 7400

以前に尋ねたこれらの質問からスピンオフ

マウントされたドライブRedhat 7から空き領域を取得する方法

crypttabの更新でfstrimのパスフレーズが要求されます

HP 3PAR StoreServ 7400があり、38のホストに170のVMが広がっています。

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

3 PARは、3つのセクションに分かれています。

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

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

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

3PAR LUNはシンプロビジョニングされており、VMはEagerThickプロビジョニングされています。

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

ファクトチェック：

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

問題に取り掛かります。

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

私たちのLinuxFedoraシステムでは、fstrimを機能させる方法を見つけようとずっと努力してきました。

私はdd = write-big-file delete-big-fileコマンドを試してみましたが、それによってディスクI/Oがルーフを介して送信されましたが、これは気付きましたが、再度実行しないように指示されました。

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

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

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

補足：私が読んだすべてを理解している場合、fstrimはすべてのブロックを調べてデータがそこにあるかどうかを確認し、必要な場合は不要であればブロックをゼロにします。sdeleteは巨大なファイルを書き込んでから削除します。これが、3PARのSSD部分全体にわたるfstrimオプションを探している理由です。

  1. ロングショットですが、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
redhatssdhp-smart-arraytrim
13
Anthony Fornito

/パーティションで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が急上昇し、実行に時間がかかることがあります。

一晩試してみる何か

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

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

10
Brian Curless

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

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

3
pauska