DYNAMIC ENDPOINT TRANSFER
ปลายทางเปลี่ยนแปลง
การถ่ายโอนไฟล์ยังคงทำงานเหมือนเดิม
เมื่อระบบที่รันงานเปลี่ยนแปลงอยู่เสมอ — GPU Server Kubernetes Workload Cloud Compute — การถ่ายโอนไฟล์ไม่จำเป็นต้องตั้งค่าใหม่ทุกครั้ง
เชื่อมต่อ Endpoint ที่โครงสร้างพื้นฐานที่มีอยู่ของคุณเลือกกับการถ่ายโอนไฟล์ INNORIX ปลายทางที่แท้จริงสามารถเปลี่ยนแปลง และลอจิกการถ่ายโอนไฟล์เดียวกันยังคงส่งไฟล์ที่คุณต้องการ
DYNAMIC ENDPOINT SELECTION
แทนที่จะเป็น Target คงที่
เชื่อมต่อ Endpoint ที่เลือกในเวลาทำงานกับการถ่ายโอนไฟล์
Dynamic Endpoint Transfer ไม่ใช่เพียงคุณลักษณะของสภาพแวดล้อมที่มี Server จำนวนมาก สิ่งสำคัญคือสภาพแวดล้อมที่ Target ที่แท้จริงที่ไฟล์ต้องไปถึงจะถูกตัดสินใจในเวลาทำงาน หรือเปลี่ยนแปลงอยู่เสมอ ใน AI Training GPU Compute ที่จะใช้สามารถแตกต่างกันในการรันแต่ละครั้ง Kubernetes Workload สามารถทำงานบน Pod หรือ Node ใหม่ Cloud Compute จะถูกสร้างเมื่อต้องการ และ Edge Device เชื่อมต่อในเวลาต่างกัน
ในกรณีที่ Transfer แบบดั้งเดิมตรึง IP หรือชื่อโฮสต์เฉพาะเป็น Target Dynamic Endpoint Transfer เชื่อมต่อบทบาทและเงื่อนไขที่งานร้องขอ — "GPU Compute ที่จะรัน Training นี้" "Edge Device ที่พร้อมใช้งานตอนนี้" — กับ Endpoint ที่แท้จริง โครงสร้างพื้นฐานของคุณตัดสินใจ Endpoint ที่แท้จริง และ INNORIX ใช้ผลลัพธ์นั้นกับการถ่ายโอนไฟล์ เพื่อให้ Endpoint สามารถเปลี่ยนแปลงได้โดยไม่ต้องสร้าง Transfer Logic ของงานใหม่
คงที่ปลายทางคงที่
แบบไดนามิกเลือกในเวลาทำงาน
ที่ใช้
- AI Training
- Kubernetes
- Cloud Compute
- Edge
ENDPOINT CONDITIONS & GROUPS
ใช้บทบาท เงื่อนไข และ Group ของ Endpoint
เพื่อสร้างโครงสร้างพื้นฐานที่เปลี่ยนแปลง
แทนที่จะตรึง Transfer ไว้ที่ที่อยู่ IP หรือชื่อของเซิร์ฟเวอร์เดียว Endpoint สามารถตั้งชื่อตามเงื่อนไข: บทบาท ภูมิภาค Workload และสถานะ
โครงสร้างพื้นฐานของคุณเลือก Endpoint ที่ตรงกัน และ INNORIX จะส่งข้อมูลไปให้ เครื่องจักรแตกต่างกันจากการรันหนึ่งไปอีกครั้งหนึ่ง การตั้งค่าการถ่ายโอนไฟล์ไม่เปลี่ยนแปลง
เงื่อนไขปลายทางเงื่อนไขที่ตั้งชื่อปลายทาง
- บทบาทGPU Compute
- ภูมิภาคSeoul
- Workloadการฝึกสอน
- สถานะพร้อม
Endpoint ที่พร้อมเลือกโดยโครงสร้างพื้นฐานของคุณ
- GPU-03Seoul | NVIDIA H100พร้อม
- GPU-07Seoul | NVIDIA H100ที่เลือก
- GPU-12โตเกียว | NVIDIA A100พร้อม
INFRASTRUCTURE INTEGRATION
โครงสร้างพื้นฐานที่มีอยู่ของคุณตัดสินใจ Endpoint State
และ INNORIX ดำเนินการตัดสินใจนั้นเป็นการถ่ายโอนไฟล์
Kubernetes Scheduler GPU Scheduler Cloud Orchestrator หรือ Edge Manager ยังคงตัดสินใจว่าที่ไหนที่จะรัน การถ่ายโอนไฟล์เชื่อมต่อกับมันโดยไม่เปลี่ยนแปลงอะไรเลย
เมื่อระบบของคุณเลือก Pod GPU Server หรือ Edge Device INNORIX จะถ่ายโอนไฟล์ไปยัง Endpoint ที่มอบให้ และส่งคืนความคืบหน้าและผลลัพธ์สำหรับขั้นตอนถัดไป
การผนวกรวมการโอนย้ายการถ่ายโอนไฟล์ไปยัง Endpoint ที่ระบบของคุณเลือก
โครงสร้างพื้นฐานที่มีอยู่
- Kubernetes Schedulerเลือก Pod เป้าหมาย
- GPU Schedulerเลือก GPU Node เป้าหมาย
- Cloud Orchestratorเลือก Compute Instance
- Edge Managementเลือก Edge Device เป้าหมาย
Endpoint ที่เลือก
INNORIX ไม่ได้จัดสรร Compute หรือตัดสินใจ Workload Placement
WORKLOAD LIFECYCLE
ใน Workload และ Endpoint Lifecycle
เชื่อมต่อจุดที่ต้องการข้อมูล
Cloud VM GPU Compute Node หรือ Kubernetes Pod ถูกสร้างเมื่องานเริ่มต้น และปล่อยออกเมื่อจบสิ้น Transfer ที่สร้างบน Server คงที่ไม่สามารถตามได้
INNORIX ส่งข้อมูล Dataset เมื่อ Endpoint พร้อม และรวบรวมข้อมูลผลลัพธ์เข้า Storage ที่คุณตั้งชื่อเมื่องานเสร็จสิ้น การสร้างและปล่อย Server ยังคงเป็นของโครงสร้างพื้นฐานของคุณ
วงจรชีวิตของเอนด์พอยต์การถ่ายโอนไฟล์ติดตามหา Endpoint จากการสร้างถึงการปล่อย
- 1. สร้างEndpoint ถูกสร้างสร้าง
- 2. พร้อมสภาพแวดล้อมสำหรับงานพร้อมพร้อม
- 3. การส่งข้อมูลข้อมูลที่จำเป็นได้รับการส่งส่งแล้ว
- 4. การรันงานงานทำงานบนข้อมูลที่ส่งเสร็จแล้ว
- 5. การรวบรวมข้อมูลผลลัพธ์ถูกรวบรวมกลับรวบรวมแล้ว
- 6. ปล่อยEndpoint ถูกปล่อยเมื่องานสิ้นสุดปล่อย
ORCHESTRATOR & API
เรียกใช้ Dynamic Transfer
จาก Orchestrator และ API ที่มีอยู่ของคุณ
เมื่อ Endpoint ได้ถูกตัดสินใจในระบบที่มีอยู่ — Kubernetes GPU Scheduler Cloud Orchestrator — ระบบนั้นเรียกใช้ความสามารถการถ่ายโอนไฟล์ของ INNORIX
Workflow Logic และ Scheduling ยังคงอยู่ในระบบที่มีอยู่ของคุณ และเชื่อมต่อเพียงการถ่ายโอนไฟล์เป็น Data Movement Layer อิสระ Endpoint แตกต่างกันในการรันแต่ละครั้ง ขณะที่การเรียกใช้และการจัดการผลลัพธ์ยังคงเหมือนเดิม ดังนั้นความสามารถการถ่ายโอนไฟล์จึงถูกเพิ่มไปยัง Dynamic Infrastructure โดยไม่ต้องกำหนด Automation ที่มีอยู่ใหม่
API Interface
UNIFIED OPERATIONS
ไม่ว่า Endpoint จะเปลี่ยนแปลงเท่าไร
ตรวจสอบผลลัพธ์การถ่ายโอนไฟล์ทุกงานบนแพลตฟอร์มเดียว
GPU หรือ Compute ที่รันงานแตกต่างกันทุกครั้ง และยังคงงานการถ่ายโอนไฟล์และผลลัพธ์ไม่ต้องการการจัดการแยกต่างหาก
จัดการเครื่องจักรที่เชื่อมต่อและ Transfer Flow ใน INNORIX Studio และใน Run ตรวจสอบ Endpoint ที่ถูกเลือกจริง ความคืบหน้าของการถ่ายโอนไฟล์ และผลลัพธ์เสร็จสิ้น
Training Data Deliveryเงื่อนไขปลายทาง | GPU · การฝึก · พร้อม
GET STARTED
เชื่อมต่อการถ่ายโอนไฟล์กับ Endpoint ที่เปลี่ยนแปลงอยู่เสมอ
เชื่อมต่อ Endpoint ที่ Kubernetes GPU Scheduler หรือ Cloud Orchestrator ที่มีอยู่ของคุณเลือกกับงานการถ่ายโอนไฟล์ INNORIX
ตรวจสอบผลลัพธ์การถ่ายโอนไฟล์ใน Studio และรวมระบบกับ Workload ที่มีอยู่ของคุณผ่าน API
TECHNICAL FAQ
คำถามที่พบบ่อย
Dynamic Endpoint Transfer คืออะไร?
ในสภาพแวดล้อมที่ Source หรือ Target ของการถ่ายโอนไฟล์ไม่ใช่เซิร์ฟเวอร์คงที่ แต่ถูกตัดสินใจในขณะการดำเนินการ มันเชื่อมต่อ Endpoint ที่เลือกจริงกับงานการถ่ายโอนไฟล์ที่มีอยู่
แตกต่างจากการถ่ายโอนไฟล์เซิร์ฟเวอร์ไปเซิร์ฟเวอร์ธรรมดาได้อย่างไร?
การถ่ายโอนไฟล์เซิร์ฟเวอร์ไปเซิร์ฟเวอร์ธรรมดาโดยปกติจะตรึง Source และ Target ล่วงหน้า Dynamic Endpoint Transfer สามารถใช้ Endpoint ที่เลือกในเวลาดำเนินการกับลอจิกการถ่ายโอนไฟล์เดียวกัน
INNORIX เลือก GPU หรือ Kubernetes Pod เอง?
ไม่ โครงสร้างพื้นฐานที่มีอยู่เช่น GPU Scheduler Kubernetes หรือ Cloud Orchestrator จัดการการวาง Resource และเลือก Endpoint INNORIX ส่งไฟล์ที่ Endpoint ที่เลือกต้องการ
สามารถใช้ได้เมื่อที่อยู่ IP ของ Endpoint เปลี่ยนแปลง?
หากโครงสร้างพื้นฐานที่มีอยู่ส่งข้อมูล Endpoint ที่ถูกต้องปัจจุบัน และ Endpoint นั้นสามารถเชื่อมต่อ INNORIX ได้ มันสามารถตั้งค่าได้โดยไม่ต้องตั้งชื่อ IP คงที่ในลอจิกการถ่ายโอนไฟล์
สามารถใช้ในสภาพแวดล้อม Kubernetes ได้?
สามารถตั้งค่าเพื่อเชื่อมต่อผลลัพธ์ของการวาง Kubernetes Workload กับ Endpoint การถ่ายโอนไฟล์จริง วิธีการเชื่อมต่อ Pod และ Node เงื่อนไขสำหรับการรัน Agent และความต้องการเครือข่ายต้องได้รับการตรวจสอบต่อสภาพแวดล้อม
สามารถใช้กับ GPU Compute Pool ได้?
สามารถตั้งค่าเพื่อส่ง Dataset ไปยัง GPU Compute ที่ Scheduler ภายนอกเลือก และรวบรวม Result หรือ Checkpoint ที่สร้างหลังจากนั้น
ใครตัดสินใจ Ready Busy และ Offline State?
โครงสร้างพื้นฐานที่มีอยู่ตัดสินใจว่า Workload สามารถรันและ Resource ถูกจัดสรรอย่างไร INNORIX รันการถ่ายโอนไฟล์บนข้อมูล Endpoint และสถานะพร้อมการถ่ายโอนไฟล์ที่มอบให้
หากเพิ่มหรือลบ Endpoint Flow ต้องถูกสร้างใหม่?
หากตั้งค่าให้ใช้บทบาทหรือกลุ่มและข้อมูล Endpoint ที่มีอยู่ในเวลาการดำเนินการ ลอจิกการถ่ายโอนไฟล์เดียวกันสามารถนำมาใช้ซ้ำได้ ว่าการเชื่อมต่อสามารถเป็นแบบไดนามิกได้แค่ไหนขึ้นอยู่กับ API และวิธีการลงทะเบียน Endpoint
Orchestrator ที่มีอยู่สามารถเรียกใช้ผ่าน API ได้?
Orchestrator ที่มีอยู่สามารถตัดสินใจ Endpoint จากนั้นเรียกใช้คุณลักษณะการถ่ายโอนไฟล์ INNORIX และตรวจสอบสถานะและผลลัพธ์ API ที่เฉพาะเจาะจงและการสนับสนุน Callback ต้องได้รับการยืนยันตามเอกสารนักพัฒนา
สามารถเริ่มการฝึกสอน AI ได้หลังจากการถ่ายโอนไฟล์สำเร็จ?
Workflow ที่มีอยู่สามารถตั้งค่าเพื่อยืนยันสถานะเสร็จสิ้นการถ่ายโอนไฟล์ INNORIX ก่อนการรันงานถัดไป คำขอที่ยอมรับและการถ่ายโอนไฟล์ที่เสร็จสิ้นจริงต้องแยกต่างหากจากกัน
ความแตกต่างระหว่าง Dynamic Endpoint Transfer และ AI Data Delivery?
Dynamic Endpoint Transfer มุ่งเน้นไปที่ว่า Compute หรือ Device ใดที่ไฟล์ต้องไปถึงตอนนี้ AI Data Delivery มุ่งเน้นไปที่การเคลื่อนตัวไฟล์ที่งาน AI ต้องการ เช่น Dataset Model Checkpoint และ Result
ผลลัพธ์ของการถ่ายโอนไฟล์ที่ทำงานแบบไดนามิกอยู่ที่ไหน?
Runs ใน Studio แสดงการถ่ายโอนไฟล์ที่รัน Endpoint ที่มันมุ่งไป ความคืบหน้า และผลลัพธ์เสร็จสิ้น
ทุกความสามารถเหล่านี้อยู่บนแพลตฟอร์มเดียว
ความสามารถในหน้านี้เป็นหนึ่งในฟีเจอร์การโอนย้ายไฟล์ มากมายที่ INNORIX Platform มีให้ ตั้งแต่การโอนย้ายไฟล์ไปจนถึงการทำงานอัตโนมัติและการดำเนินงานแบบครบวงจร ลองใช้ทุกฟีเจอร์ได้ฟรี
เริ่มต้นใช้งานฟรีกำลังพิจารณาการโอนย้ายไปยัง Endpoint ที่เปลี่ยนแปลงอยู่เสมอหรือไม่
เราจะช่วยคุณตรวจสอบรูปแบบการตั้งค่า Dynamic Transfer ที่คุณต้องการ ครอบคลุมทั้ง Cloud, Kubernetes และสภาพแวดล้อมแบบกระจาย
- ตรวจสอบสภาพแวดล้อม Dynamic Infrastructure ของคุณ
- เสนอแนวทางการเชื่อมต่อ Endpoint และ Group
- ให้คำแนะนำในการผสานรวมกับ Orchestrator ที่คุณมีอยู่