Maystyle :
Admin : New post
Guestbook
Local
media
Catergories
Recent Articles
Recent Comments
Recent Trackbacks
Calendar
Tag
Archive
Link
Search
 
해당되는 게시물 24건
  Windows 2008 Failover Cluster Persistent Reservation 
작성일시 : 2011.01.05 22:11 | 분류 : Windows Server/Cluster

Persistent Reservation란 SCSI-3의 Command 로 Cluster를 관리하는 노드에서는 해당 LUN을 예약하여 LUN을 보호한다.

Cluster에 의해 예약된 LUN은 다른 머신에서는 RAW로 표시되며 접근이 불가능하다.
하지만 CLI를 이용하는 경우 Persistent Reservation을 해제 하여 접근 할 수 있다.
Cluster Node <NodeName> /Clear:<DeviceNumber>
예) Cluster Node CluNode01 /Clear:2
물론 이 경우 단일 NTFS 파티션에 대한 접근으로 인한 손상이 발생 할 수 있을 것이다.

더불어 Cluster가 아닌 머신이 먼저 온라인 시킨 파티션은 Cluster 및 해당 머신이 모두 접근이 가능하다.

  What is a Microsoft Failover Cluster Virtual Adapter anyway? 
작성일시 : 2010.10.28 11:27 | 분류 : Windows Server/Cluster

제가 최근에 클러스터와 연계된 이슈를 해결하다가 보니 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 가 되었습니다. 물론 숨겨진 장치입니다만 어쨌든 어뎁터 입니다.

image

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

 image

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

image

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

image

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

image

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

image

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

image

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

image

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

image

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

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

  Windows 2003 x86 MSCS 용 리소스 모니터 
작성일시 : 2010.07.24 20:25 | 분류 : Windows Server/Cluster

MSCS에 Microsoft가 아닌 다른 Product 를 올리는 경우 가끔씩 x64 버전의 리소스 모니터와 호환성 문제를 일으키는 경우가 있습니다. 이런 경우 아래 위치로 x86 버전의 리소스 모니터를 추출하여 복사해 넣어주면 됩니다.
[분석]
아래와 같이 리소스를 등록하는 와중에 (amqmclrn.dll 등록) Failed to create resmon process, error 와 같은 에러를 확인 하였습니다. 해당 리소스 DLL이 32bit라는 것이 확인 되므로 이는 32bit 용 리소스 모니터가 필요할 것으로 추정하였고, 이에 C:\WINDOWS\SysWOW64\에 리소스모니터를 넣어준 후 문제가 해결 됨을 확인 하였습니다.

Cluster log
[RM] Possible 32-bit resource DLL: C:\Program Files (x86)\IBM\WebSphere MQ\bin\amqmclrn.dll
INFO [FM] RmLoadResourceTypeDll call failed 193
INFO [FM] FmpRmLoadResTypeDll: going to try loading restype IBM MQSeries MSCS in 32-bit resrcmon.exe.
WARN [FM] Failed to create resmon process, error 2.
ERR  [CS] Halting this node to prevent an inconsistency within the cluster. Error status = 2                                                
  Network Name Resource 에서의 DNS 등록이란? 
작성일시 : 2009.07.24 12:24 | 분류 : Windows Server/Cluster

원문 : http://blogs.msdn.com/clustering/archive/2009/07/17/9836756.aspx

안녕하세요.
오늘 포스트에서는 Network Name (NetName) Resource 에 대해서 좀 알아보고자 합니다.
(내용 그대로 해석 보다는 제가 더하고 싶은 내용은 더하고 빼고 싶은 내용은 빼는 나름대로의 해석을 통해 글을 진행 합니다. 양해 부탁드립니다.)

소개
Netname의 매개변수는 DNS 명입니다.
이 Netname 리소스는 Client 로 하여금 DNS 조회를 통해 IP를 찾을 수 있도록 도와주는 리소스 입니다.
물론 해당 클러스터 그룹에 IP와 Netname이 같이 등록이 되어 있고, 이 둘 사이에는 종속성이 설정 되있겠죠?

image

위 그림에서 보는것과 같이 우리가 Netname 리소스인 testcno 로 조회를 하게 되면 우리는 이와 연결된 172.24.13.99 혹은 2001:4898:…. 으로 연결이 가능합니다.
이 관계를 종속성이라고 하는데 Netname 과 IP와의 관계는 OR 종속성을 갖고 있습니다.

아무튼 우리가 클러스터 그룹에 IP 리소스와 Netname 리소스를 등록해주고 이를 종속성 관계로 잘 정의 하게 되면 우리는 해당 Netname의 매개 변수와 IP의 매개 변수를 DNS 레코드들 속에서 찾을 수 있습니다.

image

image

물론 멀티 서브넷 클러스터에서는 위 그림과 같은 구성을 볼 수 있겠죠?
단 위와 같이 구성을 하기 위해서는 두 네트워크 IP 구성 중 하나는 Gateway 설정을 제거 하고 수동으로 직접 라우팅 PATH를 설정해줘야 합니다.

어떻게 DNS 등록이 일어나게 되는가?
DNS 등록 로직은 NetName Cluster Resource DLL에 이미 구현되어 있습니다.

(Resource DLL 은 아래 그림과 같이 리소스 들의 실제 구현을 위한 공통 분모라고 보시면 됩니다. 즉 Network Name 리소스의 모든 속성은 해당 DLL에 정의가 되어 있는 거고, 우리가 Netname 리소스를 생성하게 되면 해당 DLL에 정의되어 있는 내용을 기반으로 리소스가 생성 되는거죠…^^)

image

1. Network Name 리소스가 온라인 되거나 온라인 직후
- OR 종속성으로 연계된 리소스 들이 온라인 됩니다. (예 : IP) 그리고 일반적으로 IPv6 리소스가 IPv4 보다 먼저 온라인되게 됩니다. 그렇기 때문에 IPv6 리소스가 먼저 DNS에 등록되게 되죠.

2. 만약 Cluster가 idle이면 매 24시간 마다 자신의 DNS 정보를 Refresh 합니다.

3. 만약 Netname에 연개된 IP가 추가 되거나 제거 되면 리소스의 On/Off 없이 자동으로 DNS에 등록하게 됩니다.
(Windows 2003에서는 종속성 추가를 위해서 잠시 동안 Netname Resource를 Offline 해야 합니다.)

DNS 등록에 따른 시스템 영향

1. Primary DNS Suffix
Netname의 suffix는 기본적으로 host 서버의 suffix와 동일합니다. 기본값은 AD명이 됩니다.
image

실제 AD의 존을 확인한 내용입니다.
image

2. 특정 DNS suffix 사용하기
실제로 물리적으로 맵핑된 NIC의 설정에서 진행해야 합니다.
아는 것 처럼 NIC의 속성에서 아래 그림과 같이 DNS Suffix를 따로 줄 수 있습니다.

image

해당 설정이 적용되기 위해서는 “Use this connection’s DNS suffix in DNS registration”이 체크 되어 있어야 합니다. 그와 더불어 “Register this connection’s addresses in DNS”이 언 체크 되어 있으면 우리가 설정해준 suffix는 물론 원래 host의 suffix 역시 등록이 되지 않게 됩니다.

물론 DNS에서 Dynamic update가 설정이 되어 있어야 합니다.
추가적으로 Secure only 설정 만으로 추가된 suffix를 등록할 수 는 있지만 만약 해당 레코드가 이미 등록되어 있다면 해당 레코드를 업데이트 하기 위해서는 full control 이 필요합니다.
image

  MSCS 클러스터 환경에서 Error 1721 발생한다. 
작성일시 : 2009.03.13 10:17 | 분류 : Windows Server/Cluster

[환경]
2 node A/A Cluster (SQL Server)

[현상]
재 부팅 이후 그룹들이 한쪽 노드에 몰리고 나머지 노드에서 클러스터 시작이 않됨
이후 재 부팅을 하게 되면 정상 적으로 클러스터 서비스가 시작되나 이네 Error 1721 오류가 발생하면서 “리소스 부족” 메세지와 함께 클러스터에 “!”가 표시됨

또한 클러스터 로그는 아래와 같은 메세지를 발생 시킵니다.

[JOIN] Sponsor XXX.XXX.XXX.XXX is not available (JoinVersion), status=1753.
[JOIN] JoinVersion data for sponsor XXX.XXX.XXX.XXX is invalid, status 1753.
[JOIN] Sponsor ServerName is not available (JoinVersion), status=1753.
[JOIN] JoinVersion data for sponsor ServerName is invalid, status 1753.
[JOIN] Sponsor XXX.XXX.XXX.XXX is not available (JoinVersion), status=1753.
[JOIN] JoinVersion data for sponsor XXX.XXX.XXX.XXX is invalid, status 1753.
[JOIN] Spawning thread to connect to sponsor XXX.XXX.XXX.XXX
[JOIN] Asking XXX.XXX.XXX.XXX to sponsor us.
[JOIN] Waiting for all connect threads to terminate.
[JOIN] Sponsor XXX.XXX.XXX.XXX is not available (JoinVersion), status=1722.
[JOIN] JoinVersion data for sponsor XXX.XXX.XXX.XXX is invalid, status 1722.
[JOIN] All connect threads have terminated.
[JOIN] Unable to connect to any sponsor node. [INIT] Failed to join cluster, status 53

[설명]
클러스터 연결을 위해서는 RPC 포트를 이용하게 됩니다. 이때 이 RPC 포트가 100개 미만일 경우 위와 같이 리소스가 부족하다는 메세지가 뜨게 됩니다. 기본값은 10개 입니다. 즉 위의 경우에는 클러스터가 Active 노드와의 통신을 하기 위한 RPC 포트가 부족하기 때문에 발생하는 메세지 입니다.

[해결 방안]
HKEY_LOCAL_MACHINE\Software\Microsoft\RPC\Internet 레지스트리에 보면 아래와 같은 레지스트리가 있습니다.
Ports: REG_MULTI_SZ: 4000-4009
PortsInternetAvailable: REG_SZ: Y
UseInternetPorts: REG_SZ: Y

지금 위의 예는 기본 값에 해당합니다.
위에서 Ports 값을 5000-5099 로 변경하면 포트 부족으로 인한 문제가 해결 되게 됩니다.

[추가 1]
여러분이 RPC를 Heavy 하게 사용하는 서버를 운영하고 있다면 (예 Dcom 등등) 이 경우에는 포트 갯수를 100개 이상으로 늘려주셔야 할 수 도 있습니다.

[추가 2]
Windows에서 사용하는 포트 갯 수 늘리기
Windows의 기본 값은 약 5000개의 포트를 사용하는 것입니다. 해당 포트는 65000여개 까지 늘려줄 수 있습니다.
아래의 레지스트리 값을 수정하시면 됩니다. (없을 경우 생성하시면 됩니다.)

HKLM\System\currentcontrollset\services\tcpip\parameters
MasUserPort
REG_DWROD : 65534

  Cluster 구성 정보 삭제 
작성일시 : 2009.03.10 16:07 | 분류 : Windows Server/Cluster

Windows 2003 의 Cluster는 이전과는 달리 삭제가 불가능 합니다.
다만 클러스터 구성 정보는 제거가 가능하죠.

cluster node nodename /forcecleanup

중요한 것은 만약 Binary들이 정상적으로 설치가 되어 있는 경우에는 Cleanup 한 이후 다시 클러스터에 재 조인을 하게 되면 해당 클러스터 관련 정보들이 복제 되기 때문에 거의 문제가 없이 클러스터에 조인이 가능 하다는 점 입니다.

물론 해당 작업을 하기 이전에 Active Node의 HKLM\Cluster 하위의 잘못 구성된 정보를 수정하셔야 겠죠?

출처 : http://support.microsoft.com/?id=282227

  Windows 2008 Clusdisk.sys and Clusnet.sys where is this? 
작성일시 : 2009.02.19 10:33 | 분류 : Windows Server/Cluster

The location of cluster devices were changed in windows 2008.
On the windows 2003, We can found that on the non plug and play devices, but on the windows 2008 it has invalved in it’s original location. for exemple, clusnet is located on network devices and clusdisk is located on system devices.

but i had have some troubles to find it… :)

  OS에서 파티션된 Disk는 왜? 클러스터에서 사용할 수 없을까? 
작성일시 : 2009.02.12 12:28 | 분류 : Windows Server/Cluster

MSCS 클러스터는 Disk Letter가 아닌 물리 디스크에 할당된 Signature 정보를 통해 Disk를 관리합니다.
즉 서버에서 본다면 1Device 당 1Drive 가 되어야 할 것이며, 스토리지 입장에서 본다면 최소 1LUN 당 1Dirve 로 제공 되어야 합니다.

즉 서버 측에서는 물리적으로 분리된 Disk 를 사용해야 합니다.
물론 아래 그림에서 로컬 스토리지 역시 분리되어 있지만 로컬 스토리지 의 경우 굳이 분리 하지 않아도 무방합니다.
하지만 공유 스토리지는 MUST Device 하나당 Disk 하나여야 합니다.

디스크 관리

로컬 스토리지
-------------------------------------------------
|||||||||||||||C:|||||||||||||||||||||||
||||||||||||||||||||||||||||||||||||||D|||||||||||||||||||||||||||||||||
-------------------------------------------------

공유 스토리지
-------------------------------------------------
||||||||||Q|||||||||||
||||||||||M||||||||||
||||||||||||||||||||||||||S||||||||||||||||||||||||||||||||
|||||||||||||||||||||||||L|||||||||||||||||||||||||||||||||
__________________________________________________

  Why my vbs script can not add to the MSCS? 
작성일시 : 2009.01.13 21:59 | 분류 : Windows Server/Cluster

Few days ago I got a trouble when adding Generic Script to MSCS.
Finally i found the solution…

For add to Cluster, Script implement the Generic Script resource DLL entry points.
This is MSDN document about that.
http://msdn.microsoft.com/en-us/library/aa373089(VS.85).aspx

Normal Script doesn’t added on MSCS…^^
Only Script that are implemented the Generic Script resource DLL entry points, can added.

  Cluster Chapter 1 Introduction 
작성일시 : 2008.12.30 17:21 | 분류 : Windows Server/Cluster

The Cluster means a Set of computers that works as a 1 network identity.
In Microsoft technology, Microsoft supports 2 technologies in Cluster. The first is a MSCS and the second is a NLBS.

It is designated for High Availability.

Availability = MTTF ./ (MTTF + MTTR)

MTTF is a term of occur a system failure period and MTTR is a term of recovery.
For improve the availability, you should increase MTTF or reduce MTTR.

The Cluster system appears as a single system to network clients.
Clients don't know about that is clustered or not. But a service would be in the second node because of system fail on the first node.

 Prev   1   2   3   Next