Здравствуйте!Есть задача: создание высоконагруженного сервера для отдачи медиаконтента
(файлы от 100mb до 5Gb).(отдаваться будет nginx'om)Имеем: 3U supermicro server - 2 хсеона, 16 GB ОЗУ. 2 Gb-ых ethernet-порта.
Хардварный рейд 9690SA-8I с 8 SAS дисками Seagate (1Tб).Так как раньше с подобными задачами встречаться не приходилось
возникли вопросы:1. Каков из рейдов целесообразнее всего использовать (необходим наибольший
суммарный объем дисков + скорость отдачи + отказоустойчивость)? //планируется RAID 50//
2. Какую ОС целесообразней всего использовать с учетом дальнейшего возможного масштабирования и кластеризации(подходит ли на эту роль FREE BSD 7.0 ?)? //планируется Gentoo//
3. Можно ли каким нибудь образом для расширения канала отдачи задействовать 2 Гигабитных порта и если да то каким?
4. Существуют ли в данном случае конкретные способы оптимизации nginx под такую раздачу и если да то какие?
Любые практические советы будут полезны.заранее благодарен за скорый ответ,
с уважением Владимир Громов
Изначальное условие уже не позволит реализовать правильную схему. При создании гиганских файловых хранилищь всегда руководствуются принципами: больше серверов, больше дисков маленького размера, никаких рейдов.Т.е. в твоем случае нужно было приобрести 3 x 1U (какой-нибудь celeron с 2гб), напихать в них по 4x250Гб sata и организовать дублирование файлов между серверами. т.е. каждый файл должен будет встречаться 2жды, но на разных машинах (этим убиваются одним выстрелом два зайца - высокая отказоустойчивость - вплодь что одна из машин может полностью быть отключена по причине збоя или обслуживания, и балансировка).
В общем, такое решение тебе обошлось бы ~60тр за 3 сервера - вместо ~140тр за одну немасштабируемую архитектуру.
На такой машине проц процентов на 5 занят будет - остальное время - отдыхать, и если есть возможность - отдай ее лучше под БД, а под архив - прикупи 3 сервачка совсем простеньких.пс. прочитай про различия масштабирования кластера в глубине и в ширину...
>[оверквотинг удален]
>отказоустойчивость - вплодь что одна из машин может полностью быть отключена
>по причине збоя или обслуживания, и балансировка).
>
>В общем, такое решение тебе обошлось бы ~60тр за 3 сервера -
>вместо ~140тр за одну немасштабируемую архитектуру.
>На такой машине проц процентов на 5 занят будет - остальное время
>- отдыхать, и если есть возможность - отдай ее лучше под
>БД, а под архив - прикупи 3 сервачка совсем простеньких.
>
>пс. прочитай про различия масштабирования кластера в глубине и в ширину...Спасибо за дельный совет.
1. Закупал оборудование и прорабатывал основу не я. Меня же просто поставили перед фактом - вот такой то серв - нужно чтоб отдавал медиаконтент, поэтому теперь надо бы опираться от того что есть - поэтому вопросы выбора ОС, RAID и особенностей nginx остаются в силе.
2. Сайт выбора контента - это отдельный хостинг на отдельном серваке - там же и БД. Здесь же только nginx - который будет отдавать клиентам файло, в зависимости от того на что есть права.
3. Вопрос - Интересует вопрос масштабирования и кластеризации уже имеющейся конфигурации (скорее в перспективе ибо пока думаю этого хватит).
4. А также настройки nginx для отдачи больших файлов.
Будет полезна любая информация - если у кого есть ссылки - пожалуйста не молчите.
Заранее благодарен за скорый ответ
>Изначальное условие уже не позволит реализовать правильную схему. При создании гиганских файловых
>хранилищь всегда руководствуются принципами: больше серверов, больше дисков маленького размера, никаких
>рейдов.
>Почему никаких рейдов? Как террабайт данных восстанавливать? Копированием? И сколько это времени займёт? Если контент будет только на чтение, то RAID5 или RAID6 (достаточно без RAID50)вполне нормально будет работать.
>Т.е. в твоем случае нужно было приобрести 3 x 1U (какой-нибудь celeron
>с 2гб), напихать в них по 4x250Гб sata и организовать дублирование
>файлов между серверами. т.е. каждый файл должен будет встречаться 2жды, но
>на разных машинах (этим убиваются одним выстрелом два зайца - высокая
>отказоустойчивость - вплодь что одна из машин может полностью быть отключена
>по причине збоя или обслуживания, и балансировка).
>Как и писал выше, рейд желательно настраивать. Учитывая стоимость жестких дисков SATA, потеря пространства одного из дисков для четности не так сильно ударить по карману как в случае SCSI, FC или SAS.
>В общем, такое решение тебе обошлось бы ~60тр за 3 сервера -
>вместо ~140тр за одну немасштабируемую архитектуру.
>На такой машине проц процентов на 5 занят будет - остальное время
>- отдыхать, и если есть возможность - отдай ее лучше под
>БД, а под архив - прикупи 3 сервачка совсем простеньких.
>
>пс. прочитай про различия масштабирования кластера в глубине и в ширину...
А по-вашему контроллер не копирует при замене одного харда?Насчет 5ого рейда, - пожалуйста, не давайте советов, не попробывар разные решения самостоятельно и не поработав над отдачей хотябы 10тер. Контроллеры, достаточно быстро работующие с хардами в 5рейде начинаются в стоимости от 800-1000баксов - ни один сколь-угодно прибыльный проект не окупит такое денежное вложение.
Для отдачи статики ни одна из приличных контор не использует рейды: ни гугл ниразу нигде, ни ютуб, ни яндекс, ни смотри.ком, ни рамблер, ни мейлру...
Стандартная приписка для всех перебивающих: за####и давать советы, не разбираясь в теме. Вылези вначале за пределы одного сервера, прежде чем начинать учить... только народ путаешь.
>пс. прочитай про различия масштабирования кластера в глубине и в ширину...Для масштабирования надо, чтобы само ПО умело работать, либо распределять нагрузку между несколькими нодами.
>В общем, такое решение тебе обошлось бы ~60тр за 3 сервера -
>вместо ~140тр за одну немасштабируемую архитектуру.
>На такой машине проц процентов на 5 занят будет - остальное время
>- отдыхать, и если есть возможность - отдай ее лучше под
>БД, а под архив - прикупи 3 сервачка совсем простеньких.
>
>пс. прочитай про различия масштабирования кластера в глубине и в ширину...Вы забыли посчитать стоимость поддержки данного решения, размещение на collocation, поддержка серверов, у автора все туманно, тут главное чтобы приложение было масштабируемое
>1. Каков из рейдов целесообразнее всего использовать (необходим наибольший
>суммарный объем дисков + скорость отдачи + отказоустойчивость)? //планируется RAID 50//50 избыточен, простого raid 5 хватит. Желательно один диск в hotswap, если контроллер позволяет.
>2. Какую ОС целесообразней всего использовать с учетом дальнейшего возможного масштабирования и
>кластеризации(подходит ли на эту роль FREE BSD 7.0 ?)? //планируется Gentoo//Какую лучше знаете. При прочих равных серверный дистр линукса: debian/suse/rhel и их производные; gentoo к таковым не относится.
>3. Можно ли каким нибудь образом для расширения канала отдачи задействовать 2
>Гигабитных порта и если да то каким?Это называется trunk. Оба порта должны быть подключены в один свитч и со стороны владельца свитча(скорее всего датацентр) должны быть произведены определенные манипуляции. Спрашивайте техсаппорт.
>4. Существуют ли в данном случае конкретные способы оптимизации nginx под такую
>раздачу и если да то какие?А что там оптимизировать под эту задачу? Это для быстрой отдачи большого количества мелких нужно, а у вас все упрется в пропускную способность.
P.S. Зачем упомянуто что это медиаконтент? Обычно об этом говорят, когда идет речь о потоковом вещании, а у вас, судя по всему, просто раздача больших файлов.
Лучше юзать iSCSI
>Хардварный рейд 9690SA-8I с 8 SAS дисками Seagate (1Tб).
>
>1. Каков из рейдов целесообразнее всего использовать (необходим наибольший
>суммарный объем дисков + скорость отдачи + отказоустойчивость)? //планируется RAID 50//В RAID 50 с пользой будут использоваться только 3 порта контроллера при занятых 8 портах (всего 3 гига). Мега перестраховка :) Оно вам надо?
От вылета двух любых хардов может спасти RAID 6. Это 6 с пользой из 8 (6 гигов).
От вылета одного любого харда может спасти RAID 5. Это 7 с пользой из 8 (7 гигов).
Раз "необходим наибольший суммарный объем дисков" и "отказоустойчивость", то RAID 6 имхо наиболее оптимальный выбор. При том, что чтение - одна из сильных сторон RAID 5 и 6, и при том, что названный контроллер весьма производительный, вы вообще можете не стесняться в выборе решений.>2. Какую ОС целесообразней всего использовать с учетом дальнейшего возможного масштабирования и
>кластеризации(подходит ли на эту роль FREE BSD 7.0 ?)? //планируется Gentoo//Вы вот найдите админа, который сможет все это тянуть и спросите у него - какой он будет использовать дистрибутив. Прочие ваши вопросы говорят о том, что админить пока некому. А какая ось на сервере стоит не должно заботить никого кроме админа и мб разработчиков, если таковые есть.
>3. Можно ли каким нибудь образом для расширения канала отдачи задействовать 2
>Гигабитных порта и если да то каким?Если провайдер не даст сделать транк, то как вариант - купить второй канал и переадресовывать запросы на него умным скриптом при перегрузке первого канала. Или хотябы оба адреса приписать в днс чтобы юзеры приходили рандомно через один или другой канал.
>В RAID 50 с пользой будут использоваться только 3 порта контроллера при
>занятых 8 портах (всего 3 гига). Мега перестраховка :) Оно вам
>надо?
>От вылета двух любых хардов может спасти RAID 6. Это 6 с
>пользой из 8 (6 гигов).
>От вылета одного любого харда может спасти RAID 5. Это 7 с
>пользой из 8 (7 гигов).Пардон, гигабайты это опечатка. Тут конечно терабайты
>>В RAID 50 с пользой будут использоваться только 3 порта контроллера при
>>занятых 8 портах (всего 3 гига). Мега перестраховка :) Оно вам
>>надо?
>Пардон, гигабайты это опечатка. Тут конечно терабайтыПардон, но 5+0 != 5+1. Так что из 8 портов 6, а не 3.
>Пардон, но 5+0 != 5+1. Так что из 8 портов 6, а
>не 3.А, в самом деле, поспешил :) Подумал что люди надежности хотят выше крыши.
В таком случае raid 6 все равно предпочтительнее, тк спасает от вылета любых двух дисков. Пятый спасает от вылета любого одного. А raid 50 спасает от вылета двух, но не любых... И по объему raid 6 получится как raid 50.
С другой стороны, raid 50 должен быть шустрее чем raid 5 и raid 6 при чтении больших блоков данных. При больших файлах это отлично... Но при некоторых уловиях, к которым относится рост числа качающих и их относительно невысокая скорость скачки, может нерационально использоваться память контроллера.
Имхо для небльшого числа клиентов на широченных каналах raid 50 был бы предпочтительнее. Это только если они читают, не пишут. Иначе я бы для растущего числа качков выбирал между raid 5 и raid 6.А главное. Беглый осмотр характеристик контроллера указывает на то, что он умеет миграцию уровней raid. Так что если не понравится - можно запастись валидолом и перестроить потом свое хранилище с 5 на 6, с 6 на 50 или еще как-нибудь :)
Спасибо всем за ценные советы. После всего однако появилось еще три уточняющих вопроса:1. Если я буду использовать FreeBSD 7.1 - какие ограничения на размер ОЗУ могут быть и как увидеть все 16 Гб без включения PAE?
Насколько мне известно > 4 Gb может увидеть фря amd64 архитектуры (поправте если ошибаюсь)? С другой стороны станет ли нормально такая система на интеловские камни?
2. У нас 8 дисков. Один из них будет хот спаром. Какой рейд из перечисленных можно собрать из 7 дисков (наверно 50 не собереш - ведь в юнитах окажется разное количество дисков 3и4)?
3. А не загнется ли UFS читать разделы на слайсе > 4Tb?
Заранее благодарен за скорый ответ
Бросайте это занятие. Ничего у вас не выйдет с такими знаниями. Только проблем создадите будущему админу.