- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
В 2023 году Google заблокировал более 170 млн фальшивых отзывов на Картах
Это на 45% больше, чем в 2022 году
Оксана Мамчуева
Тренды маркетинга в 2024 году: мобильные продажи, углубленная аналитика и ИИ
Экспертная оценка Адмитад
Оксана Мамчуева
Народ, недавно в этой теме, но позарез надо разобраться со всеми ее понятиями, принципами.
Задача следующая:
Нужен dedicated-сервер, делаем очень тяжелый веб-ресурс, который предпологает двухсторонний файлообмен между нами и нашими клиентами. Средний размер файлов - 3-4 гигабайта (видео, аудио). Рассчитываем, что 5-20 клиентов будут пользоваться этой возможностью каждую секунду. И канала в 100 мбит/с тут вообще не хватит, канал 1 гбит - в принципе норм, но хочется еще больше.
Так вот вопрос, как вообще наращивается скорость канала?
Что если например, подключить пару серваков в каналу 1 гбит, настроить зеркалирование, получается скорость 2 гбита, или это не так? Как живут крупные ресурсы, тот же вконтакте, у них же канал не 100 мбит, как они наращивают эту скорость?
Помогите разобраться, люди добрые.:)
можно сделать несколько вариантов:
1. много сетевых гигабитных подключений в сервер. :)
2. несколько серверов в кластер с множеством сетевых гигабитных подключений. :)
ээ... думаю, что уже хватит. ;)
и ещё... готовьтесь к солидному ценнику.
Один сервер зачастую вряд ли будет генерировать более 500 Мбит / с, все зависит от нагрузки на диски, в это упирается зачастую. Способ есть - построить кластер, а его уже подключить через дополнительные свитчи к свитчу, который умеет LAG (Link Aggregation), это когда несколько портов работает, как один. У нас так 1 из клиентов 4 Гбит / с получает. Либо напрямую сервера включать в LAG, если они выдерживают :)
Наращивать линки в свитче нужно попарно, тоесть 2, 4, 6, 8, 10, 12 Гбит / с, когда непарное количество линков было (3 Гбит / с заведено) - свитч не мог нормально распределить нагрузку по линкам.
Стучите мне в аську 305500179, проконсультирую. Опыт с трафикогенерирующими проектами уже большой, секономите деньги на ошибках :)
hosting_manager добавил 23.06.2011 в 11:40
можно сделать несколько вариантов:
1. много сетевых гигабитных подключений в сервер. :)
Упирается то не в сетевую карту, а в диски. Смысл в таком решении? :)
Упирается то не в сетевую карту, а в диски. Смысл в таком решении? :)
SSD и SAS диски + 96 ГБ оперативы. можно в памяти многое хранить. 🤪
Вы частично правы. Дешевле все-таки строить кластер на менее мощных железках, + одна железка не гарантирует безотказность. Я видел вообще мегасервер с 8-ю 10-ядерными процессорами и возможностью установить до 1 ТБ оперативной памяти и до 16 дисков с мегарейд-контроллером, но смысла в покупке такого мощного железа не вижу, дешевле и производительнее будет собрать на менее мощных. Конечно, геморрой с построением и настройкой, но раз настроить, а потом добавлять новые ноды, можно в любой момент сделать нужное количество ресурсов. Для проектов такого рода без масштабирования никуда + безотказность хоть какая-то нужна.
hosting_manager добавил 23.06.2011 в 11:51
Несколько сетевых интерфейсов имеет смысл юзать в таких случаях:
- если сервер, используется, как маршрутизатор (при большом трафике, 10 Гбит / с скажем - нереально)
- если второй сетевой интерфейс нужен для локальной синхронизации данных между нодами кластера
Для проектов такого рода без масштабирования никуда + безотказность хоть какая-то нужна.
соглашусь.
и ещё лучше всего иметь часть серверов в одном ДЦ, а часть в другом. чтобы в случае чего со второго ДЦ работа продолжилась.
вопросов на самом деле только два:
1. ТС, вы представляете порядок цен на организацию такого проекта.
2. ТС, вам РЕАЛЬНО нужно много-много серверов со множественными гигабитными каналами? или вполне устроит сначала 1 сервер, а потом по мере надобности будете наращивать мощности?
Один сервер зачастую вряд ли будет генерировать более 500 Мбит / с, все зависит от нагрузки на диски, в это упирается зачастую. Способ есть - построить кластер, а его уже подключить через дополнительные свитчи к свитчу, который умеет LAG (Link Aggregation), это когда несколько портов работает, как один. У нас так 1 из клиентов 4 Гбит / с получает. Либо напрямую сервера включать в LAG, если они выдерживают :)
Что за упертые люди, им говоришь, что с одного сервера можно и 5 гбит/с, а они продолжают рассказывать, что больше 500 мбит - никак.
Мы не упертые, мы просто делаем дешево, безотказно и качественно, как сказал yahoster - вообще лучше, когда еще и распределено по разным ДЦ, но это в идеале уже. Учитывая, что канал в ДЦ может упасть на 15 минут в год, это не столь принципиально.
Andron_buton, под раздачу файлов? Вы представляете, что это должен быть за сервер, чтоб деражал такую нагрузку? Если представляете - приведите конфиг, и сравним, что будет дешевле :)
А красивый график я тоже могу с нашего LAG-свитча взять на основном включении, там еще побольше будет трафик. С одного сервера в такой трафик не поверю, если только это не мегасервер или характер трафика не сомнительного происхождения :)
Как живут крупные ресурсы, тот же вконтакте, у них же канал не 100 мбит, как они наращивают эту скорость?
Они используют много-много серверов, на каждом канал 100мбит. Сумма каналов складывается.
Andron_buton, под раздачу файлов? Вы представляете, что это должен быть за сервер, чтоб деражал такую нагрузку? Если представляете - приведите конфиг, и сравним, что будет дешевле :)
А красивый график я тоже могу с нашего LAG-свитча взять на основном включении, там еще побольше будет трафик. С одного сервера в такой трафик неповерю, если только это не мегасервер или характер трафика не сомнительного происхождения :)
График, который я привел как раз сервера, который занимается раздачей файлов, в пике тут было 4.31к одновременных подключений (скачиваний), вообще такой сервак держит 12к подключений - это то что я видел.
Конфиг - пожалуйста:
GA-H67A-UD3H-B3
Intel Core i5-2500K
16 Гб (4 шт. по 4Гб) RAM
OCZ RevoDrive X2 OCZSSDPX-1RVDX0480 - 1 шт.
WDC WD5000AAKS-0 - 10 шт.
Intel PRO 1000 ET Dual Port Server Adapter - 1 шт.
HP NC112T - 3 шт.
3: eth4: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master bond0 state UP qlen 1000
link/ether 00:1b:21:66:12:9d brd ff:ff:ff:ff:ff:ff
4: eth2: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master bond0 state UP qlen 1000
link/ether 00:1b:21:66:12:9d brd ff:ff:ff:ff:ff:ff
5: eth1: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master bond0 state UP qlen 1000
link/ether 00:1b:21:66:12:9d brd ff:ff:ff:ff:ff:ff
6: eth3: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master bond0 state UP qlen 1000
link/ether 00:1b:21:66:12:9d brd ff:ff:ff:ff:ff:ff
7: eth0: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master bond0 state UP qlen 1000
link/ether 00:1b:21:66:12:9d brd ff:ff:ff:ff:ff:ff
8: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
link/ether 00:1b:21:66:12:9d brd ff:ff:ff:ff:ff:ff
PRC | sys 0.59s | user 0.03s | #proc 146 | #zombie 0 | #exit 1 |
CPU | sys 22% | user 2% | irq 42% | idle 295% | wait 40% |
cpu | sys 8% | user 1% | irq 13% | idle 67% | cpu003 w 11% |
cpu | sys 6% | user 1% | irq 14% | idle 68% | cpu000 w 11% |
cpu | sys 4% | user 0% | irq 10% | idle 79% | cpu001 w 8% |
cpu | sys 4% | user 0% | irq 5% | idle 82% | cpu002 w 10% |
CPL | avg1 0.91 | avg5 1.40 | avg15 1.43 | csw 19262 | intr 275063 |
MEM | tot 15.7G | free 315.0M | cache 13.5G | buff 51.7M | slab 165.8M |
SWP | tot 3.7G | free 3.7G | | vmcom 1.3G | vmlim 11.6G |
PAG | scan 66988 | stall 0 | | swin 0 | swout 0 |
DSK | sdl | busy 43% | read 84 | write 0 | avio 10 ms |
DSK | sdf | busy 43% | read 65 | write 0 | avio 13 ms |
DSK | sdi | busy 43% | read 60 | write 1 | avio 14 ms |
DSK | sdg | busy 42% | read 67 | write 0 | avio 12 ms |
DSK | sdh | busy 39% | read 57 | write 0 | avio 13 ms |
DSK | sdn | busy 38% | read 77 | write 0 | avio 9 ms |
DSK | sdm | busy 32% | read 59 | write 0 | avio 10 ms |
DSK | sdd | busy 29% | read 717 | write 0 | avio 0 ms |
DSK | sdk | busy 28% | read 59 | write 0 | avio 9 ms |
DSK | sdc | busy 25% | read 648 | write 0 | avio 0 ms |
DSK | sdj | busy 25% | read 45 | write 1 | avio 10 ms |
DSK | sdb | busy 25% | read 728 | write 1 | avio 0 ms |
DSK | sda | busy 24% | read 706 | write 0 | avio 0 ms |
DSK | sde | busy 22% | read 38 | write 0 | avio 11 ms |
NET | transport | tcpi 237993 | tcpo 465683 | udpi 0 | udpo 0 |
NET | network | ipi 237997 | ipo 99449 | ipfrw 0 | deliv 237997 |
NET | eth2 63% | pcki 46199 | pcko 105670 | si 11 Mbps | so 630 Mbps |
NET | eth0 55% | pcki 54917 | pcko 93319 | si 13 Mbps | so 557 Mbps |
NET | eth1 55% | pcki 41588 | pcko 94346 | si 10 Mbps | so 552 Mbps |
NET | eth3 52% | pcki 42447 | pcko 88572 | si 10 Mbps | so 525 Mbps |
NET | eth4 52% | pcki 52352 | pcko 87773 | si 12 Mbps | so 522 Mbps |
NET | bond0 ---- | pcki 237525 | pcko 469716 | si 58 Mbps | so 2789 Mbps |
NET | lo ---- | pcki 489 | pcko 489 | si 255 Kbps | so 255 Kbps |
PID SYSCPU USRCPU VGROW RGROW RDDSK WRDSK ST EXC S CPU CMD 1/4
15115 0.06s 0.00s 512K 264K 47864K 0K -- - S 3% nginx
15111 0.05s 0.01s 0K 0K 43860K 0K -- - S 3% nginx
15113 0.05s 0.00s 0K 0K 38948K 4K -- - S 2% nginx
15114 0.05s 0.00s 0K 0K 34776K 0K -- - S 2% nginx
15105 0.05s 0.00s 0K 0K 36484K 0K -- - S 2% nginx
15110 0.05s 0.00s 0K 0K 36988K 0K -- - S 2% nginx
15109 0.03s 0.01s 0K 0K 36868K 0K -- - S 2% nginx
15107 0.04s 0.00s 0K 0K 45208K 0K -- - S 2% nginx
15112 0.04s 0.00s 0K 0K 38772K 0K -- - S 2% nginx
15108 0.04s 0.00s 0K 0K 31148K 8K -- - S 2% nginx
дешевле и производительнее будет собрать на менее мощных. Конечно, геморрой с построением и настройкой, но раз настроить, а потом добавлять новые ноды, можно в любой момент сделать нужное количество ресурсов.
Дешевле и производительнее будет собрать то что должно решать задачу из оборудования, которое должно решать задачу. Причем не из пафосного а из цено-эффективного.
У меня используются в продакшене дисковые массивы по 24 диска. где то +1 масив в 2 месяца. Перешел на них с 8-дисковых. Сознательно, и не жалею.
Так что пироги должен печь пирожник, а сапоги - свпожник. И при этом обязательно чтобы сапоги были не их китайского дерьмантина, а из кожи, однако и не от D&G (дорого и глупо).