GPUStack को v0.7.1 से v2.1.1 में माइग्रेशन की कहानी

GPUStack को v0.7.1 से v2.1.1 में माइग्रेशन की कहानी

6 min read

Tech Blog
GPUStack
Docker Migration
NFS Shared Cache

GPU क्लस्टर ऑपरेशंस नोट्स

GPUStack को v0.7.1 से v2.1.1 में माइग्रेट करना
shared NFS मॉडल cache कॉन्फ़िगरेशन को तोड़े बिना अपग्रेड #

Legacy installation script आधार पर चलाए जा रहे GPUStack एनवायरनमेंट को Docker-आधारित v2 सीरीज़ में माइग्रेट करने का रिकॉर्ड।
जिस कॉन्फ़िगरेशन में management node ही NFS की भूमिका भी निभाता है उसे बरकरार रखते हुए, हमने 2 GPU worker नोड्स को चरणबद्ध तरीके से माइग्रेट किया,
और model cache शेयरिंग, worker reconnection, तथा deployment के समय backend/CUDA कंसिस्टेंसी वेरिफिकेशन को व्यवस्थित किया।

सार्वजनिक प्रकाशन के लिए hostname, IP और token को एब्स्ट्रैक्ट किया गया है
Ubuntu / Docker / NVIDIA GPU / NFS
लक्ष्य: GPUStack v0.7.1 → v2.1.1

इस लेख की पूर्व-धारणाएँ #

प्रोडक्शन एनवायरनमेंट में हमारे पास 1 management node और 2 GPU workers वाला कॉन्फ़िगरेशन है, और model cache को
/models में समेकित करके NFS के ज़रिए शेयर किया जाता है। इस लेख में वास्तविक hostname,
private IP और worker token जैसी संवेदनशील जानकारी को पूरी तरह हटाकर, सार्वजनिक प्रकाशन के उपयुक्त स्तर तक एब्स्ट्रैक्ट किया गया है।

मूल कॉन्फ़िगरेशन सरल था: “management node पर GPUStack Server और NFS समेकित हैं, और GPU worker नोड्स
एक साझा /models को रेफ़र करते हैं”। इसका फ़ायदा यह था कि model फ़ाइलें एक बार डाउनलोड करके, worker जोड़ते समय disk उपयोग और
network ट्रांसफ़र घटाया जा सकता था। हमने तय किया कि v2 सीरीज़ में माइग्रेट करते समय भी यही दर्शन बनाए रखेंगे,
और ऑपरेशंस को बस मौजूदा तरीके के अनुरूप पुनर्गठित किया।

अपग्रेड से पहले और बाद का दृष्टिकोण #

Before #

Legacy installation script से डिप्लॉय किए गए GPUStack को systemd सर्विस के रूप में चलाना।

Transition #

पहले management node को Docker-आधारित v2.1.1 में माइग्रेट करें, फिर GPU workers को चरणबद्ध रूप से स्विच करें।

After #

Management node केवल Server + NFS के लिए समर्पित, inference 2 GPU workers पर समेकित। /models पहले की तरह शेयर होता रहता है।

Management Node

GPUStack Server + NFS #

Docker-आधारित GPUStack Server शुरू करें और model cache की मूल प्रति यहीं रखें।

  • केवल Server चलाएँ
  • Embedded worker को disable करें
  • /models को NFS export के रूप में उपलब्ध कराएँ
Shared

GPU Worker A / B

GPUStack Worker #

NFS से शेयर किए गए /models को mount करें और inference कंटेनर शुरू करें।

  • Docker + NVIDIA runtime
  • --cache-dir /models को एकीकृत रखें
  • Worker name और IP स्पष्ट रूप से निर्दिष्ट करें

v2 सीरीज़ में अपग्रेड से पहले समझने योग्य मुख्य बिंदु #

1. माइग्रेशन Docker मानकर चलता है #

Legacy installation script या pip-आधारित तरीके से डिप्लॉय किए गए एनवायरनमेंट को
v2 सीरीज़ के आधिकारिक माइग्रेशन पथ के रूप में Docker-आधारित फ़ाउंडेशन अपनानी होगी।

2. Management DB भी बदलता है #

v0.7 सीरीज़ और उससे पहले डिफ़ॉल्ट रहे SQLite से, v2.0 और बाद के वर्ज़न embedded PostgreSQL में माइग्रेट होते हैं।
यानी यह सिर्फ़ binaries बदलने का काम नहीं, बल्कि migration को ध्यान में रखकर किया जाने वाला ऑपरेशन है।

3. Embedded worker को स्पष्ट करें #

Legacy कॉन्फ़िगरेशन में management node भी एक worker के रूप में दिखता था। इस माइग्रेशन के साथ,
हमने नीति बदलकर management node को Server-only बनाने का निर्णय लिया,
ताकि Workers सूची में केवल GPU workers ही बचें।

जो काम सबसे पहले करना बेहतरीन साबित हुआ #

Server को छूने से पहले हमने legacy data directory का backup लिया।
v2 सीरीज़ में नए कंपोनेंट legacy data dir को पढ़ते हैं, इसलिए permission समायोजन और backup बेहद महत्वपूर्ण हैं।

लागू की गई अपग्रेड प्रक्रिया #

01

Legacy data dir पहचानें और सबसे पहले backup लें #

हमने legacy systemd डेफ़िनिशन की जाँच करके स्पष्ट किया कि Server और Worker क्रमशः कौन-से data dir उपयोग करते हैं।
फिर हमने क्रम से service stop → tar backup → permission समायोजन किया।

sudo systemctl cat gpustack | sed -n '/ExecStart/p'
sudo systemctl stop gpustack
sudo systemctl disable gpustack

sudo tar -C / -cpf /root/backup/gpustack-server.tar var/lib/gpustack
02

पहले management node को v2.1.1 में माइग्रेट करें #

चूँकि management node पर GPU उपयोग की योजना नहीं थी, हमने Server स्टार्टअप से --runtime nvidia हटा दिया।
अगर इसे लगा छोड़ दिया जाए, तो unknown or invalid runtime name: nvidia त्रुटि के साथ स्टार्टअप विफल हो जाएगा
उन servers पर जहाँ Docker में NVIDIA runtime रजिस्टर्ड नहीं है।

sudo docker run -d --name gpustack \
  --restart=unless-stopped \
  --privileged \
  --network=host \
  --env GPUSTACK_DATA_MIGRATION=true \
  --volume /var/run/docker.sock:/var/run/docker.sock \
  --volume /var/lib/gpustack:/var/lib/gpustack \
  --volume /models:/models \
  gpustack/gpustack:v2.1.1 \
  --disable-worker \
  --cache-dir /models

हमने --disable-worker स्पष्ट रूप से निर्दिष्ट किया क्योंकि हम management node पर पुराने embedded worker से
भूमिकाओं को साफ़-साफ़ अलग करना चाहते थे। इस माइग्रेशन की थीम थी “management node केवल management पर फ़ोकस करे”।

03

GPU workers को चरणबद्ध रूप से Docker-आधारित worker में स्विच करें #

Workers ने मौजूदा data dir को इनहेरिट किया और Docker-आधारित workers के रूप में फिर से कनेक्ट किए गए।
Shared cache पाथ मिलाने के लिए हम कंटेनर में भी /models:/models bind करते हैं,
और स्टार्टअप arguments में --cache-dir /models जोड़ते हैं।

sudo docker run -d --name gpustack-worker \
  --restart=unless-stopped \
  --privileged \
  --network=host \
  --volume /var/lib/gpustack-data:/var/lib/gpustack \
  --volume /var/run/docker.sock:/var/run/docker.sock \
  --volume /models:/models \
  --runtime nvidia \
  gpustack/gpustack:v2.1.1 \
  --server-url http://<SERVER_IP> \
  --token <JOIN_TOKEN> \
  --worker-name <WORKER_NAME> \
  --worker-ip <WORKER_IP> \
  --cache-dir /models

मुख्य बात यह है कि GUI के “Add Worker” को महज़ “रजिस्ट्रेशन का काम” न समझा जाए।
असल में GUI केवल token और execution command प्राप्त करने का एक entry point है;
Ready स्टेटस तभी आता है जब worker node पर वास्तविक command execute किया जाए।

04

NVIDIA Container Toolkit को वेरिफ़ाई करें #

GPU workers को --runtime nvidia चाहिए। अगर Docker उस runtime को नहीं जानता,
तो हो सकता है कि NVIDIA Container Toolkit का कॉन्फ़िगरेशन लागू न हुआ हो। आधिकारिक प्रक्रिया के अनुसार
nvidia-ctk से Docker runtime कॉन्फ़िगर करें और Docker को restart करें।

sudo nvidia-ctk runtime configure --runtime=docker
sudo systemctl restart docker
05

Workers सूची को “केवल वास्तव में inference करने वाले नोड्स” तक साफ़ करें #

Legacy एनवायरनमेंट में management node worker के रूप में बना रहता था और सूची में Not Ready दिखता था, जो भ्रम का स्रोत था।
जब 2 GPU workers Ready हो गए, तो हमने management node के stale workers को cleanup के लिए चुना।
इससे ऑपरेशंस टीमों के लिए भी भूमिका सहज रूप से समझ में आती है।

इस बार जिन कठिनाइयों से हम टकराए #

Management node: unknown or invalid runtime name: nvidia #

हम --runtime nvidia के साथ शुरू कर रहे थे, जबकि Server node पर कोई GPU नहीं था,
या NVIDIA runtime इंस्टॉल नहीं किया गया था। अगर management node को Server-only समर्पित करना है,
तो इसे सीधे हटा देना ही बेहतर था।

Worker Ready है लेकिन model Pending है #

Worker का स्टेटस और model deployment की उपलब्धता दो अलग मुद्दे हैं। ख़ासकर v2 माइग्रेशन के तुरंत बाद,
पुराने से आए backend version या CUDA जनरेशन के mismatch के कारण Pending हो सकता है।
“Worker Ready हो गया तो काम पूरा” अंत नहीं है; असली माइग्रेशन में 1 model deploy करके वेरिफ़ाई करना भी शामिल है।

Deployment से मिले सबक़ #

इस बार worker साइड पर OS अपडेट भी शामिल थे, जिससे CUDA-संबंधित पैकेज 12.9 जनरेशन पर आ गए।
उस स्थिति में हमें GPUStack साइड पर built-in backend version और deployment सेटिंग्स की समीक्षा करनी पड़ी।
माइग्रेशन के बाद Inference Backends और Deployment के backend/version स्पेसिफ़िकेशन
को एक सेट के रूप में जाँचना सुरक्षित रहता है।

चेकलिस्ट #

  • सबसे पहले legacy एनवायरनमेंट के data dirs और systemd डेफ़िनिशन को समझें
  • Migration शुरू करने से पहले Server का backup लें
  • पहले management node उठाएँ, GPU workers सबसे बाद में
  • अगर NFS shared cache उपयोग कर रहे हैं, तो host / container / worker सभी में /models को एकीकृत रखें
  • अगर node Server-only है, तो embedded worker को disable करें और Workers सूची सरल बनाएँ
  • Worker कनेक्शन के बाद, backend/CUDA कंसिस्टेंसी वेरिफ़ाई करने के लिए हमेशा 1 model deploy करें

सारांश #

इस अपग्रेड में सबसे बड़ा अंतर वर्ज़न अपग्रेड करने से नहीं आया,
बल्कि “नोड की भूमिकाओं को स्पष्ट करने और स्क्रीन पर जो दिखता है उसे अधिक समझने योग्य बनाने” से आया।
स्पष्ट विभाजन के साथ—management node यानी Server + NFS, inference केवल GPU workers पर—
आगे के परिचालन निर्णय कहीं ज़्यादा आसान हो गए।

अगर आप भी इसी तरह v0.7 सीरीज़ या उससे पहले का उपयोग कर रहे हैं और shared cache कॉन्फ़िगरेशन बनाए रखते हुए v2 सीरीज़ में अपग्रेड करना चाहते हैं,
तो हम इन 3 बिंदुओं की पुरज़ोर सिफ़ारिश करते हैं: पहले Server, फिर Workers, और deployment का पूर्ण वेरिफ़िकेशन।
“चालू हो गया” पर मत रुकिए; वास्तविक model का स्टार्टअप देख लेने से माइग्रेशन की गुणवत्ता कहीं अधिक स्थिर हो जाती है।

उपयोग किए गए आधिकारिक संदर्भ #

यह लेख विशिष्ट आंतरिक एनवायरनमेंट पर आधारित एक व्यावहारिक मेमो है। वास्तविक ऑपरेशंस में लागू करते समय,
उपयोग में आने वाले GPU, drivers, CUDA जनरेशन और backend version के संयोजनों को हमेशा नवीनतम आधिकारिक जानकारी से पुनः सत्यापित करें।

Updated on 2026 वर्ष 6 माह 10 दिन

What are your feelings

  • Happy
  • Normal
  • Sad
目次