Solving the 20TB Challenge: Introducing the DB Pod 20TB Sorununu Çözmek: DB Pod'u Tanıtıyoruz
Supporting a 20 TB, high-velocity "hot" database requires a hardware profile uniquely optimized for extreme IOPS and near-zero latency. While our standard compute bundles handle stateless workloads with massive efficiency, mission-critical databases demand enterprise-grade memory protection, local multi-drive RAID, and dedicated bandwidth. To serve this exact requirement, we are introducing the MS-02 Ultra to the cluster. It preserves the agility of our mesh network while delivering the specialized storage durability and fiber-class replication speeds required for intensive transactional environments. 20 TB büyüklüğünde, yüksek hızlı bir "hot" veritabanını desteklemek, aşırı IOPS ve sıfıra yakın gecikme için özel olarak optimize edilmiş bir donanım profili gerektirir. Standart hesaplama paketlerimiz durumsuz (stateless) iş yüklerini büyük bir verimlilikle karşılarken, kritik öneme sahip veritabanları kurumsal düzeyde bellek koruması, yerel çoklu disk RAID'i ve özel bant genişliği gerektirir. Bu ihtiyacı tam olarak karşılamak için kümeye MS-02 Ultra'yı tanıtıyoruz. Bu sistem, mesh ağımızın çevikliğini korurken, yoğun işlemsel ortamlar için gereken özel depolama dayanıklılığını ve fiber sınıfı replikasyon hızlarını sunar.
Core Ultra 9 285HX with ECC supportECC destekli Core Ultra 9 285HX
Our previous pod setup — the 3-manager, 15-worker bundle — is optimized for VM hosting and normal application traffic: stateless, replaceable, and tuned for core count over data integrity. A 20TB hot database is a different kind of workload, and it starts with a different kind of chip.
Önceki pod kurulumumuz — 3 yönetici, 15 çalışanlı paket — VM barındırma ve normal uygulama trafiği için optimize edilmiştir: durumsuz, değiştirilebilir ve veri bütünlüğü yerine çekirdek sayısına göre ayarlanmıştır. 20TB'lık hot bir veritabanı farklı bir iş yükü türüdür ve bu, farklı bir çip ile başlar.
The DB pod runs on the Core Ultra 9 285HX, unlocking ECC memory support, Intel vPro remote management, and the full dual-25GbE networking path — the exact combination a 24/7 transactional workload needs.
DB pod, Core Ultra 9 285HX üzerinde çalışır; bu da ECC bellek desteğini, Intel vPro uzaktan yönetimini ve tam çift 25GbE ağ yolunu açar — 7/24 işlemsel bir iş yükünün tam olarak ihtiyaç duyduğu kombinasyon budur.
Dual 25GbE — a dedicated path for database trafficÇift 25GbE — veritabanı trafiği için özel bir yol
This type of replication needs a different kind of networking than the rest of the mesh runs on. We use the dual 25GbE ports as the physical connection point, and the database traffic layer — replication between DB pods, plus high-volume reads from the application tier — goes through it directly, instead of sharing bandwidth with general cluster traffic.
Bu tür bir replikasyon, mesh ağının geri kalanından farklı bir ağ yapısına ihtiyaç duyar. Çift 25GbE portlarını fiziksel bağlantı noktası olarak kullanıyoruz ve veritabanı trafiği katmanı — DB pod'lar arası replikasyon ile uygulama katmanından gelen yoğun okumalar — genel küme trafiğiyle bant genişliği paylaşmak yerine doğrudan buradan geçer.
10GbE + 2.5GbE alongside the 25GbE tier25GbE katmanının yanında 10GbE + 2.5GbE
Beyond the 25GbE database path, the DB pod also carries 10GbE and 2.5GbE ports for management and general cluster traffic. Our last PoC pods started at a 2.5GbE baseline across the board — the entire mesh ran on that single tier.
25GbE veritabanı yolunun ötesinde, DB pod ayrıca yönetim ve genel küme trafiği için 10GbE ve 2.5GbE portları da taşır. Son PoC pod'larımız tüm sistemde 2.5GbE temeliyle başladı — tüm mesh ağı bu tek katmanda çalışıyordu.
All workers and managers in the current cluster now use this database system as their data layer — application logic stays on the VM/compute pods, while data access runs on its own dedicated path.
Mevcut kümedeki tüm çalışanlar ve yöneticiler artık bu veritabanı sistemini veri katmanı olarak kullanıyor — uygulama mantığı VM/hesaplama pod'larında kalırken, veri erişimi kendi özel yolunda çalışır.
24TB of PCIe 4.0 NVMe, across 4 M.2 slots4 M.2 yuvasında toplam 24TB PCIe 4.0 NVMe
The DB pod supports up to 24TB of storage across four M.2 slots, each running the PCIe 4.0 interface for high-speed read and write throughput. That capacity is enough to hold the full 20TB hot dataset on a single node, with headroom left for journal/WAL writes and local snapshots.
DB pod, her biri yüksek hızlı okuma/yazma için PCIe 4.0 arayüzünü kullanan dört M.2 yuvası üzerinden 24TB'a kadar depolamayı destekler. Bu kapasite, 20TB'lık hot veri kümesinin tamamını tek bir düğümde tutmaya yeterlidir ve journal/WAL yazmaları ile yerel anlık görüntüler için de yer bırakır.
RAID at the hardware levelDonanım seviyesinde RAID
Those four drives support a RAID system, so data protection is guaranteed at the hardware level rather than depending entirely on network-wide replication to recover from a single failed disk. A drive failure gets absorbed locally, on the node itself, without triggering a cluster-wide rebuild.
Bu dört disk bir RAID sistemini destekler, böylece veri koruması yalnızca ağ genelindeki replikasyona bağlı kalmak yerine donanım seviyesinde garanti edilir. Bir disk arızası, küme genelinde bir yeniden yapılandırmayı tetiklemeden, doğrudan düğümün kendisinde yerel olarak karşılanır.
Enterprise-grade NVMe, not consumer SSDsTüketici SSD'leri değil, kurumsal düzey NVMe
We suggest enterprise-grade NVMe SSDs — specifically Samsung PM9A3 or Micron 7450 Pro. This matters because consumer-grade NVMe is risky under a constant OLTP write pattern: it's rated for a much lower total-bytes-written ceiling, which a 24/7 hot database reaches far faster than a normal application disk ever would.
Kurumsal düzeyde NVMe SSD'ler öneriyoruz — özellikle Samsung PM9A3 veya Micron 7450 Pro. Bu önemlidir çünkü tüketici sınıfı NVMe, sürekli OLTP yazma düzeninde risklidir: çok daha düşük bir toplam yazılan bayt sınırına sahiptir ve 7/24 çalışan bir hot veritabanı bu sınıra normal bir uygulama diskinden çok daha hızlı ulaşır.
Up to 256GB DDR5256GB'a kadar DDR5
The DB pod supports up to 256GB of DDR5 memory. For a hot 20TB dataset, RAM stops being a nice-to-have and becomes a hardware standard requirement — a database only needs its working set (the rows and indexes actually hit by live traffic) cached, and 256GB is enough to keep most of that in RAM instead of on disk.
DB pod, 256GB'a kadar DDR5 belleği destekler. 20TB'lık hot bir veri kümesi için RAM, olsa iyi olur seviyesinden çıkıp donanım standardı gereksinimine dönüşür — bir veritabanının yalnızca çalışma kümesinin (canlı trafiğin gerçekten eriştiği satır ve indekslerin) önbelleğe alınmasına ihtiyacı vardır ve 256GB bunun çoğunu diskte değil RAM'de tutmaya yeter.
Every read served from memory instead of NVMe is where the real latency win happens.
Gerçek gecikme kazancı, NVMe yerine bellekten karşılanan her okumada ortaya çıkar.
That RAM is also ECC — the kind of protection you'd find in enterprise servers, but not in regular mini PCs.
Bu bellek aynı zamanda ECC'dir — kurumsal sunucularda bulacağınız türden bir koruma, ancak sıradan mini PC'lerde bulunmaz.
Why ECC specificallyNeden özellikle ECC
ECC is the other half of the memory story, and it's the more important half. Standard DDR5 has no way to notice a flipped bit in RAM — it just passes the corrupted value along, silently. ECC memory detects and corrects those errors automatically, before they ever reach a running transaction. On a node holding the live, in-memory state of a database transaction, that's the difference between a clean commit and silent data corruption.
ECC, bellek hikâyesinin diğer yarısıdır ve daha önemli olan yarısıdır. Standart DDR5, RAM'de değişen bir biti fark etme yeteneğine sahip değildir — bozulmuş değeri sessizce olduğu gibi iletir. ECC bellek bu hataları otomatik olarak tespit edip düzeltir, canlı bir işleme ulaşmadan önce. Bir veritabanı işleminin canlı, bellek içi durumunu tutan bir düğümde, bu; temiz bir commit ile sessiz veri bozulması arasındaki farktır.
350W per node — enterprise capability, cluster-scale efficiencyDüğüm başına 350W — kurumsal kapasite, küme ölçeğinde verimlilik
Each DB pod draws 350W, a figure designed for enterprise-level application demand like hot-frequency databases — well above the ~28W manager and ~15W worker nodes in the standard bundle, because it's carrying ECC memory, four active NVMe drives, and dual 25GbE networking simultaneously.
Her DB pod, hot frekanslı veritabanları gibi kurumsal düzey uygulama talebi için tasarlanmış 350W çeker — standart paketteki ~28W'lık yönetici ve ~15W'lık çalışan düğümlerin çok üzerinde, çünkü aynı anda ECC belleği, dört aktif NVMe diski ve çift 25GbE ağını taşır.
How it connects to the current setup: the DB pods plug into the existing VM and application pod system rather than replacing it — compute stays on the VM pods, hot data moves onto the DB pods. Individually each DB pod uses more power than a single worker, but across the whole 18-node pods.cranko.org layout, the combined cluster still runs on much less power than an equivalent traditional enterprise database server setup.
Mevcut sisteme nasıl bağlanıyor: DB pod'lar, mevcut VM ve uygulama pod sistemini değiştirmek yerine ona eklenir — hesaplama VM pod'larında kalır, hot veri ise DB pod'lara taşınır. Tek başına her DB pod bir çalışan düğümden daha fazla güç kullanır, ancak pods.cranko.org'daki 18 düğümlük tüm yerleşim genelinde, birleşik küme yine de eşdeğer geleneksel bir kurumsal veritabanı sunucu kurulumundan çok daha az güç tüketir.
What runs on the DB Pod, and how each layer is securedDB Pod üzerinde ne çalışır ve her katman nasıl güvence altına alınır
Three types of database, one job each: a SQL database for anything that needs real consistency, a NoSQL/JSON database for fast-changing event data, and an in-memory database that catches the busiest traffic before it reaches either one. Üç tür veritabanı, her birinin tek bir görevi var: gerçek tutarlılık gerektiren her şey için bir SQL veritabanı, hızla değişen olay verileri için bir NoSQL/JSON veritabanı ve en yoğun trafiği ikisine ulaşmadan önce karşılayan bellek içi bir veritabanı.
CockroachDBCockroachDB
- Automatic distribution — data is split into ranges and spread across every node the moment it's written; there's no manual sharding step, ever.Otomatik dağıtım — veri yazıldığı anda parçalara (range) bölünür ve tüm düğümlere yayılır; hiçbir zaman manuel bir parçalama adımı gerekmez.
- No manager/worker split — every node runs the identical binary and can serve reads, writes, or act as query coordinator; there is no special node to lose.Yönetici/çalışan ayrımı yok — her düğüm aynı ikili dosyayı çalıştırır ve okuma, yazma veya sorgu koordinatörlüğü yapabilir; kaybedilecek özel bir düğüm yoktur.
- Self-healing consensus — each range keeps 3 replicas via Raft; losing a node triggers automatic re-election and rebalancing with zero manual failover.Kendi kendini onaran konsensüs — her range, Raft üzerinden 3 kopya tutar; bir düğüm kaybı otomatik yeniden seçim ve yeniden dengelemeyi tetikler, manuel failover gerekmez.
- Fast and reliable at huge, high-frequency scale — LSM-tree storage plus pipelined Raft commits keep ingest fast under constant OLTP load, not just short bursts.Büyük ve yüksek frekanslı ölçekte hızlı ve güvenilir — LSM-tree depolama ve pipeline'lı Raft commit'leri, sürekli OLTP yükü altında bile alım hızını korur, sadece kısa patlamalarda değil.
- Real ACID transactions — every write is consistent across the whole cluster, exactly what a huge, mission-critical, high-frequency dataset needs.Gerçek ACID işlemleri — her yazma, kümenin tamamında tutarlıdır; büyük, kritik önemde ve yüksek frekanslı bir veri kümesinin tam olarak ihtiyaç duyduğu şey budur.
- Mutual TLS everywhere — every node and client proves identity with a cert from one internal CA; no password ever touches the wire.Her yerde karşılıklı TLS — her düğüm ve istemci, tek bir dahili CA'dan gelen sertifikayla kimliğini kanıtlar; hiçbir parola ağa çıkmaz.
- Cert-gated cluster — a node can't join or see any data without a certificate signed by that CA.Sertifikaya bağlı küme — bir düğüm, o CA tarafından imzalanmış bir sertifika olmadan kümeye katılamaz veya hiçbir veriyi göremez.
- Least-privilege SQL roles — GRANTs scope each service to only its own tables, plus optional encryption at rest.En az ayrıcalıklı SQL rolleri — GRANT'lar her servisi yalnızca kendi tablolarıyla sınırlar; isteğe bağlı bekleyen veri şifrelemesi de eklenir.
MongoDBMongoDB
- Document-native storage — data is stored as BSON (binary JSON), so nested and variable-shaped records don't need a fixed schema up front.Belge tabanlı depolama — veri BSON (ikili JSON) olarak saklanır, bu yüzden iç içe ve değişken yapıdaki kayıtların önceden sabit bir şemaya ihtiyacı yoktur.
- Replica-set model — one primary handles writes, two secondaries replicate and stand ready to auto-elect a new primary on failure.Replika seti modeli — bir birincil yazmaları yönetir, iki ikincil replikasyon yapar ve arıza durumunda otomatik olarak yeni bir birincil seçmeye hazır bekler.
- Rich querying on nested fields — indexes and the aggregation pipeline work directly on JSON structure, not just top-level columns.İç içe alanlarda zengin sorgulama — indeksler ve aggregation pipeline, yalnızca üst seviye sütunlarda değil doğrudan JSON yapısı üzerinde çalışır.
- Built for irregular, high-frequency event data — sensor payloads, log lines, and telemetry rarely arrive with identical fields twice; MongoDB accepts each write as-is, so a new field, an extra nested object, or a dropped attribute never means an outage or a schema migration.Düzensiz, yüksek frekanslı olay verileri için tasarlanmıştır — sensör verileri, log satırları ve telemetri nadiren iki kez aynı alanlarla gelir; MongoDB her yazmayı olduğu gibi kabul eder, bu yüzden yeni bir alan, ek bir iç içe nesne veya eksik bir öznitelik asla kesinti veya şema göçü anlamına gelmez.
- X.509 for clients and nodes — the app and every replica-set member authenticate with a CA-signed cert, not a password.İstemciler ve düğümler için X.509 — uygulama ve her replika seti üyesi, parola yerine CA imzalı bir sertifikayla kimlik doğrular.
- Encrypted everywhere — requireTLS on the wire, optional WiredTiger encryption on disk.Her yerde şifreli — ağda requireTLS, diskte isteğe bağlı WiredTiger şifrelemesi.
- Scoped access — RBAC limits each cert's identity to its own databases and collections, nothing more.Sınırlı erişim — RBAC, her sertifika kimliğini yalnızca kendi veritabanları ve koleksiyonlarıyla sınırlar.
RedisRedis
- Sits in front of CockroachDB and MongoDB — absorbs the highest-frequency reads/writes before they ever reach persistent storage.CockroachDB ve MongoDB'nin önünde durur — en yüksek frekanslı okuma/yazmaları kalıcı depolamaya ulaşmadan önce karşılar.
- RAM-speed access — sub-millisecond responses for hot keys, orders of magnitude faster than an NVMe round trip.RAM hızında erişim — sık kullanılan anahtarlar için milisaniyenin altında yanıt, bir NVMe gidiş-dönüşünden kat kat hızlı.
- Not a primary store — data here is disposable by design; the source of truth always stays in CockroachDB or MongoDB.Birincil depo değildir — buradaki veri tasarım gereği geçicidir; gerçek kaynak her zaman CockroachDB veya MongoDB'de kalır.
- Simple replica setup for HA, or cluster mode only if the cache itself needs to outgrow a single node's RAM.Yüksek erişilebilirlik için basit replika kurulumu, önbelleğin kendisi tek bir düğümün RAM'ini aşması gerektiğinde ise cluster modu.
- ACLs, not one shared password — each service gets its own user, scoped to its own keys and commands.Paylaşılan tek parola yerine ACL'ler — her servis kendi anahtarları ve komutlarıyla sınırlı kendi kullanıcısını alır.
- Internal-only, TLS-wrapped — no public interface, same CA-issued certs as CockroachDB and MongoDB.Yalnızca dahili, TLS ile korunmuş — genel arayüz yok, CockroachDB ve MongoDB ile aynı CA sertifikaları.
- Low blast radius — dangerous commands disabled, and since it holds no source of truth, a breach costs performance, not data.Düşük etki alanı — tehlikeli komutlar devre dışı; gerçek veri burada tutulmadığından bir ihlal veri değil, performans kaybettirir.
Open to any test Türksat wants to runTürksat'ın çalıştırmak istediği her teste açığız
This system was designed specifically for a 20TB hot database, to the exact scenario Türksat described — every choice above, from replication factor to network path, was made for that scenario. We're open to running any kind of testing or PoC Türksat wants, in Türksat's own environment, on Türksat's own terms. Bu sistem, Türksat'ın tarif ettiği senaryoya birebir uyacak şekilde, özellikle 20TB'lık bir hot veritabanı için tasarlandı — yukarıdaki her karar, replikasyon faktöründen ağ yoluna kadar, bu senaryo için alındı. Türksat'ın isteyeceği her türlü test veya PoC'yi, Türksat'ın kendi ortamında ve kendi koşullarında çalıştırmaya açığız.
- IOPS and p99 latency — under a realistic OLTP load shaped like Türksat's actual hot-data access pattern, not a synthetic best case.IOPS ve p99 gecikmesi — Türksat'ın gerçek hot-veri erişim desenine benzer, gerçekçi bir OLTP yükü altında; sentetik en iyi senaryo değil.
- Failover and resync behavior — pull the power on an actual pod mid-test and watch how the cluster and the surviving replicas actually respond.Failover ve yeniden senkronizasyon davranışı — test sırasında gerçek bir pod'un fişini çekip kümenin ve hayatta kalan replikaların nasıl tepki verdiğini gözlemleyin.
- Network throughput — measured across the dedicated 25GbE path under concurrent replication and client load, not a single idle transfer.Ağ verimi — eşzamanlı replikasyon ve istemci yükü altında, özel 25GbE hattında ölçülür; tek bir boşta transfer değil.
- A full PoC — against a representative 20TB hot dataset, run end-to-end in Türksat's own environment before any commitment is made.Tam bir PoC — herhangi bir taahhütte bulunulmadan önce, Türksat'ın kendi ortamında uçtan uca çalıştırılan, temsili bir 20TB hot veri kümesine karşı.
We have designed the architecture to address the concerns identified by Türksat. The remaining questions are performance questions, and we propose to validate them through a controlled benchmark in Türksat's environment.
Mimariyi, Türksat tarafından tespit edilen endişeleri karşılayacak şekilde tasarladık. Geriye kalan sorular performans sorularıdır ve bunları Türksat'ın kendi ortamında, kontrollü bir kıyaslama testiyle doğrulamayı öneriyoruz.
We'd rather the numbers come from Türksat's own environment than from a lab result that doesn't transfer. Rakamların, aktarılamayan bir laboratuvar sonucundan değil, doğrudan Türksat'ın kendi ortamından gelmesini tercih ederiz.
DB Pod — Full Spec SummaryDB Pod — Tam Teknik Özet
| ComponentBileşen | SpecÖzellik |
|---|---|
| Processorİşlemci | Core Ultra 9 285HX · ECC-enabled tierECC destekli seviye |
| MemoryBellek | Up to 256GB ECC DDR5256GB'a kadar ECC DDR5 |
| StorageDepolama | 4× M.2 PCIe 4.0 · up to 24TB24TB'a kadar · RAID 0/1/5/10 |
| DrivesDiskler | Samsung PM9A3 / Micron 7450 Pro |
| DB networkDB ağı | Dual 25GbE SFP+ |
| Mgmt networkYönetim ağı | 10GbE + 2.5GbE |
| PowerGüç | 350W per nodedüğüm başına |
| SQL engineSQL motoru | CockroachDB (symmetric, ACID)(simetrik, ACID) |
| NoSQL engineNoSQL motoru | MongoDB (replica set, JSON/BSON)(replika seti, JSON/BSON) |
| Cache layerÖnbellek katmanı | Redis (in-memory hot-path)(bellek içi hot-path) |
| SecurityGüvenlik | X.509 / TLS, single internal CAX.509 / TLS, tek dahili CA |
Topology — DB Pods, Managers, WorkersTopoloji — DB Pod'lar, Yöneticiler, Çalışanlar
The DB pods connect to each other over fiber first, forming their own mesh for replication. Each manager then connects up to its bundle's DB pod, and workers connect to their manager — the same layering the mesh already uses, with the DB pods added underneath it as the data layer. DB pod'lar önce birbirlerine fiber üzerinden bağlanarak replikasyon için kendi mesh ağlarını oluşturur. Ardından her yönetici, paketindeki DB pod'a bağlanır ve çalışanlar kendi yöneticilerine bağlanır — mesh ağının zaten kullandığı aynı katmanlama, altına veri katmanı olarak DB pod'lar eklenmiş şekilde.