การจัดสรรภาระงานในเซิร์ฟเวอร์แบ็กเอนด์

คุณกำลังดูเอกสาร Apigee Edge
ไปที่เอกสารประกอบของ Apigee X ข้อมูล

Apigee Edge จะช่วยปรับปรุงความพร้อมใช้งานของ API ด้วยการสนับสนุนในตัวสำหรับการจัดสรรภาระงานและเฟลโอเวอร์ในอินสแตนซ์เซิร์ฟเวอร์แบ็กเอนด์หลายรายการ

การกำหนดค่า TargetServer จะแยก URL ปลายทางที่เป็นรูปธรรมจากการกำหนดค่า TargetEndpoint TargetServer แต่ละรายการจะมีการอ้างอิงตามชื่อใน TargetEndpoint HTTPConnection แทนที่จะกำหนด URL ที่เป็นรูปธรรมในการกำหนดค่า คุณสามารถกำหนดค่า TargetServer อย่างน้อย 1 รายการได้ตามที่อธิบายไว้ในส่วน TargetEndpoint

คำจำกัดความของ TargetServer ประกอบด้วยชื่อ โฮสต์ และพอร์ต พร้อมด้วยองค์ประกอบเพิ่มเติมเพื่อระบุว่า TargetServer เปิดใช้อยู่หรือปิดใช้

วิดีโอ

ดูวิดีโอต่อไปนี้เพื่อดูข้อมูลเพิ่มเติมเกี่ยวกับการกำหนดเส้นทาง API และการจัดสรรภาระงานโดยใช้เซิร์ฟเวอร์เป้าหมาย

วิดีโอ	คำอธิบาย
การจัดสรรภาระงานโดยใช้เซิร์ฟเวอร์เป้าหมาย	API การจัดสรรภาระงานในเซิร์ฟเวอร์เป้าหมาย
การกำหนดเส้นทาง API ตามสภาพแวดล้อมที่ใช้เซิร์ฟเวอร์เป้าหมาย	กำหนดเส้นทาง API ไปยังเซิร์ฟเวอร์เป้าหมายอื่นตามสภาพแวดล้อม
การกำหนดเส้นทาง API และการจัดสรรภาระงานโดยใช้เซิร์ฟเวอร์เป้าหมาย (Classic Edge)	กำหนดเส้นทาง API ไปยังเซิร์ฟเวอร์เป้าหมายอื่นตามสภาพแวดล้อมและจัดสรรภาระงาน API ของคุณในเซิร์ฟเวอร์เป้าหมายใน UI ของ Edge แบบคลาสสิก

ตัวอย่างการกำหนดค่า TargetServer

รหัสต่อไปนี้จะระบุเซิร์ฟเวอร์เป้าหมาย

<TargetServer  name="target1">
  <Host>1.mybackendservice.com</Host>
  <Port>80</Port>
  <IsEnabled>true</IsEnabled>
</TargetServer >

องค์ประกอบการกำหนดค่า TargetServer

ตารางต่อไปนี้อธิบายองค์ประกอบที่ใช้สร้างและกำหนดค่า TargetServer

ชื่อ	คำอธิบาย	ค่าเริ่มต้น	จำเป็นหรือไม่
name	ชื่อของการกำหนดค่า TargetServer ซึ่งต้องไม่ซ้ำกันภายในสภาพแวดล้อม ชื่อ TargetServer มีได้เฉพาะอักขระที่เป็นตัวอักษรและตัวเลขคละกันเท่านั้น	ไม่มีข้อมูล	ใช่
Host	URL โฮสต์ของบริการแบ็กเอนด์ (ไม่มีโปรโตคอล)	ไม่มีข้อมูล	ใช่
Port	พอร์ตที่บริการแบ็กเอนด์กำลังฟังอยู่	ไม่มีข้อมูล	ใช่
IsEnabled	บูลีนที่ระบุว่ามีการเปิดหรือปิดใช้การกำหนดค่า TargetServer การดำเนินการนี้ช่วยให้คุณนำ TargetServers ออกจากการหมุนเวียนได้โดยไม่ต้องแก้ไขการกำหนดค่าพร็อกซี API การใช้งานทั่วไปคือการเขียนแอปหรือสคริปต์เพื่อเปิดใช้หรือปิดใช้ TargetServer โดยอัตโนมัติตามข้อกำหนดด้านความจุที่คาดไว้ กำหนดการบำรุงรักษา ฯลฯ	true	ใช่

การจัดการเซิร์ฟเวอร์เป้าหมายโดยใช้ UI

จัดการเซิร์ฟเวอร์เป้าหมายตามที่อธิบายไว้ด้านล่าง

การจัดการเซิร์ฟเวอร์เป้าหมายโดยใช้ API

คุณสามารถใช้ Edge API เพื่อสร้าง ลบ อัปเดต รับ และแสดงรายการเซิร์ฟเวอร์เป้าหมายได้ ดูข้อมูลเพิ่มเติมได้ที่ TargetServers

ใช้การเรียก API ต่อไปนี้เพื่อสร้างเซิร์ฟเวอร์เป้าหมาย

$ 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

ตัวอย่างคำตอบ

{
  "host" : "1.mybackendservice.com",
  "isEnabled" : true,
  "name" : "target1",
  "port" : 80
}

หลังจากที่คุณสร้าง TargetServer แรกแล้ว ให้ใช้การเรียก API ต่อไปนี้เพื่อสร้าง TargetServer ที่สอง เมื่อกำหนด TargetServer 2 รายการ คุณจะระบุ URL 2 รายการที่ TargetEndpoint สามารถใช้ในการจัดสรรภาระงานได้

$ 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

ตัวอย่างคำตอบ

{
  "host" : "2.mybackendservice.com",
  "isEnabled" : true,
  "name" : "target2",
  "port" : 80
}

ใช้การเรียก API ต่อไปนี้เพื่อดึงรายการ TargetServer ในสภาพแวดล้อม:

$ curl -u email:password https://api.enterprise.apigee.com/v1/o/{org_name}/environments/test/targetservers

ตัวอย่างคำตอบ

[ "target2", "target1" ]

ตอนนี้มี TargetServer 2 รายการสำหรับใช้โดยพร็อกซี API ที่ทำให้ใช้งานได้ในสภาพแวดล้อมการทดสอบ หากต้องการโหลดการเข้าชมที่มีสมดุลระหว่าง TargetServer เหล่านี้ คุณจะต้องกำหนดค่าการเชื่อมต่อ HTTP ในปลายทางเป้าหมายของพร็อกซี API ให้ใช้ TargetServers

โดยมีขีดจำกัดอยู่ที่ 500 รายการต่อสภาพแวดล้อม ตามที่ระบุไว้ในหัวข้อขีดจำกัด

การกำหนดค่า TargetEndpoint เพื่อโหลดยอดคงเหลือข้าม TargetServer ที่มีชื่อ

ตอนนี้คุณมี TargetServers จำนวน 2 รายการแล้ว คุณอาจแก้ไขการตั้งค่าการเชื่อมต่อ HTTP TargetEndpoint เพื่ออ้างอิง TargetServer 2 รายการนั้นตามชื่อได้

<TargetEndpoint name="default">
  <HTTPTargetConnection>
    <LoadBalancer>
      <Server name="target1" />
      <Server name="target2" />
    </LoadBalancer>
    <Path>/test</Path>
  </HTTPTargetConnection>
</TargetEndpoint>

การกำหนดค่าข้างต้นเป็นการกำหนดค่าการจัดสรรภาระงานขั้นพื้นฐานที่สุดเท่าที่จะเป็นไปได้ ตัวจัดสรรภาระงานรองรับอัลกอริทึมการจัดสรรภาระงาน 3 รายการ ได้แก่ Round Robin แบบถ่วงน้ำหนัก และการเชื่อมต่อน้อยที่สุด ซึ่งเป็นอัลกอริทึมเริ่มต้น เนื่องจากไม่มีการระบุอัลกอริทึมในการกำหนดค่าข้างต้น คำขอขาออกจากพร็อกซี API ไปยังเซิร์ฟเวอร์แบ็กเอนด์จะสลับกัน 1 ต่อ 1 ระหว่างเป้าหมาย 1 และเป้าหมาย 2

องค์ประกอบ <Path> สร้างเส้นทางฐานของ URI ของ TargetEndpoint สำหรับเซิร์ฟเวอร์เป้าหมายทั้งหมด โดยจะใช้ก็ต่อเมื่อใช้ <LoadBalancer> เท่านั้น มิฉะนั้น ระบบจะไม่สนใจ ในตัวอย่างข้างต้น คำขอที่เข้าถึง "target1" จะเป็น http://target1/test และสำหรับเซิร์ฟเวอร์เป้าหมายอื่นๆ

การตั้งค่าตัวเลือกตัวจัดสรรภาระงาน

คุณปรับแต่งความพร้อมใช้งานได้โดยใช้ตัวเลือกสำหรับการจัดสรรภาระงานและเฟลโอเวอร์ที่ระดับตัวจัดสรรภาระงานและ TargetServer ส่วนนี้จะอธิบายตัวเลือกเหล่านี้

อัลกอริทึม

ตั้งค่าอัลกอริทึมที่ <LoadBalancer> ใช้ อัลกอริทึมที่ใช้ได้คือ RoundRobin, Weighted และ LeastConnections ซึ่งแต่ละรายการอธิบายไว้เป็นเอกสารด้านล่าง

แบบสุ่มลำดับ

อัลกอริทึมเริ่มต้นแบบปัดเศษ จะส่งต่อคำขอไปยังเซิร์ฟเวอร์ TargetServer แต่ละเซิร์ฟเวอร์ตามลำดับที่เซิร์ฟเวอร์อยู่ในรายการการเชื่อมต่อ HTTP ปลายทางเป้าหมาย เช่น

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>RoundRobin</Algorithm>
        <Server name="target1" />
        <Server name="target2" />
      </LoadBalancer>
      <Path>/test</Path>
  </HTTPTargetConnection>
</TargetEndpoint>

ถ่วงน้ำหนัก

อัลกอริทึมการจัดสรรภาระงานแบบถ่วงน้ำหนักช่วยให้คุณกำหนดค่าโหลดการเข้าชมตามสัดส่วนสำหรับ TargetServers ได้ LoadBalancer ที่ถ่วงน้ำหนักจะกระจายคำขอไปยังเซิร์ฟเวอร์ TargetServer ในสัดส่วนโดยตรงกับน้ำหนักของ TargetServer แต่ละรายการ ดังนั้น อัลกอริทึมถ่วงน้ำหนักจึงกำหนดให้คุณต้องตั้งค่าแอตทริบิวต์ weight สำหรับ TargetServer แต่ละรายการ เช่น

<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>

ในตัวอย่างนี้ ระบบจะกำหนดเส้นทางคำขอ 2 รายการไปยัง target2 สำหรับทุกคำขอที่กำหนดเส้นทางไปยัง target1

การเชื่อมต่อน้อยที่สุด

LoadBalancers ที่กำหนดค่าให้ใช้อัลกอริทึมการเชื่อมต่อที่น้อยที่สุดจะกำหนดเส้นทางคำขอขาออกไปยัง TargetServer ที่มีการเชื่อมต่อ HTTP แบบเปิดน้อยที่สุด เช่น

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>LeastConnections</Algorithm>
        <Server name="target1" />
        <Server name="target2" />
      </LoadBalancer>
  </HTTPTargetConnection>
  <Path>/test</Path>
</TargetEndpoint>

จำนวนความล้มเหลวสูงสุด

จำนวนคำขอที่ล้มเหลวสูงสุดจากพร็อกซี API ไปยัง TargetServer ซึ่งส่งผลให้คำขอเปลี่ยนเส้นทางไปยัง TargetServer อื่น

การตอบกลับล้มเหลวหมายความว่า Apigee ไม่ได้รับการตอบกลับจากเซิร์ฟเวอร์เป้าหมาย เมื่อเกิดกรณีนี้ขึ้น ตัวนับความล้มเหลวจะเพิ่มขึ้น 1 รายการ

อย่างไรก็ตาม เมื่อ Apigee ได้รับการตอบกลับจากเป้าหมาย แม้ว่าการตอบกลับจะเป็นข้อผิดพลาด HTTP (เช่น 500) ซึ่งจะนับเป็นการตอบกลับจากเซิร์ฟเวอร์เป้าหมาย และจะรีเซ็ตตัวนับความล้มเหลวก็ตาม เพื่อช่วยให้แน่ใจว่าการตอบสนอง HTTP ที่ไม่ดี (เช่น 500) จะเพิ่มตัวนับความล้มเหลวในการนำเซิร์ฟเวอร์ที่มีประสิทธิภาพไม่ดีออกจากการหมุนเวียนการจัดสรรภาระงานโดยเร็วที่สุด ให้เพิ่มองค์ประกอบ <ServerUnhealthyResponse> ที่มีองค์ประกอบย่อย <ResponseCode> ลงในการกำหนดค่าตัวจัดสรรภาระงาน Edge จะนับการตอบกลับที่มีรหัสเหล่านั้นว่าล้มเหลวด้วย

ในตัวอย่างต่อไปนี้ target1 จะถูกนำออกจากการหมุนเวียนหลังจากคำขอที่ล้มเหลว 5 รายการ รวมถึงการตอบกลับ 5XX บางรายการจากเซิร์ฟเวอร์เป้าหมาย

<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>

ค่าเริ่มต้นของ MaxFailures คือ 0 ซึ่งหมายความว่า Edge จะพยายามเชื่อมต่อกับเป้าหมายของแต่ละคำขอเสมอ และจะไม่นำเซิร์ฟเวอร์เป้าหมายออกจากการหมุนเวียนโดยเด็ดขาด

ควรใช้ MaxFailures > 0 กับ HealthMonitor หากกำหนดค่า MaxFailures > 0 ระบบจะนำ TargetServer ออกจากการหมุนเวียนเมื่อเป้าหมายทำงานไม่สำเร็จตามจำนวนที่คุณระบุ เมื่อมี HealthMonitor แล้ว Apigee จะทำให้ TargetServer กลับมาทำงานอีกครั้งโดยอัตโนมัติหลังจากที่เป้าหมายกลับมาทำงานอีกครั้งตามการกำหนดค่าของ HealthMonitor นั้น ดูข้อมูลเพิ่มเติมได้ที่การตรวจสอบความสมบูรณ์

หรือถ้าคุณกำหนดค่า MaxFailures > 0 และไม่ได้กำหนดค่า HealthMonitor Apigee จะไม่รวม TargetServer ในการหมุนเวียนอีกครั้งโดยอัตโนมัติหลังจากที่ Apigee ตรวจพบการทำงานล้มเหลว ในกรณีนี้ คุณต้องทำให้พร็อกซี API ใช้งานได้อีกครั้งก่อนที่ Apigee จะนำ TargetServer กลับเข้าสู่การหมุนเวียน โปรดดูการทำให้พร็อกซี API ใช้งานได้

ลองอีกครั้ง

หากเปิดใช้การลองอีกครั้ง ระบบจะลองส่งคำขออีกครั้งเมื่อใดก็ตามที่การตอบสนองล้มเหลว (ข้อผิดพลาด I/O หรือหมดเวลาของ HTTP) หรือการตอบกลับที่ได้รับตรงกับค่าที่ <ServerUnhealthyResponse> ตั้งไว้ ดูจำนวนความล้มเหลวสูงสุดด้านบนสำหรับข้อมูลเพิ่มเติมเกี่ยวกับการตั้งค่า <ServerUnhealthyResponse>

ค่าเริ่มต้น <RetryEnabled> คือ true ตั้งค่าเป็น false เพื่อปิดใช้การลองอีกครั้ง เช่น

<RetryEnabled>false</RetryEnabled>

IsFallback

สามารถตั้งค่า TargetServer หนึ่ง (เท่านั้น) เป็นเซิร์ฟเวอร์ "สำรอง" TargetServer สำรองจะไม่รวมอยู่ในกิจวัตรการจัดสรรภาระงานจนกว่าตัวจัดสรรภาระงานจะระบุว่า TargetServer อื่นๆ ทั้งหมดไม่พร้อมใช้งาน เมื่อตัวจัดสรรภาระงานระบุว่า TargetServer ทั้งหมดไม่พร้อมใช้งาน ระบบจะกำหนดเส้นทางการรับส่งข้อมูลทั้งหมดไปยังเซิร์ฟเวอร์สำรอง เช่น

<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>

การกำหนดค่าข้างต้นจะทำให้เกิดการจัดสรรภาระงานแบบพบกันหมดระหว่างเป้าหมาย 1 และ 2 จนกว่าทั้งเป้าหมาย 1 และ 2 จะใช้งานไม่ได้ เมื่อเป้าหมาย 1 และ 2 ไม่พร้อมใช้งาน ระบบจะกำหนดเส้นทางการเข้าชมทั้งหมดไปยังเป้าหมาย 3

เส้นทาง

เส้นทางกำหนดส่วนย่อย URI ที่จะนำไปต่อท้ายคำขอทั้งหมดที่ออกโดย TargetServer ไปยังเซิร์ฟเวอร์แบ็กเอนด์

องค์ประกอบนี้ยอมรับเส้นทางสตริงตามตัวอักษรหรือเทมเพลตข้อความ เทมเพลตข้อความช่วยให้คุณแทนที่สตริงตัวแปรระหว่างรันไทม์ได้ เช่น ในคำจำกัดความของปลายทางเป้าหมายต่อไปนี้ มีการใช้ค่า {mypath} สำหรับเส้นทาง

<HTTPTargetConnection>
    <SSLInfo>
      <Enabled>true</Enabled>
    </SSLInfo>
    <LoadBalancer>
      <Server name="testserver"/>
    </LoadBalancer>
    <Path>{mypath}</Path>
</HTTPTargetConnection>

การกำหนดค่าเซิร์ฟเวอร์เป้าหมายสำหรับ TLS/SSL

หากคุณใช้ TargetServer เพื่อกำหนดบริการแบ็กเอนด์ และบริการแบ็กเอนด์ต้องใช้การเชื่อมต่อเพื่อใช้โปรโตคอล HTTPS คุณต้องเปิดใช้ TLS/SSL ในคำจำกัดความของ TargetServer ซึ่งจำเป็นเนื่องจากแท็ก <Host> ไม่อนุญาตให้คุณระบุโปรโตคอลการเชื่อมต่อ ด้านล่างนี้เป็นคำจำกัดความของ TargetServer สำหรับ TLS/SSL ทางเดียวที่ Edge ส่งคำขอ HTTPS ไปยังบริการแบ็กเอนด์

<TargetServer name="target1">
  <Host>mocktarget.apigee.net</Host>
  <Port>443</Port>
  <IsEnabled>true</IsEnabled>
  <SSLInfo>
      <Enabled>true</Enabled>
  </SSLInfo> 
</TargetServer>

หากบริการแบ็กเอนด์ต้องใช้ TLS/SSL แบบ 2 ทางหรือแบบร่วม คุณจะต้องกำหนดค่า TargetServer โดยใช้การตั้งค่า TLS/SSL เดียวกันกับ 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 >

โปรดดูข้อมูลเกี่ยวกับพร็อพเพอร์ตี้ <SSLInfo> เช่น <Ciphers> และ <ClientAuthEnabled> เพื่อดูข้อมูลเกี่ยวกับการตั้งค่าพร็อพเพอร์ตี้เหล่านั้นสำหรับโฮสต์เสมือนได้ที่การกำหนดค่าการเข้าถึง TLS ไปยัง API สำหรับ Private Cloud

สำหรับคำแนะนำทั้งหมดเกี่ยวกับการกำหนดค่า TLS/SSL ขาออก โปรดดูการกำหนดค่า TLS จาก Edge ไปยังแบ็กเอนด์ (Cloud และ Private Cloud)

สคีมา TargetServer

ดูสคีมาของ TargetServer และเอนทิตีอื่นๆ ใน GitHub

การเฝ้าตรวจสอบด้านสุขภาพ

การตรวจสอบประสิทธิภาพการทำงานช่วยให้คุณเพิ่มประสิทธิภาพการกำหนดค่าการจัดสรรภาระงานได้ด้วยการสำรวจ URL ของบริการแบ็กเอนด์ที่กำหนดไว้ในการกำหนดค่า TargetServer เมื่อเปิดใช้การตรวจสอบประสิทธิภาพการทำงาน ระบบจะเปลี่ยน TargetServer ที่ล้มเหลวกลับเข้าสู่การหมุนเวียนโดยอัตโนมัติเมื่อ HealthMonitor ระบุว่า TargetServer ทำงานอยู่

การตรวจวัดสุขภาพใช้งานได้กับ <MaxFailures> หากไม่ได้เปิดใช้การตรวจสอบประสิทธิภาพการทำงาน <MaxFailures> จะระบุจำนวนคำขอที่ล้มเหลวจากพร็อกซี API ที่ส่งไปยัง TargetServer ซึ่งส่งผลให้คำขอเปลี่ยนเส้นทางไปยัง TargetServer อื่น TargetServer ที่ล้มเหลวจะถูกนำออกจากการหมุนเวียนจนกว่าคุณจะทำให้พร็อกซีใช้งานได้อีกครั้ง

เมื่อเปิดใช้การตรวจสอบประสิทธิภาพการทำงาน ระบบจะเปลี่ยน TargetServer ที่ล้มเหลวกลับเข้าสู่การหมุนเวียนโดยอัตโนมัติ และไม่จำเป็นต้องทำให้พร็อกซีใช้งานได้อีกครั้ง

HealthMonitor ทำหน้าที่เป็นไคลเอ็นต์แบบง่ายที่เรียกใช้บริการแบ็กเอนด์ผ่าน TCP หรือ HTTP ดังนี้

• ไคลเอ็นต์ TCP ช่วยให้แน่ใจว่าซ็อกเก็ตสามารถเปิดได้
• คุณกำหนดค่าไคลเอ็นต์ HTTP ให้ส่งคำขอ HTTP ที่ถูกต้องไปยังบริการแบ็กเอนด์ คุณกำหนดการดำเนินการ HTTP GET, PUT, POST หรือ DELETE ได้ การตอบสนองของการเรียกการตรวจสอบ HTTP ต้องตรงกับการตั้งค่าที่กำหนดค่าไว้ในบล็อก <SuccessResponse>

ความสำเร็จและความล้มเหลว

เมื่อเปิดใช้การตรวจสอบประสิทธิภาพการทำงาน Edge จะเริ่มส่งการตรวจสอบประสิทธิภาพการทำงานไปยังเซิร์ฟเวอร์เป้าหมาย การตรวจสอบประสิทธิภาพการทำงานคือคำขอที่ส่งไปยังเซิร์ฟเวอร์เป้าหมายซึ่งเป็นตัวกำหนดว่าเซิร์ฟเวอร์เป้าหมายมีประสิทธิภาพดีหรือไม่

การตรวจสอบประสิทธิภาพการทำงานอาจมีผลลัพธ์ที่เป็นไปได้ 1 ใน 2 กรณีต่อไปนี้

• สำเร็จ: ถือว่าเซิร์ฟเวอร์เป้าหมายมีประสิทธิภาพดีเมื่อตรวจสอบประสิทธิภาพการทำงานสำเร็จ ซึ่งโดยทั่วไปจะเป็นผลมาจากสิ่งต่อไปนี้อย่างน้อย 1 อย่าง
  • เซิร์ฟเวอร์เป้าหมายยอมรับการเชื่อมต่อใหม่ไปยังพอร์ตที่ระบุ ตอบกลับคำขอบนพอร์ตนั้น จากนั้นปิดพอร์ตภายในกรอบเวลาที่ระบุ การตอบสนองจากเซิร์ฟเวอร์เป้าหมายประกอบด้วย "การเชื่อมต่อ: ปิด"
  • เซิร์ฟเวอร์เป้าหมายตอบกลับคำขอตรวจสอบประสิทธิภาพการทำงานด้วย 200 (OK) หรือรหัสสถานะ HTTP อื่นๆ ที่คุณระบุว่ายอมรับได้
  • เซิร์ฟเวอร์เป้าหมายตอบกลับคำขอตรวจสอบประสิทธิภาพการทำงานด้วยเนื้อหาข้อความที่ตรงกับเนื้อหาข้อความที่คาดไว้

  เมื่อ Edge พิจารณาว่าเซิร์ฟเวอร์มีประสิทธิภาพ Edge จะดำเนินการต่อหรือส่งคำขอไปยังเซิร์ฟเวอร์ต่อ

• ล้มเหลว: เซิร์ฟเวอร์เป้าหมายอาจไม่ผ่านการตรวจสอบประสิทธิภาพการทำงานได้หลายวิธี ทั้งนี้ขึ้นอยู่กับประเภทการตรวจสอบ ระบบอาจบันทึกความล้มเหลวเมื่อเซิร์ฟเวอร์เป้าหมายดำเนินการต่อไปนี้
  • ปฏิเสธการเชื่อมต่อจาก Edge ไปยังพอร์ตการตรวจสอบประสิทธิภาพการทำงาน
  • ไม่ตอบกลับคำขอตรวจสอบประสิทธิภาพการทำงานภายในระยะเวลาที่ระบุ
  • แสดงรหัสสถานะ HTTP ที่ไม่คาดคิด
  • ตอบกลับด้วยเนื้อความของข้อความที่ไม่ตรงกับเนื้อหาที่คาดไว้

  เมื่อเซิร์ฟเวอร์เป้าหมายไม่ผ่านการตรวจสอบประสิทธิภาพการทำงาน Edge จะเพิ่มจำนวนความล้มเหลวของเซิร์ฟเวอร์ดังกล่าว หากจำนวนความล้มเหลวของเซิร์ฟเวอร์นั้นตรงตามเกณฑ์หรือเกินเกณฑ์ที่กำหนดไว้ล่วงหน้า (<MaxFailures>) Edge จะหยุดส่งคำขอไปยังเซิร์ฟเวอร์นั้น

การเปิดใช้ Health Monitor

หากต้องการสร้าง HealthMonitor ให้เพิ่มองค์ประกอบ <HealthMonitor> ลงในการกำหนดค่า HTTPConnection ของ TargetEndpoint สำหรับพร็อกซี คุณดำเนินการนี้ใน UI ไม่ได้ แต่จะสร้างการกำหนดค่าพร็อกซีและอัปโหลดเป็นไฟล์ ZIP ไปยัง Edge แทน การกำหนดค่าพร็อกซีเป็นคำอธิบายที่มีโครงสร้างในทุกด้านของพร็อกซี API การกำหนดค่าพร็อกซีประกอบด้วยไฟล์ XML ในโครงสร้างไดเรกทอรีที่กำหนดไว้ล่วงหน้า ดูข้อมูลเพิ่มเติมได้ที่ข้อมูลอ้างอิงการกำหนดค่าพร็อกซี API

HealthMonitor แบบง่ายจะกำหนด IntervalInSec ที่รวมกับ TCPMonitor หรือ HTTPMonitor องค์ประกอบ <MaxFailures> ระบุจำนวนคำขอที่ล้มเหลวสูงสุดจากพร็อกซี API ที่ส่งไปยัง TargetServer ซึ่งส่งผลให้คำขอเปลี่ยนเส้นทางไปยัง TargetServer อื่น โดยค่าเริ่มต้น <MaxFailures> จะเป็น 0 ซึ่งหมายความว่า Edge จะไม่ดำเนินการแก้ไข เมื่อกำหนดค่าการตรวจสอบประสิทธิภาพการทำงาน ให้ตรวจสอบว่าคุณตั้งค่า <MaxFailures> ในแท็ก <HTTPTargetConnection> ของแท็ก <TargetEndpoint> เป็นค่าที่ไม่ใช่ 0 แล้ว

TCPMonitor

การกำหนดค่าด้านล่างกำหนด HealthMonitor ที่สำรวจ TargetServer แต่ละรายการโดยการเปิดการเชื่อมต่อที่พอร์ต 80 ทุก 5 วินาที (ไม่บังคับ) หากไม่ได้ระบุไว้ พอร์ต TCPMonitor จะเป็นพอร์ต TargetServer)

• หากการเชื่อมต่อล้มเหลวหรือใช้เวลาเชื่อมต่อมากกว่า 10 วินาที จำนวนความล้มเหลวจะเพิ่มขึ้น 1 สำหรับ TargetServer ดังกล่าว
• หากการเชื่อมต่อสำเร็จ จำนวนความล้มเหลวสำหรับ TargetServer จะรีเซ็ตเป็น 0

คุณเพิ่ม HealthMonitor เป็นองค์ประกอบย่อยขององค์ประกอบ HTTPTargetConnetion ของ TargetEndpoint ได้ดังที่แสดงด้านล่าง

<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>
. . .

การตรวจสอบประสิทธิภาพการทำงานที่มีองค์ประกอบการกำหนดค่า TCPMonitor

ตารางต่อไปนี้จะอธิบายองค์ประกอบของการกำหนดค่า TCPMonitor:

ชื่อ	คำอธิบาย	ค่าเริ่มต้น	จำเป็นหรือไม่
IsEnabled	บูลีนที่เปิดใช้หรือปิดใช้ HealthMonitor	false	ไม่ได้
IntervalInSec	ช่วงเวลาระหว่างคำขอ TCP แต่ละรายการในหน่วยวินาที	0	ใช่
ConnectTimeoutInSec	เวลาที่ต้องมีการเชื่อมต่อกับพอร์ต TCP จึงจะถือว่าสำเร็จ การเชื่อมต่อไม่สำเร็จตามระยะเวลาที่กำหนดนับเป็นความล้มเหลว ซึ่งเป็นการเพิ่มจำนวนความล้มเหลวของตัวจัดสรรภาระงานสำหรับ TargetServer	0	ใช่
Port	ไม่บังคับ พอร์ตที่จะสร้างการเชื่อมต่อ TCP หากไม่ได้ระบุไว้ พอร์ต TCPMonitor จะเป็นพอร์ต TargetServer	0	ไม่ได้

HTTPMonitor

ตัวอย่าง HealthMonitor ที่ใช้ HTTPMonitor จะส่งคำขอ GET ไปยังบริการแบ็กเอนด์ 1 ครั้งทุก 5 วินาที ตัวอย่างด้านล่างจะเพิ่มส่วนหัวการให้สิทธิ์ HTTP Basic ในข้อความคำขอ การกำหนดค่าการตอบกลับจะกำหนดการตั้งค่าที่จะเปรียบเทียบกับการตอบกลับจริงจากบริการแบ็กเอนด์ ในตัวอย่างด้านล่าง การตอบกลับที่คาดหวังคือโค้ดตอบกลับ HTTP 200 และส่วนหัว HTTP ที่กำหนดเอง ImOK ซึ่งมีค่าเป็น YourOK หากการตอบสนองไม่ตรงกัน การกำหนดค่าตัวจัดสรรภาระงานจะถือว่าคำขอนั้นเป็นความล้มเหลว

HTTPMonitor รองรับบริการแบ็กเอนด์ที่กำหนดค่าให้ใช้โปรโตคอล HTTP และ HTTPS ทางเดียว อย่างไรก็ตาม ระบบไม่รองรับรายการต่อไปนี้

• HTTPS แบบ 2 ทาง (หรือที่เรียกว่า TLS/SSL แบบ 2 ทาง)
• ใบรับรองแบบ Self-signed

โปรดทราบว่าการตั้งค่าคำขอและการตอบกลับทั้งหมดในการตรวจสอบ HTTP จะมีผลเฉพาะกับบริการแบ็กเอนด์ที่ต้องเรียกใช้

    <HealthMonitor>
      <IsEnabled>true</IsEnabled>
      <IntervalInSec>5</IntervalInSec>
      <HTTPMonitor>
        <Request>
          <IsSSL>true</IsSSL>
          <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>
    

Health Monitor ที่มีองค์ประกอบการกำหนดค่า HTTPMonitor

ตารางต่อไปนี้จะอธิบายองค์ประกอบการกำหนดค่า HTTPMonitor

ชื่อ	คำอธิบาย	ค่าเริ่มต้น	จำเป็นหรือไม่
IsEnabled	บูลีนที่เปิดใช้หรือปิดใช้ HealthMonitor	false	ไม่ได้
IntervalInSec	ช่วงเวลาระหว่างคำขอแบบสำรวจแต่ละรายการเป็นวินาที	0	ใช่
Request	ตัวเลือกการกำหนดค่าสำหรับข้อความคำขอขาออกที่ส่งโดย HealthMonitor ไปยังเซิร์ฟเวอร์ TargetServer ในการหมุนเวียน เส้นทางไม่รองรับตัวแปร	ไม่มีข้อมูล	ใช่
IsSSL	ระบุว่าจะใช้ HTTPS (HTTP ที่ปลอดภัย) สำหรับการตรวจสอบการเชื่อมต่อหรือไม่ ค่าที่เป็นไปได้มีดังนี้ true: ใช้ HTTP false: ใช้ HTTP ไม่ระบุ: ใช้การกำหนดค่าเซิร์ฟเวอร์เป้าหมาย	false	ไม่ได้
ConnectTimeoutInSec	เวลาเป็นวินาทีซึ่งแฮนด์เชคการเชื่อมต่อ TCP ไปยังบริการ HTTP ต้องเสร็จสมบูรณ์ จึงจะถือว่าสำเร็จ การเชื่อมต่อไม่สำเร็จภายในระยะเวลาที่กำหนดจะนับเป็นความล้มเหลว ทำให้จำนวนความล้มเหลวของ LoadBalancer สำหรับ TargetServer เพิ่มขึ้น	0	ไม่ได้
SocketReadTimeoutInSec	เวลาเป็นวินาทีที่ต้องอ่านข้อมูลจากบริการ HTTP จึงถือว่าสำเร็จ การอ่านข้อมูลในช่วงเวลาที่ระบุไม่สำเร็จจะนับเป็นความล้มเหลว ทำให้จำนวนความล้มเหลวของ LoadBalancer สำหรับ TargetServer เพิ่มขึ้น	0	ไม่ได้
Port	พอร์ตที่จะสร้างการเชื่อมต่อ HTTP กับบริการแบ็กเอนด์	ไม่มีข้อมูล	ไม่ได้
Verb	คำกริยา HTTP ที่ใช้สำหรับคำขอ HTTP ที่ส่งคำขอไปยังบริการแบ็กเอนด์แต่ละรายการ	ไม่มีข้อมูล	ไม่ได้
Path	เส้นทางต่อท้าย URL ที่กำหนดไว้ใน TargetServer ใช้องค์ประกอบเส้นทางเพื่อกำหนดค่า "ปลายทางการสำรวจ" ในบริการ HTTP	ไม่มีข้อมูล	ไม่ได้
IncludeHealthCheckIdHeader	ช่วยให้คุณติดตามคำขอตรวจสอบประสิทธิภาพการทำงานในระบบอัปสตรีมได้ โดย IncludeHealthCheckIdHeader จะใช้ค่าบูลีนและค่าเริ่มต้นคือ false หากคุณตั้งค่าเป็น true จะมี Header ชื่อ X-Apigee-Healthcheck-Id ซึ่งแทรกอยู่ในคำขอการตรวจสอบประสิทธิภาพการทำงาน ค่าของส่วนหัวจะกำหนดแบบไดนามิกและอยู่ในรูปแบบ ORG/ENV/SERVER_UUID/N โดยที่ ORG เป็นชื่อองค์กร, ENV เป็นชื่อสภาพแวดล้อม, SERVER_UUID คือรหัสที่ไม่ซ้ำกันที่ระบุ MP และ N คือจำนวนมิลลิวินาทีที่ผ่านไปตั้งแต่วันที่ 1 มกราคม 1970 ตัวอย่างส่วนหัวของคำขอที่ได้ X-Apigee-Healthcheck-Id: orgname/envname/E8C4D2EE-3A69-428A-8616-030ABDE864E0/1586802968123	false	ไม่ได้
Payload	เนื้อหา HTTP ที่สร้างขึ้นสำหรับคำขอ HTTP แบบสำรวจแต่ละรายการ โปรดทราบว่าไม่จำเป็นต้องใช้องค์ประกอบนี้สำหรับคำขอ GET	ไม่มีข้อมูล	ไม่ได้
SuccessResponse	รูปแบบการทำงานของข้อความตอบกลับ HTTP ขาเข้าที่สร้างขึ้นโดยบริการแบ็กเอนด์ที่สำรวจ จำนวนคำตอบที่ไม่ตรงกันจะเพิ่มการนับความล้มเหลวขึ้น 1	ไม่มีข้อมูล	ไม่ได้
ResponseCode	โค้ดตอบกลับ HTTP ที่คาดว่าจะได้รับจาก TargetServer ที่สำรวจ รหัสที่แตกต่างจากรหัสที่ระบุจะส่งผลให้ระบบดำเนินการไม่สำเร็จและจำนวนที่เพิ่มขึ้นสำหรับบริการแบ็กเอนด์ที่สำรวจ คุณสามารถกำหนดองค์ประกอบ ResponseCode ได้หลายรายการ	ไม่มีข้อมูล	ไม่ได้
Headers	รายการส่วนหัวและค่า HTTP อย่างน้อย 1 รายการที่คาดว่าจะได้รับจากบริการแบ็กเอนด์ที่สำรวจ ส่วนหัวหรือค่า HTTP ในการตอบสนองที่แตกต่างจากที่ระบุไว้จะทำให้เกิดข้อผิดพลาด และจำนวนสำหรับ TargetServer ที่สำรวจจะเพิ่มขึ้น 1 รายการ คุณสามารถกำหนดองค์ประกอบส่วนหัวได้หลายรายการ	ไม่มีข้อมูล	ไม่ได้