Microsoft Azure ให้บริการโหลดบาลานซ์สำหรับเครื่องเสมือน (IaaS) และบริการคลาวด์ (PaaS) ที่โฮสต์ในระบบคลาวด์ Microsoft Azure การจัดสรรภาระงานช่วยให้แอปพลิเคชันของคุณสามารถปรับขนาดและให้ความยืดหยุ่นต่อความล้มเหลวของแอปพลิเคชัน รวมถึงประโยชน์อื่นๆ
สามารถเข้าถึงบริการโหลดบาลานซ์ได้โดยการระบุจุดสิ้นสุดอินพุตบนบริการของคุณผ่านทาง Microsoft Azure Portal หรือผ่านทางรูปแบบการบริการของใบสมัครของคุณ เมื่อมีการปรับใช้บริการโฮสต์ที่มีจุดสิ้นสุดอินพุตตั้งแต่หนึ่งจุดขึ้นไปใน Microsoft Azure บริการดังกล่าวจะกำหนดค่าบริการโหลดบาลานซ์ที่นำเสนอโดยแพลตฟอร์ม Microsoft Azure โดยอัตโนมัติ เพื่อให้ได้รับประโยชน์จากความยืดหยุ่น/ความซ้ำซ้อนของบริการของคุณ คุณต้องมีเครื่องเสมือนอย่างน้อยสองเครื่องที่ให้บริการปลายทางเดียวกัน
ไดอะแกรมต่อไปนี้เป็นตัวอย่างของแอปพลิเคชันที่โฮสต์ใน Microsoft Azure ที่ใช้บริการโหลดบาลานซ์เพื่อกำหนดเส้นทางการรับส่งข้อมูลขาเข้า (ตามที่อยู่/พอร์ต 1.2.3.4:80) ไปยังเครื่องเสมือนสามเครื่อง โดยทั้งหมดรับฟังอยู่บนพอร์ต 80
คุณสมบัติที่สำคัญของบริการโหลดบาลานซ์ใน Microsoft Azure คือ:
รองรับ PaaS / IaaS
บริการโหลดบาลานซ์ใน Microsoft Azure ทำงานร่วมกับผู้เช่าทุกประเภท (IaaS หรือ PaaS) และระบบปฏิบัติการทุกรสชาติ (รองรับ Windows หรือระบบปฏิบัติการ Linux)
ผู้เช่า PaaS ได้รับการกำหนดค่าผ่านทางรูปแบบการบริการ. ผู้เช่า IaaS คือกำหนดค่าผ่านพอร์ทัลการจัดการหรือผ่าน PowerShell
Layer-4 Load Balancer การกระจายตามแฮช
Microsoft Azure Load Balancer เป็นโหลดบาลานเซอร์ประเภท Layer-4 ตัวจัดสรรภาระงาน Microsoft Azure กระจายโหลดระหว่างชุดของเซิร์ฟเวอร์ที่มีอยู่ (เครื่องเสมือน) โดยการคำนวณฟังก์ชันแฮชบนทราฟฟิกที่ได้รับบนจุดสิ้นสุดอินพุตที่กำหนด ฟังก์ชันแฮชถูกคำนวณเพื่อให้แพ็กเก็ตทั้งหมดจากการเชื่อมต่อเดียวกัน (TCP หรือ UDP) สิ้นสุดบนเซิร์ฟเวอร์เดียวกัน Microsoft Azure Load Balancer ใช้ 5 tuple (IP ต้นทาง, พอร์ตต้นทาง, IP ปลายทาง, พอร์ตปลายทาง, ประเภทโปรโตคอล) เพื่อคำนวณแฮชที่ใช้ในการแมปการรับส่งข้อมูลกับเซิร์ฟเวอร์ที่มีอยู่ ฟังก์ชันแฮชถูกเลือกเพื่อให้การกระจายการเชื่อมต่อกับเซิร์ฟเวอร์ค่อนข้างสุ่ม อย่างไรก็ตาม ขึ้นอยู่กับรูปแบบการรับส่งข้อมูล เป็นไปได้ที่การเชื่อมต่อที่แตกต่างกันจะถูกแมปกับเซิร์ฟเวอร์เดียวกัน (โปรดทราบว่าการกระจายการเชื่อมต่อกับเซิร์ฟเวอร์คือไม่โรบินรอบ,ไม่ใช่ทั้งสองอย่างไม่มีการขอเข้าคิวใดๆ ทั้งสิ้น ดังที่ได้กล่าวไว้อย่างผิดๆ ในบางบทความ และบางบล็อก) สมมติฐานพื้นฐานของฟังก์ชันแฮชนั้นได้รับคำขอจำนวนมากที่มาจากไคลเอนต์ต่างๆ จำนวนมาก คุณจะได้รับคำขอจำนวนมากกระจายไปทั่วเซิร์ฟเวอร์
รองรับหลายโปรโตคอล
บริการโหลดบาลานซ์ใน Microsoft Azure รองรับโปรโตคอล TCP และ UDP ลูกค้าสามารถระบุโปรโตคอลในข้อมูลจำเพาะของตำแหน่งข้อมูลอินพุตในรูปแบบบริการของตน ผ่าน PowerShell หรือพอร์ทัลการจัดการ
การสนับสนุนปลายทางหลายรายการ
บริการที่เป็นโฮสต์สามารถระบุจุดสิ้นสุดอินพุตได้หลายรายการ และจะได้รับการกำหนดค่าโดยอัตโนมัติในบริการโหลดบาลานซ์
ขณะนี้ยังไม่รองรับปลายทางหลายรายการที่มีพอร์ตและโปรโตคอลเดียวกัน นอกจากนี้ยังมีขีดจำกัดของจำนวนจุดสิ้นสุดสูงสุดที่บริการโฮสต์สามารถมีได้ซึ่งปัจจุบันตั้งไว้ที่ 150 จุด
การสนับสนุนปลายทางภายใน
ทุกบริการสามารถระบุได้ถึง 25 จุดสิ้นสุดภายในที่ไม่ได้เปิดเผยตัวโหลดบาลานเซอร์และใช้สำหรับการสื่อสารระหว่างบทบาทบริการ
รองรับ Direct Port Endpoint (Instance Input Endpoint)
บริการโฮสต์สามารถระบุได้ว่าปลายทางที่กำหนดไม่ควรโหลดบาลานซ์และได้รับการเข้าถึงโดยตรงไปยังเครื่องเสมือนที่โฮสต์บริการ ซึ่งช่วยให้แอปพลิเคชันสามารถควบคุมการเปลี่ยนเส้นทางที่เป็นไปได้ของไคลเอนต์ไปยังอินสแตนซ์ของแอปพลิเคชัน (VM) ที่กำหนดได้โดยตรง โดยไม่ต้องโหลดคำขอแต่ละรายการให้สมดุล (และเป็นผลให้ส่งไปยังอินสแตนซ์อื่นได้)
การกำหนดค่าใหม่อัตโนมัติเมื่อลด/ลดขนาด การรักษาบริการ และการอัปเดต
บริการโหลดบาลานซ์ทำงานร่วมกับ Microsoft Azure Compute Service เพื่อให้แน่ใจว่าหากจำนวนอินสแตนซ์ของเซิร์ฟเวอร์ที่ระบุสำหรับจุดสิ้นสุดอินพุตเพิ่มขึ้นหรือลดลง (เนื่องจากการเพิ่มจำนวนอินสแตนซ์สำหรับบทบาทเว็บ/ผู้ปฏิบัติงาน หรือเนื่องจากการใส่ VM ถาวรเพิ่มเติม ภายใต้กลุ่มโหลดบาลานซ์เดียวกัน) บริการโหลดบาลานซ์จะกำหนดค่าใหม่โดยอัตโนมัติเพื่อให้โหลดบาลานซ์เป็นอินสแตนซ์ที่เพิ่มขึ้นหรือลดลง
บริการโหลดบาลานซ์ยังกำหนดค่าตัวเองใหม่อย่างโปร่งใสเพื่อตอบสนองต่อบริการการกระทำการรักษาโดยตัวควบคุมแฟบริคของ Microsoft Azure หรือการอัปเดตบริการโดยลูกค้า
การตรวจสอบบริการ
บริการโหลดบาลานซ์มีความสามารถในการตรวจสอบความสมบูรณ์ของอินสแตนซ์เซิร์ฟเวอร์ต่างๆ และนำอินสแตนซ์เซิร์ฟเวอร์ที่ไม่แข็งแรงออกจากการหมุนเวียน โพรบที่รองรับมีสามประเภท: โพรบ Guest Agent (บน PaaS VM), โพรบแบบกำหนดเอง HTTP และโพรบแบบกำหนดเอง TCP ในกรณีของตัวแทนแขกบริการโหลดบาลานซ์จะสอบถาม Guest Agent ใน VM เพื่อเรียนรู้เกี่ยวกับสถานะของบริการ ในกรณีของ HTTP บริการโหลดบาลานซ์อาศัยการดึง URL ที่ระบุเพื่อกำหนดความสมบูรณ์ของอินสแตนซ์ สำหรับ TCP จะอาศัยการสร้างเซสชัน TCP ที่สำเร็จไปยังพอร์ตโพรบที่กำหนด
ที่มา แนท (SNAT)
การรับส่งข้อมูลขาออกทั้งหมดที่มาจากบริการเป็น Source NATed (SNAT) โดยใช้ที่อยู่ VIP เดียวกันกับการรับส่งข้อมูลขาเข้า เราจะเจาะลึกวิธีการทำงานของ SNAT ในโพสต์ถัดไป
การเพิ่มประสิทธิภาพการรับส่งข้อมูลภายในศูนย์ข้อมูล
Microsoft Azure Load Balancer เพิ่มประสิทธิภาพการรับส่งข้อมูลระหว่างศูนย์ข้อมูล Microsoft Azure ในภูมิภาคเดียวกัน เช่น การรับส่งข้อมูลระหว่างผู้เช่า Azure ที่พูดคุยผ่าน VIP และอยู่ภายในภูมิภาคเดียวกัน หลังจากเริ่มต้นการเชื่อมต่อ TCP/IP พวกเขาข้าม Microsoft Azure Load Balancer ไปพร้อมกัน
การแลกเปลี่ยนวีไอพี
Microsoft Azure Load Balancer อนุญาตให้มีการสลับ VIP ของผู้เช่าสองราย อนุญาตให้ย้ายผู้เช่าที่อยู่ใน "ขั้นตอน" เป็น "การผลิต" และในทางกลับกัน การดำเนินการ VIP Swap ทำให้ไคลเอ็นต์สามารถใช้ VIP คนเดิมเพื่อพูดคุยกับบริการ ในขณะที่ใช้บริการเวอร์ชันใหม่ เวอร์ชันใหม่ของบริการสามารถปรับใช้และทดสอบได้โดยไม่รบกวนการรับส่งข้อมูลที่ใช้งานจริงในสภาพแวดล้อมชั่วคราว เมื่อเวอร์ชันใหม่ผ่านการทดสอบที่จำเป็นแล้ว ก็สามารถเลื่อนขั้นเป็นเวอร์ชันที่ใช้งานจริงได้โดยการสลับกับบริการเวอร์ชันที่ใช้งานจริงที่มีอยู่ ความเชื่อมโยงที่มีอยู่กับการผลิตแบบ “เก่า” ยังคงดำเนินต่อไปโดยไม่มีการเปลี่ยนแปลง การเชื่อมต่อใหม่จะถูกส่งตรงไปยังสภาพแวดล้อมการผลิต "ใหม่"
ตัวอย่าง: บริการโหลดบาลานซ์
ต่อไปเราจะมาดูกันว่าคุณสมบัติข้างต้นส่วนใหญ่ที่นำเสนอโดยบริการโหลดบาลานซ์สามารถใช้ในบริการคลาวด์ตัวอย่างได้อย่างไร ผู้เช่า PaaS ที่เราต้องการจำลองแสดงในแผนภาพด้านล่าง:
ผู้เช่ามีสองบทบาทส่วนหน้า (FE) และหนึ่งบทบาทส่วนหลัง (BE) บทบาท FE แสดงจุดสิ้นสุดโหลดบาลานซ์สี่จุดโดยใช้โปรโตคอล http, tcp และ udp จุดสิ้นสุดจุดหนึ่งยังใช้เพื่อระบุความสมบูรณ์ของบทบาทไปยังโหลดบาลานเซอร์ บทบาท BE แสดงจุดสิ้นสุดสามจุดโดยใช้โปรโตคอล http, tcp และ udp ทั้งบทบาท FE และ BE จะแสดงปลายทางพอร์ตโดยตรงหนึ่งจุดไปยังอินสแตนซ์ที่สอดคล้องกันของบริการ
บริการข้างต้นแสดงดังต่อไปนี้โดยใช้สีฟ้ารูปแบบการบริการ(ข้อกำหนดสคีมาบางอย่างถูกลบออกเพื่อให้ชัดเจนยิ่งขึ้น):
<คำจำกัดความของบริการชื่อ=“Probeผู้เช่า“>
<LoadBalancerProbes>
<LoadBalancerProbeชื่อ=“มายโพรบ”มาตรการ=“http”เส้นทาง=“Probe.aspx”ช่วงเวลาเป็นวินาที=“5”หมดเวลาเป็นวินาที=“100“/>
LoadBalancerProbes>
<บทบาทของผู้ปฏิบัติงานชื่อ=“เบโรล”vmsize=“เล็ก“>
<จุดสิ้นสุด>
<จุดสิ้นสุดภายในชื่อ=“BE_InternalEP_Tcp”มาตรการ=“ทีซีพี“/>
<จุดสิ้นสุดภายในชื่อ=“BE_InternalEP_Udp”มาตรการ=“อู๊ด“/>
<จุดสิ้นสุดภายในชื่อ=“BE_InternalEP_Http”มาตรการ=“http”ท่าเรือ=“80“/>
<InstanceInputEndpointชื่อ=“ตัวอย่างEP_BE”มาตรการ=“ทีซีพี”พอร์ตท้องถิ่น=“80“>
<จัดสรร PublicPort จาก>
<แก้ไขพอร์ตเรนจ์นาที=“10210”สูงสุด=“10220“/>
จัดสรร PublicPort จาก>
InstanceInputEndpoint>
จุดสิ้นสุด>
บทบาทของผู้ปฏิบัติงาน>
<บทบาทของผู้ปฏิบัติงานชื่อ=“เฟอโรล”vmsize=“เล็ก“>
<จุดสิ้นสุด>
<จุดสิ้นสุดอินพุตชื่อ=“FE_External_Http”มาตรการ=“http”ท่าเรือ=“10,000“/>
<จุดสิ้นสุดอินพุตชื่อ=“FE_ภายนอก_Tcp“มาตรการ=“ทีซีพี“ท่าเรือ=“10001“/>
<จุดสิ้นสุดอินพุตชื่อ=“FE_External_Udp“มาตรการ=“อู๊ด“ท่าเรือ=“10002“/>
<จุดสิ้นสุดอินพุตชื่อ=“HTTP_Probe”มาตรการ=“http”ท่าเรือ=“80”loadBalancerProbe=“มายโพรบ“/>
<InstanceInputEndpointชื่อ=“ตัวอย่างEP”มาตรการ=“ทีซีพี”พอร์ตท้องถิ่น=“80“>
<จัดสรร PublicPort จาก>
<แก้ไขพอร์ตเรนจ์นาที=“10110”สูงสุด=“10120“/>
จัดสรร PublicPort จาก>
InstanceInputEndpoint>
<จุดสิ้นสุดภายในชื่อ=“FE_InternalEP_Tcp”มาตรการ=“ทีซีพี“/>
จุดสิ้นสุด>
บทบาทของผู้ปฏิบัติงาน>
คำจำกัดความของบริการ>
การวิเคราะห์รูปแบบบริการ เราเริ่มต้นด้วยการกำหนดโพรบสถานะที่โหลดบาลานเซอร์ควรใช้เพื่อสอบถามสถานะของบริการ:
<LoadBalancerProbes>
<LoadBalancerProbeชื่อ=“มายโพรบ”มาตรการ=“http”เส้นทาง=“Probe.aspx”ช่วงเวลาเป็นวินาที=“5”หมดเวลาเป็นวินาที=“100“/>
LoadBalancerProbes>
สิ่งนี้บอกว่าเรามีโพรบที่กำหนดเอง http โดยใช้เส้นทางสัมพัทธ์ของ URL “Probe.aspx” โพรบนี้จะถูกแนบในภายหลังกับจุดสิ้นสุดเพื่อระบุอย่างครบถ้วน
ต่อไป เราจะกำหนดบทบาท FE เป็นบทบาทผู้ปฏิบัติงาน มีจุดสิ้นสุดโหลดบาลานซ์หลายจุดโดยใช้ http, tcp และ udp ดังนี้:
<จุดสิ้นสุดอินพุตชื่อ=“FE_External_Http”มาตรการ=“http”ท่าเรือ=“10,000“/>
<จุดสิ้นสุดอินพุตชื่อ=“FE_ภายนอก_Tcp“มาตรการ=“ทีซีพี“ท่าเรือ=“10001“/>
<จุดสิ้นสุดอินพุตชื่อ=“FE_External_Udp“มาตรการ=“อู๊ด“ท่าเรือ=“10002“/>
เนื่องจากเราไม่ได้กำหนดโพรบแบบกำหนดเองให้กับจุดสิ้นสุดเหล่านี้ ความสมบูรณ์ของจุดสิ้นสุดข้างต้นจึงถูกควบคุมโดยตัวแทนผู้เยี่ยมชมบน VM และสามารถเปลี่ยนแปลงได้โดยบริการโดยใช้ตรวจสอบสถานะเหตุการณ์.
ต่อไป เราจะกำหนดปลายทาง http เพิ่มเติมบนพอร์ต 80 ซึ่งใช้โพรบแบบกำหนดเองที่เรากำหนดไว้ก่อนหน้านี้ (MyProbe):
<จุดสิ้นสุดอินพุตชื่อ=“HTTP_Probe”มาตรการ=“http”ท่าเรือ=“80”loadBalancerProbe=“มายโพรบ“/>
ตัวจัดสรรภาระงานรวมข้อมูลของปลายทางและข้อมูลของโพรบ เพื่อสร้าง URL ในรูปแบบของ: https://{DIP of VM}:80/Probe.aspx ที่จะใช้เพื่อสอบถามสถานะของบริการ . บริการจะแจ้งให้ทราบ (ในบันทึก ?) ว่ามีการเข้าถึง IP เดียวกันเป็นระยะๆ นี่คือคำขอโพรบสุขภาพที่มาจากโฮสต์ของโหนดที่ VM กำลังทำงานอยู่
บริการต้องตอบสนองด้วยรหัสสถานะ HTTP 200 เพื่อให้โหลดบาลานเซอร์ถือว่าบริการมีความสมบูรณ์ รหัสสถานะ HTTP อื่นๆ (เช่น 503) จะนำ VM ออกจากการหมุนเวียนโดยตรง
คำจำกัดความของโพรบยังควบคุมความถี่ของโพรบ ในกรณีของเราข้างต้น ตัวโหลดบาลานเซอร์กำลังตรวจสอบจุดสิ้นสุดทุกๆ 15 วินาที หากไม่ได้รับคำตอบที่เป็นบวกเป็นเวลา 30 วินาที (สองช่วงเวลาของโพรบ) โพรบจะถูกถือว่าหยุดทำงานและ VM จะถูกนำออกจากการหมุน ในทำนองเดียวกัน หากบริการไม่หมุนเวียนและได้รับคำตอบที่เป็นบวก บริการนั้นจะกลับมาหมุนเวียนทันที หากบริการมีความผันผวนระหว่างปกติดี/ไม่ดี ตัวโหลดบาลานเซอร์สามารถตัดสินใจชะลอการนำบริการกลับมาหมุนเวียนใหม่ได้จนกว่าจะมีโพรบจำนวนหนึ่งเป็นปกติ
บริการ FE แสดงชุดของพอร์ตโดยตรง หนึ่งพอร์ตสำหรับแต่ละอินสแตนซ์ (จุดสิ้นสุดอินพุตของอินสแตนซ์) ที่เชื่อมต่อโดยตรงกับอินสแตนซ์ FE บนพอร์ตที่ระบุด้านล่าง:
<InstanceInputEndpointชื่อ=“ตัวอย่างEP”มาตรการ=“ทีซีพี”พอร์ตท้องถิ่น=“80“>
<จัดสรร PublicPort จาก>
<แก้ไขพอร์ตเรนจ์นาที=“10110”สูงสุด=“10120“/>
จัดสรร PublicPort จาก>
InstanceInputEndpoint>
คำจำกัดความข้างต้นเชื่อมต่อโดยใช้พอร์ต tcp 10110, 10111, … กับพอร์ต 80 ของแต่ละอินสแตนซ์ VM ของบทบาท FE ความสามารถนี้สามารถใช้ได้หลายวิธี:
ก) รับการเข้าถึงโดยตรงไปยังอินสแตนซ์ที่กำหนดและดำเนินการกับอินสแตนซ์นั้นเท่านั้น
b) เปลี่ยนเส้นทางแอปของผู้ใช้ไปยังอินสแตนซ์เฉพาะหลังจากผ่านจุดสิ้นสุดที่สมดุลของโหลด สามารถใช้สำหรับเซสชัน "เหนียว" กับอินสแตนซ์ที่กำหนด โปรดทราบว่าสิ่งนี้อาจทำให้อินสแตนซ์นั้นโอเวอร์โหลดและลบความซ้ำซ้อนใดๆ
สุดท้าย บทบาท FE เปิดเผยจุดสิ้นสุดภายใน ซึ่งสามารถใช้สำหรับการสื่อสารระหว่างบทบาท FE / BE:
<จุดสิ้นสุดภายในชื่อ=“FE_InternalEP_Tcp”มาตรการ=“ทีซีพี“/>
แต่ละบทบาทสามารถค้นพบจุดสิ้นสุดที่เปิดเผย รวมถึงจุดสิ้นสุดที่แต่ละบทบาทกำลังเปิดเผยโดยใช้คลาส RoleEnvironment
บทบาท BE ยังจำลองเป็น WorkerRole
บทบาท BE ไม่เปิดเผยจุดสิ้นสุดของโหลดบาลานซ์ เฉพาะจุดสิ้นสุดภายในที่ใช้ http, tcp และ udp:
<จุดสิ้นสุดภายในชื่อ=“BE_InternalEP_Tcp”มาตรการ=“ทีซีพี“/>
<จุดสิ้นสุดภายในชื่อ=“BE_InternalEP_Udp”มาตรการ=“อู๊ด“/>
<จุดสิ้นสุดภายในชื่อ=“BE_InternalEP_Http”มาตรการ=“http”ท่าเรือ=“80“/>
บทบาท BE ยังเปิดเผยจุดสิ้นสุดอินพุตของอินสแตนซ์ที่เชื่อมต่อโดยตรงกับอินสแตนซ์ BE:
<InstanceInputEndpointชื่อ=“ตัวอย่างEP_BE”มาตรการ=“ทีซีพี”พอร์ตท้องถิ่น=“80“>
<จัดสรร PublicPort จาก>
<แก้ไขพอร์ตเรนจ์นาที=“10210”สูงสุด=“10220“/>
จัดสรร PublicPort จาก>
InstanceInputEndpoint>
คำจำกัดความข้างต้นเชื่อมต่อโดยใช้พอร์ต tcp 10210, … ไปยังพอร์ต 80 ของแต่ละอินสแตนซ์ VM ของบทบาท BE
เราหวังว่าตัวอย่างข้างต้นจะแสดงให้เห็นว่าคุณลักษณะการจัดสรรภาระงานทั้งหมดสามารถใช้ร่วมกันเพื่อสร้างแบบจำลองบริการได้อย่างไร
ในโพสต์ในอนาคต เราจะเห็นผู้เช่ารายนี้ดำเนินการจริง และให้ตัวอย่างโค้ด นอกจากนี้ เราจะอธิบายรายละเอียดเพิ่มเติม:
ก) วิธีการทำงานของ SNAT
b) โพรบแบบกำหนดเอง
ค) เครือข่ายเสมือน
นอกจากนี้ โปรดส่งคำขอของคุณเกี่ยวกับสิ่งที่คุณต้องการดูรายละเอียดเพิ่มเติม
สำหรับทีม Microsoft Azure Networking
มาริออส ซิโก้