WVG Blog

Jak jsme vyřešili limity Kazan Onyx2 pomocí vlastní SPDK proxy vrstvyV jednom z našich předchozích článků jsme detailně popisovali, jak fungují naše NVMe JBOF storage boxy postavené na HPE J2000 a FPGA akcelerátorech Kazan Onyx2 (dnes Western Digital). Psali jsme o tom, jaká je reálná latence, jak Onyx2 mapuje NVMe namespace přímo přes PCIe do NVMe-oF a jak se nám podařilo tyto jednotky rozchodit jako jeden z nejrychlejších storage backendů v naší infrastruktuře.Tentokrát navážeme tam, kde jsme tehdy skončili. Při dalším rozšiřování jsme totiž narazili na problém, který není na první pohled vidět – limit počtu NVMe controllerů na FPGA.A tento detail nakonec vedl k tomu, že jsme implementovali vlastní SPDK proxy vrstvu mezi hypervisory a J2000 storage. A změnilo to způsob, jak náš NVMe-oF storage cluster škálujeme.Proč Kazan Onyx2 na J2000 vůbec používámeNež se dostaneme k samotné proxy, krátce připomeňme technologii.Onyx2 = FPGA NVMe-oF target engineKazan Onyx2 není síťová karta ani DPU. Je to specializovaná FPGA pipeline, která implementuje NVMe over Fabrics:čtení a zápisy jdou přímo z RDMA/TCP do DMA enginů FPGA,žádný kernel, žádné CPU, žádný kontext switch,ultra-nízká latence díky hardwarovému fast-pathu,deterministické chování bez jitteru,prakticky line-rate výkon i v QD=1.Onyx2 je tedy čistá NVMe-oF hardwarová brána mezi síťovým provozem a fyzickými NVMe disky.HPE J2000 + 6× Kazan Onyx2 (dual-path)V našich J2000 chassisech máme typicky:24 NVMe disků,6× Onyx2 karet,dual-path topologii (A/B redundantní porty),plnou podporu multipathu.Tento design se nám osvědčil – výborná latence, spolehlivost, velmi slušná efektivita.Jenže…Našli jsme limit, který nás zastavil: 32 NVMe controllerů na FPGA párFPGA Onyx2 implementuje vlastní interní NVMe-oF target. A ten target má pevně definovaný limit:Maximálně 32 NVMe controllerů na jeden FPGA pár (A/B).Reálně to znamená:32 controllerů na port A,32 controllerů na port B,pokud potřebujeme více, není jak.A zde jsme narazili.Protože:J2000 máme zapojené redundantně přes dual path,v jednom boxu je 6 Onyx2 karet,hypervisorů máme v cloud klastru výrazně více než 32.Navíc každý hypervisor si zakládá vlastní NVMe-oF controller session pro multipath. To znamená, že při větším počtu hypervisorů se 32 controllerů vyčerpá velmi rychle.Pro výkon to nebyl problém. Pro kapacitu taky ne. Ale škálovat se s tím prostě nedalo.Řešení? Vložit mezi hypervisor a storage „chytrou“ proxyPotřebovali jsme něco, co bude:na straně Kazanu fungovat jako NVMe initiator,na straně hypervisorů jako NVMe-oF target,bude umět zachovat identitu disků (EUI64/NGUID),bude přidávat minimum latence,a nebude mít limit 32 controllerů.A přesně to poskytl SPDK.SPDK Proxy – architekturaVýsledná architektura vypadá zjednodušeně takto:Hypervisor → NVMe-oF Initiator → SPDK Proxy → SPDK NVMe Initiator → Kazan Onyx2 → NVMe diskSPDK proxy server tedy:naváže NVMe-oF spojení na Onyx2 FPGA (bdev_nvme initiator),připojí jednotlivé namespaces,vytvoří nad nimi vlastní SPDK blockdevy,a vystaví je dál jako SPDK NVMe-oF target.Hypervisory už nekomunikují přímo s J2000, ale s proxy.Co bylo potřeba upravit a vyřešitNasazení SPDK jako proxy není jen o spuštění nvmf_tgt. Museli jsme řešit několik poměrně hlubokých detailů.1) EUI64/NGUID – kritická část pro multipathHypervisory očekávají, že:target A i target B budou hlásit stejný EUI64,a identifikátor musí odpovídat tomu, co hlásí původní NVMe namespace.Kazan ale vrací EUI64 v jiném byte-order, než co vrací vlastní NVMe identify (a než očekává Linux).Museli jsme tedy:patchnout SPDK,přidat EUI64 parsing do JSON výstupu,ručně správně poskládat EUI64 bajty podle NVMe specifikace,zaručit, že SPDK target bude exportovat stejnou identitu jako Onyx2 namespace.Toto byla jedna z nejnáročnějších částí, protože multipath je na konzistenci identifikátorů extrémně citlivý.2) Automatická regenerace SPDK konfiguraceProxy musí po restartu:zjistit namespaces,načíst EUI64/NGUID,spustit NVMe initiator,vytvořit subsystémy,přidat namespace,nastavit controller-id range,spustit listener,a teprve potom povolit hypervisory.Celé jsme to automatizovali vlastními skripty, které SPDK konfiguruje přes RPC. Díky tomu je start proxy deterministický a opakovatelný.3) Hardware a ladění latenceProxy server nesmí být bottleneck. Po testech jsme skončili u konfigurace založené na:AMD EPYC (kvůli vysokému single-core výkonu),ConnectX-5/6 Dx pro 100G RDMA/TCP,pinned cores: SPDK poll-loop běží na izolovaných jádrech,kernel parametrech typu: idle=poll, nohz_full, isolcpus, rcu_nocbs, nosmt, default_hugepagesz=1G, hugepages=4,IOMMU a hluboké C-states vypnuté.Tím jsme dostali jitter pod ±3 μs a proxy přidávala pouze 8–12 μs navíc, což je v podstatě nerelevantní proti celkové latenci end-to-end.Výsledky v produkciPo nasazení SPDK proxy jsme získali několik klíčových výhod:1) Žádné limity NVMe controllerů na hypervisoryHypervisory teď komunikují jen s proxy, která se dokáže tvářit jako stovky controllerů. Kazan má pořád jen několik desítek – a to stačí.2) Stabilní, konzistentní multipathEUI64 i NGUID jsou konzistentní a identické napříč celou cestou. Linuxový NVMe driver tak nemá důvod hlásit chyby typu „IDs don't match for shared namespace“.3) Nezávislost na implementaci NVMe-oF v FPGAVšechny multipath a host-specific detaily běží v SPDK na serveru, ne ve firmware. Kazan Onyx2 zůstává tím, čím je nejlepší – extrémně rychlým NVMe-oF targetem.4) Velmi nízká režiePřidání ~10 μs latence je naprosto zanedbatelné vzhledem k počtu hypervisorů, které obsluhujeme, a získané flexibilitě.5) Jednodušší upgrade / rolling updatesProxy můžeme restartovat nebo nahrazovat bez potřeby šahat na samotné storage chassis. Hypervisory cílí na stabilní endpointy, které kontrolujeme my.ZávěrTím, že jsme mezi hypervisory a J2000 storage vložili SPDK proxy vrstvu, jsme vyřešili zásadní limit, který by jinak bránil dalšímu růstu celé platformy.Kazan Onyx2 je stále perfektní backend – FPGA NVMe-oF target, který poskytuje konzistentní a extrémně nízkou latenci. SPDK pak doplňuje to, co FPGA hardware neumí: flexibilitu, kontrolu nad identitou disků, automatizaci a škálování.Výsledkem je řešení, které kombinuje:hardwarovou latenci Kazanu,flexibilitu SPDK,robustní multipath,a škálovatelnou NVMe-oF topologii bez limitů FPGA.Tato kombinace nám umožnila posunout storage infrastrukturu o generaci dál, připravit ji na vyšší počet hypervisorů a zároveň si zachovat náskok v I/O latencích, který považujeme za jednu z klíčových konkurenčních výhod.

V rámci platformy WVG Cloud jsme posunuli možnosti virtualizace o úroveň výš. Vedle klasických škálovatelných VPS nabízíme nově také možnost mít vlastní fyzický hypervisor — plně integrovaný do naší cloudové infrastruktury, s veškerým komfortem a SLA, ale bez sdílení výkonu s kymkoliv jiným. Absolutní výkon – AMD EPYC 4585PX a DDR5 ECC RAM Nové fyzické hypervisory stavíme na procesorech AMD EPYC 4585PX (16 jader / 32 vláken) s vysokým taktováním a excelentním single-thread výkonem — ideální volba pro aplikace, které potřebují reakční rychlost, buildy, CI/CD nástroje, databáze nebo virtualizační vrstvy s větším vytížením jednotlivých jader. Doplňuje je 256 GB DDR5 ECC RAM a napojení na náš sdílený storage cluster s redundancí a snapshoty. Pokud hledáte masivní paralelní výkon, nabízíme také servery s EPYC 7742 (64 jader / 128 vláken) — ideální pro velké výpočty a paralelní úlohy. Zkrátka: 4585PX pro maximální výkon na jádro, 7742 pro masivní škálování. Hypervisor jako služba Každý fyzický hypervisor je součástí WVG Cloud — spravujete jej přes stejné intuitivní UI, kde vytváříte a spravujete virtuální stroje, VLANy, IP adresy, snapshoty i grafy. Rozdíl? Železo je jen vaše. Na rozdíl od klasického VPS, kde platíte za vCPU, RAM a disk, zde můžete provádět overprovisioning — například přidělit více vCPU, než má server fyzicky. Díky tomu lze dosáhnout výrazně lepší efektivity a úspory nákladů, což ocení především firmy, které potřebují větší flexibilitu a kontrolu nad výkonem. Platíte jen za železo a storage Žádné složité účtování podle spotřeby. U fyzického hypervisoru platíte pouze za hardware (CPU + RAM) a využitý sdílený storage. Kolik VM si vytvoříte a jak rozdělíte výkon je zcela na vás. Žádné limity, žádné skryté poplatky, žádné sdílení IOPS s ostatními zákazníky. Ideální pro outsourcing a profesionální týmy Model vlastního hypervisoru je ideální pro: IT outsourcing firmy, které chtějí hostovat projekty svých klientů na vlastním uzlu, DevOps a vývojové týmy, které potřebují testovací a produkční prostředí bez omezení, menší poskytovatele a hostery s vlastním SLA a plnou kontrolou nad VM, technologické laboratoře a školní projekty s možností overprovisioningu a sandboxingu. Výhody, které běžný VPS neumí ✅ Plná nezávislost na ostatních uživatelích ✅ Overprovisioning – vytěžte hardware na maximum ✅ Přímý přístup do WVG Cloud rozhraní a API ✅ 24/7 monitoring a SLA na fyzické úrovni ✅ Možnost napojení na vlastní VLAN a veřejné i privátní IP Cloud bez kompromisů WVG Hypervisor as a Service je řešení pro ty, kteří nechtějí řešit hardware, ale zároveň nechtějí sdílet výkon. Dostanete reálný server v datacentru s naší infrastrukturou v pozadí — a svůj vlastní cloud v cloudu. 📩 Zaujalo vás to? Neexistuje lepší varianta než napsat na obchod@wvg.cz — domluvíme konfiguraci na míru vašim potřebám.

Hosting u nás není jen o serverech a virtuálních strojích. My se zajímáme o to, jak věci fungují do hloubky, a nebojíme se technologie ohnout podle sebe. Proto jsme se pustili do oblasti, kterou většina hostingových firem vůbec neřeší: DWDM optických sítí. Co je DWDM a proč nás zajímá DWDM znamená Dense Wavelength Division Multiplexing, tedy husté dělení vlnových délek. Laicky řečeno: místo toho, abychom měli jedno optické vlákno pro jeden datový tok, rozdělíme ho na desítky nebo stovky „barevných kanálů“. Každý kanál pak nese vlastní datový přenos. Najednou se tak jedno jediné vlákno stane dálnicí s mnoha pruhy. V datových centrech, kde každý metr optického vlákna stojí peníze, to znamená obrovskou úsporu. Proč BiDi: dvě cesty v jednom vlákně Běžně se data posílají dvěma vlákny – jedno pro směr tam, druhé pro směr zpátky. Jenže optická vlákna nejsou levná. V Praze stojí pronájem i kolem 2 Kč za metr měsíčně. To znamená, že pokud máme trasu o délce kilometr, platíme každý měsíc 2 000 Kč za jedno vlákno. A protože běžně potřebujeme dvě, je to hned 4 000 Kč měsíčně. My používáme BiDi (bidirectional) přenos, tedy obousměrný provoz po jediném vlákně. Cena je okamžitě poloviční. A co je důležité – druhé vlákno by nám nezvýšilo redundanci, protože jde stejně tou samou trasou. Takže bychom jen platili dvojnásobek za nic. Laicky řečeno: Je to jako kdybyste měli dálnici – někdo říká, že potřebujete dvě, jednu na jízdu tam a druhou zpátky. My používáme jeden pruh s chytrým řízením, kde se zvládne provoz v obou směrech. Výsledek? Stejné služby, poloviční náklady. Co jsou to EDFA zesilovače EDFA znamená Erbium-Doped Fiber Amplifier. Je to optický zesilovač, který dokáže zesílit světelný signál přímo ve vlákně. Uvnitř je kousek vlákna „nabuzený“ prvkem erbium. Když se do něj pustí silný laser na speciální vlnové délce, erbium dodá energii signálu a zesílí ho bez převodu na elektriku. To je důležité – běžně byste museli světlo převést na elektrický signál, zesílit ho zesilovačem a zase zpět převést na světlo. To by bylo pomalé a drahé. EDFA to zvládne přímo v optice a je proto základní stavební kámen moderních DWDM sítí. Naše cesta: od two-stage k single-stage Používáme legendární CISCO-EDFA3. Původně jsou to two-stage zesilovače – tedy dvoustupňové: nejdřív slabý pre-amp, pak silný booster. To se hodí pro klasické trasy, ale pro naše BiDi nasazení to není ideální. Proto jsme se rozhodli každý stupeň oddělit a použít samostatně. Jeden stupeň funguje jako zesilovač pro směr TX, druhý pro RX. Tím máme nezávislé řízení pro oba směry a můžeme ladit výkon přesně podle potřeby. A upřímně – když to Cisco v devadesátkách navrhovalo, asi fakt netušilo, že někdy budeme přes jejich EDFA3 tahat 100Gbit/s PAM4 linky. Ale jak se ukazuje – kvalita tehdejší konstrukce je pořád skvělá a v mnoha ohledech předčí i některé moderní „lesklé krabičky“. EDFA-1 – otevřené šasi s masivním chlazením. Resistorová destička: tajemství úspěchu Abychom mohli oba stupně oddělit, museli jsme řídicí elektronice „namluvit“, že je vše v pořádku. Jinak by vyhazovala chyby. Řešením byla resistorová destička – speciální odpory v řádu stovek megaohmů. Jsou tak vysoké, že jsou pro běžné měřáky téměř neměřitelné, ale pro řídicí obvody mají zásadní význam. Hodně jsme ladili, testovali různé hodnoty a kombinace. Výsledek je stabilní provoz, bez falešných alarmů a se zachovanými ochrannými funkcemi. Každý stupeň běží samostatně a přesně podle toho, jak potřebujeme. A protože se nám úprava povedla, udělali jsme to hned u několika dalších kousků. Na aftermarketu jsme jich koupili hromadu za zlomek ceny, a dnes máme zásobu, která by vystačila i na menší optický velkoobchod. Investice, která se vyplatila! EDFA-2 – detail PCB a fotodiody před úpravou. EDFA-3 – naše PCB s resistorovou destičkou vložené do EDFA3. Co jsou to 100G PAM4 moduly Vedle zesilovačů je klíčová i samotná modulace. Běžné 100G moduly používají NRZ (Non-Return-to-Zero), což znamená, že světlo svítí buď 0 nebo 1. PAM4 (Pulse Amplitude Modulation, 4 úrovně) používá místo toho čtyři různé úrovně jasu. Prakticky to znamená, že přenášíme dvojnásobek informací na stejnou šířku pásma. Signál je sice citlivější na šum a zkreslení, ale když máme dobře nastavený OSNR a čisté filtry, funguje to skvěle. Díky tomu dokážeme posílat 100G po kanálech, kde by jinak bylo potřeba složitější a dražší řešení. Jednoduše řečeno: Představte si, že místo toho, abyste měli jen 0 a 1, máte 0, 1, 2 a 3. Každý symbol nese víc informací, a tak zvládnete přenést víc dat za stejný čas. Výsledek: funguje to a stojí zlomek ceny Po měsících ladění jsme spokojení: kombinace flat-top filtrů, 100G PAM4 a upravených EDFA funguje spolehlivě a krásně. A k tomu s jistou dávkou ironie – staré Cisco EDFA3 mají v reálu lepší OSNR než kdejaké novější „all-in-one“ DWDM krabičky, které stojí desítky tisíc dolarů. Celé řešení nás stojí zlomek ceny oproti hotovým blackboxům. A navíc – díky tomu, že rozumíme technologii do detailu, dokážeme nabídnout službu, která je levnější, spolehlivější a transparentnější. A to je přesně to, co chceme – aby naši klienti měli špičkovou konektivitu za férovou cenu.

V rámci naší cloudové infrastruktury jsme se rozhodli jít jinou cestou. Chtěli jsme úložiště, které nebude jen "stačit", ale bude rychlé, spolehlivé, tiché a připravené růst spolu s nároky moderních aplikací. Výsledek? Vlastní high-performance NVMe JBOF řešení, postavené na 100Gbps síťové technologii a šasi HPE J2000, které jsme si upravili na míru. HPE J2000 samo o sobě není typické úložiště. Je to PCIe switch enclosure – pasivní šasi bez procesoru, bez řadiče, bez softwaru. Jen rychlé PCIe dráhy a spousta místa pro NVMe disky. Přesně to, co potřebujete, když chcete výkon bez kompromisů. Skutečné srdce? GigaIO Kazan Onyx2 Uvnitř ale nejsou jen disky – hlavní roli hrají Kazan Onyx2 karty od GigaIO. Ty totiž fungují jako NVMe-oF targety, což je technicky řečeno způsob, jak zpřístupnit NVMe disky přes síť – a to extrémně rychle a bez zbytečných vrstev. Díky tomu si může každý hypervizor v clusteru sáhnout na disk, jako by byl lokálně připojený. Pro běžného smrtelníka? Znamená to, že každý virtuální server, každý cloudový systém, má přímý a rychlý přístup ke svým datům, bez prodlev a bez přetížení, jaké známe ze starších storage řešení. Hardwarový tuning: ne vždy stačí továrna V ostrém provozu jsme zjistili, že Kazan karty se přehřívají – při běžné teplotě v serverovně (23 °C) měly až 43 °C a větráky hučely na 14 000 ot/min. Takže místo tichého úložiště jsme měli tryskové letadlo. Řešení? Naše vlastní chlazení: upravili jsme airflow tunely, vyměnili hliníkové chladiče za měděné a doladili průtok vzduchu. Výsledek: 30 °C a 8 000 ot/min. Ticho, úspora energie, delší životnost – a hlavně žádný kompromis s výkonem. 100Gbps páteř, která nestíhá zčervenat Každé JBOF je zapojeno do naší 100Gbps fabric sítě a využívá NVMe over Fabrics (NVMe-oF). Díky tomu jsou všechny disky okamžitě dostupné z libovolného serveru v clusteru, a to s latencí pod jednu milisekundu. Žádné klasické NFS, žádné bottlenecky. A hlavně: bez centralizovaného úzkého hrdla. Potřebujeme více výkonu? Přidáme další disky, další JBOF nebo celý další rack. Škálování jako LEGO, ale pro datová centra. Izolované RAIDy: výkon i bezpečnost bez kompromisů Každý disk přidělený zákazníkovi je součástí vlastního RAID1 svazku – a to napříč 2 až 3 JBOFy umístěné ve třech různých lokalitách. Ano, čtete správně – i jeden zákazník má k dispozici svůj vlastní redundantní diskový prostor, zcela oddělený od ostatních. Odolnost proti výpadku celé lokality? ✅ Bezpečnost dat a přístupů? ✅ Možnost live migrace mezi lokalitami? ✅ Žádné sdílení výkonu ani IOPS? ✅ Výkon, co byste čekali spíš u lokálního SSD Díky NVMe-oF, přímému přístupu a absenci middlewaru dosahujeme výkonu, který se běžně spojuje s lokálními NVMe disky: až 700 000 IOPS pro čtení až 350 000 IOPS pro zápis sekvenčně až 6 000 MB/s čtení sekvenčně až 4 000 MB/s zápis A to vše na jedno jediné VM. Bez front, bez sdílení, bez hádek o výkon. Je jedno, jestli provozujete databáze, CI/CD, AI modely nebo cokoliv mezi tím – tohle řešení s vámi poroste. Potřebujete dvojnásobek výkonu? Přidáme další JBOF. Potřebujete jinou lokalitu? Zapojíme další. Naše architektura je modulární a lineárně škálovatelná – to znamená, že výkon roste s každým novým blokem, bez nutnosti zásadní přestavby. Chytré řízení jako třešnička na dortu Za celým řešením stojí náš vlastní cluster management systém, který monitoruje každý disk, RAID, hypervizor i migraci. Pokud VM potřebuje změnit lokalitu, provede se jen jednoduché: RAID se odpojí ze zdrojového serveru, a znovu se připojí na cílovém, protože díky NVMe-oF je každý disk dostupný odkudkoliv. A to vše bez čekání na replikaci nebo přesun dat. Závěr? Výkon, škálovatelnost, klid na duši Naše NVMe JBOF infrastruktura je postavená tak, aby: byla extrémně rychlá a škálovatelná, odolala i výpadku celé lokality, zajistila plnou izolaci výkonu pro každého klienta, umožnila živé migrace VM bez výpadků, a hlavně – byla připravena na budoucnost. Tohle není další „shared storage“ s fancy názvem. Tohle je infrastruktura postavená techniky pro techniky, která zohledňuje reálné potřeby vývojářů, provozáků i náročných zákazníků. Sledujte náš blog, chystáme další technické detaily, tuningy a fotky z provozu – teprve začínáme.

V našem cloudu jsme si vyvinuli vlastní zálohovací systém, který umožňuje živé zálohování běžících VM bez výpadku, zátěže a s možností obnovy během několika minut. Nepoužíváme žádné krabicové řešení – vsadili jsme na kombinaci KVM drive-mirror, vlastního NBD filtru a archivních serverů s ZFS a SSD. Živá replikace pomocí KVM drive-mirror Každý zákaznický VM v našem cloudu běží na výkonném NVMe úložišti. Na úrovni jednotlivých disků aktivujeme KVM drive-mirror, který umožňuje, aby se veškeré změny na disku v reálném čase zrcadlily na druhé úložiště. Tímto způsobem proudí data do backup serverů – specializovaných strojů s SSD a ZFS. Pro běžící VM se nic nemění – každý zápis se zároveň replikuje a archivuje, a to naprosto tiše a bez zpomalení. Archivní servery s dedikovaným ZFS Backup servery nejsou žádné záložní hypervizory – jejich jediný úkol je ukládat data a spravovat verzované snapshoty. Díky použití SSD: provádíme paralelní zápisy z mnoha VM najednou, udržujeme stovky snapshotů denně, umíme obnovit data do jakéhokoli bodu v čase, to vše bez dopadu na produkční výkon. Efektivita díky vlastnímu NBD filtru Aby nebyly zálohovací servery zahlcené zbytečnými daty, vytvořili jsme vlastní NBD filtr, který analyzuje každý blok dat. Pokud se zapisovaná data neliší od těch stávajících, zápis se přeskočí. To znamená: méně zbytečných zápisů, úsporu IOPS a delší životnost SSD, častější a efektivnější zálohy. Zatímco jiné systémy vytvářejí snapshot jednou denně, my zálohujeme v reálném čase s inteligentní deduplikací už při zápisu. ZFS snapshoty: verzování, klonování, obnova ZFS se na našich backup serverech stará o automatické verzování dat pomocí snapshotů. Ty lze nastavit třeba každou hodinu a slouží jako časové záchytné body pro rychlou obnovu. V případě potřeby lze snapshot okamžitě klonovat jako nový disk a připojit ho k VM. Obnova trvá jen minuty a nevyžaduje žádné kopírování image. Co z toho mají naši zákazníci? ✔ Živé zálohy bez zpomalení VM ✔ Snapshoty verzované přímo na zálohovacím serveru ✔ Obnova do libovolného bodu v čase – během minut ✔ Samostatná zálohovací infrastruktura mimo produkci ✔ Chytrá deduplikace šetří místo i hardware ✔ Možnost zálohovat klidně každou hodinu Závěr: zálohování, které nezdržuje. Obnova, která trvá minuty. Zálohujeme chytře a efektivně – protože jsme si vše navrhli sami. Žádné čekání na nightly snapshoty. Každá změna je okamžitě uložena a připravená k obnově. Díky kombinaci ZFS, SSD a vlastního filtru je celý systém rychlý, bezpečný a udržitelný. O zálohách se často mluví – my je hlavně děláme pořádně. Sledujte náš blog, další technické detaily přineseme brzy.