git.kernel.org je nově oficiálně také v tmavém vzhledu.
Richard Hughes na svém blogu oznámil, že počet aktualizací firmwarů pomocí služby LVFS (Linux Vendor Firmware Service) přesáhl 100 milionů. Přehled podporovaných zařízení, nejnovějších firmwarů nebo zapojených výrobců na stránkách LVFS.
Byla vydána nová stabilní verze 3.19.0, tj. první z nové řady 3.19, minimalistické linuxové distribuce zaměřené na bezpečnost Alpine Linux (Wikipedie) postavené na standardní knihovně jazyka C musl libc a BusyBoxu. Z novinek lze vypíchnou podporu Raspberry Pi 5.
Altap Salamander (Wikipedie), dvoupanelový správce souborů pro Windows, byl uvolněn jako open source pod názvem Open Salamander. Zdrojové kódy jsou k dispozici na GitHubu pod licencí GPLv2.
Společnost JetBrains představila (YouTube) svou umělou inteligenci JetBrains AI a nástroj AI Assistant v IDE.
Byla vydána nová verze 255 správce systému a služeb systemd (GitHub, NEWS). Z novinek lze vypíchnout například novou službu systemd-bsod.service.
Google představil Gemini, svůj největší a nejschopnější model umělé inteligence.
openSUSE komunita vybírá nová loga. Jedním z cílů je odlišit se od SUSE. Aktuálně probíhá hlasování o logu openSUSE a čtyř distribucí Tumbleweed, Leap, Slowroll a Kalpa.
Raspberry Pi OS, oficiální operační systém pro Raspberry Pi, byl vydán v nové verzi 2023-12-05. Přehled novinek v příspěvku na blogu a poznámkách k vydání. Nově jej lze používat také s tmavým tématem.
Dnes je to 10 let, co byla vytvořena decentralizovaná kryptoměna Dogecoin. Autoři Billy Markus a Jackson Palmer ji původně zamýšleli jako vtip. Znakem kryptoměny je pes Shiba-Inu známý z internetových memů.
Řešení dotazu:
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.
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: