لا يكتب زملائي الرائعون من قسم الدعم الفني ضررًا فحسب ، بل أيضًا نصائح وحيل مفيدة لإعداد Veeam Backup & Replication. منذ نشر
المقال للمستخدمين المبتدئين ، انتقل مؤلفه ، Evgeny Ivanov ، مع استمراره في العمل مع الفريق الروماني في بوخارست ، من منصب كبير المهندسين إلى منصب قائد الفريق. لكن يوجين لم يترك المجال الفني والأدبي ، والذي يشكره كثيرًا!
تحتوي مقالة Zhenya الجديدة على توصيات لأخصائيي النسخ الاحتياطي والتكرار Veeam ذوي الخبرة الذين يواجهون مهمة الاستفادة القصوى من موارد البنية التحتية الاحتياطية. ومع ذلك ، ستكون المقالة مفيدة لأولئك الذين يخططون فقط لتثبيت منتجنا وتكوينه.
تحسين توزيع الحمل في أوقات الأنابيب الدافئةللحصول على نصائح مفيدة ، مرحبا بك في القط.
حول مزايا التثبيت الموزع
Veeam Backup & Replication هو برنامج معياري يتكون من مكونات مختلفة ، يؤدي كل منها وظائف محددة. ومن بين هذه المكونات المدير الإداري المركزي لخادم النسخ الاحتياطي Veeam ، والخادم الوكيل ، والمستودع ، ومسرع WAN وغيرها. يمكن تثبيت عدد من المكونات على جهاز واحد (بالطبع ، قوي جدًا) ، وهو ما يفعله العديد من المستخدمين. ومع ذلك ، فإن التركيب الموزع له مزاياه ، وهي:
- بالنسبة للشركات التي لديها شبكة من الفروع ، يصبح من الممكن تثبيت المكونات الضرورية محليًا في هذه الفروع. وهذا يساعد على تحسين حركة المرور ، وتنظيم معظمها مرة أخرى محليًا.
- مع نمو بنيتك الأساسية ، تحتاج إلى توسيع نطاق حل النسخ الاحتياطي. إذا استغرق النسخ الاحتياطي وقتًا أطول (تنمو "نافذة النسخ الاحتياطي") ، يمكنك تثبيت خادم وكيل إضافي. إذا كنت بحاجة إلى زيادة سعة مستودع النسخ الاحتياطي ، يمكنك تكوين مستودع نسخ احتياطي صغير الحجم وإضافة نطاقات جديدة حسب الحاجة.
- بالنسبة لبعض المكونات ، يمكنك ضمان التوفر المستمر (التوفر العالي) - على سبيل المثال ، إذا كان لديك العديد من خوادم الوكيل التي تم نشرها وإيقاف أحدها فجأة ، سيستمر البعض الآخر في العمل ، ولن يتأثر النسخ الاحتياطي.
يجب أن يوضع في الاعتبار أن الأنظمة الموزعة ستكون فعالة فقط مع توزيع حمل معقول. خلاف ذلك ، يمكن أن تحدث اختناقات ، الحمل الزائد للمكونات الفردية - وهذا أمر محفوف بانخفاض عام في الإنتاجية والتباطؤ.
كيف يتم نقل البيانات؟
للحصول على فكرة أوضح عن مكان ومكان نقل البيانات أثناء عملية النسخ الاحتياطي ، ضع في اعتبارك هذا الرسم التخطيطي (على سبيل المثال ، خذ البنية التحتية على منصة vSphere):
كما ترى ، يتم نقل البيانات من موقع المصدر (المصدر) إلى الهدف (الهدف) باستخدام "وكلاء النقل" (VeeamAgent.exe) الذين يعملون في كلا الموقعين. لذلك ، عند تشغيل مهمة النسخ الاحتياطي ، يحدث ما يلي:
- يعمل وكيل النقل "المصدر" على خادم وكيل ؛ يقرأ البيانات من مخزن البيانات ، ويقوم بالضغط وإلغاء البيانات المكررة ، ويرسل البيانات في هذا النموذج إلى وكيل النقل "المستهدف".
- يعمل وكيل النقل "الهدف" مباشرة على المستودع (Windows / Linux) أو على البوابة (خادم البوابة) ، إذا تم استخدام مشاركة CIFS. يقوم هذا الوكيل بدوره بتنفيذ عملية إلغاء البيانات المكررة من جانبه ويحفظ البيانات في ملف النسخ الاحتياطي (.VBK و .VIB وما إلى ذلك).
وبالتالي ، هناك مكونان متورطان دائمًا في نقل البيانات ، حتى إذا كانت موجودة بالفعل على نفس الجهاز. يجب مراعاة ذلك عند التخطيط لنشر الحل.
موازنة التحميل بين الخادم الوكيل والمستودع
أولاً ، دعنا نحدد مفهوم "المهمة". في مصطلحات Veeam Backup & Replication ، تقوم كل مهمة بمعالجة قرص واحد من جهاز افتراضي. بمعنى ، إذا كان لديك مهمة نسخ احتياطي (مهمة) ، والتي تتضمن 5 أجهزة VM مع قرصين لكل منهما ، فهذا يعني أنه يجب عليك معالجة 10 مهام (وإذا كان الجهاز يحتوي على قرص واحد فقط ، فإن مهمة واحدة = 1 VM). Veeam Backup & Replication قادر على معالجة العديد من المهام بالتوازي ، لكن عددهم ، بالطبع ، ليس لانهائي.
لكل خادم وكيل في خصائصه ، يمكنك تحديد الحد الأقصى لعدد المهام للتنفيذ المتوازي:
بالنسبة لعمليات النسخ الاحتياطي القياسية ، سيكون نفس التفسير للمستودع: مهمة واحدة هي نقل البيانات من قرص افتراضي واحد. في الواجهة ، تبدو متشابهة جدًا:
هنا يجب أن نصلح
قاعدة مهمة جدًا
رقم 1: تأكد من التوازن عند تعيين موارد الوكيل والمستودع وعند تحديد الحد الأقصى لعدد المهام للمعالجة المتوازية!مثال
افترض أن لديك 3 خوادم وكيلة ، يمكن لكل منها معالجة 4 مهام بالتوازي (أي ما مجموعه 12 قرصًا افتراضيًا لأجهزة VM المصدر). ولكن تم تكوين المستودع لمعالجة 4 مهام فقط بالتوازي (هذه ، بالمناسبة ، هي القيمة الافتراضية). باستخدام هذه الإعدادات ، سيتم حفظ 4 محركات أقراص فقط بالتوازي من موقع المصدر إلى الوجهة ، على الرغم من أنها يمكن أن تكون لجميع الـ 12. أي أنه سيتم تحميل الموارد بشكل أقل.
ومع ذلك ، عندما يتعلق الأمر بإنشاء نسخة احتياطية اصطناعية كاملة (وعمليات مماثلة) ، فإن مفهوم المهمة المتعلقة بالمخزون له معنى مختلف قليلاً. نتذكر أن مثل هذه العمليات لا تتضمن بروكسيات ، ولكن يتم تنفيذها محليًا في المستودع (Windows أو Linux) أو (في حالة مشاركة CIFS) باستخدام بوابة.
في هذا الخيار ، عند بناء سلسلة نسخ احتياطي عادية ، مهمة = مهمة نسخ احتياطي. وهذا يعني أن حد 4 مهام للمعالجة المتوازية هنا سيعني أنه يمكن إنشاء نسخ احتياطية اصطناعية لـ 4 مهام نسخ احتياطي في وقت واحد على المستودع.
عند بناء سلسلة من النسخ الاحتياطية المتحللة وفقًا للأجهزة الافتراضية الأصلية (ما يسمى "التخزين لكل VM" - لكل VM) ، المهمة = 1 VM. وهذا يعني أن حد 4 مهام للمعالجة المتوازية هنا يعني أنه يمكن إنشاء 4 ملفات VBK لـ 4 أجهزة افتراضية على المستودع في نفس الوقت.
وبالتالي ، نصل إلى
القاعدة رقم 2: اعتمادًا على إعدادات النسخ الاحتياطي ، يمكن أن يعني العدد نفسه من المهام حملاً مختلفًا تمامًا في المستودع. لذلك ، عند تخطيط الموارد ، تحتاج بالتأكيد إلى التحقق من هذه الإعدادات نفسها: وضع النسخ الاحتياطي ، جدول المهام ، طريقة لتنظيم سلاسل النسخ الاحتياطي.ملاحظة: على عكس إعدادات الوكيل ، يمكن للمستودع تعطيل الحد الأقصى لعدد المهام. في هذه الحالة ، سيقبل المستودع جميع البيانات الواردة من خوادم الوكيل. ولكن هذه ليست سوى تحرر واضح من القيود ، حيث أن هناك خطر الحمل الزائد للمستودع والفشل في عمل مهام النسخ الاحتياطي. لذلك ، لا نوصي بشدة بالتخلي عن هذا الحد.
مثال آخر
افترض أن لديك مهمة نسخ احتياطي تتضمن عددًا كبيرًا إلى حد ما من VMs مع إجمالي 100 قرص افتراضي. في نفس الوقت ، يتم تكوين المستودع لتخزين سلاسل النسخ الاحتياطي "باليد" (لكل VM). إعدادات المعالجة المتوازية هي كما يلي: بالنسبة للوكيل - 10 أقراص في المرة الواحدة ، وبالنسبة للمستودع - لا توجد قيود. أثناء النسخ الاحتياطي التدريجي ، سيكون الحمل على المستودع محدودًا بسبب إعدادات الوكيل ، وبالتالي سيتم الحفاظ على الرصيد. ولكن بعد ذلك تأتي لحظة إنشاء نسخة احتياطية كاملة اصطناعية. لا تستخدم هذه النسخة الاحتياطية وكيلًا ، وتتم جميع العمليات لإنشاء "المواد التركيبية" حصريًا على المستودع. نظرًا لعدم وجود قيود على المعالجة المتوازية لمهام المستودع ، سيحاول خادم المستودع معالجة المئات بالكامل في المرة الواحدة. سيتطلب هذا ضغطًا كبيرًا على الموارد وسيؤدي على الأرجح إلى الحمل الزائد.
ميزات استخدام حصة CIFS كمستودع
إذا كنت تعمل مع مستودع يعتمد على خادم Windows أو Linux ، فإن وكيل "الهدف" يبدأ مباشرة على هذا الخادم. ومع ذلك ، إذا كنت تستخدم مجلد مشاركة CIFS (مشاركة CIFS) كمستودع ، فإن وكيل "الهدف" يبدأ على جهاز مصمم خصيصًا لهذا الغرض - وهذا هو ما يسمى "البوابة" ، التي ستتلقى دفق البيانات الواردة من الوكيل على جانب VM المصدر. سيتلقى الوكيل "الهدف" هذه البيانات ثم يرسل كتل البيانات إلى كرة CIFS. يجب وضع هذا الجهاز الإضافي بالقرب من الجهاز الذي يوفر مجلدات SMB المشتركة قدر الإمكان - وهذا مهم بشكل خاص للبرامج النصية التي تستخدم اتصال WAN.
القاعدة رقم 3: لا يجب وضع الجهاز المساعد (proxy \ gateway) على موقع واحد ، ومشاركة مجلد CIFS المشترك على موقع آخر (بما في ذلك على السحابة) - وإلا فستواجه مشاكل مستمرة في الشبكة.يمكنك أيضًا تطبيق العبّارات على جميع الاعتبارات المذكورة أعلاه لموازنة الحمل على النظام. بالإضافة إلى ذلك ، يجب أن تضع في اعتبارك أن البوابة لها إعدادان إضافيان: يمكن تعيين الخادم لها بشكل صريح أو تلقائي محدد:
من حيث المبدأ ، يمكن استخدام أي خادم Windows مدرج في البنية التحتية للنسخ الاحتياطي لـ Veeam كمدخل. اعتمادًا على سيناريو النشر ، قد يكون أحد الخيارات مناسبًا لك:
- خادم محدد صراحة - هذا ، بالطبع ، يبسط الكثير ، لأنك ستعرف بالضبط الجهاز الذي يعمل عليه العامل "الهدف". يُوصى بهذا الخيار ، على وجه الخصوص ، للحالات التي يُسمح فيها بالوصول إلى الكرة من خوادم معينة فقط ، وكذلك للسيناريوهات ذات البنية التحتية الموزعة - ربما تريد استخدام الوكيل على جهاز يقع بالقرب من خادم الملفات مع الهدف كأشخاص معقولين الكرة.
- الخادم المحدد تلقائيًا (خيار التحديد التلقائي ). هنا ، تأخذ الأمور منعطفًا مثيرًا للاهتمام: إذا كنت تستخدم العديد من خوادم الوكيل ، فإن اختيار هذا الخيار ، على ما يبدو ، يؤدي إلى حقيقة أن البرنامج يستخدم أكثر من بوابة واحدة ، وتوزيع الحمل. ألاحظ أن "تلقائيًا" لا تعني "تعسفيًا" - يتم تطبيق قواعد اختيار محددة تمامًا هنا.
كيف يعمل؟
يبدأ العامل "الهدف" على الخادم الوكيل الذي يقوم بإجراء النسخ الاحتياطي.
- في حالة سلسلة النسخ الاحتياطي المعتادة ، يكون المنطق هو: إذا كانت هناك العديد من المهام التي يتم تنفيذها في وقت واحد ، كل منها مع خادم وكيل خاص بها ، فيمكنك تشغيل العديد من الوكلاء "المستهدفين". ومع ذلك ، يختلف المنطق في وظيفة واحدة: حتى إذا تمت معالجة VMs الموجودة فيه بواسطة وكلاء مختلفين ، فسيتم إطلاق الوكيل "الهدف" على واحد فقط - على العامل الذي سيبدأ العمل أولاً.
- في حالة سلسلة النسخ الاحتياطي "سلسلة" ، يتم إطلاق عامل "هدف" منفصل لكل VM. وبالتالي ، حتى في نفس المهمة ، يحدث توزيع الحمل.
عند إنشاء نسخ احتياطية اصطناعية ، لا يتم استخدام خوادم الوكيل ، وهنا يتم تحديد الجهاز لبدء تشغيل عامل "الهدف" على النحو التالي: نأخذ خادم تحميل إضافي (خادم تحميل يتم تحميل الملفات عليه ، على سبيل المثال ، أثناء عمليات الاسترداد) مرتبط بالمخزن ، و يبدأ الوكيل. إذا كان خادم التحميل غير متاح لسبب ما ، فمن الممكن التبديل إلى الشمال من النسخ الاحتياطي Veeam. كما تفهم ، لن يكون هناك توزيع تحميل في هذا الإصدار.
لذلك ، أكرر: (
هام! ) لا يوصى لمثل هذه السيناريوهات بإزالة الحد الأقصى لعدد المهام التي تتم معالجتها بالتوازي ، لأنه عند تنفيذ العمليات باستخدام "المواد التركيبية" ، يمكن أن يؤدي هذا إلى زيادة تحميل هائلة من خادم التحميل أو حتى خادم النسخ الاحتياطي Veeam.
ميزات إضافية
مستودع قابل للتحجيم. SOBR عبارة عن مجموعة من المستودعات القياسية (هنا تسمى "الامتدادات"). إذا كنت تستخدم SOBR بالفعل ، فقم بتحديدها في مهمة النسخ الاحتياطي وليس المدى. على المدى ، يمكنك استخدام بعض الإعدادات ، على سبيل المثال ، موازنة التحميل.
جميع المبادئ الأساسية التي تعمل في المستودعات العادية تعمل أيضًا مع SOBR. لتحسين استخدام الموارد ، يمكنك تقديم المشورة لإعداد SOBR مع تخزين "النسخ الاحتياطي" للنسخ الاحتياطية (لكل VM - هذا هو الخيار الافتراضي) ، مع سياسة وضع "الأداء" ("تحسين لأداء أفضل") وتوزيع السلاسل عبر مستودعات-مدى- s.
نقل النسخ الاحتياطية (نسخة احتياطية). هنا ، سيعمل وكلاء "المصدر" على مستودع المصدر. كل شيء مذكور أعلاه ينطبق أيضًا على مستودعات المصدر (باستثناء حقيقة أنه في حالة مهمة نقل مهمة النسخ الاحتياطي ، لا يتم تنفيذ العمليات باستخدام "المواد التركيبية" في مستودع المصدر).
ملاحظة: إذا كان مستودع المصدر هو مشاركة CIFS ، فإن وكيل "المصدر" يبدأ على خادم التحميل المناسب (مع القدرة على التبديل إلى خادم النسخ الاحتياطي Veeam).
الأجهزة مع إلغاء البيانات المضمن. بالنسبة لأنظمة تخزين DataDomain و StoreOnce (وربما لأنظمة أخرى في المستقبل) ، والتي تم تكوين التكامل لها مع Veeam ، تنطبق نفس الاعتبارات كما هو الحال مع مشاركة CIFS. بالنسبة إلى المستودع على StoreOnce مع إلغاء البيانات المكررة على جانب المصدر (وضع
النطاق الترددي المنخفض ) ، يفقد فقط شرط وضع البوابة بالقرب من المستودع قدر الإمكان - يمكن تكوين البوابة على موقع واحد لإرسال البيانات إلى StoreOnce على موقع آخر عبر WAN.
الخادم الوكيل المفضل. ظهرت هذه الميزة ، كما تذكر ، في الإصدار 9.5 ، وهي مسؤولة عن الحفاظ على "قائمة أولويات الوكيل" التي سيلتزم بها البرنامج عند العمل مع مستودع معين.
إذا كان الوكيل من هذه القائمة غير متاح ، فستعمل المهمة مع أي أخرى متاحة. ومع ذلك ، إذا كان هناك وصول إلى الوكيل ، ولكن الخادم الوكيل ليس لديه فتحات مجانية لمعالجة المهمة ، فسيتم تعليق مهمة النسخ الاحتياطي في انتظار تعليقها. لذلك ، تحتاج إلى استخدام هذه الميزة بعناية شديدة (وليس في نمط "التشغيل والنسيان") - كان لدينا مستخدمون قاموا بالتالي "بقطع الاتصال" بمهام النسخ الاحتياطي. يمكنك قراءة المزيد حول الميزة
هنا (باللغة الإنجليزية).
في الختام
لا يهم ما إذا كنت تقوم بتثبيت Veeam Backup & Replication للمرة الأولى أو كنت مستخدمًا لفترة طويلة - أريد أن أصدق أنه في هذه المقالة ستجد معلومات مفيدة لك وبمساعدة مساعدتها على تحسين تشغيل البنية التحتية الاحتياطية أو حتى القضاء على المخاطر المحتملة لفقدان البيانات. إليك بعض الروابط المفيدة: