탐색 링크 건너뛰기 | |
인쇄 보기 종료 | |
![]() |
Oracle Solaris 관리: IP 서비스 Oracle Solaris 10 1/13 Information Library (한국어) |
1. Oracle Solaris TCP/IP 프로토콜 제품군(개요)
5. TCP/IP 네트워크 서비스 구성 및 IPv4 주소 지정(작업)
10. TCP/IP 및 IPv4에 대한 자세한 정보(참조)
in.mpathd 데몬은 다음 유형의 실패 감지를 처리합니다.
링크 기반 실패 감지. NIC 드라이버에서 지원되는 경우에 사용합니다.
프로브 기반 실패 감지(테스트 주소가 구성된 경우)
부트 시 누락된 인터페이스 감지
in.mpathd 데몬이 인터페이스 실패 감지를 처리하는 방법에 대한 자세한 내용은 in.mpathd(1M) 매뉴얼 페이지에서 자세히 설명합니다.
인터페이스에서 이러한 유형의 실패 감지를 지원하는 경우 링크 기반 실패 감지는 항상 사용으로 설정됩니다. 현재 Oracle Solaris 릴리스에서는 다음 Sun 네트워크 드라이버를 지원합니다.
hme
eri
ce
ge
bge
qfe
dmfe
e1000g
igb
ixgb
nge
nxge
rge
xge
타사 인터페이스가 링크 기반 실패 감지를 지원하는지 확인하려면 해당 제조업체의 설명서를 참조하십시오.
이러한 네트워크 인터페이스 드라이버는 인터페이스의 링크 상태를 모니터링하여 링크 상태가 변경될 경우 네트워킹 부속 시스템에 이를 알립니다. 변경 알림을 받으면 네트워킹 부속 시스템이 해당 인터페이스에 대해 RUNNING 플래그를 적절하게 설정하거나 지웁니다. 데몬이 인터페이스의 RUNNING 플래그가 지워진 것을 감지하면 데몬이 즉시 인터페이스 실패를 발생시킵니다.
in.mpathd 데몬은 테스트 주소가 있는 IPMP 그룹의 각 인터페이스에 대해 프로브 기반 실패 감지를 수행합니다. 프로브 기반 실패 감지는 테스트 주소를 사용하는 ICMP 프로브 메시지를 송수신합니다. 이러한 메시지는 인터페이스를 통해 동일한 IP 링크에 있는 하나 이상의 대상 시스템으로 전달됩니다. 테스트 주소에 대한 소개는 테스트 주소를 참조하십시오. 테스트 주소 구성 방법에 대한 자세한 내용은 다중 인터페이스가 포함된 IPMP 그룹을 구성하는 방법을 참조하십시오.
in.mpathd 데몬은 동적으로 프로빙할 대상 시스템을 결정합니다. IP 링크에 연결된 라우터는 프로브 대상으로 자동 선택됩니다. 링크에 라우터가 없으면 in.mpathd가 링크의 인접 호스트로 프로브를 전송합니다. 모든 호스트 멀티캐스트 주소인 224.0.0.1(IPv4) 및 ff02::1(IPv6)로 멀티캐스트 패킷이 전송되어 대상 시스템으로 사용할 호스트를 결정합니다. 에코 패킷에 응답하는 처음 몇 개 호스트가 프로브 대상으로 선택됩니다. in.mpathd가 ICMP 에코 패킷에 응답하는 라우터나 호스트를 찾을 수 없는 경우 in.mpathd는 프로브 기반 실패를 감지할 수 없습니다.
호스트 경로를 사용하여 in.mpathd에서 사용할 대상 시스템 목록을 명시적으로 구성할 수 있습니다. 자세한 내용은 대상 시스템 구성을 참조하십시오.
IPMP 그룹의 각 인터페이스가 제대로 작동하는지 확인하기 위해 in.mpathd는 IPMP 그룹의 모든 인터페이스를 통해 모든 대상을 별도로 프로빙합니다. 5회 연속 프로브에 대해 응답이 없을 경우 in.mpathd는 해당 인터페이스가 실패했다고 간주합니다. 프로브 속도는 FDT(실패 감지 시간)에 따라 달라집니다. 실패 감지 시간의 기본값은 10초입니다. 그러나 /etc/default/mpathd 파일에서 실패 감지 시간을 조정할 수 있습니다. 자세한 내용은 /etc/default/mpathd 파일을 구성하는 방법을 참조하십시오.
복구 감지 시간이 10초인 경우 프로브 속도는 약 2초마다 프로브 1회입니다. 10회 연속 프로브에 대한 응답이 수신되어야 하므로 최소 복구 감지 시간은 실패 감지 시간의 2배(기본값: 20초)입니다. 실패 및 복구 감지 시간은 프로브 기반 실패 감지에만 적용됩니다.
주 - VLAN으로 구성된 IPMP 그룹에서 링크 기반 실패 감지는 물리적 링크 단위로 구현되므로 해당 링크의 모든 VLAN에 영향을 줍니다. 프로브 기반 실패 감지는 VLAN 링크 단위로 수행됩니다. 예를 들어, bge0/bge1 및 bge1000/bge1001은 한 그룹으로 구성됩니다. bge0의 케이블 연결이 끊어지면 링크 기반 실패 감지에서 bge0 및 bge1000이 모두 즉시 실패한 것으로 보고합니다. 그러나 bge0의 모든 프로브 대상을 연결할 수 없게 된 경우 bge1000은 해당 VLAN에 자체 프로브 대상이 있으므로 bge0만 실패한 것으로 보고됩니다.
그룹 실패는 IPMP 그룹의 모든 인터페이스가 동시에 실패한 것으로 나타날 때 발생합니다. in.mpathd 데몬은 그룹 실패에 대해 페일오버를 수행하지 않습니다. 또한 모든 대상 시스템이 동시에 실패할 경우 어떠한 페일오버도 발생하지 않습니다. 이 경우 in.mpathd는 현재 대상 시스템을 모두 비우고 새 대상 시스템을 찾습니다.
in.mpathd 데몬에서 인터페이스 복구를 감지하려면 해당 인터페이스에 RUNNING 플래그가 설정되어 있어야 합니다. 프로브 기반 실패 감지가 사용된 경우 in.mpathd 데몬에서 인터페이스로부터 10회 연속 프로브 패킷에 대한 응답을 받아야 해당 인터페이스가 복구된 것으로 간주합니다. 인터페이스가 복구된 것으로 간주되면 다른 인터페이스로 페일오버되었던 모든 주소가 복구된 인터페이스로 페일백됩니다. 인터페이스가 실패하기 전 “활성”으로 구성된 경우에는 복구 후 트래픽 전송 및 수신을 계속할 수 있습니다.
다음 두 예에서는 일반 구성 및 인터페이스가 실패할 경우 해당 구성이 자동으로 변경되는 방법을 보여 줍니다. hme0 인터페이스가 실패하면 모든 데이터 주소가 hme0에서 hme1로 이동합니다.
예 27-1 인터페이스 실패 전 인터페이스 구성
hme0: flags=9000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2 inet 192.168.85.19 netmask ffffff00 broadcast 192.168.85.255 groupname test hme0:1: flags=9000843<UP,BROADCAST,RUNNING,MULTICAST,DEPRECATED,IPv4,NOFAILOVER> mtu 1500 index 2 inet 192.168.85.21 netmask ffffff00 broadcast 192.168.85.255 hme1: flags=9000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2 8 inet 192.168.85.20 netmask ffffff00 broadcast 192.168.85.255 groupname test hme1:1: flags=9000843<UP,BROADCAST,RUNNING,MULTICAST,DEPRECATED,IPv4,NOFAILOVER> mtu 1500 index 2 inet 192.168.85.22 netmask ffffff00 broadcast 192.168.85.255 hme0: flags=a000841<UP,RUNNING,MULTICAST,IPv6,NOFAILOVER> mtu 1500 index 2 inet6 fe80::a00:20ff:feb9:19fa/10 groupname test hme1: flags=a000841<UP,RUNNING,MULTICAST,IPv6,NOFAILOVER> mtu 1500 index 2 inet6 fe80::a00:20ff:feb9:1bfc/10 groupname test
예 27-2 인터페이스 실패 후 인터페이스 구성
hme0: flags=19000842<BROADCAST,RUNNING,MULTICAST,IPv4, NOFAILOVER,FAILED> mtu 0 index 2 inet 0.0.0.0 netmask 0 groupname test hme0:1: flags=19040843<UP,BROADCAST,RUNNING,MULTICAST,DEPRECATED,IPv4, NOFAILOVER,FAILED> mtu 1500 index 2 inet 192.168.85.21 netmask ffffff00 broadcast 10.0.0.255 hme1: flags=9000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2 inet 192.168.85.20 netmask ffffff00 broadcast 192.168.85.255 groupname test hme1:1: flags=9000843<UP,BROADCAST,RUNNING,MULTICAST,DEPRECATED,IPv4, NOFAILOVER> mtu 1500 index 2 inet 192.168.85.22 netmask ffffff00 broadcast 10.0.0.255 hme1:2: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 6 inet 192.168.85.19 netmask ffffff00 broadcast 192.168.18.255 hme0: flags=a000841<UP,RUNNING,MULTICAST,IPv6,NOFAILOVER,FAILED> mtu 1500 index 2 inet6 fe80::a00:20ff:feb9:19fa/10 groupname test hme1: flags=a000841<UP,RUNNING,MULTICAST,IPv6,NOFAILOVER> mtu 1500 index 2 inet6 fe80::a00:20ff:feb9:1bfc/10 groupname test
hme0에 FAILED 플래그가 설정되어 인터페이스가 실패했음을 알 수 있습니다. 또한 hme1:2가 만들어진 것을 알 수 있습니다. hme1:2는 원래 hme0이었습니다. 그런 다음 주소 192.168.85.19는 hme1을 통해 액세스할 수 있게 됩니다.
192.168.85.19와 연결된 멀티캐스트 구성원은 여전히 패킷을 수신할 수는 있지만 이제 hme1을 통해 패킷을 수신합니다. 주소 192.168.85.19가 hme0에서 hme1로 페일오버되면 hme0에 가상 주소 0.0.0.0이 만들어집니다. 가상 주소는 hme0을 계속 액세스하기 위해 만들어진 것입니다. hme0:1은 hme0 없이 존재할 수 없습니다. 후속 페일백이 수행되면 가상 주소가 제거됩니다.
마찬가지로 IPv6 주소가 hme0에서 hme1로 페일오버됩니다. IPv6에서 멀티캐스트 구성원은 인터페이스 색인과 연결되어 있습니다. 멀티캐스트 구성원도 hme0에서 hme1로 페일오버됩니다. in.ndpd가 구성한 모든 주소도 함께 이동됩니다. 이 작업은 예에 표시되어 있지 않습니다.
in.mpathd 데몬은 계속해서 실패한 인터페이스 hme0을 통해 프로브를 수행합니다. 데몬이 기본 복구 감지 시간인 20초 동안 10회 연속 응답을 받게 되면 해당 인터페이스가 복구된 것으로 판단합니다. hme0에는 RUNNING 플래그도 설정되어 있기 때문에 데몬은 페일백을 호출합니다. 페일백 후 원래 구성이 복원됩니다.
실패 및 복구 중 콘솔에 기록되는 모든 오류 메시지에 대한 설명은 in.mpathd(1M) 매뉴얼 페이지를 참조하십시오.