Каков вариант использования NAS в массиве хранения среднего и высокого уровня?
Многие крупные поставщики систем хранения (EMC, NetApp и т. Д.) Предоставляют оборудование для хранения данных, которое поддерживает NAS в дополнение к FCP, FCoE или iSCSI.
Когда было бы целесообразно использовать функциональность NAS этих блоков? В условиях SMB NAS является более дешевой заменой с меньшими накладными расходами на управление файловым сервером, но почему кто-то, кто может позволить себе VNX, не просто отображает хранилище на уровне блоков на файловый сервер и разделяет его таким образом? В чем преимущество использования компонентов NAS этих устройств напрямую?
3 ответа
Преимущество возникает, когда вы поддерживаете решения, которые могут плохо работать с блочным хранилищем, или если стоимость надлежащей инфраструктуры FC непомерно высока.
Представьте себе большое распределенное приложение в высокопроизводительной вычислительной среде. Скажем, 1000 вычислительных узлов. NFS может быть идеальным для данных приложений, потому что стоимость каждого порта низкая, она масштабируется и надежна. У iSCSI были бы дополнительные накладные расходы и управленческие усилия. Оптоволоконный канал потребовал бы выделенной инфраструктуры и имел бы высокую стоимость на порт. Тем не менее, приложение может извлечь выгоду из IOPS, емкости или возможностей горизонтального масштабирования массива среднего или высокого уровня.
Я использую VMware с NFS около 80% времени по сравнению с другими протоколами. Собственное тонкое предоставление, видимость / прозрачность и отсутствие ограничений на размер хранилища данных являются преимуществами по сравнению с представлением блочного хранилища одним и тем же хостам. Различия в производительности в наши дни незначительны при правильном дизайне. Иногда я могу представить блочное хранилище и хранилище NAS в одной среде (в разных сетях). Гибкость имеет значение.
Другие примеры включают организации, которые могут захотеть использовать хранилище, встроенное в протоколы, поддерживаемые их клиентскими компьютерами, но использовать средства моментального снимка / репликации SAN или средства резервного копирования напрямую. CIFS на стороне Windows, NFS для Unix, и я недавно видел дополнения Macintosh/AFP для хранения NexentaStor.
Первое, о чем нужно подумать, это то, что если вы запустите файловую систему и протокол обмена файлами на своем устройстве хранения (сделав его 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.
Преимущество в том, что вы не добавляете еще один слой. Это имеет несколько преимуществ:
- Система хранения пытается оптимизировать для наблюдаемого шаблона доступа; если вы добавите в середину другую систему, которая вводит свои собственные кэши, то схема доступа теперь изменится на то, что производит алгоритм кэширования, который может быть более трудным для оптимизации.
- У надлежащего менеджера хранилища есть кэш записи с резервным питанием от батареи, позволяющий хранить журнал только в оперативной памяти. Если другая система обрабатывает уровень файловой системы, она записывает блоки журнала, затем ожидает подтверждения журнала, а затем записывает блоки данных. Сохранение файловой системы на NAS позволяет пропустить этот шаг.
- Диспетчер хранилища оптимизирован для высокой пропускной способности. Сомнительно, чтобы обычный файловый сервер мог когда-либо насытить ссылку 10 Гбит / с, поэтому это становится узким местом.
Система, которую я помогал создать для клиента, имеет 6x10 Гбит / с с шестью различными коммутаторами, из которых пять распределяют ссылки 1 Гбит / с на 30 компьютеров, каждый из которых выполняет работу по рендерингу. Каждая из этих машин сбрасывает файл размером 200 МБ каждые двадцать секунд, что дает среднюю скорость записи 1500 МБ / с в хранилище (на самом деле нагрузка при записи немного скачкообразна и не вполне предсказуема, поскольку разная сложность сцены приводит к изменению времени рендеринга.).
Между ними другие машины читают эти файлы, объединяя их в постоянный видеопоток, который затем передается аппаратному кодеру, и полученный поток записывается обратно в хранилище в отдельный раздел.
Общая нагрузка ввода-вывода на этом сервере выше, чем скорость шины памяти на самой быстрой материнской плате, доступной в то время, поэтому узкое место было вполне очевидным.:)