Maystyle :
Admin : New post
Guestbook
Local
media
Catergories
Recent Articles
Recent Comments
Recent Trackbacks
Calendar
Tag
Archive
Link
Search
 
해당되는 게시물 7건
  MSCS 에서 2TB 이상의 디스크 공간 사용하기 
작성일시 : 2008.10.22 14:31 | 분류 : Windows Server/Cluster | 태그 : Disk, GPT, mbr, mscs, support, TB

Windows 2003 SP1 이전 그리고 XP에서는 2TB의 제한이 있는 MBR만 지원이 됐었습니다.
하지만 Windows 2003 SP1이 나오면서 IA 플랫폼에서만 지원됐던 GPT까지 지원이 됩니다.

다만 MSCS 의 Shared Disk에서는 GPT 디스크를 사용할 수 없었습니다.
하지만 "sankim"님 덕분에 좋은 사실을 알게됐습니다.
다음 hotfix (http://support.microsoft.com/kb/919117) 를 설치하게 되면 windows 2003의 MSCS에서도 2TB 이상의 디스크를 사용할 수 있습니다.

물론 Windows 2008에서는 별도의 hotfix 없이도 GPT를 지원합니다....^^

출처 : http://blogs.technet.com/sankim/archive/2007/05/17/windows-2003.aspx

신고
  MSCS 각 모듈에 대한 설명 
작성일시 : 2008.10.17 12:14 | 분류 : Windows Server/Cluster | 태그 : Checkpoint Manager, Cluster, CP, Database Manager, DM, Failover Manager, FM, Global Update Manager, gum, lm, Log Manager, Membership Manager, mm, mscs, NM, Node Manager

클러스터 로그를 보게 되면 FM, GUM 등을 확인 할 수 있습니다.
분명 특정 Role을 하는 녀석들의 통칭일껀데 도대체 이게 뭘까요?

해당 모듈명을 알게 되면 로그를 보는데도 클러스터를 이해하는대도 큰 도움이 됩니다.
본 내용을 보기 위해서는 이전 글 (http://maystyle.tistory.com/357)의 Cluster 데이터 베이스에 대한 내용을 먼저 숙지하셔야 합니다.

1, DM (Database Manager)
Cluster의 Database를 관리합니다. 특정 노드에서 Cluster 구성 정보가 변경되게 되면 DM은 Cluster 구성 정보를 로컬의 레지스트리에 저장합니다.

2. LM (Log Manager)
변경 정보를 쿼럼 디스크에 반영하며 클러스터의 구성 정보를 최신 정보로 유지하는 책임을 지게 됩니다.

3. GUM (Global Update Manager)
변경된 구성 정보를 다른 노드에 동기화 시킵니다. Global Update는 무결성을 기반으로 합니다.
즉 Passive 된 노드에 구성 정보를 Update 할 경우 해당 노드의 Cluster Database에 대한 Update가 실패 하게 되면 Active Node 에서는 "Poison Packet"을 Passive Node에 보내 Cluster 서비스를 중지 시킵니다.

4. CP (Checkpoint Manager)
각 리소스의 레지스트리 내용 변경이 발생 할 경우 Quorum 의 registry checkpoint 파일에 저장하는 역활을 합니다.이 녀석의 역활은 꽤나 중요한데 클러스터에서 Fail over가 발생 할 경우 쿼럼에 저장된 데이터 베이스의 사본을 읽는 것이 아니라 해당 쿼럼의 Check Point 파일을 일어 데이터베이스의 내용을 최신의 정보로 유지하게 됩니다.

5. NM (Node Manager)
Heartbeat을 통해 Cluster 상의 노드의 Health를 확인 합니다.
만약 문제가 감지되게 되면 "regroup event" 를 multicast로 전송하고 response가 오는 노드만을 대상으로 클러스터 노드를 재구성합니다.
NM은 Quorum Disk Arbitration을 관리하면 Heartbeat 통신이 중단 되는 경우 Quorum을 소유한 노드로 모든 리소스를 fail over 시킵니다.

6. MM (Membership Manager)
현재 실행 중인 노드의 리스트를 관리합니다. NM에서 reqroup event 를 보내게 되면 MM은 Regroup event 응답 여부에 따라 클러스터 노드의 리스트를 재구성합니다. 문제 노드가 정상으로 동작하게 되면 MM은 해당 노드를 다시 클러스터에 추가하게 됩니다.

7. FM (Failover Manager)
리소스와 리소스 그룹의 시작과 중지를 책임 집니다.
Failover 상황에서 어느 노드에서 가상 서버가 시작될 지를 판한합니다.

출처 : Technet 세미나

신고
  Cluster의 Disk 접근 문제 
작성일시 : 2008.10.17 11:39 | 분류 : Windows Server/Cluster | 태그 : 1034, clusdb, clussvc, Cluster, connection problem, Disk, mscs, problem, Signature

클러스터를 운영하는 중에 ClusSvc 에 1034 이벤트와 함께 DISK를 찾을 수 없다는 문제가 발생하는 경우가 있습니다.

cluster가 Disk에 접근 하기 까지는 아래와 같은 큐를 통과해야 합니다.
이 큐의 각 구성요소 중 하나라도 문제가 있게 되면 클러스터는 디스크를 찾을 수 없게 됩니다.

---------------------------------------------------------------------
Cluster APP (가칭 :클러스터의 소프트웨어 모듈을 가르킴)
---------------------------------------------------------------------
ClusDisk (Disk 장치의 필터 디바이스로 Ownership 관리)
---------------------------------------------------------------------
HBA 관련 모듈 (장치 드라이버를 비롯한 소프트웨어 모듈)
---------------------------------------------------------------------
HBA 카드
---------------------------------------------------------------------
Cable
---------------------------------------------------------------------
SAN Switch
---------------------------------------------------------------------
Cable
---------------------------------------------------------------------
Controller
---------------------------------------------------------------------
Disk
---------------------------------------------------------------------

1. Cluster APP
Cluster는 Disk를 확인 하기 위해 Signature 를 이용합니다.
이 Signature는 Disk의 MBR에 기록 되고, 서버에서는 자신의 레지스트리에 저장된 Signature 정보를 통해 디스크에 접근 하게 됩니다.
즉 Signature 정보에 문제가 있게 되면 Cluster는 Disk를 확인 할 수 없어 문제가 발생합니다.
해당 정보는 아래 레지스트리에서 확인 할 수 있습니다.
HKLM/System/CurrentControlSet/Services/Clusdisk/Parameters
이경우에는 dumpcfg 라는 툴을 이용해서 Disk의 MBR의 Signature를 쉽게 변경 할 수 있습니다.
참고 : http://support.microsoft.com/kb/280425

2. ClusDisk
Disk에 접근하는데 있어 최 상위 물리 계층에서 동작하는 필터 드라이버 입니다.
주요 Role은 Owner Ship 여부에 따라 디스크 접근 권한을 주거나 뺏는 역활 입니다.
Signature 에 문제가 없다면 ClusDisk 의 문제를 추정할 수 있습니다.
하지만 거의 대부분 ClusDisk의 문제는 없고 쿼럼에 접근이 않된다거나 로컬의 클러스터 정보 및 쿼럼의 정보가 손상된 경우가 대부분 입니다.
문제 판별은 http://support.microsoft.com/kb/280425 의 내용과 같이 장치 관리자에서 해당 필터 드라이버를 Disable 시킨 후 문제 여부를 확인 할 수 있습니다.
일반적으로 클러스터의 정보는 HKEY_LOCAL_MACHINE\Cluster 키 밑에 저장되어 있습니다.
그 파일은 SystemRoot%\Cluster\ClusDB 와 Q:\MSCS\Chkxxx.tmp 입니다.
즉 하나라도 정상으로 판별되는 녀석이 있다면 해당 파일로 동기화를 해주게 되면 문제가 해결 되게 됩니다.
물론 쿼럼 손상의 경우 시작 옵션에 fixquorom 을 주거나 쿼럼을 재 생성해도 문제를 해결할 수 있습니다.

3. HBA 관련 모듈
디바이스 드라이버 및 해당 드라이버를 지원하기 위한 S/W를 통칭 합니다.
즉 이 부분 부터는 장치의 문제로 볼 수 있으며 해당 장치를 fix 해주면 됩니다.

4. HBA 카드 ~ Disk
솔직히 MS만 하는 저는 뭐라 말씀 드릴 부분이 없습니다.
장치의 문제로 볼 수 있으며 해당 구간 구간에 대한 TEST가 진행 되어야 합니다.

[기타]
시작 옵션 정리
net start clussvc /NoQuorumLogging
net start clussvc /ResetQuorumLog
net start clussvc /FixQuorum

신고
  MSCS 좀더 알아보기 1 
작성일시 : 2008.05.28 12:57 | 분류 : Windows Server/Cluster | 태그 : microsoft cluster service, mscs

MSCS는 뭔가요?
http://maystyle.tistory.com/307 에서 정리했습니다.

그럼 위의 지식은 있다고 생각하고 좀더 깊이 들어가 보겠습니다.
 
전 Cluster Service Architecture 를 3부분으로 나눴습니다. 순 개인적인 관점이죠...ㅋ
일단 우리가 핸들링이 가능하고 문제 발생 시 핸들링이 가능하며, 직접 확인이 가능한 Device Driver 등을 Key Device라 명명했습니다. 실제로 Cluster를 운영하면서 가장 크게 느끼는 점은 Cluster의 기본 본질은 특정한 리소스에 대한 소유권 관리 였습니다.  이 리소스 중 가장 중요하고 확인 가능한 리소스가 바로 Disk 와 네트워크 입니다. 즉 Disk와 Network라는 자원을 할당하고 이에 대한 소유권을 관리하는 것이 기본 적인 본질이고, 이러한 소유권 관리를 위해 Cluster 실제 Device 윗단에서 필터 드라이버의 형태의 디바이스 드라이버를 두고 이 소유권을 관리하게 됩니다.
그와 동시에 Cluster Database 즉 클러스터의 변경 사항을 관리하며 기록하는 녀석이 있는데, 이게 Cluster Database 입니다. 실제 위치는 HKLM\Cluster 에 관리 사항이 등록되며, 해당 등록된 레지스트리 값은 SystemRoot%\Cluster\ClusDB와 쿼럼\MSCS\Chkxxx.tmp로 저장이 되게 됩니다. 물론 각 노드에서 로딩하는 정보는 clusdb 이며, 로딩이 끝나게 되면 해당 정보는 레지스트리에 등록되어 관리 되게 됩니다. 또한 클러스터의 정보 변경 사항은 Chkxxx.tmp 를 통해서 복사본을 만들어 관리가 됩니다. 그리고 제 개인적인 사견이지만 chkxxx.tmp는 Database 개념에서 봤을때 실제 DB파일로 보면 됩니다. 각 노드의 로컬에서 DB 파일을 관리하긴 하지만 실제 DB 처럼 역활을 하는 부분은 chkxxx.tmp 그리고 로그는 Quolog.log라 생각하고 있습니다. 왜 이런 DB를 공유 저장소 및 각 노드에서 2중 관리하게 되는지에 대해서는 클러스터 서비스의 목표인 failover 처리라는 측면에서 보면 이유에 대한 추정이 가능합니다. 그리고 Quolog.log를 통해서 DB 파일에 대한 원자성을 보장하게 됩니다. 일단 살아날때는 로걸에 있는 DB 를 쓰고, 이 DB에 대한 원자성 보장은 로그를 통해한다. 라고 생각하면 됩니다. 정리하면 로딩할때는 clusdb를 쓰고 이 로딩된 정보를 레지스트리에 넣어서 관리하고 변경 사항이 있으면 quolog.log에 기록을 하며, 더불어 복사본 DB로써 쿼럼에 데이터를 저장한다고 보면 될꺼 같습니다.

신고
  MSCS (Microsoft Cluster Service) 
작성일시 : 2008.03.20 00:07 | 분류 : Windows Server/Cluster | 태그 : microsoft cluster service, mscs, 구성, 서비스

MSCS (Microsoft Cluster Service)란?

최초의 Fail Over Cluster는 VMS에서 시작되었습니다.
그래서 인지 Windows Server와 H/A 혹은 Fail over cluster라 불리우는 MSCS를 주위에서 흔하게 볼 수 있습니다.
MSCS는 N+1개의 서버로 구성이 됩니다. 이때 N에 해당하는 서버는 특정 서비스를 제공하는 서버 이며, 1대 혹은 7대까지 지원이 됩니다. 그래도 이러한 서비스를 하는 '활성 노드'에서 문제가 발생 하게 되면 해당 서비스를 예비노드가 대신 처리하게 되는 구조를 가지게 됩니다.

MSCS를 구성하기 위한 필요 조건은?

MSCS는 일단 Windows Enterprise Edition을 사용하신다면, 무료입니다. 하지만 몇가지 사전에 준비해하는 조건이 있습니다.
- Windows 2000, 2003 EnterPrise 이상의 제품
- Active Directory
(최소 Domain Controller를 위한 1개이상의 서버 / 타 서버와 역활 공유 가능)
- SAN Switch 및 Storage
(최소 MSCS를 위한 쿼럼 데이터를 저장하기 위한 1개의 파티션은 공유 스토리지에 위치해야함)
- 2개 이상의 Network Card
(Public, Private 통신을 위해 2개가 필요함)

Failover 가능한 서비스는?

일반적으로 서비스를 위한 네트워크 이름 과 IP 제공하는 서비스 (하단 목록) 및 해당 서비스가 Disk에 데이터를 기록하게 된다면 실제 디스크 로 구성됩니다.

즉 사용자는 해당 서비스를 사용할 때 물리 노드 구성과 관계 없이 서비스의 IP나 네트워크 이름을 통해 접근이 가능하게 됩니다.

-DHCP 서비스 및 WINS 서비스
-인쇄 스풀러
-파일 공유
-로컬 쿼럼
-주 노드 집합
-일반 응용 프로그램
-일반 스크립트
-일반 서비스
-볼륨 섀도 복사본 서비스 작업

그리고 이러한 서비스를 제공하기 위해서는 필수 적으로 "인터넷 프로토콜 주소", "네트워크 이름", "실제 디스크" 등의 리소스들이 제공되어야 합니다.

물론 이와 더불어 MSCS는 다음의 서비스에 대한 Fail over 도 지원 합니다.

- MS SQL Server
- MS Exchange Server
- MS Biztalk Server
- IIS Server

또한 3th party 벤더에서는 MSCS를 위한 추가 구성요소 설치를 통하 역시 fail over를 제공합니다.

- Oralce Database
- IBM MQ

어떻게 구성 되나요?

크게 일반적으로 통신을 위한 Public Network 그리고 노드간의 Health Check를 위한 Private Network (Cross Cable 로 구성해도 됩니다.) 그리고 DC 및 SAN Switch (1개만 있어도 무방함) 와 공유 스토리지가 필요합니다. 

이해하기 쉽게 알려주세요.

실제 서비스는 물리 계층에서 제공하게 됩니다.
하지만 사용자는 해당 물리 계층의 존제 여부도 모르죠... 단지 실제 서비스를 제공 받을 때 해당 서버의 이름 위의 그림을 보자면 Virtual Node 라는 이름으로 접근 하거나 IP 주소 192.168.0.3 으로 제공 받게 됩니다.
즉 실제 서비스의 물리적 노드가 활성 노드 즉 해당 서버 명  Node 1, IP 주소 192.168.0.1 일지라도 실제로는 서비스를 하는 가상 노드를 통해 서비스를 받게 됩니다. 

참조 : http://www.microsoft.com/windowsserver2003/enterprise/clustering.mspx

신고
  MSCS 문제 해결 도구 
작성일시 : 2008.03.19 23:27 | 분류 : Windows Server/Cluster | 태그 : ClusterRecovery.exe, microsoft cluster service, mscs, 클러스터 서버 복구 유틸리티, 클러스터 진단 및 확인 도구

클러스터 서버 복구 유틸리티(ClusterRecovery.exe)와 클러스터 진단 및 확인 도구(ClusDiag.exe)를 사용하여 단일 복사본 클러스터에 대한 문제를 해결할 수 있습니다. 또한 Windows 이벤트 로그 및 Cluster.log 파일을 확인하여 단일 복사본 클러스터에서 발생하는 이벤트를 검사할 수 있습니다.

클러스터 서버 복구 유틸리티

클러스터 복구 유틸리티는 공유된 버스의 디스크에 오류가 발생한 후에 특히 서버 클러스터에서 유용한 여러 기능을 수집하는 도구입니다. 클러스터 서버 복구 유틸리티는 Microsoft Windows Server 2003 Resource Kit 도구에 포함되어 있습니다. 또는 클러스터 서버 복구 유틸리티(ClusterRecovery.exe)(Cluster Server Recovery Utility (ClusterRecovery.exe))에서 클러스터 서버 복구 유틸리티를 다운로드할 수 있습니다.

클러스터 진단 및 확인 도구

클러스터 진단 및 확인 도구는 이전 프로덕션 서버 클러스터에서 기본 확인 및 구성 분석 검사를 수행하고 로그 파일을 만듭니다. 따라서 시스템 관리자는 프로덕션 환경에서 배포하기 전에 구성 문제를 식별할 수 있습니다. ClusDiag는 서버 클러스터의 각 노드에서 모든 관련 로그 파일 및 이벤트 로그를 캡처하고 간편한 분석 및 문제 해결을 위해 단일 파일로 병합합니다. 관리자는 기본 제공 필터링, 병합 및 책갈피 지정 기능을 사용하여 이러한 로그 파일을 분석하고 다양한 진단 보고서를 생성할 수 있습니다. 또한 ClusDiag는 클러스터 디스크 및 네트워크 구성에 대한 텍스트 기반 및 그래픽 보고서를 만들 수 있을 뿐만 아니라 클러스터 리소스 종속성 트리의 그래픽 보기를 생성할 수 있습니다.

클러스터 진단 및 확인 도구(ClusDiag.exe)(Cluster Diagnostics and Verification Tool (ClusDiag.exe))에서 Clusdiag를 다운로드할 수 있습니다.

신고
  왜 Windows Ent와 SQL Server Std/Ent를 구입하고 클러스터를 구성 하지 않을까? 
작성일시 : 2008.01.28 22:58 | 분류 : SQL Server/Administration | 태그 : Migration, mscs, SQL Server

왜 Windows Ent와 SQL Server Std/Ent를 구입하고 클러스터를 구성 하지 않을까?

한가지 Tip을 알려드립니다.

원래 MSCS 구성은 두 노드간의 H/W이 완벽하게 같아야 함을 원칙으로 하지만 실제 구성해보면 차이가 있더라도 구성이 가능합니다. (Fail over 까지 가능) 자 그렇다면 Migration 할때 간단하게 업그래이드된 서버를 노드로 추가 하고 Fail over 한 이후 이전 노드를 지워 주면 됩니다. 또한 서버의 PM 작업이 필요할 경우 (보안 패치 설치 및 기타 Down Time이 필요) 노드 추가 후 서비스를 fail over 시키고 작업 종료 후 다시 fail over 시킨 후 기존 node를 삭제하면 됩니다.

[선행 조건]
- 동일 CPU 기반 (x86, x64, ia64)
- SAN 환경
신고
 Prev   1   Next 

티스토리 툴바