Red Hat Enterprise Linux 9는 다양한 파일 시스템(FS)을 지원합니다. 다양한 유형의 파일 시스템을 통해 다양한 종류의 문제를 해결하고 용도는 애플리케이션에 따라 다릅니다. 가장 일반적인 수준에서 사용 가능한 파일 시스템을 다음과 같은 주요 유형으로 그룹화할 수 있습니다.

로컬 파일 시스템은 단일 로컬 서버에서 실행되며 스토리지에 직접 연결된 파일 시스템입니다.

예를 들어 로컬 파일 시스템은 내부 SATA 또는 SAS 디스크에 대해 유일한 선택이며 서버에 로컬 드라이브가 있는 하드웨어 RAID 컨트롤러가 있는 경우 사용됩니다. SAN에서 내보낸 장치가 공유되지 않은 경우 로컬 파일 시스템도 SAN 연결 스토리지에서 사용되는 가장 일반적인 파일 시스템입니다.

모든 로컬 파일 시스템은 POSIX와 호환되며 지원되는 모든 Red Hat Enterprise Linux 릴리스와 완벽하게 호환됩니다. POSIX 호환 파일 시스템은 read(), write() 및 search()와 같이 잘 정의된 시스템 호출 세트를 지원합니다.

애플리케이션 프로그래밍 프로그램의 관점에서 볼 때 로컬 파일 시스템간에 상대적으로 약간의 차이점이 있습니다. 사용자 관점과 가장 주목할 만한 차이점은 확장성 및 성능과 관련이 있습니다. 파일 시스템 선택을 고려할 때 파일 시스템의 크기, 보유 가능한 고유한 기능 및 워크로드에서 수행하는 방법을 고려하십시오.

XFS는 단일 호스트에서 매우 큰 파일 및 파일 시스템을 지원하는 확장성이 뛰어난 고성능, 견고하며 성숙한 64비트 저널링 파일 시스템입니다. Red Hat Enterprise Linux 9의 기본 파일 시스템입니다. XFS는 원래 SGI에 의해 Subversions에서 개발되었으며 매우 큰 서버 및 스토리지 어레이에서 실행하는 오랜 기록을 보유하고 있습니다.

XFS의 기능은 다음과 같습니다.

XFS는 단일 스레드에 대해 상대적으로 낮은 성능을 제공합니다. 예를 들어 단일 스레드에서 많은 수의 작은 파일을 생성하거나 삭제하는 워크로드와 같습니다.

ext4 파일 시스템은 ext 파일 시스템 제품군의 네 번째 세대입니다. Red Hat Enterprise Linux 6의 기본 파일 시스템입니다.

ext4 드라이버는 ext2 및 ext3 파일 시스템을 읽고 쓸 수 있지만 ext4 파일 시스템 형식은 ext2 및 ext3 드라이버와 호환되지 않습니다.

ext4는 다음과 같은 몇 가지 새로운 기능과 향상된 기능을 추가합니다.

범위 기반 메타데이터 및 지연된 할당 기능은 파일 시스템에서 사용된 공간을 추적하는 더 작고 효율적인 방법을 제공합니다. 이러한 기능을 통해 파일 시스템 성능을 개선하고 메타데이터로 소비되는 공간을 줄일 수 있습니다. 지연 할당을 사용하면 데이터가 디스크로 플러시될 때까지 새로 기록된 사용자 데이터에 대한 영구 위치를 파일 시스템을 연기할 수 있습니다. 이를 통해 더 크고 연속된 할당을 허용할 수 있으므로 파일 시스템이 훨씬 더 나은 정보로 결정을 내릴 수 있으므로 성능이 향상됩니다.

ext4에서 fsck 유틸리티를 사용하는 파일 시스템 복구 시간은 ext2 및 ext3보다 훨씬 빠릅니다. 일부 파일 시스템 복구는 성능이 6배 증가했습니다.

XFS는 RHEL의 기본 파일 시스템입니다. 이 섹션에서는 XFS 및 ext4의 사용과 기능을 비교합니다.

애플리케이션 요구 사항을 충족하는 파일 시스템을 선택하려면 파일 시스템을 배포할 대상 시스템을 이해해야 합니다. 다음 질문을 사용하여 결정을 알릴 수 있습니다.

서버와 스토리지 장치가 모두 큰 경우 XFS를 선택하는 것이 좋습니다. 크기가 작은 스토리지 어레이의 경우에도 XFS는 평균 파일 크기가 클 때 매우 잘 작동합니다(예: 크기가 수백 메가바이트).

기존 워크로드가 ext4와 함께 잘 수행된 경우 ext4를 계속 사용하면 애플리케이션에 매우 친숙한 환경을 제공해야 합니다.

ext4 파일 시스템은 I/O 기능이 제한된 시스템에서 더 잘 작동하는 경향이 있습니다. 제한된 대역폭 (200MB/s 미만)과 최대 1000 IOPS 기능에서 더 잘 작동합니다. 높은 기능을 가진 모든 것에 대해 XFS는 더 빠른 경향이 있습니다.

XFS는 ext4와 비교하여 CPU당 두 배 작업을 사용하므로 CPU 바인딩 워크로드를 약간의 동시성이 있는 경우 ext4가 더 빠릅니다. 일반적으로 애플리케이션이 단일 읽기/쓰기 스레드와 작은 파일을 사용하는 경우 ext4가 더 나은 반면, 애플리케이션이 여러 읽기/쓰기 스레드와 더 큰 파일을 사용하는 경우 XFS는 축소됩니다.

XFS 파일 시스템을 축소할 수 없습니다. 파일 시스템을 축소할 수 있어야 하는 경우 오프라인 축소를 지원하는 ext4를 사용하는 것이 좋습니다.

일반적으로 Red Hat은 ext4의 특정 사용 사례가 없는 한 XFS를 사용하도록 권장합니다. 또한 적절한 유형의 파일 시스템을 선택하도록 대상 서버 및 스토리지 시스템에서 특정 애플리케이션의 성능을 측정해야 합니다.

네트워크 파일 시스템(클라이언트/서버 파일 시스템이라고도 함)을 사용하면 클라이언트 시스템이 공유 서버에 저장된 파일에 액세스할 수 있습니다. 따라서 여러 시스템의 여러 사용자가 파일 및 스토리지 리소스를 공유할 수 있습니다.

이러한 파일 시스템은 파일 시스템 집합을 하나 이상의 클라이언트로 내보내는 하나 이상의 서버에서 빌드됩니다. 클라이언트 노드는 기본 블록 스토리지에 액세스할 수 없지만 더 나은 액세스 제어를 허용하는 프로토콜을 사용하여 스토리지와 상호 작용합니다.

클러스터 파일 시스템(클러스터 파일 시스템)이라고도 하는 공유 스토리지 파일 시스템은 클러스터의 각 서버에 로컬 SAN(Storage Area Network)을 통해 공유 블록 장치에 대한 직접 액세스 권한을 제공합니다.

네트워크 및 공유 스토리지 파일 시스템 중에서 선택할 때 다음 사항을 고려하십시오.

공유 스토리지 파일 시스템에 대한 구체적인 사용 사례가 없는 한 네트워크 파일 시스템을 사용하는 것이 좋습니다. 공유 스토리지 파일 시스템은 주로 다운타임을 최소화하고 엄격한 서비스 수준 요구 사항을 갖춘 고가용성 서비스를 제공해야 하는 배포에 사용됩니다.

볼륨 관리 파일 시스템은 단순성 및 스택 내 최적화를 위해 전체 스토리지 스택을 통합합니다.

스토리지 역할은 다음을 관리할 수 있습니다.

스토리지 역할을 사용하면 다음 작업을 수행할 수 있습니다.

스토리지 역할 구성은 다음 변수에 나열된 파일 시스템, 볼륨 및 풀에만 영향을 미칩니다.

이 섹션에서는 예제 Ansible 플레이북을 제공합니다. 이 플레이북은 기본 매개 변수를 사용하여 블록 장치에 XFS 파일 시스템을 생성하도록 storage 역할을 적용합니다.

---
- hosts: all
  vars:
    storage_volumes:
      - name: barefs
        type: disk
        disks:
          - sdb
        fs_type: xfs
  roles:
    - rhel-system-roles.storage

이 섹션에서는 예제 Ansible 플레이북을 제공합니다. 이 플레이북은 storage 역할을 적용하여 XFS 파일 시스템을 즉시 지속적으로 마운트합니다.

---
- hosts: all
  vars:
    storage_volumes:
      - name: barefs
        type: disk
        disks:
          - sdb
        fs_type: xfs
        mount_point: /mnt/data
  roles:
    - rhel-system-roles.storage

이 섹션에서는 예제 Ansible 플레이북을 제공합니다. 이 플레이북은 스토리지 역할을 적용하여 볼륨 그룹에 LVM 논리 볼륨을 생성합니다.

- hosts: all
  vars:
    storage_pools:
      - name: myvg
        disks:
          - sda
          - sdb
          - sdc
        volumes:
          - name: mylv
            size: 2G
            fs_type: ext4
            mount_point: /mnt/data
  roles:
    - rhel-system-roles.storage

이 섹션에서는 예제 Ansible 플레이북을 제공합니다. 이 Playbook은 온라인 블록 삭제가 활성화된 XFS 파일 시스템을 마운트하는 스토리지 역할을 적용합니다.

---
- hosts: all
  vars:
    storage_volumes:
      - name: barefs
        type: disk
        disks:
          - sdb
        fs_type: xfs
        mount_point: /mnt/data
        mount_options: discard
  roles:
    - rhel-system-roles.storage

이 섹션에서는 예제 Ansible 플레이북을 제공합니다. 이 플레이북은 storage 역할을 적용하여 Ext4 파일 시스템을 생성하고 마운트합니다.

---
- hosts: all
  vars:
    storage_volumes:
      - name: barefs
        type: disk
        disks:
          - sdb
        fs_type: ext4
        fs_label: label-name
        mount_point: /mnt/data
  roles:
    - rhel-system-roles.storage

이 섹션에서는 예제 Ansible 플레이북을 제공합니다. 이 플레이북은 storage 역할을 적용하여 Ext3 파일 시스템을 생성하고 마운트합니다.

---
- hosts: all
  vars:
    storage_volumes:
      - name: barefs
        type: disk
        disks:
          - sdb
        fs_type: ext3
        fs_label: label-name
        mount_point: /mnt/data
  roles:
    - rhel-system-roles.storage

이 섹션에서는 예제 Ansible 플레이북을 제공합니다. 이 Playbook은 스토리지 역할을 적용하여 블록 장치의 기존 Ext4 또는 Ext3 파일 시스템의 크기를 조정합니다.

---
- name: Create a disk device mounted on /opt/barefs
- hosts: all
  vars:
    storage_volumes:
      - name: barefs
        type: disk
        disks:
          - /dev/sdb
        size: 12 GiB
        fs_type: ext4
        mount_point: /opt/barefs
  roles:
    - rhel-system-roles.storage

---
- name: Create a disk device mounted on /opt/barefs
- hosts: all
  vars:
    storage_volumes:
      - name: barefs
        type: disk
        disks:
          - /dev/sdb
        size: 10 GiB
        fs_type: ext4
        mount_point: /opt/barefs
  roles:
    - rhel-system-roles.storage

이 섹션에서는 예제 Ansible 플레이북을 제공합니다. 이 플레이북은 스토리지 RHEL 시스템 역할을 적용하여 파일 시스템으로 LVM 논리 볼륨의 크기를 조정합니다.

---

- hosts: all
   vars:
    storage_pools:
      - name: myvg
        disks:
          - /dev/sda
          - /dev/sdb
          - /dev/sdc
        volumes:
            - name: mylv1
              size: 10 GiB
              fs_type: ext4
              mount_point: /opt/mount1
            - name: mylv2
              size: 50 GiB
              fs_type: ext4
              mount_point: /opt/mount2

- name: Create LVM pool over three disks
  include_role:
    name: rhel-system-roles.storage

이 섹션에서는 예제 Ansible 플레이북을 제공합니다. 이 플레이북은 스토리지 역할을 적용하여 스왑 볼륨이 없는 경우 또는 기본 매개변수를 사용하는 블록 장치에 스왑 볼륨을 수정하거나 스왑 볼륨이 이미 존재하는 경우 수정합니다.

---
- name: Create a disk device with swap
- hosts: all
  vars:
    storage_volumes:
      - name: swap_fs
        type: disk
        disks:
          - /dev/sdb
	size: 15 GiB
        fs_type: swap
  roles:
    - rhel-system-roles.storage

스토리지 시스템 역할을 사용하면 Red Hat Ansible Automation Platform 및 Ansible-Core를 사용하여 RHEL에서 RAID 볼륨을 구성할 수 있습니다. 매개변수를 사용하여 Ansible 플레이북을 생성하여 요구 사항에 맞게 RAID 볼륨을 구성합니다.

스토리지 시스템 역할을 사용하면 Red Hat Ansible Automation Platform을 사용하여 RHEL에서 RAID로 LVM 풀을 구성할 수 있습니다. 이 섹션에서는 사용 가능한 매개 변수를 사용하여 Ansible 플레이북을 설정하여 RAID로 LVM 풀을 구성하는 방법을 배웁니다.

이 섹션에서는 예제 Ansible 플레이북을 제공합니다. 이 플레이북은 스토리지 RHEL 시스템 역할을 적용하여 VDO(가상 데이터 최적화 도구)를 사용하여 LVM(Logical Volumes) 압축 및 중복 제거를 활성화합니다.

---
- name: Create LVM VDO volume under volume group 'myvg'
  hosts: all
  roles:
    -rhel-system-roles.storage
  vars:
    storage_pools:
     - name: myvg
       disks:
         - /dev/sdb
       volumes:
         - name: mylv1
           compression: true
           deduplication: true
           vdo_pool_size: 10 GiB
           size: 30 GiB
           mount_point: /mnt/app/shared

이 예제에서는 압축 및 중복 제거 풀이 true로 설정되어 VDO가 사용되도록 지정합니다. 다음은 이러한 매개변수의 사용을 설명합니다.

storage 역할을 사용하여 Ansible 플레이북을 실행하여 LUKS로 암호화된 볼륨을 생성하고 구성할 수 있습니다.

이 섹션에서는 예제 Ansible 플레이북을 제공합니다. 이 플레이북은 스토리지 시스템 역할을 적용하여 풀의 총 크기의 백분율로 논리 관리자 볼륨(LVM) 볼륨 크기를 표시할 수 있습니다.

---
- name: Express volume sizes as a percentage of the pool's total size
  hosts: all
  roles
    - rhel-system-roles.storage
  vars:
    storage_pools:
    - name: myvg
      disks:
        - /dev/sdb
      volumes:
        - name: data
          size: 60%
          mount_point: /opt/mount/data
        - name: web
          size: 30%
          mount_point: /opt/mount/web
        - name: cache
          size: 10%
          mount_point: /opt/cache/mount

이 예에서는 LVM 볼륨의 크기를 풀 크기의 백분율로 지정합니다. 예를 들면 다음과 같습니다. "60%". 또한 LVM 볼륨의 크기를 사람이 읽을 수 있는 파일 시스템 크기(예: "10g" 또는 "50GiB)"의 풀 크기의 백분율로 지정할 수도 있습니다.

이 섹션에서는 NFS 서비스의 기본 개념에 대해 설명합니다.

NFS(네트워크 파일 시스템)를 사용하면 원격 호스트에서 네트워크를 통해 파일 시스템을 마운트하고 로컬에 마운트된 것처럼 해당 파일 시스템과 상호 작용할 수 있습니다. 이를 통해 네트워크의 중앙 집중식 서버에 리소스를 통합할 수 있습니다.

NFS 서버는 /etc/exports 구성 파일을 참조하여 클라이언트가 내보낸 모든 파일 시스템에 액세스할 수 있는지 여부를 확인합니다. 확인되면 모든 파일 및 디렉터리 작업을 사용자가 사용할 수 있습니다.

이 섹션에는 Red Hat Enterprise Linux에서 지원되는 NFS 버전과 해당 기능이 나열되어 있습니다.

현재 Red Hat Enterprise Linux 9는 다음과 같은 주요 버전의 NFS를 지원합니다.

NFS 버전 2(NFSv2)는 Red Hat에서 더 이상 지원하지 않습니다.

기본 NFS 버전

Red Hat Enterprise Linux 9의 기본 NFS 버전은 4.2입니다. NFS 클라이언트는 기본적으로 NFSv4.2 사용을 시도하고 서버가 NFSv4.2를 지원하지 않는 경우 NFSv4.1로 돌아갑니다. 나중에 마운트가 NFSv4.0으로 대체된 다음 NFSv3로 돌아갑니다.

마이너 NFS 버전의 기능

다음은 Red Hat Enterprise Linux 9의 NFSv4.2의 기능입니다.

다음은 NFSv4.1의 기능입니다.

이 섹션에는 NFS 서버를 실행하거나 NFS 공유를 마운트하는 데 필요한 시스템 서비스가 나열되어 있습니다. Red Hat Enterprise Linux는 이러한 서비스를 자동으로 시작합니다.

Red Hat Enterprise Linux는 커널 수준 지원 및 서비스 프로세스를 결합하여 NFS 파일 공유를 제공합니다. 모든 NFS 버전은 클라이언트와 서버 간의 RPC(Remote Procedure calls)에 의존합니다. NFS 파일 시스템을 공유하거나 마운트하기 위해 다음 서비스가 구현되는 NFS 버전에 따라 함께 작동합니다.

NFSv4를 사용한 RPC 서비스

NFSv4 프로토콜의 마운트 및 잠금 프로토콜이 통합되었습니다. 서버는 또한 잘 알려진 TCP 포트 2049에서 수신 대기합니다. 따라서 NFSv4는 EgressIP bind,lockd, RuntimeClass -statd 서비스와 상호 작용할 필요가 없습니다. nfs-mountd 서비스는 내보내기를 설정하기 위해 NFS 서버에 계속 필요하지만 over-the-wire 작업에는 포함되지 않습니다.

이 섹션에서는 NFS 공유를 마운트하거나 내보낼 때 호스트를 지정하는 데 사용할 수 있는 다양한 형식을 설명합니다.

다음 형식으로 호스트를 지정할 수 있습니다.

이 절차에서는 NFS 공유를 마운트하거나 내보내는 데 필요한 모든 패키지를 설치합니다.

이 절차에서는 지정된 NFSv3 또는 NFSv4 서버 내보내기에 사용할 파일 시스템을 검색합니다.

NFSv4 및 NFSv3를 모두 지원하는 서버에서 두 방법 모두 작동하고 동일한 결과를 제공합니다.

이 절차에서는 mount 유틸리티를 사용하여 서버에서 내보낸 NFS 공유를 마운트합니다.

이 섹션에는 NFS 공유를 마운트할 때 일반적으로 사용되는 옵션이 나열되어 있습니다. 이러한 옵션은 수동 마운트 명령, /etc/fstab 설정 및 EgressIP 와 함께 사용할 수 있습니다.

이 섹션에서는 NFS 서비스의 기본 개념에 대해 설명합니다.

NFS(네트워크 파일 시스템)를 사용하면 원격 호스트에서 네트워크를 통해 파일 시스템을 마운트하고 로컬에 마운트된 것처럼 해당 파일 시스템과 상호 작용할 수 있습니다. 이를 통해 네트워크의 중앙 집중식 서버에 리소스를 통합할 수 있습니다.

NFS 서버는 /etc/exports 구성 파일을 참조하여 클라이언트가 내보낸 모든 파일 시스템에 액세스할 수 있는지 여부를 확인합니다. 확인되면 모든 파일 및 디렉터리 작업을 사용자가 사용할 수 있습니다.

이 섹션에는 Red Hat Enterprise Linux에서 지원되는 NFS 버전과 해당 기능이 나열되어 있습니다.

현재 Red Hat Enterprise Linux 9는 다음과 같은 주요 버전의 NFS를 지원합니다.

NFS 버전 2(NFSv2)는 Red Hat에서 더 이상 지원하지 않습니다.

기본 NFS 버전

Red Hat Enterprise Linux 9의 기본 NFS 버전은 4.2입니다. NFS 클라이언트는 기본적으로 NFSv4.2 사용을 시도하고 서버가 NFSv4.2를 지원하지 않는 경우 NFSv4.1로 돌아갑니다. 나중에 마운트가 NFSv4.0으로 대체된 다음 NFSv3로 돌아갑니다.

마이너 NFS 버전의 기능

다음은 Red Hat Enterprise Linux 9의 NFSv4.2의 기능입니다.

다음은 NFSv4.1의 기능입니다.

NFSv4에는 IP 네트워크를 통해 실행되는 TCP(Transmission Control Protocol)가 필요합니다.

NFSv3에서는 이전 Red Hat Enterprise Linux 버전에서 UDP(User Datagram Protocol)를 사용할 수도 있었습니다. Red Hat Enterprise Linux 9에서는 UDP를 통한 NFS가 더 이상 지원되지 않습니다. 기본적으로 UDP는 NFS 서버에서 비활성화됩니다.

이 섹션에는 NFS 서버를 실행하거나 NFS 공유를 마운트하는 데 필요한 시스템 서비스가 나열되어 있습니다. Red Hat Enterprise Linux는 이러한 서비스를 자동으로 시작합니다.

Red Hat Enterprise Linux는 커널 수준 지원 및 서비스 프로세스를 결합하여 NFS 파일 공유를 제공합니다. 모든 NFS 버전은 클라이언트와 서버 간의 RPC(Remote Procedure calls)에 의존합니다. NFS 파일 시스템을 공유하거나 마운트하기 위해 다음 서비스가 구현되는 NFS 버전에 따라 함께 작동합니다.

NFSv4를 사용한 RPC 서비스

NFSv4 프로토콜의 마운트 및 잠금 프로토콜이 통합되었습니다. 서버는 또한 잘 알려진 TCP 포트 2049에서 수신 대기합니다. 따라서 NFSv4는 EgressIP bind,lockd, RuntimeClass -statd 서비스와 상호 작용할 필요가 없습니다. nfs-mountd 서비스는 내보내기를 설정하기 위해 NFS 서버에 계속 필요하지만 over-the-wire 작업에는 포함되지 않습니다.

이 섹션에서는 NFS 공유를 마운트하거나 내보낼 때 호스트를 지정하는 데 사용할 수 있는 다양한 형식을 설명합니다.

다음 형식으로 호스트를 지정할 수 있습니다.

이 섹션에서는 NFS 서버에서 내보내기를 구성하는 두 가지 방법의 구문 및 옵션에 대해 설명합니다.

export host(options)

export host1(options1) host2(options2) host3(options3)

/exported/directory bob.example.com

/home bob.example.com(rw)
/home bob.example.com (rw)

/another/exported/directory 192.168.0.3(rw,async)

E gressIPbind 서비스는 RPC(Remote Procedure call) 서비스를 수신 대기하는 포트에 매핑합니다. RPC 프로세스는 사용자가 수신 대기 중인 포트를 등록하고, 사용할 수 있는 RPC 프로그램 번호를 등록하기 시작할 때 EgressIP bind 에 알립니다. 그런 다음 클라이언트 시스템이 server에서 특정 RPC 프로그램 번호로 bind 에 연결합니다. controlPlane bind 서비스는 클라이언트를 적절한 포트 번호로 리디렉션하여 요청된 서비스와 통신할 수 있도록 합니다.

네트워크 파일 시스템 버전 3(NFSv3)에는 rpcbind 서비스가 필요합니다.

RPC 기반 서비스는verify bind 를 사용하여 들어오는 클라이언트 요청과의 모든 연결을 수행하므로 이러한 서비스를 시작하기 전에 EgressIP bind 를 사용할 수 있어야 합니다.

EgressIP bind에 대한 액세스 제어 규칙은 모든 RPC 기반 서비스에 영향을 미칩니다. 또는 NFS RPC 데몬마다 액세스 제어 규칙을 지정할 수 있습니다.

이 절차에서는 NFS 공유를 마운트하거나 내보내는 데 필요한 모든 패키지를 설치합니다.

다음 절차에서는 NFS 공유를 내보내는 데 필요한 NFS 서버를 시작하는 방법을 설명합니다.

controlPlane bind 서비스는 RPC 서비스와 통신하는 데 사용되는 포트 번호 간의 조정을 제공하므로 문제를 해결할 때 stderr bind 를 사용하여 현재 RPC 서비스의 상태를 확인하는 것이 유용합니다. RuntimeClass info 유틸리티는 각 RPC 기반 서비스와 포트 번호, RPC 프로그램 번호, 버전 번호, IP 프로토콜 유형(TCP 또는 UDP)을 보여줍니다.

NFS에는 RPC 서비스에 대한 포트를 동적으로 할당하고 방화벽 규칙을 구성하는 데 문제가 발생할 수 있는 EgressIP bind 서비스가 필요합니다. 다음 섹션에서는 지원하려는 경우 방화벽에서 작동하도록 NFS 버전을 구성하는 방법을 설명합니다.

디스크 할당량을 사용하는 파일 시스템을 내보내는 경우 quota Remote Procedure call(RPC) 서비스를 사용하여 NFS 클라이언트에 디스크 할당량 데이터를 제공할 수 있습니다.

RDMA(Remote Direct Memory Access) 서비스는 Red Hat Enterprise Linux 9의 RDMA 가능 하드웨어에서 자동으로 작동합니다.

이 섹션에서는 NFSv4만 지원하도록 NFS 서버를 구성하는 이점과 단점에 대해 설명합니다.

기본적으로 NFS 서버는 Red Hat Enterprise Linux 9에서 NFSv3 및 NFSv4 연결을 지원합니다. 그러나 NFS 버전 4.0 이상만 지원하도록 NFS를 구성할 수도 있습니다. 이렇게 하면 NFSv4가 네트워크에서 수신 대기할 필요가 없으므로 열린 포트 수와 시스템에서 실행 중인 서비스 수가 최소화됩니다.

NFS 서버가 NFSv4 전용으로 구성된 경우 NFSv3를 사용하여 공유를 마운트하려고 하는 클라이언트는 다음과 같은 오류와 함께 실패합니다.

Requested NFS version or transport protocol is not supported.

선택적으로 NFSv4 전용 사례에 필요하지 않은 RPCBIND,MOUNT, NSM 프로토콜 호출에 대한 수신을 비활성화할 수도 있습니다.

이러한 추가 옵션을 비활성화하는 영향은 다음과 같습니다.

다음 절차에서는 NFS 버전 4.0 이상만 지원하도록 NFS 서버를 구성하는 방법을 설명합니다.

변경 사항은 NFS 서버를 시작하거나 다시 시작하는 즉시 적용됩니다.

이 절차에서는 netstat 유틸리티를 사용하여 NFS 서버가 NFSv4 전용 모드에서 구성되었는지 확인하는 방법을 설명합니다.

NFS는 내보낸 파일에 대한 액세스를 제어하기 위해 다음과 같은 기존 옵션을 제공합니다.

잠재적인 위험을 제한하기 위해 관리자는 종종 액세스를 읽기 전용 또는 squash 사용자 권한으로 일반 사용자 및 그룹 ID로 제한합니다. 유감스럽게도 이러한 솔루션은 NFS 공유를 원래 의도한 방식으로 사용하지 않습니다.

또한 공격자가 NFS 파일 시스템을 내보내는 시스템에서 사용하는 DNS 서버를 제어하면 특정 호스트 이름 또는 정규화된 도메인 이름과 연결된 시스템을 인증되지 않은 시스템으로 가리킬 수 있습니다. 이 시점에 는 NFS 마운트에 대한 추가 보안을 제공하기 위해 사용자 이름 또는 암호 정보가 교환되지 않으므로 인증되지 않은 시스템은 NFS 공유를 마운트할 수 있는 시스템입니다.

와일드카드는 NFS를 통해 디렉터리를 내보낼 때는 의도한 것보다 많은 시스템을 포함할 수 있으므로 와일드카드를 사용해야 합니다.

모든 버전의 NFS는 RPCSEC_GSS 및 Kerberos 메커니즘을 지원합니다.

RPCSEC_GSS Kerberos 메커니즘을 사용하는 AUTH_SYS와 달리 서버는 파일에 액세스하는 사용자를 올바르게 나타내기 위해 클라이언트에 의존하지 않습니다. 대신 암호화는 서버에 사용자를 인증하는 데 사용되며 악의적인 클라이언트가 해당 사용자의 Kerberos 자격 증명을 사용하지 않고 가장할 수 있습니다. Kerberos를 구성한 후 추가 설정이 필요 없기 때문에 RPCSEC_GSS Kerberos 메커니즘을 사용하는 가장 간단한 방법은 마운트를 보호하는 가장 간단한 방법입니다.

Kerberos는 대칭 암호화 및 신뢰할 수 있는 타사인 NetNamespace를 사용하여 클라이언트와 서버가 서로 인증할 수 있도록 하는 네트워크 인증 시스템입니다. Kerberos 설정을 위해 IdM(Identity Management)을 사용하는 것이 좋습니다.

NFSv4에는 Microsoft Windows NT 모델의 기능 및 광범위한 배포 때문에 POSIX 모델이 아닌 Microsoft Windows NT 모델을 기반으로 하는 ACL 지원이 포함되어 있습니다.

NFSv4의 또 다른 중요한 보안 기능은 MOUNT 프로토콜 사용을 제거하여 파일 시스템 마운트입니다. MOUNT 프로토콜에는 프로토콜이 파일을 처리하는 방식 때문에 보안 위험이 있었습니다.

NFS 파일 시스템이 원격 호스트에서 읽기 또는 읽기 및 쓰기로 마운트되면 각 공유 파일에 대한 유일한 보호 권한이 있습니다. 동일한 사용자 ID 값을 공유하는 두 사용자가 서로 다른 클라이언트 시스템에 동일한 NFS 파일 시스템을 마운트한 경우 서로의 파일을 수정할 수 있습니다. 또한 클라이언트 시스템에서 root로 로그인한 사용자는 su - 명령을 사용하여 NFS 공유로 모든 파일에 액세스할 수 있습니다.

기본적으로 ACL(액세스 제어 목록)은 Red Hat Enterprise Linux에서 NFS에서 지원됩니다. Red Hat은 이 기능을 활성화하는 것을 권장합니다.

기본적으로 NFS는 파일 시스템을 내보낼 때 루트 스쿼딩 을 사용합니다. 이렇게 하면 로컬 시스템에서 root 사용자로 NFS 공유에 액세스하는 사용자의 사용자 ID를 nobody 로 설정합니다. 루트 스쿼시는 기본 옵션 root_squash 에 의해 제어됩니다. 이 옵션에 대한 자세한 내용은 NFS 서버 구성을 참조하십시오.

NFS 공유를 읽기 전용으로 내보낼 때는 all_squash 옵션을 사용하는 것이 좋습니다. 이 옵션을 사용하면 내보낸 파일 시스템에 액세스하는 모든 사용자가 nobody 사용자의 사용자 ID를 사용합니다.

pNFS 아키텍처는 NFS의 확장성을 향상시킵니다. 서버가 pNFS를 구현하는 경우 클라이언트는 여러 서버를 통해 동시에 데이터에 액세스할 수 있습니다. 이로 인해 성능이 개선될 수 있습니다.

pNFS는 RHEL에서 다음과 같은 스토리지 프로토콜 또는 레이아웃을 지원합니다.

SCSI 레이아웃은 pNFS 블록 레이아웃 작업을 기반으로 합니다. 레이아웃은 SCSI 장치 간에 정의됩니다. SCSI 영구 예약을 지원할 수 있어야 하는 논리 단위(LU)로 순차적 일련의 고정 크기 블록이 포함되어 있습니다. LU 장치는 SCSI 장치 식별으로 식별됩니다.

pNFS SCSI은 파일에 대한 장기간 단일 클라이언트 액세스와 관련된 사용 사례에서 잘 수행합니다. 예를 들어 메일 서버 또는 클러스터를 보유하는 가상 시스템일 수 있습니다.

클라이언트와 서버 간 작업

NFS 클라이언트가 파일에서 읽거나 쓸 때 클라이언트는 LAYOUTGET 작업을 수행합니다. 서버는 SCSI 장치에 있는 파일의 위치로 응답합니다. 클라이언트는 사용할 SCSI 장치를 결정하기 위해 GETDEVICEINFO 의 추가 작업을 수행해야 할 수 있습니다. 이러한 작업이 올바르게 작동하는 경우 클라이언트는 READ 및 WRITE 작업을 서버로 보내는 대신 SCSI 장치에 직접 I/O 요청을 실행할 수 있습니다.

클라이언트 간의 오류 또는 경합으로 인해 서버에서 레이아웃을 회수하거나 클라이언트에 문제를 발생시키지 않을 수 있습니다. 이러한 경우 클라이언트는 I/O 요청을 SCSI 장치로 직접 보내는 대신 READ 및 WRITE 작업을 서버에 다시 실행합니다.

작업을 모니터링하려면 pNFS SCSI 레이아웃 기능 모니터링 을 참조하십시오.

장치 예약

PNFS SCSI은 예약 할당을 통해 펜싱을 처리합니다. 서버가 클라이언트에 레이아웃을 생성하기 전에 등록된 클라이언트만 장치에 액세스할 수 있도록 SCSI 장치를 예약합니다. 클라이언트가 해당 SCSI 장치에 명령을 실행할 수 있지만 장치에 등록되지 않은 경우 해당 장치의 클라이언트의 많은 작업이 실패합니다. 예를 들어, 서버에 클라이언트에 해당 장치의 레이아웃이 제공되지 않은 경우 클라이언트의 blkid 명령은 XFS 파일 시스템의 UUID를 표시하지 않습니다.

서버가 자체 영구 예약을 제거하지 않습니다. 이렇게 하면 클라이언트 및 서버를 다시 시작해도 장치에서 파일 시스템 내의 데이터가 보호됩니다. SCSI 장치를 다시 사용하려면 NFS 서버에서 영구 예약을 수동으로 제거해야 할 수 있습니다.

다음 절차에서는 SCSI 장치가 pNFS SCSI 레이아웃을 지원하는지 확인합니다.

이 절차에서는 pNFS SCSI 레이아웃을 내보내도록 NFS 서버를 구성합니다.

이 절차에서는 NFS 클라이언트가 pNFS SCSI 레이아웃을 마운트하도록 구성합니다.

이 절차에서는 NFS 서버가 SCSI 장치에 보유하고 있는 영구 예약을 해제합니다. 이를 통해 더 이상 pNFS SCSI을 내보낼 필요가 없는 경우 SCSI 장치를 변경할 수 있습니다.

서버에서 예약을 제거해야 합니다. 다른 IT Nexus에서는 제거할 수 없습니다.

이 절차에서는 nfsstat 유틸리티를 사용하여 서버에서 pNFS SCSI 작업을 모니터링합니다.

이 절차에서는 /proc/self/mountstats 파일을 사용하여 클라이언트에서 pNFS SCSI 작업을 모니터링합니다.

다음 다이어그램은 FS-Cache 작동 방법에 대한 간략한 설명입니다.

그림 9.1. FS-Cache 개요

FS-Cache는 시스템 관리자와 사용자에게 가능한 한 투명하도록 설계되었습니다. 솔라리스의 cachefs 와 달리 FS-Cache를 사용하면 과도한 마운트된 파일 시스템을 만들지 않고도 서버의 파일 시스템이 클라이언트의 로컬 캐시와 직접 상호 작용할 수 있습니다. NFS를 사용하면 마운트 옵션이 클라이언트에 FS-cache가 활성화된 NFS 공유를 마운트하도록 지시합니다. 마운트 지점을 사용하면 두 커널 모듈(fs cache 및 cachefiles ) 에 대한 자동 업로드가 발생합니다. cachefilesd 데몬은 커널 모듈과 통신하여 캐시를 구현합니다.

FS-Cache는 네트워크를 통해 작동하는 파일 시스템의 기본 작업을 변경하지 않으며, 이는 데이터를 캐시할 수 있는 영구 공간으로 파일 시스템을 제공하기만 하면 됩니다. 예를 들어 클라이언트는 FS-Cache가 활성화되어 있는지 여부에 관계없이 NFS 공유를 계속 마운트할 수 있습니다. 또한 캐시된 NFS는 파일이 부분적으로 캐시될 수 있으므로 캐시에 맞지 않는 파일을 처리할 수 있으며 완전히 읽을 필요가 없습니다. FS-Cache는 클라이언트 파일 시스템 드라이버에서 캐시에 발생하는 모든 I/O 오류도 숨깁니다.

캐싱 서비스를 제공하려면 FS-Cache에 캐시 백엔드 가 필요합니다. 캐시 백엔드는 캐시 파일인 캐싱 서비스를 제공하도록 구성된 스토리지 드라이버입니다. 이 경우 FS-Cache에는 bmap 및 확장 속성(예: ext3)을 캐시 백엔드로 지원하는 마운트된 블록 기반 파일 시스템이 필요합니다.

FS-Cache 캐시 백엔드에 필요한 기능을 지원하는 파일 시스템에는 다음 파일 시스템의 Red Hat Enterprise Linux 9 구현이 포함됩니다.

FS-Cache는 네트워크를 통해 일반적으로 모든 파일 시스템을 캐시할 수 없습니다. 공유 파일 시스템의 드라이버는 FS-Cache, 데이터 스토리지/retrieval, 메타데이터 설정 및 유효성 검사와 상호 작용할 수 있도록 변경해야 합니다. FS-Cache는 지속성을 지원하기 위해 캐시된 파일 시스템의 인덱싱 키와 일관성 데이터를 필요로 합니다. 파일 시스템 개체와 일치하기 위한 인덱싱 키 및 일관성 데이터를 사용하여 캐시 오브젝트가 계속 유효한지 확인합니다.

FS-Cache는 성능 향상을 보장하지 않습니다. 캐시를 사용하면 성능 저하가 발생합니다. 예를 들어 캐시된 NFS 공유에서는 교차 네트워크 조회에 대한 디스크 액세스 권한을 추가합니다. FS-Cache는 가능한 한 비동기로 시도하지만 이것이 가능하지 않은 동기 경로 (예: 읽기)가 있습니다.

예를 들어 FS-Cache를 사용하여 다른 차단되지 않은 GigE 네트워크를 통해 두 컴퓨터 간에 NFS 공유를 캐시하면 파일 액세스 시 성능 향상이 수행되지 않을 수 있습니다. NFS 요청은 로컬 디스크가 아닌 서버 메모리에서 더 빠르게 충족됩니다.

따라서 FS-Cache를 사용하면 다양한 요인이 손상 됩니다. 예를 들어 FS-Cache를 사용하여 NFS 트래픽을 캐시하는 경우 클라이언트의 속도가 약간 느려질 수 있지만 네트워크 대역폭을 사용하지 않고 로컬로 읽기 요청을 충족하기 때문에 네트워크 및 서버 로드가 느려질 수 있습니다.

현재 Red Hat Enterprise Linux 9는 cachefiles 캐싱 백엔드만 제공합니다. cachefilesd 데몬은 cachefiles 를 시작하고 관리합니다. /etc/cachefilesd.conf 파일은 cachefiles 에서 캐싱 서비스를 제공하는 방법을 제어합니다.

캐시 백엔드는 캐시를 호스팅하는 파티션에 특정 양의 여유 공간을 유지하여 작동합니다. 사용 가능한 공간을 사용하여 시스템의 다른 요소에 대한 응답으로 캐시를 확장 및 축소하여 루트 파일 시스템(예: 랩탑에서)을 안전하게 사용할 수 있습니다. FS-Cache는 캐시 큐를 통해 구성할 수 있는 이 동작의 기본값을 설정합니다. 캐시 단서 제한 구성에 대한 자세한 내용은 캐시 단서 제한 구성 을 참조하십시오.

다음 절차에서는 캐시를 설정하는 방법을 설명합니다.

cachefilesd 데몬은 공유 파일 시스템의 원격 데이터를 캐싱하여 디스크 공간을 확보하여 작동합니다. 이로 인해 사용 가능한 모든 여유 공간을 소비할 수 있으므로 디스크가 루트 파티션을 배치한 경우 문제가 발생할 수 있습니다. 이를 제어하기 위해 cachefilesd 는 캐시에서 이전 오브젝트(예: 액세스 less recently)를 삭제하여 특정 양의 여유 공간을 유지하려고 합니다. 이 동작을 캐시 큐링 이라고 합니다.

캐시 큐링은 블록 백분율과 기본 파일 시스템에서 사용할 수 있는 파일의 백분율에 따라 수행됩니다. /etc/cachefilesd.conf 에는 6개의 제한을 제어하는 설정이 있습니다.

각 설정 의 기본값은 다음과 같습니다.

이러한 설정을 구성할 때 다음 사항이 충족되어야 합니다.

다음은 사용 가능한 공간 및 사용 가능한 파일의 백분율이며 df 프로그램에서 표시하는 백분율을 100개로 표시하지 않습니다.

FS-Cache는 일반 통계 정보를 추적합니다. 다음 절차에서는 이 정보를 얻는 방법을 설명합니다.

FS-Cache 통계에는 의사 결정 지점 및 개체 카운터에 대한 정보가 포함됩니다. 자세한 내용은 다음 커널 문서를 참조하십시오.

/usr/share/doc/kernel-doc-4.18.0/Documentation/filesystems/caching/fscache.txt

이 섹션에서는 FS-Cache에 대한 참조 정보를 제공합니다.

NFS 캐시 공유에는 몇 가지 잠재적인 문제가 있습니다. 캐시는 영구적이므로 캐시의 데이터 블록은 다음 네 가지 키 순서로 인덱싱됩니다.

수퍼 블록 간의 일관성 관리 문제를 방지하기 위해 데이터를 캐시하는 데 필요한 모든 NFS 수퍼 블록에는 고유한 레벨 2 키가 있습니다. 일반적으로 동일한 소스 볼륨 및 옵션을 사용하는 두 NFS 마운트는 수퍼 블록을 공유하므로 해당 볼륨 내에서 다른 디렉터리를 마운트하더라도 캐싱을 공유합니다.

다음은 다양한 옵션을 사용하여 캐시 공유를 구성하는 예제입니다.

NFS에는 몇 가지 캐시 제한 사항이 있습니다.

cifs.ko 커널 모듈은 다음과 같은 SMB 프로토콜 버전을 지원합니다.

Samba는 SMB 프로토콜에서 CAP_UNIX 기능 비트를 사용하여 UNIX 확장 기능을 제공합니다. 이러한 확장 기능은 cifs.ko 커널 모듈에서도 지원됩니다. 그러나 Samba와 커널 모듈 모두 SMB 1 프로토콜에서만 UNIX 확장을 지원합니다.

UNIX 확장을 사용하려면 다음을 수행합니다.

UNIX 확장 기능이 활성화되어 있는지 확인하려면 마운트된 공유 옵션을 표시합니다.

# mount
...
//server/share on /mnt type cifs (...,unix,...)

마운트 옵션 목록에 unix 항목이 표시되면 UNIX 확장이 활성화됩니다.

SMB 공유만 임시로 마운트해야 하는 경우 마운트 유틸리티를 사용하여 수동으로 마운트할 수 있습니다.

# mount -t cifs -o username=user_name //server_name/share_name /mnt/
Password for user_name@//server_name/share_name:  password

-o 매개변수에서는 공유를 마운트하는 데 사용되는 옵션을 지정할 수 있습니다. 자세한 내용은 mount.cifs(8) 도움말 페이지 및 자주 사용되는 마운트 옵션 의 OPTIONS 섹션을 참조하십시오.

# mount -t cifs -o username=DOMAIN\Administrator,seal,vers=3.0 //server/example /mnt/
Password for DOMAIN\Administrator@//server_name/share_name:  password

서버에 마운트된 SMB 공유에 대한 액세스가 영구적으로 필요한 경우 부팅 시 공유를 자동으로 마운트합니다.

//server_name/share_name  /mnt  cifs  credentials=/root/smb.cred  0 0

/etc/fstab 에 있는 행의 네 번째 필드에서 자격 증명 파일 경로와 같은 마운트 옵션을 지정합니다. 자세한 내용은 mount.cifs(8) 도움말 페이지 및 자주 사용되는 마운트 옵션 의 OPTIONS 섹션을 참조하십시오.

공유가 성공적으로 마운트되는지 확인하려면 다음을 입력합니다.

# mount /mnt/

부팅 시 공유를 자동으로 마운트하는 경우와 같은 특정 상황에서는 사용자 이름 및 암호를 입력하지 않고 공유를 마운트해야 합니다. 이를 구현하려면 자격 증명 파일을 만듭니다.

이제 credentials=file_name 마운트 옵션을 마운트 유틸리티에 전달하거나 /etc/fstab 파일에서 사용하여 사용자 이름 및 암호를 입력하라는 메시지가 표시되지 않고 공유를 마운트할 수 있습니다.

SMB 공유를 마운트할 때 마운트 옵션이 결정됩니다.

/etc/fstab 파일의 네 번째 필드 또는 mount 명령의 -o 매개 변수에 여러 옵션을 설정하려면 쉼표로 구분합니다. 예를 들어, multiuser 옵션을 사용하여 공유 마운트를 참조하십시오.

다음 목록은 자주 사용되는 마운트 옵션을 제공합니다.

전체 목록은 mount.cifs(8) 도움말 페이지의 OPTIONS 섹션을 참조하십시오.

사용자가 자신의 자격 증명을 사용하여 공유에 액세스하기 전에 제한된 권한이 있는 계정을 사용하여 root 사용자로 공유를 마운트합니다.

시스템이 부팅될 때 공유를 자동으로 마운트하지 않으려면 -oResourceOverride,sec=security_type 을 mount 명령에 전달하여 수동으로 마운트합니다. 수동으로 SMB 공유 마운트에 대한 자세한 내용은 SMB 공유 수동으로 마운트를 참조하십시오.

다중 사용자 옵션을 사용하여 공유가 마운트되었는지 확인하려면 마운트 옵션을 표시합니다.

# mount
...
//server_name/share_name on /mnt type cifs (sec=ntlmssp,multiuser,...)

마운트 옵션 목록에 다중 사용자 항목이 표시되면 기능이 활성화됩니다.

사용자 지정 옵션을 사용하여 SMB 공유를 마운트하면 사용자는 해당 서버에 대한 자격 증명을 커널의 인증 키에 제공할 수 있습니다.

# cifscreds add -u SMB_user_name server_name
Password: password

사용자가 마운트된 SMB 공유가 포함된 디렉터리에서 작업을 수행할 때, 서버는 공유가 마운트될 때 처음 사용된 대신 이 사용자에 대한 파일 시스템 권한을 적용합니다.

Red Hat Enterprise Linux는 스토리지 장치를 식별하는 다양한 방법을 제공합니다. 특히 드라이브를 설치하거나 다시 포맷할 때 실수로 잘못된 장치에 액세스하지 않도록 각 장치를 사용하기 위해 올바른 옵션을 사용하는 것이 중요합니다.

일반적으로 /dev/sd(major number) 의 형태로 비영구적인 이름은 Linux에서 스토리지 장치를 참조하는 데 사용됩니다. 주요 및 마이너 번호 범위 및 관련 sd 이름은 감지 시 각 장치에 할당됩니다. 즉, 장치 탐지 순서가 변경될 경우 메이저 및 마이너 번호 범위와 연결된 sd 이름 간의 연결이 변경될 수 있습니다.

이러한 순서의 변경은 다음과 같은 상황에서 발생할 수 있습니다.

이러한 이유로 /etc/fstab 파일에서와 같이 장치를 참조할 때 메이저 및 마이너 번호 범위 또는 관련 sd 이름을 사용하지 않는 것이 좋습니다. 잘못된 장치가 마운트될 가능성이 있으며 데이터 손상이 발생할 수 있습니다.

그러나 장치에서 오류를 보고할 때와 같이 다른 메커니즘을 사용하는 경우에도 sd 이름을 참조해야 하는 경우가 있습니다. 이는 Linux 커널이 장치와 관련된 커널 메시지에서 sd 이름(및 SCSI host/channel/target/LUN tuples)을 사용하기 때문입니다.

이 섹션에서는 파일 시스템과 블록 장치를 식별하는 영구 속성의 차이점을 설명합니다.

파일 시스템 식별자

파일 시스템 식별자는 블록 장치에서 생성된 특정 파일 시스템에 연결됩니다. 식별자는 파일 시스템의 일부로 저장됩니다. 파일 시스템을 다른 장치로 복사하는 경우에도 동일한 파일 시스템 식별자를 전달합니다. 반면, mkfs 유틸리티로 포맷하는 등의 장치를 다시 작성하는 경우 장치는 속성이 손실됩니다.

파일 시스템 식별자는 다음과 같습니다.

장치 식별자

장치 식별자는 블록 장치에 연결됩니다(예: 디스크 또는 파티션). mkfs 유틸리티로 포맷하는 등의 장치를 다시 작성하는 경우 장치는 파일 시스템에 저장되지 않기 때문에 속성을 유지합니다.

장치 식별자는 다음과 같습니다.

권장 사항

이 섹션에는 udev 서비스가 /dev/disk/ 디렉터리에 제공하는 다양한 종류의 영구 이름 지정 속성이 나열되어 있습니다.

udev 메커니즘은 스토리지 장치뿐만 아니라 Linux의 모든 유형의 장치에 사용됩니다. 스토리지 장치의 경우 Red Hat Enterprise Linux에는 /dev/disk/ 디렉터리에 심볼릭 링크를 생성하는 udev 규칙이 포함되어 있습니다. 이를 통해 스토리지 장치를 참조할 수 있습니다.

udev 이름 지정 속성은 영구적이지만 시스템 재부팅 시 자체적으로 변경되지 않는 경우에도 일부 속성을 구성할 수 있습니다.

/dev/disk/by-uuid/3e6be9de-8139-11d1-9106-a43f08d823a6

UUID=3e6be9de-8139-11d1-9106-a43f08d823a6

/dev/disk/by-label/Boot

LABEL=Boot

WWID(WWID)와 비영구 장치 이름 간에 매핑되도록 DM(Device Mapper) Multipath를 구성할 수 있습니다.

시스템에서 장치로 경로가 여러 개 있는 경우 DM Multipath는 WWID를 사용하여 이를 감지합니다. 그런 다음 DM Multipath는 /dev/mapper/wwid 디렉터리에 /dev/mapper/3600508b400105df70000e00000ac0000 에 하나의 "pseudo-device"를 표시합니다.

multipath -l 명령은 비영구 식별자에 대한 매핑을 표시합니다.

3600508b400105df70000e00000ac0000 dm-2 vendor,product
[size=20G][features=1 queue_if_no_path][hwhandler=0][rw]
\_ round-robin 0 [prio=0][active]
 \_ 5:0:1:1 sdc 8:32  [active][undef]
 \_ 6:0:1:1 sdg 8:96  [active][undef]
\_ round-robin 0 [prio=0][enabled]
 \_ 5:0:0:1 sdb 8:16  [active][undef]
 \_ 6:0:0:1 sdf 8:80  [active][undef]

DM Multipath는 각 WWID 기반 장치 이름을 시스템의 해당 /dev/sd 이름에 자동으로 매핑합니다. 이러한 이름은 경로 변경 전반에 걸쳐 지속되며 다른 시스템의 장치에 액세스할 때 일관되게 유지됩니다.

DM Multipath의 user_friendly_names 기능을 사용하면 WWID가 /dev/mapper/mpathN 형식의 이름에 매핑됩니다. 기본적으로 이 매핑은 /etc/multipath/bindings 파일에서 유지됩니다. 이러한 mpathN 이름은 파일이 유지되는 한 지속됩니다.

다음은 udev 이름 지정 규칙의 몇 가지 제한 사항입니다.

다음 절차에서는 비영구 스토리지 장치의 영구 이름 지정 속성을 찾는 방법을 설명합니다.

다음 절차에서는 파일 시스템의 UUID 또는 레이블 영구 이름 지정 속성을 변경하는 방법을 설명합니다.

다음 명령에서 다음을 수행합니다.

이미 정의되어 있고 전체 하드 디스크에 걸쳐 있지 않은 파티션은 정의된 파티션에 속하지 않는 할당되지 않은 공간을 남겨 둡니다. 다음 다이어그램에서는 이것이 어떻게 보이는지 보여줍니다.

그림 19.1. 파티션되지 않은 여유 공간이 있는 디스크

첫 번째 다이어그램은 하나의 기본 파티션과 할당되지 않은 공간이 있는 정의되지 않은 파티션이 있는 디스크를 나타냅니다. 두 번째 다이어그램은 공간이 할당된 두 개의 정의된 파티션이 있는 디스크를 나타냅니다.

사용되지 않은 하드 디스크도 이 분류에 속합니다. 유일한 차이점은 모든 공간이 정의된 파티션의 일부가 아니라는 것입니다.

새 디스크에서 사용되지 않는 공간을 통해 필요한 파티션을 만들 수 있습니다. 대부분의 사전 설치된 운영 체제는 디스크 드라이브에서 사용 가능한 모든 공간을 차지하도록 구성되어 있습니다.

다음 예에서 첫 번째 다이어그램은 사용되지 않은 파티션이 있는 디스크를 나타냅니다. 두 번째 다이어그램은 Linux에서 사용되지 않은 파티션을 찾는 것을 나타냅니다.

그림 19.2. 사용되지 않는 파티션이 있는 디스크

사용되지 않은 파티션에 할당된 공간을 사용하려면 파티션을 삭제한 다음 적절한 Linux 파티션을 만듭니다. 또는 설치 프로세스 중에 사용되지 않은 파티션을 삭제하고 새 파티션을 수동으로 만듭니다.

이 프로세스에는 이미 사용 중인 활성 파티션에 필요한 여유 공간이 포함되어 있으므로 이 프로세스를 관리하기 어려울 수 있습니다. 대부분의 경우 소프트웨어가 사전 설치된 컴퓨터 하드 디스크에는 운영 체제 및 데이터를 보유한 더 큰 파티션이 포함되어 있습니다.

사용 가능한 여유 공간 사용을 최적화하기 위해, 안전하지 않거나 파괴되지 않은 재파운딩 방법을 사용할 수 있습니다.

19.3.1. 안전하지 않은 재파티션

안전하지 않은 재파티션은 하드 드라이브에서 파티션을 제거하고 대신 작은 여러 파티션을 만듭니다. 이 방법을 사용하면 전체 내용이 삭제되므로 원래 파티션에서 필요한 모든 데이터를 백업하십시오.

기존 운영 체제에 대해 더 작은 파티션을 생성한 후 다음을 수행할 수 있습니다.

• 소프트웨어 재설치.
• 데이터를 복원합니다.
• Red Hat Enterprise Linux 설치를 시작하십시오.

다음 다이어그램은 안전하지 않은 repartitioning 방법 사용에 대한 단순화된 표현입니다.

그림 19.3. 디스크에 대한 안전하지 않은 재파티 파티션 작업

주의

이 방법은 원래 파티션에 이전에 저장된 모든 데이터를 삭제합니다.

19.3.2. 강제 다시 분할되지 않은 파티션 지정

데이터 손실 없이 파티션 재파티브 크기 조정이 지연되지 않습니다. 이 방법은 신뢰할 수 있지만 큰 드라이브에서 처리 시간이 오래 걸립니다.

다음은 거부된 복원을 시작하는 데 도움이 될 수 있는 메서드 목록입니다.

• 기존 데이터 압축

일부 데이터의 저장 위치는 변경할 수 없습니다. 이렇게 하면 파티션이 필요한 크기로 크기를 조정하는 것을 방지할 수 있으며 궁극적으로 안전하지 않은 재파티션 프로세스가 발생할 수 있습니다. 이미 존재하는 파티션의 데이터를 압축하면 필요에 따라 파티션의 크기를 조정하는 데 도움이 될 수 있습니다. 또한 사용 가능한 공간을 최대화하는 데 도움이 될 수 있습니다.

다음 다이어그램은 이 프로세스를 간단하게 나타냅니다.

그림 19.4. 디스크의 데이터 압축

가능한 데이터 손실을 방지하려면 압축 프로세스를 계속하기 전에 백업을 만듭니다.

• 기존 파티션 크기 조정

기존 파티션의 크기를 조정하면 더 많은 공간을 확보할 수 있습니다. 소프트웨어 크기 조정에 따라 결과가 다를 수 있습니다. 대부분의 경우 원래 파티션과 동일한 유형의 포맷되지 않은 새 파티션을 만들 수 있습니다.

크기 조정 후 수행하는 단계는 사용하는 소프트웨어에 따라 달라질 수 있습니다. 다음 예제에서 가장 좋은 방법은 새 ClusterTask (Disk Operating System) 파티션을 삭제하고 대신 Linux 파티션을 만드는 것입니다. 크기 조정 프로세스를 시작하기 전에 디스크에 가장 적합한 항목을 확인합니다.

그림 19.5. 디스크의 파티션 크기 조정

• 선택 사항: 새 파티션 생성

소프트웨어 크기 조정 중 일부는 Linux 기반 시스템을 지원합니다. 이러한 경우 크기 조정 후 새로 생성된 파티션을 삭제할 필요가 없습니다. 나중에 새 파티션을 만드는 것은 사용하는 소프트웨어에 따라 다릅니다.

다음 다이어그램은 새 파티션을 만들기 전과 후에 디스크 상태를 나타냅니다.

그림 19.6. 최종 파티션 구성이 있는 디스크

XFS는 단일 호스트에서 매우 큰 파일 및 파일 시스템을 지원하는 확장성이 뛰어난 고성능, 견고하며 성숙한 64비트 저널링 파일 시스템입니다. Red Hat Enterprise Linux 9의 기본 파일 시스템입니다. XFS는 원래 SGI에 의해 Subversions에서 개발되었으며 매우 큰 서버 및 스토리지 어레이에서 실행하는 오랜 기록을 보유하고 있습니다.

XFS의 기능은 다음과 같습니다.

XFS는 단일 스레드에 대해 상대적으로 낮은 성능을 제공합니다. 예를 들어 단일 스레드에서 많은 수의 작은 파일을 생성하거나 삭제하는 워크로드와 같습니다.

이 섹션에서는 ext4 및 XFS 파일 시스템에서 일반적인 작업을 수행하는 데 사용할 툴을 비교합니다.

다음 절차에서는 블록 장치에 XFS 파일 시스템을 생성하는 방법을 설명합니다.

이 섹션에서는 예제 Ansible 플레이북을 제공합니다. 이 플레이북은 기본 매개 변수를 사용하여 블록 장치에 XFS 파일 시스템을 생성하도록 storage 역할을 적용합니다.

---
- hosts: all
  vars:
    storage_volumes:
      - name: barefs
        type: disk
        disks:
          - sdb
        fs_type: xfs
  roles:
    - rhel-system-roles.storage

이 섹션에서는 xfsdump 유틸리티를 사용하여 XFS 파일 시스템을 백업하는 주요 개념과 기능을 설명합니다.

xfsdump 유틸리티를 사용하여 다음을 수행할 수 있습니다.

다음 절차에서는 XFS 파일 시스템의 콘텐츠를 파일 또는 테이프에 백업하는 방법을 설명합니다.

xfsrestore 유틸리티는 xfsdump 로 생성된 백업에서 파일 시스템을 복원합니다. xfsrestore 유틸리티에는 다음 두 가지 모드가 있습니다.

고유한 세션 ID 또는 세션 레이블 은 각 백업을 식별합니다. 여러 백업이 포함된 백업에서 백업을 복원하려면 해당 세션 ID 또는 레이블이 필요합니다.

백업에서 특정 파일을 추출, 추가 또는 삭제하려면 xfsrestore 대화형 모드를 입력합니다. 대화형 모드는 백업 파일을 조작하는 명령 집합을 제공합니다.

다음 절차에서는 파일 또는 테이프 백업에서 XFS 파일 시스템의 콘텐츠를 복원하는 방법을 설명합니다.

여러 파일 시스템에서 백업으로 백업을 복원할 때 xfsrestore 유틸리티에서 메시지를 발행할 수 있습니다. 이 메시지는 xfsrestore 에서 각 백업을 순서대로 순서대로 검사할 때 요청된 백업의 일치 여부를 알려줍니다. 예를 들면 다음과 같습니다.

xfsrestore: preparing drive
xfsrestore: examining media file 0
xfsrestore: inventory session uuid (8590224e-3c93-469c-a311-fc8f23029b2a) does not match the media header's session uuid (7eda9f86-f1e9-4dfd-b1d4-c50467912408)
xfsrestore: examining media file 1
xfsrestore: inventory session uuid (8590224e-3c93-469c-a311-fc8f23029b2a) does not match the media header's session uuid (7eda9f86-f1e9-4dfd-b1d4-c50467912408)
[...]

일치하는 백업이 발견될 때까지 정보 메시지가 계속 표시됩니다.

다음 절차에서는 xfs_growfs 유틸리티를 사용하여 XFS 파일 시스템을 확장하는 방법을 설명합니다.

XFS 파일 시스템은 I/O 작업 중에 오류가 발생하면 다음 방법 중 하나로 응답합니다.

XFS가 다음 오류 조건에 응답하는 방법을 구성할 수 있습니다.

XFS가 오류를 영구적으로 간주할 때까지 최대 재시도 횟수와 최대 시간(초)을 설정할 수 있습니다. XFS는 제한 중 하나에 도달하면 작업 재시도를 중지합니다.

XFS를 구성하여 파일 시스템을 마운트 해제할 때 XFS는 다른 구성과 관계없이 즉시 재시도를 취소할 수 있습니다. 이 구성을 사용하면 영구 오류에도 불구하고 마운트 해제 작업이 성공할 수 있습니다.

다음 디렉터리는 다양한 오류 조건에 대해 XFS 오류 동작을 제어하는 구성 파일을 저장합니다.

각 디렉터리에는 재시도 제한을 구성하기 위한 다음 구성 파일이 포함되어 있습니다.

다음 절차에서는 XFS가 특정 오류 상태에 대응하는 방법을 구성합니다.

이 절차에서는 XFS가 공통 구성을 공유하는 모든 정의되지 않은 오류 조건에 반응하는 방법을 구성합니다.

다음 절차에서는 XFS가 파일 시스템을 마운트 해제할 때 오류 상태에 대응하는 방법을 구성합니다.

파일 시스템에서 fail_at_unmount 옵션을 설정하면 마운트 해제 중에 다른 모든 오류 구성을 재정의하고 I/O 작업을 다시 시도하지 않고 파일 시스템을 즉시 마운트 해제합니다. 이를 통해 영구 오류 발생 시에도 마운트 해제 작업을 수행할 수 있습니다.

관련 fsck 툴은 다음 중 하나라도 발생하는 경우 시스템을 확인하는 데 사용할 수 있습니다.

파일 시스템 불일치는 하드웨어 오류, 스토리지 관리 오류 및 소프트웨어 버그로 제한되지는 않지만 다양한 이유로 발생할 수 있습니다.

저널링 파일 시스템의 경우 일반적으로 부팅 시 필요한 경우 저널을 재생하는 데 필요한 모든 작업은 매우 짧은 작업입니다.

그러나 파일 시스템 불일치 또는 손상이 발생하는 경우 파일 시스템 검사기를 사용하여 파일 시스템을 복구해야 합니다.

일반적으로 파일 시스템 검사 및 복구 도구를 실행하면 발견된 불일치 중 적어도 일부를 자동으로 복구할 수 있습니다. 경우에 따라 다음과 같은 문제가 발생할 수 있습니다.

예기치 않거나 바람직하지 않은 변경 사항이 영구적으로 수행되지 않도록 하려면 절차에 설명된 예방 단계를 따르십시오.

이 섹션에서는 XFS가 파일 시스템의 다양한 종류의 오류를 처리하는 방법을 설명합니다.

불명확한 마운트 해제

저널링은 파일 시스템에서 발생하는 메타데이터 변경 사항의 트랜잭션 레코드를 유지 관리합니다.

시스템 충돌, 전원 장애 또는 기타 불명확한 마운트 해제가 발생하는 경우 XFS는 저널(로그라고도 함)을 사용하여 파일 시스템을 복구합니다. 커널은 XFS 파일 시스템을 마운트할 때 저널 복구를 수행합니다.

corruption

이 컨텍스트에서 손상 은 다음과 같이 로 인한 파일 시스템의 오류를 의미합니다.

XFS가 파일 시스템 또는 파일 시스템 메타데이터의 손상을 탐지하면 파일 시스템을 종료하고 시스템 로그에서 문제가 보고될 수 있습니다. /var 디렉토리를 호스팅하는 파일 시스템에서 손상이 발생한 경우 재부팅 후 이러한 로그를 사용할 수 없습니다.

# dmesg --notime | tail -15

XFS (loop0): Mounting V5 Filesystem
XFS (loop0): Metadata CRC error detected at xfs_agi_read_verify+0xcb/0xf0 [xfs], xfs_agi block 0x2
XFS (loop0): Unmount and run xfs_repair
XFS (loop0): First 128 bytes of corrupted metadata buffer:
00000000027b3b56: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000000005f9abc7a: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000000005b0aef35: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000000da9d2ded: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000000001e265b07: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000000006a40df69: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000000000b272907: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000000e484aac5: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
XFS (loop0): metadata I/O error in "xfs_trans_read_buf_map" at daddr 0x2 len 1 error 74
XFS (loop0): xfs_imap_lookup: xfs_ialloc_read_agi() returned error -117, agno 0
XFS (loop0): Failed to read root inode 0x80, error 11

사용자 공간 유틸리티는 손상된 XFS 파일 시스템에 액세스하려고 할 때 일반적으로 Input/output 오류 메시지를 보고합니다. 손상된 로그로 XFS 파일 시스템을 마운트하면 실패한 마운트와 다음과 같은 오류 메시지가 표시됩니다.

mount: /mount-point: mount(2) system call failed: Structure needs cleaning.

수동으로 xfs_repair 유틸리티를 사용하여 손상을 복구해야 합니다.

이 절차에서는 xfs_repair 유틸리티를 사용하여 XFS 파일 시스템의 읽기 전용 검사를 수행합니다. 수동으로 xfs_repair 유틸리티를 사용하여 손상을 복구해야 합니다. 다른 파일 시스템 복구 유틸리티와 달리 xfs_repair 는 XFS 파일 시스템을 완전히 마운트 해제하지 않은 경우에도 부팅 시 실행되지 않습니다. 불명확한 마운트 해제의 경우 XFS는 마운트 시 로그를 재생하여 파일 시스템이 일관되게 유지되도록 합니다. xfs_repair 는 먼저 다시 마운트하지 않고 더티 로그로 XFS 파일 시스템을 복구할 수 없습니다.

이 절차에서는 xfs_repair 유틸리티를 사용하여 손상된 XFS 파일 시스템을 복구합니다.

ext2, ext3 및 ext4 파일 시스템은 e2fsck 유틸리티를 사용하여 파일 시스템 점검 및 복구를 수행합니다. fsck.ext2,fsck.ext3, fsck.ext4 파일 이름은 e2fsck 유틸리티에 대한 하드 링크입니다. 이러한 바이너리는 부팅 시 자동으로 실행되며 해당 동작은 점검 중인 파일 시스템과 파일 시스템의 상태에 따라 다릅니다.

메타데이터 저널링 파일 시스템이 아닌 ext2 및 저널이 없는 ext4 파일 시스템에 대한 전체 파일 시스템 검사 및 복구가 호출됩니다.

메타데이터 저널링이 있는 ext3 및 ext4 파일 시스템의 경우 사용자 공간에서 저널이 재생되고 유틸리티가 종료됩니다. 이는 저널 재생이 충돌 후 일관된 파일 시스템을 보장하므로 기본 작업입니다.

이러한 파일 시스템이 마운트된 동안 메타데이터 불일치가 발생하면 파일 시스템 수퍼 블록에 이 사실을 기록합니다. e2fsck 이 파일 시스템이 이러한 오류로 표시된 것을 발견하면 e2fsck 은 저널을 재생한 후 전체 검사를 수행합니다(있는 경우).

이 절차에서는 e2fsck 유틸리티를 사용하여 ext2, ext3 또는 ext4 파일 시스템을 확인합니다.

이 절차에서는 e2fsck 유틸리티를 사용하여 손상된 ext2, ext3 또는 ext4 파일 시스템을 복구합니다.

이 섹션에서는 Linux에서 파일 시스템 마운트에 대한 기본 개념에 대해 설명합니다.

Linux, UNIX 및 유사한 운영 체제에서는 서로 다른 파티션 및 이동식 장치(예: CD, DVD 또는 USB 플래시 드라이브)의 파일 시스템을 디렉토리 트리의 특정 지점(마운트 지점)에 연결한 다음 다시 분리할 수 있습니다. 파일 시스템은 디렉터리에 마운트되지만 디렉터리의 원본 콘텐츠에는 액세스할 수 없습니다.

Linux에서는 파일 시스템이 이미 연결된 디렉터리에 파일 시스템을 마운트할 수 없습니다.

마운트 시 다음을 통해 장치를 식별할 수 있습니다.

모든 필수 정보 없이 mount 명령을 사용하여 파일 시스템을 마운트할 때 즉 장치 이름, 대상 디렉터리 또는 파일 시스템 유형이 없는 경우 mount 유틸리티는 /etc/fstab 파일의 내용을 읽고 해당 파일 시스템이 나열되는지 확인합니다. /etc/fstab 파일에는 선택한 파일 시스템이 마운트되도록 설정된 장치 이름 목록과 파일 시스템 유형 및 마운트 옵션이 포함되어 있습니다. 따라서 /etc/fstab 에 지정된 파일 시스템을 마운트할 때 다음 명령 구문으로 충분합니다.

이 절차에서는 현재 마운트된 모든 파일 시스템을 명령줄에 나열하는 방법을 설명합니다.

다음 절차에서는 mount 유틸리티를 사용하여 파일 시스템을 마운트 하는 방법을 설명합니다.

다음 절차에서는 마운트된 파일 시스템의 마운트 지점을 다른 디렉터리로 변경하는 방법을 설명합니다.

다음 절차에서는 umount 유틸리티를 사용하여 파일 시스템을 마운트 해제하는 방법을 설명합니다.

다음 표에는 마운트 유틸리티의 가장 일반적인 옵션이 나열되어 있습니다. 다음 구문을 사용하여 이러한 마운트 옵션을 적용할 수 있습니다.

# mount --options option1,option2,option3 device mount-point

사용할 수 있는 여러 유형의 공유 마운트가 있습니다. 차이점은 공유 마운트 지점 중 하나에 다른 파일 시스템을 마운트할 때 발생하는 작업입니다. 공유 마운트는 공유 하위 트리 기능을 사용하여 구현됩니다.

다음 마운트 유형을 사용할 수 있습니다.

이 절차에서는 마운트 지점을 개인 마운트로 중복합니다. 나중에 중복 아래에 마운트하거나 원래 마운트 지점이 다른 마운트 지점에 반영되지 않은 파일 시스템은 다음과 같습니다.

이 절차에서는 마운트 지점을 공유 마운트로 중복합니다. 나중에 원래 디렉토리 아래에 마운트되거나 중복된 파일 시스템은 항상 다른 디렉터리에 반영됩니다.

이 절차에서는 마운트 지점을 슬레이브 마운트 유형으로 중복합니다. 나중에 원래 마운트 지점 아래에 마운트되는 파일 시스템은 중복에 반영되지만 다른 방법은 반영되지 않습니다.

이 절차에서는 마운트 지점을 다른 마운트 지점에서 복제할 수 없도록 마운트 지점을 바인딩할 수 없음으로 표시합니다.

이 섹션에서는 파일 시스템의 영구 마운트 지점을 제어하는 /etc/fstab 구성 파일에 대해 설명합니다. /etc/fstab 를 사용하여 파일 시스템을 영구적으로 마운트하는 것이 좋습니다.

/etc/fstab 파일의 각 행은 파일 시스템의 마운트 지점을 정의합니다. 여기에는 공백으로 구분된 6개의 필드가 있습니다.

systemd 서비스는 /etc/fstab 의 항목에서 마운트 단위를 자동으로 생성합니다.

다음 절차에서는 /etc/fstab 구성 파일에서 파일 시스템의 영구 마운트 지점을 구성하는 방법을 설명합니다.

이 섹션에서는 예제 Ansible 플레이북을 제공합니다. 이 플레이북은 storage 역할을 적용하여 XFS 파일 시스템을 즉시 지속적으로 마운트합니다.

---
- hosts: all
  vars:
    storage_volumes:
      - name: barefs
        type: disk
        disks:
          - sdb
        fs_type: xfs
        mount_point: /mnt/data
  roles:
    - rhel-system-roles.storage

이 섹션에서는 필요에 따라 파일 시스템을 마운트하는 데 사용되는 EgressIP 서비스의 이점과 기본 개념에 대해 설명합니다.

/etc/fstab 구성을 사용한 영구 마운트의 한 가지 단점은 사용자가 종종 마운트된 파일 시스템에 액세스하는 방법에 관계없이 마운트된 파일 시스템을 유지하기 위해 리소스를 전용으로 지정해야 한다는 것입니다. 예를 들어 시스템은 한 번에 여러 시스템에 NFS 마운트를 유지 관리하는 경우 시스템 성능에 영향을 미칠 수 있습니다.

/etc/fstab 에 대한 대안은 커널 기반 EgressIP 서비스를 사용하는 것입니다. 다음 구성 요소로 구성됩니다.

E gressIP 서비스는 파일 시스템을 자동으로 마운트 및 마운트 해제하여 시스템 리소스를 저장할 수 있습니다. NFS, AFS, SMBFS, CIFS 및 로컬 파일 시스템과 같은 파일 시스템을 마운트하는 데 사용할 수 있습니다.

이 섹션에서는 EgressIP 서비스에서 사용하는 구성 파일의 사용법 및 구문에 대해 설명합니다.

모든 온 디맨드 마운트 지점은 마스터 맵에서 구성해야 합니다. 마운트 지점, 호스트 이름, 내보낸 디렉토리 및 옵션은 각 호스트에 대해 수동으로 구성하지 않고 파일 집합(또는 기타 지원되는 네트워크 소스)에 지정할 수 있습니다.

마스터 맵 파일은 EgressIP 에서 제어하는 마운트 지점과 자동 마운트 맵이라는 해당 구성 파일 또는 네트워크 소스를 나열합니다. 마스터 맵의 형식은 다음과 같습니다.

mount-point  map-name  options

이 형식으로 사용되는 변수는 다음과 같습니다.

/mnt/data  /etc/auto.data

자동 마운터는 디렉터리가 없는 경우 해당 디렉터리를 생성합니다. 자동 마운터가 시작되기 전에 디렉터리가 있는 경우 자동 마운터는 종료 시 해당 디렉토리를 제거하지 않습니다. 시간 초과를 지정하면 시간 초과 기간에 디렉터리에 액세스하지 않으면 디렉터리가 자동으로 마운트 해제됩니다.

일반 맵 형식은 마스터 맵과 유사합니다. 그러나 options 필드는 마스터 맵에서와 같이 항목의 끝에 있는 대신 마운트 지점과 위치 사이에 나타납니다.

mount-point  options  location

이 형식으로 사용되는 변수는 다음과 같습니다.

payroll  -fstype=nfs4  personnel:/exports/payroll
sales    -fstype=xfs   :/dev/hda4

그러나 Red Hat은 이전 섹션에 설명된 간단한 result ing 형식을 사용하는 것이 좋습니다.

다음 절차에서는 EgressIP 서비스를 사용하여 주문형 마운트 지점을 구성하는 방법을 설명합니다.

다음 절차에서는 사용자 홈 디렉터리를 자동으로 마운트하도록 EgressIP 서비스를 구성하는 방법을 설명합니다.

클라이언트 시스템의 특정 마운트 지점에 대한 사이트 기본값을 재정의하는 것이 유용한 경우가 있습니다.

이 절차에서는 E gressIP 맵 파일에 있는 것이 아니라 LDAP 구성에 자동 마운터 맵을 저장하도록 E gressIP를 구성합니다.

다음 절차에서는 마운트 지점이 /etc/fstab 에 정의된 경우 자동 마운트 systemd 장치를 사용하여 필요에 따라 파일 시스템을 마운트하는 방법을 보여줍니다. 각 마운트에 대해 자동 마운트 장치를 추가하고 활성화해야 합니다.

다음 절차에서는 마운트 지점을 마운트할 때 마운트 단위를 사용하여 필요에 따라 파일 시스템을 마운트하는 방법을 보여줍니다. 각 마운트에 대해 자동 마운트 장치를 추가하고 활성화해야 합니다.

다음 절차에서는 IdM 서버를 LDAP 서버로 사용하도록 EgressIP을 구성하는 방법을 설명합니다.

SSSD 서비스는 IdM 서버를 전혀 사용하도록 autofs 를 구성하지 않고도 IdM 서버에 저장된 autofs 맵을 캐시하는 데 사용할 수 있습니다.

시스템이 제대로 작동하려면 일부 파일과 디렉터리가 쓰기 권한을 유지해야 합니다. 루트 파일 시스템이 읽기 전용 모드로 마운트되면 이러한 파일은 tmpfs 임시 파일 시스템을 사용하여 RAM에 마운트됩니다.

이러한 파일 및 디렉터리의 기본 세트는 /etc/rwtab 파일에서 읽습니다. 시스템에 이 파일이 있어야 하는 경우 readonly-root 패키지가 필요합니다.

dirs	/var/cache/man
dirs	/var/gdm
<content truncated>

empty	/tmp
empty	/var/cache/foomatic
<content truncated>

files	/etc/adjtime
files	/etc/ntp.conf
<content truncated>

/etc/rwtab 파일의 항목은 다음 형식을 따릅니다.

copy-method    path

이 구문에서 다음을 수행합니다.

/etc/rwtab 파일은 파일 또는 디렉토리를 tmpfs 에 복사할 수 있는 다음과 같은 방법을 인식합니다.

/etc/rwtab.d/ 에 사용자 지정 경로를 추가할 때 동일한 형식이 적용됩니다.

이 절차를 수행하면 다음 모든 부팅 시 루트 파일 시스템이 읽기 전용으로 마운트됩니다.

대부분의 컴퓨팅 환경에서는 디스크 공간이 무한하지 않습니다. 할당량 하위 시스템은 디스크 공간의 사용을 제어하는 메커니즘을 제공합니다.

로컬 파일 시스템에서 개별 사용자 및 사용자 그룹에 대한 디스크 할당량을 구성할 수 있습니다. 이를 통해 사용자별 파일(예: 이메일)에 할당된 공간을 사용자가 작업하는 프로젝트에 할당된 공간과 별도로 관리할 수 있습니다. 할당량 하위 시스템은 할당된 제한을 초과할 때 사용자에게 경고하지만 현재 작업(하드 제한/소프트 제한)에 대해 일부 추가 공간을 허용합니다.

할당량을 구현하는 경우 할당량이 초과되었는지 확인하고 할당량이 올바른지 확인해야 합니다. 사용자가 할당량을 반복적으로 초과하거나 소프트 제한에 지속적으로 도달하는 경우 시스템 관리자는 사용자가 디스크 공간을 적게 사용하는 방법을 결정하거나 사용자의 디스크 할당량을 늘리는 데 도움이 될 수 있습니다.

제어할 할당량을 설정할 수 있습니다.

xfs_quota 툴을 사용하여 XFS 파일 시스템의 할당량을 관리할 수 있습니다. 또한 제한 적용이 설정된 XFS 파일 시스템을 유효 디스크 사용 회계 시스템으로 사용할 수 있습니다.

XFS 할당량 시스템은 여러 가지 면에서 다른 파일 시스템과 다릅니다. 가장 중요한 점은 XFS는 할당량 정보를 파일 시스템 메타데이터로 간주하고 저널링을 사용하여 일관성을 높은 수준으로 보장합니다.

XFS 할당량 하위 시스템은 디스크 공간(블록) 및 파일(inode) 사용량에 대한 제한을 관리합니다. XFS 할당량은 사용자, 그룹 또는 디렉터리 또는 프로젝트 수준에서 이러한 항목을 사용하거나 사용합니다. 그룹 및 프로젝트 할당량은 이전 기본이 아닌 XFS 디스크 형식에서만 상호 배타적입니다.

디렉토리별 또는 프로젝트별로 관리할 때 XFS는 특정 프로젝트와 관련된 디렉터리 계층의 디스크 사용을 관리합니다.

이 절차에서는 XFS 파일 시스템에서 사용자, 그룹 및 프로젝트에 대한 디스크 할당량을 활성화합니다. 할당량이 활성화되면 xfs_quota 툴을 사용하여 제한을 설정하고 디스크 사용량을 보고할 수 있습니다.

xfs_quota 툴을 사용하여 디스크 사용량에 대한 제한 및 보고서를 설정할 수 있습니다. 기본적으로 xfs_quota 는 대화식으로 실행되며 기본 모드에서 실행됩니다. 기본 모드 하위 명령은 단순히 사용법을 보고하며 모든 사용자가 사용할 수 있습니다.

-x 옵션으로 xfs_quota 도구를 시작하여 전문가 모드를 활성화하고 관리자 명령을 실행하여 할당량 시스템을 수정할 수 있습니다. 이 모드의 하위 명령은 실제 제한을 구성할 수 있으며 상승된 권한이 있는 사용자만 사용할 수 있습니다.

이 절차에서는 프로젝트 제어 디렉터리에 대한 제한을 구성합니다.