다음을 통해 공유

고가용성 및 확장성 달성 - ARR 및 하드웨어 Load Balancer

  • 아티클

작성자: 원유

고가용성 및 확장성 달성:
IIS 7.0 이상 및 하드웨어 Load Balancer 대한 Microsoft ARR(애플리케이션 요청 라우팅)입니다.

Microsoft Corporation F5
저자: 원유 저자: 라이언 코록
게시 날짜: 2008년 11월 13일

요약

이 문서에서는 ARR(애플리케이션 요청 라우팅)을 하드웨어 부하 분산 장치와 함께 사용하여 고가용성 및 확장성을 달성하는 방법에 대한 규범적인 지침을 제공합니다. 이 문서에서는 F5 BIG-IP 부하 분산 장치를 사용하여 ARR과 하드웨어 부하 분산 장치 간의 작동 관계를 보여 줍니다.

개요

IIS 7.0 이상용 Microsoft ARR(애플리케이션 요청 라우팅)은 HTTP 헤더, 서버 변수 및 부하 분산 알고리즘을 기반으로 콘텐츠 서버에 HTTP 요청을 전달하는 프록시 기반 라우팅 모듈입니다. 일반적인 ARR 배포는 아래 다이어그램에 나와 있습니다.

일반적인 A R R 배포 다이어그램 R R은 콘텐츠 서버에 대한 고가용성 및 확장성을 제공합니다.

ARR은 콘텐츠 서버에 고가용성 및 확장성을 제공하지만 다음과 같은 이유로 전체 배포를 고가용성 또는 확장성이 없습니다.

  • ARR은 단일 실패 지점입니다.
  • 콘텐츠 서버의 확장성은 하나의 ARR 서버의 최대 용량으로 제한됩니다.

이러한 문제를 해결하기 위해 관리자는 F5 BIG-IP와 같은 하드웨어 부하 분산 장치와 함께 여러 ARR 서버를 사용하는 것을 고려할 수 있습니다. 고가용성 또는 활성/활성 모드에서만 고가용성 및 확장성을 달성하기 위해 ARR을 활성/수동 모드로 배포할 수 있습니다. 이 백서에서는 전반적인 고가용성 및 확장성을 달성하면서 핵심 ARR 시나리오를 사용하도록 ARR 및 F5 BIG-IP를 함께 배포하는 방법을 설명합니다.

애플리케이션 요청 라우팅 및 F5 BIG-IP 사용

ARR은 IIS를 기반으로 모듈로 빌드되며 계층 7(애플리케이션)에서 라우팅 결정을 내릴 수 있도록 설계되었습니다. 보다 정확하게 말하면 ARR은 다른 IIS 모듈 인 URL 다시 쓰기를 사용하여 들어오는 HTTP 요청 헤더 및 서버 변수를 검사하여 라우팅 결정을 내립니다. 이 디자인을 고려할 때 관리자는 다음과 같은 애플리케이션 수준 정보를 기반으로 지능형 라우팅 규칙을 작성할 수 있습니다.

  • 호스트 이름(HTTP_HOST): 호스트 이름에 따라 트래픽을 다른 콘텐츠 서버로 라우팅합니다.
  • 요청된 리소스(URL): 파일 확장자를 기반으로 요청된 리소스가 정적 콘텐츠용인지 동적 콘텐츠인지 확인하고 그에 따라 요청을 라우팅합니다.
  • 클라이언트 정보(HTTP_USER_AGENT): 브라우저 유형 및 버전에 따라 요청을 적절한 콘텐츠 서버로 라우팅합니다.
  • 사용자 지정 헤더(애플리케이션별 쿠키로 설정): 사용자 기본 설정 또는 사용자 ID와 같은 애플리케이션에서 설정한 쿠키 정보를 기반으로 트래픽을 라우팅합니다.

위의 예는 몇 가지 예에 불과합니다. HTTP 헤더 및 서버 변수의 전체 목록은 부록 A를 참조하세요.

F5 Big-IP의 계층 3 및 계층 4 기능은 HTTP 헤더 및 서버 변수와 같은 계층 7을 기반으로 라우팅 결정을 내리는 ARR의 강점을 보완합니다. 동시에 ARR은 자체에 내결함성 배포 기능을 제공하지 않으며 아래와 같이 ARR 계층에 대한 고가용성을 달성하기 위해 다른 보완 기술 및 솔루션에 의존해야 합니다.

F5 Big dash I P 계층 3 및 4 기능 다이어그램 F5 Big dash I P 계층 3 및 레이어 4는 계층 7을 기반으로 라우팅 결정을 내리는 데 있어 A R R 강도를 보완합니다.

시나리오 1: HTTP 기반 라우팅 및 부하 분산

HTTP 기반 라우팅 및 부하 분산 시나리오를 사용하면 다음을 포함하는 3계층 배포 아키텍처를 사용할 수 있습니다.

  • 계층 1(웹): 정적 콘텐츠를 처리하고 나머지 동적 요청을 계층 2 서버로 라우팅 및 부하 분산하는 이중 목적을 제공합니다.
  • 계층 2(애플리케이션): 비즈니스 논리에 의존하는 동적 콘텐츠를 처리합니다.
  • 계층 3(데이터): 데이터를 저장합니다.

다음 다이어그램에서는 3계층 배포를 보여 줍니다.

3계층 배포를 보여 주는 다이어그램 동적 콘텐츠를 형성하는 정적 콘텐츠를 구분하는 라우팅 규칙을 보여줍니다.

위의 예제에서는 정적 콘텐츠를 동적 콘텐츠와 구분하는 라우팅 규칙을 보여 주지만, 또 다른 일반적인 시나리오는 웹 서비스 요청과 프레젠테이션 요청을 구분하는 것입니다.

옵션 1: 활성/수동

활성/수동 모드에서는 일반적으로 한 서버가 요청을 처리하는 두 개의 ARR 서버가 있고 다른 서버는 장애 조치(failover) 서버로 대기합니다. 위에서 설명한 것처럼 이 구성은 단일 실패 지점을 제거하여 고가용성을 달성하지만 콘텐츠 서버의 집계 용량이 하나의 ARR 서버의 최대 용량으로 제한되기 때문에 스케일 아웃 솔루션이 아닙니다.

이 설정에서는 두 ARR 서버가 동일한 방식으로 구성되므로 공유 구성이 사용됩니다. F5 BIG-IP는 모든 요청을 활성 ARR 서버로 라우팅하고 필요한 경우 수동 ARR 서버로만 요청을 라우팅하도록 구성됩니다.

ARR의 호스트 이름 선호도 기능을 제외하고 두 ARR 서버 간에 공유해야 하는 런타임 상태 정보는 없습니다. 따라서 이 시나리오에서는 ARR 서버나 F5 BIG-IP에 특별한 구성이 필요하지 않습니다. ARR에서 서버 선호도 기능을 사용하는 경우에도 F5 BIG-IP가 이전에 수동적이면서도 현재 활성 서버로 요청을 라우팅할 때 선호도가 높은 상태 정보는 요청 헤더의 쿠키를 통해 수동 서버에 제공됩니다.

이 시나리오는 ARR 버전 1 릴리스에서 완전히 지원됩니다.

ARR 구성

1단계: 두 ARR 서버에서 공유 구성을 사용하도록 설정합니다.

  • 이 문서의 단계에 따라 IIS에서 공유 구성을 설정합니다.

2단계: ARR을 사용하여 3계층 배포 아키텍처를 구성합니다.

  • 이 문서의 단계에 따라 3계층 배포 아키텍처에서 ARR을 구성합니다.

  • 높은 수준에서 위의 문서에서는 다음을 설명합니다.

    • ARR 서버에서 정적 콘텐츠를 사용할 수 있도록 하는 방법입니다.
    • ARR 서버에서 직접 제공되도록 정적 콘텐츠에 대한 URL 다시 쓰기 규칙을 작성하는 방법입니다.
    • 동적 콘텐츠에 대한 URL 다시 쓰기 규칙을 작성하여 애플리케이션 서버로 전달하는 방법입니다.

F5 BIG-IP 구성

이 시나리오에서는 두 개 이상의 ARR 서버 풀에 부하를 분산하는 가상 서버를 만듭니다. 선택한 부하 분산 방법은 사용할 수 없게 될 때까지 모든 트래픽을 기본 ARR 서버로 보내야 합니다. 이 시점에서 BIG-IP LTM은 모든 트래픽을 보조 ARR 서버로 보내야 합니다.

1단계: ARR 서버 풀을 구성합니다.

  • 로컬 트래픽 섹션에서 풀을 클릭합니다. 그런 다음 만들기 단추를 클릭하여 풀을 만듭니다.
  • 모든 고유한 이름은 풀에 대해 작동합니다. 이 예제에서는 ARR_Pool 사용합니다.
  • 상태 모니터의 경우 사용자 지정 HTTP 모니터 또는 기본 HTTP 모니터를 사용할 수 있습니다.
  • 부하 분산 메서드를 라운드 로빈으로 설정할 수 있습니다. 이 시나리오에서는 활성 및 수동 ARR 서버만 있으므로 부하 분산이 사용되지 않습니다.
  • 우선 순위 그룹 활성화를 사용하도록 설정해야 합니다. 이렇게 하면 우선 순위가 가장 높은 서버로 트래픽을 보내도록 BIG-IP가 구성됩니다. 해당 서버를 사용할 수 없는 경우 BIG-IP는 다음으로 높은 우선 순위 값으로 ARR 서버로 트래픽을 보냅니다.
  • 이 시나리오에서 10.0.0.1의 ARR 서버의 우선 순위 값은 1이고 10.0.0.2의 우선 순위 값은 2입니다. 모든 트래픽은 다운될 때까지 10.0.0.2로 전송되고 트래픽은 10.0.0.1로 전송됩니다.

Big dash I P 웹 페이지의 스크린샷. 상태 모니터 상자의 활성에서 h t t p가 강조 표시됩니다. 새 멤버 상자에서 A R R 서버 우선 순위 값은 10개 점 0점 0입니다.

2단계: ARR 서버 풀을 구성합니다.

  • 로컬 트래픽 섹션에서 가상 서버를 클릭합니다. 그런 다음 만들기 단추를 클릭하여 가상 서버를 만듭니다.
  • 모든 고유 이름은 가상 서버에 대해 작동합니다. 이 예제에서는 ARR_VS 사용합니다.
  • 대상의 경우 사용자가 브라우저를 가리키는 IP 주소를 사용할 수 있습니다. 이 특정 예제에서는 65.197.145.23을 사용합니다. 서비스 포트의 경우 '80'을 사용합니다.
  • 가상 서버 유형 섹션에는 몇 가지 옵션이 있습니다. 라우팅할 ARR에 의존하므로 최상의 성능을 위해 설계된 성능 HTTP를 선택할 수 있습니다.
  • 기본 풀의 경우 1단계에서 만든 풀을 선택합니다.

F5 Big I P 페이지의 스크린샷 이름 상자에 R R 밑줄 V S가 작성됩니다.

  • 이 시점에서 적절한 ARR 서버로 전송되는 이 Virtual Server에 연결할 수 있어야 합니다.

옵션 2: 활성/활성

활성/활성 모드에서는 둘 이상의 ARR 서버를 가질 수 있습니다. 이 구성은 고가용성만을 달성하는 Active/Pass 모드와 달리 고가용성과 확장성을 모두 달성합니다. 앞에서 설명한 것처럼 여러 ARR 서버가 동일한 방식으로 구성되므로 공유 구성이 사용됩니다. F5 BIG-IP는 들어오는 요청을 사용 가능하고 정상 상태인 모든 ARR 서버에 부하를 분산하도록 구성되며, 그러면 요청이 콘텐츠 서버에 전달됩니다. 서버 선호도 기능이 F5 BIG-IP에서 사용되는지 여부에 관계없이 ARR 서버에는 특별한 구성이 필요하지 않습니다. 하나의 경우 ARR 서버는 동일한 방식으로 구성되도록 하나의 공유 구성을 사용합니다. 둘째, ARR은 클라이언트 쿠키를 사용하여 자체 사용을 위해 서버 선호도 정보를 저장하므로 이 정보는 요청별로 사용할 수 있으므로 ARR 서버에서 사용할 수 있습니다. 이 시나리오는 ARR 버전 1 릴리스에서 완전히 지원됩니다.

ARR 구성

활성/활성에 대한 ARR 구성은 Active/Passive의 구성과 동일합니다. 기본 차이점은 F5를 구성하는 방법입니다.

1단계: 두 ARR 서버에서 공유 구성을 사용하도록 설정합니다.

  • 이 문서의 단계에 따라 IIS에서 공유 구성을 설정합니다.

2단계: ARR을 사용하여 3계층 배포 아키텍처를 구성합니다.

  • 이 문서의 단계에 따라 3계층 배포 아키텍처에서 ARR을 구성합니다.

  • 높은 수준에서 위의 문서에서는 다음을 설명합니다.

    • ARR 서버에서 정적 콘텐츠를 사용할 수 있도록 하는 방법입니다.
    • ARR 서버에서 직접 제공되도록 정적 콘텐츠에 대한 URL 다시 쓰기 규칙을 작성하는 방법입니다.
    • 동적 콘텐츠에 대한 URL 다시 쓰기 규칙을 작성하여 애플리케이션 서버로 전달하는 방법입니다.

F5 BIG-IP 구성

이 시나리오에서는 사용 가능한 모든 ARR 서버가 활성으로 간주되고 부하 분산된 트래픽의 후보로 간주됩니다. BIG-IP LTM을 사용하여 ARR 프런트 엔드의 상태 및 성능을 확인하고 트래픽을 최상의 성능으로 전달합니다.

1단계: ARR 서버 풀을 구성합니다.

  • 로컬 트래픽 섹션에서 풀을 클릭합니다. 그런 다음 만들기 단추를 클릭하여 풀을 만듭니다.
  • 모든 고유한 이름은 풀에 대해 작동합니다. 예제에서는 ARR_Pool 사용합니다. - 상태 모니터의 경우 사용자 지정 HTTP 모니터 또는 기본 HTTP 모니터를 사용할 수 있습니다. - 트래픽을 분산할 여러 ARR 서버가 있으므로 요구 사항에 가장 적합한 부하 분산 방법을 선택해야 합니다. 모든 ARR 서버가 유사한 하드웨어 특성을 가지고 있다고 가정하면 가장 빠른, 관찰 또는 예측과 같은 동적 부하 분산 방법은 성능 기반 배포를 제공합니다.

F5 Big I P 웹 페이지의 스크린샷 부하 분산 방법 상자에서 가장 빠른 애플리케이션이 선택됩니다.

2단계: 가상 서버를 구성합니다.

  • 로컬 트래픽 섹션에서 가상 서버를 클릭합니다. 그런 다음 만들기 단추를 클릭하여 가상 서버를 만듭니다.
  • 모든 고유 이름은 가상 서버에 대해 작동합니다. 이 예제에서는 ARR_VS 사용합니다. - 대상의 경우 사용자가 브라우저를 가리키는 IP 주소를 사용할 수 있습니다. 이 특정 예제에서는 65.197.145.23을 사용합니다. 서비스 포트의 경우 '80'을 사용합니다. - 가상 서버 유형 섹션에는 몇 가지 옵션이 있습니다. 라우팅할 ARR에 의존하므로 최상의 성능을 위해 설계된 성능 HTTP를 선택할 수 있습니다. - 기본 풀의 경우 1단계에서 만든 풀을 선택합니다.

F5 Big I P 웹 페이지의 스크린샷 기본 풀 상자에서 1단계 R R 풀에서 만든 풀이 선택됩니다.

시나리오 2: 호스트 이름 선호도를 사용한 공유 호스팅

이 시나리오에서는 ARR의 호스트 이름 선호도 기능을 활용하여 공유 호스팅 배포를 사용하도록 설정합니다.

  • 기존 공유 호스팅 배포와 관련된 수동 관리 및 유지 관리를 줄입니다.
  • 모든 서버 리소스가 균등하게 활용되도록 하면서 기존 서버 리소스를 최대화합니다.
  • 환경을 쉽게 확장할 수 있습니다.
  • 추가 용량을 판매할 수 있는 비즈니스 기회를 만듭니다.

공유 호스팅 및 ARR에 대한 자세한 내용은 이 문서를 참조하세요.

다음 다이어그램은 ARR을 사용하는 공유 호스팅 환경을 보여 줍니다. R R을 사용하는 공유 호스팅 환경의 다이어그램.

옵션 1: 활성/수동

앞에서 설명한 것처럼 활성/수동 모드에는 일반적으로 한 서버가 요청을 처리하는 두 개의 ARR 서버가 있고 다른 서버는 장애 조치(failover) 서버로 대기합니다. 이 구성은 단일 실패 지점을 제거하여 고가용성을 달성하지만 콘텐츠 서버의 집계 용량이 하나의 ARR 서버의 최대 용량으로 제한되기 때문에 스케일 아웃 솔루션이 아닙니다.

이 설정에서는 두 ARR 서버가 동일한 방식으로 구성되므로 공유 구성이 사용됩니다. F5 BIG-IP는 모든 요청을 활성 ARR 서버로 라우팅하고 필요한 경우 수동 ARR 서버로만 요청을 라우팅하도록 구성됩니다.

ARR의 호스트 이름 선호도 기능은 호스트 이름에 따라 특정 서버(또는 RC의 서버 그룹)에 대한 요청을 선호합니다. 호스트 이름과 콘텐츠 서버 간의 선호도 매핑에 대한 런타임 상태 정보는 ARR 서버의 instance 내에 메모리에 저장됩니다. ARR 버전 1 릴리스에서 ARR은 IIS용 Microsoft 외부 캐시를 활용하여 여러 ARR 서버 간에 이 런타임 상태를 공유하고 유지 관리합니다. 이 시나리오에 대한 자세한 내용은 이 문서에서 확인할 수 있습니다.

이 시나리오는 ARR 버전 1 릴리스에서 완전히 지원됩니다.

ARR 구성

1단계: 두 ARR 서버에서 공유 구성을 사용하도록 설정합니다.

  • 이 문서의 단계에 따라 IIS에서 공유 구성을 설정합니다.

2단계: ARR을 사용하여 3계층 배포 아키텍처를 구성합니다.

  • 이 문서의 단계에 따라 3계층 배포 아키텍처에서 ARR을 구성합니다.

  • 높은 수준에서 위의 문서에서는 다음을 설명합니다.

    • ARR 서버에서 정적 콘텐츠를 사용할 수 있도록 하는 방법입니다.
    • ARR 서버에서 직접 제공되도록 정적 콘텐츠에 대한 URL 다시 쓰기 규칙을 작성하는 방법입니다.
    • 동적 콘텐츠에 대한 URL 다시 쓰기 규칙을 작성하여 애플리케이션 서버로 전달하는 방법입니다.

3단계: 외부 캐시를 사용하도록 설정하고 구성합니다.

  • 이 문서의 단계에 따라 ARR과 함께 사용할 외부 캐시를 사용하도록 설정하고 구성합니다.

F5 BIG-IP 구성

이 시나리오에서는 두 개 이상의 ARR 서버 풀에 부하를 분산하는 가상 서버를 만듭니다. 선택한 부하 분산 방법은 사용할 수 없게 될 때까지 모든 트래픽을 기본 ARR 서버로 보내야 합니다. 이 시점에서 BIG-IP LTM은 모든 트래픽을 보조 ARR 서버로 보내야 합니다.

1단계: ARR 서버 풀을 구성합니다.

  • 로컬 트래픽 섹션에서 풀을 클릭합니다. 그런 다음 만들기 단추를 클릭하여 풀을 만듭니다.
  • 모든 고유한 이름은 풀에 대해 작동합니다. 이 예제에서는 ARR_Pool 사용합니다. - 상태 모니터의 경우 사용자 지정 HTTP 모니터 또는 기본 HTTP 모니터를 사용할 수 있습니다. - 부하 분산 메서드를 라운드 로빈으로 설정할 수 있습니다. 이 시나리오에서는 활성 및 수동 ARR 서버만 있으므로 부하 분산이 사용되지 않습니다. - 우선 순위 그룹 활성화를 사용하도록 설정해야 합니다. 이렇게 하면 우선 순위가 가장 높은 서버로 트래픽을 보내도록 BIG-IP가 구성됩니다. 해당 서버를 사용할 수 없는 경우 BIG-IP는 다음으로 높은 우선 순위 값으로 ARR 서버로 트래픽을 보냅니다. - 이 시나리오에서 10.0.0.1의 ARR 서버의 우선 순위 값은 1이고 10.0.0.2의 우선 순위 값은 2입니다. 모든 트래픽은 다운될 때까지 10.0.0.2로 전송되고 트래픽은 10.0.0.1로 전송됩니다.

Big I P 웹 사이트의 스크린샷 이름 상자에는 R R 밑줄 풀이 있습니다. 로컬 트래픽 창에서 풀이 선택됩니다.

2단계: 가상 서버를 구성합니다.

  • 로컬 트래픽 섹션에서 가상 서버를 클릭합니다. 그런 다음 만들기 단추를 클릭하여 가상 서버를 만듭니다.
  • 모든 고유 이름은 가상 서버에 대해 작동합니다. 이 예제에서는 ARR_VS 사용합니다. - 대상의 경우 사용자가 브라우저를 가리키는 IP 주소를 사용할 수 있습니다. 이 경우 를 사용합니다. 서비스 포트의 경우 '80'을 사용합니다. - 가상 서버 유형 섹션에는 몇 가지 옵션이 있습니다. 라우팅할 ARR에 의존하므로 최상의 성능을 위해 설계된 성능 HTTP를 선택할 수 있습니다. - 기본 풀의 경우 1단계에서 만든 풀을 선택합니다.

F5 웹 페이지의 스크린샷 기본 풀 상자에서 R R 풀이 선택됩니다. 로컬 트래픽 창에서 가상 서버가 선택됩니다.

  • 이 시점에서 적절한 ARR 서버로 전송되는 이 Virtual Server에 연결할 수 있어야 합니다.

옵션 2: ARR에서 활성/활성

활성/활성 모드에서는 둘 이상의 ARR 서버를 가질 수 있습니다. 이 구성은 고가용성만을 달성하는 Active/Pass 모드와 달리 고가용성과 확장성을 모두 달성합니다. 여러 ARR 서버가 동일한 방식으로 구성되므로 공유 구성이 사용됩니다. F5 BIG-IP는 들어오는 요청을 사용 가능하고 정상 상태인 모든 ARR 서버에 부하를 분산하도록 구성되며, 그러면 요청이 콘텐츠 서버에 전달됩니다.

앞에서 설명한 것처럼 호스트 이름과 콘텐츠 서버 간의 선호도 매핑에 대한 런타임 상태 정보는 ARR 서버의 instance 내에 메모리에 저장됩니다. 여러 ARR 서버 간에 이 정보를 공유하기 위해 IIS용 Microsoft 외부 캐시가 사용됩니다. 외부 캐시에 대한 자세한 내용은 이 문서를 참조하세요.

ARR 구성

활성/활성에 대한 ARR 구성은 Active/Passive의 구성과 동일합니다. 기본 차이점은 F5를 구성하는 방법입니다.

1단계: 두 ARR 서버에서 공유 구성을 사용하도록 설정합니다.

  • 이 문서의 단계에 따라 IIS에서 공유 구성을 설정합니다.

2단계: ARR을 사용하여 3계층 배포 아키텍처를 구성합니다.

  • 이 문서의 단계에 따라 3계층 배포 아키텍처에서 ARR을 구성합니다.

  • 높은 수준에서 위의 문서에서는 다음을 설명합니다.

    • ARR 서버에서 정적 콘텐츠를 사용할 수 있도록 하는 방법입니다.
    • ARR 서버에서 직접 제공되도록 정적 콘텐츠에 대한 URL 다시 쓰기 규칙을 작성하는 방법입니다.
    • 동적 콘텐츠에 대한 URL 다시 쓰기 규칙을 작성하여 애플리케이션 서버로 전달하는 방법입니다.

3단계: 외부 캐시를 사용하도록 설정하고 구성합니다.

  • 이 문서의 단계에 따라 ARR과 함께 사용할 외부 캐시를 사용하도록 설정하고 구성합니다.

F5 BIG-IP 구성

이 시나리오에서는 사용 가능한 모든 ARR 서버가 활성으로 간주되고 부하 분산된 트래픽의 후보로 간주됩니다. BIG-IP LTM을 사용하여 ARR 프런트 엔드의 상태 및 성능을 확인하고 트래픽을 최상의 성능으로 전달합니다.

1단계: ARR 서버 풀을 구성합니다.

  • 로컬 트래픽 섹션에서 풀을 클릭합니다. 그런 다음 만들기 단추를 클릭하여 풀을 만듭니다.
  • 모든 고유한 이름은 풀에 대해 작동합니다. 이 예제에서는 ARR_Pool 사용합니다. - 상태 모니터의 경우 사용자 지정 HTTP 모니터 또는 기본 HTTP 모니터를 사용할 수 있습니다. - 트래픽을 분산할 여러 ARR 서버가 있으므로 요구 사항에 가장 적합한 부하 분산 방법을 선택해야 합니다. 모든 ARR 서버가 유사한 하드웨어 특성을 가지고 있다고 가정하면 가장 빠른, 관찰 또는 예측과 같은 동적 부하 분산 방법은 성능 기반 배포를 제공합니다.

F5 웹 페이지의 스크린샷 로컬 트래픽 상자에서 풀이 선택됩니다. 부하 분산 방법 상자에서 가장 빠른 애플리케이션이 선택됩니다.

2단계: 가상 서버를 구성합니다.

  • 로컬 트래픽 섹션에서 가상 서버를 클릭합니다. 그런 다음 만들기 단추를 클릭하여 가상 서버를 만듭니다.
  • 모든 고유 이름은 가상 서버에 대해 작동합니다. 이 예제에서는 ARR_VS 사용합니다. - 대상의 경우 사용자가 브라우저를 가리키는 IP 주소를 사용할 수 있습니다. 이 경우 를 사용합니다. 서비스 포트의 경우 '80'을 사용합니다. - 가상 서버 유형 섹션에는 몇 가지 옵션이 있습니다. 라우팅할 ARR에 의존하므로 최상의 성능을 위해 설계된 성능 HTTP를 선택할 수 있습니다. - 기본 풀의 경우 1단계에서 만든 풀을 선택합니다.

F5 웹 페이지의 스크린샷 로컬 트래픽 상자에서 가상 서버가 선택됩니다. 기본 풀 상자에서 R R 풀이 선택됩니다.

요약

이 백서에서는 여러 ARR 서버를 배포하고 F5 BIG-IP를 사용하여 고가용성 및 확장성을 달성하기 위해 두 가지 기본 ARR 시나리오를 검토했습니다.

부록

부록 A: 라우팅 의사 결정 규칙을 작성하는 데 사용할 수 있는 모든 HTTP 헤더 및 서버 변수입니다.

ALL_HTTP ALL_RAW APPL_MD_PATH
APPL_PHYSICAL_PATH CERT_COOKIE CERT_FLAGS
CERT_ISSUER CERT_KEYSIZE CERT_SECRETKEYSIZE
CERT_SERIALNUMBER CERT_SERVER_ISSUER CERT_SERVER_SUBJECT
CERT_SUBJECT CONTENT_LENGTH CONTENT_TYPE
DOCUMENT_ROOT GATEWAY_INTERFACE HTTP_ACCEPT
HTTP_ACCEPT_ENCODING HTTP_ACCEPT_LANGUAGE HTTP_CONNECTION
HTTP_CONTENT_LENGTH HTTP_HOST HTTP_IF_MODIFIED_SINCE
HTTP_IF_NONE_MATCH HTTP_REFERER HTTP_UA_CPU
HTTP_USER_AGENT HTTPS HTTPS_KEYSIZE
HTTPS_SECRETKEYSIZE HTTPS_SERVER_ISSUER HTTPS_SERVER_SUBJECT
INSTANCE_ID INSTANCE_META_PATH LOCAL_ADDR
PATH_INFO PATH_TRANSLATED QUERY_STRING
REMOTE_ADDR REMOTE_HOST REMOTE_PORT
REMOTE_USER REQUEST_FILENAME REQUEST_METHOD
REQUEST_URI SCRIPT_FILENAME SCRIPT_NAME
SERVER_ADDR SERVER_NAME SERVER_PORT
SERVER_PORT_SECURE SERVER_PROTOCOL SERVER_SOFTWARE
URL