System Compleat.

Node.js dev on Cloud9 + Heroku

Techs

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


최근에는 클라우드를 사용한 온라인 개발 도구가 늘어나고 있다. 이미 좀 오래 되었지만 github 라던가, Cloud9IDE, 그리고 최근 firejune 에 의해 커스터마이즈된 JSbin 과 같은 도구들은 클라우드의 기능성과 더불어 언제 어디서나 개발이 가능한 환경을 만들어 주고 있다. 


국내 클라우드 업체들에서는 모두 아마존 꽁무니 쫒아 가느라 가랑이가 찢어지는 사이에, 이러한 도구들은 개발자들에게 가뭄의 단비와 같은 솔루션이 되고 있지 않나 싶다. 기실 조금만 생각 해 보면 서비스로서의 가치가 충분한데도, 아마존은 쫒아가려 하면서 구글은 쫒지 않는, 즉 바꿔 말하면 호스팅 서비스 그 이상의 무엇이 없지 않나 생각 해 볼 일이다. 


호스팅 서비스 역시 지난날의 웹 콘솔을 통한 관리를 넘어, 이제 oAuth 나 OpenID 등을 통한 인증, 그리고 이 인증을 바탕으로 한 API 의 지원이 필수적인 요소가 되어가고 있다. 클라우드로 만드는 서비스를 이제 서비스 업체의 웹 브라우저 콘솔만으로 제어하는 것은 이제 바가지에 밥떠먹는 것과 같은 시대가 되어 버렸다. 


오늘 소개할  Heroku, 그리고 Joyent 와 같은 클라우드 기반 호스팅은 사용자가 서버를 설정 할 필요 없이, 제공되는 클라이언트 도구 또는 다른 서비스와의 연동을 통해 온라인으로 언제 어디에서나 코드를 작성하고, 이를 배포하여 서비스 동작 여부의 확인이 가능하다. 따라서, 기존 node.js 또는 기타 여러가지의 서비스를 온라인에서 사용하려는 경우, 서버를 설치하고, 코드 저장소를 설정하는 등의 노력 없이 그저 서비스에 로그인하고, 사용하다가 일정 수준 이상의 사용량이 되면 금액을 지불하면 된다. 


사실 개발자에게 개발이 가능한 전체 환경의 설정은 매우 피곤한 일이 아닐 수 없다. 물론 내가 개발자는 아니지만, 대다수의 많은 개발자 분들이 환경 설정하는데 꽤 애를 먹으며, 이게 코드가 문제인지 인프라가 문제인지 알쏭달쏭한 경우에 빠지는 경우도 많다고 생각한다. 이러한 난제를 해결하는데 클라우드만큼 좋은게 없으며, 사용자 또는 개발자는 그저 서비스 신청, 개발환경 접근, 배포의 과정을 아주 쉽게 처리 할 수 있어 개발에만 전념 할 수 있도록 도와준다. 


오늘 소개할 조합은 바로 온라인 개발도구 Cloud9IDE ( http://c9.io ) 와 일종의 PaaS 서비스 Heroku ( http://www.heroku.com )  이다. 일단 사용량이 많지 않은 경우에는 무료로 사용 할 수 있으며, 처음 가입시 별도의 카드 정보와 같은 결재 정보도 필요 없다. 환경을 설정 해 보고, 코드를 개발 하면서 개발 된 코드가 정상적으로 동작 하는지 확인 하는데 사용하면 좋을 것 같다는 생각에 포스팅 해 본다. 물론, 이미 알고 계신 분들도 많겠지만. 


먼저, Heroku 에 가입한다. 가입 절차는 매우 간단하며, 메일 주소와 비밀번호 정도만 입력 하면 된다. 홈페이지에 접근하면 한 가운데 떵그머니 있는 Sign Up 버튼을 이용하자. 가입이 완료되면 로컬 머신에서의 환경 설정이 나타나는데, 이건 필요하면 하고 Cloud9 의 서비스와 연동할 거라면 굳이 하지 않아도 된다. 개발자에게는 골치 아픈 일일 뿐이다. 


가입을 완료 했으면 일단 두고, 이제 Cloud9IDE 에 가입하자. 역시 동일하게 계정을 생성하고, 로그인 후에 대시보드를 통해 프로젝트를 생성해 본다. 프로젝트를 생성했으면 "Start Edit" 을 살포시 눌러 실제 코드의 작성이 가능한 브라우저로 이동한다. 


이제, 아래와 같은 화면을 볼 수 있다. 



Cloud9IDE Project Page


화면 구성을 보면 일반적인 IDE 환경과 크게 다르지 않다. 가장 왼쪽에는 파일 브라우저, 배포, 설정, 테스트 등의 기능의 선택이 가능하고, 나머지는 온라인 코드를 수정하기 위한 공간이다. 새로운 파일은 왼쪽 상단의 파일 메뉴에서 생성이 가능하며, 원하는 경우 각종 코드 템플릿을 선택하여 사용 할 수도 있다. 생성된 코드는 일반적인 에디터의 저장 단축키와 같은 Cntl+s, 맥에서는 command+s 로도 잘 동작한다. 


여기까지는 일반 개발환경의 설정이며, 이제 Heroku 서비스로의 연결이 가능하다. 먼저, 왼쪽 기구 모양의 Deploy 버튼을 누른다. 

파일 브라우저의 모양이 바뀌면서, 상단에 -, + 버튼이 생긴다. 여기에서 + 버튼을 눌러 보면 다음과 같은 화면을 볼 수 있다. 



C9IDE, Select deploy site


위의 버튼을 눌러보면, Cloud9 이 지원하는 클라우드 기반 서비스를 확인 할 수 있다. 다른것은 모르겠는데, Windows Azure 를 지원한다. 이는 곧, 기존의 닷넷 개발자 분들도 git, Azure 에 대한 가벼운 이해만 있다면 C# 코딩을 그대로 하실 수 있다는 말이 되겠다. 아직 안해봐서 나는 모르겠지만, 아무튼 지금의 목적은 Heroku 로의 연결이므로, heroku 를 선택하고 아까 만들었던 Heroku 의 계정을 입력한다. 그리고 오른편의 Create New 버튼을 누르면, heroku 로 부터 코드 배포에 사용할 인스턴스를 만들 수 있다. 원하는 이름을 주고 하나 만들어 두자. 


생성을 완료하고 페이지에서 나오면, 이제 Deploy 탭에 Heroku 에서 생성한 인스턴스의 이름이 나타나는 것을 볼 수 있다. 이 인스턴스 이름을 클릭하면, 배포가 가능하다. 하지만 아직 배포할 코드가 아무것도 없으므로, 하나 작성해 보도록 하자. 



코드를 작성하기 전에, 다음과 같은 주요 내용을 이해해야 한다. 


1. Heroku 는 git 를 사용하여 동작한다. 코드를 생성하고, git push heroku master 와 같은 방법으로 동작하지만, Cloud9 에서는 그런 별도의 과정 없이 Cloud9 의 로컬 저장소에 commit 한 후에 인스턴스에 Deploy 하면 쉽게 적용 된다. 


2. Heroku 에서 Node.js 를 동작하기 위해서는 필요한 패키지, 실행 할 인스턴스의 수량 또는 종류 등을 지정해야 한다. 이는 Heroku 의 문서에 잘 나와 있으므로 여기를 참조 하도록 한다. 

https://devcenter.heroku.com/articles/nodejs


3. 기본적으로 Node.js 의 동작에 대해 이해하고 있어야 Heroku 를 손쉽게 사용 할 수 있다. 



Cloud9IDE 의 왼족 상단의 Project Files 를 클릭하고, 신규 파일을 다음과 같이 저장하자. 


파일: .gitignore 

 node_modules



package.json

{
    "name": "node-example",
    "version": "0.0.1",
    "engines": {
        "node": "0.6.15",
        "npm": "1.1.9"
    },
    "dependencies": {
        "express": "2.5.9"
    }
}


Procfile

 web: node web.js


web.js

var express = require("express");

var app = express.createServer(express.logger());

app.get('/', function(request, response) {
    response.send('Hello Firejune!');
});

var port = process.env.PORT || 3000;
app.listen(port, function() {
    console.log("Listening on " + port); 
});


대충 보면 감이 잡힐지도 모르겠다. 

.gitignore 는 git 로 작업할때 무시할 디렉토리이다. 여기에 node_modules 가 지정된 것은 node_modules 디렉토리를 heroku 에 업로드 하지 않아도 되기 때문이다. 업로드 하지 않아도 되는 이유는 바로 package.json 에서 필요한 패키지를 명시하였기 때문이며, 여기에 필요한 패키지 리스트를 잘 지정하였다면 별 문제 없다. 물론 여기서 애플리케이션 동작에 필요한 각종 모듈 및 node, npm 의 버전 명시가 가능하다. 사용 가능한 버전은 Heroku 페이지를 통해 공개되고 있으니 구글링을 통해 참고 하면 된다. 사용 방법은 위에 명시된 것과 같다.  Procfile 은 Heroku 에서 구동할 애플리케이션의 용도와 파일을 지정한다. 마지막으로 web.js 는 실제 node.js 를 사용하여 작성한 코드가 된다. 


Cloud9IDE 의 아랫쪽을 보면, console 이 있다. 이는 각종 커맨드의 사용을 위해 존재하는데, 여기서 우리는 npm 으로 필요한 모듈의 설치가 가능하다. 위의 예제는 heroku 로 부터 제공된 것으로서, express 모듈을 사용하고 있다. 따라서 이 콘솔에 다음과 같이 입력한다. 


npm install express@2.9.5


이후 설치 메세지가 나타나는 것을 확인 할 수 있으며, 만약 현재 Cloud9IDE 의 버전과 맞지 않는다면 npm info 등을 통해 적절한 버전으로 변경 해 주면 된다. 


이제, 작성한 코드가 잘 동작하는지 확인 할 필요가 있다. Cloud9IDE 의 아랫편에 보면 Console 이 있는데, 여기에 커맨드를 입력하여 원하는 작업을 할 수 있다. 다른건 됬고, git 관련 커맨드만 넣도록 한다. 


git init
git add .
git commit -m "First commit for Heroku"


모두 다 실행이 완료 되었다면, 다시 제일 왼편의 Deploy 를 클릭한다. 생성된 애플리케이션 인스턴스를 클릭하면 Deploy 버튼이 나타난다. 클릭하자. 


자, 그러면 이제 Cloud9IDE 의 로컬 repo 에서 Heroku 로 코드가 업로드 되고, 이후 애플리케이션이 준비되는 과정을 로그로 볼 수 있다. 정상적으로 잘 수행하였다면, 다음과 같은 화면을 볼 수 있을 것이다. 





제일 아래 나타난 링크를 클릭하면, 배포된 애플리케이션이 동작 하는지 아닌지를 잘 알 수 있다. 


만약 기존에 개발한 애플리케이션이 다른 버전의 node 와 npm 을 사용한다면, 아래의 링크를 통해 현재 Heroku 에서 지원하는 버전의 지정이 가능하다. 



node.js version manifest


npm version manifest



아마 클라우드라는 환경을 가장 생산적으로 사용이 가능한 사용자군은 개발자들일 것이다. 적절한 방법과 사용성만 있다면, 아이폰의 앱 결재 하듯 한달에 1~2 만원 지불하면서 본인의 자가 발전을 위해 사용해도 아깝지 않을 정도이다. 다만 Cloud9IDE 가 현재 국내에 서버가 없으므로 망의 영향을 받을 가능성이 충분하긴 하지만. 


이런 서비스를 만들어 내는것은 아무것도 아니다 라고 말하기는 좀 그렇지만, 그렇다고 엄청나게 어려운 것은 아니다. 원하는 기능을 적절히 믹스하고, 한번에 잘 동작하게 만든다면 쓸데없이 VM 생성해 두고 뭐할까 고민하는 일은 없을 것이다. 


국내의 각종 클라우드 서비스들도 미국에 비해 일반인의 클라우드에 대한 인식이 현저히 떨어지는 한국에서 매출이 안나온다고 고민하고 있을게 아니라, 위와 같은 서비스의 런칭이 필요하지 않나 생각 해 본다. 


아무튼 준호형과 관련된 재미진 프로젝트를 해 보면 어떨까 한다. 이와 비슷한, 그러나 뭔가 다른. 


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

저작자표시 비영리
,

Things about Openstack Swift implementation

Techs

( younjin.jeong@gmail.com, Younjin Jeong )


This is first time that writing blog post in English. There might be some wrong senses, so please read this post in favor. 


The Swift, from Openstack project, is one of the simplest storage cluster in the world. Like any other cloud solutions in nowadays, it's quite young project, and tries to follow Amazon service, which is called as "S3". The project is supported by vendors who wants to take lead in cloud market. It has a quite simple architecture to understand, easy to install and use. There's tons of blog posts about its benefits that you can find on internet, so I'll not explain those things on this. 


What I want to mention about Swift is, it looks easy to build up, but it isn't for enterprise service in my personal opinion. I've been worked for this storage cloud from early of last year for KT, and some other companies in Korea. Actually, the Swift system for KT is built by Cloudscaling, and I've been worked for it's hardware issue support first. After then, I wrote some automation codes for it with chef, and it's working on some services. So, I think I can speak something about its infrastructure, and it may helps your concern about how to build Swift infrastructure. 


In perspective of infrastructure, it has to be scaled-out as maximum as it can. That means, the network has to be designed for it. Not only for the network, we have to consider about commodity also. More important fact is, scale-out does not mean high performance every time. Here's the key factors to consider when we build Swift cluster. 


a. Low SSL performance of Swift proxy. 

b. Network design - Management, Service, and Storage. 

c. Number of disks per processor.  

d. Spec of each nodes. Network, CPU, memory, network. 

e. How to balance the load. 

f. Number of zone ( it's different with compute cluster ) 

g. Account, Container service load. 

f. Automation 

...and more and more.. 


To be honest, it's not easy  to archive all of those things yet. because there's many things are not proved yet. And those factors cloud be differentiated by service use cases. In other words, most factors shown are depends on type of services, because the most basic performance is based on disk I/O. So, if we are building this Swift cluster for A service, not for public such like Amazon's S3, then we can aim it's best performance architecture by type of service. I might can say, it can be adjusted by number of disks per processor. If the service is used for larger objects, then we can put more disks per processor. If not, then we can reduce the number of disks per processor, and can see how it effects to the performance. One another way to improve disk performance in Swift is, using Raid controller which has Cache memory for write back and BBU for maintain cache information. Basically, Swift recommends to do not use Raided volumes, so you might have some curiosity for this mention. The way to implement this, make every single disk as Raid 0, and creates volumes on it. So, if you have 12 disks on storage node, then you have to build each one as Raid 0, then you'll have 12 Raid 0 volumes which is not stripped. The reason why using this is, to use "write back" function. If we use this way, then a storage node will writes to the Cache memory of Raid controller, instead of actual disk ( or buffer on disk ). This will gives many performance effect for disk I/O. But remember this, put Raid controller to every single node will make higher costs. Here's some good article for this kind of issue, but it's based on S3. http://improve.dk/archive/2011/11/07/pushing-the-limits-of-amazon-s3-upload-performance.aspx    


Not only for the number of disk per node, the network is great pain point when we build this. Currently, most cloud services are using MLAG for non-blocking network. Well, it cloud be ok for Swift clusters. However, as we all know, the MLAG is vendor specific, and it needs layered architecture when we want cluster to be scaled-out massively. It also needs more expensive switches for top layer ( which can be called as "backbone" ), based on chassis, which is very expensive thing.  And more, a single node's network status change effects to the core network also because it's based on L2. As an example, if there's huge number of nodes, then the core network should have all of the information of each node's mac-ip map. In various MLAG architecture, it's not flexible for its status change, so it makes serious problem sometimes. And as you can easily imagine, there's more possibility of failure when number of server increases, then the network cloud be slower because of the actions such like update, reference on the table. And there's some MLAG doesn't support active-active, means the bandwidth utilization cloud not be maximized. So, I would like to suggest to use L3 from ToR architecture, such like an iBGP/OSPF with ECMP. Dan Mihai Dumitriu from Midokura and I are figured out how it works for cloud network, and it's effect is exactly same as we wanted. Faster fault tolerance, single node's status change does not effect to core network, not hard to expand, and can be massively scale-out. It's explained in old post at this blog, but unfortunately, it's wrote in Korean. But you can easily understand because it has diagram, and actual switch configurations. Anyway, it solves most problems of MLAG or L2 based architecture, and we can archive more good model for enterprise services.


One more important thing is, the problem of SSL. Swift is based on REST API, and it means the authentication / authorization information are flow through HTTP header. It means we need to secure every single HTTP request with SSL, so the HTTPS is basic thing to make service secure. However, the Swift proxy is built with python, so it's SSL performance is terrible. Therefore, we need to put something else to make it work faster. That is, process SSL with reverse-proxy or software based load-balancer, then pass the requests to Swift proxy which runs without SSL. If you are an infrastructure engineer, then you 'll have some ideas about how to solve this issue. There's some ways to solve this, but one thing that I want to notice is do not use hardware based load balancer which has OpenSSL hardware integration feature. Well, it could be better than single machine's performance, but it's more expensive than software. Don't forget you're building a cloud service, which means there's possibility that every components of service could be added or expanded. 


The last thing is ( even if there's much more things ), about the zone. All of the Swift document says the "5" zone is needed by default. If you have a good understand of Swift, then you already know about what the zone is, which has strong relationship with cluster expansion. And more, it's related with every single rack ( cabinet ) design. This is about how to make expansion model, and also how to make fault tolerance model. As I raise this issue, so you can think about why the "5" is considerable number, and how it effects to the cluster when we change the number to another. 


Not like many other open sources, this solution cloud not be used with "default" options. If you can remember how the linux worked in late '90, then you may understand what this means. There was "no" defaults, and sometimes we need to change some source codes before we compile, and use it. Back to the Swift, I didn't say about DB updates when massive requests comes into Swift cluster yet, because it's needs to figure out by your hands, for your services. There are many decision points exists, it means sometimes it's too hard to go on with this. It's strongly needed to do many tests to build this cluster for right service, then you can solve many of this issues. In my experience, if you build this cluster in production level without PoC or massive tests, then you'll fall into deep problem that cannot escape.  


Many contributors are working hard for Openstack, and I give thanks to them. It's get better and better as time goes by, and I believe that all of its component will be stabilized with more features in not far distant future. Swift is considerable solution when someone want to build huge size storage cluster which will used through Web. But there's always tuning point exists, so our major job to figuring out "butterfly effect" in cloud. The small change will makes huge difference for performance, and costs.


Thanks for reading this post in ugly English, and please feel free to write your opinion about this. 




( younjin.jeong@gmail.com, Younjin Jeong )  



저작자표시 비영리
,

Things that you have to concern when you build CLOUD.

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



클라우드는 이제 관심을 넘어, 이 업계의 사람들에게 실제 비용을 주고 어떻게라도 접근 해야 뒤쳐지지 않는, 마치 패션과 같은 무엇이 되어 버렸다. 이는 어떠한 일반적인 사용자에게는 애플의 "포토스트림" 과 같은 서비스를 해 주는 무언가로 인식 되기도 하고, 개발자들에게는 "저렴한 개발 플랫폼" 으로 인식되기도 하며, 누군가에게는 "어디서나 접근 가능한 저장소" 의 개념이 되기도 한다. 

바야흐로 Everything as a Service 의 시대를 맞이함에 있어, 위에 소개한 개념들을 내포한 대부분의 서비스들이 우후죽순 처럼 생겨나는 시대가 되었다. 누구나 Post Facebook 에 대해 생각해 보고, 좋은 사업 아이디어를 가지고 저렴한 비용으로 서비스를 시작해 볼 수 있는 시대이기도 하다. 아이디어만 있다면, 사업을 시작함에 있어 적어도 인프라에 있어서는 기존의 1/10 도 안되는 비용으로 가능하다.

하지만 언젠가는, 사업이 일정 규모 이상으로 커지고, 데이터 보안에 대한 압박이 커져 갈 수록 기존의 Public Cloud 서비스는 비용과 보안에서 커다란 문제를 가진다. 또한 서비스를 구성하는 각 모듈화된 컴포넌트를 구현함에 있어 제약 사항이 발생하게 되고, 이러한 제약 사항을 해결하기엔 너무 획일적인 구조를 가진 기존의 서비스로 인해 한계에 봉착하기도 한다. 이러한 한계로는 주로 네트워크의 대역폭, 사용 가능한 IP 의 제한, 심각할 정도로 낮은 I/O 성능, 서비스 공급자의 장애 발생에 의한 서비스 중단 및 Flat Network 구성으로 인해 인스턴스에서 1개의 네트워크로 외부 연결 및 내부 연결을 처리해야 하는 구조적인 제약을 가지곤 한다.

Image from: http://softwarestrategiesblog.com/2011/07/27/gartner-releases-their-hype-cycle-for-cloud-computing-2011/

이러한 제약으로 인해 빠르던 느리던 각 기업은 기존과 같이, 직접 운용해야 하는 클라우드 인프라를 소유하고자 하는 경우가 발생하게 된다.  하지만 이러한 클라우드 시스템은 오픈 소스로 구현 하였을 경우, 또 적절한 운용 인력이 있는 경우에 최대한의 성능을 발휘하지만 국내에서는 이 두가지 모두 쉬운일이 아니다. 따라서 많은 기업은 "이미 구현되어 사용법만 알면 되는 클라우드 플랫폼" 에 관심을 가지게 된다. 하지만 이건 구현에 있어 "엄청난 비용" 이 필요하므로, 처음부터 가격 경쟁력을 무시하겠다 라고 정의하고 시작하지 않는다면 향후 큰 난관을 맞이하게 된다. 

금일 포스팅은 이러한 "클라우드 플랫폼" 구성에 있어 반드시 고려해야 하는 요소들을 몇가지 적어보려 한다. 이는 물론 이 포스팅을 읽는 어느분께는 유용할 수도, 유용하지 않을 수도 있지만, 가장 궁극적인 목적은 나 스스로 이러한 것들이 중요하다고 정의/정리 하는 것이 필요함을 느껴서 이다. 따라서 관심이 없는 분들은 언제든 닫아 주셔도 좋다. 또한, 이제부터 정리하는 내용들은 모두 오픈소스 또는 가장 저렴한 방법을 통해 클라우드를 구성한다고 의사 결정이 완료 되었음을 가정하고 설명한다. 


0. 개념 

개인적으로 클라우드의 정의는 클라우드란 사실, 클러스터의 특화된 개념으로 볼 수 있다. 특정 서비스의 구현을 목적으로 동일한 형상의 시스템 다수를 네트워크를 통해 묶는 것을 말한다. 최근에 많이 사용되는 서비스를 기준으로 가상화된 인스턴스를 제공하는 클라우드는 하이퍼바이저 클러스터로 볼 수 있으며,  무한대의 확장을 제공하는 스토리지 클라우드를 디스크 클러스터로 볼 수 있다. 다시 이 위에 서비스를 구현 한 것들은 DB 클러스터, Queue 서비스 클러스터로 볼 수 있다. 

결국 엔드유저 또는 기업이 원하는 것은 하이퍼바이저 클러스터인 컴퓨트 클라우드와, 디스크 서버 클러스터인 스토리지 클라우드로 이루어진 IaaS 클라우드가 되며, 이 위에 DB, Queue, Load Balancer, CMS, CDN 등의 서비스를 덧입힌 것을 REST API 를 통해 컨트롤 하게 만들면 바로 클라우드가 된다.  

클러스터라고 부르면 보통 컴퓨팅에서는 수퍼컴퓨팅 또는 자연과학, 물리학 등에서 계산을 목적으로 사용하는 컴퓨터의 묶음 또는 거대한 Cray 컴퓨터로 할 수 있는 무엇을 상상하곤 한다. 클라우드라 불리는 이 특수목적용 클러스터는 결국, 세분화 한다면 가상화 인스턴스 클러스터, 파일 및 오브젝트 저장 클러스터의 확장에 다름 아니다. 

IBM이 문서 정리는 참 잘하는데, 다음의 링크를 한번 읽어보는 것도 좋다. 
http://www.ibm.com/developerworks/kr/library/os-cloud-anatomy/



1. 네트워킹 

클라우드가 곧 일종의 클러스터이므로, 용도와 목적에 맞는 네트워킹의 구조 설계가 하나의 중요한 포인트이다. 하지만 이 네트워크 구성에 다소 어려움을 겪는 것이 일반적인데, 이는 기존에 사용하던 단일 서비스 네트워크 구조와는 그 모양새가 다르기 때문이다. 왜 다르냐고 묻는다면, 바로 듣기에도 생소한 하이퍼바이저의 클러스터링을 해야 한다 라는 요구조건 때문인데, 이 클러스터링이 요구하는 형태가 그 클러스터 소프트웨어에 따라 조금씩 상이하기 때문에며, 또한 하이퍼바이저 역시 조금씩 다른 성향을 가지고 있기 때문이다. 

물론 그렇다 하더라도, 모든 클라우드 클러스터는 다음의 내용을 충족해야 한다는 조건을 가진다. 

- Scale-out 의 형태로 거의 무한대에 수렴하게 증설이 가능한 구조여야 한다. 
- 필요에 따라 FCoE 즉 iSCSI 트래픽의 처리에 중점을 두어야 할 필요가 있다. 
- 하이퍼바이저 또는 스토리지 클러스터가 원하는 요구조건을 충족해야 한다. 
- 보통 서비스/관리/스토리지/가상 네트워크의 종류를 가진다. 
 
예를 들어, 랙 하나를 가지고 컴퓨트 클라우드를 구현하고자 하는 경우, 다음의 옵션을 사용 할 수 있다.
- Option A :  Cloudstack  +  # of Xen server +  iSCSI Storage + Logging/etc.
- Option B :  Open Stack Nova + # of KVM server + iSCSI Storage + etc.

Option A 를 선택한다고 가정 할 때, 랙이 단 1개만 구성되는 경우라면 별 고민없이 대부분의 컴포넌트에 기본 옵션을 사용 할 수 있다. 예를 들어 Xen server 의 최대 클러스터 수량인 16대를 Compute Node 로 묶어 하나의 공유 스토리지를 가지는 형태로 구성이 가능하다. 이러한 시스템의 준비 및 설치는 장비만 있다면 필자의 경우 수십분 내로 구성이 가능하다. 이러한 단순한 구성에도 네트워킹을 위해서는 사설 관리 네트워크 / 공인 네트워크 / 사설 스토리지 네트워크의 적어도 3가지가 필요하게 되며, 이 랙을 Public 클라우드 처럼 사용하고자 한다면 Router VM 에서 각 고립된 계정에 할당되어 사용할 별도의 사설 IP 대역 및 스위치 레벨에서의 tagged VLAN 구성이 필요하게 된다.

랙 1개에 구성하고자 하는 경우에는 이처럼 큰 구조만 짜 맞추어 주면 별 문제가 안된다. 대부분을 기본값을 사용해도 무방하다. 만약 기업에 필요한 인스턴스의 숫자가 200개 미만이고, 높은 가용성을 요구하지 않는다면 손쉽게 만들어 사용 할 수 있다.

하지만, 만약 사설 클라우드를 ( 이 글의 기본 요구조건인 기업 고객이 그들의 서비스를 위해 사용하고자 하는 경우이므로 ) 엔터프라이즈 레벨, 즉 적어도 랙 500개 이상을 구현하고자 할 때는 간단한 네트워킹으로 해결 할 수 없다. 이는,  다음과 같은 요구조건을 가지게 된다.

- 모든 랙은 서로 통신이 가능해야 한다.
- 서브네팅을 하지 않는다면, 하나의 하이퍼바이저 또는 스토리지가 전체 클라우드를 말아먹을 수 있다.
- 손쉬운 설치를 위해, 모든 랙의 관리 네트워크는 DHCP 가 가능해야 한다. 
- EBS와 같은 기능을 구현하고자 하는 경우, 모든 랙에서 접근 가능한 스토리지 네트워크의 구현이 가능해야 한다.  
- 이 모든 네트워크는 확장 또는 추가에 일정한 "법칙" 또는 "체계" 를 가지도록 해야 하는 것이 좋다. 그렇지 않은경우, 디스크/서버 장애가 발생한 경우 교체를 위해 OP는 책 한권 분량의 매핑 자료를 들고 다녀야 할 것이다. 

언뜻 보기에는 쉬운 요구조건 같지만,  무엇이 베스트 모델인지 추려내는 것은 경험 없이는 쉬운일이 아닐 것이다. MLAG 기반의 L2 형 확장이 답인지, 아니면 각 랙을 L3 기반으로 만들어 백본에 추가하는 것이 나은지는 오직 서비스 요구 조건과 규모, 그리고 비용에 따라 다를 수 있다. 다음을 보자. 

MLAG 을 사용하기로 결정 한 경우
- Enterprise 보다는 Midsize 에 권한다. 
- 백본의 성능이 중요한 이슈가 된다. 
- 벤더마다 다르지만, MALG 구성시 양쪽의 회선을 동일하게 Active - Active 형태로 제공하는 제품을 사용하는지 확인 할 필요가 있다. 
- Backbone 의 포트 수량에 따라 클러스터의 크기가 결정되는 경우가 많다. 

L3 기반의 네트워킹을 사용하기로 결정 한 경우 
- OSPF/BGP 등의 프로토콜이 전사적으로 지원 되어야 한다. 
- ToR 의 물리적 Uplink 수량에 따른 ECMP 지원 여부를 확인/테스트 해야 한다. 
- 실제 장애를 발생시키는 테스트에서 Route Path 의 업데이트를 명확하게 체크하도록 한다. 


공통 
- Flat Network 를 구성하는 경우, QoS 사용 여부를 적극 검토하도록 한다. 
- 서비스에 따라 MTU 구성에 대한 최적의 값을 찾아보도록 한다. 물론, 하이퍼바이저에 따른 MTU 의 지원여부는 확인해 보아야 한다. 
- Provisioning 을 위한 DHCP Relay 의 동작을 구성하도록 한다. 

본 네트워킹에 대한 부분에서는, 이전에 포스팅한 iBGP 관련 내용을 확인 해 보도록 한다. 
네트워킹은 클러스터의 젖줄이기 때문에, 그 설계에 있어 클러스터에 필요한 모든 요구사항을 반영할 수 있어야 한다. 이 말은 바꾸면 클러스터에 대한 요구 조건을 파악하는 것이 클라우드 네트워크 설계의 핵심이며, 따라서 다음의 내용은 클러스터에 대해 알아 보도록 한다. 

아시다시피, 각 클러스터의 리소스에 연결되는 대역폭 또는 Latency 와 같은 이슈도 중요함은 굳이 추가로 설명하지 않는다. 



2. 하이퍼바이저. 

어떠한 하이퍼바이저를 사용 할 것인가 결정하는 문제는 그렇게 쉬운 것이 아니다. 그 이유는 첫째, 직접 원하는 환경에서 구동해 보지 않으면 알아낼 수 있는 사실이 거의 없고, 문제가 한번 발생하면 상용이던 오픈소스던 해결이 쉽지 않으며, 가상화를 이해하는데 필요한 기본 개념이 제법 많기 때문이다. 

한가지 더 중요하게 고려해야 할 사항은, 과연 하이퍼바이저가 필요한가의 여부이다. 물론 대부분의 가상화된 인스턴스를 제공하고자 하는 클러스터는 당연히 하이퍼바이저를 사용해야 하지만, 경우에 따라 하이퍼바이저가 없는, 즉 기존의 일반적인 물리 서버를 그대로 사용하고자 하는 경우도 있을 수 있다. 가상화를 사용하기 시작한 이유는 대부분의 서버가 서비스 하는 시간동안 peak 상태를 유지 하는 것 보다, idle 상태가 더욱 많기 때문에 물리적 자원을 극대화 하여 사용하기 위해 이를 독립적으로 쪼개어 사용하고자 하는 이유에서 비롯된 것이다. 하지만 서비스가 대부분의 시간동안 Peak 를 치는 경우, 이는 하이퍼 바이저를 사용하지 않거나, 또는 인스턴스 생성의 기본이 되는 서비스 오퍼링을 극대화, 즉 DomU 의 수량을 줄이는 형태의 구성도 때로는 필요하게 된다. 아마도 HPC 분야에 사용하려는 클라우드의 경우 이러한 구성을 생각해 볼 수 있겠다. 

상용으로 많이 사용하는 것은, VMWare 와 Xen 이며, Xen 의 경우에는 오픈소스로도 가져다가 사용이 가능하다. 통상 KVM, VMware, Citrix Xen, OSS Xen 중 하나를 선택하여 클러스터를 구성하게 되는데, 각 클러스터 별로 인스턴스의 통제를 지원하는 범위 및 API 의 사용성등이 상이하므로 충분한 테스트를 통해 기업의 서비스에 맞는 하이퍼바이저를 선택하는 것이 중요하다. 

예를 들자면, 
- VM에 대한 BIOS 제어 범위 
- Redundancy 구성의 가용 범위 ( 예를 들면 802.3ad 구성시 MTU 변경 적용 가능 여부 등 ) 
- vCPU, 메모리 할당의 한계와 VM 수량에 대한 적정 비율. 
- API 
- VM 의 백업 지원 방법 
- 공유 스토리지 필요여부 
- 이미지 / 템플릿을 통한 Deploy 
- Thin Provisioning 
- 필요한 경우 GPGPU 와 같은 기능을 위한 PCI Pass-through 
- 필요한 경우 Software 기반 스위치 ( ex. Open vSwitch ) 와의 연동 여부 
- Dom0 로 통칭되는 가상화 OS 의 변경 적용 범위 
- 사용하고자 하는 클라우드 통제 시스템 ( 통칭 클라우드 스택 ) 과의 부드러운 연계 

등등의 내용이 있을 수 있다. 이러한 하이퍼바이저의 선택과 사용은, 벤더의 제품인 경우에도 벤더에 의지하기 보다는 내부의 경험있는 기술자에 의해 검증되는것이 필요하다. 일반적으로 논의되는 Vendor Lock-in 의 문제를 피하기 위해 다양한 하이퍼바이저가 검토되어야 할 필요가 있지만, 이 하이퍼바이저는 하드웨어와도 직접적으로 연계되는 부분이 제법 있으므로 보통 한번 선택하면 변경될 가능성이 거의 없다. 

하이퍼바이저라는건 기본적으로 VM 또는 인스턴스가 돌아가는 기본 장소이며, 이에 필요한 기능만을 선택하여 사용하는 것이 중요하다. 예를 들면, Citrix Xen server 는 공유 스토리지를 기반으로 클러스터링 하여 사용하는 것이 가능하지만, 별도의 클라우드 관리 스택을 사용하는 경우 공유 스토리지 없이 사용 하는 것도 가능할 수 있다. 이렇게 되면 XAPI 를 사용한 클러스터간 통신이 없어지게 되며, 별도의 라이브마이그레이션 등의 기능을 사용하지 않게 되므로 VM을 "만들고", "켜고", "끄고", "지우는" 기본 동작이 엔터프라이즈의 규모에서 보다 빠르고 안정적이게 동작 하는 것이 가능하다. 물론, 이는 여러가지 상황을 함께 고려해야 하므로, 단순히 본인의 의견을 수용하는 것 보다는 사용하고자 하는 오케스트레이션 도구, 즉 클라우드 스택과의 연동을 함께 살펴보는 것이 중요하겠다. 


3. 클라우드 관리 도구 

사실 각 클라우드의 특성은, 이 관리도구를 어떻게 구성하는가와 밀접한 관련이 있다. 이 관리 도구의 특성과 각 구성에 있어 지원하는 범위에 따라 컴퓨트 클라우드는 그 기능이 정해진다고 해도 무리가 없다. 이를 테면 다음의 핵심 기능들이 꼭 구비 되어야 컴퓨트 클라우드가 원하는 기능을 수행하는 클라우드 스택이라고 말할 수 있다. 

- 사용자 관리 도구. 
- 사용자가 가진 인스턴스에 대한 메타데이터 생성/보존/변경 
- 하이퍼바이저 클러스터의 전체 리소스 균등 분배 
- 골드 이미지/템플릿 등을 통한 리눅스/윈도우 등의 인스턴스 생성/삭제/종료/시작 
- 사용자 키 기반의 인스턴스 보안 설정 지원 ( 패스워드 및 admin 계정 등 ) 
- 필요한 경우 사용자 단위의 추가 Volume 생성/삭제/인스턴스 연결/해제 지원 
- 사용자 이미지 생성/백업을 위한 다양한 스토리지 연결 지원 
- 각 인스턴스 또는 리소스에 대한 헬스체크를 사용, 문제 발생시 메타데이터를 통한 VM 이동, IP/Volume 등 기존 자원의 자연스러운 매핑 
- VM 콘솔 
- 빌링이 필요한 경우 각 리소스 사용량에 대한 측정 지원 
- 위의 모든 기능을 사용 할 수 있는 API ( REST API ) 지원 

클라우드 스택이란건 ( cloud.com 의 제품만을 말하는 것이 아님 ) 결국 컴퓨트 클라우드에서 가상화 자원에 대한 "이동", "생성", "삭제", "연결", "중지", "시작", "접근", "백업", "복구" 등의 핵심적인 기능을 지원하는 도구를 말한다. 이러한 모든 동작은 하이퍼바이저를 제어하는 기능과, 현재 가지고 있는 자원에 대한 적절한 계산을 통한 분배 등을 지원하는 기능을 포함해야 한다. 

예를 들어, 처음 인프라를 구성하게 되는 경우 5개의 랙으로 시스템을 구비하였다가, 향후 20개의 랙으로 확장 했을때 기존 5개의 랙에서 동작하던 VM이 자연스럽게 나머지 20개의 랙으로 골고루 퍼질 수 있어야 한다. 현재 상용및 오픈 소스로 구성이 가능한 클러스터 모두 이러한 부분에 있어 제한 사항을 가지고 있는데, 어떠한 제약이 있는지는 직접 테스트 해 보는 것이 좋을 듯 하다. 

내 생각에 가장 좋은 구현의 방법은, 메타데이터를 통한 API 명령을 조합하여 위의 기능들을 구현한 관리 스택을 기업의 개발팀이 직접 만들어 내는 것이다. 물론 개발 그룹이 없는 기업의 경우에는 힘들겠지만, 국내 대부분의 클라우드를 위한 대규모의 자금을 사용할 수 있는 기업의 경우 자력으로 구현이 가능한 자회사를 가지고 있다고 생각한다. 물론, 여러가지 이슈로 쉬운 일이 아니긴 하지만, 그런 부분을 제외하고 개인적인 견해를 피력해 보자면, 다음과 같은 컨셉을 반영한 도구면 된다. 

- 기본적으로 하이퍼바이저 레벨에서 지원하는 클러스터링은 하지 않는다. 이는 클러스터 규모를 제한함으로서 확장 단위 구성에 난점이 있다. 
- 기존의 대규모 계산용 클러스터와 같은 구성을 취하도록 한다. 각 하이퍼바이저는 랙 내에서 독립적으로 동작하며, 이들 리소스에 대한 관리는 클라우드 스택에서 한다. 
- 클라우드 스택은 서비스를 위한 데이터베이스를 가지고, 이 데이터베이스에는 사용자 VM이 동작하는 위치, VM 생성에 사용된 서비스 오퍼링, iSCSI 또는 SAN 에서 해당 VM에 연결된 가상 Volume 의 위치, 네트워크 정보 및 인증 정보 등을 가진다. 또한 별도의 헬스체크 모듈을 통해 일정 시간 단위로 VM의 상태에 대해 파악한다. 
- VM에 문제가 발생한거나 사용자가 원하는 경우, 미리 계산된 리소스 ( 하이퍼바이저의 vCPU, RAM ) 등의 가용성에 따라 적절한 호스트에 VM을 신규로 생성하고, 기존의 VM은 삭제 처리 한다. 물론, 데이터베이서의 정보를 바탕으로 기존의 Volume 연결을 지원해 준다. 
- 백업이 필요한 경우 별도의 스토리지 또는 오브젝트 스토리지등의 클라우드로의 백업 경로를 지원한다. 보통 동일한 이미지를 사용하도록 강제하는 정책을 사용함으로서, 스냅샷 기반의 백업/복구를 보다 쉽게 처리하도록 한다. 


위와 같은 구조를 채택한다면, 아마존의 EBS와 같은 사용성을 제공함과 동시에 클라우드 스택이 지원하는 모든 하이퍼바이저를 어떠한 구조적 제약 없이 사용하는 것이 가능 할 것이다. 기본적으로 우리는 항상 VM에 하이퍼바이저를 통한 Volume 연결을 생각하지만, VM에 직접 iSCSI 또는 FCoE 와 같은 기술을 통해 직접 연결을 구성한다면 필요한 Volume 의 확보 및 인스턴스(VM) 의 장애에 대한 데이터 복구가 훨씬 자유로울 수 있을 것이다. 

이러한 클라우드 스택의 동작은 하이퍼바이저를 통제하는, 즉 가상화 시스템 상위에 위치하지만, 기업이 직접 구현해야 할 사용자 포털 및 관리 포털 보다는 하위에 위치한다. 따라서 클라우드 스택은 이러한 연계를 위해 API 및 포털로 부터 할당받은 커맨드 실행을 위한 Queue 등을 구현해 줄 필요가 있게 된다. 이 말이 의미하는 바는, 즉 클라우드 스택의 기능 범위를 제한 할 필요가 있다는 것이다. 아마존을 빗대어 이야기 해 보자면, SQS, EMR, RDS, ELB 와 같은 서비스를 모두 클라우드 스택 내에 녹여낼 필요는 없다. 물론 함께 동작 할 수 있다면 좋겠지만, 각 서비스별로 구분된 클러스터를 독자적으로 만들고, 이를 포털에서 API 로 통제하는 것이 더 좋다는 말이다. 이해를 돕기위해 추가적으로 설명 해 보자면, 

- 클라우드 스택은 VM 및 Volume 의 관리 및 (사설 또는 공인) IP 의 할당 까지만 관여한다. 
- ELB 와 같은 기능은 별도의 밸런서 팜을 구성하고, 여기에 포털에서 스택과의 연계를 통해 밸런서에 인스턴스를 등록 할수 있도록 한다. 
- SDB와 같은 서비스는 고객의 인스턴스가 위치하는 컴퓨트 클라우드 외에, 별도의 독립된 컴퓨트 클라우드 팜을 구성하고, 여기에 CouchDB / MongoDB 와 같은 서비스 클러스터와 API 를 구현, 역시 포털에서 사용자 별로 독립적으로 할당하도록 한다. 

뭐 당연한 이야기 같지만, ELB 와 같은 서비스의 경우 클라우드 스택 내에서 해결하려는 경우가 많다. 극단적인 예로 단일 기업이라면, 컴퓨트 클라우드를 구성하고 각 인스턴스에 공인 ( 또는 공인 처럼 취급되는 사설) IP 를 직접 연결, 상위 별도의 망에서 밸런싱 처리를 하는 구조를 취하는 것이 가능 할 수 있다. 


이처럼, 컴퓨트 클라우드를 위한 관리 스택은 바로 EC2 의 관리를 위한 모듈처럼 취급 되어야 하며, 그 자체로 적절한 기능의 제한이 있어야 한다. 한가지의 보다 더 극단적인 예는, Cloud.com ( 이제는 Citrix ) 의 구조를 사용한 작은 클러스터를 랙 별로 할당하고, 이를 상위 포털에서 Cloudstack 의 API 를 통제하는 형태로 구현하는 것도 가능할 것이다. 물론, 여기에서 발생하는 네트워크 문제는 여러분이 직접 해결 해야 할 것이다. 기회가 되면 소개하겠지만, 이미 이 주제에 대해 너무 많이 쓴 것 같다. 



4. 스토리지 

대부분의 현재 동작중인 퍼블릭 클라우드가 I/O 성능을 병목 구간으로 가지고 있다. 사실 컴퓨트 클라우드를 더 잘 사용하려면 가급적이면 I/O 접근을 사용하는 부분을 줄이는 것이 좋은데, 아무리 이 부분을 강조 하더라도 기존의 단일 서버처럼 사용하도록 개발을 하는 패턴을 전체 개발자에게 금지 시킬 수는 없다. 하여, 기본적으로 어느 정도까지는 그 I/O 성능을 보장해 줄 필요가 있는데, 이에 대한 요구 조건을 충족 하려면 다음과 같은 내용을 고려 해야 한다. 

- 클라우드에서 사용되는 스토리지는 대부분 네트워크를 통한 원격 스토리지이다. 
- 하이퍼바이저 내에서 동작하는 VM의 수량과 관계가 있다. 이는 또 물리적으로 다른 랙에 타겟 스토리지를 구성한 경우 랙간 레이스 컨디션이 발생 할 수 있다. 
- 클라우드 클러스터에서는 대부분의 I/O 가 랜덤하게 발생한다. 따라서, 스토리지의 성능이 매우 중요한데, 요청이 과다하게 몰리는 경우에도 timed out 이 발생하여 스토리지 세션이 끊어지지 않도록 관리하는 것이 매우 중요하다. 
- 따라서 분산이 매우 중요하다. Commodity H/W 의 개념에서, 한대의 스토리지가 분산을 지원하는 것 보다는 수많은 스토리지를 별도의 네트워크에 분산하고, 이를 클라우드 스택에서 관리하도록 하는 것이 현명 한 방법이 될 수 있다. 
- 성능 이슈로 분산했다면, 장애 극복을 위한 복구 및 복제 방침이 마련 되어야 한다. DRBD 와 같은 구성이 요구 될 수 있다. 
- 하나의 랙 또는 한대의 스토리지에 너무 많은 디스크 자원을 분배하지 않아야 한다. CPU 당 디스크, I/O 성능을 기반으로 한 네트워크 한계점 설정이 중요하다. 
- 이러한 형태의 클라우드 스토리지에서는 캐쉬빨이 별로 받지 않는다. 
- 비용이 허락한다면 Write Back 을 지원하는 HBA 를 사용하도록 한다. 


스토리지는 참으로 귀중한 자원이다. 특히 오브젝트 스토리지와는 다르게 일반 Volume 의 사용성을 가지며 인스턴스에 직접 연결되는 이러한 스토리지는, 반드시 사용자의 필요에 의해 요청된 경우에만 인스턴스에 연결해야 한다. 이 말은 기본 스토리지는 휘발성을 가지도록 구성해야 하며, 꼭 필요한 경우에만 이러한 원격 스토리지를 할당해야 부하를 줄일 수 있다는 말이 된다. 

만약 인스턴스의 로컬에 격렬한 계산을 통해 스크래치 파일 ( 일반적으로 삭제되도 되는 파일 ) 을 만들어 내는 경우, 이는 하이퍼바이저 로컬에 thin provisioning 된, VM이 살아 있는 동안에만 유지되는 가상 파일시스템을 사용하는 것이 맞다. 만약 이렇게 격한 I/O 를 원격 스토리지를 사용하도록 한다면, 아마존에서 발생했던 것과 유사한 장애를 경험하게 될 확률이 높다. 

이 부분의 설계시 중요하게 고려되어야 할 부분은, 원격 스토리지 볼륨의 사용은 Persistency 를 가지는 데이터에 한하며, 각 가상 인스턴스는 꼭 필요한 경우가 아니면 이러한 원격 스토리지를 할당하지 않도록 서비스를 설계 해야 한다. 이를테면, 인스턴스가 처음 생성되거나 재부팅 시에 항상 업데이트된 코드를 저장소로 부터 다운로드 받도록 구성하는 것과 같은 기법 말이다. 

아마존 서비스의 많은 부분이 미스테리이긴 하지만, 중요한건 기업용 사설 클라우드가 반드시 아마존과 동일한 형태로 모든 서비스를 구축 할 필요는 없다는 것이다. 그들의 주 목적은 모든 사용자를 위한 "Public" 클라우드 이며, 기업용은 거의 대부분의 경우 "Private" 클라우드 이기 때문이다. 

EBS 시스템에 관해 재미있는 번역 포스팅이 있는데, 한글도 있으므로 관심이 있다면 읽어보는 것도 좋을 듯 하다. 
http://jmlab.tistory.com/19

결국은, 클러스터 된 네트워크 스토리지이며 확장을 위해 L3 레벨로 구성되었음을 알 수 있다. 



5. 자동화 

이 부분을 의외로 쉽게 보는 분들이 많은데, 위의 0,1,2,3,4 가 모두 아키텍처로 녹아 있는 것이 바로 이 자동화가 되겠다. 하지만 시작부터 겁낼 필요는 절대 없다. 이는 하나의 거대한 어플리케이션을 만드는 것이 아닌, 요소별 필요한 파트를 지속적인 코드 테스트를 통해 구현해야 하는 것이다. 하드웨어 별로 다른 코드가 필요할 수 도 있으며, 향후 인프라 아키텍처의 변경으로 인해 수정되어야 할 필요가 있을 수 있다. 처음부터 완벽한 클라우드 또는 클러스터를 만드는 것은 현재로서는 거의 불가능하며, 반복된 자동화 코드의 수정을 통해 보다 안정된 서비스를 만들어 낼 수 있게 될 것이다. 

클라우드용 클러스터 구현을 위한 자동화는, 보통 다음과 같은 내용을 구현 해야 할 필요가 있다. 

- Internal Resources ( NTP, TFTP, DHCP, DNS, Package Mirror-site, Code repository, etc ) 
- PXE Boot  Support 
- OS Install 
- First-boot scripts
- Interface setup
- File system
- SSH keys
- Cluster setup
- Storage server 
- Log / Meetering / Monitoring , etc 

서비스에 따라 더 구성해야 할 것들이 있을 수 있지만, 기본적으로는 위와 같은 구성요소를 자동화 해야 할 필요가 있다. 클라우드의 용도에 따라, 그리고 하드웨어의 변경에 따라 코드의 변화가 필요할 것 같은 부분들은 변수처리를 통해 구현하는 것이 유리하다. 

자동화에 대해서는 별도의 책을 출간 준비중이므로, 조만간 좋은 내용을 소개 할 수 있지 않을까 한다. 




6. 클라우드 개발에 대한 인식 

사실 앞의 내용들 보다 이 부분이 가장 중요 할 수 있다. 기본적으로 상용 클라우드를 직접 덩어리째 사서 들고올 생각이 아니라면, 일정 부분 이상은 오픈소스를 사용해야 할 수 있다. 심지어 오픈소스가 아닌 상용을 구매하여 사용하는 경우라도 각 컴포넌트를 충분히 경험한 엔지니어가 많지 않다. 이 말은, 어떠한 경우에라도 문제가 발생했을때 올바른 지원을 받을 가능성이 낮아진다는 말이 된다. 게다가 이 클러스터는 수많은 요소가 서로 결합된 것이기 때문에, 스토리지와 하이퍼바이저의 벤더가 다른 경우 문제가 발생 했을때 서로 손가락질 할 가능성이 있다. 이는 네트워크도 마찬가지이며, 국내 벤더사들의 특성상 벤더 엔지니어는 벤더 제품에 종속적인 경우가 많고, 만약 다른 부분에 장애가 발생한 것을 명확히 파악 하더라도 입밖으로 내기 쉬운 환경이 아니다. 

이러한 환경적 제약은, 바꾸어 말하면 클라우드를 구현하려는 기업이 스스로 능력을 축적해야 한다는 말이 된다. 컨셉을 확인 할 수 있는 최소한의 규모의 랙을 가지고, 수많은 테스트를 통해 무엇이 최선인지, 그리고 어떻게 사용해야 하는지에 대해 내부 인력이 학습해야 한다. 그것을 바탕으로 자동화코드를 만들고, 만들고 부수는 작업을 반복했을때 비로소 동작하는 클라우드를 만드는 것이 가능해 진다. 

바로,  

아키텍처 디자인 --> 개발 환경 구성 --> 자동화 코드 개발 --> 설치 및 배포 --> 테스트 --> 재 디자인 --> 코드 개발 --> 배포 --> 테스트 

의 순환을 가급적 빠른 속도로 잘 짜여진 스케줄 안에서 진행해야  개발, 운영에 대한 노하우의 내재화가 가능 할 것이다. 
물론 이러한 구성에 있어 경험자의 리딩이 매우 중요하며, 전체 과정이 일반적인 기업 연구소에서 진행 되는 것 처럼 루즈하게 늘어져서는 안된다. 그러기 위해서는 현재 실무를 담당하고 있는 인프라와 개발진이 적절한 리더에 의해 협업해야 하며, 인프라가 개발을 무시하거나 개발이 인프라를 무시하는 일 없이 서로가 서로의 일이 어떻게 시스템에 반영되는지 긍정적인 자세에서 이해하는 것이 필요하겠다. 


사실, 국내의 모든 클라우드는 바로 이 부분이 쉽지 않기 때문에 문제가 발생하지 않나 싶다. 개발과 운영이 협력하면 참 좋을텐데, 이게 쉽지 않더라는...  아무튼. 


엄청나게 긴 포스팅이 되었는데, 실질적으로 코드는 하나도 없어서 좀 그런 것 같다. 또한 너무 컴퓨트 클라우드에 종속적인 이야기가 많은 듯 하지만, 결국 기업이 원하는 사설 클라우드에 필요한 구성은 컴퓨트와 스토리지 클라우드가 거의 대부분이다. 이 두개 클러스터의 아키텍처가 올바르다면, 나머지 아마존like 한 서비스를 올리는 것은 시간의 문제일 뿐이다. 다만, 굳이 아마존과 비슷한 서비스를 만들어야 할 필요가 있는지는 자문해 보아야 한다. 

각 개인에게 클라우드 서비스를 판매 할 것이 아니라 서비스를 클라우드 위에서 구현하는 것이 목적이라면, 해당 서비스에 맞는 "적절한 클러스터의 구현" 이 오히려 올바른 개발 방향이 될 것이다. 굳이 아마존 따라서 개발 하느라 가랭이 찢어지지 말고, 먼저 구현해야 할 올바른 클러스터를 준비하는 것이 맞지 않을까 생각해 본다.


( younjin.jeong@gmail.com , 정윤진 )   
저작자표시 비영리
,

Being old car mania

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

많은 사람들은 가슴속에 가지고 싶은 것, 하고 싶은 것 하나쯤은 품고 산다.  돌이라도 씹어 먹을 것 같은 20대의 혈기에는 그에 걸맞는 아름다운 여자친구가 쟁취의 대상이 될 수도 있고, 즐기고 싶으나 금전적, 시간적인 여유가 부족해서 즐기지 못하는 어떠한 취미의 한 종류일 수도 있다. 나의 경우에는 보통 이런 저런 컴퓨팅 시스템의 조합을 통한 새로운 서비스의 디자인과 프로파일링이 그런 것이었는데, 최근에는 부쩍 차에 관심을 가지게 되면서 제목과 같은 부분에 취미가 생겨 버렸다. 

사나이의 로망, 포르쉐

 Image from: http://www.northwestautosalon.com/2010/11/fanatic-detail-paint-correction-leather-restoration-white-porsche-993-carrera-s/

사실 독일차를 새차로 구입하는 것을 보면, 잔고장도 없고 달리기도 좋고 새벽에 y00 속도 영역에서 즐기는 안정감, 80 미만에서의 무리하지 않고도 즐길 수 있는 아름다운 핸들링에 반해서인 경우가 많다. 물론 이 외에도 이성과의 만남을 위해 구입하는 경우도 있기는 하지만, 소개팅 한번 해 보지 않은 나같은 샌님에게는 여자사람을 만나는 것이 하늘의 별따기인 나의 인생과는 무관한 이유이기 때문에 뭐 그런건 접어두고. 

아무튼, 이렇게 저렇게 알아보다 보니 좀 오래되었지만 전자장비가 별로 없고, 뭔가 고쳐가면서, 공부해 가면서 탈 수 있는 재미가 있겠다 싶은 생각에 오래된 명차들에 관심을 가지게 되었다. 알아보다 보니, 이게 썩어도 준치라고 어떤차는 20년이 되어가는 주제에 아직도 몇천만원을 주어도 구하기가 힘들고, 그렇게 구하게 되더라도 수리비로 대체 얼마나 더 들어갈 지 모른다는 것이 매우 큰 난제임을 깨닫게 되었다. 

하지만 개인적으로 항상 주말에 차고에서 차를 조립하곤 하는 영상이 나오는 미국 영화를 보고 상당히 어릴적 부터 뽐뿌를 받아왔던 터라, 더 이상 미루게 되면 언제 한번 해 볼지 못해볼지 모르겠다는 생각에 최근 미친듯한 검색질을 통해, 다음과 같은 워너비 리스트를 만들게 되었다.  


1. Porsche 993. ( air-cooled ) 

Image from: http://www.mulhollandmotorsports.com/

Image from: http://www.mulhollandmotorsports.com/2010/11/10/porcshe-turbo/


Image from :  http://pattgregor.free.fr/index.php?showimage=673  

아시는 분들은 다 아는 포르쉐 993.  공냉식인 덕분에 이제는 해외에서 이사짐으로 들여오는 것도 불가능 하다는데, 그래서 그런지 통 돌아다니는 매물이 별로 없다. 쿨 매물을 찾으려 잠복한지 어언 한달인데, 좀처럼 나타나지 않는 듯. 
게다가 입양을 하려고 결심을 할때 적어도 엔진 및 변속기는 한번 들어내어 오버홀 정도는 고려해 주어야 하고 모든 부싱류 정도는 한번 갈아 줄 작정을 해야 그나마 "탈수 있지 않겠나" 싶다. 

남들이 보면 탈탈 거리는 엔진 소리에 겉멋만 잔뜩 들어보이는 이 오래된 차를 왜 사서 고생하려고 하냐고 하겠지만, 어차피 차라는게 개인적 기호가 크게 좌우되는 것이라 내가 좋다는데 무슨 상관이냐를 외쳐 주고 싶기는 하다. 하지만,  역시 관리가 안된 차들이 많고 그로인해 차 가격의 곱절은 족히 들어야 하고, 문제가 생길 때마다 받는 대단한 스트레스를 생각해 보면 그들의 말이 틀린 것도 아닐테다. 결국 차이는, 그러한 문제들을 해결해 나가는 과정을 즐기느냐 아니느냐 의 차이가 아니겠는가 싶다.  뭐 말은 이렇게 해도 언젠가는 장벽과 마주해 OTL 을 외칠지도 모르는 일. ㅎㅎ 



위의 영상은 공랭식 993 의 아름다운 엔진 사운드를 들려 준다. 하지만, 저 포르쉐는 포르쉐 본사에 의해 관리되는 것이므로, 저런 소리가 똑같이 날 거라고는 별로 기대하지 않는다.

 

오히려 위와 같은 사운드가 나지 않을까 싶은...

아무튼 좋은 차를 구할 수 있다면, 1 순위로 작업 해 보고 싶은 차량.. 


2. BMW E34 530i


Image from: http://www.bmwkatalog.cz/bmw-e34/

Image from: http://bimmerin.net/b5.php

이 두번째 차량은 조금 더 현실적인데, 단종된 년식은 993과 거의 비슷하다. 993 보다 훨씬 많은 ( 그래도 아반테 만큼 많지는 않다 ) 차량들이 존재하며, 국내에 매니아 층도 많고 동호회 활동도 활발하다. 그래도 역시 좋은 물건 구하기는 쉽지 않고, 차주의 사랑을 듬뿍 받은 축복받은 차량은 구하기 쉽지 않다. 

포르쉐와 마찬가지로 순정으로 복원하고자 한다면 얼마든지 정품을 구할 수 있으나, 가격이 만만치 않아 보인다. 시세는 보통 상태와 년식, 그리고 마일리지에 따라 500~1500 정도에 분포하는 것 같은데 일단 가져오면 역시 각종 부싱류 교환 및 오일 교환, 엔진 및 미션 정도는 작업한다고 미리 생각하는게 속이 편할 듯. 

게다가 이 차에 사용된 E60 엔진은 540과 함께 공유된 엔진을 사용하는데, Nikasil 이라 불리는 문제를 가지고 있는 차량이 많을 듯 하다. 이 문제는 품질이 떨어지는 연료, 즉 황이 많이 포함된 연료를 사용하는 경우 이 황이 실린더 벽을 갉아 여러가지 엔진 트러블을 야기하는 나름 유명한 문제로, 심한 경우 엔진 스왑을 각오해야 할 정도의 크리티컬한 문제이다. 다른 사이트에도 많이 이야기가 되었지만, 아무튼 차의 연식과 가격을 고려할 때 여러 주인이 사용한 히스토리 없는 E34 를 들일 경우 차 전체를 오버홀 해야 하는 극악 스런 문제가 발생할 수 있으므로 매우 주의해야 할 듯 하다. 아마 이러한 연료 문제가 없는 독일로 부터 엔진을 공수해 올 생각도 해야하지 않겠나, 뭐 그런 생각이 든다. 이 Nikasil 문제는 위키피디아에도 소개되었다.
 http://en.wikipedia.org/wiki/BMW_M60#The_Nikasil_problem




3. E39 530iS ( 1996 - 2003 ) 

Image from: http://forums.bimmerforums.com/forum/showthread.php?t=566720&page=2

얘는 E39 540i

Image From: http://forums.bimmerforums.com/forum/showthread.php?t=566720&page=2

E39 540

Image From: http://forums.bimmerforums.com/forum/showthread.php?t=566720&page=2

E39 540

Image From: http://forums.bimmerforums.com/forum/showthread.php?t=566720&page=2

Image From: http://forums.bimmerforums.com/forum/showthread.php?t=566720&page=2


아마도 위의 두대의 차량보다는 가장 현실적인 차가 아닐까 싶다. 이 차종의 경우에는 그래도 아직 국내에 매물이 많고, 감가상각이 진행 될 대로 되어서 매물을 구하는건 크게 어렵지 않다. 하지만 역시 문제는 차의 상태인데, 위의 사진은 거의 신품이라고 해도 믿을 정도의 극상의 상태로 볼 수 있다.  엔진과 미션 상태, 그리고 잘 정리된 정비 기록만 가지고 있는 차량을 구해서 실내 복원을 저렇게 해 보고 싶다. 

더군다나, 이 차량은 국내에서도 엄청나게 팔린 차종인 데다가 트러블이 발생과 처리에 대해 경험을 가진 미케닉이 많고, 힘들 경우 비싸긴 하지만 그나마 독일 차 중에 가장 잘 정비된 BMW 의 서비스를 이용하는 것이 가능하다. 따라서, E34 와 같이 오래된 차종 보다스크가 좀 덜하기 때문에, 복원 경험을 쌓기 좋은 최선의 선택이 아닐까 한다. 

주말에는 패밀리 세단으로, 주중에는 이른 아침 출근길과 늦은 퇴근을 고속도로로 즐기는 재미를 양껏 안겨줄 수 있지 않겠는가. 

국내에 잘 알려진 카 매니아 사이트 팀 테스트 드라이브의 마스터 권영주님도 작년에 한대 장만 하셨나 보다. 아래의 링크에서 글을 읽어 볼 수 있다. 
http://www.testdrive.or.kr/index.php?mid=boards&page=1&document_srl=1253338

뭐 사실, 저렴한 국산차 사서 마음껏 가지고 다녀도 괜찮긴 하지만, 성격상 기계나 컴퓨팅이나 인과 관계 분석을 통한 문제점 파악과 해결, 뭐 그런 일을 업으로 삼다보니 경제적인 능력만 충분하다면 언제든지 도전해 보고 싶은 것이 바로 이 차량 복원이다. 

돈없어서 타는 구닥다리 차가 아니라, 요즘에 이런 20년 즈음 되어가는 년식의 차량을 공도에서 가지고 다니는 분들이야 말로 진정 갑부가 아닌가 한다. 단순히 유지에만도 적지않은 비용과, 그 비용을 넘어선 관심이 필요한 시기의 차량이기 때문에, 기왕 탈거 그냥 차를 타는 재미만 말고 관리하는 방법, 고쳐가는 방법을 차곡차곡 배운다는 생각, 그리고 취미로 삼으면 이보다 더 좋은게 있을까 싶다. 


이보다 재미있고 돈 덜 드는 일이 많을텐데, 어쩌다가 이런 고약한 것에 마음을 빼앗기게 되었는지 모를일이다. 
아마 조만간, 저 세 대중 한대는 우리집 앞에 오일을 흘리며 주차되어있지 않을까 상상해 본다. 

( younjin.jeong@gmail.com, 정윤진 ) 
저작자표시 비영리
,

Cloud Networking

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


네트워킹에 대한 글은 참 오랜만에 써 보는 것 같다. 사실 그다지 잘 아는 분야도 아니거니와, 일반적인 L3 ip networking 이 거의 대부분의 사용성을 지배하는 한국에서는 너무 당연한 이야기들이 많아서 쓸 것이 없어 그랬지 않았나 싶기도 하다.

오늘 잠깐 생각해 볼 주제는, 클라우드 네트워킹에서 가장 중요한 '확장성'을 고려하게 될 때, 과연 어떻게 망을 구성해야 효과적일까 하는 것이다. 모두들 넌블러킹 스위칭에 대해서 이야기 하고 있지만, 실제 그 넌블러킹의 정체가 무언지, 또 그렇다면 어떤 장비를 어떻게 엮어야 그런 확장성을 이루어 낼 수 있는지에 대해서 디테일하게 이야기 해 보기란 쉽지 않은 일일것이다.

일반적으로 구성하는 ipSAN 또는 스토리지간 연결을 위한 내부 폐쇠망의 구성을 하는데 있어, 최소한 랙 500 대 이상을 확장 할 수 있어야 한다 라는 요구사항이 있을때, 이 구간의 연결 및 IP 정책을 어떻게 만들어 낼 것인가가 아마도 최대의 고민이 될 수 있을 것이다. 경력있는 네트워크 엔지니어는 이러한 경우 내부망을 위한 전용 백본을 구성하고, 이 백본에서 하위 Aggregation 스위치로 MLAG, 다시 ToR ( Top of Rack ) 스위치로의 MLAG 구성을 만드는 것이 일반적인 구성이 될 수 있겠다. 


MLAG ( Multi-chassis Link Aggregation )

 
Image from:  http://www.computer-room-design.com/Arista-Networks-7500-Series-Data-Center-Switch.asp 

흔히 MLAG 이라 불리는 이러한 기술은, 여러대의 스위치를 한대의 스위치로 묶어 L2 레벨의 사용성을 보장한다. 이러한 구성은 최근의 대부분의 벤더가 지원하지만, 특정 벤더별로 상위 스위치로 연결된 2 또는 그 이상의 trunk 된 회선을 동시에 사용하는 이른바 Multi-path 를 지원하거나 지원하지 않는 제품들이 있다. 또한, 이렇게 사용하게 될 때 보통 각 랙별로 별도의 분리된 네트워크를 사용하고자 하는 경우가 많은데, 이럴때 각 ToR 을 위한 VLAN 구성을 추가하게 된다면 이제 각 VLAN 별로 게이트웨이가 되는 IP 를 할당해 주어야 할 텐데, 여기서 또 한번 할당 할 수 있는 IP 수량에 대한 제약 사항이 발생하게 된다.   

이와는 별도로 ToR 의 이중화 구성에 대해서 궁금해 하시는 분들도 있겠지만, 현대의 대부분의 클라우드 시스템들은 랙 하나의 장애에 크게 구애받지 않는다. 따라서 Aggregation 또는 백본의 장애에 대해서만 MLAG 을 구현하고, ToR 은 랙 별로 하나만 두기 때문에 위의 그림에서는 ToR 스위치가 한대다. 물론, 비용을 보다 많이 사용 할 수 있다면 모든 구성에 이중화가 가능하겠다.

아무튼 원래 주제인 MLAG 으로 돌아가서, ToR 에서는 L2, Aggregation 에서 L3 를 구현하는 이러한 방법은 여러모로 확장에 제한을 받게 된다. 물론 이러한 확장의 제한이라는 것이, 보통 샤시 레벨의 제품군을 사용하게 된다면 수백개의 포트 단위까지는 충분히 허용이 가능하므로, 구성하려는 시스템의 규모에 따라 제약사항이 되지 않을 가능성이 있다. 아니, 지금까지는 보통 그래왔다.

게다가 샤시 레벨의 제품을 사용하지 않는 경우에도, Aggregation 의 구성에 Tier 를 적용함으로서 48포트 X 48포트의 구성을 하는 것도 가능하다. 최근의 몇몇 벤더에서는 업링크에 40G 를 지원하는 제품도 있으므로, 이러한 구성시 보다 여유로울 수 있겠다.

얼마 전 까지만 해도 나 역시 이러한 구성이 거의 유일한 해법이며, 넌블러킹 구성에 있어 이보다 좋은 다른 대안이 없는 것으로 생각하고 있었다. MLAG 구성에서 Multi-path 를 지원 할 수 있다면, 현존하는 가장 좋은 내부망 확장 방법이라고 생각 했었다.

 
하지만 최근, 일본의 Midokura ( www.midokura.com )의 Dan 과 Ryu 와 함께 일하게 되면서 새로 배운 것이 있는데, 바로 내부망에 라우팅 프로토콜인 BGP 를 사용하는 방법이다. 

사실 국내에서 네트워크 전문가가 아니라면 생소한 이 프로토콜은, 보통 AS라 불리는 별도의 망 단위간 네트워크에서 라우팅을 위해 사용된다. 국내에서 생소한 이유는, 보통 이 AS가 데이터센터에 입주한 고객에게 별도로 할당되는 경우가 매우 드물고, 따라서 고객이 데이터센터의 ISP 와의 연결에 Static 라우팅을 사용하는 경우가 대부분이기 때문이다. 실제 수년간 필드에서 잔뼈가 굵으신 엔지니어 분들 께서도 BGP 구성에 직접 참여하게 되면 먼지쌓인 책을 다시 살펴봐야 하는 경우가 허다 했다. 

어쨌든 이는 라우팅 프로토콜이기 때문에, 라우터 A 에서 라우터 Z 로 가기 위한 여러개의 경로를 동적으로 할당하는 것이 가능해 진다. 물론 이러한 목적을 위해 BGP 만 존재하는 것은 아니며, RIP, OSPF 등의 수많은 프로토콜이 존재한다. 그런데 왜 여기서 갑자기 BGP를 꺼내들었는가. 그 이유를 살펴 보자. 


1. 최근 데이터 센터 구성에 사용하는 24-48 포트 10G 스위치는 L3 기반인 경우가 많고, 이 L3 스위치들은 BGP 운용이 가능하다. 바꾸어 말하면, 10G 24-48 포트 라우터로 사용 할 수 있다.  

2. iBGP 를 사용하여 Backbone / Aggregation 을 클라우드 망으로 구성할 수 있다. 무슨 이야기인고 하니, 모든 스위치가 라우터로 동작 하므로, 어느 한 지점의 장애에 구애 받지 않게 된다.

3. ECMP 를 사용하여 수없이 발생하게 될 경로에 대한 최대한의 대역폭 사용이 가능해 진다.

4. 장애가 발생한 경우 그 전파가 매우 빠르고, 전체 망이 한꺼번에 다운될 확률이 낮아진다.

5. 각 랙에서 발생하는 L2 통신은 랙 내부로 고립되고, 이 랙에서 돌리는 각 VM의 상태가 백본 레벨로 전달 될 염려가 없다. 랙 장애는 랙 장애에 국한된다.

6. 일단 백본이 구성되고 나면, 어느 경로에든 ToR 을 원하는 형태로 가져다 붙일 수 있다.  따라서 진정한 Scale-out 이 사용 가능한 IP 대역이 떨어질 때 까지 확장 가능하다. 

위의 장점 이외에도, 다른 수많은 장점이 있을 수 있다고 본다. 물론 굳이 iBGP 가 아니라, 각 랙에 사설 AS 를 할당하여 백본과 eBGP를 구성하는 방법도 있을 수 있다. 어떠한 구성의 방법이 더 좋은지의 여부는 네트워크 벤더별로 다를 수 있으며, 경우에 따라 ECMP 를 원활하게 지원하지 않는 경우도 있으니 확인을 꼭 해 볼일이다. 


현재 일을 하고 있는 회사에서 국내에 Arista 를 배포하고 있어, 장비를 가져다가 테스트 해 볼 수 있었다.
테스트 환경은,

- Arista 7124SX   5대
- 일반 Quanta 서버 3대

였으며, 테스트를 위한 컨셉은 다음과 같다. 

iBGP Test Concept



그림은, 각 랙은 서로 다른 24bit 의 네트워크를 가지며, ToR 을 지나는 순간 iBGP 를 사용하여 다른 랙으로 라우팅 된다. 이때 ToR 회서는 각각의 백본에 연결되며, 이 서로 다른 라우팅 Path 에 모두 ECMP 를 적용하게 된다. 

컨셉이 이렇다면, 실제 백본의 할당은 다음과 같다. 

IP Allocation


 
172 네트워크는 관리를 위한 별도의 망이며, 구성된 모든 장치에 연결되어 있다. 실제 트래픽은 푸른색의 회선을 통해 실리게 된다. 이렇게 환경에 대한 구성이 끝났다면, 이제 실제 각 스위치를 설정한다. 

백본은 백본끼리 서로 동일하며, ToR 설정은 각각 모두 동일하기 때문에 샘플로 하나씩만 싣도록 한다.

먼저, Backbone #1 의 설정 
....
...
..
interface Ethernet1
   no switchport
   ip address 10.100.100.18/30
!
interface Ethernet2
!
interface Ethernet3
....
..
!
interface Ethernet22
!
interface Ethernet23
   no switchport
   ip address 10.100.100.1/30
!
interface Ethernet24
   no switchport
   ip address 10.100.100.5/30
!
interface Management1
   ip address 172.17.17.91/24
!
ip route 0.0.0.0/0 Null0 255
!
ip routing
!
router bgp 100
   bgp log-neighbor-changes
   neighbor 10.100.100.2 remote-as 100
   neighbor 10.100.100.2 update-source Ethernet23
   neighbor 10.100.100.2 maximum-routes 12000 
   neighbor 10.100.100.6 remote-as 100
   neighbor 10.100.100.6 update-source Ethernet24
   neighbor 10.100.100.6 maximum-routes 12000 
   neighbor 10.100.100.17 remote-as 100
   neighbor 10.100.100.17 update-source Ethernet1
   neighbor 10.100.100.17 maximum-routes 12000 
   network 0.0.0.0/0
!
management telnet
   no shutdown
!
!
end

이제, ToR #1 의 설정을 살펴보자. 
.....
...
.
vlan 10
!
interface Port-Channel10
   switchport access vlan 10
!
interface Ethernet1
   switchport access vlan 10
   channel-group 10 mode active
!
interface Ethernet2
   switchport access vlan 10
   channel-group 10 mode active
!
interface Ethernet3
   switchport access vlan 10
!
.....
...
..
!
interface Ethernet22
   switchport access vlan 10
!
interface Ethernet23
   no switchport
   ip address 10.100.100.2/30
!
interface Ethernet24
   no switchport
   ip address 10.100.100.14/30
!
interface Management1
   ip address 172.17.17.93/24
!
interface Vlan10
   ip address 10.1.1.254/24
!
ip routing
!
router bgp 100
   bgp log-neighbor-changes
   timers bgp 30 90
   maximum-paths 2 ecmp 2
   neighbor 10.100.100.1 remote-as 100
   neighbor 10.100.100.1 maximum-routes 12000
   neighbor 10.100.100.13 remote-as 100
   neighbor 10.100.100.13 maximum-routes 12000
   network 10.1.1.0/24
!
management telnet
   no shutdown
!
!
end

이렇게 설정하게 되면, 위의 다이어그램과 같이 원하는 대로 망이 동작하게 된다. 아래의 스크린샷은 각 스위치에 sflow 를 걸어두고, 서버 1대에서 다른 2개의 ToR 로 트래픽을 발생 시켰을 때 볼 수 있는 그림이다.

sflow when 2 paths from single server



네트워킹을 전문으로 하시는 분이라면 위의 null0 라우팅 부분을 의아하게 생각 하실 수 있겠다. 이는 이렇게 구성된 망이 폐쇠망이고 외부로 별도의 경로가 없기 때문에, 모든 ToR 에 default 라우팅을 전파하기 위해 별도로 구성된 설정으로 이해 해 주시면 된다. 또한, 경우에 따라 백본에 neighbor x.x.x.x route-reflect-client 를 구성하여 모든 ToR 에 다른 ToR 의 경로를 전파 할 수도 있겠다. 물론 여기서는 어쨌든 백본으로 모든 트래픽을 보내기 때문에, 백본에서 별도로 RR-client 설정을 넣어 주지는 않았다.

ToR 에서 살펴본 ip routing 정보. 
TOR-1#sh ip route 0.0.0.0/0
Codes: C - connected, S - static, K - kernel, 
       O - OSPF, IA - OSPF inter area, E1 - OSPF external type 1,
       E2 - OSPF external type 2, N1 - OSPF NSSA external type 1,
       N2 - OSPF NSSA external type2, B I - iBGP, B E - eBGP,
       R - RIP, A - Aggregate

Gateway of last resort:
 B I    0.0.0.0/0 [200/0] via 10.100.100.1
                          via 10.100.100.13

이러한 스위치가 가지는 장점을 백분 활용함으로서 해 볼 수 있는 것들은 정말로 많이 있다.
기존에는 생각하지 못했던 방법, 보다 스케일링이 가능한 방법. 

네트워크 엔지니어만 알고 있어서 되는게 아니고, 서버 엔지니어라고 해서 네트워크를 모르면 안되는 것과 같은 이치이다. 한 구간만 생각한다면 이러한 룰이 나올 수 있을리 없다고 생각한다. 

최근 클라우드 아키텍팅에서의 트렌드는, 기존의 L2 + L3 구성을 버리고 모두 L3 를 사용하는 방법이다. 위의 설정은 단순히 이러한 구성 및 컨셉을 확인하기 위한 용도에 지나지 않으며, 서비스에 구성하기 위해서는 보다 나은 timer 설정등이 필요하게 될 것이다. 또한, 백본을 다중화 하는 방법도 충분히 실현이 가능하다. 


이 포스팅에 굳이 MLAG 구성의 그림을 넣지 않은 이유는, BGP 의 활용에 대해서 더 살펴보기 위함이었다. 필요하신 분들 께서는 구글에서 MLAG 이라는 검색어만 넣어도 수없이 많이 떠오르는 내용을 보실 수 있을 것이다. 


본 설정을 완료하기 위해 도움을 주신 분들이 계시다. 간단히 소개를 해 보자면, 

Dan Mihai Dumitriu ( CEO/CTO at Midokura )
Nishizawa, Satoshi ( Network expert at Midokura ) 
이정호 차장님 ( Arista Korea )

또한, 고생 해 준 우리 장비들에게도 쌩유. 

Arista 7124SX


 
네트워킹에 고민하고 계신 분들께 조금이나마 도움이 되었으면 하며, 혹시라도 가져가실때는 출처를 남겨 주시길.
조만간 eBGP 도 테스트 해 볼 예정. 

( younjin.jeong@gmail.com, 정윤진 ) 
저작자표시 비영리
,

티스토리툴바