소켓 (C#)을 사용하여 원격 서버에 TCP 연결을 여는 Azure에 웹 역할이 배포되었습니다. 이 연결은 항상 열려 있어야합니다. 20 분 후에 연결이 끊어진 것 같습니다.Azure Web Role은 영구적으로 열린 TCP 연결을 호스팅하도록 설계 되었습니까?
그래서 웹 역할이 설계되었거나 그러한 연결을 호스트 할 수 있는지 궁금합니다. TCP 연결을 닫을 수있는 자동화 된 프로세스가 있습니까 (예 : 재활용)?
실행중인 코드는 내 컴퓨터에서 정상적으로 작동하며 전용 서버에서 '표준'Windows 서비스를 사용하는 경우 제대로 작동합니다.
도와 주셔서 감사합니다. Jerome.
내 요구 사항에 맞는 솔루션을 찾았습니다. 역할 재활용으로 인해 TCP 연결이 끊어졌습니다. 여기에 설명 된 솔루션 : Disable IIS Idle Timeouts in Azure Web Role을 사용하여 서비스를 배포 할 때 IIS AppPool을 구성 할 수있었습니다.
그래서 기본적으로 내가하지 않도록해야합니다
감사합니다!
클라우드로 이동할 때 아키텍처를 변경해야합니다. 클라우드에서 가장 많이 사용되는 클라우드는 처음부터 100 % 가용성과 같은 것이 없습니다. 따라서 "항상 열리지"않습니다.
다음으로 연결을 닫을 수있는 요소가 많이 있습니다. 어떤 사람들에게는 통제력이 있고, 다른 사람들에게는 그렇지 않습니다. 여기에 일부 비 결정적인 목록입니다
에서 또는 -
연결 (모든 연결)이 XXX 초 이상 유휴 상태 인 경우 (이 숫자는 시간이 지남에 따라 변경되어 특정 숫자를 인용하지 않으므로 1 분이라고 가정 함) 종료 중입니다. .
결국 클라우드에 연결을 닫을 요인이 너무 많아서 클라우드 방식으로 생각하기 시작합니다. 프로토콜에서 다시 시도 로직을 구현하고 서비스에 치유 논리를 구현합니다. 마지막으로 중요한 것은 가용성을 추구 할 경우 단일 인스턴스 역할을 사용하지 마십시오.
연결 시간 초과에 대한 흥미로운 내용은 here입니다. 동일한 데이터 센터 내의 연결 (역할 및 VM 내) 만 참조 할지라도 여전히 읽을만한 가치가 있습니다.
흥미로운 업데이트 - "나는 금융 시장과 관련이 있습니다." 그렇더라도 100 % 가동 시간 대 99.95 % 가동 시간에 대해 질문해야합니다.이 가동 시간은 2 개의 인스턴스가있는 WebRoles의 표준 SLA입니다. 절대로 쉬운 일은 아니지만 웹 롤 (또는 작업자 역할)의 최소 2 인스턴스와 연결을 모니터링하는 일종의 워치 독으로 99.95 % 가용성을 달성 할 수 있습니다. 연결이 끊어지면 항상 하나의 연결 만 유지하십시오. 즉, 즉시 (감지 된 경우) 다른 연결을여십시오. 예를 들어 Redis 캐시 또는 Azure Cache 또는 고 가용성을 위해 구성된 In-role 캐시에 필요한 데이터를 보관하십시오.
클라우드에서 고 가용성을위한 솔루션이 있습니다. 그러나 당신이 100 %를 찾는다면, 이것은 당신의 장소가 아닙니다. 클라우드에는 100 % SLA가 없습니다.
답장을 보내 주셔서 감사합니다. 연결을 유지하기위한 하트 비트 메커니즘이 있습니다. 정말 항상 열려있는 연결이 필요하며 연결 또는 서비스가 다운되지 않는지 확인해야합니다 (응용 프로그램에 버그 또는 충돌이있는 경우 제외). 나는 외부 요인에 의존하고 싶지 않습니다. 어쩌면 구름이 내게 최선의 선택이 아니겠습니까 ... –
100 % 가용성에 대해 질문하고 실패 후 TTR을 최소화하기 위해 정말로 도전하겠습니다. 100 % SLA를 제공하는 클라우드 공급 업체를 찾을 수는 있지만 가격을 비교할 때 Azure로 돌아가고 싶을 것입니다.) 항상 외부 요인에 의존합니다. 합리적인 가격으로 100 % 가동 시간 시스템을 만들 수 있다고 생각한다면 자신을 속일 수 있습니다. – astaykov
나는 알고있다. :) 그러나 나는 클라우드에서 매우 새롭고 클라우드 서비스는 표준 Windows 서비스와 동일한 동작을하지만. 나는 조사를 계속할 것이고 문제가 어디 있는지 확실하게 알게 될거야. –
Azure에서 사용되는로드 밸런서 때문에 연결이 끊어지는 것 같습니다. 1 분 후에 유휴 연결을 끊는 데 사용되었지만 이것이 20 분으로 변경되었다고 생각합니다 (나중에 이에 대한 참조를 찾고 이에 따라이 답변을 업데이트 할 수 있음).
여기서 주목해야 할 중요한 부분은 연결이 끊어지는 유휴 연결 일 뿐이므로 연결을 사용하는 경우 연결을 끊지 않아야합니다 (최대 연결 시간도있을 수 있음을 몰래 의심합니다.)).
기본적으로 Azure 역할의 IIS는 26 시간 후에 응용 프로그램 풀을 재활용합니다. 이것은 시작 스크립트의 IIS 설정 변경을 통해 변경할 수 있습니다.
또한 Azure의 모든 인스턴스는 언제든지 재활용 될 수 있습니다. 매우 자주 발생하지는 않지만 일어날 수는 없습니다. 귀하의 웹 역할은 일종의 행동을 취할 필요가 있음에도 불구하고 이런 일이 발생했다고 말하는 이벤트를 수신합니다.
Azure에서 호스트하려는 경우 원격 서버가이 연결을 처리하는 방법에보다 유연해야합니다.
내 VM의 이벤트 뷰어에서 문제의 원인을 발견했습니다. TCP 연결이 끊어진 정확한 시간에이 이벤트가 발생했습니다. "프로세스 ID가 '3724'인 응용 프로그램 풀 'd2995196-148a-4f49-93d9-b9e110188cc8'을 제공하는 작업자 프로세스가 비활성으로 인해 종료되었습니다. 응용 프로그램 풀 시간 초과 구성은 20 분으로 설정합니다. 필요할 때 새로운 작업자 프로세스가 시작됩니다. " 20 분 후에 앱 풀이 서비스를 재활용하는 것 같습니다. 웹 역할 대신 작업자 역할을 사용해 보겠습니다. –
은 세션 시간 초과와 비슷하게 들립니다. 왜 항상 연결되어 있어야합니까? –
저는 금융 시장과 관련이 있습니다. –
원칙적으로 TCP 연결을 열어 놓을 수는 없습니다 (네트워크 블립, 앱 재배포, OS 재부팅, 크래시, 버그 등). 어쨌든 연결이 끊어 질 계획이 있어야합니다. 아마도 재 연결/재 시도 전략 일 것입니다. – usr