Добрый день, друзья. Сегодня я бы хотел поделиться своим личным опытом по настройке Proxmox на soft-Raid 10.
Что имеем:
Что хотим:
Что делаем – общий план действий:
Под катом поэтапное прохождение квеста.
А теперь поэтапно.
Первый момент:
Подключил флешку – если вкратце — не найден установочный диск. Не могу смонтироваться.
Не стал разбираться что да как, да почему. Записал образ на CD-диск и подключил USB CDROM (благо он был рядом)
Второй момент:
Подключил к серверу CDROM и клавиатуру в передние порты сервера (их у него два) – первое что увидел, на первом приветственном скрине proxmox нельзя ничего нажать без мышки. То есть прееключение Tab-ом по управляющим кнопкам не происходит. Т.к. сервер был в стойке и залазить сзади было проблематично, начал по очереди втыкать клаву и мышку. Мышкой щелкаю «далее», клавой — ввожу данные.
Установка состоит из нескольких шагов:
PROXMOX установлен на первый диск, который он обозвал как /dev/sda. Подключаюсь со своего ноута на адрес, который указал при установке:
Обновляю систему:
Это не дело. Покупать пока лицензию на поддержку не планирую. Меняю официальную подписку на их «бесплатный» репозиторий.
Там вижу:
Меняю на:
И снова обновляюсь и ставлю обновки системы:
Теперь всё обновилось без запинки и система в новейшем состоянии. Ставлю пакеты для работы с рейдом:
Теперь определим точный размер первого диска, он нам пригодится в дальнейшем:
Видим что ровно 1000GB – запомним. Размечаем остальные разделы под наш массив. Первым делом очищаем таблицу разделов на трех пустых дисках и размечаем диски под GPT:
Размечаем:
Второй:
Третий:
Четвертый:
Теперь воссоздаем разделы так же как на оригинальном первом диске:
1.
2.
3.
Вот тут нам пригодится знание размера оригинального первого диска.
4.
Все эти четыре шага проделываем для всех наших дисков: sdb, sdc, sdd. Вот что у меня получилось:
Это оригинальный:
А это второй, третий и четвертый (с разницей в букве диска).
Далее надо уточнить – если вы первый раз играете с этим кейсом и до этого на сервере, а главное на винчестерах, не было даже понятия RAID – можно пропустить этот пункт. Если же что-то не получилось, значит RAID уже возможно был установлен и на винчестерах есть суперблоки которые нужно удалять.
Проверить так:
Проверить нужно все четыре диска.
Теперь настроим mdadm
Создаем конфиг на основе примера:
Опустошаем:
Открываем:
Вводим и сохраняем:
Почту пока оставим как есть, потом к ней еще вернемся.
Теперь поднимаем наши RAID в режиме деградации (пропуская первый рабочий винчестер).
И второй:
Тут надо пояснить по ключам:
UDP. После массы комментариев я вышел на один важный момент.
В процессе создания я сознательно задавал chunk размер в 2048, вместо того что бы пропустить этот флаг и оставить его по умолчанию. Данный флаг существенно снижает производительность. Особенно это даже визуально заметно на виртуалках с Windows.
То есть верная команда на создание должна выглядеть вот так:
и
Сохраняем конфигурацию:
Проверяем содержание:
Теперь нам нужно действующий LVM массив перенести на три пустых диска. Для начала создаем в рейде md1 — LVM-раздел:
И добавляем его в группу pve:
Теперь переносим данные с оригинального LVM на новосозданный:
Процесс долгий. У меня занял порядка 10 часов. Интересно, что запустил я его по привычке будучи подключенным по SSH и на 1,3% понял что сидеть столько времени с ноутом на работе как минимум не удобно. Отменил операцию через CTRL+C, подошел к физическому серверу и попробовал запустить команду переноса там, но умная железяка отписалась, что процесс уже идет и команда второй раз выполнятся не будет, и начала рисовать проценты переноса на реальном экране. Как минимум спасибо :)
Процесс завершился два раза написав 100%. Убираем из LVM первый диск:
Переносим загрузочный /boot в наш новый рейд /md0, но для начала форматируем и монтируем сам рейд.
Создаем директорию и монтируем туда рейд:
Копируем содержимое живого /boot:
Отмонтируем рейд и удаляем временную директорию:
Определим UUID раздела рейда, где хранится /boot – это нужно, что бы правильно записать его в таблицу /etc/fstab:
/dev/md0: UUID=«6b75c86a-0501-447c-8ef5-386224e48538» TYPE=«ext4»
Откроем таблицу и пропишем в ее конец данные загрузки /boot:
Прописываем и сохраняем:
Теперь монтируем /boot:
Разрешим ОС загружаться, даже если состояние BOOT_DEGRADED (то есть рейд деградирован по причине выхода из строя дисков):
Прописываем загрузку ramfs:
Графический режим загрузчика отключаем:
Инсталируем загрузчик на все три диска:
Теперь очень важный момент. Мы берем за основу второй диск /dev/sdb, на котором система, загрузчик и grub и переносим всё это на первый диск /dev/sda, что бы в последствии сделать его так же частью нашего рейда. Для этого рассматриваем первый диск как чистый и размечаем так же, как другие в начале этой статьи
Занулим и пометим как GPT:
Разбиваем его по разделам в точности как другие три:
Тут нам снова понадобиться точное знание размера диска. Напомню, получили мы его командой, которую в данном случае надо применять к диску /dev/sdb:
Так как диски у нас одинаковые, то размер не изменился – 1000Gb. Размечаем основной раздел:
Должно получится так:
Осталось добавить этот диск в общий массив. Второй раздел соответственно в /md0, а третий в /md1:
Ждем синхронизации…
Данная команда в реальном времени показывает процесс синхронизации:
И если первый рейд с /boot синхронизировался сразу, то для синхронизации второго понадобилось терпение (в районе 5 часов).
Осталось установить загрузчик на добавленный диск (тут нужно понимать, что делать это нужно только после того, как диски полностью синхронизировались).
Пару раз нажимаем Enter ничего не меняя и на последнем шаге отмечаем галками все 4 диска
md0/md1 не трогаем!
Осталось перезагрузить систему и проверить, что все в порядке:
Система загрузилась нормально (я даже несколько раз менял в BIOS порядок загрузки винтов — грузится одинаково правильно).
Проверяем массивы:
По четыре подковы в каждом рейде говорят о том, что все четыре диска в работе. Смотрим информацию по массивам (на примере первого, точнее нулевого).
Видим, что массив типа RAID10, все диски на месте, активные и синхронизированы.
Теперь можно было бы поиграться с отключением дисков, изменении диска-загрузчика в BIOS, но перед этим давайте настроим уведомление администратора при сбоях в работе дисков, а значит и самого рейда. Без уведомления рейд будет умирать медленно и мучительно, а никто не будет об этом знать.
В Proxmox по умолчанию уже стоит postfix, удалять его я не стал, хоть и сознательно понимаю что другие MTA было бы проще настроить.
Ставим SASL библиотеку (мне она нужна, что бы работать с нашим внешним почтовым сервером):
Создаем файл с данными от которых будем авторизовываться на нашем удаленном почтовом сервере:
Там прописываем строчку:
Теперь создаем транспортный файл:
Туда пишем:
Создаем generic_map:
Тут пишем (обозначаем от кого будет отправляться почта):
Создаем sender_relay (по сути, маршрут до внешнего сервера):
И пишем туда:
Хешируем файлы:
В файле /etc/postfix/main.cf у меня получилась вот такая рабочая конфигурация:
Перезагружаем postfix:
Теперь нужно вернуться в файл настроек рейда и немного его поправить. Указываем кому получать письма счастья и от кого они будут приходить.
У меня вот так:
Перезапускаем mdadm, что бы перечитать настройки:
Проверяем через консоль тестирование рейда и отправку письма:
У меня пришло два письма с информацией по обоим созданным мною рейдам. Осталось добавить задачу тестирования в крон и убрать ключ –test. Чтобы письма приходили только тогда, когда что-то произошло:
Добавляем задачу (не забудьте после строки нажать на Enter и перевести курсор вниз, что бы появилась пустая строка):
Каждое утро в 5 утра будет производится тестирование и если возникнут проблемы, произойдет отправка почты.
На этом всё. Возможно перемудрил с конфигом postfix – пока пытался добиться нормальной отправки через наш внешний сервер, много чего надобавлял. Буду признателен, если поправите (упростите).
В следующей статье я хочу поделиться опытом переезда виртуальных машин с нашего гипервизора Esxi-6 на этот новый Proxmox. Думаю будет интересно.
UPD.
Стоит отдельно отменить момент с физическим местом на разделе /dev/data – это основной раздел созданный как LVM-Thin
Когда ставился Proxmox, он автоматически разметил /dev/sda с тем учетом, что на /root раздел где хранится система, ISO, дампы и темплеи контейнеров, он выделил 10% емкости от раздела, а именно 100Gb. На оставшемся месте он создал LVM-Thin раздел, который по сути никуда не монтируется (это еще одна тонкость версии >4.2, после перевода дисков в GPT). И как вы понимаете этот раздел стал размером 900Gb. Когда мы подняли RAID10 из 4х дисков по 1Tb – мы получили емкость (с учетом резерва RAID1+0) – 2Tb
Но когда копировали LVM в рейд – копировали его как контейнер, с его размером в 900Gb.
При первом заходе в админку Proxmox внимательный зритель может заметить, что тыкая на раздел local-lvm(pve1) – мы и наблюдаем эти с копейками 800Gb
Так вот что бы расширить LVM-Thin на весь размер в 1,9TB нам потребуется выполнить все одну команду:
После этого систему не нужно даже перезапускать.
Не нужно делать resize2fs – и это скорее даже невозможно, потому как система начнет ругаться на
И правильно начнет – этот раздел у нас не подмонтирован через fstab
В общем пока я пытался понять, как расширить диск и читал форум Proxmox – система тем временем уже во всю показывала новый размер, как в таблице, так и на шкале.
Что имеем:
- Сервер HP ProLiant DL120 G6 (10 GB ОЗУ)
- 4x1000Gb SATA винчестера – без физического RAID контроллера на борту
- Флешка с PROXMOX 4.3 (об этом ниже)
Что хотим:
- Получить инсталляцию PROXMOX 4.3 установленную полностью на S-RAID 10 GPT, что бы при отказе любого диска система продолжала работу.
- Получить уведомление об отказе сбойного диска на почту.
Что делаем – общий план действий:
- Устанавливаем PROXMOX 4.3
- Поднимаем и тестируем RAID10
- Настраиваем уведомления на почту
Под катом поэтапное прохождение квеста.
А теперь поэтапно.
Первый момент:
Подключил флешку – если вкратце — не найден установочный диск. Не могу смонтироваться.
Не стал разбираться что да как, да почему. Записал образ на CD-диск и подключил USB CDROM (благо он был рядом)
Второй момент:
Подключил к серверу CDROM и клавиатуру в передние порты сервера (их у него два) – первое что увидел, на первом приветственном скрине proxmox нельзя ничего нажать без мышки. То есть прееключение Tab-ом по управляющим кнопкам не происходит. Т.к. сервер был в стойке и залазить сзади было проблематично, начал по очереди втыкать клаву и мышку. Мышкой щелкаю «далее», клавой — ввожу данные.
Установка состоит из нескольких шагов:
- Согласится с их требованиями
- Выбрать винчестер, куда система установится.
- Выбрать страну и часовой пояс
- Указать имя сервера, адресацию
- И собственно немного подождать развертки образа на сервер.
PROXMOX установлен на первый диск, который он обозвал как /dev/sda. Подключаюсь со своего ноута на адрес, который указал при установке:
root@pve1:~#ssh root@192.168.1.3Обновляю систему:
root@pve1:~#apt-get update На выходе вижу
Ign http://ftp.debian.org jessie InRelease
Get:1 http://ftp.debian.org jessie Release.gpg [2,373 B]
Get:2 http://security.debian.org jessie/updates InRelease [63.1 kB]
Get:3 http://ftp.debian.org jessie Release [148 kB]
Get:4 https://enterprise.proxmox.com jessie InRelease [401 B]
Ign https://enterprise.proxmox.com jessie InRelease
Get:5 https://enterprise.proxmox.com jessie Release.gpg [401 B]
Ign https://enterprise.proxmox.com jessie Release.gpg
Get:6 http://ftp.debian.org jessie/main amd64 Packages [6,787 kB]
Get:7 https://enterprise.proxmox.com jessie Release [401 B]
Ign https://enterprise.proxmox.com jessie Release
Get:8 http://security.debian.org jessie/updates/main amd64 Packages [313 kB]
Get:9 https://enterprise.proxmox.com jessie/pve-enterprise amd64 Packages [401 B]
Get:10 https://enterprise.proxmox.com jessie/pve-enterprise Translation-en_US [401 B]
Get:11 https://enterprise.proxmox.com jessie/pve-enterprise Translation-en [401 B]
Get:12 https://enterprise.proxmox.com jessie/pve-enterprise amd64 Packages [401 B]
Get:13 https://enterprise.proxmox.com jessie/pve-enterprise Translation-en_US [401 B]
Get:14 https://enterprise.proxmox.com jessie/pve-enterprise Translation-en [401 B]
Get:15 https://enterprise.proxmox.com jessie/pve-enterprise amd64 Packages [401 B]
Get:16 https://enterprise.proxmox.com jessie/pve-enterprise Translation-en_US [401 B]
Get:17 https://enterprise.proxmox.com jessie/pve-enterprise Translation-en [401 B]
Get:18 https://enterprise.proxmox.com jessie/pve-enterprise amd64 Packages [401 B]
Get:19 https://enterprise.proxmox.com jessie/pve-enterprise Translation-en_US [401 B]
Get:20 http://security.debian.org jessie/updates/contrib amd64 Packages [2,506 B]
Get:21 https://enterprise.proxmox.com jessie/pve-enterprise Translation-en [401 B]
Get:22 https://enterprise.proxmox.com jessie/pve-enterprise amd64 Packages [401 B]
Err https://enterprise.proxmox.com jessie/pve-enterprise amd64 Packages
HttpError401
Get:23 https://enterprise.proxmox.com jessie/pve-enterprise Translation-en_US [401 B]
Get:24 http://security.debian.org jessie/updates/contrib Translation-en [1,211 B]
Ign https://enterprise.proxmox.com jessie/pve-enterprise Translation-en_US
Get:25 https://enterprise.proxmox.com jessie/pve-enterprise Translation-en [401 B]
Ign https://enterprise.proxmox.com jessie/pve-enterprise Translation-en
Get:26 http://security.debian.org jessie/updates/main Translation-en [169 kB]
Get:27 http://ftp.debian.org jessie/contrib amd64 Packages [50.2 kB]
Get:28 http://ftp.debian.org jessie/contrib Translation-en [38.5 kB]
Get:29 http://ftp.debian.org jessie/main Translation-en [4,583 kB]
Fetched 12.2 MB in 15s (778 kB/s)
W: Failed to fetch https://enterprise.proxmox.com/debian/dists/jessie/pve-enterprise/binary-amd64/Packages HttpError401
E: Some index files failed to download. They have been ignored, or old ones used instead.Это не дело. Покупать пока лицензию на поддержку не планирую. Меняю официальную подписку на их «бесплатный» репозиторий.
root@pve1:~#nano /etc/apt/sources.list.d/pve-enterprise.listТам вижу:
deb https://enterprise.proxmox.com/debian jessie pve-enterpriseМеняю на:
deb http://download.proxmox.com/debian jessie pve-no-subscriptionИ снова обновляюсь и ставлю обновки системы:
root@pve1:~#apt-get update && apt-get upgradeТеперь всё обновилось без запинки и система в новейшем состоянии. Ставлю пакеты для работы с рейдом:
root@pve1:~#apt-get install -y mdadm initramfs-tools partedТеперь определим точный размер первого диска, он нам пригодится в дальнейшем:
root@pve1:~#parted /dev/sda printModel: ATA MB1000EBNCF (scsi)
Disk /dev/sda: 1000GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:
Number Start End Size File system Name Flags
1 1049kB 10.5MB 9437kB primary bios_grub
2 10.5MB 1000MB 990MB ext4 primary
3 1000MB 1000GB 999GB primaryВидим что ровно 1000GB – запомним. Размечаем остальные разделы под наш массив. Первым делом очищаем таблицу разделов на трех пустых дисках и размечаем диски под GPT:
root@pve1:~#dd if=/dev/zero of=/dev/sb[bcd] bs=512 count=11+0 records in
1+0 records out
512 bytes (512 B) copied, 7.8537e-05 s, 6.5 MB/sРазмечаем:
Второй:
root@pve1:~#parted /dev/sdb mklabel gptWarning: The existing disk label on /dev/sdb will be destroyed and all data on this disk will be lost. Do you want to continue?
Yes/No? yes
Information: You may need to update /etc/fstab.Третий:
root@pve1:~#parted /dev/sdc mklabel gptWarning: The existing disk label on /dev/sdc will be destroyed and all data on this disk will be lost. Do you want to continue?
Yes/No? yes
Information: You may need to update /etc/fstab.Четвертый:
root@pve1:~#parted /dev/sdd mklabel gptWarning: The existing disk label on /dev/sdd will be destroyed and all data on this disk will be lost. Do you want to continue?
Yes/No? yes
Information: You may need to update /etc/fstab.Теперь воссоздаем разделы так же как на оригинальном первом диске:
1.
root@pve1:~#parted /dev/sdb mkpart primary 1M 10MInformation: You may need to update /etc/fstab.2.
root@pve1:~#parted /dev/sdb set 1 bios_grub onInformation: You may need to update /etc/fstab.3.
root@pve1:~#parted /dev/sdb mkpart primary 10М 1GInformation: You may need to update /etc/fstab.Вот тут нам пригодится знание размера оригинального первого диска.
4.
root@pve1:~#parted /dev/sdb mkpart primary 1G 1000GBInformation: You may need to update /etc/fstab.Все эти четыре шага проделываем для всех наших дисков: sdb, sdc, sdd. Вот что у меня получилось:
Это оригинальный:
root@pve1:~#parted /dev/sda printModel: ATA MB1000EBNCF (scsi)
Disk /dev/sda: 1000GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:
Number Start End Size File system Name Flags
1 17.4kB 1049kB 1031kB bios_grub
2 1049kB 134MB 133MB fat32 boot, esp
3 134MB 1000GB 1000GB lvmА это второй, третий и четвертый (с разницей в букве диска).
root@pve1:~#parted /dev/sdb printModel: ATA MB1000EBNCF (scsi)
Disk /dev/sdd: 1000GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:
Number Start End Size File system Name Flags
1 1049kB 10.5MB 9437kB primary bios_grub
2 10.5MB 1000MB 990MB primary
3 1000MB 1000GB 999GB primaryДалее надо уточнить – если вы первый раз играете с этим кейсом и до этого на сервере, а главное на винчестерах, не было даже понятия RAID – можно пропустить этот пункт. Если же что-то не получилось, значит RAID уже возможно был установлен и на винчестерах есть суперблоки которые нужно удалять.
Проверить так:
root@pve1:~#mdadm --misc --examine /dev/sda/dev/sda:
MBR Magic : aa55
Partition[0] : 1953525167 sectors at 1 (type ee)Проверить нужно все четыре диска.
Теперь настроим mdadm
Создаем конфиг на основе примера:
root@pve1:~#cp /etc/mdadm/mdadm.conf /etc/mdadm/mdadm.conf.origОпустошаем:
root@pve1:~#echo "" > /etc/mdadm/mdadm.confОткрываем:
root@pve1:~#nano /etc/mdadm/mdadm.confВводим и сохраняем:
CREATE owner=root group=disk mode=0660 auto=yes
MAILADDR user@mail.domainПочту пока оставим как есть, потом к ней еще вернемся.
Теперь поднимаем наши RAID в режиме деградации (пропуская первый рабочий винчестер).
- В /dev/md0 – у меня будет /boot
- В /dev/md1 – VML раздел с системой
root@pve1:~#mdadm --create /dev/md0 --metadata=0.90 --level=10 --chunk=2048 --raid-devices=4 missing /dev/sd[bcd]2mdadm: array /dev/md0 started.И второй:
root@pve1:~#mdadm --create /dev/md1 --metadata=0.90 --level=10 --chunk=2048 --raid-devices=4 missing /dev/sd[bcd]3mdadm: array /dev/md1 started.Тут надо пояснить по ключам:
- --level=10 – говорит что наш RAID будет именно 10
- --chunk=2048 – размер кластера на разделе
- --raid-devices=4 – в рейде будут принимать участие четыре устройства
- missing /dev/sd[bcd]2 – первый рабочий раздел пока помечаем отсутствующим, остальные три добавляем в рейд
UDP. После массы комментариев я вышел на один важный момент.
В процессе создания я сознательно задавал chunk размер в 2048, вместо того что бы пропустить этот флаг и оставить его по умолчанию. Данный флаг существенно снижает производительность. Особенно это даже визуально заметно на виртуалках с Windows.
То есть верная команда на создание должна выглядеть вот так:
root@pve1:~#mdadm --create /dev/md0 --metadata=0.90 --level=10 --raid-devices=4 missing /dev/sd[bcd]2и
root@pve1:~#mdadm --create /dev/md1 --metadata=0.90 --level=10 --raid-devices=4 missing /dev/sd[bcd]3Сохраняем конфигурацию:
root@pve1:~#mdadm --detail --scan >> /etc/mdadm/mdadm.confПроверяем содержание:
root@pve1:~# cat /etc/mdadm/mdadm.confCREATE owner=root group=disk mode=0660 auto=yes
MAILADDR user@mail.domain
ARRAY /dev/md0 metadata=0.90 UUID=4df20dfa:4480524a:f7703943:85f444d5
ARRAY /dev/md1 metadata=0.90 UUID=432e3654:e288eae2:f7703943:85f444d5Теперь нам нужно действующий LVM массив перенести на три пустых диска. Для начала создаем в рейде md1 — LVM-раздел:
root@pve1:~#pvcreate /dev/md1 -ffPhysical volume "/dev/md1" successfully createdИ добавляем его в группу pve:
root@pve1:~#vgextend pve /dev/md1Volume group "pve" successfully extendedТеперь переносим данные с оригинального LVM на новосозданный:
root@pve1:~#pvmove /dev/sda3 /dev/md1/dev/sda3: Moved: 0.0%Процесс долгий. У меня занял порядка 10 часов. Интересно, что запустил я его по привычке будучи подключенным по SSH и на 1,3% понял что сидеть столько времени с ноутом на работе как минимум не удобно. Отменил операцию через CTRL+C, подошел к физическому серверу и попробовал запустить команду переноса там, но умная железяка отписалась, что процесс уже идет и команда второй раз выполнятся не будет, и начала рисовать проценты переноса на реальном экране. Как минимум спасибо :)
Процесс завершился два раза написав 100%. Убираем из LVM первый диск:
root@pve1:~#vgreduce pve /dev/sda3 Removed "/dev/sda3" from volume group "pve"Переносим загрузочный /boot в наш новый рейд /md0, но для начала форматируем и монтируем сам рейд.
root@pve1:~#mkfs.ext4 /dev/md0mke2fs 1.42.12 (29-Aug-2014)
Creating filesystem with 482304 4k blocks and 120720 inodes
Filesystem UUID: 6b75c86a-0501-447c-8ef5-386224e48538
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912
Allocating group tables: done
Writing inode tables: done
Creating journal (8192 blocks): done
Writing superblocks and filesystem accounting information: doneСоздаем директорию и монтируем туда рейд:
root@pve1:~#mkdir /mnt/md0root@pve1:~#mount /dev/md0 /mnt/md0Копируем содержимое живого /boot:
root@pve1:~#cp -ax /boot/* /mnt/md0Отмонтируем рейд и удаляем временную директорию:
root@pve1:~#umount /mnt/md0root@pve1:~#rmdir /mnt/md0Определим UUID раздела рейда, где хранится /boot – это нужно, что бы правильно записать его в таблицу /etc/fstab:
root@pve1:~#blkid |grep md0/dev/md0: UUID=«6b75c86a-0501-447c-8ef5-386224e48538» TYPE=«ext4»
Откроем таблицу и пропишем в ее конец данные загрузки /boot:
root@pve1:~#nano /etc/fstabПрописываем и сохраняем:
UUID="6b75c86a-0501-447c-8ef5-386224e48538" /boot ext4 defaults 0 1Теперь монтируем /boot:
root@pve1:~#mount /bootРазрешим ОС загружаться, даже если состояние BOOT_DEGRADED (то есть рейд деградирован по причине выхода из строя дисков):
root@pve1:~#echo "BOOT_DEGRADED=true" > /etc/initramfs-tools/conf.d/mdadmПрописываем загрузку ramfs:
root@pve1:~#mkinitramfs -o /boot/initrd.img-`uname -r`Графический режим загрузчика отключаем:
root@pve1:~#echo "GRUB_TERMINAL=console" >> /etc/default/grubИнсталируем загрузчик на все три диска:
root@pve1:~#grub-install /dev/sdbInstalling for i386-pc platform.
Installation finished. No error reported.root@pve1:~#grub-install /dev/sdc>Installing for i386-pc platform.
Installation finished. No error reported.root@pve1:~#grub-install /dev/sddInstalling for i386-pc platform.
Installation finished. No error reported.Теперь очень важный момент. Мы берем за основу второй диск /dev/sdb, на котором система, загрузчик и grub и переносим всё это на первый диск /dev/sda, что бы в последствии сделать его так же частью нашего рейда. Для этого рассматриваем первый диск как чистый и размечаем так же, как другие в начале этой статьи
Занулим и пометим как GPT:
root@pve1:~#dd if=/dev/zero of=/dev/sda bs=512 count=11+0 records in
1+0 records out
512 bytes (512 B) copied, 0.0157829 s, 32.4 kB/sroot@pve1:~#parted /dev/sda mklabel gptInformation: You may need to update /etc/fstab.Разбиваем его по разделам в точности как другие три:
root@pve1:~#parted /dev/sda mkpart primary 1M 10MInformation: You may need to update /etc/fstab.root@pve1:~#parted /dev/sda set 1 bios_grub onInformation: You may need to update /etc/fstab.root@pve1:~#parted /dev/sda mkpart primary 10М 1GInformation: You may need to update /etc/fstab.Тут нам снова понадобиться точное знание размера диска. Напомню, получили мы его командой, которую в данном случае надо применять к диску /dev/sdb:
root@pve1:~#parted /dev/sdb printТак как диски у нас одинаковые, то размер не изменился – 1000Gb. Размечаем основной раздел:
root@pve1:~#parted /dev/sda mkpart primary 1G 1000GbInformation: You may need to update /etc/fstab.Должно получится так:
root@pve1:~#parted /dev/sda printModel: ATA MB1000EBNCF (scsi)
Disk /dev/sda: 1000GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:
Number Start End Size File system Name Flags
1 1049kB 10.5MB 9437kB fat32 primary bios_grub
2 10.5MB 1000MB 990MB primary
3 1000MB 1000GB 999GB primaryОсталось добавить этот диск в общий массив. Второй раздел соответственно в /md0, а третий в /md1:
root@pve1:~#mdadm --add /dev/md0 /dev/sda2mdadm: added /dev/sda2root@pve1:~#mdadm --add /dev/md1 /dev/sda3mdadm: added /dev/sda3Ждем синхронизации…
root@pve1:~#watch cat /proc/mdstatДанная команда в реальном времени показывает процесс синхронизации:
Every 2.0s: cat /proc/mdstat Fri Nov 11 10:09:18 2016
Personalities : [raid10]
md1 : active raid10 sda3[4] sdd3[3] sdc3[2] sdb3[1]
1951567872 blocks 2048K chunks 2 near-copies [4/3] [_UUU]
[>....................] recovery = 0.5% (5080064/975783936) finish=284.8min speed=56796K/sec
bitmap: 15/15 pages [60KB], 65536KB chunk
md0 : active raid10 sda2[0] sdd2[3] sdc2[2] sdb2[1]
1929216 blocks 2048K chunks 2 near-copies [4/4] [UUUU]И если первый рейд с /boot синхронизировался сразу, то для синхронизации второго понадобилось терпение (в районе 5 часов).
Осталось установить загрузчик на добавленный диск (тут нужно понимать, что делать это нужно только после того, как диски полностью синхронизировались).
root@pve1:~#dpkg-reconfigure grub-pcПару раз нажимаем Enter ничего не меняя и на последнем шаге отмечаем галками все 4 диска
md0/md1 не трогаем!
Осталось перезагрузить систему и проверить, что все в порядке:
root@pve1:~#shutdown –r nowСистема загрузилась нормально (я даже несколько раз менял в BIOS порядок загрузки винтов — грузится одинаково правильно).
Проверяем массивы:
<source lang="vim">root@pve1:~#cat /proc/mdstatPersonalities : [raid10]
md1 : active raid10 sda3[0] sdd3[3] sdc3[2] sdb3[1]
1951567872 blocks 2048K chunks 2 near-copies [4/4] [UUUU]
bitmap: 2/15 pages [8KB], 65536KB chunk
md0 : active raid10 sda2[0] sdd2[3] sdc2[2] sdb2[1]
1929216 blocks 2048K chunks 2 near-copies [4/4] [UUUU]По четыре подковы в каждом рейде говорят о том, что все четыре диска в работе. Смотрим информацию по массивам (на примере первого, точнее нулевого).
root@pve1:~#mdadm --detail /dev/md0/dev/md0:
Version : 0.90
Creation Time : Thu Nov 10 15:12:21 2016
Raid Level : raid10
Array Size : 1929216 (1884.32 MiB 1975.52 MB)
Used Dev Size : 964608 (942.16 MiB 987.76 MB)
Raid Devices : 4
Total Devices : 4
Preferred Minor : 0
Persistence : Superblock is persistent
Update Time : Fri Nov 11 10:07:47 2016
State : active
Active Devices : 4
Working Devices : 4
Failed Devices : 0
Spare Devices : 0
Layout : near=2
Chunk Size : 2048K
UUID : 4df20dfa:4480524a:f7703943:85f444d5 (local to host pve1)
Events : 0.27
Number Major Minor RaidDevice State
0 8 2 0 active sync set-A /dev/sda2
1 8 18 1 active sync set-B /dev/sdb2
2 8 34 2 active sync set-A /dev/sdc2
3 8 50 3 active sync set-B /dev/sdd2Видим, что массив типа RAID10, все диски на месте, активные и синхронизированы.
Теперь можно было бы поиграться с отключением дисков, изменении диска-загрузчика в BIOS, но перед этим давайте настроим уведомление администратора при сбоях в работе дисков, а значит и самого рейда. Без уведомления рейд будет умирать медленно и мучительно, а никто не будет об этом знать.
В Proxmox по умолчанию уже стоит postfix, удалять его я не стал, хоть и сознательно понимаю что другие MTA было бы проще настроить.
Ставим SASL библиотеку (мне она нужна, что бы работать с нашим внешним почтовым сервером):
root@pve1:/etc#apt-get install libsasl2-modulesСоздаем файл с данными от которых будем авторизовываться на нашем удаленном почтовом сервере:
root@pve1:~#touch /etc/postfix/sasl_passwdТам прописываем строчку:
[mail.domain.ru] pve1@domain.ru:passwordТеперь создаем транспортный файл:
root@pve1:~#touch /etc/postfix/transportТуда пишем:
domain.ru smtp:[mail.domain.ru]Создаем generic_map:
root@pve1:~#touch /etc/postfix/genericТут пишем (обозначаем от кого будет отправляться почта):
root pve1@domain.ruСоздаем sender_relay (по сути, маршрут до внешнего сервера):
root@pve1:~#touch /etc/postfix/sender_relayИ пишем туда:
pve1@domain.ru smtp.domain.ruХешируем файлы:
root@pve1:~#postmap transportroot@pve1:~#postmap sasl_passwdroot@pve1:~#postmap geniricroot@pve1:~#postmap sender_relayВ файле /etc/postfix/main.cf у меня получилась вот такая рабочая конфигурация:
main.cf
# See /usr/share/postfix/main.cf.dist for a commented, more complete version
myhostname=domain.ru
smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
biff = no
# appending .domain is the MUA's job.
append_dot_mydomain = no
# Uncomment the next line to generate «delayed mail» warnings
#delay_warning_time = 4h
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
mydestination = $myhostname, localhost.$mydomain, localhost
mynetworks = 127.0.0.0/8,192.168.1.0/24
inet_interfaces = loopback-only
recipient_delimiter = +
smtp_tls_loglevel = 1
smtp_tls_session_cache_database = btree:/var/lib/postfix/smtp_tls_session_cache
smtp_use_tls = no
tls_random_source = dev:/dev/urandom
## SASL Settings
smtpd_sasl_auth_enable = no
smtp_sasl_auth_enable = yes
smtpd_use_pw_server=yes
enable_server_options=yes
smtpd_pw_server_security_options=plain, login
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sender_dependent_authentification = yes
sender_dependent_relayhost_maps = hash:/etc/postfix/sender_relay
smtpd_sasl_local_domain = $myhostname
smtp_sasl_security_options = noanonymous
smtp_sasl_tls_security_options = noanonymous
smtpd_sasl_application_name = smtpd
smtp_always_send_ehlo = yes
relayhost =
transport_maps = hash:/etc/postfix/transport
smtp_generic_maps = hash:/etc/postfix/generic
disable_dns_lookups = yes
myhostname=domain.ru
smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
biff = no
# appending .domain is the MUA's job.
append_dot_mydomain = no
# Uncomment the next line to generate «delayed mail» warnings
#delay_warning_time = 4h
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
mydestination = $myhostname, localhost.$mydomain, localhost
mynetworks = 127.0.0.0/8,192.168.1.0/24
inet_interfaces = loopback-only
recipient_delimiter = +
smtp_tls_loglevel = 1
smtp_tls_session_cache_database = btree:/var/lib/postfix/smtp_tls_session_cache
smtp_use_tls = no
tls_random_source = dev:/dev/urandom
## SASL Settings
smtpd_sasl_auth_enable = no
smtp_sasl_auth_enable = yes
smtpd_use_pw_server=yes
enable_server_options=yes
smtpd_pw_server_security_options=plain, login
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sender_dependent_authentification = yes
sender_dependent_relayhost_maps = hash:/etc/postfix/sender_relay
smtpd_sasl_local_domain = $myhostname
smtp_sasl_security_options = noanonymous
smtp_sasl_tls_security_options = noanonymous
smtpd_sasl_application_name = smtpd
smtp_always_send_ehlo = yes
relayhost =
transport_maps = hash:/etc/postfix/transport
smtp_generic_maps = hash:/etc/postfix/generic
disable_dns_lookups = yes
Перезагружаем postfix:
root@pve1:~#/etc/init.d/postfix restartТеперь нужно вернуться в файл настроек рейда и немного его поправить. Указываем кому получать письма счастья и от кого они будут приходить.
root@pve1:~#nano /etc/dmadm/mdadm.confУ меня вот так:
CREATE owner=root group=disk mode=0660 auto=yes
MAILADDR info@domain.ru
MAILFROM pve1@dpmain.ru
ARRAY /dev/md0 metadata=0.90 UUID=4df20dfa:4480524a:f7703943:85f444d5
ARRAY /dev/md1 metadata=0.90 UUID=432e3654:e288eae2:f7703943:85f444d5Перезапускаем mdadm, что бы перечитать настройки:
root@pve1:~#/etc/init.d/mdadm restartПроверяем через консоль тестирование рейда и отправку письма:
root@pve1:~#mdadm --monitor --scan -1 --test --oneshotУ меня пришло два письма с информацией по обоим созданным мною рейдам. Осталось добавить задачу тестирования в крон и убрать ключ –test. Чтобы письма приходили только тогда, когда что-то произошло:
root@pve1:~#crontab -eДобавляем задачу (не забудьте после строки нажать на Enter и перевести курсор вниз, что бы появилась пустая строка):
0 5 * * * mdadm --monitor --scan -1 –oneshotКаждое утро в 5 утра будет производится тестирование и если возникнут проблемы, произойдет отправка почты.
На этом всё. Возможно перемудрил с конфигом postfix – пока пытался добиться нормальной отправки через наш внешний сервер, много чего надобавлял. Буду признателен, если поправите (упростите).
В следующей статье я хочу поделиться опытом переезда виртуальных машин с нашего гипервизора Esxi-6 на этот новый Proxmox. Думаю будет интересно.
UPD.
Стоит отдельно отменить момент с физическим местом на разделе /dev/data – это основной раздел созданный как LVM-Thin
Когда ставился Proxmox, он автоматически разметил /dev/sda с тем учетом, что на /root раздел где хранится система, ISO, дампы и темплеи контейнеров, он выделил 10% емкости от раздела, а именно 100Gb. На оставшемся месте он создал LVM-Thin раздел, который по сути никуда не монтируется (это еще одна тонкость версии >4.2, после перевода дисков в GPT). И как вы понимаете этот раздел стал размером 900Gb. Когда мы подняли RAID10 из 4х дисков по 1Tb – мы получили емкость (с учетом резерва RAID1+0) – 2Tb
Но когда копировали LVM в рейд – копировали его как контейнер, с его размером в 900Gb.
При первом заходе в админку Proxmox внимательный зритель может заметить, что тыкая на раздел local-lvm(pve1) – мы и наблюдаем эти с копейками 800Gb
Так вот что бы расширить LVM-Thin на весь размер в 1,9TB нам потребуется выполнить все одну команду:
lvextend /dev/pve/data -l +100%FREEПосле этого систему не нужно даже перезапускать.
Не нужно делать resize2fs – и это скорее даже невозможно, потому как система начнет ругаться на
root@pve1:~# resize2fs /dev/mapper/pve-data
resize2fs 1.42.12 (29-Aug-2014)
resize2fs: MMP: invalid magic number while trying to open /dev/mapper/pve-data
Couldn't find valid filesystem superblock. И правильно начнет – этот раздел у нас не подмонтирован через fstab
В общем пока я пытался понять, как расширить диск и читал форум Proxmox – система тем временем уже во всю показывала новый размер, как в таблице, так и на шкале.
Поделиться с друзьями
Meklon
Очень подробно, спасибо)
vasyakrg
я сейчас продолжаю настраивать это сервер.
настроил поддержку VLAN для виртуальных машин — оказалось, что по этому вопросу очень мало достоверной информации и она очень противоречива. если будет время, попробую выпустить отдельной заметкой.
так же думаю описать, как у меня с горем пополам получилось переконвертировать несколько разнотипных виртуалок с Esxi6 — думаю тоже кому то, да пригодится.
icCE
а что там такого сложного с vlan?
Уже лет 8 использую bonding,vlan,bridge.
Основная сложность была в момент перехода proxmox на openvswitch, так как в debian свое видение конфигов.
Ну и народ еще забывает при использование HA, что кластер общается по мультикасту :)
vasyakrg
основная сложность была изменить представление настройки, после панели Esxi6. :)
особенно постоянно перезагружать сервер, даже после добавления комментария к интерфейсу.
пробовал по трем разным статьям. ничего не получалось.
пробовал точь в точь с wiki proxmox — не завелось.
в итоге дошел сам.
iface lo inet loopback
iface eth0 inet manual
iface eth1 inet manual
#VLAN 2 Amega
auto eth0.2
iface eth0.2 inet manual
vlan_raw_device eth0
#VLAN 50 DFSK
auto eth0.50
iface eth0.50 inet manual
vlan_raw_device eth0
#VLAN6 IDPhone ADSL
auto eth0.6
iface eth0.6 inet manual
vlan_raw_device eth0
auto vmbr0
iface vmbr0 inet manual
bridge_ports eth0
bridge_stp off
bridge_fd 0
auto vmbr1
iface vmbr1 inet static
address 10.10.10.1
netmask 255.255.255.0
bridge_ports eth1
bridge_stp off
bridge_fd 0
auto vmbr2
iface vmbr2 inet static
address 192.168.1.3
netmask 255.255.255.0
gateway 192.168.1.1
bridge_ports eth0.2
bridge_stp off
bridge_fd 0
icCE
я вот тут писал — http://unixforum.org/index.php?showtopic=136947
Там в конце примеры конфигов, правда они и сейчас наверно требует правок и дополнений.
Просто я еще использую объединение интерфейсов :)
vasyakrg
а объединение в данном случае для чего?
транковые группы?
icCE
bonding используется для отказоустойчивости + увелечение производительности сети (условно)
https://en.wikipedia.org/wiki/Link_aggregation
Пример, есть 4 сетевые карты eth0,1,2,3, делается единый интерфейс bond0, на него уже вешается vlan0,vlan1,vlan2 + n и уже vlan могут быть сбриджеванны с вирт машинами.
Надо понимать только про некий overhead по пакетам и насколько у вас стоят задачи так делать и насколько вам будет так удобно и нужно ли вообще. Я обычно делаю на автомате, если конечно позволяют мощности сети. Везде нужен здравый смысл.
MagicGTS
Я бы сказал, что статья из серии: как перенести установленную linux на soft-raid при наличие свободных дисков и, что она изначально на LVM (масса очепяток в статье). Таких статей много, новизны информации нет. В данной статье, к сожалению, многое описано как «черная магия».
vasyakrg
я был бы очень благодарен, если бы вы подсказали, где именно очепятки.
тогда я бы оперативно их исправил.
раз уж не удивил вас новизной, так хоть уберу банальные ошибки…
MagicGTS
Вариации букв LVM, это основное.
moropsk
вопрос вот такому моменту:
Планируется установить Proxmox на отдельный диск + 2-а массива raid 1 по 4 тб созданные на программном рейде десктопной материнской платы до установки Proxmox
Установленная виртуалка на Proxmox Debian 8 увидит эти массивы?
Их потом можно примонтировать?
vasyakrg
Proxmox — система на ОС debian. Программный и аппаратный рейд он скорее не распознает и будем думать что это один простой диск. Монтировать его в этом случае можно стандартными средствами Debian
mount /dev/sdX /mnt/disk2 и прописать в fstab что бы запускался с загрузкой системы. А в Промоксе добавить этот раздел как папку в разделе Storage.
другой вопрос: если вы на этом разделе будете хранить контейнеры — то лучше изначально создать его как LVM-thin, а потом в промаксе подключить. Можно будет на ходу менять размеры контейнеров.
вот кстати фокус с програмным рейдом из под материнки у меня не вышел с Esxi6 — та просто видела их как отдельные диски. А на форуме у них так и написано — с программными не дружим и не собираемся. покупайте железку. Это одна из причин, почему начал пробовать заморачиваться с Промоксом.
vasyakrg
про видимость массива из виртуалки не понял. проще использовать рейд в самом промоксе, на нем для этой виртуалки «отрезать» с LVM нужный кусок…
MagicGTS
RAID в большинстве десктопный материнок — это так называемый fake-raid. По русски — липовый. По сути это вариация на тему с soft-raid замаскированная под железячную. В linux с ним может работать dmraid (используя подсистемму device mapper) и работает не со всеми контроллерами. Работает это обычно с чудесами в самые неожиданные моменты, и им крайне трудно управлять из ОС. Рекомендую перевести эти диски в обычный mdadm (soft-raid), и управляемость и стабильность выше.
icCE
Я обычно в таком случаи идут немного другим путем, а именно путем debotstrap.
Грузимся, размечаем как надо и ставим всю систему.
Сейчас вполне идут игры с ZFS и использования кеша L2 как на SSD так и на в памяти.
Профит велеколепный! Там же удобно делать raid, снепшоты и не городить огород.
vasyakrg
Вот про это я бы с удовольствием почитал.
Тем более что как раз лежит в резерве SSD64Gb.
попробовал при загрузке в инсталлере выбрать не раздел, а ZFS и собрать из 4х дисков.
ничего не вышло.
На сколько я понял, проблема была UEFI — который этот сервер не поддерживает.
icCE
можно начать вот тут
https://habrahabr.ru/post/272249/
vasyakrg
да, теперь убедился, что у меня проблема была именно в UEFI
сейчас закончу с этим сервером, перенесу на него виртуалки со второго.
а вот на втором, более свежем, как раз два диска — сделаю по вашей инструкции, а заодно поиграю с кэшем.
icCE
на всякий случай, инструкция не моя.
с UEFI ситуацию так же можно вполне разрулить, но я уже насктолько привык все делать скриптами — что уже не использую стандартный установщик. Хотя тут наверно еще привычки с gentoo/archlinux, где по сути нет установщика.
vasyakrg
Возможно пригодится для размышления статья про тестирование ZFS в сравнении с mdadm+vlm от kvaps
PinGniX
Во избежание подобных ситуаций рекомендую посмотреть в сторону tmux,screen и других менеджеров терминалов. Это первое, что я обычно запускаю после входа по ssh на свежий сервер.
vasyakrg
да, именно screen пользуюсь. но в данном случае сервер был в 3 шагах от меня.
winduzoid
Вот официальная документация по установке Proxmox на debian:
https://pve.proxmox.com/wiki/Install_Proxmox_VE_on_Debian_Jessie
И проще, и быстрее.
vasyakrg
ну то есть, поднять debian, поднять на нем RAID10, разметить LVM, потом сверху установить proxmox?
а в чем разница по скорости?
winduzoid
Разница в том, что Debian можно сразу установить на Raid10.
По сути, не придется делать ничего из того, что у вас описано.
Плюс гибкость в установке. Все же это Debian.
vasyakrg
ничего не понял. как так сразу? в смысле создать через Raid10 в процессе установки debian через разметку дисков?
по поводу гибкости — в чем именно? Proxmox основан на дебиане, по сути…
при установке debian много вопросов задает в начале, потом может и проще.
Proxmox — косит под коробку — нажал 3 кнопки и готово. потом вот пришлось такую статью попутно писать, пока настраивал и разбирался.
возможно вы и правы :)
winduzoid
Да. В инсталляторе создать рейд, и поставиться на него. В итоге не будет шаманства с дисками, и шаманства с LVM.
Гибкость в том, что на этапе инсталляции вы вольны разбить диски как вам вздумается. Например, откусить немного места под систему, и поставиться хоть на Raid1 из 4 дисков (имеет смысл, кстати). А оставшееся место использовать под Raid10.
Поставили Debian, накатили Proxmox. Все.
Косит-то он под коробку, жаль, что толку от этого мало. Приходится выбирать между коробочностью и продуктивностью.
icCE
в debian можно создать файл ответа и автоматизировать установку.
В итоге используя tftp, делалась установка по сети. День работы, стойка с proxmox готова без особого напряга.
vasyakrg
думал об этом. из этой статьи можно по сути, сделать файл ответов с несколькими входными данными типа кол-ва винтов, типа рейда и тд.
merlin-vrn
ВООБЩЕ никаких танцев с бубном. Абсолютно. Просто ставишь дебиан как обычно, сверху проксмокс по инструкции.
Так просто проксмокс ставить удобнее, если скрипт автоматизации дебиана есть. Мы его так разворачиваем всегда, даже если аппаратный раид и в принципе пошло бы с проксмоквсового диска — ибо есть нормально сделанный инсталлятор дебиана с сети, и так оно по часам на стене может и больше времени занимает, а если считать время, которое администратор реально копается с системой (а не она сама там скачивается и ставится) — принципиально меньше.
Именно вы, автор, избрали невменяемый путь, хотя рядом есть правильный, простой и надёжный.
vasyakrg
ну если вы прочитали статью до конца, но могли заметить, что статья была не только и не столько про установку промокса как обычно. это скорее моя практика работы с LVM и уведомлениями после установки.
DmitriyPanteleev
Сто раз плюсую. Сам так делал. Просто. Быстро. Надежно.
Никаких «плясок с бубном». Рейд собибирается из визарда при инсталяции дебиана. Потом подключается дополнительная репа и apt update & install. И все! Просто ВСЕ! Ничего больше делать не надо!
vasyakrg
напомните, как в визарде задать размер chunk?
я вот сейчас хочу все это сделать на виртуалке с 4мя винтами.
merlin-vrn
Ну, да, это в гуи никак. В инсталляторе дебиана alt+f2 и делайте раиды руками. Там можно настроить ЧТО УГОДНО.
dmitry_ch
Может тогда ставить именно Proxmox, но на ZFS, что он умеет «из коробки» (прямо кнопкой из диалога выбора диска)?
Pilat
Тут в данной конфигурации может ожидать неожиданность — ZFS требует много памяти, а на данном сервере её и так маловато
icCE
Я бы сказал по другому, у ZFS есть свои подводные камни.
Памяти он не особо требует много, если мы не начинаем заниматся с L2ARC итд.
Хотя если памяти очень много, я бы рекомендовал это сделать + SSD под еще один кеш.
vasyakrg
а можете привести сравнение по памяти?
к примеру, сервер с 32Gb ОЗУ и 6 винтов Х 4Gb
памяти на работу с ZFS уходит 6Gb
что бы грубо представить.
понятное дело, что расходование сильно зависит от проводимых операций…
icCE
все зависит от настроек. Сжатие, дедупликация, пулы и предсказания.
минимально zfs требует 1Gb.
Если памяти мало то vfs.zfs.prefetch_disable=1 – отключение режима prefetch
vfs.zfs.arc_max — сколько будет кешироватся данных в пуле.
Если все по default и почитать гайд http://www.solarisinternals.com/wiki/index.php/ZFS_Best_Practices_Guide
Станет понятно, что zfs старается забрать всю память кроме 1 Gb, но когда она потребуется он ее освободить. Я обычно прибиваю это гвоздями и отдаю не больше 4gb, остальное кеш на ssd.
Кешировать без SSD только в память бесмысленно, при перезагрузки вам надо опять будет прогревать кеш.
vasyakrg
в моем случае не получилось. т.к. сервер не поддерживал UEFI
система попросту не загрузилась после установки.
bARmaleyKA
Ну к чему всё это? В инсталяторе есть же нормальная оснастка для создания программного массива. Jessy поддерживает работу с btrfs, поэтому можно просто создать программный RAID с этой файловой системой без танцев с LVM. Другой момент — эта система для продакшена или дома побаловаться? Если для дома, для души, то понятно. Иначе, почему не аппаратный контроллер и диски SAS. Чтобы там не фантазировали, но аппаратный контроллер будет быстрее программного, так ещё с удобствами диагностики и горячей заменой. Интерфейс SAS полнодуплексный в отличие от полудуплексного SATA и диски быстрей и надёжней.
merlin-vrn
Что касается удобства диагностики, то тут программному равных нет. Вон, amarao любит про это.
А горячая замена есть в SATA уже лет десять.
icCE
про программный и аппаратный RAID уже сломанно много копий. Если задачи относительно простые, то лучше программный.
bARmaleyKA
В программном массиве? Речь до сих пор о нём идёт?
merlin-vrn
Да, про программный. Но вообще горячая смена дисков SATA не имеет прямого отношения к программному RAID — это просто способность AHCI свободно подключать и отключать устройства. Просто эта способность очень пригодилась именно в инсталляциях с программным RAID, и как сухой остаток — в программном массиве уже лет десять как можно менять винты на горячую (т.е., не останавливая ОС и прозрачно для прикладных задач).
Например, если вы когда-нибудь использовали любую Synology DS (даже старшие модели, которые на самом деле представляют из себя стоечные серверы на i3) — там везде внутри именно Linux Software RAID в чистом виде и всё на горячую меняется. Уже давно.
vasyakrg
Остнастка есть. но мне нужен был именно LVM. Система для продакшена, но сервер будет выполнять скорее резервные функции, для экстренного переноса некоторых виртуалок с основного кластера, в случае проблем.
На счет аппаратного, скажу честно, сам не сравнивал, но тут на хабре есть ряд статей, которые, в целом, говорят о 6-8% прироста скорости по сравнению с программным. Опять же, у нас есть сервера разношерстные и, как минимум, узким местом становится сам железный контроллер. В программном, я могу в любом момент развернуть новый дебиан и восстановить массив. А в случае с железным — нужно держать ЗИП на каждый такой сервер.
да и не хотелось на этот сервер докупать что-то дополнительно.
icCE
>А в случае с железным — нужно держать ЗИП на каждый такой сервер.
Мне кажется нужно держать Backup, не? :)
Хотя в общем мысль конечно ясно.
vasyakrg
Бакап конечно есть, но хотелось бы заменить винт и включить сервер, нежели переливать пару терров. В общем то я и задался такими вот экспериментами, чтобы бакапы отодвинуть как последнюю инстанцию
merlin-vrn
Нет, неверно. Бекап предназначен для резерва на случай человеческого фактора, и не предназначен для резервирования на случай аппаратных сбоев.
Вот ЗИП (холодный резерв) — хорошая идея на этот случай. Лучше — только дублирующий сервер, который постоянно получает копию и может в считанные мгновения завести виртуалки в случае сбоя (горячий резерв).
bARmaleyKA
В своё время также проникся софтовыми массивами на статьях с хабра. Хорошие и познавательные статьи. Только прирост 6-8% для дисковой подсистемы уже не мало. Но под хорошей нагрузкой программный сливает намного больше 8%. Просто задайте себе вопрос, что будет лучше работать специализированная железка или программная эмуляция? Вы бы что предпочли лично встроенную графическую карточку или дискретную видеокарту для обработки «тяжёлого» видеопотока? Ведь по той логике софтовый/программный контроллер дисков, встроенная видеокарточка будет немногим хуже, где-то на 6-8%.
Про ЗИП из контроллеров совсем не понял. Получается, что это вроде расходника, который надо периодически менять? Обычно диски раньше помирают чем контроллер. Как это бы не блок питания в нем нет переходных процессов при выключении/включении. Греться там особо нечему, подвижных частей замечено не было. Довольно надёжный узел, понятное дело что речь не идёт о дешёвых fake-контроллерах за 500 рэ. Оно вон бывает помирает материнка на сервере, но ещё не встречал в прозапасе материнок к серверам.
kvazimoda24
А почему у RAID'а chunk всего 2 килобайта? Сейчас же новые диски идут с секторами по 4 килобайта, соответственно, с меньшим chunk'ом можно здорово потерять в скорости.
vasyakrg
а вот это попробую протестировать на лаб-сервере… отличный вопрос!
kvazimoda24
Ещё и разметка диска не выравнена по секторам. Первый раздел начинается с первого килобайта. В общем, какая-то дикая разметка диска…
vasyakrg
Подскажите, как сделать правильно? У меня второй сервер на очереди. За одно и тут поправлю.
icCE
man parted
-a alignment-type, --align alignment-type
Set alignment for newly created partitions, valid alignment types are:
none Use the minimum alignment allowed by the disk type.
cylinder
Align partitions to cylinders.
minimal
Use minimum alignment as given by the disk topology information. This and the opt value will
use layout information provided by the disk to align the logical partition table addresses to
actual physical blocks on the disks. The min value is the minimum aligment needed to align
the partition properly to physical blocks, which avoids performance degradation.
optimal
Use optimum alignment as given by the disk topology information. This aligns to a multiple of
the physical block size in a way that guarantees optimal performance.
kvazimoda24
Первый раздел обычно начинает с 2048 сектора, это если сектора программа считает по 512 байт. Получается, что раздел начинает со второго мегабайта. Размер раздела должен быть кратен четырём килобайтам, следующие разделы так же должны быть сразу после предыдущего, либо пропуск должен быть кратен четырём килобайтам. Если короче, то каждый раздел должен начинаться с позиции на диске, кратной четырём килобайтам.
В самой файловой системе использовать размер кластера так же кратным четырём килобайтам. И размер чанка у рейда установить кратным четырём килобайтам. Обычно, его и ставят размером 4096 байт.
vasyakrg
Нашел неплохую статью (@dmbarsukov), по поводу смены чанка на действующей системе. И в этой же статье ссылка на отличную таблицу, которая я думаю многим пригодится.
К сожалению на этом сервере уже не смогу поиграть. А вот на лабораторном думаю смогу поднять текущую конфигурацию и применить эту статью по подбору верного решения.
kvazimoda24
Ну, если учитывать, что по умолчанию mdadm использует размер чанка в 64К, а то и в 512К, то не совсем понимаю, зачем надо было ставить такой маленький размер. Для какой цели? Зачем его вообще было вручную задавать? Какую цель преследовали?
vasyakrg
вот этот момент я упустил и с чего-то взял, что делает он по 1024, вот и задал по 2048.
считаю должным поправить этот момент в статье.
merlin-vrn
Да можно переделать, можно. У вас очень гибкая структура, которая переживёт такую переделку без останова сервисов (но, конечно, на период миграции диски будут притормаживать).
vasyakrg
сейчас на другом сервере два винта по 930Гб (vmware) собрал в рейд-1 стандартными средствами.
chunk при этом там равен 65536 KB
что я полагаю, тоже не совсем верно?
merlin-vrn
чанк раида 64 метра? Вы что-то неправильно поняли. Это скорее чанк VMFS5, а не массива
vasyakrg
да, возможно…
/dev/md0:
Version: 0.90
Creation Time: Wed Nov 16 09:22:51 2016
Raid Level: raid1
Array Size: 964688768 (920.00 GiB 987.84 GB)
Used Dev Size: 964688768 (920.00 GiB 987.84 GB)
Raid Devices: 2
Total Devices: 2
Preferred Minor: 0
Persistence: Superblock is persistent
Intent Bitmap: Internal
Update Time: Wed Nov 16 15:38:08 2016
State: clean
Active Devices: 2
Working Devices: 2
Failed Devices: 0
Spare Devices: 0
UUID: b32c8257:dc8594a5:e5bd13ee:9370e590 (local to host webmail)
Events: 0.3038
Number Major Minor RaidDevice State
0 8 17 0 active sync /dev/sdb1
1 8 49 1 active sync /dev/sdd1
root@webmail:~# cat /proc/mdstat
Personalities: [raid1]
md0: active raid1 sdd1[1] sdb1[0]
964688768 blocks [2/2] [UU]
bitmap: 0/8 pages [0KB], 65536KB chunk
unused devices:
merlin-vrn
Это не чанк раида, а встроенного write-intent bitmap. Читайте ман, что там искать, я написал.
Размер, блока которыми оперируют RAID-ы, обычно называют полосой (stripe). Да и вообще, для RAID1 подобный параметр не имеет смысла, поэтому и не указывается в --detail и тому подобное.