सही EFS थ्रूपुट मोड वह नहीं है जिसकी सबसे बड़ी क्षमता लिखी हो। सही वह है जिसका क्षमता मॉडल वर्कलोड के पैटर्न से मेल खाए, और जिसकी लागत व संभावित खराबियों को टीम आत्मविश्वास से सँभाल सके।
Amazon EFS में फिलहाल Elastic, Provisioned और Bursting थ्रूपुट मिलते हैं। तीनों अलग समस्याएँ हल करते हैं।
Bursting: क्षमता रखे गए डेटा के साथ बढ़ती है
Bursting तब स्वाभाविक चुनाव है जब Standard स्टोरेज में डेटा बढ़ने के साथ थ्रूपुट की ज़रूरत बढ़े और व्यस्त समय के बाद क्रेडिट फिर भरने लायक शांत समय मिले। यह किफायती और सरल हो सकता है, लेकिन छोटे फ़ाइल सिस्टम की टिकाऊ बेसलाइन उम्मीद से बहुत कम हो सकती है।
इसे तब चुनें जब स्टोरेज का आकार और थ्रूपुट की माँग सचमुच साथ बढ़ें। जमा क्रेडिट को स्थायी क्षमता न मानें। लगातार गिरता BurstCreditBalance साबित करता है कि वर्कलोड संतुलन में नहीं है।
Elastic: क्षमता गतिविधि के साथ बदलती है
Elastic Throughput वर्कलोड की गतिविधि के साथ अपने आप स्केल होता है और बर्स्ट क्रेडिट इस्तेमाल नहीं करता। AWS इसे अचानक बढ़ने वाले या अनिश्चित वर्कलोड के लिए सुझाता है, खासकर जब औसत थ्रूपुट पीक का छोटा हिस्सा हो। इससे क्रेडिट खत्म होने वाली खराबी हटती है और क्षमता की योजना बनाने का काम घटता है।
इसमें समझौता आर्किटेक्चर के बजाय लागत का है: Elastic Throughput का शुल्क उपयोग पर आधारित है, इसलिए ऊँचा या ठीक से नियंत्रित न किया गया I/O खर्च बढ़ा सकता है। मॉनिटर करें MeteredIOBytes, बजट तय करें और अचानक बढ़ी माँग की जाँच करें। यह न मानें कि अपने आप स्केल होने से निगरानी और नियंत्रण की ज़रूरत खत्म हो गई।
Provisioned: क्षमता स्पष्ट ज़रूरत के हिसाब से तय होती है
Provisioned Throughput थ्रूपुट को फ़ाइल सिस्टम के आकार से अलग करता है और चुने गए स्तर की क्षमता देता है। यह ज्ञात, लगातार माँग या ऊँचे औसत-से-पीक अनुपात वाले वर्कलोड के लिए ठीक है। फायदा है अनुमान लगाने योग्य क्षमता; ज़िम्मेदारी है उसका सही आकार चुनना और समय-समय पर समीक्षा करना।
कम क्षमता तय करने से फिर वही बाधा आती है। ज़्यादा तय करने से पैसा बर्बाद होता है। यह मोड तब सबसे अच्छा है जब माप इतने स्थिर हों कि स्पष्ट क्षमता के लिए प्रतिबद्ध हुआ जा सके।
चुनने का व्यावहारिक ढाँचा
- Bursting इस्तेमाल करें जब स्टोरेज का आकार थ्रूपुट की माँग का अच्छा संकेत हो, शांत समय में क्रेडिट भर सकें और क्रेडिट की मॉनिटरिंग सामान्य संचालन का हिस्सा हो।
- Elastic इस्तेमाल करें जब माँग अनियमित हो, पीक का अनुमान मुश्किल हो या क्रेडिट खत्म होने से बचने के लिए उपयोग-आधारित कीमत उचित लगे।
- Provisioned इस्तेमाल करें जब थ्रूपुट की माँग ज्ञात हो, अपेक्षाकृत लगातार हो और रखे गए डेटा के आकार से स्वतंत्र हो।
मोड बदलना माप के आधार पर होना चाहिए
मोड बदलने से पहले बेसलाइन मेट्रिक, अपेक्षित पीक और औसत माँग, क्रेडिट का वर्तमान रुझान और ऐप की लेटेंसी दर्ज करें। बदलाव के बाद वही संकेत और लागत मिलाकर देखें। AWS ने Provisioned Throughput पर स्विच करने या उसे बदलने के बाद कुछ अस्थायी पाबंदियाँ भी बताई हैं, इसलिए रनबुक में लागू समय-सीमाएँ शामिल होनी चाहिए।
एक वाक्य में फैसला
अगर रखे गए डेटा से माँग का अनुमान मिलता है तो Bursting ठीक हो सकता है। गतिविधि अनिश्चित हो तो संचालन के लिहाज़ से Elastic आम तौर पर सुरक्षित है। ज़रूरत स्थिर और मापने योग्य हो तो Provisioned से सोच-समझकर क्षमता तय की जा सकती है। जो भी चुनें, उसकी सीमित करने वाली क्षमता को स्पष्ट दिखाएँ।


क्लाउड / सिस्टम