ระบบไฟล์ที่กระจายตามพื้นที่ซึ่งมีที่ตั้งที่ต้องการ

ฉันกำลังสร้างแอปพลิเคชั่นที่ต้องการแจกจ่ายไฟล์เซิร์ฟเวอร์มาตรฐานในบางไซต์ผ่าน WAN โดยทั่วไปแต่ละไซต์ต้องเขียนไฟล์จำนวนมากที่มีขนาดแตกต่างกัน (บางช่วงอยู่ในช่วง 100s MB แต่มีขนาดเล็กที่สุด) และแอปพลิเคชันจะถูกเขียนเช่นการชนกันจะไม่เกิดปัญหา ฉันต้องการตั้งค่าระบบที่ตรงกับคุณสมบัติดังต่อไปนี้:

1. แต่ละไซต์สามารถจัดเก็บไฟล์ใน "namespace" ที่ใช้ร่วมกัน นั่นคือไฟล์ทั้งหมดจะปรากฏในระบบไฟล์เดียวกัน
2. แต่ละไซต์จะไม่ส่งข้อมูลผ่าน WAN เว้นแต่จำเป็น นั่นคือจะมีที่เก็บข้อมูลภายในแต่ละด้านของ WAN ที่จะ "ผสาน" เข้ากับระบบไฟล์โลจิคัลเดียวกัน
3. Linux & ฟรี ($$$) เป็นเครื่องหมายบวก

โดยพื้นฐานแล้วสิ่งที่ต้องการแบ่งปัน NFS กลางจะเป็นไปตามข้อกำหนดส่วนใหญ่อย่างไรก็ตามจะไม่อนุญาตให้ข้อมูลที่เขียนเป็นภาษาท้องถิ่นอยู่ภายในเครื่อง ข้อมูลทั้งหมดจากด้านข้างระยะไกลของ WAN จะถูกคัดลอกภายในเครื่องตลอดเวลา

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

บางคำตอบสำหรับคำถามที่ถามด้านล่าง:

• เซิร์ฟเวอร์โหนด: 2 หรือ 3 เพื่อเริ่ม แต่ละเซิร์ฟเวอร์จะมีการเชื่อมต่ออ่าน / เขียนไคลเอ็นต์พร้อมกันหลายสิบเครื่อง
• WAN Topology เต็มตาข่ายและเชื่อถือได้ (บริษัท ขนาดใหญ่ค่าใช้จ่ายไม่ จำกัด เหมือนเทปสีแดง)
• ความล้มเหลวของลูกค้า: จริง ๆ แล้วฉันไม่ได้คิดถึงการมีลูกค้าล้มเหลว (ส่วนใหญ่เป็นเพราะการสมัครปัจจุบันของเราไม่ได้ทำที่เว็บไซต์เดียว) ฉันคิดว่าคำตอบที่เข้าใจได้ก็คือเซิร์ฟเวอร์ในไซต์กระจายทางภูมิศาสตร์แต่ละแห่งนั้นคาดว่าจะเป็นจุดเดียวของความล้มเหลวสำหรับลูกค้าที่พวกเขากำลังให้บริการ แม้ว่าถ้าคุณกำลังคิดเกี่ยวกับบางสิ่งบางอย่างที่นี่ฉันคิดว่ามันค่อนข้างจะมีประโยชน์ต่อการอภิปราย
• Roll-my-own: ฉันคิดเกี่ยวกับ rsync / unison แต่ฉันต้องการตรรกะที่ค่อนข้างแฟนซีเพื่อให้ส่วน "ไดนามิก" ของงานนี้ราบรื่น คือไฟล์ดูเหมือนจะอยู่ในเครื่อง แต่จะถูกดึงตามความต้องการเท่านั้น
• MS-DFS: มันดูเหมือนจะเป็นสิ่งที่ฉันควรพิจารณา ปัญหาหลักของฉันอาจไม่แน่ใจเกี่ยวกับการกำหนดค่าเซิร์ฟเวอร์ / ความน่าเชื่อถือ / ประสิทธิภาพการทำงานของเซิร์ฟเวอร์ NFS บน Windows เนื่องจากไคลเอ็นต์จำนวนมากที่เชื่อมต่อเป็นไคลเอนต์ NFS

ความอัปยศเกี่ยวกับข้อกำหนดของ Linux นี่คือสิ่งที่ Windows DFS ทำ ตั้งแต่ปี 2003 R2 มันทำในระดับบล็อกเช่นกัน

บางคำถาม:

• คุณคิดว่ามี "เซิร์ฟเวอร์" กี่โหนดที่มีส่วนร่วมในสิ่งนี้?

• โทโพโลยีการเชื่อมต่อ WAN คืออะไร - ฮับและพูด, เต็มตาข่าย? มันเชื่อถือได้แค่ไหน?

• คุณคาดหวังว่าลูกค้าจะล้มเหลวไปยังเซิร์ฟเวอร์ที่ไม่ใช่ในพื้นที่ทางภูมิศาสตร์ในกรณีที่เซิร์ฟเวอร์ภายในล้มเหลวหรือไม่?

Windows DFS-R เป็นสิ่งที่คุณต้องการอย่างแน่นอนแม้ว่าจะมีค่าลิขสิทธิ์ที่สูง

คุณบอกว่าการชนไม่ใช่ปัญหาและคุณไม่จำเป็นต้องมีตัวจัดการล็อคแบบกระจายดังนั้นคุณสามารถทำได้ด้วยเครื่องมือ userland เช่น rsync หรือUnisonและเพียงแค่ส่งออกคลังข้อมูลที่เป็นผลลัพธ์ด้วย NFS ไปยังไคลเอนต์ในพื้นที่ มันน่าเกลียดและคุณจะต้องจัดการกับการเคาะระบบบางอย่างเพื่อจัดการกับการสร้างโทโพโลยีการจำลองแบบและใช้งานเครื่องมือผู้ใช้จริง ๆ แต่จริงๆแล้วมันจะมีราคาถูกตามต้นทุนการออกใบอนุญาต

คุณคิดว่าAFSไหม?

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

ตามที่ฉันเข้าใจแล้วการพัฒนาล่าสุดส่วนใหญ่อยู่เบื้องหลังโครงการOpenAFS

ฉันไม่สามารถเสแสร้งทำความคุ้นเคยกับโครงการเพื่อทราบว่ามีคุณสมบัติ "ท้องที่ที่ต้องการ" หรือไม่ แต่อย่างอื่นมันฟังดูเหมาะสม

คุณเคยดูOST พูลใน Luster ไหม?

มันจะไม่เป็นแบบอัตโนมัติ แต่ด้วย OST พูลคุณสามารถกำหนดไดเรกทอรี / ไฟล์ให้กับ OST / OSSes เฉพาะ - โดยทั่วไปแล้วการจัดสรรพื้นที่เก็บข้อมูลตามนโยบายไม่ใช่การปัดเศษรอบ / การสไทรพ์เริ่มต้นข้าม OST

ดังนั้นคุณสามารถตั้งค่าไดเรกทอรีต่อไซต์และกำหนดไดเรกทอรีนั้นไปยัง OST ท้องถิ่นสำหรับเว็บไซต์นั้นซึ่งจะนำ I / O ทั้งหมดไปยัง OST ท้องถิ่น มันจะยังคงเป็น namespace ทั่วโลก

มีงานมากมายที่จะพัฒนาความเป็นเงาผ่านการเชื่อมต่อ WAN (แคชเซิร์ฟเวอร์ในพื้นที่และสิ่งอื่น ๆ ) แต่ทั้งหมดนี้ยังอยู่ภายใต้การพัฒนาอย่างหนัก AFAIK

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

นอกจากนี้ mabye UnionFS ก็คุ้มค่าที่จะพิจารณา ด้วยวิธีนี้ฉันคิดว่าสถานที่แต่ละแห่งจะเป็นการส่งออก NFS และจากนั้นคุณสามารถใช้ UnionFS ในแต่ละสถานที่เพื่อให้ได้และ NFS อื่น ๆ ทั้งหมดที่เมาท์จากตำแหน่งที่ตั้งจะปรากฏเป็นระบบไฟล์เดียว ฉันไม่เคยมีประสบการณ์กับสิ่งนี้

คุณสามารถดูใน DRBD เพื่อทำซ้ำดิสก์ http://www.drbd.org/ นี่เป็นโซลูชั่น Linux High Availability ซึ่งเพิ่งจะนำไปทำเป็นเคอร์เนล

อย่างไรก็ตามนี่มีข้อ จำกัด บางประการ:

1. สามารถตั้งค่าได้สองโหนดเท่านั้น
2. WAN อาจไม่น่าเชื่อถือเกินไปที่จะทำให้ DRBD แข็งแกร่ง

หากคุณต้องการทำให้มันเรียบง่ายแล้วดู rsync แก้ปัญหามากมายและสามารถเขียนสคริปต์

ตรวจสอบchironfs

บางทีมันสามารถทำสิ่งที่คุณต้องการบนพื้นฐานของระบบไฟล์

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

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

Yout btsync clients สามารถแชร์โฟลเดอร์บนเครือข่ายท้องถิ่นได้

ข้อเสียเดียวที่ฉันพบ (เทียบกับ MS DFS) คือมันจะไม่ตรวจพบการคัดลอกไฟล์ในเครื่อง แต่จะตีความว่าเป็นไฟล์ใหม่ที่อัปโหลดไปยังเพื่อนทั้งหมด

จนถึงตอนนี้ดูเหมือนว่า btsync จะเป็นโซลูชันการซิงโครไนซ์ที่ดีที่สุดและสามารถติดตั้งบนอุปกรณ์ Windows, Linux, Android และ ARM (เช่น NAS)