매일 OpenVPN을 재시작할까? 시계가 아니라 장애를 고르세요

매일 04:10에 OpenVPN을 재시작하는 cron 작업을 물려받았고, 그것이 한 해 동안 안정을 유지해 왔습니다. 그러나 그 작업은 정해진 시각에 건강한 터널을 끊고, 실제로 점심시간에 일어나는 장애에는 아무것도 하지 않습니다. 달력에 따른 재시작은 유지보수 결정입니다. 복구는 특정 트리거를 가진 다른 설계입니다.

세 가지 장애 형태에는 서로 다른 세 명의 소유자가 필요합니다. 먼저 장애를 고르면 메커니즘은 따라옵니다.

세 가지 장애, 세 명의 소유자

피어가 사라져도 터널은 살아 있을 수 있습니다. 프로세스는 돌고, 인터페이스는 존재하며, 그 안으로 유용한 것이 지나가지 않습니다. 피어가 멀쩡해도 프로세스는 죽어 있을 수 있고, 그때는 그것을 시작한 것만이 되살릴 수 있습니다. 터널 뒤의 애플리케이션은 터널과 피어가 모두 건강한데도 고장 날 수 있고, 그때 클라이언트를 재시작하면 원인은 건드리지 않은 채 장애만 넓힙니다. 이 세 경우를 분리하는 것이 전부입니다.

각각 고유한 신호와 소유자가 있습니다. 생존성은 VPN 프로토콜의 것이고, 프로세스 수명 주기는 서비스 관리자의 것이며, 애플리케이션 상태는 좁은 권한을 가진 모니터링의 것입니다.

생존성 옵션이 할 수 있는 일과 할 수 없는 일

keepalive는 ping과 ping-restart 쌍으로 확장되는 도우미이며, 링크 옵션 참조가 설명하듯이 그것이 만드는 타임아웃은 서버와 클라이언트에서 동일하지 않습니다. 서버가 밀어 넣는 값은 클라이언트가 로컬에서 설정한 값을 덮어쓸 수도 있으므로, 로컬 파일에서 맞아 보이는 타임아웃이 실제로 적용되는 값이 아닐 수 있습니다.

그래서 이것은 잃어버린 피어에는 맞는 도구이고 죽은 프로세스에는 틀린 도구입니다. 종료된 프로세스는 자기 타이머를 돌릴 수 없기 때문입니다. 또한 터널 뒤의 애플리케이션이 응답하는지에 대해서는 아무 말도 하지 않습니다. 교환은 두 VPN 끝점 사이에서 일어나기 때문입니다. 역할, 예상되는 중단, 재인증 동작을 확인하지 않고 다른 배포에서 타임아웃 쌍을 복사하는 것이 안정적인 터널이 흔들리기 시작하는 길입니다.

서비스 관리자가 소유한 것

데몬이 종료되면 그것을 시작한 관리자가 다음을 결정합니다. 실패를 기준으로 한 재시작 정책에 지연과 시작 속도 제한을 더하면 크래시 루프를 포크 폭탄으로 만들지 않고 다룰 수 있습니다. 그 설정은 프로세스 결과와 타임아웃에 반응하며, 살아 있지만 쓸모없는 프로세스는 감지하지 못합니다. 이것은 더 넓은 정책으로 메울 구멍이 아니라 수명 주기와 생존성 사이의 경계입니다.

소유권은 설정만큼 중요합니다. 데스크톱 네트워크 관리자가 시작한 연결은 그 관리자의 복구 방식을 유지해야 하며, 같은 인터페이스에 경쟁하는 서비스 유닛을 추가하면 하나의 터널에 두 명의 소유자가 생깁니다. 하나를 고르고 어느 것인지 적어 두십시오.

예약된 재시작이 정당한 경우

정해진 시각의 재시작은 합리적인 유지보수 조치일 수 있습니다. 소유자, 시간 창, 이름이 붙은 인스턴스, 독립적인 진입 경로가 있기 때문입니다. 그러나 정해진 시각에 모든 사람을 끊는 일반적인 신뢰성 정책이 되어서는 안 됩니다.

알려진 누수나 멈춘 상태를 우회하려고 재시작이 존재한다면 유닛 설명에 그렇게 적으십시오. 그렇지 않으면 다음 사람이 그것을 영원히 유지합니다.

중요한 경우를 시험하십시오. 프로세스가 살아 있는데 피어가 사라지는 경우, 프로세스가 종료되는 경우, 재시도에 새 자격 증명이 필요한 경우, 애플리케이션이 고장 난 채 터널이 돌아오는 경우입니다. 어느 구성 요소가 반응하고 어떤 상태를 남기는지 보십시오.

올바른 질문은 얼마나 자주 재시작할지가 아니라 무엇이 장애를 가장 먼저 알아차려야 하는지입니다.