« Отговор #4 -: Apr 19, 2016, 01:36 »
Съгласен, тук има и друга такава тема отскоро, макар и не точно в същия дух, обаче ми се струва разумно преди да се задава въпроса "как", да имаме отговор на "какво". Нещата са достатъчно комплексни, за да няма прост отговор, вярно е хиперболизиране в случая, но да речем сравнението е "ще правя завод, как?". Очевидно има значение какво ще произвежда този завод най-малкото.
Тъй като обикновено става въпрос малко или много за съвсем реални парични разходи, с цел най-малкото да се оптимизират нещата е редно да се знае какво ще върви, къде са му bottleneck-ите, какво натоварване се очаква. Примерно представи си три различни случая: vbox7.com, flightradar24.com и slack.com, едното е видео стрийминг услуга, другото онлайн система за проследяване на полети, третото е натоварен уеб-базиран чат.
На vbox7.com изискванията към мрежов/IO bandwidth са високи, понеже видеата малко или много са "обемни" като информация. В този случай да - dual gigabit картите сложени в bonding интерфейс и по възможност вързани не към един, а към два различни суича (в случай че суичовете са "умни"), имат повече смисъл. Също RAID 10 масив от много дискове ще ти осигури високия дисков bandwidth и надеждност на съответната цена.
На flightradar24.com нещата са други, там изискванията са към процесорно време. Стотици, вероятно хиляди пичове feed-ват на живо ADS-B информация и онези я предоставят на потребителите в реално време. Огромната част от процесинга се прави в клиентския браузър и всичко са json заявки, но сървърът им трябва да сметна нещо важно - при дадения zoom level и център на картата колко и кои самолети се намират в момента с идеята да не изсипва периодично мегабайтите информация за всички полети по земното кълбо, това е безсмислено. Оттам се почват едни сметки, понеже картата е проекция, а GPS координатите са нещо съвсем различно от координати по картата, тези сметки сървърите ги правят за сума ти клиенти и основното изискване (без да работя там, просто е лесно да си го представя) - е откъм изчислителна мощност и донякъде и латентност. Оттам, може би bonding интерфейсите и големите RAID10 масиви не са толкова важни, колкото осигуряването на достатъчно изчислителна мощност, правилното балансиране на заявките към сървърите така че да няма много по-натоварени и такива, които спят, такива работи.
На slack.com пък акцентът е върху надеждността и латентността, хората трябва възможно най-бързо да си виждат чат съобщенията, но и да си виждат и историята на чатовете, има масивно огромен брой клиенти, които нон-стоп poll-ват сървърите и там надеждността и латентността е цар. Налага се наличието на кеширащ слой отгоре на базата, а това пък налага повечко физическа памет на машините. Това измества и изискванията към storage-а, там дисковете е по-добре да са организирани в масиви, за които надеждността е най-важният фактор, което измества нещата накъм RAID5 масиви с parity. Защо не и SSD дискове с оглед на минимизиране на латентността на някои операции. Защо не някой хардуерен load-balancer, особено ако може да терминира TLS връзки, който да осигурява минимална латентност.
Всичко това предопределя и софтуерът, който ще се ползва. В смисъл защо да си слагаме каручката пред коня в крайна сметка, важно е да се знае каква е крайната идея и къде са проблемите.
Автор
Тема: най-удачно решение за изграждане на клъстер (Прочетена 17702 пъти)