2노드 Hyper-V 2012 클러스터를 처음 설정했을 때 장애 조치가 거의 즉각적으로 이루어졌습니다. 8GB RAM이 할당된 Sql Server 2012(Win2012) VM이 있습니다. 나는 그것이 살고 있는 노드를 반송할 수 있었고 SQL 연결을 끊지 않고 다른 노드로 점프할 것입니다.
그런 다음 역시 8GB의 두 번째 VM을 클러스터(첫 번째 VM의 복제본)에 추가했습니다. 이제 장애 조치에 몇 초가 걸리고 SQL 연결이 재설정됩니다. 이동해야 하는 RAM 양의 요인인가요? 네트워크의 영향을 받나요? 쿼럼 디스크의 속도인가요?
제 경우에는 두 노드가 모두 동일한 DAS에 연결되어 있으며 VM 파일은 CSV에 있습니다. 이동할 필요가 없으므로 디스크는 문제가 되지 않을 것으로 예상됩니다. 모두 RAM이어야겠죠? 그렇다면 RAM이 증가하면 장애 조치 성능이 감소합니까?
답변1
돌이켜보면 진작 알았어야 했던 것 같아요. 대답은 두 부분으로 나누어져 있습니다. 제 생각에는 계획된 장애 조치와 "실제"/계획되지 않은 장애 조치가 있고 계획된 장애 조치는 포함되지 않기 때문입니다.
계획된 장애 조치
계획된 장애 조치는 실제로 클러스터링 시스템이 노드를 비운 다음 다시 부팅하는 것입니다. 따라서 RDP 또는 클러스터링 앱 GUI의 "클러스터 서비스 중지"를 통해 노드를 직접 재부팅하면 가장 먼저 VM이 실시간 마이그레이션 해제됩니다. 실제로 VM을 실시간 마이그레이션하는 것이므로 소요되는 시간은 전송해야 하는 항목과 네트워크 연결에 따라 달라집니다. 1Gb NIC가 있는 경우 시간이 좀 걸립니다(~118MB/초). VM에 RAM이 많을수록더 빠른 NIC를 통해 더 나은 서비스를 받을 수 있습니다..
실제 장애 조치
계획되지 않은/"실제" 장애 조치는 컴퓨터의 플러그를 뽑을 때 발생합니다. 이 경우 클러스터 시스템은 자동으로 다른 노드에서 VM을 시작합니다. 외부 세계에 대한 동작은 VM을 재부팅한 것과 동일합니다. VM의 경우 "껐다가" 다시 시작한 것과 같습니다. 따라서 "실제" 장애 조치는 항상 VM을 부팅하는 데 걸리는 시간에 관한 것입니다.
접선
이것은 개념적으로 저에게 실망스러운 일입니다. 왜냐하면 Net의 모든 클러스터링 대화에서는 ("하드") 노드 오류가 클러스터링 시스템에 의해 숨겨져 있다고 제안하고 있기 때문입니다. 내려갔다. 내가 읽은 것을 기억하는 모든 웹 페이지가 소프트웨어에서 클러스터 장애 조치(계획된 장애 조치)를 테스트했다는 사실에 의해 전파되었을 가능성이 높습니다. 따라서 그들이 실제로 하고 있는 일은 Live Migration이 광고된 대로 작동한다는 것(클라이언트의 관점에서 볼 때 가동 중지 시간 없음)을 입증하는 것뿐입니다.
나의 주요 실수는 장애 조치 자체를 오해한 것입니다. 핫 서버에서 자동 장애 조치가 발생하는 핫/웜/콜드 백업 서버 개념 외에도 핫/웜/콜드 장애 조치도 있습니다. 말한 바와 같이여기, 핫 장애 조치는 즉각적이고, 웜 장애 조치는 초 단위로 측정되며, 콜드 장애 조치는 분 단위로 측정됩니다. 나는 모든 자동 실패가 "핫"하다고 가정하는 것이 순진했습니다. 나는 클러스터가 다른 노드에 있는 VM의 RAM 복사본을 업데이트하는 RAM에 일종의 마법을 기대했던 것 같습니다. SQL Server를 통한 트랜잭션 로그 전달과 같은 것입니다. 그러나 이를 위해서는 작동을 보장하기 위해 최소한 RAM만큼 빠른 시스템 간의 통신 채널이 필요합니다.