병렬 ssh 작업에 대하여

[taejoon moon]

주말들 잘 보내셨나요.

오늘은 먼저 병렬로 ssh 작업하는 경우와 Configuration Management 툴에 대해서 이야기를 해 볼까 합니다.

2009년 sysadmin 에서 공개세미나를 할 때 주로 이런 툴들에 대해서 다루었습니다.
http://wiki.kldp.org/wiki.php/SyadminStudyConf/20091124
slack,dist, pupet, controltier(controltier는 configuration management 툴은 아니라고 볼 수 있음) 등.

1. 병렬 ssh 작업
여러 대의 리눅스 서버를 운영하는 경우 동시에 각 서버에서 작업을 하려고 할 경우 여러가지 방법이 있습니다.

ssh 스크립트 이용 : ssh 로 자동 로그인할 수 있게 만들고 쉘스크립트 만들어서 for loop 문 돌리면서 순차적으로 명령을 실행할 수 있습니다. for loop 로 순차적으로 작업을 할 경우 서버 댓수가 많아지면 그에 따라서 작업 속도가 느려집니다. 물론 for loop 안에서 각 명령을 백그라운드에서 돌릴 수 있도록 하거나 서버 목록을 나누어서 돌리는 방법등이 있지만 결과 리포팅받고 에러난 시스템 체크하는 등의 작업이 매우 귀찮습니다.

그래서 이러한 병렬 ssh 작업을 위한 툴들이 나옵니다.

clusterssh : clusterssh는 동시에 xterm 화면을 여러개 띄우고 한번 타이핑을 하면 동시에 같은 명령이 동시에 실행됩니다. 스크립트를 실행하기보다는 직접 순차적으로 명령어를 실행하는 형태입니다. 동시에 실행할 수 있는 호스트에 제한이 생길 수 있고 수작업을 여러 대의 서버에서 동시에 하는 방식이기 때문에 위험성이 있습니다. 그렇지만 소규모의 시스템에서 동시에 위험하지 않은 명령을 내리는 데는 유용할 수 있습니다. 그렇지만 x-windows 프로그램이기 때문에 gui 환경을 구성해야지요.
http://sourceforge.net/projects/clusterssh/

pssh : 한번 명령을 내리면 여러 대의 서버에서 동시에 명령을 실행할 수 있습니다.
http://code.google.com/p/parallel-ssh/

dist : naver 에서 개발. 한번 명령을 내리면 여러 대의 서버에서 동시에 명령을 실행할 수 있습니다.
http://dev.naver.com/projects/dist/

간단히 pssh 와 dist 를 비교하면 다음과 같습니다.
- pssh 에서는 호스트 목록은 파일에서 가져올 수 있지만 명령어는 직접 지정을 해야 한다. pscp 기능을 이용 직접 업로드 해야 한다. 반면 dist 는 명령어를 스크립트로 지정하면 자동으로 스크립트를 업로드하고 실행 후 삭제를 한다.
- pssh 에서는 해당 호스트명과 결과과 여러 줄에 걸쳐서 나오지만 dist 에서는 한줄에 호스트명과 스크립트 실행결과를 볼 수 있다. 스크립트 작업시 dist 가 편리한 방식이라 생각이 든다.
- pssh 에서는 ssh 옵션을 변경할 수 있다. 그러나 dist 에서는 .ssh/config 에 ssh config 설정을 하고 작업을 해야 한다.

dist 에서는 scp 기능도 함께 지원하고 레포팅도 편리하게 나옵니다. 그렇지만 ssh 옵션을 바꿀 수 없기 때문에 만약 리눅스 시스템의 ssh port 나 옵션이 다르게 설정이 되어있다면 dist 실행을 하는 쉘스크립같은 것을 만들어서 처리하는 것이 편리합니다.

pssh, dist 모두 멀티스레드 기능을 이용하여서 처리하는데 dist 의 경우 시스템 사양에 따라서 다르겠지만 서버 댓수가 천대 넘어가면 중간에 멈추는 경우가 있습니다. 이 부분은 쉘스크립트를 하나 짜서 적용할 호스트의 갯수를 적절하게 쪼개어서 나누어 처리하고 결과를 합치면 됩니다.

[장군수]

안녕하세요  매번 메일을 읽기만했는데 요즘 잘사용하고있는 툴과 관련된 주제인것 같아 회신해봅니다 Fabric 이라는 툴인데 멀티스레드를 통한 병렬작업을 지원하고 출력은 타겟 호스트 기준으로 정렬해서 보여줍니다  ssh 프로토콜을 기반으로 하는 병렬 작업 API를 파이썬을 통해 구현하고있고 제공하는 API 를 잘활용하면 재사용 가능한 코드로 표현할 수있어 편리하네요

2012. 11. 26. 오전 10:47에 "taejoon moon" <taejoo...@gmail.com>님이 작성:

--
Google 그룹스 'sysadminstudy' 그룹에 가입했으므로 본 메일이 전송되었습니다.
웹에서 이 토론을 보려면 https://groups.google.com/d/msg/sysadminstudy/-/W8nQwi2p1f4J을(를) 방문하세요.
이 그룹에 게시하려면 sysadm...@googlegroups.com(으)로 이메일을 보내세요.
그룹에서 탈퇴하려면 sysadminstud...@googlegroups.com로 이메일을 보내주세요.
더 많은 옵션을 보려면 http://groups.google.com/group/sysadminstudy?hl=ko에서 그룹을 방문하세요.

[taejoon moon]

네 Fabric 소개 감사합니다.
프로그램 정보 자체는 웹을 통해서 정보를 보면 되지만 지금 현재 사용을 하고계시다면 ssh 스크립트를 이용하는 것에 비교해서 어떤 장점이 있는지 사용하면서 어떻게 활용을 하고 있는지 등 좀 더 자세한 정보를 공유해주시면 좋을 듯 하네요.

Fabric의 경우 아래 "Provisioning : OS설치-시스템 설정-애플리케이션 서비스 단계" 중 애플리케이션 서비스 단계에서 언급했던 프로그램입니다.
https://groups.google.com/forum/?fromgroups=#!topic/sysadminstudy/_R3S3m6nZxM
Capistrano, ControlTier, Fabric, Func, Mcollective

저는 Capistrano, Fabric, Func 프로그램은 사용을 해 본 것은 아니고 아래 ControlTier 문서를 보시거나 인터넷 검색하다보면 많이 나오는 툴들이라서 간단히 정보만 본적이 있습니다.
http://doc36.controltier.org/wiki/ControlTier

- 개발언어로 구분
Capistrano : ruby
ControlTier : java
Fabric : python
Func :  python
Mcollective : ruby

Fabric http://docs.fabfile.org/en/1.5/tutorial.html
capistrano https://github.com/capistrano/capistrano/wiki
func  https://fedorahosted.org/func/

개발언어로 보면 python 으로 된 것이 많네요. pssh, dist 도 모두 python 으로 개발을 한 것입니다.
일단 언어 자체가 중요한 것은 아니고 어떤 기능을 제공하느냐가 중요하겠지요.
Capistrano, Fabric, Func 잠시 살펴보면 모두 ssh 스크립트를 대체하여 운영자가 편리하게 각종 작업을 하기 위한 툴들입니다.
pssh, dist 의 경우는 ssh 에서 사용하는 스크립트나 명령을 대신 실행해주는 기본적인 기능이라면 Capistrano, Fabric, Func 프로그램의 경우는 여기에 다른 여러가지 부가 기능들을 넣은 것이라고 판단이 됩니다.
아뭏든 어떤 툴을 사용하든지 그때그때 명령어를 쳐서 원하는 결과를 얻을 수도 있고 아니면 스크립트나 각종 모듈로 만들어서 원하는 결과를 얻는 형태입니다.
중요한 것은 하나의 표준을 만들어서 각종 프로그램 배포시 또는 어떤 작업시 동일한 프로세스를 가져가는 것이겠지요.

http://doc36.controltier.org/wiki/ControlTier#Is_ControlTier_the_same_as_Capistrano.2C_Fabric.2C_or_Func.3F
In their most fundamental concepts, ControlTier, Capistrano, Fabric, and Func are similar tools. We'd definitely call Capistrano, Fabric, and Func basic Command Dispatching Frameworks.

However, ControlTier, by design, goes far beyond what these other tools provide. The automation libraries and the web-based tools that ControlTier provides are designed to let you build full automation systems ready for use by enterprise or large-scale web operations teams. There are also features like error-handling and centralized logging that just aren't in the scope of other command dispatching tools

ControlTier 페이지에서 비교한 내용을 보면 Capistrano, Fabric, Func  프로그램을 모두 basic Command Dispatching Frameworks 이라고 정의하고 있습니다. (간단히 ssh 원격작업이라고 생각하시면 될듯) 그런데 ControlTier는 뭐가 다느냐.. controltier는 자동화된 라이브러리와 웹 기반의 툴을 제공하여 엔터프라이즈 환경이나 규모가 큰 운영 환경을 위한 완전 자동화 시스템을 제공한다는 내용입니다. 다른 툴들이 제공하는 기능과 함께 에러 처리, 중앙 로깅 시스템등의 기능을 제공합니다.
예를 들어 hello world 를 출력하는 예를 들겠습니다.
어떤 언어를 쓰건 스크립트를 하나 만들거나 모듈을 만들어 해당 프로그램을 실행하여서 hello world 를 출력하도록 하겠지요.
ssh 를 이용하든 아니면 자체 에이전트를 이용하든 각 시스템에 접속하여 해당 프로그램을 실행하고 그 결과를 돌려줍니다.
ControlTier 를 이용하는 경우에는 이러한 명령을 사전에 정의합니다. 그런 다음 pssh 나 dist 로 실행을 하는 것처럼 controltier 에서 제공하는 프로그램을 이용, 명령행으로 실행하여 결과를 볼 수 도 있고 웹UI에서 실행할 수도 있습니다. 결과 레포팅도 웹UI에서 볼 수 있습니다.

그러면 https://groups.google.com/forum/?fromgroups=#!topic/sysadminstudy/_R3S3m6nZxM 메일에서 소개한 mcollective 에서는 어떻게 hello world를 출력하나? 사전에 각 시스템에 hello world 를 출력하는 스크립트나 모듈을 배포해 두어야 합니다. (이런 것 말고 커널버전, os명 등 puppet 에서 기본 수집가능한 정보는 정의하지 않고 이용할 수 있음) 이건 좀 불편하게 느껴지죠?
그 다음 mcollective server 에 hello world 를 출력하라고 명령을 내리면 mcollective server 가 각 시스템에 브로드캐스팅을 날립니다. 그러면 여기에 소속해있는 시스템들은 hello world 를 출력하고 그 결과를 mcollective server 로 돌려줍니다.


pssh 나 dist 등으로 전체 서버에 임의로 명령을 실행하는 것은 잘못된 결과를 초래할 수 있으므로 최대한 조심해서 실행해야 하고 어떠한 툴을 쓰건 사전에 정의한 명령만 사용할 수 있도록 하는 것이 좋은 정책이라고 생각이 듭니다.

기술적인 것말고 일관된 정책을 한 조직에 얼마나 쉽게 뿌리내릴 수 있느냐는 관점에서 보면 Mcollective, ControlTier 보다는  Capistrano, Fabric, Func 도 좋은 것 같고 pssh 나 dist를 쓰는 경우에도 바로 사용하지 않고 래퍼 프로그램이라고 할까요? 이런걸 만들어서 제한되게 사용할 수 있도록 하는게 좋겠습니다.
Mcollective 의 경우는 pupuet을 이미 쓰고 있는 경우에는 조합해서 그나마 손쉽게 사용가능할 수 있는데 ControlTier의 경우에는 기존의 운영 프로세스 자체를 완전 바꾸어야 가능해서 도입이 쉽지는 않을 것 같습니다. 그렇지만 웹UI를 통해서도 각종 작업을 비숙련자에게 제공할 수 있는 것은 큰 강점입니다.

2012년 11월 26일 오후 10:33, 장군수 <skys...@gmail.com>님의 말:

[taejoon moon]

장군수님, 언제 시간 되시면 Capistrano, Fabric, Func 프로그램 간단히 비교 한번 해보시고 간단히라도 공유해 주시면 더욱 고맙겠네요.

2012년 11월 27일 오후 2:03, taejoon moon <taejoo...@gmail.com>님의 말:

[inyong]

흥미로운 주제입니다^^

 

참고로 ansible 과 rundeck이란것도 있습니다.

 

http://ansible.cc/ 

http://rundeck.org/

 

- rundeck은 java로 되어 있고 사용하기가 무겁더군요. configuration 자체가 어려워 중도 포기했습니다.

- dist, mussh, pssh 등도 써보았지만 손에 편한것은 pssh더군요. :-) 호스트명별로  출력결과가 저장되어

실행후 결과를 쉽게 필터링가능한것 같고요.  규모가 커져 갈수록 거추장 스러운 UI나 복잡한 컨피그는 싫어지고,

단순하고 심플한 기능들만 쓰게 되는것 같습니다.

 

 

감사합니다.

2012년 11월 27일 화요일 오후 2시 3분 18초 UTC+9, 문태준 님의 말:

[istyles mr]

간단한툴 하나 소개해드립니다.

 

sshpass : http://aero.sarang.net/blog/2009/01/ssh-1.html

 

중앙서버에 sshpass 를 설치하고, 서버 패스워드를 저장하여, 다수의 호스트에 명령을 동시로 내리고 있습니다.

보통 서비스 서버 50-100 서버의 스케쥴러 변동사항이 있을경우, sshpass 를 이용해서 처리하고있구,

서버 한대씩 순차적으로 처리하다보니, 조금 느린부분이 있어서, 호스트목록을 여러개로 나눠서 처리하고 있습니다.

간단한 설정변경이라면 한번에 처리하기도합니다.

관리서버가 많다보니.^____^; 한번에 처리할수있는거를 생각해보다가..

sshpass +  bash shell 궁합으로 처리하게되네요.

서버 설정변동이 거의없고,전체 서버구조가 비슷하게 구성되어 있어서.

나름 유용하게 잘사용하고있네요..

 

 

2012년 11월 26일 오후 10:33, 장군수 <skys...@gmail.com>님의 말:

안녕하세요  매번 메일을 읽기만했는데 요즘 잘사용하고있는 툴과 관련된 주제인것 같아 회신해봅니다 Fabric 이라는 툴인데 멀티스레드를 통한 병렬작업을 지원하고 출력은 타겟 호스트 기준으로 정렬해서 보여줍니다  ssh 프로토콜을 기반으로 하는 병렬 작업 API를 파이썬을 통해 구현하고있고 제공하는 API 를 잘활용하면 재사용 가능한 코드로 표현할 수있어 편리하네요

[aero]

http://rexify.org/
라는 것도 있습니다. 병렬명령실행이외에도 chef,puppet,cfengine같은기능도 있습니다. 자세한건 직접보심이~

2012/11/27 istyles mr <kimh...@gmail.com>

[GiSeong Eom]

- chef 사용을 고려하고 있다면 knife 명령을 통해서 비슷한 효과를 맛볼 수 있습니다.

• http://docs.opscode.com/knife_ssh.html
  
• http://wiki.opscode.com/display/chef/Knife+Windows+Bootstrap#KnifeWindowsBootstrap-knifewinrm
  

- 주객이 전도된 느낌(?)이지만 Microsoft System Center 2012 Orchestrator 이용해서도 가능합니다.

•  http://www.windowsitpro.com/content1/topic/understanding-system-center-orchestrator-2012-141144/catpath/system-center/page/2
  

- 역시 에디터처럼 취향의 문제입니다만, 병렬 실행은 Mcollective와 같은 접근 방향이 장기적으론 맞다고 봅니다. (스크립트를 잘 못짜서...ㅋ) 

[문태준]

여러가지 의견 감사합니다.
제가 처음 메일을 쓸 때 병렬 ssh 작업과 Configuration Management 툴을 두개의 메일로 나눈 이유가 있습니다.
두가지 우선순위를 생각해보면 제 의견은 Configuration Management 툴을 먼저 도입하고 보조적인 운영 작업을 위해서 병렬 ssh 도구를 사용하는 것이 맞다고 생각해서입니다.
지금도 병렬ssh 툴에 대한 의견들이 많이 나왔는데 거꾸로 Configuration Management 툴에 대해서는 아직 낯설고 도입하지 않은 경우가 많아서 그런 것 같은데요.
자동화된 인프라를 운영하기 위해서는 개별 시스템 설정을 자동으로 하고 지속적으로 점검하는 것은 필수라고 생각을 합니다.

설정관리 프로그램을 통하여 자동으로 각 시스템에 설정을 내리고 관리하고 업데이트한 후 예를 들어 전체 시스템을 점검할 필요가 있을 때는 병렬ssh툴을 통하여 필요한 정보를 찾고 고치고 수정하는 작업을 하면 된다고 생각합니다. 그래서 병렬ssh 툴이 보조툴이어야지 이게 기본툴로 된다면 이건 시스템 설정을 수동으로 관리한다는 이야기가 됩니다.

어떤 툴을 사용하건 중앙에서 시스템 설정을 관리하고 필요한 경우 병렬ssh 툴을 통하여 시스템을 점검합니다.
애플리케이션 배포툴도 병렬ssh툴이기는 하지만 성격상 따로 분류를 한 것인데 일반적으로 인프라를 구축하는 조직과 서비스 조직이 분리되어 있는 경우가 많기 때문에 인프라차원에서의 병렬ssh툴과 애플리케이션 배포툴을 분리한 것입니다. 애플리케이션 배포툴도 어떤 툴을 사용하건 조직안에서 표준화작업을 하여 동일한 툴과 동일한 프로세스를 이용해야 합니다.
실제로 힘든 부분이 개별 툴 선정보다는 이러한 툴을 이용한 표준화작업, 일관된 프로세스와 정책을 만드는 것이 더 힘든 과정입니다.

ControlTier의 경우는 병렬ssh 기능도 가지고 있지만 작업과정을 표준화하고 사전에 워크플로어를 정의하여 관리하기 위한 목적이므로 애플리케이션 배포툴에 더 가깝다고 판단을 하는데  Capistrano, Fabric, Func 과는 다른 각도에서 접근을 하고 있기 때문에 별로도 이야기를 한 것입니다.

Mcollective 의 경우도 Capistrano, Fabric, Func 와 비슷한 성격을 가지고 있지만 중간에 MQ라는 미들웨어를 이용합니다.
시스템 규모가 더 커진다고 하러다도 중간에 미들웨어를 이용하면 확장성에서 장점을 가지고 있어서 따로 이야기를 하였습니다.
병렬로 ssh 기능을 이용하여 처리하는 경우에는 ssh 역할을 하는 서버자체의 한계가 있기 때문에 다른 설계가 필요합니다.

현재 시스템 설정용 툴로 puppet 을 사용하고 있는데(cfengine도 있지만 cfengine을 모두 puppet 으로 마이그레이션하고 있음) 실시간으로 시스템의 특정 정보를 얻기 위한 용도로 Mcollective른 도입할 계획을 가지고 있습니다. 이미 QA 시스템에서는 Mcollective를 사용하고 있습니다.
pssh나 dist 같은 원격ssh 툴은 인프라조직에서 일부 인원은 계속 사용하겠지만 다른 조직의 사람들을 위해서는 이런 툴을 직접 적용하면 문제가 있을 수 있기 때문에 필요한 명령들을 미리 정의하고 모듈같은 것으로 만들어서 제한되게 접근할 수 있도록 할 예정입니다. (나중에 각 시스템에 접근하기 위한 게이트웨이 서버 구축을 이야기할 때 좀 더 설명을 하겠습니다)
Controltier같은 워크플로우툴은 당장 도입계획이 없지만 아래 아이디어를 테스팅해보고 나서는 도입을 검토해 볼 예정입니다.


- System configuration tool + workflow too
마지막으로 2011 usenix 세미나에서 나왔던 아이디어 하나 이야기를 하지요.
https://www.usenix.org/conference/lisa11/automated-planning-configuration-changes
http://www.usenix.org/events/lisa11/tech/full_papers/Herry.pdf
이 자료를 보시면 cfengine, puppet, chef 같은 프로그램과 controltier 같은 워크플로어 툴을 조합하여 어떻게 자동화된 인프라를 관리하는지에 대한 내용을 담고 있습니다.
이 자료에서는 시스템 설정 하는 단계를 다음과 같이 정의하고 있습니다.
Manual configuration : 수동 설정
Scripted changes : 스크립트 이용
Declarative tools : puppet, cfengine 같은 도구 이용
Fixed workflow orchestration : controltier 같은 도구 이용

Acitve/Standby 웹서버 구성하는 경우를 가지고 설명을 해 보지요.
Active/Standby 웹서버의 설정은 puppet 같은 툴을 이용합니다.
Active 웹서버를 Standby 웹서버로 바꾸는 경우 아주 간단한게만 이야기를 하면 다음의 절차가 필요할 것입니다.
- Standby 웹서버 살아있는지 점검
- Acive 웹서버의 apache 내림
- DNS 서버 해당 웹서버의 IP를 변경
- Standby 웹서버 서비스 올림

전체적인 작업과정은 controltier 에서 워크플로우를 정의하여 관리합니다.
그 과정에서 Active 웹서버설정, Standby 웹서버 설정 등은 controltier가 명령을 내리면 puppet을 실행하여 해당 서버의 설정을 바꾸는 것입니다.

시스템 설정을 설정관리도구가 관리를 하되 이런 과정 자체도 사전에 모두 정의하여 컴퓨터가 알아서 하게 하는 것입니다.
워크플로어를 만들 때 문제가 있는 경우 롤백을 할 것도 미리 정의를 해 놓으면 문제가 발생했을 경우 자동으로 또는 사람이 개입하여 롤백하면 됩니다.
이렇게 하는 경우 사람이 수동으로 failover 하는 작업을 자동화하는 것이 가능합니다.

이런 과정을 거칠 때 중간중간 자동으로 담당자에게 알람을 주는 것을 추가할 수도 있고 모니터링 서버에서 해당 웹서비스 IP 등을 변경해주는 작업 등도 추가할 수 있겠지요.

처음에는 준비하는데 무지무지 시간 많이 걸리겠지만 한번 잘 구축해 놓으면 정말 멋진 그림 나옵니다.

[Dr.Mirr]

안녕하세요 완전 몇천만년만입니다.

태준님 말씀대로, cluster working tool 들은 사실상 수동이나 다름 없는 작업입니다.

예외에 대한 처리가 API 나 정해진 템플릿 혹은 프로파일 들을 이용하는것보다 많은 엔트로피를 유발하기 때문입니다.

사실 진짜 자동화, 무인화 라는것은 불가능하다고 생각하는 입장입니다.

아무리 시스템을 자동화 시켜놓아도 인력이필요(인적모니터링등등 포함) 하기 때문입니다.

결국 이 프로파일 및 템플릿을 우선적으로 이용하고, API 를 통한 일차적 예외처리, 그리고 나머진 트러블슈팅과도 비슷한,

자동화에대한 수동관리인게 인프라자동화의 기본 프로세스이지요...

뻔한얘기만 계속 써내려왔지만, 사실 이 부분에서 또 다시 생각해 봐야하는 부분은,

Platform 별 지원 가능한 성능 맟 컨피그 범위라는걸 화두로 올려보고 싶어서 입니다.

보통 다들 주로 선호하시는 운영체제가 어떤것인지요? 사실 시대가 아무리 흘러가도, 예전과 별반 다름없이,

배포판 혹은 플랫폼별 셋팅이 매우다르며, 더욱이 같은 배포판이여도 버젼의 차이에 따라 엄청난 변화(?) 들이 생기고있습니다.

이건 가상화가 도입되면서부터 예견되었었죠, 레거시를 가상화로 풀 수 있다고 구라를 쳐놓구선,

컨피그나 프로파일은 지원하지 않아버리는 경우가 많이 보인다는거죠..

결국 이 공간에서도 선호하는 모니터링 툴, 선호하는 디플로이툴, 선호하는 매니지먼트 툴들이 갈려지는거라고 봅니다.

그래서 문태준님께서 얘기하셨듯이 일단 가장 엔트로피를 최소화하고 범용적 컨피그레이션 관리를 가능하게 하는 툴이 어떤것이 있으며,

그것들의 장단점을 뿌려내 보는기 선행되어 져야 한다고 생각합니다.

사실 몇년이 지났으나, 정리가 좀체로 되지 않은 문제라고 보여 글을 쓰게 되었습니다.

조금 개발하고, 맘대로 커스터마이징 하기 앞서, 가장 적합한게있다면 가려낸것도 중요하고,

그런게 존재 하지 않는다면, 어째서 몇년이지나도 새로 갈망하게 되는 것들이 있는지 조명해 보는 자리라고 생각합니다.

음..두서없이 갑자기 튀어나와 죄송합니다 꾸벅..

[Dr.Mirr]

음...수정이 안됬던가요 원래... 태준님 뒤늦게 축하드립미다 :)

[taejoon moon]

>> 사실 진짜 자동화, 무인화 라는것은 불가능하다고 생각하는 입장입니다.

-> 현재 국내 IT상황을 보았을 때 정말 자동화를 최대한 잘 하고 나머지만 사람이 수동으로 개입해고 있느냐 했을 때 그건 아니라고 생각이 듭니다.
기본적인 작업들을 대부분 수동으로 사람에 의존하고 있기 때문에 장애 생기고 똑같은 삽질하고 반복된 문제 생기는 것이지요.
단순반복작업은 기계에 맞기고 사람은 그러한 작업을 위한 기획, 개발 작업을 해야 하는데 현실은 그게 아니지요.
국내IT가 엄청나게 발전을 했다고 하지만 운영측면에서 봤을 때는 정말 10년전이랑 별로 달라지지 않았습니다.
회사에서 이런 것에 투자하지도 않고 문제의식도 잘 못 느끼고 그냥 사람으로 땡빵합니다.

OS와 관련하여 이야기를 하자만 유닉스 계열과 윈도우 계열은 분리가 되겠지요.
유닉스계열, 윈도우 계열을 모두 통합하는 문제로 가면 너무 커지니깐 유닉스 계열로만 한정을 짓고 이야기하겠습니다.
당연히 여러가지 배포판이 있고 다양한 유닉스 계열 운영체제가 있는데 보통 System configuration tools 에서 해당 OS를 체크할 수 있습니다.
운영하는 측면에서는 최대한 동일한 OS, 동일한 배포판을 가져가야 하지만 업데이트 주기가 있으므로 항상 혼합된 환경을 염두에 두어야 합니다.
이러한 부분은 System configuration tools 에서 해당 OS 및 배포본을 체크하므로 별 문제가 되지 않습니다.
가상화가 문제를 해결해 주는 것은 아니고 가상화를 하든 물리적인 서버를 이용하든 이건 운영차원에서 제대로 관리할 수 있도록 툴을 잘 써야 하는 문제입니다.

현재 puppet 을 이용하여 system configuration 을 관리한다고 했는데 위에서 말을 한대로 OS, 배포판 등을 구분할 수 있기 때문에 아래와 같이 if then 문을 이용하여 모두 처리 가능합니다. OS별, 배포판별 시스템 설정을 다르게 가져갈 수 있습니다. 보통 system configuration 툴에서 이런 부분을 처리해 주기 때문에 운영자는 자기가 하려고 하는 작업에만 집중할 수 있습니다.
if centos5 ; then
if centos4 ; then
만약 이것을 개별 스크립트에서 처리한다면 스크립트 만들때마다 (또는 모듈로 빼놓고 include 할수도 있겠지만) os, 배포판 등등을 체크하도록 하는 작업을 해야 해서 상당히 불편해지지요.
puppet 에서 예를 들어 test 라는 계정을 추가한다면 puppet 차원에서 해당 os를 접근하므로 데비안이면 알아서 데비안 명령어로, centos 이면 알아서 centos 명령어로 다른 유닉스 계열이라면 그 OS에서 사용하는 명령어로 계정을 추가합니다.
(cfengine v2에서도 해당 OS나 배포판 구분하는 클래스(그룹)을 만들어서 원하는 OS마다 다르게 설정합니다)

>> 일단 가장 엔트로피를 최소화하고 범용적 컨피그레이션 관리를 가능하게 하는 툴이 어떤것이 있으며,

-> 제가 https://groups.google.com/forum/?hl=ko&fromgroups=#!topic/sysadminstudy/_R3S3m6nZxM 에서 이미 소개를 했습니다.
국내에서 이런 툴들이 생소한 것이지 해외쪽 컨퍼런스 보면 이미 아주 예전부터 활발하게 진행되고 있는 프로젝트들입니다.
그런데 국내에서는 이런 정보에 대한 공유가 거의 없고 레퍼런스 사이트를 찾기가 힘드니 개별적으로 알아서 도전해볼 수 밖에 없는 상황입니다.
제가 예전에 스터디모임을 했던 것도 이런 것을 바꾸어보고자 했던 것이구요.
USENIX, 오렐리 컨퍼런스 보시면 puppet은 근 몇년간 아주 많이 언급되고 있습니다.
puppet이 되었건 chef가 되었던 실제 테스팅을 해보시면 원하는 것들 웬만하면 거의 다 지원될 겁니다.
무슨 툴이든 익숙한 것 하나 정해서 테스팅하고 결정하고 가면 됩니다. 모든 툴 다 테스팅하고 결정하려면 백만년은 걸릴 거에요...

[전득진]

안녕하세요. 프리랜서로 인프라 관련 업무를 수행하고 있는 전득진 입니다.

조그만 팁을 공유하려고 메일드립니다.

요즘은 배포문제도 있고, Auto scaling 도 자동화해야되겠기에 devops관련하여 조금씩 눈팅하고 있는 상황입니다.

최근에 저희 프로젝트 이슈로는 바이너리 배포할 때 내부 네트웍 문제로 2시간씩 소요되고 있어 BBCP 라는 tool을 사용하여 분할 압축/동시 전송하는 시스템을 테스트하고 있습니다.

저와같은 고민을 갖고 계시다면 BBCP한번 적용해 보세요.

http://moo.nac.uci.edu/~hjm/HOWTO_move_data.html 

http://pcbunn.cithep.caltech.edu/bbcp/using_bbcp.htm 

2012년 11월 30일 오전 10:04, taejoon moon <taejoo...@gmail.com>님의 말:

--

Google 그룹스 'sysadminstudy' 그룹에 가입했으므로 본 메일이 전송되었습니다.

[taejoon moon]

간단하게만 자료를 보았는데 무언가 재미가 있어보이네요..
ssh 로 업무 자동화하는 주제와는 다른데 새로 주제 하나 열어서 좀 더 자세한 정보 공유를 해주시면 도움이 될 것 같네요. 매우 큰 파일이나 디렉토리 트리 같은 경우에 좋다고 나와있군요.

bbcp can act similarly to rsync but will only checksum entire files, not blocks, so for sub-GB transfers, rsync is probably a better choice in general. For very large files or directory trees, bbcp may be a better choice due to its multi-stream protocol and therefore better bandwidth utilization.

그리고 더불어 말씀하신 배포문제, Auto scaling 도 단어만 봐서는 잘 모르겠는데요.
좀 더 자세히 풀어서 이야기를 해주시면 더 이야기를 할 수 있지 않을까 생각됩니다.

연관된 주제면 여기에서 논의해도 되고 다른 주제면 새로 주제 하나 여시면 됩니다. 부담감없이 팍팍 새로 이메일...

2012년 12월 10일 오후 3:23, 전득진 <oee...@gmail.com>님의 말: