что быстрее nfs или iscsi

Что быстрее ISCSI или NFS

Господа, есть задача отдать серверу лун (с БД Postgres) c хранилища QNAP по ethernet. База будет довольно-таки большая (>100Гб) + регулярно будут делаться бекапы на другой лун того же хранилища.

Что будет работать быстрее ISCSI over Ethernet или NFS? П.С. Склоняюсь в сторону ISCSI, на сколько надежно работает? сам ни разу не настраивал

Присоединяюсь к оратору, iSCSI.

а работает он нормально? стабильно? пишут что отваливается иногда и сам не находит подключенные разделы

Выше перепись бухгалтеров вспомнивших услышанное на работе от админа словечко)

Я бы беспокоился о другом. БД на сетевой хранилке это дополнительный риск, а при учете того что на дворе 2017год обьем у вас не «довольно-таки большая (>100Гб)» а весьма скромная. Не разумнее ли со всех точек зрения разместить ее на самом серваке?

регулярно будут делаться бекапы на другой лун того же хранилища.

Сама БД будет на серваке, а вот файлы БД на хранилке. На серваке 2 диска по 600 Гб в рейд 1. А вот на хранилке 6 по 2ТБ в РЕЙД6

PG_DUMP что делает? бекап

Она на данный момент 100ГБ, но будет расти. Не вариант размещать такую базу на пространстве в 500Гб. Поправлюсь: Postgres будет на серваке в вот инстанс БД на хранилке. Все-таки я считаю что рейд6 надежнее рейда 1

Все-таки я считаю что рейд6 надежнее рейда 1

Это неверно. Четырёхдисковое зеркало надёжнее RAID6.

Искусственное ограничение. RAID1 всегда можно сделать надёжнее любого другого уровня.

По части обьема, надо понимать насколько планируется рост БД, если вам этих 500Гб мало то проще заранее заменить харды на большие.

Неплохо бы учесть tps. А то 100Гб с 10 запросов в секунду и 100Гб с 1000 запросов в секунду это серьезная разница.

Да и вообще, кажется qnap это SOHO железо, лучше базы данных на таком не держать.

Почему бы тебе не собрать 10ку из шести дисков в хранилке?

Спасибо, за такой подробный ответ! Я подумал, вы правы! В данном случае лучше разместить бд на дисках сервера, а бекапы скидывать на хранилку.

Источник

Что быстрее между сервером и клиентом iSCSI или NFS?

Может кто тестировал и ту и ту связку между двумя компами и расскажет об этом?

Re: Что быстрее между сервером и клиентом iSCSI или NFS?

iscsi во всех отношениях

Re: Что быстрее между сервером и клиентом iSCSI или NFS?

А по этой ссылке это не так:

Re: Что быстрее между сервером и клиентом iSCSI или NFS?

Re: Что быстрее между сервером и клиентом iSCSI или NFS?

Шутники. Особенно Бирди, известный спец по iSCSI.

2 автор: это разные вещи. Что быстрее, xfs или SATA?

Re: Что быстрее между сервером и клиентом iSCSI или NFS?

Re: Что быстрее между сервером и клиентом iSCSI или NFS?

> Шутники. Особенно Бирди, известный спец по iSCSI.

Re: Что быстрее между сервером и клиентом iSCSI или NFS?

>2 автор: это разные вещи. Что быстрее, xfs или SATA?

Скорость xfs зависит от SATA. Правильнее вопрос ставить так, что быстрее передаёт данные SATA или 100Mb Ethernet. И тут точно так же:

Мне нужно знать, скорость работы с удалённым диском будет быстрее используя NFS протокол или iSCSI. Оба варианта позволяют оргаизовать работу с удалённым диском.

Re: Что быстрее между сервером и клиентом iSCSI или NFS?

Our results, generated by running some of industry standard benchmarks, show that iSCSI significantly outperforms NFS for situations when performing streaming, database like accesses and small file transactions.

iSCSI лучше только при интенсивной работе с малыми порциями данных.

З.Ы. Я бы выбрал НФС.

Re: Что быстрее между сервером и клиентом iSCSI или NFS?

> Мне нужно знать, скорость работы с удалённым диском будет быстрее используя NFS протокол или iSCSI.
> Оба варианта позволяют оргаизовать работу с удалённым диском.

По NFS получаеш фаловую систему, ISCSI отдает блочное устройство. говориш нет разницы?

К примеру у меня на нем NFS home, который перекидываеся так же по ISCSI на другой сервак при тех обслуживании либо форс мажоре.

Re: Что быстрее между сервером и клиентом iSCSI или NFS?

А у меня задача проще, клиентом нужно получить доступ к удалённому диску на сервере и выбрать для этого наиболее быстродействующий вариант. И не важно где будет уровень FS заюзан на сервере (NFS) или клиенте (iSCSI).

Re: Что быстрее между сервером и клиентом iSCSI или NFS?

Re: Что быстрее между сервером и клиентом iSCSI или NFS?

> А у меня задача проще, клиентом нужно получить доступ к удалённому
> диску на сервере и выбрать для этого наиболее быстродействующий вариант.
> И не важно где будет уровень FS заюзан на сервере (NFS)
> или клиенте (iSCSI).
Очень наивно. А стоимость оборудования вы не учитываете?
Плата ISCSI для клиента к примеру QLogic стоит под штуку баксов.
А сервер ISCSI вы наверно так же софтово будете реализовать?
Не завидую.

Re: Что быстрее между сервером и клиентом iSCSI или NFS?

Именно так, что совтово будет быстрее (никаках спец плат) iSCSI или NFS. И то и то софт.

Re: Что быстрее между сервером и клиентом iSCSI или NFS?

>Именно так, что совтово будет быстрее (никаках спец плат) iSCSI или NFS. И то и то софт.

Не знаю, как работает софтверная реализация iSCSI под линуксом, но NFS худо-бедно по крайней мере пашет, что не могу утверждать про софтверный iSCSI.

Re: Что быстрее между сервером и клиентом iSCSI или NFS?

> Не знаю, как работает софтверная реализация iSCSI под линуксом,
> но NFS худо-бедно по крайней мере пашет,
> что не могу утверждать про софтверный iSCSI.
ваша позиция очень верная, пока ко мне шли платы в течении месяца, внешнее хранилище уже было закуплено ну и для тестов на серваках Поднимал различные (две) реализации ISCSI, впечатление ужасное.
Чего стоит одно банальное выдергивание кабеля и кернел паник.

Источник

Бюджетная виртуализация. NFS vs iSCSI, что выбрать?

Статья опубликована в журнале «Системный Администратор»

Тестируем и выбираем тип хранилища для небольших виртуальных сред.

Введение

При построении виртуальной инфраструктуры бюджетного уровня, порой, даже у профессионалов возникает вопрос, какой тип хранилища и протокол доступа к нему использовать. Различные источники говорят по разному и часто сбивают с толку. Попробуем разобраться, как оно есть на самом деле.

Почему не FC

Безусловно лучшим решением для построения высокопроизводительных и надежных сетей хранения данных(далее СХД) для любых задач, является использование оптических каналов и Fibre Channel Prototocol(FCP).
FCP инкапсулирующий SCSI команды, изначально разрабатывался с учетом всех тонкостей блочного обмена данными. В нем отсутствуют основные недостатки классических сетевых протоколов типа TCP/UDP, в которых данные могут теряться или приходить не последовательно, что не приемлемо для SCSI. Заголовок пакета FCP минимален в отличии от того же iSCSI, что значительно сокращает накладные расходы. Аппаратные контроллеры FC — HBA(Host Bus Adapter) полностью берут на себя генерацию заголовков пакетов снимая тем самым нагрузку с центральных процессоров. А высокопроизводительные оптические каналы (2Gb/4Gb/8Gb и выше) обеспечивают надежную передачу данных на большие расстояния.

О FC и сетях хранения, построенных с его применением, написаны целые книги [1] и перечислять его достоинства можно долго, но хочется сказать о его главном недостатке.
Высокая стоимость отдельных компонентов FC(HBA, коммутаторы и тому подобное) и суммарная стоимость конечной реализации, пожалуй, является определяющим фактором заставляющим отказаться от сетей хранения на базе FC. Так же далеко не каждая инфраструктура, в том числе и виртуальная, нуждается в FC. Например для полноценной работы нескольких десятков виртуальных машин(ВМ) не обязательно строить дорогостоящую систему хранения. А все технологии, присущие виртуализации (живая миграция ВМ, высокая доступность и так далее) так же реализуемы на iSCSI или NFS. Более того, некоторые платформы виртуализации, например такие как ProxmoxVE [3] или CloudStack [2] и вовсе не умеют работать с FC, тогда использование как iSCSi и NFS доступно на всех платформах. В общем, можно сказать однозначно, что NFS и iSCSI — быть! А вот, что и где эффективнее использовать, поговорим далее.

Немного о NFS

Network File System (NFS) — является протоколом сетевого доступа к файловым системам. NFS клиенты получают доступ к файлам на NFS сервере путем отправки RPC-запросов (Remote Procedure Call) на сервер. Если разложить структуру протокола NFS по уровням эталонной модели OSI, то выглядеть это будет примерно так:

— На прикладном уровне, выполняется собственно сам NFS, осуществляющий вызовы удаленных процедур (RPC), которые и производят различные операции с файлами и каталогами на сервере.
— Далее, RPC-вызовы передаются протоколу XDR (eXternal Data Representation), который работает на презентационном уровне и является меж платформенным стандартом абстракции данных. Протокол XDR описывает унифицированную, каноническую форму представления данных, не зависящую от архитектуры вычислительной системы. При передаче пакетов RPC-клиент переводит локальные данные в каноническую форму, а сервер проделывает обратную операцию.
— После унификации данных, сервис RPC (Remote Procedure Call), с клиентской стороны обеспечивает запрос удаленных процедур и их выполнение на сервере, представляя функции сеансового уровня. На этом, слои, специфичные для NFS заканчиваются. После чего данные инкапсулируются в стандартные TCP/UDP пакеты и отправляются дальше на лежащие ниже уровни эталонной модели OSI.

Стоит отметить, что в большинстве реализаций, NFS использует именно TCP в качестве транспортного протокола.
Таблица №1. Сопоставление уровней модели OSI и NFS

На практике, NFS реализуется очень просто и абсолютно прозрачно для любых клиентских приложений, которые и не подозревают, что их данные фактически находятся на NFS-сервере.
Пожалуй, за счет своей простоты, реализация NFS-сервера и клиента присутствует во всех современных Linux/Unix дистрибутивах, а так же в новых версиях Windows Server (2008 и выше).

NFS в контексте виртуализации

Прежде всего, NFS позволяет построить масштабируемое и легкое в управлении сетевое хранилище данных без использования дорогостоящего оборудования. Для работы NFS, достаточно обычного Gigabit Ethernet.
При этом весь функционал платформ виртуализации, такой как: горячая миграция виртуальных машин, балансировка нагрузки, высокая доступность, миграция между хранилищами, доступен так же, как при использовании FC.

К минусам NFS, стоит отнести не возможность предоставления ВМ блочного устройства или его логического раздела(LUN) целиком (Raw Device Mapping), что доступно при использовании протоколов FC и iSCSI. При использовании NFS, диски ВМ могут быть только в виде файлов, что делает кластеризацию ВМ не возможной. Так же NFS, не позволяет выполнить загрузку гипервизора по сети с системы хранения.
В случае с блочными устройствами и соответствующими протоколами (FC и iSCSI) некоторые платформы виртуализации, например VMware vSphere и Citrix XenServer создают на подключенных хранилищах собственную, кластерную файловую систему(ФС), что может оказаться эффективнее NFS работающей зачастую поверх обычных ФС. В дополнение к и так весомым минусам, можно отнести отсутствие в NFS какой-либо авторизации, кроме не всегда удобной возможности разграничивать доступ к хранилищу по ip-адрессам.

Отдельным минусом хочется выделить, проблемы производительности NFS. За счет внутренних особенностей протокола и высоких накладных расходов, связанных с инкапсуляцией нескольких протоколов высокого уровня в стандартный пакет TCP, сокращается объем полезной нагрузки (реальных данных) в пакете. Для оптимизации производительности и отказоустойчивости NFS, необходим ряд более тонких настроек, выполнение которых можно отнести к минусам протокола.

Вопросам оптимизации производительности будет просвещена отдельная статья.

Немного о iSCSI

Internet Small Computer System Interface () – сетевой протокол, обеспечивающий взаимодействие объектов (Целей и Инициаторов) в сетях хранения данных. Стоит обратить внимание на то, что в данной статье рассматривается только программно реализуемый iSCSI. Поэтому, под объектами подразумеваются серверы, операционные системы, платформы виртуализации выступающие в роли Инициаторов и блочные устройства расположенные в системах хранения (являющиеся Целями). В iSCSI, так же как и в FC транслируются SCSI команды, а данные передаются блоками только в качестве транспорта, iSCSI использует стандартный стек TCP/IP вместо FCP, а средой передачи являются стандартный Ethernet(1Gb/10Gb) вместо более надежной оптики.
Таблица №2. Уровни протокола iSCSI.

По функционалу, iSCSI, очень похож с FC, но значительно дешевле. Сегодня, программная реализация iSCSI доступна во всех современных ОС, а основной сферой его применения является виртуализация, в которой он поддерживается практически всеми платформами.

В контексте виртуализации iSCSI позволяет так же как и в случае с NFS, построить масштабируемое сетевое хранилище с возможностью использовать все присущие виртуализации функции.

К особенностям iSCSI в противовес NFS можно отнести возможность предоставления виртуальным машинам, диска (LUN в терминологии SCSI) целиком (Raw device mapping), что позволяет строить кластеры из нескольких ВМ. Так же на LUN-ах можно размещать произвольную файловую систему. В случае с iSCSI, возможна авторизация по связке имени и пароля.

К минусам, можно отнести более сложный чем с NFS, процесс настройки требующий немного больше навыков. Так же как и в случае с NFS, iSCSI имеет большие накладные расходы в связи со многоуровневой инкапсуляцией данных.

Тестовый стенд NFS vs iSCSI

Так как тема статьи ориентированна на инфраструктуры начального уровня то и тестовый стенд решено было собрать крайне бюджетный.

В качестве хранилища был выбран старый сервер с одноядерным процессором, 1 гигабайтом оперативной памяти и обычной сетевой картой Gigabit Ethernet без TOE (TCP Offload Engine). Дисковая система была представлена тремя новенькими SATA дисками.

В качестве ОС был выбран CentOS 6.3 установленный на отдельный жесткий диск не задействованный в тестах.
Один из жестких дисков был отформатирован в ext4 и выполнял роль NFS хранилища. Использовался NFS версии 4.
Последний из трех жесткий диск без каких либо приготовлений был полностью экспортирован как iSCSI-Target.
Использовался tgt версии 1.0.24

LVM(Logical Volume Management) использовался только на диске с ОС!

Прмечание: Я специально не акцентирую внимание на марках оборудования и конкретных частотах/оборотах и других характеристиках. В рамках данного тестирования, проводится сравнение двух протоколов относительное друг друга, и выявление создаваемой ими нагрузки на одном и том же оборудовании и тех же задачах.

Безусловно, данная конфигурация не является примером системы хранения даже для домашнего использования. А показатели ее производительности будут больше пугающими чем оптимистичными. Но, для сравнительного тестирования большего, на мой взгляд, ничего и не нужно.

В качестве узла виртуализации был выбран не менее бюджетный, но более производительный сервер с двухядерным процессором, 8 гигабайтами памяти и обычной сетевой картой Gigabit Ethernet без каких либо аппаратных функций.

В качестве ОС использовался Proxmox VE 2.1.

Методика тестирования

Так как в случае с NFS, диски ВМ могут храниться только в виде файлов. А iSCSI-диски могут быть подключены к ВМ напрямую. Было решено создать на NFS хранилище диск ВМ в размер всего хранилища в формате RAW дабы немного уровнять позиции протоколов.

Базовые тесты

На Proxmox-хосте был создана виртуальная машина с установленной ОС Windows Server 2003 Enterprise R2 (образ ее лежал на отдельном хранилище).
К виртуальной машине, в качестве локальных SCSI-дисков были подключены iSCSI-диск на прямую и RAW-файл с NFS-хранилища.

Вначале были проведены синтетические тесты производительности дисков с использованием ПО HD Tune Pro v3.50 внутри ВМ.

Далее были выполнены практические тесты с копированием различного рода данных.

Утилита FIO (Flexible I/O tester)[4]

На сегодняшний день, это, пожалуй, наиболее перспективное средство для тестирования дисковых массивов и систем хранения. В отличии от классического iometer [5], последний релиз которого датируется 2006 годом, FIO активно развивается и совершенствуется. Утилита позволяет гибко описать тесты с помощью конфигурационных файлов, в которых можно задать любые условия.

Для использования FIO, была установлена ВМ с ОС Ubuntu 12.04 к которой были подключены оба тестируемых хранилища в качестве локальных SCSI-дисков.

Конфигурация тестов

Тест на чтение

Запуск: fio read.ini
Содержимое read.ini

[readtest]
blocksize=4k
filename=/dev/
rw=randread
direct=1
buffered=0
ioengine=libaio
iodepth=32

Тест на запись

Запуск: fio write.ini
Содержимое write.ini

[writetest]
blocksize=4k
filename=/dev/
rw=randwrite
direct=1
buffered=0
ioengine=libaio
iodepth=32

Каждый тест был проведен по три раза после чего в таблицу заносилось среднее значение. Тестирование проводились последовательно. Вначале с одним хранилищем, затем с другим. В один момент времени в работе было только одно хранилище! Кроме выполняемых тестов, ни сервер выполняющий функции хранилища, ни узел виртуализации не были заняты другой работой, кроме стандартных процессов ОС.

Результаты тестирования

Результаты FIO

Выводы

Как видно, из сводных таблиц, в большинстве тестов, на одном и том же оборудовании и тех же задачах, iSCSI показывает лучшие результаты производительности. При использовании iSCSI нагрузка на ЦПУ как на хосте, так и у ВМ значительно выше. Такая же ситуация и с нагрузкой на сеть. В тех же задачах, iSCSI генерирует значительно больше трафика чем NFS. В свою очередь нагрузка NFS более равномерная и прогнозируемая.
Отдельно хочется отметить, сильную деградацию производительности NFS при большем количестве операций записи. И хотя в некоторых синтетических тестах на запись, NFS показала лучший результат, время самих тестов, было значительно дольше, чем в случае с iSCSI. В практических же тестах на запись, хорошо видны более высокие показатели iSCSI.

Источник

Какой протокол сетевого обмена имеет лучшую производительность и надежность? [закрыто]

У нас есть настройка, в которой несколько веб-серверов сбалансированы по нагрузке. Мы хотим иметь какое-то сетевое хранилище, доступное всем веб-серверам. Он будет использоваться как место для хранения файлов, загружаемых пользователями. Все работает под управлением Linux.

Должны ли мы использовать NFS, CIFS, SMB, fuse + sftp, fuse + ftp? Существует так много вариантов для протоколов обмена файлами в сети, их очень сложно выбрать. В основном мы просто хотим постоянно монтировать этот один ресурс на нескольких компьютерах. Функции безопасности менее опасны, потому что они не будут доступны в сети нигде, кроме серверов, монтирующих их. Мы просто хотим, чтобы он работал надежно и быстро.

Какой из них мы должны использовать?

17 ответов

NFSv4.1 добавила возможность параллельной NFS pNFS, которая делает возможным параллельный доступ к данным. Мне интересно, какие клиенты используют хранилище, если только Unix-подобный, то я бы пошел на NFS на основе показателей производительности.

В красноватой бумаге хорошая работа, в которой перечислены плюсы и минусы кластера FS против NFS. В принципе, если вам нужно много места для масштабирования, GFS, вероятно, стоит усилий. Кроме того, в примере GFS в качестве примера используется SAN Fibre Channel SAN, но это также может быть легко RAID, DAS или iSCSI SAN.

Наконец, убедитесь, что смотрите в Jumbo Frames, и если целостность данных критическая, используйте контрольную сумму CRC32, если вы используете iSCSI с Jumbo Frames.

У нас есть веб-кластер с 2-мя серверами. Мы пробовали следующие методы для синхронизации содержимого между серверами:

Решение RSYNC было самым простым, но для отображения изменений потребовалось 10 минут, и RSYNC загрузил столько загрузок на серверы, которые нам приходилось зажимать с помощью специального скрипта, чтобы приостановить его каждую секунду. Мы также ограничивались только записью на исходный диск.

SMB (CIFS) имел некоторые проблемы с блокировкой. В частности, изменения в файлах на SMB-сервере не просматривались веб-серверами. SMB также имел тенденцию к зависанию при сбое через сервер SMB.

Наше заключение заключалось в том, что OCFS2 имеет наибольший потенциал, но требует много анализа, прежде чем использовать его в производстве. Если вы хотите что-то прямолинейное и надежное, я бы порекомендовал кластер NFS-сервера с Heartbeat для отказоустойчивости.

Источник

VMFS vs NFS in vSphere

Как-то Diz задал вопрос: «правда ли, что NFS гораздо лучше, чем SCSI для хранилищ в случае одного большого хранилища? Как ситуация изменилась в 6.x?»

Наше путешествие будет включать в себя следующие пункты:

SCSI-очереди

Отлично тема очередей раскрыта тут.

Очередь — это глубина постоянно выполняющихся SCSI-команд.

Допустим, есть команда «прочитай блок №1». Пока блок №1 не будет прочитан, а его содержимое возвращено, данная команда занимает «буфер».

Соответственно, с каждого хоста vSphere до каждого LUN (дискового устройства СХД) есть буфер глубиной 32 команды (может отличаться в разных версиях vSphere у разных HBA).

Поэтому, короткий ответ будет «да» — у одного LUN для виртуализации есть шансы упереться в эту очередь.

Хочу сразу уточнить, что это глубина очереди с одного хоста до одного LUN. Если LUN несколько, и нагрузка на них равномерная, то хост может выполнить большее количество команд без их приостановки.

Типичный вариант «затыкания» в очереди — это очень большой ввод вывод с одного хоста в один LUN (например, несколько тысяч операций ввода-вывода), и не справляющиеся с этим выводом диски.

А что там с NFS

На первый взгляд, NFS-хранилище решает главную проблему SCSI — убирает глубину очереди в 32 на один LUN. Снаружи от хоста до NFS-хранилища подобного «затыка» нет, внутри у сервера глубина очереди сопоставима с SCSI-хранилищами (например, 1024 у HPE’шного рейд-контроллера).

С другой стороны, с балансированием доступа до NFS все несколько неоднозначно. До появления vSphere 6.0 и NFS 4.1 единственным вариантом балансировки нагрузки являлся EtherChannel/LACP, а это, в свою очередь, означало, что от гипервизора до СХД утилизировался один линк.

Также стоит отметить, что NFS-хранилища не предоставляют функционал RDM-дисков.

Если у вас NFS без поддержки функционала VAAI, то вы не сможете создавать толстые VMDK-диски на таком хранилище.

Решает ли скорость протокола?

И да, и нет. Разумеется, обогнать NFS поверх 1Гбит/с сможет даже «черепаший» FC4Gb, который уже давно устарел.

Текущие «топовые» коммутаторы FC поддерживают до 128Гбит/с, Ethernet — до 100Гбит/с. 10Гб/с Ethernet и 8Гб/с FC уже давно стали легкодоступной попсой.

Учтите, что полоса утилизируется только в случае последовательных операций (а это как правило бэкап или восстановление).

Возьмем данные из технической спецификации на массив начального уровня HPE MSA 2050:

Если подытожить, то скорости близкие или превышающие 10Гбит/с вы можете получить либо с SSD, либо с огромной кучи HDD с последовательными операциями ввода-вывода.

С другой стороны, есть ряд исследований, показывающих, что Fiber Channel лучше чем Ethernet (раз, два), если речь идет о достаточно высокой утилизации канала.

vSphere 6.x

В vSphere при использовании одного хранилища VMFS каждый хост будет иметь пресловутую глубину очереди и сможет в нее упереться. Это SCSI и ничего тут не поделаешь.

Так как VMFS кластерная система, она добавляет свои накладные расходы для того, чтобы ее нельзя было повредить одновременной записью.

Соответственно, VMware направляло свои силы в двух направлениях:

Файловая система VMFS поддерживает ее «растягивание» на 32 дисковых устройства (так называемые VMFS-экстенты).

Частично это может помочь, однако управлять размещением ВМ по разным лунам нельзя, так как каждый хост «старается писать» в свою область данных на растянутом VMFS-разделе.

Рекомендации

Начиная эту статью, я хотел яростно обругать NFS-хранилища и сказать, что место им в SoHo.

Но, по большому счету, если вы:

То вам может подойти NFS. Рекомендую иметь NFS с поддержкой VAAI.

Бонусом получите экономию на отсутствии у вас FC-инфраструктуры.

Если же вы хотите остаться на VMFS, то у меня есть ряд общих рекомендаций:

Как в принципе избавиться от этого:

P.S. Коллеги, приглашаю Вас высказать своё мнение в комментариях, поделиться своим опытом.

VMFS vs NFS in vSphere: 7 комментариев

Получилось сумбурно и без реального сравнения, да и смысла в нём не так много, потому что NFS для VMware = NetApp.

> До появления vSphere 6.0 и NFS 4.1 единственным вариантом балансировки нагрузки являлся EtherChannel/LACP
pNFS в ESXi до сих пор не появился, так что балансировку по прежнему надо делать на уровне датасторов, вольюмов и сокетов:
https://cormachogan.com/2018/12/12/nfs-tcp-connections-on-vsphere-revisited/

Впрочем, сам FAS/AFF тоже не выдаст всю производительность на один FlexVol и без VVols тут не обойтись.

Про глубину очереди 32 странно. Вот тут https://kb.vmware.com/s/article/1267 сама Варя говорит, что значения по умолчанию зависят в том числе от производителя HBA и версии ESXi, но ни что не мешает поменять значение Query Depth per LUN на максимальное 64, если у вас только одна виртуалка использует датастор. Т.е. и отличий между разными HBA в общем то нет. А так же для датасторов, которые используются несколькими виртуальными машинами, есть вот эта статья https://kb.vmware.com/s/article/1268. И там максимальная Query Depth уже 256, а для ESXi 6.5 зависит фактически того что может принять СХД и LUN.

Про количество LUN кратное количеству путей и вовсе непонятная рекомендация. Во первых откуда она взялась? Это NetApp для своих СХД рекомендует? Во вторых какие именно пути имеются в виду? Физические от хоста до SAN, физические от СХД до SAN, а может и вовсе логические?

Если уж упомянули про RR и отправке каждого IOPS в новый путь можно было и ссылку привести на оригинал https://kb.vmware.com/s/article/2069356. И еще указать, что это хоть и увеличивает производительность в IOPS, но в то же время слегка поднимает и Latency.

А еще для тех, кто все таки выберет iSCSI, а не FC или NFS есть вот эта вот напоминалка https://kb.vmware.com/s/article/1002598. Ну и не забывать про jumbo frames на всем пути следования IO.

При использовании NFS и нормальных СХД, которые не теряют кэш при отключении электропитания, можно смотреть в сторону использования ассинхронной записи. И не забывать про возможность настраивать размер блока ввода/вывода те же jumbo frames. Подробнее можно почитать например тут http://www.admin-magazine.com/HPC/Articles/Useful-NFS-Options-for-Tuning-and-Management

Что касается vvol, то я бы пока не ставил их в продуктив. Концепция и идея интересная, но как по мне так тонким местом является необходимость в VASA провайдере, без которого ни чего не работает. А еще я пока не видел на рынке решений по построению metro конфигураций для vvol датасторов. Может я конечно и пропустил что-то и кто-то это уже реализовал. В конце концов обычная репликация для vvol вроде как начала появляться.

В одном вы правы. Ситуации, задачи и возможности у всех разные, а значит в каждом конкретном случае нужно смотреть, что и как целесообразнее применять.

A.Vakhitov, с вашим комментарием уже понятнее. Но то, что касается глубины очередей на СХД, то они там в достаточной степени велики. На один порт IO глубина может составлять 1,5-2к (зависит от производителя). И даже в так называемом midrange сегменте есть СХД, где на каждый контроллер может приходиться от одного до нескольких десятков портов.
Вот про сами луны уже интереснее, там все сильно зависит от количества HDD или SSD по которым LUN размазан. Но и это в принципе, как вы и написали, считается и значения там тоже могут достигать вполне себе больших величин.

Сходная рекомендация (2x-3x VMFS-томов на количество путей) есть в этой презентации с VMWorld.
https://cms.vmworldonline.com/event_data/5/session_notes/STO2115BUR.pdf

Добавить комментарий Отменить ответ

What’s New in 3.0.0, November 2021 Release Scheduled Tasks Scheduler feature can be used to run periodic health checks on…

Проверь и расскажи нам!

Будет работать Horizon agent вместе с Direct Connect plгпшт с Windows Server в режиме RDSH, без Connection Server?

Ни разу с таким не встречался, это какой-то корнер-кейс с увеличением сразу на 20 ТБ?

А мы успели не только скачать, но и раскатать на несколько хостов 🙂

Так уже откатили же, даже не скачать.

Я не расист. но после того как VMware стала упралвяться и поддерживаться индусами, стабильность продукта сдохла как бобик.

Источник