Ekonomika výkonu v zajetí regulací: Architektonický manifest hybridní infrastruktury

Shrnutí

Manifest definuje strategický přístup k návrhu enterprise infrastruktury v regulovaném prostředí roku 2026 a vyvrací mýtus o „levném x86 hardwaru“ pohledem na celkové náklady na vlastnictví (TCO). Klíčem k efektivitě je vědomě řízený hybridní model, který kombinuje architekturu IBM Power pro kritické databázové vrstvy, kde může významně snížit náklady na per‑core licence (např. Oracle), a high‑density x86 uzly pro horizontálně škálovatelné aplikace a Kubernetes, přičemž zohledňuje technická omezení, síťovou latenci, personální rizika i specifika veřejných zakázek (ZZVZ).

1. Manažerské shrnutí: Konec mýtu o drahém železe

Většina infrastrukturních rozhodnutí selhává na tom, že srovnává cenu hardwaru (CAPEX) a ignoruje cenu celkového řešení (TCO). V prostředí, kde dominantní nákladovou položkou nejsou servery, ale softwarové licence (Oracle, VMware, Red Hat, Microsoft), se tradiční rovnice obrací.

Tento dokument analyzuje, proč v roce 2026 dává smysl nasazovat specializovanou architekturu (IBM Power) vedle komoditního x86, a definuje, jak tento nesourodý hybrid uřídit. Cílem je nalézt optimum mezi cenou licencí, výkonem, provozní složitostí a personální udržitelností.

2. Bod zlomu: Kde končí komodita a začíná specializace

Architektura x86 je standardem pro horizontální škálování (scale‑out). Je ideální pro bezstavové aplikace, kde selhání jednoho uzlu nebolí a výkon se dohání počtem serverů.

Architektura IBM Power je navržena pro vertikální škálování (scale‑up). Její hodnota roste v momentě, kdy narážíte na limity propustnosti paměti nebo neúměrně rostoucí cenu licencí.

2.1 Fyzika výkonu: propustnost vs. hrubý takt

Zatímco běžné x86 se soustředí na frekvenci jader, IBM Power (díky rozhraní OMI – Open Memory Interface a konceptu „memory area network“) nabízí násobně vyšší propustnost paměti na socket než typické DDR4/DDR5 konfigurace.

Dopad: Pro databáze typu „memory‑bound“ (SAP HANA, velké Oracle instance) funguje Power jako „tlustá roura“. Běžné x86 zde může narážet na bottleneck paměťové sběrnice, který nelze lineárně vyřešit přidáním dalších jader.

2.2 Architektonická stabilita: Koncept RAS

Zatímco platforma x86 řeší dostupnost primárně softwarově (redundancí uzlů v clusteru), IBM Power integruje stabilitu přímo do křemíku skrze koncept RAS (Reliability, Availability, Serviceability):

Reliability (Spolehlivost): Funkce jako Instruction Retry umožňují procesoru automaticky zopakovat operaci při náhodné chybě v registrech, čímž předchází pádu systému (u x86 končí tyto stavy často „modrou obrazovkou“).
Availability (Dostupnost): Schopnost systému izolovat vadné jádro nebo paměťový blok za chodu, aniž by došlo k přerušení provozu aplikací.
Serviceability (Servisovatelnost): Pokročilá diagnostika (First Failure Data Capture), která přesně identifikuje příčinu závady hned při prvním výskytu, což dramaticky zkracuje dobu opravy.

V kritických vrstvách (Data Tier) tato úroveň stability eliminuje riziko pádu databáze kvůli banální hardwarové chybě, která by u komoditního hardwaru vyžadovala restart.

3. Licenční matematika: výkon jako finanční derivát

Pokud provozujete software licencovaný per‑core (Oracle DB, WebLogic, některé VMware edice, vybrané Microsoft serverové produkty), hardware je pouze nosičem licence.

Oracle Core Factor: skrytá páka

Podle oficiální Oracle Processor Core Factor Table platí:

x86 (Intel/AMD): Core Factor = 0,5 (potřebujete 1 licenci na 2 fyzická jádra).
IBM Power: Core Factor = 1,0 (potřebujete 1 licenci na 1 fyzické jádro).

Rovnice rentability a „VMware tax“

Aby se IBM Power z pohledu licencí vyplatil, musí platit nerovnice

$$Performance_{PowerCore} > 2 \times Performance_{x86Core}$$

Scénář OLTP (nutno ověřit)

V paměťově náročných transakčních scénářích (OLTP – online transaction processing) benchmarky a interní POC indikují, že moderní Power10 jádro (SMT8) může dosáhnout výkonu ekvivalentního přibližně 2,5 až 3,5 jádrům běžného x86 serveru, při vhodně dimenzovaném paměťovém subsystému.

Důležité: Tento poměr není univerzální konstantou. Pro potvrzení TCO modelu je nezbytné provést Proof of Concept (PoC) na reálných datech organizace. Pokud PoC potvrdí poměr výkonu v tomto intervalu, může úspora na licencích Oracle činit řádově 30–50% v porovnání s ekvivalentním x86 designem.

Faktor Broadcom (VMware)

Přechod VMware na subscription model s licencováním po jádrech a minimálními počty core na CPU (např. 16 a více) výrazně penalizuje „rozředěné“ x86 clustery.

PowerVM (hypervizor) je součástí firmwaru a nákladově vázán na hardware, nikoliv na samostatnou per‑core subskripci. Pokud však x86 větev přejde z VMware na KVM (např. OpenShift Virtualization), licenční výhoda PowerVM se částečně stírá a zůstává primárně argument konsolidace výkonu na méně jader.

4. Tržní alternativy: kritický pohled

Pro objektivitu je nutné srovnat Power s relevantní konkurencí v segmentu high‑end platforem.

A. Oracle Exadata (vyladěný ekosystém)

Pro čistě Oracle workloady je Exadata často výkonnější než obecné platformy díky „Smart Scan“ offloadingu a tight‑coupled integraci compute a storage.

Pro: Maximální výkon pro Oracle DB, hluboce vyladěný stack od jednoho výrobce.
Proti: Vysoká závislost na ekosystému Oracle (vendor lock‑in). Ačkoliv virtualizace (např. KVM) existuje, provozování jiných workloadů (non‑Oracle) je na této platformě obvykle ekonomicky či provozně neefektivní; prakticky jde o „Oracle‑only“ prostředí.

B. HPE Superdome Flex (x86 scale‑up)

HPE nabízí velké x86 systémy (8–32 socketů) pro in‑memory computing (navazující na technologii SGI).

Pro: Špičkový RAS, kompatibilita x86, možnost konsolidovat velké in‑memory instalace na jednom systému.
Proti: Stále platí x86 Core Factor 0,5. Získáte stabilitu srovnatelnou s Powerem, ale bez licenční úspory na Oracle per‑core licencích; platíte prémii jak za HW, tak za SW.

5. Technické limity: kde Power selhává

Nasazení Power není univerzální lék a má svá omezení, zejména na úrovni ekosystému.

A. The `ppc64le` gap (Python & AI)

Moderní vývoj v Pythonu a AI/ML je optimalizován primárně pro x86_64.

Problém: Enterprise distribuce pro Power mají často zpoždění oproti upstreamu; předkompilované knihovny pro ppc64le mohou chybět nebo být verzově pozadu. Pro provoz pokročilých frameworků (PyTorch, TensorFlow) to znamená nutnost vlastních build pipeline.
Doporučení: Pokud organizace nedisponuje týmem schopným spravovat vlastní build pipelines a multi‑arch kontejnery, Python/AI workloady by měly zůstat na x86.

B. Legacy constraint (Windows & lokální trh)

Lokální dodavatelé (např. regulatorní systémy pro ČNB či specifické bankovní aplikace) často vyžadují Windows Server.

Hard stop: Windows na Power neběží. Heterogenní prostředí (Power + x86) je tedy faktickou nutností, nikoliv volbou.

6. Moderní app layer: efektivita x86 podvozku

Pro aplikační vrstvu (Kubernetes, aplikační servery, integrační platformy) potřebujeme efektivní x86, ale je vhodné vyhnout se některým historickým slepým uličkám.

6.1 Ústup blade systémů

Moderní blade šasi (např. HPE Synergy) musela kvůli chlazení vysoce výkonných CPU (TDP 250–350 W a více) snížit hustotu osaditelných serverových modulů.

Efektivita: Pro nové cloud‑native designy jsou blade systémy často suboptimální volbou – přinášejí vysokou cenu za šasi a management frame, kterou Kubernetes architektura nutně nevyžaduje, protože redundanci a orchestraci řeší softwarově.

6.2 Architektura „mravenců“: high‑density multi‑node

Řešením pro K8s jsou high‑density rack servery (např. 2U šasi se 4 nezávislými nody).

Výhoda: Vyšší hustota, sdílené napájení a chlazení, menší „blast radius“ při výpadku uzlu, lepší poměr cena/výkon pro scale‑out cluster.

6.3 Storage pro K8s: SDS (Ceph)

Místo drahé SAN lze u K8s využít software‑defined storage (např. Ceph/Rook) na lokálních NVMe discích.

Varování: Ceph vyžaduje zkušený provozní tým a pečlivý návrh. Pokud organizace nemá kompetenci pro správu SDS, je bezpečnější volbou managed storage nebo tradiční pole, i za cenu vyšších nákladů.

7. Provozní realita: daň za hybridní model

Rozdělení infrastruktury (DB na Power, app na x86) přináší rizika, která je nutné explicitně řídit.

7.1 Network latency tax

Fyzické oddělení aplikační a databázové vrstvy zavádí síťovou latenci (RTT typicky 0,1–0,3 ms u dobře navržené páteřní sítě, v brownfieldu může být vyšší kvůli firewallům a vícestupňové topologii).

Riziko: U „chatty“ aplikací (např. ORM patterny typu N+1 select) může tato latence degradovat výkon bez ohledu na hrubý výkon DB serveru.
Mitigace: Jumbo Frames (MTU 9000) end‑to‑end, optimalizace aplikačních dotazů (omezení „chatty“ patternů, batching), minimální počet síťových hopů, případně bypass některých bezpečnostních vrstev pro definované aplikační zóny dle bezpečnostní politiky.

7.2 Organizační schizma a human capital

Rozdělení na tým Power/AIX a tým x86/Linux/K8s vytváří silovou hranici, která může negativně ovlivnit řešení incidentů.

Riziko: Vysoká závislost na omezeném počtu specialistů Power/AIX v prostředí, kde většina trhu míří k Linux/K8s; bus factor jednoho nebo dvou lidí je reálné provozní riziko.
Mitigace: Zavedení role end‑to‑end architekta, definice společných SLO/SLA a sjednoceného APM monitoringu (Dynatrace, AppDynamics apod.) napříč platformami, plus dlouhodobý plán na cross‑training týmů a zajištění kompetencí pro Power platformu na celé období životního cyklu.

8. Storage strategie: dva světy

Svět A (Mission‑critical DB): Zde dominuje SAN (all‑flash FC). HCI (např. vSAN) je zde často nevhodné kvůli latenci, CPU overheadu storage vrstvy a licenčnímu prodražení (Oracle/DB licence na storage nodech).
Svět B (Kubernetes/App): Zde dominuje SDS (Ceph) nebo levnější bloková storage. Prioritou je cena za GB, škálovatelnost a integrace s K8s; konkrétní volba (Ceph vs. pole) musí reflektovat schopnosti provozního týmu.

9. Průvodce bojištěm ZZVZ (veřejné zakázky)

Jak přistoupit k nákupu technologie v souladu se zákonem a zároveň obhájit TCO?

Technické parametry:
Definujte požadavky na základě potřeb aplikace (např. minimální paměťová propustnost na socket, RAS funkce jako instruction retry, FFDC) a požadovaných SLA, nikoliv konkrétních značek. Parametry musí být formulovány funkčně tak, aby umožňovaly spravedlivou soutěž.
TCO jako hodnoticí kritérium:
Využijte možnosti hodnotit náklady životního cyklu. Požadujte kalkulaci licencí, podpory a energií na 5 let pro definovaný výkonový scénář (včetně Oracle/VMware, pokud jsou součástí řešení).
Předběžná tržní konzultace (PTK):
Cílem PTK je objektivizovat parametry. Nechte dodavatele různých platforem navrhnout konfiguraci pro splnění SLA a zdokumentujte, jaké počty jader a typy systémů navrhují. Pokud x86 vendor potvrdí nutnost násobně vyššího počtu jader pro dosažení stejného výkonu, stává se tento údaj legitimním podkladem pro obhajobu TCO modelu a technických parametrů v zadávací dokumentaci.

10. Závěrečný verdikt: rozhodovací strom

Kdy zvolit IBM Power:

$\checkmark$ Provozujete Oracle/DB2/SAP HANA s vysokými per‑core licenčními poplatky.
$\checkmark$ PoC potvrdil významný výkonnostní benefit (poměr výkonu > 1 : 2,5 ve prospěch Power jádra v cílovém workloadu).
$\checkmark$ Vyžadujete stabilitu a RAS na úrovni „mainframe třídy“ a máte plán, jak dlouhodobě zajistit kompetence pro Power platformu.

Kdy zvolit x86 (high‑density):

$\checkmark$ Provozujete aplikační vrstvu, Kubernetes, integrační platformy, Python/AI a další cloud‑native workloady.
$\checkmark$ Vaší strategií je přechod na open‑source DB (PostgreSQL apod.) bez drahých per‑core licencí – zde Power typicky nedává ekonomický smysl.
$\checkmark$ Aplikace vyžadují Windows Server nebo jiný software podporovaný pouze na x86.

Rozhodnutí:

Volíme vědomě řízený hybrid.

Data tier: IBM Power + SAN (optimalizace licencí, výkonu a stability).
App tier: high‑density x86 (optimalizace hustoty, ekosystému a nákladů na compute/storage pro K8s).

Příloha A: modelový výpočet TCO (5 let)

Disclaimer: Níže uvedená kalkulace vychází z ceníkových cen (list price) pro modelovou transakční zátěž. Reálné ceny se mohou lišit dle obchodních podmínek a slev, nicméně poměr nákladů mezi variantami typicky zůstává obdobný – hlavní podíl tvoří licenční náklady, nikoliv hardware.

Scénář: Mission‑critical DB cluster. Požadovaný výkon ekvivalentní 24 jádrům Power10 (předpokládaný poměr 1 : 3 dle OLTP benchmarků, ověřit PoC).

Nákladová položka	Varianta A: IBM Power (2× 24 cores)	Varianta B: x86 cluster (2× 72 cores)
Hardware (CAPEX)	4,5 mil. Kč (vyšší jednotková cena)	3,0 mil. Kč (komoditní cena)
Virtualizace (5 let)	~ 0 Kč (PowerVM součást HW)	1,8 mil. Kč (VMware VCF subskripce)
Oracle DB EE (licence)	24 licencí (core factor 1,0)	36 licencí (72 cores × 0,5)
Cena Oracle (odhad list price)	cca 25 mil. Kč	cca 37,5 mil. Kč
Spotřeba energie	Nižší (méně CPU, menší footprint)	Vyšší (cca 3× více CPU, vyšší nároky na chlazení)
CELKEM TCO (5 let)	~ 30 mil. Kč	~ 43 mil. Kč
ROZDÍL		x86 varianta je v modelu nákladnější o ~30%