Лучший выбор файловой системы для NFS для хранения образов дисков VMware
В настоящее время мы используем iSCSI SAN в качестве хранилища для нескольких серверов VMware ESXi. Я изучаю использование цели NFS на сервере Linux для дополнительных виртуальных машин. Я также открыт к идее использования альтернативной операционной системы (например, OpenSolaris), если это обеспечит значительные преимущества.
Какая файловая система на основе Linux поддерживает очень большие непрерывные файлы (например, образы дисков VMware)? В качестве альтернативы, как люди нашли ZFS в OpenSolaris для такой нагрузки?
(Этот вопрос изначально задавался на SuperUser; смело переносите ответы сюда, если знаете как).
5 ответов
Я действительно рекомендую вам взглянуть на ZFS, но чтобы получить приличную производительность, вам нужно выбрать отдельное устройство в качестве ZFS Intent Log (ZIL). По сути, это небольшое устройство (несколько ГБ), которое может записывать очень быстро (20-100K IOPS), что позволяет ZFS немедленно подтверждать, что записи были синхронизированы с хранилищем, но ждать до 30 секунд, чтобы фактически зафиксировать записи на жесткие диски в твой бассейн В случае сбоя / сбоя любая незафиксированная транзакция в ZIL воспроизводится при монтировании. В результате в дополнение к ИБП может потребоваться накопитель с внутренним источником питания / суперконденсатором, чтобы любые ожидающие операции ввода-вывода превращались в постоянное хранилище в случае потери питания. Если вы выбираете выделенное устройство ZIL, запись может иметь большую задержку, приводящую ко всем видам проблем. Предполагая, что вас не интересует оптимизированный для записи твердотельный накопитель Sun Loggilla объемом 18 Гбайт за $8200, существуют некоторые более дешевые альтернативы:
- DDRDrive X1 - 4 ГБ флэш-памяти DDR2 + 4 ГБ на плате PCIe x1, специально разработанной для использования с ZIL. Пишет в оперативку; в случае потери питания он синхронизирует ОЗУ с NAND в течение <60 секунд при питании от суперконденсатора. (50000-300 000 операций ввода-вывода в секунду; $2000 Direct, $1500 за.edu)
- Intel X25-E 32 ГБ 2,5-дюймовый SSD (SLC, но без супер-колпачка, 3300 операций записи на ввод-вывод); [$ 390 @ Amazon] [11]
- OCZ Vertex 2 Pro 40 ГБ 2,5-дюймовый SSD (суперкап, но MLC, IOPS с записью 20k-50k); $ 435 @ Амазонка.
После того, как вы установили OpenSolaris/Nexenta + ZFS, есть довольно много способов перемещать блоки между вашими OpenSolaris и ESX boxen; то, что вам подходит, во многом зависит от вашей существующей инфраструктуры (коммутаторы L3, оптоволоконные карты) и ваших приоритетов (избыточность, задержка, скорость, стоимость). Но поскольку вам не нужны специализированные лицензии для разблокировки функциональности iSCSI/FC/NFS, вы можете оценить все, для чего у вас есть оборудование, и выбрать свой любимый:
- iSCSI Targets (загрузка ЦП; нет поддержки ОО в OpenSolaris)
- Цели Fibre Channel (оптоволоконные карты недешевы)
- NFS (VMWare + NFS может быть привередливым, ограничено 32 монтированиями)
Если вы не можете потратить 500 долларов США на тестирование, проведите тестирование с отключенным ZIL и без него, чтобы определить, является ли ZIL узким местом. (Это, вероятно, так). Не делай этого в производстве. Пока что не связывайтесь с дедупликацией ZFS, если у вас нет большого количества оперативной памяти и SSD для L2ARC. Определенно приятно, когда вы его настроите, но вы определенно пытаетесь выполнить NFS Tuning перед тем, как поиграть с дедупликацией. Как только вы получите насыщение каналов 1-2 Гб, у 8gb FC, 10gigE и infiniband появятся возможности для роста, но каждый из них потребует значительных инвестиций даже для оценки.
Мы используем OpenSolaris 2009/06 с конфигурацией RAID 10 ZFS для предоставления NFS нашему серверу VMWare ESXi. Пока что это работает довольно хорошо для наших нужд. Мы используем диски типа SATA Raid (диски Seagate ES.2 1 ТБ). У нас еще есть некоторые настройки, чтобы сделать однако.
Я бы так не поступил. По моему опыту, Linux (особенно CentOS 3/4/5), как правило, плохой выбор для NFS-сервера. У меня их было несколько, и я обнаружил, что под нагрузкой задержка и пропускная способность имеют тенденцию к падению по причинам, которые мы никогда не могли полностью решить.
В наших случаях мы сравнивали совместную производительность Linux с Solaris (на Ultra-SPARC) и NetApp; оба из них дали результаты с точки зрения производительности "яблоки к яблокам" и туманного выражения "инженеры почти не жалуются на задержку, когда сервер находится под нагрузкой". Было несколько попыток настроить сервер Linux NFS; системы NetApps и Solaris работали "из коробки". И поскольку обе системы Solaris и NetApp были более старыми, можно утверждать, что серверы Linux имели все преимущества и по-прежнему не были убедительными.
Если у вас есть время, стоит провести эксперимент по настройке одного и того же оборудования с OpenSolaris (теперь, когда Solaris слишком дорогой в использовании), Linux и, возможно, с вариантом BSD или двумя, и участвовать в них. Если вы можете предложить некоторые показатели производительности (например, количество дисковых операций ввода-вывода в виртуальной машине, размещенной вне магазина), это может стать интересным техническим документом или статьей в Интернете. (Если у вас есть время.)
Что касается NFS в целом, люди из NetApp несколько раз говорили мне, что их тесты показали, что производительность NFS для виртуальных машин была всего 5-10%, а если ваше приложение было достаточно чувствительным, чтобы это было проблемой, вам не следует виртуализировать это в первую очередь.
Но я должен признаться, что после всех этих пор и времени наши нелокальные производственные хранилища виртуальных машин питаются от iSCSI, в основном от NetApp.
Я большой поклонник хранилищ данных NFS для VMware, у NetApp отличная реализация.
TR-3808 сравнивает масштабирование общих хранилищ данных, связанных с NetApp FC, iSCSI и NFS, что является отличным чтением.
Возможно, вы захотите рассмотреть 3-летнюю ошибку в ZFS ARC, которая все еще сохраняется, прежде чем углубляться в ZFS...
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6522017
(Это отвратительно, поскольку оно также выходит за пределы виртуальной машины гипервизора!)