Я пытаюсь разработать инфраструктуру для проекта, над которым работаю. Это будет каким-то образом проект обмена / загрузки файлов (например, rapidshare), и мне потребуются большие размеры хранилища и хорошая масштабируемость, и я бы добавил новые узлы хранения после того, как мой проект вырастет.
Я придумал 3 решения для своего проекта, которые используют Lustre, GlusterFS, HDFS, RDBD.
Для начала у меня было бы 2 сервера, один сервер для клиента glusterfs + веб-сервер + сервер db + сервер потоковой передачи, а другой сервер - узел хранения gluster. (Через какое-то время я бы добавил больше узловых серверов и клиентских серверов (не знаю, сколько новых клиентских новых серверов добавить, увидим позже)
Итак, я думаю поработать с glusterfs. Но мне действительно интересно, придется ли мне использовать высокопроизводительные серверы с большим объемом памяти или средние / медленные серверы с большим объемом хранилища? Или решения nas / das / san лучше для узлов хранения glusterfs? Я мог бы купить NAS и установить на него glusterfs. Буду рад выслушать ваши рекомендации по свойствам сервера (для каждого клиента и узла). Я действительно не знаю, действительно ли мне нужно большое количество оперативной памяти и хороший процессор для узлов. Я уверен, что он мне нужен для клиентских серверов.
Файлы также будут передаваться в потоковом режиме, поэтому важна автоматическая репликация файлов, поэтому моя система должна работать как облако, при необходимости из-за высокого трафика узлы хранения должны копировать наиболее востребованный файл для потоковой передачи и помогли бы мне. чтобы избавиться от проблем с масштабируемостью, и мои посетители смогут транслировать / скачивать эти файлы.
Кроме того, я открыт для вашего опыта / мыслей о любом хорошем решении. Lustre, hdfs, rbdb - это другие варианты, и я буду рад выслушать ваши мысли здесь. Я был бы очень рад получить ответ от любого, кто прокомментировал бы любые слова, которые я здесь использовал.
Спасибо
Редактировать:
Я знаю, что IOPS - это критическая переменная, на которую я должен рассчитывать при каждом вычислении моей сети, поэтому я говорю о случайных запросах. Но, к сожалению, статистики у меня вообще нет. Вот почему я здесь :)
Мой проект такой: вы вводите URL-адрес загрузки на мой веб-сайт, мой URL-адрес загружает его, и вы начинаете загружать его с моего собственного сервера, как загрузчик прокси.
Итак, у меня есть подключение к серверу 100 Мбит и жесткий диск 2 ТБ. Я думаю добавить NAS-серверы. На самом деле не знаю, нужно ли добавлять дублированные узлы хранения в nas. И есть ли ограничение на то, что я могу подключать устройства NAS? Я имею в виду, что я могу подключить максимум 2 сервера NAS к моему основному серверу?
Ваши вопросы нетривиальны, и информации недостаточно, чтобы дать хороший ответ. Я могу дать ответ (кластерная файловая система по волоконно-оптическому каналу SAN), но это может оказаться более дорогим и сложным, чем должно быть.
Так что я просто выкину несколько комментариев / мыслей. Действительно, вам стоит задуматься. Возможно, прочитав эту дамп мозга, вы сможете заново сформулировать предполагаемое поведение вашего приложения, и, возможно, тогда мы сможем дать вам лучший ответ.
Устройства NAS экспортируют файловые системы (например, CIFS, NFS), поэтому вы на самом деле не подключаете их к своим серверам - ваши серверы монтируют файловые системы из них. Это означает, что чтение и запись в них должны проходить через ваше соединение. Итак, если у вас есть 100-мегабитное сетевое соединение между вашим NAS и вашим сервером, и ваши чтение / запись происходят в соотношении 1: 1, то лучшее, что вы получите, - это 50-битные чтения, потому что для каждого прочитанного байта вы также пишете байт . Если ваш клиентский трафик и загружаемый трафик находятся в той же сети, вы можете снова уменьшить его вдвое. Понятно, что если вы хотите использовать NAS, вам понадобится несколько сетевых карт на ваших серверах и несколько сетей / VLAN в вашей архитектуре.
Предполагая, что в вашем приложении есть 4 возможных местоположения данных.
Тогда есть 4 возможных вектора данных
В зависимости от того, как работает ваше приложение, и игнорируя накладные расходы протокола, вам может (в худшем случае) потребоваться 4 сети по 100 Мбит / с для передачи 100 Мбит / с вашим клиентам.
Поэтому вам необходимо учитывать пропускную способность чтения и записи в NAS, если вы используете NAS. Если вы используете FC SAN, вы можете уменьшить потребности в сети и получить другие преимущества.
Например. В зависимости от ОС и файловой системы, которую вы в конечном итоге будете использовать, SAN позволит вам динамически увеличивать ваши LUN и увеличивать ваши файловые схемы в реальном времени, а также совместно использовать LUN с большим количеством хостов, опять же потенциально в режиме реального времени.
Вы можете снизить стоимость SAN, не используя оптоволоконный канал, например вы можете использовать iSCSI. В этом случае вам снова понадобятся отдельные сети для ваших данных, и вам понадобятся выделенные сетевые адаптеры, в идеале с оборудованием для разгрузки tcp / iSCSI. Это даст вам большинство преимуществ SAN при более низкой стоимости.
Я на самом деле не использовал iSCSI, за исключением самого простого одиночного LUN для одного хоста с простыми Linux LVM и ext3, поэтому я не уверен на 100%, действительно ли он так же хорош, как FC SAN, но я полагаю, что это может быть, если хорошо реализовано.
Массивы SAN, вероятно, являются лучшим выбором, если вы собираетесь использовать кластерную файловую систему. Вопрос в том, действительно ли вам нужна кластерная файловая система? Это будет зависеть от характеристик вашего приложения и вашей архитектуры.
Теперь, если ваше приложение может гарантировать, что только узел node будет записывать в данный файл в данный момент времени, вы, вероятно, можете перейти на NAS. Но у вас могут возникнуть проблемы, если вы измените файл на одном хосте, когда он читается на другом хосте, поэтому вашему приложению потребуется обнаруживать и обрабатывать этот сценарий. Если это сценарий, о котором вы не хотите беспокоиться, то кластерная файловая система, вероятно, является лучшим выбором - они предназначены для работы с таким сценарием.
Поэтому вопросы, подобные некоторым из перечисленных ниже, могут иметь большое значение для вашей архитектуры:
Учитывая ограниченность информации, которая у нас есть, я бы сказал, что самая безопасная архитектура - это самая дорогая и сложная архитектура, поскольку она решит большинство проблем наихудшего случая и будет очень масштабируемой. Т.е. Fibre Channel SAN и кластерная файловая система.
Во всех случаях, независимо от вашего хранилища, DAS, SAN, NAS, при прочих равных, больше шпинделей лучше.
Я бы выбрал архитектуру на основе DAS. Проблема в том, что в какой-то момент файловая система не имеет значения - вопрос в том, с учетом конкретных требований ввода-вывода, сколько ГБ вы можете вложить в определенную стоимость инфраструктуры (размер, мощность) по лучшей цене.
Итак, в конце я бы выбрал довольно приличный двухпроцессорный сервер AMD в специальном корпусе, который может обрабатывать МНОГО дисков в специализированном отсеке.
При этом Cluster, вероятно, настолько хорош, насколько это возможно, если вам не требуется сверхбыстрый доступ к диску, типичный для больших баз данных. Он должен делать большую часть того, о чем вы просите. Но как только вы приступите к работе, сохранение небольшой цены за гигабайт может оказаться самым важным - без чрезмерных административных расходов.