폐기 HP 3PAR StoreServ 7400

13

이전에 질문 한 내용에서 분리

우리는 38 개의 호스트에 170 개의 VM을 분산시킨 HP 3PAR StoreServ 7400을 보유하고 있습니다.

내가 이해하는 문제는 다음과 같습니다. (또한 사실인지 확실하지 않은 정보를 들었습니다. HP 3PAR StoreServ 7400 백서를 읽었으며 실제로 내 스토리지 담당자가 무엇인지를 뒷받침하는 것을 찾을 수 없습니다 누군가가 사실이 아닌 것을 알게되면 아래에 알려주십시오.)

3 개의 PAR은 3 개의 섹션으로 나뉩니다.

계층 1 : SSD는 일반적으로 액세스되는 파일을 캐시하고 빠르게 액세스하는 데 사용됩니다.

레이어 2 : 및 레이어 3 : 어떤 종류의 스피닝 디스크, 왜 그리고 왜 추가 2 개의 레이어가 있는지 확실하지 않지만 레이어 2는 가장 일반적으로 액세스되지 않지만 비트에 액세스하고 레이어 3은 데이터에 사용됩니다 나머지 저장.

데이터가 SSD 블록에 쓰여지고 삭제 된 때 많은 기사에서 읽은 SSD 부분 내에서 새 데이터가 쓰여질 때까지 해당 블록은 0이 아니므로 블록 내의 데이터가 삭제되면 매핑을 저장하는 테이블 정보가 업데이트되면 새 데이터가 동일한 블록에 기록 될 때 먼저 블록을 제로화 한 다음 기록 할 수 있습니다. 드라이브가 주기적으로 트림되지 않은 경우 SSD 내에서이 프로세스는 w / r 속도를 낮출 수 있습니다.

3PAR LUN은 씬 프로비저닝되고 VM은 Eager Thick 프로비저닝됩니다.

필자의 스토리지 담당자에 따르면 3PAR에는 SSD 스토리지를 다른 VM에서 필요에 따라 사용할 수없는 SSD 스토리지를 사용할 수있는 특수 기능이 내장되어 있습니다.

사실 확인 :

씩 프로비저닝 된 VM은 VMDK 파일이며, VM을 만들 때 VM의 크기를 지정하면 VMDK 파일이 생성됩니다. 내 생각에 VM이 정기적으로 액세스되면 전체 VMDK 파일이 SDD로 이동하고 VMDK가 40GB를 사용하도록 설정된 경우에도 40GB 중 일부를 사용할 수 있음을 알려줍니다 다른 VM? 씬 프로비저닝 된 VM처럼 두껍지 않은 것 같습니다.

문제가 생겼습니다.

Windows 시스템에서는 sdelete를 사용하여 사용하지 않는 블록을 찾아서 제로화합니다.

Linux Fedora 시스템에서 나는 fstrim을 작동시키는 방법을 알아 내려고 노력해 왔습니다.

나는 dd = write-big-file delete-big-file 명령을 시도했고 지붕을 통해 디스크 I / O를 보냈으며, 그 사실을 다시 알지 말라고 지시했다.

약간의 연구를 수행하면 sdelete가 dd = write-big-file delete-big-file과 거의 같은 역할을하므로 디스크 I / O가 Windows 시스템의 지붕을 통과하지 않는 이유는 무엇입니까?

그래서 나는 그것을 두 가지 해결책으로 옮겼다 고 생각합니다. 어느 쪽도 내가하는 법을 모른다.

VM을 다른 스토리지 배열로 v- 모션하지 않고도 SAN의 전체 SSD 부분에서 fstrim과 같은 기능을 실행할 수 있습니다.

참고 사항 : 내가 읽은 모든 것을 이해하면 fstrim이 모든 블록을보고 데이터가 있고 필요한지 확인합니다. 필요하지 않은 경우 sdelete가 거대한 파일을 작성한 다음 삭제하는 블록을 0으로 만듭니다. 그렇기 때문에 3PAR의 전체 SSD 부분에서 fstrim 옵션을 찾고 있습니다.

Longshot이지만 fstrim으로 인한 오류는 다음과 같습니다.

[root @ rhtest ~] # fstrim -v / fstrim : / : 삭제 작업이 지원되지 않습니다

폐기 옵션을 OS와 데이터 저장소 모두에 설정해야하지만 3PAR에서 폐기 옵션을 설정하는 위치 또는 방법을 알 수 없습니다 .3PAR에 대한 SSH 및 GUI 액세스가 있습니다.

나는 OS 내에서 버리기를 설정하는 데 많은 수의 연습을 해 왔으며 얼마나 많은 다른 방법으로 회전하든 상관없이 항상 같은 오류가 발생합니다.

예, 나는 또한 zerofree가 다른 옵션을 보았지만 염두에 두지 않는 몇 가지 다른 사람들도 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

— 앤서니 포르 니토
소스

10

/ 파티션에서 fstrim을 실행할 수있는 것이 가장 좋은 해결책이지만 ESXi가 구성된 방식으로는 불가능합니다.

VM과 스토리지 장치 모두에서 삭제를 활성화 할 수 있어야합니다.

xfs 파일 시스템으로 파티션 또는 논리 볼륨의 크기를 줄이려고 시도 할 수 없습니다. 이는 페도라의 알려진 버그입니다. 이 기능에 관심이 있다면 Red Hat 지원에 문의하여 Red Hat bugzilla 1062667을 참조하고 XFS 축소 / 축소가 필요한 사용 사례를 제공하십시오.

일부 환경에서 가능한 해결 방법으로 씬 프로비저닝 된 LVM 볼륨을 XFS 파일 시스템 아래의 추가 계층으로 간주 할 수 있습니다.

VM이 씩 프로비저닝 된 VMDK를 열망하는 경우, 볼륨을 정리 (기술적으로 말하기 : SCSI UNMAP) 할 때 교정 할 사항이 없습니다.

백엔드 스토리지가 씬 프로비저닝을 실행하는 경우 스토리지를 줄이고 백엔드가 웜 데이터를 캐시 / 중첩 할 수 있도록 지연 제로화 된 VMDK 파일을 사용해야합니다.

두 가지 가능한 옵션 :

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에 스파이크가 발생하고 실행하는 데 시간이 걸릴 수 있습니다.

하룻밤 사이에 시도해야 할 것

옵션 중 하나가 가장 좋지는 않지만 모든 VM을 다시 포맷하여 ext3 또는 ext4를 가져 오는 것이 실현 가능하지는 않습니다.

당신이 할 수있는 일은 모든 Linux VM에 대한 선호도 규칙을 설정하고 위의 옵션 1을 사용하는 것입니다.

— 브라이언 컬리스
소스

3

씩 프로비저닝 된 VMDK를 사용하고 있습니다. 즉, 볼륨을 정리 (기술적으로 말하기 : SCSI UNMAP) 할 때 교정 할 사항이 없습니다.

백엔드 스토리지가 씬 프로비저닝을 실행하는 경우 스토리지를 줄이고 백엔드가 웜 데이터를 캐시 / 중첩 할 수 있도록 지연 제로화 된 VMDK 파일 을 사용해야 합니다.

— 파우 스카
소스

답변 해 주셔서 감사합니다.하지만 답을 완전히 이해하지 못합니다. 질문에서 내 모든 가정이 정확하면 특히 VMDK 파일이 SSD에서 회전 디스크.? 옳은?

— Anthony Fornito

3

@AnthonyFornito 두꺼운 디스크를 사용하여 아무 것도 회수 할 수 없습니다. 두꺼운 것은 VMWare가 백엔드 스토리지가 0을 포함하여 각 파일의 전체 할당을 쓰도록 강제 함을 의미합니다.

— pauska

@pauska는 완전히 정확합니다. 3PAR 및 많은 유사한 솔루션은 압축 / 중복 제거 / 계층화를 위해 설계되었습니다. 하이브리드 3PAR 모델은 용량 효율성에 관한 것이지 실제로 성능 지향 구성이 아닙니다. 그렇기 때문에 귀하의 경우 열망하는 제로 디스크 대신 게으른 제로 디스크를 사용하는 것이 좋습니다.

— Strepsils