ईआरपी के लिए सर्वर साइजिंग: इसे सही कैसे करें

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

अधिकांश ईआरपी कार्यान्वयन में दो दिशाओं में से एक में सर्वर का आकार गलत होता है: अति-आत्मविश्वास वाली आईटी टीमें जो ईआरपी की डेटाबेस तीव्रता को ध्यान में रखे बिना "यह सिर्फ एक वेब ऐप है" अंतर्ज्ञान के आधार पर आकार देती हैं, या विक्रेता की सिफारिशें जो उचित लागत पर उचित प्रदर्शन के बजाय किसी भी कीमत पर अधिकतम प्रदर्शन के लिए कैलिब्रेट की जाती हैं।

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

मुख्य बातें

ईआरपी सामान्य वेब अनुप्रयोगों की तुलना में काफी अधिक डेटाबेस-गहन है - मानक वेब सर्वर आकार नियम लागू नहीं होते हैं

सीपीयू शायद ही कभी बाधा है; रैम और डिस्क I/O लगभग हमेशा ERP कार्यभार में बाधा बनते हैं

ओडू को प्रति समवर्ती कार्यकर्ता प्रक्रिया के लिए 2-4 जीबी रैम की आवश्यकता होती है; 50+ उपयोगकर्ताओं वाले उत्पादन उदाहरणों के लिए कम से कम 16 जीबी

अधिकांश सर्वर आकार निर्धारण अभ्यासों में डेटाबेस भंडारण IOPS आवश्यकताओं को नाटकीय रूप से कम करके आंका गया है

क्लाउड इंस्टेंसेस जो कागज पर समान दिखते हैं (समान वीसीपीयू, समान रैम) में काफी भिन्न I/O प्रदर्शन हो सकता है

हमेशा 30-40% हेडरूम के साथ अधिकतम समवर्ती भार (औसत भार नहीं) के लिए आकार

अपने विशिष्ट उपयोगकर्ता संख्या और ईआरपी प्लेटफ़ॉर्म के लिए एक विनिर्देश उत्पन्न करने के लिए ECOSIRE के निःशुल्क सर्वर साइज़िंग कैलकुलेटर का उपयोग करें

ईआरपी सर्वर का आकार अलग क्यों है

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

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

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

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

सत्र स्थिति और कार्यकर्ता प्रक्रियाएं: ओडू विशेष रूप से पायथन कार्यकर्ता प्रक्रियाएं चलाता है जो प्रत्येक सक्रिय उपयोगकर्ता कनेक्शन के लिए सत्र स्थिति बनाए रखता है। प्रत्येक कार्यकर्ता प्रक्रिया स्थिर अवस्था में लगभग 200-400 एमबी रैम और भारी रिपोर्ट निष्पादन के दौरान 1 जीबी तक की खपत करती है। डिस्क पर स्वैप किए बिना सभी सक्रिय श्रमिकों को एक साथ चलाने के लिए सर्वर को पर्याप्त रैम की आवश्यकता होती है - ईआरपी डेटाबेस सर्वर में स्वैपिंग से भयावह प्रदर्शन में गिरावट आती है।

ईआरपी सर्वर आकार में मुख्य चर

चार चर ईआरपी सर्वर संसाधन आवश्यकताओं को किसी भी अन्य की तुलना में अधिक बढ़ाते हैं:

1. समवर्ती उपयोगकर्ता संख्या (कुल उपयोगकर्ता संख्या नहीं)

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

कुल उपयोक्ता संख्या से अधिकतम समवर्ती उपयोक्ताओं का अनुमान लगाना:

सामान्य व्यावसायिक घंटों के साथ कार्यालय-आधारित ईआरपी: कुल उपयोगकर्ताओं में से 15-25% चरम पर समवर्ती हैं
एकाधिक शिफ्ट के साथ विनिर्माण: कुल उपयोगकर्ताओं का 25-35% समवर्ती (शिफ्ट-परिवर्तन शिखर)
समय क्षेत्रों में वितरित संचालन: निम्न शिखर संगामिति लेकिन लंबी शिखर अवधि
महीने के अंत के दौरान वित्त-भारी उपयोग: समाप्ति अवधि के दौरान समवर्ती 40-50% तक अस्थायी वृद्धि

सामान्य कार्यालय-आधारित उपयोग के साथ 100-उपयोगकर्ता ओडू परिनियोजन के लिए, सामान्य चरम पर 15-25 समवर्ती उपयोगकर्ताओं के लिए योजना बनाएं, महीने के अंत के दौरान 40-50 समवर्ती उपयोगकर्ताओं के प्रावधान के साथ। इससे आपके आकार की गणना होनी चाहिए, न कि कुल 100 उपयोगकर्ताओं की।

2. लेन-देन की मात्रा और लेन-देन की जटिलता

उच्च लेन-देन की मात्रा समवर्ती उपयोगकर्ताओं से स्वतंत्र रूप से डेटाबेस राइट लोड को चलाती है। एक वितरण कंपनी जो प्रतिदिन 2,000 खरीद ऑर्डर संसाधित करती है, 100 उपयोगकर्ताओं लेकिन कम लेनदेन मात्रा वाली पेशेवर सेवा फर्म की तुलना में काफी अधिक डेटाबेस राइट I/O उत्पन्न करती है। इसी तरह, जटिल लेनदेन (विनिर्माण कार्य ऑर्डर जो बीओएम खपत, इन्वेंट्री, लागत लेखांकन और गुणवत्ता रिकॉर्ड को एक साथ अपडेट करते हैं) सरल लेनदेन (एक जर्नल प्रविष्टि पोस्टिंग जो दो जी/एल खातों को अपडेट करता है) की तुलना में अधिक I/O उत्पन्न करते हैं।

उपयोग में आने वाले मॉड्यूल के बारे में सोचकर अपने लेनदेन की जटिलता का अनुमान लगाएं: विनिर्माण और मल्टी-वेयरहाउस इन्वेंट्री सबसे जटिल लेनदेन उत्पन्न करती है; सरल लेखांकन और एचआर मॉड्यूल सबसे सरल उत्पन्न करते हैं।

3. डेटाबेस का आकार और विकास दर

डेटाबेस का आकार क्वेरी प्रदर्शन को दो तरीकों से प्रभावित करता है: प्रत्यक्ष रूप से (बड़ी तालिकाओं को स्कैन करने में अधिक समय लगता है) और अप्रत्यक्ष रूप से (उपलब्ध रैम से अधिक काम करने वाले सेट कैश मिस और बढ़े हुए I/O का कारण बनते हैं)।

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

4. एकीकरण और एपीआई कार्यभार

यदि आपका ईआरपी एपीआई (ईकॉमर्स प्लेटफॉर्म, 3पीएल सिस्टम, बैंक एपीआई, मार्केटप्लेस कनेक्टर) के माध्यम से बाहरी सिस्टम से जुड़ता है, तो ये एकीकरण अतिरिक्त सर्वर लोड उत्पन्न करते हैं जो उपयोगकर्ता गणना में प्रतिबिंबित नहीं होते हैं। प्रत्येक एपीआई कॉल ईआरपी की एप्लिकेशन परत और डेटाबेस से होकर गुजरती है - एक उच्च-मात्रा एकीकरण (प्रति घंटे 1,000 ऑर्डर सिंक अनुरोधों को संसाधित करना) 10-20 समवर्ती उपयोगकर्ताओं के लोड से मेल खा सकता है।

प्लेटफ़ॉर्म और उपयोगकर्ता संख्या के आधार पर साइज़िंग दिशानिर्देश

ओडू 19 एंटरप्राइज

Odoo का आर्किटेक्चर कार्यकर्ता प्रक्रियाओं (Odoo Workers) का उपयोग करता है जो प्रत्येक उपयोगकर्ता के अनुरोधों को पूरा करता है। समवर्ती उपयोगकर्ता गणना के साथ आवश्यक पैमाने पर श्रमिकों और सर्वर संसाधनों की संख्या।

ओडू कार्यकर्ता गणना:

अनुशंसित कर्मचारी = (समवर्ती उपयोगकर्ता / 6) + 1, पूर्णांकित
प्रत्येक कर्मचारी को स्थिर अवस्था में लगभग 300-500 एमबी रैम की आवश्यकता होती है, भारी रिपोर्ट के दौरान 1 जीबी तक
क्रॉन कार्यकर्ता (पृष्ठभूमि प्रक्रियाओं के लिए) 2-4 अतिरिक्त कर्मचारी जोड़ते हैं

उपयोगकर्ता संख्या के अनुसार न्यूनतम अनुशंसित विशिष्टताएँ:

कुल उपयोगकर्ता	शिखर समवर्ती	श्रमिक	सीपीयू (कोर)	रैम	एसएसडी भंडारण
10-25	3-6	3	4	8 जीबी	100 जीबी
25-50	6-12	4	4	16 जीबी	200 जीबी
50-100	12-25	6	8	32 जीबी	300 जीबी
100-200	25-50	10	16	64 जीबी	500 जीबी
200-400	50-100	18	32	128 जीबी	1 टीबी
400+	100+	30+	48+	256 जीबी+	2 टीबी+

ओडू साइज़िंग पर महत्वपूर्ण नोट्स:

डेटाबेस (पोस्टग्रेएसक्यूएल) और एप्लिकेशन (ओडू वर्कर प्रोसेस) आदर्श रूप से 100 उपयोगकर्ताओं से ऊपर के अलग-अलग सर्वर पर चलते हैं। एक ही सर्वर पर संयुक्त, डेटाबेस और एप्लिकेशन रैम के लिए प्रतिस्पर्धा करते हैं।
PostgreSQL साझा मेमोरी (प्रभावी_कैश_आकार) को डेटाबेस सर्वर रैम के 50-75% पर सेट किया जाना चाहिए।
PostgreSQL डेटा डायरेक्टरी के लिए SSD स्टोरेज अनिवार्य है - स्पिनिंग डिस्क किसी भी ERP डेटाबेस पर विनाशकारी प्रदर्शन का कारण बनती है।
50 से अधिक उपयोगकर्ताओं की तैनाती के लिए ओडू सत्र भंडारण के लिए एक अलग रेडिस सर्वर की सिफारिश की जाती है।

माइक्रोसॉफ्ट डायनेमिक्स 365 बिजनेस सेंट्रल

SaaS परिनियोजन मॉडल का उपयोग करते समय बिजनेस सेंट्रल को Microsoft Azure इंफ्रास्ट्रक्चर पर क्लाउड-होस्ट किया जाता है - इस मामले में, सर्वर आकार का प्रबंधन Microsoft द्वारा किया जाता है। ऑन-प्रिमाइसेस तैनाती के लिए:

कुल उपयोगकर्ता	शिखर समवर्ती	सीपीयू (कोर)	रैम	एसक्यूएल सर्वर रैम	भंडारण
10-25	3-6	4	16 जीबी	8 जीबी	150 जीबी
25-75	6-18	8	32 जीबी	16 जीबी	300 जीबी
75-150	18-37	16	64 जीबी	32 जीबी	500 जीबी
150-300	37-75	32	128 जीबी	64 जीबी	1 टीबी

बिजनेस सेंट्रल ऑन-प्रिमाइसेस डेटाबेस के रूप में SQL सर्वर का उपयोग करता है, जिसमें PostgreSQL से एक अलग मेमोरी प्रबंधन मॉडल है। SQL सर्वर के बफ़र पूल में समर्पित RAM आवंटित करें (max server memory सेटिंग के माध्यम से) - डेटाबेस सर्वर RAM का लगभग 75%।

एसएपी बिजनेस वन

एसएपी बिजनेस वन को ऑन-प्रिमाइसेस (विंडोज या हाना) या एसएपी बिजनेस वन क्लाउड पर तैनात किया गया है:

कुल उपयोगकर्ता	शिखर समवर्ती	सीपीयू	राम (एसएपी हाना)	रैम (एसक्यूएल सर्वर)	भंडारण
25 तक	6-10	8 कोर	64 जीबी	32 जीबी	500 जीबी
25-75	15-25	16 कोर	128 जीबी	64 जीबी	1 टीबी
75-150	25-50	32 कोर	256 जीबी	128 जीबी	2 टीबी

SAP HANA (SAP Business One HANA संस्करण के साथ उपयोग किया जाने वाला इन-मेमोरी डेटाबेस) में पारंपरिक डिस्क-आधारित डेटाबेस की तुलना में बहुत अधिक RAM आवश्यकताएं हैं क्योंकि कार्यशील सेट को मेमोरी में फिट होना चाहिए। HANA के लिए RAM आवश्यकताएँ गैर-परक्राम्य हैं - HANA जिसकी मेमोरी ख़त्म हो जाती है क्रैश नहीं होती, ख़राब नहीं होती।

क्लाउड इंस्टेंस अनुशंसाएँ

AWS, Azure, या GCP पर स्वयं-होस्टिंग ERP करते समय, सही इंस्टेंस प्रकार का चयन महत्वपूर्ण रूप से मायने रखता है। समान वीसीपीयू और रैम गणना वाले सभी उदाहरण डेटाबेस वर्कलोड के लिए समान रूप से प्रदर्शन नहीं करते हैं।

Odoo के लिए AWS अनुशंसाएँ (संयुक्त ऐप+डीबी, 100 से कम उपयोगकर्ता):

t3.xlarge (4 वीसीपीयू, 16 जीबी): विकास और छोटा उत्पादन (25 उपयोगकर्ताओं से कम)
r6i.xlarge (4 वीसीपीयू, 32 जीबी): लघु-मध्यम उत्पादन (25-50 उपयोगकर्ता)
r6i.2xlarge (8 वीसीपीयू, 64 जीबी): मध्यम उत्पादन (50-100 उपयोगकर्ता)
r6i.4xlarge (16 वीसीपीयू, 128 जीबी): बड़ा उत्पादन (100-200 उपयोगकर्ता, संयुक्त)

Odoo के लिए AWS अनुशंसाएँ (स्प्लिट ऐप/डीबी, 100+ उपयोगकर्ता):

एप्लिकेशन सर्वर: c6i.2xlarge (8 वीसीपीयू, 16 जीबी) - गणना-अनुकूलित
डेटाबेस सर्वर: r6i.4xlarge (16 वीसीपीयू, 128 जीबी) - मेमोरी-अनुकूलित
डेटाबेस भंडारण: io2 EBS वॉल्यूम (प्रावधानित IOPS) - 3,000-6,000 IOPS प्रावधानित

एज़्योर समकक्ष:

एप्लिकेशन सर्वर: Standard_F8s_v2 (8 वीसीपीयू, 16 जीबी)
डेटाबेस सर्वर: Standard_E16s_v5 (16 वीसीपीयू, 128 जीबी)

जीसीपी समकक्ष:

एप्लिकेशन सर्वर: c2-standard-8 (8 वीसीपीयू, 32 जीबी)
डेटाबेस सर्वर: n2-highmem-16 (16 वीसीपीयू, 128 जीबी)

I/O प्रदर्शन जाल: AWS पर मानक EBS gp3 वॉल्यूम डिफ़ॉल्ट रूप से 3,000 IOPS प्रदान करते हैं। 50+ समवर्ती उपयोगकर्ताओं वाले उत्पादन ईआरपी डेटाबेस के लिए, यह अक्सर अपर्याप्त होता है - विशेष रूप से महीने के अंत में जब कई जटिल रिपोर्ट एक साथ चलती हैं। डेटाबेस भंडारण के लिए io2 प्रावधानित IOPS वॉल्यूम का उपयोग करें, जिसमें न्यूनतम 3,000 IOPS का प्रावधान हो। लागत अंतर महत्वपूर्ण है (gp3 के लिए $0.065/GB/माह बनाम io2 के लिए $0.125/GB/माह प्लस प्रावधानित IOPS के लिए $0.065/IOPS/माह), लेकिन प्रदर्शन अंतर भी महत्वपूर्ण है।

उच्च उपलब्धता वास्तुकला

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

Odoo के लिए न्यूनतम HA आर्किटेक्चर (100+ उपयोगकर्ता):

लोड बैलेंसर के पीछे दो एप्लिकेशन सर्वर (राउंड-रॉबिन या स्टिकी सत्र)
स्टैंडबाय प्रतिकृति के साथ PostgreSQL प्राथमिक डेटाबेस (स्ट्रीमिंग प्रतिकृति या AWS RDS मल्टी-एज़ेड का उपयोग करके)
सत्र भंडारण के लिए रेडिस क्लस्टर (दो नोड्स)।
ओडू के फ़ाइल अनुलग्नक डेटा के लिए साझा फ़ाइल संग्रहण (एडब्ल्यूएस ईएफएस या समकक्ष)।

यह आर्किटेक्चर मैन्युअल हस्तक्षेप की आवश्यकता के बिना किसी भी सर्वर विफलता के खिलाफ लचीलापन प्रदान करता है। प्राथमिक PostgreSQL से स्टैंडबाय तक फ़ेलओवर स्वचालित है (पैट्रोनी या AWS RDS का उपयोग करके) और आमतौर पर 30-60 सेकंड में पूरा हो जाता है।

विशिष्ट ईआरपी के लिए आरपीओ और आरटीओ लक्ष्य:

पुनर्प्राप्ति बिंदु उद्देश्य (अधिकतम डेटा हानि): 5 मिनट (सिंक्रोनस प्रतिकृति के साथ) से 30 मिनट (एसिंक प्रतिकृति के साथ)
पुनर्प्राप्ति समय उद्देश्य (अधिकतम डाउनटाइम): स्वचालित विफलता के लिए 30-60 सेकंड, मैन्युअल पुनर्प्राप्ति के लिए 15-30 मिनट

ECOSIRE सर्वर साइज़िंग कैलकुलेटर का उपयोग करना

ECOSIRE का निःशुल्क सर्वर साइज़िंग कैलकुलेटर /टूल्स/सर्वर-साइज़िंग-कैलकुलेटर ऊपर वर्णित गणना प्रक्रिया को स्वचालित करता है। इनपुट:

ईआरपी प्लेटफ़ॉर्म चयन
कुल उपयोक्ता संख्या
चरम समवर्ती उपयोगकर्ता प्रतिशत (या उपयोग के मामले के आधार पर स्वचालित अनुमान)
लेन-देन की मात्रा (कम, मध्यम, उच्च, बहुत अधिक)
एकीकरण गणना और मात्रा (कोई नहीं, बुनियादी, मध्यम, गहन)
उपलब्धता आवश्यकताएँ (एकल सर्वर, HA, आपदा पुनर्प्राप्ति)
क्लाउड प्रदाता प्राथमिकता (AWS, Azure, GCP, या ऑन-प्रिमाइसेस)

आउटपुट:

एप्लिकेशन और डेटाबेस स्तरों के लिए अनुशंसित सर्वर विनिर्देश
आपके पसंदीदा प्रदाता के लिए विशिष्ट क्लाउड इंस्टेंस अनुशंसाएँ
मासिक बुनियादी ढांचा लागत अनुमान
तीन साल का विकास अनुमान दिखा रहा है कि आपको कब अपग्रेड करने की आवश्यकता होगी
भंडारण IOPS आवश्यकताएँ और अनुशंसित भंडारण स्तर

कैलकुलेटर को दर्जनों ग्राहक कार्यान्वयनों में ECOSIRE के स्वयं के उत्पादन परिनियोजन डेटा के अनुसार कैलिब्रेट किया गया है, जो अकेले विक्रेता दस्तावेज़ीकरण की तुलना में अनुमानों को अधिक विश्वसनीय बनाता है।

अक्सर पूछे जाने वाले प्रश्न

यदि हमने पहले कभी ईआरपी का उपयोग नहीं किया है तो मैं अधिकतम समवर्ती उपयोगकर्ताओं का अनुमान कैसे लगा सकता हूं?

बिना किसी ऐतिहासिक डेटा वाले ग्रीनफ़ील्ड कार्यान्वयन के लिए, सामान्य कार्यालय-आधारित तैनाती के लिए शुरुआती अनुमान के रूप में कुल उपयोगकर्ताओं के 20% का उपयोग करें। यदि आपके पास कई शिफ्ट हैं या आप कई समय क्षेत्रों में काम करते हैं, तो 25-30% का उपयोग करें। फिर पहले दो वर्षों में विकास के लिए 50% हेडरूम जोड़ें। सामान्य कार्यालय समय के साथ 100-उपयोगकर्ता ईआरपी के लिए, सामान्य चरम पर 20 समवर्ती उपयोगकर्ताओं के लिए योजना बनाएं, 30 के लिए प्रावधान करें, और बुनियादी ढांचे में बदलाव के बिना 40 तक पहुंचने की क्षमता का निर्माण करें। यह हेडरूम दृष्टिकोण प्रदर्शन समस्याओं से बचाता है क्योंकि लाइव होने के बाद के महीनों में गोद लेने में सुधार होता है।

क्या हमें ओडू एप्लिकेशन और डेटाबेस को एक ही सर्वर या अलग सर्वर पर चलाना चाहिए?

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

ओडू डेटाबेस के लिए हमें किस भंडारण प्रकार का उपयोग करना चाहिए?

PostgreSQL डेटा निर्देशिका के लिए SSD भंडारण अनिवार्य है - स्पिनिंग डिस्क (HDD) किसी भी उत्पादन ERP डेटाबेस पर अस्वीकार्य प्रदर्शन उत्पन्न करती है। यदि आपके पास 50 से अधिक समवर्ती उपयोगकर्ता हैं, तो क्लाउड प्लेटफ़ॉर्म पर, डेटाबेस स्टोरेज के लिए प्रावधानित IOPS SSD (AWS io2, Azure प्रीमियम SSD v2, GCP एक्सट्रीम पर्सिस्टेंट डिस्क) का उपयोग करें। सामान्य प्रयोजन SSD (AWS gp3, Azure मानक SSD) 25 समवर्ती उपयोगकर्ताओं के अंतर्गत विकास और छोटे उत्पादन परिनियोजन के लिए स्वीकार्य है।

हमें अपने सर्वर के आकार में कितनी गुंजाइश बनानी चाहिए?

सामान्य संचालन के लिए अपने अपेक्षित पीक लोड से 30-40% हेडरूम बनाएं, और महीने के अंत या पीक बिक्री सीज़न जैसी असाधारण अवधि के लिए 100% हेडरूम (प्रभावी रूप से पीक क्षमता से दोगुना) बनाएं। क्लाउड परिनियोजन उस क्षमता के लिए स्थायी रूप से भुगतान किए बिना असाधारण अवधि को संभालने के लिए ऑटो-स्केलिंग का उपयोग कर सकता है - निश्चित ऑन-प्रिमाइसेस बुनियादी ढांचे पर एक महत्वपूर्ण लागत लाभ।

अगले चरण

अपने विशिष्ट परिनियोजन के लिए एक विनिर्देश उत्पन्न करने के लिए /tools/server-seasing-calculator पर ECOSIRE के निःशुल्क सर्वर साइज़िंग कैलकुलेटर का उपयोग करें। कैलकुलेटर एक AWS/Azure/GCP इंस्टेंस अनुशंसा और एक मासिक बुनियादी ढाँचा लागत अनुमान आउटपुट करता है जिसका उपयोग आप बजट योजना के लिए कर सकते हैं।

यदि आप Odoo कार्यान्वयन की योजना बना रहे हैं और चाहते हैं कि ECOSIRE कार्यान्वयन के साथ-साथ बुनियादी ढांचे के आकार और सेटअप को भी संभाले, तो बुनियादी ढांचे की योजना प्रत्येक ECOSIRE कार्यान्वयन कार्य में शामिल है।

Server Sizing for ERP: How to Get It Right