سؤال مخاطر LVM ومحاذير


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

ما هي الجوانب السلبية لاستخدام LVM؟


178
2018-06-12 07:34


الأصل


عند قراءة الإجابات على هذا السؤال ، ضع في اعتبارك تاريخ (سنة) تم نشرها. يحدث الكثير في 3 سنوات في هذه الصناعة. - MattBianco
لقد أجريت بعض التحديثات مؤخرًا (أبريل 2015) بعد فحصها لمعرفة ما إذا كان هناك أي شيء قد تغير. نواة 2.6 أصبحت الآن عتيقة ، محركات SSD أكثر شيوعًا ، ولكن بصرف النظر عن بعض إصلاحات LVM الصغيرة ، لم يتغير الكثير. لقد كتبت بعض الأشياء الجديدة على استخدام لقطات خادم VM / cloud بدلاً من لقطات LVM. حالة الكتابة التخزين المؤقت ، تغيير حجم نظام الملفات ولقطات LVM لم تتغير كثيرا بقدر ما أستطيع أن أرى. - RichVel
فيما يتعلق بالتعليق "ضع في اعتبارك التاريخ" - صحيح بما فيه الكفاية ، ولكن أيضًا ضع في اعتبارك أن الكثير من "الشركات" لا تزال تستخدم RHEL 5 و RHEL 6 ، وكلاهما من أحدث التقنيات أو أقدم من التاريخ من الجواب - JDS


الأجوبة:


ملخص

مخاطر استخدام LVM:

  • عرضة لكتابة مشكلات التخزين المؤقت مع برنامج SSD أو VM hypervisor
  • أصعب لاستعادة البيانات بسبب هياكل أكثر تعقيدًا على القرص
  • من الصعب تغيير حجم أنظمة الملفات بشكل صحيح
  • لقطات من الصعب استخدامها ، بطيئة وعربات التي تجرها الدواب
  • يتطلب بعض المهارات لتكوين بشكل صحيح نظرا لهذه القضايا

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

- تحديث سبتمبر 2017: جعل مواد النواة القديمة أقل بروزًا

تخفيف المخاطر

لا يزال بإمكان LVM العمل بشكل جيد إذا كنت:

  • احصل على إعداد كتابة التخزين المؤقت في hypervisor و kernel و SSDs
  • تجنب لقطات LVM
  • استخدم أحدث إصدارات LVM لتغيير حجم أنظمة الملفات
  • لديك نسخ احتياطية جيدة

تفاصيل

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

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

  • اكتب التخزين المؤقت واكتب إعادة الطلب من خلال محرك الأقراص الثابت مهم للأداء الجيد ، ولكن قد يفشل في طرد الكتل إلى القرص بشكل صحيح بسبب Hypervisor VM ، التخزين المؤقت للكتابة على القرص الصلب ، حبات لينكس القديمة ، إلخ.
    • اكتب الحواجز يعني يضمن kernel أنه سيتم إكمال كتابة القرص معينة قبل كتابة القرص "حاجز" ، للتأكد من أن أنظمة الملفات و RAID يمكن استرداد في حالة فقدان الطاقة المفاجئ أو تعطل. هذه الحواجز يمكن أن تستخدم أ عملية FUA (وصول وحدة القوة) للكتابة على الفور كتل معينة إلى القرص ، وهو أكثر كفاءة من تدفق دافق كامل. يمكن الجمع بين الحواجز بكفاءة الكلمات الدلالية/محلي الطابور الأوامر (إصدار طلبات I / O القرص متعددة في وقت واحد) لتمكين القرص الصلب لأداء إعادة كتابة ذكية دون زيادة خطر فقدان البيانات.
  • برنامج Hypervisor VM يمكن أن يكون لديك مشكلات مشابهة: تشغيل LVM في أحد ضيوف Linux على رأس برنامج VM hypervisor مثل VMware ، كسينيمكن إنشاء KVM أو Hyper-V أو VirtualBox مشاكل مماثلةإلى نواة بدون حواجز الكتابة ، بسبب كتابة التخزين المؤقت وكتابة إعادة الطلب. قم بفحص وثائق برنامج Hypervisor بعناية للحصول على خيار ذاكرة التخزين المؤقت "flush to disk" أو "write-to-through" (موجود في KVM، في إم وير، كسين، فيرتثلبوإكس وغيرها) - واختبارها مع الإعداد الخاص بك. بعض hypervisors مثل فيرتثلبوإكس لها الإعداد الافتراضي يتجاهل أي قرص القرص من الضيف.
  • يجب دائمًا استخدام خوادم المؤسسة ذات LVM بطارية بدعم RAID تحكم وتعطيل التخزين المؤقت للكتابة على القرص الثابت (وحدة تحكم لديه ذاكرة التخزين المؤقت للكتابة مدعومة من البطارية وهي سريعة وآمنة) - راجع هذا التعليق من قبل المؤلف من هذا الدخول إلى الأسئلة الشائعة عن XFS. قد يكون أيضا آمنا ل إيقاف حواجز الكتابة في النواة ، لكن الاختبار موصى به.
  • إذا لم يكن لديك وحدة تحكم RAID مدعومة بالبطارية ، فإن تعطيل التخزين المؤقت للكتابة على القرص الصلب سيؤدي إلى بطء عملية الكتابة بشكل ملحوظ ، ولكن جعل LVM آمنًا. يجب عليك أيضا استخدام ما يعادل ext3 data=ordered الخيار (أو data=journal لمزيد من السلامة) ، زائد barrier=1 لضمان أن التخزين المؤقت للنواة لا يؤثر على النزاهة. (أو استخدام ext4 التي تمكن الحواجز بشكل افتراضي.) هذا هو أبسط خيار ويوفر سلامة البيانات بشكل جيد بتكلفة الأداء. (لينكس تغيير الخيار ext3 الافتراضي لأكثر خطورة data=writeback لفترة من الوقت ، لذلك لا تعتمد على الإعدادات الافتراضية للخدمة الثابتة.)
  • لتعطيل التخزين المؤقت للكتابة على القرص الصلب: إضافة hdparm -q -W0 /dev/sdX لجميع محركات الأقراص في /etc/rc.local (لـ SATA) أو استخدم sdparm لـ SCSI / SAS. ومع ذلك ، وفقا ل هذا الدخول في الأسئلة الشائعة عن XFS (التي تعتبر جيدة جدًا في هذا الموضوع) ، قد ينسى محرك SATA هذا الإعداد بعد استرداد خطأ في محرك الأقراص - لذا يجب استخدام SCSI / SAS ، أو إذا كان يجب عليك استخدام SATA ، فضع أمر hdparm في مهمة cron تعمل كل دقيقة أو نحو ذلك.
  • للحفاظ على تمكين التخزين المؤقت للكتابة على محركات الأقراص SSD / الأقراص الصلبة للحصول على أداء أفضل: هذه منطقة معقدة - انظر القسم أدناه.
  • إذا كنت تستخدم محركات الشكل المتقدم بمعنى: 4 كيلوبايت قطاعات فعلية ، انظر أدناه - قد يؤدي تعطيل التخزين المؤقت للكتابة إلى مشكلات أخرى.
  • يو بي إس يعتبر أمرًا بالغ الأهمية بالنسبة إلى كل من المؤسسة و SOHO ولكن ليس كافيًا لجعل خزينة LVM آمنة: أي شيء يتسبب في حدوث عطل هائل أو فقد الطاقة (على سبيل المثال فشل UPS أو فشل PSU أو استنفاد بطارية الكمبيوتر المحمول) قد يفقد البيانات في ذاكرة التخزين المؤقت لمحرك الأقراص الثابتة.
  • حيل لينكس قديمة جدًا (2.6.x من عام 2009): هناك دعم غير مكتمل لحاجز الكتابة في إصدارات kernel القديمة جدًا ، 2.6.32 والإصدارات الأقدم (2.6.31 لديه بعض الدعم، في حين 2.6.33 يعمل لجميع أنواع الأجهزة المستهدفة) - يستخدم RHEL 6 2.6.32 مع العديد من البقع. إذا كانت هذه الحبيبات 2.6 غير مزوَّدة لهذه المشكلات ، فستفقد كمية كبيرة من البيانات الوصفية للخدمة الثابتة (بما في ذلك المجلات) من خلال تعطل ثابت يترك البيانات في المخازن المؤقتة للكتابة على محركات الأقراص الثابتة (لنقل 32 ميغابايت لكل محرك أقراص لمحركات SATA الشائعة). إن فقدان 32 ميغا بايت من أحدث البيانات الوصفية وبيانات المجلات الصادرة عن FS ، والتي يعتقد النواة أنها موجودة بالفعل على القرص ، عادة ما يعني الكثير من فساد الخدمة الثابتة ومن ثم فقدان البيانات.
  • ملخص: يجب أن تأخذ الرعاية في نظام الملفات ، RAID ، VM hypervisor ، وإعداد محرك القرص الصلب / SSD المستخدم مع LVM. يجب أن يكون لديك نسخ احتياطية جيدة جدًا إذا كنت تستخدم LVM ، وتأكد من إجراء نسخ احتياطي للبيانات الوصفية LVM وإعدادات التقسيم الفعلي و MBR وحجم وحدات التخزين. من المستحسن أيضًا استخدام محركات أقراص SCSI / SAS حيث أن هذه الملفات أقل احتمالاً للكذب حول كيفية قيامهم بكتابة التخزين المؤقت - حيث يلزم المزيد من العناية لاستخدام محركات أقراص SATA.

الحفاظ على تمكين التخزين المؤقت للكتابة للأداء (والتعامل مع محركات الكذب)

خيار أكثر تعقيدًا لكن أداءًا هو الحفاظ على تمكين التخزين المؤقت لمحركات الأقراص الثابتة / SSD والاعتماد على حواجز الكتابة في kernel التي تعمل مع LVM على kernel 2.6.33+ (تحقق مرة أخرى من خلال البحث عن رسائل "حاجز" في السجلات).

يجب عليك أيضًا التأكد من إعداد RAID وإعداد برنامج Hyper VM ونظام الملفات يستخدم حواجز الكتابة (أي يتطلب محرك الأقراص لمسح الكتابة المعلقة قبل وبعد كتابة بيانات واصفات المفاتيح الأساسية). يستخدم XFS العوائق بشكل افتراضي ، ولكن لا يعمل ext3، لذلك مع ext3 يجب عليك استخدام barrier=1 في الخيارات جبل ، وما زالت تستخدم data=ordered أو data=journal على النحو الوارد أعلاه.

  • لسوء الحظ ، بعض محركات الأقراص الصلبة ومحركات أقراص الحالة الصلبة كذب حول ما إذا كانوا قد مسح حقا مخبأهم إلى القرص (وخاصة محركات الأقراص القديمة ، ولكن بما في ذلك بعض محركات أقراص SATA و بعض الشركات SSDs) - مزيد من التفاصيل هنا. هناك ملخص كبير من مطور XFS.
  • هناك أداة اختبار بسيطة لمحركات الكذب (بيرل النصي) ، أو انظر هذه الخلفية مع أداة أخرى اختبار للكتابة إعادة ترتيب نتيجة ذاكرة التخزين المؤقت لمحرك الأقراص. غطت هذه الإجابة اختبار مماثل من محركات الأقراص SATA التي كشفت مشكلة حاجز الكتابة في برنامج RAID - تمارس هذه الاختبارات بالفعل حزمة التخزين بالكامل.
  • أحدث محركات أقراص SATA الداعمة القيادة في الطابور الأصلي (NCQ) قد يكون أقل عرضة للكذب - أو ربما تؤدي أداءً جيدًا بدون تخزين مؤقت للكتابة بسبب NCQ ، ولا تستطيع محركات الأقراص القليلة جدًا تعطيل التخزين المؤقت للكتابة.
  • محركات الأقراص SCSI / SAS بشكل عام موافق لأنها لا تحتاج التخزين المؤقت للكتابة أداء جيد (خلال SCSI معلم القيادة في قائمة الانتظار، على غرار NCA SATA).
  • إذا كانت محركات الأقراص الثابتة أو محركات أقراص الحالة الثابتة تكذب حول مسح ذاكرة التخزين المؤقت الخاصة بهم إلى القرص ، فلا يمكنك الاعتماد على حواجز الكتابة ويجب عليك تعطيل التخزين المؤقت للكتابة. هذه مشكلة لجميع أنظمة الملفات ، قواعد البيانات ، مديري وحدات التخزين ، و برنامج RAIDوليس مجرد LVM.

سواقات إشكالية لأن استخدام ذاكرة التخزين المؤقت للكتابة أمر بالغ الأهمية لمدى عمر SSD. من الأفضل استخدام SSD يحتوي على supercapacitor (لتمكين مسح ذاكرة التخزين المؤقت على فشل الطاقة ، وبالتالي تمكين ذاكرة التخزين المؤقت للكتابة للكتابة وليس الكتابة).

تنسيق متقدم إعداد محرك الأقراص - كتابة التخزين المؤقت ، والمحاذاة ، RAID ، GPT

  • مع الأحدث محركات الشكل المتقدم التي تستخدم 4 قطاعات فيزيائية ، قد يكون من المهم الحفاظ على تمكين التخزين المؤقت للكتابة ، نظرًا لأن معظم محركات الأقراص هذه تحاكي حاليًا القطاعات المنطقية 512 بايت ("مضاهاة 512") ، والبعض حتى يدعي أن يكون القطاعات المادية 512 بايت بينما يستخدم حقا 4 KiB.
  • قد يتسبب إيقاف تشغيل ذاكرة التخزين المؤقت للكتابة الخاصة بمحرك "محرك الأقراص المتقدم" في إحداث تأثير كبير جدًا في الأداء إذا كان التطبيق / kernel يقوم بالكتابة 512 بايت ، حيث تعتمد محركات الأقراص هذه على ذاكرة التخزين المؤقت لتجميع 8 × 512 بايت قبل إجراء عملية واحدة اكتب. يوصى بإجراء اختبار لتأكيد أي تأثير في حالة تعطيل ذاكرة التخزين المؤقت.
  • محاذاة LVs على حدود 4 KiB مهمًا للأداء ولكن يجب أن يحدث تلقائيًا طالما أن الأقسام الأساسية للمعالجات الفيديوية تتم محاذاتها ، لأن LVM Physical Extents (PEs) هي 4 ميجابايت بشكل افتراضي. يجب اعتبار RAID هنا - هذا صفحة إعداد RAID للبرنامج و LVM يقترح وضع superblock RAID في نهاية المجلد و (إذا لزم الأمر) باستخدام خيار على pvcreate لمحاذاة الكهروضوئية. هذا الموضوع قائمة البريد الإلكتروني LVM يشير إلى العمل المنجز في الحلب خلال عام 2011 وقضية الكتابة الجزئية للكتابة عند مزج الأقراص مع 512 بايت و 4 قطاعات كى بى في LV مفرد.
  • تقسيم GPT باستخدام التنسيق المتقدم يحتاج إلى رعاية ، وخاصة بالنسبة للأقراص التمهيد + الجذر ، لضمان بدء أول قسم LVM (PV) على حدود 4 KiB.

أصعب لاستعادة البيانات بسبب هياكل أكثر تعقيدًا على القرص:

  • أي استرداد لبيانات LVM المطلوبة بعد تعطل القرص الصلب أو فقدان الطاقة (بسبب التخزين المؤقت غير الصحيح للكتابة) هو عملية يدوية في أفضل الأحوال ، لأنه لا توجد أدوات مناسبة على ما يبدو. LVM جيد في النسخ الاحتياطي للبيانات الوصفية الخاصة به تحت /etc/lvmوالتي يمكن أن تساعد في استعادة البنية الأساسية للـ LVs و VGs و PVs ، ولكنها لن تساعد في البيانات الوصفية المفقودة لنظام الملفات.
  • ومن ثم فإن الاستعادة الكاملة من النسخ الاحتياطي من المرجح أن تكون مطلوبة. يتضمن هذا وقتًا أطول بكثير من fsck المستند إلى دفتر اليومية السريع عند عدم استخدام LVM ، وستفقد البيانات المكتوبة منذ آخر عملية نسخ احتياطي.
  • TestDisk، ext3grep، ext3undel و أدوات أخرى  يمكن استرداد الأقسام والملفات من أقراص غير LVM ولكنها لا تدعم استرداد بيانات LVM مباشرةً. يمكن أن يكتشف TestDisk أن القسم الفيزيائي المفقود يحتوي على LVM PV ، لكن لا توجد أي من هذه الأدوات يفهم وحدات التخزين المنطقية LVM. نحت الملف أدوات مثل من PhotoRec والعديد من الآخرين سيعملون مع تجاوز نظام الملفات لإعادة تجميع الملفات من كتل البيانات ، لكن هذا هو نهج أخير المستوى ، ومستوى منخفض للبيانات القيمة ، ويعمل بشكل أقل جودة مع الملفات المجزأة.
  • يمكن الاسترداد اليدوي LVM في بعض الحالات ، ولكنه معقد ويستغرق وقتًا طويلاً - راجع هذا المثال و هذه، هذهو هذه لكيفية الاسترداد.

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

  • تحديث: إصدارات أحدث من lvextend دعم -r (--resizefs) الخيار - إذا كان ذلك متاحًا ، فهذه طريقة أكثر أمانًا وأسرع لتغيير حجم LV ونظام الملفات ، خاصةً إذا كنت تقلص الخدمة الثابتة ، ويمكنك غالبًا تخطي هذا القسم.
  • لا تأخذ معظم أدلة تغيير حجم الخدمة الثابتة المستندة إلى LVM في الحسبان حقيقة أن الخدمة الثابتة يجب أن تكون أصغر إلى حد ما من حجم الجهد المنخفض: شرح مفصل هنا. عند تقليص نظام الملفات ، ستحتاج إلى تحديد الحجم الجديد لأداة تغيير FS ، على سبيل المثال ، resize2fs ل ext3 ، وإلى lvextend أو lvreduce. وبدون عناية كبيرة ، قد تكون الأحجام مختلفة قليلاً بسبب الاختلاف بين 1 جيجابايت (10 ^ 9) و 1 بنك الخليج الدولي (2 ^ 30) ، أو الطريقة التي تستخدم فيها الأدوات المختلفة أحجامًا مستديرة لأعلى أو لأسفل.
  • إذا لم تقم بإجراء الحسابات بشكل صحيح تمامًا (أو استخدم بعض الخطوات الإضافية التي تتجاوز الخطوات الأكثر وضوحًا) ، فقد ينتهي بك الأمر إلى FS التي تكون كبيرة جدًا بالنسبة للجهد المنخفض. سيبدو كل شيء على ما يرام لأشهر أو سنوات ، إلى أن تملأ الخدمة بالكامل ، وعند هذه النقطة ستحصل على فساد خطير - وما لم تكن على دراية بهذه القضية يصعب عليك معرفة السبب ، كما قد يكون لديك أيضًا أخطاء حقيقية في القرص هذا سحابة الوضع. (من المحتمل أن هذه المشكلة تؤثر فقط على تقليل حجم أنظمة الملفات - ولكن من الواضح أن تغيير حجم أنظمة الملفات في أي اتجاه يزيد من خطر فقدان البيانات ، ربما بسبب خطأ المستخدم.)
  • يبدو أن حجم LV يجب أن يكون أكبر من حجم FS بمقدار 2 x الحجم الفعلي LVM (PE) - ولكن تحقق من الارتباط أعلاه للحصول على التفاصيل لأن مصدر ذلك غير موثوق. غالبًا ما يُسمح بـ 8 ميغابايت ، ولكن قد يكون من الأفضل السماح بالمزيد ، على سبيل المثال ، 100 ميغابايت أو 1 GiB ، فقط لتكون آمنة. للتحقق من حجم PE وحجم منطقي لديك + FS ، باستخدام 4 KiB = 4096 بايت:

    يظهر حجم PE في KiB:
    vgdisplay --units k myVGname | grep "PE Size"

    حجم جميع LVs:
    lvs --units 4096b

    حجم (ext3) FS ، يفترض 4 KiB FS blockize:
    tune2fs -l /dev/myVGname/myLVname | grep 'Block count'

  • على النقيض من ذلك ، فإن الإعداد غير LVM يجعل تغيير حجم FS موثوقًا به وسهل التشغيل من GParted وتغيير حجم وحدات الخدمة الثابتة المطلوبة ، ثم ستفعل كل شيء من أجلك. على الخوادم ، يمكنك استخدامها parted من القشرة.

    • من الأفضل في كثير من الأحيان استخدام Gparted Live CD أو مفترق السحر، لأن هذه الأخيرة لها Gparted & kernel حديثة وخالية من الأخطاء أكثر من نسخة توزيعة - لقد خسرت مرة واحدة FS كامل بسبب توزيعة Gparted لم يتم تحديث الأقسام بشكل صحيح في نواة التشغيل. إذا كنت تستخدم Gparted في التوزيعة ، فتأكد من إعادة التشغيل مباشرة بعد تغيير الأقسام بحيث تكون رؤية kernel صحيحة.

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

يمكن أن تكون اللقطات بطيئة جدًا أيضًا (بمعنى 3 إلى 6 مرات أبطأ من عدم وجود LVM لها هذه الاختبارات MySQL) - نرى هذه الإجابة تغطي مختلف المشاكل لقطة. البطء هو جزئيا تتطلب اللقطات العديد من عمليات الكتابة المتزامنة.

تحتوي اللقطات على بعض الأخطاء المهمة ، على سبيل المثال ، في بعض الحالات يمكنهم جعل الحذاء بطيئا جدا، أو تسبب في فشل الحذاء تماما (لأن النواة يمكن أن تنقطع  في انتظار الجذر FS عندما تكون لقطة LVM [ثابتة في دبيان initramfs-tools التحديث ، مارس 2015]).

  • أحد المقاييس هو أن هناك العديد من الأخطاء في دبيان المطابقة "lvm snapshot 2015"، وبعضهم خطيرة للغاية - ولكن ، على ما يبدو العديد من البق الشرط الشرط على ما يبدو تم إصلاحها. يبدو LVM بدون اللقطات بشكل عام مصححًا بشكل جيد ، ربما لأنه لا يتم استخدام اللقطات بقدر ما يتم استخدام الميزات الأساسية.

بدائل لقطة - أنظمة الملفات و Hypervisors VM

لقطات VM / cloud:

  • إذا كنت تستخدم برنامج Hypervisor VM أو موفر سحابة IaaS ، فعادةً ما تكون اللقطات (مثل VMware و VirtualBox أو Amazon EBS's EBS) بديلاً أفضل بكثير عن اللقطات LVM. يمكنك بسهولة أخذ لقطة لأغراض النسخ الاحتياطي (لكن ضع في اعتبارك تجميد FS قبل القيام).

لقطات نظام الملفات:

  • من السهل استخدام لقطات نظام الملفات مع ZFS أو btrfs وهي أفضل عمومًا من LVM ، وبالرغم من أن أيا من نظامي الملفات لا ينضج على Linux ، إلا أنه قد يكون خيارًا أفضل للأشخاص الذين يحتاجون إلى لقطات دون الحاجة إلى مسار VM / cloud:

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

لقطات للنسخ الاحتياطي عبر الإنترنت و fsck

يمكن استخدام لقطات لتوفير متسقة مصدر للنسخ الاحتياطية ، طالما كنت حريصًا على المساحة المخصصة (من الناحية المثالية تكون اللقطة هي نفس الحجم الذي يتم فيه إجراء LV احتياطيًا). ممتاز rsnapshot (منذ 1.3.1) حتى إدارة إنشاء / حذف لقطة LVM لك - انظر هذا HOWTO على rsnapshot باستخدام LVM. ومع ذلك ، لاحظ المشاكل العامة مع اللقطات وأن لقطة يجب أن لا تعتبر نسخة احتياطية في حد ذاتها.

يمكنك أيضًا استخدام لقطات LVM لإجراء fsck عبر الإنترنت: لقطة LV و fsck اللقطة ، مع الاستمرار في استخدام FS FS-snap الرئيسي - هو موضح هنا - ومع ذلك ، ليس واضحًا تمامًا لذلك من الأفضل أن تستخدم e2croncheck مثل وصفه تيد تسو، صامد ext3.

يجب "تجميد" نظام الملفات مؤقتا أثناء التقاط اللقطة - بعض أنظمة الملفات مثل ext3 و XFS سوف القيام بذلك تلقائيا عندما يقوم LVM بإنشاء اللقطة.

الاستنتاجات

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

يتطلب LVM عناية كبيرة على إعداد التخزين المؤقت للكتابة بسبب Hypervisor VM ، التخزين المؤقت للكتابة على القرص الصلب / SSD ، وهكذا - ولكن الشيء نفسه ينطبق على استخدام لينكس كخادم DB. نقص الدعم من معظم الأدوات (gparted بما في ذلك حسابات الحجم الحرجة ، و testdisk الخ) يجعل الأمر أكثر صعوبة للاستخدام مما ينبغي.

إذا كنت تستخدم LVM ، فخذ عناية فائقة باستخدام اللقطات: استخدم لقطات VM / cloud إن أمكن ، أو ابحث عن ZFS / btrfs لتجنب LVM تمامًا - قد تجد ZFS أو btrs ناضجة بما فيه الكفاية مقارنة بـ LVM مع اللقطات.

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


239
2018-06-12 08:19



يعمل تغيير حجم الإنترنت مع xfs بشكل مثالي ، حتى لا تضطر إلى تحديد الحجم. سوف ينمو إلى حجم LV اقرأ المزيد في xfs_grow (5). ضرب OTOH 1+ للموجز على حواجز الكتابة. - cstamas
يا صديق! اين كنت طوال حياتي!؟ - songei2f
TREE: الفكرة مع وحدة تحكم RAID مدعومة بالبطارية هي أن ذاكرة التخزين المؤقت الخاصة بها مستمرة عبر انقطاع التيار الكهربائي ويمكن بصفة عامة الوثوق بها للعمل كموثقة ، في حين أن بعض مخابئ القرص الثابت تكذب حول ما إذا كانت قد كتبت بالفعل كتلة إلى القرص ، و بالطبع هذه المخابئ ليست ثابتة. إذا تركت ذاكرة التخزين المؤقت في القرص الصلب ، فستكون عرضة لفشل طاقة مفاجئ (على سبيل المثال فشل PSU أو UPS) ، وهو محمي ضد النسخ الاحتياطي لبطارية وحدة التحكم RAID. - RichVel
واحدة من أفضل الإجابات التي رأيتها على الإطلاق ، أي موضوع. التغيير الوحيد الذي يمكنني القيام به ، نقل ملخص إلى TOP للسؤال لأولئك الذين يعانون من اضطراب نقص الانتباه أو ليس الكثير من الوقت. :-) - Prof. Falken
رؤية جميع التعليقات وآخر تحديث للإجابة كان قبل عام ، كنت أتساءل إذا كان بالإمكان تحديث الإجابة لتعكس أي تغييرات جديدة في الموثوقية والأداء وسهولة الاستخدام. - Luis Alvarado


أنا [+1] هذا المنصب ، وعلى الأقل بالنسبة لي أعتقد أن معظم المشاكل موجودة. رأيت لهم أثناء تشغيل بعض خوادم 100 وبضع 100 تيرابايت من البيانات. بالنسبة لي ، يبدو LVM2 في لينكس وكأنه "فكرة ذكية". مثل بعض هذه ، فإنها تبين أن "ليست ذكية" في بعض الأحيان. أي. قد لا يشعر المرء بالذكاء في التخلص من حالات النواة والمستخدمين (lvmtab) بشكل صارم ، لأنه قد تكون هناك قضايا فساد (إذا لم تحصل على الرمز الصحيح)

حسنا ، فقط أن هذا الفصل كان هناك لسبب ما - تظهر الاختلافات مع معالجة فقدان PV ، وإعادة تنشيط VG عبر الإنترنت على سبيل المثال ، المفقودات الكهروضوئية لإعادة تشغيلها - ما هو النسيم على "LVMs الأصلي" (AIX ، HP-UX) يتحول إلى حماقة على LVM2 منذ معالجة الدولة ليست جيدة بما فيه الكفاية. ولا تدعوني أتحدث عن اكتشاف فقدان الحساب (haha) أو التعامل مع الحالة (إذا قمت بإزالة قرص ، فلن يتم الإبلاغ عنه على أنه غير متوفر. يملك عمود الحالة اللعين)

رد: الاستقرار pvmove... لماذا

فقدان البيانات pvmove

مثل هذه المقالة أعلى مرتبة على مدونتي ، هممم؟ الآن فقط أنظر إلى القرص حيث لا تزال معلقة البيانات LVM phyiscal على الدولة من منتصف pvmove. كان هناك بعض memleaks على ما أعتقد ، والفكرة العامة أنه أمر جيد لنسخ حول كتلة البيانات الحية من userspace هو مجرد حزين. اقتباس لطيفة من قائمة LVM "يبدو مثل vgreduce --missing لا يعالج pvmove" يعني في الواقع إذا انفصل قرص أثناء pvmove ثم تتغير أداة إدارة lvm من lvm إلى vi. لقد كان هناك أيضا علة حيث يستمر pvmove بعد خطأ في قراءة / كتابة كتلة ويفعل في الواقع لم يعد يكتب البيانات إلى الجهاز المستهدف. WTF؟

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

الميزة في الأداء ، القيام 1 يكتب بدلاً من 3. انتقاء خوارزمية سريعة ولكن لا يمكن إيجازها هو شيء يتوقعه المرء بوضوح من أشخاص مثل VMware و MS ، على "Unix" أفضل أن أحزر الأشياء "تمت بشكل صحيح". لم أكن أرى الكثير من مشاكل الأداء طالما لدي مخزن دعم لقطة على مختلف محرك الأقراص من البيانات الأولية (والنسخ الاحتياطي لواحد آخر بالطبع)

إعادة: الحواجز لست متأكدا ما إذا كان يمكن لأحد أن يلوم ذلك على LVM. كانت قضية devmapper ، بقدر ما أعرف. ولكن يمكن أن يكون هناك بعض اللوم لعدم الاهتمام حقا بهذه المسألة من على الأقل kernel 2.6 حتى 2.6.33 AFAIK Xen هو برنامج Hypervisor الوحيد الذي يستخدم O_DIRECT للأجهزة الظاهرية ، كانت المشكلة تستخدم عندما يكون "loop" مستخدمًا لأن kernel سيظل يستخدم ذلك. Virtualbox على الأقل لديه بعض الإعداد لتعطيل أشياء مثل هذا ويبدو أن Qemu / KVM يسمح بالتخزين المؤقت. جميع FUSE FS تواجه أيضًا مشاكل هناك (لا O_DIRECT)

إعادة: الأحجام أعتقد أن LVM يقوم "بتقريب" الحجم المعروض. أو أنها تستخدم GiB. على أي حال ، تحتاج إلى استخدام حجم VG Pe وضربه من خلال عدد LE من LV. يجب أن يعطي هذا الحجم الصافي الصحيح ، وهذه المشكلة دائمًا مشكلة استخدام. يزداد الأمر سوءًا من خلال أنظمة الملفات التي لا تلاحظ شيئًا من هذا القبيل أثناء fsck / mount (hello أو ext3) أو لا تعمل عبر الإنترنت "fsck -n" (hello، ext3)

بالطبع ، لا يمكنك العثور على مصادر جيدة لمثل هذه المعلومات. "كم جنيه لو VRA؟" "ما هو التعويض الفيزياري لـ PVRA ، VGDA ، ... الخ"

بالمقارنة مع LVM2 الأصلي هو المثال الرئيسي "أولئك الذين لا يفهمون UNIX يتم إدارتهم لإعادة اختراعه ، بشكل سيئ".

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

ما لم أتمكن من حله هو كيفية تحديد عمر لقطة. بالنسبة لأدائهم ، هناك ملاحظة على صفحة مشروع fedora "thinp" والتي تقول أن تقنية اللقطة يتم مراجعتها بحيث لا تصبح أبطأ مع كل لقطة. لا أعرف كيف ينفذونها.


15
2017-12-11 14:03



النقاط الجيدة ، ولا سيما على فقدان البيانات pvmove (لم يدرك هذا يمكن أن تتعطل تحت انخفاض الذاكرة) وتصميم لقطة. على حواجز الكتابة / التخزين المؤقت: كنت أخلط LVM وعارض جهاز kernel من وجهة نظر المستخدم التي تعمل معًا لتقديم ما يوفره LVM. Upvoted. أعجبني أيضًا نشر مدونتك على فقدان بيانات pvmove: deranfangvomende.wordpress.com/2009/12/28/... - RichVel
على اللقطات: هم معروفون بشكل بطيء في LVM ، لذا من الواضح أنه لم يكن قرار تصميم جيد للذهاب للأداء على الموثوقية. عن طريق "ضرب الجدار" ، هل تعني أن اللقطة ممتلئة ، وهل يمكن أن يسبب ذلك بالفعل فساد بيانات LV الأصلية؟ يقول LVM HOWTO أن اللقطة تم إسقاطها في هذه الحالة: tldp.org/HOWTO/LVM-HOWTO/snapshots_backup.html - RichVel
"يتم تنفيذ CoW بشكل غير آمن ، من خلال تحديث البيانات الجديدة في منطقة اللقطة اللمسية ومن ثم دمج مرة أخرى عند حذف الخاطف." هذا غير صحيح عند كتابة بيانات جديدة على الجهاز الأصلي ، فإن قديم يتم كتابة نسخة في لقطات بقرة المجال. يتم دمج أي بيانات من أي وقت مضى (باستثناء ما إذا كنت تريد). نرى kernel.org/doc/Documentation/device-mapper/snapshot.txt لجميع التفاصيل الفنية غوري. - Damien Tournoud
مرحبا داميان ، في المرة القادمة فقط قرأت على النقطة حيث قمت بتصحيح منصبي؟ - Florian Heigl


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

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


12
2018-06-12 09:44



إجراء 1+ لتحذير الأداء من اللقطات المفتوحة. - Prof. Falken
تجربتي هي أن محركات الأقراص 1 تيرابايت تستخدم عادة 512 بايت ، ولكن معظم محركات الأقراص 2 تيرابايت تستخدم 4 كيلوبايت. - Dan Pritts
DanPritts ليس هناك ضرر في افتراض أن حجم القطاع هو 4kB أو حتى 128kB - فقط في حالة وجود غارة بينهما. خسرت القليل جدا - ربما أن 128kB ويمكنك كسب الكثير. أيضا عند التصوير من القرص القديم إلى واحد جديد. - pQd
هناك بعض الضرر الطفيف لجعل حجم كتلة نظام الملفات "كبير جدًا" ؛ كل ملف موجود في ما لا يقل عن كتلة واحدة. إذا كان لديك الكثير من الملفات الصغيرة ومقاطع 128 كيلوبايت ، فسوف يتم إضافتها. أوافق على الرغم من أن 4K معقول جدا ، وإذا قمت بنقل نظام ملفات إلى أجهزة جديدة ، فسوف ينتهي الأمر بقطاعات 4K في نهاية المطاف. - Dan Pritts
(لن تسمح لي بتحرير تعليقي السابق) ... قد لا تضيع مضيعة للمساحة ، ولكنها ستؤدي في نهاية المطاف إلى زيادة متوسط ​​وقت البحث الخاص بك على الأقراص الدوارة. قد يتحول إلى تضخيم الكتابة (ملء القطاع بالقيم الخالية) على محركات أقراص الحالة الصلبة. - Dan Pritts


آدم،

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

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

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

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

وعموما ، أنا من محبي LVM2.


5
2018-06-22 21:03



حفظ /boot منفصلة هي دائما فكرة جيدة - Hubert Kario
يدعم GRUB2 التمهيد من وحدة التخزين المنطقية LVM (راجع wiki.archlinux.org/index.php/GRUB2#LVM) ولكن GRUB1 لا. أنا دائما استخدام منفصلة غير LVM / التمهيد فقط لضمان سهولة الاسترداد. معظم أقراص الإنقاذ هذه الأيام تدعم LVM - بعضها يتطلب دليلًا vgchange -ayللعثور على وحدات تخزين LVM. - RichVel
على pvmove: راجع النقطة حول فقدان البيانات pvmove المحرز في الإجابة فلوريان هيغل. - RichVel