우리는 잘 작동하는 IIS7 머신의 웹 팜을 가지고 있습니다. 그 앞에는 F5 Big-IP 하드웨어 부하 분산 장치가 있으며 제대로 작동합니다. :)
(출처 : www.f5.com )
현재 우리는 OutProc 상태 ASP.NET State Service를 처리하기 위해를 사용하고 있습니다 . 이것은 모든 유형의 세션 정보를 유지하기 위해 웹 팜이있는 경우 필요합니다.
F5 Big-IP에서 고정 세션 을 가질 수 있는지 궁금해서 OutProc에서 InProc로 다시 변경할 수 있습니까? 그렇다면, 이것의 단점은 무엇입니까? InProc 대 OutProc의 단점을 알고 있으므로 설명에 대해 걱정하지 마십시오. F5 Big-IP가없는 끈적 끈적한 세션의 장단점에 더 관심이 있습니다.
누구나 빛이나 경험을 흘릴 수 있습니까?
답변:
두 가지 주요 단점이 있습니다.
부하가 고르게 분산되지 않습니다. 끈적 끈적한 세션이 붙어서 이름이 붙습니다. 초기 요청은 균등하게 분배되지만 다른 사용자보다 많은 시간을 소비하는 많은 사용자가 생길 수 있습니다. 이 모든 것이 처음에 단일 서버로 설정되면 해당 서버는 훨씬 더 많은 부하를 갖게됩니다. 일반적으로 이것은 실제로 큰 영향을 미치지는 않으며 클러스터에 더 많은 서버가 있으면 완화 될 수 있습니다.
프록시는 사용자를 단일 IP로 집약하며, 모든 IP는 단일 서버로 전송됩니다. 일반적으로 개별 서버로드를 늘리는 것 외에는 해가되지 않지만 프록시는 클러스터에서 작동 할 수도 있습니다. 요청이 프록시 클러스터의 다른 프록시 서버에서 나오는 경우 그러한 시스템에서 F5 로의 요청을 반드시 동일한 서버로 다시 보낼 필요는 없습니다.
AOL은 프록시 클러스터를 사용하여 한 시점에 실제로로드 밸런서 및 고정 세션으로 망쳤습니다. 대부분의로드 밸런서는 이제 C- 클래스 넷 범위를 기반으로하는 고정 세션 또는 F5의 경우 웹 요청 쿠키에 엔드 노드를 저장하는 쿠키 기반 고정 세션을 제공합니다.
쿠키 기반 세션은 작동하지만 몇 가지 문제가 있었으며 일반적으로 IP 기반 세션을 선택합니다. BIG HOWEVER : 저는 주로 내부 앱을 개발하고 있습니다. DMZ 마일리지는 다를 수 있습니다.
언급 한 바와 같이, 우리는 끈적 끈적한 세션과 진행중인 세션으로 behing F5를 실행하는 사이트에서 큰 성공을 거두었습니다.
SQL 또는 proc 메모리 서비스 외부에 저장되는 세션의 대안으로 Memcached 또는 Velocity 와 같은 메모리 분산 캐싱 시스템 중 하나를 살펴볼 수도 있습니다 . 여러 서버에서 메모리를 실행할 수 있으므로 프로세스 내 메모리 속도에 가깝습니다.
최근에 TechNet에서 "ASP.NET 응용 프로그램을위한 확장 성 제공"에 관한 훌륭한 기사를 읽었습니다. 그것은 각각의 가능한 해결책의 장단점으로 들어갔습니다. 읽어보세요 :
Christopher의 탁월한 답변 외에도 sticky session은 중복 서버의 몇 가지 큰 이점, 즉 유지 관리를 위해 하나 이상의 작업을 중단하고 시스템 장애가 발생하더라도 투명성을 유지하는 기능을 잃어 버렸다는 의미입니다.
고정 세션은 응용 프로그램 아키텍처 및 / 또는 프로그래밍이 열악하다는 강력한 지표라고 생각합니다. "모든 비용을 피하십시오"는 나의 좌우명입니다.