Portál AbcLinuxu, 25. dubna 2024 01:34
. 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
Řešení dotazu:
13.7.2011 15:58
Max | skóre: 72
| blog: Max_Devaine
.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.
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.
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.
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.
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)
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.
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
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.
15.7.2011 12:23
pavlix | skóre: 54
| blog: pavlix
15.7.2011 13:01
pavlix | skóre: 54
| blog: 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.
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.