'IT이야기/기타'에 해당되는 글 7건

RAID란? 

1987년 캘리포니아 대학 버클리 분교의 패터슨, 깁슨, 카츠에 의해 발표되어 논문 ‘A Case for Redundant Arrays of Inexpensive Disks’에서 등장한 기술입니다. 1~5단계로 제안된 자 기기억장치의 새로운 기술과 SLED(single large expensive disk)를 비교하여 설명하였습니다. 그 후로 여러 업체에서 제안한 0, 6, 10수준 등이 있습니다. 여러 디스크를 병렬로 연결하 여 사용하는 기법으로서 접근(access) 속도와 데이터 보존 신뢰가 우수할수록 높은 등급을 받는 5단계로 구분됩니다. 간단하게 말해서, 하드디스크 여러 개를 가지고 하나처럼 사용하는 모드, 데이터 보관의 안 전성을 위해서 미러링을 하는 모드, 위의 두 가지를 합한 모드, 속도를 빠르게 하기 위해서 병렬적으로 데이터를 저장하는 모드 등 다양하게 있습니다. 

보통 RAID는 여러 개의 하드디 스크에 동시에 데이터를 분할해서 저장하기 때문에 빠른 속도로 읽기/쓰기가 가능합니다.

⊙ RAID 0 (Striped Disk Array without Fault Tolerance)

최소 드라이브 개수 : 2

최대 용량 : 디스크의 수 x 디스크의 용량

빠른 데이텅 입출력을 위해 데이터 스트립(데이타를 여러 디스크 드라이브에 분산 저장)을

제공하긴 하지만, 데이터를 중복해서 기록하지는 않습니다. RAID 0는 수행의 향상을 가져오

긴 하지만, 잘못된 수행을 막지는 못합니다. 그래서 만약 하나의 드라이브가 잘못된다면 모

든 데이터들을 잃어버릴 수도 있습니다. 1+1=2

간단하게 말해서 위에 숫자처럼 1과 1이 더하면 2가 되는 형식입니다.

두 개 이상의 디스크가 필요하고 준비된 디스크의 모든 용량을 사용하는 방식 입니다. 퍼포먼스는 높으나 안정성은 심하게 불안정한 편입니다. 불안정한 것은 백업되는 디스크가 없기 때문입니다. 그렇기 때문에 실제로는 잘 쓰지 않습

니다. 

⊙ RAID 1 (Mirroring and Duplexing)

최소 드라이브 개수 : 2

최대 용량 : (디스크의 수/2) x 디스크의 용량

두 개 이상의 디스크를 붙여서 하나의 디스크처럼 사용하는 건 위의 RAID 0과 같지만

RAID 0과는 다르게 두 개의 디스크 중에 절반의 용량을 실제 가용용량으로 정하고 나머지

절반의 용량은 백업에 쓰인다는 점이 틀립니다. 1+1=1

쉽게 설명하면, 두 개의 디스크 중 하나는 실제 사용하는 디스크이고 다른 하나는 백업용

디스크라고 생각하면 됩니다. 동일 파일이 2개가 존재합니다. 입/출력 퍼포먼스는 RAID 0 보다 상당히 떨어지고 안정성은 높습니다. 하나의 디스크에서 에러가 발생할 경우 복사된 데이터 파일을 이용해서 복구가 가능합니다. 따라서, 빠른 기록 속도와 함께 장애 복구 능력이 요구되는 경우 사용됩니다. 

⊙ RAID 2

ECC 기능이 없는 드라이브를 위해 해밍(hamming) 오류 정정 코드를 사용합니다. SCSI 디스크 드라이브는 기복적으로 에러검출 능력을 갖고 있기 때문에 RAID2는 사용하지

않습니다. RAID 3에 비해 장점이 없어 거의 사용하지 않습니다. 

⊙ RAID 3

최소 드라이브 개수 : 3

최대 용량 : (디스크의 수 - 1) x 각 디스크의 용량

Parity정보를 위한 전용 디스크를 사용하고, 나머지 디스크 드라이브에 Byte 단위로 데이터

를 균등하게 분산 저장합니다. Read의 성능은 RAID 0과 동일하나 Write 성능은 Parity 계산

으로 인해 성능 저하가 있습니다. 1개의 디스크 드라이브가 오류가 나는 것을 허용합니다. 장애 발생시 컨트롤러가 전용 패리티 드라이브로부터 장애가 생긴 드라이브의 손실된 데이

터를 가져와 복구/재생 합니다. RAID 4와 유사하나 분산 저장을 경제적으로 수행하기 위해 하드웨어적인 지원이 요구되며

효율적인 동작을 위해 동기 가능한(synchronized-spindle)드라이브 사용합니다.

⊙ RAID 4

최소 드라이브 개수 : 3

최소 드라이브 개수 : 3

모든 데이터를 Block 단위로 분산 처리합니다. 이때 모든 Block들은 각 디스크에 균등하게

저장되진 않습니다. 또한, RAID 3처럼 Parity 정보를 독립된 디스크에 저장합니다.. 데이터를 읽을때는 RAID 0에 필적하는 우수한 성능을 보이나, 저장할 때는 매번 Parity 정

보를 갱신하기 때문에 속도가 떨어집니다. RAID 3처럼 1개의 디스크 드라이브가 오류가 나는 것을 허용하며, 하나의 디스크 장애에

대해서는 완벽하게 대처하고, 두 개 이상 장애 발생에는 데이타 손실이 발생합니다. 병목 현상이 발생하면 전체 스토리지의 성능 저하가 발생합니다. 

⊙ RAID 5

최소 드라이브 개수 : 3

최대 용량 : (디스크의 수 - 1) x 디스크의 용량

1+1+1=2

세 개 이상의 디스크를 붙여서 하나의 디스크처럼 사용하고 각각의 디스크는 패리티 정보를

가지고 있어 하나의 디스크가 깨져도 다른 두 개의 디스크를 이용해서 깨진 디스크를 복구

시킬 수 있습니다. 패리티를 담당하는 디스크가 병목 현상을 발생시키지 않아서, 멀티프로세스 시스템과 같이

작은 데이터가 기록이 수시로 발생할 경우 더 빠른 속도를 냅니다. 읽기 작업일 경우 각 드라이브에서 패리티 정보를 건너뛰어야 하기 때문에 RAID 4보다 속

도가 느립니다. 장애 발생시 데이터 복구에 대하여는 아래 그림을 참고하여 설명 드리겠습니다.

일단 disk 1 의 Data가 깨져서 Disk1을 사용하지 못하게 된다고 가정하겠습니다. 그럼 가용 Data중의 A, D 부분을 못쓰게 됩니다. 소실된 내용은 Disk2 와 Disk3 의 Parity에서 가지고 옵니다. 그럼 이제 Disk1을 복구시키거나 대체하여 새로운 Disk1을 생성하고 나머지 Disk2와 Disk3

의 Parity 부분의 A와 D를 복사하면 문제가 해결됩니다. 이 방법은 우리나라에서 가장 많이 사용하는 것이기도 하고 입/출력 퍼포먼스나 안정성면에

서 적당한 수준에 있어 많이 사용합니다. 단점은 세 개의 디스크로 RAID 5를 구성 시에 두 개 이상의 디스크가 깨지면 복구할 수 없

다는 것입니다. 

⊙ RAID (6 Stripe set with dual distributed parity)

최소 드라이브 개수 : 3

최대 용량 : (디스크의 수 - 2) x 디스크의 용량

하나의 Parity를 두 개의 Disk에 dual로 분산 저장하는 방법으로 두 개의 drive에 오류가 발

생하여도 정상적으로 동작합니다. Storage가 많은 큰 시스템에서는 rebuild time이 증가하게 되는데 이 시간이 증가할수록

rebuild 중간에 다른 dirve에 오류가 발생하여 시스템 전체에 오류가 생길 수 있습니다. 따

라서 큰 시스템에서 Raid 6를 사용하면 Disk 두 개에 오류가 생겨도 정상 동작을 하기 때문

에 rebuild time에 여유가 있어 risk가 줄어듭니다. 단, 쓰기속도는 Parity를 여러 번 갱신해야 하기 때문에 RAID 5보다 떨어집니다. 디스크를

재구성하는 동안 성능이 나빠질 수 있습니다. 

⊙ RAID 1+0 (Striping & Mirroring)

최소 드라이브 개수 : 4

1+1+1+1=2

말 그대로 RAID 0 기술과 RAID 1기술의 복합체입니다. 네 개 이상의 디스크를 2개씩 RAID 1 로 묶고, 묶은 것을 다시 RAID 0 으로 묶습니다. 

내용은 위에 언급했던 RAID 기술과 다를게 없습니다. 하지만 mirroring 에서 끝나는게 아니라 mirroring 된 두 개의 디스크를 다시 striping 시켜

서 퍼포먼스를 향상 시킨다는 점이 다릅니다. 이 방법으로 RAID 0 (stripe)의 중요한 단점인 안정성의 불안을 없앨 수 있고, RAID 1(mirror)의 최대 단점인 퍼포먼스를 대폭 향상 시킬 수 있습니다. 최고의 안정성과 높은 퍼포먼스를 보장하지만 RAID를 이용하는데 많은 비용이 소모된다는

단점이 있습니다.

⊙ RAID 0+1

최소 드라이브 개수 : 4

1+1+1+1=2

말 그대로 RAID 0 기술과 RAID 1기술의 복합체입니다. 네 개 이상의 디스크를 2개씩 RAID 1로 묶고, 묶은 것을 다시 RAID 0로 묶습니다. 내용은 위에 설명했던 RAID 1+0과 동일합니다. 역시 동일하게 RAID 0 (stripe)의 중요한 단점인 안정성의 불안을 없앨 수 있고, RAID 1(mirror)의 최대 단점인 퍼포먼스를 대폭 향상 시킬 수 있습니다. 여기서 중요한건 0+1 이라고 해서 stripe 된 다음 mirroring 되는게 아니라

mirroring 된 다음 stripe 된다는 것이 중요합니다. 최고의 안정성과 높은 퍼포먼스를 보장하지만 RAID를 이용하는데 많은 비용이 소모된다는

단점이 있습니다. RAID 1+0 과 RAID 0+1 은 비슷해 보이나 RAID 1+0을 선호하는 편입니다.

Linux 나 Unix 환경설정에서는 Config 파일을 문서 편집기(Editor)를 이용하여 수정 편집 하곤 합니다.

개발자에게는 필수인 이 Editor 중에서 예전부터 리눅스나 Unix에서 기본 사용되어진 편집기가 있습니다. 바로 Vi편집기 인데 

요즈음은 Vim 편집기도 기본 탑재 입니다.

Vi 편집기에 비해 Vim 편집기는 색상으로 비쥬얼과 빠른 시인성을 높였으며 기타 몇몇 기능이 상향되어진 편집기입니다.

vi 편집기에서 파일을 열때는 

vi file1 명령을 실행하면 열리게됩니다.

vi file1 file2  ==> file1 file2 를 차례대로 열게 됩니다.

vi 명령어 (명령모드)

vi 명령어 (종료 모드)

1. cron

   - 일정시간 마다 시스템에서 자동으로 실행 시키는 데몬(Windows의 작업스케줄러와 비슷한 기능)

2. cron 데몬의 실행과 종료

   실행 : /etc/rc.d/init.d/crond [start/restart/stop]

3. crontab 옵션 

  #crontab [파일][-u사용자]     crontab을 사용자파일로 대체

  #crontab  -[-u사용자]            crontab을 표준입력으로 대채

  #crontab -l[사용자]               사용자를 위한 리스트를 보여줌

  #crontab -e[사용자]              사용자를 위한 crontab을 에디트 함 

  #crontab -d[사용자]              사용자를 위한 crontab을 제거

4. 주기 결정

*　　　　　　*　　　　　　*　　　　　　*　　　　　　*

분(0-59)　　시간(0-23)　　일(1-31)　　월(1-12)　　　요일(0-7)

각 별 위치에 따라 주기를 다르게 설정 할 수 있습니다. 순서대로 분-시간-일-월-요일 순입니다.

괄호 안의 숫자 범위 내로 별 대신 입력 할 수 있습니다.

요일에서 0과 7은 일요일입니다. 1부터 월요일이고 6이 토요일

ex)

# crontab -l       현재사용하고 있는 crontab 파일 출력

# crontab -e       crontab 파일의 수정(edit)

# crontab */2 * * * * /test.sh     -> 매 2분마다 test.sh 스크립트를 실행

# crontab 5,10 10-15 1-6 * *     -> 1일에서 6일까지 10시부터 15시 사이에 매5,10분마다 실행

사이트를 만들거나 PPT를 만들때 아이콘 및 이미지가 필요한 경우가 많다.

직접 포토샵으로 제작하면 좋지만 시간이 없거나 포토샵과 거리가 멀경우 유용한 무료 아이콘 사이트를

이용하는것이 좋다.

무료 아이콘 사이트라 할지라도 상업적 용도로 사용시는 라이센스를 꼭!! 확인해야한다.

※ 라이센스는 꼭 확인하고 사용하시기 바랍니다.

VCS(CSV, SVN, GIT) 버전관리

버전 관리란?

버전 관리란 무엇이며, 왜 이것을 알아야 할까? 버전 관리 시스템은 파일의 변화를 시간에 따라 기록하여 과거 특정 시점의 버전을 다시 불러올 수 있는 시스템이다. 

이 책에는 소프트웨어의 소스 코드를 버전 관리하는 예만 나오지만 실제로는 모든 컴퓨터 파일이 버전 관리의 대상이 될 수 있다.

이미지나 레이아웃을 수정할 때마다 각각의 형태를 모두 보존하고 싶은 그래픽 디자이너나 웹 디자이너라면 버전 관리 시스템(Version Control System; VCS)을 사용하는 것이 현명할 수 있다. 

VCS를 사용하면 개별 파일 혹은 프로젝트 전체를 이전 상태로 되돌리거나 시간에 따른 변경 사항을 검토할 수 있으며, 문제가 되는 부분을 누가 마지막으로 수정했는지, 누가 언제 이슈를 만들어냈는지 등을 알 수 있다. 

또한 파일을 잃어버리거나 무언가 잘못되어도 대개 쉽게 복구할 수 있다. 

그리고 이 모든 장점을 누리는 데는 큰 노력이 들지 않는다.

CVS(Concurrent Version System)는 1986년 Dick Grune에 의해서 개발된 가장 대중적인 버전관리 시스템이다. 오랜 시간 개발자들에게 버전관리 시스템의 대명사로 불리다 보니, 버전관리를 위한 다양한 기법들이 연구되었다. 

그 결과로 윈도우 버전과 웹 버전, 편리한 GUI 클라이언트 등도 개발되었다. 현재까지도 많은 프로젝트나 기업에서 CVS를 버전관리 시스템으로 사용하고 있다.

그러나 CVS 프로토콜은 한 번 등록된 디렉토리나 파일의 이동이나 이름 변경을 허용하지 않았으며, 역사적으로 RCS를 따라 나왔기 때문에 개별 파일 단위로만 버전관리가 되었다.

그 뿐 아니라 아스키코드로 된 파일명만 지원할 뿐 유니코드에 대한 지원이 제한적이어서 우리나라처럼 유니코드로 지원되는 언어를 쓰는 국가에서는 파일 이름을 모두 영어로 변경해야 했다.

리눅스 서버를 원할하게 다루기 위해서는 기본명령어는 반드시 외우는게 좋습니다.

테스트로 서버를 하나만들어서 외우기보단 손에 익을때까지 연습을 많이 하시면 좋습니다.

모든 명령어의 옵셥을 볼때는 뒤에 -h 라는 옵션을 넣게되면 해당 명령어의 옵션리스트를 확인할 수 있습니다.

또한 grep 옵션 명령어를 사용하여 리스트에서 특정 데이터만 확인 할 수도 있습니다.

[ 리눅스 기본 명령어 ] 

바로 네트워크 장비를 관리하고 또 감시하기 위해서 TCP/IP 계층 중 응용 계층에서 이용되는 프로토콜입니다. 다른 것들보다 좀 더 단순한 형태의 네트워크 관리 프로토콜이라고 생각하면 될듯합니다.

그럼 먼저 SNMP가 나타난 배경에 대해서 알아보도록 합시다. 

SNMP가 쓰이기 전에 일반적으로 사용되는 네트워크 관리는 ICMP에 의존했었다. ICMP는 Network계층의 프로토콜로써, 운영체제에 관계없이 사용할수 있는 간단한 프로토콜이였습니다.. 이 프로토콜을 이용해서 우리는 네트워크로 연결된 각각의 호스트가 작동하고 있는지, 작동한다면 어느정도의 응답시간을 가지고 작동하는지 등의 간단한 정보를 얻을수 있었으며, 초기에는 이정도로도 필요한 네트워크 관리가 가능했었습니다..

 ICMP를 이용한 가장 유용한 도구는 아마도 ping 프로그램일 것입니다.

그러나 인터넷의 사용이 보편화되고 네트워크에 연결된 호스트의 수가 증가하자 거기에 따라서 네트워크 구성역시 복잡해지고, ICMP만을 가지고는 이러한 네트워크의 관리를 효율적으로 할수 없게 되었습니다.

그래서 몇가지 프로토콜에 대한 연구가 진행되었고, SGMP, HIMS, CMIP/CMIS등이 제안되게 되었습니다.. 이중에서 SGMP를 발전시킨 SNMP가 사실상 네트워크 관리를 위한 표준적인 프로토콜로 자리잡게 되었습니다. 다른 프로토콜들이 사용되지 않은데에는 몇가지 이유가 있었습니다. CMIP/CMIS는 너무 방대하고 너무 복잡했으며, HEMS의 경우에는 실제 적용사례가 적었기 때문입니다.

어쨋든 SNMP는 거의 대부분의 운영체제에서 사용되어 지고 있습니다. 여러분이 사용하는 Linux, 그밖의 대부분의 유닉스와, 윈도우계열 운영체제는 기본적으로 SNMP프로토콜을 사용하는 도구들을 제공하고 있고, 그외에도 router등 TCP/IP를 네트워크 프로토콜로 사용되는 운영체제들 역시 SNMP는 필수적으로 제공하고 있습니다.

SNMP로 할수 있는것을 설명해 보겠습니다.

SNMP 기본 명령어

GET: 관리자가 에이전트로 원하는 특정 정보 요청

GET NEXT: GET과 동일하며 MIB의 다음 정보 요청시 사용
GET BULK: MIB 테이블 복구시 사용
SET: 관리장치 데이터의 수정이나 할당을 위한 명령어
TRAPS: 에이전트가 관리자에게 특정 정보를 알리기 위해 사용
INFORM: TRAPS 명령어와 비슷하지만 관리자의 확인 과정이 추가
RESPONSE: 응답 전송

MBI 란?

SNMP는 네트워크를 관리하기 위한 프로토콜이다. 그렇다면 무엇을 관리할 것인가(관리객체)를 결정해야 할것이다. 관리객체를 결정했다면, 이러한 관리객체를 효과적으로 관리하기 위해서 이를 분류해야 할것이다. 이게 바로 MIB이다.

MIB는 Man In Black의 줄임말이 아니다. Management Information Base의 줄임말인데, 관리되어야할 자원 객체의 분류된 정보를 말한다. 관리되어야할 객체는 시스템정보, 네트워크사용량, 네트워크 인터페이스정보 등이 된다.

이 MIB객체들은 관리하기 편하도록 Tree구조를 가지게 된다

SNMP 값을 가져오려면 일단 명령을 실행하는 서버와 값을 가져오려고 하는 서버에 모두 SNMP가 설치되어 있어야 합니다. 두 서버에 모두 설치가 되어 있으면 원하는 값을 가져올 수 있게 됩니다. 그렇다면 SNMP 값을 가져오는데 어느 정도의 시스템 리소스를 사용하게 될까요? 그것은 어떤 SNMP 값을 가져오는가에 따라서 다르게 됩니다. 그리고 시스템의 사양에 따라서도 조금씩 차이가 있습니다. 

SNMP 값을 가져오는 데 해당 시스템의 리소스를 너무 많이 차지하게 된다면 서버에 영향을 미칠 수 있으므로 먼저 테스트해 보는 것이 좋습니다. SNMP 값을 가져오는 데는 주로 cpu system 리소스가 사용됩니다. 앞에서 테스트했던 cpu, Load Averages 값을 가져오는 것은 1% 미만의 cpu system을 사용하게 됩니다. 그러나 메모리의 값을 가져오는 것은 10% 정도까지 cpu system 리소스를 사용할 수도 있습니다. 물론 서버마다 차이가 있으니 테스트해 보면 됩니다. 

그렇다면 1초에 한번씩 cpu 값을 가져오는 것은 큰 문제가 없어 보입니다. 해당 시스템을 모니터링하려면 1초에 한 번씩 값을 가져와서 출력해 주기 위해서입니다. 그러나 메모리의 값을 1초에 한 번씩 가져오는 것은 뭔가 문제가 있어 보입니다. 왜일까요? 1초에 한 번씩 해당 서버의 cpu system 리소스를 사용하게 되면 10% 정도의 cpu system 리소스를 사용하게 되기 때문에 뭔가 문제가 있어 보입니다. 

그리고 프로그램을 하나만 실행시키는 것이 아니라 여러 사람이 모니터링 프로그램을 실행시켜서 사용하고 있다면 1초에 한 번씩 메모리 값을 가져오는 것은 문제가 있습니다. 그럴 경우에는 적당히 간격을 조정하면 됩니다. 한 5초 정도의 주기로 값을 가져오면 될 것입니다. 1초, 5초에 한 번씩 값을 가져오는 이유는 실시간 모니터링을 위해서입니다. 

마지막으로 SNMP 메세지를 보겠습니다.

Version : SNMP 프로토콜의 버전번호.

Community name

- 매니저와 에이전트간의 관계를 나타냄.

- 인증, 접근통제 등의 목적으로 사용됨.

- 보통은 간단하게 public을 사용한다.

PDU(Physical Data Unit)

- Physical Data Unit의 줄임말.

- 실제 전송되는 필요한 정보들을 담고있는 Unit.

- Unit이라 하는 이유는 실제 전송되는 정보들의 부가 속성을 나타내기 위한 몇가지 값들을 포함하고 있기 때문.

- PDU는 PDU타입(Get인지 Set인지 Get Next인지 등등)과 Request-id, 실제보내고자 하는 데이터(OID와 OID에 대한 값들)로 구성.

SNMP 메시지는 UDP포트를 이용하여 전송된다.

- agent는 162 udp포트

- manager는 161 udp포트