मैंने एक विफल-सुरक्षित वेब सेवा कैसे की

प्रस्तावना

इस लेख में, मैं अपने अनुभव को दोष-सहिष्णु वेब सेवा के निर्माण के बारे में बताना चाहता था। मैंने PHP + MySQL (कॉर्पोरेट पोर्टल) में आंतरिक उद्यम प्रबंधन प्रणाली विकसित की है, और चूंकि उद्यम का लगभग पूरा जीवन इस प्रणाली की संचालन क्षमता पर निर्भर करता है, इसलिए दोष सहिष्णुता के मुद्दों का बहुत महत्व है। इसी समय, उद्यम छोटा है, इसलिए यह महंगा लोहा और प्रौद्योगिकी बर्दाश्त नहीं कर सकता है, और यहां तक ​​कि कई घंटों की एक सरल प्रणाली भी इसके लिए घातक नहीं है। इसलिए, मैंने इस समस्या को कम से कम वित्तीय निवेश और अपने दम पर और प्रशासन के क्षेत्र में बहुत कम ज्ञान के साथ हल करने की कोशिश की।

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

कार्य

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

सामान्य समाधान योजना

इसलिए, अपने सिस्टम को बनाने के लिए, मैंने निम्न कॉन्फ़िगरेशन वाली 2 कम-लागत वाली सिस्टम इकाइयाँ खरीदीं (कुल लागत 30 टन से थोड़ी अधिक थी):

• चटाई। ASUS सॉकेट 775 P5Q-VM DO
• इंटेल प्रोसेसर "कोर 2 डुओ E8400"
• RAM DIMM DDR2 (6400) 2048Mb x 2
• हार्ड ड्राइव 320Gb WD SATA-II 7200rpm 16Mb, RAID संस्करण
• मुख्य सर्वर में, मैंने 1 अतिरिक्त नेटवर्क कार्ड डाला, और उप-सर्वर में - 2. नेटवर्क कार्ड इंटेल कॉर्पोरेशन 82541PI गिगाबिट ईथरनेट कंट्रोलर।

यह 2 नेटवर्क इंटरफेस के साथ मुख्य सर्वर और 3 नेटवर्क इंटरफेस के साथ दास सर्वर निकला।

जिस प्लेटफ़ॉर्म पर कॉर्पोरेट पोर्टल चलता है, मैं उबंटू लिनक्स 8.04.4 पर आधारित LAMP का उपयोग करता हूं, जो VMWare वर्चुअल मशीन के रूप में चलता है। वास्तव में, मैं LAMP की स्थापना के लिए एक महान विशेषज्ञ नहीं हूं, इसलिए मैं पेशेवरों पर भरोसा करता हूं, और आधार के रूप में तैयार 1C-Bitrix आभासी मशीन ( http://www.1c-bitrix.ru/products/vmbitrix/ ) लेता हूं।

सर्वर पर वर्चुअल मशीन को चलाने के लिए, मैं मुफ्त VMware vSphere HypervisorTM (ESXi) v को स्थापित करने के विकल्प पर बस गया। 4.1 नंगे धातु, जो दोनों सर्वरों पर पहली चीज स्थापित की गई थी। यह हाइपरविजर एक मिनी-ऑपरेटिंग सिस्टम है, जिसके कार्य वर्चुअल मशीन के प्रबंधन के लिए उबालते हैं। स्थापना समस्याओं के बिना चली गई, हालांकि, जैसा कि मुझे बाद में पता चला, आखिरकार, हार्डवेयर पूरी तरह से ESXi के साथ संगत नहीं था। हालाँकि मैंने इस विषय पर इंटरनेट पर पाई जाने वाली श्वेत सूचियों के सभी घटकों ( http://www.vm-help.com/esx40i/esx40_whitebox_HCL.php और http://ultimatewhitebox.com ) की जाँच की। असंगति इस तथ्य में व्यक्त की गई थी कि ईएसएक्सआई ने सर्वर हार्डवेयर की स्थिति के बारे में नैदानिक ​​जानकारी की एक पूरी श्रृंखला प्रदर्शित नहीं की थी। यह मायने नहीं रखता है, लेकिन फिर भी बहुत अच्छा नहीं है।

तब मैंने LAMP और उसके कॉर्पोरेट पोर्टल के साथ समान रूप से कॉन्फ़िगर की गई आभासी मशीनों के लिए दोनों सर्वरों की नकल की। फिर ESXi में नेटवर्क इंटरफेस सेट करें। मुख्य सर्वर पर (केवल 2 LAN- इंटरफ़ेस): 1 नेटवर्क इंटरफ़ेस को ESXi तक पहुंच के लिए कॉन्फ़िगर किया गया है और दोनों एक वर्चुअल मशीन से "बंधे" हैं। और दास पर (केवल 3 LAN- इंटरफेस): 1 इंटरफ़ेस - ESXi तक पहुंच के लिए, और 2 अन्य वर्चुअल मशीन से "संलग्न"।

वर्चुअल मशीनों से बंधे नेटवर्क इंटरफेस के माध्यम से एक केबल सीधे दोनों सर्वरों से जुड़ा हुआ है। वर्चुअल मशीनों में, इन नेटवर्क इंटरफेस (मास्टर के लिए 10.10.10.2 और दास के लिए 10.10.10.3) को ग्राहक के लैन (172.20.15.0-255) के अलावा एक सबनेट से असाइन किया गया। सर्वर के बीच यह सीधा संबंध केवल एक दूसरे के साथ दो सर्वरों की वर्चुअल मशीनों के "संचार" के लिए है, अर्थात् MySQL डेटा की प्रतिकृति और स्क्रिप्ट के साथ फ़ोल्डरों को सिंक्रनाइज़ करने के लिए।

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

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

इस प्रकार, सामान्य सर्वर में सिस्टम संचालन की निम्न योजनाएं और मुख्य सर्वर की विफलता पर प्राप्त की गई थीं:

अब बारीकियों के बारे में थोड़ा।

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

MySQL प्रतिकृति स्थिति की निगरानी।

काम पर, मैं आसानी से देखना चाहता था कि क्या प्रतिकृति बाधित हुई थी। हर बार, ESXi में कंसोल के माध्यम से या मास्टर सर्वर के माध्यम से अधीनस्थ उत्तर तक पहुंचना थका देता है। इस समस्या को हल करने के लिए, मैंने एक स्क्रिप्ट PHP (checklave.php) में दास सर्वर पर कॉपी की, जिसका मुख्य कार्य MASTER और SLAVE से प्रतिकृति स्थिति प्राप्त करना और उन्हें एक तालिका में प्रदर्शित करना है। मास्टर सर्वर दास से पूछताछ नहीं कर सकता, क्योंकि MySQL में, उसके पास कोई अधिकार नहीं है, अधीनस्थ को मुख्य चीज़ तक पहुंचने का अधिकार है, लेकिन इसके विपरीत नहीं। कमांड निष्पादित करके स्थिति प्राप्त की जाती है:
SHOW SLAVE STATUS
और
SHOW MASTER STATUS

क्योंकि उपयोगकर्ताओं के पास केवल मुख्य तक पहुंच है, इस पर मैंने क्रोन में कमांड जोड़ा:
wget --no-check-certificate 10.10.10.3/checkslave.php -O /var/www/checkslave.html wget --no-check-certificate 10.10.10.3/checkslave.php -O /var/www/checkslave.html , जो स्लेव सर्वर से checklave.php का अनुरोध करता है और मेन सर्वर पर html फाइल में इसका आउटपुट सेव करता है। तदनुसार, आप इस फ़ाइल को ब्राउज़र में मुख्य सर्वर पर देख सकते हैं और देख सकते हैं कि क्या प्रतिकृति के साथ कोई समस्या है।

प्रतिकृति तोड़ सुरक्षा।

जैसा कि मैं काम कर रहा था, मैं इस तथ्य पर आया था कि दास सर्वर पर चल रहे किसी भी SQL परिवर्तन अनुरोध के दौरान प्रतिकृति आसानी से टूट गई थी। यह तुरंत अद्वितीय कुंजियों में डुप्लिकेट के निर्माण का कारण बना और सामान्य तौर पर, डेटा असंगति के लिए। उस पर कॉर्पोरेट पोर्टल में प्रवेश करने के लिए पर्याप्त था और प्रतिकृति बाधित हो गई थी। प्रतिकृति को अधिक विश्वसनीय बनाने के लिए, मैंने निम्नलिखित को जोड़ा। दास सर्वर पर, मैंने दो PHP स्क्रिप्ट्स को जोड़ा: एक ने MySQL उपयोगकर्ता को परिवर्तनों का अधिकार दिया, जिसके तहत कॉर्पोरेट पोर्टल स्क्रिप्ट काम करते हैं, और दूसरे ने SQL GRANT और REVOKE का उपयोग करके इन अधिकारों को हटा लिया। नियंत्रण स्क्रिप्ट स्वयं एक अलग उपयोगकर्ता के तहत MySQL से जुड़ी होती हैं, उसी स्क्रिप्ट के तहत जैसे मास्टर और स्लेव की स्थिति को मतदान करती है।

फिर मैंने एक छोटी सी स्क्रिप्ट लिखी जो यह जांचती है कि स्लेव सर्वर का मास्टर सर्वर के साथ क्या संबंध है और तदनुसार परिवर्तन के लिए स्लेव सर्वर डेटाबेस को खोलने / बंद करने के लिए स्क्रिप्ट चलाता है। स्क्रिप्ट हर 5 मिनट पर शेड्यूल पर चलती है। तदनुसार, वियोग के 5 मिनट बाद, उपयोगकर्ता दास सर्वर के साथ काम करने में सक्षम होंगे, और यदि कनेक्शन काट नहीं दिया गया है, तो दास सर्वर परिवर्तनों से बंद रहेगा:
#!/bin/bash

count=$(ping -c 8 10.10.10.2 | grep 'received' | awk -F',' '{ print $2 }' | awk '{ print $1 }')
if [ $count -eq 0 ]; then
php -f /folder/slave_open.php
else
php -f /folder/slave_close.php
fi


स्क्रिप्ट सिंक्रनाइज़ेशन।

डेटाबेस सिंक्रोनाइज़ेशन के अलावा, यह महत्वपूर्ण है कि PHP स्क्रिप्ट और अन्य काम करने वाली फाइलें भी दास सर्वर पर तब बदलती हैं जब मास्टर में परिवर्तन किया जाता है। इस समस्या को हल करने के लिए, मैंने एक शेड्यूल पर स्लेव सर्वर में एक कमांड जोड़ा:
rsync -avz 10.10.10.2:/var/www/ /var/www

फाइलों के साथ एक कॉर्पोरेट पोर्टल का काम।

PHP स्क्रिप्ट के अलावा, कॉर्पोरेट पोर्टल उपयोगकर्ता फ़ाइलों का प्रबंधन करता है, जो मास्टर और स्लेव सर्वर दोनों पर भी सुलभ होना चाहिए। इसे संभव बनाने के लिए, मैंने इन फ़ाइलों के भंडारण को विंडोज सर्वर 2008 चलाने वाले एक एंटरप्राइज़ के लिए एक अलग फ़ाइल सर्वर पर रखा। मैंने वहां एक अलग फ़ोल्डर बनाया, एक स्क्रिप्ट लिखी कि दोनों वर्चुअल मशीन जाँचें कि क्या यह फ़ोल्डर माउंटेड डिस्क में है, और यदि नहीं, तो इसे माउंट करता है।
flag=0
mnt_path='/folder'
mnt_test=`mount -t cifs`
flag=`expr match "$mnt_test" '.*folder.*'`
if [ "$flag" = "0" ]
then mount -t cifs -o username=user,password=pass,uid=bitrix,gid=bitrix,iocharset=utf8,codepage=866 //172.20.15.21/portal_folder /folder
fi


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

अंत तक पढ़े तो धन्यवाद!