تغيير حجم الخادم لـ ERP: كيفية القيام بذلك بشكل صحيح

يعد تحديد حجم الخادم لـ ERP أحد تلك القرارات التي تبدو فنية ولكن لها عواقب تجارية كبيرة. قم بتقليل حجم خادمك وستتلقى شكاوى بشأن الأداء من اليوم الأول - تحميل بطيء للصفحات، وانتهاء المهلات أثناء ذروة الاستخدام، وتوقف قاعدة البيانات تحت التحميل المتزامن. إذا تجاوز حجمها، فإنك تنفق أكثر بكثير من اللازم على البنية التحتية التي تظل خاملة في الغالب.

تخطئ معظم تطبيقات ERP في تحديد حجم الخادم في أحد الاتجاهين: فرق تكنولوجيا المعلومات المفرطة في الثقة والتي يعتمد حجمها على حدس "إنه مجرد تطبيق ويب" دون مراعاة كثافة قاعدة بيانات ERP، أو توصيات البائعين التي تمت معايرتها لتحقيق أقصى قدر من الأداء بأي تكلفة بدلاً من الأداء المناسب بتكلفة معقولة.

يمنحك هذا الدليل أسلوبًا منظمًا لتحديد حجم الخادم لعمليات نشر ERP: المتغيرات الرئيسية التي تحدد متطلبات الموارد، وإرشادات الحجم المحددة لمنصات ERP الرئيسية بأعداد مختلفة من المستخدمين، وكيفية استخدام حاسبة حجم الخادم المجانية من ECOSIRE لنمذجة موقفك المحدد.

الوجبات الرئيسية

يعد نظام تخطيط موارد المؤسسات (ERP) أكثر كثافة في استخدام قواعد البيانات من تطبيقات الويب النموذجية - ولا تنطبق قواعد تغيير حجم خادم الويب القياسية

نادراً ما تكون وحدة المعالجة المركزية هي القيد؛ تعد ذاكرة الوصول العشوائي (RAM) والإدخال/الإخراج على القرص دائمًا عنق الزجاجة في أحمال عمل ERP

يتطلب Odoo 2-4 جيجابايت من ذاكرة الوصول العشوائي لكل عملية عاملة متزامنة؛ 16 جيجابايت على الأقل لمثيلات الإنتاج التي تضم أكثر من 50 مستخدمًا

يتم التقليل من أهمية متطلبات IOPS لتخزين قاعدة البيانات بشكل كبير في معظم تمارين تغيير حجم الخادم

يمكن أن يكون لمثيلات السحابة التي تبدو متكافئة على الورق (نفس وحدة المعالجة المركزية الافتراضية ونفس ذاكرة الوصول العشوائي) أداء إدخال/إخراج مختلف تمامًا

الحجم المناسب دائمًا لذروة الحمل المتزامن (ليس متوسط التحميل) مع ارتفاع بنسبة 30-40%

استخدم حاسبة حجم الخادم المجانية من ECOSIRE لإنشاء مواصفات لعدد المستخدمين المحددين ومنصة ERP

لماذا يختلف حجم خادم ERP؟

قبل التعمق في توصيات محددة، يجدر بنا أن نفهم لماذا يتطلب تغيير حجم خادم ERP تحليلًا أكثر دقة من تغيير الحجم لتطبيق ويب نموذجي.

كثافة قاعدة البيانات: أنظمة تخطيط موارد المؤسسات (ERP) هي في الأساس أنظمة لمعالجة المعاملات. يؤدي كل إجراء يقوم به المستخدم - إنشاء أمر شراء، وترحيل فاتورة، ونقل المخزون - إلى إنشاء عمليات كتابة متعددة لقاعدة البيانات يجب الالتزام بها ذريًا. تتعامل طبقة قاعدة البيانات مع الاستعلامات العلائقية المعقدة عبر مخططات كبيرة وموحدة، غالبًا مع وصلات متعددة للجداول وحسابات مجمعة. وهذا يختلف تمامًا عن نظام إدارة المحتوى أو موقع التسويق، والذي قد يقرأ من عدد قليل من الجداول غير الطبيعية لكل عرض صفحة.

أنماط تحميل المستخدم المتزامنة: سلوك مستخدم ERP أكثر تزامنًا من تطبيقات الويب النموذجية. في موقع ويب المستهلك، يتصفح المستخدمون بشكل مستقل مع تفاعلات قليلة. في نظام تخطيط موارد المؤسسات (ERP)، يمكن لعدة مستخدمين في نفس القسم معالجة الطلبات في وقت واحد خلال ساعات الذروة (نهاية الشهر، نهاية اليوم، إغلاق المناوبة). ينشئ نمط الكتابة المتزامن هذا تنافسًا على قفل قاعدة البيانات لا يواجهه تطبيق الويب النموذجي أبدًا.

عبء عمل إنشاء التقارير: تقوم تقارير ERP - خاصة التقارير المالية وتقادم المخزون والتنبؤ بالطلب - بتنفيذ استعلامات معقدة ومتعددة الجداول يمكن تشغيلها لمدة تتراوح بين 30 و120 ثانية وتستهلك قدرًا كبيرًا من وحدة المعالجة المركزية (CPU) والإدخال/الإخراج أثناء التنفيذ. عندما يقوم ثلاثة من موظفي الشؤون المالية بتشغيل تقارير إقفال نهاية الشهر في وقت واحد، يمكن أن يكون ارتفاع العبء الناتج شديدًا.

حالة الجلسة والعمليات المنفذة: يقوم Odoo على وجه التحديد بتشغيل عمليات Python العاملة التي تحافظ على حالة الجلسة لكل اتصال مستخدم نشط. تستهلك كل عملية عاملة ما يقرب من 200 إلى 400 ميجابايت من ذاكرة الوصول العشوائي (RAM) في الحالة الثابتة وما يصل إلى 1 جيجابايت أثناء تنفيذ التقارير المكثفة. يحتاج الخادم إلى ذاكرة وصول عشوائي كافية لتشغيل جميع العمال النشطين في وقت واحد دون التبديل إلى القرص - يؤدي التبديل في خادم قاعدة بيانات ERP إلى تدهور الأداء بشكل كارثي.

المتغيرات الرئيسية في حجم خادم ERP

هناك أربعة متغيرات تدفع متطلبات موارد خادم ERP أكثر من أي متغيرات أخرى:

1. عدد المستخدمين المتزامنين (وليس إجمالي عدد المستخدمين)

يعد إجمالي عدد المستخدمين مؤشرًا سيئًا لمتطلبات الموارد. المقياس الصحيح هو ذروة المستخدمين المتزامنين: عدد المستخدمين الذين يقدمون طلبات إلى النظام بشكل نشط في نفس الوقت خلال الفترة الأكثر ازدحامًا في اليوم.

تقدير ذروة المستخدمين المتزامنين من إجمالي عدد المستخدمين:

تخطيط موارد المؤسسات المستند إلى المكتب مع ساعات العمل العادية: 15-25% من إجمالي المستخدمين متزامنون في أوقات الذروة
التصنيع مع نوبات عمل متعددة: 25-35% من إجمالي المستخدمين المتزامنين (ذروة تغيير الورديات)
العمليات الموزعة عبر المناطق الزمنية: ذروة التزامن أقل ولكن مدة الذروة أطول
الاستخدام المكثف للتمويل خلال نهاية الشهر: ارتفاع مؤقت إلى 40-50% بشكل متزامن خلال فترات الإغلاق

بالنسبة لنشر Odoo لـ 100 مستخدم مع الاستخدام العادي المعتمد على المكتب، خطط لـ 15-25 مستخدمًا متزامنًا في الذروة النموذجية، مع توفير 40-50 مستخدمًا متزامنًا خلال نهاية الشهر. من المفترض أن يؤدي هذا إلى حساب الحجم الخاص بك، وليس إجمالي 100 مستخدم.

2. حجم المعاملات وتعقيد المعاملات

تؤدي أحجام المعاملات الكبيرة إلى تحميل قاعدة البيانات بشكل مستقل عن المستخدمين المتزامنين. تقوم شركة التوزيع التي تعالج 2000 أمر شراء يوميًا بإنشاء عمليات إدخال/إخراج لكتابة قاعدة بيانات أكبر بكثير من شركة خدمات احترافية تضم 100 مستخدم ولكن حجم المعاملات منخفض. وبالمثل، فإن المعاملات المعقدة (أوامر عمل التصنيع التي تقوم بتحديث استهلاك قائمة مكونات الصنف والمخزون ومحاسبة التكاليف وسجلات الجودة في وقت واحد) تولد عمليات إدخال/إخراج أكثر من المعاملات البسيطة (ترحيل قيد دفتر اليومية الذي يقوم بتحديث حسابي أستاذ عام).

قم بتقدير مدى تعقيد معاملاتك من خلال التفكير في الوحدات المستخدمة: التصنيع ومخزون المستودعات المتعددة يولدان المعاملات الأكثر تعقيدًا؛ تولد وحدات المحاسبة والموارد البشرية البسيطة أبسطها.

3. حجم قاعدة البيانات ومعدل النمو

يؤثر حجم قاعدة البيانات على أداء الاستعلام بطريقتين: بشكل مباشر (تستغرق الجداول الأكبر وقتًا أطول للمسح) وبشكل غير مباشر (مجموعات العمل التي تتجاوز ذاكرة الوصول العشوائي المتوفرة تؤدي إلى فقدان ذاكرة التخزين المؤقت وزيادة الإدخال/الإخراج).

تنمو قواعد بيانات ERP بشكل أسرع مما تتوقعه معظم فرق تكنولوجيا المعلومات. يمكن لقاعدة البيانات الأولية التي يبلغ حجمها 20 جيجابايت أن تصل إلى 100 جيجابايت خلال عامين إلى ثلاثة أعوام مع النمو الطبيعي من سجل المعاملات ومرفقات المستندات وسجلات التدقيق. قم بقياس مساحة التخزين الخاصة بك بما يكفي لثلاث سنوات من النمو المتوقع، وليس فقط الاحتياجات الحالية.

4. عبء عمل التكامل وواجهة برمجة التطبيقات

إذا كان نظام تخطيط موارد المؤسسات الخاص بك يتصل بأنظمة خارجية عبر واجهة برمجة التطبيقات (منصة التجارة الإلكترونية، ونظام 3PL، وواجهات برمجة التطبيقات البنكية، وموصلات السوق)، فإن عمليات التكامل هذه تولد حملًا إضافيًا على الخادم لا ينعكس في أعداد المستخدمين. يمر كل استدعاء لواجهة برمجة التطبيقات (API) عبر طبقة التطبيق وقاعدة البيانات الخاصة بـ ERP - يمكن أن يطابق التكامل كبير الحجم (معالجة 1000 طلب مزامنة طلب في الساعة) حمل 10 إلى 20 مستخدمًا متزامنًا.

إرشادات الحجم حسب المنصة وعدد المستخدمين

أودو 19 إنتربرايز

تستخدم بنية Odoo العمليات المنفذة (عمال Odoo) التي تخدم كل منها طلبات المستخدم. يتم قياس عدد العاملين وموارد الخادم المطلوبة مع عدد المستخدمين المتزامنين.

حساب عامل Odoo:

العمال الموصى بهم = (المستخدمون المتزامنون / 6) + 1، مقربًا لأعلى
يحتاج كل عامل إلى ما يقرب من 300 إلى 500 ميجابايت من ذاكرة الوصول العشوائي في حالة الاستقرار، وما يصل إلى 1 جيجابايت أثناء التقارير الثقيلة
يضيف عمال Cron (للعمليات الخلفية) 2-4 عمال إضافيين

الحد الأدنى من المواصفات الموصى بها حسب عدد المستخدمين:

إجمالي المستخدمين	الذروة المتزامنة	عمال	وحدة المعالجة المركزية (النوى)	ذاكرة الوصول العشوائي	تخزين SSD
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 تيرابايت+

ملاحظات مهمة حول تغيير حجم Odoo:

تعمل قاعدة البيانات (PostgreSQL) والتطبيق (عمليات Odoo العاملة) بشكل مثالي على خوادم منفصلة تزيد عن 100 مستخدم. مجتمعة على خادم واحد، تتنافس قاعدة البيانات والتطبيق على ذاكرة الوصول العشوائي (RAM).
يجب ضبط ذاكرة PostgreSQL المشتركة (حجم ذاكرة التخزين المؤقت الفعال) على 50-75% من ذاكرة الوصول العشوائي لخادم قاعدة البيانات.
يعد تخزين SSD إلزاميًا لدليل بيانات PostgreSQL - يتسبب القرص الدوار في أداء كارثي في أي قاعدة بيانات لتخطيط موارد المؤسسات (ERP).
يوصى باستخدام خادم Redis منفصل لتخزين جلسة Odoo لعمليات النشر التي تزيد عن 50 مستخدمًا.

مايكروسوفت دايناميكس 365 بزنس سنترال

يتم استضافة Business Central على السحابة على البنية التحتية لـ Microsoft Azure عند استخدام نموذج نشر SaaS - في هذه الحالة، تتم إدارة حجم الخادم بواسطة Microsoft. بالنسبة لعمليات النشر المحلية:

إجمالي المستخدمين	الذروة المتزامنة	وحدة المعالجة المركزية (النوى)	ذاكرة الوصول العشوائي	ذاكرة الوصول العشوائي لخادم SQL	تخزين
10-25	3–6	4	16 جيجا	8 جيجا	150 جيجا
25–75	6–18	8	32 جيجا	16 جيجا	300 جيجا
75–150	١٨–٣٧	16	64 جيجا	32 جيجا	500 جيجا
150–300	37–75	32	128 جيجا	64 جيجا	1 تيرابايت

يستخدم Business Central المحلي SQL Server كقاعدة بيانات، والتي تحتوي على نموذج منفصل لإدارة الذاكرة عن PostgreSQL. تخصيص ذاكرة الوصول العشوائي (RAM) المخصصة لتجميع المخزن المؤقت لـ SQL Server (عبر إعداد max server memory) - ما يقرب من 75% من ذاكرة الوصول العشوائي لخادم قاعدة البيانات.

ساب بيزنس ون

يتم نشر SAP Business One محليًا (Windows أو HANA) أو على SAP Business One Cloud:

إجمالي المستخدمين	الذروة المتزامنة	وحدة المعالجة المركزية	ذاكرة الوصول العشوائي (SAP هانا)	ذاكرة الوصول العشوائي (SQL Server)	تخزين
حتى 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) أعلى بكثير من قواعد البيانات التقليدية المستندة إلى القرص لأن مجموعة العمل يجب أن تتناسب مع الذاكرة. متطلبات ذاكرة الوصول العشوائي (RAM) لـ HANA غير قابلة للتفاوض - HANA التي تنفد من الذاكرة تتعطل ولا تتدهور.

توصيات المثيلات السحابية

عند استضافة ERP ذاتيًا على AWS أو Azure أو GCP، يكون تحديد نوع المثيل المناسب مهمًا بشكل كبير. لا تعمل جميع المثيلات التي لها نفس عدد وحدات المعالجة المركزية الافتراضية (vCPU) وذاكرة الوصول العشوائي (RAM) بشكل متساوٍ بالنسبة لأحمال عمل قاعدة البيانات.

توصيات AWS لـ Odoo (تطبيق مدمج + قاعدة بيانات، أقل من 100 مستخدم):

t3.xlarge (4 وحدات معالجة مركزية افتراضية، 16 جيجابايت): التطوير والإنتاج الصغير (أقل من 25 مستخدمًا)
r6i.xlarge (4 وحدات معالجة مركزية افتراضية، 32 جيجابايت): إنتاج صغير ومتوسط (25-50 مستخدمًا)
r6i.2xlarge (8 وحدة معالجة مركزية افتراضية، 64 جيجابايت): إنتاج متوسط (50-100 مستخدم)
r6i.4xlarge (16 وحدة معالجة مركزية افتراضية، 128 جيجابايت): إنتاج كبير (100-200 مستخدم، مجتمعين)

توصيات AWS لـ Odoo (تقسيم التطبيق/قاعدة البيانات، أكثر من 100 مستخدم):

خادم التطبيقات: c6i.2xlarge (8 وحدة معالجة مركزية افتراضية، 16 جيجابايت) — مُحسَّن للحوسبة
خادم قاعدة البيانات: r6i.4xlarge (16 وحدة معالجة مركزية افتراضية، 128 جيجابايت) — ذاكرة محسنة
تخزين قاعدة البيانات: io2 وحدات تخزين EBS (IOPS المتوفرة) - 3000–6000 IOPS متوفرة

** معادلات Azure **:

خادم التطبيقات: Standard_F8s_v2 (8 وحدة معالجة مركزية افتراضية، 16 جيجابايت)
خادم قاعدة البيانات: Standard_E16s_v5 (16 وحدة معالجة مركزية افتراضية، 128 جيجابايت)

معادلات Google Cloud Platform:

خادم التطبيقات: c2-standard-8 (8 وحدة معالجة مركزية افتراضية، 32 جيجابايت)
خادم قاعدة البيانات: n2-highmem-16 (16 وحدة معالجة مركزية افتراضية، 128 جيجابايت)

مصيدة أداء الإدخال/الإخراج: توفر وحدات تخزين EBS gp3 القياسية على AWS 3000 IOPS بشكل افتراضي. بالنسبة لقاعدة بيانات ERP للإنتاج التي تحتوي على أكثر من 50 مستخدمًا متزامنًا، غالبًا ما يكون هذا غير كافٍ - خاصة أثناء إغلاق نهاية الشهر عندما يتم تشغيل عدة تقارير معقدة في وقت واحد. استخدم io2 وحدات تخزين IOPS المتوفرة لتخزين قاعدة البيانات، مع توفير ما لا يقل عن 3000 IOPS. يعد فرق التكلفة كبيرًا (0.065 دولارًا أمريكيًا/جيجابايت/شهرًا لـ gp3 مقابل 0.125 دولارًا أمريكيًا/جيجابايت/شهريًا لـ io2 بالإضافة إلى 0.065 دولارًا أمريكيًا/IOPS/شهريًا لـ IOPS المتوفر)، ولكن فرق الأداء كبير أيضًا.

بنية عالية التوفر

بالنسبة لأنظمة تخطيط موارد المؤسسات (ERP) للإنتاج حيث يكون لوقت التوقف عن العمل تأثير كبير على الأعمال، فكر في بنية عالية التوفر توفر المرونة ضد حالات فشل الخادم الفردي.

الحد الأدنى من بنية HA لـ Odoo (أكثر من 100 مستخدم):

خادمان للتطبيقات خلف موازن التحميل (جلسات دائرية أو ثابتة)
قاعدة بيانات PostgreSQL الأساسية مع نسخة احتياطية (باستخدام النسخ المتماثل المتدفق أو AWS RDS Multi-AZ)
مجموعة Redis (عقدتين) لتخزين الجلسة
تخزين الملفات المشتركة (AWS EFS أو ما يعادلها) لبيانات مرفقات الملفات الخاصة بـ Odoo

توفر هذه البنية مرونة ضد أي فشل في خادم واحد دون الحاجة إلى تدخل يدوي. يتم تجاوز الفشل من PostgreSQL الأساسي إلى وضع الاستعداد تلقائيًا (باستخدام Patroni أو AWS RDS) ويكتمل عادةً خلال 30 إلى 60 ثانية.

أهداف RPO وRTO لتخطيط موارد المؤسسات (ERP) النموذجي:

هدف نقطة الاسترداد (الحد الأقصى لفقدان البيانات): 5 دقائق (مع النسخ المتماثل المتزامن) إلى 30 دقيقة (مع النسخ المتماثل غير المتزامن)
هدف وقت الاسترداد (الحد الأقصى لوقت التوقف عن العمل): 30-60 ثانية لتجاوز الفشل التلقائي، و15-30 دقيقة للاسترداد اليدوي

استخدام حاسبة حجم خادم ECOSIRE

تعمل حاسبة حجم الخادم المجانية من ECOSIRE على /tools/server-sizing-calculator على أتمتة عملية الحساب الموضحة أعلاه. المدخلات:

اختيار منصة تخطيط موارد المؤسسات (ERP).
إجمالي عدد المستخدمين
ذروة النسبة المئوية للمستخدمين المتزامنين (أو التقدير التلقائي بناءً على حالة الاستخدام)
حجم المعاملة (منخفض، متوسط، مرتفع، مرتفع جدًا)
عدد التكامل وحجمه (لا يوجد، أساسي، متوسط، مكثف)
متطلبات التوفر (خادم واحد، HA، التعافي من الكوارث)
تفضيلات موفر السحابة (AWS، أو Azure، أو GCP، أو محليًا)

النواتج:

مواصفات الخادم الموصى بها لطبقات التطبيق وقاعدة البيانات
توصيات محددة لمثيلات السحابة لمزودك المفضل
تقدير تكلفة البنية التحتية الشهرية
توقعات النمو لمدة ثلاث سنوات توضح متى ستحتاج إلى الترقية
متطلبات تخزين IOPS وطبقة التخزين الموصى بها

تتم معايرة الآلة الحاسبة وفقًا لبيانات نشر الإنتاج الخاصة بـ ECOSIRE عبر العشرات من تطبيقات العميل، مما يجعل التقديرات أكثر موثوقية من وثائق البائع وحدها.

الأسئلة المتداولة

كيف يمكنني تقدير ذروة عدد المستخدمين المتزامنين إذا لم نستخدم تخطيط موارد المؤسسات (ERP) من قبل؟

بالنسبة لعمليات التنفيذ التأسيسية التي لا تحتوي على بيانات تاريخية، استخدم 20% من إجمالي المستخدمين كتقدير أولي للنشر العادي المستند إلى المكتب. إذا كان لديك ورديات متعددة أو تعمل عبر مناطق زمنية متعددة، فاستخدم 25-30%. ثم قم بإضافة 50% من المساحة للنمو خلال العامين الأولين. بالنسبة لنظام تخطيط موارد المؤسسات (ERP) لـ 100 مستخدم مع ساعات عمل عادية، خطط لـ 20 مستخدمًا متزامنًا في الذروة النموذجية، وقم بتوفير 30، وقم ببناء القدرة للوصول إلى 40 دون تغييرات في البنية التحتية. يتجنب نهج الإرتفاع هذا مشاكل الأداء مع تحسن الاعتماد في الأشهر التي تلي بدء التشغيل.

هل يجب تشغيل تطبيق Odoo وقاعدة البيانات على نفس الخادم أم على خوادم منفصلة؟

بالنسبة لعمليات النشر التي تقل عن 50 مستخدمًا، عادةً ما يكون خادم مدمج واحد أمرًا جيدًا - لا تتعارض أحمال عمل التطبيق وقاعدة البيانات على هذا النطاق عادةً. بالنسبة إلى 50-100 مستخدم، يعتمد القرار على أنماط الاستخدام: إذا تم توزيع قاعدة المستخدمين بالتساوي على مدار اليوم مع عدم وجود فترات ذروة كبيرة، فقد يستمر الخادم المدمج في العمل. إذا كانت هناك فترات ذروة حادة (نهاية الشهر، إغلاق الوردية)، فإن خوادم التطبيقات وقواعد البيانات المنفصلة توفر عزلًا أفضل. أكثر من 100 مستخدم، يوصى بشدة بخوادم منفصلة.

ما نوع التخزين الذي يجب أن نستخدمه لقاعدة بيانات Odoo؟

يعد تخزين SSD إلزاميًا لدليل بيانات PostgreSQL - ينتج القرص الدوار (HDD) أداءً غير مقبول في أي قاعدة بيانات لتخطيط موارد المؤسسات (ERP) للإنتاج. على الأنظمة الأساسية السحابية، استخدم IOPS SSD المتوفر (AWS io2 وAzure Premium SSD v2 وGCP Extreme Persistent Disk) لتخزين قاعدة البيانات إذا كان لديك أكثر من 50 مستخدمًا متزامنًا. يعد SSD للأغراض العامة (AWS gp3 وAzure Standard SSD) مقبولًا للتطوير وعمليات نشر الإنتاج الصغيرة تحت 25 مستخدمًا متزامنًا.

ما مقدار المساحة التي يجب أن نبنيها في حجم الخادم الخاص بنا؟

قم ببناء مساحة أعلى بنسبة 30-40% أعلى من الحمل الأقصى المتوقع للعمليات العادية، ومساحة علوية بنسبة 100% (ضعف سعة الذروة بشكل فعال) لفترات استثنائية مثل إغلاق نهاية الشهر أو مواسم ذروة المبيعات. يمكن لعمليات النشر السحابية استخدام التوسع التلقائي للتعامل مع الفترات الاستثنائية دون الدفع مقابل تلك السعة بشكل دائم - وهي ميزة تكلفة كبيرة مقارنة بالبنية التحتية الثابتة المحلية.

الخطوات التالية

استخدم حاسبة حجم الخادم المجانية من ECOSIRE على /tools/server-sizing-calculator لإنشاء مواصفات للنشر المحدد الخاص بك. تقوم الآلة الحاسبة بإخراج توصية مثيل AWS/Azure/GCP وتقدير شهري لتكلفة البنية التحتية التي يمكنك استخدامها لتخطيط الميزانية.

إذا كنت تخطط لتنفيذ Odoo وتريد أن يتولى ECOSIRE التعامل مع حجم البنية التحتية وإعدادها جنبًا إلى جنب مع التنفيذ، فسيتم تضمين تخطيط البنية التحتية في كل مشاركة تنفيذ ECOSIRE.

Server Sizing for ERP: How to Get It Right