Translate

<computeroutput># </computeroutput><userinput>mdadm /dev/md1 --remove /dev/sde</userinput>
<computeroutput>mdadm: hot removed /dev/sde from /dev/md1
# </computeroutput><userinput>mdadm --detail /dev/md1</userinput>
<computeroutput>/dev/md1:
[...]
Number Major Minor RaidDevice State
0 8 50 0 active sync /dev/sdd2
2 8 80 1 active sync /dev/sdf</computeroutput>
SourceTranslationState
83
Now let's see what happens when one of the elements of the RAID-1 array fails. <command>mdadm</command>, in particular its <literal>--fail</literal> option, allows simulating such a disk failure:
دعنا نرى ما سيحدث عندما يتعطل أحد عناصر مصفوفة RAID-1. يمكن محاكاة عطب قرص ما باستخدام الخيار <literal dir="ltr">--fail</literal> مع الأمر <command>mdadm</command>:
84
<computeroutput># </computeroutput><userinput>mdadm /dev/md1 --fail /dev/sde</userinput>
<computeroutput>mdadm: set /dev/sde faulty in /dev/md1
# </computeroutput><userinput>mdadm --detail /dev/md1</userinput>
<computeroutput>/dev/md1:
[...]
Update Time : Wed May 6 09:39:39 2015
State : clean, degraded
Active Devices : 1
Working Devices : 1
Failed Devices : 1
Spare Devices : 0

Name : mirwiz:1 (local to host mirwiz)
UUID : 6ec558ca:0c2c04a0:19bca283:95f67464
Events : 19

Number Major Minor RaidDevice State
0 8 50 0 active sync /dev/sdd2
2 0 0 2 removed

1 8 64 - faulty /dev/sde</computeroutput>
<computeroutput># </computeroutput><userinput>mdadm /dev/md1 --fail /dev/sde</userinput>
<computeroutput>mdadm: set /dev/sde faulty in /dev/md1
# </computeroutput><userinput>mdadm --detail /dev/md1</userinput>
<computeroutput>/dev/md1:
[...]
Update Time : Wed May 6 09:39:39 2015
State : clean, degraded
Active Devices : 1
Working Devices : 1
Failed Devices : 1
Spare Devices : 0

Name : mirwiz:1 (local to host mirwiz)
UUID : 6ec558ca:0c2c04a0:19bca283:95f67464
Events : 19

Number Major Minor RaidDevice State
0 8 50 0 active sync /dev/sdd2
2 0 0 2 removed

1 8 64 - faulty /dev/sde</computeroutput>
85
The contents of the volume are still accessible (and, if it is mounted, the applications don't notice a thing), but the data safety isn't assured anymore: should the <filename>sdd</filename> disk fail in turn, the data would be lost. We want to avoid that risk, so we'll replace the failed disk with a new one, <filename>sdf</filename>:
تبقى محتويات المصفوفة متاحة (وإذا كانت مرتبطة بشجرة الملفات، فلن تشعر التطبيقات بشيء)، لكن البيانات لم تعد بأمان: فإذا تعطل القرص <filename>sdd</filename> أيضًا، سوف تضيع البيانات. نحن لا نريد أن نخاطر بذلك، ولهذا سوف نستبدل القرص المعطوب بقرص جديد، <filename>sdf</filename>:
86
<computeroutput># </computeroutput><userinput>mdadm /dev/md1 --add /dev/sdf</userinput>
<computeroutput>mdadm: added /dev/sdf
# </computeroutput><userinput>mdadm --detail /dev/md1</userinput>
<computeroutput>/dev/md1:
[...]
Raid Devices : 2
Total Devices : 3
Persistence : Superblock is persistent

Update Time : Wed May 6 09:48:49 2015
State : clean, degraded, recovering
Active Devices : 1
Working Devices : 2
Failed Devices : 1
Spare Devices : 1

Rebuild Status : 28% complete

Name : mirwiz:1 (local to host mirwiz)
UUID : 6ec558ca:0c2c04a0:19bca283:95f67464
Events : 26

Number Major Minor RaidDevice State
0 8 50 0 active sync /dev/sdd2
2 8 80 1 spare rebuilding /dev/sdf

1 8 64 - faulty /dev/sde
# </computeroutput><userinput>[...]</userinput>
<computeroutput>[...]
# </computeroutput><userinput>mdadm --detail /dev/md1</userinput>
<computeroutput>/dev/md1:
[...]
Update Time : Wed May 6 09:49:08 2015
State : clean
Active Devices : 2
Working Devices : 2
Failed Devices : 1
Spare Devices : 0

Name : mirwiz:1 (local to host mirwiz)
UUID : 6ec558ca:0c2c04a0:19bca283:95f67464
Events : 41

Number Major Minor RaidDevice State
0 8 50 0 active sync /dev/sdd2
2 8 80 1 active sync /dev/sdf

1 8 64 - faulty /dev/sde</computeroutput>
<computeroutput># </computeroutput><userinput>mdadm /dev/md1 --add /dev/sdf</userinput>
<computeroutput>mdadm: added /dev/sdf
# </computeroutput><userinput>mdadm --detail /dev/md1</userinput>
<computeroutput>/dev/md1:
[...]
Raid Devices : 2
Total Devices : 3
Persistence : Superblock is persistent

Update Time : Wed May 6 09:48:49 2015
State : clean, degraded, recovering
Active Devices : 1
Working Devices : 2
Failed Devices : 1
Spare Devices : 1

Rebuild Status : 28% complete

Name : mirwiz:1 (local to host mirwiz)
UUID : 6ec558ca:0c2c04a0:19bca283:95f67464
Events : 26

Number Major Minor RaidDevice State
0 8 50 0 active sync /dev/sdd2
2 8 80 1 spare rebuilding /dev/sdf

1 8 64 - faulty /dev/sde
# </computeroutput><userinput>[...]</userinput>
<computeroutput>[...]
# </computeroutput><userinput>mdadm --detail /dev/md1</userinput>
<computeroutput>/dev/md1:
[...]
Update Time : Wed May 6 09:49:08 2015
State : clean
Active Devices : 2
Working Devices : 2
Failed Devices : 1
Spare Devices : 0

Name : mirwiz:1 (local to host mirwiz)
UUID : 6ec558ca:0c2c04a0:19bca283:95f67464
Events : 41

Number Major Minor RaidDevice State
0 8 50 0 active sync /dev/sdd2
2 8 80 1 active sync /dev/sdf

1 8 64 - faulty /dev/sde</computeroutput>
87
Here again, the kernel automatically triggers a reconstruction phase during which the volume, although still accessible, is in a degraded mode. Once the reconstruction is over, the RAID array is back to a normal state. One can then tell the system that the <filename>sde</filename> disk is about to be removed from the array, so as to end up with a classical RAID mirror on two disks:
هنا أيضاً تبدأ النواة طور إعادة بناء تلقائيًا، وتبقى المصفوفة خلال هذا الطور في الوضع degraded أيضًا لكنها متاحة للوصول. ترجع مصفوفة RAID-1 إلى الحالة الطبيعية فور انتهاء إعادة البناء. يمكن عندها أن نخبر النظام أننا سوف نزيل القرص <filename>sde</filename> من المصفوفة، حتى تبقى كمرآة RAID كلاسيكية بقرصين فقط:
88
<computeroutput># </computeroutput><userinput>mdadm /dev/md1 --remove /dev/sde</userinput>
<computeroutput>mdadm: hot removed /dev/sde from /dev/md1
# </computeroutput><userinput>mdadm --detail /dev/md1</userinput>
<computeroutput>/dev/md1:
[...]
Number Major Minor RaidDevice State
0 8 50 0 active sync /dev/sdd2
2 8 80 1 active sync /dev/sdf</computeroutput>
<computeroutput># </computeroutput><userinput>mdadm /dev/md1 --remove /dev/sde</userinput>
<computeroutput>mdadm: hot removed /dev/sde from /dev/md1
# </computeroutput><userinput>mdadm --detail /dev/md1</userinput>
<computeroutput>/dev/md1:
[...]
Number Major Minor RaidDevice State
0 8 50 0 active sync /dev/sdd2
2 8 80 1 active sync /dev/sdf</computeroutput>
89
From then on, the drive can be physically removed when the server is next switched off, or even hot-removed when the hardware configuration allows hot-swap. Such configurations include some SCSI controllers, most SATA disks, and external drives operating on USB or Firewire.
عند هذه اللحظة يمكن فصل القرص الفيزيائي عند إيقاف تشغيل المخدم، أو يمكن حتى فصلها مباشرة إذا كان العتاد يسمح بالتبديل الساخن hot-swap. تسمح بعض متحكمات SCSI، ومعظم أقراص SATA، والسواقات الخارجية التي تعمل عبر USB أو Firewire بهذا النوع من التبديل.
90
Backing up the Configuration
النسخ الاحتياطي للإعدادات
91
Most of the meta-data concerning RAID volumes are saved directly on the disks that make up these arrays, so that the kernel can detect the arrays and their components and assemble them automatically when the system starts up. However, backing up this configuration is encouraged, because this detection isn't fail-proof, and it is only expected that it will fail precisely in sensitive circumstances. In our example, if the <filename>sde</filename> disk failure had been real (instead of simulated) and the system had been restarted without removing this <filename>sde</filename> disk, this disk could start working again due to having been probed during the reboot. The kernel would then have three physical elements, each claiming to contain half of the same RAID volume. Another source of confusion can come when RAID volumes from two servers are consolidated onto one server only. If these arrays were running normally before the disks were moved, the kernel would be able to detect and reassemble the pairs properly; but if the moved disks had been aggregated into an <filename>md1</filename> on the old server, and the new server already has an <filename>md1</filename>, one of the mirrors would be renamed.
تُحفَظ معظم البيانات الفوقية (meta-data) الخاصة بمصفوفات RAID مباشرة على الأقراص التي تنتمي لهذه المصفوفات، حتى تتعرف النواة على المصفوفات ومكوناتها وتجمعها آليًا عند إقلاع النظام. لكن الأفضل أخذ نسخة احتياطية عن هذه البيانات، لأن عملية التعرف هذه قد تفشل، ومن المتوقع ألا تفشل هذه العملية إلا في الظروف الحساسة. فلو كان عطل القرص <filename>sde</filename> في مثالنا حقيقيًا (وليس ظاهريًا كما فعلنا) ثم أعيد تشغيل النظام دون إزالة هذا القرص <filename>sde</filename>، فقد يعود هذا القرص إلى العمل ثانية نتيجة عملية الاستكشاف أثناء إعادة الإقلاع. سوف تصطدم النواة إذًا بثلاثة أقراص فيزيائية، كلٌّ منها يدعي أنه يحوي نصف الحيز التخزيني المقابل للمصفوفة نفسها. أو يمكن أن يحدث التباس عند دمج مصفوفات RAID من مخدمين إلى مخدم واحد فقط. إذا كانت هذه المصفوفات تعمل بشكل صحيح قبل نقل الأقراص، سوف تتمكن النواة من التعرف على الأزواج وجمعها بشكل صحيح؛ لكن إذا كانت الأقراص على المخدم القديم مجموعة مع بعضها في مصفوفة اسمها <filename>md1</filename>، وكان المخدم الجديد يحوي <filename>md1</filename> أيضًا، فسوف تعاد تسمية إحدى المرآتين.
92
Backing up the configuration is therefore important, if only for reference. The standard way to do it is by editing the <filename>/etc/mdadm/mdadm.conf</filename> file, an example of which is listed here:
إذاً لا بد من أخذ نسخة احتياطية عن الإعدادات، حتى لو كانت للاستئناس فقط. الطريقة المعيارية لعمل هذا هي تحرير الملف <filename dir="ltr">/etc/mdadm/mdadm.conf</filename>، إليك مثالاً عن هذا الملف:
93
<command>mdadm</command> configuration file
ملف إعداد <command>mdadm</command>

Loading…

Loading…

Things to check

Glossary

Source Translation
No related strings found in the glossary.

Source information

Flags
xml-text
Source string age
3 years ago
Translation file
ar-MA/12_advanced-administration.po, string 88
String priority
Medium
Failing checks