अराजकता इंजीनियरिंग, भाग 3: तरीके और उपकरण

हम वही देखते हैं जो हम देखते हैं। पहले हम टूल्स को आकार देते हैं, फिर टूल्स हमें आकार देते हैं।

—मर्शल मैकलुहान

मैं अपने अच्छे दोस्त रिकार्डो सुएरास की उनकी समीक्षा, योगदान और मुझे इस लेख को अधूरा न छोड़ने देने के लिए ईमानदारी से धन्यवाद और आभार व्यक्त करना चाहता हूं। रिकार्डो, तुम सिर्फ एक किंवदंती हो!

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

"अराजकता इंजीनियरिंग में अवलोकन की वस्तु के संबंध में सावधान अवलोकन, गंभीर संदेह शामिल है, क्योंकि संज्ञानात्मक धारणाएं परिणामों की व्याख्या को विकृत करती हैं। इस तकनीक में समान टिप्पणियों के आधार पर प्रेरण के माध्यम से प्रेरण के माध्यम से परिकल्पना का निर्माण शामिल है; इसी तरह की परिकल्पना से किए गए निष्कर्षों के प्रयोगात्मक और माप-आधारित परीक्षण; समायोजन या प्रयोगात्मक परिणामों के आधार पर परिकल्पना की अस्वीकृति "

-Wikipedia

अराजकता इंजीनियरिंग उस प्रणाली की स्थिर स्थिति को समझने से शुरू होती है जो आप के साथ काम कर रहे हैं, फिर एक परिकल्पना तैयार करना, और अंत में एक प्रयोग जो इसकी पुष्टि करता है, सिस्टम की सुरक्षा के मार्जिन को बढ़ाने में मदद करता है।

अराजकता इंजीनियरिंग चरण

लेखों की एक श्रृंखला के पहले भाग में, मैंने अराजकता इंजीनियरिंग की शुरुआत की और ऊपर वर्णित कार्यप्रणाली के प्रत्येक चरण पर चर्चा की।

दूसरे भाग में , मैंने उन क्षेत्रों की जांच की, जिनमें अराजकता इंजीनियरिंग पर प्रयोग डिजाइन करते समय आपको निवेश करने की आवश्यकता होती है, और सही परिकल्पना कैसे चुननी है।

इस तीसरे भाग में, मैं स्वयं प्रयोग पर ध्यान केंद्रित करूंगा और उन उपकरणों और विधियों का चयन प्रस्तुत करूंगा जो विफलताओं की एक विस्तृत श्रृंखला को कवर करते हैं।

सूची संपूर्ण नहीं है, लेकिन शुरू करने के लिए, और विचार के लिए भोजन देने के लिए, यह पर्याप्त होना चाहिए।

विफलता का परिचय - यह क्या है और इसके लिए क्या है?

विफलता का उपयोग यह सत्यापित करने के लिए किया जाता है कि सिस्टम प्रतिक्रिया सामान्य लोड स्थितियों के तहत विनिर्देशों को पूरा करती है। पहली बार इस तकनीक का उपयोग तब किया गया था जब विफलताओं को "लोहे" स्तर पर - संपर्कों के स्तर पर, उपकरणों पर विद्युत संकेतों को बदलकर पेश किया गया था।

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

विफलताओं की शुरूआत के कई महत्वपूर्ण लाभ हैं, मदद करना:

• दुर्घटनाओं और घटनाओं की प्रतिक्रियाओं को समझें और उनका अभ्यास करें।
• वास्तविक विफलताओं के प्रभाव को समझें।
• प्रभावशीलता और दोष सहिष्णुता तंत्र की सीमाओं को समझें।
• डिज़ाइन त्रुटियों को समाप्त करें और विफलता के सामान्य बिंदुओं का पता लगाएं।
• समझने और प्रणाली की निगरानी में सुधार।
• विफलता की त्रिज्या को समझें और इसे कम करें।
• सिस्टम घटकों के बीच त्रुटि के प्रसार को समझें।

विफलता श्रेणियाँ

विफलता की शुरूआत की 5 श्रेणियां हैं: (1) संसाधन के स्तर पर; (2) नेटवर्क और निर्भरता; (3) आवेदन, प्रक्रिया और सेवा; (4) बुनियादी ढाँचा; और (5) मानव स्तर **।

अगला, मैं प्रत्येक श्रेणी की जांच करूंगा और उनमें से प्रत्येक के लिए असफलताओं को पेश करने का एक उदाहरण दूंगा। मैं विफलताओं और सभी में एक आर्केस्ट्रा साधनों को पेश करने के एक उदाहरण पर भी विचार करूंगा।

** महत्वपूर्ण! इस पोस्ट में मैं मानवीय स्तर पर विफलताओं के परिचय को नहीं छूता हूं, लेकिन मैं निम्नलिखित में इस पर विचार करूंगा।

1 - संसाधन स्तर पर विफलता का परिचय, संसाधनों की कमी उर्फ।

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

संसाधनों की कमी सेवा हमले के एक खंडन का अनुकरण करती है, लेकिन सामान्य सर्वर पर घुसपैठ करने के लिए नहीं। विफलताओं का यह परिचय शायद व्यापक है, क्योंकि, शायद, इसका उपयोग करना मुश्किल नहीं है।

CPU, मेमोरी और I / O संसाधनों को हटाना

मेरा एक पसंदीदा उपकरण तनाव-एनजी है, मूल तनाव परीक्षण उपकरण का पत्राचार , जिसे अमोस वॉटरलैंड ने लिखा है ।

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

नीचे तनाव-एनजी का उपयोग करने के कुछ व्यावहारिक उदाहरण दिए गए हैं:

सीपीयू matrixprod पर लोड मेमोरी, कैश और फ्लोटिंग पॉइंट के साथ संचालन का सही मिश्रण देता है। यह, शायद। सीपीयू को अच्छी तरह से गर्म करने का सबसे अच्छा तरीका है।

 ❯ stress-ng —-cpu 0 --cpu-method matrixprod -t 60s 

iomix-bytes लोड प्रत्येक iomix हैंडलर iomix लिए एन-बाइट्स लिखता iomix ; डिफ़ॉल्ट 1 GB है और I / O तनाव परीक्षण करने के लिए आदर्श है। इस उदाहरण में, मैं फ़ाइल सिस्टम पर 80% खाली स्थान सेट करूँगा।

 ❯ stress-ng --iomix 1 --iomix-bytes 80% -t 60s 

vm-bytes मेमोरी स्ट्रेस टेस्ट के लिए बहुत अच्छा है। इस उदाहरण में, तनाव-एनजी वर्चुअल मेमोरी के 9 तनाव परीक्षण चलाता है, जो एक साथ प्रति घंटे उपलब्ध मेमोरी का 90% उपभोग करते हैं। इस प्रकार, प्रत्येक तनाव परीक्षण में उपलब्ध स्मृति का 10% हिस्सा होता है।

 ❯ stress-ng --vm 9 --vm-bytes 90% -t 60s 

हार्ड ड्राइव पर डिस्क स्थान से बाहर

dd फ़ाइलों को परिवर्तित करने और कॉपी करने के लिए संकलित एक कमांड लाइन उपयोगिता है। हालाँकि, dd हार्ड डिस्क के बूट सेक्टर का बैकअप लेने और रैंडम डेटा की एक निश्चित राशि प्राप्त करने जैसे कार्यों के लिए /dev/zero और /dev/random जैसे विशेष उपकरणों की फाइलों से पढ़ और / या लिख ​​सकता है। इस प्रकार, इसका उपयोग सर्वर पर विफलताओं को पेश करने और डिस्क ओवरफ्लो का अनुकरण करने के लिए किया जा सकता है। क्या आपकी लॉग फ़ाइलों ने सर्वर को ओवरफ्लो किया और एप्लिकेशन को छोड़ दिया? तो, dd मदद करेगा - और यह चोट लगी होगी!

dd उपयोग बहुत सावधानी से करें। गलत कमांड दर्ज करें - और हार्ड पर डेटा मिट जाएगा, नष्ट हो जाएगा या ओवरराइट हो जाएगा!

 ❯ dd if=/dev/urandom of=/burn bs=1M count=65536 iflag=fullblock & 

एप्लिकेशन API स्‍लोडाउन

एपीआई के प्रदर्शन, लचीलापन और मापनीयता महत्वपूर्ण हैं। एपीआई अनुप्रयोगों के निर्माण और आपके व्यवसाय को बढ़ाने के लिए महत्वपूर्ण हैं।

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

wrk एक HTTP बेंचमार्किंग टूल है जो सिस्टम पर एक महत्वपूर्ण स्ट्रेन डालता है। मुझे विशेष रूप से एपीआई एक्सेस चेक का परीक्षण करना पसंद है, खासकर जब यह प्रदर्शन चेक की बात आती है, क्योंकि वे डेवलपर कोड स्तर पर डिजाइन निर्णयों के बारे में बहुत सारी चीजें प्रकट करते हैं: कैश कैसे कॉन्फ़िगर किया गया है? गति सीमा कैसे लागू की जाती है? क्या सिस्टम लोड बैलेन्सर के संबंध में स्वास्थ्य जांच को प्राथमिकता देता है?

यहां से शुरू करना है:

 ❯ wrk -t12 -c400 -d20s http://127.0.0.1/api/health 

यह कमांड 12 थ्रेड शुरू करता है और 400 HTTP कनेक्शन 20 सेकंड के लिए खुला रखता है।

2 - नेटवर्क-स्तरीय विफलताओं और निर्भरता का परिचय

पीटर डिटर की पुस्तक, द आठ फालिज ऑफ डिस्ट्रिब्यूटेड कम्प्यूटिंग, उन मान्यताओं का एक संग्रह है जो डेवलपर्स वितरित सिस्टम को डिजाइन करते समय बनाते हैं। और फिर जवाब दुर्गमता के रूप में उड़ता है, और आपको सब कुछ फिर से करना होगा। ये गलत धारणाएं हैं:

• नेटवर्क विश्वसनीय है।
• देरी 0 है।
• बैंडविड्थ अंतहीन है।
• नेटवर्क सुरक्षित है।
• टोपोलॉजी नहीं बदलती है।
• केवल एक व्यवस्थापक है।
• स्थानांतरण लागत 0।
• नेटवर्क सजातीय है।

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

नेटवर्क विलंबता, हानि या रुकावट का परिचय

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

यूडीपी या टीसीपी अनुप्रयोगों के लिए देरी और पैकेट नुकसान का अनुकरण करने के लिए या किसी विशेष सेवा के बैंडविड्थ के उपयोग को सीमित करने के लिए tc का उपयोग किया जा सकता है - इंटरनेट ट्रैफ़िक की स्थितियों का अनुकरण करने के लिए।

- 100 एमएस की देरी का परिचय

 #Start ❯ tc qdisc add dev etho root netem delay 100ms #Stop ❯ tc qdisc del dev etho root netem delay 100ms 

- 50 एमएस के डेल्टा के साथ 100 एमएस की देरी का परिचय

 #Start ❯ tc qdisc add dev eth0 root netem delay 100ms 50ms #Stop ❯ tc qdisc del dev eth0 root netem delay 100ms 50ms 

- 5% नेटवर्क पैकेट को नुकसान

 #Start ❯ tc qdisc add dev eth0 root netem corrupt 5% #Stop ❯ tc qdisc del dev eth0 root netem corrupt 5% 

- 25 प्रतिशत सहसंबंध के साथ 7% पैकेट का नुकसान

 #Start ❯ tc qdisc add dev eth0 root netem loss 7% 25% #Stop ❯ tc qdisc del dev eth0 root netem loss 7% 25% 

महत्वपूर्ण! टीसीपी आवेदन नहीं छोड़ने के लिए 7% पर्याप्त है।

"/ Etc / मेजबान" के साथ खेलना - मेजबान नामों के लिए एक स्थिर लुकअप तालिका

/etc/hosts एक साधारण पाठ फ़ाइल है जो आईपी पते को होस्ट नामों, एक समय में एक पंक्ति के साथ जोड़ती है। प्रत्येक नोड को निम्नलिखित जानकारी वाली एक पंक्ति की आवश्यकता होती है:

 IP_address canonical_hostname [aliases...] 

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

- EC2 उदाहरण के लिए DynamoDB API तक पहुंच को ब्लॉक करें

 #Start # make copy of /etc/hosts to /etc/host.back ❯ cp /etc/hosts /etc/hosts.back ❯ echo "127.0.0.1 dynamodb.us-east-1.amazonaws.com" >> /etc/hosts ❯ echo "127.0.0.1 dynamodb.us-east-2.amazonaws.com" >> /etc/hosts ❯ echo "127.0.0.1 dynamodb.us-west-1.amazonaws.com" >> /etc/hosts ❯ echo "127.0.0.1 dynamodb.us-west-2.amazonaws.com" >> /etc/hosts ❯ echo "127.0.0.1 dynamodb.eu-west-1.amazonaws.com" >> /etc/hosts ❯ echo "127.0.0.1 dynamodb.eu-north-1.amazonaws.com" >> /etc/hosts #Stop # copy back the old version /etc/hosts ❯ cp /etc/hosts.back /etc/hosts 

- EC2 उदाहरण से EC2 API तक पहुंच को रोकें

 #Start # make copy of /etc/hosts to /etc/host.back ❯ cp /etc/hosts /etc/hosts.back ❯ echo "127.0.0.1 ec2.us-east-1.amazonaws.com" >> /etc/hosts ❯ echo "127.0.0.1 ec2.us-east-2.amazonaws.com" >> /etc/hosts ❯ echo "127.0.0.1 ec2.us-west-1.amazonaws.com" >> /etc/hosts ❯ echo "127.0.0.1 ec2.us-west-2.amazonaws.com" >> /etc/hosts ❯ echo "127.0.0.1 ec2.eu-west-1.amazonaws.com" >> /etc/hosts ❯ echo "127.0.0.1 ec2.eu-north-1.amazonaws.com" >> /etc/hosts #Stop # copy back the old version /etc/hosts ❯ cp /etc/hosts.back /etc/hosts 

लाइव देखें: पहले, EC2 API उपलब्ध है और ec2 describe-instances सफलतापूर्वक देता है।

एक बार जब मैंने 127.0.01 ec2.eu-west-1.amazonaws.com को /etc/hosts , और EC2 API कॉल ड्रॉप्स में जोड़ा।

बेशक, यह सभी एडब्ल्यूएस एपीआई के लिए काम करता है।

मैं आपको DNS के बारे में एक चुटकुला बताऊंगा ...

... लेकिन, मुझे डर है, यह दूसरे दिन ही आप तक पहुँच जाएगा। मेरा मतलब है, 24 घंटे के बाद।

21 अक्टूबर, 2016 को, DDoS Dyn हमले के कारण, यूरोप और उत्तरी अमेरिका में प्लेटफार्मों और सेवाओं की एक अच्छी संख्या उपलब्ध नहीं थी। 2018 में दुनिया भर में DNS प्रदर्शन पर थाउज़ेंडाइज़ की रिपोर्ट के अनुसार, 60% उद्यम और सास प्रदाता अभी भी एक ही स्रोत DNS प्रदाता पर भरोसा करते हैं और इस प्रकार, DNS विफलताओं के लिए कमजोर हो जाते हैं। और चूंकि डीएनएस के बिना कोई इंटरनेट नहीं होगा, इसलिए डीएनएस की विफलता का अनुकरण करने के लिए अगली डीएनएस विफलता के लिए अपने लचीलापन का मूल्यांकन करना बहुत अच्छा होगा।

ब्लैकहोलिंग एक ऐसी विधि है जिसके द्वारा वे पारंपरिक रूप से DDoS हमले के नुकसान को कम करते हैं। खराब नेटवर्क ट्रैफ़िक को ब्लैक होल में रूट किया जाता है और उसे शून्य में डाल दिया जाता है। नेटवर्क पर काम करने के लिए /dev/null का संस्करण :-) आप इसका उपयोग नेटवर्क ट्रैफ़िक के नुकसान या उसी DNS के प्रोटोकॉल का अनुकरण करने के लिए कर सकते हैं, कहते हैं।

इस कार्य के लिए, आपको iptables टूल की आवश्यकता होती है, जिसका उपयोग लिनक्स कर्नेल में आईपी पैकेट को कॉन्फ़िगर करने, बनाए रखने और सत्यापित करने के लिए किया जाता है।

ब्लैकहोल के माध्यम से DNS ट्रैफ़िक प्राप्त करने के लिए, इसे आज़माएँ:

 #Start ❯ iptables -A INPUT -p tcp -m tcp --dport 53 -j DROP ❯ iptables -A INPUT -p udp -m udp --dport 53 -j DROP #Stop ❯ iptables -D INPUT -p tcp -m tcp --dport 53 -j DROP ❯ iptables -D INPUT -p udp -m udp --dport 53 -j DROP 

Toxiproxy का उपयोग कर विफलताओं का परिचय।

लिनक्स उपकरण जैसे tc और iptables एक है - लेकिन केवल गंभीर समस्या नहीं है। उन्हें चलाने के लिए रूट अनुमति की आवश्यकता होती है, और यह कुछ संगठनों और वातावरण के लिए समस्याएं पैदा करता है। कृपया प्यार और अनुग्रह करें - टोक्सिप्रोक्सी !

Toxiproxy इंजीनियरों की Shopify टीम द्वारा विकसित एक खुला स्रोत टीसीपी प्रॉक्सी है। यह अराजक नेटवर्क और सिस्टम स्थितियों या वास्तविक सिस्टम का अनुकरण करने में मदद करता है। इसे नीचे दिखाए गए अनुसार वास्तुकला के विभिन्न घटकों के बीच रखें।

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

निम्न उदाहरण दिखाता है कि टोक्सिप्रोक्सी कैसे विषाक्तता ग्राहक कोड के साथ काम करता है मेरे रेडिस क्लाइंट, रेडिस-क्ली और खुद रेडिस के बीच कनेक्शन में 1000 एमएस विलंब की शुरुआत करके।

अक्टूबर 2014 के बाद से सभी उत्पादन और विकास के वातावरण में शॉपिफाई द्वारा टोक्सिप्रोक्सी का सफलतापूर्वक उपयोग किया गया है। अधिक जानकारी उनके ब्लॉग पर है ।

3 - आवेदन, प्रक्रिया और सेवा स्तर पर विफलताओं का परिचय

सॉफ्टवेयर गिर रहा है। यह एक तथ्य है। और आप क्या करते हैं? क्या मुझे सर्वर पर एसएसएच के माध्यम से लॉग इन करना चाहिए और असफल प्रक्रिया को पुनरारंभ करना चाहिए? प्रक्रिया नियंत्रण प्रणाली राज्य नियंत्रण या राज्य के प्रकार के कार्यों को प्रारंभ, रोकना, पुनः आरंभ करना प्रदान करती है। नियंत्रण प्रणाली आमतौर पर स्थिर प्रक्रिया नियंत्रण सुनिश्चित करने के लिए उपयोग की जाती है। systemd सिर्फ एक ऐसा उपकरण है, जो Linux के लिए बुनियादी प्रक्रिया नियंत्रण ईंटें प्रदान करता है। Supervisord ऑपरेटिंग सिस्टम जैसे UNIX पर कई प्रक्रियाओं का नियंत्रण प्रदान करता है।

जब आप एप्लिकेशन को तैनात करते हैं, तो आपको इन उपकरणों का उपयोग करना चाहिए। यह महत्वपूर्ण प्रक्रियाओं को मारने से नुकसान का परीक्षण करने के लिए निश्चित रूप से अच्छा अभ्यास है। सुनिश्चित करें कि आप अलर्ट प्राप्त करते हैं और प्रक्रिया स्वचालित रूप से पुनरारंभ हो जाती है।

- जावा प्रक्रियाओं को मार डालो

 ❯ pkill -KILL -f java #Alternative ❯ pkill -f 'java -jar' 

- पायथन प्रक्रियाओं को मार डालो

 ❯ pkill -KILL -f python 

बेशक, आप सिस्टम पर चल रही कुछ अन्य प्रक्रियाओं को मारने के लिए pkill कमांड का उपयोग कर सकते हैं।

पेश है डेटाबेस विफलताएँ

यदि विफलता संदेश हैं जो ऑपरेटर प्राप्त करना पसंद नहीं करते हैं, तो ये डेटाबेस विफलता से संबंधित हैं। डेटा सोने में अपने वजन के लायक है, और इसलिए, हर बार जब एक डेटाबेस क्रैश होता है, तो ग्राहक डेटा खोने का जोखिम बढ़ जाता है।

यह सिर्फ आसान रखरखाव होगा। और-तो-और-और ... सब कुछ गिर गया

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

हालाँकि, यदि आप अमेज़ॅन अरोरा का उपयोग कर रहे हैं, तो आप असफल अनुरोधों का उपयोग करके अमेज़ॅन अरोरा डेटाबेस क्लस्टर की लचीलापन का परीक्षण कर सकते हैं।

अमेज़ॅन अरोरा क्रैश परिचय

विफलता के अनुरोधों को अमेज़ॅन अरोरा उदाहरण के लिए एसक्यूएल कमांड के रूप में जारी किया जाता है और आपको निम्नलिखित घटनाओं में से एक के सिमुलेशन को शेड्यूल करने की अनुमति देता है:

• एक लेखन DB उदाहरण की विफलता।
• अरोरा प्रतिकृति की विफलता।
• डिस्क विफलता।
• डिस्क अधिभार।

विफलता के लिए अनुरोध भेजते समय, आपको उस समय की मात्रा भी निर्दिष्ट करनी होगी, जिसके दौरान विफलता की घटना का अनुकरण किया जाएगा।

- कारण अमेज़ॅन अरोरा इंस्टेंस विफलता:

 ALTER SYSTEM CRASH [ INSTANCE | DISPATCHER | NODE ]; 

- अरोरा प्रतिकृति की विफलता का अनुकरण करें:

 ALTER SYSTEM SIMULATE percentage PERCENT READ REPLICA FAILURE [ TO ALL | TO "replica name" ] FOR INTERVAL quantity { YEAR | QUARTER | MONTH | WEEK | DAY | HOUR | MINUTE | SECOND }; 

- अरोरा डेटाबेस क्लस्टर के लिए डिस्क विफलता अनुकरण:

 ALTER SYSTEM SIMULATE percentage PERCENT DISK FAILURE [ IN DISK index | NODE index ] FOR INTERVAL quantity { YEAR | QUARTER | MONTH | WEEK | DAY | HOUR | MINUTE | SECOND }; 

- अरोरा डेटाबेस क्लस्टर के लिए डिस्क विफलता अनुकरण:

 ALTER SYSTEM SIMULATE percentage PERCENT DISK CONGESTION BETWEEN minimum AND maximum MILLISECONDS [ IN DISK index | NODE index ] FOR INTERVAL quantity { YEAR | QUARTER | MONTH | WEEK | DAY | HOUR | MINUTE | SECOND }; 

सर्वर रहित अनुप्रयोगों की दुनिया में क्रैश

यदि आप सर्वर रहित घटकों का उपयोग करते हैं, तो विफलता एक वास्तविक चुनौती हो सकती है, क्योंकि AWS लैम्ब्डा जैसी सर्वर रहित सेवाएं मूल रूप से विफलता का समर्थन नहीं करती हैं।

पेश है लाम्बा की विफलताएं

इस समस्या को समझने के लिए, मैंने AWS लैम्ब्डा में विफलताओं का परिचय देने के लिए एक छोटी सी अजगर लाइब्रेरी और एक लैम्ब्डा लेयर लिखी। वर्तमान में, दोनों देरी, त्रुटियों, अपवादों और एक HTTP त्रुटि कोड की शुरूआत का समर्थन करते हैं। निम्नानुसार AWS SSM पैरामीटर स्टोर को कॉन्फ़िगर करके विफलता प्राप्त की जाती है:

 { "isEnabled": true, "delay": 400, "error_code": 404, "exception_msg": "I really failed seriously", "rate": 1 } 

विफलता को पेश करने के लिए आप हैंडलर फ़ंक्शन में एक अजगर डेकोरेटर जोड़ सकते हैं।

- एक अपवाद फेंक:

 @inject_exception def handler_with_exception(event, context): return { 'statusCode': 200, 'body': 'Hello from Lambda!' } >>> handler_with_exception('foo', 'bar') Injecting exception_type <class "Exception"> with message I really failed seriously a rate of 1 corrupting now Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/.../chaos_lambda.py", line 316, in wrapper raise _exception_type(_exception_msg) Exception: I really failed seriously 

- त्रुटि कोड "अवैध HTTP" दर्ज करें:

 @inject_statuscode def handler_with_statuscode(event, context): return { 'statusCode': 200, 'body': 'Hello from Lambda!' } >>> handler_with_statuscode('foo', 'bar') Injecting Error 404 at a rate of 1 corrupting now {'statusCode': 404, 'body': 'Hello from Lambda!'} 

- देरी दर्ज करें:

 @inject_delay def handler_with_delay(event, context): return { 'statusCode': 200, 'body': 'Hello from Lambda!' } >>> handler_with_delay('foo', 'bar') Injecting 400 of delay with a rate of 1 Added 402.20ms to handler_with_delay {'statusCode': 200, 'body': 'Hello from Lambda!'} 

इस अजगर पुस्तकालय के बारे में अधिक जानने के लिए यहां क्लिक करें ।

कंबाइंड लिमिटेशन के माध्यम से लैम्ब्डा प्रवर्तन डेनियल

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

 ❯ aws lambda put-function-concurrency --function-name <value> --reserved-concurrent-executions 0 

यह कमांड शून्य तक पहुंच को कम कर देगा, जिससे "ब्रेकिंग" जैसी त्रुटि के साथ क्वेरी विफल हो सकती है - डीटीसी 429 ।

थंड्रा - सर्वर रहित ट्रांसमिशन ट्रेस

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

और सर्वर रहित अनुप्रयोगों पर अनुभाग के समापन में, मैं कहूंगा कि सर्वर रहित अनुप्रयोगों के संबंध में यान चुई की कठिनाइयों पर यान चुई का एक उत्कृष्ट लेख है । मैं सभी को इसे पढ़ने की सलाह देता हूं।

4 - बुनियादी ढांचे के स्तर पर विफलताओं का परिचय

यह सब अमेज़ॅन और नेटफ्लिक्स दोनों के लिए - बुनियादी ढांचे के स्तर पर विफलताओं की शुरूआत के साथ शुरू हुआ । बुनियादी ढांचे के स्तर पर विफलताओं की शुरूआत - एक संपूर्ण डेटा केंद्र को बेतरतीब ढंग से उदाहरणों को बंद करने से - लागू करने के लिए सबसे आसान है।

और, ज़ाहिर है, " अराजकता के बंदर " का उदाहरण सबसे पहले दिमाग में आता है।

EC2 उदाहरणों को रोकना जो एक निश्चित उपलब्धता क्षेत्र में अनियमित रूप से चुने गए हैं।

अपनी प्रारंभिक अवस्था में, नेटफ्लिक्स कठिन वास्तु नियमों को लागू करना चाहता था। उन्होंने अपने "अराजक बंदर" को पहले एडब्ल्यूएस अनुप्रयोगों में से एक के रूप में तैनात किया ताकि वे किसी भी उदाहरण को नष्ट कर सकें या स्वचालित रूप से प्रतिस्थापित कर सकें। कैओस बंदर ने यह सुनिश्चित किया कि किसी ने भी इस नियम का उल्लंघन नहीं किया।

अगले परिदृश्य - "अराजकता के बंदर" के समान - समान क्षेत्र के भीतर एक विशिष्ट उपलब्धता क्षेत्र में यादृच्छिक पर किसी भी उदाहरण को रोकना है।

 ❯ stop_random_instance(az="eu-west-1a", tag_name="chaos", tag_value="chaos-ready", region="eu-west-1") 

 import boto3 import random REGION = 'eu-west-1' def stop_random_instance(az, tag_name, tag_value, region=REGION): ''' >>> stop_random_instance(az="eu-west-1a", tag_name='chaos', tag_value="chaos-ready", region='eu-west-1') ['i-0ddce3c81bc836560'] ''' ec2 = boto3.client("ec2", region_name=region) paginator = ec2.get_paginator('describe_instances') pages = paginator.paginate( Filters=[ { "Name": "availability-zone", "Values": [ az ] }, { "Name": "tag:" + tag_name, "Values": [ tag_value ] } ] ) instance_list = [] for page in pages: for reservation in page['Reservations']: for instance in reservation['Instances']: instance_list.append(instance['InstanceId']) print("Going to stop any of these instances", instance_list) selected_instance = random.choice(instance_list) print("Randomly selected", selected_instance) response = ec2.stop_instances(InstanceIds=[selected_instance]) return response 

क्या आपने tag_name और tag_value ? ऐसी छोटी चीजें गलत उदाहरणों की विफलता को रोकेंगी। #lessonlearned

और हाँ ... डेटाबेस को पुनः आरंभ करें - अच्छी तरह से किया गया [उफ़, नहीं तो उदाहरण]

5 - विफलता परिचय और सभी में एक आर्केस्ट्रा उपकरण

यह संभावना है कि आप इतने सारे उपकरणों में खो गए हैं। सौभाग्य से, कुछ इंकार इंट्रोडक्शन और ऑर्केस्ट्रेशन टूल हैं जिनमें से अधिकांश शामिल हैं और उपयोग करने में आसान हैं।

अराजकता टूलकिट

मेरे पसंदीदा उपकरणों में से एक कैओस टूलकिट है , जो एक खुला स्रोत अराजकता इंजीनियरिंग प्लेटफॉर्म है, जो महान कैओसक्यू टीम द्वारा व्यावसायिक रूप से समर्थित है। यहाँ उनमें से कुछ हैं: राईस माइल्स , सिल्वेन हेलगुगार्च और मार्क पैरीने ।

अराजकता टूलकिट एक घोषणा और एक्स्टेंसिबल एपीआई को आसानी से अराजकता इंजीनियरिंग प्रयोग करने के लिए परिभाषित करता है। इसमें AWS, Google क्लाउड इंजन, Microsoft Azure, Cloud Foundry, Humino, Prometheus और Gremlin के ड्राइवर शामिल हैं।

एक्सटेंशन्स चेक और प्रयोग के लिए उपयोग की जाने वाली क्रियाओं का एक समूह है: हम एक विशिष्ट उपलब्धता क्षेत्र में बेतरतीब ढंग से चयनित उदाहरण को रोक देते हैं यदि tag-key में chaos-ready मूल्य होते हैं।

 { "version": "1.0.0", "title": "What is the impact of randomly terminating an instance in an AZ", "description": "terminating EC2 instance at random should not impact my app from running", "tags": ["ec2"], "configuration": { "aws_region": "eu-west-1" }, "steady-state-hypothesis": { "title": "more than 0 instance in region", "probes": [ { "provider": { "module": "chaosaws.ec2.probes", "type": "python", "func": "count_instances", "arguments": { "filters": [ { "Name": "availability-zone", "Values": ["eu-west-1c"] } ] } }, "type": "probe", "name": "count-instances", "tolerance": [0, 1] } ] }, "method": [ { "type": "action", "name": "stop-random-instance", "provider": { "type": "python", "module": "chaosaws.ec2.actions", "func": "stop_instance", "arguments": { "az": "eu-west-1c" }, "filters": [ { "Name": "tag-key", "Values": ["chaos-ready"] } ] }, "pauses": { "after": 60 } } ], "rollbacks": [ { "type": "action", "name": "start-all-instances", "provider": { "type": "python", "module": "chaosaws.ec2.actions", "func": "start_instances", "arguments": { "az": "eu-west-1c" }, "filters": [ { "Name": "tag-key", "Values": ["chaos-ready"] } ] } } ] } 

उपरोक्त प्रयोग करना सरल है:

 ❯ chaos run experiment_aws_random_instance.json 

कैओस टूलकिट की ताकत यह है कि, सबसे पहले, यह खुला स्रोत है और आपकी आवश्यकताओं के अनुरूप हो सकता है। दूसरे, यह सीआई / सीडी पाइपलाइन में पूरी तरह से फिट बैठता है और निरंतर अराजकता परीक्षण का समर्थन करता है।

कैओस टूलकिट के नकारात्मक पक्ष यह है कि इसे मास्टर करने में समय लगता है। इसके अलावा, इसमें कोई तैयार-किए गए प्रयोग नहीं हैं, इसलिए आपको उन्हें स्वयं लिखना होगा। हालांकि, मैं ChaosIQ में टीम से परिचित हूं, जो इस कार्य को समझते हुए अथक प्रयास करती है।

दुष्टात्मा

मेरा एक और पसंदीदा ग्रेमलिन है। इसमें सहज उपयोगकर्ता इंटरफ़ेस के साथ एक सरल उपकरण में विफलताओं को पेश करने के लिए एक व्यापक सेट है। ऐसी अराजकता-जैसी-ए-सेवा।

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

प्लस एक बोनस - ग्रेमलिन के लोग महान फैलो हैं जो ब्लॉग के लिए शानदार सामग्री लिखते हैं और हमेशा मदद के लिए तैयार रहते हैं! यहाँ उनमें से कुछ हैं: मैथ्यू , कोल्टन , टैमी , रिच , एना और एचएमएल ।

Gremlin का उपयोग करने के लिए कहीं नहीं है:

सबसे पहले Gremlin ऐप एंटर करें और "Create Attack" चुनें।

एक लक्ष्य - उदाहरण निर्दिष्ट करें।

विफलता के प्रकार का चयन करें जिसे आप शुरू करना चाहते हैं, और अराजकता शुरू हो सकती है!

मुझे यह स्वीकार करना चाहिए कि मुझे हमेशा ग्रेमलिन पसंद था: उसके साथ, अराजकता इंजीनियरिंग पर प्रयोग सहज रूप से सरल हैं।

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

AWS सिस्टम मैनेजर से कमांड चलाएँ

Run command EC2 , 2015 , . — 2, . , , Systems Manager.

Run Command DevOps ad-hoc , .

, Run Command , Windows, -.

AWS System Manager . — !

!

, .

1 — - — , - . . — , — , , . , ! :

" . ".
— , - Amazon Prime Video

2 — , , . , -.

3 — , , .

4 — , , , . , - — , .

, , , . , . , , :-)

—