DYNAMIC ENDPOINT TRANSFER
Destination बदलता है।
File transfer बिल्कुल पहले की तरह चलता है।
Where the system that runs the work keeps changing — GPU servers, Kubernetes workloads, Cloud compute — the file transfer does not have to be set up again every time.
Connect the endpoint your existing infrastructure selected to an INNORIX transfer. The real destination can change and the same transfer logic still delivers the files you need.
DYNAMIC ENDPOINT SELECTION
किसी तय Target के बजाय,
रन टाइम पर चुने गए Endpoint को ट्रांसफर से जोड़ें।
Dynamic Endpoint Transfer सिर्फ़ बहुत सारे सर्वर वाले वातावरण के लिए कोई फ़ीचर नहीं है। असली बात यह है कि किसी ऐसे वातावरण में, जहां किसी फ़ाइल को पहुंचने वाला असली Target रन टाइम पर तय होता है, या लगातार बदलता रहता है। AI Training में इस्तेमाल होने वाला GPU Compute हर रन में अलग हो सकता है, कोई Kubernetes Workload किसी नए Pod या Node पर चल सकता है, Cloud Compute ज़रूरत पड़ने पर बनाया जाता है, और Edge Devices अलग-अलग समय पर जुड़ते हैं।
जहां कोई पारंपरिक ट्रांसफर किसी खास IP या Hostname को अपने Target के तौर पर तय करता है, वहां Dynamic Endpoint Transfer उस भूमिका और शर्त को — "वह GPU Compute जो यह Training चलाएगा", "वह Edge Device जो अभी Ready है" — किसी असली Endpoint से जोड़ता है, जिसकी काम को ज़रूरत होती है। आपका इंफ्रास्ट्रक्चर असली Endpoint तय करता है, और INNORIX उस नतीजे को File Transfer पर लागू करता है, जिससे काम की Transfer Logic को फिर से बनाए बिना ही Endpoint बदल सकता है।
स्थिरनिर्धारित Target
गतिशीलRuntime पर select किया गया
यह कहां use होता है
- AI Training
- Kubernetes
- Cloud Compute
- Edge
ENDPOINT CONDITIONS & GROUPS
किसी Endpoint की भूमिका, शर्तों और Group का इस्तेमाल करें,
ताकि एक बदलते इंफ्रास्ट्रक्चर को तैयार किया जा सके।
किसी ट्रांसफर को किसी एक सर्वर के IP एड्रेस या नाम से बांधने के बजाय, Endpoint को शर्तों के आधार पर नाम दिया जा सकता है: भूमिका, क्षेत्र, Workload और स्थिति।
आपका इंफ्रास्ट्रक्चर मैच करने वाले Endpoint को चुनता है, और INNORIX डेटा उस तक पहुंचाता है। मशीन हर रन में अलग हो सकती है; ट्रांसफर सेटअप नहीं बदलता।
Target स्थितिConditions जो target को नाम देती हैं।
- भूमिकाGPU Compute
- RegionSeoul
- WorkloadTraining
- Statusतैयार
उपलब्ध एंडपॉइंटआपके infrastructure द्वारा select किया गया
- GPU-03Seoul | NVIDIA H100उपलब्ध
- GPU-07Seoul | NVIDIA H100चयनित
- GPU-12टोक्यो | NVIDIA A100उपलब्ध
INFRASTRUCTURE INTEGRATION
आपके मौजूदा infrastructure ने Endpoint की state decide करता है,
और INNORIX इस निर्णय को Transfer के रूप में execute करता है।
कोई Kubernetes शेड्यूलर, GPU शेड्यूलर, cloud ऑर्केस्ट्रेटर या edge मैनेजर यह तय करता रहता है कि क्या कहां चलता है। फ़ाइल ट्रांसफर को उसमें कुछ भी बदले बिना उससे जोड़ दिया जाता है।
जैसे ही आपका सिस्टम कोई Pod, GPU सर्वर या edge डिवाइस चुन लेता है, INNORIX फ़ाइलों को दिए गए Endpoint तक ट्रांसफर करता है और अगले चरण के लिए प्रगति व नतीजा लौटाता है।
ट्रांसफर-एकीकरणTransfer आपके system द्वारा चुने गए endpoint पर जाता है।
मौजूदा बुनियादी ढांचा
- Kubernetes SchedulerTarget Pod को select करता है
- GPU SchedulerTarget GPU node को select करता है
- Cloud OrchestratorCompute instance को select करता है
- Edge ManagementTarget edge device को select करता है
चयनित एंडपॉइंट
INNORIX Compute provision नहीं करता है और Workload Placement decide नहीं करता है।
WORKLOAD LIFECYCLE
Workload और Endpoint Lifecycle में,
डेटा जहां आवश्यक है वहां उन बिंदुओं को जोड़ें।
कोई Cloud VM, GPU Compute Node या Kubernetes Pod, काम शुरू होते समय बनाया जाता है और काम खत्म होते ही रिलीज़ कर दिया जाता है। किसी तय सर्वर पर बना ट्रांसफर इसे फ़ॉलो नहीं कर सकता।
Endpoint तैयार होते ही INNORIX Dataset पहुंचाता है, और जॉब पूरा होने पर नतीजे का डेटा आपके बताए गए Storage में इकट्ठा करता है। सर्वर बनाना और रिलीज़ करना आपके अपने इंफ्रास्ट्रक्चर का काम ही रहता है।
एंडपॉइंट-लाइफसाइकिलट्रांसफर, बनने से लेकर रिलीज़ होने तक Endpoint को फ़ॉलो करता है।
- 1. निर्मितEndpoint को create किया जाता है।निर्मित
- 2. तैयारJob के लिए environment ready है।तैयार
- 3. Data Deliveryआवश्यक data deliver किया जाता है।डिलीवर किया गया
- 4. Job रनJob delivered data पर run होता है।समाप्त
- 5. CollectionResult data को वापस collect किया जाता है।संग्रहित
- 6. जारीJob खत्म होने पर endpoint को release किया जाता है।जारी
ORCHESTRATOR & API
अपने मौजूदा Orchestrator और API से
एक Dynamic Transfer को कॉल करें।
जब किसी मौजूदा सिस्टम में — Kubernetes, GPU Scheduler या Cloud Orchestrator — Endpoint तय हो जाता है, तो वह सिस्टम INNORIX की transfer क्षमता को कॉल करता है।
Workflow Logic और Scheduling आपके मौजूदा सिस्टम में ही रहते हैं, और केवल File Transfer को एक स्वतंत्र Data Movement Layer के रूप में जोड़ा जाता है। हर रन में Endpoint अलग होता है, जबकि कॉल और उसके रिज़ल्ट को हैंडल करने का तरीका एक जैसा रहता है — इस तरह आपकी मौजूदा Automation को फिर से परिभाषित किए बिना Transfer Capability को एक Dynamic Infrastructure में जोड़ दिया जाता है।
API Interface
UNIFIED OPERATIONS
Endpoint चाहे जितनी बार बदले,
हर transfer के परिणाम को एक ही platform पर जांचें।
काम करने वाला GPU या Compute हर बार अलग हो सकता है, फिर भी transfer jobs और उनके परिणामों को अलग से मैनेज करने की ज़रूरत नहीं पड़ती।
INNORIX Studio में जुड़ी हुई मशीनों और transfer Flows को मैनेज करें, और Runs में देखें कि वास्तव में कौन-सा Endpoint चुना गया, transfer की progress क्या है और उसका पूर्णता परिणाम क्या रहा।
Training Data DeliveryTarget स्थिति | GPU · Training · तैयार
GET STARTED
ऐसे endpoints से फ़ाइल ट्रांसफर को जोड़ें जो लगातार बदलते रहते हैं।
अपने मौजूदा Kubernetes, GPU शेड्यूलर या cloud ऑर्केस्ट्रेटर द्वारा चुने गए Endpoint को किसी INNORIX फ़ाइल ट्रांसफर जॉब से जोड़ें।
Studio में transfer का परिणाम देखें, और API के ज़रिए अपने मौजूदा workload के साथ इंटीग्रेट करें।
TECHNICAL FAQ
अक्सर पूछे जाने वाले सवाल
Dynamic Endpoint Transfer क्या है?
ऐसे वातावरण में जहां किसी फ़ाइल ट्रांसफर का सोर्स या टार्गेट कोई तय सर्वर नहीं होता, बल्कि एक्ज़िक्यूशन के समय तय होता है, यह असल में चुने गए Endpoint को किसी मौजूदा ट्रांसफर जॉब से जोड़ता है।
यह सामान्य server-to-server फ़ाइल ट्रांसफर से कैसे अलग है?
सामान्य सर्वर-से-सर्वर ट्रांसफर में अक्सर सोर्स और टार्गेट पहले से तय किए जाते हैं। Dynamic Endpoint Transfer, एक्ज़िक्यूशन के समय चुने गए Endpoint को उसी ट्रांसफर लॉजिक पर लागू कर सकता है।
क्या INNORIX खुद GPU या Kubernetes pod चुनता है?
नहीं। GPU शेड्यूलर, Kubernetes या cloud ऑर्केस्ट्रेटर जैसा मौजूदा इंफ्रास्ट्रक्चर रिसोर्स प्लेसमेंट और Endpoint चुनाव का काम करता है। INNORIX वे फ़ाइलें पहुंचाता है जिनकी चुने गए Endpoint को ज़रूरत होती है।
अगर किसी endpoint का IP address बदल जाए, तो क्या इसका उपयोग किया जा सकता है?
अगर मौजूदा इंफ्रास्ट्रक्चर फ़िलहाल सही Endpoint जानकारी भेजता है और वह Endpoint INNORIX से जुड़ सकता है, तो इसे ट्रांसफर लॉजिक में कोई तय IP बताए बिना सेटअप किया जा सकता है।
क्या इसका उपयोग Kubernetes environment में किया जा सकता है?
इसे इस तरह सेटअप किया जा सकता है कि Kubernetes Workload प्लेसमेंट का नतीजा असली फ़ाइल ट्रांसफर Endpoint से जुड़ जाए। Pod और Node कैसे जुड़ते हैं, Agent चलाने की शर्तें, और नेटवर्क ज़रूरतों की समीक्षा हर वातावरण के हिसाब से करनी होगी।
क्या इसका उपयोग GPU compute pool के साथ भी किया जा सकता है?
इसे इस तरह सेटअप किया जा सकता है कि कोई Dataset किसी बाहरी शेड्यूलर द्वारा चुने गए GPU Compute को पहुंचाया जाए, और बाद में बने नतीजे या Checkpoint इकट्ठा किए जाएं।
Ready, Busy और Offline states कौन तय करता है?
मौजूदा इंफ्रास्ट्रक्चर यह तय करता है कि कोई Workload चल सकता है या नहीं, और रिसोर्स कैसे आवंटित किए जाते हैं। INNORIX, उसे दी गई Endpoint जानकारी और ट्रांसफर-तैयारी स्थिति के आधार पर फ़ाइल ट्रांसफर चलाता है।
अगर endpoints जोड़े या हटाए जाते हैं, तो क्या flow को फिर से बनाना पड़ता है?
अगर इसे भूमिकाओं या Group और एक्ज़िक्यूशन के समय मिलने वाली Endpoint जानकारी के इस्तेमाल के लिए सेटअप किया गया हो, तो वही ट्रांसफर लॉजिक फिर से इस्तेमाल किया जा सकता है। कनेक्शन असल में कितना डायनामिक हो सकता है, यह API और Endpoint रजिस्टर करने के तरीके पर निर्भर करता है।
क्या कोई मौजूदा orchestrator इसे API के ज़रिए कॉल कर सकता है?
कोई मौजूदा ऑर्केस्ट्रेटर Endpoint तय कर सकता है, फिर INNORIX के ट्रांसफर फ़ीचर को कॉल करके स्थिति और नतीजा जांच सकता है। सटीक API और Callback सपोर्ट की पुष्टि डेवलपर डॉक्यूमेंटेशन के आधार पर करनी होगी।
क्या AI training, transfer पूरा होने के बाद ही शुरू किया जा सकता है?
किसी मौजूदा वर्कफ़्लो को इस तरह सेटअप किया जा सकता है कि वह अगला काम चलाने से पहले INNORIX ट्रांसफर की पूर्णता स्थिति की पुष्टि कर ले। स्वीकृत रिक्वेस्ट और असल में पूरे हुए ट्रांसफर के बीच फ़र्क़ बनाए रखना ज़रूरी है।
Dynamic Endpoint Transfer और AI Data Delivery में क्या अंतर है?
Dynamic Endpoint Transfer इस पर फ़ोकस करता है कि फ़ाइलों को अभी किस Compute या Device तक पहुंचना है। AI Data Delivery इस पर फ़ोकस करता है कि किसी AI जॉब को ज़रूरी फ़ाइलों को कैसे मूव किया जाए, जैसे Datasets, Models, Checkpoints और Results।
डायनामिक रूप से execute किए गए transfer का परिणाम मैं कहां देख सकता हूं?
Studio में Runs, चले हुए ट्रांसफर, असल में टार्गेट किए गए Endpoint, प्रगति और पूर्णता नतीजे को दिखाता है।
इनमें से हर एक क्षमता,एक ही platform पर।
इस पृष्ठ पर क्षमता INNORIX Platform द्वारा प्रदान की जाने वाली कई फ़ाइल स्थानांतरण सुविधाओं में से एक है। फ़ाइल स्थानांतरण से लेकर स्वचालन और एकीकृत संचालन तक, हर सुविधा को मुफ्त में आजमाएं।
मुफ्त में शुरू करेंबदलते Endpoints को स्थानांतरण पर विचार कर रहे हैं?
हम आपको Cloud, Kubernetes, और वितरित वातावरण में आवश्यक Dynamic स्थानांतरण सेटअप की समीक्षा करने में मदद करेंगे।
- आपके गतिशील बुनियादी ढांचे वातावरण की समीक्षा
- Endpoint और Group कनेक्शन विधि के लिए प्रस्ताव
- आपके मौजूदा Orchestrator के साथ एकीकरण के बारे में मार्गदर्शन