Flexiant Cloud Orchestrator: มีอะไรบ้าง

Flexiant Cloud Orchestrator: มีอะไรบ้าง

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

KVM, VmWare, Xen, Virtuozzo6/7 รวมถึงคอนเทนเนอร์จาก Virtuozzo เดียวกันได้รับการสนับสนุนเป็นไฮเปอร์ไวเซอร์ของโหนดคอมพิวเตอร์ ตัวเลือกพื้นที่เก็บข้อมูลที่รองรับ ได้แก่ Local, NFS, Ceph และ Virtuozzo Storage

FCO รองรับการสร้างและการจัดการหลายคลัสเตอร์จากอินเทอร์เฟซเดียว นั่นคือคุณสามารถจัดการคลัสเตอร์ Virtuozzo และคลัสเตอร์ KVM + Ceph ได้โดยการสลับระหว่างคลัสเตอร์เหล่านั้นด้วยการคลิกเมาส์

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

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

Flexiant Cloud Orchestrator: มีอะไรบ้าง

ในทางสถาปัตยกรรม FCO ประกอบด้วยหลายส่วน ซึ่งแต่ละส่วนมีรหัสอิสระของตัวเอง และบางส่วนก็มีฐานข้อมูลของตัวเอง

เส้นขอบฟ้า – ผู้ดูแลระบบและส่วนต่อประสานผู้ใช้
Jade – ตรรกะทางธุรกิจ การเรียกเก็บเงิน การจัดการงาน
ไทเกอร์ลิลลี่ – ผู้ประสานงานบริการ จัดการและประสานงานการแลกเปลี่ยนข้อมูลระหว่างตรรกะทางธุรกิจและคลัสเตอร์
XVPผู้จัดการ – การจัดการองค์ประกอบคลัสเตอร์: โหนด พื้นที่เก็บข้อมูล เครือข่าย และเครื่องเสมือน
XVPAตัวแทน – เอเจนต์ที่ติดตั้งบนโหนดเพื่อโต้ตอบกับ XVPManager

Flexiant Cloud Orchestrator: มีอะไรบ้าง

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

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

# cat /etc/extility/config/vars
…
export LIMIT_MAX_LIST_ADMIN_DEFAULT="30000"
export LIMIT_MAX_LIST_USER_DEFAULT="200"
export LOGDIR="/var/log/extility"
export LOG_FILE="misc.log"
export LOG_FILE_LOG4JHOSTBILLMODULE="hostbillmodule.log"
export LOG_FILE_LOG4JJADE="jade.log"
export LOG_FILE_LOG4JTL="tigerlily.log"
export LOG_FILE_LOG4JXVP="xvpmanager.log"
export LOG_FILE_VARS="misc.log"
…

การกำหนดค่าทั้งหมดได้รับการแก้ไขในเทมเพลต จากนั้นจึงเปิดใช้ตัวสร้าง
#build-config ซึ่งจะสร้างไฟล์ vars และสั่งให้บริการอ่านการกำหนดค่าอีกครั้ง ส่วนต่อประสานกับผู้ใช้นั้นดีและสามารถสร้างแบรนด์ได้อย่างง่ายดาย

Flexiant Cloud Orchestrator: มีอะไรบ้าง

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

แม้จะมีลักษณะปิด แต่ FCO ก็เป็นระบบที่ปรับแต่งได้สูง มีการตั้งค่าและจุดเริ่มต้นจำนวนมากสำหรับการเปลี่ยนเวิร์กโฟลว์:

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

การปรับแต่งทั้งหมดเขียนด้วย FDL ซึ่งอิงจาก Lua ถ้าคุณรู้จัก Lua ก็จะไม่มีปัญหากับ FDL

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

function register()
    return {"pre_user_api_publish"}
end
   
function pre_user_api_publish(p)  
    if(p==nil) then
        return{
            ref = "cancelPublishImage",
            name = "Cancel publishing",
            description = "Cancel all user’s images publishing",
            triggerType = "PRE_USER_API_CALL",
            triggerOptions = {"publishResource", "publishImage"},
            api = "TRIGGER",
            version = 1,
        }
    end

    -- Turn publishing off
    return {exitState = "CANCEL"}
   
end

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

และสิ่งสำคัญคือ return {exitState = “CANCEL”} ซึ่งเป็นสาเหตุที่ทริกเกอร์ได้รับการพัฒนา มันจะคืนค่าความล้มเหลวเมื่อผู้ใช้พยายามแชร์รูปภาพในแผงควบคุม

ในสถาปัตยกรรม FCO ออบเจ็กต์ใดๆ (ดิสก์ เซิร์ฟเวอร์ รูปภาพ เครือข่าย อะแดปเตอร์เครือข่าย ฯลฯ) จะแสดงเป็นเอนทิตีทรัพยากร ซึ่งมีพารามิเตอร์ทั่วไป:

  • UUID ของทรัพยากร
  • ชื่อทรัพยากร
  • ประเภททรัพยากร
  • UUID เจ้าของทรัพยากร
  • สถานะทรัพยากร (ใช้งานอยู่, ไม่ได้ใช้งาน)
  • ข้อมูลเมตาของทรัพยากร
  • คีย์ทรัพยากร
  • UUID ของผลิตภัณฑ์ที่เป็นเจ้าของทรัพยากร
  • ทรัพยากร VDC

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

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

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

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

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

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

รวม: โดยรวมแล้วความประทับใจต่อผลิตภัณฑ์นั้นดี เราติดต่อกับผู้พัฒนาออเคสตราอย่างต่อเนื่อง พวกนั้นเต็มใจที่จะร่วมมืออย่างสร้างสรรค์

แม้จะเรียบง่าย แต่ FCO ก็มีฟังก์ชันการทำงานที่หลากหลาย ในบทความต่อๆ ไป เราวางแผนที่จะเจาะลึกหัวข้อต่อไปนี้:

  • เครือข่ายที่ FCO
  • ให้การกู้คืนสดและโปรโตคอล FQP
  • เขียนปลั๊กอินและวิดเจ็ตของคุณเอง
  • เชื่อมต่อบริการเพิ่มเติมเช่น Load Balancer และ Acronis
  • การสำรองข้อมูล
  • กลไกแบบครบวงจรสำหรับการกำหนดค่าและการกำหนดค่าโหนด
  • การประมวลผลข้อมูลเมตาของเครื่องเสมือน

ZY เขียนความคิดเห็นหากคุณสนใจในด้านอื่น ๆ คอยติดตาม!

ที่มา: will.com

เพิ่มความคิดเห็น