핫 스페어 호스트와 콜드 스페어 호스트?

동일한 핫 스페어 호스트가있는 여러 호스트가 있으며 패치 및 업데이트되므로 동일한 소프트웨어 및 구성에 매우 가깝습니다. 장애가 발생하면 네트워크 케이블이 전환되고 DHCP 서버가 새 MAC 주소로 업데이트됩니다. 일반적으로 수정이 필요한 것이 더 많기 때문에 이것이 가장 좋은 경우입니다.

핫 스페어 호스트를 유지하는 데 전력 낭비와 유지 관리에 시간 낭비가 있다고 생각하고 장애 조치의 경우 구성 수정이 필요하기 때문에 다음을 묻고 싶습니다.

핫 스페어 호스트는 구식이며 더 좋은 방법이 있습니까?

핫 스페어 호스트를 갖는 대신 콜드 스페어를 만들고 하드 드라이브를 가져와 기본 호스트에 넣고 RAID를 1에서 1 + 1로 변경하는 것이 좋습니다. 장애가 발생하면 네트워크 케이블을 변경하고 DHCP 서버를 업데이트하고 하드 드라이브를 가져와 콜드 스페어에 넣고 전원을 켜면됩니다. 내가 알다시피 이점은 2x2 디스크가 항상 동기화되어 있기 때문에 하나의 호스트 만 유지 관리하고 페일 오버시 구성 변경이 필요하지 않다는 것입니다.

좋은 생각입니까?

Sobrique는 수동 개입을 통해 제안 된 솔루션이 어떻게 최적의 상태를 유지하는지 설명 하고 ewwhite는 다양한 구성 요소의 고장 가능성에 대해 설명합니다 . 이 두 가지 IMO는 매우 좋은 지적을하므로 강력히 고려해야합니다.

그러나 아무도 지금까지 전혀 언급하지 않은 것처럼 보이는 한 가지 문제가 있습니다. 당신은 제안합니다 :

[현재 핫 스페어 호스트]를 콜드 스페어로 만들고 하드 드라이브를 가져 와서 기본 호스트에 넣고 RAID를 1에서 1 + 1로 변경합니다.

이렇게하면 OS가 디스크에서 수행하는 작업으로부터 보호 할 수 없습니다.

미러 (RAID 1)에서 미러 미러 (RAID 1 + 1)로 이동하면 디스크 장애로부터 사용자를 보호 할 수 있습니다. 각 미러 세트의 디스크 수를 늘리면 (예 : 2 디스크 RAID 1에서 4 디스크 RAID 1로 이동) 일반적인 작업 중에 읽기 성능이 크게 향상 될 수 있습니다.

그렇다면 이것이 실패 할 수있는 몇 가지 방법을 살펴 보자 .

• 시스템 업데이트를 설치하는 중이고 프로세스가 도중에 실패한다고 가정 해 봅시다. 어쩌면 거기의 전원 및 UPS 장애 (리눅스는 요즘 꽤 안정적이지만, 아직 거기 위험), 또는 어쩌면 당신은 괴물 사고를하고 타격 커널의 버그를했다.
• 업데이트로 인해 기본 시스템을 수정하는 동안 보조 시스템으로 장애 조치를 수행해야하는 테스트 중 테스트하지 않은 문제 (시스템 업데이트 테스트를 수행 할 수 있습니까?)가 발생할 수 있습니다.
• 파일 시스템 코드의 버그로 인해 디스크에 잘못된 쓰기가 발생할 수 있습니다.
• 어쩌면 뚱뚱한 (또는 악의적 인) 관리자가 rm -rf ../*또는 rm -rf /*대신 했을 수도 rm -rf ./*있습니다.
• 자체 소프트웨어의 버그로 인해 데이터베이스 내용이 크게 손상 될 수 있습니다.
• 바이러스가 몰래 침입했을 수도 있습니다.

어쩌면 어쩌면 어쩌면 ... (그리고 당신의 제안 된 접근법이 실패 할 수있는 더 많은 방법이 있다고 확신합니다.) 그러나 결국 이것은 "두 세트는 항상 동기화되어 있습니다" "이점"으로 귀결됩니다. 때로는 완벽하게 동기화 되기를 원하지 않습니다.

정확히 무슨 일이 있었는지에 따라 핫 또는 콜드 스탠바이를 켜고 다시 켜거나 적절한 백업을 원할 때입니다. 어느 쪽이든 장애 미러 모드 (또는 RAID 미러)는 장애 모드에 하드웨어 스토리지 장치 장애 (디스크 충돌) 외에 많은 것이 포함되어 있으면 도움이되지 않습니다. ZFS의 raidzN과 같은 것은 일부 측면에서 조금 더 나을 수 있지만 다른 측면에서는 전혀 나을 수는 없습니다.

나에게 이것은 의도가 어떤 종류의 재난 장애 조치 인 경우 제안 된 접근 방식을 처음부터 무용지물로 만들 것입니다.

예, 조금 오래된 학교입니다. 최신 하드웨어는 자주 실패 하지 않습니다 . 응용 프로그램의 가용성을 높이거나 (항상 가능한 것은 아님) 개별 호스트의 복원력을 높이는 데 필요한 항목에 집중하십시오.

호스트 :

• 더 나은 하드웨어를 구입하십시오.
• 지원 계약이 있는지 확인하십시오.
• 서버의 지원 계약을 등록 하십시오 (예비 부품은 등록 데이터를 기반으로 현지에 재고가 있습니다!)
• 중복 전원 공급 장치 (하드웨어?) RAID, 중복 팬을 사용하십시오.
• 서버가 위의 중복 기능을 수용 할 수없는 경우, 장애 발생시 자체 수리 할 수 ​​있도록 예비 섀시 또는 구성 요소를 준비하십시오.

고장 빈도를 줄이려면 디스크, RAM, 전원 공급 장치, 팬이 가장 자주 나타납니다. 때때로 시스템 보드 또는 CPU. 그러나 마지막 두 가지는 지원 계약이 시작되는 곳입니다.

스위치를 만들기 위해 수동 개입에 의존하기 때문에 오히려 비효율적입니다.

나는 핫 DR 사이트를 운영하는 곳에서 일했습니다. 말 그대로 기본 서버와 동일한 서버로 즉시 이동할 수 있습니다. 그러나 DR 전환은 자동화 된 프로세스입니다. 우리는 케이블 연결, 약간의 조정 및 스위치가 아니라 버튼을 누를 때의 프로세스가 한 사이트에서 다른 사이트로 모든 것을 뒤집습니다.

이 접근 방식은 비용이 많이 들지만 비즈니스 결정입니다. 허용 가능한 위험 대 목표를 달성하는 데 필요한 비용. 일반적으로 복구 시간 목표에는 지수 곡선이 있습니다. 0에 가까울수록 비용이 많이 듭니다.

그러나 그것이 당신의 질문에 관한 것입니다. 무엇 입니다 복구 시간 목표, 그리고이를 달성하는 가장 효과적인 방법은 무엇입니까. 서버 부팅을 기다리는 데 몇 분이 걸립니다. 오전 4시에 튀어 나올 때 조정 및 '복구 작업'을 수행하는 데 얼마나 걸립니까?

수용 가능한 정전은 얼마나 걸립니까?

'핫 복구'를 수행하는 경우 클러스터링을 생각하고 싶습니다. 물리적 인 경우에도 VMWare를 '장애 조치 (failover over)'하면 VMWare를 충분히 사용하여 클러스터링을 상당히 저렴하게 할 수 있습니다. 즉, 중복 하드웨어를 실행하고 있지 않습니다. (2N이 아닌 N + 1).

RTO가 충분히 길면 상자를 끄십시오. 백업에서 콜드 리빌드를 수행하기에 RTO가 충분하다는 것을 알 수 있습니다.

그것이 오래된 학교라는 사실이 반드시 핫 스페어를 나쁜 생각으로 만드는 것은 아닙니다.

가장 큰 관심사는 이론적 근거, 실행 위험, 핫 스페어 실행이 어떻게이를 완화 시키는가에 있습니다. 내 생각에 핫 스페어는 하드웨어 고장 만 해결하기 때문에 드물지는 않지만 운영상의 유일한 위험 요소는 물론 다른 가능성도 없습니다. 두 번째 관심사는 대체 전략이 더 많은 위험 감소 또는 상당한 비용 절감을 제공한다는 것입니다.

여러 수동 페일 오버 단계로 핫 스페어를 실행하면 시간이 오래 걸리고 잘못 될 가능성이 있지만 HA 클러스터 제품군이 주요 클러스터 요소로 바뀌면 자동 장애 조치가 수행되는 것 같습니다.

또 다른 것은 같은 위치에있는 냉온 대기가 지역 재난 발생시 비즈니스 연속성을 제공하지 않는다는 것입니다.

핫 스페어 또는 콜드 스페어를 갖는 개념은 애플리케이션이 처음 구축되는 방식 에 따라 다릅니다 .

내 말은 데이터와 서비스로드가 여러 시스템에 분산되는 방식으로 애플리케이션을 구축 한 경우 시스템을 중단시키는 단일 시스템의 개념이 사라져야한다는 것입니다. 이러한 상황에서는 핫 스페어가 필요하지 않습니다. 대신 개별 기계 / 구성 요소가 죽을 때 처리 할 수있는 충분한 용량이 필요합니다.

예를 들어 표준 웹 응용 프로그램에는 일반적으로 웹 서버와 데이터베이스 서버가 필요합니다. 웹 서버의 경우로드 밸런스가 2 이상입니다. 사람이 죽어도 큰 일이 없습니다. 데이터베이스는 참여하는 시스템에서 모든 데이터를 동기화하여 다중 마스터로 설계해야하기 때문에 일반적으로 더 어렵습니다. 따라서 단일 DB 서버 대신 데이터 요구를 모두 처리하는 2 이상이 필요합니다. 구글, 아마존, 페이스 북 등과 같은 대규모 서비스 제공 업체들이이 길을 갔다. 개발 시간에는 선결제 비용이 더 많이 들지만 규모를 확장해야하는 경우 배당금을 지불합니다.

이제 응용 프로그램이 그런 식으로 구성되지 않았거나 단순히 응용 프로그램을 레트로 핏하는 것이 금지 적이라면 예를 들어 핫 스페어를 원할 것입니다.