ข้อมูลเบื้องต้นเกี่ยวกับส่วนเครือข่ายของโครงสร้างพื้นฐานคลาวด์

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

วันนี้เราจะพูดถึงโลกภายในของโครงสร้างพื้นฐานคลาวด์ โดยเฉพาะอย่างยิ่งเราจะดูที่พื้นฐานของส่วนเครือข่าย

เมฆคืออะไร? การจำลองเสมือนเดียวกัน - มุมมองโปรไฟล์?

มากกว่าคำถามเชิงตรรกะ ไม่ นี่ไม่ใช่การจำลองเสมือน แม้ว่าจะไม่สามารถทำได้หากไม่มีก็ตาม ลองดูคำจำกัดความสองคำ:

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

Virtualization - นี่คือความสามารถในการแบ่งเอนทิตีทางกายภาพหนึ่งรายการ (เช่น เซิร์ฟเวอร์) ออกเป็นหลาย ๆ เสมือน ซึ่งจะเป็นการเพิ่มการใช้ทรัพยากร (เช่น คุณมีเซิร์ฟเวอร์ 3 เครื่องที่โหลดที่ 25-30 เปอร์เซ็นต์ หลังจากการจำลองเสมือน คุณจะได้รับการโหลดเซิร์ฟเวอร์ 1 เครื่อง ร้อยละ 80-90) โดยธรรมชาติแล้วการจำลองเสมือนกินทรัพยากรบางส่วน - คุณต้องป้อนไฮเปอร์ไวเซอร์อย่างไรก็ตามตามการฝึกฝนแสดงให้เห็นว่าเกมนี้คุ้มค่ากับเทียน ตัวอย่างในอุดมคติของการจำลองเสมือนคือ VMWare ซึ่งเตรียมเครื่องเสมือนได้อย่างสมบูรณ์แบบ หรือเช่น KVM ซึ่งฉันชอบ แต่นี่เป็นเรื่องของรสนิยม

เราใช้การจำลองเสมือนโดยที่ไม่รู้ตัว และแม้แต่เราเตอร์เหล็กก็ใช้การจำลองเสมือนอยู่แล้ว ตัวอย่างเช่น ใน JunOS เวอร์ชันล่าสุด ระบบปฏิบัติการได้รับการติดตั้งเป็นเครื่องเสมือนที่ด้านบนของการกระจาย Linux แบบเรียลไทม์ (Wind River 9) แต่การจำลองเสมือนไม่ใช่ระบบคลาวด์ แต่ระบบคลาวด์ไม่สามารถดำรงอยู่ได้หากไม่มีการจำลองเสมือน

การจำลองเสมือนเป็นหนึ่งในองค์ประกอบหลักที่สร้างระบบคลาวด์

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

แต่ฉันเข้าใจว่าจากคำจำกัดความที่นำเสนอข้างต้นยังไม่ชัดเจนว่าจริงๆ แล้วสิ่งใดที่เรียกว่าคลาวด์ได้

ดังนั้นเอกสารจาก NIST (National Institute of Standards and Technology) จึงระบุคุณลักษณะหลัก 5 ประการที่โครงสร้างพื้นฐานระบบคลาวด์ควรมี:

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

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

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

ปรับตัวให้เข้ากับสภาวะต่างๆ ได้อย่างรวดเร็ว บริการจะต้องมีความยืดหยุ่น - การจัดหาทรัพยากรอย่างรวดเร็ว การแจกจ่ายซ้ำ การเพิ่มหรือลดทรัพยากรตามคำขอของลูกค้า และในส่วนของลูกค้าควรจะรู้สึกว่าทรัพยากรบนคลาวด์นั้นไม่มีที่สิ้นสุด ตัวอย่างเช่น เพื่อความสะดวกในการทำความเข้าใจ คุณไม่เห็นคำเตือนว่าพื้นที่ดิสก์บางส่วนของคุณใน Apple iCloud หายไปเนื่องจากฮาร์ดไดรฟ์บนเซิร์ฟเวอร์ใช้งานไม่ได้ และไดรฟ์ใช้งานไม่ได้ นอกจากนี้ สำหรับคุณ ความเป็นไปได้ของบริการนี้แทบไม่มีขีดจำกัด - คุณต้องใช้ 2 TB - ไม่มีปัญหา คุณชำระเงินและรับแล้ว ตัวอย่างที่คล้ายกันสามารถมอบให้กับ Google.Drive หรือ Yandex.Disk

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

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

ทำไมเราถึงต้องการคลาวด์?

อย่างไรก็ตาม เทคโนโลยีใหม่หรือที่มีอยู่ โปรโตคอลใหม่จะถูกสร้างขึ้นเพื่อบางสิ่งบางอย่าง (แน่นอนว่า ยกเว้น RIP-ng) ไม่มีใครต้องการโปรโตคอลเพื่อประโยชน์ของโปรโตคอล (ยกเว้น RIP-ng แน่นอน) เป็นเหตุผลที่ระบบคลาวด์ถูกสร้างขึ้นเพื่อให้บริการบางอย่างแก่ผู้ใช้/ลูกค้า เราทุกคนคุ้นเคยกับบริการคลาวด์อย่างน้อยสองสามอย่าง เช่น Dropbox หรือ Google.Docs และฉันเชื่อว่าคนส่วนใหญ่ใช้งานได้สำเร็จ ตัวอย่างเช่น บทความนี้เขียนโดยใช้บริการคลาวด์ของ Google.Docs แต่บริการระบบคลาวด์ที่เรารู้จักเป็นเพียงส่วนหนึ่งของความสามารถของระบบคลาวด์ กล่าวอย่างเจาะจงก็คือ บริการดังกล่าวเป็นเพียงบริการประเภท SaaS เท่านั้น เราสามารถให้บริการคลาวด์ได้สามวิธี: ในรูปแบบของ SaaS, PaaS หรือ IaaS บริการใดที่คุณต้องการขึ้นอยู่กับความต้องการและความสามารถของคุณ

ลองดูแต่ละรายการตามลำดับ:

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

แพลตฟอร์มเป็นบริการ (PaaS) — เมื่อใช้โมเดลนี้ ผู้ให้บริการจะจัดเตรียมชิ้นงานไว้ให้บริการแก่ลูกค้า เช่น เอาเว็บเซิร์ฟเวอร์ เป็นต้น ผู้ให้บริการได้มอบเซิร์ฟเวอร์เสมือนให้กับลูกค้า (อันที่จริงคือชุดของทรัพยากร เช่น RAM/CPU/ที่เก็บข้อมูล/เน็ต ฯลฯ) และแม้กระทั่งติดตั้งระบบปฏิบัติการและซอฟต์แวร์ที่จำเป็นบนเซิร์ฟเวอร์นี้ อย่างไรก็ตาม การกำหนดค่าของ ลูกค้าเป็นผู้ดำเนินการทั้งหมดนี้เองและเพื่อประสิทธิภาพการบริการที่ลูกค้าตอบ เช่นเดียวกับในกรณีก่อนหน้านี้ ผู้ให้บริการมีหน้าที่รับผิดชอบต่อประสิทธิภาพของอุปกรณ์ทางกายภาพ ไฮเปอร์ไวเซอร์ เครื่องเสมือน ความพร้อมใช้งานของเครือข่าย ฯลฯ แต่ตัวบริการเองไม่อยู่ในขอบเขตความรับผิดชอบอีกต่อไป

โครงสร้างพื้นฐานเป็นบริการ (IaaS) - วิธีการนี้น่าสนใจกว่าอยู่แล้ว ที่จริงแล้ว ผู้ให้บริการมอบโครงสร้างพื้นฐานเสมือนจริงที่สมบูรณ์ให้กับลูกค้า - นั่นคือชุดทรัพยากร (พูล) บางส่วน เช่น CPU Cores, RAM, เครือข่าย ฯลฯ ทุกอย่างขึ้นอยู่กับ ลูกค้า - สิ่งที่ลูกค้าต้องการทำกับทรัพยากรเหล่านี้ภายในกลุ่มที่จัดสรร (โควต้า) - มันไม่ได้มีความสำคัญเป็นพิเศษสำหรับซัพพลายเออร์ ไม่ว่าลูกค้าจะต้องการสร้าง vEPC ของตัวเอง หรือแม้แต่สร้างตัวดำเนินการขนาดเล็กและให้บริการด้านการสื่อสาร ไม่ต้องสงสัยเลย ลงมือทำเลย ในสถานการณ์เช่นนี้ ผู้ให้บริการมีหน้าที่รับผิดชอบในการจัดเตรียมทรัพยากร ความทนทานต่อข้อผิดพลาด และความพร้อมใช้งาน รวมถึงระบบปฏิบัติการที่อนุญาตให้รวบรวมทรัพยากรเหล่านี้และทำให้ลูกค้าพร้อมใช้งานโดยสามารถเพิ่มหรือลดทรัพยากรได้ตลอดเวลา ตามคำขอของลูกค้า ไคลเอนต์กำหนดค่าเครื่องเสมือนทั้งหมดและดิ้นอื่น ๆ ด้วยตนเองผ่านพอร์ทัลและคอนโซลบริการตนเอง รวมถึงการตั้งค่าเครือข่าย (ยกเว้นเครือข่ายภายนอก)

OpenStack คืออะไร?

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

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

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

ในขณะที่เขียนเนื้อหานี้ โครงสร้าง OpenStack มีลักษณะดังนี้:

ภาพที่ถ่ายจาก openstack.org

แต่ละส่วนประกอบที่รวมอยู่ใน OpenStack ทำหน้าที่เฉพาะ สถาปัตยกรรมแบบกระจายนี้ช่วยให้คุณสามารถรวมชุดส่วนประกอบการทำงานที่คุณต้องการไว้ในโซลูชันได้ อย่างไรก็ตาม ส่วนประกอบบางส่วนเป็นส่วนประกอบหลัก และการถอดส่วนประกอบออกจะทำให้โซลูชันโดยรวมใช้งานไม่ได้ทั้งหมดหรือบางส่วน ส่วนประกอบเหล่านี้มักจะจัดเป็น:

• Dashboard — GUI บนเว็บสำหรับจัดการบริการ OpenStack
• หลักสำคัญ เป็นบริการระบุตัวตนแบบรวมศูนย์ที่ให้ฟังก์ชันการตรวจสอบสิทธิ์และการอนุญาตสำหรับบริการอื่นๆ รวมถึงการจัดการข้อมูลรับรองผู้ใช้และบทบาทของพวกเขา
• นิวตรอน - บริการเครือข่ายที่ให้การเชื่อมต่อระหว่างอินเทอร์เฟซของบริการ OpenStack ต่างๆ (รวมถึงการเชื่อมต่อระหว่าง VM และการเข้าถึงโลกภายนอก)
• ถ่าน — ให้การเข้าถึงพื้นที่เก็บข้อมูลบล็อกสำหรับเครื่องเสมือน
• โนวา — การจัดการวงจรชีวิตของเครื่องเสมือน
• เหลือบมอง — พื้นที่เก็บข้อมูลอิมเมจและสแน็ปช็อตของเครื่องเสมือน
• รวดเร็ว — ให้การเข้าถึงวัตถุที่เก็บข้อมูล
• เซลโลมิเตอร์ — บริการที่ให้ความสามารถในการรวบรวมการวัดและส่งข้อมูลทางไกลและวัดทรัพยากรที่มีอยู่และที่ใช้ไป
• ความร้อน — การเรียบเรียงตามเทมเพลตสำหรับการสร้างและการจัดเตรียมทรัพยากรโดยอัตโนมัติ

สามารถดูรายชื่อโครงการทั้งหมดและวัตถุประสงค์ได้ ที่นี่.

ส่วนประกอบ OpenStack แต่ละรายการเป็นบริการที่ทำหน้าที่เฉพาะและจัดเตรียม API เพื่อจัดการฟังก์ชันนั้นและโต้ตอบกับบริการระบบปฏิบัติการคลาวด์อื่นๆ เพื่อสร้างโครงสร้างพื้นฐานแบบครบวงจร ตัวอย่างเช่น Nova มอบการจัดการทรัพยากรการประมวลผลและ API สำหรับการเข้าถึงการกำหนดค่าทรัพยากรเหล่านี้ Glance มอบการจัดการรูปภาพและ API สำหรับการจัดการ Cinder มอบพื้นที่จัดเก็บบล็อกและ API สำหรับการจัดการ ฯลฯ ฟังก์ชั่นทั้งหมดเชื่อมโยงกันอย่างใกล้ชิด

อย่างไรก็ตาม หากคุณพิจารณาดู บริการทั้งหมดที่ทำงานใน OpenStack ก็คือเครื่องเสมือน (หรือคอนเทนเนอร์) ที่เชื่อมต่อกับเครือข่ายในที่สุด คำถามเกิดขึ้น - ทำไมเราถึงต้องการองค์ประกอบมากมาย?

มาดูอัลกอริทึมสำหรับการสร้างเครื่องเสมือนและเชื่อมต่อกับเครือข่ายและที่เก็บข้อมูลถาวรใน OpenStack

1. เมื่อคุณสร้างคำขอเพื่อสร้างเครื่อง ไม่ว่าจะเป็นคำขอผ่าน Horizon (Dashboard) หรือคำขอผ่าน CLI สิ่งแรกที่เกิดขึ้นคือการอนุญาตคำขอของคุณบน Keystone - คุณสามารถสร้างเครื่องได้หรือไม่ มันมี สิทธิ์ในการใช้เครือข่ายนี้ โควต้าร่างของคุณ ฯลฯ
2. Keystone ตรวจสอบคำขอของคุณและสร้างโทเค็นการรับรองความถูกต้องในข้อความตอบกลับ ซึ่งจะนำไปใช้เพิ่มเติม เมื่อได้รับการตอบกลับจาก Keystone คำขอจะถูกส่งไปยัง Nova (nova api)
3. Nova-api ตรวจสอบความถูกต้องของคำขอของคุณโดยติดต่อ Keystone โดยใช้โทเค็นการรับรองความถูกต้องที่สร้างขึ้นก่อนหน้านี้
4. Keystone ดำเนินการตรวจสอบสิทธิ์และให้ข้อมูลเกี่ยวกับสิทธิ์และข้อจำกัดตามโทเค็นการตรวจสอบสิทธิ์นี้
5. Nova-api สร้างรายการสำหรับ VM ใหม่ในฐานข้อมูล nova และส่งคำขอเพื่อสร้างเครื่องไปยัง nova-scheduler
6. Nova-scheduler เลือกโฮสต์ (โหนดคอมพิวเตอร์) ที่จะปรับใช้ VM ตามพารามิเตอร์ น้ำหนัก และโซนที่ระบุ บันทึกนี้และ VM ID ถูกเขียนไปยังฐานข้อมูล nova
7. ถัดไป nova-scheduler จะติดต่อกับ nova-compute พร้อมคำขอปรับใช้อินสแตนซ์ Nova-compute ติดต่อ nova-conductor เพื่อรับข้อมูลเกี่ยวกับพารามิเตอร์ของเครื่อง (nova-conductor เป็นองค์ประกอบ nova ที่ทำหน้าที่เป็นพร็อกซีเซิร์ฟเวอร์ระหว่าง nova-database และ nova-compute โดยจำกัดจำนวนคำขอไปยังฐานข้อมูล nova เพื่อหลีกเลี่ยงปัญหากับฐานข้อมูล การลดภาระความสม่ำเสมอ)
8. Nova-conductor รับข้อมูลที่ร้องขอจากฐานข้อมูล nova และส่งต่อไปยัง nova-compute
9. ถัดไป nova-compute เรียกอย่างรวดเร็วเพื่อรับ ID รูปภาพ Glace ตรวจสอบคำขอใน Keystone และส่งคืนข้อมูลที่ร้องขอ
10. Nova-compute จะสัมผัสนิวตรอนเพื่อรับข้อมูลเกี่ยวกับพารามิเตอร์เครือข่าย เช่นเดียวกับการมองดู นิวตรอนจะตรวจสอบคำขอใน Keystone หลังจากนั้นจะสร้างรายการในฐานข้อมูล (ตัวระบุพอร์ต ฯลฯ) สร้างคำขอเพื่อสร้างพอร์ต และส่งคืนข้อมูลที่ร้องขอไปยัง nova-compute
11. Nova-compute ติดต่อกับคำขอจัดสรรวอลุ่มให้กับเครื่องเสมือน เช่นเดียวกับการดูอย่างรวดเร็ว ไซเดอร์จะตรวจสอบคำขอใน Keystone สร้างคำขอสร้างวอลุ่ม และส่งคืนข้อมูลที่ร้องขอ
12. Nova-compute ติดต่อ libvirt พร้อมคำขอเพื่อปรับใช้เครื่องเสมือนด้วยพารามิเตอร์ที่ระบุ

ในความเป็นจริง การดำเนินการที่ดูเหมือนง่ายในการสร้างเครื่องเสมือนธรรมดาๆ กลายเป็นกระแสน้ำวนของการเรียก API ระหว่างองค์ประกอบของแพลตฟอร์มคลาวด์ ยิ่งไปกว่านั้น อย่างที่คุณเห็น แม้แต่บริการที่กำหนดไว้ก่อนหน้านี้ก็ยังประกอบด้วยองค์ประกอบเล็กๆ ที่มีการโต้ตอบกันเกิดขึ้น การสร้างเครื่องเป็นเพียงส่วนเล็กๆ ของสิ่งที่แพลตฟอร์มคลาวด์ช่วยให้คุณทำได้ - มีบริการที่รับผิดชอบในการสร้างสมดุลการรับส่งข้อมูล บริการที่รับผิดชอบในการจัดเก็บข้อมูลแบบบล็อก บริการที่รับผิดชอบ DNS บริการที่รับผิดชอบในการจัดเตรียมเซิร์ฟเวอร์ Bare Metal ฯลฯ . คลาวด์ช่วยให้คุณปฏิบัติต่อเครื่องเสมือนของคุณเหมือนฝูงแกะ หากมีอะไรเกิดขึ้นกับเครื่องของคุณในสภาพแวดล้อมเสมือน - คุณกู้คืนจากการสำรองข้อมูล ฯลฯ แต่แอปพลิเคชันระบบคลาวด์ถูกสร้างขึ้นในลักษณะที่เครื่องเสมือนไม่ได้มีบทบาทสำคัญเช่นนี้ - เครื่องเสมือน "ตาย" - ไม่มีปัญหา - ใหม่ถูกสร้างขึ้นอย่างเรียบง่าย ยานพาหนะนั้นใช้เทมเพลตและอย่างที่พวกเขาพูด ทีมไม่ได้สังเกตเห็นการสูญเสียเครื่องบินรบ โดยธรรมชาติแล้ว สิ่งนี้จัดให้มีกลไกการประสาน - ด้วยการใช้เทมเพลต Heat คุณสามารถปรับใช้ฟังก์ชันที่ซับซ้อนซึ่งประกอบด้วยเครือข่ายและเครื่องเสมือนมากมายได้อย่างง่ายดาย

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

นิวตรอนเป็นบริการเครือข่าย โดยจัดให้มี API สำหรับจัดการส่วนเครือข่ายของโครงสร้างพื้นฐานคลาวด์ บริการนี้ขับเคลื่อนและจัดการส่วนเครือข่ายของ OpenStack โดยจัดเตรียมเลเยอร์นามธรรมที่เรียกว่า Network-as-a-Service (NaaS) นั่นคือ เครือข่ายเป็นหน่วยเสมือนที่สามารถวัดได้เหมือนกับ ตัวอย่างเช่น แกน CPU เสมือน หรือจำนวน RAM

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

ดังนั้นเราจึงมี VM ไคลเอนต์ RED สองเครื่อง และ VM ไคลเอนต์ GREEN สองเครื่อง สมมติว่าเครื่องเหล่านี้อยู่บนไฮเปอร์ไวเซอร์สองตัวในลักษณะนี้:

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

ในการสร้างคลาวด์ เราจำเป็นต้องเพิ่มองค์ประกอบหลายอย่าง ขั้นแรก เราจำลองส่วนเครือข่าย - เราจำเป็นต้องเชื่อมต่อเครื่องทั้ง 4 นี้เป็นคู่กัน และไคลเอนต์ต้องการการเชื่อมต่อ L2 คุณสามารถใช้สวิตช์และกำหนดค่า Trunk ตามทิศทางและแก้ไขทุกอย่างโดยใช้ลินุกซ์บริดจ์ หรือสำหรับผู้ใช้ขั้นสูง openvswitch (เราจะกลับมาที่สิ่งนี้ในภายหลัง) แต่อาจมีเครือข่ายจำนวนมากและการผลักดัน L2 ผ่านสวิตช์อย่างต่อเนื่องไม่ใช่ความคิดที่ดีที่สุด - มีแผนกต่างๆ, ส่วนให้บริการ, เดือนที่รอให้แอปพลิเคชันเสร็จสมบูรณ์, สัปดาห์ของการแก้ไขปัญหา - ในโลกสมัยใหม่นี้ วิธีการไม่ทำงานอีกต่อไป และยิ่งบริษัทเข้าใจเรื่องนี้ได้เร็วเท่าไหร่ก็ยิ่งก้าวไปข้างหน้าได้ง่ายขึ้นเท่านั้น ดังนั้น ระหว่างไฮเปอร์ไวเซอร์ เราจะเลือกเครือข่าย L3 ที่เครื่องเสมือนของเราจะสื่อสาร และนอกเหนือจากเครือข่าย L3 นี้ เราจะสร้างเครือข่ายซ้อนทับ L2 เสมือนที่การรับส่งข้อมูลของเครื่องเสมือนของเราจะทำงาน คุณสามารถใช้ GRE, Geneve หรือ VxLAN เป็นการห่อหุ้มได้ ตอนนี้เรามาดูเรื่องหลังกันก่อนถึงแม้ว่ามันจะไม่ได้สำคัญเป็นพิเศษก็ตาม

เราจำเป็นต้องค้นหา VTEP ที่ไหนสักแห่ง (ฉันหวังว่าทุกคนจะคุ้นเคยกับคำศัพท์ของ VxLAN) เนื่องจากเรามีเครือข่าย L3 ที่ส่งตรงมาจากเซิร์ฟเวอร์ จึงไม่มีอะไรขัดขวางไม่ให้เราวาง VTEP บนเซิร์ฟเวอร์ได้ และ OVS (OpenvSwitch) ก็ทำได้ดีเยี่ยมในการดำเนินการนี้ ด้วยเหตุนี้เราจึงได้การออกแบบนี้:

เนื่องจากต้องแบ่งการรับส่งข้อมูลระหว่าง VM พอร์ตที่ไปยังเครื่องเสมือนจะมีหมายเลข vlan ที่แตกต่างกัน หมายเลขแท็กมีบทบาทภายในสวิตช์เสมือนเดียวเท่านั้น เนื่องจากเมื่อห่อหุ้มใน VxLAN เราสามารถลบออกได้อย่างง่ายดาย เนื่องจากเราจะมี VNI

ตอนนี้เราสามารถสร้างเครื่องและเครือข่ายเสมือนของเราได้โดยไม่มีปัญหาใดๆ

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

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

นั่นคือเราได้แผนภาพต่อไปนี้:

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

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

เป็นผลให้เราได้แผนภาพนี้:

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

จริงๆ แล้ว โครงการของเราใช้การได้แล้ว แต่มีความแตกต่างบางประการ:

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

เริ่มจากการปกป้องเครื่องจักรกันก่อน สำหรับสิ่งนี้คุณสามารถใช้ iptables ซ้ำ ๆ ได้ทำไมล่ะ

นั่นคือตอนนี้โทโพโลยีของเราซับซ้อนขึ้นเล็กน้อย:

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

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

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

และนี่คือ NAT ที่เข้ามาช่วยเหลือเรา - เราจะทำให้ลูกค้าสามารถเข้าถึงโลกภายนอกผ่านเนมสเปซเริ่มต้นโดยใช้การแปล NAT นี่เป็นปัญหาเล็กน้อย นี่เป็นสิ่งที่ดีถ้าเซิร์ฟเวอร์ไคลเอนต์ทำหน้าที่เป็นไคลเอนต์และไม่ใช่เซิร์ฟเวอร์ - นั่นคือเริ่มต้นแทนที่จะยอมรับการเชื่อมต่อ แต่สำหรับเรามันจะเป็นอีกทางหนึ่ง ในกรณีนี้ เราต้องทำ NAT ปลายทาง เพื่อว่าเมื่อได้รับทราฟฟิก โหนดควบคุมจะเข้าใจว่าทราฟฟิกนี้มีไว้สำหรับเครื่องเสมือน A ของไคลเอนต์ A ซึ่งหมายความว่าเราจำเป็นต้องทำการแปล NAT จากที่อยู่ภายนอก เช่น 100.1.1.1 .10.0.0.1 ไปยังที่อยู่ภายใน 100 ในกรณีนี้ แม้ว่าไคลเอ็นต์ทั้งหมดจะใช้เครือข่ายเดียวกัน แต่การแยกภายในจะยังคงอยู่อย่างสมบูรณ์ นั่นคือเราจำเป็นต้องทำ dNAT และ sNAT บนโหนดควบคุม ไม่ว่าจะใช้เครือข่ายเดียวกับที่อยู่แบบลอยหรือเครือข่ายภายนอก หรือทั้งสองอย่างพร้อมกัน ขึ้นอยู่กับสิ่งที่คุณต้องการนำเข้าไปยังระบบคลาวด์ เราจะไม่เพิ่มที่อยู่แบบลอยตัวลงในไดอะแกรม แต่จะปล่อยให้เครือข่ายภายนอกที่เพิ่มไว้ก่อนหน้านี้ - ไคลเอนต์แต่ละรายมีเครือข่ายภายนอกของตัวเอง (ในไดอะแกรมจะระบุเป็น vlan 200 และ XNUMX บนอินเทอร์เฟซภายนอก)

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

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

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

ปัญหาต่อไปคือดิสก์เครื่องเสมือน ในขณะนี้ พวกเขาจะถูกเก็บไว้ในไฮเปอร์ไวเซอร์เองและในกรณีที่เกิดปัญหากับไฮเปอร์ไวเซอร์ เราจะสูญเสียข้อมูลทั้งหมด - และการมีอยู่ของการโจมตีจะไม่ช่วยได้ที่นี่หากเราไม่ได้สูญเสียดิสก์ แต่เป็นเซิร์ฟเวอร์ทั้งหมด ในการทำเช่นนี้ เราจำเป็นต้องสร้างบริการที่จะทำหน้าที่เป็นส่วนหน้าสำหรับพื้นที่เก็บข้อมูลบางประเภท พื้นที่จัดเก็บข้อมูลประเภทใดไม่สำคัญสำหรับเราเป็นพิเศษ แต่ควรปกป้องข้อมูลของเราจากความล้มเหลวของทั้งดิสก์และโหนด และอาจรวมถึงทั้งตู้ด้วย มีหลายตัวเลือกที่นี่ - แน่นอนว่ามีเครือข่าย SAN ที่มี Fibre Channel แต่ขอบอกตามตรงว่า FC เป็นมรดกตกทอดของอดีตไปแล้ว - อะนาล็อกของ E1 ในการขนส่ง - ใช่ฉันเห็นด้วยมันยังคงใช้อยู่ แต่ เฉพาะที่ที่มันเป็นไปไม่ได้เลยหากไม่มีมัน ดังนั้นฉันจะไม่สมัครใจปรับใช้เครือข่าย FC ในปี 2020 โดยรู้ว่ายังมีทางเลือกอื่นที่น่าสนใจกว่านี้ แม้ว่าสำหรับแต่ละคนอาจมีคนที่เชื่อว่า FC มีข้อจำกัดทั้งหมดคือสิ่งที่เราต้องการ - ฉันจะไม่เถียง ทุกคนมีความคิดเห็นของตัวเอง อย่างไรก็ตาม วิธีแก้ปัญหาที่น่าสนใจที่สุดในความคิดของฉันคือการใช้ SDS เช่น Ceph

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

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

หมายเหตุ: คุณยังสามารถสร้างโหนดประมวลผลแบบไฮเปอร์คอนเวิร์จได้ นี่เป็นแนวคิดของการรวมฟังก์ชันต่างๆ ไว้บนโหนดเดียว เช่น ที่เก็บข้อมูล+คำนวณ โดยไม่ต้องทุ่มเทโหนดพิเศษสำหรับพื้นที่จัดเก็บ Ceph เราจะได้รับรูปแบบการทนทานต่อข้อผิดพลาดแบบเดียวกัน เนื่องจาก SDS จะจองข้อมูลตามระดับการจองที่เราระบุ อย่างไรก็ตาม โหนดไฮเปอร์คอนเวอร์จมักจะประนีประนอมเสมอ เนื่องจากโหนดการจัดเก็บข้อมูลไม่เพียงทำให้อากาศร้อนอย่างที่เห็นเมื่อมองแวบแรก (เนื่องจากไม่มีเครื่องเสมือนอยู่บนนั้น) - มันใช้ทรัพยากร CPU ในการให้บริการ SDS (อันที่จริง ทำทุกอย่าง การจำลองแบบและการกู้คืนหลังจากความล้มเหลวของโหนด ดิสก์ ฯลฯ) นั่นคือคุณจะสูญเสียพลังของโหนดคอมพิวท์บางส่วนหากคุณรวมเข้ากับที่เก็บข้อมูล

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

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

สถาปัตยกรรมนิวตรอน

ใน OpenStack นิวตรอนมีหน้าที่รับผิดชอบในการเชื่อมต่อพอร์ตเครื่องเสมือนเข้ากับเครือข่าย L2 ทั่วไป เพื่อให้แน่ใจว่ามีการกำหนดเส้นทางการรับส่งข้อมูลระหว่าง VM ที่อยู่บนเครือข่าย L2 ที่แตกต่างกัน รวมถึงการกำหนดเส้นทางภายนอก โดยให้บริการต่างๆ เช่น NAT, Floating IP, DHCP เป็นต้น

ในระดับสูงสามารถอธิบายการทำงานของบริการเครือข่าย (ส่วนพื้นฐาน) ได้ดังนี้

เมื่อเริ่มต้น VM บริการเครือข่าย:

1. สร้างพอร์ตสำหรับ VM (หรือพอร์ต) ที่กำหนดและแจ้งบริการ DHCP เกี่ยวกับมัน
2. มีการสร้างอุปกรณ์เครือข่ายเสมือนใหม่ (ผ่าน libvirt)
3. VM เชื่อมต่อกับพอร์ตที่สร้างขึ้นในขั้นตอนที่ 1

น่าแปลกที่งานของนิวตรอนใช้กลไกมาตรฐานที่ทุกคนคุ้นเคยซึ่งเคยใช้ Linux เช่น เนมสเปซ, iptables, ลินุกซ์บริดจ์, openvswitch, conntrack เป็นต้น

ควรชี้แจงทันทีว่านิวตรอนไม่ใช่ตัวควบคุม SDN

นิวตรอนประกอบด้วยองค์ประกอบหลายอย่างที่เชื่อมต่อถึงกัน:

เซิร์ฟเวอร์ OpenStack-นิวตรอน เป็น daemon ที่ทำงานร่วมกับคำขอของผู้ใช้ผ่าน API ปีศาจนี้ไม่เกี่ยวข้องกับการลงทะเบียนการเชื่อมต่อเครือข่ายใดๆ แต่ให้ข้อมูลที่จำเป็นสำหรับสิ่งนี้แก่ปลั๊กอิน ซึ่งจะกำหนดค่าองค์ประกอบเครือข่ายที่ต้องการ เอเจนต์นิวตรอนบนโหนด OpenStack ลงทะเบียนกับเซิร์ฟเวอร์นิวตรอน

จริงๆ แล้ว Neutron-server เป็นแอปพลิเคชั่นที่เขียนด้วยภาษา Python ซึ่งประกอบด้วยสองส่วน:

• บริการพักผ่อน
• ปลั๊กอินนิวตรอน (แกนหลัก/บริการ)

บริการ REST ได้รับการออกแบบมาเพื่อรับการเรียก API จากส่วนประกอบอื่นๆ (เช่น คำขอให้ข้อมูลบางอย่าง เป็นต้น)

ปลั๊กอินคือส่วนประกอบ/โมดูลซอฟต์แวร์ปลั๊กอินที่ถูกเรียกในระหว่างการร้องขอ API นั่นคือการระบุแหล่งที่มาของบริการเกิดขึ้นผ่านปลั๊กอินเหล่านั้น ปลั๊กอินแบ่งออกเป็นสองประเภท - บริการและรูท ตามกฎแล้ว ปลั๊กอินม้ามีหน้าที่หลักในการจัดการพื้นที่ที่อยู่และการเชื่อมต่อ L2 ระหว่าง VM และปลั๊กอินบริการมีฟังก์ชันเพิ่มเติมอยู่แล้ว เช่น VPN หรือ FW

คุณสามารถดูรายการปลั๊กอินที่มีอยู่ในปัจจุบันได้ ที่นี่

อาจมีปลั๊กอินบริการได้หลายปลั๊กอิน แต่จะมีปลั๊กอินม้าได้เพียงปลั๊กอินเดียวเท่านั้น

openstack-นิวตรอน-ml2 เป็นปลั๊กอินรูท OpenStack มาตรฐาน ปลั๊กอินนี้มีสถาปัตยกรรมแบบโมดูลาร์ (ต่างจากรุ่นก่อน) และกำหนดค่าบริการเครือข่ายผ่านไดรเวอร์ที่เชื่อมต่ออยู่ เราจะมาดูตัวปลั๊กอินกันในภายหลัง เนื่องจากอันที่จริงแล้วปลั๊กอินนี้ให้ความยืดหยุ่นเหมือนกับที่ OpenStack มีในส่วนของเครือข่าย สามารถเปลี่ยนปลั๊กอินรูทได้ (เช่น Contrail Networking จะทำการแทนที่ดังกล่าว)

บริการ RPC (rabbitmq-เซิร์ฟเวอร์) — บริการที่ให้การจัดการคิวและการโต้ตอบกับบริการ OpenStack อื่น ๆ รวมถึงการโต้ตอบระหว่างตัวแทนบริการเครือข่าย

ตัวแทนเครือข่าย — เอเจนต์ที่อยู่ในแต่ละโหนดซึ่งมีการกำหนดค่าบริการเครือข่าย

ตัวแทนมีหลายประเภท

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

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

เอเจนต์ L3 ใช้เนมสเปซ Linux เพื่อให้ผู้เช่าแต่ละรายมีชุดเครือข่ายแยกของตัวเองและฟังก์ชันการทำงานของเราเตอร์เสมือนที่กำหนดเส้นทางการรับส่งข้อมูลและให้บริการเกตเวย์สำหรับเครือข่ายเลเยอร์ 2

ฐานข้อมูล — ฐานข้อมูลตัวระบุเครือข่าย ซับเน็ต พอร์ต พูล ฯลฯ

ในความเป็นจริง นิวตรอนยอมรับคำขอ API จากการสร้างเอนทิตีเครือข่าย ตรวจสอบคำขอ และผ่าน RPC (หากเข้าถึงปลั๊กอินหรือเอเจนต์บางตัว) หรือ REST API (หากสื่อสารใน SDN) จะส่งไปยังเอเจนต์ (ผ่านปลั๊กอิน) คำแนะนำที่จำเป็นในการจัดการบริการที่ร้องขอ

ตอนนี้เรามาดูการติดตั้งทดสอบกัน (วิธีการปรับใช้และสิ่งที่รวมอยู่ในนั้น เราจะดูในส่วนการใช้งานจริงในภายหลัง) และดูว่าแต่ละส่วนประกอบอยู่ที่ใด:

(overcloud) [stack@undercloud ~]$ openstack network agent list  
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| ID                                   | Agent Type         | Host                                | Availability Zone | Alive | State | Binary                    |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| 10495de9-ba4b-41fe-b30a-b90ec3f8728b | Open vSwitch agent | overcloud-novacompute-1.localdomain | None              | :-)   | UP    | neutron-openvswitch-agent |
| 1515ad4a-5972-46c3-af5f-e5446dff7ac7 | L3 agent           | overcloud-controller-0.localdomain  | nova              | :-)   | UP    | neutron-l3-agent          |
| 322e62ca-1e5a-479e-9a96-4f26d09abdd7 | DHCP agent         | overcloud-controller-0.localdomain  | nova              | :-)   | UP    | neutron-dhcp-agent        |
| 9c1de2f9-bac5-400e-998d-4360f04fc533 | Open vSwitch agent | overcloud-novacompute-0.localdomain | None              | :-)   | UP    | neutron-openvswitch-agent |
| d99c5657-851e-4d3c-bef6-f1e3bb1acfb0 | Open vSwitch agent | overcloud-controller-0.localdomain  | None              | :-)   | UP    | neutron-openvswitch-agent |
| ff85fae6-5543-45fb-a301-19c57b62d836 | Metadata agent     | overcloud-controller-0.localdomain  | None              | :-)   | UP    | neutron-metadata-agent    |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
(overcloud) [stack@undercloud ~]$ 

จริงๆ แล้ว นั่นคือโครงสร้างทั้งหมดของนิวตรอน ตอนนี้ก็คุ้มค่าที่จะใช้เวลากับปลั๊กอิน ML2

โมดูลาร์เลเยอร์ 2

ตามที่กล่าวไว้ข้างต้น ปลั๊กอินนี้เป็นปลั๊กอินรูทมาตรฐานของ OpenStack และมีสถาปัตยกรรมแบบโมดูลาร์

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

ML2 มีสององค์ประกอบ - ไดรเวอร์สองประเภท: ประเภทไดรเวอร์และไดรเวอร์กลไก

ประเภทไดรเวอร์ กำหนดเทคโนโลยีที่จะใช้ในการจัดการการเชื่อมต่อเครือข่าย เช่น VxLAN, VLAN, GRE ในขณะเดียวกันผู้ขับขี่ก็อนุญาตให้ใช้เทคโนโลยีที่แตกต่างกันได้ เทคโนโลยีมาตรฐานคือการห่อหุ้ม VxLAN สำหรับเครือข่ายซ้อนทับและเครือข่ายภายนอก vlan

ไดรเวอร์ประเภทประกอบด้วยประเภทเครือข่ายต่อไปนี้:

Flat - เครือข่ายโดยไม่ต้องติดแท็ก
VLAN - เครือข่ายที่ติดแท็ก
ในประเทศ — เครือข่ายชนิดพิเศษสำหรับการติดตั้งแบบออลอินวัน (การติดตั้งดังกล่าวจำเป็นสำหรับนักพัฒนาหรือสำหรับการฝึกอบรม)
GRE - เครือข่ายซ้อนทับโดยใช้อุโมงค์ GRE
VxLAN — เครือข่ายซ้อนทับโดยใช้อุโมงค์ VxLAN

ไดรเวอร์กลไก กำหนดเครื่องมือที่รับรองการจัดระเบียบของเทคโนโลยีที่ระบุในไดรเวอร์ประเภท - ตัวอย่างเช่น openvswitch, sr-iov, opendaylight, OVN เป็นต้น

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

ตัวอย่าง: หากเราใช้ ML2 ร่วมกับ OVS เอเจนต์ L2 จะถูกติดตั้งบนแต่ละโหนดการประมวลผลที่จัดการ OVS อย่างไรก็ตาม หากเราใช้ OVN หรือ OpenDayLight เช่น การควบคุมของ OVS จะอยู่ภายใต้เขตอำนาจศาลของพวกเขา - นิวตรอนจะออกคำสั่งให้กับคอนโทรลเลอร์ผ่านปลั๊กอินรูท และมันจะทำตามที่บอกไปแล้ว

มาทำความเข้าใจกับ Open vSwitch กันดีกว่า

ในขณะนี้ หนึ่งในองค์ประกอบสำคัญของ OpenStack คือ Open vSwitch
เมื่อติดตั้ง OpenStack โดยไม่ต้องใช้ SDN ของผู้จำหน่ายเพิ่มเติม เช่น Juniper Contrail หรือ Nokia Nuage OVS จะเป็นส่วนประกอบเครือข่ายหลักของเครือข่ายคลาวด์ และเมื่อใช้ร่วมกับ iptables, conntrack, เนมสเปซ จะทำให้คุณสามารถจัดระเบียบเครือข่ายโอเวอร์เลย์หลายผู้เช่าเต็มรูปแบบได้ โดยปกติแล้ว ส่วนประกอบนี้สามารถถูกแทนที่ได้ ตัวอย่างเช่น เมื่อใช้โซลูชัน SDN ที่เป็นกรรมสิทธิ์ของบริษัทอื่น (ผู้จำหน่าย)

OVS เป็นสวิตช์ซอฟต์แวร์โอเพ่นซอร์สที่ออกแบบมาเพื่อใช้ในสภาพแวดล้อมเสมือนจริงในฐานะตัวส่งต่อการรับส่งข้อมูลเสมือน

ในขณะนี้ OVS มีฟังก์ชันการทำงานที่เหมาะสมมาก ซึ่งรวมถึงเทคโนโลยีต่างๆ เช่น QoS, LACP, VLAN, VxLAN, GENEVE, OpenFlow, DPDK เป็นต้น

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

มีองค์ประกอบสำคัญสามประการของ OVS ที่คุณต้องระวัง:

• โมดูลเคอร์เนล — ส่วนประกอบที่อยู่ในพื้นที่เคอร์เนลที่ประมวลผลการรับส่งข้อมูลตามกฎที่ได้รับจากองค์ประกอบควบคุม
• vSwitch daemon (ovs-vswitchd) เป็นกระบวนการที่เปิดตัวในพื้นที่ผู้ใช้ที่รับผิดชอบในการเขียนโปรแกรมโมดูลเคอร์เนล - นั่นคือมันแสดงถึงตรรกะของการทำงานของสวิตช์โดยตรง
• เซิร์ฟเวอร์ฐานข้อมูล - ฐานข้อมูลท้องถิ่นที่อยู่ในแต่ละโฮสต์ที่ใช้งาน OVS ซึ่งจัดเก็บการกำหนดค่าไว้ ตัวควบคุม SDN สามารถสื่อสารผ่านโมดูลนี้โดยใช้โปรโตคอล OVSDB

ทั้งหมดนี้มาพร้อมกับชุดยูทิลิตี้การวินิจฉัยและการจัดการเช่น ovs-vsctl, ovs-appctl, ovs-ofctl เป็นต้น

ปัจจุบัน OpenStack ถูกใช้อย่างกว้างขวางโดยผู้ให้บริการโทรคมนาคมเพื่อย้ายฟังก์ชั่นเครือข่ายเช่น EPC, SBC, HLR เป็นต้น ฟังก์ชั่นบางอย่างสามารถใช้งานได้โดยไม่มีปัญหากับ OVS ตามที่เป็นอยู่ แต่ตัวอย่างเช่น EPC ประมวลผลการรับส่งข้อมูลของสมาชิก - จากนั้นมันจะผ่านไป ปริมาณการรับส่งข้อมูลจำนวนมาก (ขณะนี้ปริมาณการรับส่งข้อมูลสูงถึงหลายร้อยกิกะบิตต่อวินาที) โดยปกติแล้ว การขับเคลื่อนการรับส่งข้อมูลดังกล่าวผ่านพื้นที่เคอร์เนล (เนื่องจากตัวส่งต่อจะอยู่ที่นั่นตามค่าเริ่มต้น) ไม่ใช่ความคิดที่ดีที่สุด ดังนั้น OVS มักจะถูกปรับใช้ทั้งหมดในพื้นที่ผู้ใช้โดยใช้เทคโนโลยีเร่งความเร็ว DPDK เพื่อส่งต่อการรับส่งข้อมูลจาก NIC ไปยังพื้นที่ผู้ใช้โดยข้ามเคอร์เนล

หมายเหตุ: สำหรับระบบคลาวด์ที่ใช้สำหรับฟังก์ชันโทรคมนาคม เป็นไปได้ที่จะส่งออกการรับส่งข้อมูลจากโหนดคอมพิวเตอร์โดยข้าม OVS ไปยังอุปกรณ์สวิตช์โดยตรง กลไก SR-IOV และ Passthrough ใช้เพื่อจุดประสงค์นี้

สิ่งนี้ทำงานอย่างไรบนเลย์เอาต์จริง?

ทีนี้เรามาดูส่วนที่ใช้งานได้จริงแล้วดูว่ามันทำงานอย่างไรในทางปฏิบัติ

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

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

เรามาเริ่มกันตามลำดับ ก่อนอื่นมีทฤษฎีเล็กน้อย เราจะติดตั้ง OpenStack โดยใช้ TripleO (Openstack บน Openstack) สาระสำคัญของ TripleO คือเราติดตั้ง Openstack all-in-one (นั่นคือบนโหนดเดียว) ที่เรียกว่า undercloud จากนั้นใช้ความสามารถของ Openstack ที่ปรับใช้เพื่อติดตั้ง OpenStack ที่มีไว้สำหรับการดำเนินการที่เรียกว่า overcloud Undercloud จะใช้ความสามารถโดยธรรมชาติในการจัดการเซิร์ฟเวอร์ทางกายภาพ (โลหะเปลือย) - โครงการ Ironic - เพื่อจัดเตรียมไฮเปอร์ไวเซอร์ที่จะทำหน้าที่ในการคำนวณ การควบคุม และโหนดการจัดเก็บข้อมูล นั่นคือเราไม่ได้ใช้เครื่องมือของบุคคลที่สามในการปรับใช้ OpenStack - เราปรับใช้ Openstack โดยใช้ Openstack จะมีความชัดเจนมากขึ้นเมื่อการติดตั้งดำเนินไป ดังนั้นเราจะไม่หยุดเพียงแค่นั้นและก้าวไปข้างหน้า

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

หมายเหตุ: เนื่องจากเราจะใช้งานเครื่องเสมือนในสภาพแวดล้อมเสมือนโดยใช้เครื่องเสมือน อันดับแรกเราจำเป็นต้องเปิดใช้งานการจำลองเสมือนแบบซ้อนกัน

คุณสามารถตรวจสอบว่าเปิดใช้งานการจำลองเสมือนแบบซ้อนกันหรือไม่ในลักษณะนี้:

[root@hp-gen9 bormoglotx]# cat /sys/module/kvm_intel/parameters/nested
N
[root@hp-gen9 bormoglotx]# 

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

เราจำเป็นต้องประกอบวงจรต่อไปนี้จากเครื่องเสมือน:

ในกรณีของฉัน เพื่อเชื่อมต่อเครื่องเสมือนที่เป็นส่วนหนึ่งของการติดตั้งในอนาคต (และฉันมี 7 เครื่อง แต่คุณสามารถเข้าถึงได้ด้วย 4 เครื่องหากคุณมีทรัพยากรไม่มาก) ฉันใช้ OpenvSwitch ฉันสร้างสะพาน ovs หนึ่งตัวและเชื่อมต่อเครื่องเสมือนเข้ากับมันผ่านกลุ่มพอร์ต เมื่อต้องการทำเช่นนี้ ฉันได้สร้างไฟล์ xml ดังนี้:

[root@hp-gen9 ~]# virsh net-dumpxml ovs-network-1        
<network>
  <name>ovs-network-1</name>
  <uuid>7a2e7de7-fc16-4e00-b1ed-4d190133af67</uuid>
  <forward mode='bridge'/>
  <bridge name='ovs-br1'/>
  <virtualport type='openvswitch'/>
  <portgroup name='trunk-1'>
    <vlan trunk='yes'>
      <tag id='100'/>
      <tag id='101'/>
      <tag id='102'/>
    </vlan>
  </portgroup>
  <portgroup name='access-100'>
    <vlan>
      <tag id='100'/>
    </vlan>
  </portgroup>
  <portgroup name='access-101'>
    <vlan>
      <tag id='101'/>
    </vlan>
  </portgroup>
</network>

มีการประกาศกลุ่มพอร์ตสามกลุ่มที่นี่ - สองการเข้าถึงและหนึ่ง trunk (ส่วนหลังจำเป็นสำหรับเซิร์ฟเวอร์ DNS แต่คุณสามารถทำได้โดยไม่ต้องใช้มันหรือติดตั้งบนเครื่องโฮสต์ - แล้วแต่สะดวกสำหรับคุณ) ต่อไป เมื่อใช้เทมเพลตนี้ เราจะประกาศของเราผ่าน virsh net-define:

virsh net-define ovs-network-1.xml 
virsh net-start ovs-network-1 
virsh net-autostart ovs-network-1 

ตอนนี้เราแก้ไขการกำหนดค่าพอร์ตไฮเปอร์ไวเซอร์:

[root@hp-gen9 ~]# cat /etc/sysconfig/network-scripts/ifcfg-ens1f0   
TYPE=Ethernet
NAME=ens1f0
DEVICE=ens1f0
TYPE=OVSPort
DEVICETYPE=ovs
OVS_BRIDGE=ovs-br1
ONBOOT=yes
OVS_OPTIONS="trunk=100,101,102"
[root@hp-gen9 ~]
[root@hp-gen9 ~]# cat /etc/sysconfig/network-scripts/ifcfg-ovs-br1 
DEVICE=ovs-br1
DEVICETYPE=ovs
TYPE=OVSBridge
BOOTPROTO=static
ONBOOT=yes
IPADDR=192.168.255.200
PREFIX=24
[root@hp-gen9 ~]# 

หมายเหตุ: ในสถานการณ์นี้ จะไม่สามารถเข้าถึงที่อยู่ในพอร์ต ovs-br1 ได้เนื่องจากไม่มีแท็ก vlan ในการแก้ไขปัญหานี้ คุณจะต้องออกคำสั่ง sudo ovs-vsctl set port ovs-br1 tag=100 อย่างไรก็ตามหลังจากรีบูตแท็กนี้จะหายไป (ถ้าใครรู้วิธีทำให้มันคงอยู่กับที่ฉันจะขอบคุณมาก) แต่สิ่งนี้ไม่สำคัญนัก เนื่องจากเราต้องการเพียงที่อยู่นี้ระหว่างการติดตั้ง และจะไม่ต้องใช้เมื่อ OpenStack ถูกปรับใช้อย่างสมบูรณ์

ต่อไป เราจะสร้างเครื่องอันเดอร์คลาวด์:

virt-install  -n undercloud --description "undercloud"  --os-type=Linux  --os-variant=centos7.0  --ram=8192  --vcpus=8  --disk path=/var/lib/libvirt/images/undercloud.qcow2,bus=virtio,size=40,format=qcow2 --network network:ovs-network-1,model=virtio,portgroup=access-100 --network network:ovs-network-1,model=virtio,portgroup=access-101 --graphics none  --location /var/lib/libvirt/boot/CentOS-7-x86_64-Minimal-2003.iso --extra-args console=ttyS0

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

หลังจากติดตั้งสำเร็จ คุณควรมีเครื่องเสมือนที่คุณสามารถติดตั้งอันเดอร์คลาวด์ได้

[root@hp-gen9 bormoglotx]# virsh list
 Id    Name                           State
----------------------------------------------------
 6     dns-server                     running
 62    undercloud                     running

ขั้นแรก ติดตั้งเครื่องมือที่จำเป็นสำหรับกระบวนการติดตั้ง:

sudo yum update -y
sudo yum install -y net-tools
sudo yum install -y wget
sudo yum install -y ipmitool

การติดตั้งอันเดอร์คลาวด์

เราสร้างผู้ใช้สแต็ก ตั้งรหัสผ่าน เพิ่มลงใน sudoer และให้ความสามารถในการรันคำสั่งรูทผ่าน sudo โดยไม่ต้องป้อนรหัสผ่าน:

useradd stack
passwd stack

echo “stack ALL=(root) NOPASSWD:ALL” > /etc/sudoers.d/stack
chmod 0440 /etc/sudoers.d/stack

ตอนนี้เราระบุชื่ออันเดอร์คลาวด์แบบเต็มในไฟล์โฮสต์:

vi /etc/hosts

127.0.0.1   undercloud.openstack.rnd localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6

ต่อไป เราจะเพิ่มพื้นที่เก็บข้อมูลและติดตั้งซอฟต์แวร์ที่เราต้องการ:

sudo yum install -y https://trunk.rdoproject.org/centos7/current/python2-tripleo-repos-0.0.1-0.20200409224957.8bac392.el7.noarch.rpm
sudo -E tripleo-repos -b queens current
sudo -E tripleo-repos -b queens current ceph
sudo yum install -y python-tripleoclient
sudo yum install -y ceph-ansible

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

จากนั้น คัดลอกไฟล์การกำหนดค่า undercloud ไปยังสแต็กโฮมไดเร็กตอรี่ของผู้ใช้:

cp /usr/share/instack-undercloud/undercloud.conf.sample ~/undercloud.conf

ตอนนี้เราจำเป็นต้องแก้ไขไฟล์นี้โดยปรับให้เข้ากับการติดตั้งของเรา

คุณต้องเพิ่มบรรทัดเหล่านี้ที่จุดเริ่มต้นของไฟล์:

vi undercloud.conf
[DEFAULT]
undercloud_hostname = undercloud.openstack.rnd
local_ip = 192.168.255.1/24
network_gateway = 192.168.255.1
undercloud_public_host = 192.168.255.2
undercloud_admin_host = 192.168.255.3
undercloud_nameservers = 192.168.255.253
generate_service_certificate = false
local_interface = eth0
local_mtu = 1450
network_cidr = 192.168.255.0/24
masquerade = true
masquerade_network = 192.168.255.0/24
dhcp_start = 192.168.255.11
dhcp_end = 192.168.255.50
inspection_iprange = 192.168.255.51,192.168.255.100
scheduler_max_attempts = 10

มาดูการตั้งค่ากัน:

undercloud_hostname — ชื่อเต็มของเซิร์ฟเวอร์ undercloud จะต้องตรงกับรายการบนเซิร์ฟเวอร์ DNS

local_ip — ที่อยู่ undercloud ท้องถิ่นเพื่อการจัดเตรียมเครือข่าย

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

undercloud_public_host — ที่อยู่ API ภายนอก จะมีการกำหนดที่อยู่ฟรีจากเครือข่ายการจัดเตรียม

undercloud_admin_host ที่อยู่ API ภายใน จะมีการกำหนดที่อยู่ฟรีจากเครือข่ายการจัดเตรียม

undercloud_nameservers - เซิร์ฟเวอร์ DNS

Generate_service_certificate - บรรทัดนี้มีความสำคัญมากในตัวอย่างปัจจุบัน เพราะหากคุณไม่ได้ตั้งค่าเป็น false คุณจะได้รับข้อผิดพลาดระหว่างการติดตั้ง ปัญหาดังกล่าวอธิบายไว้ใน Red Hat bug tracker

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

local_mtu - มธ. เนื่องจากเรามีห้องปฏิบัติการทดสอบและฉันมี MTU 1500 บนพอร์ตสวิตช์ OVS จึงจำเป็นต้องตั้งค่าเป็น 1450 เพื่อให้แพ็กเก็ตที่ห่อหุ้มใน VxLAN สามารถผ่านไปได้

network_cidr – เครือข่ายการจัดเตรียม

สวมหน้ากาก — การใช้ NAT เพื่อเข้าถึงเครือข่ายภายนอก

masquerade_network - เครือข่ายที่จะ NATed

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

dhcp_end — ที่อยู่สุดท้ายของกลุ่มที่อยู่ซึ่งที่อยู่จะถูกกำหนดให้กับโหนดในระหว่างการปรับใช้แบบโอเวอร์คลาวด์

การตรวจสอบ_iprange - กลุ่มที่อยู่ที่จำเป็นสำหรับการวิปัสสนา (ไม่ควรทับซ้อนกับกลุ่มข้างต้น)

scheduler_max_attempts — จำนวนความพยายามสูงสุดในการติดตั้ง overcloud (ต้องมากกว่าหรือเท่ากับจำนวนโหนด)

หลังจากอธิบายไฟล์แล้ว คุณสามารถออกคำสั่งเพื่อปรับใช้ undercloud ได้:

openstack undercloud install

ขั้นตอนนี้ใช้เวลาประมาณ 10 ถึง 30 นาที ขึ้นอยู่กับเตารีดของคุณ ในที่สุดคุณควรเห็นผลลัพธ์ดังนี้:

vi undercloud.conf
2020-08-13 23:13:12,668 INFO: 
#############################################################################
Undercloud install complete.

The file containing this installation's passwords is at
/home/stack/undercloud-passwords.conf.

There is also a stackrc file at /home/stack/stackrc.

These files are needed to interact with the OpenStack services, and should be
secured.

#############################################################################

ผลลัพธ์นี้แจ้งว่าคุณติดตั้ง Undercloud สำเร็จแล้ว และตอนนี้คุณสามารถตรวจสอบสถานะของ Undercloud และดำเนินการติดตั้ง Overcloud ต่อไปได้

หากคุณดูที่เอาต์พุต ifconfig คุณจะเห็นว่าอินเทอร์เฟซบริดจ์ใหม่ปรากฏขึ้น

[stack@undercloud ~]$ ifconfig
br-ctlplane: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1450
        inet 192.168.255.1  netmask 255.255.255.0  broadcast 192.168.255.255
        inet6 fe80::5054:ff:fe2c:89e  prefixlen 64  scopeid 0x20<link>
        ether 52:54:00:2c:08:9e  txqueuelen 1000  (Ethernet)
        RX packets 14  bytes 1095 (1.0 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 20  bytes 1292 (1.2 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

ขณะนี้การใช้งาน Overcloud จะดำเนินการผ่านอินเทอร์เฟซนี้

จากผลลัพธ์ด้านล่าง คุณจะเห็นว่าเรามีบริการทั้งหมดบนโหนดเดียว:

(undercloud) [stack@undercloud ~]$ openstack host list
+--------------------------+-----------+----------+
| Host Name                | Service   | Zone     |
+--------------------------+-----------+----------+
| undercloud.openstack.rnd | conductor | internal |
| undercloud.openstack.rnd | scheduler | internal |
| undercloud.openstack.rnd | compute   | nova     |
+--------------------------+-----------+----------+

ด้านล่างนี้คือการกำหนดค่าของส่วนเครือข่าย undercloud:

(undercloud) [stack@undercloud ~]$ python -m json.tool /etc/os-net-config/config.json 
{
    "network_config": [
        {
            "addresses": [
                {
                    "ip_netmask": "192.168.255.1/24"
                }
            ],
            "members": [
                {
                    "dns_servers": [
                        "192.168.255.253"
                    ],
                    "mtu": 1450,
                    "name": "eth0",
                    "primary": "true",
                    "type": "interface"
                }
            ],
            "mtu": 1450,
            "name": "br-ctlplane",
            "ovs_extra": [
                "br-set-external-id br-ctlplane bridge-id br-ctlplane"
            ],
            "routes": [],
            "type": "ovs_bridge"
        }
    ]
}
(undercloud) [stack@undercloud ~]$

การติดตั้งโอเวอร์คลาวด์

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

ไปที่โฟลเดอร์ที่มีดิสก์ของเครื่องเสมือนของเราและสร้างดิสก์ตามขนาดที่ต้องการ:

cd /var/lib/libvirt/images/
qemu-img create -f qcow2 -o preallocation=metadata control-1.qcow2 60G
qemu-img create -f qcow2 -o preallocation=metadata compute-1.qcow2 60G
qemu-img create -f qcow2 -o preallocation=metadata compute-2.qcow2 60G
qemu-img create -f qcow2 -o preallocation=metadata storage-1.qcow2 160G
qemu-img create -f qcow2 -o preallocation=metadata storage-2.qcow2 160G

เนื่องจากเราทำงานในฐานะรูท เราจึงต้องเปลี่ยนเจ้าของดิสก์เหล่านี้ เพื่อไม่ให้เกิดปัญหากับสิทธิ์:

[root@hp-gen9 images]# ls -lh
total 5.8G
drwxr-xr-x. 2 qemu qemu 4.0K Aug 13 16:15 backups
-rw-r--r--. 1 root root  61G Aug 14 03:07 compute-1.qcow2
-rw-r--r--. 1 root root  61G Aug 14 03:07 compute-2.qcow2
-rw-r--r--. 1 root root  61G Aug 14 03:07 control-1.qcow2
-rw-------. 1 qemu qemu  41G Aug 14 03:03 dns-server.qcow2
-rw-r--r--. 1 root root 161G Aug 14 03:07 storage-1.qcow2
-rw-r--r--. 1 root root 161G Aug 14 03:07 storage-2.qcow2
-rw-------. 1 qemu qemu  41G Aug 14 03:07 undercloud.qcow2
[root@hp-gen9 images]# 
[root@hp-gen9 images]# 
[root@hp-gen9 images]# chown qemu:qemu /var/lib/libvirt/images/*qcow2
[root@hp-gen9 images]# ls -lh
total 5.8G
drwxr-xr-x. 2 qemu qemu 4.0K Aug 13 16:15 backups
-rw-r--r--. 1 qemu qemu  61G Aug 14 03:07 compute-1.qcow2
-rw-r--r--. 1 qemu qemu  61G Aug 14 03:07 compute-2.qcow2
-rw-r--r--. 1 qemu qemu  61G Aug 14 03:07 control-1.qcow2
-rw-------. 1 qemu qemu  41G Aug 14 03:03 dns-server.qcow2
-rw-r--r--. 1 qemu qemu 161G Aug 14 03:07 storage-1.qcow2
-rw-r--r--. 1 qemu qemu 161G Aug 14 03:07 storage-2.qcow2
-rw-------. 1 qemu qemu  41G Aug 14 03:08 undercloud.qcow2
[root@hp-gen9 images]# 

หมายเหตุ: หากคุณไม่ได้วางแผนที่จะติดตั้ง ceph เพื่อศึกษาคำสั่งนั้นจะไม่สร้างอย่างน้อย 3 โหนดที่มีดิสก์อย่างน้อยสองดิสก์ แต่ในเทมเพลตระบุว่าจะใช้ดิสก์เสมือน vda, vdb ฯลฯ

เยี่ยมเลย ตอนนี้เราต้องกำหนดเครื่องจักรเหล่านี้ทั้งหมด:

virt-install --name control-1 --ram 32768 --vcpus 8 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/control-1.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc  --network network:ovs-network-1,model=virtio,portgroup=access-100 --network network:ovs-network-1,model=virtio,portgroup=trunk-1 --dry-run --print-xml > /tmp/control-1.xml  

virt-install --name storage-1 --ram 16384 --vcpus 4 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/storage-1.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc  --network network:ovs-network-1,model=virtio,portgroup=access-100 --dry-run --print-xml > /tmp/storage-1.xml  

virt-install --name storage-2 --ram 16384 --vcpus 4 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/storage-2.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc  --network network:ovs-network-1,model=virtio,portgroup=access-100 --dry-run --print-xml > /tmp/storage-2.xml  

virt-install --name compute-1 --ram 32768 --vcpus 12 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/compute-1.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc  --network network:ovs-network-1,model=virtio,portgroup=access-100 --dry-run --print-xml > /tmp/compute-1.xml  

virt-install --name compute-2 --ram 32768 --vcpus 12 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/compute-2.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc  --network network:ovs-network-1,model=virtio,portgroup=access-100 --dry-run --print-xml > /tmp/compute-2.xml 

ในตอนท้ายจะมีคำสั่ง -print-xml > /tmp/storage-1.xml ซึ่งจะสร้างไฟล์ xml พร้อมคำอธิบายของแต่ละเครื่องในโฟลเดอร์ /tmp/ ถ้าคุณไม่เพิ่มเข้าไป คุณจะไม่ถูก สามารถระบุเครื่องเสมือนได้

ตอนนี้เราต้องกำหนดเครื่องทั้งหมดเหล่านี้ด้วย virsh:

virsh define --file /tmp/control-1.xml
virsh define --file /tmp/compute-1.xml
virsh define --file /tmp/compute-2.xml
virsh define --file /tmp/storage-1.xml
virsh define --file /tmp/storage-2.xml

[root@hp-gen9 ~]# virsh list --all
 Id    Name                           State
----------------------------------------------------
 6     dns-server                     running
 64    undercloud                     running
 -     compute-1                      shut off
 -     compute-2                      shut off
 -     control-1                      shut off
 -     storage-1                      shut off
 -     storage-2                      shut off

[root@hp-gen9 ~]#

ตอนนี้มีความแตกต่างเล็กน้อย - tripleO ใช้ IPMI เพื่อจัดการเซิร์ฟเวอร์ระหว่างการติดตั้งและการวิปัสสนา

วิปัสสนาเป็นกระบวนการตรวจสอบฮาร์ดแวร์เพื่อให้ได้พารามิเตอร์ที่จำเป็นสำหรับการจัดเตรียมโหนดเพิ่มเติม วิปัสสนาดำเนินการโดยใช้แดกดันซึ่งเป็นบริการที่ออกแบบมาเพื่อทำงานกับเซิร์ฟเวอร์โลหะเปลือย

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

ติดตั้ง vbmc:

yum install yum install python2-virtualbmc

หากระบบปฏิบัติการของคุณไม่พบแพ็คเกจ ให้เพิ่มพื้นที่เก็บข้อมูล:

yum install -y https://www.rdoproject.org/repos/rdo-release.rpm

ตอนนี้เราตั้งค่ายูทิลิตี้แล้ว ทุกสิ่งที่นี่ซ้ำซากจนน่าอับอาย ตอนนี้มีเหตุผลแล้วว่าไม่มีเซิร์ฟเวอร์อยู่ในรายการ vbmc

[root@hp-gen9 ~]# vbmc list

[root@hp-gen9 ~]# 

เพื่อให้ปรากฏ จะต้องประกาศด้วยตนเองดังนี้:

[root@hp-gen9 ~]# vbmc add control-1 --port 7001 --username admin --password admin
[root@hp-gen9 ~]# vbmc add storage-1 --port 7002 --username admin --password admin
[root@hp-gen9 ~]# vbmc add storage-2 --port 7003 --username admin --password admin
[root@hp-gen9 ~]# vbmc add compute-1 --port 7004 --username admin --password admin
[root@hp-gen9 ~]# vbmc add compute-2 --port 7005 --username admin --password admin
[root@hp-gen9 ~]#
[root@hp-gen9 ~]# vbmc list
+-------------+--------+---------+------+
| Domain name | Status | Address | Port |
+-------------+--------+---------+------+
| compute-1   | down   | ::      | 7004 |
| compute-2   | down   | ::      | 7005 |
| control-1   | down   | ::      | 7001 |
| storage-1   | down   | ::      | 7002 |
| storage-2   | down   | ::      | 7003 |
+-------------+--------+---------+------+
[root@hp-gen9 ~]#

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

[root@hp-gen9 ~]# vbmc start control-1
2020-08-14 03:15:57,826.826 13149 INFO VirtualBMC [-] Started vBMC instance for domain control-1
[root@hp-gen9 ~]# vbmc start storage-1 
2020-08-14 03:15:58,316.316 13149 INFO VirtualBMC [-] Started vBMC instance for domain storage-1
[root@hp-gen9 ~]# vbmc start storage-2
2020-08-14 03:15:58,851.851 13149 INFO VirtualBMC [-] Started vBMC instance for domain storage-2
[root@hp-gen9 ~]# vbmc start compute-1
2020-08-14 03:15:59,307.307 13149 INFO VirtualBMC [-] Started vBMC instance for domain compute-1
[root@hp-gen9 ~]# vbmc start compute-2
2020-08-14 03:15:59,712.712 13149 INFO VirtualBMC [-] Started vBMC instance for domain compute-2
[root@hp-gen9 ~]# 
[root@hp-gen9 ~]# 
[root@hp-gen9 ~]# vbmc list
+-------------+---------+---------+------+
| Domain name | Status  | Address | Port |
+-------------+---------+---------+------+
| compute-1   | running | ::      | 7004 |
| compute-2   | running | ::      | 7005 |
| control-1   | running | ::      | 7001 |
| storage-1   | running | ::      | 7002 |
| storage-2   | running | ::      | 7003 |
+-------------+---------+---------+------+
[root@hp-gen9 ~]#

และสัมผัสสุดท้าย - คุณต้องแก้ไขกฎไฟร์วอลล์ (หรือปิดการใช้งานทั้งหมด):

firewall-cmd --zone=public --add-port=7001/udp --permanent
firewall-cmd --zone=public --add-port=7002/udp --permanent
firewall-cmd --zone=public --add-port=7003/udp --permanent
firewall-cmd --zone=public --add-port=7004/udp --permanent
firewall-cmd --zone=public --add-port=7005/udp --permanent
firewall-cmd --reload

ตอนนี้ไปที่ undercloud แล้วตรวจสอบว่าทุกอย่างทำงานได้ ที่อยู่ของเครื่องโฮสต์คือ 192.168.255.200 บน undercloud เราได้เพิ่มแพ็คเกจ ipmitool ที่จำเป็นระหว่างการเตรียมการสำหรับการปรับใช้:

[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power status          
Chassis Power is off
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power on
Chassis Power Control: Up/On
[stack@undercloud ~]$ 

[root@hp-gen9 ~]# virsh list 
 Id    Name                           State
----------------------------------------------------
 6     dns-server                     running
 64    undercloud                     running
 65    control-1                      running

อย่างที่คุณเห็น เราได้เปิดตัวโหนดควบคุมผ่าน vbmc สำเร็จแล้ว ตอนนี้เรามาปิดมันแล้วไปต่อ:

[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power off
Chassis Power Control: Down/Off
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power status
Chassis Power is off
[stack@undercloud ~]$ 

[root@hp-gen9 ~]# virsh list --all
 Id    Name                           State
----------------------------------------------------
 6     dns-server                     running
 64    undercloud                     running
 -     compute-1                      shut off
 -     compute-2                      shut off
 -     control-1                      shut off
 -     storage-1                      shut off
 -     storage-2                      shut off

[root@hp-gen9 ~]#

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

[root@hp-gen9 ~]# virsh domiflist --domain control-1 
Interface  Type       Source     Model       MAC
-------------------------------------------------------
-          network    ovs-network-1 virtio      52:54:00:20:a2:2f
-          network    ovs-network-1 virtio      52:54:00:3f:87:9f

[root@hp-gen9 ~]# virsh domiflist --domain compute-1
Interface  Type       Source     Model       MAC
-------------------------------------------------------
-          network    ovs-network-1 virtio      52:54:00:98:e9:d6

[root@hp-gen9 ~]# virsh domiflist --domain compute-2
Interface  Type       Source     Model       MAC
-------------------------------------------------------
-          network    ovs-network-1 virtio      52:54:00:6a:ea:be

[root@hp-gen9 ~]# virsh domiflist --domain storage-1
Interface  Type       Source     Model       MAC
-------------------------------------------------------
-          network    ovs-network-1 virtio      52:54:00:79:0b:cb

[root@hp-gen9 ~]# virsh domiflist --domain storage-2
Interface  Type       Source     Model       MAC
-------------------------------------------------------
-          network    ovs-network-1 virtio      52:54:00:a7:fe:27

หมายเหตุ: โหนดควบคุมมีสองอินเทอร์เฟซ แต่ในกรณีนี้ไม่สำคัญ ในการติดตั้งนี้จะเพียงพอสำหรับเรา

ตอนนี้เราเตรียมไฟล์ json เราจำเป็นต้องระบุที่อยู่ป๊อปปี้ของพอร์ตที่จะดำเนินการจัดเตรียมพารามิเตอร์ของโหนดตั้งชื่อและระบุวิธีรับ ipmi:

{
    "nodes":[
        {
            "mac":[
                "52:54:00:20:a2:2f"
            ],
            "cpu":"8",
            "memory":"32768",
            "disk":"60",
            "arch":"x86_64",
            "name":"control-1",
            "pm_type":"pxe_ipmitool",
            "pm_user":"admin",
            "pm_password":"admin",
            "pm_addr":"192.168.255.200",
            "pm_port":"7001"
        },
        {
            "mac":[
                "52:54:00:79:0b:cb"
            ],
            "cpu":"4",
            "memory":"16384",
            "disk":"160",
            "arch":"x86_64",
            "name":"storage-1",
            "pm_type":"pxe_ipmitool",
            "pm_user":"admin",
            "pm_password":"admin",
            "pm_addr":"192.168.255.200",
            "pm_port":"7002"
        },
        {
            "mac":[
                "52:54:00:a7:fe:27"
            ],
            "cpu":"4",
            "memory":"16384",
            "disk":"160",
            "arch":"x86_64",
            "name":"storage-2",
            "pm_type":"pxe_ipmitool",
            "pm_user":"admin",
            "pm_password":"admin",
            "pm_addr":"192.168.255.200",
            "pm_port":"7003"
        },
        {
            "mac":[
                "52:54:00:98:e9:d6"
            ],
            "cpu":"12",
            "memory":"32768",
            "disk":"60",
            "arch":"x86_64",
            "name":"compute-1",
            "pm_type":"pxe_ipmitool",
            "pm_user":"admin",
            "pm_password":"admin",
            "pm_addr":"192.168.255.200",
            "pm_port":"7004"
        },
        {
            "mac":[
                "52:54:00:6a:ea:be"
            ],
            "cpu":"12",
            "memory":"32768",
            "disk":"60",
            "arch":"x86_64",
            "name":"compute-2",
            "pm_type":"pxe_ipmitool",
            "pm_user":"admin",
            "pm_password":"admin",
            "pm_addr":"192.168.255.200",
            "pm_port":"7005"
        }
    ]
}

ตอนนี้เราต้องเตรียมภาพที่น่าขัน หากต้องการทำสิ่งนี้ ให้ดาวน์โหลดผ่าน wget และติดตั้ง:

(undercloud) [stack@undercloud ~]$ sudo wget https://images.rdoproject.org/queens/delorean/current-tripleo-rdo/overcloud-full.tar --no-check-certificate
(undercloud) [stack@undercloud ~]$ sudo wget https://images.rdoproject.org/queens/delorean/current-tripleo-rdo/ironic-python-agent.tar --no-check-certificate
(undercloud) [stack@undercloud ~]$ ls -lh
total 1.9G
-rw-r--r--. 1 stack stack 447M Aug 14 10:26 ironic-python-agent.tar
-rw-r--r--. 1 stack stack 1.5G Aug 14 10:26 overcloud-full.tar
-rw-------. 1 stack stack  916 Aug 13 23:10 stackrc
-rw-r--r--. 1 stack stack  15K Aug 13 22:50 undercloud.conf
-rw-------. 1 stack stack 2.0K Aug 13 22:50 undercloud-passwords.conf
(undercloud) [stack@undercloud ~]$ mkdir images/
(undercloud) [stack@undercloud ~]$ tar -xpvf ironic-python-agent.tar -C ~/images/
ironic-python-agent.initramfs
ironic-python-agent.kernel
(undercloud) [stack@undercloud ~]$ tar -xpvf overcloud-full.tar -C ~/images/                       
overcloud-full.qcow2
overcloud-full.initrd
overcloud-full.vmlinuz
(undercloud) [stack@undercloud ~]$ 
(undercloud) [stack@undercloud ~]$ ls -lh images/
total 1.9G
-rw-rw-r--. 1 stack stack 441M Aug 12 17:24 ironic-python-agent.initramfs
-rwxr-xr-x. 1 stack stack 6.5M Aug 12 17:24 ironic-python-agent.kernel
-rw-r--r--. 1 stack stack  53M Aug 12 17:14 overcloud-full.initrd
-rw-r--r--. 1 stack stack 1.4G Aug 12 17:18 overcloud-full.qcow2
-rwxr-xr-x. 1 stack stack 6.5M Aug 12 17:14 overcloud-full.vmlinuz
(undercloud) [stack@undercloud ~]$

การอัปโหลดภาพไปยังอันเดอร์คลาวด์:

(undercloud) [stack@undercloud ~]$ openstack overcloud image upload --image-path ~/images/
Image "overcloud-full-vmlinuz" was uploaded.
+--------------------------------------+------------------------+-------------+---------+--------+
|                  ID                  |          Name          | Disk Format |   Size  | Status |
+--------------------------------------+------------------------+-------------+---------+--------+
| c2553770-3e0f-4750-b46b-138855b5c385 | overcloud-full-vmlinuz |     aki     | 6761064 | active |
+--------------------------------------+------------------------+-------------+---------+--------+
Image "overcloud-full-initrd" was uploaded.
+--------------------------------------+-----------------------+-------------+----------+--------+
|                  ID                  |          Name         | Disk Format |   Size   | Status |
+--------------------------------------+-----------------------+-------------+----------+--------+
| 949984e0-4932-4e71-af43-d67a38c3dc89 | overcloud-full-initrd |     ari     | 55183045 | active |
+--------------------------------------+-----------------------+-------------+----------+--------+
Image "overcloud-full" was uploaded.
+--------------------------------------+----------------+-------------+------------+--------+
|                  ID                  |      Name      | Disk Format |    Size    | Status |
+--------------------------------------+----------------+-------------+------------+--------+
| a2f2096d-c9d7-429a-b866-c7543c02a380 | overcloud-full |    qcow2    | 1487475712 | active |
+--------------------------------------+----------------+-------------+------------+--------+
Image "bm-deploy-kernel" was uploaded.
+--------------------------------------+------------------+-------------+---------+--------+
|                  ID                  |       Name       | Disk Format |   Size  | Status |
+--------------------------------------+------------------+-------------+---------+--------+
| e413aa78-e38f-404c-bbaf-93e582a8e67f | bm-deploy-kernel |     aki     | 6761064 | active |
+--------------------------------------+------------------+-------------+---------+--------+
Image "bm-deploy-ramdisk" was uploaded.
+--------------------------------------+-------------------+-------------+-----------+--------+
|                  ID                  |        Name       | Disk Format |    Size   | Status |
+--------------------------------------+-------------------+-------------+-----------+--------+
| 5cf3aba4-0e50-45d3-929f-27f025dd6ce3 | bm-deploy-ramdisk |     ari     | 461759376 | active |
+--------------------------------------+-------------------+-------------+-----------+--------+
(undercloud) [stack@undercloud ~]$

กำลังตรวจสอบว่าโหลดรูปภาพทั้งหมดแล้ว

(undercloud) [stack@undercloud ~]$  openstack image list
+--------------------------------------+------------------------+--------+
| ID                                   | Name                   | Status |
+--------------------------------------+------------------------+--------+
| e413aa78-e38f-404c-bbaf-93e582a8e67f | bm-deploy-kernel       | active |
| 5cf3aba4-0e50-45d3-929f-27f025dd6ce3 | bm-deploy-ramdisk      | active |
| a2f2096d-c9d7-429a-b866-c7543c02a380 | overcloud-full         | active |
| 949984e0-4932-4e71-af43-d67a38c3dc89 | overcloud-full-initrd  | active |
| c2553770-3e0f-4750-b46b-138855b5c385 | overcloud-full-vmlinuz | active |
+--------------------------------------+------------------------+--------+
(undercloud) [stack@undercloud ~]$

อีกประการหนึ่ง - คุณต้องเพิ่มเซิร์ฟเวอร์ DNS:

(undercloud) [stack@undercloud ~]$ openstack subnet list
+--------------------------------------+-----------------+--------------------------------------+------------------+
| ID                                   | Name            | Network                              | Subnet           |
+--------------------------------------+-----------------+--------------------------------------+------------------+
| f45dea46-4066-42aa-a3c4-6f84b8120cab | ctlplane-subnet | 6ca013dc-41c2-42d8-9d69-542afad53392 | 192.168.255.0/24 |
+--------------------------------------+-----------------+--------------------------------------+------------------+
(undercloud) [stack@undercloud ~]$ openstack subnet show f45dea46-4066-42aa-a3c4-6f84b8120cab
+-------------------+-----------------------------------------------------------+
| Field             | Value                                                     |
+-------------------+-----------------------------------------------------------+
| allocation_pools  | 192.168.255.11-192.168.255.50                             |
| cidr              | 192.168.255.0/24                                          |
| created_at        | 2020-08-13T20:10:37Z                                      |
| description       |                                                           |
| dns_nameservers   |                                                           |
| enable_dhcp       | True                                                      |
| gateway_ip        | 192.168.255.1                                             |
| host_routes       | destination='169.254.169.254/32', gateway='192.168.255.1' |
| id                | f45dea46-4066-42aa-a3c4-6f84b8120cab                      |
| ip_version        | 4                                                         |
| ipv6_address_mode | None                                                      |
| ipv6_ra_mode      | None                                                      |
| name              | ctlplane-subnet                                           |
| network_id        | 6ca013dc-41c2-42d8-9d69-542afad53392                      |
| prefix_length     | None                                                      |
| project_id        | a844ccfcdb2745b198dde3e1b28c40a3                          |
| revision_number   | 0                                                         |
| segment_id        | None                                                      |
| service_types     |                                                           |
| subnetpool_id     | None                                                      |
| tags              |                                                           |
| updated_at        | 2020-08-13T20:10:37Z                                      |
+-------------------+-----------------------------------------------------------+
(undercloud) [stack@undercloud ~]$ 
(undercloud) [stack@undercloud ~]$ neutron subnet-update f45dea46-4066-42aa-a3c4-6f84b8120cab --dns-nameserver 192.168.255.253                                    
neutron CLI is deprecated and will be removed in the future. Use openstack CLI instead.
Updated subnet: f45dea46-4066-42aa-a3c4-6f84b8120cab
(undercloud) [stack@undercloud ~]$

ตอนนี้เราสามารถให้คำสั่งสำหรับการวิปัสสนาได้:

(undercloud) [stack@undercloud ~]$ openstack overcloud node import --introspect --provide inspection.json 
Started Mistral Workflow tripleo.baremetal.v1.register_or_update. Execution ID: d57456a3-d8ed-479c-9a90-dff7c752d0ec
Waiting for messages on queue 'tripleo' with no timeout.


5 node(s) successfully moved to the "manageable" state.
Successfully registered node UUID b4b2cf4a-b7ca-4095-af13-cc83be21c4f5
Successfully registered node UUID b89a72a3-6bb7-429a-93bc-48393d225838
Successfully registered node UUID 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e
Successfully registered node UUID bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8
Successfully registered node UUID 766ab623-464c-423d-a529-d9afb69d1167
Waiting for introspection to finish...
Started Mistral Workflow tripleo.baremetal.v1.introspect. Execution ID: 6b4d08ae-94c3-4a10-ab63-7634ec198a79
Waiting for messages on queue 'tripleo' with no timeout.
Introspection of node b89a72a3-6bb7-429a-93bc-48393d225838 completed. Status:SUCCESS. Errors:None
Introspection of node 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e completed. Status:SUCCESS. Errors:None
Introspection of node bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 completed. Status:SUCCESS. Errors:None
Introspection of node 766ab623-464c-423d-a529-d9afb69d1167 completed. Status:SUCCESS. Errors:None
Introspection of node b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 completed. Status:SUCCESS. Errors:None
Successfully introspected 5 node(s).
Started Mistral Workflow tripleo.baremetal.v1.provide. Execution ID: f5594736-edcf-4927-a8a0-2a7bf806a59a
Waiting for messages on queue 'tripleo' with no timeout.
5 node(s) successfully moved to the "available" state.
(undercloud) [stack@undercloud ~]$

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

(undercloud) [stack@undercloud ~]$ openstack baremetal node list
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
| UUID                                 | Name      | Instance UUID | Power State | Provisioning State | Maintenance |
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | control-1 | None          | power off   | available          | False       |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | None          | power off   | available          | False       |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | None          | power off   | available          | False       |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | None          | power off   | available          | False       |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | None          | power off   | available          | False       |
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
(undercloud) [stack@undercloud ~]$ 

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

ต่อไปเราต้องระบุว่าโหนดใดจะทำหน้าที่ใด - นั่นคือระบุโปรไฟล์ที่โหนดจะปรับใช้:

(undercloud) [stack@undercloud ~]$ openstack overcloud profiles list
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| Node UUID                            | Node Name | Provision State | Current Profile | Possible Profiles |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | control-1 | available       | None            |                   |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | available       | None            |                   |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | available       | None            |                   |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | available       | None            |                   |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | available       | None            |                   |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
(undercloud) [stack@undercloud ~]$ openstack flavor list
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
| ID                                   | Name          |  RAM | Disk | Ephemeral | VCPUs | Is Public |
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
| 168af640-7f40-42c7-91b2-989abc5c5d8f | swift-storage | 4096 |   40 |         0 |     1 | True      |
| 52148d1b-492e-48b4-b5fc-772849dd1b78 | baremetal     | 4096 |   40 |         0 |     1 | True      |
| 56e66542-ae60-416d-863e-0cb192d01b09 | control       | 4096 |   40 |         0 |     1 | True      |
| af6796e1-d0c4-4bfe-898c-532be194f7ac | block-storage | 4096 |   40 |         0 |     1 | True      |
| e4d50fdd-0034-446b-b72c-9da19b16c2df | compute       | 4096 |   40 |         0 |     1 | True      |
| fc2e3acf-7fca-4901-9eee-4a4d6ef0265d | ceph-storage  | 4096 |   40 |         0 |     1 | True      |
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
(undercloud) [stack@undercloud ~]$

ระบุโปรไฟล์สำหรับแต่ละโหนด:

openstack baremetal node set --property capabilities='profile:control,boot_option:local' b4b2cf4a-b7ca-4095-af13-cc83be21c4f5
openstack baremetal node set --property capabilities='profile:ceph-storage,boot_option:local' b89a72a3-6bb7-429a-93bc-48393d225838
openstack baremetal node set --property capabilities='profile:ceph-storage,boot_option:local' 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e
openstack baremetal node set --property capabilities='profile:compute,boot_option:local' bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8
openstack baremetal node set --property capabilities='profile:compute,boot_option:local' 766ab623-464c-423d-a529-d9afb69d1167

ตรวจสอบว่าเราทำทุกอย่างถูกต้องแล้ว:

(undercloud) [stack@undercloud ~]$ openstack overcloud profiles list
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| Node UUID                            | Node Name | Provision State | Current Profile | Possible Profiles |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | control-1 | available       | control         |                   |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | available       | ceph-storage    |                   |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | available       | ceph-storage    |                   |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | available       | compute         |                   |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | available       | compute         |                   |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
(undercloud) [stack@undercloud ~]$

หากทุกอย่างถูกต้อง เราจะออกคำสั่งให้ปรับใช้โอเวอร์คลาวด์:

openstack overcloud deploy --templates --control-scale 1 --compute-scale 2  --ceph-storage-scale 2 --control-flavor control --compute-flavor compute  --ceph-storage-flavor ceph-storage --libvirt-type qemu

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

หมายเหตุ: ตัวแปร --libvirt-type qemu จำเป็นในกรณีนี้ เนื่องจากเราจะใช้การจำลองเสมือนแบบซ้อน มิฉะนั้น คุณจะไม่สามารถเรียกใช้เครื่องเสมือนได้

ตอนนี้คุณมีเวลาประมาณหนึ่งชั่วโมงหรืออาจจะมากกว่านั้น (ขึ้นอยู่กับความสามารถของฮาร์ดแวร์) และคุณคงได้แต่หวังว่าหลังจากเวลานี้คุณจะเห็นข้อความต่อไปนี้:

2020-08-14 08:39:21Z [overcloud]: CREATE_COMPLETE  Stack CREATE completed successfully

 Stack overcloud CREATE_COMPLETE 

Host 192.168.255.21 not found in /home/stack/.ssh/known_hosts
Started Mistral Workflow tripleo.deployment.v1.get_horizon_url. Execution ID: fcb996cd-6a19-482b-b755-2ca0c08069a9
Overcloud Endpoint: http://192.168.255.21:5000/
Overcloud Horizon Dashboard URL: http://192.168.255.21:80/dashboard
Overcloud rc file: /home/stack/overcloudrc
Overcloud Deployed
(undercloud) [stack@undercloud ~]$

ตอนนี้คุณมี openstack เวอร์ชันเกือบเต็มซึ่งคุณสามารถศึกษาทดลองและอื่น ๆ ได้

มาตรวจสอบว่าทุกอย่างทำงานอย่างถูกต้อง ในโฮมไดเร็กทอรีสแต็กของผู้ใช้จะมีสองไฟล์ - หนึ่งไฟล์ stackrc (สำหรับการจัดการ undercloud) และไฟล์ที่สอง overcloudrc (สำหรับการจัดการ overcloud) ไฟล์เหล่านี้จะต้องระบุเป็นแหล่งที่มา เนื่องจากมีข้อมูลที่จำเป็นสำหรับการตรวจสอบสิทธิ์

(undercloud) [stack@undercloud ~]$ openstack server list
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
| ID                                   | Name                    | Status | Networks                | Image          | Flavor       |
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
| fd7d36f4-ce87-4b9a-93b0-add2957792de | overcloud-controller-0  | ACTIVE | ctlplane=192.168.255.15 | overcloud-full | control      |
| edc77778-8972-475e-a541-ff40eb944197 | overcloud-novacompute-1 | ACTIVE | ctlplane=192.168.255.26 | overcloud-full | compute      |
| 5448ce01-f05f-47ca-950a-ced14892c0d4 | overcloud-cephstorage-1 | ACTIVE | ctlplane=192.168.255.34 | overcloud-full | ceph-storage |
| ce6d862f-4bdf-4ba3-b711-7217915364d7 | overcloud-novacompute-0 | ACTIVE | ctlplane=192.168.255.19 | overcloud-full | compute      |
| e4507bd5-6f96-4b12-9cc0-6924709da59e | overcloud-cephstorage-0 | ACTIVE | ctlplane=192.168.255.44 | overcloud-full | ceph-storage |
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
(undercloud) [stack@undercloud ~]$ 

(undercloud) [stack@undercloud ~]$ source overcloudrc 
(overcloud) [stack@undercloud ~]$ 
(overcloud) [stack@undercloud ~]$ openstack project list
+----------------------------------+---------+
| ID                               | Name    |
+----------------------------------+---------+
| 4eed7d0f06544625857d51cd77c5bd4c | admin   |
| ee1c68758bde41eaa9912c81dc67dad8 | service |
+----------------------------------+---------+
(overcloud) [stack@undercloud ~]$ 
(overcloud) [stack@undercloud ~]$ 
(overcloud) [stack@undercloud ~]$ openstack network agent list  
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| ID                                   | Agent Type         | Host                                | Availability Zone | Alive | State | Binary                    |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| 10495de9-ba4b-41fe-b30a-b90ec3f8728b | Open vSwitch agent | overcloud-novacompute-1.localdomain | None              | :-)   | UP    | neutron-openvswitch-agent |
| 1515ad4a-5972-46c3-af5f-e5446dff7ac7 | L3 agent           | overcloud-controller-0.localdomain  | nova              | :-)   | UP    | neutron-l3-agent          |
| 322e62ca-1e5a-479e-9a96-4f26d09abdd7 | DHCP agent         | overcloud-controller-0.localdomain  | nova              | :-)   | UP    | neutron-dhcp-agent        |
| 9c1de2f9-bac5-400e-998d-4360f04fc533 | Open vSwitch agent | overcloud-novacompute-0.localdomain | None              | :-)   | UP    | neutron-openvswitch-agent |
| d99c5657-851e-4d3c-bef6-f1e3bb1acfb0 | Open vSwitch agent | overcloud-controller-0.localdomain  | None              | :-)   | UP    | neutron-openvswitch-agent |
| ff85fae6-5543-45fb-a301-19c57b62d836 | Metadata agent     | overcloud-controller-0.localdomain  | None              | :-)   | UP    | neutron-metadata-agent    |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
(overcloud) [stack@undercloud ~]$

การติดตั้งของฉันยังคงต้องใช้การสัมผัสเพียงเล็กน้อย นั่นคือการเพิ่มเส้นทางบนคอนโทรลเลอร์ เนื่องจากเครื่องที่ฉันใช้งานอยู่บนเครือข่ายอื่น หากต้องการทำสิ่งนี้ ให้ไปที่ control-1 ใต้บัญชี heat-admin และลงทะเบียนเส้นทาง

(undercloud) [stack@undercloud ~]$ ssh [email protected]         
Last login: Fri Aug 14 09:47:40 2020 from 192.168.255.1
[heat-admin@overcloud-controller-0 ~]$ 
[heat-admin@overcloud-controller-0 ~]$ 
[heat-admin@overcloud-controller-0 ~]$ sudo ip route add 10.169.0.0/16 via 192.168.255.254

ตอนนี้คุณสามารถไปสู่ขอบฟ้าได้แล้ว ข้อมูลทั้งหมด - ที่อยู่ การเข้าสู่ระบบ และรหัสผ่าน - อยู่ในไฟล์ /home/stack/overcloudrc แผนภาพสุดท้ายมีลักษณะดังนี้:

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

ปริมาณการรับส่งข้อมูลระหว่างเครื่องเสมือนเป็นอย่างไร

ในบทความนี้เราจะดูสามตัวเลือกในการส่งผ่านข้อมูล

• เครื่องจักรสองเครื่องบนไฮเปอร์ไวเซอร์หนึ่งเครื่องบนเครือข่าย L2 หนึ่งเครือข่าย
• เครื่องสองเครื่องบนไฮเปอร์ไวเซอร์ที่แตกต่างกันบนเครือข่าย L2 เดียวกัน
• เครื่องสองเครื่องบนเครือข่ายที่แตกต่างกัน (การรูทข้ามเครือข่าย)

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

เพื่อตรวจสอบ ลองรวบรวมไดอะแกรมต่อไปนี้:

เราได้สร้างเครื่องเสมือน 4 เครื่อง - 3 เครื่องบนเครือข่าย L2 หนึ่งเครือข่าย - net-1 และอีก 1 เครื่องบนเครือข่าย net-2

(overcloud) [stack@undercloud ~]$ nova list --tenant 5e18ce8ec9594e00b155485f19895e6c             
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
| ID                                   | Name | Tenant ID                        | Status | Task State | Power State | Networks        |
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
| f53b37b5-2204-46cc-aef0-dba84bf970c0 | vm-1 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | -          | Running     | net-1=10.0.1.85 |
| fc8b6722-0231-49b0-b2fa-041115bef34a | vm-2 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | -          | Running     | net-1=10.0.1.88 |
| 3cd74455-b9b7-467a-abe3-bd6ff765c83c | vm-3 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | -          | Running     | net-1=10.0.1.90 |
| 7e836338-6772-46b0-9950-f7f06dbe91a8 | vm-4 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | -          | Running     | net-2=10.0.2.8  |
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
(overcloud) [stack@undercloud ~]$ 

มาดูกันว่าเครื่องที่สร้างขึ้นนั้นอยู่บนไฮเปอร์ไวเซอร์ตัวใด:

(overcloud) [stack@undercloud ~]$ nova show f53b37b5-2204-46cc-aef0-dba84bf970c0 | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname             | vm-1                                                     |
| OS-EXT-SRV-ATTR:hypervisor_hostname  | overcloud-novacompute-0.localdomain                      |
| OS-EXT-SRV-ATTR:instance_name        | instance-00000001                                        |

(overcloud) [stack@undercloud ~]$ nova show fc8b6722-0231-49b0-b2fa-041115bef34a | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname             | vm-2                                                     |
| OS-EXT-SRV-ATTR:hypervisor_hostname  | overcloud-novacompute-1.localdomain                      |
| OS-EXT-SRV-ATTR:instance_name        | instance-00000002                                        |

(overcloud) [stack@undercloud ~]$ nova show 3cd74455-b9b7-467a-abe3-bd6ff765c83c | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname             | vm-3                                                     |
| OS-EXT-SRV-ATTR:hypervisor_hostname  | overcloud-novacompute-0.localdomain                      |
| OS-EXT-SRV-ATTR:instance_name        | instance-00000003                                        |

(overcloud) [stack@undercloud ~]$ nova show 7e836338-6772-46b0-9950-f7f06dbe91a8 | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname             | vm-4                                                     |
| OS-EXT-SRV-ATTR:hypervisor_hostname  | overcloud-novacompute-1.localdomain                      |
| OS-EXT-SRV-ATTR:instance_name        | instance-00000004                                        |

(โอเวอร์คลาวด์) [stack@undercloud ~]$
เครื่อง vm-1 และ vm-3 อยู่บน compute-0, เครื่อง vm-2 และ vm-4 อยู่บนโหนด compute-1

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

(overcloud) [stack@undercloud ~]$ openstack router list  --project 5e18ce8ec9594e00b155485f19895e6c
+--------------------------------------+----------+--------+-------+-------------+-------+----------------------------------+
| ID                                   | Name     | Status | State | Distributed | HA    | Project                          |
+--------------------------------------+----------+--------+-------+-------------+-------+----------------------------------+
| 0a4d2420-4b9c-46bd-aec1-86a1ef299abe | router-1 | ACTIVE | UP    | False       | False | 5e18ce8ec9594e00b155485f19895e6c |
+--------------------------------------+----------+--------+-------+-------------+-------+----------------------------------+
(overcloud) [stack@undercloud ~]$ 

เราเตอร์มีพอร์ตเสมือนสองพอร์ตซึ่งทำหน้าที่เป็นเกตเวย์สำหรับเครือข่าย:

(overcloud) [stack@undercloud ~]$ openstack router show 0a4d2420-4b9c-46bd-aec1-86a1ef299abe | grep interface
| interfaces_info         | [{"subnet_id": "2529ad1a-6b97-49cd-8515-cbdcbe5e3daa", "ip_address": "10.0.1.254", "port_id": "0c52b15f-8fcc-4801-bf52-7dacc72a5201"}, {"subnet_id": "335552dd-b35b-456b-9df0-5aac36a3ca13", "ip_address": "10.0.2.254", "port_id": "92fa49b5-5406-499f-ab8d-ddf28cc1a76c"}] |
(overcloud) [stack@undercloud ~]$ 

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

[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-vsctl show
[heat-admin@overcloud-novacompute-0 ~]$ sudo sudo ovs-appctl dpif/show
system@ovs-system: hit:3 missed:3
  br-ex:
    br-ex 65534/1: (internal)
    phy-br-ex 1/none: (patch: peer=int-br-ex)
  br-int:
    br-int 65534/2: (internal)
    int-br-ex 1/none: (patch: peer=phy-br-ex)
    patch-tun 2/none: (patch: peer=patch-int)
  br-tun:
    br-tun 65534/3: (internal)
    patch-int 1/none: (patch: peer=patch-tun)
    vxlan-c0a8ff0f 3/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.15)
    vxlan-c0a8ff1a 2/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.26)
[heat-admin@overcloud-novacompute-0 ~]$

ในขณะนี้ โหนดมีบริดจ์ ovs สามตัว - br-int, br-tun, br-ex อย่างที่เราเห็นมีชุดอินเทอร์เฟซอยู่ระหว่างนั้น เพื่อความสะดวกในการทำความเข้าใจ ลองพล็อตอินเทอร์เฟซเหล่านี้ทั้งหมดบนไดอะแกรมแล้วดูว่าเกิดอะไรขึ้น

เมื่อพิจารณาที่อยู่ซึ่งอุโมงค์ VxLAN ถูกยกขึ้น จะเห็นได้ว่าอุโมงค์หนึ่งถูกยกขึ้นเป็น compute-1 (192.168.255.26) อุโมงค์ที่สองมองไปที่ control-1 (192.168.255.15) แต่สิ่งที่น่าสนใจที่สุดคือ br-ex ไม่มีอินเทอร์เฟซทางกายภาพ และหากคุณดูว่าโฟลว์ใดได้รับการกำหนดค่า คุณจะเห็นว่าบริดจ์นี้สามารถลดการรับส่งข้อมูลได้เท่านั้นในขณะนี้

[heat-admin@overcloud-novacompute-0 ~]$ ifconfig eth0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1450
        inet 192.168.255.19  netmask 255.255.255.0  broadcast 192.168.255.255
        inet6 fe80::5054:ff:fe6a:eabe  prefixlen 64  scopeid 0x20<link>
        ether 52:54:00:6a:ea:be  txqueuelen 1000  (Ethernet)
        RX packets 2909669  bytes 4608201000 (4.2 GiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1821057  bytes 349198520 (333.0 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

[heat-admin@overcloud-novacompute-0 ~]$ 

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

[heat-admin@overcloud-novacompute-0 ~]$  sudo ovs-appctl fdb/show br-ex
 port  VLAN  MAC                Age
[heat-admin@overcloud-novacompute-0 ~]$  sudo ovs-ofctl dump-flows br-ex
 cookie=0x9169eae8f7fe5bb2, duration=216686.864s, table=0, n_packets=303, n_bytes=26035, priority=2,in_port="phy-br-ex" actions=drop
 cookie=0x9169eae8f7fe5bb2, duration=216686.887s, table=0, n_packets=0, n_bytes=0, priority=0 actions=NORMAL
[heat-admin@overcloud-novacompute-0 ~]$ 

ตามกฎข้อแรกทุกอย่างที่มาจากพอร์ต phy-br-ex จะต้องถูกทิ้งไป
จริงๆ แล้ว ขณะนี้ไม่มีที่ไหนอีกแล้วที่การรับส่งข้อมูลจะเข้ามาในบริดจ์นี้ ยกเว้นจากอินเทอร์เฟซนี้ (อินเทอร์เฟซกับ br-int) และเมื่อพิจารณาจากการลดลง การรับส่งข้อมูล BUM ได้ไหลเข้าสู่บริดจ์แล้ว

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

เราได้แยกโหนดคอมพิวท์ออกแล้ว มาดูโหนดควบคุมกันดีกว่า

[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl dpif/show
system@ovs-system: hit:930491 missed:825
  br-ex:
    br-ex 65534/1: (internal)
    eth0 1/2: (system)
    phy-br-ex 2/none: (patch: peer=int-br-ex)
  br-int:
    br-int 65534/3: (internal)
    int-br-ex 1/none: (patch: peer=phy-br-ex)
    patch-tun 2/none: (patch: peer=patch-int)
  br-tun:
    br-tun 65534/4: (internal)
    patch-int 1/none: (patch: peer=patch-tun)
    vxlan-c0a8ff13 3/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.19)
    vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$

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

[heat-admin@overcloud-controller-0 ~]$ ifconfig br-ex
br-ex: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1450
        inet 192.168.255.15  netmask 255.255.255.0  broadcast 192.168.255.255
        inet6 fe80::5054:ff:fe20:a22f  prefixlen 64  scopeid 0x20<link>
        ether 52:54:00:20:a2:2f  txqueuelen 1000  (Ethernet)
        RX packets 803859  bytes 1732616116 (1.6 GiB)
        RX errors 0  dropped 63  overruns 0  frame 0
        TX packets 808475  bytes 121652156 (116.0 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

[heat-admin@overcloud-controller-0 ~]$ 
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl fdb/show br-ex
 port  VLAN  MAC                Age
    3   100  28:c0:da:00:4d:d3   35
    1     0  28:c0:da:00:4d:d3   35
    1     0  52:54:00:98:e9:d6    0
LOCAL     0  52:54:00:20:a2:2f    0
    1     0  52:54:00:2c:08:9e    0
    3   100  52:54:00:20:a2:2f    0
    1     0  52:54:00:6a:ea:be    0
[heat-admin@overcloud-controller-0 ~]$ 

พอร์ตนี้เชื่อมโยงกับบริดจ์ br-ex และเนื่องจากไม่มีแท็ก vlan อยู่ พอร์ตนี้จึงเป็นพอร์ต trunk ที่อนุญาตให้ vlans ทั้งหมดได้ ขณะนี้การรับส่งข้อมูลออกไปข้างนอกโดยไม่มีแท็ก ตามที่ระบุโดย vlan-id 0 ใน เอาท์พุทด้านบน

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

เราจะไม่พิจารณาโหนดหน่วยเก็บข้อมูลในบทความนี้ แต่เพื่อความเข้าใจจำเป็นต้องกล่าวว่าส่วนเครือข่ายของโหนดเหล่านี้ซ้ำซากจนน่าอับอาย ในกรณีของเรา มีพอร์ตจริงเพียงพอร์ตเดียว (eth0) ที่ได้รับมอบหมายที่อยู่ IP แค่นั้นเอง ไม่มีอุโมงค์ VxLAN สะพานอุโมงค์ ฯลฯ - ไม่มี ovs เลย เนื่องจากไม่มีประเด็นอยู่ในนั้น เมื่อใช้การแยกเครือข่าย โหนดนี้จะมีอินเทอร์เฟซสองอินเทอร์เฟซ (ฟิสิคัลพอร์ต bodny หรือเพียงสอง vlan - มันไม่สำคัญ - ขึ้นอยู่กับสิ่งที่คุณต้องการ) - อันหนึ่งสำหรับการจัดการ ส่วนที่สองสำหรับการรับส่งข้อมูล (เขียนลงดิสก์ VM , อ่านจากดิสก์ ฯลฯ)

เราพบว่าเรามีอะไรบ้างบนโหนดหากไม่มีบริการใดๆ ตอนนี้เรามาเปิดตัวเครื่องเสมือน 4 เครื่องแล้วดูว่าโครงร่างที่อธิบายไว้ข้างต้นมีการเปลี่ยนแปลงอย่างไร - เราควรมีพอร์ต เราเตอร์เสมือน ฯลฯ

จนถึงขณะนี้เครือข่ายของเรามีลักษณะดังนี้:

เรามีเครื่องเสมือนสองเครื่องบนโหนดคอมพิวเตอร์แต่ละเครื่อง ใช้ compute-0 เป็นตัวอย่าง มาดูกันว่าทุกอย่างรวมเข้าด้วยกันอย่างไร

[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh list 
 Id    Name                           State
----------------------------------------------------
 1     instance-00000001              running
 3     instance-00000003              running

[heat-admin@overcloud-novacompute-0 ~]$ 

เครื่องมีอินเทอร์เฟซเสมือนเดียวเท่านั้น - tap95d96a75-a0:

[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Interface  Type       Source     Model       MAC
-------------------------------------------------------
tap95d96a75-a0 bridge     qbr95d96a75-a0 virtio      fa:16:3e:44:98:20

[heat-admin@overcloud-novacompute-0 ~]$ 

อินเทอร์เฟซนี้ดูในบริดจ์ linux:

[heat-admin@overcloud-novacompute-0 ~]$ sudo brctl show
bridge name     bridge id               STP enabled     interfaces
docker0         8000.0242904c92a8       no
qbr5bd37136-47          8000.5e4e05841423       no              qvb5bd37136-47
                                                        tap5bd37136-47
qbr95d96a75-a0          8000.de076cb850f6       no              qvb95d96a75-a0
                                                        tap95d96a75-a0
[heat-admin@overcloud-novacompute-0 ~]$ 

ดังที่คุณเห็นจากเอาต์พุต มีเพียงสองอินเทอร์เฟซในบริดจ์ - tap95d96a75-a0 และ qvb95d96a75-a0

ที่นี่คุ้มค่าที่จะพิจารณาประเภทของอุปกรณ์เครือข่ายเสมือนใน OpenStack เล็กน้อย:
vtap - อินเทอร์เฟซเสมือนที่แนบกับอินสแตนซ์ (VM)
qbr - บริดจ์ลินุกซ์
qvb และ qvo - คู่ vEth เชื่อมต่อกับ Linux Bridge และ Open vSwitch Bridge
br-int, br-tun, br-vlan - เปิดสะพาน vSwitch
patch-, int-br-, phy-br- - เปิดอินเทอร์เฟซแพทช์ vSwitch ที่เชื่อมต่อบริดจ์
qg, qr, ha, fg, sg - เปิดพอร์ต vSwitch ที่ใช้โดยอุปกรณ์เสมือนเพื่อเชื่อมต่อกับ OVS

ดังที่คุณเข้าใจหากเรามีพอร์ต qvb95d96a75-a0 ในบริดจ์ซึ่งเป็นคู่ vEth แสดงว่ามีพอร์ตคู่กันอยู่ที่ไหนสักแห่งซึ่งควรเรียกว่า qvo95d96a75-a0 ตามตรรกะ มาดูกันว่ามีพอร์ตใดบ้างบน OVS

[heat-admin@overcloud-novacompute-0 ~]$ sudo sudo ovs-appctl dpif/show
system@ovs-system: hit:526 missed:91
  br-ex:
    br-ex 65534/1: (internal)
    phy-br-ex 1/none: (patch: peer=int-br-ex)
  br-int:
    br-int 65534/2: (internal)
    int-br-ex 1/none: (patch: peer=phy-br-ex)
    patch-tun 2/none: (patch: peer=patch-int)
    qvo5bd37136-47 6/6: (system)
    qvo95d96a75-a0 3/5: (system)
  br-tun:
    br-tun 65534/3: (internal)
    patch-int 1/none: (patch: peer=patch-tun)
    vxlan-c0a8ff0f 3/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.15)
    vxlan-c0a8ff1a 2/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.26)
[heat-admin@overcloud-novacompute-0 ~]$ 

อย่างที่เราเห็น พอร์ตอยู่ใน br-int Br-int ทำหน้าที่เป็นสวิตช์ที่ยุติพอร์ตเครื่องเสมือน นอกจาก qvo95d96a75-a0 แล้ว พอร์ต qvo5bd37136-47 ยังมองเห็นได้ในเอาต์พุต นี่คือพอร์ตไปยังเครื่องเสมือนเครื่องที่สอง ด้วยเหตุนี้ แผนภาพของเราจึงมีลักษณะดังนี้:

คำถามที่ควรสนใจผู้อ่านที่สนใจในทันที - สะพาน linux ระหว่างพอร์ตเครื่องเสมือนและพอร์ต OVS คืออะไร? ความจริงก็คือมีการใช้กลุ่มความปลอดภัยซึ่งไม่มีอะไรมากไปกว่า iptables เพื่อปกป้องเครื่อง OVS ไม่ทำงานกับ iptables ดังนั้นจึงมีการประดิษฐ์ "ไม้ค้ำยัน" นี้ขึ้นมา อย่างไรก็ตาม มันกำลังล้าสมัย - มันถูกแทนที่ด้วย conntrack ในรีลีสใหม่

นั่นคือท้ายที่สุดแล้วโครงร่างจะมีลักษณะดังนี้:

เครื่องจักรสองเครื่องบนไฮเปอร์ไวเซอร์หนึ่งเครื่องบนเครือข่าย L2 หนึ่งเครือข่าย

เนื่องจาก VM ทั้งสองนี้อยู่บนเครือข่าย L2 เดียวกันและบนไฮเปอร์ไวเซอร์เดียวกัน การรับส่งข้อมูลระหว่าง VM จะไหลในเครื่องผ่าน br-int ตามตรรกะ เนื่องจากทั้งสองเครื่องจะอยู่บน VLAN เดียวกัน:

[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Interface  Type       Source     Model       MAC
-------------------------------------------------------
tap95d96a75-a0 bridge     qbr95d96a75-a0 virtio      fa:16:3e:44:98:20

[heat-admin@overcloud-novacompute-0 ~]$ 
[heat-admin@overcloud-novacompute-0 ~]$ 
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000003
Interface  Type       Source     Model       MAC
-------------------------------------------------------
tap5bd37136-47 bridge     qbr5bd37136-47 virtio      fa:16:3e:83:ad:a4

[heat-admin@overcloud-novacompute-0 ~]$ 
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl fdb/show br-int 
 port  VLAN  MAC                Age
    6     1  fa:16:3e:83:ad:a4    0
    3     1  fa:16:3e:44:98:20    0
[heat-admin@overcloud-novacompute-0 ~]$ 

เครื่องสองเครื่องบนไฮเปอร์ไวเซอร์ที่แตกต่างกันบนเครือข่าย L2 เดียวกัน

ตอนนี้เรามาดูกันว่าการรับส่งข้อมูลจะเป็นอย่างไรระหว่างเครื่องสองเครื่องบนเครือข่าย L2 เดียวกัน แต่อยู่บนไฮเปอร์ไวเซอร์ที่ต่างกัน พูดตามตรงจะไม่มีอะไรเปลี่ยนแปลงมากนัก เพียงแค่การรับส่งข้อมูลระหว่างไฮเปอร์ไวเซอร์จะผ่านอุโมงค์ vxlan ลองดูตัวอย่าง

ที่อยู่ของเครื่องเสมือนที่เราจะดูการรับส่งข้อมูล:

[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Interface  Type       Source     Model       MAC
-------------------------------------------------------
tap95d96a75-a0 bridge     qbr95d96a75-a0 virtio      fa:16:3e:44:98:20

[heat-admin@overcloud-novacompute-0 ~]$ 

[heat-admin@overcloud-novacompute-1 ~]$ sudo virsh domiflist instance-00000002
Interface  Type       Source     Model       MAC
-------------------------------------------------------
tape7e23f1b-07 bridge     qbre7e23f1b-07 virtio      fa:16:3e:72:ad:53

[heat-admin@overcloud-novacompute-1 ~]$ 

เราดูที่ตารางการส่งต่อใน br-int บน compute-0:

[heat-admin@overcloud-novacompute-0 ~]$  sudo ovs-appctl fdb/show br-int | grep fa:16:3e:72:ad:53
    2     1  fa:16:3e:72:ad:53    1
[heat-admin@overcloud-novacompute-0 ~]

การจราจรควรไปที่พอร์ต 2 - มาดูกันว่าเป็นพอร์ตประเภทใด:

[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl show br-int | grep addr
 1(int-br-ex): addr:7e:7f:28:1f:bd:54
 2(patch-tun): addr:0a:bd:07:69:58:d9
 3(qvo95d96a75-a0): addr:ea:50:9a:3d:69:58
 6(qvo5bd37136-47): addr:9a:d1:03:50:3d:96
 LOCAL(br-int): addr:1a:0f:53:97:b1:49
[heat-admin@overcloud-novacompute-0 ~]$

นี่คือ patch-tun - นั่นคืออินเทอร์เฟซใน br-tun มาดูกันว่าเกิดอะไรขึ้นกับแพ็คเกจบน br-tun:

[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl dump-flows br-tun | grep fa:16:3e:72:ad:53
 cookie=0x8759a56536b67a8e, duration=1387.959s, table=20, n_packets=1460, n_bytes=138880, hard_timeout=300, idle_age=0, hard_age=0, priority=1,vlan_tci=0x0001/0x0fff,dl_dst=fa:16:3e:72:ad:53 actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:2
[heat-admin@overcloud-novacompute-0 ~]$ 

แพ็กเก็ตถูกบรรจุใน VxLAN และส่งไปยังพอร์ต 2 มาดูกันว่าพอร์ต 2 นำไปสู่ที่ใด:

[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl show br-tun | grep addr   
 1(patch-int): addr:b2:d1:f8:21:96:66
 2(vxlan-c0a8ff1a): addr:be:64:1f:75:78:a7
 3(vxlan-c0a8ff0f): addr:76:6f:b9:3c:3f:1c
 LOCAL(br-tun): addr:a2:5b:6d:4f:94:47
[heat-admin@overcloud-novacompute-0 ~]$

นี่คืออุโมงค์ vxlan บน compute-1:

[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl dpif/show | egrep vxlan-c0a8ff1a
    vxlan-c0a8ff1a 2/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.26)
[heat-admin@overcloud-novacompute-0 ~]$

ไปที่ compute-1 แล้วดูว่าจะเกิดอะไรขึ้นต่อไปกับแพ็คเกจ:

[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-appctl fdb/show br-int | egrep fa:16:3e:44:98:20
    2     1  fa:16:3e:44:98:20    1
[heat-admin@overcloud-novacompute-1 ~]$ 

Mac อยู่ในตารางการส่งต่อ br-int บน compute-1 และดังที่เห็นได้จากเอาต์พุตด้านบน จะมองเห็นได้ผ่านพอร์ต 2 ซึ่งเป็นพอร์ตที่มุ่งหน้าไปยัง br-tun:

[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-ofctl show br-int | grep addr   
 1(int-br-ex): addr:8a:d7:f9:ad:8c:1d
 2(patch-tun): addr:46:cc:40:bd:20:da
 3(qvoe7e23f1b-07): addr:12:78:2e:34:6a:c7
 4(qvo3210e8ec-c0): addr:7a:5f:59:75:40:85
 LOCAL(br-int): addr:e2:27:b2:ed:14:46

ถ้าอย่างนั้นเราจะเห็นว่าใน br-int บน compute-1 มีป๊อปปี้ปลายทาง:

[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-appctl fdb/show br-int | egrep fa:16:3e:72:ad:53
    3     1  fa:16:3e:72:ad:53    0
[heat-admin@overcloud-novacompute-1 ~]$ 

นั่นคือแพ็กเก็ตที่ได้รับจะบินไปที่พอร์ต 3 ซึ่งด้านหลังมีเครื่องเสมือนอินสแตนซ์ -00000003 อยู่แล้ว

ข้อดีของการใช้ OpenStack เพื่อการเรียนรู้บนโครงสร้างพื้นฐานเสมือนคือเราสามารถบันทึกการรับส่งข้อมูลระหว่างไฮเปอร์ไวเซอร์และดูสิ่งที่เกิดขึ้นกับไฮเปอร์ไวเซอร์ได้อย่างง่ายดาย นี่คือสิ่งที่เราจะทำตอนนี้ รัน tcpdump บนพอร์ต vnet ไปทาง compute-0:

[root@hp-gen9 bormoglotx]# tcpdump -vvv -i vnet3
tcpdump: listening on vnet3, link-type EN10MB (Ethernet), capture size 262144 bytes

*****************omitted*******************

04:39:04.583459 IP (tos 0x0, ttl 64, id 16868, offset 0, flags [DF], proto UDP (17), length 134)
    192.168.255.19.39096 > 192.168.255.26.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 8012, offset 0, flags [DF], proto ICMP (1), length 84)
    10.0.1.85 > 10.0.1.88: ICMP echo request, id 5634, seq 16, length 64
04:39:04.584449 IP (tos 0x0, ttl 64, id 35181, offset 0, flags [DF], proto UDP (17), length 134)
    192.168.255.26.speedtrace-disc > 192.168.255.19.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 59124, offset 0, flags [none], proto ICMP (1), length 84)
    10.0.1.88 > 10.0.1.85: ICMP echo reply, id 5634, seq 16, length 64
	
*****************omitted*******************

บรรทัดแรกแสดงว่า Patek จากที่อยู่ 10.0.1.85 ไปที่ที่อยู่ 10.0.1.88 (การรับส่งข้อมูล ICMP) และถูกรวมไว้ในแพ็กเก็ต VxLAN ที่มี vni 22 และแพ็กเก็ตเปลี่ยนจากโฮสต์ 192.168.255.19 (compute-0) ไปยังโฮสต์ 192.168.255.26 .1 ( คำนวณ-XNUMX) เราสามารถตรวจสอบได้ว่า VNI ตรงกับค่าที่ระบุใน ovs

กลับไปที่บรรทัดนี้ actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:2 0x16 คือ vni ในระบบเลขฐานสิบหก แปลงตัวเลขนี้เป็นระบบที่ 16:

16 = 6*16^0+1*16^1 = 6+16 = 22

นั่นคือ vni สอดคล้องกับความเป็นจริง

บรรทัดที่สองแสดงการเข้าชมขากลับ ไม่มีเหตุผลที่จะอธิบายทุกอย่างชัดเจน

เครื่องสองเครื่องบนเครือข่ายที่แตกต่างกัน (การกำหนดเส้นทางระหว่างเครือข่าย)

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

ก่อนอื่น เรามาดูกันว่าการกำหนดเส้นทางใช้งานได้:

$ ping 10.0.2.8
PING 10.0.2.8 (10.0.2.8): 56 data bytes
64 bytes from 10.0.2.8: seq=0 ttl=63 time=7.727 ms
64 bytes from 10.0.2.8: seq=1 ttl=63 time=3.832 ms
^C
--- 10.0.2.8 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 3.832/5.779/7.727 ms

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

$ arp
host-10-0-1-254.openstacklocal (10.0.1.254) at fa:16:3e:c4:64:70 [ether]  on eth0
host-10-0-1-1.openstacklocal (10.0.1.1) at fa:16:3e:e6:2c:5c [ether]  on eth0
host-10-0-1-90.openstacklocal (10.0.1.90) at fa:16:3e:83:ad:a4 [ether]  on eth0
host-10-0-1-88.openstacklocal (10.0.1.88) at fa:16:3e:72:ad:53 [ether]  on eth0

ตอนนี้เรามาดูกันว่าการรับส่งข้อมูลที่มีปลายทาง (10.0.1.254) fa:16:3e:c4:64:70 ควรถูกส่งไปที่ไหน:

[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl fdb/show br-int | egrep fa:16:3e:c4:64:70
    2     1  fa:16:3e:c4:64:70    0
[heat-admin@overcloud-novacompute-0 ~]$ 

มาดูกันว่าพอร์ต 2 นำไปสู่จุดไหน:

[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl show br-int | grep addr
 1(int-br-ex): addr:7e:7f:28:1f:bd:54
 2(patch-tun): addr:0a:bd:07:69:58:d9
 3(qvo95d96a75-a0): addr:ea:50:9a:3d:69:58
 6(qvo5bd37136-47): addr:9a:d1:03:50:3d:96
 LOCAL(br-int): addr:1a:0f:53:97:b1:49
[heat-admin@overcloud-novacompute-0 ~]$ 

ทุกอย่างเป็นไปตามตรรกะ การจราจรไปที่ br-tun มาดูกันว่าอุโมงค์ vxlan ใดที่จะถูกหุ้มไว้:

[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl dump-flows br-tun | grep fa:16:3e:c4:64:70
 cookie=0x8759a56536b67a8e, duration=3514.566s, table=20, n_packets=3368, n_bytes=317072, hard_timeout=300, idle_age=0, hard_age=0, priority=1,vlan_tci=0x0001/0x0fff,dl_dst=fa:16:3e:c4:64:70 actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:3
[heat-admin@overcloud-novacompute-0 ~]$ 

พอร์ตที่สามคืออุโมงค์ vxlan:

[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-tun | grep addr
 1(patch-int): addr:a2:69:00:c5:fa:ba
 2(vxlan-c0a8ff1a): addr:86:f0:ce:d0:e8:ea
 3(vxlan-c0a8ff13): addr:72:aa:73:2c:2e:5b
 LOCAL(br-tun): addr:a6:cb:cd:72:1c:45
[heat-admin@overcloud-controller-0 ~]$ 

ซึ่งดูที่โหนดควบคุม:

[heat-admin@overcloud-controller-0 ~]$ sudo sudo ovs-appctl dpif/show | grep vxlan-c0a8ff1a
    vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$ 

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

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

ดังนั้นจึงเห็นได้ชัดว่าที่อยู่ MAC ของเกตเวย์ต้องอยู่ในตารางการส่งต่อ br-int บนโหนดควบคุม ตรวจสอบว่ามีอยู่และกำลังมองหาอยู่ที่ไหน:

[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:c4:64:70
    5     1  fa:16:3e:c4:64:70    1
[heat-admin@overcloud-controller-0 ~]$ 
[heat-admin@overcloud-controller-0 ~]$  sudo ovs-ofctl show br-int | grep addr
 1(int-br-ex): addr:2e:58:b6:db:d5:de
 2(patch-tun): addr:06:41:90:f0:9e:56
 3(tapca25a97e-64): addr:fa:16:3e:e6:2c:5c
 4(tap22015e46-0b): addr:fa:16:3e:76:c2:11
 5(qr-0c52b15f-8f): addr:fa:16:3e:c4:64:70
 6(qr-92fa49b5-54): addr:fa:16:3e:80:13:72
 LOCAL(br-int): addr:06:de:5d:ed:44:44
[heat-admin@overcloud-controller-0 ~]$ 

Mac สามารถมองเห็นได้จากพอร์ต qr-0c52b15f-8f หากเรากลับไปที่รายการพอร์ตเสมือนใน OpenStack พอร์ตประเภทนี้จะใช้เพื่อเชื่อมต่ออุปกรณ์เสมือนต่างๆ กับ OVS เพื่อให้แม่นยำยิ่งขึ้น qr คือพอร์ตไปยังเราเตอร์เสมือนซึ่งแสดงเป็นเนมสเปซ

มาดูกันว่าเนมสเปซใดบ้างบนเซิร์ฟเวอร์:

[heat-admin@overcloud-controller-0 ~]$ sudo  ip netns
qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe (id: 2)
qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638 (id: 1)
qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 (id: 0)
[heat-admin@overcloud-controller-0 ~]$ 

มากถึงสามสำเนา แต่เมื่อดูจากชื่อแล้วก็สามารถเดาจุดประสงค์ของแต่ละคนได้ เราจะกลับสู่อินสแตนซ์ที่มี ID 0 และ 1 ในภายหลัง ตอนนี้เราสนใจเนมสเปซ qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe:

[heat-admin@overcloud-controller-0 ~]$ sudo  ip netns exec qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe ip route
10.0.1.0/24 dev qr-0c52b15f-8f proto kernel scope link src 10.0.1.254 
10.0.2.0/24 dev qr-92fa49b5-54 proto kernel scope link src 10.0.2.254 
[heat-admin@overcloud-controller-0 ~]$ 

เนมสเปซนี้ประกอบด้วยสองเนมสเปซภายในที่เราสร้างไว้ก่อนหน้านี้ มีการเพิ่มพอร์ตเสมือนทั้งสองพอร์ตใน br-int ตรวจสอบที่อยู่ Mac ของพอร์ต qr-0c52b15f-8f เนื่องจากการรับส่งข้อมูลซึ่งตัดสินโดยที่อยู่ Mac ปลายทางไปที่อินเทอร์เฟซนี้

[heat-admin@overcloud-controller-0 ~]$ sudo  ip netns exec qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe ifconfig qr-0c52b15f-8f
qr-0c52b15f-8f: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1450
        inet 10.0.1.254  netmask 255.255.255.0  broadcast 10.0.1.255
        inet6 fe80::f816:3eff:fec4:6470  prefixlen 64  scopeid 0x20<link>
        ether fa:16:3e:c4:64:70  txqueuelen 1000  (Ethernet)
        RX packets 5356  bytes 427305 (417.2 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 5195  bytes 490603 (479.1 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

[heat-admin@overcloud-controller-0 ~]$ 

นั่นคือในกรณีนี้ทุกอย่างทำงานตามกฎของการกำหนดเส้นทางมาตรฐาน เนื่องจากการรับส่งข้อมูลถูกกำหนดไว้สำหรับโฮสต์ 10.0.2.8 จึงจะต้องออกผ่านอินเทอร์เฟซที่สอง qr-92fa49b5-54 และผ่านอุโมงค์ vxlan ไปยังโหนดคอมพิวท์:

[heat-admin@overcloud-controller-0 ~]$ sudo  ip netns exec qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe arp
Address                  HWtype  HWaddress           Flags Mask            Iface
10.0.1.88                ether   fa:16:3e:72:ad:53   C                     qr-0c52b15f-8f
10.0.1.90                ether   fa:16:3e:83:ad:a4   C                     qr-0c52b15f-8f
10.0.2.8                 ether   fa:16:3e:6c:ad:9c   C                     qr-92fa49b5-54
10.0.2.42                ether   fa:16:3e:f5:0b:29   C                     qr-92fa49b5-54
10.0.1.85                ether   fa:16:3e:44:98:20   C                     qr-0c52b15f-8f
[heat-admin@overcloud-controller-0 ~]$ 

ทุกอย่างมีเหตุผล ไม่มีเรื่องน่าประหลาดใจ มาดูกันว่าที่อยู่ป๊อปปี้ของโฮสต์ 10.0.2.8 มองเห็นได้ที่ไหนใน br-int:

[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:6c:ad:9c
    2     2  fa:16:3e:6c:ad:9c    1
[heat-admin@overcloud-controller-0 ~]$ 
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-int | grep addr
 1(int-br-ex): addr:2e:58:b6:db:d5:de
 2(patch-tun): addr:06:41:90:f0:9e:56
 3(tapca25a97e-64): addr:fa:16:3e:e6:2c:5c
 4(tap22015e46-0b): addr:fa:16:3e:76:c2:11
 5(qr-0c52b15f-8f): addr:fa:16:3e:c4:64:70
 6(qr-92fa49b5-54): addr:fa:16:3e:80:13:72
 LOCAL(br-int): addr:06:de:5d:ed:44:44
[heat-admin@overcloud-controller-0 ~]$ 

ตามที่คาดไว้ การจราจรไปที่ br-tun มาดูกันว่าการจราจรจะไปที่อุโมงค์ไหนต่อไป:

[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl dump-flows br-tun | grep fa:16:3e:6c:ad:9c
 cookie=0x2ab04bf27114410e, duration=5346.829s, table=20, n_packets=5248, n_bytes=498512, hard_timeout=300, idle_age=0, hard_age=0, priority=1,vlan_tci=0x0002/0x0fff,dl_dst=fa:16:3e:6c:ad:9c actions=load:0->NXM_OF_VLAN_TCI[],load:0x63->NXM_NX_TUN_ID[],output:2
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-tun | grep addr
 1(patch-int): addr:a2:69:00:c5:fa:ba
 2(vxlan-c0a8ff1a): addr:86:f0:ce:d0:e8:ea
 3(vxlan-c0a8ff13): addr:72:aa:73:2c:2e:5b
 LOCAL(br-tun): addr:a6:cb:cd:72:1c:45
[heat-admin@overcloud-controller-0 ~]$ 
[heat-admin@overcloud-controller-0 ~]$ sudo sudo ovs-appctl dpif/show | grep vxlan-c0a8ff1a
    vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$ 

การจราจรเข้าไปในอุโมงค์เพื่อคำนวณ 1 ในการคำนวณ 1 ทุกอย่างเป็นเรื่องง่าย - จาก br-tun แพ็คเกจไปที่ br-int และจากที่นั่นไปยังอินเทอร์เฟซเครื่องเสมือน:

[heat-admin@overcloud-controller-0 ~]$ sudo sudo ovs-appctl dpif/show | grep vxlan-c0a8ff1a
    vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$ 
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:6c:ad:9c
    4     2  fa:16:3e:6c:ad:9c    1
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-ofctl show br-int | grep addr                  
 1(int-br-ex): addr:8a:d7:f9:ad:8c:1d
 2(patch-tun): addr:46:cc:40:bd:20:da
 3(qvoe7e23f1b-07): addr:12:78:2e:34:6a:c7
 4(qvo3210e8ec-c0): addr:7a:5f:59:75:40:85
 LOCAL(br-int): addr:e2:27:b2:ed:14:46
[heat-admin@overcloud-novacompute-1 ~]$ 

ตรวจสอบว่านี่เป็นอินเทอร์เฟซที่ถูกต้อง:

[heat-admin@overcloud-novacompute-1 ~]$ brctl show
bridge name     bridge id               STP enabled     interfaces
docker0         8000.02429c001e1c       no
qbr3210e8ec-c0          8000.ea27f45358be       no              qvb3210e8ec-c0
                                                        tap3210e8ec-c0
qbre7e23f1b-07          8000.b26ac0eded8a       no              qvbe7e23f1b-07
                                                        tape7e23f1b-07
[heat-admin@overcloud-novacompute-1 ~]$ 
[heat-admin@overcloud-novacompute-1 ~]$ sudo virsh domiflist instance-00000004
Interface  Type       Source     Model       MAC
-------------------------------------------------------
tap3210e8ec-c0 bridge     qbr3210e8ec-c0 virtio      fa:16:3e:6c:ad:9c

[heat-admin@overcloud-novacompute-1 ~]$

จริงๆแล้วเราผ่านแพ็คเกจไปแล้ว ฉันคิดว่าคุณสังเกตเห็นว่าการรับส่งข้อมูลผ่านอุโมงค์ vxlan ที่แตกต่างกันและออกด้วย VNI ที่แตกต่างกัน เรามาดูกันว่า VNI เหล่านี้คืออะไร หลังจากนั้นเราจะรวบรวมดัมพ์บนพอร์ตควบคุมของโหนดและตรวจสอบให้แน่ใจว่าการรับส่งข้อมูลเป็นไปตามที่อธิบายไว้ข้างต้น
ดังนั้น ช่องสัญญาณที่จะคำนวณ 0 จึงมีการดำเนินการต่อไปนี้=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],เอาต์พุต:3 ลองแปลง 0x16 เป็นระบบเลขทศนิยม:

0x16 = 6*16^0+1*16^1 = 6+16 = 22

ช่องสัญญาณที่จะคำนวณ 1 มี VNI:actions=load:0->NXM_OF_VLAN_TCI[],load:0x63->NXM_NX_TUN_ID[],เอาต์พุต:2 ต่อไปนี้ ลองแปลง 0x63 เป็นระบบเลขทศนิยม:

0x63 = 3*16^0+6*16^1 = 3+96 = 99

ทีนี้มาดูการถ่ายโอนข้อมูล:

[root@hp-gen9 bormoglotx]# tcpdump -vvv -i vnet4 
tcpdump: listening on vnet4, link-type EN10MB (Ethernet), capture size 262144 bytes

*****************omitted*******************

04:35:18.709949 IP (tos 0x0, ttl 64, id 48650, offset 0, flags [DF], proto UDP (17), length 134)
    192.168.255.19.41591 > 192.168.255.15.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 49042, offset 0, flags [DF], proto ICMP (1), length 84)
    10.0.1.85 > 10.0.2.8: ICMP echo request, id 5378, seq 9, length 64
04:35:18.710159 IP (tos 0x0, ttl 64, id 23360, offset 0, flags [DF], proto UDP (17), length 134)
    192.168.255.15.38983 > 192.168.255.26.4789: [no cksum] VXLAN, flags [I] (0x08), vni 99
IP (tos 0x0, ttl 63, id 49042, offset 0, flags [DF], proto ICMP (1), length 84)
    10.0.1.85 > 10.0.2.8: ICMP echo request, id 5378, seq 9, length 64
04:35:18.711292 IP (tos 0x0, ttl 64, id 43596, offset 0, flags [DF], proto UDP (17), length 134)
    192.168.255.26.42588 > 192.168.255.15.4789: [no cksum] VXLAN, flags [I] (0x08), vni 99
IP (tos 0x0, ttl 64, id 55103, offset 0, flags [none], proto ICMP (1), length 84)
    10.0.2.8 > 10.0.1.85: ICMP echo reply, id 5378, seq 9, length 64
04:35:18.711531 IP (tos 0x0, ttl 64, id 8555, offset 0, flags [DF], proto UDP (17), length 134)
    192.168.255.15.38983 > 192.168.255.19.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 63, id 55103, offset 0, flags [none], proto ICMP (1), length 84)
    10.0.2.8 > 10.0.1.85: ICMP echo reply, id 5378, seq 9, length 64
	
*****************omitted*******************

แพ็กเก็ตแรกคือแพ็กเก็ต vxlan จากโฮสต์ 192.168.255.19 (compute-0) ไปยังโฮสต์ 192.168.255.15 (control-1) ด้วย vni 22 ภายในซึ่งมีแพ็กเก็ต ICMP บรรจุจากโฮสต์ 10.0.1.85 ถึงโฮสต์ 10.0.2.8 ตามที่เราคำนวณไว้ข้างต้น vni จะตรงกับสิ่งที่เราเห็นในผลลัพธ์

แพ็กเก็ตที่สองคือแพ็กเก็ต vxlan จากโฮสต์ 192.168.255.15 (control-1) ไปยังโฮสต์ 192.168.255.26 (compute-1) ด้วย vni 99 ภายในซึ่งมีแพ็กเก็ต ICMP ถูกแพ็กเกจจากโฮสต์ 10.0.1.85 ไปยังโฮสต์ 10.0.2.8 ตามที่เราคำนวณไว้ข้างต้น vni จะตรงกับสิ่งที่เราเห็นในผลลัพธ์

สองแพ็กเก็ตถัดไปเป็นทราฟฟิกส่งคืนจาก 10.0.2.8 ไม่ใช่ 10.0.1.85

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

ดูเป็นอย่างนั้นเหรอ? เราลืมไปประมาณสองเนมสเปซ:

[heat-admin@overcloud-controller-0 ~]$ sudo  ip netns
qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe (id: 2)
qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638 (id: 1)
qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 (id: 0)
[heat-admin@overcloud-controller-0 ~]$ 

ขณะที่เราพูดถึงสถาปัตยกรรมของแพลตฟอร์มคลาวด์ คงจะดีถ้าเครื่องได้รับที่อยู่โดยอัตโนมัติจากเซิร์ฟเวอร์ DHCP นี่คือเซิร์ฟเวอร์ DHCP สองเซิร์ฟเวอร์สำหรับสองเครือข่ายของเรา 10.0.1.0/24 และ 10.0.2.0/24

มาตรวจสอบว่าสิ่งนี้เป็นจริง มีที่อยู่เดียวเท่านั้นในเนมสเปซนี้ - 10.0.1.1 - ที่อยู่ของเซิร์ฟเวอร์ DHCP เองและรวมอยู่ใน br-int ด้วย:

[heat-admin@overcloud-controller-0 ~]$ sudo ip netns exec qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 ifconfig
lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 1  bytes 28 (28.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1  bytes 28 (28.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

tapca25a97e-64: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1450
        inet 10.0.1.1  netmask 255.255.255.0  broadcast 10.0.1.255
        inet6 fe80::f816:3eff:fee6:2c5c  prefixlen 64  scopeid 0x20<link>
        ether fa:16:3e:e6:2c:5c  txqueuelen 1000  (Ethernet)
        RX packets 129  bytes 9372 (9.1 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 49  bytes 6154 (6.0 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

มาดูกันว่ากระบวนการที่มี qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 ในชื่อของพวกเขาบนโหนดควบคุมหรือไม่:

[heat-admin@overcloud-controller-0 ~]$ ps -aux | egrep qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638 
root      640420  0.0  0.0   4220   348 ?        Ss   11:31   0:00 dumb-init --single-child -- ip netns exec qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638 /usr/sbin/dnsmasq -k --no-hosts --no-resolv --pid-file=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/pid --dhcp-hostsfile=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/host --addn-hosts=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/addn_hosts --dhcp-optsfile=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/opts --dhcp-leasefile=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/leases --dhcp-match=set:ipxe,175 --local-service --bind-dynamic --dhcp-range=set:subnet-335552dd-b35b-456b-9df0-5aac36a3ca13,10.0.2.0,static,255.255.255.0,86400s --dhcp-option-force=option:mtu,1450 --dhcp-lease-max=256 --conf-file= --domain=openstacklocal
heat-ad+  951620  0.0  0.0 112944   980 pts/0    S+   18:50   0:00 grep -E --color=auto qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638
[heat-admin@overcloud-controller-0 ~]$ 

มีกระบวนการดังกล่าวและจากข้อมูลที่นำเสนอในผลลัพธ์ด้านบน เราสามารถดูสิ่งที่เรามีให้เช่าในปัจจุบันได้:

[heat-admin@overcloud-controller-0 ~]$ cat /var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/leases
1597492111 fa:16:3e:6c:ad:9c 10.0.2.8 host-10-0-2-8 01:fa:16:3e:6c:ad:9c
1597491115 fa:16:3e:76:c2:11 10.0.2.1 host-10-0-2-1 *
[heat-admin@overcloud-controller-0 ~]$

เป็นผลให้เราได้รับชุดบริการต่อไปนี้บนโหนดควบคุม:

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

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

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

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

ฉันไม่ได้โปรโมตผลิตภัณฑ์แรกหรือผลิตภัณฑ์ที่สอง - คุณเลือกสิ่งที่คุณต้องการ แต่ถ้าฉันมีตัวเลือกดังกล่าว ฉันจะเลือกทั้งสองโซลูชัน - VMWare สำหรับไอทีคลาวด์ (โหลดต่ำ, จัดการง่าย), OpenStack จากผู้จำหน่ายบางราย (Nokia และ Juniper มีโซลูชันแบบครบวงจรที่ดีมาก) - สำหรับคลาวด์เทเลคอม ฉันจะไม่ใช้ OpenStack สำหรับไอทีล้วนๆ - มันเหมือนกับการยิงนกกระจอกด้วยปืนใหญ่ แต่ฉันไม่เห็นข้อห้ามในการใช้มันเลย นอกจากการทำซ้ำ อย่างไรก็ตาม การใช้ VMWare ในโทรคมนาคมก็เหมือนกับการลากเศษหินในรถ Ford Raptor ภายนอกดูสวยงาม แต่คนขับต้องเดินทาง 10 เที่ยวแทนที่จะเป็นครั้งเดียว

ในความคิดของฉันข้อเสียที่ใหญ่ที่สุดของ VMWare คือการปิดโดยสมบูรณ์ - บริษัท จะไม่ให้ข้อมูลใด ๆ เกี่ยวกับวิธีการทำงานแก่คุณเช่น vSAN หรือสิ่งที่อยู่ในเคอร์เนลไฮเปอร์ไวเซอร์ - มันไม่ได้ผลกำไรสำหรับมัน - นั่นคือคุณจะ อย่าเป็นผู้เชี่ยวชาญใน VMWare เลย - หากไม่มีการสนับสนุนจากผู้จำหน่าย คุณก็จะถึงวาระ (บ่อยครั้งที่ฉันพบกับผู้เชี่ยวชาญของ VMWare ที่รู้สึกงุนงงกับคำถามเล็กน้อย) สำหรับฉัน VMWare กำลังซื้อรถที่ฝากระโปรงหน้าล็อคอยู่ ใช่ คุณอาจมีผู้เชี่ยวชาญที่สามารถเปลี่ยนสายพานราวลิ้นได้ แต่มีเพียงผู้ที่ขายโซลูชันนี้ให้กับคุณเท่านั้นที่สามารถเปิดฝากระโปรงหน้าได้ โดยส่วนตัวแล้ว ฉันไม่ชอบวิธีแก้ปัญหาที่เข้ากันไม่ได้ คุณจะบอกว่าคุณอาจไม่ต้องไปอยู่ใต้ฝากระโปรง ใช่ เป็นไปได้ แต่ฉันจะดูคุณเมื่อคุณต้องการประกอบฟังก์ชันขนาดใหญ่ในระบบคลาวด์จากเครื่องเสมือน 20-30 เครื่อง เครือข่าย 40-50 เครือข่าย ครึ่งหนึ่งต้องการออกไปข้างนอก และครึ่งหลังขอ การเร่งความเร็ว SR-IOV ไม่เช่นนั้นคุณจะต้องใช้รถเหล่านี้อีกสองสามโหล - ไม่เช่นนั้นประสิทธิภาพจะไม่เพียงพอ

มีมุมมองอื่น ๆ ดังนั้นคุณเท่านั้นที่สามารถตัดสินใจว่าจะเลือกอะไร และที่สำคัญที่สุด คุณจะต้องรับผิดชอบต่อการเลือกของคุณ นี่เป็นเพียงความคิดเห็นของฉัน - บุคคลที่ได้เห็นและสัมผัสผลิตภัณฑ์อย่างน้อย 4 รายการ ได้แก่ Nokia, Juniper, Red Hat และ VMWare นั่นคือฉันมีบางสิ่งที่จะเปรียบเทียบด้วย

ที่มา: will.com