구성
이 자동화된 페일오버 솔루션을 배포하려면 로드 밸런서를 구성하고, 알람 및 통지를 설정하고, 함수를 생성하고, OCI API 게이트웨이를 구성해야 합니다.
아래 단계는 자세히 설명되어 있습니다.
- 이 프로세스는 보조 리스너 및 재지정 동작을 제어하기 위한 특정 규칙 세트를 설정해야 하는 로드 밸런서를 준비하는 것으로 시작됩니다.
- 그런 다음 응용 프로그램 서버가 모두 비정상 상태이고 정상 서버가 사용 가능해지는 경우 작업을 트리거하도록 알람 및 통지를 구성합니다.
- 그런 다음 현재 알람 상태를 기반으로 로드 밸런서 규칙 집합의 첨부 또는 분리를 프로그래밍 방식으로 제어하는 OCI 함수를 사용하여 경매를 배포하여 핵심 자동화를 사용으로 설정합니다.
- 마지막으로 사용자정의 정적 유지보수 페이지를 호스팅하도록 OCI API Gateway를 구성합니다.
이러한 각 구성은 친숙한 유지 관리 페이지로 원활하고 자동화된 페일오버를 수행할 수 있도록 하는 특정 통합 역할을 수행합니다.
로드 밸런서를 구성합니다.
이 솔루션의 기반은 이미 애플리케이션을 처리하고 백엔드 서버 간에 트래픽을 분산하는 로드 밸런서에 있습니다. 이러한 단계에서는 응용 프로그램 리스너(HTTP 또는 HTTPS), 건전성 검사가 구성된 백엔드 집합, 인터넷 게이트웨이를 통한 경로 지정 등 대부분의 배치 필요 조건이 이미 준비되어 있다고 가정합니다.
애플리케이션에 대한 일반 트래픽을 처리하도록 구성된 로드 밸런서의 기본 리스너로 시작합니다. 모든 항목이 정상적으로 작동하면 이 리스너는 VM 인스턴스의 백엔드 집합으로 들어오는 요청의 경로를 지정합니다. 표준 포트(HTTP/80 또는 HTTPS/443)에서 수신하며 건전성 검사는 정상 VM만 트래픽을 수신하는지 확인합니다.
유지 관리 페이지를 제공하려면 로드 밸런서에서 두번째 리스너를 추가합니다. 응용 프로그램 리스너와 달리 이 리스너는 응용 프로그램 서버로 요청을 전달하지 않습니다. 대신 백엔드 집합은 정적 오류 페이지 호스팅을 담당하는 OCI API Gateway 인스턴스를 가리킵니다. 이러한 분리는 모든 애플리케이션 서버의 작동이 중지되더라도 로드 밸런서가 고가용성 API 게이트웨이를 통해 브랜드 및 정보 유지 관리 페이지를 계속 제공할 수 있도록 보장합니다. 보조 리스너 및 API 게이트웨이 단계 생성은 선택사항입니다. 유지보수 페이지는 인터넷 어디에서나 호스팅할 수 있습니다.
이러한 두 리스너 간의 핸드오프는 규칙 집합을 통해 관리됩니다. 규칙 집합은 응용 프로그램 리스너에 연결되며 트래픽을 재지정할 조건을 정의합니다. 일반적인 상황에서 리스너는 응용 프로그램 서버로 직접 트래픽을 전송합니다. 그러나 응용 프로그램 서버가 건전성 검사를 실패하면 규칙 집합이 실행됩니다. 로드 밸런서는 유지 관리 리스너로 트래픽을 재지정하도록 로드 밸런서에 알려줍니다. 그러면 API 게이트웨이에서 호스팅되는 사용자정의 페이지가 제공됩니다.
다음 단계에서는 사용자를 유지 관리 페이지로 재지정하는 데 사용되는 규칙 세트를 생성하는 방법에 대해 설명합니다.
알람 정보
알람은 감지와 동작 사이의 다리 역할을 합니다.
OCI 모니터링은 VM 백엔드 집합의 상태를 포함하여 로드 밸런서를 포함하여 배포 구성요소의 건전성 측정항목을 수신합니다. OCI 알람에서 구성한 알람 조건이 충족되면(예: 모니터링되는 모든 VM이 1분 이상 비정상 상태임) 즉시 통지가 트리거됩니다. 이 통지는 인간 관리자만을 위한 것이 아닙니다. OCI 통지를 통해 경로를 지정하여 OCI 함수와 함께 배치된 사용자정의 함수를 호출할 수 있습니다. 이 함수는 로드 밸런서 구성을 변경하여 커스텀 오류 페이지를 표시합니다.
함수로 전송되는 통지 메시지에는 차원(측정항목 이벤트가 속한 리소스 및 VM의 백엔드 집합을 설명하는 키-값 쌍)이 포함됩니다.
알람 구성 본문에 다음 코드가 포함됩니다.
{{dimensions.resourceId}},{{dimensions.backendSetName}},<name of the ruleset>
이 표에서는 이 알람 본문의 구성 요소에 대해 설명합니다.
| Element | 설명 | 용도 |
|---|---|---|
{{dimensions.resourceId}} |
측정항목 이벤트를 생성한 로드 밸런서 리소스의 OCID | 함수는 이 OCID를 사용하여 규칙 집합 업데이트가 필요한 로드 밸런서를 식별합니다. |
{{dimensions.backendSetName}} |
비정상으로 전환된 백엔드 집합의 이름 | 함수는 실패한 백엔드 집합을 검증하거나 기록할 수 있습니다. 여러 백엔드 집합이 있는 동적 환경에 유용합니다. |
<name of the ruleset> |
정적 값(문자열) — 모든 백엔드가 비정상일 때 연결될 규칙 집합의 이름입니다. | 트리거될 때 적용할 규칙 집합을 함수에 알립니다. |
이 설계를 통해 동일한 기능을 재사용하여 서버 유지 관리 페이지를 표시하도록 로드 밸런서 구성, 서비스가 복원되면 실제 애플리케이션으로 트래픽 경로 지정과 같은 작업을 처리할 수 있습니다. 이 접근 방식을 적용하여 OCI 배포 전반의 로드 밸런서에서 모든 로드 밸런서 또는 애플리케이션을 관리할 수도 있습니다.
OCI 로드 밸런서 서비스는 네임스페이스 oci_lbaas에 Unhealthybackendserver이라는 측정항목을 자동으로 게시합니다. 각 백엔드 집합에서 비정상 백엔드 수를 추적합니다.
이 솔루션의 경우 이 척도의 중요한 항목은 다음과 같습니다.
- 설명
- 차원
- 호랑이 법칙
- 메시지 그룹화
이 솔루션에서는 모든 백엔드 서버(VM)가 비정상 상태가 되면 알람이 트리거되어야 합니다. 즉, 비정상 서버 수는 세트의 총 백엔드 서버 수보다 크거나 같아야 합니다.
다음은 알람 트리거 규칙 질의의 예입니다.
UnHealthyBackendServers[1m]{lbName = <name of lb>, backendSetName = <name of the backend set>}.max() >= 1query는 다음으로 변환됩니다.
- 비정상 백엔드의 최대 수가 특정 값보다 크거나 같은 경우(이 예에서는 1)
- 정의된 1분 기간 동안.
- 그런 다음 알람이
FIRING상태로 전환됩니다.
그러나 이 동적 값 채우기는 메시지 그룹화에서 분할 통지가 사용으로 설정된 경우에만 작동합니다. 분할 통지는 OCI가 모든 항목을 함께 그룹화하는 대신 차원 값당 하나의 통지를 보내도록 강제합니다. 이로 인해 사용자정의 함수에 도달하는 알람 통지에는 정확한 로드 밸런서 OCID와 실패가 발생한 정확한 백엔드 집합 이름이 포함됩니다. 따라서 로드 밸런서 세부정보를 하드 코딩하지 않고도 여러 로드 밸런서, 백엔드 집합 또는 환경에서 동일한 함수를 완전히 재사용할 수 있습니다.
이 구성을 통해 전체 자동화 체인이 작동할 수 있습니다. 알람은 동적 컨텍스트를 게시하고, 함수는 이를 읽고, 최종 사용자에게 애플리케이션을 제공하는 정확한 리스너에서 올바른 규칙 집합 첨부를 수행합니다.
함수 생성
자동화의 핵심은 모든 애플리케이션 백엔드가 비정상임을 알릴 때마다 트리거되는 기능입니다.
함수의 역할은 간단하면서도 강력합니다. 트래픽 재지정을 처리하는 규칙 세트를 연결하거나 분리하여 로드 밸런서 구성을 동적으로 업데이트합니다.
함수 내의 Python 코드는 다음 세 가지 논리적 단계를 따릅니다.
- OCI를 사용한 인증: 이 함수는 Resource Principal을 사용하여 OCI와의 보안 세션을 설정하는 것부터 시작됩니다(이를 통해 OCI의 함수가 키를 수동으로 관리하지 않고도 다른 OCI 서비스를 호출할 수 있습니다). 이렇게 하면 코드가 로드 밸런서 서비스와 안전하게 상호 작용할 수 있습니다. 인증에 대한 자세한 내용은 자세히 탐색의 링크를 참조하십시오.
- 로드 밸런서 리스너 수정을 위한 API 호출: 인증된 코드는 로드 밸런서 API를 호출합니다.
- 백엔드가 실패할 경우 함수는 재지정 규칙 집합을 응용 프로그램 리스너에 연결하여 유저를 커스텀 오류 페이지로 재지정합니다.
- 백엔드가 복구되면 함수가 규칙 세트를 분리하여 응용 프로그램 서버에 대한 일반 트래픽 플로우를 복원합니다.
- 로깅 및 검증: 이 코드에는 간단한 로깅도 포함되어 있으므로 관리자가 수행된 작업(예: "listener-1에 연결된 유지 관리 페이지 규칙 집합")을 추적할 수 있습니다. 이는 문제 해결 또는 감사 중에 매우 유용합니다.
다음 예제 Python 코드를 사용하여 Oracle Functions에서 함수를 생성하고 필요에 따라 수정합니다.
Function.py
import io
import json
import os
import oci
from fdk import response
import logging
def handler(ctx, data: io.BytesIO=None):
message = "start of function"
logging.getLogger().info("HTTP function start")
try:
payload_bytes = data.getvalue()
if payload_bytes == b'':
raise KeyError('No keys in payload')
body1 = json.loads(payload_bytes)
type1 = body1["type"]
query = body1["body"]
load_balancer_ocid = query.split(",")[0]
maintenance = query.split(",")[2]
signer = oci.auth.signers.get_resource_principals_signer()
load_balancer_client = oci.load_balancer.LoadBalancerClient(config={}, signer=signer)
load_balancer_client_composite_ops = oci.load_balancer.LoadBalancerClientCompositeOperations(load_balancer_client)
load_balancer_data = json.loads(str(load_balancer_client.get_load_balancer(load_balancer_ocid).data))
lb_config = load_balancer_data['listeners']
list1 = json.dumps(lb_config)
for key,value in json.loads(list1).items():
if value['default_backend_set_name'] == query.split(",")[1]:
f_list = key
rulesets = value['rule_set_names']
if type1=="OK_TO_FIRING":
message = "FIRE"
if maintenance in rulesets:
message = "Already in Maintenance Mode"
logging.getLogger().info("Already in Manintenance mode")
else:
rulesets.insert(0, maintenance)
message = "Entering Maintenance Mode"
logging.getLogger().info("Entering Main mode")
load_balancer_client_composite_ops.update_listener_and_wait_for_state(
oci.load_balancer.models.UpdateListenerDetails(
default_backend_set_name=value["default_backend_set_name"],
rule_set_names=rulesets,
port=value["port"],
protocol=value["protocol"],
ssl_configuration=value["ssl_configuration"]
),
load_balancer_ocid,
key,
wait_for_states=[oci.load_balancer.models.WorkRequest.LIFECYCLE_STATE_SUCCEEDED]
)
elif type1=="FIRING_TO_OK":
message = "OK"
if maintenance in rulesets:
message = "Entering Operation Mode"
logging.getLogger().info("Entering Operation Mode")
rulesets.remove(maintenance)
load_balancer_client_composite_ops.update_listener_and_wait_for_state(
oci.load_balancer.models.UpdateListenerDetails(
default_backend_set_name=value["default_backend_set_name"],
rule_set_names=rulesets,
port=value["port"],
protocol=value["protocol"],
ssl_configuration=value["ssl_configuration"]
),
load_balancer_ocid,
key,
wait_for_states=[oci.load_balancer.models.WorkRequest.LIFECYCLE_STATE_SUCCEEDED]
)
else:
message = "Already in operation Mode"
logging.getLogger().info("Already in Operation mode")
except (Exception) as ex:
message = "Error:" + str(ex)
return message
OCI API 게이트웨이 구성
이 솔루션에서 OCI API 게이트웨이는 정적 웹 페이지를 직접 제공하도록 구성됩니다.
주:
OCI API Gateway 사용은 선택 사항입니다. OCI 외부에서 유지보수/오류 페이지를 호스팅할 수도 있습니다.요청 경로가 함수 또는 컴퓨트 인스턴스와 같은 동적 백엔드로 지정되는 OCI API Gateway의 일반적인 사용과 달리, 이 접근 방식은 OCI API Gateway의 정적 응답 호스팅 기능을 활용합니다. 이 정적 페이지는 유지보수 일정이 잡힌 유지보수 또는 기타 문제로 인해 서비스를 일시적으로 사용할 수 없음을 사용자에게 알리는 친숙한 유지보수 메시지의 역할을 합니다. 정적 페이지는 OCI API Gateway를 통해 완전히 관리되므로 웹 서버 또는 객체 스토리지와 같은 추가 인프라가 필요하지 않습니다.
시스템에서 모든 백엔드 서버가 비정상임을 감지하면 로드 밸런서를 구성하여 OCI API Gateway 인스턴스를 프론트엔드하는 보조 리스너로 트래픽을 리디렉션하여 기본 오류 페이지를 표시하지 않고도 원활하고 사용자 친화적인 환경을 보장함으로써 알람으로 트리거되는 함수가 응답합니다.
이 예에서는 OCI API Gateway를 사용하여 정적 응답을 구성하는 데 필요한 단계에만 초점을 맞춥니다. 자세한 내용은 자세히 탐색의 리소스를 검토하십시오.