เซิร์ฟเวอร์จัดเก็บข้อมูลสำรองด้วย ZFS


9

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

สิ่งที่สำคัญที่สุดใน บริษัท คือ SQL Server และฐานข้อมูล มีฐานข้อมูล 10 แห่ง แต่มีเพียง 2 แห่งเท่านั้นที่มีความสำคัญจริงๆ 8GB ตัวแรกซึ่งส่วนใหญ่เป็นข้อมูลตัวอักษรและตัวเลข คนที่สองประมาณ 300GB พร้อม 16GB / เดือนเติบโตที่มี PDF และ GIF

หากต้องการบันทึกนโยบายการสำรองข้อมูลปัจจุบันของหน่วยเก็บประกอบด้วยการสำรองข้อมูลเต็มรูปแบบหนึ่งรายการต่อสัปดาห์และส่วนต่าง 6 รายการ ฉันคิดว่ามันประมาณ 350GB ต่อสัปดาห์ 1.4TB ต่อเดือน

หลังจากอ่านบทความเกี่ยวกับความเสียหายของข้อมูลแบบเงียบฉันตัดสินใจลองใช้ ZFS ด้วย Nexenta Community edition

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

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


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

คุณจัดเก็บหยดขนาดใหญ่เช่น PDF และ gif ในฐานข้อมูลของคุณหรือไม่ ไม่ใช่วิธีที่ดีที่สุดในการจัดเก็บเราใช้ลิงค์ไฟล์ภายในฐานข้อมูลซึ่งทำให้ db มีขนาดเล็กและเราให้ filesystem (xfs) ดูแลไฟล์ ง่ายและรวดเร็วในการสำรองและคืนค่า
นักเลง Unix

คำตอบ:


10

แน่นอนว่า ZFS นั้นมีเสถียรภาพมากพอที่จะทำสิ่งนี้ได้มีฐานการผลิตที่มีความน่าเชื่อถือสูงและมีขนาดใหญ่มากซึ่งมีพื้นฐานมาจาก ZFS และ Nexenta

ที่กล่าวว่ามักจะมีการสำรองข้อมูลบนดิสก์ในสถานที่เช่นที่คุณแนะนำและถอดดิสก์หรือเทปสำรองตามที่ออกนอกสถานที่ทุกวันเพื่อป้องกันไฟ / แผ่นดินไหว / คธูลู ฯลฯ

ดังนั้นคำตอบของฉันคือใช่มันใช้ได้ แต่ฉันจะเลือกทั้งสองอย่างถ้าทำได้


2
+1 สำหรับการป้องกัน cthulhu
Unix Janitor

2
+1 ธูฮูแม่เหล็กกรรม!
Janne Pikkarainen

10

(สมมติว่าคุณหมายถึงการใช้ dedupe ภายใน ZFS กับซอฟต์แวร์สำรองข้อมูลของคุณ)

ฉันจะไม่แนะนำให้ใช้การทำข้อมูลซ้ำซ้อนดั้งเดิมของ ZFS สำหรับระบบสำรองข้อมูลของคุณเว้นแต่คุณจะออกแบบระบบจัดเก็บข้อมูลของคุณโดยเฉพาะ

การใช้ dedupe ใน ZFS นั้นมีความหนาแน่นของแรมมาก เนื่องจากการขจัดข้อมูลซ้ำซ้อนเกิดขึ้นแบบเรียลไทม์เมื่อข้อมูลถูกสตรีม / เขียนไปยังพูลหน่วยเก็บข้อมูลจึงมีตารางเก็บรักษาไว้ในหน่วยความจำที่คอยติดตามบล็อกข้อมูล นี่คือตารางดีดีที หากเซิร์ฟเวอร์จัดเก็บข้อมูล ZFS ของคุณมี RAM ไม่เพียงพอที่จะรองรับตารางนี้ประสิทธิภาพจะลดลงอย่างมาก Nexenta จะเตือนคุณเมื่อตารางโตขึ้นเกินเกณฑ์ที่กำหนด แต่แล้วมันก็สายเกินไป สิ่งนี้สามารถเพิ่มได้โดยการใช้อุปกรณ์ L2ARC (อ่านแคช) แต่ผู้ใช้งานในช่วงแรก ๆ ของ ZFS ตกหลุมพรางนี้

ดู:

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

ZFS - ผลกระทบของความล้มเหลวของอุปกรณ์แคช L2ARC (Nexenta)

เมื่อฉันบอกว่าความต้องการ RAM สูงสำหรับการใช้งาน dedupe ฉันจะประมาณความต้องการ RAM และ L2ARC สำหรับชุดข้อมูลที่คุณอธิบายที่ 64GB + RAM และ 200GB + L2ARC นั่นไม่ใช่การลงทุนเล็กน้อย การเก็บไฟล์ระบบ Windows และเอกสารภาพจำนวนมากที่จะไม่อ่านซ้ำจะช่วยเติม DDT นั้นอย่างรวดเร็ว ผลตอบแทนอาจไม่คุ้มค่ากับงานวิศวกรรมที่ต้องดำเนินการล่วงหน้า

แนวคิดที่ดีกว่าคือใช้การบีบอัดบน zpool ซึ่งอาจใช้ประโยชน์จากความสามารถของ gzip สำหรับประเภทข้อมูลที่บีบอัดได้มากขึ้น การทำซ้ำจะไม่คุ้มค่าเนื่องจากมีการเข้าชมเมื่อคุณต้องการลบข้อมูลที่ซ้ำซ้อน (จำเป็นต้องอ้างอิง DDT)

นอกจากนี้คุณจะนำเสนอที่เก็บข้อมูลไปยังซอฟต์แวร์สำรองข้อมูลของคุณอย่างไร คุณจะใช้ชุดซอฟต์แวร์สำรองข้อมูลใด ในสภาพแวดล้อมของ Windows ฉันนำเสนอ ZFS เป็นที่เก็บข้อมูลของบล็อกไปที่ Backup Exec ผ่าน iSCSI ฉันไม่เคยพบฟีเจอร์ ZFS CIFS ที่แข็งแกร่งเพียงพอและต้องการข้อดีของอุปกรณ์ที่จัดรูปแบบตามธรรมชาติ

นอกจากนี้ยังเป็นแหล่งข้อมูล ZFS ที่ยอดเยี่ยมสำหรับแนวคิดการออกแบบ สิ่งที่เกี่ยวกับ ZFS ที่ไม่มีใครบอกคุณ


2
ฉันเป็นหนึ่งในคนที่ได้รับความน่าดึงดูดใจจากการขจัดข้อมูลซ้ำซ้อนของ ZFS ทุกอย่างทำงานได้ดีในสภาพแวดล้อมการทดสอบของเรา เราเปิดใช้งานในการผลิต ทุกอย่างราบรื่นและดีขึ้นโดยมีอัตราการลดความซ้ำซ้อนมากกว่า 2 เท่า สวย. เราเริ่มย้ายผู้ใช้ไปยังระบบใหม่ ไม่มีปัญหาจนกระทั่งวันหนึ่งเราย้ายผู้ใช้และประสิทธิภาพของไฟล์เซิร์ฟเวอร์ไปแล้ว ทันใดนั้นเครื่องก็คุกเข่า ความผิดพลาดและการรีบูตครั้งต่อไปใช้เวลานานกว่า 90 นาทีก่อนที่เครื่องจะกลับมาทำงานอีกครั้งเนื่องจากประมวลผลตารางการลบข้อมูล น่ากลัว เรากำจัดการหักเงิน ฉันแนะนำให้อยู่ห่างจากมัน
jlp

0

อีกทางเลือกหนึ่งคือ OpenIndiana ซึ่งดีเหมือนกันและได้รับการอัพเดทบ่อยครั้งขึ้น

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

เราเรียกใช้การตั้งค่าเช่นนี้ที่ฉันทำงาน:

  • เซิร์ฟเวอร์จัดเก็บข้อมูลหลักของ OpenIndiana [ main ] ที่มีดิสก์ 2TB หกตัวในพูล RaidZ1 ของคู่มิเรอร์สามชุด สิ่งนี้ในขณะที่ตัดเข้าไปในพื้นที่เก็บข้อมูลที่มีอยู่ของคุณทำให้เป็นที่เก็บข้อมูลที่รวดเร็วและทวีคูณซ้ำซ้อน
  • เซิร์ฟเวอร์จัดเก็บข้อมูลสำรอง [ สำรองข้อมูล ] ยังเรียกใช้ OpenIndiana ด้วยการกำหนดค่าดิสก์ที่คล้ายกันซึ่งทำหน้าที่เป็นอุปกรณ์สำรองข้อมูลเพียงอย่างเดียว
  • mainมีสคริปต์ที่ทำงานจากงาน cron ที่สแนปชอต / tank / [dataset] เป็นประจำตลอดทั้งวัน
  • ทุกเย็นงาน cron อื่นทำงานที่ผลักดันภาพรวมของวันผ่านเครือข่ายเพื่อการสำรองข้อมูล เมื่อทำการซิงค์ครั้งแรกของสแนปชอตทั้งหมดของคุณเสร็จสิ้น (เป็นขั้นตอนเพียงครั้งเดียว) ธรรมชาติของสแน็ปช็อตที่เพิ่มขึ้นหมายความว่าการเปลี่ยนแปลงจะถูกผลักไปยังอุปกรณ์สำรองข้อมูลของคุณอย่างรวดเร็ว

ฉันมีบทสรุปอย่างรวดเร็วเกี่ยวกับวิธีการส่ง / รับ ZFS ที่นี่: http://kyrill-poole.co.uk/blog/tech/zfs-send-and-receive/


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