리눅스 커널 튜닝가능한 파라메터 vm.swappiness (/proc/sys/vm/swappiness) 는 어떻게 메모리 페이지들이(memory pages) 적극적으로 디스크에 스왑(swap)되어질 수 있는지를 정의하는데 사용되어질 수 있습니다. 리눅스는 활용할 수 있는 free 메모리양이 충분하더라도 오랫동안 메모리 페이지에 접근하지 않는 것들을 스왑 공간으로 이동시킵니다. 이러한 동작은 “swappiness” 커널 파라메터 값을 /proc/sys/vm/swappiness 에서 변경할 수 있습니다.
높은 swappiness 값은 커널은 매핑된 페이지를 좀 더 해제하라는 의미 입니다. 낮은 swappiness 값은 반대의 의미로 커널은 매핑된 페이지를 덜 해제하도록 하라는 의미 입니다. 바꿔말해서, vm.swappiness 값이 높을 수록 시스템은 좀 더 많이 스왑을 할 것입니다.
vm.swappiness 는 스와핑 활동과 freeing 캐쉬사이의 균형을 바꾸기 위해서 0 에서 100 사이의 값을 가집니다. 100 은 커널이 항상 비활성 페이지를 찾게되고 그것들을 스왑 합니다. 다른 말로, 스왑의 발생은 애플리케이션이 메모리를 얼마나 많이 사용하는지, 어떻게 부족한 캐쉬가 찾기 활동을하고 비활성 아이템을 릴리즈하는가에 의존합니다.
Shell
1
2
echo0>/proc/sys/vm/swappiness
cat/proc/sys/vm/swappiness
일반적으로 프로세스들은 함수 malloc() 를 호출함으로서 메모리를 할당 합니다. 커널은 충분한 메모리가 활용가능한지 판단하고 할당요청을 허용하거나 거부할지를 결정합니다. 리눅스는 메모리 오버커밋(overcommit memory) 할 수 있는 기능을 지원 합니다. 그것은 물리적 램과 스왑을 합쳐 더 많은 메모리를 할당되어질 수 있도록 허용하는 것 입니다. 이것은 무섭지만, 때때로 애플리케이션이 최악의 케이스 시나리오로 메모리를 할당하는 경우에 필요하지만 절대로 이러한 케이스를 사용해서는 안됩니다. (애플리케이션이 메모리를 많이 잡아먹도록 만들지 말라는 이야기 입니다.)
vm.overcommit_memory 는 3가지 가능한 세팅 값이 있습니다.
0 (heuristic overcommit) : 충분한 메모리가 활용가능하지 체크하고, 만약 그렇다면, 할당을 허용한다. 만약 메모리가 충분하지 않다면, 요청을 거부하거나 애플리케이션에 에러를 리턴한다.
1 (always overcommit) : 커널은 “모든 돈을 걸어라”는 것과 같다. 1로 세팅하는 것은 커널에게 애플리케이션의 메모리에 대한 요청을 항상 성공으로 리턴하라고 명령하는 것이다. 이것은 듣기에따라서 섬뜩하고 무서운 것이다.
2 (strict covercommit) : 메모리에 물리적 메모리와 스왑을 합쳐 초과 할당을 vm.overcommit_ratio 에 정의되어진 것만큼 할당하도록 허용하라. vm.overcommit_ratio 파라메터는 비율로서 얼마나 커널이 오버커밋을 할 수 있는지를 결정할때에 추가할 메모리의 양이다. 예를들어, vm.overcommit_ratio 가 50 이고 1GB 의 램을 가지고 있따면 커널은 요청이 실페하기전에 0.5GB 의 물리메모리와 스왑을 더해서 할당되어질 수 있도록 허용하게 된다. 결국 물리메모리를 낭비하게 된다.
프로세스가 포크(fork)될때나 fork()함수를 호출할때, 이것은 전체 페이지 테이블(page table)이 복제된다. 다른 말로하면, 작식 프로세스는 완벽하게 부모의 메모리공간의 복사본을 가진다는 것이며 이는 당신이 예상한대로 두배의 메모리양을 필요로한다. (부모 메모리, 자식 메모리) 만약 그 자식들의 의도가 즉각적으로 exec()를 호출하는 것이라면( 하나의 프로세스가 다른것으로 교체되는) 부모의 메모리를 복제하는 활동은 시간을 낭비한다. 왜냐하면 이러한 패턴은 아주 일반적인것으로, fork()와 달리 vfork()로 생성은 부모 메모리를 복제하지 않으며 대신에 자식 프로세스가 exec() 를 호출하거나 사라질때까지 그것을 블럭킹한다. The problem is that the HotSpot JVM developers implemented Java’s fork operation using fork() rather than vfork()
CentOS 7 배포판은 RHEL 7 을 재컴파일해서 만들어진 배포판 입니다. 이전 버전과 달리 서비스 데몬 관리로 Systemd 를 채용했고 기본 파일 시스템으로 XFS 를 채용하는등 많은 변화를 겪었습니다.
CentOS 7 에 서버 프로그램을 설치하게 될 경우에 이 Systemd 와 결합을 시키는 것도 중요한 일로 떠올랐습니다. Systemd 는 단순하게 서비스 데몬을 관리하는 것뿐만 아니라 시스템의 전반적인 인프라자체이므로 매우 중요한 요소가 되었습니다.
이 문서에 Apache 2.4.10 은 바로 Systemd 와 통합하는 방법을 포함 합니다. 이 문서의 내용은 Fedora 22 배포판을 많이 채용한 것입니다.
2. Apache 2.4.10
2.4.10 버전에서는 이전과 달리 기본 MPM으로 Event 입니다. 별도로 MPM을 지정해주지 않으면 Event 로 지정되었습니다. 하지만, 이 기본 Event 가 라이브러리 의존성을 가지고 있기 때문에 라이브러리가 갖추어지지 않았다면 Prefork 와 Worker 가 공유라이브러리로 컴파일되고 설치 이후에 무엇을 쓸것인지를 지정해줘야 합니다.
2.4.10 버전의 경우에 Event 를 활성화하기 위해서는 Apr, Apr-utils 의 버전이 1.5 이상이여 합니다. 하지만 CentOS 7 배포판에서는 현재 1.4 버전임으로 컴파일 설치할때에 1.5 이상을 같이 컴파일 해줘야 합니다.
3. Download and Unpack
Apache 2.4.10 을 Event 로 동작하도록 컴파일 하기위해서 다운로드 합니다.
Httpd-2.4.10
Apr-1.5.1
Apr-utils-1.5.4
다운로드한 후에 압축을 해제하고 apr, apr-utils 는 srclib 디렉토리에 압축을 해제하고 버전을 제거한 패키지 이름으로 변경해 줍니다.
Apache 2.4.10, Apr-.1.5.1, Apr-Util-1.5.4 Unpack
Shell
1
2
3
4
5
6
7
8
9
10
11
12
13
14
# httpd-2.4.10 압축해제
tar xjf httpd-2.4.10.tar.bz2
# apr-1.5.1, apr-util-1.5.4 이동.
mvapr-*httpd-2.4.10/srclib/
# 디렉토리 변경
cdhttpd-2.4.10/srclib
# 압축해제
tar xjf apr-1.5.1.tar.bz2
tar xjf apr-util-1.5.4.tar.bz2
# 디렉토리 이름 변경
mvapr-1.5.1apr
mvapr-util-1.5.4apr-util
# httpd-2.4.10 디렉토리로 이동
mv../
4. Patch Download and Patch
이 패치는 Fedora 22 에 httpd-.2.4.10 패키지에 있는 것을 가지고 온 것 입니다. 여기에는 보안 패치와 더불어 Systemd 와 통합되는 모듈이 들어있습니다.
9월2719:55:20localhost.localdomainhttpd[18166]:AH00558:httpd:Could notreliably determine the server's fully qualified domain name, using localhost.localdomain. Set the 'ServerName'dir...thismessage
9월2719:55:20localhost.localdomainsystemd[1]:Started The Apache HTTP Server.
Hint:Some lines were ellipsized,use-ltoshow infull.
Python 3 설치. 현재 Python 2.x 버전이 2019년까지 수면을 연장했지만 이미 많은 모듈들이 2.x 버전에서 개발이 중단되거나 Python 3.x 를 지원하기 시작했다. 앞으로는 Python 2.x 를 개발하더라도 Python 3.x 와 호환을 고려해서 작성해야 한다.
KVM은 리눅스 커널 기반의 가상화 시스템이다. KVM 을 이용하면 네트워크도 가상화를 해주는데, 이는 KVM 의 네트워크 가상화는 Bridege 네트워크를 이용하도록 되어 있다.
Figure1. 가상화된 네트워킹 인프라.(Ibm develop works 참조)
위 그림은 KVM 하이퍼바이저의 가상 네트워킹을 보여준다. 네트워크 가상화를 하이퍼바이저내에서 이루어지다보니 가상 시스템을 모아놓은 상태에서 전체 네트워킹을 설정하고 변경하기가 쉽지가 않게 된다. 가상 네트워킹을 관리하기 좀 더 쉽게 하이퍼바이저내에서 빼내서 가상 네트워킹을 가능하도록 한다면 어떨까. OpenvSwitch 가 이것을 가능하게 해준다.
1. 환경.
CentOS 7 의 KVM 환경이다. OpenvSwitch 는 2.0 버전이며 이는 OpenStack IceHouse 패키지 저장소에 있는 것을 이용했다.
플랫폼 가상화의 폭발적인 성장과 함께, 기업 생태계의 다른 부분이 가상화되고 있다는 건 놀라운 일이 아니다. 아주 최근에 영역은 가상 네트워킹(virtual networking) 이다. 플랫폼 가상화의 초기 구현은 가상 NIC 생성지만 오늘날에는 네트워크의 큰 부분들이 가상화되어지고 있는데, 서버의 VM 간에 통신을 지원하거나 서버간의 분산된 스위치같은 것들이다. 가상 네트워킹의 배경이되는, NIC 및 스위치 가상화에 초점을 맞춰, 아이디어를 설명한다.
Computing today is undergoing something of a revival. 비록 가상화가 수십년전에 만들어졌지만, 실질적인 잠재력은 하드웨어 부품들을 통해서 이제야 현실화되어지고 있다. 가상화 통합은 서버를 효율적으로 부하를 처리하도록 하지만 서버 생태계의 다른 요소들이 좀 더 통합을 위한 후보들로 떠오르고 있다. CPU, Memory, Storage 통합과 같은 다양한 측면의 가상화가 있지만 이는 솔루션을 단순화시켜준다. 네트워크는 가상화의 열쇠이며 가상화 셋(set)에서 최고 등급의 요소이다.
Virtualizing networks
고차원의 문제를 설명하는 것으로 시작해보자. 그리고 나서 리눅스 빌드(build) 와 네트워크 가상화를 지원하는 다양한 방법에 대해서 알아본다.
전통적인 환경에서, 물리적인 서버 셋(set)은 필요한 애플리케이션 셋(set) 을 호스트 한다. 서버들간에 통신을 활성화 하기위해서, 각 서버는 외부 네트워킹 인프라와 연결된 하나 혹은 그 이상의 네트워크 인터페이스 카드(NIC) 를 가지고 있어야 한다. NIC는, 네트워킹 소프트웨어 스택을 따르는, 네트워크 인프라를 통해 끝 지점(endpoint) 사이에 통신을 가능하게 해준다. Figure 1 에서 , 이러한 기능들은 스위치에 의해서 구현되어진, 스위치에 연결된 끝 지점 사이에 효과적인 패킷 통신을 가능하다는 걸 보여준다.
Figure1. 전통적인 네트워킹 인프라
서버 통합 이면의 핵심적인 혁신은 다양한 운영 시스템을 허용하는 물리적 하드웨어 추상화와 하드웨어를 공유하는 애플리케이션들이다. (Figure 2를 보라). 이러한 혁신을 하이퍼바이저(hypervisor) 혹은 가상 머신 모니터(virtual machine [VM] monitor) 라고 부른다. 각각의 VM(운영체제 시스템과 애플리케이션 셋)은 기초적인 하드웨어를 공유하지 않는 것처럼, 그것이 존재하지 않거나 다수의 VM 에 의해서 공유되어질지라도, 마치 완전한 머신으로 보인다. 대표적인 예가 가상 NIC(vNIC) 이다. 하이퍼바이저는 하나 혹은 그 이상의 vNIC 를 각 VM 에 생성한다. 이러한 NIC 들은 VM에 마치 물리적인 NIC 처럼 나타지만 실제로는 오직 NIC 인터페이스로 제공된다. 또, 하이퍼바이저는 가상 네트워크의 동적인 구조를 허용하는데, VM 끝지점 사이의 구성가능한 통신을 할 수있도록 스위치를 가상화하도록 해준다. 끝으로, 하이퍼바이저의 논리적 인프라에 서버의 물리적인 NIC 를 붙임으로써, 외부네트워크과 효율적인 통신이 잘되는 것처럼 하이퍼바이저 안에 VM 사이에 효율적인 통신을 허용하는것처럼, 물리적인 네트워킹 인프라와 통신하는것을 허용합니다.
Figure2. 가상화된 네트워킹 인프라
가상회된 네트워크는 다른 흥미로운 혁신 또한 가능하도록하는데, 가상 기기(Virtual Appliance) 같은 것이다. 우리는 이러한 추가적인 가상 네트워크의 요소들을 살펴볼 것이다.
Virtual switching
가상화된 네트워킹 인프라 개발의 핵심중에 하나는 가상 스위치 개발이다. 가상 스위치는 서버의 물리적인 NIC 에 vNIC 를 붙이고 더 중요하게는 지역적 통신을 위해서 서버안에 vNIC 와 다른 vNIC 를 묶어준다. 이것이 흥미로운 점은, 네트워크 스피드로 할 수 있는 것을 대신해, 메모리 대역폭, 로컬 VM 사이에 효율적인 통신을 허용하고 네트워크 인프라의 오버헤드를 최소화하는 가상 스위치를 갖는다는데 있다. 이것은 물리적인 네트워크는 서버사이에 통신만을 위해서 사용되어지고 내부 VM 트래픽을 서버사이에 통신 트래픽과 분리하는 결과를 갖게 한다.
하지만, 리눅스에서는 이미 커널내에 레이어-2 스위치가 내장되어 있지만 왜 가상 스위치가 필요한지 종종 묻곤 한다. 이에 대한 대답은 다양한 속성들을 포함하지만 가장 중요한 것중에 하나는 이러한 스위치 타입에 대한 새로운 주제에 의해서 정해진다. 그 새로운 주제를 분산된 가상 스위치(distributed virtual switch) 로 기본 서버 아키텍쳐를 투명하게 해주는 방법으로 서버간 브리징(cross-server bridge)을 할수 있게 해준다. 서버내의 가상 스위치는 다른 서버의 가상 스위치를 투명하게 연결 시킬 수 있고 (Figure 3 을 보라) 아주 간단하게 서버들과 그들의 가상 인터페이스 사이에 VM 의 이동을 만들어주기 때문에 다른 서버에 분산된 가상 스위치를 붙일 수 있고 투명하게 가상 스위치된 네트워크와 연결된다.
Figure3. 분산된 가상 스위치.
이 세계에서 가장 중요한 프로젝트중에 하나가 바로 다음에 설명할 Open vSwitch 이다.
서버내에 격리된 로컬 트래픽이 가지는 이슈중에 하나는 그러한 트래픽은 외부적으로 볼 수 없다는 것이다. (예를들면, 네트워크 분석가들에게) Implementations have addressed this problem through a variety of schemes, such as OpenFlow, NetFlow, and sFlow, which are used to export remote access to control and monitor traffic. (내용상, 이러한 문제, 그러니까 외부에서 트래픽을 분석할 수 없는 문제를 해결하기 위한 다양한 스킴들이 존재하는데 OpenFlow, NetFlwo, sFlow 들이 그런것이고 이들은 트래픽을 모니터하고 외부 접속을 제어할 수 있도록 해준다 것인듯 하다.)
Open vSwitch
초기의 분산된 가상 스위치들은 패쇄적이고 상용 하이퍼바이저 운영에는 제한적이였다. 하지만 오늘날과 같은 클라우드 환경에서, 이것은 다양한 하이퍼바이저가 공존하는 이기종 환경을 지원하는 이상적인 방법이다. (말이 이상하다..;; 원문: But in today’s cloud environments, it’s ideal to support a heterogeneous environment in which multiple hypervisors can coexist.)
Open vSwitch 는 아파치 2.0 라이센스하에 활용할 수 있는 다중레이어 가상 스위치이다. 2010년 5월즘, Open vSwitch 는 1.0.1 버전으로 활용할 수 있었고 인상적인 기능들을 지원했다. Open vSwitch는 , 커널 기반 VM(KVM), VirtualBox, Xen, 그리고 XenServer들과 같은 오픈 소스 하이퍼바이저 솔루션들의 가장 중요한 부분을 지원했다. 이것은 현재 리눅스 브릿지 모듈을 대체하고 있다.
Open vSwitch 는 스위치 데몬과 흐림기반 스위칭(flow-based switching) 제어를 위한 커널 모듈듈로 구성된다. 다양한 다른 데몬들과 유틸리티 또한 스위치 관리를 위해서 존재한다. 당신은 유저 공간에서 전체적으로 Open vSwitch 를 실행할 수 있지만, 성능 저하를 초래할 수 있다.
VM 환경에서 production-quality 를 추가하기 위해서, Open vSwitch 는 상용 솔루션과 다른 비슷한 것과 경쟁하기 위해서 굉장한 기능 개발 로드 맵을 포함한다.
Network device virtualization
NIC 하드웨어 가상화는 가상 스위칭이 소개되기 이전부터 다양한 형태로, 때때로 존재해 왔다. 이 섹션은 네트워크 가상화의 속도를 개선하기위해 활용할 수 있는 몇몇의 하드웨어 가속으로 알려지는 것들을 살펴볼 것이다.
QEMU
비록 QEMU 가 플랫폼 에뮬레이터이지만, NIC를 포함한 다양한 하드웨어 장치에 대해 소프트웨어 에뮬레이션을 제공한다. 추가적으로, QEMU 는 IP 주소 할당을 위해서 동적 호스트 설정 프로토콜 서버를 제공한다. QEMU 는 KVM 기반 가상화에 대해 플랫폼을 제공하기 위해서 플랫폼 에뮬레이터와 개발 장치 에뮬레이터가 KVM과 함께 동작한다.
virtio
virtio는 VM 으로부터 하이퍼바이저에 I/O 트래픽을 신속히 처리하고 단순화하기 위한 리눅스의 Input/Output(I/O) 반 가상화(para-virtualization) 프레임워크이다. virtio 는 PCI 디바이스, 네트워크 디바이스, 기타등등 블록 디바이스를 가상화할 목적으로 VM과 하이퍼바이저 사이에 I/O에 대한 표준화된 전송 메커니즘을 생성한다.
TAP and TUN
가상화는 꽤 많은 시간동안 호스트 네트워킹 스택에 VM 게스트 네트워킹 스택 액세스를 허용하는 네트워크 스택을 구현해 왔다. 두개의 전략은 TAP 과 TUN 이다. TAP은 이데넷 디바이스를 구현한 가상 네트워크 커널 드라이버이며 이더넷 프레임 레벨에서 운영되어진다. TAP 드라이버는 게스트 이더넷 프레임이 전달 될 수 있는 이더넷 “tap” 을 제공한다. TUN(혹은 네트워크 터널링)은 네트워크 레이어 디바이스를 시뮬레이트하고 IP 패킷의 더 높은 수준의 통신, 최적화를 제공하고 기본적인 이더넷 디바이스가 TUN 의 IP 패킷의 레이어-2 프레이밍을 관리할 수 있도록하는 것등을 한다.
I/O virtualization
I/O 가상화는 하드웨어 수준에서 가상화 가속을 가능하게하는 PCI-Special Interest Group (SIG)의 표준화된 전략이다. 특히, 단일 루트 IOV (SR-IOV)는 단일 PCI Express (PCIe) 카드를 통한 인터페이스가 많은 사용자에게 마치 다중 PCIe 카드처럼 보일 수 있도록하고 다중 독립적인 드라이버가 별도의 지식이 없이 PCIe 카드를 붙이는 것을 허용하는 인터페이스를 나타낸다. SR-IOV 는 가상 기능들을, PCIe 공간의 물리적인 기능처럼 나타나지만 공유 기능으로 카드 내부에 표시되는, 다양한 사용자에게 확장하여 이러한 것을 수행한다.
SR-IOV 가 네트워크 가상화에 가져다 주는 이점은 성능이다. 하이퍼바이져가 물리적 NIC 공유를 구현하는 것보다도 카드 자체적으로 멀티플렉싱을 구현하고 게스트 VM 으로부터 직접적으로 카드에 직접적으로 I/O를 전달하는 것을 허용하는 것이 성능상 이점이 있다.
오늘날 리눅스는 KVM 하이퍼바이저의 이점인 SR-IOV 지원을 포함한다. Xen 또한 SR-IOV 를 지원을 포함하는데, vNIC 를 게스트 VM들에 제공하는 것을 효율적으로 허용한다. SR-IOV 에대한 지원은 Open vSwitch 의 로드 맵에 있다.
Virtual LANs
비록 상대적이긴 하지만, 가상 랜(VLAN)은 네트워크 가상화에 대한 물리적인 방법이다. 동일한 브로드 캐스트 도메인의 일부인 것처럼 (독립된 네트워크)에 서로 다른 호스트가 나타나도록 VLAN은 분산 네트워크를 통해 가상 네트워크를 생성 할 수있는 기능을 제공한다. VLANs 은 그들이 속한 특정한 LAN을 식별하기 위한 VLAN 정보를 가진 프레임을 태깅(tagging)함으로써 이러한것을 수행한다. 호스트는 물리적인 네트워크를 가상화하기 위해서 VLAN 스위치와 협업한다. 하지만, 비록 VLAN 인 분리 네트워크의 가상을 제공하지만, 그들은 같은 네트워크를 공유하고 따라서 같은 대역폭을 활용하고 혼잡으로 인한 충격도 공유한다.
Hardware acceleration
수 많은 I/O에 초점이되는 가상화 가속은 NIC 와 다른 디바이스를 연결하는식으로 나타나기 시작했다. 직접적인 I/O(VT-d)를 위한 Intel® 의 가상화 기술은 신뢰성과 보안성을 향상을 위한, 직접 메모리 접근 전송 재매핑을 포함하고 device-associated 인터럽트 리매핑, 미수정된 게스트들과 virtualization-aware 를 지원, I/O 리소스를 격리시키는 능력을 제공한다. 인텔 가상머신 디바이스 큐(VMDq) 는 내장된 큐에 의해서, 하드웨어 내애서 지능적으로 정렬하는, 가상화 세팅에서 네트워크 트래픽 흐름을 가속화해주는데 하이퍼바이져에 의한 CPU 사용을 적게해주며 전체 시스템 성능을 크게 개선해준다. 리눅스는 이 둘을 모두 지원한다.
Network virtual appliances
지금까지 NIC 디바이스와 스위치 가상화에 대해서 몇몇 존재하는 구현체들과 이러한 가상화들이 하드웨어를 통해서 가속화될 수 있는지에 대한 방법들에 대해서 설명했다. 이제 일반적인 네트워크 서비스들에 이러한 논의를 확장해보자.
가상화 분야에서 흥미로운 혁신중에 하나는 서버 통합으로 발생된 ecosystem 이다. 애플리케이션이 하드웨어 버전에 특화되기위해 노력하는 것보다, 서버 부분은 서버 내에서 서비스드를 확장하는 VM 들의 힘을 분리했다. 이러한 VM 들을 virtual appliances 라고 부르는데, 그들은 가상화 세팅에 대해서 개발하고 특화된 애플리케이션에 초점을 마춘다.
virtual appliance 는 일반적으로 특정한 서비스를 확장하는 하이퍼바이저에 연결되거나 하이퍼바이저가 제공하는 일반적인 네트워킹 인프라에 연결된다. 이것을 특별하게 만드는 것은 프로세싱 처리와 I/O 대역폭 부분은 virtual appliance 에서 동적으로 설정가능하다는 것이다. 이러한 기능은 좀 더 비용 효율적이고 서버내에서 동작중인 다른 애플리케이션의 요구에 기반하는 능력을 동적으로 변경할 수 있게 해준다. Virtual applicance 는 좀 더 관리를 단순화 해주는데, 애플리케이션이 운영 체제와 묶여있기 때문이다. 특별한 설정이 필요없고, VM 이 전체적으로 이미 설정되어져 있다. That’s a considerable benefit for virtual appliances and why they’re growing today.
Virtual appliances have been developed for many enterprise applications and include WAN optimization, routers, virtual private networks, firewalls, intrusion-protection/detection systems, e-mail classification and management, and more. Outside of network services, virtual appliances exist for storage, security, application frameworks, and content management.
