MSCS 의 Heartbeat 단절로 인한 서비스 영향도 최소화 설정

 

 

서로의 상태를 체크하는 것이 무엇보다도 중요하다.

운영 중인 서버의 HW 또는 SW 적인 장애로 인한 서비스의 중단을 최소화하기 위하여 적용되는 가장 일반적인 기술이 이중화다.

 Microsoft 에서 제공하는 이중화 기술은 MSCS (Microsoft Cluster Service) 로서 제조사의 기술로서 압도적으로 안정적인 기술을 보인다. 이 기술은 알다 시피 SQL, 파일 서버 등에 적용되고 Exchange 는 2010 부터 DAG 이라는 기술을 적용하면서 MSCS 를 졸업했다.

 (실제로 익스체인지는 HW 적인 가용성 문제보다는 SW 적인 파일 시스템의 손상으로 인한 시스템의 장애가 발생하는 경우가 더 많았기에, MSCS 의 기술이 그다지 많은 도움이 되지 않는 경우가 많았다.)

 

 MSCS 는 기본적으로 정상적으로 동작하는 노드 즉 머신으로 서비스를 위한 리소스를 넘겨 주는 것을 가장 큰 목적으로 하기에 서로의 상태를 체크하는 것이 무엇보다도 중요하다.

 이를 Micsosoft  에서는 Heartbeat 라는 이름으로 부른다. (물론 다른 벤더도 비슷한 이름으로 부르기도 한다.) 문제는 Heartbeat 가 깨진 경우, MSCS  가 비정상적인 동작을 보일 수 있다. 이를 예방하기 위한 방법을 알아 보도록 하자.

 

 

•  Heartbeat 는 가급적 Switch 를 타도록 구성한다.

 일반적으로 2 node cluster 의 경우, Cross link 로 연결하는 것이 일반적이지만, 문제는 서로간에 연결되는 NIC 의 물리적인 손상이 발생하는 경우에 이슈가 된다.

 NIC 은 실제로 HDD 나 Fan 처럼 구동하는 부분이 없고, CPU 처럼 과도한 열이 발생하는 파트가 아니므로 물리적인 장애는 매우 드물게 나타난다. 드라이버의 이슈로 인하여 한쪽 노드에서 다운이 발생하는 경우는 Heartbeat 의 단절로 처리하게 되지만, 물리적인 NIC 의 장애가 발생하는 경우, 두 서버 모두 Heartbeat 의 물리적인 Connectivity 의 장애 (예를 들어 둘다 Lan Cable 이 빠져 버린 것으로) 인식하게 된다.

 

경험적으로는 MSCS 자체의 Hang, 서비스 불능 등의 장애가 발생하는 경우가 있다.

 이론상 이 경우, 해당 시점에서 Quorum 을 소유하고 있는 Node 로 모든 리소스가 이동하게 되지만, 경험적으로는 MSCS 자체의 Hang, 서비스 불능 등의 장애가 발생하는 경우가 있다. 정상적으로 동작한다 할지라도 shared nothing 구조를 가지는 MSCS 의 특성상 단지 저가격의  NIC 하나 때문에 서비스의 단절이 발생하게 된다. 특히 SQL 의 대규모 트랜젝션이나 Batch  가 동작하는 경우라면 role-back 등으로 인한 시스템의 장애 시간이 단순한 서비스 중단 이상의 피해를 야기할 수 있다.

 

 따라서 예산이 허용한다면, 추가 Switch 를 구매하거나 신뢰성 있는 여유 포트의 switch 를 사용하여 heartbeat 를 구성하도록 하자.

 

•  Heartbeat 는 이중화 한다.

 

 Heartbeat 는 이중화를 강력하게 권장한다. 이중화를 하는 이유는 알다 시피 단일 포인트의 장애를 예방하기 위함이다. 단, 이중화 시에도 주의하여야 할 부분이 있는데.

1. Teaming 을 사용하지 않는다. 이는 MS 에서도 언급하고 있는 부분이다. Teaming 은 절대 사용하지 말 것.. 장애 유발 이슈가 된다.
2. 물리적으로 다른 NIC 을 사용한다. 요즘 대부분 서버에 multiport NIC  이 기본 탑재된다. 이를 이용한 이중화는 별로 의미가 없는 작업이다. 이는 물리적으로 동일할 뿐 아니라 SW 적인 드라이버도 동일하게 사용하므로 둘 중 하나에 문제가 생기면 둘다 Down 될 가능성이 매우 높다. 가급적이면 물리적으로 분리된 드라이버를 사용하기를 권장한다.

 

• 최종적으로 서비스 NIC 에 Heartbeat 를 구성한다.

 

Heartbeat 를 서비스  NIC 에 구성한다. MS 의 용어로는 혼합 네트워크 구성이다. 이를 사용하므로서 Heartbeat 전용 포트에 둘다 문제가 발생하여도 최종적인 Check 가 가능하다. 단, 우선 순위를 최소한으로 낮춤으로서 평소에는 Heartbeat 전용 회선을 통해서만 Heartbeat 를 통신하게 하므로서 서비스 포트의 성능 저하를 최소화 할 수 있다.