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

[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