AdminID.kr (어드민아이디) - 시스템, 네트워크, 보안 관리자, System Engineer, Unix, Linux, Windows, Oracle, MSSQL, MySQL, Windows, HardWare, Security, Router, Switch, Firewall

MySQL Dump / Import (덤프 / 임포트)

JAESOO — Mon, 10 Oct 2016 09:32:41 +0000

MySQL 덤프 / 임포트

1. dump

1.1 전체 dump

$>mysqldump -u [사용자아이디] -p 데이타베이스명 > 저장될 파일명.sql

예) mysqldump -uroot -p data > data.sql

1.2 테이블만 dump

$>mysqldump -u [사용자아이디] -p 데이타베이스명 테이블명 > 저장될 파일명.sql

예) mysqldump -u root -p data member > data_User.sql

2. 복구하기 (Import)

$> mysql -u[사용자아이디] -p 데이타베이스명 < 덤프파일명.sql

예) mysql -u root -p data < data.sql

예) mysql -u root -p data User_info < data_User.sql

3. 특정db의 특정 table에서 원하는 값만 덤프 받기

User라는 DB에 a,b,c라는 테이블이 있다. 여기서 b라는 테이블에서 no가 4번이상이고 7번 이하인 값만 덤프 받기

사용되는 옵션 -w

예) mysqldump -u root -p User b-w'no =>4 and no=< 7' > edu_a_cond.sql

4. Database 스키마만 백업 받기

data라는 DB의 모든 테이블 스키마를 백업 받기

예) mysqldump -u root -p -d data > data_db.sql

data라는 DB의 a라는 테이블 스키마를 백업 받기

예) mysqldump -u root -p data a > data_a_table.sql

출처 : http://kssong.tistory.com/2

Reverse DNS - 등록및 확인

JAESOO — Fri, 23 Sep 2016 16:26:14 +0000

# RDNS(Reverse DNS)

* Reverse DNS의 기본 용도는 해당 IP의 서버가 실제로 등록되어 있는지를 확인.
* 일반적으로 메일 서비스에서 스팸메일을 차단할 때 메일 발송 서버의 IP를 역방향(Reverse DNS) 조회를 해서
Reverse DNS가 등록된 서버의 메일만 수신을 허용하는 방식으로 사용.

* 특정 메일주소로 발송시 rdns 체크 오류(존재하지 않음)로 인해 메일이 전송되지 않는 증상 발생

* Reverse DNS는 DNS서버에 설정후에 상위 인터넷서비스제공자(ISP)에게 RDNS 등록 요청이 필요함.

# Reverse DNS 등록 진행 절차
1) 관리하는 DNS 서버에 Reverse DNS 설정을 추가
2) NameServer(DNS) 재시작
3) nslookup 확인
4) RDNS 정상 등록일 경우 서버및 인터넷 관리업체에 RDNS 등록 요청
- 일반(기업 또는 개인) > 등록요청(가비아 또는 IDC 담당업체) > ISP(데이콤, KT 등등)

# 일반 기업 직접 등록 요청
* 등록 요청 기관

1) 데이콤 DNS 서버관리자 : dnsadm@bora.net
- 등록 요청 양식을 메일로 전송

2) KT(kornet) DNS 작업요청 홈페이지 : http://dns.kornet.net/jsp/login.jsp
- 링크 페이지 이동 > 도메인 등록 요청/문의 > 새글작성 > 요청 양식 입력 > 확인(저장)

* 등록요청 양식

> Reverse DNS (PTR Record) 등록을 요청합니다.
1. 업체명(고객이름) :
2. 사용서비스명(상품명) :
3. 고객번호(관리번호) :
4. 메일서버 IP : x.x.x.x
5. 메일서버 호스트(도메인) : mail.YourDomain.com

# RDNS 설정

[root@ns1 etc]# vi /etc/named.conf

zone "222.111.211.in-addr.arpa" IN {
type master;
file "/var/named/slaves/named.rev";
allow-update { none; };
allow-transfer { 211.111.222.124; };
};

[root@ns1 etc]# vi /var/named/slaves/named.rev

$TTL 10M
@ IN    SOA ns1.abc.com. root.ns1.abc.com.    (
2013062010    ; serial
3h    ; refresh
1h    ; retry
1w    ; expire
1h    ; mininum
)
IN    NS    ns1.abc.com.
IN    NS    ns2.abc.com.
;
123    IN    PTR ns1.abc.com.
124 IN    PTR    ns2.abc.com.
125 IN    PTR    mail.abc.com. < 메일서버 정보(IP, 도메인)

# Reverse DNS 설정후 확인(상위 기관 등록 전)
- RDNS 조회 사이트 : http://remote.12dt.com

C:\Users\sunshiny>nslookup
기본 서버: bns1.hananet.net
Address: 210.220.163.82

> set type=ptr
> 125.222.111.211.in-addr.arpa
서버:    bns1.hananet.net
Address: 210.220.163.82

*** bns1.hananet.net이(가) 125.222.111.211.in-addr.arpa을(를) 찾을 수 없습니다.
on-existent domain

# DNS 서버 자체 조회시, PTR 조회 성공
> server abc.com
기본 서버: abc.com
Address: 211.111.222.123

> 125.222.111.211.in-addr.arpa
서버:    abc.com
Address: 211.111.222.123

125.222.111.211.in-addr.arpa name = mail.abc.com
222.111.211.in-addr.arpa nameserver = ns1.abc.com
222.111.211.in-addr.arpa nameserver = ns2.abc.com
ns1.abc.com    internet address = 211.111.222.123
ns2.abc.com    internet address = 211.111.222.124

1) 아래 내용 출처
http://www.passkorea.net/Board/ViewDoc.aspx?brdNo=8&docNo=29293&page=1&brdType

해외 메일서버로 메일을 보내려면 사용중인 메일서버 IP에 대해

Reverse DNS (PTR Record)가 등록되어 있어야 수신이 될 가능성이 높습니다.

이는 해외 메일서버에서 ‘가정용 유동IP’가 ‘서버용도 IP’임을 파악하기 위한 자료로 사용되는 경우가 많기 때문입니다.

먼저 아래처럼 사용중인 메일서버 IP에 Reverse DNS 가 등록되어 있는지 확인해보시기 바랍니다.

(nslookup 명령은 리눅스나 윈도우환경에서 공통적으로 사용이 가능한 DNS 질의명령입니다.)

nslookup -type=ptr 211.170.106.71

Non-authoritative answer:

71.106.170.211.in-addr.arpa name = mail.passkorea.net.

Authoritative answers can be found from:

106.170.211.in-addr.arpa nameserver = nis.dacom.co.kr.

106.170.211.in-addr.arpa nameserver = ns2.dacom.co.kr.

nis.dacom.co.kr internet address = 164.124.101.31

ns2.dacom.co.kr internet address = 203.248.240.31

위 조회 결과는 패스코리아넷의 메일서버 IP를 기준으로 조회했을 때이며 mail.passkorea.net 이라는 값이 Reverse DNS 로 등록되어 있는 것을 확인할 수 있습니다.

만약 등록되지 않았다면 아래와 같은 실패 메세지가 나옵니다.

** server can't find 71.106.170.211.in-addr.arpa: NXDOMAIN

등록되지 않았을 경우 아래 절차에 따라 귀사의 메일서버IP를 관리하는 상위기관에 등록요청을 하셔야 합니다.

1. 등록요청이 가능한 IP - 서버호스팅, 전용회선 사용자.

주의) VDSL, ADSL, 광랜 등의 가정용 서비스는 국내 정책상 등록이 불가능합니다.

2. 등록요청기관

서버호스팅 - 호스팅 제공업체에 요청.
전용회선 - 전용회선 임대 사업자(데이콤 등)의 DNS 서버관리자에게 요청.

참고)

데이콤 DNS 서버관리자 : dnsadm@bora.net

KT(kornet) DNS 작업요청 홈페이지 : http://dns.kornet.net/jsp/mainFrame.jsp

주의) Reverse DNS 는 자체 DNS에 등록한다고 해결되는 것이 아니라 상위 네트워크 기관에서 등록해야 인식됩니다.

3. 등록전 준비사항)

등록하려는 메일서버IP와 메일호스트명이 일치하는지 점검후 DNS 셋팅을 정확히 해놓으셔야 합니다.

참고)

nslookup mail.passkorea.net

Non-authoritative answer:

Name: mail.passkorea.net

Address: 211.170.106.71

4. 등록요청 양식)

Reverse DNS (PTR Record) 등록을 요청합니다.

1. 업체명(고객이름) :
2. 사용서비스명(상품명) :
3. 고객번호(관리번호) :
4. 메일서버 IP : x.x.x.x
5. 메일서버 호스트(도메인) : mail.YourDomain.com

2) 아래 내용 출처
https://kr.dnsever.com/faq/viewtopic.php?p=19

가. 한두개 서버(IP)의 역방향도메인(PTR)설정을 위해서는 ISP에게 문의하셔야 합니다.
메일서버에서 메일을 발송하기 위해서 역방향 도메인(PTR레코드)를 설정하는 것이 필수적인 사항은 아닙니다만,
일부 메일서버에서는 스팸을 거르기 위한 방법으로 역방향 레코드가 설정되어 있지 않은 서버에서 메일을 발송하는 경우에
메일을 스팸으로 간주하는 경우가 있기 때문에, 역방향도메인설정(PTR레코드설정)을 하는 방법에 대하여 문의가 많습니다만,
대부분의 경우는 역방향도메인(PTR레코드설정)은 DNSEver.com 에서 하는 것이 아니라,
서버의 인터넷회선(IP주소)를 제공하는 인터넷회선제공업체(ISP)에게 요청하여 설정을 해달라고 하시면 됩니다.

역방향도메인(또는 PTR레코드)는 일반적인 도메인명을 꺼꾸로 바꿔서 IP주소와 연결하는 것인데,
예를 들어서
mail.domain.com -> 1.2.3.4
와 같이 연결하는 A레코드(호스트IP 설정)가 설정되어 있다고 하면
이에 대하여 꺼꾸로 된 도메인인
4.3.2.1.in-addr.arpa -> mail.domain.com
과 같이 연결하는 PTR 레코드를 설정하는 것을 말합니다.

위에서 4.3.2.1.in-addr.arpa 라는 레코드를 설정하기 위해서는
3.2.1.in-addr.arpa 라는 도메인에 대한 네임서버(NS레코드) 설정이 필요한다.
in-addr.arpa 라는 특수한 도메인은 일방적으로 .com, co.kr 과 같은 도메인등록업체에서 구입하고 관리할 수 있는 도메인이 아니라
인터넷회선제공업체(ISP)에서만 관리할 수 있는 도메인인 것이며,
위에서 3.2.1.in-addr.arpa 도메인은 1.2.3.0 ~ 1.2.3.255 까지의 IP를 모두 할당받아 관리하는 사용자가 아니면
대부분의 인터넷회선제공업체에서는 3.2.1.in-addr.arpa 와 같은 도메인에 대한 네임서버설정(NS레코드설정, 위임이라고 합니다)은 잘 해주지 않습니다.

따라서, 역방향 레코드의 설정이 필요하다면 대부분의 경우는 인터넷회선제공업체(KT, SKT, LG데이콤등 )에 직접 연락을 해서
4.3.2.1.in-addr.arpa -> mail.domain.com
과 같이 연결하는 PTR 레코드를 설정해달라고 하시면 됩니다.

나. C Class(IP주소 256개) 이상의 네트워크에 대한 역방향 도메인을 설정하기 위해서도 ISP에서 네트워크영역의 역방향 도메인에 대한 네임서버 설정 위임을 받아야 합니다.
즉 IP주소가
1.2.3.0 ~ 1.2.3.255 까지 256개(C클래스)를 가지고 있고 해당 IP주소 영역에 대하여 역방향 도메인을 설정하기 위해선느
3.2.1.in-addr.arpa 에 대한 네임서버(NS레코드)를 ISP에서 dnsever 의 네임서버로 설정해줘야 역방향 레코드 설정이 가능합니다.

네임서버(NS레코드) 설정이 잘되어 있는지는 nslookup , dig 로 확인가능한데
#> nslookup q=NS 3.2.1.in-addr.arpa
또는
#> dig 3.2.1.in-addr.arpa PTR
과 같이 DNS 질의를 해보시면 됩니다.

대부분의 ISP에서는 네트워크영역(예: 3.2.1.in-addr.arpa)에 대한 네임서버설정(위임)을 잘 해주지 않으므로
C클래스 이상의 IP를 가지고 있는 경우에도, 가.번에서 설명한 것과 마찬가지로 ISP에 개별적인 PTR 레코드(예: 4.3.2.1.in-addr.arpa PTR mail.domain.com) 설정을 해달라고
요청하시는 것이 낫습니다.

다. C Class(IP주소 256개) 이상의 네트워크에 대한 역방향 도메인을 설정

C Class(IP주소 256개) 이상의 네트워크에 대한 역방향 도메인을 설정하기 위해서도 ISP에서 네트워크영역의 역방향 도메인에 대한 네임서버 설정 위임을 받아야 합니다.
C Class 이하의 네트워크를 위임받은 경우에는 각각의 아이피에 대한 네임서버를 CNAME을 이용해서 역시 DNSEver 네임서버로 변경하셔야 합니다.

< C Class 이하의 네트워크를 추가한 경우 >

DNSEver는 C Class 이하 네트워크의 경우에는, 인터넷서비스제공자(ISP)에 직접 요청하여 PTR레코드를 추가할 것을 권장합니다.
C Class이하 네트워크를 직접 관리하는 것은 DNSEver와 인터넷서비스제공자(ISP)간의 상호 작업이 필요할 수도 있으며,
회원님께서도 DNSEver를 통해 관리하기보다는 인터넷서비스제공자(ISP)에 요청하여 관리하는 것이 훨씬 편리하기 때문입니다.

혹, C Class 이하로 네트워크를 위임받아서 역방향 도메인을 DNSEver에 등록하셨다면 다음의 사항에 유의하시기 바랍니다.

예를 들어서 위임받은 네트워크의 영역이 192.168.10.2 ~ 192.168.10.7이며, 인터넷서비스제공자(ISP)에서 위임받은 역방향도메인이 2/7.10.168.192.in-addr.arpa 라고 가정합니다. 이 경우에는 인터넷서비스제공자(ISP)에서 단순히 2/7.10.168.192.in-addr.arpa 를 위임받는 것 외에

2.10.168.192.in-addr.arpa CNAME 2.2/7.10.168.192.in-addr.arpa
3.10.168.192.in-addr.arpa CNAME 3.2/7.10.168.192.in-addr.arpa
4.10.168.192.in-addr.arpa CNAME 4.2/7.10.168.192.in-addr.arpa
5.10.168.192.in-addr.arpa CNAME 5.2/7.10.168.192.in-addr.arpa
6.10.168.192.in-addr.arpa CNAME 6.2/7.10.168.192.in-addr.arpa
7.10.168.192.in-addr.arpa CNAME 7.2/7.10.168.192.in-addr.arpa

위와 같이 모든 아이피에 대해서 CNAME를 지정해주어야하며, 또한

2/7.10.168.192.in-addr.arpa NS ns1.dnsever.com
2/7.10.168.192.in-addr.arpa NS ns2.dnsever.com

위와 같이 2/7.10.168.192.in-addr.arpa 에 대한 네임서버를 DNS'Ever의 네임서버로 위임하셔야 정상적인 서비스가 이루어질 수 있습니다.

출처 : http://develop.sunshiny.co.kr/975

엑셀 시트보호 해제 프로그램 없이 하기

JAESOO — Tue, 06 Sep 2016 17:29:51 +0000

보통 회사나 단체기관에서 모든 문서는 보호되어 사용되는데요. 문서에 대한 저작권과 외부로의 유출이 우려되기 때문입니다.이런 보호 기능중에 하나가 엑셀에서의 시트보호 기능인데요. 이 엑셀 시트보호 해제 방법에 대해서 알아보겠습니다.

보통 이런 보호기능의 해제 방법은 특정 프로그램을 이용해서 할 수 있으나 제가 알려드리는 기능은 압축해제 프로그램 하나만 있으면 시트보호를 해제할 수가 있습니다.

파일 준비

일단 보호가 걸려있는 엑셀 파일 하나를 준비해 주시기 바랍니다.

여기 엑셀 파일 하나가 있습니다.

이 파일은 시트보호 기능이 걸려있어서 파일의 수정을 할수가 없는 상태인데요.

이렇게 될 경우 파일의 수정이 불가능하기 때문에 난감할 수 있습니다.

이 기능을 해제하려면 처음에 보호 기능을 걸때의 패스워드를 알아야 하는데요.

하지만 이 패스워드 없이 이 시트보호 기능을 해제해 보겠습니다.

엑셀 시트보호 해제

일단 저장된 엑셀파일의 확장자를 zip파일로 변환해 주시기 바랍니다.

(확장자가 안보이시는 분은 이전 포스팅인 윈도우7 확장자 보기를 참조해 주시기 바랍니다.)

zip 파일로 변경을 하신 뒤에 해당 파일을 더블클릭하면 위와 같이 압축해제 창이 열리게 됩니다.

(제가 쓰는 압축해제 프로그램을 알집이라서 알집 기준으로 설명드리겠습니다.)

해당 파일의 구조를 보시면 xl -> worksheets -> 보호가 걸려있는 파일의 xml을 선택합니다.

그리고 이파일을 메모장이나 편집이 가능한 텍스트 프로그램을 이용하여 열어주도록 합니다.

그럼 위와 같이 해당 워크시트에 대한 코드가 나타나게 됩니다.

패스워드 초기화

이곳의 sheet Protection password 항목을 찾아주도록 합니다.

여기에 16진수로 처럼 보이는 숫자가 적혀 있는데요.

이 숫자를 지운 다음에 해당 파일을 다시 저장해 주시면 됩니다. 바로 이 작업이 시트보호 비밀번호를 초기화 시켜주는 작업입니다.

저장을 마치시면 수정된 xml과 함께 해당 파일을 다시 압축해 줘야 하는데요.

알집에서 하게 될 경우 이렇게 자동적으로 압축기능이 제공되었습니다.

그리고 해당 파일을 다시 xlsx로 변경해 주신 뒤에 문서를 실행해 주시면 됩니다.

그리고 해당 시트를 시트보호 해제 기능을 이용해서 해제하게 되면 비밀번호가 초기화 되었기 때문에 아무런 질의 없이 보호가 해제됩니다.

이런 방법을 쓰시면 전용 프로그램 없이 엑셀 시트보호 해제 기능을 수행할 수 있으니 보호가 걸려있는 엑셀 파일을 가지고 계신분들은 유용하게 사용해 보시기 바랍니다.

출처 : http://ontheinfo.com/1178

윈도우 컴퓨터 유지보수에 유용한 무료 프로그램들

JAESOO — Wed, 31 Aug 2016 16:36:46 +0000

흔히들 초보자들은 유지보수(?) 라는 명목하에에 트윅프로그램이나, 클린 프로그램 등을 사용한다. 멘트는 뻔하다. 컴퓨터 빨라지는 법. 이라며 소개된 프로그램들이다. 캐쉬를 지운다던가, 레지스트리를 청소한다던가 방법도 여러가지다. 그러나 이러한 프로그램들 자체가 오히려 시스템을 느리게 만들고 있는 주범이다. 특히 레지스트리를 건드리는 프로그램은 매우 위험하고, 컴퓨터가 빨라졌다는 사람보다, 레지스트리 청소 후, 컴퓨터가 더 망가져서 도움을 요청하는 글이 더 많다.

윈도우 유지보수의 첫 걸음은 윈도우의 작동원리를 잘 이해하는 것 부터 시작된다. 쉬운일은 아니지만, 이해의 폭을 넓혀갈 수록, 문제 해결도 그만큼 빠르게 대처할 수 있게 된다.

그리고 윈도우를 항상 쾌적하게 유지하기 위해서는, 신뢰도가 낮은 제작사의 프로그램은 가급적 설치하지 않는 것이 최선이다. 그리고 컴퓨터를 매우 어지럽힐 것 같은 프로그램은 매우 주의해서 설치하고, 설치 옵션 및 설치 후에도 설정과 관련 프로세스를 꼼꼼히 살펴봐야 한다.

1. Process Explorer

작업관리자에서 흔히 보는 실행중인 프로세스를 보다 자세히, 보다 편하게 보여준다. 계층형으로 보여주기 때문에 손쉽게 시스템 기반 프로세스와, 사용자 기반 프로세스를 구분할 수 있다. 뿐만 아니라 프로세스별 gpu 점유율, 및 그래픽 메모리 까지 확인가능하다. Microsoft 공인 엔지니어가 직접 개발하여 Microsoft Technet 을 통해 배포하기 때문에 신뢰도는 의심할 여지가 없다.

다운로드

2. Autoruns

위에 process Explorer와 마찬가지로 같은 개발자가 만든 인기 관리툴이다. 윈도우 시작시 자동으로 실행되는 프로세스를 한번에 모두 관리할 수 있다.

다운로드

3. Treesize Free

각 폴더별 용량을 쉽게 볼 수 있게 해준다. 하드디스크 용량 관리에 매우 유용하다.

다운로드

4. BlueScreenView

컴퓨터가 갑자기 재부팅되거 블루스크린이 뜰 때, 윈도우는 최소한의 오류 정보를 남기고 재부팅된다. 흔히 보이는 블루스크린의 정보는 사실 해석하기도 어렵거니와, 보기도 불편하다. 이 프로그램은 블루스크린이 남기고 간 오류정보를 쉽게 다시 열어볼 수 있게 만든 프로그램이다. 블루스크린의 원인이 된 파일을 보여주기 때문에 에러의 원인을 더 쉽게 찾을 수 있다.

다운로드

5. 이벤트뷰어

프리징, 다운, 응용프로그램 종료, 에러 같은 거의 대부분의 오류들은 사실 윈도우가 모두 기록하고 있다. 그 기록들을 볼 수 있는 곳이 바로 이벤트뷰어이다. 윈도우가 정상적으로 작동하지 않다고 의심되면 제일 먼저 이벤트뷰어를 볼 것을 추천한다.

제어판 - 관리도구 - 이벤트뷰어

5. Open Hardware Monitor

컴퓨터의 온도 추적을 위해 유용한 프로그램. CPUID 의 HWMonitor 와 매우 비슷하나, 기능은 훨씬 강력하다. 심지어 HWMonitor Pro(유료) 버전보다도 기능이 강력하다. 특히 그래프(Plot)를 지원하는데, 놀라운 점은 이전의 실행됐던 로그의 그래프도 보존 되어 있다는 점. CPU가 과열로 인해, 즉시 리부팅 되어도, 리부팅 순간까지의 그래프 기록을 살펴 볼 수 있다.

다운로드

출처 : http://comfixlog.tistory.com/7

NAS용 저전력 PC 제작

JAESOO — Wed, 31 Aug 2016 16:35:41 +0000

현재 NAS로 가장 인기있는 것은 시놀로지 NAS입니다. 이는 복잡한 설치과정이나 세팅할 시간이 없고, 일반적인 용도로 충분히 만족할 만한 기능을 제공하고 있기 때문이지요. 연동 모바일 앱들도 상당한 퀄리티를 보여줍니다. 그리고 훌륭한 디스크 확장성 때문에 10테라 이상의 데이터를 운용하시는 분은 아마 시놀로지가 매우 훌륭한 선택이라 여겨집니다.

그러나 운용데이타가 크지 않고, SW개발 관련일을 하거나, 서버관련 지식이 있다면 직접 서버를 구성하는 것도 좋은 선택이라 생각합니다. 특히 요즘 저렴한 가격에 저전력 시스템이 많이 팔고 있어 예전처럼 노트북용 모듈을 구하지 않아도 손쉽게 구축이 가능해졌습니다.

기본 하드웨어 스팩

CPU : Interl J1900

Mainboard : Gigabyte J1900N-D3V (CPU포함 12만)

RAM : DDR3L 8G 노트북용 저전력 (5만)

Disk : SSD 128, HDD 750G

Power : 마이리틀 DC to DC 120w + 아답터 (5만)

Case : Elfin M-2 3.0 (3만)

총 25만원이 소요되었으며, SSD 및 HDD는 기존 보유하던 것을 이용했으므로, 하드디스크 등을 포함하면

대략 35 ~ 45만원 정도 예상됩니다.

저소음

가정용 서버(NAS)를 구축하는데 가장 큰 기준은 저소음과 저전력입니다. 먼저 무소음에 가까운 저소음을 위해서 냉각팬이 없어도 되는 CPU를 사용하였습니다. 또한 파워역시 냉각팬이 없는 DC to DC 에 아답터를 연결하였습니다. 현재 유일한 소음원은 하드디스크 입니다. 그러나 별도로 OS를 SSD에 올렸고, 하드디스크의 절전 대기 시간을 10분으로 짧게 설정하여, 대부분의 시간은 무소음 상태로 있게 됩니다. 또한 무소음 위해 케이스 팬 역시 정지 상태로 두었습니다.

CPU 온도는 아이들 50도, 풀로드 65도 입니다.

케이스 팬 작동시 온도가 10도 정도 하락되며, 현재 겨울이라 걱정이 없지만, 여름에는 케이스팬에 저항을 달아 저소음으로 운용할 계획입니다.

저전력

인스펙터2로 실제 소비전력을 체크하였습니다.

아이들 12w, 풀로드 17w

HDD 작동시 +5w

키보드, 마우스 연결시 +3w

평균 15w 를 사용한다고 하여도, 월간 12.96kw의 전기를 사용하며, 누진구간 400kw에서 월4,750원의 전기요금이 예상됩니다. 그러나 새벽에 자동 시스템 OFF, WOL(원격컴퓨터켜기) 등을 적극 활용하면 전기요금은 걱정할 수준은 아니라 생각됩니다.

CPU, 메인보드의 선택

요즘 구매하시는 분들 중 가장 큰 고민은 J1900의 후속 모델인 N3150이 소비전력은 비슷한데 성능은 10%정도 떨어진다는 것입니다. 게다가 국내 ASrock J1900 제품은 벌써 단종.

	J1900	N3150
CPU 성능	1	0.9
GPU 성능	1	2.3	N3150의 유일한 장점은 이것입니다. 4K 고화질 영상도 무리없이 재생가능하다고 합니다. HTPC (TV에 연결해서 동영상 시청용으로 쓰이는 PC) 로 쓴다면 두말 할 것없이 N3150 입니다.
SATA	SATA2	SATA3	J1900은 SATA2 (3gb/s) 밖에 지원이 안되기 때문에 SSD성능이 100% 쓸 수 없는 문제가 있습니다. (그렇다고 HDD를 쓰는것보다는 훨씬 빠릅니다.)
최대메모리	8G	16G
소비전력	1	1	CPU스펙상 TDP는 J1900 10w, N3150 6w 이지만 많은 리뷰에서 두 CPU의 실제 전력소모차이는 거의 없는 것으로 나타났습니다. 심지어 와트당 성능에서 조차 J1900이 약간 우세합니다.

사실 N3150 라인업에서 J1900과 동일한 CPU 성능을 가진 N3700 모델이 있으며, 미국 아마존 직구를 하더라도 총비용이 13만원 정도로 큰 차이가 없습니다만, 가장 큰 문제는 A/S입니다. NAS 특성상 사용시간이 길어질 수 밖에 없는데 국내 정식유통제품의 경우 3년이 무상 A/S라는 든든한 보험이 존재합니다.

J1800, N3050은 듀얼코어 제품으로 성능이 매우 떨어져 후보에 조차 올리지 않았습니다.

현재(2015년 11월) 국내에서 구매할 수 있는 메인보드는 총 3개로,

ASrock N3150-ITX, Gigabyte J1900N-D3V, ASUS J1900I-C 입니다.

판매순위는 ASrock N3150이 압도적으로 많습니다만, 저는 Gigabyte J1900을 선택했습니다. 그 이유로는 NAS 구축전제가 철저하게 성능과 저전력 때문이었습니다. 와트당 CPU성능이 떨어지는 N3150은 단순 성능만 10% 부족한 것이 아닌 같은 처리를 하더라도 전기를 더 먹고 더 열이 많아지는 복합적인 문제가 발생하기 때문입니다.

Gigabyte제품과 ASUS제품과도 고민을 했는데, Gigabyte J1900N-D3V는 독특하게도 산업용으로 나온 보드입니다. 일반인이라면 절대 쓸 일이 없는 시리얼포트가 2개나 장착되어있고, 랜포트도 2개가 장착되어있습니다. 이러한 것이 필요해서 구매한 것은 아닙니다만, 산업용이란 본래 매우 혹독한 환경 (먼지많고, 24시간 가혹하게 작동) 에서 쓰는 것을 전제로 만들어진 제품입니다. 즉 산업용인데도 무상AS 3년 보증은 어느정도 튼튼하게 만들지 않았나 하는 근거없는 믿음으로 선택하였습니다.

다음은 CPU와 메인보드 선택에 중요한 참고가 되었던 리뷰, 벤치자료 입니다.

베일트레일, 브라스웰, AMD 카비니까지 심도있게 벤치마킹한 리뷰입니다.

http://www.hardware.fr/articles/936-1/celeron-n3150-pentium-n3700-braswell-test.html

메인보드 중심으로 벤치마킹한 리뷰입니다.

http://uk.hardware.info/reviews/5651/12-amd-am1--intel-bay-trail-motherboard-review-budget-foundation

SSD, HDD

NAS에 SSD까지 설치할 필요가 있을까? 고민이 되었습니다. 소음과 전력소모의 주 원인이 되는 HDD를 가능한 많이 절전상태로 만들기 위해서는 OS를 HDD와 분리 시키는 것이 중요했습니다. 5W나 되는 하드를 더 많이 절전 상태로 둘수록, 전기소모, 발열, 소음, 성능 모든 부분에서 플러스 효과가 나타납니다.

HDD의 소음은 저가 케이스일 수록 HDD가 직접적으로 케이스 철제 프레임에 고정되어, 연결나사를 통해 케이스 전체에 퍼져 소음이 증폭하는 효과를 가져오기 때문에 더욱 소음이 크게 들릴 수 있습니다. 따라서 HDD 소음을 줄이는 가장 첫번째 조건은 HDD를 케이스에 직접 나사로 고정하지 않는 것이며, 진동을 흡수할 수 있는 실리콘이나 고무, 스폰지 등으로 고정시키는 것이 중요합니다. 물론 발열도 중요하기 때문에 무작정 하드를 감싸놓는 것은 절대 하지 말아야 합니다.

출처 : http://comfixlog.tistory.com/21

mysql이 cpu를 많이 점유하고, DB와의 연결상태가 좋지 않을때

JAESOO — Tue, 05 Jul 2016 09:28:45 +0000

mysql 이 cpu를 꾸준히 점유하고 있으며, 서버의 부하도 많이 발생한다....
물론 log 를 확인하는 방법이 가장 기본적으로 해야할 일이다. 그리고 혹시 slow query 가
얼마나 쌓이는지 확인
해 보는것도 좋다.
그리고 mytop 이나 mysqlreport 등의 실시간 모니터링 프로그램을 이용할 수도 있다.
* slow query 에 관해 간단히 알아보면 다음과 같다.
: slow query 란 DBMS 가 client로부터 요청받은 query를 수행할때 일정시간 이상 수행
되지 못한 query를
칭하는 것으로 slow query 가 많다면 당연히 성능저하가 발생된다.
mysql 을 사용할때 mysqld 가 cpu를 유난히 많이 점유한다거나 DB의 접속이 원활하지
않다면
slow query를 이용하여 원인 분석에 도움이 될 수도 있다.
log 를 쌓이게 하기 위해 mysqld 실행시에 다음 옵션을 함께 추가하거나, my.cnf 파일을
직접 수정하여
mysqld 를 실행할 수도 있다.
1) mysqld 작동시 slow query 옵션 추가
#]/usr/local/mysql/bin/mysqd_safe --log-slowqueries=/
usr/local/mysq/data/mysql_slow.log &.....
2) my.cnf 수정
#]vi /etc/my.cnf
log_slow_queries=/usr/local/mysql/data/mysql_slow.log => 로그 저장 경로
long_query_time=1 => 쿼리가 2초이상 지속될때 로그에 기록
* cache size 수정하기
set-variable = query_cache_size = 100M : 100M 로 cache size 수정
cache 수정후 mysql prompt 상에서 다음과 같이 확인 가능
mysql> use mysql;
Database changed
mysql> show global status like '%Qcache%';
+-------------------------+----------+
| Variable_name | Value |
+-------------------------+----------+
| Qcache_free_blocks | 13 |
| Qcache_free_memory | 33384736 |
| Qcache_hits | 283 |
| Qcache_inserts | 156 |
| Qcache_lowmem_prunes | 0 |
| Qcache_not_cached | 6 |
| Qcache_queries_in_cache | 37 |
| Qcache_total_blocks | 106 |
+-------------------------+----------+
8 rows in set (0.00 sec)
mysql> show global variables like '%query_cache%';
+------------------------------+----------+
| Variable_name | Value |
+------------------------------+----------+
| have_query_cache | YES |
| query_cache_limit | 1048576 |
| query_cache_min_res_unit | 4096 |
| query_cache_size | 33554432 |
| query_cache_type | ON |
| query_cache_wlock_invalidate | OFF |
+------------------------------+----------+
6 rows in set (0.00 sec)
slow query가 쌓이도록 수정후 정상적으로 적용되었는지 확인하기 위해 mysql
command prompt 에서
다음과 같이 실행한다.
#mysql>show global variables WHERE Variable_name LIKE ‘l%’;
+———————————+—————————+
| Variable_name | Value |
+———————————+—————————+
| language | /usr/share/mysql/korean
| large_files_support | ON |
| large_page_size | 0 |
| large_pages | OFF |
| license | GPL |
| local_infile | ON |
| locked_in_memory | OFF |
| log | OFF |
| log_bin | OFF |
| log_bin_trust_function_creators | OFF |
| log_error | |
| log_slave_updates | OFF |
| log_slow_queries | ON |
| log_warnings | 1 |
| long_query_time | 3 |
| low_priority_updates | OFF |
| lower_case_file_system | OFF |
| lower_case_table_names | 0 |
+———————————+—————————+
이제 쌓이는 log를 확인하여 어디에서 문제가 발생되는지 확인하고, 이를 수정해야 할 것
이다.
/usr/local/mysql/data/mysql-bin.00000 슬로우쿼리를 slowquery.log 에 덤프하여 저장
ex)/usr/local/mysql/bin/mysqldumpslow -v /usr/local/mysql/data/mysql-bin.00000
> slowquery.log
* 참고 mysql 명령어
extended-status MySQL : 데이터베이스의 현재 상황을 보여준다.
flust-hosts : MySQL에 캐시된 모든 포스트를 초기화한다.
flust-logs : MySQL의 로그 파일을 새로 작성하며 초기화한다.
flust-status : MySQL의 상태정보를 초기화한다.
flust-tables : MySQL에 캐싱된테이블 정보를 초기화한다.
flust-thread : 쓰레드 캐시에 저장된 쓰레드를 초기화한다.
flust-privileges : 권한정보 테이블을 다시 읽는다.
kill id : 특정 MySQL 프로세스를 죽인다.
Processlist : 현재 MySQL 프로세스 목록은 본다.
Refresh : 현재 캐시되어 있는 모든 테이블을 초기화하고 log 파일은 새로 만든다.
Variables 설정 가능한 모든 변수를 보여줍니다.
SHOW VARIABLES
MySQL은 설정 가능한 값들을 엄청나게 많이 가지고 있으며 SHOW VARIABLE 명령을
통해 현재 설정되어 있는 모든 값을 볼 수 있다. <화면 1>은 SHOW VARIABLES로 통해
살펴본 설정이다.
SHOW VARIABLES로 볼 경우 총 207개 정도의 변수가 표시된다. 오히려 너무 많아서 원
하는 값을 찾기가 힘들 정도이다. 그래서 SHOW VARIABLES 명령 뒤에 LIKE ‘%키워드%
’를 사용하면 원하는 값만을 볼 수 있다.
SHOW STATUS
MySQL은 내부적으로 동작 상황에 대한 실시간 통계 정보를 가지고 있다. SHOW
STATUS는 이러한 통계 정보를 보기 위한 명령이다. 모니터링할 때 가장 기본이 되는 것
이 바로 앞에서 설명한 SHOW VARIABLES의 정보와 SHOW STATUS의 정보이다. 웹
기반의 모니터링 툴을 비롯한 각종 모니터링 툴들이 바로 이 두 명령어를 통해 나온 정보
를 조합해 사용하는 것이다. SHOW STATUS도 SHOW VARIABLES와 마찬가지로 LIKE
‘%키워드%’ 사용해 원하는 값만을 볼 수 있다.
SHOW PROCESSLIST
현재 동작하고 있는 MySQL 데이터베이스 서버의 동작중인 모든 쓰레드와 유저 커넥션 정
보를 보기 위한 명령어이다. 이를 통해 얻어진 정보로 시스템 자원을 지나치게 많이 사용
하거나 잘못된 수행을 하고 있는 프로세스를 죽일 수 있다.
SHOW TABLE/TABLE STATUS/INDEX/INNODB STATUS
SHOW TABLE 명령은 현재 데이터베이스에 존재하는 테이블에 대한 기본적인 정보를 보
여주며 SHOW TABLE STATUS는 각 테이블의 생성 일자, 테이블 크기, 인덱스 크기 등
구체적인 정보를 보여준다. 하지만 이 때 주의할 점이 하나 있는데 바로 SHOW TABLE
STATUS의 경우 테이블의 스토리지 엔진이 MyISAM인 경우에만 정확한 정보를 표시하
며 InnoDB의 경우에는 부정확한 정보를 보여준다는 것이다. InnoDB 스토리지 엔진으로
되어 있는 테이블은 SHOW INNODB STATUS로 구체적인 정보를 확인할 수 있으며
SHOW INDEX를 통해 테이블의 인덱스에 대한 각종 정보를 볼 수 있다

출처 : http://egloos.zum.com/hanaduri/v/2271320

파일질라(filezilla) 디렉터리 목록 조회 실패

JAESOO — Fri, 01 Jul 2016 10:59:21 +0000

파일질라를 잘 사용하고 있었는데,

갑자기 디렉터리 목록 조회 실패로 연결이 안됨.......

거의 반나절 고생.......

쩜 자존심에 상처....

네이버, 구글링. 총 동원....

대부분 이럴 때 권장하는 방법은 두 가지..

1. 파일질라 : 편집 > 설정 > FTP > 전송모드 능동형으로

2. 자신(ftp client pc)의 컴퓨터 : 시작 > 제어판 > 윈도우방화벽 > 고급설정 > 인바운드 > 추가 > ftp client 프로그램 추가

쩜.. 이래도 해결이 안되었다..

결국 해결 방법은

File Zilla Server Interface -> Connect to Server -> FileZilla Server -> Edit -> Settings -> Passive mode setting을 아래 그림처럼..

Use custome port range 에 체크하고, 5000 ~ 5009 지정..

그리고, 서버 IP가 내부 아이피인 경우

IP4 specific을 지정된 아이피로 설정(180.182.51.50 말고, 각자 서버 IP로 지정해 주세요.)

그리고, 방화벽에서 아래의 그림처럼, 5000에서 5009번까지 포트 개방

그리고, 마지막으로 클라우드 서버를 사용한다면,

Port Forwarding에서도 해당 포트(5000~5009번) 개방(이 부분은 클라우드 서버를 사용하지 않으면 무시)

결국 해결...

아~ 시간은 다 가고, 상처뿐인 영광...

부디 파일질라(FileZilla)를 사용하시는 많은 분들도

고생하지 말고, 해결하시기를~~

출처 : http://blog.naver.com/PostView.nhn?blogId=ntzkimy&logNo=50177662300

마이크로소프트 오피스 제품군 완전 삭제 방법

JAESOO — Fri, 01 Jul 2016 10:55:23 +0000

마이크로소프트 오피스 제품군 완전 삭제 방법

오피스 2003, 2007, 2010, 2013, 365 업그레이드나 신규 설치시 문제가 생겨서 설치가 중간에 멈추거나

하는 경우에 설치가 안되는 경우가 종종 있습니다.

이런 경우에 오피스를 완전 걷어 내고 새로이 설치를 해야하는데.. 그럴때 사용하는 도구입니다.~

Ms 에서는 이미 이 문제에 대해서 예전부터 알고 있었던듯 싶네요..

Microsoft Office 2013, office 365 제품군을 제거하는 방법 : http://support.microsoft.com/kb/2739501/ko

아래 파일을 저장한다음 실행(더블클릭) 실행하셔도 됩니다.

O15CTRRemove.diagcab

Microsoft Office 2010 제품군을 제거하는 방법 : https://support.microsoft.com/ko-kr/kb/971179

아래 파일을 저장한다음 실행(더블클릭) 실행하셔도 됩니다.

윈도우 7이하 : office2010-win7.msi

윈도우 8 : office2010-win8.diagcab

Microsoft Office 2007 제품군을 제거 하는 방법 : https://support.microsoft.com/ko-kr/kb/971179

아래 파일을 저장한다음 실행(더블클릭) 실행하셔도 됩니다.

윈도우 7이하 : office2007-win7.msi

윈도우 8 : office2007-win8.diagcab

Microsoft Office 2003 제품군을 제거 하는 방법 : https://support.microsoft.com/ko-kr/kb/971179

아래 파일을 저장한다음 실행(더블클릭) 실행하셔도 됩니다.

윈도우 7이하 : office2003-win7.msi

윈도우 8 : office2003-win8.diagcab

출처 : http://blog.daum.net/sdenver/423

프로세스 BRR, PI, BPM, PS 등 개념부터 명확히

JAESOO — Tue, 24 May 2016 17:03:00 +0000

기업의 모든 활동은 프로세스가 아닌 것이 없다.
결과를 만들어 내는 과정, 즉 프로세스의 중요성은 더할 나위 없이 강조되고 있다. 프로세스가 강조되는 만큼 프로세스의 관리나 혁신에 관련한 개념이 혼용되거나 오용되고 있는 것이 현실이다.

산업계에서 혼재되고 있는 프로세스 관리와 관련한 용어는 개념적 차이가 있지만, 연계성을 가지고 있다. 원조격인 BPR(Business Process Reengineering)과 PI(Process Innovation), 가장 최근에 등장한 개념인 BPM(Business Process Management), 그리고 업무매뉴얼로 연상되는 프로세스 표준화 PS(Process Standardization) 등이 바로 그것이다.

• BPR

1990년 7월 마이클 해머가 하버드비즈니스리뷰에 발표한 ‘자동화하지 말라, 모든 것을 폐기하라(Reengineering Work : Don’t automate, Obliterate)’라는 논문에 처음 리엔지니어링(Reengineering)이라는 개념을 소개했다.

그는 ‘경쟁우위 확보를 위해 기업의 핵심부문에서 비용, 품질, 서비스, 스피드와 같은 요인의 획기적 향상을 이룰 수 있도록 프로세스를 근간으로 비즈니스 시스템을 근본적으로 재설계해 극적인 성과를 추구하는 것’이라고 BPR을 정의했다. 모든 것을 폐기하라는 선동적 주장처럼 BPR은 신기술이 도입될 때 백지상태에서 일하는 방식, 업무 지원 시스템, 수행 조직 등의 전면적 리엔지니어링을 주장한다.

이 개념은 1990년대 중반까지 많은 호응을 얻으며 기업의 물리적 구조조정 근거가 되기도 했지만, 현재는 호응도가 현저히 낮아졌다. 이에 대해 전문가들은 결국 업무를 추진하고 있는 사람(Human ware)이 리엔지니어링의 결과로 제시된 전면적 변화를 수용하는데 한계가 있음이 지적된다. BPR를 통한 새로운 업무 프로세스를 설계할 때 개선된 프로세스가 기존 프로세스 보다 확실히 나은 성과를 도출할 수 있다는 객관적 증거를 제시하기 힘들어 이에 대한 조직원의 반발, 그리고 급진적 변화(Big Bang)에 의해 새롭게 제시된 시스템과 업무절차에 대한 조직원의 부적응 등을 들 수 있다.

• PI

PI의 주창자인 토마스 데이븐포트는 마이클 해머와 거의 같은 시기인 1990년 프로세스 지향에 관한 논문과 1993년 저서인 ‘Process Innovation’에서 PI라는 용어를 사용하기 시작했다.

BPR와 PI는 급진적 변화를 주장한 만큼 개념간 큰 차이가 있지는 않다. 하지만 광의의 PI, 즉 문자 그대로 프로세스 혁신의 개념으로 이해한다면 BPR의 Zero based thinking 뿐만 아니라 기존 프로세스를 인정하고 그 위에 점진적 변화를 추구하는 일련의 프로세스 개선활동까지 포함하는 개념에서 차이가 있다고 할 수 있다.

국내 산업에 PI가 널리 퍼진 것은 2000년 초 포스코의 ‘ERP based PI’가 큰 반향을 일으키게 되면서부터이고, 철강뿐 아니라 조선, 전자, 금융 등 다양한 산업분야에서 ERP based PI가 추진됐다.

이로 인해 국내에서는 PI하면 ERP Based PI를 떠올리는 경향이 있다. 이는 ERP 패키지내 선진 프로세스를 그 기업의 추구하는 To-Be Process 인정하고 PI를 추진하는 하나의 방법론에 불과한 것이며, 그 기업에 대한 최적의 프로세스를 설계하고 이를 독자적인 전사업무관리시스템을 구축하는 방법을 택하는 기업들도 있다.
BPR이든 PI든 급진적 변화에 대한 위험성이 강조되면서 기존 업무 프로세스의 자산적 가치를 일정 부분 인정하는 분위기로 변화되는 되고 있는 추세다.

• BPM

BPM은 현재까지 그 개념 정의가 진행중이라 할 수 있다. 일반적으로 BPM은 ‘프로세스를 발견, 설계, 적용, 실행, 상호작용, 운영, 최적화 및 분석하는 종합적인 역량’을 의미한다.

하지만 BPM이 ERP의 비유연성을 극복하기 위해 주목받기 시작했기 때문에 ‘프로세스 자동화를 구현하는 BPMS라는 Application을 통해 기업의 프로세스를 관리하는 활동’이라는 지극히 IT적 관점에서 정의된다. 실질적으로 국내 기업들에게 전달되는 BPM은 IT관점에서 내린 후자의 정의에 더 가깝다.

개념상에서 BPM이 BPR이나 PI와 가장 큰 차이점은 이미 소유하고 있는 비즈니스 자산과 기술자산의 가치를 인식하고 이들의 활용을 추구하며 점진적 변화를 추구한다는 점이다.

ERP based BPR을 추진한 기업은 환경변화에 따라 민첩하게 프로세스를 변경하고 적용시킬 수 있는 시스템 지원도 부족했고 새로운 프로세스에 따른 새로운 Application의 추가 개발도 제한적이었다. 또 새로운 환경변화에 따른 전략의 변화와 프로세스의 변경·추가에 의한 성과지표 관리도 어려웠고 급격히 변화된 작업환경에 적응하기 위한 조직원들의 많은 반발과 저항도 극복해야 했다.

이같은 문제점들을 극복하기 위한 대안으로서 Workflow(프로세스에 따른 업무 처리), EAI(기업내 서로 다른 IT Application 통합을 통한 호환성 확보), BAM(Business Activity Monitoring, 프로세스 관련 성과지표관리) 등의 기능이 통합된 BPMS 구축을 통해 프로세스의 상시적 관리와 분석, 그리고 점진적 개선을 추구하게 된 것이다. 하지만 현재까지의 BPMS는 업무 성격에 따라 부문적용되고 있으며 시스템과의 연동과 프로세스 변경에 대한 유연성 측면에서 기술적 문제를 드러내고 있는 측면이 있다.

• 프로세스 표준화

기업의 최종 아웃풋인 상품·서비스의 문제는 산출물까지의 프로세스 문제로 인해 발생되는 하자가 90% 이상임을 주목하고 프로세스 관리(Process Management)의 중요성이 부각되기 시작했다. 이를 위해 기업이 프로세스 관리를 시작하고자 한다면 그 기업의 프로세스가 어떻게 생겼는지 알아야 하고(프로세스 가시화), 이의 관리를 용이하게 하기 위한 표준 버전이 필요하게 된다. 이것이 프로세스 표준화(PS)가 탄생한 배경이다.

프로세스 표준화는 ‘전사의 각 프로세스들에 대한 기준을 정하고 해당 프로세스들의 다양한 버전에 대해 어떤 것을 기준으로 삼을지 결정하는 것으로 각 사업부별 다른 프로세스들중 비슷한 프로세스들은 통합하고, 통합된 몇 개의 프로세스를 표준 프로세스로 지정해서 관리하는 것’이라고 정의할 수 있다.

BPR 및 PI와 중요한 개념 차이는 프로세스의 혁신을 위한 표준화가 아닌 프로세스의 관리를 위한 자산화라는 점이다. 표준화 이후 6시그마, Lean, Work-Out 등 일련의 사내 개선활동을 통해 점진적 개선을 추구하게 되며 이 개선결과를 표준프로세스에 반영해 장기적으로 기업에 가장 적합한 프로세스 체계를 구축해 나가는 것이다.

이 프로세스 표준화는 BPM의 점진적 개선의 철학과 함께 하며 실질적으로 BPM의 첫단계인 프로세스 가시화 및 자산화와 같은 개념이라 할 수 있다.

프로세스에 대한 이 4가지 개념은 서로 다른 것 같지만 다르지 않다.
기업의 전략적 판단 아래 급진적 변화를 도모할 수도 있고 점진적 변화를 도모할 수도 있기 때문이며, 또 급진적 변화를 택했다고 해도 이후에 지속적으로 점진적 개선을 포함한 프로세스의 상시 관리가 요구되기 때문이다.
이에 KMAC는 프로세스 성과관리, 프로세스 성숙도 진단 등의 프로그램을 통해 한국산업의 프로세스 혁신을 선도하고자 한다.

[문의]
KMAC 경영전략BU 경영전략3팀 황현철 팀장
☎ 02-3786-0660

용량 산정 (동시 접속자 계산)

JAESOO — Wed, 04 May 2016 20:41:09 +0000

= 동시접속자수, 서버용량, 로드 밸런싱

회선 대역폭 이용한도란 미디어호스팅 고객사이트에서 다운로드 전송되는 동영상 데이터로인해 발생하는 회선트래픽의 양을 의미합니다. 아래 예제는 동시접속자와 예상 대역폭을 계산하였습니다. 즉, 고객님의 홈페이지에서 한개의 동영상을 대상으로 최대 몇명의 동시 접속자가 발생하는지를 예상하여 서비스를 선택하실 수 있습니다.

예)300Kbps로 인코딩된 동영상 파일을 10명이 동시에 예) 감상하는 경우

..- 300Kbps × 10명 = 3,000Kbps = 3M bps

..- (bps = bitper second : 초당 전송 바이트수)

..- 만일 한개의 사이트에 위와같은 동영상이 10개가

..- 동시에 서비스된다면 전송량은 10배가 됩니다.

동시접속자수는 웹서버에 최근 10초 사이에 서비스요청이 있었던 사용자를 접속중인 사용자로 보아 계산한다.

서비스요청 제한수는 추후에 웹서버의 성능 테스트 결과에 따라 변경할 수 있다.

동시접속자수(천 분의 1초 사이에 동시에 request를 보내는 사용자수) 40명이라는 안정적인 수치를 확보하였다.

시스템의 운영중에 이를 초과하는 접속자수의 급격한 증가로 네트워크 트래픽이 발생하면 이를 위해서는 서버에

연결되어 있는 전용선의 용량을 증대시켜 속도개선을 취해야 한다.

=====================================================

(급) 웹서버 구축시 동시 가능 접속자수 예상법

=====================================================

웹서버 구축시 (intel Xeon 2.4Ghz, win2000, IIS서버) 서버가 얼마만큼의

동시 가능 접속자를 서비스 할 수 있을까요?

-> 일반적으로 IIS 의 경우 커넥션 수를 대략의 폭만 정하고 있습니다.

그렇기 때문에 CPU 나 RAM 등의 사양에 따라 상이하게 틀려질수 있습니다.

그리고 Xeon cpu 를 사용 하고 계시는데 이xeon cpu 의 경우 하이퍼쓰레드 를

지원 합니다. 그러나 win2k 는 완벽히 지원을 하지 못합니다.

이것이 첫번째 이유 입니다.

두번째 이유 입니다.

구성을 계획하고 계시는 사이트 의 DB 커넥션 수라던지 소스의 크기 그리고 가져가는 소스 들의 사이즈 에 따라 성능이 틀려 집니다.

세번재 이유 입니다.

사용 하실수 있는 트래픽의 대역폭이 어떻게 되는 건가요?

그 한계를 끌어 들였을때 동시에 값을 계산을 하여야 합니다.

apache web server 의 경우는 일반적인 지원 커넥션이 256 이고 컴파일을 하면서 옵션을 주며 1024 이 되는걸 알고 있습니다.

그런데 IIS 상에서는 대역폭 설정만 있으며 그 값이 세분화 된것이 아니며

그냥 10만 이하 이상 등의 방법으로 하고 있습니다.

일반적인 사이트 의 경우 동시 접속은 100을 넘는 경우가 드물며.. 활성화된 동호회 사이트 는 1000정도 그리고 잘나가는 게임 사이트 등 초대형 사이트 들은 1 만 에서 10만 정도로 알고 있습니다.

이 서버들이 부하를 못견디는건 웹서비스 가 아닌 DB 커넥션과 소스 의 입출력이 되는

트래픽 입니다.

시물레이션 할 수 있는 방법 또는 평균 예상치(벤치마크) 있나요?

-> 답이 되셨을지...

======================================================

서버용량

======================================================

우선 한게임 싸이트는 일반 웹서비스와 차원이 다릅니다..

각 유저마다 서버가 접속해 있는지 아닌지를 항상 확인하는 데몬(혹은 세션) 이 떠 있어야 하는데..

이것은 즉.. 각 사용자에게 최소한의 패킷 과 메모리가 ( 한 100 bit 쯤 되지 않을까..? ㅡㅡ^ )

할당 되어 있어야 한다는 뜻이죠.. 즉 서버가 엄청난 고사양이어야 한다는 것입니다.

그런데 그것도 한계가 있습니다.

라인 용량의 한계요...결국에는 그래서 서버수를 늘리는 거죠...

모르긴 몰라도 한게임 은.. 한 서버당 최대 수용이 800 정도가 아닐까 하는

개인적인 생각을 가지고 있습니다.

암튼,

님이 말씀하시는 싸이트의 성격이 어떤 서비스를 하려는 곳인지는 잘 모르겠지만,

우선 제 경험 상으로는.. [ 제가 운영하는 곳은 쇼핑몰입니다.]

동시 접속자 수가 편균 3000 입니다.

최대 수용은 4000 정도가 되죠..

웹서버 3 대와 관리자서버 1 대 , 파일서버가 1 대, 디비 서버가 1 대죠..

일반적으로 이렇게들 생각하실겁니다..

"아니 그럼 웹서버 한대가 1000 ~ 1400 을 커버 한단 말야..? "

가능합니다 충분히....더 할 수도 있습니다.

문제는 위에 말씀드렸던 세션 부분과 메모리 할당은 어떻게 최소화 할 것이냐와

네트워크를 오가는 패킷[데이타] 를 어떻게 최소화 할 것이냐의 문제..

그리고 데이터 베이스와의 통신의 양을 가장 적게 할 수 있는 방법들을 살펴 보면 가능합니다...

즉 시스템의 튜닝 뿐 아니라 돌아가는 프로그램의 [ 그것이 웹서비스던, 아니던간에~!!]

튜닝도 같이 이뤄져야 한다는 것을 의미합니다.

서버가 100 Mbps 의 라인을 이용하고 있다고 칩시다.

이론적으로 100 Mbps 지만.. 실제로는 네트웍이 30Mbps ~ 35Mbps 면 잘 나오는 겁니다.

그러면 봅시다...

한 서버가 초당 내보낼수 있는 라인의 용량의 한계가 35Mbps 라고 한다면..

동시접속자수가 1000 명이라고 할때..

한명당. 35 Kbps 정도가 한계라는 거죠...

또한 아마 저정도면 웹서비스 데몬이 적어도 메모리를 2 Giga 는 되야 할겁니다.

결론은 총체적으로 여러가지 부분에서 선행되어야 하는 문제들이 있지만.

그냥 기본적으로 생각할때..

동시 접속자 수가 5000 정도라고 한다면..

약 서버 5 대 정도와 디비 1 대 정도라고 말씀드릴수 있겠습니다.

( 그외에 관리서버 , 파일 서버, 백업서버, L4 스위치 등등 머 따지구 들자면 끝없지만..)

참고로 저희 사양을 말씀드리면..

웹서버,관리,파일 서버는 2 CPU/2 Giga

디비서버는 4 CPU/8 Giga 입니다..

답변이 되셨을지 모르겠네요

======================================================

동시접속자수 부하에 견디는 하드웨어

======================================================

안녕하세요. AnyMOS 서버팀 입니다.

저희가 가장 어려워 하는 질문이네요...

일반적으로 저희 Q&A를 살펴 보시면 아시겠지만 어느 특정한

서버를 놓고 '이 서버는 몇명의 동시접속자를 수용 할 수 있습니다.'

라고 하는 것은 옛날 서버가 귀하던 시절의 영업 방식입니다.

그러므로 정확한 답변은 드릴 수 없다가 저희가 드릴 수 있는 답변

이고요. 이 부분은 저희와 이상환님의 검증아래 가장 근접한 데이터를

수집하는 것으로 일을 시작해야 합니다. 일반적으로 포털 사이트인

경우 왭서버의 경우엔 시스탬의 부하량 보다는 네트웍의 부하가 우선시

됩니다. 즉 네트웍 대역폭이 받처 주는 상황에서 서버를 선정 하는 것

이 순서입니다. 기본적인 스팩의 서버로 유저들이 접속 할 경우에 대한

CPU점유률 메모리 사용량 등등을 계산하여 하나의 서버가 처리 할 수

있는 용량을 염두해 두시고 필요한 수량을 선정 해야 합니다.

이전에는 접속자가 많은 대형 포탈 서비스 업체인 경우 엔터프라이즈급

의 서버를 많이 선호 하였으나 요즘은 저가 사양의 서버에 사용자의

수에 따라 유연하게 대처 할 수 있는 로드발란싱 기술을 좀 더 선호

하고 있는 추세 입니다. 오버 사이징으로 인한 비용 낭비를 막고

하나의 서버에 집중화 시켜 부담을 주기 보다는 하드웨어나 소프트웨어

적인 결함을 유연하게 대처 할 수 있는 설계가 환영 받고 있죠.

어느정도 답변이 되셨을지 궁금하네요.

혹시 저희 AnyMOS의 제안에 동의 하셨다면 연락 부탁 드리겠습니다.

저희 AnyMOS에서는 고객사가 보다 정확한 서버를 선정하기 위해 필요

로 하는 장비들을 지원해 드리고 있습니다. 물론 비용은 들지 않습니다.

감사합니다.

======================================================

로드 밸런싱을

======================================================

(3) 세션 관리

* 기본적으로 세션 관리 기능 제공

* 세션때문에 관리와 배포가 힘든 경우도 있는데, 대규모 사용자가 있을 경우에는

세션 정보 자체가 오버헤드가 될 수 있고, 로드 밸런싱을 할 때 문제가 발생할 수 있다.

session 객체는 메모리 안에 생성된 객체이기 때문이다. 이 문제는 특정 브라우저를

특정 서버와 통신하도록 로드 밸런싱 서버를 설정함으로써 해결할 수 있기는 하지만,

해당 서버가 다운 되는 등의 경우는 Session Migration을 해주어야 한다.

출처 : http://nimba.tistory.com/m/entry/%EB%8F%99%EC%8B%9C%EC%A0%91%EC%86%8D%EC%9E%90%EC%88%98-%EC%84%9C%EB%B2%84%EC%9A%A9%EB%9F%89-%EB%A1%9C%EB%93%9C-%EB%B0%B8%EB%9F%B0%EC%8B%B1

=나의 웹서버는 얼마나 튼튼한가?

이 문서는 웹서버를 운영하면서 자신의 웹서버가 어디까지 버틸수있는지 웹서버의 임계치를 유추해내는 방법에대한 문서이다. 자 이제부터 내 웹서버는 어디까지 버틸수있을지를 실험해보자.

작성자 : 김형채

작성일 : 2005년 6월

1. 서문

리눅스를 설치하면 대부분 웹서버를 많이 설치한다. 그냥 모르고 설치하는 사람도 있고 개인적은로 웹서버를 운용하기위해서 설치하기도 하고, 공부를 위해서 설치하기도 하는등 다양한 이유로 웹서버는 설치된다.

이 문서는 나의 하드웨어 사양에서 내가 설치한 웹서버의 능력을 알려고 하면 어떻게 해야할까에서 시작된다. 같은 페이지가 보인다고 해서 같은 성능은 아니다. 이제부터 내 웹서버의 성능이 어디까지 나오는지를 테스트해보기로 하자.

2. 테스트를 위한 프로그램

웹서버의 성능 테스트를 위해서는 아래의 프로그램 들이 필요하다.

◆ 웹서버 - 이것은 당연히 설치가 되어있다고 가정한다.

◆ httperf - 웹서버에 부하를 주면서 성능을 측절하는 프로그램이다.

◆ idleconn - Idle connection 을 만들어 주는 프로그램이다. 동시접속자의 상황을 만들수있다.

httperf & idleconn

httperf 는 아래의 주소에서 다운로드 받을수 있으며 설명서도 제공되므로 참고하기 바란다.

http://www.hpl.hp.com/research/linux/httperf/

ftp://ftp.hpl.hp.com/pub/httperf/

wget 을 이용해서 다운로드 받는다

[root@ns src]# wget ftp://ftp.hpl.hp.com/pub/httperf/httperf-0.8.tar.gz

--15:31:03-- ftp://ftp.hpl.hp.com/pub/httperf/httperf-0.8.tar.gz

=> `httperf-0.8.tar.gz'

Resolving ftp.hpl.hp.com... 192.6.19.21

Connecting to ftp.hpl.hp.com[192.6.19.21]:21... connected.

anonymous로서 로그인하고 있습니다...로그인 했습니다!

==> SYST ... 완료. ==> PWD ... 완료.

==> TYPE I ... 완료. ==> CWD /pub/httperf ... 완료.

==> PASV ... 완료. ==> RETR httperf-0.8.tar.gz ... 완료.

길이: 146,107 (unauthoritative)

100%[===============================>] 146,107 73.21K/s

15:31:07 (73.06 KB/s) - `httperf-0.8.tar.gz' saved [146,107]

다운받은 파일의 압축을 해제한다

[root@ns src]# tar -xvzf httperf-0.8.tar.gz

httperf-0.8/

httperf-0.8/timer.h

httperf-0.8/core.c

httperf-0.8/httperf.c

httperf-0.8/core.h

httperf-0.8/event.h

------- 중략 --------

httperf-0.8/config.guess

httperf-0.8/aclocal.m4

httperf-0.8/idleconn.c

[root@ns src]#

일반적인 소스 설치 방법대로 아래 과정을 수행해서 설치해준다.

./configure

make

make install

동시접속자를 만들기 위한 idleconn은 설치시에 복사되지 않으므로 수동으로 복사해준다.

[root@ns httperf-0.8]# cp idleconn /bin/idleconn

3. 성능측정

자 이제 설치를 모두 마쳤으면 성능을 측정해 보기로 하자.

테스트는 일단 idleconn을 이용하지 않은 상태에서 테스트하고, idleconn을 이용해서 접속자를 많이 생성한후에 한번 진행해 보기로 하자.

httperf의 각 옵션은 다음과 같다.

--server 서버주소 : 여기에 적어 준 서버로 접속을 시도하게 된다.
--port 숫자 : 여기에 적어 준 포트로 접속을 시도하게 된다. 웹서버는 기본적으로 80번 포트를 사용하지만 정확한 측정을위해서는 8080등의 포트를 이용할 것을 권장한다. (측정중 일반 사용자의 접속이 있으면 결과가 제대로 나오지 않기 때문이다.)
--num-conns 숫자 : 서버로 총 몇개의 접속을 만들 것인지를 결정한다.
--rate 숫자 : 1초에 몇개의 접속을 만들 것인지를 결정한다.
--timeout 숫자 : 이곳에 주어진 숫자만큼의 초동안 기다린 후 응답이 없는 연결은 timeout 에러로 처리한다.
--think-timeout 숫자 : CGI등 서버쪽에서 처리해야 하는 일들이 있는 페이지의 경우 서버측에 이를 처리할 시간을 준다. timeout에서 이곳에 주어진 숫자만큼을 더한 값이 진짜 timeout값이 된다.
--hog : 가능한 모든 포트를 사용한다. 이 옵션을 주지 않으면 기본적으로 1024부터 5000까지의 포트만 사용한다.

httperf --server=linuxhowto.co.kr --uri=/ --port=80 --num-conns=500 --rate=50 --timeout=5 --think-timeout=5 --hog

위의 명령은 linuxhowto.co.kr 이라는 주소를 가진 서버의 / 페이지에 80번 포트로 1초에 50개씩 총 500개의 접속을 만들게 된다. 또한 5초간 응답이 없을 경우 시간초과 에러로 처리한다.
웹서버가 정상적으로 요청을 처리한다면 10초후에는 결과가 나타난다

4. 결과분석방법

실제 테스트 결과 아래와 같은 결과가 나타난다.

각 항목이 무엇을 말하는지는 알아보자.

Total: connections 500 requests 500 replies 500 test-duration 9.983 s

Connection rate: 50.1 conn/s (20.0 ms/conn, <=1 concurrent connections)

Connection time [ms]: min 1.6 avg 1.8 max 2.9 median 1.5 stddev 0.1

Connection time [ms]: connect 0.0

Connection length [replies/conn]: 1.000

Request rate: 50.1 req/s (20.0 ms/req)

Request size [B]: 67.0

Reply rate [replies/s]: min 50.0 avg 50.0 max 50.0 stddev 0.0 (1 samples)

Reply time [ms]: response 1.8 transfer 0.0

Reply size [B]: header 217.0 content 5726.0 footer 0.0 (total 5943.0)

Reply status: 1xx=0 2xx=500 3xx=0 4xx=0 5xx=0

CPU time [s]: user 3.06 system 6.90 (user 30.7% system 69.1% total 99.8%)

Net I/O: 294.0 KB/s (2.4*10^6 bps)

Errors: total 0 client-timo 0 socket-timo 0 connrefused 0 connreset 0

Errors: fd-unavail 0 addrunavail 0 ftab-full 0 other 0

결과는 6개의 그룹으로 표시되고 전체테스트 요약("Total"), 접속상태관련("Connection"), HTTP request 부분 ("Request"), 서버로부터 받은 응답부분 ("Reply"), CPU 시간과 network bandwidth 사용량, 마지막으로 에러집계 ("Errors") 부분으로 구성된다

실제 테스트 결과에서 주의깊게 보아야 하는부분은 서버의 응답시간을 표시하는 Reply time 부분이다.

위의 결과에서는 응답시간이 1.8 ms 인것을 확인할수 있다.

5. 웹서버 괴롭히기

테스트결과 웹서버가 50개씩 500번은 무리없이 수행하는것을 알수있다.

자 그럼 웹서버를 좀 괴롭혀보기로 하자. 컴파일시에 생성된 idleconn 을 이용해서 동시접속자를 한번 만들어보자. idleconn 이라고 치면 아래처럼 사용법이 나온다.

[root@ns httperf-0.8]# idleconn

Usage: idleconn server port numidle

동시접속자를 한 250명정도 만들어본다

[root@ns httperf-0.8]# idleconn linuxhowto.co.kr 80 250

idleconn: creating and maintaining 250 idle connections

동시접속자가 정말 만들어 졌는지 확인해보자

[root@ns ~]# netstat -anpt|grep httpd|grep ESTA|wc -l

250

보는것처럼 250개의 연결된 접속을 생성해냈다.

이제 앞에서 테스트했던 방법대로 한번더 해보자.

httperf --server=linuxhowto.co.kr --uri=/ --port=80 --num-conns=500 --rate=50 --timeout=5 --think-timeout=5 --hog

Total: connections 500 requests 500 replies 500 test-duration 9.982 s

Connection rate: 50.1 conn/s (20.0 ms/conn, <=1 concurrent connections)

Connection time [ms]: min 1.4 avg 1.9 max 16.2 median 1.5 stddev 0.7

Connection time [ms]: connect 0.0

Connection length [replies/conn]: 1.000

Request rate: 50.1 req/s (20.0 ms/req)

Request size [B]: 67.0

Reply rate [replies/s]: min 50.0 avg 50.0 max 50.0 stddev 0.0 (1 samples)

Reply time [ms]: response 1.9 transfer 0.0

Reply size [B]: header 217.0 content 5726.0 footer 0.0 (total 5943.0)

Reply status: 1xx=0 2xx=500 3xx=0 4xx=0 5xx=0

CPU time [s]: user 2.91 system 7.03 (user 29.2% system 70.5% total 99.6%)

Net I/O: 294.0 KB/s (2.4*10^6 bps)

Errors: total 0 client-timo 0 socket-timo 0 connrefused 0 connreset 0

Errors: fd-unavail 0 addrunavail 0 ftab-full 0 other 0

아직까지는 별 문제없이 잘 견디는것 처럼 보인다.

그럼 약간 더 괴롭혀 보자.

이번에는 1초에 200개씩 요청하고 10000번 해보자.

httperf --server=linuxhowto.co.kr --uri=/ --port=80 --num-conns=10000 --rate=200 --timeout=5 --think-timeout=5 --hog

Total: connections 10000 requests 10000 replies 10000 test-duration 49.999 s

Connection rate: 200.0 conn/s (5.0 ms/conn, <=3 concurrent connections)

Connection time [ms]: min 0.2 avg 1.8 max 13.3 median 1.5 stddev 0.3

Connection time [ms]: connect 0.0

Connection length [replies/conn]: 1.000

Request rate: 200.0 req/s (5.0 ms/req)

Request size [B]: 67.0

Reply rate [replies/s]: min 199.8 avg 200.0 max 200.0 stddev 0.1 (10 samples)

Reply time [ms]: response 1.8 transfer 0.0

Reply size [B]: header 217.0 content 5726.0 footer 0.0 (total 5943.0)

Reply status: 1xx=0 2xx=10000 3xx=0 4xx=0 5xx=0

CPU time [s]: user 14.05 system 35.47 (user 28.1% system 70.9% total 99.0%)

Net I/O: 1173.9 KB/s (9.6*10^6 bps)

Errors: total 0 client-timo 0 socket-timo 0 connrefused 0 connreset 0

Errors: fd-unavail 0 addrunavail 0 ftab-full 0 other 0

아직까지는 별문제 없는 상태이다.

이번에는 좀 더 많은 부하를 줘보자. 아래는 초당 1000 개의 요청을 20000개가 될 때까지 테스트하는 예이다.

[root@ns ~]# httperf --server=linuxhowto.co.kr --uri=/ --port=80 --num-conns=20000 --rate=1000 --timeout=5 --think-timeout=5 --hog

httperf --hog --think-timeout=5 --timeout=5 --client=0/1 --server=linuxhowto.co.kr --port=80 --uri=/ --rate=1000 --send-buffer=4096 --recv-buffer=16384 --num-conns=20000 --num-calls=1

Maximum connect burst length: 13

Total: connections 12506 requests 10011 replies 9984 test-duration 28.036 s

Connection rate: 446.1 conn/s (2.2 ms/conn, <=1022 concurrent connections)

Connection time [ms]: min 3.3 avg 876.3 max 12766.8 median 290.5 stddev 1345.5

Connection time [ms]: connect 546.2

Connection length [replies/conn]: 1.000

Request rate: 357.1 req/s (2.8 ms/req)

Request size [B]: 67.0

Reply rate [replies/s]: min 107.2 avg 399.2 max 499.2 stddev 165.2 (5 samples)

Reply time [ms]: response 336.2 transfer 0.0

Reply size [B]: header 217.0 content 5726.0 footer 0.0 (total 5943.0)

Reply status: 1xx=0 2xx=9984 3xx=0 4xx=0 5xx=0

CPU time [s]: user 1.08 system 20.19 (user 3.9% system 72.0% total 75.9%)

Net I/O: 2090.1 KB/s (17.1*10^6 bps)

Errors: total 10016 client-timo 2522 socket-timo 0 connrefused 0 connreset 0

Errors: fd-unavail 7494 addrunavail 0 ftab-full 0 other 0

[root@ns ~]#

결과를 보면 타임아웃으로 처리를 못하는 경우가 절반이상이고, 응답시간도 매우 길어졌음을 알수있다

5초안에 대답을 못한 요청수가 10016 개이다. 테스트한 웹서버가 이 정도는 무리라는 결론이다.

자 이제 여러분의 웹서버를 마구 괴롭혀서 어디까지 견디는지 테스트해보자.

6. 참고문헌 또는 URL

http://www.hpl.hp.com/research/linux/httperf/docs.php

출처 : http://jikime.tistory.com/284 동시접속자수 테스트 방법 참조

출처 : http://phpdoumi.tistory.com/147

SVN의 cleanup 에러시 해결방법

JAESOO — Wed, 04 May 2016 20:12:59 +0000

SVN으로 업데이트 하다가 도중에 끊겼는데 다시 업데이트를 실행하니

cleanup 에러가 발생 합니다.

그래서 cleanup 을 실행했떠니 또 에러가 뜹니다. '-' 난감합니다.

[에러코드]

Previous operation has not finished; run 'cleanup' if it was interrupted

svn cleanup failed–previous operation has not finished; run cleanup if it was interrupted

[해결방법]

Windows의 경우 http://www.sqlite.org/download.html 에서 sqlite를 다운받아 SVN 폴더에 복사

cmd 에서 SVN폴더로 이동한다음에 아래의 명령을 주면 됩니다.

sqlite3 .svn/wc.db "select * from work_queue"

sqlite3 .svn/wc.db "delete from work_queue"

보아하니 svn은 sqllite를 사용하는것 같고 work_queue에 업데이트 명령을 담아두고 실행하는것 같은데

중간에 연결이 끊어지니 work_queue의 내용이 꼬인것 같습니다.

work_queue를 delete 하고 다시 SVN의 cleanup 명령어를 준뒤 업데이트 명령을 실행하니

문제없이 최신 소스로 업데이트 되었습니다.

출처 : http://doswlf.tistory.com/489

[오류해결] svn cleanup failed-previous operation has not finished; run cleanup if it was interrupted

JAESOO — Wed, 04 May 2016 20:00:15 +0000

Previous operation has not finished; run 'cleanup' if it was interrupted

svn cleanup failed–previous operation has not finished; run cleanup if it was interrupted

직접 겪은 것은 아니고, 동료가 겪은 문제라 해결을 도와주다가 알게 된 방법입니다.

실제 해결 방법은 가장 마지막에 작성한 참고 블로그를 통해 알게 되었습니다.

일단 정확한 발생 원인은 모르겠으나 SVN을 통한 Update 과정에서 발생하는 것으로 보입니다.

Update 과정에 SVN과의 접속이 예상치 못하게 끊겨 정상적으로 처리가 완료되지 못하면 종종 발생하는 것 같습니다.

일단 SVN Clean up 을 통해서 해결이 될 줄 알았습니다.

오류 안내 메시지가 그랬거든요.

이전 작업 도중이 완료되지 못하였습니다. 만약 작업 중단되었다면 'cleanup' 을 실행하세요.

SVN cleanup 실패 - 이전 작업이 완료되지않았습니다. 만약 작업 중단되었다면 'cleanup' 을 실행하세요.

그런데 cleanup 을 하고 실행해도 같은 오류가 계속하여 뜹니다.

해결 방법은 다음과 같았습니다.

* SqlLite 내려 받은 후, 프로젝트의 SVN 폴더에 복사합니다.

아래 주소에서 받으실 수 있습니다. (윈도우 사용자인 경우 아래 스크린샷에 빨간 박스로 된 파일을 받으시면 됩니다. 다른 환경이라면 환경에 맞는 파일을 받으시면 될 것 같은데, Eclipse SVN 사용하시는 분들이 대다수 윈도우 환경 개발자이겠지요?^^)

SQLite Download Page : http://www.sqlite.org/download.html

또는 아래 파일을 그냥 내려 받으시면 됩니다. (제가 미리 받아놓은 파일입니다. ㅎㅎㅎ)

sqlite-shell-win32-x86-3081101.zip

내려 받은 후, 압축을 푸시면 sqlite3.exe 파일이 하나 있습니다.

이 파일을 문제가 발생한 프로젝트의 .svn 폴더에 복사합니다. (프로젝트의 하위 폴더에 있습니다.)

그리고 윈도우 커맨드창(Command Window)을 실행하여 해당 경로로 이동한 후, 아래 명령어 2개를 순차적으로 실행합니다.

sqlite3 .svn/wc.db "select * from work_queue"

sqlite3 .svn/wc.db "delete from work_queue"

왜 갑자기 svn 오류를 해결하는데, sqlite 프로그램이 나왔냐고 의아해 하실 수도 있을 것 같은데요.

아마도 svn에서 sqllite를 사용하는 것으로 보입니다. 그리고 그 작업 처리(명령)를 work_queue라는 테이블에 저장하고 있는 것이구요. 이 work_queue 테이블의 정보가 SVN이 갑자기 작업 중에 중단되면서 문제가 발생한 것으로 보이는데요.

그래서 데이터베이스 테이블에 저장된 이 작업들을 모두 초기화하여 문제를 해결하는 것으로 보입니다.

위의 2개의 명령어까지 문제 없이 잘 실행되었다면 다시 Eclipse를 실행하여 해당 프로젝트의 파일들을 Update받아보시길 바랍니다.

만약 동일한 오류나 유사한 오류가 다시 나타난다면 SVN의 Cleanup 명령어를 다시 한 번 실행한 후, Update 받아보세요!

참고

http://kure0769.tistory.com/entry/SVN-cleanup-fail-%EC%B2%98%EB%A6%AC

출처 : http://ooz.co.kr/281

TortoiseSVN 계정변경

JAESOO — Wed, 04 May 2016 19:58:28 +0000

출처 : http://blog.daum.net/pascal24/15122171

SVN passwd 설정 : 계정 (users/passwd)

JAESOO — Wed, 04 May 2016 14:38:28 +0000

passwd 설정 : 계정(users/passwd)

/svn/저장소 디렉토리/conf/passwd

- 원본은 보관하고 새로 만든다.

]# cd /svn/okkks.tistory.com/conf/

]# ll

]# cat passwd

]# mv passwd passwd.old

]# vi passwd

[users]

user1 = 1234

user2 = 1234

설명

- 2명의 계정 생성(user1/1234, user2/1234)

svn 설치

- svn(Subversion) 설치 확인 및 설치하기

svn 설정

- 01. svn 저장소(repository) 만들기

- 02. svn 서비스 데몬 만들기

- 03. svn svnserve.conf 설정

- 04. svn passwd 설정 : 계정(users/passwd)

- 05. authz 설정 : 권한

출처 : http://okkks.tistory.com/979

VMware Workstation 8 의 소개와 가상 머신의 특성

JAESOO — Sat, 30 Apr 2016 18:28:26 +0000

VMware Workstation 이란?

VMware Workstation 이란 가상 머신을 생성하고 운영하는 대표적인 프로그램 중 하나입니다. 가상 머신이란 문자의 뜻 그대로 Virtual Machine - 현실에 존재하지 않지만 마치 존재하는 것과 같이 만든 가상의 기계 또는 장치 - 를 의미합니다.

가상 장치에는 여러 가지가 있습니다. Virtual FDD 의 플로피 드라이브, 데몬 툴즈의 DVD-ROM, 윈도우 7 의 VHD 디스크 등이 모두 가상 장치에 해당합니다. 하지만 VMware Workstation 이 만들어내는 가상 머신은 이러한 개별적인 장치 수준이 아니라 완전한 한 대의 컴퓨터입니다.

즉, VMware Workstation 은 컴퓨터 속에 또 다른 가상의 컴퓨터를 만들어내는 프로그램인 것이죠. 우리는 그렇게 만들어진 가상의 컴퓨터 안에 운영체제를(윈도우, 리눅스 등) 설치하여 실제 컴퓨터와 흡사하게 사용하는 것이 가능합니다.

내 컴퓨터 안에 또 다른 컴퓨터, 이것이 바로 가상 머신이고, 여기에 가장 널리 사용되는 프로그램이 VMware Workstation 입니다.

가상 머신 장치의 특성과 분명한 한계

이미 다른 곳에서 가상 머신에 대해 얼핏 들으시고는 오해하시는 부분들이 적잖게 있는데 시작하기 전에 분명하게 짚고 넘어가도록 하겠습니다. 가상 머신이란 것을 처음 들어보신 분들도 시작 전 알고 넘어가시는 것이 좋습니다.

일단 가상 머신 장치들의 성능적인 부분을 간단하게 정리하자면 아래와 같습니다. (VMware Workstation 의 가상 머신에만 국한된 것이 아니라 통상적인 가상 머신들이 이러한 경향을 가집니다.)

**가상 머신에 포함되는 장치들의 성능**
장치	설명
CPU, RAM, HDD	공유 + 가상, 현재 컴퓨터의 CPU, RAM, HDD 성능(용량)의 영향을 굉장히 크게 받음.
VGA	100% 가상 장치로써 현재 컴퓨터의 VGA 성능과는 무관함. 성능에 분명한 한계가 있음.
Network(Lan)	100% 가상 장치로써 내부 네트워크끼리의 연결은 가상 장치의 성능이 그대로 나오지만 외부 네트워크와의 연결은 실제 장치를 반드시 거쳐야하기 때문에 해당 성능을 뛰어넘을 수는 없음.
기타 장치	100% 가상 장치들, 나머지 장치들은 성능적인 부분에는 큰 영향 없음.

가장 먼저 가상 머신의 CPU 와 RAM 과 HDD, 이 세 가지 장치는 현재 가상 머신이 운용되고 있는 실제 컴퓨터 각각 장치들의 성능에 영향을 지대하게 받습니다. 실제 컴퓨터 장치를 공유하여 사용하거나(CPU, RAM) 100% 가상이지만 원체 가상 장치의 성능이 높고 실제 장치 위에 맞물려서 돌아가기 때문에(HDD) 실제 장치의 성능을 거의 그대로 따라가는 경우이죠.

확실히 이 세 가지 장치들은 실제 컴퓨터 장치를 업그레이드하면 할 수록 확실히 가상 머신의 성능도 그만큼 좋아지고 부드러워지는 것을 느낄 수 있습니다.

가상 머신의 성능에 절대적인 영향을 미치는 CPU, RAM, HDD 장치.

하지만 VGA 즉, 그래픽 카드는 다릅니다. 많은 분들이 가장 많이 오해하시는 부분이 바로 이 가상 머신의 그래픽 카드와 관련된 부분인데요. VMware Workstation 의 가상 머신에서 사용하는 그래픽 카드는 100% 가상으로 만들어진 표준 VGA (VMware Tools 를 설치해야 그나마 SVGAⅡ) 그래픽 카드입니다. 절대 앞서의 CPU 나 RAM 과 같이 현재 컴퓨터의 장치를 공유하여 그대로 사용하는 것이 아닙니다. 그리고 이러한 SVGAⅡ 그래픽 카드의 성능은 매우 낮습니다.

그러니까 쉽게 뭔 말이냐면, 가상 머신의 그래픽 카드는 CPU 가 만들어내는 겁니다. 현재 장착된 그래픽 카드가 아니라! CPU 샀더니 같이 들어있더라는 Intel HD Graphics 내장 그래픽을 사용하고 있더라도, 여러분이 몇백만원을 투자하여 Radeon HD7970 을 크로스 파이어로 묶어서 아주 빵빵하게 사용하고 있더라도, 가상 머신의 그래픽 카드는 CPU 가 만들어내는 SVGAⅡ 일 뿐이며 해당 그래픽 카드의 성능은 매우 제한적이라는 것이죠. 결론적으로 가상 머신의 그래픽 카드는 여러분 컴퓨터에 장착된 그래픽 카드와 아무런 관련이 없습니다.

어라? 그럼 CPU 성능을 올리면 가상 머신의 그래픽 카드 성능도 올라가겠네요? 조... 아뇨. 만들어진 SVGAⅡ 의 한계 성능이 원체 낮기 때문에 CPU 가 아무리 빨라져도 SVGAⅡ 성능의 한계치 이상으론 올라가지 않습니다.

컴퓨터의 성능이 아무리 좋아져도 생성된 SVGAⅡ 의 성능이 워낙 낮기 때문에 가상 머신의 전체적인 그래픽 성능은 거기서 거기.

그러니까 고사양의 3D 게임을 즐긴다든지, 3D 랜더링을 하는 등의, 그래픽 카드의 성능이 절대적으로 필요한 작업에 가상 머신을 활용하는 것은 무리가 따르게 됩니다. 여러분의 컴퓨터가 아무리 좋아져도 그래픽 카드를 활용하는 부분에 있어서는 현재의 가상 머신 기술로는 어쩔 수가 없습니다. [현재까진 가상 머신에서 그래픽 카드를 직접 연결하여 성능을 제대로 뽑아낼 기술이 부족. (일부 특수한 환경에서 그것도 굉장히 제한적으로만 시도되고 있음)]

또한 과도한 3D 성능을 필요치 않는 저성능의 온라인 게임일지라도 요즘의 온라인 게임들은 가상 머신을 통해 부정한 방법을 사용한다고 판단하여 자체적으로 가상 머신을 검출, 가상 머신 내에서는 게임이 실행되지 않도록 하는 것이 보통입니다. 혹 게임에서 막지 않아 접속이 가능하다 할 지라도 끊김 현상은 감수를 해야 하는 것이죠. [저사양의 고전 패키지 게임을 즐기는데에는 뭐 크게 무리가 없습니다.]

그러니까 그러한 목적으로 (주로 3D 온라인 게임 머신으로) 가상 머신을 운영해볼 생각이시라면 제가 조심스럽게 조언을 해드리는데요. 차라리 그냥 컴퓨터를 한 대 더 사세요. 그게 스트레스를 덜 받습니다.

가상 머신의 올바른 용도

이제 VMware Workstation 를 통해 생성하게 될 가상 머신에 어울리는 용도라면, 간단한 인터넷 서핑용이라든지, 테스트나 공부용으로 매우 잘 어울린다고 할 수 있습니다. 이러한 작업에는 실제 컴퓨터를 한 대 더 들여놓는 것을 능가하는 편리함이 있죠.

내부적으로 리눅스 서버를 구축해 보거나, 윈도우의 기능을 테스트하거나, 프로그램들에 어떠한 문제가 없는지 등을 테스트하거나, 현재 윈도우 7 을 사용하는데 급하게 윈도우 XP 가 필요할 때, 윈도우 버전에 따라 문제를 일으키는 프로그램을 반드시 구동해야 할 때와 같은 경우에는 정말로 이만한 프로그램이 없습니다.

그러한 분들께는 가상 머신은 보배 중에 보배가 아닐 수 없죠. 저는 그 중에서도 VMware Workstation 이 일반적인 유저들이 사용하기에 가장 편리하고 강력한 성능을 제공하고 있다고 생각합니다.

VMware Workstation 8.0

VMware 는 가상 머신만을 전문적으로 다루는 회사로써 VMware 라는 이름으로 출시되는 프로그램들은 주 사용 용도의 특성에 맞춰 수 많은 종류들이 있습니다. 그 중에서도 일반적인 사용자를 위한 버전은 VMware Workstation 이란 버전이죠.(단! 유료 버전입니다.) 그 외에 무료 버전인 VMware Player, 맥 OS 용인 VMware Fusion 등도 있지만 실질적인 사용법은 많이 다르지 않습니다.

제 블로그에서는 현재 최신 버전인 VMware Workstation 8.0, 그 중에서도 윈도우용 버전을 중점으로 이야기를 진행해 나가도록 하겠습니다.

p.s 일단은... 디스크와 파티션 관리하기에서 VMware Workstation 이 필요할듯 하여 당장 필요한 부분만 먼저 올리겠습니다. 디스크와 파티션 강좌가 어느 정도 끝나면 천천히 VMware Workstation 을 시작하는 것으로 하도록 하죠. 아마 VMware Workstation 으로 본격적으로 들어가기 위해서는 조금은 시간이 걸릴 듯 합니다. 기다려 주세요. ^^

출처 : http://cappleblog.co.kr/255

Tomcat JVM heap memory set 및 size

JAESOO — Tue, 22 Mar 2016 17:30:16 +0000

[Tomcat JVM heap memory set] ]# /etc/profile export CATALINA_OPTS="-server -Xms256M -Xmx384M" // 정말로 이옵션이 꼭 필요하지 않는이상 적용하지 말아야 합니다. 이 옵션은 힙사이즈를 늘려주는대신 GC 시간을 잡아먹기때문에 사용자수가 유독 많은 웹사이트의 경우 절대 추천하지 않습니다. ======================================================================== 톰캣에 무거운 웹 어플리케이션을 돌리면서 오토 리로...

Java 실행 옵션 정리

JAESOO — Tue, 22 Mar 2016 16:55:44 +0000

사용법:java 또는 java -jar file.jar options: 옵션 classfiles: 호출될 클래스 파일 이름 file.jar: 호출될 jar파일 이름 argument:main함수에 파라미터로 보내질 문자열 예를들어, main함수를 포함하는 Hello.class 파일이 존재할경우, java Hello 로 프로그램을 실행시킬수 있는데, 확장자인 class는 생략할수 있지만, 대소문자는 구별하므로, 정확하게 기입해야 한다....

메모리 영역 (code, data, stack, heap)

JAESOO — Tue, 22 Mar 2016 16:52:54 +0000

프로그램은 크게 instruction(명령)과 data로 구분되며, 일반적으로 4가지, 좀더 세분화 하면 5가지 정도 구분 할 수 있다. --> 아래 그림 참조. 1) code 영역 - 코드 자체를 구성하는 메모리 영역으로 Hex파일이나 BIN파일 메모리다. - 프로그램 명령이 위치하는 곳으로 기계어로 제어되는 메모리 영역이다. 2) data 영역 - 전역변수(global), 정적변수(static), 배열(array), 구조체(structure) 등이 저장된다. 가) 초기화 된 데...

vCenter 없이 vSphere 로 ESXi 에 연결해서 가상머신 복사하기

JAESOO — Fri, 18 Mar 2016 11:00:31 +0000

Contents

VMWare 로 가상화할때 VM을 template 로 만들어 놓고 cloning 하는 기능이 있다.

이 기능을 이용하면 순식간에 서비스에 필요한 VM 을 deploy 할수 있으나 비싼 vCenter server 를 사야하는 문제가 있다.

vCenter 없고 vSphere 로 ESXi 에 바로 연결해서 VM 이미지 파일 자체를 복사(Copy, Not Cloning) 해서 VM 을 빠르게 deploy 하는 방법을 정리해 본다.

VSphere 에서 수행

vSphere clinet 로 ESXi 서버에 연결
구성(Configuration) -> 스토리지(Storage) 클릭하면 우측에 Datastore 목록이 표시됨
VM 이 설치된 datastore 를 선택하고 마우스 우클릭해서 데이터스토어 찾아보기(Browse) 선택
VM을 복사할 폴더를 만든다. (ex: New VM)
.vmdk, .vmx, .vmxf 를 선택한후에 마우스 우클릭후 복사를 선택한다
새로운 VM 폴더를 클릭한후에 붙여넣기를 선택한다.
VM을 Inventory에 추가한다.

Console 에서 수행

사전에 remote 에서 ssh 연결이 가능하게 설정되어야 한다. (VMware ESXi 에 외부에서 ssh 연결할수 있게 설정하기 참고)

ssh 로 ESXi 서버에 연결
cd /vmfs/volumes/DATASTORE_NAME (DATASTORE_NAME 은 VSphere 에서 보이는 데이타스토어 이름이다. Ex: LocalStorage)
새로 만들 VM의 이름으로 폴더를 생성한다.
1. mkdir NewVM
vmkfstools 로 vmdk 를 복제한다. (기존 VM 이름: "CentOS 6", 신규 VM이름: NewVM)

/vmfs/volumes/522e8af9-f59a0983-39fd-d89d672a29ac # vmkfstools -i CentOS\ 6/CentOS\ 6.vmdk NewVM/NewVM.vmdk
Destination disk format: VMFS zeroedthick
Cloning disk 'CentOS 6/CentOS 6.vmdk'...
Clone: 100% done.
vm configuration file(*.vmx, *.vmxf) 를 새로운 VM 에 복사한다.

?

cp CentOS\ 6/CentOS\ 6.vmx NewVM/NewVM.vmx

cp CentOS\ 6/CentOS\ 6.vmxf NewVM/NewVM.vmxf
vi 로 *.vmx 파일을 열어서 VM이름을 변경한다. ("CentOS 6" -> "NewVM")

?

vi NewVM/NewVM.vmx NewVM/NewVM.vmxf

또는 위의 기능을 shell script 로 만든 vm-copy.sh를 사용
vm-copy.sh VMDIR CopyVMDIR

vm-copy.sh

#!/bin/sh -x
if [ $# -ne 2 ];then
        echo "USAGE: $0 SRC_DIR DEST_DIR";
        exit;
fi;
## remove /
SRC=`basename "$1" /`
DEST=`basename "$2" /`
if [ ! -d "$SRC" ];then
        echo "Source Dir \"$SRC\" is not exist. Exit....";
        exit;
fi
if [ -d "$DEST" ];then
        echo "Dest Dir \"$DEST\" is already exist. Exit....";
        exit;
fi
mkdir "$DEST"
vmkfstools -i "${SRC}/${SRC}".vmdk "${DEST}/${DEST}".vmdk
sed "s/${SRC}/${DEST}/g" < "${SRC}/${SRC}".vmx > "${DEST}/${DEST}".vmx
sed "s/${SRC}/${DEST}/g" < "${SRC}/${SRC}".vmxf > "${DEST}/${DEST}".vmxf
 
echo "$Done!";

Inventory에 추가

복사된 VM 을 인벤토리에 추가해야 VSphere 에서 사용할 수 있다.

데이터스토어 브라우저를 띄워서 VM 을 복사한 데이터스토어로 들어간다.
새로 추가된 VM(NewVM) 을 클릭하고 NewVM.vmx 를 선택한후 마우스 우클릭해서 "인벤토리에 추가(A)" 를 선택한다
인벤토리 이름을 입력하고 다음을 누른다
VM을 실행할 ResourcePool 을 선택한다.
완료를 누르고 VM 을 부팅해서 정상동작 여부를 확인한다.
부팅시 다음과 같은 메시지가 나오면 "i copied it" 을 선택한다. ( 참고 링크 - VMware vSphere “I moved it” or “I copied it” – What’s the difference?)

Ref

http://nchrissos.wordpress.com/2013/04/22/cloning-a-vm-without-vcenter-in-esxi-5-1-free-edition/

출처 : https://www.lesstif.com/pages/viewpage.action?pageId=12943617

Workstation용 .vmdk를 esxi 전용으로 변환하기

JAESOO — Thu, 17 Mar 2016 18:19:09 +0000

2cpu 가상화 관련 질문을 보면 vMware Workstation용 .vmdk를 ESXi .vmdk로 변환이 가능한지 물어보는 질문이 많이 올라오더라구요.

그래서 관련 포스팅을 짧게 써봅니다.

1. 데이터스토어에 workstation용 .vmdk를 업로드

데이터스토어 이름을 datastore, 업로드 파일 이름을 esxi.vmdk로 가정합니다.

2. SSH 접속

업로드 한 데이터스토어로 들어갑니다.

cd /vmfs/volumes/datastore

이제 .vmdk 파일을 esxi용도로 변환해야 합니다. 변환 된 esxi용 .vmdk 이름을 esxi2로 가정합니다.

vmkfstools -i esxi.vmdk -d zeroedthick esxi2.vmdk

※주의사항: 데이터스토어에 최소 150GB의 여유공간이 있어야됩니다. 아니면 공간 없다고 에러납니다.

녹색의 zeroedthick는 디스크 종류를 정하는 옵션입니다.

데이터스토어에는 변환하는 esxi용 .vmdk 용량 만큼의 여유가 반드시 있어야하는데요.

여유가 없을 경우 zeroedthick 옵션을 thin으로 바꿀 수 있습니다.

vmkfstools -i esxi.vmdk -d thin esxi2.vmdk

한참을 기다리면 다 됩니다. workstation .vmdk를 올려놓은 데이터스토어에 들어가보면 다음 파일이 하나 추가됐을껍니다.

esxi2.vmdk

이 파일이 esxi용 vmdk 파일입니다. 기존의 esxi.vmdk는 삭제해주세요.

출처 : http://blog.pasion.kr/workstation-to-esxi-vmdk/

J1900 vs 1037u vs D2700 vs D525 vs D2550 vs D2500

JAESOO — Thu, 17 Mar 2016 18:18:39 +0000

一直很纠结应该选择哪个平台今上网查了一下单从cpu的性能测试来看我依然看好 J1900 . S' u. L1 X' X$ K( p7 _ U9 F

4 P! }& d$ }+ [$ f5 A9 |/ E毕竟硬件买新不买旧
# t* B4 u! e3 P( m% O. j; J$ h; R9 O& f
就等 Xynolog支持了一定会是个趋势0 A/ S" {* ?. T* ~' {' e9 p
9 ]* I) k1 c+ x# l% _$ x
不费话了看平分吧7 j+ R* Q1 }+ {: d6 F( T! @4 c

t. a4 x1 d8 Q7 m( _; n0 O6 b" k( o' p

8 y- h% I% h. V( _4 K3 A4 d6 Z- X1 _( ?+ ]; z

6 [. O1 o, V8 G. ?! e- T
5 p9 a1 ]0 ?+ T# w+ ~
: {4 P$ X# m8 l5 W' h
: W* ^: G( I8 \ L+ l8 H

) o: J/ n' h. E# w
9 ^) s/ d2 ]: J9 c& Y; A
. h" l2 u9 Q9 O

0 l8 Y* A6 x1 h) l& ~3 V

8 s' a3 _+ A& x6 Q% R$ T" |
- e) J1 N1 ~/ D3 ^) P
) }& j8 t% Q; F$ m- |* r
- f r+ g+ _0 M. T7 k0 Q7 }
! ^- d* k+ N+ E) |! ~- x. U
* V0 K5 t8 f- u7 Q% g4 T

( ?( j7 N4 Z4 t* a
5 Z5 Z' n& B" t! S7 \7 `% z, ?

. Z0 e% @$ j9 u2 Z/ H3 x
% F) m- q/ k% A' J% p# h# c

! Y) L8 s5 ~. ~

$ i2 M4 w6 a2 Y* d! V( j( L$ o# W
% i9 l- q& f7 G) d* j) V3 N0 D
1 M) D2 q9 g3 B; z6 N |! f1 `" ?- L" a

! h# {. A4 _. D5 x

8 {& Y% [1 d& ^, B, i, P) B0 D
- g9 C# o+ h, U' n/ R
1 Q5 H& y4 U( ^3 ~*

출처 : http://www.7po.com/thread-455156-1-1.html

CPU 온도에 관한 진실

JAESOO — Thu, 17 Mar 2016 18:18:16 +0000

위의 사진처럼 온도 표시 프로그램에서 상식밖의 CPU온도가 표시되는 경우를 자주 보셨을겁니다.

여태까지 이런 현상은 CPU 내부의 온도센서나 메인보드의 센서 불량이라고 생각했었는데요,

사실 이것은 하드웨어적인 문제가 아닌 계산과정의 오류라고 볼 수 있습니다.

( AMD CPU 코어부활로 생긴 온도 표시 오류는 제외합니다.)

현재 오버클럭시 가장 정확하다고 알고 있는 Realtemp나 Core Temp라는 프로그램을 사용하고있습니다.

이 프로그램들은 CPU의 TJ max (임계온도)로부터의 거리를 계산해 온도를 나타내는것으로 알고있는데요,

임계온도는 해당 온도 이상을 넘어가게 되면 CPU에 무리가 올 수 있어 쓰로틀링(온도를 낮추기위해 강제로 성능을 저하시킴)을 시작하는 한계 온도 지점입니다. (그렇기 때문에 임계온도를 넘기면 오히려 성능이 저하되어 오버클럭을 할때는 절대 임계온도를 넘기지 않습니다.)

( (TJ max) - (Distance to TJ max) = (Temperature) 즉, (임계온도) - (임계온도 까지의 거리) = (현재 온도) )

http://www.pantherproducts.co.uk/index.php?pageid=CPUtemperatures 이 사이트에 나와있는 CPU Maximum Temperatures(사실 이것이 정말 TJ max의 값인지는 불분명합니다)을 참고했을때 린필드 i5의 임계온도는 72.7도 입니다.

현재 제가 사용하고 있는 CPU는 린필드 i5 760 (2.80Ghz 전압 1.250v -> 3.80Ghz 전압(다이어트) 1.175v ) 입니다.

먼저 TJ max가 기본설정으로 되어있을때의 Realtemp 온도를 보시겠습니다.

Realtemp와 Core Temp의 기본 TJ max 값은 둘다 99였습니다

현재 CPU 의 상태는 아이들(유휴)상태입니다.

보시다싶이 아이들시의 CPU 온도 치고는 꽤 높은 온도를 보여줍니다.

하지만

위 사이트에서의 린필드 i5의 CPU Maximum Temperatures를 대입하게 되면...

이렇듯 일반적으로 우리가 생각하는 아이들시 정상적인 온도가 나오게됩니다. (반올림해서 73으로 대입했습니다)

...이쯤되면 의문이 생기게 됩니다

" 혹시 우린 모두 정확하지 않은 CPU의 온도를 보고있는것이 아닐까? "

라구요

사실 이 문제에 대해서는 저도 정확한 대답을 해드리기 어려울것 같습니다.

모든 프로그램 자체에서 정확한 임계온도 값을 대입할 수도 있고 아닐 수도 있기 때문이죠.

하지만 한가지 확실한것은...

CPU 온도에 대해 정확하게 표기하고싶다면

프로그램 표면에 표시된 계산된 온도가 아닌,

임계온도 까지의 거리를 표기해야 된다는 겁니다.

결론은

CPU는 온도정보 자체를 제공하지 않습니다.

다만 자신의 임계온도까지 남은 거리(온도)를 제공할뿐입니다.

따라서 프로그램에 표시되는 온도는 CPU의 임계온도에 따라 달라질 수 있습니다.

출처 : http://m.todayhumor.co.kr/view.php?table=total&no=9640295

[SVN] Subversion 명령들

JAESOO — Fri, 05 Feb 2016 16:41:42 +0000

Subversion 에서 사용되는 기본적인 명령들을 알아보자. IDE (통합 개발환경)을 사용하면 쉽게 사용할 수
있는 기능들이지만 커맨드 사용법을 알아두면 유용하게 사용할 수 있다. 커맨드를 직접 사용해 보면 내부동작을
좀 더 쉽게 이해할 수 있으며 특히 자동화 스크립트를 작성할 때 도움이 된다.
(소스관리 프로젝트를 위해 svn 명령을 사용할 경우와 svn 자바 라이브러리를 다룰 때도 도움이 된다. )

다음과 같은 순서로 Subversion 사용방법을 알아보겠다.

1 저장소 생성
2 프로젝트 생성
3 프로젝트 저장소에 임포트(import)
4 작업본(working copy) 내려받기(checkout)
5 woking copy에 파일 추가(add)
6 로컬 수정사항 커밋(commit)
7 저장소 변경사항 업데이트 받기 (update)
8 브랜치/태그 (저장소 파일 복사/이동)
9 저장소 파일 삭제
10 working copy 정보 보기

1. 저장소(Repository) 생성

가장 먼저 해야할 일은 저장소를 생성하는 작업이다. 저장소 생성에 관련된 내용은 지난 포스팅을 참고하기 바란다.

svnadmin create --fs-type fsfs MyRepository

2. 프로젝트 생성

이제 저장소에서 관리할 프로젝트를 위한 최초 디렉토리 구조를 로컬상에 생성한다.
다음과 같은 구조로 "문서관리 시스템"을 위한 디렉토리 구조를 생성하였다.

3. 프로젝트 저장소에 임포트(import)

이제 로컬에 생성한 프로젝트를 저장소로 옮기자. 이 작업은 공유를 위한 프로젝트 최초 기본파일을 구성하는 단계이다.
아래 명령으로 로컬 프로젝트 파일을 저장소로 복사한다.

svn import -m "First DMS Project Import" ./dms

저장소에 프로젝트 파일들이 옮겨졌기 때문에, 로컬 상에 있는 프로젝트 파일들을 삭제하자.
이제 저장소에 있는 파일들이 모든 공유 문서들의 원본이 되고, 변경이 추가될 때마다 그 이력이 버전별로 관리가 된다.

4. 작업본(working copy) 내려받기(checkout)

여러 사람이 저장소에 접근하여 산출물을 공유할 수 있게 되었다. 저장소에 있는 프로젝트 파일들을
로컬상에 먼저 내려 받아보자. 로컬상에 자신이 다루게 되는 프로젝트 파일들을 작업본(working copy) 이라고 한다.
작업본 내 모든 디렉토리에는 숨김파일 .subversion 이 생성되며 디렉토리 내 파일들의 목록과 수정사항들이 관리된다.

svn checkout svn://repository_ip_address/MyRepository/trunk dms

※ svn 명령들은 -r (revision) 옵션을 주어 아래와 같이 특정 리비전의 파일들을 다운 받을 수 있다.
svn checkout -r 7 svn://repository_ip_address/MyRepository/trunk dms

5. 작업본에 파일 추가 (add)

내려받은 작업본을 기반으로 자신이 담당한 모듈을 개발해 나가면 된다.
새로운 파일을 작업본에 추가하고 싶은 경우, 새로운 파일을 생성하는 것만으로는 되지 않는다.
작업본 파일목록에 명시적으로 새로 생성한 파일을 번영해 주어야 한다. 다음과 같은 명령을 사용한다.

svn add build.xml

6. 로컬 변경사항 커밋 (commit)

작업본에 대한 모든 수정사항은 커밋을 해야 저장소에 반영이 된다. 파일 하나하나를 수정할 때마다
커밋을 하는 것은 좋은 방법이 아니다. 에러가 발생하는 파일들을 저장소에 반영하면 업데이트를 받은 다른 팀웍들의
작업에도 영향을 주기 때문이다. 되도록이면 명확한 단위작업별로 구분하여 완전히 동작하는 수정사항만을 커밋하는
것이 좋다. 커밋을 할 때마다 -m 옵션으로 변경사항에 대한 메시지를 반드시 달아주어 변경에 대한 정보를 알수있게 하자

svn commit -m "Added build.xml ant file"

7 저장소 변경사항 업데이트 받기 (update)

작업본 checkout 이후부터, 작업을 시작하기 전에 저장소 최신 변경사항을 update 받아 작업본을 최신버전으로
유지하는 것이 좋다. 저장소와 작업본 사이에 버전 차이가 커질 수록 나중에 commit이 충돌문제가 발생할 수 있기
때문이다. 다음 명령으로 저장송 변경사항을 작업본에 최신화시킨다.

svn update

8 브랜치(branch)와 태그(tag)

특정시점의 문서버전(예를 들어 1차 개발버전과 같은...)에 대한 복사본을 남겨두고 싶을 때 브랜치를 사용한다.
브랜치를 사용하면 복사본이 생성되고, 이후 수정작업들은 다시 작업본에 계손 수정되어 나간다. branch는 가지라는 뜻으로
현재 작업버전에 대해 분기점이 되는 버전이라는 의미를 갖는다. 태그는 브랜치와 비슷한 의미를 갖지만, 분기되어
완전히 작업이 완료된 버전(첫번째 릴리지 버전과 같은...)이며 이름표를 달아서 알아보기 쉽게 표시를 한다.
svn에서 브랜치와 태그를 생성하는 명령은 copy 로 동일하다. 태그 생성시는 t 옵션을 주어 이름표를 달아준다.

브랜치 생성

svn mkdir -m "Create branch directory" svn://repository_ip_address/MyRepository/branches

svn copy -m "Creating release branch for 1.0" svn://repository_ip_address/MyRepository/trunk \

svn://repository_ip_address/MyRepositorybranches/RB-1.0

태그 생성

svn mkdir -m "Create branch directory" svn://repository_ip_address/MyRepository/tags

svn copy -m "Tag release 1.0.0" svn://repository_ip_address/MyRepository/branches/RB-1.0

svn://repository_ip_address/MyRepository/tags/REL-1.0.0

9. 저장소 파일 삭제 (delete)
저장소에 있는 파일을 삭제하는 명령은 다음과 같다. 파일 삭제후 update 를 수행하면 작업본에도 반영이 된다.

svn delete -m "Remove branch 1.0" svn://repository_ip_address/MyRepository/branches/RB-1.0

10. working copy 정보보기

다음명령으로 작업본 리비전 정보와 저장소 루트, 최신 수정일 등의 정보를 확인할 수 있다.

svn info

출처 : http://hiddenviewer.tistory.com/94

[JAVA] 개발환경설정 - 표준프레임워크

JAESOO — Fri, 01 Jan 2016 16:15:04 +0000

# 표준프레임워크 란? 대한민국의 공공부문 정보화 사업 시 플렛폼별 표준화된 개발 프레임워크를 말한다. # 설치 개요 1. jdk 설치 (필자는 가장 최신인 1.8버전으로 설치 하였다.) 2. Tomcat 설치 (Tomcat 역시 최신 버전으로 8.0 버전을 사용) 3. 이클립스 설치 및 Software 설치 # 설치전 중요사항 3번 이클립스 설치 및 Software 설치 시 다소 시간을 소모한다. 인내를 가지고 끝까지 천천히 따라와 주시기 바랍니다. # 설치 ...

Tomcat 7.x 와 8.x 간의 default configuration 차이

JAESOO — Fri, 01 Jan 2016 16:01:24 +0000

[ Article Info ] Name: appsroot Article Category: tomcat Date: 10 9월 2014 Create: 10 9월 2014 Last Update: 12 11월 2015 Hit: 2429 아래 내용 중 Tomcat 7.x는 7.0.55, 8.x 는 8.0.9를 기준으로 합니다. server.xml 1) https 기본 프로토콜 7.x - 기본 프로토콜로 org.apache.coyote.http11.Http11Protocol를 사용하며, BIO implementation 8.x - 포트 기본 프로토콜로 org.apache.coyote.http11.Http11NioProtocol를 사용...

[전자정부 표준프레임워크] 톰캣(Tomcat) 설치하기

JAESOO — Fri, 01 Jan 2016 16:00:14 +0000

전자정부 표준프레임워크를 설치했으니 이제 WAS인 톰캣을 설치해 보겠습니다. http://www.apache.org/ 이곳에서 톰캣은 미리 다운로드 받아놓으셔야 합니다. 저는 Tomcat 7.0을 미리 다운로드 받아놓았습니다. [Server] 탭에서 아래 그림처럼 링크를 클릭하셔도 되고 마우스 오른쪽 클릭하셔서 [new]로 등록하셔도 됩니다. [Browse...] 버튼을 눌러서 미리 다운로드 받았던 Tomcat이 있는 폴더를 선택해 주세요. 이 톰캣으로 실행...

잡설로 써보는 키보드 선택하는 방법

JAESOO — Thu, 31 Dec 2015 18:50:58 +0000

키보드 팔다가 갑자기 생각나서 주저리 써봅니다

지적도 받고 이해 불가능하신 부분 질문도 받습니다

1. 입력 방식
조금이라도 키보드에 대해 알아보신 분들은 보통 쓰이는 멤브레인과 기계식에 대해서는 아실겁니다.
더 자세히 나누면 멤브레인(고무 돔이 눌리며 입력), 기계식(축이 눌리며 입력), 그외 정전용량, 탄소용량 등이 있습니다.

각 입력방식의 장단점은 검색을 해도 어느정도는 나오니 생략하겠습니다.

본인이 키보드를 막쓴다고 생각하시거나, 돈을 아끼시려는 분들은 값싼 멤브레인으로 가시는것이 좋습니다.

가격대를 따지지 않으시면 기계식, 여기서 매니악 하게 파실분은 정전용량 무접점을 추천드립니다.

- 2. 축선택(기계식 해당)
대중적으로 (특히 서든어택 유저들이 많이쓰는) XENICS TESORO M7 같은 체리 스위치를 이용한 키보드, LEOPOLD FC200R LITE같은 유사 알프스 스위치, 구식 키보드나 커스텀 키보드에 쓰이는 알프스 스위치로 나뉩니다.

체리 축에서 기성품으로 나오는 축들은 청축(클릭), 갈축(넌클릭), 적축(저압 리니어), 흑축(리니어), 백축 이 있습니다.

청축은 째깍거리는 소리와 키를 누를때의 구분감이 특징입니다. 주로 FPS에 쓰이며 업무용으로는 소리가 시끄럽고, 타 게임의 속타에서 다소 불리합니다.

갈축은 청축에 비해 덜한 구분감이 있습니다. 취향을 많이타고 키캡도 많이 탄다고 합니다.

적축은 구분감없이 약한 힘으로 쑥 들어가는 것이 특징입니다. 속타에 유리하고 기계식 중 소음이 적은 편이어서 리듬게임 유저들이 적축을 쓰는 추세였으나, 요즘은 FPS유저들도 적축을 쓰는 경우가 많아졌습니다.

흑축은 무거운 키감과 키를 누르는 도중에 입력이 되는것이 특징입니다. 입문자분들께는 매니아축으로 인식되있습니다. 리듬게임을 제외한 다른 게임에서 좋습니다. 속타 시 손에 피로가 올 수 있으며 다른축이 심심한 분들이 주로 사용합니다.

백축은 클릭 타입과 일반 백축으로 나뉘나, 기성품 백축은 체리사 키보드 뿐입니다. 존재만 알아두셔도 될듯 합니다.

알프스 유사 축은 한때 레오폴드에서 판매하던 200R라이트(유사 알프스 백축), 앱솔루트 K7(유사 알프스 청축)이 있습니다.
알프스 축이 희귀해 짐에 따라 나온것같습니다. 소리는 청축 뺨치는 소리며 키압도 무거운 편이라고 합니다. 그리고 알프스용 키캡은 구하기 매우 힘들어 키캡놀이에 매우 불리합니다.

알프스 축은 님들 부모님 세대가 쓰던 기계식 정도로 생각하시면 됩니다. 현재 판매하는 키보드는 없습니다.

3. 보강판의 유무(기계식 해당)

보강판이란 하우징(상판)과 기판 사이에서 스위치를 잡아주는 역할 정도로 생각하시면 되겠습니다.

보강판이 있으면 안정적인 키감을 느낄수 있고, 없으면 그 축의 키감이 그대로 나타납니다.

드물지만 기계식도 험히 다루시는분은 보강판이 없으면 축이 하나하나 분리될수도 있겠네요. ㄷ;;

이 외에 LED유무, 배열, 키캡놀이 가능유무 등은 여러분의 취향이므로 생략하고 글 줄이겠습니다

출처 : http://cafe.naver.com/tf2np/87241

Configuring Virtual Machine Processor Settings

JAESOO — Fri, 16 Oct 2015 10:44:00 +0000

Using VMware Workstation Player for Windows > Configuring Virtual Machine Hardware Settings

1 2 3 4 5
0 Ratings

You can configure processor settings for a virtual machine, including the number of processors, the number of cores per processor, and the preferred execution mode for the virtualization engine.

To configure processor settings for a selected virtual machine, select Player > Manage > Virtual Machine Settings, click the Hardware tab,and select Processors.

Processor Settings

Setting

Description

Number of cores per processor

Select the number of cores per processor.

Workstation Player supports up to 16-way virtual Symmetric Multiprocessing (SMP) for guest operating systems running on multiprocessor host machines. You can assign processors and cores per processor to a virtual machine on any host machine that has at least two logical processors.

Preferred mode

Select the preferred execution mode for the virtualization engine. You usually do not need to change virtualization engine settings.

Automatic	Workstation Player chooses the execution mode based on the guest operating system and the host CPU.
Binary translation	Workstation Player uses a mix of directly executing guest code and binary translation to run the guest operating system. Guest memory mapping is performed by using shadow page tables.
Intel VT-x or AMD-V	Workstation Player uses hardware extensions to run and isolate guest code. Guest memory mapping is performed by using shadow page tables.
Intel VT-x/EPT or AMD-V/RVI	Workstation Player uses hardware extensions to run and isolate guest code. Guest memory mapping is performed by using hardware paging.

Disable acceleration for binary translation

In rare instances, you might find that Workstation Player appears to freeze when you install or run software inside a virtual machine. This problem typically occurs early in the execution of the program. In many cases, you can prevent the problem by temporarily disabling acceleration in the virtual machine. After the program passes the point at which the problems occur, deselect this setting.

Virtualize Intel VT-x/EPT or AMD-V/RVI

Workstation Player forces the virtual machine execution mode to VT-x/EPT or AMD-RVI. Physical Address Extension (PAE) mode must be enabled to use virtualized AMD-V/RVI.

If the execution mode is not supported by the host system, virtualized VT-x/EPT or AMD/RVI is not available. If you migrate the virtual machine to another VMware product, virtualized VT-x/EPT or AMD-V/RVI might not be available.

Enable virtual CPU performance counters

Turn on this feature if you plan to use performance monitoring applications such as VTune or OProfile to optimize or debug software that runs inside the virtual machine.

This feature is available only if the virtual machine compatibility is Workstation 9 or later.

출처 : http://pubs.vmware.com/player-12-windows/index.jsp#com.vmware.player.win.using.doc/GUID-3140DF1F-A105-4EED-B9E8-D99B3D3F0447.html

Intel Virtualization Technology for Directed I/O (VT-d)

JAESOO — Tue, 13 Oct 2015 10:02:00 +0000

어제 가상화에 관심있는 친구를 만나다가 IO 관련 가상화에 대해서 이야기를 조금 해보았는데... 그러면서 궁금해진 점이 virtualization technology for directed i/o 즉 VT-d 에 관련된 부분이었다.

그래서 IOV (I/O Virtualization) 에 관련된 내용을 좀 찾아보았는데... 내용은 다음과 같았다.

Intel Virtualization Technology for Directed I/O (VT-d)

VMM은 guest 소프트웨어로부터의 I/O requests에 대한 가상화를 지원하게 된다. 이를 위해서 현재 사용되고 있는 방법은 device emulation과 para-virtualization이다. 이러한 I/O device 가상화 (IOV) 모델에서, 신뢰성과 보호 수준에서 발생하는, 요구사항은 역시나

VMM에 의해서 장치에 할당된 자원들에 대해서만 접근이 가능하고
격리(isolate) 를 제공해야 한다는 것이다.

VT-d 는 이를 제공하기 위해서 hardware를 통해서 지원하는 가상화 기능으로

hardware assisted remapping 을 이용하여 장치 격리를 제공하고 이를 통한 reliability 와 security의 향상과,
장치들에 대한 직접적인 할당으로 인한 I/O 성능과 가용성의 증대

이다.

그렇다면 hardware assisted remapping 이란 무엇일까?

VT-d 는 장치들의 DMA를 미리 할당된 도메인 혹은 physical memory region들에 한정하는 기능을 제공한다. 이를 위해서는 DMA-remapping으로 알려져 있는 하드웨어 capability를 이용하게 된다. 칩셋의 VT-d DMA-remapping hardware logic은 DMA를 지원하는 peripheral I/O 장치들과 컴퓨터의 physical memory 간에 존재하게 되고, 이를 구현하기 위해서 computer system software로서 프로그램된다. (이를 가상화 환경에서는 VMM이 지원하게 되고, 가상화되어 있지 않은 환경, 즉 native 환경에서는 OS 가 이러한 기능을 구현하게 된다.) DMA-remapping은 incoming DMA request의 address를 현재 physical memory address로 변환하고, system software에서 제공하는 정보를 기반으로 해당 physical address에 접근이 가능한지를 검사하게 된다.

Intel VT-d 는 system software가 여러개의 DMA protection domain들을 만들도록 지원한다. 각각 protection domain은 host physical memory의 일부를 할당받은 isolated environment이다. 여기서 DMA protection domain은 소프트웨어 사용 모델에 따라서 VM에 할당된 메모리로 나타나거나, 혹은 VMM의 일부로써 혹은 VM에서 수행되는 guest OS driver에 할당된 DMA memory로서 나타날 수 있다. VT-d 구조는 system software로 하여금, 하나 혹은 그 이상의 I/O device들을 하나의 protection domain에 할당할 수 있게 한다. DMA isolation은 address-translation 테이블들을 이용하여 해당 physical memory에 할당되지 않은 I/O 장치들로부터 protection domain의 physical memory로의 접근은 제한하여 제공된다. 이는 각각 가상 머신들의 컴퓨터 자원들간의 separation을 보장하도록 필요한 isolation을 제공한다.

어떠한 주어진 I/O device가 임의의 memory location을 접근하려고 할때

DMA remapping hardware는 해당 device로부터 임의의 protection domain에 대한 접근 허용을 위해 address-translation table을 찾게 된다.
만약 장치가 접근이 허용되는 range 밖의 주소에 접근을 시도하면, DMA remapping hardware는 그 접근을 막고, 시스템 소프트웨어에게 fault 를 report하게 된다.

다음 Figure 1은 VT-d DMA Remapping을 보여주고 있는데, 여기서 Device-1은 Domain-C 에 할당되어 있지 않기에, Device-1이 Domain-C memory location range 를 접근하려고 시도할 경우 VT-d 하드웨어에 의해서 제한되게 된다.

Figure 1. VT-d DMA Remapping.

여기서, 성능을 향상시키기 위해서, I/O device 들과 protection domain들간의 mapping, 그리고 DMA address translation의 page-table entries와 같은 자주사용되는 remapping-structure entries는 캐슁된다. 이에 대해서 VT-d는 Peripheral Component Interconnect Special Interest Group (PCI-SIG) Address Translation Services(ATS) 스펙을 지원하는데 이는 Endpoint Device에서 장치에 제한된 DMA translations에 대한 캐슁을 허용하는 방법을 표준화하고 있다.

I/O performance through Direct Assignment

가상화는 다수의 virtual machines을 하나의 서버에서 생성하도록 지원하고 있다. 이러한 consolidation은 server hardware utilization을 높이는 것이 사실이지만, 추가적으로 server application들의 consolidation으로 인해서 높은 I/O performance를 요구하게 된다. Software기반의 IOV 방법론들은 I/O device들의 emulation을 사용하고 있는데, 이러한 emulation layer를 이용하는 VMM은 hardware device의 VM들에 대한 일관된 view를 제공하고, 이를 통해서 물리적인 장치는 다수의 VM들에 의해서 공유되도록 지원한다. 그러나 이는 high I/O performance device들의 I/O performance를 낮추게 되는데, VT-d 는 VM에 대한 직접적인 device의 할당을 통해서 가상화된 I/O device의 native capability 와 native performance에 대한 손실에 대한 해결책을 제공하게 된다.

이 모델에서는 VMM은 device들이 해당 파티션으로의 직접적인 할당을 가능하도록 하는 제어 기능에 대해서 일부 기능만을 수행하도록 한다. 즉, 파티션이 요청하는 모든 (혹은 대부분의) I/O request들을 진행하기 위해서 VMM이 호출되기 보다는, VMM은 guest software가 system functionality와 isolation에 관련된 조작을 하게 되는 protected resources (I/O configuration accesses, interrupt management 등과 같은)에 대한 접근을 진행하기 위해서만 VMM을 호출하게 된다.

I/O device들의 직접 VM에 할당되기 위해서, VMM 은 DMA request들이 isolation되도록 강제해야 한다. 또한 이렇게 I/O device들이 도메인들에 할당될 때, DMA remapping hardware는 I/O device로부터 해당 도메인이 현재 소유하고 있는 physical memory에 대한 DMA만을 사용하도록 제한하는데 사용되게 된다.

VM 혹은 guest 가 VMM 상에서 수행될 때, Guest Physical Address (GPA)로 알려져 있는, Guest OS의 physical address range로서 제공되는 address space는 실제 Host Physical Address (HPA)와는 같지 않을 수도 있다. DMA capable device들은 physical memory location들로부터/들로의 데이터 전송을 위해 HPA를 필요하게 된다. 그러나 direct assignment model에서는 guest OS device driver는 domain의 control하에 있게되고, DMA capable device이 필요로 하는 HPA 대신에 domain에 알고있는 GPA 를 제공하게 된다. 이때, VMM 은 DMA remapping hardware의 GPA to HPA 변환정보를 이용하여 필요한 변환을 수행하게 된다. 이러한 Remapping을 이용하여, data가 현재 중간에 존재하는 software emulation layer릍 통해서 전송되는 것이 아니라 guest들의 적절한 buffer로 직접적으로 전송될 수 있게 된다.

Figure 2. Software Emulation based I/O vs. Hardware based Direct Assignment I/O

Figure 2는 software emulation based I/O 와 hardware direct assignment based I/O 를 비교해 놓은 것이다. emulation based I/O에서는 중간의 software layer가 VM 과 device 간의 모든 I/O를 제어하는 것을 볼 수 있고, data가 emulation layer 를 통해서 device 로 전송되고 device로부터 emulation layer 로 전송되는 것을 보여준다.

direct assignment model에서는 unmodified guest OS driver가 해당 guest OS 에 할당된 device를 제어하는 것을 볼 수 있다. receive path에서 DMA remapping hardware는 guest OS driver에 의해서 제공되는 GPA를 옳은 HPA로 변환하고, 이에 따라 data는 guest OS의 버퍼로 직접적으로 전송되게 된다. VT-d 의 Interrupt Remapping 지원은 interrupt control 이 직접적으로 VM으로 할당되도록 허용하며, 이를 통해서 VMM의 overhead를 줄일 수도 있게 된다.

Intel VT-d usage models

VT-d를 지원하는 OS들과 VMM들은 I/O memory management의 VT-d functionality를 사용하여 device가 system의 기능에 영향을 줄 수 있는 delinquent DMA를 수행하는 것을 방지하여 protection domain들로부터 device들을 격리시킬수 있게 된다.

VT-d는 서버, 워크스테이션 그리고 software와 hardware의 결합에 의한 새로운 형태의 클래스에 대해서 보안을 제공하고 격리된 수행 공간인 virtual appliance라 불리는 컴포넌트를 수행함에 역시 사용될 수 있다. virtual appliance는 virus scanning과 firewall appliance 혹은 하드웨어 관리 appliance와 같이 미리 정의된 application들 그리고/혹은 service들을 위해서 최적화한 수행환경을 제공하게 된다.

가상 환경에서의 VM들은 응용단에서부터 device단까지 protection domain들로 격리시킬 수 있다. 이러한 방법은 하나의 도메인에서 발생하는 하나의 I/O device에 대한 문제가 다른 도메인들에게 문제를 발생시키는 것을 격리시킬 수 있게 되고, IT 사용자로 하여금 더욱 나은 system reliability 와 uptime을 제공할수 있게 된다.

Test와 development 환경에서도 다수의 VM들을 사용한 서버와, 가상환경에서 동작하는 공존하는 다수의 OS들를 이용한 workstation들은 work partition들을 isolate시킴으로써 장점을 취하게 된다.

Server Usage Models

많은 Server application들은 I/O-intensive 한데, 특히나 networking과 storage에 대해서는 더욱 그러하다. data center 내에서 생겨나는 중요한 I/O 요구사항들은 주로 scalability 와 performance인데, 이러한 부분은 mission-critical 응용들이 가상화된 data center server들과 infrastructure로 옮겨감에 따라서 server consolidation, reliability, 그리고 availability를 제공하기 위해서 필요하다. 또한 정부와 health-care는 동적인 health care 환경에서 mission-critical needs를 만족시키기 위해서 다수의 OS들을 제공하는 다수의 partition들에 대해서 secure I/O를 지원하고 isolation을 통해서 그 장점을 얻을 수 있다. 또한 health care에서 필요로하는 기관간의 개인 정보 보호에 관련된 보안에 대한 효과를 얻을 수 있다.

Enhancing Performance

가상화는 under-utilized server에 대해서 workload의 consolidation을 가능하게 해준다. 더욱 많은 work load가 consolidate됨에 따라서, I/O 의 사용과 bandwidth 가 많이 요구되고, I/O performance가 병목이 되게 된다. 성능을 높이기 위해서 높은 I/O 성능을 요구하는 VM에 대해서 직접적으로 전용의 고성능 I/O 장치가 할당될 수 있는데, Intel VT-d 기반의 I/O 가상화는 multi-port gigabit 그리고 10 gigabit 네트워크 아답터들과 같은 고성능 I/O 장치들로 하여금 platform상에 존재하는 다른 VM들이 고성능 장치의 동작에 영향을 주지 않도록 지원하게 된다. Intel은 PCI-SIG에서 I/O 가상화 스펙에 대해서 적극적으로 참여하고 있으며, 이는 다수의 VM들에 대해서 하나의 장치가 공유될 때에도 본연의 성능이 나오도록 지향하고 있다.

Enhancing Reliability and Security - Native OS and Server Consolidation

consolidated virtualized server들의 multiple I/O 장치들의 사용은 증가하고 있는데, 하나의 가상화된 서버에서 최대 네개의 networking 장치들이 사용되는 것이 찾기 어려운 일이 아니다. Intel VT-d 는 VMM들이 protected domain들에 대해서 이러한 device들을 isolate시킴으로써 reliability와 security 를 향상시키도록 돕게 된다.

지정된 memory range에 대해서 device들의 접근을 제어함으로써 end to end (VM to device) isolation이 VMM에 의해서 제공된다. 이는 security reliability 그리고 availability를 향상시킨다.

Device isolation은 비-가상화 플랫폼에서도 잘 적용될 수 있다. Device driver 개발자는 하드웨어 혹은 원치않는 memory range를 접근하는 device driver DMA를 debugging 하기 위해서 임의의 memory range들에 대해서 device isolation을 사용할 수 있다.

Getting around "Bounce Buffer" Conditions

Intel VT-d DMA remapping 기능을 사용한 시스템 소프트웨어는 bounce buffer conditions을 피함으로써 성능을 증가시킬 수 있다. bounce buffer들이 DMA를 수행하는 32bit device와 32bit address limitation들로 인해서 접근 불가한 physical memory range간에 사용될 때, 시스템 소프트웨어는 buffer 카피들을 수행하지 않고는 data를 high memory로의 data redirect를 사용할 수 있는데 이를 위해서 Intel VT-d DMA remapping을 사용할 수 있다.

Client Usage Models

Intel VT는 3rd party 회사로부터 필수적으로 필요한 security와 deep packet inspection과 Intel vPro technology를 이용한 desktop PC에서의 policy compliance 와 같은 activities를 위한 관리 서비스들을 수행하기 위해서 virtual appliance의 배포를 가능하게 한다. 이러한 tamper-resistant virtual appliance들은 중요한 서비스들을 위해서 더욱 secure하고 안정적인 환경을 제공하고 매우 쉽게 사용할 수 있도록 하나의 패키지에 모든 필요한 소프트웨어들을 포함하게 된다. 이러한 서비스 혹은 관리성에 있어서 VT-d는 가상 머신들을 위한 memory protections와 I/O optimization을 만족시키는 client platform을 제공하도록 isolate되고 control되는 그리고 protect되는 환경을 제공하게 된다.

VT-d based Virtual Appliances

virtual appliance는 application 그리고/혹은 서비스들을 미리정의된 집합으로써 최적화된 self-contained virtual execution environment이다. Lightweight Virtual Machine Monitor (LVMM)은 Intel VT를 사용하는 VMM으로써 두개의 수행 환경으로 client platform을 나누기 위해서 사용된다. 하나는 Windows XP와 같은 운영체제를 수행하기위한 사용자의 VM으로 video 혹은 rendering 응용들과 같은 사용자의 요구사항을 만족시키기 위한 응용, 개발과 테스트를 위한 응용, 그리고 기본적인 사무 응용들을 제공할 수 있다. 또 하나는 service partition (혹은 Server VM)으로 격리된 사용 공간에서 service OS 를 운영하게 된다. 사용자 파티션은 (예를 들어) network interface controller들을 제외한 플랫폼의 모든 장치들을 소유한다. 이때 network interface controller들은 service 파티션에 의해서 소유되는데, 이는 network traffic을 필터링하고 클라이언트 플랫폼을 위해서 다른 VM들에게 network device들을 가상화하게 된다. 서비스 파티션에서 수행되는 관리 응용들은 remote contol을 제공하여, 클라이언트 시스템을 이용해서 플랫폼의 나머지부분과 사용자 환경을 관리도록 지원한다.

Figure 3. Client VMM 구조

Figure 3에서 보여지는 구조는 서비스 파티션이 소유하고 있는 물리적인 network interface card 드라이버를 통한 network traffic 흐름을 보여준다. 브릿지 드라이버는 서비스 파티션 네트워크 스택과 사용자 파티션 네트워크 스택 사이에 패킷들을 라우팅해준다. 사용자 파티션에서는 가상 NIC 드라이버가 사용자 파티션으로 부터 모든 나가는 패킷들을 브릿지 드라이버로 보내고 브릿지 드라이버는 패킷들을 물리 NIC 으로 전달하게 된다.

이러한 네트워킹 구조는 부정적인 네트워크 트래픅으로부터 고수준의 보안을 제공하게 된다. 또한 하나의 파티션과 VT 그리고 VT-d의 사용을 통해서 할당된 자원으로부터의 부정적인 공격을 격리시키는 능력을 제공하게 된다. VT-d 는 가상 가전 기반의 새로운 종류의 응용을 만들어내는 초석을 마련하게 된다. 아는 NIC 장치 모델이 사용자 파티션에 드러난 가상화 schema 보다 잘 동작한다. 이러한 scheme에서는 모든 사용자 파티션의 NIC 장치로의 접근은 intercept되고 부정적인 코드의 확산을 보호하도록 emulate된다.

LVMM과 서비스 파티션은 사용자 파티션에 사상된 DMA 버스 마스터링 장치들로부터 보호받아야만한다. 이러한 DMA-capable 장치들은 정차시스템 메모리에 접근할 수 있고, 의도적 혹은 비의도적으로 LVMM과 서비스 파티션 코드와 데이터구조를 hosting하고 있는 메모리 페이지에 접근(읽기/쓰기)을 할 수 있다. 이러한 접근들은 IT 보안에 문제점을 야기시키고, memory corruption으로 인해서 플랫폼이 쓸모없어질 수 있는데, VT-d 는 이러한 문제점을을 방지하는데 사용될 수 있다.

앞서 언급했듯이, VT-d 는 system memory 에 대해서 두가지 view (Guest Physical Address (GPA) 와 Host Physical Address(HPA))를 허용하고 있다. LVMM은 HPA view, system physical address space 를 유지하고, 사용자 그리고 서비스 파티션들은 그들의 관련된 GPA view 를 유지하게 된다. LVMM은 CPU로부터의 접근을 위해서 GPA to HPA 로 변환하기 위해서 shadow page tables 들을 유지하게 된다. 유사하게 VT-d DMA remapping 엔진들과 관련된 변환 테이블들을 이용하여 LVMM은 모든 DMA-지원 I/O 장치들을 위해서 GPA-to-HPA 사상을 유지하게 된다. Figure 4는 이러한 사용 모델을 나타내고 있다.

Figure 4. 클라이언트 VMM에서의 VT-d 사용 모델

DMA 사상은 다음과 같이 동작한다:

모든 서비스 파티션 메모리 페이지들은 하나의 도메인에 추가되고 서비스 파티션에 사상된 DMA 장치들 (NIC들)은 오직 이러한 패이지들을 통해서만 접근이 가능하다.
모든 나머지 페이지들 (LVMM과 BIOS reserved를 제외한)은 사용자 파티션 도메인에 추가되고, 서비스 파티션에 사상된 페이지를 장치들을 제외한 모든 장치들 (예를 들어 iGFX, PCI/PCIe add-on 카드들 등)은 이러한 페이지들에 접근할 수 있다.
LVMM과 BIOS reserved 영역은 VT-d 변환 페이지 테이블에서 빠져있기 때문에 가상화된 환경에 의해서 DMA 접근들로부터 보호된다.

이러한 device-to-domain 사상은 다음과 같은 장점을 같는다.

하나의 도메인에 사상된 I/O 장치들은 다른 도메인의 메모리에 접근할 수 없다. 예를 들어, 사용자 파티션의 PCI/PCIe add-on 카드들은 LVMM 혹은 서비스 파티션에 접근할 수 없다.
서비스 그리고 사용자 파티션의 장치 드라이버들은 GPA-to-HPA 사상을 파악하기 위해서 어떠한 변화 없이 동작한다. 이러한 변환은 장치가 GPA를 통해서 I/O 요청을 이슈할 때 VT-d 하드웨어에 의해서 투명하게 수행된다.
만약 장치가 도메인에 사상되지 않은 주소에 대해서 접근하려고 시도하는 잘못된 동작을 할 경우, VT-d 하드웨어는 fault 를 생성한다. 이러한 fault 는 LVMM에 캡춰되고 서비스 파티션에 알려진다. 서비스 파티션의 추가적인 관리 응용은 fault 의 정에 따라서 에러 메세지를 표시해주거나 platform reboot으로 초기화 등의 적절한 행동에 의한 이러한 fault 를 처리할 수 있다.

Intel VT-d requirements

VT-d 는 Intel Client, Workstation 그리고 일부 Server 에서부터 지원이 시작된다.

하드웨어

VT-d 를 지원하는 chipset을 갖는 플랫폼

소프트웨어

가상환경에서 VT-d 기능을 지원하는 VMM (혹은 Hypervisor). VMM상에서 운영되는 Guest 는 수정이 필요없음.
native OS 환경 혹은 비-가상화 환경에서는 VT-d protection 특징을 OS 에서 사용할 수 있다.

BIOS requirements for the platform

VT-d 를 사용하도록 BIOS 에서 enabling 해주어야 함. BIOS는 VT-d capabilities (예를 들어 # of DMA remap engines etc)를 ACPI table 을 이용해서 VMM에게 드러내도록 해야한다.

결론

VT-d 구조는 완전한 application-to-I/O 장치 데이터 전송 격리를 지원하는 가상화된 환경을 생성할 수 있는 하드웨어 메카니즘을 제공한다. 이는 더욱 가용성있고, 신뢰성있고, 보안에 강한 가상 환경을 생성을 가능하게 한다. VT-d를 이용해서 소프트웨어 개발자들은 높은 가용성을 지원하고, 높은 성능을 제공하며, 증가하는 I/O 요구에 확장성있는 I/O 자원들을 완전히 보호하는 공유를 개발할 수 있게 된다.

I/O 장치 가상화를 위한 Intel 플랫폼에서의 VT-d 지원은 프로세서와 메모리 자원을 가상화하는 기존의 Intel VT 기능을 보완한다. 이를 통틀어서 VT 기술의 로드맵은 Intel 플랫폼의 가상화를 위한 완전한 하드웨어 지원을 제공하는 완벽한 솔루션을 제공한다. I/O 자원들의 가상화는 data center, enterprise, 그리고 home 에서의 새로운 사용 모델의 중요한 셋을 가능하도록 하는 중요한 step 이다.

참조

http://softwarecommunity.Intel.com/articles/eng/1416.htm

출처 : http://virtualization.tistory.com/m/post/8

인텔의 vPro, 5년 노력에도 안팔리는 이유?

JAESOO — Wed, 07 Oct 2015 19:44:14 +0000

인텔 2세대 샌드브릿지 VPRO의 특징과 전망

들어가기에 앞서 해당 글은 몇달전 Intel의 블로거 초청행사에서 기업용 솔루션인 vPro 기술 시연 및 간담회에서 들었던 내용을 기초로 하고 있습니다.

어떤면에서 소비자들은 참 단순한 면이 있는 것 같습니다. 물론 저도 포함해서지만요. 서비스나 제품이 잘 팔리고 있을때는 잘나가는구나 하다가도 잘 안팔리는 것 같으면 이 회사 문제 있는 것 아냐라는 식으로 보게되죠.

물론, 제품이나 서비스가 잘 안팔릴땐 보통 문제를 같이 동반하는 경우도 있지만 잘 준비된 조직에선 이런 우려를 크게 개의치 않는 것 같습니다. 일시적인 부진이므로 곧 만회 할 수 있다고 판단하기 때문입니다.

물론, 여기에 오만이나 자만이 숨어 있다면 더 큰 대가를 지불하지만 정말 잘 준비하고 있는 회사는 바로 부족 분을 매워 도약의 발판을 마련하기 때문입니다. 그런면에서 제가 생각하기엔 잘 준비 된 것 같아 보이는 한 기업을 오늘 소개해 보려고 합니다.

바로 인텔입니다. 인텔이 상당히 지탄 받는 이유는 매출이나 수익 때문입니다. 기존 시장에 안주한다는 인상때문에 그런 평가를 많이 받는 것 같습니다. 100% 틀린말은 아니지만 제가 예상 하고 있던 것 보다는 나름 잘 준비를 해왔다고 생각되 오늘은 못하는 부분이 아니라 잘 해왔던 부분을 소개해 보려고 합니다.

Intel이 돈 안되는데 계속 밀고 있는 VPRO 어떤 것인가?
vPro는 일반적으로 일반용 PC나 노트북에 들어가는 기술이 아니라 기업용 PC를 대상으로하는 기업용 기술입니다. 원칙적으로는 기업용 센트리노2 플랫폼 라인업은 2개정도 밖에 안된다고 합니다.

이것은 일반인에게 보다 다수의 PC 제어와 운영 관리가 필요한 기업용에 더 적합한 기술이기 때문이란 것이 그들의 설명입니다.

그럼 vPro라는 기술이 어떤 기술이냐? 데스크톱의 가상화, 원격제어, 보안을 하드웨어 차원에서 관리/지원하기 위해 개발한 진보한 기술입니다. 물론, 과거에도 이런 기업용 관리 솔루션이 있어왔고 현재도 절찬리에 판매중이지만 vPro한단계 더 진보한 기술이라고 합니다.

관련 내용은 앞으로 계속 소개해 드리겠습니다.

칭찬성 글이라도 이해를 부탁한다는 메시지
지금 이야기 하기 앞서 행사에 초대되긴 했지만 제가 돈을 받았다거나 뭐 답례품을 받은 것은 없습니다. 굳이 답례 품이라면 도시락 하나랑 와줘서 고맙다고 라디오 겸용이 되는 작은 조명하나 주더군요.

제가 이번 글은 좀 인텔 칭찬을 많이 할 것 같아 오해 없으시라고 이야기 드립니다. 그동안 욕만 하던 놈이 갑자기 칭찬하니 돈받은거 아냐 하실 분이 계실것 같아서요. (욕할건 욕해야겠지만 칭찬 할건 또 칭찬해야 그게 중심을 잡는게 아닐까 생각되고 이번 글도 그런 제 원칙에 따라 작성 된 글입니다.)

그럼 시작하겠습니다. 전 엔지니어는 아니지만 컴퓨팅과 정보통신 관련 학과를 나왔고 약간의 하드웨어 지식과 프로그래밍 지식에 10년 가까이 현업에 종사해 오면서 이런저런 온라인 서비스 환경을 거치다 보니 이런 저런 환경적 배경을 몸으로 체험 할 수 있었습니다.

운이 좋았는데요. 그래서 정부나 기업 일도 많이 해보고 했는데요. 서울시 정도 되는 단체에서 일을 할 경우엔 보안적 이슈가 발생합니다.

해당 사무실에 방문하려고 해도 신분증과 반납증은 필히 가지고 있어야하고 들어가서도 인터넷을 하려고해도 노트북 인증과 iP를 부여 받아야 합니다.

여기에 실제 개발 서비스를 서울시 서버에 적용시에는 더 복잡한 절차가 필요합니다. 기업은 더 말할 나위도 없겠죠. (물론 이정도 시스템을 운영 할 수 있는 기업에 한해서지만요.)

바로 이런 영역에서 인텔이 제시한 vPro가 꽤 막강한 힘을 발휘 할 수 있는 분야입니다. 전 단순히 반도체 만드는 회사에서 이런 기술을 연구하고 그것도 5년동안 큰 수익 못내는데도 계속 지원 해왔다는 사실을 높이사는 것입니다.

vPro 무었이 칭찬 받을만 한가?
우선, 간단한 예를 하나 들어보도록 하겠습니다. 보안이 잘 갖춰진 회사나 기관에서 일을 하려면 기본적으로 컴퓨터를 세팅하고 인증하고 기본적인 보안 유출 방지를 위한 세팅을 하게 됩니다.

하지만 과거엔 원격 관리 소프트웨어를 설치한뒤 관제 센터에서 이를 제어 했습니다. 하지만 절차가 복잡하고 세팅하는 동안 업무 진행이 힘들다는 점, 하드웨어에 바이러스 같은 문제 발생시 즉각 대처가 어렵다는점.. 등 다양한 이슈가 있습니다.

vPro는 KVM 원격 제어를 통해 방화벽 적용된 상황에서도 네트워크상에서 하드웨어를 물리적으로 제어가 가능하다는 점이 장점입니다. 결국 네트워크 인터페이스가 실시간으로 동작하면서 전원이 들어간 상태에서 이를 네트워크로 연결해 컴퓨터를 켰다가 끌 수 있지만 BIOS 컨트롤까지는 어렵습니다.

vPro는 vPro 기술을 이용해 바이오스 제어까지 진행되기에 네트워크를 통해 바이러스가 침투해 PC가 망가져도 일정부분 이런 부분을 물리적 상태 접근을 통해 일정부분 제어가 가능합니다.

전 회사의 컴퓨터를 전원 관리를 위해 명령어 하나로 껐다가 켤 수도 있고, 은행에 비치 된 ATM 단말기 제어와 관리를 위해서 하드웨어 파손인 경우만 아니면 사람을 파견하지 않고도 원격 제어가 가능합니다.

vPro 다른 기능은 무었을 지원하나?
인텔에서 말하는 vPro 라인업은 보통 i5 - 2400, 2500 라인업을 가지고 있다고 한다. 제품 특성상 기능상 차별점이 있는데 위에 설명한 기능적 성능 이외에 저전력 부분을 좀 더 강화한 것이 특징이라고 합니다.

하이퍼스레딩, 터보부스트, 그래픽등에서 저전력 향상시켰다고 하네요.

vPro 패키지는 단순히 CPU에 국한하지 않습니다. 프로세스, 칩셋, 네트워크 카드까지를 vPro 라인업으로 패키지로 구성해야 제대로 된 vPro 제품군이 된다고 합니다.

제품에 vPro 표시가 없는 경우는 Q67 코드가 있으면 vPro 라인업이라고 하니 참고하시고요. vPro의 기술적 내용을 좀 더 설명 드리자면 칩셋에 M데몬(Management machine)을 만들어 동작하게 해서 기업 네트워크에 동작하는 vPro의 진행 상태 모니터링 합니다. (관제실에서 M데몬을 vPro (관제 서비스 클라이트)를 실행해 서비스와 보안 관리를 담당합니다)

vPro에는 칩셋 컨트롤 인증이 된 하드웨어에 한해서 활용 되는데 이런 기술을 액티브 매니지먼트 기술이라고해서 AMT라고 합니다. vPro 운영을 위한 관제 시스템을 구축후 AMT를 이용해 회사내에 있는 모든 PC(vPro 기능을 지원하는)를 인증하면 원격 통합 관리가 되는 것이죠.

또, OTP(원타임패스워드)를 한 단계 더 보완한 IPT기능도 관심 대상입니다. OTP는 어떤 PC에서나 사용 할 수 있다는 점 때문 해커들의 공격 수단으로 악용될 수 있는데 반해, 어떤 사이트에 접속하거나 어떤 정보를 가져올 때 반드시 지정된 노트북을 통해서만 이용 가능하도록 해야 할때 유용하게 IPT를 사용 할 수 있다고 합니다.

ITP는 칩셋단에서 뿌려주는 암호와 코드를 넣어서 인증을 받는 것인데 바로 이것이 OTP를 보완하는 기술인 것이지요.

이 밖에 vPro는 도난방지(AT) 기능도 지원합니다. 이 기능을 통해 도난당한 노트북을 훔친 사람이 사용하지 못하도록 시스템 비 활성화가 진행되고 분실 된 노트북의 전원이 켜지면 몇 분 이내에 관리자가 3G 모바일 네트워크를 통해 암호화 및 인증 과정을 거친 SMS 메시지로 '포이즌필'을 전송해 분실 노트북을 찾을 수 있는 기능을 제공하는 것이 특징이라고 합니다.

vPro 동작 방법은?
인텔에서는 vPro 기술이 보안과 바이러스에 강하다고 하는데 이유는 이런 문제 요소가 하드웨어에 침입하기 전에 메인보드의 vPro 칩셋에서 M 데몬이 자동으로 하드웨어 상태를 체크해 같이 장착되어 있는 플래시 메모리에 해당 상태정보를 올려 실시간으로 모니터링 할 수 있게한다고 합니다.

즉, 바이러스 프로그램을 지우거나 프로그램 프로세스가 꺼져 있어 컨트롤이 어렵고 컴퓨터마저 꺼져있거나 비동작 상태에서 vPro가 동작해 하드웨어 차원의 물리적 컨트롤을 진행한답니다.

물리적 레벨에서 하드웨어 컨트롤을 이야기하는 것이기 때문에 랜드라이버가 삭제되더라도 랜카드를 구동시키고 운용 시킬 수 있다. 즉, 컴퓨터가 리부팅이 되던 어떤 상태간에 네트워크로 VPRO 가 탑제된 컴퓨터만 연결되어 있으면 자동으로 컴퓨터를 끄고/켤수 있음은 물론 원격지의 컴퓨터에서 CD롬이 하드웨어적으로 설치가 되있는경우 장치관리자에서 CD롬 드라이버가 삭제가 되더라도 하드웨어 레벨에서 처리할 수 있어서 원격지에서 프로그램 설치가 가능하다.

또한, PC에 필러링 알고리즘을 삽입해 이상한 패키지나 프로그램이 네트워크를 통해 하드웨어에 접근시 체크해 웜바이러스의 경우는 이 기술로 차단 할 수 있다고 합니다.

AMT 기술의 유용성은 어떻게 확보되나?
관리자가 VPRO를 이용해 하드웨어 유휴 상태에서 바이오스 화면을 보고 관리 하는 것을 지원하는 것이 이 기술의 핵심입니다. IDE Redirection 기능은 원격지에서 PC에 OS 설치가 가능한 연걸을 제공하는 것이 특징입니다.

다른 관리 소프트웨어는 리부팅시 연결이 끊기는 문제가 발생하지만 리부팅이 되더라도 연결이 지속적으로 연결되어 프로그래밍 설치와 관리를 끝까지 할 수 있다는 장점이 있습니다.

이것이 인텔이 제시하는 최고의 핵심 요소인 것이지요.

vPro 만으로 모든것이 가능한가?
사실 그렇지는 않습니다. 정말 제대로 vPro 기술을 이용해 관제와 관리 등 기업이 요구하는 요구사항을 만족 시키기 위해서는 SDK와 API를 활용해 하드웨어를 물리적으로 연결하는 소프트웨어를 만들어야 합니다.

어떤면에서 이것이 최대 약점일 수 있습니다. vPro 기술을 제대로 응용하기 위해서는 이 기술을 활용 할 수 있는 소프트웨어 지원이 필수 인데.. 문제는 이런 필수 기술이 정형화 된 소프트웨어로 제공되지 않고 있고 제공되더라도 기업마다 특수한 환경이 있는 만큼 이에 맞게 커스터마이징 해야 한다는 단점이 발생합니다.

국내에서 신한은행 등.. 몇몇 사례가 있지만 이렇게 개발하고 운영하는데 시간이 소요되고 여기에 개발 비용과 유지 관리 비용에 있어서도 vPro 업그레이드에 맞춰 꾸준히 증가 할 수 있다는 요소가 있어 도입의 장벽이 되기도 합니다.

vPro 장점이 있다면 단점도 있을텐데..
물론 단점도 존재합니다. 우선, 불규칙 패킷으로 공격하는 윔바이러스 같은 바이러스에는 대응 할 수 있지만 디도스 같은 일반적 패턴 공격에는 아직 취약성을 가지고 있습니다.

또, 관리자 관제 시스템에 접속 할 수 있는 패스워드의 경우 보안이 강화되어 있긴 하지만 관리자 PW가 뚫리면 아무리 최첨단 보안성을 제공해도 모든 네트워크 침입을 통해 공격이나 정보 취득이 가능한 문제를 않고 있는 것도 단점입니다.

그리고 가격도 일반 PC보다 비싸고 이 기술을 이용한 소프트웨어 개발하려면 비용이 추가로 들어 기업 입장에서 일반 PC나 노트북을 이용하고 관리 소프트웨어를 설치해 운용하는 것에 비해 가격적인 메리트가 크지 않는 것도 큰 단점으로 지적 될 수 있습니다.

5년동안 안팔린 이유와 인텔이 계속 지원하는 이유는?
이 부분까지 인텔 측에서 이야기해 주지는 않았지만 제 개인적으로 5년동안 안팔린 가장 큰 이유는 기술적 문제점 보다는 (현존하는 웬만한 기업용 솔루션에 비해 여러 장점이 있습니다.) 가격적 면이 가장 크다고 생각합니다.

vPro 라인업 자체 가격이 일반 인텔계열 제품보다 2~30% 비싸고 여기에 추가 소프트웨어 개발이 진행되면 저라도 사용하지 않을테니깐요.

그리고 결정적으로 클라우드 시스템을 도입하면 인텔 vPro 기술의 일부분을 모두 가져 갈 수 있으면서도 더 경제적인 대안이 될 수 있어서 이런 부분에서의 간극을 어떻게 매우느냐가 관건이라고 할 수 있을 것 같습니다.

결국, 인텔이 돈안되는 기술이지만 지속적으로 지원하는 이유는 역시 한번 이 시스템을 기업에 들여놓게 되면 기업은 기존 시스템 유지와 관리의 용의함을 위해서라도 해당 솔루션을 바로 바꾸기 힘들기 때문에 지속적으로 인텔 제품과 솔루션을 이용해야 합니다.

이 과정에서 인텔은 고정적인 매출과 제품 판매가 가능하다는 점을 그들은 노리고 있는 것이지요. 현재까지는 가격이 너무 높고 여러 기존 솔루션 제품들 때문에 시장 진입은 못하고 있지만 분명 꽤 괜찮은 기술인 것은 분명하기에 앞으로도 어떻게 될지 지켜 볼 일입니다.

결론, 인텔 vPro 성공하기 위해선 클라우드를 주목해야..
제가 볼때 인텔이 지속적으로 vPro를 밀고 있는 이유는 당분간 모바일 중시의 클라우드 체제로 전이가 쉽게 일어나지 않고 향후 몇년간은 PC와 노트북 중심의 Mobility 체제가 지속 될 가능성이 있다는 것에 더 높은 점수를 두고 있는 것 같습니다.

결국 이런 미래 분석상 모빌리티 라인업도 늦은 데다가 기존에 투여한 개발 비용과 여건을 고려하면 당분간 vPro 를 밀면서 시장 추이를 분석하는 것이 현명하다 판단한 것이 아닐까 생각됩니다.

하지만 위에서도 말했듯 모바일과 클라우드 체제는 이제 당면 과제가 되고 있고 이미 시스코나 삼성 같은 기업은 이 시대를 대비하고 이와 관련한 제품 라인어을 만들어내고 있는 중입니다.

인텔도 이런 비전에 대한 최소한의 로드맵은 제시해야 할 것이고 이 과정에서 vPro를 사장 시키고 싶지 않다면 기업 클라우드와 vPro 기술의 연계점을 찾아 새로운 가격 저렴한 vPro를 제시해야 이 기술이 팔릴 수 있다는 가장 간단한 결론이 내려지게 되죠.

그동안 이런 내막을 수박 겉핧기 식으로 알아왔전 저였기에 칭찬보단 욕을 많이 했습니다. 하짐나 정말 기술 내용을 보면 소프트웨어 한계를 극복해 하드웨어적 관리에선 꽤 독보적 기술이 될 수 있다는 생각이 들기도 했습니다.

그러나 역시 문제는 이 기술이 개인에게 적용하기 위해선 그 분야가 너무 기업용에 치우쳐져 있고 기업용 역시 너무 고가에 고 비용을 요구해서 은행이나 금융권 같은 곳이 아닌 이상 제품 솔루션을 판매하기 버겁단 어려움이 존재합니다.

좋은 기술을 만들어 자신들의 제품을 유지보수하며 지속적으로 판매하는 쪽에 포커싱을 더 맞춘다면 가격을 개선해야 하는데 가격과 수요를 모두 공략한다는 관점에선 다소 우려스러운 전략을 펼치고 있다고 생각됩니다.

어쨌든, 인텔이 프로세스가 아닌 기업용 시장 공략을 위해서 이런 노력을 하고 있다는 것을 다시 한번 엿볼 수 있었고 이런저런 다양한 기술 개발과 노력을 하고 있었다는 사실정도는 인정해야 한다는 생각을 남기며 어늘 글은 여기서 줄여야 겠습니다.

출처 : http://www.iamday.net/apps/article/talk/294/view.iamday

가상화 - 윈디하나의 솔라나라

JAESOO — Wed, 07 Oct 2015 19:35:03 +0000

분류: 솔라리스
설명: 솔라리스의 컨테이너(ZONE)에 대해서 설명 (2011-09-04)
위치: 윈디하나의 솔라나라: 가상화 (처음 오신 분은 솔라나라 이야기를 읽어주십시오)
윈디하나의 솔라나라 트위터 @solanara 출력하기

가상화(Virtualization)란?

가상화란 컴퓨팅 리소스의 추상화를 통해 다수의 운영 체제 또는 애플리케이션 이미지가 하나의 물리적 서버를 공유하도록 함으로써 총소유비용을 극적으로 절감하고 관리성을 개선할 수 있게 하는 프로세스를 말한다.

오라클의 ~~Virtualization Technology Center~~에 나와있었던 말이다. (내가 찾은것 중에서 가상화를 가장 잘 표현한 말이라 생각한다. 현재는 페이지가 삭제되어있다) 가상화를 쉽게 말하면 시스템 자원 추상화이고 이를 통해 비용 절감을 목적으로 한다. 목적이 비용 절감이기 때문에, 만약 가상화로 비용이 늘어난다면 하지 말아야 한다.

가상화 분류

구현에 의한 분류

※ 어떻게 가상화를 구현했느냐에 따라 아래와 같이 나누어진다. (아래의 내용중 일부는 위키피디아의 Vitualization항목에서 가져왔다. 위키피디아의 내용은 현재 수정된 상태다)

에뮬레이션(emulation, simulation): 에뮬레이션. PC에서 실행되는 수많은 게임 에뮬레이터도 이런 가상화 기술의 하나다. CPU를 포함한 모든 하드웨어를 가상으로 구현한다. 즉 옵코드(OpCode)가 달라도 실행 가능하다는 의미다. Bochs나 QEMU가 있다. 유일한 단점은 느리다는 것이다.
전가상화(Full-virtualization, Native-virtualization): 동일한 아키텍처에서 실행되는 Guest OS를 수정없이 그대로 띄워주는데 필요한 하드웨어를 모두 에뮬레이션 하는 형식으로 가상화 하는 것을 말한다. 쉽게 말해 CPU를 뺀 모든 하드웨어를 가상으로 구현한다. 하드웨어 에뮬레이터을 하이퍼바이저(Hypervisor)라 부른다. Oracle VM VirtualBox, VMware Workstation, VMware Server 등이 이에 속한다.
반가상화(Para-virtualization): 하드웨어 에뮬레이션 없이 하이퍼바이저(Hypervisor)를 통해 하이퍼바이저가 제공하는 API를 이용한 OS를 실행할 수 있는 가상화 방식이다. Guest OS를 하이퍼바이저의 API를 이용하도록 수정해야한다. VMware ESX Server, Xen, Solaris xVM Server, Sun Logical Domains 이 이에 속한다. 성능 저하가 크지 않아 각광받고 있는 기술이다.
OS레벨 가상화(OperatingSystem-level virtualization): OS상에서 같은 OS를 하나 더 사용하는것 처럼 꾸며주는 가상화이다. 당연히 OS의 수정이 필요하다. Solaris Containers, FreeBSD Jails, Linux Docker 가 이에 속한다. 가상화로 인한 속도저하가 없다고 생각해도 무방하다.

전가상화, 반가상화

※ 전가상화와 반가상화의 중요한 차이는 하이퍼 바이저, OS, 하드웨어의 관계이다.

전가상화
- OS는 하드웨어에 직접 액세스 하는것으로 인식 하지만 이 하드웨어는 하이퍼 바이저가 하드웨어를 에뮬레이션 한 것이다.
- OS입장에서 하드웨어를 자신이 소유한것으로 인식한다.
- 하이퍼바이저는 OS가 하드웨어에 주는 명령을 감시해 '하드웨어를 독점'하는 명령이 발생하면 별도로 핸들링 해주어야 한다. OS와 하드웨어 사이에서 중재하는 역할을 맡는다.
반가상화
- OS는 하드웨어에 하이퍼바이저가 제공한 API를 통해서 액세스 할 수 있다.
- OS입장에서 하드웨어를 자신이 소유하지 않고 있다는 것을 알고 있으므로 그에 대한 처리를 해준다.
- OS는 하드웨어를 독점하는 명령을 하지 않는다.

※ 솔라리스 10 최신 업데이트는 아래와 같이 지원한다.

OS레벨 가상화: Solaris Containers
전가상화: Oracle VM VirtualBox
반가상화: Sun Logical Domains

※ Illumos 최신 업데이트는 KVM을 추가로 지원한다.

전가상화 vs 반가상화

구분은 이렇게 해놓았지만, 이론적으로는 이렇다는 이야기고, 현재 출시되어있는 반가상화/전가상화 솔루션들도 실제로는 성능상의 문제로 전가상화와 반가상화를 넘나들며 구현되고 있다고 본다. 윈도를 포함한 대부분의 운영체제는 가상화 소프트웨어에 GuestOS로 들어가기 위해 이미 수정되어있으며, 부족한 부분은 Guest OS에 하이퍼바이저와 연동할 드라이버를 설치해 해결하고 있다. 필자는 전가상화, 반가상화 구분이 모호해진 이유가 VT-X, AMD-V 에서 제시한 Ring -1 때문이라고 본다. Ring -1 이 나온 이유중 하나가 Ring 0 에서 실행하는 운영체제를 운영체제 수정 없이 반 가상화로 실행하기 위함이다.

하이퍼바이저

하이퍼바이저(Hypervisor)는 호스트컴퓨터와 게스트 OS를 연결해주는 가상화 플랫폼이다. 크게 Type 1과 Type 2로 나뉜다.

Type 1: 하이퍼바이저가 하드웨어에서 바로 실행된다. (따라서 Type 1 하이퍼바이저는 부팅이 가능하다) 보통 Type 1은 반 가상화를 지원할 수 있다.
Type 2: 하이퍼바이저는 OS상에서 실행된다. Type 2는 전 가상화를 지원한다.

Type 1 하이퍼바이저는 부팅 가능하다는 것에서 OS와 비슷하지만 OS는 아니다. OS의 필수기능중 몇가지가 빠져있기 때문이다. 어플리케이션을 실행할 수 없다. (좀 더 복잡한 바이오스 정도로 보는것이 좋을지도 모르겠다)

가상화 지원을 위한 하드웨어 기술

[전가상화]와 [반가상화]를 사용할 때 하드웨어에서 성능 향상에 필요한 기능을 지원해주면 좀 더 빠르게 작동할 수 있다. 주로 리매핑 기술과 관련되어있다. 하드웨어 가상화 기술이 지원되는 장비와 하이퍼바이저와 게스트OS를 사용해, 가상화로 인한 성능 저하 비율을 1% 이하로 가져가는게 목표다. 필자가 생각에는 현재 가상화 기술로도 비용 절감을 실현할 수 있다고 생각한다. 아래는 현재 상용화된 가상화를 위한 하드웨어 기술들이다.

AMD-V, VT-x
CPU에서 지원하는 가상화 성능 향상 기술이다. AMD는 AMD-V, Intel은 VT-x이라 명명했다. 개발 당시 인텔에서는 Vanderpool이라고도 불렸다. 커널은 Ring 0에서 작동해 장치를 제어하게 되는데, 유저 어플인 GuestOS는 Ring 3에서 작동하기 때문에 Ring 0가 필요한경우 복잡한 과정을 거쳐야 했다. 이에 Ring -1에 해당하는 모드를 추가해(VT-x의 경우 10개의 VM* 명령셋을 추가) 하이퍼바이저를 만들어 성능을 높일 수 있도록 했다.
Nested Page
2세대 AMD-V, VT-x 라고도 불리는 Nested Page는 MMU(Memory Management Unit)를 가상 머신에 최적화시키는 CPU의 기능이다. 메모리를 많이 참조하는 어플의 경우 2배 이상의 성능향상이 있다. 인텔의 경우 EPT(Extended Page Table)로 명명했고, AMD의 경우 RVI(Rapid Virtualization Indexing)로 명명했다. AMD의 경우 페넘II 부터, 인텔의 경우 i3, i5, i7 이상의 제품군에서 사용할 수 있는데, 인텔은 CPU마다 지원사항이 다르다. 인텔 CPU의 지원여부는 About Intel® Virtualization Technology을 읽어보자. Ivy Bridge기반 i3, i5, i7은 현재 모두 EPT를 지원한다.
IOMMU
IOMMU(Input/Output Memory Management Unit)는 Intel 칩셋의 VT-d, AMD의 AMD-Vi(IOMMU), SUN의 Device Virtual Memory Access등을 지원하는 마더보드를 사용하면 (정확히는 칩셋에서 지원해야 한다) 성능을 더 향상시킬 수 있다. IOMMU는 GPU에서 사용되던 GART(Graphics Address Remapping Table)와 비슷한 기술로 메모리및 DMA 리매핑 기술이다. 이 글을 쓰는 시점에서 IOMMU 는 890FX, Q35, Q45, Q57, X58, Q67, B75, Q77, 5x00, 3450 칩셋을 채용한 마더보드의 일부에서 지원된다. 인텔 마더보드의 경우 Compatibility with Intel® Virtualization Technology (Intel® VT)에서 지원되는 마더보드를 확인해볼 수 있다.
VT-c
인텔의 이더넷 가상화 기술이다. 가상 이더넷 장치를 추가할 때 하드웨어적인 가속을 해준다.

계통도

출처: Virtualization: State of the Art (PDF)

 ┌──┐ │ＶＭ│ └─┬┘ ┌───────┴───────┐ 시스템가상화 프로세스가상화 ┌─────┴─────┐ ┌───┴───┐ │ │ ＨＷ가상화 ＨＷ에뮬레이션 │ │ 에뮬레이터 ┌───┴───┐ 다중시스템 동적변환기 Ｔｙｐｅ 1 Ｔｙｐｅ 2 ┌─────┬─┘ ┌───┼───┐ VirtualBox ┌─┴─┐ 멀티태스크 ＯＳ변환 ISA&ABI ISA&OS Language Java 반가상화 전가상화 │ xVM ┌─┴─┐ ＯＳ가상화 Zone H/W지원 바이너리변환 xVM

Solaris Containers (Zones)

Zones

존(Zones)라고는 하지만 존은 솔라리스 컨테이너(Solaris Containers)의 일부이다. Solaris containers = Zones + Resource Management 라 볼 수 있다.
참고
- System Administration Guide: Oracle Solaris Containers-Resource Management and Oracle Solaris Zones
- Oracle Solaris Containers

※ Zone의 상태 차트. [존을 생성후 인스톨 하고, 준비한 다음 부팅하면 존이 실행된다]라고 이해하면 된다. 각각의 과정을 모두 거쳐야 한다.

 ┌───────┐ｃｒｅａｔｅ┌────┐ｉｎｓｔａｌｌ ┌─────┐ｒｅａｄｙ┌─────┐ ┌────┐ │ │─────→│ＣＯＮ │────────→│ │────→│ │ｂｏｏｔ│ │ │ＮＯＴ │ │ＦＩＧ │ │ＩＮＳＴ │ │ＲＥＡＤＹ│───→│ＲＵＮＮ│ │ＣＲＥＡＴＥＤ│←─────│ＵＲＥＤ│←────────│ＡＬＬＥＤ│←────│ │ │ＩＮＧ │ └───────┘ｄｅｌｅｔｅ└────┘ｕｎｉｎｓｔａｌｌ└─────┘ｈａｌｔ └─────┘ └────┘ ↑ ｓｈｕｔｄｏｗｎ │ └──────────────────────┘ 주) incomplete 상태는 install 하다가 실패한 경우이다.

 root@wl ~ # zoneadm list -cv 1) ID NAME STATUS PATH BRAND IP 0 global running / native shared root@wl ~ # mkdir -m 700 /export/zone1 2) root@wl ~ # zonecfg -z zone1 3) zone1: 그런 영역은 구성되지 않음 새 영역 구성을 시작하려면 'create'을(를) 사용하십시오. zonecfg:zone1> create zonecfg:zone1> set zonepath=/export/zone1 zonecfg:zone1> set autoboot=true zonecfg:zone1> add inherit-pkg-dir zonecfg:zone1:inherit-pkg-dir> set dir=/opt zonecfg:zone1:inherit-pkg-dir> end zonecfg:zone1> add net zonecfg:zone1:net> set address=192.168.0.20 zonecfg:zone1:net> set physical=vmxnet0 zonecfg:zone1:net> end zonecfg:zone1> verify zonecfg:zone1> commit zonecfg:zone1> exit root@wl ~ # cat /etc/zones/zone1.xml 4) <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE zone PUBLIC "-//Sun Microsystems Inc//DTD Zones//EN" "file:///usr/share/lib/xml/dtd/zonecfg.dtd.1"> <!-- DO NOT EDIT THIS FILE. Use zonecfg(1M) instead. --> <zone name="zone1" zonepath="/export/zone1" autoboot="true"> <inherited-pkg-dir directory="/lib"/> <inherited-pkg-dir directory="/platform"/> <inherited-pkg-dir directory="/sbin"/> <inherited-pkg-dir directory="/usr"/> <inherited-pkg-dir directory="/opt"/> <network address="192.168.0.20" physical="vmxnet0"/> </zone> root@wl ~ # zoneadm list -cv 4) ID NAME STATUS PATH BRAND IP 0 global running / native shared - zone1 configured /export/zone1 native shared root@wl ~ # zonecfg -z zone1 info 4) zonename: zone1 zonepath: /export/zone1 brand: native autoboot: true bootargs: pool: limitpriv: scheduling-class: ip-type: shared inherit-pkg-dir: dir: /lib inherit-pkg-dir: dir: /platform inherit-pkg-dir: dir: /sbin inherit-pkg-dir: dir: /usr inherit-pkg-dir: dir: /opt net: address: 192.168.0.20 physical: vmxnet0 root@wl ~ # zoneadm -z zone1 install 5) Preparing to install zone <zone1>. Creating list of files to copy from the global zone. Copying <2383> files to the zone. Initializing zone product registry. Determining zone package initialization order. Preparing to initialize <1089> packages on the zone. Initializing package <1089> of <1089>: percent complete: 100% Initialized <1089> packages on zone. Zone <zone1> is initialized. Installation of <1> packages was skipped. The file </export/zone1/root/var/sadm/system/logs/install_log> contains a log of the zone installation. root@wl ~ # zoneadm list -cv | grep zone1 - zone1 installed /export/zone1 native shared root@wl ~ # zoneadm -z zone1 ready 6) root@wl ~ # zoneadm list -cv | grep zone1 1 zone1 ready /export/zone1 native shared root@wl ~ # zoneadm -z zone1 boot 7) root@wl ~ # zoneadm list -cv | grep zone1 1 zone1 running /export/zone1 native shared root@wl ~ # zlogin zone1 8) [영역 'zone1' pts/3에 연결됨] Sun Microsystems Inc. SunOS 5.10 Generic January 2005 # Ctrl+D ['zone1' pts/3 영역에 대한 연결이 닫힘] root@wl ~ # zlogin -C zone1 8) [영역 'zone1' 콘솔에 연결됨] zone1 console login: zone1 console login: ~. [영역 'zone1' 콘솔에 대한 연결이 닫힘] root@wl ~ # zoneadm -z zone1 halt 9) root@wl ~ # zoneadm list -cv | grep zone1 - zone1 installed /export/zone1 native shared root@wl ~ # zoneadm -z zone1 uninstall 10) zone1 영역을 uninstall하시겠습니까? (y/[n])? y root@wl ~ # zoneadm list -cv | grep zone1 - zone1 configured /export/zone1 native shared root@wl ~ # zonecfg -z zone1 11) zonecfg:zone1> delete zone1 영역을 삭제하시겠습니까? (y/[n])? y zonecfg:zone1> exit root@wl ~ # zoneadm list -cv ID NAME STATUS PATH BRAND IP 0 global running / native shared root@wl ~ #

1) ID값 0을 가진 global이란 존은 항상 생성되어있다. 솔라리스의 기본 존이다. 여기에 zone1 이라는 존을 생성할 것이다.
2) zone1을 생성하기 위한 디렉토리를 미리 만들어놓는다. 반드시 권한을 700으로 해야한다.
3) zone1의 설정 파일을 생성한다. [add net]뒤의 내용은 각자의 환경에 맞게 수정해야 한다.
4) /etc/zones/zone1.xml 파일이 생성되었고, zone1이 설정되었음을 알 수 있다.
5) install 명령은 한참 걸리기도 하고 시스템에 디스크 부하를 많이 준다.
6) zone1을 ready상태로 전환한다.
7) zone1을 boot상태로 전환한다. ready상태가 아니고 installed상태라면 자동으로 ready로 전환후 boot상태로 다시 전환한다.
8) 로그인은 zlogin 프로그램을 이용한다. -C 옵션을 이용하면 '콘솔'에 로그인하는 것과 같아진다. -C 를 사용하면 다른 화면을 보게될 것이며 권한도 다르다. 콘솔에서 접속을 해제하려면 로그오프 한후 ~. 을 입력한다.
9) zone1에 로그인한 후에 halt명령을 수행하거나, 존에서 나온후 zoneadm -z zone1 halt명령을 주면 존이 종료되며 installed상태로 돌아간다. halt외에 reboot를 사용할 수도 있다.
10 언인스톨 한다.
11) 설정 파일을 삭제한다.

Branded Zones

zone생성시 파라메터를 변경해 리눅스용 존을 생성할 수 있다. 리눅스 바이너리 파일을 수정없이 실행시킬 수 있다.
리눅스 브랜드 존에서는 리눅스 커널 2.4를 사용하는 GNU LibC기반의 어플리케이션만 실행 가능하다.
오픈 솔라리스의 경우 브랜드 존에 대해 리눅스 어플리케이션 호환이 더 좋다. 오라클도 띄울 수 있다. 솔라리스에서는 안되는듯. ^^

LX존 지원 종료

오라클에서는 Linux branded zone은 더이상 지원하지 않을 것이라고 밝혔다.

 root@wl ~ # wget http://www.solanara.net/downloads/centos39.distro 1) root@wl ~ # cp centos39.distro /usr/lib/brand/lx/distros/ root@wl ~ # mkdir CentOSISO root@wl ~ # cd CentOSISO root@wl ~/CentOSISO # wget http://www.solanara.net/downloads/CentOS-3.9-i386-binDVD.iso 2) root@wl ~/CentOSISO # digest -a md5 CentOS-3.9-i386-binDVD.iso 472540be581948a64c7cd052bac0d015 root@wl ~/CentOSISO # cd .. root@wl ~ # mkdir -m 700 /export/lxzone 3) root@wl ~ # zonecfg -z lxzone 4) lxzone: 그런 영역은 구성되지 않음 새 영역 구성을 시작하려면 'create'을(를) 사용하십시오. zonecfg:lxzone> create -t SUNWlx zonecfg:lxzone> set zonepath=/export/lxzone zonecfg:lxzone> set autoboot=true zonecfg:lxzone> add net zonecfg:lxzone:net> set address=192.168.0.30 zonecfg:lxzone:net> set physical=e1000g0 zonecfg:lxzone:net> end zonecfg:lxzone> add capped-memory zonecfg:lxzone:capped-memory> set locked=256m zonecfg:lxzone:capped-memory> end zonecfg:lxzone> exit root@wl ~ # zoneadm list -cv ID NAME STATUS PATH BRAND IP 0 global running / native shared - lxzone configured /export/lxzone lx shared root@wl ~ # zoneadm -z lxzone install -d ~/CentOSISO all 5) Installing distribution 'CentOS 3.9'... Installing cluster 'all' Installing miniroot for zone 'lxzone'. Attempting to locate 31 packages... Installing 31 miniroot packages... Setting up the initial lx brand environment. System configuration modifications complete. Duplicating miniroot; this may take a few minutes... Booting zone miniroot... Miniroot zone setup complete. Performing full install for zone 'lxzone'. Attempting to locate 956 packages... Installing zone 'lxzone' from ISO "/root/CentOSISO/CentOS-3.9-i386-binDVD.iso". Installing 956 packages; this may take several minutes... Completing installation; this may take a few minutes. Setting up the initial lx brand environment. System configuration modifications complete. Installation of CentOS 3.9 to zone 'lxzone' completed 2009년 2월 13일 금요일 오전 11시 39분 21초. Installation of zone 'lxzone' completed successfully. Details saved to log file: "/export/lxzone/root/var/log/lxzone.install.10794.log" root@wl ~ # zoneadm -z lxzone boot 6) root@wl ~ # zlogin -C lxzone 7) [영역 'lxzone' 콘솔에 연결됨] CentOS release 3.9 (Final) Kernel 2.4.21 on an i686 lxzone login: root [root@lxzone root]# uname -a Linux lxzone 2.4.21 BrandZ fake linux i686 i686 i386 GNU/Linux [root@lxzone root]# vi /etc/sysconfig/network 8) NETWORKING=yes HOSTNAME=lxzone [root@lxzone root]# vi /etc/hosts 192.168.0.30 lxzone [root@lxzone root]# reboot

1) centos39.distro 파일을 받는다. 솔라리스 10에서는 CentOS 3.9를 정식지원하지 않는다. 필자가 CentOS 3 Release Notes u9를 참고해 직접 만들었다.
2) CentOS 3.9의 DVD이미지를 받는다. 현재 존재하는 대부분의 미러에서 받을 수 없기 때문에 솔라나라에 링크 걸어둔다.
3) lxzone 디렉토리를 만들어 놓는다. 존 파일은 여기에 생성할 것이다.
4) lxzone 을 설정한다. 생성시 create -t SUNWlx 명령을 준다는 것이 다르다.
5) BRAND가 lx라는것이 다르다. 인스톨시 CentOS패키지가 있는 tar.bz2파일의 위치를 -d 옵션을 이용해 넣어준다. 만약 CentOS 3.8의 ISO 파일들이 /root/CentOSISO 에 있다면 [zoneadm -z lxzone install -d /root/CentOSISO all] 처럼 실행시켜도 된다. tar파일보다는 오래 걸리지만 CentOS가 더 최신 버전인듯 하다. 필자는 이렇게 사용한다.
6) 존의 설치가 끝나면 존을 부팅시킨다.
7) 존의 콘솔에 연결하면 내용을 확인해볼 수 있다.
8) 네트워크를 활성화한 한다. network 파일을 수정하고 재시작 해주어야 한다.(존을 재시작 한다) hosts파일도 수정해야 한다.

Oracle VM VirtualBox

Oracle VM VirtualBox는 독일의 이노텍(Innotek)에서 만들던 가상화 소프트웨어다. 썬 마이크로시스템에서 이노텍을 인수하고, 다시 오라클이 썬을 인수해 지금은 오라클의 소유가 되었다. VMWare Workstation 정도로 생각하면 된다. 이노텍은 마이크로 소프트의 VirtualPC 개발에도 참여했었다. (윈도우와도 많은 호환성을 보인다) 솔라리스에서 사용할 수 있는 최고의 전 가상화 소프트웨어이기도 하다.
VirtualBox 는 솔라리스 10 x86/x64 버전에서만 작동한다.

 root@wl ~/src # wget http://download.virtualbox.org/virtualbox/4.3.10/VirtualBox-4.3.10-93012-SunOS.tar.gz root@wl ~/src # mkdir VirtualBox root@wl ~/src # cd VirtualBox root@wl ~/src/VirtualBox # tar xvfz ../VirtualBox-4.3.10-93012-SunOS.tar.gz root@wl ~/src/VirtualBox # pkgadd -d VirtualBox-4.3.10-SunOS-amd64-r93012.pkg The following packages are available: 1 SUNWvbox Oracle VM VirtualBox (i386) 4.3.10,REV=2014.03.26.20.08.93012 Select package(s) you wish to process (or 'all' to process all packages). (default: all) [?,??,q]: all 패키지 예 <SUNWvbox>(을)를 </root/src/VirtualBox/VirtualBox-4.3.10-SunOS-amd64-r93012.pkg>에서 처리 중 Oracle VM VirtualBox(i386) 4.3.10,REV=2014.03.26.20.08.93012 Oracle Corporation ## checkinstall 스크립트 실행 Checking package dependencies... Done. ## 패키지 정보 처리 중 ## 시스템 정보 처리 중 ## 디스크 공간 요구 검증 중 ## 이미 설치되어 있는 패키지와의 충돌 여부를 확인하고 있습니다. ## setuid/setgid 프로그램 점검 다음의 파일은 setuid/setgid 권한과 함께 설치되는 중입니다: /opt/VirtualBox/amd64/VBoxHeadless <setuid root> /opt/VirtualBox/amd64/VBoxNetAdpCtl <setuid root> /opt/VirtualBox/amd64/VBoxNetDHCP <setuid root> /opt/VirtualBox/amd64/VBoxNetNAT <setuid root> /opt/VirtualBox/amd64/VBoxSDL <setuid root> /opt/VirtualBox/amd64/VirtualBox <setuid root> 이 파일들을 setuid/setgid 파일로 설치하겠습니까? [y,n,?,q] y 이 패키지에는 설치 과정 중 수퍼유저 권한으로 실행될 스크립트가 있습니다. <SUNWvbox>(을)를 계속 설치하겠습니까 [y,n,?] y Oracle VM VirtualBox(을)를 <SUNWvbox>(으)로 설치 ## 1째 (전체: 1) 부분 설치 /etc/hostname.vboxnet0 ... /var/svc/manifest/application/virtualbox/virtualbox-autostart.xml [ 클래스 <none> 검증 ] /opt/VirtualBox/VBoxAutostart <연결된 경로 이름> /opt/VirtualBox/VBoxHeadless <연결된 경로 이름> /opt/VirtualBox/VBoxISAExec <연결된 경로 이름> /opt/VirtualBox/VBoxManage <연결된 경로 이름> /opt/VirtualBox/VBoxSDL <연결된 경로 이름> /opt/VirtualBox/VBoxSVC <연결된 경로 이름> /opt/VirtualBox/VBoxTestOGL <연결된 경로 이름> /opt/VirtualBox/VBoxZoneAccess <연결된 경로 이름> /opt/VirtualBox/VirtualBox <연결된 경로 이름> /opt/VirtualBox/vboxwebsrv <연결된 경로 이름> /opt/VirtualBox/webtest <연결된 경로 이름> [ 클래스 <manifest> 검증 ] ## 설치 후 스크립트 실행 Checking for older bits... Installing new ones... Detected Solaris 10 Version Generic_147441-01 Loading VirtualBox kernel modules... - Loaded: Host module - Loaded: NetAdapter module - Loaded: NetFilter (STREAMS) module Configuring services... - Loaded: Zone access service Installing MIME types and icons... Installing Python bindings... - Skipped: Python 2.4 install is unusable - Installed: Bindings for Python 2.6 Updating the boot archive... <SUNWvbox>(이)가 성공적으로 설치되었습니다. root@wl ~/src/VirtualBox # VirtualBox 1)

1) VirtualBox를 실행한다. /opt/VirtualBox/UserManual.pdf 에 매뉴얼이 있다.

Oracle VM Server for SPARC

Sparc 시스템에서 가상화를 위한 소프트웨어다. Sun Logical Domains 라고 불렸지만 오라클에 인수된 이후 Oracle VM Server for SPARC으로 이름이 변경되었다.
sun4v(SUN Ultra Sparc T1 CPU 이상을 사용한 시스템, 정확하게는 썬의 CoolThreads 기술이 적용된 CPU를 사용하는 시스템), Solaris 10 u4 이후 부터 지원되는 가상화 방식이다
솔라리스 10이 설치된 상태에서 Oracle VM Server for SPARC을 받아 설치하면 된다고 한다.
해보지 않은 관계로 더이상 언급하는 건 무리다. ^O^

출처 : http://www.solanara.net/solanara/virtualization

인텔® 가상화 기술 정보

JAESOO — Wed, 07 Oct 2015 19:33:34 +0000

인텔® 가상화 기술 정보

IT 환경에서 관리 효율과 보안 및 유연성을 높여주는 가상화 기술 소프트웨어 기반 가상화 솔루션과 결합된 하드웨어 지원 인텔® 가상화 기술(인텔® VT)과 같은 가상화 기술은 단일 서버 또는 PC에 여러 환경을 통합함으로써 최대의 시스템 활용도를 제공합니다. 기본 하드웨어에서 소프트웨어를 추출하면, 새로운 사용 모델의 세계가 열려 비용 절감, 관리 효율 증가, 보안 강화 등의 이점이 있으며 재난 발생 시 컴퓨팅 인프라가 보다 탄력적으로 대처할 수 있습니다.

자세한 기술 정보는 다음을 참조하십시오: http://www.intel.com/technology/virtualization/

사용 중인 시스템의 프로세서가 인텔® VT를 지원하는지 확인하려면 인텔® 프로세서 식별 유틸리티 사용을 고려해 보십시오. 이 유틸리티는 다음 웹사이트에서 다운로드할 수 있습니다: 다운로드 센터

프로세서 제품군		인텔® VT-x 지원	인텔® EPT 지원
Intel® High End Desktop Processors		예	예
Intel® Core™ M Processors		예	예
5th Generation Intel® Core™ i7 Processors		예	제품에 따라 다름
Intel® Core™ i7-5900 Mobile Processor Series	i7-5950HQ	예	아니요
Intel® Core™ i7-5800 Mobile Processor Series	i7-5850EQ	예	예
Intel® Core™ i7-5800 Mobile Processor Series	i7-5850HQ	예	아니요
Intel® Core™ i7-5700 Mobile Processor Series	i7-5700EQ i7-5750HQ i7-5700HQ	예	예
Intel® Core™ i7-5700 Desktop Processor Series	i7-5775R i7-5775C	예	예
Intel® Core™ i7-5600 Mobile Processor Series	i7-5650U i7-5600U	예	예
Intel® Core™ i7-5500 Mobile Processor Series	i7-5557U i7-5550U i7-5500U	예	예
5th Generation Intel® Core™ i5 Processors		예	제품에 따라 다름
Intel® Core™ i5-5600 Desktop Processor Series	i5-5675R i5-5675C	예	예
Intel® Core™ i5-5500 Desktop Processor Series	i5-5575R	예	예
Intel® Core™ i5-5300 Mobile Processor Series	i5-5350U i5-5300U	예	예
Intel® Core™ i5-5300 Mobile Processor Series	i5-5350H	예	아니요
Intel® Core™ i5-5200 Mobile Processor Series	i5-5287U i5-5257U i5-5250U i5-5200U	예	예
5th Generation Intel® Core™ i3 Processors		예	예
4th Generation Intel® Core™ i7 Extreme Processor		예	예
4th Generation Intel® Core™ i7 Processors		예	예
4th Generation Intel® Core™ i5 Processors		예	예
4th Generation Intel® Core™ i3 Processors		예	예
3rd Generation Intel® Core™ i7 Extreme Processor		예	예
3rd Generation Intel® Core™ i7 Processors		예	예
3rd Generation Intel® Core™ i5 Processors		예	예
3rd Generation Intel® Core™ i3 Processors		예	예
2nd Generation Intel® Core™ i7 Extreme Processor		예	예
2nd Generation Intel® Core™ i7 Processors		예	예
2nd Generation Intel® Core™ i5 Processors		예	예
2nd Generation Intel® Core™ i3 Processors		예	예
Previous Generation Intel® Core™ i7 Extreme Processor		예	예
Previous Generation Intel® Core™ i7 Processor		예	예
Previous Generation Intel® Core™ i5 Processor		예	예
Previous Generation Intel® Core™ i3 Processor		예	예
Intel® Xeon® Processor E7 v3 Family		예	예
Intel® Xeon® Processor E7 v2 Family		예	예
Intel® Xeon® Processor E7 Family		예	예
Intel® Xeon® Processor E5 v3 Family		제품에 따라 다름	제품에 따라 다름
Intel® Xeon® Processor E5-4600 v3 Product Family	E5-4669V3 E5-4667V3 E5-4660V3 E5-4655V3 E5-4650V3 E5-4640V3 E5-4627V3 E5-4620V3 E5-4610V3	예	예
Intel® Xeon® Processor E5-2600 v3 Product Family	E5-2699V3 E5-2698V3 E5-2697V3 E5-2695V3 E5-2690V3 E5-2687WV3 E5-2683V3 E5-2680V3 E5-2670V3 E5-2667V3 E5-2660V3 E5-2658AV3 E5-2658V3 E5-2650LV3 E5-2650V3 E5-2648LV3 E5-2643V3 E5-2640V3 E5-2637V3 E5-2630LV3 E5-2630V3 E5-2628LV3 E5-2623V3 E5-2620V3 E5-2618LV3 E5-2609V3 E5-2608LV3 E5-2603V3	예	예
Intel® Xeon® Processor E5-2600 v3 Product Family	E5-2685V3	아니요	아니요
Intel® Xeon® Processor E5-2400 v3 Product Family	E5-2438LV3 E5-2428LV3 E5-2418LV3 E5-2408LV3	예	예
Intel® Xeon® Processor E5-1600 v3 Product Family	E5-1603V3 E5-1607V3 E5-1620V3 E5-1630V3 E5-1650V3 E5-1660V3 E5-1680V3	예	예
Intel® Xeon® Processor E5-1400 v3 Product Family	E5-1428LV3	예	예
Intel® Xeon® Processor E5 v2 Family		예	예
Intel® Xeon® Processor E5 Family		예	예
Intel® Xeon® Processor E3 v5 Family		예	예
Intel® Xeon® Processor E3 v4 Family		예	예
Intel® Xeon® Processor E3 v3 Family		예	예
Intel® Xeon® Processor E3 v2 Family		예	예
Intel® Xeon® Processor E3 Family		예	예
Intel® Xeon® Processor D Family		예	예
Intel® Xeon® Processor 7000 Sequence		예	제품에 따라 다름
Intel® Xeon® Processor 7500 Series	X7560 X7550 X7542 L7555 L7545 E7540 E7530 E7520	예	예
Intel® Xeon® Processor 7400 Series	X7460 L7455 L7445 E7450 E7440 E7430 E7420	예	아니요
Intel® Xeon® Processor 7300 Series	X7350 L7345 E7340 E7330 E7320 E7310	예	아니요
Intel® Xeon® Processor 7200 Series	E7220 E7210	예	아니요
Intel® Xeon® Processor 7100 Series	7150N 7140N 7140M 7130N 7130M 7120N 7120M 7110N 7110M	예	아니요
Intel® Xeon® Processor 7000 Series	7041 7040 7030 7020	예	아니요
Intel® Xeon® Processor 6000 Sequence		예	예
Intel® Xeon® Processor 5000 Sequence		예	제품에 따라 다름
Intel® Xeon® Processor C5500 series	LC5528 LC5518 EC5549 EC5539 EC5509	예	예
Intel® Xeon® Processor C3500 series	LC3528 LC3518 EC3539	예	예
Intel® Xeon® Processor 5600 Series	X5690 X5687 X5680 X5677 X5675 X5672 X5670 X5667 X5660 X5650 X5647 L5640 L5638 L5630 L5618 L5609 E5649 E5645 E5640 E5630 E5620 E5607 E5606 E5603	예	예
Intel® Xeon® Processor 5500 Series	X5570 X5560 X5550 W5590 W5580 L5530 L5520 L5518 L5508 L5506 E5540 E5530 E5520 E5507 E5506 E5504 E5503 E5502	예	예
Intel® Xeon® Processor 5400 Series	X5492 X5482 X5472 X5470 X5460 X5450 L5430 L5420 L5410 L5408 E5472 E5462 E5450 E5440 E5430 E5420 E5410 E5405	예	아니요
Intel® Xeon® Processor 5300 Series	X5365 X5355 L5335 L5320 L5318 L5310 E5345 E5335 E5320 E5310	예	아니요
Intel® Xeon® Processor 5200 Series	L5248	예	예
Intel® Xeon® Processor 5200 Series	X5272 X5270 X5260 L5240 L5238 L5215 E5240 E5220 E5205	예	아니요
Intel® Xeon® Processor 5100 Series	5148 5138 5133 5128 5113 5160 5150 5140 5130 5120 5110	예	아니요
Intel® Xeon® Processor 5000 Series	5080 5070 5063 5060 5050 5040 5030	예	아니요
Intel® Xeon® Processor 3000 Sequence		제품에 따라 다름	제품에 따라 다름
Intel® Xeon® Processor 3600 Series	W3690 W3680 W3670	예	예
Intel® Xeon® Processor 3500 Series	W3580 W3570 W3565 W3550 W3540 W3530 W3520 W3505 W3503	예	예
Intel® Xeon® Processor 3400 Series	X3480 X3470 X3460 X3450 X3440 X3430 L3426 L3406	예	예
Intel® Xeon® Processor 3300 Series	X3363 X3353	예	예
Intel® Xeon® Processor 3300 Series	X3380 X3370 X3360 X3350 X3330 X3323 X3320 L3360	예	아니요
Intel® Xeon® Processor 3200 Series	X3230 X3220 X3210	예	아니요
Intel® Xeon® Processor 3100 Series	E3113	예	예
Intel® Xeon® Processor 3100 Series	L3110 E3120 E3110	예	아니요
Intel® Xeon® Processor 3000 Series	3070 3065 3060 3050 3040	예	아니요
Intel® Xeon® Processor 3000 Series	L3014	아니요	아니요
Intel® Itanium® Processor		예	제품에 따라 다름
Intel® Itanium® Processor 9500 Series	9560 9550 9540 9520	예	예
Intel® Itanium® Processor 9300 Series	9350 9340 9330 9320 9310	예	아니요
Intel® Itanium® Processor 9100 Series	9152M 9150N 9150M 9140N 9140M 9130M 9120N 9110N	예	아니요
Intel® Itanium® Processor 9000 Series	9050 9040 9030 9020 9015 9010	예	아니요
Intel® Atom™ Processor		제품에 따라 다름	제품에 따라 다름
Intel® Atom™ Processor D2700 Series	D2700	아니요	아니요
Intel® Atom™ Processor D2500 Series	D2560 D2550 D2500	아니요	아니요
Intel® Atom™ Processor D500 Series	D525 D510	아니요	아니요
Intel® Atom™ Processor D400 Series	D425 D410	아니요	아니요
Intel® Atom™ Processor E3800 Series	E3805 E3815 E3825 E3826 E3827 E3845	예	예
Intel® Atom™ Processor E600 Series	E680T E680 E665CT E665C E660T E660 E645CT E645C E640T E640 E620T E620	예	아니요
Intel® Atom™ Processor N2800 Series	N2800	아니요	아니요
Intel® Atom™ Processor N2600 Series	N2600	아니요	아니요
Intel® Atom™ Processor N500 Series	N570 N550	아니요	아니요
Intel® Atom™ Processor N400 Series	N475 N470 N455 N450	아니요	아니요
Intel® Atom™ Processor N200 Series	N280 N270	아니요	아니요
Intel® Atom™ Processor Z600 Series	Z670 Z650 Z625 Z615 Z600	아니요	아니요
Intel® Atom™ Processor Z500 Series	Z560 Z550 Z540 Z530P Z530 Z520PT Z520	예	아니요
Intel® Atom™ Processor Z500 Series	Z515 Z510PT Z510P Z510 Z500	아니요	아니요
Intel® Atom™ Processor 300 Series	330	아니요	아니요
Intel® Atom™ Processor 200 Series	230	아니요	아니요
Intel® Atom™ Processor for Smartphone and Tablet		제품에 따라 다름	아니요
Intel® Atom™ Processor Z3700 Series	Z3795 Z3785 Z3775D Z3775 Z3770D Z3770 Z3745D Z3745 Z3740D Z3740 Z3736G Z3736F Z3735G Z3735F Z3735E Z3735D	예	아니요
Intel® Atom™ Processor Z3500 Series	Z3580 Z3570 Z3560 Z3530 Z3590	예	아니요
Intel® Atom™ Processor Z3400 Series	Z3480 Z3460	예	아니요
Intel® Atom™ Processor Z2700 Series	Z2760	아니요	아니요
Intel® Atom™ Processor Z2500 Series	Z2580 Z2560 Z2520	예	아니요
Intel® Atom™ Processor for Communications		예	예
Intel® Atom™ Processor for Server		예	제품에 따라 다름
Intel® Atom™ Processor C2000 Product Family for Server	C2750 C2730 C2550 C2530 C2350	예	예
Intel® Atom™ Processor S1200 Product Family for Server	S1260 S1240 S1220	예	아니요
Intel® Atom™ Processor for Storage		예	아니요
Intel® Quark™ SoC		예	아니요
Intel® Pentium® Processor		제품에 따라 다름	제품에 따라 다름
Intel® Pentium® Processor N3000 Series for Mobile	N3700	예	예
Intel® Pentium® Processor N3000 Series for Mobile	N3540 N3530 N3520 N3510	예	아니요
Intel® Pentium® Processor G3000 Series for Desktop	G3470 G3460T G3460 G3450T G3450 G3440T G3440 G3430 G3420T G3420 G3320TE G3260T G3260 G3258 G3250T G3250 G3240T G3240 G3220T G3220	예	예
Intel® Pentium® Processor J2000 Series for Desktop	J2900 J2850	예	아니요
Intel® Pentium® Processor G2000 Series for Desktop	G2140 G2130 G2120T G2120 G2100T G2030T G2030 G2020T G2020 G2010	예	예
Intel® Pentium® Processor 3000 Series for Mobile	3550M 3556U 3558U 3560M 3560Y 3561Y 3805U 3825U	예	예
Intel® Pentium® Processor 2000 Series for Mobile	2129Y 2127U 2117U 2030M 2020M	예	예
Intel® Pentium® Processor 1400 Series for Server	1407 1405V2 1405 1403V2 1403	예	예
Intel® Pentium® Processor A1000 Series for Mobile	A1018	예	예
Intel® Pentium® Processor B900 Series for Mobile	B915C	예	예
	B925C	예	아니요
	B980 B970 B960 B950 B940	아니요	아니요
Intel® Pentium® Processor 900 Series for Mobile	977 967 957 987 997	아니요	아니요
Intel® Pentium® Processor G800 Series for Desktop	G870 G860T G860 G850 G840	예	예
Intel® Pentium® Processor G600 Series for Desktop	G645T G645 G640T G640 G632 G630T G630 G622 G620T G620	예	예
Intel® Pentium® Processor 300 Series for Desktop	350	예	아니요
Intel® Pentium® Processor 4000 Series for Mobile	4405U 4405Y	예	예
Intel® Pentium® Processor G4400 Series For Desktop	G4400T G4400TE G4400	예	예
Intel® Pentium® Processor G4500 Series For Desktop	G4500 G4500T G4520	예	예
Legacy Intel® Pentium® Processor		제품에 따라 다름	제품에 따라 다름
Intel® Pentium® 4 Processor 500 Series	505 505J 506 511 511 515 516 519 519K	아니요	아니요
Intel® Pentium® 4 Processor 500 Series supporting Hyper-Threading Technology	517 520 520J 520J 521 524 530 530J 531 540 540J 541 550 550J 550 551 560 560J 561 570 571	아니요	아니요
Intel® Pentium® 4 Processor 600 Series	620	아니요	아니요
Intel® Pentium® 4 Processor 600 Series supporting Hyper-Threading Technology	662 672	예	아니요
	630 631 640 641 650 651 660 661 670	아니요	아니요
Intel® Pentium® 4 Processors with 533 MHz FSB	520	아니요	아니요
Intel® Pentium® D Processor 800 Series	805 820 830 840	아니요	아니요
Intel® Pentium® D Processor 900 Series	920 930 940 950 960	예	아니요
Intel® Pentium® D Processor 900 Series	915 925 935 945 920	아니요	아니요
Intel® Pentium® M Processor 700 Series	705 715 725 730 735 740 745 745A 750 755 760 765 770 780 718 738 758 778 713 723 733 753 773	아니요	아니요
Intel® Pentium® Processor E2000 Series for Desktop	E2140 E2160 E2180 E2200 E2210 E2220	아니요	아니요
Intel® Pentium® Processor E5000 Series for Desktop	E5500 E5700 E5800	예	아니요
	E5200	아니요	아니요
	E5300 E5400	SPEC 세부 사항 참조
Intel® Pentium® Processor E6000 Series for Desktop	E6300 E6500 E6500K E6600 E6700 E6800	예	아니요
Intel® Pentium® Processor Extreme Edition 800 Series for Desktop	840	아니요	아니요
Intel® Pentium® Processor Extreme Edition 900 Series for Desktop	955 965	예	아니요
Intel® Pentium® Processor G6000 Series for Desktop	G6951 G6950 G6960	예	예
Intel® Pentium® Processor P6000 Series for Mobile	P6000 P6100 P6200 P6300	아니요	아니요
Intel® Pentium® Processor SU2000 Series for Mobile	SU2700	아니요	아니요
Intel® Pentium® Processor SU4000 Series for Mobile	SU4100	아니요	아니요
Intel® Pentium® Processor T2000 Series for Mobile	T2060 T2080 T2130	예	아니요
Intel® Pentium® Processor T2000 Series for Mobile	T2310 T2330 T2370 T2390	아니요	아니요
Intel® Pentium® Processor T3000 Series for Mobile	T3200 T3400	아니요	아니요
Intel® Pentium® Processor T4000 Series for Mobile	T4200 T4300 T4500 T4400	아니요	아니요
Intel® Pentium® Processor U5000 Series for Mobile	U5400 U5600	아니요	아니요
Mobile Intel® Pentium® 4 Processor 500 Series supporting Hyper-Threading Technology	518 532 538 548 552	아니요	아니요
Intel® Celeron® Processor		제품에 따라 다름	제품에 따라 다름
Intel® Celeron® Processor N3000 Series for Mobile	N3000 N3050 N3150	예	예
Intel® Celeron® Processor 3000 Series for Mobile	3765U 3755U 3215U 3205U	예	예
Intel® Celeron® Processor N2000 Series for Mobile	N2940 N2930 N2920 N2910 N2840 N2830 N2820 N2815 N2810 N2808 N2807 N2806 N2805	예	아니요
Intel® Celeron® Processor 2000 Series for Mobile	2981U 2980U 2970M 2961Y 2957U 2955U 2950M 2002E 2000E	예	예
Intel® Celeron® Processor J1000 Series for Desktop	J1900 J1850 J1800 J1750	예	아니요
Intel® Celeron® Processor E1000 Series for Desktop	E1600 E1500 E1400 E1200	아니요	아니요
Intel® Celeron® Processor G1000 Series for Desktop	G1850 G1840T G1840 G1830 G1820TE G1820T G1820 G1630 G1620T G1620 G1610T G1610 G1101	예	예
Intel® Celeron® Processor 1000 Series for Mobile	1037U 1020M 1020E 1019Y 1017U 1007U 1005M 1000M	예	예
Intel® Celeron® Processor 1000 Series for Mobile	1047UE	예	아니요
Intel® Celeron® Processor 900 Series for Mobile	927UE	예	아니요
Intel® Celeron® Processor 900 Series for Mobile	925 900	아니요	아니요
Intel® Celeron® Processor B800 Series for Mobile	B840 B830 B820 B815 B810E B810 B800	예	아니요
Intel® Celeron® Processor 800 Series for Mobile	857 847	예	예
Intel® Celeron® Processor 800 Series for Mobile	887 877 867 847E 827E 807UE 807	예	아니요
Intel® Celeron® Processor B700 Series for Mobile	B720 B710	예	아니요
Intel® Celeron® Processor 700 Series for Mobile	787 725C	예	예
Intel® Celeron® Processor 700 Series for Mobile	797	예	아니요
Intel® Celeron® Processor G500 Series for Desktop	G555 G550T G550 G540T G540 G530T G530	예	예
Intel® Celeron® Processor G400 Series for Desktop	G470 G465 G460 G440	예	예
Legacy Intel® Celeron® Processor		제품에 따라 다름	제품에 따라 다름
Intel® Celeron® D Processor 300 Series	310 315 315J 320 325 326 325J 326 330 330 330J 331 335 335 335J 336 340 340J 341 345 345J 346 347 350 350J 351 352 355 356 360 365	아니요	아니요
Intel® Celeron® M Processor 300 Series	310 320 330 340 350 360 370 380 390 333 353 373 383	아니요	아니요
Intel® Celeron® M Processor 400 Series	410 420 430 440 450 423 443	아니요	아니요
Intel® Celeron® M Processor 500 Series	520 530 523	아니요	아니요
Intel® Celeron® M Processor ULV 700 Series	722 723 743	아니요	아니요
Intel® Celeron® Processor 200 Series for Desktop	220	아니요	아니요
Intel® Celeron® Processor 400 Series for Desktop	445	예	아니요
Intel® Celeron® Processor 400 Series for Desktop	420 430 440 450	아니요	아니요
Intel® Celeron® Processor 500 Series for Mobile	585 575 570 560 550 540 530 573	아니요	아니요
Intel® Celeron® Processor E3000 Series for Desktop	E3200 E3300 E3400 E3500	예	아니요
Intel® Celeron® Processor P1000 Series for Server	P1053	예	아니요
Intel® Celeron® Processor P4000 Series for Mobile	P4500 P4505 P4600	예	예
Intel® Celeron® Processor SU2000 Series for Mobile	SU2300	예	아니요
Intel® Celeron® Processor T1000 Series for Mobile	T1600 T1700	아니요	아니요
Intel® Celeron® Processor T3000 Series for Mobile	T3100 T3000 T3300	아니요	아니요
Intel® Celeron® Processor U3000 Series for Mobile	U3400 U3405 U3600	예	아니요
Intel® Celeron® Processor ULV 700 Series	763	아니요	아니요
Legacy Intel® Core™2 Processor		제품에 따라 다름	아니요
Intel® Core™2 Duo Processor E4000 Series	E4300 E4400 E4500 E4600 E4700	아니요	아니요
Intel® Core™2 Duo Processor E6000 Series	E6300 E6305 E6320 E6400 E6405 E6420 E6540 E6550 E6600 E6700 E6750 E6850	예	아니요
Intel® Core™2 Duo Processor E7000 Series	E7600	예	아니요
	E7200 E7300	아니요	아니요
	E7400 E7500	SPEC 세부 사항 참조
Intel® Core™2 Duo Processor E8000 Series	E8600 E8500 E8400 E8300 E8200	예	아니요
Intel® Core™2 Duo Processor E8000 Series	E8190	아니요	아니요
Intel® Core™2 Duo Processor L7000 Series	L7200 L7300 L7400 L7500 L7700	예	아니요
Intel® Core™2 Duo Processor P7000 Series	P7370 P7570	예	아니요
	P7450 P7350	아니요	아니요
	P7550	SPEC 세부 사항 참조
Intel® Core™2 Duo Processor P8000 Series	P8400 P8600 P8700 P8800	예	아니요
Intel® Core™2 Duo Processor P9000 Series	P9500 P9600 P9700	예	아니요
Intel® Core™2 Duo Processor SL9000 Series	SL9300 SL9380 SL9400 SL9600	예	아니요
Intel® Core™2 Duo Processor SP9000 Series	SP9300 SP9400 SP9600	예	아니요
Intel® Core™2 Duo Processor SU7000 Series	SU7300	예	아니요
Intel® Core™2 Duo Processor SU9000 Series	SU9300 SU9400 SU9600	예	아니요
Intel® Core™2 Duo Processor T5000 Series	T5600	예	아니요
Intel® Core™2 Duo Processor T5000 Series	T5870 T5800 T5750 T5670 T5550 T5500 T5470 T5450 T5300 T5270 T5250 T5200	아니요	아니요
Intel® Core™2 Duo Processor T6000 Series	T6570 T6670	예	아니요
Intel® Core™2 Duo Processor T6000 Series	T6400 T6500 T6600	아니요	아니요
Intel® Core™2 Duo Processor T7000 Series	T7800 T7700 T7600 T7500 T7400 T7300 T7250 T7200 T7100	예	아니요
Intel® Core™2 Duo Processor T8000 Series	T8300 T8100	예	아니요
Intel® Core™2 Duo Processor T9000 Series	T9800 T9600 T9550 T9500 T9400 T9300 T9900	예	아니요
Intel® Core™2 Duo Processor U7000 Series	U7500 U7500 U7600 U7600 U7700	예	아니요
Intel® Core™2 Extreme Processor QX6000 Series	QX6700 QX6800 QX6850	예	아니요
Intel® Core™2 Extreme Processor QX9000 Series for Desktop	QX9650 QX9770 QX9775	예	아니요
Intel® Core™2 Extreme Processor QX9000 Series for Mobile	QX9300	예	아니요
Intel® Core™2 Extreme Processor X6000 Series	X6800	예	아니요
Intel® Core™2 Extreme Processor X7000 Series	X7800 X7900	예	아니요
Intel® Core™2 Extreme Processor X9000 Series	X9000 X9100	예	아니요
Intel® Core™2 Quad Processor Q6000 Series	Q6600 Q6700	예	아니요
Intel® Core™2 Quad Processor Q8000 Series	Q8400 Q8400S	예	아니요
	Q8200 Q8200S	아니요	아니요
	Q8300	SPEC 세부 사항 참조
Intel® Core™2 Quad Processor Q9000 Series for Desktop	Q9300 Q9400 Q9400S Q9450 Q9500 Q9505 Q9505S Q9550 Q9550S Q9650	예	아니요
Intel® Core™2 Quad Processor Q9000 Series for Mobile	Q9000 Q9100	예	아니요
Intel® Core™2 Solo Processor SL3000 Series	SL3400	예	아니요
Intel® Core™2 Solo Processor SU3000 Series	SU3300 SU3500 SU3500	예	아니요
Intel® Core™2 Solo Processor U2000 Series	U2100 U2200	예	아니요
Legacy Intel® Core™ Processor		제품에 따라 다름	아니요
Intel® Core™ Duo Processor L2000 Series	L2300 L2400 L2500	예	아니요
Intel® Core™ Duo Processor T2000 Series	T2300 T2400 T2500 T2600 T2700	예	아니요
Intel® Core™ Duo Processor T2000 Series	T2050 T2250 T2300E T2350 T2450	아니요	아니요
Intel® Core™ Duo Processor U2000 Series	U2400 U2500	예	아니요
Intel® Core™ Solo Processor T1000 Series	T1300 T1350 T1400 T1250	아니요	아니요
Intel® Core™ Solo Processor U1000 Series	U1300 U1400 U1500	예	아니요
6th Generation Intel® Core™ i3 Processors		예	예
6th Generation Intel® Core™ i5 Processors		예	예
6th Generation Intel® Core™ i7 Processors		예	예
Server Accessories		예	아니요

제공된 모든 정보는 언제든 예고 없이 변경될 수 있습니다. 인텔은 언제든지 예고 없이 제조 라이프 사이클 및 사양과 제품 설명을 변경할 수 있습니다. 이곳의 정보는 "있는 그대로" 제공되며 인텔에서는 정보의 정확성과 제품 기능, 가용성, 작동 여부 또는 나열된 제품의 호환성 등에 관한 어떠한 표현이나 보증도 하지 않습니다. 특정 제품이나 시스템에 대한 자세한 정보는 시스템 공급업체에 문의하십시오.

인텔® 가상화 기술을 사용하려면 이 기술을 지원하는 프로세서, 칩셋, BIOS, 가상 기계 모니터(VMM)가 탑재된 컴퓨터가 필요하며, 일부 특정 용도로 사용하는 경우, 해당 용도를 지원하는 특정 플랫폼 소프트웨어가 필요합니다. 기능, 성능 또는 기타 장점은 하드웨어 및 소프트웨어 구성에 따라 달라집니다. 인텔 가상화 기술을 지원하는 VMM 애플리케이션은 현재 개발 단계에 있습니다.

인텔 프로세서 번호는 성능의 측정 기준이 아닙니다. 프로세서 번호는 각 프로세서 제품군 내에서의 기능을 구별하기 위한 것이지 프로세서 제품군 자체를 구별하기 위한 것이 아닙니다. 자세한 사항은 http://www.intel.com/content/www/kr/ko/processors/processor-numbers.html을 참조하십시오.

출처 : http://ark.intel.com/ko/Products/VirtualizationTechnology

[가상화] VT-D의 호환성 Motherboards

JAESOO — Wed, 07 Oct 2015 19:31:31 +0000

VT-d or AMD-V compatible motherboards

Intel desktop motherboards supporting VT-d

http://www.intel.com/support/motherboards/desktop/sb/CS-030922.htm*

* Scroll down to "The following Intel® Desktop Boards support Intel VT with Directed I/O:"

Here a summary of the VT-d compatible Intel desktop motherboards as of August 21, 2013 (see link above for updated information):

H87, Q87, Z87 chipsets: DH87MC, DH87RL, DQ87PG, DZ87KLT-75K

B85 chipset: DB85FL

X79 chipset: DX79SI, DX79SR, DX79TO

H77, Q77, Z77 chipsets: DH77DF, DH77EB, DH77KC, DQ77CP, DQ77KB (see here), DQ77MK, DZ77BH-55K, DZ77GA-70K (see here), DZ77RE-75K, DZ77SL-50K

B75, Z75 chipsets: DB75EN, DZ75ML-45K

Q67 chipset: DQ67EP, DQ67OW, DQ67SW

H61 chipset: DH61AGL

Q57 chipset: DQ57TM, DQ57TML

Q45 chipset: DQ45CB, DQ45EK

Q35 chipset: DQ35JO, DQ35MP

Asrock motherboards supporting VT-d

Asrock B85M (see here)

Asrock Z77-Pro4-M (see here)

Asrock Fatal1ty X79 Professional (see here)

Asrock 226WS (see here)

Asrock Z87 boards - see thread

ASRock Z87 Extreme6/ac (see here)

Asrock Z77 Extreme6 with BIOS 2.40 (see here)

Asrock Z77 Extreme4 (see here)

Asrock Z77 Extreme4-M (see here and here)

Asrock H61M-VS R2.0 (see here)

Asrock Z77E-ITX with BIOS 1.40 (see here and here)

Remarks:
Some Asrock motherboard BIOS releases are NOT supporting VT-d. Please check the vendor site under BIOS updates, and if in doubt, contact the vendor.

Examples:
ASRock Z77E-ITX - BIOS 1.60 breaks VT-d, but BIOS 1.70 again supports VT-d.
ASRock Z77 Extreme6 - BIOS P2.30 breaks VT-d, but there is a report that BIOS P2.40 enables it. Best to verify with vendor.

Asrock motherboards supporting AMD-V

Asrock A55MD2 (see here)

Asrock FM2A85X-Mini ITX (see here)

Asrock 970 Extreme3 R2.0 with Bios Ver 1.3 and FX-8350 CPU (see here)

Asrock Extreme3 990fx (see here)

See next post!

ASUS motherboards supporting VT-d

ASUS Z87I-Pro (see here)

ASUS Sabertooth X79 (for SB-E CPUs only!!! - see here; IVB-E CPUs are currently not supported)

ASUS Rampage IV Extreme (for SB-E CPUs; for IVB-E CPUs, use BIOS release 4802 or newer, or beta BIOS here)

ASUS Rampage IV Formula (for SB-E CPUs only!!! - see here)

ASUS Rampage IV Gene (for SB-E CPUs only!!! - see here)

ASUS P9X79-E WS (for IVB-E use BIOS 1406 - see here)

ASUS motherboards supporting AMD-V

ASUS M5A99FX PRO R2.0 with BIOS v2005 !!! (see here)

ASUS Sabertooth 990FX R2.0 with BIOS v2005 !!! (see here)

ASUS Z8NA-D6 (see here)

Gigabyte motherboards supporting VT-d

Gigabyte Z77MX-D3H (see here)

Gigabyte Z68MA-D2H-B3 (see here)

Gigabyte H77N-WIFI (see here)

Gigabyte motherboards supporting AMD-V

Gigabyte 990FX UD7 rev3 (see here)

Gigabyte 990FX UD5 rev1 (see here)

MSI motherboards supporting VT-d

MSI Z77A-G43 (see here)

MSI Z87-G45 Gaming (see here)

Supermicro motherboards supporting VT-d

Supermicro X10SAT with Xeon CPU (see here)

Edited by powerhouse - 2/3/15 at 5:37am

출처 : http://shintime.com/?mid=Favorite_Format&l=jp&document_srl=17558&order_type=desc&m=1

출처 : http://www.overclock.net/t/1338063/vt-d-compatible-motherboards

인텔의 AES-NI, TXT, VT-D (AES 명령어 세트, 신뢰 실행 기술, 가상화기술)

JAESOO — Wed, 07 Oct 2015 19:29:07 +0000

CPU의 스펙을 비교하다보면...
한번쯤은 마추치게 되는 용어들이
인텔의 AES-NI, TXT, VT-D 입니다.

이전에 Core i5 450M 프로세서에 대한 내용을
다룰때 잠깐 언급한적있는데...
Core i5 모바일 프로세서 중 400번대 제품과
500번대 제품이 나눠지는 기준이
저 기술의 유무에 따라서 나눠지게 됩니다.

링크 ☞ Core i5 430m, Core i5 450m 과 Core i5 520m 의 비교 : Arrandale CPU

마침 댓글로 질문을 남겨주신분도 계시고 해서 정리하는 의미에서 작성하겠습니다.
매번 남기는 내용이지만...
저의 지식의 깊이는 상당히 얕기 때문에 "아 그런가?" 이정도로만 받아들여주시길 바랍니다.
저는 전문가가 아니고 그냥 IT쪽에 관심이 많은 일반인 입니다. 따라서 심도 깊은 질문은 서로를
난처하게 할수 있기 때문에... 처리과정이라든지의 상세한 내용은 전문가에게 질문을 남겨주시기
바랍니다. ^^

위에서 언급했던 AES-NI, TXT, VT-D 기술은 들은 전부 축약어로...
원래의 기술이름은 아래와 같습니다.

AES-NI : Advanced Encryption Standard - New Instructions
TXT : Trusted Execution Technology
VT-D : Virtualization Technology for Directed I/O
이들 기술은 가상화와 함께 클라우드 컴퓨팅과 밀접한 연관을 가지고 있는 기술들입니다.

AES-NI 는 AES 의 New Instruction 으로 AES의 새로운 명령어 세트로 해석할 수 있습니다.
AES 는 Adcanced Encryption Standard 로 DES(Data Encryption Standard)를 대신할
미국의 표준 알고리즘입니다.
AES - NI 는 인텔의 "새로운 암호화 명령어세트"정도로 해석이 가능합니다. ^^
즉 데이터를 암호화 시키고 또 그 암호화된 데이터를 푸는데 걸리는 시간을 단축 시키는 기능입니다.

대표적인 예로 압축 프로그램인 7Zip을 사용할 경우 AES-NI가 탑재된 CPU로 작업하게 되면
보다 시간을 단축시킬수 있고, 무선랜 (Wi-Fi) 에서 역시 보안에 대한 신뢰성과 효율성을 높일 수
있게 됩니다.
저 개인의 생각으로는 일반인 보다는 업무 중심의 노트북이나 보안이 필요로하는 직업군에서
노트북을 사용을 위해 구입하신다면 한번 더 고려해야 될 기술이 아닐까합니다.

참고자료

AES_fips-197.pdf

AES-NI.pdf

AES-NI와 클라우드 컴퓨팅에 관련된 동영상입니다.

TXT는 Trusted Execution Technology 로 굳이 번역하자면 "신뢰 실행 기술" 입니다.
보다 안전한 컴퓨팅을 위한 기술로 보안이 요구되는 중요한 자료들을 빼내가고자 하는
각종 소프트 웨어의 공격으로 부터 시스템을 방어하는 것입니다.
보안이라는 소프트웨어적 개념을 하드웨어화 시킨 것입니다.

가상화 기술(Virtualization Technology) 및 TXT를 지원하는 하드웨어들이 플랫폼상의 소프트웨어 구동할때나 데이터 저장할때 암호를 생성 하고, 보안모듈을 확인하는등의 과정과
함께 관련 소프트웨어의 조합이 필요합니다.

이 조합을 통해서
인텔 TXT가 적용된 시스템은 무단변경된
소프트웨어의 실행을 방지하고,
특정 소프트웨어를 실행 시키는 경우 그에
해당된 메모리 실행 영역에 다른 소프트웨어가 접근하는 것을 하드웨어적으로 차단하는
방법으로 각종 소프트웨어의 공격으로 부터 효과적인 방어를 하게 됩니다.
대표적인 예로 키보드의 입력 정보나 모니터에 뜨는 화면을 외부로 가로채가는 등의 악성코드
또는 유해 프로그램에 대한 침투를 막을 수 있습니다.

TXT (Trusted Execution Technology) 기술의 영상입니다.

VT-D는
Virtualization Technology for Directed I/O 로
칩셋에서 제공하는 가상화 기술을 말하는데 보다 추가적인 설명에 앞서서먼저 가상화에 대해서 언급해야 될듯한데...

가상화(Virtualization)는 하나의 물리적인 리소스를 다중의 논리적 인 리소스를 만들어 내거나 반대로 여러개의 물리적 리소스를 하나의 논리적인 리소스처럼 보이게하는 것을 의미합니다.

예를 들자면...
대부분의 컴퓨터 부품들은 한번에 하나의 OS 로 부터 제어를 받도록 되어있습니다.
따라서 윈도우 내에서 윈도우가 한번 더 실행되지 않는겁니다.
가상화란 이런 문제를 해결해서 OS 상에서 다른 OS 를 사용 할 수 있도록 해주는 기술입니다.
일반적으로 보면 윈도우 7에서 애플의 운영체제인 레오파드를 설치한다거나... 아니면 리눅스 또는
윈도우 XP를 실행하는것을 말합니다.

이전에도 VMware 등을 통해서 가상화 구현이 가능했지만... 소프트웨어로 제공되는 가상화 기술은 한계를 가지기 때문에 이것을 하드웨어 기술로 구현한것이 인텔의 가상화 기술(Virtualization Technology) 입니다.

인텔의 가상화 기술을 VT-X, VT-D, VT-C 이렇게 3가지로 구분지을 수 있습니다.

VT-X - CPU
가상머신(VM: Virtual Machine)으로 인해 만들어진 많은 운영체제들은
가상머신모니터(VMM : Virtual Machine Monitor or Hypervisor) 과 통신하면서
실제 하드웨어 사용에 대한 주도권을 다투게 됩니다.
많은 OS가운데 누가 먼저 실제 CPU 리소스를 사용할 것인가에 대해 경쟁하는 과정에서
병목현상이 발생할수 있는데... VM들에 우선순위를 붙여 병목현상을 막는 역활을 합니다.

VT-D - 칩셋
가상화를 I/O(Input-Output)까지 넓힌 것으로, VM(가상머신)으로부터 직접 I/O에 접속할 수 있게
되고, 이것은 물리적인 서버에 접속하고 있는 I/O와 같은 성능을 제공할 수 있게 됩니다.
즉, 가상 OS가 각종 디바이스에 직접 접근 할 수 있으므로
하드웨어적으로 안정된 가상화를 이루게 됩니다.

VT-C - 네트워크 카드
가상머신이 네트워크 접속을 효율적으로 할 수 있도록, 네트워크 인터페이스 카드를 분류하고
패킷을 바꿔주는 기능을 합니다.

인텔의 가상화 기술(Virtualization Technology)에 대한 영상

위에서 나열한 VT-X, VT-D, VT-C 가상화 기능은 인텔의 서버에서 구현된 기술로
지금은 PC 프로세서까지 내려와 Core i7, Core i5 까지 적용 되어있고
향후 아톰과 임베디드 프로세서 까지 확장될 전망입니다.

                       샌디브릿지 프로세서에 적용된 기술들
링크 ☞  샌디 브릿지 - 터보 부스트2.0 (Sandy Bridge Processor Turbo Boost 2.0)
링크 ☞ 하이퍼스레딩과 멀티스레드 그리고 인텔의 파이프라인(Hyper-Threading & Pipeline)
링크 ☞ 인텔의 AES-NI, TXT, VT-D (AES 명령어 세트, 신뢰 실행 기술, 가상화기술)
링크 ☞ 샌디브릿지 AVX 명령어 세트 (Sandybridge AVX instruction set)

                         샌디브릿지 데스크탑 i 시리즈 프로세서의 구분
링크 ☞ 샌디브릿지 데스크탑 CPU 비교 1부 : 종류와 구분 (Sandy Bridge Processor)
링크 ☞ 샌디브릿지 데스크탑 CPU 비교 2부 : 샌디브릿지 내장 그래픽 HD 2000 & HD 3000
링크 ☞ 샌디브릿지 데스크탑 CPU 비교 3부 : 성능 비교 (SandyBridge Processor BenchMark)

                      Core i3-2105 제품의 스펙과 내용 링크
링크 ☞ Core i3 2105 & Core i5 2405S (새롭게 출시된 인텔 샌디브릿지 데스크탑 프로세서)

           샌디브릿지 데스크탑 펜티엄(Pentium) 시리즈 프로세서의 구분
링크 ☞ 샌디브릿지 펜티엄 프로세서의 비교와 차이 (Pentium G620, G620T, G840, G850)

샌디 브릿지 노트북용 모바일 프로세서의 성능은 아래의 링크를 참고하세요.
링크 ☞ 샌디브릿지 노트북 CPU (1부 : Core i3 & Core i5)
링크 ☞ 샌디브릿지 노트북 CPU (2부 : Core i7)
링크 ☞ 샌디브릿지 노트북 CPU (3부 : 내장 그래픽코어 HD Graphics 3000)

위에서 나열한 기술들의 최종 목표는 클라우드 컴퓨팅입니다.
가상화 기술에 대해서 말할때 잠깐언급했었지만... 하나의 물리적 자원을 쪼개서 사용할수도 있고... 여러개의 물리적 자원을 하나처럼 운용할수 있다는것은 운용 관리에 드는 비용과 노력을 줄이고 보다 효율적인 사용이 가능하게 됩니다.
즉 클라우드 환경을 구축하는데 필요한 요소라고 할수 있을 것입니다.

출처 : http://smsinfo.tistory.com/494

가상화 지원 CPU 확인 프로그램 : SecurAble

JAESOO — Wed, 07 Oct 2015 19:15:10 +0000

Windows 7 가상화 지원 CPU 확인 프로그램 : SecurAble

https://www.grc.com/securable.htm

1. 프로그램 다운은 를 눌러서 파일을 다운로드 합니다.

2. 받은 파일을 실행하면 상단의 이미지와 같은 창이 뜹니다.

3. 프로그램 창의 내용은

Maximum Bit Length : 최대 가능 Bit 수

Hardware D.E.P : 하드웨어 실행 방지

Hardware Virtualization : 하드웨어 가상화 여부

4. 결과 보는 방법

모든 값이 상단의 이미지와 같이 YES로 표시되어야 사용을 할 수 있습니다.

처음 숫자가 32인 경우에는 32Bit용 Windows7을 설치만 가능합니다.

처음 숫자가 64인 경우에는 32Bit, 64Bit 중 선택을 하여 설치가 가능합니다.

마지막 Hardware Virtualization부분에 Locked ON인 경우에는 CPU에서는 지원을 하지만 현재 사용중인 메인보드 칩셋 등에서 억지로

가상화 기능을 막아놓은 경우에 나타납니다.

이런 경우에는 CMOS에서 환경 설정을 해주시면 됩니다.

Locked ON인 경우에는 CPU에서는 지원을 하지만 현재 사용중인 메인보드 칩셋 등에서 해당 기능이 없이 출시되어진 제품으로

메인보드 제조사의 홈페이지에서 최신 BIOS를 업데이트를 받아서 사용을 하셔야 하지만 잘못된 업데이트를 하게 되면 A/S를 받을 수 있으니

주의하시기 바랍니다.

출처 : http://supuri.tistory.com/245

Desktop Boards - Compatibility with Intel® Virtualization Technology (Intel® VT) (가상화 지원 칩셋)

JAESOO — Wed, 07 Oct 2015 19:14:15 +0000

Desktop Boards

Compatibility with Intel® Virtualization Technology (Intel® VT)

Intel® Virtualization Technology (Intel® VT) consists of technology components that support virtualization of platforms based on Intel® Processors, thereby enabling the running of multiple operating systems and applications in independent partitions.

There are two types of virtualization:

Intel® Virtualization Technology (Intel® VT)

Improves the fundamental flexibility and robustness of traditional software-based virtualization solutions by accelerating key functions of the virtualized platform, including:

Speeding up the transfer of platform control between the guest operating systems (OSs) and the virtual machine manager (VMM)/hypervisor
Enabling the VMM to uniquely assign I/O devices to guest OSs
Optimizing the network for virtualization with adapter-based acceleration

Intel® Virtualization Technology (Intel® VT) for Directed I/O (Intel® VT-d)

Provides additional performance, security and flexibility by providing the VMM with the following capabilities:

I/O device assignment
DMA remapping
Interrupt remapping
Reliability

Intel® Desktop Boards require the following components to support Intel® VT or Intel® VT-d:

Intel® Processor that supports Intel VT.
BIOS with Intel VT or VT-d support (found on the Security menu in BIOS setup).
A third party VMM (virtual machine manager) may also be required.

To see if your processor supports Intel VT, refer to Does my processor support Intel® Virtualization Technology?

The following Intel® Desktop Boards support Intel VT:

Chipset	Desktop Board
H87, Q87, Z87	DH87MC, DH87RL, DQ87PG, DZ87KLT-75K
B85	DB85FL
X79	DX79SI, DX79SR, DX79TO
H77, Q77, Z77	DH77DF, DH77EB, DH77KC, DQ77CP, DQ77KB, DQ77MK, DZ77BH-55K, DZ77GA-70K, DZ77RE-75K, DZ77SL-50K
B75, Z75	DB75EN, DZ75ML-45K
Z68	DZ68ZV, DZ68DB, DZ68BC, DZ68AF, DZ68PL
Q67, P67, H67	DQ67EP, DQ67OW, DQ67SW, DP67DE, DP67BG, DP67BA, DH67VR, DH67GD, DH67CL, DH67CF, DH67BL
B65	DB65AL
H61	DH61AG, DH61AGL, DH61BE, DH61CR, DH61DL, DH61SA, DH61WW, DH61ZE
X58	DX58SO2, DX58SO, DX58OG
Q57	DQ57TM, DQ57TML
H55, P55	DH55HC, DH55PJ, DH55TC, DP55KG, DP55SB, DP55WB, DP55WG
X48	DX48BT2
G45, P45, Q45	DG45FC, DG45ID, DP45SG, DQ45CB, DQ45EK
B43, G43, P43, Q43	DB43LD, DG43GT, DG43NB, DG43RK, DP43BF, DP43BFL, DP43TF, DQ43AP
G41	DG41AN, DG41BI, DG41CN, DG41KR, DG41MJ, DG41RQ, DG41TX, DG41TY, DG41WV
X38	DX38BT
P35, Q35	DP35DP, DQ35JO, DQ35MP
G33	DG33BU, DG33FB
G31	DG31GL, DG31PR

The following Intel® Desktop Boards support Intel VT with Directed I/O:

Chipset	Desktop Board
H87, Q87, Z87	DH87MC, DH87RL, DQ87PG
B85	DB85FL
X79	DX79SI, DX79SR, DX79TO
H77, Q77, Z77	DH77DF, DH77EB, DH77KC, DQ77CP, DQ77KB, DQ77MK, DZ77BH-55K, DZ77GA-70K, DZ77RE-75K, DZ77SL-50K
B75, Z75	DB75EN, DZ75ML-45K
Q67	DQ67EP, DQ67OW, DQ67SW
H61	DH61AGL
Q57	DQ57TM, DQ57TML
Q45	DQ45CB, DQ45EK
Q35	DQ35JO, DQ35MP

Related topic

Intel® Virtualization Technology

This applies to:

Solution ID: CS-030922
Last Modified: 03-Aug-2015
Date Created: 04-Oct-2009

출처 : http://www.intel.com/support/motherboards/desktop/sb/CS-030922.htm

Vmware Converter 포트 확인 (Required VMware vCenter Converter ports)

JAESOO — Fri, 04 Sep 2015 09:44:26 +0000

Required VMware vCenter Converter ports (1010056)

Symptoms

You may receive these errors, which can indicate blocked ports:

Unable to contact the specified host
The host is not available, there is a network configuration problem, or the management services on the host are not responding
Failed to connect to peer
Error: Failed to connect to server
The operation failed
Incorrect user credentials
Unable to SSH to the source machine
Please check if a firewall is blocking access to the SSH daemon on the source machine
Failed to clone the volume
Unable to connect
FAILED: The request refers to an unexpected or unknown type
Failed to connect ISO image to remote VM
FAILED: unable to obtain the IP address of the helper virtual machine
ssh: Could not resolve hostname
Name or service not known
FAILED: An error occurred during the conversion
Unable to obtain IP addresss of helper virtual machine
A general system error occurred: unknown internal error

Purpose

This article describes the ports required to be open for VMware vCenter Converter.

Following the article and ensuring the ports are open ensures that common firewall configurations in your environment are compatible with Converter.

Resolution

VMware vCenter Converter fails if one or more required ports are blocked. Follow the section that matches your conversion scenario.

In this article, these terms are used:

Source computer	The physical or virtual machine that is being converted.
Converter server	The server portion of VMware vCenter Converter. In a typical installation, both the Converter server and Converter client are installed at the same location. By default, this is the installation method that is used.
Converter client	The client portion of VMware vCenter Converter. In a custom installation, the Converter client can be installed to a different computer than the Converter server.
VirtualCenter	The VirtualCenter computer that is being used as the conversion destination, if such was chosen.
ESX	The VMware ESX host that is being used as the conversion destination, if one is chosen, or the ESX host that is hosting the target virtual machine.
Fileshare path	The path to a virtual machine's .vmx file, if the source is an existing or standalone virtual machine, or the path to a directory if the destination is to be a standalone virtual machine.
Standalone virtual machine	A virtual machine that is being managed by a VMware product other than VMware ESX.
Helper virtual machine	When converting a powered on Linux operating system (P2V), this is the target virtual machine that is being used temporarily for the purpose of copying files from the source computer. It uses the TCP/IP information that is entered in the Converter wizard for the target virtual machine. Ensure that this IP address can communicate directly with the source computer.

Notes:

If you perform a corrective action, determine if the problems initially encountered are still being experienced.
To test port connectivity, do so from a command or shell prompt. For more information, see Opening a command or shell prompt (1003892).
To test TCP port connectivity use the telnet command. For more information, see Testing port connectivity with Telnet (1003487).
To test UDP port connectivity from Linux or MacOS use the traceroute command. For more information, see a traceroute man page.
To test UDP port connectivity from Windows use the Portqry utility. For more information, see the Microsoft Knowledge Base article 310099.
For powered-on Windows conversions to vCenter destinations, Proxy Mode feature in Converter 6.0 is introduced. By selecting this option, no direct connectivity is required from the source machine to the destination ESX host.

Note: The preceding links were correct as of March 15, 2009. If you find a link is broken, provide feedback and a VMware employee will update the link.

Converting a powered on Windows operating system (P2V)

Source	Destination	TCP Ports	UDP Ports	Notes
Converter server	Source computer	445, 139, 9089 or9090	137, 138	If the source computer uses NetBIOS, port 445 is not required. If NetBIOS is not being used, ports 137, 138, and 139 are not required. If in doubt, ensure that none of the ports are blocked. Port 9089 is used for Converter Standalone versions,and 9090 isused for the Converter plugin. Note: Unless you have installed Converter server to the source computer, the account used for authentication to the source computer must have a password, the source computer must have network file sharing enabled, and it cannot be using Simple File Sharing.
Converter server	VirtualCenter	443, 902		Only required if the conversion target is VirtualCenter.
Converter client	Converter server	443		Only required if a custom installation was performed and the Converter server and client portions are on different computers.
Source computer	ESX/ESXi	443, 902		If the conversion destination is vCenter Server, only port 902 is required from the source to the ESX/ESXi hosts.

Converting a powered on Linux operating system (P2V)

Note: These are the default ports. If custom ports were used when installing vCenter Server, these will need to be changed to match your environment.

Source	Destination	TCP Ports	Notes
Converter server	Source computer	22	The Converter server must be able to establish an SSH connection with the source computer.
Converter client	Converter server	443	Only required if a custom installation was performed and the Converter server and client portions are on different computers.
Converter server	VirtualCenter	443	Only required if the conversion target is VirtualCenter.
Converter server	ESX/ESXi	443, 902, 903	If the conversion destination is vCenter Server, only port 902 is required from the source to the ESX/ESXi hosts.
Converter server	Helper virtual machine	443
Helper virtual machine	Source computer	22	The helper virtual machine must be able to establish an SSH connection with the source computer. By default the helper virtual machine gets its IP address assigned by DHCP. If there is no DHCP server available on the network chosen for the target virtual machine you must manually assign it an IP address.

Converting an existing virtual machine (V2V)

Note: These are the default ports. If custom ports were used when installing vCenter Server, these will need to be changed to match your environment.

Source	Destination	TCP Ports	UDP Ports	Notes
Converter server	Fileshare path	445, 139	137, 138	This is only required for standalone virtual machine sources or destinations. If the computer hosting the source or destination path uses NetBIOS, port 445 is not required. If NetBIOS is not being used, ports 137, 138, and 139 are not required. If in doubt, ensure that none of the ports are blocked.
Converter client	Converter server	443		Only required if a custom installation was performed and the Converter server and client portions are on different computers.
Converter server	VirtualCenter	443		Only required if the target is VirtualCenter.
Converter server	ESX/ESXi	443, 902		If the conversion destination is vCenter Server, only port 902 is required from the source to the ESX/ESXi hosts.

Additional Information

For translated versions of this article, see:

Español: Puertos de VMware vCenter Converter requeridos (2033057)
Português: Portas necessárias do VMware vCenter Converter (2032593)
日本語: 必要な VMware vCenter Converter のポート (2078649)
简体中文: 需要使用的 VMware vCenter Converter 4.x/5.x 端口 (2081918)

This Article Replaces

1008757

Update History

01/03/2014 - Added vCenter Converter Standalone 5.5.x to Products

Request a Product Feature

To request a new product feature or to provide feedback on a VMware product, please visit the Request a Product Feature page.

출처 : http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1010056

형상관리에 들어 보셨나요?

JAESOO — Mon, 31 Aug 2015 10:07:59 +0000

1. 형상관리에 대해

오늘은 소프트웨어 개발에서 기본이 되는 형상관리에 대해서 알려 드리겠습니다. 형상관리(CM : configuration management)라고 들어보셨나요? 소프트웨어 공학을 배우신 분들에게는 익숙하겠지만, 그렇지 않으신 분들에게는 매우 생소한 단어라 생각 됩니다. 이미 배우신 분들은 형상관리가 범위도 다양하고 복잡하다는 걸 알고 있을 텐데, 오늘은 그 중에 개발자들에게 익숙한 소프트웨어 형상관리, 다른 말로 하면 소스 버전 관리에 대해 알아 보도록 하겠습니다.

소프트웨어 형상관리는 Software Configuration Management, 줄여서 SCM라는 단어를 쓰기도 하는데, SW개발 및 유지보수 과정에서 발생하는 소스코드, 문서, 인터페이스 등 각종 결과물에 대해 형상을 만들고, 이들 형상에 대한 변경을 체계적으로 관리, 제어하기 위한 활동입니다. 단순히 말하자면 프로젝트를 진행하면서 생성하는 소스코드를 CVS나 SVN, 또는 GIT와 같은 버전 관리 시스템을 이용하는 것을 말합니다.

다수의 개발자가 프로젝트에서 동일한 기능을 동시에 개발한다고 할 때, 작성된 소스 코드와 변경사항을 확인하고, 수정하는 협업을 도와주는 시스템이라고 할 수 있습니다.

참고로 공급망 관리를 지칭하는 Supply Chain Management(SCM)과 동일한 약어를 사용하니, 누가 SCM에 대해 물어본다면, 어떤 SCM을 말하는 것인지 확인을 하고 대답해 주세요. ^^

그럼 오늘은 소프트웨어 형상관리에서 버전 관리 시스템을 왜 사용해야 하는지, 어떤 개념들이 있는지, 그리고 어떠한 시스템들이 있는지 알아보도록 하겠습니다.

2. 왜 버전 관리 시스템이 필요한가?

프로그램을 만들다 보면, 잘못 만들어서 다시 소스코드를 이전 상태로 되돌릴 필요도 있고, 변경된 이력을 확인할 필요가 있습니다. 그리고 여러 명의 개발자들이 동시에 같은 소스코드를 개발하면서 발생하는 충돌에 대한 처리도 필요합니다. 이러한 것을 하기 위해 무엇이 필요할까요? 바로 버전 관리 시스템입니다.

과거와 달리 현재의 소프트웨어는 더 복잡해지고, 더 쉽게 변경됩니다. 만약 소프트웨어 버전관리 시스템을 사용하지 않는다면, 다른 개발자가 무엇을 했는지 알 길이 없으며, 실수를 쉽게 되돌릴 수도 없습니다.

버전 관리 시스템이 없던 과거에는, 다음과 같이 누구 책임인지 싸우느라 시간을 허비 했을지도 모릅니다.

버전 관리가 필요한 이유를 정리하면 다음과 같습니다.

개발 하는 동안 소스 코드의 변경 사항을 보존하기 위해

- 버그 및 문제점이 발생했을 때 추적에 유용
- 과거 특정 시점의 소스 파일 및 디렉토리의 내용을 손쉽게 확인 가능
- 과거 특정 시점의 소스 파일로 손쉽게 되돌릴 수 있음

협동 작업을 가능하게 하기 위해
- 대부분의 프로젝트는 팀 단위이기 때문에 전체 팀원이 하나의 소스를 가지고 효율적으로 작업할 수 있는 도구가 필요함
- 인터넷을 이용한 전세계 개발자들이 협업을 하여 개발하는 오픈 소스 프로젝트에 필수

3. 버전 관리 시스템의 기본 개념

문제 #1: 협업하기

두 명 이상의 사람들이 똑같은 소스코드를 같은 시간에 편집해야 한다면 어떻게 해야 할까요?

대안 1

누가 수정을 할지 순서를 정한다.

한 번에 한 사람만 작업을 할 수 있다.

규칙을 어떻게 지킬 수 있도록 할 수 있을까?

대안 2

작업을 각자 한 후 차이점을 찾아 수정한다.

차이점을 찾고 수정하기 위해 수많은 재 작업이 필요하다.

재 작업 시 소스코드가 손실 될 수 있다.

해결책

버전 관리 시스템은 개발자들이 동일한 소스 코드를 동시에 수정하거나 수정된 내용을 쉽게 공유할 수 있는 기능을 제공합니다.

중앙 저장소(Repository)에 메인 소스 코드를 저장해 놓습니다.
여러 명의 개발자들은 각자 로컬 PC에 중앙 저장소에 저장되어 있는 소스 코드를 작업 디렉토리(Working Copy)에 사본을 복사해 소스 코드를 수정합니다.
개발자들이 소스 코드 수정을 끝낸 후, 소스 코드를 공유하기 위해서 중앙 저장소로 소스코드를 커밋(Commit) 합니다.
다른 개발자는 변경된 내용을 확인 하기 위해서 중앙 저장소의 소스를 작업 디렉토리로 갱신(Update) 되도록 명령을 수행합니다.

문제 #2: 수정 사항 되돌리기

간혹 수정하던 소스 코드를 다음과 같은 이유로 이전 상태로 돌아갈 필요가 생깁니다.

개발을 시작한 후 시간이 지나, 잘못된 구현을 하고 있다는 것을 알게 되었을 때
이전 상태로 되돌리면서 모든 파일에 대한 변경 이력(History)를 유지하고 싶을 때
소스 코드가 언제, 무엇을, 그리고 누가 수정했는지 알고 싶을 때
->누군가 작성한 소스 코드를 이해하는 가장 좋은 방법은 작성한 사람에게 물어보는 것입니다.

해결책

버전 관리 시스템은 개발자들이 수정한 소스 코드에 대한 리비전(Revision)을 관리합니다. 리비전은 수정 시간, 수정한 사람, 수정한 내용들을 포함하고 있어, 개발자들에게 편리한 정보를 제공하고 있습니다.

또한 되돌리기(Roll back) 기능이 있어 특정 리비전 또는 특정 시간으로 소스코드를 되돌릴 수 있습니다.

위 두 가지 문제를 보면서 버전 관리 시스템의 기본적인 개념을 설명 드렸습니다. 그리고 위에서 나온 용어들을 정리하면 다음과 같습니다.

용어	설명
중앙 저장소(Repository)	원본 소스를 저장하고 있는 저장소를 의미합니다.
작업 디렉토리(Working Copy)	원본 저장소로부터 체크아웃을 통해 내려 받은 내 로컬 PC에 있는 작업 사본 디렉토리를 의미합니다.
커밋(Commit)	작업 디렉토리에서 변경, 추가 및 삭제된 파일을 원본 저장소인 서버에 적용하는 것을 말합니다.
갱신(Update)	체크아웃을 받은 작업 디렉토리를 원본 저장소의 가장 최신 커밋된 버전까지 업데이트하는 명령어입니다.
리비전(Revision)	소스 파일을 수정하여 커밋하게 되면 일정한 규칙에 의해 숫자가 증가합니다. 저장소에 저장된 각각의 파일 버전이라 할 수 있습니다.
되돌리기(Roll Back)	작업 디렉토리에 저장되어 있는 사본을 특정 리비전 또는 특정 시간으로 복원할 수 있도록 하는 명령어입니다.

위 용어들은 다양한 버전 관리 시스템에서 다양한 용어로 대체되어 사용됩니다. 예를 들면 작업 디렉토리(working Copy)는 작업 공간(Workspace)라는 단어로, 커밋(Commit)은 체크인(Check-In)이라는 단어가 사용되기도 하니 버전 관리 시스템을 사용하기 전에 어떤 단어가 위의 기능들과 매핑 되는지 확인해야 합니다.

4. 버전 관리 시스템의 종류

버전 관리 시스템은 상용과 비상용(오픈소스)로 구분 할 수 있습니다.

상용
- IBM Rational ClearCase
- Perforce
- PTC Integrity
비상용(오픈소스)
- Subversion(SVN)
- CVS
- Git

위에 나열한 시스템 외에도 수많은 버전 관리 시스템이 있습니다. 버전 관리라는 동일한 목표를 가지고 있지만, 각각의 시스템들은 특색을 가지고 있어, 그 특색에 따라 툴을 사용하는 방법들이 상이합니다. 그리고 상용 프로그램들은 가격이 정말 비쌉니다. 프로그램 라이선스가 1년에 1명 사용하는데 수백만원을 넘기니 말이죠. 그리고 최근 오픈 소스 프로젝트의 대부분은 Git를 사용하고 있습니다. 참고로 예전에는 SVN을 주로 사용했습니다. 여러분이 오픈 소스에 관심 있으시면 Git-Hub(http://git-hub.com/) 사이트를 둘러 보시면 도움이 될 것 입니다.

5. 글을 마치며

버전 관리 시스템은 아마추어 개발자와 전문 개발자를 구분하는 것 중에 하나라고 합니다. 프로젝트를 혼자서 하는 경우도 있고, 몇 명이 나누어서 진행하는 경우도 있습니다. 늘 일정에 쫓기다 보니 '바빠 죽겠는데 버전 관리까지 어떻게 해?'라고 생각하시는 분들도 있을 것입니다. 하지만 일주일 동안 온 힘을 다한 소스 코드를 실수로 날려 버린 경험을 가지신 분들은 버전 관리 및 소스 코드 백업의 필요성을 느끼실 것 입니다.

소스 코드 버전 관리는 정말 유용합니다. 처음 익숙해 질 때 어려움은 있지만, 시간이 조금 더 지나면 버전 관리에 대한 보상을 금방 얻으실 수 있습니다. 요즘 사람들이 많이 쓰는 Git로 버전 관리를 시작해 보시겠어요?

출처 : http://bsnippet.tistory.com/57

형상관리 표준 사례

JAESOO — Mon, 31 Aug 2015 10:05:26 +0000

프로젝트를 수행하다 보면, 프로세스의 표준가이드를 작성하는 것이 쉽지 않다는 것을 느낄 것이다.

그 이유는 프로젝트 특성인 유일성 때문에 주변의 다른 프로젝트와 다른 것이다. 따라서 상이한 것을 재활용하기가 쉽지 않고, 적당한 참고자료를 찾느라 많은 시간을 보내게 된다. 인터넷 덕분에 많은 자료를 찾을 수 있지만 상당수가 영어로 되어 있고, 외국 문화에 근접하여 기술되어 있어 한국적인 현실에 적응하는 것이 쉽지 않은 것이 또 단점이다.

그래서 수행하면서 만들어 두었던 표준 레퍼지토리들 중 형상관리 부문을 공개하여 여러분들과 공유하고자 한다.

수행한 프로젝트는 정부프로젝트로 비교적 사업규모(약 60억)가 큰 프로젝트였고, 신기술을 많이 도입하여 수행한 것이었다. 당시에 EDMS도 도입하였고, Clearcase를 이용한 형상관리를 시도한 점이 인상적이었다.

문서양식 자체가 형상관리의 표준적인 양식이 되기에 문서 전체를 첨부하기엔 부담이 있으니 아래 목차를 참고하시고, 필요하신 분들은 댓글을 이메일과 함께 남겨주시면 보내드리도록 하겠습니다.

해당 자료는 형상관리를 수행하려나 잘 감이 오지 않는 분이나, 구체적인 프로세스가 궁금하셨던 분들은 참고하여 주세요.

출처 : http://gmood.tistory.com/374

형상관리 정의, 도구의 필요성, 개념과 활용, 용어, 베이스라인 개념, 과정, 도입 고려사항, 도구

JAESOO — Mon, 31 Aug 2015 10:01:38 +0000

이야기를 시작하며...

오래전부터 관심이 있던 부분인데, 프로젝트의 작업환경과 관리자의 마인드가 여건이 되지 않아 이부분만 현장에 적용한 것들이 많다. 형상관리를 좀더 잘 활용하면 기존 생성부분을 재활용함으로써 소프트웨어 개발단가를 낮출 수 있음에도 불구하고 기술적/비용적인 문제로 시도가 되지 않고 있는 것이 현실이다. 아직도 많은 프로젝트가 재활용없이 신규로 작성되는 부분이 많다. 비교적, 웹시스템 구축은 재활용이 많으나 이 경우도 관리가 제대로 되지 않아서 중복관리되는 경우가 많이 있다.

개인적으로 미국의 형상관리시스템을 프로젝트 관계로 10여년 전에 접했는데 당시로는 대단한 충격이었다. 재활용 차원이 아닌 모든 자료(문서포함)를 관리하며, 효율적으로 관리 소프트웨어를 운영하는 것을 보고 CMM을 형식적으로 운영하는 것이 아닌 활용하고 있다는 생각에 참 부럽다는 생각이 많았다.

아시다시피 CMM이나 SPICE에도 형상관리 항목은 있으나 매우 작은 부분이라 형식적으로만 수행하면 통과되는 것이기에 당시 많은 한국회사들이 CMM 심사통과 목적으로 형식적인 형상관리를 수행하였고, 형상관리의 정확한 개념을 이해하는 분드로 그리 많지 않았다. 기술적으로도 개발된 소스를 관리해 보았자 이를 시스템에 재활용되는 경우는 극히 저조했기에 재활용은 문서만을 대상으로 하는 경우가 많았다. 그러나, 기술의 발달로 오늘날 대부분의 소스는 Object로 재활용 가능하며, 문서 또한 호환되는 포맷을 ㅗ저장 관리되고 있다.

그러면 마인드는 어떨까?
이 글을 읽으시는 분들은 형상관리가 필요하다고 생각하는가? 귀찮은 추가 작업이니 프로젝트에서 제일 일이 적은 사람에게 할당하거나 마지막 단계에 한꺼번에 수행하자고 생각하지는 않는가? 즉, 프로젝트 관리의 마인드에서 형상관리가 품질보다도 우선순위에서 밀리는 것이 안타까운 현실이다. 애초부터 마인드가 문제지 기술이 문제가 아니었다.

그러나 마냥 여건이 성숙되기를 기다릴 수 없으니 마인드를 바꾸고 여건을 만들고자 이렇게 형상관리 이야기를 시작한다. 여러 회로 연재될 형상관리 시리즈를 통해 많은 분들이 지식을 쌓고, 특히 현업 PM들이 사안의 중요성을 인식하는 계기가 되기를 바란다.

시스템공학자들은 '구성관리'라고도 하고, 소프트웨어 공학자들은 '형상관리'라고 하는데, 호칭은 형상관리가 대중화되어 있다. 영어로는 'Configuration Management'이다.

1. 형상관리란

가. 형상이란

S/W를 개발하는데 있어 하나의 파일만 가지고 모든 실행 모듈이 생성되는 경우는 없다. C언어로 개발되는 경우만 보더라도 그와 관련되는 헤더파일, 라이브러리 파일, 각종 문서들이 있기 마련이다. 이 중에서 우리가 원하는 어떠한 기능을 추가하게 되면 거기에 맞춰서 소프트웨어는 변화를 하게 된다.

예를 들어, A라는 기능을 하게 되는 각 소스들의 버전과 B라는 기능을 하게 되는 소스들의 버전을 달라지게 마련인데, 이때 각 기능을 하기 위한 소스 버전들의 집합을 '형상'이라는 말로 표현하면 이해가 쉬울 것이다. 즉, A라는 기능을 수행하기 위한 각 소스들의 버전의 형태를 '형상'이라고 표현한다.

나. 형상관리 활동의 4가지

시스템을 구성하는 각 부품들, 즉 형상관리의 대상으로 삼을 수 있는 것들을 통칭하여 '형상 항목(Configuration Item)'이라 지칭한다. 이들의 기능적/물리적 특성을 파악함으로써 각 형상 항목을 인식하고 구조화하게 되는데, 이를 '형상식별'이라고 한다.
각 형상 항목들은 시간에 따라 진화를 하게 되는데 이를 제어하고 기록하는 것이 필요하다. 이를 '형상제어'라 한다.
현재의 형상상태 및 형상관리의 진행상태 즉, 현재 각 형상 항목들의 관계나 구현 상태 및 변화 절차를 보고하는 활동이 필요하다. 이를 '형상보고'라 한다.
마지막으로 이러한 변경들이 미리 정해진 요구사항과 일치하는가를 점검해야 하는데, 이를 '형상감사'라 한다.

2. 형상관리 도구의 필요성 (형상관리 도구의 기능)

가. 자원의 중앙 집중적 통합관리

형상관리를 하게 되면 가장 먼저 하는 일이 대상 자원들을 구분하고 구조화하는 작업을 하게 된다. 그리고 나서 대상 자원들을 특정한 저장소에 모아두게 된다. 이렇게 하여 자원의 분산 및 중복 보관을 막게 된다.

나. 자원들의 효율적인 버전 및 이력관리

형상관리의 시작이 버전 및 이력관리에서 출발했듯이 가장 기본적인 것이라 할 수 있다. 자원들이 변화가 일어날 때만다 변화에 관련되는 정보, 즉 누가, 언제, 왜, 어떻게 등의 정보를 관리하는 기능이다. 많이 보급되고 있는 문서관리/이력관리 툴들이 형상관리의 일부인 것이다.

다. 작업 공간의 효율적 사용

형상관리 도구들은 고유한 형태의 자원저장소(Repository)를 보유하고 있으며, 사용자 별 또는 작업그룹 별로 리포지토리를 접근하거나 볼 수 있는 권한을 제어할 수 있도록 해 준다. 최근에 떠들썩한 고가의 설계도 유출사건도 이러한 도구를 사용한다면 방지할 수 있는데 안타까운 일이다.

라. 작업의 진행상태 파악 및 효율적 분배

대부분의 형상관리 도구들이 트래킹 기능을 가지고 있어 각 작업 단위 별 작업의 진행상태 및 경과정도 등을 파악할 수 있다. 뿐만 아니라 개발자, 개인 별로 작업의 상태 등을 파악할 수 있어서 관리자들은 작업을 분배하기가 쉬워진다.

마. 다양한 리포트

개발 및 유지보수 동안에 발생하는 다양한 정보들을 기록하고 관리하여 다양한 리포트 형태로 제공한다.

바. 작업 프로세스 지원

형상관리 도구를 통해 각 작업 단계 별로 필요한 작업들을 미리 정의하고, 거기에 준하여 작업할 수 있도록 지원한다는 의미이다.

사. 효율적이고 정형화된 의사소통 수단 제공

현재 나와 있는 형상관리 도구들은 자체적으로 정형화된 형태의 다양한 변경 요청서를 제공한다. 이를 이용하여 사용자들은 자신의 변경 사유를 기술하게 되고, 이것이 형상관리 도구 내에서 각 개인 사용자들에게 할당되게 되는 것이다.

3. 형상관리의 개념과 활용

현재 대부분의 많은 조직들에서 형상관리를 하려고 하고 형상관리 도구의 도입을 적극 검토하고 있다. 하지만 이것은 단순한 필요성에서 기인한 것에 불구하다. 대부분의 조직들이 형상관리 도구를 도입함으로써 자신의 조직들은 완벽한 형상관리를 할 수 있을 것이라 생각을 하기 때문에 형상관리 도구 도입에 실패하게 되는 것이다. 즉, 형상관리를 하기 위해서는 사전에 더 많은 준비를 필요로 하는 것이다.

가. 자유로운 개발을 하는 조직

이와 관련해 개발자들이 중심이 되어 작업을 하는 조직의 형상관리 도구 적용 사례를 살펴본다. 기본적으로 모든 형상관리 환경은 개발자들을 중심으로 구성되기는 하지만 형상관리의 절차를 간과해서는 안된다. 즉, 기본적으로 형상관리를 하는데 있어서의 절차를 무시할 수 없다는 것이다.

개발자 중심의 이 조직은 H/W를 제어하는 S/W를 만드는 조직으로 모든 작업을 개발자들이 담당 업무 별로 하도록 되어 있으며, 조직원들은 각자 업무에 맞는 프로그램을 개발하고 관리하는 일을 자신이 알아서 하도록 규정하고 있다.

이 조직은 한 마디로 모든 개발을 개발자들이 알아서 하는 조직이었다. Unix 환경에서 모든 사용자들이 개발을 하게 되는데 C를 사용하여 개발을 하게 된다. 물론 개발자들은 자신의 워크스테이션을 사용해 서버에 접속하여 개발을 하게 된다. 하지만 이 조직은 S/W를 개발하는 조직이 아니라 H/W에 들어가는 S/W를 개발하는 조직이다. 모든 개발자들은 자신이 담당하는 분야가 따로 있고, S/W를 개발하고 나서는 개발된 S/W는 자신이 담당하는 테스트용 H/W에 옮겨서 테스트를 하게 된다. 이 과정에서 문제가 발생하지 않으면 바로 실제 H/W로 만들어 내게 되는 것이다. 이렇게 작업을 하다 보니 모든 작업자들이 알아서 작업을 하게 되는 것이다.

다만, 개발에 들어가기 전에 변경요청서를 작성하고, 개발과 테스트 과정이 끝난 후 실제 H/W에 적용하기 전에 변경완료보고서를 작성하여 제출을 하도록 규정을 하고 있기는 하지만 실제로 전혀 지켜지고 있지는 않았다. 구두상으로 개발자들이 개발팀장에게 보고하는 형태를 취할 뿐이었다.

나. 적용 전 문제점

가장 큰 문제는 작업의 통제가 안된다는 것이다. 각자가 알아서 개발하고 자신만의 고유한 영역을 확보하고 있고, 모든 관리 역시 개인이 알아서 하는 형태를 취하다 보니 관리가 제대로 되지 않았다. 자신이 만들어 낸 프로그램을 H/W에 이식하여 실행 모듈로 만들어 다른 H/W와 운영에 들어갔을 때 문제가 발생하면 정확한 원인을 파악하는데 많은 시간이 소요가 됐다.

공통되는 모듈의 경우 개인 별로 자신의 작업 영역에 보유하고 있어서 변경이 발생했을 때 다른 사람이 소유하고 있는 것에 반영을 하기 위해서는 많은 시간이 소요가 될 뿐 아니라, 즉시 변경된 내용이 반영될 수 없다는 단점 또한 가지고 있다.

내부적으로 형상관리 절차를 규정하고는 있으나 전혀 지켜지지 않는 상태이고, 전체 개발과정과 관련하여 다른 외부 인증기관으로부터 인증 심사 준비를 하고 있는 상태여서 형상관리와 관련해서도 절차를 명확히 규정하고 조직원들이 이 절차를 정확히 따르는 것 또한 중대한 문제점이었다. 하지만 조직의 특성상 기존 형상관리 도입을 통해 업무 자체가 너무 많은 변화를 일으킨다면 일의 능률이 저하될 수 있으며, 조직원들의 심한 반발을 초래할 소지가 많아서 아주 신중한 적용이 요구되고 있었다.

다.적용 후 운용 환경

일단 가장 중요한 두 가지 작업은 형상관리 절차를 명확히 하는 일이었다. 다음으로는 여기 저기에 보관되고 있는 개발 소스를 한 곳으로 모으는 일이었다.

형상관리 절차는 기존에 사내 규정으로 있던 형상관리 절차를 그대로 이용하는 것을 원칙으로 하였다. 다만 개발자드리 불편을 느끼지 않도록 최소한의 절차로 줄이고 개발자들의 역할 또한 최소한으로 그리고 꼭 필요한 것으로 제한하여 형상관리 도구의 도입으로 인하여 많은 부분에 대해 준비하고 공부해야 하는 시간을 줄이는데 중점을 두었다. 형상관리 절차는 다음과 같다.

개발자들은 개발에 들어가기 전에 변경계획서를 작성하여 개발 팀장에게 승인을 요청하게 된다. 물론 이 과정에서 변경계획서 같은 경우 여러 가지 기본적인 내용 이외에 추가적인 그림 또는 다른 자료들이 있는 경우가 있으므로 파일을 다른 프로그램을 이용하여 만들고, 그 내용을 형상관리 도구로 불러 들여서 사용하도록 정의했다. 이렇게 하면 변경계획서가 개발팀장에게 전달이 되게 되고, 개발팀장이 이 내용을 검토 후 승인을 하게 되면 개발자들이 개발에 들어가게 되는 것이다. 개발자들은 형상관리 도구를 이용해 자신들이 필요한 소스들을 Check Out 하고 변경을 하게 된다.

변경이 끝나게 되면 테스트 과정을 거치게 되고 문제가 없다고 판단되면 변경된 소스를 형상관리 도구로 Check In하게 된다. Check In을 하는 과정에서 개발자들은 변경 완료보고를 작성하여 형상관리 도구에 붙여 넣게 된다. 변경 완료보고서를 작성 후 변경 완료 승인 요청을 개발팀장에게 하게 되고, 이렇게 되면 개발팀장은 전체 사항을 검토 후 승인을 하게 되면 그 내용이 형상관리 담당자에게 전달되게 된다. 형상관리 담당자는 이 단계에서 변경된 소스들을 이용하여 H/W를 만들 수 있도록 개발자들에게 허락해 주는 것이다.

다음 문제는 소스들을 한 곳으로 집중하는 일이었다. 많은 개발자들이 자신의 고유 영역에 개인적으로 소스들을 보관하고 있어 형상관리 도구를 이용하여 관리하기 위헤서는 한곳으로 소스를 모아 놓고 형상관리 도구를 통해서만 모든 소스들에 접근할 수 있도록 하는 일이 아주 중요한 일이었다. 그래서 하나의 서버를 형상관리 서버로 지정하고, 모든 소스들을 이 곳에 모아 리포지토리를 생성했다. 개발자들은 형상관리 클라이언트 모듈을 사용해 서버에 접속하여 작업을 하게 된다.

라. 적용 후 이점

이 조직에서의 형상관리 도입은 처음이나 다름없다. 즉, 미리 준비되어 있는 극본은 있으나 한 번도 무대에 올려지지 않은 연극과 같은 상태였다.

형상관리 적용으로 일단은 기존에 존재하던 형상관리 절차를 강제적으로 적용할 수 있게 된 것읻. 이 절차를 통하지 않고는 개발자들이 개발을 할 수 없도록 막아버림으로 형상관리 절차를 철저히 지키게 됐다. 이로 인해 외부 인증 심사를 아주 좋은 성적으로 통과할 수 있었다. 즉, 형상관리를 통해 기본적인 내부 절차가 정착화 됐다는 것이 가장 좋은 결과라 할 수 있다.

다음은 자원관리 부분이다. 여기 저기 흩어져 있던 자원을 한 곳에 모을 수 있는 기회를 만들었을 뿐 아니라 체계적으로 관리할 수 있는 기반을 마련한 것이다.

개발자들의 고유 작업 영역에는 전혀 변화가 없었다. 다만 개발자들은 변경을 하기 전에 변경을 원하는 파일들을 먼저 형상관리 서버에서 자신의 작업영역으로 Check Out 하는 것 이외에는 특별한 변화는 전혀 없었다. 기존의 작업 디렉토리 구조 및 영역을 유지할 수 있기 때문이다.

형상관리 담당자 입장에서는 전체 개발 주기를 제어할 수 있을 뿐 아니라 형상관리 도구에서 제공하는 다양한 로그를 통해 문제점 발생 시 추적할 수 있는 기반을 구축했다.

다양한 리포트를 통해 작업의 진행 상태를 출력할 수 있게 됐다. 뿐만 아니라 중요한 리포트의 경우는 HTML 문서 형식으로 만들어 기존에 운영하는 인트라넷을 통해 주기적으로 리포팅해 줌으로써 일일이 리포팅을 해야 하는 불편함을 최소화했고, 업무를 좀더 자동화 했다.

마. 도구 선택 시 중요한 원칙

형상관리 도구를 적용하는데 있어서 그리고 형상관리 도구를 선택하는데 있어서 몇 가지 중요한 원칙을 다시 한 번 짚어보도록 하겠다.

먼저 형상관리를 적용하기 위해서는 가장 먼저 환경을 만드는 것이다.

첫째, 형상관리 절차를 만들어야 한다. 여러 차례에 걸쳐 얘기했듯이 형상관리에는 절차도 중요한 요소이다. 단순히 형상관리 도구를 도입해 버전 및 이력관리만을 생각하고 있는 조직이라면 형상관리를 좀더 나중에 도입하라고 말하고 싰다. 비싼 대가를 지불해야만 형상관리 도구를 도입할 수 있는데 이러한 문제는 기본적으로 고려를 해야 할 뿐 아니라 꼭 필요한 요소이다.

또한 모든 표준화 기구 및 인증기관들에서도 단순히 형상관리가 아닌 버전관리만을 하는 것을 지양하고, 일정한 절차에 따라 형상관리를 할 것을 표준으로 제시하고 있다. 또한 단순한 버전관리만을 목적으로 형상관리 도구를 도입하는 경우 대부분의 경우 실패를 하기 마련이다. 이것은 대부분의 개발자들은 형상관리라는 것을 귀찮게 생각하기 마련이고 이렇기 때문에 절차를 만들어 절차에 따라 하지 않으면 개발을 할 수 없도록 만들어야만 개발자들이 형상관리에 적극 참여하도록 해야 한다. 그러므로 형상관리 절차를 만들고 거기에 준하여 작업할 수 있도록 하는 것이 아주 중요한 요소이다.

둘째, 형상관리 환경 구성을 어떻게 할 것인지 설정해 두어야 한다. 절차를 아무리 잘 만들었다 해도 복잡하고 까다롭다면 별 의미가 없다. 또한 형상관리 환경이 절차를 따르지 않고도 개발을 할 수 있는 환경이라면 의미가 없어진다. 그러므로 절차는 간단하고 단순하게 꼭 필요한 부분만을 수용해야 하며, 환경 자체도 절차를 따르지 않고는 변경관리를 할 수 없도록 정의되어 있어야 한다. 예를 들어, 개발 영역과 운영 영역이 동일하다 하면 개발자들은 얼마든지 운영 영역에서 직접 모든 작업을 하는 것을 막을 수는 없을 것이다. 그러므로 일단 운영 영역과 개발 영역을 분리해야 한다. 즉, 개발 영역에서 변경된 내용들이 형상관리 서버를 통하지 않고는 운영 영역에 전달될 수 없도록 해야 하며, 개발자들이 운영 영역에 접근할 수 없도록 해야 한다는 것이다.

셋째, 사용자들의 권한 및 조직원 구성을 어떻게 할지를 설정해야 한다. 사용자들은 어떠한 권한을 가지고 작업을 할 수 있는지 작업할 수 있는 내용과 작업할 수 있는 내용은 무엇인지 미리 정의해야 한다. 이렇게 함으로써 권한이 없는 사람이 실수로 작업해서 발생하는 문제점도 사전에 대비할 수 있으며 또한 각 사용자들 입장에서도 자신에게 불필요한 형상관리 도구의 기능까지 습득할 필요가 없어서 편리성을 갖게 되는 것이다.

바. 도구 선택 시 고려사항

첫째, 일단 우리 환경에 얼마나 적합한지를 살펴보아야 한다. 형상관리라는 것이 단순히 도구의 도입만으로 이뤄지지 않는다. 도구의 도입 시 현재 우리 호나경에 대해 많은 고민을 해야 한다. 그래서 현재 우리가 개발하고 있는 환경에서 최소한의 변화로 적용을 할 수 있어야 하며, 비용 등도 고려해야 할 것이다.

둘째, 많은 기능이 제공되는 툴 보다는 꼭 필요한 기능이 제공되는 도구를 선택해야 한다. 형상관리 도구의 적용에 있어서 많은 기능에 제공된다는 것은 의미가 없다. 집에서 TV를 한 번 생각해 보도록 하자. 많은 기능들이 있지만 채널과 볼륨이외에 얼마나 많은 기능들을 활용하고 있는지에 대해 형상관리 도구도 동일하다. 도구마다 수많은 기능들이 제공된다고 해도 실제 사용자들이 사용하게 되는 기능들은 5%도 되지 않는 경우가 허다하다. 비싼 비용을 들어 많은 기능을 제공하는 도구를 선택하기보다는 우리에게 꼭 필요한 기능을 제공하는 도구를 선택해야 한다. 형상관리 도구들은 대부분 대동 소이한 기능을 제공하고 있는 것이 사실이다. 사용자들 입장에서는 이러한 것을 구분해 내는 것이 그리 쉬운 일은 아닐 것이다. 우리가 꼭 필요로 하는 기능들에 대해 사전에 정리하고 가중치를 두어 도구를 검토할 때 평가 요소로 삼아야 할 것이다.

셋째, 기술 지원 능력 및 사후 관리에 대한 요소들도 점검해야 한다. 마지막으로 기술 지원 및 사후 관리에 대한 요소를 점검해야 한다. 일반적으로 형상관리를 도입 적용하기 위해서는 많은 시간을 필요로 하게 된다. 또한 경험이 전혀없는 조직의 경우는 더 많은 시간과 기술을 필요로 하게 된다. 이 과정에서 형상관리 도구를 지원하는 인력의 기술력과 경험은 아주 중요한 요소가 될 수 밖에 없다. 또한 얼마나 많이 많은 내용을 지원해 줄 것인가도 중요한 평가 요인인다. 현재 국내에는 형상관리와 관련해 많은 기술 지원 인력을 확보하고 있는 상태가 아니다. 따라서 기술 지원을 받기 위해서는 적지 않은 비용이 들게 된다. 형상관리 도구의 도입보다 더 큰 비용이 추가로 지불될 수 있으므로 도입 이후 형상관리 관련 기술 지원에 대한 비용 문제도 확실하게 계획을 세워야 한다.

4. 형상관리 용어

형상관리에서 많이 쓰이는 용어를 나열하였고, 기타사항을 파일로 첨부한다. 용어가 다수 기존의 방법론에서 설명한 것과 중복되는데 그것은 형상관리도 방법론을 지원하는 한 부분이기 때문이다.

가. 설계형상(As-Designed)

제품이 설계된 형상을 말한다. 이의 부품표를 '설계향상 As-Designed) BOM' 혹은 '설계(Engineering) BOM'이라고 한다. 이는 제품 형상의 기초가 되는 것으로 설계자나 고객의 입장에서 만들어진 것이며, 설계변경(Engineering Change)이 여기서부터 시작된다.

나. 생산형상(As-Planned)

설계된 제품을 생산하기 위해 계획한 형상을 말한다. 이의 부품표를 생산형상(As-Planned) BOM 혹은 제조(Manufacturing) BOM이라 하며, 생산 절차를 기술한 문서를 공정설계(Operation Planning)라 한다. 설계형상(As-Planned) BOM이 설계자의 입장에서 만들어진 것인데 비해 생산형상(As-Planned) BOM은 생산기술자에 의해 생산의 용이성이 감안되어 다시 만들어진 것이다. 따라서 생산형상 BOM은 설계형상 BOM과의 차이가 없음이 증명될 수 있어야 하며, 설계변경 사항이 적시에 반영되어야 한다. 특히 생산형상(As-Planned) BOM은 MRP의 가장 중요한 Input이므로 공정설계와 제품구조의 일치성이 보장되어야 한다.

다. 완성형상(As-Built)

완성된 형상을 말하는 것으로 최초 계획에서 설계변경 등 이력을 포함하여 생산 과정에서의 개선사항, 품질검사 결과 및 사후처리, 대체품을 포함한 실제 사용된 부품에 관한 제반사항 등의 광범위한 정보가 포함되어 있다. 이는 사양을 준수하여 제조하였다는 증명임과 동시에 고객에 인도되는 제품의 최종 형상으로 향후 운영 시 유지보수의 기반이 된다.

라. 운영형상(As-Maintained)

고객에 의해 운영되고 있는 형상을 말한다. 항공기, 선박, 첨단장비, 무기류 등은 제품 수명주기가 길거나 안전과 관련된 제품, 프로그램이나 첨단기술이 계속 보강되는 제품들은 현재 상태의 형상이 관리되어야 정확한 부품교환 및 수리가 가능하다. 그러므로 제품과 함께 운영형상(As-Maintained BOM)이 관리되어야 하며, 고객과 정비업체간 상호 운용성을 제공해야 한다.

마. Physical Configuration Audit

형상관리 활동의 하나로서 기능적 형상검토(FCA: Functional Configuration Audit) 이후에 개발 완료된 제품이 생산(또는 출하)에 필요한 요건을 갖추었는지를 검토해야 한다.

5. 형상관리 베이스라인(Baseline)의 개념

시스템의 생명주기의 일정 시점마다 그간의 제품상태(산출물)를 검토하고, 그 결과를 반영하여 다음 개발단계로 이전하는 방법을 사용한다. 이러한 시점이 곧 베이스라인(Baseline)이다.

즉, 베이스라인이란 생명주기 내에서 공학적, 관리적, 획득적 측면을 고려하여 정한 하나의 분기점 혹은 관리점과 그 때의 산출물을 의미하는 것으로써 개발 주기의 각 단계에서 산출되는 산출물에 대해 사용자의 요구조건을 만족시키는지 여부를 공식적인 검증과 확인을 거쳐, 한 단계를 동결하고 다음의 단계를 시작하는 기준점이 된다.

이러한 개발기점(Baseline)은 요구분석, 디자인, 코딩, 테스팅, 변경요청 등을 통제 관리하기 위해 설정하는 것으로 개발활동에 따른 시간의 순차에 의해 설정된다.

일반적으로 개발기점은 다음과 같이 5단계로 구분된다.

시스템 기능분류 기점 (FB: Functional Baseline)
- 시스템명세서(SS)의 검토 후 승인되는 시점에서 통제되는 라이브러리로 관리
소프트웨어 기능분류 기점 (AB: Allocated Baseline)
- 소프트웨어 요구분석(SRS)의 검토 후 승인되는 시점에서 통제되는 라이브러리로 관리
디자인 기점 (DB: Design Baseline)
- 기초(기본)설계 명세서 검토(PDR)와 상세설계 명세서의 검토(CDR) 검토 후 승인되는 시점에서 통제관리
최종 산출물 생성 기점 (PB: Product Baseline)
- 프로그램, 통합시험과 시스템 시험규격서/보고서가 검토 후 승인되는 시점에서 통제관리
운영개발 기점 (OB: Operational Baseline)
- 최종 산출물인 소프트웨어를 사용자에게 인도하기 위한 인증시험의 종료 후 승인되는 시점을 말하며, 운영의 시작시점인 동시에 유지보수를 위한 기준이 된다. 관리대상인 형상 항목에는 운영자 매뉴얼, 사용자 매뉴얼, 설치 매뉴얼, 목적/실행 코드 등이 있다.

미국방성의 MIL-STD-2167에서는 시스템에 대하여 3단계의 개발기점을 적용하고 있다.

기능분류 기점 (FB: Functional Baseline)
기능배분 기점 (AB: Allocated Baseline)
최종 산출물 생성 기점 (PB: Product Baseline)

이는 주로 제품(산출물) 중심의 단계적개발 접근방법(Phased Development Approach)으로

개념정립단계 (Concept Development Phase)
체계개발단계 (Development Phase)
운용 및 유지보수 단계 (Operation And Maintenance Phase)

로 베이스라인을 중심으로 형상관리 방법론을 적용하고 있다.

예를 들면, 기능배분 기점(AB)에서의 소프트웨어 요구사항 명세서(SRS)와 인터페이스 요구사항 명세서(IRS)를 바탕으로 실제적인 개발이 이루어지는데, 이 과정 중의 시스템 형상을 개발형상(Development Configuration)이라 한다.

이러한 개발 형상을 이루는 문서들을 개발기점(Baseline)의 검토 별로 나열해 보면, 아래 그림과 같다. 그림에서 보는 바와 같이 각 개발단계와 베이스라인은 밀접하게 연관되어 있어 베이스라인을 기준으로 개발단계의 진척을 평가하기도 한다.

예전 군사정보 사이트에서 참조한 자료입니다. 영어로 기술된 베이스라인의 상세 설명입니다. 참조바랍니다.

6. 형상관리 과정

가. 형상 식별

형상관리 대상 즉, 형상항목의 기능적/물리적 특성을 파악함으로써 형상항목을 식별하고 구조화
관리번호 부여
소프트웨어 형상의 구조 변경이 요구될 때 추적이 용이하도록 명확하게 정의
통제가 용이하도록 누가, 언제, 무엇을, 왜 정의하였는가 하는 정보를 생성
기준선 설정

아래와 같은 문서들이 베이스라인의 설정기준이 될 수 있다. 즉, 아래의 산출물들이 승인되는 시점들을 각각의 베이스라인으로 설정할 수 있다. 베이스라인의 특성에 따라 복수의 산출물들이 한 베이스라인에서 승인될 수 있다.

System Specification
Software Project Plan
Software Requirements Specification
Preliminary Use Manual
Design Specification (e.g. Datadesign description, Module design description)
Source Code Listings
Test Specification (e.g. Test plan and procedure, Test cases and recorded results)
Operation and Installation Manuals
Excutable Program
Database Description (e.g. Schema and file structure, Intial content)
As-built User Manual
Maintenance Documents (e.g. Software problem report, Maintenance requests)
Standards and Procedures for Software Engineening

나. 형상 통제

식별된 형상항목의 변경요구를 검토 및 승인하여 기준선에 변경사항을 반영되도록 통제
변경요청자 및 작업수행자가 참여하는 형상통제위원회의 구성
형상통제위원회는 기준선 및 변경을 승인하고, 소프트웨어의 형상에 영향을 주는 변경에 ㅐ하여 검토하고 승인
Access Control, Change Control, Version Control

변경요청 및 처리에 기술되는 문서에는 다음의 항목이 포함되어야 한다.

변경사항
변경식별번호
변경과 관련된 사항
변경의 범위와 미치는 영향
비용 및 일정에 미치는 영향
아래 도시된 문서화 된 변경절차가 존재해야 함

다. 형상 감사

기준선에 대한 변경이 미리 정해진 요구사항과 일치하는지 점검
기준선의 무결성을 평가하여 공식적으로 승인
소프트웨어에 대한 이해도가 높은 그룹(정보시스템 감사, 품질보증조직)에 의하여 수행
객관적인 확인 및 검증을 거침으로써 새로운 형상의 무결성을 확보
① 검증(Verification)
- 기준선의 형상항목이 전 단계 기준선으로부터 논리적으로 진화되었는가를 검토
- 사용자 관점에서 요구사항의 이행을 중점적으로 확인
- 소프트웨어 제품을 확인하기 위하여 수행
② 확인(Validation)
- 이전 단계에서 요구한 사항이 현 단계에서 진행했는가 확인
- 기준선 내 형상항목의 논리적인 진행과정을 검토

아래는 감사 시 수행하는 질문의 한 예이다.

형상감사위원회가 변경을 검토하였는가? 추가적인 변경사항이 수행되지 않았는가?
공식적인 기술검토회를 거쳐서 수정사항을 검토하였는가?
공학표준을 준수하여 수행하였는가?
변경대상, 날짜, 작성자 및 변경에 대한 상세한 내용이 기술되었는가?
정의된 프로세스에 따라 변경, 기록, 보고되었는가?
관련된 변경대상이 정확히 수행되었는가?

라. 형상기록

소프트웨어 형상 및 변경관리의 식별, 통제 및 감사의 결과를 기록
보고서 작성
- 이전 베이스라인의 승인시점
- 현 베이스라인의 시작시점
- 각 형상항목의 요약된 정보
- 변경문서의 상태(거부/승인/대기 등)
- 각 변경문서의 내용
- 변경대상의 상태
- 변경대상의 정보(버전 등)
- 베이스라인 변경에 대한 기술적/관리적인 상태 기록
- 형상감사 기록

7. 형상관리 도입 시 고려해야 할 사항

가. 경영진의 의지

A. 변화에 대한 개발자의 저항을 해소하기 위해서는 경영진의 의지가 확고해야 함

'형상관리를 도입한다'함은 기존 문서처리절차에 추가적인 처리단계가 생기며, 추가작업에 대한 기존 숙련자의 반발은 효과적인 홍보와 대안을 제시하여 저항을 최소화 해야 성공적으로 도입할 수 있다. 예를 들면, 형상관리절차에 따라 문서 등을 배포 전 처리하느데 소요되는 시간과 결정사항이 있는데, 시간이 급하니 생략하거나 시간을 할당하지 않고 기존대로 계획을 세운다면 이것은 작업자의 추가적인 희생만을 강요하게 되므로 형식적으로 수행하는 실패 사례가 된다.

기업조직에서 결정의 최종권한자인 경영진에서 이와 같은 변화를 고려해야 할 형상관리 도입이 성공적으로 정착할 수 있다.

B. 작업자들의 모든 내용을 기록하도록 하고 이를 감시하기 위해서는 경영진의 시간과 비용이 투입 요청됨

최근에 조선소의 설계본이 유출되거나 반도체 설계도가 유출되는 사건이 발생하였고, 기업체에서는 내부자의 보안관리를 철저히 하기 위해 EDMS르 도입한다느니 내부자 보안에 역점을 두는 추세이다. 보안사고는 대부분이 기업 내부자에 의해 발생하게 되며, 사고유형은 대부분이 정보유출과 방치 등이다.

다음 장에 형상관리도구에도 소개하겠지만 형상관리도 도구를 사용하면 효과적인 운영과 작업시간을 절약할 수 있다. 그러나, 이를 도입하게 되면 비용, 교육 및 적응시간에 따른 작업손실 등 시간과 비용이 요구된다. 더구나 일부가 아닌 일부가 아닌 전 부서, 전 프로세스에 적용한다면 경영진은 이에 따른 비용(전문관리부서 신설 등)을 고려해야 한다.

C. 가시성과 추적성의 결핍으로 인한 의사결정의 한계를 극복해야 함

형상관리는 도구를 사용한다고 하더라도 즉각적으로 효과를 측정하기 어렵다. 그 이유는 형상관리는 산출물을 생산하는 도구가 아닌 생산을 지원하는 도구이며, 주 입력물은 산출물과 그에 따른 이력정보이기 때문이다. 이력정보는 산출물이 갱신되면서 생성되므로 산출물이 갱신되어감에 따라 이력정보를 이용하여 추적이 가능하므로 이력정보는 도입 후 즉시 이용 가능한 정보가 아니다.

또한, 이력정보의 입력 시 출처 및 작성자, 날짜 등을 입력하게 되는데 최초 입력 시 충분한 정보를 입력할 수 없는 상태일 수 있다. 이에 대한 공감대를 형성해야 도입 및 활용이 조직에 정착하게 된다. 일례로 제가 수행한 프로젝트에서는 창고에 있는 물건이 언제 제조되었고, 상태가 어떤지도 관리되지 않는 것도 있었다. 물론 관련 문서도 없었으나 관련 담당자도 적절히 할당되어 있지 않았기에 이력이 손실된 것이다.

즉, 이력정보는 산출물의 생성/배포 후 추적과 재활용 시점에 빛을 발하는 것이다.

나. 관리조직의 확립

A. 형상관리를 효율적으로 수행하기 위해서는 품질보증조직과 같은 별도의 조직을 운영함이 바람직함

흔히, 형상관리는 품질조직이 같이 겸임해도 될 것으로 생각하게 된다. 그러나, 이것은 불가능한 궁합이다. 형상관리의 활동 중 형상감사는 형상관리자가 수행하는 활동이 아닌 품질관리 조직이 담당하고 체크하는 것이다. 즉, 품질보증조직이 형상관리를 감시하는 것이기에 같은 조직이 활동을 수행한다면 고양이에게 생선을 주는 형태가 된다.

또한 형상관리는 베이스라인에 따라 운영되며 산출물의 배포/변경을 담당하므로 테스트 및 프로세스의 적적한 수행을 점검하는 품질조직과는 업무성격도 다르다. 분리해서 운영함이 바람직하며, 형상관리 규모에 따라 별도 부서가 담당하는 것도 좋은 방안이다. 보통 프로젝트 레벨에서 별도의 관리자를 부여하기도 하지만 개발자들이 형상관리도구 교육을 잘 받는다면 형상관리는 PM이 할 수 있을 정도로 도구가 잘 되어 있다.

자료의 형태와 량에 따라 다르지만 중앙에서 형상자료를 관리하는 형태인 경우에는 형상 데이터의 정리와 추세를 감시하는 조직이 필요하나 조직 별로 분산하여 관리하는 형태인 경우에는 각 조직의 관리자가 수행하면 충분하다.

B. 사용자와 개발자가 공동으로 형상통제위원회를 구성

형상변경은 베이스라인과 밀접한 관계가 있다. 개발자는 베이스라인 범위 내에서 사전에 정의된 스팩 하에 별도의 의사결정없이 자유롭게 변경할 수 있으나 베이스라인을 초과하거나 스팩을 변경해야 하는 변경인 경우는 사용자와 반드시 합의하여 수행해야 한다. 이를 협의하는 기구를 형상통제위원회(CCB)라고 부르며, 프로젝트에서는 고객측/개발자측이 연합하여 구성하고 기업 내에서는 조직간 대표가 차출되어 구성된다. CCB는 상설조직이 아닌 임시회의기구 성격이므로 필요 시 소직하나 의사결정사항은 반드시 형상관리자가 기록해야 한다.

C. 소프트웨어의 버전 또는 기준선을 승인하고 이엥 대한 변경을 허가해 주는 공식적인 조직이 필수적임

이것은 CCB의 역할이다. 프로젝트의 PM이 임의의 산출물을 납품하고자 하는 것은 개발자의 의지이며, 이를 승인하는 것은 사용자의 의지이다. 따라서, 행위를 CCB에서 처리한다면 1:1에 의한 승인으로 인해 오류를 정정하는 Rework이 매우 줄어들게 된다. 또한, 복수에 의한 결정이므로 안정적인 의사결정을 수행하게 되어 프로젝트 리스크를 완화시키는 효과가 있다. 실제로 CCB는 위험을 완화시키는 역할도 한다.

다. 형상관리도구와 작업절차

A. 소프트웨어 형상항목의 특성 상 정보시스템으로 관리가 가능하므로 자동화 도구가 필요

과거에는 형상항목의 관리대상이 문서인 경우가 많아 단순 폴더 관리하는 툴들이 많았으나 기술이 발전하고 시스템이 복잡해짐에 따라, 관리대상은 일정한 형태가 아닌 Object로 바뀌고, 보안 및 프라이버시보호 등의 기능이 추가되었다.

또한, 다양한 플랫폼을 지원하므로 개발 중에 언제든지 편리하게 저장관리할 수 있어 백업의 효과를 볼 수 있다. 저장된 자료에 대한 효과적인 검색도 지원하여 타 프로젝트 또한 타 부서의 자료를 쉽게 재활용할 수 있는 등 비용절감 효과를 지원한다.

단순관리에서 개발도구와 연동하여 운영되는 도구까지 다양하므로 해당 기업 또는 프로젝트에 맞는 도구를 사용하기 바란다.

B. 도구의 활용에 앞서 소프트웨어 형상관리 작업절차가 확립되어야 함

형상관리 툴은 형상관리의 수단이지 핵심을 아니다. 도구 도입 전에 형상관리대상이 무엇인지 선정하고, 이에 적합한 프로세스를 정립한 후 이에 적합한 도구를 탐색하여 선정해야 되겠다. 대부분의 도구들이 표준프로세스들을 지원하지만 개발도구와 연동성이 약한 도구도 있기에 이 경우에는 개발자의 추가 기록작업이 수행되어야 한다. Visual SourceSafe는 개발도구인 Visual Studio와 연동되는 것이기에 수정 후에는 자동으로 기록되므로 작업자는 기존작업과 다를 바가 없게 되나, Microsoft에서 많이 사용하는 Source Depot의 경우는 별도의 Checkin & out 절차를 수행해야 하는 번거로움이 있다. 그러나 Source Depot의 경우는 세부적인 변경절차에 따른 기록이 가능하고 버그 관리도 수반하는 다양한 목적의 툴이다.

8. 형상관리 도구

가. 형상관리 도구의 특징

형상관리 도구는 복잡한 형상 항목의 인식과 형상관리활동을 지원하는 자동화 도구로서 다음과 같은 역할을 수행해야 한다.

A. 자원의 집중적 통합관리

형상관리의 모든 요소는 통합적인 관점에서 통제되어야 한다. 즉, 프로젝트의 사항이 회사 규칙에 반한다면 이를 자동으로 제제해야 하는 것이다. 보안 규정 등을 전사적으로 적용하는 것이 한 예가 될 수 있겠다.

B. 자원의 효율적인 버전 및 이려관리

모든 자료의 버전과 수정자, 사유 등 수정 이력은 저장되고 필요 시 추적 가능해야 한다. 이력이 추적되지 않는다면 부당한 수정이나 자료파손에 따른 손실을 감수해야 한다. 즉, 백업도 자동으로 되는 셈이다.

C. 작업 진행상태 파악 및 효율적인 작업 분배

각종 자료가 수정검토/승인을 거치고 수행하는지에 대한 상태정보 이력이 추적 가능해야 하며, 수정작업에 따른 서버의 부하가 적절히 분배되어야 한다. 경우에 따라서는 일부 자원이 수정이 집중될 수 있는데, 이에 따른 수정 오류를 방지하기 위해서는 수정상태의 제공 및 오류정정(Resolve) 등이 지원되어야 한다.

D. 다양한 보고서 작성

수록자료의 변경이력, 배포이력, 수정횟수, 버전, 차이분석 등 다양한 보고자료가 사용자에게 제공되어야 수정패턴 및 통제규칙 설정에 도움을 줄 수 있으며, 생성자료의 재활용을 위한 검색자료로도 활용된다.

E. 작업 프로세스 지원

형상 변경 시 변경요청/검토/승인 등 일련의 세부 프로세스를 도구가 지원한다면 작업자는 매우 편리함을 느낄 것이며, 프로세스의 수행 누락이 없는 생산성 향상에 기여하게 된다.

F. 효율적이고 정형화된 의사소통수단 제공

형상이 변경되거나 완료되거나 하였을 경우, 적절한 주변 Stakeholder에게 자동으로 통보하는 수단이 있다면 더욱 편리할 것이다. 또한, 부당한 사용에 대한 경고가 있다면 더욱 보안유지자에 도움이 되겠다. 이력기록에 일정한 양식을 지정하여 사용한다면 사용자간의 의사소통이 간결하게 될 것이다.

G. 통합개발환경과의 연동

형상관리의 핵심은 개발시스템을 지원하는 것이며, 재활용 및 버전관리를 통한 생산성향상에 기여하는 것이다. 이때, 개발툴과 밀접하게 연동된다면 수정사항이 이력과 함께 별도의 추가 작업없이 개발시스템에 반영되는 것과 동시에 형상 데이터에도 기록할 수 있다는 것을 의미하는 것이기에 매우 효과적일 것이다. MS의 SourceSafe가 그 예이다.

나. 형상관리도구의 선택

형상관리도구를 선택하는 것은 쉬운 부분이 아니다. 그 이유는 의외로 형상관리에 대한 사용자의 요구가 매우 구체적이기 때문이다. 형상관리에 대해 잘 모르는 사람이라도 평소에 이런 것이 되었으면 좋겠다던가 이것이 낭비다라고 생각하는 것이 있으며, 이것은 본인도 모르게 구체적인 형상관리 도구의 요구사항이 된다. 그만큼 형상관리 도구의 대상은 다양하고 방대한 것이다. 즉, 대형조선소의 설계도에서부터 소프트웨어 요구사항까지 모든 표현자료는 형상관리 대상이 되기에 컴퓨터를 모르는 분들이 생성한 자료도 모두 대상이 되는 것이다.

이러한 사용자의 생각이 잘 조사된 것이 1995년 'Improving Your Process for the Evaluation and Selection of Tools and Environments'라는 보고서에서 10가지 절감규칙으로 소개되었다. Westinghouse에서 선정한 10가지는 다음과 같다.

The Westinghouse common 'Cents' Rules

'Haste Makes Waste (성급은 금물)'

도구를 선정하는 시에는 무엇이 필요하고 요구사항은 무엇인지, 제약사항은 없는지 등을 꼼꼼히 따져 보고 해야 하며, 수많은 기능 중 어떤 기능에 중점을 두고 도구를 선정할 것인지 사전에 계획하는 것이 현명한 접근이다. 형상관리의 전 과정 및 데이터의 다양성 등이 이러한 고려요소가 될 수 있다.

다섯개의 도구가 각각 장점을 가지고 있다고 해서 다섯개의 도구를 모두 선택하지 않을 것이다. 예를 들어, F22개발 프로그램 개발 시 다양한 업체가 다양한 개발환경에서 다양한 프로그래밍언어로 개발되는 시스템을 관리해야 된다. 형상관리팀은 도구 선정 시 통합관리가 되는 것을 우선적으로 고려하였다.

'Practitioners Are Prime Evaluator (경험이 최고)'

형상관리 선정 이것은 경험한 사람이 하는 것이 최적이다. 그 이유는 다양한 툴의 다양한 기능들은 무경험자에게는 선택기준이 아닌 단순한 특징에 불과하기 때문이다.

'Evaluate Against User's Needs (사용자 요구사항에 근거한 평가)'

1989년에 Westinghouse는 SEI의 140개의 평가항목을 요약하여 25개 항목을 만들었으나, 1994년 54개로 늘어나다가 1995년에는 67개로 증가하였다. 이러한 항목의 증가는 형상관리 도구의 발전도 있었지만 사용자 요구사항이 변경되었고, 초보 평가자를 위해 상세한 평가항목을 추가한 것이 원인이기도 한다.

아래표는 형상관리 기능의 간략한 요약과 도구간의 비교표이다. 상세내역은 이후에 설명한다. 아래 형상도구는 이 보고서의 발표당시인 1996년 기준의 도표이다. 요즘 국내에 유행하는 PDM, EDMS 도구 등과 비교해 보시길 바란다. PDM/EDMS도 모두 형상관리 도구의 일종이다.

Taxonomy Five SCM Tools

'Don't Believe It Unless You See It (백문이 불여일견)'

앞서 표에서 제시된 다양한 기능에 많은 사람들이 현혹되기 쉬우나 이에 대한 냉철한 분석이 필요하다. 표에서 표현한 것은 전체 기능 중에 일부인 간단한 기능일 수 있다. 실제 프로젝트에서 사용가능한 시나리오를 생각하고 직접 이를 운용하는 테스트를 하면서 선정하는 것도 현명한 접근이다.

'Don't Buy It Until You've Tried It (사용해보고 구매하자)'

많은 사용자가 단지 자신들의 기준을 만족하였다고 하여 툴을 구매하는 것을 볼 수 있다. 그러나 상당수의 툴들이 기준을 다른 시각으로 해석하여 답을 다는 경우가 많으므로 구매를 최종적으로 결정하기 전에 직접 사용해 볼 것을 권한다. 툴 선정기준은 1차적으로 구매제품의 후보선정기준이며, 직접 테스트 후에는 결정기준이 되는 것이다. 후보를 무조건 최종결정하는 오류를 범하지 말길 바란다.

아래 표는 툴을 선정하는 기준을 수립하는데 도움이 될 기초 질문사항들이다. 예를 들면, 만약 툴이 요구사항을 추적하는 기능이 있어야 한다면, 툴은 반드시 변경관리기능(추적관리 및 추적보고서 기능)이 지원되어야 한다. (CM28이 이에 해당되는데, ADC와 ClearCase가 지원되지 않는군요)

'Pay Now or Pay Later (우왕좌왕하지 말자)'

위의 질문에 단순히 Yes/No로만 단정하지 않는다. 각 질문에 대해 중요도를 할당하고 Yes/No에 대해서도 점수를 할당하여 종합점수로 최종적인 평가를 수행한다. 이러한 평가시간은 오래 걸리지 않게 된다.

'Everything is Negotiable (모든 것을 고려하자)'

제품의 성능/기능에 대해 살펴보았다면, 제품의 구매방법에 대해서도 살펴보자. 일부 공급업체는 1 Copy는 팔지 않는 경우도 있고, 어떤 업체는 할인율을 구매처에 따라 다르게 적용하기도 한다. 모든 요소를 고려하여 구매해야 한다.

'Acquire Only What is Needed (필요분만 구매하라)'

업체의 판매전략과 연관되는 부분인데 업체의 할인공세에 호응하여 개발자 숫자대로 소프트웨어를 구매하였을 경우, "개발자가 동시에 모두 체크인을 하는 경우가 발생할 수 있겠는가?"를 생각해 보아야 한다. 1주일에 2번 일부 PC를 이용하여 체크인하는 경우 구매분량은 매우 적게 결정된다. 따라서, 작업방식의 결정만으르ㅗ 필요분량이 다르게 결정되는 것이다.

'Create a Champlion (툴을 숙지하자)'

툴을 잘 사용하는 사용자는 툴의 특성을 잘 파악하여 최대 효과를 거두기도 하지만 때로는 새로운 요구사항을 툴에 도입하도록 만듭니다. 예를 들면, F22 생산 시, PCMS가 흩어져 있는 사이트에 저장된 자료의 형상관리를 해야 하는 경우가 발생하였고, 이것은 PCMS의 다음 버전에서 지원하게 되었다.

'Be Constructive Not Destructive (개선점을 찾자)'

평가자는 툴이 사용중단될 때까지 지속적으로 툴을 평가하여 기능 중 무엇을 사용하고 있고 무엇을 하지 않고 있는지 파악한다. 이를 통해 문제가 무엇이고 어떻게 해결해야 하는지 알게 된다면 이를 제작자에게 피드백하여 전체적으로 툴의 성능향상에 기여할 수있다. 기존의 상용툴들은 이러한 과정을 거쳐서 개선된 경우가 많다. 제작사의 개선지원여부도 툴 선정의 주요요소가 될 수 있다.

10. 결론

모든 현실이 예측할 수 없게 바뀌듯이 고객의 요구사항은 끊임없이 바뀌고, 분석/설계자는 기술발전으로 시스템의 구조를 바꾸며, 개발자는 코드를 바꾸고 PM은 개발방법론을 변경하게 된다. 모든 변경에는 그에 따른 비용이 발생하며, 이것은 프로젝트의 중요요소가 된다. 따라서 소프트웨어의 변경관리는 프로젝트의 핵심활동 중의 하나이며, 이러한 활동을 지원하는 도구의 사용은 필연적인 것이 되어 가고 있다. 적절한 툴을 선정하여 프로젝트를 성공적으로 수행해야 하겠다.

출처 : http://gmood.tistory.com/tag/형상관리

형상관리란 무엇인가? 소프트웨어 형상관리(SCM)은 무엇인가?

JAESOO — Mon, 31 Aug 2015 09:49:32 +0000

형상관리만큼 한국에서 잘못 이해되는 개념도 없으며, 외국에서도 형상관리의 정의는 다양하고 복잡한 개념으로 알려지고 있다. 그리고 개념적으로 간단한 것인데 우리에게 아주 어렵게 소개되는 개념이기도 하다. 항상 정의는 어렵고, 이것을 소화하려면 정말 많은 노력과 지식과 경험이 필요하다. 이제 좀 더 우리의 일상에서 형상관리를 생각해 보려고 한다. 일반적인 형상관리의 정의는 시스템 형상 요소의 기능적 특성이나 물리적 특성을 문서화하고 그들 특성의 변경을 관리하며, 변경의 과정이나 실현 상황을 기록·보고하여 지정된 요건이 충족되었다는 사실을 검증하는 기능이나 과정이다.

체계공학(systems Engineering)에서 보면 형상관리는 사양(Specification), ICD (Interface Control Document), 도면, 설계변경 같은 변경관리, 그리고 납품 후 형상관리 등을 통한 제품과 프로세스의 식별하는 기능이다. 초기는 단순하였지만 점점 진화하면서 개념이 너무 다양해지고 있지만 처음시작은 1960대 방위산업 관련 사업관리의 한 방법으로 시작하였다. 초기의 형상관리는 처음 시 제작으로 만든 무기체계(Weapon System)가 두 번째 만들 때와 다르기 때문에 이것을 극복하기 위해서 사용하는 통합관리방법론이었다. 예를 들어서 첫 번째 시스템을 수 년 정도 개발을 하여서 완성하여서 두 번째 시스템을 만들려고 하니 처음에 시작하였던 계약자, 사업관리자, 엔지니어, 관리자, 고객 등 이해당사자(Stakeholder)들 모두 다른 일을 하거나, 은퇴하거나, 기억이 나지 않는 것이다. 그래서 두 번째 작품(시스템)이 보관하고 있는 도면, 문서 등 기록물을 가지고 만들 수 가 없었다. 그래서 형상관리라는 통합관리방법론이 탄생되었다.

누구인지는 모르지만 동양인 아마 일본인이 형상관리로 해석을 하였다. 그러나 오역인지 절묘한 해석인지는 모르지만 Configuration이라는 말을 형상(形狀)이라는 말로 번역을 하였다. 형상관리에서 형상의 의미는 물건(物件)의 생김새나 상태(狀態)라고 할 수 있다. 이것을 현대적으로 표현한다면 제품(Product)이나 시스템(System)의 물리적 실체에 대한 특성이나 구성 상태를 관리하며 그것들이 변경되었을 때 누가, 언제, 왜 변경되었는가를 수명주기 동안 기록하고 관리하고 추적하고 감리하는 것이다.

그러나 영어의 의미에서 Configuration이라는 의미는 arrangement of a group of thing이라고 말할 수 있다. Arrangement의 의미는 정돈, 정리, 배합, 조정, 합의 등의 의미를 가진다.

형상관리를 간단하게 말하면 조율을 통한 통합관리방법론이다. 대상은 시스템일 수 도 있고 제품이나 프로젝트라고 말할 수 도 제품과 소프트웨어의 결합일 수 도 있다. 다시 말해서 시스템 통합관리방법론이며 다양한 제품의 하드웨어, 소프트웨어 등 모든 제품을 통합적으로 관리하는 방법론이다.조금 철학적으로 말한다면 제품을 개발하거나 사업을 할 때 추상적인 관리대상을 형상화하여서 관리하는 것을 형상관리라고 할 수 있다. 그러면 어떤 것이 추상적이라고 말할 수 있냐 하면 기능, 성능, 제약조건, 제품의 사양 등은 추상적이다. 여기에서 추상적이라는 것은 글로 표현할 수 있는 것이지 실제적으로 보이는 것이 아니라는 것이다. 이것들은 물리적으로 실체인 제품의 특징을 나타내는 추상적인 항목이며, 이것을 형상으로 표현하는 것이 문서(Document)라고 할 수 있다. 여기서도 문서는 우리가 일차적으로 생각하는 종이문서(Paper)가 아닌 기록물이라는 추상적 지식물 또는 콘텐트를 의미한다.

예를 들어서 인생의 활동은 추상적인 활동들의 연속이다. 이것을 형상화 한 것이 출생신고 그리고 혼인 신고, 사망신고 등으로 우리들의 호적에서 변경 내용이 문서화 또는 기록화 되는 것과 유사하다.하드웨어 시스템을 개발할 때 구체적인 예로써 원자력발전소를 건설하는 사업(Program)에서 다양한 이해당사자(Stakeholder)와 소통을 하면서 통합적으로 관리하기 위해서는 설계요건, 물리적 실체(발전소), 시설 등의 정보를 문서화하여서 일관성을 수립하여서 관리하여야 한다. 또한 이러한 일관성을 전 수명기간 동안 유지해야 한다. 요구사항과 물리적 실체 그리고 시설 형상정보가 일치하여야 한다.

일치에 대한 요소 또는 관리 대상을 형상요소(Configuration Item)이라고 한다. 말이 어렵지 관리항목을 말한다. 모두 관리할 수 는 없기 때문에 가장 중요한 대상이나 항목을 말한다. 발전소에서는 발전소 구조물, 계통, 기기, 사업자 요건, 규제요건, 설계요건, 기능특성, 운전변수, 문서, 도면, 소프트웨어 등 일 수 있다.

또한 형상관리에서 가장 중요한 개념 중에 하나는 베이스라인 또는 기준선이라는 것이다. 원자력발전소는 물론 대부분의 공장의 생선시설 등의 각 단계의 베이스라인이 있다. 예를 들어서 제품의 수명주기에서 보면 개념설계, 기본설계, 상세설계, 생산 또는 건설, 운용/유지/보수 그리고 폐기를 단계를 가지는데, 각 단계별 베이스라인 또는 기준선을 가진다. 개념설계 다음은 기능기준선(functional baseline) 기본설계다음에는 할당기준선(allocation baseline), 그리고 상세설계 다음에는 제품기준선(product baseline)그리고 완성한 다음에는 운전 또는 운용기준선(operational baseline)이라고 한다.

형상관리는 보통 제품(일반 응용 소프트웨어 제품과도 동일)의 전 수명주기를 통해서만 발생하고 긴 수명을 가진 제품은 납품 후에도 형상관리에 대한 추적을 해야 한다.

형상관리는 개발 형상관리과 생산 형상관리, 또한 비용 예측을 위한 관리적인 성격을 지니는 작은 의미로 쓰이기도 하지만 큰 범주로 생각을 해보면 제품의 수명주기간에 모든 단계별로 형상관리가 사용될 수 있다. 제조업에서의 형상관리는 제품이 변경되었다는 과정과 상황을 기록, 보고하여 어느 정도 목적에 도달했을 때 충족되었다는 사실을 검증하는 일련의 프로세스를 말한다. 프로세스 중간중간 주요한 이정표(Milestone)이 되는 시점에서는 산출 되는 각종정보 (기술문서, 도면, 제품구조, 자재/부품 마스터, 공정 및 작업정보)에 대한 이력을 관리함으로써 장기간 진행되는 업무정보를 체계적이고 효율적으로 관리할 수 있다.

형상관리와 혼동하여서 사용하는 개념에서는 버전관리, 변경관리 등이 있다. 형상관리 프로세스에는 이러한 리비전, 버전 그리고 설계변경을 포함하고 있다. 리비전이나 버전(Version)은 개정관리라고 할 수 있다. 버전은 문서나 도면, 소스코드 등 정보개체(Item)가 한번 check-out을 하면 PLM에서는 자동적으로 1, 2, 3 등으로 변경된다. 그리고 리비전(Revision)은 이러한 아이템이 베이스라인이나 동결된 후 다시 사용할 때 A, B, C 등으로 증가 된다. 산업에 따라서 Version을 Issue로 사용하는 데도 있지만 개념은 동일하다.

왓트(Watts)가 쓴 개발 문서관리 핸드북 (Engineering Documentation Control Handbook) 에서는 형상관리는 설계 엔지니어와 나머지세계를 연결하는 다리라고 정의하였다. 그리고 기업의 형상관리 성숙도를 5단계로 나누어서 제일 아래 단계를 E (Incapable/No process), D (Acceptable), C (Efficient), B (Best in Class), 그리고 최고의 단계를 A (World Class)라고 정의 하였다.

요즈음은 형상관리가 소프트웨어 분야에서 많이 사용되고 있다. 소프트웨어 형상관리(SCM: Software Configuration Management)라고 불리며, 소프트웨어 분야에서의 PDM이라고 할 수 있다. 소프트웨어 개발 프로젝트를 진행할 때 디지털 파일로 작성된 모든 작업의 결과와 변경사항을 추적하며, 지역적으로 떨어져 있는 여러 개발자들의 협업이 가능하게 하는 시스템이다.

소프트웨어 형상관리(SCM)는 SW개발 및 유지보수 과정에서 발생하는 소스코드, 문서, 인터페이스 등 각종 결과물에 대한 계획, 개발, 운용 등을 종합하여 시스템의 형상을 만들고, 이들 형상에 대한 변경을 체계적으로 관리, 제어하기 위한 활동이다.

또한 소프트웨어 시스템 개발할 때부터 유지보수에 대비하여 만들어져야 한다. 계발 당시에 이러한 점을 소홀히 하게 되는데 추후에 비용증가의 요인이 된다. 소프트웨어가 계속 사용되고 발전하기 위해서는 이러한 개념과 문서화가 필요하다. 소프트웨어 형상관리에서는 관리대상은 대략적으로 다음과 같다.

- 개발되는 소스코드

- 지원 소프트웨어

- CASE 형상요소

- 개발 관련 문서 (분석서, 설계서, 사용지침서)

- 소프트웨어 개발 폴더, 라이브러리

- 프로젝트 계획

- 시험계획/절차/자료

- 형상관리 계획/절차

- 문제점/개선보고서

- 형상관리보고서

그러면 누가 형상관리가 필요하며, 왜 필요한 것인가를 생각하여 보자. 과거에는 특별한 환경에서 형상관리가 적용되었다. 제품의 구조가 복잡하고 제품수명주기가 길고 다양한 분야에 엔지니어가 협업을 할 때에 반드시 형상관리가 적용되어야 실패의 확률을 줄일 수 있었다. 그러한 과정에서 유지보수, 사용기간에 예측하지 못한 항목에 대응하고 필요한 정보문서를 검색하여 완전과 관리에 대응할 수 있을 수 있었으나 현재에는 다양한 환경에서 형상관리를 적용하고 있다.

고사양의 제품이 요구되는 환경 (항공전자)

제품의 수명주기가 길고 고가인 경우 (항공기개발)

제품의 운용에서 극도의 안전을 요구하는 환경 (원자력발전소 시설)

제품을 개발하는 과정에 복잡한 계약관계와 이해당사자가 개입되어있는 환경 (항공방산)

제품이나 시스템의 개발 과정에 서로 다른 복합기술이 사용되는 환경 (철도시스템)

다품종 소량생산의 환경에 소프트웨어와 하드웨어의 결합이 필요한 환경 (메카트로닉스)

다수의 사람들이 한 제품을 동시에 작업하는 경우 (소프트웨어 개발)

제품의 사용 중 개선이나 개량이 지속적으로 일어나는 경우 (인프라, 무기체계)

혁신적인 신제품의 개발환경 (제품혁신)

현재에는 고객이나 개발당사자가 현단계의 산출물과 바로 이전이나 이후의 단계의 산출물의 일치성을 확인 및 인가(Validation)하고 사용자가 요구하는 제품을 개발하였는지 검증(Verification)를 하는 형상관리는 절대적인 역할을 한다.

나의 경험에 의하면 대부분의 개발자들이 형상관리 프로세스를 싫어한다. 심지어는 개발도 힘들어 죽겠는데, 이러한 일까지 해야 하냐고 항의도 한다. 그러나 형상관리는 개발자의 가장 중요한 업무 중에 하나이다. 그리고 형상관리 담당자들은 형상관리 개념과 지식이 약해서 현업사람들을 이끌어가지 못한다. 형상관리 담당자들은 적극적으로 의사결정에 개입을 하여야 한다.

형상관리에서 관리의 의미는 Management이다. 우리말에 관리로 사용하는 영어단어에는 Management, Administrative, Control라는 말이다. 관리의 가장 단순한 단계는 Control이다. 이것은 깊은 지식이 없이 주어진 조건에서 반응만 하면 되는 것이다. 그리고 Administrative는 약간의 업무지식과 결정된 관리능력이 필요하다. 그러나 Management는 깊은 업무지식과 패러다임을 알고 더 좋은 결정을 할 수 있는 창조적인 능력이 요구된다. 그러므로 형상관리자는 이러한 능력이 필요하며, 기업에서는 이러한 인재를 양성해야 성공할 수 있다.

그러나 형상관리 자료야 말로 그냥 형식적으로 하는 것이 아니라 시스템의 수명주기 동안 미래에 무슨 문제가 발생하더라도 해결할 수 있는 유일한 자산(Asset)이라고 할 수 있다.

계획 안은 중요하지 않다, 계획 진행이 중요하다. - 아이젠하워 장군

Plans are nothing, planning is everything ?General Dwight D. Eisenhower

출처 : http://blog.daum.net/hyongsikcho/5416368

H514G 모뎀 대신 사용가능한 허브 iptime H5005-IGMP

JAESOO — Fri, 28 Aug 2015 09:51:33 +0000

이번에 iptime사에서 새로 출시한 허브인데요. 기존 SK기가라이트 인터넷을쓰시는 분들은

이렇게 생긴 H514G라는 모뎀을 달아주셨을 겁니다. 하지만 이모뎀에는 제한이 쫌 있죠. 그래서 이번에iptime이 저 모뎀을 대신하여쓸수있는 기가라이트 지원 허브를 출시하였습니다. iptime측에서도 소프트웨어적으로 해결해볼려 했지만 기술적인 문제로 새로 출시하였다고 합니다.

바로 이 H5005-IGMP라는 허브인데요. 사진을보시다시피 기가라이트를 지원한다고 되어있습니다. 보통은 4-wire로 100mbps의 인터넷을 지원하죠. 하지만 SK에서 새롭게서비스하는 기가라이트는 4-wire로 500mbps를 지원하기때문에 기존 공유기들의 지원하지못하는 점을 가만하여 H514G라는 모뎀을 달아준것 입니다.

이번에 출시한 허브는 4-wire로 500mbps의 속도를 사용할수 있기에 기존 SK모뎀을 빼시고 이허브를 끼우셔도 500mbps의 속도를 사용하실 수 있습니다. 또한 SK의 모뎀보다 기능도 많고 무상as도 2년으로 늘어서 괜찮은 제품 이라고 생각됩니다.

출처 : http://24abcd.tistory.com/12

케이블 교체 공사없이 제공되는 기가급 (300~500Mbps) 인터넷 서비스란?

JAESOO — Fri, 28 Aug 2015 09:47:53 +0000

올해 들어 아파트내 구내 배선 시스템에 변경없이 인터넷 속도를 100 Mbps에서 300~500 Mbps로 순식간에 올려주는 기술들이 국내에서 개발되어 연내 상용화한다는 이야기들이 많이 나오고 있습니다. 우리나라는 거의 10년에 가깝게 100 Mbps에 묶여 있었는 데, 오랜만에 들리는 낭보네요. 이 글에서는 이 서비스들이 무엇이고 어떤 구내 배선시스템 환경에서 적용되는 지 알아보도록 하겠습니다.

먼저 배경을 생각해 보지요.

현재 국내 통신 3사는 스타벅스같은 Hot-Spot에서 기가 와이파이 서비스(801.11ac)를 제공하고 있으며, 실제로 측정해보면 250~400 Mbps 정도의 속도가 나옵니다. 이를 위해 통신사들은 AP가 접속하는 유선 액세스망을 1Gbps로 증설했고요. 하지만 일반 가정은 유선 최고 속도가 100 Mbps이기 때문에 기가 와이파이 서비스가 제공되고 있지 않고 있습니다. 댁내 기가 와이파이 서비스를 제공하기 위해서는 유선 액세스 속도가 수백 Mbps는 나와야 하겠지요.

KT와 SKB가 올해 9월부터 개시하는 4K UHD IPTV 서비스도 품질에 걱정이 제기되고 있습니다. 인터넷 품질 측정 사이트인 벤치비에 따르면, 최대 속도가 100Mbps인 VDSL2의 경우 실제 평균 속도는 40~70 Mbps 정도 (KT)이며, 역시 최대 속도가 100 Mbps인 광랜과 FTTH의 경우도 40~80 Mbps (KT, SK Broadband, LG U+ 모두)입니다. 4K UHD 서비스가 15~30 Mbps의 대역폭을 필요로 하므로 한 집에 TV가 보통 복수대 있는 가정은 안정적인 품질 보장에 문제가 있을 수 있겠지요.

이러한 배경에서 우리나라의 통신 3사들은 아파트 거주 세대를 대상으로 기존의 전화선 기반 (VDSL2)과 UTP 기반 (Cat5/Cat5e)의 100 Mbps 인터넷 서비스의 속도를 300~500 Mbps로 향상시키는 작업을 진행하고 있습니다.

3사의 전략의 공통점은 기존 아파트에 설치된 케이블 선로의 교체 없이 새로운 액세스 기술을 사용하여 인터넷 속도를 3~5배로 빠르게 해준다는 것입니다 (KT 관계자분에 의하면, "건물내 케이블은 모두 건물주의 소유물이고, 주민들의 협상-동의를 걸쳐서 돈을 내고 깔아야 하는 매우 힘든 작업입니다. GiGA Wire 기술은 그러한 절차 없이 신속한 속도 업그레이드가 가능하다는 점이 장점입니다" 라고 하시네요).

♦ 먼저 KT의 GiGa Wire에 관해 알아보겠습니다.

그림 1. KT의 GiGA Wire 서비스 구성도 (제공: KT)

KT는 기존 전화선 (1 pair)상으로 300 Mbps이상의 다운로드 속도를 제공해주는 GiGA Wire 서비스를 준비하고 있습니다. 그러니까, 20~30년전에 지은 - 전화선만 각 세대에 인입되어 있는 - 오래된 아파트에 거주하고 있는 세대도 초초고속 인터넷 서비스를 누릴 수 있게 해준다는 것이지요.

GiGA Wire는 ITU-T G.hn 표준 (Line modulation: OFDM/DMT, Duplexing: TDD) 기반으로 KT의 특허 기술이 가미된 기술로 Marvell사가 칩을 개발하고 국내 ubiQuoss가 시스템 (GAM: G.hn Access Multiplexer ~ xDSL로 보면 DSLAM에 해당, GNT: G.hn Network Terminal ~ xDSL로 보면 모뎀에 해당)을 개발했습니다. 아래 Marvell사의 G.hn 성능 그래프를 보면 100m에서 대략 500 Mbps정도 나오네요.

KT는 Crosstalk, 노후화된 구내 배선망 등으로 인한 실환경에서의 속도 저하를 고려해 300 Mbps 정도로 서비스 컨셉을 잡은 것 같습니다. KT는 GiGA Wire 서비스를 올해 하반기에 출시할 예정이라고 합니다 (요금제를 어떻게 할 지 궁금하네요).

그림 2. 유비쿼스의 G.hn 장비와 거리에 따른 성능 (Source: Marvell and ubiQuoss)

♦ SK Broadband와 LG U+는?

SKB와 LG U+의 타켓은 KT와 좀 다른데요, 전화선 번들만 설치되어 있는 예전에 만들어진 아파트말고 그 이후에 만들어 졌거나 자신들이 돈을 들어 추가로 UTP 케이블링을 해놓은 아파트들이 대상입니다. 즉, CAT5 케이블이 설치되어 있는 아파트들입니다. 500만 세대가 넘는다고 하네요. 물론 Cat5e 케이블이 배선되어 있는 아파트도 적용할 수 있습니다.

1Gbps은 4-pair (Cat5e)가 필요하고 100 Mbps는 2-pair (Cat5)가 필요합니다. 우리가 흔히 광랜이라고 하는 서비스는 아파트 각 세대에 4-pair가 인입되고 이중에 1-pair는 전화 (POTS폰), 2-pair가 인터넷 (100Mbps)용으로 사용됩니다. 1Gbps를 쓰려면 4-pair를 다 사용해야 하고 케이블도 Cat5e이어야 해서 추가 케이블링이 요구됩니다.

SK Broadband와 LG U+는 추가 배선 공사없이 100 Mbps 이상의 인터넷 속도를 제공해주기 위해 기존처럼 Cat5 케이블 2-pair만을 이용해 500 Mbps의 속도를 제공해주는 기술을 개발한 것입니다 (100m거리에서 상하향 대칭형 500Mbps). 물론 표준은 아닙니다. SKB는 HFR이 장비를 개발했고 LG U+는 다산과 유비쿼스가 개발했습니다.

그림 3. 유선 액세스망의 혁신 - 2-pair로도 500 Mbps 속도 제공

KT는 전화선만 배선되어 있는 아파트들까지 기가급으로, SK Telecom과 LG U+는 UTP 배선이 되어 있는 아파트들만 대상으로 한다는 것은 다릅니다. 역시 유선은 KT가 큰 형님이네요.

거의 10년에 가깝도록 정체되어 있던 우리나라 초고속 인터넷이 조만간 기가급으로 진보하는 것이 확실해 보입니다. 물론 궁극적으로는 모든 집마다 광케이블을 인입해주는 FTTH으로 가겠지만 배선공사가 어려운 오래된 아파트들을 대상으로 배선 공사없이 수백Mbps의 속도를 제공하려는 우리 나라 통신 3사가 참 대단합니다.

출처 : http://osmanias.com/bbs/board.php?bo_table=newest&wr_id=2645

Synology NAS – 데이터 스크럽 알림

JAESOO — Wed, 26 Aug 2015 10:17:19 +0000

잘 사용해오던 시놀로지 나스에서 갑자기 발생한 “데이터 스트럼” 알람에 대해 파악한 결과를 남겨봅니다.

알람 내용

시놀로지 나스 로그인 하니 뜬 알람!!!

몇년동안 시놀로지 나스를 쭉 사용해오던 중 이런 알람은 처음 받아보는 종류 였습니다.- _-;;
시스템 알람은 뜨지 않는걸 보니 큰 문제가 아닌거 같아 당황하지 않고 시놀로지 카페를 살펴보았으나, 어떤 내용인지 어떻게 대처해야 되는지에 대해서는 자세히 나온게 없더군요.

그래서 바로 네이버에서도 검색해 보았으나 수확은 없고, 역시 진리의 구글링을 통해 원하는 결과를 얻을 수 있었습니다.
( 원하는 답변은 사용자 가이드에 있었다는!!! )

알람 내용!

시놀로지 나스 사용자 매뉴얼에서 발취

결과적으로 시놀로지 나스에서 발생한 ‘데이터 스크럼’ 알람은 레이드를 사용 시 각 하드에 저장되는 패리티 데이터에 문제가 없는지 일관성 검사를 해달라는 알람이였습니다.

한줄 요약 : 데이터 스크럼 알림 = 하드에 저장된 데이터 문제 확인 요청 알람

데이터 스크럼 진행 방법

아참! 수동으로 데이터 스크럼을 진행을 원할 시에는 ‘시작 버튼 → 저장소 관리자 → 불륨 탭 선택 → 원하는 볼륨 선택 → 관리’ 순으로 누르시면 진행 하실 수 있습니다.

해당 작업은 백그라운드에서 계속 진행되어 사용에 문제는 없으나, 성능에 영향을 미치며 작업이 용량에 대비해 변화하나 매우~~~ 오래 걸립니다.ㅋㅋ

참고 링크
– Synology NAS 사용자 매뉴얼 (4.2기준) : https://www.google.co.kr/url…
– 클리앙 “사무실 NAS 로 Drobo 5n 소감” 글 중 댓글 : http://www.clien.net/cs2/bbs/…

출처 : http://syanoe.com/computer/nas-pc-server/5990.htm

성능 엔지니어링 대한 접근 방법 (Performance tuning)

JAESOO — Mon, 24 Aug 2015 11:43:16 +0000

성능 엔지니어링에 대한 접근 방법

조대협

성능 개선, Performance Tuning, 용량 선정 과 같은 튜닝 관련 용어들은 모든 개발자나 엔지니어에게 모두 흥미가 가는 주제일 것이다. 그 만큼 소프트웨어에서 고성능을 내는 시스템은 만들기도 힘들뿐더러, 고성능 시스템이란 즉 잘 설계되고 구현된 소프트웨어를 뜻하는 것이니 관심을 가지는 것이 당연하지 않을까 싶다.

필자의 경우, 엔터프라이즈 시스템에 대한 약 6년간 장애 해결, 장애 회피 설계, 성능 개선, 고성능 시스템 설계 및 구현에 관련된 일을 해왔다. 특히 장애 해결과 성능 개선 작업은 하고 나면 뿌듯하기는 하지만, 특정한 기술이 필요하기 보다는 문제를 정의하고 접근하는 능력과 끝까지 목표를 달성할 때까지 지루한 작업을 반복적으로 할 수 있는 인내심을 필요로 하는 작업이다

이번 챕터에서는 Performance Engineering의 전반적인 접근 방법과, 용량 산정 방법 그리고 자바 기반의 서버 애플리케이션에 대한 성능 튜닝 및 병목 발견 방법에 대해서 설명하고자 한다.

Performance Engineering 의 정의와 범위

Performance Engineering은 시스템의 목표 성능 (응답 시간과 동시 접속자수)을 정의 하고, 이를 달성하기 위해서, 시스템의 구조를 반복적으로 개선하는 작업을 이야기 한다.

좁게 생각하면, 코드상의 병목을 잡고, 시스템의 설정(Configuration)을 바꿔서 성능을 올리는 튜닝으로 생각할 수 있지만, 성능 목표의 정의에서 부터, 최적의 성능을 내기 위한 디자인 및 구현과 같은 개발 초기의 설계 부분와 개발후의 운영단계에서 모니터링 까지 전과정을 포함한다.

Performance Engineering은 언제 해야 하는가?

Performance Engineering은 전체 소프트웨어 개발 과정에 걸쳐서 크게 아래와 같이 4단계에 걸쳐서 일어난다.

위의 개발 모델은 전형적인 Water fall model이다. 개발프로세스 챕터에서도 설명하였지만, 스크럼과 같은 애자일 방법론을 사용하더라도 큰 범위에서 개발 사이클은 Waterfall 모델과 크게 다르지 않게 된다. (각 단계별을 SPRINT 단위로 수행한다.)

분석 단계

초기 요구 사항 분석 및 시스템 기획 단계에서는 성능에 대한 목표를 정해야 한다.

목표 응답시간은 어떻게 되는지, 시스템을 사용할 총 사용자수와 동시에 시스템을 사용하는 동시접속자 수가 어떻게 되는지와 같은 성능 목표를 정의한다.

또한 고려해야 하는 사항중의 하나는 성능 모델이다. 시스템에 부하가 어떤 패턴으로 들어오는지를 정의할 필요가 있다.

예를 들어 일반적인 웹컨텐츠 사이트의 경우 사용자가 들어와서 페이지 컨텐츠를 1~3분 내에 읽고 다른 페이지로 이동하다가, 20 여분 후에는 로그아웃하거나 다른 사이트로 이동한다. 즉 한 사용자의 체류 시간은 20분정도되며, 총 평균 20 페이지를 보는 트렌젝션을 발생 시키고 나간다고 할 수 있다. 한글로 만든 사이트이고, 육아나 주부를 대상으로 한 사이트라고 가정하면, 시스템의 부하는 한국 시간으로 아이들이 학교나 유치원을 간후인 10시~11시와, 저녁시간대인 10시~12시 사이에 몰린다고 가정할 수 있다.

다른 예로 게임 시스템을 예로 들어보자, 주로 초등학생을 타켓으로 한 게임이라면, 방과후 시간인 3시~5시 대에 부하가 가장 몰릴 것이며, 게임의 종류에 따라 다르겠지만, 스타크래프트와 같은 게임의 경우 한번 플레이에 40분 정도 소요가 되고, 한 사용자가 하루에 두번정도 게임을 한다 가정 아래, 사용자당 체류 시간은 2시간, 게임 횟수는 2회/일. 그리고 주요 부하는 3~5시 오후대 라는 성능 모델을 만들 수 있다.

초기 성능 정의는 서비스의 종류(웹,게임,기업 시스템,쇼핑,뱅킹등) 나, 서비스를 사용하는 사용자층, 그리고 서비스를 사용하는 지역. 즉 전세계를 서비스하는 시스템이라면 시스템의 부하는 365일,24시간 거의 다 걸린다고 봐야 한다. 그러나 한국만을 대상으로 서비스 하는 한국어로 된 사이트인 경우, 새벽 시간에는 일반적으로 로드가 없는 것과 같은 한국의 시간대에 영향을 받을 뿐만 아리나 명절,휴일,휴가와 같은 한국이라는 국가 특성에 따라 시스템의 부하가 영향을 받는다.

디자인 단계

다음으로는 디자인 단계에서는 목표 성능과 용량을 달성할 수 있는 규모의 시스템으로 설계를 진행한다.

성능 관점에서 시스템 디자인은 항상 Peak Time (최대 성능)에 맞춰서 디자인이 된다. 최대 성능을 기반으로 전체 시스템이 받아낼 수 있는 용량과 응답 시간을 고려해야 한다.

특히 성능과 용량은 애플리케이션 디자인 뿐만 아니라 Technology selection에도 많은 영향을 받는다. 어떤 하드웨어를 사용할 것인지, 어떤 미들웨어나 프레임웍을 사용할 것인지이에 따라 용량과 성능의 차이가 많이 발생하기 때문에, 디자인 단계에서 부터 성능과 용량을 감안해서 시스템을 설계해야 한다.

하드웨어 관점에서는 예전에는 성능 모델을 산정한 후에, Peak Time 기준 (최대 성능 요구)으로 시스템을 설계하고, 하드웨어를 구매 하였으나, 근래에는 클라우드를 이용하여 필요시에만 하드웨어를 탄력적으로 사용하는 Auto Scale Out 모델을 많이 사용한다.

기업 내부의 업무 처럼 (예를 들어 이메일), 부하가 일정하고 예측이 가능한 경우에는 Fixed 된 사이즈의 하드웨어를 사용하도록 설계 하고, 출시 이벤트 행사 사이트와 같이 부하가 갑자기 몰리는 시스템의 경우 클라우드를 고려해보는 것도 권장할만 하다.

또한 빠른 응답 시간이 필요할 경우 SSD 디스크를 사용하거나, RAID 구성도 5보다는 1+0 등을 고려하는 등, 성능 모델에 따라서 적절한 하드웨어 선정과 구성 설계가 필요하다.

나 프레임웍 관점에서도 정의된 성능 모델에 따라 적절한 제품군과 설계 구조를 채택해야 한다. 100,000 사용자 정도의 시스템 규모에서는 RDBMS 를 사용해도 성능이나 용량상에 문제가 없다. 그러나 50,000,000 사용자 정도를 지원해야 하는 시스템의 경우 그냥 RDBMS 를 사용할 수 없다. Sharding이나, NoSQL과 같은 다른 차원의 접근이 필요하다.

또한 빠른 응답 시간을 요구하는 경우 Redis나 Memcached와 같은 Cache 솔루션을 적극적으로 활용하거나, 미들웨어 부분에서는 Tomcat과 같은 일반적은 Web Application Server 보다는 Netty나 Vertex와 같은 고성능 미들웨어를 고려해볼 수 있다.

이러한 성능이나 용량에 관련된 제품 선정이나 설계는 돌려 보지 않으면 사실 확신을 가지기 어렵다. 그래서 가능하면, Technology selection 후에, 간단한 프로토타입을 구현한후에 시나리오가 단순한 대규모의 성능 및 용량 테스트를 해보는 PoC (Proof Of Concept)과 같은 작업을 이 단계에서 수행하는 것을 권장한다.

개발단계

개발 단계는 개발프로세스 챕터에서 설명하였듯이, risk 가 높은 부분과 아키텍쳐에 관련되는 부분, 난이도가 높은 부분, 핵심 기능등을 개발 초기의 스프린트에서 개발한다.

초기 스프린트가 끝나고 릴리즈가 되서 성능 테스트가 가능한 QA나 스테이징 환경으로 시스템이 이전되면, Performance Engineering 역량을 이 단계에 집중하여, 시스템의 아키텍쳐와 모듈들이 성능 목표를 달성할 수 있는지 지속적으로 테스트하고 튜닝을 수행한다.

초기 단계에 성능 목표의 달성 가능 여부가 판단되어야, 아키텍쳐 변경이 가능하고, 주요 성능 이슈들을 초반에 발견해야, 발견된 성능 문제들에 대해서는 같은 문제가 발생하지 않도록 디자인 가이드나 코딩 가이드를 개발자들에게 배포하여 성능에 대한 위험도를 줄일 수 있다.

최종 테스트 단계

앞의 단계에서 성능과 용량을 고려해서 설계가 되었고, 개발 초기 단계에서 성능과 용량 부분을 검증을 제대로 하였다면, 최종 테스트 단계에서는 개발된 최종 시스템에 대한 성능과 용량 부분의 측정과 미세 튜닝 (애플리케이션의 병목을 찾아서 부분적으로 수정하거나, 하드웨어나 미들웨어의 Configuration 하는 수준)을 하는 정도로 마무리가 되어야 한다.

이 과정에서는 실수로 잘못한 설정(configuration) 이나 잘못된 코딩으로 된 부분에 대해서 검증이 이뤄지는데, 이 경우에는 보통 2배에서 크게는 10배까지의 성능 향상이 이루어진다. 이런 경우는 대부분 실수에 의한 것이고 성능이 터무니 없이 낮게 나오기 때문에 찾기가 쉽다.

예를 들어 로그 파일을 NFS와 같은 리모트 디스크에 쓴다던지, Intel 계열의 CPU에서 하이퍼쓰레딩을 ON을 안했다던지와 같이 실수에 의한 경우가 많다.

이런 오류성의 문제들이 해결되면 실제 미세 튜닝에 들어가게 되는데, JVM 튜닝이나 톰캣의 설정 튜닝, SQL 튜닝들이 이루어지는데, 이 미세 튜닝을 통해서는 비약적인 성능향상은 이루어나지 않는다. 보통 20% 내외 정도 성능이 올라간다고 보면 된다.

운영 단계

마지막으로 시스템이 운영 단계로 넘어가게 되면, 테스트시에 발견되지 않은 성능적인 문제가 있을 수 있기 때문에, 모니터링 도구를 사용하여 지속적으로 성능을 모니터링 하고, 성능상에 문제가 있는 부분을 지속적으로 수정해야 한다. 웹서버의 access로그에서 응답 시간을 모니터링 하거나, 제니퍼(http://www.jennifersoft.com)과 같은 전문적인 APM (Application Performance Monitoring)툴이나, Ganglia와 같은 시스템 모니터링 도구를 사용하면, 시스템의 성능 상태를 잘 알 수 있다.

더불어 용량 부분에 대해서도 운영단에서는 고민을 해야 하는데, 일반적으로 PEAK Time의 시스템 용량이 (CPU) 80% 정도에 다다르면, 시스템 용량 증설을 고려해야 한다.

그리고 업무에 특성에 맞게 미리미리 용량을 준비해놓는게 좋다. 예를 들어 대학의 수강 신청 시스템의 경우, 학기 시작하는 날에 부하가 폭주하기 때문에, 클라우드 기반일 경우 수강신청 전에 시스템 수를 미리 늘려놓는다던지, 클라우드가 아닌 경우, 수강 신청 기간을 앞뒤로 서버를 임대해서 용량을 늘려놓는 등의 대책을 미리 세워놓을 수 있다.

, 운영 단계에서 Performance Engineering 관점으로 챙겨야 하는 부분은 운영 로그의 수집이다. 성능 및 용량 목표 설정은 매우 중요한 과정이다. 특히 용량 목표의 경우에는 기존의 업무 시스템의 사용 패턴을 분석 하는 것이 가장 효율적이기 때문에 운영 시스템의 로그를 수집하고 분석하여 운영 중인 업무 시스템의 성능 모델을 분석 및 보유 해놓는 것이 좋다.

시스템 용량 산정 (Capacity Planning)

더 자세한 설명에 들어가기 앞서서, 성능에 관련된 용어와 함께 시스템의 목표 용량 산정 방법에 대해서 이야기 해보도록 하자.이 용어는 이 글에서 정의하는 의미의 용어이며, 다른 성능 이론에서 언급되는 용어와 다소 다를 수 있다.

Response Time (응답 시간) : 사용자가 서버에 요청을 한 시간에서 부터, 응답을 받을 때 까지의 모든 시간을 포함한다. 이 응답시간은 내부적으로 다음과 같이 조금 더 세분하게 분리된다.

Network Time (또는 Latency time). 서버에 요청을 했을때, Request를 보내고 받을 때 소요되는 네트워크 시간을 의미한다.

Transaction Time : 서버에서 실제 트렉젝션이 처리되는 시간을 의미 한다.

Think Time : 사용자가 요청에 대해서 응답을 받은 후에, 웹페이지를 보거나 화면을 보는 등의 작업을 하는 시간의 의미한다.

예를 들어 보면 한국의 사용자가 미국이 페이스북을 사용한다고 했을때, 사용자가 웹 브라우져에서 클릭을 하면, 요청이 서버로 도달할때 까지 걸리는 시간 Network time (Request), 서버가 요청을 받아서 처리를 하고, 응답을 하는 시간 (Transaction Time), 그리고 그 응답이 사용자의 브라우져 까지 도착하는 시간이 Network time (Response) 이다. 이 전체 시간을 합친 것이 Response Time이 된다.

응답을 받은 후에는 사용자가 페이스북 내용을 보는데 소요 되는 시간이 Think Time이 된다.

Think Time 까지 포함하여 다음 요청이 발생하기 까지의 전체 시간을 Request Interval 이라고 한다.

Concurrent User (동시 사용자) : 시스템을 현재 사용하고 있는 사용자를 정의한다. 웹사이트를 사용하기 위해서, 현재 브라우져를 열어놓고 웹사이트를 보고 있는 것과 같이 현재 시스템을 사용하고 있는 사용자 수를 의미 한다.

위의 그림을 보자, 5명의 사용자 A~E가 있다고 가정했을 때, 단위 시간 10분동안에 Transaction Time과 Think Time중에 있는 사용자는 A,B,C 총 3명으로 해다 시간 10분간의 Concurrent User는 3명이 된다.

Active User (액티브 사용자) : 현재 시스템에 트렌젝션을 실행하여 부하를 주고 있는 사용자를 정의한다.

기존에는 Concurrent User와 Active User간의 차이가 없었다. 이 개념은 웹이 생기면서 구체화된 개념인데, 웹 사이트를 사용하기 위해서 컴퓨터 앞에 앉아 있는다고 하더라도, 웹 페이지가 로딩 되는 순간에만 서버는 부하를 받고, 페이지가 웹 브라우져로딩 된 후에는 부하를 받지 않고 사용자는 로딩된 페이지를 보는데 시간이 발생한다. 이 시간동안에는 서버는 부하를 받지 않는다. 즉 시스템을 사용하기 위해서 웹 사이트를 열어 놓고 있는다 하더라도 지속적으로 서버에 부하를 주는 것이 아니기 때문에 Concurrent User와 Active User 의 개념 차이가 발생한다.

Active User는 클릭을 발생시켜서 그 시간 당시에 서버에 트렌젝션을 발생 시키는 사용자를 의미한다.

Active User의 수는 서버에서 순간 실행되고 있는 Thread 수 (쓰레딩 기반의 자바 서버의 경우) 나 Process의 수와 같다. 이 Active User의 수는 실제로 서버가 동시에 처리할 수 있는 트렌젝션의 양을 판단할 수 있는 기준이 되기 때문에 매우 중요한 성능 Factor가 된다.

위의 그림을 보자, 위의 그림에서 특정 순간에 있는 사용자는 총 5 명으로 Concurrent User 는 5명이지만, Transaction Time 구간중의 있는 사용자는 A,B,C 로, 총 Active User는 3명이 된다.

Transaction (트렌젝션) : Transaction이란, 사용자로 부터의 요청을 다루는 단위를 정의 한다. 이 정의가 상당히 중요한데, 성능 모델링이나 성능 테스트 시 이 Transaction의 정의에 따라서 시스템의 성능이 매우 다르게 정의 된다.

예를 들어서 사용자가 웹 페이지를 클릭했을때, 그 페이지에 대한 응답을 받는 것 까지를 하나의 트렌젝션이라고 정의 하자.

이 때, 웹페이지에는 서버에서 생생된 HTML 이외에, 여기서 참고 하는 리소스 즉, 이미지나 동영상, 자바 스크립트들이 들어있을 수 있다. 이 경우 트렌젝션에 대한 응답 시간을 측정할때, HTML 생성 이외에 이러한 리소스들을 로딩 하는 것 까지 하나의 트렌젝션으로 정의 해야 하느냐를 고려해야 한다.리소스에 로딩을 트렌젝션의 범위로 넣게 되면 전체 시스템의 응답 시간은 떨어지게 된다. (리소스를 로딩할 때 까지 기다려야 하니).

이러한 트렌젝션의 정의는 무엇을 판단 기준으로 할것인가에 따라 결정이 되는데, 예를 들어 리소스를 톰캣과 같은 WAS에서 처리하지 않고 앞단의 CDN이나 웹서버에서 처리할 경우 톰캣은 리소스에 대한 트렌젝션 요청을 받지 않기 때문에, 전체 시스템에서 비지니스 로직에 대한 처리 성능을 측정하고자 할 때는 리소스에 대한 로딩 시간을 계산하지 않고 트렌젝션을 정의 한다. 또한 리소스에 대한 로딩은 비지니스 로직에 대한 처리에 비해서 부하가 상대적으로 매우 적고, 일반적으로 브라우져에 캐쉬되기 때문에 보통 서버의 성능 측정시 이러한 리소스 로딩에 대한 부하는 트렌젝션의 단위로 처리하지 않는 경우가 많다.

TPS(Transaction Per Second) : 초당 처리할 수 있는 트렌젝션의 양을 정의 한다. 주로 서버의 성능 평가 기준이 된다.

Active 사용자가 순간 Transaction을 처리한다고 하면, 이를 목표 응답시간 (Response Time)으로 나눈 값이 목표 TPS가 된다. 예를 들어, Active User가 50 명이고, 개당 Response Time이 2초 라고 하면, 이 시스템의 TPS는 25 TPS가 된다.
※ Network time이 미세하다고 판단하여, Network time을 0으로 가정하여 계산

HPS(Hit Per Second) : 시스템이 처리할 수 있는 모든 웹 request의 초당 처리량이다. TPS가 비지니스 트렌젝션에 대한 처리 시간만을 정의 한다면, HPS는 리소스 (이미지, 자바스크립트)에 대한 request 처리량을 포함하기 때문에, TPS에 비해서 10~20 배 정도 높게 나온다.
Peak Time(피크 타임) : 서버가 순간적으로 가장 부하를 많이 받는 순간을 정의 한다. 보통 서버의 용량 산정이나 성능 설계는 이 시간의 부하량을 기준으로 한다

일반적인 업무 시스템의 경우, 출근 9시~9시30분 사이가 가장 부하가 높다. 이 때 Peak (최고 정점)을 찍는 순간의 동시 사용자 수와 기준 응답 시간을 목표로 성능 목표를 정의 하는 것이 일반적이다.

위의 개념을 정리해서 공식화 해보자.

TPS = (Active User) / (Average Response Time) – F1
TPS = (Concurrent User) / (Request Interval) – F2
Active User = TPS * (Average Response Time) – F3
Active User = (Concurrent User) * (Average Response Time) / (Request Interval) – F4
Active User = (Concurrent User) * (Average Response Time) / [ (Average Response Time) + (Average Think Time) ] – F5

예를 들어 Concurrent User가 300명이고, 목표 응답시간이 3초 이내이며, Think Time이 15초 인 시스템의 경우, F5 공식에 따라서 Active User는 300*3/(3+15) = 50 이 되며, 시스템의 Thread 또는 적정 Process 양은 50개가 된다. 목표 TPS는 약 16.6 TPS가 된다.

위의 공식은 어디까지나 이론적인 공식이다. Network Latency 값은 가변적이며, Think Time 또한 유동적이다. 그러나 용량 산정에는 어느 정도의 산정 기준이 필요하기 때문에, 이 공식을 사용하면 대략적인 시스템에 대한 요구 용량을 예측할 수 있다.

Performance Engineering 의 절차

그러면 어떤 절차로 성능과 용량을 측정하고 개선하는 절차에 대해서 알아보도록 하자.

성능 목표와 모델의 정의

먼저 주요 업무 패턴이나, 튜닝의 대상이 되는 시나리오에 대한 개별 성능 목표를 정의 한다. 예를 들어 전체 성능 목표가 1,000 동시 사용자에 대해서 응답 시간 1초내의 시스템이 전체 성능 목표라고 가정하고, 전체 성능 목표를 대략 1,000 TPS (Transaction Per Second)라고 하자. 이것이 바로 성능 목표가 된다.

다음으로 성능 모델을 정의 해야 하는데, 해당 시스템의 주요 사용자 시나리오가 여러개 있을 때, 각 시나리오별의 사용 비중을 정의 해야 한다.

예를 들어 사진을 저장하는 클라우드 서비스 시나리오가 있다고 하면, 이 서비스의 주요 사용자 시나리오는

로그인
사진 리스트
사진 업로드
사진 보기
사진 다운로드
로드 아웃

등이 된다. 이 중에서 한 사용자가 실행하는 비율을 따져야 한다. 즉 사용자가 로그인 한후, 리스트 보기를 10번, 업로드를 2번, 보기를 5번, 그리고 다운로드를 1번 한후에 로그 아웃 한다고 하자. 그러면 비율은 다음과 같이 된다. (전체 트렌젝션 횟수 1+10+2+5+1+1 = 20회)

성능 모델 :로그인의 비율 5%, 리스트 보기 50%, 업로드 10%, 보기 25%, 로그아웃 5%

이 비율을 기준으로 복합 시나리오 (전체 시나리오를 함께 돌리는) 부하테스트를 수행하였을때, 1000 TPS가 나와야 하고, 각 개별 시나리오에 대해서 최소한, 로그인의 경우 1000 TPS의 5%인 50 TPS, 리스트 보기는 500 TPS를 상회 해야 한다.

부하 생성

성능 모델이 정의 되었으면, 이 모델에 따라서 부하를 생성해야 한다.

부하 생성 도구는 여러가지가 있다. 대표적인 오픈 소스 도구로는

가장 간단하게 쓸 수 있는 도구로는 Apache AB 라는 명령어 기반의 도구가 있으며, 복잡한 스크립트를 지원할 수 있는 도구로는 grinder나 apache JMeter 등이 있으며, NHN에서 grinder를 enhancement해서 만든 (GUI가 지원되는) nGrinder라는 도구가 있다.

근래에는 국내에서는 nGrinder라는 도구가 많이 사용되고 있다.

성능 모델이 단순하고, 테스트 시나리오가 간단할 경우에는 Apache ab 등으로도 가능하지만, 스크립트가 복잡해지는 경우에는 nGrinder와 같은 도구가 유리 하다.

또한 부하 생성에 사용되는 스크립트는 복잡도가 생각보다 높고, 향후 regression(회귀) 테스트에도 재 사용되기 때문에, 반드시 형상 관리 시스템을 통해서 (VCS) 관리 하는 것을 권장한다.

※ 자세한 부하 테스트에 대한 방법은 “4장 테스트의 시스템 테스트 “ 부분을 참고하기 바란다.

※ 클라우드 컴퓨팅과 부하 테스트 툴 라이센스 모델에 대해서

예전에는 부하 테스트가 사내에서 사내에 있는 시스템을 대상으로 했었기 때문에 큰 문제가 없었다. 그러나 근래 들어서 클라우드 컴퓨팅을 사용하는 사례가 늘어남에 따라, 서비스 시스템이 회사 밖에 즉, 클라우드에 있는 경우가 많아 졌다.

상용 부하 테스트툴의 경우에는 부하 발생기의 위치와 툴 사용자에 대해서 제약을 두는 경우가 있는데, 툴을 구매했다 하더라도, 부하 테스터의 controller (부하 발생기 제외)는 반드시 사내에 있어야 하며, 사용자 역시 그 회사의 내부 직원으로만 한정하는 경우가 있다.

예를 들어, 내가 부하 테스트 도구를 서울에 있는 회사에서 구매하여, 이 툴을 Amazon 클라우드 미국에 설치하고 부하 테스트를 미국 지사 직원을 통해서 진행하는 것이 불가능 하다.

이 경우 부하 테스트 툴의 Controller는 한국 서울 사무소에 설치하고, 부하 생성기만 Amazon에 설치한후 한국 서울 사무소 직원을 통해서만 사용해야 한다.

간혹 (이럴리는 없어야 하겠지만) 부하 테스트 툴의 판매 회사 영업 사원이 이러한 사실을 제대로 통보하지 않아서, 툴을 잘 쓰다가 갑자기 영업 사원이 변경되거나, 부하 테스트 툴의 이전을 요청 하였을때, 갑자기 벤더로 부터, 추가 라이센스 구매 요청을 받을 수 있으니, 구매 전에 반드시 구매 조건에 사용 시나리오와 Controller 위치, 사용 주체 및 테스트 대상 시스테들에 대해서 명시적으로 기재 하고 구매 계약을 추진 하는 것이 좋다.

테스트 및 모니터링

부하 테스트 준비가 되었으면, 부하 테스트를 진행하고 진행중에 주요 성능 Factor에 대해서 지속적으로 모니터링 및 기록을 하여야 한다. 주로 모니터링해야하는 Factor들은 다음과 같다.

애플리케이션 관점

가장 기본적으로 애플리케이션 즉 시스템의 성능을 측정 해야 한다. 주요 모니터링 Factor는 다음과 같다.

Response Time : Request 별 응답 시간

TPS (Throughput per second) : 초당 요청(Request) 처리량

Factor들이 궁극적으로 성능에 대한 최종 목표 값이 되기 때문에, 가장 중요한 성능 Factor가 되며, 부하 생성 도구를 통해서 손쉽게 측정할 수 있다.

미들웨어 관점

미들웨어는 애플리케이션이 동작하기 위한 기본적인 솔루션이다.. Apache와 같은 웹서버나 Tomcat과 같은 Web Application 서버 , RabbitMQ와 같은 Message Queue, MySQL과 같은 데이타 베이스 등이 이에 해당한다.

각 성능 시나리오별로, 거쳐 가는 모든 미들웨어들을 모니터링해야 하는데, 이를 위해서는 각 솔루션에 대한 개별적인 깊은 이해가 필요하다.

웹서버의 경우 거의 성능 문제가 되는 부분은 없다. 성능 문제가 발생하는 부분은 대부분 Network outbound io (bandwidth)쪽이 되는 경우가 많다. 웹서버가 설치된 하드웨어의 network out bound bandwidth를 모니터링 하는 것이 유용하다.

대부분의 성능 문제는 실제 애플리케이션 로직이 수행되는 Tomcat과 같은 application server와 데이타 베이스단에서 많이 발생하는데, application server의 경우에는 Thread의 수와 Queue의 길이가 1차 모니터링 대상이 된다.

서버가 용량을 초과 하게 되면, Idle Thread수가 떨어지게 되고, Idle Thread가 0이 되면 request message가 앞단의 queue에 저장되게 된다. 그래서 이 두 개를 모니터링 하면 시스템이 병목 상태인지 아닌지를 판단할 수 있다. 이 값들은 JMX (Java Management Extension) API를 이용하여 모니터링 하면 된다.

의 경우에는 slow query를 모니터링하면 특히 느리게 수행되는 쿼리들을 잡아서 튜닝할 수 있다. MySQL 5.6의 경우 slow query는 http://dev.mysql.com/doc/refman/5.6/en/slow-query-log.html

를 사용하면 쉽게 잡아낼 수 있다.

Slow query를 찾았으면, EXPLAIN 명령어를 이용하여 query의 수행 내용을 분석한후 Index등의 튜닝을 수행할 수 있다.

인프라 관점 : CPU, Memory, Network IO, Disk IO

다음으로 하드웨어 인프라에 대한 부분을 지속적으로 모니터링해줘야 하는데, 이는 하드웨어가 해당 성능을 내기 위해서 용량이 충분한지 그리고 하드웨어 구간에서 병목이 생기지는 않는지, 생긴다면 어느 구간에서 생기는지를 모니터링하여, 해당 병목 구간에 대한 문제 해결을 하기 위함이다.

인프라에 대한 모니터링은 Ganglia나 Cacti와 같은 전문화된 인프라 모니터링 도구를 사용하거나 top이나 glance, sar와 같은 기본적인 Unix/Linux 커맨드를 사용해서도 모니터링이 가능하다. (부하 테스트주에 top 등을 띄워놓고 모니터링을 하는 것이 좋다. Load Runner와 같은 상용 도구의 경우에는 부하 테스트 툴 자체에서 테스트 대상 시스템에 대한 하드웨어 사용률을 함께 모니터링할 수 있게 제공해준다.)

CPU : 일반적으로 CPU는 대부분 잘 모니터링 한다. 목표 성능을 달성할 시에는 보통 70~80% 정도의 CPU 를 사용하는 것이 좋고, 20~30%의 여유는 항상 가지고 가는 것이 좋다 이유는, 70~80% 정도의 CPU가 사용된 후에, 하드웨어를 물리적으로 늘리는 시간에 대한 여유 시간을 가지기 위함이다. 하드웨어는 특성상 주문을한다고 해도, 바로 그 시간에 증설을 할 수 있는 것이 아니고, CPU 가 100%가 되는 순간에는 이미 애플리케이션이 CPU 부족으로 제대로 작동을 하지 못하는 경우가 많기 때문에, 항상 여유를 남겨 놓고 성능 목표를 정의 하는 것이 좋다. 그래서 성능 목표를 잡을 때는 “CPU 70%시, 500 TPS, 응답시간 1.5초 내외” 식으로 하드웨어에 대한 사용률을 포함하는 것을 권장한다.

Memory : 다음으로는 Memory 부분이다. Peak Time시에 Memory가 얼마나 사용되느냐가 중요한데, Java Application의 경우 특성상, 전체 JVM 프로세스가 사용할 메모리량을 미리 정해놓기 때문에, 부하 테스트 중에도 메모리 사용량 자체는 크게 변화하지 않는다. 다만 자주 놓치는 점이 swapping status 인데, Unix/Linux는 시스템의 특성상 물리 메모리 이상의 메모리를 제공하기 위해서 virtual memory 라는 개념을 사용하고 swapping space라는 디스크 공간에 자주 사용하지 않는 메모리의 내용을 dump해서 저장한 후 다시 사용할때 memory에 loading 하는 방식을 사용한다. 그런데 이 메모리의 내용을 디스크에 저장 및 로드 하는 과정 (swapping이라고 함)이 실제 disk io를 발생 시키기 때문에, 실제 메모리 access 성능이 매우 급격하게 떨어진다. 그래서 시스템에서 system에서 swapping이 발생하면 시스템의 성능이 장애 수준으로 매우 급격하게 떨어진다.

부하 테스트 중이나, 운영 중에 swapping이 발생하게 되면 전체 메모리 사용량을 줄이도록 튜닝을 하거나, 반대로 물리 메모리를 늘리는 증설 과정이 필요하다.

Disk IO : Disk IO는 파일 시스템에 파일을 저장하는 시나리오나, Log를 저장하는 모듈 그리고 데이타 베이스와 같이 뒷단에 파일 시스템을 필요로 하는 모듈에서 많이 발생을 한다. Ganglia와 같은 도구를 사용하면, IOPS (Input Out per Second - 초당 read/write등의 IO 발생 횟수)를 통해서 모니터링할 수 있고, 또는 iostat나 sar와 같은 명령어를 이용하면 iowait 를 통해서 디스크 IO의 pending이 발생할 경우 디스크 병목이 있는지 없는지를 확인할 수 있다.

Figure 1. iostat

Process당 Disk IO는 iotop과 같은 툴을 사용하면 조금 더 상세한 정보를 얻을 수 있다.

Figure 2. iotop

Disk IO에 대한 Bottleneck은 여러가지 해결 방법이 있다. 먼저 하드웨어 인프라 ㅈ체에서 접근 하는 방식은, 디스크 자체를 SSD로 변경하거나, 버퍼가 크거나 RPM이 높은 디스크로 변경하는 방식, 인터페이스를 SATA에서 SAS나 SSD와 같은 높은 IO를 제공하는 디스크 인터페이스로 변경, Disk Controller는 iSCSI에서 FC/HBA와 같은 광케이블 기반의 고속 컨트롤러를 사용하는 방식 또는 RAID 구성을 Stripping 방식으로 변경해서 IO를 여러 디스크로 분산 시키는 방식 등이 있으며, 애플리케이션 차원에서는 데이타 베이스 앞에 memcache와 같은 캐슁을 사용하거나, 로깅의 경우에는 중간에 message queue를 써서 로그를 다른 서버에서 쓰도록 하여 IO를 분산하거나 또는 Back write와 같은 방식으로 로그 메세지가 발생할때 마다 disk에 writing 하는 것이 아니라 20개 30개씩 한꺼번에 디스크로 flushing 하는 방식등을 이용할 수 있다.

또는 조금더 높은 아키텍쳐 레벨로는 디스크 IO가 많이 발생하는 로직의 경우 동기 처리에서 message queue를 사용하는 비동기 방식으로 시스템의 설계를 변경하는 방법을 고민할 수 있다. 예를 들어 사진을 올려서 변환하는 서비스의 경우 파일을 업로드 하는 시나리오와 변경하는 모듈을 물리적으로 분리하여, 파일 업로드가 끝나면, 사용자에게 동기 방식으로 바로 응답을 줘서 응답 시간을 빠르게 하고, 업로드된 파일은 뒷단에서 비동기 프로세스를 통해서 변환 과정을 다 끝낸 후에 사용자에게 변환이 끝나면 알려주는 방법을 사용할 수 있다.

Network IO: Network IO는 특히 고용량의 파일이나 이미지 전송에서 병목이 많이 발생하며, Reverse Proxy, NAT (Network address Translator), Router, Load Balancer 등에서 많이 발생한다. 여러가지 지점과 장비에 대해서 모니터링 해야 하기 때문에, 일반적인 unix/linux command 를 사용하는 방법보다는 Cacti나 Ganglia와 같은 RRD 툴이나 OpenNMS와 같은 NMS (Network Management System)을 사용하는게 좋다.

그래프를 보면서 추이를 지켜 보는 것이 중요한데, 부하를 넣으면 일정 수준이 되어도, 시스템들의 CPU나 메모리, Disk등의 기타 자원들은 넉넉한데, Network Input/Output이 일정 수준 이상으로 올라가지 않는 경우가 있다. 이 경우는 네트워크 구간의 병목일 가능성이 높다.

특히 소프트웨어 기반의 Load Balancer나, 소프트웨어 기반의 NAT 장비에서 많이 발생하는데, 이미지와 같은 정적 컨텐츠는 가급적이면 CDN이나 분리된 Web Server를 이용해서 서비스 하도록 하는 것이 좋다. 클라우드의 경우에는 특히나 소프트웨어 기반의 NAT나 Load Balancer를 사용해서 문제가 되는 경우가 많은데, NAT의 경우에는 여러개의 NAT를 사용해서 로드를 분산하도록 하고, Load Balancer의 경우에도 충분히 큰 용량을 사용하거나 2개 이상의 Load Balancer를 배포한 후 DNS Round Robine등을 사용하는 방법을 고려 하는 것이 좋다.

개선 (Tuning)

병목을 찾았으면, 해당 병목 문제를 해결 및 반영해야 한다.

튜닝은 병목 구간이 발생하는 부분에 대한 전문적인 지식을 필요로 하지만, 기본적인 접근 방법은 거의 같다고 보면 된다.

문제의 정의 : 성능 개선의 가장 기본은 문제 자체를 제대로 정의 하는 것이다. “그냥 느려요”가 아니라, “성능 목표가 350TPS에 1초내의 응답 시간인데, 현재 60 TPS에 5초의 응답 시간에 WAS의 CPU 점유율이 100% 입니다.”와 같이 명확해야 하며, 문제점이 재현 가능해야 한다.

특히 재현 가능성은 매우 중요한 점인데, 테스트 환경이 잘못되었거나, 외부적 요인 예를 들어 부하 테스트 당시 네트워크 회선이 다른 테스트로 인하여 대역폭이 충분히 나오지 않았거나 했을 경우 결과가 그 때마다 다르게 나올 수 있다.

즉 문제 자체를 명확하게 정의할 필요가 있다.

Break down : 다음으로는 문제가 발생하는 부분이 어떤 부분인지를 판단해야 한다. 시스템은 앞단의 로드밸런서나 미들웨어, 데이타 베이스와 같은 여러 구간에서 발생을 한다. 그렇기 때문에, 성능 저하의 원인이 정확하게 어느 부분인지를 인지하려면, 먼저 성능 시나리오가 어떤 어떤 컴포넌트를 거치는지를 명확하게 할 필요가 있다. 이 과정을 break down이라고 한다. 이 과정을 통해서 전체 성능 구간중, 어느 구간이 문제를 발생 하는지를 정의한다.
Isolate : 다음으로는 다른 요인들을 막기 위해서, 문제가 되는 구간을 다른 요인으로 부터 분리 (고립) 시킨다. 물론 완벽한 분리는 어렵다. 애플리케이션이 동작하기 위해서는 데이타 베이스가 필수적으로 필요하다. 이 경우에는 데이타 베이스를 분리할 수 는 없다. 그러나 예를 들어 시나리오 자체가 로그인 시나리오이고 Single Sign On을 통해서 로그인 하는 시나리오라서 SSO 시스템과 연동이 되어 있다면, SSO 연동을 빼고 다른 mock up을 넣어서 SSO와의 연결성을 끊고 테스트를 하는 것이 좋다.

이렇게 문제에 대한 다른 요인과의 연관성을 최대한 제거 하는 작업이 isolation이다.

Narrow down : 문제를 isolation을 시켰으면, 근본적인 문제를 찾기 위해서 문제의 원인을 파 내려간다. Profiling을 하거나, 코드에 디버그 정보를 걸어서 문제의 원인을 분석하는 과정을 narrow down이라고 한다. 특히나 이 narrow down 과정은 분석을 위한 여러가지 기법이나 도구들을 사용해야 하고, 현상에 대한 이해를 하기 위해서는 해당 솔루션이나 기술 분야에 대한 전문성은 필수적으로 필요하다.
Bottleneck 발견 : Narrow down을 해서 문제의 원인을 계속 파해쳐 나가면 병목의 원인이 되는 근본적인 문제가 판별이 된다.
해결 : 일단 병목의 원인을 찾으면 해결을 해야 하는데, 찾았다고 모두 해결이 되는건 아니다. 데이타 베이스 index를 걸지 않아서 index를 걸어주면 되는 간단한 문제도 있을 수 있지만, 근본적인 솔루션 특성이나 설계상의 오류로 인해서 문제가 발생하는 경우도 있다. 하드웨어를 늘려서 해결하는 방법도 있지만, 비지니스 시나리오 자체를 바꾸거나 UX 관점에서 해결 하는 방법도 고려할 수 있다. 예를 들어 로그인 화면이 넘어가는데 시간이 많이 걸린다고 했을때, 이 문제가 근본적으로 솔루션의 특성이라면 애플리케이션이나 솔루션 수정으로는 해결이 불가능하다. 이런 경우에는 모래 시계 아이콘이나 progress bar등을 넣어서 UX 관점에서 사용자로 하여금 체감되는 응답 시간에 대해서 느리지 않고 몬가 진행이 되고 있다고 보여주는 형태로 접근을 해서 문제를 해결할 수 도 있다.

간단한 예를 하나 들어보자. Drupal 이라는 웹 CMS 기반의 웹사이트가 있다고 하자. 성능 테스트를 수행하였는데, CPU 점유율이 지나치게 높게 나오고 응답 시간이 느리게 나왔다. 이것이 문제의 정의이다.

성능의 문제점을 찾아내기 위해서, 성능 테스트 시나리오를 검토하였다 성능 테스트 시나리오는 1) 로그인 페이지 로딩, 2) id,password를 post로 전송 3) 초기 화면으로 redirect됨 4) 로그 아웃 4가지 과정을 거치고 있었다. 1,2,3,4 과정의 응답시간을 각각 체크해서 보니, 2) 과정에서 성능의 대부분을 차지 하고 있음을 찾아 내었다. 전체적으로 성능이 안나오는 것을 인지한 후, 문제를 여러 구간으로 나누어서 접근 하는 것이 Break down이다.

2) 과정을 분석하기 위해서 성능 테스트를 다시 진행한다. 다른 시나리오가 영향을 주는 것을 방지하기 위해서, 1,3,4 시나리오를 제외 하고, 2 시나리오만 가지고 성능 테스트를 진행한다. 이렇게 문제점을 다른 변수로 부터 분리하여 고립 시키는 것을 isolation이라고 한다.

다음으로 Xhprof 라는 프로파일링 툴을 사용하여 로직중 어느 부분이 가장 성능 문제가 발생하는 지를 profiling 하였다. 대 부분의 성능 저하가 SQL 문장 수행에서 발생함을 찾아내었다. 이렇게 하나의 포인트를 깊게 들어 가면서 범위를 좁혀가는 것을 narrow down이라고 한다.

SQL 수행이 문제가 있음을 정의하고(문제의 정의), 어떤 SQL 문장이 수행되는지(Break down) 각각을 정의한후, 가장 수행 시간이 긴 SQL 문장을 찾아서 원인을 분석하였더니(narrow down) index 가 걸려 있지 않음을 찾아내었다.

해당 테이블에 index를 적용하고, 성능 테스트를 다시 수행하여 성능 목표치를 달성하였음을 해결하였다.

가상의 시나리오지만 성능 튜닝의 접근 방법은 대부분 유사 하다. 관건은 문제를 어떻게 잘 정의하고, 문제가 어떤 요소로 구성이 되어 있으며 각각이 어떤 구조로 동작을 하고 있는지 잘 파고 들어갈 수 있는 문제에 대한 접근 능력과, 점점 솔루션의 아랫부분(low level)로 들어갈 수 있는 전문성이 필요하다.

반복

튜닝이 끝났으면 다시 “테스트 및 모니터링” 항목으로 돌아가서 성능 목표에 도달할때까지 위의 작업을 계속해서 반복해서 수행한다.

Performance Engineering을 위해 필요한 것들

그러면 성능 엔지니어링을 하기 위해서 필요한 것들은 무엇이 있을까? 먼저 도구 적인 측면부터 살펴보자.

부하 테스트기 : 가장 기초적으로 필요한 것은 부하 발생 도구 이다. HP Load Runner와 같은 상용 도구에서 부터, nGrinder와 같은 오픈 소스 기반의 대규모 부하 발생 도구를 사용할 수 도 있고, SOAP UI같은 micro benchmark 테스트 툴을 이용해서 소규모 (50 사용자 정도)를 발생 시키거나 필요에 따라서는 간단하게 Python등의 스크립트 언어로 부하를 발생시킬 수 도 있다.
모니터링 도구 : 다음으로는 모니터링 도구이다. 어느 구간이 문제가 있는지 현상이 어떤지를 파악하려면 여러 형태의 모니터링 도구들이 필요하다.
프로파일링 도구 : 그리고, 문제되는 부분을 발견했을때, 그 문제에 대한 근본적인 원인을 찾기 위해서 프로파일링을 할 수 있는 도구들이 필요하다.

우리가 일반적으로 이야기 하는 프로파일링 도구들은 IDE와 같은 개발툴에서 debug 용도로 사용은 가능하지만, 대부분 대규모 부하 환경에서는 사용이 불가능한 경우가 많다.그래서 그런 경우에는 해당 시스템의 상태에 대한 스냅샷을 추출 할 수 있는 dump 도구들을 많이 사용하는데, unix process의 경우에는 ptrace를 통해서 system call을 모니터링 하거나, pmap을 이용하여 메모리 snapshot등을 추출할 수 도 있고, 자바의 경우에는 thread dump를 추출해서 병목 당시 애플리케이션이 무슨 동작을 하고 있었는지를 찾아낼 수 있다.

다음이 이 글에서 정말 언급하고 싶은 내용인데, 앞에서 도구를 언급했다면 다음은 엔지니어로써의 역량이나 지식적인 부분이다.

역량 : 당연한 것이겠지만, 기술적인 역량은 필수적이다. netstat를 통해서 TCP 소켓이 FIN_WAIT가 발생하였는데, 이 FIN_WAIT가 의미하는 것이 무엇인지 모르면 아무리 모니터링을 잘해도 소용이 없다. 기본적인 엔지니어로써의 컴퓨터와 프로그래밍, OS등에 대한 넓은 이해는 필수적이다.
하드웨어 인프라, 미들웨어 , 애플리케이션에 대한 지식 : 다음은 사용하는 특정 솔루션에 대한 전문적인 지식이다. 톰캣의 내부 구조가 어떻게 되어 있으며, JVM의 동작원리가 어떻게 되는지와 같은 특정 지식인데, 사실 이러한 지식은 오랜 경험이나 습득할 시간이 없으면 가지기가 어렵다. 이런 경우는 해당 솔루션 제품 엔지니어를 통해서 지원을 받는 방법도 고려해볼만 하다.
그리고 경험 : 성능 엔지니어링에 대한 경험인데, 대략 시스템의 상태마 봐도 어느 부분이 의심이 되는지 경험이 많은 엔지니어는 쉽게 접근을 한다. 성능 문제는 넓어보이기는 하지만, 결국 발생되는 패턴이 거의 일정하다. 그리고 특정 솔루션에 대한 지식이 없다하더라도, 문제에 대한 접근 하는 방법이나 모니터링 방법, 툴등은 사용법이 다르다 하더라도 그 의미하는 방법은 거의 비슷하기 때문에, 다른 기술로 구현되어 있는 시스템이라고 하더라도, 경험이 있는 엔지니어는 문제를 접근해서 풀어나가는 방식이 매우 익숙하다.
마지막으로 인내심 : 그리고 마지막으로 강조하고 싶은 점이 인내심인데, 사실 성능 엔지니어링은 상당히 지루한 작업이다. 반복적인 테스트와 모니터링 및 분석을 거쳐야 하고, 해당 솔루션에 대한 전문적인 지식이 없을 경우에는 보통 제품 문제라고 치부하고 하드웨어 업그레이드로 가는 경우가 많은데, 어짜피 솔루션이라고 해도 소스코드로 만들어진 프로그램이다. 디컴파일을 하건, 덤프를 추출하건, 꾸준히 보고, 오픈 소스의 경우 소스코드를 참고해서 로직을 따라가다 보변, 풀어낼 수 있는 문제가 대부분이다. 결국은 시간과 인내심의 싸움인데, 꾸준하게 인내심을 가지고 문제를 접근하고 풀어나가는 것을 반복하면 문제는 풀린다.

[1] 출처 : http://guichaz.free.fr/iotop/

출처 : http://bcho.tistory.com/787

시스템 용량산정 도구 (x86 서버외 용량산정)

JAESOO — Mon, 24 Aug 2015 11:38:28 +0000

시스템 용량산정 도구 입니다.

X86서버 외 용량산정 하실 때 유용한 자료 입니다.

- 정보시스템 용량산정 도구(Sizing).xls

- Dell_PowerEdge_tpmC_추정값.xlsx

- HP_ProLiant_tpmc_공인_추정성능치_v12_E5-24xx_update.xls

- HP_ProLiant_tpmc_공인_추정성능치_v15_IVY_bridge_update.xlsx

출처 : http://redsunset.synology.me/xe-dwcts/index.php?mid=customer_support_technical&category=1246&search_keyword=%EC%9A%A9%EB%9F%89&search_target=title&document_srl=3636

Unable to connect to the network share 'x.x.x.x\ADMIN$' - When using vCenter Converter the converter agent fails to install with an error (1021465)

JAESOO — Sun, 23 Aug 2015 20:57:55 +0000

Unable to connect to the network share 'x.x.x.x\ADMIN$'

When using vCenter Converter the converter agent fails to install with an error (1021465)

Symptoms

When converting a remote machine using vCenter Converter Standalone, you see the error:

Converter Standalone Agent installer/uninstaller failed on xxxxxxxxx.

Note: Where xxxxxxxx is the IP address or hostname of the source machine being converted.

When converting a remote machine using vCenter Converter, you see the error:

Unable to complete installation/uninstallation of vCenter Converter agent on xxxxxxxx

Where xxxxxxxx is the IP address or hostname of the source machine being converted.

In the C:\Documents and Settings\All Users\Application Data\VMware\VMware vCenter Converter Standalone\logs\vmware-converter-server-xx.log file ,you see entries similar to:

info 'App'] [agentManager,83] [AgentManager] Install Agent on xxxxxxxxx
info 'App'] [agentDeploymentWin32,47] [AgentDeployment] Connect to ADMIN$ on xxxxxxxxx as xxxxxxxxx\administrator
info 'App'] [,0] SMB manager: Error connecting to share [\\xxxxxxxxx\ADMIN$]: 1385
error 'App'] [agentDeployment,366] [AgentDeployment] Deployment on xxxxxxxxx failed: Unspecified error in remote execution mechanism
error 'App'] [agentDeployment,158] [AgentDeployment] Install of Agent failed on xxxxxxxxx
error 'App'] [agentManager,106] [AgentManager] Install Agent failed: converter.fault.AgentDeploymentFault

Cause

This issue occurs when the vCenter Converter connection to the network share of the remote computer fails.

Resolution

Note: Ensure that there are no pending Windows updates on the machine and any anti-virus software is disabled during this process.

To resolve this issue, ensure that you can connect to the remote share.

To ensure that you can connect to the remote share:

Ensure that you can access the shared location on the remote computer.
Ensure that the Server service is running on the source machine:
1. Click Start > Run, type services.msc, and click OK.
2. Locate the Server service in the services console and ensure that the status is Started.
3. If the service is not started, right-click on the service and click Start.
Disable any firewalls, User Access Control (UAC), or Simple File sharing on the remote Windows guest operating system.

For the list of necessary ports that are required to be open, see the vCenter Converter Administration Guide.

Manually copy the Converter Agent Installer, VMware-Converter-Agent.exe located at C:\Program Files (x86)\VMware\VMware vCenter Converter Standalone, from the source computer to the remote computer and install the Converter agent.
If the preceding steps do not resolve the issue, install the vCenter Converter Standalone utility on the remote computer and start the conversion from the remote computer.

Request a Product Feature

To request a new product feature or to provide feedback on a VMware product, please visit the Request a Product Feature page.

Feedback

1 2 3 4 5
89 Ratings

출처 : http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1021465

쿨러, 베어링 타입별 특징

JAESOO — Tue, 07 Jul 2015 10:41:11 +0000

요약: 비싼것일 수록 수명도 길고, 소음도 적다./ 슬레이브 타입은 비추 / 최소 1볼이상의 타입을 사용할것을 추천함.

베어링 [bearing] : 회전하고 있는 기계의 축을 일정한 위치에 고정시키고 축의 자중과 축에 걸리는 하중을 지지하면서 축을 회전시키는 역할을 하는 기계 요소

냉각팬의 베어링 방식에는 슬리브 베어링 방식과 볼 베어링 방식 크게 두 가지가 있습니다. 또는, 이 두 방식의 중간쯤 되는 하이프 방식, NBR방식 ... 등 몇가지 더 있긴 합니다만.

여기선 슬리브(SLEEVE) 베어링과 볼(BALL)베어링을 장착 했을 때의 소음 차이에 대해서 간단하게 말씀드리겠습니다.

결론부터 말씀 드리면, 베어링 때문에 소음의 차이가 나는 것은 아닙니다.

슬리브 방식보다 볼 방식이 소음이 적게 나는걸로 알고 게시는 분들이 많으신 것 같은데 팬에서 소음의 차이는 팬 속도에 의해 좌우됩니다.

팬 속도는 다음과 같이 크게 세 단계로 분류합니다.
저속 (LOW SPEED), 중속(MIDDLE SPEED), 고속(HIGH SPEED)

물론, 제조사 모델에 따라 그 이상 높은 속도가 나오는 팬도 많이 있습니다.

베어링은 소음에는 영향이 없고 팬의 수명과 직접적인 연관이 있습니다.

슬리브 베어링은 베어링에 오일을 발라서 팬의 회전을 돕는데, 일정시간 사용 후 오일이 증발해 버리면 그때부터 베어링과 샤프트의 마찰음으로 소음이 나기 시작하다가 결국엔 팬이 멈추게 됩니다.

온도가 높다거나, 먼지가 많은 곳, 장시간 팬을 사용하는 곳에는 슬리브 방식의 제품을 가능한 한 사용 안하시는게 좋습니다.

볼 베어링은 베어링 내에 볼이 들어있어서 외부의 영향을 많이 받지 않으므로 장시간 사용이 가능합니다.
다시 말씀드리지만, 베어링 방식에 따라 소음차이가 나는것이 아님을 강조 드리고 싶습니다.

출처 : http://neoray.tistory.com/604#.VXfadE0w_Gg

2. 베어링

1) 슬리브 베어링

먼저 슬리브 베어링입니다

슬리브 베어링은 좌측 그림상에서 고정되어 있는 외륜 즉 슬리브가 가운데 회전축을 지탱합니다.
물론 사이에는 완전 액체도 아니고 구리스도 아닌 묽은 구리스 수준의 윤활유가 들어있구요.
슬리브의 재질, 가공법, 사용 윤활유, 동작 RPM에 따라 수명이 결정되는데요 수명 차이가 정말 크게 납니다.
25℃ 기준으로 1,000시간도 안되는것;;; 부터 30K시간 정도인데요.
근데 얘는 회전축이 중심을 못잡고(윤활유밖에 없으니까요;;) 흔들려서 슬리브와 축이 만나 슥슥 소리가 난다는 점...

그리고 온도가 올라갈 수 록 수명이 기하급수적으로 하락합니다.
고온(45℃ 이상)에서의 내구성이 너무나도 떨어지기 때문에 CPU쿨러 배기용쿨러로는 좋지 않습니다.
슬리브와 축사이에 먼지나 이물질도 많이 들어가고 윤활유도 증발하는데요.
이 현상을 해결하기 위해 제조사에서는 사출로 마무리 한다던지 여러 방법을 고려 하지만... 슬리브베어링은 슬리브베어링입니다;;;
슬리브에 나선형의 홈을 넣어 만든 라이플 베어링도 25℃에서는 볼베어링 보다 살짝 떨어지는 수명을 가지지만 고온에서는 역시 윤활유 증발 등의 문제가 있죠.

팬이 덜덜거리면서 돌때 윤활유를 추가해주면 다시 정상적으로 동작합니다.

다만 사출로 마무리한 슬리브베어링은 답이없죠;;

2) 볼베어링

볼베어링입니다. 그림에 케이지가 빠졌습니다.
볼 사이에 볼의 간격을 정하는 케이지가 있습니다 외륜, 내륜, 케이지, 볼의 구성입니다.
2Ball 베어링과 1Ball 베어링으로 나뉘는데 일반적으로는 2Ball 베어링을 말합니다.
1볼베어링은 팬이 얇아서 안들어갈때 외에는 잘 안씁니다.
볼베어링은 일단 금속이고 쇠공이 위 슬리브 베어링에서의 윤활유 역할을 하기 때문에 고온(50℃)에서도 60K시간을 동작합니다.
사실 이론상 완벽한 볼베어링 자체는 25℃기준 200K시간까지도 작동하지만 실제로는 쇠공이 완전한 원형이 아니고 이로 인한 진동으로 그 정도 까지는 나오지 않고 25℃ 기준 95K시간 정도 작동합니다. 델타에서 만드는 델타팬은 10000RPM짜리팬도 40℃에서 70K시간의 수명이라고 하죠.
윤활제를 쓰긴하지만 오일처럼 증발이 쉬운 액체가 아니라 구리스를 씁니다.
그리고 구형태를 깎는 기술력이 완벽에 가까워질 수 록 수명도 늘어납니다.

단점은 떨어뜨리면 안된다는 겁니다.- 충격에 약합니다.

3) FDB(Fluid Dynamic Bearing)

이건 슬리브의 변종으로 볼 수 있지만 조금 다릅니다 위의 사진은 소니 FDB 베어링이지만, FDB베어링은 종류가 많습니다

소니 FDB로 팬을 만들어 인기가 있었던 ADDA의 자료를 가지고 왔는데요(너무 오래된 자료니 FDB원리만 참고하세요. 2Ball 베어링 수명기준이 1989년 ;;;;)

점성이 매우 낮은 물과 같은 윤활유를 사용합니다.
이처럼 금속 슬리브 안에 V자의 그루브가 있으며

이로인해 축이 회전함에 따라 윤활유가 한쪽으로 몰리지 않고
샤프트와 슬리브 사이에 홈을 따라 이동하며 고루고루 들어가 축이 중심을 유지합니다.

그리고 축의 회전속도가 올라가면 윤활유의 이동속도도 빨라지기 때문에 고RPM 회전을 할 수 록 축이 단단히 중심을 잡습니다.
(이 말은 FDB는 낮은 RPM 팬에서는 그리 효과가 좋지 않다는 말도 됩니다)

거기에 완전차폐를 하여 이물질의 유입을 막고 윤활유의 증발을 막기 때문에,
25℃ 기준 150K시간이라는 높은 수명을 가집니다. 그리고 ADDA의 FDB팬은 40℃기준 60k시간의 수명을 가지죠(25℃에서의 결과는 마케팅적인 측면이 강하므로 메이저 팬 제조사는 40℃에서의 결과를 우선 표기합니다.)

미세가공등의 이유로 대량생산이 쉽지 않고 생산비용이 볼베어링보다 비싸 예전에는 하드 등에만 사용되었으나 현재는 생산비용은 볼베어링과 비슷하다고 합니다.
특징으로 축과 베어링이 닿는 부분이 오일 밖에 없으므로 베어링 소음이 적고 진동도 적습니다.

하드에서는 대부분 FDB베어링을 사용중인데

이유는 진동이 적기 때문입니다.
볼베어링은 아까 말했듯이 완벽한 구형이 아니고 안에 케이지와도 맞닿기 때문에 고유한 진동이 있습니다.
근데 이 작은 진동이 하드의 진동과 정말 혹시나 일치해버리게 되면 제법 큰 공진이 생기고 공진은 하드 수명에 좋지 않기 때문이죠.

3. 팬의 생김새에 따른 차이점

1) 팬 프레임 두께에 의한 차이

팬의 두께는 소음과는 크게 관계가 없다.

2) 날개 피치각도에 따른 차이

날개의 각도를 낮추면 풍압과 소음이 적어지고 날개의 면적이 커지기 때문에 풍량이 높아집니다.
날개의 각도를 높이면 소음과 풍압이 높아지고 일정이상 높일시 풍량이 적어질 수 있습니다.

3) 날개 갯수에 따른 차이

날개가 많다 : 상대적으로 풍압이 높고 풍량이 적다 소음은 높다.
날개가 적다 : 상대적으로 풍량이 많고 풍압은 낮다. 소음은 낮다.

4) 팬의 허브에 사이즈에 따른 차이

좁은 공간으로의 공기 이동은 주변 기압차를 크게 만들고 이것은 풍압의 증가로 이어집니다

다만 왼쪽 팬보다 풍량은 적겠죠.

출처 : http://www.jeongmo.co.kr/killme/17719

녹투아(NOCTUA) 120mm PWM 저소음 팬 3종 비교

JAESOO — Thu, 02 Jul 2015 11:32:37 +0000

제품명		NF-F12 PWM	NF-P12 PWM	NF-S12A PWM
순위		1	2	3
가격		24,500	22,940	23,620
출시		2012.12	2012.11	2013.04
크기		120mmx120mmx25mm	120mmx120mmx25mm	120mmx120mmx25mm
커넥터		4-Pin PWM	4-Pin PWM	4-Pin PWM
베어링		SSO2 베어링	SSO 베어링	SSO2 베어링
팬날개 형상		독자기술 Heptapert 블레이드	VCN 형상 Nine 블레이드	S-Series With Anti-stall Knobs
프레임 기술		독자기술 Focused Flow		AAO (고급 음향 최적화)
입력전원		DC 12V	DC 12V	DC 12V
전력량		0.6W	0.6W	1.44W
전류		0.05A	0.05A	0.12A
수명		>150,000h	>150,000h	>150,000h
RPM	FAN	1500RPM	1300RPM	1200PRM+-10%
RPM	L.N.A	1200RPM	900RPM	900PRM+-10%
풍량	FAN	93.4m3/h	54.3CFM	106.5m3/h
풍량	L.N.A	74.3m3/h	37.3CFM	83.2m3/h
소음	FAN	22.4dB(A)	19.8dB(A)	17.8dB(A)
소음	L.N.A	18.6dB(A)	12.6dB(A)	10.7dB(A)
풍압	FAN	2.61mmH2O	1.68mmH2O	1.19mmH2O
풍압	L.N.A	1.83mmH2O	1.21mmH2O	0.73mmH2O
용도		흡기용		배기용

시만텍(Symantec) 솔루션 적용 구성도

JAESOO — Fri, 19 Jun 2015 16:16:06 +0000

출처 : http://www.goodmit.co.kr/?page_id=7074

[네트워크 트러블 슈팅 ④] 네트워크 장비별 트러블 슈팅

JAESOO — Mon, 15 Jun 2015 20:23:56 +0000

이미 네트워크는 특정인만의 전유물이 아니기에 네트워크상에서 발생하는 수많은 장애는 고스란히 컴퓨터를 사용하는 모든 사람들에게 영향을 주게 마련이다. 네트워크로 인해 발생하는 장애는 업무처리를 방해하기도 하지만 이렇다 할 해결책을 찾기란 쉽지 않은 일이다. 특집 4부에서는 네트워크를 이루는 장비들 사이에서 발생하는 장애요인과 그 해결방법들에 대해 알아본다.

네트워크를 배제한 상태에서 단 한대의 컴퓨터만 사용한다 하더라도 여러 문제들 탓에 컴퓨터가 말썽을 부리게 마련. 하물며 오늘날처럼 지구상의 거의 모든 컴퓨터들이 복잡한 네트워크를 통해 연결되어 있고 서로 영향을 주는 상황에서 생길 수 있는 문제가 얼마나 많을지는 말하지 않아도 알 수 있을 것이다.

물론, 그 수 많은 문제들 중 보다 빈도가 높고 찾기 쉬운 문제들도 있다. 그것이 바로 이번 부에서 알아볼 물리적 장비들이 일으키는 문제들이다.

네트워크에서 문제를 일으키는 가장 대표적인 원인은 주로 케이블 불량이나 규격 이상, 전원문제처럼 물리적인 요소와 이상 패킷, 불량 프레임, 상이한 프로토콜이나 호환 문제 등이다.

이런 논리적 요소를 네트워크를 구성하는 일곱 개 레이어 중 가장 아랫단에 있는 레이어 1과 레이어 2라고 부른다. 여기에서는 레이어 1과 2를 구성하는 요소와 그것들이 일으키는 문제들에 대해 알아본다.

문제의 시작은 케이블

네트워크를 하기 위해서 가장 중요하고 또 많이 쓰이는 것이 바로 케이블이다. 한편 많이 사용되는 만큼 가장 쉽게 문제의 원인이 되기도 한다. 케이블은 단순히 PC와 PC를 연결하기만 하는 것이 아니다. 장비와 장비를 연결해 주는 중요한 역할도 수행한다. 인터넷 망도 어떻게 보면 장비와 케이블의 조화라고 할 수 있다.

만약 갑자기 네트워크 장애가 발생한다면 자신의 랜 카드 LED가 정상적으로 반짝이는지 확인하거나 윈도우의 네트워크 상태 창을 통해 랜 카드의 작동 상태를 확인해야 한다. 그 다음으로 확인해 보아야 할 것이 바로 대부분의 경우 의심하지 않는 케이블이다.

필자가 모 대학교의 전산망을 유지 보수하던 때의 일이다. 건물 한 동 전체가 인터넷이 안 된다고 신고가 들어와 현장에 나가 보았다. 도착해서 제일 먼저 장비를 확인해 보았다. 장비에서는 문제가 발생하면 가장 간단히 확인 할 수 있는 것이 LED(상태를 나타내는 램프)이다. LED는 정상적이었고 달리 무엇이 문제인지 알 수가 없었다.

당시만해도 필자 역시 경험이 많지 않아 설마 케이블이 불량일거라는 생각은 하지도 못했다. 아무리 장비들을 확인해봐도 이상이 없어서 지푸라기라도 잡는 심정으로 확인해 본 것이 케이블. 확인 결과 건물과 백본 스위치(Backbone Switch)를 연결하는 케이블이 불량이라는 사실을 알 수 있었다. 케이블이 얼마나 중요한지 새삼 깨달을 수 있는 경험이었다.

꼭 불량이 아니더라도 케이블 때문에 생길 수 있는 문제는 참 많다. 여기에서는 먼저 우리가 많이 사용하는 케이블의 종류와 불량케이블을 확인할 수 있는 방법에 대해서 알아보자. 일반적으로 PC와 장비를 연결할 때에는 대부분 TP(Twisted-pair) 케이블을 사용한다. 우리말로는 ‘꼬인 선’ 정도로 풀이 된다.

TP 케이블은 다시 UTP와 STP 케이블로 구분된다. STP케이블은 잘라보면 전선에 절연체가 덥혀 있어 전기적인 특성을 많이 타지 않는 것이 특징이지만 가격이 비싸서 많이 사용되지는 않는다.

UTP는 Unshielded Twisted-pair의 약어로 STP(Shielded Twisted-pair)케이블과는 다르게 케이블을 잘랐을 때 따로 절연체(은박지)로 덥혀 있지 않은 케이블이다. 흔히 사용되는 UTP는 다시 1에서 6까지의 카테고리로 나뉜다.

카테고리를 나누는 기준은 케이블의 전송속도와 형태이다. 현재 LAN 환경에서는 대부분이 카테고리 5이상 사용하고 있다. <표 1>은 UTP 케이블의 규격을 나타난 것이다.

만약 자신의 랜 카드가 1Gbps를 지원하는 랜 카드이고 스위치 가 1Gbps를 지원 한다면 케이블은 카테고리 5-e 이상의 규격을 사용하여야 정상적인 속도를 제공받을 수 있다.

TP 케이블

UTP케이블 다음으로 많이 사용되며 최근에 많은 주목을 받는 케이블은 광케이블이다. TP케이블은 100M 이상의 거리에서 사용하기 어렵다는 단점이 있지만 광케이블의 경우는 수 미터에서 수백 킬로미터까지 데이터전송에 제한이 없기 때문이다. 보통 백본 스위치, 워크그룹 스위치(Workgroup Switch)와 서버를 연결할 때는 광케이블을 사용한다. <표 2>는 케이블 커넥터의 일반적인 타입 종류들이다.

UTP 케이블 규격

광케이블은 거리에 따라 멀티모드 케이블과 싱글 모도 케이블로 나뉜다. 멀티모드 케이블은 최대전송거리 2Km, 싱글 모드 케이블은 기본적으로 장비의 종류에 따라 전송거리를 제공하므로 전송거리가 2Km 이상 일 때 구성되는 케이블이다.

컴퓨터간 통신 에러의 주범 케이블
컴퓨터와 장비(Switch나 Hub)를 연결할 때는 <그림 1>와 같은 모양의 다이렉트 케이블(Direct cable)을 사용한다. 그런데 이 다이렉트 케이블을 컴퓨터와 컴퓨터를 연결하는 데에 사용하여 문제가 발생하는 경우가 종종 있다. 컴퓨터와 컴퓨터를 연결할 때에 다이렉트 케이블을 사용하면 네트워크를 구성할 수 없다.

컴퓨터와 컴퓨터를 연결해야 할 때에는 <그림 2>와 같은 모양의 크로스 케이블(Cross cable)을 사용해야 한다. 다이렉트 케이블과 크로스 케이블을 구분하는 가장 확실한 방법은 케이블의 양쪽 끝 모양을 확인하는 것이다.

케이블 양 끝의 선 순서가 같으면 다이렉트 케이블이고 그렇지 않으면 크로스 케이블이다. 또, 양 끝의 선 순서가 다르다고 무조건 제대로 된 크로스케이블이 아니며 <그림 2>처럼 1, 2, 3, 6 번 선의 순서가 제대로 배열되어 있어야 한다.

광 커넥터의 종류

다이렉트 케이블 선 배열

간혹 네트워크가 느려지는 원인으로 케이블 불량을 의심하기도 하는데, 케이블 탓에 네트워크가 느려지는 경우는 흔치 않다. 케이블에 문제가 있다면 아예 네트워크 접속 자체가 안 되는 탓이다.

크로스 케이블 선 배열

만약, <그림 1> <그림 2>와 같이 적절한 케이블을 사용했는데도 네트워크 연결이 되지 않는다면 TP 케이블 테스터를 사용해서 케이블의 상태를 확인할 수 있다.

전파사 등에서 <화면 2>와 같은 모양의 TP 케이블 테스터(일명: 랜 테스터)를 구입한 뒤에 케이블 양 끝을 테스터에 꼽으면 케이블 상태를 확인할 수 있다. 테스트 결과 케이블의 상태가 좋지 않다면 케이블을 보수하는 대신 교체하는 편이 좋다.

광케이블을 사용하는데 접속이 불량일 때의 원인과 해결법
광케이블은 먼지나 구부러짐(bending)에 매우 민감하기 때문에 주로 이러한 원인이 트러블을 일으키게 된다. 광케이블의 가장 중요한 요소가 바로 빛의 세기(dB)인데 먼지나 구부러짐으로 인해 빛의 세기가 줄어들거나 단선을 유발하는 탓이다. 혹은 광케이블 연결에 사용하는 컨버터인 GBIC(GigaBit I/F Converter)의 불량이 비슷한 증상을 유발하기도 한다.

TP 케이블 테스터

물론, 케이블의 빛의 세기가 무조건 높다고 좋은 것이 아니기에 적당한 세기(-3dB ~ -19dB)로 맞춰 주어야 한다. 광케이블을 사용하고 있는데 접속이 불량하거나 속도가 느려진다면 옵티컬 파워 미터(Optical Power meter)를 이용해서 빛의 세기를 측정한다.

일반적으로 dB 값이 너무 높을 경우 광 소자가 문제를 일으키게 되고, 너무 낮으면 접속이 되지 않는다. 옵티컬 파워 미터로 빛의 세기를 측정한 결과 빛이 너무 강하면 감쇄기를 사용해서 적정 수준으로 맞춘다. 빛의 세기가 너무 약할 때에는 해당 모듈이나 장비를 교체해야 한다. 일반적으로 너무 낮을 경우에는 장비 불량도 일부 있지만, 지빅(GBIC)이나 FX모듈(100M 광 모듈) 불량일 때가 많다.

옵티컬 파워미터(Optical Power meter)

일반적으로 네트워크에서 가장 흔히 접하는 도구가 바로 NIC(Network Interface Card) 즉 랜 카드이다. 도스 시절이나 윈도우의 초기처럼 일일이 시스템 파일을 만지고 드라이브를 설치할 필요 없이 윈도우를 설치할 때 자동으로 인식되는 랜 카드.

본체에 연결만 해 두면 대부분 별다른 문제없이 잘 돌아가기 때문에 별로 신경이 가지 않는 랜 카드지만, 한번 골을 냈다 하면 대형 사고를 치는 도구이기도 하다. 랜 카드가 일으키는 장애와 해결방법에 대해 알아보자.

랜 카드도 장애요인?

랜 카드도 대형장애의 원인
몇 달 전 필자가 관리하는 네트워크 장비 중에 중요한 스위치가 다운된 적이 있다. 사실 네트워크 관리자라 하더라도 이렇게 느닷없이 스위치가 다운되는 원인을 찾기란 쉽지 않은 일이다. 많은 컴퓨터 사용자가 그러하듯 원인을 파악하기 어려운 문제가 발생할 경우 네트워크 관리자들도 빠른 복구를 위해 해당 장비를 리부팅하는 방법을 사용한다.

필자도 가장 빠르고 확실한 해결을 위해 이 방법을 택했지만 같은 문제가 일주일 동안 지속되니 뭔가 대책이 필요했다. 네트워크를 트래픽을 분석해 보니 서버의 랜 카드가 불량 트래픽을 발생시켜서 전체 스위치에 영향을 주고 있었다.

우선 해당 시간에 백본 라우터는 EIGRP(라우팅 프로토콜의 하나)로 구성되었는데 해당 시간에 EIGRP로 이웃(Neighbor)을 맺은 라우터와 단절현상이 발생되었다. 또 백본 라우터에서 다음과 같은 메시지를 나타내며 EIGIP를 재실행한다는 메시지를 보냈다.

<백본 라우터의 로그>
%DUAL-5-NBRCHANGE: IP-EIGRP 11: Neighbor 172.27.1.3 (FastEthernet0/0/0) is down: peer restarted
%DUAL-5-NBRCHANGE: IP-EIGRP 11: Neighbor 172.27.1.3 (FastEthernet0/0/0) is up: new adjacency

그리고 스위치에서는 특정 MAC에서 플래핑(flapping)이 발생하여 지속적으로 업/다운을 발생하며 다음 메시지를 로그서버로 보냈다.

<스위치의 로그>
%C4K_EBM-4-HOSTFLAPPING: Host 00:03:2E:05:00:00 in vlan 1 is flapping between port Gi2/15 and port Gi6/44
%C4K_EBM-4-HOSTFLAPPING: Host 00:03:2E:05:00:00 in vlan 1 is flapping between port Gi2/15 and port Gi6/44

해당 MAC을 확인해 본 결과 최근에 신규로 개발을 위해서 도입한 NT서버라는 것을 확인했다. 이후에 랜 카드를 변경하여 장애를 복구할 수 있었다. 좀 더 빨리 원인을 알았더라면 대형장애를 예방할 수 있었던 사례였다.

랜 카드

만약 자신의 랜 카드에 문제가 있다고 의심이 된다면 <화면 6>처럼 도스 모드에서 ‘netstat –e’ 라는 명령어를 사용하면 네트워크의 실시간으로 모니터링을 할 수 있다. 특히 빨간색 네모에서 error가 자주 발생한다면 랜 카드나 PC와 접속되어 있는 장비를 의심해 볼 만하다. 명령어 뒤쪽에 10은 10초마다 패킷 상태를 표시하라는 의미이다.

Unknown protocols는 윈도우에서 인식하지 못하는 프로토콜을 사용하는 패킷을 말한다. 정상적인 패킷이지만 윈도우에서 인식하지 못하는 경우도 있으니 이것만으로 컴퓨터나 랜 카드가 불량이라고 의심하기에는 부족하다.

바이러스나 스파이웨어의 경우 패킷을 유발할 가능성이 높은 만큼 백신프로그램이나, 스파이웨어 제거프로그램을 자주 실행해서 예방하는 것이 중요하다. 그리고 인터넷을 사용하다가 갑자기 속도가 느려지거나, 혹은 네트워크에 문제가 발생하면 가장 먼저 자신의 컴퓨터 상태를 점검해야 한다.

트래픽 분석 프로그램을 이용한 서버 응답시간

편지나 메일을 주고 받기 위해 주소가 필요하듯 서로 다른 네트워크 장비가 통신을 할 때에도 주소를 이용한다. 그 중 가장 대표적인 주소가 바로 MAC 주소와 IP 주소이다. 랜 카드를 포함해서 모든 통신장비들은 고유의 주소를 가지는데 이런 주소를 MAC(Media Access Control) 주소라고 부른다.

자신의 컴퓨터에서 커맨드 창을 하나 열고 ‘arp –a’ 라고 입력하면 현재 자신의 MAC 주소를 알 수 있다. <화면 7>은 arp –a를 실행했을 때 자신의 MAC 및 IP를 확인할 수 있다.

<화면 7>에 표시되어 있는 ‘00-16-9d-6f-00-00’이 MAC 주소 이다. MAC 주소는 총 48bit로 되어 있고 앞의 24bit (00-16-9d)는 제조회사 코드이고 나머지는 24bit(6f-00-00 )는 일련번호이다. 먼저 통신을 하기 위해서는 서로의 MAC 정보를 알아야 한다. 일반적으로 IP주소를 가지고 통신하고 있는 것으로 알고 있는데, IP주소(논리적 주소)로만 통신이 가능하지 않다.

netstat으로 체크한 랜 카드의 상태

보통 패킷은 레이어 3계층인 네트워크 계층에서 다룬다. 이 패킷들이 인캡슐레이션(encapsulation)과정을 거친 뒤에 레이어 2로 내려오는데 이렇게 내려온 패킷을 프레임이라고 부른다. L2 프레임의 포맷은 아래 <그림 3>과 같다.

MAC 주소와 IP 주소와의 관계

- Preamble: 수신 클럭을 추출하여 송수신 속도를 맞추는 동기를 제공함.
- SFD(Starting Frame Delimiter): 다음 바이트 열이 프레임의 시작을 알림.
- DA(Destination Address): 목적지 MAC주소
- SA(Source Address): 송신 측 MAC주소, - EtherType: MAC 프레임 다음의 데이터 부분에 상위 프로토콜의 종류를 표시함.
- Data: 상위 프로토콜이 위치. 최대 허용길이(MTU)는 1500바이트임. DA부터 FCS까지 전체길이가 64바이트 이상이어야 한다는 규정을 준수해야 함.
- 패딩: 최소길이 규정을 만족하지 못할 경우 '0'으로 채움.
- FCS: 프리앰블과 SFD를 제외한 MAC프레임의 비트열의 에러를 검사함.

<그림 4>에서도 알 수 있듯이 통신 해야 할 목적지인 MAC 주소를 바로 알 수 없다. 따라서 IP 주소를 MAC 주소로 변환해 주는 과정이 있으며 이를 ARP(Address Resolution Protocol)라고 한다. ARP는 주소를 변환해주는 프로토콜이다. 변환이라기 보다는 알아내는 프로토콜이라는 표현이 더 적당할 듯하다. <그림 4>를 통해서 ARP의 동작 과정을 이해해 보자.

① 호스트 A에서 호스트 B로 프레임을 보내려 한다.
- 호스트 A는 호스트 B의 L2 주소를 알기 위해서 같은 네트워크 내의 모든 노드에게 ARP 리퀘스트 패킷을 보낸다.
- 호스트 C와 D는 ARP 리퀘스트를 받았지만 자신의 IP주소에 관한 내용이 아니므로 무시한다.

② 호스트 B는 ARP 리퀘스트를 받고 자신의 IP주소에 맞는 내용이므로 호스트 A에게 자신의 MAC 주소를 담은 ARP 리스폰스를 보냄으로 응답한다.
- 호스트 A는 호스트 B로부터 온 ARP 리스폰스를 받고 호스트 B의 L2 주소를 알게 되고 ARP 테이블에 저장한다.
이제 호스트 A는 호스트 B로 L2(MAC) 주소를 사용해서 프레임을 전송한다.
- 다른 패킷을 보내는 경우 호스트 A는 자신에게 있는 ARP 테이블을 사용하기 때문에 ARP lookup(2단계~5단계)을 생략할 수 있다.

<화면 8>에서 일어나는 일련의 과정을 이더리얼(Ethereal)라는 패킷 분석 프로그램으로 캡처하면 <화면 8>과 같은 결과를 얻을 수 있다. 우선 자신을 제외한 모든 호스트의 MAC을 모르고 있기 때문에 ARP 리퀘스트 패킷을 모든 호스트로 보낸다.

이 패킷 형태는 브로드캐스트(Broadcast)라고 하는데 이런 브로드캐스트 패킷은 네트워크의 입장에서는 줄여야 하는 패킷이고, 가끔은 장애의 원인이 되기도 한다.

ARP 확인

<화면 9>의 패킷 예를 자세히 살펴보면 Target MAC address 라는 부분이 00:00:00:00:00:00 이라고 되어 있다. 이것은 모든 호스트로 보낸다는 의미이다. 이렇게 습득한 MAC 정보는 자신의 ARP 테이블에 저장하고 일정시간 동안 관리한다.

프레임의 구조

정리하자면 논리적 주소인 IP 주소는 사용하기 편리하지만 실제로 통신에 사용되는 주소는 물리적 주소인 MAC이다. 즉 ‘MAC 주소 = 부여한 IP주소’라는 식이 만들어지고 실제로는 MAC 주소가 통신에서 사용된다는 사실이다.

ARP 동작 과정

집에서 인터넷을 사용할 때 사용하는 공유기 역시 여기에서 설명할 허브의 한 종류이다. 이 허브는 랜의 중심에 해당하는 장비이다. 간단히 말하면 여러 대의 컴퓨터를 연결하고 싶은데 중간에 연결 시켜줄 수 있는 매개체가 필요할 때 사용하는 장비이다. 일반적으로 네트워크 토플로지(네트워크형태)에서 <그림 5>과 같은 스타형 토플로 방식으로 랜을 구성한다면 무조건 허브이나 스위치가 필요하다.

이더리얼을 이용한 패킷 캡처

스타형은 말 그대로 백본을 중심으로 한 가닥씩 라인을 뻗어 네트워크를 구성하는 것이다. 스타형은 한 에지 단에 장애가 발생하더라도 전체 네트워크에 영향을 덜 미친다는 장점이 있다. 반면에 백본에 장애가 발생하면 모든 네트워크가 중단된다.

허브는 매우 단순한 구조로 만들어져 있으며 그만큼 장애에도 취약하다. 우선 허브는 중앙에 집중되어 있는 장비지만, 연결되어 있는 호스트의 MAC을 관리하지 않는다.

패켓의 형태

<그림 6>에서 허브는 연결되어 있는 포트를 통해 모든 포트로 해당 패킷을 보내게 된다. 그렇게 되면 아래 호스트는 자신과 관련 없는 패킷이기 때문에 해당 패킷을 폐기(Drop)한다. 서버와 통신하는 컴퓨터는 자신에게 온 데이터라는 것을 알고 바로 처리한다. 그리고 각각의 컴퓨터에서 MAC 주소 테이블을 관리하게 된다.

일반적으로 이더넷(Ethernet) 환경에서 가장 큰 특징 중에는 CSMA/CD라는 액세스 메소드(Access Method)를 이용한다.

허브(Hub)에서 문제점

<그림 7>은 CSMA/CD방식을 나타낸 것이다. 이는 하나의 통로를 여러 패킷이 동시에 사용하면서 생길 수 있는 충돌을 예방하기 위한 통신방식이다. 패킷을 전송하기 전에 이미 통로를 사용하고 있는 패킷이 있는지 확인한 뒤에 먼저 사용중인 패킷의 전송이 끝난 뒤에 새 패킷을 전달하는 방식으로 패킷 간의 충돌을 예방한다.

그럼, 동시에 둘 이상의 곳에서 사용중인 패킷이 없음을 확인하고 동시에 패킷을 전송하면 어떻게 될까? 당연히 각 패킷이 충돌을 하게 되는데 이러한 현상을 콜리전(Collision)이라고 한다. 콜리전은 CSMA/CD 방식에서 필연적으로 발생하며 콜리전이 발생할 수 있는 범위를 콜리전 도메인이라고 부른다.

보통 허브는 하나의 콜리전 도메인이라서 한 순간에 한 호스트만 통신한다. 다른 PC들은 통신이 끝나기를 기다려야 한다. 허브를 사용하면 네트워크가 느려진다고 느껴지는 이유가 바로 여기에 있으며, 이는 허브가 가지고 있는 원천적인 한계이다.

일반적으로 허브는 셰어드(Shared)방식을 사용한다. 이 말은 <그림 8>처럼 100Mbps 허브면 100Mbps를 가지고 모든 연결된 컴퓨터가 나누어 사용하게 된다는 뜻이다. 예를 들어 그림에서 허브에 연결된 세 대의 컴퓨터와 한 대의 서버가 100Mbps 허브에 연결되어 있다면 일반적을 25Mbps정도의 속도를 나누어 쓰고 있다고 생각하면 된다.

그런데 이 네 대 중 먼저 서버와 컴퓨터간에 80Mbps를 점유하여 사용하던 컴퓨터가 있다면 이 컴퓨터의 네트워크가 끝날 때까지 남은 20Mbps로 나머지 컴퓨터들이 사용해야 한다. 그렇기 때문에 누군가 대용량의 파일을 다운로드 받고 있으면 다른 컴퓨터의 네트워크 속도가 저하되기도 하는 것이다.

허브의 콜리전 발생 상태 확인하기
사용중인 허브에 얼마나 많은 콜리전이 발생하는지 가장 빠르게 확인할 수 있는 방법은 허브에 달린 LED를 확인하는 것이다. 허브의 LED 중에는 콜리전 상태를 나타내는 LED가 있는데, 콜리전이 많으면 이 LED가 많이 깜박인다.

콜리전 발생으로 생기는 네트워크 속도 저하를 줄이기 위해 사용할 수 있는 방법이 바로 뒤에서 설명하게 될 스위치이다. 만약 자신의 회사에서 허브를 사용하고 있는데 속도 때문에 골치라면 허브를 스위치로 교체하여 문제를 줄일 수 있다.

Star형 토플로지

스위치와 허브의 모양은 거의 비슷하다. 실제로 보통 사람들이라면 겉모습만 보고 둘을 구분하기 조차 어려운 일이다. 스위치와 허브의 가장 큰 차이는 MAC 주소 관리 능력이다. 스위치는 MAC 주소 테이블을 가지고 있기 때문이다.

<그림 9>에서처럼 허브는 프레임을 전송하기 위해 브로드캐스트를 날리고 관련 ARP 테이블을 컴퓨터에서 관리를 하게 한다. 따라서 컴퓨터에서 통신할 상대편의 MAC 주소가 없다면 매번 날려서 상대편 MAC 주소를 인지하는 수 밖에 없다. 반면 스위치는 테이블에 MAC을 획득하기 위해 플로딩(Flooding)이라는 과정을 거친다. 이렇게 획득한 MAC 주소를 일정한 버퍼에 담아 두었다가 목적지의 MAC 주소가 없을 때 사용한다.

허브의 동작

따라서 이렇게 함으로써 CSMA/CD의 문제점인 프레임충돌(콜리전)을 줄일 수 있는 장점이 있다. 또한 불필요한 브로드캐스트를 감소시킬 수 있다. 더불어 스위치에서 VLAN을 이용하여 브로드캐스트 프레임으로 인한 성능저하도 줄일 수 있다.

IP 충돌 발생시 스위치에서 해당 포트를 알아내는 방법
센터에서 근무를 하다 보면 IP 충돌과 관련된 문제가 흔히 발생한다. 필자가 현재 일하고 있는 곳에서는 DHCP에 의해서 IP를 받아 오도록 되어 있는데, 간혹 외부인을 방문해서 임의로 IP를 설정하여 문제가 발생하는 경우가 있다(독자들 중에도 이런 경험이 있을 것이다). 이런 경우 임의로 IP를 설정한 유저를 찾으면 되는데 어떻게 찾을지는 난감하다.

시스코의 스위치를 기준으로 임의로 IP 주소를 설정한 포트를 찾는 방법에 대해 알아보자. 일반적으로 IP가 충돌하면 시스코 스위치가 다음과 같이 메시지를 표시한다. 시스코 스위치에서는 IP 충돌 발생 시 duplicate address라는 메시지를 보여준다.

%IP-4-DUPADDR: Duplicate address 192.168.0.1 on Ethernet1/0, sourced by 0000.5e00.0000

명령어 “sh arp”로 해당 IP를 확인한다.
Switch#show arp
Protocol Address Age (min) Hardware Addr Type Interface
Internet 192.168.0.2 34 0003.bab1.0000 ARPA Vlan1
Internet 192.168.0.1 163 0000.5e00.0000 ARPA Vlan1

이런 메시지가 표시되면 ‘192.168.0.1’이라는 IP를 사용하는 사람을 찾으면 된다. 그 MAC 주소가 0000.5e00.0000 이다.
여기까지 찾았다면 이 MAC이 어느 포트에서 올라오는지를 확인하면 된다. ‘sh mac-address-table’ 이라는 명령어를 이용하면 간단히 해당 포트를 찾을 수 있다.

Switch#sh mac-address-table
Mac Address Table
-------------------------------------------
Vlan Mac Address Type Ports
---- ----------- -------- -----
1 0000.0c07.ac34 DYNAMIC Fa0/1
1 0000.5e00.0101 DYNAMIC Fa0/2
1 0000.f091.cfac DYNAMIC Fa0/3
1 0000.5e00.0000 DYNAMIC Fa0/8

간단히 해당 MAC 포트에 올라오는 포트가 Fa0/8이라는 것을 알 수 있다. 관련하여 포트를 disable 하던지 아니면 IP변경을 요청하면 된다.

CSMA/CD방식

VLAN(Virtual LAN)이란 한마디로 논리적으로 브로드캐스트 도메인을 나누는 것이다. 하드디스크에서 파티션을 나누어 하나의 하드디스크를 둘 이상으로 나누어 사용하는 것과 비슷하다고 생각하면 쉽게 이해될 것이다. VLAN도 물리적으로 하나의 장비에서 통신을 해야 하는 여러 그룹으로 논리적으로 묶어서 나누는 것이다. 이렇게 나눠진 VLAN끼리는 서로 브로드캐스트를 보내지 않는다.

Hub의 트래픽 처리

왜 이렇게 복잡한 작업을 해야 할까? 앞에서 설명한 허브를 생각해보자. <그림 10>처럼 100 포트 허브가 있다고 생각해보자. A와 B가 통신하려면 서로의 MAC 주소를 확인하기 위해 브로드캐스트를 보내야 할 것이다. 그런데 연결된 컴퓨터가 많다 보니 A와 B가 통신하려면 100개의 브로드캐스트를 날려야 한다.

그러면 100개의 호스트에서 각각 브로트케스트를 날리면 어떻게 되겠는가? 각각 컴퓨터가 모두 통신한다고 생각하면 10,000개(100 대의 컴퓨터 × 100 개의 브로드캐스트)의 어머어머한 브로트케스트가 발생하는 셈이다. 그런데 호스트가 100개가 아니라 5,000개면 어떻게 될까? 호스트의 수가 늘면 늘수록 네트워크 자원의 소모가 많아져 네트워크의 속도를 저하시키는 원인이 될 것이다.

이런 문제를 해결하기 위해서 나온 것이 VLAN이다. <그림 11>를 보면 스위치는 물리적으로 한 대인데 VLAN1과 VLAN2로 나누어 Port1, 6, 5끼리 통신을 하고 Port2, 3, 4번끼리 통신을 한다. 이렇게 함으로 VLAN1에 포함되어 있는 패킷이 VLAN2로 넘어가지 않도록 한다. 그림처럼 몇 대 되지 않는 환경에서 VLAN을 나눌 필요가 없겠지만, 호스트의 수가 많을 경우 사용 그룹별로 묶어서 VLAN을 설정해 주는 것 만으로도 네트워크의 속도를 높일 수 있다.

이렇게 VLAN을 나누는 기준은 몇 가지가 있다. MAC이나 Port등으로 VLAN을 나눌 수 있지만, Port VLAN을 가장 많이 사용된다. 브로드캐스트 감소로 네트워크 트래픽 또한 감소되며 그 이외에도 VLAN은 보안 측면에서도 중요한 역할을 한다. 예전에 ‘모 아파트에 진출한 통신회사에서 기존의 xDSL방식이 아닌 이더넷 방식으로 서비스를 제공하였다’는 내용의 뉴스가 보도된 적이 있다.

그런데 이 아파트 사람들의 윈도우에서 ‘네트워크 환경’을 클릭하면 이웃집 컴퓨터까지 다 보여주어서 개인정보가 유출된다는 내용의 뉴스였다. 이를 해결할 수 있었던 것이 VLAN이다. 간혹 같은 장비에 PC나 서버를 연결하였는데 링크나 케이블은 정상인데도 불구하고 통신이 되지 않는다면 우선 장비에서 VLAN이 설정되었는지를 확인해야 한다. 앞서 설명한 것처럼 동일 VLAN에서는 통신이 가능하지만 서로 다른 장비에서 같은 VLAN끼리는 통신이 되지 않는다.

이처럼 VLAN은 브로트케스트를 감소시키는 것은 물론 보안에도 중요한 역할을 한다. VLAN 생성 및 삭제, 포트 할당하는 방법은 다음과(시스코 스위치 기준) 같다. 일반적으로 벤더(원천업체)마다 그 방법은 다르다.

- VLAN 생성
C6509(config)#vlan 2 <- VLAN 2 생성
- 해당 인터페이스 VLAN설정
C6509(config)#interface gi1/1
C6509(config-if)#switchport <- Switch Port로 변경
C6509(config-if)#switchport mode access <- access 포트로 지정
C6509(config-if)#switchport access vlan 2 <- vlan 2 에 할당 설정
C6509#sh vlan id 2 <- VLAN 확인방법
VLAN Name Status Ports
2 VLAN2 active Gi1/1
- VLAN 삭제
C6509(config)#no vlan 2 <- VLAN2 삭제 (삭제 시에는 해당 VLAN에 할당된 인터페이스가 없어야 함)

브로드캐스트 스톰(Broadcast Storm) 해결하기
브로드캐스트가 자주 일어나면 이를 처리하기 위해 장비에 부하가 발생한다. 또 각 노드(사용자)에서의 처리가 실행되지 않아 네트워크 전체가 다운되기도 하는데 이런 경우를 브로드캐스트 스톰(Broadcast storm)이라고 말한다. 브로드캐스트 스톰은 프로토콜의 버전 차이에 의해서 발생하는 경우가 많다.

TCP/IP에서는 4.3 BSD와 4.2 BSD의 혼재, Appletalk Phase I과 Phase II의 혼재 등이 그 예이다. 브로드캐스트의 패킷은 보낼 곳의 주소를 가지고 있다. 때문에 네트워크 장애가 브로드캐스트에 의한 것인지 아닌지는 보통 스니퍼와 같은 분석 툴을 이용하여 패킷의 어드레스를 조사해 보면 알 수 있다.

최근에 나오는 스위치들은 패킷을 분류하여 컨트롤할 수 있는 기능이 있으며, 액세스 단의 시스코 스위치는 ‘storm-control’ 이라는 명령을 이용해 포트에 과도한 브로드캐스트가 발생하면 자동 다운되도록 설정할 수 있다.

다음은 Strorm-control을 적용한 것으로 70%가 넘는 브로드캐스트가 해당포트에 발생하면 자동으로 포트가 다운되도록 설정한 예이다. 참고로 해당 포트 enable(활성화)은 자동으로 되지 않고, 관리자가 직접 입력 해야 한다. 옵션으로 포트를 다운시킬 수도 있지만, Trap을 보내어 로그 서버나 로그에서 확인할 수도 있다.

Switch(config-if)#storm-control broadcast (multicast, unicast) level 70 (퍼센트)
Switch(config-if)#storm-control action shutdown (trap)

네트워크에서 가장 빈번하게 발생하는 문제 중 하나는 프레임이나 패킷에서 에러가 발생하는 경우이다. 이때 발생한 에러를 스위치에서 확인하는 방법과 에러의 종류들에 대해 알아보자. 다음은 스위치에서 Show interface를 확인 하는 명령어를 실행 한 것이다.

Switch#show interface fa0/1
FastEthernet0/1 is up, line protocol is up (connected)
Hardware is Fast Ethernet, address is 000d.bdf0.8401 (bia 000d.bdf0.0000)
Full-duplex, 100Mb/s
----중략------
①3684426280 packets input, 488947651 bytes, 0 no buffer
Received 82551896 broadcasts (0 multicast)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 20 ignored
0 watchdog, 40251954 multicast, 0 pause input
0 input packets with dribble condition detected
②3120267351 packets output, 124174218 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 PAUSE output
0 output buffer failures, 0 output buffers swapped out

Show Interface 명령은 간단한 명령어지만 많은 내용을 포함하고 있다. 아마도 하나의 명령어로 많은 부분을 파악할 수 있을 것이다. ①부분은 서버에서 스위치로 입력된 패킷을 나타내고, ②부분은 스위치에서 서버나 기타 접속되어 있는 장비로 나가는 패킷의 개수다. 일반적으로 서버나 장비가 정상적으로 연결되면 FastEthernet0/1 is up, line protocol is up 인터페이스와 라인프로토콜이 모두가 UP으로 되어 있다.

정상적인 패킷의 경우는 64k이상 ~ 1,518k미만이 정상적이다. 이 이외의 패킷이 들어오면 스위치에서는 해당 패킷을 파기하는데 runts 64k 미만의 패킷 수이고, giants는 1500k 이상 패킷을 말한다. 이런 패킷들은 대부분 폐기한다. Throttles는 처리범위 이상으로 유입되는 패킷의 개수를 말한다.

그리고 input error는 소스에서 만들어진 패킷이 불량인 경우인데, 이 경우에는 연결된 서버의 랜 카드나 장비가 불량인 경우가 많다. 그리고 CRC나 Frame은 프레임에서의 에러를 나타내고 위에서 설명한 Duplex나 회선에 문제가 발생할 때 관련 카운터가 증가한다.

장비는 버퍼를 가지고 있는데, 버퍼를 초과하는 패킷이 들어오면 Overrun의 카운터가 증가한다. Ignored는 버퍼에서 처리 못하는 패킷을 폐기할 때 발생한다.

Output error가 발생할 때는 해당 스위치가 에러가 발생할 경우가 많다. Duplex 모드 등 이상이 없는데도 에러가 증가한다면 해당장비를 교체하는 것이 현명하다. Collisions은 앞서 설명한 부분이라 생략하겠다. interface resets의 경우에는 해당 포트가 리셋 될 때 인데, 보통 과도한 패킷이 들어오거나 하드웨어가 불량일 경우 발생한다.

Babbles 1518 바이트 이상의 프레임이며 점보프레임과 같은 의미이다. late collision은 CSMA/CD에서 규정한 시간 내에 프레임을 전송하지 못하고 전송이 지연되는 것을 의미한다. 일반적으로 UTP케이블의 사용길이는 100m데, 이것보다 긴 케이블을 사용하거나, 다음에 설명할 듀플렉스가 안 맞을 경우 발생한다.

스위치와 서버를 연결한 뒤에 ping이 빠지거나, 속도가 느려질 경우
앞에서 ‘Full-duplex, 100Mb/s’ 부분은 듀플렉스 모드와 스피드를 나타낸다. 듀플렉스 모드가 mismatch일 때는 CRC 에러나 Runts 패킷이 많이 발생한다. 서버나 기타 통신장비가 스위치와 통신할 때 에러가 발생하는 원인 중 가장 큰 비중을 차지하는 것이 바로 이 듀플렉스 문제이다.

듀플렉스는 시스템이 서로 통신할 때 송신과 수신이 어떤 형식으로 이루어 지는 지에 대한 일종의 모드이다. 정보통신학개론 등의 책에 빠지지 않고 등장하는 메뉴인 듀플렉스는 단 방향 통신(Simplex), 반 이중방식(Half Duplex), 전 이중방식 (Full Duplex)의 세 가지 방식으로 나뉜다.

아주 오래된 장비라면 반 이중방식을 최근에 설비된 장비라면 대부분 전 이중방식이 적용되어 있다고 보면 된다. 전 이중방식으로 설비된 100M장비의 Throughput은 200Mbps가 된다.

듀플렉스는 통신하는 기기 즉 서버와 같은 시스템의 네트워크 인터페이스, 스위치 포트들 또는 스위치 포트와 라우터 인터페이스간에 서로 일치하도록 설정해야 한다. 100/10 랜 카드와 스위치의 경우 상호 오토네고네션(auto-negotiation)을 수행하여 속도와 듀플렉스 모드가 자동적으로 설정된다.

반면 장비간 오토네고네션 프로토콜의 차이로 인해 제대로 연결되지 않을 수 있다. 따라서, 100Mbps 속도를 지원하고 전 이중방식을 지원하는 장비들 간에는 오토네고네션 기능을 disable하고 100Mbps-Full Duplex로 fix하여 운영하는 것이 좋다. 듀플렉스 모드에는 auto, ull, half모드가 있으며, 속도는 지원하는 포트에 따라 10~1000M가 있다. 다음은 시스코 스위치에서 듀플렉스 및 스피드를 포트에 설정하는 방법이다.

Switch(config-if)#speed 100
Switch (config-if)#duplex full

이미 알아본 것처럼 VLAN이란 하나의 스위치를 둘 이상의 스위치인 것처럼 논리적으로 분할하여 사용하는 것이다. 그렇다면 둘 이상의 스위치에 서로 같은 VLAN을 설정하여 공유해야 할 때는 어떻게 하면 될까? 이번에는 서로 다른 스위치의 VLAN을 동일하게 설정하여 연결하는 방법에 대해 알아보자.

서로 다른 스위치의 VLAN이 통신하도록 설정하는 방법에는 두 가지가 있다. 하나는 라우팅이고 다른 하나가 트렁킹(Trunking)이다. 라우팅에 관해서는 3부에서 자세히 다루고 있기 때문에 여기에서는 생략한다. <그림 12>와 같은 네트워크가 있다면 스위치 1과 스위치 2에 각각 설정되어 있는 VLAN1을 링크하고 스위치 1과 2에 설정되어 있는 VLAN2를 링크로 연결해 주면 된다.

간단한 듯 보이지만 사실 이 방법은 아주 불편할 수도 있다. 예를 들어 서로 다른 두 개의 스위치에 설정되어 있는 VLAN의 종류가 100 가지라면 100 개의 링크가 필요한 탓이다. 이렇게 되면 링크의 수가 너무 많아지고 또 포트 낭비도 심해진다.

이런 문제를 해결하기 위해 착안된 것이 바로 링크를 통해 VLAN 정보를 주고 받는 VLAN 트렁킹이다. <그림 12>를 보면 스위치1과 2간에 링크는 하나지만 그 링크를 통해서 VLAN 정보가 넘어다니며 각각의 VLAN들이 통신할 수 있게 된다.

이처럼 VLAN 정보를 송수신할 수 있는 포트를 트렁크(Trunk)라고 부른다. 또 <그림 13>와 같이 트렁크 포트를 통해 통신하기 위해 VLAN 정보를 추가하는 것을 태깅(Tagging)이라고 한다.

태깅을 하기 위해 ISL(Inter Switch Link)와 IEEE 802.1q 방식을 주로 사용한다 있다. ISL는 시스코에서만 사용하는 것이고, IEEE 802.1q는 국제표준이다. IEEE 802.1Q는 tag-based VLAN이 Bridge를 거쳐가는 프레임의 vlan membership을 확인하기 위해 MAC header 내에 특별한 태그를 이용한다.

이 태그는 VLAN과 QoS priority의 식별에 사용된다. Vlan ID는 특정 VLAN과 프레임을 결합하여 네트워크를 거쳐가는 프레임에 대한 정보를 스위치에 제공한다.

태그드 프레임(Tagged frame)은 언태그드 프레임(Untagged frame)보다 4byte가 더 길고, 이는 2byte의 TPID(Tag Protocol Identifier)와 2byte의 TCI(Tag Control Information)을 포함한다. 이에 반해 ISL은 데이터 프레임의 양쪽 끝에 각각 26 octet의 ISL header와 4 octet의 CRC를 더한다. 이를 더블 태깅(double-tagging) 혹은 투 레벨 태깅 인캡슐레이션(two-level tagging encapsulation)이라고 한다. 다음은 시스코 스위치에서의 트렁크 설정에 대한 설명이다.

Switch(config)#interface Fa0/1
Switch(config-if)#switchport trunk encapsulation dot1q or isl <- Encapsulation방식 설정
Switch(config-if)#switchport mode trunk <- 해당포트 Trunk 포트로 설정
Switch(config-if)#switchport trunk allowed vlan 10,20 <- 트렁크포트로 허용할 VLAN

Switch#show interface trunk <- 트렁크포트 확인 시 명령어
Port Vlans allowed on trunk
Fa0/1 10,20

네이티브 VLAN이 서로 다를 경우에 문제점
모든 스위치에는 네이티브(Native) VLAN 이라는 것이 있다. 트렁크 포트나 액세스 포트를 제거 했을 때 돌아가는 VLAN을 네이티브 VLAN이라 한다. 일반적으로 시스코 스위치에서는 VLAN 1이 네이티브 VLAN이다. 제품을 구입해서 콘솔에 연결했을 때 최초 VLAN이 네이티브 VLAN인 것을 알 수 있다.

앞서 설명한 것처럼 802.1q의 경우 트렁크 구간이 기본적으로 VLAN 1로 인식되므로, 트렁크 구간으로 특정한 VLAN ID가 설정되어 있지 않은 데이터(Untagged Frame)가 들어오면 자동으로 VLAN 1로 인식된다. 이렇게 해서 두 스위치간의 트렁킹을 설정했을 때, 언태그드 프레임을 처리하기 위해 802.1에서는 네이티브 VLAN으로 처리하는 것이다.

반면에 ISL은 네이티브 VLAN이란 개념 자체를 가지지 않는다. 다시 말해 ISL에서는 네이티브 VLAN이 넘어가지 않는다.
앞에 설명한 것처럼 ISL은 네이티브 VLAN이 넘어가지 않는다. 802.1q에서만 네이티브 VLAN넘어간다.

일반적으로 VLAN1이 네이티브 VLAN인데 만약 한 스위치는 VLAN1이 네이티브이고, 다른 스위치는 VLAN2가 네이티브라고 가정해보자. 한마디로 네이티브 VLAN이 서로 다를 경우에는 어떻게 될까? 당연히 네이티브 VLAN이 넘어가지 않고 미스매치(mismatch)되기 때문에 해당 로그를 남긴다.

이럴 경우에는 네이티브 VLAN을 변경해 주어야 한다. CatOS에서는 트렁크를 설정하기 전에 set vlan으로 네이티브 VLAN을 설정한다. IOS에서는 switch port trunk native vlan 커맨드로 네이티브 VLAN을 설정한다.

스위치를 사용하면서 가장 흔하게 발생하는 문제 중 하나는 루프(loop)이다. 루프는 단일경로에서는 거의 발생하지 않으며 이중화 구성 등 복잡한 구조의 네트워크에서 주로 발생한다.

<그림 14>의 왼쪽 그림은 단일 경로로 연결된 네트워크이다. 사용자가 인터넷을 사용하면서 경유하는 경로는 ‘스위치 2->스위치1->인터넷’ 순으로 가는 방법뿐이다. 이처럼 단일 경로로 된 상태에서 길을 일어버릴 리 없다. 반면에 단일 경로는 각 장치를 연결하는 경로 중 하나가 단절되면 인터넷도 끊긴다는 치명적인 약점이 있다.

이런 문제를 해결하기 위해 고안된 것이 바로 그림의 오른쪽에 표시된 것과 같은 이중화 경로이다. 그림과 같이 연결되어 있는 경우라면 스위치 1과 3을 연결하는 경로가 단절될 경우 스위치 2와 3을 통해 인터넷에 접속할 수 있어 인터넷 고립의 문제를 해소할 수 있다.

하지만 이 방법에도 문제가 없는 것은 아니다. 같은 브로드캐스트 도메인 내에서 그림과 같은 형태의 이중화 경로로 구성하면 루핑이 발생하는 탓이다.

<그림 15>과 같은 구성에서 사용자가 만약 브로드캐스트 프레임을 스위치1과 2으로 보낼 경우 스위치2는 스위치1로, 스위치1은 다시 스위치2로 재전송하게 된다. 이런 동작이 계속 반복되면서 각 스위치들이 브로드캐스트를 계속 보내기만 하는 루프 현상이 발생하고 결국 브로드캐스트 스톰으로 이어지기까지 한다.

브로드캐스트 스톰이 발생하면 일반적으로 스위치가 다운되거나 시스템에 지나친 부하가 발생하여 스위치가 다운되는 것이다. 또한 잘못된 MAC 테이블이 생겨서 네트워크 상의 통신에도 오류가 발생한다. 이런 루핑과 관련한 일련의 문제들을 해결하기 위해 사용하는 것이 바로 지금부터 알아볼 스패닝 트리(Spanning-Tree)이다.

스패닝 트리란 <그림 16>처럼 이중화로 연결된 링크 중에 하나에는 트래픽이 흐르지 못하도록 막는 방법이다. 이처럼 두 경로 중 하나를 차단하여 루핑을 방지하고 트래픽이 흐르고 있던 경로에 문제가 생겼을 때 막았던 경로를 열어서 통신할 수 있도록 설계된 기술을 STP(Spanning Tree Protocol)이라고 부른다.

시스코 스위치에서 스패닝 트리를 Enable 하려면 다음과 같은 명령어를 입력한다.

Switch(config)#spanning-tree vlan <번호>
Switch(config)#spanning-tree vlan <번호> priority [0~61440] VLAN 우선순위 일반적으로 root는 mac으로 결정하나 priority를 주어 root port를 지정할 수 있다.

네트워크의 장애 유형은 장비의 전원불량, 네트워크 회선이나 케이블 문제, 장비 문제, 라우팅 문제 등 아주 다양하다. 하지만 필자의 경험을 바탕으로 생각해보면 대부분의 문제들 중 90% 정도는 UTP케이블이나 사용자 애플리케이션에서 발생한다. 당연히 괜찮을 것 같은 곳에서 문제가 발생할 수 있다는 이야기다. 약간의 주의를 기울이면 대형장애를 예방할 수 있음을 잊지 말자. @

도움주신 분 인네트 : 배원식님, 윤성업님, 최재혁님

참고자료
시스코 홈페이지 http://www.cisco.com
네이버 네트워크 전문가 따라잡기 http://cafe.naver.com/neteg
네이버 백과 사전 http://100.naver.com
차순태님 블로그 http://blog.naver.com/lemonaroma98

* 이 기사는 ZDNet Korea의 제휴매체인 마이크로소프트웨어에 게재된 내용입니다.

출처 : http://www.zdnet.co.kr/news/news_view.asp?artice_id=00000039160806

백본스위치(backbone switch)란?

JAESOO — Mon, 15 Jun 2015 20:09:40 +0000

구성도의 그림은 개념도이며, 이렇게 개념을 세우고 설계를 시작한다.

백본과 백본스위치는 의미상 같다고 볼수 있다.

백본스위치는 네트워크의 중심이므로 라우터는 아니고, 허브도 아니고, 주로 L3 스위치가 그런 역할을 한다.

그러나, 꼭 L3스위치가 백본스위치는 아니다.

백본과 백본스위치는 네트워크의 중심에 있으며, 모든 데이타가 거쳐서 지나가는 곳이기 때문에, 스위치를 선으로 표시하는 경향이 있다.

라우터도 전에는 백본역활을 하였는데, 현재는 거의 하지 않는다. 이유는 L3 스위치 때문이다. 처리속도도 빠르고, 데이터 변환(LAN -> WAN사용시)을 할 필요가 없기 때문이다.

개념도상의 네트워크 구조는,
맨 상위에 라우터,
그 다음에 백본스위치(주로 L3스위치)에 각종 허브나 L2스위치를 연결, 또는 서버도 연결한다.
그다음이 각종 허브나 L2스위치가 위치한다.
맨마지막이 PC, 프린터 등과 같은 단말이다.

네트워크 구조 개념도

백본스위치
백본이란 WAN으로 연결되기 위한 하나의 노드 또는 여러 노드들의 중심이다. 한 네트워크에서 중심에 위치하며 모든 패킷이 지나간다. 이와 같은 역할을 하는 장비를 백본스위치라 한다.
백본스위치는 많은 트래픽을 처리해야 하므로 기가급 장비를 많이 사용한다.

이중화
백본 스위치는 방화벽, 웍그룹 스위치 및 각종 서버가 접속되는 핵심 영역이므로 고가용, 고성능, 고확장성이 확보되는 기가급 백본 스위치를 도입하여 병목 구간의 대규모 트래픽을 처리할 수 있도록 구성한다. 또한 백본 스위치 이중화하여 안정성을 확보하여 무 중단 시스템 구축한다.

HSRP 프로토콜을 사용하여 장비 이중화 구성을 한다.

HSRP란 Active 기가비트 백본스위치의 장애시 Standby 기가비트 백본 스위치가 LAN상의 서비스 중단 없이 해당 라우팅을 자동 인계하는 라우팅 프로토콜이다.
HSRP는 하나의 백본스위치에서 다른 하나의 백본스위치를 모니터링하여 장비의 장애시 동일한 기능을 백업 받아 동작한다.
Hot Swap 기능에 의하여 On-Line상에서 모듈의 추가 및 교체가 가능하다.
장비의 주요부분 이중화로 운영 중 단일 장비의 교체 작업이나 장애로 인하여 전체 시스템의 가동이 중지되지 않는다.

VLAN
백본 스위치를 통해 구성된 각 층별 또는 건물별 등 LAN 노드간 논리적 세그먼트를 그룹화하여 주요 서버의 데이터 처리 요구량에 따라 논리적 W/G를 형성하도록 하고, 네트워크 트래픽 관리 및 튜닝을 통해 전체 네트워크의 성능을 향상시키도록 구성한다.

VLAN이란 현재의 네트워크 자원을 그대로 유지한 상태에서 물리적인 구성이 아닌 논리적 구성을 통하여 시스템 성능을 향상시키기 위한 개념이다.
이는 사용자별 또는 서버 성능별 그룹화를 하여 한 그룹에서 발생되는 트래픽은 타 그룹에 영향을 끼치지 않는 구조로 구현하여 불필요한 트래픽을 해소시킨다.
각 VLAN은 백본 스위치와 이중화 구성을 하여 한 장비의 장애시에도 원활한 통신이 되도록 설계한다.
건물별, 층별로 VLAN을 설정하여 네트워크 장애를 최소화한다.

장비선택
대용량 데이터의 증가에 따른 병목 구간 트래픽을 처리할 수 있도록 충분한 성능을 확보한 장비를 적절히 선택한다.

워크그룹 스위치
웍그룹은 소규모 작업그룹을 의미한다. 다시 말해 작은 회사 또는 한 학급 정도의 규모가 작고 허브나 스위치만으로도 통신이 가능한 그룹의 노드를 모아 놓은 장비가 웍그룹 스위치이고 다수의 웍그룹 스위치 노드가 모이는 곳이 백본 스위치이다.

※ 출처1 : http://www.mavericksys.co.kr/
※ 출처2 : http://blog.naver.com/nds239/10029215369

※ 참조자료
1. 백본 스위치 뭐가 좋은가? A: cisco > nortel (가격대 성능비 nortel > cisco)
http://kin.naver.com/detail/detail.php?d1id=1&dir_id=102&eid=GWlU+9p/OaXz+ptpYrNVvvL9TT5+UHyX&qb=uem6uyC9usCnxKE=&pid=fKRhNloi5T8sscLvkvwsss--264298&sid=ZiDe1OSsv0gAADSZiccAAAA6

출처 : http://willyoppa.tistory.com/1171684603

Cisco L3 이중화 - 2. 장애 시나리오 및 테스트

JAESOO — Mon, 15 Jun 2015 20:07:28 +0000

● L3 장애 시나리오 작성
- 본 문서는 장애 시나리오 발견시 지속적으로 업데이트 예정

● 시나리오 구성도
- L3에는 두개의 VLAN 설정(시리얼대역, 서비스대역)
- L2 스위치는 같은 VLAN으로 설정 (서비스대역)
- L3간에는 HA통신(VLAN1, VLAN10)을 위해 Trunk로 연결
- Loop 방지하기 위해 STP 설정(Active에 root Primary로 설정, Standby에 root Secondary 설정)
- VLAN1 : Active - 10.10.10.2, Standby - 10.10.10.3
- VLAN10 : Active - 172.16.1.2, Standby - 172.16.1.3

● 장애 시나리오
1. 1번 라인 장애
2. 2번 라인 장애
3. 3번 라인 장애
4. Active 장비 장애

● 장애 해결 방안
1. 장애1,2,3에 대해서는 한 라인이라도 장애 발생시 Active->Standby로 장비 이전
2. 장애4번은 Active->Standby로 장비 이전

● L3 Config 작성
1. HSRP
- Active Config
- interface Vlan1 -> 테스트에서는 fa1/0
- ip address 10.10.10.2 255.255.255.0
- standby 1 ip 10.10.10.1
- standby 1 priority 120
- standby 1 track FastEthernet1/0 20
- standby 1 track FastEthernet1/1 20
- standby 1 track FastEthernet1/2 20
- standby 1 authentication cloud

- interface Vlan10 -> 테스트에서는 fa1/1, fa1/2
- ip address 172.16.1.2 255.255.255.0
- standby 10 ip 172.16.1.1
- standby 10 priority 120
- standby 10 track FastEthernet1/0 20
- standby 10 track FastEthernet1/1 20
- standby 10 track FastEthernet1/2 20
- standby 10 authentication cloud

- Standby Config
- interface Vlan1 -> 테스트에서는 fa1/0
- ip address 10.10.10.3 255.255.255.0
- standby 1 ip 10.10.10.1
- standby 1 priority 110
- standby 1 authentication cloud

- interface Vlan10 -> 테스트에서는 fa1/1, fa1/2
- ip address 172.16.1.3 255.255.255.0
- standby 10 ip 172.16.1.1
- standby 10 priority 110
- standby 10 authentication cloud

2. STP
- Active Config
- spanning-tree vlan 1 root primary
- spanning-tree vlan 10 root primary

- Standby Config
- spanning-tree vlan 1 root secondary
- spanning-tree vlan 10 root secondary

3. HA 통신용 Trunk -> 테스트에서는 fa1/15
- Active, Standby Config
- interface fastEthernet 1/15
- switchport mode trunk
- switchport trunk encapsulation dot1q

● L2 Config
- SW01
- interface Vlan10 -> 모든포트 VLAN10
- Active Port : fa1/14
- Standby Port : fa1/15
- ip address 172.16.1.10 255.255.255.0
- ip default-gateway 172.16.1.1

- SW02
- interface Vlan10 -> 모든포트 VLAN10
- Active Port : fa1/14
- Standby Port : fa1/15
- ip address 172.16.1.20 255.255.255.0
- ip default-gateway 172.16.1.1

● HSRP 설정 정보
- Active

- Standby

● STP 설정 정보

- SW01 : Active가 살아있는 경우 fa1/15를 blocking

- SW02 : Active가 살아있는 경우 fa1/15를 blocking

● 장애 1,2,3 테스트
- Active에서 fa1/0, fa1/1, fa1/2 강제 셧다운
- 현재 Priority는 정상적으로 낮아지나 Active -> Standby로 넘어가지 않는 문제 확인 -> 버그인지 설정문제인지 확인 필요
- L2에서 STP설정 확인시 정상적으로 fa1/15가 blocking -> forwarding로 변경 확인
- L2에서 Gateway로 ping 가지 않음

● 장애4 테스트
- Active 장비 셧다운
- 동작 정상 -> STandby가 Active로 변경
- L2에서 Gateway로 ping 정상 -> port 올라오는 시간동안은 ping이 빠지는것 확인

● HSRP와 STP는 별도로 세팅되고 운영된다.
- HSRP에서 Active -> Standby로 넘어갈시 STP는 Active 장비가 셧다운되지 않는 이상 넘어가지 않는다.
- 1번 라인에 장애가 발생할 경우 HSRP의 Active -> Standby로 넘어가지만 STP는 문제가 없으므로 L2단에서는 기존 Active로 패킷이 넘어간뒤
다시 Standby로 패킷이 넘어가는 형태가 된다.

● 현재 GNS3로 테스트하는데에는 버그가 있을수있고 config가 정상적으로 작동안할수도 있기때문에
기본적인 테스트만 가능해보인다.
추후 장비가 입고된뒤 실제로 HSRP 테스트를 진행해야 할듯하다.

출처 : http://lovevirus133.tistory.com/147

[White Paper] 업무연속성과 해재복구 계획 수립

JAESOO — Mon, 15 Jun 2015 20:00:04 +0000

1. 서 론

재해복구(Disaster Recovery) 및 업무연속성계획(Business Continuity Plan) 수립이 새로운 주제는 아니다. 두 가지 모두 지난 수년 동안 인구에 회자된 것들이다. 그러나, 그만큼 널리 구현되지는 못했고, 기존의 재해복구나 업무연속성계획들이란 대부분 협의의 개념들이었다. 뉴욕의 어느 금융회사 관계자는 이렇게 말했다. “우리는 9·11 테러 이전에도 업무연속성계획을 세워두고 있었다. 그 계획에는 딜러들을 런던으로 보내 뉴욕에 있는 것처럼 일할 수 있게 하는 것도 있었다. 그러나, 모든 공항이 폐쇄될 줄 누가 알았겠는가?”
이 글에서 말하는 “비상계획”은 재해복구와 업무연속성계획이 결합된 것이다. 네트워크 관리자의 입장에서 보면, 효과적인 비상계획의 수립은 네트워크 기능이 비즈니스에 이익이 됨을 보여주는 대단히 훌륭한 방안이다. 이 글은 네트워크 관리자들이 성공적인 비상계획을 수립할 수 있도록 해주는 프레임워크를 제공하기 위한 것이다.
이 프레임워크는 비상계획에 필요한 정보기술(IT) 부문을 전반적으로 다루면서, 구체적으로는 비상계획의 네트워크 요소에 초점을 맞춘 것이다. 그리고 규모나 내용에 관계없이 모든 기업들에게 실질적으로 도움이 되는 프레임워크를 제공하려고 한다.
이 글에서는 “재해복구” 및 “업무연속성”이라는 용어가 갖는 일반적인 특징뿐만 아니라, 기업의 비상계획에 필요한 다양한 솔루션을 구성하는 주요 기술과 기능 및 프로세스에 대해서도 부분적으로 거론한다(원문에는 주요 기술과 기능 및 프로세스에 대한 논의가 포함되어 있으나, 본지에서는 지면 관계상 기술과 기능 부분은 생략하고 프로세스 부분만을 게재함 - 편집자주).
또한 자금 확보에 관해서도 다루면서 특히, IT 부서가 이 문제에 관해 비즈니스 결정권자와 어떻게 논의할 것인지에 대해 분석한다. 비상계획의 수립에는 반드시 충분한 자금이 IT에 지원되어야만 하고, 이를 제외한 비상계획이란 논의 자체가 무의미하기 때문이다.
이 글은 비상계획을 구현하는 방법을 다루는 추상적인 논문이 아니라, 이미 효과적인 비상계획을 구축했거나 현재 구축중인 여러 선도 업체들의 사례에서 발견한 사실들을 중심으로 기술하는 글이고자 한다. 일부 기업의 경우는 내부 정책상 이 글에서 회사 이름을 명시하지 않았음을 밝혀둔다.

2. 여러 가지 재해복구 방안

이 섹션에서는, 첫째 재해복구 솔루션 구현에 사용할 수 있는 여러 가지 방안을 살펴보고, 둘째 모든 비상계획의 핵심 내용인 ‘데이터 보호’에 대해 알아본다.
단, 데이터 보호에 관한 상세한 설명보다는 데이터 보호를 구현하는 좀더 통상적인 접근 방식의 일부를 설명하기로 한다.
그리고 아래 각각의 시나리오에서 열거한 장점들은 해당 비상 계획이 적절히 수립되었을 경우를 전제한 것이다. 예를 들면, 상시 대기 데이터센터(hot stand-by data center)를 구축하는 주요 목적은 재해 발생 시에도 회사가 자체 애플리케이션에 지속적으로 액세스할 수 있도록 하기 위한 것이다. 그러나, 적절한 비상계획이 수립되어 있지 않고 동일한 재해로 일차 및 백업 데이터센터가 오프라인화 된다면, 상시 대기 데이터센터란 무용지물이 되어 버린다.

◆ 시나리오 1 : 별도의 장소에 테이프 백업

이 경우는 회사가 주요 데이터베이스 컨텐츠를 정기적으로 테이프에 백업하는 것이다. 일일(daily) 백업이 일반적이며 백업 테이프는 차량으로 일정하게 떨어진 장소로 수송, 보존한다. 그리고 데이터센터에 재해가 발생한 경우, 이 백업 테이프를 다시 회사로 가져오는 것이다.
이 방식의 주된 장점은 간편하고 비용이 적게 든다는 것이다. 단점은 마지막 테이프 백업 이후에 생성된 데이터는 모두 손실되고, 또 경우에 따라서는 데이터센터가 수 일 동안 운영되지 못할 수도 있다는 것이다.

◆ 시나리오 2 : 일렉트로닉 볼팅(Vaulting)

이 시나리오는 차량을 사용하지 않는다는 점을 제외하고는 시나리오1과 유사하다. 이 시나리오에서는 회사가 WAN (Wide Area Network)을 사용하여 원격지로 주요 데이터베이스를 전송한다.
이 방식을 이용하는 회사는 대체로 시나리오1의 경우보다 데이터 백업을 더 자주 하며 매시간 업데이트가 일반적이다. 따라서, 시나리오1과 비교하여 시나리오2가 갖는 뚜렷한 장점은 손실되는 데이터가 훨씬 적다는 것이다. 그러나, 일반적으로 시나리오1보다 비용이 많이 들며, 재해의 영향을 받은 데이터센터의 비가동 시간도 줄이지 못한다는 단점이 있다.

◆ 시나리오 3 : 원격 디스크 미러링

이는 시나리오2와 유사하다. 그러나, 가장 큰 차이점은 이 방식을 이용하는 회사는 연속적으로 데이터를 업데이트 한다는 것이다. 따라서, 데이터 손실 가능성이 없다는 큰 장점이 있다. 그러나, 더 큰 용량의 WAN 링크가 요구되기 때문에 시나리오2보다 비용이 더 들고 데이터센터의 비가동 시간을 줄이지는 못한다는 단점은 마찬가지다.

◆ 시나리오 4 : 콜드 사이트(Cold Site) 구축

앞서 기술한 시나리오들에서는 재해에 영향을 받은 데이터센터가 무한 기간 동안 운영되지 않을 수도 있다. 그러나 이 시나리오는 데이터센터의 백업 용도로 콜드 사이트를 구축하는 것으로, 콜드 사이트는 비상계획이 발동된 후 장비를 설치하고 구성하는 곳이다.
이 시나리오는 앞의 다른 시나리오와 함께 사용할 수 있으며, 회사가 핵심 애플리케이션에 접근하지 못하는 시간을 최소화할 수 있는 것이 장점이다. 그러나, 추가 비용이 들고 복잡하다는 것이 단점이다.
제이디에드워즈(J.D. Edwards)사의 엔드리(Endry)는 이 방식과 관련한 복잡함에 대해 “콜드 사이트 방식을 선택하는 회사는 콜드 사이트의 장비에 관해 신중하게 계획을 수립해야 한다. 예를 들어 사양이 오래된 테이프 드라이브로 테이프를 백업한다면, 콜드 사이트에 테이프를 걸기 위해 동일한 종류의 드라이브를 급하게 구해야 하는 어려움을 겪게 될 수도 있을 것”이라고 말한다.

◆ 시나리오 5 : 완벽하게 이중화된 핫 사이트 (Hot-site)

이 시나리오는 업무연속성 솔루션으로 고려할 만한 좋은 방안이다. 이 시나리오는 적절한 애플리케이션 모두를 실행시킬 수 있는 메인프레임이나 서버가 원격지에 있다는 점에서 시나리오4와 다르다. 장점은 재해로 인해 데이터센터가 운영되지 못할 경우, 원격지의 핫 사이트가 아무런 영향을 받지 않고 운영 기능을 넘겨받을 수 있다는 점이다. 물론, 재해가 원격지의 핫 사이트에 영향을 미치지 않았다는 점을 전제로 한다. 단점은 비싸다는 것이다.

3. 비상계획의 핵심 요소

네트워크 전문가들이 적절한 비상계획 방안을 선택하기 위해서는 다음과 같은 질문을 고려할 필요가 있다.

질문 1

비즈니스에 매우 중요하면서, 재해로부터 보호해야 할 비즈니스 기능은
어떤 것들인가?

세계적인 회계법인 프라이스워터하우스쿠퍼스(Price-waterhouseCoopers)사의 브라운(Brown)은 간단히 답하기 어려운 질문이라고 한다. 그는 이렇게 부연 설명한다. “연속성을 유지해야 할 핵심 애플리케이션이 산업 부문별로 크게 다르다. 전문 서비스 부문에서는 원격 접속 및 이메일이 핵심 애플리케이션인데 반해, 제조 부문에서는 ERP시스템이 가장 핵심적인 애플리케이션이라 할 수 있다. 중요한 애플리케이션이 무엇인지에 대한 정보는 반드시 IT담당자가 아닌 해당 비즈니스 담당자로부터 얻어야 한다. 왜냐하면, 가치/비용이 애플리케이션의 잠재적 비가용성과 연관될 경우 비즈니스 담당자와 IT 담당자의 우선 순위는 달라지는 경우가 많기 때문이다.”
어바이어(Avaya)사의 미내시언(Minassian)은 단지 어떤 기능들이 비즈니스에 중요한 것인지를 아는 것만으로는 충분치 않다고 조언한다. 그는 “무엇이 비즈니스에 핵심적인지를 아는 것뿐만 아니라 그것이 재해 발생시 변경될 수도 있는지를 파악하는 것도 중요하다. 예를 들면, 예상 사용자들의 수나, 대응 시간 단축 여부 등이 그것이다. 이러한 것들을 알 수 있다면 BC/DR(Business Continuity / Disaster Recovery) 및 설계와 비용에 관한 접근 방식을 바꿀 수 있다”고 말한다.

질문 2

비즈니스의 각 요소별 보호 수준은 어떠한 것인가 예를 들면, 다음 날 바로 복
구해서 운영해야 하는 것인가?

아이서브(iSERV)사의 코커리(Corkery)는 질문 2와 관련된 문제들에 대해 이렇게 말한다. “1984년 나는 화재가 발생한 대형 통신 회사의 주요 데이터센터 복구에 참여했다. 건물은 물리적 피해를 입지 않았지만 전기 시스템을 다시 설치해야 했고 이 작업에 약 4주가 소요됐다. 우리는 모든 애플리케이션을 “핵심”과 “비핵심”으로 구분하고 핵심 애플리케이션만을 복구하기로 예정되어 있었지만, 4주가 흐르는 동안 모든 애플리케이션들이 비즈니스 사용자에게 중요해졌다. 결국, 우리는 분류 목록을 최대 허용 중단시간(Maximum Tolerable Outage) 기준으로 다시 작성했다. 그 일로 인해 우리는 무엇을 언제 해야 할 것인가 하는 필수 우선 순위 결정에 관해 배웠지만 결국 모든 것을 해야만 한다는 사실도 깨닫게 되었다.”

	질문 3	해당 솔루션은 어떤 유형의 재해에 대비하기 위한 것인가? (재해를 세 가지 유형으로 분류한 <표1> 참조)
	질문 4	어떤 솔루션이 사용 가능한가? 그 비용은 얼마인가?
	질문 5	비상계획 의사결정권이 누구에게 있는가? 보호 수준을 도입하기 위해 필요한 비용을 지불할 의사는 충분한가?

엔드리(Endry)는 자금에 대한 논의 없이 비상계획을 운운하는 것은 불가능하다고 생각한다. 그는 “많은 기업들이 이메일을 핵심적인 비즈니스 기능으로 파악하고 있다. 그렇다면 이메일 용량의 100%를 이중화할 것인지, 아니면 한동안은 용량을 줄여 운영할 것인지를 결정해야 한다. 그 결정에 따라 비용이 크게 달라질 수 있다”고 말한다.
일반적으로, 비상계획의 비용은 상기 질문들에 대한 답과 직접적인 연관이 있다. 특히, 보호를 위해 필요한 기능, 요구되는 보호 수준, 대처해야 할 재해 유형이 증가할수록 비상계획의 비용은 증가하게 된다. 앞서 언급한 바와 같이, 9·11사건으로 인해 비상계획이 뜨거운 이슈로 떠올랐다. 그리고 비상계획을 단순히 9·11 테러 공격과 같은 엄청난 사건에 대비하는 것이라고 생각하는 경향이 늘고 있다. 이는 근시안적인 생각이며, <표 1>에 기술한 것과 같이 재해 유형을 세 가지로 파악하는 것이 올바른 자세라고 할 수 있다.

재해유형	특징	예상가동중단시간
유형 1	하드웨어나 소프트웨어 장애, 잘못된 변경 사항 관리 등과 같은 요인으로 인한 시스템 또는 시스템 구성 요소의 통상적인 가동 중단	24 시간 이내
유형 2	화재, 정전, 사보타지 등 한 건물이나 캠퍼스에 영향을주는 불가항력의 재해	24시간에서 7일
유형 3	대규모 정전, 홍수, 허리케인, 테러등 한 지역에 영향을 주는 불가항력의 재해	8일 이상

분명 <표 1>의 내용은 각 기업들이 처한 특정한 상황에 맞도록 어느 정도 조정이 필요할 것이다.
한편 <표 1>과 같은 수단을 통해 IT 부서와 비즈니스 의사결정권자 간에 적절한 대화가 시작될 수 있다.
하지만, IT 부서와 비즈니스 의사결정권자들 간의 대화가 실질적인 의미를 가지기 위해서는 다양한 선택 방안에 대한 비용 문제도 논의에 포함되어야 한다.

4. 고가용성 네트워크 설계

비용 효율적인 고가용성 네트워크를 설계하려면 다양한 기술이 결합되어야 한다는 점을 염두에 두어야
한다. 장비 단계의 이중화는 장비 내의 단일장애점(SPoF: Single Points of Failure)을 없애주지만 링크 장애나 운영자 실수, 설정 오류, 소프트웨어 에러와 같은 ‘소프트’한 장애로부터 분산형 네트워크를 보호하지는 못한다. 분산형 네트워크를 모든 유형의 장애로부터 보호하는 가장 좋은 방법은 주요 종단 시스템(end system) 간에 다수의 병렬 경로를 제공하여 네트워크 수준에서 단일장애점을 제거할 수 있는 탄력적인 네트워크(resilient network)를 설계하는 것이다.
한편 탄력적인 네트워크에 장애가 발생하면 남아 있는 장비와 링크에 일시적으로 부하가 증가해, 장애가 발생하지 않은 경로에 트래픽 페일오버(failover)가 발생하는 것이 일반적이다. 장비 단계의 이중화 및 링크
이중화로 이러한 페일오버 발생 빈도를 줄일 수 있으며, 페일오버가 발생하면 QoS 메커니즘은 더 많은 네트워크 자원을 핵심 애플리케이션 트래픽에 자동으로 할당함으로써 높은 수준의 서비스를 유지할 수 있다.
비용 효율적인 고가용성 네트워크는 일반적으로 네트워크의 복잡성을 증가시킨다는 점도 염두에 두어야
한다. 어바이어(Avaya)의 미내시언은 네트워크 전문가들에게 이렇게 조언한다. “네트워크 설계의 복잡성과 유지관리상의 편리성 간의 균형을 맞추어야 한다. 유용하면서 자체 회복 기능을 갖춘 복잡한 네트워크를
설계할 수 있겠지만, 장애 발생 시에 이를 해결하고 지원할 수 있는 능력을 갖추고 있어야 한다는 점도 명심해야 한다.”

◆ 강력한 LAN 설계

몇 년 전부터 3계층의 계층적 설계로 대규모 캠퍼스 스위치 LAN을 구축하는 것이 일반화되고 있다. 이러한 설계는 <그림 2>에서 볼 수 있듯이 와이어링 클로짓(Wiring Closet)과 사이트 백본 그리고 캠퍼스 백본의 물리적 토폴로지와 일치한다.
네트워크의 각 계층은 해당 계층에서 요구되는 기능에 맞춰 최적화된, 다수의 이중화되고 장애에 강한(fault tolerant) 모듈로 구성된다. 소규모 기업의 네트워크는 하나 또는 그 이상의 와이어링 클로짓 모듈에 부합되는 단일 계층 LAN과 WAN 라우터로 구축할 수 있다. 반면, 중간 규모의 기업 네트워크는 와이어링 클로짓과 사이트 백본 모듈을 결합해 구축할 수 있다.
가장 일반적인 스위치 LAN 토폴로지는 와이어링 클로짓 계층에 Layer 2 스위칭과 사이트 및 캠퍼스 계층에 Layer 3 스위칭을 기반으로 한다.
이러한 방식을 L2/L3/L3 방식이라고도 하는데 LAN 설계의 초기 허브/라우터 모델에서 서브넷 구조를 차용하는 이점이 있다. 캠퍼스 계층은 또한 Layer 2 스위칭으로도 성공적으로 구축할 수 있지만, Layer 3 캠퍼스 백본은 훨씬 더 확장성이 높고 강력하다. Layer 3 스위칭은 신속한 페일오버를 가능하게 하며 이는 곧 더 높은 가용성으로 이어진다. Layer 3 캠퍼스 백본은 또한 그물형(meshed) OSPF(Open Shortest Path First) 백본을 통해 병렬적이며 비용이 동일한 경로로 완전한 링크 활용과 부하 공유를 가능하게 한다.
L2/L3/L3 모델의 단점은 클로짓 레벨로부터의 업링크가 Layer 2에서 스위칭 된다는 점이다. 특히, 스패닝 트리 알고리즘 사용으로 병렬 부하 공유(load-sharing) 연결이 각각의 와이어링 클로짓 스위치에서 이중화된 Layer 3 사이트 스위치로 구성되는 것이 불가능할 수 있다. 이러한 병렬 연결을 구성할 수 없다는 것은 해당 LAN 설계의 가용성을 떨어뜨린다.
스패닝 트리 알고리즘을 훼손하지 않고 가용성을 높일 수 있는 효과적인 방법은, <그림 2>와 같이 LAG(Link Aggregation)을 사용하여 와이어링 클로짓 스위치와 중심부의 경계선에 있는 첫번째 Layer 3 스위치 간에 point-to-point 링크를 만드는 것이다. 스패닝 트리 알고리즘은 각각의 LAG을 단일한 논리적 링크로 간주하며, LAG 내에서 부하는 MAG 주소와 포트 디노미네이션을 토대로 구성원 간에 균형 있게 분담된다.
L2/L3/L3모델에서 점차 보편화되고 있는 수정 사항은, 와이어링 클로짓 스위치의 업링크 포트를 포함시키기 위해 Layer 3의 경계를 더욱 확장하는 것으로 이는 백본에서 뿐만 아니라 라이저(riser)에서의 OSOF ECMP(Equal Cost Multi-Path) 부하 분담(load balancing)을 가능하게 한다. 라이저에서의 ECMP로 인해, 주경로가 장애로 작동되지 않을 경우에만 트래픽을 전송하는 예비용 이차 업링크의 비용/성능 부담 없이 단대단(end-to-end) 이중화 네트워크를 설계할 수 있다.
또한 <그림 2>는 와이어링 클로짓에서 서버팜(Server Farm)까지 완전 링크 및 장비 이중화를 갖추고 있는 3계층의 캠퍼스 네트워크 설계에 몇몇 네트워크 레벨 기능들이 어떻게 적용될 수 있는지를 보여주고 있다.
와이어링 클로짓 스위치 “A”의 Layer 2 스위칭으로, 링크 및 라우터 이중화에 LAG과 VRRP(Virtual Router Redundancy Protocol)를 적용할 수 있다.
일차 LAG(primary LAG) 또는 일차 사이트(primary site) Layer 3 스위치 “C”가 작동하지 않을 경우, 트래픽은 예비 LAG을 통해 이차 사이트(secondary site) 스위치 “D”로 전달된다. 반면, 와이어링 클로짓 스위치 “B”의 업링크에 있는 OSPF Layer 3 스위칭은 스위치 “C”와 “D”로의 동일비용경로(equal cost path )에 부하 분담(load balancing)을 가능하게 한다.
사이트 및 백본 계층에서는 ECMP OSPF가 완전 링크 및 장비 이중화를 지원한다. 서버 팜에서는 L2/L3 스위치 “E”와 “F”간의 OpenTrunk 802.1Q VLAN 트렁킹이 서버로 하여금 두 개의 서버 스위치를 연결하는 VLAN에 이중으로 장착될 수 있도록 한다.

◆ 그림 1 - 고가용성 LAN설계

◆ 강력한 WAN 설계

WAN에 네트워크 설계 이중화를 구현시키기 위해서는, 모든 주요 네트워크 사이트들이 이중화된 접속점(WAN에 부하가 균형 있게 분담되는 병렬의 연결을 제공하는 이중 라우터를 갖춘) 구축을 고려해야 한다.
한편 이러한 사이트들로부터 실질적으로 다양한 액세스가 가능하도록 하는 데는 지역교환 통신사업자(LEC: Local Exchange Carrier)와의 협조도 필요하다는 점에 유의해야 한다. 또한 이러한 다양한 접근을 가능케 할 경우 설계상의 비용이 높아진다는 점도 염두에 두어야 한다.

또 다른 기술은 ISDN을 백업 매체로 사용하는 것이다. 일반적으로, ISDN 회선은 일차 WAN 서비스(즉, 전용선이나 프레임 릴레이)가 작동하지 않는 경우 자동으로 활성화되며, 통상 두 개의 B 채널을 사용하거나
역다중화(inverse multiplexing) 및 압축을 사용한다.
그 결과 회선에서 256Kbps의 전송 속도를 기대할 수 있다. 그러나, 장애의 원인이 LEC 접속 회선의 단선인 경우에 이러한 기술은 무용지물이 된다. 이러한 상황이 발생해 지상 회선을 통해 다양하게 라우트된 접속이 용이하지 못하거나 비용상 사용이 불가할 경우, 서비스 공급자의 마이크로웨이브 접속이나 위성 링크 사용과 같은 대체 전략을 고려해야만 한다.

서비스 공급자로부터 서비스 수준 또는 가동시간에 대한 보장을 얻어 내는 것도 중요하다. 이러한 협상 및 네트워크 관리 문제가 중요한 것은 통상 서비스 공급자들이 서비스 수준을 보장하기는 하지만 불이행에 대한 보상액이 상대적으로 가볍기 때문이다. 따라서, 고가용성의 WAN 구축을 원하는 네트워크 관리자들은
서비스 수준의 보장에 관한 더욱 구체적인 협상을 할 필요가 생기는 것이다.
좀더 의미 있는 서비스 수준 보장에 관한 협상이 비상계획의 중요한 요소로 보이기도 하지만 어바이어(Avaya)사의 미내시언은 이렇게 말한다. “장애 발생 시에 서비스수준협약(SLA: Service Level Agreement)에 의존해서는 안 된다. 어바이어사는 회선의 마지막 구간을 네덜란드의 무선 서비스 공급업체에 하청을 준 적이 있다. 그런데, 네트워크에 장애가 발생했지만 노동법이 12시간 이상 근무를 금해 기술자를 파견하지 못했다. 이러한 법적 제약 때문에 SLA는 재해복구 면에서 아무런 도움이 되지 못했다.” 미내시언은 해당 WAN이 비즈니스에 중요한 부분이라면 경로를 다양화하고 이중화할 필요가 있다고 충고한다.
한편 고가용성 제공이 네트워크 관리의 문제가 된다고 한 이유는, 서비스 수준 보장을 모니터링 하는 데에 비교적 정교한 서비스 관리 도구와 프로세스를 구축해야 하기 때문이다. 서비스 공급자가 제공하는 SLA에 전적으로 의존할 수 없을 경우에는, 경쟁 인터넷 서비스 공급자와 WAN이 제공하는 이중화된 네트워크 서비스에 이중 네트워크 연결을 구축해야 한다. 이러한 예로는 많은 기업들이 자사의 콜 센터 트래픽을 여러
서비스 제공업체로 분산하고 있는 것을 들 수 있다.

◆ 그림 2 - 고가용성 WAM연결

< 그림 2>는 고가용성의 WAN 액세스 아키텍처를 보여준다. 이중화된 액세스 라우터가 서버 사이트 계층의 이중화된 Layer 3 스위치에 연결되어 캠퍼스 LAN과 WAN 사이의 모든 단일장애점(SpoF)을 제거한다.
아이서브(iSERV)사의 코커리는 “고가용성 네트워크 계획을 수립할 때 라우트를 다양화하는 것은 대단히 바람직하다. 그러나, 서비스 지역에 따라 추가 조사가 일부 필요하다. 우리는 서로 다른 통신사업자의 서비스를 사용했는데도 물리적 전송이 동일한 경우를 여러 번 경험했다. 이는 조사를 통해 단일장애점이 명확해질 때에야 알게 된다”고 말한다.
미내시언도 코커리와 같은 의견으로, “어바이어사도 서로 다른 통신사업자들의 이중 회선 서비스(동일한
파이버 백본을 통과하는)를 경험한 적이 있다. 이러한 경우는 많은 공급자들이 빌린 용량을 다시 빌려주는 대서양 횡단 및 태평양 횡단 링크에서 특히 두드러진다”고 말한다. 미내시언은 네트워크 전문가들에게 “서비스 공급자들에게 상세한 라우트 경로를 요구하여 그들이 직접 전송하는지 아니면 전대(轉貸)한 것인지를 구분, 파악해야 한다”고 충고한다.

5.비상계획 수립을 위한 프로세스

여기서는 비상계획에 포함되어야 하는 몇 가지 프로세스에 대해 살펴보고자 한다.

◆ 다른 주요 프로세스와의 링크

IT 비상계획이 실효성을 갖기 위해서는 다른 주요 프로세스와 연계되어야 한다. 예를 들면, 엔드리와 코커리가 강조한 바와 같이, 관련 비즈니스 프로세스와 긴밀하게 연계되어 있지 않은 비상계획으로 재해복구가 이루어질 경우, 시간과 돈을 낭비하게 된다.
또한, IT 업체의 비상계획은 자체 보안계획과 연계할 필요가 있다. 여기에는 두 가지 이유가 있는데, 첫째는 서비스 거부 공격(Denial of Service attack)과 같은 보안 사고로 인해 회사가 온전히 기능하지 못할 수 있기 때문이고, 둘째는 효과적인 보안계획 수립과 효과적인 비상계획 수립이 상당 부분 공통되기 때문이다. 따라서 이러한 두 가지 계획을 연계함으로써 비용을 최소화하고 각 계획의 효율성을 극대화할 수 있다.

? 정기적인 인벤토리 분석 수행
미내시언은 강력한 비상계획을 구축하기 위해서는 네트워크 전문가들이 이렇게 조언한다. “전체적인 설계에서부터 각각 장비에 설치되는 펌웨어의 최신 개정본에 이르기까지 설치와 관련된 모든 사항을 파악해야 한다. 많은 네트워크 팀들이 엔지니어의 PC에 설치된 비지오(Visio) 프로그램으로 작성된 다이어그램을 기반으로 네트워크를 설계하고 있는 실정이다.”

◆ 백업 장비 배비(配備)

뉴욕에 위치한 한 금융회사의 CTO는 9·11사건 이후 주식 시장이 다시 개장됐을 때 3000 명의 관련 직원들이 정상적으로 업무를 수행할 수 있었다고 한다. 그는 이것이 가능했던 이유 중 하나로 표준 데스크탑 환경을 갖추고 있었다는 점을 들었다. 표준 데스크탑 환경 덕분에 비교적 손쉽게 적절한 소프트웨어를 백업 데스트탑에 설치할 수 있었던 것이다. 그 과정에서 가장 까다로운 부분이 PC 3000대를 새로 구입하는 것이었다.

◆ IT 위기 관리팀 구성

재해에 신속히 대처하기 위해서는 재해 발생 이전에 IT 위기 관리팀과 대체 부서를 구성하고 업무 내용을 명확히 규정해 두어야 한다. 또한 위기 관리팀이 즉각 가동되도록 하려면 모든 사람들이 대체 관리팀, 위기 관리팀과 연락 가능하도록 최신 연락 정보를 작성하고 관리해야 한다.

◆ 효과적인 커뮤니케이션 방안 확립

위기 관리팀이 효과적으로 운영되기 위해서는 효과적인 커뮤니케이션 방안이 마련되어야 한다. “위기 발생시에는 효과적인 커뮤니케이션이 중요해지는데, 리서치인모션(Research-in-Motion)의 블랙베리(Blackberry) 제품군과 같은 신기술 제품의 사용이 매우 효율적인 것으로 밝혀졌다.
지난 봄, 도로변 변전실의 화재로 인해 우리 건물이 폐쇄되는 일이 발생했다. 당시, 상급 관리팀이 아침 출근길에 있을 때 우리가 이 문제에 대해 자문을 받게 되었다. 우리가 도착했을 때, 대체 사무실 공간을 사용하기 위한 정비가 이루어졌으며 고객지원센터의 전화선이 재정비되어 있었다. 비즈니스 사용자에게 이는 당연한 일이었지만 블랙베리의 문자 메시징이 없었다면 결코 해낼 수 없었던 일이었다.” 코커리의 말이다.

◆ 후임자 육성계획 수립

IT부서가 정상적으로 운영되기 위해서는 후임자 육성계획을 수립해야 한다. 이러한 계획의 필요성은 비상계획 수행 시에 더욱 돋보인다. IP 주소 체계와 같은 네트워크의 핵심 사항에 관한 모든 지식이 주로 한두 사람의 머리 속에만 있다는 것은 큰 취약점으로 나타날 수 있기 때문이다.
미내시언은 네트워크 전문가들에게 이렇게 조언한다. “회사 네트워크에 대해 알고 있는 사람이 두 명 이상이 되도록 해야 한다. 직원 한 명에게만 의존하다 해당 직원이 모든 지식을 가지고 떠나버리는 경우가 비일비재하므로, 공식적인 후임자 육성계획을 즉시 수립해야 한다.”

◆ 직원 교육

비상계획이 효율적으로 운영되기 위해서는 회사 직원들이 이를 깊이 있게 인식하고 있어야 한다. 신입사원 오리엔테이션이나 업무 수행 과정에서 공식적인 교육을 실시함으로써 이러한 인식을 높여야 한다. 이를 위해 여러 가지 다른 방법들도 활용할 수 있다. 예를 들면, 뉴욕의 많은 회사들이 비상 정보 카드를 활용하고 있는데, 이 카드는 셔츠 주머니에 넣고 다닐 수 있도록 만든 얇은 카드로 재해 발생시 취해야 할 행동 요령을 담고 있다.

◆ 비상계획 테스트
코커리는 “재해복구나 업무연속성계획은 테스트를 거쳐 보완되어야 개발이 완료된다. 우리는 재해복구 및 업무연속성계획을 연 4회(정규 테스트 3회와 ‘불시’ 테스트 1회) 테스트한다”고 말한다.
코커리는 불시 테스트를 시행할 때 사전에 직원이나 동료가 화재나 폭발물의 폭발 등으로 인해 업무를 볼 수 없게 되었다는 내용을 담은 쪽지를 직원의 책상에 남겨두곤 한다. 이런 방법으로 테스트는 더욱 실제 상황에 가까운 시뮬레이션이 되는 것이다.
코커리는 또한 최신 호출 번호로 꾸준히 업데이트해야 한다고 강조한다. 그는 경험을 통해 “통상 90일이 지나면 20%가 바뀐다는 것을 알게 됐다”고 말한다.
프라이스워터하우스쿠퍼스(PricewaterhouseCoopers)사의 브라운(Brown)은 “테스트는 재해복구 계획의 가장 중요한 요소 중 하나로, 여기에는 예비 하드웨어의 가용성에서부터 디젤 발전기에 연료가 채워져 있는지 또 제대로 작동하는지에 이르기까지 모든 것이 포함되어야 한다”고 말한다. 브라운은 예전에 “건물 배전이 바뀌어 결국 디젤 발전기가 작동하지 않았음을 알게 되었다. 이러한 사실은 통상적인 분기별 테스트를 통해 밝혀졌는데, 이는 정기적 테스트가 얼마나 중요한지를 단적으로 보여준다”고 말한다.
미내시언은 네트워크 전문가들이 또한 자사의 대역외(out of band) 관리 액세스를 정기적으로 점검해야
한다고 조언한다. 그는 “모뎀 사용을 위한 링크를 단선시킨 후 링크를 다시 연결하도록 기술자들에 지시하지 않는 경우가 많다.
뒤늦게 긴급 상황에 대처하기 위한 액세스가 필요할 때에야 이런 사실을 발견하게 된다”고 말한다.

◆ 복구

앞서 언급한 바와 같이 1984년에 아이서브(iSERV)사의 코커리는 화재가 발생한 대형 통신 회사의 주요 데이터센터 복구에 참여한 적이 있다. 그는 이를 통해, 재해 상황이 완료된 후에 어떤 작업이 비상계획에 포함되어야 하는지를 알게 됐다. “당시 화재 사건에서 배운 두 번째 교훈은, 비록 우리가 대체 데이터센터 가동 방안을 훌륭하게 수립했고 이를 거의 완벽하게 실행은 했지만, 원상 복구 방안에 대한 계획은 가지고 있지 않았다는 것이다. 모든 것을 원상 복구시키는 것은 또 다른 재해 상황이라 할 만한 것이었다. 결국 이 모든 것들을 천천히 조심스럽게 복구하는 데에 추가로 수개월이 소요되었다.” 코커리의 말이다.

6. 비즈니스 사안 분석

재해를 입은 회사의 40%가 수년 내에 문을 닫는다는 것이 IT 업계의 일반적인 인식이다. 이러한 통계는 기업들이 비상계획을 수립하도록 하는 자극제로는 충분하지만, 비상계획 구축에 막대한 자금을 투자할 수 있도록 경영진을 움직이는 데는 다소 역부족이다. 이를 위해서는 네트워크 관리자들이 회사 내의 의사결정권자들과 협의하여 자사의 환경에서 신뢰할 수 있는 비즈니스 사안 분석을 실시해야 한다. 이러한 비즈니스 사안 분석은 다운타임(down time) 비용을 파악하는 것에서 시작한다.
먼저, 대부분의 비즈니스 기능의 경우 그 기능이 수 시간 혹은 하루 동안 작동하지 않으면, 회사에 분명 손실이 발생할 수 있다는 사실이 아직 일반적인 인식으로 자리잡지 못했다는 점을 지적할 필요가 있다. 이는 해당 비즈니스 기능이 작동하지 않는데도 사람들이 무덤덤하다는 말이 아니다. 그보다는 그러한 기능의 장애발생 가능성을 줄이기 위해 추가로 비용을 지불할 의사가 없음을 지적하고자 하는 것이다.
그러나, 몇 가지 비즈니스 기능들에 대해서는 많은 회사들이 다운타임으로 인한 비용을 인정하고 있다. 그 기능들은 다음과 같다.

● 증권 거래
● 온라인 판매
● 적시(Just-in-Time) 생산
● 온라인 예약

이러한 기능들의 장애 비용을 산정하는 데 고려하는 여러 가지 요소들이 있으며, 이는 다음과 같다.

● 매출 감소
● 고객 감소
● 신뢰 상실

IT 부서는 비상계획 수립을 위한 비즈니스 사안 분석에서 <표 2>와 같은 표를 만들어 분석을 수행해야 한다. 이 표는 몇몇 주요 지점과 주요 기능 또는 전체 운영에 관한 것으로, 먼저 회사 내에서 장애로 인한 비용이 가장 클 것으로 보이는 비즈니스 상황부터 시작하는 것이 실질적인 접근 방법이다. 만약 비즈니스 담당자들이 그런 상황에 대비한 비상계획에 자금을 투자할 의사가 없다면, 더 이상의 작업은 시간 낭비일 것이다.
예를 들어, <표 2>가 대형 증권회사의 장내 거래에 관한 것이라고 가정해 보자. 또 분석할 특정 사안이, 회사 소속의 거래자들이 재해에도 불구하고 지속적으로 시장 데이터에 접근할 수 있도록 하는 비상계획 구축의 경제적 가능성이라고 가정해 보자.

이 경우 표를 작성하는 목적은, 비상계획에 대한 자금 지원 여부를 최종 결정하는 사람(또는 사람들)에게 IT부서가 대안을 제시하도록 하는 데 있다. 이런 맥락에서 보면, 하나의 솔루션은 여러 가지 기술과 기능 및 프로세스가 결합된 것이라 하겠다.

솔루션	보호수준	재해유형	비용
1	4시간 백업	유형1	100만 달러
2	4시간 백업	유형2	500만 달러
3	4시간 백업	유형3	2500백만 달러
4	상시 대기 (Hot stand-by)	유형4	500만 달러
5	상시 대기 (Hot stand-by)	유형5	2500만 달러
6	상시 대기 (Hot stand-by)	유형6	1억 2500만 달러

표를 작성하기 위해, IT 부서는 두 가지 핵심 요소를 기준으로 여러 가지 유망 솔루션을 검토해야 한다. 또한 그 과정에서 특정 솔루션 구축에 드는 비용을 추정 산출해야 하는 점에도 유의해야 한다. 이러한 유망 솔루션 비용도 <표 2>에서 매우 중요한 요소다.

표에 포함되어야 하는 두 가지 핵심 요소 중 하나는 비상계획이 제공하는 보호의 수준(Amount of Protection)이다. 보기에서는 두 가지로 살펴보았다. 하나는 거래자들이 거래 데이터에 지속적으로 접근할 수 있는 경우고, 다른 하나는 거래자들이 최대 4시간 동안 거래 데이터에 접근하지 못하는 경우다.
표에 포함되어야 하는 또 다른 핵심 요소는 비상계획이 대처해야 하는 재해의 강도(severity)다. 재해 유형 분류법은 <표 1>에 자세히 설명되어 있다. 보기에서는 세 가지 유형을 모두 고려했다.
< 표 2>와 같은 수단을 활용하면 다음과 같은 성과를 거둘 수 있다.

● IT 부서를 회사의 비즈니스 및 기능 관리자의 파트너로 확고하게 자리매김해준다. 이는 IT 부서가 비즈니스 의사결정권자들이 고려할 대안을 제시하고 있기 때문이다.
● 의사결정시 고려해야 할 비용 요소를 제시한다. 엔드리의 말을 빌리면, 비용 요소를 제시하지 못할 경우, 먼저 업무연속성계획의 필요에 의해 회사 이메일의 100%를 이중화해야 하는 상황이 벌어질 수도 있을 것이다. 그리고 회사 이메일의 100%를 이중화하는 데 소요되는 비용을 계량화한 후에야, 회사 이메일의 50%만을 이중화해도 괜찮은지를 비즈니스 관점에서 제대로 판단할 수 있을 것이다.

7. 요 약

재해복구 및 업무연속성이 뜨거운 이슈로 떠오르는 데는 9·11사건도 한몫 했다. 그런데 미국에 대한 공격이 초래한 여러 가지 영향들이 사람들의 뇌리에서 희미해지고 있는 반면, 재해복구 및 업무연속성은 여전히 수많은 기업에 중요한 문제로 인식될 것이다. 여기에는 두 가지 이유가 있다. 하나는 많은 회사에서, 9·11 공격의 영향이 사라지지 않은 것이고, 다른 하나는 재해복구와 업무연속성이 9·11과 같은 엄청난 사건에 대비해 단지 ‘보호’ 기능을 제공하는 것 이상의 의미가 있기 때문이다.
이 글은 이런 점들을 염두에 두고, 네트워크 담당자들이 IT 비상계획(회사의 특정한 상황과 요구를 반영하는)의 수립에 사용할 수 있는 프레임워크를 제시했다. 예를 들어, 어떤 회사들은 비교적 간단한 비상계획을 원할 것이고, 또 어떤 회사들은 좀더 포괄적인 비상계획을 원할 것이다. 어느 경우든, IT 비상계획의 효과를 극대화하기 위해서는 다른 두 가지 요소 즉, 회사의 보안 계획 및 IT 비상 계획에 대응하여 구현되고 있는 비즈니스 프로세스들과 긴밀하게 연계되어야 한다.
이 글에서 소개한 프레임워크는 비상계획 수립 시에 네트워크 전문가들이 <표 1>과 같이 재해를 세 가지로 분류해 볼 것을 제안하고 있다.
또한 이 글은 고가용성의 LAN과 WAN 인프라 구축의 가이드라인 몇 가지를 제시하고 있다. 그러나, 실제로 비상계획에 이러한 가이드라인이 적용될 경우 네트워킹 비용이 증가할 수도 있고, 네트워크 인프라가 복잡해질 수도 있다.
이 프레임워크는 비상 상황을 위한 솔루션에 여러 가지 기술과 기능 및 프로세스를 결합할 것을 제시하고 있다. 이 글에서 언급한 바와 같이 이러한 솔루션을 만드는 데 사용될 수 있는 기술들은 대단히 많다. 주로 백업 전력(backup power)과 전화의 재설정 등의 몇 가지 기술들이 비상계획 수립에 적용되고 있다. 그러나, VoIP와 컨텐츠 분산 네트워크(content distribution network) 등의 수많은 다른 기술들은 일반적으로 비상계획에 사용될 수 있음에도 불구하고 이러한 비상 계획과는 무관하게 구축되고 있다.
재해에 대한 취약성을 줄이기 위해 많은 회사들이 도입하고 있는 기능 몇 가지를 소개하면 다음과 같다.

● IT 인프라스트럭처의 단순화
● 회사의 부동산 보유의 다양화
● 호스트된 솔루션의 활용

또한, 비상계획 솔루션을 구성하는 데 부분적으로 사용될 수 있는 프로세스들도 다양하다. 이러한 프로세스 가운데 정기적인 인벤토리 분석 수행 등은 그 자체가 의미 있는 IT 관리 프로세스라고 할 수 있다. 그러나, 이러한 프로세스들의 핵심은 비상계획 지원에 있다. 따라서, 이러한 프로세스를 구현하는 것은 업무 및 비용의 증가를 의미한다.
집필에 도움을 준 수많은 고위 IT 담당 간부들은 적절한 자금 조달 방안에 관한 논의 없이는 비상계획에 대한 의미 있는 논의가 이루어질 수 없다는 점에 대해 모두 동의했다. 이 글은, 이제 막 비상계획을 준비하고 있는 IT 부서들이 다운타임으로 인해 엄청난 비용이 발생할 가능성이 가장 높은 비즈니스 상황부터 시작할 것을 제안하고 있다. 회사 내의 비즈니스 경영진들이 이러한 핵심 상황에 대비한 비상계획에 자금을 투입할 의사가 없다면 더 이상의 비상계획을 위한 작업은 시간 낭비가 될 것이기 때문이다.

출처 : http://www.his21.co.kr/advantage/advantage75/docu08.htm

Switch , VLAN , VTP

JAESOO — Mon, 15 Jun 2015 19:56:54 +0000

많이들어본 장비 스위치이다
오늘에서야 배우게되어서 궁금증이 많이 풀릴거같다.

## Switch ##

>> Layer2 Switch

- Collision Domain을 분리해서 Network 확장성을 갖는다.
   하지만 Broadcast Domain은 하나이기 때문에 많은 호스트를 Switch로
   연결하면 Broadcast Traffic이 증가해서 Network 성능이 떨어진다.

- MAC Address 학습 기능을 갖는다.

- 자신의 MAC Address Table에 목적지 MAC주소가 없는 경우 모든 포트로 플러딩 한다.

- 포워드 및 필터링 기능을 갖는다.

- Swich는 최대 300개 이상 포트를 하나에 스위치가 갖을 수 있다.
   Bridge는 최대 16개의 포트만 갖는다.

- ASIC Chip에 의한 Hardware Frame 전달을 하기 때문에 최대 100만개
   이상의 Frame을 처리하는 능력을 갖는다.
   Bridge는 CPU에 의해 OS 및 Frame 처리를 하기 때문에 스위치보다 느리다.

- Port Security 기능을 갖는다.

- VLAN(Virtual LAN) 기능을 통해 Switch의 Broadcast Domain을 분리한다.

- VTP(Virtual Trunk Protocol)은 VLAN Database를 스위치간 동기화 하는
   Protocol이다.

- STP(Spanning-tree Protocol) 기능으로 Link이중화 및 Loop 방지가 가능하다.

- EtherChannel은 두개 이상의 Link를 하나로 묶어서 대역폭을 확장한다.

>> 스위치 기능

> Address Learning(학습기능)

--> Switch에 들어오는 프레임의 MAC Address를 확인하여 각포트에 연결된
      장비들의 MAC address를 학습한다.
      이렇게 만들어진 MAC Address는 MAC Database에 저장된다.

> Forward / Filter(포워딩/필터링)

--> 프레임을 수신하고 나서 어떤 포트로 전송을 할지 MAC database를 확인
      하고 해당 포트로 전송한다.
      목적지 MAC Address가 MAC database에 없으면 들어온 포트를 제외한
      모든 포트로 플러딩한다.

> Loop Avoidance(루프 회피)

--> 링크 이중화를 위하여 Switch에 동일 경로에 대한 링크가 중복될때
      Switch는 여러 경로사이에 프레임이 계속 재전송 되는 것을 방지해야 한다.

      중복된 링크간 패킷이 지속적으로 재전송 되는 것을 Loop라고 한다.

      Loop가 있을 경우 프레임이 지속적으로 재전송되어 네트워크를 저하
      시키다 결국 다운된다.
      이러한 Loop를 막기 위한 방법으로 STP(Spanning-Tree Protocol)가 있다.

>> 프레임 처리방식

> Store and Forward

--> 프레임을 완전히 수신한 다음에 전송한다.
      수신지 Address와 송신지 Address를 확인 후 CRC검사를 수행 후 프레임을
      전달한다.
      CRC가 맞지 않으면 프레임을 삭제한다.

> Cut-through

--> 프레임이 수신되자 마자 헤더의 수신지 Address를 확인하고 바로 전송을
      시작한다.
      수신지 Address를 확인 후 바로 전송하기 때문에 프레임의 크기에 상관
      없이 지연 시간은 일정하다.
      단점은 충돌 프레임이나 잘못된 CRC값을 가진 프레임도 전송한다.

> Fragment-Free

--> 프레임을 전달하기 전에 프레임의 처음 64byte만 확인 후 전송한다.
      일반적으로 충돌은 64byte에서 발생하기 때문에 64byte만 확인하여
      충돌 프레임을 걸러 낼 수 있다.

>> EthernetⅡ Frame 구조

-------------------------------------------------------------------------------
| Freamble |    D.A    |    S.A    | Type |         DATA          |   FCS   |
|   8byte    |   6byte   |   6byte   | 2byte |      46 ~ 1500byte    |   4byte |
-------------------------------------------------------------------------------
               Cut-through                          Fragment-Free       Srore and forward

이것으로 CCNA 주말 한달간의 수업이 모두 끝났다.
2년걸리는 수업과정을 한달, 즉 8일만에 끝내려하니 정말 어렵고
빨리지나갔다.
따로 공부도 해야겠고, 자격증도 빨리 취득해야겠다
다음달부턴 자바공부를 하고, 틈틈히 CCNA 자격증 준비해야겠다^^

ps. 밑에 VLAN,VTP 설명

>> VTP(VLAN Trunk Protocol)

- Switch의 vlan.dat 파일에 정의된 VLAN Database를 VTP Domain으로 구성된
   모든 Switch에 복제해서 모든 Switch들이 동일한 vlan정보를 갖도록 한다.

- Switch간 "flash:vlan.dat" 파일을 다른 Switch와 동기화 하는 Protocol이다.

>> VTP Mode

> Server

--> Switch가 VLAN Database를 직접 생성 / 삭제 / 변경이 가능하고
      그 정보를 flash:vlan.dat로 저장하여 같은 VTP Domain에 있는
      다른 스위치에게 Replication을 수행하는 모드이다.
      Switch 초기 기본 모드이다.

> Client

--> Switch가 VLAN Database를 직접 만들지 않고 Server로 부터 동기화
      한 후 DRAM에 그 정보를 유지하는 모드이다.
      자체적으로 생성 / 삭제 / 변경이 불가능 하다.

> Transparent

--> Server 모드와 동일한 기능을 갖으나, 다른 Switch에게 그 정보를
      동기화 하지 않는 독립형 모드이다.
      하지만 자신에게 전달되어 온 VTP Summary 정보는 다른 Switch에게
      전달한다.

>> VTP 설정

1) VTP Domain을 설정한다.

   같은 vlan.dat 파일을 공유하고자 하는 모든 Switch는 모두 같은
   VTP Domain name을 사용해야 한다.
   같은 VTP Domain을 사용하는 Switch간 VALN 정보를 동기화 한다.

   Switch(config)# vtp domain <name>
   Switch(config)# vtp domain ccna

2) VTP Option 설정을 한다.

   보안을 위해 암호를 설정을 할 수 있다.
   모든 Switch간 Password가 동일해야 한다.

   Switch(config)# vtp password <암호>
   Switch(config)# vtp password cisco

3) VTP Mode를 선언한다.

   Switch(config)# vtp mode <Server | Client | Transparent>
   Switch(config)# vtp mode client

>> VTP 정보 확인

   Switch# show vtp status

=========================================================================================================
>> VLAN (Virtual Local Area Network)

- Switch는 Broadcast Traffic을 전달하는 장비이다.

- VLAN을 사용하여 Broadcast Domain(Traffic)을 분리할 수 있다.

- VLAN은 Switch Port 단위로 VLAN ID를 할당하여 다른 VLAN ID를 갖는
   Port간에는 traffic이 차단된다.

- Switch는 초기에는 모든 Port가 VLAN 1 번 ID를 설정되어 있다.
   그래서 초기에는 모든 Port간 통신이 가능하다.

- Frame Tagging을 이용한다. (ISL,802.1Q)

- VLAN을 사용하는 Switch는 Port Type이 구분된다.

- VLAN 정보는 스위치에 Flash:vlan.dat 파일에 저장된다.

- VLAN Port Mapping 정보는 Flash:config.text 파일에 저장된다.

>> Static VLAN

   --> 관리자가 직접 Switch에 VLAN Database를 구성하고 Port를 매핑한다.

>> Dynamic VLAN

   --> VMPS 서버를 만들어서 서버 Database에 VLAN정보와 MAC-Address를
       미리 매핑한 후에 Switch에 PC가 연결되면 Switch가 MAC Address를
       학습한 후 VMPS서버에 Query를 해서 해당 PC가 어떤 VLAN에 포함되어
       있는지 동적으로 알아내서 포트를 VLAN정보에 맞게 자동 변경한다.
       (사용자가 자주 바뀌는 회의실에서 유용하다.)

>> Switch Port Type

> Access-link

--> 하나에 VLAN에만 포함되는 포트이고, 해당 VLAN Traffic만 처리 한다.

      단일 VLAN Traffic을 전달하는 포트이고, 호스트 연결 포트가 된다.

      초기 모든 Port가 Access-link이다.

> Trunk-link

--> 어떠한 VLAN에도 포함되어 있지 않고, 모든 VLAN에 Traffic을 전달하는
      포트이다.

      다중 VLAN Traffic을 전달할 수 있는 포트이다.
      보통 Switch와 Switch를 연결하는 구간이다.
      Trunk는 Tagging된 Frame을 전달한다.(ISL or 802.1Q)

>> VLAN 생성

Switch(config)# vlan 10
Switch(config-vlan)# name VLAN10

>> VLAN 제거

Switch(config)# no vlan 10

>> VLAN 정보 확인

Switch# show vlan brief

>> 하나의 Port를 VLAN에 포함하기

Switch(config)#interface fastethernet 0/1
Switch(config-if)# switchport mode access
Switch(config-if)# switchport access vlan 10

>> 여러개의 Port를 VLAN에 포함하기

Switch(config)# interface range fa0/10 - 15 , fa0/20 - 24
Switch(config-if-range)# switchport mode access
Switch(config-if-range)# switchport access vlan 10

>> Trunk Link 구성

> FastEthernet 0/24 포트를 Trunk-Link로 설정

Switch(config)# interface fa0/24
Switch(config-if)# description "To SW2 Fa0/24 Trunk Connection"
Switch(config-if)# switchport mode trunk
Switch(config-if)# switchport trunk allowed vlan all

>> VLAN 10, 20번만 전달하는 Trunk Link 설정

Switch(config-if)#switchport trunk allowed vlan none
Switch(config-if)#switchport trunk allowed vlan add 10
Switch(config-if)#switchport trunk allowed vlan add 20

>> Trunk Link에서 특정 VLAN Traffic 차단

Switch(config-if)# switchport trunk allowed vlan remove 10

>> Trunk Link 정보 확인

Switch# show interface trunk

>> Switch encapsulation 설정

Switch(config-if)# switchport trunk encapsulation <dot1q | isl>

--> Layer2 Switch는 지원안함, 802.1Q만 사용가능하다.
      Switch가 ISL, 802.1Q 둘다 지원하는 경우 encapsulation을 선언해야 한다.
      switchport mode trunk 선언하기 전에 먼저 설정한다.

>> Frame Tagging

- ISL    (cisco Only)
- 802.1Q (IEEE 표준)
- 802.10 (FDDI망연결)
- LANE   (ATM 연결)

>> Switch 초기화

- VLAN.dat , config.text 두개의 파일에 VLAN정보를 저장한다.
   이 두개의 파일을 삭제해야 VLAN 및 포트 매핑정보를 초기화 할 수 있다.

   Switch# delete vlan.dat
   Switch# erase startup-config or Switch# delete config.text
   Switch# clear vtp counters
   Switch# reload

출처 : http://smstudent.egloos.com/v/2645019

Switch의 Loop방지기술 - STP

JAESOO — Mon, 15 Jun 2015 19:55:47 +0000

Spanning-Tree Protocol

스위치 네트워크를 이중화 구성할 경우, 여러가지 장애가 발생할 수 있다.

그러한 장애의 원인은 바로 이중화 구성 때문이다. 그럼 장애를 없애려면 어떻게 해야할까?

너무나도 간단한 이야기지만 이중화 구성이 아니면 된다…

그럼.. 이미 구성해 둔 이중화 링크를 한군데 뽑아버리느냐?? 그건 아니다.

물리적으로 포트를 분리시키는 것이 아니라 논리적으로 하나의 포트를 일시적으로 막아서 사용하는 것이다.

이렇게 논리적으로 하나의 포트를 막아서 루프를 방지하는 기술이 바로 Spanning-Tree Protocol이다.

STP의 동작과정

STP를 동작시키면 서로 연결된 여러 개의 스위치들은 그들 중 하나의 반장을 뽑는다.

그 반장을 우리는 Root Bridge라고 부른다.

그리고 하나의 Root Bridge를 제외한 나머지 스위치들은 Non-Root Bridge라고 한다.

1. 한 네트워크 상에 있는 스위치들은 네트워크의 정보 및 각 스위치의 정보들이 담겨있는 프레임인 BPDU를 서로 주고 받는다.

BPDU : 네트워크의 정보와 각 스위치의 정보가 담긴 프레임이다.

2. BPDU안에 담겨있는 Bridge-ID를 비교하여 가장 낮은 Bridge-ID를 가진 스위치가 Root Bridge로 선출된다.

Bridge-ID = Bridge-Priority + MAC address

<STP에서의 Port 종류>

Designated Port : Root Bridge에서 보내는 정보를 다른 스위치들에게 전달하기 위해 지정된 포트

Root Port : Root Bridge로 가는 가장 좋은 길의 포트.

Nondesignated Port : Block 포트라고 해도 되며, 논리적으로 통신을 하지 못하게 막아두는 포트.

Port가 선정될 때 유의해 야 되는 점

- Root Bridge가 가진 포트는 모두 Designated Port가 된다.

- 하나의 세그먼트당 하나의 Designated Port만 가진다.

- Non-Root Bridge 당 하나의 Root Port를 가진다.

Port 선출 시 비교하는 기준

1. 낮은 Cost (대역폭에 따라 산출됨 - 대역폭이 클수록 Cost는 낮음)

2. 낮은 Sender Bridge-ID

3. 낮은 Sender Port number

STP의 상태변화

Disabled

포트가 고장나서 사용할 수 없거나, 관리자가 수동으로 shutdown 시킨 상태

- 데이터전송 x , Mac주소학습 x , BPDU 전달 x

Blocking

스위치를 처음 키거나, Disabled 포트를 살린경우 Blocking상태로 들어간다. 이 상태에서 다른 스위치들과 BPDU를 주고 받으며 Root Bridge를 선정하고 포트를 설정하는 등의 작업이 일어난다.

- 데이터전송 x , Mac주소학습 x , BPDU 전달 o

Listening

Blocking 상태에서 모든 선정작업이 끝나게 되면 Listening 상태로 넘어가며, 이 상태는 15초간 지속된다. 새로운 장비가 접속하게 되면 다시 구성정보들이 변경되며 다시 Blocking으로 돌아간다.

- 데이터전송 x , Mac주소학습 x , BPDU 전달 o

Learning

Listening의 15초가 지나면 Learning상태가 되는데, 이 상태에서는 맥주소의 학습을 하여 맥주소 테이블을 만든다. 이 상태는 15초간 지속된다.

- 데이터전송 x , Mac주소학습 o , BPDU 전달 o

Forwarding

스위치 포트가 Learning 상태에서 변동사항 없이 15초가 지나게 되면 Forwarding상태가 된다. 이 상태에서는 드디어 데이터전송이 가능해지게 된다.

- 데이터전송 o , Mac주소학습 o , BPDU 전달 o

Listening, Learning, Forwarding 상태에서 Root port 또는 D.P에서 탈락되게 되면 바로 Blocking 상태로 전환될 수 있다. 또한 스위치 포트가 어떤 상태에 있던지 관리자에 의해 shutdown 되거나 고장으로 인해 다운되면 Disabled 상태로 전환 된다.

출처 : http://bignet.tistory.com/17

SSL VPN과 IPSec VPN

JAESOO — Fri, 22 May 2015 08:40:15 +0000

SSL VPN과 IPSec VPN [NETWORK TIMES ]

언제 어디서나 자유롭고 안전한
인터넷 사용 ‘OK’

유지보수 비용 절감·안전한 유비쿼터스 액세스 구현 … 시장 확대 중

황인각
주니퍼코리아 기술팀 차장

최근 사내간, 사내-사외간 통신에 사용되는 네트워크가 점차 인터넷 기반으로 변모함에 따라 인터넷을 이용하면서도 종단 간에 안전한 통신이 가능하도록 하는 VPN 기술이 많이 도입됐다. 이러한 VPN 기술이 개인이나 기업의 사용 용도에 맞도록 공중망을 사설망처럼 이용할 수 있게 하는 IPSec VPN 기술이다.
< 편집자>

VPN 기술은 한 조직의 내부 사용자 간의 혹은, 외부 사용자와의 통신에서 암호화 기술과 터널링 기술을 이용한 안전한 통신 채널을 제공하는 기술로서 비즈니스 측면의 사용자뿐만 아니라, ISP 사업자, 그리고 전자상거래 사업자까지 다양하게 사용될 수 있는 차세대 네트워킹을 위한 핵심기술로 기대되고 있다.

SSL VPN의 등장, ‘클라이언트리스 VPN’

IPSec VPN을 이용한 구축은 사이트 투 사이트(Site-to-Site), 사이트 투 클라이언트(Site-to Client)의 두 가지 방식으로 이뤄지고 있으며, 사이트 투 사이트 경우는 매우 안정적인 보안 서비스를 제공한다. 반면 사이트 투 클라이언트는 원거리상의 모든 컴퓨터상에 VPN 클라이언트 소프트웨어를 설치, 관리 및 유지보수를 해야하는 어려움으로 도입에 많은 걸림돌이 되고 있다.
즉, 클라이언트 VPN은 사용자 액세스를 위해 데스크톱이나 노트북에 반드시 클라이언트 소프트웨어가 설치돼야 VPN 접속이 가능하다는 점이 활성화의 장애가 되고 있다. 그래서 새로운 개념의 액세스 솔루션에 대한 요구가 대두하게 됐고 특히 무거운 클라이언트 VPN을 대체하고자 하는 새로운 SSL-VPN 기술이 개발됐다.
IPSec 기반의 클라이언트 VPN망을 운영하는 기업(관리자)은 다음과 같은 문제를 항상 가지고 있으며, SSL-VPN 솔루션은 이러한 문제를 적은 비용으로 효과적으로 해결해 줄 수 있다.

· 클라이언트 소프트웨어의 버전 및 패치 관리의 어려움
· 사용자의 다양한 하드웨어, 운영체제 버전 및 패치 상태에 따른 설치의 어려움
· 장애시 정확한 해결책 제시의 어려움

SSL-VPN은 기본 웹 브라우저만 있으면 어디서든 간편하게 VPN을 접속할 수 있다는 점에서 사용자들은 별도의 장비나 클라이언트 소프트웨어 없이 브라우저를 통해 접속하면 되기 때문에 IPSec VPN에 비해 사용 및 관리가 편리하고 비용 절감도 가능하다. 센터에 설치된 SSL-VPN 장비와 연동해 클라이언트가 없는 클라이언트리스(Clientless) VPN 구축이 가능하다는 점에서 일반 사용자, 특히 협력사, 이동 사용자 및 재택 근무자들을 위한 최적의 솔루션으로 평가 받고 있다.

SSL VPN이란
SSL(Secure Sockets layer)은 웹 서버와 웹 브라우저간의 안전한 통신을 위해 넷스케이프에서 제창한 프로토콜로 인터넷 익스플로러, 넷스케이프 네비게이터와 같은 웹 브라우저에 기본적으로 탑재돼 있는 보안 표준 프로토콜이다. SSL은 오늘날 온라인 상거래, 웹서비스, 그리고 안전한 애플리케이션 계층 액세스를 포함하는 많은 다른 네트워크 기능을 위해 보안을 제공하는 인터넷 보안 프로토콜의 선두주자다.
현재 SSL의 2.0, 3.0, 3.1(TLS 1.0)이 사용되고 있으며, 아래와 같은 중요한 보안 기능들을 사용해 인터넷 등 공개된 네트워크상에서 민감한 데이터의 전송을 가능하게 한다.

·상호인증 : 클라이어트와 서버간의 상호 인증(RSA, DSS, X.509 )
·기밀성 : 대칭키 암호화 알고리즘을 통한 데이터의 암호화(DES, 3DES, RC4등)
·데이터 무결성 : MAC기법을 이용해 데이터 변조 여부 확인(md5,SHA-1)

SSL VPN의 기술적 특징
지난 몇 년 동안의 기술적인 동향은 안전한 네트워크 액세스를 위해서 저가의 광대역 서비스를 통한 인터넷과 암호화 기술을 사용하는 것이었다. 특히 기업 및 기관들이 업무적인 생산성을 개선하고 비용 절감 차원에서 전용선과 모뎀 설비를 광대역으로 대체하기 시작했다.
인터넷 연결성의 편리성으로 인해 언제 어디서든 네트워크 접속이 용이해지면서 통신의 비밀을 보장하기 위해 암호화를 사용하는 동안, 기업은 재택 근무자, 원격 근무자 또는 이동 근무자들을 위해 내부 컴퓨팅 자원을 효율적으로 액세스하게 해줘 전반적인 네트워크 및 컴퓨팅 환경에 대한 비용의 절감을 실현할 수 있었다.
안전한 네트워크(리모트) 액세스를 요구하는 대표적인 유형을 든다면, 첫째로, 인트라넷 액세스(재택 근무, 출장, 호텔 혹은 고객 사이트에 있는 이동 직원) 둘째로, 엑스트라넷 액세스(고객 ,협력사, 계약직 및 임시직원과 같은 외부인 또는 비직원)을 들 수 있다. 아래의 몇 가지의 기술들은 인터넷을 통해 리모트 액세스를 안전하게 해주는 보편화된 기술 중 가장 광범위하게 적용되는 기술이다.

· 네트워크 레이어 기술 : 일반적인 IPSec VPN에서 채택한 기술IPSec/IKE(Internet Key Exchange) 사용
· 트랜스포트 레이어 기술 : SSL VPN에서 채택한 기술, SSL을 사용하는 SOCKS
· 애플리케이션 레이어 기술 : SSL VPN에서 채택한 기술, SSL상에서 작동되는 HTTP(대부분의 웹 브라우저에 포함된 기술)

SSL VPN은 사용자와 SSL VPN 장비 사이의 안전한 데이터의 교환을 위해 애플리케이션 계층에서 SSL을 이용한 암호화 서비스를 제공함으로써 기존 VPN의 문제점인 네트워크와 방화벽을 통과할 경우 발생하는 포트 블럭(Port Block)과 같은 문제점을 해결한다. 또한 SSL VPN은 클라이언트리스 VPN이라고 부르기도 하는데 그 이유는 오늘날 대부분의 표준화된 웹 브라우저는 HTTP와 HTTPS(SSL)를 기본적으로 모두 지원하므로 IPSec 리모트 VPN과는 대조적으로 사용자 측면에 VPN 클라이언트의 설치, 구현, 그리고 지원과 함께 결부된 모든 문제들을 해결할 수 있다.
SSL은 웹 브라우저와 웹 서버간의 안전한 통신을 위해 넷스케이프에서 개발됐고, 애플리케이션에서 암호화가 이뤄지기 때문에 하위 레이어의 다양한 프로토콜 및 응용 프로그램의 지원에 제한을 받게 된다. 그래서 SSL VPN업체들은 초창기 웹 및 웹 기반의 애플리케이션만을 지원했으며, 고객 및 시장의 확장성을 위해 대부분의 SSL VPN 업체들은 기업의 다양한 애플리케이션을 지원하기 위한 기술 투자에 많은 시간을 투자해야 했다. SSL VPN을 이용한 서비스의 지원 발전 단계는 다음과 같이 3단계로 발전해왔다.

1) 초기 단계 : 웹, 웹 기반의 애플리케이션, 파일 공유 지원
2) 확장 단계 : 클라이언트/ 서버 애플리케이션 지원
3) 성숙 단계 : UDP 트래픽, 네트워크 레이어 트래픽 지원

현재 SSL VPN은 웹, 웹 애플리케이션, 메세징 클라이언트, 이메일, 파일 공유, 클라이언트/서버 애플리케이션 등 기업의 핵심적인 모든 업무 형태를 모두 지원함으로 업무 적용의 한계가 완전히 극복된 상태며, 자체적으로 DMZ 서비스를 지원해 인트라넷의 사설 IP 네트워크 구성 시에도 정상적인 서비스 구현이 가능하다. 또한, 다양한 암호화 기법(DES, 3DES, RC4)과 데이터 무결성 기법(MD5, SHA-1)을 모두 지원한다.

IPSec과 SSL VPN의 비교
기본적으로 IPSec과 SSL VPN은 기업의 중요한 데이터를 보호하는 기능, 즉 데이터의 기밀성 및 무결성 등의 기능은 동일하며, 단지 데이터의 암호화를 구현하는 방식의 차이가 있을 뿐이다. IPSec VPN과 SSL VPN은 서비스 측면에서 상호 보안 관계이며, 서비스의 형태는 다음과 같이 분리해 볼 수 있다,

1) 고정성 인터넷 사이트 투 사이트(Intranet Site-to-Site) VPN
2) 이동성 인터넷 사이트 투 클라이언트(Intranet Site-to-Client: 리모트 클라이언트 VPN)
3) 이동성 엑스트라넷 사이트 투 클라이언트(Extranet Site-to-Client: 리모트 클라이언트 VPN)

고정성 VPN은 본사와 지사간에 특정 장소에서 VPN을 구현하며, 이동성 VPN은 센터(본사)의 고정된 장소와 사용자의 위치가 계속 바뀌는 경우에 구현하는 VPN이다. IPSec VPN은 반드시 리모트에 하드웨어나 소프트웨어가 필요하므로 신뢰할 수 있는 네트워크(본사-지사) 간의 고정성 사이트 투 사이트 형태에 적합하며, 신뢰할 수 없는 네트워크와 신뢰할 수 있는 네트워크(본사)와의 VPN 구현에는 적합하지 못하다.

또한, 리모트 컴퓨터상에 VPN 클라이언트 소프트웨어를 반드시 설치해야 하므로 설치, 관리 및 유지보수 등의 문제점을 가지고 있다. SSL VPN은 이동성 사용자에게 아주 적합한 암호화된 리모트 액세스 방법을 제공한다. 정리하면, SSL VPN의 장점은 다음과 같다.

·기업 자원을 액세스하는데 사용되는 장비로 다운로드할 필요가 없다.
·엔드 유저가 설정 작업을 수행할 필요가 없다.
·표준 웹 브라우저가 있는 곳이라면 어디서든 사용할 수 있기 때문에 사용자가 업무용 랩톱을 보유하지 않아도 된다.
·OS 독립적이다.
·액세스를 세부적으로 제어할 수 있기 때문에 사용자들은 권한이 있는 자원과 애플리케이션만을 볼 수 있다.

SSL VPN은 이와 같이 웹 브라우저에서 이용 가능한 SSL을 활용해 저가의 광대역 서비스를 통해 언제, 어디서나 손쉽게 인터넷을 통한 VPN을 구성하는 액세스 기술이며, 시장 조사 기관인 메타그룹이 발표한 자료에 의하면 향후 3년 안에 SSL VPN이 리모트 클라이언트 VPN 서비스의 80% 이상을 차지할 것으로 전망하고 있다.

[NETWORK TIMES 황인각 주니퍼코리아 기술팀 차장]

출처 : http://shadowxx.egloos.com/2333411

빅데이터 시대, DB·데이터 암호화 솔루션 길라잡이

JAESOO — Tue, 28 Apr 2015 15:16:59 +0000

입력날짜 : 2015-04-26 23:55

의료·금융·제조 분야에 암호화 필요한 데이터 많아...시장 확대 기대_
2014년 640억원 규모...관련 업체, 새로운 분야 적극 개척 나서

[보안뉴스 김태형] 지난해 카드사 정보유출 사고 이후 개정된 개인정보보호법에 따라 인터넷 구간 외에 내부 인사 시스템 등에서도 개인정보를 암호화하도록 규제가 강화됐다. 이에 따라 개인정보보호법상의 고유식별번호, 즉 주민등록번호에 대한 암호화뿐만 아니라 정부의 행정 시스템에도 개인정보보호를 위한 암호화가 의무화된 상태다.

이와 같이 개인정보 유출방지와 보안 강화를 위한 데이터 암호화는 기존의 DB 외에도 CCTV 영상정보나 금융분야의 로그데이터, 병원의 의료영상 및 이미지 등과 같은 비정형 데이터 암호화에 대한 관심도 높아지고 있어 빅데이터 시대의 가장 큰 보안이슈는 ‘데이터 암호화’라고 할 수 있다.

이에 따라 국내 DB·데이터 암호화 시장도 지난 몇 년간 급성장을 거듭해 왔다. 최근에는 기존 DB암호화에서 보안이 필요한 다양한 데이터의 증가로 인해 암호화 시장은 서서히 빅데이터로 이동하고 있다. KISA가 발표한 ‘2014 국내 정보보호산업 실태조사’에 따르면, 국내 DB암호화 시장의 2013년 매출은 607억 9백만원으로 집계됐으며, 2014년 매출은 약 640억 9300만원으로 5.6% 증가했다고 밝혔다.

또한 DB암호화는 종사자가 50인 이상 100인 미만인 기업의 매출이 172억 1600만원, 100인 이상인 기업의 매출이 248억 9800만원으로 나타났으며 일반기업의 매출액이 벤처기업의 매출액보다 높은 것으로 나타났다. 특히, DB보안은 공공부문 매출이 42.1%, 서비스부문이 25.1%로 주로 공공부문의 수요가 높은 제품으로 나타났다.

이와 관련 보메트릭코리아 이문형 지사장은 “빅데이터 및 IoT 시대를 맞아 각종 디바이스로 모아지는 다양한 데이터에 대한 보안을 강구하지 않으면 유출 시에는 큰 피해로 이어질 수 있다. 이로 인해 기존 법·규제 준수를 위한 DB보안뿐만 아니라 모든 중요 데이터의 암호화를 통한 고도화가 필요하다”고 강조했다.

보메트릭의 암호화 솔루션 보메트릭 인크립션(Vormetric Encryption)은 컬럼 단위가 아닌 파일 단위의 커널방식으로 암호화를 진행한다. 일반적인 암호화 솔루션은 컬럼 단위로 암호화를 지원하는 경우가 많지만 기존 컬럼 기반의 암호화로는 빅데이터의 대부분을 차지하고 있는 로그파일이나 SNS·이미지 파일과 같은 비정형 데이터 보호에는 한계가 있어 커널 방식이 유리하다는 게 보메트릭 코리아 측의 설명이다.

또한, 케이사인 구자동 부사장은 “지난해 카드사 고객정보 유출사고 이후 개정된 개인정보보호법은 인터넷 구간 외에 내부 인사시스템 등에서도 개인정보 암호화를 하도록 강화됐다. 하지만 아직까지 개인정보 암호화를 하지 않은 곳도 많기 때문에 올해에는 공공·금융 분야의 DB암호화에 집중해 나갈 계획”이라고 말했다.

케이사인의 통합 데이터베이스 보안 솔루션 ‘KSignSecureDB’는 데이터 암호화, 접근제어 및 로그감사를 통해 기업내 중요 데이터를 보호한다. 특히, 컬럼 단위로 암호화해 DB유출을 방지하고 세분화된 접근제어 기능을 제공하는 것이 특징이다.

이와 함께 펜타시큐리티 디아모(D’Amo)는 지난 2013년부터 의료영상에 대한 보안 솔루션을 제공하고 있다. 최근 들어서는 의료영상 데이터 보안에 대해서도 관심이 높아짐에 따라 이미지 전용 암호화 기능이 포함된 디아모(D’Amo) 솔루션으로 암호화 시장 확대를 이끌면서 적극적인 영업전략을 펼치고 있다.

펜타시큐리티 기획실장 김덕수 상무는 “DB암호화 시장은 2012년 이후부터 꾸준히 두 자리수 이상 성장하고 있으며 개인정보보호법으로 인한 컴플라이언스 이슈가 시장 확대를 주도하고 있다”면서 “DB를 포함해 기업에서 사용하는 각종 중요 데이터를 암호화하기 위해서는 각 기업이 사용하고 있는 IT 시스템을 충분히 검토하고 해당 환경에 적합한 암호화 솔루션을 설치해야만 보안은 물론 서비스의 안정성과 성능까지 보장받을 수 있다”고 말했다.

이어서 그는 “고객 입장에서는 암호화를 고려하는 데이터의 종류와 데이터를 담고 있는 시스템 환경 등 총체적인 IT 시스템 구조를 파악하고 해당 시스템에 가장 적절한 방식의 암호화 솔루션을 도입해야만 한다”면서 “펜타시큐리티의 통합 데이터 암호화 솔루션 D’Amo는 2004년에 국내 처음 출시한 암호화 솔루션으로서 2,900여건의 데이터 암호화 구축 레퍼런스를 보유하고 있다”고 덧붙였다.

▲ 국내외 주요 DB암호화 제품과 기능(업체명 가나다순)

또한, 소프트포럼의 암호화 솔루션 제큐어웹(XecureDB)은 정보유출 시에도 데이터 기밀성을 보장하는 DB암호화 솔루션으로, 국정원에서 안전성을 검증한 알고리즘을 사용해 인덱스를 암호화하기 때문에 고성능·안전성을 보장하는 것이 특징이다.

이글로벌 큐브원(CubeOne)의 경우 API, Plug-In 방식을 모두 지원하는 대표적인 암호화 솔루션이다. 이 외에도 DB 암호화 솔루션에는 신시웨이의 ‘페트라 사이퍼(Petra Cipher)’, 이니텍의 ‘세이프DB(SafeDB)’, 세이프넷 데이터시큐어(Data Secure) 등이 있다.

앞으로 빅데이터와 사물인터넷의 확산 등으로 데이터는 더욱 증가하고, 다양화될 것으로 보인다. 이로 인해 이제는 기본 DB 암호화 뿐만 아니라, 로그 정보, 금융거래 정보, CCTV 영상정보, 의료정보, 이미지 등 다양한 데이터에 대한 암호화가 요구되면서 DB암호화 솔루션 시장은 계속 확대될 것으로 전망된다.

한편, 오는 6월 30일 행정자치부 주최로 서울 삼성동 코엑스 그랜드볼룸에서 개최되는 ‘2015 개인정보보호 페어 & CPO워크숍’(http://www.pisfair.org/)에서는 공공기관을 비롯해 의료, 교육, 금융 분야에서 활용되는 각종 DB 및 데이터의 효율적인 암호화 방안 등은 물론 개인정보보호를 위한 각종 체크리스트와 보안대책들이 구체적으로 논의될 예정이다.

[김태형 기자(boan@boannews.com)]

출처 : http://www.boannews.com/media/view.asp?idx=46033

시스코 네트워킹 part 8-2 (Back to Back)

JAESOO — Thu, 16 Apr 2015 15:40:59 +0000

Back to Back - 원래 환경에서는 전화국에 요청해서 전용선을 설치하고 서로 라우터를 연결하면 되지만 실습실에 전용선을 설치할 수 는 없고 그래서 만드는 구성

즉 라우터와 라우터를 서로 직접 연결하면서 마치 전용선 구간에서 연결한 것처럼 만드는 기술

원래 전용선을 사용하기 위해선 라우터 뒤에 모뎀 장비인 DSU/CSU가 붙고 그 뒤에 전용선을 연결함.

하지만 Back to Back 구성에서는 라우터 대 라우터 V.35 케이블만을 가지고 서로 연결

실제 구성에서는 라우터의 시리얼 인터페이스에 V.35 케이블을 연결하고 한쪽 끝은 DSU/CSU에 연결

DSU/CSU는 전용선에 연결, 상대편도 마찬가지로 구성

이러한 실제 구성에서 라우터는 DTE 장비가 되고, DSU/CSU는 DCE 장비가 되기 때문에 이때 라우터에 사용하는 V.35 케이블은 DTE 케이블임.

그러나 실습환경에서는 중간에 DSU를 놓고 또 전용선을 연결하는 이러한 실제 구성이 불가능

Back-to-Back구성에서는 전용선과 DSU/CSU를 생략하고 직접 라우터 대 라우터를 V.35 케이블을 이용해서 연결

이때 중요한 것은 라우터 A나 라우터 B 둘 중 하나가 반드시 DCE로 동작해야 한다는 것

이 때 어느쪽 라우터가 DCE이고 어느쪽 라우터가 DTE인지를 알아보는 방법이 있음

Router#show controller interface interface-number

Router-b#show controller serial 0

HD unit 0, idb = 0x8E6AC, driver structure at 0x92848

이렇게 show controller 명령을 수행해서 DTE와 DCE를 확인 후, DCE 케이블이 연결되어 있는 라우터의 인터페이스 구성 모드로 들어가서 다음 구성을 추가

Router-B(config)#int s 0

Router-B(config-if)#clockrate 56000

여기서 Clockrate 값은 바로 두 라우터 간의 회선 속도가 됨. 방금과 같은 경우 56kbps의 속도로 연결된 것

출처 : http://headvoice.tistory.com/100

라우터 DTE - DCE (CSU/DSU) 구성

JAESOO — Thu, 16 Apr 2015 15:37:47 +0000

실제구성

라우터(DTE)--(V.35 CABLE)--DSU/CSU(DCE)--WAN--DSU/CSU(DCE)--(V.35)--라우터(DTE)

=> V.35 케이블을 이용해서 DSU/CSU 장비에 접속하고 이 장비들이 다시 WAN 으로
접속을 하는것 입니다

백투백

라우터--(V.35 CABLE : DTE)====(V.35 CABLE : DCE)--라우터

=>결국 두 라우터를 직접 연결해서 전용선 구간에서 연결한것 처럼 하는것입니다
그러기 위해서는 DTE/DCE V.35 CABLE 이 필요합니다
(결국에는 랜의 크로스 케이블하고 같은은것 입니다)
글구, DCE 장비에 CLOCK RATE 설정해야 통신이 가능합니다

=============================================================================

DCE (Distributed Computing Environment; or Data Communication Equipment)

네트웍 컴퓨팅에서, DCE[디씨이](Distributed Computing Environment ; 분산 컴퓨팅 환경)는 분산 컴퓨터들의 시스템 내에서 컴퓨팅 및 데이터 교환을 설정하고 관리하는데 필요한 산업표준 소프트웨어 기술이다. 일반적으로 DCE는 여러 가지 다른 크기의 서버들이 지리적으로 퍼져있는 대형 컴퓨터 시스템의 네트웍 내에서 사용된다. DCE는 클라이언트/서버 모델을 사용한다. DCE를 사용하면, 사용자는 원격지의 서버에 있는 응용프로그램과 데이터를 쓸 수 있다. 프로그래머들은 그들의 프로그램이 어느 곳에서 실행되는지 또는 데이터가 어디에 위치해 있는지 등에 대해 전혀 신경을 쓸 필요가 없다.
DCE 설정시에는 대부분, 필요할 때 DCE 응용프로그램과 관련 데이터들을 찾을 수 있도록 분산 디렉토리를 준비하는 것이 필요하다. DCE는 보안지원을 포함하며, 몇몇 제품들은 IBM의 CICS, IMS 및 DB2 데이터베이스들과 같은 보편적인 데이터베이스에 접근하기 위한 지원을 제공한다.
DCE는 몇몇 회원사들이 기여한 소프트웨어 기술을 사용하여, OSF (Open Software Foundation)에 의해 개발되었다.

컴퓨터 통신에서의 DCE (Data Communication Equipment ; 데이터 통신 기기)는 모뎀이나 다른 직렬장치들이 컴퓨터와 데이터를 주고받기 위해 사용하는 RS-232C 인터페이스를 의미한다. DCE 인터페이스와 DTE 인터페이스간의 관계에 대해 좀더 자세한 정보를 알기 원하면 RS-232C를 찾아 보라.

---------------------------------------------------------------------------------
DTE (Data Terminal Equipment) ; 데이터 단말 장치

컴퓨터 데이터 통신에서, DTE[디티이]는 컴퓨터가 모뎀이나 기타 다른 직렬장치를 이용하여 데이터를 교환하기 위한 RS-232C 인터페이스이다. DTE 인터페이스와 DCE 인터페이스에 관한 좀더 자세한 정보는, RS-232C를 참조할 것.

---------------------------------------------------------------------
CSU/DSU (Channel Service Unit/Digital Service Unit)

CSU/DSU는 근거리통신망에 사용되는 통신기술로부터 나온 디지털 데이터 프레임들을 광역통신망에 보낼 수 있도록 적절한 프레임으로 변환하는 외장형 모뎀 크기의 하드웨어 장치이다. 예를 들어, 만약 자신의 집에서 웹 관련 비즈니스를 하려면 T-1 정도의 디지털 전용회선을 전화회사로부터 빌려야하는데, 이때 자신의 집과 전화회사에 각각 1개씩의 CSU/DSU를 설치해야한다.

CSU는 광역통신망으로부터 신호를 받거나 전송하며, 장치 양측으로부터의 전기적인 간섭을 막는 장벽을 제공한다. CSU는 또한 전화회사에서 테스트 목적으로 보내는 신호에 대해 루프백 반향을 할 수 있다. DSU는 회선제어를 관리하고, RS-232C, RS-449 또는 근거리통신망으로부터의 V.35 프레임들과 T-1 회선상의 TDM DSX 프레임 사이의 입출력을 변환한다. DSU는 타이밍 에러와 신호재생을 관리한다. DSU는 DTE로서 컴퓨터와 CSU 사이에서 모뎀과 같은 인터페이스를 제공한다.

CSU/DSU는 별개의 제품으로 만들어지지만, 때로는 라우터와 함께 통합되기도 한다. CSU/DSU의 DTE 인터페이스는 보통 V.35나 RS-232C 또는 이와 비슷한 직렬 인터페이스와 호환성이 있다. CSU/DSU 제작자로는 시스코, 메모텍 및 Adtran 등이 있다.

시스코는 DSU/CSU라는 용어를 더 선호한다. CSU라는 용어는 AT&T가 자신들의 비교환 디지털 데이터시스템의 인터페이스를 부르는 데에서 유래되었다. DSU는 표준 인터페이스를 사용한 DTE의 인터페이스를 제공하며, 또한 테스팅 기능도 제공한다

-----------------------------------------------------------------------------
V.xx telephone network standards ; V.xx 전화망 표준

ITU-T로부터 나온 V 시리즈 권고안이 아래 표에 요약되어 있다. 여기에는 일반적으로 사용되는 모뎀 표준과 다른 전화망 표준의 대부분이 포함된다. ITU-T 표준 이전에는, AT&T와 Bell System 등이 저속 전송속도에 대한 자사 나름대로의 표준을 제시했었다. 또다른 일련의 표준들인 MNP 클래스 1부터 10까지(클래스 8은 없다)는 일정 기간 통용 되었으나, 그러나 세계표준이 개발되면, 다른 것들은 모두 사라지고, 표준을 따르는 제품만이 계속 세를 확장한다 (일부 모뎀은 MNP와 ITU-T 표준을 모두 지원한다).

일반적으로, 모뎀은 "핸드셰이킹"을 통해, 두 모뎀이 모두 성취할 수 있는 속도 중에서, 가장 높은 표준 속도로 통신할 것에 합의하게 된다.

V.22bis로 시작한 ITU-T 전송 속도는 2400 bps의 배수로 증가한다 (아래 표의 표준 번호 중에서 bis란 "버전 2"를 의미하고, terbo란 "버전 3"을 의미한다).

표 준	의 미
V.21	일본과 유럽에서 통용되던 300 보오 속도의 전이중 통신방식 표준이다. 미국에서는 V.21 대신 Bell 103이 사용되었다.
V.22	600 보오에서 1200 bps의 속도를 제공
V.22bis	진정한 세계 최초의 표준으로서, 600 보오에서 2400 bps의 속도를 제공
V.32	2400 보오에서 4800~9600 bps의 속도를 제공
V.32bis	14400 bps의 속도를 제공하지만, 속도를 12000, 9600, 7200 및 4800 bps 등으로 낮출 수 있다
V.32terbo	19200 bps의 속도를 제공하지만, 속도를 12000, 9600, 7200 및 4800 bps 등으로 낮출 수 있다. 압축을 통해 더 빠른 속도에서 동작할 수 있다. CCITT/ITU 표준이 아니었다.
V.34	28800 bps의 속도를 제공하지만, 속도를 24000, 19200 bps 등으로 낮출 수 있다. V.32 및 V.32bis 등과 호환성이 있다.
V.34bis	33600 bps의 속도를 제공하며, 속도를 31200 bps 또는 V.34의 전송 속도로 낮출 수 있다.
V.35	19200 bps 속도 이상에서 동작하는 네트웍 액세스 장비와 패킷 네트웍 사이의 트렁크 인터페이스이다. V.35는 여러개의 전화회선들에 대한 대역폭을 하나의 하나의 그룹으로 사용할 수 있다.
V.42	V.32 및 V.32bis 등과 전송 속도가 같지만, 더 나은 에러 교정 기능이 있어서, 좀더 신뢰도가 높다.
V.90	하향으로는 56000 bps까지 지원한다 (그러나, 실제로는 다소 떨어진다). 3Com의 x2 기술과 록웰의 K56flex 기술에서 나왔다

산업계 표준인 ISDN은 전화선 상에서 128 Kbps의 속도를 제공하기 위하여 디지털로 바꾸는 방법을 사용한다. 다른 기술인 DSL은 더욱 빠른 전송속도를 제공한다.

출처 : http://blog.pages.kr/191

CSU (Channel Service Unit, 채널 서비스 장치)

JAESOO — Thu, 16 Apr 2015 15:36:06 +0000

☞ CSU(Channel Service Unit)

CSU는 Channel Service Unit의 약자로 T1 또는 E1 트렁크를 수용할 수 있는 장비로서 각각의 트렁크를 받아서 속도에 맞게 나누어 분할하여 쓸 수 있는 장비이다. Channel Service에서 Channel이란 한 개의 채널에 64kbps 또는 56kbps의 전송속도를 갖는 것을 말한다. 보통 64kbps를 1채널로 본다. 그래서 128K는 64kbps 두개의 채널을 사용해 128Kbps 속도를 낸다. 256K 나 512K도 마찬가지로 전송로에 할당된 채널 여러개를 사용해서 전송속도를 낸다. 그리고 실제 전송할때 각의 채널이 따로따로 전송되는 것은 아니라 Mux라는 집중 장비가 여러개의 채널들을 모아서 하나의 대용량 전송로를 통하여 한꺼번 에 전송되는 트렁크 방식으로 전송이 된다. 그러므로 CSU는 바로 이러한 트렁 크라인(T1이나 E1)을 그대로 수용할 수 있는 장비이다.

전송방식의 차이로 T1은 24channel이 가능하고 E1은 30channel을 수용할 수 있다. 연결된 T1 이나 E1 전송로는 CSU의 옵션에 따라서 채널수가 지정되고 정해진 채널수에 따라서 그에 따르는 전송로의 전송속도가 결정된다. 그러나 한쪽에서 T1-MUX에서 분기되고 다른쪽에 E1-MUX에서 분기가 된다면 사용 할 수 없다. 이것은 CSU가 T1과 E1 채널이 서도 다르기 때문이다.

▶CSU는 T1,E1을 접속하여 내부에서 채널옵션에 따라 512K등 고속전송을 한다. 그리고 여러 개의 고속채널들은 Mux 집중화 장치로 연결되면서 하나의 트렁크라인으로 모여서 전송되는데 이것을 트렁크 전송이라한다

개요

  CSU DS2000D는 T1/E1 서비스에 접속 가능한 단일 PORT의 Fractional T1/E1 겸용 장비로
  회선의 효율적인 확장을 위해 T1 또는 E1 회선으로의 절체시 물리적인 변경없이
  Key 스위치의 조작만으로 변경하여 사용할수 있다.

규격

  º   Fractional T1/E1 인터페이스
  º   N x 56 또는 N x 64Kbps 속도선택
  º   전면 패널 제어 및 콘솔 포트로 유지 보수
  º   T1 운용시 D4(SF) 또는 ESF Frame으로 운용가능
  º   T1 운용시 ESF는 CRC-6 Frame 으로 운용가능
  º   T1 운용시 CODE는 AMI 또는 B8ZS로 운용가능
  º   E1 운용시 CODE는 AMI 또는 HDB3로 운용가능
  º   E1 운용시 CRC-4 Frame으로 운용 가능하며,
       - CAS 방식 사용할 때 속도는 56 ~ 1,920 kbps로
       - CCS 방식 사용할 때 속도는 56 ~ 1,984 kbps로 운용가능
  º   광 가입자 전송장치(FLC) 와 LOOPBACK 연동 가능
  º   타사 T1/E1 CSU장치와 기능적 호환 가능
  º   Console port를 이용한 CSU 제어 기능
  º   E1 운용시 Remote config 제어 기능
  º   T1 CSU는 DSX 및 CSU모드 사용 가능
  º   다양한 LOOPBACK 기능
      (LTL ,RTL,RCHL,TP,LLB,NLB, RCLB)
  º   Free Volt 전원 공급기의 채용으로 110/220V 구분없이 사용가능

구분	T1 CSU규격	E1 CSU 규격
전송방식	4선식 전이중방식	4선식 전이중방식
FRAME	ITU-T G.704(D4,ESF)	ITU-T G.704(CRC-4,FRAME가능)
LINE CODE	ITU-T G.703(AMI,B8ZS)	ITU-T G.703(AMI,HDB3)
선로 속도	1.544Mbps + 32ppm	2.048Mbps + 32ppm
선로 임피던스	100Ω ± 10%	120Ω ± 10%
DTE Rate	56 X N, 64 X N (N=1~24)	CAS : 56 X N, 64 X N(N=1~30) CAS : 56 X N, 64 X N(N=1~31)
전송속도	56Kbps ~ 1,536KBPS	CAS : 56Kbps ~ 1,920KBPS CAS : 56Kbps ~ 1,984KBPS
LBO	O, -7.5, -15, -22.5dB	NO
선로 구동거리	1.2Km(24AWG)	0.8km(24AWC)

LINE Interface	RJ-48
SYSTEM CLOCK	자체, 수신 ,외부
DTE Interface	ITU- TV. 35
소비전력	110V/220V/60Hz(13.9W)
크기	205mm(D)x 300mm(W)x 47mm(H)

CSU DS2000D구성도

TD	송신 데이터
RD	수신 데이터
RTS	Request To Send의 약자로 DTE가 DCE에 데이터 송신 요구를 표시
SYNC	전송로상의 반송파를 정상적으로 감시, 만약 SYNC가 깜빡거리면 전송로상의 문제가 있는 것이다.
RED	SYNC가 점멸하거나 꺼져 있는 경우에 빨간색 램프가 들어온다. 테스트 스위치 (LOOPBACK SWITCH)
CHANNEL LOCAL	일반적으로 DSU의 자체 테스트와 같은 의미로 자국으로 자체 루프하여 CSU장비 자체를 테스트하는 스위치
CHANNEL REMOTE	원격 루프 테스트로 장비와 대응되는 장비까지 루프 테스트는 것으로 전송로 구간을 전부 테스트 할 수 있다.

◈ CSU LED 표시 설명 표시램프 의미 [CSU ONS-150]

출처 : http://www.dasanic.co.kr/csu_kor.html

L2 MPLS VPN (AToM/EoMPLS)

JAESOO — Thu, 16 Apr 2015 15:33:27 +0000

!- '최신 MPLS/피터전' 책에서 발췌한 내용으로 전반적인 MPLS에 궁금증은 책을 사보시길 권합니다.

@ L2 MPLS VPN(AToM, any transport over MPLS)

L2 MPLS VPN은 IP주소를 기존의 MPLS 망을 통하여 이더넷, ATM, PPP, HDLC, 프레임 릴레이 등의 L2 프레임을 전송

AToM 은 다시 전송 프로토콜에 따라 EoMPLS(ethernet over MPLS), PPPoMPLS(PPP over MPLS)등 으로 구분

L2 VPN은 L2 장비간의 가상회선별로 라벨을 할당한다.

L2 MPLS VPN을 지원하려면 MPLS 백본망이 다음과 같이 구성되어야 한다.

- 백본에 IP 라우팅이 설정되어 PE 라우터들이 상호간 IP로 연결되어야 한다.

- 코어에 MPLS가 설정되어 PE 라우터들 상호간 LSP(Label switched path)가 존재해야 한다.

L2 MPLS VPN을 이용하여 이더넷 프레임을 전송하는 EoMPLS(ethernet over MPLS)를 사용하는 경우

PE-CE간의 링크는 802.1Q만 지원된다. ISL은 지원되지 않는다.

!- 아래는 CCNP ROUTE 과정에 OSPF 에서 나오는 EoMPLS 에 대한 간략한 소개

!- 아래 참고 http://blog.naver.com/hts8376/100004760678

* EoMPLS 대두 : VLAN 확장성 문제, MAC 주소 학습 문제, QoS, 망 복구 능력에 대한 대한 기술로 대두.

Point-to-point 이더넷 전용회선을 MPLS 망을 통해 L2로 제공할 수 있는 방안 제공

===========================

간단한 EoMPLS port mode(가입자 Access port로 구성)

기초 전제 이해 (MPLS 이해 및 기초 실습 Lab) http://mongu2.blog.me/140045370052

IOS : unzip-7206-ram512-c7200-adventerprisek9-mz.150-1.M3.bin , unzip_nm16esw_128ram-c3660-is-mz.124-15.T11.BIN

PE1,PE2 는 7206, A_Seoul,B_Busan 은 3660 사용

1. 기본 설정, PE1, PE2의 Lo0, F0/1은 중앙에서 eigrp 1 으로 광고하는 네트워크 이다.

=> PE1,PE2) sh ip eigrp nei, sh ip route

2. mpls 설정, PE1, PE2의 f0/1 을 MPLS 기능을 활성화 하시오.

=> sh mpls neighbor 등등

3 EoMPLS(Layer2 port mode) 구성

=> sh ip ro, sh mpls l2transport vc default, sh mpls l2transport summary

4. 회사 A를 위한 OSPF 구성 후 통신 확인

====================

1. PE1,PE2간 eigrp 1 설정

PE1,PE2)

router eigrp 1

no auto

net 1.0.0.0

passive-interface f0/0

!- 확인sh ip ro, ping lo0주소

2. PE1,PE2에 MPLS 설정

PE1,PE2)

mpls label protocl ldp

mpls ldp router-id lo0

int f0/1

mpls ip

!- 확인 sh mpls ldp nei

!- sh mpls forwarding-table

3. EoMPLS 설정

PE1)

int f0/0

xconnect 1.1.2.2 25 encapsulation mpls

PE2)

int f0/0

xconnect 1.1.1.1 25 encapsulation mpls

!- 확인 sh mpls l2transport summary, sh mpls l2transport vc 25 (detail)

4. CE1,CE2에 ospf 설정

=======================

!- 2. MPLS 네이버 확인

!- 3. EoMPLS 설정

!- EoMPLS 확인

!- 가입자 라우터의 라우팅 테이블 및 OSPF 네이버 확인

!-사업자 라우터(PE1)의 라우팅 테이블

!-서울 라우터쪽에서 부산 라우터쪽으로 ping 시 CE-PE 구간 패킷(그냥 일반 패킷)

!-PE1/PE2 구간의 MPLS 망에서는 가입자의 패킷을 MPLS에 감싸서 전달하게 된다. 가입자 end 도착 후 구분은 VC로 한다.

* 이외에도 CE들과와 PE간 Trunk 구간을 설정하여 VLAN tag 를 구분해서 Virtual Circuit 를 연결해주는 EoMPLS 구성도 있다.

첨부파일 : 패킷, 라우터 설정 파일

EoMPLS.rar

출처 : http://sola99.tistory.com/161

[기술자료] 전용선

JAESOO — Thu, 16 Apr 2015 15:24:49 +0000

전용선 방식및 프로토콜에 대한 설명입니다.

.. Ear / Mouse 를 말합니다.
양쪽 교환기 모두 E/M 카드가 꽂혀야 합니다.
1CH 이 4선식 (2WE/M) 이고, 6선식은 (4W E/M) 입니다.
선 연결방법은
4선식은 편의상, L1,L2,E선,M선이라고 하면,
양쪽 L1,L2는 극성에 상관없이 서로 연결하구요(음성,VOICE선이라고 함)
E선과,M선은 서로 엇갈리게 연결하면 됩니다(신호선이라고 함)

위는 2W E/M 이구요 4W E/M은 음성(L1,L2)을 분리한 것입니다.
선 연결방법은 E선M선은 위와 같구요. VOICE선은
L1,L2(음성 송신),L3,L4(음성 수신) 처럼 4선식이므로,
우리측 L1,L2(송신)는 상대측 L3,L4(수신)에 연결하고,
우리의 L3,L4(수신)는 상대의 L1,L2(송신)에 연결하면 됩니다.
주로 장거리나 해외로 전용회선을 사용할 경우 음성을 분리하여, 멀리가고, 잡음에 강하도록 하기위한 방식입니다.

2W던지 4W던지 체크하는 하려면 먼저 통신접지선이 필요합니다.

2W경우 L1,L2에 톤(수화갑을 말함-빠뗀스키는 안됨)을 귀에대고
접지선을 우리쪽 E선이나, M선에 대면 우리측 교환기의 발신음이 나옵니다. 여기서 소리나는 쪽이 우리측 E선입니다.
상대측도 체크하면, 상대의 E선을 알 수 있습니다.

톤이 없으면, 테스터기로 한쪽은 접지선에 다른한쪽은 E선에 대보십시요
전압이 48V뜨는 쪽이 E선입니다.

"톤으로 찍어서 발신음이 무조건 나와야지 서로 연결할 수 있습니다."

출처 : http://yjnetworks.co.kr/bbs/board.php?bo_table=net&wr_id=83&sfl=&stx=&sst=wr_hit&sod=asc&sop=and&page=6

전용회선의 종류

JAESOO — Thu, 16 Apr 2015 15:21:07 +0000

전용회선의 종류

전용회선의 종류는 속도에 따라 다음과 같이 나뉘어집니다.

9.6K
56K
128K
256K
512K
1544K (T1)
2048K (E1)

전용회선에 사용되는 장비는 전용회선의 속도에 따라 다음과 같이 분류할 수 있습니다.

9.6K ~ 56K == DSU (Data Service Unit)
128K ~ 256K == HSM (High Speed Modem)
512K ~ 2048K == CSU (Channel Service Unit)

전용회선 서비스에 사용되는 장비는 전용회선의 종류와 제조사에 따라 많은 기종이 있으나 대부분은 상기와 같이 몇 가지로 나누어 볼 수 있습니다. 위의 종단장치 종류들은 전용회선의 속도와 구성방식에 따라서 어떤 종류를 사용하는가가 결정되지만 모두 물리적인 디지탈 회선의 양끝단에 연결합니다. 그래서 종단장치라 불리웁니다. 종단장치 하단에 있는 PC나 네트워크 장비끼리 보내는 이진 데이타를 물리적인 회선상에서 전송하고 전송받는 일을 합니다.그럼 상기 3 가지 전용회선 장비의 역할과 특징에 대해 알아봅니다.

DSU (Data Service Unit)

일반적으로 DSU는 Digital Service Unit 또는 Data Service Unit이라 합니다. 보통 PC 에서 많이 사용하는 MODEM (MOdulator DEModulator)은 아나로그 회선에서 사용하며 디지털 데이터를 아나로그 신호로 바꾸거나 그 역의 기능을 합니다. DSU는 디지털용 회선에 사용하는 장비인데 디지털 데이터를 디지털 신호로 변환해주는 역할을 합니다. 그래서 디지털 서비스 유니트 라고 부르는 것입니다. 혼동될 수도 있는 디지털 데이터와 디지털 신호는 다음과 같이 생각할 수 있습니다.

디지털 데이터 (PC 등에서 보통 사용하는 이진 데이터
0 0 1 0 1 1 0 1 0 0 0 1 0 1 0
디지털 신호 ( 전송로로 전송되기 위해 변환을 거친 신호) 흔히 pc에서 사용하는 데이터 "0" , "1" 이 실제로 물리적인 전용회선으로 전송되는 것은 아니고 전송로로 전송 되기 위해서 아래와 같이 (예를 들면 "1"은 5Volt 를 가진 파형, "0" 은 0Volt를 가진 파형) 변환됩니다. 그 변환을 하는 것이 종단장치의 역할입니다.

HSM (High Speed Modem)

고객의 수요가 점차 많은 데이터 전송이 필요해 지면서, 56K 이상의 전용회선을 사용하게 됨에따라 고속 데이터 전송용으로 나온 것이 HSM 입니다. 전용회선도 56K 한채널이 아니고 다수의 채널을 모은것을 사용합니다. 한 채널이 아니고 여러 채널로 이루어져 구성된 만큼 데이터가 한번에 지나갈 수있는 폭이 넓어진 것이므로 한번에 많은 양을 보낼 수 있기 때문에 고속 데이터 전송을 할 수 있습니다.

CSU (Channel Service Unit)

Channel Service란 의미를 이해하기 위해서는 channel의 이해가 필요합니다. 1channel은 64K bps의 전송속도를 가지는데 흔히 많이 사용하시는 56K/64K는 1ch을 사용하는 것을 의미합니다 마찬가지로 128K는 64 * 2 = 128 이므로 두개의 채널을 사용합니다. 256K 나 512K도 마찬가지로 전송로에 할당된 채널이 여러개입니다. 그래서 속도가 128K인가 256K인가는 하는것은 2개 의 채널을 사용하는가 4개의 채널을 사용하는가 라고 말할 수 있습니다.

실제적인 전송에 있어서, 각각의 단채널들이 따로따로 전송되는 것은 아닙니다. 즉, 먹스라 불리우는 집중 장비가 여러개의 채널들을 모아서 하나의 대용량 전송로를 통하여 한꺼번에 전송되는 트렁크 방식으로 전송됩니다. CSU는 바로 이러한 트렁크라인(T1이나 E1)을 그대로 수용할 수 있는 장비입니다. 전송방식의 차이로 T1은 24channel이 가능하고 E1은 30channel을 수용할 수 있습니다. 연결된 T1 이나 E1 전송로는 CSU의 옵션에 따라서 채널수가 지정되고 정해진 채널수에 따라서 그에 따르는 전송로의 전송속도가 결정됩니다. CSU는 T1, E1 라인을 접속하여 내부에서 채널을 옵션에 따라 분류하여 512K 등의 고속급 전송을 합니다.

< 트렁크 전송 구성도 >

좌우측의 채널하나 또는 여러 개의 고속급 채널들은 먹스 집중화 장치로 연결되면서 하나의 트렁크라인으로 모여서 전송됩니다. 이것을 트렁크 전송이라 합니다.

출처 : https://www.linux.co.kr/open_lecture/network/circuit/page02.htm

DSU / CSU / 라우터(router)

JAESOO — Thu, 16 Apr 2015 14:59:25 +0000

■ DSU ( Digital Service Unit 또는 Data Service Unit )

보통 PC 에서 많이 사용하는 MODEM (MOdulator DEModulator)은 아나로그 회선에서 사용하며 디지털 데이터를 아나로그 신호로 바꾸거나 그 역의 기능을 합니다. DSU는 디지털용 회선에 사용하는 장비인데 디지털 데이터를 디지털 신호로 변환해주는 역할을 합니다. 그래서 디지털 서비스 유니트라고 부르는 것입니다. 혼동될 수도 있는 디지털 데이터와 디지털 신호는 다음과 같이 생각할 수 있습니다.

- 디지털 데이터 (PC 등에서 보통 사용하는 이진 데이터 0 0 1 0 1 1 0 1 0 0 0 1 0 1 0)
- 디지털 신호 ( 전송로로 전송되기 위해 변환을 거친 신호) 흔히 pc에서 사용하는 데이터 "0" , "1" 이 실제로 물리적인 전용회선으로 전송되는 것은 아니고 전송로로 전송 되기 위해서 아래와 같이 (예를 들면 "1"은 5Volt 를 가진 파형, "0" 은 0Volt를 가진 파형) 변환됩니다. 그 변환을 하는 것이 종단장치의 역할입니다.

DSU(Digital Service Unit 또는 Data Service Unit)

컴퓨터 및 주변기기는 기계가 쉽게 인식할 수 있도록 디지털 파형을 사용합니다. 이 미세한 디지털 신호를 멀리 전송하기 위해서 디지털 전송 장비가 필요한 것 입니다. 다시 말하면, 거리가 멀면 미세한 디지털 파형은 전송 되는 도중에 왜곡 현상이 발생되어 상대방이 인식 할 수 없으므로 이를 부호화(Incoding) 하여 상대방으로 전송하고 또한 부호화되어 들어오는 정보를 원래의 신호인 디지털로 복호화(Decoding) 하는 것이 디지털 전송장비의 역할입니다. 속도등이 버젼업 된 기기들이
HSM, FDSU,HDSL(High bit rate Digital Subscriber Line)이구요.

=> 디지털 신호를 충실하게 처리, 디지털전송을 가능하게 해 주는 주요장비입니다.

■ CSU(Channel Service)

의미를 이해하기 위해서는 channel의 이해가 필요합니다. 1channel은 64Kbps의 전송속도를 가지는데 흔히 많이 사용하시는 56K/64K는 1ch을 사용하는 것을 의미합니다. 마찬가지로 128K는 64 * 2 = 128 이므로 두개의 채널을 사용합니다. 256K 나 512K도 마찬가지로 전송로에 할당된 채널이 여러개입니다. 그래서 속도가 128K인가 256K인가는 하는것은 2개의 채널을 사용하는가 4개의 채널을 사용하는가 라고 말할 수 있습니다.

실제적인 전송에 있어서, 각각의 단채널들이 따로따로 전송되는 것은 아닙니다. 즉, 먹스라 불리우는 집중 장비가 여러개의 채널들을 모아서 하나의 대용량 전송로를 통하여 한꺼번에 전송되는 트렁크 방식으로 전송됩니다. CSU는 바로 이러한 트렁크라인(T1이나 E1)을 그대로 수용할 수 있는 장비입니다. 전송방식의 차이로 T1은 24channel이 가능하고 E1은 30channel을 수용할 수 있습니다. 연결된 T1 이나 E1 전송로는 CSU의 옵션에 따라서 채널수가 지정되고 정해진 채널수에 따라서 그에 따르는 전송로의 전송속도가 결정됩니다. CSU는 T1, E1 라인을 접속하여 내부에서 채널을 옵션에 따라 분류하여 512K 등의 고속급 전송을 합니다.

CSU는 Channel Service Unit의 약자로 T1 또는 E1 트렁크를 수용할 수 있는 장비로서 각각의 트렁크를 받아서 속도에 맞게 나누어 분할하여 쓸 수 있는 장비입니다. 예를 들어 512K 인 경우는 T1, E1단위로 받은 트렁크라인 중에서 8개의 채널을 분할하여 사용하게 되는 것입니다.

좌우측의 채널하나 또는 여러 개의 고속급 채널들은 먹스 집중화 장치로 연결되면서 하나의 트렁크라인으로 모여서 전송됩니다. 이것을 트렁크 전송이라 합니다.

CSU

Channel Service Unit의 약자로 T1 또는 E1 트렁크를 수용할 수 있는 장비로서 각각의 트렁크를 받아서 속도에 맞게 나누어 분할하여 쓸 수 있는 장비이다. Channel Service에서 Channel이란 한 개의 채널에 64kbps 또는 56kbps의 전송속도를 갖는 것을 말한다. 보통 64kbps를 1채널로 본다. 그래서 128K는 64kbps 두개의 채널을 사용해 128Kbps 속도를 낸다. 256K 나 512K도 마찬가지로 전송로에 할당된 채널 여러개를 사용해서 전송속도를 낸다. 그리고 실제 전송할때 각의 채널이 따로따로 전송되는 것은 아니라 Mux라는 집중 장비가 여러개의 채널들을 모아서 하나의 대용량 전송로를 통하여 한꺼번 에 전송되는 트렁크 방식으로 전송이 된다. 그러므로 CSU는 바로 이러한 트렁 크라인(T1이나 E1)을 그대로 수용할 수 있는 장비이다.

=> 분배기능이 주목적인 커다란 용량의 스위칭 허브라구 이해하시면^^.

☞ CSU(Channel Service Unit)

TD	송신 데이터
RD	수신 데이터
RTS	Request To Send의 약자로 DTE가 DCE에 데이터 송신 요구를 표시
SYNC	전송로상의 반송파를 정상적으로 감시, 만약 SYNC가 깜빡거리면 전송로상의 문제가 있는 것이다.
RED	SYNC가 점멸하거나 꺼져 있는 경우에 빨간색 램프가 들어온다. 테스트 스위치 (LOOPBACK SWITCH)
CHANNEL LOCAL	일반적으로 DSU의 자체 테스트와 같은 의미로 자국으로 자체 루프하여 CSU장비 자체를 테스트하는 스위치
CHANNEL REMOTE	원격 루프 테스트로 장비와 대응되는 장비까지 루프 테스트는 것으로 전송로 구간을 전부 테스트 할 수 있다.

◈ CSU LED 표시 설명 표시램프 의미 [CSU ONS-150]

라우터(router)
랜을 연결하여 정보를 주고 받을 때 송신정보(패킷:packet)에 담긴 수신처의 주소를 읽고 가장 적절한 통신통로를 이용하여 다른 통신망으로 전송하는 장치이다. 인터넷을 접속할 때는 반드시 필요한 장비로서, 서로 다른 프로토콜로 운영하는 통신망에서 정보를 전송하기 위해 경로를 설정하는 역할을 제공하는 핵심적인 통신장비이다.

단순히 통신망을 연결해주는 브리지(bridge) 기능에 추가하여 경로 배정표에 따라 다른 통신망을 인식하여 경로를 배정하며, 수신된 패킷에 의하여 다른 통신망 또는 자신이 연결되어 있는 통신망 내의 수신처(노드)를 결정하여 여러 경로 중 가장 효율적인 경로를 선택하여 패킷을 보낸다. 통신 흐름을 제어하며 통신망 내부에 여러 보조 통신망을 구성하는 등의 다양한 통신망 관리기능을 수행한다.

장점은 통신환경의 설정을 가능하게 하여 관리 방침에 따라 라우팅 방식을 결정하여 전체 네트워크의 성능을 개선할 수 있다. 또한 표준 놀리에 따라 통신방법이 자동으로 결정되므로 유지보수가 용이하고, 통신방법에 구애받지 않으므로 대규모 통신망을 쉽게 구성할 수 있으며, 다양한 경로를 따라 통신량(트래픽:traffic)을 분산할 수 있다.
초기 환경설정이 어렵고, 특정한 프로토콜에 의존하므로 다양한 프로토콜 지원이 어려우며, 하위 프로토콜 지원이 불가능하고, 기능이 복잡하므로 가격이 비싸다는 단점이 있다.

=>경로설정 및 보정 기능. 트래픽 예방 및 분산이 주기능이죠.

요즘은 CSU에 DSU기능이 포함하여 한 제품으로 많이 나오고 있구요.
라우터에 CSU기능이 통합된 제품두 있습니다.

디지털 회선망 즉 일반 랜의 일반적 망구성도을 순서대로 살펴보면

1.집중국(MOU)----DSU-----------CSU--------------ROUTER----컴퓨터등 단말장치 (저속)

2.집중국(MOU)----HDSL----4 wire 실선-HDSL----CSU.ROUTER----컴퓨터등 단말장치 (고속.원거리시)
(2B1Q실선)

■ 디지털 모뎀 (Digital Modem)
DSU : 56Kbps~64Kbps 속도의 전용회선에서 사용합니다.
HSM : 128Kbps 이상의 회선용이며, 전화국과의 거리가 3Km 미만일 때 사용합니다.
CSU : 128Kbps 이상의 회선용이며, 전화국과의 거리가 3Km 이상일 때 사용합니다.

전용선 혹은 WAN(wide area network) 회선을 라우터(router)와 같은 사설망의 장비에 연

결하는 종단 장비.

CSU/DSU는 모뎀과 비슷하게 보이지만, 모뎀은 아니므로 아날로그(analog)와 디지털 간의

변환(변조와 복조) 기능을 수행하지 않는다.

CSU/DSU는 LAN(local area network)의 디지탈 데이터 프레임(frame)을 WAN에 적합한

디지탈 데이터 프레임으로 또는 그 역으로 변환하는 기능을 수행하며 또한 LAN의 내부와

외부 사이의 전기적 간섭을 차단하는 역할도 담당하는 장치인데, 종종 라우터와 결합된 형

태로 제작되기도 한다.

CSU는 회선 테스트를 위한 루프백(loopback) 기능을 수행할 수 있다. DSU는 회선 제어를

수행하며, LAN의 RS-232C, RS-449, V.35 프레임과 T-1선상의 TDM(time-division

multiplex) DSX 프레임 사이의 변환을 행한다. DSU는 또한 타이밍 에러와 신호 재생을 수

행한다. DSU는 DTE(Data Terminal Equipment)로서 컴퓨터와 CSU간의 모뎀과 비슷한 인

터페이스를 제공한다.

56K, T1 및 T3 각 회선의 CSU/DSU는 서로 같지 않으며, 일반적으로 상호 교체가 불가능

하다. T1 CSU/DSU의 경우, 24개의 서로 다른 채널(64K x 24 = 1.54MB)상에 64K

chunk(time slot)로 데이터를 전송한다.

■ HSM
점차 많은 데이터 전송이 필요해 지면서, 56K 이상의 전용회선을 사용하게 됨에따라 고속 데이터 전송용으로 나온 것이 HSM 입니다. 전용회선도 56K 한채널이 아니고 다수의 채널을 모은것을 사용합니다. 한 채널이 아니고 여러 채널로 이루어져 구성된 만큼 데이터가 한번에 지나갈 수 있는 폭이 넓어진 것이므로 한번에 많은 양을 보낼 수 있기 때문에 고속 데이터 전송을 할 수 있습니다.

HSM 장비는 통신 회선을 이용하여 컴퓨터, 라우터등 다양한 동기식 데이타를 전송 장치들의 데이타를 64K ~ 768K 로 통신 가능하도록 해주는 고속 근거리 모뎀입니다. 운용상 한계특성으로 메뉴얼 내용과는 달리 768K는 링크되기가 어렵고 512K도 전화국과의 거리가 상당히 근거리가 아니고서는 구성이 어렵고 개통되더라도 loss가 생깁니다. 이 고속모뎀은 속도에 따라서 제한거리가 달라지는데 128K 속도에서는 보통 실선인 경우 2.7Km 의 거리까지 가능합니다.

출처 : http://cluster1.cafe.daum.net/_c21_/bbs_search_read?grpid=y7Hj&fldid=5crN&datanum=101&openArticle=true&docid=y7Hj5crN10120070207172134

DTE 와 DCE 개념

JAESOO — Thu, 16 Apr 2015 14:45:25 +0000

DTE

- Data Terminal Equipment의 약자

- 사용자- 네트워크 인터페이스의 사용자측에서 데이터 발신 장치나 수신 장치, 또는 두 가지 겸용으로 사용되는 장치

- DTE는 반드시 모뎀과 같은 DCE장치를 통해 데이터 네트워크에 연결되며, 일반적으로 DCE에 의해 생성된 클럭 처리 신호를 사용한다.

- DTE에는 컴퓨터, 멀티플렉서, 라우터 등과 같은 장치가 포함된다.

DCE

- Data Communications Equipment의 약어(EIA 확장기준)

- Data Circuit-terminating Equipment의 약어(ITU-T 확장기준)

- 사용자-네트워크 인터페이스의 네트워크 측으로 구성되는 통신 네트워크 장비의 연결 수단

- DCE는 네트워크로 연결되는 물리적 수단이 되며, 트래픽을 전송하고, DCE 장치와 DTE 장치 사이에서 데이터 전송을 동기화 시키는 데 사용되는

클럭 신호를 제공

- DCE에는 모뎀과 인터페이스 카드가 포함된다.

Clock Rate 설정 이유

- 라우터에서 Clock Rate를 설정하는 이유는 위의 사진처럼 라우터끼리 Back-to-Back 구성 할 경우 Clock을 잡아주는 CSU/DSU가 없기 때문에

라우터 장비 둘 중 한쪽을 DCE로 설정하고 Clock 값을 지정해 주어야 한다.

- Clock Rate를 지정해주는 이유는 시리얼 인터페이스가 통신 시 어느 한쪽에서 통신 규격 속도를 지정해주어야 하기 때문이다.

- DCE쪽에서 Clock을 잡아주면 DCE 인터페이스는 DTE인터페이스로의 속도 동기화가 이루어지는 것이다.

- 따라서 Clock값을 지정해주는 것이다.

Clock 신호 동기 방법

- 라우터 간의 전송 시 신호 동기가 필요하다. 따라서 클럭 신호 라인을 이용하여 동기화 한다.

- 라우터와 컴퓨터 간의 신호는 클럭 + 데이터 신호 라인이기 때문에 따로 동기화가 필요없다.

- Clock (기준신호) : 데이터를 처리함에 있어 기준신호가 된다.

실제 연결의 예

ISP 업체 이용

- 한 기업에서 본사에서 지사로의 거리가 멀기 때문에 ISP업체를 이용하여 전용 망을 구축하여 사용한다.

- 전용 망이기 때문에 보안에 있어 좋으나, 가격이 비싸다는 단점이 있다.

VPN(Virtual Private Network) : 가상 사설망 이용

- ISP업체 이용하는 것이 비용이 많이 들기 때문에 일반 인터넷망을 이용하는 대신 보안을 위해 VPN을 설정하여 사용한다.

출처 : http://blog.naver.com/demonicws/40108165566

Router 와 L3 Switch의 차이

JAESOO — Thu, 16 Apr 2015 14:33:16 +0000

Router는 L3 장비죠. 라우터는 IP Layer에서 동작한다고 생각하시면 됩니다.

보통 공부를 하시다보면 L2는 Switch, L3는 Router라고 죽어라 외우고 공부했더니, 실무가더니 L3 Switch가 있어서 당황하게 됩니다. 왜 라우터를 써야할 곳에 Switch가 들어가 있어니 말이죠...^^

사실은 몇년전까지만 해도 스위치는 L2장비이고, 또 오랫동안 사용을 했습니다. 또 라우터는 L3에서 동작하는 장비였죠. 네트워크가 분리되어 있는 환경이라면 당연히 라우터를 사용하여야합니다.

간단히 정리하자면 스위치는 MAC을 보고 포워딩하지만, 라우터는 IP Layer를 보고 포워딩합니다. 당연히 라우터에는 Routing table을 보고 경로를 결정합니다. 참고로 라우터의 이런기능들은 대부분 소프트웨어적으로 구현되어 있지요. 이유는 MAC의 경우는 보통 단순하지만 IP라는 녀석은 복잡해서 하드웨어로 구현하기가 무척 까다롭습니다. 여기까진 이해되시죠.

그런데 시대가 많이 흐르다보니 하드웨어 기술이 나날이 발전하였습니다.그러다보니 하드웨어적으로 IP를 분석해서 경로를 설정하고 포워딩할 수 있는 기술로 발전하게 되었죠.

이때부터 나온 제품들이 L3 Switch입니다. 사실 스위치는 Performance측면을 많이 강조하였다고 보시면 좀더 이해될뜻.

아래표는 차이점을 정리하였습니다.

주요 특징	Classical Router	Layer 3 Switch
주요 수행 OSI Layer	Layer 3	Layer 3
Routing 수행 방법	Software (CPU + Software)	Hardware (ASIC chip)
지원하는 Layer 2 MAC	Ethernet, TokerRing, FDDI ATM, WAN	FastEthernet Gigabit Ethernet
forwarding performance	Slow (CPU성능과 가격에 따라 다름)	Fast (near wire speed)
Latency	약 200 ms	< 10 ms (100 Mbps)
관리 및 program 가능성	매우 높음	적음
지원 Protocol	All	IP (일부 IPX)
Routing Protocol	All	RIP1,2 OSPF (일부 DVMRP)
WAN 지원	지원함	지원하지 않음
비용	높음	낮음

참고로 최근 나온 스위치들은 대부분 Routing Protocol을 지원합니다. 일부는 WAN 인터페이스까지 제공하는 경우도 있습니다. ^^

시대가 흘려가면서 점점 라우터와 스위치의 경계가 흐려지는뜻하군요..^^

그럼. 즐거운 하루 되세요...

스티븐과 함게하는 네떡이야기 발췌-

예를 들어 A에서 보낸 팻킷이 포트 1로 들어왔다고 합시다.

그러면 L2 스위치는 포트 1에 A가 붙어있다는 정보를 얻게 됩니다.

그래서 나중에 A로 보내져야할 팻킷이 들어오게 되면 포트 1로 내보내게 됩니다.

L3의 경우는 L2와 달리 매우 넓은 범위까지 다루게 됩니다.

그래서 오가는 팻킷을 관찰해서는 충분한 정보를 얻을 수가 없습니다.

그래서 L3 스위치끼리 통신을 하면서 정보를 축적하게 됩니다.

예를 들어 포트 1에 연결되어 있는 스위치가 여기에는 팻킷이 많이 몰린다는

내용을 보낸다면, 그 내용을 받은 스위치는 팻킷을 포트 1 대신 다른 포트로

보내게 됩니다.

L4스위치

여러대의 서버에 똑같은 컨텐츠를 탑재하는 경우는 L4에서 서버의 부하를 체크해서 가장

여유있다고 판단되는 쪽으로 보내게 됩니다.(정책이 여러개 있는데, 이방식을 가장 많이 사용합니다.)

일반 기업에서 ERP서버나 업무용서버를 운영할 때 많이 사용하는 방식입니다.

서버별로 컨텐츠가 다르다면, L4에서 정책을 세워서 해당 서비스에 대한 요청이 오면 등록된 서비스로

보내주어서 전체 부하를 분산시키는 방식을 사용합니다. 대형 포탈의 경우 이런 방식을 사용하겠죠.

그리고 대부분 DB서버는 L4를 거치지 않고 웹서버와 직접 연결시켜서 사용합니다. DB서버 분산하는게 쉽지 않기 때문에 DB를 L4에 물리는 경우는 드물죠.

세그먼트(segment)에 대해 설명드리면, 한 컴퓨터에서 발생한 신호가 수신자에 상관없이 전달되는 범위를 말합니다. 즉, 내 컴퓨터에서 자료를 보내려고 신호를 내보내면 이 신호가 일정 지역내의 모든 컴퓨터에게 전달이 되는데 그 범위를 말합니다. 그런데, 하나의 세그먼트에서는 동시에 2개의 신호가 전달될 수 없습니다. 예를 들면, 두사람이 동시에 자기 얘기만 하면 무슨소린지 모르고 충돌이 발생하듯이 하나의 세그먼트 내에서 동시에 2개 이상의 전기적인 신호가 발생하면 충돌이 발생합니다.
그럼, 여기서 한가지 생각해 보시면, 하나의 세그먼트가 컴퓨터 1000대로 구성이 되어 있다고 보면 1000대중에서 내 컴퓨터가 자료를 보내려고 하면 많은 시간을 기다려야 할 수도 있고, 충돌이 자주 발생할 수도 있습니다. 그래서~ 세그먼트를 분리시키고자 등장한 장비가 브리지(스위치는 브리지를 개량한 장비)입니다.
브리지(bridge)는 한마디로 요약하면 세그먼트를 분리시켜주는 장비입니다. 예를 들면 1000대의 컴퓨터를 100대씩 묶어서 10개의 세그먼트을 만들어 주는 장비 입니다. 이렇게 분리된 세그먼트에서 자료 교환을 중재하는 역할을 브리지가 하게 됩니다.
예를 들어 세그먼트1에 있는 컴퓨터가 세그먼트1에 있는 컴퓨터로(즉, 같은 세그먼트)데이터를 전송하면 이 신호가 다른 세그먼트에 전송이 되지 못하도록 신호를 차단하구요, 세그먼트1에서 세그먼트2로 데이터를 보내면 브리지가 이 신호를 받아서 세그먼트2로 보내줍니다. 이렇게 하면 세그먼트가 분리되어서 컴퓨터끼리 자료 교환하는데에 충돌이나 기다림(병목현상?)이 줄어들겠지요.
이제, 스위치와 라우터에 차이점을 설명 드리면.. 세그먼트를 분리시킨다는 의미에서는 같다고 보시면 됩니다. 차이점은.. 어떤걸 기준으로 분리를 시키느냐 입니다.
스위치에 여러가지 포트(하나의 포트를 하나의 세그먼트로 보셔도 될겁니다.)가 있는데, 각 포트에 어떤 컴퓨터가 연결이 되어 있는지 판단하는 것은 MAC(Media Access Control)주소 입니다. 간단히 말하면 LAN카드 번호 입니다. 이 번호는 공장에서 나올때부터 고유하게 지정된 번호로써 전세게 LAN카드가 다 다른 번호를 가지고 있습니다. 스위치는 이 번호를 가지고 스위치 장비 내부에 '표'를 하나 만들어 놓고, 포트1에는 어떤 MAC주소가 있으며, 포트2에는 어떤 MAC주소가 있는지 적어 놓습니다. 그래서, 이 표를 기준으로, 스위치로 들어오는 신호를 읽어 들여서 같은 포트의 MAC주소를 목적지로 하고 있으면 다른 포트로 데이터를 보내지 않고, 다른 포트의 MAC주소를 목적지 주소로 가지고 있으면 그곳으로 연결 시켜 줍니다.
라우터는 세그먼트를 구분하는 기준이 IP입니다. 라우터도 내부적으로 표를 만들어 놓는데 기준이 IP입니다. 따라서, 라우터로 들어오는 신호를 읽어들여서 목적지가 같은 포트(즉, 같은 세그먼트)의 IP이면 다른 포트로 신호를 보내지 않으며 다른 포트의 세그먼트의 컴퓨터가 목적지 IP이면 그 포트로 연결시켜 주는 역활을 합니다.
라우터의 역할을 보시면 알겠지만, IP를 기준으로 세그먼트를 나눕니다. 그래서, 인터넷과 독립적으로 LAN을 구축할 경우 라우터는 필요 없습니다. 하지만, 인터넷과 연결시켜서 LAN을 구축할 경우 반드시 필요한 장비가 라우터 입니다

[출처] L2,L3|작성자 새맘

1. L1 -> Flooding

2. L2 -> Swhtching

3. L3 -> Routing

4. L4 -> port number 이용 트래픽분산처리 (Load balancing)

5. L7 (cisco 6500이상 장비) -> S/W 를 장치에 올려서 Traffic filter , Security, VPN 를 할수 있다.

- 상위 계층 장비는 하위 계층 장비의 기능을 모두 가지고 있다.

- L5,L6 ? -> TCP/IP 기반이기때문에 L7이 L5~6 기능을 모두 포함하고 있다.

- TCP/IP 기반

-> L1 : Network Interface 계층

-> L2,L3 : Network (Internet) 계층

-> L4 : Transport 계층

-> L7 : Application 계층

[출처] L2,L3|작성자 새맘

한정된 IT 자원을 가지고 인터넷 트래픽을 얼마나 효율적으로 관리하는가는 IT 업계에 중요한 이슈입니다.

특히, 과거 `1ㆍ25 인터넷 대란'과 대규모 웜바이러스의 출현 이후, 네트워크 보안에 대한 관심이 늘어나면서 기존 네트워크 장비에 보안기능을 대폭 강화한 제품수요가 크게 늘어나고 있는 실정입니다.

최근 인터넷 트래픽관리 및 보안환경이 강조되고 있는 상황에서, 기존 L2/3/4 스위치에 비해 보안기능을 대폭 강화한 네트워크 장비가 L4/L7(Layer4/7) 스위치입니다.

과거에는 통상적으로 패킷의 MAC 주소나 IP 주소를 이용하여 패킷을 전달하는 역할을 수행하는 L2/L3 제품이 주류를 이뤘습니다. 그 이후 급속히 증가하고 있는 인터넷 트래픽을 효율적으로 처리하기 위하여 몇년전부터 L4 스위치가 등장해, 트래픽 부하를 분산하고 지능적인 트래픽 관리 기능을 제공하고 있습니다.

L4 스위치는 서버 및 네트워크 장비의 가용성과 확장성을 높이기 위한 수단으로 각광을 받고 있습니다. L7 스위치는 기존 L4 스위치가 제공하는 기본 기능 이외에 최근 사회적인 문제가 되고 있는 네트워크 보안문제(웜바이러스, 이메일 바이러스, DoS/DDoS 공격 등)를 어느 정도 해결해 줄 수 있는 차세대 제품입니다.

L7 스위치는 애플리케이션 스위치(Application Switch), 콘텐CM스위치(Content Switch), 다계층스위치(Multi-Layer Switch) 등 다양한 이름으로 불리는데, 이는 L7 정보가 주로 애플리케이션과 직접 연관이 있고 패킷의 내용을 분석하여 이를 바탕으로 패킷에 대한 부하분산, 리디렉션, 필터링 등을 수행하기 때문에 자연스럽게 붙여진 이름입니다.

L7 스위치는 통상적으로 L4 스위치의 연장선상에서 출발했지만 L4 스위치가 처리할 수 없는 일들을 수행합니다. L4 스위치의 경우 통상적으로 TCP/UDP 포트정보와 같은 레이어 4 정보를 이용해 패킷을 관리하는 기능을 수행하는 것을 비롯해 서버 및 네트워크 장비에 대한 부하분산 기능을 주로 제공합니다.

그러나 L4 스위치는 VoIP나 P2P와 같은 중요 애플리케이션과 같이 다양한 형태의 패킷 내용을 살펴보기 어렵고 또한 사용자의 IP가 수시로 바뀌는 경우 해당 사용자에 대한 연속적인 서비스를 제공하기 어렵다는 단점을 가지고 있습니다.

L7 스위치에서는 L4 가 갖고 있는 이러한 문제점들을 해결하기 위해 패킷의 IP/Port 정보뿐만 아니라 패킷의 URL 정보, 쿠키, 플레이로드 정보 등을 종합적으로 검사하여 사용자별로 연속적이고 차별화된 서비스를 제공해줄 수 있습니다.

L7 스위치가 기존의 L4 스위치와 가장 차별화되는 부문은 L4 스위치가 Layer4 정보(TCP/UDP port)를 바탕으로 패킷을 분류하고 원하는 서버나 장비로 전송하는 반면 L7 스위치는 패킷의 내용을 보고 이를 바탕으로 패킷을 전달한다는 것입니다. 패킷의 내용을 살펴보고 이를 바탕으로 적절한 서버를 선택할 수 있습니다.

L7 스위치 기능 중에 최근 큰 주목을 받고 있는 부문이 네트워크 보안분야입니다. L7 스위치는 기존의 L4 스위치가 갖고 있던 기능들을 모두 수용하면서 불필요한 트래픽에 대한 차단이나 네트워크에 대한 공격을 완화시켜줌으로써 서버와 네트워크의 가용성을 한층 향상시켜줍니다. 특히, L7 스위치는 웜이나, E-메일 바이러스와 같이 특정한 패턴을 갖고 있는 패킷으로서 서버나 네트워크에 불필요한 트래픽을 제어합니다.

최근에는 L7 스위치업체와 바이러스 차단업체들이 서로 제휴를 통해 새로운 바이러스 패턴이 나타날 경우 이를 빠르게 업데이트해 네트워크를 보호하고 있습니다.

또한, DoS/DDoS 와 같이 비정상적으로 트래픽이 과도하게 집중되어 서버가 정상적으로 서비스되지 못하게 만드는 부분도 해결해 줍니다.

이를 해결하기 위해서 L7 스위치에서는 트래픽의 유입수준을 일정정도로 제한하여 서버가 항상 정상적인 서비스를 할 수 있게끔 보호해 준다.

물론 L4스위치만이 L7 스위치로 발전할 수 있는 것은 아닙니다. 기존 파이어월, IPS, QoS 등 엔터프라이즈 네트워크에서 각각의 고유기능을 담당하고 있는 장비들도 패킷의 내용을 분석하는 기능을 갖고 있으며, 이를 바탕으로 여러가지 보안정책과 대역폭조절 정책을 수행해왔습니다. 따라서 이들 장비도 각각의 고유기능에 부하분산기능을 결합하고, 대용량의 트래픽을 빠르게 처리할 수 있는 스위치 구조를 도입한다면 얼마든지 L7 스위치 형태로 발전할 수 있습니다.

L7 스위치를 생산하고 있는 업체로는 시스코, 노텔, 라드웨어, 파운드리, F5 등이 있고 국내에서는 파이오링크가 L7 스위치시장에 진입해 대등하게 경쟁하고 있습니다. 한국IDC 자료에 따르면, 전 세계적으로 콘텐츠 네트워킹 시장의 46%를 L7 스위치가 점유하며 총 36억달러 이상의 매출을 보일 것으로 전망했습니다. 국내에서도 2005년도에 1000억원 규모를 훌쩍 뛰어넘는 시장으로 성장할 것으로 보고 있습니다.

[출처] L2,L3|작성자 새맘

출처 : http://egloos.zum.com/koreahojin/v/2341317

VPLS 기술

JAESOO — Thu, 16 Apr 2015 13:28:52 +0000

L2 레벨의 가상사설망(VPN), 일명 가상사설랜서비스(VPLS : Virtual Private LAN Service) 시장이 실시간 인터넷TV(IPTV) 시대를 맞아 점차 본격화될 조짐을 보이고 있다.

30일 관련업계에 따르면 KTㆍLG데이콤ㆍ하나로텔레콤 등 통신사업자들의 실시간 IPTV 서비스 제공을 위한 새로운 네트워크 구성이 검토 중인 가운데, 그 핵심기술 중 하나로 VPLS가 떠오르며 주목을 끌고 있다.

VPLS란 L2 레벨의 VPN에 IP 주소 대신 별도의 라벨을 붙여 전송하는 기술인 MPLS(Multi Protocol Label Switching)를 이용함으로써 기존 전용선 수준의 안정성과 서비스품질(QoS)를 보장해 준다. 특히 가입자별로 차별화된 엔드―투―엔드의 QoS를 비용효율적으로 제공할 수 있어 IP네트워크를 이용한 IPTV 서비스 구현에 효과적이라는 평가를 받고 있다.

한 업계 전문가는 "현재 통신사업자들이 검토 중인 IP네트워크에서 실시간으로 방송 데이터를 전송할 수 있는 네트워크 구성 방식으로는 기존 네트워크 전송망을 이용한 다중서비스지원플랫폼(MSPP) 구성과 IP 핌(PIM) 라우팅. 그리고 VPLS 등 크게 세 가지가 있다"며 "이 중 MSPP는 유연성에서 핌 라우팅은 대용량에서 각각 한계를 지니고 있어 VPLS가 가장 유력한 상황"이라고 설명했다.

VPLS(Virtual Private LAN Service)는 MPLS 기술을 이용해 이더넷 VPN(Ethernet VPN) 서비스를 제공하는 것으로 확장성, 단순성, 관리성, 품질성, 안정성 등을 목표로 하고 있다. 이 기술은 메트로이더넷의 가치를 증진시키는 동시에 IP-VPN 서비스의 복잡성을 단순화하는 장점이 있다. 이에 따라 많은 장비업체들은 이 서비스가 시장성이 있다고 판단, VPLS 기술구현에 나서고 있으며, 사업자들 역시 VPLS 서비스의 상업화에 관심을 기울이고 있다.

VPLS는 이더넷 기반의 Layer2 기술로 메트로이더넷의 가치를 부각시키고 IP-VPN 서비스의 복잡성을 감소시켜 주는 기술이다. 먼저 이더넷은 대부분의 기업 LAN 환경에서 사용되는 Layer2 기술로 사용과 운용, 그리고 설치가 간단해 IT업계에서 가장 친숙한 기술 중 하나가 됐다. 네트워크업계에서는 이더넷 기술을 끊임없이 진화시키고 있고, 이로 인해 보다 빠르고 비용이 저렴한 이더넷의 구현이 가능해졌다.
최근 들어 IETF는 IETF draft-l2vpn-vpls-ldp-05.txt(이전 draft-lasserre-vkompella)에서 VPLS를 IP/MPLS 상에서 Bridged Ethernet VPN traffic을 전송하는 기술로 정의한 바 있다.
<그림1>에서 보듯이 VPLS는 각 고객이 IP/MPLS 망을 거쳐서 다른 여러 지사로의 연결성을 하나의 연결 도메인(Bridged Domain)을 통해 제공한다. 최종 가입자에 있어서 VPLS 서비스는 마치 동일 지역에 있는 Layer 2 스위치와도 같다. 고객은 소유하고 있는 라우터를 사업자가 제공하는 이더넷 포트에 연결하고 트래픽은 자동적으로 해당하는 목적지로 전달된다.
<그림1> VPLS 아키텍처

VPLS 특징

VPLS는 802.1Q 기반의 VLAN와 RFC2547기반의 IP-VPN 서비스와 같은 이더넷 VPN 서비스를 제공하며 다음과 같은 특징을 지닌다.

△확장성 : 먼저 가입자 수는 기존의 글로벌(Global Significant)한 특성이 아닌 로컬(Local Significant)한 특성을 갖는 관계로 Q-tag를 갖는 가입자의 제한이 적용되지 않는다. 또한 하나의 VPLS 도메인에 속하는 가입자 수는 기존의 도메인에 새 가입자를 수용할 때 기존 가입자에 대한 변경내용 없다. 서비스 제공에 대한 지역적 범위의 경우 H-VPLS(계층적 VPLS)는 Full mesh 없이도 서로 다른 지역간 연결에 대한 확장성이 보장된다. 대역폭 확장성의 경우 VPLS는 최대 10Gbps까지 확장할 수 있으며 각 고객 서비스별로 대역폭 할당이 가능하다.

△단순성 : Layer2 VPN 서비스이므로 모든 라우팅 프로토콜 트래픽의 전달이 가능하고, 라우팅 정책의 경우 사업자 관리가 아닌 가입자에 그대로 종속되어 관리되며, 가입자간과 사업자간의 접속이 복잡하지 않다.

△관리성 : VPLS은 다양한 운용의 용이성과 효율성을 높일 수 있는 기능, 즉 서비스 핑, 서비스 터널링 핑, MAC 핑, MAC 트레이스, 서비스 미러링 등을 포함하고 있다.

△QoS(Quality of Service): RSVP-TE를 기반으로 한 엔드투엔드 QoS 기능은 이더넷 VPN망을 통해 비디오, 음성과 같이 대역폭 할당이나 우선처리가 필요한 서비스들을 보장할 수 있게 한다. 가장 최근의 VPLS상의 구현은 계층적 QoS(HQoS)인데, HQoS는 트래픽을 여러 단계에 거쳐 스케줄링 하는 기술로 여러 가입자가 보내는 트래픽에 대해 우선순위 차별화 및 SLA 기준 대역폭 제공 등에 효율적으로 활용된다.

△신뢰성 : VPLS는 MPLS기반의 FRR(Fast Reroute) 및 hot-standby LSP(Label-Switched Paths)등을 통해 50ms 이내의 우회경로 설정을 제공하고, 이는 비디오 및 VoIP 서비스를 위해 중요한 요소로 부각된다.

VLAN서비스 대비 VPLS의 장점

VPLS는 메트로이더넷에서 IEEE 802.1Q 기반의 VLAN(Virtual LAN) 서비스와 비교하여 다음과 같은 장점을 갖는다.

△확장성 : IEEE 802.1Q는 가상LAN(VLAN) 태그를 이용하여 하나의 네트워크에서 가입

[출처] VPLS|작성자 이현철

출처 : http://blog.naver.com/unwired/20120329822

VPLS (Virtual Private LAN Service)

JAESOO — Thu, 16 Apr 2015 11:28:28 +0000

이글에서는 메트로 이더넷 네트워크에서 이더넷 L2 VPN 서비스를 제공해주는 새로운 기술인 VPLS (Virtual Private LAN Service)에 관해서 소개하겠습니다.

메트로 이더넷 서비스는 크게 인터넷 액세스 서비스와 이더넷 L2 VPN 서비스로 나눌 수 있습니다. 이더넷 L2 VPN 서비스는 메트로 이더넷 초기에 VLAN (802.1Q)을 통해 제공을 했었습니다. 순수 이더넷 기술(802.1Q tagged VLAN, 802.1p priority queueing 등)을 이용한 메트로 이더넷 서비스가 단순하다는 장점도 있지만 확장성과 안정성 그리고 서비스 품질 보장 등의 측면에서 한계가 있어 MPLS를 메트로 이더넷에 도입하여 이러한 문제를 풀어보려는 방안들이 제시되어졌습니다.

이러한 시도에서 나온 제안이 EoMPLS (Ethernet over MPLS)로 Point-to-point 이더넷 전용 회선을 MPLS망을 통해 L2로 제공할 수 있는 방안을 제안한 것입니다.

EoMPLS도 여러 가지 방안이 제시되어 졌는 데, Level3의 Luca Marnini가 제안한 방식이 지금은 업계의 표준으로 자리 잡게 되었습니다.

이를 더욱 진화시킨 기술이 바로 VPLS로 이는 Multipoint service (Any-to-any connectivity)를 제공하기 위해 제안된 기술입니다.

VPLS 서비스의 주목적은 지리적으로 떨어져 있는 여러 사이트들이 마치 하나의 LAN switch (L2)에 연결되어 있는 것과 동일한 효과를 제공해주는 것입니다. 즉, 각 site의 CE에서 VPLS망으로 유입된 이더넷 프레임은 변형되지 않고 그대로 해당 사이트로 전달됩니다. 그러니까, VPLS 네트워크는 전체가 하나의 거대한 L2 스위치(브리지)로 보이도록 동작하게끔 해주는 것이지요.

VPLS에서도 PE (Provider Edge)에 도착한 프레임이 어느 가입자의 프레임인지 (즉, 어느 VPLS에 속한 프레임인지)를 Marini-draft처럼 Port 또는 Port + VLAN ID를 보고 판단합니다.

EoMPLS에서는 도착한 이더넷 프레임을 MPLS 헤더로 encapsulation하여 바로 해당 vc-lsp로 전달합니다. (Point-to-point connection이니까 갈 때가 한 군데 밖에 없으니까).

그러나, VPLS 서비스에서는 도착한 프레임의 목적지가 여러 사이트입니다. 따라서, 어느 사이트로 프레임을 전달해야 할 지를 알아내야 하는 데, 이를 위해 각 PE는 vc-lsp별로 MAC address를 관리/학습하고 있어야 합니다. 즉, VPLS에 참여하는 PE는 VPLS별로 configuration 정보를 가지고 있어야 하며 (local Ethernet port, PE1, PE2, PE3에 VPLS 1000이 설정되어 있다.), 각 인터페이스별로 MAC address를 학습하고 있어야 예를 들어 PE2가 site1으로 전달할 지 site 3로 전달할 지를 판단할 수 있게 됩니다. 따라서, 예를 들어 PE2는 다음과 같은 FIB (Forwarding Information Base)를 가지고 있어야 한다.
01.gif

FIB of VPLS 1000 in PE2

MAC NextHop Interface
M2 local Eth20
M1 PE1 P1/vc-lsp102
M3 PE3 P2/vc-lsp302

다음은 VPLS의 생성 (control plane)과 data 전달 과정에 관해 기술한 내용입니다.
VPLS의 생성
1. Operator는 Site 1,2,3이 연결되어 있는 PE1, PE2, PE3간에 full-mesh로 VPLS instance를 하나 생성한다. 이 VPLS instance에는 하나의 unique VCID가 할당된다.

1.1 각 PE는 Targeted LDP session을 통해downstream-unsolicited mode로 vc-label을 배보한다. 즉, VPLS에 관한 label 값을 egress LER이 할당하여 이를 ingress LER에게 바로 배포한다.
02.gif

위의 그림에서는 PE1은 PE2에게 "이 VPLS (VCID=1000)에 속한 프레임을 나에게 보낼 때는 vc-label 102를 써서 보내라"라는 의미의 Label mapping message {VCID 1000, vc-label 102}를 PE2에게 보낸다.
03.gif

PE2는 PE1에 VPLS 1000의 site가 연결되어 있음을 알게 되고 PE1에 연결된 site (site1)으로 프레임을 전달할 때는 vc-label 102를 붙여서 보내야함을 알게 된다. 마찬가지로 PE3는 PE1에 VPLS 1000의 site가 연결되어 있음을 알게 되고 PE1에 연결된 site (site1)으로 프레임을 전달할 때는 vc-label 103를 붙여서 보내야함을 알게 된다.
04.gif

망운영자는 PE2와 PE3도 VPLS를 설정하고 PE1, PE3 그리고 PE1, PE2에게 Label mapping message를 배포한다.
이 과정이 끝나면, 예를 들어 PE2는 Ethernet port 20, Port 1의 vc-lsp 102 그리고 Port 2의 vc-lsp 302를 VPLS 1000의 Broadcast domain으로 인식하게 되고 VPLS 1000의 Setup이 완료 된다.

데이타 프레임의 전달과정
1. PE2에 Port20을 통해 Ethernet frame이 들어오면, PE2는 frame이 들어온 무리적인 port(또는 port + VLAN ID)를 통해 이 frame이 VPLS 1000에 속한 프레임을 알아낸다.
05.gif

1.1 source MAC leaming : PE2는 도착한 프레임의 source MAC address를 학습하여 SA=M2를 VPLS 1000의 FIB(Forwarding Information Base)의 Eth20에 등록한다.
06.gif

1.2 Destination MAC lookup : VPLS 100의 FIB를 lookup한다. Destination MAC = M1 이 FIB entery에 없으면(즉, 학습이 되어 있지 않으면 - Unknown frame이면), VPLS 1000에 속한 모든 PE로 프레임을 flooding한다. 즉, 도착한 프레임을 복제(replication)하여 p1/vc-lsp102를 통해 PE1으로, p2/vc-lsp 302를 통해 PE3로 전달한다. (물론 PE4로는 전달하지 않는다.) 이때 vc-label과 tunnel label을 부착하여 전달한다.
07.gif

2. Core LSRs(P Routers) : PW상의 모든 LSR들은 outer label(Tunnel label)값만 참조하여 해당 PE까지 프레임을 전달한다(label swapping). LSR들은 Tunnel label값만 참조하여 포워딩하기 때문에 현재 자기가 포워딩하고 있는 프레임들이 어느 VPLS에 속한 프레임인지는 모른다.
08.gif

3. PE2(Egress LER) : PE2는 도착한 프레임의 vc-label값을 참조하여 이 프레임이 어느 VPLS에 속한 프레임인지를 알아낸다(이 예에서는 VPLS 1000에 속한 프레임임을 알게 된다).
09.gif

3.1 Source MAC learning : 도착한 MPLS 프레임의 label를 제거(POP)하고 이더넷 프레임의 source MAC address를 학습한다. PE1은 M2가 vc-label 102를 통해서 왔으므로 M2가 PE2뒤에 있음을 알게된다. 따라서, M2를 vc-label 201인터페이스에 학습시킨다. PE3도 동일한 동작을 수행한다.
10.gif

3.2 Destination MAC lookup : DA=M1이 VPLS 1000의 FIB에 학습이 되어 있찌 않으므로 VPLS 100에 속한 모든 Port로 이더넷 프레임을 flooding한다(이 예에서는 Eth10으로만 전달된다). 이때 loop 방지를 위해 vc-lsp에서온 프레임은 VPLS에 속한 다른 VC-LSP로 flooding하지 않는다. (split-horizon rule). 즉, P4/vc-lsdp301로는 flooding하지 않는다.
11.gif

4. M1 reply : Site 1의 station 1이 reply를 하여 DA=M2, SA=M1인 이더넷 프레임을 PE1으로 전달한다.
12.gif

5. PE1에 Port 10을 통해 Ehernet frame이 들어오면, PE1는 frame이 들어온 물리적인 Port(또는 Port + VLAN ID)를 통해 이 frame이 VPLS 100에 속한 프레임을 알아낸다.
13.gif

5.1 Source MAC learning : PE1는 도착한 프레임의 source MAC address를 학습하여 SA=M1를 VPLS 1000의 FIB(Forwarding Information Base)의 Eth10에 등록한다.
14.gif

5.2 Destination MAC lookup : PE1은 이더넷 프레임의 destination MAC address를 VPLS 1000의 FIB에서 Lookup 한다. M2가 학습되어 있으므로 P3/vc-lsp201을 통해 프레임을 전달한다.
15.gif

6. PE2는 SA=M1을 학습하여 FIB entry(P1/vc-lsp102)에 등록하고, DA=M2는 학습이 되어 있으므로 Eth20 port를 통해 포워딩한다.
16.gif

7. 몇번의 Unknown grame들이 flooding 방식으로 오고 가면 각 PE의 VPLS 1000의 FIB table은 아래와 같이 MAC entry들이 등록되게 된다.
17.gif

이와 같은 VPLS FIB의 entry는 IP routing table처럼 control plane에서 생성(by IP Routing prtocols)시켜주는 것이 아니고, 이더넷 스위치에서와 같이 실제 데이타 프레임이 전달되는 과정에서 학습되어 생성된다(즉, data plane에서 생성된다)는 점이 기억해야 할 점이다.

8. 이후 프레임 전달과정은 destination MAC address가 모두 학습되어 있으므로 flooding되지 않고 바로 unicast로 포워딩 된다. 몇 번의 Unknown frame들이 flooding 방식으로 오고 가면, 각 PE의 VPLS 1000의 FIB table은 아래와 같이 MAC entry들이 등록되게 된다.
18.gif

19.gif

20.gif

각 PE에는 가입자별로, 즉 VPLS별로 구분된 FIB (Forwarding Information Base)가 존재하며, PE는 프레임이 도착한 Port (Port+VLAN ID)를 보고 어는 VPLS에 속한 프레임인지를 알게 되고 해당 VPLS의 FIB를 Lookup하여 어느 vc-lsp로 (즉, 어느 PE로) 포워딩할 것인 지를 알아낸다.

위의 그림에서 두 가입자의 사이트가 PE2와 PE1에 연결되어 있는 경우 PE2는 동일한 tunnel label을 부착하여 MPLS core로 전달하고 MPLS core의 P라우터들은 계속적으로 tunnel label을 swapping하여 PE1까지 전달한다. PE1은 vc-label값을 보고 어느 VPLS에 속한 프레임인지를 알아내고 해당 VPLS의 FIB를 lookup하여 해당 사이트로 프레임을 포워딩할 수 있게 된다.

이상의 내용에서 알 수 있는 점을 정리하면 다음과 같습니다.

1) Martini-draft와 달리 VPLS에서는 Any-to-any communication이 가능하다.
2) 가입자 네트워크와 메트로 네트워크는 IP 라우팅에 서로 간섭하지 않는다.
3) PE 라우터는 가입자별로(즉, VPLS instance별로) FIB를 관리하며, 프레임이 PE에 도착하면 도착한 Port (or Port + VLAN ID)를 보고 어느 VPLS에 속한 프레임인 지 알아내며, 이후 그 VPLS의 FIB table을 참조하여 frame의 forwarding decision을 내린다.
4) Martini-draft에서는 ingress PE 라우터, P 라우터 그리고 egress PE 라우터가 가입자측의 MAC address를 학습할 필요가 없다. 그러나, VPLS에서는 PE 라우터들이 가입자의 각 사이트의 MAC address (CPE=L3면 L3 스위치의 MAC, CPE=L2면 모든 단말의 MAC)을 학습하고 있어야 한다.
5) P 라우터는 tunnel label값만 보고 포워딩하면 되므로 가입자측의 MAC 주소를 학습할 필요가 없다.
6) PE 라우터는 Unknown frame을 flooding하거나 broadcast frame을 VPLS에 속한 복수개의 site에 전달할 수 있는 능력을 가져야 한다. (Replication)

VPLS 기술은 메트로 이더넷 분야에서 기술적인 완성을 의미하는 기술로 현재 대부분의 네트 워크 벤더들이 그 해법을 찾고 있고 또 개발중인 기술입니다.
국내에서도 이에 대한 연구 및 개발이 시급하다고 판단되며 관련 통신 사업자와 벤더들의 관심과 노력을 촉구하고 싶습니다.

출처 : http://bits.or.kr/biz/biz3-8.asp

[이도경 칼럼] 올해 인터넷전화 도입시 주의사항 10가지 2

JAESOO — Thu, 16 Apr 2015 11:20:24 +0000

지난 1편에 이어 올해 인터넷전화 도입시 주의사항 10가지 2 편을 이어갑니다.

지난글 보기
2010/01/13 - [인터넷전화 뒤집어 보기] - [이도경칼럼] 올해 인터넷전화 도입시 주의사항 10가지 1

4. 본사, 지사 등 넓게 구성된 경우 전체망 구성을 어떻게 구성할지에 대해 결정해야 합니다.

한 개의 기업이라면 구성은 그리 복잡하지 않습니다.
기업 내에서 단말기, IP-PBX 구축을 고려하고, 기존 장비와는 어떻게 할지 생각하면 됩니다.

그러나 만약 본/지사가 있는 형태이고 이것이 전국에 산재해 있는 경우라면, 휠씬 더 많은 것을 고려해야 합니다.
본사는 당연히 IP-PBX를 고려하겠지만, 각 지사에 모두 IP-PBX를 설치할 필요는 없습니다.

각 지사의 대표적인 위치(광역시 단위)에 IP-PBX를 구축하여 인근 지사를 수용하는 구조가
가장 일반적인 구조로 볼 수 있습니다.
대전, 대구, 광주, 부산 등을 중심축으로 하여 IP-PBX를 구축하고, 인근 지역의 지사는 최인접 광역지역에서
수용하는 구조로 구성하는 것입니다.

물론 지사의 규모가 몇 천명되는 수준이라면 서비스 안정성을 고려하여 별도로 구축할 수 있습니다.
이렇게 전국적인 망을 구성하는 경우 가장 중요한 것은 장애에 대비한 백업 체계를 구축하는 것입니다.

한 개의 노드에 장애가 발생하더라도 다른 광역지사의 노드를 통해 통화를 할 수 있도록

확실한 백업체계를 만들어야 합니다.

기존에 PSTN에서는 불가능했지만, IP망은 이러한 구성이 가능하도록 설계할 수 있습니다.

다만, 번호 설계 시 이러한 부분을 고려하여 전국을 고려한 번호 설계를 하여야 합니다.

5. 번호 유지 및 설계는 어떻게 할 것인지에 대해 결정해야 합니다.

기업은 기존에 사용하던 번호가 있습니다.
그래서, 일반적으로는 기존 번호를 유지하면서 인터넷전화로의 변경을 추진하고 있습니다.

이때 번호이동서비스로 처리하면 기존 번호는 유지하면서, 인터넷전화 서비스로 이동할 수 있습니다.

만약 번호를 070의 인터넷전화로 변경하겠다고 하면, 번호를 재설계해야 합니다.
주로 중간 번호 4자리를 이용하므로 이를 반영하여 재설계를 진행하면 됩니다.

070 번호를 이용한다면, 좋은 번호를 설계 할 수 있다는 장점이 있습니다.

6. 인터넷전화 품질은 어떻게 확보할 것인지 여부

기업에서 가장 민감한 사안 중에 한가지로 볼 수 있습니다.
가장 큰 이슈는 인터넷전화를 위한 IP망 회선을 별도 설계하느냐?기존 데이터 회선을 같이 사용하느냐 입니다.
기본적으로 별도 구성하는 것이 음성 품질을 높일 수 있으므로 이를 고려하는 것이 가장 좋습니다.

그러나 상대적으로 회선 비용이 들어가지요.
저렴한 별도 회선 구성을 위해 소규모 기업은 초고속 인터넷을 별도 신청하여 음성 전화용으로
사용하는 경우도 있습니다. 만약 통화량이 많지 않다면, 같이 사용하는 것도 무방합니다.

한 번의 음성 통화가 차지하는 대역폭은 100K입니다.
따라서 외부와 동시에 통화하는 경우가 어느 정도인지를 생각해보고, 현재 데이터 대역폭이 그것을 지원할 수 있느냐를 점검하는 것입니다.
또한 L2 스위치에서 데이터 트래픽보다 음성처리를 우선하도록 처리하는 기능을 적용한다면 품질을 높일 수 있습니다. 이외에 통신서비스업체가 제시하는 음성품질을 높이는 방안을 추가적으로 확인해야 합니다.

7. 기업에서의 인터넷전화 보안 적용 방법은

인터넷전화는 보안에 취약하다는 것이 많이 알려져 있습니다. 그러므로 인터넷전화 도입 시 이러한 부분을 고려해야 합니다. 그런데 보안 강화는 비용과도 직접적으로 연관되어 있는 문제이므로 무조건 강화한다는 측면보다는 필요성에 대한 검토를 통해 결정해야 할 것입니다.

기업에서의 보안을 위해서는 다음과 같은 측면을 고려해야 합니다.

1. 기업 인터넷전화를 위해서 별도 인터넷전화 보안 전용 장비를 둘 것인지 여부

이 장비는 인터넷전화의 DOS, DDOS 및 스팸과 같은 공격을 막는 시스템으로 금융권처럼 돈과 직접적으로 연관되어 있는 기업이라면 이러한 장비의 도입을 적극 추진해야 할 것으로 보이며,
일반 기업이라면 다소 신중히 생각하는 것으로 고려해야 합니다.

2. 음성 통화에 대한 암호화 문제입니다.

도청, 통화 내역을 훔쳐서 활용도가 큰 경우 암호화를 적용해야 합니다.
금융권과 같이 폰뱅킹 비밀번호를 도용하지 못하도록 하게 위한 것들이 그 예라고 할 수 있습니다.

결론적으로 기업에서 보안을 어느 레벨에서 필요한지에 대한 판단을 통해 도입 시 적극 검토하여야 할 것 입니다.

8. 기업에서 인터넷전화를 위한 모바일 VoIP 환경을 구축할 것인지 여부

최근 아이폰으로 인해 스마트폰에 대한 관심이 폭발적으로 증대되었습니다.
올해 각 통신사업자는 스마트폰에 대한 확대를 선언하고 있으며, 안드로이드 기반의 스마트폰도
대거 출시될 것으로 보입니다.

이러한 스마트폰은 기본적으로 WIFI 접속이 가능하며, 인터넷전화가 가능하도록 구현되어 출시됩니다.
단말 제조사가 출시부터 인터넷전화 모듈을 탑재하는 경우도 있으며, 제조사로부터 단말기가 출시되면 통신 사업자가 추가 개발하여 인터넷전화 모듈을 탑재하기도 합니다.

어쨌든 스마트폰은 100% 인터넷전화 모듈이 탑재되고 있으며, 일반폰까지도 점차적으로 확산되고 있는 추세입니다.

그러므로 기업에서는 mVoIP 환경을 구성할지에 대해 검토해야 할 것으로 보입니다.
실질적으로 검토하면, mVoIP가 아니라 데이터를 포함한 모바일 오피스 환경 전체를 검토해야 할 것으로 보여집니다.

주요 검토 사항으로는, 이러한 스마트폰을 허용할 것인지의 여부가 우선 결정 사항입니다.

허용한다면, AP 구축 및 설계를 mVoIP를 수용할 수 있도록 설계를 해야 합니다.

스마트폰을 사용한 메일, 회사 내 그룹웨어 접속 등 각종 회사 내 데이터 서비스 이용에 대한 검토도 같이
이루어져야 합니다.

스마트폰을 사용할 경우의 보안 이슈도 별도 검토해야 합니다.
단말기 자체에서 이동이 되면서 사내 인프라에 접속하므로 기존의 VPN만으로는 제공이 어렵습니다.
추가 검토가 필요합니다.

9. 응용서비스는 무엇을 제공할 것이며, 메신저등 기업 UC의 도입 방법 및 범위는

기본 서비스 이외에 응용서비스를 어떤 것을 제공할지를 결정해야 합니다.
기본 서비스는 제안을 통해 쉽게 확보할 수 있지만, 응용서비스는 회사에서 필요한 요구사항을 기반으로 정해야
하는 사항으로 내부의 의견을 적극 반영해야 합니다.

응용서비스는 컬러링, 사서함, 회의통화와 같은 기본적인 서비스가 있으며, 최근에 많이 이야기하는 UC가 있습니다. 기존에 메신저와 연동하여 메신저에서 전화를 걸 수 있게 한다든지(Click to Call 서비스) 그룹웨어와 연동하여
서비스를 제공할 수 있도록 하는 등 여러 가지 필요한 사항을 결합하여 편리하게 제공할 수 있습니다.

그 외, 자동 안내대 서비스와 같이 대표번호를 통해 전화를 받고, 내선번호 또는 부서를 통해 연결해 주는 서비스를 일반적으로 이용하는 기업이 많은 것으로 알고 있습니다. 이와 같이 기업에서 현재 제공하는 IT 인프라와 밀접하게 연관하여 인터넷전화를 효율적으로 제공하여 편리성과 효율성을 통해 업무의 생산성을 높일 수 있다면,

기존 아날로그 전화와는 다른 좋은 반응을 볼 수 있을 것입니다.

추가적으로 회사마다 특별히 제공하는 서비스가 있으며, 이와 연동하여 기존서비스를 변경 없이 제공할 수 있도록
인터넷전화 도입을 고려해야 합니다.

10. 인터넷전화 서비스 도입으로 궁극적으로 얻을 이익이 무엇일까요?

이 부분은 당연히 생각하겠지만, 도입 담당자가 꼭 짚어보고 정리해야 할 사항일 것입니다.

인터넷전화 서비스 도입으로 가져다 줄 장점, 효과가 무엇인지 정리하고 도입을 진행한다면, 막연히 진행하는 것
보다 목표가 명확하고, 도입 시 여러 가지 결정 사항에 대해 좀 더 올바른 판단을 할 수 있으리라 생각합니다.
예를 들면,

1. 비용 절감이 목적이라면 어느 정도 되는지를 상세하게 가늠하는 것이 좋습니다.

2. 업무의 편리성을 확보해야 한다면, 어떤 서비스를 어떻게 확보할 지가 명확해 질 것으로 보여집니다.

무작정 많은 기능이나 옛날 하던 것 그대로가 아니라, 필요한 기능과 요구사항을 넣는 것이 필수적입니다.

그를 통해 실질적으로 임직원이 경제성 및 편리함을 느낄 수 있도록 구성한다면 여러분은 차별화된 업무를
진행할 수 있고 인정받을 수 있으리라 생각됩니다.

경인년 빠른 통신 변화에 맞추어 지속적으로 변화하는 여러분을 만드시길 바랍니다.

글쓴이 : 이도경 제너시스템즈 기술전략실장

제너시스템즈의 인터넷전화 기술방향을 수립하고, 필드에서 발생하는 문제점에 대한 컨설팅을 수행하고 있습니다. 인터넷 전화 가입자 확대에 따라 망 진화, 기술 발전과 관련된 다양한 이슈들이 발생하고 있습니다. 인터넷전화의 성공적인 정착과 발전을 위해 효과적인 해법들을 제시하여 인터넷전화 성장에 도움이 되고자 합니다.

출처 : http://xenerdo.tistory.com/220#.VS8akfyJgeM

[이도경 칼럼] 올해 인터넷전화 도입시 주의사항 10가지 1

JAESOO — Thu, 16 Apr 2015 11:20:07 +0000

2010년 한 해가 힘차게 시작 되었습니다.
올해도 기업에서 인터넷전화를 도입하려고 생각하는 사람들이 많을 것으로 예상됩니다.
이러한 분들이 인터넷전화를 도입하면서 생각해야 할 사항들에 대해 10가지 정도로 추려 보았습니다.

1. 가장 먼저 서비스를 어떻게 제공받을지를 결정해야 합니다.

즉, 자체적으로 시스템을 구축하여서비스를 이용할지, 아니면, 사업자가 제공하는 기업형 서비스를
이용할지에 대해 결정해야 합니다.

인터넷전화를 도입하는 방법에는 크게는 2가지가 있으며, 규모 및 목적에 따라 방향을 결정해야 합니다.

제너시스템즈의 UAP-5110

첫째는 자체적으로 별도의 시스템을 구축하는 것입니다.

PSTN(기존 전화기)에서 기업 내선전화를 이용하기 위해서 키폰(규모가 작은 경우)이나
PBX와 같은 기업형 교환 시스템을 구축하여 내선통화를 무료로 이용하였습니다

이와 동일하게 IP-PBX 시스템도 규모에 따라 소형, 중형, 대형을 구분하여 구축합니다.
이때 시스템은 기업 자체 소유가 됩니다.

두 번째로 시스템을 자체적으로 구축하지 않고, 사업자가 제공하는 서비스를 이용하는 것입니다.

기업은 단말기만 구매하여 설치하고, 내선통화를 제공하는 기업용 교환기는 사업자가 구축하여 서비스를
제공하는 것이지요.

현재 KT, SKBB, LGD, 삼성네트웍스 등의 업체는 모두 이런 서비스를 제공하고 있습니다.
이런 서비스 형태를 IP-Centrex 서비스라고 부르고 있는데, PSTN에서도 Centrex라고
동일한 형태의 서비스가 있었습니다.
그러나, 인터넷전화보다 활성화되지 않아 잘 알려지지는 않았습니다.

인터넷전화에서는 IP망을 이용하다 보니 이러한 원격 서비스 제공 개념이 휠씬 더 일반화되었지요.
최근에 SaaS(Software as a Service), 클라우드 컴퓨팅 등이 활성화되는 점과도 유사하지요.

SaaS(Software as a Service)에 대한 세미나 현장의 사진 중에서

이러한 IP-Centrex 서비스의 장점은 시스템에 대한 투자비 및 운용비가 별도로 들지 않는다는 것입니다.
그 대신 시스템 사용에 따른 회선당 기본료가 있으므로 비용이 높아진다는 단점이 있지요.
즉, 투자비와 비용의 Trade Off 관계가 있는 것입니다.

일반적으로 시장 현황을 살펴보면, 50인 이하 규모에서는 별도 장비를 구축하지 않고,
IP-Centrex 서비스를 이용하는 경우가 다소 많은 것으로 파악되고 있으며, 그 이상인 경우에는
자체적으로 IP-PBX와 같은 시스템을 구축하는 경우가 많은 것으로 보여지고 있습니다.

이러한 방향을 결정하기 위해서는 현재 기업에서 발생하는 통신비, 신규 시스템 구축 및 운용 비용,
사업자의 IP-Centrex 서비스 이용 비용 등을 상호간에 비교하여 결정해야 할 것으로 보여집니다.

2. 만약 1번에서 자체 구축을 할 경우 회사 내 경비로 할지, 통신사업자에게
투자를 받을지를 결정해야 합니다.

물론 위의 결정은 기업이 마음대로 결정할 수 있는 사항은 아닙니다.
IP-PBX를 자체 구축하지 않고, 통신 사업자로부터 투자를 받기 위해서는 일정 규모의 통신비가 나와야 합니다.
즉, 통신 사업자는 통신비(음성 및 데이터를 포함)를 보고, IP-PBX 시스템과 회선 및 관련 장비를 투자할 경우 3년 약정으로 수익을 낼 수 있는지를 분석한 후에 투자 여부를 통신사업자가 결정합니다.

최근 소형 IP-PBX도 많이 라인업을 시키고 있으므로 기업 고객의 선택 폭은 넓어졌다고 볼 수 있습니다.
그래서 직접 투자하지 않고, 통신 사업자의 제안서를 받아서 투자 방향을 결정하는 것이 중요한 검토사항이라 볼 수 있습니다.
여러 통신 사업자로부터 이번에 논의하는 10가지 검토사항을 참조하여 제안을 받고 가장 적합한 조건으로 제시한 업체를 선정하는 것이 바람직한 방법이라 볼 수 있습니다.

3. 단말기를 어떻게 할지에 대해 결정해야 하며, 기존 시스템은 어떻게 활용할지에 대해 결정해야 합니다.

인터넷전화는 기본적으로는 IP-Phone을 사용하나, 기존 아날로그 단말기를 사용할 수도 있습니다.
이를 사용하기 위해서는 아날로그 GW를 구성해야 합니다.

즉, 단말 구성을 어떻게 할지를 결정해야 합니다.

기존 아날로그 단말기는 사용할 것인지? 사용하면 몇 대나 사용할 것인지?
신규 IP-Phone은 얼마나 사용할 것인지?신규 IP-Phone중에서 고급형(영상전화용 단말기) 전화기는 사용할 것인지?
사용하면 몇 대나 사용할 것인지?
특별한 기능의 단말기가 필요한지? 즉, 기존 사용자들 중에서 비서와 같이
특별한 목적으로 단말기를 사용하고 있는 것이 있다면, 그것에 맞게 단말기를 확보해야 합니다.

이러한 현재의 상황을 파악하여 도입할 인터넷전화 단말기의 종류 및 수량을 결정해야 합니다.

출처 : http://xenerdo.tistory.com/206#.VS8Z5vyJgeO

Synology(시놀로지) DS413 설치후기 - ④ Photo Station

JAESOO — Thu, 26 Mar 2015 10:22:41 +0000

이런 순서로 진행 중입니다.

1. 설치환경 준비

2. DSM

3. Audio Station

4. Photo Station

5. Video Station

6. Cloud Station

7. File Station

8. 기타 Station들

9. 제어판

10. 원격제어

오늘은 4강, Photo Station입니다.

4강 구성은 다음과 같습니다.

1. Photo Station 설치

2. DS photo+ 앱 설치

3. Photo Station에 사진 올리기

4. Photo Station에 동영상 올리기

자, 그럼 순서대로,

1. Photo Station 설치

Audio Station 못지 않게 이 Photo Station 또한, 교회에서 그 쓰임새가 매우 크고 다양합니다. 특히, 교회 예배, 각종 행사 및 주일학교 모습 등, 소위 '비주얼' 자료공유에 힘쓰시는 교회일수록 더욱 그렇습니다. 이 Photo Station은 Photo뿐 아니라 Video Streaming까지도 가능하기 때문에 더욱 그 활용도가 높습니다. 블로그도 있는데, Photo Station이 제공하는 블로그는 쓰시라 권하기가 좀...^^

앞으로 앞 강의에서 다루었다 하더라도 독자의 편의를 위해 무한반복을 하겠습니다. 이미 익숙하신 분들에게는 다소 지루하실지라도 이제 새로 배우시는 분들을 위해 양해하여 주실 줄 믿습니다. ^^

설치는 Audio Station 때 처럼 다음과 같이 합니다.

① DSM을 admin 계정으로 로그인합니다.

② 바탕화면 상단 타이틀바 왼쪽 바탕화면 표시 바로 옆에 있는 메인 메뉴를 클릭

③ 밑으로 펼쳐지면 여러 섬네일 중 두 번째 줄 첫 번째 섬네일 패키지 센터 클릭

④ 멀티미디어 그룹에서 Photo Station 클릭, 설치

참고로, 이 Photo Station은 앞서 5개 Station들(Audio, Download, Surveillance, Video, File)처럼 사용자 지정 별칭 및 리디렉션 기능이 제공되지 않습니다.

하나의 Station을 설치, 외부에서 NAS 즉, DSM에 접근하기 위해서는 앞서 2강에서 다룬, 포트포워딩을 해주어야 하는데, 그러기 위해서는 Synology에서 각 Station에 배정한 포트 번호를 알아야 합니다.

아래 링크는 DSM 4.2 현재, Synology Support - Knowledge Base, What network ports are used by Synology services? 라는 질문에 대한 답변 페이지입니다.

http://www.synology.com/support/faq_show.php?q_id=299&lang=enu

위 표에 보면, Photo Station, DS photo+ 둘 다 HTTP의 경우, TCP 포트 번호 80을 사용합니다.

다음과 같이 합니다.

① 공유기 관리자 화면에서 고급 설정 - NAT/라우터 관리 - 포트포워드 설정으로 갑니다.

② 오른쪽 포트포워드 설정에서, 예를 들어, 아래와 같이 하지요.

규칙 이름 : DS photo+

내부 IP주소 : 192.168.0.100

프로토콜 : TCP

외부 포트 : 80

내부 포트 : 80

③ 위와 같이 하고, 추가 클릭,

④ 그러면, 하단에 한 줄 생깁니다.

⑤ 왼쪽 번호 옆 체크 박스 체크 후, 위 동작 버튼 클릭, 동작시켜 줍니다.

제대로 들어가지는지 확인은 DS photo+ 앱 설치 후, 앱에서 하겠습니다.

Photo Station의 경우, 브라우저에서는 80 포트가 겹쳐 DSM으로 들어가게 됩니다. 이 우선순위를 피하면서 바로 Photo Station으로 들어가려면, http://onelove.synology.me/photo 하시면, DSM이 아닌, Photo Station 화면이 뜹니다. 여기서 로그인하시면 됩니다.

포트 번호 80이 겹친다고 공유기 포트포워딩을 생략하시면 앱에서 안 들어가집니다.

꼭 한 줄 넣으셔야 합니다.

Photo Station 설치는 이 정도 하겠습니다.

2. DS photo+ 앱 설치

앱 설치 및 확인은 다음과 같습니다.

갤3 기준입니다만, 다른 기종들도 거의 같습니다.

① 앱 Play 스토어를 실행합니다.

② 맨 위 돋보기를 탭, 영문에서 synology 입력, 밑에 리스트에서 synology 선택

③ DS 앱들이 주욱 뜨는데 여기서 DS photo+ 선택, 설치합니다.

④ DS photo+ 앱 열기

⑤ Wi-Fi를 끕니다.

⑥ DS photo+ 로그인 창에서 한사랑교회는 다음과 같이 했습니다.

주소 또는 QuickConnect ID : onelove.synology.me

계정 : admin

패스워드 : *******

나머지는 안 건드립니다.

⑦ 앨범 - 한사랑교...30505 탭

⑧ 사진 하나 탭한 후, 홈버튼 왼쪽 메뉴 버튼 탭, 슬라이드쇼로 보시면 더욱 편합니다.

⑨ 이상 없으면 홈 버튼 왼쪽 탭, 로그아웃 탭

위 ⑤항은, 공유기 권역이 아닌, 일반 공중망에서도 잘 들어와지는지 보기 위해서입니다.

한사랑교회 NAS 이동이 완료, 이젠 잘 들어가지는군요! ^^

위 ⑥항에서, QuickConnect ID는... 아래와 같이 생성합니다.

① 관리자 계정으로 DSM 로그인

② 제어판 - 네트워크 서비스 - QuickConnect 클릭

③ 제어판 - QuickConnect 창에서 위 QuickConnect 박스에서 원하는 어플리케이션 빈 박스 체크, 여기서는 DS photo+ 체크

④ 아래 QuickConnect 정보 박스에서 QuickConnect ID : 숫자(아홉자리) 확인

⑤ (위 숫자 외우기가 불편하면) 사용자 지정 버튼 클릭, 임의의 아이디 입력, 사용하셔도 됩니다. 아이디는 숫자로 시작하실 수 없습니다.

앱 DS photo+ 실행 후, 아홉자리 숫자 혹은, 아이디를 입력해 보세요. 신기하게도 로그인이 될 겁니다. 이 방법이 훨씬 더 편하실 겁니다. ^^

QuickConnect를 지원하는 클라이언트들은 DS file, Cloud Station, DS photo+, DS audio 입니다.

지금은 첫 테스트라 admin으로 로그인했지만, 나중에 계정들 생성하면 각각 접근 권한 등을 컨트롤할 수 있습니다.

DS photo+ 앱 설치 및 확인은 여기까지입니다.

출처 : http://bygrace.kr/16

Synology(시놀로지) DS413 설치후기 - ③ Audio Station

JAESOO — Thu, 26 Mar 2015 10:22:23 +0000

이런 순서로 진행 중입니다.

1. 설치환경 준비

2. DSM

3. Audio Station

4. Photo Station

5. Video Station

6. Cloud Station

7. File Station

8. 기타 Station들

9. 제어판

10. 원격제어

오늘은 3강, Audio Station입니다.

3강 구성은 다음과 같습니다.

1. Audio Station 설치

2. File Station 사용하기

3. DS audio 앱 설치

자, 그럼 순서대로,

1. Audio Station 설치

교회에서 NAS로 할 수 있는 가장 첫 번째 활용은, 아마도 '설교 듣기'이지 싶습니다.

그래서 제일 먼저, Audio Station으로 시작합니다.

다음과 같이 합니다.

① DSM을 admin 계정으로 로그인합니다.

② 바탕화면 상단 타이틀바 왼쪽 바탕화면 표시 바로 옆에 있는 메인 메뉴를 클릭

③ 밑으로 펼쳐지면 여러 섬네일 중 두 번째 줄 첫 번째 섬네일 패키지 센터 클릭

④ 멀티미디어 그룹에서 Audio Station 클릭, 설치

위 ②번 메인 메뉴는 따로 풍선도움말이 안 떠 어떤 걸 말하는 건지 처음엔 잘 모를 수 있습니다. 1개의 파란 다이아몬드와, 3개의 하얀 사각형으로 된 아이콘을 말합니다.

각 Station의 다양하고 자세한 응용은, 나중에 제 역량이 닿는 대로 응용편에서 다루겠습니다. 여기서는 일단 '설치를 이렇게 했습니다' 선에서 넘어가겠습니다.

저는 특히 이 Audio Station의 경우, DSM 안 거치고, 바로 갈 일이 별로 없어 이 경우는 잘 안 쓰지만, 혹시 필요하신 분들 있을까 하여 잠깐 다룹니다.

이 Audio Station 핸들링을 할 때, 꼭 DSM을 거쳐서 할 필요는 없습니다.

처음부터 브라우저에 해당 주소로 바로 Audio Station 관리화면을 띄울 수 있습니다.

다름과 같이 하시면 됩니다.

① 제어판 - 응용 프로그램 설정 - 응용 프로그램 포털로 갑니다.

② 응용 프로그램 목록에서 Audio Station 선택 후, 켜지는 편집 버튼 클릭

③ 포트/별칭 규칙 편집 창을 다음처럼 합니다.

사용자 지정 별칭 활성화 : 체크

별칭 : audio (DSM 제안 그대로, 다른 걸로 해도 됩니다.)

리디렉션 원본 : 체크

④ 확인 클릭

⑤ 편집 버튼 옆 저장 버튼 반드시 눌러주셔야 합니다.

이렇게 하면, 다음부터 브라우저 주소창에 직접, 예를 들면, http://2237.synology.me/audio 이렇게 입력 후, 엔터 하면 바로 Audio Station 관리 화면으로 DSM 안 거치고, 직접 들어가시게 됩니다. 이 경우, 화면 보시면 아시겠지만, 로그인 창 하단에 음표 표시 아이콘이 붙어 Audio Station 임을 알 수 있도록 하는군요. ^^

위에서 리디렉션 원본에 체크 안 하면 주소에서 포트번호를 넣어주셔야 합니다.

저는 그 마저 귀찮아 리디렉션 합니다.

이렇게 할 수 있는 Staiton들은 아직은 총 5개로, Audio Station, Download Station, Surveillance Station, Video Station, File Station 입니다.

이 바로가기가 요긴한 한 가지 예가, File Station인데요, 예를 들어, 다른 사람이 저에게 대용량 파일을 보내셔야 할 때, 한 가지 방법이, 별도 계정을 만들어 드린 후, 그 분으로 하여금 이 File Station으로 직접 들어와 업로드하시게 하는 겁니다. 그러면, 그 분이 DSM을 안 거쳐도 되니 좀 깔끔하지요. ^^

좀 쉬고, 이어 하겠습니다.

저 역시, 요즘 교회 개척을 준비 중이어서 바쁜 나날을 보내고 있습니다.

오늘은 아내와 함께 교회에서 쓸 십자가, 헌금통 등 여러 가지를 좀 살펴보고 왔습니다.

오래 기다리신 분들께는 많이 죄송합니다.

제가 블로그를 처음 운영, 이렇게 글을 올리다 보니 이게 쉬운 일이 아니구나 싶습니다.

제가 그동안 빚진, 많은 NAS 선배님들의 이런 수고가 일찌기 있었기 때문에 오늘 내가 이렇게 글을 올릴 수 있는 거구나 싶어 그 분들께 새삼 감사를 전합니다.

다시 이어 진행합니다.

하나의 Station을 설치, 외부에서 NAS에 접근하기 위해서는 앞서 2강에서 다룬, 포트포워딩을 해주어야 하는데, 그러기 위해서는 Synology에서 Audio Station에 배정한 포트 번호를 알아야 합니다.

아래 링크는 DSM 4.2 현재, Synology Support - Knowledge Base, What network ports are used by Synology services? 라는 질문에 대한 답변 페이지입니다.

http://www.synology.com/support/faq_show.php?q_id=299&lang=enu

위 표에 보면, Audio Station, DS audio 둘 다 HTTP의 경우, 포트 번호 5000을 사용합니다.

2강으로 잠시 돌아가셔서, 포트 번호 5000으로 포트포워딩을 하고 오시기 바랍니다. ^^

Audio Station 설치는 이 정도 하겠습니다.

2. File Staiton 사용하기

Audio Station 설치 중 웬 뜬금없이 File Station 사용? 하실 분들이 계실 것 같습니다. NAS에 음악 파일 하나 테스트 용으로 업로드하려고 그러는 건데, 물론 NAS에 파일 업로드 방법이 꼭 File Station 사용만 있는 건 아닙니다. 자세한 건, 7강 File Station에서 다루겠습니다.

File Station은 다른 Station처럼 패키지로 설치하는 게 아니고, DSM 설치 시, 함께 설치되는 겁니다. DSM 바탕화면에 보면, Windows File Explorer 같이 생긴 아이콘이 하나 있는데 그 이름이 File Station으로 되어 있습니다.

테스트 용 음악 파일 하나 NAS에 업로드하는 건 다음과 같이 합니다.

① File Station을 더블 클릭, 실행합니다.

② 보안 경고 창이 뜨면 차단 안함 클릭

③ 테스트 용 음악 파일 하나, NAS music 폴더에 업로드 해주세요.

위 ②번에서 차단 클릭하시면, File Station 창에서 로컬이 안 보입니다.

로컬, 즉, 지금 내가 작업 중인 PC 드라이브들이 안 보이면... 조금 짜증나지요. ^^

위 ③번의 공용폴더 명 music은 Audio Station이 설치되면서 DSM이 알아서 생성한 건데, 나중에 공용폴더 편집 버튼으로 바꾸실 수 있지만... 저는 그냥 씁니다.

이 File Station 역시, 위 1단계에서 언급한, 사용자 지정 별칭 활성화 및 리디렉션 가능합니다.

즉, http://2237.synology.me/file 이렇게 하시면, DSM 안 거치고 바로 갑니다.

File Station 사용하기는 일단 여기까지입니다.

3. DS audio 앱 설치

교인들로 하여금 자신의 스마트폰으로 목사님 설교를 어디서나 쉽게 들으실 수 있게 하는 것

사실은 이게 최종 목표입니다. 경험에 의하면, 대부분의 교인들은 PC나 노트북 등으로 설교 듣는 것을 무척 어려워 하신다는 것을 알았기 때문에, PC를 대체할, 정말 손쉬운 방법이 필요했는데, 마침 이 똘똘이 NAS가 나타난 겁니다. 그래서 서둘러, 한사랑교회 목사님께도 그 손쉬운 구현을 바로 좀 확인시켜 드리고 싶었습니다.

앱 설치 및 사용은 다음과 같습니다.

갤3 기준입니다만, 거의 같습니다.

① 앱 Play 스토어를 실행합니다.

② 맨 위 돋보기를 탭, 영문에서 sy 입력, 밑에 리스트에서 synology 선택

③ DS 앱들이 주욱 뜨는데 여기서 DS audio 선택, 설치합니다.

④ DS audio 앱 열기

⑤ Wi-Fi를 끕니다.

⑥ DS audio 로그인 창에서 한사랑교회는 다음과 같이 했습니다.

주소 또는 QuickConnect ID : onelove.synology.me

계정 : admin

패스워드 : *******

나머지는 안 건드립니다.

⑦ 폴더 - music 으로 가서 테스트 용 파일을 실행합니다.

⑧ 이상 없으면 홈 버튼 왼쪽 탭, 로그아웃 탭

위 ⑤항은, 공유기 권역이 아닌, 일반 공중망에서도 잘 들어와지는지 보기 위해서입니다.

위 ⑥항에서, QuickConnect ID는 아직 안 만들었는데, 포트 전달 규칙 설정 등의 번거로움 없이 아홉 자리 숫자로 된 ID만 입력하면 해당 클라이언트 프로그램이 알아서 NAS에 연결하게 해주는, 일반 교인들 입장에서는 매우 획기적인 아이디어입니다. 제 경험으로는, 됐다 안 됐다 해서 잘 안 쓰지만...^^

QuickConnect를 지원하는 클라이언트들은 DS file, Cloud Station, DS photo+, DS audio 입니다.

지금은 첫 테스트라 admin으로 로그인했지만, 나중에 계정들 생성하면 각각 접근 권한 등을 컨트롤할 수 있습니다.

한사랑교회 목사님은, 조금 전까지만 해도 까만 기계 덩어리에 지나지 않았던 DS413이 이제 자기 스마트폰으로 오디오가 되니까 감격스러워 하셨습니다. 이제 교인들도 출퇴근 시, 스마트폰을 카오디오에 연결하면 운전 중 지난 주 설교를 마치 라디오 듣듯 들으실 수 있게 된 겁니다. 할렐루야!

이렇게 해서 music 폴더 밑으로 다음과 같이 서브 폴더들을 만들어 관리하면 됩니다.

주일예배

수요예배

새벽예배

부흥회

특새

세미나

기도회

음악회

주일학교

...

이상입니다.

3강은 여기까지 입니다.

출처 : http://bygrace.kr/14

Synology(시놀로지) DS413 설치후기 - ② DSM

JAESOO — Thu, 26 Mar 2015 09:31:57 +0000

이런 순서로 진행 중입니다.

1. 설치환경 준비

2. DSM

3. Audio Station

4. Photo Station

5. Video Station

6. Cloud Station

7. File Station

8. 기타 Station들

9. 제어판

10. 원격제어

오늘은 2강, DSM입니다.

2강 구성은 다음과 같습니다.

1. DSM 설치

2. NAS 구성

3. DDNS 구성

자, 그럼 순서대로

1. DSM 설치

DSM은 DiskStation Manager의 약자입니다.

DSM은 Synology NAS 운영체제의 그래픽 인터페이스입니다.

PC 운영체제로 Windows 7 혹은 Windows 8이 있듯이 말이죠.

아, 참고로, Synology NAS 운영체제는 리눅스입니다.

이 리눅스로 이렇게 Windows스럽게 UI(User Interface)를 참 잘 만들었죠?

1강에서 다운로드한 DSM 파일을 NAS를 제어 중인 PC에 설치합니다.

지금 설치 중인 DS413 모델에 대한 파일명은 다음과 같습니다. → DSM_DS413_3211.pat

설치가 끝나면 바로 DSM 로그인 화면이 떴는지 지금 잘 기억이 나지 않는데...

만일 안 뜬다면, DSM 설치에 이어 1강에서 DSM과 함께 받아 놓은 Synology Assistant 를 마저 설치합니다.

파일명은 SynologyAssistantSetup-4.2-3508.exe입니다.

설치가 끝나면 바탕화면에 생성된 아이콘으로 실행합니다.

잠시 동일 네트워크 안에 존재하는 시널로지 NAS를 찾습니다.

지금은 네트워크라야 공유기에 연결된 기기가 전부이므로, 검색되는 NAS는 하나 뿐일 겁니다.

검색 결과, 한 줄 뜰 텐데, 이 줄을 더블 클릭하면 해당 DSM이 실행됩니다.

밥 먹고 계속하겠습니다.

오래 기다리셨죠?

밥 먹고, 아내가 김치 담근다고, 같이 장 보고, 쪽파 다듬으라 하여 다듬느라 늦었습니다.

DSM 로그인 화면이 뜨면 아이디 admin 입력 후 엔터합니다.

첫 설정 시, 관리자 아이디 admin에는 패스워드가 없습니다.

관리 및 보안을 위해 아래 순서 2에서 생성하겠습니다.

DSM 설치는 일단 여기까지입니다.

2. NAS 구성

우선, NAS 이름을 주지요.

제어판 - 시스템 - 네트워크 - 일반으로 갑니다.

서버 이름 : oneloveNAS (교회 이름이 '한사랑')

기본 게이트웨이 : 192.168.0.1 (공유기라는 게이트를 통해 인터넷으로 나가니까)

DNS 서버 수동 구성 : 체크

기본 DNS 서버 : 168.126.63.1

대체 DNS 서버 : 168.126.63.2

일반 옆, 네트워크 인터페이스 탭을 엽니다.

LAN 포트에서 수동 구성 이용 선택,

IP 주소 : 192.168.0.100

서브넷 마스크 : 255.255.255.0 (그대로 놔두세요)

NAS에 Private IP 하나를 고정하는 건데요, 1강에서 공유기에서 이미 했기 때문에 안 해도 되지만, 나중에 공유기를 떼어 집이나 다른 장소로 이동할 수도 있기 때문에 그냥 한번 더 했습니다.

Jumbo Frame : Jumbo Frame 활성화. MTU 값은 다음과 같습니다 : 7000

한사랑교회 NAS는 Jumbo Frame을 이렇게 했습니다.

이 Jumbo Frame은 기가비트 네크워크 환경에서만 활성화되는 기능으로, 제대로 기능하려면, NAS, 곧, Disk Station에 엑세스하는 모든 기기가 이 기능을 지원하고, 또 동일 MTU 값을 가져야 합니다.

랜카드 등록정보에서 고급을 보면 기가비트 환경일 경우, Jumbo 프레임이라고 있는데 지금 이 글을 쓰고 있는 제 노트북의 경우, 9KB까지 있어 방금 저희 홈 NAS의 MTU를 9000으로 맞추고 네트워크를 다시 시작했습니다.

참고로, DSM 특정 화면에서 각 용어가 생소하시면 그때 그 화면 창 오른쪽 상단 물음표 동그란 아이콘 클릭하세요.

그러면, 그 창, 그 화면에 대한 자세한 안내를 받으실 수 있습니다.

그리고, 앞으로 NAS 사용하시면 점점 대용량 파일 전송이 많아져 결국 기가비트 환경이 절실하실 텐데 그때를 위해서 실은 지금 이 Jumbo Frame을 건드리고 있는 것입니다.

다 건드렸으면 밑에 적용 버튼 클릭

다음은 관리자 계정 admin의 암호를 정하지요.

제어판 - 파일 공유 및 권한 - 사용자로 가서 admin 계정 클릭 후, 상단 편집 버튼을 클릭합니다.

admin 창이 열리며, 바로 정보 탭이 열리고, 거기에 패스워드 넣는 데들이 보입니다.

패스워드 및 패스워드 확인 두 곳에 같은 패스워드를 입력합니다.

참고로, 아이디 admin을 보면 수정할 수 없게 디제이블 되어 있음을 볼 수 있습니다.

이어, 같은 창에서 사용자 그룹으로 가 혹시 admin 계정이 administrators 그룹이 아니면, 그러니까 오른쪽 끝 체크 박스가 비어 있으면 체크해 줍니다.

이어, 역시 같은 창 권한 설정으로 가서 아직은 뭐 없겠지만 거기 있는 모든 거, 읽기/쓰기 권한 줍니다.

admin 이니까요. ^^

아, 만일 나중에라도 리스트에 여러 개 죽 달렸다고 그거 일일이 체크하지 마시고, 이럴 땐, 타이틀 바에 있는 읽기/쓰기 왼쪽 빈 박스를 클릭하면 밑에 있는 것들 전부 한방에 먹는다는 거, 참고하세요.

admin 기본 설정 건드리는 건 이쯤 하고...

나중에 사용자 한 명 한 명 등록해야 할 일 생기는데 그때 지금처럼 하시면 됩니다.

NAS 구성은 일단은 이쯤 합니다.

3. DDNS 구성

DDNS는 Dynamic DNS를 말합니다.

그럼, DNS는 뭘까요?

자세한 건, 따로 IT 상식의 기초에 올리겠습니다만,

간단히 말씀드리면,

어떤 웹 사이트, 예를 들면, Synology 웹 사이트의 주소를 숫자 형태인 IP, 즉, 120.89.71.137 같은 형태 보다는, www.synology.com 같은 형태로 하는게 사람들이 기억하기 훨씬 쉽다는 점에 착안, 이 주소정보를 수집, 서비스하는 겁니다.

그럼, DDNS는 뭘까요?

앞에 'Dynamic'이라는 말이 붙은 것에서 알 수 있듯, DNS 주소정보가 움직인다는 겁니다.

보통은 안 움직여야, 즉, 변동이 없어야 하는데, 이건 변동이 있다는 겁니다.

한번 부여하면 안 변하는 IP 주소를 고정IP, 혹은, Static IP 라 하는데 이건 비쌉니다.

반면, 우리가 KT나 SKT, LG U+ 등에 인터넷 가입을 하면 회선과 함께 부여되는 IP가 있는데, 이 IP는 유동적이다, 즉, 변한다 하여 유동IP, 혹은 Dynamic IP라 합니다.

이건 별도 비용이 들지 않습니다.

문제는, 우리가 공유기를 껐다 켜거나 하면 이 IP가 바뀐다는 겁니다.

우리 집 NAS를 누가 찾아와야 하는데 주소가 그때그때 바뀌면...

그렇죠! 안 되지요. 주소라는 건 고정적이어야 합니다.

그러나 고정IP는 비쌉니다.

바로 이 문제를 해결하기 위해 등장한 기술이 바로 DDNS입니다.

즉, IP가 바뀌어도 변함없이 찾아오게 한다는 것입니다.

NAS 설치 후, 외부에서 쉽게 찾아올 수 있도록 뭔가를 설정해야 하는데 이게 바로 지금 하려는, DDNS 설정입니다.

자, 그럼, 시작합니다.

제어판 - 네트워크 서비스 - DDNS로 갑니다.

제어판 - DDNS 창에서 추가 버튼 클릭

그러면, DDNS 창이 뜨면서 몇 가지 정보를 요구합니다.

한사랑교회는 아래와 같이 입력했습니다.

DDNS 지원 활성화에 체크

서비스 제공업체 : Synology (원하시는 아무 회사나 선택)

호스트 이름 : onelove.synology.me (맨 앞 이름만 정하세요.)

사용자 이름 : abc@d.e (관리자 실제 메일 넣으세요.)

패스워드 : ******

외부주소 : (공유기 주소가 이미 선택되어 있습니다.)

Heartbeat : 사용

이렇게 입력 후, 지금 등록 클릭,

잠시 후, 맨 밑에 상태 : 가 정상으로 나오면 된 겁니다.

쉽지요?

위 Heartbeat는, 무슨 이유에선지 DDNS 연결이 끊어지면 Synology MyDS Center에서 알람을 보내는, 그런 기능입니다.

다 되었으면 하단 확인 클릭합니다.

이제 브라우저에서 http://onelove.synology.me:5000 이렇게 입력 후 엔터해 보세요.

그럼, 잠시 후, 브라우저에 짠! 하고 DSM 화면이 떠 주면 얼마나 좋을까요?

그러나 애석하게도 아직 끝난 게 아닙니다.

외부에서 접근하는 상황이기 때문에, 그렇게 쉽게 대문이 열리면 안 되거든요.

요즘 워낙 악의적인 접근들이 많아서...

그래서 한 가지 더 해줘야 하는데, 그게 바로 포트포워딩이라는 겁니다.

좀 지치셨을 듯도 하지만 이제 정말 끝이니까 조금만 더 가죠.

포트포워딩 시작합니다.

포트(port)에 대한 기본 이해가 필요하신 분은 아래 링크를 참조하세요.

'포트번호'가 뭔가요? → http://bygrace.kr/10

그냥 가정집 상황으로 설명하지요.

외부에서 우리 집 내부 네트워크으로 들어오려면 반드시 대문 역할을 하는 놈을 거쳐야 합니다.

그 놈이 바로 공유기입니다.

공유기는 대기하고 있다가 어떤 외부의 침입을 감지하면 다음과 같이 합니다.

"너, 누구야?"

"저는 누구누군데 NAS와 대화하고 싶어요."

"NAS 안에도 여러 어플들이 있어. 정확히 말해. 그 중 누구랑 대화하겠다는 거야?"

"DSM이요."

"DSM에 해당하는 번호 말해. 이거 틀리면 너, 간첩이야!!!"

"5000이요."

"기다려. 음, 맞군! 그러면, 너는 몇 번으로 가."

위 대화에서 외부인이 말한 5000이 DSM 포트번호입니다.

공유기는 중간에서 보초를 서며, 한편으로 교통정리를 하는 거죠.

공유기 포트포워딩은 다음과 같이 합니다.

① 공유기 관리자 화면에서 고급 설정 - NAT/라우터 관리 - 포트포워드 설정으로 갑니다.

② 오른쪽 포트포워드 설정에서, 예를 들어, 아래와 같이 하지요.

규칙 이름 : DSM

내부 IP주소 : 192.168.0.100

프로토콜 : TCP

외부 포트 : 5000

내부 포트 : 5000

③ 위와 같이 하고, 추가 클릭,

④ 그러면, 하단에 한 줄 생깁니다.

⑤ 왼쪽 번호 옆 체크 박스 체크 후, 위 동작 버튼 클릭, 동작시켜 줍니다.

이제 다 됐습니다.

이제 브라우저 열고, http://onelove.synology.me:5000 해보세요.

실제로 이 글을 쓰는 현 시점에서, 위 주소는 아직 연결이 안 됩니다.

NAS 이동 중이거든요... ^^

실제로 작동 중인 NAS를 보고 싶으시면...

아래, 저희 홈 NAS로 들어와 보시죠. ^^

http://2237.synology.me/

2강, 마칩니다.

길었네요...

출처 : http://bygrace.kr/13

Synology(시놀로지) DS413 설치후기 - ① 설치환경 준비

JAESOO — Thu, 26 Mar 2015 09:31:40 +0000

어제 한사랑교회(담임목사 정진기)를 다녀왔습니다.

한사랑교회는 세종시 장군면 금암리 한국 영상대 들어가는 길 입구 언덕에 있습니다.

목사님의 부탁으로 NAS 설치를 하러 갔는데 모델은 DS413, 아직은 주위에 NAS 사용하시는 분들이 거의 없으셔서 설치 기회가 주어진 게 얼마나 다행인지요. ^^

NAS에 대한 담론 수준의 이야기를 통해 관심을 일으켰다면 이제 그럼 NAS 설치 및 운영을 어떻게 하는가 실무가 필요하다 여겨져 이야기와 병행, 실무를 시작합니다.

어제 설치 전과정에 대한 기억이 아직 생생할 때 말이죠...^^

이런 순서로 진행할까 합니다.

1. 설치환경 준비

2. DSM

3. Audio Station

4. Photo Station

5. Video Station

6. Cloud Station

7. File Station

8. 기타 Station들

9. 제어판

10. 원격제어

물론, 이 외에도 참 많은데 교회에서는, 작은 교회에서는 우선 이 정도면 충분할 것 같습니다.

그럼, 시작합니다.

첫 번째, 설치환경 준비입니다.

기본적으로, NAS는 공유기에 연결하는 걸로 하겠습니다.

이 글의 주요 대상이 소규모 교회이기 때문입니다.

어제 설치환경은,

NAS : DS413

공유기 : ipTIME N904

인터넷 : 광(光)이 아니라 하시니 아마도 10Mbps 동선일 듯...

이었습니다.

다음 순서로 설치환경을 준비했습니다.

1. 설치 PC 준비

2. DSM 다운로드

3. 박스 언패킹

4. NAS, 공유기에 연결

순서대로,

1. 설치 PC 준비

NAS는 PC 혹은 노트북 등 외부 디바이스로 설치 및 제어를 합니다.

PC 본체에 모니터 연결하듯 할 수 없습니다.

항목 2에서 DSM을 다운로드해야 하니 당연히 설치PC는 인터넷 연결이 되어 있어야 합니다.

공유기는 이미 설치, PC로 인터넷을 하고 있는 환경이었습니다.

2. DSM 다운로드

PC에서 http://www.synology.com/support/download.php 로 연결, 해당 베이 및 모델을 선택합니다.

여기는 DS413이므로 베이는 4, 모델은 DS413을 선택했습니다.

이어지는 화면에서 DSM 다운로드를 Global로 합니다.

오른쪽 상단에는 DSM 버전과, 데이트가 표시되어 있습니다.

어제 보니, Version : DSM 4.2-3211; Build Date : 2013/04/18 로 되어 있었습니다.

계속해서 그 아래 Synology Assistant 를 Global로 다운로드합니다.

얘가 있어야 DSM 로그인 화면이 뜹니다.

기본적으로 우리는 Windows 환경이기 때문에 Windows 버전으로 다운받습니다.

혹시 리눅스 환경이거나 애플의 Mac 환경이면 각각, 거기에 맞는 걸로 받으셔야 합니다.

항목 4번에서, NAS를 공유기 내부IP 중 하나로 고정시킬 때 NAS MAC 어드레스가 필요한데 그때도 얘가 필요합니다.

박스 겉에도 MAC 어드레스가 있기는 합니다만...

3. 박스 언패킹

박스를 개봉하면 파워 케이블, 랜 케이블, DVD, 사용설명서, 본체 등이 들어 있습니다.

HDD가 함께 내장된 NAS이면 바로 연결하면 되고,별도, 즉 NAS 본체 케이스 따로, HDD 따로 구매하셨으면 이 단계에서 HDD를 장착하셔야 합니다.

어제 DS413은 내장되어 있었고, HDD 구성은 1, 1, 3, 3, 즉, 1테라 두 개, 3테라 두 개를 각각 개별 볼륨으로 구성되어 있는, RAID를 전혀 염두에 두지 않은, 그런 구성으로 되어 있었습니다.

목사님이 업체에게 그렇게 요청하셨다고 합니다.

목사님은 꼭 필요한 파일들은 따로 백업 방안을 마련하셨더군요.

각각의 볼륨은 나름대로 생각하고 계신 별도 용도가 있었습니다.

덕분에 8테라에 달하는 볼륨구성시간을 절약할 수 있었습니다. ^^

박스 윗면 구석에 MAC 어드레스 및 S/N을 확인합니다.

4. NAS, 공유기에 연결

NAS 본체를 전원에 연결하고, 랜 선을 공유기에 연결합니다.

NAS 본체 케이스 앞면에 있는 전원버튼을 눌러 켭니다.

이렇게 하면 일단, NAS에는 공유기가 임의로 뿌린 192.168.0.xxx Private IP 하나가 배정될 겁니다.

NAS는 여러 이유로, IP를 고정하는 게 좋겠습니다.

다음과 같이 합니다.

① PC 브라우저 주소창에 http://192.168.0.1 하여 공유기 관리자 화면으로 들어갑니다.

② 고급 설정 - 네트워크 관리 - 내부 네트워크 설정으로 순서대로 들어갑니다.

③ 오른쪽 내부 네트워크 설정 창 하단, 수동 IP 할당 설정에서 오른쪽 추가 버튼 밑 검색되어 리스트된 MAC 주소들 중 NAS 것을 찾아 맨 왼쪽 빈 박스를 클릭

④ 그러면 리스트 위 빈 박스들에 NAS의 IP 및 MAC이 복사됩니다. 밑에 NAS 체크 박스 해제

⑤ 복사된 NAS 정보 중 IP를 원하는 걸로 수정, 어제 DS413은 '100'번을 주었습니다.

⑥ 다 되었으면 추가 버튼 클릭

⑦ 그 위에 있는 적용 버튼 클릭, 상단 오른쪽 저장 버튼 클릭

⑧ 공유기를 다시 시작합니다. 고급 설정 - 시스템 관리 - 기타 설정으로 가서 공유기 다시 시작의 적용 버튼 클릭

이제 DS413은 늘 내부 고정IP 192.168.0.100을 갖게 됩니다.

물론, DSM을 실행, NAS 자체에도 자기 자신을 고정시키는 기능이 있습니다.

어제 DS413은 양쪽 다 걸어주었습니다.

1강은 여기까지입니다.

출처 : http://bygrace.kr/12

Hitachi HGST 5TB/6TB DeskStar NAS 패키지 HDD

JAESOO — Wed, 25 Mar 2015 20:27:13 +0000

1 . Hitachi HGST 5TB/6TB DeskStar NAS 패키지

데스크탑, NAS용 HDD는 물론 SSD와 모니터 등으로도 유명한 에스지컴퓨터(링크)에서 출시한

Hitachi HGST 5TB DeskStar NAS HDN726050ALE610 패키지 (SATA3/7200/128M),

Hitachi HGST 6TB DeskStar NAS HDN726060ALE610 패키지 (SATA3/7200/128M)는

최근 플레이웨어즈 온라인에 제공되면서 많은 호응을 받았던 고용량 NAS용 HDD 제품입니다.

동시에 출시됐었던 3TB / 4TB 제품(리뷰 링크)와 마찬가지로, 5TB / 6TB 또한 같은 시기에 출시되면서

3TB / 4TB에 비해 스펙이 조금씩 업그레이드된 것이 특징입니다.

단위 면적당 밀도가 약 58% 증가하였고, 데이터 버퍼는 2배 증가,

소비 전력은 약 36% 감소하는 등 용량 증가와 더불어 성능 향상도 기대해볼 만한 부분이겠습니다.

그럼, 각 제품들을 간략하게 살펴보고, 플웨즈의 HDD 벤치마크 툴을 사용하여 각 제품들의 성능이 어느 정도 되는지 알아본 다음

각 HDD별로 발생하는 소음 측정 및 소비 전력 테스트를 추가로 진행해 보도록 하겠습니다.

2 . 제품 패키지 및 외형

3 . 공식 스펙 및 정보 확인

Hitachi HGST 5TB DeskStar NAS HDN726050ALE610

Hitachi HGST 6TB DeskStar NAS HDN726060ALE610

제조사가 공개한 공식 스펙은 위와 같습니다.

앞서 언급한 바와 같이, 기존 3TB / 4TB 제품 대비 단위 면적당 밀도 약 58% 증가, 데이터 버퍼 2배 증가,

소비 전력 약 36% 감소 등의 업그레이드가 있습니다.

HDD인 만큼, SSD에 비하면 그 성능 향상폭이 크지는 않겠으나...여러모로 소비자 입장에서는 반가운 부분이라 하겠습니다.

■ 디스크 정보 확인

Hitachi HGST 5TB DeskStar NAS HDN726050ALE610

Hitachi HGST 6TB DeskStar NAS HDN726060ALE610

■ 최대 전송률 확인

ATTO Disk benchmark 2.4.7의 QD4 기본설정으로 재부팅 직후 진행된 테스트입니다.

최대전송률을 가장 잘 반영해주는 이유로 공식스펙 측정에 자주 사용되는 유틸리티입니다.

Hitachi HGST 5TB DeskStar NAS HDN726050ALE610

Hitachi HGST 6TB DeskStar NAS HDN726060ALE610

최대 전송률은 기존에 플웨즈에서 살펴본 HDD 중에서 상당히 높은 수치의 결과를 보여주었습니다.

특히 6TB 제품의 경우 200MB대를 돌파했다는 점에서 의미가 있겠습니다.

■ 액세스 시간 확인

HD Tune Pro 5.50은 하드디스크 전송속도, 액세스타임, CPU 점유율 등의 벤치마킹과

하드디스크 정보 검색 등 다양한 시스템 관리 기능을 가진 프로그램입니다.

벤치마크 탭으로 순차 액세스 시간을, 무작위 액세스 탭으로 랜덤 액세스 시간을 측정하였습니다.

● 5TB

● 6TB

확인 결과, 전체적으로 전송속도, 액세스 시간 등에서 모두 좋은 수치를 보여주었습니다.

읽기 속도에 비해 쓰기 속도가 약간 부족해 보이지만, 평균적으로는 우수한 성능을 보이리라 예상됩니다.

■ 디스크 공간 확인

Hitachi HGST 5TB DeskStar NAS HDN726050ALE610

Hitachi HGST 6TB DeskStar NAS HDN726060ALE610

4 . 테스트 환경

HDD 제품의 경우, 더티테스트에 의미가 없기 때문에...클린/더티의 구분 없이 결과에 반영하였습니다.

기본적으로 OS 및 필수 프로그램은 이전 벤치마크 진행시 제작되었던 2013년 9월 11일자 노턴고스트 백업을 사용하였으며,

그 외 테스트별 차이점은 각각의 페이지에서 별도로 언급하도록 하겠습니다.

5 . Crystal Disk Mark

Crystal Disk Mark는 순차 및 랜덤 읽기 / 쓰기 속도를 측정하는 프로그램으로 매우 간단한 인터페이스를 가지고 있는 것이 특징입니다.

Crystal Disk Mark 테스트는 HDD를 포맷 한 직후인 클린상태에서 진행되었습니다.

■ 순차 읽기

■ 순차 쓰기

■ 4K 읽기

■ 4K 쓰기

Crystal Disk Mark 벤치마크 결과...대부분의 항목에서 최상위권의 우수한 결과를 보여주었으며,

이전 모델이라 할 수 있는 HGST 4TB Deskstar와 비교해보면 상당히 발전했다고 평가할 수 있겠습니다.

4K 쓰기에서는 다소 낮은 수치가 측정되었지만, 순차 읽기/쓰기 모두 200MB/s를 넘기는 수치를 나타냈기 때문에

전체적으로는 좋은 실성능을 내줄 것이라 예상됩니다.

6 . PCMark8

PCMark8은 업계 표준 PC 벤치마크 테스트 프로그램으로써 어도비 크리에이티브 슈트, 마이크로소프트 오피스, 인기 게임 등을 사용하여

SSD 및 하이브리드 저장 장치를 테스트 할 수 있으며, 저장장치 간의 실제 성능 차이를 표시해줍니다.

PCMark8 테스트는 윈도우 및 벤치마크 프로그램 등을 설치한 뒤(노턴고스트로 이미지 복구) 진행하였습니다.

벤치마크 결과로서의 의미보다는, 실생활에서의 전체적인 평가 지표로 활용할 수 있는 PCMark8의 스토리지 테스트에서도

역시 상위권에 속하는 결과를 보여주었습니다.

굳이 NAS용이 아니더라도, HDD의 성능 한계를 감안하여 사용한다는 의미에서는 충분히 만족할 만한 수준으로 판단됩니다.

7 . 파일 스캔

Avast Free Antivirus는 개인 사용자의 경우 무료로 사용할 수 있으며, 보안기능 및 검사속도가 우수한 백신 프로그램입니다.

파일스캔 테스트시 사용한 설정은 아래와 같으며, 엔진 및 바이러스 패턴, 프로그램의 업데이트를 수동으로 설정하여

추후 테스트시에도 동일한 조건에서 파일스캔을 할 수 있도록 하였습니다.

Avast Free Antivirus 테스트는 윈도우 및 벤치마크 프로그램 등을 설치한 뒤(노턴고스트로 이미지 복구)

타 스토리지 리뷰와의 비교를 위해 제품 용량 4TB 중 약 240GB를 게임 및 프로그램 설치파일로 채우고 진행하였습니다.

※ HDD의 용량은 4TB이지만, 타 스토리지 리뷰와의 결과값 통일성을 위해 240GB를 기준으로 테스트 하였음을 참고바랍니다.

파일 스캔 결과는 상위권에 속하는 무난한 성능을 보여주었습니다.

두 제품간의 차이는 크지 않은 편이지만...

5TB에 비해 6TB가 조금씩 더 좋은 결과를 보이는 양상이 지속적으로 나타나고 있습니다.

8 . 파일 복사

파일복사 테스트는, 파일압축 테스트와 동일한 파일을 사용하여 해당 HDD 내부에서 복사 > 붙여넣기로 테스트를 진행하였습니다.

파일 복사 테스트는 윈도우 및 벤치마크 프로그램 등을 설치한 뒤(노턴고스트로 이미지 복구) 진행하였습니다.

압축에 사용된 단일 / 복합 파일의 정보는 아래와 같습니다.

파일 복사 테스트에서는 최상위권에 속하는 성능으로 확인되었으며, 단일 / 복합 파일과의 차이도 크지 않았습니다.

이전 HGST 4TB Deskstar 제품에 비하면 엄청난 발전...

공식 스펙상으론 5TB와 6TB의 차이가 거의 없는 편이었지만...

ATTO, HD TUNE 등으로 측정했던 전송속도, 액세스 타임 등에서 확실히 차이가 났었고, 벤치마크에서도 대부분 6TB가 더 좋은 결과를 보였기에

성능적인 부분만으로 판단하자면 6TB가 좀 더 좋다고 평가할 수 있겠습니다.

9 . 파일 압축

반디집은 멀티코어를 활용하여 최대 6배까지 빠른 속도로 압축이 가능한 고성능 무료 압축프로그램으로,

대용량 파일 압축과 분할 압축 및 해제 기능이 뛰어나고 ALZ, EGG 파일 등 다양한 압축 포맷을 지원합니다.

가정은 물론 기업, 공공기관, 교육기관, PC방 등에서도 무료로 사용이 가능합니다.

압축 시간 테스트는 윈도우 및 벤치마크 프로그램 등을 설치한 뒤(노턴고스트로 이미지 복구) 진행되었습니다.

압축에 사용된 단일 / 복합 파일의 정보는 아래와 같습니다.

파일 압축 테스트 역시 파일 복사 테스트와 마찬가지로 최상위권을 갱신하는 우수한 결과를 보여주었습니다.

Crystal Disk Mark 벤치마크에서 4K 쓰기를 제외하고는 전체적으로 좋은 결과를 보여준 것과, 위 테스트 결과들로 미루어 보면,

단순 읽기 작업보다는 읽기+쓰기가 혼합된 작업에서 좀 더 효율적일 것이라고 예상됩니다.

10 . 소음 측정

이번 리뷰에서 진행하는 HDD 소음 테스트는, 기존에 플웨즈 리뷰에서 자주 사용했던 Class2 인증 장비 Cirrus사의 CR-172A를 사용하였습니다.

- Cirrus Reserch plc

CR-172A Optimus sound level meter for Enviromental & Occupational Noise

1. Real-time 1:1 옥타브 밴드

* 31.5hz ~ 16,000hz 측정범위 (31.5 / 63 / 125 / 250 / 500 / 1000 / 2000 / 4000 / 8000 / 16000)

* 전체 측정구간을 대상으로 각 밴드별 Leq값을 표기합니다.

2. 녹음기능

* 16bit 16khz WAV형식 , 또는 32bit 96Khz WAV형식 지원

* 측정과 녹음을 동시에 진행할 수 있으며, 녹음 발동 조건지정 가능 (음의 세기 등)

* 4GB 내장메모리 제공

* PC의 마이크단자에 스테레오 케이블을통한 직결가능 > 마이크로 기능

3. Class2 인증의 고성능과 폭넓은 범용성

* 최하 21dB / 최고 140dB까지의 측정범위 제공

* EU, UK, OSHA, MSHA, ACGIH등 기관 표준 산법을 모두 제공

CR-172A 장비와 HDD간의 거리는 약 10cm로 고정하였습니다.

- Sontek

TS95 Noise test booth

- 자유음장 구현을 위한 무향/반무향설비에는 미치지 못하는 간이소음측정 박스.

- 1000hz 이상의 음역대에서는 무향실과 유사한 특성을 보이는 편으로, 상대적으로 저음역대의 차폐에는 손색이 있습니다.

- 차음량 STC 25 수준 보증, 정확한 음색특정보다는 대략적인 소음수준 판별에 유의한 장비.

Sound Transmission Class ?

- 소리가 특정한 벽을 통과했을 때의 소음감쇄정도를 정의한 단위.

- 125~4000hz 범위의 speech frequencies를 척도로 합니다(일상 대화위주)

- STC 단위가 10 변동하였을 시의 체감소음차이는 두 배로 잠정할 수 있습니다.

TS95에서 최소보증하는 STC25의 경우,

STC	체감수준
25	벽을 사이에두고서도 일상대화에 지장이 없음
30	일반적인 성량으로는 의미전달이 어려움
35	크게 말해도 의미전달이 어려움 (소리는 들리지만, 의미가 닿지못함)
40	사생활이 보장됨
42	큰 말소리가 '웅얼웅얼..' 수준으로 전달
45	큰 말소리조차 거의 들리지 않음 90%의 사람은 일체의 육성을 전혀 인지하지 못함
50	99%의 사람이 육성을 전혀 인지하지 못함 라이브 공연 실황수준의 소음은 간신히 청취가능
60이상	거의 완벽한 차폐

필자가 사용하는 테스트 벤치에서는 HDD의 소음만을 정확히 측정하기 어려운 관계로...

밀폐된 사운드박스 내부에 HDD + 도킹스테이션을 설치하고, 외부에서 노트북을 연결하여 HDD를 작동하도록 하였습니다.

HD Tune Pro의 랜덤 억세스 기능을 사용하여 HDD의 소음을 유발시켰으며,

비교를 위해 사운드박스 내부의 기본 소음치, HDD가 대기 상태일 때의 소음치를 추가하여 그래프를 작성하였습니다.

일반적인 소음, 즉 dBA의 경우...

5TB 제품은 idle 상태에서 하위권, load 상태에서 중위권 수준의 소음치를 보였으며, 6TB 제품은 정반대의 성향을 보여주었습니다.

두 제품 모두 평균적인 소음치을 가지고 있으며, 어느 쪽이든 50 dBA를 넘지 않는 준수한 편이기 때문에

딱히 어느 제품이 낫다고 보긴 어렵겠습니다.

하지만, 인간은 같은 음압(dB)이라고 하더라도 주파수에 따라 크게 다른 느낌을 받습니다.

일명 고주파음을 견디기 힘든 것이 이런 이유 입니다.

일례로 1KHz의 40dB와 20Hz의 90dB는 사람에게 같은 수준으로 느껴집니다.

따라서, 옥타브밴드(Octave Band)인 일명 각 주파수의 소음레벨을 각기 측정하여

NC(Noise Criteria),curve를 통해 최소 가청한계를 구하는 것이 실체감에 밀접한 관련이 있습니다.

그에 따라, Class2 인증 장비 Cirrus사의 CR-172A로 측정한 NC값은 다음과 같습니다.

흔히 고주파음이라고 판단할 수 있는 NC 1kHz 대역의 결과는 두 제품 모두 중하위권의 수치를 보여주었습니다.

비교군 내, 특히 이전 모델인 4TB에 비해서는 아쉬운 결과지만,

전체적으로 50 dBA를 넘지 않는 무난한 소음치이기 때문에 민감한 사용자가 아닌 이상, 고주파음에 대한 걱정은 없을 것으로 판단됩니다.

11 . 소비 전력

※ 소비전력의 경우, Wattman 테스터기를 통해 얻어지는 데이타 값의 평균치를 측정하였습니다.

idle - 유휴

load - 풀로드

5TB

6TB

소비전력은 공식스펙과 비교하면 약간 아쉬운 성능을 보였습니다만,

두 제품 모두 일반적인 서버/NAS용 HDD와 비교시 큰 차이가 없는 편이며...

특히 6TB 제품은 풀로드시에도 전력소모가 크지 않는 등, 전체적으로는 좋은 모습을 보여주었습니다.

NAS용 뿐만 아니라 일반적인 데스크탑용 HDD로 사용해도 큰 무리가 없는 수준.

12 . 결론

Hitachi HGST 5TB/6TB DeskStar NAS 패키지는...

HDD 전문 제조회사 Hitachi에서 NAS 전용으로 제작한 HDD 제품으로, 7200 RPM 적용,

평균 사용 100만 시간 보증 및 24시간 동작 적용, RVS(회전진동 센서), TFC(데이터 에러율 최소화) 센서 내장,

HEAD 파킹, S.M.A.R.T, 에러율 조정 지원 등 지난 3TB / 4TB 제품과 동일한 특징을 지니고 있습니다.

하지만 이번 5TB / 6TB의 경우 단위 면적당 밀도 증가, 데이터 버퍼 증가, 소비전력 감소 등

단순히 용량 증가만 한 것이 아니라, 확연하게 성능 차이가 날 정도의 업그레이드를 거쳤다는 점은

확실히 좋은 부분으로 평가할 수 있겠습니다.

물론 HDD 제품인 만큼, SSD 제품처럼 그 차이가 크게 나지는 않지만...

4K 쓰기를 제외한 모든 벤치마크 항목에서 탑 클래스급 성능을 보였으며,

실생활 테스트에서는 단순 읽기보다 읽기/쓰기가 혼합된 작업에서 더 좋은 효율을 보이는 등

다방면에 활용할 수 있는 제품이기 때문에, NAS 사용은 물론 일반 데스크탑 사용에 있어서도 무리없는 제품이라 할 수 있겠습니다.

물론, 우수한 성능을 보여주는 만큼의 가격대를 형성하고 있는데, 글 작성시 기준 인터넷 최저가는

Hitachi HGST 5TB DeskStar NAS HDN726050ALE610 패키지 : 276,700원

Hitachi HGST 6TB DeskStar NAS HDN726060ALE610 패키지 : 348,990원으로, 다소 부담스러울 수도 있는 가격이긴 하지만...

제품이 보여준 성능과, 차별화된 고급 패키지 구성 및 3년 무상 A/S 등 충분히 만족감을 얻을 수 있는 제품이기 때문에

개인용 NAS 구성을 고려하는 사용자 또는 높은 성능의 HDD를 원하는 사용자에게 딱 알맞는 제품이라고 판단됩니다.

※ 지난 6TB 플온에 이어...현재 5TB 플온이 진행중이니 참고 바랍니다.(플온 링크)

작성자 : 플레이웨어즈 부운영자 / 저장매체, 모바일 담당자 Nakotaku

출처 : http://www.playwares.com/xe/44874482

시놀로지(Synology) NAS SMB2 및 Large MTU 설정하기

JAESOO — Sat, 21 Mar 2015 21:23:51 +0000

시놀로지 NAS 에서 설정을 보면 아래와 같이 SMB2 및 Large MTU 를 설정하는 부분이 있습니다.

SMB2 와 LargeMTU 는 파일을 전송할 때 패킷으로 잘게 쪼개서 보내는데, 좀더 크게 쪼개서 파일전송할 때 부하를 적게하여 속도를 빠르게 할 수 있습니다.

속도 증가를 위해 체크하고,

SMB2와 LargeMTU는 윈도우에서도 설정을 해주어야 합니다.

기본으로 SMB1이 설정되어 있다고 하네요.

아래의 명령을 CMD 창에 넣고 실행하면 SMB2가 활성화됩니다.(윈도우 7의 경우)

sc.exe config lanmanworkstation depend= bowser/mrxsmb10/mrxsmb20/nsi

sc.exe config mrxsmb20 start= auto

다른 OS의 경우 아래의 링크를 참조하셔서 설정하시면 됩니다.

영문을 번역하여 나오게되는데, 영어 원문을 확인하시고 command를 확인하세요.

http://support.microsoft.com/kb/2696547

설정하고 보니, 최고 속도가 조금 빨라졌네요.

최고속도가 10MB를 넘지 않았는데, 최고속도가 20MB까지 나왔습니다.

내부 회선 속도가 느린편인데 이정도면 잘나오는것 같습니다.

설정전

설정후

출처 : http://www.berrycracker.net/archives/2267

기가비트 이더넷 네트워크 구축에 관해

JAESOO — Sat, 21 Mar 2015 21:23:34 +0000

꽤 오래 전에 이미 기가비트 이더넷 관련 장비들의 가격이 많이 떨어졌고 또 요즘 나오는 대부분의 메인보드나 노트북에는 기가비트 이더넷이 기본 장착돼서 나오면서 많은 분들께서 기가비트 이더넷 네트워크로 많이 옮겨가는 추세입니다. 이 중에서 널리 다뤄지지 않는 부분에 대해 얘기해보려고 합니다.

1. 점보 프레임

점보 프레임은 기존 이더넷의 표준 MTU인 1500바이트보다 큰 MTU 크기를 갖는 프레임(이더넷 상의 패킷)을 얘기하는데, 일반적으로 최대 9KB까지 설정할 수 있습니다. 점보프레임을 사용함으로써 얻을 수 있는 이득은 첫째, 패킷을 잘게 쪼갤 때보다 크게 쪼갤 때 쪼개는 횟수가 더 적어지기 때문에 패킷 처리에 드는 성능 소모를 줄일 수 있다는 이점이 있고, 둘째는 각 패킷의 앞머리에는 헤더가 붙기 마련인데, 잘게 쪼갤 때보터 크게 쪼갤 때, 전체 데이터 흐름에서 헤더가 차지하는 비율이 적어지기 때문에 헤더로 인한 오버헤드가 적어진다는 점이 있습니다.

그러나 점보 프레임이 마냥 축복인 것만은 아닙니다. 한 네트워크 안에서의 MTU크기는 모든 장치들이 같은 크기를 공유해야 한다는 점이 가장 크게 작용하는데 위에서 언급한 것처럼 대부분의 기가비트 이더넷 장비들은 9KB까지 MTU를 설정할 수 있지만, 일부 저가형 장비들은 9KB 미만을 지원하는 경우도 더러 있고, 또 점보 프레임은 흔히 말하는 무선랜, 802.11에는 해당사항이 없다는 점이 문제점으로 작용합니다.

대부분의 데이터 통신은 TCP로 이뤄지고, TCP 연결이 처음 성립될 때 양쪽의 MTU를 고려하여 MSS(최대 세그먼트 크기; TCP 패킷으로 한 번에 전송될 수 있는 최대 크기)를 서로 정해놓고 데이터를 주고 받기 때문에 양쪽의 장비의 MTU가 달라서 생기는 문제는 잘 드러나지 않는 편입니다. 하지만 이더넷 상에서 점보프레임의 크기를 서로 정하고 통신하는 것은 아니기 때문에 TCP 이외의 프로토콜, 대표적으로 UDP 통신의 경우에는, 어떤 장비에 처리할 수 있는 MTU 크기보다 더 큰 크기의 패킷이 들어오면 그 패킷은 버려지게 됩니다. 이런 이유로 아주 드물게 나타나는 호환성 문제가 발생하면 찾아내기 무척 어려운 경우가 되기 마련입니다.

예전에 기가비트 이더넷이 처음 등장했을 때는 CPU의 처리속도도 지금에 비해선 대단히 느린 편이었고, 그때의 네트워크 패킷 프로세서들도 성능이 지금만큼 좋지 못했기 때문에 점보프레임을 사용함으로써 얻는 이득이 적지 않은 편이었지만, 지금은 대부분의 메인보드 내장 칩셋도 패킷 분할을 CPU에 맡기지 않고 자신이 스스로 처리하는 기능(오프로드)을 많이 지원하고 있고, 지원하지 않는 경우라도 CPU가 처리하기에 전혀 티가 나지 않는 정도기 때문에 무작정 점보프레임을 사용하려고 하기보다는 다른 장비와의 호환성 문제, 설정의 번거로움과 성능 상의 이점을 따져서 결정하시는 편이 좋습니다.

2. 케이블 선재

많은 분들께서 대체적으로 오해하고 계시는 분이 이 부분이 아닐까 싶습니다. 이렇게 된 데에는 역사적인 이유가 있는데 간단하게 소개하자면 이렇습니다.

기가비트 이더넷의 초기 표준의 정식 명칭은 1000BASE-TX였습니다. CAT6 케이블을 사용하여 최장 100m까지 문제 없이, 즉 패킷 손실이나 속도 저하 등이 전혀 없는 클린한 상태로 통신할 수 있도록 규정된 표준이었습니다....만 이게 나중에 새 표준으로 많이 대체되었습니다. 지금도 많이 그렇지만 당시에는 CAT5 케이블이 많이 포설되어 있었고 CAT5로도 기가비트 이더넷을 쓸 수 있게 해달라는 요구가 있어서 나중에 1000BASE-T라는 새 표준이 나옵니다. 여러분이 헷갈려하시는 게 바로 이것 때문인데, -T 표준에서는 CAT6도 아니고, CAT5e도 아니고, 무려 CAT5로 최장 100m까지 문제없이 통신할 수 있도록 규정된 것이기 때문입니다.

허나 1000BASE-TX와 과거 패스트 이더넷 규격인 100BASE-TX가 이름이 서로 비슷했기 때문에 대부분의 제조사가 1000BASE-T와 TX를 지원하면서도 제품 설명엔 1000BASE-TX만을 적어놓는 경우가 정말 많았고, 역시 1000BASE-T와 TX가 별개의 표준인 걸 잘 모르는 대부분의 사용자들은 1000BASE-TX는 CAT6를 필요로 하기 때문에 기가비트 이더넷을 쓰려면 최소 CAT6 이상의 케이블을 써야 한다고 알게 된 겁니다. 1000BASE-TX가 CAT6를 필요로 한 건 맞긴 했지만 1000BASE-T의 존재는 사용자들에게는 잘 알려지지 않았기 때문에 그렇게 된 게 아닐까 합니다.

각설하고, CAT5와 CAT5e의 차이는 단지 크로스토크에 대한 규격의 유무 뿐이라서 사실 두 케이블의 차이는 거의 없는 편입니다. 다만 CAT5e와 CAT6의 대표적인 차이는 케이블이 지원하는 대역폭인데, 전자는 100Mhz, 후자는 250Mhz를 실을 수 있어야 합니다. 당연히 100Mhz의 대역폭으로도 똑같이 초당 기가비트의 데이터를 주고 받을 수 있어야 하니 1000BASE-T 장비가 1000BASE-TX보다 비쌌던 게 당연했지만, 지금은 꾸준한 단가 하락와 공정 개선으로 1000BASE-T를 지원하지 않는 장비가 사실 상 거의 없다는 것이지요.

따라서 결론적으로 규격 상으로는 CAT5로도 기가비트 이더넷 네트워크 구축이 가능하다...고 말할 수 있겠지만 실제 환경에선 대개 그렇지가 않는 게 문제입니다. CAT5e 표준이 나온 뒤로는 CAT5 케이블 생산이 거의 멎었고, 두 규격이 거의 같기 때문에 CAT5가 지금은 아예 나오지 않는 걸로 압니다. 따라서 건물에 깔려있는 CAT5는 이미 낡을 대로 낡고 삭아버린 케이블이라 케이블 규격을 따지기 이전에 상태가 대단히 좋지 않기 때문에 기가비트 이더넷을 쓰기엔 다소 무리가 있는 편입니다. 그래서 일반적으로 더 이상 생산되지 않는 CAT5 대신 CAT5e를 기가비트 이더넷의 권장사양으로 얘기할 수 있는 것입니다. 최소사양이 아닌 이유는, 크로스토크에 대한 규격이 없는 CAT5에서도 전혀 문제없이 사용가능하기 때문이고, CAT5e는 이보다 더 나은 규격을 갖고 있기 때문입니다.

간혹 CAT5e로 충분하다는 말을 듣고 해봤더니 속도가 안나오더라, 하는 경우도 사실 위와 비슷한 이유입니다. 실제로 CAT5e 케이블이 나온지도 무지 오래 됐기 때문에 케이블 자체가 이미 낡았거나, 모듈러 잭을 잘못 찝었다든가, 의외로 드물지 않게 4페어 중 2페어만 연결된 경우가 대부분이었습니다. 때문에 댁이나 회사에 있는 케이블이 CAT5e라고 해서 무작정 케이블을 바꿔보려고 하시기보다는 우선 이미 있는 것도 쓸만한 거니까 먼저 시험해보고 결정해도 늦지 않는다는 점입니다.

또 이밖에 CAT6a나 CAT7를 알아보시는 분들은, 굳이 말릴 것까진 없겠지만 자기만족이랄까 그런 걸 제외한다면 들이는 돈에 비해서 얻으실 수 있는 게 없다는 점은 알아두시는 게 좋지 않을까 합니다. 10기가비트 이더넷은 심지어 CAT5e로도 보통 4-50미터까지는 쓸 수 있고, 규격상 최소사양은 CAT6a 케이블이지만 10기가비트 이더넷부터는 사실 상 광케이블과 광장비가 훨씬 더 싸고 품질도 훨씬 더 좋기 때문에 구리 케이블을 이용한 10기가비트 장비들의 가격이 현실화되기 전에, 기존에 매설된 대부분의 CAT5가 지금 그렇듯이 지금 산 구리케이블이 먼저 노후화되고, 광케이블 솔루션이 더 저렴해질 수도 있기 때문에 우선은 재고해보시는 게 좋을 듯 합니다. 만약 노이즈로 인한 문제가 심각하다면 상위 카테고리 케이블보다는 FTP나 STP 케이블 같은 차폐 케이블을 알아보시는 쪽이 비용과 효용면에서 더 나을 것이라 생각됩니다.

비교적 장문의 글이지만 지금 막 네트워크 구축을 고려하고 계신 분들께 도움이 됐으면 하는 뜻에서 적어보았습니다. 덧글을 통해 살을 더 붙여나가보도록 하겠습니다. 읽어주셔서 감사합니다.

출처 : http://www.clien.net/cs2/bbs/board.php?bo_table=lecture&wr_id=152694

Mysql slow-query를 이용한 로그 분석

JAESOO — Mon, 16 Mar 2015 16:33:06 +0000

Mysql 프로세스가 CPU / 메모리 자원을 비정상적으로 많이 사용하여 서버의 load average가

급증 하거나, 웹페이지 접속시 로딩 속도가 현저히 지연될 경우가 있습니다.

이럴 때에는 쿼리가 처리 되는데 얼마나 시간이 소요 되는지 my.cnf에 slow-query-log를 남기게끔

설정하여 원인 분석을 할 수 있습니다.

[mysqld]

log-slow-queries = 로그 파일명

long_query_time = 쿼리 타임

ex)

# vi /etc/my.cnf

[mysqld]

log-slow-queries = /usr/local/mysql/var/mysql-slow.log

long_query_time = 3

위 내용은 쿼리 타임이 '3초'를 초과 하는 쿼리에 대해 /usr/local/mysql/var/mysql-slow.log 파일에 기록 한다는 뜻입니다.

my.cnf에 설정 및 mysql을 리스타트 한 뒤 운영 하다 보면 아래와 같이 slow-query-log가 남게 됩니다.

use iamroot;
select max(wr_comment) as max_comment from g4_write_ja
where wr_parent = '92' and wr_is_comment = 1;
# Time: 120809 16:08:15
# User@Host: iamroot[iamroot] @ []
# Query_time: 253 Lock_time: 0 Rows_sent: 1 Rows_examined: 419562
select max(wr_comment) as max_comment from g4_write_ja
where wr_parent = '92' and wr_is_comment = 1;
# Time: 120809 16:08:17
# User@Host: iamroot[iamroot] @ []
# Query_time: 94 Lock_time: 0 Rows_sent: 0 Rows_examined: 640675
use iamroot;
SELECT count(*) from comment where boardcode=1045552594 and boardidx=274;
# Time: 120809 16:08:23
# User@Host: iamroot[iamroot] @ []
# Query_time: 183 Lock_time: 0 Rows_sent: 1 Rows_examined: 268576

로그 내용 중 각 항목에 대한 설명은 아래와 같습니다.

Query_time : 쿼리 수행시간
Lock_time : 테이블 LOCK 이 걸린시간
Row_sent : 쿼리 처리 결과 ROW 수
Rows_examined : 쿼리 처리 대상의 ROW 수

출처 : http://faq.hostway.co.kr/Linux_DB/1325

Mysql 데몬 문제 해결 방안 (cpulimit)

JAESOO — Mon, 16 Mar 2015 16:23:23 +0000

Mysql 데몬 문제

joinc는 mysql(:12)을 이용해서 데이터 베이스를 관리한다. 그런데, 주기적으로 CPU 점유율을 100%가량 가까이 먹어버리는 경우가 발생한다. 추적해 본 결과 검색엔진(:12)기타 몇몇 로봇들이 사이트를 크롤링 하면서 이런 문제가 발생하는 것같았다. 명확하지는 않다. 몇몇 로봇은 아예 막아버리기도 했으나 근본적인 해결책은 되지 않았다.

그래서 mysql 데몬의 CPU 점유율을 제한해 버리기로 했다. 정상적인 요청이라면 CPU 자원을 10% 정도만 할당해도, 서비스를 하는데 문제 없을 것이라 생각되기 때문이다.

cpulimit

관련 프로그램이 있는지 구글(:12)신탁을 받기로 했다. 신탁의 결과물은 cpulimit 였다. 신탁을 받들어서 다운받았는데, 소스코드 하나와 make파일 하나만 포함한 아주 간단한 프로그램이였다. 간단해서 코드를 살펴봤다. proc(:12) 파일 시스템을 뒤져서 지정된 프로세스(:12)의 PID를 얻어오고 SIGSTOP와 SIGCONT 시그널(:12)을 이용해서 짧은 휴식을 주는 식으로 사용율을 조절했다. 괜찮은 방법 같았다.

사용 방법은 간단하다. 프로세스 이름이 mysqld인 프로세스의 CPU 점유율을 30%로 제한했다.

# cpulimit --exe mysqld --limit 30

PID단위로 제한할 수도 있다.

# cpulimit --pid 1111 --limit 30

사용 후기

cpulimit로 mysqld의 cpu 점유율을 제한한 후, 컴퓨팅 환경이 좋아진 것을 체감할 수 있을 정도로 효과가 있었다. 혹시 비슷한 문제로 고민하고 있다면 cpulimit를 추천한다. 간혹 단일 http 프로세스가 100%가 되는 경우도 있는데, 이것도 제한해볼까 생각중이다. 정상적이라면 50%를 넘어서는 안될 것이라고 생각되기 때문이다.

적당한 CPU 제한치는 프로세스 사용율 통계자료를 분석해서 설정해야 할 것으로 생각된다.

출처 : http://www.joinc.co.kr/modules/moniwiki/wiki.php/Site/System_management/Tool/cpulimit

리눅스 실시간으로 로그 보기 tail 명령어

JAESOO — Mon, 16 Mar 2015 13:39:41 +0000

어떤 파일에서 마지막 라인을 보고 싶을때 tail 명령을 쓴다..

[실시간으로 로그보기]

tail -f /opt/tomcat/log/output.log

[마지막 라인에서 50번째 라인까지 보기]

tail -50 [파일이름].txt

[옵션]

f : 파일의 마지막 10라인을 실시간으로 계속해서 출력

F : 파일 변동 시 실시간으로 보여주되 로그파일처럼 특정 시간이 지난 후 파일이 변하게 되면 새로운 파일을 오픈하여 보여줌

(다시 명령을 실행할 필요가 없음)

n : n 만큼의 라인을 출력

n+n : 마지막 줄이 아니라 첫번째 줄부터 시작해 n 번째 라인 이후부터 출력

--byte=n : n바이트 만큼의 내용을 출력

※ n은 숫자 ※

참참...

반대로 첫라인 보고 싶으면 head 명령을 쓰자..

출처 : http://blog.daum.net/bryanjo/7795945

mysql 5.5.x my.cnf 참고

JAESOO — Mon, 16 Mar 2015 13:31:50 +0000

참고

14.2.3.1. 테이블 당 테이블스페이스 사용하기

[mysqld] innodb_file_per_table = 1 # 20140719 datadir = /data/mysql socket = /var/lib/mysql/mysql.sock user=mysql init_connect=SET collation_connection = utf8_general_ci init_connect=SET NAMES utf8 character-set-server = utf8 collation-server = utf8_general_ci big-tables default-storage-engine = InnoDB # 기본 엔진설정 skip-host-cache skip-name-resolve # 역DNS 검색 비활성 skip-external-locking # 외부(TCP/IP) 잠금 비활성 max_connections = 500 table_cache = 256 wait_timeout = 50 ## General 로그를 사용하려면 아래 설정은 그대로 유지하고 ## MySQL 서버에 로그인한 후 “SET GLOBALgeneral_log=1″ 명령으로 활성화 general_log = 1 # 0=제네럴로그 비활성 general_log_file = /var/log/mysql/general_query.log # 제네럴로그 파일경로 log_slow_admin_statements # DDL쿼리도 슬로우 쿼리에 기록 slow-query-log = 1 # 슬로우 쿼리로그 활성화 long_query_time = 1 # 이 변수값보다 쿼리처리가 길게 걸린다면 에러로그에 기록 slow_query_log_file = /var/log/mysql/slow_query.log # 슬로우 쿼리 로그파일 경로 ## MySQL 스케줄러를 사용하려면 아래 event-scheduler 옵션을 ON으로 변경 #event-scheduler = OFF # 이벤트 비활성 sysdate-is-now # 함수 sysdate()와 now() 동일하게 처리 back_log = 100 # 동시접속시 대기시킬수있는 커넥션 갯수 max_connections = 300 # 최대 클라이언트 연결 갯수 max_connect_errors = 999999 thread_cache_size = 50 # 다쓴 쓰레드를 스레드풀에 저장할 갯수 table_open_cache = 400 # 각 쓰레드별 오픈할 테이블수 wait_timeout = 28800 # 커넥션 최대 대기시간(초) max_allowed_packet = 32M # 요청된 쿼리의 최대길이의 값 max_heap_table_size = 32M # MEMORY 테이블의 최대크기 tmp_table_size = 512K # 메모리 내의 임시테이블 크기 초과시 디스크에 저장 # 2012.09.13, xCode, ref http://dev.kthcorp.com/2011/07/01/mysql-innodb-storage-engine-benchmark/ #sort_buffer_size = 128K # 정렬에 필요한 버퍼의 크기 ORDER BY 또는 GROUP BY 연산 속도와 관련 #join_buffer_size = 128K # 조인이 테이블을 풀스캔 하기위해 사용하는 버퍼크기 #read_buffer_size = 128K # 테이블 스캔에 필요한 버퍼크기 #read_rnd_buffer_size = 128K # 디스크 검색을 피하기위한 랜덤 읽기 버퍼크기 sort_buffer_size = 512K # 정렬에 필요한 버퍼의 크기 ORDER BY 또는 GROUP BY 연산 속도와 관련 join_buffer_size = 6K # 조인이 테이블을 풀스캔 하기위해 사용하는 버퍼크기 read_buffer_size = 64K # 테이블 스캔에 필요한 버퍼크기 read_rnd_buffer_size = 256K # 디스크 검색을 피하기위한 랜덤 읽기 버퍼크기 query_cache_size = 32M # 쿼리 결과를 캐싱라기 위해 할당된 메모리 크기 query_cache_limit = 2M # 이 변수 값보다 큰 값은 캐싱이 안됨 group_concat_max_len = 1024 # GROUP_CONCAT()함수 사용시 컬럼값 최대크기 # 2012.09.13, xCode, 1 chip x 8 core thread_concurrency = 2 # 쓰레스 갯수 ## 마스터 MySQL 서버에서 “레코드 기반 복제”를 사용할 대는 READ-COMMIT 사용 가능 ## 복제에 참여하지 않는 MySQL 서버에서는 READ-COMMIT 사용 가능 ## 그 외에는 반드시 REPEATABLE-READ로 사용 transaction-isolation = REPEATABLE-READ # isolation 레벨 [READ UNCOMMITTED, READ COMMITTED, REPEATABLE READ, SERIALIZABLE] [innoDB] innodb_file_per_table = 1 # 테이블 단위로 테이블스페이스 할당, 활성시 확장자 .ibd 파일이 생성됨 innodb_data_home_dir = /data/mysql # innodb 홈디렉터리 경로 innodb_data_file_path = ibdata1:256M:autoextend # 파일명 : 초기용량 : 자동증가 : 최대사이즈 innodb_autoextend_increment = 100 #테이블 스페이스 자동 확장시 크기 innodb_log_group_home_dir = /data/mysql innodb_log_arch_dir = /data/mysql # 로그 디렉터리 정보 innodb_buffer_pool_size = 10G # 데이터와 인덱스를 캐시하기 위해 사용하는 메모리 버퍼크기 # innodb에서 사용할 메모리 양으로 전체 메모리의 50~80% 정도로 설정 innodb_additional_mem_pool_size = 16M # 데이터 디렉토리 정보와 내부 데이타 구조를 저장하는 메모리 풀의 크기 innodb_log_buffer_size = 16M # Redo 로그 버퍼크기 # 로그 버퍼 사이즈로 성능에 맞춰 로그를 기록하는 경우 크게 설정 innodb_log_file_size = 64M # 로그 파일 사이즈로 버퍼풀 사이즈의 25% 정도로 설정 innodb_flush_log_at_trx_commit = 2 # 커밋 로그 옵션으로 성능 최적화로 1분마다 저장되도록 2로 설정 # 1=트랜젝션 실행할때마다 로그 파일에 기록되고 디스크 플러시가 실행 innodb_support_xa = OFF # 트렌젝션 two-phase commit 지원, 디스크 플러시 횟수를 줄여 성능항상 # 분산데이터 기능 (2-PhaseCommit) # 2012.09.13, xCode, 1 chip x 8 core #innodb_thread_concurrency = 0 # InooDB내에 쓰레드 갯수, 변수 0은 쓰레드간 동시성 비활성화 innodb_lock_wait_timeout = 20 # 롤백이 진행되기 전에 LOCK을 대기하는 시간(초) innodb_force_recovery = 0 # 크래시 복구 모드 설정 innodb_flush_method = O_DSYNC # 성능을 위해 메모리에서 직접 액세스 하도록 설정 innodb_purge_threads = 1 innodb-read-io-threads = 2 innodb-write-io-threads = 2 innodb_thread_concurrency = 6 innodb-buffer-pool-instance = 3 # O_DIRECT=운영체제의 버퍼를 사용 않고 IO 실행, RAID 컨트롤러(캐시메모리 장착된)가 없거나 SAN 사용시 O_DIRECT를 사용 하지 않음 innodb_doublewrite = 0 # 이중 쓰기 버퍼 비활성 innodb_sync_spin_loops = 20 # 쓰레드가 지연되기 전에 (suspended) 풀어 주기 위해 InnoDB 뮤텍스 (mutex)를 기다리는 쓰레드의 대기 시간 innodb_table_locks = 1 # LOCK TABLES은 AUTOCOMMIT=0경우에, InnoDB로 하여금 내부적으로 테이블을 잠금 innodb_thread_sleep_delay = 1000 # InnoDB 큐를 조이닝 (joining)하기 전에 InnoDB 쓰레드가 일시 정지 (sleep)하는 시간 innodb_max_purge_lag = 0 # 퍼지 연산 (purge operation)이 래깅 (lagging)될 때 INSERT, UPDATE 및 DELETE 연산을 지연 시키는 방법을 제어, 디폴트값 0일시 지연 없음 innodb_commit_concurrency = 0 # 동시에 실행되는 쓰레드의 숫자. 이 값이 0이 되면 동시성 제어 (concurrency control)가 비활성화 innodb_concurrency_tickets = 500 # InnoDB에 동시에 들어갈 수 있는 쓰레드의 숫자는 innodb_thread_concurrency 변수로 알아볼 수가 있다. 여러 개의 쓰레드가 이미 컨커런시 한계에 도달하였다면, 하나의 쓰레드만이 큐에 들어갈 수 있다. 하나이 쓰레드가 InnoDB에 들어가게 되면, innodb_concurrency_tickets의 값과 일치하는 “자유 티켓”의 숫자가 주어지고, 쓰레드가 자신의 티켓을 사용하기 전 까지는 자유롭게 InnoDB에 들어가고 나올 수가 있다. 이런 후에는, 쓰레드는 다시금 일관성 검사를 하고 InnoDB에 다시 들어가려고 시도하게 된다 [mysql] default-character-set=utf8 show-warnings # 경고 발생시 메세지 자동 출력 prompt=\u@\h:\d\_\R:\m:\\s> # SQL 프롬프트 설정 #pager=”less -n -i -F -X -E” # 데이터 출력시 페이징처리 #no-auto-rehash # 자동 완성 기능 비활성화 #safe-updates # 데이터 변경 또는 삭제시 wherer구문 필수입력 [myisam] ## InnoDB를 사용하지 않고 MyISAM만 사용한다면 key_buffer_size를 4GB까지 설정 key_buffer_size = 32M # 인텍스 캐시 크기 bulk_insert_buffer_size = 32M # 대량 삽입에 사용된 트리 캐시의 크기, 쓰레드당 각각 할당됨 myisam_sort_buffer_size = 1M # 인덱스 정렬시 할당되는 버퍼의 크기 myisam_max_sort_file_size = 2G # 인덱스 재 생성시 사용할 임시 파일의 최대 크기 myisam_repair_threads = 1 # 정렬 복구시 사용될 쓰레드 갯수 myisam_recover # MyISAM 테이블을 열었을시 테이블 자동복구 ft_min_word_len = 3 # 하나의 FULLTEXT 인덱스에 포함 되는 단어의 최소 길이 값, # 변경후 REPAIR TABLE tbl_name QUICK 으로 재 구축해야함 [mysqld_safe] log-warnings = 1 # 에러로그에 경고메세지 기록 log-error=/var/log/mysqld.log # 에러로그 파일경로 pid-file=/var/run/mysqld/mysqld.pid # 프로세스 ID 파일경로 # 2012.09.13, xCode tcmalloc on [ndbd] connect-string="nodeid=2;host=localhost:1186" [ndb_mgm] connect-string="host=localhost:1186"

출처 : http://bluebreeze.co.kr/m/post/608

Mysql Slow query log 등록

JAESOO — Mon, 16 Mar 2015 11:25:18 +0000

대량의 데이터를 조회하거나

잘못된 인덱스 사용으로 인해 장시간 Mysql 프로세스가 물리는 현상이 발생 할 경우

어떤 쿼리문이 이런 현상을 야기 시켰느냐에 대한 분석 시

Slow Query 를 사용하시면 손 쉽게 부하가 증가되는 쿼리를 찾으실 수 있으실 것입니다.

<사용 방법>

1. mysql 환경 설정 파일인 my.cnf 파일에 아래 내용을 추가 하시면 됩니다.

[mysqld]
long_query_time=초제한(1~10)

log-slow-queries=로그파일명

ex)

[mysqld]

log-slow-queries = /temp/mysql-slow.log
long_query_time = 3

위의 의미는 쿼리타임이 3초를 초과하는 쿼리에 대해 /temp/mysql-slow.log 파일에 로그를 남기라는 의미 입니다.

2. mysql 구동시 적용하는 방법이 있습니다.

$ mysqld_safe --datadir=데이터디렉토리 --log-slow-queries[=file_name] &

< 로그 파일의 내용 >

# Time: 080218 13:25:06
# User@Host: XXXXX[xxxxx] @ localhost [127.0.0.1]
# Query_time: 8 Lock_time: 0 Rows_sent: 1 Rows_examined: 98767
use CrediMail;

SELECT count(*) FROM test

위의 양식으로 slow 쿼리가 남게 됩니다.

slow log 로 남은 쿼리들은 explain 을 사용하여 정상적인 index를 타고 있는지 체크 해 보는 방법으로

문제점을 찾아 가시면 될 것입니다.

ex) mysql>explain 문제시 되는 쿼리;

<참고>

Query_time : 쿼리 처리 시간

Lock_time : lock 이 걸린 횟수

Row_sent : 조회 결과 Row 수

Rows_examined : 조회 대상 Row 수

Reference URL

http://dev.mysql.com/doc/refman/5.0/en/slow-query-log.html

http://www.sitepoint.com/forums/showthread.php?t=397521

Setting my.cnf for log slow queries

MySQL을 운용하다보면 궁극적으로 봉착하는 문제가 바로 Slow queriy 다. 이 Slow query 야말로 모둔 query의 적이라 해도 과언이 아니라고 생각한다. MySQL에서는이 Slow query를 log로 기록할수 있게 되어있는데 이 설정이 꽤나 delicate 하다. 다음은 MySQL 5.0에서 동작하는 설정이다.

1. Check the gloval variables

in the mysql command prompt,

show global variables WHERE Variable_name LIKE ‘l%’;

+———————————+—————————+
| Variable_name | Value |
+———————————+—————————+
| language | /usr/share/mysql/english/ |
| large_files_support | ON |
| large_page_size | 0 |
| large_pages | OFF |
| license | GPL |
| local_infile | ON |
| locked_in_memory | OFF |
| log | OFF |
| log_bin | OFF |
| log_bin_trust_function_creators | OFF |
| log_error | |
| log_slave_updates | OFF |
| log_slow_queries | ON |
| log_warnings | 1 |
| long_query_time | 3 |
| low_priority_updates | OFF |
| lower_case_file_system | OFF |
| lower_case_table_names | 0 |
+———————————+—————————+

2. Configuration

[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
# Default to using old password format for compatibility with mysql 3.x
# clients (those using the mysqlclient10 compatibility package).
old_passwords=1

# added 1007/10/05
max_connections = 10000
table_cache = 256
wait_timeout = 900
max_connect_errors = 10000
key_buffer = 16M
sort_buffer = 1M
set-variable = long_query_time=3
log-slow-queries=/var/log/mysqld-slow.log

[mysql.server]
user=mysql
basedir=/var/lib

[mysqld_safe]
log-error=/var/log/mysqld.log
#log-slow-queries=/var/log/mysqld-slow.log
pid-file=/var/run/mysqld/mysqld.pid

# added 2007/10/05
#set-variable = long_query_time=3
#log-slow-queries=/var/log/mysqld-slow.log

Usage: mysqldumpslow [ OPTS... ] [ LOGS... ]

Parse and summarize the MySQL slow query log. Options are

--verbose verbose
--debug debug
--help write this text to standard output

-v verbose
-d debug
-s ORDER what to sort by (t, at, l, al, r, ar etc), 'at' is default
-r reverse the sort order (largest last instead of first)
-t NUM just show the top n queries
-a don't abstract all numbers to N and strings to 'S'
-n NUM abstract numbers with at least n digits within names
-g PATTERN grep: only consider stmts that include this string
-h HOSTNAME hostname of db server for *-slow.log filename (can be wildcard),
default is '*', i.e. match all
-i NAME name of server instance (if using mysql.server startup script)
-l don't subtract lock time from total time

Slow query filter

http://www.mysqlperformanceblog.com/files/utils/mysql_slow_log_filter

용도 : slow query log 에서 실행 시간이 일정 시간 이상이 되는 쿼리 와 일정 row 이상 access하는 쿼리만 filter 해 낼 수 있음

사용법

cat ‘slow query log’ msql_slow_log_filter -T timesec -R numrows ( T, R option은 단독으로 사용할 수 있음 )

Ex)

cat kidsmbbs1-slow.log | msql_slow_log_filter -R 400000 ( 400000 row 이상 access 하는 쿼리만 추출 )

SELECT /*!40001 SQL_NO_CACHE */ * FROM `tb_comment_121`;

# Time: 070307 5:01:11

# Query_time: 4 Lock_time: 0 Rows_sent: 31864 Rows_examined: 455198

select distinct code from tb_comment_121;

# Time: 070307 5:06:17

# Query_time: 5 Lock_time: 0 Rows_sent: 455596 Rows_examined: 455596

SELECT /*!40001 SQL_NO_CACHE */ * FROM `tb_comment_121`;

# Time: 070308 5:01:09

# Query_time: 4 Lock_time: 0 Rows_sent: 31905 Rows_examined: 455596

select distinct code from tb_comment_121;

cat kidsmbbs1-slow.log | msql_slow_log_filter -T 8 ( 8초 이상 걸리는 쿼리만 추출 )

SELECT /*!40001 SQL_NO_CACHE */ * FROM `tb_bbs_154`;

# Time: 070306 5:00:40

# Query_time: 8 Lock_time: 0 Rows_sent: 1 Rows_examined: 329849

select count(indexno) as su from tb_comment_160 where wdate>=1173020400 and wdate<=1173106800;

# Time: 070306 14:13:22

# Query_time: 15 Lock_time: 0 Rows_sent: 37014 Rows_examined: 37014

SELECT /*!40001 SQL_NO_CACHE */ * FROM `tb_bbs_154`;

# Time: 070307 5:00:40

# Query_time: 14 Lock_time: 0 Rows_sent: 37014 Rows_examined: 37014

SELECT /*!40001 SQL_NO_CACHE */ * FROM `tb_bbs_154`;

Aggregating slow query log

http://www.mysqlperformanceblog.com/files/utils/mysql_slow_log_parser

용도 : slow query log 에 있는 slow query에 대해서 aggregate 한 정보를 보여줌, 즉 실행 횟수, 평균 수행 시간, 총 수행 시간 , access 한 rows , 개인적으로 mysqldumpslow 보다 보기 좋은 것 같습니다.

### 4 Queries

### Total time: 12, Average time: 3

### Taking 3 , 3 , 3 , 3 seconds to complete

### Rows analyzed 144673, 150153, 185656 and 189447

SELECT /*!XXX SQL_NO_CACHE */ * FROM `tb_bbs_limit`;

SELECT /*!40001 SQL_NO_CACHE */ * FROM `tb_bbs_limit`;

### 2 Queries

### Total time: 10, Average time: 5

### Taking 5 , 5 seconds to complete

### Rows analyzed 78261 and 81439

use ykids_bbs;

SELECT /*!XXX SQL_NO_CACHE */ * FROM `tb_bbs_XXX`;

출처 : http://leepfe.tistory.com/163

MYSQL 성능 향상 정리

JAESOO — Mon, 16 Mar 2015 11:17:33 +0000

1.TABLE 관련

OPTIMIZE TABLE

table type이 myisam이나 bdb에서 사용하며 많은양의 데이터가 삭제되었거나 삽입되었을때 사용하면 속도향상에 좋습니다.

ex)optimaze table table_name;

2.QUERY 관련

JOIN

join이 subquery보다 빠르다.
join시 사용되는 컬럼은 동일한 column type과 길이를 가져야만 최적의 속도를 보장한다.

index설정

인덱스를 적절히 잡아줍니다.

필요한 컬럼만 select 한다.

select * 되어 있는부분을 필요할 필드만 가져옵니다.

processlist로 실행 쿼리를 mysql상태를 체크

cd /usr/local/mysql
./bin/mysqladmin -i3 processlist -ppassword

//3초에 한번씩 실행됩니다.

잘못된 query 발견

explain으로 질의과정 점검 몇번의 레코드를 검색하여 수행하는지 그리고 해당 컬럼이 index를 잘타는지 보고 쿼리를 수정합니다.

slow query log기능

slow query log를 걸어놓고 slow query time를 한 5초로 정해주시면 5초 이상 실행이 걸리는 쿼리는 모조리 로그에 남습니다.
그 query를 튜닝합니다.(explain이용)

query우선 설정

select 구문에는
select HIGH_PRIORITY id,name, ... from table_name ...

delete, insert, update 구문에는
delete LOW_PRIORITY from table_name ....

mysql 4.x 이상부터 지원!

query cache을 사용합니다.

int형과char형의 검색속도차이

int 가 char보다는 검색속도가 더 빠르다고 하지만 시스템구성과 환경마다 다릅니다.

3.하드웨어 관련

웹호스팅이 아닌 서버호스팅을 합니다.

평균 조회 레코드 50만건이상

조회 데이타가 50만건~100만건이면 DB서버와 웹서버를(이미지 서버등등) 나누어 분산처리(2-Tier)하며 조회 건수가 100만건 이상은 ORACLE같은 상용 DB로 교체해야 한다.

메모리를 증설 합니다.

1-2G 정도

하드디스크 스카시로 교체

e-ide보다 데이타 io(입/출력) 더 빠르다.(10000 rpm이상급)

출처 : http://www.zetswing.com/bbs/board.php?bo_table=MySQL_LEC&wr_id=47

MySQL Query Cache 사용법

JAESOO — Mon, 16 Mar 2015 09:52:14 +0000

MySQL에서는 반복되는 쿼리를 효율적으로 처리하기 위한 캐쉬가 존재한다.

바로 query cache인데 이는 까다로운 조건에 의해 동작하고 pruning 과정에서 meta 정보의 lock이 발생할 수 있어서 조심해서 사용해야 한다.

일단 동작하는 조건은 아래와 같다.

query cache에는 SQL문과 result set이 저장된다. 바로 이 cache에 저장되어 있는 SQL 문과 완전 동일(띄어쓰기까지..)하고 result set이 같은 쿼리가 수행될 때 query cache가 동작하고 result set을 바로 반환한다.

보통 개발자들은 위와 같은 조건을 간과하고 무작정 같은 쿼리를 수행하면 query cache를 쓰는 것으로 알고 사용한다.

그렇게 아무렇게나 쓰면 waiting query cache lock이라는 상태를 가진 프로세스로 인해 MySQL 서버가 hang이 걸릴 것이다…(오랜시간 고쳐지지 않고 있는 버그..)

이러한 상태에 빠지는 것을 방지하기 위해서는 꼭 query cache를 사용해야 하는 쿼리에만 사용하도록 옵션을 주어 사용할 수 있다.

query cache는 query_cache_type이라는 옵션을 통해 세 가지 타입을 제공한다.

OFF (0) ? Query cache를 사용하지 않는다.

ON (1) ? Query cache를 사용한다. (SQL_NO_CACHE 힌트를 사용하는 쿼리는 query cache를 사용하지 않는다.)

DEMAND (2) ? 선택한 쿼리만 query cache를 사용한다. (SQL_CACHE 힌트를 사용하는 쿼리는 query cache를 사용한다.)

위와 같은 설정은 my.cnf에서 설정 가능하고 세션 상에서도 설정이 가능하다.

# 세션에서 dynamic하게 설정하는 방법

mysql> set global query_cache_type = 1;

# my.cnf에 설정 (재시작 시 적용)

[mysqld]

query_cache_type = 1;

설정은 숫자로 설정을 하거나 alias를 통해 설정이 가능하다.

query cache를 OFF할 경우에도 query_cache_size만큼 메모리를 할당하므로 해당 설정값을 0으로 설정하는 것을 권고한다.

query cache를 사용할 경우에는 query_cache_size를 1024의 배수로 설정해야 한다. 다른 값으로 설정할 경우 반올림하여 적용된다.

구조상 최소한 40KB 이상으로 설정해야 하며 적은 값으로 설정할 경우 warning이 발생한다.

해당 값은 아래와 같이 설정한다.

# 세션에서 dynamic하게 설정하는 방법

mysql> set global query_cache_size = 16*1024*1024;

# my.cnf에 설정 (재시작 시 적용)

[mysqld]

query_cache_size = 16M;

출처 : http://www.soonpenge.com/operate/12507175

UPS 용량 계산

JAESOO — Tue, 10 Mar 2015 09:13:46 +0000

1. 용량 계산

a. 중대용량 UPS 용량 산정법

총 용량(VA)= 총 부하(사용기기 후면에 기록되어 있는 Watt의 총 합) / 0.8(일반적인 부하 측 역율) * 1.3(예비율)

※ 사용 가능한 UPS의 용량(VA) = 총 사용량 * A

b. 부하에 대한 예비율 및 사용 내구성 환산 수치

- 전산시스템에 사용하는 경우 1.5

- 공장자동화의 Main 전원에 사용하는 경우 1.6

- 비상 시 비상용 전등부하에 사용하는 경우 1.3

- 기타 무인 장비의 부하에 사용하는 경우 1.5

2. 정전 보상시간(UPS가 동작 후 Backup 시간)

a. 정전 보상시간 계산법(정확한 계산 불가)

= (UPS용량(VA)*K(상수))/(Battery 평균전압(DC전압)*0.9(보수율))

※ K 상수(정전 후 UPS가 Backup으로 동작하는 시간)

10분(0.7), 20분(0.92), 30분(1.15), 45분(1.45), 60분(1.77) 100분(2.15)

b. 계산 예

UPS 용량 : 10KVA 입력 220V, 출력 220V

DC 전압 : 220VDC

정전보상시간 : 30분

= (10000*1.15)/(220*0.9)

= 60(58.08)Ah 12V 18Cell(개)

출처 : http://blog.naver.com/geonhwan/30014777337

플웨즈(PlayWares) (PC, Display 전문)

JAESOO — Mon, 09 Mar 2015 10:43:16 +0000

플웨즈 (PC, Display 전문)

램타이밍 이야기 (CL, CAS Latency, RCD, RP, RAS)

JAESOO — Mon, 09 Mar 2015 10:41:18 +0000

램타이밍 / 램타 / 레이턴시.. 뭐 이런 용어들을 많이 들어보셨을 겁니다.

흔히 "램타이밍" 이란 용어와 "CL" 이란 값이 동격으로 쓰이는 경우가 많지만
사실 CL은 CAS Latency의 약자로, 여러가지 '램타이밍' 들 중 한가지입니다.
물론 CL 값이 램타이밍들 중 가장 성능에 영향을 많이 주긴 합니다.

오늘은 램타이밍의 종류와 역할에 대해 알아봅시다.

1. 램타이밍의 종류

흔히 메모리의 스펙을 표시할때 7-7-7-24 등으로 네 개의 숫자열을 표시하는 경우가 많습니다.
간혹 다른 경우도 있지만 대개는 CL - TRCD - TRP - TRAS의 네 가지를 나타냅니다.
각각의 이름은 다음의 약자를 나타냅니다.

CAS Latency: Column-Address Strobe Letancy
(T)RCD: (앞의 T는 시간을 뜻하는 변수 이름입니다.) Row-address to Column-address Delay
(T)RP: Row Precharge
(T)RAS: Row Active Time

각각의 램타이밍 항목은 한자리~두세자리 숫자로 나타내지는데, 해당 항목이 차지하는 클럭 사이클을 의미합니다.
즉 1000MHz 메모리의 클럭 사이클은 0.000000001초당 하나씩 왔다갔다 하는데,
이 메모리의 CL값이 10이라면 이 메모리는 CL을 수행하는 데 0.000000001 x 10초가 필요하단 뜻입니다.

2. CAS Latency

간단히 말해 메모리컨트롤러 <-> 메모리 사이의 응답시간입니다.
(한쪽이 데이터를 보낸 뒤 다른 한쪽으로부터 최초의 응답이 있기까지)
메모리는 마치 좌표평면처럼, row와 column으로 셀의 위치를 지정해 데이터를 저장하는데
CAS Latency는 이미 어떤 row/column에 저장할지 파악한 상황에서, 그 column의 데이터를 액세스하는 데 걸리는 시간입니다.
즉 모든 주소가 주어진 상황에서 "맞는 column을 찾아가서 첫번째 비트를 액세스하기까지 걸리는 시간" 으로 정의됩니다.

그렇다면 여기서 벌써 직관적으로 드는 의문이 있죠.
"CL만큼이나 맞는 column를 찾는 시간도 중요하겠네?"
그 시간은 바로......

3. TRCD

......TRCD가 바로 그 '맞는 column' 를 찾는 시간입니다.
즉 row/column 주소가 있을 때 메모리컨트롤러가 메모리를 액세스하는 데 걸리는 시간은 CL + TRCD가 되겠죠?
정확한 의미는 "하나의 row를 연 뒤, 그 row에 해당하는 column을 찾아 액세스하기까지 걸리는 시간" 입니다.
다시 말해 TRCD는 row 주소가 이미 주어졌고, 그 안에서 column 주소를 찾기까지의 시간인 거죠.

그렇다면 row 주소를 찾기까지의 시간은 뭘까요?

4. TRP

TRP가 바로 row 주소를 찾기까지의 시간이 됩니다.
정확히는 "row를 여는 명령어 (Precharge command) 가 주어진 때부터 row를 열기까지의 시간" 이 됩니다.
그렇다면 또 다시 궁금한 것이 생깁니다. "Precharge command는 얼마나 자주 내려오지?"

5. TRAS

바로 TRAS가 Precharge command의 주기입니다.

그럼 지금까지 배운 내용을 요약해 봅시다.
메모리컨트롤러가 데이터를 액세스하기 위해선 지금까지 언급한 램타이밍들이 거꾸로 등장합니다.

- 메모리컨트롤러가 메모리에 데이터를 쓰고/읽으려면 row/column 주소가 필요합니다.
- Row를 액세스하기 위해 메모리컨트롤러가 'row를 여는 명령어 (Precharge command)' 를 발행합니다.
     -----> 여기까지 걸리는 시간이 TRAS 입니다.
- Row를 열라는 명령이 떨어졌으니 문을 엽시다. 낑낑...
- Row가 열렸습니다!
     -----> 여기까지 걸리는 시간이 TRP 입니다.
- Row 안에 들어왔습니다.
- 이제 Column 주소를 찾아야 합니다. 두리번 두리번...
     -----> 여기까지 걸리는 시간이 TRCD 입니다.
- 맞는 Column 주소까지 찾았습니다. 이제 데이터를 써야/읽어야겠어요.
- 데이터를 썼/읽었습니다!
     -----> 여기까지 걸리는 시간이 CL 입니다.

즉 램타이밍의 요소들은 모두의 '합'에 관계되어 있기 때문에 어느 하나만 조여진다고 좋은 게 아닙니다.
다만 가장 잦은 빈도로 사용되는 CL / TRCD 등등 앞쪽에 위치한 값이 작을수록 더 유리하긴 합니다.
또한 Row 안에서 지지고 볶는 일들이 끝나기 전까진 Row 밖에서 열고 닫는걸 아무리 해봐야 별 소용이 없겠죠?
따라서 TRAS 값은 나머지 세 값을 합친 것과 대개 비슷한 값을 가져야 합니다. (더 작아도 별 소용이...)
예를 들어 CL-TRCD-TRP 값이 각각 5-5-5라면 이 메모리의 TRAS 값은 15가 되는 것이 적당하다는 거죠.

.
.
.
.
.

수강료는 추천 한개

출처 : http://www.playwares.com/xe/12434672

전력(Watt) 등급과, 전압-전류(VA) 등급의 차이점?

JAESOO — Wed, 04 Mar 2015 10:16:28 +0000

UPS 선택 시, 전력(Watt) 등급과, 전압-전류(VA) 등급의 차이점이 무엇인가요?

소비전력은 전압과 전류량의 곱으로 쉽게 계산이 가능하지만 UPS를 구축하시려는 상황이라면 그리 간단하지가 않습니다.

컴퓨팅 장비들의 사용 전기의 표시는 전력(W) 또는 전압-전류(VA) 단위로 표시됩니다. 전력(W)으로 표시된 장비는 실제 사용 전력량입니다. "피상 전력"이라고 하는 전압-전류(VA)는 장비에 적용되는 전압과 장비에서 실제 사용하는 전류를 곱한 값입니다.

전력(Watt) 등급과 전압-전류(VA) 등급은 각각 그 용도와 목적이 서로 다릅니다. 전력(Watt)는 설비에서 발생되거나 장비를 사용하는 것에서 발생되는 실제 사용전력을 전력회사로부터 구입하는 데 사용되고, 전압-전류(VA) 등급은 배선 및 회로 차단기의의 용량을 정하는데 사용됩니다.

백열 전구와 같은 일부 유형의 부하에 대한 VA와 전력(Watt) 등급은 동일합니다. 이와 반대로 컴퓨터 장비의 경우에는 전력(Watt) 등급과 전압-전류(VA) 등급이 크게 차이날 수 있습니다. 전압-전류(VA) 등급은 항상 전력(Wattt) 등급과 같거나 그보다 높습니다. 전압-전류(VA) 등급에 대한 전력(Watt) 등급의 비율을 나타내는 "역률"은 숫자값(예: 0.7) 또는 백분율(예: 70%)로 표시됩니다.

컴퓨터에 대한 전력(Watt) 등급은 전압-전류(VA) 등급과 다를 수 있음

컴퓨터를 포함한 모든 IT 장비는 전자식 스위칭 전원공급장치를 사용합니다. 컴퓨터의 스위칭 전원공급장치에는 기본적으로 1) 역률 보정 공급장치 또는 2) 축전기 입력 공급장치의 두 가지 유형이 있습니다. 그러나 장비를 검사해도 전원 공급의 유형을 구분할 수 없고 장비 사양에는 일반적으로 이 정보가 없습니다. 1990년대 중반에 소개된 역률 보정 공급장치(PFC 공급장치라고도 함)는 전력(Watt) 등급관 전압-전류(VA) 등급이 동일(0.99-1.0의 역률)하다는 특징이 있습니다. 반면 축전기 입력 공급장치는 전력(Watt) 등급이 전압-전류(VA) 등급의 0.55에서 0.75배(0.55-0.75의 역률)입니다.

대략 1996년 이후에 제조된 라우터, 스위치, 드라이브 배열 및 서버 같은 모든 대형 전산 장비는 전원 역률 보정 공급장치를 사용하며, 따라서 이러한 종류의 장비에 대한 역률은 1입니다.

PC, 소형 허브, PC용 주변 기기는 일반적으로 축전기 입력 공급장치를 사용하며, 이러한 종류의 장비에 대한 역률은 1보다 작고 보통 0.65 범위 내의 값이 사용됩니다. 1996년 이전에 제조된 대형 컴퓨터 장비는 주로 이러한 유형의 전원공급장치를 사용했으며 역률이 1보다 작은 것으로 나타났습니다.

UPS 전력 등급

UPS는 최대 전력(Watt) 등급과 최대 전압-전류(VA) 등급을 가집니다. UPS의 전력(Watt) 및 전압-전류(VA) 등급 이상의 부하를 연결하여 사용해서는 안됩니다.

소형 UPS 시스템의 경우 전력(Watt) 등급이 전압-전류(VA) 등급의 약 60%라는 것이 사실상 산업 표준이며, 이는 보통 일반 PC 부하의 역률입니다. 일부의 UPS 제조업체는 UPS의 VA 등급만 표시합니다. 컴퓨터 부하 조정용으로 설계된 소형 UPS에는 VA 등급만 있으며, 이 경우 전력(Watt) 등급은 표시된 VA 등급의 60% 정도로 보는 것이 적절합니다.

대형 UPS 시스템의 경우, 일반적으로 전력(Watt)을 기준으로 선정하여 구성하고 있으며, 이는 일반적인 부하의 전력(Watt)과 전압-전류(VA)의 등급이 비슷하며, 최근의 UPS도 전력(Watt)와 전압-전류(VA)가 동일하기 때문입니다. 대형 시스템 및 데이터 센터의 역률 문제에 대한 자세한 논의는 APC 백서 #26 "고조파 및 중립 과부하의 위험성"을 참조하십시오.

부하에 따른 UPS 용량 선정 시 문제가 발생할 수 있는 예

예 1: 일반적인 1000VA UPS가 있는 경우 - 사용자는 UPS를 사용하여 900W 히터에 전원을 공급하려고 합니다. 히터의 전력(Watt) 등급과 전압-전류(VA) 등급은 모두 900W이며 역률은 1입니다. 부하의 전압-전류(VA) 등급은 UPS의 전압-전류(VA)의 용량내에 해당하는 900VA지만 UPS는 이 부하에 전력을 공급할 수 가 없습니다. UPS의 전력(Watt)양은 1000VA의 60%인 600W가 될 가능성이 높고, 부하의 전력 사용량은 900W이므로 UPS의 최대 전력량을 초과하기 때문입니다.

예 2: 1000VA UPS가 있는 경우 - 사용자는 UPS를 사용하여 900VA 파일 서버에 전원을 공급하려 합니다. 파일 서버에는 전원 역률 보정 공급장치가 장착되어 있으며 따라서 900W의 전력 사용량과 900VA의 전압-전류(VA) 등급을 가집니다. 부하의 VA 용량이 UPS의 VA 용량의 범위 내의 값인 900VA이지만 UPS는 이 부하에 전력을 공급할 수 없습니다. UPS의 최대 사용 가능 전력량은 1000VA의 60% 또는 약 600W가 될 가능성이 높고, 부하의 용량은 900W이므로 UPS의 전력량을 초과하기 때문입니다.

부하에 따른 UPS 용량 선정 시 오류를 방지하는 방법

APC UPS 선택기를 사용하면(www.apc.com 참조) 지정된 장비를 기준으로 부하의 전력 값을 계산할 수 있므로 부하에 따른 UPS 용량 선정 시 오류를 방지할 수 있어 UPS 최대 전력 또는 전압-전류(VA) 의 용량을 초과하지도 않을 수 있습니다.

장비 네임플레이트에 적혀 있는 정격 용량은 종종 VA로 표시되어 있기 때문에 정격전력량은 알기가 어렵습니다. 만약 부하에 적혀있는 VA 용량을 기준으로 부하를 선정하여 시스템을 구성하면 실제 UPS의 최대 전력량을 초과할 수도 있습니다.

부하의 VA 용량을 UPS VA 용량의 60% 이하로 조정하면 UPS의 최대 사용 가능 전력 용량을 초과하지 않습니다. 결과적으로 부하의 정격 전력량을 확실하게 모를 경우 가장 안전한 방법은 부하 네임플레이트에 적혀 있는 VA 용량을 UPS 용량의 60% 이하로 유지하는 것입니다.

이러한 고전적인 부하에 따른 UPS 선정을 하게 되면 예상보다 방전타임 길어지게 됩니다. 시스템의 최적화 및 정확한 방전타임 필요하면 www.apc.com에서 APC UPS 선택기를 사용하십시오.

결론

컴퓨터 부하의 전력 소모에 대한 정확한 정보 없이 UPS를 구성하다 보면 UPS가 과부하가 될 수 있습니다. 그러므로 컴퓨터 장비의 네임플레이트 사용 전력용량 비교하여 UPS를 약간 높게 설정하여 구성한다면 시스템이 적절하게 작동하도록 보장할 수 있습니다. 오버사이징은 추가적인 UPS 백업 시간을 제공한다는 또 다른 장점이 있습니다

출처 : http://upsshop.co.kr/board/board.html?code=kmpower_board3&page=4&type=v&num1=999988&num2=00000&lock=N

NAS에 데스크탑 HDD 대신 'NAS HDD' 써야 한다? 3개월 동안 써 보니...

JAESOO — Wed, 04 Mar 2015 10:00:41 +0000

케이벤치는 'NAS에 꼭 NAS HDD를 써야 할까?' 라는 주제로 3개월에 걸쳐 테스트를 진행한바 있다.

대개는 NAS에 장착할 HDD를 고려치 않고서 써 왔기에 데스크탑 PC에서 사용해 왔던 HDD를 장착해 쓰는 경우가 많았다. NAS를 위한 HDD가 있다는 것이 일반인들에게 잘 알려져 있지 않았기 때문이다.

그래서 케이벤치는 지난 3개월 간 데스크탑 HDD와 NAS HDD를 대상으로 진행해 온 테스트 결과를 정리해 보고자 한다. 이번 기사는 NAS 기획을 다루는 최종편으로써, NAS에 왜 NAS HDD를 써야하는 것인지를 확인해 볼 수 있을 것이다.

■ 오랜 기간 사용해도 크게 줄지 않는 성능

▲ 테스트 초기와 11주 차에서 확인한 성능. NAS HDD가 데스크탑 HDD를 압도했다.

본래 NAS HDD는 우리가 흔히 사용하는 일반 데스크탑 HDD처럼 성능을 위한 셋업이 돼 있지 않다. 오랜 기간을 두고 사용하는 제품인 만큼 안정성과 신뢰성을 모토로 하고 있기 때문에 단순히 제원상으로 두 HDD의 성능을 비교한다면 NAS HDD가 불리한 것이 사실이다.

그렇지만 케이벤치가 3개월 동안 이를 테스트한 제원상으로 비교한 것과 달랐다. 처음 1주일 동안은 표기된 제원대로 데스크탑 HDD가 우위의 성능을 냈지만 테스트 막바지에 이른 11주 차에선 이 결과가 역전됐다. NAS HDD가 오히려 데스크탑 HDD를 성능으로써 압도한 것이다.

이런 차이가 나타난 것은 근본적으로 하드웨어적인 설정의 차이에서 엿볼 수 있다. 데스크탑 HDD는 일시적인 부하에서 빠른 성능을 내도록 설계돼 있지만, NAS HDD는 일정한 상태를 유지할 수 있도록 만들어져 있다는 것이다.

예를 들면, NAS에 저장해 둔 영상을 외부에서 실시간으로 보고자 할 때 지속적인 스트리밍이 이뤄지는데 이 부분에서 상태 변화의 폭이 크지 않은 NAS HDD가 유리하다 할 수 있다. 오직 한 사람만이 이용하는 데스크탑 PC의 경우라면 필요할 때마다 빠른 성능을 요하는 데스크탑 HDD가 나을 수 있으나, NAS는 환경에 따라 여러 사람이 이용할 수 있기에 안정성과 신뢰성이 강조될 수 밖에 없다.

물론 테스트 과정상에서 혹독한 테스트가 이뤄졌기 때문에 성능 저하가 조금은 과장된 부분이 있을 수도 있지만 동일한 조건 내에서 진행된 것이기에 큰 편차는 없을 것으로 사료된다.

■ 데스크탑 HDD보다 빈도가 적은 진동

▲ 진동 테스트 영상. 두 대의 NAS에서 그려지는 그래프 형상을 주목해 보자.

NAS HDD나 일반 데스크탑 HDD는 데이터를 기록되는 둥근 모양의 플래터를 고속으로 회전시키며 동작하는 기본적인 구조적 특성을 가진다. 이에 따라 장착된 HDD가 많을수록 진동이 점차 심화되는 현상을 겪을 수 있는데 이 부분에서도 NAS HDD는 데스크탑 HDD보다 나은 장점을 가진다 할 수 있다.

이는 NAS HDD와 일반 데스크탑 HDD에서 1분 당 플래터가 회전하는 속도를 비교해 보면 어느 정도 이해할 수 있다. 데스크탑 HDD의 경우 1분 당 최대 7,200 회(7,200 Rpm) 수준이지만, NAS HDD는 이보다 상대적으로 낮은 1분 당 최대 5,900 회(5,900 Rpm) 수즌으로 플래터가 돌아간다.

플래터 회전 수가 적다는 것은 그만큼 진동을 유발하는 빈도가 적을 수 있음을 의미한다. 이 수치로 미루어 보면 NAS HDD는 데스크탑 HDD 보다 진동이 적을 가능성이 크다는 점을 짐작할 수 있다.

케이벤치는 이 차이를 확인하기 위해 진동의 세기를 관찰할 수 있는 어플리케이션을 스마트폰에 설치해 이를 지켜봤다. 그 결과, NAS HDD는 데스크탑 HDD가 장착된 NAS보다 진동이 덜하다는 점을 육안으로 확인할 수 있었다.

수치적으로 분석해 본다면 애매한 차이가 아닌가 싶을수도 있지만, 동작 중인 NAS 위에 손바닥을 대 보면 어느 쪽이 NAS HDD가 설치된 제품인지를 충분히 구분할 수 있는 수준이다.

■ 상대적으로 낮은 동작 온도를 유지해

이미 플래터 회전 수와 진동의 세기에서 예상할 수 있었겠지만, NAS HDD는 데스크탑 HDD보다 동작 시 온도가 상대적으로 낮은 축에 속한다.

제원상으로는 동작 시 드라이브 케이스 최고 온도가 데스크탑 HDD에선 섭씨 60 도, NAS HDD로는 섭씨 70도로 표기돼, 의미 해석이 어려운 점이 있기는 했다. 해당 온도까지 동작을 보장한다는 것인지, 아니면 동작 시 최대 온도가 이렇다는 것인지 두 가지 의미로 해석이 가능할 수 있는 부분이기 떄문이었다.

케이벤치는 이를 확인코자, 동작 중이던 두 대의 NAS의 통풍구를 테이프로 모두 가리고 수건을 올리는 등 변수를 통제하기 위한 장치를 추가했다. 인위적으로 통풍이 제대로 되지 않는 환경을 설정한 것이라 볼 수 있다.

이 결과에서 NAS HDD는 데스크탑 HDD보다 동작 온도가 낮다는 사실을 확인할 수 있었다. 최고 온도로 기록된 평균 온도를 비교하면 데스크탑 HDD는 섭씨 59.3 도, NAS HDD는 섭씨 53.8 도를 가리켰다. 약 두 시간 간격으로 확인한 온도 분포서도 최대 10 도 이내의 차이를 내는 등의 결과를 나타냈다.

당시 테스트를 진행한 와중에는 데스크탑 HDD를 장착한 NAS가 과열로 전원이 꺼져 버리는 현상이 나타난데 반해 NAS HDD를 장착한 쪽은 이상이 있다고 할 만한 변화를 관찰할 수 없었다. 이는 NAS HDD가 데스크탑 HDD 보다 발열량이 적었기에 극한의 환경서도 상태 유지가 가능했던 것이라 볼 수 있다.

■ 적은 소비 전력으로 장시간 사용 시 유리

▲ 아이들링 시 소비 전력. 미세하지만 NAS HDD가 소모하는 전력의 양이 더 적었다.

소비 전력도 마찬가지다. 겉으론 부피가 같은 저장 장치이지만 성능을 지향한 제품일수록 소비 전력은 필연적으로 높아질 수 밖에 없다.

이는 케이벤치가 테스트하기 전에 확인했던 NAS HDD와 데스크탑 HDD 간의 제원표에서도 간단히 확인할 수 있던 내용이기도 했다. 상태 변화에 따라 NAS HDD는 데스크탑 HDD보다 0.25 ~ 2.5 W 정도로 소모하는 전력의 양이 적다는 것이다.

실제 같은 종류의 HDD 네 장이 장착된 두 대의 NAS를 대상으로 소비 전력을 측정해 보니, 절전 모드 시 2 W, 아이들링 시엔 4 W 정도 차이가 발생함을 확인할 수 있었다. 예상치 보다는 소비 전력 차이가 적게 나오긴 했지만, NAS 자체의 소모 전력이 반영돼서 나온 수치임을 고려하면 소비 전력을 비교하고 판단하는데선 크게 무리가 없는 수치다.

HDD를 사용하는 단위의 수가 늘어날수록 차이가 커질 가능성이 농후하기에 다량의 NAS를 운용하는 사용자 입장에선 이 소비 전력의 차이를 고려해 보는 것이 필요하다 하겠다.

■ 전원 차단 후 재 공급 시 데이터 복구에 원활

이례적인 일이라 할 수 있지만 NAS를 운용하다 보면 불가피하게 전원 공급이 갑작스레 중단되는 일을 경험할 수 있다. 이 경우 안정성을 위한 차원에서 유실된 데이터가 없는지 확인하는 것이 필요하다 할 수 있다.

당시 설치한 두 대의 NAS는 모두 데이터 보호 기능을 추가한 RAID 5로 설정해 놓고서 서버 부하 테스트를 진행했기 떄문에 도중에 전원 공급이 차단되더라도 재부팅 시 데이터 복구가 자동적으로 실행되어야 하는 것이 일반적인 상황이라 할 수 있다.

▲ NAS HDD는 패리티 검사가 실시됐지만, 데스크탑 HDD가 장착된 쪽은 그렇지 못했다.

케이벤치는 이를 염두하고 테스트를 진행했는데, NAS HDD를 장착한 쪽은 패리티 검사를 통한 자동 복구가 진행됐고 데스크탑 HDD는 그렇지 못했다. 이후 한 두 번 정도 상황을 반복해 테스트 해도 자동 복구가 실행되는 것은 NAS HDD를 장착한 NAS 뿐이었다.

물론 테스트 초기에는 데스크탑 HDD를 장착한 쪽에서도 자동 복구 기능이 실행되는 모습을 지켜볼 수 있었지만 오랜 기간 테스트를 거친 이후엔 자동 복구 기능이 활성화되지 않았다.

이는 NAS HDD가 데스크탑 HDD보다 사용 중 신뢰성이 높다고 판단할 수 있는 부분이라 하겠다.

■ 안정성과 신뢰성 위한다면 NAS HDD가 필요

그러므로 NAS를 위한 HDD를 선택하려 한다면 NAS HDD가 알맞다 할 수 있다.

데스크탑 HDD는 데스크탑 PC에 적합한 용도로 만들어진 HDD이기에 오랜 기간을 두고 NAS를 운용하는 환경에는 어울리지 않는다. 부하 테스트로 성능 저하의 폭이 과장됐을 수도 있다는 점을 간과할 수는 없지만 같은 조건 하에서 진행된 결과라는 점을 고려하면 NAS의 안정성이 우수하다는 점을 확인할 수 있다.

이는 진동과 온도, 소비 전력 부문에서도 확인할 수 있는 내용이다. 데스크탑 HDD보다 적은 진동에 낮은 온도, 소모하는 전력의 양 또한 적다. 이러한 결과는 NAS에 NAS HDD를 사용함으로써 얻을 수 있는 부가적인 장점이라 할 수 있다. 사용 중 전원 공급이 차단되는 상황에서도 자동 복구가 실시돼 데이터 유실의 위험도 상대적으로 적다.

그렇기에 NAS를 운용할 사용자라면 데스크탑 PC에서 사용하는 일반 HDD가 아닌, NAS HDD를 사용하는 편이 낫다고 할 수 있다.

물론 가격적인 부분에선 NAS HDD가 데스크탑 HDD보다 비교적 높은 수준에 위치해 있어 부담이 될 수도 있지만, NAS에 사용할 HDD라면 단순히 가격적인 이득보다는 안정성과 신뢰성의 비중을 더 크게 보고 선택해야 하는 것이 맞다.

이런 의미로 NAS는 가능하다면 NAS HDD를 사용하는 것이 좋다고 정리할 수 있다.

출처 : http://www.kbench.com/?q=node/132042

NAS용 6TB 하드디스크 3종 비교 테스트

JAESOO — Wed, 04 Mar 2015 09:48:59 +0000

웨스턴 디지털 레드 6TB (WDC WD60EFRX-68MYMN0)

시게이트 엔터프라이즈 캐퍼시티 3.5 HDD v4 6TB (ST6000NM0024-1HT17Z)

HGST 울트라스타 He6 6TB (HUS726060ALA640)

의 비교 벤치마크입니다.

우선 하드디스크 성능의 테스트 환경입니다.

이건 NAS 성능의 테스트 환경입니다.

테스트에 쓴 QNAP의 TS-EC1279U-SAS-RP NAS입니다.

웨스턴 디지털 레드 6TB. 1.2TB 플래터, 가격 299달러.

시게이트 6TB v4 엔터프라이즈. 가격 450~560달러.

히타치의 6TB 하드디스크는 헬륨을 채운 것이 특징입니다.

3개 하드디스크의 스펙 비교.

먼저 HD 튠 프로를 봅시다.

웨스턴 디지털

시게이트

HGST

3개 하드디스크의 지원 기능들입니다.

먼저 HD 튠 프로의 읽기 성능입니다.

다음은 쓰기 성능입니다.

랜덤 읽기 성능입니다.

랜덤 쓰기 성능입니다.

시크 타임 읽기 테스트입니다.

시크 타임 쓰기 테스트입니다.

DAS와 NAS 환경입니다.

NAS 환경에선 레이드 5 구성을 씁니다. 네트워크는 802.3ad LACP.

클라이언트 단의 테스트입니다. IO-Meter에서 25개 가상 머신이 동시에 CIFS를 통해 공유하는 대역폭과 응답 시간을 측정했습니다.

먼저 100% 읽기.

다음은 50% 읽기

이번엔 70% 읽기

65% 읽기

위 테스트에서 회전 속도가 낮은 웨스턴 디지털 레드가 성능이 떨어집니다. 하지만 가격을 생각해 보세요. 엔터프라이즈 하드디스크와 비교할 가격이 아닙니다.

QNAP NAS에서 3개의 하드디스크로 레이드 5를 구성하는데 레드 하드디스크가 I/O 에러를 뱉어냈습니다. 테스트는 통과했지만 레이드를 묵을 순 없었다고. 이건 그냥 참고만 해 두세요.

마지막으로 요건 레이드 5 볼륨 재동기에 걸리는 시간.

웨스턴 디지털의 레드는 낮은 회전 속도로 전력 사용량이 낮습니다. 시게이트의 엔터프라이즈는 성능이 괜찮구요. HGST는 TCO 단가가 낮으며 장기간 사용 성능/전력 사용량에 알맞습니다.

출처 : http://gigglehd.com/zbxe/11703794

출처 : http://www.anandtech.com/show/8263/6-tb-nas-drives-wd-red-seagate-ec-hgst-he

NAS의 HDD 베이를 비워두지 마세요.

JAESOO — Wed, 04 Mar 2015 09:13:25 +0000

결론 :

"하드 하나의 투자비용 시점을 미래로 연기하는 것은
실제 이득이 아니라 손실입니다,,,,,"

NAS도입을 검토하신다면 기능과 성능도 중요하지만 용량을 합리적으로 정해야합니다.
기능은 용도과 관련되고 성능은 사용자 수 및 작업내용(방식)과 관계됩니다.
하지만 용량은 언제 다시 교체해야하는지와 밀접합니다.

NAS는 HDD를 장착하면 간단히 용량 만들 수 있을 것 같지만
레이드 때문에 한번 만들면 유연성이 떨어집니다.

이슈

1. 레이드 상태에서 Fail HDD를 같은 모델의 HDD로 교체
2. 레이드 상태에서 Fail HDD를 다른 모델의 HDD로 교체
3. 레이드 상태에서 같은 모델의 HDD추가
4. 레이드 상태에서 다른 모델의 HDD추가
5. 레이드 상태에서 수명 주기로 인하여 같은 모델 HDD로 모두 교체
6. 레이드 상태에서 용량 부족으로 고용량 HDD로 모두 교체

위 6가지 이슈가 모두 신경쓰이는 내용들입니다.

1 의 경우는 미리 보유한 Spare HDD가 있다면
그닥 어렵지 않게 교체하여 레이드를 정상화하고 데이터를 유지할 수 있습니다.
일부제품은 핫스왑 오토리빌딩을 지원하므로 HDD Smart정보와
불량블록 스캔을 한 다음 Fail이 확인되면 그냥 교체하면 자동처리됩니다.

그러나 여분 HDD가 없거나 새로 구할 수 없다면

2의 상황
다른 모델이라도 사용하여야하므로 상황이 불리합니다.

HDD후면에 보면 LBA가 있습니다. 섹터의 갯수를 의미하며 2테라하드라 하더라도

이것이 제조사마다 달랐는데 표준화되었습니다.

LBA가 같으면 일단 레이드는 묶여집니다.

다만 안정성의 수준은 상대적인 차이를 감안하는 것이 좋습니다.

같은 회사, 같은 용량, 같은 시리즈 내로 좁혀보는 것이 좋고 가변은 금물입니다.

3은 초기에 비용을 절감하기 위하여 HDD를 장착할 수 있는 bay를 남겨둔 경우입니다.

같은 HDD가 있다면 고급모델에서는 HDD추가와 용량확장을

어렵지 않게 레이드관리도구에서 처리할 수 있습니다.

4는 같은 하드가 없으므로 2의 상황과 마찬가지의 위험헷지와 감수를 하여야합니다.

5는 하드를 하나씩 교체하면서 레이드 리빌딩과 용량 확장을 하여야하는 경우입니다.

6의 경우도 비슷하지만

보다 큰 용량의 하드로 교체하는 것이므로 기존 하드와 같은 하드일 수가 없습니다.

HDD가 용량만 다른 것 같지만 HDD에 내장된 펌웨어도 다릅니다.

1테라하드들로 묶여진 레이드에서 2테라하드로 하나 교체핟여 레이드 빌딩을 하면

2테라중 1테라만 묶입니다. 이런식으로 전체를 교체한 다음 용량을 다시 확장하는 순서입니다.

그러므로 용량이 달라도 레이드는 묶여진다는 의미입니다.

이때 하드 갯수+1만큼의 레이드빌딩을 반복하여야하므로 장시간 소요되며

작업 중 위험성도 높아집니다.

백업된 자료가 있다면 차라리 일괄 교체하고 데이터를 다시 부어넣는 것이 유리합니다.

결국 HDD를 추가하거나 나중에 고용량으로 교체하거나

수명 주기로 인하여 일괄 교체하거나 모두 같은 하드가 없다면

신경을 거슬리는 작업이되며 하드 갯수가 많으면 엄청난 수고와 위험이 동반됩니다.

그렇다면 이러한 번거로움과 스트레스를 줄이는 최선의 방법은 무엇인가 미리 감안하여야합니다.

나중에 하드 추가하기 위하여 베이를 비워두지 마세요

   데이터 차는 속도에 준하여 베이를 모두 채울만큼 쌓일려면 3년 이상걸리는 경우라면

   NAS를 잘 못 선택하신 것입니다. 3년이면 기존 하드도 모두 교체하여야할 것이므로,,

3년 후에 같은 하드를 구할 수도 없고

   두배 큰 용량의 하드도 같은 가격으로 살 수 있을 것이고

   그러므로 비어있는 베이를 사용할 일이 없습니다.

   나중에 하드 가격이 인하될 것을 고려한다면

   비어 있는 베이는 아주 많아야하고 데이터는 신속히 증가하는 경우에만 약간의 이득이 있습니다.

   즉 인하 속도는 실제 그리 빠르지 않으며

   하드 추가하면서 감수할 스트레스와 만약 같은 하드를 구할 수 없을지도 모른다는

   것을 감안하면 바람직하지 않습니다.

   2테라 하드 하나 16만원선인데

   16만원 투자시점을 1년 늦춰도 결국 8만원은 들어갈 것이므로

   계산상으로 8만원의 투자시점을 1년 늦추는 효과가 고작입니다.

   대신에 HDD수급불안, 레이드 리빌딩 위험을 감수해야합니다.

   결론적으로 3년 정도 계산하여 적정 용량을 산출하시고

   그에 맞는 베이수와 HDD를 장착하여 처음부터 구성하는 것이 정답이며

   가능한 한개정도의 여유하드는 보유하는 것이 옳습니다.

   일반 저가하드는 3년이면 수명이 다한다고 가정하는 것이 좋고

   용량이 부족해지면 일괄 교체가 좋습니다.

   3년 후면 NAS값도 더 저렴해질 것이고

   HDD가격도 더 사게 더 큰 용량을 구할 수 있을 것이므로

   3년 이상 사용할 것을 가정하여

   HDD용량, NAS의 규모를 선택하시는 것은 비용효율이 아니라

   발목을 잡히는 꼴이 됩니다.

   10년 생각하고 10테라 해달라는 분들이 참 안타까운 케이스입니다.

   10년 가는 HDD도 없고 그 상이 교체할 하드도 못구하고 NAS도 못버팁니다..^^

   3년 주기로 가시되

   2차 백업이 있다면 일괄 교체가 용이하고 없다면 매우 염려스런 상황이 됩니다.

   용량이 크지 않다면 다른 스토리지에 백업하고 일괄작업하면 되겠지만

   용량이 클 수록 반드시 2차 백업을 하는 것이 좋습니다.

   3년 후에 NAS를 새로 도입하고 기존 장비를 백업으로 사용할 수도 있겠습니다.

   계획기간은 3년이 적당하며 필요용량은 처음에 모두 구성하는 것이

   용량관리, HDD수명관리, NAS수명관리에도 유리합니다.

   너무 큰거 비싼거 사두면 아까워서 NAS가 가격이 내려가도 나중에

   더 저렴하게 더 좋을 것으로 교체를 못하는 불상사가 발생합니다.,,,,

출처 : http://egloos.zum.com/nascafe/v/2296839

SAS/SATA 지원 레이드 카드에 하드 연결 케이블

JAESOO — Wed, 25 Feb 2015 10:48:41 +0000

FOXBI 15-02-15 02:57

저는 조금 다른 정보를 드리겠습니다. 얼마전 저도 경험해서 알게된거네요..

SAS커넥터 모양이 달라서 그렇지 데이터 케이블과 전원 케이블의 단자부분 끝을 잘라내서

연결하면 사용 가능은합니다. 물론 애꿎은 케이블을 망가뜨려야 하는 단점이 있고 고정이 잘 안되는

단점이 있기는 하지만...

제대로 사용하시려면 조병철님 말씀대로 전원부가 같이 되었는 케이블을 사용하시면 됩니다.

좀 정리해서 정확히 얘기하자면 케이블 지원미지원보다는 인터페이스의 지원 미지원으로

따지는 것이 정확합니다.

종류 ; SAS Interface(RAID Card...)
지원 : SAS Disk(O), SATA Disk(O)

종류 : SATA Interface(일반 PC 보드 내장 커넥터)
지원 : SAS Disk(X), SATA Disk(O)

종류 : SAS Cable
지원 : SAS Disk(O), SATA Disk(O)

종류 : SATA Cable
지원 : SAS Disk(△), SATA Disk(O)
테이터 케이블 단자와 전원 케이블 단자의 끝부분을 잘라내면 사용가능

출처 : http://2cpu.co.kr/bbs/board.php?bo_table=QnA&wr_id=455761

새 술은 새 부대에? SATA3 케이블의 허와 실

JAESOO — Wed, 25 Feb 2015 10:46:09 +0000

새 술은 새 부대에? SATA3 케이블의 허와 실

1. 처음	2. SATA3 하드디스크, 케이블에 영향 받을까?
3. SATA3 SSD에 SATA2 케이블을 사용하면	4. 케이블 버전보다 내실이 중요

새 술은 새 부대에, SATA3 장치에는 SATA3 케이블을?

새로운 아키텍처의 CPU나 메인보드 칩셋 발표시 사용자들은 성능과 가격은 물론 하위 호환성에 촉각을 곧두 세우게 된다. 자금력이 풍부하다면야 호환성 따질 필요 없이 고성능 신제품으로 망설임 없이 교환하면 되겠지만, 대부분의 사용자들은 한정된 예산 안에서 구매를 결정해야 하기 때문에 호환성 부분에 민감하게 된다.

인텔 4시리즈 칩셋에서 5시리즈 칩셋으로 바뀌면서 소켓, 메모리 등 많은 것이 바뀌었다

이런 하위 호환성은 CPU나 메인보드 뿐만 아니라, 메모리, 그래픽 카드와 같은 주요 PC 컴포넌트는 물론 USB나 SATA와 같은 저장장치 인터페이스도 마찬가진데, 단순 하드웨어적인 역할을 하는 주요 컴포넌트와 달리, 저장장치와 관련된 USB나 SATA 인터페이스의 경우 그 안에 보관된 사용자 데이터에 관련해 인터페이스 변화에 보다 민감할 수 있다.

USB 2.0과 USB 3.0, 하위 호환은 되지만 USB 3.0을 제대로 쓰기 위해선 별도 케이블 필요

다행이 최신 USB 3.0 인터페이스의 경우 데이터 교환이라는 면에서는 USB 2.0/1.1과 하위 호환이 가능하지만, 확장된 대역폭을 비롯해 하위 버전보다 발전한 기능의 사용을 위해서는 USB 3.0 인터페이스 못지 않게 USB 3.0 전용 케이블이 필요하다.

반면, SATA 6Gbps(이하 SATA3)의 경우 기존 SATA 3Gbps(이하 SATA2)나 SATA 1.5Gbps(이하 SATA1)와 디바이스의 인터페이스는 물론, 데이터 케이블과 전원 케이블 역시 동일하여 하위 호환은 완벽하지만, EIDE로 더 잘 알려진 PATA 케이블에서의 변화나 USB 2.0에서 USB 3.0 케이블의 변화와 같이 도통 그 차이점을 알기 어렵다.

케이블에 적힌 표시가 없다면, 모양만으로 각 세대를 구별할 수 있을까?

게다가, SATA3를 위한 별도의 케이블은 필요없다는 SATA-IO(International Organization)의 공식 언급과 달리, 일부 메인보드 제조사측에서는 새로운 SATA3 장치의 성능을 제대로 활용하기 위해서는 SATA3 전용 케이블이 필요하다는 마케팅을 펼치고 있어, SATA3로 등장한 SSD와 하드디스크를 위해 시중에 판매중인 SATA3 케이블을 돈 주고 사야할지 고민도 될 것이다.

이에 보드나라에서는 실제, SATA3 SSD와 하드디스크, SATA3 케이블과 SATA2 케이블을 조합을 테스트해, SATA3 SSD와 하드디스크의 성능을 위해 SATA3 케이블이 실제로 필요한지 확인해 보도록 하겠다.

2. SATA3 하드디스크, 케이블에 영향 받을까?

보드나라에서는 앞서 SATA3 대중화에 대한 기사를 통해(SATA 6Gbps 대중화, 어디까지 왔나?) SATA3 하드디스크의 성능에 대해 살펴본 적이 있는데, 당시에는 별도의 SATA3 컨트롤러를 사용한 메인보드와 SATA3 케이블을 사용했었다.

이번에는 SATA3를 네이티브로 지원하는 AMD SB850 칩셋과, SATA2를 네이티브 지원하는 Intel P55 플래폼에서, SATA2 케이블과 SATA3 케이블을 이용해 각 경우의 성능을 확인해 보겠다.

구분	테스트 시스템
CPU	Intel Core i5 750 (2.66GHz) AMD 페넘II X2 550 (3.1GHz)
메인보드	GIGABYTE P55A-UD3R (Intel P55) ASUS CrossHair IV Formula(AMD890FX +SB850)
메모리	OCZ PC3-10666 2GB x 2 (DDR3 1333MHz)
테스트 케이블	SATA3 하드디스크 : SARA3 (1종) / SATA2 (1종) SATA3 SSD : SATA3 (2종) / SATA2 (4종)
운영체제	Windows 7 Professional 32bit
VGA	NVIDIA Geforce GTX 460
OS HDD	WD 벨로시랩터 300GB (SATA2)

테스트는 SATA2를 네이티브 지원하는 Intel P55 플랫폼과, SATA3를 네이티브 지원하는 AMD 890FX + SB850 플랫폼에서 진행했으며, 샘플 제공사의 요청으로 테스트에 사용된 SATA3 하드디스크의 모델명은 밝히지 못함을 양해 부탁드린다.

테스트는 Ceystal Disk Mark 3.0.0.e 버전(100MB)과 HD Tune Pro 4.5 버전을 이용해 각 하드 디스크의 성능 테스트 중 가장 높은 성능을 기록하는 순차 읽기 성능과 순간 최고 성능을 나타내는 버스트 레이트만을 비교했으며, 각 그래프의 결과값은 구별을 용이하게 하기 위해 테스트에 사용된 각 케이블의 색상으로 표시했다.

이번 테스트는 케이블 종류에 따라 하드디스크와 SSD의 성능에 인터페이스 별 대역폭이 영향을 미치는지 알아보는 것이므로, 실 사용과 연관된 512K나 4K 테스트 결과는 비교 대상에서 제외했음을 알린다.

SATA3 하드디스크의 케이블에 따른 성능

테스트 결과는 앞서 별도의 기사에서 살펴본 결과와 크게 다르지 않은데, 하드디시크의 물리적 특성상 SATA2와 SATA3 포트에 따른 성능 차이나 동일 인터페이스에서 케이블 변화에 따른 성능 차이 모두 오차 범위 이내를 기록하고 있다.

반면, 순간 최고 성능을 뜻하는 버스트 레이트의 경우 SATA2 포트보다 SATA3 포트에서 각 인터페이스의 한계 대역폭에 따른 변화를 볼 수 있으며, SATA3 포트에서는 오히려 SATA2 케이블을 이용할 때 보다 높은 버스트 레이트 값을 기록한 것을 확인할 수 있다.

3. SATA3 SSD에 SATA2 케이블을 사용하면

SATA3에 대한 이야기에서 빠지지 않는 것이 바로 SATA3가 진정 필요한 장치는 SSD라는 것으로, 이미 SATA2의 물리적 대역폭을 한계까지 사용하는 SSD가 출시된 바 있다.

SATA3 대역폭을 활용하는 EKDRIVE Real SSD C300

그러던 차에 드디어 SATA3 인터페이스의 SSD가 출시되었고, 보드나라 기사를 통해 확인한 것 처럼 SATA2의 이론적 대역폭을 넘어 SATA3 대역폭을 활용하는 모습을 보여줬다.

당시 테스트에서는 SATA3 케이블만을 이용해 테스트를 진행했는데, 과연 SATA3 대역폭 이상의 성능을 보여주는 SSD도 케이블의 종류에 따라 성능 차이를 보여줄지를 당시 테스트에 사용된 Real SSD C30 64GB 제품으로 확인해 보겠다.

SATA3 SSD, 케이블 세대에 따른 성능 차이는?

SATA3 SSD의 경우 SATA2 포트에 연결할 경우 인터페이스의 한계 때문에 케이블 종류에 따른 의미있는 차이를 보여주지 못함을 알 수 있다. 이는 SATA3 포트에서도 유사한 결과를 보여주는데, 대역폭이 확대되면서 SATA3 SSD의 성능을 제대로 보여준다.

SATA3 포트에서 케이블 변화에 따른 성능 차이는, Crystal Disk Mark의 경우 오차 수준의 성능 차이를 보여주며, HD Tune Pro 테스트의 경우 대체적으로 SATA2 케이블을 이용한 결과가 SATA3 케이블을 이용한 결과보다 성능이 낮지만 그 차이는 크지 않으며, 일부 케이블의 경우 SATA3 케이블 수준의 성능을 보여준다.

SSD의 버스트 레이트는 하드디스크보다 낮은 결과값을 보이는데, SATA2 포트나 SATA3 포트 모두 케이블 버전에 관계없이 오차 수준의 차이를 보인다.

4. 케이블 버전보다 내실이 중요

SATA2 케이블과 SATA3 케이블의 샘플이 총 여섯 가지로 제한되기는 했지만, 테스트 결과 SATA 테이터 케이블의 세대 차이에 따른 성능 차이는 실질적으로 없다고 봐도 무방한 오차 수준이며, 어떤 경우엔 SATA2 케이블을 사용할 때 SATA3 케이블을 사용한 경우보다 높은 성능을 발휘하기도 한다.

복잡할 것 같은 SATA 케이블의 구조, 실제는 단순하다

그도 그럴 것이, SATA 데이터 케이블은 기본적으로 양 끝단의 접지선 두 개와, 중앙의 공용 접지선 한 개, 2쌍의 액티브 데이터 케이블로 이뤄졌으며, 시중에 SATA3 케이블이라고 판매되는 제품들도 기본 구조는 여기서 벗어날 수 없기 때문이다.

SATA-IO에서도 데이터 무결성 및 안정적인 동작을 위해 고급 케이블을 사용할 것을 권하기는 하지만, SATA1이나 SATA2 케이블 역시 SATA3 장치와 연결시 성능 저하가 일어난다는 언급은 없다.

즉, 오디오 시스템에서 단순 구리 케이블이나 골드 메탈 케이블이나 무산소동선 케이블 모두 사운드 신호를 전달하는데 무리가 없지만 신호 감쇠나 노이즈 간섭을 피해 보다 선명한 사운드를 즐기기 위해 고급형 케이블을 찾는 것 처럼, SATA 케이블 역시 일반 케이블과 고급 케이블의 차이가 있을 뿐 일반 SATA 케이블을 사용한다고 해서 SATA3 디바이스의 대역폭을 소화하지 못하는 것은 아니며, 이번 테스트를 통해 확인할 수 있었다.

출처 : http://www.bodnara.co.kr/bbs/article.html?num=79786

의미 없는 PCI-Express 3.0 메인보드 성능향상 기대. 지금 세대에서는 의미 없다.

JAESOO — Wed, 21 Jan 2015 18:15:14 +0000

Posted at 2012/05/07 17:54 | Posted in 컴퓨터/기타 하드웨어 정보

인텔 아이비브릿지는 PCI-Express 3.0을 지원해준다고 하는데, 이에따라 메인보드 제조사들이 일부 제품에 PCI-E 3.0 기능을 탑재하여 판매하고 있습니다.

그러나, 성능향상에 대한 기대 때문에 이 기능만을 위해 샌디브릿지 Z68이나, P67 보드에서 PCI-E 3.0 보드로 넘어갈 이유 또는, 샌디브릿지에서 아이비브릿지로 넘어가야할 이유는 없는 것으로 나타났습니다.

결론을 미리 말씀드렸는데 위 내용을 그대로 따르시면 손해볼 것이 없습니다.

이 테스트는 techpowerup.com에서 인텔 Core i7-3770K와 엔비디아와 AMD 각각의 하이엔드 그래픽카드인 GTX 680과 HD 7970으로 실시한 것입니다.

따라서 PCI-E 3.0의 필요성에 대해 확인해보기에 충분한 데이터라고 생각되며, 벤치마크를 실시한 사이트 역시 신뢰도가 상당히 높은 곳이라 90%는 믿으셔도 됩니다.

(img source: firingsquad.com)

■ 테스트 세팅: Link

Core i7-3770K와 ASUS Maximus V Gene Intel Z77 칩셋 보드를 사용한 테스트입니다.

■ 게임 벤치마크 결과 (배트맨 Arkham City): Link

위 결과 한 개만 보셔도 상관 없습니다. 경향을 말씀드리자면 PCI-E 2.0 상태 보다 PCI-E 3.0 상태에서 테스트한 결과는 1% 더 높은 결과를 보여줍니다.

■ Unigine Heaven 2.0: Link

GTX 680을 기준으로 볼 때 PCI-E 3.0 x16 상태에서 3프레임 더 높게 프레임이 나옵니다. 그러나 게임에서 3프레임이 체감으로 연결되기는 힘듭니다.

■ 성능 종합 (퍼센티지): source

위 결과가 전부라고 봐도 무방합니다. 모든 해상도에서의 성능을 분석한 것인데, 현재 싱글 GPU 최강의 성능을 보이는 GTX 680만 놓고 봐도 PCI-E 3.0 x16과 2.0 x16의 성능 차이는 1%에 불과하다는 것을 알 수 있습니다.

그렇다면 어떤 결론을 뽑아낼 수 있을까요? 샌디브릿지 사용자이면서 P67 혹은 H67, 61을 사용하시는 분인데 PCI-Express 2.0을 사용하시는 분이라면 PCI-Express 3.0에 대한 환상을 갖고 넘어가면 호갱님이 되는 것이겠죠.

물론 새로운 기술이 좋은 것은 확실하나, 현재 출시된 그래픽카드 및 CPU가 그 대역폭을 써먹지 못하는 것으로 보이며, 엔비디아나 AMD의 그래픽카드 둘 다 2세대는 지나야 저 대역폭을 제대로 쓸 수 있지 않을까 생각이 됩니다.

그 말은 다시 말하면, 지금 PCI-Express 3.0 메인보드를 구매해도 저걸 뽑아낼 부품들을 만날 시점이 되면 또다른 메인보드를 구매해야할 가능성이 크다는 것이겠죠.

꽤 늦게 PCI-E 3.0에 대한 벤치마크가 나왔는데, 더 빨리 공개되었어야합니다. 이제 이 글을 보신 분 중에는 낚이는 분이 없길 바랍니다.

그리고, 예전 VR-Zone.com에서 최초로 PCI-Express 3.0과 2.0 비교 벤치마크를 보여준 적이 있는데, 그게 복선이였네요. 한참 전에 미리 독자들에게 정답을 알려주었던 것 같습니다.

출처 : http://hiendedition.tistory.com/971

How to Set a Passive Port Range in Serv-U FTP Server - KB Article #2100

JAESOO — Wed, 21 Jan 2015 13:32:26 +0000

XpressEngine
How to Set a Passive Port Range in Serv-U FTP Server - KB Article #2100

CPU와 관련하여 뿔딱, 뚜따 등의 의미

JAESOO — Tue, 20 Jan 2015 16:50:01 +0000

주로 오버클러커들이 사용하는 용어로

뿔딱은 오버클럭이 잘 안되는 제품을 말하구요

(온도가 높다던지, 전압을 너무 먹는다던지, 블스가 뿜뿜이라던지)

뚜따는 CPU 뚜껑을 따고 그 안에 고급 서멀을 채운뒤 다시 뚜껑을 덮는겁니다.

아이비브릿지 이후의 CPU가 숄더링되어 나오지 않아

열전달이 떨어지는(≒쿨링에 불리한) 점을 개선하기 위한 조치구요

당연하지만 뚜따과정에 CPU가 손상되면 AS불가하므로 신중히 판단하시기 바랍니다.

- 키퍼(pwypark) 2014.08.13 22:43

------------------------------------------------------------------------------------

뿔딱 : CPU 오버클럭(기존속도보다 높인다는 말...)

시도해서 기준보다 올라가지 않을때 하는 말... 다른말로 꽝!!

뚜따 : 시퓨를 감싸주는 사각 금속체를 열어 쿨링(열을 식히는 것)이 잘~ 되게

하기위한 작업

<주의>

시퓨 파손될 위험 큼...

오버클럭 : 시피유의 기존 속도보다 적게는 10% 미만..높게는 50% 이상

속도를 높임으로써 기존의 능력치를 올리는것...

ex) 3.0G 짜리 시피유를 20% 오버 시 3.6G 의 속도로 올라감...

- 조선광인(dkxp815) 2014.08.13 22:47

------------------------------------------------------------------------------------

출처 : http://kin.naver.com/qna/detail.nhn?d1id=1&dirId=1010302&docId=204423725&qb=Y3B1IOu/lOuUsQ==&enc=utf8&section=kin&rank=2&search_sort=0&spq=0&pid=S7300lpySEKssttUptssssssss4-283651&sid=VL300gpyVmMAABBXmKA

베이트레일 셀러론 J1900을 탑재한 기가바이트 GA-J1900N-D3V 보드

JAESOO — Tue, 13 Jan 2015 10:08:54 +0000

요즘 관심을 갖고 살짝 빠져 사는게 있어서, 퇴근 후에 집에서 종종 이미지 빌드를 합니다.

(Intel Galileo BSP, OpenWRT 등)

집에서 주로 쓰는 OS는 윈도지만, 빌드 환경으로는 Linux가 쓸만한지라, PC에서 VMware로 가상 머신을 만들어서 빌드 환경으로 쓰고 있는데요.

성능이나 활용도는 꽤 괜찮지만, 불편한 점이 있습니다.

바로, 빌드를 하는 동안에는 PC가 계속 살아있어야 한다는 것인데요.

일단 빌드 중에는 재부팅을 못하고, 만약 윈도에서 크래시가 발생하면 당연하게도 처음부터 다시 해야

그리고 빌드 시간이 못해도 수십분은 되기 때문에, 밤에 작업을 하면 빌드를 돌려놓고 자야 하는데 빌드가 끝나고 나서 아침에 일어날 때까지 PC를 계속 켜놓아야 하는 문제가 있네요.

제 PC의 CPU가 Core i7 980X인데, 이게 무려 Max TDP가 130W까지 치솟는 물건이고 Idle시에도 전력 소모가 적다고는 말하기 힘들 것 같은 물건인지라, 계속 켜 놓는건 나름 부담이 되는 일이죠. 저희 집은 전력 사용량이 좀 많은 집이라... (월 평균 전기요금이 대략 17~20만원선)

그래서...

최근에 발매된 Bay Trail 기반 Celeron이 나름 코어 클럭이 2Ghz가 넘고, 4Core라길래 한번 빌드 머신으로 써 봐야겠다!!는 생각을 하게 되었답니다. :-)

일단 집에 있는 mini ITX용 케이스를 쓸 것이기에 제품부터 섭외를...

찾아보니까 몇가지 나오긴 하더군요.

ASRock 제품이 2개, Gigabyte 제품이 1개.

제 개인적인 선호도 + 네트웍 인터페이스 2개 + 시리얼 포트 2개를 이유로 기가바이트 제품으로 구입을 결정하였습니다. ㅎㅎㅎ

사용한 케이스는 이거구요. 예전에 VIA C7을 탑재한 PC2000E 보드가 달려있던 물건입니다.

일단 보드 사진도 한장.

구석 구석 한번 살펴보죠. :-)

가운데 있는 크고 아름다운(?) 방열판이 인상적이죠.

저 밑에는 Intel Celeron J1900 CPU와 함께 south bridge가 있을 것으로 추정되네요.

메모리는 DDR3L, 그러니까 저전력 버전 DDR3만 사용이 가능하네요.

일단 지원하는 최대 용량인 16GB(8GB * 2)를 꽂았습니다.

메모리 슬롯의 우측에는 Mini PCI-Ex 슬롯이 하나 있네요.

크기를 보아하니 Wireless NIC를 장착하기 위한 용도로 보이네요. 대부분 Half 사이즈로 나오니까.

다음에 봐서 Intel AC7260 하나 달아주면 될 것 같은데, 케이스에 안테나를 달기가 좀 안 좋은 구조라 일단 보류.

메모리 슬롯의 좌측에는 전원부가 자리잡고 있네요.

일단 전원 커넥터는 ATX 24핀인데, 솔직히 달려있는 것들을 봐서는 20핀만 꽂아도 충분할 듯.

바로 밑에 CPU에 보조 전원을 공급하기 위한 ATX 12V 4핀 단자가 있구요.

요전에 쓰던 VIA C7이나 ATOM D510에는 이게 없었는데...

어떻게 쓸 수 있을지는 모르겠지만 DEBUG PORT 핀 헤더가 하나 있고,

프린터 포트를 추가하고 싶으면 쓸 수 있도록 패러랠 포트 핀 헤더가 하나 있네요.

이건 뭐... 저로서는 쓸 일이 없는지라... :-)

RAID 0, 1을 지원하는 SATA2 포트가 2개 달려있구요.

SATA3가 아닌건 약간 아쉽네요.

옆에는 짤려있지만, 32bit PCI 슬롯이 하나 있어서, 문제 발생 시 POST diagnostic 카드 등을 사용할 수 있겠군요.

그리고 SATA2 포트 바로 위에는 기가바이트의 특징 중 하나인 Dual BIOS를 위한 칩이 2개 박혀있군요.

백 패널을 보면, 요즘 보기 힘든 RS232C 시리얼 포트가 무려 2개나 있고,

PS/2 키보드 및 마우스 단자랑 영상 출력용 D-SUB, DVI가 하나씩 있네요.

USB 3.0 포트 4개랑 10/100/1000Mbps를 지원하는 이더넷 포트가 2개, 그리고 사운드 단자.

사운드 칩셋은 이젠 정말 익숙한 Realtek의 칩셋이군요. 일명 꽃게사운드.

네트웍 칩셋도 Realtek의 기가비트 지원 칩셋인 RTL8111F 칩셋이네요. 일명 꽃게랜.

이놈을 가지고 앞에서 이야기한 빌드 머신을 만들어보았습니다. :-)

간단한 성능(?) 자료는 앞서 올린 포스팅에 써 있으니, 그쪽을 보시면 되겠네요.

( http://miraclepocket.tistory.com/39 )

출처 : http://miraclepocket.tistory.com/m/post/41

리눅스 webalizer를 통한 apache log(웹서버 접속 통계) 분석하기 (추천)

JAESOO — Wed, 24 Dec 2014 15:28:03 +0000

[리눅스] webalizer를 통한 apache log(웹서버 접속 통계) 분석하기 OS : CentOS 5.4 UTIL : Webalizer Version 2.21 1. 설치하기 yum -y install GeoIP-data GeoIP-devel GeoIP # 국가별 로그 남기기 (GeoIP 설치) yum -y install webalizer (주의 : 영문으로 컴파일되어 있음) - http://www.mrunix.net/webalizer/download.html 에서 소스를 다운로드 받는다. wget ftp://ftp.mrunix.net/pub/webalizer/webalizer-2.21-02-src.tar...

Mysql 에서 Got a packet bigger than 'max_allowed_packet' bytes 오류

JAESOO — Wed, 24 Dec 2014 15:06:28 +0000

질문:

글쓴이: lovethecorners 작성 일시: 토, 2005/07/30 - 2:08오후

설치 및 활용 QnA

mysql 4.0.14 에서 덤프를했습니다. 파일이 조금 큽니다. 525M 정도...근데, 이파일을 mysql 4.0.22 import 하려하는데 다음과 같은 에러를 보냅니다.

Got a packet bigger than 'max_allowed_packet' bytes

my.cnf 도 수정해보았는데...역시 안되네요...아시는분 계신가요?

답변:

해결하셨다니 다행입니다.
혹시나 싶어 관련 내용을 좀 더 보충하도록 하겠습니다.

mysql의 max_allowed_packet 설정값은 mysql이 클라이언트와 통신할 때 핸들링 할 수 있는 데이터의 양을 의미합니다. 디폴트로는 1mb로 설정되어 있습니다.

mysql 3.23버젼에선 이 값을 16mb까지 설정할 수 있고 4.0.1 이상부터는 1기가까지 가능합니다.

대량의 데이터를 mysql과 주고받을땐 connect timeout 시간이나 (혹시 server-side script를 이용한다면) 스크립트의 timeout시간도 확인해봐야 하며, timeout의 값이 충분히 설정되어 있다면 다음으로 max_allowed_packet의 값을 의심해봐야 합니다.

이 값은 mysql에 입력하는 데이터의 양 뿐만 아니라, 리턴되는 데이터의 양과도 관련이 있습니다. 따라서 대량의 데이터를 리턴받아야 하는 상황(blob data type같은..)이 요구될때도 설정값을 살펴봐야 합니다.

mysql.com에서는 이 값을 적당히 늘려주는 것이 더 좋다고(안전하다고) 밝히고 있습니다. mysql은 지정된 값만큼 항상 memory를 가지고 있는 것이 아니라, 필요한 양 만큼의 메모리만(단, max_allowed_packet의 값에 제한받습니다.) 사용합니다.

이상으로
http://dev.mysql.com/doc/mysql/en/packet-too-large.html
에 있는 내용 가지고 아는척 해봤습니다. :oops: :oops:

출처 : https://kldp.org/node/55172

MySQL 내부 변수 max_allowed_packet

JAESOO — Wed, 24 Dec 2014 15:04:11 +0000

우리의 친구 MySQL에는 내부적으로 런타임 때(즉, 프로그램이 시작될 때)
설정되는 내부 변수들을 가지고 있다.

이러한 내부 변수의 설정은,
mysql 명령어를 이용하여 프로그램을 시작할 때, 직접 입력할 수도 있지만,

my.cnf에 넣어두면 DEFAULT로 읽기 때문에,
미리미리 입력해 놓으면, 까먹거나 하는 사태가 발생하지 않는다.

그 중 오늘 살펴 볼 것은 max_allowed_packet 이다.

왜 하필 이 놈을???? 이라고 생각할 수도 있지만,
내가 오늘 이 놈때문에 고초를 겪었기 때문이라고 말할 수 밖에.......
-0-;;;;

일단 ERROR가 발생한 Log를 보자..
아래 로그는 Replication이 설정 되어 있는 두 서버가 있고,

이 중 Slave에서 Master의 Log를 다 읽지 못하고,
max_allowed_packet 탓을 하고 있는 장면이다.

##################################################################
80715 15:02:00 [ERROR] Error reading packet from server: Got packet bigger than 'max_allowed_packet' bytes ( server_errno=2020)
80715 15:02:00 [ERROR] Log entry on master is longer than max_allowed_packet (1048013) on slave. If the entry is correct, restart the server with a higher value of max_allowed_pac
et
####################################################################
(설정을 바꾸면, MySQL 데몬을 죽이고 다시 시작해야 한다고 나오지?)

이에 대해서,
MySQL REFERENCE 에는 max_allowed_packet에 대해 다음과 같이 말한다.

####################################################################
max_allowed_packet
서버에 전달 또는 서버로부터 받게 되는 패킷의 최대 길이. (디폴트는 16MB임.)
####################################################################

즉, 이 말인 즉슨 한 번에 오고 가는 packet의 사이즈가 정해져 있다는 말씀이다.

그런데 여기서 궁금한 것 !!!!

Q.
TCP/IP 통신이 DEFAULT 인 MySQL의 패킷은,
TCP에 의해 통신시 분명히 패킷이 쪼개져서 움직일 테인데,
그것의 사이즈를 왜 정한다니..

A.
< MySQL Packet Too large>
http://dev.mysql.com/doc/refman/5.0/en/packet-too-large.html

그런 점에 대해서 위의 링크에서 또 설명이 나온다.
쏼라쏼라 풀어보면..

---------------------------------------------------------------------------
대저 MySQL에서의 Packet이라 함은
Single SQL 문 또는,
Replication이 이루어지는 Master에서 Slave로의 Binary Log Event를 의미한다.
..... MySQL 5.0 은 최대 1GB의 패킷을 허용하고 ......
---------------------------------------------------------------------------

흠.. 그렇다면, TCP로 쪼개져서 들어온 패킷들이,
뭉쳐져서 1개로 합쳐질 수 있는 한도 크기라는 의미로 보이는데....

그렇게 된다면,
TCP가 쪼개는 패킷의 사이즈와는 전혀 상관없다는 말씀이로군..
쩝... --;; 그걸 왜 햇갈리게 Packet이라고 부르는거냣!!!!!

암튼간에... '그런거였군!!!!' 하며 뒷목을 부여잡고,
10 + 8 을 몇 번 한 후에,
다음에 든 의문점을 알아 내기로 했다.

Q.
왜 max_allowed_packet의 크기가 Default 16M라면서,
실제 설치 후 값은 1M(1,048,576) 인 것이냐!!!!!

A.
그런데... 두둥!! 이것 역시 아래 링크에 있더라..

<MySQL Packet Too large - 위 링크랑 동일하다 -0-;;;>
http://dev.mysql.com/doc/refman/5.0/en/packet-too-large.html

또 한 번, 쏼라쏼라 말 중 찝어 오자면...
프로그램은 DEFAULT max_allowed_packet 이
--------------------------------------------------------------------------------
MySQL CLIENT 프로그램은 DEFAULT max_allowed_packet 이16M.
MySQL SERVER 의 DEFAULT max_allowed_packet 은 1M....(이런 우라질리아 --;;)
--------------------------------------------------------------------------------

라고 하더군....
쩝... 뒷 목이 뽀사지겠다 이눔아!!!!!!
서버쯤 되면 사이즈 좀 크게 잡아줄 것이지... 쪼잔하게.. 1메가가 모니 --;;

그러면... 다음 질문..

Q.
그런데, MySQL이 아무리 븅~ 이라고 할 지라도,
어떻게 Packet을 쏘길래, 받지도 못 할만큼의 사이즈로 쏘는 것인가?

A.
얼래.... 이것 역시 아래 링크에 나온다...

<MySQL Packet Too large - 다른 링크 아니다. 위랑 똑같다 --;;>
http://dev.mysql.com/doc/refman/5.0/en/packet-too-large.html

--------------------------------------------------------------------------------
Client 와 Server는 각각 max_allowed_packet을 가지고 있다.
만약,네넘이 커~~다란 사이즈의 Packet을 날리고 싶다면,
Client와 Server의 max_allowed_packet을 모두 바꿔 주어야 할 것이다..... ㅋㅋㅋ
--------------------------------------------------------------------------------

이런 뒌장 맞을.....

이 글을 읽고 조사해보니...
역시나, Master 녀석의 max_allowed_packet의 사이즈가 자그만치....
128M..............
쿠헬헬헬~~ 이 정도 되야 서버라고 부를 수 있지.... 하면서.. 역시나... 10+8 --;;

결국, slave 서버의 my.cnf에서
max_allowed_packet = 128M 로 바꿔 주고,
아무도 모르게 슬쩍 죽였다 살리기..... -0-;;;;

흐흐흐.. 사건은 종결 되었다.... 아무도 모르게....

흠흠... 다시 한 번 말하지만,
변경된 값을 적용하려면 MySQL을 다시 시작해야하기 때문에,
서비스 중인 장비에겐 치명적일 수 있다는 것.....

잘못하면...... 고객의 Complain에 몸져 누울 수 있다는 것!!!!

잊지말고 기억해 두자.. (-0-)/

출처 : http://blackbull.tistory.com/12

스위치 성능인 PPS(Packet per Sec, 초당 처리 가능한 최대 패킷 수) 계산법

JAESOO — Thu, 27 Nov 2014 09:58:09 +0000

지난번에 스위칭 패브릭 계산법에 대해 공부해 보았습니다.
이번에는 스위칭 패브릭과 항상 함께 얘기되는 Forwording Rate 계산법에 대해 공부해 보겠습니다.

스위치 성능(bps) : 스위칭 패브릭에 의한 최대 데이터 처리능력
단위 : bit

전송속도(pps) : 실질적인 데이터 처리능력(초당 몇 개의 패킷을 처리할 수있는가 ?)
단위 : packet

우선 최대 포워딩 대역폭과 pps가 어떻게 산출되는지를 설명하기에 앞서 쉽게 예를 들면 다음과 같습니다.

4차선 도로에는 차량이 4차선 도로에 해당하는 만큼 다닐 수 있습니다.
그런데 4차선 도로에 교통 경찰이 간섭해 교통 순경 때문에 4차선 도로에서 낼 수 있는 속력을 내지 못합니다.
여기서 말하고자 하는 것은 최대 포워딩 대역폭은 4차선 도로 그 자체를 논할 때 거론되는 것이고,
교통순경이 개입된다고 할 때는 pps라는 단어를 써서 스위치 처리 능력이라고 하면, 쉽게 이해할 수 있을 것입니다.

1개의 이더넷 포트가 있다고 가정해 봅시다. 이럴 경우 최대 포워딩 대역폭은 10Mbps가 나옵니다
(스위칭 패브릭은 이럴 경우 full이 된다고 가정하면 20Mbps가 됩니다).
말 그대로 물리적인 도로의 최대 전송 속도를 물어보는 겁니다.
그런데 교통 경찰이 개입해도 물리적인 도로의 최대 속력이 나올 수 있을지 다시 한번 계산을 해야 합니다.
이럴 때 쓰는 개념이 pps입니다.

< pps의 산출 공식 >

PPS(packet per second) = 1초 당 (Frame Time + Preamble Time + IFG)시간
- Frame Time - 64바이트 프레임(프레임의 최소 단위)을 처리하는데 걸리는 시간
- preamble Time - 프레임 앞에 들어가는 헤더와 같은 것을 처리하는 시간
- IFG(InterFrameGap) - 프레임 사이의 간격

- packet - OSI 7계층중 3계층인 Network Layer에서 취급하는 데이터단위
데이터(전송할데이터+포트넘버)와 IP주소가 포함된 데이터 단위
- Frame - OSI 7계층중 2계층인 Data Link Layer에서 취급하는 데이터 단위
패킷이 포함하고있는 데이터에 MAC주소가 포함된 데이터 단위

이더넷 패킷 최소 길이
1 Packet = 84 byte(= 64 byte + 8 byte 프레임블 + 12 byte 프레임 간격)
= 672 bits(=64byte*8 + 8byte*8 + 12byte*8)

이더넷에서 1비트 처리하는데 걸리는 시간 0.1㎳
0.1ms = 1 bit
1ms = 10 bits(=1.25 byte)
1sec = 10000 bits(=1250 byte)

1 Packet 처리하는데 걸리는 시간(= Frame Time + Preamble Time + IFG)
= 67.2ms(= 64byte*8*0.1ms + 8byte*8*0.1ms + 12byte*8*0.1ms)
= 67.2ms(= 512bits*0.1ms + 64bits*0.1ms + 96bits*0.1ms)
= 67.2ms(= 51.2ms + 6.4ms + 9.6ms)

672 bits/sec(=bps) = 1 packet/sec(=pps)
672 bps = 1 pps
1 bps = 1/672 pps = 0.001488 pps
1 Kbps = 1.488 pps
1 Mbps = 1488 pps = 1.48 Kpps
10 Mbps = 14880 pps = 14.8 Kpps
100 Mbps = 148800 pps = 148.8 Kpps = 0.1488 Mpps
1000 Mbps = 1488000 pps = 1.488 Mpps

다음은 시스코 스위치의 사양입니다.
Cisco Catalyst 3560-24TS: 24 Ethernet 10/100 ports and 2 SFP-based Gigabit Ethernet ports
Cisco Catalyst 3560-48TS: 48 Ethernet 10/100 ports and 4 SFP-based Gigabit Ethernet ports
Cisco Catalyst 3560G-24TS: 24 Ethernet 10/100/1000 ports and 4 SFP-based Gigabit Ethernet ports
Cisco Catalyst 3560G-48TS: 48 Ethernet 10/100/1000 ports and 4 SFP-based Gigabit Ethernet ports

38.7 Mpps (Cisco Catalyst 3560G-48TS, Catalyst 3560G-48PS, Catalyst 3560G-24TS, and Catalyst 3560G-24PS);
13.1 Mpps (Cisco Catalyst 3560-48TS and Catalyst 3560-48PS);
6.5 Mpps (Cisco Catalyst 3560-24TS and Catalyst 3560-24PS);

제조사에서 제시한 Forwading Rate이 이론과 맞는지 확인해 볼까요?
Forwarding Rate(포워딩 레이트)
C3560-24TS Forwarding Rate
= 24 port * 0.1488Mpps + 2 port * 1.488Mpps = 3.571Mpps + 2.976Mpps = 6.547Mpps
C3560-48TS Forwarding Rate
= 48 port * 0.1488Mpps + 2 port * 1.488Mpps = 7.142Mpps + 2.976Mpps = 10.118Mpps

C3560G-24TS Forwarding Rate
= 24 port * 1.488Mpps + 4 port * 1.488Mpps = 35.712Mpps + 5.952Mpps = 41.664Mpps

C3560G-48TS Forwarding Rate
= 48 port * 1.488Mpps + 4 port * 1.488Mpps = 71.424Mpps + 5.952Mpps = 77.376Mpps

그러므로 Cisco 스위치에서는
10/100Mbps 스위치는 제시된 Forwading Rate과 이론적 Forwading Rate이 거의 일치하지만
10/100/1000Mbps 스위치에서는 제시된 Forwading Rate이 이론적 Forwading Rate에 훨씬 못 미치네요

스위치 장비의 스펙을 이해하시는데 조금이나마 도움이 되었으면 합니다.

출처 : https://www.netbuysell.co.kr/global_asp/board/board_view.asp?K_no=365&page=1&Hit_Plus=85&Codeno=2&Pgtype=A&Html_change=

PPS(Packet per Sec, 초당 처리 가능한 최대 패킷 수) 계산법

JAESOO — Thu, 27 Nov 2014 09:54:19 +0000

- 출처 NRC와 함께 하는 LIVE 네트웍 -
와이어 속도는 구리선의 속도를 지원한다는 것인데.. UTP를 이용해 10Mbps로 사용한다면

스위치를 지나갈때도 이속도를 보장해준다는것이다.

여기에 나오는 개념이 PPS인데.. 1초당 몇 패킷을 보낸다는것은 알고 있겠지..

이더넷은 기본적으로 64~1518의 크기로 보내는데 64를 기준으로 발표한단다.. 왜냐면

이렇게 계산해야 큰값이 나온단다 ㅋ.

아 숫자만 나오면 짜증나.. ~ 일단.. 예를 들어서

- 책에 있는 내용이다 -

도로에 자동차 1대가 지나가는데 5초가 걸린다면 이 도로에는 평균 1초당 몇대의 차가 지나갈수 있을까? 라고는 했다.

그렇다면 1대 : 5초 = x : 1초다 그럼 x = 1/5 = 0.2

그렇다.~!! 우리는 64로 계산을 한다고 했다.

1초당 지나가는 패킷의 수를 구하려면 1/(64Byte 프레임이 지나가는데 소요되는 total 시간)

이렇게 계산하면 된다는 거죠~..

여기서 조금 이해가 안가는게 말이지..

토탈시간이라는게 제대로 된 패킷 한개가 지나가는 시간이라는데.. 64+ IFG + Preamble 까지 포함 되어야 한다는데.. IFG는 프래임간의 간격인걸 알겠다.. 그리고 Preamble 는 동기를 마쳐줘는 야 던진다 받아라 하는 말이라는것도.. 그리고 IEEE에서 정의된 타임은 IFG가 96bit time이고 Preamble는 8byte 란다..

그러니까 64바이트가 지나가는 시간은..

1/(9.6+6.4+51.2)us = 14,880 이란다...

근데.. 이게 여기서 설명된게..(아 숫자에 약해) 1bit time 가 1bit가 전송되는데 필요한 시간이

10Mbps(이건 1초당 10메가 비트를 보내는거자나??) 의 역수라는데 0.1 μs 이다.

그럼 계산을 해볼까.. 1 : 10485760 = x : 1bit ?? 이런식이 성립 되는거야?

그리고 계산식이

PPS = 1/(전체 시간 )

= 1/(IFG + Preamble +64byte)

= 1/(9.6 + 6.4 + 51.2)

- 이건 넷메모 출처요 -

Q.
업체 장비 사양에 나온 포워딩 률(forwarding rate)과 최대 포워딩 률에 대해 궁금합니다.
예를 들어서 시스코 카탈리스트 2950(2950T-24) 스위치의 장비 사양을 보면
스위칭 패브릭(switching fabric) = 13.6Gbps,
최대 포워딩 대역폭(maximum forwarding bandwidth) = 6.8Gbps라고 나옵니다.
왜 포워딩 대역폭이 pps가 아닌 bps로 나오는지 또한 6.8Gbps가 어떻게 계산된 것인지도 궁금합니다.
또한 그냥 포워딩 률=10.1Mpps라고 나오는데, 그 수치는 어떻게 산출됐는지 알려주세요.

A.
스위칭 패브릭 = 13.6Gbps라고 표현할 때는 스위칭 패브릭을 스위치 전체 처리 용량으로 여기는 것입니다.
쉽게 설명하면, 2개의 고속 이더넷 포트를 가진 스위치의 스위칭 패브릭은 400Mbps입니다.
왜냐면 풀 듀풀렉스(full duplex)로 처리할 것을 가정하기 때문에 원래 물리적인 전송 속도(2 고속 이더넷 = 200Mbps)의
2배인 400Mbps로 산출되는 것이지요.
예를 들어, 2950T-24 스위치로 스위칭 패브릭을 계산하면 24포트의 고속 이더넷은 2포트가 기가비트이므로,
4.8Gbps + 4Gpbs = 8.8Gbps가 나옵니다.
그런데 13.6Gbps는 어디서 나왔는지 궁금할 수 있습니다.
아마도 13.6Gbps는 2950T와 같은 섀시를 사용하는 제품인 2950G를 기준으로 산출한 것 같습니다.
그러므로 48포트 고속 이더넷 + 2포트 기가비트 = 9.6Gbps + 4Gbps = 13.6Gbps가 됩니다.
또한 최대 포워딩 률이라고 표현하신 것은 최대 포워딩 대역폭이라고 할 수 있습니다.
우선 최대 포워딩 대역폭과 pps가 어떻게 산출됐는지를 설명하기에 앞서 쉽게 예를 들면 다음과 같습니다.
4차선 도로에는 차량이 4차선 도로에 해당하는 만큼 다닐 수 있습니다.
그런데 4차선 도로에 교통 경찰이 간섭해 교통 순경 때문에 4차선 도로에서 낼 수 있는 속력을 내지 못합니다.
여기서 말하고자 하는 것은 최대 포워딩 대역폭은 4차선 도로 그 자체를 논할 때 거론되는 것이고,
교통순경이 개입된다고 할 때는 pps라는 단어를 써서 스위치 처리 능력이라고 하면, 쉽게 이해할 수 있을 것입니다.
1개의 이더넷 포트가 있다고 가정해 봅시다. 이럴 경우 최대 포워딩 대역폭은 10Mbps가 나옵니다
(스위칭 패브릭은 이럴 경우 full이 된다고 가정하면 20Mbps가 됩니다).
말 그대로 물리적인 도로의 최대 전송 속도를 물어보는 겁니다.
그런데 교통 경찰이 개입해도 물리적인 도로의 최대 속력이 나올 수 있을지 다시 한번 계산을 해야 합니다.
이럴 때 쓰는 개념이 pps입니다. pps의 산출 공식은 다음과 같습니다.

pps = 1초 / (IFG + Preamble Time + Frame Time)

10Mbps일 경우에 만약 최대 10Mbps 속력이 나온다고 가정을 했을 경우 pps값은 14880pps입니다.
IFG(InterFrameGap)으로 프레임 사이에 간격을 논의하고
preamble은 프레임 앞에 들어가는 헤더와 같은 것이라고 알고 있습니다.
14880pps는 10Mbps일 경우를 기준으로 IFG = 9.6㎳, Preamble time= 6.4㎳, frame time = 51.2㎳가 된다고 합니다.
프레임 타임은 보통 64바이트 프레임(프레임의 최소 단위)를 기준으로 하기 때문에
이더넷에서 1비트 처리하는데 0.1㎳가 걸리므로 64×8×0.1 = 51.2㎳가 됩니다.
10Mbps일 경우는 14880pps 이상이 돼야 회선 속도(wire speed)를 낸다고 이야기할 수 있습니다.
고속 이더넷 포트를 기준으로 하면 148800pps 이상이 돼야 어느 정도의 회선 속도를 낸다고 말할 수 있습니다.
따라서 2950T-24의 포워딩 률이 10.1Mpps가 아니라 2950G의 포워딩 률이 10.1Mpps입니다.
2950G 스위치의 경우 48포트 고속이더넷에 2개의 기가비트 포트가 있으므로,
포워딩 률을 포트별로 나눠보면, 10.1Mpps / (48+20) = 155744pps가 됩니다.
대략 155000pps가 나오므로 고속 이더넷일 경우 148800pps이상이 됩니다.
그러므로 회선 속도를 낼 수 있습니다. 2950T-24는 6.6Mpps입니다.
이것도 이와 같이 계산하면 157000pps정도 나옵니다.

스위칭 패브릭 구조에 사용되는 기술은
공유형 버스(shared bus) 방식, 크로스바(crossbar) 방식, 공유형 메모리(shared memory) 방식 등이 있습니다.
공유형 버스 방식은 버스에서의 패킷 처리에 한계가 있기 때문에 오버헤드가 발생하는 문제가 있고,
크로스바 방식은 패킷 처리 스케줄링 때문에 속도에 한계가 있을 수 있습니다.
공유형 메모리 방식은 메모리 액세스 시간에 의해 제약을 받지만 많은 개선을 통해 논-블로킹(non-blocking) 구조를
갖게 된 것입니다. 현재 많은 장비들에서 공유형 메모리 방식을 사용하고 있습니다.
하지만 스위칭 패브릭 구현에 일정한 기준은 없으면 패킷을 전송하는데 최선의 방법을 선택하는 것이 원칙입니다.
결국 스위칭 패브릭에 의한 최대 데이터 처리 능력을 흔히 스위칭 패브릭으로 표시한다고 보면 됩니다.
포워딩 레이트는 실제 처리 가능한 데이터 율을 의미하며, 보통 'Full wire speed' 제공이라고 표시합니다.
'Full wire speed'는 물리적인 인터페이스에 정의된 처리 속도를 100% 지원한다는 의미입니다.
경우에 따라 pps(Packet per Sec, 초당 처리 가능한 최대 패킷 수이며
이더넷의 최소 프레임인 64바이트 프레임을 기준으로 합니다) 단위로 나타내기도 하는데,
24개의 TX 포트와 2개의 기가비트 포트를 제공하는 스위치라면 최소한 9.6Mpps를 지원해야 합니다.
문의하신 경우도 장비가 제공하는 포트만 고려한다면 논-블로킹 스위칭을 위해 최소한
아래와 같은 정도의 스위칭 패브릭과 포워딩 레이트를 제공해야 할 것 같습니다.

·스위치 패브릭 용량(Full duplex 기준)
1기가비트 2포트×2Gbps = 4Gbps
10/100Mbps 48포트×200Mbps = 9.6Gbps
→ 총 13.6Gbps

·포워딩 레이트
1기가비트 2포트×1.488Mpps = 2.976Mpps
10/100Mbps 48포트×0.1488Mpps = 7.142Mpps
→ 총 10.118Mpps

포워딩 레이트는 초당 전송 가능한 64바이트 패킷 수를 기준으로 했으며,
'Full wire-speed'를 지원할 경우 1기가비트 포트는 1.488Mpps, 100Mbps는 0.1488Mpps를 지원합니다.
위의 수치는 현재 사용하고 있는 스위치의 성능 사양과 많은 차이가 있습니다.
이것은 장비의 성능이 일반적인 스위치에 비해 현저하게 떨어지는 경우라고 생각할 수 있습니다.
하지만 이런 경우 위에 제시된 성능이 다른 기준을 따르고 있을 가능성도 있습니다.

컴터에 사용하는 단위는 다음과 같습니다.

1 K (킬로) = 1024 입니다. -> 2의 10승
1 M (메가) = 1024 * 1024 입니다. ->2의 20승
1 G (기가) = 1024 * 1024 * 1024 입니다. ->2의 30승

1 Mbps 는 1,048,576 bps.
2,048,000 bps 는 약 2 Mbps!!

bps는 bit per second 의 약자이고
초당 전송되는 bit 의 수다.

BPS 는 Byte per second 의 약자이다.

BPS=CPS로도 쓰인다. 왜냐고? 헷깔리니깐.

1 byte 가 8 bit 이므로
2,048,000 bps는 8로 나누면 256,000 이니까

즉 초당 256,000 개의 문자를 보내는 속도다.

출처 : http://kjlim.egloos.com/viewer/10003823

스토리지 IBrix 6.0 preview

JAESOO — Thu, 20 Nov 2014 10:10:48 +0000

단순 Preview 다.

아직 정식 릴리즈는 안된것 같고, RC 정도만 나온것 같은데,

일단 내가 HP 에 있으면서 테스트 할 기회가 너무 넘쳐나서,

간략한 소개라기보단, 간략한 이슈화를 시키고자 글을 쓴다.

일단 6.0 사실 5.6 버젼으로 올라가면서 RHEL 5.5 버젼으로의 업그레이드는

이녀석을 위한 교두보였을지도 모르겠다.

6.0! 완벽하게 5.5 이후의 피쳐들을 잘 쓰고 있다.

특히나, ext3 를 넘어선 ibfs ( IbrixFS ) 의 향상은 뛰어나진것 같다.

물론 성능 자체는 어차피 Appliance 형태인 셈이니, 각 조직들의 성능을 따르는거니까,

둘째치고, Ibrix 커널 자체가 엄청나게 안정화 된것 같다.

Oops 나, Profiling (Oprofile), Debug 모드 등을 여러번 테스트해 보았을때.

뿌려지는 스택의 디테일함이 달라졌다. 이건, 물론 기본적으로 RHEL 이나

리눅스 자체의 지원이 달라진것도 있겠지만, 그것들을 충분히 이용 할 수 있게 만든

IBrix 도 흥미롭다는 사실!

일단 6.0 에서 가장 크게 새로 추가된 피쳐만 살짜쿵 애기해본다.

1. Native Snapshot.

HP 모 부장님은 자꾸 H/W 랑 S/W 랑 구분함과 동시에 외려 그 둘을 자꾸 헛갈리게

얘기하시곤 하는데 (막 H/W 를 S/W 라고하는둥) 그건 단어의 헛갈림이니 접어두고 :P

6.0 에서 추가된 Native Snapshot 이란 말그대로 , Software Snapshot 이며,

IBrix 에서 기존 제공하든 H/W Snapshot 은 Vendor Storage (EMC,HP,Dell)

만 지원했음과 다르게, 디렉토리별로 스냅샷을 제공하는 부분인게다.

물론 Ibrix Engine 과 DB 에서 관리하며, 엄밀히 따지면,

ZFS 나, BTRFS 또는, SnapFS 에서의 그 것들과 같이, 파일시스템자체에

Inode 에대한 Snap (Link) Feature 를 이용하여, Directory 상태 자체를

히든 ( .@InodeNum ) 디렉토리를 생성 후 링크하는 식으로 구현을 한 것이다.

리눅스에선 .@숫자 로 보이니 애매모호하긴 한데,

CIFS 나 NFS 등에서는 파일에 변경이 생길경우 바로 Hidden 파일 보기 옵션조절을 통해

그대로 다 보이게 된다.

물론 복구는 복사식으로 운영해야 한다는 점은 어쩔 수 없다고 본다.

2. SMB 2.0 적용.

사실 SMB 3.0 이 나온 시점에서 뭔 개소리냐 하겠으나,

Cross Protocol 에 대한 안정성을 따지자면 3.0 보단 2.0 에서가 최고인게다.

Likewise 를 이용해야 하는 상황이니까 말이다.

LikeWise 자체도 많은 버그가 수정되었고, 특히 SMB 나 NFS 프로토콜 특유의

접근하려는 파일시스템의 Directory Stat 및 File Stat 을 매번 받아오는 과정을

아예 단축시키거나 대부분 제외시켜 접근 속도를 굉장히 높였다는게 장점!
(물론 나름대로의 백그라운드 메타데이타 이용이 늘었다 ㅡ,.ㅡ:: )

3. Historical Stastics

기존 IBrix 의 단점이. 그래피컬한 데이타를 원하는 시간동안을 뽑아 볼 수 없었다는점!

그래프로 나오는건 오로지 흘러가는 데이타인 실시간 상태정도일 뿐이였던거에 반해,

원하는 시간대로 주기별로 데이타를 그래피컬하게 수집해 주는 기능이 생겼다는점!

물론 실시간은 아니고, 원하는 대로 데이타를 시간대 만큼(Range) 또는,

원하는 상태대로를 뽑아 볼 수 있게 되었다는 점이다.

사실.....SAR 를 뽑아 KSar 로 돌려 보여주는것과 같다.

여기서 주목할 점은 mplot 인가? Python 모듈을 이용한다는 점이다.

내가 사실 이거 설치할때 개삽질좀 했는데, IBRix 정식 이미지에서 제공하는 툴로는

설치할 수가 없다. 왜냐면 IBRIX 가 그냥 깔아주는 OS 에서는 XWindow 시스템은

설치하지도 않을 뿐더러, TKinter 나 WxWidget 등 의 그래피컬 툴은

전혀 설치하지 않으니까!

이건 내가 Python Module 을 직접 인스톨 하는 방향으로 해결했으니,

따로 노하우를 공개할 기회가 있을거고!

뭐 어쨋든 설치하고 나니까 그래피컬하게 뿜어주는데,

이거 명품이더라.

맨날 Dstat 이나, IOzone 등을 따로따로 보면서 막 때려 맞추던 BMT 방식을

현저하게 바꿔줄 기능이거든..

사실 ATop 등을 왜 기본으로 제공하는지 아무도 알려고 안하던데..

이녀석도 차암 BottleNeck 이 어디서부터 나오는지 구분하기 위한 척도로써

사용하기에 참 좋은녀석인데 ( Network 위주 ).. 난 말 안할거임 H 사 있는동안은 ㅎㅎ

암튼 내가 봤을때 이 3가지가 가장 큰 6.0의 메리트이지 않을까 싶다.

블럭 스냅샷따위로 디스크 및 LUN 마다 용량을 줄여먹을 필요도 없고,

아주 손쉽게 그냥 유저레벨 자체에서도 복사를 통한 복구가 가능한점 +.,+

SMB 향상.

그리고 관리자들의 고역중 하나인 그래피컬한 종합적인 자체 성능 분석 도구까지!

차암 좋아졌어...... 다만 유저블한 부분보다 엔지니어링 한 부분을 좀 더 유즈풀하게

바꿔주면 더 좋지 않았을까 하는 점...

내가 관두면 만들어 쓰는데, 직원인데 왜 내가 만들어 써야돼? 롤들이 있는데말야 ㅎㅎ

또한 하드웨어적으로 따지자면 P2000 G3 , IBrix G3 ( Proliant Server G7 )

인데, 이녀석들도 부팅이 좀 길어져서 그렇치 Controller 단의 Flushing 이나,

Writing 등이 매우 안정적이면서 게다가 빠르기까지 하더라.

미들웨어급 이상이라고 봐도 좋을거 같다는 .. ㅎㅎ

이렇게 좋은데 잘좀 하자..BRix 정말 뛰어난 Network File System 이며,

유일하게 정말로, System 이라고 얘기 할 수 있는 제품인데말야....

Cross Platform 이나 Cross Protocol 에 대한 두려움은 필요없거든.

어차피 RFC 따라서 하고있는데말야. 영업이나 기술이나 그냥 안되는건 안되고,

Best Practice 만 줄창 얘기하면 돼. 그리고 그 외의 고객 요구들은

Safty 및 Stupid 또는, Silent 하게 쑈부보면 되는거아닐까 싶다는거지..

이젠 잠.. 참 좋은데 쓰라고해도 쓰질 않고, 아무도 몰라... 이거 차~암 좋은데 ㅡ,.ㅡ
아이실론따위 만드는 E모 사보다 훨씬 훨씬 훨씬 발전적이고, 안정적이며,

싼데! 다가! 제대로 지원해주는데 말야...

PS : 오늘은 여기까지. 술한잔 마시며 오랜만에 쓰는 글들이 차암 즐겁다.

술만마시는게 아니라 예전엔 정말 술(맥주?) 마시며 기술문서 기록하고 이런

열정이 있었는데말야...

앞으로 다시 이런 열정을 되살려보려고 해야겠다.

어차피 이정도에 체력빠져서 죽을거같으면 진작 죽어야 하니까. 생명을 불태우겠어.

"하얗게 불태워버렸어" - 내일의 죠

가 생각나는 오늘!

출처 : http://mirr.tistory.com/621

Mysql binary log 정리, 삭제 주기 설정

JAESOO — Mon, 17 Nov 2014 09:44:24 +0000

DB에 레코드가 많이 쌓여 테이블 파일의 용량이 증가하는 것도 문제지만,

binary log를 초기 세팅대로 방치하면 금방 HDD가 꽉 차게 된다.

# ll -h
total 22G
drwx------ 2 mysql mysql 4.0K Feb 5 10:37 acclog
-rw-r----- 1 mysql mysql 112K Feb 5 19:09 localhost.localdomain.err
-rw-rw---- 1 mysql mysql 5 Feb 5 19:09 localhost.localdomain.pid
drwx------ 2 mysql mysql 4.0K Feb 5 10:15 mysql
-rw-rw---- 1 mysql mysql 1.1G Feb 15 07:13 mysql-bin.000174
-rw-rw---- 1 mysql mysql 1.1G Feb 15 07:24 mysql-bin.000175
-rw-rw---- 1 mysql mysql 1.1G Feb 15 07:36 mysql-bin.000176
-rw-rw---- 1 mysql mysql 1.1G Feb 15 07:47 mysql-bin.000177
-rw-rw---- 1 mysql mysql 1.1G Feb 15 07:59 mysql-bin.000178
-rw-rw---- 1 mysql mysql 1.1G Feb 15 08:16 mysql-bin.000179
-rw-rw---- 1 mysql mysql 1.1G Feb 15 08:31 mysql-bin.000180
-rw-rw---- 1 mysql mysql 1.1G Feb 15 08:42 mysql-bin.000181
-rw-rw---- 1 mysql mysql 1.1G Feb 15 08:54 mysql-bin.000182
-rw-rw---- 1 mysql mysql 1.1G Feb 15 09:05 mysql-bin.000183
-rw-rw---- 1 mysql mysql 1.1G Feb 15 09:17 mysql-bin.000184
-rw-rw---- 1 mysql mysql 1.1G Feb 15 09:29 mysql-bin.000185
-rw-rw---- 1 mysql mysql 1.1G Feb 15 09:40 mysql-bin.000186
-rw-rw---- 1 mysql mysql 1.1G Feb 15 09:52 mysql-bin.000187
-rw-rw---- 1 mysql mysql 1.1G Feb 15 10:04 mysql-bin.000188
-rw-rw---- 1 mysql mysql 334M Feb 15 11:43 mysql-bin.000189
-rw-r----- 1 mysql mysql 418 Feb 15 10:04 mysql-bin.index
drwx------ 2 mysql mysql 4.0K Feb 5 10:15 test

data 디렉토리(configure에 따라 다름) 내의 파일들을 보면 binary log가 많이 생성된 것을 알 수 있다.

파일을 rm 명령어로 직접 지우지 말고 mysql 콘솔에서 지우는 것이 바람직하다.

mysql> show binary logs;
+------------------+------------+
| Log_name | File_size |
+------------------+------------+
| mysql-bin.000174 | 1073742003 |
| mysql-bin.000175 | 1073742050 |
| mysql-bin.000176 | 1073741968 |
| mysql-bin.000177 | 1073742039 |
| mysql-bin.000178 | 1073741908 |
| mysql-bin.000179 | 1073742024 |
| mysql-bin.000180 | 1073742027 |
| mysql-bin.000181 | 1073741959 |
| mysql-bin.000182 | 1073741883 |
| mysql-bin.000183 | 1073741988 |
| mysql-bin.000184 | 1073741999 |
| mysql-bin.000185 | 1073741927 |
| mysql-bin.000186 | 1073742098 |
| mysql-bin.000187 | 1073742018 |
| mysql-bin.000188 | 1073742083 |
| mysql-bin.000189 | 349569498 |
+------------------+------------+
16 rows in set (0.00 sec)

mysql 콘솔에서는 위 명령으로 확인 가능.

위 명령어에서 binary 로그 이름을 지정하면 해당 파일 이전의 파일들을 모두 삭제한다.

그리고 binary 로그를 저장할 주기를 설정한다.

시스템 사고가 발생해도 근시일 내에 확인할 수 있거나 특별히 백업해 분석할 것이 아니라면 2일 정도면 충분할 것이다.

출처 : http://whiterussian.tistory.com/entry/binary-log-%EC%A0%95%EB%A6%AC-%EC%82%AD%EC%A0%9C-%EC%A3%BC%EA%B8%B0-%EC%84%A4%EC%A0%95

MySQL 로그 파일 관리 2 - 로그 파일 남기기

JAESOO — Mon, 17 Nov 2014 09:41:39 +0000

MySQL 로그파일

유닉스에서의 에러 로그 : 'hostname'.err
shell>find / -name 'hostname'.err

윈도우에서의 에러 로그 : /mysql/data/mysql.err

리눅스에서 my.cnf파일 만들기 : my-huge.cnf 나 my-medium.cnf 파일을 찾아서
/etc/ 아래에 복사
shell>cp my-medium.cnf /etc/my.cnf

윈도우에서 my.ini 파일 만들기 : /mysql/ 디렉토리 아래에 보면 my-small, my-medium, my-large, my-huge
파일이 존재하는데 이중 1개를 my.ini로 이름을 바꿔서 c:\winnt 아래에 복사.
* windows7에선 C:\ProgramData\MySQL\MySQL Server 5.5\my.ini에 있음

리눅스 my.cnf 파일에 쿼리 로그 사용하게 하기 ([mysqld] 섹션 아래에 설정)

[mysqld]
# MyISAM 로그
log-isam=/usr/local/mysql/data/myisamlog.log
# 쿼리 로그
log=/usr/local/mysql/data/mysql.log
# 수정 로그
log-update=/usr/local/mysql/data/mysql-update.log
# 바이너리 로그
log-bin=/usr/local/mysql/data/mysql-bins.log
# 슬로우 쿼리 로그
log-slow-queries=/usr/local/mysql/data/mysql-slow.log
long_query_time=5

윈도우 my.ini 파일에 쿼리 로그 사용하게 하기 ([mysqld] 섹션 아래에 설정)

[mysqld]
# MyISAM 로그
log-isam
# 쿼리 로그
log=c:/mysql/data/mysql.log
# 수정 로그
log-update=c:/mysql/data/mysql-update.log
# 바이너리 로그
log-bin=c:/mysql/data/mysql-bins.log
# 슬로우 쿼리 로그
log-slow-queries=c:/mysql/data/mysql-slow.log
long_query_time=5

*수정후 mysql 데몬 재실행.

출처 - http://cafe.naver.com/friendvirus.cafe?iframe_url=/ArticleRead.nhn%3Farticleid=27

===================================================================================

PHP를 이용하여 웹 어플리케이션을 작성 할 때 난감한 이슈 중의 하나는 Database query를 찍어보는 것이다.

echo나 print로 로그를 찍게 되면, 화면에 직접 출력되기 때문에 만약 운영중인 웹 어플리케이션이라면 화면 가득 쏟아져 나온 쿼리를 보게 될 것이다.

syslog를 이용하여 쿼리를 시스템 로그 파일에 기록하는 방법도 있겠지만(MySql 쿼리 디버깅을 위한 방법 - syslog 참고), 보다 근본적으로 해결하는 방법이 있다면 그 방법을 써야겠다.

MySql 로그 설정으로 보다 다양하게 찍기

MySql을 설치하면 일반적으로 로그에 대한 설정은 따로 해주지 않는다. 이 때문에 로그를 syslog로 찍어야 하는 방법 밖에 없는, 또는 echo 정도로 로그를 찍어주는 것만 하고 있을지도 모른다.

MySql 설치시에 로그에 대한 설정을 자동으로 해준다면, 더할나위 없겠지만 아쉽게도 수동으로 주석을 풀어줘야 한다.

(순서)
1. /etc/my.cnf 파일을 연다.
2. 로그와 관련된 설정을 심어준다.
3. 저장 후에 MySql을 재시동 한다.

3번 항목 재시동이라는 부분이 마음에 걸리지만, 그래도 한번 적용으로 두고두고 득(得)이 된다.
설정법은 아래와 같다.

# 바이너리 로그 설정
log-bin = bin_logs
# 쿼리 로그 설정
log = query_logs
# 에러 로그 설정
log-error = err_logs
# 느린 쿼리(slow query) 설정
log-slow-queries = slow_logs
# Update 쿼리 설정
log-update = update_logs

5가지의 로그 설정을 해 주면, 각 상황에 맞게 tail -f 파일명 을 이용하여 콘솔로 찍기만 하면 된다.
위에 설정에서 bin_logs, query_logs, err_logs, slow_logs, update_logs는 임의로 지정한 명칭이다. 상황에 맞게 적어주면 된다.

이렇게 지정된 로그의 위치는 mysql/data 폴더 안에 생성된다.
이 위치에서 보면 위에서 설정한 이름으로 파일들이 생성되었음을 확인 할 수 있다.

출처 - http://toriworks.tistory.com/entry/MySql-%EC%BF%BC%EB%A6%AC-%EB%94%94%EB%B2%84%EA%B9%85%EC%9D%84-%EC%9C%84%ED%95%9C-%EB%B0%A9%EB%B2%95-MySql-%EB%A1%9C%EA%B7%B8

출처 : http://linuxism.tistory.com/585

MySQL 로그 파일 관리 1 - 설정

JAESOO — Mon, 17 Nov 2014 09:40:42 +0000

=======================================================

   MySQL 로그 파일 관리

=======================================================

Mysql 의 로그 파일은 다음과 같이 크게 3종류가 있습니다.

1. 에러로그
2. 일반적인 로그
3. UPDATE 로그

첫번째 에러 로그는 hostname.err 의 이름으로 서버 실행시 에러를 기록하는 파일입
니다. 두번째 로그파일은 mysql 에 접근하는 사용자와 그들이 파일과 관련된 쿼리를
실행할 경우에 기록되는 로그 파일로 /usr/local/mysql/var 밑에 host_name.log 으로
저장이 되어집니다. Mysql 데이터에 파일을 기록하므로 파일과 관련된 쿼리는 DB 생
성/삭제 , 테이블 생성/삭제 , 레크드 삽입/갱신 이 있습니다.
이 로그 파일은 Mysql 실행시 --log 옵션을 주어 활성화 시키면 된다.

# /usr/local/mysql/bin/safe_mysqld --log &

업데이터로그는 테이블이 변경될때마다 해당 쿼리가 기록 됩니다. 기본적으로 활성
화 되지 않고 Mysql 실행시 --log-update 옵션으로 가능하다.

# /usr/local/mysql/bin/safe_mysql --log-update &

업데이터 로그는 /usr/local/mysql/var 밑에 host_name.00X 식으로 서버가 다시
실행되거나 mysqladmin reflesh 혹은 mysqladmin flush-logs 명령을 내릴때마다
뒤의 번호가 1씩 증가 한다. 혹은 --log-update=mysql.log 와 같이 로그파일명을
정해줄수도 있다.  Update 로그는 update 쿼리만 저장하거 같지만 ..
delete , create 등의 쿼리도 모두 저장한다.

mysql 의 사용량이 많은 사이트는 이런 로그파일이 쌓이므로 해서 디스크 용량에
문제가 생길수 있다. 관리자는 수시로 점검하여 삭제를 해어야 한다.

로그 파일을 관리하는 방법으로는 두가지가 있다.

먼저 /usr/local/mysql/share/mysql/mysql-log-rotate 파일을 이용하는 방법과
간단한 스크립트를 작성하여 cron 에 등록한뒤 관리하는 방법이 있다.

/usr/local/mysql/share/mysql/mysql-log-rotate 파일을 이용하는 방법은 ..
--log-update=mysqld.log 와 같이 로그파일을 정해서 관리할때 이용하면 된다.

# vi /usr/local/mysql/share/mysql/mysql-log-rotate
-------------------------------------------------------------------------
----
# This logname is set in mysql.server.sh that ends up in /etc/rc.d/init.d/mysql
#
# If the root user has a password you have to create a
# /root/.my.cnf configuration file with the following
# content:
#
# [mysqladmin]
# password = <secret>
# user= root
#
# where "<secret>" is the password.
#
# ATTENTION: This /root/.my.cnf should be readable ONLY
# for root !

/usr/local/mysql/var/mysqld.log {
        # create 600 mysql mysql
        notifempty
    daily
        rotate 3
        missingok
        compress
    postrotate
    # just if mysqld is really running
    if test -n "`ps acx|grep mysqld`"; then
            /usr/local/mysql/bin/mysqladmin flush-logs
    fi
    endscript
}

-------------------------------------------------------------------------
--

위의 파일을 /etc/logrotate.d 디렉토리에 복사만 하면 알아서 로테이트 하게 된다.
단..로그파일을 교체한후 mysqladmin flush-logs 를 적용하므로 root 홈디렉토리에
.my.cnf 파일을 만든후 MySQL 의 root 사용자의 암호와 사용자 명을 적어주어야 한
다.

vi /root/.my.cnf
--------------------------------------
[mysqladmin]
password = xxxxxxxxx
user = root

--------------------------------------

정상적인 로그 교체의 확인은 다음과 같이 하면 된다.

# logrotate -f mysql-log-rotate

이밖에 --log-update 등의 옵션을 이용하면 수시로 로그파일의 뒤에 001,002 씩으로
번호가 증가 되면서 저장이 되므로 별도의 스크립트를 작성하여 관리해야 한다.

이는 각자 머리를 잘 짜면 될거 같다.

#!/bin/sh

find /usr/local/mysql/var -name "*.[0-9]*" -type f -mtime +3 -exec rm -f {} \\;
/usr/local/mysql/bin/mysqladmin flush-logs

위와 같은 만들면 된다. 이는 "3일 지난 파일은 지워라" 로 cron 에 등록한뒤 적절한
시간마다 실행해주면 된다.

출처 - http://blog.syszone.co.kr/707

==================================================================================

4.10. MySQL 로그 파일

MySQL 에는 몇개의 종류의 로그 파일이 있어,mysqld 안에서 무엇이 발생하고 있을까 조사할 수 있습니다.

로그 파일	설명
에러 로그	`mysqld` 의 기동, 실행, 및 정?~ 그리고 발생한 문제.
isam 로그	ISAM 테이블에의 변경이 모두 기록.isam 코드의 디버그에만 사용.
일반 쿼리 로그	접속의 정보와 실행된 쿼리.
갱신 로그	폐?~ .데이터를 변경한 모든 스테이트먼트를 보존.
바이너리 로그	무엇인가를 변경한 모든 스테이트먼트를 보존.replication에도 사용.
슬로우 로그	`long_query_time` 초부터 시간이 걸린 쿼리, 또는 인덱스를 사용하지 않았던 쿼리를 모두 보존.

로그는 모두,mysqld 데이터 디렉토리에 있습니다.mysqld 그리고 로그 파일을 재차 열려면(혹은 새로운 로그로 전환한다) ,FLUSH LOGS (을)를 실행합니다. See 항4.6.4. 「FLUSH 구문」 .

4.10.1. 에러 로그

에러 로그 파일에는,mysqld 의 기동 시각과 정?~ 시각, 및 실행중에 발생한 에러에 관한 정보가 기록됩니다.

mysqld 하지만 이상종료(ABEND) 해 mysqld_safe 하지만 mysqld (을)를 재기동할 필요가 있는 경우,mysqld_safe (은)는 이 파일에 restarted mysqld 행을 씁니다.자동 체크 또는 자동 수복이 필요한 테이블을 mysqld 하지만 찾아냈을 경우, 경고도 기록됩니다.

일부의 operating system에서는,mysqld 하지만 이상종료(ABEND) 한 개소의 스택 트레이스가 에러 로그에 기록됩니다.이것을 사용하면,mysqld 하지만 어느 시점에서 이상종료(ABEND) 했는지 압니다. See 항E.1.4. 「스택 트레이스의 사용」 .

MySQL 4.0.10 이?~ ,mysqld 하지만 에러 로그 파일을 보존하는 장소를 --log-error[=filename] 옵션으로 지정할 수 있게 되어 있습니다.파일명을 지정하지 않으면,mysqld 하 Unix 그럼 mysql-data-dir/'hostname'.err (을)를,Windows 그럼 \mysql\data\mysql.err (을)를 사용합니다. flush logs (을)를 실행하면, 낡은 파일에는 --old 의 프리픽스가 붙어,mysqld 하지만 하늘의 신규 로그 파일을 작성합니다.

구 MySQL 버젼에서는, 에러 로그 처리는 mysqld_safe 에 의해서 행해져 에러 파일은 'hostname'.err 에 리디렉트 됩니다.이 파일명은,--err-log=filename 옵션으로 변경할 수 있습니다.

--log-error (을)를 지정하지 않는 경우, 또는 --console 옵션을 사용했을 경우에는, 에러는 stderr (단말)에 써집니다.

Windows 그럼,--console (을)를 지정하지 않으면, 출력은 항상 .err 파일에 써집니다.

4.10.2. 일반 쿼리 로그

mysqld 안에서 무엇이 발생하고 있을까 확인하고 싶은 경우에는,--log[=file] 옵션을 사용해 mysqld (을)를 기동합니다.이것에 의해, 모든 접속과 쿼리가 로그 파일(디폴트는 'hostname'.log )에 기록됩니다.이 로그는, 클라이언트 측에 에러의 원인이 있다고 생각할 수 있어mysqld 에 대해서 클라이언트가 무엇을 송신했는지 조사할 때 매우 도움이 됩니다.

낡은 버젼(MySQL 3.23.4 (으)로부터 3.23.8 )의 mysql.server 스크립트는,safe_mysqld 에, 일반 쿼리 로그를 유효화한다 --log 옵션을 건네줍니다.실가동 환경에서 MySQL 의 기동시의 퍼포먼스를 향상시킬 필요가 있는 경우에는,--log 옵션을 mysql.server (으)로부터 삭제하는지,--log-bin (으)로 변경합니다. See 항4.10.4. 「바이너리 로그」 .

이 로그의 엔트리는,mysqld 하지만 쿼리를 받은 시점에서 써집니다.이것은, 스테이트먼트가 실행된 순서와는 다른 경우가 있습니다.또, 갱신 로그 및 바이너리 로그와도 대비적입니다.갱신 로그 및 바이너리 로그는, 쿼리가 실행된 후, 락이 해제되기 전에 써집니다.

4.10.3. 갱신 로그

주의: 갱신 로그는 폐?~ 되어 대신에 바이너리 로그가 사용됩니다.See 항4.10.4. 「바이너리 로그」 . 바이너리 로그는, 이전의 갱신 로그의 기능을 모두 갖추어 더해 다른 기능도 추가되고 있습니다.MySQL 5.0 그리고 갱신 로그는 없어집니다 .

mysqld (을)를 --log-update[=file_name] 옵션으로 기동하면, 데이터를 갱신하는 모든 SQL 커멘드가 로그 파일에 기록됩니다.파일명을 지정하지 않으면, 호스트 머신의 이름이 디폴트명이 됩니다.파일명을 지정해, 패스를 지정하지 않는 경우, 파일은 데이터 디렉토리에 작성됩니다.file_name 에 확장자(extension)가 없는 경우,mysqld 하file_name.### 의 형식에서 로그 파일명을 생성합니다.여기서 ### (은)는,mysqladmin refresh ,mysqladmin flush-logs , 및 FLUSH LOGS 스테이트먼트가 실행될 때마다, 및 서버가 재기동할 때마다 인크리먼트(increment) 되는 번호입니다.

주의: 상기 스킴이 유효하기 때문에 , 갱신 로그가 사용하는 디렉토리내에서는, 갱신 로그 + 어떠한 확장자(extension) 등, 번호라고 오인되는 파일명의 파일을 작성 해서는 안됩니다.

--log 옵션 또는 -l 옵션을 사용했을 경우,mysqld 하 hostname.log (이)라는 이름의 일반 로그 파일을 작성합니다.재기동이나 리프레쉬를 실시해도 신규 로그 파일은 생성되지 않습니다(일단 닫고, 재차 열 뿐입니다).이 경우, 이하와 같이 해(Unix 상) 로그 파일을 카피할 수 있습니다.

mv hostname.log hostname-old.log mysqladmin flush-logs cp hostname-old.log to-backup-directory rm hostname-old.log

갱신 로그는, 데이터를 실제로 갱신한 스테이트먼트만을 기록합니다.UPDATE 또는 DELETE 의 WHERE 지정으로 레코드가 발견되지 않았던 경우, 그 스테이트먼트는 로그에 써지지 않습니다.컬럼의 값을, 벌써 있는 같은 값으로 갱신했다 UPDATE 스테이트먼트도 스킵 됩니다.

갱신 로그의 기입은, 쿼리가 완료한 직후에 락의 해제전에, 또는 코?~ 트의 전에 행해집니다.이 때문에, 로그는 실행 순서대로 써집니다.

갱신 로그 파일로부터 데이타베이스를 갱신하려면 , 이하를 실행합니다.여기에서는, 갱신 로그명의 형식을 file_name.### (와)과 가정하고 있습니다.

shell> ls -1 -t -r file_name.[0-9]* | xargs cat | mysql

ls (은)는, 모든 로그 파일을 올바른 순서로 취득하기 위해서 사용합니다.

이것은, 크래쉬 후에 백업파일 상태에까지 되돌린다, 혹은 백업 후부터 크래쉬까지의 사이의 갱신을 반복하는 경우 등에 도움이 됩니다.

4.10.4. 바이너리 로그

바이너리 로그는, 이전의 갱신 로그 대신에 되는 것입니다.갱신 로그는 MySQL 5.0 (이)가 아니게 됩니다.바이너리 로그에는, 갱신 로그로 이용 가능했던 정보가 모두, 보다 효율적 한편 트랜잭션(transaction) 세이프인 방법으로 포함됩니다.

바이너리 로그는 이전의 갱신 로그와 같이, 데이터를 실제로 갱신하는 스테이트먼트만을 기록합니다.UPDATE 또는 DELETE 의 WHERE 지정으로 레코드가 발견되지 않았던 경우, 그 스테이트먼트는 로그에 써지지 않습니다.컬럼의 값을, 벌써 있는 같은 값으로 갱신했다 UPDATE 스테이트먼트도 스킵 됩니다.

바이너리 로그에는, 백업 후의 갱신이 모두 기록됩니다.바이너리 로그의 주된 목적은, restore시에, 데이타베이스에 대해서 가능한 한 백업 후의 갱신을 실행할 수 있도록 하는 것입니다.

바이너리 로그는, 마스터로부터 슬레이브에 replication를 실시할 때도 사용합니다. See 항4.11. 「MySQL 의 replication」 .

바이너리 로그에는, 데이타베이스를 갱신한 각 쿼리에 걸린 시간의 정보도 포함됩니다.데이터를 변경하지 않았던 쿼리는 포함되지 않습니다.문제가 있는 쿼리를 찾아내는 등의 목적으로 모든 쿼리를 기록하고 싶은 경우에는, 일반 쿼리 로그를 사용해 주세요. See 항4.10.2. 「일반 쿼리 로그」 .

mysqld (을)를 --log-bin[=file_name] 옵션으로 기동하면, 데이터를 갱신한 모든 SQL 커멘드가 로그 파일에 기록됩니다.파일명을 지정하지 않으면, 호스트 머신의 이름에 -bin (을)를 붙인 것이 디폴트명이 됩니다.파일명을 지정해, 패스를 지정하고 있지 않는 경우에는, 파일은 데이터 디렉토리에 작성됩니다.

--log-bin=filename.extension 그리고 확장자(extension)를 지정했을 경우, 확장자(extension)는 삭제됩니다.

mysqld (은)는, 바이너리 로그 파일명에 숫자의 확장자(extension)를 추가합니다.이 번호는,mysqladmin refresh ,mysqladmin flush-logs , 및 FLUSH LOGS 스테이트먼트가 실행될 때마다, 또는 서버가 재기동할 때마다 인크리먼트(increment) 됩니다.바이너리 로그의 사이즈가 max_binlog_size 에 이르면, 새로운 바이너리 로그가 자동적으로 작성됩니다.주의: 트랜잭션(transaction)를 사용하고 있는 경우, 트랜잭션(transaction)는 1 개의 정리로 바이너리 로그에 써지기 위해, 복수의 바이너리 로그에 분할될 것은 없습니다.따라서, 큰 트랜잭션(transaction)가 있는 경우, 바이너리 로그가 max_binlog_size 보다 커질 가능성이 있습니다.

모든 바이너리 로그 파일을 삭제하려면 ,RESET MASTER 커멘드(see 항4.6.5. 「RESET 구문」 )(을)를 사용합니다.일부의 파일을 삭제하려면 ,PURGE MASTER LOGS (see항4.11.7. 「마스터 서버를 제어한다 SQL 스테이트먼트」 )(을)를 사용합니다.

mysqld 그리고 이하의 옵션을 사용해, 무엇을 바이너리 로그에 기록할까 제어할 수 있습니다(겉(표)의 뒤의 설명을 반드시 읽어 주세요).

옵션	설명
`binlog-do-db=database_name`	경향 데이타베이스(`USE` 에 의해서 선택된 데이타베이스)가 'database_name' 의 경우, 갱신을 바이너리 로그에 기록하도록(듯이) 마스터에 지시한다.그 이외의 명시적으로 지정되어 있지 않은 데이타베이스는 모두 무시한다.주의: 경향 데이타베이스내에서만 갱신을 실시하는 것이 확실한 경우에, 이 옵션을 사용하는 것(예: `binlog-do-db=some_database` ). 예상하기 힘든 동작예: 서버를 `binlog-do-db=sales` 그리고 기동해,`USE prices; UPDATE sales.january SET amount=amount+1000;` (을)를 실행했을 경우, 이 쿼리는 바이너리 로그에는 써지지 않다.
`binlog-ignore-db=database_name`	경향 데이타베이스(`USE` 에 의해서 선택된 데이타베이스)가 'database_name' 의 경우, 갱신을 바이너리 로그에 기록하지 않게 마스터에 지시한다.주의: 경향 데이타베이스내에서만 갱신을 실시하는 것이 확실한 경우에, 이 옵션을 사용하는 것(예: `binlog-ignore-db=some_database` ). 예상하기 힘든 동작예: 서버를 `binlog-ignore-db=sales` 그리고 기동해,`USE prices; UPDATE sales.january SET amount=amount+1000;` (을)를 실행했을 경우, 이 쿼리는 바이너리 로그에 써진다.

쿼리를 바이너리 로그에 쓸지의 평가는, 이하의 순서로 행해집니다.

binlog-do-db 룰 또는 binlog-ignore-db 룰이 있을까.
- No: 쿼리를 바이너리 로그에 써 종료한다.
- Yes: 다음의 스텝으로 옮긴다.
룰(binlog-do-db 또는 binlog-ignore-db , 혹은 그 양쪽 모두)가 존재한다.경향 데이타베이스가 있을까(USE 하지만 선택하고 있는 데이타베이스가 있을까).
- No: 쿼리를 쓰지 마 종료한다.
- Yes: 다음의 스텝으로 옮긴다.
경향 데이타베이스가 있다.binlog-do-db 룰은 있을까.
- Yes: 경향 데이타베이스가 binlog-do-db 룰의 어느 쪽인가에 일치하고 있을까.
  - Yes: 쿼리를 써 종료한다.
  - No: 쿼리를 쓰지 마 종료한다.
- No: 다음의 스텝으로 옮긴다.
binlog-ignore-db 룰이 존재한다. 경향 데이타베이스가 binlog-ignore-db 룰의 어느 쪽인가에 일치하고 있을까.
- Yes: 쿼리를 쓰지 말고 종료한다.
- No: 쿼리를 써 종료한다.

따라서, 예를 들어 binlog-do-db=sales 만으로 실행중의 슬레이브는, 경향 데이타베이스가 sales (이)가 아닌 쿼리를 일절 바이너리 로그에 쓰지 않습니다(즉,binlog-do-db 하 `` 다른 데이타베이스를 무시한다'' 그렇다고 하게도 됩니다).

어느 바이너리 로그 파일이 사용되었는지 알도록(듯이),mysqld (은)는 바이너리 로그인 덱스 파일도 작성합니다.이 파일에, 사용된 바이너리 로그 파일 모든 이름이 포함됩니다.디폴트에서는, 이 파일의 이름은 바이너리 로그 파일명에 확장자(extension) '.index' (을)를 붙인 것이 됩니다. 바이너리 로그인 덱스 파일의 이름을 변경하려면 ,--log-bin-index=[filename] 옵션을 사용합니다. mysqld 의 실행중은, 이 파일을 수동으로 편집하지 말아 주세요.mysqld 하지만 혼란하는 원인이 됩니다.

replication를 사용하고 있는 경우, 슬레이브가 필요로 하고 있는 동안은, 낡은 바이너리 로그 파일을 삭제하지 말아 주세요. 예를 들어,mysqladmin flush-logs (을)를 매일 실행하는 경우,3 일 경과한 로그를 모두 삭제하도록(듯이) 합니다.이러한 로그는 수동으로 삭제할 수도 있습니다만, 바이너리 로그인 덱스 파일도 안전하게 갱신할 수 있다 PURGE MASTER LOGS (see 항4.11.7. 「마스터 서버를 제어한다 SQL 스테이트먼트」 )(을)를 사용해 삭제하는 것을 추천 합니다.이 커멘드는,MySQL 4.1 (으)로부터 일자 인수를 지정할 수 있게 되어 있습니다.

SUPER 권한으로의 접속에서는,SET SQL_LOG_BIN=0 (을)를 사용하고, 쿼리의 바이너리 로그를 무효로 할 수 있습니다. See 항4.11.7. 「마스터 서버를 제어한다 SQL 스테이트먼트」 .

바이너리 로그 파일을 조사하려면 ,mysqlbinlog 유틸리티를 사용합니다. 예를 들어, 이하와 같이 바이너리 로그로부터 MySQL 서버를 갱신할 수 있습니다.

shell> mysqlbinlog log-file | mysql -h server_name

mysqlbinlog 유틸리티 및 그 사용법에 관한 상세한 것에 대하여는, 항4.9.5. 「mysqlbinlog (바이너리 로그로부터 쿼리를 실행한다)」 (을)를 참조해 주세요.

BEGIN [WORK] 또는 SET AUTOCOMMIT=0 (을)를 사용하고 있는 경우는, 이전의 갱신 로그는 아니고 MySQL 바이너리 로그를 백업용으로 사용해 주세요.갱신 로그는 MySQL 5.0 (이)가 아니게 됩니다.

바이너리 로그의 기입은, 쿼리가 완료한 직후에 락의 해제전에, 또는 코?~ 트의 전에 행해집니다.이 때문에, 로그는 실행 순서대로 써집니다.

비트랜잭션(transaction) 테이블의 갱신은 실행 직후에 바이너리 로그에 보존됩니다.BDB 테이블이나 InnoDB 테이블등의 트랜잭션(transaction) 테이블에서는, 테이블을 변경하는 모든 갱신(UPDATE ,DELETE , 또는 INSERT )(은)는,COMMIT 커멘드가 서버에 송신될 때까지 캐쉬됩니다.mysqld (은)는,COMMIT 하지만 실행되기 전에 트랜잭션(transaction) 전체를 바이너리 로그에 씁니다. 모든 스레드가, 최초로, 쿼리를 버퍼 한다 binlog_cache_size 의 버퍼를 할당합니다.쿼리가 이것보다 큰 경우, 스레드는 임시 파일을 열어 트랜잭션(transaction)를 보존합니다.스레드가 종료하면 임시 파일은 삭제됩니다.

max_binlog_cache_size (디폴트는 4G )(을)를 사용하고, 복수 쿼리 트랜잭션(transaction)의 캐쉬에 사용하는 토탈 사이즈를 제한할 수 있습니다.트랜잭션(transaction)가 이것보다 큰 경우, 에러가 되어 롤백(rollback) 합니다.

갱신 로그 또는 바이너리 로그를 사용하고 있는 경우에,CREATE ... SELECT 또는 INSERT ... SELECT (을)를 사용하면, 동시 삽입이 통상의 삽입에 변환됩니다. 이것은, 백업에 로그를 적용했을 때에, 테이블의 정확한 카피를 작성하기 위한 조치입니다.

4.10.5. 슬로우 쿼리 로그

mysqld (을)를 --log-slow-queries[=file_name] 옵션으로 기동하면, 실행에 long_query_time 초보다 길게 걸렸다 SQL 커멘드가 모두 로그 파일에 써집니다.최초의 테이블 락에 걸린 시간은 실행 시간에 포함되지 않습니다.

슬로우 쿼리 로그는, 쿼리 실행 후, 모든 락이 해제된 후에 써집니다.이것은, 스테이트먼트가 실행된 순서와는 다른 경우가 있습니다.

파일명을 지정하지 않으면, 호스트 머신의 이름에 -slow.log (을)를 붙인 것이 디폴트명이 됩니다.파일명을 지정해, 패스를 지정하지 않는 경우, 파일은 데이터 디렉토리에 작성됩니다.

슬로우 쿼리 로그는, 실행에 시간이 걸려, 최적화의 대상이 되는 쿼리를 찾아내기 위해서 사용할 수 있습니다.큰 로그에서는, 이것은 어려운 작업이 됩니다.mysqldumpslow 커멘드를 사용하면, 로그의 쿼리 요약을 취득할 수 있습니다.

--log-long-format (을)를 사용하면, 인덱스를 사용하지 않았던 쿼리도 출력됩니다. See 항4.1.1. 「mysqld 커멘드 라인 옵션」 .

4.10.6. 로그 파일의 보수

MySQL 서버에서는 몇개의 종류의 로그 파일이 생성되어 실행 내용을 간단하게 확인할 수 있습니다.See 항4.10. 「MySQL 로그 파일」 . 다만, 로그가 디스크 영역을 점유 너무 하지 않게 이러한 파일을 정기적으로 클린 업 할 필요가 있습니다.

MySQL (을)를 로그 파일과 함께 사용하는 경우, 정기적으로 낡은 파일을 삭제 또는 백업 해, 새로운 파일로 로그를 개시하도록 해 주세요. See 항4.5.1. 「데이타베이스의 백업」 .

Linux (Red Hat ) 인스톨에서는,mysql-log-rotate 스크립트를 사용하고, 낡은 로그 파일의 처리를 자동적으로 실시할 수 있습니다.RPM 디스트리뷰션으로부터 MySQL (을)를 인스톨 하고 있으면, 이 스크립트는 자동적으로 인스톨 되고 있을 것입니다.주의: replication용으로 바이너리 로그를 사용하고 있는 경우, 이 스크립트의 사용에는 주의가 필요합니다.

다른 시스템에서는, 로그 파일을 처리하기 위한 짧은 스크립트를 스스로 인스톨 할 필요가 있습니다.이 스크립트는,cron (으)로부터 개시합니다.

새로운 로그 파일의 사용을 MySQL 에 강제하려면 ,mysqladmin flush-logs (을)를 사용하는지,SQL 커멘드 FLUSH LOGS (을)를 사용합니다. MySQL 버젼 3.21 (을)를 사용하고 있는 경우,mysqladmin refresh (을)를 사용할 필요가 있습니다.

상기 커멘드는 이하를 실행합니다.

일반 로그(--log ) 또는 슬로우 쿼리 로그(--log-slow-queries )(이)가 사용되고 있는 경우, 로그 파일(디폴트에서는 mysql.log (와)과 `hostname`-slow.log )(을)를 닫아 다시 연다.
갱신 로그(--log-update )(이)가 사용되고 있는 경우, 갱신 로그를 닫고,1 개번호가 큰 신규 로그 파일을 연다.

갱신 로그만을 사용하고 있는 경우는, 로그를 플래시 하고, 낡은 갱신 로그 파일을 백업으로 이동하는 것만으로 끝납니다. 통상의 로그를 사용하고 있는 경우는, 이하와 같이 실시합니다.

shell> cd mysql-data-directory shell> mv mysql.log mysql.old shell> mysqladmin flush-logs

다음에, 백업을 작성해,mysql.old (을)를 삭제합니다.

출처 - http://itcenter.happyrising.com/core/MySQL_4.1_Korean/MySQL_4.1_Korean/ch04s10.html

출처 : http://linuxism.tistory.com/518

MySQL Binary Log 지우는 방법

JAESOO — Mon, 17 Nov 2014 09:39:20 +0000

MySQL Binary Log 는 add, delete, insert, update 등의 query 가 저장되어 있는 파일로서 MySQL 을 설치하게 되면 기본적으로 MySQL Binary Log 가 생성됩니다.
Binary Log 를 쌓지 않아도 되는 MySQL 구동 환경에서는 Binary Log 를 삭제하므로, 디스크 공간
여유 공간을 확보할 수 있는데, MySQL Binary Log 를 지우는 방법에 대해서 알아보겠습니다.

1. MySQL Replication 환경에서 지우기

- MySQL Replication MASTER 서버
shell> mysql -u root -p
mysql> RESET MASTER;

- MySQL Replication SLAVE 서버
shell> mysql -u root -p
mysql> RESET MASTER;

2. MySQL Binary Log sequence number 또는 특정 일자로 지우기

shell> mysql -u root -p
mysql> PURGE BINARY LOGS TO 'mysql-bin.000015';
shell> mysql -u root -p
mysql> PURGE BINARY LOGS BEFORE '2009-05-01 00:00:00';

3. mysqladmin flush-logs 명령어를 통해서 MySQL Binary Log 지우기

shell> mysqladmin -u root -p flush-logs

4. MySQL Binary Log 생성을 방지하는 방법

/etc/my.cnf 파일에서 아래 라인을 주석 처리
log-bin

5. MySQL Binary Log 를 특정 1주일까지만 생성 및 보관하기
/etc/my.cnf 파일에서 아래 라인을 추가
expire_logs_days = 7

출처 : http://faq.hostway.co.kr/Linux_DB/1307

MySQL 설치/사용시 발생 에러 유형별 대처방법

JAESOO — Mon, 17 Nov 2014 09:38:29 +0000

1. ./configure 시에 에러
증상1

checking for tgetent in -lncurses... no
checking for tgetent in -lcurses... no
checking for tgetent in -ltermcap... no
checking for termcap functions library... configure: error: No curses/termcap library found
[root@localhost mysql-4.0.13]# make
make: *** No targets specified and no makefile found. stop.

Q1 : 왜 이런 메세지가 뜨냐?

A1: gcc가 없던지 PATH가 안잡혀 있는 경우

Q2 : configure: error: no acceptable C compiler found in $PATH
설치를 잘못 한건가?
[root@localhost mysql-4.0.13]make 실행 시
make: *** No targets specified and no makefile found. 멈춤.
메세지 뜨는데 어케?

A2 : 리눅스에 gcc가 설치됐는지 확인하라.
# rpm -qa| grep gcc

2. 소스 설치시 "NOTE: This is a MySQL binary distribution." 라는 메시지의 경우
Q : It's ready to run, you don't need to configure it! 나옵니다. 이유가?

A : 컴파일이 필요없는 바이너리를 받은거 같다. 이미 컴파일한 거다.
압축풀고 적당한 위치로 이동시켜라.

tar zxvf mysql-xx.xx.tar.gz
mv mysql-xx.xx /usr/local/
ln -s /usr/local/mysqlxx.xx /usr/local/mysql

3. mysql을 실행하면 (2)번 에러
Q : ERROR 2002: Can't connect to local MySQL server through socket '/var/lib/mysql/m
ysql.sock' (2) 무슨 에러인지요?

A : 데몬 구동시 ./safe_mysqld --user=mysql & 실행 시켜보라.
그래도 에러가 날 경우 ln -s /tmp/mysql.sock /var/lib/mysql/mysql.sock 해보라.

4. mysql.sock 중에 (40)번에러
Q : ERROR 2002: Can't connect to local MySQL server through socket '/var/lib/mysql/m
ysql.sock' (40)

A : chown mysql.mysql -R /var/lib/mysql 를 하기 바란다.
그리고 참고로 php에서의 mysql socket 은 /etc/php.ini 에서 경로를 수정할 수 있다.

5. mysql 데몬이 죽어버릴때
Q : # ./mysqld_safe &
chown mysql .. <-- 비슷한 오류가 뜨면서 데몬이 죽어버린다.어케?

A : 레드햇 리눅스라면 groupadd 와 useradd 에 '-r' 옵션을 사용하라.
# useradd -r -d /usr/local/mysql mysql
이렇게 하면 500 보다 작은 UID, GID를 가진 mysql 그룹과 사용자가 생성된다.

6. mysql 실행시 데몬 바로 죽음
Q :

030527 22:33:39 mysqld started
030527 22:33:39 Can't start server: Bind on TCP/IP port: 주소가 이미 사용 중

030527 22:33:39 Do you already have another mysqld server running on port: 3306 ?
030527 22:33:39 Aborting
030527 22:39:50 /usr/local/mysql/libexec/mysqld: Shutdown 이 완료됨!
030527 22:39:50 mysqld ended

A : 3306 포트에 이미 다른 mysqld 가 실행되고 있다.
# vi /mysql/scripts/mysql_config 을 열어서 포트번호 수정.

7. mysql-4.0.12 설치후 데몬이 안띄워지고 바로 죽을 경우.
Q 정상적으로 소스 설치하고 나서,,
/usr/local/mysql/bin/mysqld_safe & 실행하면,,, 데몬이 시작하자 마자 바로 죽는다.
./safe_mysqld Starting mysqld daemon with databases from /usr/local/mysql/var
mysqld ended
에러 메세지를 보기 위해 /usr/local/mysql/var 로 이동 vinnylover.err 파일을 열어보니

아래와 같은 메세지가 있더군.
mysqld started
InnoDB: Started
Fetal error: Can't open privilege tables: Can't find file: ' ./mysql/host.frm'(errno: 13)'
Aborting

A : mysql_install_db 스크립트를 실행해서 초기 테이블을 생성.
# ./mysql_install_db 하면 된다. (/usr/local/mysql/bin 아래에서 하라)

8. mysql sock 에러 문제의 확실한 해결법
Q : 접속하면 >/var/lib/mysql/mysql.sock ... (111)

A : 디렉토리 퍼미션 문제
# killall mysqld
# chmod 755 -R /var/lib/mysql
# chown mysql.mysql -R /var/lib/mysql
# mysqld_safe --language=korean &

9. make 명령어를 실행하면 설치가 해제

Q : make[2]: *** No rule to make target `ctype-euc_kr.lo', needed by `bmove_upp.lo'. 멈춤.
make[2]: 나감 `/usr/local/down/mysql-3.23.38/libmysql' 디렉토리
make[1]: *** [all-recursive] 오류 1
make[1]: 나감 `/usr/local/down/mysql-3.23.38' 디렉토리
make: *** [all-recursive-am] 오류 2

A : 먼저 LD_LIBRARY_PATH에 모든 라이브러리 경로가 들어가 있어야 한다.
이런 경우때문에 필요한 라이브러리를 찾지못해 에러가 발생.
거의 필요한 패키지를 설치했는데도 에러가 나면 LD_LIBRARY_PATH를 확인해볼 필요가 있다.

10. mysql 설치시 gcc에러나는데 해결책

Q :

# ./configure --prefix=/usr/local/mysql --with-charset=euc_kr
checking for c++... c++
checking whether the C++ compiler (c++ ) works... no
configure: error: installation or configuration problem: C++ compiler cannot create executables.

A : rpm으로 찾아서 다 설치하고 나서 컴파일 하면 된다.
rpmfind.net에서 찾으실 수 있습니다. 에러 보고 하나하나 다 설치하면 된다.

11. 인스톨 설치도중 103 에러
Q : an error occured move data process: -103
compenent : server

A : mysql 설치된 폴더를 완전시 삭제 후 재설치

12. mysql설치 시 invalid user 오류

Q : chown: mysql: invalid user
Starting mysqld daemon with databases from /usr/local/mysql/data
030417 11:42:35 mysqld ended

A : mysql 이란 유져가 유효하지 않다라는 에러로써 현재 mysql이란 계정이 존재하지 않기때문에 나는 에러

# /usr/sbin/useradd mysql -M -s /bin/false

# chown -R root /usr/local/mysql
# chown -R mysql /usr/local/mysql/var
# chgrp -R mysql /usr/local/mysql

13. mysql 4.0.12 설치 시 "Check your system clock" 오류
Q

# ./configure --prefix=/usr/local/mysql --with-charset=euc_kr
이렇게 했는데 다음과 같은 메세지의 경우....
checking build system type... i686-pc-linux
checking host system type... i686-pc-linux
checking target system type... i686-pc-linux
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... configure: error: newly created file is older than distributed files!
Check your system clock

A : mysql이 개발된 시간보다 현재시간 차이로 생기는 문제
인터넷(네트웍)이 되는 상황이라면
# date

# rdate -s time.bora.net => rdate -s time.nuri.net와 같이 다른서버로 해도 된다.

# date

14. 설치시 configure: error: no acceptable cc found in $PATH 에러
Q :

configure: error: no acceptable cc found in $PATH

A : cc 즉 c complier 가 없다
c 컴파일러가 PATH에 안잡혀 있을 수 있다. path를 추가하거나 gcc를 재설치

# vi /etc/profile

PATH=$PATH:.:/usr/local/mysql/bin

15. config시 ERROR: 1062 Duplicate entry 'localhost-root' for key 1
Q : mysql 소스설치 config시 에러의 경우

rpm버전 삭제했는데 데몬이 살아 있나? ps -ax | grep mysql 하면 암것도 안나온다.
ERROR: 1062 Duplicate entry 'localhost-root' for key 1
ERROR: 1062 Duplicate entry 'localhost-root' for key 1
030312 14:58:03 ./bin/mysqld: Shutdown Complete

A : 캐시에 이전데몬이 살아있기 때문이다.
kill 또는 killall 명령으로 프로세스를 완전히 죽이고 설치하라

16. configure 에러로 "error : No curses/termcap library found" 에러?
Q : checking for termcap functions library...
configure: error : No curses/termcap library found

A : libtermcap-devel-xxx 패키지가 필요해서 발생하는 에러
설치시디를 넣으시고 설치를 하면 해결된다.

출처 : http://blog.naver.com/vinnylover/70014275743

Mysql 데이터 폴더의 mysql-bin.xxx 파일들 관련 삭제 및 초기화 방법

JAESOO — Mon, 17 Nov 2014 09:35:42 +0000

# binary logging - not required for slaves, but recommended
log-bin=mysql-bin

바이너리 로그 파일로서 위 log-bin부분을 주석처리해주면된다.

생성되었던 mysql-bin.00001등의 로그파일들은 한번에 삭제해주면되며,

mysql-bin.index 파일이 해당 파일들을 관장하기 때문에 함께 지워주고 mysql을 리붓해주면 된다.

# cd /var/lib/mysql
# rm -rf mysql-bin.*
# service mysqld restart

출처 : http://www.welog.co.kr/gbbs/bbs/board.php?bo_table=mysql&wr_id=142

기가비트 네트웍 구축의 허와 실에 대하여 - Gigabit Network

JAESOO — Fri, 14 Nov 2014 13:25:03 +0000

요즘 기가비트 네트웍을 구축하고자 하는분들이 많아졌음에도 불구하고

인터넷상에 잘못된 정보가 너무 떠돌아다녀 실제 사용중인 입장에서 몇가지 내용을 알려드릴려고합니다.

1. 기가비트 사용에 필수적으로 필요한 장비

a. 기가비트 스위칭 허브 or 기가비트 지원공유기 (Gigabyte switch hub or gigabyte ip sharing router)

! 보통 댓글들을 보면 기가비트 공유기나 허브를 사용하는 분들이 보여준 시스템과 속도차이가 너무 난다는 댓글들이 달리는 모습을 자주보는데, 댓글 다신분들의 네트웍 장비가 기가비트를 지원하지 않는 상황인경우가 대부분입니다. 기가비트를 쓸려면 기가비트 지원 공유기 혹은 기가비트 허브가 필요한데, 기가비트 지원하는 제품은 손에꼽을정도고 가격대도 다른 공유기에 비해 월등합니다. 아무튼 이사항에서 핵심은 기가비트로 쓰실려면 기가비트 지원 공유기나 기가비트 스위칭허브가 물리적으로! 필요 하다는점 입니다.

b. CAT.6 이상의 랜케이블 (network Cable level of CAT.6)

랜케이블도 교체안하시는분들 많던데, 저도 서버 구입시에 넣어준 케이블로 사용할려고 했는데 이놈의 속도가 딱 100Mbps급밖에 안나와 급히 CAT.6 케이블을 구매하여 연결하였더니 정상적으로 나옵니다. 수작업으로 만들어진 CAT.5E 케이블은 기가비트를 지원하는 경우가 꽤있어서 그냥 쓸려다가 완전 낭패를 본것입니다. 7까지는 일반사용자는 크게 필요없고 6이 적당합니다. 쉴드가 있는 고급케이블도 굳이 필요하진 않습니다. 100Mbps 급 인 CAT.5e 케이블이 1000Mbps로 연결 가능경우는 8가닥의 선이 모두 연결되어 있는 경우 뿐입니다. 실제로 4가닥만 연결해놧다거나, 다른 선끼리 (활요하는 라인제외하고)연결되어버렸다면 100Mbps 속도 밖에 낼 수 없습니다. 더군다나 보증속도도 아닌것이죠.

c.기가비트 지원 카드 (내장형/외장형) Gigabyte PHY(card)

당연한 이야기지만 기가비트를 지원하는 카드가 필요합니다. 데스크톱 컴퓨터의경우에는 대부분 메인보드가 기가비트 네트웍을 채용하고 있지만, 노트북의 경우 기가비트를 채용하지 않은경우가 상당수 있으니 유선으로 파일 전송하실분들은 구매전에 필수적으로 체크하셔야됩니다. 왜냐하면 노트북은 확장성도 데스크탑보다 떨어지기 때문에, 카드를 추가로 사야되어 지출이 늘어나고 안그래도 확장성 부족한 노트북/넷북에 유일무이한(거의 그렇습니다)확장슬롯을 고작 랜따위(!)에 헌납해야되기 때문이죠. 혹시 외장형 생각하시는분중에 USB2.0으로된 기가비트 랜카드 생각하시는분이 있다면 숙고해보시라고 당부드리는 바입니다. USB속도 자체가 이론적으로 480Mbps이니 기가비트 절반밖에안됩니다. 외장하드 써보셧으면 아시겠지만 초당전송속도도 20메가 바이트 근처를 머물죠. 100Mbps급 네트웍의 딱 두배수준이 나옵니다.

d. 중급 사양이상의 컴퓨터. (middle range preformance computer)

자주 무시되는 필요 사용중하나인데. 중급이라 함은 최소 프레스캇 셀러론급 이상에 램 1기가 이상입니다. 1Gbps의 네트웍이라는 것은 생각보다 데이터 처리량이 어마어마 하기 때문에 고성능의 컴퓨터가 필요합니다. E5200에서도 1기가로 전송시키면 점유율이 2~30%까지 올라갑니다 ( 속도가 빠를수록 점유율이 증가함), 밑에서 말씀드리겠지만 점보프레임이라는것도 이런 저사양컴퓨터에서 어느정도 속도회복을 위한 기술이지, 실제로 빠른 컴퓨터에는 하나마나... 때로는 설정시에 전송속도가 하락할 수 도 있습니다.

C. 여유공간이 넉넉한 하드 (free space Of HDD)

이론적으론 1Gbps 면 전송속도가 122,070kB/s(약 120MB/s)에 이릅니다. 에러검출이나 이런저런 내용을 데이터를빼도 100MB/s정도는 나올 수 있다는 소리죠. 물론 이론적으로 그렇다는 겁니다. 보통 피시에는 SSD가 달려 있지않기 때문에 HDD가 성능의 발목을 잡게 됩니다. 특히 여유공간이 많은 하드일 수 록 전송속도는 빨라집니다. 여유공간이 적은하드는 느려지는 구조죠. 7200rpm 정도면 어느정도 성능은 유지할 수 있고 5400rpm하드도 밀도가 높은 모델들이면 크게 나쁘지 않고 속도도 7200rpm 제품에 근접하게 나옵니다.

2. 기가비트 네트웍에 관한 오해

a. 점보프레임은 무조건 설정해야한다?

점보프레임을 무조건 설정해야 하지는 않습니다. 기본 값으로 두어도 네트웍에 구성요소들이 적절하다면 최상의 속도를 보여줍니다. 느린컴퓨터 있수록 효과가 있지만, 모든 장비가 해당 점보 프레임을 지원해야합니다. 단순히 점보프레임을 지원하는것 뿐만아니라 단위 특히 최대 점보프레임 지원단위도 일치해야 효과를 볼 수 있습니다.

b. 비싼장비가 필요하다?

비싼장비라는 기준에 따라 다르겠습니다만, 최근에는 기가비트 공유기도 10만원 언더로 나온지 꽤 되었습니다. 오히려 단순 스위칭 허브 가격이 상대적으로 비싸게 보일정도입니다. CAT6 케이블 가격도 5e케이블과 크게 차이가 없습니다.

c. 속도가 오르락 내리락합니다.

이건 당연한것입니다. HDD에 내장된 데이터에 대한 접근속도는 실제 기록된 섹터의 위치에 따라 편차가 큽니다. 같은 파일이라도 초당 100MB/s 나올수도 있고 20MB/s 정도 나올 수 도 있는것입니다. 바깥쪽에 배치된 데이터를 전송시켜놓고 기가비트 속도가 안나온다고 하시는 분들을 보면 난감하거든요. 최대의 속도를 보실려면 HDD Raid 0 으로 두개묶으시거나 SSD를 도입하시는게 최상입니다.

3. 기가바이트 네트웍을 구축하기 전에 궁금하셨던것들

a. 실제 속도는 어떻게 나오나요?

100Mbps급 네트웍에 비해서는 환상적입니다. 파일크기가 어느정도 되면 느려도 보통 30MB/s 정도 나오고, 새로 구입한 하드라면 100MB/s 가까이 나오기도 합니다. 100Mbps급에서는 11MB/s정도가 한계치죠.

b. 1Gbps도 업다운스트림이 별도인가요?

제가 알고 있기로는 별도입니다. 2채널 인거죠. 아니라면 댓글주시면 수정하겠습니다.

c. 기가비트를 지원하는 NAS를 삿는데 너무느려요. 기가비트 구성이 잘못된거 아닐까요?

NAS의 경우 embeded 제품이 많은데 기가비트에서 제대로된 속도로 쓰실려면 고급제품을 사셔야합니다. 싸고 빠르고 용량큰 NAS는 없습니다. 가끔 궁합문제로 느린경우도 있지만, 확률이 낮습니다.

d. 외부에서 쓰는데 굳이 필요 있을까요?

내부 네트웍에서 대규모 파일전송이 필요 없으시다면 굳이 필요하진 않습니다.

출처 : http://fmri.tistory.com/231

NAS, SAN, DAS, ISCSI

JAESOO — Fri, 14 Nov 2014 13:19:57 +0000

흔히 네트워크 접속 스토리지라고 번역되기도 하던 NAS(Network Attached Stoage)는 이제는 더 이상 자세한 소개가 없어도 될 만큼 오늘날 스토리지 시장에서 널리 사용되고 있으며, 이에 대비되는 개념으로 소개되던 SAN(Storage Area Network) 역시 많은 IT 산업 종사자들에게 익숙해진 개념이며 시장에도 널리 보급되어 있다. 이제 더 이상 NAS와 SAN에 관한 개념을 단순하게 소개하고 비교하는 것은 오히려 스토리지 시장의 큰 흐름인 ‘스토리지 네트워킹’을 제대로 이해하는데 큰 도움을 주지 못할 뿐만 아니라 때론 혼란만 야기시킬 뿐이다. 한국IBM 스토리지 사업부의 협조로 스토리지 네트워크 시대를 조망해 본다. <편집자>

이제 NAS와 SAN은 NAS의 뛰어난 O/S를 이용해 네트워크상의 유저들을 SAN 스토리지에 직접 접근할 수 있게 해주는 ‘게이트웨이’ 기술로 연결되고 있으며 iSCSI라는 신기술에 의해 그 경계가 무너지며 급속히 연계되고 있다. iSCSI기술은 기존의 랜 IP 네트워크상에서 SCSI 스토리지 프로토콜을 이용해 SAN과 NAS 두 기술이 주는 장점들을 적극 활용해 주는 제 3의 스토리지 네트워킹 기술이다.

SNA·NAS 경계 무너져
그동안 스토리지 시장에서 NAS와 SAN을 서로 대결하고 어느 한 쪽을 극복해야 하는 기술로 보던 시각이 있었다. 이는 각각의 기술을 어떻게 활용해야 하는가에 대한 정확한 이해가 부족했기 때문이라 여겨진다. 결국 두 기술 모두 ‘스토리지’와 ‘네트워크’라는 공통된 두 단어를 포함한다. 이런 기술들이 개발된 원인을 거슬러 올라가 보면 결국 오픈 시스템 시대에서 수많은 이기종 서버들을 어떻게 스토리지와 연결시켜 통합해서 사용할 것인가에서 시작되었음을 알 수 있다. 이미 사용중인 랜을 활용해서 쉽게 스토리지를 구축하려 한 기술이 NAS, 새로 고안된 파이버채널 네트워크를 사용해서 스토리지를 구축하려 한 기술이 SAN인 것이다. 결국 NAS와 SAN은 네트워크를 어떻게 구축할 것인가라는 효율적인 네트워크 구축이라는 시각에서 조명되야 하며 이는 어느 한 쪽을 극복해야 하는 대립적 개념이 아닌 고객의 용도와 네트워크 사이즈, 사용하는 애플리케이션의 종류와 예산 등 고객의 다양한 현실을 고려해 적절히 조율하려는 상호보완적 개념으로 파악되어야 한다.

고객의 비즈니스 환경이 요구하는 최적의 스토리지 솔루션을 도입해서 고객의 이익을 극대화해주는 스토리지 네트워크를 구성하려는 시각으로 SAN과 NAS, 나아가서 iSCSI를 접근하고 이해하려 할 때 비로소 스토리지 네트워킹 시대를 제대로 파악하고 적극적인 대안을 제시할 수 있다.

각 아키텍처마다 장단점 존재
다양한 고객 환경에 적합한 스토리지 네트워크 아키텍처를 결정하기 위해서는 다음과 같은 기존의 스토리지 아키텍처의 장점과 단점 및 차이점들을 정확히 파악해야 한다.

● DAS(Directly Attached Storage, Direct Access Storage)
● NAS(Network Attached Storage)
● SAN(Storage Area Network)
● iSCSI(Internet Small Computer Systems Interface)

DAS는 스토리지의 전형이며 원조로서 시스템에 직접 연결된 스토리지를 가리키며 다른 시스템과의 데이터 공유는 기대되지 않던 지난 시대를 지배해온 아키텍처다. 네트워크 스토리지에 의해 점차 대체되어 가고 있지만 아직 적은 용량에 데이터 공유가 필요 없는 고객에게는 저렴한 스토리지 솔루션이며 엔터프라이즈급 스토리지 기술 발달로 장차 SAN으로 업그레이드 할 수 있는 SAN-Ready형 대형 스토리지에 지금도 적용되고 있다.

서버와 스토리지를 직접 연결한 DAS에 가장 많이 사용되는 미디어는 스카시 (SCSI, Small Computer Systems Interface), 파이버채널(Fibre Channel), SSA(Serial Storage Architecture) 등 3가지가 있으며 3가지 미디어 모두 블록 I/O 프로토콜(Block In/Out Protocol)을 사용한다.

블록 I/O의 특징은 읽고 쓰기 I/O (Read & Write In/Out) 커맨드가 디스크나 테이프 드라이브 같은 특정 스토리지 장치와 그 저장위치를 정확히 지정해 준다는 것이다. 예를 들어 디스크의 경우라면 I/O 요청시 디스크의 특정 블럭의 위치를 지정해서 데이터가 읽혀지거나 쓰여진다. 따라서 DAS에 있어서 가장 중요한 특징은 스토리지 장치에 발생하는 모든 I/O가 SCSI 프로토콜 블록 I/O로 해독된다는 점이다. 즉, 모든 I/O가 블럭으로 포맷되며 이 블록 I/O는 물리적 디스크 장치에 저장된 데이터의 위치와 구조에 관한 정보를 가지고 있는 것이다.

◇ DAS의 장점

● 설치의 간편/용이성 : 설치하는데 그리 어렵지 않다. 스토리지와 서버간의 연결이 이미 SCSI 케이블로 내장되거나 포이트 투 포인트(Point-to-Point) 연결로 짧은 거리에 간단하게 설치된다.

● 저렴한 소유비용 : SCSI 케이블은 비용이 상대적으로 저렴하며 설치가 쉽고 연결거리가 짧아서 소유하는데 드는 비용이 적다.

● 뛰어난 성능 : 연결 자체가 이미 스토리지를 위해 고안되었으며 프로토콜도 스토리지 프로토콜인 SCSI 블럭 I/O를 사용하기 때문에 어떤 타입의 애플리케이션에도 그 성능이 최적화되어 있다.

● 일반용도의 솔루션으로서 유연성과 개방성 제공 : DAS는 모든 종류의 스토리지 프로세싱에 최적화되어 있는 일반 솔루션이기 때문에 대부분의 애플리케이션에 최적화되어 있으며 따라서 일반 용도의 솔루션을 구현하려 할 때 상당한 유연성과 개방성을 제공해 준다.

◇ DAS의 한계

● 제한된 확장성 : 접속 확장이 가능한 SCSI 버스의 수나 처리 가능한 데이터의 용량의 확장성이 제한적이다.

● 파일 공유 불가능 : 시스템간의 파일 공유는 불가능하여 같은 데이터를 필요한 시스템마다 가지고 있어야 하는 비효율적인 중복 저장도 발생할 수 있다.

● 총소유비용(TCO)이 저렴한 것이 아니다 : 일반적으로 구매단계에서는 DAS가 저렴한 솔루션으로 여겨지나 대규모의 데이터와 서버를 관리하는 고객인 경우 오히려 비효율적인 관리 비용을 초래한다.

파일 I/O 프로토콜 사용하는 NAS
NAS는 일반적으로 이더넷 같은 인터페이스 카드를 통해 랜에 연결된 스토리지 시스템이다. 데이터퀘스트는 NAS를 ‘저장파일 및 데이터를 사용자에게 직접 제공함으로써 서버 시스템과 하드웨어에 독립성을 부여하는 스토리지 시스템’이라고 정의하고 있다.

NAS 이전에는 증가하는 데이터 용량의 확장요구를 일반용 서버에 직접 연결하는 DAS 방식으로 해결해 왔다. 이러한 서버 중심형 네트워크에서는 서버를 통해서만 데이터에 접근할 수 있었고, 결국 서버의 가용 리소스에 부담을 가중시켜 네트워크의 처리속도를 저하시키는 큰 원인을 제공하기도 했다. 즉, 서버를 통해서만 데이터를 저장/공유할 수 있기 때문에 사용자는 서버를 통과하는 네트워크 트래픽 정도에 따라 종종 심각한 래그(lag) 문제에 부딪히게 되었다. 바로 이런 DAS 아키텍쳐가 갖는 대기시간(latency) 결함을 극복하기 위해서 개발된 데이터 중심형 스토리지 솔루션이 NAS인 것이다.

따라서 NAS란 랜에 직접 연결되어 일반 서버의 오버헤드나 복잡함없이 오직 데이터의 전송과 공유만을 위해 최적화된 스토리지 전용시스템이라고 정의할 수 있다.

DAS나 SAN 또는 iSCSI와 같은 다른 스토리지 솔루션들과는 대별되는 NAS 솔루션의 가장 큰 특징은 모든 I/O 오퍼레이션이 파일 I/O 프로토콜을 사용한다는 것이다. 파일 I/O는 블록 I/O와는 달리 읽어야 할 파일만을 지적하고 파일이 어느 위치에 저장되어야 하는지 또는 저장되어 있는지에 관한 구체적인 스토리지 위치에 관해서는 지정하지 않는다. 이에 대한 지정은 NAS 시스템의 O/S가 별도로 블록 I/O로 수행한다.

◇ NAS의 장점

● 설치와 관리가 용이하다 : NAS는 업계 표준이라 할 수 있는 랜 인프라에 직접 설치되기 때문에 설치가 매우 쉽고 조작 및 관리도 간단하다.

● 총소유비용(TCO) 측면에서 저렴한 솔루션이다 : 이미 설치되어 있는 랜에 설치되기에 SAN처럼 네트워크 설치 추가 비용이 필요하지 않고 조작과 관리가 쉬워 관리비용도 감소하기 때문에 총소유비용(Total Cost of Ownership) 측면에서 매우 경제적이다.

● 이기종 시스템간의 파일공유와 파일전송이 가능하다 : NFS와 CIFS를 지원하여 NT계열 및 유닉스 기반의 시스템간의 파일공유와 파일전송이 기본적으로 가능해진다.

● 확장성 : NAS 장비자체는 대용량을 수용할 만큼 확장이 가능하며 사용중에도 다운할 필요없이 확장이 용이하다. 그러나 랜 트래픽 밀도나 밴드위치의 여유에 따라 제한이 있을 수 있다.

● 강력한 데이터 보호/백업 : ‘스냅샷’이라 불리우기도 하는 데이터 보호 솔루션은 오늘날의 NAS를 존재하게 해준 강력한 데이터 보호 솔루션이며 NDMP 등을 이용한 리모트백업 및 테이프백업 장치와 직접 연결되며 이를 내장된 소프트웨어로 관리할 수 있어 다양한 방법으로 고객의 요구에 맞는 데이터 보호/백업이 가능하다.

◇ NAS의 제한

랜 대역폭의 한계 : 이더넷 랜(Ethernet LAN)은 작은 사이즈의 파일이나 커맨드 요청에 신속하게 대응하는 버스트형 전송(Short Burst Transmission)에 유리하지, 사이즈가 너무 큰 데이터의 전송에는 상대적으로 불리하다. 랜상에서 사이즈가 큰 데이터 블록 전송시 랜 프로토콜이 작은 패킷 사이즈로 데이터를 움직이기 때문에 심각한 오버헤드 및 네트워크 정체가 야기될 수 있다. 따라서 NAS가 그 장점을 살리면서 랜에 제대로 설치/동작하려면 랜이 충분한 대역폭을 확보해야 한다. 따라서 NAS는 매우 많은 대역폭을 필요로 하는 애플리케이션이 설치된 환경에는 적합하지 않은 솔루션이라 할 수도 있다.

스토리지 전용 고속 네트워크 SAN
SAN이란 스토리지를 위해 고안된 스토리지 전용 고속 네트워크라 정의할 수 있다. 서버와 스토리지 장비들이 SAN에 연결되며 때로는 서버 뒤의 네트워크 (the Network behind the Servers)라고 불리우기도 한다. 랜과 같이 SAN도 Any-to-Any 연결이 가능하며 라우터, 게이트웨이, 허브, 스위치 등이 연결에 사용되며 다른 네트워크 아키텍처도 가능하지만 파이버채널(Fibre Channel)이 사실상의 SAN의 표준이라 하여도 현재는 무방하다 할 수 있다.

NAS는 네트워크 인터페이스 카드(NIC)를 통해 랜에 연결되는데 반하여, SAN 스토리지 시스템은 HBA(Host Bus Adapter)를 통해 네트워크에 연결된다. 이런 버스나 채널 같은 연결 특징 때문에 호스트나 애플리케이션 서버는 SAN에 연결된 스토리지 장치를 마치 직접 연결된 스토리지 장치처럼 인식하게 된다. 이러한 네트워크 특성으로 인해 SAN 네트워크는 다양한 프로토콜과 스토리지 장치들을 지원할 수 있으며 하나의 네트워크로서 관리될 수 있다. 따라서 SAN은 DAS처럼 SCSI 블록 I/O 프로토콜이 사용된다는 것이 NAS와 대비되는 중요한 특징이다.

◇ SAN의 장점

● 무정지 확장성 : 서버에 직접 연결할 수 있는 스토리지 용량은 서버에 따라 그 한계가 정해지고 확장시 서버다운을 시켜야 가능하지만 SAN은 서버와 관계없이 대규모 확장이 가능하며 서버다운 없이 확장시킬 수 있다.

● 뛰어난 성능 : 파이버채널은 이론상 초당 100MB의 최대 전송률을 가지는 가장 효과적인 전송 메커니즘을 갖고 있다. 이론상 기가비트 이더넷과 비슷한 최대 전송률을 가진다고 하지만 실제에 있어서 파이버채널은 일반적으로 60MB/s~8 0MB/s로 기가비트 이더넷의 40MB/s의 평균전송률보다 빠르다. 이는 기가비트의 랜 파일I/O는 대용량 데이터의 전송에는 패킷사이즈의 제한으로 상대적인 오버헤드가 발생하기 때문이다.

● 재난복구 솔루션 : SAN에 PPRC (Peer-to-Peer Remote Copy)와 같은 재해/재난 복구 솔루션이 결합해 재난발생시 저장 데이터의 안전과 신속한 복구가 이루어진다. 파이버채널로 구성되기 때문에 10~20km까지의 장거리로 서버와 스토리지를 분리해 줄 수 있으며, 최대 100km 떨어진 곳에 데이터 복사본을 가진 미러링 사이트를 구축할 수 있다.

◇ SAN의 단점

SAN은 무엇보다 가격상의 어려움을 가지고 있다. 단순한 스토리지 디스크나 테이프 장비만이 아닌 네트워크 인프라를 그것도 고가의 파이버채널 스위치 장비를 사용해야 하는 점은 비용면에서 고객에게 많은 부담을 안겨준다.

이밖에도 호환성의 문제가 있었으나 점점 개방적인 오픈 환경으로 전개해 나가고 있다. 이보다는 개방적인 파이버채널 인프라의 구축이 가능해지면서 파이버채널 스위치 시장은 확대되고 있지만 이를 운영하고 관리할 수 있는 인력은 턱없이 부족한 실정이고 이는 총소유비용(TCO)을 높이는 또 다른 악재로 작용하기도 한다.

SAN·NAS 융화시키는 ‘iSCSI’ 기술
많은 업체들이 SAN이 가져다 주는 월등한 성능을 필요로 하긴 하지만 가격대비 성능을 감안할 때 또 무엇보다 그 관리가 쉽다는 점에서 NAS는 경제적인 스토리지 네트워킹 솔루션이다. 사실 그동안 랜만 구축되어 있던 인프라에 SAN은 큰 부담으로 다가오기도 했다. 이에 반해 NAS는 그 저렴한 가격으로 인해 쉽게 일반 시장에 어필할 수 있었던 반면 성능을 우선시 하는 엔터프라이즈급 시장에서는 SAN에 대한 관심이 높았고 이런 대비적인 시장에서의 반응으로 NAS와 SAN은 대칭적이고 공존 불가능한 상반된 솔루션으로 인식되기도 했다. 그러나 NAS는 네트워크에 연결되는 저장장치 솔루션이며 SAN 역시 그런 네트워크 중의 하나다. NAS도 SAN 네트워크에 연결할 수 있다. 단 이미 SAN에 스토리지가 연결되어 있기 때문에 스토리지가 필요없다.

그래서 NAS 장비에 연결된 스토리지를 없애고 직접 SAN에 연결된 스토리지와 연결하여 SAN의 전용 스토리지를 NAS처럼 사용하게 만든 것이 IBM NAS 게이트웨이다.

또한 SAN을 새로 구축하지 않고 SAN이나 DAS방식의 프로토콜인 블록 I/O와 같은 역할을 해주는, IBM과 시스코가 공동개발한 iSCSI(Internet SCSI)라는 블록 I/O 프로토콜을 파일 I/O 프로토콜을 사용하던 랜상에서 구동되도록 한 신기술이 iSCSI 기술이다.

출처 : www.townpia.com

출처 : http://kkukdal2.tistory.com/52

NAS (Network Attached Storage)란..?

JAESOO — Wed, 12 Nov 2014 11:00:09 +0000

NAS (Network Attached Storage)란..?

NAS는 저장장치를 네트웍(LAN)망에 연결하여 네트웍 사용자들이 손쉽게 이 저장장치를 사용하여 백업 및 자료를 저장할 수 있도록 연결해놓은 방식을 말합니다.

NAS 의 사용 정의

NAS를 정리해보자면 네트웍망에 연결되어 있는 여러 host(PC)들에게 파일형태의 네트웍 스토리지 기능을 제공하기 위한 것입니다. 이를 요약하면
1) 현재사용하는 네트웍망에 직접 스토리지를 연결하여 고유의 ip를 갖게 한다
2) 서버들과는TCP/IP를 기반으로 한 LAN으로 연결
3) NAS 장비가 다양한 네트웍 프로토콜을 통해 여러 애플리케이션 서버들 사이에 파일을 공유할 수 있는 기능을 제공

NAS 장비는 이 목적을 위해 파일 시스템 , 파일 접속 사용기능 및 이 장비를 관리하는 기능만을 가지면 되므로 기존 서버에 설치되는 다양한 기능의 OS에 훨씬 간단한 NAS용 OS가 제공됩니다.

NAS의 장, 단점

장점

1) 현재사용하는 네트웍(LAN) 환경에 간단히 적용 가능.
2) SAN이나 DAS에 비해 저렴한 가격과 편리한 설치가 가능.
3) 저렴한 가격에 대용량의 스토리지를 제공할 수 있어 대용량 데이타를 공유, 보관하는데 편리함. 중소, 중견기업에 적합함.

단점

4) LAN이 불안정할 경우 연결이 불투명하고 연결이 많아질 경우 LAN 상의 트래픽 문제가 발생할 가능성이 있음
5) 대규모 시스템 환경에서 단일 스토리지 솔루션을 적용하기에는 한계점을 가질수 있음

출처 : http://cafe.naver.com/nas153/8

최강의 악성코드 제거 프로그램 'Malwarebytes Anti-Malware'

JAESOO — Sat, 08 Nov 2014 03:26:59 +0000

최강의 악성코드 제거 프로그램 'Malwarebytes Anti-Malware'

안녕하세요.

새터의 태양 블로그 지기 sunstar 인사드립니다.

제 pc에는 악성 코드 제거 툴로 울타리와 일전에 소개했던 팬더 클라우드 클리너,그리고 오늘 소개해 드릴

멜웨어바이트 안티-멜웨어가 설치되어 있는데요.

저는 이 툴들을 번갈아 사용하면서 매월 둘째주 수요일이면 마이크로 소프트를 방문해 月마다 업데이트되는

마이크로 소프트의 악성 코드 제거 툴을 꼼꼼히 사용하고 있습니다.

무료 악성코드 제거 프로그램 Panda Cloud Cleaner

JAESOO — Sat, 08 Nov 2014 03:26:01 +0000

무료 악성코드 제거 프로그램 Panda Cloud Cleaner

여러분은 악성코드 제거 프로그램으로 어떤 툴을 사용하시나요?

악성코드는 검증되지 않은 웹 페이지를 열거나,다운 받은 셋업 파일을 실행했을 때

나도 모르게 pc에 설치 됩니다.

이러한 악성코드는 pc가 느려지게 하는 원인이 되며,개인정보 유출 및 심지어는 좀비 pc를 만드는 숙주로

자라나기 까지 합니다.

오늘 소개하는 무료 악성코드 제거 프로그램 Panda Cloud Cleaner v1.0.35 는

가볍고 빠른 국내 프로그램 (울타리,고클린,pc클린 등)들이 잡아내지 못하는 악성코드를 정밀 스캔하여

결과를 나타내 줍니다.

팬더 클라우드 클리너에 대한 리뷰를 잠깐 살펴 보면....

클라우드 기반의 지능적인 악성코드 감지 "Panda Cloud Cleaner" v1.0.35

운영체제 WinXP/WinVISTA/Win7

권장사항 펜티엄4 2.5GHz,1G RAM

본 프로그램은 사용에 아무런 제한이 없는 프리웨어입니다.
Panda Cloud Cleaner는 일반적인 보안 솔루션으로는 탐지가 잘 안되는 악성코드를 지능적인 검색 엔진을

통해 검사해주는 클라우드 기반의 백신 프로그램입니다.

프로그램은 'Accept And Scan' 버튼을 눌러서 검색을 진행하면 됩니다.

검색은 클라우드 방식으로 진행되며, 시스템 리소스를 꽤 많이 사용하니까

다른 작업은 중지하고 실행하는 게 좋습니다.

문제의 여지가 있는 항목에 대해 검색 결과를 알려주며, 세부 사항을 확인할 수 있습니다.

다운로드 링크

홈 페이지 http://www.pandasecurity.com

다운로드 페이지 http://pandacloudcleaner.pandasecurity.com/facebook

다음 자료실 v1.0.35 http://file.daum.net/pc/view.html?fnum=340330&cat=1&scat=31

네이버 자료실 v1.0.28 http://file.naver.com/pc/view.html?fnum=332517&cat=31

설치

설치는 빠른 속도로 진행되는데 위 다운로드 링크의 팬더 클라우드 클리너 페이스북 페이지나

마음에 드는 자료실 페이지에서 다운 받아 설치를 하시면 됩니다.

실행

Accept and Scan 버튼을 누르면 정밀 스캔이 진행되는데요.

처음 실행하면 일단 프로그램 업데이트 이후 스캔이 진행되는데 컴에 설치된 프로그램 수에 따라

인내심을 요하는 시간이 경과한 후 결과를 보여 줍니다.

Panda Cloud Cleaner의 설치와 실행을 간단하게 소개 했는데요.

Panda Cloud Cleaner의 실행 파일의 크기가 부담이 안 된다면 울타리,고클린 등과 같이 사용해도 좋을 듯 합니다.

감사합니다.

출처 : http://sunstar2.tistory.com/511#.VFz9N2dEgsN

NEXT-755FP 5Bay 데이터 스토리지 사용자설명서입니다.(USB3.0, 1394A/B 지원)

JAESOO — Mon, 27 Oct 2014 08:35:18 +0000

NEXT-755FP 5Bay 데이터 스토리지의 사용자 설명서입니다.

아래의 버튼을 클릭하시면 NEXT-755FP의 사용자 설명서를 다운 받아 보실 수 있습니다.

출처 : http://www.ez-net.co.kr/new_2012/customer/userguide_view.php?cid=11&sid=74&goods=190&cate=&q=&seq=52&PHPSESSID=313d47b23f1c521bd40a034edd0534c6

[DataMore MultiRAID] SATARaid5 프로그램

JAESOO — Fri, 24 Oct 2014 08:54:34 +0000

▶ SATARaid5 Utility 다운받기

안녕하세요 새빛입니다.

DataMore MultiRAID 제품에 기본 포함이 되어 있는 프로그램입니다.

일부 PC 에서 호환성 문제로 인하여서 기본 포함된 CD 의 프로그램으로 구동이 되지 않을 경우
위의 프로그램을 다운로드 하여서 설치를 하여 주시기 바랍니다.

감사합니다.

출처 : http://www.savitmicro.co.kr/

[DataMore Multi RAID] Java 설치 프로그램

JAESOO — Fri, 24 Oct 2014 08:53:11 +0000

DataMore Multi RAID 제품의 RAID 구성 프로그램인 sata5RAID Manager 을 실행 하였을때 실행이 되지 않고 압축 파일이 열리는것처럼 실행될때는 아래의 파일을 다운로드 하여서 설치 하여 주시기 바랍니다.

▶ 다운받기

출처 : http://www.savitmicro.co.kr/

[MultiRAID] Deluxe Model 펌웨어

JAESOO — Fri, 24 Oct 2014 08:52:54 +0000

* datamore QuadRAID Deluxe
* datamore PentaRAID Deluxe
* datamore OctaRAID Deluxe

USB3.0 호환성 문제 해결 된 펌웨어입니다.

1. 압축을 풀고 FwUpdateTool_v1_15_06_T2.exe파일을 실행합니다.

2. Load File을 클릭합니다.

3. 펌웨어파일(JMS539_PM_255.31.3.41.22_20100805.BIN)을 선택하고 열기를 클릭합니다.

4.밑에 Run을 클릭하면 펌웨어가 업그레이드 됩니다.

5. 완료 후 전원을 끄고 다시 연결합니다.

감사합니다.

jmicron_jms539_255.31.3.41.22.zip

출처 : http://www.savitmicro.co.kr/

[DataMore MultiRAID] 사용자 설명서

JAESOO — Fri, 24 Oct 2014 08:52:41 +0000

안녕하세요 새빛입니다.

DataMore MultiRAID 제품의 사용자 설명서 입니다.

적용 제품은 아래와 같습니다.

DataMore QuadRAID

DataMore PentaRAID

DataMore OctaRAID

DataMore PentaRAID Pro

DataMore PentaRAID Deluxe

▶ 다운받기

출처 : http://www.savitmicro.co.kr/

새로텍 CyberNetor Super RAID System C8-US3 (하드미포함) - 사용 설명서

JAESOO — Fri, 24 Oct 2014 08:52:20 +0000

C8-US3_Manual_R100_K.pdf

C8-US3_Quick Manual_R100_K.pdf

출처 : http://www.sarotech.com/product/product_detail.html?part_idx=167&search_item=&item_idx=372

출처 : http://www.sarotech.com/support/down.html?tb=zbbs_down_manual&field=Subject&keyword=c8&operator=AND&sw=v&rowid=295

새빛마이크로 DataMore OctaRAID Deluxe 레이드(Raid) 설정 관련

JAESOO — Thu, 23 Oct 2014 15:58:07 +0000

= 레이드(Raid) 변경 하는법

1. 뒷면의 레이드 딥 스위치 변경

2. 본체 열고 안에 있는 딥 스위치를 변경 (Raid 인 경우 CLEAN OFF, CLEAN 모드인 경우 ON)

2. Reset 버튼을 누른 상태에서 전원을 ON 하시면 RAID 설정이 적용

출처 : 인터넷 검색

[Switch 기능] STP, RSTP, MSTP에 관해서…

JAESOO — Tue, 21 Oct 2014 08:55:38 +0000

2009.03.10 admin

Switch 기능중에는 loop 방지를 위한 STP 기능이란게 있습니다.

이것이 어떤 기능을 하는지 알아볼까요?

STP (3개 루핑) 된 테이블 (#show spanning-tree)

VLAN0001
Spanning tree enabled protocol ieee
Root ID    Priority    32768
Address     0014.7c50.8ca0
Cost        200018
Port        1 (FastEthernet0/1)
Hello Time   2 sec Max Age 20 sec Forward Delay 15 sec

Bridge ID Priority    32769 (priority 32768 sys-id-ext 1)
Address     0016.c8af.fe80
Hello Time   2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 15

Interface        Role Sts Cost      Prio.Nbr Type
—————- —- — ——— ——– ——————————–
Fa0/1            Root FWD 19        128.1    P2p
Fa0/16           Desg FWD 19        128.16   P2p
Fa0/17           Desg FWD 19        128.17   P2p
Fa0/23           Desg FWD 19        128.23   P2p
Fa0/24           Desg FWD 19        128.24   P2p   (FWD 통신가능상태 / BLK 통신불가상태 STP)

STP(강의)

Root Bridge(기준점생성)
Designated port / Root port

Root Bridge
1.1 BPDU (스위치 생성시 Frame 생성)

1.1.1 Root BID (Bridge ID)

BID(8byte) = Bridge priority(2byte) + Mac Address(6byte)

Bridge priority는 32768로 고정 (= 0x8000)

1.1.2 Path cost

예전에는 1000/대역폭 으로 계산하였으나 10Gbps 등장이후 쓰이질 않는다

IEEE에서 새로 지정

대역폭 / cost

10Mbps = 100

100Mbps = 19

1gbps = 4

10gbps = 2

1.1.3 Sender BID = 32768 + 스위치 MAC주소

1.1.4 Port ID = 스위치의 Port 숫자번호

※ BID 값이 작은쪽이 Root Bridge가 된다.

연산후에 Root Bridge와 Non-root Bridge로 나뉜다.

Designated port / Root port 비교법

Non – Root Bridge 중에서 Root와 가장 가까운 Port Path Cost를 가지고 비교한다
작은쪽값이 Root Port가 된다.
Designated port는 1segment에 무조건 하나를 가진다. (1segment = 스위치와 스위치 한구간)

STP 구성시 라인 단절 확인법.

Hello BPDU는 Root bridge가 Designated port를 통해 전송한다
Max age = Hello BPDU를 Non – root Bridge가 최대로 기다릴수 있는시간 (Default 20 sec)
Block port는 모든 패킷을 막지만 단 한가지 패킷 BPDU는 수신할수 있다.

STP(Spanning Tree Protocol)

일반적인 스위치 네트워크는 복수개의 링크로 연결하는 경우가 많다. 그 이유는 특정스위치에 장애가 생기거나, 링크가 다운되어도 전체 네트워크는 계속 동작할 수 있기 때문이다. 또, 특정 목적지로 가는 트래픽을 분산시켜 전체적인 속도를 더 빠르게 할 수 있다. 장거리 통신망도 이와 같이 백업 및 로드 밸런싱 (load balancing) 구조로 설계하지만 이를 유지하기 위한 비용이 비싸다. 그러나, 스위치 네트워크는 초기 투자비외에는 추가적으로 발생하는 비용이 크지 않기 때문에, 비교적 소규모라 해도 복수개의 링크로 구성하는 경향이 있다. 이처럼 스위치간을 루프 (loop) 구조로 구성하면 어떤 문제가 발생할 수 있는 지 살펴보자. 먼저 브로드캐스트 프레임의 루핑 (looping) 문제가 발생한다. 스위치는 브로드캐스트 프레임을 수신하면, 동일한 VLAN에 속한 모든 포트로 전송한다. 이를 플러딩 (flooding) 이라고 한다. 이를 수신한 인접 스위치는 또 브로드캐스트 프레임을 플러딩한다. 이외에도 MAC 어드레스 테이블이 불안정해지며, 특정 호스트가 동일한 프레임을 중복해서 수신할 수도 있다. 이와 같은 문제를 해결하기 위해 사용되는 것이 스패닝 트리 프로토콜 (STP, Spanning Tree Protocol)이다. 즉, 스패닝 트리 프로토콜이 동작하면 물리적으로는 루프가 형성된 네트워크를 논리적으로 루프가 없게 만든다. 결과적으로 앞서 설명한 문제를 모두 해결해준다.

즉 간단히 얘기해서, L2계층통신에서 발생하는 local loop를 방지하기 위한 프로토콜임. 스위치(브리지)간에 root bridge, designate Port, block Port를 선별하여 STP토폴로지를 구성, local loop를 막습니다. 이때 토폴로지 구성에 BPDU frame의 스위치(브리지)정보를 이용합니다.

- BPDU(Bridge Protocol Data Unit)

BPDU란 스위치(브리지)간 정보 교환을 위한 frame데이터이다. 이는 네트웍내에서 발생할 수 있는 네트웍루프를 장비하기위한 STP의 정보데이터가 된다. STP가 동작하면 스위치는 35 바이트의 고정된 길이를 가지는 컨피규레이션 BPDU(Bridge Protocol Data Unit)라는 프레임을 전송한다. BPDU는 다음과 같이 구성되어 있다.

-필드 크기(바이트) 내용
-프로토콜 (protocol) ID 2 항상 0
-버전 (version) 1 BPDU의 버전 표시. STP : 0, RSTP : 2, MST : 3
-타입 (type) 1 BPDU 종류 표시. 0x00 : 컨피규레이션 BPDU, 0x80 : TCN BPDU
-플래그 (flag) 1 토폴로지 변화 표시. 0x01 : TC, 0x80 : TCA
-루트 브리지 (root brigde) ID 8 루트 스위치의 ID
-패스 코스트 (path cost) 4 루트 스위치까지의 경로 값
-브리지 (bridge) ID 8 루트 스위치로 가는 경로상, 직전 스위치의 스위치 ID
-포트 (port) ID 2 포트 ID
-메시지 에이지 (message age) 2 루트 스위치가 현 BPDU를 만들고 경과된 시간
-맥스 에이지 (max age) 2 BPDU 정보를 저장하는 시간
-헬로 타임 (hello time) 2 BPDU 전송 주기
-포워드 딜레이 (forward delay) 2 리스닝 상태와 러닝 상태에 머무르는 기간

표 BPDU의 필드 및 내용

BPDU는 컨피규레이션 BPDU외에 TCN BPDU라는 두 종류가 있다.

BPDU는 3개의 시간을 갖으며, Hello 타임(Hello time), 전달 지연 시간(Forward delay time), 최대 수명 시간(Max age tiem)등이 있다. 우선 Hello 타임은 root bridge에 의해 보내지는 BPDU의 간격이라 보면 되고 간격은 2초이다. 전달 지연 시간은 라우터가 브릿지 테이블을 완성하는데 걸리는 시간으로 15초인데, 전달 지연 시간은 리스닝과 학습상태의 지속 시간으로 각각 15초이므로 총 시간은 30초가 된다. 마지막으로 Max age time은 BPDU가 업데이트되기전까지 저장되는 시간으로 20초이다. 그래서 총 50초의 시간이 소요되는데, 이 시간이 스위치간의 다이렉트로 연결이 되어있을시에는 Max age time이 제외된 30초가 소요된다는 점에 유의한다.

STP가 loop-free leaf 토폴로지를 구성하는데 필요한 정보가 되며, 이 BPDU는 2초간격으로 스위치(브리지)간 교환하게 된다.

[출처] STP, BPDU|작성자 youth3

RSTP

흠 간단하게 말하면 STP 보다 개선된 프로토콜이라 할수있습니다

IEEE 802.1W입니다. 흔히 이야기하는 Rapid Spanning Tree 혹은 RSTP로 불리는 넘 입니다.

이것도 IEEE 802.1D와 동일하게 Loop을 방지하는 프로토콜 입니다. 하지만 이름 그대로 빠릅니다.

Listening에서 Fowarding까지 2초밖에 안걸립니다. 45초에서 2초…죽이죠?

이것 역시 BPDU를 뿌립니다. 그렇다구 위에 언급한 꿍수(?)처럼 BPDU를 자주 뿌리는 것은 아닙니다.

BPDU방식이 다릅니다. 기존 IEEE 802.1D의 BPDU는 단순 자신의 MAC주소와 Bridge Priority값만을 가지고 있었습니다.

그리고 나중에 learning과정에서 Topology를 구성했죠..

하지만 IEEE 802.1W의 BPDU에는 그 이외에 자신의 Topology를 포함해서 보냅니다. reply하는 넘 역시 받은 Toplogy에 자신의 Toplogy를 업뎃 해서 보내기에 Learning이라는 과정이 없습니다. IEEE 802.1D를 대신해 IEEE 802.1W가 요즘 대세죠..

RSTP port의 종류
– Root Port
– Alternate Port : rp가 다운되었을 경우에 대신해 주는 port, 자신이 아닌 BPDU를 받는 Port
– Designated Port
– Backup port : dp가 문제가 발생했을 경우에 대신해주는 port, 자기 자신으로 부터 발행되는 BPDU를 받는 Port

이전의 stp의 블러킹 포트가 rstp로 넘어가면서 ap와 bp로 나누어 졌다
ap는 rp가 다운이 감지되었을 때 그 역할을 대신해 주고,
dp가 다운이 감지되었을 때 그 역할을 대신해 주는 port가 bp 이다.

RSTP Link Type의 종류
-Edge : Edge – 스위치와 일단 시스템에 연결되어 있는 링크(스위치-스위치 간의 연결은 아님)
point-to-point(full-duplex) – port 의 상태가 full-duplex인 경우

- edge의 경우 RSTP가 형성이 된다.
(half-duplex 의 경우 일반적인 CSMA/CD 환경)

-Shared Link : multipoing(half-duplex)
– 허브와 스위치는 일반적으로 half-duplex로 연결
– 허브에 여러대의 시스템이 물린 환경인 경우 RSTP 구현이 되지 않는다.
– 스위치와 스위치간에 half-duplex로 연결되어 있을경우 shared link 환경이 구현되지 않는다.

half-duplex로 되어 있을 경우에,
( -if)#span link-type point-to-point
shared link 상태를 강제로 point-to-point로 인식되게 하는 명령어.
#sh int status // interface의 상태가 나온다
-Auto : Auto negotioation > Speed : 서로간에 시그널을 교환후에 알맞는 대역을 설정, 둘다 지원해 줄 수 있는
> duplex : halp-auto => half-duplex
auto-auto => Full-duplex
*Full-auto => half, duplex mismatch!!
각각의 interface에서 수동조절이 필요.

(router의 설정은 half로, switch는 auto로 설정되어 있음)
( -if)#speed 100
10
auto
( -if)#duplex half
full
auto
라우터와 스위치의 처음 연결시 체크하고 되도록이면 메뉴얼로 설정할 것.

MSTP(Multiple Spanning Tree Protocol)

▣PVSTP는 각 vlan 마다 하나의 instance가 존재한다. 즉 vlan이 10개이면 10개의 vlan instance가 존재하고 이것은 스위치 cpu에 부하를 일으킨다. 따라서 몇몇 vlan을 묶어서 그녀석들 끼리는 같은 vlan instance를 지니게 해서 부하를 줄이는데 이것이 MSTP이다.
▣vlan instance 수가 줄어드므로 pvst+보다 빠른 convergence시간을 가지고 802.1d , 802.1w와도 호환이 가능하다.
▣vlan수가 그다지 많지않은 ECNM에선 꼭 필요한 것이 아니다.
▣같은 MSTP configuration을 돌리는 bridge들은 같은 MST region안에 있다고 한다.
▣1000개의 vlan을 가진 PVST를 5:5 비율로 인위적으로 나눠서 load balancing을 했다고 하더라도 1000개의 instance를 5:5비율로 서로 다른 토폴로지에 적용시킨것 밖에 되지 않는다.

2.MST regions
▣다음과 같은 경우를 생각해보자. 어떤 vlan이 어떤 instance에 속해있는지 어떻게 알 것인가? > BPDU를 태깅해서 instance와 그것을 어떤 vlan에 적용시킬지 구분한다. CST에는 한개의 vlan instance만 존재하고 PVST에는 각 vlan마다 각기 다른 BPDU를 보낸다고 한다.
▣동일한 MST region에 들어가려면 name,revision number,vlan association table이 일치해야한다.
▣각 region 마다 다른 digest값을 가지고 이것은 BPDU에 포함되어 전송되는데 다른 포트에서 들어온 BPDU에서 추출한 값과 자기 digest값과 비교해서 같으면 같은 region 다르면 다른 region이라 판단한다.

3.Extended system Id
▣Extended system Id(12bit길이)부분에 instance id가 기재된다.

4.MST region과 802.1Q와의 상호작용

▣MST와 802.1D가 섞여 있을때는 위와 같이 동작한다. MST region에는 최소한 하나의 IST(Internal Spanning Tree)가 존재해야한다.
▣전체의 MST region이 ISTP를 통해 마치 하나의 스위치처럼 보여지는 것이다. IST는 전체의 region을 마치 하나의 가상의 스위치처럼 보이게 한다. BPDU는 region 경계선을 이루는 스위치의 트렁크 포트의 native vlan를 통해서 마치 CST BPDU처럼 교환된다.
▣MST region은 한개의 큰 IST로 대표되어서 마치 하나의 큰 스위치인양 CST에서 인식되는데 큰 IST를 쪼개보면 그 안에 각 MST instance가 있다. 한개의 region당 16개의 MSTIs(MST Instances)가 존재할 수 있는데 IST는 항상 MSTI 0번에 지정된다. IST만이 BPDU를 주고 받는다. MSTI가 아무리 많아도 BPDU는 한종류만 생성 되는것이다.
▣MST region 안에서 스위치끼리는 RSTP를 돌리면서 loop를 방지하고 있다.
▣MST와 PVST+가 연결될 경우? : MSTP는 region을 대표하는 IST의 BPDU 한개만 존재,PVST+는 각 vlan마다 BPDU가 존재한다. MSTP가 PVST와 연결될 경우 MSTP는 PVST의 vlan 개수만큼 BPDU를 복사해서 뿌린다.
▣MST region안의 MSTIs은 IST와 같은 파라메터를 쓴다(ex.같은 hellotime,forward delay,max time을 가진다)
▣요약하면 한 MST region은 하나의 IST로 CST에게 하나의 가상 스위치로 보여지며 IST로만 보면 하나로 보이지만 실제로는 여러개의 MST Instance가 집합해 있는것이다. vlan들을 묶어서 하나의 instance로 돌려서 cpu부하를 줄이는데 이 instance들은 자체적으로는 RSTP를 돌린다. 이 instance들이 RSTP를 돌리는데는 MST instand 마다의 다르게 생성되는 BPDU의 M-record라는 서브 필드가 사용되고, Hellotime같은 공통파라메터는 IST의 파라메터로 통일된다.
5.MSTP command
▣(config)#spanning-tree mst configuration > MSTP configuration submode 들어가기
▣(config_mst)#show current > 현재 mstp 컨피그 보여주기
▣(config_mst)#name 이름 > region 이름 지정
▣(config_mst)#revision revision번호 > revision번호 지정, 그냥 구분자 역할만 한다 자동으로 증가하지 않음
▣(config_mst)#instance instance번호 vlan vlan번호 > vlan에다 instance 지정
▣(config_mst)#spanning-tree mst instace번호 root primary|secondary
▣(config)#spanning-tree extend system-id > Mac address reduction or extended system id 사용
▣(config)#spanning-tree mst pre-standard > MSTP prestandard 버전 사용

출처 : http://www.spkr.co.kr/switch-%EA%B8%B0%EB%8A%A5-stp%EC%97%90-%EA%B4%80%ED%95%B4%EC%84%9C/

네트워크 장비 L2 · L3 · L4 · L7

JAESOO — Mon, 20 Oct 2014 16:12:32 +0000

패킷이란 원래 우체국에서 취급하는 "소포"를 말하는데, 화물을 적당한 크기로 분할해서 행선지를 표시하는 꼬리표를 붙인 형태이다. 데이터 통신망에서 말하는 패킷이란, 데이터와 호 제어 신호가 포함된 2 진수, 즉 비트 그룹을 말하는데, 특히 패킷교환 방식에서 데이터를 전송할 때에는 패킷이라는 기본 전송 단위로 데이터를 분해하여 전송한 후, 다시 원래의 데이터로 재조립하여 처리한다.

전자우편이나 HTML 파일, GIF 파일, 기타 어떤 종류의 파일이라도, 이것을 인터넷을 통해 한 장소에서 다른 장소로 보내려 할때, TCP/IP의 TCP 계층은 이 파일을 전송하기에 효율적인 크기로 자르게 된다. 분할된 각 패킷들에는 각각 별도의 번호가 붙여지고 목적지의 인터넷 주소가 포함되며, 각 패킷들은 인터넷을 통해 서로 다른 경로를 통해 전송될 수 있다. 보내어진 패킷들이 모두 도착하면, TCP 계층의 수신부에서 패킷들을 원래의 파일로 다시 재조립한다.

이와 같이 패킷교환 방식은 인터넷과 같은 비연결형 네트웍에서 데이터 전송 처리를 하기 위한 효율적인 방법 중의 하나이다. 또 다른 방식의 하나인 회선교환 방식은 음성 전송을 위한 네트웍이다. 회선교환에서도 네트웍 내의 회선들을 많은 사용자들이 공유한다는 측면에서는 패킷교환 방식과 마찬가지지만, 일단 특정한 경로가 설정되면 각 연결은 일정기간 동안에는 거기에 전념하여 서비스를 한다는 측면이 다르다.

패킷이나 데이터그램은 비슷한 의미로 사용되는데, TCP와 비슷한 역할의 프로토콜인 UDP에서는 패킷이라는 용어 대신에 데이터그램이라고 부른다.

패킷은 일반적으로 128 바이트가 표준이지만 52, 64, 256 옥텟 등 편의에 따라 크기를 바꿀 수 있으며, 옥텟은 보통 8 비트로 구성되고 이를 1 문자로 간주한다. 64자를 1 세그먼트로 하고, 128자를 1 패킷으로 하는 표준 패킷에 있어 그 관계는 다음과 같다.

(1 packet = 2 segment = 128 octet = 1,024 bit)

socket이란? 네트워크상에서 서버와 클라이언트 두개의 프로그램이 특정 포트를 통해 양방향 통신이 가능하도록 만들어주는 소프트웨어 장치.

● 스위치의 분류

L2: OSI 레이어 2계층에 속하는 MAC 어드레스를 참조하여 스위칭하는 장비

L3: OSI 레이어 3계층에 속하는 IP 주소를 참조하여 스위칭하는 장비

L4: OSI 레이저 3~4계층에 속하는 IP 주소 및 TCP/UDP 포트 정보를 참조하여 스위칭하는 장비, 주로 로드밸런싱 역할을 함

L7: OSI 레이어 3~7계층에 속하는 IP 주소, TCP/UDP 포트 정보 및 패킷 내용까지 참조하여 스위칭함, 로드밸런싱 역할 및 품질보증이나 보안기능 추가

신입시절... L2/L3/L4/L7 스위치를 제대로 정의를 못하던 저에게 선배님이 간단히 설명해준 적이 있었습니다.

당시 L2는 그냥 단순한 스위치고 L3는 라우팅까지 해주는 스위치고, L4는 로드밸런싱을 해주는 스위치고,

L7은 무엇인지 모르지만 좀더 좋은 스위치로 알고 있던 저였습니다. 그런데 명확히 설명하라면 난감한 상태였었습니다.

선배왈...

"즉, 모든 스위치는 말그대로 'Switching ', 즉 패킷을 어느쪽으로 보내야 하는 역할을 해야돼...

문제는 그 어느쪽으로 보낼 때 어떠한 정보를 보고 판단을 하는 것인지에 따라 Layer가 구분되는거야.~"

" L2 스위치는 MAC 정보(MAC Table)를 보고 스위칭을 하는 것."

" L3 스위치는 IP 정보(Routing Table)를 보고 스위칭을 하는 것."

" L4 스위치는 IP+Port(Session or Connection)를 보고 스위칭을 하는 것."

" L7 스위치는 실제 App 데이터(Content)를 보고 스위칭을 하는 것."

"그리고 중요한 것은 상위 레이어 스위치는 하위 레이어 스위치의 기능을 기본적으로 다 할수 있다는것.!

다만, 실제 사이트 구성시에는 자신의 주력 기능만 수행하는 것이 일반적이라는...!"

-스위칭 (Switching) ㅇ 일반적으로 접점의 개폐, 회로의 도통 및 차단, 상태의 변환 등의 동작을 말함

[출처] Socket 이란?|작성자 오바나딩요

● 네트워크장비 내부구조

( CPU · DRAM · Flash Memory · NVRAM · ROM )

CPU: PC의 CPU와 마찬가지로 시스템 제어 및 연산 담당

DRAM: 현재 사용중인 OS의 코드 임시 저장, 각 포트에서 필요한 버퍼 제공, CAM 테이블 및 라우팅 테이블 등 저장

Flash Memory: PC 등의 하드 디스크에 해당, OS가 저장, 장비에 따라 설정 내용 저장

NVRAM: 장비의 동작에 필요한 IP, 라우팅/스위칭 정책 등 설정 파일 저장, 비 휘발성

ROM: OS를 구동시키기 위한 코드 및 장애발생 시 복구를 위한 최소한의 OS등 저장

< 스위칭 내부 구조>

●네트워크 장비 외부 구조

Serial port : wan장비와 연결되는 부분, 인터페이스 지정 시 interface serial 0/0 또는 interface s0/0과 같은 명령어 사용

(앞에 모듈(또는 슬롯) 번호를 의미, 뒤에 0은 포트의 번호를 의미)

Ethernet Port: Lan 장비와 연결되는 부분, interface fastethernet 0/0 또는 interface f0/0 과 같은 명령어 사용

(앞에 0은 슬롯 번호를 의미, 뒤에 0은 포트 번호를 의미)

Console port: pc 등을 이용하여 장비를 설정 및 동작 확인 시 사용하는 포트

AUX 포트: 콘솔 포트와 용도가 같지만, 관리자용 암호가 설정되어 있지 않으면 관리자 모드로 들어갈 수 없음

●L2 스위치 개요

흔히 말하는 스위치를 지칭

OSI 7계층 중 2계층에 해당

Input 포트를 통해 들어온 프레임을 목적지 MAC 주소를 기반으로 Output 포트를 통해 전송

Collision Domain 나눔 (collision domain:충돌 영역)

장점: 구조가 단순, 가격이 저렴

단점: broadcast패킷에 의해 저하 가능성

●L2 스위치 동작원리

Learning: MAC 정보를 배우는 과정

Flooding: MAC 정보가 없어 받은 받은 포트를 제외하고 모든 포트로 다 보내는 경우

Filtering: 목적지로 향하는 포트가 수신 받은 포토와 동일한 경우 그 프레임 차단

Aging: 타이머를 설정하여 설정된 시간 동안 MAC 주소에 대한 활동이 없으면 삭제

l2 스위치 패킷 전달방법: 출발지와 목적지의 MAC Address를 확인

l2 스위치는 패킷 전송 시 , 출발지로 부터 패킷을 전송 받아 mac address를 검사하여 목적지에 맞는 포트에 패킷을 전달한다.

l2 스위치의 VLAN은 논리적으로 네트워크를 분할 하여 패킷을 전송하기 때문에 브로드캐스트 패킷 제어에 효율적이며, 보안적으로도 유용하여 많이 쓰이고 있다.

-VLAN

논리적으로 분할된 스위치 네트워크

물리적 위치가 아닌, 접속포트, MAC 주소, 프로토콜 단위로 구성 가능

조직 내에서 작업 그룹 구성 시 용이

브로드캐스트 패킷 제어에 효율적

●L3 스위치

L3 스위치는 흔히 얘기하는 라우터와 경계가 모호하여 혼동되기 쉽다. 그러나 L3 장비는 L2 장비에 라우팅 기능이 추가되어, 라우터 보다는 라우팅 처리 능력이 우수하다.

-특징

포트간 패킷 스위칭을 위해 패킷의 IP나 IPX 주소를 읽어 스위칭

Broadcast domain 나눔

3계층에 위치

Switch 장비 플랫폼에 라우팅 기능 부가

트래픽 체크, 가상 랜 (VLAN) 등의 많은 부가 기능을 갖고 있음

· 장점: 브로드캐스트 트래픽으로 전체 성능 저하 방지

· 단점: 특정한 라우팅 프로토콜을 이용해야 스위칭이 가능

l3와 라우터의 차이: l3는 확장성이 좋은 반면 소프트웨어적인 기능이 적고, 라우팅 처리 기능이 우수하다 또한 하드웨어적인 처리방식이다. 라우터는 소프트웨어 지원이 많고, 라우팅 처리 기능이 l3에 비해 떨어진다.소프트웨어적인 처리방식이다.

라우팅이란: 패킷의 목적지 IP를 확인하여 해당 패킷을 목적지 까지 전달하는 것을 말한ㄴ다. 라우팅의 종류로는 static과 dynamic이 있다

@static routing : 관리자가 경로를 직접 입력

장점

:라우팅 정보가 다른 곳으로 나가지 않기 때문에 보안성이 좋음

:다이나믹 라우팅의 오버헤드를 줄 일 수 있다.

:노트에서 보았을 때 갈수 있는 길이 오직 하나빡에 없을 때 static 라우팅이 적합

@dynamic routing : 라우팅 프로토콜에 의한 경로 결정

장점

:다른 라우터들과의 통신에 의해 경로를 결정하기 때문에 적응성이 좋음

:라우터가 많을 시 관리가 용이

@static route

장점: cpu 소모율 적음, 대역폭 소비 없음, 보안성,신뢰성,예측 가능성 높음

단점: 설정을 유지하기 어려움, 관리자가 수동적으로 라우트 설정, 변화에 적응하기 어려움, 확장성 낮음

@dynamic route

장점: 높은 적응성, 구성유지가 쉬움, 프로토콜에 대한 정의만 해주면 더 이상 관리가 필요 없음

단점: cpu 소모율 높음, 대역폭 소비가 높음

L4/L7 스위치의 용도 :

일반적으로 서버들의 로드밸런싱을 위해 사용됨

복수개의 웹서버가 있을 때, 임의의 웹서버에 접속을 시도하면, 스위치가 각 서버의 부하를 고려하여

적당한 서버와 연결시켜준다.

설정에 따라 순차적 연결 또는 접속이 가장 적은 서버에 연결하는 방식 등이 있다.

L4 스위치 :

Layer 4에서 패킷을 확인하고 세션을 관리하며, 로드밸런싱을 제공하는 스위치

TCP/UDP 패킷 정보를 분석해서 해당 패킷이 사용하는 서비스 종류 별로 처리(HTTP, FTP, SMTP...)

세션관리, 서버/방화벽 로드밸런싱, 네트워크 서비스 품질 보장

L7 스위치 :

L4 스위치의 서비스 단위 로드밸런싱을 극복하기 위해 포트 + 데이터 페이로드 패턴을 이용한 패킷 스위치

(e-mail 내용/제목, URL ...)

connection pooling(시스템 부하 감소), Traffic Compression (컨텐츠 압축 전송), 보안 기능

출처 : http://defensecurity.tistory.com/9

하드디스크 용량 계산하는 방법 및 하드용량별 실제 표기용량

JAESOO — Mon, 20 Oct 2014 09:30:20 +0000

어떤 분들은 하드를 200기가, 320기가를 사시는데

용량이 딱 맞아 떨어지지 않는다고 손해봤다고 생각하시는 분들이 있습니다

하지만 컴퓨터가 쓰는 2진수와 우리가 쓰는 10진수의 차이 때문에 그렇습니다

컴퓨터에서 1기가가 왜 1024 일까요?

바로 공학용 계산기ㄱㄱ 하셔서 십진수인 (Dec) 1024를 입력합니다

그러고나서 2진수인 Bin을 찍으면 1,000,000,000 이라는 숫자가 나옵니다

1000바이트=1KB 1000KB=1MB 1000MB=1GB 10진수에서 8인 2진수1000을 3번 곱하면 1,000,000,000이 되죠

위에서 본건 2진화 했을때의 용량으로 사람은 10진수니 정말 불편한 감이 있습니다

4라는 숫자를 2진화하면 100이 되는데 당연 불편하겠죠 그래서 10진수로 변환해서 보여주는 겁니다

이제 이 글의 요점인 HDD의 용량 계산을 해봅시다!

우선 자신이 구입했던 하드디스크의 용량을 기입합니다 당연 10 진수에서 입력해야겠죠

예를들어 320기가를 보면 논리용량?인 320,000,000,000 바이트가 되겠습니다

(아마 컴퓨터에서 보면 320 하고 뒤에 다른숫자가 더 나오니 저 상태에서 계산해도 비슷한 값이 나옵니다)

간단합니다 계산기에서 320,000,000,000를 치고 아까 위에서 설명했던 2진수 1기가의 10진수 1024를 3번 나눠줍니다

그럼 298.02322...가 나올겁니다 이것이 컴퓨터에서 320기가를 봤을때의 용량 입니다

이 방법은 하드를 편하게 쓰기위해서 파티션을 나눌때 저는 이 방법을 씁니다

C:를 98기가로 쓰기 위해서는 1024X98 해서 그 값을 쓰면 나머지 200기가는 저절로 D:가 되니 참 편한 방법입니다

혹 용량계산이 길어서 오타가난다? 짧게하는 다른방법이 있습니다

320,000,000,000에 뒤에0을 6개 빼줘서 320,000으로 만들어 줍니다 기가이니 000은 꼭 붙여줘야 합니다

그리고 아까는 1024를 나눴는데 0이 6개나 빠졌으니 10.24로 똑같이 3번 나누어 주면 값은 똑같이 나옵니다

실제 많은 질문들이 나왔는데 정확한 답변이 될듯해서 올려봅니다.

추가적으로 자신이 구입한 컴퓨터의 하드용량이 500GB 제품인제 사용공간이 130GB 정도만 표기되는 경우가 있습니다.

이런경우 본인이 하드디스크를 130GB로 분할을 했거나 아니면 윈도우XP 서비스팩1을 설치하셨기 때문입니다.

전자인경우 내컴퓨터 > 마우스오른쪽 클릭 > 관리 > 저장소(저장소관리) > 오른쪽 탭아래부분에

검정색으로 체크된 부분의 파티션을 할당해주고 포맷을 하면 사용이 가능합니다.

후자인 경우 윈도우XP 서비스팩2 이상의 상위 소프트웨어를 설치하시면 바로 해결이 가능합니다.

PS. 하드용량별 실제 컴퓨터상 표기 용량.

320GB = 298.023.223.877 (소숫점 이하 반올림)

500GB = 465.661.287.307 "

640GB = 596.046.447.754 "

750GB = 698.491.930.961 "

1TB = 931.322.574.615 "

1.5TB = 1.396.983.861.923 "

2TB = 1.862.645.149.230 "

구입하신 하드디스크 용량별 실제 컴퓨터가 표기하는 용량입니다. 참고하세요~

출처 : http://www.mypcshop.co.kr/bbs/board.php?bo_table=co_tiptech&wr_id=6

Part II. 기가와이파이(802.11ac)를 지원하는 공유기 네티스 WF2780 리뷰

JAESOO — Sun, 19 Oct 2014 14:45:08 +0000

리뷰글이 너무 길어서 첨부된 이미지등으로 게시물 하나로는 로딩시 시간이 많이 걸려 2개 파트로 나누어서 글을 올렸습니다^^;

리뷰 목차중 9~21번으로 2번째 파트입니다.

1. 이동통신은 4.5세대 LTE-A, 광대역으로진화, 와이파이는 이제 기가와이파이 5세대로진화.
2. 우리는 왜 802.11ac 기가와이파이가 필요한걸까?
3. 5세대 802.11ac 기가와이파이는 802.11N과 비교하여 무엇이 달라졌나?
4. 802.11ac를 지원하는 무선공유기는 어떤것들이있나? 11ac를 지원하는 제대로 된 성능을 가진 제품을 선택하려면?
5. 리얼텍 Soc 공유기들은 더 이상 스마트폰과 호환성문제가 없는것인가?
6. 802.11ac를 지원하는 무선랜카드는 어떤것들이 있나? 11ac를지원하는 제대로 된 성능을 가진 제품을 선택하려면?
7. 802.11ac를 지원하는 스마트폰들은 어떤것들이 있나?
8. 802.11ac를 지원하는 스마트폰에서는 왜 기가비트 속도를지원하지못하는가?

9. 802.11ac를 지원하는 기가와이파이 네티스 WF2780 공유기의특징은?
10. 하드웨어 제품스펙안내
11. 제품개봉과 구성물들
12. 제품외형 사진들:
13. WF2780 무선공유기 제품내부
14. 802.11ac를 지원하는 WF2190 USB 동글 무선랜카드:
15. 공유기 설정화면 UI 살펴보기
16. PC와 유선랜(Gigabit)으로 연결시 전송속도
17. WF2190무선랜카드(11ac지원) 전송속도
18. 스마트폰과 연결시 벤치비속도
19. IPTV와의 호환성은?
20. 070 인터넷전화기와의 호환성은?
21. 총평가

첫번째 파트글은 아래링크 클릭하시면 됩니다.
http://www.ppomppu.co.kr/zboard/view.php?id=review&page=1&divpage=6&no=30477

9. 802.11ac를 지원하는기가와이파이 네티스 WF2780 공유기의특징은?

네티스 WF2780은리얼텍에서 테스트베드로 사용된 RTL8812AR_Router를 모체로 개발되었습니다.
이 모델은 Wi-Fi Alliance에서802.11ac 인증을 물론 받았기 때문에 호환성문제는 없습니다.
WF2780은 리얼텍 RTL8812AR_Router를 모체로 개발되었기 때문에 RTL8812AR_Router에 사용된 메인CPU칩셋(RTL8197D), 5Ghz에사용된 무선랜모듈(RTL8821AR),2.4Ghz에 사용된 무선랜모듈(RTL8192CE) 등이동일하게 사용된 제품입니다.

아래 Wi-Fi Alliance에서 인증된 RTL8812AR 그림 참고:

WF2780에대한 자세한 스펙은 아래링크참고:
http://prod.danawa.com/info/?pcode=2228133&cate1=863&cate2=895&cate3=1083&cate4=0

1) 총 안테나 4개로 안테나 2개는 2.4Ghz, 나머지 안테나 2개는 5Ghz를지원하는 듀얼밴드이고, 각각의 주파수에서 2Tx 2Rx를 독립적으로 사용함. 안테나는 5dbi의 고감도 안테나가 장착됨.

제품 메인칩셋인 Realtek 8197D에서이 제품은 2.4Ghz와 5Ghz 이렇게 2가지의 주파수를 모두 지원합니다.
따라서 5Ghz가벽이나 콘트리트 등의 장애물이 약하기때문에 이런 점을 기존 2.4Ghz로 커버를 할 수 있습니다.
안테나는 총 4개가 장착되었는데, 2개는2.4Ghz를 위한 안테나이고, 나머지 2개는 5Ghz를위한 안테나로 각각의 주파수에서 2Tx 2Rx를 사용합니다.
그래서 2.4Ghz와5Ghz를 동시에 구동시키면서 2.4Ghz에서 2Tx 2Rx로 작동하여 무선 300Mbps를지원하고, 5Ghz/11ac에서는 2Tx 2Rx로 무선 867Mbps의 대역폭까지 지원할 수 있습니다. 단일 안테나 1개당 433Mbps의 속도를 내주고, 안테나가 2개이기때문에 867Mbps 링크속도를지원합니다.
802.11ac를 지원하는 갤럭시S4, 갤럭시노트3 등의 스마트폰에서도 433Mbps 링크속도로 동작합니다.
보급형모델들의 경우, 보통 안테나가 2개달려있고, 안테나가 2개일경우 2.4Ghz와 5Ghz를동시에 구동가능하지만, 각각 1Tx 1RX로만 동작하여 전송속도와 수신거리가 현저히 짧았습니다. 하지만이 제품은 2개의 주파수를 동시에 구동하면서 안테나가 각각의 주파수에 2개씩 별도로 독립적으로 동작하기때문에전송속도와 성능 역시 저하가 없는 고성능 모델입니다.

아직까지 5Ghz와802.11ac를 지원하는 기기들이 대중화되지못했고 아직 가정에서 사용하고있는 많은 무선기기들 예를들어 노트북, 스마트폰, 070 무선전화기, 스마트TV 등은 아직 2.4Ghz 주파수와802.11G 또는 802.11N을 사용하기때문에 기존 2.4Ghz와5Ghz를 동시에 지원하여 호환성에도 문제가 없습니다.

2) 주파수 간섭이 없는 5Ghz 사용가능+ 회절능력이 뛰어난 기존 2.4Ghz 동시사용가능

현재 시중에 풀린 대부분의 무선공유기들은 802.11N/2.4Ghz로 2.4Ghz에서는 사무실뿐만 아니라 가정집에서도 채널들이 중첩되어 여유채널이 없어속도저하현상이 발생합니다.
가정집에서조차도 070전화기용 AP, 그리고, 통신사에서제공해준 무선공유기, 기타 개인별로 구입한 무선공유기 등이 즐비하여 사실 지금 2.4Ghz에서는포화상태입니다. 주변에 고층건물과함께 회사가 많은 곳에서는 더욱 간섭이 많이 일어납니다.
또한 이러한 공유기 뿐만 아니라 2.4Ghz 주파수를 사용하는 무선마우스, 무선키보드, 블루투스, 전자렌지 등과도 충돌을 일으켜사실 2.4Ghz는 포화상태이며 간섭이 일어날 수 밖에 없습니다.
5Ghz에서는 이러한 가정기기들과도 충돌이 일어나지않고, 무선환경에서도 더 넓은 대역폭으로 중첩채널간섭없이 빠른속도를 낼 수있습니다.
단, 5Ghz에서는콘크리트벽 등 장애물에는 취약하기때문에 무선커버리지가 짧아지는 단점이 있기때문에 콘크리트벽등 장애물에서도 비교적 회절성이 뛰어난 기존 2.4Ghz의 주파수도 동시에 사용가능하여 편의성을 높였습니다.
현재 출시된 11ac 공유기들은대부분 5Ghz + 2.4Ghz의 듀얼밴드 방식의 공유기로 출시됩니다.

아래와같이 WF2780공유기는2.4Ghz + 5Ghz 듀얼밴드 공유기로 2.4Ghz SSID와 5Ghz SSID가동시에 구동되고 있음을 알 수 있습니다. 아래는 PC에서의 접속화면인데, 스마트폰에서도Netis 2G, Neits 5G 이렇게 2개의 SSID가보이게됩니다.

3) Gigabit유선랜 지원으로 1000Mbps 전송속도 지원.
(기가바이트 인터넷 지원이 가능하고, 내부네트워크에서기가바이트 대역폭지원으로 파일전송속도가 기존 100Mbps 공유기에비해 10배 향상)

일부 시범지역에서는 Gigabit 인터넷을시범운영하는 곳도 있지만 대부분 아직까지는 100Mbps FTTH 인터넷이 시행되고 있습니다.
하지만, 내부망에서는 사정이 달라지는데연결된 PC와 노트북, NAS 등이 모두 Gigabit를 지원할 경우 내부전송속도로 1000Mbps를 지원하기때문에 내부에서 파일전송시에 기존 100Mbps만 지원하는 공유기에서는 초당 최대 12메가의속도를 지원했던반면 이모델은 1000Mbps를 지원하는 기가비트유선랜이 장착되어 초당 120메가이상의속도까지 내줍니다. 이론상뿐만아니라 실제로도 전송속도가 대략 10배의 속도가 차이납니다.
예를들어 1.2기가 짜리 영화한편을 PC에서NAS로 전송한다면 초당 120메가속도를 내줄시 10초만에 전송이 가능합니다. 12기가짜리블루레이 고화질영화파일도 100초만에 전송이 가능합니다.
PC에 직접 물려 파일전송하는 규격중 가장 빠르다고할 수 있는 USB 3.0 외장하드가 보통 PC에 연결하여 실제 파일복사시평균적으로 초당 60~100메가정도의 속도를 내줄 수 있는걸 감안하면 네트워크상으로 초당 120메가속도까지 나온다면 답답한 100Mbps의 느린 파일전송환경에서 벗어날 수 있습니다.

4) 공유기IP를 입력하지않고 2780.com 도메인입력만으로 공유기접속가능

이제까지 사용해왔던 타사 공유기들의 경우, 공유기의내부사설IP인 예를들어 http://192.168.1.1 이런식으로 공유기 내부IP를일일히 수동으로 쳐야 공유기접속이 가능한데, 네티스 공유기는 공유기 모델명 뒤에 .com 만붙여주면 스마트폰이나 PC에서 공유기접속이 가능합니다.
별것아닌것같지만, 리뷰를 진행하면서 매번 IP접속을하지않고 도메인으로 공유기에 접속을하니 나름 편리했던것 같습니다.

5) 자체 구축한 무료 DDNS 지원

DDNS란 쉽게 말해서 고정IP와 도메인을 가지고 있지않은 가정집에서도 공유기에 서브도메인을 부여하여 매번 바뀌는 유동IP를입력하지않고도 주소창에 부여된 서브도메인을 입력하여 외부에서도 쉽게 공유기와 가정집에서 구축된 NAS, FTP, CCTV 등에 쉽게 접속할 수 있는기능입니다.
국내와 해외공유기를 통틀어 실제로 자체구축한 무료 DDNS를지원하는 공유기사는 몇곳 없습니다. 국내에서는 IPTIME, Netis, Wevo 등 일부 공유기사만 자체 DDNS를무료로 제공하고 대부분 유료서비스를 하고 있는 유료DDNS만 지원합니다. (예를들어 dyndns.org 와 같이 지금은 유료로 바뀐 유료DDNS만지원하는경우가 많습니다)
해외 공유기들의 경우도 자체 DDNS서버를구축하여 무료 DDNS를 지원하는 공유기들이 거의 없습니다.
원격에서 공유기에 접속하여 원격으로 WOL로 PC를켜거나 원격데스크탑으로 PC에 접속하여 원격조정을 하거나 FTP를 운영한다거나 NAS를운영한다고 가정시에 DDNS는 필수이기때문에 공유기 선택시에 자체 구축한 무료DDNS를지원하는지 유무는 중요할 수 있습니다.
다행히 Netis는xx.gonetis.com 형식으로 무료 DDNS를 지원합니다.
앞에 XX에는 예를들어 ppuppu.gonetis.com 이런식으로 원하는 닉을 지어서 자신만의 도메인을 등록해서 영구적으로 사용할 수 있습니다.

7) VPN서버 내장

이제까지 출시된 네티스 공유기들은 VPN서버를지원하지않은것으로 알고있는데, WF2780에서처음으로 VPN서버를 지원한것 같습니다.

예전 WF2190(브로드컴AP) 공유기리뷰때에도 타사 경쟁모델에는 VPN서버가 탑재되었지만 WF2190은 VPN서버기능이 없어 아쉬었는데이번 모델에서는 고사양 공유기인만큼 VPN서버기능이 추가되었습니다.

8) KT IPTV에서도 실시간TV와 VOD 다시보기둘다 가능한 모델

이제까지SKB와 LG U+ IPTV는 시중에 출시된 공유기에서도 정상적으로 동작했지만, KT 올레IPTV는 셋탑박스가 공인IP에서만 작동되도록 만들어져서 시중 공유기를 사용할 경우 실시간TV와VOD 다시보기중 둘중의 하나가 정상적으로 작동되지않았습니다.
대부분의 IPTV는 공유기환경에서 실시간TV와 VOD 다시보기가 가능하지만, IPTIME 이나 기타 타사공유기들에서는 KT IPTV를 지원하지못해 SK브로드밴드와 LG U+와 다르게KT IPTV에서는 유일하게 VOD 다시보기가 가능하지않습니다. 따라서 별도로 KT 전용AP/공유기를 신청해서 사용해야만 VOD 다시 보기 기능까지 작동했습니다.
하지만, 네티스 WF2780은 KT 올레IPTV에서도 실시간TV와 VOD 다시보기를 동시에 사용가능하도록 만들어져 그동안 KT 올레IPTV를 사용해온 유저로서 참 반가운 기능입니다.
그동안 유료로 KT전용 AP/공유기를 사용한유저분들도 더 이상 달달이 장비임대료를 낼 필요가 없어 메리트가 있습니다.

10. 하드웨어 제품스펙안내

제품스펙:

제품스펙을 간단히 살펴보면, 리얼텍RTL8197D CPU(메인네트워크칩셋)가 탑재되어있고, 8MB 플래쉬롬, 64MB램, 5dbi 안테나 4개 탑재, 802.11ac를지원하는 5세대 와이파이 공유기임을 알 수 있습니다.
그리고, 안테나는 총 4개로2개는 5Ghz를 위한 안테나이고, 나머지 2개는 2.4Ghz를 위한 안테나입니다. 주파수는 5Ghz와 2.4Ghz를동시에 지원하고, 대역폭은 80Mhz까지 지원하여 최대 867Mbps 속도를낼 수 있습니다.
또한, 유선랜으로는 10/100/1000 Mbps를 지원하는 기가비트랜임을 알 수 있습니다.

기존에 2008~2012년경에 출시되어 아직도 가정이나 회사에서 주로 사용되고있는 구형 공유기들이 대부분 802.11N 공유기이고, 이런 공유기들의 사양은 보통, CPU는 150~350Mhz급, 플래쉬롬은1~4MB, 램은 8~16MB가 탑재되었고, 보급형은 1TX 1RX로 최대 150Mbps까지 지원하고, 상위모델의 경우 2TX 2RX로채널본딩과 MIMO를 지원하여 최대 300Mbps까지 지원했습니다.

사실 위와같은 사양의 구형공유기로도 과거에는 원할한 사용이 가능했으나 이제는 초고화질영화파일들이 배포되면서 이러한 풀HD급 동영상조차도 실시간 스트리밍하는 시대에 이르렀고, 토렌트에서 고용량파일을 동시다발적으로다운받을 경우, 공유기가 트래픽을 견디지못하고 다운되거나 속도가 느려지는 증상이 종종 발생하곤하여 이제는 더 빠른 CPU와더 넉넉한 RAM용량이 필요하게되었습니다.

또한 5세대 와이파이 공유기는 무선으로도867Mbps~1.3Gbps의 기가급 대역폭을 처리해야하고, 기존 유무선시대에 100Mbps급을 처리해야했던 때보다 8배이상의데이타를 처리해야하기때문에 그만큼 CPU와 RAM 사양등도 기존 구세대 공유기에비해 2~3배이상의고사양이 필요하게됩니다.

이번 5세대 와이파이 공유기인 WF2780은 CPU 처리속도가 기존 구세대 공유기에비해 2~3배 더 빨라졌고, 플래쉬롬과 램은 기존 공유기에비해4~8배가량의 하드웨어사양이 향상되었고, 무선으로는 기존 11N방식의 최대 40Mhz의대역폭을 뛰어넘어 80Mhz의 대역폭으로 최대 867Mbps까지 지원됨을 알 수 있습니다.

공유기에서 램용량은 크면 클수록 더 많은 커넥션을 수용할 수 있기때문에 램은용량이 크면 클수록 더 좋습니다. 요즘같이 토렌트로 초고화질 풀HD와같은 대용량파일 여러개를 동시다발적으로 다운받고, 업로드하고또한 블루레이와 같은 초고화질 영화파일조차 스트리밍하는 시대에 64MB의 고용량램은 이제는 필수이지않나싶습니다.
또한 위와같이 빡센 작업을 하면서 온라인게임을 랙없이 즐기려면 그만큼 공유기도더 좋은 CPU와 더 고용량의 RAM이 필요한것은 당연할지도 모르겠습니다.

그리고, 유선랜으로는 기존 대부분100Mbps가 내장된 공유기였지만, WF2780은 5세대 기가와이파이 공유기인만큼1개의 WAN과 4개의 LAN포트 모두 기가비트를 지원하여내부네트워크에서도 PC to PC로 파일전송시에 기존에비해 10배 빠른 속도향상이 있습니다.
실제 성능이 어느정도일지는 이후 진행되는 테스트를 통해 알아보겠습니다.

11. 제품개봉과 구성물들

제품박스 전면사진:

제품박스를 처음 본 순간 세로로 참 길쭉하다는 생각을 했습니다.
왜 그런지는 박스개봉후 제품에 장착된 안테나를 보시면 이해가 되실겁니다.
제품박스 전면에는 netis 회사로고와모델명 그리고, 이 모델의 간단한 스펙과 특징들이 안내되어있습니다.

어떤 내용들이 적혀있는지 확대해보겠습니다.

왼쪽하단에는 이 제품의 가장 큰 특징 3가지가그림과함께 나와있습니다.
기가와이파이라는 802.11ac 최신 무선랜규격이라는점, 그리고 5Ghz 와2.4Ghz 이렇게 2개의 주파수를 동시에 사용하는 듀얼밴드 기능이 있고 유선랜이 1000Mbps(기가비트)라는 점을 강조하고있습니다

오른쪽 하단에는 와이파이 얼라이언스 로고가 박혀있습니다.
회사에 확인결과 Netis가Wi-Fi Alliance 에 정식멤버가 되었다고합니다.
반가운 소식이네요 : )
와이파이 얼라이언스에대해 생소하고 잘 모르시는분들도 있으실 것 같은데요. 모르시는분들을위해 간단하게 알려드리겠습니다.
와이파이 얼라이언스란 Wi-Fi 표준을 규격하고, 이끄는 비영리단체입니다.
우리가 보통 알고 있는 IEEE 802.11 규격들은Wi-Fi Alliance에서 표준을 규격하고, Wi-Fi Certified와 같은 로고들도 이곳에서 인증하고있습니다.
사실상 국내법상 WiFi Certified 인증을받아야하는 강제성은 없어, 인증테스트를 받지않아도 되지만 스마트폰의 경우 내수용모델조차도 100% 전량인증테스트를 받습니다.
애플, HTC, 모토토라등의 해외제조사뿐만 아니라 삼성, LG, 팬텍과 같은 국내제조사들 조차도 적지않은 비용까지 들여가면서 테스트를 마친후 인증로고 마크를 받게됩니다.
대부분 해외에 수출하기위함이 가장 큰 것으로 알고 있고있지만, 또다른이유는 Wi-Fi인증 테스트를 거치면서 유무선공유기나 다른 Wi-Fi 기기들과호환성문제를 없애기위함입니다.
유무선공유기도 와이파이 인증을 받아야하는 강제성은 없지만 인증을 받음으로써스마트폰이나 기타 와이파이 인증기기들과 호환성문제가 더이상 발생하지않기위함입니다.
즉, Wi-Fi Certified 와 같은 인증로고가 있다는것은 스마트폰이나 스마트TV 등 기타 여러 와이파이인증을 받은 기기들과 호환성문제에서 벗어날 수있다는것을 의미합니다.
수많은 Wi-Fi를사용하는 기기들이 있지만, 표준을 지키지않은 검증되지않은 WiFi기기들이난립하면서 Wi-Fi기기끼리 호환이 되지않는 등의 호환성문제가 대두되면서 Wi-Fi Alliance가Wi-Fi Certified 인증로고를 만들게 됩니다.
이 로고들은 철저하게 Wi-Fi Alliance기관이인정한 Wi-Fi 인증테스트 기관에서 Wi-Fi기기끼리 호환성 테스트를 거친후 이과정을 통과한 제품들에한해 인증로고를받을 수 있습니다.
이러한 제품들은 Wi-Fi 호환성테스트를 모두 거친 표준규격을 준수한 제품들이라는 뜻입니다.
제품전면박스에 나와있는 로고는 정확히 말하면 Netis 회사가 Wi-Fi Alliace정식멤버임을 나타내주는 로고입니다.

제품 하단 중간에는 위와같이 이 제품의 주요한 스펙이 안내되어있습니다.

제품박스 밑면사진:

제품박스 밑면에는 위와같이 자세한 스펙이 나와있습니다

제품박스를 바로 개봉했을때 사진:(비닐로 싸여져있는 공유기와 크래들)

제품박스를 처음 봤을때 왜 이렇게 박스가 길쭉한가 싶었는데, 역시네티스 특유의 장대 안테나때문이었습니다.
여기에 사용된 안테나는 총 4개 이며 4개모두 5dbi로 보통 다른 타사 공유기에 사용되는 2~3dbi보다 고출력이고 전파가 더 강하기때문에 같은 거리에서도 수신감도가 더높다는 장점이 있습니다.
다만, dbi가5dbi 이상으로 과도하게 너무 높을 경우에는 안테나가 특정한 방향으로만 전파를강하게 방사하는 지향성을 띄울수도 있기때문에 보통, 특별한 환경이 아니라면 무선공유기에는 5dbi 이상으로는장착되지않습니다.

제품구성물들 사진:

제품구성물은 제품본체, 메뉴얼, 그리고, 기가비트를지원하는 이더넷케이블, 아답터 그리고, 제품을 세로로 세울수 있게 크래들이 준비되어있습니다.

메뉴얼은 위와같이 공유기를 처음 접하는 초보자들도쉽게 설치하고 세팅할 수 있도록 만화로 그려져있습니다.
딱딱한 메뉴얼보다는 만화가 더 친숙하고 이해하기에도 더 쉽지않을까요?^^

12. 제품외형 사진들:

바닥면에는 벽걸이를 할 수 있는 마운트 홀이 있습니다. 국내산공유기들은 마운트홀이 없지만 보통 해외에서도 판매되고 있는 글로벌 모델들은 마운트홀이 존재합니다. 사진에서는 잘 보이지는 않지만, 마운트홀에도케이스내부와 통풍이 되도록 구멍이 뚫려져있습니다. 따라서 장시간 켜져있는 공유기 발열이 마운트홀이 뚫려져있는 밑면으로도발열을 방출할 수 있습니다.

위 사진은 제품전면에 뚫려있는 타공.
제품을 분해하게되면 위 구멍이 뚫려있는 위치에 기판에서 방열판으로 씌어져있는 Realtek 주칩셋이자리잡고 있고, 이곳을 통해 칩셋에서 발생하는 발열을 효과적으로 방출하는 것 같습니다.
제품의 전면에는 위와같이 발열을 효과적으로 방출하기위해 구멍이 뚫려있습니다. 공유기는24시간, 365일 항상 켜놔야하기때문에 발열을 방출하기위한 제품디자인설계 역시 중요합니다. 발열을방출하기위한 노력한 흔적들이 보입니다.

안테나쪽 사이드 모습입니다. 역시 여기에도 타공이 뚫려있어발열을 효과적으로 방출할 수 있습니다.

제품 옆면입니다. 이곳에도 타공이 뚫려있어발열을 방출할 수 있습니다.
전면, 밑면, 2개의 옆면으로 이렇게 제품의 4면에타공이 모두 뚫려있어 장시간 사용해도 발열에 효과적으로 대응할 수 있을 것 같습니다.

아래는 거실 TV거실장 옆에 위치를 한 공유기사진들입니다.

기본제공되는 크래들을 이용해서 위와같이 세울 수 있습니다.
5dbi가 내장된 4개의 장대 안테나들때문인지 꽤 뽀대가 나는 것 같습니다

위와같이 안테나는

180도 회전이 가능하여 자유자재로안테나 방향위치를 선정할 수 있습니다.

위 사진은 크래들없이 눕혀놓은 모습입니다. 크래들이없이 눕혀놓으니 모양새가 살짝 아쉬워보입니다.

제품후면 사진입니다. 후면에 보이는 빨간색버튼은WPS 버튼입니다. 파란색포트는 WAN포트이고, 나머지 왼쪽 4개의포트는 LAN포트입니다. 그리고, 파란색 WAN포트 왼쪽에 Default라고 써져있는 구멍은 Reset 버튼입니다.
공유기를 초기화할때에 이 샤프나 볼펜 등으로 Reset버튼을10초이상 눌러주면 초기화를 할 수 있습니다.

가장 왼쪽에 있는 기기는 WF2780, 2번째는IPTIME 무선랜카드, 3번째는 WF2190 무선랜카드입니다.
2번째와 3번째는 WF2780 무선공유기 성능을 테스트하기위해 필요하여 함께 준비되었습니다.

13. WF2780 무선공유기제품내부
(케이스를 분리하여 내부 메인 Real칩셋과 메모리IC, 안테나IC 사진확대

)

나사를 풀고 케이스 윗면을 분리하면 WF2780 제품내부는 위와 같습니다.
사진에 보이는 각 칩셋들을 보면서 하나씩 어떤모듈인지 살펴보겠습니다.

위 사진에 보이는 RTL8197D가CPU 역활을 하는 주 메인네트워크칩셋입니다.
현재 RTL8197D는리얼텍의 네트워크 칩셋 중 네트워크 처리 성능이 가장 빠른 최상위 칩셋입니다.
RTL8197D는 500 to 660MHz로 동작하는 Lexra 계열의 CPU 코어와 RTL8367RB 스위치가 통합된 형태의 SoC(System on Chip)칩셋입니다.

무선 네트워크는 2.4GHz와5GHz의 듀얼 밴드 구성을 지원하기 때문에 2개의 칩셋이 사용됩니다 하나는 802.11ac지원을위한 RTL8812AR과 나머지 하나는 802.11n 을 지원하는 RTL8192CE 칩셋입니다.
위 사진에 보이는 무선네트워크 칩셋은 802.11ac/5Ghz 지원을 위한 RTL8812AR 입니다. 2Tx2Rx 스펙으로, 867Mbps의 속도를 낼 수 있습니다.
이 칩셋을 통해 802.11ac를지원하는 갤럭시S4, G2, 베가시크릿노트 등의 최신스마트폰과 5Ghz로 통신을 할 수 있습니다. 또한802.11ac를 지원하는 최신 노트북이나 기타 802.11ac를 지원하는 기기들과 5Ghz로 통신할 수 있습니다.

사진에 보이는 RTL8192CE는2Tx2Rx에 802.11N을 지원하는 무선네트워크칩셋입니다. 이칩셋을 통해 기존 802.11N 를 지원하는 구형기기들과도 통신할 수 있습니다. 기존 구형스마트폰, 구형노트북, 070전화기, 스마트TV 등이이 무선네트워크칩셋과 통신할 수 있습니다.

왼쪽에 납땜이 되어있는 선

2개가2.4Ghz 안테나에 연결된 선들이고, 오른쪽에 SMA타입으로 되어있는 선 2개가5Ghz 안테나에 연결된 선들입니다.
사진을 잘 보시면 왼쪽에 납땜되어있는 2.4Ghz 안테나선2개 회로 위쪽으로 칩셋이 보이는데 RTL8192CE(802.11N지원) 칩셋입니다. 2개의선이 연결된 회로를 보시면 8192CE 칩셋방향으로 연결된것을 알 수 있습니다.
나머지 SMA타입의 5Ghz안테나선2개는 위쪽으로 RTL8812AR 칩셋쪽에 연결된걸 알 수 있습니다.

사진에 보이는 Nanya NT5TU32M16DG-BE는 64MB RAM입니다. 일반 보급형 공유기에는 16MB램이장착되어있는데, 그에비해 4배의 고용량입니다.

RTL8367RB는 Gigabit 이더넷 Switch 컨트롤러입니다. 이칩셋을 통해 4개의 기가비트 유선랜과 1개의 WAN 포트를지원하게됩니다.

eFeon은 공유기에 내장된 8MB Flash ROM입니다. 이곳에 펌웨어가 저장됩니다.

사용된 Capacitor는105도씨의 커패시터가 사용됨을 알 수 있습니다.

14. 802.11ac를 지원하는WF2190 USB 동글무선랜카드: “

WF2190 무선랜카드에대한자세한 스펙은 아래링크참고:
http://prod.danawa.com/info/?pcode=2228103&cate1=863&cate2=895&cate3=1084&cate4=0

WF2870은 802.11ac 규격이기때문에 PC나 노트북에 물려 정확한 성능테스트를 하기위해서 동일한 802.11ac 규격의 무선랜동글이 있어야하겠지요?
11ac 무선랜카드는 같은 회사의 WF2170을 사용하여 테스트하였습니다.
이 무선랜카드는 11ac 공유기리뷰에 사용된 WF2780 무선공유기 성능을 테스트하기위해 사용되었으므로 엑스트라인 WF2190은 자세한 리뷰보다는 간결하게 사진위주로 나열했습니다.
이 랜카드는 제품성능테스트는 성능테스트구간에서 함께 테스트될 예정입니다.

다음은 WF2870 리뷰를 하면서 함께 테스트에 사용된 WF2170 무선랜 USB 동글 사진들입니다.

(WF2190 무선랜카드)제품박스 전면사진:

제품전면에는 주요한 스펙들이 기재되어있습니다

.
802.11ac(867Mbps) 무선랜규격이라는 점과 5Ghz와 2.4Ghz 듀얼밴드를지원하고, 5dbi의 안테나가 사용되었다고 나와있습니다.
또한 Soft-AP의무선공유기 기능도 지원한다고 나와있습니다.
(PC나 노트북의 USB에 연결하여 무선랜카드를 무선공유기처럼 사용할 수 있는 기능입니다)

이제품 역시 Wi-Fi Alliance 로고가제품전면에 부착되어있습니다.

(WF2190 무선랜카드)제품박스 밑면사진:

(WF2190 무선랜카드)박스개봉후 사진과 구성물들:

제품전면:

제품전면은 상단은 유광이고, 하단은 무광입니다. 그리고, 안테나는5dbi 안테나가 2개가 제공되는데 일체형이 아니라 별도로 분리하고 장착이 가능한 SMA타입으로되어있습니다.

제품후면:

제품후면은 유광입니다. 광이 나서 그런지 후면이더 고급스러워보이네요.

제품에 사용된 USB 3.0 인터페이스:

WF2190은 802.11ac 규격이고, 867Mbps의대역폭의 링크속도를 내주기때문에 USB 2.0으로는 커버가 되지않아 기본적으로 USB 3.0 규격이사용되었습니다.
사진에서보시다시피 파란색의 USB 포트로3.0규격이 사용되었음을 알 수 있습니다.

함께 제공되는 USB 3.0 연장 스탠드기능이 있는 크래들:

함께 제공되는 크래들은 스탠드기능이 있어 기능적으로나 외관상으로도 부속물로 제공되는 부품치고는 꽤 쓸모있습니다.
USB 무선랜카드가 USB 3.0이므로 크래들 역시 USB 3.0 규격을 지원합니다.
길이도 무려 1.8M짜리라어느환경에서도 충분히 넉넉한 길이입나다.
시중에 판매되고있는 USB 3.0 도킹이나크래들가격만해도 대략 7~8천원은하고, 연장선도 보통 길이가 1.2M전후로 좀 짧은편인데 이건 시중에서 별도로 사는 USB 도킹보다더 쓸만한 것 같습니다.
다른회사 802.11ac 무선랜카드도이런 USB 3.0 크래들이 제공되나 확인했는데 d-link사 제품도 비슷한 크래들이 제공됩니다. 그외 iptime 등다른 11ac 무선랜카드들에는 연장선만 제공되고, 이런 크래들이 없다는 점을감안하면 부속물이지만, 꽤 메리트있어 보였습니다.

USB 3.0 외장하드나 USB 메모리 등다용도 USB 3.0연장선으로 사용될 수 있는 크래들:

PC케이스 후면 메인보드 USB 3.0단자에 꽂아 연결해놓은후 책상위에 연결해놓으면 무선랜카드를 사용하지않을때는 사진과같이 평소에는USB 3.0 외장하드나 USB메모리를 꽂아서 사용해도 될듯합니다
PC케이스 전면에 USB 3.0포트가 없는 구형PC케이스일 경우 이렇게 USB 3.0 도킹으로도사용할 수 있어 더 유용할 것 같습니다.
부속물이라 성능저하가 일어나지않을까 싶었는데, USB 3.0 외장하드를 크래들에 연결해서 속도테스트를 해보았는데 USB 3.0으로 정상적으로 연결되고 속도 역시 초당 70~100메가의 전송속도로 잘 나와주었습니다.

유의사항:
테스트하면서 한가지 변수가 생겼는데, 인텔H67칩셋메인보드에 기본장착된 USB 3.0포트에 연결하면 USB 2.0으로 작동하거나 인식이 잘 안되는 증상이 있었습니다.
확인결과 802.11ac 무선랜카드인ipTIME A2000UA도 동일한 칩셋을 사용하고 이 제품 역시 메인보드 내장 usb 3.0포트와호환성문제가 발견되었습니다.
그래서 아래 트랜샌드 USB 3.0 외장카드를구입하여 장착하니 정상적으로 인식되었습니다.
호환성에 문제가 된 메인보드 내장 USB 3.0포트는 2가지 메인보드에서 나타났는데 1개는 Nec/Renesas D720200/D720201 칩셋이었고, 나머지 1개는 Etron EJ168A 였습니다.
별도로 구입한 트랜샌드 USB 3.0 외장카드의칩셋은 Nec/Renesas D720202 로 이 칩셋은 문제가 없었습니다.
인텔H77칩셋부터는 인텔USB 3.0포트가 기본장착되어 별 문제가 없었고, H67등 구형메인보드를 사용하시다가 호환성에 문제가 생긴다면 외장USB 3.0카드를 구입하실때 Nec/RenesasD720202 칩셋이나 그 이후에 생산된 최신칩셋이 장착된 제품을 구입하시는게 좋을것 같습니다.

별도로 구입한 USB 3.0 외장카드:

WF2780 무선공유기와 USB 무선랜카드의 안테나길이 비교:

이 무선랜카드를 처음 개봉하고 가장 먼저 놀란건 안테나 길이와 DBI입니다.
보통, USB 동글무선랜카드에 사용되는 안테나는 2dbi가 사용되는데, 이 무선랜카드는 무려 5dbi의장대안테나 2개가 사용됩니다.
사진에 보이는 공유기는 WF2780 공유기인데, 공유기에사용된 5dbi 안테나갈이와 동일합니다. 정말 거대하지요?
5dbi 안테나 2개를 조립하고 크래들에 꽂고보니 긴 안테나가 뿔처럼 보이고 마치 버팔로소 같아 보이네요 ^^

사진에 보이는 하얀색 무선랜카드는 IPTIME 무선랜카드인데, 안테나만 보면 IPTIME 무선랜카드가 아기자기하게 보일정도록 WF2190 안테나가 큽니다.

15. 공유기 설정화면 UI 살펴보기

UI편에서는 세팅방법과 주요한 특징과 이전모델들에는 없었던 새로운 기능 위주로 살펴보겠습니다.
Netis WF2780 공유기 접속시에는 http://192.168.1.1 과같이 별도로 공유기IP주소를 입력해도 되지만, 더 쉬운방법이 있습니다.
PC에서나 스마트폰에서 http://2780.com 을입력하시면 더 어렵지않게 접속하실 수 있습니다. 앞에 2780은공유기 모델명숫자를 의미합니다.
IP주소가 아닌 도메인으로 공유기에 접속을 할 수 있게끔하여 초보자를 위한 배려가 돋보입니다.
이제 공유기에 접속하면 아래와같은 화면이 뜹니다.

1) 초기접속화면

초기접속화면은 위와같습니다.
인터넷연결방식은 기본세팅인 유동IP방식으로놔두고, 무선네트워크이름을 충돌을 피하기위해 반드시 원하는 이름으로 변경해줘야합니다.
그리고 무선접속비밀번호 역시 반드시 변경해줘야합니다.
초보자들은 위 4가지 세팅만으로 쉽게 공유기세팅을마칠 수 있고 바로 사용하실 수 있습니다.

2) 2.4Ghz 무선기본설정화면

2.4Ghz 무선세팅화면입니다.
11b 또는 11g 방식을 사용하는 구형기기가있을 경우에는 호환성을 위해 B+G+N 으로 해주시고, 11g와 11N만 있을경우에는 G+N으로세팅하셔야합니다. 11N 기기만 있을 경우에는 11N으로 세팅하시면 됩니다.
11b 또는 11g와 같은 구형기기가 없을 경우에는 최적의 속도를 위해서 11n으로 해주시는게 좋습니다.
채널간격은 채널본딩을 할 경우에는 40Mhz로해주시고, 채널본딩을 하지않을 경우에는 20Mhz로 해주시면됩니다.
스마트폰의경우, 2.4Ghz에서는채널본딩을 지원하지않아 20Mhz만 지원하여 20Mhz로 하셔도 속도는 동일하게나옵니다.
다만, 노트북이나 무선랜카드는 보통채널본딩을 지원하기때문에 노트북도 사용하신다면 40Mhz로 해주시면 됩니다.
채널은 방통위 권고가이드에따라 비중첩채널인 1,5,9,13번의 채널을 선택합니다. 사용환경에따라 주변AP와의 간섭이 없는 채널선택을 위해서는 Wifi-Analyzer, Wifi Manager 등을 사용해서 주변AP들과 간섭이 없는 최적의 채널을 선택합니다.

위 화면을 예를들면 1번채널은 오버래핑된 AP들이단 1대도 없고, 100%의 가장 좋은 점수를 보여줍니다. 점수가 높은순으로 채널을선택하면 됩니다.
단, 이 어플들은 해외어플이기때문에 국내사정에 맞지않아 방통위 권고라인채널인 1,5,9,13번 외에 다른채널도 추천하기때문에 1,5,9,13번 위주로 선택하시면 됩니다.

3) 2.4Ghz 무선보안설정

위 화면은 2.4Ghz 무선보안설정화면입니다.
보안방식은 WPAPSK 또는WPA2PSK로 선택하시되 가장 높은 보안방식인 WPA2PSK로선택하시는걸 추천합니다.
다만, 간혹 WPA2PSK를 지원하지않는 구형기기들은 WPAPSK로 선택하시면 됩니다. 단, 인증방식은반드시 AES로 선택해야합니다.
TKIP는 RC4 엔진을 사용하기때문에 11g의 54Mbps의 속도만 지원하므로 11N속도를내기위해서는 반드시 AES를 선택해야합니다.

4) 2.4Ghz 무선고급설정

위화면은 무선고급설정화면입니다.
별도로 만져주실부분은 없고, 이 기기의 특성때문인지 무선출력감도를100%로로 했을경우 벤치비에서 속도가 더 떨어지는 증상이 있었습니다.
50%로 낮췄을경우 벤치비에서 2.4Ghz에서 35~50Mbps에 가까운 속도가 일정하게 나와주었지만, 100%로 세팅했을경우에는 오히려 20~30Mbps로 속도가 내려가는 증상이 있었습니다.
테스트결과 무선출력감도를 50%로 했을때 가장 무난한 속도를보여주었습니다.

5) 5Ghz 무선기본설정화면

다음은 5Ghz 세팅화면입니다.
별도로 만져주실 부분은 없습니다.
채널간격은 20/40/80Mhz 이렇게3개를 모두 지원하며 기본 80Mhz로 해두셔야 11ac를 사용하실 수 있습니다.

6) LED설정

새로 추가된 기능으로야간에 LED가 깜박거리지않도록 LED를 OFF로해서 잠자는시간에 거슬리지않도록 하는 기능입니다.
위와같이 LED가 꺼지는 시간을 세팅할 수 있습니다.

7) DDNS설정

DDNS기능입니다.
Netis는 자체적으로DDNS서버가 구축되어 무료로 DDNS기능이 제공됩니다.따라서 공유기에 서브도메인을 부여할 수 있습니다. 사용방법은간단합니다.
사용자이름에 원하는ID를 적고 중복검사를 한후 ID등록만 눌러주시면 등록이 됩니다.
예를들어 netis2780이라는 ID를 등록했다면 netis2780.gonetis.com 이라는 서브도메인이 부여됩니다.
그럼 외부에서 공유기또는 집 PC에 원격으로 접속하거나 NAS에 접속할때 이 서브도메인을 입력하시면 됩니다.

8) IPTV세팅

가정에서 KT IPTV를 사용하는 경우 꼭 필요한 기능입니다.
KT IPTV는 KT전용 AP/공유기에서만 작동하기때문에 그동안 KT IPTV를 사용하는 사용자를은 KT IPTV 전용 AP를 매달 이용료를 내고 사용해야했습니다.

다행히 WF2780의 경우 KT IPTV를 지원할 수 있는 기능이 내장되어있습니다.

사용법은 KTIPTV지원에 사용함에 체크하고,연결포트는 1~4번포트중 하나를 선택한후 해당포트에 KT셋탑박스를 연결해주면됩니다.
예를들어 4번포트를 선택했다면 공유기의 4번포트에 KT 셋탑박스를 연결해주셔야합니다.이렇게하면 실시간보기 +VOD 다시 보기를 모두 완벽하게 지원합니다.

9) VPN서버설정

기존하위모델에는 VPN서버 기능이 없었는데, 이 모델이 처음으로 VPN서버기능이 추가된 것 같습니다.
사용법은 계정 ID와 패스워드에 원하는 ID,PASSWORD를 기입하고 할당될 ID에 내부IP를 입력하시면 쉽게 등록을 할 수 있습니다.

10) 펌웨어업그레이드화면

펌웨어 업그레이드화면입니다.
펌웨어 업그레이드는 반드시 PC와 공유기를 유선으로 연결한후 하셔야합니다.그렇지않고 무선으로 펌웨어 업그레이드를 할 경우에는업그레이드가 되더라도 제대로 펌웨어업그레이드가 되지않은 경우가 많아 공유기시스템이 불안정해지거나 이상해지는 증상이 발생하곤합니다.
따라서 펌웨어 업그레이드시에는 반드시 유선으로업그레이드를 해주셔야합니다.
이 점을 꼭 알려드리고싶어서 펌웨어 업그레이드화면을넣었습니다.

그리고,공유기에서도 무선랜으로 펌웨어 업그레이드시에는펌웨어 업그레이드가 되지않도록 제한기능을 두면 좋을텐데, 이런 기능이 없는것은 다소 아쉽습니다.

16. PC와 유선랜(Gigabit)으로 연결시 전송속도

Netis WF2780 공유기는 WAN 1포트와 LAN포트 4개모두 기가비트를 지원합니다.

따라서 유선랜으로 1000Mbps대역폭을 낼 수 있어 파일전송시 기존 100Mbps만 지원하는 공유기보다 10배 빠른파일전송속도를 낼 수 있습니다.
실제로 어느정도의 속도를 내는지 테스트해보겠습니다.
비교를 위해 먼저,기존 100Mbps만 지원하는 공유기 연결시 전송속도입니다.

1) 기존 100Mbps 구형공유기에서 PC-PC파일전송시 속도

위와같이 PC2대가 100Mbps로 연결되었습니다.

파일전송시에 속도테스트를 위해 iperf가 사용되었습니다.
1번PC는 192.168.1.2이고,2번 PC는 192.168.1.3입니다.
윈도우사이즈는 300K이고,100초동안 10초 간격으로 테스트하도록 옵션을 주어 테스트하였습니다.
1번 PC에서 2번 PC로 파일전송 테스트를 하는 화면입니다.
위와같이 초당 11.8MB/s속도가 나옵니다.Bandwidth(대역폭)은 역시 99.1~3Mbps로 100Mbps로 연결되었음을 알 수 있습니다.

위 화면은 실제로 윈도우7에서 PC-PC로 파일전송을 하는 모습니다.
사용된 파일은 3.3기가의 영화파일이 사용되었습니다.
초당 최대 12.1MB의 속도가 나옴을 알 수 있습니다.iperf에서 테스트한 속도와 근사한 속도가나옴을 알 수 있습니다.

2) WF2780(기가비트)지원 공유기에서 PC-PC파일전송시 속도

위와같이 PC2대가 네티스 WF2780공유기에 1기가비트(1000Mbps)로 연결되었습니다.

파일전송시에 속도테스트를 위해 iperf가 사용되었습니다.
1번PC는 192.168.1.2이고,2번 PC는 192.168.1.3입니다.

윈도우사이즈는 300K이고,100초동안 10초 간격으로테스트하도록 옵션을 주어 테스트하였습니다.
1번 PC에서 2번 PC로 파일전송 테스트를 하는 화면입니다.
위와같이 초당 무려 116~117MB/s(Mbps로는 936Mbps) 속도가 나옵니다.

Bandwidth(대역폭)은 978~982Mbps로 1000Mbps(1기가비트)로 연결되었음을 알 수 있습니다.

위 화면은 실제로 윈도우7에서 PC-PC로 파일전송을 하는 모습니다.
사용된 파일은 2.6기가의 영화파일이 사용되었습니다.
초당 최대 141MB/s의 속도가 나옴을 알 수 있습니다.
평균적으로는 초당 120MB/s가 나옵니다.(Mbps로는 960Mbps)
Mbps로는960Mbps 이므로1000Mbps 대역폭을 거의 다 풀로 사용하고있음을 확인할 수 있습니다.
기존 구세대 100Mbps공유기에 연결시에는 최대 초당 12MB/s가 나왔고, 기가비트를 지원하는 WF2780 공유기에 연결시에는 평균 초당 120MB/s가 나왔기때문에 정확히 10배의 전송속도의 차이가 나고있음을 확인할 수 있습니다.
특히,기가비트를 지원하는 NAS가 구축되어있는 환경에서는 백업이나 파일전송시 이런 기가비트 공유기를사용하면 전송속도가 10배빨라지기때문에 충분히 메리트가 있습니다.

17. WF2190무선랜카드(11ac지원) 전송속도

이번에는 PC에 11ac 무선랜카드인 WF2190을 연결후 다른 PC로 파일전송을하여 어느정도의 속도가 나오는지 전송속도를 측정해보았습니다.
여기에서는 5Ghz/11ac를 지원하는 네티스 WF2190 무선랜카드(11ac지원 안테나 2개 달린 랜카드)와 2.4Ghz/11N을 지원하는 IPTIMEN600UA무선랜카드(11N지원 안테나 2개 달린 랜카드)가 사용되어 11n에서 11ac로 바뀌면서 어느정도의 속도향상이 있는지 살펴보겠습니다.

테스트한 환경은 WF2780공유기와 PC1(WF2190랜카드장착), PC2가 모두 같은 방안에서 테스트하였습니다.
1번PC는 192.168.1.2이고,2번 PC는 192.168.1.3입니다.

1) 구세대 N600UA 무선랜카드(11N지원/2.4Ghz)로 PC-PC 파일전송시 속도

iperf를사용하여 윈도우사이즈는 300k, 100초동안 10초마다 전송테스트를 하였습니다.
화면과같이 초당 11.1~11.3MB/s(88Mbps)의 속도가 나옵니다.

대역폭은 93~94.9Mbps가 나옵니다.

실제파일전송시에는 최대 11.2MB/s가 나옵니다.
같은 방이 아닌 다른방이나 원거리에서는 2~4MB/s정도가 나왔습니다.

이제 다음으로 11ac지원 랜카드인 WF2190으로 5Ghz에서 테스트해보겠습니다.

2) Netis WF2190 무선랜카드(11ac지원/5Ghz지원)로 PC-PC 파일전송시 속도

PC1에 WF2190USB무선랜카드가 설치되어있고,PC2로 파일전송테스트를 합니다.

WF2780공유기에 연결된 연결화면:

위와같이 WF2780공유기에 5Ghz SSID로 연결되었습니다.

위와같이 5Ghz에서 867Mbps의 링크속도로 연결되었음을 알 수 있습니다.

iperf를사용하여 윈도우사이즈는 300k, 100초동안 10초마다 전송테스트를 하였습니다.
화면과같이 초당 26.5~39.1MB/s의 속도가 나옵니다.

대역폭은 222~328Mbps로 연결되었음을 알 수 있습니다.

위그림은 PC1(WF2190랜카드장착)에서PC2로 파일전송을했을때 전송속도입니다.
초당 41MB/s가 나옴을 알 수 있습니다.(328Mbps)

11n/2.Ghz지원 무선랜카드에서보다 대략 3~4배정도의 속도가 나옴을 알 수 있습니다.
그리고,5Ghz 특성상 콘크리트벽에 약하기때문에 WF2190무선랜카드와 공유기가 같은 방에 있지않고,다른방으로 이동할 경우에는 신호감도가 약해지면서
전송속도는 초당 5~20MB/s(40~160Mbps)로 하향하는 결과를 보여주었습니다.

따라서 5Ghz는 근거리에서만 사용하고, 거리가 멀어질 경우에는 공유기의 2.4GhzSSID에 접속하여 사용하면 원할한 사용이 가능했습니다.
WF2190무선랜카드는안테나가 5dbi로 감도가높아 2.4Ghz에서는음영지역에서조차도 높은 수신률을 보여주었습니다.

WF2190무선랜카드는11ac지원랜카드이지만,동시에 구버젼의 11n/g/a를 지원하므로 WF2780과같은 2.4Ghz +5Ghz 동시지원의 듀얼밴드 공유기와 사용시에는 WF2190랜카드를 연결한 PC나 노트북이 공유기와 같은 방에 있는 경우에는 5Ghz로 접속하고, 같은 방에 있지않은 경우에는 2.4Ghz로 접속할 경우 효과적으로 사용할 수 있었습니다.

18. 스마트폰과 연결시 벤치비속도

벤치비속도 보시기 전에 참고하셔야할점:

802.11ac 공유기에 스마트폰을 연결하여 벤치비속도를 테스트할시에 최고의 성능을 테스트하려면 사실 인터넷환경이 100Mbps의 광랜이 아닌 기가비트(1000Mbps)환경이어야합니다.
시중에 출시된 802.11ac공유기중 리얼텍 8197D가 탑재된 공유기들은 현재 867Mbps의 속도까지 지원하고, Broadcom이 탑재된 버팔로 공유기는 1.3Gbps까지 속도를 냅니다.
다만,스마트폰은 1Tx1Rx만 지원하므로 스마트폰에서 최대로 낼 수 있는 433Mbps의 속도를 낼 수 있습니다.

433Mbps 속도라고하더라도현재 100Mbps 광랜환경에서는433Mbps속도를낼 수 없기때문에 기가비트환경에서 테스트해야만 최고속도를 낼 수 있습니다.

테스트한 환경은 100Mbps광랜환경이라 802.11ac를 지원하는 갤럭시S4 등의 최신스마트폰에서도 433Mbps의 최고속도를 테스트 할 수 없음을 양해바랍니다.

테스트는 구형스마트폰인 갤럭시탭과 베가NO6, 갤럭시S4LTE 폰에서 테스트하였습니다.

1.갤럭시탭(SHW-M180S)과의 벤치비테스트: (802.11ac 미지원 구형스마트폰)

2.4Ghz/11N으로 접속

갤럽시탭(7인치) 초창기모델이라 5Ghz를 지원하지않아, 2.4Ghz/11N으로 접속하여 테스트했습니다.
위와같이 22Mbps의 속도가 나옵니다.
사실 22Mbps도 느린속도는 아니지만, 최신스마트폰들이모두 5Ghz를 지원하고 폰 자체 스펙도 빨라져서 최신스마트폰에 비해서는 상대적으로 느린 다운속도를내줍니다.

2. 베가NO6와의 벤치비테스트: (802.11ac미지원 스마트폰이지만 5Ghz를 지원하는 스마트폰)

2.4Ghz/11N으로 접속:

비록 2.4Ghz로접속하였지만, 위와같이 48.9~50Mbps의 빠른 속도를내줍니다.
2.4Ghz에서는 스마트폰스펙상 채널본딩이 지원되지않기떄문에 72Mbps 링크속도가 최고이며, 실제 다운로드속도는 2.4Ghz에서는 대략 50Mbps가 최고속도로 보입니다. 즉, 사진과같이 2.4Ghz에서 낼 수 있는 최고속도가 측정되었습니다.

5Ghz/11N으로 접속:

80Mbps가 넘는 속도로 2.4Ghz로연결했을때보다 훨씬 더 빠른속도를 내줍니다.
이유는 5Ghz에서는 스마트폰이 채널본딩을 지원하여11n에서도 최고 150Mbps로 접속할 수 있습니다.
위와같이 802.11ac미지원 스마트폰이지만, 5Ghz를 지원하는 스마트폰이라면 최대 150Mbps를 지원하기때문에 100Mbps 광랜환경이라면 공유기와의 근거리에서 70~90Mbps의 속도를 내줍니다.
예를들어 5Ghz를 지원하는 스마트폰은 스냅드래곤S4부터 대부분 지원이 되었고,베가S5,베가레이서2,베가R3,베가NO6,갤럭시노트2,갤럭시S3LTE, 옵티머스LTE2,옵티머스G, 옵티머스뷰2, 테이크LTE 등이 있습니다.)

802.11ac를지원하는 최신 스마트폰은 갤럭시S4 LTE, 갤럭시S4 LTE-A, 갤럭시노트3, 갤럭시라운드, 옵티머스G2, 베가아이언, 베가LTE-A, 베가시크릿노트 등이 있습니다.
이 최신스마트폰에서는 기가비트 인터넷환경에서는433Mbps 속도까지지원합니다.

3. 갤럭시S4 LTE와의 벤치비테스트:(802.11ac지원 스마트폰)

5Ghz/11ac로 접속

위와같이 433Mbps로 연결되었음을 알 수 있습니다.아쉽지만 테스트환경이 100Mbps광랜인터넷으로 기가비트 인터넷을 지원하지않는관계로 최대속도는 100Mbps이하로 측정되었고, 100Mbps에 가까운 90Mbps 이상의 속도로 측정되었습니다.
기가비트 인터넷 환경이라면 스마트폰으로 벤치비테스트시에는실제 다운로드속도는 300~400Mbps속도가 나오지않을까 예상해봅니다.
테스트환경이 기가비트 인터넷 환경이 아니라서최대 다운로드속도 테스트를 테스트해보지못하는점 너무 아쉽습니다.

꼭 802.11ac를 지원하는 최신스마트폰이 아니더라도 5Ghz를 지원하는 기존스마트폰에서도 100Mbps광랜에서 90Mbps전후의 빠른속도를 보이기때문에 실상 PC에서 유선랜 속도와 차이가 없어졌습니다.
그렇기때문에 스마트폰에서 토렌트를 돌려도 1.5G짜리 HD영화한편을 다운받는데, 대략 2~3분이면 다운을 받을 수 있어 이제 유선인터넷과 와이파이 무선인터넷의장벽이 사라졌습니다.

다만, 5Ghz 특성상 회절성이 약한 특성이 있는데, 특히콘크리트벽이 있을경우에는 콘크리트벽에 막혀 무선신호강도세기가 많이 약해지는 단점이 있습니다.
공유기가 스마트폰을 사용할 방에 있을 경우에는 5Ghz로 접속해도 되지만, 다른방으로 이동할 경우에는 콘크리트벽에의해 신호강도세기가 약해지기때문에 평소에 공유기와 같은 방에 있지않은경우에는 2.4Ghz로 접속하는게 좋습니다.
토렌트로 영화파일 다운받거나 백메가급의 파일을 다운받는 그런 경우에도 802.11N/2.4Ghz 환경에서다운받았다면 너무 오래걸려서 감당이 안되었는데,
스마트폰에서 토렌트로 고용량 영화파일을 다운받는다거나 1G이상 파일을 받아야하는 맵업데이트를해야한다거나 할 때도 단 2~3분만에 빠른속도로 다운이 되어서 확실히802.11ac/5Ghz의 장점을 느낄 수 있었습니다.

19. IPTV와의 호환성은?

대부분의 IPTV는 공유기환경에서 실시간TV와 VOD 다시보기가 가능하지만, SK브로드밴드와 LG U+와 다르게 KT 올레 IPTV에서는유일하게 실시간TV와 VOD 다시 보기가 동시에 가능하지않습니다.올레 IPTV의 경우 셋탑박스가 오로지 공인IP에서만 작동되도록 만들어져있는 특수한 환경이고, 사설IP를 사용하는 공유기환경에서는 정상적으로 작동되지않습니다.따라서 별도로 KT전용 AP/공유기를 신청해서 사용해야만 실시간TV와VOD 다시보기를 동시에 사용작동합니다.

예를들어 KT 올레IPTV의 경우 이제까지 시중에출시된 타사 공유기들에서는 멀티캐스프 포워드(IGMP설정) 등 IPTV관련 세팅을 하면 실시간TV는 되어도 VOD 다시보기가 안된다거나 또는 이 옵션을 끄면 VOD 다시보기는되고 실시간TV는 안된다거나 하는 문제가 있었습니다.
그래서 KT올레IPTV셋탑박스 ->공유기 ->PC 와같이 공유기를 셋탑박스 하위로 두어 불편하게사용하는 방법뿐이 없었습니다.

공유기 -> KT 올레IPTV 셋탑박스와 같이 공유기밑에 셋탑박스를 연결하는 일반적인 구성으로는 정상적인 사용이 불가능했었습니다.

실제로 여러 공유기를 써본결과 국내굴지의 공유기회사인IPTIME 공유기도IGMP세팅을해도 KT IPTV에서는 VOD 다시보기가 되지않았지만, 이 모델의 경우 실시간TV와 VOD 다시보기 서비스가 동시에 가능합니다. IPTV 가입자수가 800만시대를 넘어서고, 그중 KT가 IPTV에서 가입자수가 국내 최대라는점을 가만하면 그동안 공유기가 IPTV를 지원하지못하여 KT전용 AP를 매달 유료로 사용하고있었던 KTIPTV유저들에게는 메리트가 있을 것 같습니다.
제가 테스트한 올레 IPTV셋탑박스는 가장 많이 보급된 가온미디어 제품입니다.이 셋탑박스를 테스트한 결과 실시간TV와 VOD 다시보기 모두 잘 되었습니다.
다른회사 공유기들은 KTIPTV에서 실시간 TV와 VOD 다시보기 둘다 지원하는 공유기를 보지못했는데 혹시 있다면 알려주시면 고맙겠습니다.

제가 테스트한 모델은 집에서 사용하고있는가온미디어 NA1100입니다.
올레 IPTV라면 대부분 이 모델을 사용하고있는것으로 알고있습니다.

(셋탑박스상태가좀 더러워도 양해를... ^^;)

위 사진은 밑면 사진입니다.모델명은 NA1100,제조사는 가온미디어로 나와있습니다.

아래는 올레IPTV 화면입니다. 실시간TV와 VOD 모두정상적으로 잘 작동됩니다.

20. 070 인터넷전화기와의 호환성은?

---- 리뷰미완성----

21. 총평가

802.11ac 프로토콜을 지원하는 공유기들이 출시됨으로인해 이제는 유선보다 무선이 더 빠른 시대가 왔습니다.
이미 무선속도는 유선을 앞서고있고, 장비도 출시되었지만,정작 국내인터넷인프라는 아직까지 100Mbps 광랜에 머무르고있습니다.
유선인터넷 인프라가 무선인터넷 트랜드를 한참이나 뒤따라가지못하고 있는 형국입니다.
그래서 기가비트 공유기로 불리는 802.11ac 공유기의 성능을 제대로 테스트해보지못한점이너무 아쉬었습니다.
비록 (유선)기가비트 인터넷이 아직은 상용화되지않고, 일부지역에서만 시범운영을 하고있지만, 정부정책이 기가비트인터넷을 전국망으로 확대하는것이기 때문에 곧 기가비트 인터넷도 내년을 기점으로 점차 확대될것이라생각됩니다.
참고로, 다나와에서 공유기 가격을 확인해보면 현재 시중에서 802.11ac를 미지원하는 구형공유기중 유선으로 기가비트를 지원하면서5Ghz/11N을 지원하는 공유기가격도 최저 6만원이 넘었습니다.
그런데 802.11ac를 지원하는 최신사양의 공유기가 5만원대라면11ac를 미지원하는 구형 5Ghz 공유기보다 가격이 더저렴하여 가격면에서도 상당히 메리트있는 가격임에는 틀림없습니다.
이제는 2.4Ghz 주파수는 포화상태로 사무실뿐만 아니라 가정에서도 무선간섭으로인해 속도저하와무선접속지연 등의 장애가 발생하고있어 이제는 5Ghz가 그 대안이 되고 있습니다.
또한 스마트폰과 탭, 노트북으로 이제는 PC보다무선기기를 더 많이 사용하는 환경으로 바뀌어 여러 개의 무선기기들이 공유기 한대에 접속하여도 속도저하현상이 없어야하고, 램용량이 64MB이상 탑재되어 토렌트를 돌려도 수용할 수 있는 커넥션이충분한 공유기가 필요합니다.
더 이상 주변사무실과 집인근에 설치된 수많은 2.4Ghz 공유기와 집안에서도 2.4Ghz를 사용하는 무선전화기, 무선키보드, 무선마우스, 전자레인지 등과의 주파수충돌을 걱정하지않고, PC에서 토렌트를 돌리면서도 동시에 스마트폰에서 인터넷을 하여도 느려지지않은 공유기가 필요하다면 Netis WF2780이 괜찮은 선택이 될 수도 있을 것 같습니다.
아직 기가비트 인터넷 인프라가 구축되지않은 환경에서 802.11ac 공유기가 좀 이른감이있지만, 적어도 현재 2.4Ghz가 포화상태에 이르렀고, 2.4Ghz와 5Ghz를 독립적으로 동시에 사용할 수 있어 무선간섭과느린 속도에서 벗어나고싶다면 802.11ac 공유기 선택이 나쁘지않을거라 생각합니다.
더 많은 이야기를 하고싶지만 리뷰는 여기까지 마치겠습니다 ^^;

=========================================================================================

제가 10월달부터 시간나는대로 틈틈히 이글을 쓴지 시작하여 이번달 초에 글을마무리하는 과정이었는데, 이번달초에낙상으로인해 한쪽팔이 골절되어 20번은작성하지못했습니다.
수술은 마쳤는데, 팔이 나으려면 몇개월의 시간이 필요할것 같은데요. 기브스에 팔걸이를 하고있어 한쪽팔로 당장 글을 쓰기엔 너무 힘이 드네요 ㅠ.ㅠ
070 인터넷전화기 호환성 테스트를 제외하고 리뷰에서 중요한 내용들은 대부분 적어서 다행이지만,더 하고싶고 쓰고싶은 얘기가 많은데,여기까지밖에 작성하지못한점 저 역시 조금 아쉽습니다.
비록 처음 계획했던 테스트들을 모두 하지못해100% 모두완성되지못한 리뷰이지만, 최근에802.11ac 공유기들이 많이 출시되고있어 기가비트 와이파이를 지원하는 802.11ac프로토콜이 무엇인지 그리고,공유기선택에 조금이나마 도움이 되었으면 하는마음으로 올립니다.
긴 글이지만,읽어주신분들 감사합니다.
이번에 사고나면서 느끼는것이지만,몸은 건강할때 소중한걸 모르지만,아프니깐 몸이 건강한게 얼마나 행복한지 알 것같습니다.
두 팔을 쓰면서 생활하는게 얼마나 행복한 것인지 사고가 나서야 알게되었네요.
몸은 건강할 때 챙기세요.
날씨가 많이 추워졌는데,감기조심하시고 건강하세요!

출처 : http://s.ppomppu.co.kr/?idno=review_30479&target=http://www.ppomppu.co.kr/zboard/view.php?id=review&page=1&divpage=6&no=30477

AdminID.kr (어드민아이디) - 시스템, 네트워크, 보안 관리자, System Engineer, Unix, Linux, Windows, Oracle, MSSQL, MySQL, Windows, HardWare, Security, Router, Switch, Firewall

MySQL Dump / Import (덤프 / 임포트)

Reverse DNS - 등록및 확인

# RDNS(Reverse DNS)

엑셀 시트보호 해제 프로그램 없이 하기

파일 준비

엑셀 시트보호 해제

패스워드 초기화

윈도우 컴퓨터 유지보수에 유용한 무료 프로그램들

NAS용 저전력 PC 제작

mysql이 cpu를 많이 점유하고, DB와의 연결상태가 좋지 않을때

파일질라(filezilla) 디렉터리 목록 조회 실패

마이크로소프트 오피스 제품군 완전 삭제 방법

프로세스 BRR, PI, BPM, PS 등 개념부터 명확히

용량 산정 (동시 접속자 계산)

SVN의 cleanup 에러시 해결방법

[오류해결] svn cleanup failed-previous operation has not finished; run cleanup if it was interrupted

TortoiseSVN 계정변경

SVN passwd 설정 : 계정 (users/passwd)

VMware Workstation 8 의 소개와 가상 머신의 특성

Tomcat JVM heap memory set 및 size

Java 실행 옵션 정리

메모리 영역 (code, data, stack, heap)

vCenter 없이 vSphere 로 ESXi 에 연결해서 가상머신 복사하기

VSphere 에서 수행

Console 에서 수행

Inventory에 추가

Ref

Workstation용 .vmdk를 esxi 전용으로 변환하기

J1900 vs 1037u vs D2700 vs D525 vs D2550 vs D2500

CPU 온도에 관한 진실

[SVN] Subversion 명령들

[JAVA] 개발환경설정 - 표준프레임워크

Tomcat 7.x 와 8.x 간의 default configuration 차이

[전자정부 표준프레임워크] 톰캣(Tomcat) 설치하기

잡설로 써보는 키보드 선택하는 방법

Configuring Virtual Machine Processor Settings

Intel Virtualization Technology for Directed I/O (VT-d)

인텔의 vPro, 5년 노력에도 안팔리는 이유?

가상화 - 윈디하나의 솔라나라

목차

가상화(Virtualization)란?

가상화 분류

구현에 의한 분류

전가상화, 반가상화

전가상화

반가상화

하이퍼바이저

가상화 지원을 위한 하드웨어 기술

AMD-V, VT-x

Nested Page

IOMMU

VT-c

계통도

Solaris Containers (Zones)

Zones

Branded Zones

Oracle VM VirtualBox

Oracle VM Server for SPARC

인텔® 가상화 기술 정보

인텔® 가상화 기술 정보

[가상화] VT-D의 호환성 Motherboards

인텔의 AES-NI, TXT, VT-D (AES 명령어 세트, 신뢰 실행 기술, 가상화기술)

가상화 지원 CPU 확인 프로그램 : SecurAble

Desktop Boards - Compatibility with Intel® Virtualization Technology (Intel® VT) (가상화 지원 칩셋)

Vmware Converter 포트 확인 (Required VMware vCenter Converter ports)

Required VMware vCenter Converter ports (1010056)

Symptoms

Purpose

Resolution

Additional Information

See Also

This Article Replaces

Update History

Request a Product Feature

형상관리에 들어 보셨나요?

1. 형상관리에 대해

2. 왜 버전 관리 시스템이 필요한가?

3. 버전 관리 시스템의 기본 개념

4. 버전 관리 시스템의 종류