Рекомендация: добавьте дополнительный диск для расширения логического тома или расширения существующего диска

Как несколько vDisks для одного LV повлияют на производительность ввода-вывода для Oracle DB по сравнению с использованием одного большого vDisk на платформе виртуализации, где хранилище из нескольких физических дисков объединяется вместе?

Узкими местами и ограничениями производительности, которые я могу назвать, являются/могут быть:

• подключение к сети хранения uplink, который соединяет гипервизор с внутренним хранилищем.
  Один и тот же канал будет использоваться независимо от того, к одному или многим vDisks будет осуществляться доступ, разницы нет.

• Назначенные лимиты ввода-вывода.
  Большинство стеков виртуализации позволяют платформе устанавливать квоты/лимиты для гостей, чтобы одна бегущая ВМ не вызывала голодание ресурсов для других ВМ, одновременно работающих на том же гипервизоре.
  Если лимиты ввода-вывода назначаются на уровне гостя, то использование одного большого vDisk или множества маленьких vDisk не имеет большого значения.
  Если лимиты IO назначаются на блочное устройство, то каждый дополнительный vDisk дает вам дополнительную квоту IO и дополнительную (потенциальную) производительность.

• Максимальное количество блочных устройств.
  Существует верхнее ограничение на количество томов/vDisk, которые могут быть подключены к одной виртуальной машине. Это накладывает верхний предел на объем изменения размера, который вы можете сделать, добавляя дополнительные vDisks.

Я бы посоветовал вам избегать использования разделов, потому что разделы а) неудобны при изменении размера и могут потребовать перезагрузки, б) вызывают изменение геометрии при изменении размера свыше предельного размера около 500 ГБ. Множественные диски также приводят к путанице в том, как гипервизор называет диски.

Я предпочитаю иметь диск SYS и диск(ы) DATA. Данные SYS я обрабатываю как обычный диск (с некоторым разделением), а диск DATA (скажем, /dev/sdb) я оставляю без разделов и просто использую его непосредственно как физический том (PV).

Допустим, у вас есть каталог /srv, смонтированный как ext4 с /dev/mapper/vg-DATA/lv-srv

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

1. Изменение размера базового диска (sdb) в гипервизоре
2. echo - - - > /sys/block/sdb/device/rescan, чтобы заставить ядро повторно просканировать это SCSI устройство. (не уверен, что это необходимо для таких устройств, как /dev/vd*)
3. dmesg | tail должен показать, что ядро уловило изменение емкости.
4. pvresize /dev/sdb заставит PV автоматически изменить размер (будет написано '1 successful, 0 unsuccessful' или что-то подобное.
5. vgs DATA не покажет, что на диске есть свободное место.
6. Измените размер LV ('srv' в моем примере), используя lvresize --name srv --extents='+100%FREE' --resizefs DATA

(Я набирал все это по памяти, так что если я все сделал правильно, это свидетельствует о повторяемости процесса)

Обратите внимание, что я сказал --resizefs, что предполагает, что используемая файловая система способна изменять размер в режиме онлайн (например, ext4 и xfs). ext4 и xfs)

Я должен сказать, что это, возможно, не самая распространенная практика... но по моему опыту это было НАМНОГО ЛУЧШЕ, чем то, что мы использовали раньше с разделами. Проблемы с обслуживанием обычно возникают, когда диск SYS (с разделами) нуждается в работе, но в этом проекте я сказал нашим инженерам, что это должно быть признаком того, что они должны создать диск DATA и рефакторить хранилище (это то, что обычно требует отключения для переключения). Когда я определял эту практику, я пытался оптимизировать наши операции, чтобы получить опыт, более близкий к тому, что вы видите в облачных сервисах".

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

Я также должен предупредить вас, что диск может показаться пустым для программы 'fdisk'. Используйте 'lsblk', чтобы увидеть, какое хранилище используется (и установите его по умолчанию). Вот почему Oracle не рекомендует использовать ASM на неразделенных дисках; но, возможно, fdisk/parted достаточно умна, чтобы распознать неразделенный диск, который является физическим томом (я сам не знаю).

Что касается производительности, то когда мы перенесли рабочие нагрузки Oracle Database в виртуальные машины, мы обсуждали этот вопрос с администраторами VMWare. В этом случае у них было выделенное хранилище для этого (с другими оптимизациями; я не помню, что именно, но помню, что они отключили моментальные снимки). Их беспокоило то, что у нас не было кучи виртуальных устройств scsi на одной виртуальной шине; но я не знаю, насколько это важно сегодня.

Короче говоря, с точки зрения производительности, если у Nutanix нет эталонной архитектуры для вашей версии Oracle DB и вашей версии и конфигурации хранилища и виртуальной инфраструктуры, то вам придется проводить сравнение. Такие инструменты, как bonnie++, могут быть (все еще?) полезны. Вам также следует больше заботиться о том, будет ли использоваться ASM, или будут ли использоваться файлы.