У меня есть приложение SaaS, работающее на 6+ серверах в HPCloud, которое создает большие объемы данных (ГБ / ТБ). Пользователи общаются с приложением через RESTful api, который отвечает ссылкой на наш CDN, откуда они могут скачать свой файл.
Мои вопросы:
Исходя из моего исследования и предыдущего вопроса о SF, хранение всех сгенерированных данных в каком-либо централизованном хранилище (например, через NAS / SAN) было бы лучшим решением, поэтому мой CDN всегда знает, где файлы должны обслуживаться, что также обеспечить лучшее масштабирование в будущем. Поскольку я нахожусь в облаке, похожем на Rackspace, что я могу сделать?
Для моей справки, как компании, такие как mediafire, одновременно хранят TB / PB данных и LB своих загрузок? У них просто тонны серверов, подключенных к одному NAS / SAN?
Данные, запрошенные Ablue:
Вы создаете файлы для обслуживания по http? Да, эти файлы будут в основном загружены через HTTP
Вам нужно хранилище на уровне блоков? Не сейчас, но в будущем это может произойти
СКОЛЬКО ХРАНЕНИЯ ВЫ ХОТИТЕ? В настоящее время я могу обойтись без ~ 300 ГБ, но в будущем мне нужно будет масштабировать
Какие скорости доступа вам нужны / нужны? Чем быстрее, тем лучше для записи, но время чтения не имеет большого значения. Главное здесь то, что использование такой системы, как S3, увеличивает задержку из-за того, сколько времени может занять копирование данных.
У тебя есть бюджет? Да / Нет ... для облака, в котором я нахожусь, я могу развернуть еще 3-5 серверов с объемом хранения около 120 ГБ каждый
1) В облаке не так много дешевых вариантов, если вы не хотите использовать систему, подобную S3. С централизованной системой вы можете масштабироваться только до тех пор, пока не начнете сталкиваться с проблемами (см. Раздел «Увеличение или уменьшение масштаба»), поэтому, если вы развертываете собственное решение, вам, вероятно, лучше всего будет начать с распределенной системы, которая позволяет добавлять и удаляйте серверы по запросу, вместо того, чтобы просто получать большой SAN и продолжать добавлять диски.
2) Они почти наверняка будут использовать выделенное оборудование, совмещенное или в частных центрах обработки данных. Если вы пойдете к поставщику хранилища и скажете: «Эй, я хочу купить 2000 дисков», они дадут вам довольно приличные скидки, если вы знаете, что делаете. Хранение 100 ТБ данных всегда будет дешевле (за ГБ), чем хранение 100 ГБ. Чем больше вы храните, тем дешевле это становится.
Взгляните на распределенное хранилище данных, такое как HFS или Riak. Никогда не использовал HFS, но мы используем кластер Riak на 4 узлах с 10 ТБ памяти. RIAK имеет HTTP API, поэтому после небольшой тщательной настройки вы можете просто указать свой CDN на свой кластер Riak. В качестве альтернативы просто используйте S3, облачные файлы RackSpace, Google Storage и т. Д., И пусть кто-то другой позаботится об этом за вас. Поскольку существующие поставщики хранилищ уже используют хранилище размером несколько ТБ / ПБ, они, скорее всего, могут сделать это дешевле, чем вы могли бы развернуть собственный.
Что, как говорится, BackBlaze (компания по онлайн-резервному копированию) «открыла исходный код» для своих «модулей» хранения, которые очень дешево хранят невероятные объемы данных.. Они больше подходят для того, чтобы «один раз написать, годами сидеть и ничего не делать», как это характерно для резервных копий, но это все же интересное чтение. Вы также можете изучить что-то вроде Серверы хранения BroadBerry, их топовая модель имеет 36 отсеков для дисков с горячей заменой, но стоит + 5 тысяч долларов без дисков (если вы заполните их корпоративными дисками 7200 об / мин емкостью 2 ТБ, на которые вы смотрите, скорее всего, 25 тысяч долларов, или с дешевыми дисками 15 тысяч долларов, что полностью зависит от вашей рабочей нагрузки. ). OVH предоставьте несколько «резервных» серверов с ~ 20 ТБ хранилища без RAID по цене около 200 фунтов стерлингов в месяц, если я правильно помню.
Вам также нужно подумать об многоуровневом хранилище. По сути, это означает, что вы разделяете данные на «уровни» в зависимости от того, что вам нужно. Если некоторые из ваших объектов необходимо сохранить любой ценой и к ним нужно быстро получить доступ, они должны быть на верхнем или «золотом» уровне хранилища с быстрыми и надежными дисками, на серверах, хорошо оборудованных, чтобы справиться с нагрузкой. Это может быть что-то вроде того, что вы бы поставили на high-end SAN с множеством прекрасных SAS или даже SSD-дисков. Если у вас есть объекты, которые можно повторно генерировать и к которым не требуется быстрый доступ (скажем, эскизы изображений, которые обычно кэшируются на краях CDN), вы можете поместить их в хранилище «серебряного» уровня; более дешевые диски, на более медленных серверах. Затем у вас есть резервные копии, хотя они могут вам никогда не понадобиться, и они могут не быть доступны немедленно, вы хотите хранить их как можно дольше и как можно дешевле. Вы можете положить их на «бронзовое» хранилище, как ленты.
Уровни хранения, которые я описал, предназначены для чисто вымышленной ситуации, вполне возможно иметь 50 уровней хранения, и вы можете называть их как хотите. Может случиться так, что даже самый низкий уровень хранилища требует сверхбыстрого доступа, все зависит от вашего использования.
Важно знать, к каким файлам и как нужно получить доступ.
Когда люди хотят хранить большой объем данных с низкой задержкой и высокой скоростью, обычно используется SAN. Fibre Channel часто используется для максимально возможной задержки, но iSCSI и NFS также работают очень хорошо. Очевидно, вы не можете подключить оптоволокно к VPS, а iSCSI и NFS лучше всего работают, когда изолированы (отдельные сетевые адаптеры и VLAN) и с самым большим MTU, с которым вы можете справиться, поэтому VPS здесь не подходит.
В этом сценарии вам нужно будет разместить свои собственные физические серверы.
Все это при условии, что это требование для файлов, к которым вам нужно получить доступ, и при условии, что вы не просто покупаете дополнительное хранилище у своего провайдера.
Вам действительно нужно по крайней мере решить вышеперечисленные вопросы, прежде чем вы сможете начать вдаваться в подробности.
Изменить (ответ на редактирование вопроса):
Вы упомянули балансировку нагрузки. Если вы используете собственное оборудование, вы, вероятно, захотите использовать какой-то ACTIVE: ACTIVE HA Cluster.
Предложение Сэма об использовании RAIK - действительно хорошая идея, учитывая ваши критерии.
Лично я считаю, что если вы собираетесь инвестировать в оборудование и размещение, у вас должен быть твердый план того, как вы хотите или ожидаете роста; это должно помочь предотвратить инвестирование в неправильные области.
На этом этапе игры вы можете согласиться с предложением Сэма, еще одна мысль может заключаться в покупке нескольких VPS, расположенных в местах по всему миру, где вы ожидаете вашего использования, каждый с необходимым хранилищем (300 ГБ должно быть довольно недорого); затем реплицируйте данные между ними. Вы можете использовать DNS для балансировки нагрузки, используя циклический перебор или что-то более сложное, если хотите (реферал по геолокации или что-то в этом роде). Расширение хранилища для VPS довольно безболезненно.
Запуск собственного оборудования на этом этапе будет чрезвычайно дорогостоящим с небольшой выгодой. Когда / если вам нужно хранилище tb / pb, возможно, пришло время инвестировать в оборудование, и в этом случае вы просто покупаете оборудование, чтобы обеспечить то, что вы в настоящее время размещаете.