Azure NetApp Files 다중 볼륨의 Oracle 데이터베이스 성능

  • 아티클

성능이 뛰어난 Exadata 등급 데이터베이스를 클라우드로 마이그레이션하는 일이 Microsoft 고객에게는 점점 더 중요해지고 있습니다. 공급망 소프트웨어 도구 모음은 단일 컴퓨팅 노드에서 구동되는 읽기/쓰기 워크로드가 혼합된 스토리지 I/O에 대한 수요가 많기 때문에 일반적으로 기준을 높게 설정합니다. Azure NetApp Files와 함께 Azure 인프라를 사용하면 매우 까다로운 이 워크로드의 요구를 충족할 수 있습니다. 이 문서에는 한 고객의 이 요구 사항을 어떻게 충족했는지, Azure가 중요한 Oracle 워크로드의 요구 사항을 어떻게 충족할 수 있는지에 관한 예제가 나와 있습니다.

엔터프라이즈 규모 Oracle 성능

성능의 상한을 탐색할 때는 결과를 거짓으로 왜곡할 수 있는 제약 조건을 인식하고 줄이는 것이 중요합니다. 예를 들어 스토리지 시스템의 성능 기능을 입증하려는 경우, 스토리지 성능 제한에 도달하기 전에 CPU가 완화 요인이 되지 않도록 클라이언트를 구성하는 것이 이상적입니다. 이 VM에는 100Gbps의 네트워크 인터페이스뿐만 아니라 똑같이 큰(100Gbps) 송신 제한이 있으므로, 성능을 입증하기 위해 E104ids_v5 인스턴스 유형으로 테스트를 시작했습니다.

테스트는 다음의 두 단계로 진행했습니다.

  1. 첫 번째 단계는 Kevin Closson의 현재 업계 표준 SLOB2(Silly Little Oracle Benchmark) 도구 - 버전 2.5.4를 사용해 테스트하는 데 중점을 두었습니다. 목표는 한 VM(가상 머신)에서 여러 Azure NetApp Files 볼륨으로 최대한 많은 Oracle I/O를 구동한 다음, 더 많은 데이터베이스를 사용해 스케일 아웃함으로써 선형 스케일링을 시연하는 데 있습니다.
  2. 스케일링 한도를 테스트한 후 실제 공급망 애플리케이션 워크로드와 실제 데이터를 사용해 고객 테스트 단계에서 저렴하지만 성능은 거의 비슷한 E96ds_v5로 테스트를 전환했습니다.

SLOB2 스케일 업 성능

다음 차트는 스토리지 엔드포인트가 8개인 Azure NetApp Files 볼륨 8개에 대해 단 하나의 Oracle 19c 데이터베이스를 실행하는 E104ids_v5 Azure VM 한 개의 성능 프로필을 캡처한 것입니다. 볼륨은 데이터, 로그, 보관의 세 가지 ASM 디스크 그룹에 분산됩니다. 데이터 디스크 그룹에 볼륨 5개, 로그 디스크 그룹에 볼륨 2개, 보관 디스크 그룹에 볼륨 1개가 할당되었습니다. 이 문서 전반에 걸쳐 나와 있는 모든 결과는 프로덕션 Azure 지역과 활성 프로덕션 Azure 서비스를 사용하여 수집했습니다.

여러 스토리지 엔드포인트에서 여러 Azure NetApp Files 볼륨을 사용하여 Azure Virtual Machines에 Oracle을 배포하려면 Oracle용 애플리케이션 볼륨 그룹을 사용합니다.

단일 호스트 아키텍처

다음 다이어그램은 테스트가 완료된 아키텍처를 보여 줍니다. Oracle 데이터베이스는 여러 Azure NetApp Files 볼륨과 엔드포인트에 분산되어 있습니다.

Azure NetApp Files 용량 풀이 있는 Oracle 서브넷의 다이어그램.

단일 호스트 스토리지 IO

다음 다이어그램은 데이터베이스 버퍼 적중률이 약 8%인 100% 임의로 선택된 워크로드를 보여 줍니다. SLOB2는 밀리 초 미만으로 DB 파일 순차 읽기 이벤트 대기 시간을 유지하면서 초당 약 850,000개의 I/O 요청을 구동할 수 있었습니다. 데이터베이스 블록 크기는 약 6,800MiB/s의 스토리지 처리량에 해당하는 8K입니다.

단일 호스트 임의 스토리지 I/O를 보여 주는 차트.

단일 호스트 처리량

다음 다이어그램은 전체 테이블 검색 또는 RMAN 활동과 같이 대역폭을 많이 사용하는 순차 IO 워크로드의 경우 Azure NetApp Files를 통해 E104ids_v5 VM 자체의 전체 대역폭 기능을 제공할 수 있음을 보여 줍니다.

단일 호스트 순차 처리량을 보여 주는 막대형 차트.

참고 항목

컴퓨팅 인스턴스가 이론상 최대 대역폭에 있으므로 애플리케이션 동시성을 추가하면 클라이언트 쪽 대기 시간만 증가합니다. 이로 인해 SLOB2 워크로드가 목표 완료 기간을 초과하기 때문에 스레드 수가 6개로 제한되었습니다.

SLOB2 스케일 아웃 성능

다음 차트는 스케일 업 성능 섹션에 설명된 대로 각각 단일 Oracle 19c 데이터베이스를 실행하고 자체 Azure NetApp Files 볼륨 세트와 동일한 ASM 디스크 그룹 레이아웃을 사용하는 E104ids_v5 Azure VM 세 개의 성능 프로필을 캡처한 것입니다. 그래픽은 Azure NetApp Files 다중 볼륨/다중 엔드포인트를 사용하면 일관성과 예측 가능성으로 성능이 쉽게 스케일 아웃됨을 보여 줍니다.

다중 호스트 아키텍처

다음 다이어그램은 테스트가 완료된 아키텍처를 보여 줍니다. 세 개의 Oracle 데이터베이스가 여러 Azure NetApp Files 볼륨과 엔드포인트에 분산되어 있습니다. 엔드포인트는 Oracle VM 1과 같이 단일 호스트 전용으로 사용하거나, Oracle VM2와 Oracle VM 3처럼 호스트 간에 공유할 수 있습니다.

Azure NetApp Files에 대한 Oracle 자동 스토리지 관리 다이어그램.

다중 호스트 스토리지 IO

다음 다이어그램은 데이터베이스 버퍼 적중률이 약 8%인 100% 임의로 선택된 워크로드를 보여 줍니다. SLOB2는 세 호스트 모두 개별적으로 초당 약 850,000개의 I/O 요청을 구동할 수 있었습니다. SLOB2는 각 호스트에서 밀리 초 미만으로 db 파일 순차 읽기 이벤트 대기 시간을 계속 유지하고 초당 총 약 2,500,000개의 I/O 요청을 동시에 실행하면서 이 작업을 수행할 수 있었습니다. 데이터베이스 블록 크기가 8K인 경우, 이 크기는 세 호스트 간에 약 20,000MiB/s에 해당합니다.

IO 관점에서 본 집단 임의 스토리지의 꺾은선형 그래프.

다중 호스트 처리량

다음 다이어그램은 순차 워크로드의 경우 Azure NetApp Files를 통해 스케일 아웃되더라도 E104ids_v5 VM 자체의 전체 대역폭 기능을 계속 제공할 수 있음을 보여 줍니다. SLOB2는 동시에 실행하는 동안 세 호스트에서 총 30,000MiB/s가 넘는 I/O를 구동할 수 있었습니다.

집단 순차 처리량의 누적 가로 막대형 차트.

실제 성능

SLOB2를 통해 스케일링 한도를 테스트한 후 결과가 우수한 Azure NetApp Files의 Oracle에서 실제 공급망 애플리케이션 도구 모음을 사용하여 테스트를 수행했습니다. Oracle AWR(Automatic Workload Repository) 보고서의 다음 데이터는 한 가지 중요한 특정 작업이 수행된 방식을 강조하여 보여 줍니다.

이 데이터베이스는 플래시백 사용으로 인한 애플리케이션 워크로드 외에도 상당한 추가 IO가 발생하며 데이터베이스 블록 크기가 16k입니다. AWR 보고서의 IO 프로필 섹션을 보면 읽기에 비해 쓰기 비율이 매우 높은 것이 분명합니다.

- 초당 읽기/쓰기 초당 읽기 초당 쓰기
합계(MB) 4,988.1 1,395.2 3,592.9

DB 파일 순차 읽기 대기 이벤트에서 SLOB2 테스트보다 대기 시간이 2.2ms 더 높게 나타남에도 불구하고 이 고객은 Exadata의 RAC 데이터베이스에서 Azure의 단일 인스턴스 데이터베이스로 이동하는 작업의 실행 시간이 15분 단축됨을 확인했습니다.

Azure 리소스 제약 조건

결국 모든 시스템은 전통적으로 초크포인트라고 알려진 리소스 제약 조건에 직면하게 됩니다. 특히 공급망 애플리케이션 도구 모음과 같이 매우 까다로운 데이터베이스 워크로드는 리소스를 많이 사용하는 엔터티입니다. 이러한 리소스 제약 조건을 찾아서 해결하는 것이 성공적인 배포에 매우 중요합니다. 이 섹션에서는 이러한 환경에서 직면할 수도 있는 다양한 제약 조건과 이를 해결하는 방법을 설명합니다. 각 하위 섹션에서는 모범 사례와 그 이면의 근거를 모두 배울 수 있습니다.

가상 머신

이 섹션에서는 최상의 성능을 제공하기 위해 VM 선택 시 고려해야 할 조건과 테스트하기 위해 선택한 근거에 대해 자세히 설명합니다. Azure NetApp Files는 NAS(Network Attached Storage) 서비스이므로, 최적의 성능을 제공하기 위해서는 네트워크 대역폭의 크기를 적절하게 조정하는 것이 중요합니다.

칩셋

첫 번째 관심 항목은 칩셋 선택입니다. 선택한 VM SKU가 일관성을 이유로 단일 칩셋에 빌드되었는지 확인합니다. E_v5 VM의 Intel 변형은 3세대 Intel Xeon Platinum 8370C(Ice Lake) 구성에서 실행됩니다. 이 제품군의 모든 VM에는 100Gbps의 단일 네트워크 인터페이스가 장착되어 있습니다. 그에 반해 E_v3 시리즈를 예로 들면, 물리적 네트워크 대역폭이 다양한 개별 칩셋 4개 위에 빌드됩니다. E_v3 제품군(Broadwell, Skylake, Cascade Lake, Haswell)에 사용되는 네 가지 칩셋은 컴퓨터의 성능 특성에 영향을 주는 프로세서 속도가 다양합니다.

칩셋 옵션에 각별히 주의를 기울여 Azure Compute 설명서를 읽어 보세요. 또한 Azure NetApp Files에 대한 Azure VM SKU 모범 사례를 참조하세요. 일관성을 가장 잘 유지하려면 단일 칩셋이 있는 VM을 선택하는 것이 좋습니다.

사용 가능한 네트워크 대역폭

사용 가능한 VM 네트워크 인터페이스 대역폭과 동일한 인터페이스에 적용되는 데이터 대역폭 간의 차이점을 이해하는 것이 중요합니다. Azure Compute 설명서에서 네트워크 대역폭 제한을 언급하는 경우 이러한 제한은 송신(쓰기)에만 적용됩니다. 수신(읽기) 트래픽은 측정되지 않으므로 NIC 자체의 물리적 대역폭에 의해서만 제한됩니다. 대다수 VM의 네트워크 대역폭은 컴퓨터에 적용되는 송신 제한을 초과합니다.

Azure NetApp Files 볼륨이 네트워크에 연결되어 있어 송신 제한이 특히 쓰기에 적용되는 것으로 이해할 수 있지만, 수신은 읽기 및 읽기와 유사한 워크로드로 정의됩니다. 대다수 컴퓨터의 송신 제한이 NIC의 네트워크 대역폭보다 큰 반면, 이 문서의 테스트에 사용된 E104_v5는 이와 다릅니다. E104_v5에는 송신 제한이 100Gbps로 설정된 100Gbps NIC가 있습니다. 이에 비해 100Gbps NIC가 포함된 E96_v5는 송신이 35Gbps에서 제한되지만 수신은 100Gbps에서 제한되지 않습니다. VM의 크기가 감소하면 송신 제한이 감소하지만 수신은 논리적으로 부과된 제한에 의해 제약 없이 유지됩니다.

송신 제한은 VM 전반을 아우르며 모든 네트워크 기반 워크로드에 적용됩니다. Oracle Data Guard를 사용하는 경우 모든 쓰기는 보관 로그의 두 배가 되므로 송신 제한 고려 사항을 감안해야 합니다. 대상과 RMAN이 여럿 있는 보관 로그(사용되는 경우) 또한 마찬가지입니다. VM을 선택할 때 Azure는 네트워크 인터페이스 구성을 문서화하지 않으므로 NIC의 구성을 노출하는 ethtool 같은 명령줄 도구를 숙지합니다.

네트워크 동시성

Azure VM 및 Azure NetApp Files 볼륨은 특정한 용량의 대역폭을 갖추고 있습니다. 앞에서 설명한 바와 같이 VM에 CPU 헤드룸이 충분히 있는 한, 이론적으로는 워크로드가 네트워크 카드 제한 및/또는 적용된 송신 제한 내에서 사용 가능한 대역폭을 소비할 수 있습니다. 그러나 실제로 달성 가능한 처리량은 네트워크에서의 워크로드 동시성, 즉 네트워크 흐름과 네트워크 엔드포인트의 수에 따라 결정됩니다.

자세한 내용은 VM 네트워크 대역폭 문서의 네트워크 흐름 제한 섹션을 참조하세요. 요약: 클라이언트를 스토리지에 연결하는 네트워크 흐름이 많을수록 잠재적 성능이 향상됩니다.

Oracle은 커널 NFS와 dNFS(Direct NFS)의 별도 NFS 클라이언트 두 가지를 지원합니다. 커널 NFS는 늦게까지 두 엔드포인트(컴퓨팅 – 스토리지) 간에 단일 네트워크 흐름을 지원했습니다. 둘 중 성능이 더 좋은 Direct NFS는 다양한 개수의 네트워크 흐름을 지원합니다. 테스트 시 엔드포인트당 수백 개의 고유한 연결이 나타났으며 부하 요구에 따라 증가하거나 감소했습니다. 두 엔드포인트 간의 네트워크 흐름이 확장되기 때문에 Direct NFS가 커널 NFS보다 훨씬 선호되며, 권장되는 구성입니다. Azure NetApp Files 제품 그룹은 Oracle 워크로드와 함께 커널 NFS를 사용하지 않는 것이 좋습니다. 자세한 내용은 Oracle Database에서 Azure NetApp Files를 사용할 경우의 이점을 참조하세요.

실행 동시성

일관성을 얻기 위해 단일 칩셋인 Direct NFS를 활용하고 네트워크 대역폭 제약 조건을 이해하는 것만으로는 한계가 있습니다. 결국 애플리케이션이 성능을 이끌어 냅니다. SLOB2를 사용한 개념 증명과 실제 고객 데이터에 대해 실제 공급망 애플리케이션 도구 모음을 사용한 개념 증명은 애플리케이션이 높은 수준의 동시성으로 실행되었기 때문에 상당한 양의 처리량을 이끌어 낼 수 있었습니다. 전자는 스키마별로 상당수의 스레드를 사용하고, 후자는 여러 애플리케이션 서버에서 여러 연결을 사용합니다. 즉, 동시성은 똑같이 지원하기 위한 인프라가 갖춰져 있는 한 워크로드, 낮은 동시성--낮은 처리량, 높은 동시성--높은 처리량을 만들어 냅니다.

가속된 네트워킹

가속화된 네트워킹을 사용하면 VM에 대한 단일 루트 I/O 가상화(SR-IOV)를 구현할 수 있어 네트워킹 성능이 크게 향상됩니다. 이 고성능 경로는 데이터 경로에서 호스트를 우회함으로써 지원되는 VM 유형에서 가장 까다로운 네트워크 워크로드에 대한 대기 시간, 지터 및 CPU 사용률을 줄입니다. terraform이나 명령줄 같은 구성 관리 유틸리티를 통해 VM을 배포하는 경우 기본적으로 가속화된 네트워킹은 사용되지 않습니다. 성능을 최적화하려면 가속화된 네트워킹을 사용합니다. 네트워크 인터페이스를 기준으로 네트워크 인터페이스에서 가속화된 네트워킹을 사용하거나 사용하지 않도록 합니다. 가속화된 네트워킹 기능은 동적으로 사용할 수도, 사용하지 않을 수도 있는 기능입니다.

참고 항목

이 문서에는 Microsoft에서 더 이상 사용하지 않는 용어인 SLAVE에 대한 참조가 포함되어 있습니다. 소프트웨어에서 용어가 제거되면 이 문서에서 해당 용어가 제거됩니다.

NIC에 가속화된 네트워킹을 사용하기 위한 권한 있는 접근 방식은 Linux 터미널을 통하는 것입니다. NIC에 가속화된 네트워킹을 사용하면 첫 번째 NIC와 연결된 두 번째 가상 NIC가 표시됩니다. 이 두 번째 NIC는 SLAVE 플래그가 사용되는 시스템에서 구성합니다. SLAVE 플래그를 사용하는 NIC가 없으면 해당 인터페이스에 가속화된 네트워킹을 사용할 수 없습니다.

NIC가 여러 개 구성된 시나리오에서는 NFS 볼륨을 탑재하는 데 사용되는 NIC와 연결된 SLAVE 인터페이스를 결정해야 합니다. VM에 네트워크 인터페이스 카드를 추가해도 성능에 영향을 주지는 않습니다.

다음 프로세스를 사용하여 구성된 네트워크 인터페이스와 연결된 가상 인터페이스 간의 매핑을 식별합니다. 이 프로세스는 Linux 컴퓨터의 특정 NIC에 가속화된 네트워킹이 사용되는지 확인하고, NIC가 잠재적으로 달성할 수 있는 물리적 수신 속도를 표시합니다.

  1. ip a 명령을 실행합니다. ip a 명령 출력 스크린샷.
  2. 확인 중인 NIC ID /sys/class/net/ 디렉터리(예에서 eth0)와 아래 단어의 grep을 나열합니다. 
    ls /sys/class/net/eth0 | grep lower lower_eth1
  3. 이전 단계에서 하위 디바이스로 식별된 이더넷 디바이스에 대해 ethtool 명령을 실행합니다. eth1 설정 출력 스크린샷.

Azure VM: 네트워크 제한과 디스크 대역폭 제한의 비교

Azure VM 성능 제한 설명서를 읽으려면 일정 수준의 전문 지식이 필요합니다. 다음을 알고 있어야 합니다.

  • 임시 스토리지 처리량 및 IOPS 번호는 VM에 직접 연결된 임시 온박스 스토리지의 성능 기능을 나타냅니다.
  • 캐시되지 않은 디스크 처리량 및 I/O 번호는 특히 Azure Disk(Premium, Premium v2, Ultra)를 참조하며 Azure NetApp Files 같은 네트워크 연결 스토리지에 아무런 영향을 주지 않습니다.
  • VM에 추가 NIC를 연결해도 VM의 성능 제한 또는 성능 기능에 영향을 주지 않습니다(문서화되고 true로 테스트됨).
  • 최대 네트워크 대역폭은 VM 네트워크 대역폭에 적용되는 송신 제한(즉, Azure NetApp Files가 관련된 경우 쓰기)을 나타냅니다. 수신 제한(즉, Azure NetApp Files가 관련된 경우 읽기)은 적용되지 않습니다. 충분한 CPU, 충분한 네트워크 동시성, 풍부한 엔드포인트가 주어지면 VM에서 이론적으로 NIC 한도까지 수신 트래픽을 구동할 수 있습니다. 사용 가능한 네트워크 대역폭 섹션에서 설명한 대로 ethtool 등의 도구를 사용하여 NIC 대역폭을 확인합니다.

참조용 샘플 차트가 나와 있습니다.

샘플 차트 데이터를 보여 주는 테이블 스크린샷.

Azure NetApp Files

Azure 자사 스토리지 서비스인 Azure NetApp Files는 앞서 소개한 까다로운 Oracle 워크로드를 지원할 수 있는 고가용성 완전 관리형 스토리지 솔루션을 제공합니다.

Oracle 데이터베이스의 스케일 업 스토리지 성능 한계는 잘 알려져 있으므로 이 문서는 의도적으로 스케일 아웃 스토리지 성능에 중점을 둡니다. 스토리지 성능을 스케일 아웃한다는 것은 해당 볼륨이 여러 스토리지 엔드포인트에 분산된 많은 Azure NetApp Files 볼륨에 단 하나의 Oracle 인스턴스 액세스 권한을 제공함을 의미합니다.

이러한 방식으로 여러 볼륨에서 데이터베이스 워크로드를 스케일링하면 데이터베이스의 성능이 볼륨/엔드포인트 상한에서 모두 벗어나게 됩니다. 스토리지에 더 이상 성능 제한을 두지 않으면 VM 아키텍처(CPU, NIC, VM 송신 제한)가 해결해야 할 관문이 됩니다. VM 섹션에서 설명한 대로 E104ids_v5 및 E96ds_v5 인스턴스는 이를 염두에 두고 선택했습니다.

데이터베이스가 단일 대용량 볼륨에 배치되어 있든, 여러 개의 소규모 볼륨에 분산되어 있든 상관없이 총 재무 비용은 동일합니다. 단일 볼륨/엔드포인트와 다르게 여러 볼륨/엔드포인트에 I/O를 배포할 경우 얻는 이점은 대역폭 제한이 없다는 점입니다. 즉, 비용을 지불하는 만큼 사용할 수 있습니다.

Important

multiple volume:multiple endpoint 구성에서 Azure NetApp Files를 사용하여 배포하려면 Azure NetApp Files 전문가 또는 클라우드 솔루션 설계자에게 문의하여 도움을 받으세요.

데이터베이스

Oracle의 데이터베이스 버전 19c는 Oracle의 현재 장기 릴리스 버전으로, 이 문서에서 설명하는 모든 테스트 결과를 생성하는 데 사용되었습니다.

최상의 성능을 제공하기 위해 모든 데이터베이스 볼륨이 Direct NFS를 사용해 탑재되었으며, 성능 제약 조건이 있으므로 커널 NFS를 사용하는 것이 좋습니다. 두 클라이언트 간의 성능 비교는 Azure NetApp Files 단일 볼륨의 Oracle 데이터베이스 성능을 참조하세요. Azure NetApp Files 보고서를 사용하여 Microsoft Azure의 Oracle Database에 개괄된 모범 사례와 마찬가지로 관련된 모든 dNFS 패치(Oracle 지원 ID 1495104)가 적용되었습니다.

Oracle 및 Azure NetApp Files는 NFSv3, NFSv4.1을 모두 지원하지만 NFSv3는 더 성숙한 프로토콜이므로, 일반적으로 가장 안정성 있는 것으로 간주되며 중단에 매우 민감한 환경에서 사용하기에 더욱 안정적인 옵션입니다. 이 문서에 설명된 테스트는 모두 NFSv3을 통해 완료되었습니다.

Important

Oracle이 지원 ID 1495104에 문서화한 권장 패치 중 일부는 dNFS 사용 시 데이터 무결성을 유지하는 데 중요합니다. 프로덕션 환경에서는 이러한 패치를 적용하는 것이 좋습니다.

ASM(Microsoft Azure Storage)은 NFS 볼륨을 지원합니다. 일반적으로 ASM은 LVM(논리 볼륨 관리)과 파일 시스템을 모두 대체하는 블록 기반 스토리지와 연결되지만, ASM은 다중 볼륨 NFS 시나리오에서 중요한 역할을 하므로 강력하게 고려할 만한 가치가 있습니다. 이러한 ASM의 이점 중 하나인 새로 추가된 NFS 볼륨과 엔드포인트에 대한 동적 온라인 추가 및 리밸런스 기능은 관리를 간소화하여 성능과 용량을 모두 원하는 대로 확장할 수 있습니다. ASM이 그 자체로 데이터베이스의 성능을 향상시키지는 않지만, 사용하면 핫 파일이 없어도 되고 파일 배포를 수동으로 유지 관리할 필요가 없어 쉽게 확인할 수 있다는 이점이 있습니다.

dNFS를 통한 ASM 구성은 이 문서에서 설명하는 모든 테스트 결과를 생성하는 데 사용되었습니다. 다음 다이어그램은 Azure NetApp Files 볼륨 내 ASM 파일 레이아웃과 ASM 디스크 그룹의 파일 할당을 보여 줍니다.

Azure NetApp Files를 사용한 Oracle 자동 스토리지 관리 다이어그램

특정 아키텍처 고려 사항으로 해결할 수 있는 스토리지 스냅샷의 경우 Azure NetApp Files NFS 탑재 볼륨을 통해 ASM을 사용할 때 몇 가지 제한 사항이 있습니다. 이러한 고려 사항에 대한 심층적인 검토는 Azure NetApp Files 전문가 또는 클라우드 솔루션 설계자에게 문의하세요.

가상 테스트 도구 및 튜닝 가능 항목

이 섹션에서는 구체적인 테스트 아키텍처와 튜닝 가능 항목, 구성 세부 정보를 설명합니다. 이전 섹션은 구성 결정을 내리는 이유에 초점을 맞추었지만, 이 섹션에서는 특히 구성 결정의 "내용"에 중점을 둡니다.

자동화된 배포

  • 데이터베이스 VM은 GitHub에서 사용할 수 있는 bash 스크립트를 사용하여 배포됩니다.
  • 여러 Azure NetApp Files 볼륨 및 엔드포인트의 레이아웃과 할당 작업은 수동으로 완료됩니다. 도움을 받으려면 Azure NetApp Files 전문가 또는 클라우드 솔루션 설계자와 협력해야 합니다.
  • 각 컴퓨터의 SLOB2 환경 및 그리드 설치, ASM 구성, 데이터베이스 만들기/구성 작업은 일관성을 유지하기 위해 Ansible을 사용하여 구성됩니다.
  • 여러 호스트에서 동시에 SLOB2 테스트를 실행하는 경우에도 일관성을 유지하고 동시에 실행하기 위해 Ansible을 사용하여 완료됩니다.

VM 구성

구성 값
Azure 지역 서유럽
VM SKU E104ids_v5
NIC 수 1개, 참고: vNIC를 추가해도 시스템 수에는 영향을 주지 않습니다.
최대 송신 네트워킹 대역폭(Mbps) 100,000
임시 스토리지(SSD) GiB 3,800

시스템 구성

Oracle 설명서에 따라 버전 19c의 Oracle 필수 시스템 구성 설정이 모두 구현되었습니다.

다음 매개 변수가 /etc/sysctl.conf Linux 시스템 파일에 추가되었습니다.

  • sunrpc.max_tcp_slot_table_entries: 128
  • sunrpc.tcp_slot_table_entries = 128

Azure NetApp Files

모든 Azure NetApp Files 볼륨은 다음과 같은 NFS 탑재 옵션을 사용하여 탑재되었습니다.

nfs rw,hard,rsize=262144,wsize=262144,sec=sys,vers=3,tcp

데이터베이스 매개 변수

매개 변수 값
db_cache_size 2g
large_pool_size 2g
pga_aggregate_target 3g
pga_aggregate_limit 3g
sga_target 25g
shared_io_pool_size 500m
shared_pool_size 5g
db_files 500
filesystemio_options SETALL
job_queue_processes 0
db_flash_cache_size 0
_cursor_obsolete_threshold 130
_db_block_prefetch_limit 0
_db_block_prefetch_quota 0
_db_file_noncontig_mblock_read_count 0

SLOB2 구성

테스트용 워크로드 생성 작업은 모두 SLOB2 도구 버전 2.5.4를 사용하여 완료되었습니다.

SLOB2 스키마 14개가 표준 Oracle 테이블스페이스에 로드되어 실행되었으며, 나열된 슬롭 구성 파일 설정과 함께 SLOB2 데이터 세트가 7TiB에 배치되었습니다. 다음 설정은 SLOB2에 대한 임의 읽기 실행을 반영합니다. SCAN_PCT=0 구성 매개 변수가 순차 테스트 중에 SCAN_PCT=100으로 변경되었습니다.

  • UPDATE_PCT=0
  • SCAN_PCT=0
  • RUN_TIME=600
  • SCALE=450G
  • SCAN_TABLE_SZ=50G
  • WORK_UNIT=32
  • REDO_STRESS=LITE
  • THREADS_PER_SCHEMA=1
  • DATABASE_STATISTICS_TYPE=awr

임의 읽기 테스트에서 SLOB2가 아홉 번 실행되었습니다. 스레드 수는 1부터 시작하는 각 테스트가 반복될 때마다 6개씩 증가했습니다.

순차적으로 테스트하기 위해 SLOB2가 일곱 번 실행되었습니다. 스레드 수는 1부터 시작하는 각 테스트가 반복될 때마다 2개씩 증가했습니다. 네트워크 대역폭 최대 한도에 도달하여 스레드 수가 6개로 제한되었습니다.

AWR 메트릭

모든 성능 메트릭은 Oracle AWR(Automatic Workload Repository)을 통해 보고되었습니다. 결과에 표시되는 메트릭은 다음과 같습니다.

  • 처리량: AWR 부하 프로필 섹션의 평균 읽기 처리량/쓰기 처리량 합계
  • AWR 부하 프로필 섹션의 평균 읽기 IO 요청
  • AWR 전경 대기 이벤트 섹션의 db 파일 순차 읽기 대기 이벤트 평균 대기 시간

특별히 빌드된 엔지니어링된 시스템에서 클라우드로 마이그레이션

Oracle Exadata는 Oracle 워크로드를 실행하는 데 가장 최적화된 솔루션으로 간주되는 하드웨어와 소프트웨어의 조합인 엔지니어링 시스템입니다. 클라우드는 기술 세계의 전반적인 체계에서 많은 장점을 갖고 있지만, Oracle이 특정 워크로드를 중심으로 빌드한 최적화 기능을 읽고 본 사용자에게 이러한 특수 시스템은 매우 매력적으로 보일 수 있습니다.

Exadata에서 Oracle을 실행하는 경우 Exadata를 선택하는 일반적인 이유가 몇 가지 있습니다.

  • Exadata 기능에 딱 알맞은 1~2개의 높은 IO 워크로드, 이러한 워크로드에는 상당한 Exadata 엔지니어링 기능이 필요하기 때문에 함께 실행되는 나머지 데이터베이스가 Exadata에 통합됨
  • RAC의 규모를 조정해야 하고 Oracle 최적화에 대한 깊이 있는 지식 없이 독점 하드웨어로 설계하기 어려운, 복잡하거나 까다로운 OLTP 워크로드 또는 최적화할 수 없는 기술적인 문제가 있을 수도 있음
  • 다양한 워크로드가 있고 활용도가 낮은 기존 Exadata: 이전 마이그레이션, 이전 Exadata의 수명 종료 또는 사내 Exadata를 작업/테스트하려는 욕구로 인해 존재

Exadata 시스템에서 마이그레이션하는 경우 워크로드의 관점과 마이그레이션의 단순성 또는 복잡성을 이해해야 합니다. 두 번째 요구 사항은 상태 관점에서 Exadata 구매 이유를 파악하는 것입니다. Exadata 및 RAC 기술이 수요가 더 많고, 기술 관계자가 구매하도록 권장했을 수도 있습니다.

Important

시나리오에 관계없이 전체적인 요점은 Exadata에서 들어오는 모든 데이터베이스 워크로드의 경우 Exadata 독점 기능을 더 많이 사용할수록 마이그레이션과 계획이 더 복잡해진다는 것입니다. Exadata 독점 기능을 많이 활용하지 않는 환경에서는 더 간단한 마이그레이션/계획 프로세스를 사용해 볼 기회가 있습니다.

이러한 워크로드 기회를 평가하는 데 사용할 수 있는 도구가 몇 가지 있습니다.

  • AWR(Automatic Workload Repository):
    • 모든 Exadata 데이터베이스에는 AWR 보고서, 연결된 성능 및 진단 기능을 사용할 수 있는 라이선스가 부여됩니다.
    • 항상 켜져 있으며, 기록 워크로드 정보를 확인하고 사용량을 평가하는 데 사용될 수 있는 데이터를 수집합니다. 최고 값으로 시스템의 높은 사용량을 평가할 수 있습니다.
    • 더 큰 창의 AWR 보고서에서는 전반적인 워크로드를 평가하여 기능 사용과 Exadata가 아닌 시스템에 워크로드를 효율적으로 마이그레이션하는 방법에 대한 유용한 인사이트를 제공할 수 있습니다. 반면에 AWR 최고치 보고서는 성능을 최적화하고 문제를 해결하는 데 가장 적합합니다.
  • Exadata에 대한 글로벌(RAC-Aware) AWR 보고서에는 특정 Exadata 기능의 사용 현황을 살펴보고 데이터베이스와 셀 노드에서 유용한 인사이트 정보 플래시 캐시, 플래시 로깅, IO 및 기타 기능의 사용 정보를 제공하는 특정 Exadata 섹션도 포함되어 있습니다.

Exadata에서 분리

클라우드로 마이그레이션할 Oracle Exadata 워크로드를 식별할 때 다음 질문과 데이터 요소를 고려합니다.

  • 워크로드가 하드웨어 이점 이외에 다양한 Exadata 기능을 사용하고 있는가?
    • 스마트 검색
    • 스토리지 인덱스
    • 플래시 캐시
    • 플래시 로깅
    • 하이브리드 열 형식 압축
  • Exadata를 사용하는 워크로드가 효율적으로 오프로드되고 있는가? 정점 시간 전경 이벤트에서 다음을 사용하는 워크로드의 비율(DB 시간의 10% 이상)은 어떻게 되는가?
    • 셀 스마트 테이블 검색(최적)
    • 셀 다중 블록 물리적 읽기(덜 최적)
    • 셀 단일 블록 물리적 읽기(최적은 아님)
  • HCC/EHCC(하이브리드 열 형식 압축): 압축된 비율과 압축되지 않은 비율의 비교
    • 데이터베이스가 데이터를 압축하고 압축을 푸는 데 시간을 10% 넘게 소비하고 있는가?
    • 쿼리에서 압축을 사용해 조건자의 성능 향상 검사: 압축해서 절약한 양과 비교해 볼 때 그만한 가치가 있는가?
  • 셀 물리적 IO: 다음을 통해 얻은 절감 효과를 검사합니다.
    • CPU 밸런스를 맞추기 위해 DB 노드로 전달되는 양
    • 스마트 검색에서 반환된 바이트 수 식별. 이러한 값은 Exadata에서 마이그레이션한 후 셀 단일 블록의 물리적 읽기 백분율에 대한 IO에서 뺄 수 있습니다.
  • 캐시에서 논리적 읽기 수 확인. 워크로드용 클라우드 IaaS 솔루션에서 플래시 캐시가 필요한지 결정합니다.
  • 실제 읽기/쓰기의 총 바이트 수를 캐시에서 수행된 총량과 비교합니다. 실제 읽기 요구 사항을 제거하기 위해 메모리를 늘릴 수 있는가(일부에서는 SGA를 축소하여 Exadata 오프로드를 강제 적용하는 것이 일반적임)?
  • 시스템 통계에서 어떤 개체가 어떤 통계의 영향을 받는지 식별합니다. SQL을 튜닝하는 경우 추가 인덱싱, 분할 또는 기타 물리적 튜닝을 통해 워크로드를 크게 최적화할 수 있습니다.
  • 초기화 매개 변수에 밑줄(_) 또는 사용되지 않는 매개 변수가 있는지 검사합니다. 이 매개 변수는 성능에 영향을 줄 수도 있는 데이터베이스 수준의 영향에 의해 정당화되어야 합니다.

Exadata 서버 구성

Oracle 버전 12.2 이상에서는 Exadata 관련 추가 사항이 AWR 글로벌 보고서에 포함됩니다. 이 보고서에는 Exadata에서 마이그레이션하는 데 탁월한 가치를 제공하는 섹션이 있습니다.

  • Exadata 버전 및 시스템 세부 정보

  • 셀 노드 경고 세부 정보

  • Exadata 비온라인 디스크

  • Exadata OS 통계에 대한 이상값 데이터

    • 노란색/분홍색: 중요. Exadata가 최적의 상태로 실행되고 있지 않습니다.

    • 빨간색: Exadata 성능에 크게 영향을 줍니다.

    • Exadata OS CPU 통계: 상위 셀

      • 이러한 통계는 셀의 OS에서 수집되며, 이 데이터베이스 또는 인스턴스로 제한되지 않습니다.
      • v 및 짙은 노란색 배경은 낮은 범위 아래의 이상값을 나타냅니다.
      • ^ 및 옅은 노란색 배경은 높은 범위 위의 이상값을 나타냅니다.
      • 백분율 CPU별 상위 셀이 표시되고, 백분율 CPU이 내림차순으로 표시됩니다.
      • 평균: CPU 39.34%, 사용자 28.57%, 시스템 10.77%

      CPU 비율별로 상위 셀을 보여 주는 테이블의 스크린샷.

  • 단일 셀 물리적 블록 읽기

  • 플래시 캐시 사용량

  • 임시 IO

  • 열 형식 캐시 효율성

IO 처리량별 상위 데이터베이스

크기 조정을 평가할 수 있지만, 이러한 대규모 워크로드 값에 기본 제공되는 평균과 시뮬레이션된 최고치에 대한 질문이 몇 가지 있습니다. AWR 보고서의 마지막 부분에 있는 이 섹션은 Exadata에서 상위 10개 데이터베이스의 평균 플래시 및 디스크 사용량을 모두 보여 주기 때문에 매우 유용합니다. 많은 사람들이 클라우드에서 최고 성능을 발휘하도록 데이터베이스의 크기를 조정하려 한다고 가정할 수 있지만, 이는 대부분의 배포에 적합하지 않습니다(95% 이상이 평균 범위에 속하며 시뮬레이트된 최고치를 계산하면 평균 범위가 98%보다 큼). 수요가 가장 많은 Oracle 워크로드의 경우에도 필요한 만큼 비용을 지불하는 것이 중요하며, IO 처리량별 상위 데이터베이스를 검사하면 데이터베이스에 대한 리소스 요구 사항을 이해하는 데 도움이 될 수 있습니다.

Exadata에서 AWR을 사용하는 적절한 크기의 Oracle

온-프레미스 시스템에 대한 용량을 계획할 때 하드웨어에 상당한 오버헤드가 기본 제공되는 것은 당연한 일입니다. 과도하게 프로비전된 하드웨어는 데이터 증가, 코드 변경 또는 업그레이드로 인한 워크로드 추가에 관계없이 향후 몇 년간 Oracle 워크로드를 처리해야 합니다.

클라우드의 이점 중 하나가 VM 호스트의 리소스 크기를 조정하고 수요가 증가함에 따라 스토리지를 수행할 수 있다는 것입니다. 이는 프로세서 사용량(Oracle과 관련)에 따른 클라우드 비용과 라이선스 비용하는 데 도움이 됩니다.

적절히 크기를 조정하는 일에는 기존 리프트 앤 시프트 마이그레이션에서 하드웨어를 제거하고 Oracle의 AWR(Automatic Workload Repository)이 제공하는 워크로드 정보를 사용하여 고객이 선택한 클라우드에서 이를 지원하도록 특별히 설계된 컴퓨팅 및 스토리지로 워크로드를 리프트 앤 시프트하는 작업이 포함됩니다. 적절한 크기로 조정하는 프로세스는 향후 아키텍처에서 온-프레미스 시스템의 중복이 클라우드에 복제된 경우에 발생하는 인프라 기술 문제, 아키텍처 중복도를 제거하고 가능하다면 클라우드 서비스를 구현해 줍니다.

Microsoft Oracle 실무 전문가들은 Oracle 데이터베이스의 80% 이상이 과도하게 프로비전되고 있으며, 클라우드로 마이그레이션하기 전에 Oracle 데이터베이스 워크로드의 크기를 적절하게 조정하는 데 시간을 할애한다면 클라우드에서도 동일한 비용 또는 절감 효과를 경험할 것으로 예상했습니다. 이 평가를 수행하려면 팀의 데이터베이스 전문가가 과거 용량 계획을 수행했던 방식에 대한 생각을 바꿔야 합니다. 하지만 관련자가 클라우드 및 비즈니스 클라우드 전략에 투자할 만한 가치는 있습니다.

다음 단계