В моём случае первый диск — рабочий. На нём установлена система. Он не в RAID, а сам по себе. Второй диск — пустой. Как можно при таких условиях сделать то, о чём вы говорите:
тут, как по мне, лучше создать рэйд на первом диске и потом добавить второй.
Если инсталлируется новый сервер, то какой смысл собирать RAID1 на одном диске, а потом, когда сервер заработает — добавлять второй? Сразу подняли полноценный RAID, диски мгновенно синхронизировались, потому что информации на них минимум, ну а дальше — установка ПО и ввод сервака в эксплуатацию.
Вопрос всё-таки был о преимуществах создания массива не с полным набором дисков, а не о способе выхода из ситуации «подними RAID во что бы то ни стало».
И да, и нет. В любом случае обращение операционной системы к swap'у вызывает существенное замедление работы сервера, так что по скорости swap на RAID принципиально не будет отличаться от двух таковых на разных дисках.
Всё же отказоустойчивость у RAID1 присутствует, так как при отказе одного диска работоспособность сохраняется. Само собой, последствия отказа следует устранить как можно быстрее, но тем не менее, работа сервера при исправном одном из двух дисков вполне возможна.
Когда смотришь на статьи из MSKB, соответствующие выпущенным обновлениям, то в разделе «Known issues in this update» ничего не говорится о том, что данное обновление устраняет обнаруженную уязвимость Remote Desktop Services. Даже если читать аннотацию к отдельным обновлениям системы безопасности: . Странно, что о RDS там не упоминается.
Можно ли поподробнее разобрать следующие моменты, описанные в решении третьего задания:
Обнаруживаем, что собрали физический volume, которого нам ранее не хватало.Сразу починился lvroot, монтируем его, но предварительно активируем VG:
Составление RAID из /dev/sda2 и /dev/sdc2 проходит успешно, но вот дальше не получается активировать полноценную VG. У «пропавшего» PV был один UUID, а у собранного вручную — совсем другой, о чём ОС честно предупреждает:
pvs -a
WARNING: Device for PV DDuTdi-LRaP-U4k7-9HPF-srd9-v1kc-r7whQ7 not found or rejected by a filter.
Couldn't find device with uuid DDuTdi-LRaP-U4k7-9HPF-srd9-v1kc-r7whQ7.
PV VG Fmt Attr PSize PFree
/dev/loop0 --- 0 0
/dev/loop1 --- 0 0
/dev/loop2 --- 0 0
/dev/mapper/live-base --- 0 0
/dev/mapper/live-rw --- 0 0
/dev/md0 --- 0 0
/dev/sdb1 --- 0 0
/dev/sdb2 vg_c6m1 lvm2 a-- <7.51g <7.51g
[unknown] vg_c6m1 lvm2 a-m 15.01g 11.58g
В итоге активировать группу томов можно, лишь указав в качестве параметра режим частичной активации:
vgchange -ay --activationmode partial
Сменить UUID у /dev/md0 c помощью mdadm -A не получилось и поэтому у меня не вышло присоединить PV к VG, хотя в описанном решении восстановления /dev/md0 было достаточно для того, чтобы «lv_root сразу починился».
Второй момент: после активации в частичном режиме группы томов vg_c6m1 не получилось смонтировать раздел:
mount /dev/mapper/vg_c6m1-lv_root /mount/lvroot
mount: /dev/mapper/vg_c6m1-lv_root: can't read superblock
Попытки проверить и восстановить ФС, указывая положение копии суперблока ни к чему не привели.
Поскольку с третьим заданием я не справился и долго пытался починить сервер, используя «канонический» вариант, то прошу подсказать, что я делал неправильно?
А как можно создать RAID на первом диске, если на нём уже установлена ОС, стоит нужное ПО и хранятся некие, потенциально важные, данные?
Интересно, какое преимущество у этого способа перед способом создания RAID сразу с полным набором дисков?
— согласен, более надёжный вариант.
Когда смотришь на статьи из MSKB, соответствующие выпущенным обновлениям, то в разделе «Known issues in this update» ничего не говорится о том, что данное обновление устраняет обнаруженную уязвимость Remote Desktop Services. Даже если читать аннотацию к отдельным обновлениям системы безопасности: . Странно, что о RDS там не упоминается.
Поскольку с третьим заданием я не справился и долго пытался починить сервер, используя «канонический» вариант, то прошу подсказать, что я делал неправильно?