Ahojte,

za mě je např. ta konfigurace nad ARM nedostatečná např. pro Připravto. Pro naše použití je výkonnější CPU/ paměti výhodnější a i výkonnější disk. V tuto chvíli je nejčastějším problémem pro naše VPS čekání na IO u disku jak na NAS tak i na lokálním disku. Pokud bych však chtěl zvyšovat výkon pro aplikaci, tak potřebuji určitě více CPU / jádro i výkon na jádro. Už máme v aplikaci možnost, přesunout něco na jinou VPS, ale ne vždy je to dostatečné a je potřeba synchronizace.

Pokud má uživatel jiné použití pro VPS, tak může mít ARM význam, ale např. pro nás ne. Chápu, že pro někoho může být soukromí hodně důležité, ale pro nás je to pouze jedna z častí a nemáme tak jednoduché použití, aby to dávalo takový význam.

Zdenek

st 22. 8. 2018 v 23:14 odesílatel Pavel Snajdr <snajpa@snajpa.net> napsal:
On 2018-08-22 21:57, Stepan Liska wrote:
> Osobně intuitivně tíhnu spíš k variantě - rozšiřovat o nové
> stroje (ač z bazaru) a starým v první fázi odlehčit. Přijde mi
> neefektivní vyhazovat nějaká velká množství CPUček a nahrazovat
> je jinými starými, i když v lepší konfiguraci.  To už raději
> koupit hafo dalších starejch mašin a řešit to po vzoru Googlu z
> počátku věků. Což by teda vlastně asi bylo přesně opačný
> řešení než teď navrhoval Snajpa - tj. daleko menší koncentrace,
> ale potencionálně hodně levnej HW.
>
>  Š.
>

Na levnym HW jsme zacali - a realne jsme poznali obrovskej rozdil, kdyz
jsme potom po par letech nasadili dvouprocesory v ty dobe se 128G RAM.
Cim vic se rozeviraji nuzky mezi realnym HW konfigem masiny a jednou
poskytovanou virtualni jednotkou, tim vic se da pohodlne bez problemu
agregovat. Agregovat na mensich strojich se da, ale obnasi to migrace -
a bez CRIU se ty migrace nedaji udelat pro kontejner transparentne, cili
varianta levny HW (i kdyz treba s custom dohackovanym remote
managementem), trpi na tyhle problemy.

Ad. dokoupit starsi stroje cely vs. vymenit CPUcka - ono vymenit CPUcka
vsem masinam v Praze a v Brne, co maji v1/v2 za ty v2 desetijadra vyjde
jako jedna cela stara masina. Pri tom poctu masin si teda myslim, ze
vymenit CPUcka vyjde lip v prepoctu na jednu aktualne hostovanou VPSku.

To je cca moje myslenkova cesta kudy jsem se dopracoval k tomu, co tu
nadhazuju - zatim asi jediny potencialne lepsi napad je natlacit se vic
smer novy AMDcka s jeste vetsi agregaci. Je pravda, co rikal Trekker, ze
v pripade vypadku to ovlivni vetsi procento clenu v prepoctu na stroj -
no, ale s 4.8+ kernely uz tomu docela verim a soucasne 4.18/4.19 maji
focus jeste spravneji, teda jeste lepsi kontejnerizace a zvladani
vetsich systemu - myslim, ze ackoliv kernel neni jeste uplne idealne
tam, kde bychom ho chteli, uz je cca prostor o vetsich masinach
premyslet a mozna zkusit jednu-dve nakoupit. Kdyz se to neprokaze jako
hned lepsi varianta, budem pokracovat vetsim scale-outem a casem to
muzem zvazit znova.

Do toho teda je potreba taky zminit ten soucasnej ARMovej vyvoj - mame
rozdelany system s 4x Cortex A72 @ 1.8 GHz a 8 GB ECC DDR4 RAM, je to
myslene misto VPSek na seriozni pouziti, kde se neda sdilet RAM/cache.
To by melo vychazet cca na 800-900/mesic - tak mi kdyztak taky rovnou
reknete, jestli je to blbost a nikdo o to nebudete mit zajem. Podle mne
ten system sviha a vpsFree infrastrukturnim vecem (jako clenska
databaze) by to fakt sluselo. A podobny use-cases bych videl pro
vsechno, kdo ma nejaky citlivejsi data... Necitlivy chroustani ve velkym
je na shared HW fajn, ale citlivy veci by si zaslouzily micro-scale-out,
tj. co microservica, to jeji dedikovany miniHW server.

/snajpa
_______________________________________________
Community-list mailing list
Community-list@lists.vpsfree.cz
http://lists.vpsfree.cz/listinfo/community-list