Ограничение уровня сквида

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

Таким образом, я просто выведу некоторые комментарии/мысли. Действительно материал для Вас для рассмотрения. Возможно, после чтения этой "разгрузки мозга", Вы сможете вновь заявить о намеченном поведении своего приложения, и возможно затем мы можем дать Вам лучший ответ.

Устройства NAS экспортируют файловые системы (например, CIFS, NFS), таким образом, Вы действительно не подключаете их к своим серверам - Ваши серверы монтируют файловые системы от них. Это означает чтения и пишет в них, должен пробежаться через Ваш соединение. Таким образом, если у Вас есть сетевое соединение на 100 Мбит между Вашим NAS и Вашим сервером, и Ваше чтение-записи происходит в 1:1 отношение, затем лучшими, которые Вы получите, являются чтения на 50 Мбит, потому что для каждого байта Вы читаете, Вы также пишете байт. Если Ваш клиент и трафик загрузки находятся в той же самой сети затем, можно разделить на два его снова. Очевидно, если Вы хотите использовать NAS затем Вы собирающийся хотеть несколько NICs в Ваших серверах и СЕТИ/VLAN мультиэлемента растра в Вашем architecure.

Принятие там является 4 возможными местами данных в Вашем приложении.

• A) Источник данных Orignal, например, Интернет.
• B) Ваш сервер.
• C) NAS.
• D) клиентский элемент списка

Затем существует 4 возможных вектора данных

• AB т.е. данные загружают с (сеть) к B (Ваш сервер).
• До н.э т.е. запись данных от Вашего сервера до NAS.
• Данные чтения CB с NAS на Ваш сервер
• Данные записи BD от Вашего сервера до клиента

В зависимости от того, как Ваши работы приложения и протокол игнорирования наверху Вы можете (худший случай) затем нуждаются в 4 сетях на 100 Мбит для переноса 100 Мбит в секунду клиентам.

Таким образом, необходимо будет рассмотреть чтение и пропускную способность записи к NAS при использовании NAS. При использовании SAN FC, можно уменьшить сетевые потребности, и Вы получаете другой advatangges.

Например, В зависимости от ОС и файловой системы Вы заканчиваете тем, что использовали, SAN позволит, Вы, чтобы вырастить Ваши LUN динамично и вырастить Ваш filessyems живете, а также совместно используете LUN wth больше хостов, снова потенциально как живая операция.

Можно уменьшить стоимость SAN, не используя волоконно-оптический канал, например, Вы могли использовать iSCSI. В этом случае Вы снова захотите отдельные сети для своих данных, и Вы захотите выделенный NICs, идеально с tcp/iSCSI разгружают аппаратные средства. Это даст Вам большинство advatnges SAN с более низкой ценой.

Я действительно не использовал iSCSI кроме для самого основного единственного LUN к единственному хосту, с простым Linux LVM и ext3, таким образом, я не на 100% уверен, собираюсь ли он СИ, действительно столь же хорошая как FC SAN, но я, это может быть, если хорошо реализовано.

Массивы SAN являются, вероятно, лучшим выбором, если Вы собираетесь использовать кластерную файловую систему. Вопрос - Вы, действительно нуждаются в кластерной файловой системе? Это будет зависеть от характеристик Вашего приложения и Вашей архитектуры.

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

Таким образом, вопросы как некоторые из них упомянутых ниже могли бы иметь большое значение к Вашей архитектуре:

• Файл должен быть снова использован снова после того, как он был загружен однажды и отправлен клиенту - т.е. он мог бы быть перечитан от устройства хранения данных и подан другому клиенту?
• Файл должен быть записан полностью в устройство хранения данных, прежде чем это будет отправлено клиенту?
• Файл может храниться на локальном диске на сервере и подаваться клиенту от локального диска и затем записать в NAS/SAN после того, как он был подан клиенту?
• Несколько клиентов, вероятно, будут использовать тот же файл сразу? Например, это, вероятно, что 50 клиентов получат доступ к одному файлу, или 50 клиентов получат доступ к 50 различным файлам.
• Если 50 клиентов каждый запрос тот же файл, это будет загружено однажды или 50 раз?
• Если другой клиент приедет 3 часа спустя и запросит тот же файл, то файл будет загружен снова, или он прибудет из диска?
• Действительно ли диск является кэшем или медленным буфером?
• Там будет любая другая обработка, выполненная на файле, прежде чем это будет возвращено а клиентам, например, просканированной безопасности, переписали URL и т.д.

Учитывая ограниченную информацию, которую мы имеем, я сказал бы, что самая безопасная архитектура является самой дорогой и сложной архитектурой, поскольку это будет иметь дело с большинством худших проблем случая и будет очень масштабируемо. Т.е. Fibre Channel SAN и кластерная файловая система.

Во всех случаях вообще Ваше устройство хранения данных, DAS, SAN, NAS, при прочих равных условиях больше шпинделей лучше.