2007/09/16

SQL Server 2005 미러링 제한

 - 다음 내용은 Microsoft TechNet Magazine Q&A 내용중 SQL Server 와 관련된 일부 항목을 발췌하였습니다. 실제 이러한 고민은 대부분의 관리자들이 직면해 있는 최적의 방안을 찾아내야 하는 문제 이기도 합니다. -


질문:

SQL Server 2005 데이터베이스 미러링에 관한 글을 읽다가 데이터베이스 미러링은 서버 인스턴스당 데이터베이스를 최대 10개까지만 지원할 수 있는 제한이 있음을 알게 되었습니다.

제 환경에서는 별도의 저장소가 있는 두 개의 SQL Server 인스턴스가 있어야 하고, 두 인스턴스 간에 자동 장애 조치가 수행되어야 하며, 데이터 중복 기능이 제공되어야 합니다.

P2P(피어 투 피어) SQL Server 2005 트랜잭션 복제와 Microsoft® Cluster Server(MSCS)를 결합함으로써 두 노드 중 한 노드만 대상으로 하는 클러스터 IP를 사용하여 모든 삽입, 업데이트, 삭제 및 읽기 트래픽이 클러스터의 단일 노드로만 향하도록 하려고 합니다.

두 번째 노드는 패시브 노드로 만들고 이 노드에 트랜잭션이 복제되도록 하려고 합니다. 오류가 발생할 경우에는 MSCS가 해당 IP를 다른 노드로 장애 조치하고 클러스터가 P2P 및 양방향으로 구성되어 있으므로 다른 노드(백업된 경우)에 트랜잭션 게시를 시작하기 위해 수동 프로세스를 수행할 필요가 없습니다. 또한 MSCS 내에 MNS(주 노드 집합) 구성을 사용하면 쿼럼용 공유 디스크 리소스를 둘 필요가 없게 됩니다.

테이블에는 여전히 미러링 옵션이 설정되어 있습니다. SQL Server 클러스터당 1,000개에서 100개로 데이터베이스를 줄였는데도 시스템에 이런 유형의 부하를 계속 놔두어야 합니까?


답변:

SQL Server 미러링과 관련된 자세한 내용이나 안내서를 보려면 온라인 설명서, SQL Server Tech Center(microsoft.com/technet/prodtechnol/sql) 및 msdn2.microsoft.com/sql을 참조하십시오.

이 질문에 대답하려면 많은 설명이 필요합니다. 여기서는 질문자의 시나리오와 관련하여 가장 적절한 대답만 제시하겠습니다.

첫 번째는 해당 인스턴스에서 미러링할 수 있는 데이터베이스의 수에는 정해진 제한이 없다는 것입니다. 인스턴스당 최대 10개의 데이터베이스만 미러링하는 것이 좋다는 내용의 문서를 참조하신 것 같은데, 이 수치는 대략적인 것일 뿐이며 특별히 정해진 제한은 없습니다. 미러링할 수 있는 데이터베이스의 수는 전적으로 해당 시스템에서 사용할 수 있는 리소스에 달려 있습니다.

미러링이 옵션이 될 수 있지만, 성능이 매우 우수한 서버를 사용하는 경우가 아니라면 일반 서버에서 가능한 데이터베이스의 수는 최대 1,000개 정도입니다. 공유 저장소를 사용하지 않고 기본 제공되는 SQL Server 기술을 사용하려는 경우에는 미러링, 로그 전달 또는 복제 기능을 사용할 수 있습니다. 각 기능마다 나름대로의 장단점이 있습니다.

두 번째로, 공유 저장소 대신 다수의 데이터베이스가 있고 Microsoft에서 제공하는 장애 복구 솔루션을 사용하려는 경우 일련의 간단한 사용자 지정 도우미 프로그램을 사용하여 관리 오버헤드를 줄일 수 있는 로그 전달 기능을 검토해 보십시오.

한 프로그램으로 각 데이터베이스를 순서대로 백업 및 복원할 수 있으므로 여러 개의 로그 전달 에이전트를 실행하지 않아도 됩니다. 하지만 데이터가 손실될 가능성도 있다는 점을 염두에 두십시오. 기본 제공되는 솔루션은 모두 데이터 손실을 방지하기 위해 공유 저장소나 DBMS 중 하나를 필요로 합니다.

물론 MSCS로 어떻게 오류를 검색하고 장애 조치를 수행하느냐의 문제도 있습니다. 클러스터에 MNS를 구성하더라도 쿼럼용 전용 공유 LUN을 둘 필요성만 없어질 뿐이지 공유 저장소의 필요성이 완전히 사라지는 것은 아닙니다. IP와 네트워크 이름만 관리하도록 클러스터를 구성한다면 해당 계획을 실현하는 것이 가능합니다.

하지만 SQL Server는 공유 저장소 없이는 클러스터링할 수 없으므로, 이 경우 SQL 서비스를 클러스터링할 수 없게 됩니다. 즉, 일반적인 구성에서는 클러스터가 SQL Server 서비스를 검색하고 모니터링할 수 없습니다.

SQL Server 서비스를 일반 서비스로 추가하여 클러스터링하면 모니터링할 수 있지만, 이 경우 장애 조치에서 문제가 발생합니다. 다시 말해 서비스가 클러스터링되어 있으면 MSCS가 장애 조치 시 패시브 노드에서 서비스를 온라인 상태로 전환하려고 하지만 일부 SQL 서비스는 이미 실행되고 있는 문제가 발생합니다. 물론 IP와 네트워크 이름만 클러스터링한 다음 필요한 경우 수동으로 장애 조치를 수행할 수는 있습니다.

NLB(네트워크 부하 분산)를 통해 같은 목적을 달성할 수도 있는데, 이 방법은 어딘가에서 실행되고 있기도 합니다. 자세한 내용은 microsoft.com/technet/prodtechnol/sql/2000/deploy/hasog04.mspx 문서를 참조하십시오.

지원하려고 하는 데이터베이스의 수를 고려하면 로그 전달 솔루션이 더 적합합니다. 물론 DTS/SSIS(Data Transformation Services/SQL Server Integration Services) 패키지를 사용하여 프로세스를 자동화해야 합니다. 그렇지 않으면 오류가 발생할 경우 활성 로그를 수동으로 백업, 이동 및 적용하는 데 많은 시간이 걸릴 수 있습니다.


참고 포스트:

고가용 SQL Server 데이터베이스 미러링
http://www.serverinfo.pe.kr/TipnTech.aspx?Seq=251


http://www.microsoft.com/technet/




15-TechNetB_masthead_ltr.gif

댓글 없음:

댓글 쓰기

가장 많이 본 글