건물 추천한 로드밸런 ASP.NET 트

https://stackoverflow.com/questions/613568

03-07-2019
|

문제

업데이트 2009-05-21

나는 테스트 2 위의 방법을 사용하여 싱글 네트워크 공유합니다.그것은 결과에서 어떤 문제로 윈도우 서버 2003 에서 짐:

http://support.microsoft.com/kb/810886

최종 업데이트

을 받았는 제안 ASP.NET 웹사이트는 다음과 같습니다.

하드웨어 부하 분산->4lls6 에는 웹 서버->SQL Server DB 장애 조치 클러스터

여기에 문제가...

우리가 선택 저장 웹 파일(aspx,html,css,이미지).두 가지 옵션이 제안되었:

1)동일한 복사본을 만들의 웹 파일에서 각각의 4IIS 서버입니다.

2)단일의 복사본을 웹 파일 공유 네트워크에 액세스할 수 있으로 4 개의 웹 서버에 있습니다.이 webroots4IIS 서버에 매핑됩니다 하나의 네트워크 공유합니다.

는 더 나은 솔루션인가?옵션 2 분명히 간단하게 배포 이후 필요한 파일 복사를 하나만 위치에 있습니다.그러나 궁금있을 것입니다 경우 확장성 문제 때문에 네 개의 웹 서버를 모두에 액세스하는 단일의 설정 파일입니다.이 IIS 캐시 이러한 파일이 로컬?그것은 히트 네트워크에서 공유 할 모든 클라이언트의 요청이 있으십니까?또한 것입니다,네트워크 공유에 대한 액세스 권한을 항상 보다 느린 점점에 파일이 로컬 하드 드라이브는?가 네트워크의 부하를 공유가 되는 실질적으로 악화면 IIS 서버에 추가?

하게 관점에서,이를 위해 웹사이트는 현재를 받~20million hits per month.최근에는 피크,그것은 받는 약 200 명중합니다.

알려주시기 바랍는 경우에 당신은 특별한 경험과 같은 설정입니다.입력 주셔서 감사합니다.

업데이트 2009-03-05

을 명확히 나의 상황은"배포"이 시스템에서 훨씬 더 자주 이상적인 웹 응용 프로그램입니다.웹사이트 프론트 엔드에 대한 뒤 사무실 CMS.각 시간 콘텐츠에 게시 CMS,새로운 페이지(aspx,html 등)은 자동으로 밀어 라이브 사이트입니다.의 경우 기본적으로"on demand".이론적으로,이를 밀어 일어날 수 있는 몇 시간 이내에 분 이상입니다.그래서 나는 확실하지 않은 실제적인 것입 배포하는 하나의 웹 서버에서는 시간입니다.생각?

해결책

4 개의 서버간에로드를 공유하겠습니다. 그다지 많지 않습니다.

배치 할 때 또는 생산에서 단일 실패 지점을 원하지 않습니다.

배포 할 때 한 번에 1 씩 할 수 있습니다. 배포 도구는로드 밸런서에 서버를 사용하지 않아야한다는 사실을 알리고 코드 배포, 필요한 사전 컴파일 작업, 최종적으로로드 밸런서에 서버가 준비되었음을 알림으로써이를 자동화해야합니다.

우리는 200+ 웹 서버 팜 에서이 전략을 사용했으며 서비스 중단없이 배포하는 데 잘 작동했습니다.

다른 팁

당신의 주요 관심사가 성능이라면, 당신이 하드웨어 에이 돈을 모두 쓰고 있기 때문에, 편의를 위해 네트워크 파일 시스템을 공유하는 것은 실제로 합리적이지 않습니다. 네트워크 드라이브가 매우 높은 성능을 발휘하더라도 기본 드라이브만큼 성능이 뛰어납니다.

웹 자산을 배포하는 것은 어쨌든 자동화되므로 (맞습니까?) 배수로하는 것이 실제로 불편하지는 않습니다.

그것이 당신이 내놓는 것보다 더 복잡하다면, deltacopy와 같은 것이 디스크를 동기화하는 데 유용 할 것입니다.

중앙 점유율이 나쁜 이유 중 하나는 공유 서버의 NIC가 전체 농장의 병목 현상을 만들고 단일 고장 지점을 생성하기 때문입니다.

IIS6 및 7을 사용하면 첨부 된 웹/앱 서버 시스템에서 네트워크 단일 공유를 사용하는 시나리오가 명시 적으로 지원됩니다. MS는이 시나리오가 잘 작동하는지 확인하기 위해 많은 성능 테스트를 수행했습니다. 예, 캐싱이 사용됩니다. 듀얼 NIC 서버를 사용하면 공개 인터넷을위한 하나와 개인 네트워크 용 서버가 있으면 정말 좋은 성능을 얻을 수 있습니다. 배포는 방탄입니다.

시간을내어 벤치마킹 할 가치가 있습니다.

ASP.NET 가상 경로 제공 업체를 평가할 수도 있습니다.이 가상 경로 공급자는 전체 앱에 대한 단일 zip 파일을 배포 할 수 있습니다. 또는 CMS를 사용하면 파일 시스템이 아닌 콘텐츠 데이터베이스에서 컨텐츠를 바로 제공 할 수 있습니다. 이것은 버전 작성을위한 정말 좋은 옵션을 제공합니다.

#ziplib을 통해 ZIP 용 VPP.

dotnetzip을 통한 zip 용 VPP.

이상적인 고용성 상황에서는 단일 실패 지점이 없어야합니다.

즉, 웹 페이지가있는 단일 상자는 No-No라는 것을 의미합니다. 주요 통신처를 위해 HA 작업을 한 후 처음에는 다음을 제안 할 것입니다.

4 개의 서버 각각에는 자체 데이터 사본이 있습니다.
조용한 시간에 서버 두 개를 오프라인으로 가져 오십시오 (즉, HA 밸런서를 수정하여 제거하십시오).
두 개의 오프라인 서버를 업데이트하십시오.
HA 밸런서를 수정하여 두 개의 오래된 서버가 아닌 두 개의 새 서버를 사용하기 시작하십시오.
정확성을 보장하기 위해 테스트하십시오.
다른 두 서버를 업데이트 한 다음 온라인으로 가져옵니다.

그것이 당신이 여분의 하드웨어없이 그것을 할 수있는 방법입니다. 내가 일한 통신의 항문 재구성 세계에서 우리가 한 일은 다음과 같습니다.

우리는 8 개의 서버를 가지고 있었을 것입니다 (당시에는 당신이 막대기를 찌를 수있는 것보다 더 많은 돈이있었습니다). 전환이 시작되면 4 개의 오프라인 서버가 새 데이터로 설정됩니다.
그런 다음 HA 밸런서를 수정하여 4 개의 새 서버를 사용하고 이전 서버 사용을 중지합니다. 이로 인해 전환 (그리고 더 중요한 것은 우리가 채워지면 스위치 백)이 매우 빠르고 고통스러운 과정을 만들었습니다.
새 서버가 한동안 실행되었을 때만 다음 전환을 고려할 것입니다. 그 시점까지, 4 개의 오래된 서버는 오프라인으로 유지되었지만 준비된 경우를 대비하여 준비되었습니다.
재무 지출이 적은 동일한 효과를 얻으려면 전체 추가 서버가 아닌 추가 디스크를 가질 수 있습니다. 이전 디스크를 다시 넣기 위해 서버에 전원을 공급해야하기 때문에 복구는 그리 빠르지 않지만 복원 작업보다 더 빠릅니다.

저는 한 달에 6 천만 명에 불과한 게임 웹 사이트의 개발을 담당했습니다. 우리가 한 방식은 옵션 #1이었습니다. 사용자는 이미지를 업로드 할 수있는 기능을 가지고 있었고 서버간에 공유 된 NAS에 놓여있었습니다. 그것은 꽤 잘 작동했습니다. 나는 당신이 집의 응용 프로그램 측면에서 페이지 캐싱 등을하고 있다고 가정합니다. 또한 새로운 페이지를 모든 서버에 동시에 배포 할 것입니다.

4IIS로 NLB에서 얻는 것은 앱 서버를 사용한 병목 현상으로 느슨해집니다.

확장 성을 위해서는 프론트 엔드 웹 서버의 응용 프로그램을 권장합니다.

여기 우리 회사에서는 해당 솔루션을 구현하고 있습니다. 전면 끝의 .NET 앱과 SharePoint + A SQL 2008 클러스터 용 앱 서버.

도움이되기를 바랍니다!

문안 인사!

우리는 귀하와 비슷한 상황이 있으며 솔루션은 게시자/가입자 모델을 사용하는 것입니다. 당사의 CMS 앱은 실제 파일을 데이터베이스에 저장하고 파일이 만들어 지거나 업데이트 된 경우 게시 서비스에 알립니다. 그런 다음이 게시자는 모든 구독 웹 응용 프로그램에 알리고 데이터베이스에서 파일을 가져 와서 파일 시스템에 배치합니다.

가입자는 게시자의 구성 파일에 설정되어 있지만 전체 돼지를 가서 웹 앱이 앱 시작에서 구독 자체를 수행하여 관리하기가 더 쉽게 만들 수 있습니다.

저장소에 UNC를 사용할 수 있습니다. 우리는 생산 및 테스트 환경간에 편의성과 휴대 성을 위해 DB를 선택했습니다 (우리는 간단히 DB를 복사하고 모든 라이브 사이트 파일과 데이터가 있습니다).

여러 서버에 배포하는 매우 간단한 방법 (노드가 올바르게 설정되면)은 robocopy를 사용하는 것입니다.

바람직하게는 테스트를위한 작은 스테이징 서버가있는 다음 네트워크 공유를 사용하는 대신 모든 배포 서버에 'robocopy'를 갖게됩니다.

Robocopy는 다음에 포함되어 있습니다 MS ResourceKit - /miR 스위치와 함께 사용하십시오.

당신에게 생각할 음식을 주려면 당신이 같은 것을 볼 수 있습니다. Microsoft의 라이브 메쉬. 나는 그것이 당신을위한 답이라고 말하는 것이 아니라 그것이 사용하는 스토리지 모델 일 수 있습니다.

메쉬를 사용하면 메쉬에 원하는 각 Windows 시스템에 작은 Windows 서비스를 다운로드 한 다음 메쉬의 일부인 시스템의 폴더를 지명합니다. 파일을 Live Mesh 폴더에 복사하면 시스템의 다른 Foler에 복사하는 것과 동일한 작업 인 경우 서비스는 해당 파일을 다른 모든 참여 장치에 동기화하는 것을 관리합니다.

예를 들어 모든 코드 소스 파일을 메쉬 폴더에 보관하고 작업과 가정간에 동기화합니다. VS.NET, Notepad 또는 다른 앱이 업데이트를 시작하는 작업을 동기화하기 위해 아무것도 할 필요가 없습니다.

여러 서버로 이동 해야하는 파일이 자주 변경되고 아마도 이러한 변경 사항에 대한 저자를 자주 변경하는 웹 사이트가있는 경우 각 웹 서버에 메시 서비스를 넣을 수 있으며 저자가 추가, 변경 또는 제거 된 파일이 업데이트가 다음과 같습니다. 자동으로 푸시했습니다. 저자가가는 한, 파일을 컴퓨터의 일반 기존 폴더에 저장하는 것입니다.

사용 배포 도구,프로세스를 배포하는 한번에 하나씩 나머지는 시스템의 유지 작업(로 Mufaka 말했다).이 시도는 프로세스 모두에서 작동하는 콘텐츠 파일하고 모든 컴파일한 조각의 응용 프로그램(를 배포하는 원인 재활용의 asp.net 프로세스).

에 관한 업데이트 평가 이것은 무언가를 제어할 수 있습니다.업데이트로 이동을 통해 큐,그리고 하나 배포하는 프로세스 제어를 배포하는 각각의 항목입니다.이것을 주는 것을 의미 하지 않는 프로세스 각 업데이트로,따로 잡을 수 있는 현재에서 업데이트 큐 및 배포합니다.추가 업데이트 도착하는 큐,그리고 선택됩니다면 현재 세트의 업데이트입니다.

업데이트: 에 대한 질문에 comment.이것은 사용자 지정 솔루션을 기반으로 저의 경험을 가진 무거운/길 프로세스를 필요로 하는 그들의의 비율 업데이트가 통제됩니다.이 없었을 사용할 필요가 이 방법에 대한 배포본으로,그러한 동적 콘텐츠가 일반적으로의 조합으로 DB 및 캐시에는 차이가 있을 수 있습니다.

큐 필요하지 않을 보유한 전체 정보를,그것이 필요하고 적절한 정보(id/경로)에 있도록 귀하의 프로세스 전달하는 정보를 시작하는 게시 프로세스는 외부 도구입니다.그것은 사용자 지정 코드에,당신은 그것을 할 수 있습에 참여할 정보를 게시,그래서 당신은 없을 거래하는 게시 프로세스에/도구입니다.

DB 변경 될 수행하는 동안 프로세스를 게시 다시 당신은 어디 있는지 알 필요가 정보를 필요한 변화와 게시 프로세스/도구를 처리합니다.에 대해 무엇을 위해 사용하는 큐,주요 사람은 내가 사용 msmq 및 사용자 정의의 구현과 정보 sql server.큐은 그냥 있을 제어하는 속도의 업데이트,그래서 당신은 아무것도 필요하지 않은 특별히 대상으로 배포가 가능합니다.

Update2: 는지 확인 DB 변경은 하위 호환성을 유지합니다.이것은 정말 중요한 때,당신은 라이브 변경 다른 서버에 있습니다.

IIS 서버가 Windows Server 2003 R2 이상을 실행한다고 가정하면 확실히 조사하십시오. DFS 복제. 각 서버에는 자체 파일 사본이있어 다른 많은 사람들이 경고했던 것처럼 공유 네트워크 병목 현상을 제거합니다. 배포는 복제 그룹의 서버 중 하나에 변경 사항을 복사하는 것만 큼 간단합니다 (전체 메쉬 토폴로지를 가정). 복제는 원격 차동 압축을 사용하여 변경된 파일의 델타 만 보내는 것을 포함하여 나머지를 자동으로 처리합니다.

우리는 각각 로컬 페이지 사본과 클러스터 오버 클러스터가 장애가있는 SQL 서버가있는 4 개의 웹 서버를 사용하는 것을 매우 기쁘게 생각합니다.

라이센스 : CC-BY-SA ~와 함께 속성

제휴하지 않습니다 StackOverflow