Каков вариант использования NAS в массиве хранения среднего и высокого уровня?

Первое, о чем следует подумать, - это то, что если вы запустите файловую систему и протокол совместного использования файлов на своем устройстве хранения (что сделает его NAS), вам не придется запускать его на сервере. Этого можно избежать. Если файловую систему нужно будет использовать совместно с другими серверами и пользователями, этого можно будет избежать.

Если сервер, использующий данные, является единственным сервером, имеющим к ним доступ, вероятно, лучше всего придерживаться протоколов уровня блоков (FC, SAS, iSCSI или FCoE). Основная причина этого заключается в том, что, хотя управление фактической файловой системой для системы довольно простое, протокол для доступа к этой файловой системе по сети может быть запутанным и неэффективным. CIFS крайне неэффективен, а NFS, хотя и более эффективен, чем CIFS, все же намного менее эффективен, чем что-либо на основе SCSI.

Если данные будут совместно использоваться многими серверами, единственным выбором для блока будет среда кластерного типа, в которой все узлы имеют доступ к одним и тем же томам SCSI. Это может быть невозможно. И даже если это так (например, для VMWare), часто есть преимущества в том, что файловая система и протокол обмена файлами обрабатываются чем-то центральным, а не сервером.

Конкретные рабочие нагрузки, при которых имеет смысл использовать NAS:

• VMWare: файловая система VMWare, которую вы устанавливаете на том SCSI на всех устройствах, до последней версии VMWare, не очень хорошо спроектирована и вводит всевозможные ограничения в вашу среду. VMWare изогнулась, чтобы убедиться, что они поддерживают VMDK, размещенные на NFS, и это устраняет необходимость в VMFS для многих магазинов. Тем не менее, могут быть некоторые вещи, которые вы не можете сделать с NFS, что вы можете с VMFS. Я не эксперт по VMWare.
• Hyper-V: новейшая бета-версия гипервизора Microsoft поддерживает NAS, и кажется, что для них приоритетом будет обеспечение его хорошей работы.
• Файловые серверы: домашние каталоги пользователей и общие сетевые ресурсы - идеальное приложение для центрального NAS. В вашем домене на один компьютер меньше, и вы обычно можете объединить множество файловых серверов в один NAS.

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

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

Я использую VMware с NFS примерно 80% времени по сравнению с другими протоколами. Встроенное тонкое предоставление, видимость / прозрачность и отсутствие ограничений по размеру хранилища данных - преимущества по сравнению с предоставлением блочного хранилища одним и тем же хостам. В наши дни разница в производительности при правильном дизайне незначительна. Иногда я могу представить блок и NAS-хранилище в одной среде (в разных сетях). Гибкость имеет значение.

Другие примеры включают организации, которые могут захотеть использовать хранилище, встроенное в протоколы, поддерживаемые их клиентскими машинами, но напрямую используют средства моментального снимка / репликации или резервного копирования SAN. CIFS на стороне Windows, NFS для Unix и недавно я видел дополнения Macintosh / AFP для NexentaStor место хранения.

Преимущество в том, что вы не добавляете еще один слой. Это дает несколько преимуществ:

• Система хранения пытается оптимизировать наблюдаемую схему доступа; если вы добавите посередине другую систему, которая вводит свои собственные кеши, шаблон доступа теперь изменится в зависимости от того, какой алгоритм кэширования там производит, что может быть труднее оптимизировать.
• Правильный диспетчер хранилища имеет резервный кэш записи с батарейным питанием, позволяющий хранить журнал только в ОЗУ. Если другая система обрабатывает уровень файловой системы, она записывает блоки журнала, затем ожидает подтверждения журнала, а затем записывает блоки данных. Сохранение файловой системы на NAS позволяет пропустить этот шаг.
• Диспетчер хранилища оптимизирован для обеспечения высокой пропускной способности. Сомнительно, чтобы обычный файловый сервер мог когда-либо заполнить канал 10 Гбит / с, поэтому это становится узким местом.

Система, которую я помог создать для клиента, имеет скорость 6x10 Гбит / с, идущую на шесть различных коммутаторов, пять из которых распределяют каналы 1 Гбит / с на 30 машин, каждая из которых выполняет рендеринг. Каждая из этих машин сбрасывает файл размером 200 МБ каждые двадцать секунд, что дает среднюю скорость записи в хранилище 1500 МБ / с (на самом деле загрузка записи немного скачка и не совсем предсказуема, поскольку разная сложность сцены приводит к разному времени рендеринга. ).

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

Общая нагрузка ввода-вывода на этом сервере выше, чем скорость шины памяти на самой быстрой материнской плате, доступной в то время, поэтому узкое место было совершенно очевидным. :)