Další z řady brain dumpů o aktuálním dění. Nebude to ani tak o rockové hudbě, i kdy trošku Strašlivé Tísně (Dire Straits) přece jen obsahuje. Na produkci se nám stala taková zlá nepěkná věc, aneb fuck you VMware.
Asi není tajemstvím, že používáme VMware vSphere 5. Teď už to tajemství není určitě :-). VMware je dost standardní a používané, není problém dodávat zákazníkům hotové virtuální stroje, které stačí spustit. Trocha nastavení sítě a firewallu a už to jede i z Internetu. Naši zákazníci si to pochvalují a pro nás je to snadnější, než rozjíždět naše aplikace v cizím prostředí na serveru klienta. Klidně si to mohou spusti na free (zatím) Playeru, to dobře funguje. Spousta zákazníků má také dostatečně novou verzi ESX, tedy není problém ani cesta opačná, tedy rozjetí jejich hotového image na našem hostingu. Live migrace guesta umožňuje odstavit ESX HW, live migrace storage se také hodí v případě, že je nutno udělat údržbu file serveru. Všechno je velmi pěkné a velmi funkční. A časem také velmi drahé.
Pro správu vSphere clusteru potřebujete Windows. A to hned dvojím způsobem. Jednak na klientu. On sice existuje jakýsi pokus udělat HTML verzi vSphere VMware klienta, ale ten v Iceweasel (pro nedebianisty Firefox) spíše nefunguje. O dalších prohlížečích ani nemluvím. Nakonec skončíte na Windows. Licence pro klienta, tedy něco jako Windows 7. Ve VirtualBoxu. Ještě že ten je od Oracle zdarma.
Co je horší, pro řízení clusteru potřebujete: Buď Windows Server + ostré velké MSSQL 2008. Nebo vcapp + Oracle. Vyberte si. A právě vcapp nás pěkně vypeklo a mě neskutečně dožralo. vcapp je vlastně jen openSUSE s nainstalovanými službami pro řízení clusteru. VMware Inventory, vSphere Client, VMotion apod. Funguje (pokud to funguje) to velmi dobře a na rozdíl od Windows Server je to velmi rychlé. Free verze má embeded IBM DB2. Jenže.
Free verze funguje (a opravdu funguje, do limitu si nelze stěžovat) jen pro 50 guestů (virtuálek). Aby toho nebylo málo, tak stejně jako MySQL o tomto faktu kompletně mlčí. Máme mnohem více než 50 VM. A na hostingu začalo strašit. Asi po překročení počtu 50. Různé VM dostávaly stejné MAC adresy (!), přestávaly fungovat různé věci (jako třeba zálohování opět velmi drahým Veeam Backup), nebojte se, zálohujeme ještě druhým způsobem, až najednou se nedalo na cluster připojit. Hodně „pomůže“, když potom naleznete oficiální troubleshoting, kde (a jedině kde) lze najít zmíněné soft limity. Věci fungují i nad tyto limity, jenže blbě a hlavně se to vůbec nedozvíte. Potom už je pozdě.
that’s the way you do it
Teď jsme ve stavu, kdy jediná možná cesta pro záchranu vSphere clusteru je v další koupi. V koupi produktu, který nepotřebujeme. A hlavně nikde nemáme jistotu, že to bude koupě poslední (u free vcapp se také nedozvíte, že přestane fungovat). Buď je to licence za Windows Server + MSSQL (aneb cesta, jak donutit linuxový hosting platit zbytečně Microsoftu), nebo je to licence za Oracle DB (stejný shit). Takže po zakoupení dost drahé licence za vSphere 5 je jedinou cestou, jak ji skutečně používat, nákup dalšího software. Aneb peníze za nic.
get your chicks for free
Netřeba říkat, že kdybychom tohle věděli už při přípravě nového hostingu, určitě bychom nákup VMware zvážili a nejspíše neschválili. Nemohu se ubránit pocitu rukojmí v rukou vmware. Nechali nás postavit cluster, nechali nás vybudovat celou okolní infrastrukturu, která stála strašné peníze. Teď si přišli pro výpalné. Ostatní (MS a Oracle) také chtějí svůj podíl. Buď zaplatíme, nebo celá současná investice propadne. Udělali to chytře. VM fungují, na jednotlivá ESX clusteru se dostaneme, takže to stále máme v rukou. Můžeme dělat co chceme. Jen nefungují migrace (vem je čert) a nefunguje zálohování. A právě tohle může být cesta, jak vedení donutit co nejrychleji koupit další zbytečné licence. V takové chvíli nikdo nebude uvažovat na migraci na jiný tip virtualizátoru.
Snad tohle někomu pomůže se rozhodnout.
Jestli se ptáte, co bych doporučil, moje volba je dneska jednoznačně KVM. Kdekoliv je Linux, je i KVM, virtuálku lze rozjet na zelené louce jedním příkazem. Vše máte v rukou, od kompletního síťování, po storage. KVM umí, díky virtio paravirtualizaci, velmi rychlé IO. Až vSphere 5 jej dohnala. Postavit storage pro KVM lze nad kdečím. Obyčejný systém souborů (s BTRFS snapshoty můžete získat zcela neobyčejné možnosti), iSCSI, FC, NFS. Jasně, nemá to klikátko (není třeba, v krizové situaci stejně oceníte rychlou konzoli s možností zjistit úplně všechno, než lesklé grafy) a zatím to neumí migrace. Jsou experimental. Příští rok budou stable. Na KVM nakonec rozjedete i vmware guesty. Umí mnoho diskových formátů, včetně vmdk. Neplatíte licence. Btw. licence kolem vmware nás stáli tolik, jako velmi výkonný HW. Pro KVM bychom tak mohli koupit další server a pro naše zákazníky tak získat výkon navíc. Nebo prostě ušetřit náklady pro budoucí rozvoj.
Spravny spelling je ‚openSUSE‘ JFYI ;-)
Opraveno. :-)
Vcera jsme diskutovali s Red Hat o RHEV. Ted mame vSphere a v prechodu na RHEV nam brani jedina vec – Datastore cluster. Tak doufejme, ze RHEV 3.3 to bude obsahovat, kdyz jsme se „motivovali“ :-)
Zrovna tento týden vyšla beta RHELV 3.1, umí storage migration ale jestli tohle je Datastore Cluster to netuším. Live migrace pokud je mi známi umí už trojka. Jinak toto video je taky docela aktuální: http://www.youtube.com/watch?v=Zdlyhhm-DdE
ten datastore cluster mi zní jako obdoba více storage domains dohromady se storage live migration. Samotné live migrace umí RHEV (oVirt) už od doby, kdy se jmenoval SolidICE a říkal „pane“ firmě Qumranet…
Zkuste nedávno vydaný oVirt 3.1, jestli jeho „storage live migration“ neuspokojí vaše datově-ukládací potřeby (RHEV to bude mít až někdy v zimě ve své 3.1).
S tím klikátkem a nefunkčními migracemi jsem si nejsem úplně jist, jestli tohle už není prohlášeno za stabilní. Koukni na to, co umí RHEV3+ (https://access.redhat.com/knowledge/docs/Red_Hat_Enterprise_Virtualization/) a to samé pak umí i oVirt, který je zdarma. Docela by mě zajímalo, jestli by vám to řešení vyhovovalo.
Když už jsem u toho doporučení, mrkni na Foremana (http://theforeman.org/), je to management software který je postaven nad virtualizací a přináší další přidanou hodnotu. Toto by mělo být poučení, že není dobré systémy instalovat na zelené louce, protože jedinou možností jak je přesunout jinam je migrace. Daleko flexibilnější je vytvářet je flexibilní cestou (v tomto případě Puppet), takže je možné je prostě vytvořit jinde (dokonce v tomto případě například dočasně v EC2).
Jinak gratuluji k procitnutí. Hodně firem nebo jednotlivců si myslí, že nasazením virtualizace ušetří. To je veliký omyl, kupují se přidanou hodnotu. Skonsolidovali operační systémy, jsou nyní flexibilnější, a tudíž musí platit. A to samé je to s cloudem. Jestli si někdo myslí, že cloud je levnější, tak se plete. ;-)
Na odkazy mrknu, díky za ně. RHEV se mi v noci nechtělo studovat.
Virtualizace nic neušetří, ale přinese výhody. S tím naprosto souhlasím. Sice by se dalo hovořit o konsolidaci HW, ale to není tak značné, nakonec se stejně pro guesty rozdává pouze to, co je dostupné. Overcommit paměti moc nefunguje a thin provisioning (jsme nikdy nepoužívali) si zadělává na problém došlého místa na storage (správci zapomenout přidávat disky a typicky mají porozdáváno více, než umí jejich file server, i to jsme řešili). Jen těch procesorů je dneska na rozdávání.
Nám virtualizace přináší výhodu v jednotném prostředí pro všechny servery, jejiž příprava trvá pár minut. Není problém s instalací OS. Přesun na lepší HW za běhu. Apod. Často připravujeme VM pro jiné firmy. Takže zcela souhlasím, o ceně to není.
To hodně záleží na okolnostech. Pro uniformní VMky (VDI, několik stejných serverů apod.) funguje dobře. Stejně tak v případě RHEVu když se host dostane do memory crunch situace – v tu chvíli projede paměť KSM a crunch je většinou pryč.
Na RHEVu to v některých případech zvyšuje I/O výkon, protože společnou část VMek z jedné šablony si může hypervizor snáz držet v cache, než hromadu samostatných LUNů.
Aktuálně mám na asi půl roku starém setupu RHEV 3.0 over-allocation ratio 1078 % a volné místo se dojít nechystá – i když svoje bude hrát to, že tamní VMky nejsou náročné na I/O zápisy.
Osobně bych to u I/O-heavy strojů řešil kombinovaně: tence-provižnovaným diskem ze šablony pro systém (kde převládá čtení) a vlastními daty na samostatném prealokovaném disku.
Naše VM jsou všechny takřka stejné, ale krom balloonu (což mnohdy situaci ještě zhorší) jsem žádný pozitivní zásah od vmware neviděl. Když dojde paměť, tak jediné co zasáhne (po balloonu) je OOMK. A potom neběží potřebné služby. Stejnou situaci jsem viděl i na KVM. Možná, že to funguje v situaci, kdy je hodně VM nepotřebných a lze je uklidit, ale u nás běží vše a špičky jsou pro všechny VM ve stejnou dobu. Rozdáváme tedy jen to, co máme a od té doby nejsou problémy.
Naopak u CPU si dovolím rozdat mnohem více, než je v HW. Hypervizor si s tím umí dobře poradit a ty procesory jsou dobře využité. Je to dané tím, že naše app nejsou ani tak náročné na cpu jako spíše na paralelismus. Přepínání kontextů hypervizoru evidentně nevadí.
S tím thinprovisioningem. Jasně ono to funguje dobře, ale musí se to hlídat. Na řadu časem jistě přijde i deduplikace, (naše stroje jsou vesměs stejné a je to vidět i na záloze, deduplikace je v desítkách), tam lze na IO Cache ušetřit také dost.
Jenom jsem viděl několik clusterů, kde se porozdávalo více místa (asi se předváděli v tom, kdo ho má většího a tak porozdávali několik desítek TB, a když ty widle pak pustí defrag, tak se z thin stane thick) než bylo vůbec možno dostat do pole.
Pokud bys dělal nějakou evaluaci RHEVu pro vaše potřeby, moc rád bych si pak o tom přečetl. Co se líbilo, co se nelíbilo a tak dále. Určitě první zkus RHEV trial (je k tomu obsáhlá dokumentace) a rozhodni se na základě této zkušenosti. Ušetříš čas při „rozcházení“ když bys narazil na nějaký zádrhel (dokumentace je opravdu „otestovaná“ :-)
Právě včas – zrovna jsem chtěl ten VMware zkusit, takto to ani nemá cenu…
No, kdysi jsem rikal zkusme prejit na KVM, vmware je drahy, dejme ty penize do hardwaru a pripadne licenci komercni linux (RHEL)… Tusim ze absence pekneho klikatka (o ktere pises, ze v krizove situaci neni az tak potreba) byla pro nektere prekazka, proc KVM ne. Pak jeste tusim nekterym vadilo, ze KVM se pouziva ve srovnani s vmwarem krasi dobu nebo co. A ze vmware je velka firma, na kterou se muzes spolehnout – no, jak bych to, v pripade pozadavku na support to taky neni uplne super. Funguje to, ale…. Co do funkcnosti a stability nemam s KVM nejmensi problem, funguje, je stabilni, rychle, obcas narazim na problem (treba s windows guestem, ke kteremu je pripojen USB hw licencni klic jsem se celkem natrapil, nez jsem to dostal do spolehliveho stavu), ale ten by byl i s vmwarem. Takze mam nekde nasazene KVM, nekde HyperV a vmware prakticky nikde – nemam a neznam klienta, ktery by na smysluplne nasazeni vmwaru mel penize.
Nechci příliš odhalovat pro koho a co děláme, ale za posledních několik měsíců odešlo více než 10 hotových virtuálek. Jasně, šlo by to dělat třeba na free ESXi, ale… Kdyby zbytek jel na KVM, tak konvert mezi KVM a ESX by taky něco stál. Takhle udělám clon a je to.
Mě osobně je též dnes určitě nejbližší KVM. Po instalaci Debianu se dá první virtuálka spustit za pár minut, po instalaci quemu-kvm. Parametry virt-install si nepamatuji, takže pokaždé zkoumám man.
Používáš na KVM nějaký manager?
Jo, je pekne, ze vmware ti jednoduse umozni vytvorit virtual, ktery nekomu jinemu s vmwarem bez problemu pojede. A precejen je vetsi sance, ze bude mit klient vmware, nez neco jineho…
Presne tak, kvm at uz na Debianu nebo CentOSu jede za chvilicku, virtualky jedou taky dobre. Ja pouzivam jenom virsh a obcas i virt-manager. Mel jsem rozchozeny convirture, ale nepotrebuju ho, mozna tu virtualku, kde byl nainstalovany, jeste nekde vypnutou mam…. V podstate me zajima jenom jede/nejede a sluzby fungujou/nefungujou.
Pokud jde o to – od 50 virtualek dela problemy – urcite to info nekde maji, treba nekde v materialech pro certifikacni zkousky, nebo je nekde nejake doporuceni. Je fakt, ze nekdy je problem tyto udaje volne najit. Ale i driv bylo info, ze MSSQL v plne verzi na serveru je OK a ze do nejakeho poctu stroju v podstate staci MSSQL Express klidne na desktopovem systemu a zadarmo. A pokud se to presvihlo, prestalo to stihat nebo ukladat dalsi data. Beh virtualu to neohrozilo. Jen nikde nebylo konkretni cislo, jenom doporuceni. A nikde zadna tvrda kontrola, proste to jenom pomalu vyhnivalo…. V podstate je to udelane pro firmu, ktera v zacatku da malo investic, a jak roste, da se predpokladat, ze se svym rustem ma i vic penez, ktere muze do virtualizace vlozit a da je tam (protoze virtualizaci zahodit a jit na fyzicke stroje uz od urciteho momentu jednoduse nejde). Pokud se ale ziskane finance z prodeje reseni vic nacpou do odmen, v horsim pripade navic jeste jineho oddeleni, nez do udrzby a rozvoje reseni, pak je problem. V zacatku ti staci i jedno free ESXi, i kdyz dnes uz radne licencne ocesane co do moznosti, a jak rostes, potrebujes vic a pokud je vse OK, kupujes drazsi a drazsi. Vem to jak firemni auta vedeni – ze zacatku staci, ze to jede, a jak firma roste, je potreba lepsi a lepsi (i kdyz to v podstate porad jenom jede, navic pri legislativnich limitech v podstate porad stejne. Jediny rozdil je v pohodli a pripadne narocich na servis – novejsi auto ma vetsinou lepsi pohodli, vetsi image a kdyz uz se po…, tak je to i vetsi prusvih – sice ne tak casty, ale uz to pak stoji za to – bezradnym mechanikem na suportu v servisu pocinaje a treba nechutnym uctem za opravu konce.)
Navic u vas resis pozadavek na nonstop provoz, asi ne vzdy se najde klient, ktery dovoli na tyden totalni odstavku jak s registrem vozidel a pak jeste dalsi mesic ladeni…. I kdyz se statni spravou se uz nedivim nicemu, ale to je jina pohadka.