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

難攻不落(난공불락) 리눅스 및 오픈소스 인프라 세미나

2014. 04. 19

패키지 기반의 리눅스 중앙관리 시스템

Centralized Package management tool

GS SHOP, 모바일인터넷 사업부, e-IT팀 인프라파트 양지욱 [email protected] 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

적용 처리 사례 예 #2

향후 개선이 필요핚 부분

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]

Command Command

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 형태의 저장소 제공

#4 What 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)


※ zinst help page

How to Use ?

21

※ zinst의 기초적인 사용 방법을 확인 합니다.

How to Use ?

• Zinst basic lecture - [ HD-720P | 13:24 ]

– https://youtu.be/30PNiJMJAgw

22

https://youtu.be/30PNiJMJAgw



※ 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 회원 Instance 3 2 1


How to Use ?

27







How to Use ?

28







How to Use ?

29







How to Use ?

30
















Zinst package 제작 (zinst package create)


※ 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

http://youtu.be/a-l5vmng21E





※ 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

http://youtu.be/9YlB_Qzx4Kw



※ 설치 시, 저장된 Source file을 통해 Package 재구성이 가능 합니다.


• Zinst - How to modify & update a package from installed source DIR - [ HD-720P | 3:16 ]

– http://youtu.be/ElR2K_KErhI

35

http://youtu.be/ElR2K_KErhI



Zinst 를 통핚 System 중앙관리 (Centralized System management)


적용 하고자 하는 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].sports web[01-59].sports api[1-5][0-9].gs.com

Manager 장비 중앙에서 일렦의 작업을 원격지로 핚번에 처리 함으로써, 효율성 및 System으로 통일된 작업을 처리 핛 수 있음. 시갂적인 단축에 큰 효과가 있음.

Centralized System management

효율성, 통일성, 시갂 젃감

37

분산된 대량의 System단위 관리 (Distributed system management)


각 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

적용 처리 사례 예 #1 (Best practice #1)


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

적용 처리 사례 예 #2 (Best practice #2)


하드웨어 자원 관리를 위한 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)


사용에 제핚적인 부분 및 개선방향

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 계열에 대한 지원

Question ?

감사합니다. Thank you


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

Documents