NAS имеет два порта Ethernet 1 Гбит, которые могут быть установлены для Jumbo Packets
Все 5 дисков 7200 об / мин
Это обслуживает большие мультимедийные файлы, такие как необработанные цифровые файлы, фильмы, медиатека iTunes и т. Д.
Принтер, подключенный к сети Ethernet, и различные беспроводные устройства, которые на самом деле не учитывают этот вопрос, поскольку меня больше всего беспокоит возможность подключения и производительность между NAS и Mac.
Все соединения Ethernet выполняются с помощью коротких кабелей Cat 6A (6 или 8 футов - самые длинные, большинство - 3 фута), которые должны легко обрабатывать полосу пропускания.
С NAS и двумя Mac, подключенными к портам Ethernet на маршрутизаторе, я вижу довольно низкую производительность. Кстати, в лучшем случае я не думаю, что видел скорость передачи выше 10 МБ / с, и большую часть времени он может работать в диапазоне 100 КБ. Показания памяти на мониторах производительности NAS не кажутся слишком обременительными, так что это не должно быть проблемой. Быстрый поиск в Google средней производительности 5-дискового RAID 6 содержит отчет от Tom's Hardware, в котором указаны эталонные показатели скорости чтения для массивов RAID 6 с пятью дисками со скоростью около 220 МБ / с, хотя это не так, как у меня. иметь ... Я был бы в восторге от половины этой скорости прямо сейчас, так как это было бы на порядок больше того, что я сейчас вижу.
Я надеялся попробовать использовать Jumbo-пакеты, установив MTU на 9000, чтобы посмотреть, смогу ли я улучшить скорость передачи данных, но поскольку шлюз FiOS ограничивает MTU до 1500, даже если я могу установить MTU на 9000 на Mac и на DS1010 +, это вызывает проблемы с обычным интернет-трафиком, который идет с отброшенными пакетами из-за несовпадения MTU.
Поскольку у меня есть только 25Mb up / down интернета, я полагаю, что не буду жертвовать какой-либо заметной производительностью, если у меня Mac будет подключаться к шлюзу FiOS по беспроводной сети, и попытаюсь найти решение с использованием Ethernet, где я мог бы разговаривать с Mac и NAS друг к другу напрямую. Если это становится узким местом для веб-трафика, я подумал, что мог бы использовать Thunderbolt и добавить два адаптера Thunderbolt-to-ethernet и сохранить соединения Ethernet, которые у меня сейчас есть, для обычного трафика, чтобы поддерживать пропускную способность беспроводной сети строго для беспроводных устройств.
У меня была идея получить гигабитный интеллектуальный коммутатор Netgear ProSAFE GS108Tv2 и посмотреть, смогу ли я подключить Mac и NAS как VLAN (что я не совсем уверен, как это сделать), установить порты на 1000baseT и MTU 9000, и направьте весь дисковый ввод-вывод через ту VLAN на коммутаторе. Я подумал, что мог бы установить IP-адреса Ethernet на трех устройствах в другую подсеть, а затем подключиться к томам NAS, установив статический IP-адрес для порта, который был установлен на 9000 MTU. Но теперь я перебираю себе слова и не уверен, возможно ли это или как это сделать.
Вот что я хотел бы узнать
Кто-нибудь думает, что эта идея может сработать, и я вижу улучшение дискового ввода-вывода между NAS и Mac, или я просто не понимаю, как эти вещи сочетаются друг с другом?
Есть ли лучшие решения, не прибегая к очень дорогим вариантам?
Мой текущий бюджет на это решение практически исчерпан, и я хотел бы попытаться найти решение, которое работает с моим текущим оборудованием. У меня уже есть переключатель, так что это учитывается в исчислении.
Я хотел посмотреть, есть ли способ, чтобы коммутатор имел восходящую связь с маршрутизатором, чтобы компьютеры Mac и NAS могли отправлять 1500 MTU-пакетов на маршрутизатор для сетевого ввода-вывода и отправлять 9000 MTU-пакетов между собой на диск Ввод / вывод через один и тот же порт или мне нужно использовать отдельные порты для разделения трафика?
Если бы я использовал дополнительные адаптеры Thunderbolt-to-Ethernet, я мог бы иметь все шесть портов (2 для каждого Mac и два на NAS), проходящих через коммутатор, настроив три порта для подсети 9000 MTU и 3 порта для 1500 MTU подсети, а затем подключить маршрутизатор к коммутатору, чтобы весь трафик мог проходить через коммутатор, даже если через него проходили пакеты разных размеров?
На данный момент я в значительной степени за пределами моих знаний о сетевом взаимодействии, и я не уверен, что возможно, а что нет, и, если возможно, как это осуществить. Я не боюсь засучить рукава и подправить настройки системы; Я установил статическую аренду DHCP, статические IP-адреса на компьютерах, а также внедрил фильтрацию MAC-адресов, но на данный момент я не уверен, действительно ли то, что, по моему мнению, должно быть выполнимо. Любой совет на данный момент будет принята с благодарностью.
Спасибо
Обновить
Это запуск из теста с использованием iperf3.0.11. Он был запущен непосредственно через порты маршрутизатора шлюза. Я еще не настроил коммутатор, поэтому было проще запустить тест в сети как есть.
Так, как Spiff сказал, узкое место, скорее всего, не с локальными сетями. Таким образом, это делает NAS вероятным виновником ... И, конечно, их страницы поддержки в основном обвиняют сетевой трафик и не обращают внимания на то, как повысить производительность своих серверов или убить все ненужные процессы, которые выполняются без необходимости и требуют до памяти. Или это могут быть диски WD Green ... По-прежнему нет решения, но, по крайней мере, это не Ethernet.
Обновление 2
Вот некоторая дополнительная информация о тестировании с вышеуказанной настройкой. Был создан тестовый файл объемом 2 ГБ, и передача файла была выполнена из командной строки, используя оба диска, смонтированные через smb, и вошли в NAS с помощью ftp .
Using smb Load to NAS $ mkfile -n 2g largetestfile $ mv -v largetestfile /Volumes/network_attached_storage 2.15GB file - 336s Averaged Transfer Rate: 6.4MB/s or 51.2Mbps Download from NAS mv -v /Volumes/network_attached_storage/largetestfile ./Downloads/ 2.15GB file - 40s Average Transfer Rate: 53.75MB/s or 430Mbps Using ftp Load to NAS $ mkfile -n 2g largetestfile ftp> bin ftp> hash ftp> put largetestfile 2147483648 bytes sent in 01:06 (30.74 MiB/s) or ~246Mbps Download from NAS Test 1 (forgot to enter bin command prior to download) ftp> get largetestfile 2147483648 bytes received in 00:42 (48.01 MiB/s) or 384.08Mbps Test 2 (Using bin command) ftp> bin ftp> get largetestfile 2147483648 bytes received in 00:21 (93.97 MiB/s) or 751.73Mbps
Хотя скорость загрузки smb адекватна, скорость загрузки оставляет желать лучшего. Я подумал, что это может быть связано с тем, как данные записывались в RAID, но затем, когда вы загружаете через FTP, скорость в 7 раз выше, хотя все же немного медленнее, чем скорость загрузки.
Вы можете получить пропускную способность TCP через IPv4 по протоколу 943 Мегабит / с по Gigabit Ethernet со стандартными кадрами. Таким образом, гигантские кадры просто позволяют выжать еще 5% эффективности из среды. Если у вас пропускная способность не превышает 100MebiBytes / sec, поместите гигантские фреймы в самый конец списка вещей, на которые нужно посмотреть.
Spiff 8 лет назад
1
@Spiff Добавлены тестовые данные для перемещения командной строки и копирования ftp. Мне было интересно, почему установка bin вдвое сократила время загрузки в ftp. Также интересно, если у вас есть идеи, что происходит с загрузкой smb? Это становится важным для таких вещей, как приложения iTunes и медиа-обновления, так как они хранятся на NAS. Еще раз спасибо за вашу помощь. Кроме того, на CP была локальная резервная копия с NAS на USB через мой Mac для автономной копии ... Я спросил CP о другой проблеме (она затрагивает только одно ядро процессора), и их ответ о пропускной способности состоял в том, что пользователи должны ожидать только на avg для загрузки 10GB / день !!!
AMR 8 лет назад
0
1 ответ на вопрос
2
Spiff
Подключите ваш Mac к гигабитному коммутатору (порты LAN вашего маршрутизатора должны быть в порядке). Запустите IPerf 2.0.x между ними и посмотрите, что вы получите. Это должно быть 930+ Мегабит / сек, даже не пытаясь.
Если вы получаете пропускную способность IPerf TCP в этом диапазоне, то вы показали, что проблема выше уровня Ethernet. Проблема может быть в протоколе передачи файлов (или протоколе удаленной файловой системы), который вы используете, или в плохой реализации клиентского или серверного кода для этого протокола.
Apple сказала, что будущее за SMB2 (а позже ... сейчас v3.x). Убедитесь, что ваш NAS поддерживает это, и смонтируйте его поверх этого протокола (не AFP или старый вариант SMB).
Спасибо! кто-то определенно был шагом в правильном направлении. Synology поддерживает smb3, и когда я перемонтировал, я получил устойчивые скорости около 10 МБ, что, хотя все еще намного ниже того, на что я надеялся, не увидел снижения скорости до диапазона КБ, а при навигации по папкам в Finder все казалось более острым , У меня еще не было возможности запустить анализ iPerf, хотя я все еще задаюсь вопросом, не выиграю ли я от разделения трафика дискового ввода-вывода в VLAN.
AMR 8 лет назад
0
Кстати, я только что прочитал это и ** [это был отличный ответ] (http://superuser.com/questions/270489/about-mtu-settings-in-machines-and-switch?rq=1) ** вы дал и действительно помог мне понять, что происходит. Спасибо за ваш вклад.
AMR 8 лет назад
0
Программное обеспечение Disk Station Management имеет вкладку в разделе сети, где вы можете установить правила для минимальной гарантированной и максимальной пропускной способности для службы. Для Windows Files Service я установил гарантию 200 МБ / с (очевидно, максимально допустимый), а максимальный - 0, что означает неограниченный. Я не знаю, поможет ли это, но есть ли другие сервисы, о которых вы могли бы подумать, которые могли бы воспользоваться этой гарантией, если я монтирую с smb3.0?
AMR 8 лет назад
0
Также имеет ли смысл настраивать разные подсети? Я думал, что одна подсеть будет для дискового ввода-вывода, для интернет-трафика и одноранговых подключений, если я скажу, сделать общий экран другого компьютера в локальной сети?
AMR 8 лет назад
0
@AMR По моим расчетам, ваша скорость 10 МБ / с меньше, чем одна десятая от того, что ваша сеть должна быть способна (112 МБ / с для GigE). Я бы не стал усложнять ситуацию с большим количеством VLAN или большим количеством сетевых соединений, пока не нашел и не исправил нелепое узкое место. Запустите тест IPerf 2.0.x, чтобы приступить к решению проблемы. Используйте Homebrew или MacPorts, чтобы помочь установить его при необходимости. Да, и добавьте `-w 2M` к обоим вызовам IPerf. Кстати, какой марки ваш ключ Thunderbolt Ethernet? Я могу ручаться за хорошую модель Apple, но не могу сказать ни за кого.
Spiff 8 лет назад
0
Адаптер Apple Thunderbolt. Обновил мой пост с результатами тестов iperf .... Не Mac или роутер. За 2,1 ГБ за 20 секунд ... Спасибо за вашу помощь. Если вы знаете кого-то, кто знает, как оптимизировать Synology NAS, вы можете отправить его мне. Попытка установить резервное копирование CrashPlan, и у меня будет много данных для перекачки из NAS в облако за то, что сейчас выглядит так, как будто это будет в ближайшие несколько месяцев ....
AMR 8 лет назад
0
@AMR Рад видеть, что ваш GigE работает на полной скорости. Кстати, накопители WD Green выдерживают пропускную способность быстрее, чем 112 мегабит / с от GigE. SATA-II вашего DS1010 + составляет 3 Гбит / с (примерно 348 МБ / с). Таким образом, диски и шина SATA вряд ли будут узкими местами. Я все еще подозреваю протокол файловой системы (SMB). Я вижу, что DS1010 + поддерживает передачу файлов по FTP и HTTP. Я бы попробовал незашифрованные варианты каждого из них (используя файл с несколькими гигабайтами) и посмотрел, приближаются ли они к 112MiBytes / sec. Файлы FTP и HTTP изрываются так быстро, как их может переносить сырой протокол TCP. SMB может читать только порцию за раз, добавляя накладные расходы.
Spiff 8 лет назад
0
Я попробовал FTP, и это было немного медленнее, чем SMB. Переход от AFP к SMB был улучшением, так что да! На данный момент я считаю, что самым узким местом является CrashPlan. Он использует 448-битное шифрование при создании резервной копии, даже если он находится на локальном внешнем диске, поэтому он, вероятно, не может работать намного быстрее, чем 15-20 МБ / с. Я увеличил выделение памяти для приложения примерно до 4 ГБ, но я могу пойти еще выше ... это может помочь. Мне нужно будет создать большой тестовый файл, когда у меня будет больше времени, чтобы увидеть, какова скорость передачи данных как между передачей данных, так и с NAS через файловую систему. Спасибо еще раз за помощь.
AMR 8 лет назад
0
@AMR. Подождите. Вы все время использовали CrashPlan в качестве эталона производительности и ничего не сказали в исходном вопросе ?? Вы не делали простых копий файлов (перетаскивание Finder или команда `cp`) все это время ?? Когда вы выполняли тест производительности FTP, использовали ли вы команду `ftp` (что я и ожидал), или вы делали что-то глупое, например, монтировали NAS через FTP из Finder (когда фальшивка Finder была похожа на FTP-сервер, диск медленно, как черт), а затем, как сделать резервную копию CrashPlan к этому ??
Spiff 8 лет назад
0
Нет нет. У меня всегда была низкая производительность, но я игнорировал ее до сих пор, потому что мне приходится перекачивать все эти данные в CrashPlan и, если дисковый ввод-вывод будет меньше, чем пропускная способность интернета, то какой в этом смысл? CrashPlan заставил меня попытаться что-то с этим сделать. У меня просто не было возможности протестировать простую копию файла. Я думаю, что вы поняли, что изначально узким местом было AFP. Иногда рендеринг смены каталога может занять минуту. Я думаю, что SMB будет лучше.
AMR 8 лет назад
0
У меня есть широкополосный сервис со скоростью вверх / вниз 25 Мбит / с, поэтому, даже если я смогу получить даже 100 Мбит / с дискового ввода-вывода от NAS, я полагаю, что этого будет достаточно, чтобы получить максимальную выгоду от выхода из двери. Я давно хотел улучшить производительность, но на этот раз я впервые нуждался в этом, поэтому я вкладываю время, чтобы заставить его работать должным образом. Я не могу ничего поделать со скоростью широкополосного доступа, не заплатив дополнительную плату за обслуживание, но могу оптимально настроить локальную сеть. Если у вас есть инструкции о том, как использовать псевдоним FTP как подключенный диск, чтобы CP его видел, я был бы признателен. Еще раз спасибо!
AMR 8 лет назад
0