# Node.js ऐप को स्केल और ऑटो-स्केल करना

Source: https://support.kapsulehost.com/hi-in/site-scaling-and-autoscale

ऑटो-स्केलिंग आपके Node.js ऐप को चलाने वाले instances की संख्या को CPU लोड बदलने पर बढ़ाती और घटाती है, ताकि व्यस्त अवधि में अधिक क्षमता मिले और शांत अवधि में कम लागत आए। यह गाइड KPanel टैब, हर सेटिंग, क्या बिल किया जाता है, और किसी ऐप को स्केल करने के लिए सुरक्षित कैसे बनाया जाए, इसे कवर करती है।

## KPanel में स्केलिंग कहाँ है

1. [KPanel](https://kpanel.kapsulehost.com) में साइन इन करें।
2. बाएँ साइडबार में **वेबसाइटें** पर क्लिक करें, फिर साइट पर क्लिक करें।
3. साइट के बाएँ मेनू में, **प्रदर्शन** खोलें, फिर **स्केलिंग**।

सीधा पता `/websites/<site-id>/autoscale` है। पुराना `/websites/<site-id>/scaling` पता अब भी काम करता है और आपको उसी जगह भेज देता है।

![KPanel में Node.js ऐप के लिए ऑटो-स्केलिंग सेटिंग्स](https://support.kapsulehost.com/help/screenshots/site-scaling-and-autoscale.a7af79de.webp)

> **Note:** यह टैब केवल Node.js साइटों पर दिखाई देता है। यह WordPress, WooCommerce, स्टैटिक, PHP, Python, या Ruby साइट के मेनू में नहीं होगा, क्योंकि यह तंत्र एक Node.js प्रोसेस क्लस्टर को स्केल करता है।

## एक टैब, एक कॉन्फ़िगरेशन

KPanel में पहले यहाँ दो टैब होते थे, **स्केलिंग** और **ऑटोस्केल**, जो एक ही सेटिंग्स समूह पर काम करते थे। वे एक ही कॉन्फ़िगरेशन के दो दृश्य थे, जो केवल भ्रम पैदा करने का एक तरीका था, इसलिए अब ये एक ही **स्केलिंग** टैब हैं: लाइव स्थिति, सेटिंग्स, हाल के scale इवेंट, और मौजूदा बिलिंग अवधि के लिए उपयोग और लागत पैनल, सब एक ही जगह।

## यह कैसे काम करता है

आपका ऐप एक प्रोसेस क्लस्टर के रूप में चलता है। ऑटो-स्केलिंग चल रहे instances में औसत CPU पर नज़र रखती है और आपके द्वारा निर्धारित सीमाओं के अनुसार instances जोड़ती या हटाती है।

क्लस्टर मोड आवश्यक है। यदि आपका ऐप पहले से क्लस्टर मोड में नहीं चल रहा है, तो ऑटो-स्केलिंग सक्षम करने पर यह आपके लिए स्वतः बदल जाता है, जिसमें एक संक्षिप्त रीस्टार्ट शामिल होता है। ऐसा होने पर पेज आपको बता देता है।

## लाइव स्थिति पढ़ना

स्टेटस कार्ड तीन चीज़ें दिखाता है:

- **Instances**: अभी कितने चल रहे हैं।
- **औसत CPU**: उन instances में औसत CPU।
- **Cluster**: क्या ऐप क्लस्टर मोड में है। यदि यह "नहीं" कहता है, तो ऑटो-स्केलिंग सक्षम करने पर यह बदल जाएगा।

यदि ऐप बिल्कुल नहीं चल रहा है, तो कार्ड शून्य दिखाने के बजाय यही बताता है।

टैब **अंतिम scale** भी दिखाता है, सबसे हाल के scale इवेंट का समय, या **never**।

## सेटिंग्स

| सेटिंग | सीमा | यह क्या करता है |
|---|---|---|
| न्यूनतम instances | 1 से 16 | निचली सीमा। इससे नीचे कभी स्केल नहीं होता |
| अधिकतम instances | 1 से 16 | ऊपरी सीमा। इससे ऊपर कभी स्केल नहीं होता |
| CPU % पर बढ़ाएँ | 5 से 99 | इससे ऊपर औसत CPU एक instance जोड़ता है |
| CPU % पर घटाएँ | 1 से 95 | इससे नीचे औसत CPU एक instance हटाता है |
| कूलडाउन (सेक) | 30 से 3600 | scale क्रियाओं के बीच न्यूनतम प्रतीक्षा |

मुख्य स्विच सेटिंग्स कार्ड हेडर में टॉगल है। जब ऑटो-स्केलिंग बंद होती है, तो सेटिंग्स धुंधली हो जाती हैं और आपका ऐप अपनी मौजूदा instance संख्या पर बना रहता है।

शुरुआती मान जो समझदारी भरे हैं:

- **न्यूनतम instances 1 या 2।** दो तब चुनें जब आप किसी एक instance के रीस्टार्ट के कारण ऐप के ऑफलाइन होने को सहन नहीं कर सकते।
- **अधिकतम instances** उतने सेट करें जितने के लिए आप पीक समय पर भुगतान करने को तैयार हैं, न कि ऊपरी सीमा तक।
- **लगभग 70 प्रतिशत पर स्केल अप करें।** इतना ऊँचा कि आप कभी इस्तेमाल न होने वाली क्षमता के लिए भुगतान न करें, इतना कम कि अनुरोध कतार में लगने से पहले क्षमता जोड़ने का समय मिल जाए।
- **लगभग 30 प्रतिशत पर स्केल डाउन करें।** दोनों सीमाओं के बीच बड़ा अंतर रखें।
- **कुछ मिनटों का कूलडाउन।** यह सबसे कम आँकी गई सेटिंग है।

> **Warning:** दोनों CPU सीमाओं को एक-दूसरे के करीब सेट करने से उतार-चढ़ाव (flapping) होता है: क्लस्टर स्केल अप होता है, तुरंत स्केल-डाउन सीमा से नीचे गिर जाता है क्योंकि अब लोड अधिक instances में फैला है, स्केल डाउन होता है, फिर से बढ़ता है, और यह सिलसिला दोहराता रहता है। बड़ा अंतर बनाए रखें, और उदार कूलडाउन का उपयोग करें। उतार-चढ़ाव से पैसा खर्च होता है और ऐप अस्थिर होता है।

## Scale इवेंट

यह टैब हाल के scale इवेंट सूचीबद्ध करता है, सबसे नए पहले, प्रत्येक में दिशा, पहले और बाद की instance संख्या, जिस CPU रीडिंग ने इसे ट्रिगर किया, और समय दिखाया जाता है।

यही वह लॉग है जिसे पढ़ना चाहिए जब ऐप में गड़बड़ी हुई हो। कुछ मिनटों में ऊपर-नीचे इवेंट की झड़ी का मतलब है कि आपकी सीमाएँ बहुत करीब हैं या कूलडाउन बहुत छोटा है। एक अकेला स्केल-अप जो फिर कभी नीचे नहीं आया, इसका मतलब है कि लोड ऊँचा बना रहा, जो एक कॉन्फ़िगरेशन का नहीं बल्कि क्षमता का सवाल है। जब आपको इवेंट की उम्मीद थी पर कोई इवेंट नहीं हुआ, इसका मतलब है कि या तो CPU कभी सीमा से ऊपर नहीं गया या ऑटो-स्केलिंग बंद है।

## ऑटो-स्केलिंग की लागत क्या है

आपके प्लान के आधार आवंटन से ऊपर के instances मीटर किए जाते हैं और प्रति सेकंड बिल किए जाते हैं। मौजूदा अवधि के लिए टैब यह दिखाता है:

- **Instance-time उपयोग किया गया**, घंटों और मिनटों में, नीचे कच्चे instance-सेकंड के साथ।
- **अब तक खर्च हुआ** इस अवधि में।
- **अनुमानित महीने का अंत**, अब तक के उपयोग से अनुमानित।
- **ट्रैकिंग**, कुल दर्ज किए गए में से कितनी उपयोग खिड़कियाँ बिल की जा चुकी हैं।
- **अवधि प्रगति**, महीने के कुल दिनों में से बीते दिन।

प्रति-सेकंड दर उसी पैनल के शीर्ष पर दिखाई जाती है, ताकि जिस आँकड़े पर आपको बिल किया जाता है वह हमेशा उस उपयोग के बगल में दिखे जिस पर वह लागू होता है।

> **Tip:** अनुमान वह आँकड़ा है जिस पर नज़र रखनी चाहिए। यह अब तक के उपयोग से अनुमान लगाता है, इसलिए महीने की शुरुआत में असामान्य रूप से व्यस्त एक सप्ताह इसे बढ़ा-चढ़ाकर दिखा सकता है। इसे कुछ दिन बाद जाँचें, फिर महीने के बीच में फिर से, निष्कर्ष निकालने से पहले। यदि यह आपकी अपेक्षा से अधिक है, तो स्केल-अप सीमा बढ़ाने के बजाय अधिकतम instance संख्या घटाएँ: ऊपरी सीमा एक कठोर सीमा है, एक सीमा केवल एक संकेत है।

न्यूनतम तक स्केल डाउन करने से मीटरिंग रुक जाती है। यदि आप ऑटो-स्केलिंग को पूरी तरह बंद कर देते हैं, तो ऐप अपनी मौजूदा instance संख्या पर बना रहता है, इसलिए यदि लागत ही वह कारण है जिसके लिए आप इसे बंद कर रहे हैं, तो पहले इसे न्यूनतम पर वापस ले आएँ।

## किसी ऐप को स्केल के लिए सुरक्षित बनाना

पेज पर एक चेतावनी है, और यह उस पर सबसे महत्वपूर्ण बात है: आपके Node.js ऐप को instances में साफ-सुथरे ढंग से स्केल करने के लिए क्लस्टर-सुरक्षित होना चाहिए।

व्यवहारिक रूप से इसका मतलब है:

**कोई इन-मेमोरी सेशन स्थिति नहीं।** यदि किसी साइन-इन उपयोगकर्ता का सेशन एक instance की मेमोरी में रहता है, तो जब भी कोई अनुरोध किसी अलग instance पर पहुँचता है, वे साइन आउट हो जाते हैं। सेशन को एक साझा स्टोर में ले जाएँ।

**कोई इन-मेमोरी कैश नहीं जिस पर आप सटीकता के लिए निर्भर हों।** प्रत्येक instance की अपनी कैश होती है। जिस कैश में सुसंगतता अनिवार्य हो, उसे साझा किया जाना चाहिए।

**कोई लोकल फाइलसिस्टम राइट नहीं जिसे आप वापस पढ़ने की उम्मीद करते हों।** एक instance द्वारा लोकल डिस्क पर लिखी गई अपलोड फ़ाइलें अन्य instances को दिखाई नहीं देतीं। साझा स्टोरेज में लिखें।

**कोई अनियंत्रित शेड्यूल्ड कार्य नहीं।** यदि ऐप के भीतर कोई टाइमर चलता है, तो हर instance उसे चलाता है, इसलिए चार instances पर एक रात्रिकालीन कार्य चार बार चलता है। शेड्यूल्ड कार्य को cron जॉब में ले जाएँ, या इसे लॉक से सुरक्षित करें। देखें [Cron Jobs](https://support.kapsulehost.com/hi-in/cron-jobs)।

**यह मान लेना नहीं कि instance संख्या स्थिर है।** कोई भी चीज़ जो instance इंडेक्स के अनुसार कार्य विभाजित करती है, वह संख्या बदलते ही टूट जाती है।

यदि इनमें से कोई भी बात आपके ऐप पर लागू होती है, तो ऑटो-स्केलिंग सक्षम करने से पहले उन्हें ठीक करें। एक ऐप जो क्लस्टर-सुरक्षित नहीं है, ऐसे तरीकों से विफल होता है जो रुक-रुक कर आते हैं और जिन्हें दोहराना कठिन है, क्योंकि वे इस पर निर्भर करते हैं कि किस instance ने किस अनुरोध को सेवा दी।

## समस्या निवारण

**टॉगल सक्षम नहीं होता।** सक्षम करने के लिए साइट write अनुमति चाहिए। केवल-पढ़ने (read-only) भूमिका के साथ नियंत्रण अक्षम रहते हैं।

**ऑटो-स्केलिंग सक्षम करने पर ऐप रीस्टार्ट हो गया।** यह अपेक्षित है। क्लस्टर मोड में बदलने के लिए रीस्टार्ट आवश्यक है, और यह एक बार होता है।

**उपयोगकर्ता बेतरतीब ढंग से साइन आउट हो रहे हैं।** यह क्लासिक गैर-क्लस्टर-सुरक्षित लक्षण है। सेशन मेमोरी में हैं और अनुरोध अलग-अलग instances पर पहुँच रहे हैं।

**Instances स्केल अप हुए और कभी नीचे नहीं आए।** या तो लोड स्केल-डाउन सीमा से ऊपर बना रहा, या कुछ ऐसा है जो ट्रैफिक से स्वतंत्र रूप से CPU को ऊँचा बनाए रख रहा है। इवेंट सूची जाँचें और देखें कि ऐप वास्तव में क्या कर रहा है।

**एक शेड्यूल्ड कार्य कई बार चला।** हर instance ने इसे चलाया। इसे cron जॉब में ले जाएँ या लॉक जोड़ें।

**कुछ भी स्केल नहीं होता।** पुष्टि करें कि टॉगल चालू है, ऐप चल रहा है, और क्लस्टर मोड सक्षम है। फिर जाँचें कि क्या CPU वास्तव में आपकी स्केल-अप सीमा से ऊपर गया था, इवेंट सूची में।

**लागत अपेक्षा से अधिक है।** उतार-चढ़ाव के लिए इवेंट सूची देखें, फिर अपनी अधिकतम instance संख्या घटाएँ।

## संबंधित पेज

- [साइट परफॉर्मेंस और APM](https://support.kapsulehost.com/hi-in/site-performance) यह देखने के लिए कि क्या CPU वास्तव में अवरोधक है।
- [साइट अपटाइम मॉनिटरिंग](https://support.kapsulehost.com/hi-in/site-uptime-monitoring) यह पुष्टि करने के लिए कि स्केलिंग वास्तव में उपलब्धता सुधार रही है।
- [Cron Jobs](https://support.kapsulehost.com/hi-in/cron-jobs) उन शेड्यूल्ड कार्यों के लिए जिन्हें बिल्कुल एक बार चलना चाहिए।
- [क्लाउड सर्वर का आकार बदलना](https://support.kapsulehost.com/hi-in/cloud-servers-resize) यदि आपको अधिक instances के बजाय एक बड़ी मशीन चाहिए।