Hyper-V
Oracle 데이터베이스 가상화
변경 제안
PDF
VMware, Oracle OLVM 또는 KVM을 통한 데이터베이스 가상화는 미션 크리티컬한 데이터베이스도 가상화를 선택한 NetApp 고객에게 점점 더 많이 사용되고 있습니다.
지원 가능성
가상화를 위한 Oracle 지원 정책, 특히 VMware 제품 관련 정책에 관해 많은 오해가 있습니다. Oracle Induight가 가상화를 지원하지 않는다는 말은 흔히 들립니다. 이는 틀린 생각이고, 가상화의 이점을 얻을 수 있는 기회를 놓치게 되는 결과를 낳습니다. Oracle Doc ID 249212.1은 실제 요구사항을 설명하며 고객이 관심사로 간주하는 경우는 거의 없습니다.
가상화된 서버에서 문제가 발생했고 이전에 Oracle Support에서 이 문제를 알려지지 않은 경우 고객은 물리적 하드웨어에서 문제를 재현하도록 요청받을 수 있습니다. 제품의 최첨단 버전을 실행하는 Oracle 고객은 지원 가능성 문제 때문에 가상화를 사용하려 하지 않을 수 있지만 일반적으로 제공되는 Oracle 제품 버전을 사용하는 가상화 고객의 경우에는 현실이 아니었습니다.
스토리지 프레젠테이션
데이터베이스 가상화를 고려하는 고객은 비즈니스 요구사항을 근거로 스토리지 관련 결정을 내려야 합니다. 이는 모든 IT 결정에 있어 일반적으로 적용되는 사항이지만 요구 사항의 규모와 범위가 상당히 다르기 때문에 데이터베이스 프로젝트에서 특히 중요합니다.
스토리지 프레젠테이션에는 다음과 같은 세 가지 기본 옵션이 있습니다.
-
하이퍼바이저 데이터 저장소의 가상화된 LUN
-
하이퍼바이저가 아닌 VM의 iSCSI 이니시에이터에 의해 관리되는 iSCSI LUN
-
VM에 의해 마운트되는 NFS 파일 시스템(NFS 기반 데이터 저장소가 아님)
-
직접 장치 매핑 VMware RDM은 고객이 선호하지 않지만 물리적 디바이스는 KVM 및 OLVM 가상화와 유사하게 직접 매핑되는 경우가 많습니다.
성능
가상 게스트에 스토리지를 제공하는 방법은 일반적으로 성능에 영향을 미치지 않습니다. 호스트 OS, 가상화 네트워크 드라이버, 하이퍼바이저 데이터 저장소 구현은 모두 고도로 최적화되어 있으며 기본 모범 사례를 따르는 한 하이퍼바이저와 스토리지 시스템 간에 사용 가능한 FC 또는 IP 네트워크 대역폭을 모두 사용할 수 있습니다. 어떤 경우에는 다른 스토리지 프레젠테이션 방식에 비해 한 가지 스토리지 프레젠테이션 방식을 사용하면 최적의 성능을 얻는 것이 약간 더 쉬울 수 있지만 결과는 비슷해야 합니다.
관리 효율성
가상화된 게스트에 스토리지를 제공하는 방법을 결정하는 핵심 요소는 관리 능력입니다. 올바른 방법이나 잘못된 방법이 없습니다. 최상의 접근 방식은 IT 운영 요구사항, 기술 및 선호도에 따라 달라집니다.
고려해야 할 요소는 다음과 같습니다.
-
* 투명성. * VM이 파일 시스템을 관리할 때 데이터베이스 관리자나 시스템 관리자가 데이터에 대한 파일 시스템의 소스를 쉽게 식별할 수 있습니다. 파일 시스템 및 LUN은 물리적 서버와 달리 액세스됩니다.
-
* 정합성 보장. * VM이 파일 시스템을 소유하는 경우 하이퍼바이저 계층을 사용하거나 사용하지 않는 것은 관리 용이성에 영향을 미칩니다. 가상화 및 비가상화 환경 모두를 포함한 전체 자산에 걸쳐 프로비저닝, 모니터링, 데이터 보호 등에 같은 절차를 사용할 수 있습니다.
반면에 100% 가상화된 데이터 센터라면 앞에서 언급한 것처럼 전체 설치 공간 전반에서 데이터 저장소 기반 스토리지를 사용하는 것이 더 나을 것입니다. 일관성 - 프로비저닝, 보호, 조정 및 데이터 보호에 대해서도 동일한 절차를 사용할 수 있는 능력입니다.
-
* 안정성 및 문제 해결. * VM이 파일 시스템을 소유할 때 VM에 전체 스토리지 스택이 있기 때문에 우수하고 안정적인 성능 및 문제 해결이 간단해집니다. 여기서 하이퍼바이저는 FC 또는 IP 프레임을 운반하는 역할만 합니다. 데이터 저장소가 구성에 포함된 경우 시간 초과, 매개 변수, 로그 파일, 잠재적 버그 문제가 발생하여 구성이 복잡해집니다.
-
* 이식성. * VM이 파일 시스템을 소유하면 Oracle 환경을 이동하는 프로세스가 훨씬 간단해집니다. 가상화 게스트와 비가상화 게스트 간에 파일 시스템을 쉽게 이동할 수 있습니다.
-
* 공급업체 종속. * 데이터 저장소에 데이터를 배치한 후에는 다른 하이퍼바이저를 사용하거나 가상화된 환경에서 데이터를 완전히 가져오는 것이 어려워집니다.
-
* Snapshot Enablement. * 상대적으로 제한된 대역폭으로 인해 가상화 환경의 기존 백업 절차가 문제가 될 수 있습니다. 예를 들어, 4포트 10GbE 트렁크는 여러 가상화 데이터베이스의 일상적인 성능 요구를 충분히 지원할 수 있지만 RMAN 또는 데이터의 전체 크기 복사본 스트리밍이 필요한 기타 백업 제품을 사용하여 백업을 수행하기에는 불충분합니다. 그 결과 점점 더 통합되는 가상화 환경에서 스토리지 스냅샷을 통해 백업을 수행해야 합니다. 따라서 백업 윈도우에서 순수하게 대역폭과 CPU 요구사항을 지원하기 위해 하이퍼바이저 구성을 오버 빌드할 필요가 없습니다.
게스트 소유 파일 시스템을 사용하면 보호가 필요한 스토리지 오브젝트를 더 쉽게 타겟팅할 수 있기 때문에 스냅샷 기반 백업과 복원을 활용하기가 어려울 수 있습니다. 그러나 데이터 저장소 및 스냅샷과 잘 통합되는 가상화 데이터 보호 제품이 점점 더 많아지고 있습니다. 가상화된 호스트에 스토리지를 제공하는 방법을 결정하기 전에 백업 전략을 완전히 고려해야 합니다.
반가상화 드라이버
최적의 성능을 얻으려면 반가상화 네트워크 드라이버를 사용해야 합니다. 데이터 저장소를 사용할 때는 반가상화 SCSI 드라이버가 필요합니다. 에뮬레이션된 드라이버가 하이퍼바이저가 물리적 하드웨어의 동작을 모방면서 많은 CPU 시간을 사용하는 것과 대조적으로, 반가상화 장치 드라이버는 게스트가 하이퍼바이저에 더 긴밀히 통합될 수 있게 합니다.
RAM 오버 커밋
RAM 오버 커밋이란 물리적 하드웨어에 있는 것보다 더 많은 가상화 RAM을 다양한 호스트에 구성하는 것을 의미합니다. 오버 커밋은 예기치 않은 성능 문제를 초래할 수 있습니다. 데이터베이스를 가상화할 때 Oracle SGA의 기본 블록이 하이퍼바이저에 의해 스토리지로 교체되면 안 됩니다. 교체할 경우 성능 결과가 매우 불안정해집니다.
데이터 저장소 스트라이핑
데이터 저장소와 함께 데이터베이스를 사용할 때는 성능 스트라이핑과 관련하여 고려해야 할 중요한 한 가지 요소가 있습니다.
VMFS와 같은 데이터 저장소 기술은 여러 LUN을 확장할 수 있지만 스트라이핑된 디바이스는 아닙니다. LUN이 연결됩니다. 결과적으로 LUN 핫스팟이 될 수 있습니다. 예를 들어, 일반적인 Oracle 데이터베이스의 경우 8-LUN ASM 디스크 그룹이 있을 수 있습니다. 8개의 가상화된 LUN을 모두 8개의 LUN VMFS 데이터 저장소에 프로비저닝할 수 있지만 데이터가 상주할 LUN은 보장할 수 없습니다. 그 결과 VMFS 데이터 저장소 내에서 단일 LUN을 차지하는 8개의 가상화된 LUN이 모두 구성될 수 있습니다. 이로 인해 성능 병목 현상이 발생합니다.
일반적으로 스트라이핑이 필요합니다. KVM을 비롯한 일부 하이퍼바이저에서는 설명된 대로 LVM 스트라이핑을 사용하여 데이터 저장소를 구축할 수 있습니다 "여기". VMware를 사용하면 아키텍처가 조금 다르게 보입니다. 각 가상화된 LUN은 서로 다른 VMFS 데이터 저장소에 배치해야 합니다.
예를 들면 다음과 같습니다.
이 접근 방식의 주요 동인은 ONTAP가 아닙니다. 단일 VM 또는 하이퍼바이저 LUN이 병렬로 처리할 수 있는 작업 수의 내재적 제한 때문입니다. 일반적으로 단일 ONTAP LUN은 호스트가 요청할 수 있는 것보다 훨씬 더 많은 IOPS를 지원할 수 있습니다. 단일 LUN 성능 제한은 거의 보편적으로 호스트 운영 체제의 결과입니다. 그 결과 대부분의 데이터베이스에서 성능 요구를 충족하기 위해 4~8개의 LUN이 필요합니다.
VMware 아키텍처는 데이터 저장소 및/또는 LUN 경로 최대화가 이 접근 방식에서 발생하지 않도록 아키텍처를 신중하게 계획해야 합니다. 또한 모든 데이터베이스에 대해 고유한 VMFS 데이터 저장소 집합이 필요하지 않습니다. 각 호스트에 가상 LUN에서 스토리지 시스템 자체의 백엔드 LUN으로 연결되는 4-8개의 깨끗한 입출력 경로 세트가 있어야 합니다. 드문 경우지만 더 많은 데이터토어가 진정한 성능 요구 사항에 도움이 될 수 있지만 일반적으로 전체 데이터베이스의 95%에 대해 4-8개의 LUN으로 충분합니다. 8개의 LUN이 포함된 단일 ONTAP 볼륨은 일반적인 OS/ONTAP/네트워크 구성에서 최대 250,000개의 랜덤 Oracle 블록 IOPS를 지원할 수 있습니다.