Размещение сервера ZFS в качестве виртуального гостя
Я все еще новичок в ZFS. Я использую Nexenta, но думаю о переходе на OpenIndiana или Solaris 11 Express. Сейчас я рассматриваю возможность виртуализации сервера ZFS в качестве гостя в ESXi, Hyper-V или XenServer (какой из них я еще не определил - я склоняюсь к ESXi для поддержки VMDirectPath и FreeBSD).
Основная причина в том, что мне кажется, что у меня достаточно ресурсов, чтобы обойтись без проблем, чтобы я мог одновременно запустить 1-3 другие виртуальные машины. В основном Windows Server. Может быть, виртуальная машина Linux/BSD. Мне бы хотелось, чтобы на виртуализированном сервере ZFS были размещены все данные для других виртуальных машин, чтобы их данные могли храниться на физически отдельных дисках от дисков ZFS (монтировать как iscsi или nfs).
В настоящее время на сервере установлен AMD Phenom II с 6 полными ядрами (2 разблокированы), 16 ГБ ОЗУ (максимально) и HBA LSI SAS 1068E с (7) дисками SATA II емкостью 1 ТБ (планирование RAIDZ2 с оперативным резервированием). У меня также есть (4) 32 ГБ SATA II SSD, подключенных к материнской плате. Я надеюсь отразить два SSD в загрузочном зеркале (для виртуального хоста) и оставить два других SSD для ZIL и L2ARC (для гостевой виртуальной машины ZFS). Я готов добавить еще два диска для хранения гостей виртуальной машины и выделить все семь текущих дисков в качестве хранилища ZFS. Примечание. Материнская плата не поддерживает IOMMU, поскольку 880G не поддерживает ее, но у меня есть плата 890FX, в которой есть IOMMU, если это имеет огромное значение.
Мои вопросы:
1) Разумно ли это делать? Я не вижу никаких явных недостатков (что заставляет меня задуматься, почему никто другой не упомянул об этом). Я чувствую, что мог бы сделать огромный надзор, и я не хотел бы заниматься этим, перемещаться по всем моим данным только для того, чтобы разобраться с мельчайшими подробностями, которые я пропустил.
2) производительность виртуального гостя ZFS? Я готов нанести небольшой удар по производительности, но думаю, что если у гостевой виртуальной машины будет полный доступ к дискам, производительность дискового ввода-вывода будет, по крайней мере, незначительной (по сравнению с не виртуализацией ZFS)., Кто-нибудь может рассказать об этом из опыта хостинга ZFS-сервера в качестве гостя виртуальной машины?
1 ответ
Я создал несколько таких "все-в-одном" систем хранения ZFS. Первоначально вдохновленный превосходными публикациями в Ubiquitous Talk, мое решение использует несколько иной подход к проектированию аппаратного обеспечения, но дает результат инкапсулированного виртуализированного хранилища ZFS.
Чтобы ответить на ваши вопросы:
Определение того, является ли это мудрым подходом, действительно зависит от ваших целей. Что вы пытаетесь достичь? Если у вас есть технология (ZFS) и вы ищете приложение для нее, то это плохая идея. Лучше использовать подходящий аппаратный RAID-контроллер и запускать виртуальные машины в локальном разделе VMFS. Это путь наименьшего сопротивления. Однако если у вас есть конкретная причина для желания использовать ZFS (репликация, сжатие, защита данных, переносимость и т. Д.), То это определенно возможно, если вы готовы приложить усилия.
Производительность сильно зависит от вашего дизайна, независимо от того, работаете ли вы на голом металле или виртуально. Использование PCI-passthrough (или AMD IOMMU в вашем случае) очень важно, так как вы предоставляете своей виртуальной машине ZFS прямой доступ к контроллеру хранения SAS и дискам. Пока вашей виртуальной машине выделено соответствующее количество ресурсов ОЗУ и ЦП, производительность практически не отличается. Конечно, ваш дизайн бассейна имеет значение. Пожалуйста, рассмотрите зеркала против RAID Z2. ZFS масштабируется по vdevs, а не по количеству дисков.
Моя платформа - VMWare ESXi 5, а моя предпочтительная операционная система с поддержкой ZFS- NexentaStor Community Edition.
Это мой домашний сервер. Это HP ProLiant DL370 G6 под управлением ESXi с внутренней SD-картой. Два зеркальных диска по 72 ГБ в центре связаны с внутренним RAID-контроллером Smart Array P410 и образуют том VMFS. Этот том содержит виртуальную машину NexentaStor. Помните, что виртуальная машина ZFS должна находиться где-то в стабильном хранилище.
Контроллер SAS LSI 9211-8i подключен к отсеку дисковода с шестью дисками SATA емкостью 1 ТБ справа. Он передается на виртуальную машину NexentaStor, что позволяет Nexenta видеть диски как установку RAID 1+0. Диски - это дешевые диски Western Digital Green WD10EARS, правильно выровненные с zpool
двоичный файл.
В этой установке я не использую устройство ZIL или любой кэш L2ARC.
Виртуальная машина имеет 6 ГБ оперативной памяти и 2 выделенных виртуальных ЦП. В ESXi, если вы используете PCI-passthrough, будет создано резервирование памяти для полного объема выделенной ОЗУ виртуальной машины.
Я предоставляю NexentaStor VM два сетевых интерфейса. Один для управления трафиком. Другой является частью отдельного vSwitch и имеет интерфейс vmkernel (без внешней восходящей линии связи). Это позволяет виртуальной машине предоставлять хранилище NFS, монтируемое ESXi через частную сеть. Вы можете легко добавить интерфейс uplink, чтобы обеспечить доступ к внешним хостам.
Установите новые виртуальные машины в хранилище данных, экспортируемое ZFS. Обязательно установите параметры "Запуск / выключение виртуальной машины" в ESXi. Вы хотите, чтобы виртуальная машина хранения загружалась до гостевых систем и выключалась последней.
Вот результаты запуска bonnie ++ и iozone непосредственно на NexentaStor VM. Сжатие ZFS отключено, чтобы тест показывал более подходящие числа, но на практике сжатие по умолчанию ZFS (не gzip) всегда должно быть включено.
# bonnie++ -u root -n 64:100000:16:64
Version 1.96 ------Sequential Output------ --Sequential Input- --Random-
Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
saint 12G 156 98 206597 26 135609 24 410 97 367498 21 1478 17
Latency 280ms 3177ms 1019ms 163ms 180ms 225ms
Version 1.96 ------Sequential Create------ --------Random Create--------
saint -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files:max:min /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
64:100000:16/64 6585 60 58754 100 32272 79 9827 58 38709 100 27189 80
Latency 1032ms 469us 1080us 101ms 375us 16108us
# iozone -t1 -i0 -i1 -i2 -r1m -s12g
Iozone: Performance Test of File I/O
Run began: Wed Jun 13 22:36:14 2012
Record Size 1024 KB
File size set to 12582912 KB
Command line used: iozone -t1 -i0 -i1 -i2 -r1m -s12g
Output is in Kbytes/sec
Time Resolution = 0.000001 seconds.
Throughput test with 1 process
Each process writes a 12582912 Kbyte file in 1024 Kbyte records
Children see throughput for 1 initial writers = 234459.41 KB/sec
Children see throughput for 1 rewriters = 235029.34 KB/sec
Children see throughput for 1 readers = 359297.38 KB/sec
Children see throughput for 1 re-readers = 359821.19 KB/sec
Children see throughput for 1 random readers = 57756.71 KB/sec
Children see throughput for 1 random writers = 232716.19 KB/sec
Это график NexentaStor DTrace, показывающий IOPS виртуальной машины хранения и скорости передачи во время тестового прогона. 4000 IOPS и 400+ мегабайт в секунду вполне разумно для таких дисков низкого уровня. (хотя большой размер блока)
Другие заметки.
- Вы захотите протестировать свои твердотельные накопители, чтобы увидеть, могут ли они быть представлены непосредственно на виртуальной машине или DirectPath выбирает весь контроллер материнской платы.
- У вас не так много ресурсов процессора, поэтому ограничьте емкость хранилища до 2 vCPU.
- Не используйте RAIDZ1/Z2/Z3, если вам действительно не нужно место на диске.
- Не используйте дедупликацию. Сжатие бесплатно и очень полезно для виртуальных машин. Дедупликация потребовала бы намного больше RAM + L2ARC, чтобы быть эффективной.
- Запустите без SSD и добавьте их при необходимости. Определенные рабочие нагрузки не достигают ZIL или L2ARC.
- NexentaStor - это полный пакет. Преимущество имеет надежный графический интерфейс управления, однако я слышал и об успехе с Napp-It.