VPN에서 Oracle 세션이 끊겼나요? keepalive 계층을 확인하세요

스물다섯 분의 유용한 데이터베이스 작업은 거의 아무 출력도 내지 않고, 경로상의 모든 장치에서 그 흐름은 유휴 상태로 보입니다. 바로 그 유휴 상태가 회수됩니다. 나중의 보고서는 항상 같은 모양입니다. 쿼리는 돌고 있었고, 그러다 세션이 사라졌고, 결과는 끝내 도착하지 않았습니다.

조용한 세션이 살아남는지는 네 가지 확인으로 결정되며, 그것들은 소켓에서 바깥으로 나아갑니다. 이전 계층이 제 일을 한다고 전제하므로 순서대로 하세요.

어떤 흐름이 조용해지는가

중요한 연결은 데이터베이스 트래픽을 나르는 연결이며, 자체 주소와 포트로 식별됩니다. 다른 무엇도 그 연결을 갱신하지 않습니다. 게이트웨이로 가는 핑, 같은 호스트에서 나가는 두 번째 SQL 연결, 터널 자체의 하트비트는 서로 다른 흐름이고, 그것들을 추적하는 모든 장치에서 상태가 따로 있습니다.

ss -tio dst 10.60.4.20
sysctl net.ipv4.tcp_keepalive_time net.ipv4.tcp_keepalive_intvl net.ipv4.tcp_keepalive_probes

소켓 목록은 살아 있는 연결의 타이머와 큐 상태를 보여 주며, 도달성 테스트보다 많은 정보를 줍니다. sysctl 값은 keepalive 동작에 대한 커널 기본값이고, 다음 절은 그것이 당신의 세션에 결코 적용되지 않을 수 있는 이유를 설명합니다. 결코 발동하지 않는 기본값은 기본값이 전혀 없는 것과 구분되지 않습니다.

연결이 쓰는 주소, 포트, 인터페이스를 적어 두세요. 세션이 죽을 때, 네트워크가 살아 있었는지를 묻는 대신 올바른 장치에 무엇을 했는지 물을 수 있게 하는 것이 바로 이 세부 정보입니다.

유휴 정책은 만료인가, 제한인가

두 정책은 같은 증상을 만들고 반대의 대응을 요구합니다. 유휴 타임아웃은 적격 트래픽이 갱신할 수 있었던 상태를 제거하고, keepalive는 그것을 막을 수 있습니다. 절대 세션 한도는 활동과 무관하게 정해진 시간 뒤에 흐름을 제거하며, 어떤 keepalive도 그것을 바꾸지 못합니다.

각 중간 장치의 소유자에게 둘 중 무엇을 구현하는지 물으세요. 방화벽, NAT 장치, 로드 밸런서, 클라우드 게이트웨이는 모두 상태를 유지할 수 있고, 서로 일치할 필요는 없습니다. 가장 좁은 것이 당신이 이겨야 할 기한을 정합니다.

이 구분은 언제 튜닝을 멈출지도 알려 줍니다. 정책이 절대 한도라면 올바른 해법은 더 짧은 작업 단위, 다시 시작할 수 있는 작업, 승인된 예외이며, 아래 확인은 keepalive가 아무것도 바꾸지 않았음을 확인해 줄 뿐입니다.

Linux 기본값 뒤에 있는 소켓 스위치

keepalive는 소켓마다 선택 사항입니다. 커널 기본값은 소켓이 그 메커니즘을 켠 뒤 프로브가 어떻게 행동하는지를 설명하며, 기존 연결에 그것을 켜 주지는 않습니다. 결코 요청하지 않는 애플리케이션은 sysctl 값이 무엇이라도 프로브를 받지 못합니다.

그래서 숫자만 올리는 것으로는 데이터베이스 클라이언트에 아무 변화가 없습니다. 메커니즘은 클라이언트 라이브러리나 애플리케이션이 켜야 하며, 스택이 연결별 제어를 제공하는 곳에서는 무관한 서비스에 영향을 주는 호스트 전체 변경보다 범위가 좁은 설정이 낫습니다.

첫 프로브까지의 간격도 쿼리 타임아웃이 아닙니다. 건강한 연결은 프로브 사이에 조용히 있고, 죽은 상대는 프로브 간격과 횟수로 판별됩니다. 이 세 값을 하나의 타임아웃으로 읽으면 장애를 너무 늦게 또는 너무 성급하게 감지하는 설정에 이르게 됩니다. 그것들은 감지를 제어할 뿐, 애플리케이션의 인내를 제어하지 않습니다.

EXPIRE_TIME은 데이터베이스 설정이지 네트워크 수정이 아니다

Oracle Net은 자체 생존 확인 메커니즘을 제공하며, 그것은 프로세스의 유효 프로필에서 구성되고 이름이 비슷한 임의의 파일에서 구성되지 않습니다. 값은 분 단위로 표현됩니다.

SQLNET.EXPIRE_TIME = 5

주된 목적은 서버 측에서 죽은 연결을 감지하는 것이고, 확장 모델을 지원하는 플랫폼에서는 그 연결들의 TCP keepalive 동작도 조정합니다. 이는 유용한 성질입니다. 데이터베이스 계층이 클라이언트 애플리케이션에 변경을 요구하지 않고 프로브를 마련할 수 있습니다.

위의 예시 값은 가정된 기한에 맞춘 조정된 선택이며 권장 사항이 아닙니다. 문서화된 일반 지침은 더 긴 간격이고, 올바른 숫자는 설치된 구현, 감수하는 프로브 비용, 경로상의 실제 갱신 규칙에 달려 있습니다. 설정을 해당 프로세스가 읽는 프로필에 넣고, 프로세스가 그것을 받아들였는지 확인하세요. Oracle은 프로필 위치와 감지 동작을 매개변수 참조에 문서화합니다.

조용한 구간을 시험한 뒤 복구를 계획하세요

이겨 내려는 기한보다 긴 조용한 기간에 새로 허용된 연결을 통과시키고, 생존 트래픽과 애플리케이션 결과를 관찰하세요. 필요 없는 페이로드 내용은 캡처하지 마세요. 타이머와 연결 상태가 그 질문에 답합니다.

ss -tio dst 10.60.4.20
# after the quiet interval, same command
ls -l "$ORACLE_HOME/network/admin/sqlnet.ora"

그래도 세션이 사라지면, 기한은 아직 물어보지 않은 장치의 것이거나 정책이 절대 한도입니다. 살아남으면 어느 계층이 바뀌었는지 기록해, 다음 조용한 작업이 조사를 되풀이하지 않게 하세요.

마지막으로, 연결이 실제로 끊길 때 무슨 일이 일어나는지 정하세요— 생존 확인은 빈도를 줄일 뿐 가능성을 없애지 않습니다. 다시 보내기 전에 데이터베이스 작업의 기록된 결과를 확정하세요. 응답을 잃은 것은 작업이 확정되었는지에 대해 아무것도 증명하지 않습니다. 노트북을 닫거나 터널이 다시 시작되는 것을 견뎌야 하는 모든 것에는 서버가 소유하고 결과가 지속되는 작업이 더 강한 설계이며, keepalive는 스케줄러가 아닙니다.