Назад | Перейти на главную страницу

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

Я много читал (и испытал) преимущества (быстрая загрузка, быстрый запуск программ, быстрый доступ к файлам и т. Д.) Использования SSD в качестве загрузочного диска на рабочей станции, но не смог найти много полезной информации об использовании SSD для обслуживания файлов по локальной сети. Можно ли ожидать аналогичного прироста производительности или задержка в сети сводит на нет преимущества в скорости? Меня интересуют общие ответы, но, если быть более конкретным, у меня есть сервер самбы в гигабитной локальной сети, где небольшой объем данных (<10 ГБ) - это то, что я бы назвал частым использованием. Большинство файлов имеют размер <5 МБ, и я бы оценил соотношение чтения: записи как 10: 1.

В большинстве случаев не будет заметного повышения производительности за счет использования SSD для простого обслуживания файлов. Вариант использования бы демонстрируют увеличение:

  • Обслуживание больших файлов (> 512 МБ)
  • Эти файлы сильно фрагментированы
  • На 1 Гбит Ethernet

Или

  • Много файлов меньшего размера
  • Доступно примерно в одно и то же время
  • На 1 Гбит Ethernet
  • Сервер Samba имеет ограниченную оперативную память

В этом случае превосходная производительность твердотельного накопителя при произвольном чтении могла бы заполнить сетевое соединение 1 Гбит / с.

В вашем случае прирост производительности будет трудно различить из-за кэширования, выполняемого Samba / Linux.

Причина того, что SSD не такие элегантные, как том ОС, связана с нагрузками ввода-вывода. Большинство операций ввода-вывода файлового сервера на несколько порядков меньше нагрузки ввода-вывода, выполняемой для диска ОС. Конечно, есть исключения, но это общий случай. Когда у вас меньшая нагрузка на ввод-вывод, выигрыш в производительности не так очевиден.

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

Бесполезно работать со скоростью диска сервера, если сетевой стек сервера ужасно сломан и работает медленно, или диск сервера и сетевой ввод-вывод забиты до смерти из-за чрезмерно параноидальных настроек AV на всех ваших LAN-клиентах или коммутатор ужасный (есть гигабит, и есть "гигабит", если вы понимаете, о чем я).

Да и нет. Это того стоит. Но может быть неплохо в качестве тайника. Adaptec поддерживает до 4 SSD на контроллере (поддерживает около 250 дисков) в качестве кэшей чтения и заявляет о 5-кратном улучшении производительности при определенных условиях.

Это зависит от местонахождение доступа к данным. Если ваши клиенты получают доступ к набору данных, которые в основном могут быть кэшированы в ОЗУ, SSD редко должен показывать преимущества. Однако, если существует тяжелый случайный доступ к данным, вращающиеся диски вашего файлового сервера могут легко стать узким местом. Задержка поиска диска намного выше задержки сети. Вы должны рассчитать, сколько операций ввода-вывода в секунду может выполнить ваша текущая настройка диска, а затем использовать такой инструмент, как sysstat, чтобы определить, достигали ли вы этого предела исторически. Ник Андерсон есть отличная статья о том, как это сделать. Для интерактивного мониторинга использования диска и сети в реальном времени, наверху это фантастический инструмент.