🚵🏾 🏉 🌰 लगभग 1 सी सर्वर क्लस्टर 🛢️ 👨🏻‍💻 🧑🏻‍🤝‍🧑🏻

एक क्लस्टर समानांतर
या वितरित प्रणाली का एक प्रकार है जो:
1. कई इंटरकनेक्टेड
कंप्यूटर शामिल हैं;
2. एक एकल,
एकीकृत कंप्यूटर संसाधन

ग्रेगरी एफ.फिस्टर के रूप में उपयोग किया जाता है , "समूहों की खोज में"।

यह देखते हुए: एक व्यावसायिक अनुप्रयोग है (उदाहरण के लिए, एक ईआरपी सिस्टम) जिसके साथ हजारों (संभवतः दसियों हजारों) उपयोगकर्ता एक साथ काम करते हैं।

यह आवश्यक है:

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

इन समस्याओं को हल करने के लिए, हम 1C: एंटरप्राइज प्लेटफॉर्म में क्लस्टर आर्किटेक्चर का उपयोग करते हैं।

हम तुरंत वांछित परिणाम तक नहीं पहुंचे।

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

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

विफलता क्लस्टर (हा, उच्च उपलब्धता क्लस्टर)
लोड संतुलन क्लस्टर (LBC)
कम्प्यूटिंग क्लस्टर (उच्च प्रदर्शन कंप्यूटिंग क्लस्टर, एचपीसी)
(grid) , . grid- , . grid- HPC-, .

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

उन लोगों के लिए जो आज तक नहीं हैं, मैं आपको संक्षेप में बताऊंगा कि 1 सी व्यावसायिक अनुप्रयोगों की व्यवस्था कैसे होती है। ये एक विषय-उन्मुख भाषा में लिखे गए अनुप्रयोग हैं , लेखांकन व्यवसाय कार्यों के स्वचालन के लिए "तेज"। इस भाषा में लिखे गए एप्लिकेशन चलाने के लिए, कंप्यूटर पर 1C: एंटरप्राइज प्लेटफॉर्म रनटाइम इंस्टॉल करना होगा।

1C: एंटरप्राइज़ 8.0

प्लेटफ़ॉर्म संस्करण 8.0 में 1 सी एप्लिकेशन सर्वर का पहला संस्करण (अभी तक एक क्लस्टर नहीं) दिखाई दिया। इससे पहले, 1C क्लाइंट-सर्वर संस्करण में काम करता था, डेटा को एक फ़ाइल DBMS या MS SQL में संग्रहीत किया गया था, और व्यावसायिक तर्क क्लाइंट पर विशेष रूप से काम करता था। संस्करण 8.0 में, त्रि-स्तरीय वास्तुकला "क्लाइंट - एप्लिकेशन सर्वर - डीबीएमएस" के लिए एक संक्रमण बनाया गया था।

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

1C: एंटरप्राइज़ 8.1

अगले संस्करण में, हम चाहते थे:

हमारे ग्राहकों को दोष सहिष्णुता प्रदान करें ताकि कुछ उपयोगकर्ताओं की दुर्घटनाओं और त्रुटियों के कारण दुर्घटनाओं और अन्य उपयोगकर्ताओं की त्रुटियां न हों।
COM + तकनीक से छुटकारा पाएं। COM + ने केवल विंडोज पर काम किया, और उस समय लिनक्स के तहत काम करने की संभावना पहले से ही प्रासंगिक होती जा रही थी।

उसी समय, हम मंच के एक नए संस्करण को खरोंच से विकसित नहीं करना चाहते थे - यह बहुत संसाधन-गहन होगा। हम अपनी उपलब्धियों का अधिकतम उपयोग करना चाहते थे, साथ ही संस्करण 8.0 के लिए विकसित अनुप्रयोगों के साथ संगतता बनाए रखना चाहते थे।

तो 8.1 संस्करण में पहला क्लस्टर दिखाई दिया। हमने दूरस्थ प्रक्रिया कॉल (टीसीपी के ऊपर) के लिए अपने प्रोटोकॉल को लागू किया, जो दिखने में लगभग उपभोक्ता-ग्राहक के लिए COM + जैसा दिखता था (यानी, हमें व्यावहारिक रूप से क्लाइंट-सर्वर कॉल के लिए जिम्मेदार कोड को फिर से लिखना नहीं पड़ता था)। उसी समय, हमने C ++ प्लेटफ़ॉर्म में कार्यान्वित सर्वर को स्वतंत्र बना दिया, जो विंडोज़ और लिनक्स दोनों पर काम करने में सक्षम था।

अखंड सर्वर संस्करण 8.0 को 3 प्रकार की प्रक्रियाओं से बदल दिया गया था - एक कार्य प्रक्रिया जो ग्राहकों को सेवा देती है, और 2 सेवा प्रक्रियाएं जो क्लस्टर के संचालन का समर्थन करती हैं:

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

कट के तहत क्लस्टर में इन तीन प्रक्रियाओं का ऑपरेशन आरेख है।

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

1 सी: एंटरप्राइज़ 8.2

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

इस संस्करण ने कई महत्वपूर्ण नवाचारों को भी शुरू किया - सुधार की सहिष्णुता, भार संतुलन, और एक क्लस्टर अतिरेक तंत्र।

दोष सहिष्णुता

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

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

भार संतुलन

हमारे मामले में लोड संतुलन का कार्य निम्नानुसार है: एक नया क्लाइंट सिस्टम में प्रवेश करता है (या पहले से काम कर रहा क्लाइंट एक और कॉल करता है)। हमें क्लाइंट को अधिकतम गति प्रदान करने के लिए क्लाइंट के कॉल को भेजने के लिए कौन सा सर्वर और वर्कफ़्लो चुनना होगा।

यह लोड-संतुलित क्लस्टर के लिए एक मानक कार्य है। इसे हल करने के लिए कई विशिष्ट एल्गोरिदम हैं, उदाहरण के लिए:

Round-Robin () – , , – . . . . , «» . ( ) .
Weighted Round Robin – Round-Robin: , ́ .
Least Connections: , .
Least Response Time: : , .

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

नए क्लाइंट से अनुरोध इस समय सबसे अधिक उत्पादक सर्वर को संबोधित किया जाता है।

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

मौजूदा क्लाइंट का एक अनुरोध दो मामलों में दूसरे वर्कफ़्लो में स्थानांतरित किया जाता है:

कोई और प्रक्रिया नहीं है: जिस वर्कफ़्लो के साथ क्लाइंट ने पहले बातचीत की थी वह अब उपलब्ध नहीं है (प्रक्रिया गिर गई है, सर्वर अनुपलब्ध हो गया है, आदि)।
: , , , , . , , – . – (.. ).

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

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

1 सी: एंटरप्राइज 8.3

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

« »: , , . , «» .
, , .
, , , , , :

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

गलती सहिष्णुता के तीन लिंक

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

, HTTP(S), -. - -. , HTTP -, ( HTTP) libcurl .
, .
- . 1, - . - . , . , – . - (, , , ) – .
, rmngr. 20 ( ) — , .. . 1: .

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

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

संस्करण 8.3 में 1 सी सर्वर क्लस्टर की विश्वसनीयता में काफी वृद्धि हुई है। 1 सी उत्पादों को पेश करना लंबे समय से असामान्य नहीं है, जहां एक साथ काम करने वाले उपयोगकर्ताओं की संख्या कई हजार तक पहुंच जाती है। ऐसे कार्यान्वयन हैं जहां 5,000 और 10,000 उपयोगकर्ता दोनों एक साथ काम करते हैं - उदाहरण के लिए, बीलाइन में परिचय , जहां 1 सी: व्यापार प्रबंधन आवेदन रूस में सभी बीलाइन बिक्री आउटलेट , या माल वाहक में बिजनेस लाइन्स के कार्यान्वयन का कार्य करता है। , जहां 1C पर व्यावसायिक लाइन्स के IT विभाग के डेवलपर्स द्वारा स्वतंत्र रूप से बनाया गया एप्लिकेशन: एंटरप्राइज प्लेटफॉर्म, कार्गो परिवहन का पूरा चक्र प्रदान करता है। हमारे आंतरिक क्लस्टर लोड परीक्षण 20,000 उपयोगकर्ताओं तक एक साथ संचालन का अनुकरण करते हैं।

अंत में, मैं संक्षेप में सूची देना चाहूंगा कि हमारे क्लस्टर में और क्या उपयोगी है (सूची अपूर्ण है):

, . , , .
– , , , ( – , ..) . , , (, ) , ERP, , ERP.
– , (, , ..). , , , , , .

लगभग 1 सी सर्वर क्लस्टर