SMB 3.0 против NFSv4.1: что выбрать для хранения VM-дисков Hyper-V

Казалось бы, протокол для хранения VM-дисков - это не тот выбор, над которым стоит долго думать. Hyper-V на Windows, значит SMB. Linux-хосты под KVM или чужая СХД, значит NFS. Жизнь проще, когда всё определяется экосистемой. Но у одного нашего клиента ситуация оказалась интереснее.

Клиент строит новый кластер Hyper-V на Windows Server 2012 R2. СХД предполагается отдельная, на Linux-основе - это уже развёрнутая машина с ZFS и приличным объёмом дискового пространства. Вопрос: отдавать хранилище по NFS или поднять на той же машине Samba и работать через SMB? Или вообще переосмыслить и поставить Windows-СХД?

Мы решили не гадать, а потестировать.

Что стоит на стенде

Два хоста Hyper-V на Windows Server 2012 R2 с 10GbE-сетевыми картами Intel X520. СХД - сервер на Ubuntu 14.04 с ZFS-пулом на SAS-дисках и ещё одной 10GbE-картой. Сеть - выделенный VLAN для хранилища, MTU 9000 (jumbo frames). Нагрузка - IOMeter c профилями, близкими к реальной VM-нагрузке: смешанный случайный 4K и 64K, глубина очереди от 1 до 16.

Сравнивали три варианта:

• NFSv4.1 с Linux-сервера. Стандартный nfs-kernel-server на Ubuntu, параметры по умолчанию с минимальными правками под наш MTU.
• SMB 3.0 через Samba 4.1 с того же Linux-сервера. Samba выбрана потому, что клиент хотел избежать отдельной Windows-машины для роли файлового сервера.
• SMB 3.0 с Windows Server 2012 R2 - для baseline, чтобы понять, что даёт нативная реализация.

Неожиданный момент с Multichannel

SMB 3.0 в Windows Server 2012 R2 поддерживает Multichannel - автоматическое использование нескольких сетевых путей одновременно. Никакой ручной настройки не нужно: если у сервера и клиента есть несколько подходящих сетевых интерфейсов, SMB сам их агрегирует. Мы добавили второй 10GbE-интерфейс на хостах и на Windows-СХД - и Multichannel подхватил оба пути без каких-либо действий с нашей стороны.

Результат оказался неожиданным: SMB 3.0 с двумя 10GbE-интерфейсами на чтение большими блоками показал результат, близкий к суммарной пропускной способности двух линков. NFSv4.1 при той же конфигурации железа такого эффекта не дал - Linux NFS-клиент не имеет встроенной многоканальности в том же смысле, multipath там нужно городить через bonding или другими способами.

Это не означает, что NFS принципиально медленнее. На мелком случайном I/O разница минимальная - оба протокола упираются в диски раньше, чем в сеть. Но на последовательной пропускной способности, которая критична при параллельном IO от нескольких VM, SMB 3.0 с Multichannel выигрывает заметно.

SMB через Samba - отдельная история

Samba 4.1 SMB 3.0 поддерживает, но с оговорками. Multichannel в нашей версии либо не активировался, либо не давал ожидаемого прироста - в полном объёме он не работал. Samba-вариант по производительности оказался ближе к NFSv4.1, чем к нативному Windows SMB 3.0. Что в общем-то логично: реализация протокола другая, оптимизации другие.

Для клиента это означало выбор: либо Linux-СХД с NFSv4.1 и предсказуемой производительностью без сюрпризов, либо Windows-машина в роли файлового сервера с нативным SMB 3.0 и Multichannel. Третий вариант - Samba на Linux - технически работает, но выигрыша от SMB 3.0 в полном объёме не даёт, и непонятно, зачем тогда платить сложностью настройки Samba вместо простого NFS.

Что с задержками и надёжностью

NFSv4.1 принёс ещё одно улучшение относительно NFSv3, которое важно для Hyper-V: поддержку сессий и pNFS (параллельный NFS). На нашем стенде pNFS мы не тестировали - СХД одна, смысла нет. Но сессионная модель NFSv4.1 заметно лучше для VM-нагрузки: потеря сети не приводит к немедленному зависанию IO, клиент ждёт восстановления сессии.

SMB 3.0 в этом плане тоже не лыком шит: Transparent Failover работает нормально в паре с Windows Server 2012 R2 в роли СХД. Но для сценария Hyper-V на Windows + Linux-СХД по NFS - поведение при сетевых сбоях нужно проверять отдельно под конкретную версию NFS-сервера.

По задержкам на мелком случайном I/O (4K, QD=1) оба протокола ведут себя примерно одинаково - разница в пределах погрешности измерений. Диски медленнее.

К чему пришли

Для этого клиента порекомендовали два варианта на выбор, в зависимости от того, насколько он готов добавить Windows-машину в роль СХД:

• Если Windows-СХД приемлема - Windows Server 2012 R2 с ролью File Server, SMB 3.0 с Multichannel, два 10GbE-линка. Это даёт наилучшую пропускную способность для VM-дисков Hyper-V и самую простую в эксплуатации схему: всё Windows, всё штатно, Multichannel автоматически.
• Если СХД остаётся Linux - NFSv4.1. Надёжно, хорошо задокументировано для Hyper-V (Microsoft сам поддерживает NFS как хранилище для Hyper-V), производительность на мелком IO вполне достаточная.

Samba на Linux в роли Hyper-V-хранилища - в нынешнем состоянии это усложнение без явного выигрыша. Возможно, ситуация изменится с выходом следующих версий Samba с нормальным Multichannel, но пока - не наш выбор.

Клиент склоняется к Linux+NFS как наименее экзотичному варианту для его команды. Сопровождаем в рамках managed-услуги, в продакшне ещё не стоит - посмотрим, что покажет реальная нагрузка через месяц-другой.