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

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

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

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

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

วิดีโอ

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

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

โค้ดต่อไปนี้กำหนดเซิร์ฟเวอร์เป้าหมาย

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

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

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

การจัดการเซิร์ฟเวอร์เป้าหมายโดยใช้ 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 ที่ 2 การกำหนด 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 เพื่อใช้ TargetServer

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

การกำหนดค่า TargetEndpoint เพื่อกระจายภาระงานใน TargetServer ที่มีชื่อ

ตอนนี้คุณมี TargetServer 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, Weighted และ Least Connection Round Robin เป็นอัลกอริทึมเริ่มต้น เนื่องจากไม่ได้ระบุอัลกอริทึมในการกำหนดค่าข้างต้น คำขอขาออกจากพร็อกซี API ไปยังเซิร์ฟเวอร์แบ็กเอนด์จะสลับกันระหว่าง target1 และ target2

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

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

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

อัลกอริทึม

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

การสลับกันทำงาน

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

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

ระบุน้ำหนัก

อัลกอริทึมการจัดสรรภาระงานแบบถ่วงน้ำหนักช่วยให้คุณกำหนดค่าภาระงานการเข้าชมตามสัดส่วนสำหรับ TargetServer ได้ 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 สำหรับทุกๆ คำขอ 1 รายการที่กำหนดเส้นทางไปยัง target1

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

LoadBalancer ที่กำหนดค่าให้ใช้อัลกอริทึมการเชื่อมต่อน้อยที่สุดจะกำหนดเส้นทางคำขอขาออกไปยัง 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 และไม่ได้กำหนดค่า เครื่องมือตรวจสอบสถานะ Apigee จะนำเซิร์ฟเวอร์เป้าหมายออกจากรอบโดยอัตโนมัติเมื่อ ตรวจพบความล้มเหลวครั้งแรก Apigee จะตรวจสอบสถานะของเซิร์ฟเวอร์เป้าหมายทุกๆ 5 นาทีและนำกลับไป หมุนเวียนเมื่อเซิร์ฟเวอร์ตอบกลับตามปกติ

ลองอีกครั้ง

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

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

<RetryEnabled>false</RetryEnabled>

IsFallback

คุณตั้งค่า TargetServer ได้ 1 รายการ (และเพียง 1 รายการเท่านั้น) เป็นเซิร์ฟเวอร์ "สำรอง" ระบบจะไม่รวม 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>

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

เส้นทาง

Path กำหนด URI Fragment ที่จะต่อท้ายคำขอทั้งหมดที่ออกโดย 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 เดียวกันกับ TargetEndpoint

<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 จะเริ่มส่งการตรวจสอบความสมบูรณ์ไปยังเซิร์ฟเวอร์เป้าหมาย การตรวจสอบสถานะคือคำขอที่ส่งไปยังเซิร์ฟเวอร์เป้าหมายเพื่อพิจารณาว่าเซิร์ฟเวอร์เป้าหมายมีสถานะปกติหรือไม่

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

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

  เมื่อ Edge ระบุว่าเซิร์ฟเวอร์ทำงานได้ปกติ Edge จะส่งคำขอไปยังเซิร์ฟเวอร์นั้นต่อไปหรือกลับมาส่งคำขออีกครั้ง

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

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

การเปิดใช้ HealthMonitor

หากต้องการสร้าง 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>
. . .

HealthMonitor ที่มีองค์ประกอบการกำหนดค่า TCPMonitor

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

HTTPMonitor

HealthMonitor ตัวอย่างที่ใช้ HTTPMonitor จะส่งคำขอ GET ไปยังบริการแบ็กเอนด์ ทุกๆ 5 วินาที ตัวอย่างด้านล่างจะเพิ่มส่วนหัวการให้สิทธิ์ HTTP ขั้นพื้นฐานลงในข้อความคำขอ การกำหนดค่าการตอบกลับจะกำหนดการตั้งค่าที่จะเปรียบเทียบกับการตอบกลับจริง จากบริการแบ็กเอนด์ ในตัวอย่างด้านล่าง การตอบกลับที่คาดไว้คือโค้ดตอบกลับ 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>
    

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

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