Oracle Cloud Infrastructure에는 컴퓨팅, 스토리지, 네트워킹, 데이터베이스, 로드 밸런싱 등 사실상 클라우드 기반 데이터 센터를 구축하는 데 필요한 모든 인프라를 포함한 다양한 서비스가 포함되어 있습니다. 이 검토의 맥락에서 우리는 베어 메탈 인스턴스에 매우 구체적으로 초점을 맞춘 Oracle Cloud Infrastructure 컴퓨팅 범주에 관심이 있습니다. 대부분의 클라우드 공급자와 마찬가지로 Oracle은 가상화된 컴퓨팅 인스턴스를 제공하지만 대부분의 다른 가상 제품과 달리 짧은 대기 시간이 필요한 애플리케이션을 위해 최대 25TB의 NVMe 스토리지를 포함하는 구성으로 이를 지원할 수 있습니다. 그 만큼 Oracle은 대기 시간이 가장 중요한 미션 크리티컬 애플리케이션에 이상적인 업계 최초의 고성능 베어 메탈 인스턴스를 제공하여 클라우드 컴퓨팅 성능을 더욱 향상시켰습니다. 인스턴스는 최대 52개의 OCPU, 768GB RAM, 듀얼 25GbE NIC 및 최대 51TB의 로컬로 연결된 NVMe 스토리지와 함께 제공됩니다. 더 많은 것을 원하는 사용자를 위해 최대 512TB의 네트워크 연결 NVMe 블록 스토리지와 GPU 옵션을 사용할 수 있습니다. 모든 다양한 Oracle 컴퓨팅 오퍼링은 경합을 최소화하고 성능을 최대화하도록 조정된 고도로 최적화된 소프트웨어 정의 네트워크에서 실행됩니다.
Oracle Cloud Infrastructure에는 컴퓨팅, 스토리지, 네트워킹, 데이터베이스, 로드 밸런싱 등 사실상 클라우드 기반 데이터 센터를 구축하는 데 필요한 모든 인프라를 포함한 다양한 서비스가 포함되어 있습니다. 이 검토의 맥락에서 우리는 베어 메탈 인스턴스에 매우 구체적으로 초점을 맞춘 Oracle Cloud Infrastructure 컴퓨팅 범주에 관심이 있습니다. 대부분의 클라우드 공급자와 마찬가지로 Oracle은 가상화된 컴퓨팅 인스턴스를 제공하지만 대부분의 다른 가상 제품과 달리 짧은 대기 시간이 필요한 애플리케이션을 위해 최대 25TB의 NVMe 스토리지를 포함하는 구성으로 이를 지원할 수 있습니다. 그 만큼 Oracle은 대기 시간이 가장 중요한 미션 크리티컬 애플리케이션에 이상적인 업계 최초의 고성능 베어 메탈 인스턴스를 제공하여 클라우드 컴퓨팅 성능을 더욱 향상시켰습니다. 인스턴스는 최대 52개의 OCPU, 768GB RAM, 듀얼 25GbE NIC 및 최대 51TB의 로컬로 연결된 NVMe 스토리지와 함께 제공됩니다. 더 많은 것을 원하는 사용자를 위해 최대 512TB의 네트워크 연결 NVMe 블록 스토리지와 GPU 옵션을 사용할 수 있습니다. 모든 다양한 Oracle 컴퓨팅 오퍼링은 경합을 최소화하고 성능을 최대화하도록 조정된 고도로 최적화된 소프트웨어 정의 네트워크에서 실행됩니다.
현재 다양한 클라우드 제품이 있으며 AWS, Google Cloud Platform 및 Microsoft Azure가 해당 목록의 맨 위에 있는 몇 가지 대규모 클라우드 제품도 있습니다. 이러한 클라우드 서비스 공급자는 많은 훌륭한 제품과 서비스를 제공하지만 일반적으로 제공하지 않는 한 가지는 성능입니다. 클라우드를 온프레미스와 비교할 때 온프레미스가 항상 클라우드를 능가합니다. Oracle은 클라우드 인프라 제품을 통해 이러한 관점을 바꾸려고 합니다.
오라클의 컴퓨팅 오퍼링은 성능, 가용성, 다용성 및 거버넌스를 포함하여 온프레미스 스토리지 또는 서버에서 기대할 수 있는 약속과 함께 제공됩니다. 성능 측면은 미션 크리티컬 애플리케이션을 위한 최고의 일관된 성능을 지원하며 최근에 발표된 종단 간 클라우드 인프라 SLA, 이 글을 쓰는 시점에서 업계에서 이와 같은 유일한 것입니다. 이 오퍼링은 DNS, 로드 밸런싱, 복제, 백업, 스토리지 스냅샷 및 클러스터링을 포함한 여러 계층에서 가용성을 지원합니다. 컴퓨팅 오퍼링은 단일 코어 VM에서 52코어 단일 테넌트 베어메탈에 이르기까지 다양하며 공통 워크로드에서 HPC 클러스터에 이르기까지 모든 것을 실행할 수 있는 다용성을 제공합니다. Oracle의 베어메탈 인스턴스를 사용하면 다른 테넌트와 Oracle 제공 소프트웨어가 없기 때문에 고객은 온프레미스 서버를 격리하고 제어할 수 있습니다.
Oracle Cloud의 컴퓨팅 오퍼링은 베어 메탈 인스턴스, 베어 메탈 GPU 인스턴스 및 VM 인스턴스를 포함하여 여러 "형태"로 제공됩니다. 이 검토를 위해 Oracle에 따르면 최대 5.1만 IOPS를 제공할 수 있고 미션 크리티컬 데이터베이스 애플리케이션, HPC 워크로드 및 I/O 집약적 웹 애플리케이션과 같은 사용 사례를 위한 베어 메탈 인스턴스를 살펴볼 것입니다. 비교를 위해 로컬 NVMe 스토리지(DenseIO) 및 네트워크 블록 스토리지(표준)가 있는 Oracle의 VM 형태도 표시합니다.
Oracle Cloud Infrastructure의 관리 GUI는 이해하기 매우 간단합니다. 기본 페이지에는 필요한 경우 연습 및 지원이 있습니다. 맨 위에는 홈(메인 페이지), ID, 컴퓨팅, 데이터베이스, 네트워킹, 스토리지, 감사에 대한 탭과 함께 테넌시 또는 계정, 사용 중인 지역(이 경우에는 us-ashburn-1)이 있습니다. , 이메일. 테스트를 위해 DenseIO2 및 Standard2가 표시됩니다.
이 검토는 컴퓨팅 측면에 초점을 맞추고 있으므로 해당 탭 아래에서 성능 테스트에 사용할 인스턴스를 볼 수 있습니다. 각 인스턴스에는 이름, 모양, 지역, 가용성 도메인 및 생성 시기가 있습니다. 왼쪽에서 사용자는 "실행 중"과 같은 상태를 선택하여 목록을 변경할 수 있습니다.
오른쪽에 있는 줄임표를 클릭하면 인스턴스를 조금 더 깊이 파고들 수 있습니다. BM.DenseIO2.52를 보면 인스턴스가 실행 중인지 쉽게 확인할 수 있고 이에 대한 자세한 정보를 확인할 수 있습니다. 여기에서도 태그를 연결할 수 있습니다. 정보 상단에는 사용자 지정 이미지 생성, 인스턴스 시작, 중지 또는 재부팅, 종료 또는 태그 적용 기능이 있습니다. 아래로 스크롤하면 블록 볼륨도 연결할 수 있습니다.
네트워킹 탭에서 사용 중인 가상 클라우드 네트워크를 보거나 생성할 수 있습니다. VCN의 경우 지역, 기본 경로 테이블, DNS 도메인 및 생성 시기와 같은 정보가 있습니다. 다시 말하지만, 오른쪽의 줄임표는 드릴다운, 태그 적용 및 서브넷 생성을 허용합니다.
스토리지 탭에서 사용자는 자신의 구획에 있는 블록 볼륨을 보고 더 생성할 수 있습니다. 블록 볼륨은 생성된 날짜별로 나열되며 사용자는 자세한 정보를 드릴다운하고, 수동 백업을 생성하고, 인스턴스에서 블록 볼륨을 분리하고, 볼륨을 삭제하거나, 태그를 적용할 수 있습니다.
그리고 감사에서 알 수 있듯이 날짜와 시간 범위를 선택하여 과거 이벤트를 빠르게 볼 수 있습니다. 이를 통해 기업은 모든 이벤트 또는 환경 변경에 대한 사용자 및 작업을 캡처하는 관리 규정 준수 요구 사항을 충족할 수 있습니다.
퍼포먼스
VDBench 워크로드 분석
이러한 Oracle Cloud 인스턴스의 성능을 평가하기 위해 각 플랫폼에 로컬로 설치된 vdbench를 활용했습니다. 테스트는 모든 로컬 스토리지에 동시에 분산되었으므로 BV(블록 볼륨)와 NVMe 스토리지가 모두 있는 경우 한 번에 하나의 그룹을 테스트했습니다. 두 스토리지 유형 모두에서 각 장치의 12%를 할당하고 함께 그룹화하여 적당한 양의 데이터 지역성과 함께 최고 시스템 성능을 살펴보았습니다.
이러한 워크로드는 "포 코너" 테스트, 공통 데이터베이스 전송 크기 테스트, 다양한 VDI 환경의 트레이스 캡처에 이르는 다양한 테스트 프로필을 제공합니다. 이러한 모든 테스트는 스크립팅 엔진과 함께 공통 vdBench 워크로드 생성기를 활용하여 대규모 컴퓨팅 테스트 클러스터에서 결과를 자동화하고 캡처합니다. 이를 통해 플래시 어레이 및 개별 스토리지 장치를 포함한 광범위한 스토리지 장치에서 동일한 워크로드를 반복할 수 있습니다.
프로필 :
- 4K 임의 읽기: 100% 읽기, 128 스레드, 0-120% iorate
- 4K 임의 쓰기: 100% 쓰기, 64 스레드, 0-120% iorate
- 64K 순차 읽기: 100% 읽기, 16개 스레드, 0-120% iorate
- 64K 순차 쓰기: 100% 쓰기, 8개 스레드, 0-120% 속도
- 합성 데이터베이스: SQL 및 Oracle
- VDI 전체 클론 및 연결된 클론 추적
BV(원격 블록 장치)와 NVMe를 모두 살펴봅니다. 이렇게 극적인 성능 차이가 있기 때문에 결과를 두 개의 차트로 분리했습니다(대기 시간이 너무 멀어서 차트를 읽기가 매우 어렵습니다). 이 검토에서는 BV에서 표준 및 고밀도 IO 실행과 NVMe에 대한 고밀도 IO 실행이 있는 베어 메탈(BM) 및 VM 구성을 모두 살펴봅니다.
BV에 대한 최대 4K 읽기를 살펴보면 53개의 실행 모두 강력한 밀리초 미만의 대기 시간으로 시작되었습니다. 가장 먼저 벗겨낸 것은 VM.Standard로, 60,591K IOPS 바로 아래에서 15ms의 대기 시간으로 1 IOPS로 정점에 도달했습니다. 밀리초 이하의 대기 시간을 깨뜨린 다음은 VM.DenseIO로, 표준과 거의 동일한 지점에서 72,626ms를 넘었지만 대기 시간은 7.5ms로 235 IOPS로 정점을 찍었습니다. 두 가지 베어메탈 실행 모두 약 252,275K IOPS까지 밀리초 미만의 대기 시간 성능을 실행하는 DenseIO에서 훨씬 더 나은 결과를 얻었으며 대기 시간은 4.1ms인 250 IOPS에서 정점에 도달했습니다. BM.Standard는 1ms를 넘기기 전에 약 258,329K IOPS까지 도달했으며 지연 시간이 4.05ms인 XNUMX IOPS에서 정점에 도달했습니다.
NVMe의 최대 4K 읽기 성능을 살펴보면 두 실행 모두 전체적으로 밀리초 미만의 대기 시간이 있었습니다. VM.DenseIO는 569,534μs의 대기 시간과 함께 214 IOPS로 정점을 찍었습니다. BM.DenseIO는 지연 시간이 4,419,490μs에 불과한 174.6 IOPS로 정점을 찍었습니다.
BV에 대한 무작위 4K 쓰기 최고 성능으로 전환하면 VM이 BM보다 훨씬 일찍 정점에 도달하는 이전과 유사한 위치를 볼 수 있습니다. VM.Standard는 63밀리초 미만의 대기 시간을 깨기 전에 약 77,229K IOPS로 만들었고 5.3ms 대기 시간에서 69 IOPS로 정점을 찍었습니다. VM.DenseIO는 1ms를 넘기기 전에 약 84,274K IOPS에 도달하여 조금 더 나은 성능을 보였고 3.9ms의 대기 시간으로 263 IOPS로 정점에 도달했습니다. BM.DenseIO는 대기 시간이 1ms를 초과하기 전에 280,158K IOPS의 북쪽까지 도달할 수 있었고 대기 시간이 2.02ms인 278 IOPS에서 정점에 도달했습니다. 그리고 BM.Standard는 280,844밀리초 미만의 대기 시간을 거치기 전에 약 1.84K IOPS를 생성하는 최고 성능 구성이었으며 대기 시간이 XNUMXms인 XNUMX IOPS에서 정점에 도달했습니다.
NVMe on 4K 쓰기를 통해 BM은 다시 밀리초 미만의 대기 시간 성능을 통해 VM을 능가했습니다. VM.DenseIO는 412,207μs의 대기 시간과 함께 141 IOPS로 정점을 찍었습니다. BM.DenseIO는 3,232,215μs의 대기 시간과 함께 125 IOPS로 정점을 찍었습니다.
순차적 작업으로 이동하여 먼저 BV에 대한 64K 읽기를 살펴봅니다. VM.Standard와 VM.DenseIO 모두 약 1K IOPS 또는 15.5MB/s에서 968ms 대기 시간을 깨뜨렸습니다. 그리고 대기 시간이 8.2ms로 증가하면서 둘 다 거의 동일한 성능을 유지했습니다. 다시 우리는 BM.Standard와 BM.DenseIO 모두 약 1K IOPS 또는 37.5GB/s에서 2.35ms를 깨는 비슷한 것을 보았습니다. 두 구성 모두 47ms 대기 시간에서 2.95K IOPS 또는 8.4GB/s 바로 북쪽에서 정점을 찍었습니다.
NVMe 순차 64K 읽기는 두 구성 모두 전체적으로 39,512밀리초 이하의 지연 시간을 유지했습니다. VM.DenseIO는 대기 시간 2.5μs에서 403 IOPS 또는 323,879GB/s로 정점을 찍은 반면, BM.DenseIO는 대기 시간 20.2μs에서 361 IOPS 또는 XNUMXGB/s로 정점을 찍었습니다.
BV에 대한 64K 순차 쓰기를 사용하면 VM.Standard 및 VM.DenseIO 모두 1K IOPS 또는 12MB/s의 성능에서 770ms 대기 시간을 깨는 유사한 현상을 다시 볼 수 있습니다. 둘 다 15.1ms의 대기 시간에서 약 943K IOPS 또는 3.1MB/s를 기록했습니다. BM.Standard 및 BM.DenseIO를 사용하면 둘 다 약 1K IOPS 또는 42GB/s에서 2.6ms 대기 시간을 깨고 BM.DenseIO는 46,768ms 대기 시간으로 2.92 IOPS 또는 2.6GB/s에서 정점을 찍었습니다. BM.Standard는 최대 46,787 IOPS 또는 2.92GB/s, 지연 시간은 3.4ms입니다.
NVMe에 대한 64K 순차 쓰기의 경우 VM.DenseIO 및 BM.DenseIO 모두 다시 밀리초 미만의 지연 시간 성능을 보였지만 둘 다 지연 시간이 급증했습니다(BM.DenseIO의 최종 성능 감소와 함께). VM.DenseIO는 25K IOPS 또는 1.56GB/s에서 최대 311μs까지 급증한 후 대기 시간 754μs로 정점을 찍었습니다. BM.DenseIO는 최고 성능(160,895 IOPS 또는 10.1GB/s, 대기 시간 170μs)이 훨씬 더 좋았지만, 마지막에는 대기 시간이 증가하면서 일부 감소하여 132,192 IOPS 또는 8.8GB/s로 마무리되었습니다. 대기 시간은 310μs입니다.
BV에 대한 SQL 워크로드에서 VM.Standard는 약 1K IOPS에서 처음으로 50ms를 초과했으며 지연 시간이 73,259ms인 3.4 IOPS에서 정점에 도달했습니다. VM.DenseIO는 약 1K IOPS에서 58ms 대기 시간을 초과했고 78,624ms의 대기 시간으로 3.1 IOPS에서 정점에 도달했습니다. BM의 경우 둘 다 약 1K까지 대기 시간이 275ms 미만으로 유지되었습니다(BM.DenseIO가 조금 더 오래 실행됨). BM.Standard는 대기 시간이 305,368ms인 1.7 IOPS로 정점을 찍은 반면 BM.DenseIO는 대기 시간이 307,979ms인 1.35 IOPS로 정점을 찍었습니다.
NVMe용 SQL은 VM.DenseIO가 188,786μs에서 167 IOPS로 정점을 찍으면서 다시 밀리초 미만의 대기 시간을 가졌습니다. BM.DenseIO는 1,684,869μs의 대기 시간과 함께 142 IOPS로 정점을 찍었습니다.
BV에 대한 SQL 90-10 벤치마크에서 두 VM 모두 약 58K IOPS에서 밀리초 미만의 대기 시간 성능을 깨뜨렸습니다. VM.Standard는 71,691ms의 대기 시간과 함께 3.5 IOPS로 정점을 찍었습니다. VM.DenseIO는 79,033ms의 대기 시간과 함께 3.05 IOPS로 정점을 찍었습니다. BM.Standard는 대략 1K IOPS의 성능에서 270ms 대기 시간을 돌파했으며 303,904ms의 대기 시간으로 1.7 IOPS로 정점을 찍었습니다. BM.DenseIO는 약 290K IOPS까지 307,472밀리초 미만의 대기 시간을 가졌고 대기 시간이 1.34ms인 XNUMX IOPS에서 정점에 도달했습니다.
NVMe SQL 90-10의 경우 VM.DenseIO는 172,693μs의 대기 시간과 함께 182 IOPS로 정점을 찍었습니다. BM.DenseIO는 1,328,437μs에서 165 IOPS로 정점을 찍었습니다.
BV에 대한 SQL 80-20 벤치마크에서 VM.Standard는 54ms를 넘기기 전에 약 1K IOPS에 이르렀고 72,204ms의 대기 시간으로 3.4 IOPS에 도달했습니다. VM.DenseIO는 약 59K IOPS까지 지연 시간이 78,787밀리초 미만이었고 최대 지연 시간은 2.99ms인 280 IOPS였습니다. BM.Standard는 대기 시간이 1ms 미만인 약 300,014K IOPS로 실행되었으며 최대 대기 시간은 1.6ms인 1 IOPS였습니다. BM.DenseIO는 약 285K IOPS에서 299,730ms 대기 시간을 깨고 성능이 떨어지기 전에 1.3ms 대기 시간으로 XNUMX IOPS에서 정점에 도달했습니다.
NVMe에 대한 SQL 80-20 벤치마크에서 VM.DenseIO는 144,010μs의 대기 시간과 함께 218 IOPS로 정점을 찍었습니다. BM.DenseIO는 1,114,056μs의 대기 시간으로 182 IOPS로 정점을 찍고 성능이 약간 떨어졌습니다.
BV를 사용하는 Oracle 워크로드에서 VM.Standard는 약 52K IOPS에 도달할 때까지 밀리초 미만의 지연 시간 성능을 보였고 지연 시간이 70,096ms인 3.4 IOPS에서 정점에 도달했습니다. VM.DenseIO는 대략 1K IOPS에서 58ms 대기 시간을 깨고 75,000ms의 대기 시간으로 3.1 IOPS에서 정점에 도달했습니다. BM.Standard는 1ms의 대기 시간으로 255 IOPS의 최고 성능으로 약 280,599K의 1.41ms 대기 시간을 돌파했습니다. BM.DenseIO는 약 260K IOPS까지 267,632밀리초 미만의 대기 시간을 가졌고 대기 시간이 1.3ms인 XNUMX IOPS에서 정점에 도달했습니다.
NVMe를 사용한 Oracle 워크로드는 132,553μs의 대기 시간과 함께 257 IOPS의 VM.DenseIO에 대한 최고 성능을 보여주었습니다. BM.DenseIO의 경우 최고 성능은 1,043,104 IOPS이고 대기 시간은 199μs입니다.
BV용 Oracle 90-10에서 VM.Standard는 54K IOPS를 조금 넘을 때까지 밀리초 미만의 대기 시간을 가졌고 대기 시간이 72,533ms인 2.2 IOPS에서 정점에 도달했습니다. VM.DenseIO는 대략 1K IOPS에서 61ms 대기 시간을 깨고 76,908ms의 대기 시간으로 1.86 IOPS로 정점을 찍었습니다. 두 BM 모두 297ms 대기 시간을 깨기 전에 1K IOPS를 달성했습니다. BM.Standard는 305,771ms의 대기 시간과 함께 1.17 IOPS로 정점을 찍었습니다. BM.DenseIO는 297,509ms의 대기 시간으로 1.03 IOPS의 최고 성능을 보였습니다.
NVMe용 Oracle 90-10에서 VM.DenseIO는 133,330 IOPS의 최고 성능과 163μs의 지연 시간을 보였습니다. BM.DenseIO는 1,088,454 IOPS의 최고 성능과 142μs의 대기 시간을 가졌습니다.
BV가 포함된 Oracle 80-20에서 VM.Standard는 55ms 미만에 약 1K에 이르렀고 대기 시간은 74,032ms로 2.14 IOPS로 정점을 찍었습니다. VM.DenseIO는 약 51K까지 75,666밀리초 미만의 대기 시간을 가졌고 대기 시간이 2ms인 295 IOPS에서 정점에 도달했습니다. 두 BM 모두 1ms를 깨기 전에 약 306,955K IOPS까지 도달했습니다. BM.Standard는 1.14ms의 대기 시간과 함께 295 IOPS로 정점을 찍었습니다. BM.DenseIO는 893μs의 대기 시간과 함께 약 XNUMXK IOPS에서 정점을 찍었습니다.
NVMe가 있는 Oracle 80-20에서 VM.DenseIO는 108,483μs의 대기 시간과 함께 195 IOPS로 정점을 찍었습니다. BM.DenseIO는 956,326μs의 대기 시간과 함께 158 IOPS로 정점을 찍었습니다.
다음으로 VDI 전체 클론을 살펴보았습니다. BV를 사용한 부팅의 경우 VM.Standard는 1K IOPS 바로 아래에서 40ms를 중단했고 지연 시간은 56,057ms로 4.2 IOPS로 정점을 찍었습니다. VM.DenseIO는 대략 43K IOPS까지 밀리초 미만의 대기 시간으로 만들었고 대기 시간이 61,570ms인 3.6 IOPS에서 정점에 도달했습니다. 두 BM 모두 200K IOPS 임계값을 약간 넘을 때까지 대기 시간이 밀리초 미만이었습니다. 둘 다 약 220K IOPS에서 최대 2.1의 대기 시간을 가진 후 성능이 떨어졌습니다.
NVMe를 사용한 전체 클론 부팅의 경우 VM.DenseIO는 대기 시간이 136μs인 약 235K IOPS에서 정점을 찍었습니다. BM.DenseIO는 1,032,322μs의 대기 시간과 함께 213 IOPS로 정점을 찍었습니다.
BV를 사용한 VDI 전체 복제 초기 로그인을 통해 두 VM 모두 대기 시간이 밀리초 미만인 약 41K IOPS를 달성했습니다. VM.Standard는 대기 시간이 55,522ms인 경우 최고 3.7 IOPS, VMDenseIO는 대기 시간이 59,560ms인 경우 최고 3.6 IOPS였습니다. . 두 BM 모두 203K IOPS 근처에서 225밀리초 미만의 대기 시간을 깨뜨렸습니다(표준이 밀집되기 전). BM.Standard는 대기 시간이 2.04ms인 약 224,385K IOPS로 정점을 찍었고 BM.DenseIO는 대기 시간이 1.8ms인 XNUMX IOPS로 정점을 찍었습니다.
NVMe를 사용한 VDI 전체 복제 초기 로그인의 경우 VM.Standard는 59,883μs의 대기 시간과 함께 506 IOPS로 정점을 찍었습니다. 그리고 BM.DenseIO는 467,761μs의 대기 시간과 함께 262 IOPS로 정점을 찍었습니다.
VDI Full Clone Monday Login with BV는 최대 36 IOPS와 50,685ms의 대기 시간으로 2.3K IOPS에 근접할 때까지 대기 시간이 1밀리초 미만인 VM.Standard를 가졌습니다. VM.DenseIO는 38K IOPS 바로 북쪽까지 53,304ms 미만으로 수행되었으며 2.2ms 대기 시간으로 최고 1 IOPS를 기록했습니다. BM.Standard는 약 205K IOPS에서 224,764ms 대기 시간을 돌파했고 1.5ms의 대기 시간으로 1 IOPS에서 정점에 도달했습니다. BM.DenseIO는 210K IOPS를 조금 넘는 피크와 220ms의 대기 시간으로 약 1.2K에서 XNUMXms를 초과했습니다.
NVMe를 사용한 VDI 전체 클론 월요일 로그인은 44,384μs의 대기 시간과 함께 356 IOPS의 VM.DenseIO 최고 성능을 보여주었습니다. BM.DenseIO는 356,691μs의 대기 시간과 함께 252 IOPS로 정점을 찍었습니다.
테스트의 최종 선택은 VDI 연결된 클론을 살펴봅니다. BV로 부팅 테스트를 다시 시작하면 VM.Standard는 약 29K IOPS까지 지연 시간이 밀리초 미만이었으며 지연 시간이 38ms인 약 2.4K IOPS에서 정점에 도달했습니다. VM.DenseIO는 32ms를 깨기 전에 약 1K IOPS까지 만들었고 약 38K IOPS와 2.16ms 대기 시간으로 정점에 도달했습니다. 두 BM 모두 100ms 대기 시간을 넘기기 전에 대략 1K IOPS에 도달했습니다. 둘 다 114ms 대기 시간으로 약 3K IOPS의 최고 성능을 보였습니다.
NVMe용 VDI Linked Clone Boot를 사용하여 65,384μs의 대기 시간과 함께 238 IOPS에서 VM.DenseIO 피크를 확인했습니다. BM.DenseIO는 555,004μs의 대기 시간과 함께 217 IOPS로 정점을 찍었습니다.
BV를 사용한 초기 로그인을 사용하면 두 VM 모두 약 1K IOPS에서 28ms 지연 시간을 돌파했으며, VM.Standard는 36,682ms의 지연 시간으로 1.6 IOPS로 정점을 찍고 VM.DenseIO는 38,525ms의 지연 시간으로 1.6 IOPS로 정점을 찍었습니다. 두 BM 모두 약 1K IOPS에서 132ms 지연 시간을 돌파했습니다. BM.Standard는 140,848 IOPS에서 최대 지연 시간은 1.3ms, BM.DenseIO는 139,883 IOPS 및 1.2ms 지연 시간에서 최고를 기록했습니다.
NVMe를 사용한 초기 로그인은 VM.DenseIO의 경우 24,228 IOPS 및 326μs의 최고 성능을, BM.DenseIO의 경우 242,778μs의 경우 234 IOPS의 최고 성능을 보였습니다.
마지막으로 VDI Linked Clone Monday Login with BV를 통해 VM.Standard는 최대 27 IOPS와 39,874ms의 대기 시간으로 약 2.86K IOPS까지 1밀리초 미만의 대기 시간 성능을 보였습니다. VM.DenseIO는 약 25K IOPS에서 42,469ms를 중단했고 3 IOPS 및 135ms 대기 시간에서 정점에 도달했습니다. 두 BM 모두 약 146K IOPS까지 1.6밀리초 미만의 지연 시간을 가졌으며 두 BM 모두 1.76K IOPS에서 피크를 기록했습니다. denseIO의 지연 시간은 XNUMXms, 표준의 지연 시간은 XNUMXms였습니다.
VDI Linked Clone Monday Login with NVMe에서 VM.DenseIO는 최고 34,016 IOPS와 464μs의 대기 시간을 기록했습니다. BM.DenseIO는 최고 260,527 IOPS와 317μs의 대기 시간을 기록했습니다.
결론
Oracle의 Cloud Infrastructure는 클라우드의 주요 문제 중 하나인 성능 또는 성능 부족을 베어 메탈 인스턴스로 해결합니다. 오라클은 베어메탈 및 가상 컴퓨트 인스턴스는 물론 클라우드에서 볼 수 있는 그 어떤 것과도 비교할 수 없는 성능을 위해 최대 25TB의 NVMe 스토리지가 포함된 NVMe 버전을 제공합니다. 최대 5.1만 IOPS라는 오라클의 성능에 도달하려면 NVMe 스토리지 이상이 필요합니다. 또한 인스턴스에는 최대 52개의 OCPU, 768GB RAM, 이중 25GbE NIC 및 최대 51TB의 로컬로 연결된 NVMe 스토리지가 있습니다. 이 수준의 성능은 미션 크리티컬 데이터베이스 애플리케이션, HPC 워크로드 및 I/O 집약적 웹 애플리케이션과 같은 사용 사례에 주로 사용됩니다.
성능 측면에서 우리는 로컬 NVMe 스토리지(DenseIO)와 네트워크 블록 스토리지(Standard)를 모두 사용하여 베어 메탈(BM) 및 VM 형태 모두에 대해 VDBech 테스트를 실행했습니다. 간단히 말해서 성능은 우리를 놀라게 했습니다. 각 테스트에 대해 DenseIO와 Standard 사이의 대기 시간 불일치가 너무 커서 모든 차트가 한 세트에 있으면 차트를 읽기 어려울 수 있으므로 두 세트의 차트를 실행했습니다. 이러한 인스턴스의 스토리지 성능이 기존 스토리지와 비교할 때 얼마나 좋은지 면에서 클라우드 대안은 말할 것도 없고 시중 최고의 공유 스토리지 옵션과 경쟁할 수 있습니다. iSCSI를 통해 호스팅되고 백업되는 연결된 BV는 짧은 지연 시간에 제공되는 강력한 처리량과 대역폭 조합을 제공합니다. 이를 맥락에서 설명하기 위해 32개의 OCPU 인스턴스에 연결된 52개의 BV를 사용한 많은 테스트가 실험실에서 테스트한 올플래시 스토리지 어레이의 성능을 초과하는 것으로 나타났습니다. 일부는 실제로 약간 더 빠를 수 있습니다. 클라우드 인스턴스를 $250 이상의 AFA, FC 스위칭 및 여러 컴퓨팅 호스트와 비교하고 있다는 점을 고려하면 꽤 인상적입니다.
그러나 Oracle Cloud 베어메탈 인스턴스를 정말 놀랍게 만드는 것은 로컬로 연결된 NVMe 스토리지입니다. DenseIO2.8에는 1개의 장치가 있는 반면 DenseIO2.52에는 8개의 장치가 있어 수백만 IOPS로 측정된 이러한 인스턴스 성능을 제공합니다. 1개의 NVMe SSD가 있는 인스턴스는 임의 4K 읽기 속도가 569k IOPS로 최고인 반면, 8개의 인스턴스는 성능이 4.4만 IOPS로 급증했습니다. 대역폭도 장난이 아니었습니다. 더 작은 인스턴스는 2.5GB/s 읽기 피크를 보였고 더 큰 인스턴스는 20GB/s 이상이었습니다. NVMe 모양은 결국 보호해야 하는 로컬로 연결된 스토리지이므로 백업 계획을 마련해야 합니다.
오라클은 클라우드에 최고 사양의 서버와 스토리지를 구축했습니다. 베어 메탈 인스턴스에 필적할 수 있는 유일한 것은 이를 지원하는 다른 모든 구성 요소 및 서비스와 함께 로컬에서 호스팅되는 최고 사양 서버를 구축하는 것입니다. 모든 클라우드 솔루션과 마찬가지로 Oracle은 인스턴스를 켜고 끌 수 있는 유연성과 필요에 따라 스토리지 요구 사항을 조정할 수 있는 유연성을 제공합니다. 이러한 경우에 발생하게 될 명백한 문제는 비용입니다. Oracle Cloud 내에서 인스턴스를 온라인으로 가져오는 편의성과 자체 데이터 센터에 유사한 하드웨어를 설정하는 데 필요한 노력과 비용이 아마도 주요 결정 요소일 것입니다. NVMe 연결 스토리지는 비싸지만 우리가 본 성능 이점에 대해서는 논쟁의 여지가 없습니다. 대규모 데이터 세트에 대한 처리 시간의 영향을 받는 비즈니스가 있는 경우 분석과 같은 워크로드를 완료하는 데 우리가 사용한 NVMe 기반 형태보다 더 쉽고 빠른 솔루션은 없습니다. 그리고 표준 부착 블록 모양이 나쁘다는 것이 아니라 NVMe 모양이 너무 비현실적이어서 나머지를 가려줍니다. 결론은 고성능 클라우드에서 측정 가능한 가치를 도출할 수 있는 미래 지향적인 기업은 Oracle이 진행 중인 작업을 확실히 평가해야 한다는 것입니다. 클라우드로 이동할 때 많은 선택이 있지만 Oracle Cloud 베어 메탈 인스턴스에서 본 것만큼 빠른 것은 없습니다. 따라서 이러한 솔루션은 클라우드 서비스에 수여되는 첫 번째 Editor's Choice Award를 수상할 자격이 있습니다. 공급자.
