System Compleat.

'Techs'에 해당되는 글 113건

  1. Start Chef from opcode on Ubuntu
  2. Microsoft Web Farm Framework 2.0 Beta for IIS 7
  3. pNFS on Nexenta
  4. MONO Environment on Ubuntu
  5. NAPI on Linux 1

Start Chef from opcode on Ubuntu

Techs

( younjin.jeong@gmail.com , 정윤진 )


세월은 빠르게 흘러, 시스템 관리에도 고전적인 perl / python 과 같은 언어를 제치고 ruby 가 등장하게 되었다.
Chef 라고 하면 이미 나온지 그렇게 오래 된 툴은 아니지만, 그렇다고 얼마 되지 않은 것도 아니다.
이 글을 쓰게 되는 것도 번역이나 샘플 코드 조사를 통한 기본적인 동작의 이해를 위한 것임을 미리 밝히며, 시스템 자동화를 구현 할 수 있는 이런 툴을 개발하고 또 미리 알아내어 접하는 분들에게 새삼 놀랄 따름이다.

우분투에서의 ruby 인스톨은 아주 쉬운 과정으로 이루어 지며, 이거 왜 안되 할 만한 부분이 있어 별도로 소개한다.
( 우분투에서는 gem update --system 을 지원하지 않는다.  패키지 매니저로 처리 하라는 친절한 시스템사마의 설명 )

# sudo apt-get install ruby rubygem
# sudo gem install ohai chef       

하다 보면 여기서 에러를 줄줄이 뱉어 낼 것이다.  에러를 살펴보면, extconf.rb:1:in 'require': no such file to load - mkmf 라는 에러 메세지 인데, 결국 extconf.rb 는 ruby-dev 패키지를 참조하기 때문에 이 패키지를 설치 하지 않으면 정상적으로 동작하지 않는다.  따라서,  정상적으로 진행하기 위해서는

# sudo apt-get install ruby-dev

해 준다.  이후 다음의 링크에서 제공하는 Chef 를 시작하는데 안성맞춤인 내용을 따라하는데 우분투로 충분 할 것이다.

이제부터 설명할 내용은 다음의 링크에서 가져왔다.
http://brainspl.at/articles/2009/01/31/cooking-with-chef-101


Cooking with Chef 101

Chef 의 가장 매력적인 점은 확장 및 축소가 매우 쉽다는 점이다.  처음 시작할 때는 chef-solo 로 쉽게 시작하고, 이후 필요에 따라 chef-client 나 chef-server 를 통해 원하는 대로 구현이 가능해 진다. Chef 로 작성한 동일한 recipe 를 가지고  웹 서버, 데이터베이스, 어플리케이션 , couchdb 서버 및 기타 등등의 거의 모든 서버에 대한 수평적 확장이 가능하다.
구체적 설명은 됬고, 일단 간단한 recipe 를 통해 rubygem 의 일부 패키지를 설치 해 보기로 한다. 그리고, chef 가 베이스 시스템을 구성한 이후에 간단한 디렉토리 설정과 어플리케이션을 배포 해 보도록 하겠다 .

일단 chef-101 의 코드를 GitHub 로 부터 가져온다.

# git clone git://github.com/ezmobius/chef-101.git

Chef 를 설치한다. ( root 계정 또는 sudo )

# gem install chef ohai  --source http://gems.opcode.com  --source http://gems.rubyforge.org

( 일부 패키지 의존성 문제로 인해 rubygem 이 gems.opcode.com 에 의해 서비스 받고 있음에도 불구하고 rubyforge 를 소스로 추가해 주는 것이 좋다.  Rubygem 은 그런식으로 동작한단다. )
여기까지 준비 되었으면 이제 실행시켜 보면 된다.  ( 이 단계는 일부 디렉토리 생성 및 어플리케이션 들을 인스톨 하기 때문에 원치 않으면 넘어가도 관계 없다. )

실행하기전,  config/dna.json 의 user 설정을 변경 할 필요가 있다.  소스에는 'ez'로 되어있을 것이나, 시스템에 나와 같이 'ez' 계정이 없다면 변경 해 주는 것이 좋다.

# cd chef-101
# chef-solo -l debug -c config/solo.rb -j config/dna.json

엄청나게 많은 메세지들이 줄줄이 올라가는 것을 볼 수 있는데, 처음부터 대부분의 메세지는 시스템 output 컬렉터인 ohai 가 수집한 정보들이다.  이는 recipe 에서 수행하는 모든 내역을 알려주며, 정상적으로 종료 된 경우에는 다음과 같은 내용을 보여준다.

INFO: Chef Run complete in 1.09344323 seconds

여기까지 나왔다면 요리를 잘 했다고 볼 수 있다.   이제 이 Chef 가 어떤 식으로 동작하는지 알아 볼 필요가 있다.
먼저,  dns.json 을 보면,

{
  "apps": [
    "beast",
    "mephisto"
  ],
  "user": "ez",
  "gems": [
    {
      "name": "rake",
      "version": "0.8.3"
    },
    {
      "name": "tmm1-amqp",
      "source": "http://gems.github.com",
      "version": "0.6.0"
    }
  ],
  "recipes": ["main"]
}

이는, 내가 JSON DNA 라고 부르는 recipe 세트다.  이는 노드에 설치할 것들에 대한 레시피로, 코드 안에서 어플리케이션 이름, 사용자 명 등을 찾아 볼 수 있다.

시스템으로의 엔트리 포인트인 main 으로 지정된 recipe 를 보면,

include_recipe 'gems'
include_recipe 'applications'

template "/data/someservice.conf" do
  owner node[:user]
  mode 0644
  source "someservice.conf.erb"
  variables({
    :applications => node[:apps]
  })
end

include_recipe 로 필요한 recipe 를 순차적으로 호출하는 것을 볼 수 있는데, 이는  호출 순서에 따라 필요한 레시피가 동작하도록 설정 할 수 있게 하기 위함이다.  만약 다른 레시피를 먼저 구동하고 싶으면, 그 레시피를 다른 것보다 먼저 호출 하도록 한다.

자, 우리는 gem 레시피 이후 application 레시피를 호출하고, 이후 일부 디렉토리 작업을 수행 하는 것을 볼 수 있다. 이 이후작업에서 우리는 쉽게 템플릿을 정의하고, 네이밍 하여 해당 템플릿이 가져야 하는 속성의 정의를 구현하는 것을 볼 수 있다. 
이제, gem 레시피를 보자.

node[:gems].each do |gem|
  gem_package gem[:name] do
    if gem[:version] && !gem[:version].empty?
      version gem[:version]
    end
    if gem[:source]
      source gem[:source]
    end
    action :install
  end
end

여기서 우리는 loop 를 돌려가며 dna.json 에서 정의 되어 설치할 각 gem 의 버전을 가져오는 것을 볼 수 있다. Gem 은 버전과 소스를 가질 수 있으나, 주의할 점은 비어있으면 설정하지 않아야 한다. 버전을 정의하지 않으면 가장 최신의 버전을 가져오게 될 것이며, 소스를 지정하지 않으면 rubyforge.org 에서 가져오게 될 것이다. 
결국 마지막 줄에, 우리는 action :install 으로서 각 gem 에 대한 인스톨을 수행한다. 이는, 시스템에 이미 해당 gem 이 설치 되어 있으면 다시 설치하지 않는다.

자 이제 application recipe 를 보면,

directory "/data" do
  owner node[:user]
  mode 0755
end

node[:apps].each do |app|

  cap_directories = [
    "/data/#{app}/shared",
    "/data/#{app}/shared/config",
    "/data/#{app}/shared/system",
    "/data/#{app}/releases"
  ]

  cap_directories.each do |dir|
    directory dir do
      owner node[:user]
      mode 0755
      recursive true
    end
  end

end

먼저 우리는 /data 디렉토리를 생성하고 원하는 권한을 할당한 이후, json 에 명시한 owner 로 디렉토리를 설정하는것을 볼 수 있다. 이후 루프를 돌면서 필요한 디렉토리 생성 등 모든 액션을 취한다. 

보는 바와 같이 비교적 간단하게 chef-101 코드는 종료된다. 매우 간단하지만 보기 쉽게 로직을 설명하고 있어서, Chef 를 시작하는 엔트리 포인트로는 나쁘지 않을 것이다.


여기까지 날림 번역.


Chef 는, 상상할 수 있는 시스템 설정의 모든 부분에 관여 할 수있다.  각종 daemon 의 동작에 필요한 설정 파일 부터,
필요한 패키지의 설치 또는 웹 서버들의 컨텐츠 배포, Mysql 의 복제 구성까지도 모두 가능하다.

ruby 라는 언어를 먼저 습득할 필요는 있지만, perl 이나 python 중 둘중 하나에 엑스퍼트가 아니어서 하나를 배워야 한다면 루비를 적극 추천하며, 두가지 언어 모두를 알고 있는 사람에게도 Chef 는 좋은 툴이 될 수 있을 것이다.



( younjin.jeong@gmail.com , 정윤진 )


Microsoft Web Farm Framework 2.0 Beta for IIS 7

Techs
( younjin.jeong@gmail.com , 정윤진 )


최근의 클라우드와 같은 대규모 분산처리가 점점 더 이슈화 되고, 발전하고 있다.  이는 각종 SnS 서비스 및 모바일 통신 환경의 발달로 인한 더 많은 사용자 층의 서비스 유입으로 인하여 자연스럽게 나타나는 시대의 플랫폼에 대한 요구가 아닌가 하는 생각이 든다.

서비스는 보다 더 복잡해 지고, 각 진영의 개발은 그 어느때 보다 활발하며, 치열하다.  기업간 경쟁은 Apple 을 필두로 Adobe 와의 분쟁,  HTML5/CSS3 , 각종 확장된 Javascript 등은  플랫폼, 클라이언트 브라우저 등 모든 환경이 급변함으로 고인 물은 더욱 빨리 썩게 되고, 흐르는 빠른 물줄기를 쫒아 가자니 가랭이가 터질 지경이 아닌가.
더구나 그 물에 몸담그고 있다면, 또 그 물이 opensource 라면 각종 개발에 스크립트에 정신줄 놓는건 일도 아니다. ( 물론 학구열에 불타면 관계 없지만 매번 똑같은 일을 하지 않기 위해 짜는 스크립트는 항상 고뇌의 시간을 요구한다. )

뭐 서론의 헛소리가 길었지만, 어쨌든 제목과 같은 Framework는 예전 부터 있어왔나 보다.
다만 각종 Cloud 의 발전에 의해 좀 묻히지 않았나 하는 생각 과 함께,  기존 클라우드의 VM 으로서 Windows 서버를 굴리게 되더라도 IIS 의 성능 자체에는 MS 의 지원없이 할 수 없는 것들이 많이 있다.
그런 측면에서 이와같은 Framework 의 지원은 매우 반가운 일이며, 어떠한 형태로든 효율적인 IIS 의 Server Farm 을 구성 할 수 있다면 전단 웹 서버를 탄력적이고 확장가능하게 (MS에서 그렇다고 한다) 만들 수 있기에 서비스 구성에 고려할 만한 옵션이나 전략이 추가 되는 것이 아닌가 하는 생각이다.

물론, 요새 OpenNebula 2.0 이나 OpenStack 과 같이 마루타 할 것들이 많아져서 실제 구현을 한다거나 해 보지는 않았기에, 간단히 소개하는 정도로 하고 관계 되신 분들은 링크로 추가된 자료들을 검토해 보시면 될 듯 하다.
버전이 2.0 이니 1.0 부터 사용하신 분들도 많지 않겠나 하는 생각.

이와 같은 서버팜은 아마도 hosting 업체들에 유리하지 않겠나 하는 생각을 테스트없이 남발해 본다. 음;;;

원문을 보실 분들은 여기 ( http://learn.iis.net/page.aspx/905/microsoft-web-farm-framework-20-beta-for-iis-7/ ) 를 참고 하시면 되겠다.


서문.

오늘날, 웹서버 세팅과 각종 컨텐츠의 배포는 매우 고된 작업중 하나이다.  수많은 절차와 검증이 필요하며,플랫폼 관리를 위한 스크립트나 코드를 제작하여 힘겹게 운용하고 있다.

마이크로소프트 웹 팜 프레임웍 ( WFF ) 2.0 for IIS 7 은 호스팅 업체와 같이 수많은 서버를 관리해야 하는 사업체의 관리자에게  공급/확장/관리를 단순화 시켜줄 수 있는 도구이다.  관리자는 손쉽게 여러 서버를 확인할 수 있고, 컨텐츠의 배포 및 필요한 순간에 확장도 손쉽게 된다.  WFF의 사용으로,  서버군에 대한 단일화된 업데이트 및 헬스체크등의 기능을 쉽게 사용 할 수 있다.  이러한 도구의 사용 잇점은 역시, 보다 적은 비용 및 리스크로 서비스를 동일하게 구현 할 수 있다는 것이다.


주요 기능.

WFF 2.0 에 포함된 주요 기능은 다음과 같다.

* Server Farm 에 서버를 한방에 추가 할 수 있다.
* Web PI ( Web Platform Installer ) 를 사용해 Platform Provisioning 을 구현 할 수 있다.
* Web Deploy 를 사용해 Application Provisioning 을 구현 할 수 있다.
* 정책기반 Provisioning
* 추가적인 Platform components 및 contents 의 설치
* ARR ( Application Request Routing ) 을 사용한 부하 분산을 통해 서비스 업타임 증가.
* Farm 에 속한 서버들의 update 상태 및 Log 추적
* 확장 가능한 모델을 통해 추가적인 Provider 들의 write 허용.  ( 뭐 그냥 확장 가능하다는 말인듯 )


Key terms and concepts

간단한 개념 설명.

Server Farm
 - Web Farm 으로 불리우는  관리/공급/배포의 단순화를 위해 묶인 서버의 그룹

Controller Server
 - Server Farm 에 속한 서버들의 공급을 관리

Primary Server
 - 플랫폼에 설치된 어플리케이션 및 컴포넌트를 정의하기 위해 설정된 서버. 여기에 설치된 것들은 Server Farm 의 다른 서버( Secondary Servers ) 로 동기화 됨.

Secondary Server
 - Primary Server 로 부터  platform application / components / configuration settings / content / application 을 받아 동기화 되는 서버들.  ( Primary 를 제외한 나머지 모든 서비스 서버를 말함 )


Platform Requirements

Server Farm 에 구성되는 서버들은 다음의 사항을 충족 해야 한다.

* Windows Server 2008 or Windows Server 2008 R2
* .NET 2.0 또는 그 이상버전의 설치
* 다음중 하나의 계정
  - Server Farm 의 전체 서버들이 동일한 로컬 Administrator ID 와 Password 을 가지고 있거나,
  - Domain Account 에 Administrator 로 등록된 계정이 각 로컬에 동일하게 존재할 것 ( 쉽게 말해서 AD 하거나 )
* Server Farm 의 전체 서버들이 Access 가능한 네트워크에 위치하고 있어야 할 것.

방화벽 설정

다음의 두가지를 방화벽에서 허용 해 주어야 한다.

* Core Networking
* Remote Administration


Controller Server Requirements
컨트롤러 서버는 다음의 요구사항을 충족 해야 한다.

* 다음중 하나의 OS 사용 :  Windows Vista with SP1 / Windows 7 / Windows Server 2008 with SP1 / Windows Server R2
* Microsoft Web Platform Installer ( WEB PI ) 가 설치 되어 있을 것
* IIS 7 이 설치 되어 있을 것
* Microsoft Web Deploy module for IIS 가 설치 되어 있을 것
  note :  Web Deploy 모듈이 설치 되어 있지 않다면,  Web PI 설치 시에 dependency 에 따라 자동으로 설치가 진행 될 것이다.


Provisioning requirements

시스템 종류에 따른 요구사항.
Secondary / Primary 32-bit (x86) 64-bit (x64)
32-bit (x86) Supported Not supported
64-bit (x64) Supported Supported


간단하게 정리하면,  Primary 서버가 32bit 이면, Secondary 서버는 반드시 32bit 여야 한다.
Primary 서버가 64bit 이면 Secondary 서버는 32bit 나 64bit 모두 관계 없다.


OS 요구사항.
Secondary / Primary Windows Server 2008 Windows Server 2008 R2
Windows Server 2008 Supported Not Supported
Windows Server 2008 R2 Supported Supported


동일한 관계.



WFF 2.0 for IIS 7  cmdlets for Windows Powershell


WFF 2.0 역시  파워쉘로 관리가 가능하다.
파워쉘을 사용 하기 위해선,

1. Controller 서버에서 cmd 실행
2. 파워쉘을 실행하기 위해 다음의 커맨드를 실행 ( PowerShell )
3. 파워쉘 프롬프트에서 다음의 커맨드 실행
   Add-PSSnapin WebFarmSnapin
4. 다음과 같은 쉘 프롬프트가 보이면 성공
   Get-Command WebFarmSnapin\*

커맨드의 리스트는 아래와 같음.


 

서버 관리를 위한 cmdlets
cmdlet Name Description
Get-ActiveOperation Returns the operations currently running on the server or server farm.
Get-AvailableOperation Returns the operations available on the server or server farm.
Get-Server Returns a list of servers in the farm, or the server specified.
Get-ServerProcess Returns a list of the processes currently running on the server or server farm.
Get-ServerRequest Returns a list of the requests currently being processed on the server or server farm.
Get-TraceMessage Returns a list of the Trace messages from the server or server farm.
Get-WebFarm Returns the name of the server farm or farms available.
Install-ServerProduct Installs the specified product on the server or server farm.
New-MiniDump Returns the dump information from the server.
New-Server Add a server to an existing server farm.
New-WebFarm Creates a new server farm.
Remove-Server Removes a server from the server farm.
Remove-WebFarm Removes a server farm.
Run-Operation Executes the specified operation on the server or server farm.
Start-Server Starts the specified server.
Stop-Server Stops the specified server.



서버 팜 생성을 위한 예제.

파워쉘에서 다음의 커맨드 수행
New-WebFarm

다음과 같은 내용이 나옴




WebFarm 의 생성을 확인 하기 위해서는 다음의 커맨드 실행
Get-WebFarm





Server Farm 에 서버 추가를 위한 예제

파워쉘의 WFF cmdlets 에서 다음을 수행
New-Server

서버의 추가를 확인하기 위해서는 다음의 커맨드를 수행
Get-Server





날로 먹는 번역은 여기까지.



윈도우가 제공하는 많은 서버/시스템/플랫폼 관리 도구들은 그 최초 접근 및 구성/사용이 매우 쉬운것이 장점이다.
다만, 세부적인 문제가 발생했을때의 운용은 역시 실제 서비스에 도입 후 운용해 보아야만 알 수 있는 부분이 많으며,
장애가 발생한다 하더라도 MS 의 도움을 받아야 하는 경우가 많기 때문에 문제 처리에 지연이 발생 할 수 있다.
이러한 문제는 오히려 오픈소스 측면에서는 상당한 기술자가 존재하지 않으면 클라우드를 구성조차 ( 현시점에서 ) 하기 힘들다는 사실과 견주어 볼때 대단한 잇점이 될 수 있다.  물론 WFF 의 존재 가치가 클라우드와는 다르지만.

어쨌든, 사용하기 쉽고 장기적 관리가 용이한 신뢰할 만한 툴이 나온다는건 언제나 즐거운 일이다.
다만, 이를 사용한 서비스의 벤치마크 또는 성능 측정 및 배포시의 동기화 시간 등은 서비스 도입 전 반드시 체크해야 할 항목으로 두고 고려 해 보도록 하자.



다시 한번 본 포스팅의 링크는 모두 다음에 속한 링크에서 가져왔음을 미리 말해 둔다.

출처 : http://learn.iis.net/page.aspx/905/microsoft-web-farm-framework-20-beta-for-iis-7/


( younjin.jeong@gmail.com , 정윤진 )



pNFS on Nexenta

Techs
( younjin.jeong@gmail.com , 정윤진 )


파일 시스템의 클러스터링에 대해서는 이미 이슈화 된지 몇년이 지난 상태여서 본 내용에 대해서 이미 확인해 보거나 BMT 까지 수행 해 보신 분들도 많으시겠지만, 간략한 소개의 의미 및 nexenta.org 의 관련 내용 번역으로 간략히 포스팅 하고자 한다. pNFS 를 Nexenta 에서 서비스로 사용하는데에는 다소 신중함이 필요 하겠지만, VM 에서 여러대의 Nexenta 를 올려두고 간단히 테스트 하여 성능을 비교하는 재미는 쏠쏠하지 않겠는가.


pNFS 에서의 p 의 의미는, Parallel 이다. 전통적인 NFS v4에서 지원하는 단일 서버 - 클라이언트 서버 간의 Data 와 Meta Data 통신을 구분하여 병렬로 나누어 놓았다고 생각하면 이상적이라 할 수 있겠다.
클러스터 파일 시스템은 굉장히 여러가지 종류가 있고 구현 방법에 따라 설치가능한 패키지들이 있겠지만, 전통적으로 사용되는 NFS 에 대한 병렬 확장은 이미 2005년 경 부터 각 벤더 ( ex. EMC, IBM, NetApp ) 에 의해 연구되어 왔고, 종래에 와서 File 기반 서비스에 대해서는 어느정도 사용 할 만한 규모가 되었다 생각 한다.
물론 Block Level 의 클러스터FS 에 대해서는 여기서는 논외로 하고.

일단 본 포스팅에서 소개하고자 하는 내용은 Nexexta 에서의 pNFS 구현이며, 이 내용은 nexenta.org 의 wiki 내용 중 일부를 번역 한 것이며, 한글을 읽는데 불편함을 느끼시거나 원문을 직접 보고싶은 분들 께서는
http://www.nexenta.org/projects/6/wiki/PNFS?version=37 에서 내용을 참조 하시면 되겠다.

소개 ( 본 내용의 날짜는 2010년 01월 24일에 포스팅 된 wiki 를 근거로 한다 )
병렬 NFS ( pNFS )는 NFS v4.1 표준에 포함된, 클라이언트가 스토리지에 병렬로 직접 엑세스 하는 방법을 다루고 있다.
pNFS 는 오늘날 사용되고 있는 NFS의 확장성 및 성능상의 이슈를 해결하기 위하여 대두된 구조로서, 기본적인 아이디어는 데이터와 메타데이터를 분리하는 것이며, 이는 아래의 그림과 같이 전통적인 NFS 와 pNFS가 어떻게 다른지 설명 될 수 있다. ( 이미지는 pNFS 위키페이지의 것을 성능상의 이유로 본 블로그에 사진으로 첨부한다. )

Traditional NFS




How pNFS works.



차이점을 설명하면,

1. pNFS는 클라이언트들이 데이터 서버에 직접 엑세스가 가능하도록 하고 있다.
2. 데이터는 데이터 서버들 사이에서 분리되어 저장이 가능하다.
3. 데이터에 대한 엑세스는 메타 데이터 서버들을 통해 하위 호환성을 유지한다.

이로 인한 잇점은,

1. 고성능 : 확장 가능한 여러대의 서버로 파일을 분산함으로서 성능 및 확장을 노릴 수 있다.
2. 수평적 확장 :  단일 NFS 를 사용함으로서 발생 할 수 있는 제한에서 자유로울 수 있다.
3. 데이터와 메타데이터의 분리 :  데이터에 대한 변경 ( 생성, 추가, 삭제 기타 등 ) 은 메타데이터 서버에서 유지한다.
4. 전통적 NFS서버의 사용성을 유지한다.
5. 전통적 NFS서버와 같은 방법으로 마운트 할 수 있다.

#mount server:/path /mnt


pNFS on Nexenta

현재 pNFS 의 기능은 on-gate b121 에 기초하고 있으며, 이는 NCP 에서 컴파일/빌드 되었으며, 동작한다.
pNFS 에 관한 보다 많은 정보, 바이너리 및 소스와 컴파일러 셋( sun studio and other tool set )은 다음의 링크에서 다운로드 가능하다.  [pnfs-project] http://hub.opensolaris.org/bin/view/Project+nfsv41/downloads


Nexenta Core 시스템에서의 pNFS 셋업

pNFS 를 위한 3가지의 주요 설정 항목이 있다.  클라이언, 메타데이터 서버 ( MDS ) , 데이터 서버 ( DS )

현재, DS와 MDS는 반드시 별도의 머신에 설치 되어야 한다. 기본적으로 NCP - pNFS 설정을 위해서는 3 개의 머신을 추천한다.  한대는 클라이언트, 한대는 메타데이터 서버, 마지막 한대는 데이터 서버.
지금까지 설명 된 내용을 구동하기 위한 설정은 아래를 참고 한다.


메타 데이터 서버 설정 ( MDS )

공유 path 생성

#share [pathname]


데이터 서버 생성 ( DS)

파일 시스템 공유 설정

#sharemgr create -P nfs p-group
#sharemgr add-share -s /export p-group

NOTE: 본 단계에서 사용하는 파일 시스템은 임시적으로 사용하는 것이다. 데이터 서버는 지정한 파일 시스템을 사용하지 않는다. 데이터 서버의 SMF 서비스 ( svc:/network/dserv:default ) 는 NFS 서버의 SMF 서비스 ( svc:/network/nfs/server:default) 에 의존적이다.  파일 시스템의 공유는 NFS 서버의 서비스가 활성화 되었으며, 구동중임을 보장한다. ( 즉, NFS 서비스가 올라오면 관련된 서비스가 정상 동작함을 의미 한다는 표현 )

데이터 서버는 dservadm 툴을 사용하여 관리되며, 현재 man 페이지는 제공되고 있지 않으나 --help 옵션은 가능하다.

#dservadm --help

MDS 의 주소를 DS에 등록한다.

1. #dservadm addmds [MDS_IP_ADDR]
2. /etc/hosts 파일에 엔트리로 등록

pNFS 데이터셋 생성

#zpool create ppool /dev/dsk/c1t1d0
#zfs create -t pnfsdata ppool/pdata

NOTE:  데이터 서버에는 적어도 1개의 pNFS 데이터셋이 존재해야 한다. 따라서, 여러개의 인스턴스가 데이터 서버에 존재한다면, 인스턴스별로 반드시 1개 이상의 데이터셋을 생성해야 함을 잊지 말자.

dserv 서비스 시작 및 온라인 체크

#dservadm enable
#svcs dserv
    STATE          STIME        FMRI
    online         20:45:24    svc:/network/dserv:default


클라이언트 설정

MDS를 클라이언트로 마운트.

#mount -F nfs -o vers=4 [mds:/path] [mount_point]


현재 기능상의 문제. ( 이 부분의 번역은 다소 오류가 있을 수 있어 원문을 함께 첨부합니다. 오류 없으시길 )

클라이언트로 부터 파일이나 디렉토리가 제거될 때 주요한 병목이 발생하고 있다.
The major bottleneck is the fact that currently even though the files and directories are deleted from the client.. the dataset that is created on the withholding pool does not show any reduction in size.. This mean, only the namespace is being deleted from the client and mds.. Thus over a period of time the data server will run fill up and the only solution is to delete the entire zpool.
이에 대한 내용은 링크를 참조.

http://hub.opensolaris.org/bin/view/Project+nfsv41/
Project gate::
ssh://anon@hg.opensolaris.org/hg/nfsv41/nfs41-gate
Project logistics::
http://hub.opensolaris.org/bin/view/Project+nfsv41/projectlogistics


도움 요청은  IRC.frenoode.net 의 nexenta 채널로.
메일링 리스트는  gnu-sol-discuss@opensolaris.org



조금만 더 살펴보면, 이 pNFS 는 다양한 방법으로 각 스토리지 벤더에서 지원하고 있다. 이중 여기서 소개된 nexenta 의 opensolaris 진영에서도 infiniband 와 같은 고속 통신을 사용하여 pNFS over RDMA 와 같은 방법으로 구현하는 것도 있다.  물론 NetApp 의 OnTAP 에서도 그들의 독자적인 방법으로 기능을 제공한다.

주요한 것은 어떠한 파일 시스템을 사용하던, 이제는 데이터가 페타 또는 그이상의 크기를 필요로 하는 곳이 많아지게 되므로, 이와같은 병렬화된 파일레벨의 공유시스템 및 이를 사용했을때 발생하는 성능상의 이슈를 어떠한 방식의 캐싱으로 풀어나갈 것인가, 어디에 적용해야 할 것인가 등이 주요한 고민으로 작용 할 것 같다.

언제나 고민되는 스토리지다. 

각 벤더의 링크들.
http://www.panasas.com/products/pnfs-resource-center.php
http://www.netapp.com/kr/communities/tech-ontap/pnfs-ko.html
http://www.almaden.ibm.com/storagesystems/projects/pnfs/


( younjin.jeong@gmail.com , 정윤진 )


+ 요것은 초큼 다른 내용이지만, MPI-IO 관련 내용.
http://www.mcs.anl.gov/~thakur/papers/mpi-io-noncontig.pdf

MONO Environment on Ubuntu

Techs
( younjin.jeong@gmail.com , 정윤진 )


최근에 웹지니 횽아가 모노로 이것저것 가지고 노는 바람에 본의 아니게 모노 구동환경의 셋업이 자주 필요 해 질 것 같아 일부러 삽질 한번 해 보았다.


Mono Logo





컴파일 시간을 제외 하면 설치 자체는 매우 간단 하므로, 그냥 주욱 커맨드를 쓰도록 한다.

물론, 우분투 설치를 이야기 해 주진 않는다.  @_@;; 
이제 막 설치가 끝난 서버 버전의 Clean 한 시스템이 준비 되었다 친다.

# Package Install
root@mono:~# apt-get update
root@mono:~# apt-get dist-upgrade
root@mono:~# apt-get install gcc pentium-builder build-essential bison gettext pkg-config
root@mono:~# apt-get install libglibmm-2.4-dev libglibmm-2.4-doc libglib2.0-0-refdbg libglibmm-2.4-1c2a
root@mono:~# apt-get install apache2 apache2-dev

# Source downloads from http://ftp.novell.com/pub/mono/sources-stable/
root@mono:~# mkdir /usr/src/apps
root@mono:~# cd /usr/src/apps
root@mono:/usr/src/apps# wget http://ftp.novell.com/pub/mono/sources/mono/mono-2.6.4.tar.bz2
root@mono:/usr/src/apps# wget http://ftp.novell.com/pub/mono/sources/xsp/xsp-2.6.4.tar.bz2
root@mono:/usr/src/apps# wget http://ftp.novell.com/pub/mono/sources/mod_mono/mod_mono-2.6.3.tar.bz2

# Extract tarball
root@mono:/usr/src/apps# tar xvjf mono-2.6.4.tar.bz2
root@mono:/usr/src/apps# tar xvjf xps-2.6.4.tar.bz2
root@mono:/usr/src/apps# tar xvjf mod_mono-2.6.3.tar.bz2

# Build MONO
root@mono:/usr/src/apps# cd /usr/src/apps/mono-2.6.4
root@mono:/usr/src/apps# ./configure --prefix=/usr/local   # if you wants any customize, type --help and add configure options
root@mono:/usr/src/apps# make && make install

# Build xsp
root@mono:/usr/src/apps/xsp-2.6.4# ./configure --prefix=/usr/local/ 
root@mono:/usr/src/apps/xsp-2.6.4# make && make install

# Build mod_mono  for apache
root@mono:/usr/src/apps/mod_mono-2.6.3# ./configure --prefix=/usr/local --with-apr-config=/usr/bin/apr-config

# Add mod_mono.conf to apache2.conf  ( or sites that you want to run MONO )
root@mono:/etc/apache2# echo "Include /etc/apache2/mod_mono.conf"  >> /etc/apache2/apache2.conf
root@mono:/etc/apache2# tail apache2.conf

# Reload apache
root@mono:/# /etc/init.d/apache2 restart

실제 커맨드를 사용하는건 매우 간단하고, 복잡한 구성이 아니기 때문에 금방 설치가 가능하다.
필요한 경우는 위의 커맨드로 스크립트를 작성해도 별 무리가 없겠다.

서비스 용의 박스 세팅은 조금 더 신경을 써 주어야 하는 부분이 있겠지만, VM에 올려서 가볍게 사용하기엔 충분하다고 본다. 물론, 서비스 컨텐츠의 분산을 노리는 다른 웹 서버와의 조합도 충분히 가능하겠지만.

다음은 WAS로 사용될 수 있는 아주 간단한 서버 구성이 되겠다.

--- Request --->  Nginx ---> Apache with mono ---> DB
                              |                          |
                              +    NFS Storage    +

static contents handled by Nginx
dynamic contents handled by Apache


리눅스에 입문하여 모노로 닷넷 코드를 돌리고자 하시는 웹 개발자 분들께 도움이 되길 바란... ; 퍽;

+ 추가 내용
다음의 링크 참조
http://www.codeproject.com/KB/cross-platform/introtomono2.aspx
http://www.mono-project.com/Main_Page
http://www.mono-project.com/Mod_mono



( younjin.jeong@gmail.com , 정윤진 )

NAPI on Linux

Techs

( younjin.jeong@gmail.com , 정윤진 )

이제는 오래되어 버린 기술이지만, 2006년 경의 2.6.1x 대 커널에서의 NAPI 사용으로 인한 시스템 부하 절감 및 네트워킹 성능 향상은 경이로운 것이었다.  무지막지한 인터럽트 증가로 인하여 static 파일을 서비스 하는 웹 서버가 죽을똥 살똥 하던 모습이란.

언젠가 한번은 적어야지 했는데, 마치 Memory Hole 관련 문제처럼 언젠가는 잊어버리지 않을까 싶어, 생각 난 김에 포스팅 한다.

오랜만에 보는 HOW-To 문서를 번역할 예정이며, 요새 커널 버전과는 매우 동떨어져 있지만.. 뭐 그래도 잘 설명 되었으니까.   문서 원본은 아래의 링크에서 참조 할 수 있다.
( http://www.cookinglinux.org/pub/netdev_docs/napi-howto.php3.html )


NAPI 에 대해 자세한 설명은, 아래의 더보기를 통해 보시도록..
(번역이 허접해도 용서를..)




결국, 이런저런 내용이 많지만, NAPI 의 핵심은 다음의 몇가지로 압축 될 수 있다.

1)
고부하 상태건 저부하 상태건 패킷의 유입으로 인한 하드웨어로 부터 ( 하드웨어 드라이버로 부터) 의
직접적인 인터럽트는 시스템에 심각한 부하를 일으킬 가능성이 있다.

2)
따라서 이와 같은 인터럽트는 NAPI 및 기타 하드웨어 ( NIC )의 인터럽트 제어를 통해 부하율을 낮출 수 있으나,
다소간의 지연이 발생 할 수 있다.

3)
NAPI 가 동작하는 기본적인 방식은 Polling 이며, 이를 쉽게 말하면 유입된 패킷이 발생할때 마다 인터럽트 하여
가져오는 것이 아니라 드라이버가 원하는 때에 적절한 스케줄링을 통하여 폴링으로 한꺼번에 가져온다.

4)
따라서 이러한 패킷을 저장하기 위한 공간이 필요하며, 이러한 공간이 포화가 된 경우/ 또는 시스템에서 처리
불가능한 경우 등에 대한 대비가 필요하다.

5)
NAPI 는 기본적으로 rx ring 에 동작한다.


로 압축 할 수 있겠다.


번역한 문서가 아주 옛날 버전이기는 하지만, 최신 문서 소개해 봐야 다 기본 내용은 거기서 거기.

실제 netpipe 등과 같은 툴을 통해 packet storming 이나 하드웨어 레벨의 테스팅을 하다 보면
쉽게 접하고 튜닝이 가능한 부분이며, 힘들어하는 시스템에 idle 을 조금이나마 안겨 줄 수 있는
방법이라 하겠다. 배포판 또는 드라이버별로 적용이 되고 안되는 등의 차이가 있는 듯 하니
궁금하면 dmesg 를 확인 해 보길 바란다.


오늘은 이만..


( younjin.jeong@gmail.com 정윤진 )