Es irrt der Mench, solange er strebt.

Xen - I/O 가상화

2.1 디바이스 에뮬레이션

- I/O를 가상화하는 가장 직관적인 방법은 디바이스의 기능을 소프트웨어적으로 똑같이 구현하는 에뮬레이션 방식. 하이퍼바이저는 게스트 도메인에 실제로 디바이스가 존재하는 것처럼 설정하고, 게스트 도메인은 실제 디바이스에서 동작하는 것과 똑같이 동작.

- 에뮬레이션 방식의 장점은 가상의 디바이스를 제공함으로써 게스트 도메인의 드라이버를 수정없이 그대로 쓸 수 있음. 잘 알려진 디바이스를 에뮬레이션하면 게스트 운영체제 대부분이 해당 디바이스의 드라이버를 사용할 수 있으므로 다양한 게스트 운영체제를 지원할 수 있음.

2.2 반가상화 인터페이스

- 게스트 운영체제를 수정할 수 있다면 , 좀 더 효율적으로 I/O 가상화를 구현할 수 있다. 게스트와 하이퍼바이저 사이에 I/O 디바잉스에 대한 새로운 상위 수준 인터페이스를 정의해 게스트가 직접 하이퍼바이저에 I/O요청할 수 있음.

- 네트워크 디바이스의 경우 디바이스 에뮬레이션은 모든 저 수준 I/O 명령어를 있는 그대로 에뮬레이션해야 함. 패킷 하나를 네트워크 카드를 통해 전송하려면 저 수준 I/O 명령어를 요구. 이는 에뮬레이션을 실행할 때의 오버헤드 뿐만 아니라 게스트와 하이퍼바이저 사이에 많은 수의 컨택스트 스위칭을 일으키며 발생하는 오버헤드도 많음. 반가상화를 통해 게스트와 하이퍼바이저 사이의 인터페이스를 정의할 때는 좀더 상위 수준의 인터페이스로 정의. 이렇게하면 사용자의 저 수준 I/O 명령을 send_packet과 같은 한 번의 요청으로 처리할 수 있음. 게스트와 하이퍼바이저의 컨텍스트 스위치는 한 번으로 충분하고, 디바이스 에뮬레이션을 실행할 필요도 없으므로 높은 성능의 I/O 가상화를 구현.

2.3 분리 드라이버 모델(Split Driver Model)

- I/O 가상화 구현 시 논의하는 것은 디바이스 드라이버에 대한 관점. 일반적으로 디바이스 드라이버는 운영체제를 이루는 핵심 요소이며 현존하는 많은 디바이스를 운영체제가 지원해야 하므로, 실제로 리눅스 커널에서도 디바이스 드라이버의 소스 코드가 커널의 대부분을 차지.디바이스 제어를 하이퍼바이저가 하도록 설계한다면, 디바이스 드라이버의 모든 코드를 하이퍼바이저가 유지해야 하므로 상당히 비효율적. 이미 운영체제가 가진 소스코드를 소유해야 하는 중복성 측면의 문제와 하이퍼바이저를 유지 보수하는 과정에서 대용량의 소스 코드를 허용하기 쉽지 않음. 또한 하이퍼바이저가 디바이스 드라이버를 유지하면, 디바이스 드라이버의 오동작 때문에 에러가 발생하면 시스템 전체에 영향

- 이러한 이유로 디바이스 드라이버를 하이퍼바이저와 별도로 관리하자는 분리 드라이버 모델이 등장. 디바이스 드라이버로 실제로 디바이스를 제어하는 별도의 특수한 도메인을 두도록 함.

- Xen 하이퍼바이저에서는 도메인0(DOM0)을 디바이스 드라이버를 전담하는 도메인으로 할당했고, 도메인0에서 리눅스를 구동시켜 리눅스 커널에 존재하는 모든 디바이스 드라이버를 사용할 수 있음.

- 디바이스 드라이버는 하이퍼바이저가 아닌 특정 도메인에 존재하고 하이퍼바이저가 소유한 드라이버를 사용해 직접 하드웨어 디바이스에 접근. 게스트가 반가상화 인터페이스를 사용했다면 드라이버 도메인의 반가상화 인터페이스가 게스트로부터 I/O 요청을 받아서 디바이스 드라이버로 전달. 반가상화 인터페이스를 사용하지 않았다면, 드라이버 도메인에서 디바이스를 에뮬레이션해 I/O요청을 실제 디바이스 드라이버에게 보냄.

4. 직접 접근 I/O (Direct Access I/O)

- 가상화 환경은 디바이스 하나를 여러 게스트 도메인이 공유하므로 하이퍼바이저의 적절한 중재가 필요.그러므로 게스트가 직접 디바이스에 접근하는 것은 허용할 수 없음.

- 그러나 특정 디바이스를 게스트 도메인 하나만 사용하도록 허용한다면 게스트는 하이퍼바이저의 중재 없이 직접 디바이스와 통신할 수 있을 것. 이렇게 게스트 운영체제가 직접 디바이스에 접근해 I/O를 요청하는 것을 직접 접근 I/O라고 부르며, 하이퍼바이저를 통해 직접 디바이스에 접근한다고 하여 Paththrough I/O라고도 부름.

- 직접 접근 I/O는 성능이 우수하며 실제로 가상화되지 않은 환경과 동일한 성능을 보장하기도 함. 일단 디바이스를 게스트 도메인에 할당하면 하이퍼바이저의 중재 없이도 바로 I/O를 실행하기 때문.

- 직접 접근 I/O의 단점

1) 메모리 보호: 디바이스 I/O를 직접 실행한다는 것은 직접 DMA(Direct Memory Access)연산을 실행한다는 것을 의미. 디바이스는 DMA연산으로 직접 시스템 메모리의 데이터를 읽고 쓸 수 있음. 이때 어떤 게스트에 디바이스를 할당했는데, DMA를 통해 악의적인 게스트가 임의로 다른 게스트의 메모리 영역에 쓰기 연산을 실행하면 해당 게스트는 오작동일 일어날 것.

2) 전가상화 지원: DMA 명령을 내리려면 게스트 운영체제가 머신 주솔르 알아야 함다. DMA는 직접 시스템 메모리에 접근할 때 머신 주소를 입력으로 받아 DMA를 실행하기 때문. 그러나 전가상화 게스트 운영체제는 머신 주소를 알지 못하므로 올바른  DMA요청을 실행할 수 없음.

3) 디바이스 공유: 

부하분산 방식 2

3.3 서버 감시 기능 

- 서버 감시 기능에는 'L3 체크', 'L4 체크', 'L7체크' 세 가지 종류가 있고, 계층이 높은수록 유연하고 상세한 서버 상태 감시가 가능.

3.3.1 L3 체크(IP주소 체크)

- IP주소 상태를 감시하는 기능. ICMP 사용

3.3.2 L4 체크(서비스 체크)

- 포트 번호를 감시하는 기능. TCP/UDP 감시

3.3.3 L7 체크(어플리케이션  체크)

- 어플리케이션 감시. 서버 어플리케이션의 특정 응답 여부를 감시.

ex) http 상태 코드

- 웹 어플리케이션이 정상적으로 동작하고 있으며 HTTP 상태 코드'200 OK'로 응답하고, 응답 구문 안에 문자열로 포함 함. 어플리케이션에 문제가 있을 경우 '503'의 500번대 응답이 발생. 웹 페이지 내에 컨텐츠가 존재하지 않는 경우는 '404'와 같이 400번대 응답이 발생. L7 체크는 200번 이외의 상태가 돌아오면 서버를 서비스로 부터 격리.

- 유연한 감시가 가능하나 서버 부하가 올라감. 예를 들면 HTTPS 서버 감시의 경우 외부 침입 방지를 위해 SSL 핸드 쉐이크라는 처리를 사용해 접속. SSL 핸드쉐이크는 SSL키 교환 처리를 포함하고 있어 서버에 큰 부하가 걸림.

Xen 메모리 가상화

1. 메모리 가상화

-Virtual Memory

2.1 가상 메모리

- 가상 메모리를 사용하는 이유는 독립 주소 공간, 요구 페이징 등

- 가상 메모리를 구현한다는 것은 결국 메모리 주소를 속이는 것...

- CPU가 내보내는 메모리 주소, 즉 운영체제나 어플리케이션이 사용하는 주소는 실제 메모리의 물리주소가 아닌 자상 주소이다. 가상 메모리를 구현하려는 CPU 제조 업체는 저마다 하드웨어 관점에서 가상 주소를 물리 주소로 변환하는 MMU(Memory Management Unit)_라는 것을 제공.

- 가상 주소와 물리 주소와의 매핑을 결정하는 것은 페이이 테이블(Page Table). 운영체제는 가상 주소와 물리 주소 사이의 매핑 정보를 페이지 테이블에 기록. 그런 다음 CPU의 페이지 테이블 베이스 레지스터가 페이지 테이블에 기록하 메모리 주소를 등록하면, MMU는 페이지 테이블을 검색해 CPU가 내보내는 가상 주소의 실제 물리 주소를 찾아내 변화하고, 변환된 주소를 통해 메모리에 접근. 

- 페이지 테이블 구조

- x86 아키텍처 32비트 모드의 기본적인 테이블 구조이고 CPU는 32비트 주소를 사용하고, 페이지 디렉터리의 시작 주소는 CR3레이지터에 저장. 32비트 메모리 주소 중 31~22비트 까지의 10비트는 페이지 디렉터리의 인덱스로 사용, 해당 인덱스가 가리키는 페이지 디렉터리의 엔트리는 페이지 테이블의 시작 주소를 나타 냄.

- 21~12비트까지는 페이지 테이블의 인덱스로 사용하고, 해당 인덱스가 가리키는 페이지 테이블의 엔트리는 실제 물리 메모리 한 페이지의 시작 주소가 된다. 10비트의 인덱스로 2^10인 1,024개의 엔트리를 나타낼 수 있고, 32비트 머신에서 엔트리 하나는 4바이트를 차지하므로 페이지 디렉터리나 페이지 테이블 하나는 각 4KB의 페이지 크기 만큼 메모리 공간을 차지하게 됨다. 마지막으로 남은 11~0비트까지의 12비트는 4KB 페이지 안의 오프셋을 나타내고, 찾고자하는 최종 물리 주소가 된다. 12비트로 나타낼 수 있는 주소 버무이는 2^12인 4KB가 되므로 4KB로 페이지 안의 모든 주소를 가리킬 수 있음.

- 복잡한 다단계 구조로 페이지 테이블을 구성한 까닭은 MMU 구현의 효율성과 페이지 테이블의 크기와 관련. 페이지 테이블을 하나로 구성한다면 1개의 페이지 크기가 4KB인 페이지 테이블은 2^32/2^12인 1,048,576개의 엔트리가 필요. 엔트리 하나의 크기는 4바이트이므로 총 4MB의 공간이 필요. 페이지 테이블은 프로세스마다 독립적으로 하나씩 존재하므로 모든 프로세스에 이렇게 4MB의 배열을 메모리에 할당하는 일은 매우 비효율적인 방식. 모든 프로세스는 4GB의 주소 공간 중 극히 일부분만ㅇ르 사용하므로 주소 공간이 필요한 부분만 페이지 테이블을 만들어 할당 하 수 잇는 다단계 방식을 취함.

2.2 가상화 환경의 메모리 주소 체계

- 비 가상화 환경에서 물리 주소와 가상 주소라는 두 단계 주소 체계를 가진다면, 가상화 환경에서는 가상주소, 물리주소,머신 주소라는 세 단계를 가짐.

- 가상 머신에서 동작하는 게스트 운영체제는 가상화 환경에서 동작한다는 사실을 모름. 가상 머신은 가상화 되지 않은 환경에서 동작할 때와 마찬가지로 가상 주소와 물리 주소를 그대로 사용. But 가상 머신이 아는 물리 주소는 실제 물리 주소가 아니며, 하이퍼바이저의 중재 아래 실제 물리 주소로 변환해서 사용해야 함.

-  ex) 가상 머신이 사용하는 물리 주소를 그대로 사용한다면 기본적으로 운영체제는 할당된 메모리가 0번지 부터 시작한다고 생각하고 동작. 그러면 모든 가상 머신은 너도나도 0번지부터 시작하는 메모리를 사용할 것이고, 모두 같은 영역의 메모리를 사용하므로 충돌이 일어나서 정상적으로 작동할 수 없음. 하이퍼바이저가 적절히 중재를 해야함.     512MB의 메모리를 가진 가상 머신 두 개를 동작시킨다고 하면 첫 번째 가상 머신에는 실제 메모리의 0~512MB영역을 할당하고, 두 번째 가상 머신에는 513~1,024MB 영역을 할당.

2.3 섀도 페이지 테이블

- 가상화 환경의 메모리 주소 체계에서는 게스트 운영체제가 생각하는 물리 주소를 실제 머신 주소로 변환해서 사용해야 하는데, 이때 일반적으로 하이퍼바이저에서는  Shadow Page Table이라는 가상의 페이지 테이블을 사용. 운영체제가 사용하는 페이지 테이블이 가상 주소에서 물리 주소로 변환하는 정보를 저장한다면, 섀도 페이지 테이블은 가상 주소에서 머신 주소로 변환하는 정보를 저장하는 테이블 페이지. 하이퍼바이저는 머신 주소 정보를 가지므로, 섀도 테이블을 구축하고 페이지 테이블 베이스 레지스터에 섀도 페이지 테이블의 시작 주소를 등록. 그러면 MMU가 참조하는 페이지 테이블은 섀도 페이지 테이블이 되고, CPU가 생성하는 가상 주소를 머신 주소로 변경해 사용.

2.4 직접 페이지 테이블 접근

- 섀도 페이지 테이블은 메모리 가상화에 아주 적합해 보이는 방법이지만 어쩔 수 없이 오버헤드를 가짐. 게스트 운영체제 모든 프로세스의 페이지 테이블을 중복해서 가지며, 항상 게스트 운영체제의 페이지 테이블과 동기화해야 하는 등 성능 저하를 발생시키는 요인이 있음.

- 반 가상화 기법을 사용하면 게스트 운영체제의 소스 코드를 수정할 수 있으므로 섀도 페이지 테이블을 사용하지 않고도 메모리 가상화를 할 수 있음. Xen에서는 게스트 운영체제를 수정해 게스트 운영체제가 직접 페이지 테이블을 올바르게 수정하도록 변경할 수 있음.

- 가상 주소와 머신 주소사이의 주소 변환은? 게스트 운영체제는 물리주소와 머신주소 사이의 매핑 정보를 가짐. 직접 페이지 테이블에 주소를 저장할 때, 물리 주소가 아닌 머신 주소를 저장. Xen의 경우에는 하이퍼 콜을 통해서 하이퍼바이저에 테이블 수정을 요청. 하이퍼바이저는 유효한 요청인지 검사한 후 요청을 수락.

- 게스트 운영체제의 페이지 테이블은 가상 주소와 물리 주소 사이의 변환 테이블이 아니라 가상 주소와 머신 주소 사이의 변환 테이블을 가짐. MMU가 직접 게스트 운영체제의 페이지 테이블을 참조해도 정상적으로 동작하는 것. 이는 직접 소스코드를 수정해야 하는 번거로움이 있지만 섀도 페이지 테이블과 같이 중복해서 페이지 테이블을 유지할 필요가 없기 때문에 성능상의 이점.

2.5 중첩 페이지 테이즐

- 중첨 페이지 페이블은 AMD가 관련 기능을 먼저 지원. AMD-Nested Page Table/인텔-Extended Page Table.

- 기존의 가상 메모리가 가상 주소에서 물리주소로 변환하는 기능을 하드웨어적으로 구현한 것이라면, 중첩 테이블은 물리 주소에서 머신 주소로 변환하는 기능을 하드웨어적으로 구현한 것.

- CPU가 내보내는 가상 조소는 게스틍 운영체제가 구축한 페이지 테이블을 통해서 물리 주소로 변경하고, 변경한 물리 주소는 다시 하이퍼바이저가 구축한 중첩 페이지 테이블을 통해서 머신 주소로 변경해 메모리에 접근. 게스트 운영체제는 페이지 테이블을 구축할 때 섀도 페이지 테이블이나 직접 접근 방식에서 발생하던 페이지 폴트 같은 부가적인 오버헤드 없이 페이지 테이블을 구축할 수 있음. 하이퍼바이저가 게스트 운영체제를 생성할 때 할당해준 메모리의 머신 주소 정보만 중첩 페이지 테이블에 적어주면 쉽게 메모리 가상화를 할 수 있음.

Xen CPU 가상화

1. 가상 머신 모니터? (Virtual Machine Monitor) 

- 가상 머신을 모니터링하는 소프트웨어 계층. 단순 모니터링 뿐만 아니라 하드웨어 자원 관리, 가상 머신 스케쥴링 등 가상 머신을 동작시키는 데 필요한 모든 작업을 담당.

1.1 왜 가상화인가?

-  Server Consolidation? 최초 물리 서버 머신 하나가 다수의 CPU와 대량의 메모리를 갖출 수 있게 되면서 많은 자원이 유휴 상태로 남는 경우가 많아, 이런 유휴한 상태의 서버를 머신 하나로 통합 관리하자는 요구가 생김. 가상화 기술을 이용하면 물리 서버 하나를 가상 머신 하나로 대체하고 이 가상 머신 여러 대를 강력한 성능을 가진 물리 머신 하나에서 동작시켜 시스템 자원의 효율성을 극대화.

- Isolation? 가상 머신의 격리? 웹 서버, DB서버, DNS서버 등 여러 서버를 하나의 머신 위에 동작시켜도 되지만 이를 나누어 독립된 가상 머신에서 수행시켜 줌.

- 클라우드 서비스

1.2 하이퍼바이저 종류

  1.베어메탈                                                                       2. 호스트 기반

 1) 베어메탈 방식은 하드웨어 전원이 들어오면 가장 먼저 하이퍼바이저가 부팅을 시작하게 되고, 부팅을 완료하면 관리자가 가상 머신을 생성해서 여러 개의 가상 머신이 동작. Xen/VMWare/Hyper-V

 2) 호스트 기반 방식은 호스트 운영체제가 존재하고, 그 위에서 하이퍼바이저가 동작하며 다시 그 위에 게스트 운영체제가 동작. VirtualBox/KVM 

2. CPU 가상화

2.1 에뮬레이션과 직접 실행?

- ex) 안드로이트 플랫폼의 x86 아키텍쳐인 PC에서의 실행. 에뮬레이터는 안드로이드 ARM 바이너리 이미지를 스캔해 역어셈블 과정으로 ARM 명령어를 추출. 그런 다음 추출해 낸 ARM 명령어를 x86에서 동작할 수 있도록 번역하여 소프트웨어로 만들어진 가상 머신 위에서 동작하게 함. 에뮬레이션로의 실행은 머신이나 디바이스에서 실행하는 것 보다 성능이 저하. 

- 직접 실행(Direct Execution)은 에뮬레이션의 단점을 극복하고자 바이너리 프로그램을 번역과정 없이 직접 CPU에서 실행하는, 즉 가상화 환경이 아닌 것처럼 바이너리 프로그램을 CPU가 직접 실행하게 하는 것.

2.2 특권 모드& 비특권 모드

- Privileged mode: 일반적으로 응용 프로그램은 비특권 모드에서 실행되고, 운영체제 커널은 특권모드에서 실행.

- 운영 체제는 시스템 전체를 관장하며, 하드웨어를 보호하고 관리. 어플리케이션이 하드웨어에 직접 접근할 수 없게하고, 원하는 서비스를 시스템 콜을 통해 요청하도록 규정. ex) 어플리케이션이 파일에서 데이터를 읽으려면 프로그래머는 read()라는 시스템 콜을 호출하며, 운영체제는 디스크에서 직접 데이터를 읽어 어플리케이션에 전달.

- 특권 모드와 비 특권모드를 명확히 구분하지 않으면 악의적인 프로그램이나 프로그래밍 실수로 시스템 전체의 안정성을 위협할 수 있음.

2.3 특권 명령 및 트랩

- 특권 명령은 특권 모드에서만 실행 가능한 명령어를 의미. Trap는 0으로 나누기나 디버거를 위한 중단점 등과 같이 특정 이벤트를 만나면 프로그램의 제어권이 트랩 핸들러로 넘어가는 것을 의미.

2.4 전통적인 하이퍼바이저 구현 방법

- 트랩과 에뮬레이트 방식을 통해 구현. 하이퍼바이저는 하드웨어 하나에 여러 개의 운영체제를 동작하게 하는 것이 주된 의무이므로 운영체제보다 더 높은 특권이 필요. 운영체제와 하이퍼바이저가 모두 특권 모드에서 동작한다면 여러 개의 운영체제가 동시에 특권 명령으로 하드웨어 자원에 접근할 수 있어 시스템 오류를 가져올 수 있음. 하이퍼바이저는 특권 모드에서, 운영체제는 비특권 모드에서 실행 됨. 비 특권 모드에서 동작하는 운영체제가 특권 명령을 실행할 때마다 트랩이 발생해 하이퍼바이저로 제어권이 넘어가며, 하이퍼바이저는 적절히 관련 루틴을 에뮬레이트하고 다시 제어권을 운영체제로 넘겨 줌.

2.5 바이너리 변화과 하이퍼 콜

- 바이너리 변환(VMware)은 운영체제의 코드 이미지를 하이퍼바이저가 스캔해 특권 명령과 비특권 명령의 경계가 모호한 명령어들 때문에 발생하는 오류 명령어를 찾아내고 검출. 그리고 해당 명령어를 적적히 수정하여 잘 동작할 수 있는 코드를 만들어 실행. CPU에서 직접 실행하는 방식이지만 중간에 하이퍼바이저가 번역하는 과정이 추가 됨.

- 하이퍼 콜은 반가상화 기술의 일종이며 Xen에서 사용하는 방식으로 번거롭지만 직접 운영체제의 소스를 수정하여 문제의 소지가 있는 명령어를 제거. 하이퍼바이저로 호출할 수 있는 하이퍼 콜로 바꾸어서 문제의 소지가 있는 명령어가 실행될 시점에 하이퍼바이저로 제어권이 넘어가게 됨. 하이퍼바이저는 게스트 운영체제의 요청을 받아서 적절히 처리한 다음 다시 게스트 운영체제로 제어권을 넘김.

2.6 하드웨어 지원

- 가상화 기능을 CPU에 추가 시킴. 인털의 VT-x, AMD의 SVM(Secure Virtual Machine) 벤더마다 약간의 아키텍쳐적인 차이점은 있겠으나 전반적임 개념은 비슷. 게스트 운영체제의 소스 코드를 수정하거나 바이너리 변환 방법 없이도 트랩과 에뮬레이트 방식으로 하이퍼바이저를 구현할 수 있도록 하드웨어적인 기능을 추가.

    인텔 VT-x : 하이퍼바이저를 위한 root모드와 게스트 운영체제를 위한 non-root모드. 게스트 운영체제는 non-root모드의 특권 모드에서 동작, 어플리케이션은 non-root 모드의 비특권 모드에서 동작. 문제가 될 수있는 명령어가 non-root 모드에서 실행되면 트랩이 발생하고 root모드로 변경되어 하이퍼바이저로 제어권이 넘어가도록 구현.

3. Paravirt Operation & 하이퍼 콜

3.1 반가상화(Para Virtualization)

- 운영체제의 소스 코드를 수정해서 가상화 구현. 이를 통해 운영체제와 하이퍼바이저 사이의 협력을 극대화한 가상화 시스템의 고성능화를 구현.

- Xen: 하이퍼 콜 인터페이스, VMware: VMI인터페이스, 

3.2 Paravirt Operation

- 가상 솔루션 벤더마다 반가상화 인터페이스를 따로 만들어 리눅스 커널을 수정 -> 소스코드의 복잡성과 관리 문제

- 해결을위해 리눅스에서 공통 API를 제공하고 각 하이퍼바이저 벤더는 여기에 맞춰 인터페이스를 제작할 수 있도록 구현한 것이 Paravirt Operation(Pv-ops)

- 리눅스 커널의 가상화는 필요한 루틴에 공통 API를 만들어 여기에 하이퍼 콜 혹은 VMI인터페이스를 연결하는 방식으로 구현. 최초 Xen은 리눅스 2.6.18 커널을 대폭 사정하여 Xen Linux를 만들었고 이를 Pv-ops에 맞도록 포팅. 

1. 코드 Paravirt Operation 자료 구조.txt

* 첨부 참조 *

- paravirt_patch_template라는 구조체는 기능별로 세부 ops 구조체를 가지며 pv_cpu_ops 구조체는 CPU와 직접적인 관련이 있는 명령의 모임. read/write cr0, cr4 같은 명령어는 paravirt operation으로 대체할 수 있음, CR0와 CR4레지스터는 x86아키텍쳐에서 주요한 시스템 플래그를 모아놓은 Control Register이고, 페이징 활성화, 캐시활성화, 세그멘테이션 활성화 등 주요 설정을 할 수 있는 레지스터.

...

중 략 (추후)

...

3.3 하이퍼 콜

- Xen의 Hypercall 인터페이스는 일반 운영 체제의 시스템 콜과 방법이 비슷함.

1) x86아키텍쳐에서 리눅스가 시스템 콜을 호출하는 방법

- 프로그래머가 시스템 콜을 사용할 때는 보통 glibc와 같은 라이브러리를 통해서 호출. 이때 사용자가 호출하는 것은 실제 시스템콜이라기 보다는 라이브러리에서 제공하는 시스템 콜 래퍼(wrapper)함수이며 라이브러리 루틴에서 실제로 시스템 콜을 요청하는 명령어를 사용. 

- Xen에서는 SYSCALL/SYSRET 명령이라도 사용자 프로세스가 호출한 시스템 콜인지 케스트 운영체제가 호출한 하이퍼 콜인지를 구분해서 처리

...

코드

...

4. 하드웨어 지원

- x86아키텍쳐는 포펙과 골드버그의 가상화 요구를 만족하지 않으므로 가상화 프로그램 구현이 복잡. Xen의 경우 특권 명령을 하이퍼 콜로 요청하는 수정한 커널을 사용하는 반가상화를 기반으로함. 윈도우와 같이 커널을 수정할 수 없는 운영체제는 전가상화(Full Virtualization)을 통해서 지원.

- Xen에서의 전가상화는 HVM(Hardware Virtual Machine)을 통해서만 가능.HVM은 CPU에서 가상화 기능을 제공하는 하드웨어적 가상화 기술을 의미.인텔:VT-x / AMD: SVM

- 성능상의 이점과 하이퍼바이저 구현이 쉬워진다는 이유로 HVM을 활용. 

4.1 인텔 VT-x 개요

- VT-x는 가상화를 지원하는 새로운 개념인 VMX Operation이존재- 하이퍼바이저와 가상 머신이 동작하는 환경 구분

- VMX root Operation: CPU나 하드웨어의 모든 제어권을 가진 오퍼레이션.

- VMX non-root Operation: 특정 명령어 실행과 하드웨어 제어권한이 일부 제한된 오퍼레이션 (Virtual Machine)

- VMX root Operation과 non-root Operation이 서로 전환하는 것을 VMX 전환이라고 함.

- VM Entry: VM root오퍼레이션에서 VM non-root오퍼레이션으로 진입하는 VMX 전환

- VM Exit: VM non-root 오퍼레이션에서 VM root 오퍼레이션으로 빠져나가는 VMX전환

- 가상 머신은 VMX non-root 오퍼레이션에서 동작중이더라도 기존 네이티브 시스템과 같다고 인식. 특권 명령을 실행하면 VM Exit가 발생해 VMX root 오퍼레이션으로 전환. 그런 다음 VMX rot 오퍼레이션에서 하이퍼바이저가 특권 명령을 처리한 뒤에는 VM Entry로 다시 가상 머신에 진입.

-  VMX non-root 오퍼레이션의 프로세서 동작은 가상화가 쉽도록 제한. VMX non-root 오퍼레이션에서 가상 머신이 VMCALL과 같은VMX명령어를 실행하거나 특정 이벤트가 발생하면 VM Exit가 발생해 하이퍼바이저로 제어권이 넘가감. 특정 명령어를 실행했을 때 VM Exit가 발생하므로 VMX non-root 오퍼레이션의 동작은 제한적. CPU리소스는 VMX root 오퍼레이션에서 하이퍼바이저가 보두 관리.

4.2 VMX 오퍼레이션 라이프 사이클

1) 하이퍼바이저에서 VMXON명령어를 실행하여 VMX오퍼레이션으로 진입.                                                         2) VMLAUNCH와 VMRESUME명령어를 사용하면 VM Enrty가 발생해 하이퍼바이저는 가상 머신이 동작하는 VMX non-root 오퍼레이션으로 진입.                                                                                                                 3) 가상 머신이 실행 중에 제한되어 있거나 특정 명령어를 실행하거나 이벤트가 발생할 때는 VM Exit가 발생해 하이퍼바이저에 설정된 특정 한 엔트리 지점에 진입. 그러면 하이퍼바이저는 VM Exit가 발생한 원인에 따라 적절히 특권 명령을 처리한 뒤에 다시 가상 머신으로 VM Entry를 발생시 킴.                                                                             4) VMXOFF명령어를 실행해 VMX오퍼레이션을 빠졈 나옴.

4.3 VMCS (가상 머신 제어 구조)

- VMX non-root 오퍼레이션과 VMX전환을 제어하는 용도로 VMCS(Virtual-Machine Control Structure)라는 별도의 자료 구조가 존재. 인텔 VT-x를 사용하는PCPU마다 하나씩 존재하는 VMCS포인터(VMPRT)로 접근. VMPTRST명령어를 사용해 현재 VMSC포인터를 메모리에 저장하고, VMPRTLD명령어를 사용해 VMCS포인터를 설정할 수 있음.

...

VMX 활성화 ( )

...

5. 가상 머신 스케줄링

- 가상화 환경에서는 물리 머신 하나에 여러 개의 가상 머신이 동작. 실제 물리 머신에는 여러 개의 물리 CPU가 존재하고 가상 머신이나 가상의 CPU를 가지게 되는데 이것을 VCPU(Virtual CPU)라고 한다. 

- 가상 머신 스케줄링이란 물리 CPU에서 실행할 VCPU를 어떤 스케줄링 정책을 통해 선택하는 것. 일반 운영체제에서 스케줄러가 CPU에서 동작할 프로세스를 선택하는 과정처럼 가상화 환경에서는 스케줄링 대상이 VCPU가 됨.

- 가상화 환경에서는 다수의 가상 머신을 통합해서 운용하므로 실제 CPU보다 더 많은 VCPU가 존재. 따라서 스케줄럭가 어느 순간에 어떤 VCPU를 얼마만큼 실행시킬지를 결정하는 일이 시스템 전체에 큰 영향을 끼침.

5.1 Xen 스케줄러

...

...

* BOOST 우선 순위

- 운영체제는 I/O 이벤트 방식으로 동작. 하드디스크를 읽으려고 읽기 요청을 하면 하드디스크가 해당 블록의 내용을 전송할 때까지 기다리는 것이 아니고, 다른 작업을 실행하거나 혹은 잠들어 있다가 하드디스크로부터 전송 완료 이벤트(인터럽트)가 발생하면 요청을 실행.웹 서버의 경우 블록 상태 였다가 외부 요청이 오면 이벤트를 받고 깨어나기도 함.

- Xen은 I/O처리를 드라이버 도메인이라는 특정 도메인이 처리. 외부 인터럽트가 발생하면 드라이버 도메인이 깨어나서 해당 인터럽트를 처리. 블록 상태였던 VCPU가 빨리 깨어나서 작업을 실행하면서 시스템 전반적으로 반응 속도가 높아지며, 이렇게 깨어난 VCPU에 한해서 일시적으로 우선순위를 BOOST로 만들면 빨리 스케줄링 되어 실행할 수 있게 만들어 줌.

* 블록 처리

- 게스트 운영체제에서 더 처리할 작업이 없어서 유휴 상태가 되면 하이퍼바이저에 VCPU를 더는 실행하지 말라고 알려 주어야 함. 게스트 운영체제가 반 가상화 상태면 직접 하이퍼 콜을 통해서 하리퍼바이저에 블록 처리를 명령할 수 있고 게스트 운영체제가 전가상화라면 직접 하이퍼바이저에 명령할 수 없으므로 하이퍼바이저 스스로 게스트 운영체제의 halt 명령어를 감지해 블록 상태를 만듦. 운영체제 대부분은 유휴상태가 될 때 x86의 halt 명령어를 실행해 VM Exit를 발생시켜서 하이퍼바이저에 유휴 상태임을 알림. 하이퍼바이저는 VCPU를 블록 상태로 만들고, 스케줄링 이벤트를 발생. 곧 cshed_schedule() 함수 호출 - 블록 상태인 VCPU는 runq에 삽입되지 않으며 깨진 전까지 실행 안 됨.

...

5.6 cpupool

- Xen 4.1 ~ 관리자는 여러 개의 스케줄러를 하나의 머신 위에서 구동. CPU별로 그룹 짓고 특정 스케줄러로 해당 그룹이 동작하게 끔 설정.

- cpupool이 다르면 PCPU가 휴면 상태가 되더라도 다른 cpupool에 할당된 가상 머신 VCPU를 자져와서 실행하지 못함.

- cpupool 자료 구조: 모든 PCPU에는 percpu변수를 통해 해당 cpupool 구조체를 가리키는 포인터가 있음. percpu 변수는 각각 자신이 속한 cpupool을 가리키며 cpupool 구조체는 자신이 가지는 CPU를 스케줄링할 Scheduler 구조체를 가리킴. cpupool_list라는 전역 리스트는 모든 cpupool을 리스트로 엮는다.

출처: Xen으로 배우는 가상화 기술의 이해 'CPU 가상화' 편

부하분산 방식

1. 부하분산 방식 개요

 1.1. 정적 부하분산 방식

 1) 정의

  - 클라이언트로부터 리퀘스트를 받으면 서버 상태와 상관없이 서버가 가지고 있는 설정을 기준으로 할당하는 방식.상시 변하는 서버 상태를 전혀 고려하지 않고 단순히 서버에 할당함으로써 다음 순서로 할당할 서버를 예측하기 쉬움.

  a) 라운드 로빈

  - 클라이언트로부터 받은 리퀘스트를 부하분산 대상 서버에 순대대로 할당하는 방식. 부하분산 대상 서버의 성능이     동일하고 처리 시간이 짧은 어플리케이션의 경우 균등하게 분산이 이루어지기 때문에 이 방식을 사용.

  - 라운드 로빈 방식 

   - 라운드 로빈 방식 단점

      부하분산 대상의 서버의 성능이 다른 경우에 FTP나 Persistence(세션유지기능)가 필요한 어플리케이션의 경우         서버 처리와 관계없이 세션이 할당되는 라운드 로빈 방식은 적합하지 않음.

   b) 가중치(ratio) - 부하분산 대상 서버의 성능에 차이가 있을 때

   - 서버별로 비율을 설정해 두고, 그 가중치에 따라 리퀘스트를 서버에 할당하는 방식. 부하분산 대상 서버의 성능이       동일하지 않으며, 동일한 처리를 한다고 해도 처리 시간에 차이가 발생. 이런 경우 성능이 높은 서버에 높은 가중       치를, 성능이 낮은 서버에 낮은 가중치를 설정하고, 높은 성능의 서버가 많은 처리를 하도록 함. 

   c) 액티브-스탠바이 (Priority Group Activation) - 서버 이중화 개념

   - 서버를 액티브와 스탠바이 상태로 나누어 평상시에는 액티브 장치만 사용. 액티브 장치에 문제가 발생했을 때 스       탠바이 장치로 할당.    

  2.2 동적 부하분산 방식

  1) 정의

  - 클라이언트로부터 리퀘스트를 받으면, 서버 상태에 따라 할당할 대상 서버를 결정하는 방식. 서버나 클라이언트의      상태에 따라 어느 서버에 할당할 것인가를 결정하기 때문에 다양한 프로토콜과 어플리케이션에 유연하게  대처.

   a) 최소 연결 수(Least Connection)

   - 연결이 가장 적은 서버에 리퀘스트를 할당.부하분산 장치는 각 서버에 대한 연결 정보를 가지고 잇고 부하분산 장       치가 리퀘스트를 받는 시점에서 가장 연결 수가 적은 서버를  선택하여 리퀘스트를 할당.

   b) 최소 응답 시간

   - 가장 빨리 응답하는 서버에 리퀘스트를 할당하는 방식. 어떤 서버라도 처리 가능량을 넘게 되면 처리 대기 시간이       길어지고 반응 속도 자체가 느려지게 됨. 부하분산 장치는 클라이언트로부터 전달받은 리퀘스트와 서버 응답 사         이의 시간을 항상 확인있다 리퀘스트를 받으면 가장 빠르게 응답하는 서버를 선택 할당.

   c)  최소 부하

   - Least Loaded 방식은 SNMP에서 취득한 정보를 기준으로 할당한 서버를 결정하는 방식. 부하분산 장치는 SNMP의 매니저가 되어 CPU사용률잉나 메노리 사용량 등 서버 부하에 관한 정보를 정기적으로 수집. 부하분산 장치가 리퀘스트를 받으면 취득한 정보를 바탕으로 부하가 가장 적어 보이는 서버에 할당.

   - 정보 신뢰성은 높지만 실시간 정보가 아님.

** 어떤 부하 분산 방식을 선택할 것인가?

서버 성능과 프로토콜, 어플리케이션 특성 등 여려가지 요소를 고려해서 결정.

단순히 클라이언트 화면을 표시하는 웹사이트이면서 부하분산하는 서버 성능이 동일 -> 라운드 로빈

처리별 tcp 연결 수가 긴 FTP나 세션유지기능이 필요한 웹사이트라면 - 최소 연결 수 방식

등 환경에 따라 적절히 선택이 필요

NAT

NAT (Network Address Translation)

'서버 부하분산 기술의 기본은 목적지 NAT이다'

1. NAT의 정의

 - 패킷의 네트워크 주소(IP)를 변환하는 기술.

2. NAT 종류

 1) 표준 NAT

 - 정적 NAT : 내부와 외부 IP주소를 일대일로 변환.

 - 동적 NAT : 내부에서 외부로 접속할 때 출발지 IP주소를 다수 준비해 두었다가 그 중 하나를 선택.

    정적 NAT가  반드시 같은 IP주소로 변환된다면, 동적 NAT는 변환하는 대상 IP주소가 바뀜.

 2) NAPT(Network Address Port Translation) = IP Masquerade / PAT

 - 내부와 외부 IP주소를 n:1로 변환. 내부에서 외부로 접속할 때 출발지 IP주소뿐 아니라 출발지 포트 번호도 변환. 

    어떤 클라이언트가 어떤 포트 번호를 이용하는가를 확인 후 패킷을 할당하기에 다대일 변환이 가능.

 3) Twice NAT

 - 출발지만이 아니라 목적지까지 한 번에 바꿈. 

 - 회사가 합병된다거나 다른 회사 시스템과 통합되는 등 주소 범위가 중복되어 구성되는 때.

서버부하분산 개요

1. 서버 부하분산의 정의

- 서버 부하란? 서버관리 그 자체. 서버가 어떤 처리를 시작하면 CPU나 디스크 등 수많은 부품들이 동작하게 되고, 그 하나하나가 바로 서버 부하가 됨.

- 분산? 동일한 서비스(HTTP, FTP 등)를 제공하고 있는 복수의 서버에 작업을 분배하는 것을 말함.

   클라이언트 접속으로 서버 부하가 발행하며 클라이언트 접속을 분산함으로써 처리 부하를 복수의 서버에 분산시킴.

2. 서버 부하분산의 이점

 1) 처리 능력 향상

 - Scale-up: 서버 자체의 능력을 향상 시킴.

 - Scale-out : 처리할 수 있는 서버의 수를 증가 시킴.

 2) 장애대처 능력 향상

 - 멈추지 않는 시스템. 한 대의 서버가 다운돼도 그 서버를 격리시켜 다른 서버가 서비스를 제공할 수 있게 됨.

 3) 유지관리 효율 향상

 - 여러 대의 서버를 한 대씩 작업(패치,업데이트 등)이 가능하며, 작업 동안 다른 서버가 서비스를 지속할 수 있음.

3. 서버 부하분산 기술

 1) DNS 라운드 로빈

 - DNS 라운드 로빈(DNS Round Robin)은 DNS 서버 자체 기능으로 부하 분산을 구현.

 하나의 이름에 대한 복수의 IP 주소를 DNS 서버에 등록해 두고, 클라이언트로부터 요청이 오면 등록된 IP주소를 '순서대로'(Round Robin) 전달하는 방식. 전달되는 IP주소가 바뀌기 때문에 개별 클라이언트가 접속하는 서버 IP주소가  달라짐.

- 문제점: 서버 장애가 발생해도 알기 어렵다. DNS 서버는 접속 서버의 장애를 알 수 없음 -> 클라이언트 접속 장애

  균등하게 부하분산을 하지 않는다. (클라이언트의 캐쉬 - 캐쉬가 없어질 때 까지 클라이언트는 동일 서버에 접속) 

 2) OS 타입

 - OS가 가지고 있는 자체 기능(서비스)으로 부하분산 구현. -

 - Windows Server 2008 의 NLB(Network Load Balancing),리눅스 LVS(Linux Virtual Server)

 - 클러스터 서비스의 부속 기능으로 복잡한 부하분산 구현은 어렵고, 적은 비용으로 부하분산 기능 구현 가능.

 - 모드에 상관 없이 서버와도 통신을 하므로 비효율적이지만 작은 규모 사이트에서 사용하기에는 문제 없음.

 3) 어플라이언스 타입

 - 부하분산 장치(로드밸런서)라는 부하분산 전용 장비를 사용해서 구현.

 - F5 Networks의 BIG-IP, Citrix의 NetScale, Cisco의 ACE 4700 시리즈 등

 - 클라이언트로부터 오는 모든 트래픽을 일단 부하분산 장비에 저장해둔 후 그것을 배후에 있는 서버로 흘려 보냄. 

 - 전달받은 연결을 호율화한다거나 암호화된 연결을 복호화하는 기능도 있음.

4. 고급 서버 부하분산 

 1) 회선 부하분산

 - 복수의 인터넷 회선을 전부 사용하고 싶을 때 적용 가능한 기술.

  a. A사 B사, 두 개의 인터넷 회선이 있을 때 라우터와 방화벽만으로 구성하면 Active-Standby 구성만 가능.

  PBR이나 MVRRP(Multiple Virtual Router Redundancy Protocol)와 같은 기술을 사용함으로써 Active-Active 구성이 가능하나 확장성의 문제나 운용 복잡성이 있음.

  b. 라우터 앞단에 부하분산 장비를 둠으로써 양쪽 회선에 트래픽을 분배, 양쪽 인터넷 회선을 Active-Active로 사용.

 2) 광역 부하분산

 - 물리적으로 다른 장소에 있는 서버를 부하분산하는 기술.

 - 부하분산 장치가 DNS  서버가 되어 각 사이트의 상태를 감시하고, 그 결과를 기반으로 IP주소를 변경하여 부하분산. 최근에는 부하분산 기술이라기보다 DR(Disaster Recovery) 목적으로 사용하는 경우가 많아지고 있음.

Volume

I. RAID-DP

- Double parity disks / data disk

- Raid disk type : data / parity / dparity / spare

- degraded mode : no spare disk

- Max raid group : 400 per storage

- Raid group sizing for RAID-DP groups

- RAID group size는 12 ~ 20 recommended
- 쓰기 성능은 Raid-group이 큰게 작은 것 보다 빠름.

- RAID group을 작게하면 짧은 reconstruction 시간, Multiple disk failure 가능성 감소.

* raid group size 조정

 => >aggr options <aggr_name> raidsize 16

 * raid level scrubbing

 => disk block checking, media error, parity inconsistency 수정

 => disk scrub start

* spare disk가 없는 상태에서 disk fail 되면 raid.timeout 설정값에 따라 shutdown 됨 (default = 24h)

 options.raid

II. Aggregation / Volume

       Aggregation /Volume 구조

 1. Root Volume

  - System 당 한 개의 root volume을 가짐

  - Boot volume, /etc directory에 위치

  - 다른 volume으로 변경 가능, vol options [vol_name] root , /etc directory copy

  - Path (Virtual root volume) - /vol

  - root volume 이 결정하는 인자 - 모든 volume의 default language 값

 2. Volume 및 Aggregate Names

  - trad volume or aggregate naming conventions : 문자,숫자,'_' , 255자 이내

 III. Volume Management

  - Volume

  OnTAP에서 지원하는 프로토콜을 통해 유저에게 파일 액세스를 제공하는 data를 포함하는 파일시 스템을 이루는 단위

  1. Trad vol

   - dedicated aggr를 가지는 volume

   - 온라인 확장, 용량 확장은 오직 디스크 추가를 통해 가능.

   2. Flex vol

   - 같은 aggr안에 위치하는 flex vol은 aggr을 공유

   - 온라인 상태에서 확장 및 축소 가능

   - 최소 20MB, 4KB 단위로 증가

   - volume이 생성되면 aggr 사이즈의 0.5%를 reserve volume 의 meta 정보 저장.

   3. volume setting attribute

   - volume name, size, security style, cifs oplock사용 여부, volume language, space guarantee, file limit(quota),

      snapshot schedule, snaplock

   - root volume 여부

   - volume language: volume이 포함하는 데이터와 파일 이름을 표사히는 character set을 결정.

   - Space guarantee? 

  https://library.netapp.com/ecmdocs/ECMM1278323/html/smg/provisioning/concept/c_oc_prov_spc-guar.html

   1) flexvol과 reserve file의 사용된 영역에 snapshot 백업 후 overwrite를 실행할 경우 공간부족으로 인해 write가 실

       패하지 않도록 보장

   2) volume: aggr 안에 생성된 vol에 할당된 공간은 다른 vol을 위한 영역으로 사용될 수 없음.

   3) file / none

   4) Guarantee가 설정되어있다 하더라도 vol이 offline 되면 그 vol 안에서 unused 된 공간은 다른 vol에서 사용가능

       한 영역

   - Fractional_reserve? Volume % 조절

   https://library.netapp.com/ecmdocs/ECMM1278323/html/smg/provisioning/concept/c_oc_prov_spc-frct-rsrv.html

   1) Reservation 설정을 했다면 reserved size를 줄일 수 있음 : vol options ~

   2) Vol에만 적용되는 기능

   3) File reserve 했다면 default reserve 값은 100%가 됨.

   4) Qtree snapmirror를 실행하는 경우, fractional reserve 를 0으로 적용.

    > vol options vol_name fractional_reserve pct

   - volume language 변경

    vol data 영향으로 vol language 변경 시 시스템 리부팅 필요

    vol lang 변경하면 파일에 대해 nfs access 가능한지 체크하기 위해 WAFL_check 를 실행여부 결정.

   - cifs oplocks

    http://netapplines.blogspot.kr/2013/06/cifs-oplocks-opportunistic-locks.html

   - volume, qtree security style

   1) ntfs: 파일 security가 ntfs acl에 의해서 결정되며 nfs 유저는 지정된 windows sid 값에 의해 결정.

   2) unix: 파일과 디렉토리 acl이 unix permission 에 의해 결정.

   3) mixed: 파일과 디렉토리 security style은 가장 최근 permission을 설정한 방식에 의해 결정.

I. 기본 제공 소프트웨어

 1. SnapShot : 어플리케이션 서비스 중에 성능 저하없이 즉각적으로 Point in Time Image 백업을 제공하는 논리적 데이터 보호 소프트웨어.

 2. SyncMirror : RAID1과 RAID-DP 이상의 안정성을 제공하는 데이터 보호 소프트웨어.

 3. FlexVol : 볼륨을 하드웨어와 독립적으로 구성하여 논리적 레벨에서 데이터를 관리하게 하여 씬 프로비저닝을 구현하게 하는 데이터 관리 개선 소프트웨어.

 4. RAID-DP : 단일 RAID 그룹내에서 동시에 두 개의 데이터 디스크 장애 시에도 계속적인 서비스를 제공하며, RAID1이상의 안정성과 스토리지 사용량을 제공한는 데이터 보호 기술.

 5. FlexView : 기본적으로 넷앱의 스토리지를 관리,모니터링하는 웹 브라우저 기반의 툴.

 6. FlexShare : 스토리지내에 중요업무의 우선순위에 따라 해당 볼륨의 대기 응답 시간을 최소화 시키는 QoS.

 7. Deduplication : 저장되는 데이터의 중복된 블록을 제거하여 더 작은 공간에 더 많은 데이터를 저장할 수 있는 스토리지 공간 절약 효율화 소프트웨어.

II. 스토리지 소프트웨어(유상)

 1. Data Motion : 클라이언트 어플리케이션의 영향 없이 스토리지 인프라 스트럭쳐내에서 데이터를 자유롭게 이동할 수 있는 Shared Storage를 위한 Data Mobility 소프트웨어로 SnapMirror, MultiStore, Provisioning Manager로 통합된 소프트웨어.

 2. FlexCache : 스토리지 및 어플리케이션 성능 가속 솔루션으로 WAN 구간 사이의 응답 시간 지연 감소, 총 IOPS증가, 성능 병목 현상 제거가 가능한 성능 가속 소프트웨어.

 3. FlexClone : 스토리지 공간 추가없이 여러 개의 데이터셋을 즉각적으로 복제할 수 있어 어플리케이션 테스트 및 개발 환경에 매우 효과적인 Time to Market 개선 소프트웨어.

 4. MultiStore : 단일 스토리지 네트워크와 스토리지 자원을 논리적으로 분할하여 분할된 가상 스토리지간의 데이터 공유과 접근을 통제할 수 있는 Multi Domain & Multi Tenancy 소프트웨어.

III. 데이터 보호 소프트웨어 - 백업,복구

 1. Open Systems SnapVault : 이기종 스토리지 서버 데이터 보호 솔루션으로 Non-NetApp 스토리지 환경에서 Windows, Unix, Linux 등 Open Base 환경의 데이터를 넵앱의 백업스토리지로 백업하는 소프트웨어.

 2. SnapRestore : 전체 볼륨, 개별 파일 및 LUN을 이전 SnapShot으로 즉각적으로 복구하는 솔루션으로 용량에 관계없이 전체 볼륨을 1초 이내에 복구 가능한 최대 가용성을 제공하는 소프트웨어.

 3. SnapVault : 넷앱 D2D 백업 전용 소프트웨어로 최초 Initial Full 백업을 만든 후 영구적인 증분 백업이 가능하며 증분 백업만을 진행하더라도 full 백업 이미지 저장본을 가져가는 스토리지 공간 효율적인 버전관리 D2D 백업 소프트웨어

 4. MetroCluster : 최소의 비용으로 CDP 수준의 재해복구 인프라를 구축할 수 있는 넷앱읠 재해복구 솔루션.

 5. SnapMirror : 디스크 기반의 재해복구 솔루션으로 SnapShot 기술을 이용 넷앱 디스크에 저장된 데이터의 블록 단위로 복제 작업을 수행, FC,IP방식을 통해 데이터를 전송할 수 있어 큰 네트워크 대역폭이 필요하지 않은 복제 솔루션

Snapshot : Point in time copy

I. 운영

- Volume 영역에서 20%차지(default)

- 동일 볼륨에 대해 최대 255개의 snapshot 지원

- schedule & manual 백업 실행

II. 동작

그림1

그림2

III. Snapshot command

- snap list [-A | -V] [-n]  [[-q] [<vol-name>] | -o [<qtree-path>]]

- snap create [-A | -V] <vol-name> <name>

- snap delete [-A | -V] <vol-name> <snapshot-name> |

- snap delete [-A | -V] -a [-f] [-q]  <vol-name>

- snap delta [-A | -V] <vol-name> <old-snapshot-name> <new-snapshot-name>

- snap sched

- snap reserve [-A | -V] [<vol-name> [percent]]

- snap restore [-A | -V] [-f] [-t vol] | file] [-s <snapshot-name>] | [-r <restore-as-path>] <vol-name> | < restore-from-path>

IV. Snapshot schedule

- snap sched <vol_name> weekly nightly hourly@시간

ex) snap sched vol1 2 6 8@8,12,16,20

- snap list

 V. snapshot option

- client access to snapshot 설정:  #vol options <vol_name> snapdir [on|off]

- automatic snapshot 설정: #vol options <vol_name> nosnap [on|off]

- Snapshot (Flex Volume)

- Snapshot (Aggregate)