จะเลือกเส้นทางไหนไปสู่ WAN ที่พร้อมสำหรับระบบคลาวด์?

Which Way to the Cloud-Ready WAN?

การย้ายไปยังบริการบนคลาวด์กำลังดำเนินไปด้วยดี โดย Gartner คาดการณ์ว่า ภายในปี 2016 มูลค่าของซอพท์แวร์ที่อยู่ในรูปของการบริการ (Software as a Service-SaaS) หรือการปรับใช้บนคลาวด์จะมีถึง 50% ของมูลค่าของการปรับใช้ซอพท์แวร์ Customer Relationship Management-CRM) ทั้งหมด อย่างไรก็ตามเครือข่าย WAN ขององค์กรส่วนใหญ่ยังคงถูกสร้างขึ้นเพื่อใช้งานสำหรับโลกก่อนคลาวด์ (pre-cloud world) โดยเน้นไปที่การส่งข้อมูลระหว่างสาขา สำนักงานใหญ่ และศูนย์ข้อมูลอย่างมีประสิทธิภาพเป็นหลัd โดยพื้นฐานแล้วเครือข่าย WAN ขององค์กร “ในอดีต” ได้รับการปรับให้เหมาะสมสำหรับการถ่ายโอนข้อมูลระหว่างสถานที่ตั้งทางกายภาพที่เป็นเจ้าของหรือเช่าโดยองค์กร

แต่อย่างที่เราทุกคนทราบ โลกได้เปลี่ยนไปแล้ว ดังนั้นเราควรสอบถามว่าสถาปัตยกรรม WAN ควรเปลี่ยนแปลงไปพร้อมกับโลกอย่างไร เราได้เห็นว่ามีการแลกเปลี่ยน การประนีประนอมกันระหว่างฟังก์ชันการรวมศูนย์และฟังก์ชั่นการกระจายเกิดขึ้น

ตามแนวทางและศูนย์กลางการรับส่งข้อมูลปลายทางสู่อินเทอร์เน็ตทั้งหมด (all internet-destined traffic) จะถูกส่งกลับเข้ามาผ่านไฟร์วอลล์ที่ติดตั้งที่ศูนย์กลาง ซึ่งวิธีการ “ดุมล้อ – Hub and spoke” (การขนส่งที่ทุกอย่างจะถูกส่งกลับมาที่ศูนย์กลางแล้วค่อยส่งกระจายออกไป) นี้ออกแบบมาอย่างตรงไปตรงมาเพื่อให้เกิดความปลอดภัย แต่อย่างหลีกเลี่ยงไม่ได้คือการส่งข้อมูลกลับมาที่ศูนย์กลางนั้นทำให้เกิดสมรรถนะที่ต่ำกว่าความเหมาะสมในสภาพแวดล้อมที่บริการคลาวด์มีความสำคัญ (ในรูปโปรดสังเกตว่าสาขาในลอสแองเจลิสเข้าถึงบริการในซีแอตเทิลผ่านศูนย์ข้อมูลที่อยู่ในนิวยอร์ก)

Figure 1: Centralized “Hub and Spoke” Design Results in “Tromboning” of Traffic Accessing SaaS Services 

ในหลายๆ องค์กร ในปัจจุบันแอปพลิเคชั่นบนคลาวด์สร้างทราฟฟิกส่วนใหญ่โดยได้แรงหนุนจากการปรับใช้อย่างต่อเนื่องของซอฟต์แวร์และโครงสร้างพื้นฐานในฐานะบริการ (SaaS และ IaaS) ในการตอบสนองผู้ประกอบการมีแรงจูงใจที่จะพิจารณาใช้สถาปัตยกรรมแบบกระจายหรือแบบตรงไปยัง (อินเตอร์) เน็ตอย่างเต็มรูปแบบ a fully distributed or direct-to-net architecture)

ด้านซ้ายของไดอะแกรมต่อไปนี้แสดงให้เห็นถึงแนวทางแบบ direct-to-net และความซับซ้อนที่เกี่ยวข้อง: การเข้าสู่อินเทอร์เน็ตโดยตรงหมายถึงการติดตั้งไฟร์วอลล์ที่ทุกสาขา ดังนั้นเราต้องเลือกวิถีที่จะใช้ระหว่าง “การรวมศูนย์อย่างเต็มที่” (แบ็คฮอล) หรือ “การกระจายอย่างเต็มที่” (ตรงสู่เน็ต)?

ปรากฎว่าคุณไม่ได้ทำเช่นนั้น ตามที่ Andrew Lerner จาก Gartner ชี้ให้เห็น “ถ้าคุณใช้สถาปัตยกรรม WAN แบบเดิม แอประบบคลาวด์จะได้รับผลกระทบ หากคุณเลือกไปทางอินเทอร์เน็ตสถาปัตยกรรม VPN ทั้งหมด แอปขององค์กรจะประสบปัญหา” ดังนั้นในการตอบสนององค์กรจำนวนมากจึงหันไปใช้แนวทางศูนย์ระดับภูมิภาค (a regional hub approach) (แสดงอยู่ทางด้านขวาของแผนภาพด้านบน)

อย่างไรก็ตาม เนื่องจากเครือข่ายอาศัยการกำหนดเส้นทาง IP routing อย่างเดียวเท่านั้น ฮับอาจกำหนดเส้นทางการรับส่งข้อมูลตามอำเภอใจไปยังบริการใดบริการหนึ่ง (ในกรณีของเรา SaaS-1 และ SaaS-2) โดยไม่คำนึงถึงความหน่วงเวลาที่อาจเกิดขึ้น แม้จะมีความไม่มีประสิทธิภาพที่อาจเกิดขึ้นเหล่านี้ แต่แนวทางศูนย์ระดับภูมิภาคมักสร้างสมดุลที่ดีและแก้ปัญหามากมายในการสร้าง WAN ที่เป็นแบบคลาวด์ที่พร้อมใช้งาน

นอกจากนี้ โซลูชั่นการรักษาความปลอดภัยในฐานะบริการ (เช่น Zscaler ซึ่งเป็นพันธมิตรของ Silver Peak) สามารถให้ประโยชน์ที่คล้ายคลึงกันกับสถาปัตยกรรมศูนย์ระดับภูมิภาค เนื่องจากเกตเวย์เสมือนที่ปลอดภัยสามารถแยกการรับส่งข้อมูลทางธุรกิจระดับภูมิภาค/สาขาออกจากการรับส่งข้อมูลทางอินเทอร์เน็ตโดยเปลี่ยนเส้นทางการรับส่งข้อมูลแต่ละประเภทตามประเภทของข้อมูลนั้นๆ

ข้อดีอีกประการของการใช้ฮับ (ศูนย์) ระดับภูมิภาคที่จะทำให้มองเห็นได้ชัดขึ้นเมื่อคุณพิจารณาที่จะใช้บริการเว็บอื่นๆ เช่น บริการอีเมลชื่อ “กลับบ้านจากที่ทำงาน” หรือโซเชียลมีเดีย (อธิบายโดย “บริการบนเว็บ” ด้านบน) สำหรับบริการเช่นนี้ คุณไม่สนใจเกี่ยวกับการเพิ่มประสิทธิภาพการรับส่งข้อมูล และแน่นอนว่าคุณไม่ต้องการบันทึกการเข้าถึงทั้งหมด

สุดท้าย สถาปัตยกรรม SD-WAN ทำให้เราเข้าใกล้ระบบคลาวด์ที่พร้อมใช้ได้มากขึ้นโดยนำ WAN ขององค์กรที่มีอยู่แล้ว (ซึ่งอาจใช้ MPLS) และเพิ่มประสิทธิภาพด้วยลิงก์บรอดแบนด์ (หลายลิ้งก์) ที่มีอยู่ ตัวอย่างเช่น สถาปัตยกรรม Unity SD-WAN ของ Silver Peak ปรับปรุงแนวทางฮับระดับภูมิภาคโดยกำหนดฮับขาออกที่เหมาะสมที่สุดสำหรับส่วนประกอบบริการคลาวด์แต่ละรายการ และโดยการกำหนดเส้นทางที่ดีที่สุดจากแต่ละสาขาไปยังแต่ละฮับบริการ

ที่มาพร้อมกับความตั้งใจทางธุรกิจที่ซ้อนทับอยู่ Silver Peak ยังนำความสามารถของการเตรียมการใช้งานที่เกือบไม่ต้องลงมือลงแรง (Zero Touch Provisioning) การควบคุมเส้นทางที่มีพลวัตรไม่ตายตัว (Dynamic Path Control) และการลดการหน่วงเวลาแบบไดนามิกและการลดข้อมูลเพื่อให้ลูกค้ามีความยืดหยุ่นในการเข้าถึงบริการคลาวด์ได้อย่างมีประสิทธิภาพเช่นเดียวกับแอปพลิเคชั่นภายในองค์กร ชุดคุณสมบัติ SD-WAN ที่เหมาะสม ซึ่งอาจรวมกับสถาปัตยกรรมฮับระดับภูมิภาค จะนำไปสู่ ​​WAN บนระบบคลาวด์ที่พร้อมใช้งาน

Recommended Posts