☰

Hyper V의 SQL 클러스터링 - 클러스터 내의 클러스터는 이점이 있습니다.

tag-icon • tag-icon sql-server-2008 windows-server-2008-r2 cluster
Hyper V의 SQL 클러스터링 - 클러스터 내의 클러스터는 이점이 있습니다.

이것은 다음의 재해시입니다.질문나는 얼마 전에 물었습니다. 컨설턴트가 부서의 다른 팀에 아이디어를 제시한 후 전체 문제가 다시 제기되었으므로 더 자세한 답변을 찾고 있습니다.

우리는 각 SQL 인스턴스에서 다양한 시스템을 실행하는 여러 물리적 블레이드에 걸쳐 다중 인스턴스 SQL 클러스터를 설정할 계획입니다. 일반적으로 각 VM 호스트에서는 하나의 가상 SQL 인스턴스가 실행됩니다. 다시 말하지만, 일반적인 작업에서는 각 VM 호스트가 전용 기본 블레이드에서 실행됩니다. 이 설정은 필요에 따라 장애 조치할 수 있는 모든 SQL 인스턴스를 갖춘 개별 VM 또는 기본 블레이드의 유지 관리에 많은 유연성을 제공해야 합니다.

내 원래 계획은 다음을 수행하는 것이었습니다.

  1. 각 블레이드에 2008 R2 설치
  2. 각 블레이드에 Hyper V 추가
  3. 각 블레이드에 2008 R2 VM 설치
  4. VM 내에서 장애 조치(failover) 클러스터를 만든 다음 SQL Server 클러스터링을 설치합니다.

컨설턴트는 대신 다음을 수행할 것을 제안했습니다.

  1. 각 블레이드에 2008 R2 설치
  2. 각 블레이드에 Hyper V 추가
  3. 각 블레이드에 2008 R2 VM 설치
  4. 모든 VM을 호스팅할 HOST 시스템에 클러스터를 만듭니다.
  5. VM 내에서 장애 조치(failover) 클러스터를 만든 다음 SQL Server 클러스터링을 설치합니다.

가장 큰 차이점은 모든 게스트 VM도 클러스터링하는 4단계가 추가되었다는 것입니다. SQL 클러스터와 물리적 하드웨어 사이에 전혀 연결이 없기 때문에 유지 관리가 더욱 향상된다는 주장이 있습니다. 이론적으로는 SQL 클러스터에 전혀 영향을 주지 않고 호스트 주변의 게스트 VM을 실시간 마이그레이션할 수 있으므로 일상적인 유지 관리를 위해 물리적 블레이드를 중단하지 않고 장애 조치 없이 SQL 클러스터를 이동합니다.

좋은 아이디어처럼 들리지만 인터넷에서 사람들이 이 작업을 수행했고 제대로 작동한다고 말하는 내용을 본 적이 없습니다. 실제로 호스트된 SQL 클러스터 없이 게스트의 실시간 마이그레이션을 수행할 수 있습니까?

누구든지 이 설정에 대해 좋은 경험이 있거나 나쁜 경험이 있습니까? 제가 고려하지 않은 장점과 단점이 있나요?

미러링도 고려해야 할 귀중한 옵션이라는 점에 감사드립니다. 이 경우 클러스터링이 각 인스턴스 전체를 수행하고 데이터베이스 수가 많기 때문에 클러스터링을 선호합니다. 일부 DB는 미러링과도 잘 작동하지 않을 수도 있는 제3자 시스템을 위한 것입니다(클러스터링에 대한 제가 이해한 바는 장애 조치가 클라이언트에게 완전히 투명하다는 것입니다).

감사해요.

답변1

해당 블레이드가 SQL Server 실행에만 전념한다면 가상화에 신경을 쓰는 이유는 무엇입니까?

추가적인 가상화 오버헤드 없이 간단히 Windows Server와 SQL Server를 각각 설치하고 그에 따라 클러스터를 설정하면 어떨까요?

답변2

복잡해 보이네요.

나는 표준 물리적 클러스터 SQL 서버 구현의 안정성과 상대적 단순성을 통해 솔루션의 "복잡성"을 평가해야 할 것입니다.

모든 데이터베이스가 미션 크리티컬합니까? 내 경험상 일반적으로 그렇지 않기 때문에 가장 중요한 데이터베이스는 완전한 복원력을 갖춘 서버에 호스팅하고 나머지(보통 많은 부분)는 간단한 SQL 서버에 호스팅하는 경향이 있습니다.

이를 통해 가장 중요한 시스템을 가동하고 실행하는 데 집중할 수 있으며 "공중의 모든 공을 동시에" 유지하려고 노력할 필요가 없습니다.

모든 서버에는 정기적인 정기 유지 관리가 필요합니다. 보안 패치의 규칙성과 심각성, 중요성을 고려하여 우리는 이론적인 99.999999999999999999999999999999999999999999999989999999999999999999999999999999999999999999999999999999999999999999KB 가동 시간을 유지하려는 노력에서 벗어나 보다 현실적인 "서버를 안전하게 유지할 것입니다"로 전환했습니다. 안전합니다. 하지만 서버에 적절한 패치를 유지할 수 있도록 필수 유지 관리 기간이 짧아질 것입니다."

답변3

나열된 옵션 중 #2를 선택하지만 SQL을 클러스터링(5단계)하지 않을 것입니다. 왜냐하면 SQL을 클러스터링하면 얻을 수 있는 이점이 별로 없기 때문입니다. Hyper-V 클러스터링을 사용하면 이미 두 호스트 모두에서 해당 VM을 실행할 수 있으므로 하드웨어 오류가 발생할 경우를 대비할 수 있습니다.

SQL 로그 및 데이터베이스 볼륨에 고정 크기 VHD를 사용할 계획이라고 가정합니다.

저는 Hyper-V를 모두 건너뛰고 2개의 블레이드를 일반 SQL 클러스터로 사용하는 것에 대한 다른 사람들의 의견을 완전히 이해합니다. 이는 확실히 전통적인 접근 방식일 것입니다. 그러나 워크로드 가상화의 유연성 이점은 유지 관리, 업그레이드 및 하드웨어 오류에 대해 매우 큽니다. VM의 이식성은 매우 매력적입니다.

하지만 이 솔루션의 가치는 환경에 따라 달라집니다. 다른 Hyper-V 서버가 없고 직원이 Hyper-V에 대한 경험이 많지 않은 경우 가장 중요한 워크로드 중 하나를 가상화하는 것은 좋은 생각이 아닐 수 있습니다. 그러나 많은 IT 매장과 마찬가지로 덜 중요한 서버를 가상화하기 시작했고 몇 개의 호스트를 구축했으며 Hyper-V를 안정적으로 실행할 수 있는 기술과 절차를 갖추고 있다면 더 중요한 워크로드로 초점을 확장하는 것이 완전히 합리적입니다. 개인적으로 저는 SQL 수준보다는 호스트 수준에서 클러스터링을 관리하는 것을 선호하며, 아직은 일반적이지는 않지만 이 작업이 점점 더 많이 수행되는 것을 보게 될 것이라고 생각합니다.

마지막으로 Hyper-V에서 SQL 실행에 대한 질문: 예, 실시간 마이그레이션은 SQL에서 잘 작동하지만 눈치 채지 못할 것입니다. 그리고 - SQL db 미러링은 훌륭하지만 예, 보편적으로 지원되지 않으므로 모든 경우에 적합하지는 않습니다. 상황.

답변4

내 생각엔 당신 컨설턴트의 말이 맞는 것 같아요. 나 역시 그와 같은 정확한 아이디어를 갖고 있으며, 이를 현재 환경에서 구현하고 싶습니다. 물리적 하드웨어 2개, W2k8 설치 2개로 Hyper-V를 실행하는 각 하드웨어.

  1. 첫 번째 물리적 호스트에 2개의 VM을 설치합니다.
  2. 복제된 환경으로의 장애 조치를 위해 O/S 수준에서 내결함성을 설정하여 VM1에 SQL을 설치하고 VM2에 미러 또는 클러스터를 설치합니다.
  3. 두 번째 물리적 서버와 장애 조치 클러스터 Hyper-V에 W2k8을 설치합니다.

이는 SQL 환경에서 완전한 수준의 장애 조치 클러스터링 및 완전한 H/A를 제공합니다.

아니면 내 생각이 멍청한 건 아닐까?

관련 정보