홈 어시스턴트 장애 도메인: 종속성이 중단에 미치는 영향

에바 왕

IceWhale author

에바 왕 는 기술 작가 그리고 이자 ZimaSpace의 상주 장인입니다. 평생을 기술에 열정을 가진 사람으로서 홈랩과 오픈소스 소프트웨어에 열정을 가지고 있으며,복잡한 기술 개념을 쉽게 이해할 수 있는 실습 가이드로 번역하는 데 전문성을 가지고 있습니다.에바는 셀프 호스팅이 어렵지 않고 재미있어야 한다고 믿습니다. 그녀의 튜토리얼을 통해 커뮤니티가 하드웨어 설정의 신비를 풀도록돕고 있습니다. 첫 NAS 구축부터 Docker 컨테이너 마스터링까지.

Home Assistant Failure Domains: How Dependencies Shape Outages - Zima Store Online

겉보기에는 서로 독립적인 기능이라도 하나의 전원, 호스트, 스토리지, 네트워크, 인증 또는 게이트웨이 의존성을 공유하고 그 의존성이 장애를 일으키면 Home Assistant 장애 범위가 확대됩니다.

대시보드, 자동화 엔진, 데이터베이스, 브로커, 무선 코디네이터, DNS 리졸버, 모바일 클라이언트는 서로 다른 구성 요소로 실행될 수 있지만, 공통 호스트나 경로가 사라지면 함께 중단될 수 있습니다. 장애 도메인 분석은 각 가정 내 결과를 이러한 의존성을 따라 추적하고, 연쇄적으로 발생하는 손실을 식별하며, 복구 순서를 정합니다. 대체 경로가 동일한 숨은 원인을 공유하지 않을 때에만 이중화가 효과를 발휘합니다.

컨테이너가 아닌 가정 내 결과부터 시작하기

로컬 조명, 난방 안전, 경보 확인, 원격 액세스, 기록 보존과 같은 결과를 정의합니다. 각 결과에 대해 센서 또는 클라이언트에서 네트워크, Home Assistant, 통합 구성 요소, 브로커, 데이터베이스, 액추에이터까지 필요한 구성 요소를 추적합니다. 실행 중인 컨테이너라도 가정 내 결과가 여전히 장애가 발생한 게이트웨이에 의존한다면 의미가 없습니다.

고가용성 논의에서는 프로세스를 계속 실행하는 것과 자동화 경로를 계속 사용할 수 있게 유지하는 것의 차이가 반복해서 드러납니다. 이 고가용성 논의에서는 단순히 두 번째 인스턴스를 추가하는 것만으로는 해결할 수 없는 상태 동기화, 무선 소유권, 페일오버 문제를 다룹니다.

손실될 경우 결과가 바뀌는 구성 요소에서 추적을 멈춥니다. 선택적 분석 기능은 조명 제어 장애 도메인에 포함되지 않을 수 있지만, 데이터베이스 호스트 이름을 사용한다면 DNS는 필수일 수 있습니다. 이러한 경계는 전체 목록으로 인해 실제 장애를 결정하는 소수의 의존성이 가려지는 것을 막아 줍니다.

공유 인프라는 연쇄적인 손실을 만듭니다

한 호스트에 있는 두 컨테이너는 해당 호스트의 커널, 전원 공급 장치, 스토리지 컨트롤러, 그리고 대개 동일한 파일 시스템을 공유합니다. 두 호스트도 스위치, UPS, 리졸버 또는 자격 증명 제공자를 공유할 수 있습니다. 복제본은 완화하려는 장애가 모든 복제본과 선택에 필요한 조정 데이터를 제거하지 않을 때에만 위험을 줄입니다.

실용적인 Home Assistant 클러스터링 설계는 실제 페일오버에 필요한 계층의 수를 보여 줍니다. 이 복제 클러스터 설계는 복제 스토리지, 서비스 배치, 클라이언트 액세스를 분리하여, 애플리케이션 프로세스를 하나 더 추가하는 것만으로는 독립적인 장애 도메인이 되지 않는 이유를 설명합니다.

연쇄적인 위험은 그로 인한 결과가 가정의 허용 수준에 맞고 복구가 빠르다면 감수할 수 있습니다. 하지만 동일한 호스트에 활성 서비스, 유일한 데이터베이스, 유일한 백업이 모두 있으면 위험해집니다. 이중화를 도입하거나 구성하기 전에 공유하는 모든 물리적·관리적 의존성을 표시하세요.

의존성이 복구 순서를 결정합니다

복구는 기반 서비스부터 바깥쪽으로 진행해야 합니다. 즉 전원과 스토리지, 호스트와 네트워크, DNS와 인증, 데이터베이스와 브로커, Home Assistant, 통합 구성 요소, 마지막으로 클라이언트와 자동화 순서입니다. 의존성이 준비되기 전에 이를 사용하는 서비스를 시작하면 오해를 불러일으키는 오류, 재시도 또는 부분적인 가용성이 발생해 진단이 어려워질 수 있습니다.

정전 보고는 하나의 사건이 나중에 스토리지, 네트워크 또는 애플리케이션 증상으로 나타날 수 있음을 보여 줍니다. 이 정전 후 증상 기록은 모든 하위 단계의 경고를 각각 수정하기보다 가장 먼저 장애가 발생한 계층을 찾아야 한다는 점을 일깨워 줍니다.

장애 경계란 파괴적인 변경 없이는 복구하거나 확인할 수 없는 의존성입니다. 해당 지점에서는 로그와 정상 상태로 확인된 상태를 보존하세요. 데이터베이스, 브로커 또는 이름 서비스가 안정되기 전에 하위 통합 구성을 다시 만들면 실제 장애 원인은 그대로 둔 채 증거만 지울 수 있습니다.

Featured

ZimaCube 2 개인용 클라우드 홈 NAS

ZimaCube2

장애 도메인 테스트 카드 만들기

가정 내 결과마다 한 행을 만들고, 필요한 구성 요소, 공유 의존성, 감지 신호, 성능 저하 시 동작, 복구 담당자, 최대 허용 장애 시간을 열로 작성합니다. 한 번에 하나의 의존성만 안전하게 제거하는 테스트를 추가하고, 어떤 결과가 실패하는지, 어떤 결과가 로컬에서 계속되는지, 자동으로 얼마나 복구되는지를 기록합니다.

하나의 의존성에 너무 많은 필수 결과가 연결되어 있는 것으로 나타나면 로컬 제어 구성 요소 맵을 활용하세요.

모든 핵심 결과에 알려진 장애 범위, 이를 감지하는 경고, 목표에 맞는 복구 순서가 있다면 아키텍처를 승인합니다. 테스트한 장애가 허용 범위를 넘어서는 경우에만 토폴로지를 변경하세요. 통제된 장애 테스트가 없는 다이어그램은 복원력의 증거가 아니라 가정에 불과합니다.