Raid0 + LVM + XFS разметка диска и прочее

Может что посоветуете?

raid 10

Подтянуть пунктуацию. Тебя трудно дешифровывать.

raid 10 не решает проблемы отката в течении недели на версию. И диски ведь разного размера - как будет использоваться пространство не очень понятно.

Raid0 для бэкапов это сильно. Особенно на hdd.

С точки зрения надежности в целом интересная идея. Спасибо подумаю. Я так понимаю схема такая: первый пул SSD1 в зеркало с разделом HDD1, SSD2 в зеркало с разделом HDD2 и два этих пула в страйп. А оставшееся место как угодно.

Не будет ли тупить все это дело из-за разности в скорости дисков ? не получится ли вся система по скорости страйпа из HDD ?

А что вам не нравится ? вероятность выхода одновременно двух дисков - одного ссд и одного hdd - нулевая. И если рассыпится бекап можно спокойно заменить диск и сделать новый. Что не так то ?

'/boot' cannot be on a xfs filesystem!

Эм...

$ df -hT /boot/
Filesystem     Type  Size  Used Avail Use% Mounted on
/dev/sda2      xfs   497M  249M  248M  51% /boot

Я бы выкинул raid0, и оставил только lvm. Разделы lvm можно размазать на два диска для скорости.

mdadm, lvm — зачем, если все это лучше делает btrfs?

хороший вопрос, но вроде как не продакшн реди ...

Еще нашел такие рекомендации ## - '/boot' cannot be on a xfs filesystem!

В RHEL7 и CentOS7 xfs работает отлично (у меня на 5 серверах). Рекомендую однозначно. В debian 8 есть нюанс - надо загрузиться в режиме восстановления с другого носителя и сделать update-initramfs.

1) Оптимально ли использовать LVM для бекапов, интересуют инкрементные.

вариант нормальный, но не для всех

Можно ли заменить Raid0 на LVM именно для скорости?

Сомневаюсь, что скорость будет в пользу LVM, потому что на LVM тратится место диска, то есть писать надо немного больше.

хотя фэйсбук вроде использует, надо посмотреть, спасибо за наводку.

а зачем raid0 при наличии LVM?

не готово оно

andrew667 спасибо большое. Я так понимаю заморачиваться с разными разделами под Ext4 нет смысла ? на веб сервере куча мелких файлов.

ну вот andrew667 говорит что по идеи LVM в качестве raid0 медленнее будет.

а, да, возможно, не подумал.

оно урежет i/o до скорости hdd. Возьми еще два таких ssd и вперед. Hdd можно юзать для бекапов (сделать из них зеракало)

Особого смысла в ext4 в твоем случае не вижу. Я бы твой сервер улучшил в плане надежности и рациональности использования SSD. Разбей каждый hdd на два раздела (50 гиг и все остальное). Собери из первого раздела каждого hdd raid1 и на него установи систему, используя его под /. Так ты обеспечишь себе возможность загрузиться в случае выхода из строя диска. Оставшееся место на hdd можешь объединить через lvm или raid0 и использовать для бэкапов. Из SSD собирай raid0 или объединяй через LVM c размазыванием и монтируй под БД, виртуалки и др. SSD не размечай более, чем на 80% для продления ресурса. Чтобы сервер не тупил во время бэкапов лучше посадить ssd и hdd на разные контроллеры.

Да, очень интересная схема, весьма признателен, такой расклад мне в голову не приходил :)

Для некритичных задач (например хранение бэкапов, в данном случае) уже можно использовать.

Я периодически тестил btrfs, и в этом году перетащил на нее свой NAS для бэкапов.

Никаких проблем (постукиваю по чайнику) пока не было, и гораздо удобнее в использовании чем связка mdadm+lvm.

это называется разделением данных

P.S. Несмотря на то, что хочешь скорости, лучше бэкапы хранить в raid1.

Вероятность, может, и околонулевая, но закон подлости никто не отменял.

ну если брать во внимание этот закон то и одного сервера и одного хостера да и лучше вообще еще и в разных галактиках забекапиться :) Учту, спасибо за совет.

Верю, что удобнее. На каком ядре используешь?

На компе который NAS стоит обычная ubuntu 14.04, соотв. ядро 3.13.

Но и на 4.1(debian testing) с btrfs(правда без raid) все норм.

Oracle обьявил btrfs production ready еще в 2012-м году, хотя не стоить ему верить, лучше для своего случая предварительно все протестировать.

ядро 3.13.

юморист. Это читал?

Ну ясно: «The Btrfs code base is under heavy development.»

В багзилле куча не закрытых багов.

Хотя их много и у ext4, и значительно меньше у xfs — вероятно пропорционально количеству изменений в коде.

Идеальных программ нет:

Для некритичных задач (например хранение бэкапов, в данном случае) уже можно использовать.

Конечно, можно. На последнем доступном ядре ))) Там это прямым текстом сказано.

потому что на LVM тратится место диска, то есть писать надо немного больше.

Ну-ка, ну-ка подробнее с этого места.

lvm сам умеет raid0, raid1, raid4/5/6, raid10

к тому же эти рейды можно выбирать отдельно для каждого lv

Например / сделать raid1 на двух ssd, /tmp — raid0 на двух hdd и т.д.

Зато если диск вылетит из LVM-рейда, LVS даже не сообразит что массив уже degraded и ничего не сделает.

По-крайней мере еще в феврале так было.

даже не сообразит что массив уже degraded и ничего не сделает.

А mdraid что сделает? Пришлет тебе sms?

Мониторить здоровье дисков надо в любом случае.

Я вот что имел в виду:

For example, in Debian Wheezy, lvs can't tell you RAID5 sync status. I very much doubt repair and recovery (especially from «that should never happen!» situations) is anywhere near as good as mdadm (and I accidentally ran into one of those in my testing, and finally just gave up on recovering it—recovery with mdadm would have been easy).

Возможно сейчас такой проблемы нет, не в курсе.

For example, in Debian Wheezy,

oldstable, извини, дальше не читал

Ну-ка, ну-ка подробнее с этого места.

[root@server1 ~]# fdisk -l
...
Disk /dev/vdb: 1048 MB, 1048576000 bytes, 2048000 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/vdc: 1048 MB, 1048576000 bytes, 2048000 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

[root@server1 ~]# fdisk /dev/vdb
Welcome to fdisk (util-linux 2.23.2).

Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

Device does not contain a recognized partition table
Building a new DOS disklabel with disk identifier 0x39df4c64.

Command (m for help): n
Partition type:
   p   primary (0 primary, 0 extended, 4 free)
   e   extended
Select (default p): p
Partition number (1-4, default 1): 1
First sector (2048-2047999, default 2048): 
Using default value 2048
Last sector, +sectors or +size{K,M,G} (2048-2047999, default 2047999): 
Using default value 2047999
Partition 1 of type Linux and of size 999 MiB is set

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.
Syncing disks.

[root@server1 ~]# mkfs.xfs /dev/vdb1
meta-data=/dev/vdb1              isize=256    agcount=4, agsize=63936 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=0        finobt=0
data     =                       bsize=4096   blocks=255744, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0 ftype=0
log      =internal log           bsize=4096   blocks=853, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
[root@server1 ~]# mkdir /1
[root@server1 ~]# mount /dev/vdb1 /1

[root@server1 ~]# fdisk /dev/vdc
Welcome to fdisk (util-linux 2.23.2).

Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

Device does not contain a recognized partition table
Building a new DOS disklabel with disk identifier 0x6bd0a47f.

Command (m for help): n
Partition type:
   p   primary (0 primary, 0 extended, 4 free)
   e   extended
Select (default p): p
Partition number (1-4, default 1): 
First sector (2048-2047999, default 2048): 
Using default value 2048
Last sector, +sectors or +size{K,M,G} (2048-2047999, default 2047999): 
Using default value 2047999
Partition 1 of type Linux and of size 999 MiB is set

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.
Syncing disks.
[root@server1 ~]# pvcreate /dev/vdc1
  Physical volume "/dev/vdc1" successfully created
[root@server1 ~]# vgcreate VG1 /dev/vdc1
  Volume group "VG1" successfully created

[root@server1 ~]# lvcreate -n LV1 -l 100%FREE VG1
  Logical volume "LV1" created.
[root@server1 ~]# mkfs.xfs /dev/VG1/LV1 
meta-data=/dev/VG1/LV1           isize=256    agcount=4, agsize=63744 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=0        finobt=0
data     =                       bsize=4096   blocks=254976, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0 ftype=0
log      =internal log           bsize=4096   blocks=853, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
[root@server1 ~]# mkdir /2
[root@server1 ~]# mount /dev/VG1/LV1 /2

[root@server1 ~]# df 
Filesystem          1K-blocks    Used Available Use% Mounted on
/dev/vda1            15036416 3831600  11204816  26% /
devtmpfs               757752       0    757752   0% /dev
tmpfs                  766652     184    766468   1% /dev/shm
tmpfs                  766652    8972    757680   2% /run
tmpfs                  766652       0    766652   0% /sys/fs/cgroup
/dev/sr0              3798292 3798292         0 100% /run/media/andrew667/RHEL-7.1 Server.x86_64
/dev/vdb1             1019564   32928    986636   4% /1
/dev/mapper/VG1-LV1   1016492   32928    983564   4% /2

1019564 < 1016492

И?

раскрой смысл фразы

Сомневаюсь, что скорость будет в пользу LVM, потому что на LVM тратится место диска, то есть писать надо немного больше.

скорость ... писать надо немного больше

1019564 < 1016492

Разница пределах 4М — дефолтный размер PE — округление/выравнивание

Зря простынь постил. Try harder!

Разница пределах 4М — дефолтный размер PE — округление/выравнивание

Неужели? Платишь за LVM местом и производительностью. Для того чтобы записать один и тот же объем данных без LVM по сравнению с LVM, требуется меньше операций с диском и ЦПУ. Бесплатный только сыр в мышеловке.

Платишь за LVM местом и производительностью

На каждый байт без LVM ты сколько заплатишь байт на lvm? Уже задаю вопросы как для дебила.

Пожалуйста без шуток-прибауток и поговорок.

pvcreate резервирует место для информации о структуре lvm.

Но ты говоришь о постоянном оверхеде по занимаемому месту, при каждой операции. Это ложь!

Есть оверхед по трансляции LE в PE и в блоки на диске, но это не превышает тысячной доли процента CPU

Оправдывайся!

На каждый байт без LVM ты сколько заплатишь байт на lvm?

Ты реально настолько «одаренный», что выполнить элементарные арифметические операции над двумя представленными тебе числами можешь? Как все запущено... И размер этот в байтах зависит от размера экстента.

Но ты говоришь о постоянном оверхеде по занимаемому месту

Значит при одной операции оверхед есть, а при другой его отменил А.С. Пушкин... Место у тебя забрали на экстент, и никто его не отдаст.

Затем, что btfs - мать его файловая система.

Ты бредить иди вместе с Андрюшей. Без пруфов не приходите. То что он простыню накатал, ничего не значит — от слова абсолютно — там ляп на ляпе.

Да ты еще тупее чем я думал.

Ты хоть сам понял результаты performance test'a? Скоректируй PIII=500MhZ на современные CPU.

И где overhead по МЕСТУ на каждую операцию записи, о котором вещал Андрюша: «то есть писать надо немного больше» ???

Ты, видимо, тот самый школотун, который уже сегодня перед мной извинялся за тупизну.

Где тут raid0?

кто в лес кто по дрова. LVM стрип действительно медленее чем mdadm raid0 в сети есть тесты, причем сильно зависит от размера файла, местами значительно, местами нет.

Вообще изначально думал использовать LVM ради снапшотов. Наткнулся на обсуждения где приводятся примеры когда диск диградирует не только во время снапшотов, но и в промежутках пока не удалишь их.

Серьезно задумался нужно ли оно мне вообще ? Как лучше бекапиться ? Tar + dump ?

Не ленись, посмотри о чем речь в том комменте.

В том комментарии идет речь о замене raid0 на lvm

Ты так и не ответил за свою ложь. Трата 1Мб на весь PV (статическая, одноразовая трата) — ничтожна и никак не влияет на скорость. Где постоянная трата места при записи? Ступил, так признайся и проехали.

В том комментарии идет речь о замене raid0 на lvm

приехали...

LVM ради снапшотов
диск диградирует не только во время снапшотов, но и в промежутках пока не удалишь их.

причиной тому COW когда происходит перезапись данных и вытеснение старых данных в тело снапшота

/dev/vdb1

а какой смысл на дисках(даже настоящих) разделы лепить если они не под систему, а для фс с данными?