ERP کے لیے سرور کا سائز: اسے صحیح طریقے سے کیسے حاصل کیا جائے۔

ERP کے لیے سرور کا سائز ان فیصلوں میں سے ایک ہے جو تکنیکی محسوس ہوتا ہے لیکن اس کے اہم کاروباری نتائج ہوتے ہیں۔ آپ کے سرور کا سائز کم ہو جاتا ہے اور آپ کو پہلے دن سے کارکردگی کی شکایات موصول ہوتی ہیں — سست صفحہ لوڈ، زیادہ استعمال کے دوران ٹائم آؤٹ، اور ڈیٹا بیس کے تعطل اس کا سائز زیادہ ہے اور آپ بنیادی ڈھانچے پر ضرورت سے زیادہ خرچ کرتے ہیں جو زیادہ تر بیکار بیٹھا ہے۔

زیادہ تر ERP کے نفاذ سے سرور کا سائز دو میں سے ایک سمت میں غلط ہو جاتا ہے: حد سے زیادہ پراعتماد IT ٹیمیں جو ERP کے ڈیٹا بیس کی شدت کا حساب لگائے بغیر "یہ صرف ایک ویب ایپ ہے" کے وجدان کی بنیاد پر سائز کرتی ہیں، یا وینڈر کی سفارشات جو مناسب قیمت پر مناسب کارکردگی کے بجائے کسی بھی قیمت پر زیادہ سے زیادہ کارکردگی کے لیے کیلیبریٹ کی جاتی ہیں۔

یہ گائیڈ آپ کو ERP کی تعیناتیوں کے لیے سرور کے سائز کو ترتیب دینے کے لیے ایک منظم طریقہ فراہم کرتا ہے: کلیدی متغیرات جو وسائل کی ضروریات کو چلاتے ہیں، مختلف صارف شماروں پر بڑے ERP پلیٹ فارمز کے لیے مخصوص سائز کے رہنما خطوط، اور اپنی مخصوص صورت حال کو ماڈل کرنے کے لیے ECOSIRE کے مفت سرور سائزنگ کیلکولیٹر کا استعمال کیسے کریں۔

اہم ٹیک ویز

• ERP عام ویب ایپلیکیشنز کے مقابلے میں نمایاں طور پر زیادہ ڈیٹا بیس پر مشتمل ہے - معیاری ویب سرور کے سائز کے اصول لاگو نہیں ہوتے ہیں۔
• سی پی یو شاذ و نادر ہی رکاوٹ ہے۔ RAM اور ڈسک I/O تقریبا ہمیشہ ERP کام کے بوجھ میں رکاوٹ ہیں۔
• Odoo کو 2-4 GB ریم کی فی کنکرنٹ ورکر عمل درکار ہے۔ 50+ صارفین کے ساتھ پیداواری مثالوں کے لیے کم از کم 16 GB
• ڈیٹا بیس اسٹوریج IOPS کی ضروریات کو زیادہ تر سرور سائز کرنے کی مشقوں میں ڈرامائی طور پر کم سمجھا جاتا ہے
• کلاؤڈ مثالیں جو کاغذ پر مساوی نظر آتی ہیں (ایک ہی vCPU، ایک ہی RAM) کی I/O کارکردگی کافی مختلف ہو سکتی ہے۔
• 30-40% ہیڈ روم کے ساتھ چوٹی کنکرنٹ بوجھ (اوسط بوجھ نہیں) کے لیے ہمیشہ سائز
• اپنے مخصوص صارف کی گنتی اور ERP پلیٹ فارم کے لیے تفصیلات تیار کرنے کے لیے ECOSIRE کا مفت سرور سائزنگ کیلکولیٹر استعمال کریں۔

---

ERP سرور کا سائز مختلف کیوں ہے۔

مخصوص سفارشات میں غوطہ لگانے سے پہلے، یہ سمجھنے کے قابل ہے کہ ERP سرور کے سائز کو ایک عام ویب ایپلیکیشن کے لیے سائز کرنے سے زیادہ محتاط تجزیہ کی ضرورت کیوں ہے۔

ڈیٹا بیس کی شدت: ERP سسٹم بنیادی طور پر ٹرانزیکشن پروسیسنگ سسٹم ہیں۔ صارف کا ہر عمل — خریداری کا آرڈر بنانا، انوائس پوسٹ کرنا، انوینٹری کو منتقل کرنا — متعدد ڈیٹا بیس رائٹ تیار کرتا ہے جس کا ارتکاب ایٹمی طور پر ہونا چاہیے۔ ڈیٹا بیس کی پرت بڑے، نارملائزڈ اسکیموں میں پیچیدہ متعلقہ سوالات کو ہینڈل کرتی ہے، اکثر متعدد ٹیبل جوائن اور مجموعی حسابات کے ساتھ۔ یہ مواد کے نظم و نسق کے نظام یا مارکیٹنگ کی ویب سائٹ سے بہت مختلف ہے، جو فی صفحہ منظر کے لیے چند غیر معمولی جدولوں سے پڑھ سکتی ہے۔

کنکرنٹ یوزر لوڈ پیٹرن: ERP صارف کا رویہ عام ویب ایپلیکیشنز سے زیادہ ہم آہنگ ہے۔ صارفین کی ویب سائٹ میں، صارفین غیر معمولی بات چیت کے ساتھ آزادانہ طور پر براؤز کرتے ہیں۔ ایک ERP سسٹم میں، ایک ہی ڈیپارٹمنٹ میں متعدد صارفین بیک وقت آرڈرز پر کارروائی کر سکتے ہیں چوٹی کے اوقات میں (ماہ کے آخر میں، دن کے آخر میں، شفٹ کلوز)۔ یہ سمورتی تحریری نمونہ ڈیٹا بیس لاک تنازعہ پیدا کرتا ہے جس کا سامنا ایک عام ویب ایپلیکیشن کبھی نہیں کرتا۔

رپورٹ جنریشن ورک لوڈ: ERP رپورٹس — خاص طور پر مالیاتی رپورٹس، انوینٹری کی عمر، اور ڈیمانڈ کی پیشن گوئی — پیچیدہ، ملٹی ٹیبل سوالات پر عمل درآمد کریں جو 30-120 سیکنڈ تک چل سکتے ہیں اور عمل درآمد کے دوران اہم CPU اور I/O استعمال کر سکتے ہیں۔ جب مالیاتی عملے کے تین ارکان ایک ساتھ مہینے کے آخر کی قریبی رپورٹیں چلاتے ہیں، تو اس کے نتیجے میں بوجھ میں اضافہ شدید ہو سکتا ہے۔

سیشن کی حالت اور کارکن کے عمل: Odoo خاص طور پر Python کارکن کے عمل کو چلاتا ہے جو ہر ایک فعال صارف کنکشن کے لیے سیشن کی حالت کو برقرار رکھتا ہے۔ ہر کارکن کا عمل تقریباً 200–400 MB RAM کو مستحکم حالت میں اور بھاری رپورٹ کے عمل کے دوران 1 GB تک استعمال کرتا ہے۔ سرور کو تمام فعال کارکنوں کو بیک وقت چلانے کے لیے کافی ریم کی ضرورت ہوتی ہے بغیر ڈسک پر تبادلہ کیے — ERP ڈیٹا بیس سرور میں تبادلہ کارکردگی کو تباہ کن انحطاط کا باعث بنتا ہے۔

---

ERP سرور کے سائز میں کلیدی متغیرات

چار متغیرات ERP سرور کے وسائل کی ضروریات کو دوسروں سے زیادہ چلاتے ہیں:

1۔ ایک ساتھ استعمال کنندگان کی تعداد (مجموعی صارف کی تعداد نہیں)

کل صارفین کی تعداد وسائل کی ضروریات کا ناقص پیش گو ہے۔ صحیح میٹرک چوٹی کے ہم آہنگ صارفین ہیں: ان صارفین کی تعداد جو دن کے مصروف ترین عرصے کے دوران ایک ہی وقت میں سسٹم سے فعال طور پر درخواستیں کر رہے ہیں۔

مجموعی صارف کی تعداد سے چوٹی کے ہم آہنگ صارفین کا تخمینہ لگانا:

• دفتر پر مبنی ERP معمول کے کاروباری اوقات کے ساتھ: کل صارفین کا 15-25% عروج پر ہیں
• متعدد شفٹوں کے ساتھ مینوفیکچرنگ: کل صارفین کا 25-35% ایک ساتھ (شفٹ تبدیلی کی چوٹیوں)
• ٹائم زونز میں تقسیم شدہ آپریشنز: کم چوٹی ہم آہنگی لیکن زیادہ چوٹی کا دورانیہ
• مہینے کے آخر کے دوران مالیاتی بھاری استعمال: قریبی ادوار کے دوران 40-50% تک عارضی اضافہ

عام آفس پر مبنی استعمال کے ساتھ 100 یوزر Odoo کی تعیناتی کے لیے، عام چوٹی پر 15-25 ہم وقت استعمال کرنے والوں کے لیے منصوبہ بنائیں، جس میں مہینے کے آخر میں 40-50 کنکرنٹ کا انتظام ہے۔ یہ آپ کے سائز کے حساب کتاب کو چلانا چاہیے، نہ کہ کل 100 صارفین۔

2۔ لین دین کا حجم اور لین دین کی پیچیدگی

اعلی لین دین والیوم ڈیٹا بیس کو ہم آہنگی استعمال کرنے والوں سے آزادانہ طور پر لوڈ لکھتے ہیں۔ ایک ڈسٹری بیوشن کمپنی جو یومیہ 2,000 خریداری کے آرڈرز پر کارروائی کرتی ہے وہ 100 صارفین کے ساتھ پیشہ ورانہ خدمات کی فرم کے مقابلے میں نمایاں طور پر زیادہ ڈیٹا بیس رائٹ I/O تیار کرتی ہے لیکن لین دین کا حجم کم ہے۔ اسی طرح، پیچیدہ لین دین (مینوفیکچرنگ ورک آرڈرز جو کہ BOM کی کھپت، انوینٹری، لاگت اکاؤنٹنگ، اور کوالٹی ریکارڈز کو بیک وقت اپ ڈیٹ کرتے ہیں) سادہ لین دین سے زیادہ I/O پیدا کرتے ہیں (ایک جرنل انٹری پوسٹنگ جو دو G/L اکاؤنٹس کو اپ ڈیٹ کرتی ہے)۔

استعمال میں آنے والے ماڈیولز کے بارے میں سوچ کر اپنے لین دین کی پیچیدگی کا اندازہ لگائیں: مینوفیکچرنگ اور ملٹی ویئر ہاؤس انوینٹری انتہائی پیچیدہ لین دین پیدا کرتی ہے۔ سادہ اکاؤنٹنگ اور HR ماڈیول سب سے آسان پیدا کرتے ہیں۔

**3۔ ڈیٹا بیس کا سائز اور شرح نمو **

ڈیٹا بیس کا سائز استفسار کی کارکردگی کو دو طریقوں سے متاثر کرتا ہے: براہ راست (بڑی ٹیبلز کو اسکین کرنے میں زیادہ وقت لگتا ہے) اور بالواسطہ (کام کرنے والے سیٹ جو دستیاب RAM سے زیادہ ہوتے ہیں کیشے کی کمی اور I/O میں اضافہ ہوتا ہے)۔

زیادہ تر IT ٹیموں کی توقع سے زیادہ ERP ڈیٹا بیس تیزی سے بڑھتے ہیں۔ 20 جی بی کا ایک ابتدائی ڈیٹا بیس دو سے تین سالوں میں 100 جی بی تک پہنچ سکتا ہے جس میں لین دین کی تاریخ، دستاویز کے اٹیچمنٹس اور آڈٹ لاگز سے معمول کی ترقی ہوتی ہے۔ اپنے اسٹوریج کو تین سال کی متوقع نمو کے لیے سائز دیں، نہ کہ صرف موجودہ ضروریات۔

4۔ انضمام اور API کام کا بوجھ

اگر آپ کا ERP API (ای کامرس پلیٹ فارم، 3PL سسٹم، بینک APIs، مارکیٹ پلیس کنیکٹرز) کے ذریعے بیرونی سسٹمز سے جڑتا ہے، تو یہ انضمام اضافی سرور بوجھ پیدا کرتا ہے جو صارف کی تعداد میں ظاہر نہیں ہوتا ہے۔ ہر API کال ERP کی ایپلیکیشن لیئر اور ڈیٹا بیس سے گزرتی ہے — ایک اعلی حجم کا انضمام (فی گھنٹہ 1,000 آرڈر کی مطابقت پذیری کی درخواستوں پر کارروائی) 10-20 ہم آہنگ صارفین کے بوجھ سے مماثل ہو سکتا ہے۔

---

پلیٹ فارم اور صارف کی تعداد کے لحاظ سے سائز سازی کے رہنما خطوط

اوڈو 19 انٹرپرائز

اوڈو کا فن تعمیر کارکن کے عمل (اوڈو ورکرز) کا استعمال کرتا ہے جو ہر صارف کی درخواست کرتا ہے۔ کارکنوں کی تعداد اور سرور کے وسائل کے لیے ہم وقتی صارف کی تعداد کے ساتھ پیمانے کی ضرورت ہے۔

اوڈو ورکر کیلکولیشن:

• تجویز کردہ کارکنان = (ایک ساتھ استعمال کنندہ / 6) + 1، راؤنڈ اپ
• ہر کارکن کو مستحکم حالت میں تقریباً 300-500 MB RAM کی ضرورت ہوتی ہے، بھاری رپورٹس کے دوران 1 GB تک
• کرون ورکرز (پس منظر کے عمل کے لیے) 2-4 اضافی کارکن شامل کریں۔

صارف کی تعداد کے لحاظ سے کم از کم تجویز کردہ وضاحتیں:

اوڈو سائزنگ پر اہم نوٹ:

• ڈیٹا بیس (پوسٹگری ایس کیو ایل) اور ایپلیکیشن (اوڈو ورکر پروسیس) مثالی طور پر 100 سے زیادہ صارفین کے الگ الگ سرورز پر چلتے ہیں۔ ایک سرور پر مل کر، ڈیٹا بیس اور ایپلیکیشن رام کے لیے مقابلہ کرتے ہیں۔
• پوسٹگری ایس کیو ایل مشترکہ میموری (مؤثر_کیشے_سائز) کو ڈیٹا بیس سرور RAM کے 50–75% پر سیٹ کیا جانا چاہیے۔
• PostgreSQL ڈیٹا ڈائرکٹری کے لیے SSD سٹوریج لازمی ہے — گھومنے والی ڈسک کسی بھی ERP ڈیٹا بیس پر تباہ کن کارکردگی کا باعث بنتی ہے۔
• 50 سے زیادہ صارفین کی تعیناتیوں کے لیے اوڈو سیشن اسٹوریج کے لیے علیحدہ Redis سرور تجویز کیا جاتا ہے۔

مائیکروسافٹ ڈائنامکس 365 بزنس سینٹرل

SaaS تعیناتی ماڈل کا استعمال کرتے وقت بزنس سینٹرل مائیکروسافٹ Azure انفراسٹرکچر پر کلاؤڈ ہوسٹڈ ہوتا ہے — اس صورت میں، سرور کی سائزنگ کا انتظام Microsoft کے ذریعے کیا جاتا ہے۔ آن پریمیسس تعیناتیوں کے لیے:

بزنس سنٹرل آن پریمیسس ایس کیو ایل سرور کو ڈیٹا بیس کے طور پر استعمال کرتا ہے، جس میں پوسٹگری ایس کیو ایل سے الگ میموری مینجمنٹ ماڈل ہے۔ ایس کیو ایل سرور کے بفر پول (بذریعہ max server memory ترتیب) کے لیے وقف شدہ RAM - ڈیٹا بیس سرور RAM کا تقریباً 75%۔

SAP بزنس ون

SAP Business One آن پریمیسس (Windows یا HANA) یا SAP Business One Cloud پر تعینات ہے:

SAP HANA (ان میموری ڈیٹا بیس جو SAP Business One HANA ایڈیشن کے ساتھ استعمال ہوتا ہے) روایتی ڈسک پر مبنی ڈیٹا بیس کے مقابلے میں بہت زیادہ RAM کی ضروریات رکھتا ہے کیونکہ ورکنگ سیٹ کا میموری میں فٹ ہونا ضروری ہے۔ HANA کے لیے RAM کے تقاضے غیر گفت و شنید ہیں — HANA جو میموری کریشز سے ختم ہو جاتی ہے، انحطاط نہیں ہوتی۔

---

کلاؤڈ مثال کی سفارشات

AWS، Azure، یا GCP پر ERP کی خود میزبانی کرتے وقت، صحیح مثال کی قسم کا انتخاب بہت اہمیت رکھتا ہے۔ یکساں vCPU اور RAM کی گنتی والی تمام مثالیں ڈیٹا بیس کے کام کے بوجھ کے لیے یکساں کارکردگی کا مظاہرہ نہیں کرتی ہیں۔

Odoo کے لیے AWS کی سفارشات (مشترکہ ایپ+db، 100 سے کم صارفین):

• t3.xlarge (4 vCPU، 16 GB): ترقی اور چھوٹی پیداوار (25 سے کم صارفین)
• r6i.xlarge (4 vCPU، 32 GB): چھوٹی درمیانی پیداوار (25–50 صارفین)
• r6i.2xlarge (8 vCPU, 64 GB): درمیانی پیداوار (50–100 صارفین)
• r6i.4xlarge (16 vCPU، 128 GB): بڑی پیداوار (100–200 صارفین، مشترکہ)

Odoo کے لیے AWS کی سفارشات (اسپلٹ ایپ/db، 100+ صارفین):

• ایپلیکیشن سرور: c6i.2xlarge (8 vCPU، 16 GB) - کمپیوٹ کے لیے موزوں
• ڈیٹا بیس سرور: r6i.4xlarge (16 vCPU، 128 GB) - میموری کو بہتر بنایا گیا
• ڈیٹا بیس اسٹوریج: io2 EBS والیومز (پروویژنڈ IOPS) - 3,000–6,000 IOPS کی فراہمی

آزور مساوی:

• ایپلیکیشن سرور: Standard_F8s_v2 (8 vCPU، 16 GB)
• ڈیٹا بیس سرور: Standard_E16s_v5 (16 vCPU، 128 GB)

GCP مساوی:

• ایپلیکیشن سرور: c2-standard-8 (8 vCPU، 32 GB)
• ڈیٹا بیس سرور: n2-highmem-16 (16 vCPU، 128 GB)

I/O کارکردگی کا جال: AWS پر معیاری EBS gp3 والیوم ڈیفالٹ کے طور پر 3,000 IOPS فراہم کرتے ہیں۔ ایک پروڈکشن ERP ڈیٹا بیس کے لیے جس میں 50+ ایک ساتھ استعمال کنندگان ہیں، یہ اکثر ناکافی ہوتا ہے — خاص طور پر مہینے کے اختتام کے دوران جب متعدد پیچیدہ رپورٹس ایک ساتھ چلتی ہیں۔ کم از کم 3,000 IOPS کی فراہمی کے ساتھ، ڈیٹا بیس اسٹوریج کے لیے io2 پروویژن شدہ IOPS والیوم استعمال کریں۔ لاگت کا فرق اہم ہے ($0.065/GB/month for gp3 بمقابلہ $0.125/GB/month for io2 پلس $0.065/IOPS/month for provisioned IOPS)، لیکن کارکردگی کا فرق بھی اہم ہے۔

---

اعلی دستیابی کا فن تعمیر

پروڈکشن ERP سسٹمز کے لیے جہاں ڈاؤن ٹائم کا اہم کاروباری اثر ہوتا ہے، ایک اعلیٰ دستیابی کے فن تعمیر پر غور کریں جو سنگل سرور کی ناکامیوں کے خلاف لچک فراہم کرتا ہے۔

اوڈو کے لیے کم از کم HA فن تعمیر (100+ صارفین):

• لوڈ بیلنسر کے پیچھے دو ایپلیکیشن سرورز (راؤنڈ رابن یا چپچپا سیشن)
• پوسٹگری ایس کیو ایل پرائمری ڈیٹا بیس اسٹینڈ بائی ریپلیکا کے ساتھ (اسٹریمنگ ریپلیکیشن یا AWS RDS Multi-AZ استعمال کرتے ہوئے)
• سیشن اسٹوریج کے لیے ریڈیس کلسٹر (دو نوڈس)
• Odoo کے فائل اٹیچمنٹ ڈیٹا کے لیے مشترکہ فائل اسٹوریج (AWS EFS یا مساوی)

یہ فن تعمیر دستی مداخلت کی ضرورت کے بغیر کسی ایک سرور کی ناکامی کے خلاف لچک فراہم کرتا ہے۔ پرائمری PostgreSQL سے اسٹینڈ بائی تک فیل اوور خودکار ہے (Patroni یا AWS RDS کا استعمال کرتے ہوئے) اور عام طور پر 30-60 سیکنڈ میں مکمل ہوتا ہے۔

عام ERP کے لیے RPO اور RTO کے اہداف:

• ریکوری پوائنٹ کا مقصد (زیادہ سے زیادہ ڈیٹا کا نقصان): 5 منٹ (ہم وقت ساز نقل کے ساتھ) سے 30 منٹ تک (async نقل کے ساتھ)
• ریکوری ٹائم کا مقصد (زیادہ سے زیادہ ڈاؤن ٹائم): خودکار فیل اوور کے لیے 30-60 سیکنڈ، دستی ریکوری کے لیے 15-30 منٹ

---

ECOSIRE سرور سائزنگ کیلکولیٹر کا استعمال

/tools/server-sizing-calculator پر ECOSIRE کا مفت سرور سائزنگ کیلکولیٹر اوپر بیان کردہ حساب کتاب کے عمل کو خودکار کرتا ہے۔ ان پٹ:

1. ERP پلیٹ فارم کا انتخاب
2. کل صارفین کی تعداد
3. چوٹی کنکرنٹ صارف فیصد (یا استعمال کے معاملے کی بنیاد پر خودکار تخمینہ)
4. لین دین کا حجم (کم، درمیانہ، زیادہ، بہت زیادہ)
5. انضمام کی گنتی اور حجم (کوئی نہیں، بنیادی، اعتدال پسند، شدید)
6. دستیابی کے تقاضے (سنگل سرور، HA، ڈیزاسٹر ریکوری)
7. کلاؤڈ فراہم کنندہ کی ترجیح (AWS، Azure، GCP، یا آن پریمیسس)

آؤٹ پٹ:

• ایپلیکیشن اور ڈیٹا بیس درجات کے لیے تجویز کردہ سرور کی وضاحتیں۔
• آپ کے پسندیدہ فراہم کنندہ کے لیے کلاؤڈ مثال کی مخصوص سفارشات
• ماہانہ بنیادی ڈھانچے کی لاگت کا تخمینہ
• تین سالہ ترقی کا تخمینہ ظاہر کرتا ہے کہ آپ کو کب اپ گریڈ کرنے کی ضرورت ہوگی۔
• اسٹوریج IOPS کی ضروریات اور تجویز کردہ اسٹوریج ٹائر

کیلکولیٹر کو درجنوں کلائنٹ کے نفاذ میں ECOSIRE کے اپنے پروڈکشن ڈیپلائمنٹ ڈیٹا کے خلاف کیلیبریٹ کیا جاتا ہے، جس سے تخمینے صرف وینڈر دستاویزات سے زیادہ قابل اعتماد ہوتے ہیں۔

---

اکثر پوچھے گئے سوالات

اگر ہم نے پہلے کبھی ERP استعمال نہیں کیا ہے تو میں چوٹی کے ہم آہنگ صارفین کا اندازہ کیسے لگاؤں؟

بغیر کسی تاریخی اعداد و شمار کے گرین فیلڈ کے نفاذ کے لیے، عام آفس پر مبنی تعیناتی کے لیے کل صارفین کے 20% کو ابتدائی تخمینہ کے طور پر استعمال کریں۔ اگر آپ کے پاس متعدد شفٹیں ہیں یا متعدد ٹائم زونز میں کام کرتے ہیں تو 25-30% استعمال کریں۔ پھر پہلے دو سالوں میں ترقی کے لیے 50% ہیڈ روم شامل کریں۔ عام دفتری اوقات کے ساتھ 100 یوزر ای آر پی کے لیے، عام چوٹی پر 20 ایک ساتھ استعمال کنندگان کے لیے منصوبہ بنائیں، 30 کے لیے فراہمی، اور انفراسٹرکچر میں تبدیلی کے بغیر 40 تک پہنچنے کی صلاحیت بنائیں۔ یہ ہیڈ روم اپروچ کارکردگی کے مسائل سے بچتا ہے کیونکہ گو لائیو کے بعد مہینوں میں اپنانے میں بہتری آتی ہے۔

کیا ہمیں Odoo ایپلیکیشن اور ڈیٹا بیس کو ایک ہی سرور یا الگ سرور پر چلانا چاہیے؟

50 سے کم صارفین کی تعیناتیوں کے لیے، ایک واحد مشترکہ سرور عام طور پر ٹھیک ہوتا ہے — اس پیمانے پر ایپلیکیشن اور ڈیٹا بیس کے کام کا بوجھ عام طور پر متصادم نہیں ہوتا ہے۔ 50-100 صارفین کے لیے، فیصلہ استعمال کے نمونوں پر منحصر ہوتا ہے: اگر صارف کی بنیاد پورے دن میں یکساں طور پر تقسیم کی جاتی ہے بغیر کوئی اہم چوٹی کے وقفے کے، تو ایک مشترکہ سرور اب بھی کام کر سکتا ہے۔ اگر تیز چوٹیاں ہیں (ماہ کے آخر میں، شفٹ کلوز)، الگ ایپلی کیشن اور ڈیٹا بیس سرورز بہتر تنہائی فراہم کرتے ہیں۔ 100 سے زائد صارفین، علیحدہ سرورز کی سختی سے سفارش کی جاتی ہے۔

ہمیں Odoo ڈیٹا بیس کے لیے کس قسم کی اسٹوریج استعمال کرنی چاہیے؟

PostgreSQL ڈیٹا ڈائرکٹری کے لیے SSD اسٹوریج لازمی ہے — اسپننگ ڈسک (HDD) کسی بھی پروڈکشن ERP ڈیٹا بیس پر ناقابل قبول کارکردگی پیدا کرتی ہے۔ کلاؤڈ پلیٹ فارمز پر، اگر آپ کے پاس 50 سے زیادہ کنکرنٹ صارفین ہیں تو ڈیٹا بیس اسٹوریج کے لیے پروویژنڈ IOPS SSD (AWS io2، Azure Premium SSD v2، GCP Extreme Persistent Disk) استعمال کریں۔ عمومی مقصد SSD (AWS gp3، Azure Standard SSD) 25 ہم آہنگ صارفین کے تحت ترقی اور چھوٹی پیداوار کی تعیناتیوں کے لیے قابل قبول ہے۔

ہمیں اپنے سرور کے سائز میں کتنا ہیڈ روم بنانا چاہیے؟

عام کاموں کے لیے اپنے متوقع چوٹی کے بوجھ سے 30-40% ہیڈ روم بنائیں، اور غیر معمولی ادوار جیسے مہینے کے آخر میں بند ہونے یا سیلز کے عروج کے موسموں کے لیے 100% ہیڈ روم (مؤثر طور پر چوٹی کی گنجائش سے دوگنا)۔ کلاؤڈ کی تعیناتیاں اس صلاحیت کے لیے مستقل طور پر ادائیگی کیے بغیر غیر معمولی مدتوں کو سنبھالنے کے لیے آٹو اسکیلنگ کا استعمال کر سکتی ہیں - فکسڈ آن پریمیسس انفراسٹرکچر پر لاگت کا ایک اہم فائدہ۔

---

اگلے اقدامات

ECOSIRE کا مفت سرور سائزنگ کیلکولیٹر استعمال کریں /tools/server-sizing-calculator پر اپنی مخصوص تعیناتی کے لیے تفصیلات تیار کرنے کے لیے۔ کیلکولیٹر AWS/Azure/GCP مثال کی سفارش اور ماہانہ انفراسٹرکچر لاگت کا تخمینہ دیتا ہے جسے آپ بجٹ کی منصوبہ بندی کے لیے استعمال کر سکتے ہیں۔

اگر آپ Odoo کے نفاذ کی منصوبہ بندی کر رہے ہیں اور چاہتے ہیں کہ ECOSIRE نفاذ کے ساتھ ساتھ بنیادی ڈھانچے کے سائز اور سیٹ اپ کو سنبھالے، تو بنیادی ڈھانچے کی منصوبہ بندی کو ECOSIRE کے نفاذ کی ہر مصروفیت میں شامل کیا جاتا ہے۔