Thanks you Matthew :) your emails is life saving.<div><br></div><div>Thanks again,</div><div><br></div><div>MYK <br><div><br><br><div class="gmail_quote">On Tue, May 24, 2011 at 6:47 PM, Matthew Caron <span dir="ltr"><<a href="mailto:Matt.Caron@sixnet.com" target="_blank">Matt.Caron@sixnet.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>On 05/24/2011 09:10 AM, Muhammad Yousuf Khan wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
tell any one :P . have u tested mdam fail over<br>
</blockquote>
<br></div>
Yes - it works the same as it does in all the other boxes. If I yank out a drive, it just keeps running.<br>
<br>
All that said, I *don't* recommend doing software RAID for anything other than RAID1. In this respect, I agree with them.<br>
<br>
The argument basically boils down like this (and I am paraphrasing from forum conversations):<br>
<br>
Q: Do you support software RAID?<br>
A: No. Software RAID is bad because if you lose power it can corrupt your disks. Get a battery backed hardware RAID controller.<br>
Q: But if you are just doing a RAID1? mirror and lose power, it's the same as if you're using a single disk.<br>
A: But if you are doing software RAID5?, it's worse.<br>
Q: I'm not talking RAID5?, I'm talking RAID1?.<br>
A: But if we put in support for RAID1?, we'd want to support all software RAID levels, otherwise it's a halfway job. So, we're not going to support any software RAID.<br>
<br>
However, it's still Linux, and it's still Debian, and it's still based off the same tools we're used to using, so we can do what we want.<br>
<br>
There is even a mostly correct post here:<br>
<br>
<a href="http://forum.proxmox.com/threads/838-Install-on-Soft-Raid?p=4760#post4760" target="_blank">http://forum.proxmox.com/threads/838-Install-on-Soft-Raid?p=4760#post4760</a><br>
<br>
Here is my (somewhat revised) procedure pulled from my system setup notes:<br>
<br>
1. Log in as root (ssh or console, doesn't matter. ssh is likely easier). Note that at this point there is only the root account. Password is what you set up in the install.<br>
<br>
2. Get the tools you need:<br>
<br>
apt-get install mdadm initramfs-tools<br>
<br>
3. In the mdadm config screen, choose "all" (the default)<br>
<br>
4. Edit the initramfs module list in /etc/initramfs-tools/modules and add raid1 at the bottom<br>
<br>
5. sfdisk the drives. Note that these drives have a funky layout, hence the --force parameter<br>
<br>
sfdisk -d /dev/sda | sfdisk --force /dev/sdb<br>
<br>
6. Create the two metadisks, level 1 (mirrored), 2 devices, first one missing. Also bootstraps config.<br>
<br>
mdadm --create /dev/md0 --level=1 --raid-devices=2 missing /dev/sdb1<br>
mdadm --create /dev/md1 --level=1 --raid-devices=2 missing /dev/sdb2<br>
mdadm --detail scan >> /etc/mdadm/mdadm.conf<br>
<br>
7. Create a new physical lvm volume, extend the existing logical volume into it, move the data over, then reduce the existing volume out of the array. (Note that the move takes a while.)<br>
<br>
pvcreate /dev/md1<br>
vgextend pve /dev/md1<br>
pvmove /dev/sda2 /dev/md1<br>
vgreduce pve /dev/sda2<br>
<br>
8. Add the drive you just reduced out of the array to the metadisk as the missing component and then watch the rebuild until it completes<br>
<br>
mdadm --add /dev/md1 /dev/sda2<br>
watch -n1 "cat /proc/mdstat"<br>
<br>
9. Make a filesystem on the smaller metadisk and copy /boot to it<br>
<br>
mkfs.ext3 /dev/md0<br>
mkdir /mnt/md0<br>
mount /dev/md0 /mnt/md0<br>
cp -a /boot/* /mnt/md0/.<br>
umount /mnt/md0<br>
rmdir /mnt/md0<br>
umount /boot<br>
<br>
10. edit /etc/fstab and change the line mounting /dev/sda1 as /boot to mount /dev/md0 as /boot<br>
<br>
11. Remount our boot drive<br>
<br>
mount /boot<br>
<br>
12. change the id of /dev/md0 to fd (linux raid autodetect)<br>
<br>
sfdisk --change-id /dev/sda 1 fd<br>
<br>
13. Add the old /boot drive to the metadisk<br>
<br>
mdadm --add /dev/md0 /dev/sda1<br>
<br>
The rebuild will be basically instant, so you shouldn't have too much of a problem. I'd cat /proc/mdstat just to be sure.<br>
<br>
14. Set up grub on the new drive<br>
grub<br>
root (hd1,0)<br>
setup (hd1)<br>
<br>
15. Update the initial ramdisk to reflect all the changes you made:<br>
<br>
update-initramfs -t -u<br>
<br>
16. Reboot. If it breaks, you get to keep the pieces.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
and proxmox up-gradation?<br>
</blockquote>
<br>
I've just been doing standard upgrades with:<br>
sudo aptitude update<br>
sudo aptitude full-upgrade<br>
<br>
The only bump is sometimes the initramfs doesn't always get set up with the correct bits, so you end up having to do:<br>
<br>
update-initramfs -k <version> -v -u -t<br>
<br>
But this was only a problem in older kernels - I haven't had a problem recently.<br>
<br>
> is it working fine?<br>
<br>
It has been working fine for about a year and a half.<div><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
if i go for the software RAID "mdam" how stable it would be<br>
</blockquote>
<br></div>
As stable as a single disk. I have no concerns about RAID1 in this regard. Writes are simultaneous, reads are round-robin. So, if the power gets cut, your disks will be in the same shape as they would have been if there was only one - with all the good and bad which that entails.<br>
<br>
I have a bit more concern about other RAID levels - since there are parity calculations, etc. a battery-backed setup is really the way to go there.<div><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
what you say about the performance?<br>
</blockquote>
<br></div>
Slightly faster than a single disk on read, the same on write, and low overhead. Again, there are no calculations to be done, so there is just a bit more additional traffic on the bus. However, the PCIe bus is SO much faster than the individual SATA channels that I'm unconcerned. This used to be more of an issue with it was, back when you could easily saturate a straight PCI bus, but those speeds have so far outstripped the performance of rotational media that I wouldn't even consider it an issue unless you're using SSD's, and even then you'd have to run the numbers and see.<div>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
are you running this in production?<br>
</blockquote>
<br></div>
Depends on your definition. We have it as a process-critical server used for a variety of development, build, and testing servers (nightly builds and testing, etc.). That said, it is not customer facing - it is internal to engineering. So, folks would notice if it blew up, and it would make life difficult, but if it took me 48 hours to get it back, I could.<br>
<br>
As an aside, it's a fairly small rig - Core i7 @ 2.93GHz, 12GB RAM, mirrored 500GB HDDs. There are 8 machines provisioned, with 5 active. Most of them are only allocated 1GB of memory, one has 2GB, and the aggregate Physical memory usage is currently 5.41GB used. CPU Usage is about 3%, with a load of about 0.3.<br>
<br>
So, the machine is bored most of the time.<div><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
please share some of your experience regarding mdam in proxmox as it is not<br>
recommended.<br>
</blockquote>
<br></div>
Yes, and in some cases, they are correct, and I have no argument. In other cases, I respectfully disagree. This is one of those cases.<div><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
i am sending this email only to you because PVE community might<br>
get angry if we try to legalize some thing they already declared<br>
as unsuitable strategy for proxmox :)<br>
</blockquote>
<br></div>
I appreciate that, but I'm putting it back on-list, because I think there's more folks out there doing this than many folks realize. I think there is a valid use case here, and the project maintainers should be aware of it.<br>
<br>
However, they may also have a different opinion, and you're better off getting both sides of the story. Someone could call me a fool and cite some data of which I was not aware, which could help prevent you from making a mistake.<br>
<br>
Besides - we are part of the community.<div><div></div><div><br>
-- <br>
Matthew Caron<br>
Build Engineer<br>
Sixnet | <a href="http://www.sixnet.com" target="_blank">www.sixnet.com</a><br>
O <a href="tel:%2B1%20518%20877%205173%20Ext.%20138" value="+15188775173" target="_blank">+1 518 877 5173 Ext. 138</a><br>
F <a href="tel:%2B1%20518%20602%209209" value="+15186029209" target="_blank">+1 518 602 9209</a><br>
<a href="mailto:matt.caron@sixnet.com" target="_blank">matt.caron@sixnet.com</a><br>
</div></div></blockquote></div><br></div>
</div>