시스템/클라우드2011. 2. 7. 00:14

Linux의 쓰임새가 점차 대형화, 고속화를 요구하게 되면서, 많은 부분이 그에 맞추어 향상되고 있다. 64 Bit 프로세서, 기가바이트(Giga Byte : 2^30 Byte)대의 메모리, 기가비트급 네트웍, 테라바이트(Tera Byte : 2^40 Byte) 심지어 페라바이트(Pera Byte : 2^50 Byte) 규모의 파일시스템... 이루 말할 수 없는 변화가 시시각각 일어나고 있다.

올해 초, Linux Kernel 2.4 가 발표되면서 많은 기능 향상과 추가가 이루어졌다. 위에 언급한 기업수준의 규모를 어느 정도 만족시킬 수 있게 되었다. 그중에 눈에 띄는 것이 바로 LVM를 기본으로 지원한다는 것이다.

 

1. LVM 이란?


    LVM 은 Logical Volume Manager 의 약자로서, 저장장치들을 좀더 효율적이고 유연하게 관리할 수 있는 커널의 부분과 프로그램을 말한다. 처음에는 IBM에서 개발되었는데, 그후에 OSF(현재는 OpenGroup http://www.opengroup.org)에서 차용을 하여 OSF/1 operating system 에서 쓰였다. 지금은 HP-UX, Digital Unix operating system, AIX 등의 상용 유닉스에서 쓰고 있다. 리눅스 버전은 현재 HP-UX의 것을 모델로 하여 Sistina Software 사(http://www.sistina.com)에서 open source로 개발하고 있다.


    LVM 을 이해하려면 먼저 Software RAID (Redundant Array of Inexpensive Drives)를 언급해야 하는데, 이 둘은 비슷하면서도 큰 차이가 있다.
    비슷한 점은 여러 물리적인 디스크들을 하나의 논리적인 디스크처럼 다룰 수 있게 함으로서 조합방법에 따라 고용량, 고속, 데이터의 무결성을 실현하는 점이다.
    하지만 분명하게 다른 점이 있는데. lvm은 raid보다 관리 및 확장이 비교적 쉬운 반면, raid에는 lvm에는 없는 disk mirroring(RAID level 1), Parity Stripe (RAID level 4,5) 등의 방식이 있어서 속도 또는 데이터의 무결성을 보장 받을 수 있다.


    그러나 이런 차이점에도 불구하고 lvm가 주목을 받는 이유는 다음과 같다.


    ·쉬운 관리.
    ·서로 다른 많은 디바이스 조합 지원.
    ·직관적인 저장 장치로의 접근.
    ·뛰어난 확장성.
    ·믿을만한 안전성과 효율.
    ·스냅샷 기능 지원.  


    이와 같은 특징들로 인해 사용자들이 얻는 이득은 많다.


    우선, pc 급 시스템 사용자들의 가장 큰 고민 중의 하나가 시스템을 처음 설치할 때에 파티션의 구성을 어떻게 할 것인가 일 것이다. 파티션은 한번 구성해 놓으면 바꾸기가 쉽지 않기 때문이다. 또 파티션이 가득 차기라도 하면 어렵게 백업을 하거나 눈물을 머금고(?) 자료를 지워야 할 경우도 심심치 않게 생기기 마련이다. 하지만 LVM를 쓰면 간단하게 저장공간을 확장, 축소 할 수 있기 때문에 그런 고민을 덜 수 있다.


    다른 예로, 중소형 서버에서는 비교적 적은 비용으로 대용량 저장 장치를 구현하는 것이 가능해진다. 그리고, 백업 없이 기존의 환경을 유지한 채 확장이 가능하기 때문에 (물론 백업은 *언제나* 중요하다.) 유지보수면에서 상당한 이득이 있을 것이다.

 

2. 기본 지식


    일반적으로 유닉스 시스템에서 저장 장치를 쓰는 방법은 그 장치의 블록 디바이스(Block Device)에 파일 시스템 (File System)을 만들어서 (다른 표현으로는 포맷(Format)한다라고 하지만 유닉스의 세계에서는 잘 쓰지 않는다.) 디렉토리에 마운트 시키는 것이다. 예를 들어, 두번째 버스의 프라이머리 ide 디스크의 첫번째 파티션에 reiserfs 파일 시스템을 만든 후, /debian/ftp 라는 디렉토리에 마운트를 시킨다면 다음과 같은 절차를 밟을 것이다.


    # mkfs -t reiserfs /dev/hdc1
    # 화면에 나오는 질문에 y 라고 답변
    # mount -t reiserfs /dev/hdc1 /debian/ftp


    lvm을 써도 마찬가지 절차를 밟는다. 단지, 실제 블록 디바이스가 아닌 가상의 블록 디바이스를 쓴다는 점이 틀리다.



    <그림 1>


    실제적으로 lvm은 커널에서 파일 시스템과 블록 디바이스 사이에 위치하여 동작한다. 일반적인 방식과 lvm에 의해 동작하는 방식의 차이는 <그림1>에 잘 나타나 있다.


    lvm의 동작 방식의 이해와 활용을 위해서는 몇 가지 용어에 대한 사전지식이 필요하다.

     

    1)  VG, PV, LV


    VG(Volume Group)은 LVM의 가장 기본적인 요소이다. 쉽게 말하자면 가상 디스크라고 할 수 있는데, 하나 이상의 실제 물리적으로 존재하는 블록 디바이스가 모여서 VG를 이루게 된다.


    그 물리적인 블록 디바이스를 PV(Physical Volume)라고 하는데, 거의 대부분의 장치를 PV로 쓸 수 있다. 하드디스크 및 그 파티션, 소프트웨어/하드웨어 RAID 장치, 심지어 Loopback 블록 디바이스(파일 시스템상의 파일을 블록 디바이스처럼 쓸 수 있게 해준다)까지도 말이다.


    PV와 대비되는 것이 LV(Logical Volume)이다. 이것은 가상 파티션이라고도 할 수 있는데, VG를 적당히 나누어 할당한 것이 LV이다. 사용자는 LV를 일반 디스크나 파티션처럼 쓰면 된다.


    정리하자면, <그림2>를 보면 알 수 있듯이, 하나 이상의 PV가 모여 VG를 이루고, VG를 가상적으로 나누어 할당하면 LV이 된다.

    < 그림 2 >


    참고적으로, 한 시스템에서 VG는 최대 99개까지 만들 수 있고, 하나의 VG에는 PV, LV 모두 최대 256개까지 할당할 수 있다.

     

    2)  PE와 LE


    PE(Physical Extent)와 LE(Logical Extent)는 각각 물리적 할당단위와 논리적 할당단위를 뜻한다. 이 둘은 물리
    적인 위치나 크기는 같다.
    그러므로 PE가 LV에 할당되면 LE가 된다라고 볼 수 있다.


    <그림3>를 보면 PE, LE의 관계가 잘 설명되어 있다.

    < 그림 3 >


    VG를 나누어 LV로 할당할 때 LVM은 하드디스크의 섹터처럼 작은 단위로 하지 않고 적당한 크기의 PE로 하게 된다. 그 이유는 할당단위가 극히 작으면, 할당정보가 엄청나게 커지고, 그에따라 시스템의 성능도 느려질 것이다. 또한 할당할 수 있는 크기에도 한계가 생길 것이다. PE의 크기는 VG를 만들 때에 정해지는데, 그에 따라서 VG의 최대 크기가 정해진다. 하나의 VG에는 65536개까지 PE를 할당할 수 있고, PE의 크기는 최소 8KB에서 2배씩 늘어나 최대 512MB까지이다. 그러므로 VG의 최대 크기의 범위는 최소 512MB(8KB x 65536)에서 최대 32TB(512MB x 65536)일 것이다.

     

    3)  VGDA


    PV의 앞 부분에는 VGDA(Volume Group Descriptor Area)라는 부분이 있어서 VG의 모든 정보가 기록된다. 같은 VG에 속해 있는 PV들은 VGDA의 내용이 같다.


    그 내용은, VG의 이름, 상태, 속해있는 PV, LV들, PE, LE들의 할당 상태 등이다. LVM은 이 VGDA 를 참조하고, 갱신하면서 모든 일을 수행한다.

     

    4)  Linear Mapping LV 와 Striped Mapping LV


    앞서 언급한 대로 LVM은 소프트웨어 RAID를 어느 정도는 대체할 수 있다. lvm에서는 두 가지 방식으로 LV를 만들 수 있는데, Linear RAID 와 대응되는 Linear Mapping 방식과 RAID Level 0 과 대응되는 Striped Mapping 방식이 그것이다.  


    두 방식의 차이점은 두개 이상의 비어있는 PV를 가지고 있는 VG에 LV를 할당할 때에, PE를 어떻게 배치시키는가 이다.


    Linear Mapping 방식은 일반적인 것으로써, PE를 순차적으로 할당시킨다. 예를 들어 <그림4>의 왼쪽 그림을
    보면, 각각 3개의 PE가 있는 PV1, PV2으로 이루어진 VG1에 4개의 LE를 가진 LV1을 할당한다고 할 때에, LVM은 먼저 PV1에 3개의 PE를 순차적으로 할당하고 나머지 1개의 PE는 PV2에 할당한다.


    반면, Striped Mapping 방식은 <그림4>의 오른쪽 그림에 나타나 있듯이, 위에서와 같은 환경으로 할당한다고 할 때에, PE는 적당한 크기의 조각들(stripes?)로 나누어진다. LVM는 그것을 두 PV에 분산하여 할당하게 된다. 그러므로 두 PV들에 할당된 PE의 갯수는 같다.




    Striped Mapping 방식의 목적은 두개 이상의 PV를 동시에 읽고 씀으로서, 속도 향상을 바랄 수가 있다는 것이다. 물론, PV들이 서로 독립적인 장치이어야지, 같은 장치 내의 파티션들이라면 오히려 역효과가 날 것이다.

     

    5)  Snapshots  


    규모가 큰 시스템에서 서비스의 중지없이 백업을 할 때에 가장 큰 문제점이 백업도중에 데이터가 변경되는 것이다. 그러면 백업 자체가 무용지물이 될 수도 있기 때문이다.


    그런 문제를 해결하려면 어느 시점에 데이터가 변경되지 못하게 고정시키는 것인데, 그런 기능을 구현한 것이 Snapshot LV이다.


    Snapshot LV는 기존의 LV를 복사하며 별도의 읽기 전용의 LV를 만드는 것이기 때문에, 데이터 변경을 걱정하지 않고 백업을 마칠 수 있을 것이다.  


    [출처] http://www.linuxlab.co.kr/docs/01-05-4.htm

Posted by @dmin @dmin
TAG ,

댓글을 달아 주세요