Q&A 10 คำถามสุดว้าวจาก OpenInfra LIVE ‘Large Scale Ops Deep Dive: NIPA Cloud’

เมื่อวันที่ 21 กันยายน 2566 ที่ผ่านมา ทาง OpenInfra Foundation ได้จัดกิจกรรมถ่ายทอดสดสุดพิเศษ #OpenInfraLive ภายในคอมมิวนิตี้ NIPA Cloud ในฐานะหนึ่งในสมาชิกคอมมิวนิตี้ระดับโลก ก็ได้มีโอกาสเข้าร่วมบรรยายในหัวข้อ Large Scale Ops Deep Dive นำโดย ดร.อภิศักดิ์ จุลยา (Chief Executive Officer) และ ชาญศิลป์ ชิ้นประเสริฐ (Chief Innovation Officer) ทั้งสองท่านเป็นตัวแทนไปพูดคุยแลกเปลี่ยนหัวข้อดังกล่าวกับ Thierry Carrez (Vice-President of Engineering, OpenStack Foundation), Felix Huettner (STACKIT) และ Arnaud Morin (DevOps, OVHCloud) เป็นระยะเวลาประมาณ 1 ชั่วโมง ซึ่งเราได้คัด Q&A ที่สำคัญและน่าสนใจมาให้แล้วจำนวน 10 คำถาม ดังต่อไปนี้

ชาญศิลป์ : เราใช้ KVM hypervisor ร่วมกับ module NOVA ของ OpenStack เพื่อให้บริการประมวลผล (compute) Ceph Storage เราใช้ Cinder Volume สำหรับให้บริการ volume storage และ object storage เราใช้ Octavia สำหรับการให้บริการ load balancer และเราใช้ Fabric Networking สำหรับให้บริการ network โดย NIPA Cloud ได้วาง network ผ่านการใช้งาน VxLAN, BGP และ VPN เพื่อให้ครอบคลุมทุกโลเคชัน หากลูกค้าต้องการใช้งานแอปพลิเคชันทั้งสอง AZ ก็สามารถเชื่อมต่อผ่าน private network ที่เราออกแบบไว้ได้ โดยเราได้วาง network 2 เลเยอร์ ส่วน underlay network ได้ใช้ eVPN, VxLAN สำหรับ leaf spine และ peer MP BGP ระหว่าง AZ และส่วน network overlay ได้ใช้ fabric networking เชื่อมต่อกับ router และแบ่งปันเส้นทางกับ BGP ซึ่งในทางฮาร์ดแวร์ ทีม network จะมีการปรับแต่งค่าอุปกรณ์ด้วย eBGP อยู่แล้ว และทำให้ OpenStack ทำงานบน network ขนาดใหญ่ที่เปรียบเสมือน 1 ภูมิภาค (region)

ดร.อภิศักดิ์ : เมื่อพูดถึง OpenStack ที่เราใช้งานอยู่ ขณะนี้มี VM ประมาณ 2,000 เครื่องสำหรับ NIPA Cloud Space ภายหลังจากการเปิดให้บริการเพียงหนึ่งปีเท่านั้น เรามี compute node ทั้งหมด 4,000 node และ Ceph Storage 18 node โดยมีปริมาณความจุที่เป็น NVMe ประมาณ 300 เทระไบต์ และมี spinning drive ที่เราใช้เพื่อให้บริการ object storage ขนาด 2 เพตะไบต์ โดยแบ่งเป็น 1 เพตะไบต์สำหรับ BKK site (กรุงเทพฯ) และ 1 เพตะไบต์สำหรับ NON Site (นนทบุรี)

นอกจากนี้ยังได้กล่าวถึงการใช้งาน OpenStack คลัสเตอร์แรก และประสบการณ์ที่ NIPA Cloud ได้เรียนรู้มา โดยในช่วงเริ่มต้น เรารัน OpenStack ภายใต้เวอร์ชัน Ocata และใช้ Open vSwitch (OVN) ในขณะนั้น เราพบปัญหาเกี่ยวกับการทำ OpenStack คลัสเตอร์แรกนั่นคือปัญหาเกี่ยวกับการทำ auto backup และปัญหาเกี่ยวกับการขยายขนาด (scaling) เราได้เรียนรู้มากมายจากการทำสิ่งนั้นจนตัดสินใจที่จะสร้างคลัสเตอร์ใหม่โดยใช้โมดูล Victoria และ Yoga ของ OpenStack แต่สำหรับคลัสเตอร์แรกก็ยังใช้ได้ดีอยู่ โดยเรามีการอัปเกรดใหญ่​ (major upgrade) ทุก 2 ปี และจะมีการอัปเกรดย่อย (minor upgrade) ทุก 3 เดือน

ดร.อภิศักดิ์ : เรามีกรณีศึกษามากมาย เมื่อเรานำ Tungsten Fabric มาใช้งาน สิ่งหนึ่งที่เราสามารถให้บริการได้ คือ เราสามารถให้บริการหลาย AZ ได้ ไม่ว่าคุณจะใช้งานจากที่ไหน เรามี private link ที่เชื่อมโยงเข้าด้วยกัน นั่นทำให้การปรับใช้แอปพลิเคชันทั้ง 2 ไซต์หรือหลายไซต์ง่ายขึ้น นั่นคือความสวยงามของ Tungsten Fabric ปัจจุบันเรามี flavor ให้บริการทั้ง shared core และ dedicated core เพื่อให้ผู้ใช้งานสามารถใช้งานแอปพลิเคชันได้หลากหลายที่เหมาะกับความต้องการ หากต้องการปรับขนาดก็สามารถปรับขนาดภายใน instance ได้ นี่คือการบริการตนเอง (self-service) ทั้งหมด เมื่อเป็นเช่นนั้นทำให้เราเห็นแอปพลิเคชันเข้ามามากมาย

อีกหนึ่งกรณีการใช้งานในประเทศไทย คือ การย้ายขึ้นระบบคลาวด์ครั้งแรก โดยลูกค้าจำนวนมากส่งฮาร์ดดิสก์มาให้เราที่ศูนย์ข้อมูล และวิศวกรของเราทำการแปลงเป็น image VMDK เป็น qcow2 เพื่อทำงานบน OpenStack นี่เป็นกรณีการใช้งานที่เรามีต่อลูกค้าชาวไทย

ชาญศิลป์ : ก่อนอื่น ในด้านแอดมิน เราเชื่อมต่อ keystone กับเซิร์ฟเวอร์ LDAP และเราเขียนนโยบายการปรับแต่งของ Neutron, Nova, Cinder, Octavia เล็กน้อย เพื่อแจ้งให้ทีมซัพพอร์ตของเราเข้าใจ และเราก็ใช้งาน Horizon และ CLI ด้วย และยังมีสคริปต์ และ admin portal ที่ต้องจัดการ

ชาญศิลป์ : เราใช้ Zabbix เพื่อรวมศูนย์การตรวจสอบ และตรวจสอบหลายเลเยอร์ เช่น การตรวจสอบฮาร์ดแวร์ การตรวจสอบระบบปฏิบัติการ และ OpenStack API โดยล่าสุดที่เราปรับใช้เมื่อไม่กี่เดือนที่ผ่านมาเป็นเรื่องเกี่ยวกับการตรวจสอบการทำงานของ VM ทั้งหมด โดยได้ลองเรียก ping จากไ hypervisor ไปยัง VM เพราะครั้งสุดท้ายที่ production ของเราหยุดทำงานเกี่ยวกับ Ceph Storage ทำให้ระบบของเราติดขัดประมาณ 5 นาที และเราไม่รู้ว่าจะรีบูต VM ตัวไหน นั่นคือเหตุผลที่เราต้องการเครื่องมือตรวจสอบการใช้งาน

เมื่อพูดเกี่ยวกับไฟฟ้าขัดข้อง เราเคยมีเหตุการณ์ไฟฟ้าขัดข้อง ซึ่งมันเกี่ยวข้องกับ Ceph Storage ระบบคลาวด์ของเราใช้งาน volume storage และเมื่อคุณสร้าง compute node VM จะมีเพียง CPU และ RAM เท่านั้น จากนั้นระบบจะ attach volume storage จาก Ceph Storage ดังนั้นจึงมีปัญหากับ Ceph Storage ทำให้เรามีปัญหากับ VM และมีปัญหาด้านฮาร์ดแวร์กับ Ceph Storage สาเหตุคือ เส้นทางของ NIC card ไม่เสถียร และเป็น OCP 2.0 จากปัจจัยนี้เองทำให้เกิดความร้อนมากกว่าที่ควรจะเป็น และแผงระบายความร้อนเปิดในฮาร์ดแวร์ เราจึงแก้ไขด้วยการพลิกกระแสลมไปอีกด้าน เรามองว่ามันเป็นปัญหาของผู้ผลิตที่ทดสอบไม่ดีพอ เราพบว่ามีความร้อนสูงมาก เราจึงเปลี่ยนจาก OCP 2.0 เป็นการ์ด PCI ทุกอย่างจึงกลับมาใช้งานได้ตามปกติ

ปัญหาที่เกิดขึ้นหลัก ๆ ตอนนั้น คือ network card กำลังจะเสีย และระบบ Ceph ที่ไม่รู้ว่า OHD ตัวไหนยังทำงานอยู่บ้าง เราใช้เวลาเรียนรู้จากสิ่งนี้สักพัก โชคดีที่เรามี AZ 2 แห่ง ซึ่งปัญหาเกิดขึ้นแค่แห่งเดียว เพราะอีกแห่งยังไม่ค่อยได้ใช้งานมากนัก แต่กับ AZ ที่ใช้งานเยอะ ความร้อนมันจะสูงเกินไป สิ่งเหล่านี้คือสิ่งที่เราเรียนรู้ ตอนนี้เราแทนที่การ์ด NIC ทั้งหมดของ OCP 2.0 ด้วยการ์ด PCI เรียบร้อยแล้ว

ชาญศิลป์ : ในระบบของเรา เราไม่ได้ใช้ Kolla Ansible เพียงหนึ่งอย่าง เรากำหนดคลัสเตอร์ของเรา โดยเลเยอร์แรกคือโครงสร้างพื้นฐานระดับโลกที่ใช้การ config 1 Kolla เพื่อจัดการ และเราได้แยกตัวควบคุมและ compute node บางส่วนออก ทีมของเราเรียกว่า edge deployment ซึ่งเป็นการ config Kolla Ansible อีกแบบ เมื่อเรามีไซต์มากขึ้น เราจะทำซ้ำ kolla ansible สำหรับ edge site

ดร.อภิศักดิ์ : แค่ปีนี้ปีเดียว เราเติบโตขึ้นถึง 2,000 VM โครงสร้างพื้นฐานหลักได้รับการติดตั้งเรียบร้อยแล้ว สิ่งเดียวที่เราต้องทำคือเพิ่ม compute node และด้วย leaf spine ทำให้เราสามารถขยายได้และสามารถเติบโตได้ นี่คือความงดงามของการปรับขนาดที่เรามี เช่นเดียวกับ Ceph Storage เพียงแค่ปรับขนาดโดยการเพิ่ม storage เราก็พร้อมสำหรับการขยายแล้ว แต่เรายังไม่รู้ว่าตลาดไทยจะยอมรับสิ่งเหล่านี้ยังไง แต่เรากำลังแสดงสัญญาณที่ดีว่าเราอยู่ในช่วงเริ่มต้น เราต้องแข่งขันกับ hyperscaler กับ Huawei, Tencent ที่กำลังจะเข้ามาในประเทศไทย โดยเราเป็นคลาวด์ท้องถิ่นเพียงแห่งเดียวที่นี่ที่สามารถมอบโครงสร้างพื้นฐานและความเสถียรที่คล้ายคลึงกันให้กับลูกค้าของเรา และเมื่อเป็นแบบท้องถิ่นและ edge และด้วย Tungsten Fabric จะทำให้เราสามารถเติบโตและขยายได้

ดร.อภิศักดิ์ : คลัสเตอร์เก่าเราพบปัญหาการ broadcast เครือข่าย L2 ที่ทำให้เครือข่ายซ้อนทับวนซ้ำ (network overlay loop) การปรับใช้ OpenStack ทั่วไปคือการกำหนด vlan ให้ไปที่ storage ต่อไปยังตัวควบคุม และเมื่อเราปรับขนาด vlan เราจำเป็นต้องขยายไปยัง rack อื่น เมื่อวิศวกรของเราทำบางอย่างผิดพลาด มันจะสร้างลูปเครือข่ายในคลัสเตอร์ ซึ่งทำให้คลัสเตอร์ของเราเกิดปัญหา นี่คือปัญหาที่เราได้รับก่อนหน้านี้

และสำหรับ OpenStack เราประสบปัญหาเมื่อเราทำ snapshot ใน compute node มันจะต้องใช้หน่วยความจำมากขึ้นในขณะที่ทำ snapshot ในประเทศไทยลูกค้าของเราต้องทำ auto backup ทุกวัน นั่นหมายความว่าทุก vm ใน hypervisor แต่ละตัวจะต้องทำ snapshot ในเวลากลางคืน ซึ่งทำให้หน่วยความจำเต็มและคลาวด์ล่ม นั่นเป็นเหตุผลที่เราย้ายไปที่ volume เมื่อมันทำการ snapshot มันจะดำเนินการในฝั่ง Ceph

ชาญศิลป์ : มันไม่เกี่ยวกับ L3 Agent แต่มันเกี่ยวกับวิธีการปรับขนาด compute node, storage และ underlay network นั่นคือปัญหาหลัก เหตุผลที่เราใช้ Tungsten Fabric เพราะว่า Tungsten Fabric ใช้ BGP protocol เราสามารถใส่ BGP บางส่วนจากการซ้อนทับไปยัง router ได้ และ router สามารถควบคุมกฎว่าทิศทางของ network จะไปในทิศทางใด เรามี AZ 2 แห่ง และ floating network 2 แห่ง VM สามารถเข้าสู่อินเทอร์เน็ตได้โดยตรงจากทั้งสองไซต์

ชาญศิลป์ : การโจมตีแบบ DDoS เราได้รับการโจมตีทำให้หน่วยความจำใน vrouter ถูกใช้จนหมด และการเชื่อมต่อเครือข่ายทั้งหมดก็หยุดทำงาน นอกจากนี้ ผู้ที่ไม่ได้รับการโจมตีก็ได้รับความเสียหายเช่นกัน เราจะแก้ปัญหาโดยการทำงานร่วมกับพันธมิตร อาทิ Imperva, Radware, Cloudflare เพื่อปกป้อง IP ทั้งหมดนี้ คุณต้องมีผู้ให้บริการท้องถิ่นด้วย มิฉะนั้น หากคุณจะใช้ traffic ตลอดเวลา จะต้องออกนอกประเทศ และจะเกิด latency จำนวนมาก เราไม่ต้องการสิ่งนั้น โดยการโจมตี DDoS ส่วนใหญ่มาจากภายนอก นี่คือสิ่งที่เราพยายามทำงานร่วมกับผู้ให้บริการ สิ่งที่เราต้องการให้พวกเขาเป็นการตั้งอยู่ในโลคอล หากจะแก้ไขปัญหาบางอย่างให้ทำที่นี่ แต่หากถูกโจมตีจากภายนอก คุณสามารถใช้ node จากทั่วโลกเพื่อปกป้องเราและให้ส่ง good traffic กลับประเทศไทย