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

오늘은 간단한 팁. 

맥용 인코딩 어플을 뒤져봐도 뭐 하나 쓸만한게 없는데 다들 도네이션이나 돈은 내란다. 

이전에도 avconv 를 소개 한 적이 있는데, 오늘 맥에서 보니 brew 에는 avconv 가 없어서 ffmepg 를 사용하는 방법을 소개 한다. 

먼저 brew 인데, 이건 구글에서 Home brew 라고 검색해서 먼저 설치 해 주어야 한다. 그거 설명은 패스. 

아, 그리고 Home brew 는 이를테면 Gentoo 리눅스의 emerge 같은 건데, 패키지 소스를 받아서 컴파일 후 맥에 설치하기 때문에 컴파일러가 필요하다. 이 말인 즉슨, Xcode 를 설치해야 하고, 아울러 Xcode 의 CLI 도구도 설치해야 한다는 말. 검색하면 다 나온다. 

어차피 기나긴 옵션에 대한 설명은 필요 없을 듯 하고. 

brew install ffmpeg 
==> Installing ffmpeg dependency: texi2html
==> Downloading http://download.savannah.gnu.org/releases/texi2html/texi2html-1.82.tar.gz
....
..
하면 뭔가 엄청 다운받고 컴파일 한다. 
...
기다리면, 
....
==> Installing ffmpeg
==> Downloading http://ffmpeg.org/releases/ffmpeg-1.1.tar.bz2
######################################################################## 100.0%
==> ./configure --prefix=/usr/local/Cellar/ffmpeg/1.1 --enable-shared --enable-gpl --enable-version3 --enable-nonfree --enable-hardcoded-tables --cc=cc
==> make install
/usr/local/Cellar/ffmpeg/1.1: 141 files, 25M, built in 3.1 minutes

# 하고 프롬프트가 떨어지면 설치가 완료 된 것.

ffmpeg -i My_Godness.avi -qscale 0 -vcodec mpeg4 -acodec libfaac -threads 16 -f psp My_Godness.mp4

# 다음과 같은 메세지가 주르륵 나오며 인코딩을 시작한다. 영상 파일의 크기에 따라 시간이 걸리므로 주의. 

ffmpeg version 1.1 Copyright (c) 2000-2013 the FFmpeg developers
  built on Jan  8 2013 18:20:08 with Apple clang version 4.1 (tags/Apple/clang-421.11.66) (based on LLVM 3.1svn)
  configuration: --prefix=/usr/local/Cellar/ffmpeg/1.1 --enable-shared --enable-gpl --enable-version3 --enable-nonfree --enable-hardcoded-tables --cc=cc --host-cflags= --host-ldflags= --enable-libx264 --enable-libfaac --enable-libmp3lame --enable-libxvid
  libavutil      52. 13.100 / 52. 13.100
........
.....
..
Stream mapping:
  Stream #0:0 -> #0:0 (mpeg4 -> mpeg4)
  Stream #0:1 -> #0:1 (mp3 -> libfaac)
Press [q] to stop, [?] for help
frame=227317 fps=262 q=0.0 Lsize= 2194142kB time=02:06:25.32 bitrate=2369.6kbits/s dup=1 drop=0    
video:2069449kB audio:118243kB subtitle:0 global headers:0kB muxing overhead 0.294866%

ffmpeg 는 무지하게 많은 옵션을 가지고 있지만 내가 가진 비디오를 모바일용으로 인코딩 하기위해서라면 위의 정도로 충분하다. 

간단히 설명하면, 

-i : 원본파일

-qscale 0 : 퀄리티 변경 없이 인코딩 할 것 

-vcodec mpeg4 : 비디오 코덱 

-acodec libfaac : 오디오 코덱 

-threads 16  : 작업을 수행 할 스레드의 갯수 

-f psp : 출력파일 

그럼, 즐거운 모바일 생활을 위해! 

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

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

1. 문제 

클라우드 클라우드 클라우드 지겨워 죽을 정도로 많이 이야기된다. 누구는 사업 타당성에 대해서, 누구는 어떻게 만들어야되는지에  대해서, 누구는 그 실질적 효용성에 대해서. 구름이 어쩌고 아키텍쳐는 뭔데 아마존과 구글이 뭘 했다더라 등등등. 

여기에 맵 리듀스가 뭐고 빅데이터가 어쩌구 하기 시작하게 되면 제조업 중심의 회사CIO 또는 전형적인 SI 타입의 레거시 IT 회사들의 의사결정자들에게 이 주제는 난공불락처럼 보였던 만리장성 쌓기처럼 들린다. 사실 그렇게 들리는 것이 맞을 수 있다. 대부분의 중견기업 관리자들에게 클라우드란 그저 어느날 KT 로부터 촉발된 새로운 타입의 인프라일 뿐 아니겠는가. 

요는, 그렇게 많이들 이야기 하고 있는 주제임에도 불구하고 아직도 이게 무엇인지, 어디에다 써야하는지 모르는 사람들이 생각보다 엄청 많다는 것이다. 대화를 조금 섞어보면 아는척 하기만 하는 사람도 참 많다. 아울러 KT 클라우드는 대체 자기가 만들었다고 하는 사람들이 왜 그리 많은 것인가. 내가 거기서 아키텍처 미팅하고 자동화 코드 작성할떄는 8-12명 정도가 다였는데. 뭐 이건 좀 다른 이야기고. 

우리나라 기업들에서 클라우드에 대해 모르는 것을 정리하면 대략 다음과 같은 것들이다. 

1. Amazon EC2 / S3 / Google AppEngine / Google Drive 서비스가 뭐하는 서비스인지 대부분 모른다.  

2. 위의 두가지 서비스를 직접 사용 해 본 중간관리자가 거의 없다. 

3. 구글과 아마존, 빅데이터에 대해서는 위와 아래로 부터 귀가 따갑게 들었다. 

4. 위의 1,2,3 번을 몰라도 Facebook / Twitter 는 들어봤다. 

5. 1,2,3,4 번을 다 듣고 안다. 그래서 클라우드를 만들어서 오라클을 넣을 생각이다. 

2. 클라우드 마이그레이션 하면 좋은 샘플

아주 먼 옛날, 그러니까 지금으로부터 대강 5년 전 즈음에 다녔던 호스팅 회사의 고객 중 다음의 고객이 급성장 하고 있었다. 이들은 누가 보아도, 다른 쇼핑몰과 비교해 보아도 확실히 매력적인 몇가지 요소를 가지고 있었다. 뭐 그것은 그 회사 사장님의 마케팅이나 경영적 노하우니까 나와는 상관 없다. 문제는 그 회사가 "괄목할만한 성장을 하고있다" 라는 것이었다. 그 사이트는 바로 Stylenanda.com 였고, 이 사이트의 엄청난 고객의 증가로 인해 기존의 시스템을 확장, 분산해야 하는 이슈를 쇼핑몰 담당팀과 함께 연구소에서 처리를 하기로 했다. 

아직도 매력적으로 보이는 그 회사

다른 쇼핑몰과 마찬가지로, 이 회사는 엄청난 양의 이미지를 서비스 하고 있었다. 레이아웃을 짜는 것이 쉽지 않아서 그런건지는 잘 모르곘지만, 대부분의 쇼핑몰들이 포토샵을 통해 페이지당, 또는 사진 한장에 몇메가씩 되는 사진을 페이지로 서비스 한다. 그리고 꼭 필요한 결재에 필요한 연동, 배송에 관한 부분, 뭐 그런것들이 일반적인 쇼핑몰의 시스템 구성이다. 

당시 우리는 크게 두가지 방향으로 성능을 개선하기로 했는데, 하나는 소프트웨어적인 튜닝을 통한 개선이었고 다른 하나는 하드웨어를 역할별로 분리하여 여러개의 프로세스를 한꺼번에 돌렸을 때 발생하는 심각한 양의 context switching 으로인한 CPU time 의 낭비를 막는 것이었다. 이 두가지 개선 방향은 디테일하게 말하는 것은 법적 문제가 있을 수 있기 때문에 여기서 줄이지만, 아무튼 큰 효과를 보였으며 단일 시스템으로서도 동일한 사용자 유입시에 시스템의 부하가 절반으로 감소했었다. 

뜬금없이 갑자기 잘 나가는 쇼핑몰을 예로 들었지만, 이것이 바로 왜 클라우드 시스템을 사용하면 좋은지에 대해 이야기 해 볼 수 있는 가장 좋은 예가 된다. 그리고 아마존에서 제안하고 있는 기존 서비스를 클라우드로 마이그레이션 할 때 나오는 LAPM 그림에 가장 적합한 모델이기도 하다. 그 과정은 예나 지금이나 크게 다른 것은 없지만, 이런 서비스가 클라우드로 이사갈때, 또는 애초에 클라우드에 있을 때 무지하게 이득을 볼 가능성이 높다는 것이다. 어떤 서비스도 마찬가지지만, 어느 순간에 급격한 성장을 보이며, 이 회사가 만약 IT 나 IT 리소스를 사용하여 서비스 하고 있던 회사였다면 확장/증설/튜닝을 통해 사용자 증가를 처리 하고자 할 때 반드시 모멘텀이 필요했다는 것이다. 

이러한 모멘텀을 줄여줄 수 있는 것이 바로 클라우드이며, 그 클라우드 시스템에 등록된 서비스가 "클라우드에 맞게" 등록되어 있을 때 확실한 효과가 발생 할 수 있다. 

3. 현실 그리고 앞으로는. 

우리나라의 대기업들이 하는 서비스 중에는 보통 데이터 폭발 발생하지 않는다. 심지어 발생중이라고 하더라도 그 양이 매우 미비하다. 더군다나 이미 있는 서비스들은 도저히 교체 불가능한 아키텍처와 벤더 제품들로 떡이 되어있다. 지금 시점에서 그것은 좋다 나쁘다를 가리기는 힘들며, 그것들은 그것 나름대로 이미 동작하고 있는 서비스다. 이야기의 흐름대로 만의 하나 그런 서비스가 생겨난다면 확장이 매우 힘들겠지만, 어쨌든 똑같이 다시 벤더를 사용해서 떡을 만들것이다. 비싸지고, 하청업체가 없어짐으로 해서 다시 코드 관리 안되고 나중에 뭐 좀 해보려면 년단위 프로젝트로 짜야하는 뭐 그렇게 전과 똑같은 수순. 

하지만 벤더 제품은 그 나름대로 존재의 의미가 있다. 그것들은 안정되고도 보장된 신뢰를 바탕으로 확장과 성능은 비록 떨어 질 수 있지만 여태까지의 인프라를 구성 해 왔으며, 지금 현재 기업에 구성된 업무 프로세스와도 밀접한 관련이 있다. 이것들은 기업에서 매우 중요한 포지션을 차지하고 있으며, 이것들이 어떠한 이유로든 중지하게 되면 심각한 문제를 발생 시킬 수 있다. S사 같은 글로벌 회사의 인증 시스템이 중지했다고 하면 아마 어마어마한 혼란을 초래 할 것은 누가 봐도 분명하다. 그래서, 벤더로 되어있지만 중요하고 쉽게 중지 시킬 수 없으며, 또 데이터가 매우 귀중하기 때문에 한꺼번에 어디로 옮기는 것은 쉽지 않다. 

따라서 중요한 것은, 클라우드에 넣어도 되는 것과 넣지 말아야 할 것, 즉 똥과 된장을 구분해야 할 필요가 있는데 이것이 잘 안되는 경우가 많다는 것이다. 한가지 더는, 똥과 된장을 구분했다면 이걸 가지고 국을 끓일지 쌈장을 만들지를 알아야 하는데 여기에는 아직 경험이 없다보니 일이 제대로 되지 않는 경우가 많다는 것. 

이런 현실을 탓하기 전에, 우리는 우리 스스로 자문 해 볼 필요가 있다. 우리는 과연 저런 생각을 가지고 있는 의사결정권자를 만났을 때 적절한 해법을 제시 할 수 있는가. 나는 아래와 같은 것들을 먼저 간단히 정리 해 봤다. 

1. 이미 잘 동작하고 있는 서비스의 "데이터" 를 클라우드로 이전 하지 말 것. 

2. 대부분의 기업에게 모바일 서비스는 신규 분야이므로, 이 부분을 우선 적용. 

3. 컴퓨트 클라우드는 하루 아침에 뚝딱 만들어 지는 것이 절대 아님. 장비 비용을 제외하더라도 년단위의 계획과 백억단위 이상의 자금이 필요함. 단, 이 이전에 소규모 POC 를 수행해야함. 

4. 현재 버리고 있는 데이터의 수집/아카이빙을 목표로 비교적 구현이 쉬운 스토리지 클라우드를 먼저 생각해야 할 필요가 있음. 

5. 기업 내부의 신규 사업이라면, 아마존과 같은 서비스에 런칭 해 볼 필요가 있음 

6. 기존의 인프라 관련 구성원들이 자동화 / 클라우드 서비스에 대해 익숙해 져야 할 필요가 있음 

최근 기존의 서버 / 인프라 벤더들이 엄청나게 저렴한 가격으로 시장을 공략하고 있다. 결론부터 말하자면, 이것들은 정상적인 가격이 아니다. 클라우드 태그가 붙지 않으면 제품이 팔리지 않는다. 그리고 그 가격을 바탕으로 다시 Vendor lock in 을 걸려고 하고 있으며, 여기에 클라우드 사업을 제안하고 있다. 여러가지 측면에서 클라우드에 대한 명확한 접근 개념없이는, 이 모든 것들은 국내 시장에 혼란을 가중시키고 있을 뿐이다. 

언젠가는 모든것을 깨닫게 되는 날이 오겠지만, 그 전에 현재의 어려운 경제적 국면에서 어마어마한 비용을 쏟아 뻘짓하는 것은 막을 수 있으면 막았으면 하는 바람이다. 그리고 그 "언젠가"를 보다 앞으로 당기는 것이 필요 하지 않을까 하는 생각. 

스타일난다의 시스템 확장이 발생했던 근본적 원인과 클라우드가 가져야 할 가장 큰 덕목인 Elasticity 를 생각해 볼 필요가 있다. 만약 기존의 서버로 구성된 레거시 시스템이 있다면, 그리고 클라우드를 사용해서 사업을 하고 싶다면, 해답은? 모바일 전용 페이지를 클라우드에서 시작 해 보는것, 그런 시작이 필요하지 않겠다 싶다. 말도안되는 Public IaaS 를 만들겠다 이런거 말고. 

결국은, 신규와 모바일 서비스를 통해 기업의 클라우드에 대한 역량을 준비해야 하며, 빅데이터에 대해서는 지금까지 버릴 수 밖에 없었던 데이터 소스를 저장할 스토리지 클라우드를 구성해야 한다는 말이 이 포스팅의 전부다. 

조금 마케팅적인 이야기라서, 숙취상태에서 쓴 글이라 너무 중구난방이다 라는 사족을 붙이고 싶은 포스팅. 

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

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

최근 포항공대와의 협력 프로젝트를 위해 정신없이 KTX 를 타고 위아래로 다니고 있는 와중에 Nutanix 라는 회사의 제품을 검토해 보라는 특명이 떨어졌다. 그래서 수차례 컨콜을 해 보고, 데모를 해 본 결과 이것은 현재 컴퓨트 클라우드에서 가지고 있는 스토리지 공유 모델에 대한 아주 적절한 해법을 제시한 솔루션이라는 생각이 들었다. 

일반적으로 컴퓨트 클라우드를 구성하게 될 때, 스토리지에 공유 스토리지 모델을 적용하고자 하는 경우 하이퍼바이저를 클러스터링 하게 된다. 이 방법에 NFS 를 사용하던 iSCSI 를 사용하던 이는 클러스터의 확장 규모에 따른 제약을 받게 되며, 이 제약에 의해 전체 서비스의 Availability 와 성능에 한계를 가지게 된다. 물론 컴퓨트 클라우드에 있어 중요한 것이 스토리지만은 아니지만, 이 스토리지의 공유 모델 구성과 어떤 방법, 즉 인터페이스를 사용하느냐에 따라 그 네트워크 구조도 함께 변하게 된다. 

물론 퍼블릭 서비스를 위한 클라우드 서비스라면 가급적이면 대부분의 서비스에 적절한 오픈소스 솔루션을 배치하고, 이를 슬기로운(?) 아키텍처로 구성해야 할 필요가 있다. 예를 들어 만약 KVM 이나 OSS Xen 을 사용하여 컴퓨트 클라우드를 구성한다고 했을 떄, 가급적이면 네트워크의 종류를 줄여야 물리적 케이블에 필요한 비용이 절감 될 수 있다. 관리 / 서비스 / 스토리지 의 네트워크를 전부 별도로 구성한다고 하면, 각 용도의 케이블링에 추가적인 비용이 발생하게 된다. 비단 케이블링 뿐만 아니라 이 케이블들이 직접될 ToR 스위치가 하나씩 더 필요하게 되고, 이는 결과적으로 비용 증가를 발생시킨다. 

이러한 비용을 절감하기 위해 서비스 + 스토리지 를 함께 혼용하여 사용하는 네트워크를 구성하면서, 이를 L3 레벨로 통신하게 함과 동시에 vSwitch 구성을 통해 SDN 을 사용하여 서비스 네트워크를 준비하고, Latency 가 증가하면 치명적인 스토리지 네트워크에는 서버/스위치 레벨에서 tx-queue / DSCP 등을 사용한 QoS를 서비스 네트워크에 적용하여 스토리지 트래픽에 대한 대역폭을 확보 하는 등의 복합적이고도 다소 복잡한 설계가 필요하다. 

어머 복잡도 하지.

Image source: http://www.h3c.com/portal/Products___Solutions/Products/Switches/H3C_S10500_Series_Switches/Detail_Material_List/201111/729682_57_0.htm

이러한 구성에서 오픈소스를 사용해야만 하는 이유는, 시장에서는 적어도 AWS에 비해 가격 경쟁력을 가져야 할 필요가 있기 때문이다. 우리 회사에서 클라우드 솔루션을 직접 만들었는데, 이것이 AWS 보다 비용이 높은데도 불구하고 써야만 하는 이유는 보안과 성능 이슈밖에 없다. 하지만 AWS의 서비스 비용이라는 것은 참으로 만들기 쉽지 않은 것이기 때문에, 오픈소스를 매우 높은 기술력을 통해 공격적으로 사용해야 할 필요가 있다. 

아울러 오픈 소스 뿐만 아니라 Commodity 하드웨어를 사용하는 것도 매우 중요한데, ipmi 정도만 지원하는 보드라면 용산에서 사다가 세팅하는 것도 용납될 정도가 되어야 한다. 더욱 저렴한 하드웨어를 사용하기 위해서는 더욱 많은 테스트가 필요하기 때문에, 시간이 더 필요하게 되고 개발기간이 증가하게 되며, 충분한 경험이 없다면 시간에 비해 좋은 결과물이 나오는 것도 쉽지 않을 것이다. 이게 힘들어서 기존의 메이저 벤더 제품으로 바르기 시작하면, AWS 가격은 고사하고 기존 호스팅 서비스보다도 배는 비싸질 것이다. 게다가 성능은 이미 안드로메다로. 충분히 좋고 저렴한 하드웨어를 선택하고 싶다면, Facebook 이나 Google 이 어느 회사로 부터 시스템을 가져다가 생산하는지 알아보도록. 또한, Cisco / IBM / HP / Dell 등에서 판매하는 하드웨어가 그 회사들이 직접 만든 것인지 역시 알아 볼 필요가 있다. 

이러한 노력과 기술력이 합쳐지고, 여기에 적절한 어플리케이션을 통해 하드웨어와 긴밀하게 동작 할 수 있다면 퍼블릭 클라우드를 만들기 위한 기본은 준비된다. API 를 지원하고 하는 것들은 이 이후의 문제가 된다. 

단, 많은 사용자에게 저렴한 비용으로 서비스 할 필요가 있는 것이 아니라 높은 비용이 들더라도 안정적인 컴퓨팅 클라우드 시스템을 만들고 싶은 경우에는 이야기가 조금 달라질 수 있다. 이를테면, 비용은 조금 들지만 안정적이고 편리한 운용으로 IT회사가 아니더라도 (클라우드에 대한 높은 기술력이 없다고 하더라도) 산업의 다양한 부분에서 회사 내부에서 가상화된 컴퓨팅 자원을 사용자에게 할당 하고자 하는 경우가 한가지 예가 된다. 직원에게 할당 해 주는 PC나 노트북은 자주 고장나며, 교체주기가 있고 회사에 필요한 각종 보안 소프트나 인증 연동, 그리고 업무에 필요한 소프트등을 계속 유지/보수 해 주어야 하기 때문에 매번 교육과 관리가 필요하다. 이것은 현대 기준으로 보면 매우 불필요하고 불합리한 일이 될 수 있다. 

예를 들어보자면, 설계가 주 업무인 제조업 회사가 있다고 치자. 자동차나 항공 산업 분야가 예가 될 수 있겠다. 이 산업도 역시 제조 원가가 중요하기 때문에 기본적인 부품 설계, CAD 작업 등에는 보다 저렴한 인건비를 가진 국가의 인력에게 일을 맡기는 경우가 많다. 이때 도면을 직접 메일로 주고 받아야 할지, 아니면 웹 하드 서비스를 사용해야 할지, 아니면 회사의 인증 디렉토리에 별도의 구성을 더한 뒤에 이러한 아웃소싱 인력들을 별도로 관리해야 할 지 등 고민을 한 뒤에, 아 그렇다 VDI 다 라고 판단 할 수 있겠다. 이러한 경우 AutoCAD 등이 설치된 가상 인스턴스를 작업자에게 사용하도록 하면, 적절한 통제를 통해 도면이 외부로 유출되거나 하는 사태를 방지 할 수 있다. 노동력은 사용하되, 산출물에 대한 열람과 작업은 통제되며, 작업자가 세계 어디에 위치하건 네트워크만 확보 된다면 업무를 볼 수 있다. 

가장 궁극적으로 이러한 요구사항을 충족하는데는, 적절한 가격을 가진 제품을 사다가 설치하면 된다. 그리고 지금까지는 이런 적절한 가격을 가진 제품이란 없었다. 따라서 뛰어난 기술팀이 없는 사업장이라면, 현명한 의사 결정 조직을 가지고 있었다면 구축을 미뤄왔을 것이다. 

오늘 간단하게 소개할 바로 이 Nutanix 가 그런 고민을 많이 해결 해 줄 수 있다. 고성능/고가용성과 구조적인 복잡함을 따로 배울 필요가 없는, 구글/Nicira 인력이 주축이 되어 만들어진 컴퓨트 클라우드 용 하드웨어이기 때문이다. 긴 말보다 아래의 영상을 살펴 보자. 

이게 대체 그래서 뭐야? 스토리지야 하이퍼바이저야? 하는 질문을 가질 수 있겠다. 이 제품은, VMware 와 스토리지가 결합된 어플라이언스라고 할 수 있다. 따라서 이 시스템을 사용하여 클라우드를 구축하고자 하는 경우, 서버+스토리지를 빼고 이 장비를 넣으면 된다는 말이 되겠다. 

간단하게 정리하면 다음과 같다. 

1. 기존의 서버 + 스토리지의 구성이 필요가 없다. 즉, EMC나 NetApp 같은 스토리지가 필요 없다. 

2. VMware 기반이며, 현재 KVM 버전도 준비 중이라고 한다. 따라서 vCenter 및 VMware 서버 제품을 그대로 사용한다. 

3. 스토리지의 클러스터링과 그 구현 방법이 매우 뛰어나다. 

4. VM 이 늘어남에 따라 보통 스토리지의 응답시간이 매우 지연되는데, 이 제품은 아무리 VM이 늘어나더라도 일정한 응답시간을 보여준다. 

5. 현재 VMware 에 흡수된 Nicira 를 사용 할 수 있도록 준비중이란다. 

따라서, 다음의 고객이라면 이 제품을 사용하는 것이 백번 낫다. 

1. 우리는 클라우드 구현 기술을 모른다. 

2. 우리는 클라우드 구현 기술을 알고 싶지도 않다. 

3. 구현과 기술은 모르지만 우리 회사 내부에 구축해서 사용하고 싶다. 

4. 향후 운영 (증설 / 교체 등 )이 복잡하지 않았으면 좋겠다. 

5. VMware + 서버 + 스토리지가 너무 비싼 것 같다. 

스토리지 구현과 하이퍼바이저와의 연동 등 이 제품은 결코 가볍게 볼 수 없는 스토리지 기술이 구현되어 있다. 이를테면 디스크 속도에 따른 tier 를 별도로 구성하여 hit ratio 가 높은 hot data 에 대해 보다 높은 성능을 제공한다던가, 클러스터링을 하되 가급적이면 로컬의 데이터를 최 우선으로 사용하는 형태로 복제 구성을 하는 것 등이 바로 그렇다. 이것들은 하루 아침에 뚝딱 만들어 낼 수 있는 것들이 분명히 아니며, 분명 현재 클라우드 구현에 있어 고민스러운 많은 것들에 대한 해결이 가능하다. 

아래는 이 제품의 스크린샷이다. 실제 사용 해 봤는데 꽤 쉽고, 직관적이다. 

나는 오픈소스 맹신론자는 아니다. 하지만 오픈소스는 정말 위대하다. 없는게 없다. 그래서 엄청나게 좋아하며, 적어도 내가 일하고 있는 분야에 있어서 필요해 보이는 것들, 사용해 보고 싶은 것들은 꼭 해 보는 편이다. 여기서 중요한 것은, 상용 제품과의 비교가 필요하다는 것이다. 이를테면 ArcSight 나 Splunk 와, syslog-ng , logstash 같은 것들 처럼. 이 제품의 경우에는, 그 핵심의 구성에 있어서는 KVM 또는 OSS Xen 그리고 pNFS 를 엮는 형태로 구성 할 수도 있다. 하지만 Nutanix 가 현재 지원하는 기능을 모두 제공하려면 많은 부분에 대한 수정이 필요하다.  

뛰어난 상용 제품은 그 기능이 확실히 동작하며 매우 직관적이지만, 오픈소스 몇개 엮어서 뚝딱 만들어 낼 수 있는 수준의 제품이 아닌 경우가 많이 있다. SDN 분야가 그렇고, 분산 스토리지 분야가 그렇다. 그 외에도 많이 있지만. 

Nutanix 를 굳이 오늘 포스팅 하는 이유는, 이 제품이 컴퓨팅 클라우드 구축을 위해서 충분히 고려될 만한 최초의, 그리고 현존하는 최고의 대안이 될 수 있기 때문이다. 지금까지 클라우드의 복잡성과 그 태생적 난해함으로 인해 접근해 볼 엄두가 나지 않았다거나 또는 아직 신뢰 할 만한 수준의 제품이 없다고 생각 했다면, 이 제품을 한번 확인해 보기 바란다. 

보다 많은 정보는 아래의 페이지에서 구할 수 있다. 

http://www.nutanix.com/

http://www.nutanix.com/resources.html

레퍼런스도 제법 있으므로, 관심이 있다면 확인 해 보도록. 

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

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

최근들어 다양한 주제로 블로그에 찾아오시는 분들이 제법 있음에도 불구하고 한동안 블로그를 처박아두다시피 했는데, 오늘 파이어준의 포스팅을 보니 웬지 간만에 블로깅 의욕이 불끈 솟아 내일 출장을 위해 일찍 일어나야 함에도 불구하고 간단하게나마 포스팅이 필요 할 것 같아 몇자 적어본다. 

회사 대표님의 "드랍박스 비슷한 서비스를 Openstack Swift 기반으로 만들어 보자" 라는 심플하고도 아리송한 제안으로 시작된 이 프로젝트는, 기업 고객을 대상으로 클라우드 인프라 기반의 컨텐츠 공유 및 저장을 목적으로 하고 있다. Velox 라는 이름은 원래 프로젝트 코드명이었는데, 어차피 기업용 제품이고 해서 다른 이름을 아무리 가져다 붙여도 팀 구성원 그 누구도 기타등등의 서비스 이름에 동조를 해 주지 않아 서비스 이름으로 굳어지는 분위기이다. ( 이미 인증서 구매까지 완료 했으니 어쩌랴! ) 검색해 보시면 알겠지만, Velox 는 Swift 의 그리스 ( 라틴어 였던가 ) 단어다. 

이 Openstack 의 Swift 인프라는 이미 국내 굴지의 ISP 를 위해 진행되었던 스토리지 클라우드의 제품으로 인프라의 설계와 트러블슈팅 등에 참여했던 이력이 있어 그 동작에 대해서는 다른 분들보다 조금 먼저 서비스 레벨로서의 접근이 가능했었다. 이 오픈소스 인프라가 가지고 있는 한계라던가 운영상의 주요 포인트, 그리고 확장을 위한 네트워크 아키텍쳐와 성능 향상을 위해서 어떤 부분을 조율 해야 하는지 등을 신경써서 디자인 할 필요가 있었다. 물론 지금 이 제품은 개발 및 스테이징 단계기 때문에 그 인프라 구성이 매우 간단하지만, 그 확장 모델에 대해서는 이미 기업환경을 위해 플랜이 짜여 있으므로 향후 사이징이나 성능에 문제가 없겠다. 

이 프로젝트는 사실 제대로 스프린트를 한 것이 5개월 남짓 되는데, 전체 플로우는 다음과 같았다. 

1. 인력 구성- 토탈 3명 : 파이어준 ( aka 경준호 ), 임성렬 ( backend ), 나 ( 인프라 ). 

2. Swift - Keystone 및 Reverse - proxy 등의 설치 / 협업 도구 redmine 및 github 등의 리소스 준비 

3. Swift 클러스터를 위한 자동화 스크립트와 Chef 를 통한 코드 구현 

4. 구현된 인프라를 개발팀에 인계, 개발팀 요구사항을 인프라에 즉시 반영 

5. 기업 관계자들로 부터의 feedback 수렴 및 기능 추가, 반영 

6. 테스트 프로젝트 기획, 실행 중. 

각 단계별로 난관이 있었는데, 이는 비단 개발 및 인프라 설계 및 설치 뿐만 아니라 인력등과 관계된 부분들이 제법 많았다. 

제품의 스크린샷은 준호형이 워낙 잘 떠놨기 때문에 준호형의 포스트를 링크한다. 여기 를 참조하시면 되겠다. 

이 프로젝트는 완벽한 오픈소스 기반 솔루션들의 조합으로 이루어졌으며, 하드웨어 역시 Commodity 라 할 수 있는 하드웨어들 기반으로 동작한다. 네트워킹에는 현재 10g 가 사용되었지만, Swift 아키텍처는 특정 부분을 제외하고는 대부분 1G 네트워크를 사용하는 것이 가능하다. 또한 밸런싱 및 프락싱, 그리고 SSL Endpoint 에는 상용 밸런서나 하드웨어 기반의 L7 장비들이 전혀 사용되지 않았다. 따라서 이는 기업의 요구에 따라 5T 부터 수십 Peta 까지 확장이 가능하며, 구조적인 팁을 더한다면 거의 무한대에 가까운 Zeta 레벨로까지의 확장이 가능하다. 인증은 기업의 AD 나 LDAP 등과도 연동이 가능하며, 이런 인증 시스템이 없어 별도로 필요하다면 따로이 데이터베이스를 사용하여 운용 할 수도 있다.  

이 포스팅에서는 기술적으로 세부사항이 어떻게 되고 하는 것을 설명하기 보다는, 팀원 세명이 마치 Garage 에서 컴퓨터 놓고 개발하여 1.0 을 만들어 내는 과정을 경험 해 본 것이 가장 의미 깊었던 일임을 알리고 싶다. 서로 다른 전문 분야를 가진 사람들이 소수의 인원으로 팀으로서 구성되어 빠른 의사결정 과정과 최대한 저렴한 비용 소비를 통해 제품을 만들어 내는 과정은 돌이켜 보면 난점도 꽤 있었지만 결과물을 어느정도 만들어 낸 지금 굉장히 고무적이다. 

Nutanix 와 같은 제품을 만드는 것은 엔지니어링 적으로 굉장히 높은 수준의 사람들이 뭉쳐야 가능 한 것이지만, 우리는 시장에 필요할 것같은 제품을 최대한 빠른 속도로 사용 가능한 버전으로 만들어 내는 것에 중점을 두고 있었기 때문에 기술적 깊이는 다소 낮을 수 있겠다. 하지만 Node.js 에서의 쉽지 않은 바이너리 처리와, 이를 인프라에서 솔루션을 내어 어플리케이션 또는 프레임웍 자체가 가지고 있는 문제를 우회하도록 하는 솔루션을 만들어 내는 것은 어플리케이션과 인프라를 뗄레야 뗄 수 없는 관계로 만들어 냄으로서 보다 의미있는 작업이 된 것 같다. 이를 테면, 기존에는 아파치 설정은 아파치 대로 돌지만 어플리케이션과는 상관 없는 형태였다면, 이 제품은 인프라의 설정 파일마저 github 에 등록해야 할 정도로 그 긴밀성이 대단하다. 일례로 url 라우팅과 같은 부분을 SSL Endpoint 와 함께 처리하는 것은 프락싱 해 줘야 하는 어플리케이션의 부담을 낮춤과 동시에, 개발자들이 별도로 크게 노력하지 않아도 분산구조를 취할 수 있도록 해 주는 것과 같은 것이다. 

백엔드와 프론트엔드의 롤 간에 다양한 이야기들이 있지만, 여기에 인프라까지 끼는 이야기는 많지 않을 것이다. 이 제품이 얼마나 크게 빛을 발할 지 모르겠지만, 지금까지의 작업은 그 어디에서도 경험 해 보지 못한 귀중한 것이며, 개발을 위한 팀이 어떠한 모습이어야 하는지를 배우게 해 준 동료들에게 매우 감사한다. 

이제 막 알파 정도의 서비스이며, 지금 굴리고 있는 인프라도 조촐하지만 기업 환경을 위해서는 얼마든지 확장 가능한 준비가 되어 있기 때문에 현재 인프라와 어플리케이션의 한계를 보는것이 주요하겠다. 

마지막으로, 이런 업무환경이 가능하도록 도움을 주신 지금 회사의 대표님과 이 회사에 입사 하여 각종 대형 클라우드 서비스 구현에 핵심에 서 있도록 해 주었던 Nicholas S. Lee, 그리고 장비를 준비 해 준 재성형에게도 감사한다. 

제품 컨셉과 스크린샷 등의 확인은 파이어준의 블로그에서. 

그리고 성렬형 결혼 축하!! 

덧.)  splunk 는 매우 획기적인 로그 수집, 검색 도구다. 로그가 쌓이는 양이 그다지 많지 않다면 사용해 볼 만 하다. 다만, 특정 사이징이 넘어가게 되면 비용을 지불해야 하므로 주의 할 것. 한가지 더, 데모 기간이 지나면 계정 관리가 되지 않는다. 이 말은, 바로 그냥 로그인 되어 버리므로 인터넷에서 접근 가능하도록 구성하였다면 반드시 패스워드 등을 걸어 둘 것. 

아이피들이 나와 있기는 한데 뭐 별일 있겠나 싶어서 그냥 올린다.

덧2.) 로그 서버가 없거나 빈약하다면 다음의 서비스를 알아 보는 것도 좋다. 

http://www.sumologic.com/ 

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

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

클라우드에는 참 많은 종류의 네트워크가 필요한데, 바로 이 부분을 보다 단순화 할 수 없을까 하는 생각에 몇가지 테스트를 진행하던 중 블로그에 Quagga 를 검색어로 유입되는 경우가 꽤 있어 얼마전 진행했던 테스트의 내용을 간추려 올린다. 

오늘도 역시 발로 그림이 먼저 등장한다. 

Quagga with BGP

실제 구성은 각 ToR 이 8회선의 multi-path 를 가지는 것이었지만, 단순화를 위해 살짝 변경 했다. 맨 위의 박스는 우분투 서버이며, 인터넷으로의 업링크 회선은 일반 UTP 로, 172.16.1.250/24 에 게이트웨이는 172.16.1.1, 인터페이스는 eth0 이다. 

다운링크는 Intel 10G Dual port 로, Arista 7124SX 의 24번 포트에 TwinAx 케이블로 연결되어있다. 망은 30 bitmask 를 가지며, 이 구간에는 eBGP 를 사용하였다. 

Aggregation <---> ToR 에는 각 2회선이 사용되었으며, 모두 10G 연결이다. 역시 각 회선마다 30 bitmask 의 네트워크 구성이 되어 있으며, ECMP 가 적용되어 있다. (LACP 가 아님에 주의) AGGR 측에서는 1번 포트부터 순차적으로 2포트씩 다운링크에 사용한다. 

ToR 스위치는 업링크에 23,24번 포트를 사용하며, 1번부터 22번 포트까지는 Vlan 10 으로, 랙에 설치된 서버의 연결에 사용한다. 서버는 ToR 스위치를 게이트웨이 인터페이스로 가지지만, ToR 스위치는 Aggregation 스위치와 iBGP 로 연결 되어 있다. 

이와 같은 구성에서, 서버의 Quagga 설정은 zebra 와 bgpd 만을 사용하도록 하며, 설정은 다음과 같다. 

# /etc/quagga/daemons
# This file tells the quagga package which daemons to start.
#
# Entries are in the format: =(yes|no|priority)
#   0, "no"  = disabled
#   1, "yes" = highest priority
#   2 .. 10  = lower priorities
# Read /usr/share/doc/quagga/README.Debian for details.
#
# Sample configurations for these daemons can be found in
# /usr/share/doc/quagga/examples/.
#
# ATTENTION: 
#
# When activation a daemon at the first time, a config file, even if it is
# empty, has to be present *and* be owned by the user and group "quagga", else
# the daemon will not be started by /etc/init.d/quagga. The permissions should
# be u=rw,g=r,o=.
# When using "vtysh" such a config file is also needed. It should be owned by
# group "quaggavty" and set to ug=rw,o= though. Check /etc/pam.d/quagga, too.
#
zebra=yes
bgpd=yes
ospfd=no
ospf6d=no
ripd=no
ripngd=no
isisd=no

/etc/quagga/daemons 는 어떤 프로토콜을 사용 할 지를 정해주는 설정 파일이다. 

이후 모든 Quagga 설정 파일은 한번에 나오므로, 각 섹션의 주석 처리된 파일 이름으로 구분해서 참고 하도록 하자. 

# /etc/quagga/vtysh.conf
!
!
! service integrated-vtysh-config
!
hostname Ubuntubox
username root nopassword
!
!

# /etc/quagga/zebra.conf
!
hostname quagga
!
interface eth0
ip address 172.16.1.250/24
!
interface lo
!
interface eth2
ip address 10.254.1.254/30
!
ip forwarding
!
ip route 0.0.0.0/0 172.16.1.1
!
line vty
!  

# /etc/quagga/bgpd.conf
!
router bgp 60001
  bgp router-id 172.16.1.250
  network 0.0.0.0/0
  neighbor downstream peer-group
  neighbor downstream remote-as 60000
  neighbor downstream ebgp-multihop 10
  neighbor 10.254.1.253 peer-group downstream
  neighbor 10.254.1.253 update-source eth2
  no auto-summary
!

이제, 이 서버와 연결되는 AGGR 스위치의 config. 

# AGGR config
! device: 10G-AGGR-01 (DCS-7124SX, EOS-4.9.0-590041.EOS490RibPimFix (engineering build))
!
! boot system flash:/EOS-4.9.0-EFT2.swi
!
terminal length 30
!
hostname 10G-AGGR-01
!
spanning-tree mode mstp
!
no aaa root
!
username admin secret 5 heymannodbodygivesashitaboutwhatyouaredoing
!
interface Ethernet1
   no switchport
   ip address 10.1.1.1/30
!
interface Ethernet2
   no switchport
   ip address 10.1.1.5/30
!
interface Ethernet3
   no switchport
   ip address 10.1.2.1/30
!
interface Ethernet4
   no switchport
   ip address 10.1.2.5/30
!
interface Ethernet5
!
interface Ethernet6
!
interface Ethernet7
!
interface Ethernet8
!
interface Ethernet9
!
interface Ethernet10
!
interface Ethernet11
!
interface Ethernet12
!
interface Ethernet13
!
interface Ethernet14
!
interface Ethernet15
!
interface Ethernet16
!
interface Ethernet17
!
interface Ethernet18
!
interface Ethernet19
!
interface Ethernet20
!
interface Ethernet21
!
interface Ethernet22
!
interface Ethernet23
!
interface Ethernet24
   no switchport
   ip address 10.254.1.253/30
!
interface Management1
   ip address 192.168.1.201/24
!
ip routing
!
router bgp 60000
   bgp log-neighbor-changes
   timers bgp 1 3
   maximum-paths 16
   neighbor 10.1.1.2 remote-as 60000
   neighbor 10.1.1.2 update-source Ethernet1
   neighbor 10.1.1.2 next-hop-self
   neighbor 10.1.1.2 maximum-routes 12000 
   neighbor 10.1.1.6 remote-as 60000
   neighbor 10.1.1.6 update-source Ethernet2
   neighbor 10.1.1.6 next-hop-self
   neighbor 10.1.1.6 maximum-routes 12000 
   neighbor 10.1.2.2 remote-as 60000
   neighbor 10.1.2.2 update-source Ethernet3
   neighbor 10.1.2.2 next-hop-self
   neighbor 10.1.2.2 maximum-routes 12000 
   neighbor 10.1.2.6 remote-as 60000
   neighbor 10.1.2.6 update-source Ethernet4
   neighbor 10.1.2.6 next-hop-self
   neighbor 10.1.2.6 maximum-routes 12000 
   neighbor 10.254.1.254 remote-as 60001
   neighbor 10.254.1.254 ebgp-multihop 2
   neighbor 10.254.1.254 maximum-routes 12000 
   redistribute connected
!
!
end

각 ToR 설정. 

### ToR #1 
! device: 10G-TOR-01 (DCS-7124S, EOS-4.9.0-590041.EOS490RibPimFix (engineering build))
!
! boot system flash:/EOS-4.9.0-EFT2.swi
!
terminal length 30
!
logging host 192.168.17.201
logging facility local0
!
hostname 10G-TOR-01
!
spanning-tree mode mstp
!
no aaa root
!
username admin secret 5 whogivesashit
!
vlan 10
!
interface Ethernet1
   switchport access vlan 10
!
interface Ethernet2
   switchport access vlan 10
!
interface Ethernet3
   switchport access vlan 10
!
interface Ethernet4
   switchport access vlan 10
!
interface Ethernet5
   switchport access vlan 10
!
interface Ethernet6
   switchport access vlan 10
!
interface Ethernet7
   switchport access vlan 10
!
interface Ethernet8
   switchport access vlan 10
!
interface Ethernet9
   switchport access vlan 10
!
interface Ethernet10
   switchport access vlan 10
!
interface Ethernet11
   switchport access vlan 10
!
interface Ethernet12
   switchport access vlan 10
!
interface Ethernet13
   switchport access vlan 10
!
interface Ethernet14
   switchport access vlan 10
!
interface Ethernet15
   switchport access vlan 10
!
interface Ethernet16
   switchport access vlan 10
!
interface Ethernet17
   switchport access vlan 10
!
interface Ethernet18
   switchport access vlan 10
!
interface Ethernet19
   switchport access vlan 10
!
interface Ethernet20
   switchport access vlan 10
!
interface Ethernet21
   switchport access vlan 10
!
interface Ethernet22
   switchport access vlan 10
!
interface Ethernet23
   no switchport
   ip address 10.1.1.2/30
!
interface Ethernet24
   no switchport
   ip address 10.1.1.6/30
!
interface Management1
   ip address 192.168.1.203/24
!
interface Management2
!
interface Vlan10
   mtu 9212
   ip address 10.0.1.254/24
!
ip routing
!
router bgp 60000
   bgp log-neighbor-changes
   timers bgp 1 3
   maximum-paths 8 ecmp 8
   neighbor 10.1.1.1 remote-as 60000
   neighbor 10.1.1.1 export-localpref 70
   neighbor 10.1.1.1 maximum-routes 12000 
   neighbor 10.1.1.5 remote-as 60000
   neighbor 10.1.1.5 export-localpref 70
   neighbor 10.1.1.5 maximum-routes 12000 
   network 10.0.1.0/24
!
management telnet
   no shutdown
!
!
end

#### ToR 2

! device: 10G-TOR-02 (DCS-7124SX, EOS-4.9.0-590041.EOS490RibPimFix (engineering build))
!
! boot system flash:/EOS-4.9.0-EFT2.swi
!
terminal length 30
!
hostname 10G-TOR-02
!
spanning-tree mode mstp
!
no aaa root
!
username admin secret 5 whogivesashit
!
vlan 10
!
interface Ethernet1
   switchport access vlan 10
!
interface Ethernet2
   switchport access vlan 10
!
interface Ethernet3
   switchport access vlan 10
!
interface Ethernet4
   switchport access vlan 10
!
interface Ethernet5
   switchport access vlan 10
!
interface Ethernet6
   switchport access vlan 10
!
interface Ethernet7
   switchport access vlan 10
!
interface Ethernet8
   switchport access vlan 10
!
interface Ethernet9
   switchport access vlan 10
!
interface Ethernet10
   switchport access vlan 10
!
interface Ethernet11
   switchport access vlan 10
!
interface Ethernet12
   switchport access vlan 10
!
interface Ethernet13
   switchport access vlan 10
!
interface Ethernet14
   switchport access vlan 10
!
interface Ethernet15
   switchport access vlan 10
!
interface Ethernet16
   switchport access vlan 10
!
interface Ethernet17
   switchport access vlan 10
!
interface Ethernet18
   switchport access vlan 10
!
interface Ethernet19
   switchport access vlan 10
!
interface Ethernet20
   switchport access vlan 10
!
interface Ethernet21
   switchport access vlan 10
!
interface Ethernet22
   switchport access vlan 10
!
interface Ethernet23
   no switchport
   ip address 10.1.2.2/30
!
interface Ethernet24
   no switchport
   ip address 10.1.2.6/30
!
interface Management1
   ip address 192.168.1.204/24
!
interface Vlan10
   ip address 10.0.2.254/24
!
ip routing
!
router bgp 60000
   bgp log-neighbor-changes
   timers bgp 1 3
   maximum-paths 8 ecmp 8
   neighbor 10.1.2.1 remote-as 60000
   neighbor 10.1.2.1 export-localpref 70
   neighbor 10.1.2.1 maximum-routes 12000 
   neighbor 10.1.2.5 remote-as 60000
   neighbor 10.1.2.5 export-localpref 70
   neighbor 10.1.2.5 maximum-routes 12000 
   network 10.0.2.0/24
!
management telnet
   no shutdown
!
!
end

아마 스위치 설정에는 더 필요한게 있거나 빼야 할 것이 있을 수 있다. 스스로 네트워크 전문가는 절대 아니라고 생각하고 있으므로, 무언가 더 필요한게 있다고 생각 되시면 조언을 주시면 좋겠다. 

일단 이와 같이 구성된 설정에서, 제대로 통신이 되는지 설정을 확인. 

먼저 서버. Quagga 가 설치된 이후에는 일반 스위치 설정과 같은 CLI 인터페이스를 vtysh 를 통해 진입이 가능하다. 

root@yjjeong:/etc/quagga# vtysh
END # <-- type 'q'
Quagga# sh run
hostname qugga
hostname External01
!
interface eth0
 ip address 172.16.1.250/24
 ipv6 nd suppress-ra
!
interface eth1
 ip address 192.168.1.201/24
 ipv6 nd suppress-ra
!
interface eth2
 ip address 10.254.1.254/30
 ipv6 nd suppress-ra
!
interface eth3
 ip address 10.254.2.254/30
 ipv6 nd suppress-ra
!
interface lo
!
router bgp 60001
 bgp router-id 172.16.1.250
 network 0.0.0.0/0
 neighbor downstream peer-group
 neighbor downstream remote-as 60000
 neighbor downstream ebgp-multihop 10
 neighbor 10.254.1.253 peer-group downstream
 neighbor 10.254.1.253 update-source eth2
 neighbor 10.254.2.254 peer-group downstream
 neighbor 10.254.2.254 update-source eth3
!
ip route 0.0.0.0/0 172.16.1.1
!
ip forwarding
!
line vty
!
end

Quagga# sh ip bgp 
BGP table version is 0, local router ID is 172.16.1.250
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, R Removed
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 0.0.0.0          0.0.0.0                  0         32768 i
*> 10.0.1.0/24      10.254.1.253                           0 60000 i
*> 10.1.1.0/30      10.254.1.253                           0 60000 i
*> 10.1.2.0/30      10.254.1.253                           0 60000 i
*> 10.254.1.252/30  10.254.1.253                           0 60000 i

Total number of prefixes 5
Quagga# sh ip route
Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF,
       I - ISIS, B - BGP, > - selected route, * - FIB route

S   0.0.0.0/0 [1/0] via 172.16.1.1, eth0
K>* 0.0.0.0/0 via 172.16.1.1, eth0
B>* 10.0.1.0/24 [20/0] via 10.254.1.253, eth2, 02w0d00h
B>* 10.1.1.0/30 [20/0] via 10.254.1.253, eth2, 02w0d00h
B>* 10.1.2.0/30 [20/0] via 10.254.1.253, eth2, 02w0d00h
B   10.254.1.252/30 [20/0] via 10.254.1.253 inactive, 02w0d00h
C>* 10.254.1.252/30 is directly connected, eth2
C>* 127.0.0.0/8 is directly connected, lo
C>* 172.16.1.0/24 is directly connected, eth0
Quagga# sh ip bgp 
Quagga# ping 10.1.2.1
PING 10.1.2.1 (10.1.2.1) 56(84) bytes of data.
64 bytes from 10.1.2.1: icmp_req=1 ttl=64 time=0.161 ms
64 bytes from 10.1.2.1: icmp_req=2 ttl=64 time=0.115 ms
64 bytes from 10.1.2.1: icmp_req=3 ttl=64 time=0.122 ms
64 bytes from 10.1.2.1: icmp_req=4 ttl=64 time=0.120 ms
64 bytes from 10.1.2.1: icmp_req=5 ttl=64 time=0.114 ms
64 bytes from 10.1.2.1: icmp_req=6 ttl=64 time=0.114 ms
^C
--- 10.1.2.1 ping statistics ---
6 packets transmitted, 6 received, 0% packet loss, time 4998ms
rtt min/avg/max/mdev = 0.114/0.124/0.161/0.019 ms
Quagga# ping 10.1.1.2
PING 10.1.1.2 (10.1.1.2) 56(84) bytes of data.
64 bytes from 10.1.1.2: icmp_req=1 ttl=63 time=0.181 ms
64 bytes from 10.1.1.2: icmp_req=2 ttl=63 time=0.161 ms
^C
--- 10.1.1.2 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 999ms
rtt min/avg/max/mdev = 0.161/0.171/0.181/0.010 ms
Quagga# quit

다이어그램 제일 하단의 각 서버들에서도 이상 없이 우분투 서버로의 통신이 가능했다. 만약 여기서 사설네트워크에 대한 인터넷을 제공하고자 한다면, 다음의 iptables 로 SNAT 을 지정해 준다. 

root@yjjeong:/etc/quagga# iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Quagga 의 BGP 는 아직 ECMP 를 지원하고 있지 않다. 따라서, 만약 서버에서의 ECMP 가 필요하다면 OSPF 를 사용하는 것이 나을 수도 있다. 단순하게 ECMP 의 기능이 필요해서인 것 뿐 아니라, 내부의 네트워크에도 iBGP 대신 OSPF 를 사용하는 것이 보다 효율적일지도 모르겠다. 다만, 랙의 숫자, 즉 ToR 스위치와 이에 따른 하위 네트워크의 숫자가 늘어나는 경우, 라우팅 테이블이 너무 많아지지 않도록 처리하는 방법이 가장 좋지 않겠나 싶다. 

위의 구성은 단순 AGGR - ToR 이지만, Distributed-Core 라 부르는, 다중의 Core - AGGR - Leaf (ToR) 의 구성으로도 쉽게 확장이 가능 할 것임을 알 수 있겠다. 아마도 확장은 아래 비슷한 모델? 

Distributed core architecture

더 좋은 의견이나 테스트 해 볼 사항에 대해 의견이 있다면 얼마든 환영! 

2박 3일 회사에서 신세지고 17시간 잤더니 웬지 개운한 하루. 

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