05f723556e
deploy.sh referenced DEPLOYMENT-TYPES.md and router-bmp-config.md, which were never committed (they lived only in a chat session's outputs). Land them under docs/ along with PORTABILITY-FINDINGS.md covering all 12 greenfield findings, including the two from today's deploy (chmod-777-vs-psql, telegraf docker API) and the open router-side gap (cml tooling still targets HOST_IP:5000). - scripts/wsl-portproxy.ps1: idempotent elevated-PS helper for the Windows portproxy + firewall rules; auto-detects the current WSL IP. Replaces the copy-paste netsh block as the primary path (raw commands kept as fallback). - deploy.sh: plan now prints the branch @ commit (+dirty marker) so every deploy records exactly what it ran from; doc references point at docs/. - README: greenfield quickstart with pinned-checkout guidance; warning on the manual chmod path that breaks existing Postgres trees (finding 10). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
3.0 KiB
Deployment types
deploy.sh deploys one of three types (--scope). This is the reference for
what each includes, when to use it, and what to size it for. Old scope names
(core/feeders/full/standalone) are accepted as aliases.
1. full-stack
Everything on one host: collector + Kafka + Postgres/TimescaleDB + Grafana +
whois + lab feeders (--profile test: ExaBGP, GoBGP, traffic-gen, InfluxDB,
telegraf, rib-poller, churn/kafka-lag monitors). BMP terminates here and data
is stored here.
- Use when: one node monitors the whole fabric (lab, or small prod).
- Excludes: nothing except Authelia (separate toggle,
--auth authelia+--profile auth). - Resources: prod-realistic 16 vCPU / 48-64 GB / NVMe >=250 GB; lab-only 4 vCPU / 16 GB / SSD.
2. remote
Collector + local Kafka only. Forwards parsed/raw data to a central store's
Kafka (--central-kafka HOST:PORT, written to KAFKA_FQDN). No local
Postgres/psql-app/Grafana.
- Use when: scaling ingest out — run these near the routers so each node's Kafka spool absorbs only its own routers' RIB dumps instead of every table hitting one host at once.
- Resources: light — 2-4 vCPU / 4-8 GB / 20-40 GB fast disk (the Kafka spool must buffer a full connect/flap burst from its local routers).
3. central-store
The store half: Kafka + Postgres + Grafana + feeders, no local collector.
Ingest arrives from remote collectors over Kafka. Run one of these behind N
remote nodes.
- Use when: you've split ingest with remote collectors.
- Resources: same as the full-stack store tier — 16 vCPU / 48-64 GB / NVMe >=250 GB (it carries all remotes' data).
Sizing: dimension for BMP burst, not steady state
BMP is event-driven and bursty. Steady state is trivial; the sizing events are (1) the initial RIB dump on PEER_UP, (2) all routers reconnecting at once (collector restart / RR failover), (3) reconvergence churn.
The multiplier that actually bites is full table x monitored sessions. A full v4+v6 table is ~1.18M paths; in an RR topology the same table is reflected to every client, so BMP ingests it once per monitored session. Monitoring the RR-clients group means absorbing full-table x (RRs x clients) simultaneously — that is what saturates a single host. The wall is Postgres write latency + write amplification backpressuring psql-app -> Kafka -> the BMP TCP sessions; the collector process itself is light and is not the sizing driver.
Mitigations: NVMe with real IOPS headroom (>=5000); BMP-monitor pre-policy on
the RRs only (not every client session); stagger connects
(initial-refresh delay/spread on the routers); raise PSQL_MEM_LIMIT /
Kafka memory; or split ingest with remote collectors.
Storage scales with prefixes: ~1 GB per peer with a full internet table (+~50 MB/day of timeseries); internal peers far less.
All figures are engineering estimates to calibrate against your own watermarking, not measured specs. Replace them with real numbers once a prod-realistic node has been load-tested (see docs/production-sizing.md).