หมายเหตุ
การเข้าถึงหน้านี้ต้องได้รับการอนุญาต คุณสามารถลอง ลงชื่อเข้าใช้หรือเปลี่ยนไดเรกทอรีได้
การเข้าถึงหน้านี้ต้องได้รับการอนุญาต คุณสามารถลองเปลี่ยนไดเรกทอรีได้
หลังจากที่คุณตัดสินใจใช้ ExpressRoute สำหรับ Power Platform ขั้นตอนต่อไปของคุณคือการวางแผนการปรับใช้งาน บทความนี้ให้คำแนะนำเกี่ยวกับข้อกำหนดเบื้องต้นและข้อควรพิจารณา
ข้อกำหนดเบื้องต้นสำหรับการใช้ ExpressRoute
ExpressRoute ต้องการข้อกำหนดเบื้องต้นเฉพาะ ความล้มเหลวในการวางแผนอาจส่งผลให้เกิดค่าใช้จ่ายที่ไม่คาดคิดขัดขวางโครงการและส่งผลกระทบต่อการดำเนินงานของบริการอื่น ๆ
การเชื่อมต่อทางกายภาพตั้งค่าโดยผู้ให้บริการการเชื่อมต่อ ExpressRoute ไม่ได้ให้การเชื่อมต่อทางกายภาพเอง แต่ให้การเชื่อมต่อส่วนตัวผ่านการเชื่อมต่อทางกายภาพที่กำหนดไว้ ซึ่งต้องตั้งค่าโดยผู้ให้บริการการเชื่อมต่อ การเชื่อมต่อทางกายภาพกับคู่ค้า ExpressRoute สามารถทำได้หลายวิธี เรียนรู้เพิ่มเติมในคู่มือ ExpressRoute และตรวจสอบรายชื่อคู่ค้าในภูมิภาคของคุณ
การสมัครใช้งาน Azure จัดเตรียม กำหนดค่า และเรียกเก็บเงินวงจร ExpressRoute ในการสมัครใช้งานนี้
วางแผนการปรับใช้งาน
ในการวางแผน ต้องคำนึงถึงปัจจัยต่อไปนี้:
ภูมิศาสตร์: ทำความเข้าใจว่าต้องเชื่อมต่อที่ใดในพื้นที่ทางภูมิศาสตร์
ค่าใช้จ่าย: ผู้ให้บริการการเชื่อมต่อจะเรียกเก็บเงินสำหรับการสร้างการเชื่อมต่อส่วนตัว ค่าใช้จ่ายอาจสูงและแตกต่างกันไปตามชนิดและจำนวนการเชื่อมต่อที่คุณต้องการ
เวลาในการตั้งค่า: ในบางกรณี ฮาร์ดแวร์ทางกายภาพต้องได้รับการตั้งค่า รวมเวลาสำหรับความพยายามนี้ในการดำเนินการ จัดกำหนดการ
ทักษะและทรัพยากรการกำหนดค่า: ความซับซ้อนส่วนใหญ่อยู่ในการตั้งค่าการกำหนดเส้นทางภายในในเครือข่ายของคุณ ตรวจสอบให้แน่ใจว่ามีคนที่มีทักษะพร้อมที่จะทำงานนี้
วางแผนการกำหนดค่าการกำหนดเส้นทางสำหรับปริมาณการใช้งาน Power Platform ใน ExpressRoute
คุณหรือผู้ให้บริการการเชื่อมต่อกำหนดค่าการกำหนดเส้นทางปริมาณการใช้งาน Power Platform ผ่าน ExpressRoute ขึ้นอยู่กับชนิดการเชื่อมต่อ เมื่อคุณวางแผนสำหรับการกำหนดเส้นทางปริมาณการใช้งาน Power Platform ให้คำนึงถึงชนิดของปริมาณการใช้งานที่การเชื่อมต่อจะจัดการและการเชื่อมต่อเข้าและออก Power Platform ซึ่งขึ้นอยู่กับบริการและคุณลักษณะที่คุณใช้
แม้ว่าการเชื่อมต่อ ExpressRoute จะอยู่ระหว่างศูนย์ข้อมูล แต่การเชื่อมต่อเครือข่ายส่วนใหญ่มาจากอุปกรณ์ไคลเอนต์ของผู้ใช้ อุปกรณ์เหล่านี้มักจะกระจายไปทั่วเครือข่ายบริเวณกว้าง (WAN) เช่น สำนักงานสาขา การกำหนดเส้นทางการเชื่อมต่อจากอุปกรณ์ไคลเอ็นต์ผ่าน WAN ไปยังศูนย์ข้อมูล จากนั้นจึงข้ามวงจร ExpressRoute
การกำหนดค่านี้ต้องระมัดระวัง ตั้งค่า WAN เพื่อให้มีลักษณะอย่างใดอย่างหนึ่ง:
- เส้นทางผ่านซับเน็ตเครือข่ายได้รับการกำหนดค่าสำหรับ ExpressRoute หรือ
- วงจรเฟลโอเวอร์ถูกเลือกให้เหมาะสมกับการเชื่อมต่ออินเทอร์เน็ตสาธารณะกับ Power Platform
จึงเป็นสิ่งสำคัญที่จะระบุว่าเครือข่ายย่อยใดภายในเครือข่ายของคุณควรเป็นเป้าหมายสำหรับการเชื่อมต่อเซสชันหลักและสำรอง Border Gateway Protocol (BGP) ตรวจสอบให้แน่ใจว่าคำนำหน้า Power Platform ต้องการเส้นทางนั้น ไม่จำเป็นต้องกำหนดค่าบริการที่ปลายแต่ละด้านโดยเฉพาะ การกำหนดค่านั้นทำได้โดยการโฆษณาซับเน็ต IP หรือคำนำหน้าผ่านการเชื่อมต่อ เมื่อมีการเริ่มต้นคำขอ อัลกอริธึมการกำหนดเส้นทางจะเห็นว่าการเชื่อมต่อ BGP โดยตรงนั้นเป็นเส้นทางที่ต้องการสำหรับการรับส่งข้อมูลไปยังซับเน็ตที่เชื่อมต่อกับวงจร ExpressRoute และกำหนดเส้นทางการรับส่งข้อมูลนั้น
กำหนดค่า ExpressRoute สำหรับฐานผู้ใช้แบบกระจาย
ExpressRoute ได้รับการออกแบบมาเพื่อให้การเชื่อมต่อที่เป็นส่วนตัว เฉพาะ และคาดการณ์ได้จากสภาพแวดล้อมของคุณไปยังเครือข่าย Microsoft การเชื่อมต่อเฉพาะและโดยตรงผ่านผู้ให้บริการการเชื่อมต่อกับ Microsoft จะลดโอกาสในการต้องต่อสู้กับปริมาณการใช้งานอื่นๆ ในการเชื่อมต่อที่คุณใช้ร่วมกันผ่านเครือข่ายของผู้ให้บริการการเชื่อมต่อ ไม่จำเป็นต้องใช้ ExpressRoute เพื่อให้ได้คุณภาพการเชื่อมต่อนี้ แต่ช่วยให้มั่นใจได้
ในตัวอย่างต่อไปนี้ ผู้ใช้ในตำแหน่งสาขาเชื่อมต่อกับการเชื่อมต่อศูนย์ข้อมูลของบริษัทไปยัง ExpressRoute ผ่าน WAN
หากผู้ใช้ของคุณมีการกระจายอย่างมาก เช่น ที่สำนักงานสาขาที่ตั้งอยู่ทั่วประเทศ/ภูมิภาค การรับส่งข้อมูลเครือข่ายจะต้องเชื่อมต่ออย่างมีประสิทธิภาพจากสถานที่ที่แยกจากกันทางภูมิศาสตร์หลายแห่ง รูปแบบทั่วไปคือการกำหนดเส้นทางปริมาณการใช้งานผ่าน WAN ไปยังเครือข่ายท้องถิ่นที่เชื่อมต่อกับ ExpressRoute ดังที่แสดงในภาพต่อไปนี้
ExpressRoute ไม่สามารถแก้ปัญหาการเชื่อมต่อที่ไม่ดีอิ่มตัวหรือไม่มีประสิทธิภาพระหว่างอุปกรณ์ไคลเอนต์และ ExpressRoute พิจารณาใช้ ExpressRoute Direct ซึ่งช่วยให้คุณเชื่อมต่อโดยตรงกับเครือข่ายทั่วโลกของ Microsoft
เมื่อคุณเผชิญกับการเชื่อมต่อ WAN ที่ท้าทาย การสร้างการฝ่าวงล้อมอินเทอร์เน็ตในพื้นที่จากสำนักงานสาขาอาจเป็นประโยชน์ วิธีนี้จะช่วยหลีกเลี่ยงการเชื่อมต่อ WAN ที่ช้ากว่า และใช้การเข้าถึงของผู้ให้บริการการเชื่อมต่อเพื่อให้เกิดการเชื่อมต่อโดยตรงกับบริการคลาวด์
คุณสามารถตั้งค่าวงจร ExpressRoute จากหลายตำแหน่งและแม้กระทั่งออกไปยังที่ตั้งสาขาแต่ละสาขาผ่านเครือข่ายอินเทอร์เน็ตในพื้นที่ ดังแสดงในภาพต่อไปนี้
เพื่อลดปัญหาการเชื่อมต่อ WAN คุณสามารถตั้งค่าการเชื่อมต่อ ExpressRoute จากสำนักงานสาขาแต่ละแห่ง อย่างไรก็ตาม การตั้งค่าการเชื่อมต่อในหลายสถานที่นั้นมีราคาแพงและซับซ้อนในการบำรุงรักษา คุณมีทางเลือกที่เป็นประโยชน์มากขึ้น:
คุณสามารถเชื่อมต่อที่ตั้งสาขากับศูนย์ข้อมูลกลางผ่าน WAN และตั้งค่าการเชื่อมต่อ ExpressRoute จากศูนย์ข้อมูลส่วนกลาง
คุณสามารถเพิ่มประสิทธิภาพการเชื่อมต่อ WAN ได้โดยการเพิ่มแบนด์วิดท์หรือปรับปรุงการกำหนดเส้นทาง
คุณสามารถเชื่อมต่อสำนักงานสาขาทั้งหมดและศูนย์ข้อมูลทั้งหมดบนเครือข่ายส่วนตัวเสมือน (VPN) IP เดียวกัน และให้ผู้ให้บริการ IP VPN เชื่อมต่อกับ Microsoft ที่ตำแหน่งที่ตั้ง ExpressRoute
สำหรับเครือข่ายที่กระจายไปตามพื้นที่ทางภูมิศาสตร์ที่กว้าง การมีฮับหลายแห่งที่เชื่อมต่อกับ ExpressRoute สามารถลดจำนวนการเชื่อมต่อ ExpressRoute ที่จำเป็น ในขณะที่ยังคงเสนอจุดเชื่อมต่อในพื้นที่สำหรับผู้ใช้แต่ละราย ตรวจสอบให้แน่ใจว่ามีการเผยแพร่ IP สาธารณะที่ไม่ซ้ำกันผ่านวงจร ExpressRoute แต่ละวงจร แต่ละซับเน็ตต้องแตกต่างกัน ซึ่งต้องใช้ซับเน็ตที่มีการเผยแพร่สู่สาธารณะมากพอๆ กับการเชื่อมต่อ ExpressRoute
วิธีนี้จะเป็นประโยชน์หากพื้นที่ปฏิบัติงานที่แตกต่างกันตั้งอยู่ในพื้นที่ทางภูมิศาสตร์ที่แตกต่างกันอย่างมาก หรือหากการเชื่อมต่อเครือข่ายระหว่างพื้นที่มีจำกัด และสามารถสร้างการเชื่อมต่อโดยตรงกับ Microsoft สำหรับแต่ละพื้นที่ได้
ภูมิภาคต่างๆ อาจมีข้อกำหนดด้านความเป็นส่วนตัวที่แตกต่างกัน ไม่ใช่ทุกภูมิภาคที่จำเป็นต้องใช้ ExpressRoute เพราะมีภูมิภาคหนึ่งใช้ การเชื่อมต่อบางอย่างอาจกำหนดเส้นทางโดยตรงผ่านอินเทอร์เน็ตขณะที่การเชื่อมต่ออื่นๆ ใช้ ExpressRoute ดังที่แสดงในภาพต่อไปนี้
ExpressRoute (มาตรฐาน) ให้บริการการเชื่อมต่อในพื้นที่ทางภูมิศาสตร์ที่เฉพาะเจาะจง ต้องใช้ ExpressRoute Premium เพื่อให้การเข้าถึงแบบหลายภูมิภาคจากจุดเชื่อมต่อ ExpressRoute จุดเดียว สมมติว่าคุณมีสำนักงานในสหรัฐอเมริกาและสำนักงานในยุโรป ทั้งหมดนี้ใช้สภาพแวดล้อม Power Platform เดียว หากผู้เช่า Power Platform ของคุณถูกปรับใช้ในสหรัฐอเมริกา วงจร ExpressRoute ของคุณในยุโรปต้องเป็นเวอร์ชัน Premium ถ้าผู้เช่า Power Platform ของคุณอยู่ในยุโรป วงจรในสหรัฐอเมริกาของคุณต้องเป็น Premium
หลีกเลี่ยงการกำหนดเส้นทางไม่สมมาตร
ความท้าทายอย่างหนึ่งที่ต้องระวังคือการกำหนดเส้นทางแบบอสมมาตร ในการกำหนดเส้นทางไม่สมมาตร การกำหนดค่าการกำหนดเส้นทางเครือข่ายของคุณจะส่งปริมาณการใช้งานไปยังศูนย์ข้อมูล Microsoft โดยตรงผ่านอินเทอร์เน็ต แต่ปริมาณการใช้งานย้อนกลับจะถูกส่งผ่านวงจร ExpressRoute ความไม่ตรงกันนี้สามารถทริกเกอร์ไฟร์วอลล์ให้ปฏิเสธปริมาณการใช้งาน เนื่องจากจะได้รับแพ็กเก็ตการตอบสนองโดยไม่ต้องส่งแพ็กเก็ตคำขอที่สอดคล้องกัน
การกำหนดเส้นทางไม่สมมาตรอาจเกิดขึ้นได้หากเครือข่ายท้องถิ่นสำหรับไคลเอ็นต์กำหนดว่าการกำหนดเส้นทางที่มีประสิทธิภาพมากที่สุดไปยังบริการคลาวด์ของ Microsoft นั้นข้ามอินเทอร์เน็ตสาธารณะมากกว่าผ่าน WAN ไปยังวงจร ExpressRoute ส่วนตัว หากที่อยู่ IP ของไคลเอ็นต์เป็นที่อยู่ IP สาธารณะหรือแปลผ่านการแมป Network Address Translation (NAT) ไปยังที่อยู่ IP สาธารณะที่โฆษณาผ่าน ExpressRoute เส้นทางที่มีประสิทธิภาพมากที่สุดกลับไปยังที่อยู่นั้นน่าจะผ่านเซสชัน BGP ผ่าน ExpressRoute เพื่อหลีกเลี่ยงสถานการณ์นี้ ให้ใช้ NAT IP ที่แตกต่างกันบน Edge อินเทอร์เน็ต และ ExpressRoute Edge ของคุณ ด้วยที่อยู่ต้นทางที่แตกต่างกัน ปริมาณการใช้งานจะกลับมาที่ Edge เดิมอย่างชัดเจน
การกำหนดเส้นทางไม่สมมาตรสามารถเกิดขึ้นได้เมื่อมีวงจร ExpressRoute หลายวงจรกำหนดค่าไว้สำหรับลูกค้ารายเดียวกันด้วยการกำหนดเส้นทางปริมาณการใช้งานขาออกผ่านวงจรหนึ่ง แต่การกำหนดเส้นทางปริมาณการใช้งานกลับผ่านอีกวงจรหนึ่ง การตรวจสอบไฟร์วอลล์อาจบล็อกการรับส่งข้อมูลบนเส้นทางส่งคืน เพื่อหลีกเลี่ยงการกำหนดเส้นทางไม่สมมาตรในวงจร ExpressRoute ที่แตกต่างกันสำหรับเส้นทางขาออกและขาเข้า ตรวจสอบให้แน่ใจว่ามีการเผยแพร่ IP สาธารณะที่ไม่ซ้ำกันในแต่ละวงจร
การเชื่อมต่อภายนอกไปยัง/จาก Power Platform
เมื่อคุณเชื่อมต่อกับ Power Platform จากตำแหน่งของคุณ การเชื่อมต่ออาจเกี่ยวข้องกับการเพียร์สองชนิดคือ Microsoft และส่วนตัว วงจร ExpressRoute เดียวกันรองรับการเพียร์ทั้งสองแบบ ดังแสดงในภาพต่อไปนี้
มีการเชื่อมต่อชนิดต่างๆ ระหว่างบริการ Power Platform กับเครือข่ายภายนอก ตัวอย่างเช่น การเชื่อมต่อ Exchange Web Services โดยใช้การทำข้อมูลให้ตรงกันทางฝั่งเซิร์ฟเวอร์ ใช้ ExpressRoute เพื่อส่งผ่านการรับส่งข้อมูลเครือข่ายจากเครือข่าย Microsoft ไปยังเครือข่ายลูกค้า ไคลเอ็นต์ HTTPS ใช้การเชื่อมต่อ ExpressRoute สำหรับการเข้าถึงจากเครือข่ายของลูกค้าไปยังเครือข่าย Microsoft การเชื่อมต่อบริการเว็บใช้ ExpressRoute สำหรับการรับส่งข้อมูลทั้งขาเข้าและขาออกไปยังเครือข่าย Microsoft
การจราจรขาออก (การจราจรจากบริการ Power Platform)
ปริมาณการใช้งานขาออกหลายชนิดสามารถส่งผ่านได้โดยตรงจากบริการ Power Platform ไปยังส่วนบริการลูกค้า ส่วนบริการลูกค้าต้องสามารถระบุที่อยู่แบบสาธารณะได้ โดยมีที่อยู่ IP สาธารณะที่บริการ Power Platform สามารถแก้ไขได้ผ่าน DNS สาธารณะ ที่อยู่ IP ยังต้องโฆษณาไปยัง Microsoft ผ่าน ExpressRoute เพื่อให้การกำหนดเส้นทางเครือข่ายภายในที่อยู่ในบริการ Power Platform รู้เส้นทางปริมาณการใช้งานผ่านการเชื่อมต่อ ExpressRoute นั้น
บริการ Power Platform ไม่สามารถระบุอินสแตนซ์ของบริการหรือองค์กรลูกค้าที่ส่งคำขอไปยังที่อยู่ IP ได้ ดังนั้น จึงเป็นเรื่องสำคัญที่จะต้องจัดการกับคำขอที่ส่งเข้ามายังเครือข่ายองค์กรเสมือนว่ามาจากอินเทอร์เน็ต และรักษาความปลอดภัยให้เป็นเช่นนั้น
ตารางต่อไปนี้อธิบายการรับส่งข้อมูลขาออกจากบริการ Power Platform
รายละเอียด | ชนิดและทิศทางของการจราจร | ชนิดการเพียร์ | วัตถุประสงค์ |
---|---|---|---|
Web Service | HTTPS ขาออกจากบริการ Power Platform | การเพียร์ของ Microsoft เผยแพร่บริการเว็บบนที่อยู่ IP สาธารณะ ที่อยู่ในซับเน็ตที่กำหนดค่า ExpressRoute |
ปลั๊กอินที่กำหนดเองและกิจกรรมเวิร์กโฟลว์สามารถร้องขอบริการเว็บไปยังบริการภายนอกได้ |
การรวมการแลกเปลี่ยน: โหมดไฮบริด | HTTPS ขาออกจากบริการ Power Platform | การเพียร์ของ Microsoft เผยแพร่บริการเว็บบนที่อยู่ IP สาธารณะ ที่อยู่ในซับเน็ตที่กำหนดค่า ExpressRoute |
คำขอ Exchange Web Services จากการทำข้อมูลให้ตรงกันทางฝั่งเซิร์ฟเวอร์สำหรับการปรับใช้แบบไฮบริด (บริการ Power Platform Exchange ในสถานที่) |
ตัวเชื่อมต่อ | HTTPS ขาเข้าจากบริการ Power Platform | การเพียร์ของ Microsoft | คำขอจากบริการ Power Platform ผ่าน Azure API Management ผ่านตัวเชื่อมต่อโดยใช้เกตเวย์ข้อมูลในสถานที่ |
รีเลย์ Azure | HTTPS ขาออกจากบริการ Power Platform | การเพียร์ของ Microsoft เผยแพร่บริการเว็บบนที่อยู่ IP สาธารณะ ที่อยู่ในซับเน็ตที่กำหนดค่า ExpressRoute |
การเชื่อมต่อโดยตรงระหว่างโฟลว์ระบบคลาวด์ Power Automate และโฟลว์เดสก์ท็อป |
การจราจรขาเข้า (การจราจรไปยังบริการ Power Platform)
ตารางต่อไปนี้อธิบายปริมาณการใช้งานขาเข้าไปยังบริการ Power Platform จากเครือข่ายลูกค้า
Description | ชนิดและทิศทางของการจราจร | ชนิดการเพียร์ | วัตถุประสงค์ |
---|---|---|---|
การเชื่อมต่อไคลเอนต์ | HTTPS ขาเข้าไปยังบริการ Power Platform | การเพียร์ของ Microsoft การเชื่อมต่ออินเทอร์เน็ตโดยตรงสำหรับเนื้อหาคงที่ที่ให้บริการโดย Azure Content Delivery Network |
คำขอไคลเอนต์สำหรับ UI บริการ Power Platform |
Web Service | HTTPS ขาเข้าไปยังบริการ Power Platform | การเพียร์ของ Microsoft | คำขอไปยังบริการ Power Platform ผ่าน API บริการเว็บ (SOAP, API เว็บ) ไม่ว่าจะจากแอปพลิเคชันไคลเอ็นต์มาตรฐานหรือแบบกำหนดเอง |
ตัวเชื่อมต่อ | HTTPS ขาเข้าไปยังบริการ Power Platform | การเพียร์ของ Microsoft | ตอบกลับไปยังบริการ Power Platform ผ่าน API Management ผ่านตัวเชื่อมต่อโดยใช้เกตเวย์ข้อมูลในสถานที่ |
การเชื่อมต่อระบบคลาวด์ภายในในบริการ Power Platform
ตารางต่อไปนี้อธิบายวิธีการที่บริการ Power Platform ใช้และรวมเข้ากับบริการออนไลน์อื่นๆ ของ Microsoft ที่โฮสต์ใน Microsoft 365 และ Azure
Description | ชนิดและทิศทางของการจราจร | จุดประสงค์ |
---|---|---|
การรวม Exchange | HTTPS ขาออกไปยัง Microsoft 365 | คำขอบริการเว็บ Exchange ไปยัง Exchange Online จากการทำข้อมูลให้ตรงกันทางฝั่งเซิร์ฟเวอร์ |
การรวม SharePoint | HTTPS ขาออกไปยัง Microsoft 365 | คำขอบริการเว็บ SharePoint ไปยัง SharePoint Online จากบริการ Power Platform |
ธุรกิจการบริการ | HTTPS ขาออกไปยัง Azure Service Bus | พุชเหตุการณ์ไปที่ Azure Service Bus ไม่ว่าจะเป็นการลงทะเบียนเหตุการณ์มาตรฐานหรือจากปลั๊กอินที่กำหนดเอง และกิจกรรมเวิร์กโฟลว์ |
ข้อมูลซิงค์ | HTTPS ขาเข้าจาก Azure | คำขอการติดตามการเปลี่ยนแปลงขาเข้าสำหรับการซิงโครไนซ์บริการข้อมูล รวมถึงการค้นหา/ออฟไลน์/ข้อมูลเชิงลึกของลูกค้า |
การรับรองความถูกต้อง | HTTPS ขาออกไปยัง Microsoft Entra | การรับรองความถูกต้องส่วนใหญ่ดำเนินการผ่านการเปลี่ยนเส้นทางแบบพาสซีฟและโทเค็นการอ้างสิทธิ์ แต่ข้อมูลบางส่วนจะถูกซิงโครไนซ์กับ Microsoft Entra ID โดยตรง |
กระแสข้อมูล | HTTPS ขาออกไปยัง Azure Data Lake Storage | ให้ความสามารถในการวิเคราะห์และอนุญาตให้เข้าถึงโซลูชันข้อมูลขนาดใหญ่ ที่รวมข้อมูลจากบริการ Power Platform และแหล่งข้อมูลอื่นๆ นอกเหนือจากข้อมูลเชิงลึกที่ได้จากการวิเคราะห์ |
ตัวเชื่อมต่อ | HTTPS ขาออกไปยังบริการ Azure Platform as a Service (PaaS) | การเชื่อมต่อกับบริการ Azure PaaS ต่างๆ |
โฟลว์เดสก์ท็อป | HTTPS ขาออกไปยัง Azure Relay | การเชื่อมต่อโดยตรงระหว่างโฟลว์ระบบคลาวด์ Power Automate และโฟลว์เดสก์ท็อปที่สร้างใน Power Automate สำหรับเดสก์ท็อป |
Microsoft จัดการการเชื่อมต่อระหว่างบริการเหล่านี้ ซึ่งโฮสต์ใน Microsoft หรือการสมัครใช้งาน Azure ของลูกค้า ExpressRoute ไม่สามารถใช้ได้กับการเชื่อมต่อกับบริการเหล่านี้
ในกรณีที่มีการพุชเหตุการณ์บนบัสบริการ การเชื่อมต่อระหว่างบริการ Power Platform กับ Azure จะได้รับการจัดการเป็นการภายใน โดยแยกกัน ลูกค้าสามารถร้องขอไปยังบัสบริการเพื่อดึงข้อมูลที่สามารถจัดการได้ผ่านการเพียร์ของ Microsoft
การเชื่อมต่อคลาวด์สาธารณะและส่วนตัวของลูกค้า ไปยัง/จาก บริการ Power Platform
บริการ Power Platform ยังอนุญาตให้รวมโดยตรงกับทรัพยากร Azure แบบสาธารณะหรือส่วนตัว:
- จากแหล่งภายนอก โดยใช้ API บริการเว็บ Microsoft Dataverse
- ไปยังแหล่งภายนอก โดยใช้การร้องขอบริการเว็บที่ทำ
- ไปยังแหล่งภายนอก โดยใช้ตัวเชื่อมต่อ
ตารางต่อไปนี้อธิบายชนิดของปริมาณการใช้งานที่สามารถกำหนดเส้นทางผ่าน ExpressRoute เข้าและออกจากบริการ Power Platform
Description | ชนิดและทิศทางของการจราจร | ชนิดการเพียร์ | จุดประสงค์ |
---|---|---|---|
พอร์ทัล | HTTPS ขาเข้าไปยัง Azure | ภายในไปยังศูนย์ข้อมูล ยกเว้นเนื้อหาคงที่ ซึ่งใช้เครือข่ายการให้บริการเนื้อหา (CDN) ExpressRoute ไม่รองรับ CDN ดังนั้นเนื้อหาคงที่จึงเดินทางผ่านอินเทอร์เน็ตสาธารณะ | โฮสต์สาธารณะ-ผ่านบริการ หากพนักงานภายในสามารถเข้าถึงทรัพยากรเหล่านี้ได้ คุณอาจต้องการให้การจราจรเดินทางผ่าน ExpressRoute แทนที่จะเป็นอินเทอร์เน็ตสาธารณะ |
เส้นทางการเรียนรู้ | HTTPS ขาเข้าไปยัง Azure | ใช้ CDN ExpressRoute ไม่รองรับ CDN ดังนั้นเนื้อหาจึงเดินทางผ่านอินเทอร์เน็ตสาธารณะ | โฮสต์บนบริการสาธารณะ เนื่องจากไม่มีข้อมูลส่วนตัวของลูกค้า เพื่อวัตถุประสงค์ในการคาดการณ์ คุณอาจต้องการกำหนดเส้นทางปริมาณการใช้งานนี้ผ่าน ExpressRoute |
ธุรกิจการบริการ | HTTPS ขาเข้าไปยัง Azure Service Bus | ภายในศูนย์ข้อมูล | พูลเหตุการณ์จาก Azure Service Bus ที่มีอยู่ที่นั่นเป็นการลงทะเบียนเหตุการณ์มาตรฐานหรือจากปลั๊กอินที่กำหนดเอง หรือกิจกรรมเวิร์กโฟลว์อย่างใดอย่างหนึ่ง |
คำขอบริการเว็บ | ขาเข้าจาก Azure infrastructure as a service (IaaS) หรือ PaaS | ภายในศูนย์ข้อมูล | ลูกค้าสามารถโฮสต์แอปพลิเคชันแบบกำหนดเองใน Azure และสร้างคำขอของบริการเว็บ Power Platform |
คำขอบริการเว็บ | ขาออกไปยัง Azure IaaS/PaaS | ภายในศูนย์ข้อมูล | ลูกค้าสามารถใช้ปลั๊กอินที่กำหนดเองและกิจกรรมเวิร์กโฟลว์ที่ส่งคำขอบริการของโฮสต์ของ Azure |
กระแสข้อมูล | การเชื่อมต่อข้อมูลกับ Azure Data Lake Storage | ภายในศูนย์ข้อมูล | ให้ความสามารถในการวิเคราะห์และอนุญาตให้เข้าถึงโซลูชันข้อมูลขนาดใหญ่ ที่รวมข้อมูลจากบริการ Power Platform และแหล่งข้อมูลอื่นๆ นอกเหนือจากข้อมูลเชิงลึกที่ได้จากการวิเคราะห์ |
Azure Data Lake | การเชื่อมต่อข้อมูลกับ Azure Data Lake Storage | ภายในศูนย์ข้อมูล | ให้ความสามารถในการวิเคราะห์และอนุญาตให้เข้าถึงโซลูชันข้อมูลขนาดใหญ่ที่รวมข้อมูลจากบริการ Power Platform และแหล่งข้อมูลอื่นๆ และข้อมูลเชิงลึกที่ได้จากการวิเคราะห์ |
Azure SQL | การเชื่อมต่อข้อมูลกับบริการ Azure SQL | ภายในศูนย์ข้อมูล | ด้วยความสามารถ เช่น ส่งออกไปยังคลังข้อมูล การใช้อินสแตนซ์ Azure SQL เพื่อเก็บแบบจำลองของข้อมูล Microsoft Dataverse เพื่อการรายงานหรือการจำลองแบบจะเพิ่มขึ้น การปกป้องการเชื่อมต่อกับทรัพยากรเหล่านี้ผ่าน ExpressRoute อาจมีประโยชน์ |
บริการสาธารณะอื่นๆ อาจเชื่อมต่อภายในกับศูนย์ข้อมูล เนื่องจากมีการใช้ความสามารถเพิ่มเติมของ Azure