Раздел для новичка

GN
На сайте с 22.06.2011
Offline
21
3827

Народ, недавно в этой теме, но позарез надо разобраться со всеми ее понятиями, принципами.

Задача следующая:

Нужен dedicated-сервер, делаем очень тяжелый веб-ресурс, который предпологает двухсторонний файлообмен между нами и нашими клиентами. Средний размер файлов - 3-4 гигабайта (видео, аудио). Рассчитываем, что 5-20 клиентов будут пользоваться этой возможностью каждую секунду. И канала в 100 мбит/с тут вообще не хватит, канал 1 гбит - в принципе норм, но хочется еще больше.

Так вот вопрос, как вообще наращивается скорость канала?

Что если например, подключить пару серваков в каналу 1 гбит, настроить зеркалирование, получается скорость 2 гбита, или это не так? Как живут крупные ресурсы, тот же вконтакте, у них же канал не 100 мбит, как они наращивают эту скорость?

Помогите разобраться, люди добрые.:)

yahoster
На сайте с 14.04.2011
Offline
234
#1

можно сделать несколько вариантов:

1. много сетевых гигабитных подключений в сервер. :)

2. несколько серверов в кластер с множеством сетевых гигабитных подключений. :)

ээ... думаю, что уже хватит. ;)

и ещё... готовьтесь к солидному ценнику.

Цену на хостинг устанавливаете вы (https://cadedic.ru/aktsii/chestnaya-tsena/). Вечные виртуальные серверы (http://lto-vds.ru/otf-vds.html).
hosting_manager
На сайте с 26.03.2010
Offline
294
#2

Один сервер зачастую вряд ли будет генерировать более 500 Мбит / с, все зависит от нагрузки на диски, в это упирается зачастую. Способ есть - построить кластер, а его уже подключить через дополнительные свитчи к свитчу, который умеет LAG (Link Aggregation), это когда несколько портов работает, как один. У нас так 1 из клиентов 4 Гбит / с получает. Либо напрямую сервера включать в LAG, если они выдерживают :)

Наращивать линки в свитче нужно попарно, тоесть 2, 4, 6, 8, 10, 12 Гбит / с, когда непарное количество линков было (3 Гбит / с заведено) - свитч не мог нормально распределить нагрузку по линкам.

Стучите мне в аську 305500179, проконсультирую. Опыт с трафикогенерирующими проектами уже большой, секономите деньги на ошибках :)

hosting_manager добавил 23.06.2011 в 11:40

yahoster:
можно сделать несколько вариантов:
1. много сетевых гигабитных подключений в сервер. :)

Упирается то не в сетевую карту, а в диски. Смысл в таком решении? :)

ua-hosting.company: серверы в NL/US со скидкой 30% нашим читателям: E5-2650v4/10GB DDR4/240GB SSD/1 Gbps - от $20 ()
yahoster
На сайте с 14.04.2011
Offline
234
#3
hosting_manager:
Упирается то не в сетевую карту, а в диски. Смысл в таком решении? :)

SSD и SAS диски + 96 ГБ оперативы. можно в памяти многое хранить. 🤪

hosting_manager
На сайте с 26.03.2010
Offline
294
#4

Вы частично правы. Дешевле все-таки строить кластер на менее мощных железках, + одна железка не гарантирует безотказность. Я видел вообще мегасервер с 8-ю 10-ядерными процессорами и возможностью установить до 1 ТБ оперативной памяти и до 16 дисков с мегарейд-контроллером, но смысла в покупке такого мощного железа не вижу, дешевле и производительнее будет собрать на менее мощных. Конечно, геморрой с построением и настройкой, но раз настроить, а потом добавлять новые ноды, можно в любой момент сделать нужное количество ресурсов. Для проектов такого рода без масштабирования никуда + безотказность хоть какая-то нужна.

hosting_manager добавил 23.06.2011 в 11:51

Несколько сетевых интерфейсов имеет смысл юзать в таких случаях:

- если сервер, используется, как маршрутизатор (при большом трафике, 10 Гбит / с скажем - нереально)

- если второй сетевой интерфейс нужен для локальной синхронизации данных между нодами кластера

yahoster
На сайте с 14.04.2011
Offline
234
#5
hosting_manager:
Для проектов такого рода без масштабирования никуда + безотказность хоть какая-то нужна.

соглашусь.

и ещё лучше всего иметь часть серверов в одном ДЦ, а часть в другом. чтобы в случае чего со второго ДЦ работа продолжилась.

вопросов на самом деле только два:

1. ТС, вы представляете порядок цен на организацию такого проекта.

2. ТС, вам РЕАЛЬНО нужно много-много серверов со множественными гигабитными каналами? или вполне устроит сначала 1 сервер, а потом по мере надобности будете наращивать мощности?

Andron_buton
На сайте с 19.07.2007
Offline
270
#6
hosting_manager:
Один сервер зачастую вряд ли будет генерировать более 500 Мбит / с, все зависит от нагрузки на диски, в это упирается зачастую. Способ есть - построить кластер, а его уже подключить через дополнительные свитчи к свитчу, который умеет LAG (Link Aggregation), это когда несколько портов работает, как один. У нас так 1 из клиентов 4 Гбит / с получает. Либо напрямую сервера включать в LAG, если они выдерживают :)

Что за упертые люди, им говоришь, что с одного сервера можно и 5 гбит/с, а они продолжают рассказывать, что больше 500 мбит - никак.

hosting_manager
На сайте с 26.03.2010
Offline
294
#7

Мы не упертые, мы просто делаем дешево, безотказно и качественно, как сказал yahoster - вообще лучше, когда еще и распределено по разным ДЦ, но это в идеале уже. Учитывая, что канал в ДЦ может упасть на 15 минут в год, это не столь принципиально.

Andron_buton, под раздачу файлов? Вы представляете, что это должен быть за сервер, чтоб деражал такую нагрузку? Если представляете - приведите конфиг, и сравним, что будет дешевле :)

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

Andreyka
На сайте с 19.02.2005
Offline
822
#8
Ghost_nsk:
Как живут крупные ресурсы, тот же вконтакте, у них же канал не 100 мбит, как они наращивают эту скорость?

Они используют много-много серверов, на каждом канал 100мбит. Сумма каналов складывается.

Не стоит плодить сущности без необходимости
Andron_buton
На сайте с 19.07.2007
Offline
270
#9
hosting_manager:
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

H
На сайте с 12.05.2007
Offline
133
#10
hosting_manager:
дешевле и производительнее будет собрать на менее мощных. Конечно, геморрой с построением и настройкой, но раз настроить, а потом добавлять новые ноды, можно в любой момент сделать нужное количество ресурсов.

Дешевле и производительнее будет собрать то что должно решать задачу из оборудования, которое должно решать задачу. Причем не из пафосного а из цено-эффективного.

У меня используются в продакшене дисковые массивы по 24 диска. где то +1 масив в 2 месяца. Перешел на них с 8-дисковых. Сознательно, и не жалею.

Так что пироги должен печь пирожник, а сапоги - свпожник. И при этом обязательно чтобы сапоги были не их китайского дерьмантина, а из кожи, однако и не от D&G (дорого и глупо).

hvosting.ua (http://hvosting.ua/)

Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий