Abilita Elimina HP 3PAR StoreServ 7400


13

Esci da queste domande precedenti

Come ottenere spazio libero dall'unità montata Redhat 7

Aggiorna crypttab chiede Passphrase per fstrim

Abbiamo un HP 3PAR StoreServ 7400 con 170 macchine virtuali disponibili su 38 host.

Ecco il problema per come lo capisco: (Inoltre mi sono state fornite alcune informazioni che non sono sicuro che siano vere o no, ho letto il white paper HP 3PAR StoreServ 7400 e non riesco davvero a trovare nulla che supporti il ​​mio ragazzo di archiviazione dicendomi. Quindi, nel seguito, se qualcuno nota qualcosa di non vero, per favore fatemelo sapere.)

Il 3 PAR è suddiviso in 3 sezioni,

Livello 1: SSD utilizzato per memorizzare nella cache e accedere rapidamente ai file a cui si accede comunemente.

Livello 2: e Livello 3: un qualche tipo di disco rotante, cosa e perché ci sono 2 livelli aggiuntivi non sono sicuro ma il mio presupposto è che il Livello 2 viene utilizzato per i dati a cui non si accede più comunemente ma che accede un po 'e il Livello 3 viene utilizzato per conservazione del resto.

All'interno della parte SSD come ho letto in molti articoli quando i dati vengono scritti su un blocco SSD e quindi cancellati, quel blocco non viene azzerato fino a quando non vengono scritti nuovi dati su di esso, quindi quando i dati all'interno del blocco vengono eliminati la tabella che memorizza il mapping le informazioni vengono aggiornate, quindi quando i nuovi dati vengono scritti nello stesso blocco, il blocco deve prima essere azzerato e quindi può essere scritto. Questo processo all'interno di SSD se il disco non viene periodicamente regolato può portare a una riduzione della velocità in bianco e nero.

Il LUN 3PAR è sottoposto a thin provisioning, mentre le VM sono dotate di Eager Thick provisioning.

Secondo il mio ragazzo di archiviazione, la 3PAR ha una funzione speciale integrata che consente di non utilizzare l'archiviazione SSD per essere disponibile per le altre VM in base alle esigenze, il che non ha senso.

Verifica dei fatti:

Una VM con provisioning spesso è un file VMDK, quando viene creata la VM si specifica la dimensione della VM e questo crea un file VMDK. Nella mia mente ciò mi dice che se si accede regolarmente alla VM, l'intero file VMDK viene quindi spostato su SDD e ciò che mi dicono è che anche se la VMDK è impostata per utilizzare 40 GB, alcuni di quei 40 GB possono essere utilizzati su altre macchine virtuali? Mi sembra più una VM con thin provisioning e non una di spessore.

Ok, arriva al problema.

Sui nostri sistemi Windows utilizziamo sdelete per trovare e azzerare i blocchi inutilizzati.

Sul nostro sistema Linux Fedora sono stato dappertutto cercando di capire come far funzionare fstrim.

Ho provato il comando dd = write-big-file delete-big-file e che ha inviato l'I / O del disco attraverso il tetto, che è stato notato, e mi è stato detto di non farlo di nuovo.

Facendo una piccola ricerca mi sembra che sdelete faccia praticamente la stessa cosa di dd = write-big-file delete-big-file, quindi perché l'I / O del disco non passa attraverso il tetto sui sistemi Windows?

Quindi penso di averlo ridotto a due soluzioni. Nessuno dei quali so come fare.

  1. In qualche modo senza v-motioning le VM su un array di archiviazione diverso essere in grado di eseguire una funzione simile a fstrim sull'intera porzione SSD della SAN.

Nota a margine: se capisco tutto quello che ho letto fstrim guarda ogni blocco per vedere se i dati sono lì e se sono necessari, se non necessari azzereranno il blocco, dove come sdelete scrive un file enorme e quindi lo elimina. Questo è il motivo per cui sto cercando un'opzione fstrim in tutta la porzione SSD della 3PAR.

  1. Longshot ma l'errore che ottengo con fstrim è:

[root @ rhtest ~] # fstrim -v / fstrim: /: l'operazione di eliminazione non è supportata

Ho letto che l'opzione di eliminazione deve essere impostata sia sul sistema operativo che sull'archivio dati, ma non riesco a capire dove o come impostare un'opzione di eliminazione su 3PAR ho accesso SSH e GUI a 3PAR.

Ho passato innumerevoli procedure dettagliate sull'impostazione degli scarti all'interno del sistema operativo e non importa in quanti modi diversi lo eseguo, ricevo sempre lo stesso errore.

Sì, ho anche esaminato altre opzioni che zerofree era una, e un paio di altre che non mi vengono in mente comunque hanno funzionato come zdelete, o ho letto che erano molto pericolose, ho guardato in hdparam ecc.

Di seguito inserirò alcuni output relativi al sistema operativo in questione, che sono tutti uguali.

[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

Risposte:


10

Essere in grado di eseguire fstrim su / partitions sarebbe la soluzione migliore, tuttavia con il modo in cui ESXi è configurato non sarebbe possibile.

Devi essere in grado di abilitare gli scarti sia sulla macchina virtuale che sul dispositivo di archiviazione.

Cercare di ridurre le dimensioni di una partizione o di un volume logico con il filesystem xfs non può essere fatto, si tratta di un bug noto con fedora. Se sei interessato a questa funzionalità, contatta il supporto Red Hat e fai riferimento a Red Hat bugzilla 1062667 e fornisci il tuo caso d'uso per la riduzione / riduzione di XFS.

Come possibile soluzione in alcuni ambienti, i volumi LVM con thin provisioning possono essere considerati come un livello aggiuntivo sotto il file system XFS.

Se le macchine virtuali sono VMDK con provisioning di grandi dimensioni, il che significa che non c'è nulla da recuperare quando si tenta di tagliare (tecnicamente parlando; SCSI UNMAP) i volumi.

Se l'archiviazione back-end esegue il thin provisioning, è necessario utilizzare anche file VMDK azzerati in modo pigro per ridurre l'archiviazione e consentire al back-end di memorizzare nella cache / deduplicare i dati caldi.

Due possibili opzioni:

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

Da quello che posso dire questo fa la stessa cosa di sdelete, tuttavia può causare un picco nell'I / O del disco e richiedere del tempo per l'esecuzione.

Qualcosa da provare durante la notte

Entrambe le opzioni non sono le migliori ma riformattare ogni VM per ottenere ext3 o ext4 non sembra fattibile.

Quello che potresti essere in grado di fare è impostare una regola di affinità per tutte le macchine virtuali Linux e utilizzare l'opzione 1 dall'alto.


3

Si sta utilizzando un VMDK con provisioning denso e desideroso, il che significa che non c'è nulla da recuperare quando si tenta di tagliare (tecnicamente parlando; SCSI UNMAP) i volumi.

Se l'archiviazione back-end esegue il thin provisioning, è necessario utilizzare anche file VMDK azzerati in modo pigro per ridurre l'archiviazione e consentire al back-end di memorizzare nella cache / deduplicare i dati caldi.


Grazie per aver risposto, tuttavia non sono sicuro di aver compreso completamente la tua risposta, se tutti i miei presupposti dalla domanda sono corretti, sarebbe necessario recuperare i blocchi diversi da SAN dalla SAN, specialmente se il file VMDK viene spostato da SSD a disco rotante. Corretta?
Anthony Fornito,

3
@AnthonyFornito Non è possibile recuperare nulla con dischi spessi e desiderosi. Desideroso significa che VMWare impone allo storage back-end di scrivere l'allocazione completa di ciascun file, inclusi gli zero.
pauska,

@pauska è totalmente corretto. 3PAR e molte soluzioni simili sono progettate per la compressione / deduplicazione / tiering. Il tuo modello 3PAR ibrido riguarda più l'efficienza della capacità e non la configurazione orientata alle prestazioni. Ecco perché è meglio usare i dischi azzerati pigri anziché quelli azzerati nel caso.
Strepsils,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.