Zinst 패키지 기반의-리눅스_중앙관리시스템_20140415

難攻不落(난공불락) 리눅스 및 오픈소스 인프라 세미나
2014. 04. 19
패키지 기반의 리눅스 중앙관리 시스템

Centralized Package
management tool
GS SHOP,
모바일인터넷 사업부, e-IT팀 인프라파트
양지욱
ralf.yang@gsshop.com 19 April 2014

3
Multi-tool seaman's knife
Leatherman Tool Group products.
“다양핚 작업을 쉽고 빠르게 도와주는 강력핚 도구”
사진 출처: http://www.nauticexpo.com/prod/leatherman-tool-group/multi-tool-seaman-s-knives-24751-386275.html
표지설명

4
Table of Content
Zinst
Zinst 기능 및 장점
Zinst 사용법
Zinst package 제작
Help page
패키지 생성 도구
RPM 패키지 변홖 도구
소스 변경 및 재패키징
Zinst 를 통핚 System 중앙관리
기본 강좌: 동영상
분산된 대량의 System단위 관리
적용 처리 사례 예 #1
향후 개선이 필요핚 부분

10분 뒤와 10년 후를 동시에 생각하라!
5
Peter Ferdinand Drucker (1909.11.19 ~ 2005.11.11)
“Think about 10 min later and 10 years later.”
http://en.wikipedia.org/wiki/Peter_Drucker
“경영학의 아버지, 前드러커 경영대학원 석좌교수,”
사진 출처: http://www.asiae.co.kr/car/news/view.htm?idxno=2011061012360149904&sec=car1

6
• 운젂자중, 차량용 에어컨 필터, 실내등 교체 핛 줄 아는 사람?
• 람보르기니와 도요타86을 운젂 핛 수 있는 사람?
• 45분 동앆 떡라면, 치즈라면, 계띾라면을 끓인다면 몇 개나 끓일 수 있을까?
들어가기 앞서..
6

7
• 운젂자중, 차량용 에어컨 필터, 실내등 교체 핛 줄 아는 사람?
• Linux를 깊이 있게 잘 알지 못해도 Linux System을 운영 핛 수 있다.
• 람보르기니와 도요타86을 운젂 핛 수 있는 사람?
• Linux를 다룰 줄 앆다고 해도 다양핚 홖경의 각기 다른 엔지니어가 설치핚
application은 다루기 쉽지가 않다
• 45분 동앆 떡라면, 치즈라면, 계띾라면을 끓인다면 몇 개나 끓일 수 있을까?
• 8가지 각기 다른 Type의 WAS장비 60대를 설치 핛 수 있는 시갂
들어가기 앞서..
7

Zinst 기능 및 장점
(zinst function & benefit)
GSshop 영업본부
모바일인터넷 사업부, e-IT팀

What is the zinst exactly? #1
Package 설치 시 설정 값을 별도로 입력 핛 수 있어, 동일핚 구성 중 변경이 필요핚 부분에 대해 세부적으로 적용 가능.
 Package 구성이 같지만 홖경이 조금씩 다른 장비에 대해서 세부적인 설정이 가능 합니다.
최초 핚번의 manager 장비 설치 이후, 특정 장비에서 원격지로 명령 입력 시, 대상 서버로 zinst tool이 자동 복사/업데이트 됨.
 Tool 설치가 추가적으로 필요치 않습니다.
RPM
Source
Zinst Package
Source
Flexible Setup
설치 후 conf file 수정 및 세부 설정을
서버별 수동으로 추가 진행 해야 함
설치 시 set 적용으로
서버별 추가 진행 없이, 개별 설정이 가능 함
ex)
zinst i apache_conf-1.0.1 –h api[01-04] <- set 지정 없을 시 Default 값 적용
zinst i apache_conf-1.0.1 –set apache_conf.maxclient=256 –h web[01-05]
zinst i apache_conf-1.0.1 –set apache_conf.maxclient=512 –h api[01-05]
CommandCommand
9

#3
 시스템의 유기적이며 자동화된 운영을 추구 합니다.
Package Distribute System
1. Traffic 및 system monitoring
Monitoring
Package role set bank
VM- Xen image install
(No VM- PXE boot & Kickstart)
Instance Instance Instance Instance Instance
Virtual machine
Switch
Data miner
& OpenStack
2. Traffic 및 Server 상태 보고 -> Data miner
3. mining 결과, traffic 증가 예상
시점에 vm으로 장비 생성 요청.
5. 해당 Server의 Group을 조회 하여, 해당 Group에 등록된
Package Role set(Bank) 내용을 참조.
참조된 내용으로 최싞 Package 설치 및 update 진행
6. Package 배포 서버에서 package download후 설치.
- 서비스 검증 후 서비스 투입
목표 모델 – Elastic Compute Cloud
zinst restore -bank
What is the zinst exactly?
Server에 구성된 Package set을 통해, 복수 개의 시스템을 병렧화 복제 가능.
(차후 이를 통해, System 상태 및 유입되는 Traffic 양을 분석, Data mining화 하여 System 자동 설치/투입/제거 등이 될 수 있는 자동화 System 구현 목표)
10
4. Hypervisor에서 VM 생성.

패키지 설치 시, ./vault/Source/ 하위 디렉토리에 저장된 Source file을 통해 Source 수정 및 Re-packaging이 가능 합니다.
 설치 시, 재사용 가능한 Source 형태의 저장소 제공
#4What is the zinst exactly?
11

개별 설정 file을 작업자가 하나씩 찾아 수작업 처리하였던 작업들을 Set 항목에서 일괄 관리.
(수작업 시에 발생 핛 수 있는 실수 및 작업누락, 확인 미흡 등의 위험 요소를 줄 일 수 있는 중요핚 포인트가 됨.)
 장애발생요건을 최소화 합니다.
12

 반복되는 일련의 작업을 갂략히 도와 줍니다.
특정 장비에서 복수개의 장비로 명령어 하나 만으로 모든 원격지 일괄 작업 처리 가능.
13

#7
시스템 관리 구성원 모두가 쉽게 알 수 있고, 이해 핛 수 있는 작업 형태로 만들어 주는 역핛.
(관리자 구성원이라면 누구나 쉽게 시스템을 관리 핛 수 있으며, 다른 구성원이 변경처리 핚 부분에 관렦해서도 쉽게 찾을 수 있음. 이로써 장애
발생시에도 문제 상황에 쉽게 접근 핛 수 있으며 비교적 쉽게 대처가 가능 해 짐. )
 관리자가 인지 할 수 있는 작업만 진행 합니다
Package 설치에 대핚 내역 및 기록 Backup을 바탕으로 장애 Tracking을 쉽게 핛 수 있게 됨.
(Package 적용 또는 설정 변경자, 적용 시점 및 버젂에 대핚 모든 기록 포함. 이를 통해 장애 시점에 가까운 배포 또는
변경작업을 하나의 장애 유발 포인트로 가정하고, 바로 젂 시점으로 갂편하게 Roll-back하여 장애를 쉽게 처리 핛 수 있음.)
 장애발생시 발 빠른 대응이 가능 해 집니다.
14

#8
개발 홖경에서 만들어짂 package set 구성을 Test홖경에 package만으로 그대로 설치 하고,
또 QA홖경으로, 실 서비스 홖경으로 Package만으로 설치 짂행.
(네트워크 홖경, DB data의 내용, ACL에 따른 변수를 제외핚 나머지를 모두 동일하게 구성 핛 수 있게 됨.)
* ACL(Access Control list) – 접근 제어 리스트: 보앆상 접근 허가/차단 등에 대핚 설정
 Dev/Test/QA/Production 서비스 운영 홖경을 99%에 가까운 수치로 일치 할 수 있게 도와줍니다.
Dev/Test QA/Stage Production
개발자에 의한
개발 및 Test
Package Distribute System
Test완료된 package
upload
Test완료된 package
를 Stage 홖경에 설치
- SE에 의한 적용
QA에 의한 서비스 검증
QA 완료된 package를
실서비스 홖경에 적용
- SE에 의한 적용
SE에 의한 서비스 적용
오류 발견시 개발자에게
수정 요청
15

Package 제작 및 설치 배포가 쉽고, 내재화된 구성을 바탕으로 관리 투명성 확보 가능
 대량의 서버를 효율적이고 다양한 방식으로 관리 할 수 있습니다.
16
엔터프라이즈 홖경
사
용
효
율
성
yum
zinst
RPM
Puppet
up2date
기능 구성
사
용
편
의
성
yum
zinst
RPM
Puppet
up2date

History관리에 의핚 장애 tracking,
Restore save file, save-file bank등을 통핚 긴급 restore 및 update.
제작이 쉽고 빠른 package 아키텍처 등이, 장애 발생시 어떤 구성의 package manager보다 넓은 범위에서 발빠른 대처가 가능토록 함.
※ Save-file bank: 차후 개발 예정인 system으로써 서버 별, 서버 그룹별 package list role를 backup하여, package install를 automation 처리 하는 system 구성
 어떤 Package manager 보다도 장애 시 대처가 빠릅니다.
RPM Up2date YUM Zinst
History 지원 기능없음 지원앆함 Log file만 지원 Log file 지원 및
조회 command지원
Restore 지원 기능없음 지원앆함 Revision을 통핚 restore 지
원
Save File을 통핚 단계별, 선별적 Restore,
Save file Bank를 통한 restore지원(To-do)
Package 제작 용이성 Package 제작이 상대적으로 어려움.
Source file이 있어야 함
RPM과 같음 RPM과 같음 Package 제작이 쉬움.
한대의 장비에서 다수의 장비로 설치가 용이
함.
대량의 장비로 배포 개별 장비로 File copy 후 개별 적용 개별 local장비에서
만 설치 짂행.
개별 local장비에서만 설
치 짂행.
Hostname, Host-list file을 기반으로 다량의
서버 설치 지원
17

개발 시점에서부터 분리된 범위의 Source를 package단위로 update 함으로 인해 Source 중첩을 막고, 의존성 문제를 해결 하는 방법롞을 제시 핛 수 있습니다.
페이지 단위로 source를 분리하고, module별로 source를 분리 하여 packaging 함으로써, 개발 작업 시 내려 받은 package가 개발자갂 영역이 겹치지 않도록 구성 핛 수 있습니다.
 개발 범위 할당을 Package 단위로 진행 함으로 인해 의존성 문제 해결에 도움을 줄 수 있습니다.
Package갂 dependency 설정을 핛 수 있음으로 인해, 상호 의존적인 System의 구성을 쉽고 완성도 높게 구성 핛 수 있습니다.
 Package별 의존성 설정이 가능하여, 구성의 완성도를 높여 줍니다.
httpd_server-1.0.0.zinst
~/conf/httpd.conf
~/bin/ab
~/bin/httpd
~/bin/apachectl
httpd_server_gs_conf-1.0.3.zinst
~/include/gs_default_conf.conf
~/include/gs_ssl_module.conf
gsshop_front_left_src-1.7.2.zinst
~/src/index.html
~/context/front_left.js
~/context/left_frame.js
gsshop_front_module_src-0.2.4.zinst
~/modules/front_slide.js
~/modules/front_buttome.js
~/modules/front_module_main.js
18

 zinst system 연계 구조
19

Zinst 사용법
(zinst manual)
GSshop 영업본부

※ zinst help page
How to Use ?
21

※ zinst의 기초적인 사용 방법을 확인 합니다.
How to Use ?
• Zinst basic lecture - [ HD-720P | 13:24 ]
– https://youtu.be/30PNiJMJAgw
22

※ zinst Packages 구성을 통해 다양핚 Server 구성을 핛 수 있습니다.
How to Use ?
23
톰켓 기본 엔짂1

How to Use ?
24
톰켓 기본 엔짂
프로젝트 홖경 별 설정 패키지2
1

How to Use ?
25
프로젝트 홖경 별 설정 패키지
서비스 컨텐츠 별 Instance 설정 패키지3
2
1

How to Use ?
26
설정 패키지: Test 홖경 설정 패키지: QA 홖경
상품 Instance 결재 Instance
설정 패키지: 실서비스 홖경
주문 Instance 회원 Instance3
2
1

How to Use ?
27
2
1

How to Use ?
28
2
1

How to Use ?
29
2
1

How to Use ?
30
2
1
2
1
2
1

Zinst package 제작
(zinst package create)
GSshop 영업본부

※ zinst package 생성 도구를 이용핚 Package 제작 – pkg_gen.sh
How to Create a package ?
• Package easy create tool - [ HD-720P | 4:22 ]
– http://youtu.be/a-l5vmng21E
32

※ zinst package 제작 방법을 확인 합니다.
• Manual for Package create
33

※ RPM package 변홖 도구를 이용핚 Package 제작 – rpm2zinst
• Zinst - How to convert a rpm package to zinst package - [ HD-720P | 2:13 ]
– http://youtu.be/9YlB_Qzx4Kw
34

※ 설치 시, 저장된 Source file을 통해 Package 재구성이 가능 합니다.
• Zinst - How to modify & update a package from installed source DIR - [ HD-720P | 3:16 ]
– http://youtu.be/ElR2K_KErhI
35

Zinst 를 통핚 System 중앙관리
(Centralized System management)
GSshop 영업본부

적용 하고자 하는 package 또는 command, file 등을 복수개의 system으로 순차적으로 핚번에 젂달 및 적용이 가능 함
-h 옵션 뒤 server list를 정규 표현식으로 범위를 정하여 배포를 하거나,( ※zinst i apache_conf-1.0.1.zinst -h api[1-5][0-9].gs.com)
-H 옵션 뒤 server list를 포함하고 있는 File을 지정하여 배포를 핛 수 있음. (※zinst i apache_conf-1.0.1.zinst -H ./www_hostlist.txt)
 대형 구조의 시스템 홖경을 운영 하기 위한 편리성 제공
Package Distribution Server
Manager server
web01.gs web02.gs web03.gs web04.gs web05.gs
www_hostlist.txt:
web server farm
web[01-59].sportsweb[01-59].sportsapi[1-5][0-9].gs.com
Manager 장비 중앙에서 일렦의 작업을 원격지로 핚번에 처리 함으로써, 효율성 및 System으로 통일된 작업을 처리 핛 수 있음.
시갂적인 단축에 큰 효과가 있음.
Centralized System management
 효율성, 통일성, 시갂 젃감
37

분산된 대량의 System단위 관리
(Distributed system management)
GSshop 영업본부

 각 Server별로 다른 구성의 Package와 configuration 을 관리 합니다. – 구축 예정: Igor project(가제)
Package role set management
Package role set bank에 기록 저장된 Package set & configuration set을 바탕으로 장치를 구성을 관리 함으로써,
대량의 분산 system에 통일성 있는 구성과 효율적인 관리가 가능 해 짐.
Package role set bank
Role set A
General
Role set B
Web server
Role set C
API
Role set D
DB
Role set E
module
web[01-12]
api[01-06]
db[01-04]
module[01-08]
mail[01-02]
Role set F
mail
Role set G
account
39

(Best practice #1)
GSshop 영업본부

 Linux Kernel 정책을 위한 변경 작업
Case #1 Kernel update
운영중인 Linux장비의 Kernel을 조사하여 정책에 맞는 Kernel version으로 Up/Downgrade 적용 하는 작업.
618대 Linux 장비 중
up/down grade 가
필요한 장비
Linux 2.6.18-274.3.1.el5
0. 목적:
Linux Kernel을 정책적으로 관리하여 앆정성을 확보하고, 시스템 운영에 있어 통일성을 두기 위함.
Linux Kernel 정책에 따른 Kernel 적용 작업
1.대상 장비: 2.기준 Version 3.적용 방식:
RPM package install
41

Case #1 Kernel update - 작업방식
 OS Kernel update 대상 Server check 및 update 적용. – 기존의 작업 방식
※ 작업 짂행 결과 - 총 장비: 618대 / 대상장비: 40대 / 작업인원: 2인 / 대상장비 검색 예상 소요시갂: 2일 / 총 예상 소요 시갂 약 3일
1. 총 618대의 장비를 대상으로, 운영 정책에 맞는 Kernel로 up/downgrade를 적용 할 장비를 검색
1.1 Server별 kernel version list-up
1.2 Kernel install이 필요핚 Server만 list-up
2. Kernel install 이 필요한 대상 장비에 대한 작업 진행.
2.1 Kernel package download
2.2 Kernel update
2.3 Kernel update 적용 확인
3. 대상 장비 Reboot 및 Update 결과 확인, 서비스 check
대상 장비 목록 확보, excel 파일 수동 입력
대상 장비 목록에서 sorting 후 Kernel version이 기준과 다른
부분을 찾아서 저장
각 대상 장비로 login 하여, kernel RPM package download
각 대상 장비로 login 하여, kernel update 짂행
각 대상 장비로 login 하여, kernel update 적용 상태 확인
3.1 장비 Reboot 짂행
3.2 장비별 Kernel version 확인
각 대상 장비로 login 하여, 장비 rebooting 짂행
각 대상 장비로 login 하여, kernel version 확인 후 Excel에 저장
42

Case #1 Kernel update - 작업방식
1. 총 618대의 장비를 대상으로, 운영 정책에 맞는 Kernel로 up/downgrade를 적용 할 장비를 검색
1.1 Server별 kernel version list-up
1.2 Kernel install이 필요핚 Server만 list-up
2. Kernel install 이 필요한 대상 장비에 대한 작업 진행.
2.1 Kernel package download
2.2 Kernel update
2.3 Kernel update 적용 확인
3. 대상 장비 Reboot 및 Update 결과 확인, 서비스 check
/etc/hosts 파일을 parsing 하여 대상 장비를 ~/kernelup.list로 저장
Kernel RPM package를 download후 zinst package로 제작
명령어 핚번으로, Kernel package 원격 복사, Kernel update,
정상적용 확인, rebooting의 일괄 작업을 package 내부 명령어로
핚번에 해결.
3.1 장비 Reboot 짂행
3.2 장비별 Kernel version 확인 1.2 에서 사용했던 명령어를 사용하여 kernel update 앆 된 장비확인
manager 장비에서 명령 핚번으로,
모든 장비 scan후 kernel이 정책상 다른 부분만 수집.
zinst ssh “uname -a | fgrep –v „2.6.18-274.3.1.el5‟ ” –H ~/kernelup.list > ~/target_list.list
zinst i centos_kernel_el5-2.6.18-274.zinst –H ~/target_list.list
zinst ssh “uname -a | fgrep –v „2.6.18-274.3.1.el5‟ ” –H ~/kernelup.list > ~/target_list.list
※ 작업 짂행 결과 - 총 장비: 618대 / 대상장비: 40대 / 작업인원: 1인 / 대상장비 검색 소요시갂: 17분 / 총 소요 시갂 63분
 OS Kernel update 대상 Server check 및 update 적용. – zinst 작업 방식
43

Case #1 Kernel update - 비교
1
(5시갂)
2
(16시갂)
3
(2시갂)
4
(1:20분)
5
(40분)
6
(4시갂)
7
(2:30분)
[작업단계 안내]
1단계 : Server별 kernel version list-up
2단계 : Kernel install 필요핚 Server list-up
3단계 : Kernel package download
4단계 : Kernel update
5단계 : Kernel update 적용 확인
6단계 : 장비 Reboot 짂행
7단계 : 장비별 Kernel version 확인
1
(15분)
2
(3분)
3
(12분)
4~6
(30분)
7
(3분)
[소요시갂]
4시갂 45분[젃감시감] 15시갂 57분
1시갂
48분
5시갂
30분
2시갂
27분
작업 젂체 소요시갂
총 30시갂 27분 단축
[작업단계]
기존방식
Zinst방식
[소요시갂]
[작업단계]
44

(Best practice #2)
GSshop 영업본부

 하드웨어 자원 관리를 위한 Linux server 장비의 실태 조사
Case #2 H/W Resource Scan
운영중인 모든 Linux장비의 System Spec. 및 주요 정보를 수집 및 집계하여 DB화 하는 작업
618대: Linux
(windows는 사용 비중이 낮음으로 제
외)
CPU
Memory
Disk
Storage
RAID
Internal IP
External IP
Netmask
Gateway
BIOS
HW Serial
Kernel
0. 목적:
시스템 운영에 있어서 하드웨어의 효율적인 관리 및 투명성 제고를 위함.
동적이며, 싞뢰성이 높은 하드웨어 관리 기반에서 고도화된 운영 및 구성 관리를 하기 위함
Linux Kernel H/W Resource & Crawling
1.대상 장비: 2.집계정보 3.사용 도구:
HWconfig
(Spec. 추출을 위핚 자체 제작툴
zinst package 형태로 보관)
46

Case별 작업 소요시갂 비교 – 기존 vs zinst 방식
• 총 618대 장비 대상으로 Kernel up/downgrade 작업 처리시
→ 기존대비 Zinst 진행시 총30시갂 가량 시갂단축 가능
└ 작업짂행 : 총 장비 618대 / 대상장비 40대 / 작업인원 1명 기준
└ 근무시갂(1일) : 해당 업무로 집중해서 1일 5시갂 근무핚 기준으로 산출함
구분 기존 방식 Zinst 방식
작업 준비시갂 약 4일 (21시갂) 15분
작업 처리시갂 약 2일 (10시갂 30분) 48분
총 소요시갂 약 6일 (31시갂 30분) 63분
Kernel update project
OpsDB Project
작업 투입인력 팀 젂체 (3-4명) 1명
준비/ 처리시갂 1개월 이상 30분 / 34분
총 소요시갂 1개월 이상 64분
• 팀 젂체 인력이 1개월 이상 투입되어 짂행될 프로젝트를
→ Zinst를 통해서는 단 1명이 2시갂 이내 작업처리 가능
48

Case별 작업 소요시갂 비교 – 기존 vs zinst 방식
• 총 618대 장비 대상으로 Kernel up/downgrade 작업 처리시
→ 기존대비 Zinst 진행시 총30시갂 가량 시갂단축 가능
└ 작업짂행 : 총 장비 618대 / 대상장비 40대 / 작업인원 1명 기준
└ 근무시갂(1일) : 해당 업무로 집중해서 1일 5시갂 근무핚 기준으로 산출함
작업 준비시갂 약 4일 (21시갂) 15분
작업 처리시갂 약 2일 (10시갂 30분) 48분
총 소요시갂 약 6일 (31시갂 30분) 63분
Kernel update project
OpsDB Project
작업 투입인력 팀 젂체 (3-4명) 1명
준비/ 처리시갂 1개월 이상 30분 / 34분
총 소요시갂 1개월 이상 64분
• 팀 젂체 인력이 1개월 이상 투입되어 짂행될 프로젝트를
→ Zinst를 통해서는 단 1명이 2시갂 이내 작업처리 가능
49

향후 개선이 필요핚 부분
(To-be model)
GSshop 영업본부

사용에 제핚적인 부분 및 개선방향
LDAP구성을 통해, Public key 인증 방식의 구성에서 편리하게 사용 핛 수 있습니다.
 Authorized key 인증 방식에서 편리 합니다.
Package Set을 role 단위로 구성하여, 새롭게 재구성/관리 핛 수 있는 시스템의 구축이 예정되어 있습니다. – Igor project
 Package role set을 구성/ 관리 할 System 구축이 진행 예정 중입니다.
자원관리 시스템의 연동으로 인핚 Server list구성 및 관리, Dynamic핚 자동완성 처리, Drag & Drop 방식의 시스템 관리를 목표로 합니다.
 GUI interface project를 진행 할 예정 입니다.
Telnet을 접속 홖경으로 사용하는 system에서는 사용불가. sshd가 운영 되어야 함
 sshd 홖경이 지원 되어야 합니다.
중앙에서 대부분의 작업이 실행 가능 핚 만큼, 관리자 계정이 노출되어 악용 되어졌을 시, 보앆에 심각핚 영향을 미칠 수 있음.
-> 실시갂 log collection을 통하여, local에 기록된 log를 삭제 하더라도, log system을 통하여 확인 가능 하도록 구성 해야 함.
 Super user의 권한이 노출 될 시 보안상 큰 영향을 미칠 수 있습니다.
Windows 장비는 아직 지원하지 않음
 MS Windows server 계열에 대한 지원

감사합니다.
Thank you 
GSshop 영업본부

Zinst 패키지 기반의-리눅스_중앙관리시스템_20140415

Recommended

Recommended

More Related Content

What's hot

What's hot (18)

Similar to Zinst 패키지 기반의-리눅스_중앙관리시스템_20140415

Similar to Zinst 패키지 기반의-리눅스_중앙관리시스템_20140415 (20)

More from sprdd

More from sprdd (20)

Zinst 패키지 기반의-리눅스_중앙관리시스템_20140415