commit
This commit is contained in:
Stanislav Hubacek
43
.opencode/agents/kb-research.md
Normal file
43
.opencode/agents/kb-research.md
Normal file
@@ -0,0 +1,43 @@
|
||||
---
|
||||
description: >
|
||||
Zpracovává [todo] položky v knowledge base. Hledá v souborech sources/<area>/sources.md položky se statusem
|
||||
[todo], rešeršuje téma, zapracuje nové poznatky do příslušného KB souboru a změní status na [done].
|
||||
Spouštět s konkrétním požadavkem, např. "zpracuj všechny todo v sources/cicd/". Používat pro rozšiřování
|
||||
knowledge base o nová témata z nespracovaných zdrojů.
|
||||
mode: subagent
|
||||
permission:
|
||||
edit: allow
|
||||
read: allow
|
||||
bash: allow
|
||||
webfetch: allow
|
||||
websearch: allow
|
||||
---
|
||||
|
||||
Jsi **KB Research Agent** — tvým úkolem je systematicky zpracovávat `[todo]` položky v knowledge base.
|
||||
|
||||
## Workflow
|
||||
|
||||
1. **Analýza** — projdi `sources/<area>/sources.md` v zadané oblasti a identifikuj všechny řádky se `[todo]`
|
||||
2. **Rešerše** — pro každou todo položku:
|
||||
- Pokud má URL, načti obsah (webfetch)
|
||||
- Pokud je to kniha / standard, vyhledej aktuální informace (websearch)
|
||||
- Získej klíčové koncepty, definice, best practices
|
||||
3. **Zapracování** — rozšiř příslušný `.md` soubor v kořeni KB o nové poznatky
|
||||
4. **Update zdroje** — změň `[todo]` na `[done]`
|
||||
|
||||
## Pravidla
|
||||
|
||||
- Neodstraňuj existující obsah — pouze přidávej a rozšiřuj
|
||||
- Udržuj konzistentní formát (tabulky, seznamy, hlavičky)
|
||||
- Piš česky, fakticky, bez subjektivních názorů
|
||||
- Každý nový koncept doplň krátkým popisem
|
||||
- Pokud narazíš na `[done]` položku, nech ji být
|
||||
- Na konci vytvoř summary: co bylo zpracováno, co bylo přidáno
|
||||
|
||||
## Příklady použití
|
||||
|
||||
Uživatel: "zpracuj všechny todo v sources/cicd/"
|
||||
→ Projdeš sources/cicd/sources.md, zpracuješ každý [todo] záznam a rozšíříš CICD.md
|
||||
|
||||
Uživatel: "zpracuj [todo] položku o CAP theorem"
|
||||
→ Najdeš konkrétní todo o CAP theorem (v sources/databases/), provedeš rešerši a rozšíříš DATABASES.md
|
||||
89
.opencode/agents/kb-reviewer.md
Normal file
89
.opencode/agents/kb-reviewer.md
Normal file
@@ -0,0 +1,89 @@
|
||||
---
|
||||
description: >
|
||||
Kontroluje konzistenci, kvalitu a aktuálnost celé knowledge base. Prochází všechny .md soubory,
|
||||
ověřuje formátování (tabulky, nadpisy, seznamy), křížové odkazy mezi soubory, duplicitní obsah,
|
||||
zastaralé informace a konzistenci se zdroji v sources/. Spouštět např. "proveď review celé KB"
|
||||
nebo "zkontroluj konzistenci CICD.md".
|
||||
mode: subagent
|
||||
permission:
|
||||
edit: allow
|
||||
read: allow
|
||||
webfetch: allow
|
||||
websearch: allow
|
||||
---
|
||||
|
||||
Jsi **KB Reviewer** — tvým úkolem je auditovat kvalitu knowledge base.
|
||||
|
||||
## Kontrolní oblasti
|
||||
|
||||
### 1. Formátování a konzistence
|
||||
|
||||
- [ ] Všechny soubory mají stejnou strukturu nadpisů (začínají na `#`, sekce `##`)
|
||||
- [ ] Tabulky mají konzistentní formát (zarovnání, oddělovače `|---|`)
|
||||
- [ ] Kódové bloky používají ``` s jazykovým tagem
|
||||
- [ ] Seznamy jsou jednotně odsazeny
|
||||
- [ ] Diagramy (ASCII / Mermaid) jsou čitelné
|
||||
|
||||
### 2. Křížové odkazy
|
||||
|
||||
- [ ] Témata, která se překrývají mezi soubory, na sebe vzájemně odkazují
|
||||
- Např. "monitoring v CICD" → odkaz na MONITORING.md
|
||||
- Např. "cloud networking" → odkaz mezi CLOUD.md a NETWORKING.md
|
||||
- [ ] README.md obsahuje všechny aktuální soubory
|
||||
- [ ] Každý `.md` soubor v kořeni je zmíněn v README.md
|
||||
|
||||
### 3. Duplicity
|
||||
|
||||
- [ ] Stejný koncept není vysvětlen na více místech s rozdílnými informacemi
|
||||
- [ ] Pokud se koncept opakuje, je konzistentní (stejná čísla, definice, doporučení)
|
||||
|
||||
### 4. Aktuálnost
|
||||
|
||||
- [ ] Verze nástrojů odpovídají aktuálním stabilním vydáním (ověř webem)
|
||||
- [ ] EOL technologie jsou označeny nebo odstraněny
|
||||
- [ ] Žádné "brzy bude" — pokud není splněno, označ jako outdated
|
||||
- [ ] Licence a ceny (kde uvedeny) jsou aktuální
|
||||
|
||||
### 5. Konzistence se zdroji
|
||||
|
||||
- [ ] Každý fakt v KB by měl mít dohledatelný zdroj v `sources/`
|
||||
- [ ] Pokud je zdroj v `sources/` označen `[done]`, měl by být odpovídající obsah v KB
|
||||
- [ ] Pokud `sources/` obsahuje zdroj k tématu, které v KB chybí — upozorni
|
||||
|
||||
### 6. Pravopis a styl
|
||||
|
||||
- [ ] Žádné překlepy
|
||||
- [ ] Konzistentní terminology (nepoužívat "VM" i "virtuální stroj" v jednom souboru)
|
||||
- [ ] Anglicismy jsou tam kde dávají smysl (vysvětlené při prvním použití)
|
||||
|
||||
## Report
|
||||
|
||||
Na konci vygeneruj přehledný report:
|
||||
|
||||
```markdown
|
||||
## Review report — YYYY-MM-DD
|
||||
|
||||
### Problémy (nutno opravit)
|
||||
- [soubor.md:řádek] popis problému
|
||||
|
||||
### Doporučení
|
||||
- [soubor.md] popis
|
||||
|
||||
### Stav
|
||||
- ✅ Kontrola formátování: OK / N problémů
|
||||
- ✅ Křížové odkazy: OK / N chybějících
|
||||
- ✅ Duplicity: OK / N nalezeno
|
||||
- ✅ Aktuálnost: OK / N zastaralých
|
||||
- ✅ Konzistence se zdroji: OK / N nesrovnalostí
|
||||
```
|
||||
|
||||
## Příklady použití
|
||||
|
||||
Uživatel: "proveď review celé KB"
|
||||
→ Projdeš všechny soubory a vypíšeš kompletní report
|
||||
|
||||
Uživatel: "zkontroluj konzistenci NETWORKING.md"
|
||||
→ Zaměříš se jen na jeden soubor, zkontroluješ ho ze všech úhlů
|
||||
|
||||
Uživatel: "najdi duplicity mezi CLOUD.md a INFRASTRUCTURE.md"
|
||||
→ Porovnáš specifické soubory
|
||||
53
.opencode/agents/kb-source-scout.md
Normal file
53
.opencode/agents/kb-source-scout.md
Normal file
@@ -0,0 +1,53 @@
|
||||
---
|
||||
description: >
|
||||
Vyhledává nové zdroje (knihy, články, dokumentace, nástroje, standardy, videa, certifikace)
|
||||
pro rozšíření knowledge base. Prochází web, identifikuje relevantní materiály k zadané oblasti
|
||||
a přidává je jako [todo] do příslušného sources/<area>/sources.md. Používat pro kontinuální
|
||||
obohacování knowledge base o aktuální zdroje. Spouštět např. "najdi nové zdroje pro cloud architekturu".
|
||||
mode: subagent
|
||||
permission:
|
||||
edit: allow
|
||||
read: allow
|
||||
webfetch: allow
|
||||
websearch: allow
|
||||
---
|
||||
|
||||
Jsi **KB Source Scout** — tvým úkolem je aktivně vyhledávat nové kvalitní zdroje pro knowledge base.
|
||||
|
||||
## Workflow
|
||||
|
||||
1. **Analýza stavu** — přečti `sources/<area>/sources.md` pro zadanou oblast, zjisti co už je zdokumentované
|
||||
2. **Rešerše novinek** — pomocí websearch najdi nové zdroje:
|
||||
- Oficiální dokumentace a whitepapery
|
||||
- Knihy (ISBN, autor, vydání)
|
||||
- Kvalitní články a blog posty
|
||||
- Nástroje a frameworky
|
||||
- Standardy a RFC
|
||||
- Video kurzy a přednášky (konference)
|
||||
- Certifikace
|
||||
3. **Deduplikace** — zkontroluj, zda zdroj už není v sources.md
|
||||
4. **Přidání** — doplň nové zdroje do příslušného `sources/<area>/sources.md` s tagem `[todo]`
|
||||
|
||||
## Kritéria kvality
|
||||
|
||||
- **Oficiální dokumentace** — preferovat primary sources (vendor docs, RFC, standardy)
|
||||
- **Knihy** — preferovat vydání z posledních 3 let, u klasik (jako TCP/IP Illustrated) stačí starší
|
||||
- **Články** — preferovat autority v oboru (Brendan Gregg, Martin Kleppmann, Kelsey Hightower, ...)
|
||||
- **Nástroje** — aktivní komunita, aktuální verze, open-source bonus
|
||||
- Vyhýbej se: zjevně zastaralým materiálům (>5 let mimo obor), clickbaitům, nedůvěryhodným zdrojům
|
||||
|
||||
## Formát zápisu
|
||||
|
||||
Pro každý nový zdroj přidej řádek do tabulky v příslušném sources.md.
|
||||
Udržuj konzistentní formát dle existujících záznamů v souboru.
|
||||
|
||||
## Příklady použití
|
||||
|
||||
Uživatel: "najdi nové zdroje pro cloud architekturu"
|
||||
→ Prohledáš web, najdeš knihy, články, whitepapery o cloud architektuře z roku 2025/2026 a přidáš je do sources/cloud/sources.md jako [todo]
|
||||
|
||||
Uživatel: "scout infra"
|
||||
→ Prohledáš nové zdroje pro infrastrukturu (hypervisory, DC, storage, hardware) a přidáš je do sources/infrastructure/sources.md
|
||||
|
||||
Uživatel: "najdi novinky v observability za poslední rok"
|
||||
→ Zaměříš se na monitoring/observability, hledáš nové nástroje, články, verze a doplníš do sources/monitoring/sources.md
|
||||
17
.opencode/opencode.json
Normal file
17
.opencode/opencode.json
Normal file
@@ -0,0 +1,17 @@
|
||||
{
|
||||
"$schema": "https://opencode.ai/config.json",
|
||||
"agent": {
|
||||
"kb-research": {
|
||||
"description": "Zpracovává [todo] položky v knowledge base — rešerše a zapracování nových témat",
|
||||
"mode": "subagent"
|
||||
},
|
||||
"kb-source-scout": {
|
||||
"description": "Vyhledává nové zdroje (knihy, články, dokumentace) a přidává je do sources/ jako [todo]",
|
||||
"mode": "subagent"
|
||||
},
|
||||
"kb-reviewer": {
|
||||
"description": "Audituje konzistenci, aktuálnost, křížové odkazy, duplicity a formátování celé KB",
|
||||
"mode": "subagent"
|
||||
}
|
||||
}
|
||||
}
|
||||
498
CICD.md
Normal file
498
CICD.md
Normal file
@@ -0,0 +1,498 @@
|
||||
# 🔄 CI/CD a DevOps
|
||||
|
||||
## CI/CD Pipeline
|
||||
|
||||
```
|
||||
Code Commit → Build → Test → Package → Deploy to Staging → Integration Tests → Deploy to Production
|
||||
```
|
||||
|
||||
### Detailní pipeline stages
|
||||
|
||||
```
|
||||
1. Checkout ──→ 2. Lint ──→ 3. Test ──→ 4. Build ──→ 5. Scan ──→ 6. Publish ──→ 7. Deploy
|
||||
│ │ │
|
||||
ESLint/ Unit/Integ/ SAST/SCA/
|
||||
Prettier e2e tests Container scan
|
||||
```
|
||||
|
||||
| Stage | Nástroje | Co se děje |
|
||||
|-------|----------|------------|
|
||||
| **Checkout** | git clone, fetch | Stažení kódu z repozitáře, včetně submodulů |
|
||||
| **Lint** | ESLint, Prettier, RuboCop, golangci-lint | Statická analýza kódu, formátování |
|
||||
| **Test (unit)** | Jest, pytest, JUnit | Rychlé testy (ms až s), bez závislostí |
|
||||
| **Test (integration)** | Testcontainers, Docker Compose | Testy s DB, message queue, externí služby |
|
||||
| **Test (e2e)** | Playwright, Cypress, Selenium | Full-stack testy v prohlížeči |
|
||||
| **Build** | Docker build, go build, npm build, Maven | Kompilace, sestavení artifactu |
|
||||
| **Scan (SAST)** | Semgrep, SonarQube, CodeQL | Statická analýza bezpečnosti |
|
||||
| **Scan (DAST)** | OWASP ZAP, Burp Suite | Dynamická analýza (běžící aplikace) |
|
||||
| **Scan (SCA)** | Dependabot, Snyk, Trivy | Analýza závislostí a CVE |
|
||||
| **Publish** | Docker push, npm publish, Maven deploy | Nahrání artifactu do registru |
|
||||
| **Deploy** | ArgoCD, Terraform, Helm, kubectl | Nasazení do cílového prostředí |
|
||||
|
||||
### Continuous Integration (CI)
|
||||
|
||||
- Automatické sestavení a testy při každém commitu
|
||||
- Rychlá feedback smyčka (< 10 min)
|
||||
- Linting, type checking, unit testy, security scan (SAST)
|
||||
|
||||
### Continuous Delivery (CD)
|
||||
|
||||
- Automatické deploye do staging / test prostředí
|
||||
- Ruční schválení do produkce (optional)
|
||||
- Smoke testy po deployi
|
||||
|
||||
### Continuous Deployment
|
||||
|
||||
- Plně automatický deploy do produkce
|
||||
- Vyžaduje vysokou důvěru v testy a monitoring
|
||||
- Feature flagy pro řízení rizika
|
||||
|
||||
## GitHub Actions detail
|
||||
|
||||
### Workflow syntax
|
||||
|
||||
```yaml
|
||||
name: CI Pipeline
|
||||
on:
|
||||
push:
|
||||
branches: [main]
|
||||
pull_request:
|
||||
branches: [main]
|
||||
|
||||
env:
|
||||
NODE_VERSION: "20"
|
||||
|
||||
jobs:
|
||||
lint:
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- uses: actions/checkout@v4
|
||||
- uses: actions/setup-node@v4
|
||||
with:
|
||||
node-version: ${{ env.NODE_VERSION }}
|
||||
- run: npm ci
|
||||
- run: npm run lint
|
||||
|
||||
test:
|
||||
runs-on: ubuntu-latest
|
||||
needs: lint
|
||||
strategy:
|
||||
matrix:
|
||||
node-version: [18, 20, 22]
|
||||
steps:
|
||||
- uses: actions/checkout@v4
|
||||
- name: Run tests
|
||||
run: npm test
|
||||
```
|
||||
|
||||
### Matrix builds
|
||||
|
||||
- Spouští stejné joby s různými parametry (OS, jazyková verze, architektura)
|
||||
- `strategy.matrix` — kombinace parametrů (kartézský součin)
|
||||
- `strategy.fail-fast` — zastavení všech při selhání jednoho
|
||||
|
||||
### Reusable workflows
|
||||
|
||||
```yaml
|
||||
# .github/workflows/deploy.yml (called)
|
||||
on:
|
||||
workflow_call:
|
||||
inputs:
|
||||
environment:
|
||||
required: true
|
||||
type: string
|
||||
secrets:
|
||||
cloud_role:
|
||||
required: true
|
||||
|
||||
# Volání v caller workflow
|
||||
jobs:
|
||||
deploy:
|
||||
uses: ./.github/workflows/deploy.yml
|
||||
with:
|
||||
environment: staging
|
||||
secrets:
|
||||
cloud_role: ${{ secrets.STAGING_ROLE }}
|
||||
```
|
||||
|
||||
### Composite actions
|
||||
|
||||
- Vlastní akce bez nutnosti samostatného repozitáře
|
||||
- Kombinace `run`, `uses`, `shell` kroků
|
||||
- Use case: standardizace lint/test/build napříč repozitáři
|
||||
|
||||
### Self-hosted runners
|
||||
|
||||
- Vlastní infrastruktura pro běh GitHub Actions
|
||||
- Use case: privátní síť, GPU, specifický HW, compliance
|
||||
- Škálování: actions-runner-controller (Kubernetes), auto-scaling groups
|
||||
- Bezpečnost: izolace jobů, ephemeral runners
|
||||
|
||||
## GitLab CI detail
|
||||
|
||||
```yaml
|
||||
stages:
|
||||
- lint
|
||||
- test
|
||||
- build
|
||||
- deploy
|
||||
|
||||
variables:
|
||||
DOCKER_IMAGE: $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA
|
||||
|
||||
lint:
|
||||
stage: lint
|
||||
image: node:20
|
||||
script:
|
||||
- npm ci
|
||||
- npm run lint
|
||||
|
||||
test:
|
||||
stage: test
|
||||
image: node:20
|
||||
needs: ["lint"]
|
||||
script:
|
||||
- npm test
|
||||
artifacts:
|
||||
paths:
|
||||
- coverage/
|
||||
reports:
|
||||
coverage_report:
|
||||
coverage_format: cobertura
|
||||
path: coverage/cobertura-coverage.xml
|
||||
|
||||
deploy-staging:
|
||||
stage: deploy
|
||||
needs: ["build"]
|
||||
rules:
|
||||
- if: $CI_COMMIT_BRANCH == "main"
|
||||
environment:
|
||||
name: staging
|
||||
url: https://staging.example.com
|
||||
script:
|
||||
- kubectl set image deployment/app app=$DOCKER_IMAGE
|
||||
```
|
||||
|
||||
**Koncepty**:
|
||||
- **Stages** — sekvenční fáze (každá stage může mít více jobů paralelně)
|
||||
- **Rules** — podmínky spuštění (branch, tag, changes, variables) — nahrazuje `only/except`
|
||||
- **Needs** — DAG závislosti (job nemusí čekat na celou stage)
|
||||
- **Artifacts** — předávání souborů mezi joby (binárky, reporty, cache)
|
||||
- **Environments** — sledování deployů (rollback, history, approvals)
|
||||
|
||||
### DAG pipelines (needs)
|
||||
|
||||
```
|
||||
lint ──→ test ──→ build ──→ deploy-staging ──→ deploy-prod
|
||||
↓
|
||||
build-arm ──→ test-arm
|
||||
```
|
||||
|
||||
- Definuje závislosti mezi joby (ne nutně stages)
|
||||
- Umožňuje paralelizaci nezávislých jobů
|
||||
- Snižuje celkový čas pipeline
|
||||
|
||||
## Infrastructure as Code (IaC)
|
||||
|
||||
| Nástroj | Typ | Jazyk |
|
||||
|---------|-----|-------|
|
||||
| Terraform | Declarative | HCL |
|
||||
| OpenTofu | Declarative | HCL (fork Terraformu) |
|
||||
| Pulumi | Declarative | TypeScript, Python, Go, C# |
|
||||
| AWS CDK | Declarative | TypeScript, Python, Java, C# |
|
||||
| CloudFormation | Declarative | YAML/JSON (AWS) |
|
||||
| Azure ARM/Bicep | Declarative | Bicep, JSON |
|
||||
| Ansible | Imperative/Config | YAML |
|
||||
| Chef/Puppet | Config mgmt | Ruby DSL |
|
||||
|
||||
### Terraform detail
|
||||
|
||||
#### State locking mechanism
|
||||
|
||||
| Backend | Locking mechanism | Poznámka |
|
||||
|---------|------------------|----------|
|
||||
| **S3 + DynamoDB** | DynamoDB (ConditionalPut) | Nejčastější, levný, jednoduchý |
|
||||
| **Terraform Cloud** | Built-in (API) | SaaS, audit logy, VCS integration |
|
||||
| **Azure Storage** | Azure Blob Lease | Podobný S3 modelu |
|
||||
| **GCS** | Cloud Storage Object Hold | Omezené |
|
||||
| **Consul** | Consul KV session_lock | High-availability |
|
||||
| **PostgreSQL** | pg_advisory_lock / row lock | Vlastní backend |
|
||||
|
||||
#### State backends comparison
|
||||
|
||||
| Vlastnost | S3 + DynamoDB | Terraform Cloud | Consul |
|
||||
|-----------|--------------|----------------|--------|
|
||||
| Cena | $ (S3 + DynamoDB) | $$ (free tier omezený) | $$ (infra) |
|
||||
| Team workflow | GitHub Actions + OIDC | Native RBAC, runs | Vlastní |
|
||||
| Locking | DynamoDB | Built-in | Consul session |
|
||||
| History | S3 versioning | Full history, diff | None |
|
||||
| Remote ops | Ne (pouze state) | Ano (remote runs) | Ne |
|
||||
| Encryption | SSE-S3/KMS | At rest + in transit | TLS |
|
||||
|
||||
#### Workspaces vs Terragrunt
|
||||
|
||||
| Aspekt | Terraform Workspaces | Terragrunt |
|
||||
|--------|---------------------|------------|
|
||||
| **Separace stavu** | Jeden backend, klíč: `env:/workspace` | Samostatný backend per env |
|
||||
| **Code reuse** | Stejný kód, jiné proměnné | DRY konfigurace, moduly |
|
||||
| **Riziko** | Omylem `apply` do špatného workspace | Izolované backends |
|
||||
| **Kdy použít** | Jednoduché projekty, <5 env | Mikroservice, multi-env, multi-team |
|
||||
| **Extra features** | — | Dependency, include, before_hook |
|
||||
|
||||
#### Provider versioning
|
||||
|
||||
```hcl
|
||||
terraform {
|
||||
required_version = ">= 1.5, < 2.0"
|
||||
required_providers {
|
||||
aws = {
|
||||
source = "hashicorp/aws"
|
||||
version = "~> 5.0"
|
||||
}
|
||||
kubernetes = {
|
||||
source = "hashicorp/kubernetes"
|
||||
version = ">= 2.23"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
- `~> 5.0` — pouze patch verze (5.x, x ≥ 0)
|
||||
- `>= 2.23, < 3.0` — jakákoli 2.x od 2.23
|
||||
- `~>` constraints zabraňují breaking changes v major/minor
|
||||
|
||||
### Terraform workflow
|
||||
|
||||
```
|
||||
terraform init → Stáhne provider moduly
|
||||
terraform plan → Zobrazí změny
|
||||
terraform apply → Aplikuje změny
|
||||
terraform destroy → Zničí infrastrukturu
|
||||
terraform validate → Validace syntaxe
|
||||
terraform fmt → Formátování HCL
|
||||
```
|
||||
|
||||
### State management
|
||||
|
||||
- Remote state (S3, Terraform Cloud, Azure Storage)
|
||||
- State locking (DynamoDB, Consul)
|
||||
- Workspaces pro oddělení prostředí
|
||||
|
||||
## Dockerfile best practices
|
||||
|
||||
```dockerfile
|
||||
# Multi-stage build
|
||||
FROM node:20-alpine AS builder
|
||||
WORKDIR /app
|
||||
COPY package*.json ./
|
||||
RUN npm ci --only=production
|
||||
COPY . .
|
||||
RUN npm run build
|
||||
|
||||
# Runtime stage — distroless
|
||||
FROM gcr.io/distroless/nodejs20-debian12
|
||||
WORKDIR /app
|
||||
COPY --from=builder /app/dist ./dist
|
||||
COPY --from=builder /app/node_modules ./node_modules
|
||||
USER nonroot:nonroot
|
||||
EXPOSE 3000
|
||||
CMD ["dist/server.js"]
|
||||
```
|
||||
|
||||
**Pravidla**:
|
||||
- **Multi-stage build** — oddělení build tools od runtime
|
||||
- **Distroless images** — minimal attack surface (žádný shell, package manager)
|
||||
- **Non-root user** — USER nonroot (security best practice)
|
||||
- **Layer caching** — nejdříve kopírovat málo se měnící soubory (package.json → npm ci → code)
|
||||
- **Small base image** — Alpine (5 MB), distroless (minimální), scratch (Go static binary)
|
||||
- **Healthcheck** — HEALTHCHECK instrukce pro orchestrátor
|
||||
- **Labels** — LABEL maintainer, version, git commit
|
||||
- **.dockerignore** — minimalizace build contextu
|
||||
|
||||
## Artifact management
|
||||
|
||||
### Docker registries
|
||||
|
||||
| Registry | Public/Private | Cena | Integrace |
|
||||
|----------|---------------|------|-----------|
|
||||
| **Docker Hub** | Obojí | Public free, private $5/měsíc | GitHub Actions, GitLab |
|
||||
| **ECR (AWS)** | Private | $0.10/GB/měsíc + data transfer | IAM, ECS, EKS |
|
||||
| **GHCR (GitHub)** | Obojí | Public free, private 500 MB free | GitHub Actions, npm |
|
||||
| **GCR / Artifact Registry** | Private | $0.10/GB/měsíc | GKE, Cloud Build |
|
||||
| **ACR (Azure)** | Private | $0.11/GB/měsíc | AKS, Azure DevOps |
|
||||
| **Harbor** | Private (self-hosted) | Zdarma (open source) | Vlastní, CNCF |
|
||||
|
||||
### Helm charts
|
||||
|
||||
- **Repository** — index.yaml + chart .tgz na HTTP serveru (S3, GitHub Pages, ChartMuseum)
|
||||
- **OCI registry** — Helm 3.8+ podporuje uložení chartů v OCI registrech (ECR, GHCR, Harbor)
|
||||
- **Versioning** — chart version (balíček) + app version (aplikace)
|
||||
|
||||
### SBOM (Software Bill of Materials)
|
||||
|
||||
- **SPDX** / **CycloneDX** — standardní formáty SBOM
|
||||
- Generování: Trivy, Syft, grype
|
||||
- Use case: supply chain security, compliance (EO 14028, EU CRA)
|
||||
|
||||
## Konfigurace a tajemství
|
||||
|
||||
| Nástroj | Popis |
|
||||
|---------|-------|
|
||||
| Vault (HashiCorp) | Dynamic secrets, encryption-as-a-service |
|
||||
| AWS Secrets Manager | Managed, auto-rotation |
|
||||
| Azure Key Vault | Managed, HSM podpora |
|
||||
| GCP Secret Manager | Managed |
|
||||
| SOPS | Encryption v git repos |
|
||||
| Sealed Secrets | Encrypted secrets pro Kubernetes |
|
||||
|
||||
### Secret management workflows
|
||||
|
||||
**Vault agent injector** (Kubernetes)
|
||||
- Sidecar container (vault-agent) injectuje secrets do podu
|
||||
- Secrets mountovány jako tmpfs volume (ne do environment variables)
|
||||
- Auto-rotation: vault-agent periodicky refreshuje secrets
|
||||
|
||||
**External Secrets Operator** (Kubernetes)
|
||||
- CRD: `ExternalSecret` → vytváří `Secret` v K8s
|
||||
- Backend: AWS Secrets Manager, Azure Key Vault, GCP Secret Manager, Vault
|
||||
- Push-based refresh: změna v externím store → propagate do K8s
|
||||
|
||||
**Sealed Secrets**
|
||||
- `kubeseal` zašifruje Secret na clusteru (controller má privátní klíč)
|
||||
- Zašifrovaný manifest (SealedSecret) může být bezpečně v gitu
|
||||
- Controller decryptuje při deployi
|
||||
|
||||
## GitOps
|
||||
|
||||
- **Princip**: Git je jediný zdroj pravdy (single source of truth)
|
||||
- **Nástroje**: ArgoCD, Flux, Rancher Fleet
|
||||
- Pull-based deploy — agent v clusteru sleduje repo a aplikuje změny
|
||||
- Auto-sync + drift detection
|
||||
|
||||
## Environment promotion (dev → staging → prod)
|
||||
|
||||
```
|
||||
Code → Dev (auto-deploy) → Staging (auto + smoke tests) → Prod (manual approval + gating)
|
||||
```
|
||||
|
||||
**Quality gates**:
|
||||
1. **Unit tests** — pass rate 100 %, code coverage ≥ 80 %
|
||||
2. **Integration tests** — all critical paths pass
|
||||
3. **SAST scan** — no critical/high vulnerabilities
|
||||
4. **SCA scan** — no known critical CVEs
|
||||
5. **Container scan** — all fixable vulns addressed
|
||||
6. **Smoke tests** — po deployi na staging (health endpoint, basic flow)
|
||||
7. **Manual approval** — pro produkci (volitelné při CD)
|
||||
|
||||
## Deployment strategie
|
||||
|
||||
| Strategie | Popis | Riziko |
|
||||
|-----------|-------|--------|
|
||||
| **Rolling update** | Postupná výměna instancí | Nízké |
|
||||
| **Blue/Green** | Dvě identická prostředí, přepojení trafficu | Střední |
|
||||
| **Canary** | % trafficu na novou verzi, postupné zvyšování | Nízké |
|
||||
| **Feature flag** | Zapnutí/vypnutí funkce bez deploye | Velmi nízké |
|
||||
| **A/B testing** | Různé verze pro různé uživatele | Nízké |
|
||||
|
||||
## Git branching strategies
|
||||
|
||||
| Strategie | Popis | Vhodné pro |
|
||||
|-----------|-------|-----------|
|
||||
| **Trunk-based** | Jeden hlavní branch (main), krátké feature branche (< 1 den) | CD, microservices, mature teams |
|
||||
| **GitHub Flow** | Main + feature branche, PRs, jednoduchý | Startupy, web apps |
|
||||
| **GitLab Flow** | Main + environment branche (staging, prod) + feature branche | Enterprise, regulated |
|
||||
| **GitFlow** | Develop + main + feature/release/hotfix branche | Release-based, enterprise legacy |
|
||||
| **One Flow** | Zjednodušený GitFlow (bez develop branche) | Střední týmy |
|
||||
|
||||
## Rollback strategies
|
||||
|
||||
| Strategie | Popis | Rychlost | Riziko |
|
||||
|-----------|-------|----------|--------|
|
||||
| **Forward fix** | Nový deploy s hotfixem | Pomalá (build + deploy) | Nízké |
|
||||
| **Rollback (revert commit)** | Revert gitu, nový deploy | Střední | Nízké |
|
||||
| **Blue/Green switchback** | Přepojení zpět na starou verzi | Okamžitá | DB inkompatibilita |
|
||||
| **Database rollback** | Reverze DB migrace (migrate down) | Pomalá | Data loss risk |
|
||||
|
||||
### Database rollback challenges
|
||||
|
||||
- **Breaking changes** — odstranění sloupce/tabulky znamená rollback problém (data ztracena)
|
||||
- **Best practice**: Expand → Migrate → Contract (nikdy neodstraňovat v jednom deployi)
|
||||
- **Tooling**: Flyway undo (limited), Liquibase rollback, pgroll (Postgres)
|
||||
- **Feature flagy** jako prevence — nový kód je za flagem, rollback = vypnutí flagu
|
||||
|
||||
## CI/CD Design Patterns
|
||||
|
||||
Moderní CI/CD pipeline řeší opakující se problémy pomocí návrhových vzorů:
|
||||
|
||||
| Vzor | Popis |
|
||||
|------|-------|
|
||||
| **Pipeline as Code** | Pipeline definovaná v YAML/Kotlin DSL (`.gitlab-ci.yml`, `.github/workflows/`) |
|
||||
| **Immutable Pipeline** | Každý build je artifact, nikdy se nemění |
|
||||
| **Quality Gate** | Branch protection, required checks, code coverage threshold |
|
||||
| **Deployment Strategy** | Blue/Green, Canary, Rolling (viz tabulka níže) |
|
||||
| **GitOps** | Pull-based deploy s auto-sync a drift detection |
|
||||
| **Shift-Left Security** | SAST/DAST/SCA součást pipeline |
|
||||
| **Dependency Caching** | Cache layer mezi běhy pipeline |
|
||||
|
||||
## Shift left security
|
||||
|
||||
### SCA (Software Composition Analysis)
|
||||
| Nástroj | Typ | Integrace |
|
||||
|---------|-----|-----------|
|
||||
| **Dependabot** | GitHub native | GitHub, auto-PR na fix |
|
||||
| **Renovate** | Multi-platform | GitHub, GitLab, Bitbucket |
|
||||
| **Snyk** | SaaS + CLI | Všechny platformy, Docker, IaC |
|
||||
| **Trivy** | CLI, OSS | CI/CD pipeline (GitHub Actions, GitLab) |
|
||||
|
||||
### SAST (Static Application Security Testing)
|
||||
| Nástroj | Jazyky | Charakteristika |
|
||||
|---------|--------|----------------|
|
||||
| **Semgrep** | 30+ (Python, Java, Go, JS/TS) | Rychlý, custom rules, CI-native |
|
||||
| **SonarQube** | 30+ | Komplexní, quality gates, tech debt |
|
||||
| **CodeQL** | 12 (C++, C#, Go, Java, JS/TS, Python) | GitHub native, query-based |
|
||||
| **Checkmarx** | 30+ | Enterprise, CxSAST, CxFlow |
|
||||
| **Fortify** | 30+ | Enterprise, SAST + DAST |
|
||||
|
||||
### Container scanning
|
||||
| Nástroj | Popis |
|
||||
|---------|-------|
|
||||
| **Trivy** | OSS, skenuje OS packages + language-specific + IaC |
|
||||
| **Grype** | OSS, od Anchore, rychlý, Syft pro SBOM |
|
||||
| **Clair** | Red Hat, OSS, OCI-compatible |
|
||||
| **Docker Scout** | Docker Desktop / CLI, integrace s Docker Hub |
|
||||
|
||||
## AI-Native Software Delivery (2025–2026)
|
||||
|
||||
AI transformuje DevOps 2.0:
|
||||
|
||||
- **AI-assisted CI/CD** — automatické diagnózy selhání pipeline, optimalizace resource alokace
|
||||
- **Agent Control Protocol (ACP)** / **Model Context Protocol (MCP)** — standardy pro interakci AI agentů s toolingem
|
||||
- **AI-driven cost management** — FinOps optimalizace cloudu
|
||||
- **Intelligent test selection** — ML určuje, které testy spustit podle změn v kódu
|
||||
- **Self-healing pipelines** — AI auto-detekuje a opravuje běžné problémy
|
||||
|
||||
Nové nástroje: Harness (AI-native CD), GitLab 19.0 (agentic MR workflows, secrets manager), Octopus Deploy.
|
||||
|
||||
## Nástroje pro pipeline
|
||||
|
||||
- **GitHub Actions** — integrovaný s GitHubem, velký marketplace
|
||||
- **GitLab CI** — nativní v GitLabu, auto DevOps
|
||||
- **Jenkins** — nejstarší, extensible, self-hosted
|
||||
- **CircleCI** — SaaS, rychlý
|
||||
- **Argo Workflows** — Kubernetes nativní
|
||||
- **Buildkite** — hybrid (vlastní agenti, SaaS orchestrator)
|
||||
|
||||
## Best practices
|
||||
|
||||
- **Idempotentní pipeline** — opakované spuštění dává stejný výsledek
|
||||
- **Immutable infrastructure** — nikdy neupravovat running server, vždy znovu nasadit
|
||||
- **Shift left** — testy a security co nejdříve v pipeline
|
||||
- **Artifact management** — všechny buildy verzované v registru (Docker Hub, ECR, GHCR)
|
||||
- **Dependency caching** — urychlení pipeline (npm ci, pip cache, Docker layer caching)
|
||||
- **Fail fast** — pipeline selže co nejdříve při chybě
|
||||
|
||||
## Zdroje
|
||||
|
||||
Odkazy, knihy a standardy: [sources/cicd/sources.md](sources/cicd/sources.md)
|
||||
- **Quality gates** — automated checks před každým povýšením do dalšího prostředí
|
||||
- **Pipeline visibility** — dashboard s aktuálním stavem všech pipeline (GitHub, GitLab, ArgoCD)
|
||||
315
CLOUD.md
Normal file
315
CLOUD.md
Normal file
@@ -0,0 +1,315 @@
|
||||
# ☁️ Cloud architektura
|
||||
|
||||
## Poskytovatelé
|
||||
|
||||
- **AWS** — největší tržní podíl, nejširší portfolio
|
||||
- **Azure** — silná integrace s Microsoft ekosystémem
|
||||
- **GCP** — Kubernetes (GKE), data & ML, síťová konektivita
|
||||
|
||||
## Modely nasazení
|
||||
|
||||
| Model | Popis |
|
||||
|-------|-------|
|
||||
| Public cloud | Sdílená infrastruktura poskytovatele |
|
||||
| Private cloud | Vyhrazená infrastruktura (on-prem nebo hosted) |
|
||||
| Hybrid cloud | Propojení public + private |
|
||||
| Multi-cloud | Více veřejných poskytovatelů |
|
||||
|
||||
## Multi-cloud strategie
|
||||
|
||||
### Důvody pro multi-cloud
|
||||
- **Vendor lock-in prevence** — diverzifikace rizika
|
||||
- **Regulatorní požadavky** — data residency v konkrétních regionech
|
||||
- **Best-of-breed** — každý provider má silné stránky (AWS networking, Azure enterprise, GCP data/ML)
|
||||
- **Akviziční scénáře** — merge & acquisition sjednocení
|
||||
|
||||
### Multi-cloud connectivity
|
||||
|
||||
| Metoda | Latence | Propustnost | Náklady |
|
||||
|--------|---------|-------------|---------|
|
||||
| Site-to-Site VPN | Střední | Omezená | Nízké |
|
||||
| Private interconnect (Direct Connect / ExpressRoute / Dedicated Interconnect) | Nízká | Vysoká | Vysoké |
|
||||
| Cloud-to-cloud VPN | Střední | Střední | Střední |
|
||||
| SD-WAN | Nízká | Vysoká | Střední |
|
||||
|
||||
### Výzvy
|
||||
- **Síťová komplexita** — rozdílné VPC/VNet koncepty, security modely
|
||||
- **IAM federace** — jednotné identity napříč cloudy (SSO, SAML, OIDC)
|
||||
- **Data gravitace** — pohyb dat mezi cloudy je drahý a pomalý
|
||||
- **Monitoring** — jeden pane of glass napříč cloudy (Grafana, Datadog)
|
||||
|
||||
## Migrační strategie — 6 Rs
|
||||
|
||||
| Strategie | Popis | Náročnost | Typický scénář |
|
||||
|-----------|-------|-----------|----------------|
|
||||
| **Rehost** (Lift & Shift) | Přesun VM/as-is bez změn | Nízká | Rychlá migrace, datacentrum exit, minimální riziko |
|
||||
| **Replatform** (Lift & Reshape) | Migrace s drobnými úpravami (např. RDS místo self-managed DB) | Střední | Optimalizace bez přepisování aplikace |
|
||||
| **Refactor** (Re-architect) | Přepis aplikace na cloud-native (microservices, serverless) | Vysoká | Maximalizace cloudu, dlouhodobá strategie |
|
||||
| **Repurchase** | Přechod na SaaS (např. Salesforce, Workday) | Nízká | Aplikace je zastaralá, existuje SaaS alternativa |
|
||||
| **Retire** | Vypnutí nepotřebných aplikací | Nízká | Aplikace již není používaná, decommission |
|
||||
| **Retain** | Ponechání on-prem | Žádná | Regulatorní důvody, příliš vysoké riziko migrace |
|
||||
|
||||
### Decision framework pro 6 Rs
|
||||
|
||||
```
|
||||
Start: Je aplikace potřebná?
|
||||
├── Ne → Retire
|
||||
└── Ano → Existuje SaaS alternativa?
|
||||
├── Ano → Repurchase
|
||||
└── Ne → Vyplatí se refactoring?
|
||||
├── Ano → Refactor
|
||||
└── Ne → Stačí změna platformy?
|
||||
├── Ano → Replatform
|
||||
└── Ne → Rehost
|
||||
```
|
||||
|
||||
## Well-Architected Framework (AWS)
|
||||
|
||||
1. **Operational Excellence** — automace, monitoring, dokumentace
|
||||
2. **Security** — IAM, encryption, compliance
|
||||
3. **Reliability** — recovery, škálování, záložní plány
|
||||
4. **Performance Efficiency** — right-sizing, výběr správných služeb
|
||||
5. **Cost Optimization** — FinOps, reserved instances, spot instances
|
||||
6. **Sustainability** (od 2022) — carbon footprint, energy efficiency
|
||||
|
||||
Obdoby: Azure Well-Architected Framework, GCP Architecture Framework
|
||||
|
||||
### Klíčové otázky z Well-Architected Review (~60 otázek)
|
||||
|
||||
**Operational Excellence (12 otázek)**
|
||||
- Jak jsou změny řízeny a automatizovány?
|
||||
- Jak jsou operace dokumentovány a sdíleny v týmu?
|
||||
- Jak jsou očekávané a neočekávané události reflektovány v operacích?
|
||||
- Jaké runbooky existují pro běžné provozní scénáře?
|
||||
- Jak probíhá incident management a postmortem proces?
|
||||
|
||||
**Security (12 otázek)**
|
||||
- Jak je implementováno identity & access management?
|
||||
- Jak jsou chráněna data v klidu a při přenosu?
|
||||
- Jak je zajištěna detekce bezpečnostních incidentů?
|
||||
- Jaké jsou postupy pro patch management a vulnerability remediation?
|
||||
- Jak jsou řízeny infrastrukturní kredenciály a secrets?
|
||||
|
||||
**Reliability (12 otázek)**
|
||||
- Jak je zajištěna dostupnost služby při výpadku komponenty?
|
||||
- Jak je implementováno backup a disaster recovery?
|
||||
- Jak service limity (quotas, throttling) ovlivňují spolehlivost?
|
||||
- Jak probíhá automatické škálování při změně zátěže?
|
||||
- Jaké jsou SLI/SLO metriky a jak jsou monitorovány?
|
||||
|
||||
**Performance Efficiency (12 otázek)**
|
||||
- Jak je vybrán správný typ a velikost compute/ storage?
|
||||
- Jak je optimalizována databázová vrstva (indexy, dotazy, caching)?
|
||||
- Jak je monitoring využit k identifikaci úzkých hrdel?
|
||||
- Jak je implementováno škálování (vertikální vs horizontální)?
|
||||
|
||||
**Cost Optimization (12 otázek)**
|
||||
- Jak jsou náklady alokovány na týmy/projekty (chargeback/showback)?
|
||||
- Jaké nástroje se používají pro analýzu nákladů?
|
||||
- Jak jsou identifikovány a eliminovány nevyužité zdroje?
|
||||
- Jak je optimalizováno licencování (BYOL, hybrid benefit)?
|
||||
|
||||
## Klíčové komponenty
|
||||
|
||||
### Výpočetní vrstva
|
||||
|
||||
- **VM / instance** — EC2, Azure VMs, GCE
|
||||
- **Container orchestrace** — EKS, AKS, GKE
|
||||
- **Serverless** — Lambda, Azure Functions, Cloud Functions
|
||||
- **PaaS** — App Engine, Elastic Beanstalk, Azure App Service
|
||||
|
||||
### Compute comparison matrix (AWS EC2)
|
||||
|
||||
| Rodina | Typ | vCPU:Memory | Use case | Příklady cen (on-demand, us-east-1) |
|
||||
|--------|-----|-------------|----------|--------------------------------------|
|
||||
| **General purpose** | M7g, m7i | 1:4 | Web servery, microservices, dev/test | m7i.large ~$0.088/h |
|
||||
| **Compute optimized** | C7g, c7i | 1:2 | HPC, batch processing, CI/CD, gaming | c7i.large ~$0.078/h |
|
||||
| **Memory optimized** | R7g, r7i, x2idn | 1:8 až 1:32 | In-memory DB (Redis), SAP HANA, real-time analytics | r7i.large ~$0.118/h |
|
||||
| **Storage optimized** | I4i, im4gn | 1:4 + NVMe | Transactional DB, data warehousing, Kafka | i4i.large ~$0.138/h |
|
||||
| **GPU / ML** | P5, g5, trn1 | GPU attach | AI training (P5), inference (g5), ML (trn1) | g5.xlarge ~$1.006/h |
|
||||
|
||||
Viz [HARDWARE.md](HARDWARE.md#gpu-v-serverech) pro detail GPU modelů a konfigurací.
|
||||
|
||||
### Úložiště
|
||||
|
||||
- **Object storage** — S3, Blob Storage, Cloud Storage
|
||||
- **Block storage** — EBS, managed disks, persistent disks
|
||||
- **File storage** — EFS, Azure Files, Filestore
|
||||
- **CDN** — CloudFront, Azure CDN, Cloud CDN
|
||||
|
||||
### S3 Storage Classes
|
||||
|
||||
| Třída | Dostupnost | Retrieval time | Cena / GB / měsíc | Use case |
|
||||
|-------|-----------|----------------|-------------------|----------|
|
||||
| **S3 Standard** | 99.99 % | milisekundy | ~$0.023 | Aktivní data, častý přístup |
|
||||
| **S3 Intelligent-Tiering** | 99.9 % | milisekundy | ~$0.023 + monitoring fee | Neznámý / proměnlivý přístup |
|
||||
| **S3 Standard-IA** | 99.9 % | milisekundy | ~$0.0125 | Méně častý přístup, ale rychlý |
|
||||
| **S3 One Zone-IA** | 99.5 % | milisekundy | ~$0.01 | Znovu vytvořitelná data |
|
||||
| **S3 Glacier Instant** | 99.9 % | milisekundy | ~$0.004 | Archiv s občasným přístupem |
|
||||
| **S3 Glacier Flexible** | 99.99 % | 1-5 min (expedite) / 3-5 h (standard) | ~$0.0036 | Dlouhodobý archiv |
|
||||
| **S3 Glacier Deep Archive** | 99.99 % | 12 h (standard) / 48 h (bulk) | ~$0.00099 | Nejlevnější, compliance archívy |
|
||||
|
||||
## Multi-AZ a Multi-Region architektura
|
||||
|
||||
```
|
||||
Region ┌──────────────────────────────┐
|
||||
│ AZ-1 AZ-2 AZ-3 │
|
||||
│ ┌───┐ ┌───┐ ┌───┐ │
|
||||
│ │APP│──────│APP│──────│APP│ │
|
||||
│ └─┬─┘ └─┬─┘ └─┬─┘ │
|
||||
│ │ │ │ │
|
||||
│ ┌─▼──────────▼──────────▼─┐ │
|
||||
│ │ Load Balancer │ │
|
||||
│ └────────────┬────────────┘ │
|
||||
│ │ │
|
||||
│ ┌────────────▼────────────┐ │
|
||||
│ │ Database (Primary) │ │
|
||||
│ │ + Read Replica │ │
|
||||
│ └─────────────────────────┘ │
|
||||
└──────────────────────────────┘
|
||||
```
|
||||
|
||||
## Cloud design patterns
|
||||
|
||||
### Strangler Fig
|
||||
Postupné nahrazování částí monolitické aplikace microservices.
|
||||
- Legacy funkcionalita se postupně přesměrovává na nové služby
|
||||
- Strangler Fig proxy (route hlavičky, feature flagy) řídí přesun trafficu
|
||||
- Výhoda: průběžné dodávání hodnoty bez big-bang přepisu
|
||||
|
||||
### Circuit Breaker
|
||||
Zabránění kaskádovým selháním při výpadku závislé služby.
|
||||
- Tři stavy: **Closed** (normální provoz), **Open** (requesty okamžitě failují), **Half-Open** (testovací request po timeoutu)
|
||||
- Parametry: failure threshold, timeout (reset timeout), half-open max requests
|
||||
- Implementace: resilience4j, Hystrix (legacy), Istio (envoy), AWS App Mesh
|
||||
|
||||
### Saga
|
||||
Distribuovaná transakce napříč microservices — řada lokálních transakcí s kompenzačními akcemi.
|
||||
- **Choreography** — každá služba publikuje událost, další služba reaguje (Kafka, EventBridge)
|
||||
- **Orchestration** — centrální orchestrátor řídí kroky (Step Functions, Temporal, Camunda)
|
||||
|
||||
### CQRS (Command Query Responsibility Segregation)
|
||||
Oddělení zápisových (Command) a čtecích (Query) modelů.
|
||||
- Command model: optimalizovaný pro zápis (normalizovaný, transactionální)
|
||||
- Query model: optimalizovaný pro čtení (denormalizovaný, read-optimized views)
|
||||
- Eventual consistency mezi modely (event bus propaguje změny)
|
||||
- Use case: reporting, audit logy, high-throughput systémy
|
||||
|
||||
### Event Sourcing
|
||||
Ukládání stavu jako sekvence událostí (eventů), ne aktuálního stavu.
|
||||
- Každá změna je append-only event v event store
|
||||
- Současný stav = fold všech událostí
|
||||
- Výhody: audit trail, time travel, CQRS kompatibilita
|
||||
- Implementace: EventStoreDB, Kafka (log), DynamoDB + CDC
|
||||
|
||||
## Hybrid cloud konektivita
|
||||
|
||||
Viz také: [NETWORKING.md](NETWORKING.md) — síťová architektura (VPN, BGP, VPC design).
|
||||
|
||||
- **Site-to-Site VPN** — IPSec tunel přes internet
|
||||
- **Direct Connect / ExpressRoute / Dedicated Interconnect** — privátní fyzické propojení
|
||||
- **Cloud VPN / Transit Gateway** — hub-and-spoke topologie
|
||||
|
||||
## Cost optimization detail
|
||||
|
||||
### Savings Plans vs Reserved Instances
|
||||
|
||||
| Vlastnost | Compute Savings Plan | EC2 Instance Savings Plan | Reserved Instances |
|
||||
|-----------|---------------------|---------------------------|-------------------|
|
||||
| Flexibilita | Instance family, region, OS | Instance family + region | Specifická instance |
|
||||
| Termín | 1 nebo 3 roky | 1 nebo 3 roky | 1 nebo 3 roky |
|
||||
| Sleva (typicky) | ~30-50 % | ~40-60 % | ~40-60 % |
|
||||
| Změna instance | Ano (libovolná) | Ano (v rámci rodiny) | Ne |
|
||||
| Změna regionu | Ano | Ne | Ne |
|
||||
| Payment options | All Upfront / Partial / No Upfront | All Upfront / Partial / No Upfront | All Upfront / Partial / No Upfront |
|
||||
|
||||
### Spot instance best practices
|
||||
|
||||
- **Diverzifikace** — používejte mix instance typů (spot fleet) pro vyšší dostupnost
|
||||
- **Graceful handling** — aplikace musí zvládnout termination notice (2 minuty varování)
|
||||
- **Checkpointing** — pravidelné ukládání stavu pro restart po spot přerušení
|
||||
- **Spot block** (AWS) — ochrana na 1-6 h (omezená dostupnost)
|
||||
- **Použití**: batch processing, CI/CD runners, stateless microservices, ML training
|
||||
- **Vyhnout se**: stateful workloads, databáze (bez speciálního designu)
|
||||
|
||||
## Organizace a governance
|
||||
|
||||
### AWS Organizations
|
||||
|
||||
```
|
||||
Root OU
|
||||
├── Security OU
|
||||
│ ├── Audit Account (CloudTrail, Config)
|
||||
│ └── Security Tooling Account (GuardDuty, Security Hub)
|
||||
├── Infrastructure OU
|
||||
│ ├── Network Account (Transit Gateway, VPN)
|
||||
│ ├── Shared Services Account (AD, SSO)
|
||||
│ └── Log Archive Account
|
||||
├── Workloads OU
|
||||
│ ├── Dev OU → jednotlivé dev accounts
|
||||
│ ├── Staging OU → staging accounts
|
||||
│ └── Prod OU → production accounts
|
||||
└── Sandbox OU → izolované experimentální účty
|
||||
```
|
||||
|
||||
- **SCP** (Service Control Policies) — whitelist/blacklist služeb na OU úrovni
|
||||
- **Tag policies** — enforcement tagování napříč účty
|
||||
- **AI services opt-out** — kontrola použití dat v AWS AI službách
|
||||
|
||||
### Azure Management Groups
|
||||
|
||||
```
|
||||
Tenant Root Group
|
||||
├── Platform MG
|
||||
│ ├── Connectivity (hub VNet, ExpressRoute)
|
||||
│ ├── Management (Log Analytics, Automation)
|
||||
│ └── Identity (AD DS, PIM)
|
||||
├── Application MG
|
||||
│ ├── DEV (dev subscriptions)
|
||||
│ ├── TEST (test subscriptions)
|
||||
│ └── PROD (production subscriptions)
|
||||
└── Sandbox MG
|
||||
```
|
||||
|
||||
- **Azure Policy** — built-in a custom policies (podobné SCP)
|
||||
- **Management Group hierarchy** — až 6 úrovní hloubky
|
||||
- **Subscription limits** — max 10 000 subscriptions na tenant
|
||||
|
||||
### GCP Projects
|
||||
|
||||
```
|
||||
Organization Node
|
||||
├── Folder: Platform
|
||||
│ ├── Project: Shared Networking (VPC, Cloud NAT, VPN)
|
||||
│ ├── Project: Security (Cloud KMS, Secret Manager, Chronicle)
|
||||
│ └── Project: Monitoring (Cloud Monitoring, Logging)
|
||||
├── Folder: Workloads
|
||||
│ ├── Folder: Dev
|
||||
│ │ └── Project: [aplikace]-dev
|
||||
│ ├── Folder: Staging
|
||||
│ │ └── Project: [aplikace]-staging
|
||||
│ └── Folder: Prod
|
||||
│ └── Project: [aplikace]-prod
|
||||
└── Folder: Sandbox
|
||||
└── Project: [user]-sandbox
|
||||
```
|
||||
|
||||
- **Organization policies** — constrainty na úrovni organizace/folderu
|
||||
- **Resource Manager** — hierarchie: Organization → Folder → Project → Resources
|
||||
- **Project limits** — max 30 projektů (lze navýšit), resources per project 10k
|
||||
|
||||
## Best practices
|
||||
|
||||
- Používejte **infrastructure as code** (Terraform, Pulumi, CDK)
|
||||
- Designujte pro **failure** — každá komponenta může spadnout
|
||||
- Implementujte **defense in depth** — security na každé vrstvě
|
||||
- Monitorujte **náklady** — taggování, budget alerts, anomaly detection
|
||||
- Používejte **managed services** kde to dává smysl (méně operací)
|
||||
- **Least privilege** pro všechny IAM role a politiky
|
||||
|
||||
## Zdroje
|
||||
|
||||
Odkazy, knihy a standardy: [sources/cloud/sources.md](sources/cloud/sources.md)
|
||||
- **Cost tagging** — assign tags pro chargeback/showback (Environment, Team, Cost Center, Application)
|
||||
- **Automated compliance** — AWS Config, Azure Policy, GCP Org Policies pro guardrails
|
||||
- **Multi-account strategie** — AWS Control Tower, Azure Landing Zones, GCP Resource Hierarchy
|
||||
204
CONNECTIVITY.md
Normal file
204
CONNECTIVITY.md
Normal file
@@ -0,0 +1,204 @@
|
||||
# 🔌 Server connectivity — síťová a storage konektivita
|
||||
|
||||
## Ethernet — síťová konektivita
|
||||
|
||||
### Rychlosti a formáty
|
||||
|
||||
| Rychlost | Označení | Form factor | Kabeláž | Rok standardu | Use case |
|
||||
|----------|----------|-------------|---------|---------------|----------|
|
||||
| **1 GbE** | 1000BASE-T | RJ45 (copper) | Cat5e/Cat6 | 1999 | Management, legacy |
|
||||
| **10 GbE** | 10GBASE-T / SFP+ | RJ45 / SFP+ | Cat6A (30m) / Cat7 (100m) / DAC / SR/LR | 2006 | Běžný server, storage |
|
||||
| **25 GbE** | 25GBASE-R | SFP28 | Cat8 (30m) / DAC (5m) / SR/LR (100m/10km) | 2016 | Standard pro servery (2020+) |
|
||||
| **40 GbE** | 40GBASE-R | QSFP+ | DAC (7m) / SR (150m) / LR (10km) | 2010 | Legacy, spine |
|
||||
| **50 GbE** | 50GBASE-R | SFP56 | DAC / SR / LR | 2018 | Emerging server |
|
||||
| **100 GbE** | 100GBASE-R | QSFP28 | DAC (3m) / SR4 (100m) / LR4 (10km) / PSM4 (500m) | 2015 | Spine, storage, AI |
|
||||
| **200 GbE** | 200GBASE-R | QSFP56 | DAC / SR4 / DR4 | 2019 | AI/ML, HPC |
|
||||
| **400 GbE** | 400GBASE-R | QSFP-DD / OSFP | DAC (2.5m) / SR8 (100m) / DR4 (500m) / FR4 (2km) | 2017 | AI training, hyperscale |
|
||||
| **800 GbE** | 800GBASE-R | QSFP-DD800 / OSFP | DAC (2m) / SR8 (100m) / DR8 (500m) | 2024 | Next-gen AI/ML |
|
||||
|
||||
**Doporučení pro servery (2026)**:
|
||||
- **Standard**: 2× 25 GbE (management + data) nebo 2× 100 GbE pro náročné workloady
|
||||
- **AI/ML training**: 8× 400 GbE (InfiniBand preferován pro GPU communication)
|
||||
- **Storage**: 2× 25/100 GbE (iSCSI/NFS) nebo dedikovaná FC (16/32 Gbps)
|
||||
|
||||
### Form factor NIC
|
||||
|
||||
| Form factor | PCIe lanes | Rychlost | Use case |
|
||||
|------------|-----------|----------|----------|
|
||||
| **OCP 3.0** | x8/x16 | 25/100/200 GbE | Moderní servery (Dell, HPE), small form factor |
|
||||
| **PCIe HHHL** | x8 | 25/50 GbE | Standardní 1U/2U servery |
|
||||
| **PCIe FHHL** | x16 | 100/200/400 GbE | GPU servery, high-density |
|
||||
| **Mezzanine** | x8 | 10/25 GbE | Blade servery (HPE Synergy, Dell MX) |
|
||||
| **LOM (LAN on Motherboard)** | — | 1/10/25 GbE | Integrovaný, základní konektivita |
|
||||
|
||||
### NIC features
|
||||
|
||||
| Feature | Popis | Benefit |
|
||||
|---------|-------|---------|
|
||||
| **TSO/GRO** | TCP Segmentation Offload / Generic Receive Offload | Snížení CPU zátěže pro TCP |
|
||||
| **LRO/LSO** | Large Receive/Send Offload | Obdoba TSO/GRO pro legacy |
|
||||
| **RSS** | Receive Side Scaling | Distribuce příchozích packetů přes více CPU jader |
|
||||
| **RPS/RFS** | Receive Packet Steering / Flow Steering | Softwarové RSS, cache affinity |
|
||||
| **XDP** | eXpress Data Path | BPF-based packet processing (DDoS, load balancer) |
|
||||
| **RDMA (RoCE v2)** | RDMA over Converged Ethernet | GPU direct communication, storage (NVMe-oF) |
|
||||
| **iWARP** | RDMA over TCP | RDMA bez speciálního switch (vyšší latence) |
|
||||
| **DPDK** | Data Plane Development Kit | Uživatelský prostor pro packet processing (VNF, vSwitch) |
|
||||
| **VXLAN/NVGRE offload** | HW offload pro tunelování | Overlay networking (VMware NSX, OpenStack) |
|
||||
| **SR-IOV** | Single Root I/O Virtualization | Direct NIC access pro VM (VF), nízká latence |
|
||||
| **Flow Bifurcation** | Split NIC traffic mezi kernel a DPDK | Souběžný management a high-speed data path |
|
||||
| **PTP (IEEE 1588)** | Precision Time Protocol | Finanční služby, 5G, telco |
|
||||
|
||||
### NIC selection per workload
|
||||
|
||||
| Workload | Doporučená NIC | Zdůvodnění |
|
||||
|----------|---------------|------------|
|
||||
| **Web / API servery** | 2× 25 GbE SFP28, OCP | Nízká cena, dostatečná bandwidth |
|
||||
| **Virtualizace (VMware)** | 2× 25 GbE (SR-IOV, VXLAN offload) | SR-IOV pro VM, VXLAN pro NSX |
|
||||
| **Databáze (OLTP)** | 2× 25/100 GbE (RSS, low latency) | Nízká latence, RSS pro CPU scaling |
|
||||
| **Storage (NFS/iSCSI)** | 2× 25/100 GbE (RoCE v2) | RDMA pro NVMe-oF, low latency |
|
||||
| **Storage (FC SAN)** | 2× 32 Gb FC HBA | SAN pro VMware VMFS, block storage |
|
||||
| **AI/ML training** | 8× 400 GbE + InfiniBand NDR | GPU communication, data ingestion |
|
||||
| **AI/ML inference** | 4× 100 GbE (RoCE v2) | Model serving, GPU direct |
|
||||
| **HPC** | InfiniBand NDR 400 Gbps | MPI communication, low latency |
|
||||
| **Telco / Edge** | 2× 25 GbE (DPDK, PTP) | VNF, 5G UPF, low latency |
|
||||
|
||||
---
|
||||
|
||||
## Storage connectivity
|
||||
|
||||
### Fibre Channel (FC) SAN
|
||||
|
||||
| Generace | Rychlost | Označení | Form factor | Dosah (SMF) | Use case |
|
||||
|----------|----------|----------|-------------|-------------|----------|
|
||||
| **Gen 5** | 16 Gbps | 16GFC | SFP+ | 10 km | Legacy SAN |
|
||||
| **Gen 6** | 32 Gbps | 32GFC | SFP28 | 10 km | Současný standard |
|
||||
| **Gen 7** | 64 Gbps | 64GFC | SFP56 | 10 km | Emerging, high-performance |
|
||||
| **Gen 8** | 128 Gbps | 128GFC | QSFP28 | 10 km | Budoucnost (2026+) |
|
||||
|
||||
**HBA (Host Bus Adapter)**:
|
||||
|
||||
| Výrobce | Model | Rychlost | PCIe | Porty | Features |
|
||||
|---------|-------|----------|------|-------|----------|
|
||||
| **Broadcom / Emulex** | LPe35000 | 32 GFC | PCIe 3.0 x8 | 1-2 | NVMe-FC, T10-PI, SR-IOV |
|
||||
| **Broadcom / Emulex** | LPe36000 | 64 GFC | PCIe 4.0 x16 | 1-2 | NVMe-FC, FC-NVMe |
|
||||
| **Marvell / QLogic** | QLE2770 | 32 GFC | PCIe 3.0 x8 | 1-2 | FC-NVMe, T10-PI |
|
||||
| **Marvell / QLogic** | QLE2870 | 64 GFC | PCIe 4.0 x8 | 1-2 | NVMe-FC, 64GFC |
|
||||
|
||||
**FC SAN topology**:
|
||||
|
||||
```
|
||||
Server ──HBA── FC Switch ──── Storage Array (FC port)
|
||||
│ │
|
||||
│ ┌────┴────┐
|
||||
│ │ Fabric │
|
||||
│ └─────────┘
|
||||
│
|
||||
──── ISL (Inter-Switch Link) ──── backup fabric (B)
|
||||
```
|
||||
|
||||
**Zoning** (FC):
|
||||
|
||||
```
|
||||
Zone A: Server1_HBA1 + Storage_Port1 (production)
|
||||
Zone B: Server1_HBA2 + Storage_Port2 (backup fabric)
|
||||
Zone C: Backup_Server + Storage_Target (backup)
|
||||
```
|
||||
|
||||
### iSCSI
|
||||
|
||||
| Vlastnost | iSCSI | Poznámka |
|
||||
|-----------|-------|----------|
|
||||
| **Transport** | TCP/IP (port 3260) | Po standardním ethernetu |
|
||||
| **Rychlost** | 1/10/25/100 GbE | Stejná jako Ethernet |
|
||||
| **Initiator** | SW (OS) nebo HW (TOE) | SW initiator zdarma, ~5-10 % CPU load |
|
||||
| **Multipathing** | MPIO (Multiple Connections per Session) | Až 8 cest, active/active nebo active/passive |
|
||||
| **CHAP** | Authentication | Mutual CHAP doporučen |
|
||||
| **Jumbo frames** | Doporučeno MTU 9000 | Snížení CPU overhead, vyšší throughput |
|
||||
| **Use case** | Malé a střední SAN, backup, DR | Levnější než FC, nižší výkon |
|
||||
|
||||
**iSCSI configuration**:
|
||||
|
||||
```
|
||||
# Software initiator (Linux)
|
||||
iscsiadm -m discovery -t sendtargets -p 10.0.0.100:3260
|
||||
iscsiadm -m node --login -T iqn.2024-05.storage:array01
|
||||
|
||||
# Multipath (dm-multipath)
|
||||
mpathconf --enable --with_multipathd y
|
||||
# /etc/multipath.conf: aliases, failback, rr_min_io
|
||||
```
|
||||
|
||||
### NVMe-oF (NVMe over Fabrics)
|
||||
|
||||
| Transport | Protokol | Latence | CPU overhead | Use case |
|
||||
|-----------|----------|---------|-------------|----------|
|
||||
| **NVMe over FC** | FC-NVMe (FC Gen 6/7) | <10 µs | Nízký | Enterprise SAN, VMware |
|
||||
| **NVMe over RDMA (RoCE v2)** | RDMA (RoCE) | <5 µs | Velmi nízký | AI/ML, HPC, K8s (CSI) |
|
||||
| **NVMe over TCP** | TCP | ~50 µs | Střední (10-20 % CPU) | Standardní Ethernet, bez RDMA |
|
||||
| **NVMe over InfiniBand** | IB RC/UC | <3 µs | Nejnižší | HPC, AI training |
|
||||
|
||||
**NVMe-oF comparison**:
|
||||
|
||||
| Vlastnost | FC-NVMe | NVMe/RoCE | NVMe/TCP | NVMe/IB |
|
||||
|-----------|---------|-----------|----------|---------|
|
||||
| **Latence (target)** | ~8 µs | ~4 µs | ~50 µs | ~3 µs |
|
||||
| **Bandwidth** | 64 Gbps | 100/200 GbE | 25/100 GbE | NDR 400 Gbps |
|
||||
| **Requires special HW** | FC HBA + switch | RoCE NIC + DCB switch | Standard NIC | IB HCA + switch |
|
||||
| **Ecosystem** | Broadcom, Marvell | NVIDIA, Broadcom | OS built-in | NVIDIA Mellanox |
|
||||
| **Use case** | VMware, enterprise SAN | AI/ML, K8s, HPC | SMB, K8s, cost-effective | HPC, large AI |
|
||||
|
||||
### SAS (Serial Attached SCSI)
|
||||
|
||||
| Generace | Rychlost | Kabeláž | Dosah | Use case |
|
||||
|----------|----------|---------|-------|----------|
|
||||
| **SAS 3** | 12 Gbps | SAS cable (SFF-8644) | 6-10 m | Legacy storage, DAS |
|
||||
| **SAS 4** | 22.5 Gbps | SAS cable (SFF-8644) | 6-10 m | Současný standard |
|
||||
| **SAS 5** | 45 Gbps | SAS cable (SFF-8644) | 6-10 m | Emerging |
|
||||
|
||||
**SAS topology**: Server → SAS HBA → SAS expander → SAS disk (point-to-point, ne shared jako FC)
|
||||
|
||||
---
|
||||
|
||||
## Server connectivity — decision matrix
|
||||
|
||||
| Workload | Primární | Sekundární | Management |
|
||||
|----------|----------|-----------|------------|
|
||||
| **Web / API** | 2× 25 GbE (LACP) | — | 1× 1 GbE BMC |
|
||||
| **Databáze** | 2× 25/100 GbE (RSS) | 2× 32 Gb FC (SAN) | 1× 1 GbE BMC |
|
||||
| **Virtualizace** | 4× 25 GbE (SR-IOV) | 2× 32 Gb FC (VMFS) | 1× 1 GbE BMC |
|
||||
| **Kubernetes** | 2× 25/100 GbE | — | 1× 1 GbE BMC |
|
||||
| **Storage node** | 2× 100 GbE (RoCE) | 2× 25 GbE (management) | 1× 1 GbE BMC |
|
||||
| **AI training** | 8× 400 GbE + IB NDR | 4× 100 GbE (storage) | 1× 1 GbE BMC |
|
||||
| **AI inference** | 4× 100 GbE (RoCE) | 2× 25 GbE (management) | 1× 1 GbE BMC |
|
||||
| **HPC** | InfiniBand NDR | 2× 100 GbE (storage) | 1× 1 GbE BMC |
|
||||
|
||||
---
|
||||
|
||||
## Server NIC placement (PCIe slot optimization)
|
||||
|
||||
```
|
||||
2U Server (GPU/AI):
|
||||
┌─────────────────────────────────────────────────┐
|
||||
│ PCIe 0: GPU (x16) — NVLink / InfiniBand (x16) │
|
||||
│ PCIe 1: GPU (x16) — NIC 100 GbE (x16) │
|
||||
│ PCIe 2: GPU (x16) │
|
||||
│ PCIe 3: GPU (x16) │
|
||||
│ PCIe 4: GPU (x16) │
|
||||
│ PCIe 5: GPU (x16) — NIC 100 GbE (x16) │
|
||||
│ PCIe 6: Storage HBA / NIC (x8) │
|
||||
│ PCIe 7: Management / OCP (x8) │
|
||||
└─────────────────────────────────────────────────┘
|
||||
|
||||
1U Standard:
|
||||
┌─────────────────────────────────┐
|
||||
│ OCP: 2× 25 GbE (management) │
|
||||
│ PCIe 0: NIC 25 GbE (x8) │
|
||||
│ PCIe 1: Storage HBA / FC (x8) │
|
||||
│ PCIe 2: GPU (x16, optional) │
|
||||
│ PCIe 3: NVMe (x4, M.2) │
|
||||
└─────────────────────────────────┘
|
||||
```
|
||||
|
||||
## Zdroje
|
||||
|
||||
Odkazy, knihy a standardy: [sources/infrastructure/sources.md](sources/infrastructure/sources.md)
|
||||
394
DATABASES.md
Normal file
394
DATABASES.md
Normal file
@@ -0,0 +1,394 @@
|
||||
# 🗄️ Databázová architektura
|
||||
|
||||
## Klasifikace databází
|
||||
|
||||
### Relační (SQL)
|
||||
|
||||
| DB | Licence | Use case |
|
||||
|----|---------|----------|
|
||||
| PostgreSQL | Open source | Univerzální, geospatial, analytika |
|
||||
| MySQL | Open source | Web, LAMP stack |
|
||||
| MariaDB | Open source | MySQL kompatibilní |
|
||||
| Microsoft SQL Server | Proprietary | Enterprise .NET |
|
||||
| Oracle DB | Proprietary | Enterprise |
|
||||
| Amazon Aurora | Managed | MySQL/PostgreSQL kompatibilní |
|
||||
|
||||
### NoSQL
|
||||
|
||||
| Typ | DB | Use case |
|
||||
|-----|----|----------|
|
||||
| Document | MongoDB, Couchbase | JSON data, flexibilní schema |
|
||||
| Key-Value | Redis, DynamoDB | Cache, session store, real-time |
|
||||
| Wide-column | Cassandra, ScyllaDB | Time-series, IoT, velká data |
|
||||
| Graph | Neo4j, Dgraph | Vztahy, doporučení, social grafy |
|
||||
|
||||
## Transaction isolation levels
|
||||
|
||||
| Úroveň | Dirty Read | Non-repeatable Read | Phantom Read | Serialization Anomaly |
|
||||
|--------|-----------|---------------------|-------------|----------------------|
|
||||
| **Read Uncommitted** | Ano (možné) | Ano | Ano | Ano |
|
||||
| **Read Committed** | Ne (prevence) | Ano | Ano | Ano |
|
||||
| **Repeatable Read** | Ne | Ne | Ano (PostgreSQL: Ne) | Ano |
|
||||
| **Serializable** | Ne | Ne | Ne | Ne |
|
||||
|
||||
**Anomálie**:
|
||||
- **Dirty Read** — čtení dat z necommitnuté transakce (data mohou být rollbacknuta)
|
||||
- **Non-repeatable Read** — stejný dotaz vrátí jiná data (jiná transakce mezitím updatovala řádek)
|
||||
- **Phantom Read** — stejný dotaz vrátí nové řádky (jiná transakce insertla data splňující podmínku)
|
||||
- **Serialization Anomaly** — výsledek transakcí není ekvivalentní žádnému sériovému pořadí
|
||||
|
||||
### PostgreSQL specific
|
||||
- **Read Uncommitted** se chová jako **Read Committed** (není implementováno)
|
||||
- **Repeatable Read** v PG je **Snapshot Isolation** — zabraňuje i phantom reads
|
||||
- **Serializable** v PG používá Serializable Snapshot Isolation (SSI) — detekce sériových konfliktů
|
||||
|
||||
## PostgreSQL detail
|
||||
|
||||
### MVCC (Multi-Version Concurrency Control)
|
||||
|
||||
- Každá transakce vidí snapshot dat (transaction snapshot) z okamžiku startu
|
||||
- Staré verze řádků (tuple) zůstávají v tabulce, označené jako `xmax` / `xmin`
|
||||
- INSERT vytvoří nový tuple s `xmin = current_xid`
|
||||
- DELETE označí tuple `xmax = current_xid` (nezmizí hned)
|
||||
- UPDATE = DELETE old + INSERT new
|
||||
- VACUUM fyzicky maže tuple starší než nejstarší aktivní snapshot
|
||||
|
||||
### VACUUM a autovacuum
|
||||
|
||||
| Parametr | Popis | Výchozí |
|
||||
|----------|-------|---------|
|
||||
| `autovacuum_vacuum_threshold` | Min. mrtvých řádků pro spuštění | 50 |
|
||||
| `autovacuum_vacuum_scale_factor` | % z tabulky jako threshold | 0.2 (20 %) |
|
||||
| `autovacuum_analyze_threshold` | Min. změněných řádků pro ANALYZE | 50 |
|
||||
| `autovacuum_vacuum_cost_limit` | Limituje I/O vacuum (prevence zátěže) | 200 |
|
||||
| `autovacuum_naptime` | Interval mezi kontrolami | 1 min |
|
||||
| `deadlock_timeout` | Detekce deadlocků | 1 s |
|
||||
|
||||
**Příznaky nedostatečného vacuum**:
|
||||
- Růst tabulky (bloat) — staré tuple zabírají místo
|
||||
- Zhoršení výkonu index scanů (VISIBLE MAP není aktuální)
|
||||
- XID wraparound hazard — emergency vacuum (může zastavit DB)
|
||||
|
||||
### WAL archiving a PITR
|
||||
|
||||
```conf
|
||||
# postgresql.conf
|
||||
wal_level = replica # nebo logical
|
||||
archive_mode = on
|
||||
archive_command = 'aws s3 cp %p s3://backups/pg-wal/%f'
|
||||
```
|
||||
|
||||
- **WAL** (Write-Ahead Log) — append-only log všech změn
|
||||
- **WAL archiving** — kontinuální záloha WAL segmentů (16 MB)
|
||||
- **PITR** (Point-In-Time Recovery) — obnova k libovolnému okamžiku
|
||||
1. Restore base backup (pg_basebackup)
|
||||
2. Replay WAL archivů až k cílovému času
|
||||
3. `recovery_target_time = '2026-06-03 10:30:00 UTC'`
|
||||
|
||||
### Replication slots
|
||||
|
||||
- **Physical replication slot** — zaručuje, že WAL není smazán masterem, dokud ho replica nespotřebuje
|
||||
- **Logical replication slot** — pro logickou replikaci (selectivní tabulky, transformace dat)
|
||||
- **Riziko**: pokud replica spadne a slot není aktivní, WAL naroste na disku (disk full)
|
||||
- Monitoring: `pg_replication_slots`, `pg_stat_replication`
|
||||
|
||||
## Replikace
|
||||
|
||||
| Typ | Popis | Latence |
|
||||
|-----|-------|---------|
|
||||
| Synchronní | Zápis potvrzen až po replikaci na všechny nod | Vysoká, ale konzistentní |
|
||||
| Asynchronní | Zápis potvrzen ihned, replikace na pozadí | Nízká, možný data loss |
|
||||
| Semi-synchronní | Potvrzení od majority nodů | Kompromis |
|
||||
|
||||
### Topologie
|
||||
|
||||
- **Leader-Follower** (Master-Slave) — čtení z replic
|
||||
- **Leader-Leader** (Multi-master) — zápis na více nodů
|
||||
- **Quorum-based** — R + W > N (Cassandra, DynamoDB)
|
||||
|
||||
## Index types
|
||||
|
||||
| Typ | Algoritmus | Use case | Operace | Poznámka |
|
||||
|-----|-----------|----------|---------|----------|
|
||||
| **B-tree** | Balanced tree | Většina dotazů — =, <, >, BETWEEN, IN, LIKE (prefix) | Rychlé vyhledávání, řazení | Výchozí v PostgreSQL, MySQL |
|
||||
| **Hash** | Hash table | Pouze = (equality) | Rychlé lookup | Malá velikost, nelze range dotazy |
|
||||
| **GiST** | Generalized Search Tree | Full-text, geometrie, intervaly, IP rozsahy | Rychlé: overlaps, contains, distance | GIST pro geometrii (PostGIS), full-text |
|
||||
| **GIN** (Generalized Inverted Index) | Inverted index | Pole, JSONB, full-text search | contains (@>), overlaps (&&) | Pomalý build, rychlé čtení |
|
||||
| **BRIN** (Block Range Index) | Min/Max per block range | Velké tabulky, data v pořadí (time-series) | Range dotazy na korelovaná data | Extrémně malý (tisíckrát menší než B-tree) |
|
||||
| **SP-GiST** | Space-partitioned GiST | Quad-tree, KD-tree, radix tree | Partitioned search | Geografické clustery, síťová data |
|
||||
|
||||
## Index selection guide
|
||||
|
||||
| Query pattern | Doporučený index | Příklad |
|
||||
|--------------|-----------------|---------|
|
||||
| `WHERE user_id = 123` | B-tree na `user_id` | Uživatelský lookup |
|
||||
| `WHERE status = 'active' AND created_at > '2026-01-01'` | Composite B-tree na `(status, created_at)` | Filtrace + range |
|
||||
| `WHERE data @> '{"key": "value"}'` | GIN na JSONB sloupec | JSONB dotazy |
|
||||
| `WHERE tags && ARRAY['urgent']` | GIN na pole | Tagy |
|
||||
| `WHERE position <@> POINT(50, 14) < 1000` | GiST na geometry | Lokalitní dotazy |
|
||||
| `WHERE event_time BETWEEN '2026-06-01' AND '2026-06-02'` | BRIN na `event_time` | Time-series, logy |
|
||||
| `WHERE email = 'user@example.com'` | Hash na `email` | Equality only |
|
||||
|
||||
## Query execution
|
||||
|
||||
### Seq scan vs Index scan vs Bitmap scan
|
||||
|
||||
| Typ | Popis | Kdy se používá |
|
||||
|-----|-------|---------------|
|
||||
| **Seq Scan** | Prochází všechny řádky tabulky | Velká část tabulky (>10 %), malá tabulka, žádný vhodný index |
|
||||
| **Index Scan** | Hledá v indexu, pak náhodný přístup k heap | Malá podmnožina dat (<5 %), selektivní dotazy |
|
||||
| **Index Only Scan** | Načítá data pouze z indexu (ne z heap) | Všechny potřebné sloupce jsou v indexu (covering index) |
|
||||
| **Bitmap Scan** | Kombinace více indexů → bitmapa → heap access | AND/OR podmínky na více indexovaných sloupcích |
|
||||
| **Bitmap Heap Scan** | Načítá řádky z bitmapy (srovnané) | AND/OR kombinace, ~5-20 % tabulky |
|
||||
|
||||
### EXPLAIN ANALYZE
|
||||
|
||||
```sql
|
||||
EXPLAIN (ANALYZE, BUFFERS, FORMAT JSON)
|
||||
SELECT * FROM orders WHERE user_id = 456 AND created_at > '2026-01-01';
|
||||
|
||||
-- Výstup:
|
||||
-- Index Scan using idx_orders_user_created on orders
|
||||
-- Index Cond: ((user_id = 456) AND (created_at > '2026-01-01'::date))
|
||||
-- Buffers: shared hit=3
|
||||
-- Planning Time: 0.12 ms
|
||||
-- Execution Time: 0.34 ms
|
||||
```
|
||||
|
||||
Klíčové metriky: `Execution Time`, `Planning Time`, `Buffers` (hit/read/dirtied), `Rows Removed by Filter`, `Actual Time` (first...last)
|
||||
|
||||
## Sharding
|
||||
|
||||
Distribuce dat napříč uzly podle shard klíče.
|
||||
|
||||
```
|
||||
┌─────────┐
|
||||
│ Proxy │
|
||||
│ Router │
|
||||
└────┬────┘
|
||||
┌──────────┼──────────┐
|
||||
┌────▼───┐ ┌───▼────┐ ┌───▼────┐
|
||||
│Shard A │ │Shard B │ │Shard C │
|
||||
│ 0-100 │ │101-200 │ │201-300 │
|
||||
└────────┘ └────────┘ └────────┘
|
||||
```
|
||||
|
||||
### Hash-based sharding
|
||||
|
||||
```
|
||||
shard_id = hash(shard_key) % number_of_shards
|
||||
```
|
||||
|
||||
### Range-based sharding
|
||||
|
||||
- Data rozdělena podle rozsahu hodnot (např. uživatelé A-M, N-Z)
|
||||
- Může vést k nerovnoměrnému rozdělení (hot spots)
|
||||
|
||||
### Consistent hashing
|
||||
|
||||
```
|
||||
Hash ring:
|
||||
0 ─── shard A ─── hash(key1)
|
||||
│
|
||||
90 ─── shard B ─── hash(key2)
|
||||
│
|
||||
180 ─── shard C ─── hash(key3)
|
||||
│
|
||||
270 ─── shard D ─── hash(key4)
|
||||
```
|
||||
|
||||
- Minimalizuje přeuspořádání přidáním/odebráním nodu (pouze sousední shard)
|
||||
- **Virtual nodes** (vnodes) — každý fyzický nod má více virtuálních bodů na ring (lepší distribuce)
|
||||
- **Koordinační služba**: Cassandra (vnodes), Riak (vnodes), DynamoDB (Consistent Hashing)
|
||||
|
||||
### Rebalancing
|
||||
|
||||
- **Ruční** — zastavit zápisy, přerozdělit data, restartovat
|
||||
- **Automatické** — incremental migration (Cassandra vnodes)
|
||||
- **Proxy-based** — Vitess (shard splitting), Citus (shard rebalancing)
|
||||
|
||||
### Routing approaches
|
||||
|
||||
- **Proxy-based** — aplikace jde na proxy, ta routuje (Vitess, ProxySQL)
|
||||
- **Client-side** — aplikace ví, na který shard jít
|
||||
- **DNS-based** — každý shard má vlastní endpoint
|
||||
|
||||
## CAP teorém
|
||||
|
||||
V distribuovaném systému lze mít pouze 2 ze 3:
|
||||
|
||||
- **C**onsistency — všichni vidí stejná data
|
||||
- **A**vailability — každý request dostane odpověď
|
||||
- **P**artition tolerance — systém funguje i přes výpadek komunikace
|
||||
|
||||
V praxi: P je vždy vyžadováno, volíme mezi CP (konzistence) a AP (dostupnost).
|
||||
|
||||
### PACELC rozšíření
|
||||
|
||||
PACELC rozšiřuje CAP o chování za normálních podmínek (bez partition):
|
||||
|
||||
- **P**artition → **A**vailability vs **C**onsistency
|
||||
- **E**lse (bez partition) → **L**atency vs **C**onsistency
|
||||
|
||||
| DB | Partition volba | Else volba |
|
||||
|----|----------------|------------|
|
||||
| Cassandra | AP (dostupnost) | LC (nízká latence, eventual consistency) |
|
||||
| DynamoDB (default) | AP | LC |
|
||||
| MongoDB | CP (primární) | LC |
|
||||
| PostgreSQL (single) | CP | CC |
|
||||
| CockroachDB | CP | CC |
|
||||
|
||||
### Quorum detail
|
||||
|
||||
- **R** (read quorum) + **W** (write quorum) > **N** (replication factor)
|
||||
- Typické: N=3, R=2, W=2 (toleruje 1 node down)
|
||||
- **Sloppy quorum** — při nedostupnosti nodu, data dočasně uložena na jiném nodu (nastolit konzistenci po obnově)
|
||||
- **Hinted handoff** — dočasný zápis na jiný node s hintem, při obnově se data přenesou
|
||||
|
||||
## Caching
|
||||
|
||||
| Vrstva | Nástroj | Use case |
|
||||
|--------|---------|----------|
|
||||
| Application cache | Redis, Memcached | Session, API response cache |
|
||||
| Database cache | Built-in | Query cache, buffer pool |
|
||||
| CDN cache | CloudFront, Fastly | Static assets, API responses |
|
||||
| HTTP cache | Varnish, nginx | Reverse proxy cache, ESI |
|
||||
|
||||
### Cache strategie
|
||||
|
||||
| Strategie | Popis | Use case |
|
||||
|-----------|-------|----------|
|
||||
| **Cache-aside** | Aplikace načte z cache, při miss jde do DB a naplní cache | Obecná |
|
||||
| **Read-through** | Cache sama načte z DB při miss | Jednoduché lookupy |
|
||||
| **Write-through** | Zápis jde do cache i DB zároveň | Konzistence |
|
||||
| **Write-behind** | Zápis do cache okamžitě, do DB asynchronně | Propustnost |
|
||||
| **Cache-aside (lazy loading)** | TTL + invalidace | Nejčastější |
|
||||
|
||||
### Redis detail
|
||||
|
||||
**Data structures**:
|
||||
|
||||
| Struktura | Popis | Use case |
|
||||
|-----------|-------|----------|
|
||||
| **String** | Binární string (max 512 MB) | Cache hodnoty, session tokeny, counters |
|
||||
| **Hash** | Map field-value | Uživatelský profil, objekt v cache |
|
||||
| **List** | Linked list (push/pop na oba konce) | Queue (RPUSH/LPOP), log stream |
|
||||
| **Set** | Unikátní hodnoty (unordered) | Tags, deduplikace, memberships |
|
||||
| **Sorted Set** | Unikátní + score (řazení) | Leaderboardy, rate limiting, timeouts |
|
||||
| **Bitmap** | Bitové pole | Feature flagy, daily active users |
|
||||
| **HyperLogLog** | Approximate cardinality (12 KB = 2^64) | Unikátní návštěvníci (error < 1%) |
|
||||
| **Stream** | Append-only log (Kafka-like) | Event store, messaging |
|
||||
|
||||
**Eviction policies**:
|
||||
|
||||
| Policy | Popis | Use case |
|
||||
|--------|-------|----------|
|
||||
| **noeviction** | Chyba při zápisu když je plno | Transakční data, neztrácet |
|
||||
| **allkeys-lru** | LRU na všechny klíče | Obecná cache, standard |
|
||||
| **allkeys-lfu** | LFU na všechny klíče | Často přistupovaná data |
|
||||
| **volatile-lru** | LRU na klíče s TTL | Cache s expirací |
|
||||
| **volatile-ttl** | Nejblíž k expiraci | Krátkodobá data |
|
||||
| **allkeys-random** | Náhodný | Testování |
|
||||
|
||||
**Redis Cluster vs Sentinel**:
|
||||
|
||||
| Vlastnost | Redis Sentinel | Redis Cluster |
|
||||
|-----------|---------------|---------------|
|
||||
| **Škálování** | Read replicas (master + replica) | Data sharding (16384 hash slotů) |
|
||||
| **Auto-failover** | Ano (Sentinel) | Ano (gossip-based) |
|
||||
| **Multi-key ops** | Ano (transactiony na masteru) | Omezené (stejný hash slot) |
|
||||
| **Client komunikace** | Přes Sentinel (deprecated) | Cluster nodes redirect (MOVED/ASK) |
|
||||
| **Minimální uzly** | Master + Replica + 3 Sentinel | 3 masters (každý s replikou) |
|
||||
| **Use case** | Vysoká dostupnost, single shard | Multi-shard, horizontální škálování |
|
||||
|
||||
### Connection pooling
|
||||
|
||||
| Pooler | DB | Typ | Protokol |
|
||||
|--------|-----|-----|----------|
|
||||
| **PgBouncer** | PostgreSQL | Proxy (transaction/session) | PostgreSQL wire |
|
||||
| **RDS Proxy** | PostgreSQL, MySQL | Managed proxy | AWS |
|
||||
| **ProxySQL** | MySQL | Proxy (advanced routing) | MySQL wire |
|
||||
| **Odyssey** | PostgreSQL | Proxy (multithreaded) | PostgreSQL wire |
|
||||
| **pgpool-II** | PostgreSQL | Proxy (replication, load balancing) | PostgreSQL wire |
|
||||
|
||||
**PgBouncer režimy**:
|
||||
- **Session pooling** — spojení drženo po celou dobu session (aplikace) → overhead
|
||||
- **Transaction pooling** — spojení vráceno po dokončení transakce → efektivnější (vyžaduje bezstavovost)
|
||||
|
||||
## Migrace dat
|
||||
|
||||
### Schéma migrace (PostgreSQL / MySQL)
|
||||
|
||||
```
|
||||
V1__initial_schema.sql
|
||||
V2__add_users_table.sql
|
||||
V3__add_email_index.sql
|
||||
V4__add_orders_table.sql
|
||||
```
|
||||
|
||||
### Zero-downtime migrace
|
||||
|
||||
1. **Expand** — přidání nového sloupce/tabulky (aplikace toleruje oba stavy)
|
||||
2. **Migrate** — backfill dat, update aplikace na nové schema
|
||||
3. **Contract** — odstranění starého sloupce/tabulky
|
||||
|
||||
### Nástroje detail
|
||||
|
||||
| Nástroj | Jazyk | Strategie | Zero-downtime | Rollback |
|
||||
|---------|-------|-----------|--------------|----------|
|
||||
| **Flyway** | Java (multi-lang CLI) | Versioned SQL | Omezeně (jen additive) | `undo` (limited, enterprise) |
|
||||
| **Liquibase** | Java (multi-lang CLI) | Changesets (XML/YAML/JSON/SQL) | Ano (changeset design) | `rollback <count>` |
|
||||
| **Alembic** | Python | Auto-generation, versioned | Ano (branching) | `downgrade` |
|
||||
| **Prisma Migrate** | TypeScript | Declarative schema → diff | Ano (shadow DB) | `migrate diff` |
|
||||
| **gh-ost** | Go | Triggerless online DDL (MySQL) | Ano (binlog stream) | Ne (progresivní) |
|
||||
| **pgroll** | Go | Online schema migrace (PG) | Ano (views, multiple versions) | Ano (okamžitý) |
|
||||
|
||||
## Data consistency patterns
|
||||
|
||||
| Pattern | Popis | Příklad |
|
||||
|---------|-------|---------|
|
||||
| **Strong consistency** | Po zápisu každý read vidí nejnovější data | Single DB, Raft, Spanner |
|
||||
| **Eventual consistency** | Po zápisu se data časem propagují | DNS, DynamoDB (default), Cassandra |
|
||||
| **Read-after-write** | Autor svůj zápis vždy vidí (ostatní eventual) | Sociální sítě, komentáře |
|
||||
| **Causal consistency** | Kauzálně závislé operace viděny ve správném pořadí | COPS, Orbe, MongoDB (causal clusters) |
|
||||
| **Monotonic reads** | Nevidíte starší data po tom, co jste viděli novější | Cassandra (MONOTONIC_READ consistency) |
|
||||
| **Monotonic writes** | Zápisy od jednoho clienta v pořadí | Queue-based, single leader |
|
||||
|
||||
## Storage engines — přehled
|
||||
|
||||
### B-Tree vs LSM-Tree
|
||||
|
||||
| Vlastnost | B-Tree | LSM-Tree |
|
||||
|-----------|--------|----------|
|
||||
| Zápis | In-place update (náhodný I/O) | Append-only (sekvenční I/O) |
|
||||
| Čtení | Rychlé (přímo v page) | Pomalejší (merge z více SSTable) |
|
||||
| Kompaktnost | Horší (page fragmentation) | Lepší (kompaktní SSTable) |
|
||||
| Write amplification | Nižší | Vyšší (kompakce) |
|
||||
| Read amplification | Nižší | Vyšší (bloom filtry pomáhají) |
|
||||
| Typické DB | PostgreSQL, MySQL (InnoDB) | Cassandra, RocksDB, LevelDB |
|
||||
|
||||
### Write-Ahead Log (WAL)
|
||||
|
||||
- Append-only log pro crash recovery
|
||||
- Každá změna se zapíše do WAL před aplikací na data page
|
||||
- Checkpoint = bod, od kterého je WAL při recovery potřeba
|
||||
|
||||
### MVCC (Multi-Version Concurrency Control)
|
||||
|
||||
- Každá transakce vidí snapshot dat v okamžiku startu
|
||||
- Staré verze řádků zůstávají v tabulce (vacuum/GC)
|
||||
- Izolační úrovně: Read Committed, Repeatable Read, Serializable
|
||||
|
||||
## Best practices
|
||||
|
||||
- **Connection pooling** — PgBouncer, RDS Proxy, ProxySQL
|
||||
- **Indexování podle query patternů** — nemít zbytečné indexy
|
||||
- **Read replicas** pro reporting a analytiku
|
||||
- **Backup & recovery** — point-in-time recovery (PITR), pravidelné testy
|
||||
- **Query monitoring** — slow query log, pg_stat_statements, performance_schema
|
||||
- **Encryption at rest & in transit**
|
||||
- **Migrace v CI/CD** — součást pipeline, ne manuálně
|
||||
|
||||
## Zdroje
|
||||
|
||||
Odkazy, knihy a standardy: [sources/databases/sources.md](sources/databases/sources.md)
|
||||
155
DATACENTERS.md
Normal file
155
DATACENTERS.md
Normal file
@@ -0,0 +1,155 @@
|
||||
# 🏭 Datová centra
|
||||
|
||||
## Tier klasifikace (TIA-942 / Uptime Institute)
|
||||
|
||||
| Tier | Dostupnost | Downtime / rok | Redundance |
|
||||
|------|-----------|----------------|------------|
|
||||
| **Tier I** | 99.671 % | 28.8 h | N — bez redundance |
|
||||
| **Tier II** | 99.741 % | 22.7 h | N+1 — redundantní komponenty |
|
||||
| **Tier III** | 99.982 % | 1.6 h | N+1 — současně udržovatelné |
|
||||
| **Tier IV** | 99.995 % | 26.3 min | 2N+1 — fault tolerant |
|
||||
|
||||
## Klíčové subsystémy
|
||||
|
||||
| Systém | Popis |
|
||||
|--------|-------|
|
||||
| **Power** | UPS, generátory (diesel), ATS, PDU, redundantní přívody (A/B feed) |
|
||||
| **Cooling** | CRAC/CRAH, chilled water, free cooling, containment (hot/cold aisle) |
|
||||
| **Fyzická bezpečnost** | Kamerový systém, biometric access, mantrap, bezpečnostní zámky racků |
|
||||
| **Cabling** | Structured cabling (Cat6A/7/8, OM3/OM4 single-mode fiber), patch panely |
|
||||
| **Fire suppression** | Poplach, inertní plyny (Novec, FM-200), VESDA (very early smoke detection) |
|
||||
| **Monitoring** | DCIM (Data Center Infrastructure Management), SNMP, BMS (Building Management System) |
|
||||
|
||||
## Aisle containment
|
||||
|
||||
```
|
||||
┌────────────────────────────────────┐
|
||||
│ Rack Row │
|
||||
│ ┌──┐ ┌──┐ ┌──┐ ┌──┐ ┌──┐ ┌──┐ │
|
||||
Cold │ │ │ │ │ │ │ │ │ │ │ │ │ │ Cold
|
||||
Aisle <──│ └──┘ └──┘ └──┘ └──┘ └──┘ └──┘ ──> Aisle
|
||||
│ ┌──┐ ┌──┐ ┌──┐ ┌──┐ ┌──┐ ┌──┐ │
|
||||
Hot │ │ │ │ │ │ │ │ │ │ │ │ │ │ Hot
|
||||
Aisle ──>│ └──┘ └──┘ └──┘ └──┘ └──┘ └──┘ <── Aisle
|
||||
└────────────────────────────────────┘
|
||||
```
|
||||
|
||||
## Environmental třídy (ASHRAE TC 9.9)
|
||||
|
||||
ASHRAE Technical Committee 9.9 definuje teplotní a vlhkostní obálky pro IT zařízení v DC.
|
||||
|
||||
| Třída | Teplota (doporučeno) | Teplota (allowable) | Použití |
|
||||
|-------|---------------------|---------------------|---------|
|
||||
| **A1** | 18-27 °C | 15-32 °C | Enterprise DC, přísná kontrola |
|
||||
| **A2** | 18-27 °C | 10-35 °C | Běžné DC |
|
||||
| **A3** | 18-27 °C | 5-40 °C | Volnější prostředí |
|
||||
| **A4** | 18-27 °C | 5-45 °C | Maximální úspora chlazení |
|
||||
| **H1** | 18-22 °C | 5-25 °C | High-density air-cooled (AI/ML) |
|
||||
|
||||
- 5. edice (2021) přidala třídu H1 pro high-density a rozšířila liquid cooling W-třídy (W17, W27, W32, W40, W45, W+)
|
||||
- 2024: nové S-třídy pro Technology Cooling System (TCS) chlazení kapalinou
|
||||
- Vlhkost: doporučeno −9 °C DP až 70 % RH (při nízkých polutantech); max 50 % RH při vysoké korozivitě
|
||||
|
||||
## Power
|
||||
|
||||
### Power chain
|
||||
|
||||
```
|
||||
Grid ──> UPS ──> PDU ──> Rack PDU ──> Server PSU
|
||||
│
|
||||
└──> Generator (ATS přepíná při výpadku)
|
||||
```
|
||||
|
||||
### Power calculation
|
||||
|
||||
```
|
||||
Total Power = Σ(P_server + P_storage + P_network + P_cooling + P_losses)
|
||||
|
||||
P_server = P_idle + (P_max - P_idle) × Utilization%
|
||||
P_cooling = P_IT / PUE
|
||||
|
||||
Příklad:
|
||||
100 serverů × 500 W (avg) = 50 kW IT load
|
||||
PUE = 1.5 → celkem 75 kW
|
||||
UPS + generátor → dimenzováno na 75 kW × 1.2 (safety factor) = 90 kW
|
||||
```
|
||||
|
||||
### PUE (Power Usage Effectiveness)
|
||||
|
||||
```
|
||||
PUE = Total Facility Energy / IT Equipment Energy
|
||||
```
|
||||
|
||||
| PUE | Efektivita | Typ |
|
||||
|-----|-----------|-----|
|
||||
| 1.0-1.1 | Vynikající | Hyperscale (Google, Meta) |
|
||||
| 1.1-1.3 | Velmi dobrý | Moderní DC |
|
||||
| 1.3-1.6 | Dobrý / průměr | Enterprise DC |
|
||||
| 1.6-2.0 | Podprůměr | Starší DC |
|
||||
| >2.0 | Špatný | Legacy |
|
||||
|
||||
### 3-phase vs Single-phase
|
||||
|
||||
| Vlastnost | Single-phase (230 V) | 3-phase (400 V) |
|
||||
|-----------|---------------------|-----------------|
|
||||
| **Napětí** | 230 V (L-N) | 230/400 V (L-N/L-L) |
|
||||
| **Výkon per feed** | ~7.4 kW (32 A) | ~22 kW (32 A, 3-f) |
|
||||
| **Efektivita** | Nižší (více ztrát) | Vyšší (nižší proud) |
|
||||
| **Use case** | Menší racky, office | Standard v DC, high-density |
|
||||
| **PDU** | Single-phase (C13/C19) | 3-phase (C13/C19, 3-f monitoring) |
|
||||
|
||||
### Rack power density
|
||||
|
||||
| Kat. | Typ | kW/rack | Cooling |
|
||||
|------|-----|---------|---------|
|
||||
| Nízká | Office, storage | 1-3 kW | Air (free cooling) |
|
||||
| Střední | Standard compute | 5-10 kW | Air (CRAC/CRAH) |
|
||||
| Vysoká | GPU, HPC | 15-30 kW | Air + liquid assist |
|
||||
| Ultra | AI/ML clusters | 40-100+ kW | Direct-to-chip / immersion |
|
||||
|
||||
## Cooling
|
||||
|
||||
### Chilled water vs Direct Expansion (DX)
|
||||
|
||||
| Vlastnost | Chilled water (CW) | Direct Expansion (DX) |
|
||||
|-----------|-------------------|----------------------|
|
||||
| **Medium** | Voda + glycol | Freon (R134a, R410A) |
|
||||
| **CRAC/CRAH** | CRAH (Coolant-based) | CRAC (refrigerant compressor) |
|
||||
| **Efektivita** | Vyšší (COP 5-7) | Nižší (COP 2-4) |
|
||||
| **Komplexita** | Vyšší (chillers, pumps, pipes) | Jednodušší |
|
||||
| **Use case** | Velké DC, enterprise | Menší DC, edge, retrofit |
|
||||
|
||||
### Free cooling
|
||||
|
||||
- **Air-side** — nasávání venkovního vzduchu při vhodné teplotě (filtrace, humidifikace)
|
||||
- **Water-side** — využití chladné vody z venkovních chillerů (strainer cycle)
|
||||
- **Klimatické pásmo** — free cooling využitelný ~2000-8000 hodin/rok podle lokality
|
||||
- **Hybrid** — kombinace free cooling + mechanical cooling
|
||||
|
||||
### Liquid cooling
|
||||
|
||||
| Typ | Popis | Use case |
|
||||
|-----|-------|----------|
|
||||
| **Direct-to-chip (cold plate)** | Kapalina na chladiči CPU/GPU, voda nebo dielektrikum | AI/ML, HPC, GPU clustery |
|
||||
| **Immersion cooling** | Server ponořen v dielektrické kapalině (single-phase/two-phase) | High-density, bitcoin mining |
|
||||
| **Rear-door heat exchanger** | Chladič na zadních dveřích racku (voda) | Retrofity, medium-density |
|
||||
| **Coolant Distribution Unit (CDU)** | Distribuce chladiva mezi racky, monitoring teploty | Standard pro liquid cooling |
|
||||
|
||||
## Monitoring disků — S.M.A.R.T.
|
||||
|
||||
Self-Monitoring, Analysis and Reporting Technology — prediktivní monitoring HDD/SSD.
|
||||
|
||||
| Klíčový atribut | ID | Popis |
|
||||
|----------------|----|-------|
|
||||
| Reallocated Sectors Count | 5 | Počet přemapovaných sektorů (nárůst = konec disku) |
|
||||
| Power-On Hours | 9 | Celková doba provozu v hodinách |
|
||||
| Reported Uncorrectable Errors | 187 | Nekorigovatelné chyby (červená kontrolka) |
|
||||
| CRC Error Count | 199 | Chyby na SATA lince (kabel/controller) |
|
||||
| SSD Life Left | 231 | % zbývající životnosti SSD |
|
||||
| Media Wearout Indicator | 233 | Celkový zápis do NAND |
|
||||
|
||||
Nástroje: `smartmontools` (smartctl, smartd), Prometheus exporter (`node_exporter`), OTeL collector.
|
||||
|
||||
## Zdroje
|
||||
|
||||
Odkazy, knihy a standardy: [sources/infrastructure/sources.md](sources/infrastructure/sources.md)
|
||||
126
GPU.md
Normal file
126
GPU.md
Normal file
@@ -0,0 +1,126 @@
|
||||
# 🎮 GPU — architektura, modely, virtualizace
|
||||
|
||||
## GPU modely
|
||||
|
||||
### NVIDIA
|
||||
|
||||
| GPU | Architektura | VRAM | HBM | FP16 (TFLOPS) | FP8 (TFLOPS) | Interconnect | TDP |
|
||||
|-----|-------------|------|-----|--------------|-------------|-------------|-----|
|
||||
| **A100** | Ampere (2020) | 40/80 GB | HBM2e | 312 | — | NVLink 3 (600 GB/s) | 400 W |
|
||||
| **H100** | Hopper (2022) | 80 GB | HBM3 | 1000 | 2000 (sparse) | NVLink 4 (900 GB/s) | 700 W |
|
||||
| **H200** | Hopper (2023) | 141 GB | HBM3e | 1650 | ~3300 | NVLink 4 (900 GB/s) | 700 W |
|
||||
| **B200** | Blackwell (2024) | 192 GB | HBM3e | 2250 | ~4500 | NVLink 5 (1800 GB/s) | 700 W |
|
||||
| **B100** | Blackwell (2024) | 192 GB | HBM3e | ~1800 | ~3600 | NVLink 5 | 700 W |
|
||||
| **GB200** | Blackwell (2024) | — | HBM3e | 4500 (dual) | 9000 (dual) | NVLink 5 | 2700 W |
|
||||
|
||||
### AMD
|
||||
|
||||
| GPU | Architektura | VRAM | HBM | FP16 (TFLOPS) | Interconnect | TDP |
|
||||
|-----|-------------|------|-----|--------------|-------------|-----|
|
||||
| **MI250X** | CDNA 2 (2021) | 128 GB | HBM2e | 383 | Infinity Fabric | 500 W |
|
||||
| **MI300X** | CDNA 3 (2023) | 192 GB | HBM3 | ~2600 | Infinity Fabric (896 GB/s) | 750 W |
|
||||
| **MI350** | CDNA 4 (2025) | 288 GB | HBM3e | ~3500 | Infinity Fabric | 750 W |
|
||||
|
||||
## GPU interconnects
|
||||
|
||||
| Technologie | Poskytovatel | Bandwidth | Topologie | Use case |
|
||||
|------------|-------------|-----------|-----------|----------|
|
||||
| **NVLink 4** | NVIDIA | 900 GB/s (18× 50 GB/s) | GPU-GPU direct | AI training (H100, H200) |
|
||||
| **NVLink 5** | NVIDIA | 1800 GB/s (18× 100 GB/s) | GPU-GPU direct | AI training (B200, GB200) |
|
||||
| **Infinity Fabric** | AMD | 896 GB/s | GPU-GPU + CPU-GPU | AI training (MI300X, MI350) |
|
||||
| **NVSwitch** | NVIDIA | 900 GB/s per GPU (NVLink) | Full-mesh (256 GPU) | DGX SuperPOD, HGX |
|
||||
| **InfiniBand (NDR)** | NVIDIA/Mellanox | 400 Gbps per port | GPU-NIC direct, RDMA | Distributed training, HPC |
|
||||
| **PCIe 5.0** | Standard | 63 GB/s per x16 | CPU-GPU | Inference, rendering |
|
||||
| **Ethernet (RoCE v2)** | Standard | 100/200/400 GbE | GPU-NIC, RDMA over converged ethernet | AI inference, storage |
|
||||
|
||||
### GPU direct communication
|
||||
|
||||
```
|
||||
GPU 0 ──NVLink── GPU 1 GPU 0 ───PCIe─── CPU ───PCIe─── GPU 1
|
||||
│ │
|
||||
│ │
|
||||
NVSwitch InfiniBand
|
||||
│ │
|
||||
│ │
|
||||
GPU 2 ──NVLink── GPU 3 GPU 2 ───PCIe─── CPU ───PCIe─── GPU 3
|
||||
|
||||
NVLink topologie (GPU direct) PCIe topologie (CPU mediated)
|
||||
```
|
||||
|
||||
- **GPU Direct RDMA** — GPU ↔ NIC bez CPU (InfiniBand, RoCE)
|
||||
- **GPU Direct Storage** — GPU ↔ NVMe bez CPU (NVIDIA Magnum IO)
|
||||
- **NVSwitch** — full bisection bandwidth mezi všemi GPU v node
|
||||
|
||||
## Virtualizace GPU
|
||||
|
||||
| Technologie | Popis | GPU support | Use case |
|
||||
|------------|-------|-------------|----------|
|
||||
| **NVIDIA vGPU (Grid)** | Časové slicing + dedikované profily | A-series (VDI), Q-series (pro viz), B-series (AI) | VDI, virtualizované AI |
|
||||
| **NVIDIA MIG** | Hardwarové partition GPU | A100 (7 inst.), H100/H200/B200 | AI inference, multi-tenant GPU |
|
||||
| **AMD MxGPU** | SR-IOV, hardwarové partition | AMD MI (pro), Radeon Pro | VDI, cloud gaming |
|
||||
| **Intel SG (SG1)** | SR-IOV, hardwarové partition | Intel SG1, Flex, Arc | VDI, media transcoding |
|
||||
| **GPU passthrough** | Dedikovaný GPU celé VM (VFIO-pci) | Všechny GPU | AI training, HPC, nejvyšší výkon |
|
||||
|
||||
### MIG partition table (A100 / H100)
|
||||
|
||||
| GPU | Partition profile | GPU Memory | Compute units |
|
||||
|-----|------------------|-----------|--------------|
|
||||
| **A100 80 GB** | 1g.5gb | 5 GB | 1 |
|
||||
| A100 80 GB | 2g.10gb | 10 GB | 2 |
|
||||
| A100 80 GB | 3g.20gb | 20 GB | 3 |
|
||||
| A100 80 GB | 7g.40gb | 40 GB | 7 |
|
||||
| A100 80 GB | Full (7× 1g) | 7 × 5 GB | 7 instances |
|
||||
| **H100 80 GB** | 1g.6gb+me | 6 GB | 1 |
|
||||
| H100 80 GB | 2g.12gb+me | 12 GB | 2 |
|
||||
| H100 80 GB | 3g.24gb+me | 24 GB | 3 |
|
||||
| H100 80 GB | 7g.80gb | 80 GB | 7 |
|
||||
|
||||
## GPU use cases
|
||||
|
||||
### AI Training
|
||||
|
||||
- **Modely**: LLM (70B-405B+), vision, multimodal
|
||||
- **GPU**: H100, B200, GB200, MI300X
|
||||
- **Interconnect**: NVLink 5 / Infinity Fabric (v rámci node), InfiniBand NDR (mezi nody)
|
||||
- **Parallelism**: Data Parallel (DDP), Tensor Parallel (TP), Pipeline Parallel (PP), Fully Sharded (FSDP)
|
||||
- **Framework**: PyTorch (NCCL), JAX (XLA), DeepSpeed, Megatron-LM
|
||||
- **Tipy**:
|
||||
- GB200: 2× B200 propojené NVLink, 8 GPU → 4 GB200
|
||||
- DGX B200 / HGX B200: standardní building block
|
||||
- InfiniBand: fat tree topology pro all-reduce optimalizaci
|
||||
|
||||
### AI Inference
|
||||
|
||||
- **Modely**: LLM serving, embedding, image gen
|
||||
- **GPU**: A100, H200, B200 (larger VRAM pro větší modely)
|
||||
- **Techniky**: MIG partition, TensorRT-LLM, vLLM, Triton Inference Server
|
||||
- **Kvantizace**: FP8, INT8, INT4 → nižší VRAM, vyšší throughput
|
||||
- **Latency**: batch size optimalizace, dynamic batching, continuous batching
|
||||
- **Scale**: on-prem (2-32 GPU) / cloud (elastic)
|
||||
|
||||
### VDI (Virtual Desktop Infrastructure)
|
||||
|
||||
- **GPU**: NVIDIA A16 (1 GPU = 16 users), A10 (1 GPU = 4 users)
|
||||
- **Technologie**: vGPU (Grid), AMD MxGPU
|
||||
- **Protokoly**: VMware Blast, Citrix HDX, Microsoft RDP, PC-over-IP (HP Teradici)
|
||||
- **Use case**: CAD (CATIA, SolidWorks), Office, engineering, healthcare (PACS)
|
||||
|
||||
### Rendering a VFX
|
||||
|
||||
- **GPU**: NVIDIA RTX 6000 Ada, RTX A6000, AMD Radeon Pro W7900
|
||||
- **Rendering**: Blender (Cycles/OptiX), V-Ray, Octane Render, Redshift
|
||||
- **Denoising**: AI-accelerated denoising na GPU
|
||||
- **Farm rendering**: Deadline, Qube! (job scheduler)
|
||||
|
||||
## GPU server form factors
|
||||
|
||||
| Form factor | GPU count | Power | Cooling | Příklad |
|
||||
|------------|-----------|-------|---------|---------|
|
||||
| **1U** | 1-2 | 700-1400 W | Air (high-RPM) | Dell XR4510c |
|
||||
| **2U** | 4-8 | 3-6 kW | Air / Liquid | Dell R760xa, HPE DL380a |
|
||||
| **4U** | 8-10 | 5-8 kW | Liquid | NVIDIA DGX H100, Dell R760xa |
|
||||
| **8U / Chassis** | 8-16 | 10-20 kW | Liquid (CDU) | NVIDIA HGX, Supermicro SYS-821GE |
|
||||
|
||||
## Zdroje
|
||||
|
||||
Odkazy, knihy a standardy: [sources/infrastructure/sources.md](sources/infrastructure/sources.md)
|
||||
10
HARDWARE.md
Normal file
10
HARDWARE.md
Normal file
@@ -0,0 +1,10 @@
|
||||
# 🔧 Hardware a servery
|
||||
|
||||
Tento soubor byl rozdělen do samostatných oblastí:
|
||||
|
||||
| Oblast | Soubor |
|
||||
|--------|--------|
|
||||
| 🔧 Server hardware — komponenty a architektura | [SERVER-HW.md](SERVER-HW.md) |
|
||||
| 🎮 GPU — architektura, modely, virtualizace | [GPU.md](GPU.md) |
|
||||
| ⚙️ Server configuration — best practices podle workloadu | [SERVER-CONFIG.md](SERVER-CONFIG.md) |
|
||||
| 📦 Provisioning — boot, instalace, správa serverů | [PROVISIONING.md](PROVISIONING.md) |
|
||||
154
HYPERVISORS.md
Normal file
154
HYPERVISORS.md
Normal file
@@ -0,0 +1,154 @@
|
||||
# 🖥️ Hypervisory a virtualizační platformy
|
||||
|
||||
## Typy hypervisorů
|
||||
|
||||
| Typ | Popis | Příklady |
|
||||
|-----|-------|----------|
|
||||
| **Type 1** (bare-metal) | Běží přímo na hardware | VMware ESXi, Microsoft Hyper-V, KVM, Xen |
|
||||
| **Type 2** (hosted) | Běží nad OS hostitele | VirtualBox, VMware Workstation, Parallels |
|
||||
|
||||
## Přehled platforem
|
||||
|
||||
| Platforma | Hypervisor | Licence | Poznámka |
|
||||
|-----------|-----------|---------|----------|
|
||||
| **VMware vSphere** | ESXi | Proprietary (Subscription od 2024) | Tržní lídr, široká adopce |
|
||||
| **Microsoft Hyper-V** | Hyper-V | Windows Server / standalone | Integrace s Azure, SCVMM |
|
||||
| **Proxmox VE** | KVM + LXC | Open source | Debian-based, web UI, levný |
|
||||
| **Red Hat OpenStack / oVirt** | KVM | Open source | Otevřená alternativa, komplexní |
|
||||
| **Nutanix AHV** | KVM (fork) | Součást Nutanix | Integrované HCI řešení |
|
||||
| **XCP-ng / Xen Server** | Xen | Open source | Nástupce Citrix Hypervisor |
|
||||
| **Oracle VM** | Xen | Proprietary | Oracle ekosystém |
|
||||
|
||||
## Klíčové koncepty
|
||||
|
||||
- **VM — Virtual Machine** — plná virtualizace, vlastní kernel
|
||||
- **Container** — sdílený kernel hostitele, lehčí (Docker, LXC)
|
||||
- **Paravirtualizace** — guest OS ví, že běží ve VM (lepší výkon I/O)
|
||||
- **NUMA** — Non-Uniform Memory Access, optimalizace přidělování CPU/memory (viz [HARDWARE.md](HARDWARE.md#memory-a-numa))
|
||||
- **Overcommit** — přidělení více vCPU/RAM než je fyzicky (řízení poměru)
|
||||
- **Live Migration** — přesun běžící VM mezi hosty (vSphere vMotion, Hyper-V Live Migration)
|
||||
- **HA (High Availability)** — restart VM na jiném hostu při selhání
|
||||
- **DRS / Load Balancing** — automatická distribuce VM podle vytížení
|
||||
|
||||
## VMware vSphere
|
||||
|
||||
### Cluster design
|
||||
|
||||
- **Max velikost clusteru**: 64 hostů (vSphere 8), 96 hostů (vSphere 8 + enhanced)
|
||||
- **Datastore limits**: max 256 datastorů na host, max 65 TB na VMFS-6 datastore
|
||||
- **vSAN ready capacity**: doporučeno max 60-64 hostů na vSAN cluster
|
||||
- **Fault domains** — rozdělení clusteru do skupin hostů (rack awareness), min 3 fault domains pro stetch cluster
|
||||
- **Admission control** — rezervace resource pro HA failover:
|
||||
- **Host failures cluster tolerates** — nejčastější (1-4 hosty)
|
||||
- **Percentage of cluster resources** — rezervace % CPU/memory
|
||||
- **Dedicated failover hosts** — vyhrazený host(y) pro HA
|
||||
- **Cluster limits (vSphere 8)**:
|
||||
- 512 VMs per host (max)
|
||||
- 15 000 VMs per cluster (vCenter max)
|
||||
- 300 hosts per cluster (vSphere 8, hardware vMotion)
|
||||
|
||||
## Microsoft Hyper-V
|
||||
|
||||
| Vlastnost | Hyper-V | Poznámka |
|
||||
|-----------|---------|----------|
|
||||
| **Max hostů v clusteru** | 64 (Windows Server 2025) | Shared Nothing Live Migration |
|
||||
| **Max VM na host** | 1024 (WS 2022+) | Generace 2 VM |
|
||||
| **Max vCPU per VM** | 240 (WS 2022+) | 64 hostů cluster |
|
||||
| **Max RAM per VM** | 12 TB (WS 2022+) | Dynamická paměť |
|
||||
| **Live Migration** | SMB, CSV, RDMA | Compressed nebo RDMA |
|
||||
| **Storage** | CSV (Cluster Shared Volumes), ReFS | S2D pro HCI |
|
||||
| **Nested Virtualization** | Ano | Intel VT-x / AMD-V |
|
||||
| **SCVMM** | System Center VMM | Enterprise management, fabric, P2V |
|
||||
|
||||
### Hyper-V vs VMware srovnání
|
||||
|
||||
| Vlastnost | VMware vSphere | Microsoft Hyper-V |
|
||||
|-----------|---------------|-------------------|
|
||||
| **OS** | VMware ESXi (VMkernel) | Windows Server / Hyper-V Server |
|
||||
| **Licence** | Per CPU (subscription) | Windows Server license / Datacenter |
|
||||
| **Storage** | VMFS, NFS, vSAN, HCI | NTFS, ReFS, SMB, S2D |
|
||||
| **Live Migration** | vMotion (cross-vSwitch, long distance) | Live Migration (SMB/RDMA) |
|
||||
| **Storage Migration** | Storage vMotion (online) | Shared Nothing (datový disk) |
|
||||
| **Replication** | vSphere Replication | Hyper-V Replica (ASR) |
|
||||
| **Management** | vCenter, vSphere Client | SCVMM, Hyper-V Manager, Admin Center |
|
||||
| **Linux support** | Výborný (open-vm-tools) | Dobrý (Linux Integration Services) |
|
||||
| **TCO** | Vyšší | Nižší (s Windows licencí) |
|
||||
|
||||
## KVM
|
||||
|
||||
### Architektura
|
||||
|
||||
```
|
||||
Hardware ──> QEMU (emulace I/O) + KVM (kernel module, virtualization)
|
||||
│
|
||||
libvirt (API + management)
|
||||
│
|
||||
┌───────┼───────────┐
|
||||
virt-manager virsh openstack/proxmox
|
||||
```
|
||||
|
||||
### Ladění
|
||||
|
||||
- **CPU pinning** — `virsh vcpupin vm1 0 2` (vCPU 0 → physical core 2), zamezuje přepínání kontextu
|
||||
- **Huge pages** — 2 MB / 1 GB stránky místo 4 KB, snížení výpadků TLB (VM s velkou RAM): `echo 2048 > /proc/sys/vm/nr_hugepages`
|
||||
- **NUMA affinity** — VM pinned na jeden NUMA node (minimalizace cross-NUMA memory access)
|
||||
- `numactl --cpunodebind=0 --membind=0`
|
||||
- `virsh numatune vm1 --nodeset 0`
|
||||
- **VirtIO** — paravirtualizované I/O (virtio-net, virtio-blk, virtio-scsi) pro lepší výkon
|
||||
- **IO threads** — dedikovaná vlákna pro I/O emulaci QEMU
|
||||
|
||||
### KVM tuning checklist
|
||||
|
||||
- Ověřit HW virtualizaci: `lscpu | grep Virtualization`
|
||||
- Naložit KVM moduly: `kvm`, `kvm_intel`/`kvm_amd`, `vfio-pci`
|
||||
- Optimalizovat storage: raw/LVM (vyhnout se qcow2 u výkonových workloadů)
|
||||
|
||||
## Storage v hypervizorech
|
||||
|
||||
Viz také: [STORAGE.md](STORAGE.md) — detailní přehled storage protokolů a konfigurací.
|
||||
|
||||
| Typ | Popis | Protokoly |
|
||||
|-----|-------|-----------|
|
||||
| **Local storage** | Disky přímo v serveru | SATA, SAS, NVMe |
|
||||
| **Shared storage** | SAN / NAS přístupné všem hostům | Fibre Channel, iSCSI, NFS, SMB |
|
||||
| **vSAN / HCI** | Hyperkonvergované úložiště (disky serverů = jediný pool) | VMware vSAN, Nutanix, StarWind |
|
||||
| **Software-Defined** | SDS odděluje storage software od hardware | Ceph, GlusterFS, MinIO |
|
||||
|
||||
## HCI detail
|
||||
|
||||
| Vlastnost | Nutanix (AOS + AHV) | VMware vSAN | Azure Stack HCI |
|
||||
|-----------|--------------------|-------------|----------------|
|
||||
| **Hypervisor** | AHV (KVM fork), ESXi optional | ESXi (required) | Hyper-V |
|
||||
| **Min. nodů** | 3 | 2 (witness) | 2 (witness) |
|
||||
| **Max nodů** | 80+ | 64 | 16 (typical) |
|
||||
| **Replikace** | 2 nebo 3 kopie + erasure coding | Mirroring (RAID 1), erasure coding | Mirroring + parity |
|
||||
| **Deduplication** | Na úrovni clusteru (post-process) | Na úrovni disku (capacity tier) | ReFS (real-time) |
|
||||
| **Compression** | Inline (AOS 6+) | Dedup + compression combined | ReFS |
|
||||
| **Management** | Prism (web UI) | vCenter + vSAN UI | Windows Admin Center |
|
||||
| **Licencování** | Per node subscription | Per CPU subscription | Per core subscription |
|
||||
| **Ekosystém** | Built-in DR, backup, security | Broad ISV ecosystem | Azure integration |
|
||||
| **Use case** | Enterprise VDI, general VM | VMware-centric shops | Azure hybrid, branch offices |
|
||||
|
||||
## Virtualizační platformy — srovnání
|
||||
|
||||
| Schopnost | VMware vSphere | Microsoft Hyper-V | Proxmox VE | Nutanix AHV |
|
||||
|-----------|---------------|-------------------|------------|-------------|
|
||||
| Live Migration | vMotion | Live Migration | Live Migration | Live Migration |
|
||||
| HA | vSphere HA | Hyper-V HA | Proxmox HA | Built-in |
|
||||
| DRS/balancování | DRS | SCVMM / AKS | HA skupiny | Built-in |
|
||||
| Storage vMotion | ano | při vypnuté VM | ZFS send/recv | Built-in |
|
||||
| Snapshoty | ano | ano | ano | ano |
|
||||
| Backup API | CBT (Changed Block Tracking) | Hyper-V WMI / RCT | Proxmox Backup Server | Native |
|
||||
| GPU passthrough | vGPU (NVIDIA Grid) | DDA | VFIO passthrough | GPU passthrough |
|
||||
| Licencování | Per CPU / subscription | Windows Server licence | Open source (free) | Per node subscription |
|
||||
|
||||
## OpenStack
|
||||
|
||||
- **Distribuce**: Red Hat OpenStack, Canonical Charmed OpenStack
|
||||
- **Služby**: Nova (compute), Cinder (block), Neutron (networking), Glance (images), Swift (object)
|
||||
- **Use case**: Telco, velké private cloudy, MNO (MANO, NFVI)
|
||||
- **Náročnost**: Vysoká — komplexní nasazení a údržba
|
||||
|
||||
## Zdroje
|
||||
|
||||
Odkazy, knihy a standardy: [sources/infrastructure/sources.md](sources/infrastructure/sources.md)
|
||||
10
INFRASTRUCTURE.md
Normal file
10
INFRASTRUCTURE.md
Normal file
@@ -0,0 +1,10 @@
|
||||
# 🏗️ Infrastruktura
|
||||
|
||||
Tento soubor byl rozdělen do samostatných oblastí:
|
||||
|
||||
| Oblast | Soubor |
|
||||
|--------|--------|
|
||||
| 🖥️ Hypervisory a virtualizace | [HYPERVISORS.md](HYPERVISORS.md) |
|
||||
| 🏭 Datová centra | [DATACENTERS.md](DATACENTERS.md) |
|
||||
| 💾 Storage | [STORAGE.md](STORAGE.md) |
|
||||
| 🔧 Hardware a servery | [HARDWARE.md](HARDWARE.md) |
|
||||
386
MONITORING.md
Normal file
386
MONITORING.md
Normal file
@@ -0,0 +1,386 @@
|
||||
# 📊 Monitoring a observabilita
|
||||
|
||||
## OpenMetrics standard
|
||||
|
||||
OpenMetrics (CNCF sandbox) je de-facto standard pro expozici metrik v cloud-native prostředí:
|
||||
|
||||
- Podpora text representation i Protocol Buffers
|
||||
- Základ pro Prometheus exposition format
|
||||
- Specifikuje: counter, gauge, histogram, summary, gaugehistogram, statefulset
|
||||
- `_total` suffix pro kumulativní hodnoty, `_bucket` pro histogramy
|
||||
- Metadata: HELP, TYPE, UNIT, (časové razítko volitelné)
|
||||
|
||||
Standard se vyvíjí v rámci [OpenObservability](https://github.com/OpenObservability/OpenMetrics).
|
||||
|
||||
## Nové nástroje a trendy (2024–2026)
|
||||
|
||||
| Nástroj | Popis |
|
||||
|---------|-------|
|
||||
| **Grafana Sigil** | AI observability pro LLM agenty (OTel-native) |
|
||||
| **InfraLens** | eBPF-based, zero-instrumentation network observability |
|
||||
| **Ingero** | GPU causal observability (eBPF, CUDA tracing) |
|
||||
| **GreptimeDB** | Unified observability DB — nahrazuje Prometheus + Loki + ES |
|
||||
| **Netdata** | AI-powered full-stack monitoring, 800+ integrations, edge ML |
|
||||
|
||||
## Tři pilíře observability
|
||||
|
||||
1. **Logs** — nestrukturovaná data o událostech (ERROR, WARN, INFO)
|
||||
2. **Metrics** — číselná data v čase (latence, chybovost, vytížení CPU)
|
||||
3. **Traces** — sledování požadavku napříč službami (distributed tracing)
|
||||
|
||||
## SLI / SLO / SLA
|
||||
|
||||
| Termín | Význam | Příklad |
|
||||
|--------|--------|---------|
|
||||
| **SLI** (Service Level Indicator) | Naměřená metrika | Latence p99 = 250ms |
|
||||
| **SLO** (Service Level Objective) | Cílová hodnota | 99.9 % requestů < 300ms |
|
||||
| **SLA** (Service Level Agreement) | Právní závazek | 99.95 % uptime |
|
||||
|
||||
### Error budget
|
||||
|
||||
`Error Budget = 100 % - SLO`
|
||||
- Pokud je SLO 99.9 %, error budget je 0.1 % času
|
||||
- Dokud error budget zbývá, tým může deployovat nové featury
|
||||
- Po vyčerpání — freeze na deploye, priorita je stabilita
|
||||
|
||||
## Pyramid of metrics — RED vs USE vs 4 Golden Signals
|
||||
|
||||
### 4 Golden Signals (Google SRE)
|
||||
|
||||
1. **Latency** — čas zpracování requestu (rozlišovat success vs error latenci)
|
||||
2. **Traffic** — počet requestů / propustnost (RPS, QPS, throughput)
|
||||
3. **Errors** — explicitní chyby (5xx, 4xx) i implicitní (success s chybným výsledkem)
|
||||
4. **Saturation** — jak je služba "plná" (CPU, memory, queue depth, connection pool)
|
||||
|
||||
### USE (pro infrastrukturu)
|
||||
- **U**tilization — jak je resource vytížená (% času je aktivní)
|
||||
- **S**aturation — kolik čeká ve frontě (run queue, I/O wait)
|
||||
- **E**rrors — chyby (dropped packets, disk errors, OOM)
|
||||
|
||||
### RED (pro služby)
|
||||
- **R**ate — počet requestů za sekundu
|
||||
- **E**rrors — počet chybných requestů
|
||||
- **D**uration — latence (distribuce, percentily)
|
||||
|
||||
| Metodologie | Zaměření | Typické metriky |
|
||||
|------------|----------|----------------|
|
||||
| **4 Golden Signals** | Služby + infrastruktura | Latence, RPS, errors, saturation |
|
||||
| **USE** | Infrastruktura | CPU util, I/O saturace, disk errors |
|
||||
| **RED** | Microservices | RPS, error rate, p50/p95/p99 latence |
|
||||
|
||||
## PromQL příklady
|
||||
|
||||
| Výraz | Popis |
|
||||
|-------|-------|
|
||||
| `rate(http_requests_total[5m])` | Počet requestů za sekundu (průměr za 5 min) |
|
||||
| `increase(http_requests_total[1h])` | Celkový nárůst za 1 hodinu |
|
||||
| `sum by (status) (rate(http_requests_total[5m]))` | Requesty agregované podle status kódu |
|
||||
| `histogram_quantile(0.99, sum(rate(http_request_duration_seconds_bucket[5m])) by (le))` | p99 latence |
|
||||
| `avg_over_time(cpu_usage[1h])` | Průměrné CPU vytížení za hodinu |
|
||||
| `topk(5, sum(rate(http_requests_total[5m])) by (service))` | Top 5 služeb podle RPS |
|
||||
| `max_over_time(memory_usage[24h])` | Maximální memory usage za 24h |
|
||||
| `rate(node_network_drop_total[5m]) > 0` | Sítě s dropped pakety |
|
||||
| `(1 - avg(rate(node_cpu_seconds_total{mode="idle"}[5m])))` | CPU utilization (1 - idle) |
|
||||
| `delta(http_request_duration_seconds_sum[5m]) / delta(http_request_duration_seconds_count[5m])` | Průměrná latence |
|
||||
| `absent(metric)` | Alert když metrika chybí |
|
||||
|
||||
## Recording rules
|
||||
|
||||
Pre-agregace často používaných PromQL dotazů pro snížení zátěže při dotazování.
|
||||
|
||||
### Kdy použít
|
||||
- Složité dotazy používané na více dashboardech
|
||||
- Dotazy nad surovými daty s vysokým kardinality
|
||||
- Často dotazované agregace (např. p99 latence za poslední měsíc)
|
||||
|
||||
### Příklad
|
||||
|
||||
```yaml
|
||||
groups:
|
||||
- name: service_rules
|
||||
interval: 1m
|
||||
rules:
|
||||
- record: job:http_requests:rate5m
|
||||
expr: sum(rate(http_requests_total[5m])) by (job)
|
||||
- record: instance:cpu:utilization
|
||||
expr: (1 - avg(rate(node_cpu_seconds_total{mode="idle"}[5m])) by (instance))
|
||||
- record: service:http_latency:p99
|
||||
expr: histogram_quantile(0.99, sum(rate(http_request_duration_seconds_bucket[5m])) by (le, service))
|
||||
```
|
||||
|
||||
- **record** — název nové metriky (konvence: `level:metric:aggregation`)
|
||||
- **interval** — jak často se pravidlo vyhodnocuje (typicky 1-5 min)
|
||||
|
||||
## Metriky — nástroje
|
||||
|
||||
### Metrics
|
||||
| Nástroj | Popis |
|
||||
|---------|-------|
|
||||
| Prometheus | Pull-based, time-series DB, silný query language (PromQL) |
|
||||
| Grafana | Vizualizace, dashboardy, alerting |
|
||||
| Datadog | SaaS, APM, logs, metrics v jednom |
|
||||
| New Relic | APM, browser monitoring |
|
||||
| CloudWatch | AWS nativní |
|
||||
| Azure Monitor | Azure nativní |
|
||||
| Google Cloud Ops | GCP nativní |
|
||||
|
||||
### Logging
|
||||
| Nástroj | Popis |
|
||||
|---------|-------|
|
||||
| ELK Stack | Elasticsearch, Logstash, Kibana |
|
||||
| Loki | Grafana Loki — lightweight, Prometheus-like |
|
||||
| Splunk | Enterprise log management |
|
||||
| Fluentd / Fluent Bit | Log collector a forwarder |
|
||||
| Vector | High-performance log/metric collector |
|
||||
|
||||
### Tracing
|
||||
| Nástroj | Popis |
|
||||
|---------|-------|
|
||||
| Jaeger | Open-source distributed tracing |
|
||||
| Zipkin | Open-source distributed tracing |
|
||||
| OpenTelemetry | Standard pro instrumentaci (logs, metrics, traces) |
|
||||
| Datadog APM | SaaS tracing |
|
||||
| AWS X-Ray | AWS tracing |
|
||||
|
||||
## OpenTelemetry detail
|
||||
|
||||
### Span attributes
|
||||
|
||||
```yaml
|
||||
resource:
|
||||
attributes:
|
||||
- service.name: "payment-service"
|
||||
- service.version: "1.2.3"
|
||||
- deployment.environment: "production"
|
||||
scope:
|
||||
name: "io.opentelemetry.payment"
|
||||
spans:
|
||||
- name: "processPayment"
|
||||
kind: SPAN_KIND_INTERNAL
|
||||
attributes:
|
||||
- payment.method: "credit_card"
|
||||
- payment.amount: 2499
|
||||
- payment.currency: "CZK"
|
||||
events:
|
||||
- name: "authorization.complete"
|
||||
timestamp: 1717428000000000000
|
||||
```
|
||||
|
||||
### Context propagation (W3C TraceContext)
|
||||
|
||||
- **`traceparent`** — hlavička nesoucí trace-id, span-id, trace flags
|
||||
- Formát: `00-0af7651916cd43dd8448eb211c80319c-b7ad6b7169203331-01`
|
||||
- Version (00) | Trace-ID (32 hex) | Span-ID (16 hex) | TraceFlags (01 = sampled)
|
||||
- **`tracestate`** — vendor-specific data, kompatibilní cross-provider
|
||||
- Propagace probíhá přes HTTP hlavičky, gRPC metadata, message queue properties
|
||||
|
||||
### Sampling
|
||||
|
||||
| Typ | Popis | Use case |
|
||||
|-----|-------|----------|
|
||||
| **Head-based** | Rozhodnutí o sample na začátku trace (na základě ID) | Jednoduchý, deterministický |
|
||||
| **Tail-based** | Rozhodnutí po dokončení trace (podle výsledku, latence) | Kvalitnější sample, komplexnější |
|
||||
|
||||
- Tail-based sampling: často používán pro kritické trace (5xx, p99+, slow traces)
|
||||
- Nástroje: Grafana Tempo (tail-based), Jaeger (head-based), OTel Collector (head + tail)
|
||||
|
||||
## Alerting
|
||||
|
||||
### Principy
|
||||
|
||||
- **Alert na symptom, ne na příčinu** — "500 errors" místo "high CPU"
|
||||
- **Reduce noise** — flapping alerts, alert fatigue
|
||||
- **Runbook pro každý alert** — co dělat když alert pípne
|
||||
- **Alert severity** — P0 (critical), P1 (high), P2 (medium), P3 (low)
|
||||
|
||||
### Alertmanager (Prometheus)
|
||||
|
||||
```yaml
|
||||
route:
|
||||
receiver: "team-pager"
|
||||
group_by: ["alertname", "cluster"]
|
||||
group_wait: 30s
|
||||
group_interval: 5m
|
||||
repeat_interval: 4h
|
||||
routes:
|
||||
- match:
|
||||
severity: critical
|
||||
receiver: "team-pager"
|
||||
repeat_interval: 1h
|
||||
- match:
|
||||
severity: warning
|
||||
receiver: "team-slack"
|
||||
|
||||
receivers:
|
||||
- name: "team-pager"
|
||||
pagerduty_configs:
|
||||
- routing_key: "<KEY>"
|
||||
severity: "{{ .CommonLabels.severity }}"
|
||||
- name: "team-slack"
|
||||
slack_configs:
|
||||
- channel: "#alerts"
|
||||
title: "{{ .GroupLabels.alertname }}"
|
||||
```
|
||||
|
||||
**Koncepty**:
|
||||
- **Grouping** — seskupování alertů podle labelů (snížení noise, např. všechny down instance v clusteru)
|
||||
- **Inhibition** — potlačení méně závažných alertů při existenci závažnějšího (např. nodedown inhibuje pod alerty)
|
||||
- **Silencing** — dočasné potlačení alertu (matching labels + duration)
|
||||
- **Routing tree** — hierarchické routování podle label match (severity, service, team)
|
||||
|
||||
### ESM (Event / Incident Management)
|
||||
|
||||
- PagerDuty, Opsgenie, OnCall (Grafana)
|
||||
- Escalation policies
|
||||
- On-call rotations
|
||||
|
||||
## Strukturované logování
|
||||
|
||||
```
|
||||
{
|
||||
"timestamp": "2026-06-03T10:30:00Z",
|
||||
"level": "ERROR",
|
||||
"service": "payment-service",
|
||||
"trace_id": "abc123",
|
||||
"user_id": "u456",
|
||||
"message": "Payment gateway timeout",
|
||||
"duration_ms": 1200,
|
||||
"error": {
|
||||
"type": "TimeoutError",
|
||||
"message": "Gateway did not respond in 1000ms"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### Povinná pole strukturovaného logu
|
||||
|
||||
| Pole | Popis | Příklad |
|
||||
|------|-------|---------|
|
||||
| `timestamp` | ISO 8601 / RFC 3339 | `2026-06-03T10:30:00Z` |
|
||||
| `level` | Log level (RFC 5424) | `ERROR`, `WARN`, `INFO`, `DEBUG` |
|
||||
| `message` | Lidsky čitelná zpráva | `Payment processed` |
|
||||
| `service` | Název služby | `payment-service` |
|
||||
| `trace_id` | Korelace napříč službami | `abc123def456` |
|
||||
|
||||
### RFC 5424 log levels
|
||||
|
||||
| Číslo | Level | Použití |
|
||||
|-------|-------|---------|
|
||||
| 0 | EMERG | Systém nepoužitelný |
|
||||
| 1 | ALERT | Nutná okamžitá akce |
|
||||
| 2 | CRIT | Kritická chyba |
|
||||
| 3 | ERROR | Chyba (ne kritická) |
|
||||
| 4 | WARN | Varování |
|
||||
| 5 | NOTICE | Normální, ale důležitá událost |
|
||||
| 6 | INFO | Informační zpráva |
|
||||
| 7 | DEBUG | Ladění (vypnuto v produkci) |
|
||||
|
||||
### Correlation ID (traceparent)
|
||||
|
||||
- Generován při vstupu do systému (API gateway, frontend, message consumer)
|
||||
- Propagován v HTTP hlavičce `X-Correlation-ID` / `traceparent`
|
||||
- Umožňuje spojit logy napříč microservices (→ Grafana Explore, Kibana Discover)
|
||||
- Implementace: middleware v aplikaci, service mesh (Envoy), API gateway
|
||||
|
||||
## Distributed tracing detail
|
||||
|
||||
### Span kinds
|
||||
|
||||
| Kind | Popis | Příklad |
|
||||
|------|-------|---------|
|
||||
| **CLIENT** | Volání downstream služby (outbound) | HTTP klient volá API |
|
||||
| **SERVER** | Zpracování příchozího požadavku | HTTP handler |
|
||||
| **INTERNAL** | Lokální operace v rámci služby | Výpočet, transformace |
|
||||
| **PRODUCER** | Odeslání zprávy do fronty | Kafka producer |
|
||||
| **CONSUMER** | Příjem zprávy z fronty | Kafka consumer |
|
||||
|
||||
### Trace context chain
|
||||
|
||||
```
|
||||
Trace: abc123
|
||||
├── Span: /checkout (SERVER, root)
|
||||
│ ├── Span: validateCart (INTERNAL)
|
||||
│ ├── Span: POST /orders (CLIENT → payment-service)
|
||||
│ │ └── Span: /processPayment (SERVER)
|
||||
│ │ ├── Span: authorizeCard (INTERNAL)
|
||||
│ │ └── Span: chargeCard (CLIENT → bank-gateway)
|
||||
│ │ └── Span: /charge (SERVER, external)
|
||||
│ └── Span: sendConfirmation (PRODUCER → kafka)
|
||||
│ └── Span: consumeConfirmation (CONSUMER → email-service)
|
||||
```
|
||||
|
||||
- **W3C TraceContext** — standardizace cross-service tracing
|
||||
- **Baggage** — přenos kontextových dat (tenant, user role) mezi spans
|
||||
|
||||
## Grafana
|
||||
|
||||
### Provisioning dashboards as code
|
||||
|
||||
```yaml
|
||||
apiVersion: 1
|
||||
providers:
|
||||
- name: "default"
|
||||
orgId: 1
|
||||
folder: "Services"
|
||||
type: file
|
||||
options:
|
||||
path: /etc/grafana/provisioning/dashboards
|
||||
```
|
||||
|
||||
Dashboards JSON v gitu → CI/CD → automatický import do Grafany.
|
||||
|
||||
### Variables
|
||||
|
||||
- **Query variable** — dynamické hodnoty (např. seznam service names z PromQL: `label_values(up, service)`)
|
||||
- **Interval variable** — `$__auto_interval`, `$__interval` pro proměnlivý time range
|
||||
- **Custom variable** — ruční seznam hodnot (env: prod, staging, dev)
|
||||
- **Chained variable** — závislá proměnná (výběr namespace → zobrazí pody v namespace)
|
||||
|
||||
### Annotations
|
||||
|
||||
- Kreslení událostí do grafu (deploye, incidenty, config změny)
|
||||
- Zdroje: Prometheus alerty, Loki logy, GitHub Actions, custom API
|
||||
- Use case: "Deploy v 14:30 → spike v latenci v 14:31 → korelace"
|
||||
|
||||
## On-call best practices
|
||||
|
||||
### Escalation policies
|
||||
|
||||
```
|
||||
Level 1: Primární on-call (reakce do 5 min)
|
||||
└── timeout 15 min
|
||||
Level 2: Sekundární / senior engineer (reakce do 15 min)
|
||||
└── timeout 15 min
|
||||
Level 3: Engineering manager / incident commander
|
||||
```
|
||||
|
||||
### Incident severity matrix
|
||||
|
||||
| Severity | Popis | Reakce | Komunikace |
|
||||
|----------|-------|--------|------------|
|
||||
| **P0 (Critical)** | Služba kompletně nedostupná, data loss, security breach | Ihned, 24/7 | Status page + Stakeholder update |
|
||||
| **P1 (High)** | Major funkčnost degradovaná, část uživatelů postižena | Do 15 min | Slack channel + Tým lead |
|
||||
| **P2 (Medium)** | Non-critical funkce nefunguje, workaround existuje | Do 1 h | Slack channel |
|
||||
| **P3 (Low)** | Kosmetický problém, žádný dopad na uživatele | Next business day | Jira ticket |
|
||||
|
||||
### Postmortem
|
||||
|
||||
- **Blameless** — cílem je naučit se, ne obviňovat
|
||||
- **Struktura**: Timeline, detection, root cause, resolution, action items
|
||||
- **SRE princip**: každá incident → postmortem → systémové zlepšení
|
||||
- **Nástroje**: Jira, Incident.io, PagerDuty postmortem, Google Docs
|
||||
|
||||
## Logging patterns
|
||||
|
||||
### Best practices
|
||||
|
||||
- **Dashboard pro každou úroveň** — executive, service, troubleshooting
|
||||
- **Syntetické monitoring** — Heartbeat checky, browser tests (Playwright, Cypress)
|
||||
- **APM** — Application Performance Monitoring (databázové query, externí volání)
|
||||
- **Anomaly detection** — ML-based detekce outlierů
|
||||
- **Retention politika** — raw data krátce, agregace dlouhodobě
|
||||
- **Jednotný formát logů** — JSON, strukturovaná data
|
||||
|
||||
## Zdroje
|
||||
|
||||
Odkazy, knihy a standardy: [sources/monitoring/sources.md](sources/monitoring/sources.md)
|
||||
396
NETWORKING.md
Normal file
396
NETWORKING.md
Normal file
@@ -0,0 +1,396 @@
|
||||
# 🌐 Síťová architektura
|
||||
|
||||
## Referenční model (TCP/IP)
|
||||
|
||||
| Vrstva | Protokoly | Zařízení |
|
||||
|--------|-----------|----------|
|
||||
| Aplikační | HTTP/HTTPS, DNS, SMTP, SSH | — |
|
||||
| Transportní | TCP, UDP | — |
|
||||
| Síťová | IP, ICMP, BGP | Routery |
|
||||
| Linková | Ethernet, ARP, VLAN | Switche |
|
||||
|
||||
## TCP detail
|
||||
|
||||
### 3-way handshake
|
||||
|
||||
```
|
||||
Client Server
|
||||
| |
|
||||
| SYN (seq=x) |
|
||||
|──────────────────────────────>|
|
||||
| |
|
||||
| SYN+ACK (seq=y, ack=x+1) |
|
||||
|<──────────────────────────────|
|
||||
| |
|
||||
| ACK (seq=x+1, ack=y+1) |
|
||||
|──────────────────────────────>|
|
||||
| |
|
||||
| << established >> |
|
||||
```
|
||||
|
||||
- **SYN** — client odešle segment s příznakem SYN (Synchronize Sequence Number)
|
||||
- **SYN-ACK** — server odpoví vlastním SYN + potvrzením clientova seq čísla
|
||||
- **ACK** — client potvrdí, spojení je navázáno
|
||||
- TCP Fast Open (TFO) — data v SYN paketu pro 0-RTT u opakovaných spojení
|
||||
|
||||
### Flow control (sliding window)
|
||||
|
||||
- **Receiver Window (rwnd)** — kolik dat je receiver ochoten přijmout
|
||||
- **Sliding window** — sender udržuje okno nepotvrzených paketů
|
||||
- Window scaling (RFC 1323) — umožňuje okno až 1 GB (místo 64 KB)
|
||||
- Zero Window — receiver oznámí 0, sender zastaví, persist timer periodicky testuje
|
||||
|
||||
### Congestion control
|
||||
|
||||
| Algoritmus | Popis | Use case |
|
||||
|-----------|-------|----------|
|
||||
| **Cubic** | Výchozí v Linuxu (od kernel 2.6.19), kubická growth funkce | Obecné sítě, výchozí pro Internet |
|
||||
| **BBR** (Bottleneck Bandwidth and RTT) | Model-based, měří bandwidth a RTT, ne packet loss | Vysokorychlostní sítě, YouTube, Google |
|
||||
| **Reno** | Classic AIMD (Additive Increase Multiplicative Decrease) | Legacy, reference |
|
||||
| **CDG** (CAIA Delay Gradient) | Delay-based, detekce congeste podle RTT gradientu | Videostreaming, real-time |
|
||||
|
||||
BBRv2 (2024+) — zahrnuje ECN signalizaci, koexistenci s Cubic, lepší handling při loss.
|
||||
|
||||
## DNS (Domain Name System)
|
||||
|
||||
- **Record typy**: A, AAAA, CNAME, MX, TXT, NS, SRV, PTR, CAA, DS, DNSKEY, RRSIG, NSEC
|
||||
- **DNS resolver**: rekurzivní dotaz přes hierarchii (root → TLD → authoritative)
|
||||
- **Anycast DNS** — stejná IP z více lokací, směrování k nejbližší
|
||||
- **DNS caching** — TTL řízení, cache poisoning ochrana (DNSSEC)
|
||||
- **Cloud DNS** — Route53, Azure DNS, Cloud DNS
|
||||
|
||||
### DNS lookup flow (krok za krokem)
|
||||
|
||||
```
|
||||
1. Uživatel zadá "api.example.com" do prohlížeče
|
||||
2. OS stub resolver zkontroluje lokální cache (/etc/hosts, systemd-resolved)
|
||||
3. Pokud není v cache → dotaz na rekurzivní resolver (ISP / 8.8.8.8 / 1.1.1.1)
|
||||
4. Resolver zkontroluje svou cache
|
||||
5. Nenalezeno → resolver začne rekurzivní lookup:
|
||||
a. Dotaz na root nameserver (.) → vrátí NS pro .com
|
||||
b. Dotaz na .com TLD nameserver → vrátí NS pro example.com
|
||||
c. Dotaz na autoritativní NS pro example.com → vrátí A záznam (IP)
|
||||
6. Resolver uloží do cache (TTL), vrátí IP clientu
|
||||
7. Client naváže TCP spojení na získanou IP
|
||||
```
|
||||
|
||||
Celý proces typicky trvá 10–200 ms (s cache < 1 ms).
|
||||
|
||||
### DNSSEC detail
|
||||
|
||||
- **RRSIG** — digitální podpis pro každý RRset (Resource Record Set)
|
||||
- **DNSKEY** — veřejný klíč zóny (ZSK = Zone Signing Key, KSK = Key Signing Key)
|
||||
- **DS** (Delegation Signer) — hash DNSKEY předávaný do parent zóny (řetěz důvěry)
|
||||
- **NSEC / NSEC3** — authenticated denial of existence (důkaz, že záznam neexistuje)
|
||||
- **Chain of trust**: root → .com → example.com (cesta od trust anchor přes DS recordy)
|
||||
|
||||
```
|
||||
Root DS → .com DNSKEY → .com DS → example.com DNSKEY → example.com RRSIG(A)
|
||||
```
|
||||
|
||||
- Validace: resolver zkontroluje podpisy přes celý řetěz až k trust anchor
|
||||
|
||||
### DNS-based service discovery
|
||||
|
||||
| Mechanismus | Popis | Příklad |
|
||||
|------------|-------|---------|
|
||||
| **SRV record** | Service location (priority, weight, port, target) | `_http._tcp.example.com` |
|
||||
| **Consul DNS** | Service discovery přes DNS rozhraní | `web.service.consul` |
|
||||
| **CoreDNS** | Kubernetes DNS, plugin-based | `my-svc.my-namespace.svc.cluster.local` |
|
||||
| **Kubernetes DNS** | Service discovery uvnitř clusteru (kube-dns / CoreDNS) | `svc.cluster.local` |
|
||||
| **mDNS** (Multicast DNS) | Zero-config, lokální síť (Bonjour/Avahi) | `myprinter.local` |
|
||||
|
||||
## Load Balancing
|
||||
|
||||
| Typ | Vrstva (OSI) | Popis |
|
||||
|-----|-------------|-------|
|
||||
| L4 (NLB) | 4 | TCP/UDP, rychlý, nižší latence |
|
||||
| L7 (ALB) | 7 | HTTP/HTTPS, path-based routing, sticky sessions |
|
||||
| Global | DNS | Geo-routing, latency-based, weighted |
|
||||
|
||||
### Algoritmy
|
||||
|
||||
- Round Robin / Weighted RR
|
||||
- Least Connections
|
||||
- IP Hash (session persistence)
|
||||
- Random
|
||||
|
||||
### Health check typy
|
||||
|
||||
| Typ | Popis | Vhodné pro |
|
||||
|-----|-------|-----------|
|
||||
| **TCP health check** | TCP handshake na cílový port | L4 NLB, základní check |
|
||||
| **HTTP health check** | HTTP GET na URL, očekává 200 OK | L7 ALB, webové služby |
|
||||
| **HTTPS health check** | HTTP + TLS handshake | Služby s TLS terminací |
|
||||
| **gRPC health check** | gRPC Health/Check RPC (gRPC specific) | Microservices, gRPC služby |
|
||||
| **ICMP ping** | Ping na cílovou IP | Základní konektivita |
|
||||
|
||||
### Connection draining
|
||||
|
||||
- **Connection draining** (AWS) / **Deregistration delay** — při odebrání targetu z ASG/LB se počká, až existující spojení skončí (configurable: 1-3600 s)
|
||||
- **Slow start** — nový target dostává postupně více requestů (zabrání přetížení cold cache)
|
||||
|
||||
### Cross-zone load balancing
|
||||
|
||||
- **Enabled**: LB rovnoměrně rozděluje traffic napříč všemi AZ (i nerovnoměrný počet instancí)
|
||||
- **Disabled**: traffic rozdělen rovnoměrně mezi AZ, pak v rámci AZ mezi instance
|
||||
- AWS ALB/NLB: enabled by default (2022+), bez dalších poplatků
|
||||
|
||||
## Firewally a bezpečnost
|
||||
|
||||
- **Stateful firewall** — sleduje stav spojení (AWS Security Groups, Azure NSG)
|
||||
- **Stateless firewall** — ACL (Network ACLs)
|
||||
- **NGFW** — aplikační vrstva, IPS/IDS (Palo Alto, Fortinet)
|
||||
- **WAF** — ochrana web aplikací (Cloudflare, AWS WAF, Azure WAF)
|
||||
|
||||
## Network segmentation — Security Groups vs Network ACLs
|
||||
|
||||
| Vlastnost | Security Group (SG) | Network ACL (NACL) |
|
||||
|-----------|-------------------|-------------------|
|
||||
| **State** | Stateful (automaticky povoluje return traffic) | Stateless (nutné explicitní pravidlo pro oba směry) |
|
||||
| **Úroveň** | Instance / ENI | Subnet |
|
||||
| **Pravidla** | Povolující (allow only) | Povolující i zakazující (allow + deny) |
|
||||
| **Vyhodnocení** | Všechna pravidla se vyhodnotí (OR) | Pravidla od nejnižšího čísla (first match) |
|
||||
| **Default** | All traffic denied (inbound), all traffic allowed (outbound) | All traffic denied (inbound i outbound) |
|
||||
| **Podpora** | AWS, GCP (firewall rules), Azure (NSG) | AWS (NACL), GCP (firewall rules na subnet), Azure (NSG) |
|
||||
|
||||
### Mikrosegmentace
|
||||
|
||||
- **Zero Trust networking** — každý workload má vlastní security group / NGFW policy
|
||||
- **Service mesh** — Istio, Linkerd, Consul Connect pro L7 mikrosegmentaci (mTLS, authorization policies)
|
||||
- **Network policies** — Kubernetes NetworkPolicy pro segmentaci pod-to-pod trafficu
|
||||
- **Tanzu / NSX** — micro-segmentation na hypervisor úrovni
|
||||
|
||||
## VPN
|
||||
|
||||
- **Site-to-Site** — IPSec, trvalé spojení mezi lokalitami
|
||||
- **Client-to-Site** — OpenVPN, WireGuard, AnyConnect
|
||||
- **Cloud VPN** — AWS VPN, Azure VPN Gateway, GCP Cloud VPN
|
||||
|
||||
## CDN (Content Delivery Network)
|
||||
|
||||
- Edge lokace pro cachování statického obsahu
|
||||
- DDoS ochrana
|
||||
- SSL/TLS termination na edge
|
||||
- Poskytovatelé: CloudFront, Cloudflare, Akamai, Fastly
|
||||
|
||||
## BGP a routing
|
||||
|
||||
- **BGP** — protokol pro výměnu rout mezi AS (autonomními systémy)
|
||||
- **ASN** — unikátní identifikátor sítě
|
||||
- **iBGP** — interní BGP (uvnitř AS)
|
||||
- **eBGP** — externí BGP (mezi AS)
|
||||
|
||||
### BGP path selection algoritmus
|
||||
|
||||
BGP router vybírá jedinou nejlepší cestu podle následujících kriterií (v pořadí priority):
|
||||
|
||||
1. **WEIGHT** (Cisco-specific) — nejvyšší weight (local to router)
|
||||
2. **LOCAL_PREF** — nejvyšší local preference (v rámci AS)
|
||||
3. **Originate** — preferuje route originovanou lokálním routerem
|
||||
4. **AS_PATH** — nejkratší AS_PATH length
|
||||
5. **ORIGIN** — IGP < EGP < INCOMPLETE
|
||||
6. **MED** (Multi-Exit Discriminator) — nejnižší MED (při stejném AS souseda)
|
||||
7. **eBGP > iBGP** — preferuje externí BGP před interním
|
||||
8. **Next-hop reachable** — cesta k next-hop musí být dosažitelná
|
||||
9. **Neighbor IP** — preferuje cestu od routeru s nejnižší IP
|
||||
10. **Router ID** — preferuje cestu s nejnižším Router ID
|
||||
|
||||
### iBGP full mesh vs Route Reflectors
|
||||
|
||||
| Aspekt | Full mesh | Route reflectors |
|
||||
|--------|-----------|-----------------|
|
||||
| **Počet session** | n(n-1)/2 | n (každý peer k RR) |
|
||||
| **Při 100 routerech** | 4 950 session | 100 (při 1 RR) |
|
||||
| **Škálování** | Špatné (kvadratické) | Lineární |
|
||||
| **Redundance** | Přirozená | Nutné multi-RR + cluster |
|
||||
| **Konfigurace** | Jednoduchá logika | RR pravidel (non-transitive) |
|
||||
|
||||
BGP nutné znát pro: Cloud interconnects, MPLS L3VPN, SD-WAN, Data center fabrics (VXLAN + BGP EVPN)
|
||||
|
||||
## Architektura VPC / Virtual Network
|
||||
|
||||
```
|
||||
Internet ──┬── Internet Gateway (IGW)
|
||||
│
|
||||
┌──────▼──────┐
|
||||
│ Public Subnet │
|
||||
│ ┌──────────┐ │
|
||||
│ │ ALB/NAT │ │
|
||||
│ └────┬─────┘ │
|
||||
└───────┼────────┘
|
||||
│
|
||||
┌───────▼────────┐
|
||||
│ Private Subnet │
|
||||
│ ┌──────────┐ │
|
||||
│ │ App │ │
|
||||
│ └────┬─────┘ │
|
||||
└───────┼─────────┘
|
||||
│
|
||||
┌───────▼─────────┐
|
||||
│ Data Subnet │
|
||||
│ ┌────────────┐ │
|
||||
│ │ Database │ │
|
||||
│ └────────────┘ │
|
||||
└──────────────────┘
|
||||
```
|
||||
|
||||
### VPC design patterns
|
||||
|
||||
**Three-tier architecture**
|
||||
- Web tier (public subnets) → ALB
|
||||
- App tier (private subnets) → auto-scaling
|
||||
- Data tier (private subnets) → RDS / self-managed DB
|
||||
- NAT Gateway / Instance v public subnet pro outbound traffic z app/data tier
|
||||
|
||||
**VPC Peering**
|
||||
- Přímé spojení mezi dvěma VPC (same nebo cross-account)
|
||||
- Transitive peering **není** podporován (A→B, B→C neznamená A→C)
|
||||
- Případy: sharing resources (LDAP, monitoring), service endpoints
|
||||
|
||||
**Transit Gateway**
|
||||
- Hub-and-spoke topologie, transitive routing
|
||||
- Podporuje: VPC, VPN, Direct Connect, peering mezi TGW
|
||||
- Route tables per attachment — izolace environmentů
|
||||
- AWS TGW: 50 Gbps per attachment, až 5000 attachments
|
||||
|
||||
**PrivateLink / VPC Endpoint**
|
||||
- Privátní přístup k službám bez IGW, NAT, VPC peering
|
||||
- **Interface Endpoint** (ENI v subnet) — pro AWS services, SaaS
|
||||
- **Gateway Endpoint** (S3, DynamoDB) — route table entry, zdarma
|
||||
- **AWS PrivateLink** — Service Consumer ↔ NLB/ENI ↔ Service Provider
|
||||
|
||||
## MTU, jumbo frames, PMTUD
|
||||
|
||||
| Síť | Standardní MTU | Jumbo frames |
|
||||
|-----|---------------|--------------|
|
||||
| Ethernet | 1500 B | 9001 B (AWS: 9001, Azure: 1400→9000) |
|
||||
| GRE tunel | 1476 B | — |
|
||||
| PPPoE | 1492 B | — |
|
||||
| VLAN (802.1Q) | 1496 B | — |
|
||||
| VXLAN | N/A (inner 1500 + 50) | 8950 B |
|
||||
|
||||
**PMTUD** (Path MTU Discovery)
|
||||
- Nastaví DF (Don't Fragment) bit v IP hlavičce
|
||||
- Pokud cesta vyžaduje fragmentaci → ICMP "Fragmentation Needed" (Type 3, Code 4)
|
||||
- Snižuje MTU, dokud paket neprojde
|
||||
- Častý problém: ICMP blokovaný firewallem → black hole (TCP connection hangs)
|
||||
- **Workaround**: MSS clamping (TCP MSS = MTU - 40)
|
||||
|
||||
**Jumbo frames use cases**
|
||||
- NFS / SMB (NAS)
|
||||
- iSCSI / NVMe-oF (SAN)
|
||||
- HPC / MPI workloads
|
||||
- Data replication (DB, DRBD)
|
||||
- Amazon EFS, AWS Managed Streaming pro Kafka
|
||||
|
||||
## Anycast vs Unicast vs Multicast
|
||||
|
||||
| Typ | Popis | Příklad |
|
||||
|-----|-------|---------|
|
||||
| **Unicast** | 1:1 — jeden source, jeden destination | Běžný TCP/IP provoz |
|
||||
| **Multicast** | 1:N — jeden source, skupina receiverů | IPTV, mDNS, VXLAN BUM traffic |
|
||||
| **Anycast** | 1:1 z nejbližšího — stejná IP z více lokací | DNS (8.8.8.8, 1.1.1.1), Cloudflare |
|
||||
| **Broadcast** | 1:VŠICHNI — všechna zařízení v síti | ARP, DHCP (omezeno na L2 broadcast doménu) |
|
||||
|
||||
Anycast detail:
|
||||
- Stejná IP prefix je anunciována z více lokací (BGP)
|
||||
- Traffic jde k topologicky nejbližšímu uzlu (BGP path selection)
|
||||
- **Výhody**: jednoduchá redundance, DDoS absorpce, nižší latence
|
||||
- **Výzvy**: connection persistence (TCP), stateful anycast, routing convergence
|
||||
- **Cloud**: Route53, CloudFront, Cloudflare, Google DNS
|
||||
|
||||
## Cloud networking resilience (2026)
|
||||
|
||||
Viz také: [CLOUD.md](CLOUD.md) — cloud architektura, multi-AZ, hybrid cloud konektivita.
|
||||
|
||||
### Cell-based architektury
|
||||
|
||||
- Izolace fault domain do "cell" (skupina AZ + services)
|
||||
- Každá cell samostatně deploysovatelná, vlastní DB, vlastní LB
|
||||
- Limit blast radius: selhání jedné cell neovlivní ostatní
|
||||
- Implementace: AWS Cell-based architecture, Azure STAG (Scale Tier Availability Group)
|
||||
|
||||
### DNS resilience
|
||||
|
||||
- **Anycast DNS** — stejná IP z více regionů, směrování k nejbližšímu
|
||||
- **DNS failover** — health checky automaticky odstraňují nedostupné endpointy
|
||||
- **Multi-DNS provider** — Route53 + Cloudflare + UltraDNS pro eliminaci SPOF
|
||||
|
||||
### Traffic engineering
|
||||
|
||||
- **BGP optimization** — AS path prepend, MED, local pref pro řízení vstupního/výstupního trafficu
|
||||
- **Global Load Balancing** — GSLB na DNS úrovni (latency-based, geo-proximity, weighted)
|
||||
- **AIOps** — ML-based predikce traffic patternů a automatické škálování
|
||||
|
||||
### Nové trendy
|
||||
|
||||
- **Path Aware Networking** — aplikace si vybírá cestu sítí podle aktuálních podmínek
|
||||
- **Segment Routing (SR-MPLS / SRv6)** — zjednodušení MPLS, programovatelné cesty
|
||||
- **Zero Trust Networking** — mikrosegmentace, identity-based access, never trust / always verify
|
||||
|
||||
## Best practices
|
||||
|
||||
- **Segmentace sítě** — oddělení environmentů (dev/staging/prod), vrstev (web/app/db)
|
||||
- **Least privilege access** — security groups povolují jen nutný provoz
|
||||
- **Monitoring** — VPC Flow Logs, netflow, sFlow
|
||||
- **Redundance** — multi-AZ, multi-region pro kritické služby
|
||||
- **Encryption in transit** — TLS všude, mTLS pro service-to-service
|
||||
- **DDoS protection** — AWS Shield, Azure DDoS Protection, Cloudflare
|
||||
|
||||
## Zdroje
|
||||
|
||||
Odkazy, knihy a standardy: [sources/networking/sources.md](sources/networking/sources.md)
|
||||
- **MTU alignment** — konzistentní MTU napříč celou cestou, kontrola ICMP blokování pro PMTUD
|
||||
- **IP planning** — RFC 1918 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), vyhnout se překryvům pro peering
|
||||
|
||||
## TLS detail
|
||||
|
||||
### TLS 1.3 handshake (1-RTT)
|
||||
|
||||
```
|
||||
Client Server
|
||||
| |
|
||||
| ClientHello (key_share, sig_algs) |
|
||||
|─────────────────────────────────────────>|
|
||||
| |
|
||||
| ServerHello + EncryptedExtensions |
|
||||
| + Certificate + CertificateVerify |
|
||||
| + Finished |
|
||||
|<─────────────────────────────────────────|
|
||||
| |
|
||||
| Finished |
|
||||
|─────────────────────────────────────────>|
|
||||
| |
|
||||
| << Application Data >> |
|
||||
```
|
||||
|
||||
- **0-RTT** (early data) — client posílá data ihned s první zprávou (při opakovaném spojení s PSK)
|
||||
- Riziko 0-RTT: replay attacks (HTTP GET je bezpečný, POST vyžaduje ochranu)
|
||||
- Oproti TLS 1.2: odstraněny zastaralé ciphery, AEAD required, faster handshake (2 RTT → 1 RTT)
|
||||
|
||||
### Cipher suites
|
||||
|
||||
| Suite | Key exchange | Auth | Encryption | MAC | Status |
|
||||
|-------|-------------|------|-----------|-----|--------|
|
||||
| `TLS_AES_128_GCM_SHA256` | (EC)DHE | (EC)DHE | AES-128-GCM | AEAD | TLS 1.3 default |
|
||||
| `TLS_AES_256_GCM_SHA384` | (EC)DHE | (EC)DHE | AES-256-GCM | AEAD | Vyšší bezpečnost |
|
||||
| `TLS_CHACHA20_POLY1305_SHA256` | (EC)DHE | (EC)DHE | ChaCha20-Poly1305 | AEAD | Mobilní / bez AES-NI |
|
||||
| `ECDHE-ECDSA-AES128-GCM-SHA256` | ECDHE | ECDSA | AES-128-GCM | AEAD | TLS 1.2 (PFS) |
|
||||
| `ECDHE-RSA-AES128-GCM-SHA256` | ECDHE | RSA | AES-128-GCM | AEAD | TLS 1.2 (PFS) |
|
||||
|
||||
PFS (Perfect Forward Secrecy) — při kompromitaci privátního klíče nelze dešifrovat dříve zachycený provoz (ECDHE + ephemeral klíče).
|
||||
|
||||
### Certificate chain validation
|
||||
|
||||
```
|
||||
1. Client obdrží certificate chain od serveru
|
||||
2. Validace:
|
||||
a. Datum: certifikát není expirovaný a je platný (notBefore, notAfter)
|
||||
b. CRL / OCSP: certifikát není revokován (OCSP stapling pro snížení latence)
|
||||
c. Signature chain: podpis každého certu v řetězu je ověřen veřejným klíčem vydavatele
|
||||
d. Root CA: poslední cert v řetězu je důvěryhodný (v trust store klienta)
|
||||
3. CN / SAN: doménové jméno v certifikátu musí odpovídat cílové doméně
|
||||
```
|
||||
|
||||
Typický řetěz: `Leaf Cert → Intermediate CA → Root CA` (self-signed, v trust store).
|
||||
195
PROVISIONING.md
Normal file
195
PROVISIONING.md
Normal file
@@ -0,0 +1,195 @@
|
||||
# 📦 Provisioning — boot, instalace, správa serverů
|
||||
|
||||
## Síťový boot (PXE / iPXE)
|
||||
|
||||
### PXE boot flow
|
||||
|
||||
```
|
||||
1. Server power-on → PXE ROM v NIC / UEFI
|
||||
2. DHCP Broadcast → DHCP server nabídne IP + next-server (TFTP) + boot file
|
||||
3. TFTP stáhne pxelinux.0 (BIOS) / bootx64.efi (UEFI)
|
||||
4. Načte konfiguraci (pxelinux.cfg/default nebo MAC/IP-based)
|
||||
5. Stáhne kernel + initrd přes TFTP/HTTP (iPXE)
|
||||
6. Kernel boot → automatická instalace (Kickstart / Preseed / AutoYaST)
|
||||
```
|
||||
|
||||
### DHCP konfigurace (ISC DHCP)
|
||||
|
||||
```
|
||||
subnet 10.0.0.0 netmask 255.255.255.0 {
|
||||
next-server 10.0.0.10; # TFTP server
|
||||
filename "ipxe.efi"; # Boot file (UEFI)
|
||||
option domain-name-servers 10.0.0.10;
|
||||
option routers 10.0.0.1;
|
||||
}
|
||||
```
|
||||
|
||||
### iPXE (moderní náhrada PXE)
|
||||
|
||||
- HTTP místo TFTP (rychlejší, spolehlivější)
|
||||
- HTTPS support (Image verification, secure boot)
|
||||
- iSCSI boot, FCoE boot
|
||||
- Scriptable: `chain http://boot.example.com/script.ipxe`
|
||||
- Embedded: iPXE ROM flashnutá přímo do NIC
|
||||
|
||||
### Vergleich PXE vs iPXE
|
||||
|
||||
| Vlastnost | PXE | iPXE |
|
||||
|-----------|-----|------|
|
||||
| Protokol | TFTP (pomalý, 512B/blok) | HTTP/HTTPS/iSCSI |
|
||||
| Šifrování | Ne | HTTPS, TLS |
|
||||
| Scripting | Pouze menu | Plný scripting engine |
|
||||
| Debugging | Omezený | Vestavěný shell |
|
||||
| UEFI/BIOS | Oba | Oba |
|
||||
|
||||
## Automatická instalace
|
||||
|
||||
### Kickstart (RHEL/Alma/Rocky)
|
||||
|
||||
```
|
||||
# Minimal kickstart pro RHEL 9
|
||||
text
|
||||
url --url="http://10.0.0.10/install/rhel9"
|
||||
lang en_US.UTF-8
|
||||
keyboard us
|
||||
timezone Europe/Prague --isUtc
|
||||
|
||||
rootpw --iscrypted $6$...
|
||||
|
||||
%packages
|
||||
@^minimal-environment
|
||||
vim
|
||||
net-tools
|
||||
%end
|
||||
|
||||
%post
|
||||
echo "node001" > /etc/hostname
|
||||
%end
|
||||
|
||||
reboot
|
||||
```
|
||||
|
||||
### Preseed (Debian/Ubuntu)
|
||||
|
||||
```
|
||||
d-i debian-installer/locale string en_US.UTF-8
|
||||
d-i keyboard-configuration/xkb-keymap us
|
||||
d-i netcfg/choose_interface select auto
|
||||
d-i netcfg/get_hostname string node001
|
||||
d-i clock-setup/utc boolean true
|
||||
d-i time/zone string Europe/Prague
|
||||
|
||||
d-i partman-auto/method string regular
|
||||
d-i partman-auto/choose_recipe select atomic
|
||||
|
||||
d-i passwd/root-login boolean true
|
||||
d-i passwd/root-password password securepass
|
||||
d-i passwd/root-password-again password securepass
|
||||
|
||||
d-i pkgsel/include string openssh-server vim
|
||||
d-i finish-install/reboot_in_progress note
|
||||
```
|
||||
|
||||
## Metal as a Service
|
||||
|
||||
### MAAS (Canonical)
|
||||
|
||||
- **Discovery**: DHCP → PXE boot → hardware detection (CPU, RAM, disk, MAC)
|
||||
- **Komisionování**: node projde commissioning, uloží inventory do DB
|
||||
- **Deploy**: obraz OS (Ubuntu, RHEL, ESXi) nahrán na disk → reboot
|
||||
- **Integrace**: Juju, OpenStack, Kubernetes (Charmed Kubernetes)
|
||||
- **Networking**: VLAN, subnet, DNS/DHCP management, BGP peering
|
||||
|
||||
### Digital Rebar / RackN
|
||||
|
||||
- **Provisioning**: workflow-based (stages: discovery → firmware → OS → config)
|
||||
- **Multi-cloud**: bare metal + cloud + edge
|
||||
- **Template**: šablony pro OS deployment (RHEL, Ubuntu, VMware)
|
||||
- **API**: plně REST API, Terraform provider
|
||||
|
||||
## Management API — Redfish
|
||||
|
||||
### Standard DMTF
|
||||
|
||||
REST API (JSON) → nástupce IPMI.
|
||||
|
||||
| Endpoint | Účel |
|
||||
|----------|------|
|
||||
| `/redfish/v1/Systems/` | Server management (power, boot, inventory) |
|
||||
| `/redfish/v1/Chassis/` | Fyzický hardware (PSU, fan, temp, sensors) |
|
||||
| `/redfish/v1/Managers/` | BMC (iLO, iDRAC, XClarity) |
|
||||
| `/redfish/v1/UpdateService/` | Firmware updates |
|
||||
| `/redfish/v1/EventService/` | Event subscription (webhook) |
|
||||
|
||||
### Redfish příklady
|
||||
|
||||
```
|
||||
# Power on server
|
||||
POST /redfish/v1/Systems/1/Actions/ComputerSystem.Reset
|
||||
Body: {"ResetType": "On"}
|
||||
|
||||
# Set boot override (one-shot PXE)
|
||||
PATCH /redfish/v1/Systems/1
|
||||
Body: {"Boot": {"BootSourceOverrideTarget": "Pxe", "BootSourceOverrideEnabled": "Once"}}
|
||||
|
||||
# Get sensor data
|
||||
GET /redfish/v1/Chassis/1/Thermal
|
||||
→ {"Temperatures": [{"Name": "CPU1", "ReadingCelsius": 45}], "Fans": [...]}
|
||||
```
|
||||
|
||||
### IPMI (legacy)
|
||||
|
||||
- Port 623/UDP (RMCP)
|
||||
- `ipmitool power on/off/status`
|
||||
- `ipmitool sensor list`
|
||||
- `ipmitool chassis bootdev pxe`
|
||||
- Serial over LAN: `ipmitool sol activate`
|
||||
|
||||
## Terraform pro provisioning
|
||||
|
||||
```
|
||||
# Terraform provider pro VMware vSphere
|
||||
provider "vsphere" {
|
||||
user = var.vsphere_user
|
||||
password = var.vsphere_password
|
||||
vsphere_server = var.vsphere_server
|
||||
}
|
||||
|
||||
resource "vsphere_virtual_machine" "web" {
|
||||
name = "web-${count.index}"
|
||||
resource_pool_id = data.vsphere_resource_pool.pool.id
|
||||
datastore_id = data.vsphere_datastore.ds.id
|
||||
num_cpus = 4
|
||||
memory = 16384
|
||||
guest_id = "rhel9_64Guest"
|
||||
network_interface { network_id = data.vsphere_network.net.id }
|
||||
disk { label = "os", size = 80 }
|
||||
}
|
||||
```
|
||||
|
||||
Více v [CICD.md](CICD.md#infrastructure-as-code).
|
||||
|
||||
## Firmware management
|
||||
|
||||
- **BIOS/UEFI settings**: profilový update při provisioningu (Redfish `PATCH /Systems/1/Bios`)
|
||||
- **Firmware updates**: Redfish UpdateService, SUU (Dell), SUM (HPE), SMM (Supermicro)
|
||||
- **Lifecycle Controller** (Dell LC): integrovaný OS pro firmware management
|
||||
- **Baseline management**: udržovat konzistentní firmware verze napříč fleetem
|
||||
- **Boot: UEFI vs Legacy BIOS**:
|
||||
- **UEFI**: Secure Boot, GPT, větší disky, rychlejší boot
|
||||
- **Legacy BIOS**: MBR, kompatibilita, limit 2 TB boot disk
|
||||
|
||||
## Configuration management (post-provisioning)
|
||||
|
||||
| Nástroj | Jazyk | Push/Pull | Use case |
|
||||
|---------|-------|-----------|----------|
|
||||
| **Ansible** | YAML | Push (SSH) | General config management, ad-hoc |
|
||||
| **Puppet** | Ruby DSL | Pull (agent) | State management, enterprise |
|
||||
| **Chef** | Ruby DSL | Pull (agent) | Compliance, infrastructure automation |
|
||||
| **SaltStack** | YAML/Python | Both (salt-minion) | High-speed config, event-driven |
|
||||
|
||||
Více v [CICD.md](CICD.md).
|
||||
|
||||
## Zdroje
|
||||
|
||||
Odkazy, knihy a standardy: [sources/infrastructure/sources.md](sources/infrastructure/sources.md)
|
||||
38
README.md
Normal file
38
README.md
Normal file
@@ -0,0 +1,38 @@
|
||||
# Infrastrukturní architektura — Knowledge Base
|
||||
|
||||
Přehled témat, principů a best practices pro návrh a provoz infrastruktury.
|
||||
|
||||
## Obsah
|
||||
|
||||
| Oblast | Soubor | Popis |
|
||||
|--------|--------|-------|
|
||||
| ☁️ Cloud architektura | [CLOUD.md](CLOUD.md) | AWS/Azure/GCP, hybrid cloud, multi-cloud, well-architected framework |
|
||||
| 🌐 Síťová architektura | [NETWORKING.md](NETWORKING.md) | DNS, load balancing, firewall, VPN, CDN, BGP, TCP/IP |
|
||||
| 📊 Monitoring a observabilita | [MONITORING.md](MONITORING.md) | Logging, metrics, tracing, alerting, SLI/SLO/SLA |
|
||||
| 🔄 CI/CD a DevOps | [CICD.md](CICD.md) | Pipelines, GitOps, IaC (Terraform, Pulumi), konfigurace |
|
||||
| 🗄️ Databázová architektura | [DATABASES.md](DATABASES.md) | SQL/NOSQL, sharding, replikace, caching, migrace |
|
||||
| 🖥️ Hypervisory | [HYPERVISORS.md](HYPERVISORS.md) | VMware, Hyper-V, KVM, Proxmox, virtualizační platformy |
|
||||
| 🏭 Datová centra | [DATACENTERS.md](DATACENTERS.md) | Tier klasifikace, power, cooling, Aisle containment, ASHRAE |
|
||||
| 💾 Storage | [STORAGE.md](STORAGE.md) | SAN/NAS/DAS/object, RAID, SDS, Ceph |
|
||||
| 🔧 Server hardware | [SERVER-HW.md](SERVER-HW.md) | CPU (Xeon/EPYC), RAM, PCIe, NUMA, TDP, BMC, storage controllers |
|
||||
| 🔌 Server connectivity | [CONNECTIVITY.md](CONNECTIVITY.md) | Ethernet (1-800 GbE), FC SAN, iSCSI, NVMe-oF, SAS, NIC features |
|
||||
| 🎮 GPU | [GPU.md](GPU.md) | NVIDIA/AMD GPU, NVLink, MIG/vGPU, AI training/inference |
|
||||
| ⚙️ Server config | [SERVER-CONFIG.md](SERVER-CONFIG.md) | BIOS tuning, DB/hypervisor/K8s/storage best practices |
|
||||
| 📦 Provisioning | [PROVISIONING.md](PROVISIONING.md) | PXE/iPXE, Kickstart, Redfish, Terraform, config management |
|
||||
| 📋 Původní HARDWARE | [HARDWARE.md](HARDWARE.md) | Rozděleno na SERVER-HW, GPU, SERVER-CONFIG, PROVISIONING |
|
||||
| 📋 Review workflow | [REVIEW.md](REVIEW.md) | Proces oponentury a kontroly obsahu |
|
||||
| 📝 ADR template | [templates/ADR.md](templates/ADR.md) | Architecture Decision Record template |
|
||||
|
||||
## Zdroje
|
||||
|
||||
Raw referenční data (dokumentace, knihy, standardy) podle oblastí:
|
||||
- [sources/cloud/](sources/cloud/), [sources/networking/](sources/networking/), [sources/monitoring/](sources/monitoring/)
|
||||
- [sources/cicd/](sources/cicd/), [sources/databases/](sources/databases/), [sources/infrastructure/](sources/infrastructure/)
|
||||
|
||||
## Principy
|
||||
|
||||
- **Dostupnost** — SLA, redundance, failover, multi-AZ/region
|
||||
- **Škálovatelnost** — horizontalní vs. vertikální, auto-scaling
|
||||
- **Bezpečnost** — defense in depth, least privilege, zero trust
|
||||
- **Náklady** — FinOps, right-sizing, reserved instances
|
||||
- **Operability** — observabilita, automation, dokumentace
|
||||
89
REVIEW.md
Normal file
89
REVIEW.md
Normal file
@@ -0,0 +1,89 @@
|
||||
# 📋 Review workflow — Oponentura a kontrola obsahu
|
||||
|
||||
## Proces
|
||||
|
||||
```
|
||||
Draft ──→ Self-review ──→ Peer review ──→ Approval ──→ Merged
|
||||
↑ │
|
||||
└────────────── Feedback loop ───────────────────────┘
|
||||
```
|
||||
|
||||
## Fáze
|
||||
|
||||
### 1. Draft
|
||||
|
||||
- Autor vytvoří nový obsah / upraví existující
|
||||
- Označí soubory jako `[draft]` v poznámce commit message
|
||||
- Cíl: zachytit myšlenky, strukturu a fakta
|
||||
|
||||
### 2. Self-review (autor)
|
||||
|
||||
- [ ] Je obsah **srozumitelný**? Pochopí to junior?
|
||||
- [ ] Jsou **fakta správná**? Ověřit proti sources / oficiální dokumentaci
|
||||
- [ ] Jsou uvedeny **zdroje**? (odkazy v `sources/`)
|
||||
- [ ] Je **struktura konzistentní** se zbytkem KB?
|
||||
- [ ] Jsou **zkratky** vysvětleny?
|
||||
- [ ] **Pravopis a gramatika**
|
||||
- [ ] Odpovídá **tón** — faktický, bez subjektivních názorů
|
||||
- [ ] Obsahuje **actionable best practices**, nejen teorii
|
||||
|
||||
### 3. Peer review (kolega / oponent)
|
||||
|
||||
- Autor zažádá o review (PR / issue / @mention)
|
||||
- Oponent kontroluje:
|
||||
- **Odborná správnost** — jsou data a koncepty validní?
|
||||
- **Úplnost** — není něco důležitého vynecháno?
|
||||
- **Nestrannost** — neupřednostňuje jeden vendor bezdůvodně?
|
||||
- **Aktuálnost** — nejsou informace zastaralé?
|
||||
|
||||
**Review template:**
|
||||
|
||||
```
|
||||
## Review: [název souboru]
|
||||
|
||||
### Odborná správnost
|
||||
- [ ] Fakta jsou správná
|
||||
- [ ] Doporučení jsou vhodná
|
||||
- [ ] Uvedené zdroje jsou relevantní
|
||||
|
||||
### Struktura a forma
|
||||
- [ ] Logické členění
|
||||
- [ ] Konzistentní formátování
|
||||
- [ ] Jazyk je srozumitelný
|
||||
|
||||
### Připomínky
|
||||
- [ ] [připomínka 1]
|
||||
- [ ] [připomínka 2]
|
||||
|
||||
### Verdikt
|
||||
- [ ] Schvaluji
|
||||
- [ ] Schvaluji s výhradami (viz připomínky)
|
||||
- [ ] Zamítnuto (důvod: …)
|
||||
```
|
||||
|
||||
### 4. Approval
|
||||
|
||||
- Schvaluje: autor + minimálně 1 peer reviewer
|
||||
- Po schválení se obsah považuje za `[done]`
|
||||
- Změny po schválení vyžadují nový review cyklus
|
||||
|
||||
### 5. Merged / Published
|
||||
|
||||
- Obsah je považován za aktuální a důvěryhodný
|
||||
- Pokud je zdroj označen `[done]` v `sources/`, je to potvrzení zpracování
|
||||
|
||||
## Stavy souborů
|
||||
|
||||
| Status | Význam |
|
||||
|--------|--------|
|
||||
| `[draft]` | Rozpracováno, neprošlo review |
|
||||
| `[in-review]` | Probíhá peer review |
|
||||
| `[done]` | Schváleno, aktuální |
|
||||
| `[outdated]` | Zastaralé, čeká na revizi |
|
||||
| `[deprecated]` | Nahrazeno jiným dokumentem |
|
||||
|
||||
## Pravidelná revize
|
||||
|
||||
- **Kvartálně** — kontrola aktuálnosti celé KB
|
||||
- **Trigger** — nová verze nástroje, změna architektury, EOL technologie
|
||||
- Každý soubor by měl mít v patičce **datum poslední revize**
|
||||
285
SERVER-CONFIG.md
Normal file
285
SERVER-CONFIG.md
Normal file
@@ -0,0 +1,285 @@
|
||||
# ⚙️ Server configuration — best practices podle workloadu
|
||||
|
||||
## Obecná BIOS/UEFI nastavení
|
||||
|
||||
| Nastavení | Doporučení | Zdůvodnění |
|
||||
|-----------|-----------|------------|
|
||||
| **Boot mode** | UEFI | Secure Boot, GPT, větší disky |
|
||||
| **Power profile** | Performance / OS Control | Max výkon, C-States disabled |
|
||||
| **Hyper-Threading** | Enabled | +30-50 % throughput pro multi-thread |
|
||||
| **Virtualization** | Enabled (VT-x/AMD-V) | Nutné pro hypervisor, containers |
|
||||
| **SR-IOV** | Enabled | GPU, NIC passthrough |
|
||||
| **NUMA** | Enabled | NUMA-aware scheduling |
|
||||
| **ACPI** | Enabled | Power management, OS-level |
|
||||
| **Security Boot** | Enabled | Secure boot chain |
|
||||
| **TPM** | Enabled | Measured boot, key storage |
|
||||
|
||||
---
|
||||
|
||||
## 1. Databázové servery
|
||||
|
||||
### Volba CPU
|
||||
|
||||
| DB typ | CPU preference | Zdůvodnění |
|
||||
|--------|---------------|------------|
|
||||
| **OLTP** (PostgreSQL, MySQL) | High clock, moderate cores | Nízká latence na transakci, limited parallelism |
|
||||
| **OLAP** (ClickHouse, Snowflake) | Many cores, AVX-512 | Columnstore, high parallelism |
|
||||
| **In-memory** (Redis, Memcached) | High clock, low cache latency | Single-threaded (Redis), RAM bandwidth |
|
||||
| **Document** (MongoDB) | Balance (clock × cores) | Mixed workload |
|
||||
| **Distributed** (Cassandra, Scylla) | Many cores, high cache | Shard-per-core (Scylla), compaction |
|
||||
|
||||
### Storage layout
|
||||
|
||||
```
|
||||
Mount point FS RAID Disk type Účel
|
||||
───────────── ───── ───── ────────── ──────────────────
|
||||
/ ext4 1 (mirror) 2× SSD OS, binární soubory
|
||||
/data xfs 10 (stripe) 4-8× NVMe Databázová data
|
||||
/wal xfs 1 (mirror) 2× NVMe Write-ahead log (PostgreSQL)
|
||||
/tmp tmpfs — RAM Dočasné soubory
|
||||
```
|
||||
|
||||
### PostgreSQL specific
|
||||
|
||||
| Parametr | Doporučení | Poznámka |
|
||||
|----------|-----------|----------|
|
||||
| `shared_buffers` | 25 % RAM | Cache databázových bloků |
|
||||
| `effective_cache_size` | 75 % RAM | Odhad OS cache pro query planner |
|
||||
| `work_mem` | 4-64 MB per operation | SORT, HASH JOIN (correlate s max_connections) |
|
||||
| `maintenance_work_mem` | 1-10 % RAM | VACUUM, CREATE INDEX, ANALYZE |
|
||||
| `wal_buffers` | 64-256 MB | Write-ahead log buffer |
|
||||
| `max_connections` | 50-500 | Connection pooling (PgBouncer) |
|
||||
| `random_page_cost` | 1.1 (NVMe), 4 (HDD) | Index scan cost (NVMe = téměř seq scan) |
|
||||
| `effective_io_concurrency` | 200 (NVMe), 2 (HDD) | Parallel I/O |
|
||||
|
||||
### MySQL / MariaDB specific
|
||||
|
||||
| Parametr | Doporučení | Poznámka |
|
||||
|----------|-----------|----------|
|
||||
| `innodb_buffer_pool_size` | 70-80 % RAM | Hlavní cache InnoDB |
|
||||
| `innodb_log_file_size` | 1-4 GB | Redo log, čím větší tím lepší write perf |
|
||||
| `innodb_flush_log_at_trx_commit` | 1 (ACID) / 2 (perf) | 1 = fsync každou transakci |
|
||||
| `innodb_io_capacity` | 2000 (NVMe) / 200 (HDD) | IOPS limit |
|
||||
| `innodb_write_io_threads` | 4-8 | Parallel write threads |
|
||||
| `max_connections` | 100-500 | Connection pooling doporučen |
|
||||
|
||||
### MongoDB specific
|
||||
|
||||
| Parametr | Doporučení | Poznámka |
|
||||
|----------|-----------|----------|
|
||||
| **WiredTiger cache** | 50-80 % RAM | Storage engine cache |
|
||||
| **WiredTiger compression** | Snappy / Zstd | Komprese disku (zlib je pomalý) |
|
||||
| `filesystem` | XFS | Doporučený FS (ext4 OK, NTFS ne) |
|
||||
| **ReadConcern/WriteConcern** | majority/majority | Pro důležitá data |
|
||||
|
||||
### Kernel tuning pro DB
|
||||
|
||||
```
|
||||
# /etc/sysctl.d/99-database.conf
|
||||
|
||||
vm.swappiness = 1 # Minimalizuj swap, preferuj cache
|
||||
vm.dirty_ratio = 30 # % RAM before background flush
|
||||
vm.dirty_background_ratio = 5 # Start flush at 5 %
|
||||
vm.nr_hugepages = 0 # Huge pages pokud DB podporuje (PostgreSQL, MongoDB)
|
||||
net.core.rmem_max = 134217728
|
||||
net.core.wmem_max = 134217728
|
||||
net.ipv4.tcp_rmem = 4096 87380 134217728
|
||||
net.ipv4.tcp_wmem = 4096 65536 134217728
|
||||
net.core.somaxconn = 4096
|
||||
|
||||
# I/O scheduler (NVMe = none, SSD = mq-deadline, HDD = kyber/bfq)
|
||||
# echo none > /sys/block/nvme0n1/queue/scheduler
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 2. Hypervisor host (ESXi / KVM / Hyper-V)
|
||||
|
||||
### CPU a NUMA
|
||||
|
||||
| Nastavení | Doporučení | Poznámka |
|
||||
|-----------|-----------|----------|
|
||||
| **Overcommit ratio** | 1:1 až 4:1 (vCPU:pCPU) | Podle workloadu (1:1 DB, 4:1 web) |
|
||||
| **NUMA-aware sizing** | VM ≤ 1 NUMA node | Cross-NUMA penalty ~1.5-2× latence |
|
||||
| **CPU pinning** | Dedikované VM: ano | Zamezí context switching |
|
||||
| **C-States** | Disabled (in BIOS) | Nižší latence, vyšší spotřeba |
|
||||
| **P-State** | OS control / Performance | HW power management |
|
||||
| **Hyper-Threading** | Enabled | Více vCPU, watch for noisy neighbor |
|
||||
|
||||
### Storage pro hypervisor
|
||||
|
||||
```
|
||||
VM storage:
|
||||
├── OS datastore RAID 1 (2× SATA SSD) — ESXi boot, images
|
||||
├── VM datastore (gold) RAID 10 (4× NVMe) — critical VMs, DB
|
||||
├── VM datastore (silver) RAID 5 (6× SAS SSD) — general VMs
|
||||
└── VM datastore (bronze) RAID 6 (8× SATA HDD) — backup, archive
|
||||
|
||||
Swap datastore: 1× NVMe nebo SATA SSD (dedikovaný)
|
||||
```
|
||||
|
||||
### Network design
|
||||
|
||||
| Traffic | VLAN | Speed | NIC teaming |
|
||||
|---------|------|-------|-------------|
|
||||
| **Management** | Mgmt VLAN | 1 GbE | Active/Passive |
|
||||
| **VM traffic** | VM VLANs | 25/100 GbE | LACP (802.3ad) |
|
||||
| **Storage** | Storage VLAN | 25/100 GbE | LACP / RDMA |
|
||||
| **vMotion** | vMotion VLAN | 25/100 GbE | Dedikovaný, multi-NIC |
|
||||
| **FT (Fault Tolerance)** | FT VLAN | 10 GbE | Dedikovaný, low latency |
|
||||
|
||||
### BIOS pro hypervisor
|
||||
|
||||
| Nastavení | Hodnota | Zdůvodnění |
|
||||
|-----------|---------|------------|
|
||||
| Hyper-Threading | Enabled | Vyšší VM density |
|
||||
| Virtualization Technology | Enabled | VT-x/AMD-V |
|
||||
| VT-d / IOMMU | Enabled | Passthrough, SR-IOV |
|
||||
| Power Management | Performance / OS | Minimalizace latence VM |
|
||||
| C-States | Disabled | Nižší latence VM exit |
|
||||
| NUMA | Enabled | NUMA-aware VM placement |
|
||||
| SR-IOV | Enabled | NIC/GPU virtualizace |
|
||||
|
||||
---
|
||||
|
||||
## 3. Kubernetes node
|
||||
|
||||
### Node profily
|
||||
|
||||
| Role | CPU | RAM | Storage | Network | Use case |
|
||||
|------|-----|-----|---------|---------|----------|
|
||||
| **General purpose** | 16-32 cores | 64-128 GB | 1× NVMe OS + 1×NVMe local | Web, API, microservices |
|
||||
| **Memory optimized** | 32-64 cores | 256-512 GB | 1× NVMe OS + 2×NVMe local | In-memory cache, DB |
|
||||
| **Compute optimized** | 64-128 cores | 128-256 GB | 1× NVMe OS | Batch, CI/CD |
|
||||
| **GPU node** | 32-64 cores | 512-1024 GB | 1× NVMe OS + 4-8×NVMe local | AI/ML training, inference |
|
||||
| **Storage node** | 16-32 cores | 64-128 GB | 4-12× NVMe/SATA (Ceph/Longhorn) | SDS, persistent volumes |
|
||||
|
||||
### Kernel tuning
|
||||
|
||||
```
|
||||
# /etc/sysctl.d/99-kubernetes.conf
|
||||
net.bridge.bridge-nf-call-iptables = 1
|
||||
net.bridge.bridge-nf-call-ip6tables = 1
|
||||
net.ipv4.ip_forward = 1
|
||||
net.ipv4.conf.all.forwarding = 1
|
||||
|
||||
# Connection tracking (pro NodePort, Service)
|
||||
net.netfilter.nf_conntrack_max = 2097152
|
||||
net.netfilter.nf_conntrack_tcp_timeout_established = 86400
|
||||
|
||||
# File watchers (pro kubelet, containerd)
|
||||
fs.inotify.max_user_instances = 8192
|
||||
fs.inotify.max_user_watches = 524288
|
||||
|
||||
# Memory management
|
||||
vm.swappiness = 0
|
||||
vm.overcommit_memory = 1 # Allow overcommit (CRI-O, containerd)
|
||||
vm.panic_on_oom = 0
|
||||
kernel.panic = 10
|
||||
kernel.panic_on_oops = 1
|
||||
```
|
||||
|
||||
### Container storage
|
||||
|
||||
| Typ | Doporučení | Poznámka |
|
||||
|-----|-----------|----------|
|
||||
| **OS disk** | RAID 1 (2× NVMe) | Ext4/XFS, 100-200 GB |
|
||||
| **Container runtime image** | RAID 1 (2× NVMe) | /var/lib/containerd, 200-500 GB |
|
||||
| **Local PV** | Single NVMe | Raw device, no RAID |
|
||||
| **Rook/Ceph OSD** | Raw NVMe/SATA | HBA/IT mode, no RAID |
|
||||
| **Longhorn** | Raw NVMe/SATA | Ext4/XFS per volume |
|
||||
|
||||
---
|
||||
|
||||
## 4. Storage server (Ceph / MinIO / NAS)
|
||||
|
||||
### Ceph OSD node
|
||||
|
||||
| Komponenta | Doporučení | Poznámka |
|
||||
|-----------|-----------|----------|
|
||||
| **CPU** | 1-2 cores per OSD | Do 12 OSD na node (24 cores) |
|
||||
| **RAM** | 4-8 GB per OSD + OS | BlueStore cache, 16-64 GB min |
|
||||
| **Network** | 2× 25/100 GbE | Public + Cluster network |
|
||||
| **Storage** | 10-12× NVMe/SATA SSD OSD | HBA/IT mode, žádný RAID |
|
||||
| **OS disk** | 2× SATA SSD RAID 1 | OS, Ceph MON/MGR |
|
||||
|
||||
**BIOS pro Ceph:**
|
||||
- SATA/NVMe: AHCI/NVMe mode (ne RAID)
|
||||
- C-States: Disabled (nižší latence OSD)
|
||||
- NUMA: Enabled
|
||||
- Power: Performance
|
||||
|
||||
### MinIO node
|
||||
|
||||
| Komponenta | Doporučení |
|
||||
|-----------|-----------|
|
||||
| **CPU** | 8-16 cores (32+ pro erasure coding) |
|
||||
| **RAM** | 32-64 GB + 1 GB per 1 TB storage |
|
||||
| **Storage** | 4-16× NVMe (direct, no RAID) |
|
||||
| **Network** | 2× 25/100 GbE |
|
||||
| **OS** | Ubuntu / RHEL, XFS (pro data) |
|
||||
|
||||
### NAS (TrueNAS / FreeNAS)
|
||||
|
||||
- **ZFS**: RAID-Z1/Z2/Z3, compression (lz4, zstd), dedup
|
||||
- **ARC cache**: 1 GB per 1 TB storage (max 64 GB)
|
||||
- **L2ARC**: NVMe cache (optional, read-heavy)
|
||||
- **SLOG**: NVDIMM / Optane (sync write, ZIL)
|
||||
- **Network**: 2-4× 10/25 GbE LACP
|
||||
|
||||
---
|
||||
|
||||
## 5. Web / API servery
|
||||
|
||||
| Parametr | Doporučení |
|
||||
|----------|-----------|
|
||||
| **CPU** | High clock, 8-32 cores |
|
||||
| **RAM** | 32-128 GB |
|
||||
| **Storage** | 2× NVMe RAID 1 (OS + app) |
|
||||
| **OS** | Ubuntu / RHEL, optimized kernel |
|
||||
| **Network** | 2× 10/25 GbE (bonding) |
|
||||
|
||||
**Kernel tuning:**
|
||||
```
|
||||
net.ipv4.tcp_tw_reuse = 1
|
||||
net.ipv4.tcp_fin_timeout = 15
|
||||
net.core.somaxconn = 65535
|
||||
net.ipv4.tcp_max_syn_backlog = 65535
|
||||
net.core.netdev_max_backlog = 65535
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Rychlý decision tree — výběr serveru
|
||||
|
||||
```
|
||||
Jaký workload?
|
||||
│
|
||||
├── Databáze (OLTP)
|
||||
│ → EPYC, high clock, 8-16 GB/core, RAID10 NVMe, huge pages
|
||||
│
|
||||
├── Databáze (OLAP)
|
||||
│ → Xeon AMX/AVX-512, 16-64 GB/core, many cores
|
||||
│
|
||||
├── Virtualizace
|
||||
│ → EPYC, many cores, 4-8 GB/core, shared storage (SAN/NFS/vSAN)
|
||||
│
|
||||
├── Kubernetes
|
||||
│ → EPYC, balance, 2-4 GB/core, local NVMe
|
||||
│
|
||||
├── AI/ML training
|
||||
│ → GPU node (H100/B200), NVLink, InfiniBand, liquid cooling
|
||||
│
|
||||
├── AI/ML inference
|
||||
│ → A100/H200, MIG, large VRAM, PCIe 5.0
|
||||
│
|
||||
├── Storage (Ceph/SDS)
|
||||
│ → EPYC (PCIe lanes), HBA mode, 4-8 GB/OSD
|
||||
│
|
||||
└── Web / API
|
||||
→ EPYC, high clock, 2-4 GB/core, 10 GbE
|
||||
|
||||
## Zdroje
|
||||
|
||||
Odkazy, knihy a standardy: [sources/infrastructure/sources.md](sources/infrastructure/sources.md)
|
||||
```
|
||||
329
SERVER-HW.md
Normal file
329
SERVER-HW.md
Normal file
@@ -0,0 +1,329 @@
|
||||
# 🔧 Server hardware — komponenty a architektura
|
||||
|
||||
## Form faktory
|
||||
|
||||
| Typ | Popis | Výhody | Nevýhody |
|
||||
|-----|-------|--------|----------|
|
||||
| **Rack (1U/2U/4U)** | Standardní rack mount, šířka 19" | Široká škála konfigurací, jednoduchá výměna | Omezený počet PCIe slotů v 1U |
|
||||
| **Blade** | Modulární server do chassis (HPE Synergy, Dell MX) | Vysoká hustota, sdílené napájení/chlazení | Vendor lock-in, vyšší cena chassis |
|
||||
| **Tower** | Samostatně stojící skříň | Tichý, rozšiřitelný | Zabírá místo, není rack-optimized |
|
||||
| **Edge / Micro** | Malý, nízká spotřeba, industriální provedení | Odolnost vůči prostředí, nízký odběr | Omezený výkon, méně PCIe |
|
||||
|
||||
## Procesory (CPU)
|
||||
|
||||
### Intel Xeon vs AMD EPYC
|
||||
|
||||
| Vlastnost | Intel Xeon (6. gen Granite Rapids) | AMD EPYC (5. gen Turin) |
|
||||
|-----------|-----------------------------------|------------------------|
|
||||
| **Max jader** | 128 (P-cores) | 192 (Zen 5c) / 128 (Zen 5) |
|
||||
| **PCIe lanes** | 80-96 per socket | 128 per socket |
|
||||
| **Memory channels** | 8 (DDR5) | 12 (DDR5) |
|
||||
| **Max memory** | 4 TB | 6 TB+ |
|
||||
| **Cache L3** | ~200 MB | ~384 MB |
|
||||
| **AVX-512** | Ano (full width) | Ano (256bit) |
|
||||
| **AMX (matrix)** | Ano (AMX, Intel AMX) | Ne |
|
||||
| **TDP** | 350-500 W | 360-500 W |
|
||||
| **Infrastructure** | Intel QuickAssist, DSA, IAA | AMD Infinity Architecture |
|
||||
| **Use case** | AI inference, networking, HPC | Virtualizace, databáze, general purpose |
|
||||
|
||||
### CPU selection guide
|
||||
|
||||
| Workload | Doporučený CPU | Zdůvodnění |
|
||||
|----------|---------------|------------|
|
||||
| **Databáze (OLTP)** | EPYC (high core count, more memory channels) | Více PCIe lanes pro NVMe, vyšší memory bandwidth |
|
||||
| **Databáze (OLAP/DW)** | Xeon (AVX-512, AMX) | Vektorové instrukce pro analytické dotazy |
|
||||
| **Virtualizace** | EPYC (více jader, nižší TCO) | Vyšší core density, nižší cena per core |
|
||||
| **HPC / AI training** | Xeon + GPU (AMX pro preprocessing) | AMX pro data preprocessing, GPU pro training |
|
||||
| **Web / API servery** | EPYC (good perf/core, low TDP variants) | Dobrý poměr výkon/W |
|
||||
| **Storage** | EPYC (128 PCIe lanes pro NVMe) | Maximum NVMe disků |
|
||||
|
||||
## Operační paměť (RAM)
|
||||
|
||||
### Typy DIMM
|
||||
|
||||
| Typ | Popis | Use case | Server support |
|
||||
|-----|-------|----------|---------------|
|
||||
| **RDIMM** (Registered) | Registrovaná, buffer adresových linek (1 register) | Standardní serverová paměť | Všechny servery |
|
||||
| **LRDIMM** (Load-Reduced) | Snížená elektrická zátěž (2 registry — data + adresy) | Vysokokapacitní konfigurace (více DIMMů na channel) | Enterprise, 4R+ |
|
||||
| **NVDIMM** (Non-Volatile) | Bateriově zálohovaná DRAM + flash | Write cache, metadata, persistence | Legacy (Intel Optane PMEM) |
|
||||
| **3D XPoint / Optane** | PCM-based persistence (ukončeno Intelem) | Legacy | Intel-only, ukončeno |
|
||||
|
||||
### DDR5 vs DDR4 klíčové rozdíly
|
||||
|
||||
| Vlastnost | DDR4 | DDR5 |
|
||||
|-----------|------|------|
|
||||
| **Channel architektura** | 1× 64-bit channel per DIMM | 2× 32-bit sub-channel per DIMM |
|
||||
| **Bank groups** | 4 (single rank) | 8 (single rank) |
|
||||
| **Burst length** | 8 (BL8) | 16 (BL16) |
|
||||
| **On-die ECC** | Ne | Ano (pro opravu bitových chyb v DRAM) |
|
||||
| **PMIC** | Na motherboard | Na DIMM (power management IC) |
|
||||
| **VDD** | 1.2 V | 1.1 V |
|
||||
| **RCD** | 1× RCD per DIMM | 2× RCD (jeden na sub-channel) |
|
||||
| **Max DIMM capacity** | 64 GB (LRDIMM) | 256 GB (RDIMM 3DS) |
|
||||
| **Max speed** | 3200 MT/s | 6400 MT/s (aktuálně 4800-5600) |
|
||||
|
||||
### Memory rank — detail
|
||||
|
||||
Rank = sada DRAM čipů na DIMMu, které jsou přístupné současně (64bit data + 8bit ECC).
|
||||
|
||||
| Rank | Počet DRAM čipů (x8) | Kapacita DIMM (typ.) | Popis |
|
||||
|------|---------------------|---------------------|-------|
|
||||
| **Single Rank (1R)** | 8-9 | 8-32 GB | Všechny DRAM čipy v jedné bance |
|
||||
| **Dual Rank (2R)** | 16-18 | 16-128 GB | Dvě banky, rank interleaving |
|
||||
| **Quad Rank (4R)** | 32-36 | 64-256 GB (3DS) | Čtyři banky, vyšší kapacita |
|
||||
| **Octa Rank (8R)** | 64-72 | 256 GB (3DS) | Nejvyšší kapacita, enterprise |
|
||||
|
||||
**Rank interleaving**: Dual-rank DIMM může oslovovat dva ranking střídavě, což zvyšuje efektivní bandwidth (až o 5-15 % oproti single-rank při stejném taktu).
|
||||
|
||||
**DDR5 rank vs DDR4**: DDR5 single-rank již obsahuje 8 bank groups (ekvivalent dual-rank DDR4), proto je rank upgrade u DDR5 méně výrazný než u DDR4.
|
||||
|
||||
**Pravidlo**: Vždy preferovat dual-rank DIMMy před single-rank pro vyšší hustotu a bandwidth. Quad-rank a octa-rank pouze LRDIMM nebo 3DS.
|
||||
|
||||
### Osazování DIMM — základní pravidla
|
||||
|
||||
#### 1DPC vs 2DPC (DIMMs Per Channel)
|
||||
|
||||
| Konfigurace | DIMMů na channel | Max speed DDR5 | Bandwidth | Kapacita |
|
||||
|------------|-----------------|---------------|-----------|----------|
|
||||
| **1DPC** | 1 | 4800-5600 MT/s | 100 % | Nižší |
|
||||
| **2DPC** | 2 | 4000-4400 MT/s | ~80 % | Vyšší |
|
||||
|
||||
**Důležité**: Při osazení 2 DIMMů na channel klesá rychlost pamětí. Např. Dell R760:
|
||||
- 1DPC: 5600 MT/s (s 5th Gen Xeon)
|
||||
- 2DPC: 4400 MT/s (vždy)
|
||||
|
||||
#### Channel architecture (Intel Xeon 4th/5th Gen — 8 channels per CPU)
|
||||
|
||||
```
|
||||
CPU 1 — Channel A [Slot A1 (white)] [Slot A9 (black)] 1DPC: osadit bílé sloty
|
||||
─ Channel B [Slot A7 (white)] [Slot A15 (black)] 2DPC: osadit bílé + černé
|
||||
─ Channel C [Slot A3 (white)] [Slot A11 (black)]
|
||||
─ Channel D [Slot A5 (white)] [Slot A13 (black)]
|
||||
─ Channel E [Slot A4 (white)] [Slot A12 (black)]
|
||||
─ Channel F [Slot A6 (white)] [Slot A14 (black)]
|
||||
─ Channel G [Slot A2 (white)] [Slot A10 (black)]
|
||||
─ Channel H [Slot A8 (white)] [Slot A16 (black)]
|
||||
```
|
||||
|
||||
#### Channel architecture (AMD EPYC — 12 channels per CPU)
|
||||
|
||||
```
|
||||
CPU 1 ─ Channel 0-11 (12× single channel, 2 DPC)
|
||||
Slot A0 (P0) / Slot A1 (P1) — dle konkrétního serveru
|
||||
```
|
||||
|
||||
AMD EPYC má 12 memory channels (vs Intel 8), což dává o 50 % vyšší teoretickou memory bandwidth.
|
||||
|
||||
### Pravidla osazování od výrobců
|
||||
|
||||
#### Dell PowerEdge (R660 / R760)
|
||||
|
||||
| Počet DIMMů na CPU | 1DPC (bílé sloty) | 2DPC (bílé + černé) | Speed |
|
||||
|-------------------|-------------------|---------------------|-------|
|
||||
| **1 DIMM per CPU** | A1 (Channel A) | — | 5600 MT/s |
|
||||
| **2 DIMMs per CPU** | A1, A7 | — | 5600 MT/s |
|
||||
| **4 DIMMs per CPU** | A1, A7, A3, A5 | — | 5600 MT/s |
|
||||
| **8 DIMMs per CPU** | A1-A8 (všechny bílé) | — | 5600 MT/s |
|
||||
| **16 DIMMs per CPU** | A1-A8 (bílé) | A9-A16 (černé) | 4400 MT/s |
|
||||
|
||||
**Klíčová pravidla dle Dell**:
|
||||
1. Všechny DIMMy musí být DDR5 (nemíchat generace)
|
||||
2. Nemíchat kapacity DIMMů (všechny stejné)
|
||||
3. Nemíchat x4 a x8 DRAM chips
|
||||
4. Nemíchat 3DS a non-3DS RDIMM
|
||||
5. Pokud mícháte rychlosti DIMMů, všechny běží na nejnižší
|
||||
6. Vyvážit kapacitu mezi procesory
|
||||
7. Optimální konfigurace: 16× identický DIMM (1DPC na každém channelu)
|
||||
8. Fault Resilient Memory (FRM): pouze 8 nebo 16 DIMMů na procesor
|
||||
|
||||
#### HPE ProLiant (DL360 / DL380 Gen11)
|
||||
|
||||
**Population order** (16 slotů na CPU, Intel):
|
||||
|
||||
| DIMMů | Pořadí osazení |
|
||||
|-------|---------------|
|
||||
| 1 | 10 |
|
||||
| 2 | 1, 3 |
|
||||
| 4 | 1, 3, 7, 10 |
|
||||
| 6 | 3, 5, 7, 10, 14, 16 |
|
||||
| 8 | 1, 3, 5, 7, 10, 12, 14, 16 |
|
||||
| 12 | 1, 2, 3, 5, 6, 7, 10, 11, 12, 14, 15, 16 |
|
||||
| 16 | 1-16 |
|
||||
|
||||
**Pravidla HPE SmartMemory**:
|
||||
1. Nejkvalifikovanější konfigurace: 1DPC (bílé sloty)
|
||||
2. 2DPC (černé sloty) až po osazení všech bílých
|
||||
3. HBM + 4th Gen Intel: nepodporuje Hemi (hemisphere) a SGX
|
||||
4. Heterogenní mix: vyšší rank count do bílých slotů
|
||||
5. **Nemíchat**: 3DS s non-3DS, x4 s x8, různé ranky v channelu, 16 Gb / 24 Gb / 32 Gb DRAM
|
||||
|
||||
### Memory population — decision flow
|
||||
|
||||
```
|
||||
Kolik DIMMů na CPU?
|
||||
│
|
||||
├── 1 DIMM → Channel A (slot 1), ztrácíte 87.5 % bandwidth
|
||||
│
|
||||
├── 2 DIMMs → Channels A+B, stále ztráta 75 % bandwidth
|
||||
│
|
||||
├── 4 DIMMs → Channels A,B,C,D, lepší, ale ne optimální
|
||||
│
|
||||
├── 8 DIMMs → 1DPC na všech channel = MAX SPEED (5600 MT/s)
|
||||
│ ✅ Doporučeno pro výkon
|
||||
│
|
||||
├── 12 DIMMs → 8× 1DPC + 4× 2DPC = mixed speed (4400 MT/s)
|
||||
│
|
||||
├── 16 DIMMs → 2DPC na všech channel = MAX KAPACITA (4400 MT/s)
|
||||
│ ✅ Pro kapacitně náročné workloady
|
||||
│
|
||||
└── Více než 16 → Pouze s LRDIMM / 3DS, speed penalty
|
||||
|
||||
Závěr: 8 DIMMů na CPU (1DPC) = nejvyšší výkon
|
||||
16 DIMMů na CPU (2DPC) = nejvyšší kapacita
|
||||
```
|
||||
|
||||
### Vliv konfigurace na výkon
|
||||
|
||||
| Konfigurace | Relativní bandwidth | Latence | Use case |
|
||||
|------------|-------------------|---------|----------|
|
||||
| **1DPC, 8 ch, 5600 MT/s** (8 DIMM) | 100 % | Nejnižší | Databáze OLTP, HPC, real-time |
|
||||
| **2DPC, 8 ch, 4400 MT/s** (16 DIMM) | ~78 % | +10-15 % | Virtualizace, VDI, in-memory DB |
|
||||
| **Mixed 1+2DPC** (12 DIMM) | ~85 % | Střední | Kompromis kapacity/výkonu |
|
||||
| **Unbalanced channels** | 50-70 % | Vysoká | **Vyhnout se** |
|
||||
|
||||
**Doporučení výrobců:**
|
||||
- **Dell**: 16× identických DIMMů (8 per CPU), 1DPC, 5600 MT/s = optimální výkon
|
||||
- **HPE**: Vždy plnit bílé sloty první, pro max výkon 1DPC, pro max kapacitu 2DPC
|
||||
- **Supermicro**: Sledovat konkrétní manual pro daný model (DSG, GPU, storage)
|
||||
- **Lenovo**: Stejná pravidla jako Intel/AMD platforma — preferovat 1DPC
|
||||
|
||||
### Memory sizing per workload
|
||||
|
||||
| Workload | Poměr RAM/core | Typický pool | Doporučená konfigurace |
|
||||
|----------|---------------|--------------|----------------------|
|
||||
| Databáze (OLTP) | 8-16 GB/core, DB v RAM | 256 GB - 2 TB | 8× 32-64 GB RDIMM, 1DPC |
|
||||
| Databáze (OLAP) | 16-64 GB/core, columnstore | 512 GB - 4 TB+ | 16× 64-128 GB RDIMM, 2DPC |
|
||||
| Virtualizace (VM) | 4-8 GB/core, podle VM density | 256 GB - 2 TB | 8-16× 32-64 GB RDIMM |
|
||||
| Kubernetes (general) | 2-4 GB/core | 64-256 GB | 8× 16-32 GB RDIMM, 1DPC |
|
||||
| AI training (CPU preprocessing) | 2-4 GB/core | 128-512 GB | 8× 32-64 GB RDIMM, 1DPC |
|
||||
| HPC | 1-2 GB/core | 64-128 GB | 8× 16 GB RDIMM, 1DPC, high-speed |
|
||||
| In-memory DB (SAP HANA) | 8-32 GB/core | 1-6 TB+ | 16× 128-256 GB LRDIMM/3DS |
|
||||
|
||||
## PCIe
|
||||
|
||||
| Generace | Rok | Rychlost per lane | x16 propustnost | x24 (GPU) |
|
||||
|----------|-----|-------------------|-----------------|-----------|
|
||||
| **PCIe 3.0** | 2010 | 985 MB/s | 15.8 GB/s | 23.6 GB/s |
|
||||
| **PCIe 4.0** | 2017 | 1.97 GB/s | 31.5 GB/s | 47.3 GB/s |
|
||||
| **PCIe 5.0** | 2022 | 3.94 GB/s | 63 GB/s | 94.5 GB/s |
|
||||
| **PCIe 6.0** | 2025 | 7.88 GB/s | 126 GB/s | 189 GB/s |
|
||||
|
||||
**PCIe lane allocation**:
|
||||
- GPU (x16): NVIDIA H100, AMD MI300X
|
||||
- NVMe U.2 (x4): každý NVMe disk
|
||||
- NIC 100 GbE (x16): dual-port 100 GbE
|
||||
- RAID/HBA (x8): storage controller
|
||||
|
||||
**CPU PCIe lane count**:
|
||||
- Intel Xeon Scalable (4. gen): 64-80 lanes per socket
|
||||
- AMD EPYC (4. gen Genoa): 128 lanes per socket
|
||||
- Dual-socket: 256 lanes total
|
||||
|
||||
## NUMA
|
||||
|
||||
### Topologie
|
||||
|
||||
```
|
||||
Socket 0 (NUMA node 0) Socket 1 (NUMA node 1)
|
||||
├── Cores 0-31 ├── Cores 32-63
|
||||
├── Memory 0-256 GB ├── Memory 256-512 GB
|
||||
├── PCIe root complex (GPU, NVMe) ├── PCIe root complex (NIC, NVMe)
|
||||
└── I/O hub └── I/O hub
|
||||
│ │
|
||||
└───────── Infinity Fabric / UPI ──┘
|
||||
```
|
||||
|
||||
- **Local access** — CPU → vlastní memory (nízká latence, plná bandwidth)
|
||||
- **Remote access** — CPU → druhý socket memory (vyšší latence, ~1.5×, nižší bandwidth)
|
||||
- NUMA-aware aplikace: databáze, VM, DPDK, AI training
|
||||
|
||||
### Cross-NUMA penalty
|
||||
|
||||
| CPU | Local latency | Remote latency | Penalty |
|
||||
|-----|--------------|----------------|---------|
|
||||
| AMD EPYC (Genoa) | ~80 ns | ~150 ns | ~1.9× |
|
||||
| Intel Xeon (Sapphire Rapids) | ~90 ns | ~160 ns | ~1.8× |
|
||||
|
||||
## TDP a chlazení
|
||||
|
||||
| CPU | TDP | Core count | Chlazení |
|
||||
|-----|-----|-----------|----------|
|
||||
| Intel Xeon Platinum 8480+ | 350 W | 56 | Air (high-performance) |
|
||||
| Intel Xeon 6980P (Granite Rapids) | 500 W | 128 | Liquid recommended |
|
||||
| AMD EPYC 9654 (Genoa) | 360 W | 96 | Air / Liquid |
|
||||
| AMD EPYC 9965 (Turin) | 500 W | 192 | Liquid recommended |
|
||||
|
||||
### Cooling requirements per rack density
|
||||
|
||||
| Rack density | kW/rack | Cooling |
|
||||
|-------------|---------|---------|
|
||||
| Low | 1-5 kW | Free air cooling |
|
||||
| Medium | 5-15 kW | CRAC/CRAH, hot/cold aisle |
|
||||
| High | 15-40 kW | In-row cooling, rear-door HX |
|
||||
| Ultra | 40-100+ kW | Direct-to-chip liquid, immersion |
|
||||
|
||||
## BMC a management
|
||||
|
||||
| Vendor | BMC | API | Remote console | Features |
|
||||
|--------|-----|-----|---------------|----------|
|
||||
| **Dell** | iDRAC (9/10) | Redfish, RACADM | Virtual Console (HTML5) | Lifecycle Controller, SUU |
|
||||
| **HPE** | iLO (5/6) | Redfish, iLOREST | Integrated Remote Console | Smart Update Manager, SUM |
|
||||
| **Supermicro** | BMC / IPMI | IPMI, Redfish | IPMIView, HTML5 KVM | SuperDoctor, SSM |
|
||||
| **Lenovo** | XClarity Controller | Redfish, IPMI | Remote Console | XClarity Administrator |
|
||||
| **Cisco** | CIMC / UCSM | Redfish, XML API | KVM Console | UCS Manager, Intersight |
|
||||
|
||||
### Standardní funkce
|
||||
- Power: on/off/cycle/reset
|
||||
- Boot: one-shot PXE, CD-ROM redirect, BIOS setup
|
||||
- Monitoring: sensors (temp, voltage, fan, PSU)
|
||||
- Alerting: SNMP traps, email, Redfish events
|
||||
- Remote media: ISO mount přes network
|
||||
- Serial over LAN (SOL)
|
||||
|
||||
## Výrobci a řady
|
||||
|
||||
| Výrobce | Rack series | Blade series | Management |
|
||||
|---------|-------------|-------------|------------|
|
||||
| **Dell** | PowerEdge R6xx/R7xx (R660, R760) | MX7000, FX2 | iDRAC, OpenManage Enterprise |
|
||||
| **HPE** | ProLiant DL (DL360, DL380) | Synergy, BladeSystem | iLO, OneView, OpsRamp |
|
||||
| **Cisco** | UCS C-Series (C240, C245) | UCS B-Series, Fabric Interconnect | UCS Manager, Intersight |
|
||||
| **Lenovo** | ThinkSystem SR (SR630, SR650) | ThinkSystem SN | XClarity |
|
||||
| **Supermicro** | SuperServer (pro GPU, storage, cloud) | FatTwin, MicroBlade | IPMI, SuperDoctor |
|
||||
|
||||
## Server connectivity
|
||||
|
||||
Detailní kapitola o síťové a storage konektivitě: [CONNECTIVITY.md](CONNECTIVITY.md)
|
||||
|
||||
## Storage controllers
|
||||
|
||||
| Controller | Typ | RAID | Cache | Protokol |
|
||||
|-----------|-----|------|-------|----------|
|
||||
| **Dell PERC** (H755, H965) | HW RAID | 0/1/5/6/10/50/60 | 4-8 GB NV | NVMe, SAS, SATA |
|
||||
| **Broadcom / LSI** (9560, 9670) | HW RAID / HBA | 0/1/5/6/10/50/60 | 4 GB NV | NVMe, SAS, SATA |
|
||||
| **Intel VROC** | SW RAID (CPU) | 0/1/5/10 | — | NVMe only |
|
||||
| **M.2 HW RAID** (BOSS-S1) | HW RAID | 0/1 | — | 2× M.2 NVMe/SATA |
|
||||
|
||||
### IT vs HW RAID mode
|
||||
|
||||
| Vlastnost | IT (Initiator Target) / HBA | HW RAID |
|
||||
|-----------|---------------------------|---------|
|
||||
| **OS vidí** | Každý disk samostatně | RAID virtuální disk |
|
||||
| **Caching** | OS cache | RAID controller cache (BBU) |
|
||||
| **RAID** | Software (mdadm, ZFS, Ceph) | Hardware + SW driver |
|
||||
| **Passthrough** | Ano | Ne |
|
||||
| **Use case** | SDS (Ceph, MinIO), ZFS | VMware VMFS, Windows, legacy |
|
||||
| **Battery/Backup** | Není potřeba | Write-back cache vyžaduje BBU |
|
||||
|
||||
## Zdroje
|
||||
|
||||
Odkazy, knihy a standardy: [sources/infrastructure/sources.md](sources/infrastructure/sources.md)
|
||||
90
STORAGE.md
Normal file
90
STORAGE.md
Normal file
@@ -0,0 +1,90 @@
|
||||
# 💾 Storage infrastruktura
|
||||
|
||||
## Typy úložišť
|
||||
|
||||
| Typ | Popis | Latence | Use case |
|
||||
|-----|-------|---------|----------|
|
||||
| **DAS** (Direct Attached) | Disky přímo v serveru | <0.1 ms | OS, cache, lokální data |
|
||||
| **SAN** (Storage Area Network) | Bloková zařízení po síti | <1 ms | Databáze, VM datastory |
|
||||
| **NAS** (Network Attached Storage) | Souborový přístup (NFS, SMB) | 1-3 ms | Sdílené soubory, home dirs |
|
||||
| **Object storage** | REST API, flat namespace | 10-100 ms | Zálohy, media, big data |
|
||||
|
||||
## Protokoly
|
||||
|
||||
| Protokol | Typ | Rychlost | Poznámka |
|
||||
|----------|-----|----------|----------|
|
||||
| **Fibre Channel** | SAN | 8/16/32/64 Gbps | Nízká latence, dedikovaná síť |
|
||||
| **iSCSI** | SAN (IP) | 1/10/25 GbE | Levnější, po ethernetu |
|
||||
| **NVMe-oF** | SAN (NVMe) | 25/50/100 GbE | Nejnižší latence, emerging |
|
||||
| **NFS** | NAS | 1/10/25 GbE | Univerzální, jednoduchý |
|
||||
| **SMB/CIFS** | NAS | 1/10/25 GbE | Windows native |
|
||||
| **S3 API** | Object | — | Standard pro object storage |
|
||||
|
||||
## RAID
|
||||
|
||||
| RAID | Min. disků | Kapacita | Ochrana | Rychlost čtení | Rychlost zápisu | Use case |
|
||||
|------|-----------|----------|---------|---------------|----------------|----------|
|
||||
| **0** | 2 | 100 % | Žádná | N × (striping) | N × | Temp data, cache (risky) |
|
||||
| **1** | 2 | 50 % | 1 disk | N × (mirror) | 1 × | OS disk, kritická data |
|
||||
| **5** | 3 | 67-94 % | 1 disk | N-1 × | N-1 × (parity write penalty) | Univerzální file/VM storage |
|
||||
| **6** | 4 | 50-88 % | 2 disky | N-2 × | N-2 × (double parity) | Velké kapacity, důležitá data |
|
||||
| **10** | 4 | 50 % | 1/mirror | N × | N/2 × | Databáze, VM, high-performance |
|
||||
| **50** | 6 | 67-94 % | 1/stripe | N-1 × | N-1 × | Large capacity + performance |
|
||||
| **60** | 8 | 50-88 % | 2/stripe | N-2 × | N-2 × | Enterprise |
|
||||
|
||||
### Stripe size
|
||||
|
||||
- Malý stripe (16-64 KB) — lepší IOPS, horší throughput (databáze, OLTP)
|
||||
- Velký stripe (128-1024 KB) — lepší throughput, horší IOPS (video, media, backup)
|
||||
- Write hole u RAID 5/6: při výpadku během zápisu parity je metadata nekonzistentní (prevence: non-volatile cache, battery-backed RAID controller)
|
||||
|
||||
## Software-Defined Storage (SDS)
|
||||
|
||||
| Nástroj | Typ | Use case |
|
||||
|---------|-----|----------|
|
||||
| **Ceph** | Object/Block/File (RADOS) | Univerzální SDS, OpenStack, Kubernetes |
|
||||
| **MinIO** | Object (S3 API) | High-performance S3, AI/ML data lake |
|
||||
| **GlusterFS** | Distributed File | Shared filesystem, POSIX |
|
||||
| **Longhorn** | Block (Kubernetes) | K8s PVC, mikroservisy |
|
||||
| **Linstor** | Block (DRBD + LVM) | Linux SDS, Kubernetes |
|
||||
| **VMware vSAN** | Block (HCI) | VMware ecosystem |
|
||||
| **StarWind** | Block (HCI) | Hyper-V / VMware |
|
||||
|
||||
### Ceph
|
||||
|
||||
**Architektura**:
|
||||
|
||||
```
|
||||
RADOS (Reliable Autonomic Distributed Object Store)
|
||||
├── Monitors (MON) — cluster map, quorum (3/5)
|
||||
├── Managers (MGR) — dashboard, balancer, orchestrator
|
||||
├── OSDs (Object Storage Daemons) — data + replikace
|
||||
└── MDS (Metadata Server) — pouze pro CephFS
|
||||
```
|
||||
|
||||
**CRUSH map** (Controlled Replication Under Scalable Hashing):
|
||||
|
||||
- Algoritmus pro výpočet umístění dat (žádný centrální index)
|
||||
- Vrstvy: Root → Datacenter → Rack → Host → OSD
|
||||
- Failure domain: replikace napříč racky / hosty
|
||||
- `ceph osd crush rule create-replicated replicated_rule default host`
|
||||
|
||||
**Přístupová rozhraní**:
|
||||
|
||||
| Rozhraní | Typ | Use case |
|
||||
|----------|-----|----------|
|
||||
| **RBD** (RADOS Block Device) | Block | VM images, Kubernetes PVC (csi-rbd) |
|
||||
| **RGW** (RADOS Gateway) | Object (S3/Swift API) | S3-kompatibilní storage, backup |
|
||||
| **CephFS** | File (POSIX) | Shared filesystem, home dirs |
|
||||
| **NFS-Ganesha** | File (NFS) | NFS export přes CephFS |
|
||||
|
||||
**Erasure coding**:
|
||||
|
||||
- K+M (data + parity chunks), např. 8+3 (8 data, 3 parity)
|
||||
- Prostorově efektivnější než 3× replikace (1.375× vs 3×)
|
||||
- Vyšší CPU režie, nižší IOPS
|
||||
- Doporučeno pro cold data (RGW) místo replikace
|
||||
|
||||
## Zdroje
|
||||
|
||||
Odkazy, knihy a standardy: [sources/infrastructure/sources.md](sources/infrastructure/sources.md)
|
||||
BIN
sources/.DS_Store
vendored
Normal file
BIN
sources/.DS_Store
vendored
Normal file
Binary file not shown.
21
sources/README.md
Normal file
21
sources/README.md
Normal file
@@ -0,0 +1,21 @@
|
||||
# Raw zdroje — Immutable reference data
|
||||
|
||||
Tento adresář obsahuje nespracovaná referenční data (odkazy, knihy, standardy, RFC), ze kterých knowledge base vychází.
|
||||
|
||||
**Pravidla:**
|
||||
- Obsah je **immutable** — po přidání se nemění (pouze append)
|
||||
- Zdroj označujeme tagem `[done]` pokud je již zpracován do KB
|
||||
- Každá oblast má vlastní `sources.md`
|
||||
|
||||
## Struktura
|
||||
|
||||
```
|
||||
sources/
|
||||
├── README.md
|
||||
├── cloud/
|
||||
├── networking/
|
||||
├── monitoring/
|
||||
├── cicd/
|
||||
├── databases/
|
||||
└── infrastructure/
|
||||
```
|
||||
35
sources/cicd/sources.md
Normal file
35
sources/cicd/sources.md
Normal file
@@ -0,0 +1,35 @@
|
||||
# CI/CD a DevOps — Zdroje
|
||||
|
||||
## Oficiální dokumentace
|
||||
|
||||
| Zdroj | URL | Status |
|
||||
|-------|-----|--------|
|
||||
| Terraform docs | https://developer.hashicorp.com/terraform/docs | `[done]` |
|
||||
| ArgoCD docs | https://argo-cd.readthedocs.io/ | `[done]` |
|
||||
| Flux docs | https://fluxcd.io/flux/ | `[done]` |
|
||||
| GitHub Actions docs | https://docs.github.com/en/actions | `[done]` |
|
||||
| GitLab CI docs | https://docs.gitlab.com/ee/ci/ | `[done]` |
|
||||
|
||||
## Knihy
|
||||
|
||||
| Název | Autor | ISBN | Status |
|
||||
|-------|-------|------|--------|
|
||||
| The DevOps Handbook | Kim, Humble, Debois, Willis | 978-1942788003 | `[done]` |
|
||||
| Infrastructure as Code (2nd ed.) | Kief Morris | 978-1098114671 | `[todo]` |
|
||||
| Terraform: Up and Running (3rd ed.) | Yevgeniy Brikman | 978-1098166045 | `[todo]` |
|
||||
| Continuous Delivery | Humble, Farley | 978-0321601912 | `[done]` |
|
||||
|
||||
## Standardy
|
||||
|
||||
| Standard | Popis | Status |
|
||||
|----------|-------|--------|
|
||||
| 12 Factor App | https://12factor.net/ | `[done]` |
|
||||
| CNCF Cloud Native Landscape | https://landscape.cncf.io/ | `[done]` |
|
||||
|
||||
## Nové knihy (2024–2026)
|
||||
|
||||
| Název | Autor | ISBN | Status |
|
||||
|-------|-------|------|--------|
|
||||
| CI/CD Design Patterns | Bajpai, Schildmeijer, Piwosz, Mishra | 978-1-83588-965-7 | `[done]` |
|
||||
| AI-Native Software Delivery | Durkin, Minick, Gaikwad | — (O'Reilly, 2025) | `[done]` |
|
||||
| DevOps Frameworks, Techniques, and Tools | Vijayakumaran, Kofler, Öggl, Springer | 978-1-4932-2670-2 | `[done]` |
|
||||
37
sources/cloud/sources.md
Normal file
37
sources/cloud/sources.md
Normal file
@@ -0,0 +1,37 @@
|
||||
# Cloud architektura — Zdroje
|
||||
|
||||
## Oficiální dokumentace
|
||||
|
||||
| Zdroj | URL | Status |
|
||||
|-------|-----|--------|
|
||||
| AWS Well-Architected Framework | https://docs.aws.amazon.com/wellarchitected/latest/framework/ | `[done]` |
|
||||
| Azure Well-Architected Framework | https://learn.microsoft.com/en-us/azure/well-architected/ | `[done]` |
|
||||
| Google Cloud Architecture Framework | https://cloud.google.com/architecture/framework | `[done]` |
|
||||
| AWS Multi-AZ / Multi-Region whitepaper | https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/ | `[done]` |
|
||||
|
||||
## Knihy
|
||||
|
||||
| Název | Autor | ISBN | Status |
|
||||
|-------|-------|------|--------|
|
||||
| Cloud Architecture Patterns | Bill Wilder | 978-1449319779 | `[todo]` |
|
||||
| Building Evolutionary Architectures | Ford, Parsons, Kua | 978-1492097549 | `[todo]` |
|
||||
|
||||
## Nové knihy (2024–2026)
|
||||
|
||||
| Název | Autor | ISBN | Status |
|
||||
|-------|-------|------|--------|
|
||||
| Multi-Cloud Administration Guide | — | 978-1-5015-1948-2 | `[todo]` |
|
||||
| AWS for Solutions Architects (3rd ed.) | Shrivastava, Srivastav, Thakur | 978-1-83664-193-3 | `[todo]` |
|
||||
| Engineering Resilient Systems on AWS | Schwarz, Moran, Bachmeier | 978-1-098-16241-2 | `[todo]` |
|
||||
| Building Resilient Architectures on AWS | — | 978-1-83588-711-0 | `[todo]` |
|
||||
| Multi-Cloud Handbook for Developers | Natarajan, Jacob | 978-1-80461-709-0 | `[todo]` |
|
||||
| The Azure Cloud Native Architecture Mapbook (2nd ed.) | Stéphane Eyskens | 978-1-80580-505-2 | `[todo]` |
|
||||
| Cloud Computing: AWS, Azure, and Google Cloud | Azhar ul Haque Sario | 978-3384756886 | `[todo]` |
|
||||
|
||||
## Certifikace
|
||||
|
||||
| Certifikace | Oblast |
|
||||
|-------------|--------|
|
||||
| AWS Solutions Architect — Associate | AWS |
|
||||
| Azure Solutions Architect Expert | Azure |
|
||||
| Google Professional Cloud Architect | GCP |
|
||||
34
sources/databases/sources.md
Normal file
34
sources/databases/sources.md
Normal file
@@ -0,0 +1,34 @@
|
||||
# Databázová architektura — Zdroje
|
||||
|
||||
## Oficiální dokumentace
|
||||
|
||||
| Zdroj | URL | Status |
|
||||
|-------|-----|--------|
|
||||
| PostgreSQL docs | https://www.postgresql.org/docs/ | `[done]` |
|
||||
| MySQL docs | https://dev.mysql.com/doc/ | `[done]` |
|
||||
| MongoDB docs | https://www.mongodb.com/docs/ | `[done]` |
|
||||
| Redis docs | https://redis.io/docs/ | `[done]` |
|
||||
| Cassandra docs | https://cassandra.apache.org/doc/ | `[done]` |
|
||||
| Amazon DynamoDB docs | https://docs.aws.amazon.com/dynamodb/ | `[done]` |
|
||||
|
||||
## Knihy
|
||||
|
||||
| Název | Autor | ISBN | Status |
|
||||
|-------|-------|------|--------|
|
||||
| Designing Data-Intensive Applications (1st ed.) | Martin Kleppmann | 978-1449373320 | `[done]` |
|
||||
| Designing Data-Intensive Applications (2nd ed.) | Kleppmann, Riccomini | 978-1098119058 | `[todo]` |
|
||||
| Database Internals | Alex Petrov | 978-1492040346 | `[done]` |
|
||||
| High Performance MySQL | Schwartz, Zaitsev, Tkachenko | 978-1492080510 | `[todo]` |
|
||||
| PostgreSQL: Up and Running | Regina Obe, Leo Hsu | 978-1491963418 | `[todo]` |
|
||||
| Architecting an Apache Iceberg Lakehouse | Alex Merced | 978-1-63343-510-0 | `[todo]` |
|
||||
| More SQL Antipatterns | Bill Karwin | 979-8888652060 | `[todo]` |
|
||||
| AI-Ready PostgreSQL 18 | Vibhor Kumar, Marc Linster | 978-1-80602-847-4 | `[todo]` |
|
||||
| Vector Databases | Nitin Borwankar | 978-1-098-17758-4 | `[todo]` |
|
||||
|
||||
## Články / přednášky
|
||||
|
||||
| Název | URL | Status |
|
||||
|-------|-----|--------|
|
||||
| CAP Theorem (Eric Brewer) | https://www.infoq.com/articles/cap-twelve-years-later-how-the-rules-have-changed/ | `[done]` |
|
||||
| PACELC theorem | https://www.cs.umd.edu/~abadi/papers/abadi-pacelc.pdf | `[done]` |
|
||||
| Amazon Dynamo DB paper | https://www.allthingsdistributed.com/files/amazon-dynamo-sosp2007.pdf | `[todo]` |
|
||||
70
sources/infrastructure/sources.md
Normal file
70
sources/infrastructure/sources.md
Normal file
@@ -0,0 +1,70 @@
|
||||
# Infrastruktura — Zdroje
|
||||
|
||||
Rozděleno do samostatných souborů:
|
||||
- [HYPERVISORS.md](../../HYPERVISORS.md) — hypervisory a virtualizace
|
||||
- [DATACENTERS.md](../../DATACENTERS.md) — datová centra
|
||||
- [STORAGE.md](../../STORAGE.md) — storage
|
||||
- [HARDWARE.md](../../HARDWARE.md) — hardware a servery
|
||||
|
||||
## Oficiální dokumentace
|
||||
|
||||
| Zdroj | URL | Status |
|
||||
|-------|-----|--------|
|
||||
| VMware vSphere docs | https://docs.vmware.com/en/VMware-vSphere/ | `[done]` |
|
||||
| Microsoft Hyper-V docs | https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/ | `[done]` |
|
||||
| Proxmox VE docs | https://pve.proxmox.com/wiki/Main_Page | `[done]` |
|
||||
| OpenStack docs | https://docs.openstack.org/ | `[done]` |
|
||||
| Ceph docs | https://docs.ceph.com/ | `[done]` |
|
||||
| Redfish specification | https://www.dmtf.org/standards/redfish | `[done]` |
|
||||
|
||||
## Standardy
|
||||
|
||||
| Standard | Popis | Status |
|
||||
|----------|-------|--------|
|
||||
| TIA-942 | Telecommunications Infrastructure Standard for Data Centers | `[done]` |
|
||||
| Uptime Institute Tier Standard | Data Center Tier Classification | `[done]` |
|
||||
| ASHRAE TC 9.9 | Thermal Guidelines for Data Processing Environments | `[done]` |
|
||||
| S.M.A.R.T. | Self-Monitoring, Analysis and Reporting Technology | `[done]` |
|
||||
|
||||
## Knihy
|
||||
|
||||
| Název | Autor | ISBN | Status |
|
||||
|-------|-------|------|--------|
|
||||
| The Data Center as a Computer (1st ed. → 4th ed. 2025) | Barroso, Hölzle, Ranganathan | 978-3-031-99488-3 | `[todo]` |
|
||||
| Storage Systems | Ganger, Gibson | 978-1680837540 | `[todo]` |
|
||||
| Virtualization Essentials | Matthew Portnoy | 978-1119481513 | `[todo]` |
|
||||
| VMware vSphere Design (2nd ed.) | Forbes Guthrie, Scott Lowe | 978-1119130312 | `[todo]` |
|
||||
| AI Data Center Network Design and Technologies (1st ed.) | Subramaniam, Styszynski, Tambakuwala | 978-0-13-543628-8 | `[todo]` |
|
||||
| Electronics Cooling: From the Chip to the Datacenter | Abraham et al. | 978-0-443-47084-4 | `[todo]` |
|
||||
| The AI Cloud Infrastructure Blueprint | Thummarakoti, Vududala, Madupati, Kaushik | 978-1-041-16642-9 | `[todo]` |
|
||||
|
||||
## Server connectivity
|
||||
|
||||
| Zdroj | URL | Status |
|
||||
|-------|-----|--------|
|
||||
| HPE Gen11 NIC selection guide | https://www.hpe.com/psnow/doc/a50007643enw | `[todo]` |
|
||||
| Broadcom / Emulex FC HBA specs | https://www.broadcom.com/products/storage/fibre-channel-host-bus-adapters | `[todo]` |
|
||||
| NVIDIA Mellanox Ethernet + InfiniBand adapters | https://www.nvidia.com/en-us/networking/ethernet/ | `[todo]` |
|
||||
| NVMe-oF specification (NVM Express Inc.) | https://nvmexpress.org/specifications/ | `[todo]` |
|
||||
| Dell PowerEdge R760 NIC placement guide | https://www.dell.com/support/manuals/en-us/oth-r760/per760_ism_pub/ | `[todo]` |
|
||||
|
||||
## Server memory — osazování DIMM
|
||||
|
||||
| Zdroj | URL | Status |
|
||||
|-------|-----|--------|
|
||||
| Dell PowerEdge R760 Installation & Service Manual — System Memory Guidelines | https://www.dell.com/support/manuals/en-al/oth-r760/per760_ism_pub/system-memory-guidelines | `[done]` |
|
||||
| Dell PowerEdge R760 — General Memory Module Installation Guidelines | https://www.dell.com/support/manuals/en-al/oth-r760/per760_ism_pub/general-memory-module-installation-guidelines | `[done]` |
|
||||
| HPE Gen11 Server Memory Population Rules (4th Gen Intel Xeon) | https://www.hpe.com/psnow/doc/a50007437enw | `[done]` |
|
||||
| HPE Gen11 Server Memory Population Rules (5th Gen Intel Xeon) | https://www.hpe.com/psnow/doc/a50010242enw | `[done]` |
|
||||
| HPE Gen11/Gen12 Server Memory Population Rules (AMD EPYC 9005) | https://www.hpe.com/psnow/doc/a50010243enw | `[todo]` |
|
||||
| Single Rank vs Dual Rank vs Quad Rank vs Octa Rank Memory | https://corewavelabs.com/single-rank-vs-dual-rank-vs-quad-vs-octa-memory/ | `[done]` |
|
||||
|
||||
## Výrobci hardware
|
||||
|
||||
| Výrobce | Serverové řady | Management |
|
||||
|---------|---------------|------------|
|
||||
| Dell | PowerEdge (R6xx, R7xx) | iDRAC / OpenManage |
|
||||
| HPE | ProLiant (DL, ML, Synergy) | iLO / OneView |
|
||||
| Cisco | UCS (B-Series, C-Series) | UCS Manager / Intersight |
|
||||
| Lenovo | ThinkSystem (SR, ST) | XClarity |
|
||||
| Supermicro | SuperServer (cloud, storage, GPU) | IPMI / SuperDoctor |
|
||||
49
sources/monitoring/sources.md
Normal file
49
sources/monitoring/sources.md
Normal file
@@ -0,0 +1,49 @@
|
||||
# Monitoring a observabilita — Zdroje
|
||||
|
||||
## Oficiální dokumentace
|
||||
|
||||
| Zdroj | URL | Status |
|
||||
|-------|-----|--------|
|
||||
| Prometheus docs | https://prometheus.io/docs/ | `[done]` |
|
||||
| Grafana docs | https://grafana.com/docs/ | `[done]` |
|
||||
| OpenTelemetry specification | https://opentelemetry.io/docs/specs/otel/ | `[done]` |
|
||||
| OpenMetrics standard | https://openmetrics.io/ | `[done]` |
|
||||
|
||||
## Knihy
|
||||
|
||||
| Název | Autor | ISBN | Status |
|
||||
|-------|-------|------|--------|
|
||||
| Site Reliability Engineering | Beyer, Jones, Petoff, Murphy | 978-1491929124 | `[done]` |
|
||||
| The Site Reliability Workbook | Beyer, Jones, Petoff, Murphy | 978-1492029502 | `[todo]` |
|
||||
| Observability Engineering | Majors, Fong-Pong | 978-1492076445 | `[todo]` |
|
||||
|
||||
## Články
|
||||
|
||||
| Název | URL | Status |
|
||||
|-------|-----|--------|
|
||||
| The USE Method (Brendan Gregg) | https://www.brendangregg.com/usemethod.html | `[done]` |
|
||||
| The RED Method (Tom Wilkie) | https://grafana.com/blog/2018/08/02/the-red-method-how-to-instrument-your-services/ | `[done]` |
|
||||
| Google SRE book (free) | https://sre.google/sre-book/table-of-contents/ | `[done]` |
|
||||
|
||||
## Nové knihy (2024–2026)
|
||||
|
||||
| Název | Autor | ISBN | Status |
|
||||
|-------|-------|------|--------|
|
||||
| Mastering OpenTelemetry and Observability | Steve Flanders | 978-1-394-25312-8 | `[done]` |
|
||||
| OpenTelemetry Cookbook | — | 978-9349174238 | `[done]` |
|
||||
| Cloud Observability in Action | — | — | `[todo]` |
|
||||
| Observability in the AI-Native Era | Lipsig, Grabner, Rati | 978-1-80638-959-9 | `[todo]` |
|
||||
| Mastering Prometheus | William Hegedus | 978-1-80512-566-2 | `[todo]` |
|
||||
| Observability with Grafana (LGTM stack) | — | 978-1-80324-964-3 | `[todo]` |
|
||||
| Open Source Observability | Corless, Pawar | — (O'Reilly, 2025) | `[todo]` |
|
||||
| Hands-On Monitoring and Alerting with Prometheus | Muhammad Badawy | 978-9349887565 | `[todo]` |
|
||||
|
||||
## Nové nástroje (2024–2026)
|
||||
|
||||
| Nástroj | Popis | URL | Status |
|
||||
|---------|-------|-----|--------|
|
||||
| Grafana Sigil | AI observability (OpenTelemetry-native) | https://github.com/grafana/sigil | `[todo]` |
|
||||
| InfraLens | eBPF-based zero-instrumentation observability | https://github.com/Herenn/Infralens | `[todo]` |
|
||||
| Ingero | GPU causal observability (eBPF) | https://github.com/ingero-io/ingero | `[todo]` |
|
||||
| GreptimeDB | Unified observability DB (OTel-native) | https://github.com/GreptimeTeam/greptimedb | `[todo]` |
|
||||
| Netdata | AI-powered full-stack observability | https://github.com/netdata/netdata | `[todo]` |
|
||||
40
sources/networking/sources.md
Normal file
40
sources/networking/sources.md
Normal file
@@ -0,0 +1,40 @@
|
||||
# Síťová architektura — Zdroje
|
||||
|
||||
## RFC a standardy
|
||||
|
||||
| RFC | Název | Status |
|
||||
|-----|-------|--------|
|
||||
| RFC 791 | Internet Protocol | `[done]` |
|
||||
| RFC 793 | Transmission Control Protocol | `[done]` |
|
||||
| RFC 1034/1035 | Domain Names — Concepts and Facilities | `[done]` |
|
||||
| RFC 4271 | Border Gateway Protocol (BGP-4) | `[done]` |
|
||||
| RFC 5246 | TLS 1.2 | `[done]` |
|
||||
| RFC 8446 | TLS 1.3 | `[done]` |
|
||||
|
||||
## Oficiální dokumentace
|
||||
|
||||
| Zdroj | URL | Status |
|
||||
|-------|-----|--------|
|
||||
| AWS VPC docs | https://docs.aws.amazon.com/vpc/ | `[done]` |
|
||||
| Azure Virtual Network docs | https://learn.microsoft.com/en-us/azure/virtual-network/ | `[done]` |
|
||||
| Google VPC docs | https://cloud.google.com/vpc/docs | `[done]` |
|
||||
|
||||
## Knihy
|
||||
|
||||
| Název | Autor | ISBN | Status |
|
||||
|-------|-------|------|--------|
|
||||
| Computer Networking: A Top-Down Approach | Kurose, Ross | 978-0133594140 | `[done]` |
|
||||
| TCP/IP Illustrated | W. Richard Stevens | 978-0321336316 | `[todo]` |
|
||||
|
||||
## Nové knihy (2024–2026)
|
||||
|
||||
| Název | Autor | ISBN | Status |
|
||||
|-------|-------|------|--------|
|
||||
| AI Data Center Network Design and Technologies | Subramaniam, Styszynski, Tambakuwala | 978-0-13-543628-8 | `[todo]` |
|
||||
| Cloud Networking and Resilience | Cristian Critelli | 979-8868824357 | `[todo]` |
|
||||
| Zero Trust in Resilient Cloud and Network Architectures | Halley, Prajapati, Leza, Saini | 978-0-13-820460-0 | `[todo]` |
|
||||
| The Segmentation Blueprint | Kulkarni, Sivakumar, Morais, Lloyd | 978-0-13-546236-2 | `[todo]` |
|
||||
| Segment Routing for SP and Enterprise Networks | Deragisch et al. | 978-0-13-823101-9 | `[todo]` |
|
||||
| Understanding and Designing Azure Networking | Stuart, Moreno | — (2025) | `[todo]` |
|
||||
| Mastering Next-Gen Juniper Data Centers | — | 978-0-13-533636-6 | `[todo]` |
|
||||
| Intelligent Cloud Networking: AI-Driven Resource Management | Manoj Yadav | 9364220110 | `[todo]` |
|
||||
50
templates/ADR.md
Normal file
50
templates/ADR.md
Normal file
@@ -0,0 +1,50 @@
|
||||
# ADR — Architecture Decision Record
|
||||
|
||||
## Název rozhodnutí
|
||||
|
||||
<!-- Stručný název (např. "Použití PostgreSQL jako primární databáze") -->
|
||||
|
||||
## Status
|
||||
|
||||
<!--
|
||||
Navrženo | Schváleno | Deprecated | Nahrazeno [ADR-XXX]
|
||||
-->
|
||||
|
||||
## Kontext
|
||||
|
||||
<!--
|
||||
Popište problém, který řešíme. Jaké jsou okolnosti, omezení a požadavky?
|
||||
-->
|
||||
|
||||
## Rozhodnutí
|
||||
|
||||
<!--
|
||||
Jaké řešení jsme zvolili a proč? Popište architektonický přístup.
|
||||
-->
|
||||
|
||||
## Důvody
|
||||
|
||||
<!--
|
||||
Proč jsme zvolili toto řešení? Jaké jsou hlavní benefity oproti alternativám?
|
||||
-->
|
||||
|
||||
## Alternativy
|
||||
|
||||
<!--
|
||||
Jaké další možnosti jsme zvažovali a proč jsme je zamítli?
|
||||
-->
|
||||
|
||||
## Důsledky
|
||||
|
||||
<!--
|
||||
- Co se mění? Co je potřeba udělat?
|
||||
- Jaké jsou trade-offy (např. vyšší komplexita za nižší latenci)?
|
||||
- Dopad na ostatní týmy / systémy?
|
||||
-->
|
||||
|
||||
## Metadata
|
||||
|
||||
- **Datum**: YYYY-MM-DD
|
||||
- **Autor**: jméno
|
||||
- **Zainteresované strany**: tým A, tým B
|
||||
- **Reference**: [odkaz na design doc], [odkaz na issue]
|
||||
Reference in New Issue
Block a user