SQL Server

SQL Server 클러스터링에 유용한 정보

Tom Moreau

한 눈에 보기:

• 클러스터에서 SQL Server 실행
• 하드웨어 및 소프트웨어 요구 사항
• 1 노드 클러스터링
• 비용 효율적인 옵션

서버 클러스터를 사용하면 여러 개의 실제 서버나 노드를 연결하여 각각이 서로의 장애 조치 파트너로 작동하도록 할 수 있습니다. 클러스터가 제공하는 중복성은 중요 작업을 위한 가동 시간을

더 늘려 줍니다. 지난 13년간 SQL Server™를 사용하면서 수많은 클러스터를 구현해 보았는데 저마다 고유의 문제를 지니고 있었습니다. 이러한 경험을 바탕으로 클러스터링을 보다 쉽고 안정적으로 사용하는 데 도움이 되는 많은 유용한 정보를 수집할 수 있었습니다.

서버 클러스터는 Windows Server® Enterprise Edition 제품군에서 기본적으로 제공되는 클러스터링 기능을 사용합니다. 사실 클러스터링을 사용할 목적이라면 Windows 2000 Advanced Server보다 Windows Server 2003이 훨씬 낫습니다. 클러스터링을 통해 얻을 수 있는 이점을 최대화하려면 적절한 하드웨어를 사용해야 하는데 이를 위해서는 어느 정도의 비용을 투자할 필요가 있습니다. 공유 디스크를 사용하여 두 개의 서버를 연결하는 것만으로는 충분하지 않습니다. 또한 개별 하드웨어 구성 요소는 Windows® 카탈로그(이전의 하드웨어 호환성 목록)에서 구할 수 있다는 사실에만 의존해서도 안 됩니다. 시스템 전체가 Windows 카탈로그에 있는 것이어야 합니다. 하지만 저렴한 비용으로 사용할 수 있는 몇 가지 검증된 클러스터 솔루션이 있으므로 걱정할 필요는 없습니다. 그림 1에서는 일반적인 클러스터 구성을 보여 줍니다.

Figure 1** A typical cluster **(더 크게 보려면 이미지를 클릭하십시오.)

물론 클러스터링을 구현하려면 하드웨어 외에 적절한 SQL Server 2005 버전도 선택해야 합니다. Enterprise Edition을 사용하면 클러스터링뿐 아니라 더 많은 수의 CPU를 활용할 수 있는 기능, 분산되어 있고 업데이트가 가능한 분할된 뷰, 기본으로 제공되는 로그 전달, 인덱싱된 뷰 자동 사용과 같은 여러 유용한 기능을 사용할 수 있습니다. 이미 Enterprise Edition 라이선스를 구입한 경우 일반적인 클러스터 구성에 필요한 2-8대의 서버가 있는지 여부에 관계없이 클러스터링 사용을 고려해야 합니다. 잠시 후 1 노드 클러스터에 대해 살펴보겠습니다. SQL Server 2005 Standard Edition을 사용하는 경우 2 노드 클러스터를 설치할 수 있습니다.

Windows Server 2003의 Enterprise Edition 및 Datacenter Edition에서는 클러스터링이 기본으로 제공되므로 클러스터 관리자를 실행하여 클러스터를 설치하기만 하면 됩니다. 노드를 한 번에 모두 추가하거나 한 번에 하나씩 추가할 수 있습니다. 마찬가지로 SQL Server를 클러스터링되지 않은 개별 서버에 설치하거나 클러스터에 가상 인스턴스를 설치할 수 있습니다. 가상 인스턴스를 설치할 경우 클러스터의 모든 노드, 일부 노드 또는 한 노드에만 설치할 수 있습니다.

마지막으로, 클러스터링을 통해 고가용성이라는 궁극적인 목적을 달성하려면 자격을 갖춘 인력과 비상 사태에 대한 대비 절차가 마련되어 있어야 합니다. 클러스터링이 하드웨어 오류에 대한 좋은 방책은 될 수는 있지만 데이터베이스 관리자가 야간 근무 중에 수면 부족으로 중요한 테이블을 잘못 삭제하는 것과 같은 사용자 오류까지 막을 수는 없습니다.

1 노드 클러스터

지금은 단일 서버만 필요하더라도 1 노드 클러스터를 만드는 것을 고려해 보십시오. 그러면 나중에 필요할 때 클러스터로 업그레이드할 수 있으므로 다시 만들 필요가 없습니다. 선택한 하드웨어가 Windows 카탈로그의 클러스터 부분에 포함되어 있는지 확인하기만 하면 됩니다.

이는 나중에 노드를 추가할 수 있도록 하는 고가용성만을 위한 것이 아닙니다. 나중에 서버의 용량이 충분하지 않게 될 경우 어떤 일이 발생할지 생각해 보십시오. 이로 인해 많은 시간과 노력이 수반되는 마이그레이션을 수행해야 할 수도 있습니다. 1 노드 클러스터를 만들면 작동 중단 시간은 대폭 줄이면서도 마이그레이션은 더욱 쉽게 수행할 수 있습니다. 클러스터에 새 노드를 추가하고 새 노드에 SQL Server 이진 파일과 서비스 팩을 추가한 다음 새 노드로 장애 조치합니다. 그런 다음 서비스 팩 이후 나온 업데이트를 추가하고 이전 노드를 제거합니다. 시스템 작동은 장애 조치를 수행하고 업데이트를 추가하는 동안에만 중단됩니다.

노드 추가

클러스터의 노드는 모두 동일해야 하므로 여분의 노드를 미리 준비해 두는 것이 좋습니다. 그렇지 않으면 동일 노드의 생산이 중단될 경우 어려움을 겪을 수 있습니다. 이전에 수행했던 한 프로젝트에서는 SQL Server 2000 클러스터에 한 개의 노드를 다시 만들어야 했습니다. 당시 컴퓨터를 다시 구축하는 기본적인 작업은 운영 체제/네트워크 관리자에게 위임하고 필자는 클러스터에 노드를 다시 추가하여 SQL Server 노드로 작동하도록 준비하는 작업을 진행했습니다. 새 노드로 장애 조치를 시작하기 전까지는 모든 것이 순조롭게 진행되었습니다. 하지만 장애 조치를 시작하자마자 곧바로 오류가 발생했습니다. 간단히 말하자면, 클러스터 서비스 및 SQL Server 서비스 계정을 두 노드에 추가하는 방법을 포함하여 새 클러스터 구축에 대한 자세한 문서를 마련해 두었는데 이 문서의 내용이 정확하게 반영되지 않았던 것입니다. 그 관리자는 다시 만든 노드에 서비스 계정을 추가하지 않았고 그 결과 노드를 다시 만들기 전까지 해당 서비스 계정에 부여되어 있었던 권한이 없어졌습니다.

이 문제의 원인을 추적하기까지 많은 시간이 걸렸습니다. 어느 날 로컬 그룹 멤버 자격을 검토하게 될 일이 생겼고, 이때 두 개의 계정을 추가하게 되었는데 이후부터는 장애 조치가 원활하게 이루어졌습니다. 그때 문득 다음과 같은 생각이 들었습니다. 노드를 다시 만드는 작업은 비상시에만 수행하는 일이지 자주 수행하는 일은 아니라는 것입니다. 문서까지 마련해 두었지만 적절히 사용되지 않았습니다. 당시 두 개의 계정을 추가하고 필요에 맞게 기타 사항을 사용자 지정하는 간단한 스크립트를 작성하여 이 보안 부분을 자동화할 수 있었습니다. SQL Server 2005에서는 상황이 개선되어 설치 관리자가 SQL Server 서비스 계정에 대해 도메인 수준 그룹을 설정하도록 요청합니다.

물론 이로 인해 생각해야 할 것도 많아졌습니다. CLUSTER.EXE를 호출하여 MSCS(Microsoft® Cluster Server) 클러스터에 노드를 추가하는 스크립트를 만들 수 있습니다. 노드 이름만 제공하면 나머지는 스크립트가 자동으로 처리합니다. 비상시에는 자동화가 정말로 편리합니다.

N+1 클러스터

노드를 대체하려는 것이 아닌 다른 이유로 클러스터에 노드를 추가해야 할 경우가 있습니다. 클러스터에 SQL Server 인스턴스를 추가할 수 있지만 각 인스턴스에는 별도의 디스크 리소스가 필요합니다. 단일 노드에서 여러 개의 인스턴스를 실행할 수도 있지만 이 경우 모든 인스턴스가 CPU와 RAM을 공유하므로 성능이 저하될 수 있습니다. 따라서 단일 노드에서 단일 인스턴스를 실행하는 것이 가장 이상적입니다. 하지만 이 경우 장애 조치를 어떻게 수행해야 하는지에 대한 문제가 발생합니다. 방법은 간단합니다. 한 노드에서만 서비스를 실행하지 않고 이외 다른 노드에서는 SQL Server 인스턴스를 하나씩 실행하는 것입니다. 즉, N+1 클러스터란 N+1개의 노드에서 N개의 인스턴스를 실행하는 클러스터를 의미하며, 여분의 노드는 백업용입니다.

SQL Server 업그레이드

클러스터링된 SQL Server 인스턴스를 업그레이드하는 것은 결코 쉬운 작업이 아닌데 클러스터링의 목적이 바로 가동 시간을 늘리는 데 있기 때문입니다. 하지만 SQL Server 2005에서는 이러한 경우에 유용하게 사용할 수 있는 여러 향상된 기능이 있으므로 작동 중단 시간을 최소화하면서 업그레이드를 수행할 수 있습니다.

아래의 내용을 읽고 자신에게 적합한 방법을 선택하십시오. 먼저 비용이 가장 많이 드는 솔루션인 새 클러스터를 만드는 것에 대해 살펴보겠습니다. 새 클러스터를 만든다는 것은 새 서버, 그리고 경우에 따라 새 SAN(Storage Area Network)을 만드는 것을 의미합니다. 기존 네트워크 스위치는 그대로 사용할 수 있지만 그게 전부입니다. 분명히 이 방법은 비용이 저렴하다고는 할 수 없지만 장점이 많습니다. 디스크 용량과 속도가 매우 빠르게 향상되고 있는 새 하드웨어를 사용하면 일반적으로 기존 하드웨어보다 더 나은 성능을 얻을 수 있습니다. 즉, 새 하드웨어만으로도 성능이 개선되는 효과를 볼 수 있습니다. 단순히 기술면에서 앞서가려는 목적이라면 장비를 임대할 수도 있습니다.

하드웨어가 준비되었으면 여기에 새로운 가상 SQL Server를 만들고 프로덕션 데이터베이스를 복사하여 새로운 시스템의 성능을 시험해 봅니다. 시스템 전환일까지 버그를 없앨 시간도 충분합니다. 기존 서버에서 새 서버에 로그인할 수 있도록 지원하는 작업은 스크립트를 통해 수행하십시오. 자세한 내용은 support.microsoft.com/kb/246133에서 확인할 수 있습니다. 치명적 오류가 발생한 경우 로그인 생성 스크립트를 업데이트하는 것도 좋은 방법입니다.

데이터베이스 크기가 매우 작고 어떤 사용자도 연결하지 않는 특정 시간대가 있는 경우가 아니면 작동 중단 시간을 최소화하기 위해 로그 전달을 사용해야 합니다. 시스템 전환일 직전에 로그를 전달할 수도 있습니다. 그런 다음 사용자에게 시스템 사용을 중단할 것을 요청하고 마지막 로그를 잘라서 전달한 다음 새 인스턴스를 가리키도록 응용 프로그램을 설정하면 됩니다. 로그 전달 대신 사용할 수 있는 다른 방법은 아래의 데이터베이스 미러링 단원을 참조하십시오. DNS 별칭을 사용하는 경우 새 인스턴스를 가리키도록 응용 프로그램을 설정할 필요가 없습니다. 이때는 DNS 별칭을 업데이트하면 됩니다. 이 방법은 마이그레이션 작업을 상당 부분 진행했는데 원래 데이터베이스로 되돌려야 할 경우 원래 데이터베이스가 남아 있다는 점에서 그 장점을 찾을 수 있습니다.

이보다 저렴한 방법도 있지만 이를 수행하려면 보다 치밀한 계획이 필요합니다. 클러스터가 둘 이상의 SQL Server 인스턴스를 지원할 수는 있지만 각 인스턴스는 자체의 디스크 리소스를 사용해야 합니다. 따라서 SAN을 구성할 때 향후 업그레이드에 대비하여 LUN 하나를 여분으로 남겨 두어야 합니다. 업그레이드를 수행하려면 이 디스크 리소스에 SQL Server 이진 파일을 설치합니다. 새로운 시스템이 제대로 실행되는지 테스트한 다음 준비가 되면 현재 SQL Server를 종료합니다. 그런 다음 이전 SQL Server 그룹에서 디스크 리소스를 이동하고 종속 관계를 업데이트한 다음 새 SQL Server 인스턴스를 온라인으로 전환합니다. 이전 인스턴스의 데이터베이스를 연결하면 시스템이 작동되기 시작합니다. 잊지 말고 모든 항목을 미리 백업해 두십시오.

이것이 비용이 저렴한 방법입니다. 하지만 여기에는 몇 가지 위험도 따릅니다. 어딘가에서 오류가 발생하더라도 새 인스턴스에서 데이터베이스를 분리하여 원래대로 되돌릴 수 없습니다. 따라서 백업에서 복원할 수밖에 없는데 이 경우 작동 중단 시간이 너무 길어지게 됩니다.

대안으로 SAN에 SQL Server 인스턴스를 두 개 배치하는 방법이 있는데 이 방법을 사용하려면 공간이 충분해야 합니다. 프로덕션 백업과 로그 전달을 새 인스턴스로 복원한 다음 앞에서 설명했던 절차를 진행합니다. 하지만 앞에서와는 다르게 지금은 여분의 LUN이 있습니다. 마이그레이션이 완료되면 이전 인스턴스의 SAN 리소스를 확보할 수 있습니다. 따라서 추가로 사용된 디스크에만 비용을 투자하면 됩니다.

부하 분산

지금부터는 흔히 잘못 알고 있는 다음과 같은 개념에 대해 그 진실을 밝혀보겠습니다. MSCS 클러스터링은 부하 분산이 아니라 고가용성을 위해 사용합니다. 또한 SQL Server에는 기본적으로 제공되는 자동 부하 분산 기능이 없으므로 응용 프로그램의 물리적 설계를 통해 부하를 분산해야 합니다. 이것이 의미하는 바가 무엇인지 궁금하실 것입니다.

테이블의 크기가 커짐에 따라, 특히 이와 함께 테이블 검색이 수반될 경우 성능 저하를 예상할 수 있습니다. 데이터베이스의 행이 엄청나게 많아질 경우 이를 해결하기 위한 방법으로 지금까지는 분할된 뷰가 사용되어 왔습니다. 분할된 뷰란 UNION ALL로 연결된 테이블의 집합이며 테이블들은 동일한 스키마를 가집니다. 또한 멤버 테이블을 구분할 수 있도록 CHECK 제약 조건을 적용하는데 이 때문에 분할된 뷰에서는 데이터 복제가 수행될 수 없었습니다. CHECK 제약 조건에 사용된 열이 기본 키의 일부이기도 한 경우에는 뷰를 업데이트할 수 있습니다.

멤버 테이블이 자체의 파일 그룹에 있으며 해당 파일 그룹의 파일이 별도의 실제 드라이브에 있으면 디스크 성능이 향상됩니다. 테이블을 별도의 데이터베이스에 둘 수도 있습니다. 하지만 SQL Server 2005에서는 모든 데이터가 동일한 데이터베이스에 있는 경우에만 구현하기 휠씬 쉬운 테이블 분할 기술을 사용할 수 있습니다.

하지만 테이블 분할 또는 로컬 분할된 뷰를 사용하여 할 수 있는 모든 시도를 해 보았으나 여전히 성능이 느리다고 가정해 보십시오. SQL Server 2000 또는 SQL Server 2005를 사용하는 경우 분산된 분할된 뷰를 사용할 수 있습니다. 분할된 뷰와 비교했을 때 분산된 분할된 뷰가 가지는 가장 큰 차이점은 멤버 테이블이 서로 다른 SQL Server 인스턴스에 상주할 수 있으며 이러한 인스턴스를 N+1 클러스터에 설치할 수 있다는 것입니다. 굉장하지 않습니까? 분할된 뷰에서는 멤버 테이블 중 하나가 오프라인으로 전환되면 뷰 전체가 오프라인으로 전환됩니다. 이러한 멤버를 클러스터의 일부로 만들면 성능을 개선하는 데 필요한 안정성과 함께 부하 분산이라는 두 가지 목적을 모두 달성할 수 있습니다.

클러스터가 정말로 필요하십니까?

여분의 서버가 있는데 이러한 서버가 Windows 카탈로그의 클러스터 부분에 없는 서버라고 가정해 보십시오. 남아도는 서버가 있는데 클러스터를 지원하려고 새로운 서버를 구입한다는 것은 말이 되지 않습니다.

데이터베이스 미러링은 클러스터링 대신 사용할 수 있는 매우 매력적인 기술입니다. 미러링에는 다음 세 가지 요소가 포함됩니다. 하나는 미러링된 데이터베이스의 원본이 되는 주 서버라는 인스턴스이고 다른 하나는 미러 서버라고 하는 백업 서버입니다. 마지막으로 자동 장애 조치를 원하는 경우 미러링 모니터 서버라고 하는 제3의 서버가 필요합니다. 간단히 말하면 주 서버의 데이터베이스에 있는 트랜잭션이 미러 서버에서 다시 실행됩니다. 주 서버가 다운되면 미러 서버로 장애 조치되며 미러링 모니터 서버가 있는 경우 장애 조치가 자동으로 수행됩니다. 각 응용 프로그램 데이터베이스에 대해 미러링을 설정해야 하며 시스템 데이터베이스는 미러링할 수 없습니다.

미러 서버는 별도의 SQL Server 인스턴스이므로 클러스터와는 달리 수천 킬로미터 떨어진 곳에 둘 수도 있습니다. 미러 서버의 캐시는 주 서버에서 복제된 트랜잭션으로 인해 발생하는 업데이트 작업을 통해 채워집니다. 물론 이는 주 서버에서 미러링된 트랜잭션을 받는 것 외에는 미러 서버에서 어떤 작업도 일어나지 않는다고 가정했을 때의 경우입니다. 미러 서버에서 SQL Server가 이미 실행되고 있으므로 장애 조치가 수행되는 속도는 일반적으로 클러스터보다 빠릅니다. 적어도 캐시의 일부는 최적의 상태이므로 초기 성능은 클러스터링 시나리오만큼 느리지는 않습니다. 또한 미러링된 데이터베이스에 장애 조치가 필요한 경우 주 서버와 미러 서버의 역할이 바뀐다는 점에도 주목하십시오.

데이터베이스 미러링의 경우 클러스터에 비해 필요한 총 디스크 용량이 클러스터의 두 배에 달한다는 단점이 있습니다. 데이터 손실이 없는 동기화 모드로 실행하려면 CPU 성능도 더 우수해야 합니다. 앞에서도 언급했지만 고가용성은 결코 저렴한 기술이 아닙니다.

두 방법의 결합

미러 서버는 주 서버와 멀리 떨어진 지점에 배치할 수 있으므로 장애 복구(DR) 계획에 적합합니다. 클러스터를 최전방 방어선으로 사용할 수 있지만 클러스터링과 미러링을 모두 사용하면 훨씬 좋습니다. 클러스터 장애 조치를 사용할 경우 미러링 구성의 일부로 미러링 모니터 서버를 배치하면 클러스터링된 SQL Server가 온라인으로 전환되는 동안 미러 서버가 주 서버가 됩니다. 하지만 새로운 주 서버에서 클러스터링된 새 미러 서버로의 장애 조치는 자동으로 수행되지 않는다는 점에 주목하십시오. 결과적으로 클러스터와 함께 사용할 때는 미러링된 데이터베이스에 자동 장애 조치를 사용하지 않는 것이 좋습니다.

미러링을 사용하는 이유가 재해 복구에만 있는 것은 아닙니다. 미러링은 주 서버에 서비스 팩이나 핫픽스를 적용해야 할 경우 미러 서버로 수동으로 장애 조치할 수 있으므로 유용합니다. 서비스 팩이나 핫픽스를 적용하는 동안에는 이전의 주 서버가 임시로 오프라인으로 전환되고 새로운 주 서버에서 발생하는 커밋된 트랜잭션은 큐로 보내져 다시 새 미러 서버(이전의 주 서버)로 보내질 때까지 대기합니다. 서비스 팩 또는 핫픽스 설치가 끝나면 동기화가 수행되어 두 서버가 완전히 동기화됩니다. 동기화가 끝나면 주 서버와 미러 서버의 역할을 바꿀 수 있습니다. 장애 조치를 수행하고 원래대로 되돌리는 데 필요한 작동 중단 시간은 매우 짧습니다. SQL Server를 다른 컴퓨터로 마이그레이션하는 데 이 방법을 사용할 수 있습니다. 실패하지 말고 잘 해보십시오.

가상 서버 추가가 제공하는 융통성

가상화 기술을 사용하면 한 대의 실제 서버에서 하나 이상의 운영 체제를 동시에 실행할 수 있습니다. 가상화 소프트웨어를 사용하면 소프트웨어에도 클러스터링을 적용할 수 있으므로 클러스터의 기능이 한 층 더 다양해집니다. 결론부터 말하자면 호스트가 실행되는 서버에서 오류가 발생하면 서버와 서버의 게스트 운영 체제가 백업 노드로 장애 조치됩니다. 따라서 게스트 서버를 간편하게 마이그레이션하는 방법으로 이용할 수 있습니다. 게다가 게스트 운영 체제에서는 클러스터링을 지원할 필요가 없으므로 클러스터에서 Microsoft Virtual Server 2005를 실행하는 게스트 Windows Server 2003 내에서 SQL Server Workgroup Edition을 실행할 수 있습니다. 이를 통해 간접적으로 Workgroup Edition을 클러스터링한 결과를 얻을 수 있습니다(그림 2 참조).

Figure 2** Using a virtual server **(더 크게 보려면 이미지를 클릭하십시오.)

관리

SQL Server 구현을 담당하는 사람은 서버를 항상 사용 가능한 상태로 유지해야 합니다. 서버 클러스터링을 사용하면 이러한 목표를 쉽게 달성할 수 있습니다. 이 문서에서는 클러스터링을 시작하는 데 도움이 되는 몇 가지 유용한 정보를 제공합니다. . "클러스터링 리소스" 추가 기사에서는 보다 자세한 정보를 제공하는 문서의 링크를 제공합니다.

클러스터링 리소스

이 문서에서 설명하는 방법 및 SQL Server 클러스터를 설정하는 데 필요한 다양한 제품에 대한 자세한 내용은 다음 리소스를 참조하십시오.

• SQL Server 2005 장애 조치 클러스터링
• SQL Server 2000 장애 조치 클러스터링
• 클러스터링 서비스
• Microsoft 클러스터 서버 관리자 가이드
• Microsoft Virtual Server 2005 R2

Tom Moreau는 토론토에 거주하며 이학 석사 학위, 박사 학위, MCSE 인증 및 MCDBA 인증을 소지하고 있습니다. 현재는 SQL Server 데이터베이스 관리, 설계 및 구현 분야의 전문적인 독립 컨설턴트로 활동하고 있습니다. 1993년부터 SQL Server를 사용해 왔고 2001년부터 SQL Server MVP로 활동하고 있습니다. 지금까지 작성한 기사만 100편이 넘으며 SQL Server 관련 서적의 공동 저자이기도 합니다. 유용한 정보를 제공한 SQL Server MVP Geoff Hiten에게 감사를 전합니다.

© 2008 Microsoft Corporation 및 CMP Media, LLC. All rights reserved. 이 문서의 전부 또는 일부를 무단으로 복제하는 행위는 금지됩니다..