Přeskočit na obsah
.cloud

Co tvoří platformu

Dvanáct provozních vrstev. Jeden paušál.

Platforma není seznam parametrů serveru. Je to dvanáct vrstev, které musí někdo provozovat, aktualizovat, hlídat a v případě incidentu opravit. U nás je provozujeme my — a tady je vidíte všechny, včetně technických parametrů.

  1. 01

    Výpočetní platforma

    dedikované vCPU a RAM · dvě datacentra

    Vyhrazený výkon jen pro váš provoz, s rezervou na špičky i růst. Nesdílíte procesor s cizí zátěží, takže odezva aplikace nezávisí na tom, co dnes dělá soused.

  2. 02

    Úložiště dat

    Ceph · distribuovaný cluster · replikace napříč uzly

    Data leží na několika uzlech zároveň.

  3. 03

    Síťová vrstva

    2× 40 GbE · perimetrový firewall · oddělené VLAN

    Redundantní konektivita s filtrací na perimetru. Produkce, testovací a vývojová prostředí jsou oddělená na úrovni sítě, ne jen konfigurací aplikace.

  4. 04

    Virtualizace

    Proxmox VE · LXC kontejnery

    Hypervisor spravujeme, aktualizujeme a bezpečnostně záplatujeme my. Je to vrstva, u které nejčastěji vzniká technický dluh — a u nás vám nevzniká.

  5. 05

    Automatický failover mezi datacentry

    DNS HA · dva nezávislé uzly

    Když vypadne primární lokalita, provoz se přesměruje na záložní bez ručního zásahu. Nikdo nemusí být u telefonu, aby se služba vrátila.

  6. 06

    Vyvažování provozu a HA proxy

    proxy vrstva · rozkládání zátěže · redundance protokolem VRRP

    Vysokou dostupnost vašich aplikací hlídá proxy vrstva, která balancuje provoz mezi běžící instance. Sama je zálohovaná protokolem VRRP — když vypadne jeden uzel proxy, druhý převezme adresu bez zásahu obsluhy.

  7. 07

    Replikace databáze

    streaming replikace master → replika

    Databáze běží zrcadleně i v druhé lokalitě. Data jsou připravená jinde dřív, než je budete potřebovat — obnova nezačíná rozbalováním zálohy.

  8. 08

    Bezpečné propojení s vaší sítí

    site-to-site VPN · dva redundantní tunely

    Šifrované spojení z obou datacenter do vaší interní sítě. Výpadek jednoho tunelu nepřeruší přístup k interním systémům.

  9. 09

    Zálohování a obnova

    několik vrstev záloh · databáze každých 6 h · denní inkrement · týdenní plná záloha · retence od dní po roky

    Zálohy vznikají v několika nezávislých vrstvách a držíme je geograficky odděleně od produkce, takže je nezničí stejný incident jako primární data. Jak hluboko do minulosti body obnovy sahají — od dní po roky — stanovíme podle vašich provozních a regulatorních požadavků. Obnovu testujeme, ne jen plánujeme.

  10. 10

    Kapacitní plánování

    průběžný monitoring využití zdrojů

    Sledujeme trend vytížení a navýšení navrhneme v předstihu. O kapacitní strop se nedozvíte z incidentu, ale z naší zprávy.

  11. 11

    Obnova hardwaru

    výměny vadných komponent i refresh na straně Nuxu

    Stárnoucí železo měníme na své náklady a riziko. Neřešíte amortizaci, konec podpory ani investiční cyklus — a paušál se tím nemění.

  12. 12

    Provoz datacenter

    racky · redundantní napájení · chlazení · řízený fyzický přístup

    Fyzická vrstva, kterou byste jinak museli postavit a certifikovat sami. Tady je součástí služby.

Uvedené parametry jsou výchozí konfigurace platformy. Konkrétní rozsah — kapacitu, retenci záloh i úroveň redundance — ladíme podle profilu vašeho provozu a zapisujeme do smlouvy.

Vrstva 09 podrobně

Jak vypadá zálohovací režim

Co vzniká v primární lokalitě, co odchází do druhé a jak dlouho se body obnovy drží. Bez toho zůstane výčet intervalů jen řádkem ve specifikaci.

Tady zálohy vznikají

Produkce · primární lokalita

DC7 · Enterprise HA lokalita · HPE Synergy

Vrstvy záloh

  • Databázekaždých 6 h
  • Inkrementální zálohadenně
  • Plná zálohatýdně

okno 7 dní · čas zleva doprava


šifrovaný přenos
do druhé lokality

Tady se zálohy drží

Zálohy · druhá lokalita

OPND · geograficky oddělené od produkce

Body obnovyhusté u dneška, řidší do minulosti
rokyměsícetýdnydny

Co sem přichází

  • Databáze
  • Inkrementální záloha
  • Plná záloha

retence od dní po roky

obnovu testujeme, ne jen plánujeme

Schéma režimu, ne kalendář konkrétního provozu. Zálohy vznikají v několika vrstvách; jejich hustotu i hloubku retence — od dní po roky — ladíme podle kritičnosti aplikace a vašich regulatorních požadavků a zapisujeme do smlouvy. Cílové hodnoty RPO a RTO z nich vycházejí.

Přenesená odpovědnost

Provozní kompetence, kterou nemusíte budovat interně.

Platforma nepokrývá jen běžící prostředky, ale i schopnost je provozovat, obnovovat a koordinovat s vaší aplikací. To je ta část, kterou se nejtěžší nahrazuje nákupem hardwaru.

01

Rezervní kapacita

Držíme rezervu CPU, RAM i úložiště pro špičky a růst. Neplatíte za každé navýšení zvlášť a nemusíte ho plánovat rok dopředu.

02

Druhá lokalita

Kompletní provoz záložního datacentra včetně replikace a testování failover scénářů. Bez vlastní investice do druhého místa.

03

Obnova hardwaru

Refresh železa i výměny vadných komponent na nákladech a riziku Nuxu. Konec životnosti serveru není váš problém.

04

Provoz datacentra

Racky, redundantní napájení, chlazení, řízený fyzický přístup a fyzická bezpečnost. Vrstva, ke které se nikdy nedostanete.

05

Odpovědnost za výpadek

Úložiště, síť, hypervisor i datacentrum. Infrastrukturní incident řešíme my — ne váš interní tým v noci.

06

Koordinace platformy s aplikací

Údržbová okna, migrace a upgrady plánujeme tak, aby nepřerušily aplikační provoz. Termíny s vámi ladíme, neoznamujeme.

SLA a dostupnost

Dostupnost, která stojí ve smlouvě, ne v prezentaci.

Platforma je stavěná jako vysoká dostupnost na každé vrstvě: redundantní výpočetní uzly, proxy pár s VRRP, distribuované úložiště, replikovaná databáze a failover do druhé lokality. Konkrétní parametry SLA k tomu stanovujeme podle kritičnosti vašeho provozu — univerzální číslo na webu by nic neznamenalo, protože jiné hodnoty jsou dosažitelné pro portál s replikovanou databází a jiné pro prostředí obnovované ze zálohy.

RPO a RTO
Cíle obnovy sjednané podle kritičnosti provozu a architektury aplikace
Nepřetržitě
Monitoring a definovaná eskalace incidentů s pojmenovanými kontakty; bezpečnostní incidenty vede tým Nux CSIRT
Reporting
Pravidelný přehled provozu, incidentů a využití kapacity
Auditní stopa
Záznam zásahů do infrastruktury jako podklad pro váš audit

Nezávazná konzultace

Řekněte nám, co provozujete.

Projdeme kapacitu, závislosti a vaše nároky na dostupnost a připravíme návrh rozsahu. Nezávazně a pod NDA, pokud si to vyžádáte.

Radek Růžička, jednatel a technický ředitel Nux s.r.o.

Platformu má na starost

Radek Růžička

jednatel a technický ředitel

meet@nux.cz
+420 250 250 500Připraveni i na NDA