OSX 및 Linux 배포판 정리
Php를 이용해서 아래와 같이 편하게 할 수 있음
| #!/bin/bash -e
INPUT=$1;
if [ -z $INPUT ]; then echo ” Input your encoding Plain text” else php -r “echo base64_encode($INPUT);”; echo “\n”; fi |
예전엔, 이렇게 openssl을 이용했엇따.
[root@jinstalk ~]# printf “mail.shhong” | openssl base64
bWFpbC5zaGhvbmc=
Decode는 해당 openssl을 이용해서 이런식으로 가능합니다.
#!/bin/bash -e
INPUT=$1;
if [ -z $INPUT ];
then
echo ” Input your decoding Base64Encoded text”
else
echo $INPUT | openssl base64 -d;
echo “”;
fi
#RPM BUILD INSTALL
yum install rpm-build
yum install redhat-rpm-config
#STATUS FOR RPM-BUILD
rpm -qs rpm-build
#Environment for BUILD
mkdir -p ~/rpmbuild/{BUILD,RPMS,SOURCES,SPECS,SRPMS}
# rpm 설치시 /etc/rpm/macro.dist 에 설정
#아래 매크로는 따로 설정하지 않아도 동작함.
echo ‘%_topdir %(echo $HOME)/rpmbuild’ > ~/.rpmmacros
#COMPILER Install
yum install make gcc
# 쌘트 6에서 공식 지원하는건 gcc 4.4
# RH 프로젝트를 통해서 비공식적으로 파이선 2.7 버전과, gcc 4.8을 Virtual ENV 형태로 제공 받을 수 있음.
Nginx에서 HTTPS Optimizing
SSL/TLS의 대부분 오버헤드는 초기의 연결 setup이다.
이 연결을 캐싱하면 다음 요청들이 좀 더 빨라진다.
설정에 다음을 추가한다.
ssl_session_cache shared:SSL:20m;
ssl_session_timeout 10m;
이는 모든 워커 프로세스들 사이에 공유되는 캐쉬를 생성한다.
캐쉬 사이즈는 bytes이고 4000 세션은 1MB에 저장된다고 한다. 20MB는 80000 세션을 저장하게 될 것이다.
SSL은 TLS에 의해 대체된다. SSL을 계속 이야기 하는 건 오래된 습관과 관습이 아닐까 한다.(이 건 원본 저자의 의견)
SSL은 몇 가지 약점을 가지고 있기 때문에(이건 찾아봐야 함) 실지적으로 다양한 공격이 있었다.
TLS를 지원 안 하는 브라우저는 IE 6이다. (굿바이 했으니~ 패스)
TLS의 최신 버전은 1.2다. 그러나 새로운 브라우저들과 라이브러리들이 여전히 TLS 1.0을 사용한다.
따라서 설정에 다음을 추가한다.
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
저자가 왜 이것을 옵티마이징 해야하는지.. 사용할 때 안전한 것만 지정해서 쓰면 될 거 같은데.. 여튼 한 번 해봤다.
설정에 다음을 추가하고
ssl_prefer_server_ciphers on;
아래 설정 중에 하나면 선택해서 쓰면 된다. (옵션 1과 옵션 2의 차이는 원본 참조)
# Cipher suite option 1:
ssl_ciphers ECDH+AESGCM:ECDH+AES256:ECDH+AES128:!ADH:!AECDH:!MD5;
# Cipher suite option 2:
#ssl_ciphers ECDH+AESGCM:ECDH+AES256:ECDH+AES128:DH+3DES:!ADH:!AECDH:!MD5;
# If you absolutely need IE8 compatibility, use this:
#ssl_ciphers ECDH+AESGCM:ECDH+AES256:ECDH+AES128:DH+3DES:RSA+3DES:!ADH:!AECDH:!MD5;
Online Certificate Status Protocol(OCSP) 는 현재 인증서의 폐지 상태를 체크하는 프로토콜이다. 브라우저가 인증서를 볼 때 해당 인증서가 폐지 안 됐는지 체크하기 위해 인증서를 발행한 곳과 접촉한다. 물론 이 것은 연결을 초기화하는데 오버헤드가 된다. 또한 이 과정에서 3자(인증서를 발행한 곳)가 포함되어서 프라이버시 이슈가 있다.
이것을 적용하려면 Nginx 1.3.7 이상이 필요하다.
그리고 인증서를 발행하는 사이트에 가서 아래 파일을 다운 받는다.
AddTrustExternalCARoot.crt PositiveSSLCA2.crt
우리는 Comodo 인증서를 다운 받기 때문에 아래 URL에서 다운받았다.
그런 다음 한개의 파일로 합친다.
cat AddTrustExternalCARoot.crt PositiveSSLCA2.crt > trustchain.crt
이제 적절한 위치(예: /etc/nginx/cert/trustchain.crt)에 넣고 Nginx의 설정을 아래와 같이 추가한다.
ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /etc/nginx/cert/trustchain.crt;
resolver 8.8.8.8 8.8.4.4;
stapling과 관련 없이 resolver가 들어가 있다. 이건 DNS 주소이고 2개의 DNS주소는 구글의 public DNS 주소이다. 다른 DNS 주소를 넣어도 상관없다.
SPDY를 사용할 때 모든 HTTP 요청을 HTTPS로 redirect하고 싶다면 Strict Transport Security를 사용하고 싶을 거라고 하는데 SPDY를 사용 안 하므로 패스 했다.
적용해보니 https로 사용하는 우리 사이트에서는 약 400ms 정도 빨라졌다.
좀 더 정확한 내용을 보고 싶으면 아래 원본을 읽어 보시길~
원본:
https://bjornjohansen.no/optimizing-https-nginx
원본 위치 <http://chickenlabs.blogspot.kr/2014/08/nginx-https-optimizing.html>
톰켓 proxypass 시에 header 에 Original URI 전달하기.
관련해서 proxy backend 로 넘겨줄 때 X-Original-URI 말고 X-forwarded-URI 로도 넘겨주는 방법(동일?) 선택하면 될듯합니다.
참고 : http://nerds.qminderapp.com/request-url-behind-proxy.html
nginx 설정
header 의 X-Original-URI
location / {
proxy_set_header X-Original-URI $request_uri;
proxy_pass http://127.0.0.1:8080/;
}
location /testuri {
proxy_set_header X-Original-URI $request_uri;
proxy_pass http://127.0.0.1:8080/;
}
java 설정
request.getHeader(“X-Original-URI”);
실제 패킷 분석 결과
(톰켓으로 넘어가는 loopback 8080 캡쳐 : # tcpdump –i lo –qexX port 8080)
get http://test.hongstalk.com
09:54:56.618161 00:00:00:00:00:00 (oui Ethernet) > 00:00:00:00:00:00 (oui Ethernet), IPv4, length 623: localhost.47502 > localhost.webcache: tcp 557
0x0000: 4500 0261 210a 4000 4006 198b 7f00 0001 E..a!.@.@…….
0x0010: 7f00 0001 b98e 1f90 7f44 b41a 86a9 4ace ………D….J.
0x0020: 8018 0200 0056 0000 0101 080a 4fc9 9511 …..V……O…
0x0030: 4fc9 9511 4745 5420 2f20 4854 5450 2f31 O…GET./.HTTP/1
0x0040: 2e30 0d0a 582d 4f72 6967 696e 616c 2d55 .0..X-Original-U
0x0050: 5249 3a20 2f0d 0a48 6f73 743a 2031 3237 RI:./..Host:.127
get http://test.hongstalk.com/testuri
09:58:54.909510 00:00:00:00:00:00 (oui Ethernet) > 00:00:00:00:00:00 (oui Ethernet), IPv4, length 543: localhost.47504 > localhost.webcache: tcp 477
0x0000: 4500 0211 f02b 4000 4006 4ab9 7f00 0001 E….+@.@.J…..
0x0010: 7f00 0001 b990 1f90 59d0 c7ce 9d52 e649 ……..Y….R.I
0x0020: 8018 0200 0006 0000 0101 080a 4fcd 37e4 …………O.7.
0x0030: 4fcd 37e4 4745 5420 2f20 4854 5450 2f31 O.7.GET./.HTTP/1
0x0040: 2e30 0d0a 582d 4f72 6967 696e 616c 2d55 .0..X-Original-U
0x0050: 5249 3a20 2f74 6573 7475 7269 0d0a 486f RI:./testuri..Ho
svn co –no-auth-cache –config-option servers:global:http-proxy-host=10.10.10.10 –config-option servers:global:http-proxy-port=3128 –username 아이디 –password 암호 http://svn.bbunbro.com/static/ /bbunbro/data/static/
설명
–no-auth-cache : 암호 등 인증 관련 크레덴셜을 저장하지 않음
— config-option : ~/.subversion/config 에 지정하는 옵션, 위에서는 proxy를 이용한 svn 접속을 뜻함
–username, –password : svn 접속 주소
user nobody;
# no need for more workers in the proxy mode
worker_processes 2;
error_log /var/log/nginx/error.log info;
worker_rlimit_nofile 20480;
events {
worker_connections 8120; # increase for busier servers
use epoll; # you should use epoll here for Linux kernels 2.6.x
}
http {
server_name_in_redirect off;
server_names_hash_max_size 10240;
server_names_hash_bucket_size 1024;
include mime.types;
default_type application/octet-stream;
server_tokens off;
disable_symlinks if_not_owner;
sendfile on;
tcp_nopush on;
tcp_nodelay on;
keepalive_timeout 3;
gzip on;
gzip_vary on;
gzip_disable “MSIE [1-6]\.”;
gzip_proxied any;
gzip_http_version 1.1;
gzip_min_length 1000;
gzip_comp_level 3;
gzip_buffers 16 8k;
# You can remove image/png image/x-icon image/gif image/jpeg if you have slow CPU
gzip_types text/plain text/xml text/css application/x-javascript application/xml image/png image/x-icon image/gif image/jpeg application/xml+rss text/javascript application/atom+xml;
ignore_invalid_headers on;
client_header_timeout 120m;
client_body_timeout 120m;
send_timeout 90m;
reset_timedout_connection on;
connection_pool_size 256;
client_header_buffer_size 256k;
large_client_header_buffers 4 256k;
client_max_body_size 1024M;
client_body_buffer_size 128k;
request_pool_size 32k;
output_buffers 4 32k;
postpone_output 1460;
proxy_temp_path /tmp/nginx_proxy/;
client_body_in_file_only on;
log_format bytes_log “$msec $bytes_sent .”;
include “/etc/nginx/vhosts/*”;
include /etc/nginx/naxsi_core.rules;
#limit_zone limit_per_ip $binary_remote_addr 5m;
#limit_conn_zone limit_per_ip $binary_remote_addr 10m;
#limit_conn_zone limit_per_ip $binary_remote_addr zone=limit_per_ip:10m;
limit_req_zone $binary_remote_addr zone=allips:5m rate=200r/s;
limit_req zone=allips burst=200 nodelay;
limit_conn_zone $binary_remote_addr zone=addr:10m;
}
원본 위치 <http://www.phpfoxcamp.com/topic/6025-first-byte-time-is-too-long-on-my-nginx-server/>
[root@10.10.10.10 ~]# curl -o /dev/null -w “Connect: %{time_connect} TTFB: %{time_starttransfer} Total time: %{time_total} \n” -s https://internal-test.bbunbro.com
Connect: 0.002 TTFB: 0.069 Total time: 0.069
외부는 그냥 webpagetest.org 에서 테스트 하시오. 좋습니다.
참고 :
(로컬 호스트 톰켓 http listener 체크)
[root@10.10.10.10 ~]# curl -o /dev/null -w “Connect: %{time_connect} TTFB: %{time_starttransfer} Total time: %{time_total} \n” -s http://127.0.0.1:8080/www
Connect: 0.000 TTFB: 0.026 Total time: 0.026
A friendly formatter for curl requests to help with debugging.
Raw (디버깅을 위한 스니프 포멧 생성 후 테스트 하는 법)
sniff.txt
\n
============= HOST: ==========\n
\n
local_ip: %{local_ip}\n
local_port: %{local_port}\n
remote_ip: %{remote_ip}\n
remote_port: %{remote_port}\n
\n
======= CONNECTION: ==========\n
\n
http_code: %{http_code}\n
http_connect: %{http_connect}\n
num_connects: %{num_connects}\n
num_redirects: %{num_redirects}\n
redirect_url: %{redirect_url}\n
\n
============= FILE: ==========\n
\n
content_type: %{content_type}\n
filename_effective: %{filename_effective}\n
ftp_entry_path: %{ftp_entry_path}\n
size_download: %{size_download}\n
size_header: %{size_header}\n
size_request: %{size_request}\n
size_upload: %{size_upload}\n
speed_download: %{speed_download}\n
speed_upload: %{speed_upload}\n
ssl_verify_result: %{ssl_verify_result}\n
url_effective: %{url_effective}\n
\n
=== TIME BREAKDOWN: ==========\n
\n
time_appconnect: %{time_appconnect}\n
time_connect: %{time_connect}\n
time_namelookup: %{time_namelookup}\n
time_pretransfer: %{time_pretransfer}\n
time_redirect: %{time_redirect}\n
time_starttransfer: %{time_starttransfer}\n
———-\n
time_total: %{time_total}\n
\n
Steps to Use:
#1. Make a file named sniff.txt and paste the contents of this gist into it
#2. Make an alias in your .bash_profile or .zshrc ( or whatever you use ) that looks like this ( make sure to source .bash_profile the file afterwards ):
alias sniff=’curl -w “@/path/to/sniff.txt” -o /dev/null -s ‘
#3. Now you can use your alias to get some fun data back:
sniff https://api.twitter.com/1.1/search/tweets.json?q=@mrmidi
You will get a response that looks like this:
============= HOST: ==========
local_ip: 192.168.0.67
local_port: 49469
remote_ip: 199.16.156.231
remote_port: 443
======= CONNECTION: ==========
http_code: 400
http_connect: 000
num_connects: 1
num_redirects: 0
redirect_url:
============= FILE: ==========
content_type: application/json; charset=utf-8
filename_effective: /dev/null
ftp_entry_path:
size_download: 62
size_header: 380
size_request: 110
size_upload: 0
speed_download: 57.000
speed_upload: 0.000
ssl_verify_result: 0
url_effective: https://api.twitter.com/1.1/search/tweets.json?q=mrmidi
=== TIME BREAKDOWN: ==========
time_appconnect: 0.724
time_connect: 0.566
time_namelookup: 0.526
time_pretransfer: 0.724
time_redirect: 0.000
time_starttransfer: 1.078
———-
time_total: 1.078
iperf 소스를 다운받아 ./configure && make && make install 을 진행하거나, package를 다운받아서 설치한다.
http://pkgs.repoforge.org/iperf/ 에서 다운받아 쎈트에는 rpm -ivh로 설치함, 우분투는 apt-get install iperf
서버에서는 다음과 같이 실행
iperf -s
디폴트로 5001 tcp 포트가 오픈되며, acl등을 막지 않으면 클라이언트에서 다음과 같이 테스트한다.
iperf -c SERVER_IP
약간의 시간이 지연된 후 데이터전송 대역폭의 측정값이 노출된다.
추가로 다음과 같은 옵션이 가능
-t : 데이터를 보내는 시간 (기본 10초)
-i : 밴드위스를 쪼개는 옵션 ( -t 50으로 50초 동안 데이터를 보낸다는 가정하에 -i 5 옵션은 5번으로 끊어 나눠서 보내면서 테스트 한다.
-r : 양방향 테스트
-p : 페러럴 클라이언트 쓰레드 실행
개요
설치
* Installation prefix: /usr/local
* System type: pc-solaris2.10
* Host CPU: i386
* C Compiler: gcc (GCC) 4.6.2
* Assertions enabled: yes
* Debug enabled: no
* Warnings as failure: no
—
root@wl ~/src/libmemcached-1.0.5 # /usr/sfw/bin/gmake
root@wl ~/src/libmemcached-1.0.5 # /usr/sfw/bin/gmake install
실행
1) 도움말. 중요하다고 생각되는건 번역했다. 대형 사이트의 경우 도움말을 참조해 메모리관련 옵션 최적화를 반드시 수행해야 한다.
아래 커맨드는 windy 사용자의 권한을 사용하고, 64MB 메모리를 사용하고, 큰 페이지를 사용하며, 127.0.0.1만 바인드(외부 접속 불가)하는 데몬을 띄운다. PID 파일은 /tmp/memcached.pid 에 있다.
root@wl ~ # memcached -u windy -d -m 64 -l 127.0.0.1 -p 11211 -L -P /tmp/memcached.pid
memcached 는 kill 을 사용해 종료하면 된다.
root@wl ~ # kill `cat /tmp/memcached.pid`
1) 세팅 확인
2) 데이터 저장
3) 데이터 추출
아래와 같이 memcached_watch.d 스크립트를 작성해 DTrace 를 실행하고 위의 프로토콜 예제를 다시 따라하면 [command-set fired]가 출력될 것이다. Ctrl+C를 눌러 종료한다.
root@wl ~ # cat memcached_watch.d
/* TO RUN: dtrace -s memcached_watch.d -p `pgrep -x memcached` -q */
dtrace:::BEGIN
{
printf(“Hit Ctrl-C to end.\n”);
}
memcached*:::command-set
{
printf(“command-set fired\n”);
}
root@wl ~ # dtrace -s memcached_watch.d -p `pgrep -x memcached` -q
Hit Ctrl-C to end.
command-set fired
^C
JAVA/JSP
| memcache.java | 다운로드 (717 바이트) |
| 1
2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 |
package test;
import java.io.IOException; import java.net.InetSocketAddress; import java.util.HashMap;
import net.spy.memcached.MemcachedClient;
/** * Memcached Sample. * WindyHana’s Solanara – Memcached http://www.solanara.net/solanara/memcached * java test.MemcachedSample */ public class MemcachedSample { /** * 테스트 함수 * @param args */ @SuppressWarnings(“unused”) public static void main(String[] args) { MemcachedClient c; try { c = new MemcachedClient(new InetSocketAddress(“localhost”, 11211)); c.set(“someKey”, 3600, new HashMap<String, Object>()); Object myObjeckt = c.get(“someKey”); c.delete(“someKey2”); } catch (IOException e) { e.printStackTrace(); } } } |
PHP
PHP에서 memcached 를 사용하기 위한 모듈은 두가지를 제공한다. PECL:memcache, PECL:memcached 가 그것인데, 두가지 모두 memcached 에 접속해 사용한다. 단지 PECL:memcache는 memcached 에 직접 접속하는 PHP 모듈이고, PECL:memcached 는 libMemcached 를 통해 memcached 에 접속하는 모듈이라는 점이 다르다. PHP에서의 사용 방법이나 지원 함수도 조금씩 다르므로 매뉴얼을 확인하자.
php.ini 를 수정해야 한다. 윈디하나의 솔라나라: SAMP의 [PHP 설정]를 참조해 extension_dir 을 설정하고 아래와 같이 extension 을 추가해야 한다.
root@wl ~ # vi /usr/local/php/lib/php.ini
extension=memcache.so
| memcache.phps | 다운로드 (534 바이트) |
| 1
2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
<?php session_start(); ?>
<pre> <?php $presessdata = @$_SESSION[“data”]; $_SESSION[“data”] = @$_SESSION[“data”] + 1;
$memcache = new Memcache; $memcache->connect(“localhost”, 11211); print_r($memcache->getStats());
$items = array( ‘key1’ => ‘value1’, ‘key2’ => ‘value2’, ‘key3’ => ‘value3’ ); foreach ($items as $k => $v) { $memcache->set($k, $v); } var_dump($memcache->get(array(‘key1’, ‘key3’))); var_dump($memcache->get(‘key2’)); var_dump($memcache->get(‘key4’)); ?> SESSION: <?php echo $_SESSION[“data”]; ?> </pre> |
아래와 유사하게 출력되어야 한다.
Array
(
[pid] => 16700
[uptime] => 425530
[time] => 1333412724
[version] => 1.4.15
[libevent] => 2.0.20-stable
[pointer_size] => 32
[rusage_user] => 6.387770
[rusage_system] => 4.913250
[curr_connections] => 5
[total_connections] => 57
[connection_structures] => 7
[reserved_fds] => 20
[cmd_get] => 148
[cmd_set] => 45
[cmd_flush] => 0
[cmd_touch] => 0
[get_hits] => 100
[get_misses] => 48
[delete_misses] => 6
[delete_hits] => 0
[incr_misses] => 0
[incr_hits] => 0
[decr_misses] => 0
[decr_hits] => 0
[cas_misses] => 0
[cas_hits] => 0
[cas_badval] => 0
[touch_hits] => 0
[touch_misses] => 0
[auth_cmds] => 0
[auth_errors] => 0
[bytes_read] => 66307
[bytes_written] => 36315
[limit_maxbytes] => 67108864
[accepting_conns] => 1
[listen_disabled_num] => 0
[threads] => 4
[conn_yields] => 0
[hash_power_level] => 16
[hash_bytes] => 262144
[hash_is_expanding] => 0
[expired_unfetched] => 0
[evicted_unfetched] => 0
[bytes] => 27437
[curr_items] => 20
[total_items] => 45
[evictions] => 0
[reclaimed] => 0
)
array(2) {
[“key1”]=>
string(6) “value1”
[“key3”]=>
string(6) “value3”
}
string(6) “value2”
bool(false)
SESSION: 1
출처 – http://www.solanara.net/solanara/memcached
원본 위치 <http://linuxism.tistory.com/984>
Redis 본가 프로젝트로 개발되고있는 Redis 서버의 사활 감시 / 알림 및 자동 페일 오버 기능을 제공하는 관리 서버 (redis-sentinel)입니다. v2.4.16 또는 2.6.0-rc6 이상 버전에서 사용할 수 있습니다. 공식 문서를 참고로하면서 동작 확인을합니다.
구성
여기에서는 두 호스트에서 Slave를 2 프로세스 Sentinel 3 프로세스 구성 봅니다.
설정
/etc/redis/sentinel.conf
# port <sentinel-port>
port 26379
# sentinel monitor <master-name> <ip> <redis-port> <quorum>
sentinel monitor mymaster db0 6379 2
# sentinel down-after-milliseconds <master-name> <milliseconds>
sentinel down – after – milliseconds mymaster 5000
# sentinel failover-timeout <master-name> <milliseconds>
sentinel failover – timeout mymaster 900000
# sentinel can-failover <master-name> <yes | no>
sentinel can – failover mymaster yes
# sentinel parallel-syncs <master-name> <numslaves>
sentinel parallel – syncs mymaster 1
각 설정 항목 표하고 있습니다. Sentinel 의한 클러스터 모니터는 이른바 Quorum 기반 투표의 방식을 취합니다. 여러 Sentinel이 Master를 감시하고 그중 임계 값보다 많은 Sentinel이 Master 다운을 감지하면 장애 조치 프로세스를 시작합니다.
| 설정 항목 | 개요 |
| monitor | Master 호스트와 포트 및 상태가 ** ODOWN (objectively down) **로 전환하기위한 정족수 (quorum) |
| down-after-milliseconds | Master / Slave 다운 감지 후 상태가 ** SDOWN (subjectively down) **로 전환 될 때까지의 시간 (ms) |
| failover-timeout | 장애 처리 시간 (ms) |
| can-failover | 장애 조치가 실행하거나 (yes / no) |
| parallel-syncs | Slave를 Master로 승격시킨 후, 몇 개의 Slave와 동기화하거나 |
Sentinel은 Master와 Slave 모두의 사활 감시를 해줍니다 만, 상태가 ODOWN로 전환하는 것은 Master만이므로주의하십시오. can-failover를 no로하고 시작한 Sentinel 과정은 장애 조치 자체는 실시하지 않고 (다른 Sentinel에 맡길) 자신은 다운 탐지 및 투표 처리 만합니다.
시작
Sentinel 시작 전에 복제가 작동하는지 확인해야합니다.
redis-cli
redis db0 : 6379> info replication
# Replication
role : master
connected_slaves : 1
slave0 : db0, 6380, online
slave1 : db1, 6379, online
계속 3 개의 Sentinel 프로세스를 시작합니다.
redis-sentinel
$ redis – sentinel / etc / redis / sentinel. conf
## 또는 redis-server를 sentinel 모드로 부팅
$ redis – server / etc / redis / sentinel. conf – sentinel
로그에서 각 Slave 및 Sentinel와 연결 한 것을 확인할 수 있습니다.
[19069] 14 May 16 : 30 : 31.909 * + slave slave db1 : 6379 db1 6379 @ mymaster db0 6379
[19069] 14 May 16 : 30 : 31.909 * + slave slave db0 : 6380 db0 6380 @ mymaster db0 6379
[19069] 14 May 16 : 30 : 38.320 * + sentinel sentinel db0 : 26380 db0 26380 @ mymaster db0 6379
[19069] 14 May 16 : 30 : 39.655 * + sentinel sentinel db1 : 26379 db1 26379 @ mymaster db0 6379
또한 Sentinel 시작 후 INFO 명령 Sentinel 관련 정보를 확인할 수 있습니다.
redis-cli
redis db0 : 26379> info sentinel
# Sentinel
sentinel_masters : 1
sentinel_tilt : 0
sentinel_running_scripts : 0
sentinel_scripts_queue_length : 0
master0 : name = mymaster, status = ok, address = db0 : 6379, slaves = 2, sentinels = 3
Sentinel 과정 자체 모니터링은 아래 항목을 보도록하면 좋을까 생각합니다.
장애 조치 동작 확인을 위해 여기에서 Master를 떨어 뜨립니다.
redis-cli
redis db0 : 6379> shutdown
로그에서 장애 조치 진행 상황을 확인할 수 있습니다.
[19069] 14 May 16 : 30 : 51.170 # + sdown master mymaster db0 6379
[19069] 14 May 16 : 30 : 52.386 # + odown master mymaster db0 6379 #quorum 2/2
[19069] 14 May 16 : 30 : 52.386 # + failover-triggered master mymaster db0 6379
[19069] 14 May 16 : 30 : 52.386 # + failover-state-wait-start master mymaster db0 6379 #starting in 13910 milliseconds
[19069] 14 May 16 : 31 : 06.379 # + failover-state-select-slave master mymaster db0 6379
[19069] 14 May 16 : 31 : 06.480 # + selected-slave slave db1 : 6379 db1 6379 @ mymaster db0 6379
[19069] 14 May 16 : 31 : 06.480 * + failover-state-send-slaveof-noone slave db1 : 6379 db1 6379 @ mymaster db0 6379
[19069] 14 May 16 : 31 : 06.583 * + failover-state-wait-promotion slave db1 : 6379 db1 6379 @ mymaster db0 6379
[19069] 14 May 16 : 31 : 06.901 # + promoted-slave slave db1 : 6379 db1 6379 @ mymaster db0 6379
[19069] 14 May 16 : 31 : 06.902 # + failover-state-reconf-slaves master mymaster db0 6379
[19069] 14 May 16 : 31 : 06.991 * + slave-reconf-sent slave db0 : 6380 db0 6380 @ mymaster db0 6379
[19069] 14 May 16 : 31 : 07.294 * + slave-reconf-inprog slave db0 : 6380 db0 6380 @ mymaster db0 6379
[19069] 14 May 16 : 31 : 08.316 * + slave-reconf-done slave db0 : 6380 db0 6380 @ mymaster db0 6379
[19069] 14 May 16 : 31 : 08.417 # + failover-end master mymaster db0 6379
[19069] 14 May 16 : 31 : 08.417 # + switch-master mymaster db0 6379 db1 6379
[19069] 14 May 16 : 31 : 08.548 * + slave slave db0 : 6380 db0 6380 @ mymaster db1 6379
[19069] 14 May 16 : 31 : 09.068 * + sentinel sentinel db0 : 26380 db0 26380 @ mymaster db1 6379
[19069] 14 May 16 : 31 : 12.258 * + sentinel sentinel db1 : 26379 db1 26379 @ mymaster db1 6379
Sentinel이 Master 다운을 감지하면 상태가 SDOWN에 quorum 파라미터에서 지정한 수의 SDOWN이 맞춰지면 다음은 ODOWN로 전환 후 장애 조치 프로세스가 시작됩니다.
마지막으로 새로운 Master와 Slave에서 제대로 실행되는지 확인합니다.
redis-cli
redis db1 : 6379> info replication
# Replication
role : master
connected_slaves : 1
slave0 : db0, 6380, online
이상 Sentinel 페일 오버 기능이 작동 확인까지 시도했습니다.
Sentinel API
Sentinel 몇 가지 API를 제공하고 있기 때문에 쉽게 소개하고 싶습니다.
redis-cli
## SENTINEL masters
# 감시 대상의 Master 정보 확인
redis 127.0 0.1 : 26379> sentinel masters
1) 1) “name”
2) “mymaster”
3) “ip”
4) “127.0.0.1”
5) “port”
6) “6379”
7) “runid”
8) “b3b31e6c6d1fbb0cec5d179fd666ce00ea103746”
9) “flags”
10) “master”
11) “pending-commands”
12) “0”
13) “last-ok-ping-reply”
14) “568”
15) “last-ping-reply”
16) “568”
17) “info-refresh”
18) “9745”
19) “num-slaves”
20) “1”
21) “num-other-sentinels”
22) “1”
23) “quorum”
24) “2”
## SENTINEL slaves <master name>
# Slave 정보 확인
redis 127.0 0.1 : 26379> sentinel slaves mymaster
1) 1) “name”
2) “127.0.0.1:6380”
3) “ip”
4) “127.0.0.1”
5) “port”
6) “6380”
7) “runid”
8) “17c0f7e7e4d2af0f5f6140ea0ceb0d82d0010aed”
9) “flags”
10) “s_down, slave, disconnected”
11) “pending-commands”
12) “0”
13) “last-ok-ping-reply”
14) “709377”
15) “last-ping-reply”
16) “709377”
17) “s-down-time”
18) “704333”
19) “info-refresh”
20) “712808”
21) “master-link-down-time”
22) “0”
23) “master-link-status”
24) “ok”
25) “master-host”
26) “127.0.0.1”
27) “master-port”
28) “6379”
29) “slave-priority”
30) “100”
## SENTINEL is-master-down-by-addr <ip> <port>
# Master의 사활 확인
redis 127.0 0.1 : 26379> sentinel is – master – down – by – addr 127.0 0.1 6379
1) (integer) 0 ## 0 : UP 1 : DOWN
2) “397dec99760d5d30043941fe4c1c35ba99e99ebf”## Sentinel (subjective leader)의 run_id
## SENTINEL get-master-addr-by-name <master name>
# Master의 IP, Port를 확인
redis 127.0 0.1 : 26379> sentinel get – master – addr – by – name mymaster
1) “127.0.0.1”
2) “6379”
## SENTINEL reset
# Sentinel의 현재 상태를 재설정 (장애 조치 중에라도)
redis 127.0 0.1 : 26379> sentinel reset mymaster
(integer) 1
Sentinel 관련 관리 도구를 만들 때이 Sentinel API를 지원하는 클라이언트 라이브러리를 사용하면 쉽게 아닐까 생각합니다.
이하, 장애 복구 프로세스의 거동에 관한 부분을 픽업하여 소개합니다.
승격 Slave의 선택
당연 합니다만 Slave로 성공적으로 실행하는 프로세스가 적용됩니다. 세세한 조건을 생략하고 싹둑 말하면, Master와의 연결이 안정하고 (다운 타임이 적은) Sentinel에서 PING / INFO 명령에 최근 5000ms 이내에 응답하는 Slave가 대상이됩니다 (자세한 내용은 공식 문서와 src / sentinel.c 참조).
대상이되는 Slave가 여러 개있는 경우 slave_priority 값이 작은 Slave를 선택합니다.
redis-cli
redis db0 : 6380> info replication
# Replication
role : slave
master_host : 127.0 0.1
master_port : 6379
master_link_status : up
master_last_io_seconds_ago : 0
master_sync_in_progress : 0
slave_priority : 100 ## <-이 값
slave_read_only : 1
connected_slaves : 0
같은 slave_priority의 Slave가 있으면 run_id 작은 Slave를 선택합니다.
redis-cli
redis db0 : 6380> info
# Server
redis_version : 2.6. 10
redis_git_sha1 : 00000000
redis_git_dirty : 0
redis_mode : standalone
os : Linux 2.6 18 – 194.26 1. el5 x86_64
arch_bits : 64
multiplexing_api : epoll
gcc_version : 4.1. 2
process_id : 17468
run_id : 17 c0f7e7e4d2af0f5f6140ea0ceb0d82d0010aed ## <-이 값
tcp_port : 6380
uptime_in_seconds : 1738
uptime_in_days : 0
lru_clock : 538965
2013/06 현재는 slave_priority을 변경할 API는 공개되지 않은 것이므로 단순히 run_id 젊은 Slave가 선택되게됩니다. Slave 선택 알고리즘은 향후 변경 될 수도있을 것입니다.
Sentinels / Slaves 자동 감지
Sentinel 설정에 Slave의 목록을 갖게 할 필요가없는 것은 Sentinel이 Pub / Sub 의한 정보 공유를하고 있기 때문입니다. 중간에 다른 Sentinel와 Slave를 온라인으로 추가해도 다른 Sentinel 그 정보는 전해집니다.
redis-cli
## Sentinel은 “__sentinel __ : hello”채널을 이용하고있다
redis db0 : 6379> subscribe __sentinel__ : hello
Reading messages … (press Ctrl – C to quit)
1) “subscribe”
2) “__sentinel __ : hello”
3) (integer) 1
1) “message”
2) “__sentinel __ : hello”
3) “127.0.0.1:26380:77887a367e1c76ee9dc15f67a2fb3dc49bb00bf4:1”
1) “message”
2) “__sentinel __ : hello”
3) “127.0.0.1:26379:3a92da7269b69fa1dcce5915068c4af6e8caf161:1”
1) “message”
2) “__sentinel __ : hello”
3) “127.0.0.1:26380:77887a367e1c76ee9dc15f67a2fb3dc49bb00bf4:1”
1) “message”
2) “__sentinel __ : hello”
3) “127.0.0.1:26379:3a92da7269b69fa1dcce5915068c4af6e8caf161:1”
메시지의 내용은 host : port : run_id : can-failover가있어 __ sentinel __ : hello 채널에 5 초마다 publish 모든 Sentinel은이 채널을 subscribe하여 정보 공유하고 있습니다.