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

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

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

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

คําจํากัดความของ 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 การกําหนด TargetServers 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 ต่อไปนี้เพื่อเรียกข้อมูลรายการ TargetServers ในสภาพแวดล้อม

$ 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 ที่มีชื่อ

เมื่อคุณมี TargetServers 2 รายการแล้ว คุณสามารถแก้ไขการตั้งค่าการเชื่อมต่อ HTTP ของ TargetEndpoint เพื่ออ้างอิง TargetServers 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 กับ target 2

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

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

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

อัลกอริทึม

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

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

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

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

ระบุน้ำหนัก

อัลกอริทึมการจัดสรรภาระงานแบบถ่วงน้ำหนักช่วยให้คุณกำหนดค่าภาระการรับส่งข้อมูลตามสัดส่วนสำหรับเซิร์ฟเวอร์เป้าหมายได้ 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) ระบบก็จะนับเป็นการตอบกลับจากเซิร์ฟเวอร์เป้าหมาย และรีเซ็ตตัวนับการไม่สําเร็จ คุณสามารถเพิ่มองค์ประกอบ <ServerUnhealthyResponse> ที่มีองค์ประกอบย่อย <ResponseCode> ลงในการกำหนดค่าตัวจัดสรรภาระงานได้เพื่อช่วยตรวจสอบว่าการตอบกลับ HTTP ที่ไม่ถูกต้อง (เช่น 500) จะเพิ่มตัวนับการไม่สําเร็จด้วยเพื่อนำเซิร์ฟเวอร์ที่ไม่เสถียรออกจากการหมุนเวียนการจัดสรรภาระงานโดยเร็วที่สุด นอกจากนี้ 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 รายการเท่านั้น TargetServer สำรองจะไม่รวมอยู่ในกิจวัตรการจัดสรรภาระงานจนกว่าตัวจัดสรรภาระงานจะระบุว่า TargetServer อื่นๆ ทั้งหมดไม่พร้อมใช้งาน เมื่อระบบตรวจสอบความสมดุลของภาระงานแล้วพบว่า TargetServers ทั้งหมดไม่พร้อมใช้งาน ระบบจะกำหนดเส้นทางการเข้าชมทั้งหมดไปยังเซิร์ฟเวอร์สำรอง เช่น

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

สคีมา 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 ข้อ
  • เซิร์ฟเวอร์เป้าหมายยอมรับการเชื่อมต่อใหม่กับพอร์ตที่ระบุ ตอบสนองต่อคำขอในพอร์ตนั้น แล้วปิดพอร์ตภายในกรอบเวลาที่กำหนด การตอบกลับจากเซิร์ฟเวอร์เป้าหมายมี "Connection: close"
  • เซิร์ฟเวอร์เป้าหมายตอบกลับคําขอตรวจสอบสถานะด้วยรหัสสถานะ 200 (OK) หรือรหัสสถานะ HTTP อื่นๆ ที่คุณพิจารณาว่ายอมรับได้
  • เซิร์ฟเวอร์เป้าหมายตอบกลับคำขอตรวจสอบประสิทธิภาพการทำงานด้วยเนื้อหาข้อความที่ตรงกับเนื้อหาข้อความที่คาดไว้

  เมื่อ 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 แบบ 1 ทิศทาง แต่จะไม่รองรับรายการต่อไปนี้

• 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