ZFS - ทำลาย zvol ที่ซ้ำซ้อนหรือชุดข้อมูลจะถ่วงเซิร์ฟเวอร์ วิธีการกู้คืน


11

ฉันใช้ Nexentastor บนเซิร์ฟเวอร์จัดเก็บข้อมูลสำรองที่ทำงานบน HP ProLiant DL180 G6 พร้อม 12 ไดรฟ์ Midline (7200 RPM) SAS ระบบมี CPU E5620 และ RAM 8GB ไม่มีอุปกรณ์ ZIL หรือ L2ARC

เมื่อสัปดาห์ที่แล้วฉันสร้าง zvol กระจัดกระจาย 750GB โดยมีการหักและการบีบอัดเปิดใช้งานเพื่อแบ่งปันผ่าน iSCSI ไปยังโฮสต์ VMWare ESX ฉันสร้างอิมเมจเซิร์ฟเวอร์ไฟล์ Windows 2008 และคัดลอกข้อมูลผู้ใช้ ~ 300GB ไปยัง VM เมื่อมีความสุขกับระบบฉันย้ายเครื่องเสมือนไปยังที่จัดเก็บ NFS ในกลุ่มเดียวกัน

ครั้งหนึ่งและทำงานกับ VMs ของฉันในที่เก็บข้อมูล NFS ฉันตัดสินใจที่จะลบ 750GB zvol ดั้งเดิม การทำเช่นนั้นจะทำให้ระบบหยุดชะงัก การเข้าถึง Nexenta เว็บอินเตอร์เฟสและ NMC หยุดทำงาน ในที่สุดฉันก็สามารถเข้าถึงกระสุนดิบได้ การทำงานของระบบปฏิบัติการส่วนใหญ่นั้นใช้งานได้ดี แต่ระบบหยุดทำงานตามzfs destroy -r vol1/filesystemคำสั่ง น่าเกลียด ฉันพบรายการ Bugzilla ของ OpenSolaris สองรายการต่อไปนี้และตอนนี้เข้าใจว่าเครื่องจะถูกปิดกั้นในช่วงเวลาที่ไม่รู้จัก ใช้เวลา 14 ชั่วโมงดังนั้นฉันจึงต้องการแผนเพื่อให้สามารถเข้าถึงเซิร์ฟเวอร์ได้อีกครั้ง

http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6924390

และ

http://bugs.opensolaris.org/bugdatabase/view_bug.do;jsessionid=593704962bcbe0743d82aa339988?bug_id=6924824

ในอนาคตฉันอาจใช้คำแนะนำที่ได้รับจากวิธีแก้ปัญหา buzilla:

Workaround
    Do not use dedupe, and do not attempt to destroy zvols that had dedupe enabled.

อัปเดต: ฉันต้องบังคับให้ระบบปิดเครื่อง Importing zfs filesystemsเมื่อรีบูตระบบแผงลอย มันเป็นอย่างนั้นมา 2 ชั่วโมงแล้ว

คำตอบ:


15

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

อาจเป็นเรื่องศีลธรรมที่ความซ้ำซ้อนไม่ได้ขัดมากและ RAM นั้นมีความสำคัญต่อประสิทธิภาพของมัน ฉันแนะนำ 24GB หรือมากกว่านั้นขึ้นอยู่กับสภาพแวดล้อม มิฉะนั้นปล่อยให้ ZFS dedupe ปิด ไม่เหมาะสำหรับผู้ใช้ตามบ้านหรือระบบขนาดเล็ก


5

ในฐานะที่เป็นผู้ใช้เครื่องใช้ซีรีย์ Sun / Oracle ZFS 7000 มาเป็นเวลานานฉันสามารถบอกคุณได้ว่าคำถามที่ไม่ซ้ำซ้อนก็ไม่ขัด อย่าสับสนระหว่างการขายพร้อมส่ง! พนักงานขายจะบอกคุณว่า "โอ้มันได้รับการแก้ไขแล้ว" ในชีวิตจริง - ชีวิตจริงของฉัน - ฉันสามารถบอกคุณ 24GB ไม่เพียงพอที่จะจัดการ "ตาราง DDT" นั่นคือดัชนีแบ็คเอนด์ที่เก็บตาราง dedupe ตารางนั้นต้องอยู่ในหน่วยความจำระบบเพื่อให้ I / O แต่ละตัวถูกดักจับบนเครื่องบินเพื่อที่จะทราบว่าจำเป็นต้องเขียนลงดิสก์หรือไม่ ยิ่งมีพูลหน่วยเก็บข้อมูลของคุณมากเท่าไหร่การเปลี่ยนแปลงของข้อมูลก็จะยิ่งมากขึ้นเท่านั้นตารางนี้ก็ยิ่งมีมากขึ้นและความต้องการหน่วยความจำระบบก็จะมากขึ้น หน่วยความจำนั้นมาจากค่าใช้จ่ายของ ARC (แคช) และในบางครั้งระบบปฏิบัติการของตัวเอง - ซึ่งเป็นสาเหตุที่ทำให้คุณสัมผัสกับแฮงค์เนื่องจากคำสั่งบางอย่างเกิดขึ้นในเบื้องหน้าบางส่วนอยู่ในพื้นหลัง ดูเหมือนว่าการลบกลุ่มจะเกิดขึ้นในเบื้องหน้าเว้นแต่คุณจะบอกเป็นอย่างอื่นใน CLI ตัวช่วยสร้าง GUI จะไม่ทำสิ่งนี้

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

ในทุกกรณีเว้นแต่คุณจะใช้หน่วยความจำจนหมดแล้วหาวิธีสำรองหน่วยความจำสำหรับระบบปฏิบัติการโดย จำกัด ARC และ DDT (และฉันไม่คิดว่าคุณสามารถ จำกัด DDT ตามลักษณะของมันได้มันเป็นเพียงดัชนีที่เชื่อมโยงอย่างแน่นอน ถึง I / O ของคุณ) จากนั้นคุณจะถูกซ่อนระหว่างการลบขนาดใหญ่หรือการทำลาย zvol / พูล

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.