Nextcloud: النشر المتسامح مع الخطأ للشركات متوسطة الحجم

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



اليوم سنقوم بنشره. لن أعطي تعليمات كاملة خطوة بخطوة ، لكنني سأحاول أن أذكر النقاط الرئيسية للهندسة المعمارية التي تستحق الاهتمام بها. على وجه الخصوص ، سنقوم بتحليل موازنة التحميل ونسخ قاعدة البيانات والصيانة الروتينية دون انقطاع الخدمة.



سنقوم بنشره في إصدار آمن من الفشل لشركة صغيرة تضم 150-1000 مستخدم ، ولكنه سيكون مفيدًا أيضًا للمستخدمين المنزليين.

ماذا تحتاج الشركات؟

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



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



على وجه الخصوص ، من واقع خبرتي ، فإن Nextcloud مطلوب للعديد من الميزات بين الشركات الصغيرة:

1. توفير الوصول إلى الدلائل المشتركة والمزامنة.
2. ميزة قاتلة مع توفير وصول خارجي داخل الاتحاد. يمكنك التكامل مع منتج مشابه من الزملاء وشركة أخرى.
3. توفير وصول خارجي عبر رابط مباشر. من المفيد كثيرًا ، على سبيل المثال ، العمل في صناعة الطباعة وتحتاج إلى تبادل كميات كبيرة من البيانات الثقيلة مع العملاء.
4. محرر مستندات Collabora يعمل على جانب الخادم ويعمل كواجهة أمامية لـ LibreOffice.
5. الدردشات ومكالمات الفيديو. ميزة مثيرة للجدل قليلاً وليست مستقرة تمامًا ، ولكنها موجودة وتعمل. في الإصدار الأخير ، تم تثبيته بالفعل.

نحن نبني العمارة

لسوء الحظ ، في أحدث الإصدارات ، لا تتوفر وثائق تنفيذ مؤسسة Nextcloud إلا لأصحاب الاشتراكات المدفوعة. ومع ذلك ، كمرجع ، يمكنك أن تأخذ كتيبات أقدم لا تزال في المجال العام.





نموذجي للاستخدام المنزلي والتركيبات الفردية.



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





يوصى بخيار النشر القابل للتوسع لأحمال العمل الأكبر.



المكونات الرئيسية للنظام:

• 1 موازن. يمكنك استخدام HAproxy أو Nginx. سأفكر في الخيار مع Nginx.
• 2-4 قطع خادم التطبيق (خادم الويب). تثبيت Nextcloud نفسه مع الكود الرئيسي في php.
• 2 ديسيبل. في التكوين القياسي الموصى به ، هذا هو MariaDB.
• تخزين NFS.
• Redis لتخزين استعلامات قاعدة البيانات مؤقتًا

موازن

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



يرجى ملاحظة أن الموازن هو أيضًا نقطة إنهاء SSL / TLS لعملائك ، ويمكن أن يمر الاتصال بالخلفية إما عبر HTTP للشبكات الداخلية الموثوقة ، أو باستخدام HTTPS إضافي إذا كانت حركة المرور إلى خادم التطبيق تمر عبر قنوات عامة غير موثوق بها.

قاعدة البيانات

الحل النموذجي هو MySQL / MariaDB في التنفيذ العنقودي في النسخ المتماثل الرئيسي والعبد. في نفس الوقت ، لديك قاعدة بيانات نشطة واحدة فقط ، والثانية تعمل في وضع الاستعداد السريع في حالة حدوث فشل طارئ للقاعدة الرئيسية أو أثناء العمل المجدول. يمكن أيضًا مراعاة موازنة الحمل ، لكنها أكثر صعوبة من الناحية الفنية. عند استخدام MariaDB Galera Cluster مع خيار النسخ المتماثل الرئيسي ، تحتاج إلى استخدام عدد فردي من العقد ، ولكن على الأقل ثلاثة. وبالتالي ، يتم تقليل مخاطر حالات انقسام الدماغ إلى الحد الأدنى ، عند قطع الاتصال بين العقد.

تخزين

أي حل أفضل لك يوفره بروتوكول NFS. للأحمال العالية ، ضع في اعتبارك IBM Elastic Storage أو Ceph. من الممكن أيضًا استخدام تخزين كائن متوافق مع S3 ، ولكن هذا خيار للتثبيتات الكبيرة جدًا.

HDD أو SSD

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



سيتم تحديد سرعة المزامنة وتحميل الملفات من خلال أداء تخزين NFS الخاص بك.

تكوين الموازن

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

لحسن الحظ ، تم حل هذا باستخدام طريقة ip_hash . في هذه الحالة ، سيتم تعيين جلسات المستخدم إلى خلفية محددة ، والتي سيتم توجيه جميع الطلبات الواردة من المستخدم إليها. هذه النقطة موصوفة في الوثائق:

, IP- . IPv4- IPv6- . , . , . .

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



يصف ملف التكوين nginx هذا على النحو التالي:

upstream backend {
    ip_hash;

    server backend1_nextcloud.example.com;
    server backend2_nextcloud.example.com;
    server backend3_nextcloud.example.com;
    server backend4_nextcloud.example.com;
}

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

upstream backend {
    ip_hash;

    server backend1_nextcloud.example.com weight=3;
    server backend2_nextcloud.example.com;
    server backend3_nextcloud.example.com;
}

في المثال المعطى ، من بين 5 طلبات مستلمة ، 3 ستنتقل إلى الواجهة الخلفية 1 ، و 1 إلى الواجهة الخلفية 2 و 1 إلى الواجهة الخلفية 3.



إذا فشل أحد خوادم التطبيق ، سيحاول nginx إعادة توجيه الطلب إلى الخادم التالي من قائمة الخلفيات.

تكوين قاعدة البيانات

يمكن العثور على تفاصيل تكوين Master-Slave في الوثائق الرئيسية .



دعنا نلقي نظرة على بعض النقاط الرئيسية. أولاً ، نقوم بإنشاء مستخدم لنسخ البيانات:

create user 'replicant'@'%' identified by 'replicant_password';
grant replication slave on *.* to replicant;
flush privileges;

ثم نقوم بتحرير التكوين الرئيسي:

sudo nano /etc/mysql/mariadb.conf.d/50-server.cnf 

في منطقة كتلة "التسجيل والنسخ المتماثل" ، قم بإجراء التعديلات اللازمة:

[mysqld]
log-bin         = /var/log/mysql/master-bin
log-bin-index   = /var/log/mysql/master-bin.index
binlog_format   = mixed
server-id       = 01
replicate-do-db = nextcloud
bind-address = 192.168.0.6

على Slave ، نقوم بتكوين التكوين:

sudo nano /etc/mysql/mariadb.conf.d/50-server.cnf 

في منطقة كتلة "التسجيل والنسخ المتماثل" ، قم بإجراء التعديلات اللازمة:

    [mysqld]
    server-id       = 02
    relay-log-index = /var/log/mysql/slave-relay-bin.index
    relay-log       = /var/log/mysql/slave-relay-bin
    replicate-do-db = nextcloud
    read-only = 1
    bind-address    = 192.168.0.7

أعد تشغيل كلا الخادمين:

sudo systemctl restart mariadb

بعد ذلك ، ستحتاج إلى نسخ قاعدة البيانات إلى Slave.

على الماستر ، نقوم أولاً بإغلاق الجدول:

flush tables with read lock;

ثم ننظر إلى الحالة:

    MariaDB [(none)]> show master status;
    +-------------------+----------+--------------+------------------+
    | File              | Position | Binlog_Do_DB | Binlog_Ignore_DB |
    +-------------------+----------+--------------+------------------+
    | master-bin.000001 |      772 |              |                  |
    +-------------------+----------+--------------+------------------+
    1 row in set (0.000 sec)

لا تخرج من وحدة تحكم قاعدة البيانات ، وإلا ستتم إزالة الأقفال!

سنحتاج إلى master_log_file و master_log_pos من هنا لتكوين Slave.

إغراق وإزالة الأقفال:

sudo mysqldump -u root nextcloud > nextcloud.sql

    > unlock tables;
    > exit;

ثم نقوم باستيراد التفريغ إلى Slave وإعادة تشغيل البرنامج الخفي:

sudo mysqldump -u root nextcloud < nextcloud.sql
sudo systemctl restart mariadb

بعد ذلك ، قم بإعداد النسخ المتماثل في وحدة التحكم:

    MariaDB [(none)]> change master 'master01' to     
    master_host='192.168.0.6',     
    master_user='replicant',     
    master_password='replicant_password',     
    master_port=3306,     
    master_log_file='master-bin.000001',     
    master_log_pos=772,     
    master_connect_retry=10,     
    master_use_gtid=slave_pos;

نطلق ونتحقق من:

> start slave 'master01';
show slave 'master01' status\G;

يجب ألا يكون هناك أخطاء في الإجابة وستشير نقطتان إلى نجاح الإجراء:

Slave_IO_Running: Yes
Slave_SQL_Running: Yes

نشر عقد التطبيق

هناك عدة خيارات للنشر:

1. يفرقع، ينفجر
2. عامل ميناء الصورة
3. تحديث يدوي

Snap متاح بشكل أساسي لـ Ubuntu. إنه جيد جدًا في تقديم تطبيقات احتكارية معقدة ، ولكن بشكل افتراضي. لكن لديها ميزة مزعجة إلى حد ما في بيئة صناعية - فهي تقوم تلقائيًا بتحديث حزمها عدة مرات في اليوم. سيتعين عليك أيضًا الاطلاع على عمليات الوصول الإضافية إلى الخارج إذا كان لديك شبكة داخلية محددة بشكل صارم. في الوقت نفسه ، فإن عكس مستودعاتها في الداخل ليس تافهًا تمامًا.



نعم ، هناك قنوات اشتراك ، وإصدارات كبرى ، نظريًا ، لا ينبغي تبديلها ، بل التفكير فيها. أوصي بالتحكم الكامل في عملية التحديث ، خاصةً لأنها غالبًا ما تكون مصحوبة بتغيير في بنية البيانات في قاعدة البيانات.



يعد Docker-image خيارًا جيدًا ، خاصةً إذا كانت البنية الأساسية الخاصة بك تعمل بالفعل على Kubernetes. من المحتمل أن تنتقل عقدة Redis نفسها إلى الكتلة بعد خوادم التطبيق.



إذا لم يكن لديك البنية التحتية للقيام بذلك ، فإن التحديث والنشر يدويًا من tar.gz يعد أمرًا مريحًا للغاية ويمكن التحكم فيه.



تذكر أنك ستحتاج إلى تثبيت خادم ويب على خادم التطبيق للتعامل مع الطلبات الواردة. أوصي بحزمة من nginx + php-fpm7.4. مع أحدث إصدارات php-fmp ، تحسن الأداء والاستجابة بشكل ملحوظ.

تكوين SSL / TLS

يجب عليك بالتأكيد الاعتماد على TLS 1.3 إذا كنت تقوم بتثبيت جديد ولا توجد مشاكل مع حزم nginx التي تعتمد على حداثة نظام opensl. على وجه الخصوص ، تسمح ميزة 0-RTT وغيرها من الأشياء الجيدة في بعض الأحيان بتسريع إعادة اتصال العميل بشكل كبير بسبب التخزين المؤقت. الأمان أيضًا أعلى بسبب الاستغناء عن البروتوكولات القديمة.



سأقدم التكوين الفعلي لخادم تطبيق nginx ، الذي يتواصل مع الموازن عبر TLS:

صيانة روتينية

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



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

قم بإيقاف تشغيل الموازن في وقت أقل تحميل واستمر في التحديث.



بعد ذلك نقوم بتنفيذ عملية التحديث اليدوي عليها من الملف tar.gz الذي تم تنزيله ، مع حفظ ملف التكوين config.php. التحديث عبر الويب في عمليات التثبيت الكبيرة فكرة سيئة للغاية!

نقوم بالتحديث عبر سطر الأوامر:

sudo -u www-data php /var/www/nextcloud/occ upgrade

بعد ذلك ، قم بتشغيل الموازن وأرسل حركة المرور إلى الخادم المحدث. للقيام بذلك ، نقوم بإزالة جميع خوادم التطبيقات غير المحدثة من الموازنة:

upstream backend {
    ip_hash;

    server backend1_nextcloud.example.com;
    server backend2_nextcloud.example.com down;
    server backend3_nextcloud.example.com down;
    server backend4_nextcloud.example.com down;
}

يتم تحديث باقي العقد تدريجياً وتشغيلها. في هذه الحالة ، لا يلزم إجراء ترقية Occ! تحتاج فقط إلى استبدال ملفات php وحفظ التكوين.



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