페일오버 테스트: 설정된 TCP 스트림은 살아남는가?

「백업이 작동한다」는 문장 안에는 두 가지 결과가 숨어 있습니다. 새 요청이 성공하는 것은 복구입니다. 이미 진행 중인 전송이 계속되는 것은 연속성입니다. 이 둘은 서로 다른 약속이며, 대부분의 페일오버 설계는 첫 번째를 제공하는 동안 두 번째는 조용히 시간 초과됩니다. 메커니즘을 고르기 전에 어느 쪽이 필요한지 정하고, 둘을 구분할 수 있도록 시험을 작성하십시오.

하나의 성공처럼 보이는 두 가지 결과

10.90.0.42에 있는 클라이언트가 198.51.100.20:443으로 연결되어 있다고 상상해 보십시오. 기본 출구는 이를 하나의 공인 주소와 포트로 변환하고, 백업 출구는 다른 것으로 변환합니다. 클라이언트의 내부 주소는 결코 바뀌지 않으며, 그래서 사람들은 연결이 살아남기를 기대합니다.

서버는 내부 주소를 보지 않습니다. 변환된 종단점을 보며, 그 종단점은 전환 후에 달라집니다.

그래서 오래된 스트림은 시간 초과되는 반면 같은 서비스로의 새 연결은 즉시 작동합니다. 두 관찰 모두 동시에 사실입니다.

출구가 바뀔 때 서버가 보는 것

TCP 연결은 사중 튜플로 식별되며, 출발지 주소나 포트가 바뀌면 수신 호스트 입장에서는 다른 연결이 됩니다. 서버가 모르는 연결로 새 출발지에서 도착한 패킷은 버려지거나 재설정으로 응답됩니다. VPN 클라이언트의 주소에는 그 변화를 넘어 연결 관계를 유지하는 것이 없습니다.

상태 기반 페일오버는 바로 이것을 피하려고 존재하며, 전달 장치 사이에서 변환 상태와 연결 상태를 교환하여 작동합니다. 그것은 터널이 아니라 쌍의 기능이며, 가정할 것이 아니라 설계하고 시험해야 합니다.

누군가에게 연속성을 약속하기 전에 그 쌍이 실제로 상태를 유지하는지 확인하십시오. 아래 명령은 양쪽의 현재 상태를 보여 줍니다.

conntrack -L -d 198.51.100.20 2>/dev/null | head
ss -tin dst 198.51.100.20
tcpdump -ni any host 198.51.100.20 -c 10

같은 공인 주소로 충분하지 않은 이유

두 경로에서 하나의 공인 주소를 유지하는 것은 좋은 출발입니다. 그러면 서버가 같은 출발지 종단점을 보기 때문입니다. 그러나 그것만으로는 충분하지 않습니다. 전달 장치에는 여전히 변환 상태, 방화벽 상태, 사용 가능한 반환 경로가 필요하며, 이는 전환 후 트래픽을 나르는 장치에 있어야 합니다.

RFC 3022는 주소 변환을 설명하고 변환 장치 사이의 상태 교환을 백업 설계의 일부로 다룹니다. 유동 주소나 복사한 프로필은 구성을 옮길 뿐 상태는 옮기지 않습니다.

그래서 백업을 통한 핑만 하는 시험은 증명하는 것이 매우 적습니다. 핑에는 잃을 연결 상태가 없습니다.

요구가 얼마나 강한지 정하십시오

장애 후 사용자가 다시 연결할 수 있다면 설계는 복구 설계이고 인수 시험은 새 요청입니다. 파일 전송이 살아남아야 한다면 설계에는 상태 동기화와 훨씬 신중한 시험이 필요합니다. 원격 세션이 살아남아야 한다면 요구는 더욱 강하며 네트워크 수준이 아니라 응용 수준의 메커니즘이 필요할 수 있습니다.

요구를 측정 가능한 결과가 있는 문장으로 쓰십시오. 예를 들어 업로드가 다시 시작하지 않고 완료되거나 운영자가 일 분 안에 다시 연결되는 것입니다. 그런 다음 이를 만족하는 가장 저렴한 메커니즘을 고르십시오. 흔히 그것이 복구 설계입니다.

기본 경로가 돌아올 때 무슨 일이 일어나는지 분명히 말하십시오. 자동 페일백은 백업에서 막 복구된 연결을 끊을 수 있습니다. 그 상황은 각주가 아니라 시험 계획에 속합니다.

오래된 스트림과 새 요청을 확인하십시오

기본 경로로 무해한 장시간 전송을 시작한 다음, 같은 서비스로 별도의 새 요청을 보내십시오. 응용 맥락, 관찰된 출구 주소, 시각을 기록하십시오. 승인된 방식으로 기본 경로를 끊고, 백업을 통해 새 요청을 보내면서 원래 전송을 계속 관찰하십시오.

세 가지 값을 보고하십시오. 오래된 스트림이 계속되었는지, 재설정되었는지, 시간 초과되었는지, 새 작업이 처음 작동한 시점, 페일백이 무언가를 끊었는지 여부입니다. 그 세 줄이 인수 기록입니다.

ss -tin dst 198.51.100.20
curl -sS -o /dev/null -w '%{http_code} %{time_total}\n' https://198.51.100.20/
tcpdump -ni any port 443 -c 20

작업 부하가 데이터를 쓴다면, 시간 초과 후에 불확실한 작업을 무작정 반복하지 마십시오. 응답이 사라지기 전에 쓰기가 도착했을 수 있습니다. 응용에 결과를 물어보거나, 작업이 멱등인 경우에만 다시 시도하십시오. 그런 다음 인수 진술을 세 부분으로 쓰십시오. 새 작업은 출구 정책 아래에서 복구되고, 기존 스트림은 문서화된 중단 동작을 가지며, 응용은 안전하게 재개됩니다. 그 진술은 시험 가능하며, 설계가 약속하지 않는 것에 대해 정직합니다.