티스토리 툴바


'System/Networks'에 해당되는 글 6건

  1. 2012/08/30 Quagga test with Arista switches
  2. 2012/08/29 Nginx + memcached, and balancing
  3. 2012/08/28 RS232 to Bluetooth, BlueSnap-XP
  4. 2012/02/09 Cloud Networking (2)
  5. 2011/08/25 Quagga - Simple Router for Linux

( younjin.jeong@gmail.com, 정윤진 ) 


클라우드에는 참 많은 종류의 네트워크가 필요한데, 바로 이 부분을 보다 단순화 할 수 없을까 하는 생각에 몇가지 테스트를 진행하던 중 블로그에 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 설정 파일은 한번에 나오므로, 각 섹션의 주석 처리된 파일 이름으로 구분해서 참고 하도록 하자. 


# /etc/quagga/vtysh.conf
!
!
! service integrated-vtysh-config
!
hostname Ubuntubox
username root nopassword
!
!


# /etc/quagga/zebra.conf
!
hostname quagga
!
interface eth0
ip address 172.16.1.250/24
!
interface lo
!
interface eth2
ip address 10.254.1.254/30
!
ip forwarding
!
ip route 0.0.0.0/0 172.16.1.1
!
line vty
!  


# /etc/quagga/bgpd.conf
!
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
  no auto-summary
!


이제, 이 서버와 연결되는 AGGR 스위치의 config. 


# AGGR config
! device: 10G-AGGR-01 (DCS-7124SX, EOS-4.9.0-590041.EOS490RibPimFix (engineering build))
!
! boot system flash:/EOS-4.9.0-EFT2.swi
!
terminal length 30
!
hostname 10G-AGGR-01
!
spanning-tree mode mstp
!
no aaa root
!
username admin secret 5 heymannodbodygivesashitaboutwhatyouaredoing
!
interface Ethernet1
   no switchport
   ip address 10.1.1.1/30
!
interface Ethernet2
   no switchport
   ip address 10.1.1.5/30
!
interface Ethernet3
   no switchport
   ip address 10.1.2.1/30
!
interface Ethernet4
   no switchport
   ip address 10.1.2.5/30
!
interface Ethernet5
!
interface Ethernet6
!
interface Ethernet7
!
interface Ethernet8
!
interface Ethernet9
!
interface Ethernet10
!
interface Ethernet11
!
interface Ethernet12
!
interface Ethernet13
!
interface Ethernet14
!
interface Ethernet15
!
interface Ethernet16
!
interface Ethernet17
!
interface Ethernet18
!
interface Ethernet19
!
interface Ethernet20
!
interface Ethernet21
!
interface Ethernet22
!
interface Ethernet23
!
interface Ethernet24
   no switchport
   ip address 10.254.1.253/30
!
interface Management1
   ip address 192.168.1.201/24
!
ip routing
!
router bgp 60000
   bgp log-neighbor-changes
   timers bgp 1 3
   maximum-paths 16
   neighbor 10.1.1.2 remote-as 60000
   neighbor 10.1.1.2 update-source Ethernet1
   neighbor 10.1.1.2 next-hop-self
   neighbor 10.1.1.2 maximum-routes 12000 
   neighbor 10.1.1.6 remote-as 60000
   neighbor 10.1.1.6 update-source Ethernet2
   neighbor 10.1.1.6 next-hop-self
   neighbor 10.1.1.6 maximum-routes 12000 
   neighbor 10.1.2.2 remote-as 60000
   neighbor 10.1.2.2 update-source Ethernet3
   neighbor 10.1.2.2 next-hop-self
   neighbor 10.1.2.2 maximum-routes 12000 
   neighbor 10.1.2.6 remote-as 60000
   neighbor 10.1.2.6 update-source Ethernet4
   neighbor 10.1.2.6 next-hop-self
   neighbor 10.1.2.6 maximum-routes 12000 
   neighbor 10.254.1.254 remote-as 60001
   neighbor 10.254.1.254 ebgp-multihop 2
   neighbor 10.254.1.254 maximum-routes 12000 
   redistribute connected
!
!
end


각 ToR 설정. 


### ToR #1 
! device: 10G-TOR-01 (DCS-7124S, EOS-4.9.0-590041.EOS490RibPimFix (engineering build))
!
! boot system flash:/EOS-4.9.0-EFT2.swi
!
terminal length 30
!
logging host 192.168.17.201
logging facility local0
!
hostname 10G-TOR-01
!
spanning-tree mode mstp
!
no aaa root
!
username admin secret 5 whogivesashit
!
vlan 10
!
interface Ethernet1
   switchport access vlan 10
!
interface Ethernet2
   switchport access vlan 10
!
interface Ethernet3
   switchport access vlan 10
!
interface Ethernet4
   switchport access vlan 10
!
interface Ethernet5
   switchport access vlan 10
!
interface Ethernet6
   switchport access vlan 10
!
interface Ethernet7
   switchport access vlan 10
!
interface Ethernet8
   switchport access vlan 10
!
interface Ethernet9
   switchport access vlan 10
!
interface Ethernet10
   switchport access vlan 10
!
interface Ethernet11
   switchport access vlan 10
!
interface Ethernet12
   switchport access vlan 10
!
interface Ethernet13
   switchport access vlan 10
!
interface Ethernet14
   switchport access vlan 10
!
interface Ethernet15
   switchport access vlan 10
!
interface Ethernet16
   switchport access vlan 10
!
interface Ethernet17
   switchport access vlan 10
!
interface Ethernet18
   switchport access vlan 10
!
interface Ethernet19
   switchport access vlan 10
!
interface Ethernet20
   switchport access vlan 10
!
interface Ethernet21
   switchport access vlan 10
!
interface Ethernet22
   switchport access vlan 10
!
interface Ethernet23
   no switchport
   ip address 10.1.1.2/30
!
interface Ethernet24
   no switchport
   ip address 10.1.1.6/30
!
interface Management1
   ip address 192.168.1.203/24
!
interface Management2
!
interface Vlan10
   mtu 9212
   ip address 10.0.1.254/24
!
ip routing
!
router bgp 60000
   bgp log-neighbor-changes
   timers bgp 1 3
   maximum-paths 8 ecmp 8
   neighbor 10.1.1.1 remote-as 60000
   neighbor 10.1.1.1 export-localpref 70
   neighbor 10.1.1.1 maximum-routes 12000 
   neighbor 10.1.1.5 remote-as 60000
   neighbor 10.1.1.5 export-localpref 70
   neighbor 10.1.1.5 maximum-routes 12000 
   network 10.0.1.0/24
!
management telnet
   no shutdown
!
!
end



#### ToR 2 ! device: 10G-TOR-02 (DCS-7124SX, EOS-4.9.0-590041.EOS490RibPimFix (engineering build)) ! ! boot system flash:/EOS-4.9.0-EFT2.swi ! terminal length 30 ! hostname 10G-TOR-02 ! spanning-tree mode mstp ! no aaa root ! username admin secret 5 whogivesashit ! vlan 10 ! interface Ethernet1 switchport access vlan 10 ! interface Ethernet2 switchport access vlan 10 ! interface Ethernet3 switchport access vlan 10 ! interface Ethernet4 switchport access vlan 10 ! interface Ethernet5 switchport access vlan 10 ! interface Ethernet6 switchport access vlan 10 ! interface Ethernet7 switchport access vlan 10 ! interface Ethernet8 switchport access vlan 10 ! interface Ethernet9 switchport access vlan 10 ! interface Ethernet10 switchport access vlan 10 ! interface Ethernet11 switchport access vlan 10 ! interface Ethernet12 switchport access vlan 10 ! interface Ethernet13 switchport access vlan 10 ! interface Ethernet14 switchport access vlan 10 ! interface Ethernet15 switchport access vlan 10 ! interface Ethernet16 switchport access vlan 10 ! interface Ethernet17 switchport access vlan 10 ! interface Ethernet18 switchport access vlan 10 ! interface Ethernet19 switchport access vlan 10 ! interface Ethernet20 switchport access vlan 10 ! interface Ethernet21 switchport access vlan 10 ! interface Ethernet22 switchport access vlan 10 ! interface Ethernet23 no switchport ip address 10.1.2.2/30 ! interface Ethernet24 no switchport ip address 10.1.2.6/30 ! interface Management1 ip address 192.168.1.204/24 ! interface Vlan10 ip address 10.0.2.254/24 ! ip routing ! router bgp 60000 bgp log-neighbor-changes timers bgp 1 3 maximum-paths 8 ecmp 8 neighbor 10.1.2.1 remote-as 60000 neighbor 10.1.2.1 export-localpref 70 neighbor 10.1.2.1 maximum-routes 12000 neighbor 10.1.2.5 remote-as 60000 neighbor 10.1.2.5 export-localpref 70 neighbor 10.1.2.5 maximum-routes 12000 network 10.0.2.0/24 ! management telnet no shutdown ! ! end


아마 스위치 설정에는 더 필요한게 있거나 빼야 할 것이 있을 수 있다. 스스로 네트워크 전문가는 절대 아니라고 생각하고 있으므로, 무언가 더 필요한게 있다고 생각 되시면 조언을 주시면 좋겠다. 


일단 이와 같이 구성된 설정에서, 제대로 통신이 되는지 설정을 확인. 

먼저 서버. 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) 의 구성으로도 쉽게 확장이 가능 할 것임을 알 수 있겠다. 아마도 확장은 아래 비슷한 모델? 



Distributed core architecture



더 좋은 의견이나 테스트 해 볼 사항에 대해 의견이 있다면 얼마든 환영! 

2박 3일 회사에서 신세지고 17시간 잤더니 웬지 개운한 하루. 





( younjin.jeong@gmail.com, 정윤진 )


저작자 표시 비영리
Posted by YZ Cerberos 트랙백 0 : 댓글 0

( younjin.jeong@gmail.com, 정윤진 )



English ver.


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 설치 역시 여기서 다루지는 않는다. 


user www-data; worker_process 16; worker_cpu_affinity 0001 0001 0011 0111 1111 1100 1110 1001 1101 1011 1010 0010 0100 1000 1111 0110; worker_rlimit_nofile 8192; ssl_engine aesni; error_log /var/log/nginx/error.log; pid /var/run/nginx.pid; events { worker_connections 1024; multi_accept on; } http { upstream redmine { server 192.168.1.240:3000; } upstream splunk { server 192.168.1.241:8000; } upstream image { ip_hash; server 192.168.1.101:80 max_fails=3 fail_timeout=10s; server 192.168.1.102:80 max_fails=3 fail_timeout=10s; } upstream sharebox { least_conn; server 192.168.1.1:80 max_fails=3 fail_timeout=10s; server 192.168.1.2:80 max_fails=3 fail_timeout=10s; server 192.168.1.3:80 max_fails=3 fail_timeout=10s; server 192.168.1.4:80 max_fails=3 fail_timeout=10s; server 192.168.1.5:80 max_fails=3 fail_timeout=10s; } server { listen 0.0.0.0:443; ssl on; ssl_certificate /etc/nginx/ssl/cert.crt; ssl_certificate_key /etc/nginx/ssl/cert.key; server_name sharebox.mydomainname.com; sendfile on; client_max_body_size 4096m; client_body_buffer_size 128k; location / { set $memcached_key $request_url; default_type application/x-www-urlencoded; memcached_pass 127.0.0.1:11211; if ($request_method = POST) { proxy_pass http://sharebox; break; } proxy_intercept_errors on; error_page 404 502 = /fallback$uri; } location /fallback { internal; proxy_redirect off; proxy_pass http://sharebox; } } server { listen 0.0.0.0:80; server_name redmine.mydomainname.com; root /var/lib/redmine/; proxy_redirect off; sendfile_on; client_max_body_size 50m; client_body_buffer_size 128k; localtion / { proxy_pass http://redmine; proxy_set_header Host $http_host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Photo $scheme; proxy_connect_timeout 90; proxy_send_timeout 90; proxy_buffer_size 4k; proxy_buffers 4 32k; proxy_busy_buffer_size 64k; proxy_temp_file_write_size 64k; } } server { listen 0.0.0.0:80; server_name image.mydomainname.com; location / { valid_referes none blocked *.mydomainname.com; if ($invalid_referer) { return 403; } proxy_pass http://image; } } } include tuning/*.conf;


서버는 단순 이미지 파일을 제공하는 image 서버, redmine 서버로의 프락싱, 그리고 무언가 서비스를 돌리고 있는 내부 시스템의 웹 서버로 밸런생+프락싱의 세가지 기능을 한다. 추가적으로 memcached 가 일부 서비스에서 엮여 있는데, 이는 테스트용이므로 참고 해도 좋고 아니어도 좋다. 


Nginx 서비스를 시작하고 다음의 커맨드를 넣으면 보다 디테일한 정보를 볼 수 있다. 


root@redmine:/etc/nginx# nginx -V
nginx: nginx version: nginx/1.0.5
nginx: TLS SNI support enabled
nginx: configure arguments: --prefix=/etc/nginx --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-client-body-temp-path=/var/lib/nginx/body --http-fastcgi-temp-path=/var/lib/nginx/fastcgi --http-log-path=/var/log/nginx/access.log --http-proxy-temp-path=/var/lib/nginx/proxy --http-scgi-temp-path=/var/lib/nginx/scgi --http-uwsgi-temp-path=/var/lib/nginx/uwsgi --lock-path=/var/lock/nginx.lock --pid-path=/var/run/nginx.pid --with-debug --with-http_addition_module --with-http_dav_module --with-http_geoip_module --with-http_gzip_static_module --with-http_image_filter_module --with-http_realip_module --with-http_stub_status_module --with-http_ssl_module --with-http_sub_module --with-http_xslt_module --with-ipv6 --with-sha1=/usr/include/openssl --with-md5=/usr/include/openssl --with-mail --with-mail_ssl_module --add-module=/build/buildd/nginx-1.0.5/debian/modules/nginx-echo --add-module=/build/buildd/nginx-1.0.5/debian/modules/nginx-upstream-fair


로그 서버인 Splunk 는 upstream 에는 등록이 되었지만, 실제로 사용하지는 않았다. 다이어그램에는 Sumo Logic 인데 웬 Splunk 하시는 분들도 계실지 모르겠다. 그렇다. 아무 상관 없다. @_@  음, Sumo Logic 은 클라우드 로그 솔루션이다. 데모 어카운트를 받아서 해봤는데, 검색기능도 강력하고 무엇보다 골치아픈 로그 서버를 내부에서 관리 하지 않아도 된다는 특장점이 있다. 물론 이 특장점은 로그를 외부로 유출 할 수 없는 시스템에서는 고민거리로 탈바꿈 하지만. 


upstream 에 least_conn; 을 적용하려면 nginx 버전이 1.3.1 / 1.2.2 이 되어야 한다. 물론 keepalive 값을 주는 것도 가능. 

upstream 과 밸런싱에 대한 자세한 내용은 요기 http://nginx.org/en/docs/http/ngx_http_upstream_module.html


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 으로 리다이렉션 시켜버린다. 네이버에는 몇년 전에도 해봤는데 이번에 해도 잘 나오네. 



user root;
worker_processes  16;
worker_cpu_affinity 0001 0001 0011 0111 1111 1100 1110 1001 1101 1011 1010 0010 0100 1000 1111 0110;
ssl_engine aesni;

error_log  /var/log/nginx/error.log;
pid        /var/run/nginx.pid;

events {
    worker_connections  1024;
    multi_accept on;
}

http {
	upstream naver {
	server naver.com:80;
	}
	upstream daum {
	server daum.net:80;
	}

	server {
		listen 0.0.0.0:80;
		server_name naver.yourdomainname.com;
                sendfile on;
                client_max_body_size       4096m;
                client_body_buffer_size    512k;
		location / {
			set $memcached_key $request_uri;
			default_type application/octet-stream;
			memcached_pass	127.0.0.1:11211;
			if ($request_method = POST) {
				proxy_pass http://naver;
				break;
			}
			proxy_intercept_errors on;
			error_page 404 502 = /fallback$uri;
		}
		location /fallback {	
			internal;
			proxy_redirect off;
			proxy_pass http://naver;
		}
	}
	server {
		listen 0.0.0.0:80;
		server_name daum.yourdomainname.com;
                sendfile on;
                client_max_body_size       4096m;
                client_body_buffer_size    512k;
		location / {
			set $memcached_key $request_uri;
			default_type application/x-www-urlencoded;
			memcached_pass	127.0.0.1:11211;
			if ($request_method = POST) {
				proxy_pass http://daum;
				break;
			}
			proxy_intercept_errors on;
			error_page 404 502 = /fallback$uri;
		}
		location /fallback {	
			internal;
			proxy_redirect off;
			proxy_pass http://daum;
		}
	}
}


위와 같이 설정한 후, 브라우저에서 naver.yourdomainname.com 으로 접근하면 네이버 페이지가 나온다. 성실하게 작업하면 구멍 없이 리다이렉션을 걸어 줄 수 있을 듯. 뭐, 별로 할 필요는 없지만. 



Reverse-proxy to naver.com



네이버가 이뻐서 스크린샷까지 찍어 준 것은 아님. +ㅁ+ 


( younjin.jeong@gmail.com, 정윤진 ) 


저작자 표시 비영리
Posted by YZ Cerberos 트랙백 0 : 댓글 0

( younjin.jeong@gmail.com, 정윤진 ) 


한해 한해 갈 수록 머리가 점점 더 나빠지나 보다. 힘들게 설정한 장치나 설정파일을 며칠만 지나면 홀랑 까먹어 버린다. Evernote 를 사용하여 적어 두기는 하는데, 미처 다 적지 못한 부분은 꼭 이전에 했던 삽질을 다시해야만 하는 비효율 적인 짓을 최근 들어 자주한다. 이건 필시 이렇게 저렇게 들이부은 술과 꾸역꾸역 피워온 담배 때문인듯. 



Network device console port



네트워크 장비의 초기 설정을 주로 하시는 분들이라면, 또 주로 설정하는 네트워크 장비가 Arista 의 ZTP 와 같은 기능을 제공하지 않는 경우라면 콘솔 포트의 사용은 매일 접하는 업무의 한 부분일 것이다. 비단 네트워크 장비 뿐 아니라, 바코드리더와 연결하는 Serial 포트의 사용이라던가, 임베디드 장비의 콘솔 아웃을 serial 을 통해 확인해야 한다던가 하는 일을 할때에는 이 RS-232가 매우 유용하게 사용된다. 이전의 두께 4Cm 이상의 노트북, 또는 일반 데스크탑에서는 COM 포트가 기본으로 달려있어 별 무리없이 연결하여 HyperTerminal 이나 putty, 또는 minicom 등을 사용하여 연결했지만, 최근의 대부분의 노트북에는 이 포트가 달려서 나오는 경우가 거의 없다. 더군다나 엄청나게 창궐하고 있는 애플의 노트북들은 당연히 이런 구시대적인 인터페이스는 지원하지 않는다. 



보통 윈도우만을 지원한다.

image from: http://serialio.com/products/adaptors/usb_serial_WinDesk.php



물론 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 의 온라인 스토어에서 찾아 볼 수 있다. 


BlueSnapXP Bluetooth Dongle DTR mode 


다만 충전은 해야 할 것이 아닌가. 다음의 링크에서 USB 충전 케이블을 함께 구매 해 준다. 

https://serialio.com//store/product_info.php?cPath=72&products_id=565&osCsid=ostjslmp70t5qcsd0uhbqtp5q4


컴퓨터나 노트북의 USB 전원을 사용하여 충전한다. 

밥 주는 중




이 생소한 장비가 배달 되었을때, 이걸 어떻게 사용해야 하나 하고 한참을 고민 했더랬다. 사실 맨 처음 가졌던 생각은, 그냥 노트북과 블루투스 페어링을 잡아 주면, 일반 콘솔 어플리케이션에서 접근 할 수 있지 않겠나 싶었다. 결론 부터 말하자면 매우 삽질했다. ㅠㅠ  언제나 그렇지만 알고 나면 다 써있는건데, 알게 되기 까지 참 고생이 심하다. 멍청해서 그런가보다. 

몇가지 장치의 동작에 대해서 간략하게 설명 하면, 다음과 같다. 

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 으로 동작. 


이 정도가 간단한 삽질의 핵심이다. 접근에 사용한 도구는 맥에 기본으로 포함된 터미널 어플리케이션이었는데, 설정 모드에서 종종 타이핑한 글자가 보이지 않아 따로 하나 구했다.  http://www.w7ay.net/site/Applications/Serial%20Tools/index.html  

먼저, 일반 네트워크 장비용으로 사용하고자 하는 경우에는 설정모드에서 커맨드를 통해 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번을 통해 공장 초기화를 진행하면 된다. 


네트워크 가상화가 유행이기는 하지만, 어떠한 형태로든 망의 물리적인 연결은 필요하다. 이러한 망 설정의 첫 단계인 콘솔의 사용 에 있어 인터페이스의 제한을 핑계로 윈도우에 묶여 있지 말고, 간지나는 맥북 에어를 들고 센터에 가자. 



Connexion



별 내용도 아닌데 한참 삽질 한게 억울해 쓰다보니 괜시리 길어진듯. 


( younjin.jeong@gmail.com , 정윤진 )




저작자 표시 비영리
Posted by YZ Cerberos 트랙백 0 : 댓글 0

Cloud Networking

2012/02/09 21:10 from System/Networks
( younjin.jeong@gmail.com, 정윤진 )


네트워킹에 대한 글은 참 오랜만에 써 보는 것 같다. 사실 그다지 잘 아는 분야도 아니거니와, 일반적인 L3 ip networking 이 거의 대부분의 사용성을 지배하는 한국에서는 너무 당연한 이야기들이 많아서 쓸 것이 없어 그랬지 않았나 싶기도 하다.

오늘 잠깐 생각해 볼 주제는, 클라우드 네트워킹에서 가장 중요한 '확장성'을 고려하게 될 때, 과연 어떻게 망을 구성해야 효과적일까 하는 것이다. 모두들 넌블러킹 스위칭에 대해서 이야기 하고 있지만, 실제 그 넌블러킹의 정체가 무언지, 또 그렇다면 어떤 장비를 어떻게 엮어야 그런 확장성을 이루어 낼 수 있는지에 대해서 디테일하게 이야기 해 보기란 쉽지 않은 일일것이다.

일반적으로 구성하는 ipSAN 또는 스토리지간 연결을 위한 내부 폐쇠망의 구성을 하는데 있어, 최소한 랙 500 대 이상을 확장 할 수 있어야 한다 라는 요구사항이 있을때, 이 구간의 연결 및 IP 정책을 어떻게 만들어 낼 것인가가 아마도 최대의 고민이 될 수 있을 것이다. 경력있는 네트워크 엔지니어는 이러한 경우 내부망을 위한 전용 백본을 구성하고, 이 백본에서 하위 Aggregation 스위치로 MLAG, 다시 ToR ( Top of Rack ) 스위치로의 MLAG 구성을 만드는 것이 일반적인 구성이 될 수 있겠다. 


MLAG ( Multi-chassis Link Aggregation )

 
Image from:  http://www.computer-room-design.com/Arista-Networks-7500-Series-Data-Center-Switch.asp 

흔히 MLAG 이라 불리는 이러한 기술은, 여러대의 스위치를 한대의 스위치로 묶어 L2 레벨의 사용성을 보장한다. 이러한 구성은 최근의 대부분의 벤더가 지원하지만, 특정 벤더별로 상위 스위치로 연결된 2 또는 그 이상의 trunk 된 회선을 동시에 사용하는 이른바 Multi-path 를 지원하거나 지원하지 않는 제품들이 있다. 또한, 이렇게 사용하게 될 때 보통 각 랙별로 별도의 분리된 네트워크를 사용하고자 하는 경우가 많은데, 이럴때 각 ToR 을 위한 VLAN 구성을 추가하게 된다면 이제 각 VLAN 별로 게이트웨이가 되는 IP 를 할당해 주어야 할 텐데, 여기서 또 한번 할당 할 수 있는 IP 수량에 대한 제약 사항이 발생하게 된다.   

이와는 별도로 ToR 의 이중화 구성에 대해서 궁금해 하시는 분들도 있겠지만, 현대의 대부분의 클라우드 시스템들은 랙 하나의 장애에 크게 구애받지 않는다. 따라서 Aggregation 또는 백본의 장애에 대해서만 MLAG 을 구현하고, ToR 은 랙 별로 하나만 두기 때문에 위의 그림에서는 ToR 스위치가 한대다. 물론, 비용을 보다 많이 사용 할 수 있다면 모든 구성에 이중화가 가능하겠다.

아무튼 원래 주제인 MLAG 으로 돌아가서, ToR 에서는 L2, Aggregation 에서 L3 를 구현하는 이러한 방법은 여러모로 확장에 제한을 받게 된다. 물론 이러한 확장의 제한이라는 것이, 보통 샤시 레벨의 제품군을 사용하게 된다면 수백개의 포트 단위까지는 충분히 허용이 가능하므로, 구성하려는 시스템의 규모에 따라 제약사항이 되지 않을 가능성이 있다. 아니, 지금까지는 보통 그래왔다.

게다가 샤시 레벨의 제품을 사용하지 않는 경우에도, Aggregation 의 구성에 Tier 를 적용함으로서 48포트 X 48포트의 구성을 하는 것도 가능하다. 최근의 몇몇 벤더에서는 업링크에 40G 를 지원하는 제품도 있으므로, 이러한 구성시 보다 여유로울 수 있겠다.

얼마 전 까지만 해도 나 역시 이러한 구성이 거의 유일한 해법이며, 넌블러킹 구성에 있어 이보다 좋은 다른 대안이 없는 것으로 생각하고 있었다. MLAG 구성에서 Multi-path 를 지원 할 수 있다면, 현존하는 가장 좋은 내부망 확장 방법이라고 생각 했었다.

 
하지만 최근, 일본의 Midokura ( www.midokura.com )의 Dan 과 Ryu 와 함께 일하게 되면서 새로 배운 것이 있는데, 바로 내부망에 라우팅 프로토콜인 BGP 를 사용하는 방법이다. 

사실 국내에서 네트워크 전문가가 아니라면 생소한 이 프로토콜은, 보통 AS라 불리는 별도의 망 단위간 네트워크에서 라우팅을 위해 사용된다. 국내에서 생소한 이유는, 보통 이 AS가 데이터센터에 입주한 고객에게 별도로 할당되는 경우가 매우 드물고, 따라서 고객이 데이터센터의 ISP 와의 연결에 Static 라우팅을 사용하는 경우가 대부분이기 때문이다. 실제 수년간 필드에서 잔뼈가 굵으신 엔지니어 분들 께서도 BGP 구성에 직접 참여하게 되면 먼지쌓인 책을 다시 살펴봐야 하는 경우가 허다 했다. 

어쨌든 이는 라우팅 프로토콜이기 때문에, 라우터 A 에서 라우터 Z 로 가기 위한 여러개의 경로를 동적으로 할당하는 것이 가능해 진다. 물론 이러한 목적을 위해 BGP 만 존재하는 것은 아니며, RIP, OSPF 등의 수많은 프로토콜이 존재한다. 그런데 왜 여기서 갑자기 BGP를 꺼내들었는가. 그 이유를 살펴 보자. 


1. 최근 데이터 센터 구성에 사용하는 24-48 포트 10G 스위치는 L3 기반인 경우가 많고, 이 L3 스위치들은 BGP 운용이 가능하다. 바꾸어 말하면, 10G 24-48 포트 라우터로 사용 할 수 있다.  

2. iBGP 를 사용하여 Backbone / Aggregation 을 클라우드 망으로 구성할 수 있다. 무슨 이야기인고 하니, 모든 스위치가 라우터로 동작 하므로, 어느 한 지점의 장애에 구애 받지 않게 된다.

3. ECMP 를 사용하여 수없이 발생하게 될 경로에 대한 최대한의 대역폭 사용이 가능해 진다.

4. 장애가 발생한 경우 그 전파가 매우 빠르고, 전체 망이 한꺼번에 다운될 확률이 낮아진다.

5. 각 랙에서 발생하는 L2 통신은 랙 내부로 고립되고, 이 랙에서 돌리는 각 VM의 상태가 백본 레벨로 전달 될 염려가 없다. 랙 장애는 랙 장애에 국한된다.

6. 일단 백본이 구성되고 나면, 어느 경로에든 ToR 을 원하는 형태로 가져다 붙일 수 있다.  따라서 진정한 Scale-out 이 사용 가능한 IP 대역이 떨어질 때 까지 확장 가능하다. 

위의 장점 이외에도, 다른 수많은 장점이 있을 수 있다고 본다. 물론 굳이 iBGP 가 아니라, 각 랙에 사설 AS 를 할당하여 백본과 eBGP를 구성하는 방법도 있을 수 있다. 어떠한 구성의 방법이 더 좋은지의 여부는 네트워크 벤더별로 다를 수 있으며, 경우에 따라 ECMP 를 원활하게 지원하지 않는 경우도 있으니 확인을 꼭 해 볼일이다. 


현재 일을 하고 있는 회사에서 국내에 Arista 를 배포하고 있어, 장비를 가져다가 테스트 해 볼 수 있었다.
테스트 환경은,

- Arista 7124SX   5대
- 일반 Quanta 서버 3대

였으며, 테스트를 위한 컨셉은 다음과 같다. 

iBGP Test Concept



그림은, 각 랙은 서로 다른 24bit 의 네트워크를 가지며, ToR 을 지나는 순간 iBGP 를 사용하여 다른 랙으로 라우팅 된다. 이때 ToR 회서는 각각의 백본에 연결되며, 이 서로 다른 라우팅 Path 에 모두 ECMP 를 적용하게 된다. 

컨셉이 이렇다면, 실제 백본의 할당은 다음과 같다. 

IP Allocation


 
172 네트워크는 관리를 위한 별도의 망이며, 구성된 모든 장치에 연결되어 있다. 실제 트래픽은 푸른색의 회선을 통해 실리게 된다. 이렇게 환경에 대한 구성이 끝났다면, 이제 실제 각 스위치를 설정한다. 

백본은 백본끼리 서로 동일하며, ToR 설정은 각각 모두 동일하기 때문에 샘플로 하나씩만 싣도록 한다.

먼저, Backbone #1 의 설정
....
...
..
interface Ethernet1
   no switchport
   ip address 10.100.100.18/30
!
interface Ethernet2
!
interface Ethernet3
....
..
!
interface Ethernet22
!
interface Ethernet23
   no switchport
   ip address 10.100.100.1/30
!
interface Ethernet24
   no switchport
   ip address 10.100.100.5/30
!
interface Management1
   ip address 172.17.17.91/24
!
ip route 0.0.0.0/0 Null0 255
!
ip routing
!
router bgp 100
   bgp log-neighbor-changes
   neighbor 10.100.100.2 remote-as 100
   neighbor 10.100.100.2 update-source Ethernet23
   neighbor 10.100.100.2 maximum-routes 12000 
   neighbor 10.100.100.6 remote-as 100
   neighbor 10.100.100.6 update-source Ethernet24
   neighbor 10.100.100.6 maximum-routes 12000 
   neighbor 10.100.100.17 remote-as 100
   neighbor 10.100.100.17 update-source Ethernet1
   neighbor 10.100.100.17 maximum-routes 12000 
   network 0.0.0.0/0
!
management telnet
   no shutdown
!
!
end

이제, ToR #1 의 설정을 살펴보자.
.....
...
.
vlan 10
!
interface Port-Channel10
   switchport access vlan 10
!
interface Ethernet1
   switchport access vlan 10
   channel-group 10 mode active
!
interface Ethernet2
   switchport access vlan 10
   channel-group 10 mode active
!
interface Ethernet3
   switchport access vlan 10
!
.....
...
..
!
interface Ethernet22
   switchport access vlan 10
!
interface Ethernet23
   no switchport
   ip address 10.100.100.2/30
!
interface Ethernet24
   no switchport
   ip address 10.100.100.14/30
!
interface Management1
   ip address 172.17.17.93/24
!
interface Vlan10
   ip address 10.1.1.254/24
!
ip routing
!
router bgp 100
   bgp log-neighbor-changes
   timers bgp 30 90
   maximum-paths 2 ecmp 2
   neighbor 10.100.100.1 remote-as 100
   neighbor 10.100.100.1 maximum-routes 12000
   neighbor 10.100.100.13 remote-as 100
   neighbor 10.100.100.13 maximum-routes 12000
   network 10.1.1.0/24
!
management telnet
   no shutdown
!
!
end

이렇게 설정하게 되면, 위의 다이어그램과 같이 원하는 대로 망이 동작하게 된다. 아래의 스크린샷은 각 스위치에 sflow 를 걸어두고, 서버 1대에서 다른 2개의 ToR 로 트래픽을 발생 시켰을 때 볼 수 있는 그림이다.

sflow when 2 paths from single server



네트워킹을 전문으로 하시는 분이라면 위의 null0 라우팅 부분을 의아하게 생각 하실 수 있겠다. 이는 이렇게 구성된 망이 폐쇠망이고 외부로 별도의 경로가 없기 때문에, 모든 ToR 에 default 라우팅을 전파하기 위해 별도로 구성된 설정으로 이해 해 주시면 된다. 또한, 경우에 따라 백본에 neighbor x.x.x.x route-reflect-client 를 구성하여 모든 ToR 에 다른 ToR 의 경로를 전파 할 수도 있겠다. 물론 여기서는 어쨌든 백본으로 모든 트래픽을 보내기 때문에, 백본에서 별도로 RR-client 설정을 넣어 주지는 않았다.

ToR 에서 살펴본 ip routing 정보. 
TOR-1#sh ip route 0.0.0.0/0
Codes: C - connected, S - static, K - kernel, 
       O - OSPF, IA - OSPF inter area, E1 - OSPF external type 1,
       E2 - OSPF external type 2, N1 - OSPF NSSA external type 1,
       N2 - OSPF NSSA external type2, B I - iBGP, B E - eBGP,
       R - RIP, A - Aggregate

Gateway of last resort:
 B I    0.0.0.0/0 [200/0] via 10.100.100.1
                          via 10.100.100.13

이러한 스위치가 가지는 장점을 백분 활용함으로서 해 볼 수 있는 것들은 정말로 많이 있다.
기존에는 생각하지 못했던 방법, 보다 스케일링이 가능한 방법. 

네트워크 엔지니어만 알고 있어서 되는게 아니고, 서버 엔지니어라고 해서 네트워크를 모르면 안되는 것과 같은 이치이다. 한 구간만 생각한다면 이러한 룰이 나올 수 있을리 없다고 생각한다. 

최근 클라우드 아키텍팅에서의 트렌드는, 기존의 L2 + L3 구성을 버리고 모두 L3 를 사용하는 방법이다. 위의 설정은 단순히 이러한 구성 및 컨셉을 확인하기 위한 용도에 지나지 않으며, 서비스에 구성하기 위해서는 보다 나은 timer 설정등이 필요하게 될 것이다. 또한, 백본을 다중화 하는 방법도 충분히 실현이 가능하다. 


이 포스팅에 굳이 MLAG 구성의 그림을 넣지 않은 이유는, BGP 의 활용에 대해서 더 살펴보기 위함이었다. 필요하신 분들 께서는 구글에서 MLAG 이라는 검색어만 넣어도 수없이 많이 떠오르는 내용을 보실 수 있을 것이다. 


본 설정을 완료하기 위해 도움을 주신 분들이 계시다. 간단히 소개를 해 보자면, 

Dan Mihai Dumitriu ( CEO/CTO at Midokura )
Nishizawa, Satoshi ( Network expert at Midokura ) 
이정호 차장님 ( Arista Korea )

또한, 고생 해 준 우리 장비들에게도 쌩유. 

Arista 7124SX


 
네트워킹에 고민하고 계신 분들께 조금이나마 도움이 되었으면 하며, 혹시라도 가져가실때는 출처를 남겨 주시길.
조만간 eBGP 도 테스트 해 볼 예정. 

( younjin.jeong@gmail.com, 정윤진 ) 
저작자 표시 비영리
Posted by YZ Cerberos 트랙백 0 : 댓글 2
( younjin.jeong@gmail.com, 정윤진) 

요새 라우터의 기능이나 성능 때문에 리눅스를 대용으로 사용 하려는 경향은 거의 없다. 하지만 Cisco 가 실리콘 밸리의 떠오르는 샛별이 되던 그 시절 즈음 해서, 아마도 ISA 버스를 사용하는 이더넷 랜카드가 대부분이던 그 시절에, LRP ( Linux Router Project ) 라는게 있었다. 지금이야 다들 Cisco 의 config를 모델로한 대부분의 상용 라우터를 사용하지만, 궁했던 그때에는 이런 리눅스 기반 라우터를 많이들 사용하곤 했더랬다.  플로피 디스켓의 추억이 떠올라 검색을 좀 해 보니, 이런 글이.  리눅스로 라우터 만들기

관련하여 LEAP (Linux Embedded Appliance Project) 라는 프로젝트도 있는데, 좀 재미있어 보이는 듯. 역시 좀 오래된 프로젝트인데, 마지막 업데이트가 언제인지는 잘 모르겠다.

http://leaf.sourceforge.net/index.php?module=pagemaster&PAGE_user_op=view_page&PAGE_id=4&MMN_position=18:18
http://sourceforge.net/projects/leaf/files/


아무튼 요새는 이런 정도로 사용 할 필요는 없지만, 간혹, 아주 간혹 시스템 내부에서 간단한 라우팅 프로토콜 설정이 필요한 경우가 있을 수 있다. 단순히 Static 라우팅이 아닌, rip 또는 ospf, 경우에 따라서는 bgp 정도의 구성이 필요한 경우가 있다. 이럴때 간단하게 사용 할 수 있는 도구가 바로 Quagga인데, 필요한 데몬의 조합으로 원하는 구성이 가능하다.

zebra : static 라우팅 및 인터페이스 정의
bgpd :  BGP 라우팅
ospfd :  OSPF
ospf6d : OSPF IPv6
ripd : RIP v2
ripngd : RIP IPv6


다음의 페이지에 간단한 샘플 구성이 있기에 가져와 보았다.
http://www.readytechnology.co.uk/open/bgp/loadbalanced.html

 

이런식의 이중화 구성을 사용하는데가 아직 있는지는 모르겠지만, 어쨌든 필요하면 할 수도 있는 것이므로 간단한 설정의 예제로서 참고하도록 한다.

위의 네트워크 다이어그램에서의 조건은 다음과 같다.

  • r1 과 r2 는 FreeBSD & Quagga 조합의 라우터일 수도 있고, Cisco 7204/7206 일 수도 있다. 어쨌든 분명한건 라우터이다.
  • 각 라우터는 각각의 ISP와 연결되어 있다. 
  • 2950 스위치 2대는 각각 서로 다른 사설 네트워크로 구성되어 있다. (192.168.1.0/24 , 192.168.2.0/24)
  • 이 조직은 외부 서비스 연결을 위해 공인 IP 블럭을 가지고 있다. 각 내부 호스트들은 루프백 인터페이스에 /32 넷마스크의 공인 IP를 하나씩 가지고 있다. 따라서, NAT 구성이 반드시 필요하지는 않다.
  •  각 서버는 리눅스로 동작하고 있으며, 이들의 커널은 Equal Cost Multi-Path 라우팅이 활성화 된 상태로 컴파일 된 것을 사용한다. 이는, 커널이 라우팅 테이블에 다수의 기본 게이트웨이를 가지도록 구성이 가능하므로, 외부로 전달되는 트래픽의 분산이 가능하다. ( 커널 config 옵션은 CONFIG_IP_ROUTE_MULTIPATH=y )
  •  전체 서버에서의 기본 게이트웨이를 포함한 라우팅 구성은 절대 수동으로 하지 않는다. 대신, Quagga 를 전체 서버에 구성하도록 한다. 내부의 서버들에서는, Quagga 의 OSPF를 사용하여 라우터의 주소를 설정하도록 구성 할 것이다.
  • 각각의 라우팅이 장비의 문제 등으로 인해 사용이 불가능한 경우에는, OSPF 프로토콜에 의해 5초 이내로 장애가 감지되며, 이후 라우팅 테이블에서 해당 경로를 삭제한다.
  • OSPF를 사용하여 장애를 감지하는 것이 최선 일 수 있다. 이는 OSPF 가 IP 계층을 기반으로 동작하기 때문이다. 만약 r2에 연결된 2950 에 케이블 문제가 발생한다 하더라도, OSPF는 이러한 상황을 잘 처리 할 수 있을 것이다.  

위의 구성을 바탕으로, 실제 서비스를 구성해 보면 된다. 예제에서는 데비안 리눅스를 사용하였으므로, 이변이 없다면 그냥 우분투를 사용해도 무방하겠다. 공인 IP 주소는 A.B.C.D 로 표현 되었음에 주의 하자.

Quagga 설치
      apt-get update
      apt-get install quagga iproute

리눅스 인터페이스 설정. 당연히 우분투에서는 /etc/network/interfaces

auto lo
iface lo inet loopback
  up ip addr add dev lo A.B.C.D/32 scope global

# notice that we use `manual' rather than `static', so that we can
# over-ride the scope parameter
auto eth0
iface eth0 inet manual
  up ip link set dev eth0 up
  up ip addr add dev eth0 192.168.1.10/24 scope link

auto eth1
iface eth1 inet manual
  up ip link set dev eth1 up
  up ip addr add dev eth1 192.168.2.10/24 scope link

아래의 내용을 /etc/quagga/zebra.conf 에 구성

      hostname www1
      password changeme
      enable password changeme

      interface lo
        ip address 127.0.0.1/8
        ip address A.B.C.D/32       (this is your server's real IP)

      interface eth0
        ip address 192.168.1.10/24
        multicast

      interface eth1
        ip address 192.168.2.10/24
        multicast

     !log file /var/log/quagga/zebra.log
    
아래의 내용을 /etc/quagga/ospfd.conf 에 적용

hostname www1
password changeme
enable password changeme

interface eth0
 no ip ospf authentication-key
 ip ospf hello-interval 2
 ip ospf dead-interval 5

interface eth1
 no ip ospf authentication-key
 ip ospf hello-interval 2
 ip ospf dead-interval 5

router ospf
  ospf router-id A.B.C.D
  network 192.168.1.0/24 area 0
  network 192.168.2.0/24 area 0

!log file /var/log/quagga/ospfd.log

/etc/quagga/daemons.conf 를 수정.  set zebra=yes 및 ospfd=yes


확인

설정이 완료된 호스트를 재부팅 한다. 재부팅이 완료 되면, ip route 커맨드를 사용하여 여러개의 기본 게이트웨이가 있는지의 여부를 확인한다. 이후에는 라우터 또는 회선을 분리하여 OSPF가 잘 동작하는지 확인 할 수 있을 것이다.

위의 내용 대로 설정 했음에도 불구하고 잘 동작하지 않는다면, 다음의 내용을 확인 해 보도록 한다.

  • 커널이 Equal Cost Multi-Path 설정이 된 상태로 컴파일 되어있는지 확인한다.
  • 커널에서 Multicast 가 활성화 되어 있는지 확인한다. 또한, NIC 및 드라이버가 이를 지원하는지의 여부를 확인하도록 한다.
  • iptables 에 의해 OSPF 가 막혀 있지는 않은지 확인 한다. 만약 기존의 정책에 추가해야 할 필요가 있다면, 다음의 커맨드를 참조한다.
    iptables --insert INPUT -s 192.168.0.0/16 --protocol ospf -j ACCEPT


이는 예제를 통해서 간단하게 살펴 본 것이므로, 보다 더 알고 싶은 경우에는 구글 검색을 해 보면 되겠다. 다음의 링크에 잘 정리된 Tutorials 가 있으므로 참조 하도록 한다.

Quagga Tutorials


( younjin.jeong@gmail.com, 정윤진)






저작자 표시 비영리
Posted by YZ Cerberos 트랙백 0 : 댓글 0