SQL Server
SQL Server의 고가용성 실현
Zach Nichter
한 눈에 보기:
- 미러링
- 데이터베이스 스냅숏
- 로그 전달
- 클러스터링
- 복제
이 기사의 코드 다운로드: NichterHA2007_03.exe (151KB)
고가용성은 모든 데이터베이스 관리자가 알아야 하는 개념으로서, 시스템의 응답성과 액세스 가능성을 의미합니다. 고가용성은 초 단위의 응답 시간을 의미하기도 하지만 밀리초 단위의
응답 시간을 의미할 수도 있습니다. SQL 쿼리의 왕복 응답 시간이 밀리초 단위로 설정된 웹 서버를 사용하고 있는 회사의 자문을 맡은 적이 있습니다. 응답 시간이 이 제한 시간을 초과할 경우 데이터베이스 시스템은 다운된 것으로 간주되고 웹 서버는 사용 가능한 다음 데이터베이스 서버에 다시 연결되었습니다.
응용 프로그램의 빠른 실행을 원하는 사용자의 경우 고가용성과 빠른 응답 시간을 실현하는 방법을 알고 있으면 데이터 종속적 응용 프로그램을 현명하게 계획하는 데 많은 도움이 됩니다.
다행히 SQL Server™ 2005에는 복제, 클러스터링, 데이터베이스 미러링, 데이터베이스 스냅숏 및 데이터베이스 로그 전달을 포함하여 가용성을 높여 주는 다양한 옵션이 있습니다. 이러한 기능을 살펴보고 사용자의 환경에 적합한 기능을 결정하는 방법에 대해 알아보겠습니다. 먼저 SQL Server 2005의 가용성 옵션을 보여 주는 그림 1을 살펴보겠습니다.
Figure 1 고가용성 옵션
| 기술 특성 | 복제 | 데이터베이스 미러링 | 클러스터링 | 데이터베이스 스냅숏 | 로그 전달 |
| 고가용성 옵션 | |||||
| 높은 트랜잭션 요구 사항 허용 | |||||
| 실시간 데이터 가용성 | |||||
| 읽기 전용인 데이터 이미지 | |||||
| 고유한 하드웨어 구성 | |||||
| 저렴한 비용 | |||||
| 데이터 복구 제공 | |||||
| 자동 장애 조치 | |||||
| 잠재적으로 복잡한 구현/관리 | |||||
| 가능한 성능 고려 사항 |
고가용성 정의
고가용성 응용 프로그램을 계획할 때 우선적인 목표로 고려해야 하는 사항 중 하나는 현재 자신이 속한 환경에서 고가용성이 의미하는 바를 정의하는 것입니다. 일부 조직의 경우 고가용성은 프로덕션 하드웨어와 동일한 예비 하드웨어가 있고, 데이터와 하드웨어 두 가지 모두의 가동 시간 및 가용성이 99.995% 이상이 되는 것을 의미합니다. 반면 데이터 자체의 고가용성만 필요로 하고 프로덕션 수준 성능을 위해서는 장애 조치만을 고려하는 조직도 있습니다. 고가용성 정의는 상황에 적합한 솔루션을 결정하는 데 중요합니다.
발생할 수 있는 가동 중단 유형을 식별하고 이러한 가동 중단이 서비스 수준 계약(SLA)에 어떤 영향을 주는지 나타내야 할 필요가 있습니다. 가용성에 영향을 줄 수 있는 가동 중단에는 계획된 중단, 계획되지 않은 중단 및 성능 저하가 포함됩니다.
계획된 중단은 일반적으로 예약된 유지 관리 시간대로, 시스템 사용자에게 미리 통보됩니다. 계획되지 않은 중단은 일반적으로 하드웨어 또는 소프트웨어 오류로 인해 발생하며 데이터에 액세스할 수 없게 됩니다. 성능 저하로 인해서도 중단이 발생할 수 있는데 성능 저하는 주로 최종 사용자 응답 시간으로 측정되며 일반적으로 기업뿐만 아니라 IT 조직에 의해 SLA 형태로 미리 계약됩니다.
가동 중단의 가능한 원인을 식별하는 것 외에도 데이터의 작업 수준을 결정하고 데이터가 항상 온라인 상태여야 하는지 니어라인 또는 오프라인 상태가 되어도 되는지를 결정해야 합니다. 가용성 옵션을 동일 지역 위치에 적용할지 또는 원격 위치에 적용할지도 결정해야 합니다. 예산의 규모 또한 결정을 내리는 데 중요한 고려 사항입니다. 이제 각 가용성 옵션을 살펴보겠습니다.
데이터베이스 미러링
데이터베이스 미러링에 대한 설명을 시작하기 전에 용어를 정의하겠습니다.
주 서버 는 미러 서버와 데이터베이스에 지속적으로 트랜잭션 로그를 보내는 데이터베이스가 설치되어 있는 주 프로덕션 서버입니다.
미러 서버 는 데이터베이스의 백업 사본이 설치되어 있는 보조 서버입니다. 미러 사본은 주 데이터베이스와 일관성 있게 동기화됩니다.
역할 은 특정 서버의 목적 즉, 해당 서버가 주 서버인지 미러 서버인지를 나타냅니다.
미러링 모니터 서버 는 역할을 수행하는 주 및 미러 서버를 모니터링하고 자동 장애 조치를 시작할 수 있는 인스턴스입니다.
파트너 서버 는 주 서버 또는 미러 서버가 될 수 있습니다.
일반적인 환경의 경우 주 데이터베이스는 주 인스턴스에 백업되고 백업은 미러 인스턴스에 복원됩니다(그림 2 참조). 데이터베이스가 복원된 후에는 SMSS(SQL Server Management Studio)에서 주 데이터베이스의 속성 창을 사용하거나 T-SQL 스크립트를 사용하여 주 서버에서 미러링을 설정해야 합니다.
Figure 2** Database mirroring architecture **(더 크게 보려면 이미지를 클릭하십시오.)
미러링이 구성되고 미러링 세션이 설정되면 주 데이터베이스와 미러링된 데이터베이스가 동기화됩니다. 그런 다음 주 데이터베이스에서 미러 서버에 마지막 백업이 적용된 이후로 발생한 이벤트에 대한 트랜잭션 로그를 보냅니다. 미러 서버에서는 로그를 수신한 후 가능한 빨리 적용하려고 시도합니다. SQL Server 2005 Enterprise Edition을 사용하는 경우에는 이 프로세스가 다중 스레드로 처리되지만 그렇지 않은 경우에는 단일 스레드로 처리됩니다. 이러한 로그가 미러 서버에 적용되면 데이터베이스는 동기화된 것으로 간주되며 미러링된 세션이 끊길 때까지 동기화된 상태로 유지됩니다.
클라이언트에서 새 트랜잭션을 실행하면 주 서버에서 주 데이터베이스에 대한 트랜잭션이 실행되면서 트랜잭션 로그 레코드가 주 데이터베이스에서 미러링된 데이터베이스의 다시 실행 로그나 로그 큐로 전달된 후 미러링된 데이터베이스에 선택되어 적용됩니다. 미러 데이터베이스에서 트랜잭션이 적용 및 커밋되면 트랜잭션이 미러 서버에서 커밋되었음을 알리는 응답이 주 서버에 전달됩니다. 주 서버는 미러 서버의 확인 응답이 수신되기 전까지는 시스템에 적용될 수 있는 새 트랜잭션을 확인하지 않습니다.
오류가 발생할 경우 미러 서버는 자동 장애 조치를 시작할 수 있으며 미러링 모니터 서버는 주 데이터베이스를 사용할 수 있는지 여부를 확인하여 이 프로세스를 지원합니다. 오류가 발생하면 현재 미러 파트너가 된 서버에서 문제를 해결해야만 해당 서버가 다시 주 파트너가 될 수 있습니다. 미러 파트너에서 문제가 해결되면 미러 파트너 서버로 되돌아가는 프로세스가 시작되고 데이터베이스가 다시 동기화됩니다. 데이터베이스가 동기화되면 미러링 세션을 다시 시작할 수 있습니다.
이 특정 미러링 모드는 트랜잭션 안정성을 설정하여 동기 트랜잭션 작업을 제공하는 안정성이 높은 모드지만 자동 장애 조치를 사용하지 않기 때문에 즉, 모든 장애 조치를 수동으로 시작하기 때문에 미러링 모니터 서버가 필요하지 않습니다. 동기 트랜잭션 작업을 제공하는 다른 종류의 미러링 모드로는 고가용성 모드가 있습니다. 이 모드에서는 트랜잭션 안정성을 설정해야 할 뿐만 아니라 오류가 발생할 경우 자동 장애 조치를 위해 미러링 모니터 서버도 사용됩니다.
미러링에 사용할 수 있는 세 번째 마지막 모드는 고성능입니다. 이 모드에서는 비동기 작업을 지원하기 위해 트랜잭션 안정성을 해제해야 합니다. 그래야 트랜잭션 레코드가 미러 서버에 기록될 때까지 기다릴 필요 없이 주 파트너에서 트랜잭션을 커밋할 수 있습니다. 고성능 모드에서는 미러링 모니터 서버를 구성할 필요가 없습니다.
미러링을 위해서는 주 서버와 미러 서버에서 동일한 에디션의 SQL Server를 사용해야 하지만 미러링 모니터 서버의 경우 다른 서버와 상관없이 SQL Server Express Edition을 사용할 수 있습니다. 또한 주 데이터베이스는 전체 복구 모드여야 합니다.
SQL Server 2005에 통합된 ADO.NET 2.0에는 데이터베이스 미러링을 지원하는 기능과 미러링된 환경에서 응용 프로그램에 대한 투명한 장애 조치를 수행할 수 있는 기능이 있습니다. 따라서 주 데이터베이스에 대한 연결을 설정할 수 없는 경우 추가 코딩 또는 구성 작업 없이도 ADO.NET 응용 프로그램에서 자동으로 장애 조치를 수행할 수 있습니다. 두 환경의 공통 사용자와 장애 조치 파트너를 연결 문자열에 지정하기만 하면 구성이 완료됩니다. 다음은 미러링된 데이터베이스 환경에 대한 장애 조치 파트너를 식별하는 ADO.NET 연결 문자열의 예입니다.
"Provider=SQLNCLI.1;Data Source=MirrorDB;Failover Partner=SQL03;
Initial Catalog=AdventureWorks;
Persist Security Info=True;User ID=TestUser; Password=TestPswd; Pooling=True;
Connect Timeout=5;Application Name=ADOMirrorTest"
회사의 응용 프로그램 및 데이터 요구 사항에 따라 데이터베이스 미러링이 좋은 선택이 될 수 있지만 최적의 성능을 얻기 위해서는 여러 가지 사항을 고려해야 합니다. 예를 들어 시스템의 트랜잭션 속도와 데이터 변경의 양을 어느 정도로 할 것인지 결정해야 합니다. 데이터베이스 미러링을 고려할 때는 대역폭과 네트워크 속도가 데이터 볼륨과 트랜잭션 처리 속도를 충분히 처리할 수 있는지 여부를 확인하는 것이 중요합니다. 또한 링크의 포화도를 고려해야 합니다. 미러 서버가 다른 지역에 있는 경우에는 링크의 포화도가 매우 중요합니다. 미러링의 정상적인 작동을 방해하는 환경 제한이 있는지 여부를 알 수 있으므로 시스템을 미리 모니터링하는 것이 중요합니다.
데이터베이스 미러링은 비용을 절감하려는 경우에 매우 좋은 선택이 될 수 있습니다. 실제로 데이터베이스 미러링 아키텍처에서는 공유 디스크를 사용하지 않아도 되며 환경을 운영하는 데 특별한 고급 기술이 필요하지도 않습니다. 그리고 클러스터링과는 달리 데이터베이스 미러링에는 두 파트너가 동일한 하드웨어를 사용할 필요도 없습니다. 또한 데이터베이스 속성 창의 미러링 탭에 있는 설치 마법사를 사용하여 미러링을 쉽게 구현할 수 있습니다(그림 3 참조). 자세한 내용은 "데이터베이스 미러링 최선의 방법 및 성능 고려 사항"(go.microsoft.com/fwlink/?LinkId=80897) 백서를 참조하십시오.
Figure 3** Mirroring setup wizard **(더 크게 보려면 이미지를 클릭하십시오.)
데이터베이스 스냅숏
데이터베이스 스냅숏은 SQL Server 2005 Enterprise Edition에 포함된 새로운 기술이지만 고가용성 옵션으로 간주되지는 않습니다. 데이터베이스 스냅숏은 다른 기술과 함께 사용될 경우 복구 또는 실행 가능한 보고 옵션으로 사용됩니다. 스냅숏은 단순히 특정 시점의 읽기 전용 데이터베이스 뷰입니다.
스냅숏은 다음과 같이 CREATE DATABASE 명령을 사용하여 만듭니다.
CREATE DATABASE SnapDB_20061028_2030 ON
(NAME = SnapDB_Data, FILENAME =
'C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data\SnapDB_20061028_2030.snp')
AS SNAPSHOT OF SnapDB;
GO
데이터베이스 스냅숏이 만들어지면 일반적으로 데이터베이스에서 사용되는 데이터 파일 대신 스파스 파일이라는 하나 이상의 파일이 사용됩니다. 이러한 스파스 파일은 기본적으로 처음에는 어떠한 데이터도 갖고 있지 않는 가상 공간으로서, 원본 데이터베이스에서 데이터가 변경 또는 삭제되는 경우에만 데이터를 저장하는 데 사용됩니다. 데이터는 한 번에 한 데이터 페이지씩 스파스 파일에 기록되며 실제 데이터베이스 스냅숏에는 스냅숏이 만들어진 이후 변경된 데이터만 표시됩니다. 나머지 데이터는 원본 데이터베이스의 데이터 페이지로 구성됩니다.
데이터베이스 스냅숏 파일은 스냅숏을 만드는 시점의 데이터베이스 크기에 따라 할당됩니다. 할당된 크기를 통해 실제 저장된 데이터의 양을 파악할 수는 없습니다. 이 정보를 확인하려면 다음과 같은 T-SQL 문을 실행합니다.
SELECT *
FROM fn_virtualfilestats(DB_ID(N'SnapDB_20061028_
2030'), 1);
GO
데이터가 스파스 파일과 원본 데이터베이스에 저장되는 방법 때문에 데이터베이스 스냅숏에 액세스하면 원본 데이터베이스 데이터 파일의 데이터 페이지와 스냅숏의 스파스 파일에 있는 데이터 페이지가 검색됩니다. 데이터 페이지를 공유해야 하기 때문에 스냅숏을 만든 원본 데이터베이스가 설치된 서버에서만 스냅숏을 사용할 수 있습니다. 이 아키텍처에서는 원본 데이터베이스에 대한 I/O 부담이 완화되지 않기 때문에 데이터베이스의 실제 상태를 나타내지 못하는 스냅숏은 사용하기에 적합한 보고 옵션이 아닙니다.
데이터베이스 미러링을 스냅숏과 함께 사용하는 시나리오를 살펴보겠습니다. 이 시나리오에서는 보고 데이터, 미러 및 스냅숏 데이터베이스를 주 데이터베이스와 물리적으로 분리할 수 있습니다. 데이터베이스 스냅숏은 SQL Server 에이전트와 사용자 지정 스크립트를 사용하여 정기적으로 갱신된 스냅숏을 제공하도록 예약됩니다. 그림 4의 예제 스크립트에서는 이 작업을 수행하는 데 사용된 저장 프로시저를 보여 줍니다. 이 스크립트는 환경에 설치된 특정 데이터베이스에 대한 스냅숏을 만들고 제거하는 작업을 관리하는 작업 내에서 사용할 수 있도록 설계되었습니다. 이 스크립트를 사용하면 보고 데이터가 프로덕션 데이터로부터 격리되기 때문에 보고 솔루션으로 사용하기에 적합합니다.
Figure 4 스냅숏 예약을 위한 저장 프로시저
use msdb;
GO
set nocount on
GO
CREATE PROCEDURE usp_snaprefresh
@database sysname = NULL --name of the database to snapshot
,@keepsnap int = 24 --# of hours to keep a snapshot
--after it was created
--use a value of '0' to keep all
--existing snapshots
,@fileloc sysname --location for snapshot
= 'C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data\'
AS
DECLARE
@dt datetime ,@cnt int
,@databaseid int ,@snap sysname
,@sql nvarchar(1000) ,@yy varchar(4)
,@mm varchar(2) ,@dd varchar(2)
,@h varchar(2) ,@m varchar(2)
,@lname sysname ,@pname sysname
,@file sysname ,@pos1 int
,@pos2 int
-- initialize variables
SELECT
@dt = getdate()
,@cnt = 0, @pos1 = 0, @pos2 = 0
,@databaseid = db_id(@database)
-- check if valid database was provided
IF @databaseid IS NULL
BEGIN
RAISERROR ('Missing database name. Rerun the procedure specifying a
valid database name.',16,1)
RETURN (0)
END
--determine if snapshots should be kept
IF @keepsnap <> 0
BEGIN
-- determine if other snapshots exist for this server older than @
-- keepsnap value hrs
SELECT ROW_NUMBER() OVER(ORDER BY name DESC) AS [RowNum],
name INTO #t1
FROM master.sys.databases
WHERE source_database_id = @databaseid
AND create_date < dateadd(hh,-(@keepsnap),getdate())
IF (SELECT max(RowNum) FROM #t1 where name is not null) > 0
BEGIN
WHILE @cnt <= (SELECT max(RowNum) FROM #t1)
BEGIN
SELECT @snap = name FROM #t1 WHERE RowNum = @cnt
PRINT 'Dropping snapshot ''' + @snap + ''''
SET @sql = 'DROP DATABASE ' + @snap
EXEC(@sql)
SELECT @cnt = @cnt + 1
END
END
END
-- break apart point in time date time information for file name
SELECT @yy = convert(varchar(4),year(@dt)),@mm = convert(varchar(2),
month(@dt))
,@dd = convert(varchar(2), day(@dt)),@h = convert(varchar(2),
datepart(hh,@dt))
,@m = convert(varchar(2), datepart(mi,@dt))
-- piece together the database snapshot name and the file name
SELECT @file = @database + '_' + @yy + @mm + @dd + '_' + @h + @m
-- identify logical file name of primary data file
SET @sql = 'SELECT name INTO tempdb..t1
FROM ' + @database + '.sys.database_files
WHERE file_id = 1'
EXEC(@sql)
--setting logical filename for the snap
SELECT @lname = name FROM tempdb..t1
-- making sure the file location ends with '\'
IF substring(@fileloc, len(@fileloc), 1) <> '\'
BEGIN
SET @fileloc = @fileloc + '\'
END
-- build sql statement to be run
SET @sql = N'CREATE DATABASE ' + @file + ' ON
(NAME = ' + @lname + ', FILENAME = ''' + @fileloc + @file + '.snp'')
AS SNAPSHOT OF ' + @database
EXEC(@sql)
-- cleanup
DROP TABLE tempdb..t1;
GO
그러나 스냅숏은 백업이 불가능하고 원본 데이터베이스가 없으면 존재할 수 없기 때문에 데이터베이스 스냅숏은 임시 데이터라는 점을 잊지 마십시오. 스파스 파일의 여유 공간이 없어지면 스냅숏은 손상된 것으로 간주되어 제거됩니다.
또한 데이터베이스 스냅숏을 사용하면 스냅숏이 만들어질 때마다 원본 데이터베이스 데이터 파일의 데이터 페이지가 스파스 파일에 기록되기 때문에 원본 데이터베이스에서 데이터 수정 작업이 수행되는 동안 시스템 성능이 저하될 수 있습니다. 결과적으로 데이터베이스에 있는 스냅숏 수에 비례하여 쓰기 횟수가 늘어납니다.
스냅숏이 만들어질 때 원본 데이터베이스에 의해 정의되는 읽기 권한은 변경할 수 없습니다. 스냅숏과 원본 데이터베이스는 데이터 페이지뿐만 아니라 동일한 버퍼 캐시도 공유하므로 동일한 인스턴스에 있어야 합니다.
스냅숏은 미러링을 함께 사용할 경우에만 보고 솔루션으로 사용하는 것을 고려할 만하며 그 외의 경우에는 환경의 성능 향상에 도움이 되지 않습니다. 데이터베이스 스냅숏은 의심이 가는 작업을 시스템에서 실행하기 전에 데이터를 보존할 수 있는 가장 빠른 방법일 수 있습니다. 데이터베이스를 스냅숏의 상태로 되돌리거나 스냅숏의 데이터를 원본 데이터베이스의 데이터와 바꿀 수 있습니다.
스냅숏 데이터베이스에 대한 명명 표준을 결정해야 합니다. 여기서 사용하는 표준은 originaldatabasename_date_time.snp입니다. 이 표준은 원본 데이터베이스를 먼저 지정한 후 스냅숏이 만들어진 날짜와 시간(24시간 형식)을 지정합니다.
로그 전달
로그 전달은 백업과 복구를 사용하여 매우 저렴한 솔루션을 만들 수 있는 제한된 고가용성 옵션입니다. 로그 전달은 예약된 간격으로 트랜잭션 로그 백업을 수행하여 보조 데이터베이스를 최신 상태로 유지합니다.
SQL Server 2005의 로그 전달에서는 마법사를 통해 설치, 예약, 초기화 및 모니터링 프로세스를 수행합니다(그림 5 참조). 이 프로세스는 간단하기 때문에 몇 분 안에 완료할 수 있습니다.
Figure 5** Log shipping setup wizard **(더 크게 보려면 이미지를 클릭하십시오.)
주 데이터베이스가 식별되면 일정이 만들어지고 백업 파일에 대한 파일 보존 기간이 결정됩니다. 그런 다음 백업 파일에 대한 파일 공유를 설정해야 합니다. 파일 공유를 설정한 후에는 보조 데이터베이스 파일 위치를 설정한 다음 주 데이터베이스의 복원을 완료하여 보조 데이터베이스를 초기화해야 합니다. 마지막으로 각 단계에 필요한 경고 또는 지연과 함께 트랜잭션 로그 백업의 복원과 백업 파일 사본에 대한 일정을 설정해야 합니다.
설정이 완료되면 로그 전달은 예약된 일정에 따라 데이터베이스의 트랜잭션 로그를 공유 네트워크 위치에 백업합니다. 파일이 공유 위치로 전송되면 정해진 일정에 따라 백업이 보조 데이터베이스에 적용됩니다.
로그 전달은 단순하기 때문에 여러 상황에서 잘 작동할 뿐만 아니라 트랜잭션이 높은 시스템에 사용할 수 있고 저렴하기 때문에 고가용성을 위해 선택할 수 있는 좋은 방법입니다. 로그 전달에 사용되는 보조 데이터베이스는 읽기 전용 모드로 사용할 수 있기 때문에 보고 데이터베이스로 사용하기에 좋습니다. 로그 전달은 오버헤드가 매우 낮지만 오류를 처리해야 하는 경우에는 경고 정책을 사용해야 합니다.
환경에서 로그 전달을 사용할 경우 얻을 수 있는 장점은 설정 및 관리가 간편하고 특별한 기술이 거의 필요하지 않다는 점입니다. 로그 전달은 실시간 고가용성 솔루션이 아니지만 데이터베이스 미러링과 함께 사용할 경우 이 목적으로 사용할 수 있습니다. 로그 전달은 일정과 백업, 파일 사본 및 복원과 같은 작업에 의해 제한됩니다. 또한 수동 장애 조치가 필요합니다. 이러한 이유 때문에 로그 전달은 시간 요구 사항의 중요성이 높지 않은 환경에 적합한 간단한 솔루션입니다.
SQL 서버 클러스터링
서버 클러스터링은 OS 수준에서 작동하며 여분의 하드웨어를 배치해야 하고 클러스터에서 액세스할 공유 디스크 리소스도 필요합니다. 클러스터링은 최종 사용자에게 가장 많은 혜택을 줄 수 있는 방법인 동시에 비용도 가장 많이 드는 방법입니다. 클러스터링되지 않은 인스턴스를 실행하는 데 필요한 하드웨어에 비해 두 배 이상의 하드웨어가 필요합니다.
클러스터링이라는 주제는 매우 광범위하므로 여기서는 모든 것을 자세히 설명하는 대신 일반적인 개요만 설명하겠습니다. 클러스터링에는 두 개 이상의 서버가 필요하며, 이들 서버에는 동일한 버전의 Windows® 2000 Advanced 또는 Datacenter Edition이나 Windows Server® 2003 Enterprise 또는 Datacenter Edition이 설치되어 있어야 합니다. 또한 서버 간 공유 리소스의 소유권을 처리하고 IP 주소, 공유 디스크 및 네트워크 이름을 관리하는 Microsoft® Cluster Services(MSCS)가 설치되어 있어야 합니다. 또한 클러스터링에는 일반적으로 SAN(Storage Area Network) 또는 SCSI 연결 저장소 형태로 된 공유 디스크 리소스도 필요합니다.
SQL Server 인스턴스도 리소스로 고려되며 SQL Server 2005 Standard 및 Enterprise Edition을 클러스터 구성에 설치할 수 있습니다. SQL Server 2005 Standard 및 Enterprise Edition에서 지원되는 기능 목록은 "SQL Server 2005 기능 비교 차트"(microsoft.com/sql/prodinfo/features/compare-features.mspx)를 참조하십시오.
클러스터에 리소스가 설정되면 클러스터의 두 노드를 연결하는 개인 네트워크에 설정된 하트비트를 통해 클러스터의 보조 노드와 주 노드 사이의 정기적인 통신이 유지됩니다. 하트비트는 주 노드의 오류 여부를 확인하기 위해 사용되는 간격 검사점입니다.
주 노드에 오류가 발생하면 리소스가 보조 노드로 옮겨지고 논리 서버의 상태는 그대로 유지됩니다. 이 경우 클라이언트에서는 일시적으로 상호 작용이 중단되기는 하지만 계속해서 작업을 수행할 수 있습니다. 전체 장애 조치 프로세스는 5 - 30초 정도 소요되며, 클러스터에 관련된 하드웨어, 소프트웨어 및 네트워킹 구성 요소에 따라 그 이상의 시간이 걸릴 수도 있습니다.
클러스터링은 시스템 오류를 해결하기 위해 전문적인 기술이 필요한 복잡하고 많은 비용이 드는 기술이기는 하지만 자동 장애 조치 옵션 중 가장 원활한 장애 조치 성능을 제공하는 기술입니다. 다양한 응용 프로그램 중에는 클러스터를 인식하지 못하거나 호환이 되지 않는 응용 프로그램이 있을 수 있으며, 최악의 경우에는 응용 프로그램을 다시 연결해야 합니다.
복제
SQL Server 2005 복제도 고가용성 아키텍처에 사용할 수 있습니다. SQL Server 2005 복제에는 스냅숏, 트랜잭션, 피어-투-피어 및 병합이라는 네 가지 유형의 복제가 있습니다. 피어-투-피어 복제는 실제로 트랜잭션 복제의 한 형태이므로 여기서는 설명하지 않겠습니다.
복제를 사용하면 주 데이터베이스와 완전 동일하게 작동하는 보조 사이트 및 데이터베이스를 통해 고가용성을 얻을 수 있습니다. 이러한 효과는 주 데이터베이스와 보조 데이터베이스의 트랜잭션을 모두 받아서 변경 내용을 상대 데이터베이스에 병합하는 병합 복제를 통해 얻을 수 있습니다. 그러나 예상한 대로 이 구성에는 충돌 해결 절차가 필요합니다.
트랜잭션 복제는 논리 설계면에서 데이터베이스 미러링과 매우 비슷합니다. 환경을 일관되게 유지하기 위해 주 데이터베이스에 적용된 트랜잭션이 보조 데이터베이스에 전달됩니다. 수신된 트랜잭션은 보조 데이터베이스에 적용된 후 시스템에 적용될 다음 트랜잭션을 기다립니다.
스냅숏 복제는 예약된 간격으로 실행된다는 점과 각 트랜잭션이 커밋될 때 두 시스템에 적용되지 않고 대량의 변경 내용을 적용하여 보조 데이터베이스를 업데이트한다는 점에서 로그 전달과 매우 비슷합니다. 두 기술은 매우 비슷한 방식으로 사용됩니다.
복제에는 특별한 지식이 필요하기 때문에 전담 DBA가 없는 환경에서는 많은 부담을 느낄 수 있습니다. 복제는 문제 해결 과정이 다소 복잡할 수 있으며 고가용성 옵션으로 사용할 경우 보다 복잡한 설계가 필요합니다.
복제는 고가용성 솔루션에 대한 요구 사항을 적절하게 충족할 수 있습니다. 이 기술은 데이터베이스 미러링이 수행할 수 있는 작업을 자동 장애 조치에 대한 옵션 없이 트랜잭션 복제를 사용하여 레코드 수준에서 수행합니다. 충분한 리소스가 있고 어느 정도의 창의성만 있으면 자동 장애 조치 솔루션도 어렵지 않게 스크립트로 작성할 수 있습니다.
데이터베이스 미러링과는 달리 원본 및 대상 데이터베이스 모두 클라이언트 응용 프로그램에 완전히 액세스할 수 있습니다. 복제는 스냅숏 복제를 사용하는 로그 전달과 동일한 기능을 제공합니다.
그러나 복제 기술은 현장에서 검증된 기술로서 문서화가 잘 되어 있다는 점을 고려해야 합니다. 복제를 고가용성 솔루션으로 사용할 경우에는 몇 가지 단점이 있으며 데이터베이스 미러링과 마찬가지로 성능 문제가 발생할 수 있습니다. 복제를 사용하여 설계한 고가용성 솔루션은 아키텍처가 복잡하기 때문에 관리하기가 어렵습니다. 반드시 고급 아키텍처라고는 할 수 없지만 보다 복잡한 것은 분명합니다. 또한 고려해야 할 난제 중 하나는 데이터베이스 테이블 구조가 변경되거나 복제할 테이블을 추가할 경우 두 데이터베이스에 적용할 변경 내용에 대한 게시를 삭제하고 다시 정의해야 한다는 것입니다.
요약
이제 환경에 적합한 고가용성 솔루션을 만들기 위해서는 약간의 창의성이 필요하다는 것을 알 수 있습니다. 각 SQL Server 2005 고가용성 기술에는 장단점이 있기 때문에 적합한 상황 또한 각기 다릅니다.
로그 전달, 스냅숏 복제 및 고성능 모드의 데이터베이스 미러링은 주 웹 데이터베이스 환경과 보조 데이터베이스 환경이 지역적으로 분리되어 있는 경우, 특히 보조 데이터를 실시간으로 액세스하지 않아도 되는 경우에 적합합니다.
반면 실시간 데이터 액세스가 보조 데이터베이스의 요구 사항에 포함된 경우, 주 서버의 트랜잭션 속도가 낮고 두 환경 사이트 간의 링크가 빠르면서 비포화 상태라면 트랜잭션 복제나 데이터베이스 미러링이 적합합니다.
또한 이러한 기술에 대해 얼마나 잘 알고 있는지도 고려해야 합니다. 이미 이러한 기술에 대한 작업 경험이 있으면 도움이 될 것입니다. 전담 DBA가 없는 관리자라면 이동해야 할 부분이 많고 문제 해결이 복잡할 수 있는 복제와 같은 복잡한 기술은 사용하지 않는 것이 좋습니다. 또한 경험 많은 SQL Server 컨설턴트에 문의하여 환경에 적합한 새로운 고가용성 솔루션에 대한 설계, 구현 및 관리 직원 교육에 필요한 도움을 받을 수 있습니다.
데이터의 가용 시간을 최대한으로 유지해야 하고 데이터 중지 시간을 매우 중요하게 고려하는 조직의 경우 고가용성을 위해 클러스터링을 선택하는 것도 좋은 방법입니다.
이 모든 내용의 주제는 SQL Server 2005가 다양한 유형의 환경에 적합한 고가용성을 구현하는 데 필요한 여러 가지 새 옵션을 제공한다는 것입니다. 단일 가용성 옵션이 요구에 적합할 수 있는 반면 여러 기술을 결합해서 사용할 수도 있습니다. 앞에서 설명한 대로 환경에 적합한 다양한 선택의 기회가 있습니다.
Zach Nichter는 10년 이상의 경력을 가진 SQL Server 전문가로서, DBA, 팀장, 관리자 및 컨설턴트를 비롯한 다양한 SQL Server 지원 업무를 수행했습니다. 현재 Levi Strauss & Co.에서 DBA 설계자로 근무하고 있는 Zach는 주로 SQL Server 성능, 모니터링, 아키텍처 및 기타 전략적 이니셔티브에 관한 업무를 담당하고 있습니다.
© 2008 Microsoft Corporation 및 CMP Media, LLC. All rights reserved. 이 문서의 전부 또는 일부를 무단으로 복제하는 행위는 금지됩니다..