متطلبات العتاد

متطلبات العتاد

عند تجهيز العتاد لتشغيل Overleaf، فإن العامل الرئيسي الذي يجب مراعاته هو عدد المستخدمين المتزامنين الذين سيشغّلون عمليات الترجمة.

على سبيل المثال، إذا كان لديك ترخيص لـ 100 مستخدم إجمالًا، لكنك تتوقع أن يعمل ~5 منهم فقط في الوقت نفسه، فسيكون التثبيت الأدنى كافيًا. أما إذا كنت تتوقع أن تعمل نسبة أعلى منهم (وتُجري عمليات ترجمة) في آن واحد، فعليك التفكير في تجهيز خادم بمواصفات أعلى.

التثبيت الأدنى

يلزم حد أدنى أساسي من نواتين (2 cores) وذاكرة بسعة 3GB للعمليات الأساسية مع نحو 5 مستخدمين متزامنين. وسيكون هذا الحد الأدنى كافيًا أيضًا للمجموعات الأكبر حيث يكون الاستخدام المتزامن أقل، أو حيث لا بأس بأن تطول أوقات الترجمة أثناء فترات الاستخدام المكثف.

إذا كنت تفكر في استخدام نظام ملفات قائم على NFS (Network File System) لمثيلك الصغير، فيُرجى الاطلاع على هذا الجزء في قسم استكشاف الأخطاء وإصلاحها.

التوسّع

كقاعدة عامة، ولتقديم مستوى خدمة مرتفع وثابت، يجب إضافة نواة معالج واحدة و1GB من الذاكرة إلى التثبيت الأدنى لكل 5-10 مستخدمين متزامنين.

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

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

المثال 1	المثال 2
إذا كنت تشغّل تثبيتًا من Server Pro لـ 300 مستخدم إجمالًا، وتتوقع بانتظام أن يُجري 30-60 منهم عمليات ترجمة للمستندات في الوقت نفسه، فإن 8GB و7 أنوية (5 أنوية + 5GB + الأساس المكوّن من نواتين و3GB) يُفترض أن توفر موارد كافية ليحظى مستخدموك بمستوى خدمة مرتفع وثابت.	ولإعطاء مثال على متطلبات العتاد لنشر أكبر، فقد أُعدّ بنجاح تثبيت من Server Pro لـ 1,000 مستخدم إجمالًا باستخدام خادم واحد مجهّز بمعالجين رباعيي الأنوية و32GB من ذاكرة النظام. وقد كان ذلك كافيًا لاحتياجات الفريق على مدار العام الماضي من الاستخدام.

يمكن للعملاء الذين يتجاوزون حدود خادم كبير واحد الاطلاع على التوسّع الأفقي لـ Server Pro.

التخزين

لا ننصح باستخدام Network File System (NFS) أو Amazon EFS أو Amazon EBS لتخزين المشاريع والسجل في الإعدادات الأكبر، ولا ندعمها صراحةً للتوسّع الأفقي.

فسلوك أنظمة الملفات هذه لا يوفر الأداء والموثوقية اللازمين لـ Server Pro عند التشغيل على نطاق واسع. فعندما يعجز نظام الملفات عن مجاراة الحمل، يتوقف التطبيق بسبب كثرة عمليات الإدخال والإخراج الحاجبة (blocking IO). وقد تؤدي حالات التوقف هذه إلى تجاوز مهلة الأقفال القائمة على Redis، مما قد يؤدي بدوره إلى تلف بيانات المشاريع.

ننصح باستخدام تخزين كائنات متوافق مع S3 بدلًا من ذلك. فبطء أداء S3 لا يؤثر إلا في رفع الملفات وتنزيلها، مما يؤدي فقط إلى ارتفاع عدد الاتصالات المفتوحة مع مزوّد S3 لديك، ولا يؤثر في سلوك بقية التطبيق. إضافة إلى ذلك، يمكن لـ Server Pro تحديد مهلات معقولة لطلبات S3، وهو أمر غير ممكن لعمليات نظام الملفات/الإدخال والإخراج على مستوى التطبيق.

للمرجعية، تتبنى GitLab موقفًا مماثلًا يتمثل في عدم دعم NFS/Amazon EFS في عرضها المُدار ذاتيًا.

إعدادات خاصة بـ Nginx لعمليات النشر الكبيرة

افتراضيًا، يحدّ مثيل Overleaf Server عدد الاتصالات بـ 768. ويشمل ذلك اتصالات Websocket الدائمة، والتنقل في صفحات HTML ذات المستوى الأعلى، وطلبات ajax. وبمجرد بلوغ هذا الحد، قد يتعذر على المحرر الاتصال، وقد لا تُحمَّل صفحة المحرر بالكامل، وقد تفشل طلبات الترجمة. وسيُعيد Nginx استجابات بالحالة 500 ويسجّل worker_connections are not enough while connecting to upstream في var/log/nginx/error.log داخل الحاوية sharelatex.

يحدّ الإعداد worker_connections عدد الاتصالات المتزامنة التي سيقبلها nginx لكل عامل (worker). ويتحكم الإعداد worker_processes في عدد العمال، وقيمته الافتراضية 4 في إعدادات nginx لدينا.

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

توفر مثيلات Overleaf Server متغيرات بيئة لضبط إعدادات nginx هذه:

• NGINX_WORKER_PROCESSES للإعداد worker_processes (القيمة الافتراضية 4)

• NGINX_WORKER_CONNECTIONS للإعداد worker_connections (القيمة الافتراضية 768)

• NGINX_KEEPALIVE_TIMEOUT للإعداد keepalive_timeout (القيمة الافتراضية 65)

  عند تشغيل وكيل آخر أمام الحاوية sharelatex (مثلًا لإنهاء TLS)، يجب أن تكون قيمة NGINX_KEEPALIVE_TIMEOUT في مثيل Overleaf Server أكبر من قيمة الوكيل السابق. فمثلًا مع عملية nginx أخرى على مضيف Docker nginx-host، إليك مثالين:

• القيمة الافتراضية لـ NGINX_KEEPALIVE_TIMEOUT: استخدم keepalive_timeout 60s (القيمة الافتراضية في upstream) في nginx-host

• القيمة المخصصة NGINX_KEEPALIVE_TIMEOUT=100s: استخدم keepalive_timeout 90s (قيمة مخصصة في upstream) في nginx-host

سرعة المعالج

LaTeX برنامج أحادي الخيط (single threaded)، أي أنه لا يستطيع استخدام سوى نواة معالج واحدة في كل مرة. كما أن المعالج هو القيد الرئيسي عند ترجمة مستند. لذلك كلما كان أداء النواة الواحدة في معالجك أسرع، تمكنت من ترجمة المستند بشكل أسرع. ولن تفيد الأنوية الإضافية إلا إذا كنت تحاول ترجمة مستندات أكثر من عدد أنوية المعالج الحرة لديك.