สถานการณ์การสูญเสียข้อมูล ZFS


27

ฉันกำลังมองหาการสร้าง ZFS Pool ขนาดใหญ่ (150TB +) และฉันอยากได้ยินประสบการณ์ของผู้คนเกี่ยวกับสถานการณ์การสูญเสียข้อมูลเนื่องจากฮาร์ดแวร์ที่ล้มเหลวโดยเฉพาะอย่างยิ่งการแยกแยะระหว่างอินสแตนซ์ที่ข้อมูลบางส่วนสูญหายไปกับระบบไฟล์ทั้งหมด ของหากมีความแตกต่างดังกล่าวใน ZFS)

ตัวอย่างเช่นสมมติว่า vdev สูญหายเนื่องจากความล้มเหลวเช่นกล่องหุ้มไดรฟ์ภายนอกสูญเสียพลังงานหรือการ์ดคอนโทรลเลอร์ล้มเหลว จากสิ่งที่ฉันอ่านพูลควรเข้าสู่โหมดที่มีความผิดพลาด แต่ถ้า vdev ถูกส่งคืนพูลควรกู้คืนได้หรือไม่? หรือไม่? หรือถ้า vdev ได้รับความเสียหายบางส่วนหนึ่งจะสูญเสียพูลทั้งหมดบางไฟล์ ฯลฯ ?

จะเกิดอะไรขึ้นหากอุปกรณ์ ZIL ล้มเหลว หรือแค่หนึ่งใน ZILs หลายอัน?

เรื่องราวเล็ก ๆ น้อย ๆ หรือสถานการณ์สมมุติที่ได้รับการสนับสนุนโดยความรู้ทางเทคนิคอย่างแท้จริงจะได้รับการชื่นชม!

ขอบคุณ!

ปรับปรุง:

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

ข้อมูลส่วนใหญ่เป็นไฟล์ขนาดเล็กโดยนับของฉันประมาณ 500k ไฟล์ต่อ TB

ข้อมูลมีความสำคัญ แต่ไม่สำคัญมาก เราวางแผนที่จะใช้พูล ZFS เพื่อจำลองอาร์เรย์ข้อมูล "สด" 48TB (ใช้งานเป็นเวลา 3 ปีหรือมากกว่านั้น) และใช้พื้นที่เก็บข้อมูลที่เหลือสำหรับข้อมูล 'ที่เก็บถาวร'

พูลจะถูกแบ่งใช้โดยใช้ NFS

ชั้นวางนั้นอยู่บนสายสร้างเครื่องกำเนิดไฟฟ้าสำรองและเรามี UPS APC สองเครื่องที่สามารถจ่ายพลังงานให้กับแร็คที่โหลดเต็มเป็นเวลา 5 นาทีหรือมากกว่านั้น


2
หากคุณยังไม่ทราบว่ากำลังทำอะไรอยู่ขอคำปรึกษาและ / หรือรับหลักสูตร ฉันสงสัยเฉพาะทั้งหมดที่คุณต้องการสามารถครอบคลุมในคำตอบง่ายๆ
— ลูคัสคอฟฟ์แมน

3
ดังนั้นคุณยังคงวางแผนที่จะใช้ผู้บริโภค cheapo 7.2 SATA อยู่ใช่ไหม? ถอนหายใจ
— Chopper3

@ Chopper3 ที่จริงแล้วฉันตั้งใจไม่ได้บอกว่า ... ฉันกำลังพิจารณาอย่างจริงจังในการซื้อไดรฟ์ SAS 2TB แทนที่จะเป็นไดรฟ์ SATA 3TB แม้ว่าฉันเคยเห็นผู้คนมากมายพูดว่าพวกเขาใช้ไดรฟ์ SATA ได้ดี ....
— Cyclone

1
ดิสก์ SATA สำหรับ ZFS ไม่ใช่ส่วนผสมที่ดีจริงๆ คุณจะไม่พบคนจำนวนมากแนะนำการตั้งค่าในปัจจุบัน ในระดับที่คุณกำลังพูดถึง (150TB) มันเป็นข้อผิดพลาดราคาแพงและไม่จำเป็น ลองดูที่นี้แม้ว่า
— ewwhite

คำตอบ:


22

ออกแบบวิธีที่ถูกต้องและคุณจะลดโอกาสในการสูญเสียข้อมูลของ ZFS คุณยังไม่ได้อธิบายสิ่งที่คุณเก็บไว้ในสระว่ายน้ำ ในแอปพลิเคชันของฉันส่วนใหญ่ให้บริการ VMWare VMDK และการส่งออก zvols ผ่าน iSCSI 150TB ไม่ได้เป็นเรื่องเล็กน้อยดังนั้นฉันจะพึ่งพาผู้เชี่ยวชาญเพื่อรับคำแนะนำ

ฉันไม่เคยสูญเสียข้อมูลกับ ZFS

ฉันมีประสบการณ์อย่างอื่น:

แต่จากทั้งหมดนี้ไม่เคยมีการสูญเสียข้อมูลที่ประเมินได้ เพียงแค่หยุดทำงาน สำหรับ VMWare VMDK นั่งอยู่บนที่เก็บข้อมูลนี้บ่อยครั้งที่ fsck หรือ reboot จำเป็นต่อการเกิดเหตุการณ์ แต่ไม่แย่ไปกว่าเซิร์ฟเวอร์อื่น ๆ

สำหรับการสูญเสียอุปกรณ์ ZIL นั้นขึ้นอยู่กับการออกแบบสิ่งที่คุณจัดเก็บและ I / O ของคุณและรูปแบบการเขียน อุปกรณ์ ZIL ที่ฉันใช้มีขนาดค่อนข้างเล็ก (4GB-8GB) และทำงานเหมือนเขียนแคช บางคนสะท้อนอุปกรณ์ ZIL การใช้อุปกรณ์ STEC SSD ระดับไฮเอนด์ทำให้สะท้อนต้นทุนได้ ฉันใช้การ์ดDDRDrive PCIe เดียวแทน วางแผนสำหรับการป้องกันแบตเตอรี่ / UPS และใช้การ์ด SSD หรือการ์ด PCIe ที่มีการสำรองข้อมูลตัวเก็บประจุแบบซุปเปอร์ (คล้ายกับตัวควบคุม RAID BBWC และการใช้งาน FBWC )

ที่สุดของประสบการณ์ของผมที่ได้รับใน Solaris / OpenSolaris และNexentaStorด้านของสิ่งที่ ฉันรู้ว่าผู้คนใช้ ZFS บน FreeBSD แต่ฉันไม่แน่ใจว่ารุ่น Zpool และคุณสมบัติอื่น ๆ นั้นไกลแค่ไหน สำหรับการปรับใช้ที่เก็บข้อมูลอย่างแท้จริงฉันขอแนะนำให้ไปตามเส้นทางของ Nexentastor (และพูดคุยกับพันธมิตรที่มีประสบการณ์ ) เนื่องจากเป็นระบบปฏิบัติการที่สร้างขึ้นตามวัตถุประสงค์


ฉันอัปเดตคำถามของฉันพร้อมข้อมูลเพิ่มเติม แต่ฉันสนใจที่จะทราบรายละเอียดเพิ่มเติมเกี่ยวกับ: 'ไม่เคยสูญเสียข้อมูลอย่างเห็นได้ชัด' และสิ่งที่มีความหมาย / เกี่ยวข้อง สนใจที่จะทราบเพิ่มเติมเกี่ยวกับการกู้คืน zpools ที่มีข้อผิดพลาดเหล่านั้นจัดการ NIC ที่ไม่ดีและแม้แต่ปัญหาเกี่ยวกับไดรฟ์ SATA และเปลี่ยนไปใช้ SAS (แม้ว่าคุณจะมีความสุขที่จะรู้ก็ตาม ตามคำแนะนำของคุณ)
— พายุไซโคลน

แบบไม่เห็นการสูญเสีย == ไม่กี่วินาทีของข้อมูลการทำธุรกรรมหรือรัฐผิดพลาดที่สอดคล้องกัน และ NIC ที่ไม่ดีนั้นถูกแยกไปยังโฮสต์ VMWare เดียวและทำให้เกิดปัญหาที่ระดับ VM ไม่ใช่ที่เก็บข้อมูล ZFS พื้นฐาน
— ewwhite

design the right wayลิงค์เสียตอนนี้
— Saurabh Nanda

11

ฉันเขียนทับ ZILs ทั้งสองเวอร์ชั่นโดยไม่ตั้งใจใน OpenSolaris เวอร์ชันล่าสุดซึ่งทำให้พูลทั้งหมดหายไปอย่างถาวร (ความผิดพลาดที่แย่จริงๆในส่วนของฉัน! ฉันไม่เข้าใจว่าการสูญเสีย ZIL หมายถึงการสูญเสียสระว่ายน้ำ

แม้ว่ารุ่น 151a จะเป็นอย่างไร (ไม่ทราบทันทีว่ารุ่น ZPool หมายถึงอะไร) ปัญหานี้ได้รับการแก้ไขแล้ว และฉันสามารถเป็นพยานได้ว่ามันใช้งานได้

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

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

ถ้าหากคุณไม่ต้องการลงไปใน ACL-hell อย่าใช้เซิร์ฟเวอร์ CIFS ในตัวไปยัง ZFS ใช้ Samba (คุณบอกว่าคุณใช้ NFS)

ฉันไม่เห็นด้วยกับอาร์กิวเมนต์ SAS กับ SATA อย่างน้อยข้อเสนอแนะที่ SAS ต้องการมากกว่า SATA สำหรับ ZFS ฉันไม่ทราบว่าข้อคิดเห็น [s] นั้นอ้างอิงถึงความเร็วการหมุนของแผ่นเสียงความน่าเชื่อถือที่สันนิษฐานความเร็วของอินเทอร์เฟซหรือคุณลักษณะอื่น ๆ (หรืออาจเป็นแค่ "พวกเขามีราคาสูงกว่าและโดยทั่วไปจะไม่ได้ใช้โดยผู้บริโภคดังนั้นพวกเขาจึงดีกว่า" การสำรวจอุตสาหกรรมที่เพิ่งเปิดตัว (ยังคงอยู่ในข่าวที่ฉันแน่ใจ) เปิดเผยว่า SATA จริง ๆ แล้วมีประสิทธิภาพเหนือกว่า SAS ขนาดตัวอย่างที่สำคัญของแบบสำรวจ (ทำให้ฉันตกใจอย่างแน่นอน) ฉันจำไม่ได้ว่าเป็นรุ่น "องค์กร" ของ SATA หรือผู้บริโภคหรือความเร็วเท่าไหร่ - แต่จากประสบการณ์ที่มากพอโมเดลองค์กรและผู้บริโภคก็ล้มเหลวในเวลาเดียวกัน อัตรานัยสำคัญทางสถิติ (มีปัญหาเรื่องไดรฟ์สำหรับผู้บริโภคที่ใช้เวลาในการล้มเหลวนานเกินไปซึ่งเป็นสิ่งสำคัญอย่างยิ่งในองค์กร - แต่นั่นไม่ได้กัดฉันและฉันคิดว่ามันเกี่ยวข้องกับตัวควบคุมฮาร์ดแวร์ที่สามารถใช้งานได้ทั้งหมด ในกรณีเช่นนี้ แต่นั่นไม่ใช่ปัญหา SAS vs SATA และ ZFS ไม่เคยล้มเหลวจากฉันจากประสบการณ์นั้นตอนนี้ฉันใช้ไดรฟ์ 1/3 ขององค์กรและ 2/3 Consumer SATA .) นอกจากนี้ฉันไม่เคยเห็นประสิทธิภาพการทำงานที่สำคัญของการผสมผสานของ SATA นี้เมื่อกำหนดค่าอย่างเหมาะสม (เช่นแถบของกระจกสามทาง) แต่จากนั้นอีกครั้งฉันมีความต้องการ IOPS ต่ำดังนั้นขึ้นอยู่กับว่าร้านค้าของคุณมีขนาดเท่าใด กรณีการใช้งานทั่วไป YMMV ฉันได้สังเกตเห็นอย่างแน่นอนว่าขนาดแคชในตัวต่อดิสก์มีความสำคัญต่อปัญหาเวลาในการตอบสนองมากกว่าความเร็วในการหมุนของแผ่นเสียง

กล่าวอีกนัยหนึ่งมันคือซองจดหมายที่มีพารามิเตอร์หลายตัว: ค่าใช้จ่ายปริมาณงาน IOPS ประเภทข้อมูลจำนวนผู้ใช้แบนด์วิดท์การดูแลระบบและกรณีใช้งานทั่วไป ในการพูดว่า SAS นั้นเป็นทางออกที่ถูกต้องเสมอคือไม่ต้องคำนึงถึงการเปลี่ยนแปลงอันใหญ่หลวงของปัจจัยเหล่านั้น

แต่อย่างใด ZFS ก็สั่นสะเทือนอย่างแน่นอน


3
ขอบคุณที่สละเวลาตอบ ประสบการณ์ของคุณกับ ZFS นั้นสอดคล้องกับของฉัน ความคิดเห็นของฉันเกี่ยวกับการเลือกไดรฟ์นั้นเกี่ยวกับ SAS ใกล้กับดิสก์ SATA ความแตกต่างที่สำคัญคืออินเทอร์เฟซ พวกมันเทียบเท่าเครื่องจักร แนวปฏิบัติที่ดีที่สุดใน ZFS-land ในขณะนี้คือการหลีกเลี่ยง SATA เนื่องจากความต้องการอินเตอร์เฟซแบบดูอัลพอร์ตการแก้ไขข้อผิดพลาดที่ดีขึ้นและการจัดการไทม์เอาต์ที่จัดการได้โดย SAS
— ewwhite

ฉันลงเอยด้วยดิสก์ 3TB SAS แต่ .... ก่อนที่จะทำเช่นนั้นฉันจึงปูด้วยกันดิสก์ผสม 30 แผ่นหรือมากกว่านั้น (5 400GB SATA, 12 750GB SATS, 14 1TB SAS) ที่ฉันใส่ไว้ใน SAS ตัวเดียวกัน เป็นกรณีที่เลวร้ายที่สุดจริงๆตาม ไดรฟ์เหล่านี้มีรันไทม์ประมาณ 2-3 ปีแล้ว ฉันเขียนโปรแกรมที่รัน 8 เธรดโดยสุ่มอ่านการเขียนและการลบไฟล์ไปยังพูล ฉันวิ่งมานานกว่าหนึ่งสัปดาห์ อ่านและเขียน> 100 TB ลงในพูล ... ไม่มีปัญหา AVG R / W 100-400MB / วินาที ฉันสงสัยว่า SATA บนคำเตือน SAS อาจเป็นข่าวเก่าในขณะนี้
— พายุไซโคลน
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.