IBM XIV Storage System 스냅샷의재발견 백서 2008 년 9 월
차례 볼륨의스냅샷을만드는이유 4 고객의희망사항 4 XIV 시스템의스냅샷구현 6 혁신적인메타데이터설계 9 Redirect on Write 10 셸프내 (Intra-shelf) 복사와 XIV System의확장그리드 11 강력한스냅샷기능 11 쓰기가능스냅샷 11 스냅샷의스냅샷 12 쓰기가능스냅샷을이용한볼륨복구 12 기존스냅샷오버라이드 13 스냅샷시나리오 13 1번시나리오 : 미러링프로세스를중단시키지않는원격미러링테스트 13 2번시나리오 : 볼륨크기변경테스트 15 요약 16 부록 : 최첨단과그한계 17
서론 기존볼륨의스냅샷을만들고관리할수있는기능은최신전사급스토리지시스템이널리제공하는가장기초적인기능중하나입니다. IBM XIV Storage System은이개념을한단계발전시켜완전히혁신적인스냅샷생성및관리방법을제안합니다. XIV 시스템은현재업계에서제공되는다른접근방법과비교할때다음과같은분명한이점을제시합니다. 시스템에서생성할수있는스냅샷의수무제한. 복제하는볼륨의크기와관계없이거의순간적으로스냅샷생성. 현재시스템에정해져있는스냅샷의수에영향을받지않는스냅샷지원시스템의성능수준. 본백서에서는 XIV의스냅샷아키텍처를묘사하고그이점을성능, 사용편리성, 유연성및안정성의측면에서설명합니다. 또한, 이와같은이점이어떻게시스템의고유한전체그리드아키텍처의기능을이용하여얻을수있는지설명합니다. 스냅샷볼륨을만드는이유 스냅샷이란특정한시점의원본볼륨과동일한컨텐츠를가지고있는논리적볼륨입니다. 스토리지시스템에서스냅샷이제작될때, 원본볼륨은항상스냅샷에영향을미치지않고정상적인 I/O 활동을계속합니다. 현재스냅샷은산업에서다음과같은다양한종류의작업을위해사용됩니다. 외장미디어에데이터백업. 스냅샷을이용하면외장미디어에저장하고나중에복구목적을위해사용할수있는핫백업이기능합니다. 스냅샷을백업을위해사용하면어떤실행중인애플리케이션도중지하지않고전체볼륨을특정시점에일관되게복사할수있습니다. 논리적장애복구. 시스템에안전하게저장되어있는데이터는때때로사용자나관리자의실수로수정되거나삭제됩니다. 이와같은유형의논리적장애는호스트에서실행되는애플리케이션의문제 ( 데이터베이스손상등 ) 나사용자의실수 ( 실수에의한파일삭제등 ) 에서비롯됩니다. 스냅샷을이용한백업메커니즘은이와같은상황에서쉽게복구를지원할수있습니다. 스냅샷을이용한복구프로세스는다음중한가지방법으로실행할수있습니다. 스냅샷으로부터볼륨의컨텐츠를복구함으로써근본적으로스냅샷이만들어진시점으로되돌리는방법.
스냅샷에서손상된데이터를선별적으로검색하여이를애플리케이션단계에서원본볼륨으로복사하는방법. 테스트. 새로운소프트웨어버전을개발하고테스트하는동안개발자는기존데이터세트의전체사본을사용해야합니다. 스냅샷은이렇게할수있는능력을부여합니다. 테스트목적을위해스냅샷은시스템안의다른모든독립적인볼륨과마찬가지로호스트가수정할수있는쓰기가능한볼륨으로구성할수있습니다. 데이터마이닝. 많은 IT 환경은볼륨의컨텐츠가계속하여호스트에의해수정되는동안특정시점에촬영한볼륨컨텐츠의사진을사용할것을요구하는데이터마이닝절차를이행합니다. 이와같은경우에는스냅샷이사용됩니다. 고객의희망사항 현재의기업고객은스냅샷메커니즘에서다음과같은주요기능을기대합니다. 순간적이고간단한스냅샷생성. 최소한의사전준비를요하고관리자의시간을최소한으로사용합니다. 다중스냅샷. 데이터복구에소요되는시간을줄이고복구기능의세밀도를개선합니다. 쓰기가능한스냅샷. 스냅샷이개발및테스트용으로사용될때필수적입니다. 데이터베이스시스템 ( 예 : Oracle) 과기타애플리케이션은요청된작업 ( 예 : 테이블스캔 ) 이읽기전용일경우에도애플리케이션의상태를업데이트하고저장하기위해쓰기액세스를필요로합니다. 스냅샷의스냅샷 ( 스냅샷트리 ) 생성. 쓰기가능한스냅샷의스냅샷을만들수있는기능. 이를통해쓰기가능한스냅샷을계속사용할수있으며, 해당쓰기가능스냅샷의모든읽기전용스냅샷으로부터복구할수있는기능도지원됩니다. 스냅샷에서반복적으로복구스냅샷을 1차사본으로복구하고해당스냅샷이생성된시점이바람직하지않은경우다른스냅샷에서복구할수있는기능. 차동스냅샷. 원본과스냅샷이현재차이가나는부분에대해서만데이터의실제사본을만듦으로써성능과시스템의스토리지공간사용효율을개선합니다. 최소한의성능저하. 스냅샷의생성및관리는시스템의전체성능과특히고객의실운영볼륨의성능에영향을미치지않아야합니다. 확장성. 위의모든요구사항 ( 즉각적인생성, 다중스냅샷그리고성능저하방지 ) 은작고큰볼륨에공히적용되어야하며시스템에저장된전체데이터의양이증가하기시작할때에도타협해서는안됩니다.
XIV 시스템의스냅샷구현 IBM XIV Storage System은스냅샷생성및관리의모든측면에완전히혁신적인방법으로접근하여시중에서제공되는다른여러기술의한계를크게뛰어넘습니다. ( 다른스냅샷기술의문제에대한자세한설명은부록을참조하십시오.) XIV 시스템의스냅샷방식이제시하는가장두드러진특징은다음과같습니다. 스냅샷은 1초미만에순간적으로생성됩니다. 볼륨별로수천개의스냅샷을생성할수있습니다. 성능저하가거의없습니다. 스냅샷에서원본볼륨의컨텐츠를 1초미만에순간적으로복구할수있습니다. 성능, 생성시간및복구시간은볼륨의크기나스냅샷의수와관계없이일정합니다. 위의속성을모두가진쓰기가능한스냅샷을만들수있습니다. 스냅샷의스냅샷은유연한시스템개발및테스트를지원합니다. 모든스냅샷에서반복적으로복구할수있습니다. 이와같은중요한발전은다음과같은 2대원칙을중심으로제작된완전히확장가능한그리드스토리지플랫폼이라는 XIV 시스템아키텍처의근본적인특징으로인해가능했습니다. 데이터모듈은모두동일한물리적장치안에서 2개의 PCI-X 버스로서로연결된캐시와디스크를포함하는표준인텔기반서버의형태로구현됩니다. 시스템안의모든논리적볼륨은시스템안의모든데이터모듈및모든디스크드라이브에걸쳐분산된데이터조각의형태로저장됩니다.
호스트데이터모듈 내부연결 캐시 CPU 인터페이스디스크 디스크, 캐시및 CPU 는동일한장치안에있어완전한확장성을보장함 높은대역폭은디스크 - 캐시통신을지원함 시스템안의모든스핀들은각스냅샷의복사프로세스에참여함 그림 1: XIV 시스템아키텍처와그것이스냅샷생성에근본적으로기여하는이점 이와같은원칙에서도출되는구조적인이점은다음과같습니다. 시스템의스토리지용량이증가하면 CPU 처리능력과캐시메모리영역도항상나란히성장하므로모든내부프로세스, 특히스냅샷프로세스의완전한확장이보장됩니다. 데이터복제는항상시스템모듈안에서내부적으로실행됩니다. 이때, 거대한대역폭이디스크와캐시사이의통신을지원하고셸프 (shelf) 간통신은필요하지않습니다. 스냅샷과관련된각각의프로세스는시스템전체의모든모듈과스핀들에
걸쳐동시에실행됩니다. 혁신적인 ( 특허를획득한 ) 메타데이터설계는사실상순간적인스냅샷생성프로세스를지원합니다. 기본데이터복제메커니즘은 (copy-on-write가아닌 ) redirect-on-write이므로, 스냅샷이시스템성능에미치는영향이크게줄어듭니다.
이어지는내용에서는이와같은혁신에대해자세히설명하면서이러한혁신이 XIV 시스템의전체적인구조에자연스럽게결합되어있음을시사합니다. 시스템의전반적인구조적이점은스냅샷메커니즘을위해완전히활용되며쓰기가능및읽기전용스냅샷에똑같이효율적으로적용됩니다. 혁신적인메타데이터설계 모든스토리지시스템에서차동스냅샷을만들고취급하기위해서는복잡한메타데이터집합을구현하여볼륨과연관된어떤데이터조각이어느스냅샷이나원본볼륨에의해사용되는지를파악해야합니다. 그러나 XIV 시스템에서는이프로세스에사용되는메타데이터의크기가스냅샷을만드는시점에아주작기때문에스냅샷생성명령은사실상순간적으로이행됩니다. 예를들면, 시스템에 5 TB 볼륨이있는데매 4 시간마다이볼륨의스냅샷을만들고자하는경우를가정해보십시오. 1년후에해당볼륨에대해생성된스냅샷은총 2,000개에달할것입니다. 이처럼많은수의사본과초기볼륨의커다란크기와관계없이 XIV 시스템은각스냅샷을만들때매우작은일정한크기의메타데이터헤더만정의합니다. 이메타데이터는데이터조각의물리적인사본을추가할때에만, 그리고그것이원본볼륨에서수정될경우에만커집니다. 이런조건하에서는큰볼륨의스냅샷을 2000개나만든다는개념자체가실제로가능해집니다. 마찬가지로, 매우많아보이는스냅샷의수도시스템의전체성능에는거의, 또는전혀영향을미치지않습니다. 스냅샷생성명령이 XIV 시스템에서는사실상순간적으로이행된다는것을보여주는또하나의예를고려해보십시오. 30 TB 볼륨하나가있는데이에대한스냅샷을하나만들고자하는경우를가정해보십시오. 원본볼륨이수신된쓰기요청에의해수정되지않는한, 볼륨과스냅샷은계속하여모든데이터의물리적사본을공유합니다. 볼륨과스냅샷이동일한이상스냅샷은사실상어떤메타데이터메모리요건도갖지않습니다.
Redirect on Write XIV 시스템은쓰기요청이원본과스냅샷이공유하는데이터슬롯을수정할때사용되는기본적인 copy-on-write 메커니즘대신 redirect-on-write라고하는색다른방법을사용합니다. 기존의 copy-on-write 방식은세차례의디스크탐색작업을수반하는반면, XIV 시스템의 redirect-on-write는아래그림에나와있는것처럼이작업을 2 차례만수행합니다. 그림 2: Copy-on-write 와 Redirect-on-write 의비교
셸프내 (Intra-shelf) 복사와 XIV System 의확장그리드 차동스냅샷을사용할때 Copy-on-write로인한성능저하는불가피합니다. Redirect-on-write 방식은성능저하를완전히없애지는못하지만, 합당한수준으로감소시킵니다. XIV 시스템의독특한아키텍처는그기본원리로인해스냅샷작업을할때타의추종을불허하는뛰어난성능을제공합니다. Redirect-on-write를셸프 (shelf) 간통신없이모듈안에서완전히수행합니다. XIV 시스템이전체시스템에걸쳐데이터를배포하기위해사용하는정교한알고리즘으로인해어떤특정한부분의원본과그것의모든물리적스냅샷은항상동일한모듈안에상주합니다. 각모듈은모두동일한물리적장치안에서 2개의 PCI-X 버스로서로연결된캐시와디스크를포함하는표준인텔기반서버입니다. 따라서, redirect-on-write 작업에는실로커다란대역폭이사용되어어떤병목지점도발생할수없습니다. 결과적으로성능에미치는영향은크게감소합니다. 반대로기존의스토리지시스템은 FC나공동버스를통해연결된공동컨트롤러를통해디스크셸프 (shelf) 간에 copy-on-write를수행합니다. 시스템의모든모듈에서동시에 redirect-on-write를수행합니다. 실제로스토리지용량이나메모리를추가할때에는시스템성능이저하되지않습니다. 반대로기존시스템은제한된수의컨트롤러를사용하여 copy-on-write를수행합니다. 강력한스냅샷기능 XIV 시스템은위에서설명한독특한구조적인이점을토대로다음과같은몇가지 매우중요하고강력한스냅샷기능을제공합니다. 쓰기가능한스냅샷 XIV 시스템의모든스냅샷은쓰기가능한스냅샷으로지정할수있습니다. 이스냅샷을호스트에매핑하면호스트는이를읽기전용이아닌일반적인읽기 / 쓰기볼륨으로인식하지만, 쓰기가능으로지정하지않은스냅샷이나대부분의업체가구현하는스냅샷은읽기전용으로인식합니다. 스냅샷은기본볼륨에매핑하든스냅샷에매핑하든관계없이호스트에게계속하여투명하게비춰집니다. 쓰기가능한스냅샷은계속하여수정되지않은데이터를 XIV 시스템의원본볼륨과공유합니다. 따라서, 구체적으로이스냅샷에쓰여진데이터만물리적리소스를추가로소비합니다. 나아가, 쓰기가능한스냅샷은크기를조정할수도있습니다.
쓰기가능한스냅샷에더해진추가용량은실제로데이터가쓰여질때까지 소비되지않습니다. 쓰기가능한스냅샷은주로다음과같은 2가지시나리오에서사용됩니다. 블록-레벨읽기 / 쓰기액세스. 많은애플리케이션은애플리케이션레벨권한이읽기전용일경우에도블록레벨읽기 / 쓰기권한을요구합니다. 이는파일시스템메타데이터, 서명블록또는기타관련상황때문일수있습니다. 이와같은경우에는스냅샷을쓰기가능으로지정해야할필요가있습니다. 이와같은상황에서데이터가변경되는경우는일반적으로매우드물기때문에 XIV 시스템의쓰기가능한스냅샷이소중한물리적공간을아주조금만소비한다는사실은매우중요합니다. 테스트. 테스트를위해스냅샷을사용하려면스냅샷이쓰기가능해야합니다. 이경우 XIV 시스템이쓰기가능스냅샷을위해사용하는물리적공간은미미하기때문에테스트환경의리소스효율은훨씬더높아집니다. 스냅샷의스냅샷 일단스냅샷이쓰기가능으로지정되면자연히스냅샷의스냅샷을만들수있는지도궁금해질것입니다. 이기능은매우직관적이고쉽게사용이가능하지만다른스토리지업체에서이를제공하는경우는매우드뭅니다. XIV 시스템은순간생성, 실사용량으로국한되는최소한의공간소모및고성능을포함한여타훌륭한기능들을하나도희생시키지않고기존쓰기가능한스냅샷의스냅샷을생성하는기능을기본적으로지원합니다. 스냅샷의스냅샷기능은복합적인개발및테스트환경에서매우큰도움이됩니다. 이기능은 ( 전체사본의필요성을배제함으로써 ) 상당한스토리지공간을절약하고 ( 여러스냅샷을쉽게생성함으로써 ) 테스트및개발을개선하고스냅샷을사용하는애플리케이션에대해서도논리적백업을지원합니다. 쓰기가능스냅샷을이용한볼륨복구 쓰기가능한스냅샷은볼륨복구작업에서원본으로도사용할수있습니다. 쓰기가능스냅샷에는이미다른데이터가기록되어원본의내용과달라졌을가능성이높기때문에, 이는얼핏보면모순이라고생각될수있습니다. 쓰기가능스냅샷은일반적으로어떤특정시점의마스터볼륨의상태를반영하지않습니다. 그럼에도불구하고실제로는이와같은복구상황이필요할때가있습니다. 실제로, 쓰기
가능한스냅샷을이용하여복구하는방법은애플리케이션개발또는테스트도중에빠르고편리하게복구할수있는유일한방법입니다. XIV 시스템에서는기본적으로스냅샷의트리를만들수있는데트리의각가지는그자체로완전한개발환경이됩니다. XIV 시스템은이독특한기능을간단하면서도강력한스냅샷아키텍처의자연스러운연장으로서제공합니다. 기존스냅샷오버라이드 볼륨의스냅샷을찍으면새로운스냅샷볼륨이만들어지는기본적인스냅샷구현방식과함께, XIV 시스템은볼륨의현재컨텐츠가기존스냅샷으로논리적으로복사되는대안을제시합니다. 이기능은기존스냅샷이이미호스트로매핑되어있을때유용합니다. 이경우, 새로운컨텐츠는볼륨매핑과 SCSI 일련번호를변경하지않고 XIV 시스템이나호스트에서사용할수있습니다. 따라서, 호스트는운영체제단계에서다시스캔을하는프로세스를실행해야할필요가없습니다. 물론, 전체컨텐츠가변경되었기때문에데이터를사용하는애플리케이션은다시시작해야합니다. 이기능을이용하면백업환경을훨씬더간단하고빠르게구축할수있습니다. 스냅샷시나리오 아래에는 XIV 시스템의기능과독특한아키텍처가어떻게과거에는해결할수 없었던문제를해결해주는지를보여주는몇가지시나리오가제시되어있습니다. 1 번시나리오 : 미러링프로세스를중단시키지않는원격 미러링테스트 현재거의모든중요한하이엔드애플리케이션은미러링되어 2차사이트에백업됩니다. 다른모든백업솔루션과마찬가지로이 2차사이트는수시로테스트를하지않으면정말로필요할때제기능을수행하지못할수있습니다. 2차시스템을테스트하기위해서는 2차사이트에있는서버를활성화하고데이터를사용해야합니다. 기존의스로리지솔루션에서는이를위해미러링프로세스를중단해야하며이로인해데이터가 2차사이트로복제되지않는시간의공백이발생하게됩니다. XIV 시스템은미러링프로세스를중단하지않고 2차사이트를테스트하는다음과같은간단한프로세스를제시합니다.
1 2차볼륨의스냅샷생성 2 스냅샷을쓰기가능으로지정 3 스냅샷을마치원본볼륨인것처럼 2차사이트에있는서버로매핑. 이와같은간단한절차를이행하면, 환경은다음과같이설정됩니다. 2차볼륨으로미러링하는과정은절대중단되지않으며, 애플리케이션은여전히진행중인테스트를을인식하지못합니다. 2차서버는쓰기가능한스냅샷으로매핑되어재난시나리오를완전히시뮬레이션합니다. 일단테스트가끝나면스냅샷은간단히삭제되고정보를복구하거나동기화할 필요가없습니다.
2 번시나리오 : 볼륨크기변경테스트 때로는애플리케이션의수요가증가하여볼륨의크기를늘려야할필요가있을수있습니다. XIV 시스템에내장된가상화기능으로인해스토리지쪽에서는이작업이사소한것이되지만애플리케이션쪽의복잡성은해소되지않습니다. 볼륨의크기를늘리는모든애플리케이션이지원하지않는작업은복잡한작업이며조심스럽게수행해야합니다. 몇몇애플리케이션을제외하고볼륨의크기를조정하려면애플리케이션의가동을중단하는다운타임이필요합니다. 다운타임을단축하는것은어떤기준에서보든데이터센터의우수성을가늠하는중요한척도중하나입니다. XIV 시스템은애플리케이션문제를해결할수는없지만이러한프로세스의테스트를단순화시켜줄수있습니다. 실운영을중단하지않고볼륨의크기조정을테스트할때에는다음과같은방법을사용하면쉽습니다. 1 실운영볼륨의스냅샷을찍습니다. 2 스냅샷을쓰기가능으로지정합니다. 3 테스트에사용할애플리케이션의새로운인스턴스를만들고새로만든쓰기가능스냅샷을이인스턴스에매핑합니다. 4 새로운인스턴스를사용하여볼륨크기를늘리는절차에따라쓰기가능한스냅샷의크기를늘리고모든문제가해결될때까지프로세스를완전히디버깅합니다. 5 실운영볼륨에대해동일한절차를따르는한편쓰기가능한스냅샷은참고용으로보관합니다. 6 작업이완료되면쓰기가능한스냅샷을삭제합니다. 이절차는실운영을중단하지않고복잡한절차를오프라인으로테스트하는방법을제시합니다. 테스트프로세스는실운영프로세스를완전히반복하게됩니다. 테스트에사용되는애플리케이션인스턴스는확장할읽기 / 쓰기볼륨을인식하지만이것이실제볼륨이아닌스냅샷임을인식하지못합니다. 나아가, 스냅샷을만들고크기를조정하는작업은실제로데이터를복사하지않고사실상순간적으로수행되며프로세스는지연없이여러차례테스트할수있습니다. 아울러, 스냅샷은차동스냅샷이기때문에테스트단계에서는볼륨을늘리기위해필요한실제공간이소비되지않습니다.
요약 XIV 시스템은진정으로중요한방법으로현재다른업체의제품에영향을미치는가장중대한성능저하의문제를극복하는혁신적인스냅샷사용방식을제시합니다. XIV 시스템의스냅샷메커니즘은 XIV 기술의힘의완전히이용하고 XIV의독특한그리드아키텍처가제시하는장점에자연스럽게의존합니다. 이어지는 2개의표에는다른주요스토리지업체와비교한 XIV 시스템의스냅샷생성방법의장점이요약되어있습니다. 표 1: 애플리케이션기준비교 애플리케이션 IBM XIV Storage System 기타선두업체 물리적백업논리적백업테스트및개발환경데이터마이닝 스냅샷이순간적으로생성되어백업프로세스를단순화함스냅샷생성시에도고성능유지성능에부담을주지않는다중스냅샷을이용하면다세대제품에걸친논리적백업이현실적으로가능해짐순간적으로생성가능한다중스냅샷으로인해프로세스는간단하고효율적임다중스냅샷과관계없이유지되는고성능으로인해효과적인사용이가능쓰기가능한스냅샷은테스트용으로적합함스냅샷의스냅샷은개발환경을위한논리적인백업을지원함. 스냅샷과관계없이고성능이유지되어데이터마이닝이가능함순간적인스냅샷생성을통한프로세스단순화 복잡한스냅샷생성방법은복잡한프로세스로이어짐백업스냅샷은성능을저하시킴다세대제품의논리적인백업을위한실용적인솔루션없음제한적인기능과성능으로인해프로세스는비효과적이고비경제적임성능문제와복잡한스냅샷생성방법이효과를제한함
표 2: 특징비교 특징 IBM XIV Storage System 기타선두업체 메타데이터기본원리 : 크기는변경횟수에비례구체적인장점 : 볼륨크기와관계없이거의순간적으로생성스냅샷수무제한 기본원리 : 크기는스냅샷의수와볼륨의크기와비례구체적인단점 : 생성시간은볼륨의크기와비례스냅샷수제한적 복사기법기본원리 : Redirect-on-write 구체적인장점 : 보다적은데이터를복사하므로성능에미치는영향이적음 CPU 기본원리 : CPU/ 용량비고정구체적인장점 : 일정한생성시간일정한성능저하 기본원리 : Copy-on-write 또는전체복사구체적인단점 : 데이터를더많이복사하기때문에성능이크게저하됨기본원리 : 전체시스템용량에대해 CPU 고정구체적인단점 : 생성시간은비례하지않음성능저하는비례하지않음 복사기본원리 : 모듈내구체적인장점 : 크기와관계없는고성능 기본원리 : 모듈간구체적인단점 : 저성능, 크기와반비례 부록 : 최첨단과그한계 선두스토리지업체들은현재불완전한스냅샷솔루션을제공하고있으며앞에서언급한고객의요구사항을완전히충족하지못하고있습니다. 이들업체가제공하는최상위제품의기본구조는 15~20년전에설계되었기때문에이는어쩌면당연하다고할수있습니다. 스냅샷생성기능은이러한제품의아키텍처가처음설계된후한참뒤에추가되었기때문에둘의결합은여러가지면에서부자연스럽습니다. 따라서, 고객은높은가격을지불하면서도그에
상응하는가치를얻지못합니다. 스냅샷생성메커니즘은일반적으로 2개의중요한연속적인단계를수반합니다. 1 단계. 원본과그스냅샷사이에논리적관계확립. 1단계는일반적으로메타데이터의집합을만드는과정을포함합니다. 이집합은후에메커니즘의 2 단계와관련된모든활동의기초로사용됩니다. 메타데이터는예를들면원본볼륨과스냅샷사이에현재공유되고있는데이터영역을표시하기위해사용할수있습니다. 기존의스냅샷방식에서일반적으로사용되는이와같은메타데이터집합의크기는원본볼륨의크기와비례합니다. 2 단계. 원본볼륨의데이터가계속수정되는동안원본볼륨에저장되어있는데이터의물리적사본을점진적으로생성, 2 단계에는업계에서흔히 copy-onwrite 라고알려진메커니즘의구현이수반됩니다. 원본볼륨에서데이터슬롯이스냅샷생성후처음으로쓰기요청에의해수정될때마다, copy-on-write 메커니즘은일반적으로 I/O와디스크의상호작용을 2차례추가함으로써 2번의디스크탐색작업을수행하게됩니다. 따라서, 명령은수신데이터가캐시메모리에안전하게기록되고쓰기요청이호스트에게인식된후에원본볼륨과스냅샷의새로운상태를모두완전히업데이트하기위해한번의읽기와한번의쓰기작업을수행하는배경활동을통해완료됩니다. 이는분명시스템의성능에상당한부담을주며이로인한성능저하는시스템에서스냅샷의수가계속증가할수록더욱심해집니다. 따라서, 현재타업체에서제공하는스냅샷매커니즘에영향을미치는중요한한계들은두단계에각각존재하는문제에기인하며, 다음과같습니다. 느린스냅샷생성프로세스. 일반적인업체가말하는바와는달리스냅샷은사실극미한순간적인명령을통해생성되지않고스냅샷볼륨의크기에따라무시못할시간이소요될수있는프로세스를따라생성됩니다. 심각한처리속도저하. 특히스냅샷의수가계속증가할때. 개별 I/O 트랜잭션의대기시간증가. 특히차동스냅샷사용시. 제한된수의스냅샷 : 볼륨당, 그리고시스템전체에걸쳐모두. 특정고객에게이는스냅샷을논리적장애시나리오에서효과적인솔루션으로사용할수없게할만큼심각한한계가됩니다. 스토리지공간의비효율적인사용. 특히전체볼륨사본이성능문제를해결하기위한솔루션으로사용될때. 1회복구한계. 일부업체는스냅샷에서반복적으로복구하는기능을지원하지않습니다.
Copyright IBM Corporation 2008 IBM, IBM 로고, ibm.com System Storage, XIV, 및 XIV 로고는미국및 / 또는다른국가에서 IBM Corporation의상표또는등록상표입니다. 이러한상표및기타 IBM 상표로등록된용어가본문서에서처음언급될때에는적절한상표기호 ( 또는 ) 와함께표시되어해당상표및용어가본문서가발행된시점에 IBM 소유의미국등록상표또는관습법상표였음을나타냅니다. 해당상표는다른국가에서도등록상표이거나관습법에의해인정되는상표일수있습니다. IBM 상표의최신목록은 ibm.com/legal/copytrade.shtml에서온라인으로확인할수있습니다. 기타회사, 제품및서비스이름은각회사의상표또는서비스상표입니다. 이문서에는기술적오류나인쇄상의오류가있을수있습니다. IBM은본문서에언급된제품, 서비스또는기능을일부국가에서제공하지않을수있으며제품정보는예고없이변경될수있습니다. 각지역에서제공되는제품또는서비스에대한내용은해당지역의 IBM 비즈니스담당자에게문의하십시오. IBM의향후방향및목표에관한모든내용은예고없이변경되거나취소될수있으며, IBM의방향이나목표이외의다른의미를갖지않습니다. 본문서에수록된정보는최초출판일에만최신정보로인정되며, 예고없이변경될수있습니다. 모든성능정보는통제된환경에서확인되었습니다. 실제결과는다를수있습니다. 성능정보는 " 있는그대로 " 제공되며, IBM은어떠한명시적이거나암묵적인보장이나보증도하지않습니다. IBM 외제품에대한정보는해당제품의공급업체나해당업체가발표한내용, 또는기타공개적으로사용가능한출처로부터제공받았습니다. IBM 외제품의성능에대한문의는해당공급업체에게해주십시오. IBM은본문서에서제공하는정보가귀사또는귀사의배급업체또는고객의요구사항을충족한다는보증을하지않습니다. IBM은정보를 " 있는그대로 " 보증없이제공합니다. IBM은비침해, 상품성및특정한용도에대한적합성의암묵적인보증을포함한모든명시적이고암묵적인보증을부인합니다. IBM 제품은해당제품의제공에관한계약의조건및규정에따라보증됩니다. info@xivstorage.com www.xivstorage.com