เจาะลึก Load Balancing: ที่คนเรียกกันว่า F5 พร้อมเคสจริงจากหน้างาน

คนทำ Ops และงานความปลอดภัยแทบไม่มีใครหนีพ้นคำหนึ่ง—Load Balancing พอพูดถึง Load Balancing อุปกรณ์แรกที่หลายคนนึกออกก็คือ “F5” ที่น่าสนใจคือ F5 แท้จริงเป็นชื่อบริษัท (F5 Networks) แต่เพราะผลิตภัณฑ์ดังเกินไป มันค่อย ๆ กลายเป็นคำเรียกแทนตัวโหลดบาลานเซอร์ไปโดยปริยาย เหมือนกับที่ “ค้นด้วย Baidu” กลายเป็นคำเรียกแทนการค้นหาไปเอง

บทความนี้จะเจาะให้ขาด: F5 มันคืออะไรกันแน่ เลเยอร์ 4 กับเลเยอร์ 7 ต่างกันตรงไหน และสถานการณ์จริงคอนฟิกยังไง

หนึ่ง: Load Balancing แก้ปัญหาอะไรกันแน่

Load Balancing โดยแก่นแท้คือการแบ่งงานออกไปประมวลผลบนหน่วยปฏิบัติการหลายตัว—เช่น Web เซิร์ฟเวอร์, FTP เซิร์ฟเวอร์ หรือเซิร์ฟเวอร์แอปพลิเคชันสำคัญขององค์กร ให้ทุกตัวช่วยกันทำงานจนเสร็จ

มองจากมุมเทคนิค มันเผยตัวออกภายนอกเป็นที่อยู่เซิร์ฟเวอร์เสมือน (Virtual Server) เมื่อผู้ใช้เข้ามาเชื่อมต่อ มันจะใช้การแปลงที่อยู่เครือข่ายสองทาง (NAT) ส่งต่อการเชื่อมต่อไปยังเซิร์ฟเวอร์จริงที่เหมาะสมที่สุด ผู้ใช้เห็นจุดเข้าเดิมเสมอ แต่เบื้องหลังคือกองเครื่องที่ช่วยกันแบก

มันต้องแก้สามเรื่อง:กลัวล่ม (จุดล้มเหลวจุดเดียว) กลัวแบกไม่ไหว (คอขวดด้านประสิทธิภาพ) กลัวขยายไม่ได้ (ขยายแนวนอนไม่ได้)

สอง: เลเยอร์ 4 vs เลเยอร์ 7 จุดที่งงง่ายที่สุด

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

โหลดบาลานซ์เลเยอร์ 4 (Transport Layer)

• ชั้นที่ทำงาน: ชั้นที่ 4 ของ OSI โปรโตคอล TCP/UDP
• เกณฑ์การส่งต่อ: IP ต้นทาง, IP ปลายทาง, หมายเลขพอร์ต—ไม่แตะข้อมูลแอปพลิเคชัน
• ความสามารถหลัก: การส่งต่อพอร์ต การใช้ซ้ำการเชื่อมต่อ TCP การตรวจสุขภาพระดับเลเยอร์ 4 (TCP Handshake) และการป้องกัน DDoS ระดับพื้นฐาน
• ประสิทธิภาพ: ส่งต่อได้ประสิทธิภาพสูงมาก ใกล้ขีดจำกัดของฮาร์ดแวร์ ความหน่วงระดับไมโครวินาที
• สถานการณ์ทั่วไป: ฐานข้อมูล (MySQL/Redis) บริการ TCP (เกมเซิร์ฟเวอร์ บริการ Netty) และการกระจายโหลดลิงก์ข้ามศูนย์ข้อมูล
• ผลิตภัณฑ์ตัวแทน: LVS, F5 (โหมดเลเยอร์ 4), HAProxy (โหมดเลเยอร์ 4), Nginx (โมดูล stream)

โหลดบาลานซ์เลเยอร์ 7 (Application Layer)

• ชั้นที่ทำงาน: ชั้นที่ 7 ของ OSI โปรโตคอลแอปพลิเคชันอย่าง HTTP/HTTPS, DNS, FTP
• เกณฑ์การส่งต่อ: URL, Cookie, HTTP Header, พารามิเตอร์คำขอ, เนื้อหา JSON
• ความสามารถหลัก: การเราต์ตามเนื้อหา SSL Offload แคช การจำกัดอัตราและตัดวงจร การผสาน WAF Session Persistence และการเปิดตัวแบบ Canary
• ประสิทธิภาพ: ฟีเจอร์จัดเต็ม แต่ต้องแยกวิเคราะห์โปรโตคอลแอปพลิเคชัน ความหน่วงสูงขึ้นเล็กน้อย (ระดับมิลลิวินาที) ใช้การขยายคลัสเตอร์มาชดเชย
• สถานการณ์ทั่วไป: เว็บแอปพลิเคชัน API ไมโครเซอร์วิส บริการ HTTPS การเปิดตัวแบบ Canary และ API Gateway
• ผลิตภัณฑ์ตัวแทน: Nginx, HAProxy (โหมดเลเยอร์ 7), F5 (โมดูลเลเยอร์ 7), Kong, Spring Cloud Gateway

วิธีจำแบบประโยคเดียว: เลเยอร์ 4 เห็น “ป้ายทะเบียน” (IP กับพอร์ต) ก็ส่งต่อเลย ส่วนเลเยอร์ 7 ต้อง “แกะกล่อง” (ดูเนื้อหา) ก่อนแล้วค่อยตัดสินใจว่าจะส่งไปไหน ต้องการประสิทธิภาพเลือกเลเยอร์ 4 ต้องการฟีเจอร์เลือกเลเยอร์ 7

สาม: F5 BIG-IP เก่งตรงไหนกันแน่

ผลิตภัณฑ์หลักของ F5 คือ BIG-IP LTM ชื่อทางการเรียกว่าLocal Traffic Manager (ตัวจัดการทราฟฟิกภายใน) ทำโหลดบาลานซ์ได้ตั้งแต่เลเยอร์ 4 ถึง 7 มันไม่ใช่แค่เครื่องส่งต่อ รายการฟีเจอร์ยาวพอสมควร: Application Switching, Session Switching, การมอนิเตอร์สถานะ, Smart NAT, Universal Persistence, การจัดการข้อผิดพลาดของการตอบสนอง, IPv6 Gateway, การเราต์ขั้นสูง, การเร่ง SSL, การบีบอัด HTTP อัจฉริยะ, การปรับแต่ง TCP, Content Buffering, การเข้ารหัส Cookie, การกรองการโจมตีแอปพลิเคชัน, การป้องกัน DoS และ SYN Flood, การกรองแพ็กเก็ตแบบไฟร์วอลล์ ฯลฯ

เลือกหยิบอันที่ใช้ได้จริงที่สุดมาพูด:

1. โหลดบาลานซ์และความซ้ำซ้อนหลายลิงก์

ธุรกิจสำคัญมักต้องต่อสาย ISP หลายเจ้า เพื่อรักษาคุณภาพและกำจัดจุดล้มเหลวจุดเดียว ตรงนี้แบ่งเป็นสองทิศทาง:

• ทราฟฟิก OUTBOUND (ภายในออกภายนอก): BIG-IP LC กระจายทราฟฟิกไปยังอินเทอร์เฟซ Internet ที่ต่างกันอย่างชาญฉลาด พร้อมทำ Source NAT
• ทราฟฟิก INBOUND (ภายนอกเข้าภายใน): ผูกที่อยู่สาธารณะของสอง ISP ตอบ DNS ของทั้งสองเจ้า โดยตอบกลับอย่างชาญฉลาดตามสุขภาพเซิร์ฟเวอร์และเวลา RTT

2. โหลดบาลานซ์ฝั่งเซิร์ฟเวอร์

ให้บริการภายนอกผ่าน VIP (Virtual IP ประกอบจากที่อยู่ IP และพอร์ต TCP/UDP) และตรวจสุขภาพเซิร์ฟเวอร์เป้าหมายตั้งแต่ L4 ถึง L7 อย่างต่อเนื่อง เมื่อพบเซิร์ฟเวอร์มีปัญหาจะดึงออกจากกลุ่มโหลดบาลานซ์ทันที ยังใช้ร่วมกับ iRules เปิดแพ็กเก็ต TCP/UDP เพื่อจัดการตามกฎจากลักษณะเนื้อหา—เช่น เปลี่ยนเส้นทางทราฟฟิกตาม URL ไปยังเซิร์ฟเวอร์ต่างกัน

3. ความพร้อมใช้งานสูงของระบบ

นี่คือจุดที่ F5 อวดได้เต็มปาก ในโหมดความซ้ำซ้อนแบบเครื่องคู่สลับด้วยความหน่วงระดับมิลลิวินาที (เร็วสุดภายใน 200ms) อวดกันว่าความพร้อมใช้งาน 99.999% หลักการคือ: ทุกเซสชันที่ผ่านเครื่อง Active จะถูกซิงก์ข้อมูลเซสชันไปยังเครื่อง Backup ผ่านสายข้อมูลซิงก์—เพราะฉะนั้นตอนสลับ ผู้ใช้ไม่สะดุด ชิป watchdog ในเครื่องมอนิเตอร์สัญญาณอีกฝั่งผ่านสายหัวใจ ถ้า Active ล่มจะแจ้ง Backup ให้เข้ารับ Shared IP และ VIP ทันที

4. ความปลอดภัย

BIG-IP ใช้หลักการออกแบบแบบไฟร์วอลล์ คือปฏิเสธโดยค่าเริ่มต้น (Default Deny) ตัดการเชื่อมต่อที่ว่างอยู่เพื่อป้องกัน DoS ทำ Source Route Tracking เพื่อป้องกันการปลอม IP และปฏิเสธ SYN ที่ไม่มี ACK เพื่อป้องกันการโจมตีแบบ SYN ฟีเจอร์ Dynamic Reaping ของมันลบการเชื่อมต่อว่างในสถานการณ์ DoS ได้อย่างมีประสิทธิภาพ และจะเร่งอัตราการตัดการเชื่อมต่อตามปริมาณการโจมตีที่เพิ่มขึ้น—จุดนี้เฉียบมาก ส่วนเทคนิค Delay Binding ให้การป้องกัน SYN Flood แบบครอบคลุมแก่เซิร์ฟเวอร์เบื้องหลัง

5. การเร่ง SSL

BIG-IP ทุกเครื่องมีชิปเร่ง SSL แบบฮาร์ดแวร์ แถมมาพร้อม License 100 TPS ไม่ต้องจ่ายแยก ถ้าภายหลังต้องขยาย อัปเกรด License ก็พอ

สี่: F5 หรือ Nginx? เทียบกันเพื่อเลือก

นี่คือคำถามที่ถูกถามบ่อยที่สุดในหน้างานจริง ทั้งสองไม่ใช่คู่แข่งกัน มากกว่าเป็นการเติมเต็มกัน

F5 BIG-IP (ฮาร์ดแวร์)

• รูปแบบการดีพลอย: อุปกรณ์ฮาร์ดแวร์เฉพาะทาง (มีชิปออกแบบเฉพาะ)
• ประสิทธิภาพ: การเชื่อมต่อ TCP ระดับล้าน ความหน่วงการส่งต่อระดับไมโครวินาที
• ฟีเจอร์: จัดเต็มทุกด้าน—เลเยอร์ 4+7, SSL Offload, ป้องกัน DDoS, WAF, VPN, โหลดลิงก์
• ความน่าเชื่อถือ: ความซ้ำซ้อนแบบฮาร์ดแวร์ (Hot Standby เครื่องคู่) ความพร้อมใช้งาน 99.999%
• ต้นทุน: แพงมาก (หลักแสนถึงหลักล้าน) ต้องใช้วิศวกรเฉพาะทางดูแล
• ความยืดหยุ่น: พึ่งการอัปเกรดฮาร์ดแวร์ ความยืดหยุ่นต่ำ
• การดูแลระบบ: ซับซ้อน ต้องคุ้นเคยกับหน้าจอคอนฟิกเฉพาะและ CLI

Nginx (ซอฟต์แวร์)

• รูปแบบการดีพลอย: ซอฟต์แวร์ รันบนเซิร์ฟเวอร์ทั่วไปหรือเครื่องคลาวด์
• ประสิทธิภาพ: การเชื่อมต่อ TCP ระดับแสน ความหน่วงระดับมิลลิวินาที ขยายแบบคลัสเตอร์ได้
• ฟีเจอร์: เบาและมีประสิทธิภาพ—เลเยอร์ 7 เป็นแกน รองรับเลเยอร์ 4, SSL Offload, แคช, จำกัดอัตรา, Reverse Proxy
• ความน่าเชื่อถือ: ต้องตั้งค่า Hot Standby เครื่องคู่ด้วยมือ (Keepalived) พึ่งความเสถียรของฮาร์ดแวร์เซิร์ฟเวอร์
• ต้นทุน: โอเพนซอร์สฟรี Nginx Plus ก็ค่าบริการค่อนข้างต่ำ
• ความยืดหยุ่น: รองรับดีพลอยแบบคลัสเตอร์ ในสภาพแวดล้อมคลาวด์ขยายแบบยืดหยุ่นได้
• การดูแลระบบ: ง่าย ไฟล์คอนฟิกอ่านง่าย วิศวกรแบ็กเอนด์เริ่มใช้ได้เร็ว

ทางแยกการเลือก เดินตามนี้ได้เลย:

• บริการ TCP คอนเคอเรนซีสูง (เกม หุ้น) + ความพร้อมใช้งานสูงสุด → F5 เลเยอร์ 4
• จุดเข้าธุรกิจหลัก + ความต้องการด้านความปลอดภัย (WAF/DDoS) → F5 เลเยอร์ 7
• API Gateway ไมโครเซอร์วิส + ดีพลอยบนคลาวด์ → Nginx เลเยอร์ 7
• โหลดฐานข้อมูล/Redis + คุ้มค่า → Nginx เลเยอร์ 4
• ธุรกิจขนาดเล็ก-กลาง + ปรับปรุงเร็ว → Nginx (เลเยอร์ 4/เลเยอร์ 7)
• ศูนย์ข้อมูลระดับองค์กร + หลายลิงก์ → F5 ทำจุดเข้า Nginx ทำโหลดบริการภายใน

คอมโบสุดท้ายนี้ในหน้างานจริงของบริษัทใหญ่พบบ่อยมาก—F5 เฝ้าประตูหน้าบ้าน Nginx จัดการด้านใน

ห้า: เคสจากหน้างาน: คอนฟิก F5 มันยุ่งแค่ไหน

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

สถานการณ์: เว็บเซิร์ฟเวอร์สองตัวให้บริการภายนอก IP เป็น 192.168.192.10-20/24 ต้องการทำโหลดบาลานซ์ผ่านที่อยู่ภายนอก 192.168.27.100 พอร์ต 80

โหลดบาลานซ์แบบง่ายที่สุดต้องใช้แค่สามพารามิเตอร์ ความสัมพันธ์เกาะกันเป็นชั้น ๆ:

• Node (โหนด): นิยามพื้นฐานที่สุด เซิร์ฟเวอร์หนึ่งตัวคือหนึ่ง Node
• Pool (กลุ่มทรัพยากร): กลุ่ม Node ที่รับและประมวลผลทราฟฟิก เช่น คลัสเตอร์เว็บเซิร์ฟเวอร์
• Virtual Server (เซิร์ฟเวอร์เสมือน): จุดเข้าภายนอก เชื่อมกับ Pool

ทิศทางการไหลของข้อมูล: คำขอของลูกค้า → Virtual Server → Pool → Node

ขั้นตอนปฏิบัติ (หน้าจอจัดการ BIG-IP):

• ขั้นที่หนึ่ง: เปิดใช้งานอุปกรณ์ ได้ F5 มาเปิดใช้งานก่อน ตัวช่วยง่าย ๆ แต่จำไว้ว่าต้องต่ออินเทอร์เน็ต และควรทำให้เสร็จก่อนขึ้นแร็ก—นี่คือบทเรียนจากคนเคยโดนกับดัก
• ขั้นที่สอง: ล็อกอิน เปิดเบราว์เซอร์ไปที่ https://IP ผู้ดูแล ชื่อผู้ใช้และรหัสผ่านเริ่มต้นคือ admin ทั้งคู่
• ขั้นที่สาม: สร้าง VLAN Network → VLANs สร้าง VLAN แล้วเพิ่มอินเทอร์เฟซเข้าไป (เลือกแบบ Untagged)
• ขั้นที่สี่: ตั้งค่า IP Networks → Self IPs กำหนดที่อยู่ให้แต่ละ VLAN
• ขั้นที่ห้า: ตั้งค่าเราต์ Networks → Routes ตั้งเกตเวย์เริ่มต้นหรือสแตติกเราต์
• ขั้นที่หก: ตั้งค่า Pool Local Traffic → Virtual Servers → Pools ตั้งชื่อ การตรวจสุขภาพ (เช่น TCP) อัลกอริทึมโหลดบาลานซ์ (เช่น observed-member แบบเฝ้าสังเกต) และ IP กับพอร์ตของเซิร์ฟเวอร์จริง
• ขั้นที่เจ็ด: ตั้งค่า Virtual Server Local Traffic → Virtual Servers เชื่อมกับ Pool ข้างบน เลือกวิธีหมุนเวียน (นิยม RoundRobin)
• ขั้นที่แปด: ตั้งค่า Monitor Local Traffic → Monitors ตรวจสถานะสุขภาพเซิร์ฟเวอร์และเชื่อมกับ Pool
• ขั้นที่เก้า: ตั้งค่า Redundant เพื่อทำความซ้ำซ้อนแบบเครื่องคู่

หก: พารามิเตอร์สำคัญของ Virtual Server

แกนของ F5 คือ Virtual Server พารามิเตอร์สักสองสามตัวถ้าไม่ใส่ใจจะมีปัญหา

VS Type (ชนิด) พบบ่อยสามแบบ:

• Performance L4: ส่งต่อเลเยอร์ 4 ล้วน TMM ทำหน้าที่แค่จัดสรรการเชื่อมต่อ ไม่แก้พารามิเตอร์ TCP การเชื่อมต่อไคลเอนต์กับเซิร์ฟเวอร์เป็น 1:1 อัตราการส่งต่อเร็ว ใช้กันมากในองค์กร เพื่อลดผลกระทบต่อแอปพลิเคชันถ้าเลือกได้ให้เลือกแบบนี้ก่อน
• Standard VS: การเชื่อมต่อ TCP ระหว่างไคลเอนต์กับเซิร์ฟเวอร์เป็นอิสระจากกันสมบูรณ์ ใช้เมื่อต้องการฟีเจอร์เลเยอร์ 7 (Cookie Persistence, Session ID Persistence, Header Persistence, การแยก Long Connection ตามธุรกรรม, การป้องกัน SYN Attack) ระวังคุณสมบัติหนึ่ง:พอร์ตของมันเปิดสู่ภายนอกตลอดไป—แม้ Node เบื้องหลังจะล่มหมด พอร์ต 80 ของ VIP ก็ยัง telnet ผ่านอยู่ แค่หน้าเว็บเปิดไม่ได้ ตอนใช้ตัวนี้ไล่ปัญหาต้องจำไว้
• Forwarding IP: ใช้สำหรับการเชื่อมต่อระหว่างเครือข่ายภายในกับภายนอก ไม่มี Pool Member การส่งต่อขึ้นกับเราต์ในเครื่อง โดยค่าเริ่มต้น F5 ไม่มีฟังก์ชันเราต์ ต้องสร้าง VS ที่เป็น 0 ทั้งหมดเพื่อเปิดฟังก์ชันเราต์

ต้องจัด Timeout ให้ตรงกัน (อันนี้กับดักจริง) ถ้า VS ตั้งค่า TCP Profile ไว้ การเชื่อมต่อ UDP จะไม่ถูกรับ ที่ต้องใส่ใจกว่านั้นคือค่า Idle Timeout ใน tcp—ต้องสอดคล้องกับเซิร์ฟเวอร์ ถ้า F5 ตั้ง 150 วินาที แต่เซิร์ฟเวอร์ IIS เป็น 300 วินาที จะเกิดเออเรอร์เยอะมาก เวลาสองฝั่งต้องคุยกันให้เข้าใจตรงกัน

Address/Port Translation: ค่าเริ่มต้นเป็น enabled ทั้งคู่ ถ้า IP ของ VS กับ IP ของเครื่องจริงต่างกันต้องเปิด Address Translation ถ้าพอร์ต 8080 ของ VS ตรงกับพอร์ต 80 ของที่อยู่จริงต้องเปิด Port Translation

SNAT AutoMap: คำขอออกจาก VLAN ไหน ที่อยู่ต้นทาง SNAT ก็เป็น Self IP บน VLAN นั้น ถ้า VLAN เดียวมีหลาย Self IP จะใช้แบบหมุนเวียน

เจ็ด: ทำไมต้องเข้าใจ “Session Persistence”

นี่คือแนวคิดที่ถูกมองข้ามง่ายที่สุดและเกิดเรื่องง่ายที่สุดในโลกของโหลดบาลานซ์

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

นี่คือเหตุผลที่ Session Persistence มีอยู่ F5 ทำผ่าน Connectivity โดยมีโหมดให้เลือก เช่น:

• การคงอยู่ตามที่อยู่ต้นทาง: ผูกตาม IP ต้นทางของไคลเอนต์
• Cookie Persistence: F5 แทรก Cookie เซสชันให้อัตโนมัติ นิยมใช้ที่เลเยอร์ 7 มากที่สุด
• SSL Session ID Persistence: ใช้ซ้ำเซสชัน SSL
• ตาราง Session Persistence: รองรับกฎการหมดเวลาและการจับคู่หลากหลายรูปแบบ

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

แปด: รายละเอียดหน้างานที่เลี่ยงไม่ได้

สุดท้ายหยิบกับดักที่คนอื่นเคยโดนมาสักไม่กี่อัน สรุปให้ตรง ๆ:

• เลือกชั้นของการตรวจสุขภาพให้ถูก: ถ้าดูแค่ TCP Handshake พอร์ตเซิร์ฟเวอร์ยังมีชีวิตแต่แอปล่มก็ยังถูกส่งต่อเหมือนเดิม ถ้าจะตรวจเลเยอร์แอปพลิเคชันต้องใช้ Monitor ชนิด HTTP ยิงเข้า /actuator/health แบบนี้
• ไฟร์วอลล์ต้องจัดแบบ “แซนด์วิช”: ไฟร์วอลล์เครื่องเดียวมักได้ throughput แค่ 30% ของความเร็วเต็มสาย จะเพิ่มต้องกองหลายเครื่อง แต่ไฟร์วอลล์ต้องการให้ข้อมูลเข้า-ออกทางเดียวกัน ไม่งั้นการเชื่อมต่อถูกปฏิเสธ—โซลูชันโหลดบาลานซ์ไฟร์วอลล์ของ F5 แก้ปัญหานี้ได้ ทำ Persistence ของอุปกรณ์แบบโปร่งใสได้
• SSL Offload คือตัวช่วยประหยัด CPU ตัวใหญ่: ให้ F5 จัดการ HTTPS Handshake และการเข้ารหัส-ถอดรหัส แอป Java เบื้องหลังทำแค่ HTTP ประสิทธิภาพดีขึ้นชัดเจน
• ก่อนต่อเข้าสภาพแวดล้อมจริง ทำ Load Test ก่อน: เลเยอร์ 4 เร็วก็จริง แต่ถ้าคุณเปิด Session Persistence บน VS เลเยอร์ 4 เท่ากับแนะนำ state เข้ามา คาดการณ์ประสิทธิภาพต้องคำนวณใหม่
• ตัวชี้วัดมอนิเตอร์ เฝ้าสามอันนี้: สถานะ Pool, Throughput ของ Virtual Server, สถานะสุขภาพของ Node
• คำสั่งไล่ปัญหา: tmsh show ltm pool <pool-name> ดูสถานะ Pool, tmsh show ltm virtual <vs-name> ดูสถานะ Virtual Server

บทส่งท้าย

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

ในคลื่นลูกของ Cloud Native ตอนนี้ โซลูชันซอฟต์แวร์อย่าง LVS, Nginx, HAProxy เอาอยู่สบายในสถานการณ์ขนาดเล็ก-กลาง ข้อได้เปรียบด้านต้นทุนชัดเจน แต่พอเกี่ยวกับจุดเข้าหลักของการเงิน หุ้น หรืออีคอมเมิร์ซตัวใหญ่ คุณค่าของโหลดบาลานซ์ฮาร์ดแวร์ด้านความเสถียร การสลับระดับมิลลิวินาที และความสามารถด้านความปลอดภัยครบวงจร ระยะสั้นก็ยังทดแทนไม่ได้

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

เลเยอร์ 4 ดูป้ายทะเบียน เลเยอร์ 7 แกะกล่อง ต้องประสิทธิภาพเลือกเลเยอร์ 4 ต้องฟีเจอร์เลือกเลเยอร์ 7

อ้างอิง: เอกสารทางการ F5 BIG-IP LTM, เคส F5 Load Balancing จากวารสาร Network Operations and Management, การเปรียบเทียบเทคนิคโหลดบาลานซ์เลเยอร์ 4/เลเยอร์ 7