Первоначально для решения для хранения данных требуется всего несколько ТБ (<10 ТБ).
Мой первоначальный план состоит в том, чтобы иметь NAS с другими серверами, монтирующими данные, хранящиеся на устройстве NAS, выталкивая и извлекая данные из него. Поскольку это будет небольшое развертывание, стоимость SAN не может быть оправдана, а ожидаемый рост пока неизвестен. Так что это будет NAS, но он должен быть расширяемым.
Однако я вижу несколько проблем с этим дизайном;
Во-первых; SMB / CIFS не подходит для нескольких серверов, на которых установлено одно и то же хранилище данных, NFS здесь кажется лучшим вариантом. Хотя, насколько я знаю, это единственный вариант. Это будет собственное развертывание Linux, поэтому доступны ли мне какие-либо лучшие протоколы, кроме NFS, или это мой единственный выбор здесь?
Во-вторых; По мере того, как устройству NAS не хватает емкости ввода-вывода или места, в зависимости от того, что произойдет раньше, необходимо добавить еще одно (и этот процесс будет повторяться). Как я могу подключить еще один NAS к сети и расширить существующий общий ресурс хранилища (насколько это касается просмотра с других серверов), чтобы включить это дополнительное пространство для хранения? Что такое «эквивалент NAS» для добавления еще одного узла хранения в сеть SAN и расширения файловой системы в нем? (Насколько я знаю, это невозможно, но я спрашиваю, если я ошибаюсь!).
Предположительно то, что я описал в приведенном выше сценарии, когда первый NAS выходит на полную мощность, является основным требованием для SAN, это правильно? Будет ли более масштабируемым подходом добавить еще один NAS и заставить серверы монтировать оба общих хранилища, а приложение поддерживать использование нескольких пространств хранения, а не пытаться реализовать постоянно растущее пространство хранения?
SMB / CIFS отлично подходит для нескольких серверов, на которых установлено одно и то же хранилище данных. Это файловая система с множеством одновременных подключений, которая, несмотря на то, что она медленнее и с большей задержкой, чем NFS, прекрасно справляется с большим количеством одновременных подключений. Более серьезной проблемой может быть доступ пользователей, поскольку весь трафик к вашему монтированию CIFS будет проходить от имени пользователя, который аутентифицировал монтирование, в отличие от NFS. В целом, я считаю NFS более надежным решением для обмена файлами между сервером и сервером.
Если вы планируете расширяемость в одном пространстве имен, гораздо дешевле масштабировать, чем масштабировать. Большинство поставщиков предоставляют какие-либо решения для дисковых массивов на основе SAS. Как правило, они могут быть соединены в цепочку, и вы можете запустить на них единую согласованную файловую систему с помощью LVM или аналогичного диспетчера томов (помня, что, если одна дисковая полка выйдет из строя, весь ваш том будет уничтожен, поэтому вам, вероятно, понадобится несколько путей к вашему место хранения). Это, наверное, самое экономичное решение для вас, но вариантов масса. Ваш выбор файловой системы имеет значение, так что имейте это в виду. Я поклонник ZFS на Solaris 11, но ваш выбор будет более разнообразным, если вы посвятите себя использованию бесплатного программного решения.
Если вы твердо настроены на масштабирование, существует ряд параллельных файловых систем, таких как Gluster и Ceph, но они находятся на разной степени зрелости и совместимости, и я бы не рекомендовал их для общего доступа к файлам на данном этапе. точка.
Если вы используете iSCSI, вы можете превратить свой NAS в сеть SAN. После этого используйте его с cLVM и ocfs для одновременного монтирования в ваших системах. cLVM даст вам возможность расширяться по желанию.