Bạn đang xem tài liệu về Apigee Edge.
Hãy xem tài liệu về Apigee X.
Apigee Edge tăng cường khả năng sử dụng API bằng cách cung cấp khả năng hỗ trợ tích hợp để cân bằng tải và chuyển đổi dự phòng qua nhiều thực thể máy chủ phụ trợ.
Cấu hình TargetServer phân tách các URL điểm cuối cụ thể khỏi cấu hình TargetEndpoint. Mỗi TargetServer được tham chiếu theo tên trong HTTPEndpoint HTTPConnection. Thay vì xác định một URL cụ thể trong cấu hình, bạn có thể định cấu hình một hoặc nhiều Máy chủ đích có tên như được mô tả trong phần TargetEndpoint.
Định nghĩa TargetServer bao gồm tên, máy chủ và cổng cùng với một phần tử bổ sung để cho biết liệu TargetServer được bật hay tắt.
Video
Xem các video sau để tìm hiểu thêm về cách định tuyến API và cân bằng tải bằng máy chủ mục tiêu
Video | Mô tả |
---|---|
Cân bằng tải bằng máy chủ đích | Tải API cân bằng tải trên các máy chủ mục tiêu. |
Định tuyến API dựa trên môi trường sử dụng máy chủ đích | Định tuyến API đến một máy chủ đích khác dựa trên môi trường. |
Định tuyến API và cân bằng tải bằng máy chủ đích (Classic Edge) | Định tuyến API đến một máy chủ đích khác dựa trên môi trường và cân bằng tải API của bạn trên các máy chủ mục tiêu trong giao diện người dùng Classic Edge. |
Cấu hình máy chủ đích mẫu
Mã sau đây xác định máy chủ đích:
<TargetServer name="target1"> <Host>1.mybackendservice.com</Host> <Port>80</Port> <IsEnabled>true</IsEnabled> </TargetServer >
Phần tử cấu hình máy chủ đích
Bảng sau đây mô tả các phần tử dùng để tạo và định cấu hình TargetServer:
Tên | Mô tả | Mặc định | Bắt buộc? |
---|---|---|---|
name |
Tên của cấu hình TargetServer phải là duy nhất trong môi trường. Tên TargetServer chỉ có thể chứa các ký tự chữ và số. | Không áp dụng | Có |
Host |
URL máy chủ của dịch vụ phụ trợ (không có giao thức). | Không áp dụng | Có |
Port |
Cổng mà dịch vụ phụ trợ đang lắng nghe | Không áp dụng | Có |
IsEnabled |
Giá trị boolean cho biết cấu hình TargetServer được bật hay tắt. Điều này cho phép bạn loại bỏ TargetServers mà không cần sửa đổi cấu hình proxy API. Trường hợp sử dụng phổ biến là viết một ứng dụng hoặc tập lệnh để tự động bật hoặc tắt TargetServers dựa trên các yêu cầu về dung lượng dự kiến, lịch bảo trì, v.v. | true |
Có |
Quản lý máy chủ mục tiêu bằng cách sử dụng giao diện người dùng
Quản lý máy chủ đích, như được mô tả bên dưới.
Edge
Cách quản lý máy chủ đích bằng cách sử dụng giao diện người dùng Edge:
- Đăng nhập vào apigee.com/edge.
- Chọn Quản trị > Môi trường > Máy chủ mục tiêu trong thanh điều hướng bên trái.
- Chọn môi trường mong muốn, chẳng hạn như kiểm thử hoặc sản phẩm.
- Cách tạo máy chủ đích:
- Nhấp vào + Máy chủ mục tiêu.
- Nhập tên, máy chủ lưu trữ và cổng cho máy chủ đích.
Ví dụ:
- Tên: target1
- Máy chủ lưu trữ: 1.mybackendservice.com
- Cổng: 80
- Chọn SSL, nếu được yêu cầu.
- Chọn Bật để bật máy chủ đích.
- Nhấp vào Thêm.
- Cách chỉnh sửa máy chủ đích:
- Đặt con trỏ trên máy chủ đích mà bạn muốn chỉnh sửa để hiển thị trình đơn thao tác.
- Nhấp vào
.
- Chỉnh sửa giá trị máy chủ targer.
- Nhấp vào Cập nhật.
- Cách xoá máy chủ đích:
- Đặt con trỏ của bạn lên máy chủ mục tiêu mà bạn muốn xóa để hiển thị trình đơn tác vụ.
- Nhấp vào
.
- Nhấp vào Delete (Xóa) để xác nhận toán tử.
Classic Edge (Đám mây riêng)
Để truy cập trình hướng dẫn Tạo proxy bằng giao diện người dùng Classic Edge:
- Đăng nhập vào
http://ms-ip:9000
, trong đó ms-ip là địa chỉ IP hoặc tên DNS của nút Server Server. - Chọn API > Cấu hình môi trường > Máy chủ mục tiêu trong thanh điều hướng bên trái.
- Chọn môi trường mong muốn, chẳng hạn như kiểm thử hoặc sản phẩm.
- Cách tạo máy chủ đích:
- Nhấp vào Chỉnh sửa.
- Nhấp vào + Máy chủ mục tiêu.
- Nhập tên, máy chủ lưu trữ và cổng cho máy chủ đích.
Ví dụ:
- Tên: target1
- Máy chủ lưu trữ: 1.mybackendservice.com
- Cổng: 80
- Chọn Bật để bật máy chủ đích.
- Nhấp vào Lưu.
- Cách chỉnh sửa máy chủ đích:
- Nhấp vào Chỉnh sửa.
- Chỉnh sửa giá trị máy chủ targer.
- Nhấp vào Lưu.
- Cách xoá máy chủ đích:
- Nhấp vào Chỉnh sửa.
- Nhấp vào Xoá.
Quản lý máy chủ đích bằng API
Bạn có thể sử dụng Edge API để tạo, xóa, cập nhật, nhận và liệt kê các máy chủ mục tiêu. Để biết thêm thông tin, hãy xem phần TargetServers.
Sử dụng lệnh gọi API sau đây để tạo một máy chủ mục tiêu:
$ curl -H "Content-Type:text/xml" -X POST -d \ '<TargetServer name="target1"> <Host>1.mybackendservice.com</Host> <Port>80</Port> <IsEnabled>true</IsEnabled> </TargetServer>' \ -u email:password https://api.enterprise.apigee.com/v1/o/{org_name}/environments/test/targetservers
Phản hồi mẫu:
{ "host" : "1.mybackendservice.com", "isEnabled" : true, "name" : "target1", "port" : 80 }
Sau khi bạn tạo TargetServer đầu tiên, hãy sử dụng lệnh gọi API sau đây để tạo một TargetServer thứ hai. Bằng cách xác định hai Máy chủ đích, bạn cung cấp hai URL mà TargetEndpoint có thể sử dụng để cân bằng tải:
$ curl -H "Content-type:text/xml" -X POST -d \ '<TargetServer name="target2"> <Host>2.mybackendservice.com</Host> <Port>80</Port> <IsEnabled>true</IsEnabled> </TargetServer >' \ -u email:password https://api.enterprise.apigee.com/v1/o/{org_name}/environments/test/targetservers
Phản hồi mẫu:
{ "host" : "2.mybackendservice.com", "isEnabled" : true, "name" : "target2", "port" : 80 }
Sử dụng lệnh gọi API sau đây để truy xuất danh sách Máy chủ đích trong môi trường:
$ curl -u email:password https://api.enterprise.apigee.com/v1/o/{org_name}/environments/test/targetservers
Câu trả lời mẫu:
[ "target2", "target1" ]
Hiện tại, bạn có thể sử dụng hai Máy chủ đích để sử dụng proxy API được triển khai trong môi trường thử nghiệm. Để tải lưu lượng truy cập cân bằng trên các Máy chủ đích này, bạn hãy định cấu hình kết nối HTTP trong điểm cuối mục tiêu của proxy API để sử dụng Máy chủ mục tiêu.
Mỗi môi trường có giới hạn là 500 máy chủ mục tiêu, như nêu trong chủ đề Giới hạn.
Định cấu hình TargetEndpoint để tải số dư trên các Máy chủ đích được đặt tên
Bây giờ, khi đã có hai Máy chủ mục tiêu, bạn có thể sửa đổi chế độ cài đặt kết nối HTTP TargetEndpoint để tham chiếu đến hai Máy chủ đích đó theo tên:
<TargetEndpoint name="default"> <HTTPTargetConnection> <LoadBalancer> <Server name="target1" /> <Server name="target2" /> </LoadBalancer> <Path>/test</Path> </HTTPTargetConnection> </TargetEndpoint>
Cấu hình ở trên là cấu hình cân bằng tải cơ bản nhất có thể. Trình cân bằng tải hỗ trợ ba thuật toán cân bằng tải là Round Robin, Weight và Least Connection. Round Robin là thuật toán mặc định. Vì không có thuật toán nào được chỉ định trong cấu hình ở trên, nên các yêu cầu đi từ proxy API đến các máy chủ phụ trợ sẽ lần lượt thay thế, giữa các mục tiêu 1 và 2.
Phần tử <Path>
tạo thành đường dẫn cơ sở của URI TargetEndpoint cho tất cả máy chủ đích. Giá trị này chỉ được dùng khi sử dụng <LoadBalancer>
. Nếu không, hàm này sẽ bị bỏ qua. Trong ví dụ trên, yêu cầu đạt đến "target1" sẽ là
http://target1/test
và tương tự như vậy đối với các máy chủ mục tiêu khác.
Đặt tùy chọn trình cân bằng tải
Bạn có thể điều chỉnh tình trạng sẵn có bằng cách sử dụng các tuỳ chọn cân bằng tải và chuyển đổi dự phòng ở cấp độ trình cân bằng tải và cấp TargetServer. Phần này mô tả các tùy chọn này.
Thuật toán
Đặt thuật toán mà <LoadBalancer>
sử dụng. Các thuật toán
hiện có là RoundRobin
, Weighted
và LeastConnections
được liệt kê dưới đây.
Thi đấu vòng tròn
Thuật toán mặc định, vòng tròn, chuyển tiếp một yêu cầu đến từng TargetServer theo thứ tự liệt kê các máy chủ trong kết nối HTTP của điểm cuối mục tiêu. Ví dụ:
<TargetEndpoint name="default"> <HTTPTargetConnection> <LoadBalancer> <Algorithm>RoundRobin</Algorithm> <Server name="target1" /> <Server name="target2" /> </LoadBalancer> <Path>/test</Path> </HTTPTargetConnection> </TargetEndpoint>
Trọng số
Thuật toán cân bằng tải có trọng số cho phép bạn định cấu hình tải lưu lượng truy cập tương ứng cho các Máy chủ mục tiêu của bạn. Loadbalancer có trọng số phân phối yêu cầu đến TargetServers theo tỷ lệ trực tiếp với trọng số của mỗi TargetServer. Do đó, thuật toán trọng số yêu cầu bạn phải đặt một thuộc tính weight
cho mỗi TargetServer. Ví dụ:
<TargetEndpoint name="default"> <HTTPTargetConnection> <LoadBalancer> <Algorithm>Weighted</Algorithm> <Server name="target1"> <Weight>1</Weight> </Server> <Server name="target2"> <Weight>2</Weight> </Server> </LoadBalancer> <Path>/test</Path> </HTTPTargetConnection> </TargetEndpoint>
Trong ví dụ này, hai yêu cầu sẽ được chuyển đến target2 cho mỗi yêu cầu được chuyển đến target1.
Ít kết nối nhất
Loadbalancers được định cấu hình để sử dụng thuật toán kết nối ít nhất định tuyến các yêu cầu gửi đi tới TargetServer có ít kết nối HTTP mở nhất. Ví dụ:
<TargetEndpoint name="default"> <HTTPTargetConnection> <LoadBalancer> <Algorithm>LeastConnections</Algorithm> <Server name="target1" /> <Server name="target2" /> </LoadBalancer> </HTTPTargetConnection> <Path>/test</Path> </TargetEndpoint>
Số lỗi tối đa
Số lượng tối đa các yêu cầu không thành công từ proxy API đến TargetServer dẫn đến yêu cầu được chuyển hướng đến một máy chủ đích khác.
Lỗi phản hồi có nghĩa là Apigee không nhận được bất kỳ phản hồi nào từ máy chủ đích. Khi điều này xảy ra, bộ đếm lỗi sẽ tăng thêm một.
Tuy nhiên, khi Apigee nhận được phản hồi từ một mục tiêu, ngay cả khi phản hồi đó là lỗi HTTP (chẳng hạn như 500
), phản hồi đó sẽ được tính là một phản hồi từ máy chủ mục tiêu và bộ đếm lỗi được đặt lại. Để đảm bảo rằng các phản hồi HTTP không hợp lệ (chẳng hạn như 500
) cũng làm tăng bộ đếm lỗi để đưa máy chủ hoạt động không ổn định ra khỏi tính năng cân bằng tải ngay khi có thể, bạn có thể thêm phần tử <ServerUnhealthyResponse>
có các phần tử con <ResponseCode>
vào cấu hình trình cân bằng tải. Edge cũng sẽ đếm phản hồi có các mã đó là không thành công.
Trong ví dụ sau, target1
sẽ bị xoá khỏi xoay vòng sau năm
yêu cầu không thành công, bao gồm một số phản hồi 5XX
từ máy chủ đích.
<TargetEndpoint name="default"> <HTTPTargetConnection> <LoadBalancer> <Algorithm>RoundRobin</Algorithm> <Server name="target1" /> <Server name="target2" /> <MaxFailures>5</MaxFailures> <ServerUnhealthyResponse> <ResponseCode>500</ResponseCode> <ResponseCode>502</ResponseCode> <ResponseCode>503</ResponseCode> </ServerUnhealthyResponse> </LoadBalancer> <Path>/test</Path> </HTTPTargetConnection> </TargetEndpoint>
Giá trị mặc định của MaxFailures là 0. Điều này có nghĩa là Edge luôn cố gắng kết nối với mục tiêu cho từng yêu cầu và không bao giờ xoá máy chủ đích khỏi chế độ xoay.
Tốt nhất là bạn nên sử dụng MaxFailures > 0 với HealthMonitor. Nếu bạn định cấu hình MaxFailures > 0, TargetServer sẽ bị xoá khỏi chế độ xoay khi mục tiêu không đạt được số lần bạn chỉ định. Khi đã có HealthMonitor, Apigee sẽ tự động đặt TargetServer quay lại sau khi mục tiêu được thiết lập và chạy lại, theo cấu hình của HealthMonitor đó. Hãy xem phần Theo dõi sức khỏe để biết thêm thông tin.
Ngoài ra, nếu bạn định cấu hình MaxFailures > 0 và không định cấu hình HealthMonitor, thì Apigee sẽ không tự động bao gồm lại TargetServer vào chế độ xoay vòng sau khi Apigee phát hiện lỗi. Trong trường hợp này, bạn phải triển khai lại proxy API trước khi Apigee đặt TargetServer quay lại. Xem phần Triển khai proxy API.
Thử lại
Nếu bạn bật lại tính năng thử lại, một yêu cầu sẽ được thử lại mỗi khi xảy ra lỗi phản hồi (lỗi I/O hoặc thời gian chờ HTTP) hoặc phản hồi nhận được khớp với giá trị do <ServerUnhealthyResponse>
đặt.
Hãy xem phần Số lỗi tối đa ở trên để biết thêm thông tin về cách đặt
<ServerUnhealthyResponse>
.
Theo mặc định, <RetryEnabled>
được đặt thành true
. Hãy đặt thành false
để tắt tính năng thử lại.
Ví dụ:
<RetryEnabled>false</RetryEnabled>
Dự phòng
Một (và chỉ một) TargetServer có thể được đặt làm máy chủ 'dự phòng'. TargetServer dự phòng không được đưa vào quy trình cân bằng tải cho đến khi trình cân bằng tải xác định rằng tất cả các Server khác đều không dùng được. Khi trình cân bằng tải xác định rằng không có máy chủ đích, thì tất cả lưu lượng truy cập đều được định tuyến đến máy chủ dự phòng. Ví dụ:
<TargetEndpoint name="default"> <HTTPTargetConnection> <LoadBalancer> <Algorithm>RoundRobin</Algorithm> <Server name="target1" /> <Server name="target2" /> <Server name="target3"> <IsFallback>true</IsFallback> </Server> </LoadBalancer> <Path>/test</Path> </HTTPTargetConnection> </TargetEndpoint>
Cấu hình ở trên dẫn đến việc cân bằng tải vòng tròn giữa mục tiêu 1 và 2 cho đến khi cả hai mục tiêu 1 và 2 không có sẵn. Khi mục tiêu 1 và 2 không có sẵn, tất cả lưu lượng truy cập đều được định tuyến đến mục tiêu 3.
Đường dẫn
Đường dẫn xác định một phân đoạn URI sẽ được thêm vào tất cả yêu cầu do TargetServer đưa ra cho máy chủ phụ trợ.
Phần tử này chấp nhận một đường dẫn chuỗi bằng chữ hoặc mẫu thông báo. Mẫu thông báo cho phép bạn thay thế chuỗi biến trong thời gian chạy.
Ví dụ: trong định nghĩa điểm cuối mục tiêu sau, giá trị của {mypath}
được dùng cho đường dẫn:
<HTTPTargetConnection> <SSLInfo> <Enabled>true</Enabled> </SSLInfo> <LoadBalancer> <Server name="testserver"/> </LoadBalancer> <Path>{mypath}</Path> </HTTPTargetConnection>
Định cấu hình máy chủ đích cho TLS/SSL
Nếu bạn đang sử dụng TargetServer để xác định dịch vụ phụ trợ và dịch vụ phụ trợ cần có kết nối để sử dụng giao thức HTTPS, thì bạn phải bật TLS/SSL trong định nghĩa TargetServer. Điều này là cần thiết vì thẻ <Host>
không cho phép bạn chỉ định giao thức kết nối. Bên dưới là định nghĩa TargetServer cho TLS/SSL một chiều trong đó Edge thực hiện các yêu cầu HTTPS đối với dịch vụ phụ trợ:
<TargetServer name="target1"> <Host>mocktarget.apigee.net</Host> <Port>443</Port> <IsEnabled>true</IsEnabled> <SSLInfo> <Enabled>true</Enabled> </SSLInfo> </TargetServer>
Nếu dịch vụ phụ trợ yêu cầu TLS/SSL hai chiều hoặc tương hỗ, thì bạn phải định cấu hình Máy chủ đích bằng cách sử dụng cùng chế độ cài đặt cấu hình TLS/SSL như TargetEndpoints:
<TargetServer name="TargetServer 1"> <IsEnabled>true</IsEnabled> <Host>www.example.com</Host> <Port>443</Port> <SSLInfo> <Ciphers/> <ClientAuthEnabled>true</ClientAuthEnabled> <Enabled>true</Enabled> <IgnoreValidationErrors>false</IgnoreValidationErrors> <KeyAlias>keystore-alias</KeyAlias> <KeyStore>keystore-name</KeyStore> <Protocols/> <TrustStore>truststore-name</TrustStore> </SSLInfo> </TargetServer >
Để biết thông tin về các thuộc tính <SSLInfo>
, chẳng hạn như <Ciphers>
và <ClientAuthEnabled>
, hãy xem thông tin về cách đặt các thuộc tính đó cho Máy chủ ảo trong phần Định cấu hình quyền truy cập của TLS vào API cho Đám mây riêng.
Để biết hướng dẫn đầy đủ về cách định cấu hình TLS/SSL đi, hãy xem Định cấu hình TLS từ Edge cho phần phụ trợ (Cloud và Private Cloud).
Giản đồ TargetServer
Xem giản đồ cho TargetServer và các thực thể khác trên GitHub.
Theo dõi sức khỏe
Tính năng theo dõi tình trạng cho phép bạn cải thiện cấu hình cân bằng tải bằng cách chủ động thăm dò các URL dịch vụ phụ trợ được xác định trong cấu hình TargetServer. Khi bạn bật tính năng giám sát tình trạng hoạt động, một TargetServer bị lỗi sẽ tự động được khôi phục khi HealthMonitor xác định rằng TargetServer đang hoạt động.
Tính năng giám sát sức khỏe hoạt động với <MaxFailures>
. Nếu bạn không bật tính năng giám sát tình trạng, <MaxFailures>
sẽ chỉ định số lượng yêu cầu không thành công từ proxy API tới TargetServer dẫn đến yêu cầu được chuyển hướng đến một Máy chủ mục tiêu khác.
Sau đó, TargetServer bị lỗi sẽ được đưa ra khỏi quá trình xoay cho đến khi bạn triển khai lại proxy.
Khi bật tính năng giám sát tình trạng, TargetServer bị lỗi sẽ tự động được khôi phục và không cần triển khai lại proxy.
HealthMonitor hoạt động như một ứng dụng khách đơn giản gọi một dịch vụ phụ trợ qua TCP hoặc HTTP:
- Ứng dụng khách TCP chỉ đảm bảo rằng có thể mở ổ cắm.
- Bạn định cấu hình ứng dụng HTTP để gửi yêu cầu HTTP hợp lệ đến dịch vụ phụ trợ. Bạn có thể xác định các thao tác HTTP GET, PUT, POST hoặc DELETE. Phản hồi của lệnh gọi màn hình HTTP phải khớp với chế độ cài đặt đã định cấu hình trong khối
<SuccessResponse>
.
Thành công và thất bại
Khi bạn bật tính năng theo dõi tình trạng sức khỏe, Edge sẽ bắt đầu gửi tính năng kiểm tra tình trạng đến máy chủ đích của bạn. Kiểm tra tình trạng là một yêu cầu được gửi đến máy chủ đích để xác định xem máy chủ đích có hoạt động hay không.
Kiểm tra tình trạng có thể có một trong hai kết quả sau:
- Success (Thành công): Máy chủ đích được coi là hoạt động tốt khi kiểm tra tình trạng thành công. Nguyên nhân thường là do một hoặc nhiều nguyên nhân sau đây:
- Máy chủ đích chấp nhận kết nối mới với cổng được chỉ định, phản hồi yêu cầu trên cổng đó rồi đóng cổng trong khung thời gian đã chỉ định. Phản hồi từ máy chủ đích có thông báo “Connection: close” (Kết nối: đóng)
- Máy chủ đích phản hồi yêu cầu kiểm tra tình trạng bằng mã trạng thái HTTP 200 (OK) hoặc mã trạng thái HTTP khác mà bạn xác định là có thể chấp nhận được.
- Máy chủ đích phản hồi một yêu cầu kiểm tra tình trạng có phần nội dung thư khớp với nội dung thư mong đợi.
Khi xác định rằng một máy chủ hoạt động tốt, Edge sẽ tiếp tục hoặc tiếp tục gửi yêu cầu đến máy chủ đó.
- Không đạt: Máy chủ mục tiêu có thể không vượt qua được quy trình kiểm tra tình trạng theo nhiều cách, tuỳ thuộc vào loại kiểm tra. Hệ thống có thể ghi lại lỗi khi máy chủ đích:
- Từ chối kết nối từ Edge tới cổng kiểm tra tình trạng.
- Không trả lời yêu cầu kiểm tra tình trạng trong một khoảng thời gian nhất định.
- Trả về mã trạng thái HTTP không mong muốn.
- Trả lời bằng nội dung tin nhắn không khớp với nội dung tin nhắn mong muốn.
Khi máy chủ đích không kiểm tra được tình trạng, Edge sẽ gia tăng số lỗi của máy chủ đó. Nếu số lượng lỗi của máy chủ đó đạt hoặc vượt quá ngưỡng xác định trước (
<MaxFailures>
), thì Edge sẽ ngừng gửi yêu cầu đến máy chủ đó.
Bật HealthMonitor
Để tạo HealthMonitor, bạn thêm phần tử <HealthMonitor>
vào cấu hình HTTPConnection của TargetEndpoint. Bạn không thể thực hiện việc này trong giao diện người dùng. Thay vào đó, bạn sẽ tạo một cấu hình proxy và
tải tệp này lên Edge làm tệp ZIP. Cấu hình proxy là nội dung mô tả có cấu trúc về tất cả các khía cạnh của proxy API. Cấu hình proxy bao gồm các tệp XML trong cấu trúc thư mục được xác định trước. Để biết thêm thông tin, hãy xem phần Tài liệu tham khảo về cấu hình proxy API.
HealthMonitor đơn giản xác định IntervalInSec
kết hợp với TCPMonitor hoặc HTTPMonitor. Phần tử <MaxFailures>
chỉ định số lượng tối đa
các yêu cầu không thành công từ proxy API đến TargetServer dẫn đến yêu cầu
được chuyển hướng đến một máy chủ đích khác. Theo mặc định, <MaxFailures>
là 0, có nghĩa là
Edge sẽ không thực hiện hành động khắc phục nào. Khi định cấu hình trình theo dõi tình trạng, hãy đảm bảo rằng bạn thiết lập <MaxFailures>
trong thẻ <HTTPTargetConnection>
của thẻ <TargetEndpoint>
thành giá trị khác 0.
TCPMonitor
Cấu hình bên dưới xác định HealthMonitor sẽ thăm dò ý kiến mỗi TargetServer bằng cách mở kết nối trên cổng 80 mỗi năm giây. (Cổng là tùy chọn. Nếu không được chỉ định, cổng TCPMonitor là cổng TargetServer.)
- Nếu kết nối không thành công hoặc mất hơn 10 giây để kết nối, thì số lỗi sẽ tăng 1 cho TargetServer.
- Nếu kết nối thành công thì số lần lỗi cho TargetServer được đặt lại về 0.
Bạn có thể thêm HealthMonitor dưới dạng phần tử con của phần tử HTTPTargetConnetion của TargetEndpoint, như được hiển thị bên dưới:
<TargetEndpoint name="default"> <HTTPTargetConnection> <LoadBalancer> <Algorithm>RoundRobin</Algorithm> <Server name="target1" /> <Server name="target2" /> <MaxFailures>5</MaxFailures> </LoadBalancer> <Path>/test</Path> <HealthMonitor> <IsEnabled>true</IsEnabled> <IntervalInSec>5</IntervalInSec> <TCPMonitor> <ConnectTimeoutInSec>10</ConnectTimeoutInSec> <Port>80</Port> </TCPMonitor> </HealthMonitor> </HTTPTargetConnection> . . .
HealthMonitor với các phần tử cấu hình TCPMonitor
Bảng sau đây mô tả các phần tử cấu hình TCPMonitor:
Tên | Mô tả | Mặc định | Bắt buộc? |
---|---|---|---|
IsEnabled |
Giá trị boolean bật hoặc tắt HealthMonitor. | sai | Không |
IntervalInSec |
Khoảng thời gian, tính bằng giây, giữa mỗi yêu cầu TCP thăm dò ý kiến. | 0 | Có |
ConnectTimeoutInSec |
Thời gian cần thiết lập kết nối với cổng TCP để được coi là thành công. Không kết nối được trong khoảng thời gian được chỉ định là lỗi, làm tăng số lượng sự cố của trình cân bằng tải cho TargetServer. | 0 | Có |
Port |
Không bắt buộc. Cổng nơi kết nối TCP sẽ được thiết lập. Nếu không được chỉ định, cổng TCPMonitor sẽ là cổng TargetServer. | 0 | Không |
Giám sát HTTP
Một HealthMonitor mẫu sử dụng HTTPMonitor sẽ gửi yêu cầu GET tới dịch vụ phụ trợ 5 giây một lần. Mẫu dưới đây sẽ thêm tiêu đề Uỷ quyền cơ bản HTTP vào thông báo yêu cầu. Cấu hình phản hồi xác định các chế độ cài đặt sẽ được so sánh với phản hồi thực tế từ dịch vụ phụ trợ. Trong ví dụ bên dưới, phản hồi dự kiến là một mã phản hồi HTTP 200
và một tiêu đề HTTP tùy chỉnh ImOK
có giá trị là YourOK
. Nếu phản hồi không khớp, thì cấu hình trình cân bằng tải sẽ coi yêu cầu là lỗi.
HTTPMonitor hỗ trợ các dịch vụ phụ trợ được định cấu hình để sử dụng giao thức HTTP và HTTPS một chiều. Tuy nhiên, tính năng này không hỗ trợ:
- HTTPS hai chiều (còn được gọi là TLS/SSL hai chiều)
- Chứng chỉ tự ký.
Lưu ý rằng mọi chế độ cài đặt Request and Response (Yêu cầu và phản hồi) trong màn hình HTTP sẽ dành riêng cho dịch vụ phụ trợ mà sẽ được gọi.
<HealthMonitor> <IsEnabled>true</IsEnabled> <IntervalInSec>5</IntervalInSec> <HTTPMonitor> <Request> <ConnectTimeoutInSec>10</ConnectTimeoutInSec> <SocketReadTimeoutInSec>30</SocketReadTimeoutInSec> <Port>80</Port> <Verb>GET</Verb> <Path>/healthcheck</Path> <Header name="Authorization">Basic 12e98yfw87etf</Header> <IncludeHealthCheckIdHeader>true</IncludeHealthCheckIdHeader> </Request> <SuccessResponse> <ResponseCode>200</ResponseCode> <Header name="ImOK">YourOK</Header> </SuccessResponse> </HTTPMonitor> </HealthMonitor>
HealthMonitor với các phần tử cấu hình HTTPMonitor
Bảng sau đây mô tả các phần tử cấu hình HTTPMonitor:
Tên | Mô tả | Mặc định | Bắt buộc? |
---|---|---|---|
IsEnabled |
Giá trị boolean bật hoặc tắt HealthMonitor. | sai | Không |
IntervalInSec |
Khoảng thời gian, tính bằng giây, giữa mỗi yêu cầu thăm dò ý kiến. | 0 | Có |
Request |
Các tuỳ chọn cấu hình cho thông báo yêu cầu gửi đi do HealthMonitor gửi tới TargetServers trong chế độ xoay. Đường dẫn không hỗ trợ biến. |
Không áp dụng | Có |
ConnectTimeoutInSec |
Thời gian tính bằng giây, trong đó sự kết nối kết nối TCP với dịch vụ HTTP phải hoàn tất để được coi là thành công. Việc không kết nối được trong khoảng thời gian đã chỉ định được tính là lỗi, làm tăng số lượng sự cố của Loadbalancer cho TargetServer. | 0 | Không |
SocketReadTimeoutInSec |
Thời gian, tính bằng giây, trong đó dữ liệu phải được đọc từ dịch vụ HTTP để được coi là thành công. Việc không đọc trong khoảng thời gian được chỉ định được tính là không thành công, làm tăng số lượng lỗi của Loadbalancer cho TargetServer. | 0 | Không |
Port |
Cổng nơi kết nối HTTP với dịch vụ phụ trợ sẽ được thiết lập. | Không áp dụng | Không |
Verb |
Động từ HTTP được sử dụng cho mỗi yêu cầu HTTP thăm dò ý kiến về dịch vụ phụ trợ . | Không áp dụng | Không |
Path |
Đường dẫn được nối vào URL được xác định trong TargetServer. Sử dụng phần tử đường dẫn để định cấu hình một "điểm cuối thăm dò ý kiến" trên dịch vụ HTTP. | Không áp dụng | Không |
| Cho phép bạn theo dõi các yêu cầu kiểm tra tình trạng trên hệ thống tải lên. IncludeHealthCheckIdHeader nhận giá trị Boolean và mặc định là false . Nếu bạn đặt giá trị này là true , thì Header có tên là X-Apigee-Healthcheck-Id sẽ được đưa vào yêu cầu kiểm tra tình trạng. Giá trị của tiêu đề được chỉ định động và có dạng ORG/ENV/SERVER_UUID/N, trong đó ORG là tên tổ chức, ENV là tên môi trường, SERVER_UUID là mã nhận dạng duy nhất xác định MP và N là số mili giây đã trôi qua kể từ ngày 1 tháng 1 năm 1970.
Ví dụ về tiêu đề yêu cầu kết quả: X-Apigee-Healthcheck-Id: orgname/envname/E8C4D2EE-3A69-428A-8616-030ABDE864E0/1586802968123
|
sai | Không |
Payload |
Phần nội dung HTTP được tạo cho mỗi yêu cầu HTTP bỏ phiếu. Xin lưu ý rằng phần tử này không bắt buộc đối với các yêu cầu GET. | Không áp dụng | Không |
SuccessResponse |
Các tuỳ chọn so khớp cho thông báo phản hồi HTTP đến do dịch vụ phụ trợ được thăm dò ý kiến tạo ra. Số phản hồi không khớp sẽ làm tăng số lỗi 1. | Không áp dụng | Không |
ResponseCode |
Mã phản hồi HTTP dự kiến sẽ nhận được từ TargetServer được thăm dò ý kiến. Một mã khác với mã chỉ định sẽ dẫn đến lỗi và số lượng sẽ tăng lên đối với dịch vụ phụ trợ được thăm dò ý kiến. Bạn có thể xác định nhiều phần tử mã phản hồi. | Không áp dụng | Không |
Headers |
Danh sách một hoặc nhiều tiêu đề HTTP và giá trị dự kiến sẽ nhận được từ dịch vụ phụ trợ được thăm dò ý kiến. Mọi tiêu đề HTTP hoặc giá trị trên phản hồi khác với các tiêu đề hoặc giá trị được chỉ định sẽ dẫn đến lỗi và số lượng của TargetServer được thăm dò ý kiến sẽ tăng thêm 1. Bạn có thể xác định nhiều phần tử Tiêu đề. | Không áp dụng | Không |