Загрузка файлов на разные серверы, диски. Структура, ахритектура

флоппик

promotor fidei
Команда форума
Партнер клуба
интересен алгоритм выбора сервера отдачи (или куда грузить контент):
- либо по странам, регионам
А у тебя сервера на отдачу разбросаны терреториально, или стоят в одной серверной?
 

dimagolov

Новичок
флоппик, в общем случае надо расчитывать на то, что сервера будут разбросаны территориально, так как при масштабировании может потребоваться иметь несколько распределенных площадок.
 

dimagolov

Новичок
флоппик, у моих знакомых конкретный случай сети отдачи видеоконтента и они его хранять на самых дефолтных выделенных хостингах с винтами по 300 гиг и для масштабирования просто заказывают новые машины у хостеров (разных). А диспечер контента раскидывает файлы по нескольким таким нодами одновременно для:
а) возможности масштабировать производительность одновременной отдачи одного и того же файла
б) резервирования на случай преждевременной кончины ноды
в) равномерного заполнения дисков нод
кол-во хранимых копий зависит и от популярности контента ради п. а).
 

dimagolov

Новичок
MiksIr, это про описанную мной систему хранения? какие у тебя к ней замечания? такая схема была выбрана из соображений:
а) из экономической целесообразности так как использует самые стандартные и значит доступные и дешевые компоненты
а) возможности масштабирования от нуля и до очень существенных величин как по объему контента так и по кол-ву пользователей практически незвисимо от окружения, то есть нет никакой привязки к конкретной площадке

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

MiksIr

miksir@home:~$
Несомненно, набирать в аренду сервера у разных провайдеров офигенно как экономически выгодно ;)
 

dimagolov

Новичок
MiksIr, не понимаю иронии. а какие предложения? строить хранилище и кластер для отдачи по цене за мегабайт (даже без учета кластера) на порядки выше? счет то идет почти сразу на терабайты и за хранилище надо было сразу отвалить в несколько раз больше бабла чем за набор блейдов. при этом хранилище жестко централизует архитектуру и имеет предел масштабируемости хотя бы на уровке канала, через который будет отдаваться контент. кстати, у гугла тоже распределенная сеть хранения, правда на более высоком уровне реализации, но у них и объемы побольше. или ограничиться одним провайдером хостинга? ради чего? чтобы теоретически быстрее перетаскивать контент между нодами но все равно рано или поздно упереться в канал площадки?

-~{}~ 06.11.08 13:09:

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

MiksIr

miksir@home:~$
Да, да.. я слышал, гугл на днях еще взял три дедика у мастерхоста и пару VPS еще где-то. А что делать, индекс поисковый растет...
Какие-то блейды всплыли... пропускная способность канала... мдя.
Географическая распределенность имеет смысл для приближения контента к потребителю. Например, стали активно видео качать из Ебурга - выносим туда зеркало. В случае фотохостинга тут даже не зеркало, а хранилище для фоток пользователей из ебурга (логично предположить, что в большинстве своем там и основные потребители будут). В случае продажи кина, к примеру, делать зеркало накладно - имеет смысл выносить на такие географические точки горячий контент только.
Ну когда совсем все хорошо будет, можно полный миррор в разных ДЦ сделать, но это уже другая песня.
А размазывать вот так вот все серверами по разным ДЦ, да еще не своими серверами... как малобюджетный старт разве что сойдет, и то не вижу смысла по разным ДЦ разбрасывать.. разве что если только экономить на качестве ДЦ и не палица сильна трафиком. Но, блин, всерьез строить сервис на такой схеме... вот это по-русски ;)
 

dimagolov

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

MiksIr

miksir@home:~$
dimagolov, а завязывать свои бизнес-процессы (в которых закладываются простои любой железки) на качество обслуживания хостеров... Да и потом, поинтересуйтесь, сколько в нормальных дц стоит SLA хотя бы на что-то менее 24-х часов простоя.
Как это нормально делается? Да очень просто - в каждом ДЦ - свой зип. Первичное обслуживание произвести может и персонал ДЦ или любой другой интегратор имеющий в данном месте территориальное представительство.
А уж о сложностях централизации зоопарка из разных провайдеров на всех этапах - от бухгалтерии до общения с тех службой... даже думать не хочется.

-~{}~ 06.11.08 20:17:

Автор оригинала: dimagolov
использование стандартных компонент вместо уникальных так же дает выигрыш и в надежности, так как надежность конкретных стандартных компонент доказана опытом их широкого использования а не расчетами. ну и чем проще компонент, тем он надежнее.
Это ты чего это щас такое умное сказал?
 

dimagolov

Новичок
да никто не спорит, что по-русски. бизнес в Канаде, ориентирован на бывших наших и разработан и развит ими же.

просто пока ты по существу ничего не возразил, чем такой подход к маштабируемости плох.

полный миррор никто не делает, для разного по популярности контента кол-во копий и распределение варьируется
 

MiksIr

miksir@home:~$
Мдя, чем проще компонент, тем надежнее! Даешь велопробег Москва-Владивосток ;)
 

dimagolov

Новичок
странные у тебя аргументы. "можно организовать качественное обслуживание техники в ДЦ". ну и что с того, что ты считаешь, что это возможно? если ты не ответил на вопрос зачем это нужно, если сдохший стандартный тазик меняется на другой такой же (всегда имеющийся в запасе у хостера) в течении пары часов и на систему в целом это никак не влияет, просто на новый тазик заливается нужный контент и как только он там появляется, то он включается в доступный пул отдачи контента.
 

MiksIr

miksir@home:~$
dimagolov, вам хостер гарантирует, что у него есть этот другой такой же? Он подписывается под этим через SLA? Нет. Вот в этом и отличие.

Тезисно если, почему фигня
1. Дешево только на самом старте, потом - дорого, а потом - песец как дорого.
2. Неоправдано - масштабирование ради мастштабирования, а не ради решения конкретных проблем надежности и скорости доставки.
3. Плохоуправляемо - очень скоро все силы уйдут на взаимодействие с хостерами, а не развитие.
4. Избыточно - мульон серверков всегда хуже десятка нормальных серверов (в т.ч. из-за п.1, п.2, п.3)
 

dimagolov

Новичок
Мдя, чем проще компонент, тем надежнее!
Если ты утверждаешь обратное, то докажи, что бензопила надежнее и ремонтопригоднее топора, или что газонокосилка ручной косы.

-~{}~ 06.11.08 13:32:

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

MiksIr

miksir@home:~$
Вспомнилось "- А чего топором то лес валишь, бензопилой же быстрее гораздо! - Некогда мне с ней разбираться, лес надо валить!" =)
Но вообще, дурацкая аналогия. Хотите другую? Что надежнее - ВАЗ 2101 или трактор "Беларусь" в условиях бездорожья и перевозки многотонных грузов ;)
В общем ладна, пусть делают как хотят ;)
 

dimagolov

Новичок
MiksIr, если ты вспомнишь диаграммы $/MIPS в одном устройстве, то ты поймешь, что выше определенного предела нет возможности масштабировать ни технически ни экономически.
 

MiksIr

miksir@home:~$
Этот предел гораздо выше "самых дефолтных выделенных хостингов".
А при хранении тяжелого контента MIPS вообще не к месту упомянуто было.
 
Сверху