Что такое Лучшая инфраструктура серверов хранения? DAS/NAS/SAN или установка GlusterFS/LUSTER/HDFS/RBDB

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

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

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

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

• А) Оригинальный источник данных, например, интернет.
• Б) Ваш сервер.
• В) NAS.
• D) элемент списка клиентов

Тогда есть 4 возможных вектора данных

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

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

Поэтому вам нужно учитывать пропускную способность чтения и записи в NAS, если вы используете NAS. Если вы используете FC SAN, вы можете уменьшить свои сетевые потребности и получить другие преимущества.

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

Вы можете уменьшить стоимость SAN, не используя оптоволоконный канал, например, вы можете использовать iSCSI. В этом случае вам снова понадобятся отдельные сети для ваших данных, и вам понадобятся выделенные сетевые карты, в идеале с разгрузочным оборудованием tcp / iSCSI. Это даст вам большую часть преимуществ сети 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, при прочих равных условиях, чем больше шпинделей, тем лучше.

Я бы пошел на архитектуру на основе DAS. Проблема в том, что в какой-то момент файловая система не имеет значения - вопрос, учитывая конкретное требование ввода-вывода, сколько ГБ вы можете поместить в определенную стоимость инфраструктуры (размер, мощность) по лучшей цене.

• SuperMicro имеет специальные случаи, которые занимают до 48 жестких дисков. Они не дешевые, но на основе SAS.
• Вы, вероятно, должны пойти с приличным контроллером SAS для тех.
• Мощность процессора также может быть проблемой, как и память. Если у вас около 40000 ГБ в коробке, то для кеширования может потребоваться около 8 ГБ оперативной памяти;)

Итак, в конце я бы выбрал довольно приличный двухпроцессорный сервер AMD на специальной установке корпуса, которая может обрабатывать МНОГО дисков в специализированной клетке.

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