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

คุณกำลังดูเอกสารประกอบของ 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>

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

เส้นทาง

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

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

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

  เมื่อ 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