류짱:Beyond MySelf

Windows Server 2012R2 hyper-v cluster에서 사용 중인 CSV 볼륨에 Cache를 사용 하는 방법을 정리 해 보았습니다.


[
설정 방법]

Windows Server 2012R2에서는 BlockCacheSize가  Default Enable 되어 있지만

Size Zero 설정 되어 있기 때문에 Cache 사이즈는 아래 명령어를 통해서 설정 해줘야 합니다.

 

Windows 2012R2 경우 Cachesize 물리적 메모리의 최대 80%설정 가능합니다만 권장은 512MB 입니다.

 

 

 

설정 cache size 모니터링 하기위해서는 성능 모니터를 실행 아래 항목을 확인 하면 되지만
해당 볼륨의 offline online 실행 적용 가능하며 한 번 적용이 된 후 부터는 변경 할 경우 실시간으로 변경 됩니다.

 

 

 

 

CSV 볼륨의 디스크를 오프라이인으로 변경 후 다시 온라인 한 후 부터 아래와 같이 캐시 사이즈를 변경하면 실시간으로 해당 캐시 사이즈가 적용 됨을 확인 할 수 있습니다.
 

감사합니다.

 

[참고자료]

How to Enable CSV Cache
http://blogs.msdn.com/b/clustering/archive/2013/07/19/10286676.aspx


 

 

저작자 표시 비영리 변경 금지
신고

Comment 0

Windows server 2012 Hyper-V를 이용해서 SQL Server 2012 Failover Clustering 설치 하기#6- SQL 추가노드

 

 

 

 

이제 SQL 2012의 Failover Clustering 설치가 마무리 되었습니다.

클러스터 관리자를 실행 하면 Roles에서 SQL 그룹을 확인 할 수 있습니다.



감사합니다.

[참고 자료]
Add or Remove Nodes in a SQL Server Failover Cluster (Setup)
http://msdn.microsoft.com/en-us/library/ms191545.aspx

저작자 표시 비영리 변경 금지
신고

Comment 0

Windows server 2012 Hyper-V를 이용해서 SQL Server 2012 Failover Clustering 설치 하기#5- SQL

[SQL Server 구성 정보]

 * SQL 네트워크 이름 : sql2012
 * SQL IP : 192.168.1.25
 * SQL 레터 : F


SQL 설치 CD를 1번 노드에 삽입 후 실행 후 설치 설치 => New SQL Failover Cluster installation을 선택 한후 설치를 진행합니다

 

 

 

 

 

 

 

 

 

 

[참고 자료]
새 SQL Server 장애 조치(Failover) 클러스터 만들기(설치)
http://msdn.microsoft.com/ko-kr/library/ms179530.aspx

저작자 표시 비영리 변경 금지
신고

Comment 0

Windows server 2012 Hyper-V를 이용해서 SQL Server 2012 Failover Clustering 설치 하기#4 - MSDTC

이번엔 지난번에 이어 MSDTC를 구성 해 보도록 하겠습니다.

[MSDTC 구성 정보]

 * MSDTC 이름 : sql2012DTC
 * DTC  IP : 192.168.1.24
 * DTC 레터 : M

클러스터를 실행 후 configrue role을 선택 합니다.

다음을 클릭합니다.

DCT를 선택 한 후 다음을 클릭합니다.

DTC 정보를 입력합니다.

DTC용 디스크를 선택합니다.

구성을 다시 한번 확인 한 후 다음을 클릭합니다.

DTC 설치가 완료 되었습니다.

다음으로 설치 된 DTC의 설정을 변경합니다.
서버 관리자를 실행 후 Too => Component Services를 선택합니다.

Component Services를 실행 후 아래와 같이 DTC에서 SQL2012DTC를 오른쪽 마우스로 선택 한 후 등록정보를 실행합니다.

보안탭에서 설정을 아래와 같이 변경한 후 적용을 클릭합니다.

경고 메시지가 팝업되면 확인을 클릭 하면 DTC가 자동 재 시작이 되고 클러스터 관리자에서 DTC가 정상적으로 실행이 됨을 확인 할 수 있습니다.

이제 SQL2012 failover clustering을 위한 준비가 다 끝났습니다. 다음 포스팅에서는 본격적으로 SQL 2012를 설채 해 보도록 하겠습니다.

감사합니다.

저작자 표시 비영리 변경 금지
신고

Comment 0

Windows server 2012 Hyper-V를 이용해서 SQL Server 2012 Failover Clustering 설치 하기#3 -Cluster 구성

정말 오랜만에 업데이트를 합니다.^^

양쪽 노드에 디스크 할당이 모두 끝났으므로 이번에는 서버 관리자를 통해서 클러스터 기능을 추가한 후 쿼럼 디스크를 설정 하도록 하겠습니다.
디스크 할당 과정은 생략합니다. (2008클러스터 구성시 이미 다 했기 때문에...)

양쪽 노드에 쿼림, MSDTC, SQL용 디스크가 제대로 할당 되었다는 가정 하에 먼저 클러스터를 구성하도록 하겠습니다.

서버 관리자를 실행 한 후 .netframework3.5(SQL 설치를 위해 반드시 필요) 와 failoverclustering 기능을 추가 합니다.
만약 기능 설치 중 .netframework3.5의 설치가 실패된다면 아래 포스팅을 참고하여 문제를 해결 하시면 됩니다.
Windows server 2012에 .Net Framework 3.5 실패
http://ryuchan.kr/484

[클러스터 구성 정보]

 * 클러스터 이름 : sql2012clu
 * 클러스터 IP : 192.168.1.22
 * 클러스터 쿼럼 레터 : Q



.netframework 3.5와 Failover clustering의 설치가 완료 되면 서버 관리자를 실행 후 클러스터 관리자를 실행 합니다.

클러스터관리자를 실해 클러스터 구성 전 유효성 검사를 진행 합니다.

 

유효성검사가 완료되면 아래와 같이 create the cluster now를 선택 한 클러스터 설치를 진행합니다.

클러스터 설치가 완료되면 쿼럼 디스크를 구성 합니다.

 

 

 

이제 클러스터 설치가 완료 되었습니다.
다음에는 SQL 서버를 위한 MSDTC를 구성 해 보도록 하겠습니다.

[참고 자료]
How to configure two node Windows Server 2012 cluster on Virtual Machines for testing?
http://blogs.technet.com/b/babulalghule/archive/2013/02/16/how-to-configure-two-node-windows-server-2012-cluster-on-virtual-machines-for-testing.aspx


 

 

저작자 표시 비영리 변경 금지
신고

Comment 0

지난 포스팅에 이어 이번에는 DC 서버에 설치 된 iSCSI Target 서버에 클러스터용 가상 디스크를 추가하고 해당 디스크를 각 노드에 연결 방법을 알아 보도록 하겠습니다.

먼저 iSCSI 타겟 서버의 서버 관리자에서 로컬 서버를 선택 후 File and Storage Services를 선택 한 합니다.

File and Storage Services 관리자 화면에서 iSCSI를 선택 한 후 오른쪽 Task를 클릭하여 "New iSCSI Virtual Disk를 선택 합니다.

New iSCSI Virtual Disk 마법사가 시작 되면 아래 그림에서 처럼 미리 설정 된  iSCSI 타겟용 디스크인 E 드라이브를 선택한 후 Next를 클릭 합니다.

먼저 SQLData용 디스크를 만들기 위해 name에 SQLData를 입력 한 후 next를 클릭합니다.
 


사이즈를 20G정도로 할당합니다.

iSCSI 타켓을 새로 만들기 위해 New iSCSI target을 선택합니다.

타겟 이름에 SQLData를 입력 한 후 다음을 클릭 합니다.

해당 타켓서버를 사용할 노드를 지정합니다. SQL2012-node01과 SQL2012-node02  두 노드를 추가 합니다.
아래 그림에서는 1번 노드만 추가 하는 방법을 설명 하였으니 2번 노드는 1번 노드를 추가 한 후 다시 동일하게 작업을 하시면 됩니다. 

타켓 서버와 해당 타겟 서버를 바라보는 노드가 모두 지정이 되었으면 아래 그림에서 Create 클릭하여 클러스터 노드용  iSCSI Virtual Disk를 생성 합니다.

 SQL2012-node01로 이동하여 iSCSI initiator를 찾은 후 실행 합니다.

 

  iSCSI initiator 관리 화면이 시작 되면 Discovery를 선택 한 후 타겟 서버의 IP를 입력 합니다.

 타겟 서버 IP 입력 후 Target 탭으로 이동하여 Refresh를 클릭하면 아래와 같이 타겟 서버에서 설정 한 Target에 연결이 됩니다. 그러나 아직 Active를 하지 않았기 때문에 상태는 Inactive 입니다. Connec를 눌러 연결을 활성화 합니다.

 

 

 나머지 다른 디스크용 타겟들도 전부 연결이 되면 아래와 같이 모든 Targete들의 상태가 Connected로 보입니다.

 

저작자 표시 비영리 변경 금지
신고

Comment 0

Windows server 2012 Hyper-V를 이용해서 SQL Server 2012 Failover Clustering 설치 하기 - 1

[사전 구성]

가상 머신 3대 생성
 1. DC & ISCSI Target & Storage Server
    IP : 192.168.100.1
    Domain Name: ryuchan2012.kr
 2. Node1
    IP : 192.168.100. 10
    Host Name : SQL2012-node01
 3. Node2
    IP : 192.168.100. 11
    Host Name : SQL2012-node01

[설치 순서]
1 .Domain controller
서버에  ISCSI Target 설치

 1-1 . DC에 로그온 후 서버 관리자를 실행 한 후 "Add roles and feature"를 클릭 합니다.

 1-2. 역할 및 기능 추가 화면에서 "Role-based or Feature-based installation을 선택 합니다.

 

 1-3. 서버를 선택하는 화면에서 DC를 선택 합니다.

1-4. 서버 롤 선택화면에서 File and Storage Service => File and iSCSI Services => iSCSI Target Server를
선택 한 후 Next를 클릭합니다.
** iSCSI Target Server를 선택 할 경우 File server도 자동으로 선택 됩니다.


1-5. File server와 iSCSI Tareget 서버를 설치합니다.

2. Active Directory domain service 구성

Windows Server 2012의 경우 이전 버전의 서버들과 달리 AD 설치를 위해 DCPromo 명령어를 사용할 수 업습니다. 물론 unattand File을 이용한 무인 설치를 해야 할 경우나 AD를 강제 제거 해야 할 경우에는 사용 할 수 있습니다만 일반적인 환경에서 dcpromo 명령어를 실행 할 경우 아래와 같은 오류가 발생하기 때문에 서버 관리자를 통해서 AD를 설치 해야만 합니다.

 

2-1. 서버 관리에서 Active Directory Domain Services 역할을  설치합니다. 역할 설치 후 시스템을 재 시작 한 후 서버 관리자를 실행하면 아래와 같이 경고메시지를 확인 할 수 있습니다. 경고 메시지클릭 하면 해당 머신을 도메인 컨트롤러로 Promote 할 수 있습니다.
 

 

 

 


저작자 표시 비영리 변경 금지
신고

Comment 0

[환 경]
MSSQL Server 2008 on Windows Server 2008 x86 ENT + SP2

[증상]
15분 주기로 FailoverClustering Event ID 1207 발생

로그 이름:         System
원본:            Microsoft-Windows-FailoverClustering
날짜:            2012-03-06 오후 4:58:45
이벤트 ID:        1207
작업 범주:         네트워크 이름 리소스
수준:            오류
키워드:          
사용자:           SYSTEM
컴퓨터:           w2k8-node1.ryuchan.kr
설명:
클러스터 네트워크 이름 리소스 '%1'을(를) 온라인 상태로 만들 수 없습니다. 다음과 같은 이유로 '%2' 도메인에서 리소스와 연결된 컴퓨터 개체를 업데이트하지 못했습니다.
%3.

관련 오류 코드는 %4입니다.
 
클러스터 ID '%5'에 개체를 업데이트하는 데 필요한 권한이 부족할 수 있습니다. 도메인 관리자와 함께 클러스터 ID가 도메인의 컴퓨터 개체를 업데이트할 수 있는지 확인하십시오

 


[원 인]
Cluster 에서 만든 CNO, VCO는 그룹 정책에 정해진 주기로 패스워드를 변경하는데 패스 워드 변경이 실패할 경우 15분 주기로 재 시도를 하게 됩니다.

 

[조치 방법]
이벤트에서 확인 된 VCO를 도메인 컨트롤러에서 찾은 후 해당 VCO의 속성 => 보안 탭을 선택 후 CNO 즉 클러스터 계정에 대해 Full 권한을 부여 합니다.

[참고 자료]
Recovering a Deleted Cluster Name Object (CNO) in a Windows Server 2008 Failover Cluster|
http://blogs.technet.com/b/askcore/archive/2009/04/27/recovering-a-deleted-cluster-name-object-cno-in-a-windows-server-2008-failover-cluster.aspx

Description of the failover cluster security model in Windows Server 2008
http://support.microsoft.com/kb/947049/en-us

 감사합니다.

 

저작자 표시 비영리 변경 금지
신고

Comment 0

 

Windows Server 2008 Failover Cluster networking features

A new cluster network driver architecture
The ability to locate cluster nodes on different, routed networks in support of multi-site clusters
Support for DHCP assigned IP addresses
Improvements to the cluster health monitoring (heartbeat) mechanism
Support for IPv6

New cluster network driver architecture
The legacy cluster network driver (clusnet.sys) has been replaced with a new NDIS level driver called the Microsoft Failover Cluster Virtual Adapter (netft.sys)

The goal of the new driver model is to sustain TCP/IP connectivity between two or more systems despite the failure of any component in the network path. This goal can be achieved provided at least one alternate physical path is available. In other words, a network component failure (NIC, router, switch, hub, etc…) should not cause inter-node cluster communications to break down, and communication should continue making progress in a timely manner (i.e. it may have a slower response but it will still exist) as long as an alternate physical route (link) is still available.

 If cluster communications cannot proceed on one network, the switchover to another cluster-enabled network is automatic. This is one of the primary reasons that each cluster node must have multiple network adapters available to support cluster communications and each one should be connected to different switches.

The failover cluster virtual adapter is implemented as an NDIS miniport adapter that pairs an internally constructed virtual route with each network found in a cluster node. The physical network adapters are exposed at the IP layer on each node. The NETFT driver transfers packets (cluster communications) on the virtual adapter by tunneling through the best available route in its internal routing table

the default port for cluster communication is still TCP\UDP: 3343.

When the cluster service starts, and a node either Forms or Joins a cluster, NETFT, along with other components, is responsible for determining the node’s network configuration and connectivity with other nodes in the cluster. One of the first actions is establishing connectivity with the Microsoft Failover Cluster Virtual Adapter on all nodes in the cluster.

Beginning with Windows Server 2008 failover clustering, individual cluster nodes can be located on separate, routed networks. This requires that resources that depend on IP Address resources (i.e. Network Name resources), implement an OR logic since it is unlikely that every cluster node will have a direct local connection to every network the cluster is aware of. This facilitates IP Address and hence Network Name resources coming online when services\applications failover to remote nodes. Here is an example (Figure 10) of the dependencies for the cluster name on a machine connected to two different networks.

All IP addresses associated with a Network Name resource, which come online, will be dynamically registered in DNS (if configured for dynamic updates). This is the default behavior. If the preferred behavior is to register all IP addresses that a Network Name depends on, then a private property of the Network Name resource must be modified. This private property is called RegisterAllProvidersIP (Figure 11). If this property is set equal to 1, all IP addresses will be registered in DNS and the DNS server will return the list of IP addresses associated with the A-Record to the client.

Since cluster nodes can be located on different, routed networks, and the communication mechanisms have been changed to use reliable session protocols implemented over UDP (unicast), the networking requirements for Geographically Dispersed (Multi-Site) Clusters have changed. In previous versions of Microsoft clustering, all cluster nodes had to be located on the same network. This required ‘stretched’ VLANs be implemented when configuring multi-site clusters. Beginning with Windows Server 2008, this requirement is no longer necessary in all scenarios.

Improvements to the cluster ‘heartbeat’ mechanism

The cluster ‘heartbeat’, or health checking mechanism, has changed in Windows Server 2008. While still using port 3343, it is no longer a broadcast communication It is now unicast in nature and uses a Request-Reply type process. This provides for higher security and more reliable packet accountability.

The default configuration (shown here) means the cluster service will wait 5.0 seconds before considering a cluster node to be unreachable and have to regroup to update the view of the cluster (One heartbeat sent every second for five seconds). The limits on these settings are shown in Figure 17. Make changes to the appropriate settings depending on the scenario. The CrossSubnetDelay and CrossSubnetThreshold settings are typically used in multi-site scenarios where WAN links may exhibit higher than normal latency.

These settings allow for the heartbeat mechanism to be more ‘tolerant’ of networking delays. Modifying these settings, while a worthwhile test as part of a troubleshooting procedure (discussed later), should not be used as a substitute for identifying and correcting network connection delays.

저작자 표시 비영리 변경 금지
신고

Comment 0

최근 Windows Server 2003클러스터의 로그 분석 문의가 부쩍 많아졌습니다. 클러스터 로그 생성 과정과 로그 분석시 참고 할 만한 사이트를 정리 해 봅니다.

[
클러스트 에러 메시지 확인 방법
]
명령 프롬프트에서 아래 명령어를 실행 하면 에러 코드의 확인이 가능 합니다
.

net helpmsg [error_number]

C:\Users\Administrator>net helpmsg 32
The process cannot access the file because it is being used by another process.

[Log Summary of Cluster Formation]
When the Cluster service forms a cluster, it does the following:

1. Starts the Resource Monitor, the manager of the cluster's resources.
2. Brings the Quorum resource online.
3. Updates local copies of the cluster database.
4. Recreates groups and resources.
5. Configures the networks, recreates network and interface objects, registers the networks and interfaces with cluster transport, and then brings them online.
6. Brings all resources online.
7. Takes a checkpoint of the cluster database.
9. And the cluster is formed. Resources continue to be brought online after the cluster formation is reported complete.


Forming a Cluster
Forming a cluster involves the following stages:

1. Starting an instance of the Resource Monitor (Resrcmon.exe).
2. Bringing the Quorum resource online, including the following:
3. Applying the quorum log changes to the cluster database.
4. Recreating groups and resources in the cluster database
5. The Cluster service might have used stale object information at startup; now it needs to destroy and then recreate all the group and resource objects in order to refresh their information.
6. Configuring the networks.
7. Bringing resources online, which might involve updating resources' registry keys.
8. The cluster can be successfully formed before all the resources have been brought online.

Initializing the Node
The following entries represent initialization of the local node.

378.32c::1999/06/09-18:00:18.874 Cluster Service started - Cluster Node
Version 3.2051
378.32c::1999/06/09-18:00:18.874 OS Version
5.0.2051
Note that the preceding entries include, with the time the Cluster service started, the version number of the Cluster service and of the node's operating system.

378.380::1999/06/09-18:00:18.874 [CS] Service Starting...
378.380::1999/06/09-18:00:19.210 [EP] Initialization...
378.380::1999/06/09-18:00:19.218 [DM]: Initialization
378.380::1999/06/09-18:00:19.226 [DM]: Loading cluster database from
C:\WINNT\cluster\CLUSDB
In the preceding entry, the Database Manager loads the cluster database into the local registry. Later, the Database Manager updates the cluster's registry data with any cluster database checkpoints or quorum log change records that are more recent than the version of the cluster database that it just loaded into the cluster registry key.

378.380::1999/06/09-18:00:19.382 [DM] DmpStartFlusher: Entry
378.380::1999/06/09-18:00:19.382 [DM] DmpStartFlusher: thread created
378.380::1999/06/09-18:00:19.406 [NM] Initializing...
378.380::1999/06/09-18:00:19.429 [NM] Local node name = NODE1.
378.380::1999/06/09-18:00:19.429 [NM] Local node ID = 1.
The last two, preceding entries identify the node the name and ID of the node whose activity this log tracks. This identity is important for tracking interactions in the various nodes' cluster logs.

378.380::1999/06/09-18:00:19.429 [NM] Creating object for node 1 (NODE1)
378.380::1999/06/09-18:00:19.429 [NM] Initializing networks.
378.380::1999/06/09-18:00:19.437 [NM] Initializing network interfaces.
378.380::1999/06/09-18:00:19.609 [NM] Initialization complete.
378.380::1999/06/09-18:00:19.632 [FM] Starting worker thread...
378.3a8::1999/06/09-18:00:19.632 [FM] Worker thread running
378.380::1999/06/09-18:00:19.632 [API] Initializing
378.380::1999/06/09-18:00:19.632 [lm] :LmInitialize Entry.
378.380::1999/06/09-18:00:19.640 [lm] :TimerActInitialize Entry.
378.380::1999/06/09-18:00:19.640 [CS] Service Domain Account = ITRESKIT\administrator
378.380::1999/06/09-18:00:19.640 [CS] Initializing RPC server.
378.380::1999/06/09-18:00:19.734 [INIT] Attempting to join cluster CLUSTER1
After it is initialized, the Cluster service immediately tries to join a cluster.

[Anatomy of a Cluster Log Entry]
Cluster log abbreviations for components and node states are shown in Table 20.1.

Table 20.1 Cluster Log Abbreviations for Components and Node States

Abbreviation

Node state or component

[API]

API support. These entries come from the Cluster service component that provides support for the Server Cluster API.

[ClMsg]

Cluster messaging. The component that Regroup (also known as Membership Manager see later in this table) uses to send and receive its messages.

[ClNet]

Cluster network engine. Generic code to determine a node's network configuration.

[CP]

Checkpoint Manager. If a resource has its registry key registered for checkpointing, the Checkpoint Manager monitors any changes to the key while the resource is online and writes a checkpoint to the quorum disk whenever there is a change to the registered key. On the node to which the resource is being failed over, the resource key in the registry is updated with the resource key's checkpoint before the resource is brought online.

[CS]

Cluster service. This abbreviation is assigned to messages that come out of the Cluster service rather than one of its components.

[DM]

Database Manager. The agent through which other components read or make changes to the cluster configuration database.

[EP]

Event Processor. Components of the Cluster service register with the Event Processor to receive internal cluster events, such as a node's going up or down.

[FM]

Failover Manager. Coordinates the moving of a group from one node to another based on failure criteria specified by the group's properties.

[GUM]

Global Update Manager. A cluster-wide, broadcast-like remote procedure call (RPC) mechanism used to distribute information to all nodes in the cluster.

[INIT]

The initial state of a node prior to joining or forming a cluster.

[JOIN]

The node state that follows [INIT] when the node attempts to join a cluster. If the join operation succeeds, the state of the node then moves to cluster member.

[LM]

Log Manager. Maintains the quorum log.

[MM]

Membership Manager, also known and written to the cluster log as Regroup ([RGP]). See [RGP] in this table.

[NM]

Node Manager. Keeps track of the state of other nodes in the cluster as well as maintaining the cluster-wide network configuration.

[OM]

Object Manager. Maintains an in-memory database of entities, or objects (nodes, networks, groups, and so on). Each object has an associated type and a set of methods with which other components can manipulate it. Each cluster object is represented in the Object Manager space. The Object Manager does not differentiate between types of objects.

[RGP]

Regroup, also known and written to the cluster log as Membership Manager ([MM]). Tracks which nodes are members of the cluster. Regroup writes entries to the log during initialization, form operations, and join operations, and when cluster membership changes.

[RM]

Resource Monitor. Any of the processes (instances of Resrcmon.exe) of the Cluster service that actually monitor individual resources.



[
참고 자료]

Interpreting the Cluster Log
http://technet.microsoft.com/en-us/library/cc961673.aspx

The meaning of state codes in the Cluster log
http://support.microsoft.com/kb/286052/en-us

Recovering from a lost or corrupted quorum log
http://support.microsoft.com/kb/245762/EN-US

Server Cluster Troubleshooting
http://technet.microsoft.com/en-us/library/cc776978(WS.10).aspx

How to Troubleshoot Cluster Service Startup Issue
http://support.microsoft.com/kb/266274/en-us

How to Use the Cluster TMP file to Replace a Damaged Clusdb File
http://support.microsoft.com/kb/224999/EN-US

감사합니다.

 

 

저작자 표시 비영리 변경 금지
신고

Comment 0