Změna infrastruktury: od virtualizace ke kontejnerům
Jak provozoval dříve Seznam svou infrastrukturu?
Je to klasický full-stack. Administrátoři se starají o hardware, ovladače, operační systém i aplikace. Ve většině případů to tak stále provozujeme. Mezi tím přišla virtualizace, na kterou jsme přibližně v roce 2007 velmi rychle naskočili také. Hlavní motivací bylo oddělit od sebe jednotlivé aplikace, aby se nemohly ovlivňovat. Ve stejné době přišly i vícejádrové procesory, což nám hodně pomohlo. Virtualizace umožnila nový hardware lépe využít.
Proč už tenhle způsob nevyhovuje?
Jak přibývalo lidí a hardware, ukázalo se, že překážkou je rozdílnost produkčního a vývojářského prostředí. Na jedné straně jsou experimentující vývojáři, na té druhé straně pak potřeba co nejstabilnějšího produkčního prostředí. Hodně času se trávilo řešením problémů mezi těmito prostředími.
Na trh se začaly postupně dostávat technologie velkých hráčů jako Docker nebo Kubernetes. Ty nám ukázaly cestu ven a nasměrovaly nás. Dnes tomu říkáme Seznam Computing Infrastructure (SCIF).
Jak dlouho tahle změna probíhá?
U nás přibližně dva roky.
Co vám kontejnerizace přináší?
Tím hlavním je agilnost vývoje, možnost dostat věci velmi rychle do produkce. Když máte dlouhou řadu lidí, kteří musí každou změnu zkontrolovat a otestovat, trvá vám i drobná úprava velmi dlouho. Tyhle technologie umožňují jednak celou cestu zkrátit, ale také aplikovat různé nástroje pro automatizaci, nasazení a testování. Výsledkem je auditovatelnost a opakovatelnost.
Sjednotila se nám také prostředí, takže když dnes vývojář něco vytvoří, má velkou naději, že to bude úplně stejně fungovat v provozu. Tohle bylo cílem. Moderní věci jako DevOps vlastně znamenají bořit technologické a lidské bariéry. Není pak vývoj a provoz, ale všichni používáme stejné technologie, postupy a služby. Cílem je doručit aplikaci co nejjednodušší cestou. Už máme týmy, kde vývojáři nasazují do produkce. K tomu se chceme postupně dostat s většinou našich služeb.
Co hodně diskutovaná bezpečnost kontejnerů?
To je problém. Náš centrální systém pro evidenci a správu serverů a operačních systémů, který nazýváme Puzzle, nám umožňuje mít přehled o tom, co je uvnitř jednotlivých kontejnerů. Můžeme pak sledovat například jednotlivé verze knihoven a vyvolat varování pro případ, že se objeví bezpečnostní chyba. Chceme se dostat do stavu, kdy se automat postará o přebalení obrazů, spuštění integračních testů a nasazení. To je ale hudba budoucnosti.
Kdo je Vlastimil Pečínka?
Vlastimil Pečínka je duší vývojář klasické školy se silnou provozní zkušeností. Ve společnosti Seznam.cz pracuje od roku 2004, podílel se na vývoji vyhledávače, e-mailu a titulní strany. Od roku 2006 je technickým ředitelem, s krátkou přestávkou v roli ředitele Výzkumu a vývoje. Je ženatý, má tři děti a baví ho volejbal a technologie kolem bitcoinu.
Seznam se uvnitř mění
Kolik je toho dnes v Seznamu takto provozováno?
Určitě ne víc než deset procent. Jsou kolem toho nějaké porodní bolesti – změna myšlení lidí, ale i technologické změny. Nabírá to ale na rychlosti a během letošního roku toho dramaticky přibude. Potřebujeme ale udělat nějaký vývoj, nestačí jen vzít původní aplikaci a pustit ji v kontejneru. Je třeba věci dekomponovat a do velké míry přepsat.
Směr je ale jasně dán, máme tu tři clustery s Kubernetem, dva openstackové clustery, službu log-as-a-service, aplikační load balancer a další. Základní kameny máme, teď investujeme do lepšího TLS a DNS managementu, aby byl plně automatizovaný a mohli ho využívat administrátoři i vývojáři.
Musíte migrovat službu jako celek?
Ne, migrujeme spíše části služby. Dnešní služba je jako pavouk – mnoho komponent, které spolu komunikují. U některých je přesun jednodušší, obvykle jsou to různé frontendy nebo procesy běžící na pozadí. Ty jsou relativně snadno přenositelné do Kubernetu. Pak jsou tu ale databáze a backendové služby, u kterých je to složitější. Takže se dnes už běžně stává, že logika služby běží v původním režimu, ale fontend už je v Kubernetu. Spojování obou světů přináší své problémy a nové výzvy.
V jakém časovém horizontu plánujete takto převést všechny služby?
Máme to v plánu, ale platforma se vyvíjí. Je naivní si myslet, že všechno se dá provozovat v Kubernetu. V prostředí SCIF hraje Kubernetes důležitou roli, ale je to soustava služeb, které konzumují vývojáři a administrátoři. Je to jako provozovat interní cloud, který může kdokoliv ve firmě využívat.
Pak jsou tu ale další služby, pro které se nám pořád vyplatí full-stack mít, cloud nespasí úplně všechno. Vyplatí se, pokud je v určité oblasti byznysová potřeba rychlého vývoje. Pokud ale některá klíčová technologie konzumuje celý hardware, pak se vyplatí jít vlastní cestou.
Příkladem je náš Hadoop cluster, který vznikl daleko dřív než myšlenka na SCIF. Máme velký Hadoop tým, který službu provozuje na vlastním hardware. Nechceme je tlačit do toho, aby se vzdali hardware a provozovali to v OpenStacku. Jsou tak klíčoví a velcí sami o sobě, že si vystačí jako samostatná jednotka. Vždycky to bude podobný mix.
Kolik fyzických serverů dnes používáte?
Dohromady jich bude přibližně 9 000 – polovina v každém z obou datových center Kokura a Nagano, plus v Kokuře máme vývoj a pak máme ještě třetí menší serverovnu tady v centrále. Ta slouží jako arbitr v HA, abychom měli lichý počet instancí. Pak je tu infrastruktura kvůli televizi, která není malá.
Hardware už dnes není tak stěžejní, ten zajímá jen určitý tým našich lidí. Ale s virtualizací se dnes už zaměřujeme spíše na jednotlivé operační systémy. Ty spravujeme a díky virtualizaci je jich pětkrát až šestkrát víc než fyzických serverů. K tomu je už potřeba nějaký orchestrační nástroj.
Jaký orchestrační nástroj používáte?
Máme vyvinutý vlastní systém Puzzle, do kterého se všechny systémy samy zaregistrují a poskytují o sobě nové informace. Puzzle sám o sobě není orchestrační nástroj. Orchestrací je spíše soubor nástrojů, kam zapadá vedle Puzzle i Kubernetes s OpenStackem, ale také např. Gitlab CI nebo někde Jenkins
Používáte pořád ještě Debian?
Naše servery vždy běžely na Debianu, kontejnery teď sestavujeme také na jeho základě. Máme tu už ale i Ubuntu a bavíme se o dalším rozšíření distribucí. U některých služeb nedává smysl, abychom je provozovali na takto velkém systému, ale stačil by nám Alpine Linux nebo čistý Busybox a podobně. Chceme ale zůstat u vlastního repozitáře, abychom nebyli závislí na externím řešení, které by mohlo kdykoliv skončit.
Změna v load balancingu a síti
Jaké nástroje používáte pro load balancing v takto komplexním prostředí?
Historicky máme ještě nakoupené řešení od F5, ale čeká nás postupná změna související právě s přechodem na SCIF. V původním řešení používáme velkou L2 síť, tedy switchování. Všechny naše servery komunikují v jedné obrovské doméně, která je samozřejmě rozdělena pomocí VLAN, ale přináší to své problémy.
Nově přecházíme na L3, tedy na routovanou síť. Budujeme si tady malý internet (smích). V tomhle prostředí vyvíjíme také vlastní balancing postavený na Nginx a consistent hashingu. Pomocí routingu se umíme s provozem trefovat do jednotlivých strojů a Nginx nám pak zajišťuje TLS terminaci a komunikaci s endpointy v Kubernetu. Je to vlastní řešení, kterému říkáme Labrador.
Balancujete i mezi oběma datacentry?
V současné době používáme DNS balancing, kdy posíláme uživatele na různé IP adresy. Když vypadne lokalita, umíme z DNS příslušné adresy odebrat a díky nízkému TTL se nám během pěti minut naprostá většina uživatelů přepojí do druhé lokality. Do budoucna zvažujeme anycast, tedy řešení na úrovni sítě.
Všechny lokality máte vzájemně propojené?
Ano, máme vždy minimálně dvě redundantní trasy a všechno je vzájemně propojené.
Jak vypadá infrastruktura vašich datových úložišť?
My jsme vždycky sázeli na lokální disky, protože tahle varianta nejlépe škáluje společně s růstem počtu serverů. V současné clusterové době sázíme na objektovou storage, na kterou používáme Swift od OpenStacku. Používáme i Ceph, ale zatím jen pro televizní studio. Plánujeme ho ale nasadit i jako službu do SCIFu jako obecnou objektovou storage.
Neplánovali jste někdy otevření vlastního veřejného cloudu?
Ne, protože to je úplně jiná disciplína. Naopak jsme uvažovali, jestli se nevyplatí naši infrastrukturu provozovat někde jinde – třeba u Amazonu. Dospěli jsme k tomu, že naše vlastní řešení je levnější, ale hlavně si pak můžeme věci sami ohnout. V případě využití cizího řešení bychom zůstali závislí na technologii někoho jiného. Pořád považujeme svou technologii za konkurenční výhodu.
My tedy ven nechceme a neplánujeme ani pustit zákazníky dovnitř. Je to úplně jiný způsob podnikání – najednou na vás někdo spoléhá a vy musíte stavět věci jinak. My se můžeme rozhodnout nároky trochu snížit, protože máme věci pojištěné v druhém datovém centru nebo prostě tím, jak máme služby napsané. To ale nemůžete předpokládat u nějakého partnera.
Pro něco takového bychom museli vybudovat nové zázemí, podporu, zajistit konzultanty a podobně. Tohle neděláme. My působíme na mediálním trhu, ne na technologickém.
Vlastní hardware
Je pravda, že si vyvíjíte vlastní servery?
Už když jsme otevírali vlastní datové centrum, jsem vtipkoval, že dalším krokem bude vlastní hardware. Servery si můžeme normálně koupit, ale pokud si začneme stavět vlastní, okamžitě se nám otevírají další příležitosti. Založili jsme tedy projekt Montovna, v rámci kterého si stavíme servery.
Běžná řešení mají spoustu hezkých vlastností určených k tomu, aby se dobře prodávala. My ale nevyužijeme ani dvě třetiny, protože dnes je toho spousta zajištěna v software – třeba odolnost proti výpadku. Naše servery tedy umí jen to nejnutnější, nemají tam tolik elektroniky, nemají tak naleštěný hardware a chybí jim značka. Stavíme je ale o třetinu levněji.
V Kokuře vlastní servery provozujeme už přibližně rok a letos máme v plánu je začít dávat do Nagana. Budeme je tedy mít v obou datových centrech.
Takže nakoupíte skříně, zdroje, desky, paměti a skládáte vlastní počítače?
Jsme ještě trošku dál, vyrábíme si vlastní skříně (smích). Inspirovali jsme se projektem Open Compute od Facebooku a do racku dáváme 12U skříň s vlastními zdroji a dovnitř se pak vejde 24 šuplíků s počítači napájenými 12 V. Jelikož je formát jednoho počítače menší než půlka U, jsme schopni dát do jedné skříně dvakrát tolik serverů.
Šetříme také na zdrojích, protože máme v šasi šest 2KW zdrojů místo 48 zdrojů od dodavatele jednotlivých serverů.
Takže vlastní řešení po vzoru Blade?
Já mám Blade spojené s tím, že mají centrální správu a switch. U nás je každý server úplně samostatný, využívá jen centrální napájení.
Co přesně vašim serverům chybí proti komerčně dostupným řešením?
Nemáme tam hardwarový RAID, protože dnes už není problém se stabilitou ani výkonem softwarového řešení. Zároveň tam nemáme spoustu elektroniky, které tam dodává výrobce: diagnostiky, raiser karty a management. Ten jsme stejně nevyužívali, protože každý výrobce ho dělá jinak a nejsme schopni držet žádnou monokulturu.
Takže na vlastních serverech vůbec management nemáte?
Máme, ale jen ten úplně základní. Nám vlastně stačí server zapnout, vypnout nebo restartovat. Pokud chceme něco pokročilejšího, máme vlastního agenta Selfcheck, který dodává data do Puzzle. Jsme sami sobě cloud providerem, takže se nemusíme spolehnout na management serveru.
Navíc použití konzole v managementu je manuální práce a pro nás je výhodnější podpora protokolů jako je Redfish.
Malé servery s procesory ARM
Stavíte ale ještě nějaké servery s procesory ARM, že?
Inspirovali jsme se Turrisem a stavíme vlastní armový server velikosti SSD. K němu přidáme jedno SSD a dáme do šuplíku kompatibilního s našim serverovým šasim. Výsledkem je jakýsi chytrý disk, na kterém spustíme Linux a softwarového agenta, který vytvoří malou objektovou storage.
Původně to bylo řešení plánované pro náš e-mail, kde používáme proprietární objektovou storage – to je největší žrout místa. Snižujeme tím náklady na úložiště, protože používáme tenhle malý serveřík. Jeho cena je vlastně zanedbatelná vůči ceně samotného disku, takže jde o velmi levné řešení – jsme prakticky na ceně za disk.
Ukázalo se, že existují i další aplikace. Plánujeme tedy stejné řešení nasadit na Ceph a plánujeme podobným způsobem zajistit i Hadoop – měli bychom obrovské množství méně výkonných Hadoop clusterů.
To je plně vaše řešení?
Ano, desku si navrhujeme sami a necháváme ji osazovat tady v Čechách.
Nápad pochází od vás?
Inspirovali jsme se u Seagate, ale dnes to dělají všichni velcí dodavatelé disků. Zjistili od velkých zákazníků, že je tu poptávka po objektovém úložišti s ethernetovým portem, do kterého se přes API dá objekt uložit, načíst a smazat. Tím se obejde spousta nadbytečných vrstev jako souborový systém. My jsme to udělali po svém a říkáme tomu Dataholder.
Kolik se vám jich vejde do jednoho šasi?
Máme osm disků v dlouhém šuplíku a každý je vlastně samostatný server. Do jednoho našeho 12U šasi se tak vejde 192 Dataholderů. Šuplík má i servisní napájecí konektor zepředu, abychom mu mohli dodávat napájení, když ho vytahujeme ze šasi.
Každý disk pak má své síťové rozhraní?
Ano, každý má svou IP adresu a každá služba si na něm může spustit svého agenta – Swift, Hadoop, Ceph nebo náš e-mail. Dnes všichni podporují procesory ARM, takže kompatibilita agentů není vůbec problém.
Jaký hardware v Dataholderech používáte?
Je tam čtyřjádrový procesor Marvell A72, 4 GB ECC paměti a gigabitový ethernet.
Jak je možné, že je takový hardware takhle levný?
Cena takového serveru závisí samozřejmě na objemu výroby, ale obecně je to několik tisíc korun. My k němu ale přidáme 4TB SSD, které stojí poměrně dost peněz. Takže cena serveru se vedle toho ztratí.
Jaký máte poměr rotačních disků k SSD?
Už déle než rok kupujeme v drtivé většině jen SSD. Je to také díky Montovně, která přinesla ještě jednu zásadní výhodu – standardizovala hardware. Týmy už si vybírají jen to, zda potřebují 192 nebo 256 GB paměti a zda chtějí šest 480GB disků nebo chtějí dva z nich nahradit 2TB variantou. Zbytek je u všech serverů stejný. S přirozenou obměnou hardware nám do čtyř let rotační disky vymizí.
Jaké s nimi máte zkušenosti?
Výborné, kromě výjimečných vadných sérií nám všechny skutečně vydrží výrobcem garantovanou dobu životnosti. Spíše ji překračujeme. Protože jsme ale v přímém kontaktu s výrobci, tak nám třeba Intel prozradil, že nám může přidat kapacitu disků na úkor jejich životnosti – není tam pak tolik skrytých náhradních bloků.
Nebojíte se pak většího množství selhání?
U některých aplikací to není problém. Například na e-mailu drtivou většinu doby čteme. E-mail se jednou zapíše a pak se už jen čte. Držíme obrovský archiv mailů, ale naše SSD mají jen minimum zápisů. Naši hardwaráři mají přesný přehled o tom, kam se který model disku hodí.
Strategický přechod na SCIF
Čím se budete zabývat v nejbližší budoucnosti?
Přechod na SCIF je součástí strategie firmy a je to to největší, co se teď děje. Není to činnost ohraničená v čase, vyžaduje to technologickou přípravu i vlastní inovace. Zároveň s tím probíhá změna myšlení při běžném provozu i vývoji. Tohle nás v následujících letech bude zaměstnávat nejvíc.
Primární cíl je byznysový: být agilnější v nasazování změn v reakcích na potřeby. Zároveň ale chceme lépe vytěžovat hardware. I s nasazením virtualizace se nám daří zatěžovat procesory v průměru asi na 20 %. Rádi bychom se přiblížili k 50% zatížení, ale výš jít nechceme – chceme být redundantní, aby při výpadku jednoho datacentra převzalo plně jeho úlohu to druhé.
Co přijde dál? Existuje už něco dalšího?
Určitě existuje. Svět IT je hrozný právě v tom, jak rychle se mění. Je to vidět třeba při hledání nových lidí. Dneska už není podstatné, co člověk v danou chvíli umí, ale jestli je schopen a ochoten se učit nové věci. Pokud umíte nějakou moderní technologii, vydržíte s tím dva roky a pak se budete učit nějakou novou.
Rozhodně hledáme multifunkční lidi, kteří jsou někde na pomezí mezi programátorem a administrátorem. Nejdůležitější je ale jejich chuť se učit. Je těžké predikovat, co bude za chvíli.
Děkuji za rozhovor.
