리눅스
변경 제안
PDF
Linux 운영 체제에만 해당되는 구성 항목
Linux NFSv3 TCP 슬롯 테이블
TCP 슬롯 테이블은 호스트 버스 어댑터(HBA) 큐 길이(queue depth)와 동등한 NFSv3의 기능입니다. 이들 테이블은 한 번에 수행될 수 있는 최대 NFS 작업의 수를 제어합니다. 기본값은 보통 16이며 최적의 성능을 발휘하기에 너무 낮습니다. 최신 Linux 커널에서는 반대의 문제가 발생하는데, 요청을 통해 NFS 서버를 포화시키는 수준까지 TCP 슬롯 테이블의 한계를 자동으로 높일 수 있습니다.
최적의 성능을 얻으면서 성능 문제를 방지하려면 TCP 슬롯 테이블을 제어하는 커널 매개 변수를 조정하십시오.
를 실행합니다 sysctl -a | grep tcp.*.slot_table 명령을 실행하고 다음 매개 변수를 관찰합니다.
# sysctl -a | grep tcp.*.slot_table sunrpc.tcp_max_slot_table_entries = 128 sunrpc.tcp_slot_table_entries = 128
모든 Linux 시스템에는 가 포함되어 있습니다 sunrpc.tcp_slot_table_entries`그러나 일부에만 가 포함됩니다 `sunrpc.tcp_max_slot_table_entries. 둘 다 128로 설정해야 합니다.
| 주의 |
|---|
이러한 매개 변수를 설정하지 않으면 성능에 상당한 영향을 미칠 수 있습니다. 경우에 따라 Linux 운영 체제가 충분한 I/O를 실행하지 않기 때문에 성능이 제한됩니다 또는 Linux 운영 체제가 처리할 수 있는 것보다 더 많은 I/O를 발급하려고 하면 I/O 지연 시간이 늘어납니다. |
Linux NFS 마운트 옵션
다음 표에는 단일 인스턴스의 Linux NFS 마운트 옵션이 나와 있습니다.
| 파일 형식 | 마운트 옵션 |
|---|---|
ADR 홈 |
|
제어 파일 데이터 파일 다시 실행 로그 |
|
ORACLE_HOME |
|
다음 표에는 RAC에 대한 Linux NFS 마운트 옵션이 나와 있습니다.
| 파일 형식 | 마운트 옵션 |
|---|---|
ADR 홈 |
|
제어 파일 데이터 파일 다시 실행 로그 |
|
CRS/투표 |
|
전용 |
|
공유됨 |
|
단일 인스턴스와 RAC 마운트 옵션 간의 주된 차이점은 을 추가한다는 것입니다 actimeo=0 마운트 옵션으로 이동합니다. 이렇게 추가되면 호스트 운영 체제 캐싱이 비활성화되어 RAC 클러스터의 모든 인스턴스에서 데이터 상태에 관한 일관된 뷰를 얻게 됩니다. 를 사용하는 경우에도 마찬가지입니다 init.ora 매개 변수 filesystemio_options=setall 호스트 캐싱이 비활성화되는 것과 동일한 효과가 있으며, 그것도 사용해야 합니다 actimeo=0.
그 이유는 actimeo=0 은(는) 공유에 필요합니다 ORACLE_HOME 배포는 Oracle 암호 파일과 spfile 같은 파일의 일관성을 지원하기 위한 것입니다. RAC 클러스터의 각 인스턴스에 전용 이 있는 경우 `ORACLE_HOME`이 매개 변수는 필요하지 않습니다.
특정 애플리케이션에서는 요구사항이 다를 수 있지만 일반적으로 데이터베이스가 아닌 파일은 단일 인스턴스 데이터 파일에 사용되는 것과 같은 옵션으로 마운트해야 합니다. 마운트 옵션을 사용하지 마십시오 noac 및 actimeo=0 이러한 옵션은 파일 시스템 레벨의 미리 읽기 및 버퍼링을 비활성화하기 때문에 가능한 경우 추출, 변환, 로딩 같은 프로세스에 심각한 성능 문제가 초래될 수 있습니다.
ACCESS 및 GETATTR
ACCESS 및 GETATTR 같은 극히 높은 레벨의 기타 IOPS가 워크로드를 장악할 수 있다는 사실을 깨달은 고객들이 있습니다. 극단적인 경우 그러한 읽기 및 쓰기 작업이 전체 중 10% 남짓할 수 있습니다. 이는 를 포함하는 모든 데이터베이스에서 정상적인 동작입니다 actimeo=0 및/또는 noac 이러한 옵션 덕분에 Linux 운영 체제가 스토리지 시스템에서 파일 메타데이터를 지속적으로 다시 로드하게 되기 때문입니다. ACCESS 및 GETATTR 같은 작업은 데이터베이스 환경에서 ONTAP 캐시로부터 서비스되며 그 영향이 크지 않습니다. 스토리지 시스템에 대한 진정한 수요를 창출하는 읽기 및 쓰기 같은 진정한 IOPS로 간주해서는 안 됩니다. 이러한 기타 IOPS는 특히 RAC 환경에서 약간의 로드를 생성합니다. 이러한 상황을 해결하려면 DNFS를 활성화하여 운영 체제 버퍼 캐시를 우회하고 이 불필요한 메타데이터 작업을 피하십시오.
Linux 직접 NFS
한 가지 추가 마운트 옵션이라고 합니다 nosharecache`는 (a) DNFS가 활성화되고 (b) 소스 볼륨이 단일 서버에 두 번 이상 마운트되며 (c) 중첩된 NFS 마운트가 있는 경우에 필요합니다. 이 구성은 SAP 애플리케이션을 지원하는 환경에서 주로 볼 수 있습니다. 예를 들어, NetApp 시스템의 단일 볼륨의 경우 에 디렉토리가 있을 수 있습니다 `/vol/oracle/base 그리고 에서 두 번째에도 /vol/oracle/home. If(경우 /vol/oracle/base 에 탑재됩니다 /oracle 및 /vol/oracle/home 에 탑재됩니다 `/oracle/home`이 경우 같은 소스에서 NFS 마운트가 중첩됩니다.
운영 체제는 및 /oracle/home 이 같은 볼륨, 즉 소스 파일 시스템에 상주한다는 사실을 감지할 수 /oracle 있으며 같은 장치를 사용하여 데이터에 대한 액세스를 처리합니다. 이렇게 되면 운영 체제 캐싱 사용 및 기타 특정 작업이 개선되나 DNFS에는 지장을 줍니다. DNFS가 에서 /oracle/home 같은 파일에 액세스해야 하는 경우 spfile 데이터에 대한 잘못된 경로를 사용하려 할 수 있으며 그 결과 I/O 작업이 실패합니다. 이러한 구성에서 소스 볼륨을 해당 호스트의 다른 NFS 파일 시스템과 공유하는 NFS 파일 시스템에 마운트 옵션을 추가합니다 nosharecache. 그러면 Linux 운영 체제에서 해당 파일 시스템을 처리할 독립적 장치를 할당하게 됩니다.
Linux Direct NFS 및 Oracle RAC
Linux에는 노드 전체에 걸친 일관성을 위해 RAC에 필요한 직접 I/O를 강제 적용할 방법이 없기 때문에 DNFS를 사용하면 Linux 운영 체제 기반 Oracle RAC에서 특별한 성능 이점을 얻을 수 있습니다. 이를 해결하려면 Linux에서 를 사용해야 합니다 actimeo=0 마운트 옵션을 사용하면 운영 체제 캐시에서 파일 데이터가 즉시 만료됩니다 그러면 이 옵션은 Linux NFS 클라이언트가 특성 데이터를 계속 다시 읽게 강제 적용합니다. 이는 지연 시간을 저하시키고 스토리지 컨트롤러의 로드를 증가시킵니다.
DNFS를 활성화하면 호스트 NFS 클라이언트가 우회되어 이러한 저하가 일어나지 않습니다. 여러 고객의 보고에 따르면, DNFS를 활성화했을 때 RAC 클러스터에서의 성능이 상당히 개선되었고 특히 IOPS와 관련하여 ONTAP 로드가 크게 감소하였다고 합니다.
Linux Direct NFS 및 oranfstab 파일
다중 경로 옵션으로 Linux에서 DNFS를 사용할 때는 여러 서브넷을 사용해야 합니다. 그 외 운영 체제에서는 를 사용하여 여러 DNFS 채널을 설정할 수 있습니다 LOCAL 및 DONTROUTE 단일 서브넷에 여러 DNFS 채널을 구성하는 옵션입니다. 하지만 이 방법은 Linux에서 제대로 작동하지 않을 수 있고 예기치 않은 성능 문제가 초래될 수 있습니다. Linux에서는 DNFS 트래픽을 위해 사용되는 각 NIC가 다른 서브넷에 있어야 합니다.
I/O 스케줄러
Linux 커널은 블록 장치의 I/O를 스케줄링하여 낮은 레벨의 제어를 허용합니다. Linux의 다양한 배포 방식에서는 여러 가지의 기본값을 사용할 수 있습니다. 테스트에 의하면 Deadline이 보통 최상의 결과를 제공하지만 NOOP에서 성능이 더 높은 경우도 간혹 있었습니다. 성능 차이는 크지 않으나 데이터베이스 구성에서 최대한의 성능을 끌어내려면 필요 시 두 옵션을 모두 테스트하십시오. 대다수 구성은 CFQ를 기본값으로 하며, 데이터베이스 워크로드에서 심각한 성능 문제가 발생한다는 사실이 입증되었습니다.
I/O 스케줄러 구성에 관한 관련 Linux 공급업체 설명서의 지침을 참조하십시오.
다중 경로
어떤 고객은 다중 경로 데몬이 시스템에서 실행되지 않아 네트워크 중단 시 충돌이 발생하였습니다. Linux 최신 버전에서는 운영 체제 설치 프로세스와 다중 경로 데몬에 의해 운영 체제가 이 문제에 취약해질 수 있습니다. 패키지는 올바르게 설치되나 재부팅 후 자동 시동되도록 구성되지 않습니다.
예를 들어, RHEL5.5에서 다중 경로 데몬의 기본값은 다음과 같이 나타날 수 있습니다.
[root@host1 iscsi]# chkconfig --list | grep multipath multipathd 0:off 1:off 2:off 3:off 4:off 5:off 6:off
다음과 같은 명령으로 이를 수정할 수 있습니다.
[root@host1 iscsi]# chkconfig multipathd on [root@host1 iscsi]# chkconfig --list | grep multipath multipathd 0:off 1:off 2:on 3:on 4:on 5:on 6:off
ASM 미러링
ASM 미러링은 ASM이 문제를 인식하고 대체 장애 그룹으로 전환할 수 있도록 Linux 다중 경로 설정을 변경해야 할 수 있습니다. ONTAP의 대다수 ASM 구성은 외부 이중화를 사용하는데, 이는 외부 어레이를 통해 데이터가 보호되고 ASM은 데이터를 미러링하지 않는다는 뜻입니다. 일부 사이트는 ASM에서 일반적인 수준의 이중화를 사용하며 일반적으로 여러 사이트에 걸쳐 양방향 미러링을 제공합니다.
에 나와 있는 Linux 설정입니다 "NetApp Host Utilities 설명서" I/O의 무한 대기를 야기하는 다중 경로 매개 변수를 포함하십시오 즉, 액티브 경로가 없는 LUN 장치의 I/O가 I/O가 완료될 때까지 큐에서 대기합니다. Linux 호스트가 SAN 경로 변경이 완료될 때까지, FC 스위치가 재부팅될 때까지, 또는 스토리지 시스템의 페일오버가 완료될 때까지 대기하기 때문에 이는 일반적으로 바람직한 방식입니다.
무제한 큐잉 동작은 ASM 미러링에 문제를 발생시키는데, 대체 LUN에서 I/O를 재시도하려면 ASM이 I/O 장애를 수신해야 하기 때문입니다.
Linux에서 다음 매개 변수를 설정합니다 multipath.conf ASM 미러링과 함께 사용되는 ASM LUN용 파일:
polling_interval 5 no_path_retry 24
이들 설정은 ASM 장치의 시간 초과 값을 120초로 만듭니다. 시간 초과는 로 계산됩니다 polling_interval * no_path_retry 초 단위로 표시합니다. 정확한 값을 위해 조정이 필요할 때도 있지만 대부분의 경우에는 120초 시간 초과로 충분합니다. 특히, 장애 그룹을 오프라인 상태로 만들어버리는 I/O를 생성하지 않고 120초 동안 컨트롤러가 테이크오버 또는 반환을 수행할 수 있어야 합니다.
더 낮아졌습니다 no_path_retry 값을 지정하면 ASM이 대체 장애 그룹으로 전환하는 데 필요한 시간을 단축할 수 있지만 이렇게 하면 컨트롤러 테이크오버 같은 유지보수 활동 중에 원치 않는 페일오버 위험이 증가합니다. 이러한 위험은 ASM 미러링 상태를 주의 깊게 모니터링하여 완화할 수 있습니다. 원치 않는 페일오버가 발생한 경우에도 재동기화가 상대적으로 빠르게 수행된다면 미러링이 신속하게 재동기화됩니다. 추가 정보는 사용 중인 Oracle 소프트웨어 버전의 ASM 빠른 미러 재동기화에 관한 Oracle 설명서를 참조하십시오.
Linux xfs, ext3 및 ext4 마운트 옵션
|
* NetApp는 기본 마운트 옵션을 사용하여 * 를 권장합니다. |