728x90
반응형

리눅스에서 특정 유저에 대해 OS 내부 보안정책에서 예외를 두고 싶을 때 필요한 방법이다.

순서가 중요함

 

특정계정 PAM 모듈에서 제외처리

 

[root@test ~]# cat /etc/pam.d/system-auth

#%PAM-1.0

# This file is auto-generated.

# User changes will be destroyed the next time authconfig is run.

auth        required      pam_env.so

auth [success=1 default=ignore] pam_succeed_if.so user in TESTUSER

 

 

[root@test ~]# cat /etc/pam.d/password-auth

#%PAM-1.0

# This file is auto-generated.

# User changes will be destroyed the next time authconfig is run.

auth        required      pam_env.so

auth [success=1 default=ignore] pam_succeed_if.so user in TESTUSER

 

728x90
300x250
728x90
반응형

DEV
개발/개발서버

TEST
일반적인 개발 후 단위 테스트 서버

SIT (System Integration Test )
흔히 말하는 통합 테스트
개발/기획/QA,QC 등이 진행
SIT 서버라고 한다.

UAT (User Acceptnace Test)
현업,사용자,운영자 테스트
검수 테스트라고 한다.
UAT 서버라고 한다

PAT (Production Acceptance Test)
운영 배포 후 Test
P.A.T 종료 언제까지냐고 의사 소통을 한다.

STG (Stage Server or Staging Server)

스테이지 서버라고도 함 / 게임업계에서는 베타서버라고도 함
운영환경과 거의 동일한 상태
운영서버 배포전 UAT 당시 진행되는 서버
운영서버와의 Sync는 주로 Infra요소보다는 데이터 정합성에 초점을 맞춘다.

PROD (Production)
제품출시 및 최종 EndUser가 사용하는 서버 즉 실 운영이 되는 서버, 운영서버

728x90
300x250
728x90
반응형

 

자빅스(zabbix) 공식 레파지토리 : http://repo.zabbix.com/zabbix/

자빅스 (zabbix) 한글 매뉴얼 : http://manual.oplab.co.kr

 

  1. epel 저장소 추가 (epel = Extra Package for Enterprise Linux -> 엔터프라이즈 리눅스를 위한 추카 패키지)
728x90
  1. 자빅스 구성요소 설치 ( Zabbix / DB(Maria DB) / Webb (Apache) / PHP )
    • yum -y install zabbix-server-mysql zabbix-web-mysql mysql mariadb-server httpd php
  2. DB 설정
    • systemctl start mariadb
    • systemctl enable mariadb
    • ps -ef | grep mysql
    • mysql_secure_installation --> 설치 절차 지문 읽어보고 확인 후 최종 완료
    • 로컬 로그인시 mysql -u root -p , 원격 로그인시 mysql -h 127.0.0.1 -p 3306 -u root -p
    • create database ZABBIXDB;
    • grant all privileges on ZABBIXDB.* to zabbix@localhost identified by 'password12';
    • flush privileges;
    • exit
  • DB에 자빅스 테이블 insert
    • cd /usr/share/doc/zabbix-server-mysql-3.2.11
    • gunzip create.sql.gz
    • mysql -u root -p ZABBIXDB < create.sql
  • 자빅스 DB정보 Configure
    • vi /etc/zabbix/zabbix_server.conf
    • 맨 아래 아랫값 적용
    • DBHost=localhost
    • DBName=ZABBIXDB
    • DBUser=zabbix
    • DBPassword=root
  • PHP 설정
    • vi /etc/php.ini
    • max_execution_time = 600  (30 → 600)
    • max_input_time = 600  (60 → 600)
    • memory_limit = 256M  (128M → 256M)
    • post_max_size = 32M  (8M → 32M)
    • upload_max_filesize = 16M  (2M → 16M)
    • date.timezone = Asia/Seoul  (앞에 ; 주석제거후 한국시간으로 설정)
  • 방화벽 확인
    • 80, 10050, 10051
  • 자빅스 서비스 & httpd 서비스 시작
    • systemctl start zabbix-server
    • systemctl enable zabbix-server
    • systemctl start httpd
    • systemctl enable httpd
    • ps -ef | grep zabbix, httpd
  • 자빅스 GUI 
  • 기본 접속 정보 admin / zabbix
  • 자빅스 service 확인
    • systemctl status zabbix-server.service
    • systemctl status mariadb
    • systemctl status httpd
  • 웹페이지 접근 안될 때 방화벽 살펴보기
  • Zabbix 서버 가동중이 아니오 일 때, 로그 확인
  • 로그 위치 /var/log/zabbix/zabbix*
    • DB소켓에러 났을 때 소켓 위치를 zabbix config에 DBSocket 지정후 해당 소켓 위치 설정

 

아래에 Zabbix 5.0 버전으로 새로 발행한 글이 있습니다.

참조 해주세요

2022.01.17 - [IT/Zabbix] - (최신) Amazon Linux 2 Zabbix Server 5.0 설치

 

 

 

 

 

728x90
300x250

'IT > Zabbix' 카테고리의 다른 글

Zabbix agent on Windows Server  (0) 2021.08.17
Zabbix 감시 설정  (0) 2021.07.29
Zabbix Template 설정  (0) 2021.07.29
Zabbix Agent 설치  (0) 2021.07.29
Zabbix 서버에 대해  (0) 2021.07.29
728x90
반응형

1. 링크 up 되는 디바이스 확인

[root@rhel6-test ~]# ethtool eth0 | grep Link

        Link detected: yes
[root@rhel6-test ~]# ethtool eth1 | grep Link
        Link detected: yes
[root@rhel6-test ~]# ethtool eth2 | grep Link
        Link detected: no  

 

확인결과 eth0, eth1 디바이스가 링크 UP되어있다. 

 

2. bonding 디바이스설정

- bond0(본딩마스터)
[root@rhel6-test ~]# vi /etc/sysconfig/network-scripts/ifcfg-bond0
DEVICE=bond0
BOOTPROTO=none
IPADDR=192.168.0.65
NETMASK=255.255.255.0
GATEWAY=192.168.0.1
ONBOOT=yes
BONDING_OPTS="mode=1 miimon=100"
TYPE=BOND
USERCTL=no


- eth0,eth1 (본딩슬래이브)
[root@rhel6-test ~]# vi /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
BOOTPROTO=none
HWADDR=00:0c:29:4c:15:06
ONBOOT=yes
MASTER=bond0
SLAVE=yes
USERCTL= no
TYPE= Ethernet
[root@rhel6-test ~]# vi /etc/sysconfig/network-scripts/ifcfg-eth1
DEVICE=eth1
BOOTPROTO=none
HWADDR=00:0c:29:4c:15:10
ONBOOT=yes
MASTER=bond0
SLAVE=yes
USERCTL= no
TYPE= Ethernet  

 

3. NetworkManager 데몬 STOP
- 해당 데몬 살아있을시 bonding device 에러 (중요함)
[root@rhel6-test ~]# chkconfig NetworkManager off

 

4. network service 재시작
[root@rhel6-test ~]# service network restart

 

5.Bonding Interface 확인
[root@rhel6-test ~]#  cat /proc/net/bonding/bond0
Ethernet Channel Bonding Driver: v3.6.0 (September 26, 2009)
Bonding Mode: fault-tolerance (active-backup)
Primary Slave: None
Currently Active Slave: eth0
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 0
Down Delay (ms): 0
Slave Interface: eth0
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: 00:0c:29:4c:15:06
Slave queue ID: 0
Slave Interface: eth1
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: 00:0c:29:4c:15:10
Slave queue ID: 0 
[root@rhel6-test ~]# service NetworkManager stop

728x90
300x250
728x90
반응형

TPS(transaction per second)란 초당 완료된 트랜잭션의 수 다. 이것은 테스트에서 특정한 기간동안 몇번의 트랜잭션이 완료되었는지를 초당으로 계산된 값이라는 뜻이다.

예를 들어, 만약 뷰져(vuser/virtual user/가상 사용자)가 6번의 트랜잭션을 매 분마다 완료할 경우, TPS는 6 트랜잭션 / 60 초 = 0.1TPS 가 된다.

트랜잭션 개수 / 시간(초)을 지속적으로 계산하면 된다.

728x90
300x250
728x90
반응형


Windows NT부터 Windows 7에서 까지 ‘시스템 속성 > 성능 > 설정 > 성능 옵션 > 고급 > 프로세서 사용 계획’에 ‘프로그램’과 ‘백그라운드 서비스’ 옵션 두 가지 중 하나를 사용자가 선택할 수 있습니다. 이 두 개의 옵션에 대해서 여러 의견(?)들이 난무하는데요, 이번 포스팅에서는 이 두 가지 옵션이 어떤 의미를 가지는지 그리고 여러분은 어떤 상황에서 두 옵션 중 하나를 선택할 것인지를 설명 드릴까 합니다.

image

[그림 1. Windows 7, 프로세서 사용 계획]



 

잘못된 오해
 많은 분들께서 이 옵션에 대해서 아래와 같이 잘못 이해하고 계십니다.

{‘프로그램’은 실제 사용자가 실행하는 응용 프로그램이고 ‘백그라운드 서비스’는 ‘서비스 관리자(services.msc)’에서 실행되는 서비스를 의미한다. 그래서 프로세서 사용계획의 설정에 의해 ‘프로그램’을 선택하면 사용자 프로그램에 더 많은 CPU 사용량을 할당하고 ‘백그라운드 서비스’를 선택하면 서비스(Service)에 더 많은 CPU 사용량을 할당한다} => NO, NO, NO 이렇게 이해하고 계시면 안됩니다.




 

진실을 말씀 드리겠습니다.
 (이 옵션을 이해하기 위해서는 먼저 스레드와 컨텍스트 스위치 두가지 개념을 이해하셔야 합니다 그래서 이 단어의 정의를 설명드리면서 옵션을 이해하도록 하겠습니다)
우리가 사용하는 프로그램이란 것은 알고 보면 실행 파일이 프로세스(Process)로 만들어 진 후 스레드(Thread)에서 명령이 실행되는 것 입니다, 여기서 스레드란 명령어가 CPU를 사용하여 실행되는 단위로 정의 할 수 있습니다. (그밖에 많은 복잡한 이야기들이 있지만 여기서는 이정도 까지만 이해하시면 되겠습니다)

우리가 컴퓨터를 사용할 때 우리는 모르지만 네트워크 처리, HDD 처리, 커널에서의 작업, 응용프로그램 처리 등등 너무나도 많은 작업들이 동시 다발적으로 이뤄지고 있습니다. 다른 예로, 사용자가 인터넷에서 파일을 다운로드 하면서 Word와 WMP를 함께 사용하는 경우도 생각해 볼 수 있습니다. 이러한 것들은 모두 스레드 단위로 작업이 이뤄지며 작업에 따라 스레드 처리 시간이 길수도 짧을 수도 있습니다.

일상 생활에서도 금방 끝나는 일이 있고 오래 걸리는 일들이 있듯이 스레드도 처리 하는데 시간이 긴 작업과 짧은 작업들이 섞여 있는데 만약 그림처럼 CPU에서 하나의 스레드가 끝날 때까지 다른 스레드들은 기다려야 한다면 스레드 A가 끝날 때 까지는 스레드 B, C는 기다리고만 있어야 할 것 입니다.

image

[그림 2]

위 그림 2처럼 하나의 스레드가 자신의 명령이 끝날 때가지 계속 CPU 독점해서 사용한다고 하면 오랜 시간 동안 다른 스레드들(프로그램)이 실행되지 못할 것입니다, 그렇게 되면 다른 프로그램의 성능에 영향을 주겠죠? 특히 스레드 B의 입장에서는 잠시 CPU를 사용하면 금방 끝날 일인데 앞에서 스레드 A의 작업이 끝나기를 기다려야 하니 답답한 노릇일 것입니다.

그래서 좀더 효율적으로 동시 작업이 가능 하도록 하나의 스레드가 시작해서 끝날 때까지 무작정 CPU를 사용하는 것이 아니고 그림 3. 처럼 스레드의 실행 시간을 짧은 시간 단위로 잘라낸 뒤 순서대로 세워 놓고 실행하다 자신에게 할당된 시간이 끝나면 하던 일을 멈추고 다음 스레드에게 CPU를 사용할 수 있도록 한 뒤 다시 자기 차례가 돌아오면 자신의 일을 다시 합니다. 스레드가 CPU를 얼마 동안 사용할지를 정의한 시간 단위를 바로 퀀텀(Quantum)이라고 합니다. 그러면 그림에서처럼 스레드 B는 다음 순번에서 바로 작업을 끝낼 수 있습니다. (그림 3의 ‘A B C A B C A C A C A A A’ 순서를 보시면 이해가 좀 쉬우실 것입니다)

image

[그림 3]

이 퀀텀을 사용자가 길게도 혹은 짧게도 설정 할 수 있는데 이것이 바로 ‘프로세스 사용 계획 옵션’입니다. 그래서 ‘프로그램’으로 설정하면 모든 스레드의 퀀텀을 짧게(6, 대략 2 Click) 설정하고 반대로 ‘백그라운드 서비스’로 설정하면 길게(36, 대략 12 Click) 설정 합니다.

그렇다면 퀀텀(스레드 실행 시간)을 짧게 혹은 길게 설정 하는 것은 어떤 차이가 있을까요?

차이와 그에 따른 장단 점을 이해 하시려면 Context Switch라는 의미를 이해 해야 합니다.

image

[그림 4, Context Switch]

그림 4.와 같이 퀀텀에 정의된 시간이 끝나 CPU를 떠나야 하는 스레드 A는 CPU를 떠나기 전에 자신이 어디까지 작업을 했는지를 저장합니다, 그래야 다음 차례에 다시 A가 실행될 때 앞에서 마지막으로 진행했던 부분부터 다시 시작 할 수 있기 때문입니다, 또한 B는 자신이 앞에서 실행 했던 부분부터 다시 시작 하기 위해 앞에서 저장했던 실행정보를 불러옵니다, 바로 이런 일련의 작업을 컨텍스트 스위치(Context Switch)라고 합니다.

이 Context Switch 자체는 미약(?)하기는 하지만 전체적으로 보면 성능에 영향을 줄 수 있는 작업입니다. 그래서 만약 다른 작업은 거의 없고 CPU에서 스레드를 처리하는데 긴 시간이 필요한 단일 응용프로그램(SQL Server 혹은 그래픽 랜더링 작업 같은)만 실행하는 환경이라면 ‘백그라운드 서비스’로 설정해 Context Swith를 최소화하고 해당 프로그램의 스레드가 긴 시간 CPU를 사용 할 수 있도록 하는 것이 효과적일 것입니다.

반대로 일반 사용자의 컴퓨터 사용 패턴은 아주 소소한 아이콘 클릭 같은 작업을 포함해 IE같은 웹 브라우저 사용과 함께 음악을 듣는 것과 같이 동시에 여러 프로그램을 실행하는 패턴을 보입니다. 이런 경우 스레드에 긴 시간을 주면 스레드가 끝나기를 기다리는 시간이 오래 걸리기 때문에 다른 작업으로 넘어가는데 시간이 걸려 반응속도를 늦출 수 있지만, 일정한 시간 내에 여러 스레드들이 실행 될 수 있도록 퀀텀을 작게 설정하면 사용자 측면에서 반응속도를 높일 수 있습니다..



두 옵션은 아래와 같이 정의 할 수 있습니다


프로그램: 여러 작업을 동시에 수행하는 일반 사용자 환경에서 쾌적한(?) 반응 속도를 보여준다.
백그라운드 서비스: 계속해서 한가지 작업을 실행하는 응용프로그램을 실행 하는 경우 높은 처리 효율을 가진다.
 * 이 두 옵션을 그 반대의 환경에 설정하였다면 반드시 나쁘다고는 말할 수 없겠지만 성능 효율면에서는 떨어질 것입니다.

그래서 기본적으로 Windows 2000 Professional, XP, Vista그리고 Windows 7과 같이 일반 사용자를 위한 Windows 클라이언트에서는  ‘프로그램’으로 설정 되어 있으며 Windows Server 2000, 2003, 2008에서는 ‘백그라운드 서비스’로 설정 되어 있습니다. 만약 윈도우 클라이언트지만 그래픽 랜더링 작업 같이 CPU를 많이 사용하는 하나의 작업을 주로 사용하는 환경이라면 ‘백그라운드 서비스’를 선택 할 수 있을 것이고 반대로 윈도우 서버지만 클라이언트 환경같이 사용한다면 ‘프로그램’ 옵션을 선택하면 성능에 효과적일 것입니다.




조금 자세한 추가 설명
‘프로그램’으로 설정 되어 있으면 스레드는 2 Clock interval 기간 동안 실행이 가능하며 ‘백그라운드 서비스’는 12 Clock interval 기간 동안 실행할 수 있습니다.

퀀텀에서는 Clock interval의 3배수로 설정됩니다, 그래서 ‘프로그램’으로 설정 되어 있으면 Short 값인 6(‘실제 Clock 2개’ x 3배수)을 가지고, ‘백그라운드 서비스’로 설정 되어 있으면 퀀텀 Long 값인 36(‘실제 Clock 12개’ x 3배수)을 가집니다. 그래서 클럭인터럽트가 걸릴 때마다 퀀텀 값을 3단위로 줄여가 결국 0이 되면 일단 그 스레드가 이번에 실행될 시간은 모두 끝내고 기다리고 있던 다음 스레드가 실행 되도록 합니다.

이해를 돕고자 상당 부분 단순화 썼습니다. 좀더 자세한 정보가 필요하신 분들께서는 아래  Windows Internals의 Thread 부분을 참고 하시기 바랍니다.



[참고문서]Windows Internals 4’th, Chapter 6, Controlling the Quantum
 

Tags  Kernel Microsoft Performance Windows Windows 2008 Windows 7 Windows Vista 마이크로소프트 윈도우즈 7

728x90
300x250

'IT > IT 개념' 카테고리의 다른 글

하드웨어의 가상화 - CPU 부분  (0) 2016.07.07
VT-D 란 무엇인가?  (0) 2016.07.07
728x90
반응형

작성자 : 서비님(https://dslee1.blogspot.kr/)

 

1. 개요
 방문자에게 질문하고 싶다. 이곳에 어떤 방법으로 방문하게 되었나?
그렇다. 인터넷 검색을 통해서 방문하였을 것이다. 그럼 인터넷 검색은 어떠한 공간에 있는 것일까?
우리가 검색을 할 수 있는 공간은 서버들이 모여있는 공간이어야 될 것이다. 그러한 서버들에 자료들이 저장되어있을 것이고, 그러한 자료를 우리 사용자가 볼 수 있도록 인터넷 웹페이지를 보여주는 역할을 하는 것이 Web 서버 및 Was 서버의 역할이다.

 

2. Web서버 Was서버 사전적인 의미는 무엇일까?
위키백과사전을 참조하여 한번 정리해 보도록 하겠다.

 

[web 서버]
- 웹 서버 (소프트웨어) : 웹 브라우저와 같은 클라이언트로부터 HTTP 요청을 받아들이고, HTML 문서와 같은 웹 페이지를 반환하는 컴퓨터 프로그램.
- 웹 서버 (하드웨어) : 위에 언급한 기능을 제공하는 컴퓨터 프로그램을 실행하는 컴퓨터

 

[was 서버]
웹과 기업의 기간 시스템 사이에 위치하면서, 웹 기반 분산 시스템 개발을 쉽게 도와주고 안정적인 트랜잭션 처리를 보장해 주는 일종의 미들웨어소프트웨어 서버. 3계층 웹 컴퓨팅 환경에서 기존 클라이언트/서버환경의 애플리케이션 서버와 같은 역할을 하며, 클라이언트와 서버 환경에서 트랜잭션 처리 및 관리와 다른 기종 시스템 간의 애플리케이션 연동 등을 주된 기능으로 하고 있다.

 

WAS는 웹이 탄생한 이래, 주로 데이터베이스조회나 일반적인 비즈니스 로직에 대한 처리를 위해 다양한 언어로 개발된 인터넷/인트라넷환경의 소프트웨어를 지칭한다. 자바스크립트나 JSP 등과 같은 스크립트 및 서비스들은 대개 최신의 데이터를 검색하기 위해 데이터베이스에 접근하고, 브라우저 또는 클라이언트프로그램을 통해 사용자들에게 검색 결과를 제공한다.

 

WAS를 비롯한 애플리케이션 서버들은, 웹서버 즉 HTTP 서버와 같은 컴퓨터를 공유할 수도 있지만, 별개의 컴퓨터를 독립적으로 사용하는 때도 많다. 대규모 사이트에서는, 오히려 WAS와 웹서버 등을 위해 여러 대의 컴퓨터가 동원되기도 한다. 넷스케이프의 Netscape Application Server, BEA의 Web logic Enterprise, 볼랜드의 App Server, 그리고 IBM의 Web sphere Application Server 등이 WAS의 대표적인 제품들이다

 

 

 


단순 용어만 놓고 봤을때에는 이해하기 쉽지 않을것이다. 그래서 아래와 같이 조금더 쉽게 풀어서 설명을 해보겠다.

WEB서버는 html, jpg, gif 확장자로 된 문서나 이미지를 이용해서 웹페이지를 보여주는 것.
Was서버는 Container(컨테이너)라는 용어로 사용되고있으며, 초창기에 cgi 로 사용되다가 요즘에는 jsp, asp 문서를 사용하여 웹페이지를 보여주는 것이다.

 

인터넷 검색해보면 너무나도 생소하고 어려운 용어들이 많이 있지만, 아주 기본적인 개념만 잡고있으며 web,was 는 쉽다.

그럼 여기서 web이 좋냐 was가 좋냐고 물어볼수 있는데, 정답은 없다. 웹페이지를 보여주는 방식이 다를 뿐이지 한쪽에만 치우친다고 해서 좋지는 못하다.

그래도 was가 좀더 고급적이고 관광서 및 큰 기업에서 많이 사용되고 있으므로 조금더 설명을 하도록 하겠다. 추가적으로 개념을 알아두면 좋을 것이다.

 

[WAS 도입효과 및 기술표준]


1. Was 도입효과
 - 안정된 시스템 구성 : 안정적 서비스 보장, 자동적인 어플리케이션 복구기능 제공, 업무 로직이 중간 어플리케이션 서버에 존재, 쉽고 빠르게 구축할 수 있다.
  - DB 성능 보장 : WAS서버가 DB서버와의 최적 사용을 조절화, DB connection pool을 총해 DB connection 관리 및 트랜잭션 처리
 - 비용절감 : 서버 리소스의 원할한 사용

 

2. WAS 기술 표준
 - J2EE : Java 기반의 분산객체 아키텍쳐

 

3. WAS의 일반적인 기능
 - Web 환경을 위한 n-tier Architecture 플랫폼
 - Presentation(GUI)과 Business Logic의 분리 운영
 - Thread 관리
 - 부하조절(Load Balancing) 기능 지원
 - 장애대책(Fail-Over) 기능 지원
 - Transaction 처리 자동화
 - Web Service 플랫폼으로써의 역할

 

[어플리케이션 종류(프로그램 종류)]
그럼 Web서버와 Was서버를 실질적으로 서비스 하는 어플리케이션은 무엇이 있을까?
이부분을 가볍게 읽고 넘어가기 바란다.

Was Server 종류 : tomcat, tMax jeus, BEA Web Logic, IBM Web Spere, JBOSS,
                              Bluestone, Gemston, Inprise, Oracle, PowerTier, Apptivity, SilverStream
Web Server 종류 : IIS, apache, tMax WebtoB

인지도가 높고, 사용률이 높은 어플리케이션은 별도로 표시해뒀다.

3. 마무리
Web서버와 Was서버의 차이에 대해서 살펴보았다. 최대한 쉽고 가볍게 정리한다는것이 다시 살펴보니 용어가 어려운 부분이 보여 아쉬움이 남는다.
다음 포스팅은 was서버, web서버의 어플리케이션 종류에 대해서 상세히 살펴보도록 하겠다.

728x90
300x250
728x90
반응형

- Virtual Machine(이하 VM)에도 CPU가 있지만 실제 VM내의 게스트OS에서의 발생하는 모든 프로세스들은 VM이 아닌,
실제 호스트의 CPU에서 처리가 이루어지며, 게스트OS에서 발생하는 프로세스들(CPU Process)은 VMkernel의 'VMM'을 통해 실제 호스트의 CPU로 프로세스 처리가 가능하도록 전달해줍니다.
(VMM은 'Virtual Machine Monitor'이며 VM에서 실행되는 실제 CPU명령을 전달해줍니다, 하나의 VM에 하나의 VMM이 반드시 생성되며, 개별 VM들이 서로 충돌이나 간섭없이 작동될 수 있도록 격리시키져는 역할도 하게 됩니다.

이 때, CPU에게 명령을 전달해주는 방식으로는 두 가지가 있습니다.


1. Binary Translation
 --> VM내의 게스트OS에서 CPU에 직접 명령을 전달해야하는 Privilege code들을 'Binary Translation' 기법을 통해 중간에 가로채어 에뮬레이션화 해서 접을 조종하게 됩니다.


2. Direct Execution
 --> RIng 0접근이 필요없는 사용자 레벨(Ring 3)에서의 코드들은 'Direct Execution(직접 실행)' 기법을 사용하게 됩니다.)


 - VMKernel은 모든 VM에게 발생하는 CPU Process들은 최대한 균등하게 분배할 수 있도록 전체 물리적인 CPU 리소스를 스케줄링하며 시분할 방식을 통해 프로세스를 처리하려고 합니다.


 - 멀티코어 프로세서


: 코어 개수가 많으면 많을소록, 더 많은 가상 CPU를 사용할 수 있게됩니다. vSphere서버에서 각 코어는 하나의 Logical Processor단위로 인식이 되며,듀얼코어 CPU의 경우 2개의 Logical Processor단위로 인식하게 되며, 그 위에 Virtual CPU를 할당하여 사용하게 됩니다.


- 하이퍼쓰레딩


: 하이퍼쓰레딩이란 OS가 물리적인 하나의 CPU를, 두 개의 논리적인 CPU처럼 인식하여 동작하게 해주는 기술입니다.
vSphere에서도 하이퍼쓰레딩을 지원하게 되며, 기능이 설정되었다면, 모두 Logical Processor로 인식하게 됩니다.


 - DVFS(Dynamic Voltage and Freqyency Scaling)


: CPU의 Clock rate와 전력을 동적으로 조정하여 전력비용을 절감 시킬 수 있는 기술입니다.
설정에 따라 CPU가 갖고 있는 최대 Clock rate를 사용할 수 도 있으며, CPU 사용량에 따라 vSphere서버 스스로 동적으로 Clock rate를 변경할 수 있습니다.


 - CPU Affinity


: VM의 Virtual CPU가 보는 호스트의 CPU는 항상 같을 수는 없습니다.
첫 번째 명령을 0번 코어가 처리했다면, 두 번째 명령을 4번 코어가 처리할 수도 있습니다, 하지만 특정 VM에서 일어나는 CPU 명령을 고정적으로 처리할 수 있게 CPU를 지정해주는 기능을 말합니다.
주의해야 할 사항은, Affinity 설정 시 기존CPU 개수에 +1를 해주는 것이 좋습니다. 그리고 하이퍼쓰레딩을 사용하는 경우에는 CPU번호를 떨어뜨려서 사용해야 합니다 (Ex, CPU0-CPU4)
왜냐하면, 하이퍼쓰레딩의 경우 물리적 한개를, 논리적 2개로 인식을 합니다. vSphere서버가 CPU를 인식할 때는 물리적 CPU내의 논리적 CPU순서입니다.(물리CPU0 - 논리CPU0, 물리CPU1 - 논리CPU-1....등)
Affinity설정 시, CPU0-CPU1를 하게 된다면 논리적으로 보았을 때는 별 문제 없어보이나 물리적으로 본다면 실질적으로 코어
 한개만을 사용하는 것이 되기 때문입니다(하이퍼쓰레딩을 사용시 Affnity설정할 때의 이야기입니다).


 

- Full Virtualization, Paravirtualization


1. Full Virtualization, 대표로는 VMware의 ESX서버입니다


여기서 작동되는 게스트OS는 자신이 하이퍼바이저 커널에서 작동되고 있다는 것을 모릅니다. 단순히 자신에게 물리적인 장치들이 장착되어 있으며 나 혼자만이 하드웨어를 독점하여 사용하고 있다고 생각할 뿐입니다.
이와 같이 스스로 착각을 하기 때문에, CPU의 경우 VMware에서 'Binary Translation'과 'Direct Execution' 과 같은 기법을 통해 CPU 명령을 중간에서 변환시켜야 하는 일종의 오버헤드가 발생하기 때문에 성능저하가 발생할 여지가 존재하게 됩니다.


2. Paravirtualiztion, 대표로는 Zen 서버입니다.


Full Virtualization과는 조금 다릅니다, 최초엔 하이퍼버이저에서 인식할 수 있는 특별한 시스템 콜 명령을 가지고 있는 게스트OS여야만 작동이 가능했습니다. 이 방식을 통해 직접 CPU에게 명령을 전달하여 오버헤드를 줄일 수 있으므로, Full Virtualization보다 좀 더 하드웨어에 근접한 성능을 뽑아낼 수 있었으나, 게스트OS의 커널이 수정되어야 하는 불편함이 존재했습니다.
리눅스의 경우는 시스템 콜 명령이 커널 내부에 포함되어 작동이 되었지만(커널 2.6이상) 윈도우의 경우 그렇지 않았습니다.
그러나 Intel VT-x , AMD-V 기술이 나오게 되면서 이러한 부분이 해결이 되었습니다.
VMM이 Ring -1로 가게되면서 게스트OS가 제약없이 RIng 0의 하드웨어 접근권한을 갖게 되므로, 윈도우에서도 커널 수정없이 바로 작동이 가능하게 된 것입니다.

728x90
300x250

+ Recent posts