การรันอย่างถาวรใน VMWare snapshot ไม่ดีต่อประสิทธิภาพหรือไม่?

ฉันเข้าใจว่า VMWare KB ขมวดคิ้วจากสแนปชอตที่ใช้เวลานานเนื่องจากสองสิ่ง (ในความคิดของฉัน)

การถ่ายภาพสแนปชอตเป็นตันสามารถเติมที่เก็บข้อมูลได้ Snapshots เป็นเพียงไฟล์เดลต้า สมมติว่าคุณมี 50 Gigd VMDK ใกล้เต็มแล้วถ่ายสแน๊ปช็อต ในภาพรวมของคุณคุณพลิกทุกบิต ไฟล์เดลต้าของคุณจะมีขนาดประมาณ 50 GB สแนปชอตอีกครั้งพลิกบิตไฟล์เดลต้าอีก 50 กิกะ สิ่งเหล่านี้สามารถควบคุมได้อย่างรวดเร็ว
การทำภาพรวมขนาดใหญ่นั้นมีความเสี่ยง เมื่อรวมสแนปชอตคุณกำลังเขียนการเปลี่ยนแปลงของเดลต้าลงใน VMDK ดั้งเดิม สิ่งนี้ต้องใช้เวลาและมีความเสี่ยงว่าถ้ามีอะไรเกิดขึ้นคุณเพียงแค่ทำการดอง VMDK ของคุณ

คำเตือนของพวกเขาดูเหมือนสมเหตุสมผล

เมื่อพูดถึงมันเป็นสิ่งที่เลวร้ายหรือไม่ที่เรียกใช้เครื่องของฉันอย่างถาวรจาก snapshot VMDK ฉันต้องการทำให้ต้นไม้ของฉันต่อไปนี้:

ฐาน
- Snap1
  - สแน็ป 2
  - คุณอยู่ที่นี่

Snap 1 และ 2 จะดำเนินการทันทีหลังจากติดตั้งและเตรียมระบบพื้นฐาน เป็นเครื่องที่ฉันวางแผนจะรีเฟรชเป็นประจำดังนั้นฉันจะทำให้ต้นไม้ของฉันดูเหมือนสิ่งต่อไปนี้:

ฐาน
- Snap1
  - คุณอยู่ที่นี่
  - สแน็ป 2

ลบ Snap2 และสร้าง Snap2 ใหม่

ฉันไม่สามารถดูว่าสิ่งนี้อาจมีความหมายด้วยเหตุผลใด ๆ ต่อไปนี้:

เนื่องจากฉันเพิ่งติดตั้งอิมเมจพื้นฐานและนำเดลต้าของฉันทันทีหลังจากที่ฉันไม่สามารถเติมที่เก็บข้อมูลได้ สมมติว่าภาพฐานของฉันมีเพียง 10 GB (บนดิสก์ที่จัดเตรียมแบบบางขนาด 50 GB) แม้ว่าเดลต้าของฉันจะพลิกทุก ๆ บิตการใช้งานทั้งหมดของฉันสูงสุดอาจเป็น 60 GB (VMDK พื้นฐาน 10 GB ซึ่งถูกล็อก + เดลต้า 50 GB ใน ไฟล์ snapshot VMDK) สิ่งนี้ถือว่าฉันไม่ได้สร้างสแนปชอตเพิ่มเติม
เนื่องจากกรณีการใช้งานของฉันไม่ได้เรียกร้องให้รวมสแนปชอตฉันจึงไม่เสี่ยงข้อผิดพลาดเมื่อรวมเดลตาของฉัน เมื่อฉันย้ายกลับไปที่ Snap1 และลบ Snap2 เดลต้าทั้งหมดที่อยู่ใน Snap2 จะถูกลบ
โหลดหน่วยเก็บนั้นเหมือนกันดังนั้นฉันควรได้รับ IOPS เดียวกัน ฉันเข้าใจว่าไฟล์บางไฟล์ (ส่วนใหญ่เป็นไฟล์ระบบ) จะมีอยู่บน VMDK ดั้งเดิมและอื่น ๆ (ทุกอย่างหลังจากฐาน) จะอยู่ในเดลต้า แต่ฉันไม่เห็นว่า ESXI จะสนใจอย่างไร ไฟล์ทั้งหมดอยู่ในที่เก็บข้อมูลจริงเดียวกันดังนั้นประสิทธิภาพควรเทียบเท่ากับการอ้างอิงทุกอย่างใน VMDK ดั้งเดิมโดยไม่มีสแนปชอต

ความคิดใด ๆ ESXI 5.5 พร้อมที่เก็บข้อมูลเป็น RAID'd DAS

ฉันไม่มีสิทธิ์ใช้งาน vCenter ดังนั้นการสร้างเทมเพลตและการโคลนนิ่งนอกตาราง

ผลการทดสอบ

ฉันมาถึงก่อนวันนี้เพื่อทำการทดสอบ นี่คือผลลัพธ์ มีบทลงโทษ แต่ฉันไม่แน่ใจว่าทำไม

ก่อนสแนปชอต:

หลังจากสแนปชอต: หลังจาก Shapshoting

— VM_Storage_Inception
แหล่งที่มา

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

— peterh - Reinstate Monica

@ PeterHorvath - นั่นคือสิ่งที่ฉันชอบที่จะได้ยิน สมาร์ท, แฮ็ค, มีประสิทธิภาพ, โซลูชั่นกระดูกเปลือย หากคุณไม่รังเกียจคุณสามารถให้ฉันเขียนสิ่งที่คุณทำใน pastebin หรืออะไร? คุณทำ VMDK และสแน็ปช็อตด้วยกันหรือไม่

— VM_Storage_Inception

ถ้าฉันต้องทำบ่อยกว่านี้ฉันก็ทำได้ด้วยสคริปต์ แต่มันไม่ได้เป็นกรณีและในกรณีส่วนใหญ่ฉันไม่ได้ใช้แม้กระทั่ง snapshpts เพราะมันช้า

— peterh - Reinstate Monica

คำตอบ:

ใช่มีความหมายด้านประสิทธิภาพสำหรับภาพรวมระยะยาว มีความหมายที่ยิ่งใหญ่กว่าสำหรับการรวมเดลต้า VMDK กลับไปยังไฟล์ดิสก์ดั้งเดิม สิ่งนี้อาจทำให้ไม่ตอบสนองในระบบปฏิบัติการของ VM หรือพฤติกรรมที่ไม่พึงประสงค์อื่น ๆ

VMware มีฟังก์ชันการสร้างเทมเพลตและการโคลนที่สร้างไว้ใน vCenter คุณต้องมีใบอนุญาต $ 600 vSphere Essentials เพื่อเปิดใช้งานสิ่งนี้

คุณสามารถสร้าง VM เพื่อรสนิยมของคุณจากนั้นโคลนไปยังเทมเพลต แม่แบบนั้นสามารถใช้เพื่อสร้างเครื่องเสมือนใหม่จากอิมเมจ "Golden Master"

ป้อนคำอธิบายรูปภาพที่นี่

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

— ewwhite
แหล่งที่มา

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

— VM_Storage_Inception

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

— VM_Storage_Inception

ฉันเดาว่าฉันพยายามเข้าใจว่าทำไมคุณถึงยืนยันที่จะออกแบบคุณลักษณะที่ควรใช้สำหรับการเข้าถึงระยะสั้น

— ewwhite

@VM_Storage_Inception - ดูเหมือนว่าคุณต้องการแนวทางที่ไม่ดีของคนที่ใช้ Lab Manager ผลิตภัณฑ์ที่หมดอายุของ VMWare

— TheCleaner

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

— ewwhite

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

คุณสร้าง VM การอ่านเสมือนจาก vmdk ใช้เวลาหนึ่งการอ่านฟิสิคัลดิสก์ที่มีขนาดเท่ากัน ค่อนข้างตรงไปตรงมา

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

สำหรับสแนปชอตสองรายการคุณกำลังอ่านสามครั้งเป็นต้น หากคุณมีสแนปชอตจำนวนมากคุณสามารถดูว่านี่จะเป็นโทษต่อประสิทธิภาพอย่างมากหรือไม่ ไม่จำเป็นต้องแปลเป็นประสิทธิภาพที่แย่ลง n-times (เนื่องจากการแคชส่วนที่ไม่ได้เปลี่ยนแปลง ฯลฯ ) แต่ก็ไม่ใช่วิธีปฏิบัติที่ดี

— tfrederick74656
แหล่งที่มา

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

— Guntram Blohm สนับสนุน Monica

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

— tfrederick74656

ที่อาจถูกต้อง แต่จำนวนบล็อกทั้งหมดที่คุณต้องอ่านยังคงเหมือนเดิม (เช่น 10 บล็อกจากสแนปชอตและ 100 จากดิสก์ฐาน) ESXi ตรวจสอบสแน็ปช็อตที่มีอยู่ก่อนเพื่อหาบล็อกที่จำเป็นจนกว่าจะสิ้นสุดที่สแน็ปช็อตที่ถูกต้อง (หรือดิสก์ฐาน) อาจมีบทลงโทษเล็กน้อยเนื่องจากระบบอาจข้ามส่วนสแน็ปช็อตนั้นไปโดยสิ้นเชิงเมื่อไม่มีสแนปชอตเลย นอกจากนี้ไฟล์สแนปชอตที่รันเป็นเวลานานอาจมีปัญหาการแตกแฟรกเมนต์ที่รุนแรง

— Dirk Trilsbeek

ระบบสแนปชอตดิสก์เสมือนที่ทำ N อ่านสำหรับ N สแนปชอตจะเป็นการใช้งานที่โง่มาก ฉันสงสัยว่าเป็นวิธีที่ใช้ใน VMWare การปรับให้เหมาะสมอย่างง่ายสามารถทำได้โดยเพียงสร้างไฟล์ดัชนีที่เก็บดิสก์ไฟล์แต่ละบล็อกของไดรฟ์ที่จำลอง สมมติว่าคุณมีดิสก์เสมือน 512GB ที่มีขนาดบล็อกเท่ากับ 4kB คุณต้องใช้ดัชนี 64 MB เพื่อกำหนดเวลาคงที่ซึ่งไฟล์ดิสก์เสมือนสูงสุด 16 ไฟล์มีบล็อก

— Lie Ryan

ตามคำตอบใน serverfault.com/questions/430138 ฉันต้องไม่เห็นด้วย ฉันคิดถึงสแนปชอตเสมอมาจากเลขฐานสองไม่ใช่แค่การรวบรวมข้อมูลใหม่ ดังนั้นถ้าคุณมีบิต 01010101 ใน VMDK พื้นฐานของคุณคุณจะจับภาพจากนั้นเปลี่ยนบิตเหล่านั้นเป็น 10101010 เดลต้าของคุณจะมี 11111111 (บ่งชี้ว่าทุกบิตในไฟล์ต้นฉบับเปลี่ยนไม่ใช่ค่าใหม่ของ 10101010) เท่าที่ฉันเห็นด้วยกับความคิดเห็นข้างต้น VMDKs เป็นไฟล์ดิบที่คาดคะเน ดัชนีจะถูกเก็บไว้ที่ไหน? ฉันไม่เคยเห็นสิ่งนี้กล่าวถึงในผับเทคโนโลยี VMWare ใด ๆ

— tfrederick74656

VMware ESX snapshots มีไว้สำหรับการใช้งานระยะสั้น

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

คุณสามารถดำเนินการ templating VM ด้วยตนเองผ่าน ssh คัดลอกโฟลเดอร์ VM ที่มี vmdk, vmx ฯลฯ ไปยังโฟลเดอร์ใหม่หนึ่งโฟลเดอร์ ในไฟล์ vmx ของ VM ที่คัดลอกใหม่เปลี่ยน UID และที่อยู่ MAC

VMware มีผลิตภัณฑ์ Linked Clone ซึ่งเป็นสิ่งเดียวกันกับที่คุณพยายามทำ และพวกเขาบอกว่ามันมีปัญหาประสิทธิภาพการทำงานที่อาจเกิดขึ้น ในทางปฏิบัติคุณจะทำการปรับแต่ง VMs ใหม่หลังจากนั้นไม่นาน https://www.vmware.com/support/ws5/doc/ws_clone_typeofclone.html

— ริโอ
แหล่งที่มา