오픈스택 인 액션 - 맛보기 by 한빛미디어

오픈스택 인 액션 상용 수준의 자체 클라우드를 구축하는 단계별 지침

| 표지 설명 | 표지 그림은 “쿠탕스의 우유 짜는 여자(Milkmaid from Coutances)” 그림에서 따온 것이다. 이 그림은 루이 퀴메아Louis Curmer가 많은 예술가의 작품들을 편집해 1841년 출간한 작품집에서 가져왔다. 그 작품집의 이름은 “Les Français peints par eux-mêmes”인데, 번역하면 “스스로 그린 프랑스인”이라는 뜻이다. 모든 그림은 손으로 세밀하게 그려 채색되어 있으며, 이 작품집에 실린 다양한 그림을 보 면 200년 전의 세계의 지역, 도시, 마을, 인근 지역이 서로 문화적으로 얼마나 떨어져 있었는지를 떠올릴 수 있다. 서로 격리된 사람들은 다른 방언과 언어를 사용했다. 거리나 시골길에서 볼 수 있는 그들의 옷차림만으로도 그들이 어디에 살고 어떤 직업이나 신분을 가지고 있는지를 쉽게 알 수 있었다. 그 이후로 옷차림이 점점 바뀌어 갔고, 당시의 풍부했던 지역별 다양성도 사라져버렸다. 이제는 다른 도시나 지역은 말할 것도 없고, 다른 대륙에 사는 사람도 구분하기 어려워졌다. 문화적 다양성을 다채로운 개인의 삶과 바꾼 것일지도 모른다. 다양하고 빠르게 변하는 기술 사회를 살아가는 삶은 분명히 더욱 그러하다. 한 권의 컴퓨터 책을 다른 책과 구분하기 어려운 지금 이 시대에, 매닝은 2세기 전 각 지역의 다양한 삶을 그린 책 표지로 컴퓨터 산업의 창의성과 선도성을 찬미하고자, 이런 작품집의 그림을 다시 세상에 선보이고 있다.

오픈스택 인 액션 : 상용 수준의 자체 클라우드를 구축하는 단계별 지침 초판발행 2016년 10월 1일 지은이 코디 범가드너 / 옮긴이 강재준, 신원석, 오성근, 이준섭, 조영준 / 펴낸이 김태헌 펴낸곳 한빛미디어 (주) / 주소 서울시 마포구 양화로 7길 83 한빛미디어(주) IT출판부 전화 02 – 325 – 5544 / 팩스 02 – 336 – 7124 등록 1999년 6월 24일 제10 – 1779호 / ISBN 978-89-6848-486-5 93000 총괄 전태호 / 책임편집 김창수 / 기획·편집 이복연 디자인 표지·내지 여동일, 조판 이경숙 영업 김형진, 김진불, 조유미 / 마케팅 박상용, 송경석, 변지영 / 제작 박성우, 김정우 이 책에 대한 의견이나 오탈자 및 잘못된 내용에 대한 수정 정보는 한빛미디어(주)의 홈페이지나 아래 이메일로 알려주십시오. 잘못된 책은 구입하신 서점에서 교환해 드립니다. 책값은 뒤표지에 표시되어 있습니다. 한빛미디어 홈페이지 www.hanbit.co.kr / 이메일 ask@hanbit.co.kr

OpenStack in Action by V.K.Cody Bumgardner Original English language edition published by Manning Publications. USA. Copyright © 2015 by Manning Publications Co. Korean language edition copyright © 2016 by HANBIT Media Inc. All rights reserved. 이 책의 한국어판 저작권은 대니홍 에이전시를 통한 저작권사와의 독점 계약으로 한빛미디어(주)에 있습니다. 저작권법에 의해 한국 내에서 보호를 받는 저작물이므로 무단전재와 복제를 금합니다.

지금 하지 않으면 할 수 없는 일이 있습니다. 책으로 펴내고 싶은 아이디어나 원고를 메일 (writer@hanbit.co.kr) 로 보내주세요. 한빛미디어(주)는 여러분의 소중한 경험과 지식을 기다리고 있습니다.

오픈스택 인 액션 상용 수준의 자체 클라우드를 구축하는 단계별 지침

지은이•옮긴이 소개

지은이

코디 범가드너 Cody Bumgardner http://codybum.com

IT 산업에서 20년 넘게 IT 아키텍처, 소프트웨어 개발, 네트워크, 연구, 시스템, 보안 분야에서 기 술, 경영, 영업을 담당했다. 지난 몇 년은 클라우드 컴퓨팅과 전산 경제학을 집중적으로 연구하고, 구현하고, 강의했다. 현재는 영국 켄터키 대학교에서 컴퓨터 과학 박사 과정을 밟고 있으며, 전산 경제학과 분산 자원 관리에 집중하고 있다. 또한 캔터키 대학교의 최고 기술 아키텍트Chief Technology Architect를

역임하며 클라우드 컴퓨팅 5개년 중장기 전략과 로드맵을 수립했다. 이 로드맵은 혁신적

인 클라우드 기술의 도입 및 관련 IT 인력 구성의 변화를 서술한다. 그 계획은 학술, 연구, 건강 관 리 분야에 종사하는 40,000명 이상의 사용자를 지원하기 위한 오픈스택 사설 클라우드를 배포하는 것이 주요 내용이다. 코디는 그 중 오픈스택 사설 클라우드, 연구용 컴퓨터, 기타 클라우드 컴퓨팅 계획의 아키텍처, 재정 모델, 배포, 장기 전략을 담당하고 있다.

옮긴이

강재준, 신원석, 오성근, 이준섭, 조영준

옮긴이들은 SK텔레콤에서 길게는 10년 이상 네트워크 시스템과 IT 인프라를 구축, 관리, 운용하는 업무를 담당해오고 있다. 2G/3G/LTE 통신 인프라 및 연동 시스템을 운용해왔으며, 현재는 가상화 기반의 통신 인프라 구축/운용 및 다양한 고객 서비스를 제공하는 업무를 수행 중이다.

VMware, 오픈스택 등의 솔루션을 기반으로 각종 서비스를 제공하고 있고, 작년에는 국내 최초로 가상화 기반의 LTE 코어 시스템(NFV, Network Function Virtualization )을 상용화해 운용 중이 다. 가상화 기술 기반의 통신망 상용화 프로젝트를 계속 추진하고 있으며, 효율적인 데이터센터 인 프라 관리를 위한 자동화 체계도 지속적으로 구축하고 있다. 『VMWare vSphere 6 서버 가상화 구축과 운용』(에이콘출판사, 2015 )을 번역했다.

추천의 글

노바 프로젝트의 원본 소스 코드를 살펴본 지 벌써 5년이 지났다는 것이 믿기지 않는다. 그 코드는 안소Anso 연구팀이 NASA를 위해 만들어 발표했다. 그 당시 내가 일했던 랙스페이스Rackplace는 랙스 페이스 클라우드의 차세대 동력이 될 새로운 코드를 찾고 있었다. 몇 달 후, 랙스페이스 클라우드 파 일 플랫폼의 코드를 스위프트Swift라는 오픈 소스 프로젝트로 공개했다. 이렇게 노바와 스위프트는 초기 오픈스택 프로젝트의 토대가 되었다. 그 이후로, 두 프로젝트는 상당한 변화를 겪어왔다. 많은 기능이 추가되고 성능과 확장성 면에서 많 은 개선이 이루어졌지만, 스위프트의 핵심 개발팀과 코드는 놀랍게도 그대로 남아 있다. 반면에 노 바의 소스 코드는 미약하게 시작한 것에 비해 거의 알아보지도 못할 정도로 많이 변했다. 글랜스, 신 더, 키스톤 그리고 뉴트론 같은 새로운 코드는 원래는 노바가 처리했던 기능을 제공하도록 만들어 졌다. 대규모 컴퓨팅 인프라 관리에 필수적인 기능을 처리하기 위해 이러한 새로운 소스 코드가 등장한 것 과 동시에 새로운 유형의 오픈 소스 커뮤니티가 형성되기 시작했다. 운영체제 배포와 패키징, 구성 관리, 데이터베이스 설계, 자동화, 네트워크, 스토리지 시스템에 경험이 있는 오픈 소스 개발자와 지지자들이 오픈스택 프로젝트에 기여하기 위해 모여들었다. 오픈스택 커뮤니티는 정신없이 빠른 속도로 성장했고(지금도 계속 성장하고 있다) 지구상에서 가 장 크고, 활발하고, 영향력 있는 오픈 소스 커뮤니티 중 하나가 되었다. 이러한 성공적인 커뮤니티 성장의 발판이 된 과제들을 관리하기 위해 오픈스택 재단이 만들어졌다. 설계 서밋summit과 컨퍼런스 에 전 세계에서 매년 3,500명이 넘는 기여자가 모일 정도로 그 규모가 커졌다. 커뮤니티는 소스 코드의 개발과 기여자 수의 엄청난 성장을 뒷받침하기 위해 세계적 수준의 통합 구 축 시스템을 만들었다. 현재 이 자동화 구축 시스템의 규모와 범위는 아파치나 이클립스 재단과 같 은 훨씬 오래된 오픈 소스 커뮤니티에 필적하거나 뛰어넘는 수준이다. 오픈스택 생태계는 스위프트스택SwiftStack과 피스톤 클라우드Piston Cloud 등의 신생 기업이 생겨나는 밑 거름이 되었다. HP, 미란티스Mirantis, 레드햇Red Hat 등의 기존 기업들은 오픈스택이 수익 모델이 될

수 있다고 판단하고, 오픈스택 커뮤니티의 빅 텐트big tent를 구성하는 많은 프로젝트에서 지속적으로 혁신을 이끌고 있다. 이러한 오픈스택 커뮤니티의 확장으로 인해 분산 소프트웨어 구성요소를 배포하는 방법과 상호 동 작하는 방식은 엄청나게 복잡해졌다. 오픈스택을 “백지에서” 배포하려면 네트워크와 스토리지는 물 론이고 가상화와 구성 관리까지 아우르는 전반적인 개념을 이해해야 한다. 필요한 지식과 기술을 얻 는 것은 오픈스택을 사용해 클라우드 플랫폼을 만들고 싶은 사람들이 직면하는 주요 도전 과제다. 『오픈스택 인 액션』은 독자들에게 오픈스택을 배포하고 실행하기 위해 필요한 지식을 제공한다. 저자는 복잡한 오픈스택 배포 방법을 설명하기 위해, 소프트웨어를 배포하는 세 가지 방식으로 스크 립트 방식의 데브스택DevStack, 운영체제 패키지의 수동 설치, 퓨얼Fuel 오픈스택 인스톨러를 사용한 다. 각 절에서는 네트워크와 스토리지 설정에 대한 개념을 전반적으로 설명한다. 이를 통해 독자들 은 점차 클라우드 컴퓨팅 속으로 발을 내디딜 수 있고, 이 책의 마지막쯤에는 깊은 곳까지 편하게 들 어갈 수 있을 것이다. 오픈스택 기술에 대한 뛰어난 설명 외에도, 저자는 클라우드 컴퓨팅에서 얻을 수 있는 혜택을 평가 하는 방법 또한 설명한다. 클라우드는 많은 조직에서 시간을 들여 수작업으로 처리해야 하는 문제를 마법처럼 해결해주지는 않는다. 그러나 클라우드는 효과적으로 잘 구현하면 IT 조직을 변화시키고 그들이 제공하는 서비스를 급격히 개선할 수 있다. 9장에서 저자는 가상화되어 있는 기존의 IT 인 프라를 오픈스택으로 교체하거나 내부 고객을 위한 새 사설 클라우드를 구축하려는 모든 IT 관리자 가 반드시 읽어봐야 하는 주제에 대해 이야기한다. 간단히 말해, 『오픈스택 인 액션』은 복잡한 클라우드 컴퓨팅과 오픈스택 소프트웨어 생태계에 대한 훌륭한 입문서 역할을 한다. 읽고 자신의 것으로 만들어 “스태커Stacker”가 되어보자! 오픈스택 기술 위원, 미란티스 공학 이사_ 제이 파이프스Jay Pipes

옮긴이의 말

이 책의 독자라면 클라우드 환경에 가장 적합한 기술로 주목받고 있는 오픈스택에 분명히 관심이 있 을 것이다. 2012년 오픈스택 재단이 출범한 이후, 점점 더 많은 기업이 오픈스택 기술의 발전에 동 참하고 있다. 오픈스택에는 현재 178개국에서 345개 기업이 참여하고 있으며, 그 소스 코드도 3백

5십만 라인에 이른다고 한다. 오픈스택의 사용자층도 점점 확대되고 있으며, IT 업계뿐 아니라 자 동차, 엔터테인먼트, 금융 업계에서도 속속 오픈스택 기술을 도입하고 있다. 클라우드스택CloudStack, 유칼립투스Eucalyptus 등의 경쟁 기술이 있었지만, 현재는 확장성과 모듈화를 바탕으로 제조사 및 개 발자 주도하에 급성장한 오픈스택이 대세로 떠오르는 추세다. 오픈스택 재단은 매년 새로운 버전을 두 차례 출시한다. 버전명 첫 글자는 알파벳 순서로 결정되는 데, 2010년 첫 번째 버전인 ‘오스틴Austin’부터 시작해 2014년에는 이 책에서 예제로 활용하는 ‘아이 스하우스Icehouse’가, 2015년에는 ‘킬로Kilo’와 ‘리버티Liberty’ 그리고 2016년 현재는 ‘미타카Mitaka’까지 출시되었다. 초창기에서 컴퓨트 기술을 중심으로 프로젝트가 진행되었고, 그 이후 스토리지와 네트 워크 기술과 관련한 프로젝트를 강화해오고 있다. 오픈스택의 가장 큰 장점은 오픈 소스 형태로 누구나 참여할 수 있는 개방성과 가상화 기반 자원들 을 바탕으로 다양한 인프라/서비스를 제공하는 모듈성이다. 이를 오픈스택 재단에서는 개별적인 프 로젝트로 관리하고 있으며, 프로젝트마다 고유 이름과 관련 구성요소가 존재한다. 현재 많은 주목 을 받는 IT 기술인 컨테이너 기술, 네트워크 가상화(소프트웨어 정의 네트워크) 등도 오픈스택의 이런 개방성과 모듈성 덕분에 함께 발전하고 있다. 이 책은 앞서 이야기한 가상화 기반 자원들을 가지고 컴퓨트, 스토리지, 네트워크 등 오픈스택 핵 심 구성요소를 제공하는 환경을 직접 배포해보면서 프레임워크를 이해하도록 구성되어 있다. 필요 에 따라 사용할 수 있는 다양한 배포 방식이 존재하며, 오픈스택을 간단하게 맛보고 싶다면 쉽게 배 포할 수 있는 데브스택Devstack을 설치해볼 수 있다. 오픈스택 각 구성요소의 기능과 서로 간의 상 호작용을 이해하기 위해서는 수동으로 모든 단계를 직접 설치해보는 것도 좋다. 또한 기업 환경에 서 상용 수준의 클라우드를 관리한다면 더 효율적이고 안정적인 자동화 도구를 사용해서 배포하는

방법을 익혀둘 필요가 있다. 이 책은 위의 모든 배포 방식을 설명하면서 초보자부터 고급 관리자 수 준까지 아우를 수 있도록 구성되어 있다. 실제로 이런 다양한 배포 방식으로 오픈스택을 스스로 구 성해보기란 쉽지 않다. 클라우드 관리자나 개발자, 설계자는 이 책을 통해서 매우 귀중한 경험을 해 볼 수 있을 것이다. 저자 서문에서 더 상세한 흐름을 알 수 있겠지만, 이 책에서는 오픈스택을 이해하고, 배포하고, 구 성요소를 설정하고, 오픈스택을 더욱 잘 활용하기 위한 다양한 솔루션을 접할 수 있다. 적절한 그림 과 명령어 수준까지 제공하는 예제들이 오픈스택을 구체적으로 이해하는 데 큰 도움을 줄 것이다. 순서대로 읽을 필요는 없지만, 1부는 오픈스택에 대한 기본적인 이해를 도와주고, 2부는 오픈스택 환경에 대해 더 깊게 들여다보고, 3부는 상용 환경에서 사용하는 솔루션 등을 소개한다. 이 책을 다 읽게 되면 주요 서비스 구성요소를 구성하는 방법과 이들이 서로 상호작용하는 방식을 이해하게 될 것이다. 또한 이에 대한 다양한 기반 기술(네임스페이스, OVS, LVM 등)도 언급하면서, 고급 IT 기술을 처음 접하는 독자의 이해를 돕는 실마리도 제공하고 있다. 옮긴이들 또한 KVM과 오픈스택 기반의 가상화 인프라를 직접 구축/관리해오면서 기술적인 도움 과 구조적인 지식이 필요한 상황에 자주 부딪혀왔고, 그때마다 오픈스택 공식 홈페이지, 국내외 블 로그, 읽기 어려운 해외 사이트들을 찾아다니며 문제를 해결해왔다. 그러던 중 오픈스택의 기본적인 이해뿐만 아니라 상세한 구조와 상호작용까지 체계적으로 배울 수 있는 『오픈스택 인 액션』을 번역할 기회를 얻게 되었다. 이 책은 매닝의 유명한 다른 『인 액션』 시리즈와 마찬가지로 어느 정도의 기본 지식이 필요하지만, 초보자부터 고급자까지 누구나 직접 실습해보며 익힐 수 있도록 구성되었다. 번역하기 까다로운 부분들은 더욱 쉽게 읽을 수 있도록 저자의 의도를 해치지 않는 선에서 의역하기 도 하였지만, 독자들에게 더 쉽게 전달하지 못한 점이 있을까 아쉬움이 남는다. 다음은 번역 용어나 번역 규칙 등에 대한 몇 가지 참고 사항이며, 이 책을 읽기 전에 미리 알아두는 것이 도움이 될 것이다.

오픈스택 프로젝트명과 버전명은 읽기 쉽게 하기 위해 한글로 표기했다.

●●

오픈스택 자체적으로 사용되는 다양한 용어들(tenant, quota, user role 등)은 이해에 무리가 없는 수준에

●●

서 한글로 번역 표기하였으며, 메뉴나 스크린샷, 명령줄 등은 영문 버전 그대로 표기했다. 이 책은 우분투 14.04 기반의 오픈스택 아이스하우스 버전을 사용하여 예제를 설명하고 있다. 최신 버전과는

●●

일부 메뉴 구성이나 클라이언트 명령어 체계가 다를 수 있다. 그렇더라도 오픈스택 고유의 동작과 내부 구조를 이해하는 데는 전혀 문제가 없으며, 단지 버전상의 차이로 인한 UI나 명령어의 차이 정도만 고려하면 된다.

옮긴이들의 노력에도 불구하고, 여전히 누락되거나 잘못된 부분이 있을 수도 있으므로 추가로 확인 되는 오류나 독자들의 제보를 반영해 한빛미디어 도서정보 페이지를 통해 정오표를 제공할 것이다. 이제는 다른 팀에서 일하고 있지만 각자의 자리에서 최선을 다하고 있는 동료들께 항상 감사를 드린 다. 더욱이 이 책이 출간되기까지 적극적인 관심과 지원을 해주신 본부장 및 팀장님께도 감사를 드 린다. 마지막으로 번역 과정에서 항상 친절한 안내와 상세한 조언을 해주신 한빛미디어 관계자분들 께도 감사의 말씀을 전한다. 아무쪼록 이 책이 여전히 열악한 국내 가상화 및 IT 환경에서 고군분투하는 많은 관리자와 개발자 들에게 좋은 지침서가 되길 바란다.

지은이의 말

내가 처음으로 오픈스택을 접한 때는 켄터키 대학교에서 일하던 2011년 여름이었다. 동료이자 친 구인 브렌트 솔즈베리Brent Salisbury와 나는 제품 개발 프로젝트를 논의하기 위해 포춘 50대 기술 회사 와의 회의에 참석했다. 회의 동안 그 프로젝트의 담당 임원은 기존의 상용 도구를 가지고 일하는 것 과 오픈스택이라는 커뮤니티 프로젝트를 연구하는 것 중 하나를 선택하도록 제안했다. 당연히 우리 는 그 미지의 프레임워크로 일하는 쪽을 선택했고, 그렇게 해서 우리의 오픈스택 여정은 시작되었 다. 제품 개발 프로젝트는 무산되었지만 나중에 알고 보니 오픈스택과의 만남은 우리의 전문 분야, 학문, 경력에 큰 전환점이 되었다. 브렌트는 학교를 떠나 나중에 도커Docker에 매각된 스타트업을 공 동 창립했으며, 지금도 도커에서 일하고 있다. 반면에 나는 석사 과정을 거쳐 박사 과정으로 진학했 고 이 책을 쓰게 되었다.

2013년 초, 오픈스택 그리즐리Grizzly 버전은 현재 버전과 어느 정도 유사하긴 했지만, 급하게 개발 된 기능들이 불안정해 기업 환경에서는 상용으로 사용할 수 없었다. 기업용 오픈스택에 내 모든 것 을 걸지는 않았지만 연구용 컴퓨터는 전혀 다른 이야기다. 대학원 독립 연구 과정의 일환으로, 나는 연구용 컴퓨터에서 오픈스택을 사용하는 것에 대한 사용 사례, 아키텍처, 전략을 주제로 한 논문을 썼다. 추가로 오픈스택을 기업용 사설 클라우드 플랫폼으로 채택하는 절차도 서술했다. 나는 학술 보고서에서 [그림 0]을 사용해 구성요소별로 분산된 오픈스택을 표현했다. 코끼리를 먹을 때도 마찬가지지만 코끼리를 요리할 때도 한 번에 한 조각씩 요리해야 한다. 기술 분야에서는 “나는 스토리지 담당자야” 또는 “나는 네트워크 담당자야”라고 하면서 기술적인 고립을 당연한 것으로 받 아들이는 관례가 있는데, 이는 코끼리의 한 부분만 먹는 사람에게는 가장 중요한 가치일 수도 있다. 이 책에서 나는 코끼리를 더 쉽게 소화할 수 있도록, 알아볼 수 있을 정도로 작은 조각으로 나누어 이를 새로운 개념과 섞어보려고 노력했다. 코끼리 발을 맛보고 싶지는 않겠지만, 클라우드 컴퓨팅 을 성공적으로 도입하고 싶다면 최소한 이론적으로라도 코끼리 발이 어떻게 움직이는지는 알아두는 게 좋다.

그림 0 이 그림은 마에스트로 마르티노Maestro Martino의 16세기 저서 『요리의 예술Libro de Arte Coquinaria』의 판본에 실려 있다.

나는 이 서문을 매닝의 편집자와 처음 이야기를 나눈 지 정확히 2년 만에 쓰고 있다. 이 프로젝트를 시작했을 때는 오픈스택 기여자가 500명이 채 안 되었는데 이제는 수천 명이 되었다. 오픈스택은 가장 빠르게 성장하는 오픈 소스 커뮤니티 중 하나가 되었을 뿐 아니라 세계에서 가장 큰 여러 조직 에서 채택하고 있다. 더 중요한 것으로, 오픈스택은 이제 성숙 단계로 접어들어 사설 클라우드를 위 한 기반 역할을 할 준비가 되었다.

이 책에 관하여

이 책의 주요 주제는 오픈스택을 사용해 기업의 사설 클라우드를 배포하는 것이다. 이런 맥락에서 사설 클라우드를 인프라 자원의 풀 또는 조직이 소유하고 관리하는 IaaSInfrastructure as a Service로 볼 수 있다. 이와 반대로, 공용 클라우드 IaaS 자원은 외부 서비스 제공자가 소유하고 운영한다. 재정적인 면에서 사설 클라우드는 일반적으로 자본 비용인 반면에, 공용 클라우드는 대개 운영 비용 으로 볼 수 있다. 사설 클라우드 환경에서 기업들은 일반적으로 실제 사용 여부와 관계없이 고정 인 프라를 구매하거나 일정 기간 동안 대여한다는 점을 고려하면 이 구분은 이해하기 쉽다. 공용 클라 우드에서 비용은 일반적으로 시간당 사용량 및 통신 비용과 직접적인 관계가 있다. 기업이 사설 클라우드를 선택할지 공용 클라우드를 선택할지는 보통 그 기업의 IT 업무의 규모나 범위와 관련이 있다. 기술적인 구조와 자원을 다른 부서에 제공해야 하는 중앙 IT 부서는 보통 사설 클라우드를 활용하는 데 관심이 있다. 다중 테넌트multi-tenant를 지원하고 완전히 조직화된 사설 클라 우드는 기업의 IT 자원 관리의 효율성을 크게 높여준다. 이러한 면에서 기업의 IT 부서는 클라우드 중개자가 될 수 있다. 이와 반대로 부서별 IT 조직은 대개 비용 효율적으로 사설 클라우드를 배포할 수 있는 데이터센터 시설과 인력을 보유하고 있지 않다. 부서별 IT 조직은 비교적 적은 자원만 필요 로 하기 때문에 종종 공용 클라우드 자원을 이용할 수 있다. 가능한 경우에는 기업의 IT 부서가 관 리하는 사설 클라우드 자원을 사용할 수도 있다. 작업 부하에 따라 사설과 공용 클라우드를 함께 사 용하면 이를 하이브리드 클라우드라고 한다. 클라우드와 이를 활용하는 조직의 유형은 다를지라도, 클라우드 자체는 동일한 기술을 사용해 구축 할 수 있다. 반면, 클라우드 자원을 구성하는 재료는 동일할 수 있지만, 그 조리법과 사용 방법은 매 우 다를 수 있다. 오픈스택은 사설 및 공용 클라우드 모두를 구성하기 위한 강력한 프레임워크를 제공한다. 기본적으 로 오픈스택은 클라우드를 구축할 때 사용하는 하드웨어와 소프트웨어를 위한 공통 API를 추상화 해 제공한다. 오픈스택 프레임워크는 매우 중요한 다음의 두 가지 기능을 제공한다.

특정 구성요소의 제조사 종속을 방지하는 하드웨어 및 소프트웨어 자원의 추상화

●●

연결 구성요소를 완전히 오케스트레이션할 수 있는 여러 자원 간의 공통 API

●●

첫 번째 기능은 경제적인 면에서 좋고 두 번째는 현대 IT 변혁의 핵심이다. 오픈스택은 기업의 IT를 위해 클라우드 배포 환경에 혁신적인 수준의 효율성을 가져다줄 수 있다.

왜 『오픈스택 인 액션』인가? 이 책은 컴퓨팅 자원의 클라우드를 구축하기 위한 단계별 상향식 가이드를 제공한다는 목적으로 계 획되었다. 예상 독자는 오픈스택 환경 배포에 관심이 있는 연구원, 관리자, 학생이다. 기본적인 리눅 스 작업 방법만 알고 있으면 어떠한 기술적인 사전 요구사항도 없고, 매우 다른 배경과 기술력을 가 졌더라도 누구나 쉽게 이해할 수 있도록 만들었다. 이처럼 오픈스택은 많은 사례에서 적합하다. 오픈스택 프레임워크를 활용하는 사례는 다양하지만 사설 클라우드의 요구사항과 설계는 서비스 제 공자마다 매우 다를 수 있다. 기업은 조직 내부에 자체 보유한 사설 자원들을 묶은 클라우드를 제공 하는 데 관심이 있다. 이런 사설 클라우드는 추가적인 서비스를 제공하지는 않는다. 하지만 조직이 컴퓨팅 자원을 제공하는 방식을 변화시킬 수는 있다. 이 책은 다음과 같은 내용을 담고 있다. 단일 노드 개발 환경에서 오픈스택을 자동 배포하는 방법

●●

다중 노드 환경에서 오픈스택을 단계적으로 수동 배포하는 방법

●●

IT 운영 관점에서 사설 클라우드 기술(오픈스택, 세프, 주주 등)이 주는 혜택

●●

제조사가 제공하는 자동 배포 및 관리 도구를 사용한 상용 오픈스택 환경 배포

●●

이 책에서 다루는 아키텍처는 소규모(노드 5개 정도)에서 대규모(노드 100개 이상)까지 기업 사 설 클라우드 배포 환경에 적합하다. 또한, 12장에서는 오픈스택 히트Heat나 우분투 주주Ubuntu Juju와 같은 애플리케이션 오케스트레이션 도구를 사용하는 방법을 살펴볼 것이다. 이 책은 사설 클라우드 기술과 그 기술을 배포하고 운영하는 방법과 더불어 클라우드 오케스트레이

션이 전통적인 IT에 미치는 장기적인 영향을 이해할 수 있도록 꾸몄다. 이 책은 독자들의 회사에 오 픈스택 사설 클라우드를 배포하도록 설득력 있는 주장을 할 수 있게 해주고, 사설 클라우드를 배포 할 수 있는 기술 지식을 습득하는 데 도움을 줄 것이다. 알아두어야 할 가장 중요한 것은 오픈스택 사설 클라우드가 단순히 또 다른 가상화 도구는 아니라는 점이다. 오픈스택은 기존의 가상화 도구를 활용해 클라우드를 구축하고 관리하기 위한 하나의 프레 임워크다. 독자들은 클라우드를 구축하고 관리하고 조직화하는 방법을 배울 수 있을 것이다. 기술 적인 면에서는 오픈스택의 구성요소와 이를 뒷받침해주는 기술, 특히 오픈스택 컴퓨트, 네트워크, 블록 스토리지, 대시보드, API 구성요소를 이해할 수 있을 것이다.

이 책의 구성 이 책은 3부로 구성되어 있다. 1부(1~4장)에서 오픈스택을 처음 만나고, 2부(5~8장)에서는 오 픈스택 생태계를 깊이 들여다보고, 마지막 3부(9~12장)에서는 상용 환경에서 오픈스택을 사용할 준비를 할 것이다.

1장은 오픈스택 클라우드 운영체제, 오픈스택 프레임워크의 개발 목적, 오픈스택이 할 수 있는 것을 소개한다.

2장에서는 간이 배포 도구와 최소한의 인프라를 사용해 오픈스택을 체험해볼 것이다. 또한 오픈스 택 대시보드 UXUser eXperience를 보여주고 오픈스택 프레임워크를 학습하면서 사용하는 일반적인 작 업 방법을 알려줄 것이다. 마지막에는 직접 만든 오픈스택 환경에서 가상 머신을 프로비저닝해볼 것 이다.

3장은 2장에서 구성한 환경을 사용해 오픈스택 명령줄 인터페이스(CLI )를 소개한다. 새 테넌트(프 로젝트), 사용자, 역할, 내부 네트워크를 만들어보면서 기본 오픈스택 작업 방법을 살펴볼 것이다.

4장에서는 오픈스택을 사용하는 방법부터 시작해 구성요소별 기능과 전체 오픈스택 프레임워크 내 에서의 서로 간의 상호작용을 살펴볼 것이다. 오픈스택을 다중 노드 환경에 배포하기 위한 준비 과

정으로 몇 가지 클라우드 설계 방법도 둘러본다. 이 장은 오픈스택 구성요소들이 함께 맞물려 돌아 가는 방식과 제조사 자원과의 관계를 다룬다.

5~8장은 주요 프로젝트마다 하나의 장씩 할애해 개별 오픈스택 프로젝트를 자세히 다룬다. 또한 다중 노드 환경에서 오픈스택을 수동 배포하는 방법을 안내할 것이다. 이를 통해 오픈스택 생태계에 서 각 구성요소가 동작하는 방법과 원리를 이해할 수 있을 것이다. 추가로 수동 배포를 직접 해보면 서 문제 해결 경험도 얻을 수 있을 것이다.

9장은 상용 오픈스택 배포와 관련한 설계, 구조, 전략을 결정하는 방법을 다룬다. 10장에서는 세프 Ceph

스토리지의 기본적인 배포와 작업 방법을 다룬다. 11장에서는 퓨얼Fuel을 이용한 고가용성 오픈

스택 자동 배포 방법을 살펴볼 것이다. 마지막으로, 12장은 오픈스택 히트와 우분투 주주를 이용한 클라우드 오케스트레이션 방법을 다룬다.

누가 이 책을 읽어야 하는가? 이 책은 오픈스택을 사용해 사설 클라우드 환경을 배포하는 데 관심이 있는 인프라 전문가, 엔지니 어, 아키텍트, 지원 인력에 적합하다. 경영진과 전략적 역할을 하는 사람에게도 가치가 있지만, 전 체적인 내용은 기술 분야의 독자에게 맞춰져 있다. 기본적인 리눅스 지식 외에는 어떠한 기술적인 사전 지식도 필요하지 않다.

예제 소스 내려받기 이 책의 예제 소스는 아래에서 내려받을 수 있다. https ://github.com/codybum/OpenStackInAction

●●

http ://www.hanbit.co.kr/exam/2486

●●

감사의 말 이 책은 나의 박사 과정 지도 교수이자 친구인 빅터 W. 마렉Victor W. Marek의 도움이 없었다면 존재할 수 없었을 것이다. 항상 힘이 되어준 그의 격려와 믿음에 꼭 보답하고 싶다. 내가 이번에 직접 책을 만드는 경험을 하지 못했다면 그 과정에서 드는 노력은 결코 상상하지도 못했을 것이다. 이런 노력의 결과가 결실을 맺을지 여부는 독자가 결정하겠지만, 여러 비평가, 편집 자, 기고자 분들이 좋은 품질의 책을 위해 들인 시간과 노력은 의심할 여지가 없다. 이 책을 쓰면서 다른 출판사의 여러 책에 기고도 하고 리뷰도 해보았지만, 매닝은 가능한 한 최고의 작품을 만들어 내기 위해 최선을 다하고 있다고 자신 있게 말할 수 있다. 특히, 지속적으로 개선을 추진하면서 이 책의 대부분을 담당한 개발 편집자인 수잔 코넌트의 지칠 줄 모르는 작업에 고마움을 전하고 싶다. 또한 발행자인 마쟌 베이스를 비롯해 메리 피어지스, 신시아 케인, 앤디 캐롤, 케이티 테넌트 외에 도 보이지 않는 곳에서 일하는 많은 분과 편집팀 및 제작팀의 모든 분께 감사를 드린다. 이 책을 만 드는 동안 기술 편집을 해준 빌 브런스, 앤디 힐, 마이클 키드, 제프 림, 파브리치오 소펠사에게도 많은 감사를 드린다. 마지막으로, 이 책의 원고를 읽고 많은 제안을 해준 앤디 키르슈, 크리스 스노 우, 페르난도 로드리게스, 하피주르 라만, 제프 림, 코즈마스 차치미샬리스, 맷 하팅, 마유르 파틸, 마이클 함라, 피유시 마하시, 토비 라자르 모두에게 감사드린다. 우리 두 아이를 돌보면서 나의 출장, 졸업, 이 책, 그리고 다른 작업까지도 뒷바라지해주기 위해 맡 은 몫보다 훨씬 많은 것을 해준 나의 아내 새라에게 특별한 감사를 전한다. 비록 논문과 발표 자료와 책에는 내 이름이 적혀 있지만, 우리 가족이 함께 사용하는 성(姓)도 언제나 그 안에 남아 있을 것 이다. 새라! 시드니! 잭! 함께 보내지 못한 시간과 활동에 대해 미안! 내가 우리 가족을 자랑스러워 하는 것처럼 우리 가족도 나를 자랑스러워 하길 바란다. 우리 가족 모두를 사랑한다.

CONTENTS

PART

지은이·옮긴이 소개 ................................................................................................

추천의 글 ................................................................................................................

옮긴이의 말 .............................................................................................................

지은이의 말 ...........................................................................................................

이 책에 대하여 .......................................................................................................

I 시작하기

CHAPTER

1 오픈스택 소개 1.1 오픈스택이란? ........................................................................................................... 32 1.2 클라우드 컴퓨팅과 오픈스택 이해하기 ............................................................................ 36 1.2.1 추상화와 오픈스택 API ...................................................................................... 37

1.3 오픈스택과 오픈스택이 제어하는 컴퓨터 자원과의 관계 ..................................................... 38 1.3.1 오픈스택과 하이퍼바이저 .................................................................................... 39 1.3.2 오픈스택과 네트워크 서비스 ................................................................................ 42 1.3.3 오픈스택과 스토리지 ......................................................................................... 43 1.3.4 오픈스택과 클라우드 용어 ................................................................................... 46

1.4 오픈스택 구성요소 소개 ............................................................................................... 47 1.5 오픈스택의 역사 ......................................................................................................... 48 1.6 요약 ......................................................................................................................... 49

CONTENTS

CHAPTER

2 오픈스택 맛보기 2.1 데브스택이란 무엇인가? .............................................................................................. 52 2.2 데브스택 배포하기 ...................................................................................................... 54 2.2.1 서버 생성하기 .................................................................................................. 57 2.2.2 서버 환경 준비하기 ........................................................................................... 58 2.2.3 데브스택 준비하기 ............................................................................................ 60 2.2.4 데브스택 실행하기 ............................................................................................ 62

2.3 오픈스택 대시보드 사용하기 ......................................................................................... 72 2.3.1 [Overview] 화면 .............................................................................................. 74 2.3.2 [Access & Security] 화면 ................................................................................. 75 2.3.3 [Images & Snapshots] 화면 ............................................................................. 79 2.3.4 [Volumes] 화면 ............................................................................................... 84 2.3.5 [Instances] 화면 .............................................................................................. 86

2.4 첫 번째 사설 클라우드 서버에 접속하기 .......................................................................... 91 2.4.1 인스턴스에 유동 IP 할당하기 .............................................................................. 92 2.4.2 유동 IP에 네트워크 트래픽 허용하기 ..................................................................... 93

2.5 요약 ......................................................................................................................... 94

CHAPTER

3 오픈스택 기본 작업 방법 3.1 오픈스택 CLI 사용하기 ............................................................................................... 96 3.2 오픈스택 API 사용하기 ............................................................................................... 99 3.3 테넌트 모델 운용 ...................................................................................................... 101 3.3.1 테넌트 모델 ................................................................................................... 101 3.3.2 테넌트, 사용자, 역할 생성하기 ........................................................................... 104 3.3.3 테넌트 네트워크 ............................................................................................. 109

3.4 할당량(Quota) ......................................................................................................... 127 3.4.1 테넌트 할당량 ................................................................................................ 128 3.4.2 테넌트 사용자 할당량 . ..................................................................................... 130 3.4.3 기타 할당량 ................................................................................................... 132

3.5 요약 ....................................................................................................................... 134

CHAPTER

4 사설 클라우드 구성요소 이해하기 4.1 오픈스택 구성요소에는 어떤 관계가 있는가? ................................................................. 136 4.1.1 구성요소 간 통신 이해하기 ................................................................................ 136 4.1.2 분산 컴퓨팅 모델 ............................................................................................ 143

4.2 오픈스택은 제조사 기술과 어떤 관련이 있는가? ............................................................. 148 4.2.1 오픈스택에서 제조사 스토리지 시스템 사용하기 .................................................... 149 4.2.2 오픈스택에서 제조사 네트워크 시스템 사용하기 .................................................... 154

4.3 수동 배포는 왜 해보는가? .......................................................................................... 164 4.4 요약 ....................................................................................................................... 164

PART

II 오픈스택 수동 배포하기

CHAPTER

5 컨트롤러 배포하기 5.1 컨트롤러의 사전 준비 사항 배포하기 ............................................................................ 169 5.1.1 환경 준비하기 ................................................................................................ 170 5.1.2 네트워크 인터페이스 구성하기 ........................................................................... 171 5.1.3 패키지 갱신하기 ............................................................................................. 175 5.1.4 의존 소프트웨어 설치하기 ................................................................................. 176

CONTENTS

5.2 공유 서비스 배포하기 ................................................................................................ 181 5.2.1 아이덴티티 서비스(키스톤) 배포하기 ................................................................... 182 5.2.2 이미지 서비스(글랜스) 배포하기 ......................................................................... 194

5.3 블록 스토리지(신더) 서비스 배포하기 ........................................................................... 204 5.3.1 신더 데이터 저장소 생성하기 ............................................................................. 205 5.3.2 신더 키스톤 사용자 생성하기 ............................................................................. 206 5.3.3 신더 서비스와 엔드포인트 생성하기 .................................................................... 207 5.3.4 신더 설치하기 ................................................................................................ 209

5.4 네트워크(뉴트론) 서비스 배포하기 ............................................................................... 211 5.4.1 뉴트론 데이터 저장소 생성하기 .......................................................................... 212 5.4.2 뉴트론 키스톤 사용자 구성하기 .......................................................................... 213 5.4.3 뉴트론 설치하기 ............................................................................................. 215

5.5 컴퓨트(노바) 서비스 배포하기 ..................................................................................... 218 5.5.1 노바 데이터 저장소 생성하기 ............................................................................. 219 5.5.2 노바 키스톤 사용자 구성하기 ............................................................................. 219 5.5.3 ‘nova’ 사용자에게 역할 할당하기 ....................................................................... 220 5.5.4 노바 서비스와 엔드포인트 생성하기 .................................................................... 221 5.5.5 노바 컨트롤러 설치하기 .................................................................................... 222

5.6 대시보드(호라이즌) 서비스 배포하기 ............................................................................ 225 5.6.1 호라이즌 설치하기 .......................................................................................... 225 5.6.2 호라이즌 접속하기 .......................................................................................... 226 5.6.3 호라이즌 디버깅하기 ....................................................................................... 227

5.7 요약 ....................................................................................................................... 228

CHAPTER

6 네트워크 배포하기 6.1 네트워크의 사전 준비 사항 배포하기 ............................................................................ 232 6.1.1 환경 준비하기 ................................................................................................ 232 6.1.2 네트워크 인터페이스 구성하기 ........................................................................... 232 6.1.3 패키지 갱신하기 ............................................................................................. 236 6.1.4 소프트웨어와 구성 의존성 ................................................................................. 237 6.1.5 Open vSwitch 설치하기 ................................................................................. 240 6.1.6 Open vSwitch 구성하기 ................................................................................. 245

6.2 뉴트론 설치하기 ....................................................................................................... 248 6.2.1 뉴트론 구성요소 설치하기 ................................................................................. 249 6.2.2 뉴트론 구성하기 ............................................................................................. 249 6.2.3 뉴트론 ML2 플러그인 구성하기 ......................................................................... 250 6.2.4 뉴트론 L3 에이전트 구성하기 ............................................................................ 251 6.2.5 뉴트론 DHCP 에이전트 구성하기 ...................................................................... 252 6.2.6 뉴트론 메타데이터 에이전트 구성하기 ................................................................. 253 6.2.7 뉴트론 에이전트 재시작 및 확인하기 ................................................................... 254 6.2.8 뉴트론 네트워크 생성하기 ................................................................................. 255 6.2.9 리눅스, OVS, 뉴트론 간의 관계 ......................................................................... 269 6.2.10 호라이즌 확인하기 ........................................................................................ 272

6.3 요약 ....................................................................................................................... 273

CHAPTER

7 블록 스토리지 배포하기 7.1 블록 스토리지의 사전 준비 사항 배포하기 ..................................................................... 278 7.1.1 환경 준비하기 ................................................................................................ 278 7.1.2 네트워크 인터페이스 구성하기 ........................................................................... 278

CONTENTS

7.1.3 패키지 갱신하기 ............................................................................................. 282 7.1.4 논리 볼륨 관리자 설치 및 구성하기 ..................................................................... 283

7.2 신더 배포하기 ......................................................................................................... 289 7.2.1 신더 설치하기 ................................................................................................ 291 7.2.2 신더 구성하기 ................................................................................................ 292 7.2.3 신더 에이전트 재시작 및 확인하기 ...................................................................... 293

7.3 신더 테스트하기 ....................................................................................................... 295 7.3.1 신더 볼륨 생성하기 : 명령줄 .............................................................................. 295 7.3.2 신더 볼륨 생성하기 : 대시보드 ........................................................................... 298

7.4 요약 ....................................................................................................................... 301

CHAPTER

8 컴퓨트 배포하기 8.1 컴퓨트의 사전 준비 사항 배포하기 ............................................................................... 305 8.1.1 환경 준비하기 ................................................................................................ 306 8.1.2 네트워크 인터페이스 구성하기 ........................................................................... 306 8.1.3 패키지 갱신하기 ............................................................................................. 310 8.1.4 소프트웨어와 구성 의존성 ................................................................................. 310 8.1.5 Open vSwitch 설치하기 ................................................................................. 311 8.1.6 Open vSwitch 구성하기 ................................................................................. 313

8.2 하이퍼바이저 설치하기 .............................................................................................. 315 8.2.1 호스트 확인하기 ............................................................................................. 315 8.2.2 KVM 사용하기 ............................................................................................... 317

8.3 컴퓨트 노드에 뉴트론 설치하기 ................................................................................... 320 8.3.1 뉴트론 소프트웨어 설치하기 .............................................................................. 320 8.3.2 뉴트론 구성하기 ............................................................................................. 320 8.3.3 뉴트론 ML2 플러그인 구성하기 ......................................................................... 321

8.4 컴퓨트 노드에 노바 설치하기 ...................................................................................... 322 8.4.1 노바 소프트웨어 설치하기 ................................................................................. 323 8.4.2 핵심 노바 구성요소 구성하기 ............................................................................. 323 8.4.3 호라이즌 확인하기 .......................................................................................... 325

8.5 노바 테스트하기 ....................................................................................................... 326 8.5.1 인스턴스(VM) 생성하기 : 명령줄 ........................................................................ 326

8.6 요약 ....................................................................................................................... 331

PART

III 상용 환경 구축하기

CHAPTER

9 오픈스택 구조 설계하기 9.1 기존 가상 서버 플랫폼의 대체 ..................................................................................... 336 9.1.1 배포 방식 선택하기 ......................................................................................... 338 9.1.2 네트워크 유형 ................................................................................................ 340 9.1.3 스토리지 유형 ................................................................................................ 341 9.1.4 서버 유형 ...................................................................................................... 345

9.2 왜 사설 클라우드를 구축하는가? ................................................................................. 347 9.2.1 공용 클라우드의 규모의 경제 ............................................................................. 347 9.2.2 대규모 부하 처리 또는 철저한 성능 관리 .............................................................. 348 9.2.3 사설 클라우드에 데이터 보관하기 ....................................................................... 349 9.2.4 하이브리드 시대 ............................................................................................. 350

9.3 사설 클라우드 구축하기 ............................................................................................. 351 9.3.1 오픈스택 배포 도구 ......................................................................................... 351 9.3.2 사설 클라우드의 네트워크 ................................................................................. 352 9.3.3 사설 클라우드의 스토리지 ................................................................................. 355

9.4 요약 ....................................................................................................................... 357

CONTENTS

CHAPTER

10 세프 배포하기 10.1 세프 노드 준비하기 ................................................................................................ 360 10.1.1 노드 인증 및 인가 ......................................................................................... 361 10.1.2 세프 소프트웨어 배포하기 ............................................................................... 365

10.2 세프 클러스터 생성하기 .......................................................................................... 366 10.2.1 초기 구성 파일 생성하기 ................................................................................. 366 10.2.2 세프 소프트웨어 배포하기 ............................................................................... 367 10.2.3 초기 구성 배포하기 ....................................................................................... 369

10.3 OSD 자원 추가하기 ............................................................................................... 370 10.3.1 OSD 장치 준비하기 ...................................................................................... 372 10.3.2 OSD 생성하기 ............................................................................................. 374

10.4 세프 기본 작업 방법 ............................................................................................... 376 10.4.1 세프 풀 ....................................................................................................... 376 10.4.2 세프 클러스터 벤치마킹하기 ............................................................................ 378

10.5 요약 .................................................................................................................... 382

CHAPTER

11 퓨얼을 사용한 HA 오픈스택 자동 배포 11.1 환경 준비하기 ....................................................................................................... 385 11.1.1 네트워크 하드웨어 ........................................................................................ 385 11.1.2 서버 하드웨어 .............................................................................................. 390

11.2 퓨얼 배포하기 ....................................................................................................... 399 11.2.1 퓨얼 설치하기 .............................................................................................. 399

11.3 웹 기반의 기본적인 퓨얼 오픈스택 배포 방법 ............................................................... 402 11.3.1 서버 검색 .................................................................................................... 403 11.3.2 퓨얼 배포 환경 생성하기 ................................................................................. 404

11.3.3 네트워크 환경 구성하기 .................................................................................. 405 11.3.4 환경에 호스트 할당하기 .................................................................................. 407 11.3.5 최종 설정 및 검증 ......................................................................................... 410 11.3.6 변경 사항 배포하기 ....................................................................................... 412

11.4 요약 .................................................................................................................... 412

CHAPTER

12 오픈스택을 사용한 클라우드 오케스트레이션 12.1 오픈스택 히트 ....................................................................................................... 414 12.1.1 히트 템플릿 ................................................................................................. 414 12.1.2 히트 예제 .................................................................................................... 417

12.2 우분투 주주 .......................................................................................................... 424 12.2.1 주주를 위한 오픈스택 준비하기 ........................................................................ 425 12.2.2 주주 설치하기 .............................................................................................. 427 12.2.3 참 CLI 배포하기 ........................................................................................... 432 12.2.4 주주 GUI 배포하기 ........................................................................................ 434

12.3 요약 .................................................................................................................... 442

APPENDIX

A 리눅스 설치하기 A.1 시작하기 ................................................................................................................ 444 A.2 초기 구성 ............................................................................................................... 444 A.3 네트워크 구성 ......................................................................................................... 447 A.3.1 수동으로 어댑터 구성하기 ................................................................................ 449 A.3.2 호스트 및 도메인 이름 구성하기 ........................................................................ 452

A.4 사용자 구성 ............................................................................................................ 454

CONTENTS

A.5 디스크와 파티션 ...................................................................................................... 455 A.5.1 블록 장치(하드 드라이브) 구성하기 ..................................................................... 457 A.5.2 root 및 스왑 파티션과 마운트 지점 구성하기 ....................................................... 459 A.5.3 디스크 구성 마무리하기 ................................................................................... 462

A.6 기본 시스템 구성 .................................................................................................... 463

찾아보기 ..............................................................................................................................................

467

Part

시작하기

1부에서는 오픈스택 프레임워크를 소개하면서 왜 오픈스택을 써야 하며 어떻게 쓰는지를 알아본다. 오픈스택

의 구성요소를 분해하고 하부 자원(컴퓨트, 스토리지, 네트워크 등)과의 관계를 설명한다. 데브스택 배포 도구 를 사용하여 오픈스택을 단일 노드에 배포해볼 것이다. 이러한 내용은 오픈스택을 독자들의 환경에 어떻게 적 용할지 고민하게 해주고 오픈스택 프레임워크에 대한 흥미를 갖게 하여, 향후 오픈스택의 내부 동작 방식을 깊이 이해할 수 있도록 이끌어줄 것이다.

1장 오픈스택 소개

Part I

시작하기

1장

오픈스택 소개

2장 오픈스택 맛보기 3장

오픈스택 기본 작업 방법

4장 사설 클라우드 구성요소 이해하기

1부 시작하기

CHAPTER

오픈스택 소개 오픈스택과 클라우드 생태계

●●

오픈스택을 선택해야 하는 이유

●●

오픈스택이 해줄 수 있는 것

●●

오픈스택의 주요 구성요소

●●

몇십 년 전만 해도 많은 컴퓨터 하드웨어 대기업은 자신만의 제조 시설을 갖추고 전용 프로세 서를 만들어 경쟁 우위를 누렸지만, 생산 비용이 증가하면서 수익을 유지할 수 있을 만큼의 규 모로 칩을 생산할 수 있는 회사는 이제 거의 남아 있지 않다. 범용 프로세서를 대규모로 생산할 수 있는 상용 칩 제조사가 등장해 생산 비용을 크게 끌어내렸다. 몇몇 컴퓨터 칩 제조사는 인텔

x86 명령어 집합으로 표준화된 데스크톱과 서버 플랫폼을 권장해왔고, 결국 x86은 클라이언 트-서버 시장에서도 범용 하드웨어가 주류가 되도록 이끌었다.

2000년대 초반의 닷컴 시대에는 웹의 급격한 성장으로 인해 이러한 범용 하드웨어로 채워진 거대 데이터센터들이 나타났다. 범용 하드웨어는 충분히 강력하고 저렴했다. 하지만 그 아키텍 처는 중앙 집중식 관리를 염두에 두고 설계되지 않은 데스크톱 컴퓨팅 환경 그대로였다. 범용 하드웨어를 자원의 집합으로 추상화하여 관리할 수 있는 어떠한 도구도 존재하지 않았다. 설상 가상으로, 이 시기의 서버들은 데스크톱 계통과 마찬가지로 하드웨어 관리 능력이 대개 결여되 어 있었다. 메인프레임과 대규모 SMPSymmetric Multi-Processing (대칭형 다중 처리) 장치와는 달리, 데스크톱과 유사한 이러한 범용 서버에는 독립적인 자원들을 조율해주는 관리 소프트웨어 계 층이 필요했다.

1장 오픈스택 소개

그림 1.1 상호 연결된 범용 자원들의 클라우드 샌프란시스코 데이터센터 데이터센터에는 랙rack이 존재한다.

데이터센터

뭄바이 데이터센터

뉴욕 데이터센터

파리 데이터센터 애플리케이션 플랫폼

스위치 하이퍼바이저 OS

물리 장치

각 랙에는 자원들이 존재한다.

이 기간에 여러 공공 및 민간 단체에서 범용 자원들을 관리하기 위해 내부적으로 많은 관리 프 레임워크를 만들어냈다. [그림 1.1 ]은 여러 데이터센터에 분산되어 상호 연결된 자원들의 집 합을 보여준다. 관리 프레임워크를 사용하면 가용성 요구나 사용자의 필요에 따라 이러한 공동 의 자원들을 서로 교환하여 사용할 수 있었다. “클라우드cloud”라는 용어를 누가 만들었는지는 불분명하지만, 관리 프레임워크로 범용 컴퓨팅 능력을 이용하던 사람들은 스스로 자원들의 “클 라우드”를 갖추고 있다고 말하곤 했다. 이 기간에 개발된 많은 상용 및 오픈 소스 클라우드 관리 패키지 중 가장 인기 있는 제품이 바 로 오픈스택 프로젝트다. 오픈스택은 서버, 스토리지, 네트워크, 심지어 애플리케이션 자원들 의 클라우드까지도 제어하는 공통 플랫폼을 제공한다. 오픈스택은 웹 기반 인터페이스, 명령줄 인터페이스(CLI ), API로 관리할 수 있다. 이 플랫폼은 특정 제조사의 하드웨어나 소프트웨어 없이도 자원들을 제어할 수 있다. 제조사 전용 구성요소들을 최소한의 노력만으로 대체할 수 있다. 그 덕분에 오픈스택은 IT 조직의 수많은 사람에게 혜택을 준다. 아마존 구매 경험을 되짚어보면 오픈스택을 이해하는 데 도움이 된다. 고객이 아마존에 로그인

1부 시작하기

하여 상품을 주문하면 그 상품이 집까지 배달된다. 그 이면에는 상품을 고객의 집까지 가능한 한 빠르고 싸게 가져다주기 위해 고도로 최적화된 단계들을 거친다. 아마존 웹 서비스Amazon Web Services, AWS

는 아마존이 설립되고 12년 후에 시작되었다. AWS는 그간의 경험을 컴퓨팅 자원을

배달하는 비즈니스로 가져왔다. 외딴 지역의 IT 부서에서 새 서버를 요청하면 몇 주가 소요되 기도 했지만, AWS에서는 신용카드와 몇 번의 마우스 클릭만으로 해결할 수 있다. 오픈스택 은 아마존과 같은 서비스 제공자와 동일한 수준의 조직화된 효율을 제공하는 것을 목표로 하고 있다. 오픈스택이란 무엇인가? 클라우드/시스템/스토리지/네트워크 관리자에게 - 오픈스택은 다양한 유형의 상용 또는 오픈 소스 하드웨어

●●

와 소프트웨어를 제어하며, 제조사 전용 자원 위에서 클라우드 관리 계층을 제공한다. 디스크와 네트워크 프로 비저닝과 같은 반복적인 수작업을 자동화한다. 사실상 가상 머신(VM )을 프로비저닝하는 모든 절차와 심지어 애플리케이션까지 오픈스택을 사용하여 자동화할 수 있다. 개발자에게 - 오픈스택은 개발 환경에 사용되는 자원(가상 머신, 스토리지 등)을 제공하는 아마존 형태의 서

●●

비스뿐만 아니라 템플릿 기반의 확장 가능한 애플리케이션을 배포하기 위한 클라우드 통합 플랫폼이다. 오픈스 택이 인프라(메모리 용량이 X인 서버 Y대)와 애플리케이션의 소프트웨어 의존성(MySQL, Apache2 등)을 확인한 후 독자들 대신 이러한 자원들을 배포하는 모습을 상상해보라. 최종 사용자에게 - 오픈스택은 인프라와 애플리케이션을 위한 셀프 서비스 시스템이다. AWS에서와 마찬가

●●

지로 사용자는 격리된 테넌트 공간에서 간단한 가상 머신 프로비저닝부터 고급 가상 네트워크와 애플리케이션 구성까지, 모든 것을 할 수 있다. 프로젝트Project라고도 알려진 테넌트Tenant는 오픈스택이 자원의 할당을 격리하 는 방식이다. 테넌트 격리는 스토리지, 네트워크, VM 격리를 포함하므로 최종 사용자는 전통적인 가상 서버 환 경에서보다 더 많은 자유를 누릴 수 있다. 원하는 자원을 원하는 시기에 원하는 방식으로 쉽게 프로비저닝하고, 이를 할당받아 사용하는 최종 사용자의 모습을 상상해보라.

가상 머신과 테넌트 이 책에서 가상 머신은 물리 머신(서버)을 에뮬레이션한 인스턴스를 의미한다. 가상 머신은 물 리 머신과 동일한 기능을 수행하며, 운영 체체 관점에서는 실제 하드웨어와 구별하기 어렵게 되 어 있다. 가상 머신은 다양한 용도로 사용되나, 가상화의 목적 대부분은 성능을 희생하더라도 무 언가를 소프트웨어로 제어하는 유연성을 얻기 위함이다. 큰 그림에서 보면 오픈스택은 소프트 웨어 하이퍼바이저가 서버에 가져다준 것과 같은 수준의 운영 효율성을 데이터센터에 가져다 준다.

1장 오픈스택 소개

테넌트라는 용어는 오픈스택에서 특별한 의미를 지니고 있다. 정확한 의미는 이 책에서도 설명 하겠지만 당장은 “논리적으로 서로 격리된 VM들이 사용하는 할당량을 제한한quota-limited 자원의 집합”으로 생각하면 충분하다. 예를 들어, 사용자가 테넌트 A에서 네트워크를 잘못 구성하더라 도 테넌트 B는 영향을 받지 않는다.

오픈스택 재단은 수백 개의 공식 기업 스폰서와 130개국 이상에서 수만 명이 참여하는 커뮤니 티를 보유하고 있다. 이러한 커뮤니티 지원 덕분에 사람들은 오픈스택을 (리눅스와 마찬가지 로) 상용 제품에 대한 대안으로써 찾게 될 것이다. 그리고 서비스의 수준과 지원 범위 면에서 오픈스택과 견줄 만한 클라우드 프레임워크가 거의 없다는 사실을 곧 깨닫게 될 것이다. 아마 도 더 중요한 것으로, 상용 제품을 포함해도 일반적인 시스템 관리자, 개발자, 또는 아키텍트가 직접 운용할 수 있으면서 자신의 조직에 이 정도의 이득을 주는 다른 제품은 없을지도 모른다.

1.1 오픈스택이란? 클라우드 자원을 관리하고 정의하고 활용하기 위한 프레임워크인 오픈스택의 정의를 더 자세 히 알아보자. 공식 사이트(www.openstack.org )에서는 오픈스택을 “사설 및 공용 클라우드 를 만들기 위한 오픈 소스 소프트웨어”로 규정한다. 계속해서 “오픈스택 소프트웨어는 대규모 로 확장 가능한 클라우드 운영체제를 제공한다”라고 정의한다. 서버 가상화를 경험해보았다면 오픈스택을 단지 가상 머신을 제공하는 방법 중 하나라는 잘못된 결론을 성급히 내릴 수도 있 다. 가상 머신도 오픈스택 프레임워크가 제공하는 서비스는 맞지만 이것이 전부는 아니다. [그림 1.2 ]는 오픈스택이 공용 및 사설 클라우드를 만들기 위해 조율하는 다양한 자원 구성요 소를 보여준다. 그림에서 보듯이 오픈스택이 이러한 자원 제공자들을 대체하지는 않는다. 오픈 스택은 프레임워크에 내장된 제어 지점들을 통해 단순히 자원 제공자들을 관리만 할 뿐이다.

1부 시작하기

그림 1.2 오픈스택은 클라우드 운영체제다.

사설 및 공용 클라우드

외부 네트워크

오픈스택은 물리 및 가상 자원들을 관리한다.

물리

가상

스토리지

서버 네트워크

회의적인 시각을 가진 경험 많은 시스템 관리자라면 앞의 정의에서 오픈스택을 단순히 “클라우 드 운영체제”라고 생각할 수도 있다. 오픈스택은 전통적인 운영체제처럼 수백 대의 서버를 부 팅 디스크에서부터 구동하여 운영체제를 올려 놓은 것과는 다르다. 오픈스택은 자원을 관리한 다는 점에서 운영체제의 특성을 공유하지만 어디까지나 클라우드 컴퓨팅이라는 맥락에서만 그 러하다. 오픈스택 클라우드에서는 다음과 같은 것을 할 수 있다. 물리 및 가상 서버, 네트워크, 스토리지 시스템의 자원을 엮어서 이용할 수 있다.

●●

테넌트, 할당량qouta, 사용자 역할user role을 통해 자원의 클라우드를 효과적으로 관리할 수 있다.

●●

공통 인터페이스를 제공하여 하부 제조사 서브시스템과 관계없이 자원을 제어할 수 있다.

●●

얼핏 보면 오픈스택이 전통적인 운영체제처럼 보이지 않지만, 다시 보면 사실 “클라우드” 자체

1장 오픈스택 소개

가 일반 컴퓨터처럼 보이지 않는 것이다. 한 걸음 물러서서 운영체제가 주는 기본적인 혜택을 잘 생각해봐야 한다. 운영체제 또는 최소한 하드웨어 수준의 추상화 언어(어셈블리)가 등장하기 전에는, 특정 컴퓨 터의 언어(바이너리 머신 코드)로만 프로그램을 만들었다. 그 후 전통적인 운영체제가 나타나 고 나서야 애플리케이션 코드와 하드웨어 관리 기능을 표준화할 수 있게 되었다. 이제 관리자 는 공통 인터페이스를 사용하여 하드웨어를 관리할 수 있고, 개발자는 공통 시스템을 위한 코 드를 작성할 수 있으며, 사용자는 하나의 사용자 인터페이스만 익히면 된다. 이는 어떤 하드웨 어를 사용하든 운영체제만 동일하면 적용되는 사실이다. 컴퓨터의 발달 과정에서 운영체제의 발전과 확산으로 인해 시스템 엔지니어링과 시스템 관리라는 분야가 생겨났다. [그림 1.3 ]은 현대 컴퓨터 시스템에서의 다양한 추상화 계층을 보여준다. 그림 1.3 컴퓨터의 추상화 계층 일반적인 추상화 계층 프로세서 전용 아키텍처

기계 코드

명령어 집합 아키텍처

어셈블리

운영체제

가상 계층

오픈스택

바이트코드

제조사 API

오픈스택 API

일반적인 계층별 접근 방식

과거에 운영체제가 막 등장했을 때 운영체제를 사용하면 하드웨어를 직접 제어할 수 없다는 개 념을 좋아하지 않던 개발자들이 있었다. 마찬가지로 서버를 가상화하면 밑단의 하드웨어와 운 영체제에 대한 제어권을 잃게 된다고 생각하고 서버 가상화를 좋아하지 않는 시스템 관리자들 도 있다. 기계 코드에서 어셈블리를 거쳐 가상화 계층까지 이어지는 이러한 일련의 변화에서 우리는 하부 계층에 대한 제어권을 잃은 것이 아니라, 단지 하부 계층이 추상화를 통해 표준화 되었을 뿐이다. 고도로 최적화된 하드웨어와 운영체제는 변함없이 존재하며, 이 계층들 사이에 하드웨어 가상화 계층이 더해질 뿐이다. 일반적으로, 최적화를 통해 얻는 이득이 계층 사이의 번역(가상화) 비용보다 클 때 새로운 추 상화 계층이 폭넓게 채택된다. 다시 말해서, 원래의 성능을 희생함으로써 컴퓨팅 환경의 전체

1부 시작하기

적인 효용이 커지면 추상화 계층이 채택된다. 이러한 현상은 내부 아키텍처는 근본적으로 바뀌 었지만 수십 년 동안 같은 명령어 집합을 준수하는 CPU에서 가장 분명히 나타난다.

CPU를 보고 하드웨어 수준의 가상화와 실행 가변성을 떠올리는 사람은 거의 없지만, 이는 엄 연한 사실이다. x86 프로세서의 많은 명령어가 프로세서 내부에서 가상화되고, 한편으로는 지 금은 거의 사용하지 않는 일부 복잡한 명령어가 더 단순하고 더 빠른 여러 명령어로 변환되어 실행된다. 복잡한 명령어 수준의 최적화는 이 책의 범위를 벗어나지만, 아무것도 설치되지 않 은 서버를 사용할 때조차도 어떠한 형태든 가상화가 연관되어 있고, 심지어 프로세서 수준에서 도 가상화가 존재한다는 사실을 이해하는 것이 중요하다. 이제부터는 제어권을 잃는다는 관점 에서 벗어나 인프라와 애플리케이션의 사설 및 공용 클라우드를 관리, 모니터링, 배포하기 위 한 공통 프레임워크를 사용하는 쪽으로 시선을 옮겨보자. 이러한 진화의 단계를 거쳐 오픈스택 이 등장했다.

CPU 추상화와 가상화의 역사 1978년, 인텔은 8086 CPU와 함께 x86 명령어 집합 instruction set을 시장에 선보였다. 이 명령어 집합은 인텔의 이전 CPU인 8080 프로세서와 호환되었다. 프로세서 구조는 변했지만 기존 어셈 블리 명령어를 그대로 사용할 수 있었다. 그 후로도 새로운 “프로세서 확장 기능”이 추가되고 클 럭 사이클이 증가되었지만 기존 명령어들은 여전히 남아 있었다. 시장은 계속해서 더 빠른 프로세서를 원했고 프로세서 세대 간의 소프트웨어 상호운용성 보장에 대한 요구도 커졌다. CPU 설계자들은 더 낮은 추상화 수준에서 최적화하되 명령어 수준의 호환 성(표준화)은 유지하는 유연성을 원했다. 이런 추상화 덕분에 설계자들은 하드웨어 구조를 마음 대로 변경할 수 있었기에 CPU는 세대를 거듭하며 클럭 속도를 크게 증가시킬 수 있었다. 1995 년에 등장한 펜티엄 프로는 마이크로 옵 mirco-op 디코딩이라는 개념을 도입했다. 이 방식에서는 실행에 한 클럭 사이클이 필요한 특정 명령어가 단순한 명령어 여러 개로 변환되어 여러 사이클 을 소비하기도 했다. 마이크로 옵 외에도 펜티엄 프로 프로세서는 명령어들의 비순차 실행 out-of-order execution과 메모 리 가상화(32비트 버스로 36비트의 메모리 주소를 지정)를 통한 최적화를 도입했다. 그러나 이 모든 것은 개발자로부터 완전히 추상화되어 같은 애플리케이션을 프로세서 제조사나 세대와 관 계없이 실행할 수 있었다. 이러한 명령어 호환성은 최신 x86_64 프로세서까지 계속 이어지고 있다.

1장 오픈스택 소개

1.2 클라우드 컴퓨팅과 오픈스택 이해하기 이 책은 오픈스택을 이용하여 사설 기업용 클라우드를 배포하는 것에 중점을 두고 있다. 이러 한 맥락에서 사설 클라우드를 기업이 보유하고 관리하는 인프라 자원(VM, 스토리지 등)의 모 음이라고 설명할 것이며, 이는 IaaS로도 알려져 있다. 이에 반해 공용 클라우드 IaaS 자원은 아마존 AWS, 마이크로소프트 애저Azure 등과 같은 서드 파티 서비스 제공자가 소유하고 운영 한다. 이 책의 목표는 독자들의 회사에 공용 클라우드에서와 같은 편의성과 효율성을 제공하는 것이다.

사설 대 공용 클라우드의 경제학 재정적인 면에서 사설 클라우드는 일반적으로 자본 비용인 반면에 공용 클라우드는 대개 운영 비용으로 볼 수 있다. 사설 클라우드 환경에서 기업들은 일반적으로 실제 사용 여부와 관계없이 고정 인프라를 구매하거나 일정 기간 대여한다는 점을 고려하면 이 구분은 이해하기 쉽다. 공용 클라우드에서 비용은 일반적으로 시간당 사용량(전원이 켜지고 프로비저닝되면 비용을 지불하 나, 전원이 꺼지고 소멸되면 비용을 지불하지 않는다) 및 통신 비용과 직접적인 관계가 있다.

기업이 사설 클라우드를 선택할지 공용 클라우드를 선택할지는 보통 그 기업의 IT 업무의 규모 나 범위와 관련이 있다. 기술적인 구조와 자원을 다른 부서에 제공할 의무가 있는 중앙 IT 부서 는 보통 사설 클라우드를 활용하는 데 관심이 있다. 다중 테넌트multi-tenant (데이터, 구성, 사용 자 관리가 테넌트별로 논리적으로 격리된다)를 지원하고 완전히 조직화된 사설 클라우드를 통 해 중앙 IT 부서는 사설 클라우드 서비스 중개자가 될 수 있다.

다중 테넌시와 완전한 오케스트레이션 다중 테넌시multi-tenancy란 부서별로 컴퓨팅 자원들을 관리할 수 있는 클라우드 플랫폼의 능력을 의미한다. 예를 들어 마케팅 부서는 공유 자원(VM X개, 용량이 Y인 스토리지 등)의 일부를 할 당받을 수 있으며 이 할당된 자원 내에서 마케팅 부서는 중앙 조직과의 상호작용 없이 자원을 프 로비저닝할 수 있다. 이와 유사하게 완전한 오케스트레이션orchestration이란 애플리케이션 의존성 에 연계하여 자원을 할당하는 능력을 말한다. 예를 들어 웹 서버와 데이터베이스 서버에 의존성 이 있는 회계 애플리케이션은 계획에 따라 이러한 환경에 배포할 수 있다. 따라서 마케팅 부서

1부 시작하기

는 자신의 자원을 스스로 관리할 수 있을 뿐만 아니라 인프라(VM )와 애플리케이션(MySQL,

Apache2, 사용자 지정 애플리케이션 등) 모두를 자신의 테넌트 내에 배포하는 데 플랫폼 오케 스트레이션을 사용할 수 있다.

이와 반대로 부서별 IT 조직은 대개 사설 클라우드를 비용 효율적으로 배포할 수 있는 데이터 센터 시설과 인력을 보유하고 있지 않다. 부서별 IT 조직은 비교적 적은 자원만 있으면 되니 공 용 클라우드를 활용하거나, 중앙 IT 부서가 관리하는 사설 클라우드를 이용할 수 있다. 업무상 필요에 의해 사설과 공용 클라우드 둘 다를 이용하는 경우라면 이러한 조합을 하이브리 드 클라우드hybrid cloud라고 부른다. 공용과 사설 클라우드는 모두 동일한 기술을 사용하고 동일 한 구성요소로 이루어질 수도 있지만, 둘의 사용 목적은 아주 다르다. 예를 들어 보안 유지가 목적이라면 대개 사설 클라우드를 사용한다. 계속 반복되는 작업이나 전 세계를 대상으로 하여 한 기업이 부담하기에는 과도한 비용이 드는 작업에는 공용 클라우드를 사용하는 것이 일반적 이다. 이 책에서는 오픈스택을 사설 클라우드용으로 사용하는 데 중점을 두고 있지만, 내용 중 많은 부분이 오픈스택 API를 기반으로 하는 공용 클라우드 서비스에도 해당한다.

1.2.1 추상화와 오픈스택 API 기본적으로 오픈스택은 광범위한 제조사의 하드웨어와 소프트웨어 자원을 제어하기 위한 공통

API를 추상화하여 제공한다. 오픈스택은 두 가지 매우 중요한 기능을 제공한다. 하드웨어와 소프트웨어 자원의 추상화 - 이를 통해 특정 구성요소가 제조사에 종속되는 것을 피할 수 있다. 이

●●

는 제조사의 제품을 직접 사용하지 않고 오픈스택을 통해 자원을 관리하기 때문에 가능하다. 오픈스택이 제조 사의 모든 기능을 지원하지 못하는 점이 단점이지만 공통적으로 필요한 기능은 충분히 지원하고 있다. 자원들 간의 공통 API - 이를 통해 연결된 구성요소들의 완전한 오케스트레이션이 가능하다.

●●

첫 번째는 경제적인 면에서 유익한 기능이며, 두 번째는 현대의 IT 변혁에서 핵심적인 기능 이다. 다음 절에서는 오픈스택과 관련한 다른 기술들에 대해 살펴볼 것이다.

1장 오픈스택 소개

무엇을 알아야 하는가? 오픈스택은 확장 가능하고 하드웨어를 추상화하는 광범위한 기능을 지원한다. 오픈스택(또는 다른 클라우드 프레임워크)이 현재의 모든 사례에 다 적합한 것은 아니다. 클라우드 컴퓨팅의 장 점을 제대로 활용하기 위해서는 업무 처리 방식을 변경해야 할 수도 있다. 업무 처리 기준이 데이터센터 내의 모든 서버가 특정 작업을 위해서 특정 제조사의 기능을 사용 하는 것이라면, 이러한 접근 방식은 제조사를 추상화하는 클라우드 환경에는 적합하지 않다. 사 용자가 요청할 때마다 가상 머신을 수동으로 생성하는 식으로 업무를 처리한다면, 클라우드 셀 프 서비스라는 핵심을 놓치고 있는 것이다. 최종 사용자의 요청을 효과적으로 자동화해서 처리 하거나 최종 사용자 스스로 자원을 프로비저닝할 수 있다면, 그제서야 클라우드 컴퓨팅의 힘을 제대로 이용하고 있는 것이다.

1.3 오픈스택과 오픈스택이 제어하는 컴퓨터 자원과의 관계 지금까지 오픈스택이 제공하는 뛰어난 기능에 대해 알아보았다. 그렇다면 과연 오픈스택은 어 떻게 동작하는가? 오픈스택의 동작 방식을 이해하는 가장 쉬운 방법은 기업 환경에서 널리 사 용되는 다른 기술들과 오픈스택을 연관 지어보는 것이다. 이번 절에서는 오픈스택과 오픈스택이 제어하는 기본 자원(컴퓨트, 스토리지, 네트워크 등) 간의 관계를 알아볼 것이다. 곧 알게 되겠지만, 일반적으로 오픈스택은 실제 자원을 제공하지 않고 단순히 하위 계층의 자원을 제어만 할 뿐이다. [그림 1.4 ]에서는 가상 머신이 최종적으로 사용하는 자원을 오픈스택이 어떻게 관리하는지를 볼 수 있다. 이어지는 몇 개의 하위 절에서 하이퍼바이저가 제어하는 서버 가상화, 하드웨어와 오픈스택 서 비스가 제어하는 네트워크, 제조사와 오픈스택 서비스가 제어하는 블록 및 오브젝트 스토리지 순으로 오픈스택 자원을 구성하는 요소를 자세히 알아볼 것이다. 마지막으로 오픈스택 서비스 를 일반적으로 통용되는 클라우드 용어와 비교해서 살펴볼 것이다. 곧 알게 되겠지만 오픈스택 은 기술이나 제조사와 관계없이 자원과 서비스를 조율하는 프레임워크이다.

1부 시작하기

그림 1.4 오픈스택 자원 관리 모델 오픈스택 서비스 오픈스택 대시보드는 UI를 제공한다.

오픈스택은 자원을 관리한다. 네트워크

컴퓨트

스토리지

제조사 네트워크

제조사 하이퍼바이저

제조사 스토리지 시스템

VM 네트워크

VM 컴퓨트

VM 볼륨

제조사는 자원을 제공한다.

가상 머신이 사용한다.

1.3.1 오픈스택과 하이퍼바이저 하이퍼바이저 또는 가상 머신 모니터Virtual Machine Monitor, VMM는 가상 머신을 위해 물리 하드웨어를 에뮬레이션하는 소프트웨어다. 오픈스택 자체는 하이퍼바이저가 아니며 단지 하이퍼바이저의 동작을 제어할 뿐이다. 오픈스택은 젠서버XenServer/XCP, KVMKernel-based Virtual Machine, QEMU,

LXC, ESXi, Hyper-V 등의 다양한 하이퍼바이저를 지원한다(하이퍼바이저 지원 매트릭스 는 https://wiki.openstack.org/wiki/HypervisorSupportMatrix에서 볼 수 있다). 현재

VMware ESX, VMware ESXi, 마이크로소프트 Hyper-V가 기업 가상화 시장을 주도하고 있다. 하지만 라이선스 제한이나 비용 등의 여러 요인 때문에 오픈스택 커뮤니티는 상용 하이 퍼바이저보다는 오픈 소스 하이퍼바이저에 더 많은 지원을 해오고 있다.

1장 오픈스택 소개

[그림 1.5 ]는 물리 하드웨어 위에서 하이퍼바이저가 가상화한 자원을 오픈스택이 관리하는 모 습을 보여준다. 오픈스택은 다양한 하이퍼바이저 자원과 가상 머신을 오픈스택 클러스터에서 관리하고 조율한다. 그림 1.5 오픈스택은 하이퍼바이저를 관리한다.

오픈스택 컴퓨트

하이퍼바이저 관리

컴퓨트

가상 하드웨어

서버 하드웨어

CPU

RAM

디스크

네트워크

VM 컴퓨트

가상화 환경의 규모와 관계없이 대부분의 사람이나 조직은 광범위한 기능을 지원하는 젠서버 또는 KVM 하이퍼바이저 둘 중 하나를 사용한다. 시트릭스Citrix의 제품인 젠서버는 오픈 소스 하이퍼바이저지만 시트릭스가 상용(유료) 지원 서비스를 제공한다. KVM은 리눅스 커널에 포 함되어 있어서 레드햇Red Hat, 우분투Ubuntu, 수세SUSE 등 많은 리눅스 배포판에서 KVM에 대한 상 용 지원을 제공하고 있다.

1부 시작하기

인증 문제 대규모 서비스 제공자들이 오픈스택 기반의 공용 IaaS를 제공하기 위한 준비를 시작했을 때, 하이퍼바이저 에서 동작 중인 윈도우 서버를 위한 마이크로소프트 인증이 필요하다는 것을 곧바로 인지했다. 그 당시 시트 릭스는 젠서버에 대한 마이크로소프트 인증 절차를 통과하여 고객들의 요구에 부응했다. 하지만 시트릭스가 클라우드스택CloudStack이라는 경쟁력 있는 플랫폼을 보유하고 있었음에도 많은 사용자가 젠서버를 오픈스택 의 하이퍼바이저로 사용했다. 그 이후로 많은 리눅스 배포판에서 마이크로소프트 인증 절차를 통과했고 현재

KVM을 비롯한 오픈스택이 제어할 수 있는 하이퍼바이저들은 모두 윈도우 게스트를 완벽히 지원한다.

이 책의 예제에서는 KVM을 사용할 것이다. KVM은 2007년 초반에 발표된 2.6.20 버전 이후 로 리눅스 커널에 포함되었으며 현재 오픈스택은 KVM을 완벽히 지원하고 있다. KVM은 반가 상화 paravirtualization 또한 지원하는데, 이를 위해서는 가상화된 운영체제 이미지 내에서 자체적으 로 반가상화를 지원하거나 하이퍼바이저 전용 드라이버를 설치하여 반가상화 기능을 추가해야 한다. 오픈 소스 하이퍼바이저의 고질적인 문제점은 배포하고 관리하는 방법을 배우기 쉽지 않 으며, 종종 시스템, 네트워크, 애플리케이션 관리 경험까지도 필요하다는 점이다. 가상화된 자 원을 제공하는 중앙 부서에 자원을 요청할 때는 그 프로비저닝 과정에서 조직의 네트워크, 시 스템, 보안, 그리고 재정적인 부분까지 검토를 거쳐야만 한다. 이때 사용자는 일반적으로 다음 세 가지 중 하나를 선택할 수 있다. 커뮤니티에서 배포한 코드를 사용한 사용자 자체 지원 - 커뮤니티에서 관리하는 소프트웨어에 대한 커뮤니티

●●

의 지원을 받아 사용자가 직접 가상화 환경을 설계, 배포, 운영한다. 커뮤니티에서 배포한 코드를 사용한 상용 지원 - 커뮤니티에서 관리하는 소프트웨어에 대해 특정 업체의 지원

●●

을 받아 사용자 또는 업체가 가상화 환경을 책임진다. 업체가 개발한 커뮤니티 프로젝트 소프트웨어를 사용한 상용 지원 - 업체가 지원하는 소프트웨어를 사용하여

●●

일반적으로는 사용자가 가상화 환경의 운영과 업체 관리를 책임진다.

다수의 업체가 오픈스택과 KVM을 상용 지원하고 있지만, 조직 내부에서 사용하는 많은 클라 우드 환경은 상용 지원이나 인증이 필요없는 작업을 위해 구축되므로, 상용 지원을 받지 않고

KVM과 함께 오픈스택을 사용하는 것이 가장 인기 있는 방식이다. 이 책에서는 배포 환경이나 지원 방식과 상관없는 공통적으로 유용한 주제를 다룬다.

1장 오픈스택 소개

리눅스 컨테이너 최근 인프라 수준의 가상화 대신에 운영체제 수준의 가상화를 사용하여 오픈스택 인스턴스를 제 공하는 방식이 많은 관심을 받고 있다. 운영체제 수준의 가상화를 이용하면 단일 서버에서 다수 의 격리된 OS 인스턴스(컨테이너)를 가동할 수 있다. 그러나 이 가상화 방식은 하이퍼바이저 기술은 아니며, 컨테이너는 운영체제와 동일한 커널을 공유하며 동작한다. 컨테이너는 전full가상 화에서 필연적인 에뮬레이션 오버헤드 없이 가상의 격리 공간을 제공하는 방식이다. 운영체제 수준의 가상화 프로젝트 중 가장 인기 있는 두 가지가 바로 도커Docker (http://www.

docker.com/)와 로켓Rocket ( https://github.com/coreos/rkt )이다. 컨테이너가 OS 단위의 인스턴스보다 애플리케이션 실행에 더 적합한지에 대해서는 논쟁의 여지가 남아 있지만, 분명히 컨테이너 기반 기술은 클라우드를 구축하는 데 점점 더 널리 채택될 것이다.

1.3.2 오픈스택과 네트워크 서비스 오픈스택 자체는 가상 스위치가 아니지만 여러 물리 및 가상 네트워크 장치와 가상 오버레이 네트워크를 관리할 수 있다. 하이퍼바이저의 경우에는 하이버파이저 자체적으로 제공하는 서 비스만 제한적으로 오픈스택이 제어할 수 있지만, DHCPDynamic Host Configuration Protocol나 라우팅 등의 네트워크 서비스는 오픈스택이 직접 제공한다. 그러나 하이퍼바이저에서와 마찬가지로 네트워크 서비스에서도 오픈스택은 상용이든 오픈 소스든 어떠한 하부 기술에도 종속되지 않 는다. 더 중요한 것은 네트워크 유형이나 제조사가 변경되더라도 구성 설정을 변경할 필요가 없다는 점이다. 네트워크 서비스에 특정 하드웨어, 소프트웨어, 사용자 인터페이스가 밀접하게 관련되 어 있다면 다른 제조사나 기술로 변경하는 것이 쉽지 않다. [그림 1.6 ]에서 보듯이 오픈스택은 이러한 인터페이스를 오픈스택 API로 추상화하고 있다. 오픈스택은 아리스타 네트웍스Arista Networks, 시스코 넥서스Cisco Nexus, 리눅스 브리지Linux Bridge,

OVSOpen vSwitch 등 많은 유형의 네트워크 기술(메커니즘)을 관리할 수 있다. 이 책에서는 오픈 스택과 OVS가 제공하는 네트워크 서비스를 사용한다. OVS는 특정 하드웨어가 필요 없고 쉽 게 구해서 사용할 수 있기 때문에 오픈스택에서 일반적으로 선택되는 스위치다. 네트워크 메커 니즘에 따라서 오픈스택이 지원하는 여러 네트워크 타입(VLAN, 터널 등)이 존재하며, 이에 대해서는 6장에서 다룬다.

1부 시작하기

그림 1.6 오픈스택은 네트워크를 관리한다. 오픈스택

네트워크

제조사 네트워크 장비 서버 하드웨어

네트워크

컴퓨트

1.3.3 오픈스택과 스토리지 일반적인 스토리지의 개념에서 볼 때 오픈스택 자체는 스토리지 어레이가 아니다. 오픈스택은 가상 머신이 사용하는 스토리지를 물리적으로 제공하지는 않는다. 파일 공유(NFS, CIFS 등)를 사용해본 적이 있다면 이미 “파일 기반” 스토리지를 사용해본 것 이다. 이 유형의 스토리지는 사람이 찾아보기도 쉽고 컴퓨터가 접속하기도 편리하지만, 이것은 일반적으로 블록 block 스토리지라는 또 다른 유형의 스토리지를 추상화한 것이다. 블록 스토리 지는 운영체제나 파일 시스템이 주로 사용한다고 볼 수 있다. 오브젝트object 기반 스토리지라는 그다지 친숙하지 않은 또 다른 유형의 스토리지가 있다. 이 유형의 스토리지는 일반적으로 소프트웨어 API (예를 들어 GET /obj=xxx )를 통해 접근할 수 있다. 오브젝트 기반 스토리지는 파일과 블록 스토리지를 한 단계 더 추상화한 것이지만 파 일이나 블록 스토리지에서의 제한 사항이 없다. 오브젝트 기반 스토리지는 다수의 참여 노드

1장 오픈스택 소개

간에 쉽게 배포하고 복제할 수 있다. VM이 빠르게 접근해야만 하는 블록 스토리지와는 다르게 오브젝트 스토리지에서는 더 긴 지연 시간이 허용되기 때문에 VM의 볼륨(인스턴스에 항상 연 결되어 있음)으로는 사용되지 않는다. 오브젝트 스토리지는 볼륨과 이미지(운영체제 포함)의 백업을 저장하기 위해 일반적으로 사용한다. 먼저 오픈스택이 어떻게 블록 스토리지와 함께 동작하는지를 알아본 후 오브젝트 스토리지를 살펴볼 것이다.

블록 스토리지 오픈스택은 현재 최종 사용자를 위한 파일 기반 스토리지를 관리하지 않는다.1 [그림 1.7 ]에서 오픈스택이 하이퍼바이저와 네트워크를 관리하는 것과 매우 유사하게 블록 스토리지를 관리하 는 것을 볼 수 있다. 그림 1.7 오픈스택은 블록 (VM) 스토리지를 관리한다. 오픈스택

네트워크

스토리지

서버 하드웨어 제조사 네트워크

제조사 스토리지 시스템

네트워크

컴퓨트

볼륨

1 옮긴이_ 오픈스택 주노 버전부터 공유 파일 서비스인 마닐라(Manila ) 프로젝트가 추되었다.

1부 시작하기

이 그림은 기본적인 VM의 자원 관리 측면에서 완전한 그림을 보여준다. 오픈스택은 세프Ceph, 델Dell, EMC, HP, IBM, 넷앱NetApp 등의 다양한 제조사가 제공하는 스토리지 솔루션을 관리할 수 있다. 하이퍼바이저와 네트워크에서와 마찬가지로 오픈스택은 어떠한 구성 설정 변경 없이 스토리지 제조사와 기술을 변경할 수 있는 유연성을 제공한다.

오브젝트 스토리지 오픈스택 자체가 (VM 부팅용) 블록 스토리지를 위한 스토리지 어레이는 아니지만 오브젝트 스토리지를 제공하는 능력을 기본적으로 가지고 있다. 어떠한 다른 소프트웨어 없이 오픈스택 이 지원하는 리눅스를 구동할 물리 하드웨어만 있다면 오픈스택은 분산 오브젝트 스토리지 클 러스터를 제공할 수 있다. 이 유형의 스토리지는 볼륨 백업을 저장하기 위해 사용할 수 있으며, 또한 바이너리 객체로 분류될 수 있는 대량의 데이터를 위해 사용하는 것이 일반적이다. [그림

1.8 ]은 오픈스택 환경에 포함된 기본 오브젝트 서버 배포 환경을 보여준다. 그림 1.8 오픈스택은 오브젝트 기반 (API) 스토리지를 제공한다. 오픈스택

프록시 노드

스토리지 노드

오브젝트 스토리지를 단일 장소에만 두어서는 안 된다. 실제로 서로 간에 복제를 하는 다수의 노드(프록시와 스토리지)를 다수의 장소에 둘 수 있다.

1장 오픈스택 소개

일반적으로 오브젝트 스토리지는 문서나 파일과 같이 사용자를 대신하여 애플리케이션이 접근 하는 데이터를 저장하는 데 사용한다. 오픈스택 환경에서 오브젝트 스토리지를 사용하는 사례 가 많이 있다. 예를 들어, 오브젝트 스토리지는 VM 이미지의 저장소로 흔히 사용된다. VM이 이 스토리지를 직접 사용한다는 의미는 아니지만, VM은 이 스토리지에 저장된 데이터에서 프 로비저닝된다. 프로비저닝 과정에서는 임의의 데이터에 접근할 때의 지연 시간이 크게 중요하 지 않기 때문에 이는 합리적인 선택이다. 또한 오브젝트 스토리지는 VM의 스냅샷을 장기간 백 업해두는 용도로 사용할 수도 있다.

1.3.4 오픈스택과 클라우드 용어 오픈스택은 클라우드 구축을 위한 프레임워크며 공용 및 사설 클라우드를 구축하기 위해 사용 한다. 공용과 사설 클라우드의 정의 외에도 “as-a-service”라는 클라우드의 목적이 존재한 다. 오픈스택은 어떤 “as-a-service”인가? 오픈스택은 여러 가지 “as-a-service” 클라우드 를 위한 토대로 사용할 수 있다.

VM과 스토리지 자원을 확보하기 위한 아마존 형태의 서비스를 독자들의 회사에 제공하고자 한다. 이것은 IaaSInfrastructure as a Service로 간주된다. 이 상황에서 사용자에게는 개별 가상 머신을 직접 프로비저닝하고 관리할 수 있는 접근 권한이 주어진다. 사용자는 클라우드를 구성하는 물 리 구성요소를 볼 수는 없지만 가상 구성요소에는 직접 접근할 수 있다. 오픈스택은 자원을 제 어하여 최종 사용자에게 인프라를 제공하는 책임만 진다. 이제 클라우드 사용자에게 IaaS 기능에 대한 직접 접근 권한은 주지 않고 오픈스택이 제공하고 지원하는 애플리케이션 오케스트레이션 기능에 대한 접근 권한만 부여한다고 가정하자. 이 상 황에서 오픈스택은 PaaSPlatform as a Service를 제공하는 백엔드back end로 간주할 수 있다. 사용자는 하부에 존재하는 물리 및 가상 인프라 구성요소를 볼 수 없다. 개발팀이 소프트웨어 테스트를 위한 서버와 네트워크 인프라(IaaS 위에 애플리케이션을 배포)를 요청하는 경우를 생각해보 자. 테스트용 플랫폼을 배포하기 위한 백엔드로 오픈스택을 사용하여 클라우드 오케스트레이 션을 할 수 있다. 이제 오픈스택이 제공하는 IaaS 또는 PaaS를 사용하는 고객에게 특정 서비스를 제공한다고 가 정해보자. 이 상황에서 오픈스택은 SaaSSoftware as a Service의 백엔드 구성요소로 역할을 한다. 보

1부 시작하기

다시피 다양한 계층의 클라우드 컴퓨팅에서 오픈스택을 기본 구성요소로 사용할 수 있다. 지금까지 오픈스택이 무엇을 하고 어떻게 동작하는지를 알아보았으므로, 이제 실제로 오픈스 택을 동작시키는 여러 구성요소를 소개할 때다. 다음 절에서는 오픈스택의 개별 구성요소들과 프레임워크 전체에서 각각의 역할을 설명할 것이다.

1.4 오픈스택 구성요소 소개 1.1절에서 오픈스택의 기본적인 기능을 소개했다. 이번 절에서는 오픈스택을 구성하는 기본적 인 구성요소들을 살펴볼 것이다. [표 1.1 ]은 다양한 오픈스택의 구성요소, 즉 핵심 프로젝트core project를 보여준다. 여러 번의 개발 단계를 거치면서 더 많은 프로젝트가 생겨났지만, 다음이 오픈스택의 기본적인 구성요 소다. 오픈스택 서비스의 최신 로드맵은 오픈스택 로드맵 페이지( www.openstack.org/

software/roadmap/)에서 찾을 수 있다. 표 1.1 핵심 프로젝트 프로젝트

코드명

설명

컴퓨트

노바Nova

CPU, 메모리, 디스크, 네트워크 인터페이스 등의 VM 자원 관리

네트워크

뉴트론Neutron

IP 주소, 라우팅, SDNSoftware Defined Network 등 VM의 네트워크 인터페이 스가 사용하는 자원 제공

오브젝트 스토리지

스위프트

RESTful API로 접근할 수 있는 오브젝트 스토리지 제공

블록 스토리지

신더Cinder

VM에 블록 스토리지(일반적인 디스크) 제공

아이덴티티

키스톤Keystone

오픈스택 구성요소를 위한 역할 기반 접근 제어Role-Based Access Control, RBAC

Swift

관리 및 인증 서비스 제공 이미지 서비스

글랜스Glance

VM의 디스크 이미지 관리. VM에 이미지 제공 및 스냅샷(백업) 서비스 제공

대시보드

호라이즌

오픈스택에서 작업하기 위한 웹 기반 GUI 제공

텔레메트리Telemetry

실로미터Ceilometer

오픈스택 구성요소의 사용량 측정 및 모니터링을 위한 도구 모음 제공

오케스트레이션

히트Heat

오픈스택 환경을 위한 템플릿 기반의 클라우드 애플리케이션을 오케스트

Horizon

레이션하는 기능 제공

1장 오픈스택 소개

지금까지 오픈스택이 무엇이며 무엇을 하는지에 대해 알아보았으므로 이제 오픈스택이 발전해 온 과정을 빠르게 살펴보자.

1.5 오픈스택의 역사 미국 대통령 버락 오바마는 2009년 취임 첫 날, 집무실에서 모든 연방 기관에 보낸 메모를 통 해 연방 정부와 국민 간의 투명성, 참여, 협력을 저해하는 장벽을 철폐하라고 지시했다. 이 메 모는 열린 정부 지침Open Government Directive으로 알려져 있다. 이 지침이 발령된 지 120일 후에 NASA는 NASA의 열린 정부 프레임워크Open Government Framework 를 발표했으며, 여기에는 네뷸라 Nebula라는 도구를 공유한다고 기술되어 있다. 네뷸라는 NASA 과학자와 연구원에게 IaaS 자원을 더 빠르게 제공하기 위해 개발되었다. 이와 동시에 클라우드 컴퓨팅 업체인 랙스페이스Rackspace는 자사의 오브젝트 스토리지 플랫폼인 스위프트Swift를 오픈 소스화한다고 발표했다.

2010년 7월 랙스페이스와 NASA는 다른 25개 회사와 협력하여 오픈스택 프로젝트에 착수했 다. 첫 발표 후 매해 거의 두 번씩 새 버전을 발표했고, 오픈스택 버전 정보는 [표 1.2 ]에서 볼 수 있다. 표 1.2 오픈스택 버전 이름

날짜

핵심 구성요소

오스틴

2010년 10월

노바, 스위프트

벡사Bexar

2011년 2월

노바, 글랜스, 스위프트

캑터스Cactus

2011년 4월

노바, 글랜스, 스위프트

디아블로Diablo

2011년 9월

노바, 글랜스, 스위프트

에섹스

2012년 4월

노바, 글랜스, 스위프트, 호라이즌, 키스톤

폴섬Folsom

2012년 9월

노바, 글랜스, 스위프트, 호라이즌, 키스톤, 퀀텀Quantum, 신더

그리즐리Grizzly

2013년 4월

노바, 글랜스, 스위프트, 호라이즌, 키스톤, 퀀텀, 신더

하바나Havana

2013년 10월

노바, 글랜스, 스위프트, 호라이즌, 키스톤, 뉴트론 Neutron, 신더, 실로미터,

Austin

Essex

히트

1부 시작하기

아이스하우스Icehouse

2014년 4월

노바, 글랜스, 스위프트, 호라이즌, 키스톤, 뉴트론, 신더, 실로미터, 히트, 트로브Trove

주노Juno

2014년 10월

노바, 글랜스, 스위프트, 호라이즌, 키스톤, 뉴트론, 신더, 실로미터, 히트, 트로브, 사하라Sahara

킬로Kilo

2015년 4월

노바, 글랜스, 스위프트, 호라이즌, 키스톤, 뉴트론, 신더, 실로미터, 히트, 트로브, 사하라, 아이러닉Ironic

리버티Liberty

2015년 10월

노바, 글랜스, 스위프트, 호라이즌, 키스톤, 뉴트론, 신더, 실로미터, 히트, 마르코니Marconi, 트로브, 사하라, 아이러닉, 서치라이트Searchlight, 데지그네 이트Designate, 자카르Zaqar, DBaaS, 바비칸Barbican, 마닐라 Manila

오픈스택은 6개월 주기로 새 버전을 발표해오고 있으며, 오픈스택 서밋 행사에서 발표한다. 현 재 오픈스택 프로젝트에 참여하는 기업이 25개에서 200개 이상으로 늘어났으며, 130개국 이 상에서 수천 명의 참여자가 동참하고 있다.

1.6 요약 IaaS 클라우드는 관리 프레임워크를 통해 조율되는 범용 자원의 모음이다.

●●

오픈스택은 최종 사용자가 직접 IaaS를 조정하고 애플리케이션을 오케스트레이션(PaaS/SaaS )할 수 있도

●●

록 해주는 관리 프레임워크다. 오픈스택은 하이퍼바이저, 스토리지 시스템, 네트워크 하드웨어와 소프트웨어 등 기존 상용 및 커뮤니티 기술

●●

을 제어한다. 오픈스택은 각각 특정 목적을 가진 프로젝트의 모음으로 구성된다.

●●

오픈스택의 각 프로젝트는 고유한 코드명을 가지고 있다.

●●

1장 오픈스택 소개

CHAPTER

오픈스택 맛보기 데브스택을 사용해 오픈스택 맛보기

●●

데브스택 환경 준비하기

●●

●● ●●

오픈스택 테넌트(프로젝트) 모델 이해하기 오픈스택으로 가상 머신 생성하기

데브스택 구성 및 배포하기

●●

오픈스택 대시보드와 친해지기

●●

1장에서는 오픈스택이 주는 다양한 혜택과 오픈스택이 클라우드 생태계에 얼마나 적합한지를 설명했다. 오픈스택으로 무엇을 할 수 있는지를 알았으므로 이제는 오픈스택이 어떻게 구성되 어 있는지가 궁금할 것이다. 사용자들은 오픈스택을 통해 무엇을 경험할 수 있을까? 이번 장에 서 간편한 오픈스택 배포 도구인 데브스택을 사용하여 오픈스택을 체험하고 나면 이 질문에 답 할 수 있을 것이다. 데브스택을 사용하면 대규모 배포 환경 대신에 작은 규모로 배포된 오픈스택을 사용해볼 수 있 다. 구성요소를 빠르게 배포 또는 스태킹stacking, 쌓기 (오픈스택을 다루는 동료들이 이렇게 부른 다)해서 오픈스택이 상용 환경에 적합한지를 평가해볼 수 있다. 데브스택은 [그림 2.1 ]과 같이 대규모 다중 서버 환경에 배포되어 있는 것과 동일한 오픈스택 구성요소들을 단 하나의 서버에 배포할 수 있다. 오픈스택을 잘 알지 못하고 하드웨어가 부족해도 데브스택을 사용하면 작은 규모로 오픈스택 환경을 구축할 수 있다. 이 그림은 신더, 노바, 뉴트론 등 다양한 구성요소가 여러 노드에 배포되어 있는 모습을 보여준 다. 오픈스택은 구성요소마다 코드명을 사용하는데, 코드명 신더Cinder는 스토리지 구성요소를, 노바Nova는 컴퓨트 구성요소를, 뉴트론Neutron은 네트워크 구성요소를 의미한다. 지금은 오픈스 택의 각 구성요소, 코드명, 역할을 아는 것은 중요하지 않다. 이에 대해서는 4장에서 자세히 설 명할 것이다. 지금 알아두어야 할 것은 오픈스택은 다양한 핵심 구성요소로 이루어져 있으며 의도적인 설계에 따라 이 구성요소를 여러 노드(서버)에 분산 배치할 수 있다는 사실이다. 오 픈스택 설계에 대해서는 9장에서 다룰 것이다.

2장 오픈스택 맛보기

그림 2.1 다중 서버 오픈스택 오픈스택 서비스

컨트롤러 (서버 0) 공유 서비스 뉴트론

노바

신더

네트워크

컴퓨트

스토리지 노바 (서버 1)

뉴트론 (서버 2)

신더 (서버 3)

2.1 데브스택이란 무엇인가? 데브스택은 원래 테스트나 개발 환경에서 오픈스택을 더 빠르고, 더 편하고, 더 이해하기 쉽게 배포하기 위해 만들어졌다. 하지만 데브스택을 사용해 오픈스택을 쉽게 배포할 수 있게 되면서 어느새 오픈스택을 배우기 위한 자연스러운 시작점이 되었다. 데브스택은 환경을 준비하고 오 픈스택을 구성하여 배포하기 위해 사용하는 배시Bash 셸 스크립트의 모음이다. 데브스택의 코 드는 사람과 컴퓨터 모두가 인식할 수 있게 되어 있으며 데브스택 개발자들은 데브스택 코드 안에 바로 문서화 작업을 한다. 즉, 의존 관계에 있는 소프트웨어 정보가 모두 코드에 주석으로

1부 시작하기

적혀있어서 사용자는 동작 중인 시스템에 이러한 의존 소프트웨어를 어떻게 제공해야 할지를 알 수 있다. 오픈스택 프레임워크는 주눅이 들 정도로 크고 복잡하지만 데브스택은 그 모든 것을 쉬워 보이 게 해준다. [그림 2.2 ]를 보면 지나치게 단순해 보일 수 있지만 사실은 데브스택의 기능을 정확 히 묘사해놓은 것이다. 그림 2.2 데브스택은 하나의 노드에 오픈스택을 자동으로 설치하고 구성할 것이다. 배포 전 데브스택 서버 (리눅스만 설치)

오픈스택 소프트웨어 및 관련 의존 소프트웨어를 설치한다. 데브스택을 실행한다.

배포 후 데브스택 서버 (오픈스택 배포)

오픈스택 구성요소가 서로 동작하도록 구성한다.

가상화, 스토리지, 네트워크, 심지어 리눅스 경험이 없는 사용자라도 단기간에 단일 서버에 오 픈스택 환경을 구성할 수 있다. 데브스택은 오픈스택이 인프라를 위해 할 수 있는 많은 것을 오 픈스택을 대신해서 해준다(1장에서 설명했다). 다시 말해서 데브스택은 오픈스택을 간소화하 고 추상화한다. 하지만 상용 환경에서 오픈스택을 배포하기 위해 데브스택을 사용하는 것은 권장하지 않는다. 실제로 오픈스택 업계에는 “진정한 친구라면 자신의 친구가 상용 환경에서 데브스택을 사용하 도록 보고만 있지 않는다”는 말이 회자되곤 한다. 우리는 5장부터 8장에 걸쳐 오픈스택을 수동 으로 배포해볼 것이다. 수동으로 설치해보면 오픈스택의 구성 옵션과 구성요소를 배울 수 있고 오픈스택 환경에서 발생하는 문제를 해결하는 능력을 키울 수 있다. 11장에서는 상용 환경에

2장 오픈스택 맛보기

서 사용할 수 있는 오픈스택 자동 배포 방법을 다룰 것이다. 이번 장에서는 데브스택을 사용해 환경을 준비하고 오픈스택을 배포할 것이다. 단일 서버에 오 픈스택 환경을 배포하기 위해 리눅스, 스토리지, 네트워크에 대해 많이 알 필요는 없다. 이 배 포 방법을 사용해 오픈스택과 상호작용할 수 있는 방법을 살펴볼 것이며, 이를 통해 구성요소 와 전체 시스템에 어느 정도는 익숙해질 수 있을 것이다. 그 후, 오픈스택이 자원을 논리적으로 분리하고, 제어하고, 프로젝트에 할당하는 방법인 테넌트 모델을 알아볼 것이다. 오픈스택 용 어인 테넌트와 프로젝트는 서로 바꿔서 사용할 수 있다. 마지막으로, 그동안 배운 것을 바탕으 로 가상화 환경에서 가상 머신을 생성해볼 것이다. 이제 스태킹을 시작해보자!

2.2 데브스택 배포하기 그 이름이 암시하듯이 데브스택은 개발 도구이며, 데브스택과 관련한 오픈스택 코드는 계속 개 발 중에 있다. 오픈스택 코드를 배포하기 위해 데브스택이 사용하는 여러 지원 패키지 또한 계 속 개발 중에 있다. 데브스택은 잘 배포되기만 하면 멋지게 동작하지만, 동작이 실패하면 상황 이 복잡해지고 처음 해보는 사용자는 좌절하곤 한다. 이번 장의 대부분은 데브스택을 사용하여 오픈스택을 배포하는 데 집중하고 있지만 최신 버전의 데브스택에서도 명령어가 잘 실행될지 는 그 때마다 미지수다. 동일한 데브스택 명령어가 월요일에는 실패했는데 금요일에는 잘 실행 될 수도 있다. 독자들의 좌절감을 줄이기 위해 데브스택이 배포된 오픈스택 인스턴스가 들어 있는 컴패니언 companion

가상 머신(VM )을 제공할 것이다. 이 VM은 제한된 하드웨어 자원과 노력만으로도 오

픈스택을 체험하기 위해 사용할 수 있다. 데브스택이 제대로 동작하지 않는 경우에는 간단히 컴패니언 VM을 사용하면 된다. 전체 오픈스택 프레임워크를 더 잘 이해하게 되면 언제든지 데 브스택 배포를 다시 시도해볼 수 있다.

1부 시작하기

컴패니언 VM은 어떤 버전의 오픈스택을 사용하는가? 이 책의 1부와 2부의 예제에서 사용하는 컴패니언 VM은 오픈스택 아이스하우스 버전을 사용한 다. 이 책을 쓰는 시점에는 이미 아이스하우스 이후로 수 차례 새 버전이 발표되었지만, 아이스 하우스는 여전히 가장 널리 배포되어 있으며 오픈스택의 가장 안정적인 버전이다. 또한 아이스 하우스 버전을 지원하는 다양한 리눅스 배포판과 오픈스택 배포 도구가 존재한다. 이 책의 3부 에서 아이스하우스나 최신 버전을 포함한 다양한 버전의 오픈스택 배포에 사용할 수 있는 상용 환경용 배포 도구를 다룰 것이다.

컴패니언 VM을 사용하고 싶다면 아래의 “컴패니언 VM 사용 방법” 보충 설명을 참조한 후 2.3 절은 건너뛰어도 된다.

컴패니언 VM 사용 방법 다음 절차를 따른다.

1. http://manning.com/bumgardner에서 VM 이미지를 내려받는다. 2. 버추얼박스를 설치한다(이 VM 이미지는 버추얼박스 4.3.30 버전에서 테스트했다). 3. devstack_icehouse_openstackinaction.zip 파일의 압축을 푼다. 4. devstack_icehouse_openstackinaction.vbox 파일을 더블클릭한다(또는 명령어를 사용 - 자세한 방법은 버추얼박스 문서를 참조).

5. 버추얼박스가 실행되고 devstack_icehouse_openstackinaction VM을 볼 수 있다. 6. devstack_icehouse_openstackinaction VM을 시작한다. 7. VM 설정 화면을 보면 VM의 여러 포트가 로컬 호스트(127.0.0.1 )로 포워딩된다. 이 포 트에는 VM에 SSH로 접속하기 위한 2222와 오픈스택 대시보드에 접속하기 위한 8080 이 포함되어 있다.

8. VM이 시작되면 ID는 sysop, 비밀번호는 u$osuser01을 사용하여 VM에 로그인한다(예 를 들어 ssh -u sysop@127.0.0.1 -p 2222 ).

9. 콘솔에서 stack 사용자로 전환한다. sudo -i -u stack 10. rejoin 스크립트를 실행한다. sudo /opt/devstack/rejoin-stack.sh

2장 오픈스택 맛보기

11. 오픈스택 구성요소와 관련한 스크린screen이 나타날 것이다. 원하는 스크린을 선택하려면 컨트롤+A를 눌렀다 땐 후 " (큰따옴표)를 누른다. 선택할 수 있는 스크린 목록이 나타날 것이다. 다음은 오픈스택에 접속하기 위한 몇 가지 팁이다. ●●

오픈스택 CLI로 작업하기 위해 VM에 접속하고자 한다면 3.1절에 나오는 방법을 사용하면 된다. 오픈 스택 VM의 내부 주소는 10.0.2.32라는 것을 기억해두자.

●●

대시보드에서 작업하기 위해 VM에 접속하고자 한다면 http ://127.0.0.1 :8080으로 접속한 후, 사용 자 이름은 “admin”, 비밀번호는 “devstack”을 사용하면 된다.

베이그런트 사용자인가? 베이그런트Vagrant 사용법은 이 책의 범위를 벗어나지만 devstack -vagrant ( https ://github .com /

openstack-dev/devstack-vagrant )와 vagrant_devstack ( https://github.com/bcwaldon/ vagrant_devstack )과 같이 버추얼박스에서 데브스택을 배포하기 위해 베이그런트를 사용하는 커뮤니티 프로젝트가 많이 존재한다.

다음 단계의 설명을 따라 데브스택을 사용해 오픈스택를 배포해보기를 권장한다. 설치를 해보 면 오픈스택 프레임워크에 빨리 익숙해질 수 있고 그 과정에서 오픈스택 구성요소를 근본적으 로 이해할 수 있다. 빠르고 쉽게 시작하기 위해 데브스택을 사용할 수도 있지만, 배포 스크립트 가 완전히 공개되어 있어 각 오픈스택 구성요소를 원하는 대로 구성할 수도 있다. 심지어 데브 스택을 사용해 다중 서버 오픈스택 환경을 배포하는 것도 가능하다. 이번 장에서는 단일 서버에 모든 구성요소를 배포하는 데 집중할 것이다. 그래야 3장에서 논의 할 오픈스택 구성요소 분산 모델을 완전히 이해하지 못한 상태에서 구성 문제가 발생할 여지를 줄일 수 있다. 단일 서버에서 동작하는 구성요소 간의 관계를 이해하기만 하면 다중 서버에 배 포하는 것은 훨씬 이해하기 쉽다. 다중 서버 오픈스택을 2부에서는 수동으로 배포하고, 3부에 서는 자동으로 배포해볼 것이다. 배포를 시작하려면 오픈스택이 지원하는 리눅스 배포판이 구동 중인 (물리 혹은 가상) 서버가 한 대 필요하다.

1부 시작하기

CHAPTER

오픈스택 기본 작업 방법 오픈스택 CLI로 배포 환경 관리하기

●●

새 테넌트를 만들어보면서 오픈스택 테넌트 모델 살펴보기

●●

테넌트 내부 구성과 함께 기본 테넌트 네트워크 구성하기

●●

오픈스택 네트워크로 내부 및 외부 네트워크 구성하기

●●

테넌트 할당량을 수정해 자원 할당 제어하기

●●

이번 장에서는 2장에서 배포한 오픈스택을 사용하여 오픈스택 관리자나 사용자가 하는 기본적 인 작업 방법을 설명할 것이다. 2장은 최종 사용자가 오픈스택과 상호작용하는 방법에 중점을 두었기 때문에 많은 관리 기능을 쉽게 사용할 수 있는 대시보드를 기반으로 예제를 구성했다. 이번 장에서는 작업 사례를 위주로 설명할 것이므로 오픈스택 명령줄 인터페이스(CLI )를 기 반으로 예제를 구성할 것이다. 시스템 관리자로 일해보았다면 수천 명의 사용자를 생성하는 것과 같은 반복적인 작업을 대신 해주는 스크립트에 고마움을 느낄 것이다. 오픈스택 API는 이런 작업에도 사용할 수 있으며, 이에 대해서도 간단히 소개할 것이다. 곧 알게 되겠지만, CLI로 할 수 있는 작업은 API를 직접 사용해도 쉽게 할 수 있다. 이번 장의 예제에서는 CLI를 계속 사용할 예정이지만, CLI를 통해 개념을 이해하고 난 후에 API나 대시보드를 사용하는 예제도 살펴볼 수 있도록 구성했다.

CLI는 또한 오픈스택 구성요소마다 제공되는 애플리케이션을 사용할 수 있는 장점이 있다. 처 음 보기에는 이러한 방식이 좋지 않아 보일 수도 있지만, 어떤 구성요소가 어떤 역할을 맡고 있 는지를 이해하는 데 도움이 될 것이다. 이번 장에서 다루는 오픈스택의 기본 작업 방법은 2장의 데브스택 배포 환경이나 대규모 다중 서버 상용 환경에도 적용할 수 있다. 2장에서는 Demo 테넌트(프로젝트)와 demo 유저를 사 용했다. 이들 오브젝트는 모두 데브스택이 자동으로 만들어주었지만, 수동으로 배포할 때는 테 넌트, 사용자, 네트워크 등의 오브젝트가 자동으로 생성되지는 않는다. 이번 장에서는 테넌트

3장 오픈스택 기본 작업 방법

내에 필요한 오브젝트를 생성하는 절차를 살펴본다. 이번 장의 마지막쯤에는 오픈스택 테넌트 모델을 사용해 자원을 분리하여 할당하는 방법을 알게 될 것이다. 먼저 오픈스택 CLI를 소개하는 것부터 시작할 것이다. 그 후 테넌트, 사용자, 네트워크를 만드 는 절차를 소개하겠다. 마지막으로, 테넌트 관점에서 할당량을 관리하는 방법도 배울 것이다. 예제를 따라가면서 각 단계에서 사용하는 CLI 애플리케이션에 주목하기 바란다. 오픈스택의 기본 작업 방법을 배울 수 있을 뿐만 아니라 오픈스택 구성요소별로 제공하는 기능을 더 잘 이 해할 수 있을 것이다. 4장에서는 오픈스택 구성요소들 간의 관계를 자세히 다룰 것이다.

3.1 오픈스택 CLI 사용하기 이제 명령줄에서 오픈스택과 상호작용하는 방법을 간단히 살펴보자. CLI 명령어를 실행하기 전에 셸에서 환경 변수를 적절히 설정해야 한다. 환경 변수는 사용자를 인증하는 방법과 인증 위치를 CLI에 알려준다. CLI에 이 변수를 직접 입력할 수도 있지만, 보기 편하게 하기 위해 모 든 예제에서는 적절한 환경 변수를 먼저 설정할 것이다. 이 변수를 설정하기 위해 다음 명령어를 셸에서 실행한다. 세션에 로그인할 때마다 환경 변수 를 설정해야 한다. 목록 3.1 환경 변수 설정하기

source /opt/stack/python-novaclient/tools/nova.bash _completion ❶ source openrc demo demo ❷

❶ “명령어 /bo”를 입력한 후에 탭(tab ) 키를 누르면 “명령어 /boot”가 완성되도록 셸 자동 완성 기능을 위한 변수를 설정한다. ❷ 이 명령어는 ~/devstack 디렉터리에서 실행한다. 오픈스택 CLI 명령어를 실행할 때 demo 테넌트의

demo 사용자로 인증받을 것이다.

1부 시작하기

수동으로 환경 변수 설정하기 경험이 많거나 데브스택을 사용하고 있지 않다면 다음 명령어를 실행하여 환경 변수를 수동으로 설정할 수 있다. 다음 예제에서 사용한 명령어의 값은 개별 환경에 맞춰 변경해야 한다.

export export export export

OS_USERNAME=admin OS_PASSWORD=devstack OS_TENANT_NAME=admin OS_AUTH_URL=http://10.0.2.32:5000/v2.0

이 명령어 예제는 현재 셸 사용자를 오픈스택 admin 테넌트의 admin 사용자로 설정할 것이다.

변수가 적절히 설정되었는지 확인하려면 오픈스택 CLI 명령어를 실행할 수 있는지 테스트해봐 야 한다. 셸에서 [목록 3.2 ]처럼 nova image-list 명령어를 입력한다. 이 CLI 명령어는 방금 설정한 환경 변수를 읽어 인증에 사용한다. 정상적으로 인증되어 적절한 권한을 얻었다면 CLI 는 현재 사용할 수 있는 이미지 목록을 오픈스택 컴퓨트(노바)에 질의할 것이다. 목록 3.2 변수 설정 및 첫 CLI 명령어 실행하기

❶ 이 간단한 명령어로 노바 이미지를 출력할 수 있다.

이제 demo 테넌트의 demo 사용자로 CLI 명령어를 실행할 수 있다. 이 사용자는 2장에서 사 용한 것과 동일한 사용자이므로 CLI로 변경한 모든 것이 대시보드에도 반영될 것이다. [목록

3장 오픈스택 기본 작업 방법

3.3 ]의 명령어를 사용하면 대시보드에서 했던 것과 같이 새 오픈스택 인스턴스를 만들 수 있 다. 2장에서 언급한 바와 같이 이 책의 목적상 오픈스택 인스턴스는 VM으로 간주한다. 목록 3.3 CLI로 인스턴스 시작하기

nova boot \ ❶ --flavor <플레이버 ID> \ ❷ --image <이미지 ID> \ ❸ <인스턴스 이름> ❹

❶ 인스턴스를 생성하여 시작하도록 노바에게 알려준다. ❷ nova flavor -list 명령어를 통해 출력된 플레이버 ID (크기)를 지정한다. ❸ nova image -list 명령어를 통해 출력된 이미지 ID를 지정한다. ❹ 인스턴스의 이름을 지정한다.

1부 시작하기

CLI를 이용하면 대시보드로 할 수 있는 모든 것은 물론이거니와 그 이상의 것도 할 수 있다. 앞 의 예제에서는 nova boot 명령어로 새 VM을 프로비저닝했다. 노바 명령어에 대한 더 자세한 도움말이 필요하면 nova help <확인하고 싶은 명령어>를 사용하면 된다. 키스톤, 글랜스, 뉴 트론 등에도 이와 유사한 명령줄 유틸리티가 있다. 지금까지 오픈스택 CLI의 기본적인 동작 방식을 알아보았다. 앞으로는 CLI를 사용하여 대부 분의 작업을 할 것이므로 데브스택의 내부 동작을 알아두면 언젠가 문제 해결에 도움이 될 것 이다. 테넌트 예제로 넘어가기 전에 먼저 오픈스택 API의 구조를 살펴보자.

3.2 오픈스택 API 사용하기 지금쯤 아마 오픈스택 CLI는 과연 어떻게 동작하는지가 궁금할 것이다. 이 질문의 답은 CLI 애 플리케이션이 각 오픈스택 구성요소별 API를 호출한다는 것이다. 각 구성요소별 API는 다른

API나 관계형 데이터베이스 등 수많은 요소와 연동한다. 2장에서 사용한 대시보드도 마찬가지 다. 모든 오픈스택의 상호작용은 결국 오픈스택 API 계층으로 돌아온다. 오픈스택 API 고유의 제조사 중립성은 분명 오픈스택의 가장 큰 장점이다. 오픈스택 API의 내 용은 책 한 권 전체를 할애해야 할 정도로 방대하다. 외부 시스템과 통합하길 원하거나 오픈스 택 코드를 디버깅하고 싶다면 API 계층을 살펴보면 된다. 분명히 기억해두어야 할 것은 모든 길은 오픈스택 API로 통한다는 것이다. API에 더 관심이 있다면 “CLI 디버깅/API 출력하기” 보충 설명을 참조하길 바란다. 직접 오픈스택 API를 사용해보려면 [목록 3.4 ]의 예제를 따라 해보자. 이 명령어는 오픈스택

API에 정보를 질의하고, API는 JSON 형식으로 결과를 반환한다. 파이썬은 JSON을 화면에 서 읽기 좋게 파싱하기 위해 사용한다.

3장 오픈스택 기본 작업 방법

목록 3.4 첫 번째 API 명령어 실행하기

curl -s -X POST http://10.0.2.32:5000/v2.0/tokens \ ❶ -d '{"auth": {"passwordCredentials": \ {"username":"demo", "password":"devstack"}, \ "tenantName":"demo"}}' -H "Content-type: application/json" | \ python -m json.tool

❶ 10.0.2.32 대신에 자신의 환경에 맞는 IP를 입력한다.

CLI 디버깅/API 출력하기 디버깅 플래그가 설정되면 모든 CLI 명령어는 대응하는 API 명령어를 출력한다. 특정 CLI 명령 어에 디버깅을 활성화하고 싶다면 다음과 같이 다른 변수 앞에 --debug 매개변수를 전달한다. devstack@devstack:~$ nova --debug image-list REQ: curl -i 'http://10.0.2.32:5000/v2.0/tokens' -X POST -H "Content-Type: application/json" -H "Accept: application/json" -H "User-Agent: python-novaclient" -d '{"auth": {"tenantName": "admin", "passwordCredentials": {"username": "admin", "password": "devstack"}}}' ...

오픈스택 CLI와 API의 구조를 이해했으므로 이제 이 기법을 사용할 준비가 되었다. 다음 절에 서는 CLI를 사용해 새 테넌트(프로젝트)를 만들어볼 것이다. 일반 테넌트에서 분리하고 싶은 새 부서, 새 사용자, 새 프로젝트를 위해 이 기능을 사용할 것이다.

100 1부 시작하기

CHAPTER

사설 클라우드 구성요소 이해하기 오픈스택 핵심 프로젝트 상호운용성 이해하기

●●

제조사 하드웨어와 오픈스택 간의 관계 살펴보기

●●

오픈스택 수동 설치하기

●●

1장에서는 오픈스택을 소개했다. 오픈스택이 클라우드 생태계에 얼마나 적합한지와 오픈스택 기술이 채택된 이유, 그리고 이 책에서 중점을 두고 있는 항목을 설명했다. 2장에서는 큰 그림 에서 보는 개념부터 시작해서 데브스택을 이용해 오픈스택 프레임워크를 체험해보는 실습을 해보았다. 3장에서는 오픈스택 운영자로 일하면서 접할 수 있는 사례를 살펴보면서 오픈스택 의 구조에 대해 더 깊이 이해할 수 있었다. 이번 장에서는 큰 그림에서 보는 개념으로 되돌아간다. 1장에서 오픈스택을 소개하고 알려주 었다면, 2장은 오픈스택 기술에 대한 흥미를 불러 일으켰고, 3장은 오픈스택을 쉽고 편하게 운 영하는 방법을 알려주었다. 4장은 오픈스택 프레임워크 내부에서 실제로 일어나는 일을 근본 적으로 이해하도록 해준다. 이번 장은 1장처럼 생각할 거리가 많거나 2장과 3장처럼 재미있지는 않을 것이다. 하지만 독 자들이 시스템 관리자, 개발자, IT 아키텍트, 심지어 CTO라도 관계없이, 이번 장이 오픈스택 을 이해하는 데 가장 중요한 장이 될 것이다. 독자들이 최전방에 나서서 오픈스택을 다룰 예정 이라면 이번 장은 그렇게 할 수 있는 토대를 마련해줄 것이고, 5장부터 8장을 통해 그 토대가 더 견고해질 것이다. 독자들이 오픈스택을 관리자 입장에서 다룰 예정이고 단순히 업체의 도움 을 받는 솔루션만 담당하게 되더라도 이번 장은 오픈스택 배포 환경을 구성하고 상호작용하는 여러 요소를 이해하는 데 도움을 줄 것이다. 무엇을 기다리는가? 당장 시작해보자!

4장 사설 클라우드 구성요소 이해하기 135

4.1 오픈스택 구성요소에는 어떤 관계가 있는가? 오픈스택 프레임워크는 2010년에 최초로 공식 발표되었을 때는 단 몇 개의 핵심 구성요소만 갖췄었으나 현재는 10여 개로 규모가 늘어났다. 현재는 다양한 수준의 상호운용성을 가지는 수백 개의 오픈스택 연관 프로젝트가 존재한다. 이 프로젝트들은 오픈스택 라이브러리에 의존 하는 소프트웨어부터 반대로 오픈스택 프레임워크가 의존하는 프로젝트까지 범위가 다양하다. 다양한 프로젝트를 구조화하려는 노력의 일환으로 오픈스택 재단은 핵심Core, 배양 Incubated, 라 이브러리Library, 게이팅Gating, 지원Supporting, 연관Related 등 여러 프로젝트 명칭을 만들었다. 이 프 로젝트의 명칭과 설명을 [표 4.1 ]에서 확인할 수 있다. 표 4.1 프로젝트 명칭 프로젝트 명칭

설명

핵심

공식 오픈스택 프로젝트(대부분 이 프로젝트를 사용)

배양

개발 중인 핵심 프로젝트(핵심 프로젝트가 되는 절차를 진행 중)

라이브러리

핵심 프로젝트가 의존하는 소프트웨어

게이팅

통합 테스트 도구 모음과 개발 도구

지원

문서화와 개발 인프라

연관

비공식 프로젝트(자체적으로 관련된 프로젝트)

개발이 완료되어 승인받은 배양 프로젝트는 최종적으로 핵심 프로젝트가 되어 제 기능을 하게 된다. 라이브러리 함수들은 핵심 프로젝트와의 상호작용을 통해 추상화(보이지 않게)된다. 게 이팅과 지원 프로젝트는 배포된 시스템의 자원을 제공하기 위해서 사용하는 것이 아니므로 이 들에 대해서는 크게 신경 쓰지 않아도 된다. 마지막으로 연관 프로젝트는 그 이름이 암시하는 바와 같이 오픈스택과 어느 정도 관련이 있다고 분류된 프로젝트다.

4.1.1 구성요소 간 통신 이해하기 사람들이 “오픈스택”을 언급할 때는 보통은 “핵심” 프로젝트를 지칭하는 것이다. 오픈스택 재 단의 규정에 따르면 핵심 프로젝트는 오픈스택 로고를 사용할 수 있으며 필수 테스트를 반드시 통과해야만 한다. 간단히 말해서 대부분의 사람이 오픈스택 배포 환경에서 사용하는 것이 바로

136 1부 시작하기

핵심 프로젝트다. [표 4.2 ]에서 보듯이 컴퓨트, 네트워크, 스토리지, 공유 서비스, 대시보드 등 의 프로젝트가 핵심 프로젝트의 예다. 표 4.2 핵심 프로젝트 프로젝트 컴퓨트

코드명 Nova

노바

설명

CPU, 메모리, 디스크, 네트워크 인터페이스 등 가상 머신(VM)의 자원 을 관리

네트워크

뉴트론Neutron

IP 주소, 라우팅, 소프트웨어 정의 네트워크(SDN) 등 VM의 네트워크 인터페이스가 사용하는 자원을 제공

오브젝트 스토리지

스위프트Swift

RESTful API로 접근할 수 있는 오브젝트 수준의 스토리지를 제공

블록 스토리지

신더Cinder

VM에 블록 수준(일반적인 디스크)의 스토리지를 제공

아이덴티티 서비스

Keystone

키스톤

(공유 서비스) 이미지 서비스

RBAC

를 관리하고 인증 서비스를 제공

글랜스Glance

(공유 서비스) 텔레메트리 서비스

실로미터Ceilometer

오픈스택 구성요소의 사용량 측정 및 모니터링을 위한 도구 모음을 제공

Heat

히트

(공유 서비스) 데이터베이스 서비스

VM의 디스크 이미지 관리. VM에 이미지 제공 및 스냅샷(백업) 서비 스를 제공

(공유 서비스) 오케스트레이션 서비스

오픈스택 구성요소를 위한 역할 기반 접근 제어Role-Based Access Control,

오픈스택 환경을 위한 템플릿 기반의 클라우드 애플리케이션을 오케스 트레이션하는 기능을 제공

트로브Trove

관계형 및 비관계형 데이터베이스 서비스를 제공

호라이즌Horizon

오픈스택으로 작업하기 위한 웹 기반의 GUI 제공

(공유 서비스) 대시보드

다양한 프로젝트 명칭 외에도 프로젝트 구성요소를 배포하는 다양한 토폴로지도 존재한다. 특 정 자원(스토리지, 컴퓨트, 네트워크 등)이 더 많이 필요하면 해당 구성요소 전용 서버를 더 추가할 수 있다. 프로젝트 명칭 및 그와 관련된 구성요소에 대해서는 4.1.2절에서 논의할 것 이다.

대시보드 인증을 위한 통신 이제 본격적으로 핵심 구성요소들이 어떻게 통신하는지를 살펴보자. 오픈스택 대시보드에 접 속하는 절차를 알아보고 가상 머신 생성 옵션을 검토한 후 가상 머신을 생성해볼 것이다. 먼저 대시보드에 로그인 자격증명을 제공해 인증 토큰을 얻어야 한다. 인증 토큰은 웹 브라우

4장 사설 클라우드 구성요소 이해하기 137

저에 쿠키로 저장되어 다음 요청 시 사용된다. [그림 4.1 ]에서 보듯이 아이덴티티 서비스에서 인증 토큰을 받는다. 이 책의 나머지 예제에서 대시보드(CLI나 API가 아님) 화면에서 원하는 곳을 찾아 가는 방법을 일일이 설명하지는 않을 것이다. 로그인하는 동안, 대시보드는 단순히 웹 브라우저와 오픈스택 API 간의 상호작용만 표시한다. 여기서는 주로 API 수준의 구성요소 간 상호작용에 관심을 둘 것이다. 그림 4.1 대시보드 로그인

1. 로그인하려

2. 사용자 정보가

합니다.

맞나요? 키스톤 아이덴티티

4. 이 토큰을 인증에 사용하세요.

3. 네, 인증 토큰은 여기 있어요.

인증 토큰을 받았다면 다음 단계로 컴퓨트에 접근해 가상 머신을 만들 수 있다.

자원 확인 및 요청을 위한 통신 3장에서 설명한 것처럼 오픈스택은 테넌트 모델을 기반으로 동작한다. 오픈스택 배포 환경이 자 원의 호텔이라면 테넌트는 호텔의 방으로 볼 수 있다. 각 테넌트(방)에는 자원 할당량(타월, 침 대 등)이 정해져 있다. 오픈스택 사용자(고객)는 역할이라는 것을 통해 테넌트(방)에 할당된 다. 인증 정보는 아이덴티티 구성요소가 보관하며 할당량 정보는 컴퓨트 구성요소가 관리한다. 대시보드에서 [Launch Instance ]를 클릭하면 현재 테넌트에서 어떤 자원과 구성을 사용할 수 있는지를 확인하는 질의가 컴퓨트 구성요소에 전달된다. 사용자는 사용 가능한 자원과 구성 에 따라 VM을 원하는 대로 구성한 후 생성을 요청할 수 있다.

VM 생성을 요청하는 과정에서 구성요소 간에 주고 받는 통신을 [그림 4.2 ]에서 볼 수 있다. VM이 순간적으로 생성되지는 않기 때문에 이 절차는 비동기적으로 실행되고, 따라서 사용자 가 VM을 프로비저닝하도록 요청한 후에는 대시보드 화면으로 바로 복귀한다. 웹 브라우저는

VM의 상태 정보를 대시보드에 주기적으로 갱신한다.

138 1부 시작하기

그림 4.2 자원 질의와 요청

가용 자원이 있나요?

CPU/RAM/스토리지, 네트워크, 이미지

CPU:2, RAM:8GB, 스토리지:40GB, 사설 네트워크, 우분투 리눅스 이미지로 myVM을 생성해주세요.

1. VM 생성을 위해 어떤 자원을 사용할 수 있나요?

노바

컴퓨트 2. X 만큼의 자원 (CPU, RAM, 스토리지) 할당량, 사설 및 공용 네트워크 접근 권한, 우분투 리눅스 12.04 이미지를 사용할 수 있습니다.

3. 지정한 자원을 사용해 myVM을 생성해주세요

노바

컴퓨트

myVM을 프로비저닝...

4. myVM의 프로비저닝 절차를 시작하세요.

자원 프로비저닝을 위한 통신 VM 생성을 요청하면 컴퓨트 서비스 구성요소는 요청된 VM을 프로비저닝하기 위해 다른 구성 요소와 협업할 것이다. 먼저 VM 오브젝트 정보가 컴퓨트 서비스 구성요소에 등록된다. 이 오 브젝트 정보에는 VM의 상태와 구성 정보가 포함되어 있다. VM 오브젝트는 VM 인스턴스 자 체는 아니고 단지 인스턴스를 기술하는 정보일 뿐이다.

VM 생성 과정에서 구성요소 간에 통신을 할 때 각 구성요소는 이 VM 오브젝트 같은 공통 오 브젝트를 참조한다. 예를 들어 컴퓨트 서비스 구성요소가 스토리지 서비스 구성요소에게 스토 리지를 할당해달라고 요청할 수 있다. 그러면 스토리지 서비스 구성요소는 요청한 스토리지를 프로비저닝한 후 그 응답으로 해당 스토리지 오브젝트에 대한 참조를 넘겨주며, 이를 VM 오브 젝트가 참조한다.

4장 사설 클라우드 구성요소 이해하기 139

[그림 4.3 ]에서 보듯이 컴퓨트 서비스 구성요소는 VM 오브젝트에 자원을 프로비저닝하여 할 당하기 위해 다른 핵심 구성요소와 통신을 한다. 컴퓨트는 먼저 스토리지나 네트워크 같은 인 프라 구성요소를 요청한다. VM 오브젝트가 VM에 할당된 가상 인프라를 참조하고 나면 이미 지 서비스는 요청한 이미지나 스냅샷으로 가상 스토리지 볼륨을 준비할 것이다. 이 시점에서

VM 생성 절차가 완료되며 컴퓨트 구성요소는 VM을 실행할 수 있다. 그림 4.3 자원 프로비저닝하기

1. CPU:2, RAM:8GB로 myVM을 생성해주세요.

신더

스토리지

2. myVM에 40GB가 필요합니다.

7. OK. myVM의 볼륨에 이미지 를 복제했습니다.

노바

3. OK. 40GB를 할당했습니다.

6. myVM의 40GB 볼륨에 우분투 리눅스 12.04를 복제한 이미지가 필요합니다.

컴퓨트

4. myVM의 사설 네트워크용 가상 어댑터가 필요합니다.

글랜스 이미지

5. OK. myVM에 사설 네트워크용 어댑터를 할당했습니다.

뉴트론

네트워크

[그림 4.3 ]처럼 여러 핵심 구성요소는 오픈스택 서비스를 제공하기 위해 서로 협력하며 동작한 다. 오픈스택의 상호작용, 심지어 대시보드에서의 상호작용도 결국 오픈스택 API로 귀결된다. 다음 절에서 알게 되겠지만 보통 연관 프로젝트도 단독으로 API 호출을 사용해 오픈스택과 상 호작용한다.

140 1부 시작하기

Part

오픈스택 수동 배포하기

2부에서는 여러 오픈스택 핵심 구성요소의 수동 배포를 단계적으로 진행할 것이다. 오픈스택 구성요소 간

의 상호작용을 이해하는 것도 중요하지만, 2부가 오픈스택을 배포할 때 단순히 참조하기 위한 지침서로 의 도된 것은 아니다. 각 소프트웨어 버전을 위한 상세 문서는 오픈스택 재단에서 제공하고 있다(http://docs. openstack.org/). 2부의 목표는 구성요소와 구성 정보의 깊은 부분까지 파헤쳐 오픈스택에 대한 독자들의

자신감을 확립하는 것이다. 또한 독자들이 상용 환경을 설계할 때 정보에 입각해 결정할 수 있을 정도로 오픈 스택 아키텍처를 충분히 이해할 수 있게 도와주는 것이다.

5장 컨트롤러 배포하기 165

Part II

오픈스택 수동 배포하기

5장

컨트롤러 배포하기

6장 네트워크 배포하기 7장

블록 스토리지 배포하기

8장 컴퓨트 배포하기

166 2부 오픈스택 수동 배포하기

CHAPTER

컨트롤러 배포하기 컨트롤러 사전 준비 사항 설치하기

●●

공유 서비스 배포하기

●●

컨트롤러 측 블록 스토리지, 네트워크, 컴퓨트, 대시보드 서비스 구성하기

●●

처음 두 장에서 오픈스택을 소개하고 호라이즌 웹 인터페이스를 사용해 프레임워크를 맛보았 다. 3장에서는 명령줄 인터페이스(CLI )를 사용한 기본적인 운용 작업을 소개했다. 4장에서는 다중 노드 환경에서 오픈스택 구성요소가 어떻게 연관돼 분산되어 있는지를 설명했다. 이 책의

1부는 오픈스택이 할 수 있는 것을 이해하고, 프레임워크를 운용하는 데 익숙해지고, 프레임워 크 구성요소가 상호작용하는 방법을 이해할 수 있도록 설계했다. 2부에서는 구성요소 그 자체 를 자세히 설명할 것이다.

2부를 다 읽고 나면 오픈스택 핵심 구성요소 각각의 구성, 사용법, 배치에 익숙하게 될 것이다. 이 책의 목적 이 책은 오픈스택 운용이나 아키텍처에 대한 모범 사례에는 집중하지 않는다. 이 주제 또한 중요하지만 오픈 스택 버전과 사용자 요구사항에 상당히 의존적이다. 이 책의 목적은 개별적인 요구사항을 넘어 오픈스택의 미래 버전에서도 유지될 오픈스택 프레임워크의 기본을 이해하도록 도와주는 것이다.

1부는 데브스택을 사용해 오픈스택 구성요소 및 의존 소프트웨어를 설치하고 구성한 단일 노 드 배포 환경을 기반으로 했다. 2부는 다중 노드에 수동으로 배포한 오픈스택을 기반으로 하므 로 데브스택은 더 이상 사용하지 않을 것이다. 2부에서는 리눅스 배포판에서 제공하는 패키지 관리 시스템을 사용해 구성요소 소프트웨어를 설치한 후 수동으로 구성한다. 이 과정을 통해 개별 오픈스택 구성요소의 의존성, 구성, 관계, 사용법을 이해할 수 있을 것이다.

5장 컨트롤러 배포하기 167

[그림 5.1 ]은 2부에서 새로 생성할 아키텍처를 보여준다. 이 그림에서는 네 가지 노드를 볼 수 있다. 컨트롤러 – 컨트롤러 자체와 다른 공유 서비스를 관리하는 노드. 서버 측 API 서비스를 관리하며, 구성요소의

●●

요청을 조율하고 오픈스택 배포를 위한 주요 인터페이스 역할을 한다. 네트워크 – 가상 머신에 네트워크 자원을 제공하는 노드. 오픈스택 내부 네트워크와 외부 네트워크를 연결

●●

한다. 스토리지 – 가상 머신에 스토리지 자원을 제공하고 관리하는 노드

●●

컴퓨트 – 가상 머신에 컴퓨트 자원을 제공하는 노드. 코드는 여기에서 실행된다. 오픈스택이 관리하는 가상 머

●●

신은 이 노드에서 동작한다고 볼 수 있다.

그림 5.1 다중 노드 아키텍처 컨트롤러 노드는 오픈스택 배포를 위한 주요 인터페이스며 …

… 컨트롤러와 공유 서비스를 수용 하고 서비스를 관리하고 각종 요청 을 조율한다. 컨트롤러

키스톤

글랜스

호라이즌

아이덴티티

이미지

대시보드

뉴트론

노바

신더

네트워크

컴퓨트

스토리지

내부 네트워크

공인 네트워크

네트워크 노드는 VM에 네트 워크 자원을 제공하며, 오픈 스택 내부 네트워크와 외부 네트워크를 연결한다.

뉴트론

신더

스토리지 노드는

VM에 스토리지 자 원을 제공하고 관리 한다.

네트워크

클라이언트 네트워크

168 2부 오픈스택 수동 배포하기

노바

컴퓨트

스토리지

컴퓨트 노드는 VM에 컴퓨트 자원을 제공한다. 코드는 여기에서 실행된다. 오픈스택이 관리하는 VM도 여기에서 동작한다.

4장에서 설명한 것처럼 오픈스택 배포 모델에서 자원 노드는 컨트롤러의 지시를 받는다([그림 5.1 ] 참조). [그림 5.2 ]에서 보듯이 앞으로 여러 장에 걸쳐 다중 노드 배포 환경의 각 부분을 구축할 것이다. 이번 장에서는 컨트롤러 노드(그림의 상단)를 구축할 것이다. 이어지는 세 개 의 장에서는 남은 다른 노드(네트워크, 스토리지, 컴퓨트)를 구축해 다중 노드 수동 배포를 완 료할 것이다. 그림 5.2 오픈스택 배포 로드맵

컨트롤러

5장

키스톤

글랜스

호라이즌

아이덴티티

이미지

대시보드

뉴트론

노바

신더

네트워크

컴퓨트

스토리지

노바

신더

뉴트론

6장

7장 네트워크

컴퓨트

스토리지

8장

5.1 컨트롤러의 사전 준비 사항 배포하기 이 장을 계속 진행하기 전에, 새로 설치한 우분투 14.04 물리 또는 가상 노드에 접속할 수 있어 야 한다. 우분투 14.04 설치 방법은 부록으로 제공한다.

5장 컨트롤러 배포하기 169

어떤 OS 배포판을 사용해야 하는가?

2부(5장에서 8장까지)의 예제에서는 14.04 LTSLong Term Support 버전의 우분투 서버를 사용할 것이다. 이 우분투 버전은 오픈스택 아이스하우스 버전을 포함하고 있고 2019년 4월까지 지원을 보장한다.

2장에서 데브스택을 설치하고 오픈스택 의존 소프트웨어를 구성해보았다. 이번 장에서는 이 의존 소프트웨어를 수동으로 설치할 것이다. 다행히 패키지 관리 시스템을 사용해 소프트웨 어를 설치할 수 있다(컴파일할 필요는 없다). 그러나 구성요소는 여전히 수동으로 구성해야 한다. 진행 시 주의 사항 다중 노드 환경에서 작업하면 배포가 훨씬 복잡해진다. 구성요소나 의존 소프트웨어를 구성할 때 저지른 별 관련이 없어 보이는 작은 실수조차도 추적하기 매우 어려운 문제를 일으킬 수 있다. 모든 절을 주의 깊게 읽 고, 무엇을 설치하고 구성 중인지를 확실히 이해하고 있어야 한다.

앞으로 나올 여러 예제는 검증 절차를 포함하고 있으며, 이를 생략해서는 안 된다. 구성한 것이 검증을 통과하지 못하면 마지막 검증 지점으로 되돌아가 다시 시작하는 것이 좋다. 이런 연습 을 통해 많은 실패를 줄일 수 있을 것이다.

5.1.1 환경 준비하기 네트워크 구성을 제외하고 환경을 준비하는 절차는 모든 노드에서 비슷하다. 5장부터 8장에 걸쳐 컨트롤러, 네트워크, 스토리지, 컴퓨트 노드를 네 개의 물리 노드에 수동으로 배포할 것 이다. 추가 노드를 사용할 수 있다면 해당 자원을 반복해서 구성해 추가 자원 노드(컴퓨트, 네트워 크, 스토리지)를 배포 환경에 간단히 추가할 수 있다. 컴퓨트 노드를 추가하고 싶다면, 간단히 컴퓨트 노드 구성을 설명하는 8장의 절차를 반복하면 된다. 노드가 몇 개밖에 없다면 네트워크 와 컴퓨트 같은 서비스를 하나의 노드에 배포할 수 있다. 분명히 구분하기 위해 2부의 예제에 서는 핵심 오픈스택 서비스를 개별 노드에 분리하여 구성한다. 2장에서 배웠다시피 오픈스택 을 하나의 노드에 넣을 수도 있지만 다중 노드야말로 진짜 재미(장점)가 있는 곳이다.

170 2부 오픈스택 수동 배포하기

이제 시작할 때다. 이번 장에 시간을 어느 정도 투자하는 것이 좋다. 컨트롤러를 구축할 때 모 든 백엔드 서비스를 구성해야 하므로 설치에 시간이 걸릴 수 있다. 일단 컨트롤러가 동작하면 자원 노드(네트워크, 스토리지, 컴퓨트)를 구성하는 것은 시간이 덜 걸린다.

5.1.2 네트워크 인터페이스 구성하기 한 인터페이스는 클라이언트의 트래픽을 위해, 또 다른 인터페이스는 내부 오픈스택 관리를 위 해 사용하도록 컨트롤러 노드의 네트워크 인터페이스를 구성해야 한다. 기술적으로는 컨트롤 러에 하나의 인터페이스만 사용할 수도 있으나, 곧 알게 되겠지만 오픈스택 운용을 위해 (공 인, 내부, 관리 등) 여러 네트워크를 지정할 수 있다.

네트워크 확인하기 네트워크 인터페이스를 구성하는 첫 번째 단계는 서버에 어떤 물리 인터페이스가 있는지를 확 인하는 것이다. 그 후 오픈스택 환경에서 사용할 인터페이스를 구성할 수 있다. 다음 목록에서 보듯이 ifconfig -a 명령어로 인터페이스를 출력할 수 있다. 목록 5.1 인터페이스 출력하기

$ ifconfig -a em1 Link encap:Ethernet HWaddr b8:2a:72:d3:09:46 inet addr:10.33.2.50 Bcast:10.33.2.255 inet6 addr: fe80::ba2a:72ff:fed3:946/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:950 errors:0 dropped:0 overruns:0 frame:0 TX packets:117 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:396512 (396.5 KB) TX bytes:17351 (17.3 KB) Interrupt:35 em2 Link encap:Ethernet HWaddr b8:2a:72:d3:09:47 BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) Interrupt:38

5장 컨트롤러 배포하기 171

여러 인터페이스를 볼 수 있지만 지금은 공인 네트워크와 내부 네트워크에 사용할 em1과

em2 인터페이스에만 집중한다. 예제 컨트롤러에서 em1은 공인 인터페이스로 사용하고 em2 는 내부 인터페이스로 사용한다. 오픈스택 공인 주소로 사용할 주소는 em1에 이미 할당했고

em2 인터페이스는 내부 인터페이스로 사용한다. 특정 네트워크 주소, VLAN, 인터페이스 기 능은 다음 절에서 설명할 것이다. 다음으로 컨트롤러 노드의 물리 인터페이스를 구성해야 한다.

네트워크 구성하기 우분투에서는 /etc/network/interfaces 파일에서 인터페이스 구성을 관리한다. 다른 리눅스 배포판을 사용한다면 해당 배포판과 버전에서 네트워크 인터페이스를 구성하는 방법을 확인해 야 한다. [표 5.1 ]의 이탤릭체로 된 IP 주소에 따라 컨트롤러 노드를 구성할 것이다. 표 5.1 네트워크 주소 표 노드

기능

인터페이스

IP 주소/서브넷마스크

컨트롤러

공인 인터페이스/노드 주소

em1

10.33.2.50/24

컨트롤러

오픈스택 내부

em2

192.168.0.50/24

네트워크

노드 주소

em1

10.33.2.51/24

네트워크

오픈스택 내부

em2

192.168.0.51/24

네트워크

VM 인터페이스/네트워크

p2p1

없음: 오픈스택 네트워크에 할당

스토리지

노드 주소

em1

10.33.2.52/24

스토리지

오픈스택 내부

em2

192.168.0.52/24

컴퓨트

노드 주소

em1

10.33.2.53/24

컴퓨트

오픈스택 내부

em2

192.168.0.53/24

이 표에서 기능 열의 용어에 대한 설명은 다음과 같다. 공인 인터페이스 – 테넌트 사용자, 호라이즌, 공개 API 호출이 접근

●●

노드 주소 – 노드의 기본 주소. 이 주소는 공인 주소일 필요는 없으나, 간단히 하기 위해 컨트롤러 노드의 공인

●●

인터페이스와 자원 노드의 노드 인터페이스를 동일한 네트워크에 둘 것이다.

172 2부 오픈스택 수동 배포하기

오픈스택 내부 – AMQP, 내부 API 등의 오픈스택 구성요소 트래픽을 노드 간에 전달하기 위한 인터페이스

●●

네트워크 인터페이스 이름 네트워크 인터페이스 이름은 서버의 하드웨어 순서와 위치에 따라 다르다. 예를 들어 온보드 인터페이스는

em<포트 번호> 형태로 표시되는 반면에 PCI 확장 인터페이스는 p<슬롯 번호>p<포트 번호>_<가상 함수 인 스턴스>로 표시된다.

네트워크 구성이나 특권이 필요한 구성 정보를 수정하려면 sudo 권한 ( sudo vi /etc /

network/interfaces )을 사용해야 한다. 알다시피 sudo 명령어를 사용하면 일반 사용자가 (sudo 그룹에 포함되어 있는 경우) 상승된 권한으로 명령어를 실행할 수 있다. 다음 목록은 네트워크 인터페이스 구성 예를 보여준다. [표 5.1 ]의 값 또는 독자가 사용하는 주 소 체계에 따라 인터페이스 구성을 수정한다. 목록 5.2 /etc/network/interfaces에서 인터페이스 구성 수정하기

# 루프백 네트워크 인터페이스 auto lo iface lo inet loopback # 공인/노드 네트워크 인터페이스 auto em1 iface em1 inet static address 10.33.2.50 netmask 255.255.255.0 network 10.33.2.0 broadcast 10.33.2.255 gateway 10.33.2.1 dns-nameservers 8.8.8.8 dns-search testco.com # 오픈스택 내부 인터페이스 auto em2 iface em2 inet static address 192.168.0.50 netmask 255.255.255.0

이제 네트워크 설정을 다시 읽어 네트워크 구성 변경 사항을 갱신해야 한다. 하지만 먼저 주 인

5장 컨트롤러 배포하기 173

터페이스의 주소를 변경했다면 변경 사항을 적용한 후에는 시스템 접속이 끊어지니 이 시점에 서 서버를 재부팅해야 한다. 주 인터페이스의 설정을 바꾸지 않았다면 접속이 중단되지는 않을 것이다. 다음 목록은 네트워크 설정을 다시 읽기 위해 사용하는 명령어를 보여준다. 목록 5.3 네트워크 설정 다시 읽기

$ sudo ifdown em2 && sudo ifup em2

이제 네트워크 구성이 활성화되었다. 인터페이스는 구성 정보를 반영하여 자동으로 온라인 상 태가 될 것이다. 구성 정보 갱신이 필요한 모든 인터페이스마다 이 절차를 반복하자. 구성 정보가 적용된 것을 확인하려면 다음과 같이 인터페이스를 다시 한 번 확인해야 한다. 목록 5.4 네트워크 갱신 상태 확인하기

$ ifconfig -a em1 Link encap:Ethernet HWaddr b8:2a:72:d3:09:46 inet addr:10.33.2.50 Bcast:10.33.2.255 Mask:255.255.255.0 inet6 addr: fe80::ba2a:72ff:fed3:946/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:3014 errors:0 dropped:0 overruns:0 frame:0 TX packets:656 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:2829516 (2.8 MB) TX bytes:94684 (94.6 KB) Interrupt:35 em2

Link encap:Ethernet HWaddr b8:2a:72:d3:09:47 inet addr:192.168.0.50 Bcast:192.168.0.255 Mask:255.255.255.0 inet6 addr: fe80::ba2a:72ff:fed3:947/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:1 errors:0 dropped:0 overruns:0 frame:0 TX packets:6 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:64 (64.0 B) TX bytes:532 (532.0 B) Interrupt:38

174 2부 오픈스택 수동 배포하기

이제 컨트롤러 서버에 원격으로 접속할 수 있어야 하며 컨트롤러 서버에서도 인터넷에 접속할 수 있어야 한다. SSH로 원격 접속 또는 콘솔로 직접 접속하여 남은 설치를 진행할 수 있다.

5.1.3 패키지 갱신하기 우분투 14.04 LTS는 아이스하우스 버전의 오픈스택을 내장하고 있으며, 이 버전의 오픈스택 은 다음 구성요소를 포함하고 있다. 노바 - 오픈스택 컴퓨트 프로젝트의 이름으로 IaaS 클라우드 패브릭 컨트롤러로 동작

●●

글랜스 - VM 이미지 검색, 등록을 위한 서비스를 제공

●●

스위프트 - 확장성 높은 분산 오브젝트 스토리지 서비스를 제공

●●

호라이즌 - 오픈스택 대시보드 프로젝트의 이름으로 웹 기반의 관리자 및 사용자 GUI를 제공

●●

키스톤 - 오픈스택 구성요소에 인증, 토큰, 카탈로그, 정책 서비스를 제공

●●

뉴트론 - 오픈스택 구성요소에 네트워크 관리 서비스를 제공

●●

신더 - 오픈스택 컴퓨트에 블록 스토리지 서비스를 제공

●●

실로미터 - 각종 자원 사용률 통계를 기록하는 중앙 지점

●●

히트 - 오픈스택 자원의 애플리케이션 오케스트레이션을 제공

●●

다른 버전의 OS나 오픈스택을 사용하고 싶다면 다른 리눅스 배포판이나 더 최신의 오픈스택을 사용하고 싶을 수도 있다. 하지만 지정한 버전을 유지하기를 적극 권장한다. 오픈스택을 자유롭게 운용할 수 있는 수준으로 이해한 후에는 언제든 새로운 버전으로 옮겨 가도 좋다.

우분투 리눅스 배포판은 패키지 관리를 위해 APT 시스템을 사용한다. APT 패키지 인덱스는 /etc/apt/sources.list 파일에 정의되어 있는, 사용할 수 있는 모든 패키지를 담은 데이터베이 스다. 로컬 데이터베이스가 해당 리눅스 배포판을 위한 저장소의 최신 패키지와 동기화되어 있 는지를 확인해야 한다. 설치에 앞서, 구식이 되었을 수도 있는 리눅스 커널 등의 저장소 항목도 갱신해야 한다. 다음 목록은 서버에서 패키지를 갱신하고 업그레이드하는 방법을 보여준다.

5장 컨트롤러 배포하기 175

목록 5.5 패키지 갱신 및 업그레이드하기

sudo apt-get -y update sudo apt-get -y upgrade

패키지 갱신과 업그레이드를 하고 나면 변경한 패키지나 구성을 반영하기 위해 서버를 재부팅 해야 한다. 목록 5.6 서버 재부팅하기

sudo reboot

이제 오픈스택의 의존 소프트웨어를 설치할 때다.

5.1.4 의존 소프트웨어 설치하기 오픈스택 관점에서 볼 때, 의존 소프트웨어는 오픈스택 프로젝트의 일부가 아니라 오픈스택 구 성요소에 필요한 소프트웨어다. 여기에는 다른 무엇보다도 오픈스택 코드(파이썬 및 관련 모 듈), 큐queue 시스템(RabbitMQ ), 데이터베이스 플랫폼(MySQL )을 실행하기 위해 사용하는 소프트웨어가 포함된다. 이번 절에서는 오픈스택의 의존 소프트웨어를 배포할 것이다. 먼저 RabbitMQ 설치부터 시작 해보자.

RabbitMQ 설치하기 RabbitMQ는 일종의 AMQPAdvanced Message Queuing Protocol로, 대규모 분산 시스템에서 메시지 전 송과 전송 순서를 보장하는 큐 시스템이다. 오픈스택은 RabbitMQ 메시지 서비스를 기본 큐 시스템으로 사용하며, 이 덕분에 오픈스택 구성요소는 빠르면서도 순서가 보장되는 메시지 통 신을 할 수 있다.

APT 또는 사용 중인 리눅스 배포판용 패키지 관리 시스템을 사용해 RabbitMQ를 설치하자. 다음 목록은 APT를 사용한 설치를 보여준다.

176 2부 오픈스택 수동 배포하기

목록 5.7 RabbitMQ 설치하기

sudo apt-get -y install rabbitmq-server

앞의 명령어를 실행하면 다음과 같은 결과가 출력될 것이다. ... The following extra packages will be installed: erlang-asn1 erlang-base erlang-corba ... libltdl7 libodbc1 libsctp1 lksctp-tools ... ... Setting up rabbitmq-server (3.2.4-1) ... Adding group 'rabbitmq' (GID 118) ... Done. Adding system user 'rabbitmq' (UID 111) ... Adding new user 'rabbitmq' (UID 111) with group 'rabbitmq' ... Not creating home directory '/var/lib/rabbitmq'. * Starting message broker rabbitmq-server

만약 [ * FAILED - check /var /log /rabbitmq /startup ... ] 오류가 발생하면 /etc /

hostname 내의 호스트 이름이 /etc/hosts 내의 호스트 이름과 일치하는지를 확인하고, 필요 하다면 서버를 재부팅해야 한다.

RabbitMQ는 관리자 권한을 가진 guest 사용자를 자동으로 생성한다. guest 계정의 비밀번 호를 바꾸고 싶다면 다음 예처럼 바꿀 수 있다(새 비밀번호를 “openstack1”으로 설정했다). 목록 5.8 RabbitMQ guest 비밀번호 설정하기

$ sudo rabbitmqctl change _password guest openstack1 Changing password for user "guest" ... ...done.

이제 RabbitMQ가 정상적으로 실행되는지 확인해야 한다. 목록 5.9 RabbitMQ 상태 확인하기

$sudo rabbitmqctl status Status of node rabbit@controller ... [{pid,2452},

5장 컨트롤러 배포하기 177

{running _applications,[{rabbit,"RabbitMQ","3.2.4"}, {mnesia,"MNESIA CXC 138 12","4.11"}, {os _mon,"CPO CXC 138 46","2.2.14"}, {xmerl,"XML parser","1.3.5"}, {sasl,"SASL CXC 138 11","2.3.4"}, {stdlib,"ERTS CXC 138 10","1.19.4"}, {kernel,"ERTS CXC 138 10","2.16.4"}]}, ... ...done.

이제 오픈스택이 사용할 수 있는 완벽하게 동작하는 RabbitMQ가 준비되었다.

MySQL 설치하기 오픈스택은 구성 정보와 상태 정보를 전통적인 관계형 데이터베이스에 저장한다. 오픈스택은 기본적으로 내장된 SQLite 데이터베이스를 사용하도록 되어 있지만, 성능이 뛰어나고 접근성 도 좋은 MySQL을 대신 사용하도록 구성하는 방법을 보여줄 것이다. 이를 통해 구성 및 상태 데이터의 백엔드 저장소로 MySQL 서버를 사용할 수 있다. 5장에서 8장에 걸쳐 배포할 모든 오픈스택 구성요소는 이번 단계에서 배포하는 중앙 데이터베이스를 사용할 것이다.

APT (또는 독자가 사용 중인 리눅스 배포판용 패키지 관리 시스템)를 사용해 다음 목록과 같 이 MySQL을 설치한다. 목록 5.10 MySQL 바이너리 설치하기

$ sudo apt-get -y install python-mysqldb mysql-server Reading package lists... Done Building dependency tree Reading state information... Done Suggested packages: python-mysqldb-dbg ... The following NEW packages will be installed: ... mysql-server python-mysqldb ... Setting up libaio1:amd64 (0.3.109-3) ... Setting up libmysqlclient18:amd64 (5.5.29-0ubuntu1) ... Setting up libnet-daemon-perl (0.48-1) ...

178 2부 오픈스택 수동 배포하기

CHAPTER

네트워크 배포하기 네트워크 노드의 사전 준비 사항

●●

오픈스택 네트워크 핵심 서비스 배포하기

●●

오픈스택 네트워크 ML2 플러그인 설정하기

●●

오픈스택 네트워크 DHCP, 메타데이터, L3, OVS 에이전트 구성하기

●●

5장에서는 서버 측에서 오픈스택 서비스를 관리하는 오픈스택 컨트롤러 노드를 배포해보았다. 컨트롤러를 배포하는 과정에서 네트워크, 컴퓨트, 스토리지 등 여러 오픈스택 핵심 서비스를 위한 컨트롤러 측 구성을 했다. 이 과정에서 컨트롤러에 관한 모든 핵심 서비스를 구성하는 방 법은 설명했지만 서비스 자체를 자세히 소개하지는 않았다.

6장에서 8장까지는 자원 노드에 핵심 오픈스택 서비스를 배포하는 방법을 알아볼 것이다. 자 원 노드란 오픈스택 서비스와 관련한 특정 자원을 제공하는 노드를 말한다. 예를 들면 오픈스 택 컴퓨트(노바) 서비스(및 모든 사전 요구사항)가 동작하는 서버는 컴퓨트 자원 노드로 간주 한다. 2장에서 살펴본 바와 같이 하나의 특정 노드가 컴퓨트(노바), 네트워크(뉴트론), 블록 스토리지(신더) 등의 여러 서비스를 제공할 수도 있다. 그러나 5장에서 컨트롤러만을 위한 전 용 노드를 사용한 것처럼 6장(네트워크), 7장(블록 스토리지), 8장(컴퓨트)에서도 전용 자원 노드를 사용할 것이다. [그림 6.1 ]에서 5장에서 소개한 다중 노드 아키텍처를 다시 볼 수 있다. 이번 장에서는 그림의 왼쪽 아래에 있는 네트워크 구성요소를 단독 노드에 수동으로 배포할 것 이다.

6장 네트워크 배포하기 229

그림 6.1 다중 노드 아키텍처

컨트롤러 키스톤

글랜스

호라이즌

아이덴티티

이미지

대시보드

뉴트론

노바

신더

네트워크

컴퓨트

스토리지

내부 네트워크

공인 네트워크

뉴트론

노바

신더

네트워크

컴퓨트

스토리지

네트워크 노드는 VM에 네트워크 자원을 제공하 며, 오픈스택 내부 네트 워크와 외부 네트워크를 연결한다.

클라이언트 네트워크

[그림 6.2 ]는 수동 배포를 하고 있는 현재 진행 상태를 보여준다. 이번 장에서는 먼저 네트워크 장치로 동작할 서버를 준비할 것이다. 다음에는 뉴트론 OSI 2계층(스위칭) 구성요소를 설치 하고 구성할 것이다. 마지막으로 OSI 3계층(DHCP, 메타데이터 등)에서 동작하는 뉴트론 서 비스를 설치하고 구성할 것이다. 이번 장에서 구성하는 네트워크 자원은 오픈스택이 제공하는

VM이 직접 사용할 것이다.

230 2부 오픈스택 수동 배포하기

그림 6.2 오픈스택 배포 로드맵

컨트롤러

5장

키스톤

글랜스

호라이즌

아이덴티티

이미지

대시보드

뉴트론

노바

신더

네트워크

컴퓨트

스토리지

뉴트론

신더

노바

6장

7장 네트워크

컴퓨트

스토리지

8장

대부분의 사람은 이번 장을 가장 어렵게 느낄 것이다. 전통적인 네트워크를 잘 알고 있더라도 오픈스택 네트워크가 어떻게 동작하는지는 시간을 두고 고민해봐야 한다. 다른 네트워크 위에 구성한 네트워크인 오버레이overlay 네트워크는 베어메탈bare-metal 서버에서 가상 머신을 추상화 하는 것과 여러모로 비슷하다. 아마 메시/오버레이/분산 네트워크를 처음 접하는 것일 수도 있 지만, 이 기술들은 오픈스택에서만 사용하는 것은 아니다. 이번 장에서 오버레이 네트워크와 오픈스택에서의 용도를 설명하겠지만, 시간을 가지고 그 근본적인 차이를 이해해두면 다른 많 은 기술을 받아들일 때 유용할 것이다.

6장 네트워크 배포하기 231

6.1 네트워크의 사전 준비 사항 배포하기 2장에서는 데브스택이 오픈스택 의존 소프트웨어를 자동으로 설치하고 구성했다. 이번 장에서 는 이 의존 소프트웨어를 수동으로 설치할 것이다. 다행히 패키지 관리 시스템을 사용해 소프 트웨어를 설치할 수 있다. 컴파일을 할 필요는 없지만 여전히 많은 구성요소를 수동으로 구성 해야 한다. 진행 시 주의 사항 다중 노드 환경에서 작업하면 배포가 훨씬 복잡해진다. 구성요소나 의존 소프트웨어를 구성할 때 저지른 별 관련이 없어 보이는 작은 실수조차도 추적하기 매우 어려운 문제를 일으킬 수 있다. 모든 절을 주의 깊게 읽 고, 무엇을 설치하고 구성 중인지를 확실히 이해하고 있어야 한다.

이번 장의 많은 예제도 검증 절차를 거치고 있으며, 독자들도 이 절차를 따를 것을 강력히 권한 다. 구성한 것이 검증을 통과하지 못하면 마지막으로 성공한 검증 지점으로 되돌아가 다시 시 작하는 것이 좋다. 이런 연습을 통해 많은 실패를 줄일 수 있을 것이다.

6.1.1 환경 준비하기 네트워크 구성을 제외하고, 환경을 준비하는 절차는 5장에서 배포한 컨트롤러 노드와 유사하 다. 네트워크 인터페이스와 주소를 구성하는 데 주의해야 한다. 그렇지 않으면 오타가 발생하 기 쉽고, 종종 이를 추적하기 어려울 수 있다.

6.1.2 네트워크 인터페이스 구성하기 다음의 세 인터페이스를 가지도록 네트워크를 구성할 것이다. 노드 인터페이스 - 오픈스택과 직접 관련이 없는 트래픽을 위한 인터페이스로, SSH 콘솔 접속, 소프트웨어

●●

업데이트, 노드 모니터링과 같은 관리 작업을 위해 사용한다. 내부 인터페이스 - 오픈스택 구성요소 간의 통신을 위한 인터페이스로, API와 AMQP 트래픽이 이 인터페이

●●

스를 사용한다. VM 인터페이스 - 오픈스택 VM 간 또는 VM과 외부의 통신을 위한 인터페이스다.

●●

232 2부 오픈스택 수동 배포하기

먼저 시스템에 어떤 인터페이스가 존재하는지를 확인해야 한다.

네트워크 확인하기 다음 명령어는 서버의 인터페이스들을 출력할 것이다. 목록 6.1 인터페이스 출력하기

$ ifconfig -a em1 Link encap:Ethernet HWaddr b8:2a:72:d5:21:c3 inet addr:10.33.2.51 Bcast:10.33.2.255 Mask:255.255.255.0 inet6 addr: fe80::ba2a:72ff:fed5:21c3/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:9580 errors:0 dropped:0 overruns:0 frame:0 TX packets:1357 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:8716454 (8.7 MB) TX bytes:183958 (183.9 KB) Interrupt:35 em2 Link encap:Ethernet HWaddr b8:2a:72:d5:21:c4 inet6 addr: fe80::ba2a:72ff:fed5:21c4/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:7732 errors:0 dropped:0 overruns:0 frame:0 TX packets:8 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:494848 (494.8 KB) TX bytes:680 (680.0 B) Interrupt:38 ... p2p1 Link encap:Ethernet HWaddr a0:36:9f:44:e2:70 BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

초기 설치 단계에서 노드 인터페이스 em1을 구성했다. em1 인터페이스는 이 노드와 통신하 기 위한 용도로 사용한다. 다른 인터페이스인 em2와 p2p1도 살펴보자. 이 책에서 사용하는 예제 시스템에서는 em2 인터페이스를 오픈스택 내부 트래픽과 확장 10G 어댑터에 사용하며,

p2p1 인터페이스는 VM 간 통신에 사용할 것이다. 다음으로, 예제 노드의 네트워크 구성을 확인하고 컨트롤러 인터페이스를 구성할 것이다.

6장 네트워크 배포하기 233

네트워크 구성하기 우분투에서는 /etc/network/interfaces 파일에서 인터페이스 구성을 관리한다. [표 6.1 ]의 이탤릭체로 된 IP 주소에 따라 네트워크를 구성할 것이다. 표 6.1 네트워크 주소 표 노드

기능

인터페이스

IP 주소

컨트롤러

공인 인터페이스/노드 주소

em1

10.33.2.50/24

컨트롤러

오픈스택 내부

em2

192.168.0.50/24

네트워크

노드 주소

em1

10.33.2.51/24

네트워크

오픈스택 내부

em2

192.168.0.51/24

네트워크

VM 네트워크

p2p1

없음: 오픈스택 네트워크에 할당

스토리지

노드 주소

em1

10.33.2.52/24

스토리지

오픈스택 내부

em2

192.168.0.52/24

컴퓨트

노드 주소

em1

10.33.2.53/24

컴퓨트

오픈스택 내부

em2

192.168.0.53/24

네트워크 구성이나 특권이 필요한 구성 정보를 수정하려면 sudo 권한 ( sudo vi /etc /

network/interfaces )을 사용해야 한다. 마음에 드는 텍스트 편집기를 사용해 다음과 같이 인 터페이스 파일을 수정한다. 목록 6.2 /etc/network/interfaces 파일 수정하기

# The loopback network interface auto lo iface lo inet loopback # The OpenStack Node Interface auto em1 ❶ iface em1 inet static address 10.33.2.51 netmask 255.255.255.0 network 10.33.2.0 broadcast 10.33.2.255 gateway 10.33.2.1 dns-nameservers 8.8.8.8

234 2부 오픈스택 수동 배포하기

dns-search testco.com # The OpenStack Internal Interface auto em2 ❷ iface em2 inet static address 192.168.0.51 netmask 255.255.255.0 # The VM network interface auto p2p1 ❸ iface p2p1 inet manual

❶ em1은 노드 관리를 위해 사용하는 공인 인터페이스다. ❷ em2는 주로 자원 노드와 컨트롤러 간의 AMQP와 API 트래픽을 위해 사용한다. ❸ p2p1은 자원 노드와 외부 네트워크 간의 VM 트래픽 전달에 사용한다.

이 네트워크 구성에서 em1 인터페이스는 SSH 접속 등의 노드 관리에 사용한다❶. 오픈스택 이 이 인터페이스를 직접 사용하지는 않는다. em2 인터페이스는 주로 자원 노드와 컨트롤러 사이의 AMQP 및 API 트래픽용으로 사용한다❷. p2p1 인터페이스는 뉴트론이 관리한다. 이 인터페이스는 주로 자원 노드와 외부 네트워크 간의 VM 트래픽을 전달한다❸. 이제 구성을 변경한 네트워크 인터페이스를 갱신해야 한다. 주 인터페이스의 설정을 바꾸지 않 았다면 접속이 중단되지는 않을 것이다. 주 인터페이스의 주소를 변경했다면 이 시점에서 서버 를 재부팅하기를 권장한다. 다음과 같이 em2와 p2p1 인터페이스의 네트워크 구성을 갱신할 수 있다. 목록 6.3 네트워크 설정 갱신하기

sudo ifdown em2 && sudo ifup em2 sudo ifdown p2p1 && sudo ifup p2p1

운영체제 관점에서는 이제야 네트워크 구성이 활성화된다. 인터페이스는 구성 정보를 반영하 여 자동으로 온라인 상태가 될 것이다. 구성 정보 갱신이 필요한 인터페이스마다 이 절차를 반 복하자. 구성 정보가 적용된 것을 확인하기 위해 다시 한 번 인터페이스를 확인해보자.

6장 네트워크 배포하기 235

목록 6.4 네트워크 갱신 상태 확인하기

$ ifconfig -a em1 Link encap:Ethernet HWaddr b8:2a:72:d5:21:c3 inet addr:10.33.2.51 Bcast:10.33.2.255 Mask:255.255.255.0 inet6 addr: fe80::ba2a:72ff:fed5:21c3/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:10159 errors:0 dropped:0 overruns:0 frame:0 TX packets:1672 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:8803690 (8.8 MB) TX bytes:247972 (247.9 KB) Interrupt:35 em2 Link encap:Ethernet HWaddr b8:2a:72:d5:21:c4 inet addr:192.168.0.51 Bcast:192.168.0.255 Mask:255.255.255.0 inet6 addr: fe80::ba2a:72ff:fed5:21c4/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:7913 errors:0 dropped:0 overruns:0 frame:0 TX packets:8 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:506432 (506.4 KB) TX bytes:680 (680.0 B) Interrupt:38 ... p2p1 Link encap:Ethernet HWaddr a0:36:9f:44:e2:70 inet6 addr: fe80::a236:9fff:fe44:e270/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:8 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:648 (648.0 B)

이제 네트워크 서버에 원격으로 접속할 수 있어야 하며 네트워크 서버에서도 인터넷에 접속할 수 있어야 한다. SSH로 원격 접속 또는 콘솔로 직접 접속하여 남은 설치를 진행할 수 있다.

6.1.3 패키지 갱신하기 APT 패키지 인덱스는 /etc/apt/sources.list 파일에 정의되어 있는, 사용할 수 있는 모든 패 키지를 담은 데이터베이스다. 로컬 데이터베이스가 해당 리눅스 배포판을 위한 저장소의 최신 패키지와 동기화되어 있는지를 확인해야 한다. 설치에 앞서, 구식이 되었을 수도 있는 리눅스 커널 등의 저장소 항목 또한 업그레이드해야 한다.

236 2부 오픈스택 수동 배포하기

목록 6.5 패키지 갱신 및 업그레이드하기

sudo apt-get -y update sudo apt-get -y upgrade

이제 변경한 패키지나 구성을 적용하기 위해 서버를 재부팅해야 한다. 목록 6.6 서버 재부팅하기

sudo reboot

우분투 서버 14.04부터 다음 오픈스택 구성요소를 공식적으로 지원하며 기본 배포판에 포함하 고 있다. 노바 - 오픈스택 컴퓨트 프로젝트의 이름으로 IaaS 클라우드 패브릭 컨트롤러로 동작

●●

글랜스 - VM 이미지 검색, 등록을 위한 서비스를 제공

●●

스위프트 - 확장성 높은 분산 오브젝트 스토리지 서비스를 제공

●●

호라이즌 - 오픈스택 대시보드 프로젝트의 이름으로, 웹 기반의 관리자 및 사용자 GUI를 제공

●●

키스톤 - 오픈스택 구성요소에 인증, 토큰, 카탈로그, 정책 서비스를 제공

●●

뉴트론 - 오픈스택 구성요소를 위해 네트워크 관리 서비스를 제공

●●

신더 - 오픈스택 컴퓨트에 블록 스토리지 서비스를 제공

●●

6.1.4 소프트웨어와 구성 의존성 이 절에서는 설치를 위한 준비 사항으로 몇 가지 의존 소프트웨어를 설치하고 구성을 변경할 것이다.

리눅스 브리지와 VLAN 유틸리티 설치하기 시스템( OS )에서 네트워크 브리지로 작업하기 위해 bridge-utils 패키지를 설치해야 한다.

OS에서 제공하는 네트워크 브리지는 오픈스택 네트워크가 동작하는 데 매우 중요한 역할을 한다. 당분간은 리눅스의 네트워크 브리지를 동일한 네트워크 세그먼트에 다수의 인터페이스 를 둘 수 있는 기능으로 생각하면 충분하다. 기본적으로 리눅스 네트워크 브리지는 스위치처럼 동작하므로 충분히 이런 식으로 생각할 수 있다.

6장 네트워크 배포하기 237

추가로 네트워크 하부 시스템이 IEEE 802.1Q에 정의된 VLANVirtual Local Area Network을 사용할 수 있도록 vlan 패키지를 설치해야 한다. VLAN을 사용하면 가상 인터페이스에서 VLAN ID 를 사용해 네트워크 트래픽을 분리할 수 있다. 이 덕분에 OS가 관리하는 물리 인터페이스 하 나를 가상 인터페이스를 사용하는 여러 네트워크로 분리할 수 있다. 예제에서는 VLAN 구성을 사용하지는 않을 예정이지만 그 기술은 알고 있어야 한다. 뉴트론에서 VLAN 사용하기 대부분의 배포 환경에서는 IEEE 802.1Q VLAN을 사용해 뉴트론 노드에 여러 네트워크를 제공하기 때문 에 [목록 6.7]에서 vlan 패키지 설치 방법을 소개한다. 그러나 이 책의 예제에서는 간단히 하기 위해 VLAN 인터페이스를 사용하지 않을 것이다. 오픈스택 네트워크를 이해하고 있다면 OS에서 VLAN을 적용하는 것 은 간단하다.

요약하자면, VLAN은 트래픽과 인터페이스를 격리하는 반면에 리눅스 브리지는 트래픽과 인 터페이스를 통합한다. 목록 6.7 vlan과 bridge-utils 설치하기

$ sudo apt-get -y install vlan bridge-utils ... Setting up bridge-utils (1.5-6ubuntu2) ... Setting up vlan (1.9-3ubuntu10) ...

이제 VLAN과 리눅스 브리지를 생성할 수 있다.

서버를 라우터로 구성하기 오픈스택은 가상 머신에게 제공할 자원을 관리한다. 가상 머신이 다른 가상 또는 물리 머신 과 통신하기 위해 사용하는 네트워크도 이런 자원 중 하나다. 오픈스택이 네트워크 서비스를 제공하기 위해서는 네트워크 장비의 기능(라우팅, 스위칭 등)을 하는 자원 노드가 적어도 하 나는 있어야 한다. 이 노드는 네트워크 트래픽을 처리하는 라우터나 스위치처럼 동작해야 할 것이다. 기본적으로 리눅스 커널은 인터페이스 간의 트래픽 라우팅을 허용하지 않는다. 기본 네트워크 기능과 같은 커널 파라미터를 수정할 때는 sysctl 명령어를 사용한다. 우리도 sysctl을 사용해

238 2부 오픈스택 수동 배포하기

커널 설정을 몇 가지 수정해야 한다. 첫 번째로 수정할 것은 리눅스 커널이 포워딩하거나 라우팅하는 네트워크 인터페이스 간의 트 래픽과 관련한 것이다. 커널이 어떤 인터페이스로 들어온 트래픽의 목적지 네트워크가 커널이 관리하고 있는 다른 인터페이스에 있다고 판단하면 그 인터페이스로 트래픽을 포워딩하거나 라우팅하기를 원할 것이다. [그림 6.3 ]은 인터페이스가 두 개인 서버의 모습이다. 그림 6.3 리눅스 IP 라우팅 서버

서버

패킷 =

라우팅 테이블 목적지

사용 인터페이스

그림에서 보듯이 INT _0 인터페이스의 주소가 들어온 패킷의 목적지가 아니기 때문에 기본적 으로 그 패킷은 INT _0 인터페이스에서 폐기된다. 그러나 서버가 패킷의 목적지 주소를 확인 하고 서버의 라우팅 테이블을 본 후 적절한 경로를 찾는다면, 그 패킷을 해당 인터페이스로 전 달forwarding해 주기를 바랄 것이다. [목록 6.8 ]에서 보듯이 net.ipv4.ip _forward 설정을 통해 커널이 트래픽을 전달하도록 할 수 있다. 커널이 IP를 전달하도록 설정하는 것 외에도, 덜 흔한 커널 설정을 몇 개 더 변경해야 한다. 네 트워크 세계에는 나가는 트래픽과 들어오는 트래픽의 경로가 같지 않은 비대칭 라우팅asymmetric routing

이라는 것이 있다. 지상파로 업로드하고 위성으로 다운로드하는 기술( www.google.

com/patents/US6038594 )처럼 비대칭적으로 라우팅하는 것이 적절한 경우도 있지만, 이 기 능은 자주 분산 서비스 거부(DDOS ) 공격의 대상이 된다. 이런 DDOS 공격의 영향을 줄이 기 위해 역경로 필터링reverse path filtering이라는 RFC 3704, “Ingress Filtering for Multihomed

Networks” 기술이 도입되었다. 리눅스 커널이 패킷의 출발지 경로를 알 수 없으면 그 패킷은 기본적으로 폐기된다. 오픈스택 네트워크는 많은 계층의 네트워크 자원을 포함하는 복잡한 플

6장 네트워크 배포하기 239

랫폼이지만, 네트워크 자원만 가지고는 네트워크를 완성할 수 없다. 역경로 필터링을 비활성화 해 오픈스택이 경로를 관리할 수 있도록 커널을 구성해야 한다. [목록 6.8 ]에서는 net.ipv4.conf.all.rp _filter 값을 0으로 설정하여 모든 인터페이스에서 역 경로 필터링을 비활성화했다. 마찬가지로 net.ipv4.conf.default.rp _filter 설정으로는 향후 의 모든 인터페이스에 대해서도 역경로 필터링을 비활성화하도록 했다. 다음 목록의 설정을 오픈스택 네트워크 노드에 적용한다. 목록 6.8 /etc/sysctl.conf 수정하기

net.ipv4.ip _forward = 1 net.ipv4.conf.all.rp _filter = 0 net.ipv4.conf.default.rp _filter = 0

서버를 재부팅하지 않고 sysctl 커널 변경 사항을 적용하기 위해 sysctl -p 명령어를 실행 한다. 목록 6.9 sysctl 명령어 실행하기

$ sudo sysctl -p net.ipv4.conf.default.rp _filter = 0 net.ipv4.conf.all.rp _filter = 0 net.ipv4.ip _forward = 1

이제 모든 인터페이스는 IPv4 트래픽을 전달하며, 역경로 필터링도 비활성화되었다. 다음 절에서는 Open vSwitch 패키지를 사용하는 고급 네트워크 기능을 추가할 것이다.

6.1.5 Open vSwitch 설치하기 오픈스택 네트워크는 오픈 소스 분산 가상 스위치 패키지인 Open vSwitch (OVS )를 활용한 다. OVS는 물리 스위치처럼 데이터 스위칭 기능(포트 B로 향하는 포트 A의 L2 트래픽을 포 트 B로 스위칭)을 제공하지만, 이 기능은 서버에서 소프트웨어로 동작한다.

240 2부 오픈스택 수동 배포하기

스위치는 무슨 일을 하는가? 스위치의 역할을 이해하기 위해서는 이더넷 허브를 먼저 살펴봐야 한다(아마 모든 유무선 장치 에서 어떤 형태로든 이더넷을 사용하고 있을 것이다). “허브란 무엇인가?”

1990년대 초반에는 다수의 OSI 1계층(물리 계층) 이더넷 토폴로지가 서로 경쟁하고 있었 다. 그 중 하나인 IEEE 10Base2는 가정용 케이블 TV와 유사한 방식으로 동작하는데, 하나 의 케이블을 T 커넥터로 나누어 다른 네트워크를 연결할 수 있었다. 또 다른 흔한 토폴로지인

10BaseT (RJ45 커넥터 연선)는 현재 대부분의 사람이 알고 있는 “이더넷”의 원조다. 10BaseT 는 네트워크 서비스를 중단하지 않고 네트워크를 연장할 수 있다는 장점이 있다. 단점으로는 이 물리 토폴로지에는 케이블 세그먼트의 경계를 구분하기 위한 어떤 장치가 필요하다. 이 장치를 바로 허브라고 하며, 이 또한 OSI 1계층(물리 계층)에서 동작한다. 데이터가 A 포트에 연결된 장치에서 전송되면, 허브는 그 데이터를 허브의 다른 모든 포트로 물리적으로 전송한다. 모든 데이터를 모든 포트에 전송하는 것과 관련한 명백한 보안적 우려는 차치하더라도, 허브만 으로는 규모를 확장하기 어렵다. 수천 개의 장치가 수백 개의 상호 연동된 스위치에 연결되어 있 는 모습을 상상해보자. 모든 트래픽이 모든 포트로 흘러들게flooding 될 것이다. 이 문제를 해결하 기 위해 네트워크 스위치가 개발되었다. 네트워크 인터페이스 카드NIC 제조사는 모든 카드에 고 유의 이더넷 하드웨어 주소Ethernet Hardware Address, EHA를 할당한다. 스위치는 모든 포트에서 흔히 매 체 접근 제어Media Access Control, MAC 주소라는 EHA 주소를 기록한다. 목적지 MAC이 xyz인 패킷이 포트 A로 전송되고 스위치의 포트 B에 xyz의 기록이 있다면, 그 패킷은 포트 B로 전송(스위칭) 된다. 스위치는 OSI 2계층(데이터링크 계층)에서 동작하며 MAC 주소를 기반으로 트래픽을 스 위칭한다.

이 책의 예제에서는 OVS를 단독 스위칭 플랫폼으로 사용한다. 이제 서버는 기본적인 네트워크 라우터(IP 커널 포워딩 사용)와 스위치(리눅스 네트워크 브리 지 사용)처럼 동작한다. 이제 OVS를 설치해 서버에 고급 스위칭 기능을 추가할 것이다. OVS 는 책 한 권 전체를 할애해야 할 정도로 방대한 주제지만, 지금은 OVS가 제공하는 스위칭 기 능이 개별 네트워크 제조사가 제공하는 기능에 필적하는 수준이라는 것만 알아두면 충분하다.

6장 네트워크 배포하기 241

오픈스택 네트워크에 OVS가 반드시 필요한 것은 아니다 분명히 오픈스택 네트워크에서는 OVS를 주로 사용하지만 오픈스택 프레임워크에 무조건 OVS 가 필요한 것은 아니다. 다만, 앞서 4장에서 소개한 다음 그림을 보면 OVS가 오픈스택 네트워크 아키텍처에 가장 적합하다는 것을 알 수 있다.

뉴트론

네트워크

ML2 플러그인

API 확장

타입 드라이버

메커니즘 드라이버 아리 스타

시스코

리눅스 브리지

OVS는 L2 메커니즘 드라이버다.

제조사별 뉴트론 플러그인이나 모듈이 지원하기만 한다면 OVS 대신 기본 리눅스 브리지(앞서 설명한 가상 스위치) 또는 심지어 물리 스위치도 사용할 수 있다.

이제부터 설명할 OVS 설치 방법을 통해 서버를 고급 스위치로 바꿀 수 있다. 목록 6.10 OVS 설치하기

$ sudo apt-get -y install openvswitch-switch ... Setting up openvswitch-common ... Setting up openvswitch-switch ... openvswitch-switch start/running

Open vSwitch 설치 과정에서 새 OVS 커널 모듈이 설치될 것이다. 추가로, 네트워크 오버레 이를 구축하기 위해 필요하다면 OVS 커널 모듈은 추가 커널 모듈(GRE, VXLAN 등)을 로딩 할 것이다.

242 2부 오픈스택 수동 배포하기

Part

III

상용 환경 구축하기

이 책의 마지막인 3부에서는 상용 환경, 특히 일반적인 시스템 관리자가 광범위한 인프라와 애플리케이션 모 두를 관리하는 기업 환경에서 오픈스택을 배포하고 활용하는 것에 관한 주제를 다룬다. 기업 환경에서는 대개 시스템 엔지니어가 인프라를 설계하고 배포하고 선정한다. 3부의 여러 장을 통해 독자들이 오픈스택을 성공적 으로 배포할 수 있도록 도와줄 것이다.

9장 오픈스택 구조 설계하기 333

Part III

상용 환경 구축하기

9장

오픈스택 구조 설계하기

10장 세프 배포하기 11장 퓨얼을 사용한 HA 오픈스택 자동 배포 12장 오픈스택을 사용한 클라우드 오케스트레이션

334 3부 상용 환경 구축하기

CHAPTER

오픈스택 구조 설계하기 오픈스택을 사용해 기존 가상 서버 플랫폼 대체하기

●●

사설 클라우드를 구축하는 이유

●●

사설 클라우드를 구축할 때의 선택 사항

●●

1부에서는 데브스택을 사용해보면서 오픈스택에 발을 담가보았다. 1부의 목표는 오픈스택의 사용 방법과 사용 이유를 소개하고, 오픈스택의 내부 동작 방식을 깊이 이해할 수 있도록 독자 들의 호기심을 자극하는 것이었다.

2부에서는 여러 오픈스택 핵심 구성요소를 수동으로 배포해보았다. 오픈스택 구성요소 간의 상호작용을 이해하는 것도 중요하지만, 2부가 오픈스택을 배포할 때 단순히 참조하기 위한 지 침서로 의도된 것은 아니다. 수동으로 배포해보면서 구성요소와 구성 정보의 깊은 부분까지 파 헤쳐 하부 시스템에 대한 독자들의 자신감을 확립할 수는 있지만, 이것이 상용 환경에서도 구 성요소를 수동으로 설치하라는 이야기는 아니다. 이 책의 마지막인 3부에서는 상용 환경, 특히 일반적인 시스템 관리자가 광범위한 인프라와 애 플리케이션 모두를 관리하는 기업 환경에서 오픈스택을 배포하고 활용하는 것에 관한 주제를 다룬다. 기업 환경에서는 대개 시스템 엔지니어가 인프라를 선정하고 설계하고 배포한다. 3부 의 여러 장을 통해 독자들이 오픈스택을 성공적으로 배포할 수 있도록 도와줄 것이다. 이번 장에서는 오픈스택 배포 계획을 수립할 때 해야 할 설계, 재정, 운영상의 결정 사항을 다 룬다. 이번 장은 따라하기 식의 요리책이 아니라, 성공적인 아키텍처를 개발할 때 처음부터 도움을 받을 수 있는 참고 자료다. 아키텍처를 개발하는 관례적인 접근 방식을 알고 싶다면 “OpenStack Architecture Design Guide (http://docs.openstack.org/arch-design )” 를 읽어보기를 권장한다. 일단 오픈스택 배포 유형을 결정하고 나면, 이 온라인 설계 가이드가

9장 오픈스택 구조 설계하기 335

구성 및 규모 산정을 위한 소중한 자산이 될 것이다. 기업 시스템을 관리하는 대부분의 사람은 가상 및 물리 인프라 플랫폼을 바라보는 전통적인 관 점에서 오픈스택에 접근할 것이다. 먼저 기존 가상 서버 플랫폼을 오픈스택으로 대체해 사용하 는 것에 대해 설명한 후에, 오픈스택 배포 환경을 최대한 활용하기 위해 필요한 전략적인 설계 선택 사항도 다룰 것이다.

9.1 기존 가상 서버 플랫폼의 대체 2015년 가트너 보고서에서는 x86 시스템의 75%가 시장 주도 업체인 VMware를 사용해 가상 화할 것이라고 예측했다.1 이번 절에서는 오픈스택이 어떻게 기존 VM 환경을 대체하거나 확장 할 수 있는지를 다룬다. 또한 오픈스택이 기존 가상 서버 플랫폼의 대체재 이상의 역할을 하는 이유를 설명할 것이다. 전통적인 가상 환경은 물리 머신을 기능적으로 흉내 내는 방식으로 가상 머신을 제공하도록 설계되어 있다. 또한 가상화를 인프라 비용을 절감하는 수단으로 도입했을 가능성이 크다.

P2VPhysical to Virtual로 알려진 절차를 통해 물리 서버를 가상 서버로 옮길 때, P2V 도구는 물리 서 버와 정확하게 동일한 복제본을 만든다. 대개 물리 및 가상 서버는 같은 네트워크에서 동작하 며, 이 덕분에 서비스 중단 없이 P2V 마이그레이션을 할 수 있다. 가상 서버로 작업을 통합하 는 절차는 결과적으로 상당한 경제적인 이득을 낳는다. 자원을 더 효율적으로 사용할 수 있는 것 외에도, 마스터 이미지와 가상 머신 이미지 스냅샷과 같은 새로운 기능은 이제 소프트웨어 배포와 업그레이드 절차의 일부가 되었으며, 많은 유형의 소프트웨어와 하드웨어 고장을 줄여 주었다. 가상 환경이 사용자에게 제공하는 수많은 새로운 기능에도 불구하고 시스템 관리자들 은 여전히 가상 머신의 OS와 애플리케이션을 물리 머신에서와 같은 방식으로 관리하고 있다. 앞서 말한 것처럼 가상 환경을 물리 환경과 동일한 방식으로 다룬다면 오픈스택의 이점은 제한 적일 것이다. 다시 말해서, 현재 자동화 없이 중앙 부서에서 가상 서비스를 수동으로 배포하는 운용 방식을 채택하고 있다면, 오픈스택과 같은 클라우드 프레임워크를 채택하는 것이 얼마나

1 “Magic Quadrant for x86 Server Virtualization Infrastructure”(2015. 7. 14 ), www.gartner.com/technology/reprints. do?id=1-2JGMVZX&ct=150715

336 3부 상용 환경 구축하기

효과적일지를 한 번 더 고민해봐야 한다. 서버 가상화 플랫폼으로 VMware vSphere를 사용해오다가, 비용을 절감하기 위해 VMware 를 오픈스택으로 대체하는 것에 관심이 있다고 가정해보자. 오픈스택을 단순히 VMware의 “무료” 대안으로만 생각한다면 잘못된 길로 가고 있는 것일 수 있다. 대부분의 경우, 경쟁 관계 에 있는 많은 가상 환경과 동일한 기능을 하도록 오픈스택을 배포할 수 있지만, 이는 기존 운용 방식과도 조화를 이루는 방향으로 이루어져야 한다. 기존의 모든 VMware 작업을 오픈스택으 로 대체하는 앞의 사례를 고려해보자. 오픈스택이 VMDK (VMware의 이미지 형식) 파일을 처리할 수 있음에도 불구하고, VMware가 제공하는 것과 같은 그래픽 환경의 V2VVirtual to Virtual 마이그레이션 도구는 없으며, 아마 앞으로도 없을 것이다. 이제 VMware 기반의 가상 머신 이미지를 만들기 위해 가장 흔히 사용하는 절차를 고려해보 자. 일반적으로 데스크톱 클라이언트를 사용해 워크스테이션에서 CD나 DVD를 가상 하드웨 어로 마운트한 후 물리 머신과 동일한 방식으로 설치한다. 하지만 오픈스택 대시보드에는 CD 나 DVD 이미지를 원격으로 마운트하는 기능이 없다. 이 때문에 오픈스택이 불완전하다고 생 각할 것이 아니라, 오픈스택을 전통적인 가상 서버 환경과는 다르게 사용해야 한다는 것을 이 해해야 한다. 오픈스택이 VMware 등의 다른 상용 하이퍼바이저를 훌륭히 대체할 수 있을 것인가? 이에 답 하기 위해서는 먼저 인프라 자원의 관리 방식을 전략적으로 고려해봐야 한다. [표 9.1 ]은 인프라 관리 전략에 따른 오픈스택의 영향도를 보여준다. 표 9.1 환경에 따른 오픈스택의 영향도 환경

설명

영향도

개별적siloed이고

하드웨어 관리는 개별적이고 자원은 공유된다. 가상 하드웨어는 IT 직원이 최종

없음~낮음

수동으로 만든 VM

사용자에게 수동으로 프로비저닝하며, 최종 사용자는 OS 운용을 책임진다.

개별적이고

하드웨어 관리는 개별적이고 자원은 공유된다. 가상 인프라는 IT 직원이 자동화

자동으로 만든 VM

된 방식으로 배포하며 최종 사용자는 애플리케이션 운용을 책임진다.

애플리케이션 전용

하드웨어는 클라우드 프레임워크가 전적으로 관리한다. 특정 애플리케이션을

높음~

백엔드

위한 인프라와 애플리케이션의 배포는 IT 직원이 자동화한다.

매우 높음

사설 클라우드

하드웨어는 클라우드 프레임워크가 전적으로 관리한다. 애플리케이션과 표준

매우 높음

중간

(크기 및 OS) VM은 자동화된 셀프서비스 방식으로 최종 사용자에게 제공된다.

9장 오픈스택 구조 설계하기 337

이 표에서 개별적이고 수동으로 만든 VM의 경우에는 자동화 없이 수동으로 가상 머신을 프로 비저닝하는 중앙 부서가 존재하며, 이들은 오픈스택을 불완전하거나 불필요하다고 생각할 가 능성이 크다. 자동화하지 않고는 오픈스택은 현재의 작업을 도와줄 수 있는 어떤 것도 제공하 지 않는다. 개별적이고 자동으로 만든 VM 환경은 인프라를 관리하는 IT 부서가 인프라 오케스트레이션만 최소한의 수준으로 사용하는 것 외에는 수동으로 관리하는 환경과 유사하다. 예를 들어, 요청 한 작업의 일부에 대해서만 자동화된 프로비저닝을 사용하는 경우가 여기에 속한다고 볼 수 있 다. 수동으로 관리하는 대부분의 조직과 마찬가지로 이 범주에 속하는 조직은 보통 오픈스택을 직접적인 비용 절감을 위해 현재 사용 중인 것을 대체하는 정도로 평가한다. 오픈스택이 비용 절감을 이끌어낼 수 있다는 점은 사실이지만, 오픈스택 프레임워크를 최대한 활용하려면 이 조 직의 운용 및 업무 절차에 변화를 주어야 한다. 이제 가상 머신을 수동으로 프로비저닝하는 중앙 부서의 직원을 인프라나 애플리케이션 자원 관리자로 재배치한다고 가정하면, 이는 애플리케이션 전용 백엔드 시나리오와 같다. 이런 전략적인 변화를 통해 인프라 구조뿐만 아니라 애플리케이션 프로비저닝에도 자동화를 사용한다고 가정해보자. 테넌트별로 자원을 할당하고 개별 부서의 직원들도 자신만의 자원을 프로비저닝할 수 있다고 추가로 가정해보자. 이것이 바로 사설 클라우드며, 이 경우 중앙 부서 는 서비스를 직접 제공하지 않고 중개만 하게 되고, 결과적으로 개별 부서는 민첩성을 올릴 수 있다. 여러 면에서 볼 때, 이런 방식으로 운용하면 인프라의 역할에 대한 고정 관념을 바꿀 수 있다. 애플리케이션과 인프라를 자동화하면 P2V나 V2V 도구가 필요 없어지므로 더 이상 이 미지를 이리 저리 옮길 필요가 없다. 이런 운용 방식에서 인프라 자원은 정적인 할당 체계에 비 해 더 짧은 기간 동안 할당되며 더 많은 애플리케이션 용량을 수용할 수 있다. 오픈스택의 진짜 가치는 프레임워크가 제공하는 자동화와 플랫폼 추상화에 있다. 다음으로, 오 픈스택을 설계할 때 고려해야 하는 아키텍처상의 고려 사항을 설명할 것이다.

9.1.1 배포 방식 선택하기 VMware vSphere나 Hyper-V와 같은 가상 서버 플랫폼에 익숙하다면 이제 하드웨어를 구 입하고 지원하는 방식을 다시 생각해야 할 수도 있다. 과거보다 덜 흔하긴 하지만, 네트워크 스

338 3부 상용 환경 구축하기

위치와 중앙 스토리지 풀과 같은 기업의 물리 자원은 물리와 가상 자원 사이에 공유할 수 있다. 자원을 가상 서버 플랫폼에 독점적으로 할당한다고 하더라도, 사람들은 일반적으로 가상 서버 플랫폼이 그 자원을 관리하는 것이 아니라 그 플랫폼이 사용할 자원을 프로비저닝한다고 생각 한다. 예를 들어 하이퍼바이저에 새 VLAN을 할당하거나 공유 LUNLogical Unit Number을 사용할 수 있도록 하는 것은 흔한 일이다. 그러나 새 VLAN이나 새 공유 LUN을 만들고 싶다면 시스템 관리자는 자신의 프로비저닝 절차를 재검토해볼 필요가 있다. “네트워크 관리자”가 모든 네트 워크를 구성하고, “스토리지 관리자”가 모든 스토리지를 할당하고, “VM 관리자”가 VM을 생성 하기 위해 자원을 물리 서버와 함께 묶는 것 또한 매우 흔한 일이다. 이 절차 동안 각 관리자는 종종 자신의 자원이 전체 인프라에서 어떤 역할을 하는지 이해하지 못한 채로 수동 프로비저닝 절차를 수행해야 한다. 중앙의 공유 인프라에서 오픈스택을 배포하는 것은 일반적으로 잘못된 방법이다. 오픈스택이 인프라 자원을 감지하고, 구성하고, 프로비저닝하는 것이지 그 반대가 아니다. 중앙의 공유 인 프라가 오픈스택 자동화를 격리하는 다중 테넌트multi-tenant (오픈스택 테넌트와 혼동하면 안 된 다) 기능을 제공하더라도, 오픈스택이 공유 자원에서 자원을 프로비저닝하는 것으로 인한 영향 도는 여전히 고려해야 한다. 예를 들어, 오픈스택 운용과는 관련 없는 소프트웨어 업그레이드가 서비스에 영향을 줄 수도 있다. 또한 오픈스택의 관리 범위 밖에 있는 자원의 사용률이 성능에 영향을 주는 데도 오픈스택 서비스에는 그 문제에 대한 어떠한 조짐도 없을 수도 있다. 대부분의 가상 환경은 인프라를 계획에 따라 관리하고 그 혜택을 활용할 수 있도록 설계되어 있지 않다. 이런 경우에는 컴퓨트, 스토리지, 네트워크, 부하 분배기 등의 개별 자원을 수직으 로 관리하는 방식으로 운용 방식이 발전되어갈 것이다. 이와 반대로, 오픈스택은 물리 인프라 를 완전히 추상화하는 것을 철학으로 설계되었다. 일반적으로 오픈스택에 자원을 독점적으로 할당하고 플러그인과 서비스를 통해 오픈스택이 자원을 관리하도록 하면 많은 문제에서 벗어 날 수 있다. 이어지는 여러 절에서는 서비스를 확장하거나 새 서비스를 추가하기 위해 오픈스택을 사용해 자원을 관리한다고 가정한다. 오픈스택의 관리 기능을 최대한 활용하고 심지어 하드웨어도 오 픈스택으로 관리할 수 있지만, 최종 산출물은 기존에 제공하는 것과 유사할 것이다. 구체적으 로 말하자면, 효율성을 위해 운용 및 배포 방식을 변경할 수도 있지만, 대부분의 주 관심사는

VMware나 마이크로소프트 제품으로 기존에 하던 방식대로 VM을 배포하는 것일 것이다. 9.2 절에서 IaaS에 대한 더 진보된 접근 방식을 논의할 것이다.

9장 오픈스택 구조 설계하기 339

9.1.2 네트워크 유형 오픈스택은 활용하고 싶으나 오픈스택이 라우팅, DHCP, VPN 등의 L3 서비스를 관리하기를 원하지 않는다면, L2 (스위칭) 서비스만 관리하는 방안을 검토해야 한다. 예를 들어 [그림 9.1 ]은 VM이 공인 L2 네트워크에 직접 연결되어 있는 것을 보여준다. 이 예 는 오픈스택에만 해당하는 것은 아니며 VMware vSphere나 마이크로소프트 Hyper-V 등의 많은 가상 서버 플랫폼에서 사용하는 네트워크 배포 환경과 유사하다. 이 네트워크 배포 시나 리오에서 하이퍼바이저의 역할은 L2 네트워크 트래픽을 스위치로 직접 전달하는 것으로, 이 스 위치는 일반적으로 하이퍼바이저의 제어 범위 밖의 물리 스위치다. 이 가상 서버 플랫폼은 L2 서비스를 제공하지 않기 때문에 이 책의 많은 네트워크 예제와는 다르게 여기에는 “내부” 또는 하이퍼바이저 네트워크에 대한 개념은 존재하지 않는다. 이러한 배포 형태에서 모든 L3 서비 스는 하이퍼바이저 외부의 시스템이 제공한다. 짐작하다시피 대부분의 네트워크 서비스를 가 상 서버 플랫폼에서 분리하면 플랫폼의 이점이 줄어들지만 그 단순함으로부터 오는 혜택도 없 지 않다. IT 전략, 기존 자원, 지원 구조에 따라서는 이러한 운용 방식이 최선일 수도 있다. 그림 9.1 VM과 하이퍼바이저에 연결된 L2 네트워크

WAN: 공인 주소 하이퍼바이저

LAN: L2 네트워크 인터넷 물리 라우터

이 책의 대부분은 L2 및 L3 서비스를 제공하는 오픈스택 네트워크(뉴트론)에 중점을 두고 있 다. 앞의 여러 장에서 설명한 바와 같이 뉴트론은 단순히 L2 트래픽을 외부 네트워크로 내보내 기 위해서가 아니라, 오픈스택 환경 내에서 복잡한 네트워크와 서비스를 관리하기 위해 만들 어졌다. 하지만 뉴트론보다 앞선 오픈스택 컴퓨트(노바) 프로젝트는 기본 L2 서비스를 제공 한다. 오픈스택 배포 환경을 L2 서비스로만 한정하고 싶다면 뉴트론보다는 노바가 네트워크에 더 적합할 것이다.

340 3부 상용 환경 구축하기

CHAPTER

세프 배포하기 세프 배포를 위한 서버 준비하기

●●

ceph -deploy 도구를 사용해 세프 배포하기

●●

기본 세프 작업 방법

●●

세프(http://ceph.com )는 범용 서버를 사용해 블록, 파일, 오브젝트 스토리지 서비스를 제 공하기 위해서 사용하는 RADOS ( http://ceph.com/papers/weil-rados-pdsw07.pdf ) 기반의 오픈 소스 스토리지 플랫폼이다. 세프는 단일 장애 지점을 제거하기 위해 사용자와 클 러스터 관리 데이터를 복제하는 분산 아키텍처로 동작한다. 그렇다면 오픈스택 책에서 왜 별도 의 장을 할애해 세프를 소개하는가? 오픈스택 커뮤니티 사용자 설문조사에 따르면, 오픈스택 스토리지를 위해 세프를 가장 많이 선택하고 있다.1 7장에서 볼륨 스토리지를 관리하기 위해

LVM을 사용하도록 신더를 구성했지만, 상용 배포 환경에서는 신더가 관리할 스토리지를 제공 하기 위해 LVM 대신 세프 백엔드를 사용할 수도 있다. 이번 장에서는 세프의 설계와 작업 방법을 자세히 설명하지는 않을 것이다. 대신 세프 개발자 가 제공하는 배포 도구인 ceph-deploy를 사용해 세프를 배포해볼 것이다. 또한, 이번 장에서는 스토리지를 제공하기 위해 세프가 사용하는 자원 노드resource node와 세프 클라이언트이자 세프를 프로비저닝할 환경으로 사용할 관리 노드admin node, 이 두 종류의 노드 (범용 서버)를 가지고 작업할 것이다.

1 아래 주소의 “OpenStack users share how their deployments stack up” 문서 참조 http://superuser.openstack.org/articles/openstack-users-share-how-their-deployments-stack-up

10장 세프 배포하기 359

10.1 세프 노드 준비하기 세프 아키텍처에서 자원 노드는 세프 클러스터를 구동하고 관리하는 노드와 스토리지를 제공 하는 노드로 나눌 수 있다. 여러 유형의 세프 노드를 [표 10.1 ]에서 볼 수 있다. 표 10.1 세프 자원 노드 노드 유형

설명

기능

MON

모니터 노드

스토리지 클러스터 데이터 지도의 마스터 사본을 관리한다.

OSD

오브젝트 스토리지

원시 데이터 스토리지를 제공한다.

장치 노드

MDS

메타데이터 서버 노드

모든 파일 시스템 메타데이터(디렉터리, 파일 소유권, 접근 모드 등)를 저장한다.

이번 장의 예제는 공유 관리 서버 1대와 세프 전용으로 사용하는 물리 서버 6대로 이루어진 세 프 클러스터를 기반으로 한다. 각 노드의 이름, 역할, 주소는 [표 10.2 ]와 같다. 표 10.2 예제에 사용할 세프 노드 노드 이름

노드 유형

IP 주소

admin.testco.com

ADMIN

10.33.2.57

sm0.testco.com

MON/MDS

10.33.2.58

sm1.testco.com

MON/MDS

10.33.2.59

sm2.testco.com

MON/MDS

10.33.2.60

sr0.testco.com

OSD

10.33.2.61

sr1.testco.com

OSD

10.33.2.62

sr2.testco.com

OSD

10.33.2.63

관리 노드 유형 관리 노드는 세프 아키텍처의 일부는 아니다. 이 노드는 단순히 전용 하드웨어에서 세프의 배포와 관리를 자 동화하기 위해 사용하는 서버다.

360 3부 상용 환경 구축하기

시각 동기화 세프와 같은 분산 시스템은 단일 컴퓨터의 파일 시스템처럼 중앙 시각 time에 의존할 수 없다. 이 것이 중요한 이유는 분산 시스템이 분산 이벤트의 순서를 결정하는 방법 중 하나가 각 분산 노 드가 보고하는 시각 정보를 참조하는 것이기 때문이다. 세프 클러스터에 참여하는 노드 간에 시 각이 동기화되어 있는지 확인하는 것은 중요한 일이다. 특히 MON 노드들은 기본적으로 50ms 내에 서로 시각 정보를 보고하지 않으면 경보가 발생할 것이다(설정 변경 가능). 세프 노드에서

NTPNetwork Time Protocol 서비스를 사용하기를 권장한다.

세프 스토리지 클러스터를 배포하는 첫 번째 단계는 노드를 준비하는 것이다. 세프는 이 책의 다른 오픈스택 구성요소와 마찬가지로 범용 하드웨어와 소프트웨어에서 동작한다. 먼저 노드 인증과 인가 정보를 구성한 후, 노드에 세프 소프트웨어를 배포할 것이다.

10.1.1 노드 인증 및 인가 ceph-deploy가 세프를 설치하고 구성하는 데 사용할 사용자를 각 서버에 생성해야 한다. 다 음 명령어를 사용해 사용자를 생성한다. 목록 10.1 세프 사용자 생성하기

sudo useradd -d /home/cephuser -m cephuser sudo passwd cephuser Enter new UNIX password: Retype new UNIX password: passwd: password updated successfully

프롬프트 없이 비밀번호 설정하기 비밀번호는 chpasswd 명령어로도 변경할 수 있다.

echo 'cephuser:u$block01' | sudo chpasswd

10장 세프 배포하기 361

앞의 목록에서 이름이 “cephuser”고 비밀번호가 “u$block01”인 사용자를 생성했다. ceph-

deploy 도구는 세프 노드에 소프트웨어를 설치하기 위해 특권(sudo )이 필요하다. 일반적으로는 앞의 목록의 명령어처럼 특권 명령어를 실행할 때는 sudo 비밀번호를 입력해야 하지만, 자동 설치 과정에서 특권 명령어가 실행될 때마다 매번 비밀번호를 입력하고 싶지는 않을 것이다. cephuser가 비밀번호 없이 sudo 명령어를 실행하기 위해서는 /etc/sudoers.d 디렉터리에 sudoers 파일을 생성하고 필요한 권한을 주어야 한다. 다음 목록의 명령어를 실행 해 적절한 권한을 가진 sudoers 파일을 생성한다. 목록 10.2 sudoers 파일 생성하기

echo "cephuser ALL = (root) NOPASSWD:ALL" \ | sudo tee /etc/sudoers.d/cephuser sudo chmod 0440 /etc/sudoers.d/cephuser

이제 새 사용자 cephuser를 생성했고, 이 사용자는 sudo 비밀번호를 입력할 필요 없이 sudo 명령어를 실행할 수 있다.

세프 노드 간 인증 앞 단계에서 생성한 cephuser는 생성한 서버에서만 로컬로 사용할 수 있다. 서버가 몇 대 안 된다면 서로 로그인하여 스크립트를 실행하는 데 문제가 없을 수도 있지만, 10대 혹은

100대로 작업한다면 어떠한가? 자동 배포에 필요한 인증과 인가 절차를 완료하기 위해서는 cephuser가 비밀번호를 입력하지 않고 SSH로 원격 로그인할 수 있도록 각 서버를 구성해야 한다. 원격 호스트가 비밀번호 없이 다른 호스트에 로그인할 수 있다는 것이 자동화를 위해 보안을 희생해야 함을 의미하는 것은 아니다. 이것이 어떻게 동작하는지를 이해하기 위해서는 SSH의 기본 동작을 이해해야 한다. 이 책에서 SSH에 대한 자세한 설명은 다루지 못하지만, 원격 사용 자와 특정 로컬 사용자를 인증하는 두 가지 방법을 알아보는 것만으로도 충분하다. 이 책의 예제를 따라 왔다면 SSH 로그인을 위해 비밀번호를 입력하는 절차는 이미 익숙할 것 이다. 그러나 비밀번호를 기반으로 하는 인증 방법의 대안으로 서버 간에 공개 키public key를 공 유하는 키쌍 key-pair 인증이라는 것이 있다. 자세한 내용은 복잡하지만, 여기서 알아야 할 것은

362 3부 상용 환경 구축하기

서버_A가 사용자_A의 공개 키를 서버_B와 공유하고 있다면 서버_A는 서버_B에 있는 사 용자_A를 비밀번호 없이 인증할 수 있다는 것이다. 이 관계를 [그림 10.1 ]에서 볼 수 있다. 그림 10.1 SSH 키쌍 교환 절차 나는 사용자_A 입니다.

서버_A [개인 키]

증명해보세요.

[개인 키]로 [메시지]를 복호화

메시지

서버_B [공개 키]

[공개 키]로 [메시지]를 암호화

서버_B [공개 키]

메시지 비교

사용자_A가 인증됨

일치

불일치

사용자_A가 인증되지 않음

이 시나리오에서 서버_A는 관리 노드, 서버_B는 자원 노드라고 생각하자. 관리 노드는 서비 스를 제공할 자원 노드에 접속해 자동 배포 작업을 실행한다. 결과적으로 관리 노드에서 비밀 번호 없이 다수의 자원 노드에 접속할 수 있어야 한다. SSH 키쌍 인증 서버가 비밀번호 없이 다른 서버에 접속하는 것과 마찬가지로 사용자도 종종 이 기능을 원한다. 비밀번호를 입력하지 않는 편리함은 차치하더라도 이런 방식의 인증은 비밀번호를 평문으로 저장하거나 전송할 필요를 없애주며, 키쌍과 비밀번호를 함께 사용한다면 비밀번호 인증만 단독으로 사용하는 것보다 안전하다. 사실 오 픈스택은 인스턴스 생성 과정에서 키쌍을 VM 내부로 주입하는 기능을 제공한다.

관리 노드에서 cephuser를 사용해 [목록 10.3 ]의 절차에 따라 개인/공개 키쌍을 생성한다. 암호를 입력하라고 요구할 때 어떤 것도 입력하면 안 된다. 그렇지 않으면 키쌍을 사용할 때 그 암호를 입력해야 할 것이다. 문제가 발생하면 키쌍 생성 절차를 다시 진행할 수 있다.

10장 세프 배포하기 363

목록 10.3 관리 노드에서 개인/공개 키쌍 생성하기

$ ssh-keygen Generating public/private rsa key pair. Enter file in which to save the key (/home/cephuser/.ssh/id _rsa): Created directory '/home/cephuser/.ssh'. Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/cephuser/.ssh/id _rsa. Your public key has been saved in /home/cephuser/.ssh/id _rsa.pub. The key fingerprint is: 90:6c:09:3d:b8:19:5e:f0:27:be:4b:00:91:34:1d:72 cephuser@admin The key's randomart image is: +--[ RSA 2048]----+ | .=oE= | | .=+++o | | .. =O.. | | .+o + | | . . S | | . . | o | | | . . | | . | +-----------------+

키쌍을 생성했으므로 이제 모든 자원 노드에 공개 키(/home/cephuser/.ssh/id _rsa _pub ) 를 배포해야 한다. 공개 키는 모든 자원 노드의 /home/cephuser/.ssh/authorized _keys 파일에 저장해야 한다. 다행히 공개 키 배포를 도와주는 ssh-copy-id라는 도구가 있다. 다음 목록의 절차를 따라 관리 노드에서 각 자원 노드에 공개 키를 배포한다. 목록 10.4 관리 노드에서 공개 키 배포하기

$ ssh-copy-id cephuser@sm0.testco.com /usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed /usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -if you are prompted now it is to install the new keys cephuser@sm0.testco.com's password: [enter password] Number of key(s) added: 1

364 3부 상용 환경 구축하기

Now try logging into the machine, with: "ssh 'cephuser@sm0.testco.com'" and check to make sure that only the key(s) you wanted were added.

이제 관리 노드에 cephuser로 로그인하기만 하면 자원 노드에 안전한 방식으로 원격 로그인 할 수 있다. 더불어 이전의 sudoers 구성 덕분에 이제 모든 노드에서 특권 명령어를 실행할 수 있다. 다음 절에서는 세프를 배포하기 위해 사용하는 자동화 도구를 설치할 것이다.

10.1.2 세프 소프트웨어 배포하기 ceph-deploy는 세프 스토리지 배포를 자동화하기 위해 사용하는 스크립트의 모음이다. ceph-deploy를 다루는 방법을 습득하면 지루하고 낮은 수준의 반복 작업을 추상화하면서 세프의 동작 방식을 구성요소 수준까지 이해할 수 있을 것이다. 우분투 주주(12장에서 다룬 다)와 같은 더 일반적인 오케스트레이션 패키지와는 달리 ceph-deploy는 세프 스토리지 클 러스터를 생성하기 위해서만 사용된다. 즉, 오픈스택이나 다른 도구를 배포하기 위해 사용하지 는 않는다. 11장에서 완전히 자동화된 오픈스택 배포 도구를 사용해 오픈스택에서 사용할 세 프를 배포하고 구성해볼 것이다. 다음 목록과 같이 관리 노드에 ceph-deploy를 설치해보자. 목록 10.5 ceph-deploy 설치하기

$ wget -q -O- \ 'https://ceph.com/git/?p = ceph.git;a = blob _plain;f = keys/release.asc' \ | sudo apt-key add OK $ echo deb http://ceph.com/debian-dumpling/ $(lsb _release -sc) \ main | sudo tee /etc/apt/sources.list.d/ceph.list $ sudo apt-get update Hit http://ceph.com trusty InRelease Ign http://us.archive.ubuntu.com trusty InRelease

10장 세프 배포하기 365

... Fetched 2,244 kB in 5s (423 kB/s) Reading package lists... Done $ sudo apt-get install ceph-deploy Reading package lists... Done Building dependency tree Reading state information... Done The following packages will be upgraded: ceph-deploy …

이제 관리 노드에 ceph-deploy를 설치했다. 다음으로, 세프 클러스터를 구성할 것이다.

10.2 세프 클러스터 생성하기 이번 절에서는 세프 클러스터를 배포해볼 것이다. 이 클러스터는 오픈스택에 오브젝트 스토리 지나 블록 스토리지 등의 스토리지 자원을 제공하기 위해 사용할 수 있다.

10.2.1 초기 구성 파일 생성하기 세프 클러스터를 생성하는 첫 단계는 배포 환경에서 사용할 클러스터 구성 파일을 생성하는 것 이다. 이 단계에서 구성 파일은 관리 노드에 생성할 것이다. 다음 목록과 같이 세프 클러스터 구성 파일을 생성한다. MON 노드가 스토리지 클러스터의 데 이터 지도의 마스터 사본을 관리하기 때문에 이 단계에서는 앞서 지정한 모든 MON 노드를 참 조할 것이다. 목록 10.6 초기 클러스터 구성 파일 생성하기

$ ceph-deploy new sm0 sm1 sm2 [ceph _deploy.conf][DEBUG ] found configuration file at: /home/cephuser/.cephdeploy.conf [ceph _deploy.cli][INFO ] Invoked (1.5.21): /usr/bin/ceph-deploy new sm0

366 3부 상용 환경 구축하기

CHAPTER

퓨얼을 사용한 HA 오픈스택 자동 배포 퓨얼을 사용하기 위한 환경 준비하기

●●

퓨얼 서버 설치하기

●●

퓨얼을 사용해 오픈스택 배포하기

●●

이번 장은 퓨얼Fuel을 사용해 고가용성High Availability, HA 오픈스택 배포를 자동화하는 방법을 설명 한다. 자동화라고 말한 이유는, 자동 배포를 위해 하드웨어를 준비하고 환경 정보를 지정하기만 하면

5~8장에서 다룬 오픈스택 구성요소와 10장에서 다룬 세프 등 오픈스택 배포에 필요한 모든 절차를 자동화 도구가 수행해주기 때문이다. 고가용성이란 오픈스택 컨트롤러를 여러 개 사용 하는 아키텍처를 의미한다.

2장에서 데브스택 자동화 도구를 소개했다. 이 도구는 오픈스택 배포와 관련한 작업을 자동화 해주지만, 상용 환경에 배포하기 위한 것이 아니라 개발 도구로 사용하도록 만들어진 것이다. 상용 환경에서 사용하는 자동화 도구는 단순히 오픈스택을 설치하고 구성하는 것보다는 많은 기능을 해야 한다. OS 설치와 서버 측 네트워크 구성과 같은 사전 환경 준비도 할 수 있어야 한 다. 이번 장에서 소개할 도구도 이런 기능을 가지고 있지만 실제로 어떤 자동화 도구는 네트워 크 하드웨어까지도 구성할 수 있다. 상용 환경을 위한 자동화 도구는 감사 기능, 반복 기능, 안 정성을 가져야 하며, 상용 고객 지원도 제공해야 한다. 고가용성이란 특정 구성요소에 문제가 생기더라도 일정한 제한 내에서 배포 환경이 계속 동작 해야 한다는 것을 의미한다. 이 책의 2장과 2부에서 설명한 배포 환경에서는 컨트롤러를 하나 만 사용했다. 이런 방식의 배포 환경에서는 컨트롤러 서버나 관련 구성요소(MySQL 등) 중 하나에 문제가 생기면 오픈스택 배포 환경 전체에 문제가 된다. 하나밖에 없는 컨트롤러가 다

11장 퓨얼을 사용한 HA 오픈스택 자동 배포 383

시 동작하기 전까지는 인프라에 어떤 변경도 할 수 없다. 이번 장에서 소개할 HA 배포 환경에 서는 컨트롤러 하나가 고장나더라도 배포 환경은 평소처럼 계속 동작할 것이다. 다수의 컨트롤 러가 서로의 상태를 알고 있기 때문에, 한 컨트롤러가 고장나면 다른 컨트롤러가 대신 서비스 를 제공한다. 이번 장에서 소개할 오픈스택 배포 도구는 퓨얼이다. 퓨얼은 미란티스Mirantis (www.mirantis.

com )가 개발해 2013년에 오픈 소스로 공개했다. 2015년 후반에 오픈스택 재단은 퓨얼 을 정식으로 승인하고 “빅 텐트Big Tent” 프로젝트( governance.openstack.org/reference/

project )에 포함시켰다. 많은 상용 오픈스택 자동화 도구가 개발되어 있지만 완성도, 미란티 스 오픈스택 코드의 안정성, 상용 배포 사례 수, 상용 기술 지원 등 여러 요소를 고려해 이 책에 서는 퓨얼을 선택했다. 이번 장에서는 퓨얼을 사용해 HA 오픈스택을 배포하는 방법을 보여주 지만, 어떤 도구를 사용하든 대부분의 단계는 동일할 것이다. 먼저 환경을 준비하고 퓨얼 도구를 배포한 후 퓨얼을 사용해 오픈스택 환경을 배포할 것이다.

어떤 버전의 오픈스택을 사용할 것인가? 상용 환경에서는 사용할 오픈스택 버전뿐만 아니라 사용 중인 코드나 패키지 관리자도 함께 고 려해야 한다.

1부에서는 커뮤니티( https://github.com/openstack/)에서 직접 가져온 오픈스택 코드로 이루어진 데브스택을 사용했다. 2부에서는 우분투 클라우드 아카이브( https://wiki.ubuntu.

com/OpenStack/CloudArchive#Icehouse )의 아이스하우스 패키지(우분투 14.04 LTS의 기본 버전)를 사용했다. 이번 장에서는 퓨얼을 사용해 미란티스 버전의 오픈스택을 사용할 것 이다. 리눅스 버전마다 자체 커널과 사용자 패키지를 포함하고 있듯이 오픈스택도 마찬가지다. 적절한 오픈스택 배포 도구를 선택하기 위해서는 배포 도구의 기능뿐만 아니라 상용 오픈스택 패키지도 평가해봐야 한다.

384 3부 상용 환경 구축하기

11.1 환경 준비하기 일반적인 일괄 자동화의 의미는 언뜻 보면 차를 구매하는 경험과 유사하다. 서명란에 서명을 하고 판매자로부터 키를 받아 자유롭게 도로로 나가면 된다. 불행히도 오픈스택을 배포하는 표준 조립 라인이 없기 때문에 오픈스택 분야에는 어떠한 표준 배포 지원 모델도 존재하지 않 는다. 예를 들어, 윈도우나 리눅스 관리자라면 윈도우나 리눅스가 어디에 설치되어 있든 최소 한 기본적인 수준으로는 이해하고 있을 것이다. 이들 운영체제를 어떻게 배포하는가에 관해서 는 보편적인 규칙이 적용된다. 배포 방법 측면에서 볼 때 이러한 보편적인 규칙이 오픈스택, 즉 “클라우드 운영체제”에는 존재하지 않는다. 이것이 이 책이 필요한 이유다. 무언가가 고장나거 나 자동화 도구를 활용할 때 그 이면에서 발생하는 일을 어느 정도는 알 수 있도록 오픈스택 프 레임워크를 충분히 이해하고 있어야 한다. 자동 배포 환경을 준비하고 구성하는 것이 작은 규모의 환경을 수동으로 배포하는 것보다 더 오랜 시간이 걸릴 수도 있다. 그러나 기업에서는 작은 규모의 배포 환경에서도 자동화 도구를 사용하는 것이 매우 유용하다. 2부에서 완료한 작업을 반복할 수 있고, 기술 지원을 받을 수도 있으며, 동작을 추적하면서 필요하다면 검증도 할 수 있다는 점에서 도움이 될 것이다.

11.1.1 네트워크 하드웨어 2장과 6장에서 언급한 바와 같이, 기업의 시스템 관리자와 네트워크 관리자는 각자 부여받은 책임만 갖고 있기 때문에 오픈스택의 뉴트론 네트워크 구성요소가 헷갈릴 수도 있다. 시스템 관리자는 네트워크 가상화, 라우터, 오버레이 등을 다루지 않고, 네트워크 관리자는 가상 서버 환경 내부의 작업을 다루지 않는다. 관리하고 구성해야 할 부분이 분명 많이 존재할 것이다. 라우터나 스위치 구성에 대한 이해가 부족하면 이 어려움은 증폭된다. 라우팅이나 스위칭을 잘 알고 있더라도 네트워크 하드웨어에 직접 접속하는 방법을 모를 수도 있다. 혹은 오픈스택 배포를 위해 네트워크 하드웨어에 직접 접속할 수 있더라도 주소와 VLAN을 할당하거나 네트워크 하드웨어를 구성할 능력이 없을 수 도 있다. 이번 장을 살펴보고 나면, 직접 하든 누군가에게 시키든 간에 이런 작업을 할 수 있게 될 것이다.

11장 퓨얼을 사용한 HA 오픈스택 자동 배포 385

언태깅된 VLAN 대 태깅된 VLAN IEEE 802.1Q 네트워크 표준은 이더넷 프레임에 추가 정보를 넣어 가상 네트워크를 지정할 수 있도록 허용한다. 가상 로컬 영역 네트워크Virtual Local Area Network, VLAN는 OSI 2계층의 기능이다. 이를 이용하면 하나의 스위치를 여러 L2 네트워크로 분리할 수 있고 하나의 물리 트렁크 인터 페이스에 다수의 VLAN을 할당할 수도 있다. VLAN이 태깅tagged되면 VLAN 정보를 알려주는

802.1Q 헤더가 이더넷 프레임에 포함된다. 반대로 이더넷 프레임이 802.1Q 헤더를 갖고 있 지 않으면 언태깅untagged되었다고 한다. 일반적으로 스위치 간에는 태깅된 프레임(다수의 VLAN 이 같은 포트를 사용)을 사용해 통신하는 반면에 서버 간에는 언태깅된 프레임(포트당 하나의

VLAN을 사용)을 사용한다. 6장에서 설명했듯이 오픈스택에서 서버는 스위치처럼 동작하며, 스위치와 마찬가지로 태깅 혹 은 언태깅된 VLAN을 사용할 수 있다. 다음으로 넘어가기 전에 이 개념을 이해하는 것이 중요 하다. 이 책의 예제에서는 물리 스위치와 서버의 물리 네트워크 인터페이스 모두에서 태깅된

VLAN을 사용한다.

배포 네트워크 구성하기 이번 절에서는 다음 세 가지 작업을 할 것이다. 자동화 서버(퓨얼)에 접속할 수 있도록 구성한다.

●●

자동화 서버가 모든 호스트 서버에 접속할 수 있도록 구성한다.

●●

자동화 서버와 호스트 서버 모두에 대역 외 접속을 할 수 있도록 구성한다.

●●

이번 장에서 설명하는 배포 환경은 자동화 관리 네트워크와 대역 외out-of-band, OOB 네트워크라 는 두 개의 독립된 물리 네트워크를 사용한다. 관리 네트워크는 운영체제와 오픈스택 수준에서 호스트 서버를 관리하기 위해 자동화 시스템이 사용한다. OOB 네트워크는 하드웨어 수준에 서 서버에 접속해 구성하기 위해 사용한다.

386 3부 상용 환경 구축하기

OOB 네트워크의 중요성 OOB 네트워크 없이 오픈스택이나 대규모 시스템에서 작업하는 것은 하늘을 나는 동안 비행기 엔진을 고치는 것과 같다. 자동 배포를 위한 OOB 네트워크의 중요성은 아무리 강조해도 지나 치지 않다. 기존 환경 또는 심지어 오픈스택 수동 배포 환경에서 물리적으로 연결된 콘솔로 작업 할 수도 있다. 그러나 자동 배포 환경에서 프로비저닝하는 과정에는 하드웨어 측면에서 서버를 구성하기 위해 원격에서 네트워크에 접속해야 한다. 예를 들어 서버의 하드웨어 디스크 컨트롤 러나 부팅 장치를 구성할 때는 원격에서, 그리고 프로그램적으로 제어할 수 있어야 한다. 시스템 관리자나 네트워크 관리자에게는 OOB 네트워크에 접속하지 못하는 것보다 더 큰 두려 움은 없다. OOB 네트워크에 접속할 수 없다면 문제가 생긴 데이터센터에 직접 방문해야 하기 때문이다.

이 두 네트워크를 사용하는 방법은 다음 절에서 설명할 예정이지만, 지금은 예제의 각 서버마다 관리 네트워크와 OOB 네트워크를 위한 두 개의 분리된 네트워크 인터페이스가 있고 그 두 인 터페이스에서는 언태깅된 네트워크(VLAN )를 사용할 것이라는 점만 알고 있으면 충분하다.

스위치 업링크 포트 구성하기 관리 스위치를 실제로 사용하기 위해서는 상위 네트워크로 향하는 업링크를 구성해야 한다. [그림 11.1 ]에서 배포 환경의 물리 네트워크 토폴로지를 볼 수 있다. 이 그림은 업링크와 관리 스위치와 단일 오픈스택 호스트의 관계를 보여준다.

11장 퓨얼을 사용한 HA 오픈스택 자동 배포 387

그림 11.1 단일 호스트를 관리하기 위한 네트워크 하드웨어 토폴로지 업링크 스위치 태깅된 VLAN 95와 96(포트 1개에 다수의 VLAN 사용)

관리 스위치

언태깅된 VLAN 95와 96

OOB 네트워크는 하드 웨어 수준에서 서버에 접속해 구성하기 위해 사용한다(부팅 장치 설 정, 전원 온/오프).

OOB

관리

관리 네트워크는 운영체제와 오 픈스택 수준에서 호스트 서버를 관리하기 위해 자동화 시스템이 사용한다(PXE 부팅, OS 업데 이트).

서버 0 (단일 오픈스택 호스트)

예제에서 사용하는 오픈스택 관리 스위치인 Force10 S60의 스위치 인터페이스와 VLAN 구성 방법은 다음과 같다. 목록 11.1 OOB와 관리 네트워크 스위치 구성

interface GigabitEthernet 0/1 description "Uplink Port VLAN no ip address switchport no shutdown ! interface GigabitEthernet 0/2 description "OOB Server 0" no ip address switchport no shutdown ! interface GigabitEthernet 0/3

388 3부 상용 환경 구축하기

❶ 95,96"

❷

❸

CHAPTER

오픈스택을 사용한 클라우드 오케스트레이션 오픈스택 히트를 사용한 애플리케이션 오케스트레이션

●●

우분투 주주를 사용한 애플리케이션 오케스트레이션

●●

오케스트레이션Orchestration이란 정교하고 빈틈없는 계획과 운용을 통해 무언가를 배치하거나 조 정한다는 의미다. 아마도 앞의 정의 중 컴퓨팅 환경과 관련한 “배치”라는 단어는 눈에 익을 수 도 있다. 애플리케이션을 배포하려면 하드웨어와 소프트웨어 의존성을 정리해 적절히 배치해 야 한다. 이번 장, 어떤 면에서 이 책 전체는 정교하고 빈틈없는 오케스트레이션에 관한 것이 다. 특히 이번 장에서는 오픈스택 자원을 활용해 애플리케이션을 오케스트레이션하는 도구 몇 가지를 다룬다. 살펴볼 도구 중 일부는 공식 오픈스택 프로젝트며, 나머지는 연관 프로젝트다. 공식 오픈스택 오케스트레이션 도구들 내에도 의존성 계층 구조가 존재한다. 예를 들어 사용자 에게 애플리케이션 카탈로그를 제공하는 기능을 하는 무라노Murano 프로젝트는 인프라와 애플 리케이션 구성요소를 배포하기 위해 히트Heat 프로젝트의 도움이 필요하다. 의존 관계가 있는 인프라를 배치하기 위해 오픈스택 API와 직접 연동하는 단독 도구도 존재한다. 그 대표적인 예 로, 우분투 주주는 오픈스택 API를 사용해 애플리케이션을 배포한다. 이번 장은 인프라와 애플리케이션 사이에서 동작하는 공식 오픈스택 프로젝트인 히트부터 시 작한다. 다음으로, 독립형 우분투 도구인 주주를 살펴볼 것이다.

12장 오픈스택을 사용한 클라우드 오케스트레이션 413

12.1 오픈스택 히트 오픈스택 히트 프로젝트는 오픈스택의 기본 오케스트레이션 도구다. 여러 면에서 볼 때, 히트 는 오픈스택의 인프라 구성요소(노바, 신더 등)가 제조사 하드웨어와 소프트웨어를 위해 하는 일과 같은 역할을 애플리케이션을 위해 해주며, 이는 결국 통합을 간단하게 해준다. 오픈스택 이전에도 대규모의 자동화된 컴퓨트 클러스터가 존재했지만 클러스터 관리 시스템은 자체 제 작하거나 제조사에 의존했다. 오픈스택은 인프라 자원을 관리하기 위한 공통 인터페이스를 제 공한다. 그러나 애플리케이션을 배포하는 전체 과정에서 볼 때 인프라는 배포 과정의 일부에 지나지 않 는다. 빠른 시간 내에 가상 머신을 무제한으로 프로비저닝할 수 있는 시스템을 갖추고 있다고 하더라도 그 VM에서 동작하는 애플리케이션을 관리하기 위한 별도의 도구는 여전히 필요할 것이다. 또한 인프라와 애플리케이션 계층 어느 쪽이든 변화에 능동적으로 대응할 수 있어야 할 것이다. 예를 들어, 애플리케이션 성능이 임계값을 초과하는 경우 사람의 개입 없이 자동으 로 인프라를 추가하기를 원할 수도 있다. 이와 유사하게, 인프라 자원이 부족해지면 가장 덜 중 요한 애플리케이션이 자동으로 자원을 반납하기를 원할 수도 있다.

VM을 구성하는 인프라 자원을 잠시 생각해보자. VM에는 최소한 CPU, RAM, 스토리지 자원 은 포함되어야 한다. 오픈스택과 같은 환경에는 개별 자원 정보와 그 자원이 어떻게 VM을 형 성하는지를 기술하기 위해 정의된 형식이 존재한다. 이제 애플리케이션을 수동으로 배포할 때 필요한 모든 절차를 기술할 수 있다고 가정하자. 이때 사용하는 템플릿은 자원 의존성과 애플 리케이션 설치 지침을 포함하는 텍스트 형식의 기술서다.

12.1.1 히트 템플릿 오픈스택 히트는 오픈스택이 제공하는 인프라를 활용해 템플릿을 애플리케이션으로 변환한다. 템플릿에서 애플리케이션 스택을 생성하는 절차를 스태킹stacking이라고 한다. 당연히 히트의 기 능을 활용하기 위해서는 템플릿이 필요하다. 분명히 히트 설계자는 히트 프로젝트가 오픈스택 커뮤니티에서 가능한 한 유용하게 사용되기를 원했을 것이다. 이런 이유로 기존의 아마존 웹 서비스Amazon Web Services, AWS의 클라우드포메이션CloudFormation 템플릿 형식을 채택했고, 이를 히트 에서는 클라우드포메이션 호환 형식CloudFormation-compatible format, CFN으로 부른다. AWS 클라우드

414 3부 상용 환경 구축하기

포메이션은 히트보다 몇 년 앞선 2011년 4월에 발표되었으며 https://aws.amazon.com/

cloudformation/aws-cloudformation-templates/에서 많은 CFN 템플릿을 이용할 수 있다.

CFN 템플릿의 구조를 다음 목록에서 볼 수 있다. 목록 12.1 AWS 클라우드포메이션 템플릿 형식

{ "AWSTemplateFormatVersion" : "버전 날짜", "Description" : "JSON 문자열", "Parameters" : { // 스택 입력 유형 및 값을 선언한다. }, "Mappings" : { // Resources와 Outputs 단계에서 참조할 키/값 쌍을 할당한다. }, "Conditions" : { // 스택 생성을 위한 논리 조건을 지정한다. }, "Resources" : { // 자원 의존성과 애플리케이션 설치 절차를 선언한다. }, "Outputs" : { // 스태킹 완료 시 출력할 값을 선언한다. } }

기존에 만들어진 많은 템플릿을 히트에서도 사용할 수 있다는 점에서 CFN 형식을 지원하는 것 이 가치는 있지만, 결국 이 형식은 여전히 AWS를 위해 설계된 형식일 뿐이다. 히트 프로젝트 참여자들은 오픈스택 전용 형식이 필요하다고 결정하고 HOTHeat OpenStack Template 형식을 만들었 다. CFN 템플릿이 JSON 형식인 반면에 HOT 템플릿은 YAML 형식으로 구성된다. HOT 규 격은 아이스하우스 버전(2014년 4월) 이후로 히트의 표준 템플릿이다. 다음 HOT 템플릿은 오픈스택 히트 공식 문서에서 가져온 워드프레스 배포 템플릿의 일부다.

12장 오픈스택을 사용한 클라우드 오케스트레이션 415

목록 12.2 HOT 템플릿 예제

heat _template _version: 2013-05-23 description: > ❶ Heat WordPress template to support F20, using only Heat OpenStack-native resource types, and without the requirement for heat-cfntools in the image. WordPress is web software you can use to create a beautiful website or blog. This template installs a single-instance WordPress deployment using a local MySQL database to store the data. parameters: ❷ image _id: type: string description: > Name or ID of the image to use for the WordPress server. Recommended values are fedora-20.i386 or fedora-20.x86 _64; get them from http://cloud.fedoraproject.org/fedora-20.i386.qcow2 or http://cloud.fedoraproject.org/fedora-20.x86 _64.qcow2 . default: fedora-20.x86 _64 resources: ❸ wordpress _instance: type: OS::Nova::Server properties: image: { get _param: image _id } ... user _data: str _replace: template: | #!/bin/bash -v yum -y install mariadb mariadb-server httpd wordpress ... outputs: ❹ WebsiteURL: description: URL for WordPress wiki ...

❶ 템플릿에 대한 설명 ❷ 입력 유형과 값을 선언 ❸ 자원 의존성과 애플리케이션 설치 절차를 선언 ❹ 스태킹 완료 시 출력할 값을 선언

416 3부 상용 환경 구축하기

CFN과 HOT 형식 모두 기본 구성요소는 동일하지만, 이들은 서로 다른 템플릿 언어다. 이 템 플릿 언어는 프로그래밍 언어로 생각할 수 있다. 처음에는 오케스트레이션 템플릿이 프로그래 밍 언어로 보이지 않을 수도 있지만, 언어의 기본 속성을 생각해보면 컴퓨터 언어는 컴퓨터 시 스템에 명령을 전달하기 위해 사용하는 형식 언어다. 템플릿이 형식 언어라면 히트는 그 언어의 번역기 역할을 한다. 템플릿 번역의 중간(처리 단계) 결과는 애플리케이션을 오픈스택이 제공 하는 인프라에 배포하는 데 필요한 모든 명령어의 집합이다. 번역의 최종 결과는 템플릿 언어로 기술된 명령어를 실행해 배포가 완료된 최종 시스템이며, 이때 템플릿의 outputs 절에 정의한 내용이 출력된다. 히트 프로젝트를 구성하는 개별 애플리케이션을 [표 12.1 ]에 정리했다. 표 12.1 히트 애플리케이션 이름

설명

heat

히트 API와 통신하는 CLI 도구

heat-api

오픈스택 내장 REST API

heat-api-cfn

AWS 형식의 질의 API(AWS 클라우드포메이션 API 호환)

heat-engine

API로부터 입력을 받아 템플릿 언어를 번역하는 엔진

다음으로, 히트를 사용해 스택을 생성하는 방법을 살펴볼 것이다.

12.1.2 히트 예제 이번 절에서는 히트의 명령줄 도구를 사용해 간단한 애플리케이션 스택을 배포해볼 것이다. 그 러나 히트는 단순히 애플리케이션을 배포하는 것 이상의 역할을 한다. 히트를 오픈스택 실로미 터(사용량 측정 서비스)와 함께 사용하면 템플릿에 기술한 정책에 기반해 자원의 크기를 동적 으로 조정할 수 있다. 히트의 오토스케일링autoscaling 기능에 관한 전체 세부 내용은 오픈스택 히 트 공식 문서(http://docs.openstack.org/developer/heat/)에서 찾을 수 있다.

2장에서 데브스택을 사용해 오픈스택을 배포해보았다. 이번 장의 예제는 데브스택 환경에서 배포할 예정이지만, 히트가 동작하기만 하면 어떤 환경이든 사용할 수 있다. 이미 히트가 잘 동 작 중이라면 “스택 의존성 확인하기” 절은 건너뛰어도 좋다.

12장 오픈스택을 사용한 클라우드 오케스트레이션 417

데브스택에서 히트 활성화하기 2장에서 배포한 데브스택 환경을 사용하고 있다면 히트를 활성화하기 위해 local.conf 스크 립트 파일의 구성을 조금 변경해야 한다. 데브스택 환경의 명령어 셸에 접속해 다음 몇 줄을 /opt/devstack/local.conf에 추가한다. 목록 12.3 데브스택의 local.conf에서 히트 활성화하기

# Enable Heat (orchestration) Service enable _service heat h-api h-api-cfn h-api-cw h-eng HEAT _BRANCH = stable/juno

추가한 구성은 모든 히트 서비스를 활성화하고 사용할 버전을 지정한다. 이 구성을 추가할 때

HEAT _BRANCH 항목의 버전명은 구성 파일 내의 다른 구성요소의 버전명과 일치해야 한다. local.conf 파일에 히트와 관련한 구성을 완료한 후, 2.2.4절의 스태킹 및 언스태킹 절차를 반 복하고 다음 목록의 명령어를 실행해 환경 변수를 설정한다. 목록 12.4 환경 변수 설정하기(/opt/devstack 디렉터리에서 실행)

$ source openrc

3장의 내용을 되짚어보면, 데브스택이 제공하는 openrc 스크립트는 사용자가 오픈스택 서비 스와 상호작용할 수 있도록 셸의 환경 변수를 설정해준다. 이제 히트 환경이 동작 중이고 콘솔 접근 권한을 얻었다. 다음으로, 첫 번째 스택을 만들기 위 해 모든 의존성을 정리해야 한다.

스택 의존성 확인하기 오픈스택 환경이 스태킹할 준비가 되었는지 확인하기 위해 몇 가지 추가 절차가 필요하다. 먼 저 [표 12.1 ]의 heat 애플리케이션을 포함한 오픈스택 구성요소에 명령줄 접근이 가능한지 확인해야 한다. heat 애플리케이션의 전체 명령어 목록은 오픈스택 공식 문서(http://docs.

openstack.org/cli-reference/heat.html )에서 찾을 수 있다. 다음 목록의 heat 명령어를 실행해 히트의 기본 작업 방법을 확인해보자.

418 3부 상용 환경 구축하기

목록 12.5 히트 스택 출력하기

예상한 대로, 이 예제에서는 아직 어떤 스택도 출력되지 않지만, 이것만으로도 환경 변수를 적 절히 설정했고 히트를 제대로 설치했음을 확인할 수 있다. 히트 문제인가? 환경 설정 문제인가? 앞의 단계에서 오류가 발생했다면 오류 메시지를 유심히 살펴봐야 한다. 오류가 히트와 관련된 것인가? 아니 면 자격 인증과 관련된 문제인가? 환경 변수를 제대로 설정했는지 확인하려면 노바 등의 서비스가 잘 동작 하고 있는지 확인해봐야 한다(nova list ). 노바에 접근할 수 있다면 문제는 히트 자체에 있을 가능성이 크다. 노바에 접근할 수 없다면 환경 변수와 관련한 문제일 가능성이 크다.

오픈스택 구성요소에 접근할 수 있으므로, 이제 시스템에서 사용할 수 있는 이미지를 확인해야 한다. 앞서 여러 장에서 언급한 것처럼 이미지는 글랜스 서비스가 관리한다는 사실을 기억할 것이다. 글랜스를 사용해 다음과 같이 모든 이미지를 출력해보자. 목록 12.6 글랜스 이미지 출력하기

$ glance image-list +-----------------------------------------+-------------+..+ | ID | Name | Disk Format |.. +-----------------------------------------+-------------+..+ | b5...d9 | Fedora-x86_64-20-20140618-sda | qcow2 |.. +-----------------------------------------+-------------+..+

데브스택 환경에서 히트를 활성화했다면, 데브스택 스태킹 과정에서 추가된 새 이미지 하나를 확인할 수 있을 것이다. 이번 히트 스태킹 예제에서는 이 새 페도라Fedora 이미지를 사용할 것이 다. 데브스택을 사용하지 않거나 페도라 이미지가 출력되지 않는다면 201페이지의 “이미지 관 리” 절에서 설명한 대로 이미지 하나를 추가하기 바란다.

12장 오픈스택을 사용한 클라우드 오케스트레이션 419

히트가 지원하는 이미지 히트 템플릿에는 어떤 이미지라도 지정할 수 있지만, 어떤 템플릿은 이미지 내에 미리 설치되어 있어야 하 는 히트 클라우드포메이션 도구를 사용한다. 페도라 F20 이미지( http://cloud.fedoraproject.org/

fedora-20.x86_64.qcow2 )1는 heat-cfntools를 내장하고 있어 히트 이미지로 흔히 선택된다.

마지막 준비 단계는 스태킹 절차 동안 호스트에 밀어 넣을 SSH 키쌍을 만드는 것이다. 이미지 와 마찬가지로 어떠한 키쌍이라도 템플릿에 지정할 수 있다. 이번 예제에서는 다음 목록에서 보듯이 히트 인스턴스에 사용할 heat _key라는 이름의 새로운 키쌍을 만들 것이다. 인스턴스 에 직접 접근할 필요가 있다면 heat _key를 저장해두어야 한다. 목록 12.7 히트 SSH 키쌍 생성하기

$ nova keypair-add heat _key > heat _key.priv $ chmod 600 heat _key.priv

이제 이미지, 플레이버flavor, 키쌍을 사용해 히트 스택을 만들 준비가 되었다. 이제 스태킹 절차 를 마무리할 때다.

히트 스택 구동하기 이제 템플릿을 제외하고는 필요한 모든 준비가 완료되었다. 좋은 소식으로, 오픈스택 깃허 브 저장소( https ://github .com /openstack /heat -templates )에 이미 만들어진 템플 릿이 많이 있으며, AWS 클라우드포메이션 템플릿 사이트( http ://aws .amazon .com /

cloudformation/ aws-cloudformation-templates/)에서도 더 많은 템플릿을 찾을 수 있 다. 절차의 마지막 단계는 템플릿을 선택한 후 템플릿 parameters 항목을 정의하는 것이다. 이번 장의 앞 절에서 템플릿 parameters 항목은 특정 스택의 구체적인 속성을 기술하기 위해 사용하는 키/값 쌍이라고 한 것을 기억할 것이다. 이 단계를 위해 오픈 소스 콘텐츠 관리 시스템인 워드프레스를 배포해주는 히트 템플릿을 사용 할 것이다.

1 옮긴이_ 번역 시점에는 이 주소를 사용할 수 없었다. 대신 https://goo.gl/qk19BR 주소에서 최신 버전인 페도라 23을 내려받을 수 있다.

420 3부 상용 환경 구축하기

INDEX A

access list 76

Cactus 48

Access & Security 75, 88, 425

Ceilometer 47, 137

Active Directory (AD) 182

CentOS 57

admin node 359

Ceph 45, 356

adminurl 189

ceph -deploy 359, 365

Advanced Message Queuing Protocol 176 Advanced Packaging Tool (APT) 58, 175, 236 AKI 80, 202 Amazon Web Services (AWS) 31, 414 AMI 80, 202 AMQP 176 Ansible 351 API Access 75, 425

ceph -deploy disk list 372 ceph -deploy disk zap 373 ceph -deploy forgetkeys 376 ceph -deploy install 368 ceph -deploy mon create -initial 369 ceph -deploy new 366 ceph -deploy osd activate 375 ceph -deploy osd prepare 374 ceph -deploy purge 368, 376

ARI 80, 202

ceph -deploy purgedata 376

Associate Floating IP 93

ceph -deploy uninstal 368

asymmetric routing 239

ceph health 375

Austin 48

ceph osd pool create 377

autoscaling 417

CFN 414, 415

Availability Zone 88

charm 141, 428

Azure 36

Chef 351

CIDR 115, 262 Cinder 47, 51, 137

Barbican 49

cinder create 296

bare 201, 202

cinder list 295

bare -metal 231

cinder -manage db sync 210

Bexar 48

cinder quota -show 133

Big Tent 384

cirros 82, 92

bind -address 179

CLI 디버깅 100

Boot Loader 465

cloud 30

bootstrap 141, 430

CloudFormation 414

br -ex 245 bridge -utils 237 br -int 245, 313 broadcast domain 451

CloudFormation -compatible format 414 cloud -init 79, 248, 253 Compute Services 325 Console 91 controller 144 control plane 160

찾아보기

467

INDEX Core 136

core project 47

Fedora 57

cpu -checker 315

Fiber Channel (FC) 151

Create Image 83

Fiber Channel over Ethernet (FCoE) 151

Create Images 81

flavor 327

Create Volume 84, 298

Flavor 88

Create Volumes 81

Floating IPs 75, 77

CRUSH rules 377

Folsom 48

curl 73

Fuel 383 Fully Qualified Domain Name (FQDN) 367

D data gravity 349

data plane 160

Gating 136

DBaaS 49

Generic Routing Encapsulation (GRE) 148, 243, 247, 313, 355

dbus 319 Debian 57

git 60

default 네트워크 브리지 319

GitHub 61

descriptor 286

Glance 47, 137

Designate 49 Details 88 Device Name 88 Device Size 88 DevOps 352 DHCP 392 DHCP 에이전트 118, 248, 252, 264 Diablo 48 Distributed Virtual Routing (DVR) 353 DNSmasq 248

glance -api 200 glance image -create 203, 426 glance image -list 419, 426 glance -manage db _ sync 200 glance -registry 200 GRE 터널 315 Grizzly 48 GRUB 부트로더 465

H Havana 48

Docker 42

heat 417

Download OpenStack RC File 425

Heat 47, 137

Dynamic Kernel Module Support (DKMS) 244

heat -api 417

heat -api -cfn 417 heat -engine 417

erasure coding 377

heat event -list 422

Essex 48

Heat OpenStack Template 형식 415

ESXi 39

heat stack -create 421

Ethernet Hardware Address (EHA) 241

heat stack -delete 423

exercises 67

heat stack -list 419, 422

468 찾아보기

heat stack -show 423

juju init 427

Helion 351

juju metadata generate -image 429

High Availability (HA) 383

juju metadata generate -tools 430

Horizon 47, 137

juju ssh 434

HOT 템플릿 415

juju status 431, 432, 435

HP 힐리온 351

Juno 49

hybrid cloud 37 Hyper -V 39, 342, 346

K Kernel -based Virtual Machine (KVM) 39,

315, 317, 346

Icehouse 49

Key Pairs 75, 77

IEEE 802.1Q 238, 386

key -pair 인증 362

Image Name 88

Keystone 47, 137

Images 79, 82

keystone discover 187

Images & Snapshots 79

keystone endpoint -create 190, 198, 208,

Incubated 136

215, 221

Infrastructure as a Service (IaaS) 36, 46

keystone -manage db _ sync 186

Instance Boot Source 88

keystone role -create 192

Instance Count 88

keystone role -list 105, 108

Instance Name 88

keystone service -create 188, 197, 208, 214,

Instances 86

221

instruction set 35

keystone tenant -create 104, 191

internalurl 189

keystone tenant -list 105, 128, 258

Internet Small Computer System Interface 151

keystone tenent -id 261

ip netns 270

keystone user -create 106, 191, 196, 206,

ip netns exec 269

213, 219

ip netns list 269

keystone user -list 107

Ironic 49

keystone user -role -add 108, 193, 196,

iSCSI 151 ISO 80, 202

207, 213, 220 keystone user -role -list 193, 207, 214, 220 Kilo 49

J Journal 371

kvm _ amd 318 kvm _ intel 318

JSON 형식 99, 415 Juju 351

juju add -relation 433

L3 에이전트 248, 251

juju bootstrap 430

Launch Instance 87, 138

juju deploy 432, 433, 435

Liberty 49

juju expose 434, 435

Libvirt 317

찾아보기

469

INDEX libvirtd 319

net.ipv4.conf.default.rp _ filter 240, 311

Lightweight Directory Access Protocol (LDAP) 182

net.ipv4.ip _ forward 239 Network Agents 272

Link Layer Discovery Protocol (LLDP) 411

Network File System (NFS) 151

Linux Bridge 42

Networking 89

Linux -IO (LIO) 292

Network Time Protocol (NTP) 361

local.conf 62

Network Topology 272

Logical Unit Number (LUN) 339

Neutron 47, 51, 137

Logical Volume Manager (LVM) 154, 283, 345,

neutron net -create 112, 121, 258, 265

355

neutron net -external -list 119

lsmod 243, 312, 318

neutron quota -show 133

lvdisplay 297

neutron router -create 116, 262

LXC 39, 346

neutron router -gateway -clear 125 neutron router -gateway -set 119, 126, 268

neutron router -interface -add 117, 263

Manage Floating IP Associations 93

neutron router -list 125, 269

Manage Rules 94

neutron router -show 126, 268

Manila 49

neutron subnet -create 114, 123, 260, 266

mapper 373

neutron 명령어 257

Maximum Transmission Unit (MTU) 381

Nova 47, 51, 137

MDS 360

nova boot 98, 327, 329

Media Access Control (MAC) 241

nova -compute 325

Mirantis Fuel 351

nova flavor -list 98, 328

mirco -op 디코딩 35

nova help 99

ML2 플러그인 162, 216, 248, 321, 354

nova image -list 97, 328

modprobe 244, 313, 318

nova keypair -add 420

MON 노드 360, 366

nova list 327, 330, 433

multi -tenancy 36, 71

nova -manage 224

multi -tenant 36, 339

nova -manage db sync 224

my.cnf 179

nova net -list 329

MySQL 178

nova quota -show 128, 130

MySQL 콘솔 180

nova quota -update 129, 132

NASA 48

OOB 관리 카드 391

NAT 92

OOB 관리 콘솔 393

Nebula 48

OOB 네트워크 386, 390

net.ipv4.conf.all.rp _ filter 240, 311

OOB 웹 인터페이스 392

470 찾아보기

Open Government Directive 48

Open Government Framework 48

QCOW 80, 202

Open Networking Foundation (ONF) 162

qcow2 201

openrc 96, 418

qemu -utils 300

OpenStack Summits 49

Quantum 162

OpenSUSE 57

Quick Emulator (QEMU) 39, 317

Open vSwitch (OVS) 42, 240, 311, 354

quota 74

orchestration 36

Orchestration 413 OSD 360

rabbitmqctl 176, 177

OSD 노드 370

Rackspace 48

out -of -band (OOB) 386

RADOS 359

out -of -order execution 35

rados 명령어 378

ova 202

raw 202

Overview 74

RAW 80

OVF 201, 202

Red Hat 40

OVS -HybridIptablesFirewallDriver 76 ovs -system 246, 315 ovs -vsctl 245, 313 OVS 에이전트 250, 321 ownership 377

region 189 rejoin -stack.sh 71 Related 136 replication 377 resource node 359 RESTful API 47, 137 reverse path filtering 239

P Peripheral Component Interconnect Express (PCI -E) 151 Physical to Virtual (P2V) 336 placement groups 376 Platform as a Service (PaaS) 46

Rocket 42 Role -Based Access Control (RBAC) 47, 137, 182

S Sahara 49 screen 67

Policy Inaccessible (PI) 76

SCSI ID 285

Preboot eXecution Environment 부팅

Searchlight 49

(PXE 부팅) 394

Security Groups 75

public key 362

Service Level Agreement (SLA) 348

publicurl 189

shared -nothing 342

Puppet 351

Software as a Service (SaaS) 46

pvcreate 286

Software Defined Network (SDN) 156

pvdisplay 286, 287

source 96, 187

pvscan 286

ssh -copy -id 364

python -cinderclient 295

ssh -keygen 364

찾아보기

471

INDEX sshpass 393

virsh net -undefine 319

SSH 키쌍 420

Virtual Local Area Network (VLAN) 238

stacking 51, 414

Virtual Machine Monitor (VMM) 39

stack -screenrc 71

Virtual to Virtual (V2V) 337

stack.sh 65

VLAN 토폴로지 341

Storage Area Network (SAN) 345

VM 75

sudo 173, 362

VMDK 80, 202, 337

sudoers 362

VMware ESXi 346

Supporting 136

VMware vSphere 337

SUSE 40

VM 볼륨 276

Swift 47, 48, 137

VM 오브젝트 139

Symmetric Multi -Processing (SMP) 29

VOLUME _ BACKING _ FILE _ SIZE 85

sysctl 238, 310

Volumes 84, 298

sysctl -p 240, 311

Volume Snapshots 82

System Info 272, 325

Volumes & Snapshots 298 VXLAN 243, 313, 355

T Telemetry 47

W ~ Z

Tempest 67

WordPress 141

tgt 291

x86 29

Thin Provisioning 283

x86 _ 64 35

Trove 49, 137

x86 명령어 집합 35

Trusty Tahr 57

XenServer/XCP 39 YAML 형식 415

U Ubuntu 40

zapping 371 Zaqar 49

Ubuntu Juju 141 udev 285

ㄱ

Unified Extensible Firmware Interface (UEFI) 394

가상 머신 31

unstack.sh 70

가상 머신 모니터 39 가상화 확장 기능 57

가용 영역 88

Vagrant 56, 351

게이팅 136

VDI 80, 202

고가용성 383

vgcreate 286

고성능 컴퓨터 (HPC) 352

vgdisplay 288

공개 키 362

VHD 80, 202

공용 클라우드 347

virsh - -connect 319

공유 서비스 137, 181

virsh net -destroy 319

공유 호스트 볼륨 342

472 찾아보기

공인 네트워크 265

대시보드 137, 225

공인 인터페이스 172

대역 외 (OOB) 386

관리 네트워크 386

대칭형 다중 처리 29

관리 노드 359

데브스택 51

그리즐리 48

데브스택 엑서사이즈 67

글랜스 47, 137, 181, 194

데브옵스 352

글랜스 서비스 194, 197

데비안 57

글랜스 엔드포인트 194

데이터베이스 서비스 137, 181

깃 60

데이터 중력 349

깃허브 61

데이터 평면 160 데지그네이트 49

ㄴ

도커 42, 346

내부 네트워크 112, 258

디아블로 48

내부 서브넷 113, 259 네임스페이스 269

ㄹ

네트워크 ID 119

라우터 생성 116

네트워크 노드 168

라이브러리 136

네트워크 서비스 211

랙스페이스 48

노드 주소 172

레드햇 40

노바 47, 51, 137

레드햇 RDO 351

노바 API 218

로켓 42

노바 구성요소 322

리눅스 SCSI 대상 (target) 프레임워크 291

노바 네트워크 352

리눅스 네임스페이스 252

노바 서비스 221

리눅스 네트워크 네임스페이스 269

노바 엔드포인트 221

리눅스 브리지 42, 237

논리 볼륨 286

리눅스 컨테이너 42

논리 볼륨 관리자 283

리버티 49

뉴트론 47, 51, 137

리전 189

뉴트론 API 211 뉴트론 CLI 257

ㅁ

뉴트론 서비스 214

마닐라 49

뉴트론 엔드포인트 214

마이크로소프트 애저 36

뉴트론 콘솔 111, 257

마이크로 옵 (mirco -op) 디코딩 35 매체 접근 제어 241

ㄷ

메모리 가상화 35

다중 노드 229

메시 (mesh) 분산 구조 143

다중 노드 아키텍처 168

메시 네트워크 247

다중 테넌시 36, 71

메커니즘 드라이버 163, 354

다중 테넌트 36, 101, 339

메타데이터 서버 노드 360

찾아보기

473

INDEX 메타데이터 에이전트 248, 253

세프 클러스터 구성 파일 366

모니터 노드 360

세프 풀 376

무라노 (Murano) 프로젝트 413

셰프 351

물리 볼륨 286

셸 자동 완성 96

미란티스 퓨얼 351

소유권 377 소프트웨어 정의 네트워크 (SDN) 156, 160

ㅂ

수세 40

바비칸 49

스냅샷 80, 283

배치 그룹 376

스위프트 47, 48, 137, 343

버추얼박스 55, 80

스크린 67

범용 오케스트레이션 도구 351

스태킹 51, 58, 414

베어메탈 231, 346

스토리지 노드 168

베이그런트 56, 351

스토리지 드라이버 355

복제 377

스토리지 오브젝트 139

볼륨 그룹 286

스토리지 인터페이스 281

볼륨 그룹 디스크립터 286

시큐리티 그룹 76

부트스트랩 141, 430

신더 47, 51, 137

부트스트랩 에이전트 424

신더 API 289

부트스트랩 인스턴스 430

신더 서비스 207

분산 가상 라우팅 (DVR) 147

신더 엔드포인트 207

분산 서비스 거부 (DDoS) 239

실로미터 47, 137, 181

분산 컴퓨팅 모델 143

씬 프로비저닝 283

브로드캐스트 도메인 451 블록 스토리지 44, 86, 137, 149, 344, 355

ㅇ

블록 스토리지 (신더) 204

아마존 웹 서비스 31, 414

비대칭 라우팅 239

아무것도 공유하지 않는 (shared -nothing) 모델 342

비순차 실행 35

아이덴티티 47

빅 텐트 384

아이덴티티 서비스 137, 181, 182 아이러닉 49

ㅅ

아이스하우스 49

사설 클라우드 36, 338, 347

아파치 225

사용자 ID 107

액티브 디렉터리 182

사용자 생성 191

앤시블 351

사하라 49

어셈블리 34

서브넷 ID 115

언스태킹 66, 70

서비스 수준 동의 348

언태깅된 VLAN 386

서치라이트 49

에섹스 48

세프 45, 356

엔드포인트 182, 187, 197, 214, 221

세프 CLI 369

역경로 필터링 239, 311

474 찾아보기

역할 101, 182

인스턴스 이름 88

역할 기반 접근 제어 47, 137, 182

인증 토큰 137

역할 생성 192

일시적 (ephemeral) 스토리지 344

역할 출력 193

일체형 (monolithic) 네트워크 플러그인 353

역할 할당 107, 193 연관 프로젝트 136, 141

ㅈ

열린 정부 지침 48

자동화 338

열린 정부 프레임워크 48

자원 노드 145, 229, 359

영구적 (persistent) 스토리지 344

자카르 49

오버레이 (overlay) 네트워크 231, 243, 355

장애 복구 (resilience) 방식 376

오브젝트 스토리지 45, 86, 137, 149, 343

장치 이름 88

오브젝트 스토리지 장치 노드 360

장치 크기 88

오스틴 48

재핑 371, 373

오케스트레이션 36, 141, 413

저널 371

오케스트레이션 서비스 137, 181

저널 볼륨 371

오토스케일링 417

점보 (jumbo) 프레임 381

오픈수세 57

접근 목록 76

오픈스택 API 72, 99

접근 불가 정책 76

오픈스택 CLI 72, 96

제어 노드 145

오픈스택 대시보드 72

제어 평면 160

오픈스택 분산 구성요소 146

제조사 네트워크 시스템 154

오픈스택 분산 모델 145

제조사 스토리지 149

오픈스택 서밋 49

젠서버 (XenServer)/XCP 39

오픈스택 템페스트 67

주노 49

외부 네트워크 119, 120, 265

주주 351

외부 서브넷 122

주주 CLI 141

우분투 40, 57

주주 GUI 434

우분투 주주 141, 413, 424

중첩 (nested) 가상화 57

우분투 클라우드 아카이브 330

지원 136

워드프레스 141, 420 유니버스 (universe) 저장소 427

ㅊ

유동 IP 77, 92

참 141, 428

의존성 지옥 421

참 CLI 432

이더넷 하드웨어 주소 241 이레이저 코딩 377

ㅋ

이미지 서비스 137, 181, 194

캐시 볼륨 283

이미지 이름 88

캑터스 48

인스턴스 75

커널 장치 매퍼 373

인스턴스 부팅 소스 88

컨테이너 346

인스턴스 수 88

컨테이너 형식 201

찾아보기

475

INDEX 컨트롤러 144

페도라 57

컨트롤러 노드 168

폴섬 48

컴패니언 VM 54

퓨얼 383

컴퓨트 137

퓨얼 CLI 402

컴퓨트 노드 151, 168

퓨얼 웹 인터페이스 402

컴퓨트 (노바) 서비스 218

프로젝트 102

퀀텀 162

플랫 DHCP 토폴로지 341

크러시 규칙 376

플랫 네트워크 109, 255

클라우드 30

플랫 토폴로지 341

클라우드 운영체제 32

플랫폼 추상화 338

클라우드 이미지 79

플러그인 152, 160

클라우드포메이션 414

플레이버 88, 327

클라우드포메이션 호환 형식 414 키스톤 47, 137, 181, 182

ㅎ

키스톤 서비스 187

하둡 352

키스톤 엔드포인트 190

하바나 48

키쌍 (key -pair) 인증 362

하이브리드 분산 모델 144

킬로 49

하이브리드 클라우드 37, 347, 350 하이퍼바이저 39, 147, 303, 315, 346

ㅌ

할당량 74, 127

타입 드라이버 163, 354

핵심 프로젝트 47, 136

태깅된 VLAN 386

허브 241

터널링 243

허브 앤드 스포크 (hub and spoke) 분산 구조 143

테넌트 31, 182, 190

호라이즌 47, 137, 225, 272

테넌트 ID 104, 258

호스트 간 내부 통신 156

테넌트 네트워크 109, 256

호스트 간 외부 통신 156

테넌트 모델 101, 138

호스트 내 통신 156

테넌트 사용자 할당량 130

환경 변수 96

테넌트 생성 104, 190

히트 (Heat) 47, 137, 181

테넌트 할당량 128

히트 프로젝트 413

텔레메트리 47 텔레메트리 서비스 137, 181

기 타

트러스티 타르 57

10Base2 241

트로브 49, 137, 181

10BaseT 241

ㅍ 파이썬 225 파일 스토리지 86 퍼펫 351

476 찾아보기

w w w. h a n b i t . c o . k r

이것이 프로그래밍이다! 저자 직강 동영상 제공!

이것이 안드로이드다

이것이 C언어다

이것이 자바다

진정한 안드로이드 개발자로 이끌어줍니다.

세상에 없던 새로운 C언어 입문서 탄생!

가장 중요한 프로그래밍 언어를 하나 배워야 한다면, 결론은 자바다!

SDK 5.0 롤리팝 호환!

삼성, LG에서 펼쳐졌던 전설의 명강의를 풀타임 동영상 강좌로!

중급 개발자로 나아가기 위한 람다식, JavaFX, NIO 수록

이보다 더 확실한 방법은 없다, 칠판강의

책만 보고, 동영상 강좌로도 만족하지 못했다면 Daum 카페 '슈퍼드로이드'에서 만나요

전체 동영상 강좌 유투브 전격 공개!

자바의 모든 것을 알려주는 인터넷 강의 궁금한 것은 카페에서!

cafe.daum.net/superdroid

http://goo.gl/tJK3Tu

cafe.naver.com/thisisjava

박성근 저 | 1,164쪽 | 45,000원

서현우 저 | 708쪽 | 25,000원

신용권 저 | 1,224쪽 | 30,000원

w w w. h a n b i t . c o . k r

지금은 모던 웹 시대! 모던 웹 디자인을 위한

모던 웹을 위한

HTML5 + CSS3 입문 HTML5 분야 부동의 1위 도서

JavaScript + jQuery 입문

HTML5 표준안 확정에 맞춘 완전 개정판의 귀환!

자바스크립트에서 제이쿼리, 제이쿼리 모바일까지 한 권으로 끝낸다!

HTML5 권고안과 최신 웹 브라우저 환경 대응

시대의 흐름에 맞춰 다시 쓴 자바스크립트 교과서

윤인성 저 | 624쪽 | 30,000원

윤인성 저 | 980쪽 | 32,000원

모던 웹을 위한

HTML5 + CSS3 정복

Node.js

프로그래밍 페이스북, 월마트, 링크드인은 왜 Node.js를 선택했는가?

필요한 것만 배워 바로 현장에서 쓰는 HTML5

이 물음에 대한 답은 Node.js가 보여주는 빠른 처리 능력 때문이다.

순서대로 읽으며 실습할 수 있는 HTML5 자습서

윤인성 저 | 484쪽 | 25,000원

김상형 저 | 700쪽 | 32,000원

w w w. h a n b i t . c o . k r

Hanbit eBook

Realtime w w w. h a n b i t . c o . k r / e b o o k

DRM free! 어떤 디바이스에서도 자유롭게

eBook Oriented! 전자책에 꼭 맞는 최적의 내용과 디자인

Hanbit eBook

Realtime 70

Realtime 89 49

MFC 프로그래밍 주식분석 프로그램 만들기 김세훈 지음

Hanbit eBook

Realtime 90

Realtime 92 49

자바 개발자를 위한

Vert.x JavaScript Promise azu지음 /주우영옮김

애플리케이션 개발 모바일/웹 메시징 STOMP와 MQTT로 개발하는 IoT 모바일/웹 애플리케이션 Mobile and Web Messaging 제프 메스닐 지음 / 조건희 옮김

이연복 지음

w w w. h a n b i t . c o . k r

즐거운 상상이 가득! 2015년 화제의 신간

전자부품 백과사전 vol.1 찰스 플랫 지음 / 배지은 옮김 / 30,000원

취미공학에 필요한 핵심 전자부품을 사전식으로 정리한 안내서.

전자부품 백과사전 vol.1 찰스 플랫 지음 / 배지은 옮김 / 30,000원

처음 시작하는 센서

취미공학에 필요한 핵심 전자부품을 사전식으로 정리한 안내서.

전자부품 백과사전 vol.2

찰스 플랫 지음 / 가격미정

키모 카르비넨, 테로 카르비넨 지음 임지순 옮김 / 13,000원

세상을 수치로 읽어내는

<전자부품 백과사전> 시리즈의 두 번째 도서다.

부품인 센서를 알려주 는 책. 이 책을 통해 자신 만의 프로젝트에 다양한 처음 센서를 사용해보자.

Zero to Maker

: 누구나 메이커가 될 수 있다 데이비드 랭 지음 / 장재웅 옮김 / 14,000원

전자부품 백과사전 vol.2

찰스 플랫 지음 / 가격미정

일반인에서 메이커로. 날백수에서 무인 잠

<전자부품 백과사전> 시리즈의 수정 회사 CEO 가 된 사나이, 데이비드두 번째 도서다. 랭의 메이커 도전기.

Make: 센서

시작하는 센서

키모 카르비넨, 테로 카르비넨 지음 임지순 옮김 / 13,000원

세상을 수치로 읽어내는 부품인 센서를 알려주

키모 카르비넨, 테로 카르비 넨, 빌 발토카리 지음 는 책. 이 책을 통해 자신 / 가격미정

만의 프로젝트에 다양한

필수 전자부품인 센서를

센서를 사용해보자. 마이크로 컨트롤러 보드

Zero to Maker

: 누구나 메이커가 될 수 있다

에 응용하는 방법을 담

데이비드 랭 지음 / 장재웅 옮김 / 14 ,000원 Maker Pro

았다.

베이첼 지음 / 가격미정 일반인에서 메이커로.존날백수에서 무인 잠

메이커라면 반드시 읽어야 할 필수 계발

수정 회사 CEO가 된 사나이, 데이비드 서. 프로 메이커들과의 인터뷰 및 에세이 랭의 메이커 도전기. 수록.

프로젝트로 배우는 라즈베리 파이

도날드 노리스 지음 / 임지순 옮김

다양한 실전 프로젝트를 통해 라즈베리 파이를 쉽고 재미있게 배워본다.

Maker Pro 존 베이첼 지음 / 가격미정

메이커라면 반드시 읽어야 할 필수 계발

Make: 센서 키모 카르비넨, 테로 카르비 넨, 빌 발토카리 지음 / 가격미정

필수 전자부품인 센서를 마이크로 컨트롤러 보드 에 응용하는 방법을 담 았다.