웹 사이트에 고 가용성을 도입 할시기는 언제입니까?

웹 사이트에 고 가용성을 도입 할시기는 언제입니까?

고 가용성 옵션에 대한 기사가 많이 있습니다. 그러나 WHEN이 단일 서버에서 고 가용성 구성으로 전환하기에 적합한시기는 분명하지 않습니다.

내 상황을 고려하십시오 :
http://www.postjobfree.com 은 트래픽이 많은 24/7 웹 사이트입니다 :
http://www.similarweb.com/website/postjobfree.com

현재 단일 서버에서 실행합니다. IIS 7.0 웹 서버와 SQL Server 2008은 모두 동일한 하드웨어 상자에서 실행됩니다.

일반적으로 일부 Windows Server 업데이트에 필요한 재부팅으로 인해 ~ 5 분의 다운 타임이 발생하는 경우가 있습니다 (한 달에 ~ 1 회). 일반적으로 다운 타임은 예정되어 있으며 밤에 발생합니다. Google Bot과 일부 사용자는 여전히 밤에 활동하기 때문에 여전히 불쾌합니다.

현재 웹 사이트 수익은 ~ $ 8K / 월입니다.

두 개의 서버 구성 (두 개의 웹 서버의 웹 팜과 두 개의 하드웨어 서버에서 호스팅되는 두 개의 SQL Server 클러스터)로 전환하는 것을 고려합니다.

장점 :
1) 고 가용성 (이론적으로 다운 타임 없음). 서버 중 하나가 다운 되더라도 다른 서버가 대신합니다.
2) 데이터 손실 없음 : SQL 클러스터가 없으면 하드웨어 고장 (일일 백업)시 최대 하루의 데이터가 손실 될 수 있습니다.

단점 :
1) 그러한 구성을 설정하고 유지하기위한 더 많은 노력.
2) 더 높은 호스팅 비용. ~ 600 달러 / 월 대신 약 1200 달러 / 월입니다.

당신의 추천은 무엇입니까?

짧은 대답 : 가동 중지 시간이나 그 위험으로 인해 고 가용성을 유지하는 데 드는 비용보다 더 많은 비용이 소요됩니다.

근본적으로 경제적 인 결정입니다. 예로서. 월 $ 8k는 2 시간의 정전으로 인해 $ 22가 소요됨을 의미합니다. 2 시간 내에 처음부터 완전한 기능을 갖춘 사이트로 이동할 수 있도록 시스템을 구성 할 수 있으면 고 가용성은 그보다 22 달러의 기능 만 제공합니다.

달리 말하면, 주어진 달에 예방할 수없는 다운 타임이 54 시간이 될 때까지는 비용을 절약 할 수 있습니다.

이해 당사자 / 사업자 (당신이 될 수 있음)가 결정해야합니다.

• 수용 가능한 수익 손실
• 평판 상실, 존중 등
• 수용 가능한 데이터 손실 ( 복구 지점 목표 )
• 허용 가능한 가동 중지 시간 ( 복구 시간 목표 )

수익 손실은 정량화하기 쉽습니다. 나머지는 여기에 대답 할 수 없습니다. 죄송합니다 ...

대부분의 사용자는 약간의 예정된 다운 타임을 처리 할 수 ​​있다고 생각합니다. ebay는 금요일 밤에 매주 업데이트되며 입찰가가 작동하지 않는 것을 고려하십시오. 저의 (주요 호주) 은행의 온라인 뱅킹은 매주 몇 시간 동안 중단 될 예정입니다. 트위터는 항상 오프라인 상태가됩니다. Heroku / EC2는 최근 며칠 동안 다운되었습니다.

한 달에 5 분만 이야기한다면 sysadmin으로 일을 잘하고 있습니다.

인덱싱 측면에서 Google을 이미 언급했지만 대기 시간 / 사이트 응답 성이 SEO에 미치는 영향을 고려할 가치가 있습니다. 그것은 블랙 박스이며 수량화하기가 어렵습니다.하지만 가치가 있지만 Matt Cutts는 하나의 중심이라고 생각 합니다. 다른 사람들이 말했듯이 평판에 대해 더 걱정하고 싶습니다.

보안과 마찬가지로 HA는 제품이 아니라 프로세스라는 점을 명심하십시오.

예를 들어, 데이터베이스 복제는 데이터베이스의 각 미러가 자체적으로 계속 작동 할 수있는 지점까지만 제공하지만 장애가 발생한 구성 요소를 교체 한 후 재 동기화 전략도 필요합니다.

예를 들어 주문 시스템을 고려하십시오. 고객이 주문을 제출하고 처리하는 동안 주문 정보를 로컬 데이터베이스 사본에 저장 한 후 대화하려는 실제 시스템이 실패합니다. 초조 한 고객이 "제출"을 다시 누르면 다른 서버로 연결되어 주문을 수락합니다. 다른 쪽에서 누락 된 INSERT 문을 재생하여 데이터베이스를 다시 동기화하면 순서가 복제되므로 원하는 순서가 아닐 수 있습니다.

@Slartibartfast가 제안한 것처럼, 그것은 모두 경제적 인 결정으로 귀결되지만, 앞으로 몇 년 동안 계획을 세우는 것이 좋습니다. 적절한 HA 설정이 필요할 것으로 예상되면 이제 준비 작업을위한 리소스를 따로 보관 해 두어야합니다.

당신이 이것에 대해 생각하는 동안 나는 당신이 "고래 고래"페이지를 설정하는 것을 고려한다고 생각합니다.

이 작업을 수행하는 방법은 많이 있지만 route53과 s3의 aws 콤보는 내 작은 사이트에서 잘 작동합니다.

장애가 발생했을 때 DNS가 사용자를 사용자에게 s3에있는 정적 html 페이지로 보내도록 상태 확인으로 도메인을 설정했습니다. 아무것도 아닌 비용.

귀하의 사이트에서 "죄송합니다.하지만 문제가 발생했습니다."라고 말하면서 사용자에게 차이가 생깁니다. 사용자와 커뮤니케이션 할 수있는 Twitter 계정이 더 좋습니다.

이는 중단으로 인한 가장 큰 영향을 줄 수있는 "평판 손실"을 완화하는 데 오랜 시간이 걸렸습니다.

https://aws.amazon.com/blogs/aws/create-a-backup-website-using-route-53-dns-failover-and-s3-website-hosting/ 을 참조하십시오 .

DynDns의 소셜 페일 오버 http://dyn.com/managed-dns/social-failover/ 는 비슷한 종류의 것입니다.

DNS 레코드의 TTL이 낮고 프로그래밍 방식으로 조작 할 수있는 방법이 있다면 스스로 롤업하고 상태 점검을 수행 한 다음 DNS 변경 사항을 스크립팅 할 수 있습니다.

융통성있게 확장하고 단점을 무효화 할 수있는 EC2와 같은 것을 사용하는 것을 고려 했습니까? EC2를 사용하는 것이 가치가 있는지 아닌지는 궁극적으로 경제적 인 결정이지만, 적어도 고려해야 할 옵션입니다.

데이터 손실을 방지하려면 클러스터 전에 Raid 구성을 조사해야합니다. 또한 DNS 전파를 기다릴 필요없이 재해 발생시 한 서버에서 다른 서버로 전환 할 수있는 장애 조치 IP를 구성해야합니다.