Azure Fundamentals · पाठ

स्वास्थ्य जाँच और सुचारु अवनयन

पाठ 4, कुल 4 में से13 चरण

स्वास्थ्य जाँच और सुचारु अवनयन, CoddyKit पर Azure Fundamentals का एक निःशुल्क पाठ है। यह 4 में से 4वाँ पाठ है। आप नीचे पूरा पाठ निःशुल्क पढ़ सकते हैं—फिर अंतर्निहित कोड संपादक और 24/7 एआई ट्यूटर के साथ ब्राउज़र में इसका व्यावहारिक अभ्यास कर सकते हैं। यह Azure Fundamentals सीखने के मार्ग का हिस्सा है और आपकी प्रगति वेब तथा CoddyKit ऐप पर सिंक होती रहती है। Azure Fundamentals पाठ्यक्रम में कुल 4 पाठ शामिल हैं।

स्वास्थ्य जाँचें क्यों आवश्यक हैं

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

Azure Load Balancer की स्वास्थ्य जाँचें

Azure Load Balancer दो प्रकार की स्वास्थ्य जाँचों का समर्थन करता है:

TCP जाँच — जाँचती है कि बैकएंड किसी निर्दिष्ट पोर्ट पर TCP कनेक्शन स्वीकार कर सकता है या नहीं। सरल है, लेकिन अनुप्रयोग के तर्क की पुष्टि नहीं करती।
HTTP/HTTPS जाँच — निर्दिष्ट पथ पर GET अनुरोध भेजती है और 200 OK प्रतिक्रिया की अपेक्षा करती है। यह अधिक सटीक है, क्योंकि यह सीधे अनुप्रयोग एंडपॉइंट का परीक्षण करती है।

यदि जाँच लगातार निर्धारित संख्या में प्रयासों में विफल हो, तो बैकएंड को अस्वस्थ चिह्नित किया जाता है।

# Create an HTTP health probe for an Azure Load Balancer:
az network lb probe create \
  --resource-group myRG \
  --lb-name myLoadBalancer \
  --name httpHealthProbe \
  --protocol Http \
  --port 80 \
  --path /health \
  --interval 15 \
  --threshold 2

विश्वसनीय स्वास्थ्य एंडपॉइंट तैयार करना

अच्छी तरह तैयार किया गया स्वास्थ्य एंडपॉइंट (/health) केवल 200 OK लौटाने से अधिक काम करता है — यह सत्यापित करता है कि अनुप्रयोग की महत्वपूर्ण निर्भरताएँ पहुँच योग्य हैं। व्यापक स्वास्थ्य जाँच में डेटाबेस, कैश और किसी भी डाउनस्ट्रीम API से कनेक्टिविटी का परीक्षण किया जा सकता है। यदि कोई निर्भरता उपलब्ध नहीं है, तो एंडपॉइंट 5xx स्थिति कोड लौटाता है, जिससे लोड बैलेंसर को यह संकेत मिलता है कि इस इंस्टेंस को रोटेशन से हटा दिया जाए।

# Example health endpoint response (JSON):
# GET /health
# {
#   'status': 'healthy',
#   'checks': {
#     'database': 'ok',
#     'cache': 'ok',
#     'externalApi': 'ok'
#   }
# }
# If database check fails, return HTTP 503 instead of 200

Traffic Manager की स्वास्थ्य जाँचें

Azure Traffic Manager भी स्वास्थ्य जाँचों का उपयोग करता है, लेकिन क्षेत्रीय स्तर पर। यह प्रत्येक क्षेत्र में कॉन्फ़िगर किए गए एंडपॉइंट URL पर समय-समय पर HTTP या HTTPS GET अनुरोध भेजता है। यदि कोई एंडपॉइंट लगातार निर्धारित संख्या में अंतरालों के दौरान समय-सीमा के भीतर प्रतिक्रिया देने में विफल रहता है, तो Traffic Manager उस एंडपॉइंट को खराब स्थिति वाला चिह्नित कर देता है और उसे DNS क्वेरी रूट करना बंद कर देता है, जिससे उपयोगकर्ताओं को स्वस्थ क्षेत्र में भेजा जाता है।

# Configure Traffic Manager health probe settings:
az network traffic-manager profile update \
  --resource-group myRG \
  --name myTMProfile \
  --monitor-protocol HTTPS \
  --monitor-port 443 \
  --monitor-path /health \
  --monitor-interval 30 \
  --monitor-timeout 10 \
  --monitor-tolerated-failures 3

Application Gateway की स्वास्थ्य जाँचें

Azure Application Gateway में मानक Load Balancer की तुलना में अधिक उन्नत स्वास्थ्य जाँच क्षमताएँ हैं। यह कस्टम जाँचों का समर्थन करता है, जिनमें होस्ट हेडर, अपेक्षित स्थिति कोड सीमा (जैसे, 200-399) और मुख्य भाग से मिलान करने वाली स्ट्रिंग निर्दिष्ट की जाती है। Application Gateway प्रति-पथ रूटिंग का भी समर्थन करता है, इसलिए अलग-अलग बैकएंड पूल में अलग-अलग URL पथों के लिए स्वास्थ्य जाँच के अलग कॉन्फ़िगरेशन हो सकते हैं।

# Create a custom probe for Application Gateway:
az network application-gateway probe create \
  --gateway-name myAppGateway \
  --resource-group myRG \
  --name customProbe \
  --protocol Http \
  --host-name-from-http-settings true \
  --path /api/health \
  --interval 20 \
  --timeout 10 \
  --threshold 3

सुचारु रूप से सीमित कार्यक्षमता क्या है

सुचारु रूप से सीमित कार्यक्षमता का अर्थ है कि एक या अधिक निर्भरताएँ विफल होने पर भी अनुप्रयोग आंशिक कार्यक्षमता प्रदान करता रहे। पूरी तरह क्रैश होने के बजाय, अनुप्रयोग किसी गैर-महत्वपूर्ण सेवा की अनुपलब्धता का पता लगाता है और कम सुविधाओं वाली, लेकिन फिर भी उपयोगी स्थिति में चला जाता है। उदाहरण के लिए, यदि अनुशंसा सेवा विफल हो जाए, तो ई-कॉमर्स साइट पूरे उत्पाद पृष्ठ को क्रैश करने के बजाय सामान्य सुझाव दिखा सकती है।

सर्किट ब्रेकर पैटर्न

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

# Circuit breaker states:
# CLOSED: normal operation, calls pass through
# OPEN:   service failing, calls immediately return error/fallback
# HALF-OPEN: cool-down expired, try one request:
#           success -> CLOSED
#           failure -> OPEN (reset timer)

# Libraries: Polly (.NET), Resilience4j (Java), polly-js (JS)

घातांकीय बैकऑफ़ के साथ पुनः प्रयास

क्षणिक विफलताओं (नेटवर्क में थोड़े समय के लिए आने वाली रुकावटों या सेवा पर अस्थायी अधिक भार) के लिए घातांकीय बैकऑफ़ के साथ पुनः प्रयास की रणनीति उपयुक्त होती है। एप्लिकेशन विफल कॉल को कुछ विलंब के बाद फिर से करता है और अधिकतम सीमा तक, प्रत्येक पुनः प्रयास के साथ उस विलंब को दोगुना करता है। विलंब में jitter (यादृच्छिक परिवर्तन) जोड़ने से सभी पुनः प्रयास एक ही समय पर नहीं होते और ठीक हो रही सेवा पर अत्यधिक भार नहीं पड़ता।

# Exponential backoff with jitter (pseudocode):
# attempt 1: wait 1s  + random(0-500ms)
# attempt 2: wait 2s  + random(0-500ms)
# attempt 3: wait 4s  + random(0-500ms)
# attempt 4: wait 8s  + random(0-500ms)
# max retries: 4
# max wait: 30s (cap)
# After max retries: return error to caller

बल्कहेड पैटर्न

बल्कहेड पैटर्न एप्लिकेशन के अलग-अलग हिस्सों को अलग-अलग संसाधन पूलों में विभाजित करता है, ताकि किसी एक हिस्से की विफलता सभी संसाधनों का उपयोग करके पूरे सिस्टम को बंद न कर दे। इसका नाम जहाज़ के उन बल्कहेड से लिया गया है जो किसी एक जलमग्न कक्ष को पूरे जहाज़ को डुबाने से रोकते हैं। Azure में इसका अर्थ अलग-अलग सेवाओं के लिए अलग-अलग थ्रेड पूल या अलग-अलग App Service plans का उपयोग करके विफलताओं को सीमित करना हो सकता है।

फ़ॉलबैक प्रतिक्रियाएँ और कैश किया गया डेटा

सुव्यवस्थित रूप से क्षमता घटने की स्थिति संभालने की एक सामान्य तकनीक यह है कि लाइव डेटा स्रोत उपलब्ध न होने पर कैश किया हुआ या पुराना डेटा प्रस्तुत किया जाए। उदाहरण के लिए, यदि डेटाबेस अस्थायी रूप से पहुँच से बाहर हो, तो उत्पाद कैटलॉग पृष्ठ त्रुटि दिखाने के बजाय Azure Cache for Redis से कल की कैश की गई कीमतें दिखा सकता है। उपयोगकर्ताओं को पूरी तरह विफलता के बजाय थोड़ी असुविधा (कुछ पुरानी कीमतें) का अनुभव होता है।

क्षमता घटने की निगरानी और चेतावनी

सुव्यवस्थित रूप से क्षमता घटने की स्थिति दृश्य और मापनीय होनी चाहिए। सर्किट ब्रेकर के खुलने, फ़ॉलबैक प्रतिक्रियाओं और पुनः प्रयासों की दर को कस्टम मेट्रिक के रूप में ट्रैक करने के लिए Application Insights का उपयोग करें। जब ये मेट्रिक निर्धारित सीमाओं से अधिक हो जाएँ, तब चेतावनियाँ स्थापित करें, ताकि ऑन-कॉल टीम को पता चल सके कि एप्लिकेशन घटे हुए स्तर पर चल रहा है, भले ही उपयोगकर्ता को दिखाई देने वाला अनुभव स्वीकार्य लगे।

त्वरित जाँच

इस पाठ से Microsoft Azure Fundamentals (AZ-900) की अवधारणाओं के बारे में अपनी समझ जाँचें।

इंटरैक्टिव पाठ में इसका उत्तर दें

पाठ का पुनरावलोकन

इस पाठ में आपने सीखा: स्वास्थ्य जाँच लोड बैलेंसर को विफल बैकएंड का पता लगाकर ट्रैफ़िक को स्वचालित रूप से दूसरे मार्ग पर भेजने देती हैं; सुव्यवस्थित रूप से क्षमता घटाना निर्भरताएँ विफल होने पर भी एप्लिकेशन को आंशिक रूप से कार्यशील बनाए रखता है; और सर्किट ब्रेकर, बैकऑफ़ के साथ पुनः प्रयास तथा बल्कहेड जैसे पैटर्न एप्लिकेशन स्तर पर लचीलापन लागू करते हैं। आगे हम आपदा पुनर्प्राप्ति की अवधारणाओं का अध्ययन करेंगे — RTO, RPO और पुनर्प्राप्ति स्तरों को परिभाषित करेंगे।

शुरुआत निःशुल्क

एआई शिक्षक के साथ Azure Fundamentals सीखें — निःशुल्क

अपने ब्राउज़र में वास्तविक कोड लिखें और चलाएँ, चौबीसों घंटे एआई शिक्षक से तुरंत सहायता पाएँ, और वेब या ऐप पर वहीं से शुरू करें जहाँ आपने छोड़ा था।

पाठ्यक्रम: 30
पाठ: 120

निःशुल्क सीखना शुरू करें पूरा पाठ्यक्रम देखें

अक्सर पूछे जाने वाले प्रश्न

क्या “स्वास्थ्य जाँच और सुचारु अवनयन” पाठ निःशुल्क है?

हाँ—“स्वास्थ्य जाँच और सुचारु अवनयन” का पूरा पाठ यहाँ वेब पर निःशुल्क पढ़ा जा सकता है। इंटरैक्टिव अभ्यास (अंतर्निहित कोड संपादक और 24/7 एआई ट्यूटर) करने और Azure Fundamentals पाठ्यक्रम का बाकी हिस्सा अनलॉक करने के लिए CoddyKit PRO लें। Azure Fundamentals पाठ्यक्रम में कुल 4 पाठ शामिल हैं।

“स्वास्थ्य जाँच और सुचारु अवनयन” में मैं क्या सीखूँगा?

विफलताओं का शीघ्र पता लगाने के लिए लोड बैलेंसर और Traffic Manager की स्वास्थ्य जाँच कॉन्फ़िगर करें तथा अपने अनुप्रयोग स्तर के लिए सर्किट-ब्रेकर और सुचारु अवनयन पैटर्न डिज़ाइन करें। आप ब्राउज़र में सीधे चलाए जाने वाले व्यावहारिक कोड के साथ Azure Fundamentals का अभ्यास करते हैं, और पाठ पूरा करते समय 24/7 एआई ट्यूटर आपके प्रश्नों के उत्तर देता है।

क्या Azure Fundamentals शुरू करने के लिए मुझे किसी अनुभव की आवश्यकता है?

पहले के अनुभव की आवश्यकता नहीं है। CoddyKit पर Azure Fundamentals शुरुआती से लेकर उन्नत शिक्षार्थियों तक सभी के लिए व्यवस्थित किया गया है, इसलिए आप यहीं से या शुरुआत से सीखना शुरू कर सकते हैं और अपनी गति से आगे बढ़ सकते हैं। यह 4 में से 4वाँ पाठ है।

“स्वास्थ्य जाँच और सुचारु अवनयन” पाठ पूरा करने में कितना समय लगता है?

CoddyKit का अधिकांश पाठ लगभग 5–10 मिनट में पूरा हो जाता है। हर पाठ छोटा और संवादात्मक है, इसलिए आप लगातार प्रगति करते हैं और वेब या ऐप पर वहीं से सीखना जारी रख सकते हैं जहाँ आपने छोड़ा था।

क्या मैं इस Azure Fundamentals पाठ में कोड लिख और चला सकता हूँ?

हाँ। हर Azure Fundamentals पाठ में एक अंतर्निर्मित कोड संपादक शामिल है, जिससे आप सीधे अपने ब्राउज़र में वास्तविक कोड लिख और चला सकते हैं और तुरंत एआई प्रतिक्रिया पा सकते हैं—स्थानीय सेटअप की आवश्यकता नहीं है।

इस पाठ्यक्रम के सभी पाठ

← Azure Fundamentals पर वापस जाएँ