SQL Server 2005까지는 SQL Server 클러스터에 Service Pack을 설치할 때 반드시 Active Node(현재 SQL Server 리소스가 온라인되어 있는 노드)에서 Service Pack 설치 프로그램을 실행해야만 하며, Active Node에서 한번만 Service Pack 설치 프로그램을 실행해 주면 Passive Node에도 원격설치(Remote Setup)가 자동적으로 실행되기 때문에 Passive Node에서 별도로 Service Pack을 설치해 줄 필요가 없었습니다.
SQL Server 2008에서는 클러스터 환경에서 더 이상 원격설치(Remote Setup)이 지원되지 않기 때문에 신규 설치시 각각의 노드에서 설치 작업을 별도로 진행해 주었던 것처럼 Service Pack 설치시에도 각각의 노드에서 별도로 Service Pack 설치 작업을 수행해 주어야 합니다. 어떻게 보면 SQL Server 2000/2005에 비해서 더 불편해 진 것처럼 보일 수도 있으나, SQL Server 2008에서는 Rolling Update가 지원되기 때문에 Service Pack 설치 작업이 훨씬 효율적으로 바뀌었습니다.
SQL Server 2008 클러스터 환경에서 제공되는 Rolling Update는 Service Pack 설치시 오랫동안 SQL Server 서비스가 Offline되는 문제점을 해결해 줍니다. SQL Server 2008에서는 Passive Node(현재 SQL Server 리소스가 온라인되어 있지 않은 노드)에서 Service Pack 설치 작업을 진행할 수 있으며 이를 통해 SQL Server 서비스가 Offline되는 시간을 최소화하면서 업데이트 작업을 완료할 수 있습니다(이를 Rolling Update라고 합니다). Rolling Update 작업은 Passive Node에서 Service Pack 설치, Active Node에서 Passive Node로의 그룹이동(Failover), 나머지 Passive Node(기존의 Active Node)에서 Service Pack 설치의 순서로 작업이 이루어 지며 SQL Server는 그룹이동이 발생하는 짧은 시간 동안만 Offline 상태가 됩니다.
SQL Server 2008에서는 Rolling Update를 위해 SQL Server 2005에 비해서 달라진 점이 두 가지가 있습니다. 첫째는, 시스템 개체들(System Objects)에 대한 정보를 포함하고 있는 리소스 데이터베이스(mssqlsystemresource)가 SQL Server 2005에서는 공유 디스크(<drive>:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data)에 존재했던 반면에 SQL Server 2008에서는 로컬 디스크(<drive>:\Program Files\Microsoft SQL Server\MSSQL10.<instance_name>\MSSQL\Binn)에 존재한다는 것입니다. 둘째는, SQL Server 2005에서는 Service Pack 설치 마지막 단계에서 수행되던 업그레이드 스크립트 실행 작업이 SQL Server 2008에서는 Service Pack 설치 과정에서 실행되지 않고 나중에 업데이트된 노드에서 SQL Server가 처음으로 시작될 때 실행된다는 것입니다. 이 두 가지 변화는 Service Pack 설치 작업을 반드시 Active Node에서 해야 하는 제약 조건을 제거함으로써 Rolling Update를 가능하게 하였습니다.
물론 SQL Server 2008 클러스터 환경에서도 기존처럼 Active Node에서 Service Pack 설치 작업을 진행할 수는 있습니다. 하지만, Service Pack 설치 과정에서 SQL Server 서비스가 오랫동안 Offline(바이너리 파일들을 대체하기 위해서)될 뿐이고 어차피 Passive Node에는 별도로 Service Pack 설치 작업을 해 주어야 하기 때문에 얻을 수 있는 이점이 하나도 없습니다. Active Node에서 Service Pack 설치 프로그램을 실행하면 다음과 같이 설치 규칙 검사 단계에서 친절하게도 경고를 표시해 줍니다. '로컬 컴퓨터에서 소유한 클러스터 그룹'과 '클러스터 리소스 DLL 업데이트 다시 시작 검사'의 두 가지 규칙에 대해서 경고가 표시되는데 이는 Passive Node에서 Service Pack 설치 프로그램을 실행했을 때에는 발생하지 않는 경고입니다. 즉, Active Node에서는 Service Pack 설치 프로그램을 실행하지 말라는 경고성 메시지인 것입니다.
참고적으로 '로컬 컴퓨터에서 소유한 클러스터 그룹'과 '클러스터 리소스 DLL 업데이트 다시 시작 검사'의 두 가지 규칙에 대한 경고의 상세 내용은 다음과 같습니다.
그럼 이제부터 SQL Server 2008 2-node Active/Passive 클러스터(Windows Server 2008 클러스터)에 SQL Server 2008 Service Pack 1을 Rolling Update하는 방법에 대해서 자세히 살펴 보도록 하겠습니다.
1. 관리 도구에서 '장애 조치(Failover) 클러스터 관리'를 실행한 다음 다음과 같이 SQL Server의 네트워크 이름(Network Name) 리소스를 마우스 우측 버튼으로 클릭하고 '속성(R)'을 클릭합니다.
2. 다음의 SQL Server 네트워크 이름 리소스의 속성 창에서 '고급 정책' 탭을 클릭합니다.
3. '가능한 소유자(P)' 항목 값을 보면 다음과 같이 두 대의 노드(node1, node2)가 모두 선택되어 있음을 확인할 수 있습니다.
4. 다음과 같이 '가능한 소유자(P)' 항목에서 SQL Server 2008 Service Pack 1을 먼저 설치할 Passive Node(현재 SQL Server 리소스가 online되어 있지 않은 노드)의 선택을 해제하고 '확인'을 클릭합니다. 이렇게 하는 이유는 Passive Node에 Service Pack이 설치되는 중에 Passive Node로의 그룹 이동(Failover)이 되지 못하도록 하기 위한 것으로 만일의 사태에 대비하기 위한 조치입니다. SQL Server 2008에서는 'SQL Server 네트워크 이름' 리소스에 대한 가능한 소유자로 지정된 노드로만 그룹 이동(Failover)이 수행될 수 있습니다(반면에 SQL Server 2005에서는 'SQL Server' 리소스에 대한 가능한 소유자로 지정된 노드로만 그룹 이동이 수행될 수 있었습니다).
5. Passive Node(node2)에서 SQL Server 2008 Service Pack 1을 설치합니다. Passive Node에서 설치 작업이 진행되는 동안 Active Node(node1)에는 아무런 영향이 미치지 않으므로 Active Node에서 SQL Server는 정상적으로 계속 서비스됩니다.
6. Passive Node(node2)에서 Service Pack 설치 작업이 완료되면 '장애 조치(Failover) 클러스터 관리'를 실행하고 다음과 같이 SQL Server 네트워크 이름 리소스를 마우스 우측 버튼으로 클릭한 다음 '속성(R)'을 클릭합니다.
7. 다음의 SQL Server 네트워크 이름 리소스의 속성 창에서 '고급 정책' 탭을 클릭합니다.
8. '가능한 소유자(P)' 항목 값을 보면 다음과 같이 Active Node(node1)만이 선택된 상태임을 확인할 수 있습니다.
9. 다음과 같이 '가능한 소유자(P)' 항목에서 SQL Server 2008 Service Pack 1이 설치된 Passive Node(node2)를 다시 선택하고 '확인'을 클릭합니다. 이렇게 하는 이유는 Passive Node로 그룹 이동(Failover)가 다시 가능하도록 하기 위한 것입니다.
10. '장애 조치(Failover) 클러스터 관리'에서 다음과 같이 '서비스 및 응용 프로그램' 아래의 SQL Server 그룹명을 마우스 우측 버튼으로 클릭하고 '이 서비스 또는 응용 프로그램을 다른 노드로 이동(O)' - '1(1) - node2 노드로 이동'을 차례로 선택하여 SQL Server 그룹을 Passive Node(node2)로 그룹 이동합니다.
11. 그룹 이동 작업 확인 창에서 다음과 같이 첫 번째 항목을 클릭하여 그룹 이동 작업을 진행합니다.
12. 그룹 이동 작업이 완료되면 다음과 같이 SQL Server 그룹의 '현재 소유자'가 node2로 변경되며 이 시점에서 SQL Server는 Service Pack 1이 적용된 상태로 서비스가 됩니다. 그룹 이동으로 인해 node2에서 SQL Server가 시작되는 과정에 업그레이드 스크립트 실행 작업이 자동적으로 수행됩니다.
13. 나머지 노드(이전에 Active Node였던 node1)에 Service Pack 1을 설치하기 위한 준비 작업을 위해 다음과 같이 SQL Server 네트워크 이름 리소스의 '속성(R)'을 클릭합니다.
14. 다음의 SQL Server 네트워크 이름 리소스의 속성 창에서 '고급 정책' 탭을 클릭합니다.
15. '가능한 소유자(P)' 항목 값을 보면 다음과 같이 두 대의 노드(node1, node2)가 모두 선택되어 있음을 확인할 수 있습니다.
16. 이번에는 다음과 같이 '가능한 소유자(P)' 항목에서 이전에 Active Node였다가 현재는 Passive Node인 node1의 선택을 해제하고 '확인'을 클릭합니다. 이렇게 하는 이유는 Passive Node에 Service Pack이 설치되는 중에 Passive Node로의 그룹 이동(Failover)이 되지 못하도록 하기 위한 것으로 만일의 사태에 대비하기 위한 조치입니다.
17. Passive Node(node1)에서 SQL Server 2008 Service Pack 1을 설치합니다. Passive Node에서 설치 작업이 진행되는 동안 Active Node(node2)에는 아무런 영향이 미치지 않으므로 Active Node에서 SQL Server는 정상적으로 계속 서비스됩니다. node1에서의 Service Pack 설치 작업이 완료됨으로써 SQL Sever 2008 클러스터에 대한 Service Pack 1 설치 작업은 모두 완료되었습니다.
18. SQL Server 네트워크 이름 리소스에 대한 '가능한 소유자' 설정 값을 원상태로 복구하기 위해 '장애 조치(Failover) 클러스터 관리'를 실행하고 다음과 같이 SQL Server 네트워크 이름 리소스를 마우스 우측 버튼으로 클릭한 다음 '속성(R)'을 클릭합니다.
19. 다음의 SQL Server 네트워크 이름 리소스의 속성 창에서 '고급 정책' 탭을 클릭합니다.
20. '가능한 소유자(P)' 항목 값을 보면 다음과 같이 Active Node(node2)만이 선택된 상태임을 확인할 수 있습니다.
21. 다음과 같이 '가능한 소유자(P)' 항목에서 현재 Passive Node인 node1을 다시 선택하여 모든 노드가 선택되도록 하고 확인을 클릭합니다. 이로써 SQL Server 2008 클러스터에 Service Pack을 Rolling Update하는 작업이 모두 완료되었습니다.
22. 모든 노드에 Service Pack 1이 적용된 후 검증 차원에서 그룹 이동 테스트를 통해 정상적으로 동작하는지 여부를 확인해 봅니다(이는 권장 사항으로 반드시 해야 하는 작업은 아닙니다). 다음과 같이 '장애 조치(Failover) 클러스터 관리'에서 '서비스 및 응용 프로그램' 아래의 SQL Server 그룹명을 마우스 우측 버튼으로 클릭하고 '이 서비스 또는 응용 프로그램을 다른 노드로 이동(O)' - '1(1) - node1 노드로 이동'을 차례로 선택하여 SQL Server 그룹을 Passive Node(node1)로 그룹 이동합니다.
23. 그룹 이동 작업 확인 창에서 다음과 같이 첫 번째 항목을 클릭하여 그룹 이동 작업을 진행합니다.
24. 다음과 같이 그룹 이동 작업이 정상적으로 완료되어 모든 리소스가 온라인 상태가 되면 테스트 작업이 성공적으로 완료된 것입니다. 이로써 두 노드에서 모두 SQL Server 2008 Service Pack 1이 적용된 버전이 정상적으로 동작함이 확인되었습니다.
SQL Server 2008 클러스터에 Service Pack 1을 Rolling Update할 때 업그레이드 스크립트는 업데이트된 노드에서 SQL Server가 처음으로 시작될 때 실행된다고 했습니다. 그럼 실제로 업그레이드 스크립트가 실행되었다는 것을 확인해 볼 수 있는 방법은 없을까요? SQL Server의 로그 파일인 ErrorLog로부터 그 해답을 찾을 수 있습니다. Serivce Pack 1이 설치된 노드에서 처음으로 SQL Server가 시작될 때 다음과 같은 메시지들이 ErrorLog에 기록되는 것을 확인해 볼 수 있는데 이를 통해 업그레이드 스크립트가 실행되었음을 알 수 있습니다.
2010-04-26 18:54:33.09 Server Microsoft SQL Server 2008 (SP1) - 10.0.2531.0 (Intel X86)
Mar 29 2009 10:27:29
Copyright (c) 1988-2008 Microsoft Corporation
Enterprise Edition on Windows NT 6.0 <X86> (Build 6002: Service Pack 2) (VM)
...
2010-04-26 18:54:41.75 spid7s Starting up database 'mssqlsystemresource'.
2010-04-26 18:54:41.87 spid7s The resource database build version is 10.00.2531. This is an informational message only. No user action is required.
...
2010-04-26 18:54:43.29 spid7s The NETBIOS name of the local node that is running the server is 'NODE2'. This is an informational message only. No user action is required.
...
2010-04-26 18:54:51.50 spid7s Starting up database 'msdb'.
2010-04-26 18:54:54.44 spid7s 데이터베이스 'master'이(가) 스크립트 'msdb_upgrade_discovery.sql'의 수준 167773760을(를) 수준 167774691(으)로 업그레이드하고 있습니다.
...
2010-04-26 18:54:59.63 spid7s 데이터베이스 'master'이(가) 스크립트 'sqlagent100_msdb_upgrade.sql'의 수준 0을(를) 수준 2(으)로 업그레이드하고 있습니다.
2010-04-26 18:54:59.86 spid7s ----------------------------------------
2010-04-26 18:54:59.86 spid7s Starting execution of PREINSTMSDB100.SQL
2010-04-26 18:54:59.86 spid7s ----------------------------------------
...
2010-04-26 18:55:06.77 spid7s ----------------------------------------
2010-04-26 18:55:06.77 spid7s Execution of PREINSTMSDB100.SQL complete
2010-04-26 18:55:06.77 spid7s ----------------------------------------
2010-04-26 18:55:06.77 spid7s ----------------------------------
2010-04-26 18:55:06.77 spid7s Starting execution of INSTMSDB.SQL
2010-04-26 18:55:06.77 spid7s ----------------------------------
...
2010-04-26 18:55:42.06 spid7s ----------------------------------
2010-04-26 18:55:42.06 spid7s Execution of INSTMSDB.SQL complete
2010-04-26 18:55:42.06 spid7s ----------------------------------
...
2010-04-26 18:55:44.34 spid7s -----------------------------------------
2010-04-26 18:55:44.34 spid7s Execution of POSTINSTMSDB100.SQL complete
2010-04-26 18:55:44.34 spid7s -----------------------------------------
...
2010-04-26 18:55:44.35 spid7s Upgrading Database Mail related objects...
2010-04-26 18:55:44.56 spid7s Completed upgrade of Database Mail related objects...
...
2010-04-26 18:55:44.84 spid7s Executing replication upgrade scripts.
2010-04-26 18:55:44.84 spid7s Executing sp_vupgrade_replication.
...
2010-04-26 18:55:45.30 spid7s sp_vupgrade_replication executed successfully
2010-04-26 18:55:45.30 spid7s Saving upgrade script status to 'SOFTWARE\Microsoft\MSSQLServer\Replication\Setup'.
2010-04-26 18:55:45.33 spid7s Saved upgrade script status successfully.
2010-04-26 18:55:45.34 spid7s Recovery is complete. This is an informational message only. No user action is required.
'SQL Server 이야기' 카테고리의 다른 글
| SQL Server 2005/2008에서 작업 진행률을 확인하는 방법 (0) | 2010.06.20 |
|---|---|
| SQL Server 클러스터 리소스의 상태 체크(LooksAlive/IsAlive Check) 방식 (0) | 2010.05.05 |
| SQL Server 2008 업데이트(서비스 팩 포함) 제거 방법 (0) | 2010.04.25 |
| SQL Server 2008 업데이트 통합 설치(Slipstream Setup) (0) | 2010.04.25 |
| SQL Server 2005/2008 Procedure Cache에 대한 이해 (0) | 2010.04.08 |