कस्टमर एज डायग्नोस्टिक्स

एक कस्टमर एज (CE) वह F5 Distributed Cloud नोड है जिसे यह रिपॉज़िटरी Azure में प्रोविज़न करती है — terraform/modules/ce-node, जो volterraedgeservices/volterra-node मार्केटप्लेस इमेज से बनाया गया है।

यह डेटा प्लेन (Argo), कंट्रोल प्लेन (Vega), एक Envoy प्रॉक्सी, एक Kubernetes स्टैक, और vpm चलाता है — वह एजेंट जो नोड को रजिस्टर करता है और उस पर बाकी सब कुछ प्रबंधित करता है।

जब कोई CE ठीक से काम नहीं करता, तो Site CLI ही उपकरण है। पहला निर्णय यह है कि कौन सा एक्सेस पथ लागू होता है, और इसे गलत समझना इस तरह समय बर्बाद करता है कि यह एक खराब नोड जैसा दिखता है।

चार एक्सेस पथ, और वे परस्पर विनिमेय नहीं हैं

Debug APIFor a node that is ONLINE. Scriptable, read-only, and covers 34 commands.

Site ConsoleF5's own per-node troubleshooting UI, over an Azure Bastion tunnel. No SSH key, no jump host.

SSHThe full on-box Site CLI. Needs a key present from first boot and a host inside the VNet.

Serial consoleFor a node that never registered. The only route when the node has no network path.

डीबग API नोड तक F5 Distributed Cloud कंट्रोल प्लेन के माध्यम से पहुँचता है। यही पूरी वजह है कि यह विभाजन महत्वपूर्ण है: API केवल तब उत्तर दे सकता है जब नोड रजिस्टर हो चुका हो और ONLINE रिपोर्ट करे।

एक नोड जो रजिस्टर होने में विफल रहा — खराब cloud-init, एक समाप्त हो चुका टोकन, register.ves.volterra.io तक कोई रूट नहीं — ठीक वही स्थिति है जहाँ आपको डायग्नोस्टिक्स की आवश्यकता होती है, और ठीक वही स्थिति है जिसे API सेवा नहीं दे सकता।

Site Console पहले आज़माने वाला विकल्प है जब आप विशिष्ट कमांड के बजाय F5 का अपना ट्रबलशूटिंग UI चाहते हैं। यह आपसे सबसे कम माँगता है — कोई कुंजी नहीं, कोई जंप होस्ट नहीं, नोड पर कोई सार्वजनिक IP नहीं — क्योंकि कौन कनेक्ट कर सकता है, यह एक Azure RBAC निर्णय बन जाता है, और यह चाहे साइट रजिस्टर हुई हो या नहीं, उत्तर देता है। इसे Azure Bastion की आवश्यकता होती है, जिसे यह डिप्लॉयमेंट enable_bastion के पीछे नियंत्रित करता है और जो डिफ़ॉल्ट रूप से डिप्लॉय नहीं होता।

SSH एकमात्र मार्ग है जो एप्लायंस की पूरी कमांड सतह तक पहुँचता है — डीबग API 34 कमांड उजागर करता है और नोड स्वयं कई और प्रदान करता है। दो चीज़ें इसे सीमित करती हैं। sshd केवल नोड के आंतरिक (SLI) पते पर उत्तर देता है, इसलिए इसे VNet के भीतर एक होस्ट की आवश्यकता होती है; और कुंजी पहले बूट पर cloud-init द्वारा लिखी जाती है, क्योंकि साइट ऑब्जेक्ट पर ssh_key फ़ील्ड निष्क्रिय है — vpm admin उपयोगकर्ता को छोड़ देता है और उसे कभी लागू नहीं करता। इसलिए चल रहे नोड्स पर इसे सक्षम करने का अर्थ है उन्हें बदलना।

तो: यदि साइट ONLINE है और 34 कमांड पर्याप्त हैं, तो डीबग API का उपयोग करें। UI के लिए, या ऐसे नोड के लिए जो कभी रजिस्टर नहीं हुआ लेकिन जिसका नेटवर्क पथ अभी भी है, Site Console का उपयोग करें। यदि आपको शेष कमांड सतह की आवश्यकता है और आप VNet तक पहुँच सकते हैं, तो SSH का उपयोग करें। यदि नोड का कोई भी काम करने वाला नेटवर्क पथ नहीं है, तो सीरियल कंसोल ही अंदर जाने का एकमात्र रास्ता है।

पहले साइट की स्थिति जाँचें — और जाँचें कि आप सही टेनेंट से पूछ रहे हैं

एक ही अनुरोध आपको बताता है कि आप किस पथ पर हैं:

curl -sS -H "Authorization: APIToken $XCSH_API_TOKEN" \
  "$XCSH_API_URL/api/config/namespaces/system/sites/<site>" \
  | jq -r '.spec.site_state'

ONLINE का अर्थ है कि डीबग API काम करेगा। कुछ और होने का अर्थ है Site Console या सीरियल कंसोल।

एक साइट जो मौजूद नहीं है, उसके लिए “यह कभी रजिस्टर नहीं हुई” से पहले एक दूसरा स्पष्टीकरण है: आप गलत टेनेंट की ओर संकेत कर रहे हैं। यह डिप्लॉयमेंट f5-sales-demo में रहता है (https://<XC_TENANT>.console.ves.volterra.io), जिसे var.expected_xc_tenant द्वारा पिन किया गया है — cd terraform && terraform output -raw xc_tenant कुछ भी छुए बिना यह बता देता है। किसी अन्य टेनेंट के लिए बनाया गया क्रेडेंशियल एक सादा 401 लौटाता है, जो एक समाप्त हो चुके टोकन जैसा पढ़ा जाता है।

सुरक्षा नियम

ये नीचे दिए गए प्रत्येक पृष्ठ पर प्रत्येक कमांड के लिए लागू होते हैं।

• जब तक आप निश्चित न हों, केवल-पढ़ने योग्य रहें। कमांड सतह दो विशेषाधिकार श्रेणियों में विभाजित है, और Exec श्रेणी या तो नोड को बदलती है या एक स्थिति मार्कर पढ़ती है। इन पृष्ठों पर कुछ भी Exec कमांड नहीं चलाता, और न ही कैप्चर हार्नेस चलाता है।
• कभी यह न मानें कि कोई कमांड अपने नाम से सुरक्षित है। ip-link-set एक क्वेरी जैसा पढ़ा जाता है और एक इंटरफ़ेस को डाउन कर देता है। systemctl-restart-crio एक लाइव डेटा प्लेन के तहत कंटेनर रनटाइम को पुनः आरंभ करता है।
• उस सबसे संकीर्ण कमांड को प्राथमिकता दें जो प्रश्न का उत्तर देता है। health और diagnosis नोड का सारांश सस्ते में देते हैं; flow-l प्रत्येक लाइव फ़्लो को डंप करता है, और flow-l-match उसी प्रश्न का उत्तर एक कनेक्शन के बारे में देता है।
• एक CE लाइव ट्रैफ़िक सेवा देता है। ये साझा डेमो वातावरण हैं। यह मान लें कि कोई उस साइट से प्रस्तुति दे रहा है जिसे आप डीबग कर रहे हैं।

यहाँ क्या दस्तावेज़ीकृत है

इस टेनेंट पर चल रहे सॉफ़्टवेयर बिल्ड पर डीबग API के माध्यम से पहुँचने योग्य प्रत्येक कमांड, प्रत्येक के साथ आउटपुट किसी अन्य स्रोत से प्रतिलिपि किए जाने के बजाय एक लाइव नोड से कैप्चर किया गया।

कमांड संदर्भ उन सभी को उनकी श्रेणी, विशेषाधिकार श्रेणी और ट्रांसपोर्ट के साथ सूचीबद्ध करता है; वर्कफ़्लो उन्हें उन क्रमों में जोड़ते हैं जिन्हें आप वास्तव में कुछ गलत होने पर उपयोग करते हैं।

Site CLI के केवल-ऑन-बॉक्स भाग — configure, configure-network, factory-reset, upgrade और लगभग साठ अन्य ExecCLI कमांड — कवर नहीं किए गए हैं, क्योंकि उनका आउटपुट एक लाइव नोड से उस तरह कैप्चर नहीं किया गया है जैसा नीचे दिए गए प्रत्येक पृष्ठ के लिए किया गया है।

फिर भी, वे अब पहुँच से बाहर नहीं हैं। scripts/sitecli_ssh_harvest.py एप्लायंस के अपने कंप्लीशन मेनू को SSH के माध्यम से चलाता है और प्रत्येक कमांड के लिए एप्लायंस द्वारा दिया गया विवरण रिकॉर्ड करता है, जिससे सतह का अनुमान लगाने के बजाय उसे मापा जा सके। इसका निष्पादन डिफ़ॉल्ट रूप से अस्वीकृत है — यह सब कुछ सूचीबद्ध करता है और केवल एक अनुमति-सूची चलाता है — क्योंकि असत्यापित कमांड सिंटैक्स, और असत्यापित कमांड प्रभाव, वही दोष हैं जिन्हें दोहराने से बचने के लिए यह दस्तावेज़ीकरण मौजूद है।