Azure의 Oracle Database Enterprise Edition 아키텍처

적용 대상: ✔️ Linux VM

Azure는 Oracle과 함께 Azure에서 계속 최적으로 실행해야 하는 워크로드를 포함하여 모든 Oracle 워크로드의 홈입니다. Oracle Diagnostic Pack 또는 Automatic Workload Repository(AWR)가 있으면 워크로드에 대한 데이터를 수집할 수 있습니다. 이 데이터를 사용하여 Oracle 워크로드를 평가하고, 리소스 요구 사항의 크기를 조정하고, 워크로드를 Azure로 마이그레이션합니다. 이러한 보고서에서 Oracle이 제공하는 다양한 메트릭은 애플리케이션 성능 및 플랫폼 사용량에 대한 이해를 제공할 수 있습니다.

이 문서는 Azure에서 실행할 Oracle 워크로드를 준비하고 최적의 클라우드 성능을 제공하기 위한 최고의 아키텍처 솔루션을 탐색하는 데 도움이 됩니다. Oracle이 Statspack에서 제공하는 데이터와 그 하위 항목인 AWR에서 제공하는 데이터는 명확한 기대치를 개발하는 데 도움이 됩니다. 이러한 기대치에는 아키텍처를 통한 물리적 튜닝의 한계, 데이터베이스 코드의 논리적 튜닝의 이점 및 전체 데이터베이스 디자인이 포함됩니다.

두 환경 간의 차이점

온-프레미스 애플리케이션을 Azure로 마이그레이션할 때 두 환경 간의 몇 가지 중요한 차이점을 염두에 두어야 합니다.

중요한 차이점 중 하나는 Azure 구현에서 VM, 디스크 및 가상 네트워크와 같은 리소스가 다른 클라이언트와 공유된다는 것입니다. 또한 리소스는 요구 사항에 따라 제한될 수도 있습니다. Azure는 실패를 피하는 데 초점을 맞추는 대신 실패에서 살아남는 데 더 중점을 둡니다. 첫 번째 접근 방식은 평균 고장 간격(MTBF)을 늘리려고 시도하고 두 번째 접근 방식은 평균 복구 시간(MTTR)을 줄이려고 시도합니다.

다음 표에는 Oracle 데이터베이스의 온-프레미스 구현과 Azure 구현 간의 차이점이 나열되어 있습니다.

	온-프레미스 구현	Azure 구현
네트워킹	LAN/WAN	SDN(소프트웨어 정의 네트워킹)
보안 그룹	IP/포트 제한 도구	NSG(네트워크 보안 그룹)
복원력	MTBF	MTTR
계획된 유지 보수	패치/업그레이드	Azure에서 관리하는 패치/업그레이드가 포함된 가용성 집합
리소스	전용	다른 클라이언트와 공유
지역	데이터 센터	지역 쌍
스토리지	SAN/실제 디스크	Azure 관리 스토리지
스케일	수직적 확장	수평적 확장

요구 사항

마이그레이션을 시작하기 전에 다음 요구 사항을 고려합니다.

• 실제 CPU 사용량을 확인합니다. Oracle의 코어별 라이선스는 vCPU의 크기 조정이 비용 절감에 필수적일 수 있음을 의미합니다.
• 데이터베이스 크기, 백업 스토리지 및 증가 속도를 결정합니다.
• Oracle Statspack 및 AWR 보고서를 기반으로 추정할 수 있는 I/O 요구 사항을 결정합니다. 운영 체제에서 사용할 수 있는 스토리지 모니터링 도구에서 요구 사항을 예측할 수도 있습니다.

구성 옵션

AWR 보고서를 생성하고 구성에 대한 결정을 내리는 데 도움이 되는 몇 가지 메트릭을 가져오는 것이 좋습니다. 이제, Azure 환경에서 성능을 향상시키기 위해 조정할 수 있는 잠재적인 네 가지 영역을 알아보겠습니다.

• 가상 머신 크기
• 네트워크 처리량
• 디스크 형식 및 구성
• 디스크 캐시 설정

AWR 보고서 생성

기존 Oracle Enterprise Edition 데이터베이스가 있고 Azure로 마이그레이션하도록 계획하는 경우 몇 가지 옵션이 있습니다. Oracle 인스턴스에 대한 진단 팩이 있는 경우 Oracle AWR 보고서를 실행하여 메트릭(예: IOPS, Mbps, GiB)을 가져올 수 있습니다. 진단 팩 라이선스를 사용하지 않는 데이터베이스 또는 Oracle Standard Edition 데이터베이스의 경우, 수동 스냅샷을 수집한 후에도 Statspack 보고서를 사용하여 동일한 중요한 메트릭을 수집할 수 있습니다. 이러한 두 보고 방법의 주요 차이점은 AWR이 자동으로 수집되고 Statspack보다 데이터베이스에 대한 더 많은 정보를 제공한다는 것입니다.

일반 및 최대 워크로드 모두에서 AWR 보고서를 실행하여 비교할 수 있도록 하세요. 더 정확한 워크로드를 수집하려면 하루가 아닌 일주일의 확장 기간 보고서를 고려합니다. AWR은 보고서에서 계산의 일부로 평균을 제공합니다. 기본적으로 AWR 리포지토리는 8일간의 데이터를 유지하고 시간 간격으로 스냅샷을 생성합니다.

데이터 센터 마이그레이션의 경우 프로덕션 시스템에서 크기 조정을 위한 보고서를 수집해야 합니다. 사용자 테스트, 테스트 및 개발에 사용되는 나머지 데이터베이스 복사본을 백분율로 예측합니다. 예를 들어 프로덕션 크기 조정의 50%를 예상합니다.

명령줄에서 AWR 보고서를 실행하려면 다음 명령을 사용합니다.

sqlplus / as sysdba
@$ORACLE_HOME/rdbms/admin/awrrpt.sql;

주요 메트릭

보고서에서 다음 정보를 요구하는 메시지가 표시됩니다.

• 보고서 유형은 HTML 또는 TEXT입니다. HTML 형식은 자세한 정보를 제공합니다.
• 표시할 스냅샷의 기간(일)입니다. 예를 들어 1시간 간격의 경우 1주 보고서는 168개의 스냅샷 ID를 생성합니다.
• 보고서 창의 시작 SnapshotID입니다.
• 보고서 창의 끝 SnapshotID입니다.
• AWR 스크립트가 만드는 보고서의 이름입니다.

RAC(Real Application Cluster)에서 AWR 보고서를 실행하는 경우 명령줄 보고서는 awrrpt.sql이 아닌 awrgrpt.sql 파일입니다. g 보고서는 단일 보고서에서 RAC 데이터베이스의 모든 노드에 대한 보고서를 만듭니다. 이 보고서를 사용하면 각 RAC 노드에서 하나의 보고서를 실행할 필요가 없습니다.

AWR 보고서에서 다음 메트릭을 가져올 수 있습니다.

• 데이터베이스 이름, 인스턴스 이름 및 호스트 이름
• Oracle의 지원 가능성을 위한 데이터베이스 버전
• CPU/코어
• SGA/PGA 및 크기가 부족한 경우 사용자에게 알릴 수 있는 관리자
• 전체 메모리(GB)
• CPU 백분율 사용 중
• DB CPU
• IOP(읽기/쓰기)
• MBP(읽기/쓰기)
• 네트워크 처리량
• 네트워크 대기 시간 비율(낮음/높음)
• 상위 대기 이벤트
• 데이터베이스에 대한 매개 변수 설정
• 데이터베이스가 RAC인지, Exadata인지 또는 고급 기능이나 구성을 사용하는지 여부

가상 머신 크기

다음은 최적의 성능을 위해 가상 머신 크기를 구성하는 데 수행할 수 있는 몇 가지 단계입니다.

AWR 보고서의 CPU, 메모리 및 I/O 사용량에 따라 VM 크기 예측

시스템 병목 현상이 있는 위치를 나타내는 상위 5개의 시간 지정 전경 이벤트를 확인합니다. 예를 들어 다음 다이어그램에서는 로그 파일 동기화가 맨 위에 있습니다. 로그 작성기에서 로그 버퍼를 다시 실행 로그 파일에 쓰기 전에 필요한 대기 수를 나타냅니다. 이러한 결과는 더 효율적으로 수행되는 스토리지 또는 디스크가 필요함을 나타냅니다. 또한 다이어그램에서는 CPU 코어 수와 메모리 양도 보여줍니다.

다음 다이어그램에서는 읽기 및 쓰기의 총 I/O 수를 보여 줍니다. 보고서 시간 동안 59GB의 읽기 및 247.3GB의 쓰기가 있었습니다.

VM 선택

다음 단계에서는 AWR 보고서에서 수집한 정보에 따라 요구 사항을 충족하는 비슷한 크기의 VM을 선택합니다. 사용 가능한 VM에 대한 자세한 내용은 메모리 최적화 가상 머신 크기를 참조하세요.

ACU에 따라 비슷한 VM 시리즈로 VM 크기 미세 조정

VM을 선택한 후에는 해당 VM에 대한 ACU(Azure 컴퓨팅 단위)에 주의해야 합니다. 요구 사항에 더 적합한 ACU 값에 따라 다른 VM을 선택할 수도 있습니다. 자세한 내용은 Azure 컴퓨팅 단위를 참조하세요.

네트워크 처리량

다음 다이어그램에서는 처리량과 IOPS 간의 관계를 보여 줍니다.

총 네트워크 처리량은 다음 정보를 기반으로 하여 예측합니다.

• SQL*Net 트래픽
• MBps에 서버 수를 곱한 값(Oracle Data Guard와 같은 아웃바운드 스트림)
• 애플리케이션 복제와 같은 다른 요소

네트워크 대역폭 요구 사항에 따라 다양한 게이트웨이 유형을 선택할 수 있습니다. 이러한 유형에는 기본, VpnGw 및 Azure ExpressRoute가 포함됩니다. 자세한 내용은 VPN Gateway 가격 책정을 참조하세요.

권장 사항

• 네트워크 대기 시간은 온-프레미스 배포에 비해 더 높습니다. 네트워크 왕복 수를 줄이면 성능이 크게 향상될 수 있습니다.
• 왕복을 줄이려면 동일한 가상 머신에서 트랜잭션이 많은 애플리케이션 또는 chatty 앱을 통합합니다.
• 네트워크 성능을 향상시키려면 가속화된 네트워킹을 사용하는 Virtual Machine를 사용합니다.
• 특정 Linux 배포판의 경우 TRIM/UNMAP 지원을 사용하도록 설정하는 것이 좋습니다.
• 별도의 Virtual Machine에 Oracle Enterprise Manager를 설치합니다.
• 기본적으로 큰 페이지는 linux에서 사용하도록 설정되지 않습니다. 큰 페이지를 사용하도록 설정하고 Oracle DB에 use_large_pages = ONLY를 설정하는 것이 좋습니다. 이 접근 방식은 성능을 높이는 데 도움이 될 수 있습니다. 자세한 내용은 USE_LARGE_PAGES를 참조하세요.

디스크 형식 및 구성

다음은 디스크를 고려할 때 몇 가지 팁입니다.

• 기본 OS 디스크: 이러한 디스크 유형은 영구 데이터 및 캐싱을 제공합니다. 시작 시 운영 체제 액세스에 최적화되며, 트랜잭션 또는 데이터 웨어하우스(분석) 워크로드용으로는 설계되지 않았습니다.

• 관리 디스크: Azure에서 VM 디스크에 사용하는 스토리지 계정을 관리합니다. 필요한 디스크 유형과 크기를 지정합니다. 유형은 Oracle 워크로드의 경우 프리미엄(SSD)인 경우가 가장 많습니다. Azure에서 사용자에게 맞는 디스크를 만들고 관리합니다. 프리미엄 SSD 관리 디스크는 메모리 최적화 및 설계된 VM 시리즈에만 사용할 수 있습니다. 특정 VM 크기를 선택하면 해당 VM 크기를 기반으로 하여 사용할 수 있는 Premium Storage SKU만 메뉴에 표시됩니다.

  

VM에서 스토리지를 구성한 후 데이터베이스를 만들기 전에 디스크를 로드하여 테스트할 수 있습니다. 대기 시간 및 처리량 모두와 관련된 I/O 속도를 알고 있으면 VM에서 대기 시간 목표로 예상되는 처리량을 지원할 수 있는지 확인하는 데 도움이 됩니다. Oracle Orion, Sysbench, SLOB 및 Fio와 같이 애플리케이션 부하 테스트를 위한 여러 도구가 있습니다.

Oracle 데이터베이스를 배포한 후에 부하 테스트를 다시 실행합니다. 일반 및 최대 워크로드를 시작합니다. 그러면 결과에서 사용자 환경의 초기 계획을 보여 줍니다. 워크로드 테스트에서 현실적이어야 합니다. 실제 VM에서 실행할 워크로드와 전혀 다른 워크로드를 실행하는 것은 의미가 없습니다.

Oracle은 I/O 집약적 데이터베이스일 수 있으므로 스토리지 크기가 아닌 IOPS 비율을 기반으로 스토리지 크기를 조정하는 것이 중요합니다. 예를 들어 필요한 IOPS 값이 5,000이지만 200GB만 필요한 경우 200GB 이상의 스토리지가 있어도 P30 클래스 프리미엄 디스크를 받을 수도 있습니다.

AWR 보고서에서 IOPS 속도를 가져올 수 있습니다. 다시 실행 로그, 물리적 읽기 및 쓰기 속도에 따라 IOPS 속도가 결정됩니다. 항상 선택한 VM 시리즈에는 워크로드의 IO 요청을 처리할 수 있는 기능이 있는지 확인합니다. VM의 I/O 제한이 스토리지보다 낮은 경우 VM은 최대 제한을 설정합니다.

예를 들어 다시 실행 크기는 초당 12,200,000바이트이며, 11.63MBps와 같습니다. IOPS 값은 12,200,000 / 2,358 = 5,174입니다.

I/O 요구 사항에 대해 명확히 알고 있으면 이러한 요구 사항에 가장 적합한 드라이브 조합을 선택할 수 있습니다.

디스크 유형 권장 사항

• 데이터 테이블스페이스의 경우 관리 스토리지 또는 Oracle ASM(Automatic Storage Management)을 사용하여 여러 디스크에 I/O 워크로드를 분산시킵니다.
• Oracle 고급 압축을 사용하여 데이터와 인덱스 모두에 대한 I/O를 줄입니다.
• 별도의 데이터 디스크에 다시 실행 로그, 임시 및 실행 취소 테이블스페이스를 분리합니다.
• 기본 운영 체제 디스크에 애플리케이션 파일을 배치하지 않습니다. 이러한 디스크는 빠른 VM 부팅 시간에 맞게 최적화되지 않으며, 애플리케이션에 좋은 성능을 제공하지 않을 수 있습니다.
• Premium 스토리지에서 M 시리즈 VM을 사용하는 경우 다시 실행 로그 디스크에서 쓰기 가속기를 사용하도록 설정합니다.
• 대기 시간이 긴 다시 실행 로그를 울트라 디스크로 이동하는 것이 좋습니다.

디스크 캐시 설정

호스트 캐싱에는 세 가지 옵션이 있지만 Oracle 데이터베이스의 데이터베이스 워크로드에는 읽기 전용 캐싱만 권장됩니다. 읽기/쓰기는 데이터 파일에 심각한 취약성을 발생시킬 수 있습니다. 데이터베이스 쓰기의 목적은 정보를 캐시하는 것이 아니라 데이터 파일에 기록하는 것이기 때문입니다. 읽기 전용 모드에서는 모든 요청이 이후 읽기를 위해 캐시됩니다. 모든 쓰기는 디스크에 계속 기록됩니다.

디스크 캐시 권장 사항

처리량을 최대화하려면 가능하면 호스트 캐싱에 대한 읽기 전용으로 시작합니다. Premium Storage의 경우 읽기 전용 옵션을 사용하여 파일 시스템을 탑재할 때 barrier를 사용하지 않도록 설정해야 합니다. 디스크의 범용 고유 식별자로 /etc/fstab 파일을 업데이트합니다.

• 운영 체제 디스크의 경우 읽기-쓰기 호스트 캐싱이 포함된 프리미엄 SSD를 사용합니다.
• 다음을 포함하는 데이터 디스크의 경우 읽기 전용 호스트 캐싱이 있는 프리미엄 SSD를 사용합니다. Oracle 데이터 파일, 임시 파일, 제어 파일, 블록 변경 추적 파일, BFILE, 외부 테이블용 파일 및 플래시백 로그
• Oracle 온라인 다시 실행 로그 파일이 포함된 데이터 디스크의 경우 호스트 캐싱이 없는 프리미엄 SSD 또는 UltraDisk, 없음 옵션을 사용합니다. 보관된 Oracle 다시 실행 로그 파일 및 Oracle Recovery Manager 백업 세트도 온라인 다시 실행 로그 파일과 함께 상주할 수 있습니다. 호스트 캐싱은 4,095GiB로 제한되므로 호스트 캐싱을 사용하여 P50보다 큰 프리미엄 SSD를 할당하지 마세요. 4TiB 이상의 스토리지가 필요한 경우 RAID-0으로 여러 프리미엄 SSD를 스트라이핑합니다. Linux LVM2 또는 Oracle Automatic Storage Management를 사용합니다.

낮과 저녁 사이에 워크로드가 크게 달라지고 IO 워크로드가 이를 지원할 수 있는 경우 버스팅을 사용하는 P1-P20 프리미엄 SSD는 야간 시간 일괄 처리 로드 또는 제한된 IO 수요 중에 필요한 성능을 제공할 수 있습니다.

보안

Azure 환경을 설정하고 구성한 후에는 네트워크를 보호해야 합니다. 몇 가지 권장 사항입니다.

• NSG 정책: 서브넷 또는 네트워크 인터페이스 카드로 NSG를 정의할 수 있습니다. 보안 및 강제 라우팅 애플리케이션 방화벽 모두에 대해 서브넷 수준에서 액세스를 제어하는 ​​것이 더 간단합니다.

• Jumpbox: 더 안전한 액세스를 위해 관리자는 애플리케이션 서비스 또는 데이터베이스에 직접 연결해서는 안 됩니다. 관리자 컴퓨터와 Azure 리소스 간에 Jumpbox를 사용합니다.

  

  관리자 컴퓨터는 Jumpbox에 대해 IP가 제한된 액세스만 제공해야 합니다. Jumpbox에는 애플리케이션과 데이터베이스에 대한 액세스 권한이 있어야 합니다.

• 프라이빗 네트워크(서브넷): NSG 정책이 더 나은 제어를 설정할 수 있도록 애플리케이션 서비스와 데이터베이스를 별도의 서브넷에 두는 것이 좋습니다.

리소스

• Oracle ASM 구성
• Oracle Data Guard 구성
• Oracle GoldenGate 구성
• Oracle 백업 및 복구

다음 단계

• Azure CLI를 사용하여 완전한 Linux 가상 머신 만들기
• VM 배포 Azure CLI 샘플 탐색