참 오랫만에 IBM DeveloperWorks의 글을 소개하려한다. "Linux로 상용 하드웨어를 재활용하기 위한 세 가지 방법"이라는 글인데, 읽어보면 한번쯤은 생각해봤던 내용이라는 생각이 들것이다. 가벼운 마음으로 한번 읽어보자.

아래는 글의 서문을 발췌한 것이다. 자세한 내용은 원문을 보자. 원문 보기(클릭)

Linux 세계의 연금술

Linux 권위자인 H. Peter Anvin은 최근에 오래된 시스템의 용도를 파일 서버로 변경했다. 그는 잦은 보안 업데이트, RPM 기반 패키지 관리 시스템 및 서버에 적절하게 패키지로 제공되는 소프트웨어의 수를 근거로 하여 Fedora를 운영 체제로 선택했다. Anvin의 시스템은 RAID(Redundant Array of Independent Disks) 6 구성에서 9TB의 새 하드 디스크를 호스트한다. 책상 아래에 사용하지 않은 채 방치하고 있었던 이전의 개발 시스템이 지금은 매우 중요한 작업을 수행하고 있다.

이 시스템이 아주 오래된 것은 아니지만, 컴퓨터 하드웨어를 사용하지 않고 있었다는 것은 대체로 뭔가 문제가 있음을 나타낸다. 이런 시스템은 오늘날과 같은 빠른 발전과 변화의 추세를 따라잡기에는 대체로 너무 느리고 이를 지원하기에 너무 오래된 것은 물론이고, 특히 보증 기간이 지난 경우 기술적으로 안정적이지 않다. 하지만, 시스템이 오래되었다고 그냥 버리기에는 너무 아깝다. 많은 회사와 가정에서는 이렇게 오래된 시스템을 학교나 도서관에 기증하여 더 오래 사용할 수 있도록 하고 있지만, 이런 시스템을 기증받아 사용하는 사람들 역시 그런 구형 시스템으로 뭘 할 수 있을지 몰라서 결국 하드웨어가 재활용 센터로 넘어가는 운명에 처하는 경우가 많다. 이는 자원 낭비일 뿐 아니라, 때로는 재활용 컴퓨터가 소위 제3세계 국가의 쓰레기 매립장이나 소각로로 보내지는 바람에, 전자 폐기물이라는 새로운 문제를 만들어낸다(자세한 내용은 참고자료 참조).

본 기사에서는 Linux 운영 체제를 사용하여 오래되긴 했지만 작동하는 컴퓨터 시스템의 용도를 변경함으로써, 구식 시스템에 서버, 미디어 플레이어 또는 씬 클라이언트로서의 새로운 생명을 불어넣는 방법을 설명한다.


 UNIX 혹은 Linux 서버를 운영하는 관리자라면 객관적인, 혹은 보고서 작성을 위한 성능 분석 결과가 필요하게 된다. 현재 운영체제 성능 분석 및 모니터링을 위한 도구들이 꽤 많이 나와있다. 하지만 그 중에서도 공짜로 사용할 수 있는 툴들에 대해서 얘기해보고자 한다. kSar와 nmon analyser라는 툴을 들어보셨을거다. 각각 sar와 nmon으로 만들어진 log 파일을 분석하는 툴이다. 자세히 얘기해보자.

1. kSar
 지인의 소개로 알게된 kSar는 sar라는 툴로 저장한 서버의 성능 관련 data를 분석하기 위한 GUI 툴이다. 소스포지에서 다운로드 받을 수 있으며, 링크는 http://sourceforge.net/projects/ksar이다. BSD 라이선스 정책을 따르며, 현재 최신 버전은 5.0.6이다.
 실행시키면 아래와 같은 화면이 뜬다.



2. nmon analyser
 nmon analyser는 nmon으로 저장한 서버 성능 데이타를 분석하기 위한 툴이다. 마이크로소프트 엑셀에서 해당 엑셀 파일을 열어서 nmon log file을 분석하는 방식으로 되어있다. 그래프로 보기 좋게 분석되어 나와서 나는 주로 nmon과 nmon analyser를 사용한다. nmon과 nmon analyser는 무료로 사용할 수 있기는 하지만 엑셀이라는 유료 소프트웨어를 이용해야만 결과를 알수 있다는 단점이 있다. 아마... 어딘가에 엑셀외의 다른 도구를 사용하는 방법이 있을지도 모르지만... 아직 찾지 못 했다.

 nmon analyser는 이전에도 소개한 적이 있다. 아래의 글들을 보면 nmon analyser가 어떤 프로그램인지 알 수 있을것이다.
2009/04/10 - [Operating System] - NMON, NMON Analyser를 이용한 시스템 성능 리포트 만들기
2011/04/07 - [Operating System] - nmon analyser 3.3.f가 나왔네요.




 현재 사용중인 Linux server가 어떤 시스템인지 정보를 확인하는 방법은 많다.
RedHat 계열이면 /etc/redhat-release 파일을 열면 배포판 정보가 보이고,
uname 명령을 사용하면 또 일부 정보를 확인할 수 있다.

nmon을 설치했다면 nmon 실행 후 r을 입력하면 시스템 정보를 볼 수 있지만, 32비트인지 64비트인지 확인하는데는 좀 번거롭기도 하고... 그래서 찾아보았더니 명령어 한줄로 확인하는 법이 있었다!!

# getconf LONG_BIT
64


자 이렇게 하면 32 혹은 64로 화면에 뿌려준다.
쉽구나... 근데, 이거 정확한거겠지... ^^;
  이번에 백업용 DB 서버에서 개발사에서 제공한 이기종간 Database link를 사용할 수 있게 해주는 Gateway 프로그램을 실행하는데 오류가 발생하더군요. 그래서 검색을 해봤더니 ldd라는 명령어를 이용하여 해당 실행 파일이 필요로하는 라이브러리를 확인할 수 있더군요.

DB1> ldd 파일이름


이렇게 해주면 라이브러리 이름과 버전 정보를 알려줍니다. 아래는 ls를 ldd 명령으로 라이브러리 정보를 확인해본 결과입니다.

db@DB1:/bin>ldd ls
    librt.so.1 => /lib64/tls/librt.so.1 (0x00000034e0600000)
    libacl.so.1 => /lib64/libacl.so.1 (0x0000002a9557f000)
    libselinux.so.1 => /lib64/libselinux.so.1 (0x00000034de900000)
    libc.so.6 => /lib64/tls/libc.so.6 (0x00000034dc000000)
    libpthread.so.0 => /lib64/tls/libpthread.so.0 (0x00000034dcb00000)
    /lib64/ld-linux-x86-64.so.2 (0x00000034dbc00000)
    libattr.so.1 => /lib64/libattr.so.1 (0x0000002a95686000)

 점점 대용량 시스템 구축이 일상화되어가는 시기라 분산 파일 시스템에 대한 관심이 많아졌습니다. 다양한 파일 시스템이 존재하는데, IBM DeveloperWorks에서 특이한 이름의 Linux 분산 파일 시스템에 관한 문서를 보게 되었습니다. Ceph라는 분산 파일 시스템은 "페타바이트 규모의..."라는 큼지막한 규모감으로 다가옵니다.
 구현해보지는 않아서 실제로 어떨지는 모르지만, 이런 녀석들이 일년 뒤에는 하둡처럼 시장을 이글지도 모르죠. 미리 읽어두어서 나쁠건 없을것 같아서 링크를 겁니다. ^^ 평온한 오후시간 보내시길...


원문링크 : Ceph: 페타바이트 규모의 Linux 분산 파일 시스템

요약: Linux®는 확장 가능한 컴퓨팅 공간과 특히, 확장 가능한 스토리지 공간을 지속적으로 넓혀가고 있습니다. 최근에 Linux에는 POSIX 호환성을 유지하면서 복제 및 내결함성을 통합한 분산 파일 시스템인 Ceph라는 파일 시스템이 추가되었습니다. 이 기사에서는 Ceph의 아키텍처를 살펴본 후 Ceph가 내결함성을 제공하고 대량 데이터의 관리를 단순화하는 방법에 대해 설명합니다.




 가장 유명한 리눅스 배포판 중에 하나인 SLES(Suse Linux Enterprise Server)와 RHEL(Red Hat Enterprise Linux)를 비교한 글입니다. 특이한 점이라고 한다면 IBM의 System p에서의 SLES, RHEL에 대한 글이라는 겁니다. x86 이외의 CPU에서의 Linux에 대한 글이 흔하지 않아서 소개하게 되었습니다.
 System p는 보통 AIX 운영체제하에서 사용해본 분들이 많이 있을거라 생각합니다. 저도 예전에 근무했던 직장에서는 강력한 성능과 가상화 기능 등을 이용하여 DBMS, WAS 등을 운영했었습니다. 그 중에 한 서버에는 도입시에 SLES 9 설치 CD가 끼어 있더군요. 한번 설치해보는건데... 아쉽네요. 결국 저도 System p에서는 AIX 이외의 운영체제를 설치 및 운영해본 경험은 없습니다. 그래서 더 흥미가 생겼구요. 한번쯤 읽어보시면 좋을것 같습니다.

원저자 : Ken Milberg, 대표와 컨설턴트, 기술 편집자, 지역 전문가, techtarget.com

원문 : IBM System p에서 SLES(SUSE)와 RHEL(Red Hat) 비교

소개

LoP(Linux on POWER)는 APV(Advanced Power Virtualization) 및 IBM System p5®와 함께 2005년에 출시되었다. 이 제품의 출시로 인해 IBM System p® 아키텍처 사용자는 Linux를 변경 작업 없이 IBM의 LPAR(logical partitioning) 기술 위에 설치할 수 있었다. 따라서 IBM의 UNIX® 브랜드인 AIX®처럼 IBM의 Linux 브랜드인 System p에서도 가상화 기능을 사용할 수 있게 되었다. 이러한 기능에는 마이크로파티셔닝, VIOS((Virtual IO Server) 및 지원되는 고급 레벨 기능(예: CoD(Capacity on Demand))이 포함된다. Live Partition Mobility와 같은 Power6의 혁신적인 최신 기능에 의해 지원되기는 하지만 이러한 기능을 사용하면 System p 서버 간에 중단 시간 없이 워크로드를 동적으로 이동할 수 있으며 전용 용량을 공유하여 예비 프로세서 주기의 사용을 최적화할 수 있다.

LoP 사용자는 PowerVM™의 혁신 기능을 알아야 한다. 과거에 System p AVE라고 불렸던 이 기능의 현재 이름은 PowerVM Lx86이다. PowerVM Lx86은 애플리케이션의 네이티브 설치 없이 POWER6™, POWER5+™ 또는 POWER5™ 프로세서가 탑재된 System p 또는 BladeCenter® 모델에 대부분의 32비트 x86 Linux 애플리케이션을 설치 및 실행할 수 있도록 지원한다. 이 기능은 POWER™ 프로세서 기반 시스템에서 실행되는 x86 Linux 애플리케이션 환경을 구축한 후 동적으로 x86 명령어를 Power Architecture® 명령어로 변환하고 캐싱하여 성능을 향상시킨다. 또한 x86 Linux 시스템 호출을 LoP 시스템 호출에 맵핑한다. 이 솔루션의 고유한 특징은 네이티브 포팅 또는 애플리케이션 업그레이드 없이도 대부분의 x86 Linux 애플리케이션을 실행할 수 있다는 것이다. 이 기능은 SLES와 RHEL에서 모두 지원된다.

하지만 Red Hat 및 Novell 배포판이 둘 다 IBM System p에서 지원되는가? 물론 두 배포판 모두 지원된다. 하지만 주의해야 할 몇 가지 기본적인 차이점이 있다. Linux 배포판을 다른 Linux 배포판으로 이동하는 대규모 프로젝트에 참여한 프로젝트 관리자로서 필자는 이 의사 결정을 위해 고려해야 할 중요한 요소를 제시할 수 있다. 이러한 요소에는 사용자에게 GUI가 얼마나 중요한지, 배포판 벤더에게서 받고자 하는 지원의 종류 및 각 배포판의 시장 점유율 등이 있다. 의사 결정을 돕기 위해 볼륨 그룹 관리 및 물리적 볼륨을 논리적 환경에 할당하는 작업과 관련된 내용을 살펴보자.


OTN(한국 Oracle Technology Network)에 올라온 문서인데, Oracle 9i RAC을 Linux, FireWire 환경에 설치하는 방법을 설명하는 문서입니다. 기본적으로 개발 및 테스트 용도의 시스템으로 사용하는데 무리가 없다고 합니다. 저는... 아직 구축해보지 못 했구요. ㅡ.ㅡ (이놈의 게으름은...)
 OTN의 화면상에서는 이미 링크가 없어진 상태입니다. 속 내용을 전부 넣으려다 저작권 문제가 생길것 같아서 링크를 걸고, 서문에 해당하는 내용만 가져왔습니다. 개요와 구축에 사용사는 기술 소개 정도는 복사해와도 되겠죠?? 출처도 명확히 표시했으니...
 물론 해당 사이트에서 관련 링크가 삭제된 문서라 내용은 상당히 오래전에 작성된 글임을 짐작하실 수 있을겁니다. 하지만 아직가지 Oracle 9i를 사용하는 업체가 제법있구요. 개인적으로 구성한다면 이런것도 가능하다는걸 습득하는걸로도 도움이 될거 같습니다.
음... 이 문서의 최근 버전에서는 OacleVM을 이용하더군요. 아무래도 이 문서는 실제로 적용해보지는 않고 최근 버전의 문서를 이용해서 RAC 구축을 연습해볼것 같습니다. 그게 좀더 편할거 같아요. ^^; 암튼... RAC 구축에 성공하는 날 다시 글을 올리겠습니다.

원문 보기(링크)


목차

개 요
Oracle9i Real Application Cluster(RAC) 소개
RAC에 필요한 소프트웨어
공유 스토리지 개요
FireWire 기술
하드웨어 및 비용
간단한 프로세스 설명
Red Hat Linux(Fedora Core 1) 설치
네트워크 구성
적합한 Linux 커널 얻기 및 설치
"oracle" 사용자 및 디렉토리 생성
공유 FireWire 스토리지 장치에 분할 영역 생성
RAW 바인딩 생성
RAW 볼륨에서 심볼 링크 생성
Linux 서버 구성
hangcheck-timer 커널 모듈 구성
원격 액세스를 위한 RAC 노드 구성
각 RAC 노드에 대한 모든 시작 명령
Red Hat Linux 시스템(Oracle Metalink Note 252217.1) 갱신
Oracle9i 설치 파일 다운로드/압축 풀기
Oracle9i Cluster Manager 설치
Oracle9i RAC 설치
Oracle Database 생성
TNS 네트워킹 파일 생성
RAC 클러스터/데이타베이스 구성 확인
클러스터 시작 및 중지
TAF(Transparent Application Failover) 


개요

Oracle Real Application Clusters(RAC) 기술에 익숙해질 수 있는 가장 효율적인 방법은 실제 Oracle RAC 클러스터를 사용해보는 것입니다. 이 새로운 기술을 학습해보면 결함 허용, 새로운 보안 수준, 로드 밸런싱 및 쉬운 업그레이드 성능 등과 같은 Oracle RAC의 장점을 빨리 파악하게 될 것입니다. 하지만 이렇게 하는 데에는 전형적인 프로덕션 RAC 구성을 갖추기 위해 필요한 하드웨어 구입 비용이 문제입니다. 예를 들어 노드 두 개의 소규모 클러스터를 구축하는 데에도 10,000달러에서 20,000달러의 비용이 듭니다. 하지만 이 비용에는 프로덕션 RAC 환경의 핵심인 공유 스토리지 비용은 포함되지도 않았습니다.

단순히 Oracle RAC 기능을 배우려는 독자를 대상으로 하여 본 문서에서는 저렴한 비용으로 일반 판매 제품과 다운로드 가능한 소프트웨어를 사용하여 Oracle9i RAC 시스템을 구성하는 방법을 설명합니다. 이 구성을 위해서는 대략 1,000달러에서 1,500달러 정도의 비용이 듭니다. 이 시스템은 Linux를 사용하는 이중 노드 클러스터로 구성되며 IEEE1394 (FireWire) 드라이브 기술 기반의 공유 디스크 어레이가 포함됩니다.

본문의 내용 외에도 다양한 방식으로 저비용의 Oracle9i RAC 시스템을 구축할 수 있습니다. 예를 들어, 공유 스토리지를 FireWire 대신 SCSI를 사용하여 구현할 수도 있습니다. 일반적으로 SCSI 카드는 대략 70달러 정도이고 80GB 외장형 SCSI 드라이브가 700달러에서 1,000달러 정도라는 점을 감안하면 Firewire보다 SCSI에 더 많은 비용이 필요할 것입니다. 일부 메인보드에는 SCSI 컨트롤러가 내장되어 있을 수도 있습니다.

이러한 구성은 절대로 프로덕션 환경에서 실행될 수 없으며, 오라클 또는 기타 어떤 업체에서도 지원되지 않습니다. 광 채널은 포인트 투 포인트 또는 스위치 토폴로지 중 어떤 구성에서도 시스템과 스토리지 장치를 연결할 수 있는 고속 직렬 전송 인터페이스이기 때문에, 프로덕션 환경에서는 이러한 광 채널도 선택 대상으로 고려할 수 있습니다. FireWire는 테스트 및 개발 목적으로 광 채널에 대한 저비용의 대안이 될 수 있지만, 아직 프로덕션 환경에 사용할 수 있는 수준은 아닙니다.

참고: 본 문서를 작성한 시기에는 이러한 설명이 Oracle Database 10g에서 작동하는지 확인하지 않았습니다. 이에 대해서는 몇 개월이 지난 후에 개별 문서에서 10g를 사용한 유사 설치 방법을 설명할 예정입니다.


Oracle9i Real Application Clusters(RAC) 소개

Oracle Real Application Clusters(RAC)는 Oracle Parallel Server(OPS)의 후속 제품으로 개발되었습니다. RAC를 사용하면 동일 데이타베이스(스토리지)를 여러 인스턴스에서 동시에 액세스할 수 있습니다. RAC는 시스템 확장이 가능하기 때문에 결함 허용, 로드 밸런싱 및 향상된 성능을 제공합니다. 또한 모든 노드가 동일한 데이타베이스를 액세스하기 때문에 한 인스턴스에서 장애가 발생해도 데이타베이스에 대한 액세스가 손실되지 않습니다.

Oracle RAC의 핵심은 공유 디스크 하위 시스템입니다. 클러스터의 모든 노드는 클러스터 내의 모든 노드에 대한 데이타, 리두 로그 파일, 제어 파일 및 매개변수 파일을 액세스할 수 있어야 합니다. 데이타 디스크는 모든 노드가 데이타베이스를 액세스할 수 있도록 허용하기 위해 전역으로 사용할 수 있어야 합니다. 각 노드는 자신의 리두 로그 및 제어 파일이 있지만, 시스템 장애의 경우 특정 노드를 복구하기 위해 다른 노드에서도 이러한 파일을 액세스할 수 있어야 합니다.

일부 클러스터링 솔루션의 경우에는 공유 스토리지가 사용되지 않습니다. 일부 업체들은 데이타를 전체적으로 공유하는 대신 여러 시스템에 분산시켜두는 연합 클러스터(federated cluster)라는 이름의 방식을 사용합니다. 하지만 Oracle RAC에서는 여러 노드가 동일 디스크 세트를 사용하여 데이타를 저장합니다. Oracle RAC에서 데이타, 리두 로그, 제어 및 아카이브 로그 파일은 원시 디스크 장치의 공유 스토리지 또는 클러스터화된 파일 시스템에 보관됩니다. 오라클의 이러한 클러스터 방식은 클러스터의 모든 노드를 총체적으로 처리하는 능력을 활용하며 동시에 복구 보안 기능을 제공합니다.

절대적인 필수 사항은 아니지만 오라클은 Oracle Cluster File System(OCFS)을 설치할 것을 권장합니다. OCFS는 모든 노드에 동일한 파일 시스템을 작성함으로써 사용자의 디스크 관리 편의를 향상시켜줍니다. OCFS는 필수 요소가 아니지만 OCFS를 사용하지 않을 경우 모든 분할 영역을 수동으로 만들어야 합니다. (참고: 본 문서에서는 OCFS 설치 및 활용에 대해 자세히 다루지 않으며, 분할 영역을 작성하고 원시 장치를 이러한 분할 영역에 수동으로 바인드하는 작업을 설명합니다.)

Oracle RAC와 OPS의 가장 큰 차이는 새로 추가된 캐시 결합 기능입니다. OPS에서는 한 노드에서 다른 노드로 데이타를 요청할 경우 해당 데이타를 먼저 디스크에 기록한 다음에야 요청 노드에서 데이타를 읽을 수 있습니다. 하지만 캐시 결합 기능을 사용할 경우 데이타는 잠금 상태를 거치지 않고 바로 전송됩니다.

Red Hat Linux에 OCFS를 사용하지 않기로 한 중요한 이유는 OCFS가 RPM 형식으로 제공되기 때문입니다. 모든 RPM 모듈과 선행 컴파일된 모듈은 Red Hat Enterprise Linux AS(1,200달러) 커널 이름 지정 표준과 연결되어 있으며 제공된 2.4.20 연결 커널에서 로드되지 않습니다.

미리 구성된 Oracle9i RAC 솔루션은 Dell, IBM 및 HP와 같은 업체에서 프로덕션 환경용으로 제공됩니다. 하지만 본 문서에서는 Linux 서버와 저렴한 공유 디스크 솔루션인 FireWire를 사용하여 개발 및 테스트 용도의 Oracle9i RAC 환경을 구성하는 방법을 중점적으로 설명할 것입니다.                    


RAC에 필요한 소프트웨어와 구입 정보

RAC는 Oracle9i Database Enterprise Edition 내에 포함되어 있습니다. (오라클은 최근 Oracle Database 10g Standard Edition에서도 RAC를 사용할 수 있다고 발표하였습니다.) 클러스터에 Oracle9i Enterprise Edition을 설치하면 Oracle Universal Installer(OUI)에서 클러스터가 인식되어 RAC 설치 옵션이 제공됩니다. 대부분의 UNIX 플랫폼에서는 필요한 클러스터웨어를 위한 OSD 설치가 필요합니다. Intel 플랫폼(Linux 및 Windows)을 위해, 오라클은 Oracle9i Enterprise Edition 릴리스에 OSD 소프트웨어를 함께 제공하고 있습니다.


공유 스토리지 개요

현재 광 채널은 가장 대중적인 공유 스토리지 솔루션 중 하나입니다. 앞서 언급한 바와 같이 광 채널은 포인트 투 포인트 또는 스위치 토폴로지 모두에서 시스템과 스토리지 장치를 연결하는 데 사용되는 고속 직렬 전송 인터페이스입니다. 광 채널에서 지원되는 프로토콜에는 SCSI와 IP가 포함됩니다. 광 채널 구성은 최대 127개의 노드를 지원할 수 있으며 초당 처리량은 최대 2.12GB입니다. 하지만 광 채널은 매우 비쌉니다. 광 채널 스위치 만으로도 1,000달러 정도의 비용이 소모될 수 있습니다. 이 외에도 광 채널 스토리지 어레이 및 고급 드라이브를 구입해야 하며, 드라이브는 36GB 용량의 경우 300달러의 비용이 필요합니다. 서버에 대한 광 채널 카드를 포함하는 전형적인 광 채널 설정의 기본 설정에는 대략 5,000달러의 비용이 들며 여기에 클러스터 구성 서버 비용은 포함되지 않습니다.

광 채널에 대해 비교적 저렴한 대안은 SCSI입니다. SCSI 기술은 공유 스토리지를 위한 적절한 성능을 제공합니다. 하지만 GPL 기반 Linux 가격에 익숙한 관리자 및 개발자에게는 SCSI도 비용 부담이 클 수 밖에 없습니다. SCSI 구성에서 이중 노드의 클러스터 비용은 1,000달러에서 2,000달러 정도입니다.

이 외에 자주 사용되는 솔루션은 Sun NFS(Network File System)입니다. Sun NFS는 공유 스토리지에 사용할 수 있지만 네트워크 기기나 기타 유사 장비를 사용할 경우에만 가능합니다. 특히 NFS 상의 직접 입출력이 보장되는 서버가 필요합니다.


FireWire 기술

Apple Computer 및 Texas Instruments에서 개발된 FireWire는 고속 직렬 데이타 버스에 대한 교차 플랫폼 구현 기술입니다. 고대역폭, 장거리(최대 100미터 길이) 및 고성능 버스 기능을 제공하는 FireWire는 디지털 비디오(DV), 전문 오디오, 하드 드라이브, 고급 디지털 스틸 카메라 및 홈 엔터테인먼트 장치와 같은 애플리케이션에 사용되고 있습니다. 현재 FireWire는 초당 800MB의 전송 속도로 운영되며, 차세대 FireWire의 경우에는 이론상 1,600Mbps의 비트 속도를 지원하고 그 이후에는 3,2000Mbps까지도 지원할 예정입니다. 즉, 초당 3.2기가비트의 성능을 제공할 수 있는 FireWire는 이러한 속도로 인해 대용량 데이타 파일을 전송 뿐만 아니라, 압축되지 않은 HD(high-definition) 비디오 또는 다양한 SD(standard-definition) 비디오 스트림 처리와 같은 가장 어려운 비디오 애플리케이션의 경우에도 꼭 필요한 기술입니다.

다음 표는 여러 디스크 인터페이스 간의 속도를 비교한 것입니다. 각 인터페이스에는 초당 최대 전송 속도가 kb(킬로비트), KB(킬로바이트), Mb(메가비트) 및 MB(메가바이트) 단위로 표시되어 있습니다. 표에서 알 수 있듯이 IEEE1394 기능은 다른 사용 가능한 디스크 인터페이스 기술과 비교할 때 적정 성능을 제공합니다.

디스크 인터페이스 속도
직렬 115 kb/s - (.115 Mb/s)
병렬(표준) 115 KB/s - (.115 MB/s)
USB 1.1 12 Mb/s - (1.5 MB/s)
병렬(ECP/EPP) 3.0 MB/s
IDE 3.3 - 16.7 MB/s
ATA 3.3 - 66.6 MB/sec
SCSI-1 5 MB/s
SCSI-2 (Fast SCSI / Fast Narrow SCSI) 10 MB/s
Fast Wide SCSI (Wide SCSI) 20 MB/s
Ultra SCSI (SCSI-3 / Fast-20 / Ultra Narrow) 20 MB/s
Ultra IDE 33 MB/s
Wide Ultra SCSI (Fast Wide 20) 40 MB/s
Ultra2 SCSI 40 MB/s
IEEE1394(b) 100 - 400Mb/s - (12.5 - 50 MB/s)
USB 2.x 480 Mb/s - (60 MB/s)
Wide Ultra2 SCSI 80 MB/s
Ultra3 SCSI 80 MB/s
Wide Ultra3 SCSI 160 MB/s
FC-AL Fiber Channel 100 - 400 MB/s

 지난번에 소개한 [Linux 전력 소비량 줄이기] 시리즈의 세번째 문서를 소개합니다.

원문 : Linux 전력 소비량 줄이기, Part 3: 조정 결과

세 편의 기사로 구성된 이 시리즈에서는 전력 효율 향상을 위해 시스템을 조정하는 방법에 대해 설명합니다. Part 3에서는 조정된 상태와 조정되지 않은 상태에서 다섯 가지 커널 내 거버너의 성능을 비교하여 Linux 기반 System x 서버를 최적화하는 방법에 대해 살펴봅니다.

 요즘 친환경 IDC관련 글이 꽤 많습니다. IBM으로부터 받은 메일 중에는 친환경 IDC 구축에 관한 글도 다수 있더군요. IDC에 설치하는 랙의 문짝에 냉각 기능을 넣는 것도 소개되어있었구요. 음... 그외에 기타등등...
그런데 여러가지 요소 중에서 실제로 전기를 많이 소비하는 서버 장비의 OS에서 전력 소모량을 줄일 수 있다면 참 좋을것 같죠. 여기에 관한 글을 소개합니다. 물론... 저도 OS쪽 전문가가 아니라서 이 글의 내용에 대해서 자신있게 말씀드릴 수는 없습니다. 앞으로 실 서버에 적용을 해보고 비교해볼만한 환경이 갖춰지면 꼭 한번 비교 분석해보고 싶긴합니다. 그날이 곧... 다가올까요? 로또라도 한번 해야겠네요.

  IBM DeveloperWorks 한국 사이트에서 Linux server에서의 전력 소비량 줄이기에 대한 글이 올라와있네요. 원래 시리즈로 세편의 글이 영문으로 올라와있는데, 한글로 번역된 문서는 2편까지 올라와있습니다.


글 보러가기
Linux 전력 소비량 줄이기 Part 1 : CPUfreq 서브시스템
Linux 전력 소비량 줄이기 Part 2 : 일반 및 거버너 관련 설정

세 편의 기사로 구성된 이 시리즈에서는 전력 효율 향상을 위해 시스템을 조정하는 방법에 대해 설명합니다. 먼저 Part 1에서는 전력 효율 향상을 위해 Linux 기반 System x 서버를 미세 조정하는 데 필요한 구성 요소와 개념을 간단히 살펴본 후 Linux CPUfreq 서브시스템을 활성화하는 방법, C 및 P 상태에 대한 지침을 가져오는 방법 및 다섯 가지 커널 내 거버너(governor) 중에서 시스템의 전력 효율 향상을 위해 필요한 거버너를 결정하는 방법에 대해 설명합니다.

의견 나누기:  회사에서 절전이 얼마나 중요한지에 대한 의견을 추가해주기 바랍니다.

이 시리즈의 정보

이 시리즈에서는 전력 효율을 높이기 위해 Linux 기반 IBM System x 서버를 조정하는 방법에 대해 살펴본다. 커널 내 거버너 및 관련 설정과 거버너의 사용 방법에 대해 알아본 후 조정된 거버너가 전력 성능 및 전자 상거래 워크로드에 미치는 효과를 살펴본다. 예제는 RHEL 5.2(Red Hat Enterprise Linux 버전 5.2)가 실행 중인 System x 서버를 기반으로 하지만 모든 2.6.x 커널과 주파수 배율 조정을 지원하는 모든 유형의 프로세서에도 동일한 지침이 적용된다.

Part 1에서는 전력 효율 향상을 위해 시스템을 조정하는 데 필요한 Linux CPUfreq 서브시스템, C 및 P 상태, 다섯 가지 커널 내 거버너 등을 포함한 구성 요소와 개념에 대해 설명한다.

Part 2에서는 Linux CPUfreq 서브시스템의 일반 설정과 다섯 가지 커널 내 거버너 즉, 성능, 절전, 사용자 공간, 온디맨드일반 거버너와 해당 설정에 대해 자세히 살펴본다.

Part 3에서는 조정된 상태와 조정되지 않은 상태에서 다섯 가지 커널 내 거버너의 성능을 비교하여 시스템에 대한 전력 조정을 통해 얻을 수 있는 결과를 확인한다.

전력 효율은 사업 비용이나 환경 문제와 관련된 모든 사람에게 중요한 고려 사항이다. 이 기사에서는 Linux CPUfreq 서브시스템과 커널 내 거버너를 사용하여 프로세서의 작동 주파수를 변경하여 성능에 큰 영향을 주지 않으면서 시스템의 전력 효율을 향상시키는 방법에 대해 설명한다. 하지만 전력 효율 조정은 실제 하드웨어에 의존하게 된다는 한계가 있다. (이 시리즈의 Part 2에서 이에 대해 자세히 설명한다.)

Linux CPUfreq 서브시스템

2.6.0 Linux 커널부터는 CPUfreq 서브시스템을 통해 프로세서 주파수 배율을 동적으로 제어할 수 있다. 낮은 클럭 속도로 작동하는 프로세서는 속도에 비례하여 전력 소비량과 발열량이 낮다. 이처럼 클럭 속도를 동적으로 제어하는 기능을 사용하면 시스템이 많이 사용되지 않을 때 전력을 적게 소비하도록 시스템을 조절할 수 있다.

CPUfreq 구조에서는 거버너와 데몬을 사용하여 시스템의 정적 또는 동적 전력 정책을 설정한다. 이 기사의 뒷부분에서 설명할 동적 거버너는 CPU 사용률에 따라 CPU 주파수를 전환하여 성능에 영향을 주지 않으면서 전력 소비를 줄일 수 있다. 이러한 거버너에서는 사용자 조정 기능도 제공되므로 주파수 배율을 쉽게 변경하고 사용자 정의할 수 있다. 또한 sched_mc_power_savingssched_smt_power_savings 설정은 스레드 통합을 통해 전력을 절약할 수 있다.


IBM DeveloperWorks 한글 사이트에 올라온 글 중에서 가상화 관련 문서 두개를 소개하려합니다.

원문 보러가기
1. VM 전개 자동화하기
2. Linux 하이퍼바이저 분석

 Linux에서의 가상화 솔루션과 VM 전개 자동화에 관한 글인데, 일단 DeveloperWorks 상의 분류는 Linux로 되어 있네요. [VM 전개 자동화하기]는 VMWare를 기준으로 설명을 하고 있고요. [Linux 하이퍼바이저 분석]은 오픈소스인 KVM(Kernel-based Virtual Machine)과 Lguest(이전에는 lhype)로 설명하고 있습니다.
 흠... 둘 다 써보진 않았지만 아주 흥미로운 내용이었습니다. 다만, 아직 Linux에서의 가상화 솔루션을 많이 경험해보지 않아서 인지 [VM 전개 자동화하기]문서 보다는 [Linux 하이퍼바이저 분석]가 좀더 재미있더군요. 소스 코드가 없어서 그런건지... ^^;

 Oracle RAC을 집에 있는 PC에 구현해보려하는데, OTN에서 찾은 문서에는 Oracle VM을 사용하더군요. Oracle VM이 Xen 기반인걸로 알고 있는데, Xen에 대한 설명은 없어서 좀 아쉽더군요. HDD랑, RAM이랑 증설한 뒤에 빨리 집에다가 구성해봐야 할텐데요...

아... 암튼... 이번에 소개하는 [VM 전개 자동화하기], [Linux 하이퍼바이저 분석] 모두 도움이 될 만한 내용이라고 생각합니다. 한번 보시길...

+ Recent posts