เครือข่ายที่กำหนดโดยซอฟต์แวร์ (SDN): ประวัติ สถาปัตยกรรม และการใช้งาน

อินฟอร์เมเทค ดิจิตอล » Recursos » เครือข่ายที่กำหนดโดยซอฟต์แวร์ (SDN): ประวัติ สถาปัตยกรรม และการใช้งาน

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

แนวทางใหม่นี้ไม่ได้เกิดขึ้นมาโดยไม่มีที่มาที่ไป: มันเป็นผลมาจากการวิจัยหลายทศวรรษและพัฒนาการทางเทคโนโลยีหลายอย่างตั้งแต่เครือข่ายแบบแอคทีฟในช่วงทศวรรษ 90 ไปจนถึงการกำหนดมาตรฐาน OpenFlow และการสร้างระบบนิเวศที่สมบูรณ์แบบของคอนโทรลเลอร์ API และแอปพลิเคชันต่างๆ มาดูกันทีละขั้นตอนว่าเรามาถึงจุดนี้ได้อย่างไร ปัญหาอะไรที่ SDN แก้ไขได้ มันทำงานอย่างไรภายใน และในสถานการณ์จริงที่มันถูกนำไปใช้ในปัจจุบันมีอะไรบ้าง

ที่มาและประวัติของเครือข่ายที่กำหนดโดยซอฟต์แวร์ (SDN)

เรื่องราวของ SDN เริ่มต้นเมื่อประมาณ20 ปีที่แล้ว ในช่วงเริ่มต้นของอินเทอร์เน็ตเชิงพาณิชย์เมื่อความสำเร็จของเครือข่ายทั่วโลกทำให้เห็นได้ชัดว่าโครงสร้างพื้นฐานด้านการสื่อสารจำเป็นต้องสามารถปรับเปลี่ยนและพัฒนาได้ง่ายขึ้นมาก จากนั้นเป็นต้นมา สามารถแบ่งออกได้เป็นสามขั้นตอนหลักที่ปูทางไปสู่สิ่งที่เราเรียกว่า SDN ในปัจจุบัน

ขั้นตอนแรกสอดคล้องกับเครือข่ายแอคทีฟ (ประมาณปี 1995-2000)แนวคิดคือการเปิดเครือข่ายให้สามารถเขียนโปรแกรมได้ คล้ายกับการเขียนโปรแกรมพีซี แต่ใช้กับแต่ละโหนดการสื่อสาร เพื่อให้บรรลุเป้าหมายนี้ จึงมีการกำหนด API ในอุปกรณ์เครือข่ายที่เปิดเผยทรัพยากรต่างๆ เช่น พลังการประมวลผล พื้นที่จัดเก็บ คิวแพ็กเก็ต และฟังก์ชันการประมวลผล ทำให้สามารถโหลดโค้ดที่ใช้พฤติกรรมแบบกำหนดเองกับกระแสการรับส่งข้อมูลเฉพาะได้

แนวทางนี้ขัดแย้งกับมุมมองของผู้ที่โต้แย้งว่าหนทางเดียวที่อินเทอร์เน็ตจะขยายตัวและใช้งานได้อย่างต่อเนื่องคือการทำให้เครือข่ายเรียบง่ายที่สุดเท่าที่จะเป็นไปได้ ถึงกระนั้น โครงการสร้างเครือข่ายเชิงรุกก็กระตุ้นให้เกิดความก้าวหน้าสำคัญหลายประการ ได้แก่ การลดต้นทุนการคำนวณ การปรับปรุงภาษาโปรแกรม การเกิดขึ้นของเครื่องเสมือนและเหนือสิ่งอื่นใด คือแนวคิดที่ว่าเครือข่ายสามารถถูกมองว่าเป็นแพลตฟอร์มที่ตั้งโปรแกรมได้ ไม่ใช่เพียงแค่กลุ่มของกล่องปิด

ตัวเร่งปฏิกิริยาที่สำคัญในยุคนั้นคือการสนับสนุนจากหน่วยงานต่างๆ เช่น DARPA ซึ่งได้ริเริ่มโครงการ Active Networks Programซึ่งดำเนินการตั้งแต่กลางทศวรรษ 90 ถึงต้นทศวรรษ 2000 แม้ว่าเครือข่ายแอคทีฟจะไม่ได้รับการใช้งานอย่างแพร่หลาย แต่ก็ได้วางรากฐานแนวคิดที่ต่อมากลายเป็นพื้นฐานของ SDN ได้แก่ ฟังก์ชันที่ตั้งโปรแกรมได้ในเครือข่าย การจำลองทรัพยากรเสมือน และมุมมองที่เป็นหนึ่งเดียวของอุปกรณ์ต่างๆ (ไฟร์วอลล์, IDS, NAT เป็นต้น)

เมื่อเข้าสู่ทศวรรษใหม่และปริมาณการรับส่งข้อมูลเพิ่มขึ้นอย่างรวดเร็ว ระยะที่สองจึงเริ่มต้นขึ้น โดยเน้นที่การแยกส่วนควบคุม (control plane) และส่วนประมวลผลข้อมูล (data plane) (ปี 2001-2007)เราเตอร์และสวิตช์แบบดั้งเดิมรวมตรรกะการควบคุม (การเลือกเส้นทาง โปรโตคอลการกำหนดเส้นทาง) และส่วนประมวลผลข้อมูล (การส่งต่อแพ็กเก็ตจริง) ไว้ในอุปกรณ์เดียวกัน ทำให้ยากมากที่จะแก้ไขข้อผิดพลาด ปรับแต่งการจัดการการจราจร หรือแนะนำบริการใหม่ๆ

เพื่อรับมือกับสถานการณ์นี้ ผู้ให้บริการเครือข่ายจึงเริ่มนำการส่งต่อแพ็กเก็ตไปใช้บนฮาร์ดแวร์เฉพาะทางในขณะที่การควบคุมยังคงแยกออกจากกัน และในขณะเดียวกันพวกเขาก็พยายามหาวิธีจัดการเครือข่ายที่มีขนาดใหญ่และซับซ้อนมากขึ้นเรื่อยๆ ด้วยบริการต่างๆ เช่น VPNและคุณสมบัติขั้นสูงอื่นๆ จากนี้จึงเกิดนวัตกรรมขึ้นสองแนวทาง: ในด้านหนึ่งคืออินเทอร์เฟซแบบเปิดระหว่างการควบคุมและการส่งต่อ เช่น ForCES (IETF) หรือ Netlink บน Linux ในอีกด้านหนึ่งคือสถาปัตยกรรมที่มีการควบคุมเชิงตรรกะแบบรวมศูนย์ เช่น RCP, SoftRouter หรือโปรโตคอล PCE ซึ่งช่วยให้สามารถตัดสินใจเกี่ยวกับการกำหนดเส้นทางได้จากมุมมองโดยรวม

ขั้นตอนที่สามมาถึงพร้อมกับProject 4D และ Ethane ที่ตามมาซึ่งได้รวบรวมแนวคิดของตัวควบคุมตรรกะส่วนกลางที่มีระนาบที่กำหนดไว้อย่างชัดเจนสี่ระนาบ ได้แก่ ข้อมูล (การประมวลผลแพ็กเก็ตตามกฎ) การค้นหา (การรวบรวมข้อมูลทางภูมิศาสตร์และข้อมูลการรับส่งข้อมูล) การเผยแพร่ (การติดตั้งกฎการประมวลผล) และการตัดสินใจ (นโยบายโดยรวมที่แปลงเป็นกฎเฉพาะ) Ethane ซึ่งใช้งานในสภาพแวดล้อมจริง เช่น มหาวิทยาลัยสแตนฟอร์ด ได้นำเสนอการออกแบบสวิตช์ที่เรียบง่ายอย่างยิ่ง ซึ่งจะกลายเป็นพื้นฐานของสิ่งที่เราเรียกว่าOpenFlowใน ปัจจุบัน

ในขณะเดียวกัน ระบบนิเวศของการทดลองก็ก้าวหน้าไปเช่นกัน โครงสร้างพื้นฐานอย่าง PlanetLab และ Emulab โครงการต่างๆ เช่น GENI และโครงการ FIRE ของยุโรป และโครงการ Clean Slate ของมหาวิทยาลัยสแตนฟอร์ดส่งเสริมการทดสอบสถาปัตยกรรมเครือข่ายทางเลือกในวงกว้าง และในสภาพแวดล้อมนี้เองที่ OpenFlow ถือกำเนิดขึ้นในฐานะวิธีการที่ใช้งานได้จริงในการเปิดเผยความสามารถในการส่งต่อข้อมูลของสวิตช์ไปยังคอนโทรลเลอร์ภายนอกโดยใช้ API มาตรฐาน

ความก้าวหน้าครั้งสำคัญในอุตสาหกรรมคือ การสาธิตของ Avaya ในปี 2014ซึ่งรวม Shortest Path Bridging เข้ากับ OpenStack เพื่อสร้างเครือข่ายที่กำหนดโดยซอฟต์แวร์โดยใช้การกำหนดค่าด้วยตนเองน้อยที่สุด และค่อยๆ เกิดขึ้น ด้วยการอัปเดตเฟิร์มแวร์ที่ง่าย สวิตช์เชิงพาณิชย์จำนวนมากเริ่มรองรับ OpenFlow โดยไม่ต้องเปลี่ยนแปลงฮาร์ดแวร์

ปัญหาของเครือข่ายแบบดั้งเดิมที่ SDN สามารถแก้ไขได้

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

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

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

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

จากมุมมองทางเศรษฐกิจ องค์กรต่างๆ ประสบปัญหาจากการพึ่งพาผลิตภัณฑ์ของผู้ผลิต อย่างมาก หากต้องการฟังก์ชันการทำงานเครือข่ายใหม่ การอัปเดตซอฟต์แวร์เพียงอย่างเดียวมักไม่เพียงพอ องค์กรต้องรอให้ผู้จำหน่ายออกรุ่นที่เหมาะสม รอให้การรับรองภายในเสร็จสมบูรณ์ รอให้จัดหาอุปกรณ์ และรอให้มีการติดตั้งใช้งาน ซึ่งกระบวนการเหล่านี้อาจใช้เวลานานหลายปีและขัดขวางนวัตกรรม

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

นอกจากนี้ การเติบโตของบริการคลาวด์ (SaaS, IaaS, PaaS)ยังต้องการการจัดสรรทรัพยากรอย่างรวดเร็ว การปรับขนาดแบบไดนามิกของการประมวลผล การจัดเก็บข้อมูล และเครือข่าย รวมถึงข้อกำหนดด้านความปลอดภัยที่ซับซ้อนยิ่งขึ้น การเพิ่มขึ้นของบิ๊กดาต้าต้องการแบนด์วิดท์และกำลังการขนส่งมหาศาลระหว่างเซิร์ฟเวอร์หลายพันเครื่อง ซึ่งเครือข่ายแบบดั้งเดิมไม่สามารถรองรับได้เสมอไป

SDN คืออะไรกันแน่ และมันช่วยแก้ปัญหาได้อย่างไร?

SDN (Software-Defined Networking) คือสถาปัตยกรรมใหม่ที่ออกแบบมาเพื่อมอบความยืดหยุ่น การควบคุมจากส่วนกลาง และความสามารถในการตั้งโปรแกรมให้กับเครือข่าย โดยย้ายความซับซ้อนไปอยู่ที่ซอฟต์แวร์และลดความซับซ้อนจากฮาร์ดแวร์ ไม่ใช่เรื่องของการจัดการอุปกรณ์แต่ละตัวแยกกันอีกต่อไป แต่เป็นการกำหนดพฤติกรรมของเครือข่ายที่ต้องการจากเลเยอร์เชิงตรรกะที่สูงกว่า

หลักการสำคัญคือการแยกส่วนควบคุม (Control Plane) และส่วนส่งข้อมูล (Data Plane) ออกจากกันส่วนส่งข้อมูลมีหน้าที่ในการส่งแพ็กเก็ตด้วยความเร็วสูงระหว่างปลายทางต่างๆ ส่วนควบคุมจะตัดสินใจว่าแพ็กเก็ตเหล่านั้นควรเดินทางไปอย่างไรและที่ใด โดยใช้หลักการ นโยบาย เส้นทาง และกฎต่างๆ ใน ​​SDN ส่วนต่างๆ เหล่านี้จะแยกออกจากกัน และการควบคุมจะรวมศูนย์อยู่ที่ตัวควบคุมเชิงตรรกะหนึ่งตัวหรือมากกว่านั้น

มีการสร้างอินเทอร์เฟซที่กำหนดไว้อย่างชัดเจนระหว่างทั้งสอง โดยปกติจะใช้โปรโตคอลมาตรฐาน เช่น OpenFlowด้วยอินเทอร์เฟซนี้ ตัวควบคุมสามารถติดตั้ง แก้ไข หรือลบกฎการส่งต่อบนสวิตช์และเราเตอร์ ซึ่งจะทำให้พวกมันทำงานเหมือนอุปกรณ์ที่ตั้งโปรแกรมได้ แทนที่จะเป็นระบบปิด OpenFlow ไม่ใช่โปรโตคอลเดียวที่เป็นไปได้ แต่เป็นโปรโตคอลที่แพร่หลายที่สุดและกลายเป็นมาตรฐานโดยพฤตินัย

เหนือตัวควบคุม (Controllers) แอปพลิเคชัน SDN ใช้ API แบบ northbound เพื่อระบุพฤติกรรมที่ต้องการจากเครือข่ายเช่น การจัดลำดับความสำคัญของทราฟฟิกบางประเภท การแบ่งส่วนแผนก การกระจายโหลด การปรับปรุงคุณภาพการบริการ การตอบสนองต่อการโจมตีแบบปฏิเสธการให้บริการ เป็นต้น ตัวควบคุมจะแปลงคำขอระดับสูงเหล่านี้ให้เป็นกฎการส่งต่อที่เป็นรูปธรรมซึ่งนำไปใช้ในระนาบข้อมูล (Data Plane)

กล่าวอีกนัยหนึ่ง SDN เปลี่ยนเครือข่ายให้เป็นแพลตฟอร์มที่สามารถพัฒนาแอปพลิเคชันและบริการได้ราวกับว่าเป็นซอฟต์แวร์ล้วนๆโดยไม่คำนึงถึงรายละเอียดของแต่ละรุ่นอุปกรณ์หรือโปรโตคอลระดับต่ำ การสร้างนามธรรมนี้ช่วยให้เกิดระบบอัตโนมัติ ลดข้อผิดพลาด และปรับตัวให้เข้ากับการเปลี่ยนแปลงของความต้องการได้เร็วขึ้นมาก

สถาปัตยกรรม SDN: ตัวควบคุม, API และส่วนประกอบสำคัญ

โดยทั่วไปแล้ว เครือข่าย SDN จะมีโครงสร้างเป็นชั้นตรรกะหลายชั้นและส่วนประกอบที่แตกต่างกันอย่างชัดเจน หัวใจสำคัญของเครือข่ายคือตัวควบคุม SDNซึ่งทำหน้าที่เป็นสมองของเครือข่าย รวบรวมข้อมูลจากส่วนประมวลผลข้อมูลและดำเนินการตัดสินใจของแอปพลิเคชัน

ตัวควบคุมจะรักษาภาพรวมเชิงนามธรรมของเครือข่ายไว้ เช่น โครงสร้างเครือข่าย ความสามารถของแต่ละอุปกรณ์ สถิติการรับส่งข้อมูล สถานะการเชื่อมต่อ ฯลฯ ด้วยข้อมูลเหล่านี้ และอาศัยโมดูลเสริมที่สามารถเปิดหรือปิดใช้งานได้ (การจัดการสินค้าคงคลัง การรวบรวมสถิติ โมดูลรักษาความปลอดภัย การปรับสมดุลโหลด ฯลฯ) ตัวควบคุมจะทำการตัดสินใจและสื่อสารไปยังอุปกรณ์ต่างๆ ผ่าน API ฝั่งใต้ ซึ่งโดยทั่วไปคือ OpenFlow หรือโปรโตคอลอื่นๆ เช่น OVSDB หรือ Cisco OpFlex

อุปกรณ์ในระนาบข้อมูล—สวิตช์ทางกายภาพ สวิตช์เสมือน เราเตอร์—ทำหน้าที่สร้างสิ่งที่ ONF เรียกว่าSDN Datapath : ชุดของกลไกการส่งต่อและฟังก์ชันการประมวลผลทราฟฟิกที่เปิดเผยในเชิงตรรกะ ภายในแต่ละ Datapath จะมี Control Interface Processing Agent (CDPI agent) ที่รับคำสั่งจากคอนโทรลเลอร์และแปลงคำสั่งเหล่านั้นเป็นกฎในตารางการไหลหรือการกระทำของฮาร์ดแวร์เฉพาะ

ส่วนบนสุดของสถาปัตยกรรมคือแอปพลิเคชัน SDN แอปพลิเคชันเหล่านี้สื่อสารกับคอนโทรลเลอร์ผ่าน API ฝั่งเหนือ (NBIs) และแสดงความต้องการทางธุรกิจหรือทางเทคนิค เช่น การจัดการที่อยู่ IP (IPAM), การจัดระเบียบการบริการ, การควบคุมคุณภาพการบริการ (QoS), ระบบป้องกันการโจมตี DoS, เครื่องมือวิเคราะห์ขั้นสูง เป็นต้น แอปพลิเคชันแต่ละตัวมีตรรกะของตัวเองและ NBIs อย่างน้อยหนึ่งตัวเพื่อโต้ตอบกับคอนโทรลเลอร์

ระหว่างบล็อกเหล่านี้คือ ส่วนต่อประสานระหว่างการควบคุมและข้อมูล (Control-to-Data Plane Interface หรือ CDPI)ซึ่งมีหน้าที่ในการให้ความสามารถในการตั้งโปรแกรมเกี่ยวกับการส่งต่อข้อมูล การโฆษณาความสามารถของอุปกรณ์ การแสดงสถิติ และการแจ้งเตือนเหตุการณ์ต่างๆ ตัวควบคุมจะสร้างไดรเวอร์สำหรับส่วนต่อประสานนี้ และอุปกรณ์จะสร้างเอเจนต์ ดังนั้นไดรเวอร์/เอเจนต์แต่ละคู่จึงสร้างความสัมพันธ์เฉพาะระหว่างโครงสร้างพื้นฐานทางกายภาพและแอปพลิเคชัน

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

ส่วนต่อประสานทางเหนือและทางใต้ และแบบจำลองการเขียนโปรแกรมการไหล

API ฝั่งใต้เชื่อมต่อคอนโทรลเลอร์กับฮาร์ดแวร์หรือเส้นทางข้อมูล OpenFlow เป็นอินเทอร์เฟซแรกที่ได้รับการยอมรับอย่างกว้างขวาง โดยกำหนดวิธีการที่คอนโทรลเลอร์ติดตั้งรายการในตารางโฟลว์ของสวิตช์ วิธีการรวบรวมสถิติ วิธีการรายงานเหตุการณ์ต่างๆ เช่น แพ็กเก็ตที่ไม่ตรงกัน และอื่นๆ ทางเลือกอื่นๆ เช่น Cisco OpFlex นำเสนอโมเดลที่แตกต่างกัน แต่มีแนวคิดพื้นฐานเดียวกันคือการอนุญาตให้องค์ประกอบส่วนกลางมีอิทธิพลต่อพฤติกรรมของอุปกรณ์

API ฝั่งเหนือ (Northbound API) ช่วยให้แอปพลิเคชันสามารถสื่อสารกับตัวควบคุมและรับมุมมองเชิงนามธรรมของเครือข่ายได้ ที่นี่ไม่มีมาตรฐานที่เป็นที่ยอมรับเหมือน OpenFlow: มีข้อเสนอและไลบรารีมากมายที่อยู่ในเลเยอร์ต่างๆ ของสแต็ก (REST, gRPC, SDK เฉพาะ, โมเดลตามเจตนา ฯลฯ) และด้วยความหลากหลายนี้เองที่ ONF ให้ความสำคัญอย่างมากกับการกำหนดแนวทางปฏิบัติที่ดีที่สุดและหาแนวทางที่เข้ากันได้

ในระดับการปฏิบัติงาน ตัวควบคุมสามารถใช้ โมเดล เชิงรุก เชิงรับ หรือแบบผสมผสานเพื่อบังคับใช้กฎการไหลของข้อมูลบนอุปกรณ์ต่างๆ ในแนวทางเชิงรับ สวิตช์จะสอบถามตัวควบคุมเมื่อได้รับแพ็กเก็ตที่ไม่ตรงกับรายการใดๆ ในตาราง ตัวควบคุมจะตอบกลับด้วยคำสั่ง และหากจำเป็น จะสร้างกฎใหม่สำหรับแพ็กเก็ตที่คล้ายกันในอนาคต

ในโมเดลเชิงรุก ตัวควบคุมจะติดตั้งกฎสำหรับการไหลของข้อมูลที่คาดการณ์ไว้ล่วงหน้า คล้ายกับวิธีการเติมข้อมูลลงในตารางการกำหนดเส้นทางแบบดั้งเดิม ซึ่งจะช่วยลดการสอบถามแบบเรียลไทม์และลดความหน่วงของการสื่อสารเริ่มต้น การใช้งานจริงจำนวนมากผสมผสานทั้งสองโมเดลเข้าด้วยกัน โดยตอบสนองต่อปริมาณการรับส่งข้อมูลที่ไม่สามารถคาดเดาได้ และเชิงรุกสำหรับการไหลของข้อมูลที่รู้จักกันดี

จุดแข็งที่แท้จริงของ SDN อยู่ที่ความสามารถในการเขียนโปรแกรมผ่าน API แบบเปิดเหล่านี้ ด้วย API เหล่านี้ทำให้สามารถปรับเส้นทางแบบไดนามิกตามปริมาณงาน จัดลำดับความสำคัญของทราฟฟิกที่สำคัญ ตอบสนองต่อความล้มเหลวหรือเหตุการณ์ด้านความปลอดภัยโดยอัตโนมัติ และแม้กระทั่งอนุญาตให้แอปพลิเคชันเจรจาเงื่อนไขที่ต้องการกับเครือข่ายได้เอง (แบนด์วิดท์ ความหน่วงสูงสุด ระดับความซ้ำซ้อน ฯลฯ)

กรณีศึกษาการประยุกต์ใช้ความสามารถในการเขียนโปรแกรมใน SDN

เพื่ออธิบายแนวคิดเรื่องการเขียนโปรแกรมเครือข่าย มักมีการกล่าวถึงกรณีการใช้งานหลักสามกรณีเพื่อแสดงให้เห็นว่าSDN ถูกนำไปใช้ในทางปฏิบัติอย่างไรกรณีแรกคือการปรับแต่งการไหลของทราฟฟิก: ด้วยโปรโตคอลอย่าง OpenFlow ตัวควบคุมสามารถตัดสินใจได้เกือบจะในทันทีว่าทราฟฟิกประเภทใดควรใช้เส้นทางใด เพื่อปรับสมดุลโหลดระหว่างลิงก์ หลีกเลี่ยงความแออัด หรือใช้มาตรการรักษาความปลอดภัยที่เข้มงวดมากขึ้นเมื่อจำเป็น

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

องค์ประกอบสำคัญประการที่สามคือการทำงานอัตโนมัติของเครือข่ายในสถานการณ์ SDN ที่ออกแบบมาอย่างดี เครือข่ายสามารถตอบสนองต่อเหตุการณ์ต่างๆ ได้อย่างอิสระ เช่น หากลิงก์ล้มเหลว เส้นทางจะถูกคำนวณใหม่ หากพบรูปแบบการรับส่งข้อมูลที่น่าสงสัย ระบบจะใช้กฎการบล็อกหรือเปลี่ยนเส้นทางไปยังระบบวิเคราะห์ หากมีการเปิดตัวแอปพลิเคชันใหม่ เครือข่ายจะจัดสรรทรัพยากรโดยอัตโนมัติ บทบาทของผู้ดูแลระบบจะเปลี่ยนจากการ "เปลี่ยนคำสั่ง" เพียงอย่างเดียว ไปเป็นการกำหนดนโยบายระดับสูงและตรวจสอบให้แน่ใจว่ามีการปฏิบัติตาม

ข้อดีของ SDN สำหรับองค์กร

ข้อดีของ SDN นั้นชัดเจนและเป็นประโยชน์อย่างมากสำหรับบริษัทและผู้ให้บริการหนึ่งในข้อดีที่โดดเด่นที่สุดคือการจัดการแบบรวมศูนย์: จากตัวควบคุม สามารถกำหนดนโยบายการเข้าถึง กฎความปลอดภัย ลำดับความสำคัญของการรับส่งข้อมูล และการจัดสรรบริการสำหรับเครือข่ายทั้งหมดได้ โดยไม่ต้องจัดการอุปกรณ์แต่ละตัวแยกกัน หรือพึ่งพาอินเทอร์เฟซเฉพาะของผู้ผลิตแต่ละราย

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

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

จากมุมมองทางเศรษฐกิจ SDN ช่วยลดทั้งค่าใช้จ่ายในการลงทุน (CAPEX) และค่าใช้จ่ายในการดำเนินงาน (OPEX) ในด้านหนึ่งช่วยให้สามารถนำฮาร์ดแวร์ที่มีอยู่แล้วมาใช้ซ้ำได้เนื่องจากสวิตช์หลายตัวสามารถเปิดใช้งานฟังก์ชัน SDN ได้ด้วยการอัปเดตเฟิร์มแวร์อย่างง่าย ในอีกด้านหนึ่ง ระบบอัตโนมัติช่วยลดเวลาที่พนักงานใช้ไปกับงานกำหนดค่าซ้ำๆ ลดข้อผิดพลาดจากมนุษย์ และทำให้การบำรุงรักษาและการอัปเกรดง่ายขึ้น

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

ข้อเสียและความท้าทายของเครือข่าย SDN

SDN ไม่ใช่ยาวิเศษและยังมีข้อท้าทายที่ต้องคำนึงถึงเมื่อออกแบบและใช้งานเครือข่ายประเภทนี้ หนึ่งในข้อท้าทายที่ถูกกล่าวถึงบ่อยที่สุดคือความเปราะบางของตัวควบคุม: เนื่องจากมีการรวมเอาตรรกะและการตัดสินใจจำนวนมากไว้ที่นั่น จึงกลายเป็นจุดวิกฤตที่หากเกิดความล้มเหลวหรือการถูกบุกรุกอาจทำให้ระบบทั้งหมดล่มได้

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

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

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

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

บทบาทของ ONF และผู้มีส่วนเกี่ยวข้องอื่นๆ ในระบบนิเวศ SDN

มูลนิธิOpen Networking Foundation (ONF)มีบทบาทสำคัญอย่างยิ่งต่อวิวัฒนาการของ SDN (Software-Defined Networking) เป็นองค์กรที่ขับเคลื่อนโดยผู้ใช้งานปลายทาง (ผู้ให้บริการเครือข่าย บริษัทขนาดใหญ่) โดยมีเป้าหมายเพื่อส่งเสริมการนำเครือข่ายที่กำหนดโดยซอฟต์แวร์มาใช้ผ่านมาตรฐานแบบเปิดและกระบวนการความร่วมมือ

ONF มีหน้าที่รับผิดชอบในการกำหนด บำรุงรักษา และพัฒนามาตรฐาน OpenFlowซึ่งเป็นมาตรฐาน SDN ที่ได้รับการยอมรับเป็นครั้งแรก และยังคงเป็นองค์ประกอบหลักในสถาปัตยกรรมหลายๆ อย่าง แต่การทำงานของ ONF นั้นครอบคลุมมากกว่านั้น: ONF เป็นผู้นำกลุ่มทำงานที่วิเคราะห์ข้อกำหนดสำหรับการใช้งานเชิงพาณิชย์ เสนออินเทอร์เฟซ โมเดลข้อมูล และคำศัพท์ใหม่ๆ และส่งเสริมระบบนิเวศแบบหลายผู้จำหน่าย

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

แนวทางแบบผสมผสานนี้สะท้อนให้เห็นถึงความเป็นจริงในทางปฏิบัติ กล่าวคือ ไม่จำเป็นต้องควบคุมทุกอย่างจากตัวควบคุมส่วนกลาง และเป็นเรื่องสะดวกที่กลไกการตอบสนองอย่างรวดเร็วบางอย่างจะยังคงอยู่ใกล้กับการจราจร ในขณะที่ระบบอัจฉริยะและการประสานงานที่ซับซ้อนกว่านั้นจะได้รับการจัดการในลักษณะรวมศูนย์และตั้งโปรแกรมได้

SDN, การจำลองเสมือนเครือข่าย และกรณีการใช้งานในโลกแห่งความเป็นจริง

ในหลายองค์กร มีการนำ SDN มาใช้ร่วมกับเทคนิคการจำลองเสมือนเครือข่ายเพื่อสร้างเครือข่ายแบบโอเวอร์เลย์บนโครงสร้างพื้นฐานทางกายภาพที่มีอยู่เดิม เครือข่ายเสมือนเหล่านี้สามารถแบ่งส่วนสภาพแวดล้อมต่างๆ (การผลิต การพัฒนา ลูกค้าที่แตกต่างกัน) โดยใช้ฮาร์ดแวร์พื้นฐานเดียวกัน หรือสามารถเชื่อมต่อเครือข่ายทางกายภาพหลายเครือข่ายเข้าด้วยกันราวกับว่าเป็นหน่วยตรรกะเดียว

แนวทางนี้มีประสิทธิภาพเป็นพิเศษเมื่อผสานรวมกับบริการคลาวด์คอมพิวติ้ง เช่น SaaS, IaaS และ PaaSเครือข่ายที่กำหนดโดยซอฟต์แวร์จะประสานงานกับแพลตฟอร์มการจัดการเพื่อให้วงจรการจัดสรรทั้งหมด—เครื่องเสมือน พื้นที่จัดเก็บ เครือข่าย และความปลอดภัย—ดำเนินการได้อย่างสม่ำเสมอ รวดเร็ว และอัตโนมัติ โดยส่วนใหญ่มักทำผ่าน API

ในองค์กรขนาดใหญ่และผู้ให้บริการเครือข่าย SDN ถูกนำมาใช้เพื่อสร้างเครือข่าย WAN ขององค์กรที่ชาญฉลาดขึ้นโดยมีการจัดการปริมาณการรับส่งข้อมูลระหว่างสำนักงานใหญ่ ศูนย์ข้อมูล และคลาวด์สาธารณะอย่างละเอียด ตัวอย่างเช่น Google ใช้ SDN มาหลายปีแล้วเพื่อเชื่อมต่อศูนย์ข้อมูลทั่วโลก และได้ร่วมมือกับ ONF ในการกำหนดอินเทอร์เฟซควบคุมใหม่ๆ นอกเหนือจาก OpenFlow

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

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

ด้วยพื้นฐานทางประวัติศาสตร์ เทคนิค และประสบการณ์เชิงปฏิบัติทั้งหมดนี้ SDN กำลังสร้างความแข็งแกร่งให้กับตัวเองในฐานะวิธีการทำความเข้าใจเครือข่ายที่แตกต่างออกไป: ใกล้ชิดกับโลกของซอฟต์แวร์มากขึ้น มุ่งเน้นไปที่ระบบอัตโนมัติและการเขียนโปรแกรม และสามารถตอบสนองต่อความท้าทายของการเติบโตของปริมาณการรับส่งข้อมูล คลาวด์ บิ๊กดาต้า และ IoT โดยไม่ต้องบังคับให้มีการเพิ่มจำนวนฮาร์ดแวร์หรือความซับซ้อนในการดำเนินงานอย่างไม่มีที่สิ้นสุด