การซิงค์แบบเรียลไทม์แบบสองทิศทางของทรีไฟล์ขนาดใหญ่ระหว่างเซิร์ฟเวอร์ linux สองตัวที่อยู่ห่างไกล


21

ต้นไม้ไฟล์ขนาดใหญ่ฉันหมายถึงไฟล์ประมาณ 200k และเพิ่มขึ้นตลอดเวลา แม้ว่าจะมีการเปลี่ยนแปลงจำนวนไฟล์ค่อนข้างน้อยในเวลาใดก็ตาม

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

โดยไกลฉันหมายความว่าเซิร์ฟเวอร์ทั้งคู่อยู่ในศูนย์ข้อมูล แต่อยู่ห่างจากกันทางภูมิศาสตร์ ขณะนี้มีเซิร์ฟเวอร์เพียง 2 เครื่องเท่านั้น แต่อาจขยายได้ตามเวลา

ตามเวลาจริงมันก็โอเคที่จะมีเวลาแฝงเล็กน้อยระหว่างการซิงค์ แต่การเรียกใช้ cron ทุก 1-2 นาทีดูเหมือนจะไม่ถูกต้องเนื่องจากไฟล์ขนาดเล็กมากอาจมีการเปลี่ยนแปลงในชั่วโมงใดก็ตาม

แก้ไข : นี่ทำงานบน VPS ดังนั้นฉันอาจถูก จำกัด ประเภทของระดับเคอร์เนลที่ฉันสามารถทำได้ ยิ่งไปกว่านั้น VPS นั้นไม่ได้อุดมไปด้วยทรัพยากรดังนั้นฉันจึงอายที่จะแก้ปัญหาที่ต้องใช้ RAM จำนวนมาก (เช่น Gluster?)

อะไรคือวิธีที่ "ยอมรับ" ที่ดีที่สุดในการทำสิ่งนี้? ดูเหมือนว่ามันจะเป็นความต้องการทั่วไป แต่ฉันยังไม่สามารถหาวิธีการที่ยอมรับกันโดยทั่วไปได้ซึ่งน่าแปลกใจ (ฉันกำลังมองหาความปลอดภัยของฝูง :)

ฉันเจอlsyncdเพื่อเรียกการซิงค์ที่ระดับการเปลี่ยนแปลงของระบบไฟล์ ดูเหมือนจะฉลาด แต่ไม่ใช่เรื่องธรรมดาและฉันก็สับสนเล็กน้อยกับวิธีการต่างๆของ lsyncd มีเพียงการใช้ lsyncd กับ rsync แต่ดูเหมือนว่านี่อาจจะเปราะบางสำหรับ bidirectionality เนื่องจาก rsync ไม่มีแนวคิดเกี่ยวกับหน่วยความจำ (เช่น - เพื่อทราบว่าไฟล์ที่ถูกลบใน A ควรลบใน B หรือไม่ว่าเป็นไฟล์ใหม่ใน B ที่ควรคัดลอกไปยัง A) lipsyncดูเหมือนจะเป็นเพียงการใช้ lsyncd + rsync ใช่มั้ย

จากนั้นมีการใช้ lsyncd กับcsync2เช่นนี้: https://icicimov.github.io/blog/devops/File-system-sync-with-Csync2-and-Lsyncd/ฉันกำลังเข้าใกล้แนวทางนี้ แต่ csync2 ค่อนข้างแปลก แต่ฉันก็ทำการทดสอบได้สำเร็จ ฉันกังวลเป็นส่วนใหญ่ว่าฉันไม่สามารถหาคำยืนยันจากชุมชนจำนวนมากเกี่ยวกับวิธีนี้

ผู้คนที่นี่ดูเหมือนจะพร้อมเพรียงกันมาก แต่ดูเหมือนว่ามันจะไม่ได้อยู่ภายใต้การพัฒนาที่ใช้งานได้อีกต่อไปและไม่ชัดเจนว่ามันมีทริกเกอร์อัตโนมัติเช่น lsyncd

ฉันเคยเห็นกลอสเตอร์กล่าวถึง แต่อาจเกินความจำเป็นสำหรับสิ่งที่ฉันต้องการ

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


คุณต้องการการเปลี่ยนแปลงแบบใด การสร้าง EG, การลบ, การดัดแปลง
sciurus

นอกจากนี้คุณคาดหวังความขัดแย้งไหม? สามารถแก้ไขไฟล์เดียวกันบนเซิร์ฟเวอร์ทั้งสองได้หรือไม่
sciurus

การเปลี่ยนแปลงทั้งหมด: การสร้างการลบการดัดแปลง มีความเป็นไปได้ที่อาจเกิดความขัดแย้ง ฉันจะไม่รังเกียจถ้าฉันเพิ่งได้รับการแจ้งเตือนเกี่ยวกับความขัดแย้งที่ฉันต้องแก้ไขด้วยตนเอง
dlo

คำตอบ:


5

DRBDในโหมดDual-primaryพร้อมพร็อกซีเป็นตัวเลือก


ดูเหมือนว่าพร็อกซีไม่ใช่โอเพนซอร์สหรือฟรีใช่ไหม ฉันไม่แน่ใจว่าฉันเข้าใจผลของการไม่มีพร็อกซีในโหมดอะซิงก์: ในช่วงเวลาหยุดทำงานนานหากไม่มีพร็อกซีบัฟเฟอร์ขนาดเล็กเอาท์พุท [เล็ก?] อาจเติมเต็มและเราจะสูญเสียการซิงค์หรือไม่ เป็นการยากที่จะกู้คืนจากสิ่งนั้น
dlo

ดูคำตอบของฉันด้านบน ฉันไม่คิดว่าพรอกซีเป็นสิ่งที่คุณต้องการ แม้ในช่วงเวลาหยุดทำงานเล็ก ๆ drbd-meta-device จะทำเครื่องหมายบล็อก "สกปรก" และจะถ่ายโอนได้หลังจากการเชื่อมต่ออีกครั้ง ฉันคิดว่าความแตกต่างที่สำคัญระหว่างพร็อกซีและโหมด async คือโหมด async ใช้บัฟเฟอร์สูงสุดของบาง MB หลังจากนั้นจะซิงค์ก่อนที่จะเติมบัฟเฟอร์อีกครั้ง พร็อกซีช่วยให้สามารถบัฟเฟอร์ที่ใหญ่กว่า (จำเป็นถ้าคุณมีเวลาแฝงที่ยิ่งใหญ่หรือสามารถเขียนได้เร็วกว่าในพื้นที่ห่างไกล)
นิลส์

2

แทนที่จะซิงค์ทำไมไม่แชร์ระบบไฟล์เดียวกันกับ NFS


2
NFS แย่มากเพียงอันยิ่งใหญ่ สิ่งใดจะดีกว่า NFS
AliGibbs

2
หนึ่งในประเด็นหลักของการตั้งค่าหลายเซิร์ฟเวอร์คือ failover / redundancy ดังนั้นเซิร์ฟเวอร์หนึ่งจะต้องสามารถดำเนินการต่อได้หากไม่มีเซิร์ฟเวอร์อื่น
dlo

คุณควรพูดถึงเรื่องนี้ในคำถามของคุณแล้ว - ไม่จำเป็นต้องโหวตคำตอบที่สมเหตุสมผลอย่างสมบูรณ์แบบ!
บาร์ต B

fyi ฉันไม่ได้ลงคะแนน - คนอื่นทำ แต่ใช่ฉันควรจะเริ่มต้นด้วย
สำนักกฎหมายธรรมนิติ

@Bart: อืม - เขาพูดถึงว่ามีการเข้าถึงพร้อมกันในสองเว็บไซต์ที่อยู่ห่างไกล ดังนั้นแม้ว่าคุณจะวาง HA-NFS ซึ่งจะเป็นทางออกที่ไม่ดีเนื่องจากด้านหนึ่งจะได้รับความล่าช้าในระหว่างการเข้าถึง NFS และฉันไม่ได้ลงคะแนนอย่างใดอย่างหนึ่ง แต่ฉันเคยเป็นผู้ดูแลระบบ NFS มานานพอที่จะรองรับ AliGibbs : - /
นิลส์

2

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

ฉันไม่คิดว่า Gluster (หรือ AFS) เกินความเป็นจริง


Gluster ต้องการ RAM 1GB หรือไม่ gluster.com/community/documentation/index.php/ ...... ฉันยังเป็น VPS ด้วยดังนั้นฉันไม่แน่ใจเกี่ยวกับการเปลี่ยนแปลงระดับเคอร์เนลที่ AFS อาจต้องการ แต่ฉันเริ่มเห็นว่า fs กระจายที่เหมาะสมเป็นเส้นทางที่ดีกว่า
dlo

ใช่ขอโทษฉันไม่ได้รู้มาก่อนหน้านี้ว่าคุณกำลังใช้โฮสต์ VPS รอยเท้าหน่วยความจำ Gluster ทั้งเซิร์ฟเวอร์และไคลเอนต์ไม่เล็กและสามารถเติบโตได้อย่างมาก DRBD ฟังดูเหมาะสมกว่า

AFS เป็นวิธีที่จะไป
Anthony Giorgio

2

ในกรณีของคุณฉันแนะนำให้ใช้ DRBD ในโหมด dual-primary-mode และ gfs หรือ ocfs

ข้อเสียของ DRBD ในสองหลักคือมันจะทำงานในโหมดซิงโครนัส แต่ความเร็วในการเขียนดูเหมือนจะไม่สำคัญใช่ไหม

อีกทางเลือกหนึ่งสำหรับ DRBD อาจเป็น Soft-Raid1 ที่ใช้ iSCSI- เป้าหมายจำนวนมาก (2+) - แต่ฉันต้องการ DRBD ที่มีสองโหนด


1
โหมดซิงโครนัสจะไม่ดี - ฉันไม่ต้องการและฉันไม่ต้องการบ่อนทำลายประสิทธิภาพเนื่องจากเซิร์ฟเวอร์เชื่อมต่อผ่าน WAN ข้ามทวีป แต่คุณไม่สามารถมีสองหลักในโหมด async ได้หรือไม่?
dlo

ฉันกำลังใช้ DRBD 8.3.5 - คุณต้องอยู่ในโหมดซิงค์ ("C") เพื่อเข้าสู่โหมดหลักคู่ ฉันไม่มีประสบการณ์ส่วนตัวกับ DRBD proxy แต่ดูเหมือนว่าจะคล้ายกับ Veritas Volume Replicator - แต่มันไม่เหมาะอย่างยิ่งเนื่องจากคุณต้องการเข้าถึงการเขียนทั้งสองด้าน โหมดซิงค์ในระดับบล็อกอาจไม่เลวร้ายอย่างที่คิด - บางที gfs และ / หรือ ocfs สามารถบัฟเฟอร์การเขียน
นิลส์

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

0

ดังที่แสดงไว้ด้านบนมีวิธีแก้ปัญหามากมายซึ่งแต่ละแบบมีข้อดีและข้อเสีย

ฉันคิดว่าฉันจะพิจารณาวางแผนผังทั้งหมดภายใต้การควบคุมเวอร์ชัน ( ตัวอย่างเช่นการโค่นล้ม ) และการตรวจสอบ / อัปเดตเป็นระยะจากเซิร์ฟเวอร์ทั้งสองในงาน cron


0

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

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