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.
- 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.
- 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