2012년 7월 30일 월요일
구글 TV 서비스 시작, 구글 파이버(Google Fiber) 발표
7월26일 구글에서 구글 파이버(Google Fiber) 서비스를 발표하였다. 내용은 100 배 빠른 인터넷 서비스를 제공하겠다는 것이고, 이것은 고객들이 기존보다 훨씬 나은 환경의 다양한 서비스를 이용할 수 있도록 하겠다는 것이다. 이 서비스는 전체를 대상으로 하는 것이 아니라 시범적으로 미 캔자스에서만 우선 제공하는 것이다.
검색전문업체인 구글에서 직접 인터넷 서비스 영역까지 뻗어나가고 있는 것인데, 빠른 속도를 통해 구글이 보여줄 것들은 무엇이 있을지 기대가 된다. 지금 시점에서는 HD 수준의 비디오와, 빠른 속도의 전송을 기반으로 한 다양한 연계 서비스들이 있다. 구글의 계획했던 구글 TV 의 본격적인 행보가 이어질 것이다.
예를 들면, 여러개의 디바이스에서 화면을 쉽게 볼 수 있고 (N 스크린) 동시에 8개의 프로그램을 레코딩 할 수도 있다. 2 테라 저장 공간을 지원하기 때문이다.
서비스 계획을 보면 기가비트 인터넷에 티비를 같이 이용할 경우 월/120 달러를 지불하면 된다. 기가비트 인터넷은 월/70 에 제공한다. 중요한 것은 무료로 인터넷도 제공한다. 물론 초기에 설치비용인 $300 을 지불하면 된다. ( 한번에 지불하거나 또는 월 25불씩 1년동안 지불할 수 있다) 무료로 제공되는 인터넷은 기가비트 인터넷이 아니라 일반적으로 현재 이용되는 인터넷 속도로 5Mbps 다운로드와 1Mbps 의 업로드 속도이다. 이 서비스는 최소 7년 동안은 보장된다고 하며, 언제든 파이버 서비스로 업그레이드 할 수 있다.
기가비트 인터넷과 TV 를 이용하면 요새 인기를 끌고 있는 넥서스 7 타블릿과 티비박스, 스토리지 박스, 네트워크 박스, 1테라 구글 드라이브를 모두 제공한다. 스토리지 박스는 2테라 공간으로 동영상뿐만 아니라, 사진, 음악등도 저장하여 집안에서는 어디서나 접근할 수 있게 된다.
현재 사전 등록을 받고 있으며, 이것은 9월 9일까지 진행된다. 그리고 9월 10일 구글 파이버 서비스를 이용할 수 있다. 1기가 속도의 업 다운 속도라면 다양한 서비스를 제공하는데 있어서 고객과 구글과의 관계는 기반이 구성된 것이다. 더불어 홈네트워크 서비스를 하기 위한 디바이스 또한 제공하므로, 지금 우리가 단순히 일방적으로 전달받는 정보 구조에서 많은 변화가 있을 것이다.
개인적으로는 구글의 네트워크 인프라 운영면에서도 상당한 기술을 가지고 있다고 생각한다. 생각보다 꽤 큰 규모의 망을 운영하고 있고, SDN(Software Defined Network) 에서도 상당히 앞서나가고 있다. 기가비트 네트워크가 일반 가정으로까지 확대된다니, 정말 과거와 비교해 보면 인프라 환경은 너무나 달라졌다. 하이텔 전용 접속 장치를 통해서 인터넷을 하던때가 엊그제 같은데 집 까지 기가비트의 망이 연결된다고 하니 말이다.
빠른 서비스를 제공받아서 좋긴 한데, 엔지니어들은 계속 고민이 커질 것 같다. 빠른 속도를 제공함에 따라 고려해야 할 이슈들이 많아질 것이기 때문이다. 네트워크 패킷 뜨는 일도 더 힘들어 질것만 같다. 계속 증대되는 고속 전송은 수 많은 패킷안에서 내가 찾고자 하는 것이 더욱 어려워 질 것이다.
구글 파이버에 대한 자세한 내용은 다음 사이트를 방문해 보길 바란다.
http://fiber.google.com
2012년 7월 24일 화요일
전문가와 기술자의 차이
몇일 전 이메일을 통해서 보게 된 '행복한 경영이야기'. 제목인즉, 전문가와 기술자의 차이입니다.
여러분들이 생각하는 전문가란 무엇이며? 또 기술자와의 차이는 무엇이라고 생각합니까?
우선, 내용을 한번 들여다 보도록 하죠.
어떤가요? 저는 특히 '열정' 이라는 부분에 동감이 많이 갑니다.
열정이 있어야 일도 재미있게 할 수 있고, 끈기를 가지고 이어갈 수 있다는 생각이 듭니다.
한통의 메일을 받아 보고,
많이 생각해 보게 되었습니다. 지금의 나는 전문가인가 기술자인가를 말이죠....
여러분들이 생각하는 전문가란 무엇이며? 또 기술자와의 차이는 무엇이라고 생각합니까?
우선, 내용을 한번 들여다 보도록 하죠.
"전문가와 기술자의 차이"
그 사람이 가진 기술적인 역량 때문에,
고객에게 훌륭하다는 소리를 듣는 전문가는 극히 드물다.
전문가의 반대말은 비전문가가 아니라 기술자이다.
전문성은 능력이 아니라 대부분 태도에 달려 있다.
진정한 전문가는 열정을 가진 기술자다.
사람들은 당신이 얼마나 열정이 있는지 알기 전에는
당신이 얼마나 아는지에 관심 없다.
전문가는 존경을 받지만,
기술자라고 다 존경받지는 못합니다.
모든 핵심인재는 재능과 더불어
반드시 열정을 포함한 바람직한 태도를 보유한 사람들입니다.
특히 조직과 일, 목표에 헌신할 수 없는 사람은
더 높은 직위에 올라가는 것을 스스로 거부할 수 있어야 합니다.
어떤가요? 저는 특히 '열정' 이라는 부분에 동감이 많이 갑니다.
열정이 있어야 일도 재미있게 할 수 있고, 끈기를 가지고 이어갈 수 있다는 생각이 듭니다.
한통의 메일을 받아 보고,
많이 생각해 보게 되었습니다. 지금의 나는 전문가인가 기술자인가를 말이죠....
2012년 7월 13일 금요일
여러개의 네트워크 인터페이스를 하나로! Bonding 하기
오늘은 bonding 기술에 대해서 다뤄보고자 한다. 이것은 여러개의 네트워크 인터페이스를 하나로 만들어 이더넷 카드 장애 또는 링크 Fail 에 대해 대비를 할 수 있다. 또한 로드발랜스를 구현할 수 있으며, 자연스럽게 Fault tolerance 를 보장해주어 고장 허용한계를 최소화 할 수도 있겠다. 스위치 장비 같은것에서 보면 "채널본딩", "트렁킹" 같은 기술들이 이와 이론적으로는 유사하다고 할 수 있다.
여기서는 리눅스를 기반으로 설정하는 방법을 다뤄볼 것이다. 대부분의 배포용 리눅스에는 이미 본딩 드라이버를 이용할 수 있다. 가장 쉽게 설치해 볼 수 있는 방법은 각 배포판에서 제공해주는 패키지 도구를 이용하면 된다. 데비안, 우분투의 경우는 apt-get 를 이용해 설치할 수 있다.
설치가 되었으면, bonding 모듈이 올라가 있는 것을 확인할 수 있다.
# lsmod | grep bon
bonding 73991 0
이제 사용할 준비는 되었으니 설정만 해 주면 된다. 수동으로 명령어를 통해 다음과 같은 형태로 잡아줄 수도 있으나,
# modprobe bonding
# ifconfig bond0 192.168.0.1 netmask 255.255.0.0
# ifenslave bond0 eth0 eth1
아래와 같은 방법을 통해 설정파일에 내용을 기록해 두고 사용하는 편이 훨씬 수월하다. bond0 라는 이름이 이제 우리가 설정할 bonding 인터페이스이다.
위 내용중에서 아래 5라인 정도가 실제 bonding 과 관련된 내용이다. 인터페이스 bond0 에 192.168.0.1 IP 를 설정하고 동작모드로 balance-tlb 를 설정하였다. 이 모드는 Active slave 모드로 슬레이브로 설정된 인터페이스에서 들어오는 트래픽을 받는다.
bond-miimon 은 링크 모니터링 주기를 설정하는 것으로 100 밀리세컨드로 지정하였다.
bond-downdelay 는 링크 Fail 이 감지된 후 Slave 를 중지시키기전 대기할 시간을 정의한 것이다. bond-updelay 는 downdelay 와 반대로 링크가 복구된 후 slave 를 재 동작하기까지 대기할 시간이다. 그리고 마지막으로 slaves 를 통해 실제 본딩에 사용될 인터페이스 eth0 과 eth1 을 지정했다.
커널상에서는 가상의 bond0 를 통해 통신되며 실제 모든 통신은 slave 를 통해서 이뤄진다는 점이다.
bond-mode 는 다양하게 존재하는데 몇 가지를 알아보면 다음과 같다.
모든 슬레이브 인터페이스로 전송한다
적절하게 로드 발랜싱 역할을 수행한다. Outbound 트래픽은 각 슬래이브의 로드를 고려해 분산되며, Incoming 트래픽은 현재 설정된 슬레이브로 받게 된다. 만약 트래픽을 받고 있는 슬레이브가 Fail 되면 다른 슬레이브가 MAC 주소를 이어받아 계속 트래픽을 전달 받을 수 있다.
적절하게 로드 발랜싱 역할을 수행한다는 측면에서 balance-tlb 와 같다. 그런데 여기에 추가로 트래픽을 받는 부분에 있어서도 로드발랜싱을 수행한다. 이것은 ARP negotiation 을 통해서 동작하게 된다.
내가 설정한 Bonding 이 잘 동작하고 있는지 확인하려면 간단하게는 /proc/net/bonding/bond0 를 살펴보면 된다. 그러면 현재 설정된 정보를 볼 수 있는데, Bonding mode 는 transmit load balancing 으로 되어 있고 Up Delay 나 Down Delay 등이 위 설정파일에 설정한 것과 동일하게 정의되어 있다.
또는 ifconfig 를 통해 설정한 bonding 인터페이스인 bond0 가 있는지 확인해 볼 수도 있다.
bond0 Link encap:Ethernet HWaddr 84:XX:XX:XX:10:1c
inet addr:192.168.0.1 Bcast:192.168.0.255 Mask:255.255.255.0
inet6 addr: fe80::862b:2bff:fefa:101c/64 Scope:Link
UP BROADCAST RUNNING MASTER MULTICAST MTU:1500 Metric:1
RX packets:64861 errors:0 dropped:0 overruns:0 frame:0
TX packets:2542 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:4984737 (4.7 MiB) TX bytes:176928 (172.7 KiB)
eth0 Link encap:Ethernet HWaddr 84:XX:XX:XX:10:1c
UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1
RX packets:32694 errors:0 dropped:0 overruns:0 frame:0
TX packets:1278 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2510260 (2.3 MiB) TX bytes:90488 (88.3 KiB)
Interrupt:36 Memory:d6000000-d6012800
eth1 Link encap:Ethernet HWaddr 84:XX:XX:XX:10:1e
UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1
RX packets:32167 errors:0 dropped:0 overruns:0 frame:0
TX packets:1264 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2474477 (2.3 MiB) TX bytes:86440 (84.4 KiB)
Interrupt:48 Memory:d8000000-d8012800
여기 인터페이스 정보를 보면 우선 설정한 bond0 가 보이고 그 아래 eth0, eth1 은 RUNNING SLAVE 로 동작하는 것이 보인다. eth0 은 맥 뒷자리가 10:1c 이고 eth1 은 10:1e 이다. bond0 를 보면 10:1c 로 되어 있다. 즉 현 시점에서 Active Slave 는 eth0 이 되는 것이다.
만약 eth0 인터페이스의 링크가 Fail 되면 eth1 이 맥 주소를 넘겨받아 10:1e 가 아닌 10:1c 상태가 되어 버린다. 이것은 bonding 을 구성후 랜 케이블을 뽑아보면 쉽게 살펴볼 수 있다.
링크 Fail 을 감지하면 앞서 설명한 것과 맥 주소를 넘겨받는 다고 하였는데, 이런 동작 과정이 /var/log/message 에 상세히 기록되어 있다.
Jul 6 00:18:36 test kernel: [ 4.227038] bonding: bond0: Setting down delay to 200.
Jul 6 00:18:36 test kernel: [ 4.233007] bonding: bond0: doing slave updates when interface is down.
Jul 6 00:18:36 test kernel: [ 4.233012] bonding: bond0: Adding slave eth0.
Jul 6 00:18:36 test kernel: [ 4.233014] bonding bond0: master_dev is not up in bond_enslave
Jul 6 00:18:36 test kernel: [ 4.335328] bnx2: eth0: using MSIX
Jul 6 00:18:36 test kernel: [ 4.337600] bonding: bond0: enslaving eth0 as an active interface with a down link.
Jul 6 00:18:36 test kernel: [ 4.380870] bonding: bond0: doing slave updates when interface is down.
Jul 6 00:18:36 test kernel: [ 4.380875] bonding: bond0: Adding slave eth1.
Jul 6 00:18:36 test kernel: [ 4.380878] bonding bond0: master_dev is not up in bond_enslave
Jul 6 00:18:36 test kernel: [ 4.463151] bnx2: eth1: using MSIX
Jul 6 00:18:36 test kernel: [ 4.465304] bonding: bond0: enslaving eth1 as an active interface with a down link.
Jul 6 00:18:36 test kernel: [ 4.470976] ADDRCONF(NETDEV_UP): bond0: link is not ready
Jul 6 00:18:38 test kernel: [ 7.540376] bnx2: eth0 NIC Copper Link is Up, 1000 Mbps full duplex
Jul 6 00:18:38 test kernel: [ 7.560033] bonding: bond0: link status up for interface eth0, enabling it in 0 ms.
Jul 6 00:18:38 test kernel: [ 7.560037] bonding: bond0: link status definitely up for interface eth0.
Jul 6 00:18:38 test kernel: [ 7.560041] bonding: bond0: making interface eth0 the new active one.
Jul 6 00:18:38 test kernel: [ 7.560065] bonding: bond0: first active interface up!
Jul 6 00:18:38 test kernel: [ 7.562122] ADDRCONF(NETDEV_CHANGE): bond0: link becomes ready
Jul 6 00:18:39 test kernel: [ 7.668144] bnx2: eth1 NIC Copper Link is Up, 1000 Mbps full duplex
Jul 6 00:18:39 test kernel: [ 7.759691] bonding: bond0: link status up for interface eth1, enabling it in 200 ms.
Jul 6 00:18:39 test kernel: [ 7.959351] bonding: bond0: link status definitely up for interface eth1.
위 로그를 보면 알 수 있듯이 eth0 링크가 문제 생기면서 eth1 으로 slave 가 변경되는 과정을 알 수 있다.
Bonding 구성을 완료후에는, 정상적으로 잘 동작하는지 랜 케이블 선을 제거해 보는 것과 같이 테스트 과정을 거치는 것이 필요하다. 최근의 서버급 장비들은 하나의 랜 카드에 4개의 이더넷 포트가 달려 있는 경우도 많이 있다. 시스템의 사용용도에 따라 이와 같이 설정해 사용해 보는 것은 어떨까 한다.
실제로 사용해 보면 아주 간단하고도 쉽게 구성할 수가 있다.
[참고]
1. 리눅스 파운데이션 : bonding
http://www.linuxfoundation.org/collaborate/workgroups/networking/bonding
여기서는 리눅스를 기반으로 설정하는 방법을 다뤄볼 것이다. 대부분의 배포용 리눅스에는 이미 본딩 드라이버를 이용할 수 있다. 가장 쉽게 설치해 볼 수 있는 방법은 각 배포판에서 제공해주는 패키지 도구를 이용하면 된다. 데비안, 우분투의 경우는 apt-get 를 이용해 설치할 수 있다.
# apt-cache search ifenslave
ifenslave-2.6 - Attach and detach slave interfaces to a bonding device
# apt-get install ifenslave-2.6
설치가 되었으면, bonding 모듈이 올라가 있는 것을 확인할 수 있다.
# lsmod | grep bon
bonding 73991 0
Bonding 인터페이스 설정
이제 사용할 준비는 되었으니 설정만 해 주면 된다. 수동으로 명령어를 통해 다음과 같은 형태로 잡아줄 수도 있으나,
# modprobe bonding
# ifconfig bond0 192.168.0.1 netmask 255.255.0.0
# ifenslave bond0 eth0 eth1
아래와 같은 방법을 통해 설정파일에 내용을 기록해 두고 사용하는 편이 훨씬 수월하다. bond0 라는 이름이 이제 우리가 설정할 bonding 인터페이스이다.
# cat /etc/network/interface
auto bond0
iface bond0 inet static
address 192.168.0.1
netmask 255.255.255.0
gateway 192.168.0.254
bond_mode balance-tlb
bond_miimon 100
bond_downdelay 200
bond_updelay 200
slaves eth0 eth1
위 내용중에서 아래 5라인 정도가 실제 bonding 과 관련된 내용이다. 인터페이스 bond0 에 192.168.0.1 IP 를 설정하고 동작모드로 balance-tlb 를 설정하였다. 이 모드는 Active slave 모드로 슬레이브로 설정된 인터페이스에서 들어오는 트래픽을 받는다.
bond-miimon 은 링크 모니터링 주기를 설정하는 것으로 100 밀리세컨드로 지정하였다.
bond-downdelay 는 링크 Fail 이 감지된 후 Slave 를 중지시키기전 대기할 시간을 정의한 것이다. bond-updelay 는 downdelay 와 반대로 링크가 복구된 후 slave 를 재 동작하기까지 대기할 시간이다. 그리고 마지막으로 slaves 를 통해 실제 본딩에 사용될 인터페이스 eth0 과 eth1 을 지정했다.
커널상에서는 가상의 bond0 를 통해 통신되며 실제 모든 통신은 slave 를 통해서 이뤄진다는 점이다.
bond-mode 는 다양하게 존재하는데 몇 가지를 알아보면 다음과 같다.
- balance-rr
- active-backup
- balance-xor
- broadcast
모든 슬레이브 인터페이스로 전송한다
- balance-tlb
적절하게 로드 발랜싱 역할을 수행한다. Outbound 트래픽은 각 슬래이브의 로드를 고려해 분산되며, Incoming 트래픽은 현재 설정된 슬레이브로 받게 된다. 만약 트래픽을 받고 있는 슬레이브가 Fail 되면 다른 슬레이브가 MAC 주소를 이어받아 계속 트래픽을 전달 받을 수 있다.
- balance-alb
적절하게 로드 발랜싱 역할을 수행한다는 측면에서 balance-tlb 와 같다. 그런데 여기에 추가로 트래픽을 받는 부분에 있어서도 로드발랜싱을 수행한다. 이것은 ARP negotiation 을 통해서 동작하게 된다.
Bonding 이 잘 동작하고 있는지의 확인은 ?
내가 설정한 Bonding 이 잘 동작하고 있는지 확인하려면 간단하게는 /proc/net/bonding/bond0 를 살펴보면 된다. 그러면 현재 설정된 정보를 볼 수 있는데, Bonding mode 는 transmit load balancing 으로 되어 있고 Up Delay 나 Down Delay 등이 위 설정파일에 설정한 것과 동일하게 정의되어 있다.
# cat /proc/net/bonding/bond0
Ethernet Channel Bonding Driver: v3.5.0 (November 4, 2008)
Bonding Mode: transmit load balancing
Primary Slave: None
Currently Active Slave: eth0
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 200
Down Delay (ms): 200
Slave Interface: eth0
MII Status: up
Link Failure Count: 1
Permanent HW addr: 84:XX:XX:XX:10:1c
Slave Interface: eth1
MII Status: up
Link Failure Count: 1
Permanent HW addr: 84:XX:XX:XX:10:1e
또는 ifconfig 를 통해 설정한 bonding 인터페이스인 bond0 가 있는지 확인해 볼 수도 있다.
bond0 Link encap:Ethernet HWaddr 84:XX:XX:XX:10:1c
inet addr:192.168.0.1 Bcast:192.168.0.255 Mask:255.255.255.0
inet6 addr: fe80::862b:2bff:fefa:101c/64 Scope:Link
UP BROADCAST RUNNING MASTER MULTICAST MTU:1500 Metric:1
RX packets:64861 errors:0 dropped:0 overruns:0 frame:0
TX packets:2542 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:4984737 (4.7 MiB) TX bytes:176928 (172.7 KiB)
eth0 Link encap:Ethernet HWaddr 84:XX:XX:XX:10:1c
UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1
RX packets:32694 errors:0 dropped:0 overruns:0 frame:0
TX packets:1278 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2510260 (2.3 MiB) TX bytes:90488 (88.3 KiB)
Interrupt:36 Memory:d6000000-d6012800
eth1 Link encap:Ethernet HWaddr 84:XX:XX:XX:10:1e
UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1
RX packets:32167 errors:0 dropped:0 overruns:0 frame:0
TX packets:1264 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2474477 (2.3 MiB) TX bytes:86440 (84.4 KiB)
Interrupt:48 Memory:d8000000-d8012800
여기 인터페이스 정보를 보면 우선 설정한 bond0 가 보이고 그 아래 eth0, eth1 은 RUNNING SLAVE 로 동작하는 것이 보인다. eth0 은 맥 뒷자리가 10:1c 이고 eth1 은 10:1e 이다. bond0 를 보면 10:1c 로 되어 있다. 즉 현 시점에서 Active Slave 는 eth0 이 되는 것이다.
만약 eth0 인터페이스의 링크가 Fail 되면 eth1 이 맥 주소를 넘겨받아 10:1e 가 아닌 10:1c 상태가 되어 버린다. 이것은 bonding 을 구성후 랜 케이블을 뽑아보면 쉽게 살펴볼 수 있다.
링크 Fail 을 감지한다면?
링크 Fail 을 감지하면 앞서 설명한 것과 맥 주소를 넘겨받는 다고 하였는데, 이런 동작 과정이 /var/log/message 에 상세히 기록되어 있다.
Jul 6 00:18:36 test kernel: [ 4.227038] bonding: bond0: Setting down delay to 200.
Jul 6 00:18:36 test kernel: [ 4.233007] bonding: bond0: doing slave updates when interface is down.
Jul 6 00:18:36 test kernel: [ 4.233012] bonding: bond0: Adding slave eth0.
Jul 6 00:18:36 test kernel: [ 4.233014] bonding bond0: master_dev is not up in bond_enslave
Jul 6 00:18:36 test kernel: [ 4.335328] bnx2: eth0: using MSIX
Jul 6 00:18:36 test kernel: [ 4.337600] bonding: bond0: enslaving eth0 as an active interface with a down link.
Jul 6 00:18:36 test kernel: [ 4.380870] bonding: bond0: doing slave updates when interface is down.
Jul 6 00:18:36 test kernel: [ 4.380875] bonding: bond0: Adding slave eth1.
Jul 6 00:18:36 test kernel: [ 4.380878] bonding bond0: master_dev is not up in bond_enslave
Jul 6 00:18:36 test kernel: [ 4.463151] bnx2: eth1: using MSIX
Jul 6 00:18:36 test kernel: [ 4.465304] bonding: bond0: enslaving eth1 as an active interface with a down link.
Jul 6 00:18:36 test kernel: [ 4.470976] ADDRCONF(NETDEV_UP): bond0: link is not ready
Jul 6 00:18:38 test kernel: [ 7.540376] bnx2: eth0 NIC Copper Link is Up, 1000 Mbps full duplex
Jul 6 00:18:38 test kernel: [ 7.560033] bonding: bond0: link status up for interface eth0, enabling it in 0 ms.
Jul 6 00:18:38 test kernel: [ 7.560037] bonding: bond0: link status definitely up for interface eth0.
Jul 6 00:18:38 test kernel: [ 7.560041] bonding: bond0: making interface eth0 the new active one.
Jul 6 00:18:38 test kernel: [ 7.560065] bonding: bond0: first active interface up!
Jul 6 00:18:38 test kernel: [ 7.562122] ADDRCONF(NETDEV_CHANGE): bond0: link becomes ready
Jul 6 00:18:39 test kernel: [ 7.668144] bnx2: eth1 NIC Copper Link is Up, 1000 Mbps full duplex
Jul 6 00:18:39 test kernel: [ 7.759691] bonding: bond0: link status up for interface eth1, enabling it in 200 ms.
Jul 6 00:18:39 test kernel: [ 7.959351] bonding: bond0: link status definitely up for interface eth1.
위 로그를 보면 알 수 있듯이 eth0 링크가 문제 생기면서 eth1 으로 slave 가 변경되는 과정을 알 수 있다.
Bonding 구성을 완료후에는, 정상적으로 잘 동작하는지 랜 케이블 선을 제거해 보는 것과 같이 테스트 과정을 거치는 것이 필요하다. 최근의 서버급 장비들은 하나의 랜 카드에 4개의 이더넷 포트가 달려 있는 경우도 많이 있다. 시스템의 사용용도에 따라 이와 같이 설정해 사용해 보는 것은 어떨까 한다.
실제로 사용해 보면 아주 간단하고도 쉽게 구성할 수가 있다.
[참고]
1. 리눅스 파운데이션 : bonding
http://www.linuxfoundation.org/collaborate/workgroups/networking/bonding
2012년 7월 4일 수요일
지속적인 패킷덤프로 인한 메모리 증가
지속적인 패킷 덤프로 인해 메모리 사용률이 크게 증가할 수도 있다. 단순한 패킷 저장이면 모르겠지만, 특정한 경우에는 메모리 사용이 크게 나타났다. 예를들어, tshark 를 통해 특정 필드의 텍스트 값을 저장하는 경우다. 나의 경우가 그런것인지는 모르겠지만, 어느날 프로세스를 확인해 보니 메모리 사용이 9.7 기가나 되었다.
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
15175 root 20 0 10.1g 9.7g 28m R 3 30.8 695:36.14 tshark
TOP 을 통해서 본 것으로 VIRT 는 Virtual Image 로 tshark 에 의해 사용되고 있는 전체 가상 메모리이다. 이건 모든 코드, 데이터 그리고 공유 라이브러리, 메모리 페이지 까지 모두 포함된 것이다. RES 는 Resident Size 로 tshark 에 의해 사용된 스왑되지 않은 물리적인 메모리 양이다. 즉 RES 는 CODE + DATA 라고 할 수 있다.
시스템 활동정보를 살펴보기 위해 SAR 을 이용했고 -r 옵션을 사용하여 메모리 상태 정보를 1초 마다 출력하게 하였다.
# sar -r 1
Linux 2.6.32-5-amd64 () 05/24/2012 _x86_64_ (16 CPU)
05:20:10 PM kbmemfree kbmemused %memused kbbuffers kbcached kbcommit %commit
05:20:11 PM 105292 32898320 99.68 292348 21170036 10814820 24.15
05:20:12 PM 105808 32897804 99.68 292348 21170072 10814820 24.15
05:20:13 PM 105808 32897804 99.68 292348 21170076 10814820 24.15
05:20:14 PM 105684 32897928 99.68 292348 21170112 10814820 24.15
사용되는 메모리 양이 거의 99.68%에 달하고 있다. tshark 프로세스 ID 인 15175 를 Kill 해보도록 하겠다.
# kill 15175
# 18 packets dropped
104133176 packets captured
동작중인 프로세스가 동작을 멈추면서 정보를 남기기를 1억개의 패킷을 캡쳐했다. 프로세스 동작을 중지시키고 다시 살펴본 메모리 사용량은 약 17기가 정도가 되었다. 사용된 메모리는 이제 48.52% 가 되었다.
# sar -r 1
Linux 2.6.32-5-amd64 () 05/24/2012 _x86_64_ (16 CPU)
05:20:46 PM kbmemfree kbmemused %memused kbbuffers kbcached kbcommit %commit
05:20:47 PM 6836172 26167440 79.29 295644 14461968 10814628 24.15
05:20:48 PM 6836432 26167180 79.29 295644 14461968 10814628 24.15
05:20:49 PM 11008288 21995324 66.65 295652 14462016 10027308 22.39
05:20:50 PM 16989180 16014432 48.52 295652 14461988 348920 0.78
05:20:51 PM 16989464 16014148 48.52 295652 14461992 348920 0.78
05:20:52 PM 16989836 16013776 48.52 295652 14461992 348920 0.78
05:20:53 PM 16989852 16013760 48.52 295652 14461996 348920 0.78
05:20:54 PM 16990100 16013512 48.52 295652 14462000 348920 0.78
05:20:55 PM 16990488 16013124 48.52 295652 14462004 348920 0.78
^C
패킷을 장기적으로 덤프하는 경우, 이와 같이 메모리 사용이 커지는 경우가 발생할 수 있으므로 주의깊게 살펴보아야 한다. 모든 경우가 아니지만, 메모리 사용이 많아질 수 있는 패킷 덤프 사용에 다른 프로세스까지 영향을 주어 시스템운영에 문제를 끼칠 수 있다는 점!
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
15175 root 20 0 10.1g 9.7g 28m R 3 30.8 695:36.14 tshark
TOP 을 통해서 본 것으로 VIRT 는 Virtual Image 로 tshark 에 의해 사용되고 있는 전체 가상 메모리이다. 이건 모든 코드, 데이터 그리고 공유 라이브러리, 메모리 페이지 까지 모두 포함된 것이다. RES 는 Resident Size 로 tshark 에 의해 사용된 스왑되지 않은 물리적인 메모리 양이다. 즉 RES 는 CODE + DATA 라고 할 수 있다.
시스템 활동정보를 살펴보기 위해 SAR 을 이용했고 -r 옵션을 사용하여 메모리 상태 정보를 1초 마다 출력하게 하였다.
# sar -r 1
Linux 2.6.32-5-amd64 () 05/24/2012 _x86_64_ (16 CPU)
05:20:10 PM kbmemfree kbmemused %memused kbbuffers kbcached kbcommit %commit
05:20:11 PM 105292 32898320 99.68 292348 21170036 10814820 24.15
05:20:12 PM 105808 32897804 99.68 292348 21170072 10814820 24.15
05:20:13 PM 105808 32897804 99.68 292348 21170076 10814820 24.15
05:20:14 PM 105684 32897928 99.68 292348 21170112 10814820 24.15
사용되는 메모리 양이 거의 99.68%에 달하고 있다. tshark 프로세스 ID 인 15175 를 Kill 해보도록 하겠다.
# kill 15175
# 18 packets dropped
104133176 packets captured
동작중인 프로세스가 동작을 멈추면서 정보를 남기기를 1억개의 패킷을 캡쳐했다. 프로세스 동작을 중지시키고 다시 살펴본 메모리 사용량은 약 17기가 정도가 되었다. 사용된 메모리는 이제 48.52% 가 되었다.
# sar -r 1
Linux 2.6.32-5-amd64 () 05/24/2012 _x86_64_ (16 CPU)
05:20:46 PM kbmemfree kbmemused %memused kbbuffers kbcached kbcommit %commit
05:20:47 PM 6836172 26167440 79.29 295644 14461968 10814628 24.15
05:20:48 PM 6836432 26167180 79.29 295644 14461968 10814628 24.15
05:20:49 PM 11008288 21995324 66.65 295652 14462016 10027308 22.39
05:20:50 PM 16989180 16014432 48.52 295652 14461988 348920 0.78
05:20:51 PM 16989464 16014148 48.52 295652 14461992 348920 0.78
05:20:52 PM 16989836 16013776 48.52 295652 14461992 348920 0.78
05:20:53 PM 16989852 16013760 48.52 295652 14461996 348920 0.78
05:20:54 PM 16990100 16013512 48.52 295652 14462000 348920 0.78
05:20:55 PM 16990488 16013124 48.52 295652 14462004 348920 0.78
^C
패킷을 장기적으로 덤프하는 경우, 이와 같이 메모리 사용이 커지는 경우가 발생할 수 있으므로 주의깊게 살펴보아야 한다. 모든 경우가 아니지만, 메모리 사용이 많아질 수 있는 패킷 덤프 사용에 다른 프로세스까지 영향을 주어 시스템운영에 문제를 끼칠 수 있다는 점!
2012년 7월 2일 월요일
Bittwist 64 비트 실행에러
블로그에서도 소개한 Bittwist 를 64비트 환경에서 실행하는데, 정상적인 동작을 하지 않았다.
왜 이런 현상이 나타나는 것일까? 이 문제를 해결하기 위한 간단한 방법은 최신 버전으로 업데이트 하면 해결된다. 즉. 2.0 버전대를 사용하면 문제없이 사용 가능해진다.
처음에는 패킷파일이 잘못된 줄 알고 이래저래 헤맸는데, 결국은 프로그램적인 이슈!
64비트 환경에서 사용하는 분들이 있다면 참고하세요.
[참고]
1. 에러관련 글, bittwist: Fails to work in 64bit-systems
# bittwiste -I attack.pcap -O test.pcap
input file: attack.pcap
output file: test.pcap
bittwiste: fread(): error reading attack.pcap
# bittwiste -v
bittwiste: invalid option -- 'v'
bittwiste version 1.1
libpcap version 1.1.1
Usage: bittwiste [-I input] [-O output] [-L layer] [-X payload] [-C]
[-M linktype] [-D offset] [-R range] [-S timeframe]
[-T header] [header-specific-options] [-h]
왜 이런 현상이 나타나는 것일까? 이 문제를 해결하기 위한 간단한 방법은 최신 버전으로 업데이트 하면 해결된다. 즉. 2.0 버전대를 사용하면 문제없이 사용 가능해진다.
처음에는 패킷파일이 잘못된 줄 알고 이래저래 헤맸는데, 결국은 프로그램적인 이슈!
64비트 환경에서 사용하는 분들이 있다면 참고하세요.
[참고]
1. 에러관련 글, bittwist: Fails to work in 64bit-systems
피드 구독하기:
글 (Atom)