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

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

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

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

ประวัติและพัฒนาการของ SDN

SDN เป็นผลพวงจากความพยายามในการพัฒนาแนวคิดด้านเครือข่ายตั้งแต่ในช่วงทศวรรษที่ 1990 ซึ่งในช่วงเวลานั้น แนวคิดเกี่ยวกับ Active Networking เกิดขึ้นมา โดยตอบโจทย์ที่ว่าเครือข่ายจะสามารถทำให้ “กำหนด” หรือ “สามารถโปรแกรม” (programmable) ได้อย่างไร แนวคิดของ Active Networking คือการมองว่าเครือข่ายนั้นสามารถที่จะเหมือนเครื่องคอมพิวเตอร์ตามปกติได้ ซึ่งก็คือการที่ผู้ดูแลระบบ/นักพัฒนา สามารถเขียนโปรแกรมเพื่อเข้าเรียกใช้งานทรัพยากร (resources) ของเครือข่ายให้ได้เต็มที่ วิธีการสำคัญคือการทำให้เครือข่ายมี API (Application Programming Interface) ในฐานะช่องทางการเข้าถึง และการถอดรหัส (demultiplex) หัวแพ็กเก็ต เพื่อส่งไปให้ถูกที่ ซึ่งที่สุดทั้งสองอย่างนี้อยู่ภายใต้แนวคิดที่ว่าโครงสร้างทั้งหมดของอุปกรณ์ต่างๆ จะต้องถูกรวมกัน (unified)

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

ภายใต้กรอบคิดเช่นนี้ ชั้นทั้งสองที่แยกกันจะมีส่วนที่ประสานงานกันซึ่งเป็นส่วนที่เปิด และรวบรวมการควบคุมระบบเครือข่ายให้มาอยู่ในจุดเดียวกันทั้งหมด ซึ่งกลายมาเป็นแนวทางที่สำคัญสำหรับ SDN ซึ่งก็คือแนวคิดของการมี API เปิดซึ่งประสานงานเข้ากับ control plane และ data plane ในการจัดการ และการจัดการแบบกึ่งรวมศูนย์กึ่งกระจายตัว กล่าวคือ ในแง่หนึ่งเรารวมศูนย์เพื่อจัดการ แต่ในเวลาเดียวกันการรวมศูนย์นี้จะต้องป้องกันไม่ให้เกิดความล้มเหลวแบบจุดเดียว (single point failure) อันจะนำมาซึ่งการล่มของระบบนั่นเอง

แนวคิดทั้งสองมีผลทำให้เกิดโครงการที่เรียกว่า OpenFlow ซึ่งเป็น API มาตรฐานในการเรียกใช้งานที่ตอบสนองกับแนวคิดดังกล่าวข้างต้น โดยโครงการ OpenFlow ที่ภายหลังไปอยู่ภายใต้การดูแลของ Open Network Foundation กลายเป็นแกนสำคัญของระบบ SDN นั่นเอง

โครงสร้างของ SDN

SDN นั้นสร้างตัวเองอยู่บนฐานของแนวคิดที่ว่า ส่วนที่ควบคุม (control plane) และส่วนของข้อมูล (data plane) แยกออกจากกันอย่างชัดเจน โดยมีส่วนของการจัดการ (management) เป็นตัวเชื่อมโดยใช้ API ในการเชื่อมต่อทั้งสองส่วนนี้เข้าด้วยกัน

Control plane เป็นส่วนที่จะทำหน้าที่ในการตัดสินใจว่า แพ็กเก็ตที่วิ่งอยู่ภายในระบบหรือเข้าถึงระบบแล้ว จะต้องจัดการส่งต่อหรือทำอย่างไรก็ต่อไป ส่วน Data plane คือส่วนที่จะอนุญาต หรือทำหน้าที่ในการส่งข้อมูลไปตามการตัดสินใจของ control plane นั่นเอง เพื่อให้เห็นภาพชัดเจนขึ้น เราลองมาดูภาพด้านล่างที่เป็น OSI Model เทียบกับแนวคิดดังกล่าว

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

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

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

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

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

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

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

(ภาพจาก Open Network Foundation)

ผลที่ได้จากการใช้งาน SDN

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

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

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

• ผู้ดูแลระบบสามารถจัดการเครือข่ายให้มีประสิทธิภาพ เนื่องจากตัว control plane สามารถที่จะกำหนดค่าในการใช้งานต่างๆ ได้ผ่านทางซอฟต์แวร์ที่ควบคุมจากศูนย์กลาง (จึงได้ชื่อว่าเป็น software-defined network) สวิตซ์แต่ละชุดจะสามารถควบคุมผ่าน API สำหรับการควบคุม

แนวโน้มและบทสรุปของ SDN

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

ผมได้มีโอกาสลองเล่น SDN บน Windows Server 2012 R2 (ลองทำตามนี้ได้) โดยคร่าว เพื่อที่จะเข้าใจแนวคิดของ SDN และก็พบว่าหากมีการนำเอามาใช้งานจริงแล้ว SDN จะทำให้ระบบเครือข่ายขยายตัวได้ง่าย เพราะการเพิ่มเครื่องเข้าระบบ (ในกรณีที่เป็น virtual machine) และการตั้งค่าเพื่อกำหนดเส้นทาง ใช้เวลาไม่นานนัก และไม่ได้ยากจนเกินไป

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

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

อ้างอิง

• บทความ "Software-Defined Networking: The New Norm for Networks" จาก Open Networking Foundation
• บทความ "The Road to SDN: An Intellectual History of Programmable Networks" เขียนโดย Nick Feamster, Jennifer Rexford และ Ellen Zegura (เข้าถึงได้จากที่นี่)
• บทความ "Introduction to Software Defined Networking (SDN)" จาก Datatrend Technologies Inc.
• บทความ "Software Defined Networking" จาก TechCentral.ie
• บทความ "Software Defined Networking (SDN) for the non-technical CXO" จาก CXO Unplugged

แหล่งข้อมูลแนะนำเพิ่มเติม

• SDN Central