Docker를 활용한 AirComix 서버 설치


Synology NAS - Docker를 활용한 AirComix 서버 설치


나스시장의 최강자! 시놀로지!

그동안 저는 DS-215j 모델을 사용해오고 있어서 몰랐는데 새로나온 고사양급 모델들은 요즘 IT인프라에서 가장 핫한 아이템인 Docker를 사용 할 수 있도록 업데이트가 되었더군요! 이번에 신형 NAS로 교체한 기념으로 포스팅 해봅니다.

그 Docker로 무얼 할 수 있는가? 고민하다가 예전 버전에서는 어렵게 아파치 서버를 띄워서 구성했던.. 근데 DSM이 버전업 해버리면서 아파치의 경로가 바뀌어서 서버가 깨져서 내부에서 꼬여버려 사용하지 못했던 슬픈 역사가 있던.. AirComix 서버 설치를 해보려고 합니다. AirComix 서버를 설치하면 막대한 용량의 압축 파일들을 앱에 넣지 않고, 통신망을 사용하여 어디에서든 스트리밍으로 구독이 가능합니다. 그래서 이번엔 아파치가 아닌 Nginx를 가지고 AirComix 서버를 구성해보고자 합니다.


설치과정에 있어서 pagein.net의 글을 많이 참고 했습니다.

설치하면서 제가 답답했던 부분이나 추가적인 부분을 더 포스팅 하려고 합니다.


Nginix PHP 설치


레지스트리를 선택한다음, 검색창에 nginx php 라고 검색을 한 후 나오는 목록에서 richarvey/nginx-php-fpm를 선택합니다.

더블 클릭하면 설치할 버전을 물어봅니다.

이미지에 richarvey/nginx-php-fpm:lastest 라고 생성 되는데, 다운이 완료 되면 304MB 용량 표시가 뜨고, 실행 버튼이 활성화 됩니다.

실행을 누르면 컨테이너 생성을 할 수 있습니다.

컨테이너 이름에 저는 aircomix-server 라고 넣었습니다. 원하는 이름으로 서버를 생성하시면 됩니다.

고급 설정을 누르면

자동 재시작 활성화에 체크 해주시고

볼륨 탭에서 폴더 추가를 해줍니다.

파일/폴더 있는 곳은 실제 NAS에 만화책들의 압축파일이 있는 경로를 지정해주시고, 마운트 경로는 Docker에 올라간 컨테이너 내에서 실제 책이 있는 경로가 마운트 되어 표현되어지는 경로입니다.

이게 무슨 소리냐? 하실 수도 있는데, 쉽게 말하자면,

만약에 실제 NAS의 /volume2/coimx 경로에 책 파일 있습니다. 하지만 docker로 컨테이너가 구성 되면 나스 안에 새로운 OS가 생성된것 같이 보이는데, 그안에는 실제 경로인 /volume2/coimx는 보이지 않고, 그 볼륨 구성안에서 /volume1/books 라는 경로로 실제 NAS의 경로가 연결된다는 뜻입니다. (실제 /volume2/comix => 컨테이너 /volume1/books) 윈도우의 바로가기나 리눅스의 ln 링크처럼 말이죠. 저는 만화책 뿐만 아니라 다른 책들도 같이 넣을것이기 때문에 books라고 지정 했습니다. 마운트에 volume1은 바꾸지 마세요.

포트 설정입니다. 다른 포트 다 지우셔도 상관 없습니다.

자동으로 되어 있는 로컬 포트도 31257로 고정하고, 컨테이너 포트도 31257로 설정해 줍니다. TCP, UDP 다 설정 해줍니다.

그러면 비디오 형식에 다음과 같이 컨테이너가 실행되고 있음을 확인 할 수 있습니다.

세부사항을 누르고, 터미널 탭으로 가서 생성을 누르면 bash 쉘이 뜹니다.

pwd를 치면 컨테이너 안에서 현재 경로가 보이는데, /var/www/html 이 곳이 nginx의 웹을 구동하기 위해 파일을 넣어두는 디렉토리입니다. 이 곳에서 github에 있는 AirComix 파일을 내려받습니다.

bash-4.4# wget https://github.com/song31/comix-server/archive/master.tar.gz

그리고 다운로드가 완료 되면 압축을 풉니다.

bash-4.4# tar -zxvf master.tar.gz

압축을 풀면 /var/www/html/ 아래에 comix-server-master 라는 디렉토리가 생성됩니다.

bash-4.4# cd comix-server-master

comix-server-master 디렉토리에 가서 몇가지 설정파일을 편집 해줍니다.

우선 index.php를 수정해줍니다.

기본 값은 manga 라고 되어 있는데, 아까 위에서 /volume1/books로 지정했던 부분의 books를 넣어줍니다. 만약 /volume1/comics 로 지정 했다면 comics를 넣으면 됩니다.

그 다음에 /etc/nginx/sites-enabled 로 이동을 합니다.

bash-4.4# cd /etc/nginx/sites-enabled

이 곳에다 aircomix-server.conf 파일을 만들어 줄것인데, 아래 명령으로 설정 파일을 받아 압축을 풀어도 되고,

bash-4.4# wget https://pagein.net/wp-content/uploads/2018/01/aircomix-server.tar.gz

아니면 vi 로 직접 생성해줘도 됩니다.

bash-4.4# vi aircomix-server.conf

아래와 같이 설정 해줍니다.

server {
    listen 31257;
    server_name 192.168.xxx.xxx;
    charset UTF-8;
    root /var/www/html/comix-server-master;
    location / {
        autoindex on;
        index index.php;
        #auth_basic "Restricted Access";
        #auth_basic_user_file /var/www/html/comix-server-master/.htpasswd;
    }
    location ~ \.php$ {
        fastcgi_pass unix:/var/run/php-fpm.sock;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        include fastcgi_params;
    }
    location ~ ^/manga(.*)$ {
        include fastcgi_params;
        fastcgi_pass unix:/var/run/php-fpm.sock;
        fastcgi_param SCRIPT_FILENAME /var/www/html/comix-server-master/handler.php;
    }
}

NAS-IP에는 실제 시놀로지 NAS가 공유기에서 받은 IP를 넣어주는 겁니다.

편집이 끝났으면 저장. (vi 편집기 사용에 관한 부분은 다른 사이트를 참고하셔서 알아두시는 편이 좋습니다.)

그리고 비디오 형식에 작업 버튼에 다시 시작을 누르거나 오른버튼을 클릭해서 다시 시작을 하거나 오른쪽 버튼을 클릭해서 껐다 키거나 해서 컨테이너를 재시작 해주면 실행이 됩니다.


웹 브라우저를 열고 http://NAS IP:31257 쳐서 books 라고 나오면 성공한겁니다.

제어판에 외부엑세스에서 DDNS 서비스를 이용하고 계시다면 http://해당 도메인:31257 으로 외부에서도 접속이 가능한데, 이건 공유기에서 DMZ 설정이나 포트포워딩 설정이 NAS로 연결되어 있어야지만 가능한 겁니다. 구글에서 포트포워딩 혹은 공유기 DMZ설정을 찾아보세요. 공유기 제조사 마다 설정 방법이 모두 다릅니다.


AirComix 암호설정하기


코믹스 서버 디렉토리로 이동합니다.

bash-4.4# cd /var/www/html/comix-server-master

여기에서 .htpasswd 파일을 생성합니다.

bash-4.4# printf "AirComix:$(openssl passwd -crypt 패스워드)\n" >> .htpasswd
bash-4.4# chown nginx:nginx .htpasswd
bash-4.4# chmod 640 .htpasswd

그리고 다시 aircomix-server.conf 파일을 수정합니다.

bash-4.4# vi /etc/nginx/sites-enabled/aircomix-server.conf

주석(#)처리된 부분을 지워주고 저장.

이렇게 하면 앱에서 AirComix 서버로 접속하기 위해서는 반드시 패스워드가 필요합니다.

설정 완료!

'Operating System > Synology NAS' 카테고리의 다른 글

Docker를 활용한 AirComix 서버 설치  (2) 2019.01.29
  1. 맨 끝에 주석(#) 있는 부분을 지우고 저장 하라 했는데 어디를 지워야 하는건가요?? 동그란 원에 있는 auth로 된 곳 2줄 다 지웠는데 암호 설정이 안됐고, 그냥 암호 없이 들어가지네요,

오픈스택 수동 설치 실습 #.14


오픈스택 수동 설치 실습 #.14 - Cinder block storage 서비스 설치


Cinder - LVM을 이용한 스토리지 노드 구성

오픈스택 블록 스토리지(Cinder)는 오픈스택 컴퓨트 인스턴스에 사용할 지속적인 블록 레벨 스토리지 장치들을 제공합니다. 블록 스토리지 시스템은 블록 장치들을 서버에 작성, 부착, 제거하는 일을 관리하며, 블록 스토리지 볼륨들은 클라우드 사용자들이 자신만의 스토리지의 필요한 부분을 관리하기 위한 대시보드 및 오픈스택 컴퓨트와 완전히 연동됩니다. 로컬 리눅스 서버 스토리지뿐 아니라 Ceph, 클라우드바이트, Coraid, EMC(ScaleIO, VMAX, VNX and XtremIO), GlusterFS, 히타치 데이터 시스템, IBM 스토리지(IBM DS8000, Storwize 계열, SAN 볼륨 컨트롤러, XIV 스토리지 시스템, GPFS), 리눅스 LIO, 넷앱, 넥센타, 님블 스토리지, Scality, 솔리드파이어, HP (스토어버추얼, 3PAR 스토어서브 계열), 퓨어 스토리지를 포함한 스토리지 플랫폼들을 사용합니다. 블록 스토리지는 데이터베이스 스토리지, 확장 가능 파일 시스템과 같은 성능에 민감한 시나리오에 적절하며, 서버에 로우 블록 레벨 스토리지에 대한 접근을 제공합니다. 스냅샷 관리는 블록 스토리지 볼륨에 저장된 데이터를 백업하는 강력한 기능을 제공하며, 스냅샷들은 새로운 블록 스토리지 볼륨들을 만들기 위해 사용하거나 복원할 수 있습니다.


Controller 노드 설치

# su - postgres
$ psql
postgres=# create role cinder with login;
postgres=# create database cinder;
postgres=# grant ALL PRIVILEGES ON DATABASE cinder TO cinder;
postgres=# alter user cinder with encrypted password 'cinder';

# . admin-openrc


cinder 유저 생성 및 admin 권한 추가

# openstack user create --domain default --password-prompt cinder
# openstack role add --project service --user cinder admin
cinderv2 와 cinderv3 서비스 생성
# openstack service create --name cinderv2 \
  --description "OpenStack Block Storage" volumev2
 
# openstack service create --name cinderv3 \
  --description "OpenStack Block Storage" volumev3
endpoint 생성
# openstack endpoint create --region RegionOne \
  volumev2 public http://controller:8776/v2/%\(project_id\)s
 
# openstack endpoint create --region RegionOne \
  volumev2 internal http://controller:8776/v2/%\(project_id\)s
 
# openstack endpoint create --region RegionOne \
  volumev2 admin http://controller:8776/v2/%\(project_id\)s
 
# openstack endpoint create --region RegionOne \
  volumev3 public http://controller:8776/v3/%\(project_id\)s
 
# openstack endpoint create --region RegionOne \
  volumev3 internal http://controller:8776/v3/%\(project_id\)s
 
# openstack endpoint create --region RegionOne \
  volumev3 admin http://controller:8776/v3/%\(project_id\)s
cinder 패키지 설치
# yum -y install openstack-cinder 
cinder.conf 파일 수정
# vi /etc/cinder/cinder.conf 
[database]
connection = postgresql://cinder:cinder@controller/cinder

[DEFAULT]
transport_url = rabbit://openstack:RABBIT_PASS@controller
auth_strategy = keystone
my_ip = 10.0.0.11
enable_v3_api = True

[keystone_authtoken]
auth_uri = http://controller:5000
auth_url = http://controller:5000
memcached_servers = controller:11211
auth_type = password
project_domain_id = default
user_domain_id = default
project_name = service
username = cinder
password = CINDER_PASS

[oslo_concurrency]
lock_path = /var/lib/cinder/tmp
블록 스토리지 데이터베이스 배포

# su -s /bin/sh -c "cinder-manage db sync" cinder
Compute 노드에서

nova.conf 파일수정
# vi /etc/nova/nova.conf
[cinder]
os_region_name = RegionOne
nova 서비스 재시작

# systemctl restart openstack-nova-api.service

다시 Controller 노드에서

keystone에 Volume API 버전 추가
# echo "export OS_VOLUME_API_VERSION=3" >> ~/admin-openrc
cinder 서비스 등록 및 시작
# systemctl enable openstack-cinder-api.service openstack-cinder-scheduler.service
# systemctl start openstack-cinder-api.service openstack-cinder-scheduler.service



Storage 노드 설치 (LVM 이용)


storage 노드는 다양한 스토리지로 설치가 가능하지만 VM환경에서는 LVM으로 진행을 합니다.


필요 패키지 설치

# yum -y install centos-release-openstack-rocky
# yum -y upgrade
# yum -y install python-openstackclient
# yum -y install openstack-selinux
# yum -y install python-psycopg2
lvm 패키지 설치
# yum install lvm2 device-mapper-persistent-data

lvm 서비스 등록 및 시작

# systemctl enable lvm2-lvmetad.service
# systemctl start lvm2-lvmetad.service

pv 볼륨 설정

# pvcreate /dev/sdb

Physical volume "/dev/sdb" successfully created

vg 볼륨 설정

# vgcreate cinder-volumes /dev/sdb

Volume group "cinder-volumes" successfully created

lvm.conf 수정

# vi /etc/lvm/lvm.conf
devices {
...
filter = [ "a/sdb/", "r/.*/"]

cinder 패키지 설치
# yum -y install openstack-cinder targetcli python-keystone python2-crypto

cinder.conf 파일 수정

# vi /etc/cinder/cinder.conf
[database]
connection = postgresql://cinder:cinder@controller/cinder

[DEFAULT]
transport_url = rabbit://openstack:RABBIT_PASS@controller
auth_strategy = keystone
my_ip = 10.0.0.41
enabled_backends = lvm

glance_api_servers = http://controller:9292

enable_v3_api = True


[keystone_authtoken]
auth_uri = http://controller:5000
auth_url = http://controller:5000
memcached_servers = controller:11211
auth_type = password
project_domain_id = default
user_domain_id = default
project_name = service
username = cinder
password = CINDER_PASS

[lvm]
volume_driver = cinder.volume.drivers.lvm.LVMVolumeDriver
volume_group = cinder-volumes
iscsi_protocol = iscsi

iscsi_helper = lioadm

target_ip_address = 10.0.0.41
volumes_dir = $state_path/volumes


[oslo_concurrency]
lock_path = /var/lib/cinder/tmp

※ [lvm] 부분은 없으니 만들어 줍니다.

cinder 서비스 등록 및 시작

# systemctl enable openstack-cinder-volume.service target.service
# systemctl start openstack-cinder-volume.service target.service
controller 노드에서 서비스 확인


볼륨 설정이 완료 되었습니다.

Cinder 까지 설치가 완료되어 코어 부분은 다 설치가 완료 되었습니다.


PostgreSQL 시간 조회



현재 시간 조회
 postgres=# select now();
현재 타임존 조회
 postgres=# show timezone;
타임존 변경 방법
 postgres=# SET TIME ZONE 'Asia/Seoul';
시스템 일자
 postgres=# select current_date, current_time, timeofday();
postgres=# select now(), current_timestamp, timestamp 'now';
년도 추출
 postgres=# select date_part('year', current_timestamp);
월 추출
 postgres=# select date_part('month', current_timestamp);
일 추출
 postgres=# select date_part('day', current_timestamp);
분 추출
postgres=# select date_part('minute', current_timestamp);
초 추출
 postgres=# select date_part('second', current_timestamp);
요일/일차 추출
 postgres=# select extract('dow' from timestamp '2013-07-30 20:38:40');    -- 일요일(0), 토요일(6)
result: 5
 postgres=# select extract('isodow' from timestamp '2013-07-30 20:38:40'); -- 월요일(1), 일요일(7)
result: 5
 postgres=# select extract('doy' from timestamp '2013-07-30 20:38:40');


오픈스택 수동 설치 실습 #.13



오픈스택 수동 설치 실습 #.13 - Horizon 대시보드 설치


Horizon 대시보드 설치


오픈스택 대시보드(Horizon)는 관리자와 사용자들에게 클라우드 기반 자원 배치의 접근, 제공, 자동화를 위한 그래픽 인터페이스를 제공합니다. 과금, 모니터링, 추가 관리 도구와 같은 서드파티 제품과 서비스들을 수용합니다. 대시보드는 또한 이용하기 원하는 서비스 제공자 및 기타 상용 벤더들을 위해 브랜드화가 가능하며, 대시보드는 사용자들이 오픈스택 자원들과 상호작용할 수 있는 여러 방법 가운데 하나입니다. 개발자들은 네이티브 오픈스택 API나 EC2 호환 API를 사용하여 자원을 관리하기 위해 액세스를 자동화하거나 도구를 빌드할 수 있습니다.



Horizon 대시보드 패키지 설치

# yum -y install openstack-dashboard

local_setting 파일 수정

# vi /etc/openstack-dashboard/local_settings
# 대시보드 호스트를 추가합니다.
ALLOWED_HOSTS = ['*']

# 오픈스택 API의 버전들을 설정 합니다.
OPENSTACK_API_VERSIONS = {
#    "data-processing": 1.1,
    "identity": 3,
    "image": 2,
    "volume": 2,
}

# 오픈스택의 멀티 도메인을 사용가능하게 합니다.
OPENSTACK_KEYSTONE_MULTIDOMAIN_SUPPORT = True

# Keystone의 기본 도메인을 'Default'로 설정합니다.
OPENSTACK_KEYSTONE_DEFAULT_DOMAIN = 'Default'


# SESSION_ENGINE을 설정합니다.
SESSION_ENGINE = 'django.contrib.sessions.backends.cache'

# Memcached 정보를 설정합니다.
CACHES = {
    'default': {
         'BACKEND': 'django.core.cache.backends.memcached.MemcachedCache',
         'LOCATION': 'controller:11211',
    }
}


# 오픈스택 대시보드를 실행할 컨트롤러 노드의 관리용 IP를 OPENSTACK_HOST에 설정합니다.
OPENSTACK_HOST = "controller"

# 오픈스택의 Keystone URL을 설정합니다.
OPENSTACK_KEYSTONE_URL = "http://%s:5000/v3" % OPENSTACK_HOST

# 오픈스택의 Keystone 기본권한을 설정합니다.
OPENSTACK_KEYSTONE_DEFAULT_ROLE = "_member_"

# Provider 네트워크를 선택하여 linuxbridge를 이용한다면 l3 네트워킹 서비스 지원을 사용안함으로 설정합니다.
OPENSTACK_NEUTRON_NETWORK = {
    ...
    'enable_router': False,
    'enable_quotas': False,
    'enable_distributed_router': False,
    'enable_ha_router': False,
    'enable_lb': False,
    'enable_firewall': False,
    'enable_vpn': False,
    'enable_fip_topology_check': False,
}

# 타임존을 설정합니다.
TIME_ZONE = "Asia/Seoul"

openstack-dashboard.conf 파일 수정

# vi /etc/httpd/conf.d/openstack-dashboard.conf 
WSGIDaemonProcess dashboard
WSGIProcessGroup dashboard
WSGISocketPrefix run/wsgi
WSGIApplicationGroup %{GLOBAL}

Httpd 재시작

# systemctl restart httpd.service memcached.service

인터넷 브라우저에서 http://10.0.0.11/dashboard 로 접속하면 로그인 화면이 뜹니다.

admin 계정으로 로그인을 해보면,

개요 화면이 보이고, 내부 정보가 보입니다.

이러면 설치가 완료된 것입니다.



오픈스택 수동 설치 실습 #.12

오픈스택 수동 설치 실습 #.12 - Neutron 네트워크 설치 :



Linux Bridge를 이용한 Provider 네트워크 구성

Compute 노드


Neutron 패키지 설치

# yum -y install openstack-neutron-linuxbridge ebtables ipset
neutron.conf 파일 수정
# vi /etc/neutron/neutron.conf
[DEFAULT]
# ...
transport_url = rabbit://openstack:RABBIT_PASS@controller

[DEFAULT]
# ...
auth_strategy = keystone

[keystone_authtoken]
# ...
www_authenticate_uri = http://controller:5000
auth_url = http://controller:5000
memcached_servers = controller:11211
auth_type = password
project_domain_name = Default
user_domain_name = Default
project_name = service
username = neutron
password = NEUTRON_PASS

[oslo_concurrency]
# ...
lock_path = /var/lib/neutron/tmp

linuxbridge_agent.ini 파일 수정

# vi /etc/neutron/plugins/ml2/linuxbridge_agent.ini
[linux_bridge]
physical_interface_mappings = provider:PROVIDER_INTERFACE_NAME

[vxlan]
enable_vxlan = false

[securitygroup]
# ...
enable_security_group = true
firewall_driver = neutron.agent.linux.iptables_firewall.IptablesFirewallDriver
nova.conf
# vi /etc/nova/nova.conf
[neutron]
# ...
url = http://controller:9696
auth_url = http://controller:5000
auth_type = password
project_domain_name = Default
user_domain_name = Default
region_name = RegionOne
project_name = service
username = neutron
password = NEUTRON_PASS

Nova-compute 재시작

# systemctl restart openstack-nova-compute.service
neutron 서비스 설정 및 시작
# systemctl enable neutron-linuxbridge-agent.service
# systemctl start neutron-linuxbridge-agent.service
Neutron 설치가 완료 되었습니다.

Controller 노드에서 확인

Compute 노드에도 Keystone 인증 파일(admin-openrc)을 만들고 openstack network agent list


PostgreSQL 주기적인 유지관리 Vacuuming



주기적인 유지관리 Vacuuming

Vacuum 기초

 - PostgreSQL의 Vacuum 명령은 다음과 같은 이유로 각 테이블마다 정기적으로 프로세스 해야합니다.

 a. 업데이트 또는 삭제된 행이 점유한 디스크 공간의 복구 또는 재사용.
 b. PostgreSQL 쿼리 플래너가 사용하는 데이터 통계 업데이트 (DB통계정보)
 c. 인덱스 전용 스캔 속도를 높이는 가시도 맵(visibility map) 업데이트
 d. 트랜잭션 ID 랩어라운드 또는 multixact ID 랩어라운드에 의한 아주 오래된 데이터가 손실되지 않도록 보호
 
 Vacuum에는 두가지 변이인 표준 Vacuum과 Vacuum Full이 있습니다. Vacuum Full은 디스크 공간을 더 많이 회수하는 대신 실행이 느립니다. 또한, 표준형 Vacuum은 데이터베이스 작업과 병렬로 실행할 수 있습니다. (Vacuum 진행중에 DDL (alter) 명령은 안되나 DML (select,insert,delete,update) 명령은 정상 작동함)
 Vacuum Full 작업은 작업중인 테이블에 대해 배타적 잠금이 필수이므로, 테이블의 다른 작업과 병렬로 사용할 수 없습니다.
 Vacuum은 상당한 I/O 트래픽이 발생되며, 다른 활성 세션의 성능을 저하시키는 원인이 됩니다.
 
1) 디스크 공간 복구

 - PostgreSQL에서 행의 UPDATE 또는 DELETE는 행의 오래된 버전을 즉각 제거하지 않습니다. 이러한 접근법은 MVCC의 장점을 누리기 위한것으로, 다른 트랜잭션에서 계속 확인될 가능성이 있을 경우에는 행 버전을 삭제해서는 안됩니다. 그러나 오래되었거나 삭제된 행 버전은 트랜잭션 대상이 아니기 때문에 Vacuum으로 회수 가능합니다.
 - 표준형 Vacuum은 테이블과 인덱스에서 Deed row 버전을 삭제하고, 나중에 재사용할 수 있도록 가용 공간으로 표시합니다. 하지만 테이블에 쓸수 있는 공간이 있는 경우는 오래된 공간을 반환하지 않습니다.
 - Vacuum Full은 Dead space가 일절 없도록 모든 공간을 반환합며, 테이블을 새버전으로 작성함으로 테이블이 최소화되지만, 시간이 오래걸리는 단점이 있습니다.
 - 일상적인 Vacuuming의 목표는 Vacuum Full이 불필요 하도록 표준형 Vacuum을 충분히 실행하는 것입니다. autovacuum데몬은 이와 같은 방식을 작동 되며, 사실상 Vacuum Full을 절대 수행하지 않습니다.
 
2) 실행 계획 통계 업데이트

 - PostgreSQL 쿼리 플래너는 쿼리에 대해 괜찮은 플랜을 생성하기 위해, 테이블 내용에 대한 통계정보에 의존합니다. 이러한 통계는 자체적으로 호출하거나 Vacuum에서 옵션으로 처리하거나 ANALYZE 명령으로 생성됩니다.
 - autovacuum 데몬이 활성화 되면 테이블 내용이 바뀔때마다 ANALYZE 명령이 자동으로 실행됩니다. 업데이트가 빈번하더라도, 데이터의 통계적 분포가 많이 바뀌지 않을때는 통계를 업데이트를 할 필요가 없습니다.

3) visibility map 업데이트

 - Vacuum은 모든 활성 트랜잭션에 보이는 것으로 알려진 튜플만 포함된 페이지를 추적하기 위하여 각 테이블에 대한 visibility map을 관리합니다.
 - 첫번째 목적은 Vacuum 자체는 cleanup 할 것이 없으므로 다음 실행에서 해당 페이지를 스킵합니다.
 - 두번째 목적은 기저 테이블을 참조하지 않고 인덱스만 이용하여 PostgreSQL이 일부 쿼리에 응답할 수 있게 합니다. 테이블을 참조 하지 않고 인덱스만 스캔하는 경우 visibility map을 먼저 확인하기 때문에 페이지에 튜플이 보이는 경우 heep fetch를 스킵할 수 있습니다. 거대 데이터 세트에서는 visibility map이 디스크 액세스를 막을 수 있는 가장 확실한 방법입니다. visibility map은 heep 보다 훨씬 작기때문에 heep이 매우 클 경우에도 쉽게 캐쉬 됩니다.

4) 트랜잭션 ID 랩어라운드 실패 방지

 - PostgreSQL의 MVCC 트랜잭션 시멘틱은 트랜잭션 ID(XID) 번호의 비교 가능 여부에 달려있습니다. 트랜잭션 ID의 크기는 제한되어 있으므로(32비트) 장시간 (40억 트랜잭션 이상) 동안 실행되는 클러스터는 트랜잭션 ID 랩어라운드가 발생합니다. XID 카운트가 0으로 랩어라운드 되고 과거에 있었던 모든 트랜잭션이 미래에 나타나게 됩니다. 즉 데이터의 소실이 발생합니다. 이 것을 피하려면 피하려면 20억 트랜잭션마다 모든 데이터베이스의 모든 케이블을 Vacuum해야 합니다.
 - 주기적으로 Vacuuming으로 문제가 해결되는 이유는 이 행이 과거에 커밋된 트랜잭션에 의해 삽입되었고 삽입 트랜잭션의 결과로 MVCC 관점으로 부터 현재와 미래 트랜잭션에서 모두 보이는 것이 확실하도록 Vacuum이 행에 동결 표시를 한다는 것입니다.
 
5) Multixact 및 랩어라운드

 - Multixact ID는 복수 트랜잭션에 의한 행 잠금을 지원할 때 사용됩니다.
 - Vacuum 테이블 스캔 중에, 테이블 부분적으로 또는 전체적으로 vacuum_multixact_freeze_min_age보다 오래된 multixact ID는 서로 다른 값으로 교체되는데, 이 값은 0, 단일 트랜잭션ID 또는 신규 multixact ID일 수 있습니다. 테이블 별로 pg_class.relminmxid는 해당 테이블에 계속 나타날 가능성이 있고 가장 오래된 multixact ID를 저장합니다. 이 값이 vacuum_multixact_freeze_min_age보다 오래된 경우 전체 테이블 스캔이 강제됩니다.
 - 전체 테이블 Vacuum 스캔은 사용된 멤버 저장소 공간이 할당된 저장소 공간의 50%를 초과 할 경우 multixact 연령이 가장 오래된 것을 시작으로 모든 테이블에 대해 순처적으로 일어납니다.
 
6) Autovacuum 데몬
 
 - Autovacuum 데몬의 목적은 Vacuum과 ANALYZE 명령의 실행을 자동화하는 것입니다.
 - autovacuum이 활성화 되면 다수의 튜플이 삽입, 업데이트 또는 삭제된 테이블을 검사합니다. 이 검사는 통계 수집 기능을 사용합니다. 따라서 track_counts가 true로 설정되지 않으면 사용할 수 없습니다.
 

오픈스택 수동 설치 실습 #.11

오픈스택 수동 설치 실습 #.11 - Neutron 네트워크 설치 :



Linux Bridge를 이용한 Provider 네트워크 구성


Controller 노드



OpenStack 네트워킹 (neutron)은 가상 네트워킹 인프라 (VNI)에 대한 모든 네트워킹 측면과 OpenStack 환경에서 물리 네트워킹 인프라 (PNI)의 접근 레이어 측면에서 관리합니다. OpenStack 네트워킹은 firewall, load balancer, virtual private network (VPN) 같은 서비스를 포함할수 있으며, 진보한 가상 네트워크 토폴리지를 생성하여 tenant를 활성화 합니다.


네트워킹에서는 객체 추상화를 통해 네트워크, 서브넷, 라우터를 제공합니다. 각 추상화는 물리적인 구성에 대응하여 모방하는 기능이 들어있습니다: 네트워크는 서브넷이 포함되어 있고, 다른 서브넷과 네트워크 간의 트레픽은 라이터를 통하여 나눠집니다.


각 라우터는 네트워크에 연결하는 하나의 게이트웨이를 갖고, 많은 인터페이스들이 서브넷에 연결됩니다. 서브넷은 같은 라우터 내에 연결된 다른 서브넷 상의 머신에 액세스 가능합니다.


임의로 주어진 네트워킹 셋업은 하나 이상의 외부 네트워크를 갖습니다. 다른 네트워크와 달리, 외부 네트워크는 단지 가상으로 정의된 네트워크를 의미하지 않습니다. 이 대신, OpenStack 설치 바깥으로 접근 가능한 뷰의 물리, 외부 네트워크에 대한 슬라이스를 나타냅니다. 외부 네트워크의 IP 주소는 바깥 네트워크 상의 임의의 물리적인 객체에서 액세스 가능합니다. 외부 네트워크가 바깥 네트워크로의 뷰를 나타내기에, DHCP가 해당 네트워크에서는 비활성화됩니다.


외부 네트워크 뿐만 아니라, 임의의 네트워킹 셋업은 하나 이상의 내부 네트워크를 갖습니다. 이러한 소프트웨어 정의 네트워크들은 VM에 직접 연결됩니다. 임의의 주어진 내부 네트워크, 또는 인터페이스를 통해 비슷한 라우터에 연결된 서브넷 상의 VM에서만 대상 네트워크에 직접 연결된 VM에 액세스 가능합니다.


외부 네트워크에서 VM에 접근하거나, 그 반대의 경우에도 네트워크 사이의 라우터가 필요합니다. 각 라우터는 네트워크에 연결된 하나의 게이트웨이와 많은 인터페이스에 연결된 서브넷으로 되어있습니다. 물리적 라우터와 같이 동일한 라우터에 연결된 다른 서브넷의 머신에 접근할 수 있고, 머신에서 라우터의 게이트웨이를 통하여 외부 네트워크에 접근할 수 있습니다.


또한, 외부 네트워크를 내부 네트워크와 연결하도록 IP 주소를 할당할 수 있습니다. 하위 네트워크에 어떤 포트가 연결되든 이 연결을 포트라고 합니다. 외부 네트워크 IP 주소를 가상 머신에 포트와 할당할 수 있습니다. 이 방법을 통해 외부 네트워크의 실체가 가상 머신에 접근할 수 있습니다.


네트워킹은 시큐리티 그룹 을 지원합니다. 시큐리티 그룹은 그룹내에서 방화벽 규칙을 정의하여 관리자를 활성화합니다. VM은 하나에서 여러 시큐리티 그룹을 가질 수 있으며, 시큐리티 그룹에서 포트를 막거나 열고, 포트 범위, VM에 대한 트래픽 타입 등의 규칙을 적용할 수 있습니다.


네트워킹에서 사용하는 각 플러그인은 각자의 개념을 갖고 있습니다. VNI 및 OpenStack 환경을 운영하는데 필수는 아니지만, 이러한 개념에 대한 이해는 네트워킹 셋업을 도와줍니다. 모든 네트워킹 설치는 코어 플러그인과 보안 그룹 플러그인 (또는 단순히 No-Op 보안 그룹 플러그인)을 사용합니다. 부가적으로, Firewall-as-a-Service (FWaaS) 및 Load-Balancer-as-a-Service (LBaaS)이 사용 가능합니다.



Neutron 설치 : Controller 노드

# su - postgres

$ psql

Neutron 데이터베이스 생성

postgres=# create role neutron with login;

postgres=# create database neutron;

postgres=# grant ALL PRIVILEGES ON DATABASE neutron TO neutron;

postgres=# alter user neutron with encrypted password 'neutron';

Keystone 인증 불러오기

# . admin-openrc

Neutron 계정 생성 및 admin 권한 부여

# openstack user create --domain Default --password-prompt neutron

# openstack role add --project service --user neutron admin


Neutron 서비스 생성

# openstack service create --name neutron \

  --description "OpenStack Networking" network

# export controller=10.0.0.11 

Neutron 엔드포인트 생성 

# openstack endpoint create --region RegionOne \

  network public http://controller:9696


# openstack endpoint create --region RegionOne \

  network internal http://controller:9696


# openstack endpoint create --region RegionOne \

  network admin http://controller:9696


Neutron 패키지 설치

# yum install openstack-neutron openstack-neutron-ml2 \

  openstack-neutron-linuxbridge ebtables

neutron.conf 파일 수정

# vi /etc/neutron/neutron.conf

[DEFAULT]

# ...

transport_url = rabbit://openstack:open1234@controller

auth_strategy = keystone


[keystone_authtoken]

# ...

www_authenticate_uri = http://controller:5000

auth_url = http://controller:5000

memcached_servers = controller:11211

auth_type = password

project_domain_name = default

user_domain_name = default

project_name = service

username = neutron

password = open1234


[oslo_concurrency]

# ...

lock_path = /var/lib/neutron/tmp

linuxbridge-agent.ini 수정

# vi /etc/neutron/plugins/ml2/linuxbridge_agent.ini

[linux_bridge]

physical_interface_mappings = provider:ens33 <-- bridge로 설정했던 공유기에서 ip받아오는 NIC


[vxlan]

enable_vxlan = false


[securitygroup]

# ...

enable_security_group = true

firewall_driver = neutron.agent.linux.iptables_firewall.IptablesFirewallDriver

nova.conf 수정

# vi /etc/nova/nova.conf

[neutron]

# ...

url = http://controller:9696

auth_url = http://controller:5000

auth_type = password

project_domain_name = Default

user_domain_name = Default

region_name = RegionOne

project_name = service

username = neutron

password = open1234

ml2-conf.ini 링크

# ln -s /etc/neutron/plugins/ml2/ml2_conf.ini /etc/neutron/plugin.ini

Neutron DB Sync

# su -s /bin/sh -c "neutron-db-manage --config-file /etc/neutron/neutron.conf \

  --config-file /etc/neutron/plugins/ml2/ml2_conf.ini upgrade head" neutron

Nova 재시작

# systemctl restart openstack-nova-api.service

Neutron 서비스 등록 및 시작

# systemctl enable neutron-server.service \

  neutron-linuxbridge-agent.service neutron-dhcp-agent.service \

  neutron-metadata-agent.service

# systemctl start neutron-server.service \

  neutron-linuxbridge-agent.service neutron-dhcp-agent.service \

  neutron-metadata-agent.service

L3 에이전트 서비스 등록 및 시작

# systemctl enable neutron-l3-agent.service

# systemctl start neutron-l3-agent.service


확인 (DHCP나 Metadata 에이전트가 올라오는데 약간의 시간이 소요되니 잠깐 기다리면 올라옵니다.)



 

오픈스택 수동 설치 실습 #.10


오픈스택 수동 설치 실습 #.10 - Compute 노드에 Nova 설치



노바 패키지 설치

# yum -y install openstack-nova-compute

nova.conf 파일 수정

# vi /etc/nova/nova.conf

[DEFAULT] # define own IP address my_ip = 10.0.0.31 state_path = /var/lib/nova enabled_apis = osapi_compute,metadata log_dir = /var/log/nova # RabbitMQ connection info transport_url = rabbit://openstack:open1234@10.0.0.11 [api] auth_strategy = keystone # enable VNC [vnc] enabled = True server_listen = 0.0.0.0 server_proxyclient_address = 10.0.0.31 novncproxy_base_url = http://10.0.0.11:6080/vnc_auto.html # Glance connection info [glance] api_servers = http://10.0.0.11:9292 [oslo_concurrency] lock_path = $state_path/tmp # Keystone auth info [keystone_authtoken] www_authenticate_uri = http://10.0.0.11:5000 auth_url = http://10.0.0.11:5000/v3 memcached_servers = 10.0.0.11:11211 auth_type = password project_domain_name = Default user_domain_name = Default project_name = service username = nova password = NOVA_PASS [placement] auth_url = http://10.0.0.11:5000/v3 os_region_name = RegionOne auth_type = password project_domain_name = Default user_domain_name = Default project_name = service username = placement password = PLACEMENT_PASS [wsgi] api_paste_config = /etc/nova/api-paste.ini

nova.conf에 libvirt 라는 항목이 있습니다.


$ egrep -c '(vmx|svm)' /proc/cpuinfo


해당 명령을 실행 했을때, 0 (Zero)가 나온다면, qemu로 설정을 해줘야 합니다.

1 or 더 큰수가 나올 경우에는 다른 하이퍼바이저를 사용 할 수 있습니다. vm환경에다 설치할 경우 0 (Zero)가 나올겁니다.

[libvirt]

# ...

virt_type = qemu

※ Nova compute 서비스가 실패 하는 경우 /var/log/nova/nova-compute.log 를 체크 했을때, AMQP server on controller:5672 is unreachable 이 나온다면 방화벽 같은 항목에서 5672 포트가 막혀있는 것이니 확인 해주세요.




Nova 서비스 생성 및 자동실행 등록

# systemctl start openstack-nova-compute

# systemctl enable openstack-nova-compute


아래 항목은 Controller 노드에서 확인합니다.

$ . admin-openrc

Compute Host 찾기

# su -s /bin/bash nova -c "nova-manage cell_v2 discover_hosts"


compute 노드 설치가 완료 되었습니다.


오픈스택 수동 설치 실습 #.9


오픈스택 수동 설치 실습 #.9 - Controller 노드에 Nova 설치


Nova 설치 준비


SQL DB에 접속하여 nova, placement 2개의 유저를 생성합니다. DB계정에 대한 password는 보기 편하게 user와 동일하게 설정 했습니다.

Database nova, nova-api, nova_cell0, placement 4개의 DB를 생성합니다.

# su - postgres

$ psql

postgres=# create database nova;

postgres=# create database nova_api;

postgres=# create database nova_cell0;

postgres=# create database placement;


postgres=# create role nova with login;

postgres=# create role placement with login;


postgres=# grant all privileges on database nova to nova;

postgres=# grant all privileges on database nova_api to nova;

postgres=# grant all privileges on database nova_cell0 to nova;

postgres=# grant all privileges on database placement to placement;


postgres=# alter user nova with encrypted password 'nova';

postgres=# alter user placement with encrypted password 'placement';

keystone 인증 불러오기

# . admin-openrc

Nova 유저를 생성합니다.

$ openstack user create --domain Default --password-prompt nova

Nova 유저에 admin 권한을 줍니다.

$ openstack role add --project service --user nova admin

Nova 서비스 엔티티 생성

$ openstack service create --name nova \

  --description "OpenStack Compute" compute

Compute API 엔드포인트 생성

$ openstack endpoint create --region RegionOne \

  compute public http://controller:8774/v2.1


$ openstack endpoint create --region RegionOne \

  compute internal http://controller:8774/v2.1

  

$ openstack endpoint create --region RegionOne \

  compute admin http://controller:8774/v2.1

Placement 서비스 유저 생성

$ openstack user create --domain Default --password-prompt placement

Placement 서비스 유저에 admin 권한부여

$ openstack role add --project service --user placement admin

Placement 서비스 생성

$ openstack service create --name placement \

  --description "Placement API" placement

Placement API 엔드포인트 생성

$ openstack endpoint create --region RegionOne \

  placement public http://controller:8778

  

$ openstack endpoint create --region RegionOne \

  placement internal http://controller:8778


$ openstack endpoint create --region RegionOne \

  placement admin http://controller:8778


Nova 패키지 설치 및 설정

# yum install openstack-nova-api openstack-nova-conductor \

  openstack-nova-console openstack-nova-novncproxy \

  openstack-nova-scheduler openstack-nova-placement-api

# vi /etc/nova/nova.conf

[DEFAULT]

# ...

enabled_apis = osapi_compute,metadata

transport_url = rabbit://openstack:RABBIT_PASS@controller

my_ip = 10.0.0.11


[api_database]

# ...

connection = postgresql://nova:nova@controller/nova_api


[database]

# ...

connection = postgresql://nova:nova@controller/nova


[placement_database]

# ...

connection = postgresql://placement:placement@controller/placement


[api]

# ...

auth_strategy = keystone


[keystone_authtoken]

# ...

auth_url = http://controller:5000/v3

memcached_servers = controller:11211

auth_type = password

project_domain_name = Default

user_domain_name = Default

project_name = service

username = nova

password = NOVA_PASS


[vnc]

enabled = true

# ...

server_listen = 10.0.0.11

server_proxyclient_address = 10.0.0.11


[oslo_concurrency]

# ...

lock_path = /var/lib/nova/tmp


[placement]

# ...

region_name = RegionOne

project_domain_name = Default

project_name = service

auth_type = password

user_domain_name = Default

auth_url = http://controller:5000/v3

username = placement

password = PLACEMENT_PASS

Placement API 설정에 15째줄에 아래 내용을 추가해줘야 합니다.

# vi /etc/httpd/conf.d/00-nova-placement-api.conf

  <Directory /usr/bin>
    Require all granted
  </Directory>

# semanage port -a -t http_port_t -p tcp 8778

Nova-api DB와 placement DB에 배포

# su -s /bin/bash nova -c "nova-manage api_db sync"

cell0 데이터베이스 등록

# su -s /bin/bash nova -c "nova-manage cell_v2 map_cell0"

cell1 cell 생성

# su -s /bin/sh -c "nova-manage cell_v2 create_cell --name=cell1 --verbose" nova

Nova DB에 배포

# su -s /bin/bash nova -c "nova-manage db sync"

Nova 리스트에 cell0과 cell1을 등록

# ssu -s /bin/bash nova -c "nova-manage cell_v2 create_cell --name cell1"

httpd 재시작

# systemctl restart httpd


Nova 서비스 생성 및 자동실행 등록

# for service in api consoleauth conductor scheduler novncproxy; do
systemctl start openstack-nova-$service
systemctl enable openstack-nova-$service
done


Controller 노드에 Nova 설치가 끝났습니다.

이어서 Compute 노드에 Nova를 설치해야 합니다.


오픈스택 수동 설치 실습 #.8

오픈스택 수동 설치 실습 #.8 - Nova : Compute API


Compute (Nova)



오픈스택 컴퓨트 (Nova)는 IaaS 시스템의 주가 되는 부분인 클라우드 컴퓨팅 패브릭 컨트롤러(fabric controller)입니다. 컴퓨터 자원의 풀을 관리하고 자동화하도록 설계되어 있으며 베어 메탈(Bare metal), 고성능 컴퓨팅(HPC) 구성뿐 아니라 널리 이용 가능한 가상화 기술들과 함께 동작할 수 있습니다. 하이퍼바이저 기술(가상 머신 모니터)로서 KVM, VM웨어, 젠 중 하나를 선택할 수 있으며, 여기에 하이퍼-V 및 LXC와 같은 리눅스 컨테이너 기술을 함께 사용할 수 있습니다.


파이썬으로 작성되어 있으며 Eventlet(병행 프로그래밍용), Kombu(AMQP 통신용), SQLAlchemy(데이터베이스 접속용)와 같은 수많은 외부 라이브러리들을 사용합니다.] 컴퓨트의 아키텍처는 어떠한 사유 하드웨어 및 소프트웨어 요구 사항 없이 표준 하드웨어 위에서 수평적 확장을 하기 위해 설계되어 있으며 레거시 시스템들과 서드파티 기술들과 연동하는 기능을 제공합니다.


기업 수준의 인프라스트럭처로의 통합이 확산되면서 일반적으로 오픈스택의 성능을 모니터링하는 것과 특히 Nova의 성능을 측정하는 것이 규모 면에서 매우 중요한 이슈가 되었습니다. 종단 간 성능을 모니터링하려면 Nova, Keystone, Neutron, Cinder, Swift 등의 서비스로부터 메트릭을 추적하는 것뿐 아니라 메시지 전달을 위해 오픈스택 서비스들이 사용하는 RabbitMQ의 모니터링이 필요합니다.


OpenStack Compute에서는 인증은 OpenStack Identity를 통해, 디스크와 서버 이미지는 OpenStack Image 서비스를 통해, 사용자와 관리자 인터페이스는 OpenStack 대시보드를 통하여 상호작용을 합니다. 이미지 접근은 프로젝트, 사용자에 대해 제한합니다. Quota는 프로젝트당 제한을 말합니다. (예를 들어, 인스턴스 숫자같은...) OpenStack Compute는 표준 하드웨어에서 수평적 확장이 가능하며, 실행하는 인스턴스 이미지를 다운받을 수 있습니다.


OpenStack Compute는 다음 부분과 그에대한 구성 요소로 이뤄져 있습니다.


nova-api 서비스

최종 사용자에 대한 compute API 콜에 대해 허용하고 응답합니다. 이 서비스는 OpenStack Compute API, Amazon EC2 API, 권한이 있는 사용자에 대한 특정 Admin API에 대한 관리 작업을 할 수 있도록 지원합니다. 몇가지 정책을 적용하고, 인스턴스를 실행하는 등의 orchestration 작업을 합니다.


nova-api-metadata 서비스

인스턴스에서의 메타데이터 요청을 허용합니다. nova-api-metadata 서비스는 일반적으로 nova-network 설치할 때와 다중 호스트 모드를 실행할때 사용합니다. 더 자세한 내용은 OpenStack Administrator Guide에서 Metadata service 를 확인합니다.


nova-compute 서비스

Worker 데몬은 가상화 API를 이용하여 가상 머신 인스턴스를 생서하고 종료시킵니다. 예를 들어:

XenServer/XCP에서 사용하는 XenAPI

KVM 또는 QEMU에서 사용하는 libvirt

VMware에서 사용하는 VMwareAPI

이 프로세싱은 상당히 복잡합니다. 기본적으론 데몬이 큐로온 작업을 허용하고 KVM인스턴스를 시스템 명령어로 실행하고, 데이터베이스에 관련 상태값을 업로드합니다.


nova-scheduler 서비스

큐로부터 가상 머신 인스턴스를 요청하고 어떤 compute 서버 호스트에서 실행할 것인지를 결정합니다.


nova-conductor 모듈

nova-compute 서비스와 데이터베이스 상호작용을 중재합니다. nova-compute 서비스에 의해 만들어진 클라우드 데이터베이스에 직접 접근을 제거합니다. nova-conductor 모듈과 수평적인 확장이 가능합니다. 그러나 nova-compute 서비스가 작동중인 노드에서는 배포해서는 안됩니다. 더 자세한 내용은 Configuration Reference Guide 를 확인하십시오.


nova-cert 모듈

X509 인증서에 대한 Nova Cert 서비스를 제공하는 서버 데몬입니다. euca-bundle-image 에 대한 인승서를 생성하여 사용합니다. EC2 API를 사용할때만 필요합니다.


nova-network worker 데몬

nova-compute 서비스에서 유사한 큐에대한 네트워킹 작업을 허용하고 네트워크를 조정합니다. IPtable 규칙을 수정하거나 브리지 인터페이스 설정등 작업을 합니다.


nova-consoleauth 데몬

콘솔 프록시를 제공하는 사용자에 대한 인증 토큰을 제공합니다. nova-novncproxy 와 nova-xvpvncproxy 를 참고 하십시오. 이 서비스는 콘솔 프록시 작업이 작동되고 있어야 합니다. 클러스터 구성에서 nova-consoleauth 서비스에 대한 두 종류 프록시를 실행할 수 있습니다. 자세한 내용은 About nova-consoleauth 를 살펴봅니다. 

  ※ 해당 데몬은 18.0.0 버전인 rocky 버전에서부터는 제거 되었고 더 이상 제공되지 않습니다.


nova-novncproxy 데몬

VNC 연결을 통해 작동중인 인스턴스 접근에 대한 프록시를 제공합니다. 브라우저 기반의 novnc 클라이언틀 제공합니다.


nova-spicehtml5proxy 데몬

SPICE 연결을 통해 작동중인 인스턴스 접근에 대한 프록시를 제공합니다. 브라우저 기반의 HTML5 클라이언트를 제공합니다.


nova-xvpvncproxy 데몬

VNC 연결을 통해 작동중인 인스턴스 접근에 대한 프록시를 제공합니다. OpenStack 만의 Java 클라이언트를 제공합니다.


nova-cert 데몬

x509 인증서.


nova 클라이언트

Tenant 관리자나 최종 사용자가 명령을 제공하는 클라이언트 입니다.


데몬간의 프로세싱 메시지를 전달하기 위한 중앙 허브입니다. 일반적으로 RabbitMQ 로 구현되며, 또한 Zero MQ 와 같은 다른 AMQP 메시징 큐로 구현할 수 있습니다.


SQL 데이터베이스

클라우드 인프라에 대한 구축 동안과 작동중인 상태를 저장합니다. 다음 내용을 포함합니다.

◆ 사용 가능한 인스턴스 타입

◆ 사용중인 인스턴스

◆ 사용 가능한 네트워크

◆ 프로젝트


오픈스택 수동 설치 실습 #.7


오픈스택 수동 설치 실습 #.7 - Glance 설치


오픈스택 이미지(Glance)는 디스크 및 서버 이미지를 위한 검색, 등록, 배급 서비스를 제공합니다. 저장된 이미지들은 템플릿으로 사용이 가능합니다. 수에 제한이 없는 백업본을 저장하고 카탈로그화하는데 사용할 수도 있습니다. 이미지 서비스는 Swift를 포함한 다양한 백엔드에 디스크와 서버 이미지들을 저장할 수 있습니다. 이미지 서비스 API는 디스크 이미지에 관한 정보를 조회하기 위해 표준 REST 인터페이스를 제공하며 클라이언트가 이미지를 새로운 서버에 스트리밍할 수 있게 합니다.



Glance는 기존의 레거시 인프라스트럭처에 수많은 개선 사항을 추가하고 있습니다. 이를테면 VMware와 연동할 경우 Glance는 고가용성 및 동적 자원 스케줄링(DRS)인 vSphere 계열에 대한 고급 기능들을 도입하고 있습니다. vMotion은 하나의 물리적인 서버에서 다른 서버로 서비스 방해 없이 실행 중인 VM의 실시간 마이그레이션을 수행합니다. 그러므로 동적이고 자동화된 자체 최적화 데이터센터를 가능케 하며, 다운타임 없이 성능이 떨어지는 서버들의 하드웨어 유지보수를 허용합니다.


Heat와 같이 이미지와 상호작용이 필요한 다른 오픈스택 모듈들은 Glance를 통해 이미지 메타데이터와 통신해야 합니다. 또한, 노바는 이미지에 대한 정보를 표시할 수 있으며, 인스턴스를 만들기 위한 이미지의 변경 사항을 구성합니다. 한편, Glance는 이미지를 추가, 삭제, 공유, 복제할 수 있는 유일한 모듈입니다.



Glance 설치 준비


SQL DB에 접속하여 glance database 및 유저를 생성합니다. DB계정에 대한 password는 보기 편하게 user와 동일하게 설정 했습니다.

# su - postgres
$ psql

keystone 데이터베이스 및 유저 생성

postgres=# CREATE ROLE glance WITH LOGIN;
postgres=# CREATE DATABASE glance;
postgres=# GRANT ALL PRIVILEGES ON DATABASE glance TO glance;
postgres=# ALTER USER glance WITH ENCRYPTED PASSWORD 'glance';

glance 계정으로 DB 접속이 되나 확인합니다.



keystone 인증을 합니다. 앞으로는 다른 API 모듈을 설치하기 위하여 keystone 인증을 반드시 진행해야 합니다.

# . admin-openrc

glance 유저를 생성합니다

$ openstack user create --domain Default --password-prompt glance


glance 유저에 admin 권한을 추가 해줍니다.

$ openstack role add --project service --user glance admin

이미지 서비스를 생성합니다.

$ openstack service create --name glance \
  --description "OpenStack Image" image


Glance의 endpoint API를 생성합니다.

$ openstack endpoint create --region RegionOne \
  image public https://controller:9292


$ openstack endpoint create --region RegionOne \   image internal http://controller:9292


$ openstack endpoint create --region RegionOne \   image admin http://controller:9292



Glance 설치 및 설정

# yum -y install openstack-glance 

glance-api.conf 파일 수정. <GLANCE_PASS>부분에는 glance의 패스워드를 넣어주세요.

# vi /etc/glance/glance-api.conf

[database]

# ...

connection = postgresql://glance:glance@controller/glance


[keystone_authtoken]

# ...

www_authenticate_uri  = http://controller:5000

auth_url = http://controller:5000

memcached_servers = controller:11211

auth_type = password

project_domain_name = Default

user_domain_name = Default

project_name = service

username = glance

password = <GLANCE_PASS>


[paste_deploy]

# ...

flavor = keystone


[glance_store]

# ...

stores = file,http

default_store = file

filesystem_store_datadir = /var/lib/glance/images/

glance-registry.conf 파일 수정. <GLANCE_PASS>부분에는 glance의 패스워드를 넣어주세요.

# vi /etc/glance/glance-registry.conf

[database]

# ...

connection = postgresql://glance:glance@controller/glance


[keystone_authtoken]

# ...

www_authenticate_uri  = http://controller:5000

auth_url = http://controller:5000

memcached_servers = controller:11211

auth_type = password

project_domain_name = Default

user_domain_name = Default

project_name = service

username = glance

password = <GLANCE_PASS>


[paste_deploy]

# ...

flavor = keystone

Glacne DB에 테이블 설치

# su -s /bin/sh -c "glance-manage db_sync" glance

glance 서비스 생성 및 실행

# systemctl enable openstack-glance-api.service \

  openstack-glance-registry.service

# systemctl start openstack-glance-api.service \

  openstack-glance-registry.service

정상적으로 Glacne API가 설치 되었는지 확인해야 합니다.

Keystone 인증을 불러옵니다.

$ . admin-openrc

glance에 이미지 추가


cirros 이미지 추가

$ wget http://download.cirros-cloud.net/0.4.0/cirros-0.4.0-x86_64-disk.img

$ openstack image create "cirros" \

  --file cirros-0.4.0-x86_64-disk.img \

  --disk-format qcow2 --container-format bare \

  --public

CensOS 7 이미지 추가

$ wget http://cloud.centos.org/centos/7/images/CentOS-7-x86_64-GenericCloud.qcow2

$ openstack image create \

    --container-format bare \

    --disk-format qcow2 \

    --file CentOS-7-x86_64-GenericCloud.qcow2 \

    CentOS-7-x86_64

이미지 리스트 확인

$ openstack image list
+--------------------------------------+-----------------+--------+
| ID                                   | Name            | Status |
+--------------------------------------+-----------------+--------+
| a76a04d2-34ae-4092-94f3-88352bf79783 | CentOS-7-x86_64 | active |
| f0117caf-e764-487c-849d-b464c79efbd0 | cirros          | active |
+--------------------------------------+-----------------+--------+

Glance 설치가 완료 되었습니다.

오픈스택 수동 설치 실습 #.6

오픈스택 수동 설치 실습 #.6 - Keystone 인증 설치


사용자가 대시보드로 오픈스택을 사용할 때 반드시 거쳐야 할 과정이 있는데 바로 인증입니다. 오픈스택에서 Keystone은 모든 서비스를 관장하는 위치에 있습니다. Keystone은 타인이나 해커에게서 시스템을 안전하게 보호하고 사용자 등록, 삭제, 권한 관리, 사용자가 접근할 수 있는 서비스 포인트 관리까지 전반적인 사용자 인증을 관리합니다. 



Keystone 위치를 보면 서비스 백단에서 오픈스택의 모든 서비스를 관장하고 있습니다.



Keystone 설치


SQL DB에 접속하여 keystone database 및 유저를 생성합니다. DB계정에 대한 password는 보기 편하게 user와 동일하게 설정 했습니다. 

# su - postgres

$ psql

keystone 데이터베이스 및 유저 생성

postgres=#create role keystone with login;

postgres=#create database keystone;

postgres=#grant ALL PRIVILEGES ON DATABASE keystone TO keystone;

postgres=#alter user keystone with encrypted password 'keystone';

keystone 계정으로 DB 접속이 되나 확인 합니다.



다시 root로 돌아와서 keystone을 설치합니다.

 # yum -y install openstack-keystone httpd mod_wsgi


keystone.conf 파일 수정

# vi /etc/keystone/keystone.conf

 [database]

# ...

connection = postgresql://keystone:keystone@controller/keystone


[token]

# ...

provider = fernet

지금부터는 tail -f /var/log/keystone/keystone.log 통해 keystone 인증 과정을 확인 할 수 있습니다. log에 Error 메세지가 찍힌다면 어딘가 잘못된 부분이 있는 겁니다. 해당 에러를 확인하고, Error 메세지가 나오지 않게 조치한 후 진행 해야 합니다.


Keystone DB 인증

# su -s /bin/sh -c "keystone-manage db_sync" keystone


Fernet 키 저장소 초기화

# keystone-manage fernet_setup --keystone-user keystone --keystone-group keystone

# keystone-manage credential_setup --keystone-user keystone --keystone-group keystone


인증서비스 bootstrap

※ ADMIN_PASS 에는 admin 계정의 패스워드를 입력해야 합니다.

# keystone-manage bootstrap --bootstrap-password <ADMIN_PASS> \

  --bootstrap-admin-url http://controller:5000/v3/ \

  --bootstrap-internal-url http://controller:5000/v3/ \

  --bootstrap-public-url http://controller:5000/v3/ \

  --bootstrap-region-id RegionOne


httpd server 설정

# vi /etc/httpd/conf/httpd.conf

httpd.conf 내용 편집

 ServerName controller

wsgi-keystone.conf를 httpd 설정 폴더 밑에 링크합니다.

# ln -s /usr/share/keystone/wsgi-keystone.conf /etc/httpd/conf.d/

httpd 서비스 등록 및 시작

# systemctl enable httpd.service

# systemctl start httpd.service


keystone 인증값을 스크립트로 만듭니다.

※ ADMIN_PASS 부분에는 admin 유저의 패스워드를 넣습니다.

# vi admin-openrc

export OS_PROJECT_DOMAIN_NAME=Default

export OS_USER_DOMAIN_NAME=Default

export OS_PROJECT_NAME=admin

export OS_USERNAME=admin

export OS_PASSWORD=<ADMIN_PASS>

export OS_AUTH_URL=http://controller:5000/v3

export OS_IDENTITY_API_VERSION=3

export OS_IMAGE_API_VERSION=2

export PS1="\[\e[36;1m\]\u@\[\e[32;1m\]\h:\[\e[31;1m\]\w(keystone)]# \[\e[0m\]"

인증값을 불러옵니다.




※ httpd status 에서 wsgi를 불러와야 정상입니다.



keystone-manage bootstrap 과정에서 Default domain은 만들어져서 이미 존재합니다. (※ 대문자 주의)


Default Domain 값을 가진 프로젝트 생성

$ openstack project create --domain Default \

  --description "Service Project" service



admin 유저의 인증 토큰 만들기

$ openstack --os-auth-url https://controller:5000/v3 \

  --os-project-domain-name Default --os-user-domain-name Default \

  --os-project-name admin --os-username admin token issue


$ . admin-openrc

$ openstack token issue



Keystone 인증 설치가 완료 되었습니다.

오픈스택 수동 설치 실습 #.5

오픈스택 수동 설치 실습 #.5 - Message Queue, Memcached, etcd


Message Queue 인 RabbitMQ는 Controller 노드에서만 실행됩니다.


RabbitMQ는 간단하게 말하면 표준 AMQP (Advanced Message Queueing Protocol) 메세지 브로커 소프트웨어(message broker software) 오픈소스입니다.


RabbitMQ를 이해하기 위해서는 우선 MQ(Message Queuing)에 대한 이해가 필요합니다. 프로그래밍에서 MQ는 프로세스 또는 프로그램 인스턴스가 데이터를 서로 교환할때 사용하는 방법이죠. 이때 데이터를 교환할때 시스템이 관리하는 메세지 큐를 이용하는 것이 특징입니다. 이렇게 서로 다른 프로세스나 프로그램 사이에 메시지를 교환할때 AMQP(Advanced Message Queueing Protocol)을 이용합니다. AMQP는 메세지 지향 미들웨어를 위한 open standard application layer protocol 입니다. AMQP를 이용하면 다른 벤더 사이에 메세지를 전송하는 것이 가능한데 JMS (Java Message Service)가 API를 제공하는것과 달리 AMQP는 wire-protocol을 제공하는데 이는 octet stream을 이용해서 다른 네트워크 사이에 데이터를 전송할 수 있는 포멧인데 이를 사용합니다. 이러한 복잡한 설명과 달리 RabbitMQ 튜토리얼에서는 RabbitMQ를 매우 간단하게 편지를 작성하여 받는 사람에게 보낼 우체통, 우체국, 우편배달부가 있듯, post box, post office and postman라고 비유적으로 설명하고 있습니다. 


오픈스택에서는 RabbitMQ를 이용하여 각 모듈간의 API 통신을 합니다.


RabbitMQ 설치

# yum -y install rabbitmq-server

# systemctl enable rabbitmq-server.service

# systemctl start rabbitmq-server.service

RABBIT_PASS에는 openstack이 RabbitMQ 사용에 사용할 패스워드를 입력해주시기 바랍니다.

# rabbitmqctl add_user openstack <RABBIT_PASS>


Creating user "openstack" ...
# rabbitmqctl set_permissions openstack ".*" ".*" ".*"


Setting permissions for user "openstack" in vhost "/" ...


Memcached는 controller 노드에서만 실행됩니다.


Memcached는 범용 분산 캐시 시스템입니다. 외부 데이터 소스(예: 데이터베이스나 API)의 읽기 횟수를 줄이기 위해 데이터와 객체들을 RAM에 캐시 처리함으로써 동적 데이터베이스 드리븐 웹사이트의 속도를 높이기 위해 종종 사용됩니다. Memcached는 BSD 허가서로 라이선스되는 자유-오픈 소스 소프트웨어입니다. Memcached는 유닉스 계열 운영 체제(적어도 리눅스와 macOS), 마이크로소프트 윈도우에서 실행되며, libevent 라이브러리에 의존합니다.


Memcached 설치

# yum -y install memcached python-memcached

# vi /etc/sysconfig/memcached


OPTIONS="-l 127.0.0.1,::1,controller".

# systemctl enable memcached.service

# systemctl start memcached.service


etcd는 go언어와 Raft프레임워크 이용해 작성된 오픈소스 key-value 저장소로 대규모 Docker 클러스터링에 있어서 컨테이너들을 유기적으로 연동시키고 억세스하기 위한 세련된 아키텍처를 제공합니다. 좀 더 설명하자면 OS에 배당된 IP어드레스에 비해 탑재된 컨테이너들의 수는 엄청나게 많은데, 이러한 컨터이너들에 접근하기 위해서는 IP어드레스 이외의 효율적인 어드레싱 수단을 필요로 하게 됩니다. etcd는 이러한 어드레싱을 HTTP/JSON을 이용해 구현하고 있으며 빠른 성능과 암호화 제공등으로 현재 Docker 사용자들에게 주목받고 있습니다. 직접 물리서버에 설치도 가능하고, Vagrant,Amazon EC2, Azure, QEMU/KVM, VMware그리고 OpenStack에 이르기까지 요즘 인기있는 가상화/클라우드 플랫폼은 충실하게 지원하고 있습니다. 특히, docker를 이용한 대규모 클러스터링 구현은 vagrant에 의존하지 않고는 무척 고된작업이 되어버릴 것이며, 지금부터 docker를 이용한 클러스터링에 관심을 가지고 사용해 보려는 유저들에게는 익혀두면 크게 도움이 될 것입니다.


etcd 설치

# yum -y install etcd

# vi /etc/etcd/etcd.conf

#[Member]

ETCD_DATA_DIR="/var/lib/etcd/default.etcd"

ETCD_LISTEN_PEER_URLS="http://10.0.0.11:2380"

ETCD_LISTEN_CLIENT_URLS="http://10.0.0.11:2379"

ETCD_NAME="controller"

#[Clustering]

ETCD_INITIAL_ADVERTISE_PEER_URLS="http://10.0.0.11:2380"

ETCD_ADVERTISE_CLIENT_URLS="http://10.0.0.11:2379"

ETCD_INITIAL_CLUSTER="controller=http://10.0.0.11:2380"

ETCD_INITIAL_CLUSTER_TOKEN="etcd-cluster-01"

ETCD_INITIAL_CLUSTER_STATE="new"

# systemctl enable etcd
# systemctl start etcd 



오픈스택 수동 설치 실습 #.4

오픈스택 수동 설치 실습 #.4 - Controller 노드에 PostgreSQL DB 설치


자! openstack.org 공식 문서에도 없는 부분이 왔습니다! 

오픈스택의 공식 설치 문서에는 오픈소스 DB인 MariaDB를 사용해서 설치하는 법이 나와 있습니다. 그러나 오픈스택은 역시 오픈소스 DB인 PostgreSQL도 지원하고 있습니다. 그러나 설치는 사용자의 몫. 아쉽게도 공식 문서에는 PostgreSQL을 사용하여 설치하는 법 따위는 소개 하고 있지 않습니다.


이론적으로 OpenStack Compute는 SQL-Alchemy가 지원하는 모든 데이터베이스를 지원합니다. 일반적으로 테스트에는 SQLite3를 개발작업에는 MySQL, PostgreSQL을 사용합니다.


그러면 왜 저는 PostgreSQL을 설치 하느냐? 일단 제 업무 환경이 Postgres로 구성 되어 있습니다. 두번째, 성능면에서 MariaDB보다 뛰어납니다. 세번째, MariaDB보다 설정이 쉽습니다.



※ SQL DB는 controller 노드에만 설치를 합니다.


PostgreSQL Download 홈페이지


홈페이지에 가서 yum repo를 통해 원하는 버전의 패키지를 내려 받아야 합니다.



저는 9.6 버전을 선택했고, 플랫폼은 CentOS7을 설정했습니다.

설정을 하면 나오는 4번 항목의 주소를 복사해서 controller 노드에서 실행합니다.

# yum -y install https://download.postgresql.org/pub/repos/yum/9.6/redhat/rhel-7-x86_64/pgdg-centos96-9.6-3.noarch.rpm


그리고 postgresql을 yum으로 설치해야 하는데, 오픈스택에서 사용하는 driver인 python-psycopg2를 같이 설치해줘야 합니다.


※ python-psycopg2 패키지는 controller 노드 뿐만 아니라 모든 노드에 설치를 해줘야 controller 노드에 설치되어 있는 DB에 접근 할 수 있습니다.


예전에 원하는 경로에 PostgreSQL을 설치하는 포스팅을 한적이 있는데 (http://db.necoaki.net/225) 오늘은 기본값과 최소한의 설치만 가지고 진행하겠습니다. 

# yum -y install postgresql96 postgresql96-server python-psycopg2


yum으로 설치가 완료되면 DB 클러스터를 구성합니다.


# /usr/pgsql-9.6/bin/postgresql96-setup initdb


그리고 DB가 서버 구동시 자동으로 올라오도록 구성해줍니다.


# systemctl enable postgresql-9.6

# systemctl start postgresql-9.6


그럼 DB가 구동 되었는지 확인하기 위해 su - postgres 하여 유저 변환을 합니다.


root@controller:~]# su - postgres

-bash-4.2$


프롬프트 기본값이 영 보기가 좋지 않네요. .bash_profile을 수정합니다. (안해도 됩니다. 취향입니다...)

$ vi .bash_profile

# .bash_profile


# Get the aliases and functions

if [ -f ~/.bashrc ]; then

        . ~/.bashrc

fi


# User specific environment and startup programs


PATH=$PATH:$HOME/.local/bin:$HOME/bin


export PATH


[ -f /etc/profile ] && source /etc/profile

PGDATA=/var/lib/pgsql/9.6/data

export PGDATA

# If you want to customize your settings,

# Use the file below. This is not overridden

# by the RPMS.

[ -f /var/lib/pgsql/.pgsql_profile ] && source /var/lib/pgsql/.pgsql_profile


export PS1="\[\e[27;1m\]\u@\[\e[32;1m\]\h:\[\e[31;1m\]\w]$ \[\e[0m\]"

export TERM=linux


PATH=$PATH:$HOME/bin:/usr/pgsql-9.6/bin

export PATH


export PSQL_HOME=/var/lib/pgsql


alias vi='vim $*'

프롬프트 설정이 완료 되었고, postgres 마스터 계정의 패스워드를 바꿔줍니다. pg_hba.conf 에서 로컬의 접속도 md5로 변환 해줄 것이기 때문에 미리 바꿔줘야 나중에 마스터 계정으로 접속이 가능합니다.



$ vi $PGDATA/pg_hba.conf


맨 밑으로 내려보면 아래와 같은 설정이 있습니다.

# TYPE  DATABASE        USER            ADDRESS                 METHOD


# "local" is for Unix domain socket connections only

local   all             all                                     peer

# IPv4 local connections:

host    all             all             127.0.0.1/32            ident

# IPv6 local connections:

host    all             all             ::1/128                 ident

# Allow replication connections from localhost, by a user with the

# replication privilege.

#local   replication     postgres                                peer

#host    replication     postgres        127.0.0.1/32            ident

#host    replication     postgres        ::1/128                 ident

다음과 같이 바꿔 줍니다.

# TYPE  DATABASE        USER            ADDRESS                 METHOD


# "local" is for Unix domain socket connections only

#local   all             all                                     peer

local   all             all                                     md5

# IPv4 local connections:

host    all             all             127.0.0.1/32            ident

host    all             all             10.0.0.0/24            md5

# IPv6 local connections:

host    all             all             ::1/128                 ident

# Allow replication connections from localhost, by a user with the

# replication privilege.

#local   replication     postgres                                peer

#host    replication     postgres        127.0.0.1/32            ident

#host    replication     postgres        ::1/128                 ident


postgresql.conf 파일을 열어 리스너 부분의 주석을 해제하고 * 옵션을 줘서 모든 ip에 대해 접속 가능하게 리스너 설정을 합니다.


 $ vi $PGDATA/postgresql.conf

# - Connection Settings -


listen_addresses = '*'                  # what IP address(es) to listen on;

저장 후 DB를 재구동 해줍니다.

$ pg_ctl restart

PostgreSQL DB 설치는 완료 되었습니다.


오픈스택 수동 설치 실습 #.3

오픈스택 설치 실습 #.3 - 사전에 각각의 노드에 준비해야 할 것들


저는 일단 controller, compute1, block1 이렇게 3개의 노드를 준비했습니다.

각각 3개의 노드에 /etc/hosts 파일을 수정해서 넣어주고, 서로간에 Ping이 가는지 확인해 봅시다.


※ controller, compute1, block1 에서 모두 설정

# vi /etc/hosts

# controller

10.0.0.11       controller

# compute1

10.0.0.31       compute1

# block1

10.0.0.41       block1



핑이 잘 갑니다.



NTP 설정하기


CentOS 7 설치시에 NTP 옵션을 준 것을 기억하시나요? 그렇다면 각 서버에는 chrony 데몬이 설치 되어 있을 겁니다. 설치가 안되어 있다면, yum install chrony 명령으로 설치를 해줍니다.


chrony 데몬은 RHEL 7버전부터 선택된 기존의 ntpd를 대체하는 시간 동기화 데몬입니다. 네트워크에서 일시 중단되거나 간헐적으로 연결이 끊어지는 시스템 (모바일 및 가상 서버 등)에 가장 적합한 데몬입니다.


▶ chrony의 장점


1) 24 시간 운영되지 않는 데스크톱이나 시스템에서 유용하게 사용되는 시간 및 주파수 오류를 최소화하기 위해 시간 대신 단 몇 분만에 빠른 동기화가 가능합니다. 

2) 클록 주파수의 급격한 변화에 대한보다 나은 대응은 클록 주파수가 불안정한 가상 머신이나 클럭 주파수를 일정하게 유지하지 않는 절전 기술에 유용합니다. 

3) 초기 동기화 후에는 시스템 시간을 필요로하는 응용 프로그램에 영향을 미치지 않도록 시계를 단계별로 조정하지 마십시오. 

4) 일시적인 비대칭 지연을 처리 할 때 안정성이 좋아집니다 (예 : 링크가 대량 다운로드로 포화 된 경우). 

5) 주기적으로 서버를 폴링 할 필요가 없으므로 네트워크 연결이 간헐적으로 연결된 시스템은 여전히 ​​신속하게 클록을 동기화 할 수 있습니다. 


chrony 데몬을 통해 controller 노드는 NTP 서버에서 시간을 가져오고, 각각의 노드는 controller 노드에서 시간을 가져오게 끔 설정합니다.


chrony.conf 파일을 열어 해당 부분의 주석을 제거하고 값을 수정합니다.


※ controller 에서 설정

# vi /etc/chrony.conf


.

.

.

# Allow NTP client access from local network.

allow 10.0.0.0/24

.

.

.


※ compute1, block1 각각의 노드에서 설정

# vi /etc/chrony.conf


.

#server 0.centos.pool.ntp.org iburst #server 1.centos.pool.ntp.org iburst #server 2.centos.pool.ntp.org iburst #server 3.centos.pool.ntp.org iburst server controller iburst

.

.

.


※ 모든 노드에서 실행

# systemctl enable chronyd.service
# systemctl restart chronyd.service

설정이 완료되면 각각의 노드에서 chronyc sources 명령을 통해 확인 할 수 있습니다.



controller 노드는 ntp 서버에서, 각각의 노드는 controller 노드에서 시간을 받아오는 걸 확인 할 수 있습니다.



오픈스택 패키지 설치하기


※ 모든 노드에서 실행 (controller, compute1, block1 )

# yum install centos-release-openstack-rocky

# yum upgrade

# yum install python-openstackclient

# yum install openstack-selinux


이제 오픈스택 설치 준비가 완료 되었습니다.

오픈스택 수동 설치 실습 #.2


오픈스택 수동 설치 실습 #.2 - 네트워크 구성에 대한 이해


 

오픈스택을 처음 설치 하는 분들이 이 부분을 처음에 안 짚고 가면 나중에 Neutron 설치 부분에서 멘붕이 올 수 있습니다. 

네트워크를 어떻게 해야하지? 라는 의문이 들겁니다.



본 네트워크 레이아웃은 가장 최소한의 네트워크 레이아웃 입니다.

그런데 Neutron을 설치하면서 두 가지 상황을 마주하게 됩니다. Provider Network와 Self-service Network 구성입니다.



네트워크의 종류


Management Network - 각 요소 간 네트워크입니다. 서로 API를 호출하는데 사용합니다. Compute, Network, Control Node, 그리고 스토리지와 연결되어 있습니다.


Private Network - VM의 네트워크를 구성하는데 사용하는 네트워크입니다. GRE, VxLAN 등의 기술이 사용됩니다. Compute, Network Node 간에 연결되어 있습니다. 이 Private Network는 Tunnel Network, Overlay Network, VM Data Network 등으로 불리기도 합니다.


Storage Network - 블록 스토리지용 네트워크로 Compute Node와 스토리지 간에 연결되어 있습니다.


External Network - Horizon 접속 또는 유저들이 VM에 접속하기 위한 네트워크로 Network 및 Control Node 간에 연결되어 있습니다.


그런데 네트워크를 Neutron 상에서 설정하기 위한 방식으로 나눌 수도 있습니다.


Provider Network - 서비스하는 사람이 구축한 네트워크라는 의미에서 "Provider Network"입니다. 이 네트워크는 인터넷에 연결되어 있는 네트워크입니다. 그래서 앞서 이야기한 External Network에 대응합니다.


Self-Service Network - 사용자가 직접 VM을 위해 구축한 네트워크입니다. Provider Network을 기반으로 GRE, VxLAN 등의 터널링을 통해 구축합니다.



그럼 두 가지 레이아웃을 비교 해봅시다.


뭔가 다르죠?

Open vSwitch가 구성 되게 되면 가상의 스위치가 노드에 생성되게 됩니다.

랜포트는 하나지만, 하나의 랜포트를 통해 여러개의 NIC가 서비스 될수 있는 겁니다.


Self-service Network는 터널링 구성을 통해서 Compute 노드가 생성한 vm들끼리 통신을 할수 있고, 사설 IP 대역을 이용하면서 공인 IP의 사용을 줄일수 있며, Floating IP 구성을 하여 외부 인터넷 망과도 통신을 할 수 있습니다. Floating 설정이 없으면 터널링 네트워크는 클라우드 내부에서만 통신이 가능합니다.


어떻게 네트워크를 구성 할 것인가는 사전 기획 단계에서 충분히 논의 되어져야 하고, 실습 환경에서는 원하시는대로 진행 하시면 됩니다.





오픈스택 수동 설치 실습 #.1


오픈스택 수동 설치 실습 #.1 - OS 준비


일단 오픈스택을 수동으로 설치를 해보면 오픈스택을 이해하기에 조금 더 도움이 됩니다. 그러니 VM 환경에다가 구축 실습을 해봅니다. 설치 버전은 rocky 버전으로 가장 최신 버전이며, 설치하면서 부분 부분 설명을 가미 해보도록 하겠습니다.


https://docs.openstack.org/rocky/install/


해당 공식 설치 문서를 참고하여 진행합니다.



CentOS 7 버전을 이용해 OS를 준비해 보겠습니다.


하드웨어 설정에 controller 노드의 용량은 RAM 4GB, HDD 50GB 입니다.

compute 노드는 RAM 2GB, HDD 50GB 입니다.




보안 정책을 꺼줍니다.



KDUMP도 꺼버립니다.



NIC 설정입니다.

ens32는 Bridge 네트워크로 Provider Network가 될 부분입니다. DHCP로 놔두어도 상관 없습니다.






ens33은 NAT로 구성했습니다.

VM의 네트워크 매니저에서 10.0.0.0/24 대역으로 구성했습니다. Management Network로 구성될 부분입니다.






파티션은 원하는대로 설정해도 되고, 그냥 기본으로 설치해도 됩니다.

용량은 50GB 할당 했습니다.



네트워크 통신이 된다면 NTP도 되겠죠?



설치 되는 동안 ROOT의 패스워드를 설정해주고 완료 되면, Reboot 합니다.




미니멀로 설치 했기 때문에 터미널 모드로 부팅합니다.

편한 작업을 위한 SSH 설정을 위해 sshd_config 파일을 수정해 줍니다.

 # vi /etc/ssh/sshd_config

PermitRootLogin yes

해당 부분 주석 해제

 # vi /etc/selinux/config

SELINUX=disable

이 부분은 선택입니다. 오픈스택은 SELINUX를 사용해 보안 설정을 할 수 있기 때문에 사용하기도 합니다. 그런데 저는 MariaDB가 아닌 PostgreSQL을 기본 DB로 선택할 것이기 때문에 SELINUX가 PostgreSQL에서 문제가 발생 할 수있는 여지가 있어 해제하고 설치를 진행합니다.


 # yum -y install net-tools vim

ifconfig 같은 명령이나 vim이 없기 때문에 설치를 진행 합니다.



프로파일을 수정합니다.

# vi .bash_profile 

아래 항목을 추가해서 노드가 헷갈리지 않게 합니다.

그리고 기본 에디터를 vim으로 사용하기 위해 설정을 해줍니다.

export PS1="\[\e[36;1m\]\u@\[\e[32;1m\]\h:\[\e[31;1m\]\w]# \[\e[0m\]"

export TERM=linux

alias vi='vim $*'

그리고 SELINUX 설정을 적용하기 위해 재부팅을 한번 해줍니다.


Controller Node의 준비가 끝났습니다.


이와 같은 방식으로 Compute Node와 Block Storage Node, Network Node를 준비하시면 됩니다.

Block Storage Node와 Network Node는 옵션입니다. 최소 controller와 compute만 있어도 설치는 가능합니다.

VM을 복사해서 hostname과 ip를 바꿔서 만들어도 상관 없습니다.



.bash_profile의 프롬프트 설정 부분의 가운데 숫자 (export PS1 .... 32->33) 변경하니 노드의 색이 바뀌었습니다. 

두 노드를 왔다 갔다 하면서도 쉽게 구분 할수 있겠죠?

오픈스택의 아키텍처 맵

오픈스택의 아키텍처 맵



openstack.org에 가면 확인할수 있는 맵 파일 입니다.

전체적인 큰 그림을 머릿속에 넣어두고 시작해 봅시다.

Git Bash



윈도우용 Bash 쉘이 포함된 Git 입니다.


개발하거나 리눅스가 편리하시분들 윈도우에서도 Bash 명령을 이용해 작업을 할 수 있습니다.

putty 대용으로도 사용 할 수 있고, grep을 이용해 로그의 특정 부분을 긁어 모으거나 vi가 편하신분들에게 유용합니다.


원출처는 https://gitforwindows.org/



pwd를 치면 기본 홈은 /c/user/{$사용자} 입니다.


CMD창도 git 스타일로 이용할 수 있습니다.


Git-2.20.1-64-bit.zip

Git-2.20.1-64-bit.z01

Git-2.20.1-64-bit.z02

Git-2.20.1-64-bit.z03

Git-2.20.1-64-bit.z04



클라우드 컴퓨팅에서 데이터베이스 전문가의 방향

클라우드 컴퓨팅에서 데이터베이스 전문가의 방향



  지금까지 오라클 데이터베이스 엔지니어로 10년 가까이 일해 왔지만, 앞으로 오라클만 할 줄 아는 DB 엔지니어 혹은 DBA는 시장에서 살아 남기가 힘들거라고 예상을 하고 있습니다. 장비가 가격이 내리고, 성능이 좋아져서 SQL 쿼리 튜닝에 투자하는 비용이 점점 줄어들고 있어 튜너들이 설자리가 점점 없어지고 있습니다. 또, 오라클의 비싼 라이센스 정책에 반하여 기업들은 어떻게든 비용 절감을 위해 오픈 소스를 도입한다거나, 클라우드를 구축한다거나, 아니면 다른 회사가 제공하는 클라우드 플랫폼을 이용하는 경우도 있습니다. 

 

 물론 오라클의 안정성과 성능은 인정합니다. 하지만 지금 시대는 예전에 오라클을 대체하지 못하던 시절과 많이 다릅니다. 오픈소스 DB의 대표적인 DB인 PostgreSQL의 성능은 이미 오라클의 바짝 뒤쫓고 있으며, 오픈 소스인 만큼 가격적인 측면에서 뛰어난 가성비를 제공합니다. EDB 같은 업체를 통해 PPAS의 유지보수 기술지원도 제공 받을수 있으며, 그 비용이 오라클과의 유지보수 계약에 비하면 정말 싼편이기 때문에, 이젠 충분히 대체 선택을 할 만하다고 생각합니다. 




 또, 앞으로는 DB 시장이 빅데이터와 클라우드를 중심으로 움직일 것이기에 HPE에서도 하드웨어 시장에 집중하기 보다는 빅데이터 분석을 위한 데이터베이스인 Vertica 같은 회사의 제품을 인수하여 시장에 내놓고 있으며, 새로운 환경에 특화된 데이터베이스들이 많이 나오고 있습니다. 오픈소스 기반의 DB들도 빠른 속도로 발전하고 있으며, 빅데이터에 특화 되어 있거나, 클라우드의 컨테이너 환경에 더 어울리는 DB가 발전 가능성이 크고 좀 더 많은 사용자가 유입 될 것이라고 예상합니다.


 클라우드 환경에서는 자체적으로 이중화 삼중화가 되어 있기 때문에, 오라클 같은 RAC 환경의 Active-Active 구성이 아니더라도, DB가 설치된 VM이 장애가 발생하더라도, 시스템이 자동으로 다른 컴퓨트 노드에 동일한 VM을 구동시켜 빠르게 장애 상황을 대체 할 수 있습니다. 이러한 기술은 RAC에 들어가는 라이선스와 장비의 비용 절감 효과가 엄청나기 때문에 기업 입장에서는 구미가 당길수 밖에 없는 상황이죠.



 DB의 부하가 걸려 자원이 더 필요한 상황이 오더라도, 스케일아웃을 통해 자동으로 노드를 추가하여 VM들의 클러스터링 통해 성능을 높일수 있고, 또 부하가 줄어든 시점에 자동으로 노드를 제거하여, 자원 효율을 극대화 시킬 수도 있습니다. 일반적인 상황에서 스케일아웃은 하드웨어 장비가 들고, 상면 랙이 늘고 하는 상황이 발생하지만, 클라우드 환경에서는 VM만 늘어나면 되기에 관리도 어렵지 않고, 필요없는 자원에 대한 회수도 용이합니다. 




 요즘은 MS도 자사의 클라우드 플랫폼인 Azure에 대한 홍보를 적극적으로 하고 있죠. 클라우드 환경에서의 관계형 DB로 시장이 크게 넘어가고 있는 중입니다. 당장 하던일을 그만 두라는 것은 아니지만, 계속 IT쪽에서 일을 해야 한다면, 앞으로 다가올 미래에 대한 대비 정도는 해야하지 않을까 생각해 봅니다.


클라우드 컴퓨팅이란?


클라우드 컴퓨팅이란?


 클라우드 컴퓨팅이란 이미 많은 해외기업들이 시장에 도입하였고, 앞으로 많은 IT 인프라 구축 및 개발에 있어 기본적인 기반 기술로 사용될 기술을 의미합니다. 클라우드 컴퓨팅의 대표적인 장점 3가지를 말해보고자 합니다.




 자원의 효율성


 기존에는 각자 업무에 맞는 장비 (ex 서버, PC)등을 프로젝트나 부서별로 구매하여 해당 자원을 하나의 용도로 사용하였습니다. 그러다보니 자원이 부족한 경우에는 필요한 추가 자원의 분석과 자원을 구매하기 위한 결재를 받는 절차를 거쳐, 제품을 구매하여 추가 증축하는 등의 단계를 거치는 어려움이 있고, 또 반대로 자원이 남는 경우는 기존의 사용 요소위에 다른 서비스를 올려 활용하는 방안등은 보안이나 효율적인 면에서 좋지 않기 때문에 남는 자원을 방치 할 수 밖에 없었습니다.

 클라우드 컴퓨팅은 이러한 단점을 보완하고, 빠르고 유연하게 다양한 구성원의 니즈에 맞춰 서비스를 제공할 수 있는 기반 기술입니다. 쉽게 말하자면 아주 거대한 VM 환경을 구축하는 것인데, 소비자가 원하는 만큼 자원을 구성하여 서비스 할 수 있으며, 사용자가 사용중에 자원이 부족한 경우 스케일아웃(scale-out)을 통해 빠르게 자원을 확장하고, SDN을 통해 트래픽을 분산시킬수 있습니다. 거대한 자원풀에서 자동으로 사용량이 많은 노드에 자원을 공급하고, 사용량이 많지 않은 쪽은 자원을 줄여 필요한 곳에 적절한 양의 자원을 사용하여 자원의 효율성을 높일수 있습니다.




 민첩성


 예전에는 회사의 한 부서에서 필요한 시스템을 구축하기 위해, 전문들에게 컨설팅을 받고, 기존의 사용량을 분석하거나, 제품 결정 및 구매 결재등에 많은 시간을 투자해야 했습니다.  클라우드 컴퓨팅안에서는 사용자가 요청하는 즉시 포탈을 통해 자원을 할당 받을수 있으며 컨테이너, 도커의 활용을 통해 운영 환경과 같은 개발 환경도 즉시 제공 받을수 있습니다. 이런 시스템은 새로운 상품을 개발 할때에도 시간을 단축시키고, 시장 진입의 시간을 앞당기는 효과를 가져올수 있습니다.




 오토메이션


 클라우드 컴퓨팅에는 다양한 자동화 기술이 있습니다. 사용자가 직접 포탈에 사용 신청을 하면, 컴퓨트 노드는 필요한 만큼 개인에게 VM을 할당합니다. 필요한 양을 분석하고 장비를 구매하여 구축하고 서비스 도입하던 예전 방식에 비해 너무나 빠른 시간안에 환경이 갖추어 지는 것이죠. 심지어는 필요한 어플리케이션이나 미들웨어, 운영체제까지 모두 설치된 상태로 사용자에게 배포됩니다. Kubernetes 같은 툴을 이용해 도커를 관리하고 만들며, Kolla-Ansible을 이용해 빠르게 배포하고 모든 업무 처리를 자동화 시킵니다. 운영하는데 있어 효율적이고 빠른 업무진행이 가능해 지는 겁니다.


물론 이 밖에도 더 많은 장점이 있습니다. 인프라 자원을 표준화 시켜 운영의 효율성을 높일 수 있고, 비용 절감에도 효과가 있습니다.


PostgreSQL 테이블스페이스 및 오브젝트 사용량 확인



PostgreSQL 테이블스페이스 및 오브젝트 사용량 확인

 - 테이블스페이스 총량

  postgres=# select spcname, pg_size_pretty(pg_tablespace_size(spcname)) from pg_tablespace;


 - Table Size (Index 미포함)

 postgres=# select pg_relation_size('TableName');


 - Table Size (Index 포함) 

 postgres=# select pg_total_relation_size('TableName');


 - Index size

 postgres=# select pg_relation_size('IndexName');

 

 - Total Size ( 데이터 + 인덱스)

 postgres=# select pg_total_relation_size('TableName');


 ※ 단위적용 - pg_size_pretty()


 - DB Size

 postgres=# select pg_size_pretty(pg_database_size('DBName'));

PostgreSQL 백업 및 복원



PostgreSQL 백업 및 복원


 - PostgreSQL 데이터를 백업하는 3가지 방법

 

 1. SQL 덤프

 2. 파일 시스템 레벨 백업

 3. 연속 아카이빙


 

1. SQL 덤프


pg_dump 사용


 덤프 백업


 $ pg_dump dbname > outfile


 - pg_dump 는 최신 버전에서 다시 로드 할 수 있습니다.

 - 32bit -> 64bit 서버로 이동할 수 있는 유일한 방법입니다.

 - 한번에 하나의 데이터베이스만 백업 가능합니다.


 덤프 복원


 $ psql dbname < infile


 - 새로운 환경에서 복원하게 되면 dbname 부분의 들어가는 데이터베이스가 자동으로 생성 되지 않기 때문에, 미리 사용자가 같은 이름의 데이터베이스를 생성 해줘야 합니다.

 - SQL 덤프를 복원하기 전에 덤프된 데이터베이스의 개체를 소유하고 있거나 개체에 대한 권한이 부여된 모든 사용자가 이미 존재해야 합니다.

 - 덤프 복원은 에러가 나도 계속 진행하기 때문에 --set ON_ERROR_STOP=on 옵션을 주면 에러 발생시 psql을 종료하게 할 수 있습니다.

 - pg_dump로 생성된 덤프는 template0에 상대적입니다. 이것은 template1을 통해 추가된 언어, 프로시저 등도 pg_dump에 의해 덤프된다는 것을 의미합니다. 결과적으로 복원시, 커스터마이즈된 template1을 사용하는 경우 template0으로부터 비어있는 데이터베이스를 생성해야 합니다. 

 - 파이프에 쓰거나, 파이프에서 읽어 오는 pg_dump 및 psql의 기능은 데이터베이스를 특정 서버에서 다른 서버로 직접 덤프를 가능하게 합니다.


 $ pg_dump -h host1 dbname | psql -h host2 dbname



pg_dumpall 사용


 - pg_dump는 한 번에 하나의 데이터베이스만 덤프하며, role 또는 테이블스페이스에 대한 정보는 덤프하지 않습니다. 


 백업

 

 $ pg_dumpall > outfile


 복원


 $ psql -f infile postgres


 - 실제로 시작한 기존 데이터베이스 이름을 지정할 수 있지만 비어있는 클러스터로 로딩한 경우 postgres를 일반적으로 사용해야 합니다.

 - 클러스터 차원의 데이터는 pg_dumpall --globals-only 옵션을 사용하여 단독 덤프가 가능합니다.



거대 데이터베이스 처리


 - 일부 운영체제는 거대 pg_dump 출력 파일을 생성할 때 최대 파일 크기 제한이 있습니다. pg_dump는 표준 출력으로 사용할 수 있어, 유닉스 툴로 이런 문제의 가능성을 피할 수 있습니다.


 ◆ 압축 덤프 사용

  

  gzip을 이용한 덤프

  $ pg_dump dbnam | gzip > filename.gz


  리로드

  $ gunzip -c filename.gz | psql dbname


 ◆ split 사용

  

  1GB 단위로 분할 백업

  $ pg_dump dbname | split -b 1024m - filename


  리로드

  $ cat filename* | psql dbname


 ◆ pg_dump의 커스텀 덤프 형식 사용

  

  - 설치된 zlib 압축 라이르러리를 사용하여 PostgreSQL을 시스템에서 빌드한 경우 출력 파일에 쓸 때 커스텀 덤프 형식이 데이터를 압축합니다.

 - 덤프파일 크기는 gzip과 비슷하지만 테이블을 선택적으로 복원할 수 있다는 장점이 있습니다.


  백업

  $ pg_dump -Fc dbname > filename


  복원 : psql이 아닌 pg_restore를 이용해 복원합니다.

  $ pg_restore -d dbname filename


 ◆ pg_dump의 병렬 덤프 기능 사용


  - 거대 데이터베이스의 덤프 속도를 높이기 위하여 병렬 모드를 사용할 수 있습니다.

  - 병렬 덤프는 "디렉토리" 아카이브 형식에 대해서만 지원합니다.

 

 백업

 $ pg_dump -j <number> -F d -f out.dir dbname


 복원

 pg_resote -j 를 이용하여 복원 할 수 있습니다.




2. 파일 시스템 레벨 백업


 - 시스템 레벨에서 백업을 하는 것인데, 정상적인 백업을 위해서는 반드시 DB를 shutdown 해야 합니다. 복원도 마찬가지.


 tar -cf backup.tar /usr/local/pgsql/data


 - 파일 시스템 백업은 전체 데이터베이스 클러스터의 완전한 백업 및 복원에 대해서만 동작합니다.



 

3. 연속 아카이빙 및 PITR


 - PostgreSQL은 클러스터의 데이터 디렉토리의 pg_xlog/ 서브 디렉토리에 WAL를 항상 유지관리합니다. 이 로그에는 데이터 파일에서 일어난 모든 변경 내용이 기록 됩니다.

 - 복구가 필요한 경우, 파일 시스템 백업을 복원한 이후, 백업된 WAL 파일로부터 리플레이로 시스템을 현재 상태로 불러옵니다. (오라클 Hot backup 복원 후 archive 적용하는 것과 비슷한 개념입니다.)

 - 일반 파일 시스템 백업과 마찬가지로, 전체 데이터베이스 클러스터 복원만 지원합니다.


 베이스 백업


 - pg_base 를 이용한 백업

 

 1) WAL 아카이빙이 활성화 되어 있는지 확인한다.

 2) 슈퍼유저로 데이터베이스에 연결하고 다음 명령을 실행한다.

   SELECT pg_start_backup('label');

   여기서 label은 백업 작업의 식별을 위한 string이다.

   기본적으로 pg_start_backup은 완료 되는데 체크포인트를 수행하기 때문에 시간이 오래걸린다.

   백업을 가능한 빨리 시작하고 싶다면, 다음을 사용하는 것이 좋다.

   SELECT pg_start_backup('label',ture);

   체크포인트를 강제한다.

 3) tar 또는 cpio 같은 편리한 파일 시스템 백업툴을 사용하여 백업을 수행한다.

 4) 슈퍼유저로 데이터베이스에 접속후에 명령을 실행한다.

   SELECT pg_stop_backup();

 5) 백업을 아카이브 하는 중에 WAL 세그먼트가 활성화 되면 백업이 끝이 난다.

 

 ※ 오라클 Hot backup과 동일한 개념으로 보면 됩니다.


 연속 아카이브 백업을 사용한 복구


 1) 서버가 실행중인 경우 서버를 중지한다.

 2) 공간에 여유가 잇는 경우 필요할 때를 대비하여 전체 클러스터 데이터 디렉토리와 테이블스페이스를 임시 위치에 복사한다. 시스템 다운 정에 아카이브되지 않은 로그가 포함되었을 수 있는 클러스터의 pg_xlog 서브디렉토리의 내용을 최소한이라도 따로 저장해두어야 한다.

 3) 사용 중인 클러스터 데이터 디렉토리 아래 및 데이블스페이스의 root 디렉토리 아래의 모든 기본 파일 및 서브 디렉토리를 삭제한다.

 4) 데이터베이스 파일을 파일 시스템 백업으로 부터 복원한다. 올바른 소유권 확인 및 pg_tblspc의 심볼릭 링크가 바른지 확인.

 5) pg_xlog/ 밑에 오래된 파일 시스템 백업에서 온 로그를 삭제한다.

 6) pg_xlog/ 2단계에서 저장된 아카이브되지 않은 WAL 세그먼트 파일이 있을 경우 pg_xlog/에 복사한다.

 7) 클러스터 데이터 디렉토리에서 복구 명령 파일 recovery.conf를 생성한다. pg_hba.conf를 수정하여 복구하는 동안 접속을 막는다.

 8) 서버를 시작한다. 서버가 복구모드로 들어가고 아카이브된 WAL 파일을 통해 읽기가 진행 된다. 복구가 완료 되면 recovery.conf의 이름을 recovey.done 으로 변경하고 다시 복구 모드로 들어가지 않게 바꿔준다.

 9) 데이터베이스의 내용을 확인하고 pg_hba.conf 를 복원하여 사용자 연결을 확인한다.


※ recovery.conf


 예제 파일. /usr/pgsql-9.6/share/recovery.conf.sample을 이용하여 만들수 있다.


 아카이브 복구 설정


 restore_command (string)

  - WAL 파일 시리즈의 아카이브된 세그먼트의 검색을 실행하는 로컬 쉘 명령.

  - 아카이브 복구에 필요하지만 스트리밍 복제의 경우는 옵션.

  - string의 %f 는 아카이브에서 검색할 파일 이름으로 교체되고, %p 는 서버의 복사 대상 경로로 교체된다.

 

    restore_command = 'cp /data/pgsql/archvie/%f "%p"'


 archive_cleanup_command (string)

  -모든 restartingpoint에서 실행되는 쉘 명령을 지정한다.

  - 스탠바이 서버에서 더 이상 필요로 하지 않는 오래된 아카이브 WAL 파일을 클린업하는 메카니즘을 제공하는 것.

  - %r 은 마지막 유효 재시작 지점이 있는 파일의 이름으로 교체된다.

  

   archive_cleanup_command = 'pg_archivecleanup /data/pgsql/archive %r'


 recovery_end_command (string)

  - 복구 종료 시에 한 번만 실행되는 쉘 명령을 지정한다. 이 매개변수는 옵션이다.


복구 타깃 설정


recovery_target = 'immediate'

  - 온라인 백업에서 복원하는 경우 이것은 백업이 종료된 지점을 의미한다.

  - 현재 다른 매개변수는 없다.


recovery_target_name (string)

  - 이 매개변수는 지명된 복원 지점(pg_create_restore_point()를 사용하여 생성)을 복구가 진행되는 지점으로 지정.


recovery_target_time (timestamp)

  - 이 매개변수는 타임스탬프를 복구가 진행되는 지점으로 지정한다.

  - 정밀한 정지 지점은 recovery_target_inclusive의 영향도 받는다


recovery_target_xid (string)

  - 트랜잭션 ID를 복구가 진행되는 지점으로 지정한다.

  - 복구되는 트랜잭션은 지정된 것 이전에 커밋된 트랜잭션이다.


다음 옵션은 복구 타깃을 추가로 지정하며, 타깃에 도달 했을때, 발생하는 것에 영향을 끼친다.


recovery_target_inclusive (boolean)

  - 지정된 복구 타깃 직후에 중지 할 것인지, 직전에 중지 할 것인지 지정한다.

  - 기본값은 ture.


recovery_target_timeline (string)

  - 특정한 타임라인으로의 복구를 지정한다.

  - 기본값은 베이스 백업을 가져왔을 때 현재였던 동일한 타임라인을 따라 복구하는 것이다.

  - 이것을 lastest로 설정하면 아카이브의 최신 타임라인으로 복구 되며, 스탠바이 서버에 유용하다.

 







PostgreSQL 로컬라이제이션



PostgreSQL 로컬라이제이션


 - 로케일 지원은 initdb를 이용해 클러스터를 구성하면 자동으로 초기화 됩니다. 

 - 특별히 옵션을 넣지 않으면 en_US.UTF8로 설정이 됩니다.

 

 LC_COLLATE

 String 정렬 순서

 LC_CTYPE

 문자 분류 (어떤글자인지, 대문자도 동일한지)

 LC_MESSAGES

 메세지 언어

 LC_MONETARY

 통화 형식

 LC_NUMERIC

 숫자 형식

 LC_TIME

 날짜 및 시간 형식


 예)

 로케일을 한국으로 설정하되 통화 형식은 달러를 쓴다면,

 initdb --locale=ko_KR --lc-monetary=en_US 로 클러스터를 구성하면 됩니다.


 - 시스템에 로케일 지원이 안되는 것처럼 하고 싶으면 특수한 로케일 이름인 C 또는 동등하게 POSIX를 사용해야 합니다.

 - 일부 로케일 카테고리는 데이터베이스가 생성될 때 고정된 값이어야 합니다. 

 - 서로 다른 데이터베이스에 대해 서로 다른 설정을 사용할 수는 있지만, 데이터베이스가 생성된 다음에는 설정을 변경 할 수 없습니다.

 - 인덱스 정렬 순서에 영향을 미치므로 고정된 상태로 유지되어야 하며, 데이터베이스 운영 중 변경하면 인덱스 손상이 발생합니다.

 - initdb 에서 선택된 값은 postgresql.conf에 작성되어 서버 시작시 기본값으로 사용됩니다. 이 값을 postgresql.conf에서 제거하면 서버가 실행 환경에서 설정을 상속 받습니다.

 - 리눅스가 처음부터 ko_KR.UTF8로 설정 되어 있다먼, initdb 시 옵션을 넣지 않아도 ko_KR.UTF8로 설정됩니다.



※ 로케일 설정은 다음과 같은 SQL 기능에 영향을 줍니다.


 1. order by를 사용한 쿼리에서 정령 순서 또는 텍스트 데이터에서 표준 비교 연산자

 2. upper 및 lower, initcap 함수

 3. 패턴 일치 연산자 (LIKE, SIMILAR TO 및 POSIX 스타일 정규식). 대소문자 비 구분 일치 및 문자 클래스 정규식에 의한 문자 분류에 모두 영향을 미치는 로케일.

 4. TO_CHAR 계열 함수

 5. LIKE 절을 사용한 인덱스 사용 능력


 - PostgreSQL에서 C 또는 POSIX가 아닌 다른 로케일을 사용할 때의 단점은 성능입니다. 문자 처리가 느려지고 LIKE에서 사용 되는 일반 인덱스를 사용하지 못합니다. 이러한 이유로, 실제로 필요한 경우에만 로케일을 사용해야 합니다.


※ 이미 클러스터를 구성해서 운영중인데 다른 언어셋이 필요하다면, create database 명령에서 로케일 옵션을 변경해서 생성 할 수 있습니다.


postgres=# create database test_kr

with

template=template0

encoding='EUC_KR'

LC_COLLATE='POSIX'

LC_CTYPE='ko_KR.euckr'

tablespace=test_kr

connection limit=999;

CREATE DATABASE

postgres=# \l

                                  List of databases

   Name    |   Owner   | Encoding |   Collate   |    Ctype    |   Access privileges   

-----------+-----------+----------+-------------+-------------+-----------------------

 postgres  | postgres  | UTF8     | en_US.UTF-8 | en_US.UTF-8 | 

 template0 | postgres  | UTF8     | en_US.UTF-8 | en_US.UTF-8 | =c/postgres          +

           |           |          |             |             | postgres=CTc/postgres

 template1 | postgres  | UTF8     | en_US.UTF-8 | en_US.UTF-8 | =c/postgres          +

           |           |          |             |             | postgres=CTc/postgres

 test_kr   | postgres  | EUC_KR   | C           | ko_KR.euckr | 

 testdb    | test_user | UTF8     | en_US.UTF-8 | en_US.UTF-8 | 

(5 rows)



 - C가 아닌 로케일 하에서 LIKE 절을 사용한 인덱스를 PostgreSQL이 이용하려면 몇 가지 커스텀 연산자 클래스가 존재해야 합니다. 이것은 로케일 비교 규칙은 무시하면서 엄격한 문자별 비교를 수행하는 인덱스의 생성을 허용합니다. 다른 방법은 C 콜레이션을 사용하여 인덱스를 생성하는 것입니다.

PostgreSQL 데이터베이스 Role



PostgreSQL 데이터베이스 Role


 - PostgreSQL은 role 이라는 개념을 사용하여 데이터베이스 액세스 권한을 관리합니다.

 - role의 개념은 "사용자" 및 "그룹"의 개념을 포함합니다.

 - 데이터베이스 role은 운영체제 사용자와는 다른 개념입니다.

 - 특정 데이터베이스 연결에 사용할 role 이름은 애플리케이션 특정 방식의 연결 요청을 초기화하는 클라이언트에 의해 표시됩니다. 예를들면, psql 프로그램은 -U 옵션을 사용하여 연결한 role을 표시합니다. 다수의 애플리케이션이 기본적으로 현재 운영체제 시스템 사용자의 이름을 가정합니다. (createuser 및 psql 포함) 따라서 role 및 운영체제 사용자 간에 네이밍 연관성을 유지하는 것이 편리합니다.

 - 오라클 처럼 user와 role이 분리된 개념이 아니라, user=role 느낌으로 사용됩니다. 



role 생성


postgres=#CREATE ROLE [name];


role 삭제


postgres=# DROP ROLE [name];


role 확인


postgres=# \du

postgres=# select rolname from pg_roles;




※ role  속성


 - 로그인 권한 :

 postgres=# CREATE ROLE [name] LOGIN;

 postgres=# CREATE ROLE [name];


 Login 속성이 있는 role은 "데이터베이스 사용자"와 동일한 것으로 간주 될 수 있습니다.

 CREATE USER는 디폴트로 LOGIN 권한을 준다는 접에서 CREATE ROLE과 다릅니다.


 - 슈퍼유저:

 postgres=# CREATE ROLE [name] SUPERUSER;


 데이터베이스 슈퍼유저는 로그인 권한을 제외한 모든 권한 검사를 건너뜁니다. 

 아무에게나 슈퍼유저 권한을 주는 것은 위험합니다.


 - 데이터베이스 생성:

 postgres=# CREATE ROLE [name] CREATEDB;


 - role 생성:

 postgres=# CREATE ROLE [name] CREATEROLE;


 role을 추가적으로 생성하려면 권한이 명시적으로 role에 주어져야 합니다.

 CREATEROLE 권한이 있는 role은 다른 role을 변경, 삭제할 수 있으며, 멤버십을 부여 또는 취소할 수 있습니다.

 단 슈퍼유저의 role은 수정 불가.


 - 복제 초기화:

 postgres=# CREATE ROLE [name] REPLICATION LOGIN;


 streaming replication을 초기화하려면 필요한 권한입니다.

 해당 role은 항상 LOGIN 권한을 같이 가지고 있어야 합니다.


 - 패스워드:

 postgres=# CREATE ROLE [name] PASSWORD 'string';


 패스워드는 데이터베이스에 연결할 때 사용자가 패스워드를 입력해야 하는 클라이언트 인증 방법인 경우에만 중요합니다.

 password 및 md5 인증방법은 패스워드를 이용합니다.

 


 - role의 속성은 ALTER ROLE 명령으로 수정할 수 있습니다.



role 멤버십


 - 권한 관리의 편의상 사용자를 그룹으로 묶는 것이 편리할 수 있습니다. 이렇게 하면 권한을 그룹단위로 부여하거나 취소할 수 있습니다. PostgreSQL에서 이것은 그룹을 나타내는 role을 생성한 다음, 그룹 role의 멤버십을 개별 사용자 role에 부여하면 됩니다.

 - 그룹 role을 설정 하려면 먼저 role을 생성해야 합니다.

 - 그룹 role이 존재하는 경우 grant 및 revoke 명령을 사용하여 멤버를 추가 및 삭제할 수 있습니다.


 쉽게 설명하자면 아래와 같습니다.


 두개의 role을 만들어 봅니다.

 postgres=# CREATE ROLE user01 login;

 postgres=# CREATE ROLE admin;

 postgres=# GRANT admin to user01;

 postgres=# ALTER role admin WITH createdb createrole;


 user01을 이용해서 로그인은 가능하지만, admin으로는 로그인이 되지 않습니다.

 

 postgres@psql-db01:/usr/local/pgsql/data]$ psql -d postgres -U admin

 psql: FATAL:  role "admin" is not permitted to log in

 

 postgres@psql-db01:/usr/local/pgsql/data]$ psql -d postgres -U user01

 psql (9.6.11)

 Type "help" for help. 

 

 postgres=>


 user01은 로그인은 가능하지만 권한이 없기 때문에 create database 명령은 사용할 수 없습니다.

 

 postgres=> create database test02;

 ERROR:  permission denied to create database

 postgres=>

 

 

 user01은 슈퍼유저가 아니기 때문에 postgres에 롤로 전환할 수 없습니다.


 postgres=> set role postgres;

 ERROR:  permission denied to set role "postgres"



 하지만 admin에 속해 있기 때문에 admin으로 전환은 가능합니다.

 admin으로 전환해서 create database 명령을 사용 가합니다.


 postgres=> set role admin;

 SET

 postgres=> create database test03;

 CREATE DATABASE

 

 이렇게 여러가지 role을 만들어서 멤버십을 통해 다양하게 활용할 수 있습니다.

 

 role 간에 전환은 set role [name]; 명령으로 합니다.

 

 처음에 접속한 role로 돌아가려면


 set role [처음 접속한 role name];

 set role none;

 reset role;


 셋중 하나로 원상 복구가 됩니다.

 oracle로 치면 SQL> 안에서 conn 명령으로 유저가 이동하는것과 비슷한데, 허용된 멤버십 안에서 이동이 가능한 것 입니다.




 

'Database > PostgreSQL' 카테고리의 다른 글

PostgreSQL 백업 및 복원  (0) 2019.01.01
PostgreSQL 로컬라이제이션  (0) 2019.01.01
PostgreSQL 데이터베이스 Role  (0) 2019.01.01
PostgreSQL 아카이브 모드  (0) 2019.01.01
PostgreSQL 커널 리소스 관리  (0) 2019.01.01
PostgreSQL 모니터링  (0) 2018.12.31

PostgreSQL 아카이브 모드



PostgreSQL 아카이브 모드 (Archive Mode)



- PostgreSQL에서 아카이브 모드를 이해하기전에 WAL을 자세히 알고 넘어가야 할 필요가 있습니다. 

- WAL (Write-Ahead Logging)은 데이터 무결성을 보장하는 표준 방법입니다.

- WAL의 중심개념은 변경 내용을 설명하는 로그 레코드를 영구적 저장소에 먼저 기록한 후에 데이터 파일의 변경 내용을 작성한 다는 것입니다. (오라클의 redo-archive와 비슷한 역할)

- 충돌 발생시 로그를 사용하여 데이터베이스를 복구 할 수 있으므로 트랜잭션 커밋마다 데이터 페이지를 디스크에 쓸 필요가 없습니다. 데이터 페이지에 적용되지 않은 변경 내용은 로그 레코드에서 실행 취소가 가능합니다. (이것은 roll-forward 복구 이며, REDO라고도 합니다.)

- 로그 파일은 순차적으로 작성되며, 로그 파일 동기화 비용은 데이터 페이지 쓰기 비용보다 훨씩 적습니다. 

- 서버가 소규모 도시 트랜잭션을 다수 처리하는 경우 로그 파일의 fsync 하나로 여러가지 트랜잭션을 충분히 커밋할 수 있습니다.

- 온라인 백업 및 PIT(point-in-time) 복구를 지원 가능하게 합니다.




 ※ $PGDATA 밑에 있는 postgresql.conf 파일안의 파라미터 값 수정하여 설정 가능합니다.


 ◆ wal_level (enum)

 - wal_level은 WAL에 기록되는 정보의 양을 결정합니다. 기본값은 충돌 또는 즉시 셧다운으로부터 복구하기 위해 필요한 정보만 기록하는 minimal 입니다.

  

  minimal : 기본값

  archive : WAL 아카이브에 필요한 로깅만 추가. 

  hot_standby : 대기 서버에서 읽기전용 쿼리에 필요한 정보를 추가.


 ◆ archive_mode (boolean)

  -archive_mode를 사용하는것으로 설정하면 완료된 WAL 세그먼트가 archive_command 설정에 의하 아카이브 저장소로 전달 됩니다. archive_mode 및 archive_command는 별개의 변수이므로 아카이빙 모드를 해지하지 않고도 archive_command를 변경할 수 있습니다. 이 매개변수는 서버 시작 시 설정됩니다. wal_level이 minimal로 설정된 경우 archive_mode를 사용 할 수 없습니다.

 

 ◆ archive_command (string)

  - 완료된 WAL 파일 세그먼트를 아카이브하기 위해 실행하는 로컬 쉘 명령입니다.

  - String : %p 아카이브할 파일의 경로명으로 대체

             %f 파일명으로만 대체


 ◆ archive_timeout (integer)

  - archive_command는 완료된 WAL 세그먼트를 호출합니다. 그러므로 서버에는 WAL 트래픽이 발생되지 않아서 트랜잭션이 완료되는 시간과 아카이브 저장소에서 안전하게 기록 되는 사이에 긴 지연시간이 발생 할 수 있습니다. 데이터가 아카이브되지 않은 채로 방치되지 않게 하기 위해 서버가 새 WAL 세그먼트 파일로 주기적으로 전환되도록 archive_timeout을 설정할 수 있습니다. 

 - archive_timeout을 매우 짧게 설정하는 것은 저장소를 부풀게 함므로 현명하지 못하며, 1~2분정도로 설정하는 것이 좋습니다.




※ 실제로 설정 해보기


$ vi postgresql.conf


wal_level = archive

archive_mode = on

archive_command = 'cp %p /data/pgsql/archive/arch_%f.arc'

archvie_timeout = 120


:wq!


postgres@psql-db01:/usr/local/pgsql/data]$ pg_ctl stop

waiting for server to shut down.... done

server stopped

[1]+  Done                    postgres -D /usr/local/pgsql/data > /var/postgresql/log/postgresql.log 2>&1  (wd: /var/postgresql/log)

(wd now: /usr/local/pgsql/data)

postgres@psql-db01:/usr/local/pgsql/data]$ postgres -D /usr/local/pgsql/data >/var/postgresql/log/postgresql.log 2>&1 &

[1] 52044

$



※ 아카이브 모드 확인하기


postgres=# select * from pg_settings

           where name in ('archive_mode', 'archive_command', 'archive_timeout', 'wal_level');

postgres=# show wal_level;

postgres=# show archive_mode;

postgres=# show archive_command;



로그 스위치


pg_switch_xlog() / pg_xlogfile_name / pg_xlogfile_name_offset



pg_switch_xlog() - 현재 사용중인 로그 파일을 아카이빙하고 새로운 파일로 스위칭 함.


postgres=# select pg_switch_xlog();

 pg_switch_xlog 

----------------

 0/70000B0

(1 row)


pg_xlogfile_name / pg_xlogfile_name_offset - 아카이빙 된 파일명 출력


postgres=# select pg_xlogfile_name('0/3000078'), pg_xlogfile_name_offset('0/3000078');

     pg_xlogfile_name     |    pg_xlogfile_name_offset     

--------------------------+--------------------------------

 000000010000000000000003 | (000000010000000000000003,120)

(1 row)



현재 사용중인 로그 확인


pg_current_xlog_locatioin() : 현재 사용중인 로그 출력


postgres=# select pg_current_xlog_location();

 pg_current_xlog_location 

--------------------------

 0/41000060

(1 row)




'Database > PostgreSQL' 카테고리의 다른 글

PostgreSQL 로컬라이제이션  (0) 2019.01.01
PostgreSQL 데이터베이스 Role  (0) 2019.01.01
PostgreSQL 아카이브 모드  (0) 2019.01.01
PostgreSQL 커널 리소스 관리  (0) 2019.01.01
PostgreSQL 모니터링  (0) 2018.12.31
PostgreSQL 점검  (0) 2018.12.31

PostgreSQL 커널 리소스 관리



공유 메모리 및 세마포어


 - 공유 메모리 및 세마포어는 통칭 "System V IPC"라고 합니다. 윈도우 외에, PostgreSQL이 이러한 기능에 대한 자체적인 구현을 제공하는 경우 PostgreSQL을 실행하기 위해 이러한 기능이 요구됩니다.


 - PostgreSQL은 서버 사본별로 System V 공유 메모리 수 바이트가 필요합니다. (64비트 플랫폼의 경우 보통 48바이트)


 - 서버 사본은 다수 실행 중이거나 다른 애플리케이션도 System V 공유 메모리를 사용중인 경우 바이트 단위의 공유 메모리 최대 크기인 SHMMAX를 늘려야 하거나 시스템 차원(system-wide)의 System V 공유 메모리인 SHMALL을 늘려야 할 수 있습니다. SHMALL은 여러 시스템에서 바이트 단위가 아니라 페이지 단위로 처리된다는 점에 유의해야 합니다.


 - PostgreSQL은 16개 한 세트로, 허용된 연결당 (max_connections) 및 autovacuum worker 프로세스당(autovacuum_max_workers) 1개의 세마포어를 사용합니다. 시스템에서 세마포어 최대 수는 SEMMNS에 의해 설정되며, 따라서 최소한 max_connection + autovacuum_max_workers + 각각 허용된 16개의 연결에 1추가 + worker여야 합니다. 각각의 세트마다 다른 애플리케이션에서 사용되는 세마포어 세트와의 충돌을 감지하기 위한 "매직 넘버"가 17번째 세마포어에 포함되어 있습니다.


 ceil((max_connection + autovacuum_max_workers +4)/16)*17외 다른 애플리케이션의 여유분.




리눅스에서의 세마포어


 - 최대 세그먼트 크기 기본값은 32MB 이며, 최대 총 크기 기본값은 2097152 페이지 입니다. "huge page"를 이용한 특수 커널 구성일 때 외에는 페이지는 거의 항상 4096바이트 입니다. (확인하려면 getconf PAGE_SIZE 사용).


 - 공유 메모리 크기설정은 sysctl 인터페이스를 통해 변경이 가능합니다. 예를 들어, 16GB를 허용하려면 다음과 같이 합니다.


 # sysctl -w kernel.shmmax=17179869184

 # sysctl -w kernem.shmall=4194304


 또한, /etc/sysctl.conf 파일에서 리부팅 사이에서도 이 설정을 보존할 수 있습니다. 



'Database > PostgreSQL' 카테고리의 다른 글

PostgreSQL 데이터베이스 Role  (0) 2019.01.01
PostgreSQL 아카이브 모드  (0) 2019.01.01
PostgreSQL 커널 리소스 관리  (0) 2019.01.01
PostgreSQL 모니터링  (0) 2018.12.31
PostgreSQL 점검  (0) 2018.12.31
PostgreSQL 권한 부여 및 해제  (0) 2018.12.31