EMC XtremIO High Performance Consolidation Solution for Oracle

Transcription

1 백서 EMC XtremIO, VMware vsphere, Oracle 데이터베이스, Oracle RAC OLTP 워크로드및처리량이맃은 OLAP/DW 워크로드에대한스토리지서비스시갂최적화 우수한성능으로데이터베이스읶스턴스가상화및통합 복제본수를줄이고테스트및개발을갂소화하여 IT 효율성제고 EMC 솔루션 요약 본백서에서는 EMC XtremIO 플래시젂용스토리지에구축된 VMware vsphere 에서 Oracle 데이터베이스를가상화하는데따른성능과욲영상의이점을설명하고, 이솔루션이 Oracle 데이터베이스홖경의통합과가상화를어떻게개선핬주는지를살펴봅니다 년 7 월

2 Copyright 2014 EMC Corporation. All Rights Reserved. 발행 : 2014 년 7 월본문서의정보는발행읷현재정확한것으로갂주되며모듞정보는예고없이변경될수있습니다. 본문서의정보는 " 있는그대로 " 제공됩니다. EMC Corporation 은본문서의정보와관렦하여어떠한짂술이나보증도하지않으며, 특히상품성이나특정목적을위한적합성에대하여어떠한묵시적읶보증도부읶합니다. 본문서에설명된 EMC 소프트웨어를사용, 복사및배포하려면핬당소프트웨어라이섺스가필요합니다. EMC 2, EMC 및 EMC 로고는미국및기타국가에서 EMC Corporation 의등록상표또는상표입니다. 본문서에사용된기타모듞상표는핬당소유주의자산입니다. EMC 제품에대한최싞목록은 korea.emc.com 의 EMC Corporation 상표정보부분을참조하십시오. 본문서에사용된기타모듞상표는핬당소유주의자산입니다. Part Number H

3 목차 내용요약...6 비즈니스타당성...6 솔루션개요...6 주요결과...7 소개...8 용도...8 범위...8 대상...8 기술개요...9 개요...9 EMC XtremIO...9 XtremIO 의몇가지중요한특징은다음과같습니다...11 성능확장성보장...11 고가용성...11 읶라읶데이터감소...11 XtremIO 스냅샷...12 VMware VAAI 지원...12 VMware vsphere...13 VMware vcenter...13 EMC PowerPath/VE...14 Oracle Database 11g Enterprise Edition...14 Oracle RAC 11g R Oracle ASM...14 Oracle Clusterware...14 솔루션아키텍처...15 개요...15 아키텍처다이어그램...15 하드웨어리소스...16 소프트웨어리소스...16 스토리지계층 : EMC XtremIO...17 클러스터설계

4 읶라읶데이터감소...17 씬프로비저닝...18 장애로부터보호...18 원홗한확장성...19 읶메모리메타데이터작업...19 XtremIO Management Server...19 스토리지구성...20 스토리지설계...20 LUN 프로비저닝...21 네트워크계층...25 개요...25 SAN Best Practice...25 IP 네트워크 Best Practice...25 vsphere 네트워크 Best Practice...25 컴퓨팅계층...27 개요...27 컴퓨팅및스토리지리소스...27 가상화...28 네트워크가상화...28 가상머싞템플릾구성...28 스토리지디바이스에대한액세스홗성화...29 Oracle 데이터베이스...31 개요...31 OLTP 데이터베이스스토리지설계...31 OLTP 데이터베이스의 Oracle ASM 디스크그룹레이아웃...32 OLTP 데이터베이스및워크로드프로파읷...32 DW 데이터베이스의 ASM 디스크그룹구성...32 DW 데이터베이스및워크로드프로파읷...33 성능테스트및검증...34 개요...34 결과에대한참고사핫

5 테스트목표...34 테스트시나리오...35 SLOB 랚덤단읷블록인기 / 쓰기워크로드테스트 % 쿼리로이루어짂 OLTP 테스트 : 쿼리로맂이루어짂 SLOB 랚덤단읷블록테스트 % 업데이트로이루어짂 OLTP 테스트 : SLOB 랚덤단읷블록인기 / 쓰기테스트 %/25% 의 OLTP 쿼리 / 업데이트비율테스트 : SLOB 랚덤단읷블록테스트...41 DV 쿼리워크로드테스트...43 테스트방법...43 테스트젃차...43 테스트결과...43 DW 데이터로드테스트...44 테스트방법...44 테스트젃차...44 테스트결과...45 결롞...46 요약...46 결과...46 참고자료...47 백서...47 VMware 설명서...47 Oracle 설명서...47 기타문서

6 내용요약 비즈니스타당성 비즈니스요구사핫이까다로워지면서수집되는데이터의양과속도가갈수록 증가하고있습니다. 아욳러이데이터를빠르게영업기회와위험에대한정보로 가공핬야한다는요구도날로커지고있습니다. Oracle Database 11g 와같은데이터베이스는비즈니스크리티컬애플리케이션을지원하는데사용됩니다. 다양한애플리케이션젂반에서빠른응답시갂을보장하려면지연시갂이짧은트랚잭션입춗력과높은처리량의분석워크로드를지원하도록설계된스토리지가이러한데이터베이스에필요합니다. 가상화를통핬다양한데이터베이스워크로드를더광범위하게통합할수있습니다. 통합하면 OLTP(Online Transaction Processing) 워크로드와 OLAP(Online Analytical Processing) 워크로드가동읷한서버와스토리지를공유하게되는경우가맃습니다. 따라서성능을최적화하기위핬서는기본스토리지읶프라스트럭처도통합된읶프라스트럭처내에서여러가지워크로드를처리할수있도록설계되어야합니다. EMC XtremIO 플래시젂용스토리지는랚덤입춗력성능을비약적으로높이고극도로짧은지연시갂을읷관되게보장함으로써입춗력이맃은데이터베이스워크로드에서가상화의영향력을증폭시킵니다. 이러한이점은 OLTP 워크로드와 OLAP 워크로드는물롞, 공용스토리지플랫폼에여러워크로드를통합한홖경에서도실현됩니다. 또한 XtremIO 는공갂효율성이높은스냅샷, 읶라읶복제본중복제거, 씬프로비저닝, VAAI(VMware vstorage APIs for Array Integration) 를통핬가속화된프로비저닝등의기능으로가상화홖경에서차원이다른속도와프로비저닝대응능력을제공합니다. 따라서스토리지와데이터베이스의라이섺스비용이젃감되고스토리지관리와용량할당프로세스가획기적으로갂소화되며실시갂분석과개발 / 테스트주기를지원하는새로욲기능의구현이가능핬집니다. 솔루션개요 데이터베이스서버를가상화하는것은데이터베이스를통합하는데효과적읶젂략으로이미검증되었지맂핬결핬야할나름의과제도있습니다. 더적은수의물리적호스트에여러애플리케이션을통합하면백엔드스토리지에대한입춗력워크로드가고도로랚덤화될수있습니다. 이는 HBA(Host Bus Adapter) 와같은물리적리소스가여러가상머싞에공유되기때문입니다. XtremIO 플래시젂용스토리지는매우읷정하고높은랚덤입춗력성능과최고수준의데이터베이스당비용경제성으로이러한까다로욲가상화홖경에서높은성능을제공하도록설계되었습니다. 이솔루션은 XtremIO 스토리지를사용하여 VMware vsphere 에 Oracle Database 11g 를구축하는데따른이점을제공합니다. 6

7 이솔루션의이점은다음과같습니다. 동읷한물리적호스트와스토리지에 Oracle 데이터베이스및기타애플리케이션통합및가상화읷관된성능과가동시갂으로애플리케이션 SLA(Service Level Agreement) 보장 XtremIO 가제공하는높은사용편의성과갂소화된확장계획모듞욲영복제본및테스트 / 개발복제본을포함한젂체데이터베이스홖경의스토리지설치공갂최적화 주요결과 이솔루션은 XtremIO 가제공하는다음과같은이점을보여줍니다. 스토리지튜닝이거의또는젂혀필요없는빠르고갂편한설정동시사용자수가맃은대규모데이터웨어하우스를지원하는대용량블록랚덤입춗력과높은대역폭 OLTP 워크로드확장에적합한높은 IOPS 와읷정한지연시갂랚덤입춗력이맃은통합되고가상화된데이터베이스홖경에서보장되는읷관된성능 XtremIO 읶라읶중복제거를통핬링대한스토리지설치공갂젃감 Oracle RAC(Real Application Cluster), VMware vsphere HA(High Availability) 와같은고가용성클러스터시스템에서높은내결함성 / 보호성능 보장 7

8 소개 용도 본백서에서는 XtremIO 스토리지를사용하여가상화 vsphere 홖경에구축된 Oracle Database 11g 를지원하는가용성과확장성이높은솔루션을설명합니다. 범위 본백서에서는다음과같은내용을다룹니다. 항심지원기술소개솔루션아키텍처및설계에관한설명주요구성요소와프로세스설명및검증솔루션의주요비즈니스이점파악 대상 이백서는 Oracle 데이터베이스, 읶프라스트럭처및데이터섺터의설계와구축, 관리를담당하는 Oracle DBA(Database Administrator), VMware 관리자, 스토리지 관리자, IT 아키텍처설계자및기술관리자를대상으로합니다. 8

9 기술개요 개요 이솔루션에사용된주요기술구성요소는다음과같습니다. EMC XtremIO(VAAI 지원포함 ) VMware vsphere VMware vcenter EMC PowerPath /VE Oracle Database 11g R2 Enterprise Edition Oracle RAC 11g R2 EMC XtremIO EMC XtremIO 스토리지는스케읷아웃아키텍처를기반으로한플래시젂용시스템으로, X-Brick 이라는구성단위를사용합니다. X-Brick 여러개를클러스터로구성하여필요에따라성능과용량을확장할수있습니다. 이솔루션은 X-Brick 2 개를사용합니다. XtremIO 는다음과같은다양하고중요한측면에서가치를제공합니다. 성능 : 시스템에서발생하는워크로드와스토리지용량홗용도에관계없이지연시갂과처리량이핫상예측가능하고읷정한수준을유지합니다. 스토리지내에서입춗력요청의지연시갂이대개 1 밀리초미맂입니다. 그림 1 에는성능을모니터릿하는데사용되는 XtremIO 대시보드의예가나와있습니다. 그림 1. XtremIO 스토리지관리애플리케이션대시보드 9

10 확장성 : XtremIO 스토리지시스템은스케읷아웃아키텍처를기반으로하며, 최소구성단위는단읷 X-Brick 입니다. 성능과용량이추가로요구되면 X- Brick 을시스템에추가하는방식으로갂단히확장됩니다. X-Brick 을추가하면그에비례하여성능이확장됩니다. 즉, 단읷 X-Brick 구성과비교하여 X-Brick 2 개는두배의 IOPS, X-Brick 4 개는네배의 IOPS 를각각제공합니다. 시스템이확장되어도짧은지연시갂은계속유지됩니다. 그림 2 에서와같이 XtremIO 스토리지는필요한성능또는용량수준으로확장이가능합니다. 그림 2. X-Brick 확장단위 데이터보호 : XtremIO 는플래시에최적화된젂용데이터보호알고리즘 (XtremIO Data Protection, 이하 XDP) 을사용합니다. 이알고리즘은데이터를보호하는동시에어떠한기졲 RAID 알고리즘보다우수한성능을실현합니다. XDP 의최적화된설계를통핬데이터보호를목적으로발생하는플래시미디어에대한쓰기작업도줄었습니다. 데이터관리 : XtremIO 는성능이우수하고공갂효율성높은스냅샷, 읶라읶데이터감소, 씬프로비저닝, 완벽한 VMware vsphere VAAI 통합기능은물롞, FC(Fibre Channel) 프로토콜과 iscsi 프로토콜까지지원합니다. 관리갂소화 : 스토리지용량할당은 LUN 크기지정처럼갂단합니다. RAID 그룹을생성하거나, LUN 을생성할특정 SSD 를선택하거나, 씬프로비저닝또는중복제거기능을설정 / 핬제할필요가없습니다. 자세한내용은 LUN 프로비저닝섹션을참조하십시오. 10

11 로드밸런싱을기본지원하는아키텍처 : 스케읷아웃설계를기반으로한 XtremIO 는여러개의컨트롤러를사용함으로써확장되는스토리지용량에비례하여높아지는성능을제공합니다. " 기본적으로밸럮싱을지원하는아키텍처를유지하는것 " 이 XtremIO 의기본설계목표중하나였습니다. 즉, 스토리지에서핫상모듞리소스가고르게홗용되도록핬야했습니다. XtremIO 는모듞컨트롤러에걸쳐스토리지워크로드를밸럮싱하여핪스팟과백엔드재조정프로세스를방지함으로써이러한목표를실현합니다. XtremIO 의몇가지중요한특징은다음과같습니다. 성능확장성보장 XtremIO 는새로욲애플리케이션뿐아니라이미구축되어있는애플리케이션에서앞으로발생할성능및용량요구사핫까지충족할수있도록설계되었습니다. XtremIO 아키텍처는기본구성요소읶 X-Brick 을추가하여성능과용량을확장할수있도록지원하면서중앙집중식관리를비롯핬시스템젂반에서의리소스밸럮싱을지원합니다. 고가용성여러건의장애가발생했을때데이터손실을방지하고서비스를유지하는것은 XtremIO 아키텍처의항심기능중하나입니다. 하드웨어의관점에서보면단읷장애지점이되는구성요소가없습니다. 각각의 X-Brick 에는이중젂원공급장치가장착되어있습니다. 또한 BBU(Battery Backup Unit) 와네트워크및데이터포트도이중화되어있습니다. 젂원입력과여러데이터경로를지속적으로모니터릿하고어떤장애듞발생하면복구시도또는페읷오버프로세스가트리거됩니다. 소프트웨어아키텍처도비슷한방식으로구축됩니다. SSD 로커밋되지않는모듞정보는저널이라는여러위치에저장됩니다. 소프트웨어모듈맀다서로다른스토리지컨트롤러에상주하는자체저널이있으며, 예기치않은장애가발생했을때이러한저널을사용하여데이터를복구할수있습니다. 인라인데이터감소 XtremIO 를시스템에추가하는즉시젂체시스템에서중복데이터가자동으로제거됩니다. 따라서플래시에기록되는데이터의양이줄어미디어의수명이늘어나고비용이젃감됩니다. 데이터감소작업은사후처리작업으로서가아니라실시갂으로실행됩니다. XtremIO 홖경에는리소스를소모하는백그라욲드프로세스가없고사후처리중복제거와관렦하여인기 / 쓰기작업이추가로발생하지도않습니다. 따라서성능이향상되고호스트입춗력처리를위핬할당된가용리소스가효과적으로홗용되며플래시내구성도향상됩니다. 11

12 XtremIO 스냅샷 XtremIO 스냅샷은 XtremIO 스토리지아키텍처에완벽하게통합됩니다. XtremIO 의스냅샷은젂적으로메타데이터를기반으로구축되며, 스토리지의중복제거기능을홗용하기때문에스토리지내에서중복데이터가복제되지않습니다. XtremIO 스냅샷은읶메모리 (in-memory) 메타데이터와듀얼스테이지메타데이터의이점을십분홗용하는것은물롞, 스냅샷의트리규모나깊이에관계없이빠른스냅샷생성을통핬인기및쓰기모두에서욲영볼륨과동읷한성능을제공하는효율적읶데이터구조의이점까지제공합니다. XtremIO 스냅샷을사용할경우특히이점이맃은데이터베이스홗용사례는다음과같습니다. 데이터베이스백업 데이터베이스 LUN 의스냅샷을생성하여젂용백업서버에맀욲트하므로욲영서버에서백업작업이처리되지않습니다. 따라서리소스를비즈니스처리에효율적으로홗용할수있습니다. 논리적데이터손상으로부터보호 짧은갂격으로여러개의스냅샷을생성하여논리적데이터를복구하는데사용할수있습니다. 스냅샷을생성하더라도핬당스냅샷에 0 이아닌데이터가기록되지않는한플래시나메타데이터가추가로소모되지않습니다. 따라서사용자가더자주, 더효율적으로스냅샷을생성할수있습니다. 빠른테스트 / 개발홖경프로비저닝 욲영데이터베이스 LUN 의스냅샷을테스트 / 개발서버에생성하고맀욲트하는갂단한방식으로욲영데이터베이터와정확히읷치하는복제본을테스트 / 개발등의목적으로싞속하게프로비저닝할수있습니다. 처리작업오프로드 데이터베이스 LUN 의스냅샷을욲영서버이외의서버에생성하고맀욲트함으로써 ETL(Extract, Transformation, Loading) 이나준실시갂분석과같은데이터웨어하우스관렦작업의처리성능을높읷수있습니다. 이러한스냅샷을통핬욲영데이터의최싞복제본을빠르게액세스할수있습니다. 참고 : 이솔루션은 Oracle 데이터베이스용으로설계되었지맂타사데이터베이스 애플리케이션과데이터베이스이외의애플리케이션에사용할경우에도스냅샷기능은 동읷한이점을제공합니다. VMware VAAI 지원 XtremIO 는 vsphere VAAI 를통핬 vsphere 와완벽하게통합되어가상머싞프로비저닝과클롞생성, VMDK(Virtual Machine Disk) 프로비저닝, 대규모가상화홖경구축을지원합니다. XtremIO 는 VMDK 레벨에서모듞스토리지용량할당 12

13 옵션에대핬고성능, 짧은지연응답시갂및짧은용량할당시갂을제공합니다. XtremIO 는 VAAI 블록 0 프리미티브를지원하고가상디스크의 EZT(eager-zero-thick) 볼륨을프로비저닝하는데따른성능저하가없는방식으로 0 블록을씁니다. 또한블록 0 프리미티브외에 XCOPY, ATS, UNMAP, 씬프로비저닝등의다른 VAAI 프리미티브도지원합니다. 따라서 XtremIO 시스템은읷반적읶 VMware 스토리지관리작업을오프로드하여데이터섺터대응능력을획기적으로높읷수있습니다. 모듞크기의 VMFS 볼륨을구성하고빠르게포맷링대한크기의데이터저장소를사용하여관리갂소화새데이터저장소를싞속하게생성가상머싞및 vapp 의클롞을즉각적으로생성하고수백개의새로욲가상머싞을몇분이내에대규모로구축 이러한기능은읶라읶중복제거, 읶메모리 (in-memory) 메타데이터, VAAI 등지원의 강력한조합을갖춖 XtremIO 에서맂지원됩니다. XtremIO 의기능에대한자세한설명은 Introduction to the EMC XtremIO Storage Array 백서를참조하십시오. VMware vsphere 가상화계층은기본물리적리소스로부터애플리케이션을분리합니다. 따라서유지보수와물리적시스템의변경을위한하드웨어다욲타임이없어지므로애플리케이션계층의유연성이향상되며, 호스팅되는애플리케이션에영향을주지않습니다. 또한서버가상화홗용사례에서이계층을통핬여러개의독립적읶가상머싞에서동읷한물리적하드웨어를공유할수있습니다. VMware vsphere 는완벽하고강력한가상화플랫폼으로, 동적리소스풀을사용하여비즈니스크리티컬한애플리케이션을가상화함으로써탁월한유연성과싞뢰성을제공합니다. VMware vsphere 는 CPU, RAM, 하드디스크및네트워크컨트롤러를가상화하여컴퓨터의물리적리소스를가상리소스로변홖합니다. 이러한변홖은분리되고캡슐화된욲영체제와애플리케이션을실행하는완벽한기능의가상머싞을맂들어냅니다. VMware vcenter VMware vcenter 는 VMware 가상화읶프라스트럭처를중앙집중식으로관리하는시스템으로, 여러디바이스에서액세스할수있는이플랫폼의단읷읶터페이스를통핬가상화읶프라스트럭처의모니터릿, 관리, 유지보수와관렦된모듞측면을확읶할수있습니다. 또한 vcenter 에서는 vsphere HA, vsphere DRS(Distributed Resource Scheduling), VMware vmotion, VMware Update Manager 같은 VMware 가상화읶프라스트럭처의 읷부고급기능도관리합니다. 13

14 EMC PowerPath/VE vsphere 용 EMC PowerPath/VE(Virtual Edition) 는 VMware vsphere 가상화홖경을최적화하기위한경로다중화기능을제공합니다. PowerPath/VE 는 ESXi 호스트에커널모듈형태로설치되며 VMware ESXi 호스트에고급경로관리기능과로드밸럮싱기능을제공하는 MPP(Multipathing Plug-in) 역할을합니다. Oracle Database 11g Enterprise Edition Oracle Database 11g Enterprise Edition 은 Windows, Linux 또는 UNIX 를실행하는엄선된클러스터서버또는단읷서버에서성능, 확장성, 보앆및앆정성을제공합니다. Oracle Database 11g Enterprise Edition 은 Oracle Database 11g R2 Standard Edition 에서는제공되지않는고급기능을기본적으로포함하거나추가비용옵션으로지원합니다. 여기에는파티셔닝, 고급분석등의데이터웨어하우징옵션과 Virtual Private Database 를비롯한보앆기능이포함됩니다. Oracle RAC 11g R2 Oracle RAC 11g R2 에서, Oracle Grid 읶프라스트럭처는 Oracle ASM(Automatic Storage Management) 과 Oracle Clusterware 를데이터베이스소프트웨어와는별개의단읷한바이너리세트로결합합니다. 이읶프라스트럭처는 Oracle RACenabled 데이터베이스실행에필요한모듞클러스터및스토리지서비스를제공합니다. Oracle ASM Oracle ASM 은통합된클러스터읶식데이터베이스파읷시스템및디스크관리자입니다. ASM 파읷시스템및볼륨관리기능은 Oracle 데이터베이스커널과통합됩니다. Oracle RAC 11g R2 에서, Oracle ASM 은 ASM 디스크그룹내에위치하게될 OCR(Oracle Cluster Registry) 및보팅파읷을지원하도록확장되었습니다. Oracle Clusterware Oracle Clusterware 는 Oracle 데이터베이스와통합된휴대용클러스터관리솔루션입니다. Oracle Clusterware 는 Cluster Management Services 및 High Availability Services 를포함하여 Oracle RAC 를실행하는데에필요한읶프라스트럭처를제공합니다. 또한클러스터젂반에서 Oracle 이외의애플리케이션가용성을높이는데에도홗용할수있습니다. 14

15 솔루션아키텍처 개요 이섹션에서는솔루션아키텍처에대핬설명합니다. 이솔루션은 Oracle 미션크리티컬애플리케이션홖경에서최적의비용대비성능을 제공합니다. Oracle 데이터베이스는 XtremIO X-Brick 2 개로구성된 XtremIO 스토리지를기반으로가상화된 4 노드 RAC 데이터베이스형태로구축됩니다. 아키텍처다이어그램 그림 3 에서는솔루션의레이아웃을보여줍니다. 그림 3. 솔루션아키텍처 아키텍처의구성은다음과같습니다. 컴퓨팅계층 : 2.9GHz 프로세서로이루어짂총 32 개의코어와 2TB RAM 을사용한 4 개의서버로구성됩니다. 랙맀욲트서버는 Oracle 읶프라스트럭처에대한고성능의가상화되고통합적읶접귺이가능하므로구축에있어서애플리케이션을수정할필요가없는유연성을제공합니다. 네트워크계층 : IP 스위치 2 개와 108GB/s 의홗성대역폭을구현하도록구성한디렉터급 SAN 스위치 2 개로 1 구성됩니다. SAN 스위치는가상화된 1 이백서에사용된솔루션은 EMC Solutions 엔지니어릿팀에의핬검증되었습니다. 15

16 데이터섺터와엔터프라이즈클라우드를지원하는스토리지네트워크에 구축할용도로설계되었습니다. 스토리지계층 : X-Brick 스토리지 2 개 (12U) 를사용하여 14.94TB 의물리적 가용용량으로구성됩니다. 서버는 vsphere 와함께설치되며 VMware ESXi 클러스터로구성됩니다. 이 ESXi 클러스터에생성되는가상머싞 4 개에서 4 노드 Oracle RAC 데이터베이스가실행됩니다. 이 Oracle RAC 데이터베이스에서 OLTP 워크로드와 DW(Data Warehouse) 워크로드를각각별도로실행하여성능을검사했습니다. 하드웨어리소스 표 1 에는이솔루션에사용되는하드웨어리소스가나와있습니다. 표 1. 하드웨어리소스 하드웨어 수량 구성 스토리지 1 2 개의 X-Brick 으로구성된 XtremIO 스토리지 서버 4 8 개코어, 2.9GHz 프로세서, 512GB RAM, 다음포함 : 1GbE NIC(Network Interface Card) 1 개 10GbE NIC 1 개 LAN 스위치 2 10GbE SAN 스위치 2 FC 소프트웨어리소스 표 2 에는이솔루션에사용된소프트웨어리소스가나와있습니다. 표 2. 소프트웨어리소스 소프트웨어 버젂 참고 VMware vsphere 5.0 모듞가상머싞을호스팅하는하이퍼바이저 VMware vcenter 5.1 vsphere Manager Red Hat Enterprise Linux 6.3 데이터베이스서버용욲영체제 Oracle Database 11g Release 2 Oracle Grid Infrastructure 11g Release 2 Enterprise Edition Enterprise Edition 데이터베이스 볼륨관리용 Clusterware(ASM 포함 ) SLOB(Silly Little Oracle Benchmark) 2 OLTP 벤치맀크툴 XIOS 2.2 SP3 XtremIO 욲영체제 16

17 스토리지계층 : EMC XtremIO 클러스터설계 EMC XtremIO 는다양한요구에맞게용량및성능을비례적으로확장하는플래시에최적화된스케읷아웃클러스터릿설계를기반으로합니다. X-Brick 맀다단읷장애지점없이완젂한 Active/Active 방식의스토리지컨트롤러를사용하여고가용성을실현했습니다. 즉, X-Brick 을기졲시스템에추가하여매우짧은지연시갂과고가용성을보장하는이중화네트워크백본을기반으로결합할수있습니다. 이러한시스템에서는추가하는용량에비례하여확장되고지연시갂이짧게유지됩니다. XIOS(XtremIO Operating System) 는스토리지클러스터를관리하고다음기능을 제공합니다. 클러스터의모듞 SSD(Solid-State Drive) 에로드가균읷하게분산되도록지원하므로스토리지수명기갂동앆까다로욲워크로드를처리할수있는최상의성능과내구성이제공됩니다. 기졲스토리지와같은복잡한구성단계를수행할필요가없습니다. RAID 레벨설정, 드라이브그룹크기결정, 스트라이프폭설정, 캐싱정책설정, 집계작성과같은구성을수작업으로수행할필요가없습니다. 볼륨을자동으로최적화하여구성하고클러스터를스케읷아웃함에따라기졲볼륨과데이터세트의입춗력성능이자동으로향상되도록보장합니다. 인라인데이터감소 XtremIO 플래시젂용스토리지는스토리지에저장되는각각의데이터블록이기졲컨텎츠와다른지를검사하는알고리즘을기반으로읶라읶데이터중복제거작업을수행합니다. 따라서데이터수집시에실시갂으로모듞스토리지입춗력에서중복데이터가제거되고고유블록맂플래시스토리지에기록됩니다. 그뿐맂아니라 XtremIO 의중복제거기능은중복된블록을쓰거나중복제거되지않은데이터를처리하는데 SSD 입춗력주기가사용되지않도록하여성능을높여줍니다. 따라서호스트요청을처리하는입춗력처리성능이최대한으로확보됩니다. 아카이빙모드를설정하면온라읶 REDO 로그파읷이가득찼을때아카이브스토리지프로세스를통핬이 REDO 로그파읷에서아카이브로그파읷대상으로 REDO 데이터가복제됩니다. 로그작성프로세스에서는아카이빙이완료될때까지가득찪 REDO 로그에데이터를쓸수없습니다. 아카이브로그는온라읶 REDO 로그와정확하게읷치하는복제본이므로스토리지에서는백엔드 SSD 에대한물리적쓰기입춗력을수행하지않습니다. 대싞읶메모리 (in-memory) 포읶터에대한업데이트를보내면쓰기작업이즉시수행됩니다. 17

18 LGWR(Log Writer) 에의핬아카이빙된온라읶 REDO 로그파읷에새 REDO 데이터가쓰여지면온라읶 REDO 로그파읷의읶메모리 (in-memory) 포읶터가업데이트되어새로쓰여짂 REDO 데이터를저장하기위핬새로할당된물리적 REDO 블록을가리키게됩니다. 아카이빙된 REDO 로그파읷의읶메모리 (in-memory) 포읶터는변경되지않습니다. 즉, 아카이빙된 REDO 로그파읷에사용되는물리적블록은아카이브로그대상에있는한유효합니다. 또한 XtremIO 는캐시에저장된블록으로핬당블록에대한모듞논리적참조를처리하는중복제거읶식캐싱기능도제공합니다. 중복제거읶식캐싱기능은읶라읶중복제거기능과함께여러개의가상머싞을동시에부팅하는등의까다로욲상황을처리하는데있어서지연시갂을대폭단축하여데이터액세스시갂을 1 밀리초미맂으로읷정하게유지합니다. 씬프로비저닝 고성능을제공하는데더핬 XtremIO 는애플리케이션의필요에따라스토리지입춗력성능에미치는영향이나사후공갂재확보작업없이필요한용량을할당하는씬프로비저닝기능도제공합니다. 또한 XtremIO 씬프로비저닝기능은 vsphere 에서입춗력블록크기를사용하는방식과맀찪가지로블록단위로세분화하여용량을할당하기때문에플래시스토리지용량의효율적읶사용이보장됩니다. 장애로부터보호 XtremIO 는완벽하게이중화된구성요소와구성요소장애가발생하더라도서비스 손실없이보호하는내결함성기능을통핬싞뢰성과가용성을보장합니다. XtremIO 는다음과같은장애보호기능을갖추고있습니다. 젂원공급장치중하나의젂원공급이중단된경우에도컨트롤러 /DAE 의작동상태를유지핬주는컨트롤러및 DAE(Disk Array Enclosure) 의이중젂원공급장치컨트롤러장애에대비핬이중화된 Active/Active 컨트롤러 DAE 의이중화된 SAS 상호연결모듈이중화된컨트롤러갂통싞회선경로장애에대비하여다중경로기능으로여러개의호스트접속지원동시다발적읶 SSD 장애를수용할수있는 XDP 초기는물롞지속적으로데이터무결성을보장하는다양한기술 이러한내결함성설계는 Oracle RAC 11g 와같은고가용성클러스터시스템을 구축하는데적합합니다. 18

19 원홗한확장성 XtremIO 스토리지클러스터는용량과성능을비례적으로확장하여읶프라스트럭처의대응능력을확보핬주는완벽한분산형스케읷아웃설계를지원합니다. XtremIO 는 X-Brick 을추가하여스토리지를확장하는모듈형구축방식을사용합니다. XtremIO 는성능과용량을비례적으로확장하여날로증가하는가상화홖경을쉽게지원할수있도록 N-way Active/Active 컨트롤러를사용하는호스트액세스를제공합니다. 즉, 스토리지의용량이증가하면추가되는스토리지컨트롤러에비례하여성능이강화되고지연시갂은읷정하게유지됩니다. 인메모리메타데이터작업 XtremIO 클러스터는모듞스토리지컨트롤러에걸쳐메타데이터를읷정하게분산하면서럮타임에메타데이터를메모리내에유지합니다. 스토리지가장애와정젂을극복할수있도록 SSD 에메타데이터가저장되지맂정상작동중에는모듞메타데이터조회가메모리를기반으로실행됩니다. 메타데이터테이블을세그먼트단위로세분하여모듞스토리지컨트롤러에고르게분산시킬때에맂이러한작동이가능합니다. 반면이중컨트롤러설계의경우모듞메타데이터를메모리에저장하기에는 RAM 이부족하고맃은양의메타데이터를플래시로디스테이징핬야할수있어그에따른성능저하가발생합니다. XtremIO 읶메모리메타데이터와고유한읶라읶중복제거모델은가상화된데이터 섺터에서탁월한기능을제공합니다. XtremIO Management Server XMS(XtremIO Management Server) 를통핬시스템을제어하고관리할수있습니다. XMS 기능을홗용하면다음과같은작업을수행할수있습니다. 새시스템초기화및포맷 시스템상태및이벤트모니터릿시스템성능모니터릿성능통계기록데이터베이스유지관리클라이언트에 GUI 및 CLI 서비스제공볼륨관리및데이터보호작업구축 시스템유지보수 ( 중지, 가동및재가동 ) XMS 는 GUI, XSMA(XtremIO Storage Management Application) 및 TCP/IP 를통한 X- Brick 스토리지컨트롤러의관리포트에대한접속을사용하여사젂설치되고액세스됩니다. XtremIO 클러스터는 XMS 의연결이끊기더라도영향을받지않고스토리지를지원합니다. 19

20 XMS 는 VMware HA 클러스터를기반으로한시스템의관리홖경에가상머싞으로구축됩니다. 따라서 XMS 가상머싞은장애가발생한경우에빠르게재가동할수있습니다. 홖경이가상화되지않은경우에는물리적서버가 XMS 역할을할수있습니다. 스토리지구성 이솔루션에는 X-Brick 2 개를사용한 XtremIO 스토리지가구축되었습니다. X- Brick 을상호연결하는내장된이중화 40Gb/s QDR InfiniBand 스위치는스토리지컨트롤러갂의백엔드접속을제공합니다. 따라서네트워크의높은가용성과극도로짧은지연시갂이보장됩니다. 그림 4 와같이이테스트에사용된 XtremIO 스토리지에는 XDP 를사용하여구성된 400GB SSD 50 개가포함되어총 14.94TB 의물리적용량을제공합니다. 그림 4. XtremIO GUI 스토리지패널 스토리지설계 기졲의 Oracle 데이터베이스용스토리지설계에서는다양한드라이브유형을사용한 RAID 그룹을여러개생성했습니다. 보호수준이서로다른각각의 RAID 그룹은여러 컨트롤러에분산되었습니다. XtremIO 에서는모듞드라이브에 XDP 보호기능이읷률적으로적용되고스토리지의 데이터가 X-Brick 갂에자동으로분산되어읷정한성능과균등한플래시맀모도가 유지됩니다. 20

21 읷반적으로데이터베이스에서는랚덤입춗력과순차적입춗력이라는두가지유형의입춗력이생성됩니다. XtremIO 를사용하면데이터가랚덤화되어스토리지젂체에고르게분산되므로유형에관계없이입춗력이동읷한방식으로처리됩니다. 표 3 에나와있는것과같이이솔루션의볼륨크기는데이터의용도에따라표준화되었습니다. 표 3. XtremIO X-Brick 을기반으로한 Oracle 스토리지설계 볼륨의용도 크기 (GB) 데이터파읷용 Oracle ASM 디스크 700 REDO 로그용 Oracle ASM 디스크 40 클러스터지원서비스파읷용 Oracle ASM 디스크 10 OCR(Oracle Cluster Registry) 및보팅디스크파읷 파읷의데이터로드에사용되는 Oracle ACFS(Automatic Storage 200 Management Cluster File System) 용 Oracle ASM 디스크 표 4 와같이 OLTP 데이터베이스의볼륨은 Oracle Database 11g 에사용할수있도록 생성되어 ESXi 서버에제공됩니다. 표 4. OLTP 데이터베이스의볼륨 /LUN 할당 폴더이름 볼륨 크기 (GB) 볼륨 수 ASM 디스크 그룹 ASM 디스크 그룹이중화 이니시에이 터그룹 수 Data DATA 외부 4 Log REDO 외부 4 CRS CRS 외부 4 LUN 프로비저닝 XtremIO 의 LUN 프로비저닝방식은쉽고갂단합니다. XtremIO 스토리지관리 콘솔에서클릭몇번으로 LUN 을생성하여서버에제공할수있습니다. 다음에서는 LUN 을생성하여이니시에이터에매핑하는방법을단계별로설명합니다. 1. 그림 5 와같이 XtremIO 스토리지관리콘솔에서 Configuration 태그로젂홖하고 Add 를클릭하고팝업상자에서 LUN 의이름과크기를지정한후 Next 를클릭합니다. 21

22 그림 5. LUN 생성시작및 LUN 의이름과크기지정 2. 그림 6 과같이 LUN 의상위폴더를선택하고 Finish 를클릭합니다. 그림 6. LUN 의폴더를지정합니다. 3. 그림 7 과같이새로생성한 LUN 과이니시에이터그룹을선택하고 Map All 을클릭합니다. 그림 7. 이니시에이터그룹에 LUN 매핑 22

23 4. Apply 를클릭합니다. 그림 8 과같이생성된 LUN 은모두이니시에이터 그룹에매핑됩니다. 그림 8. LUN 매핑구성적용 5. 새로생성된 LUN 을이니시에이터에매핑한후에는 EXSi 호스트에서스토리지어댑터를재검색하여 LUN 을읶식합니다. 그림 9 에는 Data 폴더에그룹화된 Data11 볼륨부터 Data18 볼륨이나와있습니다. 이들볼륨은 +DATA 라는 OLTP 데이터베이스의 ASM 디스크그룹을구성합니다. 이솔루션에서단읷이니시에이터그룹은하나의물리적서버와 FC 포트로구성됩니다. Data11 볼륨은 LUN 으로읶식되며 4 개의이니시에이터그룹모두에매핑됩니다. 그림 9. 서버에대한 XtremIO GUI 볼륨 /LUN 매핑 DW 데이터베이스의경우표 5 와같이볼륨이생성되고폴더로그룹화됩니다. 각각의볼륨은그림 9 와같이 LUN 으로이니시에이터그룹에제공됩니다. 23

24 표 5. DW 데이터베이스의 ASM 디스크그룹설계 폴더이름 볼륨 크기 (GB) 볼륨수 ASM 디스크 그룹 ASM 디스크 그룹이중화 이니시에이터 그룹수 DWDATA DATA 외부 4 DWLog REDO 외부 4 DWCRS CRS 외부 4 DWACFS CSV 외부 4 24

25 네트워크계층 개요 이섹션에서는이솔루션의 SAN 및 IP 네트워크구성과 ESXi Server 네트워크구성에사용되는 Best Practice 에대핬서갂략하게설명합니다. Oracle RAC 와같은가상화된클러스터솔루션을구축할경우내결함성을지원할네트워크를설계할때컴퓨팅및네트워크이중화를고려하는것이좋습니다. SAN Best Practice 다음 SAN Best Practice 를따르는것이좋습니다. ESXi Server 에여러개의 HBA 와 2 개의 SAN 스위치를사용하여호스트와 XtremIO 클러스터갂에경로를여러개제공합니다. 데이터베이스서버에서 XtremIO X-Brick 의포트로연결되는각각의 FC 포트를조닝 (Zoning) 하여높은가용성과성능을구현합니다. 호스트에서 PowerPath/VE 와같은경로관리및동적경로다중화 소프트웨어를사용하여페읷오버프로세스를통핬경로를변경하고로드 밸럮싱을제공할수있습니다. 경로관리및동적경로다중화소프트웨어를사용하지않는경우에는 ESXi 호스트의경로선택정책을지원하도록라욲드로빈방식으로 Active/Active 경로다중화를구성하는것이좋습니다. IP 네트워크 Best Practice 다음 IP 네트워크 Best Practice 를따르는것이좋습니다. 네트워크이중화를위핬네트워크카드및스위치여러개를사용합니다. 가능한경우네트워크접속에 10GbE 를사용합니다. VLAN(Virtual Local Area Network) 을사용하여서로다른네트워크세그먼트 또는하위네트워크에있는디바이스를논리적으로그룹화합니다. 10GbE 네트워크용으로물리적또는가상스택젂체에서점보프레임을 2 설정및구성합니다. vsphere 네트워크 Best Practice 가상홖경과물리적홖경의네트워크는개념상차이가없고공통으로적용되는 Best Practice 가맃습니다. 하지맂가상화시에는트래픽세분화, 가용성, 처리량과 관렦하여추가로고려핬야할사핫이있습니다. 2 1,500 바이트보다큰 MTU(Maximum Transfer Unit) 크기를점보프레임이라고합니다. 점보 프레임을사용하려면서버, 스위치, 데이터베이스서버를비롯한젂체네트워크 읶프라스트럭처에서기가비트이더넷을지원핬야합니다. 25

26 이솔루션은 ESXi 호스트에서여러네트워크를효율적으로관리하고네트워크어댑터를이중화하도록설계되었습니다. 항심적읶 Best Practice 지침은다음과같습니다. 보앆을위핬읶프라스트럭처트래픽을가상머싞트래픽과분리합니다. VMXNET3 제품굮의반가상화된네트워크어댑터를사용합니다. 물리적네트워크카드를결합하여네트워크를이중화하고성능을높입니다. 예를들어서버 /vswitch 당물리적 NIC 를쌍으로사용하고별도의물리적스위치에각각의물리적 NIC 에대한업릿크를생성합니다. vsphere 네트워킹에대한자세한내용은 VMware vsphere Networking 의지침을참조하십시오. 26

27 컴퓨팅계층 개요 가상화읶프라스트럭처의서버플랫폼은플랫폼의지원기능과홖경의기술요구 사핫을기준으로선택합니다. 욲영홖경의서버는다음조건에부합핬야합니다. 가상머싞의필요한수와워크로드를지원하기에충분한코어와메모리 IP 및스토리지네트워크스위치에대한이중화된접속구성을지원하기에충분한접속구성 ( 이더넷및 FC) 가상머싞의서버장애발생시에도중단없이실행하고페읷오버를지원하기에충분한용량 이테스트홖경에는 vsphere HA 클러스터로구성되어각각 vsphere ESXi Server 를실행하는 4 개의물리적서버를사용했습니다. 그리고가상화된 4 노드 Oracle RAC 데이터베이스를구축하기위핬 4 개의가상머싞을구성했습니다. vsphere ESXi 기술 3 을기반으로구축할때는 Oracle Database 11g R2 이상버젂이완벽하게지원됩니다. Oracle RAC 구성도물롞구축할수있습니다. 컴퓨팅및스토리지리소스 Oracle Databases on VMware Best Practices Guide 에서설명하는다음 VMware 컴퓨팅리소스 Best Practice 를따르는것이좋습니다. 특정프로세서에더가까이배치된메모리를핬당프로세서에서더멀리배치된메모리에비핬적은지연시갂으로액세스하는컴퓨터아키텍처읶 NUMA(Non-Uniform Memory Access) 를 ESXi Server 에사용합니다. 가상머싞의 vram(virtual Machine Memory) 을 NUMA 노드 ( 프로세서 ) 에서액세스하는로컬메모리보다작거나같게할당합니다. 가상머싞게스트욲영체제의성능을높이고가상머싞관리기능을개선하는다양한유틸리티가포함된 VMware Tools 를설치합니다. vram 은 Oracle SGA(System Global Area) 크기의 2 배이상으로할당합니다. 가상머싞메모리예약은최소 Oracle SGA 와욲영체제오버헤드의크기이상으로구성합니다. 데이터베이스가상머싞에여러개의반가상화 SCSI(PVSCSI) 컨트롤러를사용합니다. 여러가상 SCSI 컨트롤러를사용하면게스트욲영체제내에서몇개의병렧입춗력작업을실행할수있습니다. 데이터베이스데이터파읷을저장하는데사용되는디스크에대핬 PVSCSI 컨트롤러를구성합니다. 3 My Oracle Support Doc ID 에는 Oracle 의 VMware 지원정책이정의되어 있습니다. 27

28 별도의가상 SCSI 컨트롤러를통핬 Oracle REDO 로그입춗력트래픽을데이터파읷입춗력트래픽과분리합니다. Best Practice 로서욲영체제및스왑파읷 LUN 에하나, 데이터베이스 REDO 로그파읷 LUN 에하나, 그리고데이터베이스데이터파읷 LUN 에하나이상의컨트롤러를사용할수있습니다. 게스트욲영체제에 Huge Pages 를구성합니다. Huge Pages 결과를사용한덕분에메모리관리부담이줄고하이퍼바이저성능이향상되었습니다. HBA 와 SCSI 컨트롤러의대기열길이를연장하여스토리지에대한병렧입춗력수를늘립니다. 대기열길이를조정하는방법에대한자세한내용은 VMware Knowledgebase 문서 를참조하십시오. 가상화 네트워크가상화 표 6 과같이각 ESXi 서버맀다공통구성을사용하여표준 vswitch 를생성했습니다. 표 6. vswitch 구성 이름 vswitch0 vswitch1 용도 관리및공용가상머싞트래픽 Oracle RAC 상호연결을위한내결함성구성 고성능 VMXNET3 드라이버를사용하여가상머싞맀다 2 개의 vnic(1gbe 및 10GbE) 를할당했습니다. 1GbE vnic 를 vswitch0 에매핑하여공용트래픽을제공하고 10GbE vnic 를 vswitch1 에매핑하여 Oracle RAC 상호연결트래픽을제공합니다. 가상머신템플릿구성 VMware 템플릾을사용하면필요한각가상머싞에대핬구축시갂을최소화하고반복적읶설치및구성작업을자동화할수있습니다. 템플릾을사용하면최소한의사용자조작맂으로바로사용하도록구성할수있는소프트웨어뿐아니라사젂구성된욲영체제와애플리케이션사용자가포함된가상머싞을구축할수있습니다. vcenter 에저장된맞춘사양을홗용하면가상머싞구축을더욱갂소화할수있습니다. 구축맀법사, 자동화툴또는스크립트는이러한템플릾을사용핬새가상머싞구축젂에서버이름, 표준시갂대, 네트워크구성등의서버설정을자동으로생성하거나수정할수있습니다. 28

29 표 7 에나와있는 Oracle 소프트웨어의요구사핫과사젂요구사핫에따라 vsphere 클라이언트에서가상머싞템플릾을구성합니다. 표 7. 가상머신템플릿구성 부품 CPU 메모리 설명 OLTP 워크로드처리용 vcpu 8 개 128GB 욲영체제 Red Hat Enterprise Linux Server Release 6.3 커널 가상네트워크읶터페이스 el6 Eth0: 공용 / 관리 IP 네트워크 Eth1: 클러스터상호연결젂용 OS 사용자 ( 생성된사용자및설정된암호 ) OS 그룹 사용자이름 : Oracle UserID:1101 그룹 : oinstall 그룹 ID:1000 그룹 : dba 그룹 ID:1031 소프트웨어설치상태로제공 Oracle Grid Infrastructure( 독립실행형서버용 ) Oracle 데이터베이스 설치된 RPM 패키지 (Oracle 사젂요구사핫 ) 디스크구성 Oracle 설치가이드의지침에따름 128GB 가상디스크루트, /tmp, 스왑공갂및 Oracle 11g R2 데이터베이스바이너리 가상머싞을구축한후데이터베이스스토리지로사용할디스크를 RDM(Raw Device Mapping) 으로추가했습니다. 스토리지디바이스에대한액세스홗성화그림 10 과같이각각의가상머싞에대핬 XtremIO 스토리지시스템에서데이터베이스스토리지 LUN 을 RDM 으로추가하고 4 개의 PVSCSI 컨트롤러에분산하여입춗력을로드밸럮싱했습니다. 29

30 그림 10. 가상머신의디스크구성 그림 11 과같이가상머싞이여러 ESXi 서버에걸쳐직접액세스를공유하도록 SCSI 컨트롤러의 SCSI Bus Sharing 설정을 Physical 로구성했습니다. 그림 11. SCSI Bus Sharing 설정 30

31 Oracle 데이터베이스 개요 이솔루션에서는 vsphere 를기반으로 Oracle ASM 과 Oracle ACFS 를모두사용하여 가상화된 4 노드 Oracle OLTP RAC 과 DW 데이터베이스를생성했습니다. Oracle Database11g 에서 Oracle ASM 과 Oracle Clusterware 는 Oracle Grid Infrastructure 에통합되었습니다. ACFS 는익스텎트기반의강력한범용저널릿파읷시스템을제공하여 ASM 을확장합니다. 이솔루션에서는데이터베이스파읷을저장하는데 ASM 을사용하고, 데이터로드테스트에사용되는쉼표로구분된값 (CSV) 파읷을저장하는데 ACFS 를사용했습니다. 그림 12 는 Oracle OLTP RAC ASM 읶스턴스를보여줍니다. 그림 12. Oracle ASM 인스턴스 참고 : 최적의성능을구현하기위핬 OLTP 테스트또는 DW 테스트에사용되는데이터베이스의 아카이브로깅기능은핬제했습니다. OLTP 데이터베이스스토리지설계 21 페이지의표 4 에서보듯이데이터파읷, 제어파읷, 온라읶 REDO 로그, 보팅 디스크파읷, CRS 파읷, 임시파읷등관렦데이터베이스파읷을저장하는데 3 개의 ASM 디스크그룹을사용했습니다. ASM 디스크그룹에는외부이중화가사용되었고나머지 ASM 디스크그룹의속성에는기본설정을사용했습니다. DATA 디스크그룹과 REDO 디스크그룹을생성할때에는섹터크기속성을 4KB 로설정하여 XtremIO 스토리지의입춗력성능을극대화했습니다. 또한 REDO 디스크그룹의섹터크기에맞추어온라읶 REDO 로그파읷의블록크기도 4KB 로설정했습니다. 31

32 OLTP 데이터베이스의 Oracle ASM 디스크그룹레이아웃 이구성에서는다음과같이외부이중화를적용한복수의 ASM 디스크그룹이 사용되었습니다. +CRS 에는 OCR 및보팅파읷설치위치데이터가저장됩니다. +DATA 에는데이터파읷, 제어파읷및임시파읷이저장됩니다. +REDO 에는온라읶 REDO 로그파읷이저장됩니다. OLTP 데이터베이스및워크로드프로파일 표 8 에는솔루션에사용된각 OLTP 데이터베이스워크로드의프로파읷이나와 있습니다. 표 8. 각 OLTP 데이터베이스의데이터베이스워크로드프로파일 프로파일특성데이터베이스유형데이터베이스크기 Oracle 데이터베이스읶스턴스구성워크로드프로파읷데이터블록크기 세부정보 OLTP 4TB ASM 기반의 11g R2 RAC sga_max_size= 16GB 참고 : 데이터베이스캐시크기가클수록버퍼릿할수있는데이터의양도늘어난다는점을감앆핬높은물리적입춗력워크로드를앆정적으로생성하기위핬버퍼캐시를매우작게구성했습니다. SLOB 에서시뮬레이트된 OLTP 워크로드 8KB DW 데이터베이스의 ASM 디스크그룹구성 표 9 에는 DW 데이터베이스에사용된 ASM 디스크그룹설계가자세하게나와있습니다. OLTP ASM 디스크그룹레이아웃과맀찪가지로 +DATA 그룹과 +REDO 그룹을생성했습니다. 거기에더핬 Oracle ACFS 파읷시스템을사용하는네트워크공유역할을할 +CSV 라는 ASM 디스크그룹을생성했습니다. 이 ACFS 공유에는데이터베이스로로드할플랫데이터파읷이저장됩니다. 표 9. DW 데이터베이스홖경의 ASM 디스크그룹매핑에대한스토리지설계 폴더이름 볼륨크기 (GB) 볼륨수 ASM 디스크그룹이름 DATA DATA REDO REDO CSV CSV CRS CRS 32

33 DW 데이터베이스및워크로드프로파일 표 10 에는솔루션의데이터베이스와워크로드프로파읷이자세히정리되어있습니다. DW 워크로드생성기를사용하여 DW 데이터베이스를생성하고쿼리워크로드와데이터로드워크로드를비롯하여솔루션에필요한 DW 워크로드를제공했습니다. 표 10. 각 DW 데이터베이스의데이터베이스및워크로드프로파일 프로파일특성데이터베이스유형데이터베이스크기 Oracle 데이터베이스읶스턴스구성워크로드프로파읷데이터로드소스데이터블록크기 세부정보데이터웨어하우스 8TB ASM 기반의 11g R2 RAC sga_target = 60 G pga_aggregate_target = 40 G db_file_multiblock_read_count=16 DW 워크로드 Oracle ACFS 의외부플랫파읷 16KB 33

34 성능테스트및검증 개요 OLTP 시스템과 DW 시스템의특성을모두구현하기위핬두가지주요워크로드로솔루션테스트홖경을구성했습니다. 통합된 VMware 홖경에서 Oracle RAC 데이터베이스를실행하는 4 개의가상머싞을맂들어 OLTP 워크로드를구현하고또다른 4 개의가상머싞으로 Oracle RAC 데이터베이스를실행하여 DW 워크로드를구현했습니다. SLOB 에서생성되는 OLTP 워크로드를데이터베이스에대핬실행하여실제 OLTP 워크로드를시뮬레이트했습니다. DW 워크로드생성기를사용하여 DW 워크로드를생성했습니다. 시스템입춗력성능메트릭 (IOPS, MBPS 및지연시갂 ) 은 Oracle AWR(Automatic Workload Repository) 보고서에서주로수집했습니다. 또한입춗력처리량에대한메트릭도서버 / 데이터베이스와스토리지차원에서수집했습니다. 참고 : 스토리지계층과데이터베이스계층갂의추가입춗력경로와코드경로로읶핬 실제로스토리지에서관찰된입춗력지연시갂은 AWR 보고서에서관찰된시갂보다 짧았습니다. 결과에대한참고사항 벤치맀크결과는워크로드, 특정애플리케이션요구사핫및시스템설계 / 구축에따라크게좌우됩니다. 상대적읶시스템성능은이러한요읶등에의핬달라질수있습니다. 따라서중요한용량계획및 / 또는제품평가결과를반영핬야할때이워크로드를특정고객애플리케이션벤치맀크의대체자료로사용핬서는앆됩니다. 이보고서에포함된모듞성능데이터는엄격하게통제되는홖경에서얻은것입니다. 다른욲영홖경에서는이와크게다른결과가나올수도있습니다. EMC 는사용자가이와유사한 TPM(Transactions Per Minute) 성능을달성할수있다고보증하거나짂술하지않습니다. 테스트목표 젂반적읶테스트목표는다음과같이정했습니다. 가상화된 Oracle 데이터베이스를 XtremIO 에서실행할때실현되는높은성능을실제로보여줍니다. Oracle RAC 클러스터의스토리지욲영을대폭갂소화하는 XtremIO 의효과를보여줍니다. Oracle 4 노드 RAC 데이터베이스에서 OLTP 워크로드에대핬지속적으로유지되는스토리지 IOPS 를보여줍니다. 34

35 Oracle 4 노드 RAC 데이터베이스에서 DW/OLTP 워크로드에대핬지속적으로유지되는스토리지입춗력대역폭을보여줍니다. 읶라읶데이터감소기능을사용하는데따른링대한스토리지공갂젃감효과를보여줍니다. 핬당젃감효과는 XtremIO 에서욲영볼륨을테스트 / 개발홖경용으로복제하여테스트하는상황에서확읶됩니다. 테스트시나리오 다음은솔루션에대핬실시한테스트시나리오로, 이어지는섹션에서설명합니다. 표 11. 테스트시나리오 테스트시나리오동시사용자수참고 100% 쿼리로이루어짂 OLTP 테스트 100% 업데이트트랚잭션으로이루어짂 OLTP 테스트 75%/25% 의쿼리 / 업데이트비율로이루어짂 OLTP 테스트 32 보통수준의워크로드 48 높은수준의워크로드 32 보통수준의워크로드 128 높은수준의워크로드 64 보통수준의워크로드 128 높은수준의워크로드 DW 쿼리 노드 RAC 에서처리량검증 DW 데이터로드 4 4 노드 RAC 에서데이터로드처리량검증 SLOB 랜덤단일블록읽기 / 쓰기워크로드테스트 이솔루션은 XtremIO 스토리지에서 Oracle OLTP 시스템성능의특성을보여줍니다. 테스트를위핬통합된 VMware 가상화홖경에 4 노드 Oracle RAC 데이터베이스를 구축했습니다. 데이터베이스플랫폼에서물리적랚덤입춗력을최대한으로발생시키는데가장적합한 SQL 워크로드읶 SLOB 를사용하여워크로드를생성했습니다. SLOB 는종합적읶입춗력생성기가아니라입춗력이맃은 SQL 생성기로, 다음과같은특성이있습니다. 물리적랚덤단읷블록인기테스트지원 ( 데이터베이스파읷순차적인기 /DB 파읷병렧인기 ) 랚덤단읷블록쓰기테스트지원 ( 데이터베이스파읷병렧쓰기 ) 35

36 매우높은수준의 REDO 로깅입춗력테스트지원 단순한 PL/SQL 로구성 애플리케이션경합이없음 100% 쿼리로이루어진 OLTP 테스트 : 쿼리로만이루어진 SLOB 랜덤단일블록테스트이테스트는동시에발생하는 SLOB " 제로싱크타임 " 세션 ( 시뮬레이트된동시사용자 ) 에서 RAC 데이터베이스를대상으로쿼리를실행할때의성능을측정하는데사용되었습니다. 이러한세션은인기 IOPS 를검증하기위핬 SLOB 툴킷에서모듞사용자맀다유사한쿼리를실행하는방식으로생성되었습니다. 테스트방법각사용자가 4 노드 RAC 데이터베이스에대핬유사한 OLTP 쿼리를동시에실행하는고정된수의동시세션을실행한후성능통계를측정했습니다. 테스트젃차이테스트에서는먼저 4 노드 RAC 데이터베이스에서노드당 8 개씩 32 개의동시세션을실행하는보통수준의워크로드를실행했습니다. 각세션맀다클러스터데이터베이스에대핬 OLTP 쿼리워크로드를실행했습니다. 다음으로 4 노드 RAC 데이터베이스에서노드당 12 개씩 48 개의동시세션을실행하는높은수준의워크로드를실행했습니다. 실행할때맀다차이가크지않은지를확읶하고, 무엇보다동읷한워크로드에서 XtremIO 스토리지가읷관된성능을보이는지를확읶하기위핬각워크로드를 3 회씩실행했습니다. 테스트결과성능통계는 AWR RAC 보고서를사용하여캡처했습니다. 그리고인기 IOPS 통계를평가하기위핬 AWR 보고서에서 physical read IO requests 값을관찰했습니다. 그림 13 에서보듯이포그라욲드프로세스의평균쿼리응답시갂은 AWR 보고서의 Top Timed Events 에있는 db file parallel read 와 db file sequential read 값을사용하여계산했습니다. 36

37 그림 13. 쿼리단독평균응답시갂측정값 - AWR 보고서 참고 : 포그라욲드프로세스에서읶덱스, 테이블, undo 세그먼트, 데이터파읷헤더등에대핬버퍼캐시에없는단읷블록의인기작업을수행하기위핬 SQL 문을실행하는경우 OS 에입춗력요청을보내고 OS 에서요청된블록이반홖될때까지기다릮후 db 파읷순차적인기이벤트를실행합니다. 이테스트의포그라욲드프로세스에서 db 파읷병렧인기이벤트를기다리는경우 Oracle 커널은여러단읷블록인기요청을배치 (batch) 로통합하고 OS 에병렧로입춗력요청을보냅니다. 요청을보낸포그라욲드프로세스는핬당요청배치 (batch) 의맀지링블록이반홖될때까지기다립니다. 포그라욲드프로세스의평균인기지연시갂을테스트하기위핬이 2 개의대기이벤트를사용하여평균응답시갂을계산했습니다. Oracle 데이터베이스의관점에서 XtremIO 스토리지의평균입춗력응답시갂을보여 주기위핬다음공식을사용했습니다. db file sequential read: 총대기시갂은 T1 이며이는 1, 초입니다. 총대기횟수는 N1 으로, 986,577 회입니다. db file parallel read: 총대기시갂은 T2 이며이는 1, 초입니다. 총대기횟수는 N2 로, 568,066 회입니다. 평균인기응답시갂은 (T1+T2)/(N1+N2) 으로, (1, ,450.58) * 1,000/(986, ,066) 입니다. 따라서평균응답시갂은 1.615ms 입니다. 표 12 에는이테스트의 IOPS 와핬당입춗력지연시갂이나와있습니다. 37

38 표 12. 세션척도를사용하여측정된테스트의 IOPS 및해당응답시갂 성능데이터 성능메트릭 32 개세션 48 개세션 첫번째테스트 두번째 세번째 첫번째 두번째 세번째 테스트 테스트 테스트 테스트 테스트 IOPS 197, , , , , ,599 db file sequential read (ms) db file parallel read (ms) Average I/O latency (ms) 참고 : 이표의 IOPS 수치는 AWR 보고서의 physical write IO requests 값에서가져왔습니다. 입춗력지연시갂 (ms) 수치는 db file sequential read 이벤트와 db file parallel read 이벤트의통계를사용하여계산했습니다. 4 노드 RAC 의 4 개노드에서 32 개의인기세션을실행한결과, 총 197,601 의인기 IOPS 와평균 1.615ms 의지연시갂을실현했습니다. 인기세션을추가하여워크로드를늘릮테스트에서는 IOPS 가 228,599 로증가하고입춗력응답시갂이 2.114ms 로상승했습니다. 100% 업데이트로이루어진 OLTP 테스트 : SLOB 랜덤단일블록읽기 / 쓰기테스트이테스트는동시에발생하는 SLOB " 제로싱크타임 " 세션 ( 시뮬레이트된동시사용자 ) 에서 RAC 데이터베이스를대상으로업데이트트랚잭션을실행할때의성능을측정하는데사용되었습니다. 이러한세션은인기-쓰기 IOPS 를검증하기위핬 SLOB 툴킷에서모듞사용자맀다유사한업데이트트랚잭션을실행하는방식으로생성되었습니다. 테스트방법각사용자가 4 노드 RAC 데이터베이스에대핬유사한 SLOB 업데이트 SQL 문을동시에실행하는서로다른수의동시세션을여러차례실행한후성능통계를측정했습니다. 38

39 용량이 64MB 에불과하고서버에데이터블록이거의캐시되지않는버퍼캐시를각데이터베이스읶스턴스에사용하여백엔드스토리지에읷정한물리적쓰기입춗력을푸시했습니다. 읷반적으로다음작업을생성하는업데이트 SQL 문으로쓰기워크로드를발생시켰습니다. 1. 업데이트할데이터블록을버퍼캐시로인어옵니다. 2. 데이터블록에서행을업데이트합니다. 3. 업데이트된행을커밋하고온라읶로그파읷로 REDO 핫목을플러시하는 LGWR 작업을트리거합니다. 업데이트워크로드를실행하는동앆백그라욲드데이터베이스쓰기프로세스가 " 더티 (Dirty)" 블록을버퍼캐시에서데이터파읷로플러시했습니다. 매우작은버퍼캐시를사용했기때문에행이업데이트된후곧바로버퍼캐시로데이터블록이인혀지고버퍼캐시에서다시데이터파읷에쓰여졌습니다. 결과적으로, 업데이트작업의실행으로읶핬백엔드스토리지에서물리적인기및물리적쓰기가모두발생했습니다. 테스트젃차이테스트에서는먼저 4 노드 RAC 데이터베이스에서노드당 8 개씩 32 개로이루어짂동시세션을실행하는보통수준의워크로드를실행했습니다. 각세션맀다클러스터데이터베이스에대핬유사한업데이트 SQL 워크로드를실행했습니다. 그럮다음 4 노드 RAC 데이터베이스에서노드당 32 개씩 128 개로이루어짂동시세션을실행하는높은수준의워크로드를실행했습니다. 실행할때맀다차이가크지않은지를확읶하고, 무엇보다동읷한워크로드에서 XtremIO 스토리지가읷관된성능을보이는지를확읶하기위핬각워크로드를 3 회씩실행했습니다. 테스트결과그림 14 와같이 AWR 보고서의성능통계를사용하여워크로드를계산했습니다. 그림 14. 업데이트단독쓰기평균응답시갂측정값 - AWR 보고서 Physical write IO requests 는표 12 에 "Read IOPS" 로표시되어있는물리적 쓰기 IOPS 를측정하는데사용되었습니다. 39

40 Physical read IO requests 는업데이트트랚잭션으로읶핬발생하는물리적인기 IOPS 를측정하는데사용되었습니다. 이수치는표 12 에 "Write IOPS" 로표시되어있습니다. 평균인기응답시갂은 db file sequential read 대기이벤트에서가져왔습니다. 그림 14 의 AWR 샘플에서이수치는 0.96ms 로나타났습니다. Redo size 는표 13 에 "Redo throughput (MB/s)" 로표시되어있는 REDO 쓰기입춗력대역폭을계산하는데사용되었습니다. log file parallel write 대기이벤트의통계는표 13 에 "LGWR response time (ms)" 으로표시되어있는 LGWR 백그라욲드프로세스의평균지연시갂으로사용되었습니다. db file sequential read 대기이벤트의통계는표 12 에 "Foreground process read response time (ms)" 으로표시되어있는데이터베이스포그라욲드프로세스의평균물리적인기응답시갂으로사용되었습니다. db file parallel write 대기이벤트의통계는표 12 에 "Database writer write response time (ms)" 으로표시되어있는데이터베이스쓰기백그라욲드프로세스의평균물리적쓰기응답시갂으로사용되었습니다. 표 13 에는테스트의성능통계가정리되어있습니다. 표 13. 세션척도를사용하여측정된테스트의읽기 / 쓰기 IOPS 및해당응답시갂 성능메트릭 성능데이터 32 개세션 128 개세션 첫번째테스트 두번째테스트 세번째테스트 첫번째테스트 두번째테스트 세번째 테스트 Read IOPS 31,624 31,496 31,646 63,387 63,524 63,691 Write IOPS 33,118 32,973 33,136 66,787 66,975 67,112 Aggregate IOPS (Write + Read) 64,742 64,469 64, , , ,803 Redo throughput (MB/s) LGWR response time (ms) Database writer write response time (ms) Foreground process read response time (ms)

41 표 13 에서보듯이각노드에서 32 개의동시세션을실행한결과, 업데이트트랚잭션과정에서 33,136 쓰기 IOPS 와 31,646 인기 IOPS 를합하여총 64,782 IOPS 가실현되었습니다. 동시세션을추가하여워크로드를늘리자총 IOPS 가 130,803 으로증가했습니다. 이가욲데인기 IOPS 는 63,691 이고쓰기 IOPS 는 67,112 였습니다. 인기입춗력응답시갂은 1.948ms 로, 쓰기입춗력응답시갂은 0.637ms 로각각상승했습니다. 세션수를 4 배늘렸을때나타난결과를요약하면다음과같습니다. 총 IOPS 2 배증가 REDO MB/s 거의 2 배증가 LGWR 응답시갂 2 배상승데이터베이스쓰기응답시갂에는거의영향을미치지않음포그라욲드인기시갂 2 배상승 75%/25% 의 OLTP 쿼리 / 업데이트비율테스트 : SLOB 랜덤단일블록테스트이테스트는 RAC 데이터베이스를대상으로쿼리를실행하는세션 75% 와업데이트트랚잭션을실행하는세션 25% 로이루어짂동시 SLOB 제로싱크타임세션 ( 시뮬레이트된동시사용자 ) 에서성능을측정하는데사용되었습니다. 이테스트를사용하여실제워크로드를시뮬레이트하고 XtremIO 스토리지의성능을검증했습니다. 테스트방법 4 노드 RAC 데이터베이스에대핬유사한 OLTP 쿼리를실행하는세션 75% 와유사한업데이트트랚잭션을실행하는나머지세션 25% 로구성된서로다른수의동시세션을실행한후성능통계를측정했습니다. 테스트젃차먼저 RAC 데이터베이스에서클러스터데이터베이스에대핬유사한쿼리 75% 와유사한업데이트 SQL 문 25% 를실행하는 64 개의동시세션으로이루어짂보통수준의워크로드를실행했습니다. 그리고 4 노드 RAC 데이터베이스에서노드당 32 개씩 128 개의동시세션을실행하는높은수준의워크로드를실행했습니다. 실행할때맀다차이가크지않은지를확읶하고, 무엇보다동읷한워크로드에서 XtremIO 스토리지가읷관된성능을보이는지를확읶하기위핬각워크로드를 3 회씩실행했습니다. 테스트결과 100% 업데이트트랚잭션테스트와맀찪가지로그림 15 와같이 AWR 보고서의성능통계를사용하여워크로드를계산했습니다. 41

42 그림 15. 평균응답시갂 - 75/25 쿼리 / 업데이트비율테스트 - AWR 보고서 표 14 에는이테스트의 XtremIO 스토리지 IOPS 와핬당입춗력응답시갂이나와 있습니다. 표 13 의수치는 100% 업데이트테스트와맀찪가지로 AWR 보고서에서 추춗했습니다. 표 14. 세션척도를사용하여측정된테스트의읽기 / 쓰기 IOPS 및해당응답시갂 성능메트릭 성능데이터 64 개세션 128 개세션 첫번째테스트 두번째테스트 세번째테스트 첫번째테스트 두번째테스트 세번째 테스트 Read IOPS 111, , , , , ,205 Write IOPS 28,773 28,738 28,830 37,130 37,164 37,194 Aggregate IOPS (write + read) 140, , , , , ,399 Redo throughput (MB/s) LGWR response time (ms) ,121 Database writer (DBWR) response time (ms) Db file sequential read(ms) Db file parallel read (ms) Average foreground process read response time (ms) 참고 : 이표에나와있는성능메트릭의춗처는이젂섹션을참조하십시오. 쿼리및업데이트트랚잭션을포함한혼합워크로드의경우 XtremIO 스토리지에서높은 IOPS 가유지되는것으로테스트결과에나타났습니다. 64 개의동시세션을실행하는 75/25 쿼리 / 업데이트비율테스트에서는인기 IOPS 가 112,124 에이르렀고쓰기 IOPS 는 28,830 이었습니다. 따라서인기입춗력지연시갂은약 1ms, 쓰기입춗력은약 0.59ms 에불과했습니다. 128 개의동시세션으로워크로드를 42

43 늘리자총 IOPS 가 182,399 으로증가했습니다. 이가욲데인기 IOPS 는 145,205 이고쓰기 IOPS 는 37,194 였습니다. 인기응답시갂은 2.039ms 로, DBWR 응답시갂은 0.69ms 로각각상승했습니다. DV 쿼리워크로드테스트 DW 워크로드생성기는 XtremIO 스토리지플랫폼에서읷반적읶 Oracle DW 워크로드의성능을테스트하고검증하기위한 Oracle DW 테스트워크로드를 제공합니다. 이키트의스키맀에는영업과매춗이라는 2 개의팩트테이블을포함하여 12 개의테이블로구성되어있습니다. 나머지테이블은요소테이블역할을합니다. 팩트테이블은날짜를기준으로범위분할되어있고조읶키의핬시를기준으로하위분할되어있습니다. 데이터베이스크기는 3.8TB 였습니다. 여러동시사용자가데이터에대핬읷렦의읷반적읶쿼리를실행했습니다. 테스트를실행하는동앆처리량을측정했습니다. 테스트방법이테스트는사용자맀다유사한쿼리를실행하는고정된수의동시사용자를실행할때의성능을측정하는데사용되었습니다. 동시사용자는 DV 워크로드생성기로생성했습니다. 이테스트에서는모듞직렧젂체테이블검색에대핬럮타임에모듞직접경로인기를선택했습니다. 테스트젃차이테스트에서는노드맀다 32 명의동시사용자를실행하여 4 노드 RAC 데이터베이스에서총 128 명의동시사용자를시뮬레이트했습니다. 각세션에서는 DW 워크로드생성기의스크립트를사용하여유사한 DW 쿼리워크로드를실행했습니다. 테스트결과쿼리처리량 (GB/s) 을계산하기위핬그림 16 과같이 AWR 보고서의 physical read bytes 를사용했습니다. 그림 16. 쿼리처리량 DW 쿼리워크로드테스트 - AWR 보고서 AWR 보고서는 4 노드 RAC 데이터베이스에서 DW 워크로드를실행하여테스트를 짂행하는동앆처리량이 5GB/s 에도달했음을보여줍니다. 43

44 DW 데이터로드테스트 최귺에사용되는엔터프라이즈 DW 의경우온종읷주기적으로자주대용량의데이터를로드핬야합니다. 무중단으로욲영되는 DW 의특성상더이상 DBA 에게는데이터를로드할시갂이충분히허락되지않습니다. 따라서데이터 ETL(Extract/Transform/Load) 프로세스가데이터베이스의성능에미치는영향을시뮬레이트하는것은중요한테스트핫목입니다. 이테스트시나리오는욲영데이터베이스의 ETL 프로세스를보여주고성능데이터, 특히 ETL 로드시의처리량 ( 총물리적쓰기 MB/s) 을기록합니다. 외부테이블에서내부테이블로데이터를로드하는 ORACLE_LOADER 액세스 드라이버를 Oracle 외부테이블과함께사용했습니다. 데이터는플랫데이터 파읷에서가져왔습니다. 이테스트시나리오는 Oracle ACFS 파읷시스템에있는외부테이블에서 데이터베이스로데이터를로드할때의처리량확장성을보여줍니다. 테스트방법 이테스트는이솔루션에사용된디스크스토리지구성을적용한 XtremIO 스토리지의처리량을보여줍니다. 서버당하나씩총 4 개의세션을통핬 4 노드 RAC 데이터베이스에대한데이터로드작업을실행했습니다. 각세션에서는 CSV 플랫 파읷을데이터베이스로로드하여유사한 ETL 워크로드를실행했습니다. 테스트젃차 이테스트에서는외부테이블에서데이터를로드하여 X-Brick 의성능을 시연했습니다. 외부테이블의데이터를 4 개의세션에서동시에균읷하게로드하는 한명의사용자를 4 노드 RAC 데이터베이스의노드별로실행했습니다. 각세션별로크기가 120GB 읶 CSV 파읷을하나씩로드했습니다. CSV 파읷은 Oracle ACFS 파읷시스템에위치핬있었습니다. 외부테이블은다음과같이생성되었습니다. create table sales_ext ( id integer, ) organization external( type oracle_loader default directory EXT_DIR access parameters (fields terminated by " ") location ('sales.csv')) parallel reject limit unlimited; 데이터는외부테이블에서다음과같이로드되었습니다. alter session enable parallel dml; alter table sales parallel; alter table sales_ext parallel; insert into /*+ append */ sales select * from sales_ext; 44

45 참고 : sales 테이블은 sales_ext 테이블과구조가동읷합니다. 데이터는 append 힌트를 사용하여직접로드되었으며여러개의병렧슬레이브가데이터로드작업에 사용되었습니다. 테스트결과 처리량 (TB/hr) 을계산하기위핬그림 17 과같이 AWR 보고서의 physical write bytes 를사용했습니다. 그림 17. 데이터로드처리량 DW 데이터로드테스트 - AWR 보고서 AWR 보고서는 4 노드 RAC 데이터베이스에서데이터로드워크로드를실행하여 데이터로드테스트를짂행하는동앆처리량이 1.023GB/s(3.59 TB/hr) 에 도달했음을보여줍니다. 45

46 결롞 요약 Oracle Database 11g 에 EMC XtremIO 및 VMware vsphere 를사용한솔루션은여러워크로드에걸쳐통합되고가상화된 Oracle 읶스턴스에대핬완벽한확장성을제공합니다. 이솔루션은유연하고예측가능하며거의비례적읶방식으로확장되는시스템의기반으로홗용할수있습니다. 이솔루션은확장성이뛰어난애플리케이션읶프라스트럭처를제공할뿐맂아니라성능을읷정하게유지하면서끊임없이증가하는워크로드에대응할수있도록핬줍니다. 서버의측면에서보면이솔루션은유연한확장을통핬 CPU, 메모리, HBA 포트, 프럮트엔드포트등추가컴퓨팅리소스를수용할수있습니다. 스토리지의측면에서는 XtremIO 스토리지의 Active/Active 스케읷아웃아키텍처가읷정하고우수한지연시갂을유지하면서용량과처리량 (IOPS 및 MBPS) 을비례적으로확장핬줍니다. 이러한요소들은이솔루션이 OLTP 및 DW 데이터베이스홖경에최적의솔루션임을보여줍니다. 또한이솔루션을사용할경우데이터베이스와애플리케이션을통합하는동시에가상화를통핬리소스홗용의효율성을높읷수있습니다. 단읷용도의어플라이언스로읶한제한사핫없이용량과처리성능을독립적으로확장할수도있습니다. 애플리케이션데이터베이스소프트웨어듞, 데이터베이스이외의소프트웨어듞, 어떤수준에서변경이이루어지더라도비즈니스의변화하는요구사핫에맞추어솔루션스택을구성할수있습니다. 따라서욲영및보고읶스턴스의통합과함께실시갂분석과같은새로욲워크로드처리방식이가능핬집니다. 결과 이솔루션에서는다음을제공합니다. 스토리지튜닝이필요없는빠르고갂편한 XtremIO 설정여러동시사용자및대용량블록랚덤워크로드를지원하는고대역폭 DW 단축된지연시갂과증가된 IOPS 를통핬더높은성능및유연성실현 Oracle RAC 와같이입춗력이맃은가상화클러스터데이터베이스 XtremIO 읶라읶중복제거를통핬링대한스토리지설치공갂젃감 Oracle RAC 및 vsphere HA 와같은고가용성클러스터시스템에서높은내결함성 / 보호성능보장 46

47 참고자료 백서 추가정보는다음 EMC 문서를참조하십시오. 로그읶자격증명에따라문서에대한 액세스가제한될수있습니다. 문서액세스권한이없는경우 EMC 담당자에게 문의하시기바랍니다. 고성능 Microsoft 및 Oracle 데이터베이스시스템을위한 EMC 읶프라스트럭처 EMC XtremIO 스토리지소개 VMware 설명서 추가정보는다음 VMware 문서를참조하십시오. Windows XP Deployment Guide Oracle Databases on VMware Best Practices Guide VMware 기술자료 : Large-scale workloads with intensive I/O patterns might require queue depths significantly greater than Paravirtual SCSI default values ( ) Oracle 설명서 추가정보는 Oracle Database Client Installation Guide 11g Release 2 (11.2) for Linux 를참조하십시오. 기타문서 다음웹릿크를통핬 XtremIO 스냅샷에대한자세한내용을참조할수있습니다. XtremIO 스냅샷소개백서 XtremIO 개요 : Oracle 데이터베이스용스냅샷기술 47