내 A 웹 서버의 연결이 끊어지면 모든 사용자를 다른 도시의 내 B 웹 서버로 자동 리디렉션하거나 그 반대의 경우는 어떻게합니까?

내 A 웹 서버의 연결이 끊어지면 모든 사용자를 다른 도시의 내 B 웹 서버로 자동 리디렉션하거나 그 반대의 경우는 어떻게합니까?

로드 밸런싱 스위치는 두 웹 서버가 모두 같은 건물에 있지 않으면 작동하는 방법을 알 수 없다는 점을 제외하고 원하는 작업을 수행합니다.

고 가용성 클러스터링 시스템은 두 웹 서버가 모두 같은 건물에 있지 않으면 작동하는 방법을 알 수 없다는 점을 제외하고 원하는 작업을 수행합니다.

" 주 웹 서버가 다운되었을 때 다른 웹 서버의 정적 페이지로 리디렉션 "에 대한 대답 은 두 도시에서 웹 서버를 지원하는 것으로 보입니다. 그러나 한 상자에 소프트웨어를 설치하면 해당 상자의 플러그를 뽑은 후에 어떻게 도움이됩니까?

어떻게 라운드 로빈 DNS 및 콘텐츠 전달 네트워크 (CDN 서비스는) 그것은 무엇입니까?

하나의 접근법이 다음과 같이 시작한다고 가정합니다.

1. 실제 웹 서버 각각의 IP 주소를 얻습니다.
2. "물리적"웹 사이트의 단일 도메인 이름 (여러 A 레코드 또는 AAAA 레코드 또는 둘 다)에 대한 실제 웹 서버 각각의 IP 주소를 DNS 레코드에 넣었습니다.
3. ... 그러면 어떻게해야합니까?

다른 접근법이 다음과 같이 시작한다고 가정합니다.

1. 사용자가 웹 브라우저에 입력 할 것으로 예상되는 단일 도메인 이름에 일부 동적 DNS 공급자를 사용합니다.
2. 각 웹 서버에서 주기적으로 DNS 공급자에게 자체 IP 주소 (A 레코드 또는 AAAA 레코드 업데이트) 또는 자체 도메인 이름 (CNAME 레코드 또는 DNAME 레코드 업데이트)을 알려주는 cron 작업을 설정했습니다.
3. ... 그러면 어떻게해야합니까?

(현재로서는 사용자에게 웹 서버 A의 플러그를 뽑을 때마다 내 연락처 정보가 포함 된 정적 웹 페이지와 "메인 A 웹 서버가 다운 된 것 같습니다"라는 각주가 있으면 기쁠 것입니다. 단순히 "서버를 찾을 수 없음"오류가 발생하는 현재 시스템입니다. 이상적으로 A와 B가 완전히 동기화되고 분명히 동일하기를 원하지만 다른 질문 은 CDN과 동일하지만 동적 내용에 대한 것입니까? ).

GSLB (Global Server Load Balancing) 솔루션을 찾고있는 것 같습니다. GSLB는 일반적으로 "스마트"DNS를 사용하여 여러 매개 변수 (예 : 서버를 사용할 수 없음, 높은로드, IP 위치 정보 등)에 따라 다른 서버로 사용자를 안내합니다.

예를 들어, 하나는 서쪽 (10.10.10.1/24)과 하나는 동쪽 (10.20.20.1/24) 인 두 개의 웹 서버가 있다고 가정하십시오. 웹 호스트 이름이 www.connect.com이라고 가정하십시오.

GSLB는 DNS 또는 CNAME으로 구성 할 수 있습니다. 어떤 방법 으로든 사용자가 www.connect.com에 입력하면 dns 쿼리는 GSLB 솔루션으로 보내지고 매개 변수에 따라 10.10.10.1 또는 10.20.20.1로 응답합니다. GSLB는 일반적으로 낮은 TTL을 설정하므로 클라이언트 호스트 / 브라우저는 가능한 한 적은 시간 동안 응답을 캐시합니다. 지속성을 해결하는 방법에는 여러 가지가 있지만이 시나리오의 범위를 벗어납니다.

동쪽 (10.20.20.1) 웹 서버가 다운되었다고 가정하겠습니다. GSLB는 일반적으로 백엔드 노드의 상태를 확인하기 위해 상태 확인을 구현합니다. GSLB 통지 동부가 다운되었으며 www.connect.com에 대한 모든 후속 dns 레코드는 10.10.10.1로 해석됩니다.

로컬 서버로드 밸런싱 솔루션 (SLB)이있는 경우 www.connect.com이 두 개의 백엔드 노드 (10.10.10.1/24 및 10.20.20.1/24). 기술적으로 로컬 SLB가 다른 서버에 도달 할 수있는 한 노드는 다른 네트워크 세그먼트에있을 수 있습니다. 백엔드 노드가 다운되면 SLB 솔루션이 사용자를 사용 가능한 서버로 리디렉션 할 수있을 정도로 똑똑 할 수 있습니다. F5 LTM을 사용하는 경우 이러한 이벤트에 대한 iRule을 쉽게 만들 수 있습니다. Citrix NetScaler 및 기타 SLB 솔루션에도 비슷한 기능이 있어야합니다.

이 경우 RR DNS가 작동하지 않습니다. RR DNS에는 인텔리전스가 내장되어 있지 않습니다. DNS 사용 사례를 수행 할 수있는 유일한 방법은 GSLB (또는 유사한) 솔루션을 통해 일종의 "스마트"DNS를 사용하는 것입니다.

CDN은 일반적으로 고객에게 HA를 보장하기 위해 GSLB / SLB 솔루션을 구현합니다.

F5 및 Cisco make와 같은 글로벌로드 밸런서를 조사하려고합니다. 기본적으로 파트너가 중단 된 경우 DNS를 사용하여 트릭을 수행하고 파트너가 가동 된 경우로드 밸런서를 통해 상대방에게 데이터를 공급합니다.

저렴하고 빠르고 안정적인 평가를위한 또 다른 솔루션은 Amazon Route 53 장애 조치 ( http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/health-checks-creating.html)를 사용하는 것 입니다. 이 기능은 2013 년 2 월 11 일에 릴리스되었으며 기본 사이트와 보조 사이트 간의 고 가용성 및 / 또는로드 밸런싱을 제공합니다.

아심

환경에서 어떤 종류의 리버스 프록시를 사용 중인지 알려 주면 백업 서버로 리디렉션 할 수 있습니다.

그렇지 않으면 F5를 사용하는 것이 좋습니다.

또한 타사 도메인 등록 기관에 도메인을 등록한 경우 DNS 서버 구성을 가져 와서 새 서버 또는 백업 서버로 리디렉션 할 수 있습니다.

최소한 다음 두 가지 방법을 사용하여 네트워크 어플라이언스를 사용하지 않고도이 작업을 수행 할 수 있지만 변경 제어가 필요합니다.

• 리버스 프록시, 프록시 후보에서 플러그를 뽑을 서버를 제거해야합니다.

• DNS, 미리 계획하고 DNS를 변경하고 TTL이 통과 할 때까지 기다려야합니다.

특히 라우팅 프로토콜을 사용하여 정적 페이지를 제공하는 웹 서버에 대해 자동로드 밸런싱 및 액티브-액티브 페일 오버를 수행 할 수도 있습니다. EGP 및 IGRP를 확인하십시오. 라우터를 통해 둘 이상의 호스트에서이를 수행하는 방법을 자세히 설명하는 온라인 자료 (특히 Cisco 관련 자료)가 있어야합니다.