용어 정리 : service level agreement (서비스 수준 협약서)

Service level agreement는 서비스를 제공함에 있어 공급자와 사용자간에 서비스에 대한 측정지표와 목표등에 대한 협약서를 말한다. 일반적인 서비스 측정치들은 가용시간이나 응답시간, 헬프데스크 서비스 시간 or 응답시간, 서비스 처리에 대한 완료 or 최초 응답 시간 등이 해당한다. 대표적으로 HP CarePack에서 장애 발생 시 "최초 응답 2시간이내" 등을 규정하는 것이 대표적인 예이다. 대부분 아웃소싱으로 서비스를 제공받는 경우 작성하며, IT의 운영이나 유지보수 업무 등에 많이 적용되고 있다. 일반 계약서와의 차이는 사용자와 공급자간의 협의와 상호 협조로 수행해야 한다는 점이 다른점이다.

RHEL 5, 6 Storage volume 연결 시 sda 변경되는 이슈

< 현상 > Local volume 의 / 가 처음엔 sda 였으나 , storage volume 을 연결하면 storage volume 이 sda 가 되고 / 가 다른 device name 으로 변경되는 이슈 참고 > 다들 아시겠지만 RHEL 6 부터는 Filesystem 의 block id(blkid) 사용을 권장합니다 . 이유는 커널에서 모듈을 읽어올 때 local disk 의 모듈부터 읽는 것이 아니라 먼저 인식된 볼륨부터 인식하기 때문입니다 . < 해결방법 > RHEL 5  : /etc/modprobe.conf 에서 모듈 로딩의 순서를 지정 # vi /etc/modprobe.conf    alias scsi_hostadapter hpsa    alias scsi_hostadapter qla2xxx RHEL6 : rdloaddriver 를 통한 설정 지정  #vi /etc/grub.conf    rdloaddriver=hpsa rdloaddriver=qla2xxx ( 마지막 줄에 추가 )

Raid Cache Memory BBWC와 FBWC의 차이점

< 사전 지식 > Raid Controller에서 Data Read / Write의 요청을 처리할 때 서버의 메모리로 전송간 성능의 차이가 발생된다.  이는 구성 물질과 구조의 차이점으로 일반적인 정보와 같이 CPU -> memory -> Disk 순으로 전송속도의 차이가 발생되며  각 구간별로 전송 속도의 차이가 심하여 이를 보완하기 위해서 구간별 cache라는 장치 혹은 논리적 메모리 영역을 만든다.  Raid Controller도 Disk와 DRAM간의 데이터 전송속도를 보완하기 위해서 Raid Cache Memory를 장착하며, 이 공간은 데이터가   전송되거나 받을 때 가장 우선적으로 받게 되는 구간이다.  Raid Cache Memory와 함께 사용되는 것이 배터리인데 존재의 이유는 메모리의 휘발성 문제 때문이다. Raid cache와 disk간 데이터를 적재하는 도중  전원이 차단되면 기본적으론 raid cache 영역 데이터를 분실하게 되며 추후 전원이 공급되어 시스템을 가동 시 데이터의 정합성이 맞지 않아서 데이터가  깨지는 현상이 발생될 수 있기 때문이다.  즉, 서버나 OS입장에서 볼 때 CPU는 데이터 전송 완료를 대기하는 시간은 메모리 -> Raid cache 구간까지로 인식하며 실질적인 데이터의 저장은 Raid cache에서 Controller를 지나서 Disk로 Raid 방식에 맞추어 저장되는 방식이다.  < Type > BBWC - Battery Backed Write Cache는 Backup Battery Unit(BBU)로 전원이 공급되며, BBU는 일반적인 배터리 구조를 사용한다.  BBWC의 구동 방식은 정전 시 raid cache에 BBU를 통하여 전원을 공급, 데이터를 유지시켜주는 방식이다.  단점으론 장시간 정전 또는 배터리의 수명이다. ...

EPEL Repository 추가

CentOS등 Free Linux를 사용하고 있으면 효율적인게 오픈소스를 편하게 다운로드 받는것이 좋다~! 이는 Repository를 이용하는 Yum을 통하여 사용하게 되는데, OS를 설치하게 되면 사용할 수 있는 Repository외에도 오픈된 Repository를 다양하게 사용할 수 있다.  관심 또는 테스트하려는 프로젝트 사이트에 들어가면 대부분 제공되지만 fedora project는 EPEL이 대표적이다.  자세한 설명은 검색 고고싱! EPEL Repository 설치는 다음과 같다.  다음 사이트로 이동 http://www.rackspace.com/knowledge_center/article/install-epel-and-additional-repositories-on-centos-and-red-hat CentOS and Red Hat Enterprise Linux 5.x wget http://dl.fedoraproject.org/pub/epel/5/x86_64/epel-release-5-4.noarch.rpm sudo rpm -Uvh epel-release-5*.rpm CentOS and Red Hat Enterprise Linux 6.x wget http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm sudo rpm -Uvh epel-release-6*.rpm CentOS and Red Hat Enterprise Linux 7.x wget http://dl.fedoraproject.org/pub/epel/7/x86_64/e/epel-release-7-1.noarch.rpm sudo rpm -Uvh epel-release-7*.rpm wget이 설치되어 있어야 하며, 자동으로 repository 등록을 시켜준다.  이제 yum repolist를 통해서 확인...

CentOS Minimal 설치 후 GUI (runlevel 5) 설치하기

CentOS를 대량으로 설치하게될때 설치되는 이미지의 패키지가 적은 것이 좋다. 그리고 서비스 또는 테스트 용으로 사용하게 될때도 불필요한 패키지가 설치되지 않은 상태에서 필요한 것은 Yum을 통하여 Repository에서 받아 오면 그만!  그래서 나같은 경우는 CentOS를 설치할 때 minimal로 설치하고 GUI가 필요할 때 추가로 설치해 준다.  minimal 설치 후 추가 설치   1. 마우스 우클릭 Terminal      # yum install nautilus-open-terminal  2. GUI 화면으로 부팅하기 (runlevel 5)     # yum groupinstall "Desktop" "Gnome X Window System" 위 작업들은 설치 완료 후 적용을 위하여 logout 후 재 로그인이 필요하다.