한 서버 시스템에 장애가 발생하더라도 데이터베이스 백엔드로 데이터베이스 백엔드를 사용할 수 있으므로 SQL Server 2012를 사용하는 응용 프로그램을 확인해야한다고 가정합니다.
DBA가 아닌 개발자로서 장애 조치 / 고 가용성에 어떤 시나리오를 사용해야하는지 이해하기 위해 고심하고 있습니다.
각 시나리오 중 어떤 시나리오가 어떤 종류의 워크로드에 작동하며, 이러한 시나리오로 처리 할 수있는 장애 / 정지 유형은 무엇입니까? 그것들은 비교 가능하고 교환 가능합니까?
답변:
항상 고 가용성 솔루션을 시각화하는 방법은 다음과 같습니다.
고 가용성이란 무엇입니까? 전체 인스턴스 여기에는 모든 서버 개체 (로그인, SQL Server 에이전트 작업 등)가 포함됩니다. 여기에는 데이터베이스 및 포함 엔티티도 포함됩니다. 고 가용성 SQL Server 인스턴스에 적합한 솔루션입니다.이 솔루션이 포함 된 수준으로 유지되기 때문입니다.
보고는 어떻습니까? 없음, NULL, 존재하지 않습니다. 장애 조치 클러스터 인스턴스에는 인스턴스, VNN 등을 포함하는 클러스터 그룹을 제공하는 활성 노드가 있으며 다른 모든 노드는 수동적이며 유휴 상태 (현재 클러스터 그룹에 관한 한)에 있고 장애 조치를 기다리고 있습니다.
장애 조치가 발생하면 어떻게됩니까? FCI의 중단 시간은 수동 노드가 클러스터 리소스를 가져 와서 SQL Server 인스턴스를 실행 상태로 만드는 데 걸리는 시간에 따라 결정됩니다. 일반적으로 시간이 최소화됩니다.
클라이언트 추상화? 예. 장애 조치 클러스터 인스턴스의 가상 네트워크 이름으로 기본 제공됩니다. 항상 현재 SQL Server 클러스터 리소스를 제공하는 활성 노드를 가리 킵니다.
고 가용성이란 무엇입니까? 가용성 그룹은 여기서 고 가용성을 논리적으로 포함하는 반면 가용성 그룹은 여러 데이터베이스와 가상 네트워크 이름 (리스너, 선택적 클러스터 리소스)으로 구성됩니다. 로그인 및 SQL Server 에이전트 작업과 같은 서버 개체는 HA 솔루션의 일부가 아니며 가용성 그룹으로 올바르게 구현되도록 특별히 고려해야합니다. 지나치게 부담이되는 요구 사항은 아니지만주의를 기울여야합니다.
보고는 어떻습니까? 아마도보고 복제본으로 동기 복제본을 사용하지 않더라도보고를위한 훌륭한 솔루션입니다. 동기 및 비동기의 두 가지 확약 관계가 있습니다. 제 생각에 실제로 본 것은 동기 보조 복제본이 재난을 기다리고 있다는 것입니다. 문제 발생시 데이터 손실없이 장애 조치를 수행 할 준비가 된 복제본으로 생각하십시오. 그런 다음 해당보고 워크로드를 처리 할 수있는 비동기 복제본이 있습니다. 이 복제본을 위에서 언급 한 솔루션으로 사용하지 않고보고와 같은 용도로 사용합니다. 보고 워크로드는이 복제본을 가리킬 수 있습니다 (리스너를 통한 읽기 전용 라우팅을 통해 직접 또는 간접적으로).
장애 조치가 발생하면 어떻게됩니까? 자동 장애 조치와 쌍을 이루는 동기 커밋 보조 복제본의 경우 복제본 역할 상태가 SECONDARY_NORMAL에서 PRIMARY_NORMAL로 변경됩니다. 자동 장애 조치가 이루어 지려면 현재 동기화 된 동기 보조 복제본 이 있어야하며 실제로 장애 조치가 발생할시기를 결정 하는 탄력적 장애 조치 정책 이 구현 됩니다. 이 정책은 실제로 구성 가능합니다.
클라이언트 추상화? 예, 선택적으로 AlwaysOn 가용성 그룹 수신기를 구성 할 수 있습니다. 기본적으로 현재 기본 복제본을 가리키는 가상 네트워크 이름 (AG 클러스터 그룹에서 클러스터 리소스로 WSFC를 통해 볼 수 있음)입니다. 이는 읽기 전용 트래픽을 리디렉션하려는 서버에서 읽기 전용 라우팅 목록을 설정하고보고 워크로드를 전환하는 데 중요한 부분입니다 (SQL 용 .NET Framework Provider를 사용하여 연결 문자열을 통해 설정 됨) 서버, 이것은 Application Intent 매개 변수이며 ReadOnly로 설정됩니다 . 보조 복제본 역할을 수행하는 동안이보고 작업을 수신하려는 각 복제본에 대해 읽기 전용 라우팅 URL을 설정해야합니다.
고 가용성이란 무엇입니까? 이것은 논쟁의 여지가 있지만, 아무 말도하지 않을 것 입니다. 복제를 고 가용성 솔루션으로 보지 못했습니다. 예, 데이터 수정이 가입자에게 제공되고 있지만 출판 / 문서 수준에서 논의 중입니다. 이것은 데이터의 하위 집합이 될 것입니다 (모든 데이터를 포함 할 수는 있지만 시행되지는 않습니다. 즉 게시자 데이터베이스에 새 테이블을 만들고 구독자에게 자동으로 푸시되지는 않습니다). HA가 진행되는 한, 이것은 배럴의 최하위이며, 견고한 HA 솔루션으로 그룹화하지는 않을 것입니다.
보고는 어떻습니까? 데이터 하위 집합에 대한보고를위한 훌륭한 솔루션입니다. 트랜잭션이 많은 1TB 데이터베이스가 있고 해당보고 작업 부하를 OLTP 데이터베이스에서 유지하려면 트랜잭션 복제를 사용하여보고 작업 부하를 위해 데이터의 하위 집합을 구독자 (또는 구독자)에게 푸시 할 수 있습니다. 1TB의 데이터 중보고 작업량이 50GB에 불과하면 어떻게됩니까? 이 솔루션은 현명한 솔루션이며 비즈니스 요구를 충족하도록 비교적 구성 할 수 있습니다.
요약하자면 (부분적으로 비즈니스에서) 대답해야 할 몇 가지 질문이 있습니다.
Windows 장애 조치 클러스터의 두 개 이상의 서버, 클러스터 된 인스턴스 인 SQL Server
어떤 종류의 작업량? "의존"-그러나 이것은 데이터 센터 고 가용성에 로컬이 필요한 온라인 애플리케이션에 유용합니다. 하나의 시스템 또는 하나의 운영 체제의 장애로부터 보호됩니다. 로그인, 작업, 새 데이터베이스, 유지 관리 등은 모두 동일한 스토리지를 공유하는 동일한 두 노드가있는 클러스터이므로 모두 동일한 시스템 데이터베이스를 갖기 때문에 자동으로 동기화됩니다. 장애 조치는 매우 빠르지 만 장애 조치가 발생할 때 여전히 SQL Server를 다시 시작하는 것처럼 보이는 딸꾹질이 있습니다.
단점 / 문제 -단일 실패 지점은 스토리지와 모든 구성 요소입니다. SAN 공급 업체는 항상 "SAN을 실패하지 않는다"하지만, 스토리지 영역 네트워크에서 움직이는 부분이 많이있다라고 나는에 대한 블로그로 여기에 , 그들은 할 수 있습니다. 또한-당신은 아무것도 할 수없고 걸어서 기다릴 수있는 2 차 서버에 대한 비용을 지불하고 있습니다. 이제 액티브 / 액티브 / 멀티 노드를 수행 할 수 있고 두 방향으로 장애 조치를 수행하고 두 번째 노드를 사용할 수있는 두 개의 활성 인스턴스를 가질 수 있습니다.
자동 장애 조치? "가장"자동입니다. 증인이 필요하지 않으며 클러스터입니다. 이것은 가능한 한 매끄럽게 만드는 클러스터의 역할입니다. 이제 이들 중 어떤 것이라도 장애 조치가 발생하면 SQL을 시작하거나 연결을 가리켜 야하기 때문에 장애를 느끼게됩니다. 이 상황이 발생하면 기본적으로 SQL이 다시 시작되는 것처럼 느껴지고 DB가 백업되어 복구 등을 실행합니다.
클라이언트에 다운 타임에 대한 허용 오차가 매우 낮기 때문에 로컬 데이터 센터의 고 가용성 환경에서 "모든 데이터베이스, 모든 로그인 등을 완벽하게 유지하고 싶습니다"라고 말하면 장애 조치 클러스터 인스턴스를 고려해야합니다. 마지막으로 언급 한 옵션은 강력한 경쟁자이며 일부 관리 오버 헤드를 수행하지 않아도됩니다). 사이트 오류나 SAN 오류로부터 보호하기 위해 로컬 FCI와 AG 비동기 보조를 수행 할 것입니다.
트랜잭션 복제를 통해 최신 상태로 유지되는 두 개 이상의 SQL Server 인스턴스
동기 커밋 모드로 구성된 SQL Server 가용성 그룹의 두 개 이상의 SQL Server
이것이 사람들이 점점 더 최근에 구현하도록 돕고 있지만 때로는 여전히 클러스터링에갑니다.
요약
HA와 DR은 다릅니다. 그리고이 기술들은 둘 중 하나를 제공하는 데 도움이됩니다. 고 가용성이란 한 시스템에 문제가 발생하면 복구 지점 목표 및 복구 시간 목표가 짧다는 것을 신속하게 복구 할 수 있음을 의미합니다. 그것은 클러스터링과 동기식 AG입니다.
재해 복구는 "HA 솔루션에서도 장애가 발생했을 때 일어날 수 있습니다. 다른 데이터 센터, 미러링 또는 복제로 갈 때 AG가 될 수 있습니다.
공유 대상 을 고려하는 것도 중요합니다 .
장애 조치 클러스터링은 하나의 디스크 배열을 공유하는 둘 이상의 서버 노드를 사용합니다 . 디스크 어레이가 다운되면 서버 노드 수에 관계없이 서비스가 손실됩니다. 해당 디스크 어레이가있는 서버 실에서 화재 나 홍수가 발생하면 서비스를 잃게됩니다.
AlwaysOn 가용성 그룹 및 데이터베이스 미러링은 "공유 없음"클러스터링 기술입니다. 데이터베이스는 여러 서버의 여러 디스크 배열에 있습니다. 네트워크 연결 상태가 양호하면 여러 서빙이 여러 서버 실에있을 수있어 화재 나 홍수로부터 사용자를 보호 할 수 있습니다.
완전성을 위해 일반 오래된 미러링을 사용하는 옵션이 있습니다. 가용성 그룹 사용의 복잡성과 장애 조치 (failover) 클러스터링을위한 공유 저장소가 필요없는 두 개의 데이터베이스 복사본이 여기에 있습니다. 단점은 미미하지만 미러링은 더 이상 사용되지 않습니다.
응용 프로그램 코드는 장애 조치시 발생하는 모든 트랜잭션을 다시 시도 할 수 있어야하지만 미러링을 사용한 장애 조치 시간은 10 초 정도입니다.