Прошу прощения за некропост, но, попадал в свое время в абсолютно аналогичную ситуацию. Только контроллер на замену не удалось найти совсем.
Решилось сборкой массива вручную при помощи ПО для восстановления данных. И, слава богам, встроенный кэш работал в режиме write-through.
С тех пор я аппаратные RAID контроллеры не использую в своих проектах совсем. Как и встроенные в материнскую плату. И то, и то — точка отказа. Только программные массивы.
Даже все имеющиеся LSI SAS RAID контроллеры в SAS HBA ( Initiator/Target режим) перепрошил.
Универсального решения там нет. Что делать в случае, если закончились деньги — для каждого сервиса, — сугубо индивидуально. И, даже более того, не всегда возможно. И, даже не всем нужно.
Нужно такое, в основном мелкому бизнесу и частным лицам, для которых 20к долларов — это деньги. А крупные облака все больше по крупным клиентам работают. Для них все как вы сказали. Проще заплатить.
Потому и сделал я акцент, в основном, именно на то, что, в первую очередь нет инициативы сделать. Технические сложности есть, но они вторичны.
Если бы у облаков был интерес в сознании правильного лимитирования, то можно было бы сделать так:
Допустим, задержка биллинга — 3 часа. От лимита осталось 100 долларов. Можно посчитать сколько запросов укладывается в лимит. Допустим, это 100000 запросов.
В сервисе можно поставить ограничение — не больше 100000 запросов. И, по достижении блокировать запросы. При этом, периодически этот лимит можно обновлять по мере того, как биллинг подтягивается и обновляется.
Есть же виртуализация. На голое железо можно поставить гипервизор, а этот замечательный Pluton эмулировать сохраняя ключи где душе угодно. Через IOMMU на виртуальную машину пробрасывается вся периферия (сетевые контроллеры/usb контроллеры/GPU/NVM-E), и, при желании, там можно делать что угодно.
Я могу порекомендовать трюк с пробросом сетевых адаптеров ноутбука в виртуальную машину. На этой виртуальной машине настраивается «маршрутизатор», который и занимается всей чехардой с маршрутизацией определенных IP куда надо. А сам хост выходит в сеть через этот самый «маршрутизатор».
Как пользователь btrfs со стажем чуть больше года хочу сказать, что от dd if=/dev/zero of=/dev/sda спасает регулярный send/recieve снапшота на устройство для резервных копий. Тем более, оно позволяет перемещать «разницу» между двумя снимками, что очень запросто можно использовать для инкрементального быстрого бэкапа на внешнее устройство.
Ну наверно можно, только тогда теряется смысл ключей директора в принципе. Смысл как раз в том, чтобы делать это единожды, при выдаче ключа, а не каждый раз.
А то, это выглядит как-то странно. Представьте, вы пришли в банк и просите снять все деньги со счета юр-лица наличкой. При этом, вы показываете паспорт, заверенную копию устава другого юр-лица, где вы числитесь директором, и, говорите, «Ну, я еще и директор и этого юр-лица тоже, но заверенного документа показать не могу, но деньги все равно давайте. Можете проверить по базе.» Так вот… скорее всего вас пошлют. Просто потому, что проверять по базе, — не их обязанность.
Сертификат, директора, это не только подтверждение личности, но и подтверждение полномочий.
Личный сертификат или сертификат директора другой компании может подтвердить только личность. Полномочия не может.
Думаю, что пока нет, разве что какие-то внутренние инструменты. Но, думаю что через пару лет появятся. Рано или поздно кому-то да надоест поддерживать и то, и то.
Могу еще порекомендовать настроить мониторинг на уровень износа и по-достижении определенного % износа заменять один из дисков.
В случае зеркала из 2хNVME по достижении 60% износа один из накопителей заменяется на новый. Далее накопители ротируются соблюдая правило, что минимум один из накопителей должен всегда иметь износ меньше 60%, когда как другой может быть любой. Ранее извлеченные накопители с >60% можно потом доносить, когда сдохнет тот, который остался в массиве.
Возможны другие схемы ротации.
Добавлю еще к вышесказанному, что у вас сами накопители явно являются узким местом. У них слишком высокие задержки, и очень плохое случайное чтение в 1 поток. Вот такие данные я получаю при использовании Linux Soft RAID1 из 2хSamsung SSD 970 EVO 500GB: fio --name=test --blocksize=4k --direct=1 --buffered=0 --ioengine=libaio --iodepth=1 --loops=1000 --runtime=300 --rw=write --filename=/dev/vg_root/test
write: IOPS=36.8k, BW=144MiB/s (151MB/s)(42.1GiB/300000msec)
| 99.00th=[ 31], 99.50th=[ 37], 99.90th=[ 51], 99.95th=[ 60],
Неплохо!
Выводы коротко:
Для RAID0 рулит Linux Soft RAID;
Для RAID1 рулит VROC;
LSI отстает везде.
Но, только для 4k random R/W.
Дополнительно добавлю, что грузиться с NVM-E вообще и NVM-E Linux Soft RAID в частности можно в Legacy/BIOS режиме, причем, даже на очень старом железе, где BIOS знать не знает, что такое NVM-E. Главное чтобы загрузчик (GRUB) знал, а его можно записать на SATA диск или массив из них, как, например, это сделано тут: habr.com/ru/post/492834
Это все хорошо, вот только "последовательная запись на пустой диск" слишком слабо нагружает контроллер. Гораздо слабее, чем случайная, и, на порядки слабее чем на занятый диск. Да, и в реальной практике обычных пользователей встречается гораздо реже чем случайная запись на диск заполненный.
Вывод из написанного: Существуют сценарии использования в которых перечисленным накопителям Kingston радиаторы не требуются. OK.
Решилось сборкой массива вручную при помощи ПО для восстановления данных. И, слава богам, встроенный кэш работал в режиме write-through.
С тех пор я аппаратные RAID контроллеры не использую в своих проектах совсем. Как и встроенные в материнскую плату. И то, и то — точка отказа. Только программные массивы.
Даже все имеющиеся LSI SAS RAID контроллеры в SAS HBA ( Initiator/Target режим) перепрошил.
Нужно такое, в основном мелкому бизнесу и частным лицам, для которых 20к долларов — это деньги. А крупные облака все больше по крупным клиентам работают. Для них все как вы сказали. Проще заплатить.
Потому и сделал я акцент, в основном, именно на то, что, в первую очередь нет инициативы сделать. Технические сложности есть, но они вторичны.
Допустим, задержка биллинга — 3 часа. От лимита осталось 100 долларов. Можно посчитать сколько запросов укладывается в лимит. Допустим, это 100000 запросов.
В сервисе можно поставить ограничение — не больше 100000 запросов. И, по достижении блокировать запросы. При этом, периодически этот лимит можно обновлять по мере того, как биллинг подтягивается и обновляется.
И как я буду теперь свои старые процессоры на «авито» продавать???
dd if=/dev/zero of=/dev/sdaспасает регулярный send/recieve снапшота на устройство для резервных копий. Тем более, оно позволяет перемещать «разницу» между двумя снимками, что очень запросто можно использовать для инкрементального быстрого бэкапа на внешнее устройство.А то, это выглядит как-то странно. Представьте, вы пришли в банк и просите снять все деньги со счета юр-лица наличкой. При этом, вы показываете паспорт, заверенную копию устава другого юр-лица, где вы числитесь директором, и, говорите, «Ну, я еще и директор и этого юр-лица тоже, но заверенного документа показать не могу, но деньги все равно давайте. Можете проверить по базе.» Так вот… скорее всего вас пошлют. Просто потому, что проверять по базе, — не их обязанность.
Личный сертификат или сертификат директора другой компании может подтвердить только личность. Полномочия не может.
В случае зеркала из 2хNVME по достижении 60% износа один из накопителей заменяется на новый. Далее накопители ротируются соблюдая правило, что минимум один из накопителей должен всегда иметь износ меньше 60%, когда как другой может быть любой. Ранее извлеченные накопители с >60% можно потом доносить, когда сдохнет тот, который остался в массиве.
Возможны другие схемы ротации.
fio --name=test --blocksize=4k --direct=1 --buffered=0 --ioengine=libaio --iodepth=1 --loops=1000 --runtime=300 --rw=write --filename=/dev/vg_root/test
write: IOPS=36.8k, BW=144MiB/s (151MB/s)(42.1GiB/300000msec)
| 99.00th=[ 31], 99.50th=[ 37], 99.90th=[ 51], 99.95th=[ 60],
fio --name=test --blocksize=4k --direct=1 --buffered=0 --ioengine=libaio --iodepth=1 --loops=1000 --runtime=300 --rw=read --filename=/dev/vg_root/test
read: IOPS=50.5k, BW=197MiB/s (207MB/s)(57.8GiB/300000msec)
| 99.00th=[ 22], 99.50th=[ 28], 99.90th=[ 45], 99.95th=[ 81],
Выводы коротко:
Для RAID0 рулит Linux Soft RAID;
Для RAID1 рулит VROC;
LSI отстает везде.
Но, только для 4k random R/W.
Дополнительно добавлю, что грузиться с NVM-E вообще и NVM-E Linux Soft RAID в частности можно в Legacy/BIOS режиме, причем, даже на очень старом железе, где BIOS знать не знает, что такое NVM-E. Главное чтобы загрузчик (GRUB) знал, а его можно записать на SATA диск или массив из них, как, например, это сделано тут:
habr.com/ru/post/492834
Вывод из написанного:
Существуют сценарии использования в которых перечисленным накопителям Kingston радиаторы не требуются. OK.