Install Citrix XenServer on Software RAID
While the Citrix Xen Server is based on a Linux distribution, the installation process does not allow you to manage partition sizes and configuration of hard drives for the installed system. By default, during installation, it asks only the disk on which you want to install with automatic layout of disk space for your needs. During installation, 3 primary partitions are created on the selected disk. Two 4GB and one for the remaining space. (By the way, can someone tell me why the second 4GB partition is needed? I suppose that in case of updates, system restorations there is a copy of the first partition with the installed system, but I did not find the exact information.)
Faced with the need to raise Xen Server on three disks, I thought about ensuring at least some kind of data security. So the layout of the resulting array will take the following form:
Next, how is this implemented.
To get started, put the system on the first disk. We will not go through the installation steps, because there are more than enough materials about this in the network. The only thing I want to note is that during installation, you must refuse to connect the virtual machine storage. To do this,
uncheck the box on the first line of the Virtual Machine Storage screen. We will connect the storage after creating the array. And if you create it now, we scoop up an extra headache for its subsequent transfer.
After installing the system and loading, go to the console and start creating an array. To begin with the theory. We are sitting on a working system on the first disk. Create a beaten array on the two remaining disks. We make a copy of the working system on the created array. Reboot from the beaten array. We connect the original disk to the array and wait for the restoration of the integrity of the array. After that we create storage for virtual machines. And so, let's get started.
After loading into the system, we look at the structure of the disk created by the installer.
The output would be something like this:
The numbers of the starting and ending sectors are important to us.
We erase the partition table on the second and third disk:
We set the GPT partition table there:
We create a partition table identical to the table of the first disk (attention to the numbers, put identical for the corresponding partition on the source disk with the installed system):
But the section identifiers must be replaced. I made identical to the source disk and killed a lot of time fixing problems that the system did not want to start from the array. fd00 partition id with raid
We put the flags of the boot partition
In this case, I will pay special attention only to the lines of mdadm --create. As you might guess, the --level array type. In the first two sections, create a mirror. We unite the third partitions in RAID 5. --raid-devices number of devices included in the array. missing means an array in a degraded state, and at the end, partitions entering the array are separated by spaces. Naturally two out of three. Partitions on the sda drive will be added to the array after.
We create and mount the file system.
We copy.
Replace the file system root name in / mnt / etc / fstab with / dev / md0. Just edit the configuration file.
Copy the bootloader to the second and third disk.
We generate a new image of the system.
We fix the boot config. To do this, open the file /mnt/boot/extlinux.conf in a text editor and replace (root = LABEL = xxx) with root = / dev / md0.
We mount all partitions connected earlier and reboot the system. We are loading now not from the first disk, but from any other one entering the beaten array.
We change the type of partitions and add the partitions of the first disk to our array.
After that, the array rebuild will automatically start. Depending on the size of the disks, it can take quite a while. You can monitor the status and time to completion by looking at the / proc / mdstat file. For continuous monitoring:
You can try to increase the speed of the rebuild. Google publishes many pages on this subject. Without delving deeply into this article, I simply increased the value of stripe_cache_size and calmed down.
Actually one command on the device / dev / md2 creates storage.
All. The system is ready to use. As a result, we have a system on top of a software array that is not tied to a specific hardware controller. The array can be moved to another server and quickly raise a working system. I think it will be necessary to register only new network cards in the system. I hope those who have read to the end will come in handy such a guide.
Faced with the need to raise Xen Server on three disks, I thought about ensuring at least some kind of data security. So the layout of the resulting array will take the following form:
Next, how is this implemented.
System installation.
To get started, put the system on the first disk. We will not go through the installation steps, because there are more than enough materials about this in the network. The only thing I want to note is that during installation, you must refuse to connect the virtual machine storage. To do this,
uncheck the box on the first line of the Virtual Machine Storage screen. We will connect the storage after creating the array. And if you create it now, we scoop up an extra headache for its subsequent transfer.
Array configuration.
Partitioning on the second and third disk.
After installing the system and loading, go to the console and start creating an array. To begin with the theory. We are sitting on a working system on the first disk. Create a beaten array on the two remaining disks. We make a copy of the working system on the created array. Reboot from the beaten array. We connect the original disk to the array and wait for the restoration of the integrity of the array. After that we create storage for virtual machines. And so, let's get started.
After loading into the system, we look at the structure of the disk created by the installer.
sgdisk -p /dev/sda
The output would be something like this:
Disk /dev/sda: 5860533168 sectors, 2.7 TiB
Logical sector size: 512 bytes
Disk identifier (GUID): 77D7DEB8-2759-490F-9BA9-7269A5F9247C
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 5860533134
Partitions will be aligned on 2048-sector boundaries
Total free space is 6042 sectors (3.0 MiB)
Number Start (sector) End (sector) Size Code Name
1 2048 8388641 4.0 GiB 0700
2 8390656 16777249 4.0 GiB 0700
3 16779264 5860533134 2.7 TiB 8E00
The numbers of the starting and ending sectors are important to us.
We erase the partition table on the second and third disk:
sgdisk --zap-all /dev/sdb
sgdisk --zap-all /dev/sdc
We set the GPT partition table there:
sgdisk --mbrtogpt --clear /dev/sdb
sgdisk --mbrtogpt --clear /dev/sdc
We create a partition table identical to the table of the first disk (attention to the numbers, put identical for the corresponding partition on the source disk with the installed system):
sgdisk --new=1:2048:8388641 /dev/sdb
sgdisk --new=2:8390656:16777249 /dev/sdb
sgdisk --new=3:16779264:5860533134 /dev/sdb
sgdisk --new=2:8390656:16777249 /dev/sdc
sgdisk --new=1:2048:8388641 /dev/sdc
sgdisk --new=3:16779264:5860533134 /dev/sdc
But the section identifiers must be replaced. I made identical to the source disk and killed a lot of time fixing problems that the system did not want to start from the array. fd00 partition id with raid
sgdisk --typecode=1:fd00 /dev/sdb
sgdisk --typecode=2:fd00 /dev/sdb
sgdisk --typecode=3:fd00 /dev/sdb
sgdisk --typecode=1:fd00 /dev/sdc
sgdisk --typecode=2:fd00 /dev/sdc
sgdisk --typecode=3:fd00 /dev/sdc
We put the flags of the boot partition
sgdisk /dev/sda --attributes=1:set:2
sgdisk /dev/sdb --attributes=1:set:2
sgdisk /dev/sdc --attributes=1:set:2
Creating raid arrays.
mdadm --stop /dev/md0
mknod /dev/md0 b 9 0
mknod /dev/md1 b 9 1
mknod /dev/md2 b 9 2
mdadm --create /dev/md0 --level=1 --raid-devices=3 missing /dev/sdb1 /dev/sdc1
mdadm --create /dev/md1 --level=1 --raid-devices=3 missing /dev/sdb2 /dev/sdc2
mdadm --create /dev/md2 --level=5 --raid-devices=3 missing /dev/sdb3 /dev/sdc3
mdadm --grow /dev/md0 -b internal
mdadm --grow /dev/md1 -b internal
mdadm --grow /dev/md2 -b internal
In this case, I will pay special attention only to the lines of mdadm --create. As you might guess, the --level array type. In the first two sections, create a mirror. We unite the third partitions in RAID 5. --raid-devices number of devices included in the array. missing means an array in a degraded state, and at the end, partitions entering the array are separated by spaces. Naturally two out of three. Partitions on the sda drive will be added to the array after.
Copy the working system to the created array.
We create and mount the file system.
mkfs.ext3 /dev/md0
mount /dev/md0 /mnt
We copy.
cp -vxpR / /mnt
Replace the file system root name in / mnt / etc / fstab with / dev / md0. Just edit the configuration file.
Copy the bootloader to the second and third disk.
mount --bind /dev /mnt/dev
mount -t sysfs none /mnt/sys
mount -t proc none /mnt/proc
chroot /mnt
/sbin/extlinux --raid --install /boot
exit
dd if=/mnt/usr/share/syslinux/gptmbr.bin of=/dev/sdb
dd if=/mnt/usr/share/syslinux/gptmbr.bin of=/dev/sdс
We generate a new image of the system.
chroot /mnt
mkinitrd -v -f --theme=/usr/share/splash --without-multipath /boot/initrd-`uname -r`.img `uname -r`
exit
We fix the boot config. To do this, open the file /mnt/boot/extlinux.conf in a text editor and replace (root = LABEL = xxx) with root = / dev / md0.
We mount all partitions connected earlier and reboot the system. We are loading now not from the first disk, but from any other one entering the beaten array.
Adding the first disk to the array.
We change the type of partitions and add the partitions of the first disk to our array.
sgdisk --typecode=1:fd00 /dev/sda1
sgdisk --typecode=2:fd00 /dev/sda2
sgdisk --typecode=3:fd00 /dev/sda3
mdadm -a /dev/md0 /dev/sda1
mdadm -a /dev/md1 /dev/sda2
mdadm -a /dev/md2 /dev/sda3
After that, the array rebuild will automatically start. Depending on the size of the disks, it can take quite a while. You can monitor the status and time to completion by looking at the / proc / mdstat file. For continuous monitoring:
watch -n 1 cat /proc/mdstat
You can try to increase the speed of the rebuild. Google publishes many pages on this subject. Without delving deeply into this article, I simply increased the value of stripe_cache_size and calmed down.
Creating a data warehouse.
Actually one command on the device / dev / md2 creates storage.
xe sr-create content-type=user type=lvm device-config:device=/dev/md2 shared=false name-label="Local storage"
All. The system is ready to use. As a result, we have a system on top of a software array that is not tied to a specific hardware controller. The array can be moved to another server and quickly raise a working system. I think it will be necessary to register only new network cards in the system. I hope those who have read to the end will come in handy such a guide.