Ativar Descarte HP 3PAR StoreServ 7400

13

Desvie dessas perguntas anteriormente feitas

Como obter espaço livre da unidade montada Redhat 7

Atualizar o crypttab pede passphrase para o fstrim

Temos um HP 3PAR StoreServ 7400 com 170 VMs espalhadas por 38 hosts.

Aqui está o problema que eu entendo: (Também me disseram algumas informações que eu não tenho certeza se é verdade ou não, eu li sobre o whitepaper HP 3PAR StoreServ 7400 e realmente não consigo encontrar nada que faça o backup do meu cara armazenamento está me dizendo.Em todo o abaixo, se alguém percebe alguma coisa não é verdade por favor me avise.)

O 3 PAR está dividido em 3 seções,

Camada 1: SSD usado para armazenar em cache e acessar rapidamente arquivos acessados com frequência.

Camada 2: e Camada 3: Algum tipo de disco giratório, o que e por que há duas camadas adicionais inseguras, mas minha suposição é que a Camada 2 é usada para dados que não são acessados com mais frequência, mas acessam um pouco e a Camada 3 é usado para armazenamento do resto.

Dentro da parte do SSD como li em muitos artigos quando os dados são gravados em um bloco SSD e, em seguida, excluído, esse bloco não é zerado até que novos dados sejam gravados. Assim, quando os dados dentro do bloco são excluídos, armazena as informações de mapeamento é atualizado, em seguida, quando novos dados são gravados no mesmo bloco, o bloco primeiro precisa ser zerado e, em seguida, pode ser gravado para. Este processo dentro do SSD, se a periodicidade do inversor não for ajustada, pode levar a menores velocidades p / r.

O 3PAR LUN é thin provisioned e as VMs são fornecidas por Eager Thick.

De acordo com meu responsável pelo armazenamento, o 3PAR possui um recurso especial que permite que o armazenamento SSD não esteja disponível para outras VMs conforme necessário, o que não faz sentido.

Verificação de fatos:

Uma VM provisionada espessa é um arquivo VMDK. Quando a VM é criada, você especifica o tamanho da VM e isso cria um arquivo VMDK. Em minha mente, isso me diz que se a VM está sendo acessada regularmente, todo o arquivo VMDK é movido para o SDD, e o que eles estão me dizendo é que mesmo que o VMDK esteja configurado para usar 40GB, alguns desses 40GB podem ser usados outras VM's? Isso soa mais para mim como uma VM thin provisioned não muito espessa.

Ok, resolvendo o problema.

Em nossos sistemas Windows, usamos sdelete para encontrar e zerar blocos não utilizados.

No nosso sistema Linux Fedora eu tenho tentado descobrir como fazer o fstrim funcionar.

Eu tentei o comando dd = write-big-file delete-big-file e enviei a E / S do disco pelo telhado, o que foi notado, e me disseram para não fazer isso novamente.

Fazendo uma pequena pesquisa, parece-me que sdelete praticamente faz o mesmo que dd = write-big-file delete-big-file, então por que a E / S de disco não passa pelo telhado dos sistemas Windows? / p>

Então eu acho que reduzi a duas soluções. Nenhum dos quais eu sei fazer.

  1. De alguma forma, sem acionar as VMs para um array de armazenamento diferente, é possível executar uma função semelhante a toda a parte de SSD da SAN.

Nota: Se eu entendi tudo o que li, o fstrim olha para cada bloco para ver se os dados estão lá e se necessário, se não for necessário zerará o bloco, enquanto o sdelete grava um arquivo enorme e o apaga . É por isso que estou procurando uma opção fstrim em toda a parte SSD do 3PAR.

  1. Longshot, mas o erro que recebo com o fstrim é:

[root @ rhtest ~] # fstrim -v / fstrim: /: a operação de descarte não é suportada

Eu li que a opção de descarte precisa ser definida no sistema operacional e no armazenamento de dados, mas não consigo descobrir onde ou como definir uma opção de descarte no 3PAR Eu tenho acesso SSH e GUI ao 3PAR.

Já passei por incontáveis orientações sobre a configuração de descartes no sistema operacional e não importa quantas maneiras diferentes eu o gire. Sempre recebo o mesmo erro.

Sim, eu também olhei em outras opções zerofree foi um, e alguns outros que não me vêm à mente no entanto eles trabalharam como zdelete, ou eu li que eles eram muito perigosos, eu olhei para o hdparam etc.

Abaixo, vou colocar alguns resultados sobre o sistema operacional em questão, eles são todos iguais.

[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
    
por Anthony Fornito 31.10.2016 / 18:34

2 respostas

10

Ser capaz de executar o fstrim nas / partitions seria a melhor solução, mas com a maneira como o ESXi é configurado, não seria possível.

Você precisa ativar as devoluções na VM e no dispositivo de armazenamento.

Tentando reduzir o tamanho de uma partição ou volume lógico com o sistema de arquivos xfs não pode ser feito, este é um bug conhecido com o fedora. Se você estiver interessado nesta funcionalidade, entre em contato com o suporte da Red Hat e consulte o bugzilla 1062667 da Red Hat, e forneça seu caso de uso para a necessidade de redução / redução de XFS.

Como possível trabalho em alguns ambientes, os volumes LVM com aprovisionamento dinâmico podem ser considerados como uma camada adicional abaixo do sistema de arquivos XFS.

Se as VMs estão ansiosas VMDK provisionadas, o que significa que não há nada a recuperar quando você está tentando cortar (tecnicamente falando; SCSI UNMAP) seus volumes.

Se o armazenamento de back-end estiver executando o provisionamento thin, você também precisará usar arquivos VMDK com zeros lazy para reduzir o armazenamento e tornar possível que o back-end armazene os dados mais quentes.

Duas opções possíveis:

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

Pelo que sei, isso faz o mesmo que sdelete, mas pode causar um pico na E / S do disco, além de demorar um pouco para ser executado.

Algo para tentar durante a noite

Qualquer uma das opções não é a melhor, mas reformatar todas as VMs para obter ext3 ou ext4 não parece viável.

O que você pode fazer é configurar uma regra de afinidade para todas as VMs do Linux e usar a opção 1 acima.

    
por 08.11.2016 / 21:00
3

Você está usando o VMDK provisionado, o que significa que não há nada para recuperar quando você está tentando cortar (tecnicamente falando; SCSI UNMAP) seus volumes.

Se o armazenamento de back-end estiver executando o provisionamento thin, você também precisará usar arquivos VMDK lazy zerados para reduzir o armazenamento e tornar possível que o back-end armazene dados .

    
por 31.10.2016 / 19:14