إلى الأرض من السحاب: نقل Proxmox إلى كمبيوتر في مكتب في الاتحاد الروسي

يوم سعيد هبر!



أود أن ألفت انتباهكم إلى تاريخ موجز لنقل خادم افتراضي قائم على Proxmox من Hetzner إلى الاتحاد الروسي إلى خادم افتراضي موجود في رف في مكتب الشركة.

باختصار حول أسباب اختيار Proxmox وخصائصه. ويكيبيديا حول نظام المحاكاة الافتراضية Proxmox .



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



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



لقد امتدحت النظام ، وأطلب الباقي تحت القطع.



فيما يتعلق بنمو سعر صرف اليورو ، بدأت الخدمة المستأجرة لتوفير أماكن عمل بعيدة على خادم مستأجر خصيصًا في الارتفاع. بعد الحسابات ، تقرر شراء "معالج 8 x AMD Ryzen 5 1400 رباعي النواة (1 مقبس)" ، 2 * SSD M.2 1 تيرابايت + رافعات للتثبيت في منفذ PCI-E ، 32 جيجا بايت رام ... في السحابة ، نفس وحدة المعالجة المركزية (وحدات المعالجة المركزية) للجهاز 8 × Intel® Core (TM) i7 CPU 920 @ 2.67 جيجاهرتز (1 مقبس) ، 2 * 2 تيرابايت HDD ، 47.16 جيجا بايت رام.





تعتمد إعدادات تخزين Proxmox الجاهزة على وحدات تخزين LVM ، على الرغم من أنه من الممكن استخدام مجلد نظام التشغيل وخيارات نظام الملفات الأخرى لتخزين الصور ، وحتى موارد FTP الخارجية (المزيد حول هذا أدناه) على هذا الجهاز ، يتم تكوين قسم LVM يسمى "البيانات" على القرص 1 ويتم تسجيل مخزن بيانات proxmox المسمى "البيانات" ، ويقوم بتخزين صور القرص للأجهزة الظاهرية. يتم حفظ النسخ الاحتياطية (لقطات) للأجهزة الظاهرية على القرص الثاني وفقًا لجدول زمني معين.



في السحابة ، يتم تشغيل عقدتين للعميل مع 4 وحدات معالجة مركزية 16 جيجابايت من ذاكرة الوصول العشوائي لكل منهما ونوع معالج core2duo الأقراص الافتراضية الخاصة بهم هي 2 تيرابايت بالكامل.





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

• العقدة 1: 200 جيجا بايت + 400 جيجا بايت + 200 جيجا بايت ؛ حجم النسخ الاحتياطي 175 جيجابايت
• العقدة 2: 200 جيجا بايت + 500 جيجا بايت ؛ حجم النسخ الاحتياطي 7 جيجا بايت ؛

نطلب من العميل منح الوصول وتحديد أن Node 2 disk 2 غير مستخدم ، على الرغم من أنه نشط. لذلك ، على الجهاز الأصلي في السحابة ، يجب عليك تكوين نظام التشغيل الضيف بشكل صحيح وتعطيل قرص 500 جيجابايت في واجهة الويب Proxmox. في هذه الحالة ، سيظل مرتبطًا بالعقدة 2 ، ولكن سيتم "تعطيله" ، أي أن العقدة 2 لن تراها.



في واجهة الويب ، يتم عمل نسخة احتياطية من التغييرات التي تم إجراؤها بأقصى ضغط لصورة القرص في GZip. نحصل على نفس 6 جيجا بايت في الأرشيف ، وهو أمر متوقع بالفعل.



مساحة المكتب بها مساحة تخزين مع وصول FTP ، 1 تيرابايت مخصص لتحميل الصور المؤرشفة للأجهزة الافتراضية ، لذلك تقرر توصيل هذا التخزين عبر FTP بالمجلد "/ bkps" في نظام التشغيل السحابي.







على خادم جهاز الاستقبال ، يتم تكوين الأقراص على النحو التالي: LVM data1 on 1TB-> Storage data1؛ بيانات LVM 2 مؤقتًا على SSD 256 جيجا بايت -> بيانات التخزين 2. بعد نقل صورة الجهاز إلى كرة FTP ، قم بتوصيلها باستخدام الطريقة الموضحة أعلاه بدليل / bkps لخادم الاستقبال. في تخزين الخادم المستلم ، قم بتوصيل الدليل "/ bkps" كمخزن للنسخ الاحتياطي وحاول استعادته إلى العقدة 2 التي تم إنشاؤها مسبقًا من واجهة الويب. المشاكل الأولى:

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

فشلت محاولة تحرير الملف "2.tar.bz2 Node Archive" في MC. أحاول على عقدة متوقفة 2 من وحدة تحكم خادم المحاكاة الافتراضية باستخدام

dd if=/data/vm-101-disk-0 | grep -9cf > /bkps/vm-101-disk-0.img.gz
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

تحميل إلى FTP ونشره على خادم الاستقبال من وحدة التحكم إلى الصورة التي تم إنشاؤها على بيانات LVM 2 بالاسم "/ dev / data2 / vm-101-disk0" باستخدام الأوامر:

cd /bkps
ls | grep vm101
gunzip -c vm101-disk-0.img.gz | dd of=/dev/data2/vm101-disk-0
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

في نهاية العملية ، بدأت Node 2 بشكل صحيح ، وبدأ نظام التشغيل الضيف العمل دون مزيد من التلاعب.



مع Node 1 ، أصبحت العملية أكثر تعقيدًا ، نظرًا لاستخدام DD لم يكن من الممكن توسيع القرص 2 إلى 400 جيجا بايت. ما هو السبب لا يزال مجهولا بالنسبة لي. منذ نفاد الوقت ، تم اتخاذ قرار سليمان: إعادة تسمية تخزين خادم الاستقبال من "data1" إلى "بيانات" ونشر العقدة 1 من النسخة الاحتياطية. في هذا التكوين ، سارت العملية على ما يرام ، وبدأ الجهاز ويعمل بشكل صحيح ، ويرى جميع الأقراص المتصلة.



وختاماً ، باختصار عن ترحيل الأقراص داخل الخادم بين المخازن.

1. نوقف العقدة.
2. في إعدادات التكوين الخاصة بالعقدة ، نهدف إلى القرص الذي يجب ترحيله. من الغريب أنه يعمل فقط على قرص متصل ، ولا يمكن ترحيل القرص غير "المرفق".
3. نختار التخزين المستهدف والنظام ينقله إلى التخزين المطلوب.

بناءً على الاستنتاج ، كان من الممكن التحرك على هذا النحو (طريقة إضافية للتحرك للقراء الأكثر إصرارًا):

1. على الخادم في السحابة ، ابدأ الترحيل إلى دليل عشوائي لمحركات أقراص Node1 و Node2 ؛
2. نقلها عن طريق نسخها إلى FTP (ربما تم ضغطها بنفس gzip لتقليل حركة المرور) ؛
3. نشر ملف قرص افتراضي على خادم FTP إذا قمنا بنقل صورة مضغوطة ؛
4. الاتصال (بدون البدء) بالعقدة المطلوبة واضغط على زر "ترحيل".

ستؤدي هذه التلاعبات إلى ترحيل منتظم لصورة القرص الافتراضي إلى التخزين الذي نحتاجه.



شكرا لاهتمامكم ، وآمل أن يجد شخص ما هذا النص مفيدا.