Рекомендации: настройка стека NAS 10GbE для хранилища виртуализации
Я постараюсь изо всех сил сказать это, чтобы это не считалось списком покупок.
Некоторое время мы успешно запускаем среду разработки / тестирования ESXi с парой серверов Dell PE2950III через начальный комплект HP MSA2012fc (с коммутатором SAN класса B на базе Brocade). Это очень хорошо сработало для нас, но, будучи в dev/test, оно имеет ряд предостережений в отношении времени безотказной работы / производительности.
В любом случае, предполагаемый успех платформы dev / test привел к призывам к более "готовой к работе" платформе виртуализации. Мы сейчас готовим рекомендации.
Однако одна из претензий к существующему стеку связана с отсутствием поддержки других технологий виртуализации (HyperV, Xen и т. Д.), Поскольку SAN LUN полностью выделены и отформатированы как VMFS. Это то, что нам сказали преодолеть, но, как это обычно бывает, нет никаких признаков использования HyperV/Xen (и мы не особенно хотим тратить "дорогой" ресурс хранения, выделяя LUN таким, где он не будет использоваться).
Таким образом, наша текущая идея заключается в том, чтобы отказаться от традиционной волоконно-оптической сети хранения данных (SAN) в пользу простого CentOS-блока (вероятно, HP ProLiant DL380p Gen8 более высокого уровня), работающего с демонами NFS и Samba/CIFS, с коммутатором 10GbE (возможно, Cisco Nexus серии 5000/5500).
Причина заключается в том, что головки ESXi могут общаться по NFS, а головки HyperV могут говорить по CIFS, но в конечном итоге оба указывают на одни и те же тома XFS/RAID1+0.
Теперь я не настолько хорош, чтобы думать, что 10GbE позволит мне получить истинную пропускную способность ввода-вывода 10 Гбит / с между головками и дисками, но я не знаю, какие издержки я могу ожидать от реализации NFS и CIFS (и любые другие биты, которые могут помешать, когда с ним пытается общаться более одного хоста).
Я надеюсь, по крайней мере, приблизиться к постоянной скорости чтения / записи дисков прямого подключения, хотя, для максимально возможного количества хостов. Глядя на веб-сайты различных производителей приводов, я примерно ожидаю, что это будет где-то около отметки 140-160 МБ / с (если я далеко, пожалуйста, дайте мне знать).
Какие рекомендации / рекомендации / дальнейшее чтение может предложить кто-либо в отношении конфигурации коммутатора Linux/NFS/Samba или 10GbE, который может помочь достичь этого?
3 ответа
Я понимаю желание перейти от чистого блочного хранилища к чему-то более гибкому.
Однако я бы не стал использовать для этого простой стек хранения Linux, когда сейчас доступно несколько предложений программного обеспечения для устройств хранения. Подход Linux может сработать, но недостаток функций / поддержки управления, необходимая настройка XFS ( здесь и здесь) и тот факт, что это не специализированная ОС хранения, являются недостатками.
Добавьте к этому некоторые неприятные проблемы с сопровождающим кода XFS/RHEL и неприятную ошибку в ядре, которая влияет на среднюю загрузку системы, и описанная вами комбинация Linux становится менее привлекательной.
Чистый Linux можно было бы заставить хорошо работать для этой цели, но установка, безусловно, была бы вне нормы и могла бы использовать эзотерические решения, такие как ZFS на Linux или не очень готовые к запуску Btrfs. Подробнее об этом позже.
Я делаю это часто, предпочитая использовать NFS в хранилище на основе ZFS для большинства моих развертываний VMware, в отличие от SAN начального уровня, такого как массив HP P2000. Я дополняю установку ZFS с помощью устройств кэширования SSD и DRAM L2ARC (чтение) и ZIL (запись). Кроме того, я использую 10GbE с этим типом установки в течение четырех лет.
Сейчас я сосредоточусь на NexentaStor, поскольку это программное обеспечение для устройств, которое я использую большую часть времени...
Я построил множество систем на основе HP ProLiant для хранилища ZFS, от универсальных хостов VMware до автономных "устройств" хранения DL380 до полнофункциональных многопутевых SAS-соединений с каскадными блоками JBOD хранилища ( спереди и сзади).
NexentaStor и NFS / CIFS.
Nexenta поддерживает представление файлового и блочного хранилища для внешних систем. Я могу взять пул из 24 дисков и предоставить хранилище iSCSI для хостов, которым требуется собственное блочное хранилище, NFS для моей инфраструктуры VMware ESXi и CIFS для нескольких клиентов Windows. Пространство используется эффективно и вырезано из хранилища бассейна. Например, нет искусственных шапок. Сжатие прозрачно и очень помогает в сценариях виртуальных машин (меньше перемещаться по проводам).
10GbE помогает, но это зависит от того, что вы представляете своим хостам виртуализации. Будут ли они 1GbE или 10GbE?
тесты:
Я проведу быстрый тест гостевой виртуальной машины, работающей на хосте ESXi, подключенном через 10GbE к NexentaStor SAN.
Это собирается на 6-дисковый массив. (в корпусе HP D2600 - 600 ГБ, 15k SAS)
[root@Test_VM /data]# iozone -t1 -i0 -i1 -i2 -r1m -s6g
Iozone: Performance Test of File I/O
Run began: Mon Feb 11 18:25:14 2013
Record Size 1024 KB
File size set to 6291456 KB
Command line used: iozone -t1 -i0 -i1 -i2 -r1m -s6g
Output is in Kbytes/sec
Children see throughput for 1 initial writers = 128225.65 KB/sec
Children see throughput for 1 readers = 343696.31 KB/sec
Children see throughput for 1 random readers = 239020.91 KB/sec
Children see throughput for 1 random writers = 160520.39 KB/sec
Это будет занятый 16-дисковый массив (в корпусе HP D2700 - 300 ГБ, 10 000 SAS).
[root@Test_VM2 /data]# iozone -t1 -i0 -i1 -i2 -r1m -s4g
Iozone: Performance Test of File I/O
Run began: Mon Feb 11 16:33:53 2013
Record Size 1024 KB
File size set to 4194304 KB
Command line used: iozone -t1 -i0 -i1 -i2 -r1m -s4g
Output is in Kbytes/sec
Children see throughput for 1 initial writers = 172846.52 KB/sec
Children see throughput for 1 readers = 366484.00 KB/sec
Children see throughput for 1 random readers = 261205.91 KB/sec
Children see throughput for 1 random writers = 152305.39 KB/sec
Графики ввода-вывода из одного и того же цикла... Килобайт / сек и IOPS.
Использование хоста Linux, предоставляющего хранилище CIFS для хостов Hyper-V, нецелесообразно и определенно не поддерживается Microsoft. Когда вы говорите о чем-то столь важном, как виртуализация для критически важной бизнес-инфраструктуры, вам определенно нужна поддержка поставщиков.
Вам нужно будет либо предоставить более традиционные хранилища iSCSI или Fibre Channel для серверов Hyper-V, либо, если вы планируете использовать Windows 2012, вы можете использовать службы хранилища Windows 2012 для предоставления iSCSI вашим хостам.
Другая возможность - использовать Windows 2012 или что-то вроде Nexenta в качестве виртуального гостя в вашей инфразратуре VMWare, чтобы предоставить iSCSI для гостей Hyper-V. Это не самая производительная конфигурация, но и не плохая. Поскольку ваша площадь Hyper-V невелика или отсутствует, это может быть хорошим компромиссом для максимальной гибкости без выделенного LUN.
В противном случае вам придется использовать что-то, что полностью виртуализирует ваши логические модули, например HP LeftHand SAN. С LeftHand диски не предназначены для LUN. Вместо этого все LUN распределяются по всем дискам. Звучит немного странно, но это хороший продукт.
Вероятно, отчасти это мой опыт и опыт, о которых я здесь говорил, но я бы не рекомендовал решение для домашнего пивоварения для хранения виртуальных машин в среде, которая может считаться производственной или корпоративной.
Я бы посмотрел на основных поставщиков систем хранения данных, которые могли бы предоставить решение SAN, но с парой головок NAS высокой готовности для экспорта базовой файловой системы в виде NFS/CIFS поддерживаемым, сертифицируемым способом.