세상에 뿌려진 사랑만큼....

IEEE 802.3ad와 ECMP over OSPF같은 프로토콜을 사용하여 복수의 회선을 번갈아 가면서 쓰는 방법입니다.
님께서 질문하신 서버를 복수로 두는 것은 SLB라 합니다.
Server Load Balance....
이것은 일반 스위치에서는 안되구 L4스위치에서 가능합니다.
즉, 서버를 두개두고(물론 이 두개간은 미러가 되어야겠지요) 사용자가 접근할때
서버1,2를 번갈아 가면서 접속시키는 것입니다.

비교되는 것이 FLB로서 Firewall Load Balance입니다.
물론 방법은 같습니다.
(출처 : '네트워크 용어중에 NLB가 무엇인지요?' - 네이버 지식iN)

솔라리스 10 버전에서 IPMP는 아래처럼 기존에 IP주소가 3개를 사용했던 것과 달리 1개로 가능합니다.
실제 vmware상에서 테스트 해 본 결과 상당히 만족스런 결과를 얻었습니다. ^^
pcn interface는 공식적으로 ipmp를 지원하지 않는것으로 나와 있으나 잘 되네요..

썬에서 공식적으로 Link-Based Failure Detection 지원하는 network interface는 다음과 같습니다.
     -> hme, eri, ce, ge, bge, qfe, dmfe

Link-Based Failure Detection 지원하지 않는 네트윅 카드는 될 수 있으면 쓰지 않는게 좋겠죠?
 하지만 문제점은 링크가 끊기면 바로 failover 되버린다는것 단순히 네트윅 이중화만 되어 있다면
문제가 되지 않겠지만, Cluster가 깔린 서버라면 문제가 좀 커지겠죠? failover되는시간(DB,AP)만큼 서비스를
못하는 현상이 있을수 있습니다.
더 공부해봐야겠지만, DLPI IFF_RUNNING flag 부분을 더 삽질해서 공부하면 좋은 결과가 나올꺼라
생각됩니다 ^^
아마 기존 probe-based 방식처럼 failover 되는 시간을 수정하는 부분이 있을거라 생각됩니다. ^^
찾아보고 있으면 추가로 업뎃하겠습니다.

아래부터는 다음 카페에서 가져온 글 입니다. ^^
===========================================================================* 출처 : http://cafe.daum.net/osschool (조재구 강사님 카페, 야옹스님이 쓴 글)


기존 sol9이하버전까지는 IPMP 적용 시 failover가 실행되기 위해서는 최소 3개의 IP Address가 필요했지용...

Sol10부터는 link based Failure Detection 이라는 data link layer 점검층을 이용하여 1개의 IP Address만 사용하여도 fail over, fail back이 지원됩니다.

(기존은 방식은 probe based Failure Detection으로 application layer 점검층을 이용)

구 분  Link_based Failure Detection  Probe_based Failure Detection IPAddress수             1         3   지원 OS      Solaris 10 이상 Solaris 8 이상   점검 층       data link layer application layer   점검 방법    DLPI IFF_RUNNING flag              ICMP

아래내용은 Sunsolve에서 발췌한 내용입니다...

Most of the informations are already documented in the IP Services/IPMP part of the Solaris System Administration Guide (816-4554). This document is a short summary of failure detection types with additional/typical/recommended configuration examples using Link-based failure detection only. Even though link-based failure detection was supported before Solaris 10 (since DLPI link up/down notifications are supported by used network driver), it is now possible to use this failure detection type without any probing (probe-based failure detection).


Contents:

1. Types of Failure Detection

1.1. Link-based Failure Detection
1.2. Probe-based Failure Detection

2. Configuration Examples using Link-based Failure Detection only

2.1. Single Interface

2.2. Multiple Interfaces

2.2.1. Active-Active
2.2.1.1. Two Interfaces
2.2.1.2. Two Interfaces + logical
2.2.1.3. Three Interfaces

2.2.2. Active-Standby
2.2.2.1. Two Interfaces
2.2.2.2. Two Interfaces + logical

3. References

1. Types of Failure Detection
1.1. Link-based Failure Detection

Link-based failure detection is always enabled (supposed to be supported by the interface), whether optional probe-based failure detection is used or not. As per PSARC/1999/225 network drivers do send asynchronous DLPI notifications DL_NOTE_LINK_DOWN (link/NIC is down) and DL_NOTE_LINK_UP (link/NIC is up). The UP and DOWN notifications are used in IP to set and clear the IFF_RUNNING flag which is, in the absence of such notifications, always set for an interface that is up. Failure detection software will immediately detect changes to IFF_RUNNING. These DLPI notifications were implemented to network drivers by and by, and supported by almost all of them since Solaris 10.

With link-based failure detection, only the link between local interface and the link partner is been checked on hardware layer. Neither IP layer nor any further network path will be monitored!

No test addresses are required for link-based failure detection.

For more informations, please refer to Solaris 10 System Administration Guide:
IP Services >> IPMP >> 30. Introducing IPMP (Overview) >> Link-Based Failure Detection

1.2. Probe-based Failure Detection

Probe-based failure detection is performed on each interface in the IPMP group that has a test address. Using this test address, ICMP probe messages go out over this interface to one or more target systems on the same IP link. The in.mpathd daemon determines which target systems to probe dynamically:

all default routes on same IP link are used as probe targets.

all host routes on same IP link are used as probe targets. ( Configuring Target Systems)

always neither default nor host routes are available, in.mpathd sends out a all hosts multicast to 224.0.0.1 in IPv4 and ff02::1 in IPv6 to find neighbor hosts on the link.

Note: Available probe targets are determined dynamically, so the daemon in.mpathd has not to be re-started.

The in.mpathd daemon probes all the targets separately through all the interfaces in the IPMP group. The probing rate depends on the failure detection time (FDT) specified in /etc/default/mpathd (default 10 seconds) with 5 probes each timeframe. If 5 consecutive probes fail, the in.mpathd considers the interface to have failed. The minimum repair detection time is twice the failure detection time, 20 seconds by default, because replies to 10 consecutive probes must be received.

Without any configured host routes, the default route is used as a single probe target in most cases. In this case the whole network path up to the gateway (router) is monitored on IP layer. With all interfaces in the IPMP group connected via redundant network paths (switches etc.), you get full redundancy. On the other hand the default router can be a single point of failure, resulting in 'All Interfaces in group have failed'. Even with default gateway down, it could make sense to not fail the whole IPMP group, and to allow traffic within the local network. In this case specific probe targets (hosts or active network components) can be configured via host routes. So it is question of network design, which network path you do want to monitor.

A test address is required on each interface in the IPMP group, but the test addresses can be in a different IP test subnet than the data address(es). So private network addresses as specified by rfc1918 (e.g. 10/8, 172.16/12, or 192.168/16) can be used as well.

For more informations, please refer to Solaris 10 System Administration Guide:
IP Services >> IPMP >> 30. Introducing IPMP (Overview) >> Probe-Based Failure Detection

2. Configuration Examples using Link-based Failure Detection
An IPMP configuration typically consists of two or more physical interfaces on the same system that are attached to the same IP link. These physical interfaces might or might not be on the same NIC. The interfaces are configured as members of the same IPMP group.

A single interface can be configured in its own IPMP group. The single interface IPMP group has the same behavior! as an IPMP group with multiple interfaces. However, failover and failback cannot occur for an IPMP group with only one interface.

The following message does tell you, that this is link-based failure detection only configuration. It is reported for each interface in the group.

/var/adm/messages
in.mpathd[144]: [ID 975029 daemon.error] No test address configured on interface ce0; disabling probe-based failure detection on it

So in this configuration it is not an error, but more a confirm!ation, that the probe-based failure detection has been disabled correctly.

2.1. Single Interface

/etc/hostname.ce0
192.168.10.10 netmask + broadcast + group ipmp0 up

# ifconfig -a
ce0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 4
inet 192.168.10.10 netmask ffffff00 broadcast 192.168.10.255
groupname ipmp0
ether 0:3:ba:93:90:fc

2.2. Multiple Interfaces

2.2.1. Active-Active

2.2.1.1. Two Interfaces

/etc/hostname.ce0
192.168.10.10 netmask + broadcast + group ipmp0 up

/etc/hostname.ce1
group ipmp0 up

# ifconfig -a
ce0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 4
inet 192.168.10.10 netmask ffffff00 broadcast 192.168.10.255
groupname ipmp0
ether 0:3:ba:93:90:fc
ce1: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 5
inet 0.0.0.0 netmask ff000000 broadcast 0.255.255.255
groupname ipmp0
ether 0:3:ba:93:91:35

2.2.
1.2. Two Interfaces + logical

/etc/hostname.ce0
192.168.10.10 netmask + broadcast + group ipmp0 up \
addif 192.168.10.11 netmask + broadcast + up

/etc/hostname.ce1
group ipmp0 up

# ifconfig -a
ce0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 4
inet 192.168.10.10 netmask ffffff00 broadcast 192.168.10.255
groupname ipmp0
ether 0:3:ba:93:90:fc
ce0:1: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 4
inet 192.168.10.11 netmask ffffff00 broadcast 192.168.10.255
ce1: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 5
inet 0.0.0.0 netmask ff000000 broadcast 0.255.255.255
groupname ipmp0
ether 0:3:ba:93:91:35

2.2.1.3. Three Interfaces

/etc/hostname.ce0
192.168.10.10 netmask + broadcast + group ipmp0 up

/etc/hostname.ce1
group ipmp0 up

/etc/hostname.bge1
group ipmp0 up

# ifconfig -a
bge1: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 3
inet 0.0.0.0 netmask ff000000 broadcast 0.255.255.255
groupname ipmp0
ether 0:9:3d:11:91:1b
ce0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 4
inet 192.168.10.10 netmask ffffff00 broadcast 192.168.10.255
groupname ipmp0
ether 0:3:ba:93:90:fc
ce1: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 5
inet 0.0.0.0 netmask ff000000 broadcast 0.255.255.255
groupname ipmp0
ether 0:3:ba:93:91:35

2.2.2. Active-Standby

2.2.2.1. Two Interfaces

/etc/hostname.ce0
192.168.10.10 netmask + broadcast + group ipmp0 up

/etc/hostname.ce1
group ipmp0 standby up

# ifconfig -a
ce0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 4
inet 192.168.10.10 netmask ffffff00 broadcast 192.168.10.255
groupname ipmp0
ether 0:3:ba:93:90:fc
ce0:1: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 4
inet 0.0.0.0 netmask ff000000 broadcast 0.255.255.255
ce1: flags=69000842<BROADCAST,RUNNING,MULTICAST,IPv4,NOFAILOVER,STANDBY,INACTIVE> mtu 0 index 5
inet 0.0.0.0 netmask 0
groupname ipmp0
ether 0:3:ba:93:91:35

2.2.2.2. Two Interfaces + logical

/etc/hostname.ce0
192.168.10.10 netmask + broadcast + group ipmp0 up \
addif 192.168.10.11 netmask + broadcast + up

/etc/hostname.ce1
group ipmp0 standby up

# ifconfig -a
ce0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 4
inet 192.168.10.10 netmask ffffff00 broadcast 192.168.10.255
groupname ipmp0
ether 0:3:ba:93:90:fc
ce0:1: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 4
inet 192.168.10.11 netmask ffffff00 broadcast 192.168.10.255
ce0:2: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 4
inet 0.0.0.0 netmask ff000000 broadcast 0.255.255.255
ce1: flags=69000842<BROADCAST,RUNNING,MULTICAST,IPv4,NOFAILOVER,STANDBY,INACTIVE> mtu 0 index 5
inet 0.0.0.0 netmask 0
groupname ipmp0
ether 0:3:ba:93:91:35

*테스트 방법

# if_mpadm -d ce0

ce0 interface를 offline

ce1으로 fail over



# if_mpadm -r ce0

ce0 interface를 online

ce1에서 ce0로 fail back

개요: 100Mb 패스트이더넷 802.3 auto-negotiation를 처리하는 방법
상세설명:
htm와 qfe 100BaseT 인터페이스상에서 auto-negotiation 문제를 줄이기 위한
몇가지 처리 가이드라인과 정보는 무엇인가?

100Mb auto-negotiation 문제가 생길 때는 대개 제거 처리 문제이다.
여기에 모든 가능한 경우가 있다:

1. 좋지않은 케이블! ( 다른 환경과 nics와 케이블 길이는 다양한 결과를 야기시킬 수 있다)
2. 스위치가 802.3u auto-negotiation를 충족시키지 못해서, 속도와 듀플렉스를
일치시키고 강하게 한다.
3. Ultra Flash PROM 업데이트를 하지 않았다.
4. hme / qfe 드라이버 패치를 하지 않았다.
5. 스위치는 firmware/Version 업데이트를 요구한다.
6. 링크 파트너사이에서의 autoneg 양립 또는 패러랠 감지 문제/실패는
속도를 빠르게 하고 듀플렉스 모드를 요구한다.
7. 링크 파트너상의 100Mb 포트 하드웨어 문제 ( 스위치 - 허브 - 라우터 ).
8. Ultra 마더보드 또는 패스트이더넷 카드상의 100Mb 포트 하드웨어 문제

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

정보와 유의 :

케이블은 검증되고 시험된 분류 5 100Mb이여야 한다.
정상적으로 분류 5 케이블 시험기 / 한쌍(pair) 스캐너는 분류5
케이블링과 패치 패널로 설치된 100BaseT를 검사하기 위해 사용된다.

링크 속도, 모드 설정, auto-negotiation 설정을 검사하고 확인하기 위해서.
( 만약 qfe를 사용한다면 - "hme"장치가 언급된 곳을 "qfe"로 대체한다.)

# ndd -set /dev/hme instance 0
# ndd -get /dev/hme link_status
0 = link down 1 = link up
# ndd -get /dev/hme link_speed
0 = 10 Meg 1 = 100 Meg
# ndd -get /dev/hme link_mode
0 = half duplex 1 = full duplex

hme 드라이버가 autoneg와 적절한 수용능력을 알릴 준비가 되었는지 중복 검사한다.
( 모든 것이 1이여야 한다)
# ndd -set /dev/hme instance 0
# ndd /dev/hme adv_100fdx_cap
# ndd /dev/hme adv_100hdx_cap
# ndd /dev/hme adv_10fdx_cap
# ndd /dev/hme adv_10hdx_cap
# ndd /dev/hme adv_autoneg_cap

연결 파트너 능력이 어떻게 설정되느지 검사하기 위해서:

연결 파트너를 위한 파라미터들을 덤프한다

( 이 레지스터들은 연결의 다른쪽에서 받은 정보로부터 설정된다 [ 스위치, 트랜스시버..])

인스턴스 수를 설정한다 (인스턴스는 인터페이스 이름과 일치한다)
# ndd -set /dev/hme instance 0
이제 이들을 위한 파라미터 값들을 덤프하거나 획득한다:
# ndd -get /dev/hme lp_autoneg_cap
# ndd -get /dev/hme lp_100fdx_cap
# ndd -get /dev/hme lp_100hdx_cap
# ndd -get /dev/hme lp_10fdx_cap
# ndd -get /dev/hme lp_10hdx_cap

이들을 위한 값들은 파트너(당신이 플러그인한 스위치)가 알리는 것이다.
1 = enabled/capable 0 = not enabled/not capable

만약 lp_autoneg_cap 레지스터가 0이면 = 이것은 Link-partner/Hub가 802.3u auto-negotiation
adv_autoneg_cap이 사용못하거나 충족되지 않거나, 또는 감지되지 않는다는 표시이다.
firmware/patch 업그레이드를 위해 케이블링, 연결 파트너 HW, 또는 필수장비를 한곳에 모은다.

만약 연결 한쪽이 패러랠 감지에 실패하면 속도와 모드가 필요할 것이다.

# ndd -set /dev/hme instance # <--- set to the Interface in Question

( #=0 for hme0)
# ndd -set /dev/hme adv_100fdx_cap 1 <--- force ON 100Mb full duplex
# ndd -set /dev/hme adv_100hdx_cap 0 <--- force OFF 100Mb half duplex
# ndd -set /dev/hme adv_10fdx_cap 0 <--- force OFF 10Mb full duplex
# ndd -set /dev/hme adv_10hdx_cap 0 <--- force OFF 10Mb half duplex
# ndd -set /dev/hme adv_autoneg_cap 0 <--- force OFF autonegotiation
(FORCE mode)
or /etc/system:
set hme:hme_adv_autoneg_cap=0
set hme:hme_adv_100fdx_cap=1
set hme:hme_adv_100fdx_cap=1

qfe 드라이버: Quad 패스트이더넷:

같은 절차가 gfe 드라이버에 적용된다 ( substitute /dev/qfe for /dev/hme)

# ndd -set /dev/qfe adv_autoneg_cap 0

vge 드라이버: Vector Gigabit:

단지 풀-듀플렉스에서만 autonegotiation를 기본값으로 설정한다.
auto-negotiation은 꺼질 수 있다.

# ndd -set /dev/vge link_negotiation 0

ge 드라이버: GEM Gigabit:

기본값은:

adv_1000autoneg_cap : 1
adv_1000fdx_cap : 1
adv_1000hdx_cap : 1
adv_pauseTX : 0
adv_pauseRX : 1
# ndd -set /dev/ge adv_1000autoneg_cap 0
# ndd -get /dev/hme lp_autoneg_cap

만약 연결 파트너 (스위치)가 auto-negotiation를 지원하지 않는 경우에
100 Mbps에 대한 패러랠 감지를 성공한다면 그 드라이버에 의해 100 Mbps 반-듀플렉스가
선택되어야 한다. 더우기, 원하는 속도와 듀플렉스를 얻기 위해서는 속도와 듀플렉스 모두를
강하게 해야 한다(100MbFDX).

더 많은 정보는 Sunsolve 문서들과 유사한 Sun Adapter Installation와 사용자 가이드에 언급된다.

infodoc 16070 하나 이상의 hme 인터페이스를 위해 hme 파라미터를 설정하는 방법
infodoc 16728 어떻게 100baseT 이더넷 auto-negotiation이 작동하는가? 그리고 hme와 qfe 드라이브
기본값은 무엇인가?
infodoc 16144 HME 카드는 100mb에서 어떻게 작동하게 하는가(full-duplex).
srdb 16143 HME 카드는 10mb에서 어떻게 작동하게 하는가(full-duplex).
srdb 13206 네트웍 속도를 100 Mbps로 하기
srdb 12605 풀 듀플렉스는 선 이더넷 드라이버들을 지원한다.
infodoc 16017 hme 인터페이스는 10BaseT 또는 100BaseT에서 실행되고 있는가?

APPLIES TO: Operating Systems/Solaris/Solaris 2.x

netstat -an 결과에 대한 설명 (ns>root)/user/root# netstat -an UDP    Local Address         Remote Address     State -------------------- -------------------- -------       *.111                                 Idle       *.*                                   Unbound       *.32771                               Idle       *.4045                                Idle       *.32772                               Idle 127.0.0.1.53                                Idle 211.217.77.202.53                           Idle       *.32773                               Idle       *.514                                 Idle       *.177                                 Idle       *.32778                               Idle       *.2049                                Idle       *.*                                   Unbound TCP    Local Address        Remote Address    Swind Send-Q Rwind Recv-Q  State -------------------- -------------------- ----- ------ ----- ------ -------       *.*                  *.*                0      0     0      0 IDLE       *.111                *.*                0      0     0      0 LISTEN       *.*                  *.*                0      0     0      0 IDLE       *.32771              *.*                0      0     0      0 LISTEN       *.21                 *.*                0      0     0      0 LISTEN       *.23                 *.*                0      0     0      0 LISTEN       *.110                *.*                0      0     0      0 LISTEN       *.512                *.*                0      0     0      0 LISTEN       *.4045               *.*                0      0     0      0 LISTEN 127.0.0.1.53               *.*                0      0     0      0 LISTEN 211.217.77.202.53          *.*                0      0     0      0 LISTEN       *.25                 *.*                0      0     0      0 LISTEN       *.587                *.*                0      0     0      0 LISTEN       *.32772              *.*                0      0     0      0 LISTEN       *.80                 *.*                0      0     0      0 LISTEN       *.32773              *.*                0      0     0      0 LISTEN       *.2049               *.*                0      0     0      0 LISTEN       *.3306               *.*                0      0     0      0 LISTEN 211.217.77.202.23    211.217.77.206.16701 65489      0  8760      0 ESTABLISHED 211.217.77.202.23    211.217.77.206.19073 17276      0  8760      0 ESTABLISHED 211.217.77.202.23    211.217.77.206.19629 16089      1  8760      0 ESTABLISHED 211.217.77.202.110   210.217.178.202.1407 65356      0  8760      0 TIME_WAIT       *.*                  *.*                0      0     0      0 IDLE Active UNIX domain sockets Address  Type          Vnode     Conn  Local Addr      Remote Addr 7071dea8 stream-ord 70560b68 00000000 /tmp/mysql.sock   ------------------------------------------------------------------------------- 상태 Idle - 포트가 열려 있으나 사용 하지않고 있음 LISTEN - 들어오는 접속을 대기 하고 있음 ESTABLISHED - 정상적으로 접속이 연결된 상태 TIME_WAIT - 접속 후 다른 명령이나 신호를 기다리는 상태 SYN_SENT -  접속을 ESTABLISHED 상태로 되려고 시도 하는 상태 CLOSE_WAIT -  서버에서 연결을 종료 하기 위해 클라이언트에게 종결을 요청하고               회신을 받아 종료하는 과정의 상태 Unbound - 접속을 기다리지 않음 CLOSED - 완전히 종료 CLOSING - 흔하지 않지만 주로 확인 메세지가 전송도중 분실된 상태 SYN_RECEIVED - 서버가 원격 클라이언트로부터 접속 요구를 받아 클라이언트에게 응답                하였으나 아직 클라이언트에게 확인 메세지를 받지 않은 상태 이름 TCP (Transmission Control Protocol) 패킷 관리 프로토콜. 패킷 전달 후 연결 여부까지 확인 UDP (User Datagram Protocol) TCP 보다 연결이 적은 사용자 프로토콜. 패킷전달 여부만 확인

111번 포트에서 어떤 서비스가 돌고 있는지 알기 위하여 아래와 같은 명령을 내렸더니 다음과 같은 결과가 나왔습니다.

# lsof -i tcp:111   엔터

COMMAND PID USER   FD   TYPE        DEVICE      SIZE/OFF     NODE NAME
rpcbind          165   root      6u     IPv4     0x30002ab22c0      0t0         TCP *:sunrpc (LISTEN)

질문)

sunrpc라는 놈이 111번 포트를 사용하고 있는것 같은데 맨 앞쪽에 있는 rpcbind의 뜻이 무엇인지 모르겠네요....^^

sunrpc를 죽일려면 어떻게 해야 하나요(kill로 말고, 영구적으로요)

실력있는 분들의 답변을 기다립니다.

[답변] 안녕하세요. 백승찬입니다.

# cat /etc/rpc | head
#
#ident  "@(#)rpc        1.17    01/10/30 SMI"   /* Svr4.0 1.2   */
#
# Copyright (c) 2001 by Sun Microsystems, Inc.
# All rights reserved.
#
#       rpc
#
rpcbind         100000  portmap sunrpc rpcbind
rstatd          100001  rstat rup perfmeter

위와 같이 나왔다고 해 봅시다.
rpcbind 라는 것이 rpc서비스를 하는 데몬역할을 하는 서비스구요. 100000이 프로그램 이름이구요. rpcbind는 alias 이름으로 portmap 또는 sunrpc 또는 rpcbind라고 한다고 하는 군요.

그러니까 같은 역할을 하는 놈들을 여러가지로 부르는 것입니다. 같다는 뜻이죠.

* Solaris 에서 변경해야 될 파일들

   /etc/nodename              # if you need to change the name of the machine
   /etc/hostname.interface    # eg. hostname.hme0
   /etc/hosts                 # Update to reflect new name
   /etc/nsswitch.conf         # Update if your name resolution
   /etc/resolv.conf    

   # Update if your name servers/domain changed (DNS only)
   /etc/defaultdomain             # set you default domain
   /etc/defaultrouter             # Set the default router's IP
   /etc/inet/networks             # Set your network name
   /etc/inet/netmasks             # Set your network number
   /etc/n/etc/net/ticots/hosts    # For the streams-level loopback
   /etc/ticlts/hosts              # For the streams-level loopback
   /etc/net/ticotsord/hosts       # For the streams-level loopback

* Solaris 에서 IP 변경 작업

   /etc/hosts 파일을 수정함.
   /etc/hostname.hme0 랜카드에 적용되는 호스명을 명시

   $ ifconfig hme0 [ip] netmask 0xffffff00 broadcast + up

   ex)
   --- 영구적인 변경
   $vi /etc/hostname.hme0
   credilist

   $ vi /etc/hosts
   127.0.0.1       localhost
   211.192.191.178 credilist       loghost

   --- 임시변경시 (컴퓨터가 켜져있는 동안, 리부팅되면 정보가 사라짐)
   $ ifconfig -a
   lo0: flags=1000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 8232 index 1
        inet 127.0.0.1 netmask ff000000
   hme0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
         inet 211.192.191.178 netmask ffffff00 broadcast 211.192.191.255

   $ ifconfig hme0 211.192.191.171 netmask 0xffffff00 broadcast + up

* Solaris 에서 GATEWAY 변경 작업

   $ netstat -rn
   $ route add default [gateway ip]
   $ vi /etc/defaultrouter
   [gateway ip]

   ex)
   --- 영구적인 변경
   $ vi /etc/defaultrouter
   211.192.191.177

   --- 임시적인 변경
   route add default 211.192.191.177

* Solaris 에서 DNS 변경 작업

   ex)
   $ vi /etc/resolv.conf
   nameserver 168.126.63.1
   nameserver 168.126.63.2
   nameserver 211.169.248.153

   $ vi nsswitch.conf
   # hosts: 부분을 수정한다.
   # consult /etc "files" only if nis is down.
   hosts:      files dns

출처 : Tong - J.래빗님의 유닉스,리눅스,솔라리스통

IPMP 이해 및 설정

Objectives

IPMP 기능 이해

IPMP 관련 화일및 명령어 이해

IPMP 설정 및 테스트

 

Description

솔라리스 8부터 새로이 추가된 기능중 하나인 IPMP(IP MultiPathing)는 솔라리스의 core package인 SUNWcsr에 포함되어 있다. IPMP는 하나의 시스템이 여러개의 NIC(Network Interface Card)를  사용할때 네트웍 카드들을 그룹핑을 하여서 그중 하나의 네트웍 카드가 failure 되었을때 이를 검사하여 정상적인 네트웍 카드로 failover해주는 기능이다. 그러므로써 네트웍 서비스를 제공하는데  있어서 네트웍 카드의 장애로 생기는 네트웍 장애 문제를 극복할 수 있는 안정적인 환경을 구성해 줄 수 있다. 또한 failback 기능을 가지고 있는데 이는 장애가 발생한 네트웍 카드를 복구한 후 관리자가 메뉴얼하게 네트웍 카드의 설정을 하지 않아도 자동으로 이전 설정으로 돌려주는 기능이다.

IPMP 설정 방법으로는 크게 두가지가 있다. Standby NIC를 가지는 환경과 그렇지 않은 환경이다. Standby NIC란 네트웍 서비스를 일반적으로 하지 않는 NIC를 하나 설정하여 실제 서비스중인 NIC의 failover에 집중적으로 책임을 지는 인터페이스이다. 이것이 Standby NIC를 가지고 IPMP를 설정하는 것이다.

Standby NIC를 가지지 않는 환경이란 그룹에 있는 NIC들이 네트웍 서비스를 각각 하고 있다가  그룹내 NIC 하나가 failure가 발생하면 남아있던 정상의 NIC로 failover하는 것이다. IPMP를 설정하는데 있어서 Standby를 갖는냐 갖지 않는냐의 가장 큰 차이는 failover를 할 수 있는 대상 NIC 차이이다.

Standby NIC는 Standby가 아닌 다른 NIC의 failover를 제공하지만 반대는 할 수 없다. 즉, Standby가  아닌 NIC는 Standby NIC의 failure에 대해 failover를 하지 않는다.

Standby NIC가 없이 NIC들을 모두 active path로 잡아주는 환경은 그룹에 있는 NIC들이 어떤것이든 서로를 failover하며 서비스 해 줄 수 있다.

아래의 Lab에서는 Standby NIC를 두는 IPMP 환경 설정과 그렇지 않는 설정에 대해 설명할것이다.

 

IPMP 구현 관련 명령어와 파일

 

1. in.mpathd : IPMP의 main control daemon이다. NIC를 그룹핑하는 Ifconfig 명령어를 실행하면  실행하는 프로세스로써 그룹내에 있는 네트웍 카드가 failure가 발생했는지 검사하여 정상적인 네트웍 카드를 failover를 시켜주고 failback을 시켜주는 프로세스이다. 이때 in.mpathd가  failover, failback을 하기위해 (NIC를 테스트하기 위해) 사용하는 logical interface가 필요한데 이것이  test interface이다. test interface는 failover하지 않는다. 단지 테스트를 위한 virtual interface이다.

참고로 Standby interface는 test interface 형태로만 설정한다. 하지만 그룹내 NIC들이 모두  active한 환경이라면 (즉 Standby NIC를 가지지 않는 설정) NIC들은 public한 ip address와 test를 위한 ip address 모두를 갖도록 설정해야한다.

 

2. /etc/default/mpathd : in.mpathd의 configuration file이다. 예를 들어 in.mpathd가 그룹내 NIC들의 failover를 체크할 시간 간격을 정의하는 파라메터등을 설정하는 화일이다.

 

3. ifconfig : 너무나 잘 알고 있듯이 네트웍 카드 설정을 해주는 명령어이다. 예를 들어 ip address나 netmask등을 설정해주는 명령어이다. 그러한 기본 기능뿐만이 아니라 IPMP를 설정시에도 그룹을 지정하거나 테스트 NIC를 설정하는데 사용된다. IPMP 설정에 관련있는 ifconfig 명령어들의 옵션이나 아규먼트 몇 가지를 살펴보자.

group : IPMP failover를 할 그룹을 설정한다.

deprecated -failover : test interface 에 설정하는 옵션

addif : test interface 이면서 active path 를 가지고 있으면서 test interface를 add 하기 위해

사용하는 아규먼트

standby : active path를 갖지 않는 standby test interface 를 설정하는 아규먼트

 

Implementation

아래의 구현 내용은 IPMP를 설정하는 방법으로 첫째로 standby를 사용하지 않고 두 NIC가 모두  active하게 서비스를 할 수 있는 상태로 만든후 failover, failback을 하는 내용이다. 두번째 구현의  내용은 standby를 사용하는 테스트의 예이다.

 

1.      Standby 없이 dual active path 의 IPMP설정 및 확인

설정

host1#eeprom local-mac-address? local-mac-address?=false host1# eeprom local-mac-address?=true --> 각 interface의 ethernet address를 달리 설정하기 위한 eeprom parameter를 true로 설정 host1# eeprom local-mac-address? local-mac-address?=true   host1# ifconfig ge0 unplumb host1# ifconfig ge1 unplumb host1# ifconfig ge0 plumb 192.168.0.86 group testgrp2 up   host1# ps -ef|grep mpath root 477 1 0 17:18:09 ? 0:00 /sbin/in.mpathd   host1# ifconfig ge0 addif 192.168.0.87 deprecated -failover up ---> test interface 설정 . Created new logical interface ge0:1   host1# ifconfig -a lo0: flags=1000849 <UP,LOOPBACK,RUNNING,MULTICAST,IPv4>mtu 8232 index 1 inet 127.0.0.1 netmask ff000000 ge0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 6 inet 192.168.0.86 netmask ffffff00 broadcast 192.168.0.255 groupname testgrp2 ether 8:0:20:c0:ff:ec ge0:1: flags=9040843<UP,BROADCAST,RUNNING,MULTICAST,DEPRECATED,IPv4,NOFAILOVER> mtu 1500 index 6 inet 192.168.0.87 netmask ffffff00 broadcast 192.169.0.255   host1# ifconfig ge1 plumb 192.168.0.88 group testgrp2 up host2# ifconfig ge1 addif 192.168.0.89 deprecated -failover up  --> test interface설정 . Created new logical interface ge1:1   host1# ifconfig -a lo0: flags=1000849 <UP,LOOPBACK,RUNNING,MULTICAST,IPv4>mtu 8232 index 1 inet 127.0.0.1 netmask ff000000 ge0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 6 inet 192.168.0.86 netmask ffffff00 broadcast 192.168.0.255 groupname testgrp2 ether 8:0:20:c0:ff:ec ge0:1: flags=9040843<UP,BROADCAST,RUNNING,MULTICAST,DEPRECATED,IPv4,NOFAILOVER> mtu 1500 index 6 inet 192.168.0.87 netmask ffffff00 broadcast 192.168.0.255 ge1: flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4>mtu 1500 index 7 inet 192.168.0.88 netmask ffffff00 broadcast 192.168.0.255 groupname testgrp2 ether 8:0:20:c0:ff:ec ge1:1: flags=9040843<UP,BROADCAST,RUNNING,MULTICAST,DEPRECATED,IPv4,NOFAILOVER> mtu 1500 index 7 inet 192.168.0.89 netmask ffffff00 broadcast 192.168.0.255

 

Failover 테스트

다른 호스트 host2 로부터 192.168.0.88 번으로 ping을 날리고 host1은 그러는 중간에 ge1에 장애를 일으켰다. lab에서는 네트웍 포트를 뽑아버렸다

host2# ping -s 192.168.0.88 PING 192.168.0.88: 56 data bytes 64 bytes from host1 (192.168.0.88): icmp_seq=0. time=0. ms 64 bytes from host1 (192.168.0.88): icmp_seq=1. time=0. ms 64 bytes from host1(192.168.0.88): icmp_seq=2. time=0. ms 64 bytes from host1(192.168.0.88): icmp_seq=3. time=0. ms 64 bytes from host1 (192.168.0.88): icmp_seq=4. time=0. ms 64 bytes from host1 (192.168.0.88): icmp_seq=5. time=0. ms 64 bytes from host1 (192.168.0.88): icmp_seq=6. time=0. ms . . 64 bytes from host1 (192.168.0.88): icmp_seq=14. time=0. ms 64 bytes from host1 (192.168.0.88): icmp_seq=15. time=0. ms 64 bytes from host1 (192.168.0.88): icmp_seq=16. time=0. ms

위의 결과에서 보듯이 중간에 잠시 멈추는 부분이 보이는데 이때 host1의 ge1이 장애를 일으켰다. 하지만 잠시 시간이 흐른 후 계속 ping 이 잘 진행되는 것을 확인할 수 있다.

host1에서 IPMP설정에 의해 failover가 되는 것이다. 이러한 테스트는 ge0에 장애를 일으켜도 마찬가지로 ge1으로 failover 된다.

그럼 host1쪽의 failover된 환경을 확인해 보자.

 

host1# ifconfig -a lo0: flags=1000849 <UP,LOOPBACK,RUNNING,MULTICAST,IPv4>mtu 8232 index 1 inet 127.0.0.1 netmask ff000000 ge0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 6 inet 192.168.0.86 netmask ffffff00 broadcast 192.168.0.255 groupname testgrp2 ether 8:0:20:c0:ff:ec ge0:1: flags=9040843<UP,BROADCAST,RUNNING,MULTICAST,DEPRECATED,IPv4,NOFAILOVER> mtu 1500 index 6 inet 192.168.0.87 netmask ffffff00 broadcast 192.168.0.255 ge0:2: flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 6 inet 192.168.0.88 netmask ffffff00 broadcast 192.168.0.255 ge1: flags=19000842 <BROADCAST,RUNNING,MULTICAST,IPv4,NOFAILOVER,FAILED>mtu 0 index 7 inet 0.0.0.0 netmask 0 groupname testgrp2 ether 8:0:20:c0:ff:ec ge1:1: flags=9040843<UP,BROADCAST,RUNNING,MULTICAST,DEPRECATED,IPv4,NOFAILOVER> mtu 1500 index 7 inet 192.168.0.89 netmask ffffff00 broadcast 192.168.0.255

 

Failback 테스트

ge1을 복구한 후 얼마 지나지 않아 자동으로 failback 하는 것을 확인할 수 있다. 아래의 내용은 failback을 한 후의 host1의 네트웍 카드 설정을 보면 이전 상태로 돌아가 있는 것을 확인할 수 있다.

host1# ifconfig -a lo0: flags=1000849 <UP,LOOPBACK,RUNNING,MULTICAST,IPv4>mtu 8232 index 1 inet 127.0.0.1 netmask ff000000 ge0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 6 inet 192.168.0.86 netmask ffffff00 broadcast 192.168.0.255 groupname testgrp2 ether 8:0:20:c0:ff:ec ge0:1: flags=9040843<UP,BROADCAST,RUNNING,MULTICAST,DEPRECATED,IPv4,NOFAILOVER> mtu 1500 index 6 inet 192.168.0.87 netmask ffffff00 broadcast 192.168.0.255 ge1: flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4>mtu 1500 index 7 inet 192.168.0.88 netmask ffffff00 broadcast 192.168.0.255 groupname testgrp2 ether 8:0:20:c0:ff:ec ge1:1: flags=9040843<UP,BROADCAST,RUNNING,MULTICAST,DEPRECATED,IPv4,NOFAILOVER> mtu 1500 index 7 inet 192.168.0.89 netmask ffffff00 broadcast 192.168.0.255

 

/etc/hostnanme.<interface> 설정 내용

# cat /etc/hostname.hme0 192.168.10.215 broadcast + netmask + up group test  \ addif 192.168.10.216 –failover  deprecated netmask + broadcast + up # cat /etc/hostname.hme1 192.168.10.217 broadcast + netmask + up group test  \ addif 192.168.10.218 –failover  deprecated netmask + broadcast + up

 

2.      Standby 를 가진 single active path의 IPMP 설정하기

 

설정

host1#eeprom local-mac-address? local-mac-address?=false host1# eeprom local-mac-address?=true --> 각 interface의 ethernet address를 달리 설정하기 위한 eeprom parameter를 true로 설정 host1# eeprom local-mac-address? local-mac-address?=true   host1# ifconfig ge0 unplumb host1# ifconfig ge1 unplumb host1# ifconfig ge0 plumb 192.168.0.86 group testgrp2 up   host1# ps -ef|grep mpath root 477 1 0 17:18:09 ? 0:00 /sbin/in.mpathd   host1# ifconfig ge0 addif 192.168.0.87 deprecated -failover up ---> test interface 설정 . Created new logical interface ge0:1   host1# ifconfig -a lo0: flags=1000849 <UP,LOOPBACK,RUNNING,MULTICAST,IPv4>mtu 8232 index 1 inet 127.0.0.1 netmask ff000000 ge0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 6 inet 192.168.0.86 netmask ffffff00 broadcast 192.168.0.255 groupname testgrp2 ether 8:0:20:c0:ff:ec ge0:1: flags=9040843<UP,BROADCAST,RUNNING,MULTICAST,DEPRECATED,IPv4,NOFAILOVER> mtu 1500 index 6 inet 192.168.0.87 netmask ffffff00 broadcast 192.169.0.255   host1# ifconfig ge1 plumb 203.234.247.88 group testgrp1 deprecated -failover standby up host1# ifconfig -a lo0: flags=1000849 <UP,LOOPBACK,RUNNING,MULTICAST,IPv4>mtu 8232 index 1 inet 127.0.0.1 netmask ff000000 ge0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 6 inet 192.168.0.86 netmask ffffff00 broadcast 192.168.0.255 groupname testgrp2 ether 8:0:20:c0:ff:ec ge0:1: flags=9040843<UP,BROADCAST,RUNNING,MULTICAST,DEPRECATED,IPv4,NOFAILOVER> mtu 1500 index 6 inet 192.168.0.87 netmask ffffff00 broadcast 192.169.0.255 ge1: flags=69040843 <UP,BROADCAST,RUNNING,MULTICAST,DEPRECATED,IPv4,NOFAILOVER,STANDBY,INACTIVE> mtu 1500 index 5 inet 192.168.0.88 netmask ffffff00 broadcast 192.168.0.255 groupname testgrp1 ether 8:0:20:c0:ff:ec

 

Failover 테스트

다른 호스트 host2 로부터 192.168.0.86 번으로 ping을 날리고 host1은 그러는 중간에 ge1에 장애를 일으켰다.  lab에서는 네트웍 포트를 뽑아버렸다.

host2# ping -s 192.168.0.86 PING 192.168.0.86: 56 data bytes 64 bytes from host1 (192.168.0.86): icmp_seq=0. time=0. ms 64 bytes from host1 (192.168.0.86): icmp_seq=1. time=0. ms 64 bytes from host1(192.168.0.86): icmp_seq=2. time=0. ms 64 bytes from host1(192.168.0.86): icmp_seq=3. time=0. ms 64 bytes from host1 (192.168.0.86): icmp_seq=4. time=0. ms 64 bytes from host1 (192.168.0.86): icmp_seq=5. time=0. ms 64 bytes from host1 (192.168.0.86): icmp_seq=11. time=0. ms 64 bytes from host1 (192.168.0.86): icmp_seq=12. time=0. ms 64 bytes from host1 (192.168.0.86): icmp_seq=13. time=0. ms

위의 결과에서 보듯이 중간에 잠시 멈추는 부분이 보이는데 이때 host1의 ge1이 장애를 일으켰다. 하지만 잠시 시간이 흐른 후 계속 ping 이 잘 진행되는 것을 확인할 수 있다.

host1에서 IPMP설정에 의해 failover가 되는 것이다. 하지만 이때 ge0이 아닌 standby 인 ge1에 장애가 발생하면 ge0으로는 failover되지 않는다.

 

/etc/hostnanme.<interface> 설정 내용

# cat /etc/hostname.ge0 192.168.0.86 netmask 255.255.255.0 broadcast + group host1 up \ addif 192.168.0.87 deprecated -failover netmask 255.255.255.0 broadcast + up   #cat /etc/hostname.ge1 192.168.0.88 netmask 255.255.255.0 broadcast + group host1 deprecated -failover standby up