SQL Server 클러스터 문제 해결을 위한 몇 가지 팁 [2]

더 저렴한 방안도 채택할 수 있지만, 더 많은 사전 계획이 필요하다. 클러스터는 여러 SQL Server 인스턴스를 지원할 수 있지만 각 인스턴스에는 자체 디스크 리소스가 있어야 합니다. 따라서 SAN 을 조닝 (zoning) 할 때 향후 업그레이드를 위해 LUN 을 남겨 두십시오. 업그레이드를 수행하려면 이 디스크 리소스에 SQL Server 바이너리를 설치합니다. 시스템을 연습하고 준비가 되면 전원을 끌 수 있습니다. 현재 SQL Server 는 디스크 자원을 이전 SQL Server 그룹 밖으로 이동하여 종속성을 업데이트한 다음 새 SQL Server 인스턴스를 이전 인스턴스의 데이터베이스에 온라인으로 전환하고 실행을 시작합니다 (모든 데이터 쌍을 미리 백업했습니까? ) 을 참조하십시오

이것은 저렴한 방법이다. 이 방법을 실현하려면, 너는 약간의 위험을 감수해야 한다. 문제가 발생하면 데이터베이스를 새 인스턴스에서 분리하여 원래 위치에 다시 놓을 수 없습니다. 운영이 백업에서 복구하도록 단순화되었습니다. 즉, 오랜 다운타임이 발생합니다.

또 다른 방법은 운영 백업 (및 로그 전송) 을 새 인스턴스로 복구할 수 있는 충분한 디스크 공간이 있는 경우 SQL Server 의 두 인스턴스를 모두 SAN 에 배치하는 것입니다. 그런 다음 위에서 설명한 단계에 따라 계속 진행할 수 있습니다. 그러나 마이그레이션이 완료되면 이전 인스턴스에서 사용하는 SAN 자원을 확보할 수 있는 방법이 있습니다. 디스크를 추가하기만 하면 됩니다.

로드 밸런싱

MSCS 클러스터가 로드 밸런싱이 아닌 고가용성에 사용된다는 일반적인 오해를 폭로합시다. 또한 SQL Server 에는 자동 로드 밸런싱 기능이 내장되어 있지 않습니다. 애플리케이션의 물리적 설계를 통해 로드 밸런싱을 수행해야 합니다. 그게 무슨 뜻이에요?

테이블이 증가함에 따라 특히 테이블 스캔 작업 시 성능이 저하될 수 있습니다. 행 수가 수백만 또는 수십억 개에 이르면 기존 솔루션은 union ALL 을 통해 연결된 동일한 구조의 여러 테이블로 구성된 파티션 뷰를 사용합니다. 또한 검사 제약 조건이 적절한 위치에 배치되어 멤버 테이블을 구별합니다. 이렇게 하면 파티션 뷰 간에 데이터가 복제되지 않습니다. CHECK 구속조건에 사용된 열이 기본 키의 일부인 경우 뷰를 업데이트할 수 있습니다.

멤버 테이블이 해당 파일 그룹에 있고 해당 파일 그룹의 파일이 서로 다른 물리적 드라이브에 있는 경우 디스크 성능이 향상됩니다. 이러한 테이블은 서로 다른 데이터베이스에 있을 수도 있지만 SQL 서버에서는 모든 데이터가 동일한 데이터베이스에 있는 한 테이블 분할을 사용할 수 있으며 테이블 분할은 훨씬 쉽게 구현할 수 있습니다.

그러나 테이블 파티션 또는 (로컬) 파티션 뷰를 최대한 활용했지만 성능이 여전히 낮다고 가정합니다. SQL Server 또는 SQL Server 가 있는 경우 분산 파티션 뷰를 사용할 수 있습니다. 주요 차이점은 멤버 테이블이 서로 다른 SQL Server 인스턴스에 있을 수 있고 N+ 클러스터에 설치할 수 있다는 것입니다. 왜 네가 이렇게 하도록 격려하느냐? 분할 뷰의 멤버 테이블이 오프라인인 경우 전체 뷰도 오프라인이 되므로 이러한 멤버를 클러스터의 일부로 만들면 성능 지원 및 로드 밸런싱에 필요한 신뢰성을 제공할 수 있습니다.

클러스터가 정말 필요한가요?

유휴 상태의 예비 서버가 있을 수도 있지만, 이러한 서버는 Windows 디렉토리의 클러스터 부분에 있지 않습니다. 이러한 서버를 사용할 수 있을 때 클러스터를 지원하기 위해 새 서버를 사러 나가야 하는 것은 낭비적이고 수치스러운 행위입니다.

데이터베이스 미러링은 클러스터를 대체하는 가장 적합한 방법일 수 있습니다. 대칭에는 세 가지 피쳐가 포함됩니다. 미러링된 데이터베이스의 인스턴스를 마스터 데이터베이스라고 합니다. 백업 서버를 미러 서버라고 합니다. 자동 장애 조치를 위해서는 증인 서버라는 세 번째 서버가 필요합니다. 간단히 말해 마스터 데이터베이스의 트랜잭션은 미러에서 다시 실행됩니다. 주체가 실패할 때 증거 데이터베이스가 있을 경우 자동으로 미러로 장애 조치됩니다. 각 응용 프로그램 데이터베이스에 대해 미러를 설정해야 하지만 시스템 데이터베이스는 미러링할 수 없습니다.

미러는 SQL Server 의 독립 실행형 인스턴스입니다. 클러스터와 달리 미러는 수천 마일 떨어진 곳에 있을 수 있으며 마스터에서 트랜잭션을 복제하므로 캐시가 업데이트 작업으로 가득 차 있습니다. 물론 호스트에서 미러 트랜잭션을 수신하는 것 외에 미러에 다른 활동이 없다고 가정할 수 있습니다. SQL Server 가 이미 미러에서 실행 중이기 때문에 장애 조치 속도는 일반적으로 클러스터보다 빠릅니다. 일부 캐시는 이미 준비되었기 때문에 초기 성능은 클러스터 시나리오만큼 낮지 않습니다. 또한 미러 데이터베이스가 복구될 때 마스터 데이터베이스와 미러 데이터베이스가 롤을 교환한다는 점에 유의하십시오.

데이터베이스 미러링의 단점은 필요한 총 디스크 용량이 클러스터의 두 배라는 것입니다. 동기화 모드에서 실행 하 고 데이터 손실을 원하지 않는 경우 더 많은 CPU 처리 능력이 필요 합니다. 내가 말했듯이, 고가용성을 달성하는 것은 매우 비싸다.

조합 방법

미러링과 주체 사이의 거리가 상당히 길어질 수 있으므로 재해 복구 (DR) 계획에서 미러 클러스터를 첫 번째 방어선으로 선택하는 것이 현명합니다. 하지만 클러스터와 미러를 모두 사용하면 어떻게 됩니까? 클러스터 장애 조치에서 미러 구성에 증인 서버가 있는 경우 클러스터 SQL Server 가 온라인 상태일 때 미러 서버가 마스터 서버가 되지만 새 마스터 서버에서 새 미러 서버로의 장애 조치는 자동이 아니므로 클러스터와 함께 사용할 때 미러 데이터베이스에 대해 자동 장애 조치를 활성화하지 않는 것이 좋습니다.

재해 복구 만이 미러를 사용하는 유일한 이유는 아닙니다. 미러링은 서비스 팩 또는 패치를 마스터에 적용해야 하는 경우에도 유용합니다. 이 경우 수동으로 미러로 장애 조치를 수행할 수 있습니다. 서비스 팩 또는 패치를 적용하면 이전 마스터 서버가 일시적으로 오프라인이 되고 새 마스터에서 발생한 커밋된 트랜잭션이 새 미러 (이전 마스터) 로 다시 전송될 때까지 대기합니다. 서비스 팩 또는 패치가 설치되면 동기화됩니다. 결국 두 서버가 완전히 동기화됩니다. 이제 주체와 미러 간에 역할을 교환할 수 있습니다. 페일오버 및 복구에는 단 몇 초 만에 다운타임이 발생합니다. 이 방법을 사용하여 SQL Server 를 다른 컴퓨터로 마이그레이션할 수 있지만 장애로부터 복구할 수는 없습니다.

가상 서버의 유연성 향상

가상화를 사용하면 하나의 물리적 서버에서 하나 이상의 운영 체제를 동시에 실행할 수 있습니다. 가상화 소프트웨어는 클러스터에 소프트웨어를 추가할 수 있기 때문에 클러스터 개념에 또 다른 기능을 추가합니다. 따라서 호스트를 실행하는 서버에 장애가 발생할 경우 호스트 및 게스트 운영 체제가 백업 노드로 페일오버되는 것이 게스트 서버를 마이그레이션하는 가장 쉬운 방법일 수 있습니다. 또한 게스트 운영 체제에는 클러스터링 기능이 필요하지 않으므로 Microsoft 가상 서버에서 실행되는 게스트 Windows 서버에서 SQL Server Workgroup Edition 을 실행할 수 있습니다. 이는 실제로 클러스터 Workgroup Edition 을 간접적으로 보유하고 있음을 의미합니다.

통제 하에 있다

SQL Server 구현을 담당하는 경우 서버를 항상 사용할 수 있는지 확인해야 합니다. 서버 클러스터는 서버를 항상 사용할 수 있도록 하는 데 도움이 됩니다. 이 글은 네가 시작하는 데 도움이 되는 몇 가지 어려운 기교를 제공한다. 클러스터 리소스의 사이드바에서 더 유용한 정보를 찾을 수 있습니다.

Lishi Xinzhi/article/program/SQL server/201311/22476