डिस्ट्रीब्यूटेड फ़ाइल स्टोरेज समझाया: यह कैसे काम करता है
IPFS और Ceph जैसे डिस्ट्रीब्यूटेड फ़ाइल स्टोरेज सिस्टम को समझें। आधुनिक स्टोरेज में रेप्लिकेशन, संगति और फ़ॉल्ट टॉलरेंस।
Distributed file storage data को कई nodes पर फैलाता है ताकि कोई एक machine bottleneck या single point of failure न हो। Design choices — data कहाँ रखें, कैसे replicate करें, node failures कैसे handle करें, consistency कैसे बनाए रखें — Ceph (object/block/file), GlusterFS (POSIX), HDFS (big-data batch), MinIO (S3-compatible), और content-addressed systems जैसे IPFS और Filecoin को अलग करते हैं। हर system अलग workloads target करता है, और tradeoffs वास्तविक हैं। यहाँ concrete walkthrough है कि ये systems वास्तव में कैसे काम करते हैं।
Replication बनाम Erasure Coding
दो strategies node failure से बचाती हैं। Replication multiple full copies store करता है: Ceph का default 3x replication है, मतलब 1 GB object 3 GB raw storage उपयोग करता है। Simple, fast reads, storage पर expensive। Erasure coding data को k data chunks plus m parity chunks में Reed-Solomon codes से split करता है, इसलिए (10,4) scheme 14 chunks store करता है और 4 failures tolerate करता है — 200 percent के बजाय केवल 40 percent overhead के साथ। MinIO erasure coding default करता है; Backblaze Vaults 17+3 Reed-Solomon उपयोग करता है। Erasure coding reads slower हैं क्योंकि reconstruction multiple chunks चाहता है, इसलिए hot data अक्सर replication और cold data erasure coding उपयोग करता है।
Consistent Hashing और Data Placement
System decide कैसे करता है कि कौन सा node कौन सा object store करे? Consistent hashing — Karger et al. (1997) के academic work में introduced, DynamoDB और Cassandra से popularized — keys को ring पर hash करता है और हर range को node पर map करता है। Node add या remove करने पर केवल keys का fraction shuffle होता है, पूरा dataset नहीं। Ceph CRUSH (Controlled Replication Under Scalable Hashing) उपयोग करता है, एक deterministic algorithm जो topology map (rack, row, datacenter) के आधार पर objects place करता है ताकि replicas diverse failure domains पर end up हों। Physical node प्रति Virtual nodes (vnodes) load imbalance smooth करते हैं।
Consistency Models: Strong, Eventual, और Causal
CAP theorem कहता है consistency, availability, और partition tolerance एक साथ नहीं हो सकते, दो choose करने हैं। Strong consistency (linearizability) का मतलब reads latest write देखते हैं; Spanner और etcd जैसे systems यह Paxos या Raft जैसे consensus protocols के माध्यम से provide करते हैं। Eventual consistency (DynamoDB, Cassandra, ऐतिहासिक रूप से कुछ operations के लिए S3) का मतलब replicas समय के साथ converge होते हैं, propagation के दौरान stale reads संभव। Causal consistency full linearizability के बिना cause-effect order preserve करता है। File storage अक्सर metadata (listing, size) के लिए eventual consistency accept करता है, same object के reads-after-writes के लिए strong consistency के साथ।
Ceph Architecture: OSDs, Monitors, Managers, और MDSes
Ceph चार daemon types run करता है। OSDs (Object Storage Daemons) objects store करते हैं और replicate करते हैं; cluster में आमतौर पर spinning या NVMe disks पर 10 से 1,000 OSDs होते हैं। Monitors (MONs) Paxos के माध्यम से cluster state maintain करते हैं; 3 या 5 MONs quorum provide करते हैं। Managers (MGRs) metrics expose करते हैं और dashboards host करते हैं। MDSes (Metadata Servers) CephFS POSIX filesystem layer serve करते हैं। RADOS Gateway (RGW) के माध्यम से Object storage S3 और Swift APIs present करता है। RBD के माध्यम से Block storage OpenStack volumes और VM disks back करता है। एक codebase, तीन personalities, /etc/ceph/ceph.conf और CRUSH map edits से tuned।
HDFS और Hadoop Legacy
HDFS (Hadoop Distributed File System) MapReduce और Spark jobs के लिए large sequential reads target करता है। Files 128 MB या 256 MB blocks में split होती हैं; हर block default पर DataNodes पर 3x replicate होता है। NameNode सभी metadata memory में hold करता है, scale को लगभग 500 million files per NameNode तक limit करता है। HDFS Federation और HDFS Router multi-namespace support add करते हैं। HDFS छोटी files (metadata dominate करता है) या POSIX compatibility के लिए अच्छा नहीं है, लेकिन TB-scale datasets पर analytics के लिए excellent है। Cloud era में compute storage से अलग होने के साथ object storage (S3, GCS) इसे displace कर रहा है।
Content-Addressed Storage: IPFS और Filecoin
IPFS (InterPlanetary File System) content को location के बजाय उसके hash (CID, Content IDentifier) से identify करता है। Same content वाली file store करने वाला कोई भी same CID produce करता है। Retrieval DHT (Distributed Hash Table, Kademlia-based) का उपयोग करके content hold करने वाले nodes find करता है। Filecoin economic incentives add करता है, miners PoRep (Proof-of-Replication) और PoSt (Proof-of-Spacetime) के माध्यम से prove करते हैं कि वे content store कर रहे हैं और FIL tokens earn करते हैं। IPFS archival और decentralized publishing (NFT metadata, web3 sites) के लिए fit है; DHT lookup latency (hundreds of milliseconds से seconds) के कारण interactive workloads के लिए slow है।
Object Storage: S3, R2, B2, और MinIO
Object storage एक flat key-value API present करता है: key के साथ object PUT करें, वापस GET करें। कोई directories नहीं, कोई POSIX semantics नहीं। यह simplicity massive scale enable करती है — AWS S3 11 nines durability के साथ trillions of objects store करता है। Cloudflare R2, Backblaze B2, Wasabi, और DigitalOcean Spaces जैसे clones different backends पर S3 API implement करते हैं। MinIO open source AGPL v3 के रूप में on-premises चलता है, अक्सर Kubernetes में StatefulSet के रूप में, commodity hardware पर S3-compatible storage provide करता है। Object storage cloud storage market जीत चुका है क्योंकि API simple है, pricing clear है, और durability trustworthy है।
Erasure Coding Practice में: Reconstruction कैसे काम करता है
Erasure-coded system में node die होने पर, remaining nodes lost chunks reconstruct करते हैं। (10,4) Reed-Solomon code के लिए, कोई भी 10 of 14 chunks finite field पर matrix algebra के माध्यम से original 10 data chunks reconstruct करते हैं। Reconstruction load surviving nodes पर पड़ती है, इसलिए 100 nodes के cluster में 1 node खोने पर lost chunk प्रति 10 अन्य nodes से reads trigger होते हैं। Rebuild के दौरान bandwidth एक major operational concern है। Ceph जैसे systems production I/O को impact करने से बचने के लिए rebuilds rate-limit करते हैं। Azure द्वारा उपयोग किए गए Local Reconstruction Codes (LRC) और Hitchhiker codes जैसे newer codes partial reads allow करके reconstruction bandwidth कम करते हैं।
Tail Latency और Hedged Requests
Distributed systems में long tails होती हैं। Slow disk या congested network hit करने वाला request median से 10x समय ले सकता है। Google के paper "The Tail at Scale" (Dean & Barroso, 2013) ने techniques formalize किए: hedged requests दो nodes को duplicate reads भेजते हैं, जो हारे उसे cancel करते हैं; tied requests coordinate करते हैं ताकि केवल एक actually execute हो। Ceph, DynamoDB, और Spanner सभी variations उपयोग करते हैं। File transfer systems के लिए, multiple replicas से parallel में object read करना और first response लेना — थोड़ी अधिक bandwidth की कीमत पर — p99 latency dramatically cut करता है।
Failure Domains और Data Diversity
तीन replicas place करना help नहीं करता यदि तीनों same rack में हों और rack का top-of-rack switch fail हो। Failure domain awareness का मतलब replicas different racks, rows, या datacenters में land होते हैं। Ceph के CRUSH rules encode करते हैं "कम से कम 2 copies different racks में, 1 copy different datacenter में।" Cloud object storage यह transparently handle करता है — S3 Standard 3+ Availability Zones पर store करता है। Cross-region replication के लिए, S3 Cross-Region Replication (CRR) asynchronously objects को दूसरे region में mirror करता है, disaster recovery और regional data residency के लिए useful। DPDP Act 2023 के तहत भारतीय data के लिए, AWS ap-south-1 (Mumbai) और ap-south-2 (Hyderabad) residency requirements पूरी करते हैं।
File Transfer Services के लिए Practical Implications
File transfer service आमतौर पर POSIX file system के बजाय object storage पर build होती है। S3-compatible backends (AWS S3, Cloudflare R2, MinIO) बिना team को Ceph या GlusterFS run किए durability और scale handle करते हैं। Service auth, presigned URLs, metadata, और user-facing features add करती है। HexaTransfer client-side AES-256-GCM encryption के साथ S3-compatible backend उपयोग करता है, इसलिए distributed storage layer durability handle करता है जबकि app layer file contents को हर tier से private रखता है।
hexatransfer.com पर आज़माएं — मुफ़्त, कोई अकाउंट नहीं, अधिकतम 10 GB।
एंड-टू-एंड एन्क्रिप्शन के साथ बड़ी फ़ाइलें सुरक्षित रूप से भेजें
एंड-टू-एंड एन्क्रिप्शन के साथ 10 GB तक की फ़ाइलें मुफ़्त में ट्रांसफ़र करें। अकाउंट की आवश्यकता नहीं। अपलोड से पहले आपकी फ़ाइलें ब्राउज़र में एन्क्रिप्ट की जाती हैं — कोई और उन्हें पढ़ नहीं सकता।
फ़ाइल भेजें