В เราได้พูดคุยเกี่ยวกับความพยายามของเราในการใช้ Watcher และจัดทำรายงานการทดสอบ เราทำการทดสอบดังกล่าวเป็นระยะๆ เพื่อความสมดุลและฟังก์ชันที่สำคัญอื่นๆ ขององค์กรขนาดใหญ่หรือระบบคลาวด์ของผู้ให้บริการ
ความซับซ้อนสูงของปัญหาที่กำลังแก้ไขอาจต้องใช้บทความหลายบทความเพื่ออธิบายโครงการของเรา วันนี้เรากำลังเผยแพร่บทความที่สองในชุดนี้ ซึ่งเน้นเรื่องการปรับสมดุลเครื่องเสมือนในระบบคลาวด์
บางคำศัพท์
บริษัท VmWare เปิดตัวยูทิลิตี้ DRS (Distributed Resource Scheduler) เพื่อสร้างสมดุลภาระของสภาพแวดล้อมการจำลองเสมือนที่พวกเขาพัฒนาและนำเสนอ
ตามที่
“VMware DRS (Distributed Resource Scheduler) เป็นยูทิลิตี้ที่สร้างสมดุลระหว่างโหลดการประมวลผลกับทรัพยากรที่มีอยู่ในสภาพแวดล้อมเสมือน ยูทิลิตี้นี้เป็นส่วนหนึ่งของชุดการจำลองเสมือนที่เรียกว่า VMware Infrastructure
ด้วย VMware DRS ผู้ใช้จะกำหนดกฎสำหรับการกระจายทรัพยากรทางกายภาพระหว่างเครื่องเสมือน (VM) สามารถกำหนดค่ายูทิลิตีสำหรับการควบคุมด้วยตนเองหรืออัตโนมัติได้ พูลทรัพยากร VMware สามารถเพิ่ม ลบ หรือจัดระเบียบใหม่ได้อย่างง่ายดาย หากต้องการ คุณสามารถแยกกลุ่มทรัพยากรระหว่างหน่วยธุรกิจต่างๆ ได้ หากปริมาณงานบนเครื่องเสมือนตั้งแต่หนึ่งเครื่องขึ้นไปเปลี่ยนแปลงอย่างมาก VMware DRS จะกระจายเครื่องเสมือนใหม่ผ่านเซิร์ฟเวอร์กายภาพ หากปริมาณงานโดยรวมลดลง เซิร์ฟเวอร์จริงบางตัวอาจออฟไลน์ชั่วคราวและปริมาณงานจะรวมเข้าด้วยกัน"
เหตุใดจึงต้องมีความสมดุล?
ในความเห็นของเรา DRS เป็นฟีเจอร์คลาวด์ที่ต้องมี แม้ว่านี่ไม่ได้หมายความว่าจะต้องใช้ DRS เสมอและทุกที่ อาจมีข้อกำหนดที่แตกต่างกันสำหรับ DRS และวิธีการปรับสมดุล ทั้งนี้ขึ้นอยู่กับวัตถุประสงค์และความต้องการของระบบคลาวด์ อาจมีบางสถานการณ์ที่ไม่จำเป็นต้องมีการปรับสมดุลเลย หรือแม้กระทั่งเป็นอันตราย
เพื่อให้เข้าใจได้ดีขึ้นว่าจำเป็นต้องใช้ DRS ของลูกค้าที่ไหนและสำหรับกลุ่มใด เราจะมาพิจารณาเป้าหมายและวัตถุประสงค์ของลูกค้ากัน คลาวด์สามารถแบ่งออกเป็นสาธารณะและส่วนตัว ต่อไปนี้เป็นข้อแตกต่างหลักๆ ระหว่างระบบคลาวด์เหล่านี้กับเป้าหมายของลูกค้า
คลาวด์ส่วนตัว / ไคลเอนต์องค์กรขนาดใหญ่
เมฆสาธารณะ / ธุรกิจขนาดกลางและขนาดเล็ก ผู้คน
เกณฑ์หลักและเป้าหมายของผู้ปฏิบัติงาน
การให้บริการหรือผลิตภัณฑ์ที่เชื่อถือได้
การลดต้นทุนการให้บริการในการต่อสู้ในตลาดที่มีการแข่งขันสูง
ข้อกำหนดการบริการ
ความน่าเชื่อถือในทุกระดับและในทุกองค์ประกอบของระบบ
รับประกันประสิทธิภาพ
จัดลำดับความสำคัญของเครื่องเสมือนเป็นหลายประเภท
ความปลอดภัยของข้อมูลและข้อมูลทางกายภาพ
SLA และการสนับสนุนตลอด XNUMX ชั่วโมงทุกวัน
ความสะดวกสูงสุดในการรับบริการ
บริการที่ค่อนข้างง่าย
ความรับผิดชอบต่อข้อมูลขึ้นอยู่กับลูกค้า
ไม่จำเป็นต้องจัดลำดับความสำคัญของ VM
ความปลอดภัยของข้อมูลในระดับมาตรฐานการบริการ ความรับผิดชอบต่อลูกค้า
อาจมีข้อผิดพลาด
ไม่มี SLA ไม่รับประกันคุณภาพ
การสนับสนุนทางอีเมล
ไม่จำเป็นต้องสำรองข้อมูล
คุณสมบัติไคลเอนต์
แอพพลิเคชั่นที่หลากหลายมาก
แอปพลิเคชันแบบเดิมที่สืบทอดมาจากบริษัท
สถาปัตยกรรมแบบกำหนดเองที่ซับซ้อนสำหรับไคลเอนต์แต่ละราย
กฎความสัมพันธ์
ซอฟต์แวร์ทำงานโดยไม่หยุดในโหมด 7x24
เครื่องมือสำรองข้อมูลแบบทันที
ปริมาณงานของลูกค้าตามรอบที่คาดการณ์ได้
แอปพลิเคชันทั่วไป – การปรับสมดุลเครือข่าย, Apache, WEB, VPN, SQL
แอปพลิเคชันอาจหยุดทำงานชั่วขณะหนึ่ง
อนุญาตการกระจาย VM ในระบบคลาวด์โดยพลการ
การสำรองข้อมูลไคลเอนต์
โหลดเฉลี่ยทางสถิติที่คาดการณ์ได้พร้อมไคลเอนต์จำนวนมาก
ผลกระทบต่อสถาปัตยกรรม
การจัดกลุ่มทางธรณีวิทยา
พื้นที่เก็บข้อมูลแบบรวมศูนย์หรือแบบกระจาย
IBS ซ้ำซ้อน
การจัดเก็บข้อมูลภายในเครื่องบนโหนดคอมพิวเตอร์
เป้าหมายที่สมดุล
การกระจายโหลดสม่ำเสมอ
การตอบสนองของแอปพลิเคชันสูงสุด
เวลาหน่วงขั้นต่ำสำหรับการปรับสมดุล
ปรับสมดุลเมื่อจำเป็นอย่างชัดเจนเท่านั้น
นำอุปกรณ์บางอย่างออกมาเพื่อการบำรุงรักษาเชิงป้องกัน
การลดต้นทุนการบริการและต้นทุนผู้ประกอบการ
ปิดการใช้งานทรัพยากรบางอย่างในกรณีที่โหลดน้อย
ประหยัดพลังงาน
การลดต้นทุนบุคลากร
เราได้ข้อสรุปดังต่อไปนี้สำหรับตัวเราเอง:
สำหรับคลาวด์ส่วนตัวให้กับลูกค้าองค์กรขนาดใหญ่ สามารถใช้ DRS ได้ภายใต้ข้อจำกัดต่อไปนี้:
- ความปลอดภัยของข้อมูลและคำนึงถึงกฎความสัมพันธ์เมื่อทำการปรับสมดุล
- ความพร้อมของทรัพยากรที่เพียงพอในกรณีที่เกิดอุบัติเหตุ
- ข้อมูลเครื่องเสมือนตั้งอยู่บนระบบจัดเก็บข้อมูลแบบรวมศูนย์หรือแบบกระจาย
- ขั้นตอนการบริหาร การสำรอง และความสมดุลที่ส่ายไปมาเมื่อเวลาผ่านไป
- ปรับสมดุลภายในการรวมโฮสต์ไคลเอนต์เท่านั้น
- ปรับสมดุลเฉพาะเมื่อมีความไม่สมดุลที่รุนแรง การโยกย้าย VM ที่มีประสิทธิภาพและปลอดภัยที่สุด (ท้ายที่สุดแล้ว การโยกย้ายอาจล้มเหลว)
- ปรับสมดุลเครื่องเสมือนที่ค่อนข้าง "เงียบ" (การโยกย้ายเครื่องเสมือน "ที่มีเสียงดัง" อาจใช้เวลานานมาก)
- ปรับสมดุลโดยคำนึงถึง "ต้นทุน" - โหลดบนระบบจัดเก็บข้อมูลและเครือข่าย (พร้อมสถาปัตยกรรมที่ปรับแต่งสำหรับลูกค้าขนาดใหญ่)
- ปรับสมดุลโดยคำนึงถึงลักษณะพฤติกรรมส่วนบุคคลของ VM แต่ละตัว
- การปรับสมดุลควรทำในช่วงเวลาที่ไม่ใช่เวลาทำงาน (กลางคืน วันหยุดสุดสัปดาห์ วันหยุดนักขัตฤกษ์)
สำหรับคลาวด์สาธารณะการให้บริการแก่ลูกค้ารายย่อย DRS สามารถใช้งานได้บ่อยมากขึ้นด้วยความสามารถขั้นสูง:
- ไม่มีข้อจำกัดด้านความปลอดภัยของข้อมูลและกฎความสัมพันธ์
- ปรับสมดุลภายในคลาวด์
- ปรับสมดุลในเวลาที่เหมาะสม
- ปรับสมดุล VM ใด ๆ
- ปรับสมดุลเครื่องเสมือน "ที่มีเสียงดัง" (เพื่อไม่ให้รบกวนผู้อื่น)
- ข้อมูลเครื่องเสมือนมักจะอยู่บนดิสก์ในเครื่อง
- โดยคำนึงถึงประสิทธิภาพโดยเฉลี่ยของระบบจัดเก็บข้อมูลและเครือข่าย (สถาปัตยกรรมคลาวด์เป็นหนึ่งเดียว)
- ปรับสมดุลตามกฎทั่วไปและสถิติพฤติกรรมของศูนย์ข้อมูลที่มีอยู่
ความซับซ้อนของปัญหา
ความยากในการทรงตัวคือ DRS ต้องทำงานกับปัจจัยที่ไม่แน่นอนจำนวนมาก:
- พฤติกรรมของผู้ใช้ระบบข้อมูลของลูกค้าแต่ละราย
- อัลกอริธึมสำหรับการทำงานของเซิร์ฟเวอร์ระบบสารสนเทศ
- พฤติกรรมของเซิร์ฟเวอร์ DBMS
- โหลดทรัพยากรคอมพิวเตอร์ ระบบจัดเก็บข้อมูล เครือข่าย
- การโต้ตอบของเซิร์ฟเวอร์ระหว่างกันในการต่อสู้เพื่อทรัพยากรคลาวด์
โหลดของเซิร์ฟเวอร์แอปพลิเคชันเสมือนและฐานข้อมูลจำนวนมากบนทรัพยากรคลาวด์เกิดขึ้นเมื่อเวลาผ่านไป ผลที่ตามมาสามารถแสดงออกมาและทับซ้อนกันด้วยผลกระทบที่คาดเดาไม่ได้ในช่วงเวลาที่ไม่สามารถคาดเดาได้ แม้จะควบคุมกระบวนการที่ค่อนข้างง่าย (เช่น การควบคุมเครื่องยนต์ ระบบทำน้ำร้อนที่บ้าน) ระบบควบคุมอัตโนมัติก็ยังจำเป็นต้องใช้ที่ซับซ้อน อัลกอริธึมพร้อมข้อเสนอแนะ
งานของเรามีความซับซ้อนมากขึ้นและมีความเสี่ยงที่ระบบจะไม่สามารถปรับสมดุลโหลดให้เป็นค่าที่กำหนดได้ในเวลาที่เหมาะสม แม้ว่าจะไม่มีอิทธิพลภายนอกจากผู้ใช้ก็ตาม
ประวัติความเป็นมาของการพัฒนาของเรา
เพื่อแก้ไขปัญหานี้ เราตัดสินใจที่จะไม่เริ่มต้นใหม่ทั้งหมด แต่เพื่อสร้างประสบการณ์ที่มีอยู่ และเริ่มโต้ตอบกับผู้เชี่ยวชาญที่มีประสบการณ์ในด้านนี้ โชคดีที่เราเข้าใจปัญหาตรงกันโดยสมบูรณ์
ขั้นตอนที่ 1
เราใช้ระบบที่ใช้เทคโนโลยีโครงข่ายประสาทเทียมและพยายามเพิ่มประสิทธิภาพทรัพยากรของเราตามเทคโนโลยีนั้น
ความสนใจของขั้นตอนนี้คือการทดสอบเทคโนโลยีใหม่ และความสำคัญของมันคือการใช้แนวทางที่ไม่ได้มาตรฐานในการแก้ปัญหา โดยที่สิ่งอื่นๆ ที่เท่าเทียม แนวทางมาตรฐานแทบจะหมดสิ้นไปแล้ว
เราเปิดตัวระบบ และเราเริ่มสร้างสมดุลจริงๆ ขนาดของระบบคลาวด์ของเราไม่ได้ทำให้เราได้รับผลลัพธ์ในแง่ดีตามที่นักพัฒนาระบุไว้ แต่เป็นที่ชัดเจนว่าการปรับสมดุลนั้นได้ผล
ในเวลาเดียวกัน เรามีข้อจำกัดที่ค่อนข้างร้ายแรง:
- ในการฝึกโครงข่ายประสาทเทียม เครื่องเสมือนจะต้องทำงานโดยไม่มีการเปลี่ยนแปลงที่สำคัญเป็นเวลาหลายสัปดาห์หรือหลายเดือน
- อัลกอริธึมได้รับการออกแบบมาเพื่อการปรับให้เหมาะสมตามการวิเคราะห์ข้อมูล "ในอดีต" ก่อนหน้านี้
- การฝึกอบรมโครงข่ายประสาทเทียมต้องใช้ข้อมูลและทรัพยากรการประมวลผลค่อนข้างมาก
- การเพิ่มประสิทธิภาพและการปรับสมดุลสามารถทำได้ค่อนข้างน้อย - ทุกๆ สองสามชั่วโมง ซึ่งเห็นได้ชัดว่าไม่เพียงพอ
ขั้นตอนที่ 2
เนื่องจากเราไม่พอใจกับสถานการณ์ เราจึงตัดสินใจแก้ไขระบบ และต้องตอบคำถามนี้ คำถามหลัก – เราทำเพื่อใคร?
อันดับแรก - สำหรับลูกค้าองค์กร ซึ่งหมายความว่าเราต้องการระบบที่ทำงานได้อย่างรวดเร็ว โดยมีข้อจำกัดขององค์กรที่ทำให้การใช้งานง่ายขึ้นเท่านั้น
คำถามที่สอง – คำว่า “ทันที” คุณหมายถึงอะไร? จากผลการดีเบตสั้นๆ เราตัดสินใจว่าจะเริ่มต้นด้วยเวลาตอบสนองที่ 5–10 นาที เพื่อที่ว่าไฟกระชากในระยะสั้นจะไม่ทำให้ระบบเกิดการสั่นพ้อง
คำถามที่สาม – ขนาดของเซิร์ฟเวอร์ที่สมดุลให้เลือกคือขนาดใด?
ปัญหานี้แก้ไขได้ด้วยตัวเอง โดยทั่วไปแล้ว ไคลเอนต์ไม่ได้ทำให้การรวมเซิร์ฟเวอร์มีขนาดใหญ่มาก และสิ่งนี้สอดคล้องกับคำแนะนำของบทความเพื่อจำกัดการรวมเซิร์ฟเวอร์ไว้ที่ 30-40 เซิร์ฟเวอร์
นอกจากนี้ การแบ่งกลุ่มพูลเซิร์ฟเวอร์ทำให้เราลดความซับซ้อนของงานอัลกอริธึมการปรับสมดุลลง
คำถามที่สี่ – Neural Network เหมาะกับเราแค่ไหนกับกระบวนการเรียนรู้ที่ยาวนานและความสมดุลที่หายาก? เราตัดสินใจละทิ้งมันเพราะหันไปใช้อัลกอริธึมการปฏิบัติงานที่ง่ายกว่าเพื่อให้ได้ผลลัพธ์ในไม่กี่วินาที
คุณสามารถดูคำอธิบายของระบบที่ใช้อัลกอริธึมดังกล่าวและข้อเสียได้
เราปรับใช้และเปิดตัวระบบนี้และได้รับผลลัพธ์ที่น่าพึงพอใจ ในตอนนี้ระบบได้วิเคราะห์ภาระงานบนคลาวด์เป็นประจำและให้คำแนะนำสำหรับการเคลื่อนย้ายเครื่องเสมือน ซึ่งส่วนใหญ่ถูกต้องแล้ว แม้ว่าตอนนี้จะเป็นที่ชัดเจนว่าเราสามารถบรรลุการปล่อยทรัพยากร 10-15% สำหรับเครื่องเสมือนใหม่ในขณะที่ปรับปรุงคุณภาพงานที่มีอยู่
เมื่อตรวจพบความไม่สมดุลใน RAM หรือ CPU ระบบจะออกคำสั่งไปยังตัวกำหนดตารางเวลาของ Tionix เพื่อดำเนินการย้ายเครื่องเสมือนที่จำเป็นแบบเรียลไทม์ ดังที่เห็นได้จากระบบการตรวจสอบ เครื่องเสมือนย้ายจากโฮสต์หนึ่ง (ด้านบน) ไปยังโฮสต์อื่น (ด้านล่าง) และเพิ่มหน่วยความจำบนโฮสต์ด้านบน (เน้นด้วยวงกลมสีเหลือง) ตามลำดับโดยครอบครองที่ด้านล่าง (เน้นด้วยสีขาว วงกลม)
ตอนนี้เรากำลังพยายามประเมินประสิทธิภาพของอัลกอริทึมปัจจุบันให้แม่นยำยิ่งขึ้นและพยายามค้นหาข้อผิดพลาดที่อาจเกิดขึ้น
ขั้นตอนที่ 3
ดูเหมือนว่าใครๆ ก็สามารถสงบสติอารมณ์ในเรื่องนี้ได้ รอการพิสูจน์ประสิทธิภาพแล้วปิดหัวข้อ
แต่เราถูกผลักดันให้ดำเนินการขั้นใหม่ด้วยโอกาสในการเพิ่มประสิทธิภาพที่ชัดเจนดังต่อไปนี้
- สถิติ เช่น и แสดงให้เห็นว่าระบบที่มีโปรเซสเซอร์สองตัวและสี่ตัวมีประสิทธิภาพต่ำกว่าระบบที่ใช้โปรเซสเซอร์ตัวเดียวอย่างมาก ซึ่งหมายความว่าผู้ใช้ทุกคนจะได้รับเอาต์พุตจาก CPU, RAM, SSD, LAN, FC ที่ซื้อในระบบมัลติโปรเซสเซอร์น้อยลงอย่างเห็นได้ชัด เมื่อเทียบกับโปรเซสเซอร์ตัวเดียว
- ตัวกำหนดเวลาทรัพยากรอาจมีข้อผิดพลาดร้ายแรง ในหัวข้อนี้
- เทคโนโลยีที่นำเสนอโดย Intel และ AMD สำหรับการตรวจสอบ RAM และแคชทำให้สามารถศึกษาพฤติกรรมของเครื่องเสมือนและวางไว้ในลักษณะที่เพื่อนบ้านที่ "ส่งเสียงดัง" ไม่รบกวนเครื่องเสมือนที่ "เงียบ"
- การขยายชุดพารามิเตอร์ (เครือข่าย ระบบจัดเก็บข้อมูล ลำดับความสำคัญของเครื่องเสมือน ค่าใช้จ่ายในการย้าย ความพร้อมในการย้าย)
เบ็ดเสร็จ
ผลลัพธ์ของงานของเราในการปรับปรุงอัลกอริธึมการปรับสมดุลคือข้อสรุปที่ชัดเจนว่าการใช้อัลกอริธึมที่ทันสมัยทำให้เป็นไปได้ที่จะเพิ่มประสิทธิภาพทรัพยากรศูนย์ข้อมูลได้อย่างมีนัยสำคัญ (25-30%) และในขณะเดียวกันก็ปรับปรุงคุณภาพการบริการลูกค้า
อัลกอริธึมที่ใช้โครงข่ายประสาทเทียมเป็นวิธีแก้ปัญหาที่น่าสนใจอย่างแน่นอน แต่เป็นสิ่งที่ต้องมีการพัฒนาเพิ่มเติม และเนื่องจากข้อจำกัดที่มีอยู่ จึงไม่เหมาะสำหรับการแก้ปัญหาประเภทนี้บนวอลุ่มทั่วไปสำหรับคลาวด์ส่วนตัว ในขณะเดียวกัน อัลกอริธึมก็แสดงผลลัพธ์ที่ดีในระบบคลาวด์สาธารณะที่มีขนาดสำคัญ
เราจะบอกคุณเพิ่มเติมเกี่ยวกับความสามารถของตัวประมวลผล ตัวกำหนดเวลา และการปรับสมดุลระดับสูงในบทความต่อไปนี้
ที่มา: will.com