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

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

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

การกำหนดค่า TargetServer แยก URL ปลายทางที่เป็นรูปธรรมจาก TargetEndpoint การกำหนดค่าเอง มีการอ้างอิง TargetServer แต่ละรายการตามชื่อใน TargetEndpoint HTTPConnection แทนที่จะกำหนด URL ที่เป็นรูปธรรมในการกำหนดค่า คุณสามารถกำหนดค่า URL ได้ หรือชื่อ TargetServers หลายรายการตามที่อธิบายไว้ในส่วน 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 การกำหนด 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 ต่อไปนี้เพื่อเรียกข้อมูลรายการ TargetServers ในสภาพแวดล้อม

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

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

[ "target2", "target1" ]

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

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

การกําหนดค่า TargetEndpoint เพื่อโหลดการจัดสรรภาระงานทั่วทั้ง TargetServers ที่มีชื่อ

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

องค์ประกอบ <Path> สร้างเส้นทางฐานของ URI ของ TargetEndpoint สำหรับ เซิร์ฟเวอร์เป้าหมายทั้งหมด และจะใช้เฉพาะเมื่อใช้ <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>

ระบุน้ำหนัก

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

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

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

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

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

HTTPMonitor

HealthMonitor ตัวอย่างที่ใช้ HTTPMonitor จะส่งคำขอ GET ไปยังแบ็กเอนด์ 1 ครั้งทุก 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>
    

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

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