přejít na obsah přejít na navigaci

Linux E X P R E S, Ceph na poštovním serveru (SUSECON 2017)

POINT.X

Ceph na poštovním serveru (SUSECON 2017)

Ceph

Je tady první článek z konference SUSECON 2017 v Praze a je věnován případové studii nasazení technologie Ceph na poštovním serveru ve společnosti Deutsche Telekom.


reklama

SUSECON 2017

V hotelu Hilton Prague v pražském Karlíně (nedaleko české pobočky společnosti SUSE) ještě stále probíhá letošní ročník konference SUSECON, skončí až v pátek a i nadále budeme přítomni (štafetu účasti přebírá Antonín Judytka). Proto je první článek z této konference zaměřen na jedno zajímavých témat – celkové shrnutí konference vyjde až příští týden.

SUSECON 2017 - mezi stánky sponzorů konference SUSECON 2017 - mezi stánky sponzorů konference

Ceph jako úložiště pro poštovní server

Na konferenci SUSECON je prezentována řada případových studií z nasazení různých technologií. Jednou z nich je nasazení úložné technologie Ceph jako úložiště pro poštovní server v německé společnosti Deutsche Telekom. Hovořil o něm Danny Al-Gaaf, působící ve firmě jako Senior Cloud Technologist.

Deutsche Telekom provozuje pro své zákazníky e-mailovou službu TelekomMail. Je postavena na serverové technologii Dovecot, má aktuálně okolo 39 milionů poštovních účtů, 6,7 miliardy uložených zpráv a 1,3 PB dat. Dosud se data zpráv ukládala na NAS se standardním protokolem NFS (a s využitím shardingu).

O softwaru Dovecot

Dovecot je open-source software určený pro řadu úkolů v rámci poštovního serveru. Nejvíce se využívá přístup ke zprávám protokoly IMAP (včetně řady rozšíření) a POP3, dále může Dovecot fungovat i jako doručovací agent (přebírá zprávy od softwaru, jako je třeba Postfix, a doručuje je do schránek) s možností filtrů podle standardu Sieve, server pro správu filtrů (ManageSieve) a jako autentizační agent (ověřování uživatelů např. pro Postfix). Je aktuálně nejpoužívanějším IMAP serverem na světě.

SUSE slaví 25 let své existence SUSE slaví 25 let své existence

Problémy s NFS

Používání NFS pro ukládání zpráv a přístup k nim se ukazovalo jako výkonově problematické. Operace pro čtení a zápis tvoří v praxi dohromady jen 21 % z celkového počtu, zbytek jsou například práce s atributy, hledání souboru nebo přejmenování. Přitom objemově drtivě převládá přímá práce s daty.

S e-maily se obvykle pracuje tak, že se jednou zapíší (při příchodu nebo uložení z klienta) a pak už se jenom čtou (tedy způsob práce WORM). Záleží ovšem i na tom, zda se přistupuje z klasického IMAP klienta nebo z klienta webového. Zprávy bez příloh jsou velmi dobře komprimovatelné.

Kritická jsou metadata, která obsahují údaje o zprávách (např. o přečtení nebo štítcích), a dále indexy a cache. Pokud se poškodí indexy, jejich opětovné vygenerování znamená projít kompletně všechny zprávy a to je náročné na čas i výkon. Poškození metadat může znamenat ztrátu důležitých informací, které zprávy nesou (kdo si zprávy značkuje štítky, ví, o čem je řeč; pozn. aut.).

Zprávy i metadata lze ukládat klasicky do souborového systému (např. mbox nebo maildir), do SQL databáze nebo ve formě objektů (např. u cloudových úložišť S3 nebo Swift). Každé řešení má své výhody a nevýhody.

O technologii Ceph

Ceph je otevřená technologie pro distribuované objektové datové úložiště. Kromě objektového přístupu (RADOS) podporuje i přístup blokový a souborový. Data se replikují na více uzlů a je tak zajištěna ochrana proti selhání jediného bodu. Ceph je výborně škálovatelný, poskytuje rychlou samoopravitelnost a může fungovat na běžném komoditním hardwaru. Díky tomu je řešením spolehlivým, nezávislým na dodavateli a nabízejícím nízké náklady.

Danny Al-Gaaf při své přednášce Danny Al-Gaaf při své přednášce

Jak Ceph využít

Ceph nabízí různé způsoby přístupu pro ukládání dat. Liší se mezi sebou poměrně výrazně.

  • CephFS – souborový přístup. Trpí podobnými neduhy jako NFS, pro ukládání zpráv se nehodí (lze ale použít pro metadata), platformově závislý, vyžaduje přímý přístup do úložné sítě.

  • RBD – blokový přístup. Vyžaduje sharding, musí se řešit zvětšování úložiště, data nelze sdílet mezi klienty, použití není praktické.

  • RADOS Gateway – objektový přístup přes bránu. E-mailové zprávy lze ukládat přímo jako objekty, není potřeba přímý přístup do úložné sítě, hrozí ale problémy s výkonem.

  • Librados – objektový přístup přes knihovnu. Rychlejší a paralelizovatelné řešení, vyžaduje ale přímý přístup do úložné sítě.

Jak skloubit Dovecot a Ceph

Samotný Dovecot neobsahuje žádnou podporu pro objektové ukládání zpráv. V Dovecotu Pro (proprietární verze) je k dispozici plugin obox, který ale podporuje jen REST API a navíc je jeho nasazení drahé. Neexistovalo ani žádné hotové otevřené řešení. Proto se v Deutsche Telekomu rozhodli, že takové otevřené řešení nechají na své náklady vyvinout.

Vyvíjela ho firma Tallence s konzultacemi Wida den Hollandera (z firmy 42on.com) a firmy SUSE. Jako první krok bylo zvoleno hybridní řešení, které ukládá zprávy objektově a metadata souborově (přes CephFS). Cílem bylo, aby byl kód maximálně generický, rozdělený do knihoven, a aby se následně integroval do upstreamu.

Účastníci konference sledují přednášku o nasazení technologie Ceph Účastníci konference sledují přednášku o nasazení technologie Ceph

Výsledkem je knihovna librmb (pro objektové ukládání zpráv do Cephu přes knihovnu librados) a úložišťový plugin rbox do Dovecotu. Kód je napsán v jazyce C++, rozšiřován pod licencí GNU LGPL 2.1 a podporuje Dovecot ve verzi 2.2.21 a novějších.

Zdrojové kódy jsou k dispozici na GitHubu. Knihovna librmb je zatím součástí pluginu, ale je v plánu její vyčlenění a integrace do upstreamu projektu Ceph.

Vzhledem k požadavkům je potřeba použít nejnovější stabilní verzi Cephu, tedy „Luminous“. Deutsche Telekom využívá pro běh celého řešení produkty SUSE, konkrétně SUSE Linux Enterprise Server a SUSE Enterprise Storage.

Hardware se používá běžný, konkrétně servery HPE ProLiant DL380 Gen9 se dvěma CPU, dvěma 10Gb síťovými kartami a jen s HBA, bez řadiče RAID. Pro úložné uzly na metadata (CephFS) byly zvoleny servery s rychlými CPU (vysoká frekvence) a se SSD, pro uzly na zprávy (RADOS) pak se SSD a především HDD.

Servery jsou v datovém centru umístěny do dvou samostatných „fire compartments“ (požárních úseků, tedy z požárního hlediska zcela oddělených od ostatních), počítá se selháním serveru, switche, racku nebo požárního úseku. Data existují minimálně ve třech replikách.

Shrnutí

Ukázalo se, že Ceph může úspěšně nahradit NFS, při zachování nízkých nákladů (díky otevřené licenci) – zatím ve formě hybridního řešení, v budoucnu by se mohlo vyvinout řešení kompletně pro RADOS. Knihovna librmb může posloužit i pro jiná e-mailová řešení, než je Dovecot.

Plán dalšího vývoje (zdroj: prezentace k přednášce, CC BY-SA) Plán dalšího vývoje (zdroj: prezentace k přednášce, CC BY-SA)



Nahoru

(Jako ve škole)
Průměr: 1,25 | Hodnotilo: 4
 

Top články z OpenOffice.cz

Příspěvky

Tomáš Crhonek Ceph na poštovním serveru (SUSECON 2017)
Tomáš Crhonek 28. 09. 2017, 10:30:39
Odpovědět  Odkaz 
Nevím. CEPH testujeme asi tak rok a na produkční nasazení to (podle mého názoru) není. V podstatě se nám to kdykoliv na počkání podařilo shodit (specifickou zátěží) - data zůstala v pořádku, ale klienti se odpojili až do restartu cephu. Zkoušeli jsme jak CephFS, tak blokové zařízení RBD. Běžné servery, 10GBe síť, Intel server SSD jako ceph cache a běžné SAS disky jako OSD. Výkon poměrně nepřesvědčivý, spolehlivost nic moc.

Další věcí je chybějící dokumentace. Když jsem zkoušel podle Quick start nainstalovat tehdy stable verzi 10, tak to prostě nešlo, příkazy a jejich parametry neodpovídaly dokumentaci. Kolega, co měl větší trpělivost, to potom teda za násobně větší čas dal. Verze 11 nefungovala prakticky vůbec, byl tam jakýsi nový proces, který permanentně zatěžovat cpu na 100% (což by samo o sobě až tak nevadilo), ale v dokumentaci o něm nebyla ani čárka. A verzi 12 jsme zkoušeli ještě jako RC, ale to vydrželo bez zátěže běžet tak 3 dny a potom se to samo sesypalo.

Nevím, kde se stala chyba, neříkám, že je CEPH špatný produkt, ale tohle mě prostě zklamalo. Pokud nelze ani dokončit instalaci podle oficiálního návodu, jak tomu má člověk věřit, když potom nastane nějaký větší problém za produkčního nasazení?

--

Díky za pěkný článek, je z té přednášky záznam nebo slajdy s popisem té jejich architektury? Docela by mě to zajímalo.
Lukáš Jelínek Re: Ceph na poštovním serveru (SUSECON 2017)
Lukáš Jelínek 28. 09. 2017, 11:23:53
Odpovědět  Odkaz 
Záznam mám zvukový, mohu ti ho poslat (zveřejňovat ho nebudu). Slajdy jsou jen ty, na které vede odkaz pod obrázkem na konci článku.
Tomáš Crhonek Re: Re: Ceph na poštovním serveru (SUSECON 2017)
Tomáš Crhonek 28. 09. 2017, 11:36:51
Odpovědět  Odkaz 
To asi není nutné, pokud se nepořizoval oficiální záznam, tak to nebudeme hrotit. Slajdy si projdu.
Re: Re: Re: Ceph na poštovním serveru (SUSECON 2017)
KaliszAd 28. 09. 2017, 17:22:58
Odpovědět  Odkaz 
O Ceph i GlusterFS jako "nových" systémech jsem slyšel hodně zlého i dobrého ve smyslu, že mbusíte vědět, co a jak a že je to boj. Potom to ale jde.

Proto jsem se rozhodl pro kombinaci Pacemaker, Corosync, DRBD a minimálně na Failover s iSCSI to bylo fajn i když jsem to dost týral. Caching s SSD a dm_cache je taky fajn budu o tom přednášet na LinuxDays.

Jinak HPE VSA a VMWare vSAN jsou do určité míry konkurencí těmto přístupům. Pokud chcete něco podobného, ale bez osobní zodpovědnosti.
Tomáš Crhonek Re: Re: Re: Re: Ceph na poštovním serveru (SUSECON 2017)
Tomáš Crhonek 28. 09. 2017, 17:49:01
Odpovědět  Odkaz 
DRBD je strašně pomalé. Přesně v konfiguraci Heartbeard, DRBD a iSCSI jsme to provozovali někdy kolem roku 2009, režim active/pasive, jo, funguje to, je to snadné na nasazení ale naprosto pomalé pro jakýkoliv provoz. Zkušeli jsme i active/active s VMFS, ale v praxi nikdy nenasadili, přešlo se na trochu jiné řešení.

GlusterFS jsem chvíli testovat, na rozdíl od cephu bylo nasazení na 4 nody hotové do půl hodiny a šlapalo to na první dobrou. Interní NFS běželo no problémo, na rozumně velké soubory to bylo slušně rychlé. Ale víc zkušeností s tím nemám, Aleš Kapica říkal, že je docela problém s hodně velkými soubory (on to zkoušel pro image vmek), při kontrole synchronizace dat jsou ty soubory prostě nedostupné.

Na přednášku o dm_cache se těším, doufám, že bude záznam.

Ty komerční věci jsou brutálně předražené. Za stejné peníze postavím potřebný storage jiným způsobem a levněji.

Přidat názor

Nejsou podporovány žádné značky, komentáře jsou jen čistě textové. Více o diskuzích a pravidlech najdete v nápovědě.
Diskuzi můžete sledovat pomocí RSS kanálu rss



 
 

Lukáš Jelínek

Lukáš Jelínek

Šéfredaktor LinuxEXPRESu a OpenOffice.cz. Vystudoval FEL ČVUT v oboru Výpočetní technika. Žije v Kutné Hoře a podniká v oblasti informačních technologií. Ve volném čase rád fotografuje, natáčí a stříhá video, občas se věnuje powerkitingu a na prahu čtyřicítky začal hrát tenis.


  • Distribuce: Debian, Linux Mint
  • Grafické prostředí: KDE
  • Hodnocení autora: ***

| proč linux | blog


Redakční blog

Pavel Fric

Pavel Fric, 23. říjen

Nové motivy pro přehrávač Sayonara

Pomozte rozšířit možnost měnit vzhled programu za běhu


Pavel Fric

Pavel Fric, 28. únor

Lollypop


Pavel Fric

Pavel Fric, 29. listopad

Palapeli


Všechny blogy »