클라우드에는 참 많은 종류의 네트워크가 필요한데, 바로 이 부분을 보다 단순화 할 수 없을까 하는 생각에 몇가지 테스트를 진행하던 중 블로그에 Quagga 를 검색어로 유입되는 경우가 꽤 있어 얼마전 진행했던 테스트의 내용을 간추려 올린다.
오늘도 역시 발로 그림이 먼저 등장한다.
Quagga with BGP
실제 구성은 각 ToR 이 8회선의 multi-path 를 가지는 것이었지만, 단순화를 위해 살짝 변경 했다. 맨 위의 박스는 우분투 서버이며, 인터넷으로의 업링크 회선은 일반 UTP 로, 172.16.1.250/24 에 게이트웨이는 172.16.1.1, 인터페이스는 eth0 이다.
다운링크는 Intel 10G Dual port 로, Arista 7124SX 의 24번 포트에 TwinAx 케이블로 연결되어있다. 망은 30 bitmask 를 가지며, 이 구간에는 eBGP 를 사용하였다.
Aggregation <---> ToR 에는 각 2회선이 사용되었으며, 모두 10G 연결이다. 역시 각 회선마다 30 bitmask 의 네트워크 구성이 되어 있으며, ECMP 가 적용되어 있다. (LACP 가 아님에 주의) AGGR 측에서는 1번 포트부터 순차적으로 2포트씩 다운링크에 사용한다.
ToR 스위치는 업링크에 23,24번 포트를 사용하며, 1번부터 22번 포트까지는 Vlan 10 으로, 랙에 설치된 서버의 연결에 사용한다. 서버는 ToR 스위치를 게이트웨이 인터페이스로 가지지만, ToR 스위치는 Aggregation 스위치와 iBGP 로 연결 되어 있다.
이와 같은 구성에서, 서버의 Quagga 설정은 zebra 와 bgpd 만을 사용하도록 하며, 설정은 다음과 같다.
# /etc/quagga/daemons
# This file tells the quagga package which daemons to start.
#
# Entries are in the format: =(yes|no|priority)
# 0, "no" = disabled
# 1, "yes" = highest priority
# 2 .. 10 = lower priorities
# Read /usr/share/doc/quagga/README.Debian for details.
#
# Sample configurations for these daemons can be found in
# /usr/share/doc/quagga/examples/.
#
# ATTENTION:
#
# When activation a daemon at the first time, a config file, even if it is
# empty, has to be present *and* be owned by the user and group "quagga", else
# the daemon will not be started by /etc/init.d/quagga. The permissions should
# be u=rw,g=r,o=.
# When using "vtysh" such a config file is also needed. It should be owned by
# group "quaggavty" and set to ug=rw,o= though. Check /etc/pam.d/quagga, too.
#
zebra=yes
bgpd=yes
ospfd=no
ospf6d=no
ripd=no
ripngd=no
isisd=no
/etc/quagga/daemons 는 어떤 프로토콜을 사용 할 지를 정해주는 설정 파일이다.
이후 모든 Quagga 설정 파일은 한번에 나오므로, 각 섹션의 주석 처리된 파일 이름으로 구분해서 참고 하도록 하자.
아마 스위치 설정에는 더 필요한게 있거나 빼야 할 것이 있을 수 있다. 스스로 네트워크 전문가는 절대 아니라고 생각하고 있으므로, 무언가 더 필요한게 있다고 생각 되시면 조언을 주시면 좋겠다.
일단 이와 같이 구성된 설정에서, 제대로 통신이 되는지 설정을 확인.
먼저 서버. Quagga 가 설치된 이후에는 일반 스위치 설정과 같은 CLI 인터페이스를 vtysh 를 통해 진입이 가능하다.
root@yjjeong:/etc/quagga# vtysh
END # <-- type 'q'
Quagga# sh run
hostname qugga
hostname External01
!
interface eth0
ip address 172.16.1.250/24
ipv6 nd suppress-ra
!
interface eth1
ip address 192.168.1.201/24
ipv6 nd suppress-ra
!
interface eth2
ip address 10.254.1.254/30
ipv6 nd suppress-ra
!
interface eth3
ip address 10.254.2.254/30
ipv6 nd suppress-ra
!
interface lo
!
router bgp 60001
bgp router-id 172.16.1.250
network 0.0.0.0/0
neighbor downstream peer-group
neighbor downstream remote-as 60000
neighbor downstream ebgp-multihop 10
neighbor 10.254.1.253 peer-group downstream
neighbor 10.254.1.253 update-source eth2
neighbor 10.254.2.254 peer-group downstream
neighbor 10.254.2.254 update-source eth3
!
ip route 0.0.0.0/0 172.16.1.1
!
ip forwarding
!
line vty
!
end
Quagga# sh ip bgp
BGP table version is 0, local router ID is 172.16.1.250
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, R Removed
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 0.0.0.0 0.0.0.0 0 32768 i
*> 10.0.1.0/24 10.254.1.253 0 60000 i
*> 10.1.1.0/30 10.254.1.253 0 60000 i
*> 10.1.2.0/30 10.254.1.253 0 60000 i
*> 10.254.1.252/30 10.254.1.253 0 60000 i
Total number of prefixes 5
Quagga# sh ip route
Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF,
I - ISIS, B - BGP, > - selected route, * - FIB route
S 0.0.0.0/0 [1/0] via 172.16.1.1, eth0
K>* 0.0.0.0/0 via 172.16.1.1, eth0
B>* 10.0.1.0/24 [20/0] via 10.254.1.253, eth2, 02w0d00h
B>* 10.1.1.0/30 [20/0] via 10.254.1.253, eth2, 02w0d00h
B>* 10.1.2.0/30 [20/0] via 10.254.1.253, eth2, 02w0d00h
B 10.254.1.252/30 [20/0] via 10.254.1.253 inactive, 02w0d00h
C>* 10.254.1.252/30 is directly connected, eth2
C>* 127.0.0.0/8 is directly connected, lo
C>* 172.16.1.0/24 is directly connected, eth0
Quagga# sh ip bgp
Quagga# ping 10.1.2.1
PING 10.1.2.1 (10.1.2.1) 56(84) bytes of data.
64 bytes from 10.1.2.1: icmp_req=1 ttl=64 time=0.161 ms
64 bytes from 10.1.2.1: icmp_req=2 ttl=64 time=0.115 ms
64 bytes from 10.1.2.1: icmp_req=3 ttl=64 time=0.122 ms
64 bytes from 10.1.2.1: icmp_req=4 ttl=64 time=0.120 ms
64 bytes from 10.1.2.1: icmp_req=5 ttl=64 time=0.114 ms
64 bytes from 10.1.2.1: icmp_req=6 ttl=64 time=0.114 ms
^C
--- 10.1.2.1 ping statistics ---
6 packets transmitted, 6 received, 0% packet loss, time 4998ms
rtt min/avg/max/mdev = 0.114/0.124/0.161/0.019 ms
Quagga# ping 10.1.1.2
PING 10.1.1.2 (10.1.1.2) 56(84) bytes of data.
64 bytes from 10.1.1.2: icmp_req=1 ttl=63 time=0.181 ms
64 bytes from 10.1.1.2: icmp_req=2 ttl=63 time=0.161 ms
^C
--- 10.1.1.2 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 999ms
rtt min/avg/max/mdev = 0.161/0.171/0.181/0.010 ms
Quagga# quit
다이어그램 제일 하단의 각 서버들에서도 이상 없이 우분투 서버로의 통신이 가능했다. 만약 여기서 사설네트워크에 대한 인터넷을 제공하고자 한다면, 다음의 iptables 로 SNAT 을 지정해 준다.
root@yjjeong:/etc/quagga# iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
Quagga 의 BGP 는 아직 ECMP 를 지원하고 있지 않다. 따라서, 만약 서버에서의 ECMP 가 필요하다면 OSPF 를 사용하는 것이 나을 수도 있다. 단순하게 ECMP 의 기능이 필요해서인 것 뿐 아니라, 내부의 네트워크에도 iBGP 대신 OSPF 를 사용하는 것이 보다 효율적일지도 모르겠다. 다만, 랙의 숫자, 즉 ToR 스위치와 이에 따른 하위 네트워크의 숫자가 늘어나는 경우, 라우팅 테이블이 너무 많아지지 않도록 처리하는 방법이 가장 좋지 않겠나 싶다.
위의 구성은 단순 AGGR - ToR 이지만, Distributed-Core 라 부르는, 다중의 Core - AGGR - Leaf (ToR) 의 구성으로도 쉽게 확장이 가능 할 것임을 알 수 있겠다. 아마도 확장은 아래 비슷한 모델?
Nginx is one of the simplest reverse-proxy server in the world. It's really easy to implement, and quite working well with many type of proxy configurations. Nginx itself does not need external cache solutions, because it's quite fast without it. And, if you're running nginx on Linux systems, then you may already know that the Linux has traditional cache algorithm in itself. However, you can still have memcached for your nginx. Even if you are not a web-programmer, you can configure it to use memcached by using nginx.conf. This feature may gives you additional performance when you build reverse-proxies. I do not recommend to use memcached with nginx for image server, because you can use sendfile, which comes with Linux. As I wrote above, additional cache system may cause unexpected problems, and sendfile/Nginx has quite good caching performance.
Well, it's very nice when you serve general web services. However, if you're planing to serve some kind of huge size thing, usually file based objects or streams, but it may not a best choice to use. Nginx is designed to lightweight, high-performance for small files, or reverse-proxy.
Because the Nginx is used for reverse-proxy, you may want to use it as a SSL endpoint. This is the one of the great function when you build a service with this. If your system has SSL engine, then you can include it to Nginx workers. One another fantastic feature is, you can assign each workers to CPU with configuration. It means, if you have many processors on your server, then the performance can be increased with this feature dramatically.
There are many kind of this exists, but Nginx has most simplest syntax for configuration, so I'll give some diagrams and nginx.conf. I wrote this post without extremely care, so you'll need to double check when you apply it to user production systems.
In this post, I'll mention about,
a. Reverse-proxy
b. Load balancing
c. Nginx with memcached, for application/octect-stream ( Experimental )
Nginx 는 언젠가부터 급 부상하기 시작한 다용도의-가볍고-사용하기쉬운 웹 서버다. lighttpd 와 같은 시스템 과는 약간 궤를 달리하는데, apache 에서 어플리케이션 서버의 기능을 배제하고, 부가기능에 보다 충실한 서버다 라고 할 수 있겠다. Nginx 에 대한 자세한 설명은 http://wiki.nginx.org 에서 얻을 수 있으므로 그게 무엇이다를 설명하는 것은 스킵하기로 한다.
다음은 발로 그린 서비스 아키텍쳐이다. 여기에는 내부망과 외부망 사이에서 각 서비스로의 도메인 라우팅 ( aka. 리버스 프락싱 ) 및 로드 밸런싱, 그리고 SSL endpoint 로서의 기능을 하는 서버가 필요하다. 물론 여기에 상용의 밸런서를 넣을 수도 있으며, 아예 밸런서 클라우드로 구성해 버리는 방법도 있다. 하지만 양자 모두 돈이 많이 드니까, 그냥 Nginx 를 쓰기로 했다.
Diagram #1, Entire system design
다시한번 그림은 발로 그렸음을 강조한다. ( 사실은 인튜오스4에 Sketchbook Express ;;; )
구성하고자 하는 것이 Compute cloud 건, Storage cloud 건, 하둡이건, 그도 아니면 태풍을 예보하는 기상용 HPC 클러스터이던 간에 서비스를 구성하는 구성 요소는 대부분 다 엇비슷하다. 멤버들의 스펙이나 연결 방법들은 조금씩 다르긴 하지만. 아무튼 요즘 유행하고 있는 여기건 저기건 무한대로 확장해야 한다 라는 요소를 가미하면, 모든 구간에 확장이 가능해야 하며 여기에는 똥색으로 그려진 밸런서들도 예외가 아니다. 만약 백본의 트래픽이 수십/수백 기가에 달하는 지경이 된다면 서비스의 종류에 따라 내부 트래픽은 훨씬 더 증가 할 가능성이 있으며, 이 트래픽들은 DSR 구조로 연결되어 있지 않다면 모두 밸런서를 통과하게 된다.
행여 역시 개발로 쓴 영문을 보신 분들이라면 알겠지만, Nginx 는 만능이 아니다. 잘못사용하게 되면 사용하지 않느니만한 결과를 불러오며, 간결하게 만들어진 시스템에 이것저것 붙이다 보면 오히려 최근의 BMW 처럼 된다. 성능과 정비성이 떨어지게 되며, 장애 포인트가 늘어난다. 프락싱이나 밸런싱의 종류에 따라, Varnish / Pound / Apache 등이 좋은 선택이 될 수 있다. 테스트 테스트.
Simple concept - 발그림 2탄
밸런싱은 기본적으로 Service rack #1 - 5 에 대해서 수행하게 되며, 추가적으로 Log 서버에서 제공하는 웹 페이지와 Redmine 을 운영에 필요한 Issue tracking 으로 사용한다고 치자. 그리고, 이 Nginx 는 SSL payload 를 처리하도록 한다. 물론 어차피 이런 구조라면 밸런서를 각 랙에 넣으면 되지 않냐고 할 수도 있겠지만, 그런 내용은 요기의 주제가 아니므로 패씅.
요새는 멀티 코어 서버가 유행이므로, 일단 프로세서는 적당한 가격으로 1~2개 정도 넣어준다. 멀티코어에 하이퍼스레딩을 더하면 OS 에서 뻥튀기는 순식간이므로..;; Nginx 용 서버는 Generic x86_64 로 하고, 편의상 우분투로 한다. 설정을 진행하기 전에, 아래의 내용을 보자.
root@balancer01:/etc/nginx# openssl engine -t
(aesni) Intel AES-NI engine
[ available ]
(dynamic) Dynamic engine loading support
[ unavailable ]
위의 커맨드는 현재 시스템에서 지원하는 SSL engine 을 확인하는 커맨드 된다. 이제 몇년전에 포스팅에 끄적이고 한번도 올리지 않았던 nginx.conf 의 샘플을 올려본다. 물론, 그대로 가져다 사용하면 문제가 될 수 있으므로 몇몇 포인트는 수정해야 할 수 있겠다. 물론 SSL 에 필요한 crt/key 파일 생성은 사전에 진행 되어야 하겠다. Nginx 설치 역시 여기서 다루지는 않는다.
서버는 단순 이미지 파일을 제공하는 image 서버, redmine 서버로의 프락싱, 그리고 무언가 서비스를 돌리고 있는 내부 시스템의 웹 서버로 밸런생+프락싱의 세가지 기능을 한다. 추가적으로 memcached 가 일부 서비스에서 엮여 있는데, 이는 테스트용이므로 참고 해도 좋고 아니어도 좋다.
로그 서버인 Splunk 는 upstream 에는 등록이 되었지만, 실제로 사용하지는 않았다. 다이어그램에는 Sumo Logic 인데 웬 Splunk 하시는 분들도 계실지 모르겠다. 그렇다. 아무 상관 없다. @_@ 음, Sumo Logic 은 클라우드 로그 솔루션이다. 데모 어카운트를 받아서 해봤는데, 검색기능도 강력하고 무엇보다 골치아픈 로그 서버를 내부에서 관리 하지 않아도 된다는 특장점이 있다. 물론 이 특장점은 로그를 외부로 유출 할 수 없는 시스템에서는 고민거리로 탈바꿈 하지만.
upstream 에 least_conn; 을 적용하려면 nginx 버전이 1.3.1 / 1.2.2 이 되어야 한다. 물론 keepalive 값을 주는 것도 가능.
default_type 은 보통 text 를 할당하는데, 이미지 캐싱을 위해서 한번 바꿔봤다. 이미지가 로컬에 있지 않고 REST 기반의 시스템에 토큰이 포함된 주소를 던져야 뱉어주는데, 좀 빨라질까 싶어서 테스트 중.
아, 그리고 memcached 최신의 버전에서는, -I (대문자임) 옵션을 사용하여 value 로 사용할 저장소의 크기를 1m 이상을 사용 할 수 있다. 물론 크게 잡으면 크게 잡을수록 키 하나가 먹는 메모리 사이즈가 증가하므로 별로 바람직하지 않을 수 있겠다. 위의 설정 파일에서는 키를 request_url 로 잡았음을 확인 할 수 있다. 또한 캐시 서버가 없거나 죽은 경우에는 바로 내부 서버로 던지므로 서비스 동작에는 문제가 없다. /etc/memcached.conf 를 서비스로 추가한다.
# 2003 - Jay Bonci
# This configuration file is read by the start-memcached script provided as
# part of the Debian GNU/Linux distribution.
# Run memcached as a daemon. This command is implied, and is not needed for the
# daemon to run. See the README.Debian that comes with this package for more
# information.
-d
# Log memcached's output to /var/log/memcached
logfile /var/log/memcached.log
# Be verbose
# -v
# Be even more verbose (print client commands as well)
# -vv
# Start with a cap of 64 megs of memory. It's reasonable, and the daemon default
# Note that the daemon will grow to this size, but does not start out holding this much
# memory
-m 4096
# Default connection port is 11211
-p 11211
# Run the daemon as root. The start-memcached will default to running as root if no
# -u command is present in this config file
-u memcache
# Specify which IP address to listen on. The default is to listen on all IP addresses
# This parameter is one of the only security measures that memcached has, so make sure
# it's listening on a firewalled interface.
-l 127.0.0.1
# Limit the number of simultaneous incoming connections. The daemon default is 1024
-c 10240
# Lock down all paged memory. Consult with the README and homepage before you do this
# -k
# Return error when memory is exhausted (rather than removing items)
# -M
# Maximize core file limit
# -r
# Increate allocation size limit of value per key to 5 Mega
-I 5m
무슨 메모리를 저리 무식하게 할당 했는가 할 수 있겠는데, 서버가 메모리가 48기가가 있어서 그랬다. 음.. 용서를.
밸런서가 여러대 있는데 이건 또 어떻게 밸런싱 하나 뭐 그럴 수도 있겠는데, 그건 일단 그림에 PowerDNS 를 쑤셔박는걸로 회피했다. 또한, 당연히 성능에 대해서 이런 저런 의견이 있을 수 있겠지만, 어쨌든 서버만 있으면 오픈소스로 엮어서 돌릴 수는 있다. 가성비에 대해서는 추가적인 비교가 필요하지만, 이건 간단한 소개 정도이므로 여기서 종료.
원래는 Quagga 까지 함께 엮어서 내부 망에 iBGP / eBGP 및 OSPF 등으로 L3 스위치와 엮는 설정을 함께 적으려 했는데, 아직 Quagaa 가 BGP에 대해 maximum-path ( ECMP ) 를 지원하지 않아서 스킵은 핑계. 아, OSPF 에 대해서는 지원한다.
뭔가 거창하게 시작했는데 괴발개발 그림 그리다 날 샜다. 다시 업장으로 컴백 고고 하기 전에, naver.com 을 대상으로 reverse-proxy 를 수행 한 모습. 다음에도 해봤는데 아마도 피싱 방지 목적용인지 무조건 http://www.daum.net 으로 리다이렉션 시켜버린다. 네이버에는 몇년 전에도 해봤는데 이번에 해도 잘 나오네.
최근 스토리지 클라우드 관련 테스트를 위해 1~2 기가 바이트 정도의 동영상 파일들을 토런트를 사용하여 받고 있다. 단순히 받기만 하는 것이 아니라, 혹시 나중에 스트리밍을 위해 사용 할 지도 몰라서 RSTP / H.264 포멧, 그리고 애플용 모바일 기기를 위해 mp4 로 함께 인코딩을 하고 있다. 물론 파일의 크기와 종류가 다양해 지니만큼 소기의 목적이었던 풍족한 테스트를 위해서도 바람직한 일이다.
문제는 이 인코딩 그리고 다운로드에 개인 노트북이나 PC를 사용하는 경우 쓸데없이 많은 리소스를 잡아먹어서 일에 제법 방해가 될 때가 많다. 단순히 일에 방해가 되는 것 뿐만 아니라, 효율이 떨어지는 2년된 맥북 프로가 고생하는 모습을 보니 안스러워서 새벽에 잠깐 검색질을 통해 조금 더 편리 한 방법을 구성 했다. 물론 아시는 분들은 다 아시는.
transmission-cli 는 토런트 클라이언트의 lightweight 버전을 다시 cli 전용으로 만든 것이다. apt-get install 로 쉽게 설치가 가능하다. ffmpeg 와 avconv 는 모두 영상/음성 관련 도구들이다. 많은 확장 기능들이 있지만, 핵심은 영상 또는 음성의 encoding 이다.
transmission-cli 는 다음과 같이 간편하게 사용이 가능하다.
transmission-cli -w /root/torrent/ [DOWNLOADNAME.TORRENT] 또는 [DOWNLOAD_MAGNET_ADDRESS]
-w 뒤의 옵션은 다운로드 받은 파일을 저장하고자 하는 경로를 지정한다. 위의 커맨드로 인해 발생하는 아웃풋이 별로 마음에 들지 않는다면 stdout 의 리다이렉션 ( aka. > ) 을 사용하여 간단히 로그로 남겨도 된다.
이런식으로 다운로드 받은 파일을 갖가지 용도의 다른 영상으로 인코딩이 가능한데, 여기에는 다음과 같은 스크립트를 뚝딱 만들어서 사용한다. 크론으로 돌리게 되는 경우에는 중복처리를 신경 써 주어야 할 것이다. 또한, 전용 인코딩 팜을 돌리려면 torque 와 같은 queue 시스템이 필요 할 지도 모르겠다. 다음의 스크립트는 /root/drama 디렉토리의 모든 영상을 변환하고, 변환이 완료되면 Swift 의 스토리지 클러스터로 업로드 한다.
#!/bin/bash
PWD=/root/drama
cd $PWD
for input in `ls -1`
do
echo "Process output name"
output=`echo $input | cut -d'.' -f1`
echo "Source file: ${input}"
echo "Encoded file: ${output}.mp4"
echo "Encoding $input to mp4"
avconv -y -i $input -strict experimental -qscale 2 ${output}.mp4
echo "Upload ${output}.mp4 to swift storage system"
swift -V 2 -A http://127.0.0.1:35357/v2.0 -U account:userid -K userkey upload mp4 ${output}.mp4
echo "Upload compleated, delete local files"
rm -f $input ${output}.mp4
done
avconv 도구의 -y 옵션은 사용자가 질의를 받지 않기 위함이며, -strict experimental 은 현재 apt 패키지 관리 도구로 설치되는 어플리케이션의 AAC 인코딩이 experimental 이라 그렇다. 그리고 -qscale 은, 이 옵션 없이 돌려 보면 실망을 금치 못할 것이다. 화질에 대한 옵션인데, 기본적으로 mp4 인코딩은 굉장히 구린 화질로 인코딩 되는데, 이 -qscale 옵션을 사용하게 되면 제법 볼만한 결과물이 나온다. 값은 2-5 를 지정 할 수 있는데, 낮을 수록 좋은 화질이다.
달성하고자 하는 목적은,
1. 인코딩에 서버 자원을 활용한다.
2. 다운로드에 서버 자원을 활용한다.
3. 클라우드로의 업로드도 서버 자원을 활용한다.
노트북은 소중하니;;;;
뭐 아무튼, 만약 여러분이 가상 서버를 사용중이거나 여분의 리눅스 자원이 있다면 전용 다운로드/인코딩 박스로 활용해도 좋지 않나 싶다. 모뎀 시절에는 참 이런 박스 많이 만들어 놀았는데 요새는 이런게 별로 어렵지도 않네...
물론 여기에 보다 더 많은 기능을 넣을 수도 있겠지만, 현재로는 이정도면 충분하지 않나 싶다. 왜냐면 난 디게 바쁘니깐. +ㅁ+
한해 한해 갈 수록 머리가 점점 더 나빠지나 보다. 힘들게 설정한 장치나 설정파일을 며칠만 지나면 홀랑 까먹어 버린다. Evernote 를 사용하여 적어 두기는 하는데, 미처 다 적지 못한 부분은 꼭 이전에 했던 삽질을 다시해야만 하는 비효율 적인 짓을 최근 들어 자주한다. 이건 필시 이렇게 저렇게 들이부은 술과 꾸역꾸역 피워온 담배 때문인듯.
Network device console port
네트워크 장비의 초기 설정을 주로 하시는 분들이라면, 또 주로 설정하는 네트워크 장비가 Arista 의 ZTP 와 같은 기능을 제공하지 않는 경우라면 콘솔 포트의 사용은 매일 접하는 업무의 한 부분일 것이다. 비단 네트워크 장비 뿐 아니라, 바코드리더와 연결하는 Serial 포트의 사용이라던가, 임베디드 장비의 콘솔 아웃을 serial 을 통해 확인해야 한다던가 하는 일을 할때에는 이 RS-232가 매우 유용하게 사용된다. 이전의 두께 4Cm 이상의 노트북, 또는 일반 데스크탑에서는 COM 포트가 기본으로 달려있어 별 무리없이 연결하여 HyperTerminal 이나 putty, 또는 minicom 등을 사용하여 연결했지만, 최근의 대부분의 노트북에는 이 포트가 달려서 나오는 경우가 거의 없다. 더군다나 엄청나게 창궐하고 있는 애플의 노트북들은 당연히 이런 구시대적인 인터페이스는 지원하지 않는다.
물론 USB to RS-232 또는 FTDI 와 같은 방법들이 존재하기는 하지만, 개인적으로 맥에서 호환되는 USB to RS-232 를 찾는건 쉽지 않았던 것 같다. 뭐 물론 덥썩 사서 사용해 보는 무대뽀 정신도 필요할 지는 모르겠지만, 주변의 대대수의 엔지니어분들이 맥을 들고다니면서 윈도우 VM 또는 부트캠프를 올리고, 거기서 드라이버를 설정해 사용하는 모습을 보며 안타까움을 금할 길이 없었다. 많은 분들이 윈도우에 익숙 할 테지만, 그렇다고 콘솔 터미널 접근을 위해 맥에서 윈도우를 돌려 USB 케이블과 장비로 연결된 콘솔 케이블을 주렁주렁 매단 채로 시끄러운 데이터 센터 안에서 장비를 설정하는 모습은 분명 아름답지는 않은 것이었다.
원래 네트워크 장비를 그다지 자주 설정하지는 않지만, 최근 들어 요구가 발생하는 바람에 가볍고 예쁜 맥북 에어에서 좀더 멋지게 작업하는 방법이 없을까 하고 고민 하던 중, RS232 를 Bluetooth 신호로 전달 해 주는 장치를 찾았다. 국내에서 판매하는 장치는 가장 많이 검색되는 것이 http://wirelessall.co.kr/goods_detail.php?goodsIdx=7395 인데, Palo Alto에서 지내시는 지인분께서 한국에 들어 올 일이 있다 하여 염치 불구하고 http://serialio.com/products/adaptors/BlueSnapXP.php 를 구매하여 셔틀을 부탁했다.
BlueSanp-XP with internal battery
BlueSnapXP 는, RS-232를 Bluetooth 로 전달해 주는데 배터리가 내장 되어 있어 노트북에 주렁주렁 케이블을 연결 할 필요가 없다. 더군다나 Bluetooth 를 사용하기 때문에 별도의 드라이버를 설치하거나 할 필요도 없게 된다. 만약 데이터 센터에서 작업을 하게 된다면, 그저 BlueSnap-XP 에 콘솔 케이블을 연결 해 두고 대상 장비만 변경 해서 연결 해 주면 되고, 노트북은 전혀 움직일 필요가 없어진다. 귀찮은 윈도우 가상 머신을 사용하지 않아도 되니 이 얼마나 아름다운 세상인가. 하이퍼 터미널이여 안녕. minicom 설정이 복잡하다고 머리를 쥐어뜯던 지난 날이여 안녕.
일단 나의 경우 별도의 전원장치가 필요하지 않다라고 판단 하여, 다음의 제품을 구매했다. serialio.com 의 온라인 스토어에서 찾아 볼 수 있다.
이 생소한 장비가 배달 되었을때, 이걸 어떻게 사용해야 하나 하고 한참을 고민 했더랬다. 사실 맨 처음 가졌던 생각은, 그냥 노트북과 블루투스 페어링을 잡아 주면, 일반 콘솔 어플리케이션에서 접근 할 수 있지 않겠나 싶었다. 결론 부터 말하자면 매우 삽질했다. ㅠㅠ 언제나 그렇지만 알고 나면 다 써있는건데, 알게 되기 까지 참 고생이 심하다. 멍청해서 그런가보다.
몇가지 장치의 동작에 대해서 간략하게 설명 하면, 다음과 같다.
1. 장치의 기본 동작은 "설정 모드" 와 "데이터 통신 모드" 가 있다.
- 설정모드의 진입은 장치를 껐다가 켠 이후, 60초 이내에 콘솔 어플리케이션으로 접근하여 $$$ <cr> (aka. 엔터) 를 쳐 준다.
- 설정모드에서 나오려면 장치를 reset 하던지, 아니면 --- <cr> 로 빠져 나온다.
2. 블루투스 기반의 장치들은 그저 Slave 로 동작하는 것이 아니라, 경우에 따라 Master 로도 사용 하여 같은 장비들끼리 연결이 가능하다. 하지만 이 기능은 원래 사용하고자 하는 목적과 부합되지 않으므로 패스.
3. 장치의 외부에 보면, 딥 스위치로 구성된 점퍼가 있다. 모두 이해하려면 머리 아프지만, 간단히 자주 쓰이는 설정은 다음과 같다.
- 1번 스위치 : 뭔가 잘못 설정 되었을때 초기 화 할때 사용한다.
- 초기화는 1번 점퍼 ON, 장치가 켜지면 Off / On / Off 2회 반복.
- 2번 스위치 : 일반적으로 많이 사용되는 기능. 장치의 자동 검색, 연결이 가능하도록 한다.
- 3번 스위치 : Master 모드로 다른 BlueSnap 장치의 마스터로서 설정하는 경우에 사용한다.
점퍼를 올리기 전 설정 모드에서 SR 커맨드를 사용하여 리모트를 지정해 주어야 한다.
또는, 2 번 스위치와 함께 사용하여 Auto discover 할 수도 있다.
- 4번 스위치 : 기본적으로 장치의 Baud rate 는 115200, 이 스위치를 올리면 9600 으로 동작.
먼저, 일반 네트워크 장비용으로 사용하고자 하는 경우에는 설정모드에서 커맨드를 통해 Baud Rate 를 9600 으로 세팅해 주어야 한다. 그 외에 장치의 이름이나 페어링에 사용할 패스워드의 변경, 기타 확장 명령도 사용이 가능하다. 설정은 다음의 순서.
1. 장치를 켜고, OSX의 System preferences 의 Bluetooth 메뉴를 이용하여 페어링을 설정.
2. 위 링크의 Serial tool 을 다운로드, 실행.
3. 장치를 껐다가 다시 켠다. 그리고 Serial tool 에서 장치를 선택, Connect 버튼을 누른다.
- 페어링이 성공적으로 완료 되었다면, BlueSnap-XP-XXXX-SPP 와 같은 이름을 볼 수 있을 것이다.
- 9600-8-none-1, cr/if 버튼에 체크. 이 외의 RTS/DTR 등의 체크박스는 uncheck 상태로 둔다.
Serial tools
4. Connect 버튼을 누른다. 사실 이전에는 장치는 미리 페어링 되어 있지 않은 상태에서, 버튼을 누르면 장치를 찾고 블루투스를 연결하기 때문에 실패 할 수도 있다. 3번 까지 적당한 간격으로 연결이 될 때까지 눌러주면 된다.
5. 연결이 완료 되었다면, 60초가 지나기 전에 $$$ 엔터 를 눌러 설정 모드로 진입한다. 성공적으로 진입 하였다면, CMD 의 문자열을 볼 수 있다.
6. 기본 커맨드는 D ( 기본 설정 확인 ), E ( 확장 설정 확인 ), h ( 도움말 ) 등이 있다. 설정 명령의 형태는 기본적으로 2 캐릭터로된 문자열 뒤에 콤마 (,) 이후 공백없이 알맞은 값을 넣어주면 된다. 보다 디테일한 설명은 홈페이지의 표를 참조하면 된다.
7. 설정을 마친 뒤에는 R,1 으로 장치를 재부팅한다. 재부팅이 완료되면 장치를 종료하고, 점퍼의 2번을 ON 상태로 변경한다.
8. 스위치 등에 연결하여 정상 동작 확인.
6번에서 설정의 내용은 다음과 같다.
$$$CMD
h
*** SET COMMANDS ***
SA,<1,0> - Authentication
SB, - Send Break
SC, - Service Class
SD, - Device Class
SE,<1,0> - Encryption
SF,1 - Factory Defaults
SI, - Inquiry Scan Window
SJ, - Page Scan Window
SL, - Parity
SM,<0-5> - Mode (0=slav,1=mstr,2=trig,3=auto,4=DTR,5=Any)
SN, - Name
SO, - conn/discon Status
SP, - Pin Code
SR, - Remote Address
SS, - Service Name
ST, - Config Timer
SU, - Baudrate
SW, - Sniff Rate
SX,<1,0> - Bonding
SY, - TX power
SZ, - Raw Baudrate
S7,<0-1> - 7bit data
S~,<0-3> - Profile (0=SPP,1=DCE,2=DTE,3=MDM,4=D&S
S?,<0-1> - role switch
S$, - CMD mode char
S@, - io port dir
S&, - io port val
S%, - io boot dir
S^, - io boot val
S*, - pio(8-11) set
S|, - low power timers
*** DISPLAY ***
D - Basic Settings
E - Extended Settings
G - Stored setting
GB - BT Address
GK - Connect Status
G& - I/O Ports
V - Firmare version
*** OTHER ***
C, - Connect
F,1 - Fast Mode
I,
어떤 부분이 커맨드고 어떤 부분이 아웃풋인지 구분하기가 힘들것이다. XX,0 이런 스타일로 된 부분이 커맨드이며, 설정값이 정상인 경우 AOK 를 보여준다. 만약 설정 값에 문제가 있거나 정해진 문자열의 길이를 넘는다면, ERR 메세지를 볼 수 있을 것이다.
위와 같이 설정이 완료 되었다면, 이제 장치를 끄고, 스위치에 연결된 콘솔 포트의 RS-232에 연결 한 다음, 장치를 켜자. 그리고 맥에 기본 내장 되어있는 터미널을 실행 하고, 다음의 커맨드를 날려준다.
screen /dev/tty.YZ-SnapXP-SPP
모든 설정이 정상적으로 완료 되었다면, 예전 하이퍼 터미널에서 보던 것과 같은 콘솔 메세지를 확인 할 수 있다. 지금까지의 과정에서 무언가 잘못 되었거나, 실수로 마스터 모드등으로 설정한 경우라면 위에 소개된 점퍼 1번을 통해 공장 초기화를 진행하면 된다.
네트워크 가상화가 유행이기는 하지만, 어떠한 형태로든 망의 물리적인 연결은 필요하다. 이러한 망 설정의 첫 단계인 콘솔의 사용 에 있어 인터페이스의 제한을 핑계로 윈도우에 묶여 있지 말고, 간지나는 맥북 에어를 들고 센터에 가자.
