인프라의 규모가 커질 수록 서버 설치와 설정에 대한 부담이 늘어납니다. 특히 트래픽이 급격히 늘어나는 경우, 이에 빠르게 대처하여 서버를 구축하기 위해서는 자동화가 필수입니다. Saltstack은 이런 대규모 인프라를 관리하기 위한 자동화 관리 시스템입니다.  

장점

빠릅니다. server 와 agent 간 zeromq 를 통해 통신하는데, agent 요청에 대해 비동기 병렬로 처리 하기 때문에 agent가 많아져도 수 초안에 처리가 가능합니다. 1만대 이상 agent 에 명령을 보내고 응답 받는데 2초가 걸리지 않습니다.

구조가 심플합니다. Server-agent 기반의 매우 단순한 구조입니다. 서버의 경우 DB조차 사용하지 않습니다. (DB를 사용하고 싶은 경우 plug-in 구조로 DB를 사용할 수 있게 지원) 보통 이런 시스템을 도입하게 되면 시스템 자체의 운영에 대해 부담감이 있지만 구조가 단순하다면 이런 부담감도 크지 않아 도입하는데 무리가 없습니다.

많은 모듈 지원합니다. 인프라 환경 구성을 위한 거의 대부분의 작업을 지원하는 내장 모듈이 존재합니다. 그리고 이를 이용해 다수의 서버를 프로그래머블하게 제어하는게 가능합니다. (= Infrastructure as a Code )

구조

Salt-Master

Saltstack에서 Server 역할을 담당합니다. Master는 등록된 Minion 에게 명령을 publishing하고 그 결과를 취합하여 보여주는 역할을 합니다. 1대의 single master가 minion 수천대까지 관리가 가능합니다.

Salt-Minion

Agent의 역할이며, 구성 자동화를 하기 위한 대상 서버에 설치하면 됩니다. Master의 명령을 기다리고 있다가 명령이 오면 그에 맞춰 작업을 수행하게 됩니다. 만약, 서버에 minion을 설치하기 어려운 상황이라면 Ansible처럼 SSH로 명령 push가 가능하도록 지원합니다.

ZeroMQ

Salt-master와 Salt-minion 간 통신에 ZeroMQ라는 비동기 메시징 라이브러리를 사용합니다. 따로 설치해야 하는 것은 아니며 Salt-master를 설치하면 zeroMQ도 함께 설치됩니다. publish Port로 4505, Return Port 로 4506을 사용합니다. (포트 수정 가능)

Port 4505는 Publisher로서, 모든 salt-minion 들이 명령을 받기 위해 해당 포트를 listening합니다. salt-master는 이 포트를 통해 명령을 전달하며, 모든 minion은 비동기 형태(asynchronous) 로 동시에 명령을 받아 수행하게 됩니다.

Port 4506은 minion 들이 수행한 작업 결과를 받게 되는 역할로 사용됩니다. 그리고 결과 리턴 뿐만 아니라 minion이 master에게 파일을 요청하거나 minion의 특정 데이터 값(Salt pillar)을 요청하는 포트로도 사용됩니다.

특징 

Python 기반

  • Saltstack 자체가 Python 으로 개발되었으며, Saltstack에서 실행되는 모든 명령 실행 코드는 Python 기반의 Module / Function 으로 구현되어 있습니다. 만약 사용자가 원하는 custom module을 구현하고 싶다면 Python 으로 개발하면 됩니다. 근데 custom module 개발할 필요가 없을 정도로 내장 모듈이 많으며 강력합니다. 

YAML / Jinja2 포맷의 설정 파일

  • 자동화할 작업들을 명세하는 sls 파일들은 YAML 포맷을 기본으로 합니다. 또한 template 파일의 경우, 로직에 대한 처리는 Jinja2 template을 사용합니다. Jinja의 경우 기존에 Django나 Flask 같은 프레임워크에서도 많이 사용된 기술이기 때문에 어렵지 않게 사용이 가능합니다.

ZeroMQ 기반의 메시징 처리

AES 암호화 통신

  • salt-minion이 master에 처음 등록될 때 minion은 master에게 자신의 public key를 전달하게 됩니다. 그리고 master는 이 public key를 저장하고 해당 minion의 등록을 허락하는 절차를 거치게 됩니다. 이후 master와 minion은 ZeroMQ를 통해 통신할 때 public key와 AES key를 이용해 암호화 되어 통신하게 됩니다.


'서버' 카테고리의 다른 글

루프백 아이피  (0) 2017.03.08
Puppet, Chef, Ansible, Saltstack 비교  (0) 2017.02.18
Saltstack  (0) 2017.02.18
[Linux] sudo command not found 해결법 (Go 권한문제 해결법)  (0) 2017.02.02
[Linux] 디렉토리 구조  (0) 2017.01.28
HAProxy  (0) 2017.01.28

우분투에서 패키지를 설치하지 않고 압축을 풀어서 사용하면 로그인된 사용자에 맞게 설정할 시, 로그인된 사용자는 세팅한 명령어를 사용할 수 있지만 사용자 권한을 변경하면 해당 패키지를 찾지 못하여 에러가 발생합니다.

아래에서는 go라는 압축파일을 풀어 로그인된 사용자가 세팅한 다음, 루트계정으로 변환하여 해당 명령어를 실행하는 예제입니다.

예제

test$ tar -xcvf go1.7.1.linux-amd64.tar.gz # 패키지 압축해제
test$ sudo mv go /usr/local/ # /usr/local/ 폴더 하위로 압축파일 이동
test$ cd /home/test
test$ echo "export PATH=$PATH:/usr/local/go/bin" >> .bashrc # .bashrc파일에 go 패키지 등록
test$ source .bashrc # 적용
test$ go
# 정상적으로 적용
Go is a tool for managing Go source code.
Usage:
	go command [arguments]
The commands are:
 
....
 
test $ sudo su # root로 변경
root # go # 명령어 인식 못함
-bash: go: command not found


위와 같이 root 권한으로 실행하려고 할 때, 패키지를 못찾는 문제에 대해 해결하는 방법을 다음에서 설명합니다.

sudo su

test$ sudo su
root# cd ~root
root# echo "export PATH=$PATH:/usr/local/go/bin" >> .bashrc 
root# source .bashrc
root# go
# 정상적으로 적용
Go is a tool for managing Go source code.
Usage:
	go command [arguments]
The commands are:
 
....


sudo 명령어

위처럼 sudo su로 사용하는 것이 아닌 sudo go 처럼 권한만 가져와 실행한다고 하면 똑같은 에러가 발생합니다.

test$ sudo go
-bash: go: command not found


위와같은 문제를 해결하는 방법은 다음과 같이 두 가지가 존재합니다.

sudoers 파일 수정

test$ sudo vi /etc/sudoers
 
#
# This file MUST be edited with the 'visudo' command as root.
#
# Please consider adding local content in /etc/sudoers.d/ instead of
# directly modifying this file.
#
# See the man page for details on how to write a sudoers file.
#
Defaults        env_reset
Defaults        mail_badpass
Defaults        secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"  # <- 이 부분에 :/usr/local/go/bin과 같이 패키지 경로 추가
# Host alias specification
# User alias specification
# Cmnd alias specification
# User privilege specification
root    ALL=(ALL:ALL) ALL
# Members of the admin group may gain root privileges
%admin ALL=(ALL) ALL
# Allow members of group sudo to execute any command
%sudo   ALL=(ALL:ALL) ALL
# See sudoers(5) for more information on "#include" directives:
#includedir /etc/sudoers.d

:wq!로 강제저장한 다음 sudo go env를 사용하면 명령어가 먹히는 것을 볼 수 있습니다.

심볼릭 링크 생성

test$ sudo ln -s /usr/local/go/bin/go /usr/bin/go


위와같이 할 경우 sudo go를 사용할 수 있는 것을 확인할 수 있습니다.


여기서 PATH만 사용할 경우는 위와처럼 하면 되지만 go와 같이 GOPATH라는 특수한 환경변수도 공유하여 사용하고 싶은 경우 아래와 같이 .bashrc를 수정합니다.

test$ sudo vi .bashrc
 
.....
 
alias sudo ='sudo env GOPATH=$GOPATH' # 추가


위까지 할 경우 sudo go env의 내용과 사용자계정으로 세팅한 내용이 똑같은 것을 확인할 수 있습니다.

여기에서는 root계정에 직접 go 환경을 세팅하는 것과 sudo 권한에 심볼릭 링크 등을 걸어 사용자 환경과 동일시하게 하는 방법을 소개했지만 sudo go처럼 실행하는 방법을 지양하고 있습니다. (할 필요도 없다고..)


'서버' 카테고리의 다른 글

Puppet, Chef, Ansible, Saltstack 비교  (0) 2017.02.18
Saltstack  (0) 2017.02.18
[Linux] sudo command not found 해결법 (Go 권한문제 해결법)  (0) 2017.02.02
[Linux] 디렉토리 구조  (0) 2017.01.28
HAProxy  (0) 2017.01.28
Mesos  (0) 2017.01.28

리눅스의 디렉토리 혹은 파일 시스템 구조는 윈도우와는 조금 다른 구조를 가지고 있습니다. 기본적으로 디렉토리를 구분하는 '/'(슬래시)는 리눅스에서 사용하고 윈도우는 반대인 '\'(역슬래시)를 사용하죠. 디렉토리 또한 그 명칭을 리눅스에서는 디렉토리(directory), 윈도우에서는 폴더(folder)라고 불리웁니다.


리눅스 파일 시스템 구조

리눅스 시스템의 디렉토리 구조는 전체적으로 역 트리(tree) 구조를 하고 있습니다. 그리고 명령어의 종류와 성격, 사용권한등에 따라 각각의 디렉토리들로 구분됩니다. 리눅스 배포판들은 '리눅스 파일시스템 표준' 인 FSSTND(LINUX FILE System Standard) 라는 표준을 준수하므로 대부분의 리눅스 배포판들은 그 기본 골격이 같습니다.

/(루트)

최상의 디렉토리인 루트 디렉토리를 의미하며, 리눅스의 모든 디렉토리들의 시작점. 즉, 모든 디렉토리들을 절대경로로 표기할 때에 이 디렉토리로부터 시작해야 함.

/bin

기본적인 명령어가 저장된 디렉토리. 즉, 리눅스 시스템사용에 있어 가장 기본적이라고 할 수 있는 mv, cp, rm 등과 같은 명령어들이 이 디렉토리에 존재하며 root 사용자와 일반사용자가 함께 사용할 수 있는 명령어 디렉토리.

/boot

리눅스 부트로더(Boot Loader)가 존재하는 디렉토리. 즉, GRUB 과 같은 부트로더에 관한 파일들(grub.conf 등)이 이 디렉토리에 존재.

/dev

시스템 디바이스(device)파일을 저장하고 있는 디렉토리. 즉, 하드디스크 장치파일 /dev/sda, CD-ROM 장치파일 /dev/cdrom 등과 같은 장치파일들이 존재하는 디렉토리.

/etc

시스템의 거의 모든 설정파일이 존재하는 디렉토리. /etc/sysconfig(시스템 제어판용 설정파일), /etc/passwd(사용자관리 설정파일), /etc/named.conf(DNS 설정파일) 등과 같은 파일들이 존재.

/etc/mai/

sendmail.cf 나 access 파일등의 sendmail 의 설정파일들이 존재하는 디렉토리.

/etc/ssh/

SSH 서비스, 즉 sshd 데몬에서 사용하는 각종 설정파일들이 존재하는 디렉토리.

/etc/squid/

squid 프락시서버의 설정파일들이 저장된 디렉토리.

/etc/samba/

삼바관련 설정파일들이 저장된 디렉토리

/etc/skel/

계정사용자 생성시의 초기화파일들이 저장된 디렉토리(useradd 에서 사용함)

/etc/rc.d/

부팅레벨별 부팅스크립트파일들이 존재하는 디렉토리.

/etc/rc.d/init.d/

시스템 초기화 파일들의 실제파일들이 존재함.

/etc/pam.d/

PAM 설정 정보파일들이 저장된 디렉토리.

/etc/httpd/

RPM 으로 설치된 아파치 설정파일(httpd.conf 등)들이 저장된 디렉토리.

/etc/cron.d/, /etc/cron.daily/, /etc/cron.hourly/, /etc/cron.monthly/, /etc/cron.weekly/

모두 크론설정파일이 존재하는 디렉토리임.

/etc/xinetd.d/

xinetd 수퍼데몬에 의해 서비스되는 서비스설정파일이 존재함.

/home

사용자의 홈디렉토리, useradd 명령어로 새로운 사용자를 생성하면 대부분 사용자의 ID와 동일한 이름의 디렉토리가 자동으로 생성됨.

/lib

커널모듈파일과 라이브러리파일 즉, 커널이 필요로하는 커널모듈파일들과 프로그램(C, C++ 등)에 필요한 각종 라이브러리 파일들이 존재하는 디렉토리.

/media

DVD, CD-ROM, USB 등과 같은 탈부착이 가능한 장치들의 마운트포인트로 사용되는 디렉토리.

/mnt

/media 디렉토리와 비슷한 용도로 탈부착이 가능한 장치들에 대하여 일시적인 마운트포인트로 사용하는 디렉토리.

/proc

일명 "가상파일시스템" 이라고 하는 곳으로 현재 메모리에 존재하는 모든 작업들이 파일형태로 존재하는 곳. 디스크상에 실제 존재하는 것이 아니라 메모리상에 존재하기 때문에 가상파일시스템이라고 부름. 실제 운용상태를 정확하게 파악할 수 있는 중요한 정보를 제공하며 여기에 존재하는 파일들 가운데 현재 실행중인 커널(kernel)의 옵션 값을 즉시 변경할 수 있는 파라미터파일들이 있기 때문에 시스템 운용에 있어 매우 중요한 의미를 가짐.

/root

시스템 최고관리자인 root 사용자의 개인 홈디렉토리.

/sbin

ifconfig, e2fsck, ethtool, halt 등과 같이 주로 시스템 관리자들이 사용하는 시스템관리자용 명령어를 저장하고 있는 디렉토리.

/tmp

일명 "공용디렉토리" . 시스템을 사용하는 모든 사용자들이 공동으로 사용하는 디렉토리. mysql 에서 사용하는 mysql.sock 등과 같은 소켓파일, 또는 아파치에서 사용하는 세션파일등이 생성되기도 한다. 웹해킹에 사용되기도 해서 주의를 요망.

/usr

시스템이 아닌 일반사용자들이 주로 사용하는 디렉토리. 즉, c++, chsh, cpp, crontab, du, find등과 같이 일반사용자들용 명령어들은 /usr/bin 에 위치.

/usr/bin/

일반 사용자들이 사용가능한 명령어 파일들이 존재하는 디렉토리.

/usr/X11R6/

X 윈도우 시스템의 루트 디렉토리.

/usr/include/

C 프로그램에 필요한 헤드파일(*.h) 디렉토리.

/usr/lib/

/lib 에 들어가지 않은 라이브러리 디렉토리.

/usr/sbin/

/bin 에 제외된 명령어와 네트워크관련 명령어가 들어있는 디렉토리.

/usr/src/

프로그램 소스(주로 커널소스)가 저장되는 디렉토리.

/usr/local/

MySQL, Apache, PHP 등과 같은 어플리케이션들을 소스로 컨파일설치할 때 사용되는 장소.

/usr/share/man/

명령어들의 도움말을 주는 메뉴얼(manual)페이지 디렉토리. 즉, 이 디렉토리에는 시스템에서 사용하는 모든 맨페이지파일(man page)이 존재함.

/var

시스템운용중에 생성되었다가 삭제되는 데이터를 일시적으로 저장하기 위한 디렉토리. 거의 모든 시스템로그파일은 /var/log 에 저장되고, DNS 의 zone 설정파일은 /var/named 에 저장되고, 메일파일은 /var/spool/mail 에 저장되며, 크론설정파일은 /var/spool/cron 디렉토리에 각각 저장됨.

/var/tmp/

/tmp 디렉토리와 같은 공용디렉토리. 즉, /tmp 디렉토리와 /var/tmp 디렉토리의 퍼미션은 1777 로서 sticky bit 가 설정되어 있는 공용디렉토리. 리눅스 시스템에서 공용디렉토리는 /tmp 와 /var/tmp 둘뿐.

/var/log/

시스템로그파일(messages, secure, xferlog 파일등)이 저장되는 디렉토리.

/var/ftp/

vsftp 등과 같은 FTP 서비스를 위한 다운로드될 파일들 즉, FTP 홈디렉토리.

/var/named/

BIND 즉, DNS 에서 사용하는 zone 파일들이 저장되는 디렉토리.

/var/spool/mail/

각 계정사용자들의 메일파일이 저장되는 디렉토리.

/var/spool/lpd/

프린트를 하기 위한 임시 디렉토리(스풀링 디렉토리).

/var/spool/mqueue/

발송을 위한 메일 일시저장 디렉토리.

/var/spool/cron/

각 사용자들의 cron 설정파일들이 저장된 디렉토리.

/var/spool/at/

atd 즉, 예약작업에 관한 파일들이 저장되는 디렉토리.

/lost+found

최상위 디렉토리인 / 디렉토리에만 존재하는 것이 아니라 파일시스템마다 존재할 수 있는 디렉토리. 이 디렉토리는 fsck 또는 e2fsck 등과 같은 파일시스템 체크 및 복구유틸리티 실행후에 주로 생성이 되는 것으로서 복구되지 않은 채로 블록(block)만 존재하는 파일 즉, 연결이 끊어진 inode 들이 숫자파일형태로 존재하는 곳임. 숫자형태로 존재하는 파일들은 mv 명령어로 파일이름만 바꾸면 바로 복구될 수 있음.

'서버' 카테고리의 다른 글

Saltstack  (0) 2017.02.18
[Linux] sudo command not found 해결법 (Go 권한문제 해결법)  (0) 2017.02.02
[Linux] 디렉토리 구조  (0) 2017.01.28
HAProxy  (0) 2017.01.28
Mesos  (0) 2017.01.28
OpenStack Swift  (0) 2017.01.26

HAProxy란?

HAProxy는 기존의 하드웨어 스위치를 대체하는 소프트웨어 로드 밸런서로, 네트워크 스위치에서 제공하는 L4, L7 기능 및 로드 밸런서 기능을 제공합니다. HAProxy는 설치가 쉽고 또한 환경 설정도 어렵지 않으므로 서비스 이중화를 빠르게 구성하고 싶다면 HAProxy를 추천합니다.

로드 밸런싱이란?

로드 밸런싱이란 부하 분산을 위해서 가상(virtual) IP를 통해 여러 서버에 접속하도록 분배하는 기능을 말합니다. 로드 밸런싱에서 사용하는 주요 기술은 다음과 같습니다.

  • NAT(Network Address Translation): 사설 IP 주소를 공인 IP 주소로 바꾸는 데 사용하는 통신망의 주소 변조기.
  • DSR(Dynamic Source Routing protocol): 로드 밸런서 사용 시 서버에서 클라이언트로 되돌아가는 경우 목적지 주소를 스위치의 IP 주소가 아닌 클라이언트의 IP 주소로 전달해서 네트워크 스위치를 거치지 않고 바로 클라이언트를 찾아가는 개념.
  • Tunneling: 인터넷상에서 눈에 보이지 않는 통로를 만들어 통신할 수 있게 하는 개념으로, 데이터를 캡슐화해서 연결된 상호 간에만 캡슐화된 패킷을 구별해 캡슐화를 해제할 수 있음.

로드 밸런서 동작 방식

로드 밸런서의 동작을 간단하게 설명하면, 네트워크에서 IP 주소와 MAC 주소를 이용해 목적지(destination) IP 주소를 찾아가고 출발지로 되돌아오는 구조입니다. 이 글에서는 4가지의 로드 밸런서 동작 방식을 설명하겠습니다.

Bridge/Transparent Mode

사용자가 서비스를 요청하면 L4로 전달된 목적지 IP 주소를 real server IP 주소로 변조하고 MAC 주소를 변조해서 목적지를 찾아가는 방식.

  1. 요청 전달 시 변조 
    - 사용자 > L4 > NAT(IP/MAC 주소 변조) > real server - 사용자가 L4를 호출하면 중간에 NAT가 목적지 IP 주소를 real server IP 주소로 변조하고 MAC 주소도 변조.
  2. 응답 전달 시 변조 
    - real server > NAT > L4 > 사용자 - real server에서 L4를 거치면서 출발지(source) IP 주소를 L4 가상 IP 주소로 변조. 동일 네트워크 대역이므로 MAC 주소는 변조하지 않음.

Router Mode

Bridge/Transparent Mode와 유사하지만 출발지(source) MAC 주소도 변조.

One Arm Mode

사용자가 real server에 접근할 때 목적지 IP는 L4 스위치 IP를 바라봄. L4에 도달하면 L4가 클라이언트에게 받은 목적지 IP 주소를 L4 IP 주소에서 real server IP와 real server MAC 주소로 변조. 되돌아가는 IP는 L4의 IP pool의 IP 주소로 변조.

DSR (Direct Server Return) Mode

사용자가 real server에 접근할 때 출발지와 목적지의 IP 주소를 변조하지 않고, L4에서 관리하는 real server의 MAC 주소 테이블을 확인해서 MAC 주소만 변조.

HAProxy 동작 방식

HAProxy는 기본적으로 reverse proxy 형태로 동작합니다. 우리가 브라우저에서 사용하는 proxy는 클라이언트 앞에서 처리하는 기능으로, forward proxy라 합니다. reverse proxy의 역할을 간단히 설명하면, 실제 서버 요청에 대해서 서버 앞 단에 존재하면서, 서버로 들어오는 요청을 대신 받아서 서버에 전달하고 요청한 곳에 그 결과를 다시 전달하는 것입니다.


HAProxy의 동작 흐름은 다음과 같습니다.

  1. 최초 접근 시 서버에 요청 전달
  2. 응답 시 쿠키(cookie)에 서버 정보 추가 후 반환
  3. 재요청 시 proxy에서 쿠키 정보 확인 > 최초 요청 서버로 전달
  4. 다시 접근 시 쿠키 추가 없이 전달 > 클라이언트에 쿠키 정보가 계속 존재함(쿠키 재사용)

HAProxy HA(High availability) 구성

HAProxy는 기본적으로 VRRP(Virtual Router Redundancy Protocol)를 지원합니다. HAProxy의 성능상 초당 8만 건 정도의 연결을 처리해도 크게 무리가 없지만, 소프트웨어 기반의 솔루션이기 때문에 HAProxy가 설치된 서버에서 문제가 발생하면 하드웨어 L4보다는 불안정할 수 있습니다. 따라서 HA 구성으로 master HAProxy에 문제가 생기는 경우에도 slave HAProxy에서 서비스가 원활하게 제공될 수 있는 구성을 알아보겠습니다.

다음 그림과 같은 구성에서는 가상 IP 주소를 공유하는 active HAProxy 서버와 standby HAProxy 서버가 heartbeat를 주고 받으면서 서로 정상적으로 동작하는지 여부를 확인합니다. active 상태의 서버에 문제가 발생하면 standby HAProxy가 active 상태로 변경되면서 기존 active HAProxy의 가상 IP 주소를 가져오면서 서비스가 무정지 상태를 유지합니다. 다만 1초 정도의 순단 현상은 발생할 수 있습니다.

HA로 설정된 HAProxy의 동작 흐름이 단일 HAProxy와 다른 점은 최초 접근 시 쿠키에 바로 서버 정보를 입력하지 않고 서버에서 jsessionid가 전달될 때 서버 정보를 합쳐서 전달한다는 것입니다.

  1. 쿠키에 정보 추가 없고 X-Forwarded-For에 정보 추가
  2. 쿠키에 추가 없음
  3. Jsessionid 추가
  4. 서버 정보 + jsessionid를 쿠키에 추가
  5. 쿠키에서 서버 판별 후 jsessionid만 전달

L4 + HAProxy HA 구성 및 Global 환경에서 구성

HAProxy와 기존 하드웨어 스위치를 이용해서 더 확장된 형태의 고가용성 구조를 설계할 수가 있습니다. 다음과 같은 형태의 구성도 가능합니다.

하드웨어 L4 + HAProxy

클라이언트에서 연결되는 부분은 가상 IP 주소 + L4의 구성으로 하드웨어 이중화를 구축하고, L4에서 서버 앞 단에 HAProxy를 구축해서 HAProxy를 더 확장할 수 있는 구조로 설계할 수 있습니다.

GSLB(Global Service Load Balancing) + HAProxy

global 서비스가 증가되면서 IDC 간 이중화 및 global 환경에서의 무정지 서비스를 위한 DR(Disaster Recovery, 재해 복구) 시스템 구축이 필수 요구사항이 되었습니다. GSLB + HAProxy를 이용하면 global한 무정지 서비스 구축이 가능합니다. GSLB 구축에 L4 스위치를 사용할 수도 있지만 GSLB 구성용 L4는 고가의 장비입니다. 따라서 L4를 이용한 GSLB 대신 DNS(BIND)를 이용한 구축 형태는 다음과 같습니다.

  1. 클라이언트에서 DNS로 도메인 조회
  2. 근거리 IDC 정보 전달

'서버' 카테고리의 다른 글

[Linux] sudo command not found 해결법 (Go 권한문제 해결법)  (0) 2017.02.02
[Linux] 디렉토리 구조  (0) 2017.01.28
HAProxy  (0) 2017.01.28
Mesos  (0) 2017.01.28
OpenStack Swift  (0) 2017.01.26
블록 스토리지와 오브젝트 스토리지  (0) 2017.01.23


Mesos란?

UC Berkeley에서 Nexus라는 이름으로 개발이 진행되던 프로젝트이고, Mesos라는 이름으로 Apache재단에서 오픈소스로 발표하였습니다. Cloud Infrastructure 및 Computing Engine들의 자원을 통합적으로 관리할 수 있도록 만든 자원관리 프로젝트입니다. Mesos는 분산 시스템 커널(distributed systems kernel)입니다. 뭔가 굉장히 복잡해 보이지만, 기본 개념은 간단합니다. 네트워크로 묶여 있는 여러 개의 컴퓨터의 자원 즉, CPU, 메모리, 디스크 등의 자원을 하나로 묶어서 resource pool로 만들어서 마치 하나의 컴퓨터 처럼 보이게 하겠다는 겁니다. 그리고 커널로서 작동하기 위한 기능인 스케쥴러와 애플리케이션 관리 기능을 더해서, 분산 커널을 만듭니다. 이제 유저가 애플리케이션 실행을 요청하면, 자원이 넉넉한 인스턴스를 할당하고 애플리케이션을 실행 하면 됩니다. 

Architecture

아래의 그림은 Mesos 아키텍쳐입니다. 마스터는 Active/Standby 구조로 되어있으며 Zookeeper를 통해서 Master Failover를 자동으로 관리해줍니다. Active Master 서버가 문제가 발생하면 Zookeeper를 통해 Standby를 Leader로 승격시켜 Active상태로 만들어줍니다. 그리고 어플리케이션을 실행하면 마스터가 정보를 받아 리소스(CPU, Memory, Disk)가 남아있는 Slave 서버에서 어플리케이션을 실행시켜 줍니다.

자원할당

Mesos는 각 Slave서버들의 자원을 Master에게 전달하게 되어있습니다. Mesos는 Framework라는 개념이 있는데 대표적인 Framework는 marathon과 chronos가 있습니다. Marathon는 자원할당과 Job을 만드는 Framework이고, Chronos는 스케쥴 Framework입니다. Marathon 을 통해 등록된 어플리케이션은 Master에게 전달된 Slave의 자원을 확인하여 리소스가 넉넉한 slave에서 어플리케이션을 실행하게 됩니다.

Mesos Master UI

아래는 Mesos Master UI입니다. 아래의 그림처럼 현재 실행중인 Task와 완료된 Task 그리고 어느 서버에서 실행되고, 성공/실패한 내용을 자세히 확인할 수 있습니다.


Mesos Cluster에서 총 CPU, Memory, Disk 사이즈와 사용중인 리소스, 사용가능한 리소스를 확인할 수 있습니다.



Slave Detail 정보를 표시한 UI입니다. 현재 실행중인 Task의 CPU/Memory/Disk 사용량을 실시간으로 확인이 가능합니다. 실제로 nginx에 부하를 주었을때 CPU와 메모리 사용량이 변하는걸 확인할 수 있습니다.

Marathon

Marathon UI입니다. 아래의 그림처럼 Marathon에서 실제로 어플리케이션을 실행 시킬 수 있으며, 실행시킨 어플리케이션의 정보를 확인할 수 있습니다. 어플리케이션이 실행되고있는 Mesos Slave서버가 장애가 발생하면 다른 Mesos Slave서버로 어플리케이션을 실행시켜줍니다.

Chronos

Chronos 는 distribute job scheduler 이고, 아래의 그림은 WEB UI 입니다.

'서버' 카테고리의 다른 글

[Linux] 디렉토리 구조  (0) 2017.01.28
HAProxy  (0) 2017.01.28
Mesos  (0) 2017.01.28
OpenStack Swift  (0) 2017.01.26
블록 스토리지와 오브젝트 스토리지  (0) 2017.01.23
[Linux] sudo 명령어 실행시 PATH 연결이 안될 때 해결 방법  (0) 2017.01.17

OpenStack Swift는 Object Storage 중 하나이며 Open Source Project입니다. 분산 구조의 Object 데이터의 저장 스토리지 체계로서 가장 많이 사용되는 Open Source Project가 바로 OpenStack Swift입니다. Object Storage가 비록 빠른 성능을 요구하는 경우에 쓰이기에는 부적절하지만 안정적이면서도 대용량의 저장공간이 필요할 때 사용하기 적절한 스토리지입니다. 

개요

OpenStack Swift는 OpenStack의 Object Storage 서비스를 위한 구성요소로 개발되어 최근 다양한 클라우드 서비스의 Object Storage 인프라로 가장 많이 사용되는 Open Source Project입니다. OpenStack Swift는 동영상, 이미지, 디스크 이미지 등의 대용량, 비정형 데이터를 저장하기에 적합한 스토리지로 데이터를 파일과 메타데이터로 저장하며 각각의 파일을 복제 방식을 이용해 분산 관리하고 계정마다 저장공간을 분리하지 않고 하나로 사용하여 공간을 최대한으로 활용하는 분산형 Object Storage입니다. Object Storage는 편리한 확장성을 제공하지만 Block Storage, File Storage에 비해서 성능이 떨어져 변경이 빈번한 파일에 부적합하며 비정형/대용량 데이터 관리에 적합니다. 파일의 관리는 Account 별로 관리되는 Container 내에 Object로 관리되며 파일 관리의 편리성을 위해 Pseudo Folder 기능도 제공합니다.

Swift 장점

  • 동영상, 이미지, 디스크 이미지 등의 대용량, 비정형 데이터를 저장하기에 적합
  • 각각 Object 들은 고유한 URL을 갖고 API로 제어(외부 어플리케이션, 웹 등에서 동시에 접근 가능)
  • 멀티 테넌트로 구현이 가능하며 저장 공간에 제약이 없음(계정마다 저장공간을 할당받는 것이 아닌 모든 공간을 같이 사용)
  • 페타규모의 클러스터로 확장 가능하며 확장시에도 downtime없이 간단하게 확장 가능
  • 복제본은 격리된 환경(zone)으로 관리하여 안전하게 보관
  • 비공유 구조(shared-nothing)으로 단일 장애점이 없기 때문에 가용성이 높음
  • open source를 사용하여 적은 비용에 구축 가능

Swift API

Swift는 OpenStack의 통합 Console을 이용해 기본적인 Object 저장 및 다운로드 등의 기능을 이용할 수 있습니다. 하지만 OpneStack이 없는 상태로 Swift만 단독으로 사용하여 사용자가 원하는 기능을 구현하거나 또는 별도의 UI를 만들기 위해서는 Swift API를 이용해야 합니다. Swift는 API를 통해 Object를 관리할 수 있도록 다양한 기능을 제공하며 개발자의 편의를 위해 다양한 형태의 API를 제공합니다. Swift API는 기본적으로 REST API입니다. 이 REST API를 이용해 개발자의 편의를 위해 동일한 기능을 Java, PHP, C 등을 사용해 구현이 가능하도록 하는 것입니다. 또 OpenStack은 Python을 이용해 만들어진 프로젝트로 Python을 이용하면 더 많은 기능을 이용할 수도 있습니다. 그리고 Swift는 CLI도 별도로 제공하기 때문에 개발자의 환경 또는 개발 기능의 목적에 따라 다양한 형태의 API를 사용할 수 있습니다. 

REST API 등을 사용하여 Object를 관리하기 위해서는 먼저 사용자 인증을 받아야 합니다. 일반적으로 OpenStack의 KeyStone Auth를 사용해 Token을 받습니다. 그리고 이 Token을 이용해 Object Storage의 데이터를 관리하게 됩니다. API 요청을 받아들이고 이를 처리하는 역할은 Proxy Server가 담당하며 요청의 종류에 따라 실제 데이터의 처리를 어디서 수행하게 될지를 결정합니다.

API 기능

 

Swift는 OpenStack의 API를 기본적으로 사용합니다. OpenStack API는 각각의 구성요소에 따라 서로 다른 API를 제공하는데 Swift 사용을 위해서는 크게 2가지, 즉 Identity API와 Object Storage API를 사용하게 됩니다. 제공되는 기능은 Account 및 User 관리 기능 및 Token 처리, Account Server의 데이터 관리, Container Server의 데이터 관리, 그리고 데이터의 본체인 Object에 대한 관리 기능을 제공합니다. 기본적으로 RESTful API이며 API를 적절하게 잘 사용하면 단순한 데이터 관리 기능 이외에 ACL, Large Object, Versioning 등의 고급 기능도 사용할 수 있습니다.

 

OpenStack Swift Architecture

OpenStack Swift는 인터넷을 기반으로 서비스를 제공하는 객체 기반 스토리지입니다. 따라서 HTTP를 통한 요청을 처리해야 하고 이에 따르는 적절한 처리를 수행할 수 있어야 합니다. 

서비스 모델로서의 아키텍처를 살펴보면 사용자의 요청은 로드밸런서를 통해 Proxy Server에 전달됩니다. 이 때 원활한 요청의 처리를 위해 여러 대의 Proxy Server를 둘 수 있습니다. 요청이 오면 해당 요청이 Account에 대한 요청인지, 또는 Container, Object에 대한 요청인지를 확인하고 이에 대한 데이터가 어디에 있는지 확인하기 위해 Ring이라는 일종의 주소록을 참조해서 주소값을 얻어와서 데이터를 처리하게 됩니다. Proxy Server의 증설은 요청 처리 용량의 증설을 의미하고 각각의 Zone 내에 있는 서버의 증설은 Storage 용량의 증설을 의미합니다.

Proxy Server

키텍처의 주요 구성요소에 대해 하나씩 알아보도록 하겠습니다. 먼저 사용자의 요청에 따라 알맞은 서버에 연결하여 서비스를 제공하는 역할을 담당하는 Proxy Server입니다. Proxy Server는 Swift의 모든 요청을 Ring을 참고하여 적합한 서버에 처리를 분산하는 역할을 합니다. Proxy Server는 요청을 처리하는 서버로의 역할을 위해 인증관리, 상태 점검, 속도 향상을 위한 캐쉬 관리, 요청관리 등을 위한 다양한 데몬과 미들웨어를 가지고 있습니다. 그리고 분산 서버들의 정보를 가지고 있는 Ring이 있는데 이 Ring을 이용해 실제 요청을 처리할 서버와 스토리지 디바이스를 찾게 됩니다.

Ring의 구조

Ring은 데이터가 저장될 논리적 위치와 물리적인 저장 위치 간의 매핑을 제공하는 정보로서 전화번호부 또는 주소록과 비슷한 역할을 합니다. 전화번호부가 시시각각 변하지 않는 책이듯, Ring도 동적으로 변하는 것이 아니라 스토리지를 구성할 때 미리 만들어 놓고 사용하는 정보입니다.

 

Ring은 Proxy Server 및 각각의 개체에 대한 Ring이 별도로 존재하며 Account에 대한 처리는 Proxy Server를 거쳐 Account Ring이 최종적인 처리를 담당하게 되며 각각의 Ring은 관리자가 직접 생성 작업을 수행해 두어야 합니다. Ring은 Account, Container, Object별로 존재하지만 Ring의 데이터 구조는 동일합니다. Account, Container는 Database로 정보를 관리하지만 일종의 파일구조이기 때문에 Object와 별도의 구성을 할 필요는 없는거죠. Ring은 크게 Device 목록과 Partition 목록, 그리고 모듈로 연산을 위한 Partition Shift 값으로 이루어집니다.

Ring의 동작

 Ring은 Request API가 호출되면 해당 Request의 정보를 Hash > 변환 > 시프트연산을 거쳐 만들어진 Partition 번호 값을 이용해 API가 원하는 개체에 대한 작업을 수행할 수 있도록 동작합니다.

Ring의 동작 단계는 크게 “사용자 요청” > “저장 디바이스의 탐색” > “파일 저장”으로 이루어집니다. 사용자의 요청단계에서는 전달된 요청을 통해 어떤 개체에 대한 요청인지를 파악합니다. 그리고 각각의 Path 정보에 따라 각각의 Controller에 전달합니다. 저장 디바이스 탐색의 단계에서는 요청 정보를 MD5 Hash로 만들고 난 다음, Hash 값을 숫자로 변환한 후 Shift 연산을 통해 파티션 크기에 맞게 Modulation을 하여 일정 범위 내의 값을 생성합니다. 생성된 값은 파티션의 번호입니다. 이 번호를 이용해 Ring을 조회합니다. 예를 들어 31685번 파티션이 저장될 위치를 Ring을 통해 찾는 것입니다. 마지막으로 파일을 저장하는 단계에서 Ring을 통해 찾은 디바이스에 파일을 저장하게 되는데 저장 시에는 원본 파일과 함께 복제 규칙에 따라 디바이스가 중복되지 않고 Zone이 분리되는 기본적인 규칙에 따라 복사본도 함께 저장됩니다.

 

 

Account Server

Account Server도 계정 정보 및 사용자 정보를 관리하고 각각의 계정별 컨테이너 정보를 관리하기 위해 다양한 데몬을 가지고 있습니다. 또한 계정정보 및 계정의 컨테이너 기록을 위해 별도의 저장공간으로 Database를 포함하고 있습니다.

Container Server

Container Server는 사용자 계정의 컨테이너를 관리하는 서버로 계정 하의 컨테이너들을 관리하며 컨테이너가 가지고 있는 Object들의 정보를 관리하는 역할을 합니다. 다른 서버들과 마찬가지로 서비스를 제공하기 위해 다양한 데몬을 포함하고 있으며 컨테이너 정보 및 컨테이너의 Object를 기록하고 관리하기 위해 별도의 Container DB를 가지고 있습니다.

 

Object Server

실제 데이터를 저장하고 있는 Object Server 입니다. Object Server는 실질적인 데이터를 Object로 관리/저장하고 이를 조회할 수 있는 기능을 제공합니다. 역시 서비스를 제공하기 위한 데몬과 실질적인 Object로 이루어져 있는 것을 볼 수 있습니다.

기타 데몬

마지막으로 앞서 설명한 Core Component에서 실행되는 주요한 데몬들에 대해 알아볼 수 있도록 하겠습니다.

 

각각의 서버에는 다양한 데몬들이 실행되는데 그 중 가장 대표적인 데몬이 Replicator입니다. 말 그대로 복제를 담당하는 데몬입니다. Object의 유실을 방지하기 위해 Swift는 기본적으로 3개의 Replica를 만듭니다. 이 복제본은 각각의 Zone과 서로 다른 Device에 나누어 저장되며 데이터가 잘못 되었을 경우 이 Replicator에 의해 복구되는 프로세스가 실행됩니다. 그 외에 여러가지 복제 및 복구에 관련된 일을 수행하는 데몬이 바로 Replicator입니다.

 

두번째로 Updater라는 데몬입니다. 이 데몬은 Object의 Update가 정상적으로 이루어질 수 있도록 도와주는 역할을 합니다. 특히 Object의 변경이 High Load 상태로 인해 지연되는 경우 이를 지속적으로 수행할 수 있도록 해주고 더불어 Object 변경에 따른 정보의 변경 처리도 담당하게 됩니다.

 

세번째 데몬은 Auditor입니다. Object, Container, Account들의 무결정을 검사하는 데몬으로 이상이 발생하면 이상이 발생한 파일을 격리하고 Replicator를 이용해 복제본을 사용하여 파일을 대체하는 등의 일을 수행합니다.

 

네번째 데몬은 Object-Expirer로서 Object가 일정한 시간 내에 삭제되어야 하는 등의 생명주기 관리 설정이 되어 있는 경우 이를 수행하기 위한 데몬입니다. 이 외에도 Swift는 많은 데몬과 미들웨어를 제공하고 있습니다.

OpenStack Swift 기능

OpenStack Swift는 API 또는 CLI를 이용해 Object Storage의 다양한 기능을 사용할 수 있습니다. 해당 기능을 WEB UI로 구현하여 다양한 서비스도 제공할 수 있습니다.

 

첫번째는 Container, Object에 대한 생성 및 관리, 그리고 접근 관리입니다. 특히 접근관리를 통해 컨테이너 수준 및 Object 수준으로 특정 사용자에게 접근 권한을 할당할 수 있습니다. 그리고 Object에 대한 생명주기 관리를 통해 Object를 자동으로 삭제하는 등의 작업을 할 수 있습니다.

 

두번째는 Object Versioning입니다. 파일의 현재 버전과 이전 버전을 관리하고 복구하며 삭제하는 등의 작업을 할 수 있습니다.

 

세번째는 Object에 대한 다양한 고급 기능 지원입니다. 긴 리스트에 대해 페이징을 지원하고 가상의 계층형 폴더를 지원하며 5GB 이상의 큰 Object를 저장할 수 있도록 하는 기능, 그리고 여러 파일을 한번에 삭제하고, 자동 압축 풀림 아카이브 파일 설정, 그리고 마지막으로 컨테이너에 있는 파일을 이용해 정적인 웹 사이트 서비스를 할 수 있도록 하는 등 거의 Amazon S3가 제공하는 대부분의 기능이 포함되어 있습니다. 충분히 기능을 연구하고 보강하면 퍼블릭 수준의 Object Storage 서비스를 제공할 수 있게 되는 것입니다.

'서버' 카테고리의 다른 글

HAProxy  (0) 2017.01.28
Mesos  (0) 2017.01.28
OpenStack Swift  (0) 2017.01.26
블록 스토리지와 오브젝트 스토리지  (0) 2017.01.23
[Linux] sudo 명령어 실행시 PATH 연결이 안될 때 해결 방법  (0) 2017.01.17
[Linux] chmod, chown, umask  (0) 2017.01.13

+ Random Posts