من المحتمل أن كل شخص كان في حيرة واحدة على الأقل من خلال البحث عن تخزين عالي الأداء يحدده البرنامج عاجلاً أم آجلاً سمع عن DRBD ، أو ربما تعامل معه.
صحيح ، في ذروة شعبية Ceph و GlusterFS ، التي تعمل بشكل جيد من حيث المبدأ ، والأهم من خارج الصندوق ، نسي الجميع القليل عنها. علاوة على ذلك ، لم يدعم الإصدار السابق النسخ المتماثل لأكثر من عقدتين ، وبسبب هذا ، غالبًا ما واجهت مشاكل مع انقسام الدماغ ، والتي من الواضح أنها لم تضيف إلى شعبيتها.
الحل ليس جديداً ، ولكنه تنافسي جداً. مع تكاليف منخفضة نسبيًا لوحدة المعالجة المركزية وذاكرة الوصول العشوائي ، توفر DRBD مزامنة سريعة وآمنة حقًا على مستوى جهاز الحظر . طوال هذا الوقت ، لا يقف مطورو LINBIT - DRBD ساكنين ويقومون بتحسينه باستمرار. بدءًا من إصدار DRBD9 ، لم يعد مجرد مرآة شبكة ويصبح شيئًا أكثر.
أولاً ، سقطت فكرة إنشاء جهاز كتلة موزعة واحد للعديد من الخوادم في الخلفية ، والآن تحاول LINBIT توفير أدوات لتنظيم وإدارة العديد من أجهزة drbd في مجموعة يتم إنشاؤها فوق أقسام LVM و ZFS .
على سبيل المثال ، يدعم DRBD9 ما يصل إلى 32 نسخة متماثلة و RDMA وعقد بدون قرص وأدوات تنظيم جديدة تتيح لك استخدام اللقطات والترحيل عبر الإنترنت والمزيد.
على الرغم من حقيقة أن DRBD9 يحتوي على أدوات تكامل مع Proxmox و Kubernetes و OpenStack و OpenNebula ، في الوقت الحالي هم في وضع انتقالي ، عندما لا يتم دعم الأدوات الجديدة في كل مكان ، وسيتم الإعلان عن الأدوات القديمة على أنها موقوفة قريبًا جدًا. هذه هي DRBDmanage و Linstor .
سأستفيد من هذه اللحظة لعدم الخوض في تفاصيل كل منها كثيرًا ، ولكن لفحص بمزيد من التفصيل تكوين ومبادئ العمل مع DRBD9 نفسها. لا يزال يتعين عليك اكتشاف ذلك ، إذا كان ذلك فقط لأن التكوين المتحمل للأخطاء في وحدة تحكم Linstor يعني ضمنيًا تثبيته على أحد هذه الأجهزة.
في هذه المقالة ، أود أن أخبركم عن DRBD9 وإمكانية استخدامه في Proxmox بدون المكونات الإضافية الخارجية.
إدارة و لينستور
أولاً ، من الجدير بالذكر مرة أخرى عن DRBDmanage ، التي تتكامل بشكل جيد للغاية في Proxmox . يوفر LINBIT مكون DRBDmanage جاهز لـ Proxmox والذي يسمح لك باستخدام جميع وظائفه مباشرة من واجهة Proxmox .
يبدو الأمر مدهشًا حقًا ، ولكن للأسف هناك بعض العيوب.
- أولاً ، يجب تسمية أسماء
drbdpool أو مجموعة LVM أو تجمع ZFS بـ drbdpool . - عدم القدرة على استخدام أكثر من تجمع لكل عقدة
- نظرًا لتفاصيل الحل ، يمكن أن يكون حجم وحدة التحكم فقط على LVM عادي وليس خلاف ذلك
- مواطن الخلل في dbus الدورية ، والتي تستخدم عن كثب من قبل DRBDmanage للتفاعل مع العقد.
ونتيجة لذلك ، قررت LINBIT استبدال كل منطق DRBDmanage المعقد بتطبيق بسيط يتواصل مع العقد باستخدام اتصال tcp عادي ويعمل بدون أي سحر هناك. لذلك كان هناك لينستور .
يعمل Linstor بشكل جيد للغاية. لسوء الحظ ، اختار المطورون لغة جافا باعتبارها اللغة الرئيسية لكتابة خادم Linstor ، ولكن لا تدع هذا يخيفك ، لأن Linstor نفسها لا تهتم سوى بتوزيع تكوينات DRBD وتقطيع أقسام LVM / ZFS على العقد.
كلا الحلين مجانيان ويتم توزيعهما بموجب ترخيص GPL3 المجاني .
يمكنك القراءة عن كل واحد منهم وعن إعداد المكون الإضافي المذكور أعلاه لـ Proxmox على موقع Proxmox الرسمي
تجاوز الفشل خادم NFS
لسوء الحظ ، في وقت كتابة هذا التقرير ، لم يكن لدى Linstor سوى التكامل مع Kubernetes . ولكن في نهاية العام ، من المتوقع أن تكون هناك برامج تشغيل لبقية أنظمة Proxmox و OpenNebula و OpenStack .
ولكن حتى الآن لا يوجد حل جاهز ، لكننا بطريقة أو بأخرى لا نحب الحل القديم. دعونا نحاول استخدام DRBD9 بالطريقة القديمة لتنظيم وصول NFS إلى قسم مشترك.
ومع ذلك ، فإن هذا الحل سيثبت أيضًا أنه لا يخلو من المزايا ، لأن خادم NFS سيسمح لك بتنظيم الوصول التنافسي إلى نظام الملفات في المستودع من عدة خوادم دون الحاجة إلى أنظمة ملفات معقدة معقدة مع DLM ، مثل OCFS و GFS2.
في هذه الحالة ، ستتمكن من تبديل أدوار العقدة الأساسية / الثانوية ببساطة عن طريق ترحيل الحاوية مع خادم NFS في واجهة Proxmox.
يمكنك أيضًا تخزين أي ملفات داخل نظام الملفات هذا ، بالإضافة إلى الأقراص الافتراضية والنسخ الاحتياطية.
في حالة استخدام Kubernetes ، ستتمكن من ترتيب وصول ReadWriteMany الخاص بك إلى PersistentVolumes .
حاويات Proxmox و LXC
السؤال الآن: لماذا Proxmox؟
من حيث المبدأ ، لبناء مثل هذا المخطط ، يمكننا استخدام Kubernetes وكذلك المخطط المعتاد مع مدير الكتلة. لكن Proxmox يوفر واجهة جاهزة متعددة الوظائف للغاية وفي نفس الوقت واجهة بسيطة وبديهية لكل ما تحتاجه تقريبًا. إنه خارج الصندوق قادر على التجميع ويدعم آلية المبارزة القائمة على softdog. وعند استخدام حاويات LXC ، يتيح لك تحقيق الحد الأدنى من المهلات عند التبديل.
لن يكون للحل الناتج نقطة واحدة من الفشل .
في الواقع ، سنستخدم Proxmox في المقام الأول كمدير مجموعة ، حيث يمكننا التفكير في حاوية LXC منفصلة كخدمة تعمل في مجموعة HA الكلاسيكية ، فقط مع اختلاف أن الحاوية تأتي أيضًا مع نظام الجذر الخاص بها . أي أنك لا تحتاج إلى تثبيت العديد من مثيلات الخدمة على كل خادم بشكل منفصل ، يمكنك القيام بذلك مرة واحدة فقط داخل الحاوية.
إذا كنت قد عملت في أي وقت مضى مع برنامج مدير الكتلة وتوفير HA للتطبيقات ، فسوف تفهم ما أعنيه.
مخطط عام
سيشبه الحل الذي نقدمه مخطط النسخ المتماثل القياسي لقاعدة بيانات.
- لدينا ثلاث عقد
- تحتوي كل عقدة على جهاز drbd موزع.
- الجهاز به نظام ملفات عادي ( ext4 )
- يمكن أن يكون خادم واحد فقط سيد
- يتم تشغيل خادم NFS في حاوية LXC على المعالج.
- تصل جميع العقد إلى الجهاز بدقة من خلال NFS.
- إذا لزم الأمر ، يمكن أن ينتقل المعالج إلى عقدة أخرى ، إلى جانب خادم NFS
يحتوي DRBD9 على ميزة رائعة جدًا تبسط كل شيء بشكل كبير:
يصبح جهاز drbd تلقائيًا أساسيًا في الوقت الذي يتم فيه تركيبه على بعض العقدة. إذا تم وضع علامة على الجهاز على أنه أساسي ، فإن أي محاولة لتركيبه على عقدة أخرى ستؤدي إلى خطأ في الوصول. وهذا يضمن الحظر والحماية المضمونة ضد الوصول المتزامن للجهاز.
لماذا يبسط كل هذا إلى حد كبير؟ لأنه عندما تبدأ الحاوية ، يقوم Proxmox تلقائيًا بتثبيت هذا الجهاز ويصبح أساسيًا في هذه العقدة ، وعندما تتوقف الحاوية ، يتم إلغاء تحميله على العكس ويصبح الجهاز ثانويًا مرة أخرى.
وبالتالي ، لم نعد بحاجة للقلق بشأن تبديل الأجهزة الأساسية / الثانوية ، فسيقوم Proxmox بذلك تلقائيًا ، مرحى!
إعداد DRBD
حسنًا ، لقد توصلنا إلى الفكرة ، فلننتقل الآن إلى التنفيذ.
بشكل افتراضي ، يتم توفير الإصدار الثامن من drbd مع نواة لينكس ، للأسف لا يناسبنا ونحن بحاجة إلى تثبيت الإصدار التاسع من الوحدة.
قم بتوصيل مستودع LINBIT وقم بتثبيت كل ما تحتاجه:
wget -O- https://packages.linbit.com/package-signing-pubkey.asc | apt-key add - echo "deb http://packages.linbit.com/proxmox/ proxmox-5 drbd-9.0" \ > /etc/apt/sources.list.d/linbit.list apt-get update && apt-get -y install pve-headers drbd-dkms drbd-utils drbdtop
pve-headers kernel اللازمة لبناء الوحدةdrbd-dkms - وحدة kernel في شكل DKMSdrbd-utils - المرافق الأساسية لإدارة DRBDdrbdtop هو أداة تفاعلية مثل القمة لـ DRBD فقط
بعد تثبيت الوحدة ، سوف نتحقق مما إذا كان كل شيء مناسبًا لها:
إذا رأيت الإصدار الثامن في إخراج الأمر ، حدث خطأ ما وتم تحميل وحدة kernel داخل الشجرة . تحقق من dkms status لمعرفة السبب.
سيكون لكل عقدة لدينا نفس جهاز drbd يعمل على الأقسام العادية. نحتاج أولاً إلى إعداد هذا القسم لـ drbd على كل عقدة.
يمكن أن يكون هذا القسم أي جهاز كتلة ، يمكن أن يكون lvm أو zvol أو قسم القرص أو القرص بأكمله. في هذه المقالة سأستخدم قرص nvme منفصل مع قسم تحت drbd: /dev/nvme1n1p1
تجدر الإشارة إلى أن أسماء الأجهزة تميل إلى التغيير في بعض الأحيان ، لذلك من الأفضل أن تأخذها على الفور كعادة لاستخدام ارتباط رمزي ثابت للجهاز.
يمكنك العثور على مثل هذا الارتباط الرمزي لـ /dev/nvme1n1p1 بهذه الطريقة:
نحن نصف مواردنا على جميع العقد الثلاث:
من المستحسن استخدام شبكة منفصلة لمزامنة drbd.
الآن قم بإنشاء بيانات التعريف لـ drbd وقم بتشغيلها:
كرر هذه الخطوات على العقد الثلاث وتحقق من الحالة:
الآن قرصنا غير المتناسق موجود على جميع العقد الثلاث ، وذلك لأن drbd لا يعرف أي قرص يجب أن يؤخذ على أنه الأصلي. يجب وضع علامة على أحدها على أنه أساسي حتى تتم مزامنة حالته مع العقد الأخرى:
drbdadm primary --force nfs1 drbdadm secondary nfs1
مباشرة بعد ذلك ، ستبدأ المزامنة :
لا يجب أن ننتظر حتى ننتهي ويمكننا تنفيذ خطوات أخرى بالتوازي. يمكن تنفيذها على أي عقدة ، بغض النظر عن حالتها الحالية للقرص المحلي في DRBD. ستتم إعادة توجيه جميع الطلبات تلقائيًا إلى الجهاز بحالة UpToDate .
لا تنسى تفعيل التشغيل التلقائي لخدمة drbd على العقد:
systemctl enable drbd.service
تكوين حاوية LXC
سنحذف جزء التهيئة من مجموعة Proxmox من ثلاث عقد ، وهذا الجزء موصوف جيدًا في الويكي الرسمي
كما قلت من قبل ، سيعمل خادم NFS في حاوية LXC . /dev/drbd100 بالحاوية على الجهاز /dev/drbd100 الذي /dev/drbd100 للتو.
نحتاج أولاً إلى إنشاء نظام ملفات عليه:
mkfs -t ext4 -O mmp -E mmp_update_interval=5 /dev/drbd100
يتضمن Proxmox بشكل افتراضي حماية متعددة على مستوى نظام الملفات ، من حيث المبدأ ، يمكننا الاستغناء عنها ، لأنه تتمتع DRBD بحمايتها الخاصة بشكل افتراضي ، فهي ببساطة تمنع الأساسي الثاني للجهاز ، ولكن الحذر لا يؤذينا.
الآن قم بتنزيل قالب Ubuntu:
# wget http://download.proxmox.com/images/system/ubuntu-16.04-standard_16.04-1_amd64.tar.gz -P /var/lib/vz/template/cache/
وأنشئ حاويتنا منه:
pct create 101 local:vztmpl/ubuntu-16.04-standard_16.04-1_amd64.tar.gz \ --hostname=nfs1 \ --net0=name=eth0,bridge=vmbr0,gw=192.168.1.1,ip=192.168.1.11/24 \ --rootfs=volume=/dev/drbd100,shared=1
في هذا الأمر ، نشير إلى أن نظام الجذر /dev/drbd100 سيكون على الجهاز /dev/drbd100 وإضافة المعلمة shared=1 للسماح /dev/drbd100 الحاوية بين العقد.
إذا حدث خطأ ما ، فيمكنك دائمًا إصلاحه من خلال واجهة /etc/pve/lxc/101.conf أو في /etc/pve/lxc/101.conf حاوية /etc/pve/lxc/101.conf
سيقوم Proxmox بفك القالب وإعداد نظام جذر الحاوية لنا. بعد ذلك يمكننا إطلاق الحاوية الخاصة بنا:
pct start 101
تكوين خادم NFS.
افتراضيًا ، لا يسمح Proxmox لخادم NFS بالعمل في الحاوية ، ولكن هناك عدة طرق لتمكينه.
أحدها فقط لإضافة lxc.apparmor.profile: unconfined /etc/pve/lxc/100.conf الخاص /etc/pve/lxc/100.conf .
أو يمكننا تمكين NFS لجميع الحاويات على أساس مستمر ، لذلك نحن بحاجة إلى تحديث القالب القياسي لـ LXC على جميع العقد ، أضف الأسطر التالية إلى /etc/apparmor.d/lxc/lxc-default-cgns :
mount fstype=nfs, mount fstype=nfs4, mount fstype=nfsd, mount fstype=rpc_pipefs,
بعد التغييرات ، أعد تشغيل الحاوية:
pct shutdown 101 pct start 101
الآن دعونا تسجيل الدخول:
pct exec 101 bash
تثبيت التحديثات وخادم NFS :
apt-get update apt-get -y upgrade apt-get -y install nfs-kernel-server
إنشاء تصدير :
echo '/data *(rw,no_root_squash,no_subtree_check)' >> /etc/exports mkdir /data exportfs -a
إعداد HA
في وقت كتابة هذا التقرير ، يحتوي proxmox HA-manager على خطأ لا يسمح لحاوية HA بإكمال عملها بنجاح ، ونتيجة لذلك ، تمنع عمليات مساحة النواة لخادم nfs التي لم تُقتل تمامًا جهاز drbd من مغادرة المرحلة الثانوية . إذا كنت قد واجهت مثل هذا الموقف بالفعل ، فلا داعي للذعر وتنفيذ killall -9 nfsd على العقدة حيث تم إطلاق الحاوية ، ومن ثم يجب أن "يطلق" جهاز drbd وسيذهب إلى الثانوي .
لإصلاح هذا الخطأ ، قم بتشغيل الأوامر التالية على جميع العقد:
sed -i 's/forceStop => 1,/forceStop => 0,/' /usr/share/perl5/PVE/HA/Resources/PVECT.pm systemctl restart pve-ha-lrm.service
الآن يمكننا الانتقال إلى تكوين HA-manager . لنقم بإنشاء مجموعة HA منفصلة لجهازنا:
ha-manager groupadd nfs1 --nodes pve1,pve2,pve3 --nofailback=1 --restricted=1
سيعمل موردنا فقط على العقد المحددة لهذه المجموعة. أضف حاويتنا لهذه المجموعة:
ha-manager add ct:101 --group=nfs1 --max_relocate=3 --max_restart=3
هذا كل شيء. بسيطة ، أليس كذلك؟
يمكن توصيل كرة nfs الناتجة على الفور بـ Proxmox لتخزين وتشغيل الأجهزة والحاويات الافتراضية الأخرى.
التوصيات والضبط
DRBD
كما أشرت أعلاه ، من المستحسن دائمًا استخدام شبكة منفصلة للنسخ المتماثل. من المستحسن للغاية استخدام محولات شبكة 10 جيجابت ، وإلا فسوف تواجه سرعة المنفذ.
إذا كان النسخ المتماثل يبدو بطيئًا بما فيه الكفاية ، فجرب بعض الخيارات لـ DRBD . هنا هو التكوين ، وهو في رأيي الأمثل لشبكة 10G الخاصة بي:
# cat /etc/drbd.d/global_common.conf global { usage-count yes; udev-always-use-vnr; } common { handlers { } startup { } options { } disk { c-fill-target 10M; c-max-rate 720M; c-plan-ahead 10; c-min-rate 20M; } net { max-buffers 36k; sndbuf-size 1024k; rcvbuf-size 2048k; } }
يمكنك الحصول على مزيد من المعلومات حول كل معلمة من وثائق DRBD الرسمية.
خادم NFS
لتسريع عملية خادم NFS ، قد يساعد في زيادة العدد الإجمالي لمثيلات خادم NFS قيد التشغيل. بشكل افتراضي - 8 ، شخصيًا ، ساعدني على زيادة هذا العدد إلى 64 .
لتحقيق ذلك ، قم بتحديث RPCNFSDCOUNT=64 معلمة في /etc/default/nfs-kernel-server .
وإعادة الشياطين:
systemctl restart nfs-utils systemctl restart nfs-server
NFSv3 مقابل NFSv4
تعرف الفرق بين NFSv3 و NFSv4 ؟
- NFSv3 هو بروتوكول عديم الجنسية ؛ وكقاعدة عامة ، فإنه يتحمل بشكل أفضل حالات الفشل ويتعافى بشكل أسرع.
- NFSv4 هو بروتوكول ذو حالة ، وهو يعمل بشكل أسرع ويمكن ربطه بمنافذ TCP معينة ، ولكن نظرًا لوجود الحالة ، فإنه أكثر حساسية للإخفاقات. كما أن لديها القدرة على استخدام المصادقة باستخدام Kerberos ومجموعة من الميزات الأخرى المثيرة للاهتمام.
ومع ذلك ، عند تشغيل showmount -e nfs_server ، يتم استخدام بروتوكول NFSv3. يستخدم Proxmox أيضًا NFSv3. كما يُستخدم NFSv3 بشكل شائع لتنظيم أجهزة تمهيد الشبكة.
بشكل عام ، إذا لم يكن لديك سبب معين لاستخدام NFSv4 ، فحاول استخدام NFSv3 لأنه أقل إيلامًا لأي إخفاقات بسبب عدم وجود حالة على هذا النحو.
يمكنك تركيب الكرة باستخدام NFSv3 بتحديد المعلمة -o vers=3 لأمر mount :
mount -o vers=3 nfs_server:/share /mnt
إذا كنت ترغب في ذلك ، يمكنك تعطيل NFSv4 للخادم على الإطلاق ، للقيام بذلك ، قم بإضافة الخيار --no-nfs-version 4 إلى متغير --no-nfs-version 4 وأعد تشغيل الخادم ، على سبيل المثال:
RPCNFSDCOUNT="64 --no-nfs-version 4"
بروتوكول iSCSI و LVM
وبالمثل ، يمكن تكوين برنامج tgt منتظم داخل الحاوية ، وستنتج iSCSI أداءً أعلى بكثير لعمليات الإدخال / الإخراج ، وستعمل الحاوية بسلاسة أكبر لأن خادم tgt يعمل تمامًا في مساحة المستخدم.
بشكل عام ، يتم تقطيع LUN المُصدّر إلى قطع عديدة باستخدام LVM . ومع ذلك ، هناك العديد من الفروق الدقيقة التي يجب مراعاتها ، على سبيل المثال: كيف يتم توفير أقفال LVM لمشاركة مجموعة مصدرة على مضيفين متعددين.
ربما هذه وغيرها من الفروق الدقيقة التي سأصفها في المقالة التالية .