What is a Microsoft Failover Cluster Virtual Adapter anyway?

제가 최근에 클러스터와 연계된 이슈를 해결하다가 보니 Failover Cluster Virtual Adapter에 IP가 할당된 것을 발견했습니다. 왜 일까? 고민하다가 좋은 글을 찾아서 공유해 봅니다.
배경 지식이 없으니 조금 힘드네요… 역시 언제나 그렇지만 제 번역은 항상 Poor 합니다… ; )
원문 : http://blogs.technet.com/b/askcore/archive/2009/02/13/what-is-a-microsoft-failover-cluster-virtual-adapter-anyway.aspx

Microsoft Failover Cluster Virtual Adapter 가 무엇일까?

종종 “Microsoft Failover Cluster Virtual Adapter 가 무엇이고, 우리는 그것을 통해 무엇을 할 수 있나요?” 란 질문을 받곤 합니다. 보통 정확한 대답은 “그냥 두세요 혼자서 알아서 당신을 위해 일하게 두시면 됩니다.” 입니다. 대부분의 사람들은 이런 대답에 충분히 만족 합니다. 하지만 일부는 더 알고 싶어합니다. 내 본 내용은 그 분들을 위한 내용입니다.

Windows Server 2008 Failover Clustring 의 네트워크 모델을 새로운 기능을 충족시키기 위해서 다시 작성되었습니다. (DHCP 서버로부터 IP을 할당 받는 기능 및 네트워크 적으로 분리된 즉 서로 다른 서브넷에 클러스터 노드들을 위치시키는 것) 추가적으로 이전 통신의 경우 UDP 브로드케스트를 이용했지만 현재는 약간의 TCP 통신이 가미된 UDP 유니케스트를 이용하여 통신하게 됐습니다. 이 모든 추가 기능들은 클러스터 내의 좀 더 신뢰성 있고 견고한 Communication connectivity 를 제공합니다. 클러스터 노드가 어디에 위치하고 있는지는 이제 신경 쓰지 않아도 됩니다. 더 이상 클러스터의 노드들이 같은 데이터 센터의 같은 서버 랙에 있는지 아니면 다른 OC3 WAN Connection 으로 연결된 원격 데이터 센터의 서버 랙에 있는지 신경 쓸 필요가 없습니다. 이를 통해 Cluster는 단일 지점 오류로부터 좀 더 자유롭게 되었습니다, e.g.. 네트워크 인터페이스 카드 (NIC) 카드 (그리고 이러한 새로운 디라이버의 이름은 “Network Fault-Tolerant or NetFT.sys” 입니다.). 실제로 유일한 최소 요구 사항은 클러스터 상의 모든 노드들 간에 2개 이상의 redundant communication conectivity 을 제공하는 것입니다. 이렇기 때문에 Cluster network driver (NETFT.SYS)는 클러스터에서 서비스 되는 어플리케이션과 서비스가 highly available 할 수 있도록 완벽한 라우팅 구조를 만들 수 있으며, 이와 동시에 Redudant communication connectivity 를 제공합니다.

Note : 클러스터 통신을 위해 적어도 2개 이상의 네트워크를 갖지 못한 경우 Cluster validation process 중에 Warning (Best practice 위반)으로 표시되게 됩니다. 이 내용은 하드웨어 요구사항의 Network Adpters and cable 섹션에서 표시됩니다.

새로운 기능에 대한 몇 가지 예를 제공하기 위해서 (물론 아직 새로운 네트워킹 모델에 대해 깊이 파해지친 못했지만), 전 클러스터 노드로 부터 클러스터 로그를 생성하여 클러스터 시작 시 어떻게 이 새로운 네트워크 모델이 반영되고 있는지 설명하고자 합니다. 클러스터 로그의 몇몇 엔트리들은 NETFT와 연관되어 있습니다. 한정 지을 순 없지만 이와 관련된 몇몇에 대해 설명은 아래와 같습니다.

NETFT – Network Fault-Tolerant
TM – Topology Manager (Cluster Netowrk topology에 대한 검색 및 관리. 네트워크 및 NIC의 오류를 보고. Microsoft Failover Cluster Virtual Adapter의 설정)
IM – Interface Manager (어떤 NIC 라도 모두 클러스터 구성의 일부로써의 책임을 짐)
NETFTAPI – NETFT Application Programming Interface (API)
FTI – Fault-Tolerant Interface

클러스터가 시작될 때, 이 이벤트들은 등록된 Indicating NETFT는 클러스터 아키텍처의 다른 부분들과의 통신을 준비합니다. (느낌은 오는데 해석이 않되네요… 죄송합니다. 아래의 로그들은 이벤트 처리처리를 위해 준비하는 내용입니다.)
As the cluster service starts, there are events registered indicating NETFT is preparing for communications with other pieces of the cluster architecture

00000784.000007cc::2009/01/30-14:26:38.199 INFO [NETFT] FTI NetFT event handler ready for events.
00000784.000007b0::2009/01/30-14:26:39.369 INFO [NETFT] Starting NetFT eventing for TM
00000784.000007b0::2009/01/30-14:26:39.369 INFO [NETFT] TM NetFT event handler ready for events.
00000784.000007b0::2009/01/30-14:26:39.369 INFO [CS] Starting IM
00000784.000007b0::2009/01/30-14:26:39.369 INFO [NETFT] Starting NetFT eventing for IM
00000784.000007b0::2009/01/30-14:26:39.369 INFO [NETFT] IM NetFT event handler ready for events.

다른 노드와 연결이 되게 되면 라우팅 경로가 추가 됩니다.

00000784.00000648::2009/01/30-14:26:39.744 INFO [NETFT] Added route <struct mscs::FaultTolerantRoute>
00000784.00000648::2009/01/30-14:26:39.744 INFO <realLocal>172.16.0.181:~3343~</realLocal>
00000784.00000648::2009/01/30-14:26:39.744 INFO <realRemote>172.16.0.182:~3343~</realRemote>
00000784.00000648::2009/01/30-14:26:39.744 INFO <virtualLocal>fe80::2474:73f1:4b12:8096:~3343~</virtualLocal> 00000784.00000648::2009/01/30-14:26:39.744 INFO <virtualRemote>fe80::8b6:30ea:caa3:8da7:~3343~</virtualRemote>
00000784.00000648::2009/01/30-14:26:39.744 INFO <Delay>1000</Delay>
00000784.00000648::2009/01/30-14:26:39.744 INFO <Threshold>5</Threshold>
00000784.00000648::2009/01/30-14:26:39.744 INFO <Priority>99</Priority>
00000784.00000648::2009/01/30-14:26:39.744 INFO <Attributes>1</Attributes>
00000784.00000648::2009/01/30-14:26:39.744 INFO </struct mscs::FaultTolerantRoute>

라우트 경로를 통해 노드들에 ‘도달할 수 있는’ 경로들에 대한 추가적인 이벤트들이 등록됩니다.

00000784.0000039c::2009/01/30-14:26:39.759 DBG [NETFTAPI] Signaled NetftRemoteReachable event, local address 172.16.0.181:003853 remote address 172.16.0.182:003853
00000784.0000039c::2009/01/30-14:26:39.759 DBG [NETFTAPI] Signaled NetftRemoteReachable event, local address 172.16.0.181:003853 remote address 172.16.0.182:003853
00000784.0000039c::2009/01/30-14:26:39.759 DBG [NETFTAPI] Signaled NetftRemoteReachable event, local address 172.16.0.181:003853 remote address 172.16.0.182:003853
00000784.000004f4::2009/01/30-14:26:39.759 INFO [FTI] Got remote route reachable from netft evm. Setting state to Up for route from 172.16.0.181:~3343~ to 172.16.0.182:~3343~.
00000784.000002f4::2009/01/30-14:26:39.759 INFO [IM] got event: Remote endpoint 172.16.0.182:~3343~ reachable from 172.16.0.181:~3343~
00000784.000002f4::2009/01/30-14:26:39.759 INFO [IM] Marking Route from 172.16.0.181:~3343~ to 172.16.0.182:~3343~ as up
00000784.000001f8::2009/01/30-14:26:39.759 INFO [TM] got event: Remote endpoint 172.16.0.182:~3343~ reachable from 172.16.0.181:~3343~
00000784.00000648::2009/01/30-14:26:39.759 INFO [FTW] NetFT is ready after 0 msecs wait.
00000784.00000648::2009/01/30-14:26:39.759 INFO [FTI] Route is up and NetFT is ready. Connecting to node W2K8-CL2 on virtual IP fe80::8b6:30ea:caa3:8da7%15:~3343~
00000784.0000061c::2009/01/30-14:26:39.759 INFO [CONNECT] fe80::8b6:30ea:caa3:8da7%15:~3343~: Established connection to remote endpoint fe80::8b6:30ea:caa3:8da7%15:~3343~.

이러한 변화들의 결과로 Cluster Networking 모델은 그 자체로써 실제 Cluster network driver 가 되었습니다. 물론 숨겨진 장치입니다만 어쨌든 어뎁터 입니다.

장치관리자의 기본 뷰에서는 숨긴 장치로 표시되지만, (숨김 장치 표시를 선택해야만 해당 장치를 볼 수 있습니다.) ipconfig /all 커멘드를 통해 클러스터 노드의 네트워크 설정에 대한 조회를 통해 쉽게 볼 확인 할 수 있습니다.

 

다른 어뎁터들과 마찮가지로 Microsoft Failover Cluster Virtual Adapter 역시 자신의 MAC 주소와 IPv4 및 IPv6 주소를 가지고 있습니다. IPv4 주소는 Automatic Private Internet Protocol Addressing (APIPA) address 이고 IPv6는 라우팅이 될 수 없는 Link-Local address 입니다, 하지만 이는 크게 중요하지 않습니다. 왜냐하면 모든 클러스터 상의 Communication은 실제 NIC 상에서 터널링을 통해 진행 되게 됩니다. 그리고 이 NIC 상의 통신 경로는 위에서 설명한 것과 같이 Cluster 서비스의 시작 시 해당 경로를 얻게 됩니다.

Microsoft Failover Cluster Virtual Adapter 의 MAC 주소는 실제 NIC의 MAC 주소를 기반으로 합니다.

Cluster network driver(netft.sys)는 커널 모드 드라이버로 Cluster 서비스에 의해 시작되고, 중지 될 수 있습니다.

Cluster network driver는 HKLM\System\CurrentControlSet\Services 밑에 entry를 가지고 있습니다.

추가로 아래는 클러스터 각 노드의 Microsoft Failover Cluster Virtual Adapter 라우팅 테이블 entry 입니다. 아래는 클러스터 노드에서 route print 커멘드를 실행하여 얻은 3자기 섹션의 output 입니다. 첫번째 파트는 해당 노드의 모든 인터페이스를 보여줍니다. 인터페이스 15번이 Microsoft Failover Cluster Virtual Adapter 입니다.

다음 화면은 IPv4의 라우팅 테이블 입니다. Microsoft Failover Cluster Virtual Adapter의 3개의 entry를 반영 하고 있습니다.

마지막은 IPv6의 라우팅 테이블 입니다.

자 우리는 어떤 경우에 문제를 겪게 될까요? 아래는 문제가 발생하는 몇 가지 경우입니다.

1. Microsoft Failover Cluster Virtual Adapter 의 Disable
2. Windows 2008 Failover Cluster가 설치된 상태에서 Sysprep 를 통해 초기화를 시도하는 경우 이경우 Cluster Validation 과정에서 문제가 될 수 있습니다.
3. 어뎁터의 정보를 수정한 경우

Hopefully, this gives you a better feel for this new functionality in Windows Server 2008 Failover Clusters, and like I stated at the beginning of the blog, the correct answer is to not do anything to the adapter - just let it work for you. Thanks and we hope this has been helpful.

Chuck Timon and John Marlin
Senior Support Escalation Engineers
Microsoft Enterprise Platforms Support