탐색 링크 건너뛰기 | |
인쇄 보기 종료 | |
Oracle Solaris ZFS 관리 설명서 Oracle Solaris 10 1/13 Information Library (한국어) |
1. Oracle Solaris ZFS 파일 시스템(소개)
3. Oracle Solaris ZFS 저장소 풀 관리
4. Oracle Solaris ZFS 루트 파일 시스템 설치 및 부트
5. Oracle Solaris ZFS 파일 시스템 관리
6. Oracle Solaris ZFS 스냅샷 및 복제 작업
7. ACL 및 속성을 사용하여 Oracle Solaris ZFS 파일 보호
10. Oracle Solaris ZFS 문제 해결 및 풀 복구
잘못된 디스크 또는 컨트롤러로 인한 일시적인 I/O 오류
우주선(cosmic ray)으로 인한 디스크 내장 데이터 손상
드라이버 버그로 인해 잘못된 위치에서 또는 잘못된 위치로 데이터 전송
사용자가 실수로 물리적 장치의 일부분을 덮어쓰는 경우
경우에 따라 모든 I/O 오류와 같이 컨트롤러에 문제가 발생하는 동안에 발생하는 일시적인 오류일 수도 있고, 디스크 손상과 같은 영구적인 손상일 수도 있습니다. 그러나 영구적인 손상이라고 해서 이 오류가 반드시 다시 발생하는 것은 아닙니다. 예를 들어, 실수로 디스크의 일부를 덮어쓴 경우 어떠한 유형의 하드웨어 고장도 발생하지 않았으므로 장치를 교체할 필요가 없습니다. 장치와 관련한 정확한 문제를 식별하는 것은 쉬운 작업이 아니므로 뒤 절에서 자세히 설명합니다.
fsck에 해당하는 유틸리티가 ZFS에는 없습니다. 이 유틸리티는 일반적으로 파일 시스템 복구 및 파일 시스템 검증이라는 두 가지 목적을 제공합니다.
기존 파일 시스템에서는 데이터가 기록되는 방식이 본래 파일 시스템 불일치를 일으키는 예상치 않은 오류에 취약합니다. 기존 파일 시스템은 트랜잭션이 아니므로 참조되지 않은 블록, 잘못된 링크 카운트 또는 기타 불일치한 파일 시스템 구조가 발생할 수 있습니다. 저널링을 추가하면 이러한 문제가 해결되지만, 로그를 롤백할 수 없는 경우 추가로 문제가 발생할 수 있습니다. 하드웨어 오류(이 경우 중복된 풀을 사용해야 함)가 발생하거나 ZFS 소프트웨어에 버그가 존재하는 경우에만 불일치 데이터가 ZFS 구성의 디스크에 존재하게 됩니다.
fsck 유틸리티는 UFS 파일 시스템에만 해당하는 알려진 문제를 복구합니다. 대부분의 ZFS 저장소 풀 문제는 일반적으로 하드웨어 오류 또는 전원 오류와 관련이 있습니다. 따라서 중복된 풀을 사용하여 문제를 방지할 수 있습니다. 하드웨어 오류 또는 정전으로 인해 풀이 손상된 경우 ZFS 저장소 풀 전반의 손상 복구를 참조하십시오.
중복된 풀이 아닌 경우 파일 시스템 손상으로 인해 데이터의 일부 또는 전체에 액세스할 수 없게 될 위험이 항상 존재합니다.
fsck 유틸리티는 파일 시스템 복구를 수행하는 것 외에도, 디스크의 데이터에 문제가 없는지 검증합니다. 일반적으로 이 작업을 수행하려면 파일 시스템을 마운트 해제하고 fsck 유틸리티를 실행하며 가능하면 프로세스 중에 시스템을 단일 사용자 모드로 전환해야 합니다. 이 경우 검사할 파일 시스템의 크기에 비례하여 작동 중지 시간이 발생합니다. ZFS는 필요한 검사를 수행하기 위한 명시적 유틸리티 대신 모든 불일치에 대해 루틴 검사를 수행하는 방식을 제공합니다. 스크러빙이라고 하는 이 기능은 일반적으로 메모리 및 기타 시스템에서 하드웨어 또는 소프트웨어 오류가 발생하기 전에 오류를 발견하고 방지하는 한 방법으로 사용됩니다.
ZFS에서 오류가 발생할 때마다 스크러빙을 통해 또는 요구 시 파일에 액세스할 경우 오류가 내부적으로 기록되므로, 사용자는 풀 내에서 발생한 모든 알려진 오류를 한눈에 확인할 수 있습니다.
데이터 무결성을 검사하는 가장 간단한 방법은 풀 내에 있는 모든 데이터의 명시적 스크러빙을 시작하는 것입니다. 이 작업은 풀 내의 모든 데이터를 한 번 탐색한 다음 모든 블록을 읽을 수 있는지 확인합니다. 스크러빙은 장치에서 허용하는 한 가능한 빠르게 진행되지만, I/O 우선 순위는 일반 작업보다 낮습니다. 스크러빙이 수행되는 동안 풀 데이터는 사용하지 않은 상태로 유지되고 거의 응답하지만 이 작업은 성능에 부정적인 영향을 미칠 수 있습니다. 명시적 스크러빙을 시작하려면 zpool scrub 명령을 사용하십시오. 예를 들면 다음과 같습니다.
# zpool scrub tank
현재 스크러빙 작업의 상태는 zpool status 명령을 사용하여 표시할 수 있습니다. 예를 들면 다음과 같습니다.
# zpool status -v tank pool: tank state: ONLINE scrub: scrub completed after 0h7m with 0 errors on Tue Tue Feb 2 12:54:00 2010 config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 c1t0d0 ONLINE 0 0 0 c1t1d0 ONLINE 0 0 0 errors: No known data errors
풀당 하나의 활성 스크러빙 작업만 한 번에 수행될 수 있습니다.
-s 옵션을 사용하여 진행 중인 스크러빙 작업을 중지할 수 있습니다. 예를 들면 다음과 같습니다.
# zpool scrub -s tank
대부분의 경우 데이터 무결성을 확인하는 스크러빙 작업을 계속 수행하여 완료해야 합니다. 스크러빙 작업이 시스템 성능에 영향을 미치는 경우 재량으로 이 작업을 중지할 수 있습니다.
루틴 스크러빙을 수행하면 시스템의 모든 디스크에 대한 연속 I/O가 보장됩니다. 루틴 스크러빙은 유휴 디스크를 절전 모드로 전환하지 못하도록 하는 부작용이 있습니다. 시스템이 일반적으로 I/O를 항상 수행하는 경우 또는 전력 소비가 중요하지 않은 경우에는 이 문제를 무시해도 안전합니다.
zpool status 출력 결과 해석에 대한 자세한 내용은 ZFS 저장소 풀 상태 질의를 참조하십시오.
장치가 교체되면 리실버링 작업이 시작되어 양호한 복사본의 데이터를 새 장치로 이동합니다. 이 작업은 디스크 스크러빙의 일종입니다. 따라서 지정된 시간에 풀에서 한 번만 수행될 수 있습니다. 스크러빙 작업이 진행 중인 경우 리실버링 작업이 현재 스크러빙을 일시 중지한 다음 리실버링이 완료된 후 다시 시작합니다.
리실버링에 대한 자세한 내용은 리실버링 상태 보기를 참조하십시오.
데이터 손상은 하나 이상의 장치 오류(하나 이상의 장치 누락 또는 손상을 나타냄)가 최상위 가상 장치에 영향을 미칠 때 발상합니다. 예를 들어 미러의 반쪽에서 수천 개의 장치가 오류가 발생했지만 데이터 손상이 발생하지 않을 수 있습니다. 그러나 미러 다른 쪽의 정확히 같은 위치에서 오류가 발생할 경우에는 데이터가 손상됩니다.
데이터 손상은 항상 영구적이므로 복구 중 특별한 고려가 필요합니다. 기본 장치를 복구하거나 교체해도 원본 데이터는 영구 손실됩니다. 대부분 이 경우에는 백업에서 데이터를 복원해야 합니다. 데이터 오류는 발생할 때 기록되므로, 다음 절에 설명된 루틴 풀 스크러빙을 통해 제어할 수 있습니다. 손상된 블록이 제거되면 다음 스크러빙 단계에서 더 이상 손상된 부분이 없음을 파악하여 시스템에서 오류 추적을 제거합니다.
ZFS의 파일 시스템 및 풀 공간 계산 보고 방법이 확실하지 않은 경우 다음 절을 참조하십시오. 또한 ZFS 디스크 공간 계산도 참조하십시오.
zpool list 및 zfs list 명령은 사용 가능한 풀과 파일 시스템 공간을 확인하는 데 있어 이전 df 및 du 명령보다 낫습니다. 레거시 명령을 사용하면 풀 공간과 파일 시스템 공간을 쉽게 구별할 수 없으며, 종속 파일 시스템이나 스냅샷에서 사용하는 공간을 확인할 수도 없습니다.
예를 들어 다음 루트 풀(rpool)에는 5.46GB가 할당되었으며 68.5GB가 사용 가능합니다.
# zpool list rpool NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT rpool 74G 5.46G 68.5G 7% 1.00x ONLINE -
개별 파일 시스템의 USED 열을 검토하여 풀 공간 계산을 파일 시스템 공간 계산과 비교할 경우 ALLOC에 보고된 풀 공간이 파일 시스템의 USED 공간에 대해 고려되었음을 알 수 있습니다. 예를 들면 다음과 같습니다.
# zfs list -r rpool NAME USED AVAIL REFER MOUNTPOINT rpool 5.41G 67.4G 74.5K /rpool rpool/ROOT 3.37G 67.4G 31K legacy rpool/ROOT/solaris 3.37G 67.4G 3.07G / rpool/ROOT/solaris/var 302M 67.4G 214M /var rpool/dump 1.01G 67.5G 1000M - rpool/export 97.5K 67.4G 32K /rpool/export rpool/export/home 65.5K 67.4G 32K /rpool/export/home rpool/export/home/admin 33.5K 67.4G 33.5K /rpool/export/home/admin rpool/swap 1.03G 67.5G 1.00G -
zpool list 명령이 보고하는 SIZE 값은 일반적으로 풀의 물리적 디스크 공간의 양이지만 풀의 중복성 레벨에 따라 달라집니다. 다음 예제를 참조하십시오. zfs list 명령은 파일 시스템에서 사용 가능한 공간을 나열하는데, 이는 디스크 공간에서 ZFS 풀 중복성 메타 데이터 오버헤드(있는 경우)를 뺀 값입니다.
중복되지 않은 저장소 풀 – 풀이 한 개의 136GB 디스크로 만들어진 경우 zpool list 명령은 SIZE 및 초기 FREE 값을 136GB로 보고합니다. zfs list 명령이 보고하는 초기 AVAIL 공간은 풀 메타 데이터 오버헤드의 양이 작기 때문에 134GB입니다. 예를 들면 다음과 같습니다.
# zpool create tank c0t6d0 # zpool list tank NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT tank 136G 95.5K 136G 0% 1.00x ONLINE - # zfs list tank NAME USED AVAIL REFER MOUNTPOINT tank 72K 134G 21K /tank
미러링된 저장소 풀– 풀이 두 개의 136GB 디스크로 만들어진 경우 zpool list 명령은 SIZE를 136GB로 보고하고 초기 FREE 값을 136GB로 보고합니다. 이 보고를 압축 공간 값이라고 합니다. zfs list 명령이 보고하는 초기 AVAIL 공간은 풀 메타 데이터 오버헤드의 양이 작기 때문에 134GB입니다. 예를 들면 다음과 같습니다.
# zpool create tank mirror c0t6d0 c0t7d0 # zpool list tank NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT tank 136G 95.5K 136G 0% 1.00x ONLINE - # zfs list tank NAME USED AVAIL REFER MOUNTPOINT tank 72K 134G 21K /tank
RAID-Z 저장소 풀 – raidz2 풀이 세 개의 136GB 디스크로 만들어진 경우 zpool list 명령은 SIZE를 408GB로 보고하고 초기 FREE 값을 408GB로 보고합니다. 이 보고를 압축 공간 값이라고 하는데, 여기에는 중복성 오버헤드(예: 패리티 정보)가 포함됩니다. zfs list 명령이 보고하는 초기 AVAIL 공간은 풀 중복성 오버헤드로 인해 133GB입니다. RAID-Z 풀에 대한 zpool list와 zfs list 출력 결과 사이의 공간 차이는 zpool list가 압축 풀 공간을 보고하기 때문입니다.
# zpool create tank raidz2 c0t6d0 c0t7d0 c0t8d0 # zpool list tank NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT tank 408G 286K 408G 0% 1.00x ONLINE - # zfs list tank NAME USED AVAIL REFER MOUNTPOINT tank 73.2K 133G 20.9K /tank
다음 절에서는 데이터 손상 유형을 식별하고 데이터를 복구하는 방법에 대해 설명합니다.
ZFS는 체크섬, 중복성 및 자체 치료 데이터를 사용하여 데이터 손상 위험을 최소화합니다. 그럼에도 불구하고, 풀이 중복되지 않은 경우, 풀 디그레이드 중에 손상이 발생한 경우 또는 일련의 이벤트가 동시에 발생하여 여러 데이터 복사본이 손상되는 경우 데이터 손상이 발생할 수 있습니다. 소스와 관계없이 결과는 같습니다. 즉, 데이터가 손상되어 더 이상 액세스할 수 없습니다. 수행할 조치는 손상된 데이터의 유형 및 관련 값에 따라 달라집니다. 두 가지 기본 유형의 데이터가 손상될 수 있습니다.
풀 메타 데이터 - 풀을 열고 데이터 세트에 액세스하기 위해서는 구문 분석할 특정한 양의 데이터가 ZFS에 필요합니다. 이 데이터가 손상될 경우 전체 풀 또는 데이터 세트 계층의 일부분을 사용할 수 없게 됩니다.
객체 데이터 – 이 경우 특정 파일 또는 디렉토리 내에서 손상이 발생합니다. 이 문제로 인해 파일 또는 디렉토리의 일부분에 액세스할 수 없게 되거나 객체가 모두 손상됩니다.
일반 작업 중이나 스크러빙을 통해 데이터를 확인할 수 있습니다. 풀 데이터의 무결성을 확인하는 방법에 대한 자세한 내용은 ZFS 파일 시스템 무결성 검사를 참조하십시오.
기본적으로 zpool status 명령은 손상이 발생했다는 것만 표시하고 이 손상이 발생한 위치는 표시하지 않습니다. 예를 들면 다음과 같습니다.:
# zpool status monkey pool: monkey state: ONLINE status: One or more devices has experienced an error resulting in data corruption. Applications may be affected. action: Restore the file in question if possible. Otherwise restore the entire pool from backup. see: http://www.sun.com/msg/ZFS-8000-8A scrub: scrub completed after 0h0m with 8 errors on Tue Jul 13 13:17:32 2010 config: NAME STATE READ WRITE CKSUM monkey ONLINE 8 0 0 c1t1d0 ONLINE 2 0 0 c2t5d0 ONLINE 6 0 0 errors: 8 data errors, use '-v' for a list
각 오류는 지정된 시점에서 오류가 발생했다는 사실만 표시할 뿐 반드시 시스템에 아직도 이러한 오류가 있다는 것은 아닙니다. 그러나 이는 정상적인 상황에서 적용되는 내용입니다. 일시적인 특정 작동 중단은 데이터 손상을 일으키지만 이러한 손상은 작동 중단이 종료되면 자동으로 복구됩니다. 풀의 모든 활성 블록을 검사하기 위해 전체 풀 스크러빙이 보장됩니다. 따라서 스크러빙이 완료될 때마다 오류 로그가 재설정됩니다. 더 이상 오류가 존재하지 않는 것으로 확인되어 스크러빙이 완료될 때까지 기다리지 않아도 되는 경우 zpool online 명령을 사용하여 풀의 모든 오류를 재설정하십시오.
데이터 손상이 풀 전체 메타 데이터에서 발생한 경우 출력 결과가 약간 다릅니다. 예를 들면 다음과 같습니다.
# zpool status -v morpheus pool: morpheus id: 1422736890544688191 state: FAULTED status: The pool metadata is corrupted. action: The pool cannot be imported due to damaged devices or data. see: http://www.sun.com/msg/ZFS-8000-72 config: morpheus FAULTED corrupted data c1t10d0 ONLINE
풀 전체 손상의 경우 풀이 원하는 중복성 레벨을 제공할 수 없기 때문에 풀이 FAULTED 상태가 됩니다.
파일 또는 디렉토리가 손상된 경우 손상 유형에 따라 시스템이 계속 작동할 수 있습니다. 시스템에 정상적인 데이터 복사본이 없을 경우 결과적으로 손상을 복구할 수 없습니다. 중요한 데이터일 경우 영향을 받는 데이터를 백업에서 복원해야 합니다. 이 경우에도 전체 풀을 복원하지 않고 이 손상에서 복구할 수 있습니다.
파일 데이터 블록에서 손상이 발생한 경우 파일을 안전하게 제거하면 시스템에서 오류가 지워집니다. 영구적인 오류가 발생한 파일 이름 목록을 표시하려면 zpool status -v 명령을 사용하십시오. 예를 들면 다음과 같습니다.
# zpool status -v pool: monkey state: ONLINE status: One or more devices has experienced an error resulting in data corruption. Applications may be affected. action: Restore the file in question if possible. Otherwise restore the entire pool from backup. see: http://www.sun.com/msg/ZFS-8000-8A scrub: scrub completed after 0h0m with 8 errors on Tue Jul 13 13:17:32 2010 config: NAME STATE READ WRITE CKSUM monkey ONLINE 8 0 0 c1t1d0 ONLINE 2 0 0 c2t5d0 ONLINE 6 0 0 errors: Permanent errors have been detected in the following files: /monkey/a.txt /monkey/bananas/b.txt /monkey/sub/dir/d.txt monkey/ghost/e.txt /monkey/ghost/boo/f.txt
영구적인 오류가 발생한 파일 이름 목록은 다음과 같이 설명될 수 있습니다.
전체 파일 경로가 발견되고 데이터 세트가 마운트된 경우, 전체 파일 경로가 표시됩니다. 예를 들면 다음과 같습니다.
/monkey/a.txt
전체 파일 경로가 발견되었지만 데이터 세트가 마운트되지 않은 경우, 앞에 슬래시(/)가 붙지 않고 데이터 세트 내의 파일에 대한 경로가 이어지는 데이터 세트 이름이 표시됩니다. 예를 들면 다음과 같습니다.
monkey/ghost/e.txt
dnode_t의 경우와 같이, 오류로 인해 또는 객체에 연관된 실제 파일 경로가 없어 파일 경로에 대한 객체 수를 성공적으로 변환할 수 없는 경우 데이터 세트 이름 뒤에 객체 번호가 표시됩니다. 예를 들면 다음과 같습니다.
monkey/dnode:<0x0>
MOS(Metaobject Set)에 있는 객체가 손상된 경우 특수 태그 <metadata> 뒤에 객체 번호가 표시됩니다.
손상이 디렉토리 또는 파일의 메타 데이터 내에서 발생한 경우 파일을 다른 곳으로 이동할 수만 있습니다. 파일이나 디렉토리를 덜 편리한 위치로 안전하게 이동하면 원본 객체를 해당 위치에서 복원할 수 있습니다.
손상된 파일 시스템에 스냅샷과 같이 여러 블록 참조가 있는 손상된 데이터가 있는 경우 zpool status -v 명령은 모든 손상된 데이터 경로를 표시하지 않습니다. 손상된 데이터에 대한 현재 zpool status 보고는 메타 데이터 손상 정도에 따라 제한되며 zpool status 명령 실행 후 블록이 재사용된 경우로 제한됩니다. 중복 제거된 블록은 모든 손상된 데이터를 더욱 복잡하게 만듭니다.
손상된 데이터가 있고 zpool status -v 명령으로 스냅샷 데이터가 영향을 받은 것으로 확인된 경우 다음 명령을 실행하여 추가 손상된 경로가 있는지 식별하는 것이 좋습니다.
풀 메타 데이터에서 손상이 발생했는데 이 손상으로 인해 풀을 열거나 가져올 수 없는 경우 다음 옵션을 사용할 수 있습니다.
zpool clear -F 명령 또는 zpool import - F 명령을 사용하여 풀을 복구할 수 있습니다. 이 명령은 마지막 몇 개의 풀 트랜잭션을 작동 상태로 롤백하려고 시도합니다. zpool status 명령을 사용하여 손상된 풀 및 권장되는 복구 단계를 검토할 수 있습니다. 예를 들면 다음과 같습니다.
# zpool status pool: tpool state: FAULTED status: The pool metadata is corrupted and the pool cannot be opened. action: Recovery is possible, but will result in some data loss. Returning the pool to its state as of Wed Jul 14 11:44:10 2010 should correct the problem. Approximately 5 seconds of data must be discarded, irreversibly. Recovery can be attempted by executing 'zpool clear -F tpool'. A scrub of the pool is strongly recommended after recovery. see: http://www.sun.com/msg/ZFS-8000-72 scrub: none requested config: NAME STATE READ WRITE CKSUM tpool FAULTED 0 0 1 corrupted data c1t1d0 ONLINE 0 0 2 c1t3d0 ONLINE 0 0 4
위 출력 결과에 설명된 복구 프로세스는 다음 명령에 사용하기 위한 것입니다.
# zpool clear -F tpool
손상된 저장소 풀을 가져오려고 시도하면 다음과 비슷한 메시지가 표시됩니다.
# zpool import tpool cannot import 'tpool': I/O error Recovery is possible, but will result in some data loss. Returning the pool to its state as of Wed Jul 14 11:44:10 2010 should correct the problem. Approximately 5 seconds of data must be discarded, irreversibly. Recovery can be attempted by executing 'zpool import -F tpool'. A scrub of the pool is strongly recommended after recovery.
위 출력 결과에 설명된 복구 프로세스는 다음 명령에 사용하기 위한 것입니다.
# zpool import -F tpool Pool tpool returned to its state as of Wed Jul 14 11:44:10 2010. Discarded approximately 5 seconds of transactions
손상된 풀이 zpool.cache 파일에 있는 경우, 시스템을 부트하면 문제가 발견되고 손상된 풀이 zpool status 명령에 보고됩니다. 이 풀이 zpool.cache 파일에 없는 경우 풀을 가져오거나 열 수 없으므로 해당 풀을 가져오려고 시도하면 손상된 풀 메시지가 표시됩니다.
손상된 풀은 읽기 전용 모드로 가져올 수 있습니다. 이 방법으로 풀을 가져와서 데이터에 액세스할 수 있습니다. 예를 들면 다음과 같습니다.
# zpool import -o readonly=on tpool
풀을 읽기 전용으로 가져오는 방법은 읽기 전용 모드로 풀 가져오기를 참조하십시오.
zpool import -m 명령을 사용하여 누락된 로그 장치가 있는 풀을 가져올 수 있습니다. 자세한 내용은 누락된 로그 장치가 있는 풀 가져오기를 참조하십시오.
어떠한 풀 복구 방법으로도 풀을 복구할 수 없는 경우 백업 복사본에서 풀과 모든 데이터를 복원해야 합니다. 풀 구성 및 백업 전략에 따라 사용하는 방식이 달라집니다. 먼저, 풀이 삭제된 후 구성을 다시 만들 수 있도록 zpool status 명령에 의해 표시된 대로 구성을 저장합니다. 그런 다음 zpool destroy -f 명령을 사용하여 풀을 삭제합니다.
또한 풀에 액세스할 수 없게 될 경우 데이터 세트의 레이아웃 및 로컬에 설정된 다양한 등록 정보에도 액세스할 수 없게 되므로 이 정보를 안전한 위치에 보관하십시오. 풀 구성 및 데이터 세트 레이아웃을 사용하면 풀 삭제 후 전체 구성을 재구성할 수 있습니다. 그런 다음 백업 또는 복원 전략을 사용하여 데이터를 채울 수 있습니다.