Etkinleştir Atılan HP 3PAR StoreServ 7400

Önceden sorulan bu sorulardan uzaklaşın

Monte edilmiş sürücüden boş alan nasıl elde edilir Redhat 7

Crypttab güncellemesi fstrim için Parola ister

38 ana makinede 170 VM ile donatılmış bir HP 3PAR StoreServ 7400 var.

İşte anladığım gibi sorun: (Ayrıca doğru olup olmadığından emin olmadığım bazı bilgiler söylendi, HP 3PAR StoreServ 7400 teknik incelemesini okudum ve gerçekten depolama adamımın ne olduğunu yedekleyen bir şey bulamıyorum Eğer biri doğru olmayan bir şey fark ederse lütfen bana bildirin.)

3 PAR 3 bölüme ayrılmıştır,

Katman 1: SSD, sık erişilen dosyaların önbelleğe alınması ve hızlı erişilmesi için kullanılır.

Katman 2: ve Katman 3: Bir çeşit eğirme diski, emin olmadığınız ek 2 katman ne ve neden var, ancak benim varsayım, Katman 2'ye en yaygın şekilde erişilmeyen ancak biraz erişilen veriler için kullanılır ve Katman 3 aşağıdakiler için kullanılır: geri kalanının depolanması.

Veriler bir SSD bloğuna yazıldığında ve daha sonra silindiğinde, yeni veriler yazılana kadar bu blok sıfırlanmaz, yani blok içindeki veriler silindiğinde eşlemeyi depolayan tablo bilgi güncellenir, daha sonra aynı bloğa yeni veriler yazıldığında, önce bloğun sıfırlanması gerekir ve sonra da yazılabilir. Sürücünün kesilmemesi halinde SSD içindeki bu işlem periyodiklik düşük w / r hızlarına yol açabilir.

3PAR LUN ince koşulludur, VM'ler Eager Kalınlıklıdır.

Depolama görevlime göre, 3PAR'ın SSD depolamasının kullanılmayan diğer VM'ler için kullanılmamasına izin veren özel bir özelliği var, bu da anlamsız.

Gerçek Kontrol:

Kalınlaştırılmış bir VM bir VMDK dosyasıdır, VM oluşturulduğunda VM'nin boyutunu belirtirsiniz ve bu bir VMDK dosyası oluşturur. Bana göre, VM düzenli olarak erişiliyorsa, tüm VMDK dosyasının SDD'ye taşındığını ve bana söyledikleri şey, VMDK 40GB kullanacak şekilde ayarlanmış olsa bile, 40GB'ın bir kısmının kullanılabileceği diğer VM'ler? Bu bana daha kalın değil, ince bir provizyon VM gibi geliyor.

Sorunu almak için Tamam.

Windows sistemlerimizde kullanılmayan blokları bulmak ve sıfırlamak için sdelete kullanıyoruz.

Linux Fedora sistemimizde her yerde çalışmak için nasıl çalışacağımı anlamaya çalıştım.

Dd = write-big-delete-big-file komutunu denedim ve fark edilen çatıdan disk G / Ç gönderdi ve bunu tekrar yapmamam söylendi.

Biraz araştırma yapmak bana sdelete hemen hemen dd = write-big-delete-big-file ile aynı şeyi yapıyor gibi görünüyor, bu yüzden disk I / O neden windows sistemlerinde çatı geçmiyor?

Bence bunu iki çözüme indirdim. Bunların hiçbirini nasıl yapacağımı bilmiyorum.

1. Bir şekilde VM'leri farklı bir depolama dizisine v-motion etmeden SAN'ın tüm SSD bölümünde fstrim benzeri bir işlevi çalıştırabilir.

Yan not: Eğer okuduğum her şeyi anlarsam fstrim her blokta verinin var olup olmadığını görmek için her bloğa bakar ve gerekirse, sdelete büyük bir dosya yazıp siler. Bu yüzden 3PAR'ın tüm SSD kısmında fstrim seçeneği arıyorum.

2. Longshot ama fstrim ile olsun hata:

[root @ rhtest ~] # fstrim -v / fstrim: /: silme işlemi desteklenmiyor

Atma seçeneğinin hem işletim sisteminde hem de veri deposunda ayarlanması gerektiğini okudum, ancak 3PAR'da bir atma seçeneğini nerede veya nasıl ayarlayacağımı anlayamıyorum, 3PAR'a hem SSH hem de GUI erişimine sahibim.

İşletim sistemi içinde afetler oluşturma konusunda sayısız yol boyunca ilerledim ve kaç farklı şekilde döndürdüğüm önemli değil, her zaman aynı hatayı alıyorum.

Evet ben de sıfır seçenek bir diğer seçeneklere baktım, ve akla gelmeyen bir çift diğerleri ancak onlar ya zdelete gibi çalıştı, ya da çok tehlikeli olduklarını okudum, ben hdparam vb içine baktı.

Aşağıda söz konusu işletim sistemi hakkında bazı çıktıları koyacağım, hepsi aynı.

[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

/ Bölümleri üzerinde fstrim çalıştırmak en iyi çözüm olacaktır, ancak onlar ESXi yapılandırılmış yolu ile mümkün olmazdı.

Hem VM'de hem de depolama aygıtında atmayı etkinleştirebilmeniz gerekir.

Xfs dosya sistemi ile bir bölümün veya mantıksal birimin boyutuna küçültmeye çalışmak, bu fedora ile ilgili bilinen bir hatadır. Bu işlevsellik ile ilgileniyorsanız lütfen Red Hat desteğine başvurun ve Red Hat bugzilla 1062667'ye başvurun ve XFS azaltma / küçültme gereksinimi için kullanım durumunuzu sağlayın.

Bazı ortamlarda olası bir çözüm olarak, ince provizyonlu LVM hacimleri XFS dosya sisteminin altında ek bir katman olarak düşünülebilir.

VM'ler istekli kalın koşullu VMDK ise, bu da birimlerinizi kesmeye (teknik olarak; SCSI UNMAP) giriştiğinizde geri kazanılacak hiçbir şey olmadığı anlamına gelir.

Arka uç depolama ince provizyon çalıştırıyorsa, depolama alanını azaltmak ve arka ucun sıcak verileri önbelleğe almasını / veri tekilleştirmesini mümkün kılmak için tembel sıfırlanmış VMDK dosyaları da kullanmanız gerekir.

İki olası seçenek:

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

Ne söyleyebilirim bu sdelete ile aynı şeyi yapar ancak disk I / O bir artış neden olabilir ve aynı zamanda çalıştırmak için bir süre alabilir.

Gece boyunca denenecek bir şey

Her iki seçenek de en iyisi değildir ancak ext3 veya ext4 elde etmek için her VM'yi yeniden biçimlendirmek mümkün görünmemektedir.

Yapabileceğiniz şey, tüm linux VM'leri için bir yakınlık kuralı oluşturmak ve yukarıdan 1. seçeneği kullanmaktır.

İstekli kalın koşullu VMDK kullanıyorsunuz.

Arka uç depolama ince provizyon çalıştırıyorsa , depolama alanını azaltmak ve arka ucun sıcak verileri önbelleğe almasını / veri tekilleştirmesini mümkün kılmak için tembel sıfırlanmış VMDK dosyaları kullanmanız gerekir .