Назад | Перейти на главную страницу

Причины запустить программный RAID на Linux-сервере, работающем в VMWare

Я обнаружил, что один из наших серверов работает на виртуальной машине VMWware и имеет программный RAID.

Админ недоступен в ближайшие дни.

Я думаю, что программный рейд в виртуальной машине не имеет смысла. Я думаю, что с RAID должен работать гипервизор, а не внутри виртуальной машины.

Что могло быть реальной причиной для этого?

cat /proc/mdstat

Personalities : [raid10] 
md127 : active raid10 sde1[3] sdc1[1] sdb1[0] sdd1[2]
      209712128 blocks super 1.0 512K chunks 2 near-copies [4/4] [UUUU]
      bitmap: 0/2 pages [0KB], 65536KB chunk

unused devices: <none>

В общем, в большинстве случаев это не имеет смысла.

Однако есть несколько особых случаев, когда это имеет смысл (это не исчерпывающий список, это просто то, что я могу придумать):

  • Администратор знал, как настроить программные RAID-массивы в Linux, но не в VMWare, поэтому он установил их там, где, как он знал, он мог правильно им управлять. Это будет мое первое предположение в вашем конкретном случае, учитывая, что вы не предоставили много другой информации на сервере.
  • Если в любом случае это должен быть программный RAID, может быть более эффективно обрабатывать его внутри виртуальной машины, а не снаружи. Это может быть, а может и не иметь место для любого конкретного продукта VMWare, который вы используете (я сомневаюсь, что это будет для ESXi, но меня бы не удивило, если бы это было для некоторых других продуктов VMWare).
  • Если гость начал свою жизнь на физическом сервере, а затем вам нужно его виртуализировать, имеет смысл просто сохранить стек хранилища как есть в гостевой системе, потому что это упрощает процесс преобразования и снижает вероятность остановки чего-либо в гостевой системе. работает из-за разной конфигурации.
  • Если целью виртуальной машины является тестирование конкретной программной конфигурации, которая будет использоваться на реальном оборудовании, конфигурация внутри виртуальной машины должна быть как можно ближе к тому, что будет фактически использоваться на реальном оборудовании, включая использование того же хранилища. стек.
  • Здесь не так, но при использовании BTRFS / ZFS внутри виртуальной машины, но не снаружи, имеет смысл иметь репликацию и / или четность внутри виртуальной машины, чтобы вы могли в полной мере воспользоваться контрольными суммами блоков, предоставляемыми BTRFS / ZFS. для исправления ошибок. Тот же аргумент может быть применен в обратном порядке, если у вас есть BTRFS или ZFS в качестве серверной части хранилища на хосте, но вы не используете их внутри гостей.
  • Если необходимо, чтобы каждая копия хранилась на физически отдельном оборудовании, может быть проще добиться этого, разместив уровень RAID внутри виртуальной машины. Это легко продемонстрировать с помощью QEMU в Linux и дисков на iSCSI, с уровнем RAID на хосте, вы должны маршрутизировать вещи через несколько уровней внутри блочного уровня хоста, в то время как размещение уровня RAID внутри виртуальной машины означает, что вам не нужно даже прикоснуться к блочному уровню хоста (потому что QEMU изначально может говорить на iSCSI).
  • Какое бы приложение ни работало в гостевой ОС, может действительно заботиться о детальном контроле репликации или относящейся к нему подробной статистике производительности, и ни то, ни другое не может быть легко предоставлено, если массив RAID обрабатывается на хосте.