Автор Тема: най-удачно решение за изграждане на клъстер  (Прочетена 17626 пъти)

HQ

  • Напреднали
  • *****
  • Публикации: 195
  • Distribution: *BSD
  • Window Manager: none
    • Профил
Здравейте!
Искам да си направя клъстер от няколко машини които да си споделят натоварването, те по всяка вероятност ще са леко различни. Целта е всички те да работят в една операционна система и да си споделят натоварването, тя ест ще е Freebsd с virtualbox headless виртуални машини. Какво ми трябва за целта?
Bare-metal вариантите на proxmox, vsphere и m$ hyper-v 2016 ги пробвах, неудобни са и трудни за усвояване.
Ще бъда много благодарен за всякаква информация!
Активен

pennywise

  • Гост
С какво точно мислиш д ги натоварваш, и какво ще върви на тези машини?
Активен

HQ

  • Напреднали
  • *****
  • Публикации: 195
  • Distribution: *BSD
  • Window Manager: none
    • Профил
на виртуални машини ще експериментирам с почти всичко от windows 3.1 до solaris 11.2. Някои ще са включени нон стоп и ще вършат определена работа,някои само при нужда. Когато нуждите нарастнат ще мога да ъпгрейдна част от хардуера или да добавя още машини, нещо като rackmount но без rack-a. Предполагам ще успея да настроя bootp протокол и второстепенните машини да буутват от главния и да нямат харддискове,а само дъно,проц и рам.
Също до колко ще е решаваща скоростта на мрежата, добре ли е да ползвам single или dual gigabit (всяка машина да има по 2 лан карти и всички те се свързват към един единствен суич) или да се ориентирам към оптика?
Активен

BRADATA

  • Напреднали
  • *****
  • Публикации: 833
  • Distribution: Slackware/Mint/CentOS
  • Window Manager: console/KDE/LXDE
    • Профил
    • WWW
Искаш да се метнеш направо в дълбокото, ама не си се подготвил. Като за начало си отсвирил всички прайм решения :) Е, забравил си едно, ама е простено... След това не си си отговорил на въпроса що е то вируализация, клъстер, HA, fence, NAS/SAN network storage etc... Когато си изясниш понятията - сам ще стигнеш до заключението как и с какво ще го правиш. С две думи въпроса ти звучи като "Абе ще си губя времето да си джиткам насам натам - къф въртолет да си сглобя?"
Активен

gat3way

  • Напреднали
  • *****
  • Публикации: 6050
  • Relentless troll
    • Профил
    • WWW
Съгласен, тук има и друга такава тема отскоро, макар и не точно в същия дух, обаче ми се струва разумно преди да се задава въпроса "как", да имаме отговор на "какво". Нещата са достатъчно комплексни, за да няма прост отговор, вярно е хиперболизиране в случая, но да речем сравнението е "ще правя завод, как?". Очевидно има значение какво ще произвежда този завод най-малкото.

Тъй като обикновено става въпрос малко или много за съвсем реални парични разходи, с цел най-малкото да се оптимизират нещата е редно да се знае какво ще върви, къде са му 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 връзки, който да осигурява минимална латентност.

Всичко това предопределя и софтуерът, който ще се ползва. В смисъл защо да си слагаме каручката пред коня в крайна сметка, важно е да се знае каква е крайната идея и къде са проблемите.
Активен

"Knowledge is power" - France is Bacon

gog

  • Напреднали
  • *****
  • Публикации: 15
    • Профил
Е то целия въпрос е смехотворен. На човека са му трудни готовите системи като Proxmox, Vsphere и други, където нещата се пускат с по няколко клика, за това е решил всичко да направи сам ... за по-лесно... а това с пускането на всички възможни операционни системи дори няма да го коментирам :)
Активен