ESXi 6.0 - jak šel Exchange 2007 na samotné dno

2.7.2016 16:13 | Přečteno: 2809× | plky | poslední úprava: 2.7.2016 16:13

Tato pohádka je smutná, se smutným průběhem a smutně šťastným koncem.

ESXi 6 a menší připomínka

Nejdříve si připomeňme, jak ESXi funguje a jaké jsou možnosti zálohování. Toto rozebírám v tomto blogu :
Základní info o ESXi free a dlouhodobé zkušenosti

V současné době všude pomalu nasazuji ESXi 6.0 U2 + aktuální ghettoVCB. Tato verze ESXi má v sobě jednak nějaké opravy se snapshoty, jejichž inovování a problémy přinesla verze 6.0, dále má tato verze konečně i html web klienta. Je tedy možné s ESXi Free plně využívat práci s VM včetně nejnovějších verzí HW VM a odpadá tedy i nutnost používat starého windows klienta. Vzhledem k tomu, že máme zatím Free verzi, tak nemáme cluster, nemáme možnost live migrace atd., takže samotný upgrade hypervisorů je složitější a vyžaduje odstávky.

Exchange 2007 v současné době běží na verzi ESXi 6.0 + aktuální vmtools + verze hw je 8. Vzhledem k tomu, že plánujeme nákup licencí a rozjetí clusteru, tak jsem ani neplánoval, že bych provedl upgrade na současnou verzi ESXi, ale počkal bych až na ten cluster, kde by pak odstávka nemusela být, nebo by byla opravdu minimální. Bohužel, asi nebudu moci čekat :-/. I když celé řešení a zálohování bez problémů fungovalo asi půl roku, tak najednou nastal problém :-/.

ESXi + ghettoVCB

Jak vlastně funguje zálohování pod ESXi? Jednoduše, hlavní soubory s img celé VM jsou uzamčeny, nejde s nimi manipulovat. Je tedy potřeba v rámci ESXi vytvořit snapshot VM, tím se vytvoří delta file, kam se zapisují veškeré změny a původní soubory s VM se odemknou. Ty se odkopírují na backup storage a následně se snapshot zruší (delta file se mergne do hlavních souborů VM). V případě Exchange pak lze během dne odkopírovávat i transakční logy a mít tak vlastně zálohu Exchange i v průběhu dne.

Pápá Exchange 2007

Přijdu si tak do práce na sedmou a jako vždy vše zkontroluji, cestou do kanclu přes serverovnu, v kanclu zkontroluji nagios (méně důležité věci, nechci, aby mi chodil mail apod. když odpadne nějaké AP, nebo kamera atd.), následně juknu, jak proběhly zálohy (některé končí během dopoledne) a pak začnu vyřizovat maily. Vše plně ok, žádný problém. Ten ovšem nastal v cca 7:17, kdy mi volá uživatel, že poslal maila a kolegovi nepřišel, i když on ho má v odeslané poště. Zahajuji kontrolu, co to bylo za mail, odkud kam šel atd. I když vše běželo a vše se tvářilo ok, tak jsem našel v event logu windows serveru s exchange jednu nepěknou a nic neříkající chybu z času zhruba 7:15 (takže vím, že nemusím ani používat nagios, uživatel zjistí jakoukoli nefunkčnost služby do 2min od nějakého problému :D ):

MSExchangeIS, Event ID:10025
There are 20 RPC requests that take abnormally long time to complete. It may be indicative of performance problems with your server.

Podíval jsem se tedy do ESXi klienta, zda náhodou neběží ještě zálohy, ale síť nebyla využita, takže kopírování se nemohlo konat. Na VM nebyl v klientu vidět, že by byl vytvořen nějaký snapshot, takže záloha musela nutně doběhnout, ale maila jsem ještě neměl.

Transakční logy Exchange se vytvářely, všechny služby běžely. Jen těch transakčních logů bylo docela hodně - přes 54 000 v jednom adresáři (dělám jejich purge jednou za čas). Řekl jsem si ok, asi jich je fakt hodně v jednom adresáři, tak zkusím purge. Ten ale né a né doběhnout ani po trojnásobné době, co běžívá, takže kill, už není moc času, lidi chodí do práce.

• 8:03 - pokouším se o restart služeb Exchange
• 8:18 - stále se nechce ukončit db služba (běžně se ukončuje třeba jen minutu), zabíjím, ze zkušeností vím, že to není problém, data vždy přežijou
• 8:19 - vše se spustilo, db služba zjistila, že má k dispozici transakční logy, které ještě nejsou v db, začíná tedy import logů od 7:13, takže od této doby se neprovedl jediný zápis do db exchange, hodně divný :(. Dokud se logy nenaimportují, tak se storage služba nespustí.
• 9:46 - import všech transakčních logů se dokončil (začínalo se u 450 a jeden se ze začátku importoval 1min, od půlky jeden za cca 5-10s) - jednotlivé logy mají 1MiB, takže relativně málo dat
• 9:49 - chyba ID 10025 se znovu objevila, zkouším restart celé VM
• 10:01 - VM naběhla a chyba ID 10025 je tu znovu.
  Behěm restartu jsem viděl hlášku, že se maže snapshot VM s Exchange. U souborů s VM jsem pak viděl delta file a v logách, že se jej nepodařilo consolidovat (což udělal ten restart VM - při mazání snapshotu se nesmí VM vypnout, což restart udělal).
• 10:30 - zahájil jsem offline consolidaci snapshotu VM (tzn. VM jsem vypnul a ručně dal consolidovat snapshoty)
• 11:00 - spouštím poslední backup Exchange v izolované síti přímo z backup storage, dle časů to vypadá, že backup jako takový se dokončil, skutečně naběhl a vše v něm funguje. Maily jsou v něm poslední od půlnoci, kdy záloha započala, takže zadní vrátka v případě neopravení produkce tu jsou a jsou v pořádku (teoreticky by případně neměl být problém dohrát transakční logy z rozbitého Exchange a dostat se tak do aktuálního času).
• 11:15 - šéfové oddělení se sešli a závěrem bylo, že se nepoužije záloha, ale počká se na doběhnuté současné akce
• 14:15 - consolidace doběhla
• 14:18 - vše běží, postupně se vyprazdňují fronty, na Exchange přes 900 emailů na odeslání, na linuxboxu přes 4200 emailů

Kde nastal problém?

Dle všeho je evidentní, že po dokončení zálohy se začal mazat snapshot (začal se aplikovat rozdílový delta file). Hned poté hlásil Exchange přetížení. Delta file měl asi 125GiB a aplikování změn v offline režimu trvalo 4 hodiny. Buď za vzniklou situaci mohlo to, že VM má starší verzi HW, nebo to, že tato verze ESXi má u snapshotů nějaké chyby a měl jsem dávno přejít na 6.0 U2. Taktéž je možnost, že vše nastalo formou několika faktorů (stará verze ESXi + stará verze vm hw + hodně transakčních logů exchange), protože když to půl roku jede, tak proč až teď chyba.

Každopádně práce se snapshoty u ESXi je pomalá a náročná operace a rychlost aplikace transakčních logů u Exchange mně taktéž neohromila, i když je pravda, že v té době musel běžet merge delta file, takže asi mohla být rychlejší. Další věcí je, že jsem nemusel čekat na aplikaci transakčních logů, měl jsem znovu killnout proces storage a rovnou jít na offline consolidaci snapshotu. Poté mohla aplikace transakčních logů doběhnout rychleji, jak za 1:15.

Jak do budoucna?

Už hodně dlouhou dobu přemýšlíme o řešení formou koupě "Standard" licence na ESXi + nejvyšší verzi Veeam backupu + NetApp. Nejvyšší verze Veeamu umí pracovat se storage (NetApp, HP 3Par atd.). Lze tak používat snapshoty v rámci storage, které budou 100% konzistentní, protože to celé bude řídit Veeam a ten před vytvořením storage snapshotu řekne všem VM, aby flushly data. Celý NetApp se pak může pomocí SnapMirror kopírovat na NetApp v záložní lokalitě a mít tak data i snapshoty v obou lokalitách a obnovovat z jakéhokoli času. NetApp se svým WAFL je něco jako ZFS / btrfs, jen je z nich nejstarší, takže si myslím, že je to celkem rozumné.
Dále pak ani není problém VM replikovat na backup storage a mít tak data na třech místech.
Další výhodou pak bude to, že Veeam mj. umí automaticky kontrolovat funkčnost zálohy a dělat o tom reporty. Tím nám odpadne další velká starost (kontrolovat zálohy a jejich funkčnost)

Pokud do toho půjdeme, tak se o celém řešení i o NetAppu samozřejmě rozepíšu. Jinak ve hře jsou i jiná řešení, jako např. samotné ZFS, Nexenta Stor (tady asi ne, cena za licenci je masakrální), vlastní cluster storage (Ceph, Sheepdog), VMWare Metro Storage Cluster (vMSC) a další a další. Nastudováno je mnoho a ceny jsou též známé, takže až bude po všem (po létě), tak to sepíši a uvedu důvody, proč to a né ono.

Jinak v současné době provádím online cross domain migraci Exchange 2007 na Exchange 2013, fakt žůžo labůžo :-/. Nicméně Exchange 2013 je mnohem méně náročnější na IOPS, než Exchange 2010 a ten zase než Exchange 2007, takže očekávám lepší výkon a menší zabíjení pole. Dále upgrade na novější verzi Exchange je nutnost, protože Outlook 2016 již s Exchange 2007 nefunguje.

Závěr

Problém s touto odstávkou, která byla nejdelší v dějinách (doteď jedeme snad 99,99 + údržbové odstávky mimo hl. prac. dobu), je samozřejmě má chyba a mohl jsem v některých věcech urychlit řešení problému. Osobně doufám, že konečně přejdeme na HA a těchto problémů se zbavím. Mezitím mám teď v době dovolené naplánovanou odstávku a upgrade ESXi u Exchange. ESXi 6.0U2 (a hlavně i 6.0u1b)jsem započal testovat už dřív, jen jsem otálel s nasazením (moc práce, žádný volný čas po večerech atd.).

Zdar Max        

Komentáře

[Pan_Filuta]

Zdraví, díky za zkušenost. Chtěl bych se jen zeptat - na jakém os vám Exchange běží? Hádám 2003, jinak by jste zálohoval přes Windows Backup ve 2008?

Jak jste tak rychle zprovoznil aktuální zálohu Exchange v izolované sítí? Napadá mě jen mí připojený backup storage přes NFS a mít přes gheto rovnou k dispozici VMDK soubory ?

Nakonec jsem se chtěl zeptat - jsou zálohy Exchange přes gheto konzistentní ? Pokud by byl Exchange ve vypnutém stavu, tak ano. Ale v zapnutém? (sám jsme ghetto jen testoval před lety, ale hlavně spravuji hyper-v hypervizory).

A úplně poslední dotaz - pokud zálohujete celý VM - případě obnovy by jste stejně musel spustit nějakou Exchange obnovu ze zálohy, aby Exchange věděl že byl obnovený ne (něco ve stylu neautorativní obnovy AD)? Nemůže pak dojít k problému synchronizace mailboxů ? Vycházím z https://technet.microsoft.com/en-us/library/jj126252(v=exchg.141).aspx# (Requirements for Hardware Virtualization)

Díky

PS: soucítím s vámi, čeká mě migrace z Exchange 2013 na 2016 :/

[Max]

Exchange běží na W2008R2. Záloha celé VM se dělá, protože je lepší mít celou VM, k čemu mi je dump Exchange, který nemám kam obnovit?
Záloha je konzistentní. Tato záloha je konzistentní i v případě, že se NEpoužije volba Quiesce (vmware tools zařídí, aby všechny app fushly data na disk, něco jako : teď dělám VSS, tak s tím počítejte)
Vytvoření snapshotu bez "Quiesce" je jako výpadek proudu. Stroj musí prostě naběhnout, tyto ACID normy dnes splňuje snad všechno.

Dělám backup na NFS storage, takže není problém přímo z NFS spustit VM a běží to jak z lokálního storage. Je to otázka chvilky. Takto spuštěnou VM nemusím pouštět do ostré sítě, mohu jí dát třeba do virtuální, jen aby měla síťovka link a stav funkčnosti pak ověřit přes KVM.

V současné době máme AD na stejné VM jako Exchange, tzn. oficiálně nepodporované řešení. Takto to provozujeme asi 7 let. Nejdříve na W2003R2, nyní na W2008R2. Obnovuje se tedy i AD, takže jsem nikdy ani neřešil. Aktuálně migruji stanice do AD (používali jsme NetWare, tak proto) a přecházím z domény "firma.local" na "corp.firma.cz". Takže dělám právě online cross domain migraci. Online migrace ve stejné doméně je easy.

Ten linkovaný dokument ohledně Exchange, už jsem to myslím někdy četl. Nevím, co si o tom mám myslet, třeba toto :
All storage used by an Exchange guest machine for storage of Exchange data (Exchange Binaries, Transaction Logs, Transport or Mailbox or Public Folder Databases) must be block-level storage because Exchange 2010 doesn’t support the use of non-block-level storage protocols, such as, but not limited to NFS or CIFS/SMB. The volumes must be block-level storage protocols from the storage device to the guest machine. It also isn’t supported to present a volume to a hypervisor using a non-block-level storage protocol, even if the hypervisor presents the volume to the guest machine as a block-level storage protocol. The following virtual disk requirements apply for volumes used to store Exchange data:
Virtual disks that dynamically expand aren't supported by Exchange.
Nevím, jak to mám chápat, zamýšlel autor textu, že NFS ani SMB není podporováno? A to ani v případě, že bude prezentováno VM jako blokové zařízení? To samé s rozšiřováním hdd.
Něco třeba zde : NFS and Exchange - not a good combination
Rozšiřoval jsem storage Exchange 2007 za běhu asi 15x (z toho asi 10x z linuxu při odstávce u W2003R2 a zbytek online ve W2008R2), nikdy problém. Firmy, co nám navrhují nový storage tlačí na používání NFS, dokonce i v případě Oracle pomocí dNFS.
Dále třeba zde : Exchange & NFS in VMWare - My thoughts on why this can work
Mně to celý přijde od MS ujetý. Už nevěřím ničemu, co kde napíše.
Zdar Max

[Pan_Filuta]

Díky za odpověď. Já Windows virtuály nízko nákladově zálohuji právě přes kompletní Windows Backup - provádím kompletní "bare metal recovery backup" většinou na iscsi úložiště.

Obnova celého OS je pak jednoduchá, jen se v novém virtuálu nabootuje z Win CD, zvolí se obnova (iscsi se mezitím připojí na jiném stroji a nasdílí Windosově). Obnova pak proběhne přes sdílené složky. Ale dá se vyrobit také Win DVD ve kterém je iscsi klient už zabudovaný. Výhodou je, že aplikace (AD a Exchange) se dozví že byli obnoveny ze zálohy. A jde obnovit třeba i jen Exchange DB. Taky je super že se přes shadow copy ukládá více předchozích záloh, zrovna koukám že 300GB Exchange Server zálohovaný na 900GB disk nabízí k obnově 23 kopií.

Jinak zrovna u vašeho řešení kdy je AD a Exchange ne jednom serveru bych se bál situace kdy by bylo nutné obnovit autoritativně doménu - přece jenom u obnovy system state s nainstalovaným exchangem se může stát ledacos :)

Co se týče VSS zálohy, ta je určitě konzistentní - ale právě nevím (a to mě děsí co se stane když takto obnovíte exchange do dřívějšího stavu, bez toho aby věděl že byl obnoven - zda nemůže nastat problém třeba v synchronizaci klientů, když ty mají novější poštu...ale opravdu nevím.

Tomu co zaminují v tom dokumentu také příliš nerozumím, ale chápu to tak že to prostě ze strany MS není podporováno a mají o starost méně - třeba v roce 2013 ze kterého je ten článek narazili na nějaké problémy. Ale věřím že vmware to má pořešené. Já jsem většinu serverů převedl z bezplatného esxi na hyper-v - jak z licenčních důvodů, tak z praktických (třeba zálohovací možnosti)

[Max]

Nj, problém je, že já to dokážu obnovit v čase startu VM, tzn. do 10min mi to ze zálohy běží. Bootovat cd a obnovovat je na dlouho.
Jinak jednou jsem na SBS2008 obnovoval Exchange z VSS a bez problémů. Nevím, jak k tomu došlo, ale prostě se celá db posrala. Sáhnul jsem do VSS a obnovil jsem jen adresář s db a logy, ale to neprošlo, tak jsem nakonec obnovil celý adresář s Exchange a bez keců se spustil a jel.
Zdar Max

[Max]

Jinak náš Exchange má asi 2x700GiB databáze, takže nejrychlejší způsob obnovy je buď spuštění VM, nebo mít někde standby Exchange a importovat do ní logy v nějakých intervalech (ale tady je to špatný s licencí a těžko říci, jak dobře to jde, lepší je inkremental celé VM). Obnova přes CD a další věci je nemožná, čekat, až se mi někde po Gbit licence přeleje přes 1TiB dat, to ne, to je minimálně na 4h.
Zdar Max

[Pan_Filuta]

Určitě souhlasím, vaše metoda přímé spuštění zálohy je to nejrychlejší co jde vymyslet - u hyper-v to pokud vím není možné (export není vss konzistentní), ale snad to půjde ve Srv 2016 kde jde dělat produkční snapshoty. Díky za diskuzi

[Max]

Mno, slyšel jsem, že je hyper-v v dost věcech pozadu. Zdarma je bez centrálního mgmt, takže takové ESXi Free. S live migracema má prý stále problémy, takže slušné HA/FT pod hyper-v nejde, nemá implementovány žádné QoS technologie a s hotplugem má prý také problémy. Ale fakt nevím, nezkoušel jsem. Ale podle toho, co jsem slyšel, tak je pomalu free verze ESXi lepší, jak hyper-v zdarma. A pokud jde o licence běžících VM s win, tak není v obou případech rozdíl.
Zdar Max

[Pan_Filuta]

Pravda, centrální management chybí - je to bolístka. Live migrace na druhou stranu běží v pohodě - kompletně online bez výpadku sítě. Jen jen nutné pro každý hyper-v host povolit kerberos delegaci, viz třeba https://www.benday.com/2013/05/09/problem-moving-virtual-machines-between-hyper-v-2012-hosts/ Taky je šikovné možnost si vytvořit export VMkka zaživa - třeba pro diagnostiku offline.

QoS je myslím k dispozici pro úložiště, je možné nastavovat min/max IOPS pro vhd. V gen2 virtuálech jde taky přidávat/odebírat živě scsi disky - a od verze 2016 taky sítovky

Co je v hyper-v super je windows backup (opět :) ) s podporou hyper-v. Jde to dobře používat i na linuxové virtuály - MS nabízí VSS daemona který zajistí konzistentní zálohu. A opět je možné mít desítky verzí zpětně na malém uložiti

Co se týče licence - já si jí vykládám že že je možné mít Windows přímo na HW a k tomu dva Windows virtuály s jednou licencí.

[Max]

Windows server 2012 Standard umožňuje běh dvou instancí na maximálně dvouprocesorovém serveru. Výjimkou jsou tři instance s tím, že ta jedna slouží čistě pro hyper-v, nad kterou běží ty dvě zbylé instance (dvě VM). V takovém případě v té instanci s hyper-v nesmí běžet žádná jiná služba.
S windows server 2016 se licenční politika mění a počítá se s jádrama CPU, do určitého počtu jader to bude shodné s W2012, nad určitý počet jader si člověk připlatí.
Z licenčního hlediska je tedy jedno, zda provozuješ hyper-v, nebo ESXi
Zdar Max

[Pan_Filuta]

Zdravím, omlouvám se že píšu do tak staré diskuze, ale konečně jsme si udělal čas na porovnání obnovy Exchange z Windows Backupu a z hyper-v snaphotu (ve vypnutém stavu). A musím Vám dát za pravdu

Loni jsem zde zmiňoval obavu, že při obnovení ze snaphotu může dojít k problémům synchronizace mezi serverem a Outlook klienty - konkrétně jsem neměl jasno jaký osud potká zprávy, které díky rollbacku zmizí se serveru a budou jen v Outlooku.

Ukázalo se že při obnovení Windows Backupu i obnovení snaphotu mají stejný osud - zůstanou v Outlooku a na server se neprosynchronizují. To jde ale v rychlosti opravit třeba přesunem posledních zpráv do nějaké složky a pak zpět (v Outlooku) - pak se na OWA objeví.

Čeká mě větší aktualizace Exchange 2013 na serveru s hodně pomalým uložištěm, tak pravděpodobně použiji vaši metodu obnovy ze snaphotu - pokud by se něco opravdu hodně pokazilo (samozřejmě Windows Backup bude druhý záložní plán :) )

Takže děkuji za článek, rozšíření obzorů, inspiraci a snad trochu méně stresující upgrade

[Heron]

Delta file měl asi 125GiB a aplikování změn v offline režimu trvalo 4 hodiny.

Z komentářů jsem pochopil, že ten VM má 1.4TB. Jak dlouho ta záloha běžela, že to mělo 125GB? U nás používáme Veeam, ten umí CBT, záloha 600GB VM je hotová v řádově v minutách, snapshot se maže max pár desítek sekund. I kdyby to byla fullka, tak 125GB změn na poštovním serveru za pár hodin, to je teda hukot.

Behěm restartu jsem viděl hlášku, že se maže snapshot VM s Exchange. U souborů s VM jsem pak viděl delta file a v logách, že se jej nepodařilo consolidovat (což udělal ten restart VM - při mazání snapshotu se nesmí VM vypnout, což restart udělal).

Tohle info, že se během odstraňování snapu nesmí vypnout / restartovat VM, máš odkud? Během odstraňování snapu je vm plně funkční i pro zápis, nevidím tedy žádný důvod, proč by se ten stroj neměl vypnout.

Jinak po update verze VM HW na 10 jsme zaznamenali problém, že během zapracování snapshotu (což se děje několikrát denně po backupu) se stroj na poměrně dlouhou dobu, až minutu, pauzne. Nevim proč, VM 9 to nedělá, při live migraci storage to taky nedělá, možná další buga ve veeamu.

[Max]

Ahoj, samozřejmě vše jede online, ale fakt nemůžeš VM vypnout a myslím, že ani dělat během toho procesu live migraci. ESXi mi to hodil do logu.
Záloha běžela celé VM po 1Gbit lince, tak si to spočítej, v tomto případě to bylo reálně kolem 7h (takže během toho času v noci, kdy toho moc neteče, Exchange změnil 125GiB dat)
CBT použít nejde, páč máme free verzi. Až koupíme licenci, tak se samozřejmě vše hodně urychlý.
Jinak jak migruji na ESXi 6.0U2, tak tam je VM HW 11, tak uvidím.
Zdar Max

[ET]

hey, tech 125GiB mi pripada moc, mozna by tomu odlehcil tuning maintanance modu

[Max]

Já vím, už jsem to jednou upravoval a asi to úplně scratchuju a budu dělat maintenance jen o víkendu ...
Zdar Max

[Max]

Jinak podle popisu to je spíš buga ve vmware ...
Zdar Max

[Heron]

Ne, je to problém veeamu. Veeam má několik modů jak se dostat k diskům zálohovaného vmka. A mají tam bugu, kdy v jedno režimu si to drží NFS zámky příliš dlouho, vm nemá kam zapisovat, tak se pauzne. Při změně módu na nějaký jiný to funguje ok. (Názvy neuvádím schválně, musel bych se zeptat kolegy - já si nechci špinit ruce, proto na sračky nesahám, takže si interní věci veeamu nepamatuju.)

[Ruža Becelin]

konečně i html web klienta.

Hahaaaaa.... sorry. Na html klienta ceklali vsichni jak na smilovani, ale nez pouzivat ten zabrzdeny shit, to se radsi drzime toho .Net fujajblu. Jestli e ve VMware neproberou a neco s tim neudelaji, tak jim zakaznici udelaji papa uz jenom kvuli tomuhle, pokud uz ne kvuli predrazenem ESXi, kteremu pomalu dochazi dech.

[Max]

Heleď, nějak zatím nepozoruji problémy. Nemá to online look, mají tam refresh button, ale jinak nemám výhrady, ani k rychlosti.
KVM taktéž ok.
Zdar Max

[Ruža Becelin]

To mas kliku, pri vetsim mnozstvi VM to jde totalne do kopru...

[Max]

Aha, pravou je, že mám na jednom serveru max. 10VM
Zdar Max

[Max]

Tak doupgradovávám další hv a máš pravdu, někdy to není nejsvižnější. Ten win klient je na tom lépe. Mno, ještě, že takové věci nemusím skoro vůbec používat.
Zdar Max

[Vantomas]

Je to přímo tragické. Taky doba, kdy se do prohlížečů instalovaly pluginy je tatam.

Nevím jak je to v případě přímo ESXi, ale když je vSphere, tak naštěstí se dá připojit Win klientem a jdou takové ty věci jako vypnout/zapnout, připojit se na konzoli, změnit nastavení síťovky, migrovat, atd. nejdou jen editovat ty věci, které jsou specifické pro HW v10 a výš, na to se musí používat web rozhraní.

[Max]

Já to vím moc dobře a popisuji to i v tom předchozím článku. A není to HW 10 a výše, ale HW 9 a výše. Win klient podporuje max HW 8.
Zdar Max

[Ruža Becelin]

Jinak co jde, resim PowerShellem. Je to mnohem pohodlnejsi a rychlejsi...

[Chulda]

bacha na to, že web rozhraní má "fíčury", které jsou ve vshpere klientovi nedostupné :(

To pak člověk půl hodiny hledá, kde se to nastavuje, aby to pak přes web našel hned.

[Max]

Např.? Když teda pominu editaci vyššího VM HW, jak 8 ve win klientu, tak co na webu verzi najdu dalšího?
Při běžném procházení jsem zatím nenarazil na nic, co není ani ve win klientovi. Jop, nenašel jsem tam jak připojit iso jinak, než přes datastore. Win klient umožňuje připojit lokální iso. Ale třeba jsem jen špatně koukal. Navíc toto je nepodstatné, ale stále to je +1 fce ve prospěch win klienta.
Zdar Max

[Chulda]

z hlavy si to nepamatuji, ale měl jsem třeba problém přiřadit uživatele do skupiny. Vsphere klient to neumí. Jsou to takové drobnosti, proto jsem psal ty fíčury v uvozovkách.

I když teď jsem si uvědomil, že nemáš vcentrum.

[Ruža Becelin]

Když teda pominu editaci vyššího VM HW, jak 8 ve win klientu

To umi Win klient taky, akorat se musi nainstalovat jeden update a u verze 9-10 to pokazde remca, ale funguje...

Nejlepsi alternativa podle me bude napsat si wrapper nad PowerCLI (PowerShell SDK). Jinak si zrovna pisu C# klienta, protoze mam neschopnosti VMware plne zuby....

[citanus]

Jop, nenašel jsem tam jak připojit iso jinak, než přes datastore. Win klient umožňuje připojit lokální iso.

Tusim ze to funguje, jen kdyz mas otevrenou konzoli na virtualku a mas "VMware Client Integration Plugin"..

[R]

Presne kvoli takymto pruserom sa vyhybam sprave uzavreteho SW (M$, VMware...), kde nikto netusi, co sa vnutri deje. Vsetko sa tvari ruzovucko a jednoducho, ale len do momentu ked sa nieco poserie... Potom je spravidla velky problem, niekedy az neriesitelny. Aby sa takymto problemom predchadzalo, tak sa nakupuje dalsi drahy uzavrety SW (vsetko v ramci "setrenia" a "znizovania nakladov") na clustery a zalohovanie - a ked sa poserie ten, tak je z toho megapruser. Napriklad som videl vypadok celeho clustera VMware.

[Heron]

+1

[Max]

Bohužel nemám s ničím větší zkušenosti. Provozuji pár VM na kvm, ale jsou to nedůležité stroje a zvolil jsem ze začátku špatně a použil raw / LVM. Až to budu předělávat, tak to stejně asi půjde do ESXi clusteru, ale snad si najdu čas a ještě si pohraji.
Zkoušel jsem oVirt a tomu nevěřím. Ohledně Xenu jsem slyšel o bugu, kdy zacuklý win zacukly celý hypervisor. Ale to se týkalo verze ob starší, takže teď se asi nic neděje.
Komplexní řešení v podobě oVirt jsem zkoušel a tomu nevěřím (i když poslední verze vypadá zase o něco slibněji).
Na ovirtu se mi líbí, že má klientský portál, takže by neměl být problém s virtualizací stanic. To třeba Proxmox nemá.
Mno, ale stejně je to jedno, protože nic jiného by u nás stejně neprošlo. Je to asi stejný případ jako u Herona.
Zdar Max

[Heron]

Mno, ale stejně je to jedno, protože nic jiného by u nás stejně neprošlo. Je to asi stejný případ jako u Herona.

Nevím, zda je to stejný případ. U nás se jistý člověk ve vedení kdysi zhlédnul v komerčních řešeních (do té doby bylo vše OSS), nějak si to dokázal prosadit u nejvyššího a od jisté doby některé systémy máme na komerčním softu (přes hlasité protesty ostatních v týmu). Po čase se ukázalo, že to bylo velmi špatné a velmi drahé rozhodnutí, jenže háček se už zasekl a teď se z toho bude velmi složitě manévrovat ven. Nevím, zda to u vás bylo také tak. V každém případě, já dál jedu čistě OSS, problémy, které tam někdo zavlekl se mě naštěstí týkají jen okrajově.

Mimochodem, teď se tam opět vetřeli nějací obchodní zástupci se "storage" systémy. No klasika, to co jsem měl před 10 lety zadara, tak dnes nabízejí za hezkých pár zlaťáků. Tak jim pokaždé pěkně poděkujeme a alespoň vím, že jdu správnou cestou.

[Ruža Becelin]

Po čase se ukázalo, že to bylo velmi špatné a velmi drahé rozhodnutí, jenže háček se už zasekl a teď se z toho bude velmi složitě manévrovat ven.

Za tohle dost casto muzou firemni fosilie, co vyrostly na MS doktrine a nic jineho neuznavaji. Nejlepsi, jak prosadit OSS ve firme, je OSS se supportem, oni pak kdyz vidi, ze to stoji, tak to akceptuji spis, nez kdyz je to uplne zadarmo...

[trekker.dk]

zvolil jsem ze začátku špatně a použil raw / LVM.

Co je na tom špatně?

[Max]

Co ti raw, resp LVM přinese? Absolutně nic, nemá to jedinou výhodu :-/.
qcow2 umí snapshoty díky copy on write, nebo použiješ btrfs, nebo zfs a budeš na tom ještě líp
S qcow2 můžeš bez problémů konvertovat mezi různými druhy img, je tedy i rychlejší portovat VM z jiného formátu do qcow2, než do LVM.
qcow2 umí copy-on-write klonování
Výkon qcow2 vs raw je ve spoustě věcí shodný (a qcow3 na tom bude ještě líp)
A jak použiješ např. lvm na nějakým clusteru? Hodně blbě .
Zdar Max

[trekker.dk]

Co ti raw, resp LVM přinese? Absolutně nic, nemá to jedinou výhodu :-/.

No, pro začátek to funguje, já jsem skromnej

qcow2 umí snapshoty díky copy on write

LVM je umí taky. I když kdysi dávno jsem slyšel něco, že je tam docela propad ve výkonu - možná to někdo opravil, to nevim.

S qcow2 můžeš bez problémů konvertovat mezi různými druhy img, je tedy i rychlejší portovat VM z jiného formátu do qcow2, než do LVM.

Což to je pravda, to dělám každý den dvakrát a trvá to strašně dlouho.

Výkon qcow2 vs raw je ve spoustě věcí shodný (a qcow3 na tom bude ještě líp)

Což znamená, že ve spoustě věcí shodný není - a rychlejší než s raw přístupem na blokové zařízení asi nebude. A to ještě za předpokladu, že použijete něco, kde vám nepřibude režie filesystému, na který ten image uložíte.

A jak použiješ např. lvm na nějakým clusteru? Hodně blbě

CLVM?

Jako neříkám, že je raw/LVM nějaký zázrak nebo nutně nejlepší možnost, ale zatím jsem nenarazil na to, že by mě něco nutilo používat qcow nebo dokonce litovat toho, že ho nepoužívám.

[Jendа]

LVM je umí taky. I když kdysi dávno jsem slyšel něco, že je tam docela propad ve výkonu - možná to někdo opravil, to nevim.

Na CentOS 6.5 byl furt. Podle mě je to z principu, změněné bloky to prostě do snapshotu leje sekvenčně, takže pokud na tom máš třeba žurnálovací FS, časem to pořád seekuje a I/O stojí.

[citanus]

qcow2 umí snapshoty díky copy on write

LVM je umí taky. I když kdysi dávno jsem slyšel něco, že je tam docela propad ve výkonu - možná to někdo opravil, to nevim.

opravil. Na ovirt/rhev se s tim da bezne a bezproblemu pracovat

Výkon qcow2 vs raw je ve spoustě věcí shodný (a qcow3 na tom bude ještě líp)

Což znamená, že ve spoustě věcí shodný není - a rychlejší než s raw přístupem na blokové zařízení asi nebude. A to ještě za předpokladu, že použijete něco, kde vám nepřibude režie filesystému, na který ten image uložíte.

No vmware podporuje RAW taky. rika se tomu "Raw Device Mapping" a duvody pro pouziti jsou officialne:

• Velky SAN disky po migraci physical -> virtual
• Vyuziti featur SANky, ktery by jinak bylo tezky pouzivat (zalohy, dr apod)

A jak použiješ např. lvm na nějakým clusteru? Hodně blbě

CLVM?

napr rhev/ovirt to pouziva a beha to.

[Jendа]

To podle mě není ani tak o uzavřenosti a otevřenosti, jako spíš o návrhu. Ostatně přímo do zdrojáků se při ladění dívám fakt málokdy. Oproti tomu různé enterprise molochy v Javě, Zimbra atd. sice mohou být otevřené, ale uvnitř je to taky magie a ladí se to fakt blbě.

[R]

Nie je to len o otvorenosti zdrojakov, ale celeho systemu.

Spravujem jeden server, kde je asi 200 schranok - 500 GB mailu. Kedze to je Postfix+Dovecot, tak data su v maildiroch a nie v nejakom binarnom blobe. Ziadne restartovanie db sluzieb, transakcne logy a vypadky 3/4 pracovnej doby.

[Vantomas]

No a potom se tam člověk připojí přes webové rozhraní, napíše něco do vyhledávání a čeká a čeká a čeká. Stejně tak se tam připojí emailový klient na počítači (nebo ještě hůř, na telefonu) a pořád se ověřuje a porovnává zda tam nejsou nějaké změny, což u těch telefonů má vliv na baterku atd. atd. A od toho tam všechny ty DB služby a transakční logy jsou.

[Jendа]

No a potom se tam člověk připojí přes webové rozhraní, napíše něco do vyhledávání a čeká a čeká a čeká.

Obsah mailu se v DB neukládá, ale předmět a odesílatel jo, tak budiž. Stejně bych spíš uvítal, kdyby tohle bylo bokem a soubory byly v maildiru. Vždyť by stačilo, aby to store/ nebylo uspořádané podle hashe, ale podle schránky a složek maildiru.

Software jako Xapian umožňuje vytvořit inkrementální invertovaný index i nad maildirem.

Stejně tak se tam připojí emailový klient na počítači (nebo ještě hůř, na telefonu) a pořád se ověřuje a porovnává zda tam nejsou nějaké změny

Počkat, jak vlastně funguje IMAP? Podle mě řekne něco jako „dej mi N nejnovějších a sleduj nepřečtené“. Normální IMAP server si tak na adresář hodí inotify watch a usne.

[Max]

To, zda mít maily v db, nebo v souborech, je věčné téma. Když používáš db, tak máš transakční logy, můžeš se dostat do jakéhokoli času a budeš mít 100% konzistenci. Stejně tak můžeš replikovat data (transakční logy) do vzdálené lokality a s velmi nízkými datovými přenosy a časy můžeš mít 100% to samé i na druhé straně. To samé můžeš docílit s dovecotem a rsyncem, nebo replikací rovnou na úrovni fs, nebo storage.
Pravdou je, že databáze vznikly za účelem ukládání velkých množství informací a jejich snadnému nalezení. A co jsou emaily? Převážně pár KiB velké texťáky, kterých může být v rámci jednoho mailboxu třeba 100 000 (toto je reálný stav u nemálo našich schránek).
Každopádně neprovozuji dovecot s postfixem na tak velkém počtu uživatelů a hlavně mailů, abych mohl porovnat výkonnost s Exchange.
K Exchange se blížím s KerioConnect (používá také maildir), kde mám teď aktuálně asi 370 uživatelů a 1TiB dat (Exchange 1,4TiB vs Kerio 1TiB), ale oběh mailů na Exchange je mnohem větší. Lidi na Keriu mají hodně divné pracovní postupy (posílají si všechno mailama, takže není u nich problém zaplnit 8GiB schránku do týdne).
Zdar Max

[R]

Dovecot ma dsync, planujem upgrade a nasadenie druheho serveru s tymto riesenim.

U nas tiez niektori ludia pouzivaju mail dost divnym sposobom. Je ich tam dost nad 10 GB, extrem je 26 GB a asi 1000 folderov, v odoslanych 21 tisic mailov (inde som radsej nepozeral)...

[Max]

Joj, to je stejný jako u nás :D
70k v doručené
20k v odeslané
Největší mailbox má asi 35GiB a to už hodně nadáváme uživateli, ať si to čistí (když se něco posere, třeba se soubory outlooku, nebo něco, tak sync a věci s tím spojené trvají dlouho, prostě manipulace ohledně opravy je pak zdlouhavá).
a fakt tolik složek v mailboxu, že Exchange vyhlásil dosažení default size limitu a musel jsem navyšovat ...
Pak máme jednu systémovou schránku, ta když se zapomeně pročistit, tak za pár měsíců je tam přes milion mailů a to už má problém s otevřením i exchange webmail.
Zdar Max

[Jendа]

Zimbra ale neukládá v databázi tělo mailu. V databázi je uložen záznam s pár metadaty (komu to patří, předmět, datum, odesílatel) a hash. Samotná zpráva je pak na filesystému v něčem jako /adresář/první_písmenko_hashe/druhé_písmenko_hashe/zbytek_hashe.

[Max]

To já vím, ale nevím, odkud bereš to, že mluvím o Zimbre.
Zdar Max