การลบสแนปชอตช้าอย่างไม่น่าเชื่อ


13

ฉันมีกล่อง ESXi พร้อมที่เก็บ HP LeftHand ที่เปิดเผยผ่าน iSCSI

ฉันมีเครื่องเสมือนที่มีดิสก์ 1TB ซึ่งมีการใช้งาน 800GB ดิสก์มีการจัดเตรียมแบบหนาบนที่เก็บข้อมูล LeftHand

สแน็ปช็อตเปิดอยู่บน VM (เพื่อให้การสำรองข้อมูลและการกู้คืนของ Veeam สามารถทำสิ่งนั้นได้) และเปิดประมาณ 6 ชั่วโมง แผ่นเดลต้าประมาณ 5GB ถูกสร้างขึ้นในช่วงเวลานี้

ขณะนี้การลบสแนปชอตใช้เวลาเกิน 5 ชั่วโมงและยังไม่เสร็จสมบูรณ์ อาร์เรย์หน่วยเก็บข้อมูลกำลังรายงานว่าไม่มี IOPS ในอาร์เรย์นั้น (ประมาณ 600 ซึ่งเป็นเสียงรบกวนพื้นหลัง) ไม่มีปริมาณงาน (ประมาณ 8MB / วินาทีซึ่งอีกครั้ง - เสียงรบกวนรอบหลัง) ซึ่งมีความลึกของคิวเฉลี่ย 9

กล่าวอีกนัยหนึ่งกระบวนการรวมภาพรวมดูเหมือนจะไม่ถูกผูกไว้กับ IO ฉันไม่เห็นสิ่งใดที่ทำให้การลบภาพรวมทำงานช้ามาก มันจะทำงานตัดสินโดยดูไฟล์เดลต้า

มีอะไรอีกบ้างที่ฉันควรดูว่าทำไมสแนปชอต (ค่อนข้างเล็ก) นี้จึงถูกลบออกช้ามาก?


ตามเอกสารของ VMWareฉันกำลังดูls -lh | grep -E "delta|flat|sesparse"อยู่ตอนนี้และฉันเห็นไฟล์เดลต้าสองไฟล์ที่เปลี่ยนแปลง:

-rw-------    1 root     root      194.0M Jun 15 01:28 EXAMPLE-000001-delta.vmdk
-rw-------    1 root     root      274.0M Jun 15 01:27 EXAMPLE-000002-delta.vmdk

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

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

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


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


ฉันไม่สามารถสังเกตเห็นได้ว่า 8Mbit / วินาทีนั้นใกล้กับเครือข่าย 10Mbit / วินาทีลบค่าใช้จ่าย โอกาสใด ๆ ที่เป็นปัญหาเกี่ยวกับเครือข่ายในลิงค์ iSCSI - แพตช์หลบซึ่งเพิ่งเริ่มล้มเหลว? มันเป็นลิงค์เดียวโฮสต์เดียวเป็นโฮสต์หรือไม่ปฏิบัติตามตกลงสำหรับการอ่าน / เขียนอย่างยั่งยืน? คุณสามารถตรวจสอบข้อผิดพลาดพอร์ตสวิตช์ได้หรือไม่
TessellatingHeckler

@TessellatingHeckler ฉันเพิ่งทำการทดสอบบางอย่างและฉันยังสามารถรับประมาณ 1.5Gbit / วินาทีตามลำดับจากอาร์เรย์ซึ่งเป็นสิ่งที่ฉันคาดว่าจะได้รับจากมันภายใต้สถานการณ์ปกติ เมื่อคืนที่ผ่านมาการถอดสแน็ปช็อตใช้เวลาสามนาทีซึ่งเร็วที่สุดเท่าที่ฉันเคยเห็นมา (โดยปกติมันยาวประมาณ 10x แต่มีเกมฟุตบอลขนาดใหญ่อยู่ที่นี่เมื่อคืนที่แล้วดังนั้นฉันสงสัยว่าไม่มีใครใช้ระบบหลังจากชั่วโมง เมื่อการสำรองข้อมูลทำงานดังนั้นเดลต้าขนาดเล็กและเวลาการส่งมอบขนาดเล็ก) ดังนั้นจึงสามารถทำได้อย่างรวดเร็วเพียงแค่ครั้งเดียวที่มันไม่ได้
Mark Henderson

อืมมม คุณมี VMware Storage IO Control ทำงานอยู่หรือไม่และที่เก็บข้อมูลร่วมกับ VM อื่นหรือไม่ โอกาสใดบ้างที่มีการกดปุ่มควบคุมปริมาณ / จำกัด ที่นั่นโดยไม่ต้องเน้นโฮสต์หรือฮาร์ดแวร์ SAN?
TessellatingHeckler

รุ่น ESXi และ vCenter?
นิลส์

@Nils 5.5 สำหรับทั้งคู่
Mark Henderson

คำตอบ:


2

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

ยิ่งมีการเปลี่ยนแปลงระหว่างสแน็ปช็อตนานเท่าไรการผสานก็จะนานขึ้น


1
ขวายกเว้น 6 ชั่วโมงเพื่อลบสแน็ปช็อตขนาด 5GB นั้นไร้สาระ ตามที่ฉันกล่าวถึงโดยทั่วไปแล้วจะใช้เวลาประมาณ 40 นาทีในการลบสแนปชอตและฉันก็รู้สึกว่า 40 นาทีช้าเกินไปแล้ว นี่เป็นสแน็ปช็อตเพียงตัวเดียวบน VM และการลบสแน็ปช็อตที่มีการเปลี่ยนแปลงใน ESXi รุ่นที่ใหม่กว่าซึ่งลำดับที่พวกเขาถูกเอาออกนั้นไม่สำคัญมากนัก
Mark Henderson

2
ฉันเคยเห็นพฤติกรรมสแนปชอตช้าก่อนที่จะมี I / O เพียงเล็กน้อยในที่จัดเก็บข้อมูล แต่ไม่เคยติดตามมันจนเป็นสาเหตุ ฉันมักจะสันนิษฐานว่าไฮเปอร์ไวเซอร์นั้นกำลังเคี้ยวอยู่บนเดลตาในหน่วยความจำ (เครื่องที่มีปัญหากำลังใช้ที่เก็บข้อมูลแบบต่อพ่วงโดยตรงหรือฉันอาจมองปัญหา SAN ด้วยเช่นกัน แต่ฉันได้ทำการเขียนจนถึง deltas ขนาดใหญ่หรือรหัสที่ไม่ได้เพิ่มประสิทธิภาพในระบบย่อย snapshot ของ VMWare)
voretaq7
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.