다음을 통해 공유


SQL Server on Linux의 PMEM(영구적 메모리) 구성

적용 대상: SQL Server - Linux

이 문서에서는 Linux에서 SQL Server 2019 (15.x) 이상 버전에 대해 PMEM(영구 메모리)을 구성하는 방법을 설명합니다.

개요

SQL Server 2019 (15.x)에는 영구 메모리를 사용하는 많은 메모리 기능이 도입되었습니다. 이 문서에서는 SQL Server on Linux에 대해 영구 메모리를 구성하는 데 필요한 단계를 설명합니다.

참고 항목

인식이라는 용어는 영구 메모리 인식 파일 시스템의 작업 개념을 전달하기 위해 도입되었습니다. 메모리 매핑(mmap())을 사용하면 간편하게 사용자 공간 애플리케이션에서 파일 시스템에 직접 액세스할 수 있습니다. 파일에 대한 메모리 매핑이 생성된 경우, 애플리케이션에서 I/O 스택을 완전히 무시하고 로드/저장 명령을 실행할 수 있습니다. 호스트 확장 애플리케이션 관점에서 “인식” 파일 액세스 방법으로 간주하며, SQLPAL이 Windows 또는 Linux OS와 상호 작용할 수 있도록 하는 코드입니다.

PMEM 디바이스에 대한 네임스페이스 만들기

디바이스 구성

Linux에서 ndctl 유틸리티를 사용합니다.

  • ndctl을 설치하여 PMEM 디바이스를 구성합니다. 여기에서 찾을 수 있습니다.
  • ndctl을 사용하여 네임스페이스를 만듭니다. 네임스페이스는 PMEM NVDIMM 간에 인터리브되며, 디바이스의 메모리 영역에 대한 여러 유형의 사용자 공간 액세스를 제공할 수 있습니다. fsdax는 SQL Server에 적합한 기본 모드입니다.
ndctl create-namespace -f -e namespace0.0 --mode=fsdax --map=dev

여기서는 fsdax 모드를 선택했으며 시스템 메모리를 사용하여 페이지별 메타데이터를 저장합니다. --map=dev를 사용하는 것이 좋습니다. 이 옵션은 메타데이터가 네임스페이스에 직접 저장됩니다. --map=mem을 사용하여 메타데이터를 메모리에 저장하는 기능은 현재 실험 단계입니다.

ndctl을 사용하여 네임스페이스를 확인합니다.

샘플 출력은 다음과 같습니다.

# ndctl list -N
{
  "dev":"namespace0.0",
  "mode":"fsdax",
  "map":"dev",
  "size":4294967296,
  "sector_size":512,
  "blockdev":"pmem0",
  "numa_node":0
}

PMEM 디바이스 만들기 및 탑재

예: XFS 사용

mkfs.xfs -f /dev/pmem0
mount -o dax,noatime /dev/pmem0 /mnt/dax
xfs_io -c "extsize 2m" /mnt/dax

예: EXT4 사용

mkfs.ext4 -b 4096 -E stride=512 -F /dev/pmem0
mount -o dax,noatime /dev/pmem0 /mnt/dax

기술 고려 사항

  • 이전에 설명한 대로 XFS/EXT4에 2MB 블록 할당
  • 블록 할당과 mmap 간의 불일치로 인해 4KB로 자동 대체
  • 파일 크기는 2MB의 배수여야 함(모듈로 2MB)
  • THP(투명한 대용량 페이지) 해제 안 함(대부분의 배포에 기본적으로 사용하도록 설정되어 있음)

디바이스가 ndctl을 통해 구성되고 생성 및 탑재되고 나면, 디바이스에 데이터베이스 파일을 배치하거나 새 데이터베이스를 만들 수 있습니다.

아래 명령을 사용하여 fsdax 모드로 구성된 경우 PMEM 디바이스에 SQL Server 데이터 파일(MDFS, NDFS) 및 tempdb 파일을 저장할 수 있습니다. 트랜잭션 로그가 섹터 원자성 보장을 제공하는 스토리지에 있어야 하기 때문에 LDFS(SQL Server 로그) 파일을 저장하는 데 이 방법을 사용하면 안 됩니다.

ndctl create-namespace -f -e namespace0.0 --mode=fsdax --map=dev

이전 명령에서 map 옵션을 설정하기 전에 다음 사항에 유의하세요.

  • 이 디바이스에서 이러한 NVDIMM 페이지 항목 액세스 및 업데이트 시 최상의 성능을 위해 -map=mem을 사용하는 것이 좋습니다.
  • NVDIMM의 용량이 너무 큰 경우(512GB 초과) –map=dev를 설정하면 IO 처리량에 영향을 주고 성능에 방해가 됩니다

PMEM 디바이스의 SQL Server 로그 파일의 경우 PMEM 디바이스를 Con하여 섹터/BTT(블록 변환 테이블)를 사용합니다. 이렇게 하면 이 스토리지 디바이스 기술에 SQL Server 로그 파일에 필요한 섹터 원자성이 제공됩니다. 또한 워크로드 성능 유효성 검사를 수행하는 것이 좋습니다. 이 솔루션과 동급 최고 NVMe SSD의 워크로드 SQL Server 로그 성능을 비교한 다음 요구 사항을 가장 잘 충족하고 더 나은 성능을 제공하는 솔루션을 선택할 수 있습니다.

ndctl create-namespace -f -e namespace0.0 --mode= sector

강제 플러시 동작 사용 중지

PMEM 디바이스는 O_DIRECT (직접 I/O) 안전하므로 강제 플러시 동작을 사용하지 않도록 설정할 수 있습니다.

참고 항목

스토리지 시스템은 캐시되거나 스테이징된 모든 쓰기가 안전하고 내구성이 있다고 보장할 수 있습니다. 이는 장치에 발행된 쓰기가 시스템 충돌, 인터페이스 재설정, 전원 장애 시에도 지속되는 매체에 저장되고, 매체 자체가 하드웨어 중복성을 가지도록 보장함으로써 가능합니다.

  • SQL Server 2017 (14.x) CU 6 및 이후 버전에서는 강제 플러시 동작을 사용하기 때문에 데이터베이스(.mdf.ndf)와 트랜잭션 로그(.ldf) 파일이 기본적으로 writethroughalternatewritethrough를 사용하지 않습니다. 추적 플래그 3979는 데이터베이스 및 트랜잭션 로그 파일에 대해 강제 플러시 동작을 사용하지 않도록 설정하고 해당 writethroughalternatewritethrough 논리를 사용합니다.

  • 데이터베이스 스냅샷, 데이터베이스 일관성 검사를 위한 내부 스냅샷(DBCC CHECKDB), 프로파일러 추적 파일, 확장 이벤트 추적 파일 등 SQL Server에서 FILE_FLAG_WRITE_THROUGH를 사용하여 여는 다른 파일은 writethroughalternatewritethrough 최적화를 사용합니다.

SQL Server 2017(14.x) CU 6에 도입된 변경 내용에 대한 자세한 내용은 KB 4131496를 참조하세요. FUA(강제 단위 액세스) 내부에 대한 자세한 내용은 FUA 내부를 참조하세요.

SQL Server 및 FUA(Forced Unit Access) I/O 하위 시스템 기능

특정 버전의 지원되는 Linux 배포에서는 FUA I/O 하위 시스템 기능을 지원하여 데이터 내구성을 제공합니다. SQL Server는 FUA 기능을 사용하여 SQL Server 워크로드에 대한 매우 효율적이고 안정적인 I/O를 제공합니다. Linux 배포의 FUA 지원과 SQL Server에 미치는 영향에 대한 자세한 내용은 SQL Server On Linux: FUA(강제 단위 액세스) 내부 항목을 참조하세요.

SUSE Linux Enterprise Server 12 SP5, Red Hat Enterprise Linux 8.0 및 Ubuntu 18.04는 I/O 하위 시스템에서 FUA 기능을 지원합니다. SQL Server 2017(14.x) CU 6 이상 버전을 사용하고 있는 경우 SQL Server에서 FUA를 사용하여 성능이 뛰어나고 효율적인 I/O를 구현하려면 다음 구성을 사용해야 합니다.

다음 조건이 충족되는 경우 권장 구성을 사용합니다.

  • SQL Server 2017 (14.x) CU 6 이상 버전

  • FUA 기능을 지원하는 Linux 배포 및 버전(Red Hat Enterprise Linux 8.0, SUSE Linux Enterprise Server 12 SP5 또는 Ubuntu 18.04부터 시작)

  • SQL Server 스토리지용 XFS 파일 시스템

  • FUA 기능을 지원하고 이 기능용으로 구성된 스토리지 하위 시스템 및/또는 하드웨어

권장 구성:

  1. 추적 플래그 3979를 시작 매개 변수로 사용.

  2. mssql-conf를 사용하여 control.writethrough = 1control.alternatewritethrough = 0 구성.

위의 조건을 충족하지 않는 거의 모든 다른 구성에서 권장되는 구성은 다음과 같습니다.

  1. 추적 플래그 3982를 시작 매개 변수로 사용(Linux 에코시스템의 SQL Server인 경우 기본값)하여 추적 플래그 3979가 시작 매개 변수로 사용되지 않도록 합니다.

  2. mssql-conf를 사용하여 control.writethrough = 1control.alternatewritethrough = 1 구성.

Kubernetes에 배포된 SQL Server 컨테이너에 대한 FUA 지원

  1. SQL Server는 overlayfs가 아닌 지속형 탑재 스토리지를 사용해야 합니다.

  2. 스토리지는 XFS 파일 시스템을 사용해야 하며 FUA를 지원해야 합니다. 이 설정을 사용하도록 설정하기 전에 Linux 배포 및 스토리지 공급업체와 협력하여 OS 및 스토리지 하위 시스템이 FUA 옵션을 지원하는지 확인해야 합니다. Kubernetes에서 다음 명령을 사용하여 파일 시스템 형식을 쿼리할 수 있습니다. 여기서 <pvc-name> 는 다음과 PersistentVolumeClaim같습니다.

    kubectl describe pv <pvc-name>
    

    출력에서 XFS로 설정된 fstype를 찾습니다.

  3. SQL Server Pod를 호스팅하는 작업자 노드는 FUA 기능을 지원하는 Linux 배포 및 버전을 사용해야 합니다(Red Hat Enterprise Linux 8.0, SUSE Linux Enterprise Server 12 SP5 또는 Ubuntu 18.04부터 시작).

위의 조건이 충족되면 다음 권장 FUA 설정을 사용할 수 있습니다.

  1. 추적 플래그 3979를 시작 매개 변수로 사용.

  2. mssql-conf를 사용하여 control.writethrough = 1control.alternatewritethrough = 0 구성.