DYNAMIC ENDPOINT TRANSFER
Cel się zmienia.
Przesyłanie plików przebiega tak jak dotychczas.
Tam, gdzie system wykonujący pracę nieustannie się zmienia — serwery GPU, workloady Kubernetes, Cloud compute — transfer plików nie musi być konfigurowany od nowa każdym razem.
Połącz endpoint wybrany przez Twoją istniejącą infrastrukturę z transferem INNORIX. Rzeczywisty cel może się zmieniać, a ta sama logika transferu wciąż dostarcza potrzebne pliki.
DYNAMIC ENDPOINT SELECTION
Zamiast stałego Target,
połącz Endpoint wybrany w czasie działania z Transfer.
Dynamic Endpoint Transfer to nie po prostu funkcja dla środowisk z bardzo dużą liczbą serwerów. Liczy się środowisko, w którym rzeczywisty Target, do którego musi trafić plik, jest ustalany w czasie działania albo nieustannie się zmienia. W AI Training wykorzystywane GPU Compute może różnić się przy każdym przebiegu, Kubernetes Workload może działać na nowym Pod lub Node, Cloud Compute jest tworzone w chwili, gdy jest potrzebne, a Edge Devices łączą się w różnych momentach.
Tam, gdzie klasyczny transfer ustala jako Target konkretny adres IP lub nazwę hosta, Dynamic Endpoint Transfer łączy z rzeczywistym Endpointem rolę i warunek wymagany przez pracę — „GPU Compute, które wykona ten Training", „Edge Device, które jest akurat Ready". Twoja infrastruktura decyduje o faktycznym Endpoincie, a INNORIX przekazuje ten wynik do File Transfer, dzięki czemu Endpoint może się zmieniać, a Transfer Logic tej pracy nie trzeba budować od nowa.
StatycznyStały cel
DynamicznyZur Laufzeit ausgewahlt
Gdzie jest używany
- AI Training
- Kubernetes
- Cloud Compute
- Edge
ENDPOINT CONDITIONS & GROUPS
Wykorzystaj rolę, warunki i Group endpointu,
aby zbudować zmieniającą się infrastrukturę.
Zamiast przypiętowania transferu do adresu IP lub nazwy jednego serwera, punkt końcowy może być określany warunkami: rolą, regionem, obciążeniem i statusem.
Twoja infrastruktura wybiera pasujący endpoint, a INNORIX dostarcza do niego dane. Maszyna zmienia się przy każdym przebiegu; konfiguracja transferu pozostaje bez zmian.
Warunek docelowyWarunki określające cel.
- RolaGPU Compute
- RegionSeoul
- WorkloadTraining
- StatusGotowy
Verfugbare EndpointsVon Ihrer Infrastruktura ausgewahlt
- GPU-03Seoul | NVIDIA H100Verfugbar
- GPU-07Seoul | NVIDIA H100Ausgewahlt
- GPU-12Tokio | NVIDIA A100Verfugbar
INFRASTRUCTURE INTEGRATION
Twoja istniejąca infrastruktura decyduje o stanie Endpoint,
a INNORIX realizuje tę decyzję jako Transfer.
Kubernetes scheduler, GPU scheduler, cloud orchestrator lub edge manager wciąż decyduje, co działa gdzie. Transfer plików zostaje z tym połączony, bez zmiany tego mechanizmu.
Gdy Twój system wybierze Pod, serwer GPU lub Edge Device, INNORIX przesyła pliki do przekazanego mu endpointu i zwraca postęp oraz wynik na potrzeby kolejnego kroku.
Integracja transferuTransfer trafia do Endpoint, który wybrał Twój system.
Bestehende Infrastruktura
- Kubernetes SchedulerWybiera docelowy Pod
- GPU SchedulerWybiera docelowy węzeł GPU
- Cloud OrchestratorWybiera instancję Compute
- Edge ManagementWybiera docelowy Edge Device
Ausgewahlter Endpoint
INNORIX nie udostępnia Compute i nie decyduje o Workload Placement.
WORKLOAD LIFECYCLE
W Lifecycle Workloadu i Endpointu
połącz punkty, w których potrzebne jest Data.
Cloud VM, GPU compute node lub Kubernetes Pod powstaje, gdy praca się zaczyna, i jest zwalniany, gdy się kończy. Transfer zbudowany na stałym serwerze nie jest w stanie za tym nadążyć.
INNORIX dostarcza Dataset, gdy endpoint jest gotowy, i zbiera dane wynikowe we wskazanym przez Ciebie Storage, gdy zadanie zostaje zakończone. Tworzenie i zwalnianie serwera pozostaje po stronie Twojej własnej infrastruktury.
Cykl życia EndpointTransfer podąża za punktem końcowym od utworzenia do zwolnienia.
- 1. UtworzonoPunkt końcowy jest tworzony.Utworzono
- 2. GotoweŚrodowisko dla zadania jest gotowe.Gotowy
- 3. Data DeliveryWymagane dane są dostarczane.Dostarczono
- 4. Job-AusfuhrungZadanie działa na dostarczonych danych.Zakończono
- 5. CollectionDie Wynikdaten werden zuruckgesammelt.Zebrano
- 6. ZwolnionoPunkt końcowy jest zwalniane po zakończeniu zadania.Zwolniono
ORCHESTRATOR & API
Wywołaj Dynamic Transfer
z istniejącego Orchestratora i API.
Gdy Endpoint zostanie ustalony w istniejącym systemie — Kubernetes, GPU Scheduler, Cloud Orchestrator — ten system wywołuje funkcję transferu INNORIX.
Workflow Logic i Scheduling pozostają w Twoim obecnym systemie, a jako niezależna Data Movement Layer podłączony jest tylko File Transfer. Endpoint zmienia się przy każdym przebiegu, podczas gdy wywołanie i obsługa jego wyniku pozostają takie same — dzięki temu Transfer Capability zostaje dodana do Dynamic Infrastructure, bez potrzeby ponownego definiowania Twojej istniejącej Automation.
API Interface
UNIFIED OPERATIONS
Niezależnie od tego, jak bardzo zmienia się Endpoint,
sprawdzaj każdy wynik transferu na jednej platformie.
GPU lub Compute wykonujące pracę różni się przy każdym przebiegu, a mimo to zadania transferu i ich wyniki nie wymagają odrębnego zarządzania.
Zarządzaj podłączonymi maszynami i transfer Flows w INNORIX Studio, a w Runs sprawdzaj faktycznie wybrany Endpoint, postęp transferu i jego wynik końcowy.
Training Data DeliveryTarget-Bedingung | GPU · Szkolenie · Bereit
GET STARTED
Połącz przesyłanie plików z nieustannie zmieniającymi się Endpoints.
Połącz Endpoint wybrany przez Twój istniejący Kubernetes, GPU Scheduler lub Cloud Orchestrator z zadaniem przesyłania plików INNORIX.
Sprawdź wynik transferu w Studio i zintegruj go z istniejącym Workload za pomocą API.
TECHNICAL FAQ
Haufig gestellte Fragen
Co to jest Dynamic Endpoint Transfer?
W środowisku, w którym Source lub Target transferu plików nie jest stałym serwerem, lecz jest ustalany w momencie wykonania, łączy on faktycznie wybrany endpoint z istniejącym zadaniem transferu.
Czym różni się od zwykłego przesyłania plików serwer-serwer?
Zwykły transfer serwer-serwer zazwyczaj ustala Source i Target z wyprzedzeniem. Dynamic Endpoint Transfer może zastosować do tej samej logiki transferu Endpoint wybrany w momencie wykonania.
Czy INNORIX samodzielnie wybiera GPU lub Pod Kubernetes?
Nie. Istniejąca infrastruktura, taka jak GPU Scheduler, Kubernetes czy Cloud Orchestrator, zajmuje się rozmieszczeniem zasobów i wyborem Endpoint. INNORIX dostarcza pliki potrzebne wybranemu Endpoint.
Czy można go używać, gdy zmienia się adres IP endpointu?
Jeśli istniejąca infrastruktura przekazuje aktualnie obowiązujące informacje o endpoincie, a ten endpoint może połączyć się z INNORIX, można to skonfigurować bez podawania stałego adresu IP w logice transferu.
Czy można go używać w środowisku Kubernetes?
Można to skonfigurować tak, aby wynik Kubernetes Workload Placement był łączony z rzeczywistym endpointem transferu plików. Sposób łączenia Pod i Node, warunki działania Agent oraz wymagania sieciowe trzeba zweryfikować dla każdego środowiska.
Czy można go używać również z pulą obliczeniową GPU?
Można to skonfigurować tak, aby dostarczać Dataset do GPU Compute wybranego przez zewnętrzny scheduler i zbierać wyniki lub Checkpoints wygenerowane później.
Kto decyduje o stanach Ready, Busy i Offline?
Istniejąca infrastruktura decyduje, czy Workload może zostać uruchomiony i jak przydzielane są zasoby. INNORIX wykonuje transfer plików na podstawie przekazanych mu informacji o endpoincie oraz stanu gotowości do transferu.
Czy flow trzeba budować od nowa, gdy endpointy są dodawane lub usuwane?
Jeśli skonfigurowano go tak, aby wykorzystywał role lub Groups oraz informacje o endpointach dostępne w czasie wykonania, tę samą logikę transferu można wykorzystać ponownie. To, jak bardzo dynamiczne może być w praktyce to połączenie, zależy od API i sposobu rejestrowania endpointów.
Czy istniejący orchestrator może go wywołać przez API?
Istniejący orchestrator może wybrać endpoint, a następnie wywołać funkcję transferu INNORIX i sprawdzić status oraz wynik. Konkretne wsparcie API i callback trzeba potwierdzić w dokumentacji dla deweloperów.
Czy AI Training można uruchomić tylko po zakończeniu transferu?
Istniejący workflow można skonfigurować tak, aby potwierdzał stan zakończenia transferu INNORIX, zanim zostanie wykonane kolejne zadanie. Przyjęte żądanie i faktycznie zakończony transfer trzeba rozróżniać.
Jaka jest różnica między Dynamic Endpoint Transfer a AI Data Delivery?
Dynamic Endpoint Transfer koncentruje się na tym, do jakiego Compute lub Device muszą teraz trafić pliki. AI Data Delivery koncentruje się na przenoszeniu plików potrzebnych do zadania AI, takich jak Datasets, Models, Checkpoints i Results.
Gdzie sprawdzam wynik dynamicznie wykonanego transferu?
Runs in Studio pokazuje wykonany transfer, Endpoint, do którego faktycznie skierowano transfer, postęp oraz wynik zakończenia.
Każda z tych możliwości,na jednej platformie.
Możliwość na tej stronie jest jedną z wielu funkcji transferu plików jakie zapewnia platforma INNORIX. Od transferu plików do automatyzacji i ujednoliconych operacji, spróbuj każdej funkcji za darmo.
Zacznij za darmoRozważasz transfer do zmieniających się punktów końcowych?
Pomożemy Ci przejrzeć dynamiczną konfigurację transferu, której potrzebujesz w chmurze, Kubernetes i rozproszczonych środowiskach.
- Przegląd środowiska dynamicznej infrastruktury
- Propozycja metody połączenia punktu końcowego i grupy
- Wskazówki dotyczące integracji z istniejącym orkiestratorem