Comments 10
Этот раид контроллер и так и так программный. что на уровне ОС ради делать, что на уровне драйвера. только во втором случае программный слой будет скрыт от ОС.
В таком случае, делать раид средствами ОС даже предпочтительнее, т.к. обладает бОльшей управляемость и предсказуемостью в случае выхода из строя диска
В таком случае, делать раид средствами ОС даже предпочтительнее, т.к. обладает бОльшей управляемость и предсказуемостью в случае выхода из строя диска
Очень верно подмечено. Плюс залипнуть на одной версии ядра. Мне в свое время хватило печального опыта с подобными контроллерами, которые достались на серваках с боевыми системами, когда нужен был апгрейд, но фигушки.
Хотя справедливости ради, стоит отметить, что в том же EL8 редхаты выпилили поддержку кучи аппаратных контроллеров, которые еще вполне себе актуальны и пользуются спросом на вторичке типа lsi 2x08.
Обратите внимание, драйвер rhel7u8 спокойно работает в текущей CentOS 7.9. И в 6-ке конкретно на этой машине пройдено не мало апдейтов, все ровно. Благо, она в парке всего одна с таким адаптером. Год лежала без дела, дождалась, нашлось ей применение. )
На грабли можно наступить и с отказом вполне надежных настоящих аппаратных и Адаптеков и LSI — через это тоже проходили.
Выпилили старье — и не надо держаться за это «наследие». Оно тянет назад. Нет смысла поддерживать его во всем многообразии везде и всюду. Ядро будет несоразмерно распухшим. Старому железу — старые ОС, 7-ка еще до 2024 поддерживается.
На грабли можно наступить и с отказом вполне надежных настоящих аппаратных и Адаптеков и LSI — через это тоже проходили.
Выпилили старье — и не надо держаться за это «наследие». Оно тянет назад. Нет смысла поддерживать его во всем многообразии везде и всюду. Ядро будет несоразмерно распухшим. Старому железу — старые ОС, 7-ка еще до 2024 поддерживается.
Да, он по сути программный. Однако управляется нормально, причем единообразно и в M$ Окнах, и в Linux, и в ESXi (который, будучи энтерпрайзным продуктом, чисто программные массивы не поддерживает вообще). Об управлении из ОС есть раздел в статье.
После замены диска контроллер сам соберет массив без каких либо дополнительных настроек со стороны ОС.
О потенциальной опасности этого (как, впрочем, и любого другого с железной составляющей) контроллера против программного массива есть предупреждение. Но надо помнить, что идеальная надежность — штука почти не достижимая и надо понимать, против каких рисков какие меры следует применять.
После замены диска контроллер сам соберет массив без каких либо дополнительных настроек со стороны ОС.
О потенциальной опасности этого (как, впрочем, и любого другого с железной составляющей) контроллера против программного массива есть предупреждение. Но надо помнить, что идеальная надежность — штука почти не достижимая и надо понимать, против каких рисков какие меры следует применять.
А потом Redhat что-то поменяет в ядре и текущий драйвер превратится в тыкву с обновлением. Насколько я помню такое уже было один раз точно. Аналогично разок сам наступил на такие же грабли со связкой CentOS 7 + DKMS + ixgbe. Нативный драйвер сетёвки любил чудить переставляя пакеты в буфере местами (как на приеме, так и на отправке). Для TCP ничего критичного, но вот MPEG2TS-over-IP страдал. Собрал свежий igxbe без таких чудес из исходников, инсталлировал через DKMS и спустя год весь этот карточный домик на костылях рухнул при обновлении ядра. К тому моменту, к счастью, эту багу пофиксили в нативном модуле.
Никого не оправдываю, но у всех бывают ошибки. И у Intel'а и RH и M$ и у <впишите своего любимого вендора>. RedHat не так часто вносит критические изменения и для этого есть какие-то причины. А если что-то и не работает, у Вас же есть подписка и можете обратиться в ТП? )) Ну а если нет — система живет без гарантии, на свой страх и риск. Об этом всегда следует помнить, не зависимо от от любви или ненависти к Linux. Равно как и в ОС от M$ тоже случаются чудеса, кратно усиливающиеся после обновлений, вплоть до BSoD.
Вроде еще в доке для CentOS 5 был описан данный метод подгрузки драйвера во время инсталляции ОС. Перевод просто запостили?
В документации ОС процесс обновления описан как для 5-ки (и более ранним)), так и по 7-ке, в статье есть ссылка на него. Любопытные могут ознакомиться, там много интересного. Есть и по 8.
Опять же в родной документации к ОС есть и описание этой ситуации. В статье также есть на нее ссылка.
Перевод чего? Если уже говорить о переводах, то это скорее что-то около HPE-шное. Но статья — туториал, а не перевод. Просто обмен опытом по вполне конкретной задаче. На HPE-шные ресурсы тоже указаны ссылки.
Итого: статья полное пошаговое руководство по конкретной задаче с отсылкой к первоисточникам.
Опять же в родной документации к ОС есть и описание этой ситуации. В статье также есть на нее ссылка.
Перевод чего? Если уже говорить о переводах, то это скорее что-то около HPE-шное. Но статья — туториал, а не перевод. Просто обмен опытом по вполне конкретной задаче. На HPE-шные ресурсы тоже указаны ссылки.
Итого: статья полное пошаговое руководство по конкретной задаче с отсылкой к первоисточникам.
Создайте бэкап сервера c clonezilla, etc.
Переведите raid-контроллер в hba mode.
Разверните Proxmox с ZFS.
Импортируйте бэкап с помощью qm import.
Радуйтесь )
forum.netgate.com/topic/120102/proxmox-ceph-zfs-pfsense-%D0%B8-%D0%B2%D1%81%D0%B5-%D0%B2%D1%81%D0%B5-%D0%B2%D1%81%D0%B5
Переведите raid-контроллер в hba mode.
Разверните Proxmox с ZFS.
Импортируйте бэкап с помощью qm import.
Радуйтесь )
forum.netgate.com/topic/120102/proxmox-ceph-zfs-pfsense-%D0%B8-%D0%B2%D1%81%D0%B5-%D0%B2%D1%81%D0%B5-%D0%B2%D1%81%D0%B5
Sign up to leave a comment.
CentOS 7 и контроллер HPE B320i