เพื่อให้บริการ IaaS (ศูนย์ข้อมูลเสมือน) เรา
KVM, VmWare, Xen, Virtuozzo6/7 รวมถึงคอนเทนเนอร์จาก Virtuozzo เดียวกันได้รับการสนับสนุนเป็นไฮเปอร์ไวเซอร์ของโหนดคอมพิวเตอร์ ตัวเลือกพื้นที่เก็บข้อมูลที่รองรับ ได้แก่ Local, NFS, Ceph และ Virtuozzo Storage
FCO รองรับการสร้างและการจัดการหลายคลัสเตอร์จากอินเทอร์เฟซเดียว นั่นคือคุณสามารถจัดการคลัสเตอร์ Virtuozzo และคลัสเตอร์ KVM + Ceph ได้โดยการสลับระหว่างคลัสเตอร์เหล่านั้นด้วยการคลิกเมาส์
หัวใจหลัก FCO เป็นโซลูชันที่ครอบคลุมสำหรับผู้ให้บริการคลาวด์ ซึ่งนอกเหนือจากการจัดการแล้ว ยังรวมถึงการเรียกเก็บเงินด้วยการตั้งค่าทั้งหมด ปลั๊กอินการชำระเงิน ใบแจ้งหนี้ การแจ้งเตือน ผู้ค้าปลีก ภาษี และอื่นๆ อย่างไรก็ตามส่วนที่เรียกเก็บเงินไม่สามารถครอบคลุมความแตกต่างของรัสเซียทั้งหมดได้ ดังนั้นเราจึงละทิ้งการใช้มันและหันไปใช้โซลูชันอื่น
ฉันพอใจมากกับระบบที่ยืดหยุ่นในการกระจายสิทธิ์ไปยังทรัพยากรคลาวด์ทั้งหมด: รูปภาพ ดิสก์ ผลิตภัณฑ์ เซิร์ฟเวอร์ ไฟร์วอลล์ - ทั้งหมดนี้สามารถ "แบ่งปัน" และให้สิทธิ์ระหว่างผู้ใช้ และแม้กระทั่งระหว่างผู้ใช้ของไคลเอ็นต์ที่แตกต่างกัน ลูกค้าแต่ละรายสามารถสร้างศูนย์ข้อมูลอิสระหลายแห่งในระบบคลาวด์ของตน และจัดการได้จากแผงควบคุมเดียว
ในทางสถาปัตยกรรม FCO ประกอบด้วยหลายส่วน ซึ่งแต่ละส่วนมีรหัสอิสระของตัวเอง และบางส่วนก็มีฐานข้อมูลของตัวเอง
เส้นขอบฟ้า – ผู้ดูแลระบบและส่วนต่อประสานผู้ใช้
Jade – ตรรกะทางธุรกิจ การเรียกเก็บเงิน การจัดการงาน
ไทเกอร์ลิลลี่ – ผู้ประสานงานบริการ จัดการและประสานงานการแลกเปลี่ยนข้อมูลระหว่างตรรกะทางธุรกิจและคลัสเตอร์
XVPผู้จัดการ – การจัดการองค์ประกอบคลัสเตอร์: โหนด พื้นที่เก็บข้อมูล เครือข่าย และเครื่องเสมือน
XVPAตัวแทน – เอเจนต์ที่ติดตั้งบนโหนดเพื่อโต้ตอบกับ XVPManager
เราวางแผนที่จะรวมเรื่องราวโดยละเอียดเกี่ยวกับสถาปัตยกรรมของแต่ละองค์ประกอบไว้ในบทความชุดหนึ่ง หากแน่นอนว่าหัวข้อนั้นกระตุ้นความสนใจ
ข้อได้เปรียบหลักของ 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 และสั่งให้บริการอ่านการกำหนดค่าอีกครั้ง ส่วนต่อประสานกับผู้ใช้นั้นดีและสามารถสร้างแบรนด์ได้อย่างง่ายดาย
อย่างที่คุณเห็นอินเทอร์เฟซประกอบด้วยวิดเจ็ตที่ผู้ใช้สามารถควบคุมได้ เขาสามารถเพิ่ม/ลบวิดเจ็ตออกจากเพจได้อย่างง่ายดาย จึงเป็นการสร้างแดชบอร์ดที่เขาต้องการ
แม้จะมีลักษณะปิด แต่ FCO ก็เป็นระบบที่ปรับแต่งได้สูง มีการตั้งค่าและจุดเริ่มต้นจำนวนมากสำหรับการเปลี่ยนเวิร์กโฟลว์:
- รองรับปลั๊กอินแบบกำหนดเอง เช่น คุณสามารถเขียนวิธีการเรียกเก็บเงินของคุณเองหรือทรัพยากรภายนอกของคุณเองเพื่อมอบให้แก่ผู้ใช้ได้
- รองรับทริกเกอร์แบบกำหนดเองสำหรับเหตุการณ์บางอย่าง เช่น การเพิ่มเครื่องเสมือนเครื่องแรกให้กับไคลเอนต์เมื่อถูกสร้างขึ้น
- รองรับวิดเจ็ตที่กำหนดเองในอินเทอร์เฟซ เช่น การฝังวิดีโอ 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