मिनियो डिबगिंग के लिए प्रो टिप्स: कुबेरनेट्स और बेयर मेटल वातावरण में आम समस्याओं पर काबू पाना

मिनियो परिनियोजन सभी आकारों और आकारों में आते हैं। हम लिनक्स के किसी भी संस्करण पर बेयर मेटल इंस्टालेशन, कुबेरनेट्स के किसी भी संस्करण (रेड हैट ओपनशिफ्ट सहित) पर कंटेनराइज्ड इंस्टालेशन का समर्थन करते हैं, और लगभग हर जगह इंस्टालेशन करते हैं जहाँ आप एक छोटे हल्के सिंगल बाइनरी को तैनात कर सकते हैं। लेकिन लचीलेपन के साथ यह अनिवार्यता भी आती है कि एज केस मुद्दों को डीबगिंग की आवश्यकता होगी।

इस ब्लॉग पोस्ट में, हम आपको बताएंगे कि कुबेरनेट्स में चल रहे मिनियो इंस्टॉलेशन को कैसे डीबग किया जाए और साथ ही कुछ सामान्य समस्याएं जो आपको बेयर मेटल इंस्टॉलेशन करते समय आ सकती हैं और उन्हें कैसे सुधारा जाए।

कुबेरनेट्स डीबगर पॉड

Kubernetes क्लस्टर के अंदर चल रहे MinIO API तक पहुँचने के कुछ तरीके हैं। हम kubectl port-forwarding उपयोग कर सकते हैं या API तक पहुँचने में सक्षम होने के लिए NodePort पर Service सुनने की व्यवस्था कर सकते हैं। ये दोनों विधियाँ नेटवर्क के बाहर से सेवा तक पहुँचने का एक तरीका प्रदान करती हैं, लेकिन इनमें एक बड़ी कमी है: आप केवल उस सेवा तक पहुँच सकते हैं जिसे NodePort या पोर्ट फ़ॉरवर्डिंग किसी उपलब्ध पोर्ट पर संदर्भित करता है (एप्लिकेशन के लिए सामान्य कॉन्फ़िगरेशन नहीं)। उदाहरण के लिए, आपको MinIO API तक पहुँचना होगा, जो आमतौर पर पोर्ट 9000 पर पाया जाता है, एक यादृच्छिक रूप से निर्दिष्ट 3xxxx पोर्ट के माध्यम से।

क्या होगा अगर मैं आपको बताऊं कि एक बेहतर तरीका है - और यह नया नहीं है? जब आप एप्लिकेशन को डीबग कर रहे हों तो आप मूल रन-टाइम वातावरण तक पूरी पहुँच चाहते हैं ताकि आप क्लस्टर को समस्या निवारण और डीबग करने के लिए विभिन्न उपकरणों का उपयोग कर सकें। ऐसा करने का एक तरीका "बिजीबॉक्स" स्टाइल पॉड लॉन्च करना और एप्लिकेशन को डीबग करने के लिए आवश्यक सभी आवश्यक उपकरण इंस्टॉल करना है।

सबसे पहले अपने MinIO इंस्टाल के समान नामस्थान में एक Pod लॉन्च करें। ऐसा करने के लिए debugger-pod.yaml नामक एक yaml फ़ाइल बनाएँ जिसमें निम्न yaml हो।

 apiVersion: v1 kind: Pod metadata: name: mc labels: app: mc spec: containers: - image: minio/mc:latest command: - "sleep" - "604800" imagePullPolicy: IfNotPresent name: mc restartPolicy: Always

उपरोक्त पॉड कॉन्फ़िगरेशन मिनियो mc यूटिलिटी के लिए छवि खींच रहा है। यह सुनिश्चित करने के लिए कि पॉड बस लॉन्च न हो जाए और फिर बाहर न निकल जाए, हमने एक sleep कमांड जोड़ा है।

एक बार yaml सहेजे जाने के बाद कॉन्फ़िगरेशन को Kubernetes नामस्थान पर लागू करें जहाँ MinIO क्लस्टर चल रहा है

kubectl apply -f debugger-pod.yaml

एक बार पॉड चालू हो जाए तो उसे शेल के माध्यम से एक्सेस करें

 $ kubectl exec -i -t -n default mc -c mc -- sh -c "(bash || ash || sh)" [root@mc /]#

फिर mc के साथ आप MinIO क्लस्टर तक पहुँच सकते हैं

 [root@mc /]# mc alias set myminio --insecure Added `myminio` successfully.

अब जब हमारे पास डीबगर पॉड चालू है, तो आप उसी नेटवर्क के भीतर सीधे क्लस्टर पर कार्रवाई कर सकते हैं। उदाहरण के लिए, यदि साइट के ऑफ़लाइन होने या हार्डवेयर विफलता के कारण प्रतिकृति टूट गई थी, तो आप निम्न कमांड का उपयोग करके प्रतिकृति किए जाने वाले किसी भी लंबित ऑब्जेक्ट को फिर से सिंक कर सकते हैं

 [root@mc /]# mc admin replicate resync start minio1 minio2 [root@mc /]# mc admin replicate resync status minio1 minio2 ✔ ✔ ✔ ResyncID: 2248d1d1-633f-4d61-b938-d8ea0b9b2d31 Status: Completed Objects: 2225 Versions: 2225 FailedObjects: 0 Throughput: 5.3 MiB/s IOPs: 124.23 objs/s Transferred: 94 MiB Elapsed: 17.909833202s CurrObjName: testbucket/web-app/tsconfig.json

डिबगर पॉड चलाने का एक और कारण यह है कि यदि आपके पॉड में कुछ फ़ाइल सिस्टम अनुमतियाँ या अमान्य समूह कॉन्फ़िगरेशन हैं, तो आप उन्हें डिबगर पॉड का उपयोग करके अपडेट कर सकते हैं

 [root@mc /]# chgrp -R 1000780050 .minio.sys/

उपरोक्त डिबगिंग विधि का उपयोग बेयर मेटल वातावरण में भी किया जा सकता है। उदाहरण के लिए, आप mc इंस्टॉल करके बिजीबॉक्स या बैस्टियन नोड लॉन्च कर सकते हैं और ऊपर दिए गए निर्देशों का पालन कर सकते हैं।

नंगे धातु का डिबगिंग

बेयर मेटल लिनक्स इंस्टालेशन सबसे सरल है। वास्तव में, सिस्टमडी के साथ मिनियो को इंस्टाल करने और चलाने के लिए बस कुछ कमांड की आवश्यकता होती है। विवरण के लिए, कृपया देखें SystemD के साथ MinIO को कॉन्फ़िगर करना .

कभी-कभी, नंगे धातु के इंस्टॉलेशन में गड़बड़ी हो जाती है। यहाँ कुछ (असामान्य) खामियाँ बताई गई हैं जिनके बारे में हमसे पूछा जाता है सबनेट या ढीला ये खामियां हार्डवेयर या ऑपरेटिंग विशिष्ट नहीं हैं, लेकिन किसी भी तरह के वातावरण में जानना उपयोगी हो सकता है।

फ़ाइल अनुमति

सबसे आम गलतियों में से एक है मिनियो बाइनरी और कॉन्फ़िगरेशन फ़ाइल की फ़ाइल अनुमतियाँ। यदि ऐसा होता है, तो जब आप सिस्टमडी का उपयोग करके मिनियो शुरू करेंगे तो आप देखेंगे

Assertion failed for MinIO. और यहां पूर्ण स्टैक ट्रेस है

 # systemctl status minio.service ● minio.service - MinIO Loaded: loaded (/etc/systemd/system/minio.service; enabled; vendor preset: enabled) Active: inactive (dead) Assert: start assertion failed at Tue 2023-12-26 18:21:38 PST; 8s ago AssertFileIsExecutable=/usr/local/bin/minio was not met Docs: https://docs.min.io Dec 26 18:13:37 minio1 systemd[1]: minio.service: Starting requested but asserts failed. Dec 26 18:17:50 minio1 systemd[1]: Assertion failed for MinIO. Dec 26 18:21:38 minio1 systemd[1]: minio.service: Starting requested but asserts failed. Dec 26 18:21:38 minio1 systemd[1]: Assertion failed for MinIO.

इसके कई कारण हो सकते हैं, आइये सूची पर नजर डालें और प्रत्येक कारण की जांच करें।

मिनियो बाइनरी : इस उदाहरण में /usr/local/bin/minio पर स्थित बाइनरी को क्रमशः उपयोगकर्ता और समूह के लिए root:root अनुमति की आवश्यकता होती है।

 # ll /usr/local/bin/minio total 93804 -rwxr-xr-x 1 root root 96018432 Nov 15 16:35 minio*

मिनियो सर्विस यूजर और ग्रुप : मिनियो सर्विस को सुरक्षा उद्देश्यों के लिए एक अद्वितीय लिनक्स यूजर और ग्रुप के तहत चलाने की आवश्यकता है, इसे कभी भी root यूजर के रूप में नहीं चलाना चाहिए। डिफ़ॉल्ट रूप से हम यूजर और ग्रुप नामों के लिए minio-user उपयोग करते हैं। सिस्टमडी सर्विस कॉन्फ़िगरेशन फ़ाइल में आपको कुछ इस तरह दिखना चाहिए

 User=minio-user Group=minio-user

मिनियो डेटा डायरेक्टरी : वह डायरेक्टरी जहां मिनियो डेटा संग्रहीत किया जाएगा, उसका स्वामित्व minio-user:minio-user या जिस भी उपयोगकर्ता को आप मिनियो सेवा चलाने के लिए चुनते हैं, उसके पास होना चाहिए।

 # ls -l /mnt total 4 drwxrwxr-x 2 minio-user minio-user 4096 Dec 27 09:58 data

सिस्टमडी और मिनियो कॉन्फ़िगरेशन : दोनों कॉन्फ़िगरेशन फ़ाइलों में उपयोगकर्ता और समूह के लिए root:root अनुमतियाँ होनी चाहिए जैसे कि

 # ls -l /etc/default/minio -rw-r--r-- 1 root root 1330 Dec 27 09:52 /etc/default/minio # ls -l /etc/systemd/system/minio.service -rw-r--r-- 1 root root 941 Dec 26 17:13 /etc/systemd/system/minio.service

रूट के रूप में चलाएँ : पूरी इंस्टॉल प्रक्रिया को root के रूप में चलाया जाना चाहिए। यदि आपके उपयोगकर्ता के पास अनुमतियाँ हैं तो आप sudo भी आज़मा सकते हैं, लेकिन अनुशंसा रूट के रूप में चलाने की है क्योंकि इंस्टॉल को कई स्थानों पर फ़ाइलों को रखने की आवश्यकता होती है जहाँ केवल root उपयोगकर्ता ही पहुँच सकता है। आपके बैश प्रॉम्प्ट में # होना चाहिए न कि $ जैसा कुछ

# बनाम $

यदि उपरोक्त में से कोई भी उपाय काम नहीं करता है, तो सबसे अच्छा तरीका यह है कि ऐप, निर्देशिकाएं और कॉन्फ़िगरेशन हटा दिए जाएं और रूट उपयोगकर्ता के रूप में नया इंस्टॉलेशन शुरू किया जाए।

बंदरगाह संघर्ष

डिलीट की गई फ़ाइलों से संबंधित एक और आम समस्या जो अभी भी प्रक्रिया पर टिकी हुई है, जो पोर्ट संघर्ष का कारण बनती है। जब कोई सेवा नहीं चल रही होती है, तब भी आप मौजूदा पोर्ट पर नई सेवा शुरू करने में असमर्थ हो सकते हैं या जो सेवा चल रही है वह गलत व्यवहार करेगी (जैसे कि आपको लॉगिन करने की अनुमति नहीं देना)।

 # lsof -n | grep (deleted) COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME nginx 13423 root 5u REG 253,3 42949672960 17 (deleted) minio 13423 minio 6u REG 253,3 0 18 (deleted) minio 13423 minio 7u REG 253,3 0 19 (deleted)

आपको MinIO इंस्टाल पर नीचे दी गई त्रुटियाँ दिखाई दे सकती हैं

• लॉगिन विफल net::ERR_FAILED
• 500 आंतरिक सर्वर त्रुटि
• अनधिकृत 401

ऊपर दिया गया स्क्रीनशॉट एक आंतरिक सर्वर त्रुटि और एक अनधिकृत त्रुटि दिखाता है। सतह पर देखने पर यह स्पष्ट नहीं लगता कि इस त्रुटि का कारण क्या है, हम थोड़े लिनक्स ज्ञान के साथ डीबग कर सकते हैं कि ऐसा क्या हो सकता है, आइए एक नज़र डालते हैं।

इस समस्या को डीबग करने के कई तरीके हैं, सबसे पहले यह देखें कि क्या एक ही नोड पर कई MinIO प्रक्रियाएँ चल रही हैं

 # ps aux | grep -i minio minio-u+ 5048 0.3 1.7 1594008 144384 ? Ssl 11:03 0:01 /usr/local/bin/minio server --console-address :9001 /mnt/data/disk1/minio minio-u+ 9276 0.3 1.7 1594208 144301 ? Ssl 11:25 0:01 /usr/local/bin/minio server --console-address :9001 /mnt/data/disk1/minio

जैसा कि हम ऊपर देख सकते हैं कि 2 MinIO प्रक्रियाएँ चल रही हैं। सबसे पहले उस प्रक्रिया को समाप्त करें जो पुरानी है या सबसे लंबे समय से चल रही है, इस मामले में यह प्रक्रिया आईडी 5048 है।

kill -9 5048

कभी-कभी प्रक्रिया को समाप्त करने के बाद भी सेवा शुरू नहीं हो सकती है या फिर रुकी रह सकती है क्योंकि इसने प्रक्रिया संख्या आरक्षित कर रखी है लेकिन उसे जाने नहीं दिया है। ऐसा उन फ़ाइलों के कारण हो सकता है जिन्हें हटा दिया गया है लेकिन ऑपरेटिंग सिस्टम द्वारा अभी भी ट्रैक किया जा रहा है। आप LSOF के माध्यम से हटाई गई फ़ाइलों को पा सकते हैं

lsof -n | grep '(deleted)'

अंतिम लेकिन कम महत्वपूर्ण बात यह है कि यदि कोई डिलीट की गई फ़ाइल या हैंग प्रोसेस नहीं बची है और यदि सब कुछ बिल्कुल साफ दिखता है, तो अंतिम उपाय नोड को जल्दी से पुनः आरंभ करना है। यह एक आसान तरीका है जो किसी भी लंबित फ़ाइल और प्रोसेस को बंद कर देता है और साफ़ कर देता है ताकि आप एक नया इंस्टॉलेशन शुरू कर सकें।

बचाव के लिए सबनेट

हालांकि दुर्लभ, इंस्टॉलेशन एज केस हमेशा मौजूद रहेंगे। मिनियो ग्राहक जानते हैं कि उन्हें चिंता करने की कोई बात नहीं है क्योंकि वे हमारे इंजीनियरों को - जिन्होंने कोड लिखा है - संदेश भेज सकते हैं सबनेट पोर्टल। हमने दुनिया भर में लगभग सब कुछ देखा है, इसलिए जब पहली नज़र में समस्या रहस्यमय या दिमाग को चकरा देने वाली लग सकती है, हम कई अलग-अलग वातावरणों में इंस्टॉलेशन को डिबग करने में अपनी वर्षों की विशेषज्ञता का उपयोग करेंगे और आपको तुरंत मदद करेंगे।