🚖 🎹 👶🏽 हम अमेज़ॅन में "बैकअप" सर्वर कैसे करते हैं और पिरान्हा को बंद करते हैं 🚟 📰 📠

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

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

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

ईबीएस डिस्क की विश्वसनीयता - RAID1 या "बदतर"?

ईमानदार होने के लिए, ईबीएस-डिस्क पर आधिकारिक अमेज़ॅन प्रलेखन से, मुझे अभी भी समझ नहीं आया कि वे RAID1 से अधिक विश्वसनीय हैं या नहीं - डिस्क की मात्रा के कार्यात्मक निर्भरता के बारे में कोई भी बात, डिस्क के अंतिम स्नैपशॉट का समय, जादूगर की दाढ़ी और चंद्रमा के चरण में बालों की संख्या आशावाद को प्रेरित नहीं करती है:
"आपके वॉल्यूम का स्थायित्व आपके वॉल्यूम के आकार और आपके पिछले स्नैपशॉट के बाद से बदल चुके डेटा के प्रतिशत दोनों पर निर्भर करता है। उदाहरण के रूप में, ऐसे वॉल्यूम जो 20 जीबी या उससे कम संशोधित डेटा के साथ काम करते हैं क्योंकि उनके सबसे हाल के अमेज़ॅन ईबीएस स्नैपशॉट 0.1% - 0.5% के बीच वार्षिक विफलता दर (एएफआर) की उम्मीद कर सकते हैं, जहां विफलता वॉल्यूम की पूरी हानि को संदर्भित करती है »

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

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

फिर भी, आधे साल के लिए, अमेज़ॅन में एक भी डिस्क नहीं उड़ गई (हमारे पास लगभग 50 हैं), बिजली की कमी को बिजली की हड़ताल के बाद नहीं गिनना, जो हमें अधिक या कम विश्वसनीय "RAID1" ड्राइव (दस्तक) के रूप में इलाज करने की अनुमति देता है ; एक ही डेटा सेंटर में स्थित एक उपकरण के लिए प्रतिकृति), s3 की विश्वसनीयता में हीन (यह अलग-अलग डेटा केंद्रों में 2 उपकरणों के अतिरिक्त प्रतिकृति है, और सामान्य तौर पर यह एक ब्लॉक डिवाइस नहीं है), लेकिन साधारण हार्ड ड्राइव की तुलना में 10 गुना अधिक विश्वसनीय है।

सॉफ्टवेयर छापे और कम ईबीएस प्रदर्शन

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

cat /proc/mdstat
Personalities : [raid10]
md0 : active raid10 sdo[0] sdj[8](S) sdi[7] sdh[6] sdg[5] sdn[4] sdm[3] sdl[2] sdk[1]
629145344 blocks 64K chunks 2 near-copies [8/8] [UUUUUUUU]

अरे हाँ, स्पेयर-डिस्क, जैसा कि आप देख सकते हैं, हम :-) 'sdj [8] (S)' का उपयोग करते हैं। सभी समान, उन्होंने गलती की सहनशीलता के स्तर को बढ़ाने के लिए छापे डालने का फैसला किया।
छापे के लिए डेटा माइग्रेशन के बाद, मशीनों पर डिस्क सबसिस्टम के प्रदर्शन के साथ समस्याएं परेशान होना बंद हो गईं।

क्लस्टर फ़ाइल सिस्टम और ईबीएस ड्राइव

क्योंकि हमारी मुख्य साइट (www.1c-bitrix.ru) एक वेब-क्लस्टर कॉन्फ़िगरेशन में काम करती है: दो वेब मशीनें, एक डेटाबेस (मास्टर + दास) के साथ दो मशीनें - बैलेंसर (नग्नेक्स) के पीछे, हम वास्तव में, वास्तव में एक क्लस्टर फ़ाइल सिस्टम का उपयोग करना चाहते थे। OCFS2 या GFS2 की तरह। लेकिन यह पता चला है कि ईबीएस डिस्क कई आभासी मशीनों पर एक साथ नहीं लगाया जा सकता है। इसलिए, हम सामग्री क्लस्टरिंग के लिए csync2 उपयोगिता का उपयोग करते हैं, जो कि ऐड-इन के आधार पर अक्सर अपडेट किए गए भारी फ़ोल्डरों को "जल्दी" सिंक्रनाइज़ करने के लिए मजबूर किया जाता है (यदि रुचि है, तो हम आपको और अधिक बताएंगे)।

बैकअप ईबीएस ड्राइव

वर्चुअल मशीन डिस्क बैकअप के लिए बहुत आसान है, क्योंकि इस प्रयोजन के लिए, ब्लॉक डिवाइस के स्नैपशॉट बनाने के लिए एक उपकरण बनाया गया था:
ec2-create-snapshot vol-a5rtbvwe
ऑपरेशन बहुत जल्दी (सेकंड) शुरू होता है, और s3 में स्नैपशॉट लोड करना एक निश्चित समय तक रहता है, डिस्क आकार और अमेज़न लोड के आधार पर - दसियों मिनट तक।

हम वयस्क हैं और समझते हैं कि डिस्क का एक समग्र स्नैपशॉट हो सकता है यदि:

ड्राइव पूर्व-रहित है: "umount -d / dev / sdh"।
सर्वर पहले बंद है।
फाइल सिस्टम जमी हुई है। हालांकि इस मामले में, आपको अभी भी डिस्क को डेटा फ्लश करने के लिए एप्लिकेशन को बताने की आवश्यकता है।

अन्यथा, हमें डिस्क का एक स्नैपशॉट मिलता है "जैसे कि अचानक बिजली बंद होने के बाद" और मशीन के बूट होने पर डिस्क का इलाज (fsck) करना होगा - जो कि, आधुनिक जर्नलिंग फाइल सिस्टम (ext3, ext4, xfs, आदि ) के लिए धन्यवाद, किसी का ध्यान नहीं जाता है और अक्सर जल्दी से होता है। एक पत्रिका खेल रहा है। हमने एक डिस्क के स्नैपशॉट को लाइव (बिना नंबर के) ext3 और xfs के साथ बनाने का परीक्षण किया - लॉग को चलाने के लिए एक ठहराव के बाद, डिस्क (स्नैपशॉट से निर्मित) माउंट किया जाता है और काम करता है।

"फ्रीजिंग" और "फ्रीजिंग" फ़ाइल सिस्टम

"निलंबन" का समर्थन करने वाले फ़ाइल सिस्टम के रूप में, हमने xfs को चुना। यह एफएस अमेज़ॅन द्वारा अनुशंसित है और उपयोगिताओं द्वारा उपयोग किया जाता है जो कि पारिस्थितिक-सुसंगत-बैकअप प्रकार का पूरा स्नैपशॉट बनाने के लिए है:
xfs_freeze -f | -u mount-point
वास्तव में, अगर "xfs_freeze -f" के बाद डिस्क का एक स्नैपशॉट बनाया जाता है, तो यह लॉग को बहुत तेज़ी से चलाने के बिना माउंट किया जाता है।

CentOS6 में (और "अपडेट किए गए" कर्नेल के साथ अन्य वितरणों में), fsfreeze कमांड के साथ ext3 / ext4 जैसे डिफ़ॉल्ट फ़ाइल सिस्टम को भी "फ्रीज" करना संभव हो गया। हम ईबीएस डिस्क के समग्र स्नैपशॉट बनाने के संदर्भ में इस उपयोगिता का अच्छी तरह से परीक्षण करने की योजना बनाते हैं।

सॉफ्टवेयर RAID बैकअप

यदि आप तार्किक रूप से सोचते हैं, तो आपको a) "स्टॉप" द राइड फाइल सिस्टम, बी) ए फिजिकल रेड डिस्क डिस्क के लिए एक स्नैपशॉट बनाना शुरू करें, ग) छापे फाइल सिस्टम को "रिलीज़" करें।
दुर्भाग्य से, अमेज़ॅन एपीआई प्रलेखन में इस बात की जानकारी नहीं है कि बी) और सी के बीच कितना समय बीत जाना चाहिए)। हालाँकि, यह प्रायोगिक तौर पर पाया गया था (और इसी तरह इस उपयोगिता में ) कि यह प्रत्येक RAID डिस्क के लिए एपीआई कॉल से स्नैपशॉट पहचानकर्ताओं को प्राप्त करने के लिए पर्याप्त है और छापे फाइल सिस्टम को "विगलित" किया जा सकता है - और छापे को इकट्ठा करते समय इसे बिना पुनर्निर्माण के उठाया जाएगा। अन्यथा, यह पुनर्निर्माण करना शुरू कर देगा। तो हमने किया:

bxc_exec("/usr/bin/ssh remote_xfs_freezer@hostname".escapeshellarg("sudo /usr/sbin/xfs_freeze -f /xfs_raid_path"));
...
ec2-create-snapshot -
...
bxc_exec("/usr/bin/ssh remote_xfs_freezer@hostname".escapeshellarg("sudo /usr/sbin/xfs_freeze -u /xfs_raid_path"));
...
ec2-create-volume --snapshot id_of_snapshot
...
ec2-attach-volume volume_id -i instance_id -d device
...
mdadm --assemble /dev/mdN /dev/sd[az]

स्नैपशॉट MySQL?

यद्यपि आप MySQL डेटा को एक हाथ से डिस्क में फ्लश कर सकते हैं: READ LOCK के साथ FLUSH TABLES , बाएं पैर के साथ फाइल सिस्टम को फ्लिप करें: xfs_freeze -f / path, और स्नैपशॉट रिमूवल API को निष्पादित करने के लिए अपनी नाक से एंटर करें: ec2-create-snapshot ... हम पूरी तरह से हैं अतुल्यकालिक MySQL प्रतिकृति एक और डीसी के लिए संतुष्ट है :-)। दिलचस्प है टैक्स्टौराइन के साथ उपरोक्त नृत्यों के बिना - xtrabackup का उपयोग करके आधार स्नैपशॉट का निर्माण।

आप एक ही बार में पूरी मशीन का बैकअप ले सकते हैं!

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

हमने भूमिकाओं को परिभाषित किया: वेब मशीन, DBMS, बैलेंसर, मॉनिटरिंग मशीन, और हमारी बैकअप स्क्रिप्ट कुछ इस तरह से काम करती हैं:

DBMS टैग के साथ एक कार खोजें और इसकी आईडी प्राप्त करें
"फ्रीज" कार के पहिए
एक डिस्क स्नैपशॉट बनाएं । एक स्नैपशॉट टैग "DBMS" सेट करें।
"डीफ्रॉस्ट" कार के पहिये
पुराने स्नैपशॉट को साफ़ करने के लिए, आप टैग और समय के अनुसार चयन कर सकते हैं और अनावश्यक को हटा सकते हैं।

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

ec2-create-image id_of_instance [--no-reboot]
...
ec2-run-instances ami_image_id

फर्क महसूस करो! मैं एक मशीन से 9 डिस्क्स के छापे के साथ एक छवि बनाता हूं - एक कमांड में। और मैं उसके डिस्क और स्नैपशॉट की आईडी के बारे में चिंतित नहीं हूं - मशीन को फिर से बनाने के लिए आवश्यक सभी जानकारी स्वचालित रूप से एएमआई छवि को लिखी गई है। केवल नकारात्मक यह स्पष्ट नहीं है कि एक AMI छवि बनाने के लिए किसी रनिंग मशीन के ड्राइव / छापे को बंद करने में कितना समय लगता है। अनुभवी ने पाया कि 2-5 सेकंड पर्याप्त है - यदि कम है, तो नई मशीन बनाते समय डिस्क / छापे ठीक होने लगते हैं। यह भी बहुत सुविधाजनक है कि आप बैकअप से छवि (एएमआई) तक किसी अन्य डेटा सेंटर (AZ) में कार ले सकते हैं।
अब हम अपने क्लस्टर कॉन्फ़िगरेशन (सैकड़ों गीगाबाइट) की सभी मशीनों की एएमआई छवि के लिए दिन में दो बार बैकअप बनाते हैं। "अप्रचलित" छवियों की सफाई, उनके स्नैपशॉट के साथ, स्क्रिप्ट द्वारा की जाती है:

 function bxc_delete_old_instance_backups( AmazonEC2 $ec2, $instanceRole = '', $bkpsMaxCount = 3) { if (!$instanceRole || !is_object($ec2) || $bkpsMaxCount<1 ) { bxc_log_error("Bad input params: ".__FUNCTION__); return false; } $response = $ec2->describe_images(array( 'Filter' => array( array('Name' => 'tag:Role', 'Value' => 'Image:'.$instanceRole), array('Name' => 'state', 'Value' => 'available'), ) )); if ( !$response->isOK() ) { bxc_log_amazon_error($response, __FUNCTION__.":".__LINE__); return false; } if ( isset($response->body->imagesSet->item) ) { $images = array(); $snaps = array(); foreach ( $response->body->imagesSet->item as $image ) { $images[ (string) $image->name ] = (string) $image->imageId; if ( isset($image->blockDeviceMapping->item) ) { foreach ( $image->blockDeviceMapping->item as $disk ) { $snaps[ (string) $image->name ][] = $disk->ebs->snapshotId; } } } if ($images) { krsort($images); } else { bxc_log("No images with tag:Role=Image:$instanceRole"); return true; } if ( count($images) <= $bkpsMaxCount ) { bxc_log("Nothing to delete"); return true; } $imagesToDelete = array_slice($images, $bkpsMaxCount, count($images)-$bkpsMaxCount, true); foreach ($imagesToDelete as $imageName=>$imageId ) { $r = $ec2->deregister_image($imageId); if ( $r->isOK() ) { bxc_log("Image deleted ok: ".$imageId); sleep(5);//Important. Wait to ami really be deleted ;-) foreach ( $snaps[$imageName] as $snapId ) { $rr = $ec2->delete_snapshot( $snapId ); if ( $rr->isOK() ) { bxc_log("Snapshot deleted ok: ".$snapId); } else { bxc_log_amazon_error($rr, __FUNCTION__); bxc_log_error("Cannot delete snapshot: ".$snapId); } } } else { bxc_log_amazon_error($r, __FUNCTION__); bxc_log_error("Cannot delete image: ".$imageId); } } return true; } else { bxc_log("No images with tag:Role=Image:$instanceRole"); return true; } return false; }

व्यवस्थापक, कंसोल या API

Amazon AWS के पास एक अच्छा प्रशासन क्षेत्र है, लेकिन कई चीजें केवल एपीआई के माध्यम से की जा सकती हैं। लिनक्स के लिए, आप अमेज़ॅन एपीआई के साथ काम करने के लिए कमांड लाइन टूल स्थापित कर सकते हैं, जो बहुत अच्छी तरह से प्रलेखित हैं। हम निम्नलिखित उपकरणों का उपयोग करते हैं:

ls /opt/aws/
AutoScaling-1.0.39.0
ElasticLoadBalancing-1.0.14.3
ec2-api-tools-1.4.4.1
env-set.sh

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

निष्कर्ष

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

हम अमेज़ॅन में "बैकअप" सर्वर कैसे करते हैं और पिरान्हा को बंद करते हैं