Installation & Setup
System Requirements
Everything you need to run Cassandra in development and production environments!
📖 The $50K Hardware Mistake
Meet Tom, a startup CTO who just got $500K in funding. He decided to run Cassandra for their new social media app...
❌ What Tom Did Wrong
- 💥 Bought cheap servers: 4GB RAM, 2 cores, spinning HDDs
- 💥 Ran Java 8: Didn't check Java version requirements
- 💥 Windows servers: Thought "OS doesn't matter"
- 💥 Single SSD: No RAID, no redundancy
- 💥 1Gbps network: Shared with other services
Result:
- ⏱️ Queries taking 30+ seconds
- 💥 Constant out-of-memory crashes
- 🔥 Data loss from disk failures
- 😡 Investors furious at slow demo
- 💸 Had to spend $50K replacing everything!
✅ The RIGHT Way
After reading system requirements:
- ✅ 16GB RAM minimum per node
- ✅ 8+ CPU cores for production
- ✅ Linux servers (Ubuntu 20.04 LTS)
- ✅ NVMe SSDs in RAID 10
- ✅ 10Gbps network dedicated to Cassandra
- ✅ Java 11 (OpenJDK recommended)
Result: Queries in milliseconds, investors happy, system stable! 🎉
Let's make sure YOU don't repeat Tom's mistakes!
⚡ Quick Summary
TL;DR for the busy developer!
Development
- RAM: 4GB minimum
- CPU: 2 cores
- Disk: 20GB any type
- OS: Any (Mac/Linux/Win)
- Java: 11 or 17
- Network: Standard LAN
Production
- RAM: 16-32GB (64GB ideal)
- CPU: 8-16 cores
- Disk: 1-4TB NVMe SSD
- OS: Linux (Ubuntu/RHEL)
- Java: 11 LTS (recommended)
- Network: 10Gbps dedicated
High Performance
- RAM: 64-128GB+
- CPU: 16-32+ cores
- Disk: 4TB+ NVMe RAID 10
- OS: Tuned Linux kernel
- Java: 11 + custom JVM flags
- Network: 25-100Gbps
🖥️ Hardware Requirements
Let's break down each component in detail!
💾 RAM (Memory)
Why RAM Matters
Cassandra uses RAM for:
- MemTables: Recent writes before flushing to disk
- Row Cache: Hot data cached in memory
- Key Cache: Partition key locations
- JVM Heap: Java object storage
- OS Page Cache: File system caching
| Environment | Minimum RAM | Recommended RAM | Why? |
|---|---|---|---|
| Development | 4GB | 8GB | Basic testing, single node |
| Staging | 8GB | 16GB | Realistic workload testing |
| Production (Light) | 16GB | 32GB | < 1TB data per node |
| Production (Heavy) | 32GB | 64-128GB | > 1TB data per node |
# Recommended RAM allocation (for 32GB total RAM)
JVM Heap: 8GB # 1/4 of total RAM (max 16GB)
Off-Heap: 4GB # Memtables, caches
OS Page Cache: 18GB # Remaining for OS caching
OS + Overhead: 2GB # Operating system
Common RAM Mistakes
- ❌ Too little RAM: Constant swapping, slow queries
- ❌ Huge JVM heap (> 16GB): Long garbage collection pauses
- ❌ No room for OS cache: Disk reads instead of memory
- ✅ Rule of thumb: JVM heap = 1/4 of RAM, max 16GB
🔢 CPU (Processor)
What Cassandra Does with CPU
CPU intensive operations:
- Compaction: Merging SSTables (background process)
- Read/Write threads: Handling client requests
- Gossip: Cluster state communication
- Compression: Data compression on writes
- Repairs: Data consistency checks
| Environment | CPU Cores | Notes |
|---|---|---|
| Development | 2 cores | Minimum for single node |
| Production (Small) | 4-8 cores | Light to moderate traffic |
| Production (Medium) | 8-16 cores | Standard production workload |
| Production (Large) | 16-32+ cores | High throughput, many tables |
CPU Best Practices
- ✅ More cores > Higher frequency: Cassandra is highly concurrent
- ✅ Avoid hyperthreading issues: Count physical cores
- ✅ Leave headroom: Don't run CPU at 100%
- ✅ Monitor compaction: Can be CPU intensive
💿 Disk Requirements
Disk is CRITICAL for Cassandra
This is the #1 performance bottleneck!
- ❌ HDDs: 100-200 IOPS = SLOW
- ✅ SSDs: 10,000+ IOPS = FAST
- ✅ NVMe SSDs: 100,000+ IOPS = BLAZING
| Disk Type | IOPS | Latency | Use Case |
|---|---|---|---|
| HDD (7200 RPM) | ~100 | 10-20ms | ❌ NOT for Cassandra |
| SATA SSD | ~10,000 | 0.1-1ms | ✅ Development/Small prod |
| NVMe SSD | ~100,000 | 0.01-0.1ms | ✅✅ Production (recommended) |
| NVMe RAID 10 | ~400,000+ | <0.01ms | 🚀 High-performance prod |
# Disk capacity planning
Raw Data Size: 1TB
Replication Factor: ×3 # 3 copies
Compression: ×0.5 # 50% compression
Overhead (snapshots): ×1.2 # 20% extra
────────────────────────────────
Total Needed: 1.8TB # per node
# Recommended: 2TB+ NVMe SSD per node
Storage Layout Best Practices
- ✅ Separate disk for commit log: Isolate sequential writes
- ✅ Separate disk for data: Random read/writes
- ✅ RAID 10 for production: Performance + redundancy
- ❌ Don't use RAID 5/6: Write penalty hurts Cassandra
- ✅ XFS or ext4 filesystem: Best tested with Cassandra
🐧 Operating System Requirements
Cassandra runs on multiple OS, but Linux is STRONGLY recommended for production!
Linux (Recommended)
Best for production!
- Ubuntu 20.04/22.04 LTS
- RHEL 8/9
- CentOS 8
- Debian 11+
Why Linux?
- Best performance tuning
- Most production deployments
- Better community support
macOS (Development Only)
OK for local dev
- macOS 11+ (Big Sur)
- Works with Docker
- Good for testing
Limitations:
- ❌ NOT for production
- ❌ Performance issues
- ❌ Missing Linux features
Windows (Not Recommended)
Avoid if possible
- Windows Server 2016+
- Experimental support
- Limited tooling
Why avoid?
- Poor performance
- Few deployments
- Limited documentation
Linux Kernel Requirements
- Minimum: Linux kernel 3.10+
- Recommended: Linux kernel 4.15+ or 5.x
- File descriptor limit: At least 100,000 (ulimit -n)
- Max map count: vm.max_map_count >= 1048575
# Check your Linux version
uname -r
# Output: 5.15.0-60-generic (good!)
# Check file descriptor limit
ulimit -n
# Output: 100000 (minimum)
# Increase file descriptors (add to /etc/security/limits.conf)
cassandra soft nofile 100000
cassandra hard nofile 100000
# Increase max map count
sudo sysctl -w vm.max_map_count=1048575
☕ Java/JVM Requirements
Cassandra is a Java application - choosing the right JVM is crucial!
Supported Java Versions
| Cassandra Version | Java Versions | Recommended |
|---|---|---|
| Cassandra 4.x | Java 8, 11 | ✅ Java 11 |
| Cassandra 5.x | Java 11, 17 | ✅ Java 11 or 17 |
OpenJDK (Recommended)
- Free and open source
- Well tested
- Community support
- Azul Zulu
- Amazon Corretto
Oracle JDK
- Works fine
- Commercial license
- $ Cost in production
- Not necessary
# Install OpenJDK 11 on Ubuntu
sudo apt update
sudo apt install openjdk-11-jdk
# Verify Java version
java -version
# Output should show: openjdk version "11.0.x"
# Set JAVA_HOME
export JAVA_HOME=/usr/lib/jvm/java-11-openjdk-amd64
# Add to ~/.bashrc to make permanent
echo 'export JAVA_HOME=/usr/lib/jvm/java-11-openjdk-amd64' >> ~/.bashrc
JVM Heap Size Rules
Critical for performance!
- ✅ Heap = 1/4 of total RAM
- ✅ NEVER exceed 16GB heap (GC pauses!)
- ✅ Young gen = 1/4 of heap
- ❌ Don't use tiny heaps (< 2GB)
# Example: Server with 32GB RAM
# Edit: conf/jvm.options or jvm11-server.options
# Heap size (8GB = 1/4 of 32GB)
-Xms8G
-Xmx8G
# Young generation (2GB = 1/4 of heap)
-Xmn2G
# GC settings (G1GC recommended for Java 11)
-XX:+UseG1GC
-XX:MaxGCPauseMillis=500
# Example: Server with 128GB RAM
# Still cap heap at 16GB!
-Xms16G
-Xmx16G
-Xmn4G
🌐 Network Requirements
Cassandra is a distributed system - network performance is CRITICAL!
Network Bandwidth Requirements
| Environment | Minimum | Recommended | Why? |
|---|---|---|---|
| Development | 100 Mbps | 1 Gbps | Local testing |
| Production (Small) | 1 Gbps | 10 Gbps | Replication traffic |
| Production (Large) | 10 Gbps | 25-100 Gbps | High throughput + repairs |
Network Latency Matters!
- ✅ Same datacenter: < 1ms latency ideal
- ⚠️ Cross datacenter: < 100ms acceptable
- ❌ > 200ms latency: Will cause problems!
- 💡 Tip: Use dedicated network for Cassandra if possible
Required Ports
| Port | Protocol | Purpose | Direction |
|---|---|---|---|
| 7000 | TCP | Inter-node communication (cluster) | Node ↔ Node |
| 7001 | TCP | Inter-node SSL | Node ↔ Node (encrypted) |
| 7199 | TCP | JMX monitoring | Admin → Node |
| 9042 | TCP | CQL native transport (clients) | App → Node |
| 9160 | TCP | Thrift (deprecated, legacy) | App → Node |
# Firewall rules example (Ubuntu/UFW)
# Allow CQL client connections
sudo ufw allow 9042/tcp
# Allow inter-node communication
sudo ufw allow from 10.0.0.0/24 to any port 7000
sudo ufw allow from 10.0.0.0/24 to any port 7001
# Allow JMX from monitoring server
sudo ufw allow from 10.0.0.10 to any port 7199
# Enable firewall
sudo ufw enable
🏭 Production Environment Best Practices
Real-world production requirements from companies running Cassandra at scale!
📊 Netflix Production Setup
Netflix's Cassandra Nodes
- CPU: 16-32 cores (AWS c5.4xlarge or larger)
- RAM: 32-64GB
- Disk: 2TB NVMe SSD (i3 instances)
- Network: 10 Gbps
- OS: Ubuntu 20.04 LTS
- Java: OpenJDK 11
- Cluster Size: 100s of nodes per region
📱 Instagram Production Setup
Instagram's Cassandra Nodes
- CPU: 24 cores minimum
- RAM: 64-128GB
- Disk: 4TB NVMe SSD RAID 10
- Network: 25 Gbps bonded
- OS: CentOS 7 (custom kernel)
- Java: OpenJDK 11 with G1GC
- Data per node: ~3TB
💳 Apple Production Setup
Apple's Cassandra Nodes
- CPU: 32+ cores
- RAM: 128GB+
- Disk: 8TB+ NVMe RAID 10
- Network: 40-100 Gbps
- OS: RHEL 8
- Cluster: Largest Cassandra deployment (75,000+ nodes!)
✅ Production Checklist
Before Going to Production
Infrastructure:
- ☐ 16GB+ RAM per node (32GB recommended)
- ☐ 8+ CPU cores per node
- ☐ NVMe SSDs (NOT HDDs!)
- ☐ 10 Gbps+ network
- ☐ Redundant network paths
- ☐ Separate disk for commit log
Software:
- ☐ Linux OS (Ubuntu/RHEL)
- ☐ Java 11 OpenJDK
- ☐ Latest stable Cassandra version
- ☐ Tuned JVM settings
- ☐ Proper ulimit settings
Cluster:
- ☐ At least 3 nodes (5+ recommended)
- ☐ Replication Factor = 3
- ☐ NetworkTopologyStrategy
- ☐ Time synchronization (NTP)
- ☐ Monitoring setup (Prometheus/Grafana)
- ☐ Backup strategy in place
☁️ Cloud-Specific Recommendations
Optimized instance types for AWS, Azure, and GCP!
AWS Recommendations
Recommended Instance Types:
- Dev/Test: m5.large (2 vCPU, 8GB)
- Small Prod: i3.2xlarge (8 vCPU, 61GB, 1.9TB NVMe)
- Medium Prod: i3.4xlarge (16 vCPU, 122GB, 3.8TB NVMe)
- Large Prod: i3.8xlarge (32 vCPU, 244GB, 7.6TB NVMe)
- High Perf: i4i.8xlarge (32 vCPU, 256GB, 7.5TB NVMe)
Azure Recommendations
Recommended VM Sizes:
- Dev/Test: Standard_D2s_v3 (2 vCPU, 8GB)
- Small Prod: Standard_L8s_v2 (8 vCPU, 64GB, 1.92TB NVMe)
- Medium Prod: Standard_L16s_v2 (16 vCPU, 128GB, 3.84TB NVMe)
- Large Prod: Standard_L32s_v2 (32 vCPU, 256GB, 7.68TB NVMe)
GCP Recommendations
Recommended Machine Types:
- Dev/Test: n2-standard-2 (2 vCPU, 8GB)
- Small Prod: n2-standard-8 + Local SSD (8 vCPU, 32GB)
- Medium Prod: n2-standard-16 + Local SSD (16 vCPU, 64GB)
- Large Prod: n2-standard-32 + Local SSD (32 vCPU, 128GB)
Cloud Best Practices
- ✅ Use local NVMe SSDs: Don't use network-attached storage (EBS/Azure Disk)
- ✅ Spread across availability zones: Use rack awareness
- ✅ Use placement groups: Low-latency networking (AWS)
- ✅ Enable enhanced networking: SR-IOV for better throughput
- ❌ Avoid burstable instances: (t2/t3) - not suitable for Cassandra
💼 Interview Questions & Expert Answers
Ace your Cassandra interview with these system requirements questions!
1
Why is SSD storage critical for Cassandra? Can you use HDDs?
▼
Answer:
SSDs are critical because Cassandra performs heavy random I/O operations. HDDs provide only ~100-200 IOPS, while SSDs provide 10,000+ IOPS.
Why Cassandra needs high IOPS:
- Compaction: Reads multiple SSTables, writes new ones
- Read path: May need to check multiple SSTables
- Repair: Heavy I/O during data consistency checks
- Bloom filters: Random disk access patterns
Impact of using HDDs:
- 💥 Read latency: 10-50ms (vs 0.1-1ms on SSD)
- 💥 Compaction takes 10x longer
- 💥 Cluster can't keep up with writes
- 💥 Repairs timeout and fail
Recommendation: Always use NVMe SSDs in production. HDDs are only acceptable for cold archival data that's rarely accessed.
2
Why should JVM heap size never exceed 16GB in Cassandra?
▼
Answer:
Large JVM heaps (> 16GB) cause long garbage collection (GC) pauses that can freeze your Cassandra node.
The Problem with Large Heaps:
- GC pause time: Increases with heap size
- 16GB heap: GC pauses ~200-500ms (acceptable)
- 32GB heap: GC pauses 1-3 seconds (BAD!)
- 64GB heap: GC pauses 5-10+ seconds (DISASTER!)
What happens during long GC pauses:
- 💥 Node appears dead to cluster (gossip timeout)
- 💥 Other nodes mark it as DOWN
- 💥 Hints start accumulating
- 💥 Client queries timeout
- 💥 When GC finishes, flood of messages overwhelms node
The Solution:
Cap heap at 16GB. Cassandra uses off-heap memory for many operations (compression buffers, bloom filters, etc.), so the rest of your RAM is still used effectively.
# Server with 128GB RAM
JVM Heap: 16GB # Capped!
Off-heap: 10GB # Cassandra uses this
OS cache: 100GB # OS caches SSTable data
OS overhead: 2GB
3
Why is 10 Gbps network recommended for production Cassandra clusters?
▼
Answer:
Cassandra generates massive inter-node network traffic for replication, repairs, and streaming operations. 1 Gbps becomes a bottleneck quickly.
Network Traffic Sources:
- Writes (RF=3): Each write sends data to 3 nodes
- Repairs: Compares and streams gigabytes of data
- Bootstrap: New node streams entire dataset
- Compaction: Streaming across nodes
- Read repair: Synchronizing inconsistent replicas
Example Scenario:
# Cluster with 1TB per node, RF=3
# Adding a new node
Data to stream: 1TB
Network: 1 Gbps = 125 MB/s
Time to bootstrap: 1TB / 125MB/s = 2.3 hours
# With 10 Gbps network
Network: 10 Gbps = 1.25 GB/s
Time to bootstrap: 1TB / 1.25GB/s = 13 minutes!
Problems with 1 Gbps:
- ⏱️ Slow cluster expansion (adding nodes)
- ⏱️ Slow repairs (can take days!)
- 💥 Write throughput limited by network
- 💥 Network saturation during repairs
Recommendation: 10 Gbps minimum for production. 25-100 Gbps for large deployments.
4
What's the difference between requirements for development vs production Cassandra?
▼
Answer:
| Component | Development | Production | Why Different? |
|---|---|---|---|
| RAM | 4-8GB | 16-64GB+ | Dev: small dataset. Prod: GB-TB data + caching |
| CPU | 2 cores | 8-32 cores | Dev: light load. Prod: concurrent users + compaction |
| Disk | Any (even HDD) | NVMe SSD only | Dev: latency OK. Prod: IOPS critical |
| Network | 100 Mbps | 10 Gbps+ | Dev: single node. Prod: multi-node replication |
| Nodes | 1 | 3-100+ | Dev: testing. Prod: HA + scalability |
Key Differences Explained:
- Data Volume: Dev has MB/GB, prod has TB/PB
- Traffic: Dev has 1-10 req/sec, prod has 10K-1M req/sec
- Uptime: Dev can crash, prod needs 99.99% uptime
- Performance: Dev accepts seconds, prod needs milliseconds
Common Mistake: Running dev-sized hardware in production! Always test with production-equivalent specs in staging.
5
How do you size a Cassandra cluster for a specific workload?
▼
Answer:
Follow this step-by-step capacity planning process:
Step 1: Calculate Storage Requirements
Raw data size: 10TB
Replication factor: ×3
Compression ratio: ×0.5 # 50% compression
Snapshot overhead: ×1.2 # 20% for snapshots
Total storage needed: 18TB
# With 2TB disks per node:
Nodes needed (storage): 18TB / 2TB = 9 nodes
Step 2: Calculate Throughput Requirements
Peak writes/sec: 50,000
Peak reads/sec: 100,000
Avg row size: 1KB
# Write throughput needed:
Write MB/s: 50,000 × 1KB = 50 MB/s
With RF=3: 50 MB/s × 3 = 150 MB/s
# Per node (9 nodes):
Write MB/s per node: 150 / 9 = 17 MB/s # Easy!
Step 3: Validate Latency Requirements
- Target p99: < 10ms?
- Need: NVMe SSDs + sufficient RAM for caching
- RAM rule: Allocate 1GB RAM per 100GB data
Step 4: Add Headroom
Nodes calculated: 9
Growth buffer (20%): +2 nodes
Failure buffer (1 node): +1 node
────────────────────────────
Final cluster size: 12 nodes
Final Recommendation:
12 nodes, each with:
- 32GB RAM
- 16 CPU cores
- 2TB NVMe SSD
- 10 Gbps network
🎓 Chapter Summary: System Requirements Mastery
You now know exactly what hardware and software Cassandra needs!
Production Minimums (Never Go Below):
- 💾 16GB RAM per node (32GB+ recommended)
- 🔢 8 CPU cores per node (16+ recommended)
- 💿 NVMe SSD storage (HDDs = disaster)
- 🌐 10 Gbps network (dedicated to Cassandra)
- 🐧 Linux OS (Ubuntu 20.04/22.04 or RHEL 8/9)
- ☕ Java 11 OpenJDK (LTS version)
Critical Rules:
- ✅ JVM Heap ≤ 16GB (avoid GC pauses)
- ✅ Heap = 1/4 of RAM (leave room for OS cache)
- ✅ Separate disks for commit log and data
- ✅ Test in staging with production-equivalent hardware
🚀 Next: Let's install Cassandra with these requirements!
Advertisement
Responsive Ad