LINUX.ORG.RU
ФорумAdmin

mdraid 1 + writeback SSD Cache. Отказ SSD.

 , , ,


0

2

Добрый день.

Лирика:

Руководству хочется быстро, безотказно и бесплатно. На desktop'ный ПК установлен proxmox 6. Кое-как крутится 3-4 VM. Есть идея фикс - прикрутить ssd cache в режиме writeback, чтоб крутились пошустрее.

Голос в моей голове шепчет: «У тебя VM в виде qcow. Если сдохнет твой ssd - считай рубанут по питанию. Велика беда.»

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

  
--- Logical volume ---
  LV Path                /dev/pve/VM_FAST
  LV Name                VM_FAST
  VG Name                pve
  LV UUID                ahdNjT-xInn-ayAG-ee8t-0GSZ-n6dM-LHgJHk
  LV Write Access        read/write
  LV Creation host, time pve, 2021-07-13 18:22:35 +0300
  LV Cache pool name     cache
  LV Cache origin name   VM_FAST_corig
  LV Status              NOT available
  LV Size                437.72 GiB
  Current LE             112057
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
Вроде бы всё логично: отцеплю кэш и заживём... Но не тут то было. Если и meta и cache живут на ssd, то lvconvert --uncache /dev/pve/VM_FAST --force -y идёт в сплошной отказ. Совет с serverfault по подсовыванию в VG диска с таким же UUID не спасает. В режиме meta на hdd, cache на ssd - зависает следующим образом:
  Unknown feature in status: 8 2775/262144 512 62875/915728 8651 1539 1966 22479 0 0 45 3 metadata2 writethrough no_discard_passdown 2 migration_threshold 2048 cleaner 0 rw - 
  Flushing 45 blocks for cache pve/VM_FAST.
  Unknown feature in status: 8 2775/262144 512 62875/915728 8651 1539 1966 22479 0 0 45 3 metadata2 writethrough no_discard_passdown 2 migration_threshold 2048 cleaner 0 rw - 
  Flushing 45 blocks for cache pve/VM_FAST.

Конфигурация:

  • Debian Buster (proxmox 6)
  • i3 8100, 16Gb
  • 2хHDD => mdadm raid 1 => LVM
  • 1xSSD
  lsblk
  NAME                        MAJ:MIN RM   SIZE RO TYPE  
  MOUNTPOINT
  sda                           8:0    0   1.8T  0 disk  
  └─sda1                        8:1    0   1.8T  0 part  
    └─md0                       9:0    0   1.8T  0 raid1 
      ├─pve-swap              253:0    0    16G  0 lvm   [SWAP]
      ├─pve-root              253:1    0    96G  0 lvm   /
      ├─pve-VM                253:2    0   1.2T  0 lvm   /VM
      ├─pve-cache_cmeta       253:5    0     1G  0 lvm   
      │ └─pve-VM_FAST         253:7    0 437.7G  0 lvm   
      └─pve-VM_FAST_corig     253:6    0 437.7G  0 lvm   
        └─pve-VM_FAST         253:7    0 437.7G  0 lvm   
  sdb                           8:16   0   1.8T  0 disk  
  └─sdb1                        8:17   0   1.8T  0 part  
    └─md0                       9:0    0   1.8T  0 raid1 
      ├─pve-swap              253:0    0    16G  0 lvm   [SWAP]
      ├─pve-root              253:1    0    96G  0 lvm   /
      ├─pve-VM                253:2    0   1.2T  0 lvm   /VM
      ├─pve-cache_cmeta       253:5    0     1G  0 lvm   
      │ └─pve-VM_FAST         253:7    0 437.7G  0 lvm   
      └─pve-VM_FAST_corig     253:6    0 437.7G  0 lvm   
        └─pve-VM_FAST         253:7    0 437.7G  0 lvm   
  pve-cache_cdata-missing_0_0 253:3    0 223.6G  0 lvm   
  └─pve-cache_cdata           253:4    0 223.6G  0 lvm   
    └─pve-VM_FAST             253:7    0 437.7G  0 lvm 

Суть вопроса:

Есть ли рабочий способ отделить writeback lvmcache или получить доступ к данным, в случае потери носителя.



Последнее исправление: SKIF-1 (всего исправлений: 5)

выкинуть LVM
заюзать ZFS

Minona ★★☆
()

ССД с конденсатором, если нет, то забудь и про lvm кэш и про zfs

jewelry
()
  1. Память с ECC

  2. SSD с защитой от сбоев по питанию

  3. zfs l2arc и cache разделами. - Почитай, там оно даже вроде как научилось кеш сохранять после reboot.

Сама виртуалка на zfs с настройками по умолчанию.

DALDON ★★★★★
()
Ответ на: комментарий от DALDON

Ах да, ещё и mdadm максимум только для системы юзать.

DALDON ★★★★★
()

ssd кэш делай из зеркала двух дисков

anonymous
()

возьми хотя бы hp gen8 в самой дешёвой комплектации, с хардварным кэшем и конденсатором, уложишься в сотку килорублей, за то получишь отказоустойчивую железку для своего proxmox.

не пытайся софтварным путём изобрести всё то, что уже давно изобрели до тебя хардварно, что уже работает у людей десятилетиями.

Spoofing ★★★★★
()
Ответ на: комментарий от Spoofing

Да дохнут они точно так же красиво. У меня конечно выборка идет на тысячи серверов, но вот привезли допустим 40 штук DL360 Gen10 - обязательно 1-2 будет полумертвых искаропки. То проц битый, то сторадж. А потом еще штук пять в течение месяца отсыпаются.

pekmop1024 ★★★★★
()
Ответ на: комментарий от pekmop1024

Смысл пролайантов не в неубиваемости (обычное железо, тащемта), а в гарантийном обслуживании, когда в течение часов или дней в любой Мухосранск приедет человечек в футболке HPE и всё сам сделает, ибо гарантия и сервис.

pekmop1024 ★★★★★
()
Ответ на: комментарий от pekmop1024

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

чаще всего отваливается чип NAND, пишет iLO Degraded, когда тот переходит в read-only режим. тоже отдаём в ремонт такое.

а в остальном, сколько я работаю, жалобы если и были, то на комплектующие, а чтобы вот так сам по себе сервер сдох — ну NAND отвалится. в остальном неубиваемая тачка. =)

Spoofing ★★★★★
()
Ответ на: комментарий от pekmop1024

ну это хорошо когда контора может себе такое позволить, работать напрямую с HP по подписке. не все такие же)

Spoofing ★★★★★
()
Ответ на: комментарий от Spoofing

чтобы вот так сам по себе сервер сдох

Материнки дохнут только в путь. А бывает вообще барабашка в сервер заводится, поменяют в нем все комплектующие, кроме корпуса, а он виснет к чертям раз в неделю. Такие меняют целиком.

pekmop1024 ★★★★★
()
Ответ на: комментарий от Spoofing

iLO Degraded, когда тот переходит в read-only режим

Такое в 50% случаев лечится накатыванием свежих прошивок с помощью SPP.

pekmop1024 ★★★★★
()
Ответ на: комментарий от pekmop1024

не соглашусь, беру любой сервак с проблемным нандом, накатываю свежую 2.78 и... нифига. накатываю ещё раз и... нифига. ничего ты с этим не сделаешь. а если сделаешь, то всё равно отвалится скоро. надо в ремонт.

Spoofing ★★★★★
()
Ответ на: комментарий от Spoofing

возьми хотя бы hp gen8 Ты щас насоветуешь, специались my ass. Это вообще не сервер, это маркетинговая чешуя от hp.

anonymous
()
Ответ на: комментарий от Spoofing

накатываю свежую 2.78 и… нифига. накатываю ещё раз и… нифига

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

pekmop1024 ★★★★★
()
Ответ на: комментарий от pekmop1024

Чувачок, я рулю сотнями hp proliant 580 и я те ответственно заявляю, что микросерверы от hp - подзплупная перхоть.

anonymous
()
Ответ на: комментарий от pekmop1024

А бывает вообще барабашка в сервер заводится, поменяют в нем все комплектующие, кроме корпуса, а он виснет к чертям раз в неделю.

Никакой барабашки. Попробую предположить, что меняют на железо из той же партии.

anc ★★★★★
()

Потерю writeback кэша в LVM можно приравнять к потере данных. В вашем случае можно попытаться сделать mirror из двух SSD и поставить его кэшем перед LVM.

Nastishka ★★★★★
()
Ответ на: комментарий от Spoofing

а в остальном, сколько я работаю

это сколько, два месяца уже?

t184256 ★★★★★
()
Ответ на: комментарий от anc

Кто же их знает, может и из той же, только мы серверы единомоментно партиями закупаем, и когда такое случается с одним из нескольких десятков партии, дело явно не в этом. А в чем, нмкому не понятно. Лично я делаю ставку на брак шасси в части заземления, но эту теорию никто не проверял - проще по гарантии всю железку заменить

pekmop1024 ★★★★★
()
Ответ на: комментарий от Nastishka

Печалит то, что это не потеря того, что осталось в кэше и не успело записаться (это можно было бы пережить), а полная потеря раздела со всей информацией. Интересовало, есть ли экспериментально проверенный способ вытащить информацию с раздела, после отвала кэша.

SKIF-1
() автор топика
Ответ на: комментарий от DALDON

«Сервер», как было написано выше - десктопное ведро. Вся начинка потребительская.

ZFS краем глаза смотрел. Ощущения таковы, что относительно mdadm + lvm дико прожорлива до памяти. Да и в общем случае (не относящемся к посту) mdadm + lvm можно поковырять каким-нибудь testdisk’ом, а что делать в случае краша zfs - понятия не имею (разве что только backup).

SKIF-1
() автор топика
Ответ на: комментарий от t184256

Хотелось ускорить чтение и запись с использованием энергонезависимого носителя. Увы, рассчитывать на то, что ssd перейдёт в read only а не отвалится с концами по той или иной причине я не могу. Эксперименты показали, что в такой ситуации всё плохо.

SKIF-1
() автор топика
Ответ на: комментарий от SKIF-1

Ну с такой вводной либо ускорить только чтение, либо забить.

t184256 ★★★★★
()
Ответ на: комментарий от SKIF-1

Тривиально. Такой кэширующий том состоит из кэш-волюма над базовым волюмлм. С помощью dmsetup можете посмотреть. Соответственно просто берёте и читаете из базового слоя через /dev/dm-***, конкретно нужное устройство в выводе dmsetup найдёте

Nastishka ★★★★★
()
Ответ на: комментарий от SKIF-1

ZFS ... дико прожорлива до памяти

Не совсем так, само оно ест не так много, но сколько дашь - столько и сожрёт.
Память эта идёт на пользу, так что жалеть её не надо )

GAMer ★★★★★
()
Ответ на: комментарий от Nastishka

То ли лыжи не едут…

#lvchange -ay –partial /dev/pve/VM_FAST
PARTIAL MODE. Incomplete logical volumes will be processed. Couldn’t find device with uuid ZEt2Uz-qmxD-sFbo-7UVn-l8ik-cl7i-HeSRR8. /dev/mapper/pve-cache_data_cmeta: read failed: Input/output error

#lvs -a
Couldn’t find device with uuid ZEt2Uz-qmxD-sFbo-7UVn-l8ik-cl7i-HeSRR8. LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert VM pve -wi-ao—- <1.22t
VM_FAST pve Cwi—C-p- 437.72g [cache_data] [VM_FAST_corig]
[VM_FAST_corig] pve owi—C— 437.72g
[cache_data] pve Cwi—C-p- <102.92g
[cache_data_cdata] pve Cwi—–p- <102.92g
[cache_data_cmeta] pve ewi—–p- 8.87g
[lvol0_pmspare] pve ewi——- 8.87g
root pve -wi-ao—- 96.00g
swap pve -wi-ao—- 16.00g

# dmsetup ls
pve-VM  (253:2)
pve-swap        (253:0)
pve-root        (253:1)

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

SKIF-1
() автор топика

LVM Cache и в нормальных работает херово, 2/10, не рекомендую.

izzholtik ★★★
()
Ответ на: комментарий от Nastishka

Как я уже писал в стартовом сообщении темы:

Совет с serverfault по подсовыванию в VG диска с таким же UUID не спасает.

SKIF-1
() автор топика

А сброс в swap если диск медленный можно настроить?

nanosecond
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.