.NET 3.5 웹 서버 부하 분산을 위한 요구 사항

Question

실제로 단일 서버 환경에서 로드 밸런싱된 10개 클러스터로 전환하는 경우 즉시 경고음이 울립니다. 여러분이 이미 알아냈을 질문이 많이 있습니다. 하지만 어쨌든 그 질문들을 지적하고 몇 가지 일반적인 고려 사항을 제공하겠습니다.

어떻게 10번지에 도착하셨나요? 왜 2개 또는 3개로 확장하지 않고 필요에 따라 더 추가하지 않습니까?

애초에 왜 로드 밸런싱을 하려고 합니까? 예를 들어, 고부하, 고가용성, 아니면 둘 다를 원하시나요? 즉각적인 필요가 있습니까, 아니면 예측적 필요입니까?

지금 부하가 걸려 있고 이를 해결하기 위해 확장을 시도하고 있다면 제가 묻고 싶은 중요한 질문 중 하나는 실제로 병목 현상을 식별했는지 여부입니다. 세션 상태에 .NET과 SQL을 사용하고 있다고 말씀하셨으니 SQL 지원 애플리케이션도 사용하고 계시리라 생각됩니다. SQL Server의 균형도 조정하고 있나요? SQL Server가 현재 연결의 10배를 처리할 수 있습니까?

가용성을 추구한다면 다른 모든 실패 지점을 고려했습니까? 로드 밸런서에 중복성이 있습니까? 데이터베이스 서버에 중복성이 있습니까? 인터넷 업링크에 중복성이 있습니까(모든 지점 고려: 단일 케이블, 단일 스위치 등)? 가용성의 경우 가장 약한 링크만큼만 안전합니다. 프런트 엔드 웹 서버가 10개 또는 100개 있더라도 데이터베이스 서버가 하나만 있고 작동이 중단된다면 문제가 되지 않습니다.

병목 현상이 발생하는 경우는 대부분 데이터베이스 서버입니다. 그렇다면 프런트 엔드 수는 중요하지 않습니다.

SSL을 사용하는 경우 일반적으로 로드 밸런서가 작동하는 두 가지 일반적인 모드가 있으며, 이는 SSL 작동 방식에 영향을 미칩니다.
- 레이어 4: TCP 수준입니다. SSL은 각 서버에서 처리되므로 각 서버에 SSL 인증서를 설치해야 합니다.
- 계층 7: 이는 역방향 프록시라고도 하는 애플리케이션 수준입니다. 로드 밸런서는 HTTP 세션을 처리하고 애플리케이션 서버에 두 번째 연결을 설정합니다. 이 모드에서는 SSL 인증서가 밸런서에만 설치되며 앱 서버에 대한 연결은 일반적으로 HTTP입니다. 이는 때때로 "SSL 오프로딩"이라고도 하며 로드 밸런서가 강력하고 앱 서버가 SSL의 암호화 오버헤드를 처리하는 것을 원하지 않는 경우(예: 앱이 CPU 집약적임) 일반적으로 유용합니다.
서버가 다운될 때 서버가 회전에서 제외되도록 밸런서가 설정되어 있는지 확인하고 이 기능을 테스트하십시오. 나머지 서버에 영향을 주지 않고 서버를 다운시킬 수 있어야 합니다. 참고 PING, HTTP 및 응답 시간 확인. (핑이 발생한다고 해서 HTTP가 응답한다는 의미는 아닙니다)
환경을 로드 테스트하세요. 전체 작업을 수행할 수는 없지만 최소한 두 대의 서버를 로드할 수 있어야 합니다(밸런서에는 해당 두 대만 포함).
스테이징 환경을 실행합니다. 이는 서버 10대가 아닐 수도 있지만 배포 테스트를 위해 프로덕션 시스템을 복제하기에 충분해야 합니다.
자동화된 배포 스크립트를 갖추고 소스 관리 및 구성 관리를 매우 엄격하게 유지하세요. 이상적으로 이는 모든 것(구성 파일 포함)이 소스 제어 시스템에 있고 설치 프로그램/스크립트까지 모든 것을 생성하기 위해 자동화된 빌드를 가지고 있음을 의미합니다.
외부 사이트와 모든 내부 서버를 모두 모니터링하는 도구를 받으세요. 서버가 죽으면 외부 세계의 관점에서 볼 때 실제로 아무것도 바뀌지 않지만 어쨌든 서버를 알고 고치고 싶습니다. 성능이나 가용성에 문제가 발생하기 시작하면 3개의 서버가 한 달 동안 다운되었고 나머지는 추가 로드로 인해 어려움을 겪고 있다는 사실을 확인하고 싶지 않습니다.

Answer 1