Dotaz: Kolik RAM pro virtuální server

[PetrHL]

Dobrý den,

mám webovou aplikaci napsanou v PHP. Databáze má velikost asi 250MB, obsahuje skoro 900k záznamů. Web má průměrně 400 návštěv denně. Ve špičkách je tak 600 návštěvníků. V budoucnu doufám ve víc . Průměrně při používání webu každý uživatel znamená průměrně kolem 30 SQL dotazů, 99% pouze čtení z DB. Jedná se o jednoduché dotazy typu SELECT FROM, žádné JOINy a pod.

Zatím používám hosting NoLimit u WEDOSu, ale chtěl bych dát web raději na virtuální server. Ulehčil bych si tak aktualizace záznamů v databázi a další věci.

Kolik RAM by takový stroj měl ideálně mít? 1GB, 2GB nebo více? Nemám vůbec představu a nerad bych VPS poddimenzoval nebo naopak zase předimenzoval.

Díky za rady!

Petr

---

---

Odpovědi

[PetrHL]

Myslím si, že s 1GB by neměl být problém .
Zdar Max

[PetrHL]

Nakonec jsem pořídil VPS s 1GB RAM a stačí to. Díky moc!

[Radovan Garabík]

Mám (skutočné železo) starší server (4× Xeon 2GHz), 2GB RAM, lighttpd, php (fastcgi), mysql, priemerne desiatky návštev za minútu. Bez problémov stíha (kedysi mal návštev 3× viac, s apache nestíhal, po náhrade za lighttpd zase začal).

[loki]

Myslim si, ze vpsfree.cz pro vas bude jako delane.

[PetrHL]

Na vpsfree.cz jsem se díval, ale na webu mi chybí informace co se děje pokud jim chcípne server, jak dlouho bude moje VPS offline. U WEDOSu psali, že jsou schopni migrovat virtuální mašiny za běhu mezi stroji (snad jsem si to přečetl správně a mozek nekecá). Sice nemám tušení jak se to dělá, ale i kdyby to nebyla pravda, předpokládám, že firma s vlastním datacentrem bude mít i záložní servery a v případě, že nějaký chcípne, nahradí jej velice rychle.

Mám u nich nyní VPS s 512MB RAM, je na tom 6 webů, návštěvy v desítkách denně a ta paměť je málo. Zřejmě mám něco blbě nastaveno protože mi tam neustále běží asi 10 instancí mysqld. Zatím jsem to moc nezkoumal.

[Sten]

KVM (to používá Wedos) lze migrovat za běhu. Nebo skoro za běhu. Virtuál se zapauzuje, zkopíruje se RAM a stav virtualizovaného HW na nový stroj a tam se spustí. Celková doba bývá podle velikosti RAM a rychlosti spojení kolem jedné až dvou sekund.

[PetrHL]

To jsem netušil. Díky moc za rozšíření obzorů.

[trekker.dk]

Virtuál se zapauzuje, zkopíruje se RAM a stav virtualizovaného HW na nový stroj a tam se spustí.

Pro upřesnění - pokud jde o migraci za běhu, ve skutečnosti se nejprve spustí zapauzovaný virtuální stroj na cílovém hostiteli, pak se zkopíruje obsah RAM (host stále běží, když dojde k nějaké změně již zkopírovaných dat, kopírují se znovu.) Pak teprve se host zastaví, dokopíruje se zbytek RAM (to, co za běhu zkopírovat nešlo) a spustí se to na novém hostiteli.

[Radek Hladik]

Ono je to trošku složitější, jak už psal Trekker.dk. Je potřeba trochu myslet nad tím, co člověk píše.

zkopíruje se RAM a stav virtualizovaného HW na nový stroj a tam se spustí. Celková doba bývá podle velikosti RAM a rychlosti spojení kolem jedné až dvou sekund.

Pokud mám 1GB RAM a mělo by se to za vteřinu přenést, tak to znamená 8Gbit/s spojení. Proto se to dělá tak, že se přenese postupně celá paměť (v běžných nasazeních většinou po Ethernetu) a pak se přenese znova s tím, že se přenesou jen změněné bloky. To se dělá tak dlouho, dokud není možné přenést zbytek v požadované době (to jsou ty 1-2 sekundy). Pak se původní stroj zastaví, přenese se ten zbytek a ten nový se spustí.

Proč to píšu je to, že vlasntí migrace může tvrat i několik minut a někdy nemusí proběhnout vůbec. Například pokud na VM pustíte memtest, pak je matematika jasná: přístup do paměti vs přenosová rychlost pro migraci. Proto je někdy dobré výkon migorvaného VM snížit a to buď z vnitřku nebo z vnějšku.

Dalším problémem je migrace jendotlivých virtualizovaných HW komponent, především HDD a síťovek.

[trekker.dk]

Dalším problémem je migrace jendotlivých virtualizovaných HW komponent, především HDD a síťovek.

Síťovek? Když ten VS není připojen na fyzický hardware, tak udělat stejnou síťovku je jenom otázka její definice při spuštění KVM, nebo se pletu?

Jasně, co se týče disku, tam to tak jednoduché není. Co jsem si s tím hrál, tak jsem zatím neobjevil jediný způsob, jak udělat úložiště, aby bylo možné ten stroj migrovat a zároveň to nemělo menší výkon, než když to pojede přímo z LVM oddílu.

[VSi]

Síťovek? Když ten VS není připojen na fyzický hardware, tak udělat stejnou síťovku je jenom otázka její definice při spuštění KVM, nebo se pletu?

Ten cílový stroj musí mít přístup na stejný L2 segment. Což při migraci mezi fyzicky oddělenými lokalitami není úplně samozřejmé.

Jasně, co se týče disku, tam to tak jednoduché není. Co jsem si s tím hrál, tak jsem zatím neobjevil jediný způsob, jak udělat úložiště, aby bylo možné ten stroj migrovat a zároveň to nemělo menší výkon, než když to pojede přímo z LVM oddílu.

Používá se "shared-storage", tj. diskové pole připojené ke všem uzlům clusteru přímo (třeba přes SAS) nebo přes storage síť (SAN - Fibre Channel, iSCSI). Druhá možnost je softwarová replikace, na linuxu pomocé DRBD. U něj není výkon nutně výrazně menší, ale samozřejmě to vyžaduje dostatečně rychlou síť mezi uzly (ideálně 10GbE) a dost pomůže také HW RAID radič s vlastní write-cache.

[trekker.dk]

Ten cílový stroj musí mít přístup na stejný L2 segment. Což při migraci mezi fyzicky oddělenými lokalitami není úplně samozřejmé.

Tak to jo, já počítal se situací všechno na jednom místě.

Druhá možnost je softwarová replikace, na linuxu pomocé DRBD. U něj není výkon nutně výrazně menší,...

No nevím, co jsem měřil, tak mezi LVM a DRBD nad LVM byl propad při sekvenčním zápisu až o čtvrtinu (a to za situace, kdy to DRBD nebylo připojené po síti)

[VSi]

No nevím, co jsem měřil, tak mezi LVM a DRBD nad LVM byl propad při sekvenčním zápisu až o čtvrtinu (a to za situace, kdy to DRBD nebylo připojené po síti).

Co to bylo za řadič? Obyčejný SATA, nebo nějaký HW RAID? Princip DRBD je takový, že si na konci disku uržuje bitmapu změněných bloků, aby se urychlila pozdější resynchronizace. Takže při každém zápisu musí hlavička udělat seek na konec disku, aktualizovat metadata, a až pak je zápis potvrzen. HW řadič se zálohovanou pamětí umožňuje ten seek bezpečně nechat na později, takže výkonnostní ztráta je podstatně nižší. Jinak je tam snad i možnost oddělit metadata na jiný disk.

[trekker.dk]

Princip DRBD je takový, že si na konci disku uržuje bitmapu změněných bloků, aby se urychlila pozdější resynchronizace.

Jo, něco podobného jsem nakonec vypozoroval taky - u druhého a dalších zápisů (do stejného souboru, který zabíral skoro celý "disk") už ten propad nebyl tak hrozný. A byl to obyčejný SATA řadič.

Jinak je tam snad i možnost oddělit metadata na jiný disk.

Jj, akorát to má i nějaké nevýhody, na které si teď nevzpomenu

[Radek Hladik]

Jak je už napsáno níže, když se vytvoří nová virtuální síťovka, která se (většinou) nějak bridguje s reálnou HW síťovkou (t.j. de facto se reálné síťovce přidává virtuální MAC adresa), tak je potřeba, aby stroje byly na stejném L2 segmentu a byla možnost ten segment snadno a rychle přesvědčit o přesunu. Například u ethernetu se musí nejbližší switch typicky pomocí ARPu přesvědčit, že ta virtuální MAC adresa je na jiném portu.

Jak je již také napsáno níže, tak pro disk se používá nějaká forma shared storage. Já například používám disk připojený z iSCSI serveru, který se na zdrojovém stroji odpojí a na cílovém stroji připojí. Další možnosti jsou různé clusterové filesystémy, ono DRBD, NFS,samba, atd...

[trekker.dk]

Další možnosti jsou různé clusterové filesystémy, ono DRBD, NFS,samba, atd...

O DRBD viz výše. NFS a Samba - když jsem to zkoušel naposledy, tak VS používající jako disk soubor na LVM oddílu dal 60MB/s sekvenčního zápisu, kdežto VS, kde byl diskem přímo ten oddíl, dal 100.

[Radek Hladik]

Já mám principielně podobné zkušenosti s výkonem. Soubory jsou výrazně pomalejší - řekněme třeba i o 20%. Na druhou stranu, jsou to soubory a pěkně se s nimi pracuje. Navíc se výrazně lépe sdíli - Samba a NFS je přeci jen pohodlnější než sdílení na úrovni blokového zařízení. A například já osobně mám přímo strašné zkušenosti se všemi clusterovými filesystémy, snad kromě toho od ESX.

Jinak řečeno, ty řešení mají různé výhody a nevýhody a vždy záleží na tom, co člověk potřebuje.

[pavlix]

Pardon, že dělám reklamu svým přátelům, ale virtualmaster.cz nabízí možnost, že si člověk dimenzuje parametry VPS kdykoli podle potřeby s dobrou granularitou (nepamatuju si přesně, ale mám za to, že minimálně hodin).

Pak úplně odpadají starosti s předčasným dimenzováním VPS.

[PetrHL]

To máte pravdu, ale cena je dost někde jinde. Nevyužiju všechny možnosti, které mi virtualmaster dává. Když si tam vyberu 2GB RAM a 60GB HDD, je to přes 1000 Kč/měsíc. U wedosu mám stejné parametry za 480Kč/měsíc. Pravda, nemohu si kdykoliv přidat nebo odebrat, ale to stejně nevyužiju.

Zatím zůstávám na webhostingu. Uvidíme jak se projekt rozjede a jestli něco vydělám na reklamě. Pak bych koupil lepší VPS.

[pavlix]

To máte pravdu, ale cena je dost někde jinde. Nevyužiju všechny možnosti, které mi virtualmaster dává. Když si tam vyberu 2GB RAM a 60GB HDD, je to přes 1000 Kč/měsíc. U wedosu mám stejné parametry za 480Kč/měsíc. Pravda, nemohu si kdykoliv přidat nebo odebrat, ale to stejně nevyužiju.

Ceny jsem neporovnával, nejsem na tom nijak zainteresován. Ale třeba v případě stránek s nárazovou návštěvností to může vyjít levněji. Nemusím platit parametry VPS podle špiček, ale podle normálního provozu. Na špičky si můžu vždycky trochu ramky a cpu přidat.

Zatím zůstávám na webhostingu. Uvidíme jak se projekt rozjede a jestli něco vydělám na reklamě. Pak bych koupil lepší VPS.

Jinak umím v této oblasti zařídit ledacos (nemusí to být ani zrovna virtualmaster.cz), stačí se ozvat.