Amazon Cassandra Basics & Guidelines for AWS/EC2/VPC/EBS

™
Cassandra and AWS Support on AWS/EC2
Comprehensive Guide to
Deploying Cassandra on
AWS
• Covers VPC, EC2, EBS, AMIs,
concerns
• Covers Networking
• Covers instance storage vs. EBS
• Covers KMS encryption
• March, 22, 2017
• Accurate and up to date
• Comprehensive guide
• Working examples with src
• Ec2MultiRegionSnitch
• EC2Snitch
• Broadcast address
• Using KMS
• SSL config
• Ansible / SSH Config
• Bastions
• Private Subnets
• VPN Multi-Region Cassandra
• Using enhanced networking
• Using new EBS elastic volumes
March 2017 – version 2

™
Cloudurable
Amazon
Cassandra
Basics
Support around Cassandra
and Kafka running in EC2

™
Cassandra / Kafka Support in EC2/AWS
Company
Overview How we got our start

™
Different companies same
challenges
❖ How to setup a Cluster across multiple AZs
❖ Where does enhanced networking fit it
❖ Should we use EBS or instance storage
❖ Monitoring and logging that can be actionable
❖ Integration with AWS services like CloudFormation, and
CloudWatch.
❖ Best fit for images, VPC setup, peering, subnets,
firewalls

™
Services we provide
❖ Cassandra Training
❖ Cassandra Consulting
❖ Setting up Cassandra in AWS/EC2
❖ AWS CloudFormations
❖ Subscription Support around Cassandra running in
AWS/EC2
❖ AWS CloudWatch monitoring
❖ AWS CloudWatch logging

™
Cloudurable Cassandra AWS Support
AWS Review Review of key Amazon
Services and features

™
Advice and documents AWS
Cassandra
❖ There is a lot of advice on how to configure a
Cassandra cluster on AWS
❖ Not every configuration meets every use case
❖ Best way to know how to deploy Cassandra on AWS is
to know the basics of AWS
❖ We start covering AWS (as it applies to Cassandra)
❖ Later we go into detail with AWS Cassandra specifics

™
AWS Key Concepts
❖ EC2 – compute services, virtual servers
❖ EC2 instance a virtual server running in a VPC
❖ EBS – virtual disk drives
❖ VPC – software defined networks
❖ Public Subnets – have InternetGateway
❖ Private Subnets – no route to InternetGateway

™
Amazon Region and Availability
Zones
❖ AWS supports regions around the world
❖ Regions are independent of each other
❖ place services in a region to be closer to your end consumer to lower latency
and to improve reliability
❖ Availability Zone (AZ) are isolated - Multiple AZs live in a region
❖ AZ protects against outage
❖ Placing your services and application in different Azs
❖ AZs have independent power, backup generators, UPS units, etc.
❖ AZs if possible exists in a separate location of a metropolitan area
❖ AZs are redundantly connected together with fast connections that deliver low-
latency using multiple tier-1 transit providers.

™
EC2 Compute EC2, EC2 instances, Instance
types, networking speed
Amazon EC2

™
EC2 Compute
❖ Resizable compute capacity in the cloud
❖ Compute: computational power needed for your use case
❖ Add compute resources as needed (IaaS)
❖ EC2 allows you to launch instances
❖ instance is a server
❖ install whatever software you need: NGINX, Apache httpd, Cassandra, Kafka,
etc.
❖ Pay for compute power that you use
❖ Different instance types with various ranges of CPU, RAM, IO, and networking
power
❖ Pay for compute resources by hour or longer
Amazon EC2

™
EC2 Compute

™
EC2 Instance Types
❖ Defines the size/power of virtual server
❖ Many types of EC2 instances - Families of instance type
❖ Virtual CPUs (vCPUs)
❖ vCPU is a hyperthread of an Intel Xeon core for M4,
M3, C4, C3, R3, HS1, G2, I3, and D2.
❖ Memory RAM (size and type)
❖ Network performance
Amazon EC2

™
Families of types – Part 1
❖ T2 - inexpensive and burst-able (good for less expensive and
more sporadic workloads)
❖ M4 - new generation of general purpose instances (added
clustering and placement groups to M3)
❖ C4 - compute optimized like M4 but less memory and more
vCPUs (use this if you are not using all of your M4 memory)
❖ P2 - GPU intensive applications (Machine learning)
❖ G2 - graphics-intensive applications (server-side graphic
workloads)
What are the two most likely of these families that
you would use with Cassandra?
Amazon EC2

™
Families of types – Part 2
❖ X1 - memory optimized for in-memory computing (SAP,
HANA)
❖ R3 - memory intensive databases and distributed
caches (MongoDB)
❖ I3 - High IOPS at lower cost, SSD instance storage
(MongoDB, RDBMS)
❖ D2 - High IO throughput and large disks at lower cost,
magnetic instance storage (MapReduce, Kafka)
What are the two most likely of these families that
you would use with Cassandra? Why?
Amazon EC2

™
AWS EC2 AMI
❖ AMI is a Amazon Machine Image (AMI)
❖ Contain info on how to launch EC2 instance
❖ AMI are specified when an EC2 instance is launched
❖ Has template for the root volume for the instance
❖ Tied to an account or public
Lives in one region, but can be copied:
aws ec2 copy-image --source-region us-west-2
--source-image-id ami-6db3310d
--name CassandraClusterAMI

™
Amazon Elastic
Block Storage
Virtual volumes
SSD
Magnetic
Amazon EBS

™
Elastic Block Storage (EBS)
❖ Amazon Web Services (AWS) provides Amazon
Elastic Block Store (Amazon EBS) for EC2 instance
storage
❖ EBS virtual hard drives and SSDs for your virtual
servers (EC2 instances)
❖ EBS volumes are automatically replicated in same AZ
❖ Easy to take snapshots of volumes (back up)
❖ Advantages: reliability, snapshotting, resizing
Amazon EBS

™
AWS EBS

™
EBS Volume types
❖ Four EBS volume types
❖ Two types of Hard Disk Drives (HDD) (Magnetic)
❖ Two types of SSDs
❖ Volumes differ in price and performance
❖ EC2 instance can have many EBS volumes attached
❖ EBS volume can only be attached to one EC2 instance
at a time
Amazon EBS

™
Magnetic Volumes - HDD
❖  Magnetic volumes can’t be used as a boot volume.
❖  Lowest performance for random access
❖  least cost per gigabyte
❖  highest throughput (500 MB/s) for sequential access
❖  Magnetic volumes average 100 IOPS, but can burst to hundreds of IOPS.
❖  Good for services like Kafka which writes to a transaction log in long streams,
❖  Good for databases which use log structured storage or log structured merge
tree
❖ LevelDB, RocksDB, Cassandra
Amazon EBS

™
Good use cases for Magnetic
Volumes
❖ streaming workloads which require cost effective, fast,
consistent I/O
❖ big data
❖ data warehouses
❖ log processing
❖ Databases which use structured merge tree
Amazon EBS

™
Two types of Magnetic
Volumes
❖ st1 - Throughput Optimized HDD
❖ sc1 - Cold HDD and most cost effective
Which would be better for a Cassandra production system
with low reads but large rows with frequent writes?
Amazon EBS

™
General-Purpose SSD (gp2)
1
❖ Cost effective, and useful for many workloads.
❖ Minivan of EBS
❖ Performance of 3 IOPS per gigabyte provisioned
❖ 250 GB volume you can expect a baseline of 750 IOPS
❖ Peak capped @ 10,000 IOPS
❖ Sizes range from 1 GB to 16 TB
❖ Use Cases: Databases that use some form of BTrees (MongoDB,
MySQL, etc.).
❖ Geared to a lower volume database or one that has peak load times
but long periods at rest where IOPS credits can accumulate
Amazon EBS

™
General-Purpose SSD (gp2)
2
❖ Can be used for boot volumes
❖ Under 1 TB these volumes burst to 3,000 IOPS for extended periods of time
❖ Unused IOPS get accumulated as IOPS credits which can be used with bursting
❖ IOPS credits is like a savings account
❖ As you are using it, the bank account is being withdrawn from
• Use Case
• A server than does periodic batch or cron jobs
• Low-latency interactive apps
• Medium-sized databases
Could you use this for Cassandra? If your Cassandra Cluster had 12 nodes
And you got max 12,000 reads per second across the cluster and max
120,000 writes per second what size gp2 would work per node assuming
the cluster grows 2 TB per year?
Amazon EBS

™
Bursting
Credit Amazon Documentation for both images
Amazon EBS

™
Provisioned IO (io1)
❖ For I/O intensive workloads
❖ Most expensive EBS option
❖ IOPS up to 20,000 - you can purchase IOPs
❖ Use Cases
❖ Mission critical business applications that require
sustained IOPS performance
❖ Databases with large, high-volume workloads
❖ For developers bad at math
Amazon EBS

™
EBS Type Review
How can Cassandra use HDD and get 1,000 IOPs? 3 ways
Amazon EBS

™
EBS Volumes
EC2 m4
200 GB
200 GB
200 GB
200 GB
EBS Non-provisioned
IOPs
Max IOPs for read?

™
EBS Volumes
EC2 m4
EBS Non-provisioned IOPs
Max IOPs for random read?
2 TB
2 TB
2 TB
2 TB

™
EBS Volumes
EC2 m4
EBS Non-provisioned IOPs
4 TB
4 TB
4 TB
4 TB
4 TB4 TB
4 TB
4 TB
4 TB
4 TB

™
EBS Volumes
EC2 m4
Provisioned IOPs
200 GB
200 GB
200 GB
200 GB

™
EBS Volumes
EC2 i3 4x Large
1.9 TB
1.9TB

™
NOT EBS: Instance storage
❖ Don’t forget you don’t have to use EBS
❖ Instances storage is faster than EBS
❖ EC2 instance types with instance storage are expensive
❖ No server area network (SAN) or IO over network
Amazon EBS

™
EBS Optimized
❖ Newer EC2 instance types support EBS Optimized
❖ Higher throughput
❖ Less jiggle
❖ More reliable
❖ Don’t use C3 or M3 use C4 and M4
❖ Uses Optimized by default
❖ New Feature added in Feb 2017: Elastic Volumes!
Amazon EBS

™
EBS: Don’t just guess
measure
❖ Make educated guess to pick the right EBS based on workload
❖ Deploying Kafka or Cassandra or MongoDB then you must
understand how to configure the tool
❖ Smaller nodes but more of them, or less nodes with larger
EBS volumes
❖ JBOD, RAID 1, etc.
❖ Use Amazon CloudWatch
❖ watch IOPs and IO throughput
❖ while load testing or watching production workloads
❖ quickest and best way to pick best EBS volume type
Amazon EBS

™
Snapshots - EBS backups
❖ Data safety with EBS - Backup/Recovery (Snapshots)
❖ Amazon EBS allows you to easily backup data by taking
snapshots
❖ Snapshots are point-in-time backups
❖ Snapshots provide incremental backups of your data
❖ Snapshots just saves the blocks that have changed
❖ Only changed blocks since last snapshot saved in new
snapshot
❖ Only last snapshot needed to restore the volume
EBS Snapshots
A Cassandra node goes down, and its EBS volume is corrupt
and you have snapshots for this volume. Would it be faster to spin up an new
instance with a volume created from the last snapshot or just let Cassandra repopulate the node?

™
Taking Snapshots
❖ Snapshots are done with:
❖ AWS Management Console
❖ Scheduled snapshots
❖ AWS API - AWS CLI
❖ snapshots backed by S3 but you can’t see them
❖ Snapshots are stored per region
❖ Use snapshots to create new EBS volumes
❖ Snapshots can be copied to other regions
EBS Snapshots

™
Best Practices for Snapshots
❖ Test the process of recovering your instances from
snapshots if the Amazon EBS volumes fail
❖ Use separate volumes for the operating system versus
your data
❖ Make sure that the data persists after instance
termination
❖ Don’t use instance store for database storage, unless
you are using replication
EBS Snapshots
You wrote a Chef or Ansible script to update the JDK and Cassandra.
Should you perform a snapshot before you run this?

™
VPC Software defined networking
Amazon VPC

™
VPC: 1 public and two private
subnets
Amazon VPC

™
Amazon VPC
❖ Software defined networking
❖ Virtual private cloud
❖ Multiple VPCs can live in a AWS region
❖ VPC can span multiple availability zones
❖ Isolated area to deploy Amazon EC2 instances
❖ Associated with a CIDR block
❖ DHCP Options
Amazon VPC

™
CIDR Block
❖ /# denotes the size of the network
❖ how many bits of the address will be used for the network
❖ Example: 10.10.1.32/27 denotes a CIDR range (also known as CIDR block).
❖ First 27 bits of address is for the network (32 bits total)
❖ 32 - 27 leaves five bits for your servers. 00000-11111
❖ First five addresses are reserved in a subnet, and the last address is reserved for broadcast
❖ Example leaves us 26 addresses for our servers (10.10.1.37 to 10.10.1.61)
❖ VPC address range may be as large as /16 (32-16 = 16 bits which allows for 65,536 available
addresses)
❖ or as small as 16 addresses (/28 is 32 - 28 = 4 bits which is 16 available addresses)
❖ Addresses of two VPC should not overlap if you plan on adding VPC peering.
Amazon VPC

™
CIDR Block Diagram
Amazon VPC
Source WikiPedia

™
Components of VPC
❖ Made up of subnets, route tables, DHCP option sets,
security groups, and Network ACLs.
❖ Can also have Internet Gateways (IGWs), Virtual
Private Gateways (VPGs), Elastic IP (EIP) addresses,
Elastic Network Interfaces (ENIs), Endpoints, Peering,
and NAT gateways
❖ A VPC has a router defined by its route tables
❖ per subnet and default
Amazon VPC

™
CloudFormation for VPC
Amazon VPC

™
VPC Subnets
❖ Part of an VPC’s IP address range
❖ Has CIDR blocks
❖ Associated with availability zones
❖ Can be public or private
❖ Private subnet has no route from the IGW (Internet
Gateway)
Amazon VPC

™
CloudFormation VPC Subnet
Amazon VPC

™
Internet Gateway
Amazon VPC

™
Internet Gateway
❖ Internet Gateway (IGW) enables inbound traffic from the public
Internet to your VPC
❖ Public subnets have route tables that target IGW
❖ IGW does network address translation from public IPs of EC2
instances to their private IP
❖ EC2 instance send IP traffic from a public subnet, the IGW acts as
the NAT for public subnet,
❖ translates the reply address to the EC2 instance’s public IP
(EIP)
❖ IGW keep track of the mappings of EC2 instances private IP
address and their public IP address
❖ Highly available and handles the horizontal scale, redundancy as
needed
Amazon VPC

™
Route Tables
Amazon VPC

™
Subnet Route Tables
❖ contain set of ingress and egress rules (aka routes)
❖ rules are applied to subnet
❖ connect subnets within a VPC so they can communicate
❖ routes direct network traffic
❖ routes are specified by CIDR and a target
❖ most specific route that matches traffic determines traffic route
❖ if subnet has route to the InternetGateway then public
❖ Each subnet associated with a route table (default route table)
Amazon VPC

™
CF: Route from Pub Subnet to
IGW
Amazon VPC

™
VPC VPN Access via VGW and
CGW
❖ AWS to augment your existing IT infrastructure via VPN
❖ Connect existing datacenter to VPC using VPG (Virtual Private Gateways)
and CGW (Customer Gateways)
❖ VGW like the IGW but it sends traffic to/fro your corporate network instead of the public
Internet
❖ VPGs connect to your companies - VPG is the Amazon side of the VPN connection
❖ CGW is the customer side of the VPN connector
❖ CGWs are processes running on a server or network device.
❖ Connect a VPG and a CGW with a VPN tunnel
❖ Uses the IPSec to connect VPC to corporate network
❖ Use dynamic routing or static routes
Which subnets in a given VPC would have access
to the corporate internet connected via the VPN?

™
NAT Gateway and EIP
Amazon VPC

™
Elastic IP (EIP)
❖ AWS pool of public IP addresses - Available to rent per region
❖ Check out EIPs to use and assign - Allows you to keep same Public IP
❖ Example: Assign an EIP to an instance (and only one)
❖ Spin up a new upgraded version of the instance from a snapshot or
with Ansible, Chef, etc.
❖ Reassign the EIP to the new upgraded instance.
❖ Allow public IPs to be reassigned to new underlying infrastructure
❖ Allocated in a VPC, can be moved to another same region VPC
❖ Assigned to resources like EC2 instances, Nat Gateways, etc.
Amazon VPC

™
Nat Gateways
❖ Needed so Amazon EC2 instances launched in a private subnet cannot access the
Internet
❖ NAT is a network address translator
❖ Why? yum install foo, you could not do it because instance by default have no route to
the public Internet.
❖ Similar to IGW but unlike IGWs they do not allow incoming traffic
❖ Only allow responses to outgoing traffic from your Amazon EC2 instances
❖ To maximize failover you will want to deploy a NAT gateway per AZ
❖ To setup
❖ Set up the route table by connecting private subnet to direct Internet traffic to
the NAT gateway
❖ Associate the NAT gateway with an EIP (covered shortly - elastic IP)
Amazon VPC

™
CloudFormation for NAT GW
Amazon VPC

™
Placement groups per AZ
❖ Amazon Enhanced networking by using
❖ Placement groups
❖ Instance types m4, c4, p2, g2, r3, g2, x1, i2 and d2
support enhanced networking/placement groups
❖ Essential for high-speed server to server performance
which is important for clustering
❖ To achieve maximum throughput, placement groups
must be placed in the same AZ – 10Gbits
Why would this be important for Cassandra? Other systems?
Amazon VPC

™
Elastic Network Interface ENI
❖ ENI is a virtual network interface - network interface in AWS speak
❖ Can attach to EC2 instance in a VPC - detach an ENI and attach to another
EC2 instance
❖ Attributes : description, primary private IPv4 address, multiple secondary private
IPv4 addresses, EIP per private address, public IPv4 address, multiple IPv6
addresses, multiple security groups (at least one), MAC address,
source/destination check flag
❖ Keeps its attributes no matter which EC2 instance it is attached to
❖ If an underlying instance fails, the IP address (MAC, public IP, EIPs, etc.) are
preserved
❖ Makes EC2 instances replaceable - low-budget, high-available solutions
What special Cassandra nodes might benefit from using an ENI
to keep their private IP constant even if instance goes down?
How are ENIs different than EIPs? How are they similar?
Amazon VPC

™
Security Groups
Amazon VPC

™
Security Groups (SG)
❖ stateful firewall - controls inbound and outbound network traffic
to EC2 instances and AWS resources
❖ Stateful means an Amazon instance (or resource) is allowed to
respond to an inbound traffic with outbound traffic
❖ EC2 instances have to be associated with a security group
❖ Rules are only allow rules
❖ Rules consist of the following attributes:
❖ Source (CIDR or SG id)
❖ Protocol (TCP, ICMP, UDP, HTTP, HTTPS, SSH, etc.)
❖ Port range (8000-8080)
Amazon VPC

™
CloudFormation SG Bastion
Amazon VPC

™
CloudFormation SG
Cassandra
The above allows all traffic from the VPC’s
CIDR to access this box.
-1 means all ports.
Private Subnet
Amazon VPC

™
CloudFormation SG
Cassandra
What is different about this SG for Cassandra than the last one?
How could we narrow which EC2 instances access Cassandra nodes?
Amazon VPC

™
CloudFormation: NACL
Amazon VPC

™
Network ACL (NACL)
❖ Amazon Network Access Control List (NACL)
❖ Stateless firewall
❖ Provides a number ordered list of rules
❖ Lowest number rule evaluated first
❖ First rule that allows or denies wins
❖ Has both allow rules and deny rules
❖ Return traffic must be allowed (stateless)
❖ Applies to the whole subnet
How does this compare to Security Groups?
Amazon VPC

™
CloudFormation for NACL
Amazon VPC

™
VPC Peering
❖ Networking connection between two VPCs
❖ Enables routing traffic between private IP addresses
❖ As if VPCs are on the same network
❖ Both VPC must be in the same AWS Region
❖ CIDR addresses of VPCs can’t have conflict/overlaps

™
Related important
AWS Concepts
Important AWS concepts
helpful for DevOps of
clustered software
Amazon VPC

™
AWS Important Concepts
❖ Auto Scaling
❖ used scale Amazon EC2 capacity up or down automatically
❖ autoscale a group of instances based on workload
❖ used to recover when instances go down by automatically spinning
up an instance to take its place
❖ Amazon Route 53
❖ DNS as a service. Route 53 is highly available and scalable
❖ Easily assign DNS names instead of configuring with public IP
addresses (internal and external)
❖ Amazon CloudFormation: allows developers, DevOps, and Ops create
and manage a collection of related AWS resources
Could you use Route53 instead ENI for seed servers?
Amazon VPC

™
Aws CMD: CloudFormation
Route53
Create a DNS name for a public IP address from an EC2 instance
Create a new CloudFormation stack (like JSON file from earlier)
Amazon VPC

™
More important AWS
concepts
❖ IAM
❖ AWS Identity and Access Management (IAM) enables secure control access to AWS Cloud
services and resources for their users
❖ Defines IAM defines, users, roles, and allows you to apply this to EC2 instances as well as users
or groups of users (example in notes)
❖ KMS
❖ AWS Key Management Service (KMS) allows you to create and control the encryption keys
❖ Uses Hardware Security Modules (HSMs) to protect the security of your keys
❖ Used to encrypt Amazon EBS volumes, Amazon S3 buckets and other services.
❖ S3
❖ Amazon Simple Storage Service to store your backups and big data.
❖ Good for backups of Cassandra snapshots
Amazon VPC

™
Amazon CloudWatch
❖ Monitoring service it uses for its AWS Cloud resources and services
❖ Can be used for your services and applications
❖ Track key performance indicators (KPIs) and metrics
❖ Log aggregation, and can easily create alarms.
❖ Trigger AWS Lambda functions based on limits of an KPI or how often an item shows up
in log stream in a give period of time
❖ Provides system-wide visibility into resource utilization, and operational health
❖ Not passive – Action oriented
❖ Integration with the entire Amazon ecosystem **integration!
❖ Actionable: Triggers and events to keep everything running smoothly
Amazon VPC

™
AWS Guidelines Details on how to configure
Cassandra in EC2

™
Cloudurable Amazon
Cassandra Guidelines
Support around Cassandra
and Kafka running in EC2

™
Cassandra on
AWS Best Practices!

™
Cassandra on AWS
❖ Apache Cassandra is extensively deployed in AWS
❖ Estimated 60,000 AWS customers also use Cassandra
❖ Estimated 1/3 of Cassandra are on AWS
❖ More AWS users use Cassandra than DynamoDB
❖ AWS published guide: Deploying Cassandra on AWS in
2016
AWS Cassandra Support

™
Cassandra AWS
Overview
Cassandra Architecture
Review
AWS Cassandra Architecture

™
What is Cassandra?
❖ Linearly scalable, open source NoSQL database
❖ Uses log-structured merge-tree
❖ Supports high-throughput writes
❖ continuous availability, with operational simplicity
❖ master-less peer-to-peer distributed clustered store
❖ each node knows about cluster network topology via
gossip

™
AWS Cassandra Concepts:
Cluster
❖ Cassandra node runs on EC2 instances
❖ Cassandra cluster can span AZs and Regions
❖ Cassandra Cluster consists of Data centers, racks,
nodes
❖ AWS AZ equate to Cassandra racks
❖ Amazon regions equate to Cassandra data centers
❖ AZs should equate to a multiple of replication level

™
AWS Cassandra Concepts:
Commit log and in-memory
❖ Commit logs are write-ahead logs used for Cassandra
node recovery – sequential append write - only read for
recovery
❖ Must but commit log on separate EBS volume if
magnetic
❖ Memtables, key cache, row cache, in-memory bloom
filters, in-memory index files, OS buffers for disk and
TCP/IP, all require lots of memory
❖ Pick EC2 instances with enough DRAM

™
AWS Cassandra: SSTable,
Keyspace
❖ SSTable and Commit log should be stored on separate
EBS volume (especially if not SSD)
❖ SSTable disk representation of Memtable
❖ Type of compaction can range between 20% and 50%
overhead
❖ Account for this when allocating EBS volumes
❖ Keyspaces dictate replication factors, more can mean
more IO (IOPs and network bandwidth needs)

™
AWS Embrace Change!
❖ AWS rules keep changing
❖ Faster, more reliable, more competition
❖ Prices keep changing (dropping)
❖ AWS knowledge of EC2, EBS, etc. three or five years
ago is ancient now
What AWS or EC2 rule has changed since you started working with AWS?

™
AWS EC2 Instance
Types for Cassandra AWS EC2 Instance types to
consider for Cassandra
AWS Cassandra Storage Reqs.

™
High CPU to memory ratio

™
If in doubt, start with M4

™
Perfect for Cassandra high-speed, small sized reads. Critical path. No KMS encryption.

™
Could be used in an analytics Cassandra DC that is connected to another
DC that uses SSD for frequent small reads.
Starts at 6TB per node. IoT device monitoring.

™
Storage optimizedGeneral Purpose
General Purpose
Trivia what is ECU? What does vCPU equate to?

™
Cassandra AWS
Storage
Guidelines
Cassandra storage
requirements for Amazon EC2
and EBS

™
Cassandra AWS - Storage
Requirements
❖ Cassandra does lots of sequential disk IO (commit logs,
SSTables)
❖ Cassandra writes large streams of data to commit logs
SSTable, index files and bloom filter files
❖ Put commit log on separate disk (EBS volume) than
SSTables
❖ Maybe ok if using SSD
❖ Never if HDD, always separate volume if HDD

™
Consider EC2 Instance
Storage
❖ AWS provides EC2 instance local storage called instance
storage
❖ Available with some EC2 instance types
❖ Instance storage unlike EBS does not go over a SAN or Intranet
– less worry from traffic congestion, noisy neighbors
❖ Instance storage uses local hardware bus – can be as fast as
real disks on real server
❖ More Expensive! - Less flexible
❖ More reliable than EBS ** see notes (EBS bad reputation)
❖ Historically the only real option for running Cassandra nodes in
EC2

™
Prefer EBS
❖ Historically EBS did not work well with Cassandra
❖ You will read old AWS Cassandra guides that tell you to use EC2 instance
storage
❖ Until recently (2015) using Cassandra and AWS EBS was not a good idea
❖ Latest generation of EBS-optimized instances offer performance and improved reliability
❖ EBS volumes best pick for price for performance
❖ If in doubt start with EBS-optimized instances
❖ EBS has nice features like snapshots, and redundancy
❖ NEW! EBS elastic volumes, provisioned IO
❖ EBS is more flexible, and less expensive
❖ Other ways to improve reliability with Cassandra and AWS (replication)
❖ Supports high-speed encryption (i3 would need OS encryption or JDK)

™
EBS-Optimized Instances
❖ C4, M4, and D2 instances use EBS-Optimized by default
❖ Delivers up to between 500 and 4K Mbps throughput
❖ Dedicated connection minimizes contention between Amazon
EBS I/O and other traffic from your EC2 instance
❖ Standard (10K IOPs) and Provisioned IOPS (20K IOPs) Amazon
EBS volumes
❖ 65K IOPs max per EC2 instance
❖ Provisioned IOPS volumes (expensive) can achieve single digit
millisecond latencies and are designed to deliver within 10% of
the provisioned IOPS performance 99.9% of the time
❖ Standard IOPs supported is a function of EBS volume size
If using Cassandra, JBOD how many volumes minimum would I need to get up to
65K IOPs with standard EBS optimized volume? With provisioned IOPs?

™
Credit AWS Docs

™
Cassandra EC2 instance good
picks
❖ M4 (or C4) and I3 family mainly used
❖ I3 came out end of last year (still rolling out in some regions)
❖ I3 has instance storage
❖ I3 super fast IO, fairly low cost
❖ Benchmark of M4 against I2 (previous generation)
❖ I2 was 8x perf of M4 for tiny read/writes
❖ About the same for medium size read/writes
❖ Consider D2 for large storage needs and high throughput
(less expensive) uses HDD instance storage
What is the max total IOPS with M4?
What is the max total IOPS with I3?

™
SSD vs HDD
❖ If in doubt use ESB SSD
❖ SSD has higher read speed / IOPS (random access, seeking
key)
❖ You can use SSD with provision IOPS to improve read access
(expensive)
❖ Magnetic disks (HDD) have higher throughput but lower IOPS
❖ AWS guide says don’t use, benchmarks say works for some
use cases
❖ Increase HDD IOPS by using instance store or JBOD
❖ Cheapest throughput and storage of volume options

™
Take Replication into Account
❖ Keep replication strategy into account when sizing EBS
volumes and instance stores
❖ SSTable Compaction data makes heavy use of disk
❖ LeveledCompactionStrategy needs 10 to 20%
overhead for compaction (faster reads)
❖ SizeTieredCompactionStrategy worse case is 50%
overhead for compaction (faster writes)
❖ Improves read speed (spikier CPU)

™
RAID, JBOD, Read speed
❖ If RAID, use RAID 0
❖ Not needed for data safety because EBS provides it
as does Cassandra
❖ Prefer JBOD to RAID 0
❖ Just mount EBS volumes for JBOD
❖ JBOD is just a bunch of disks (added in Cassandra 3)
❖ JBOD helps with read speed (more so than RAID 0)

™
EBS Elastic Volumes and Linux File
Systems
❖ New EBS elastic volumes goes well with ext4 and XFS
❖ AWS Elastic volume added 2/2017, you can change
EBS type on running node!
❖ Prefer XFS Linux file system or Ext4 is ok
❖ For ext4, you will need to expand the volume using
❖ sudo resize2fs /dev/xvda1
❖ For XFS expand volume with
❖ sudo xfs_growfs -d /mnt.

™
Cassandra Encryption at Rest
use KMS
❖ If you need data at rest encryption, use encrypted EBS
volumes / KMS
❖ AWS KMS uses hardware-assisted encryption
(Hardware Security Modules)
❖ Faster than JDK based encryption and built into EBS
❖ Same IOPS performance as unencrypted volumes
❖ Use KMS so you can rotate keys and expire them
❖ KMS encryption does not work with EC2 instance
storage

™
EBS problems and
workarounds
❖ EBS has been know to degrade over time
❖ Watch for EBS issues like poor throughput, performance
degrading over time, and instances not cleanly dying
❖ Watch with CloudWatch
❖ Cloudurable provides AMIs which can be monitored using
Amazon CloudWatch (installs systemd processes)
❖ Linux OS log aggregation, and Cassandra log aggregation into
CloudWatch logs
❖ OS metrics and Cassandra metrics into CloudWatch metrics
❖ Have a plan to retire problem Cassandra Nodes and spin up new
ones – yes we have experienced these problems as recent as
2016

™
Ways to Improve Cassandra Read
Speed
❖ Horizontally scale Cassandra (more nodes)
❖ Use instance store (super fast IO)
❖ Buy provisioned IOPs – or bigger SSDs
❖ Add more disks to each node using JBOD (more disks)
❖ More EBS volumes or
❖ EC2 instances with more SSDs or Disks
❖ Use a bigger key-cache, row-cache (more memory)
❖ More disk space for SizeTieredCompactionStrategy
What would you need to make sure of if you added a materialized
view on a large table to improve read speed? WRT to EBS

™
Cassandra AWS
CPU Guidelines
Cassandra CPU requirements
with Amazon EC2
AWS Cassandra CPU Guidelines

™
Cassandra CPU Reqs for AWS
Cloud
❖ Cassandra is highly concurrent
❖ Cassandra nodes can uses as many CPU cores as
available if configured correctly
❖ An Amazon EC2 vCPU is a hyper thread
❖ often referred to as a virtual core
❖ Physical thread of execution worker

™
Cassandra high-speed writes = CPU
bound
❖ Cassandra clusters insert heavy workloads can be CPU-bound
❖ Potential to be multiplied if using JBOD - 4 or 8+ volumes
❖ Cassandra is efficient for writes, but does CPU intensive structured merge sort during compaction
❖ Writes are almost never IO bound, concurrent_writes (workers) depends on vCPU in EC2
Cassandra node instance
❖ concurrent_compactors should be set to
❖ # of vCPUs if using SSDs
❖ number of attached EBS volumes for JBOD
❖ unless you are having GC issues than set to max 4
❖ More vCPU resources your Cassandra node has, the faster compaction throughput
❖ See this Cassandra tuning guide for more information, and this JIRA ticket.

™
Compaction strategy and CPU
usage
❖ Compaction strategy can influence CPU Spikes
❖ SizeTieredCompactionStrategy works with larger
SSTables so has more spikey CPU
❖ Need for faster writes
❖ LeveledCompactionStrategy will use a more even
level of CPU
❖ Needed for more consistent CPU usage
❖ Needed for faster reads

™
Use 8 vCPUs for prod
❖ In general use, 4 to 8 vCPUs for Cassandra Nodes minimum
❖ You need at least 4 cores but prefer 8 cores for a production
machine (add more as needed per use case)
❖ Why 8 to start? Compaction, compression, key lookup based on
bloom filters, SSL if enabled, all need CPU resources
❖ m4.xlarge ok for development testing (4 vCPUs)
❖ m4.2xlarge 8 vCPUs should handle most production loads nicely
❖ Use i3.2xlarge (for high random and small reads)
❖ Use d2.xlarge for high writes and long sequential
❖ Use c4.2xlarge for use cases with few cache hits

™
CPU Usage for GC1 Garbage collector
and CMS
❖ GC1 Garbage collector and the CMS garbage collector benefit
from having more threads (i.e., may need more EC2 vCPUs)
❖ When working with large Java heap sizes, GC1 and CMS can
benefit from parallel processing which requires more EC2
vCPUs
❖ CMS can really use more CPU!
❖ Habit of turning memory eventually into Swiss cheese
❖ Eventually needing a full, stop the world garbage collection
❖ GC1 does not have this same problem with memory
fragmentation, which is why CMS is deprecated in Java 9.
What happens if a node under heavy load has a stop the world GC?

™
Multi Region/DC need more EC2
vCPUs
❖ If you are using multiple regions, i.e., a multi-dc deployment
increase max_hints_delivery_threads as cross DC
handoffs are slower
❖ Also keep in mind for cluster/storage communication that
there is more CPU overhead, which might be a wash if the
DC to DC communication has a lot of latency, using SSL,
then more too
❖ How many threads do you need? How eventually consistent
do you want to be between data-centers? And how long will
these threads be waiting for IO?
❖ Don’t just consider happy case, but unhappy case

™
Cassandra workloads with large
datasets
❖ Cassandra workloads that can’t fit into main memory,
❖ Cassandra’s bottleneck will be reads that need to fetch
data from disk (EBS Volume or local storage)
❖ concurrent_reads should be set to (16 *
number_of_drives)
❖ potential with JBOD 4 of having 64 read threads
❖ Use EC2 instance with more memory?

™
Cassandra with high volume of
writes/streams
❖ Doing a lot of streaming writes between nodes?
Increase memtable_flush_writers
❖ If streaming a lot of data from many nodes
❖ you need to increase the number of flush writers (memtable_flush_writers).
❖ If you do not have enough writers to deal with a (larger than normal) amount
of data hitting them you can cause your streams to fail
❖ recommendation is to set memtables_flush_writers equal to the number of
vCPUs on the EC2 Cassandra node instance
❖ EC2 instance with more vCPUs allows more throughput for writes
❖ Instance Storage SSD increase: memtable_flush_writers *
data_file_directories <= # of vCPU.
❖ Instance storage HDDs or EBS SSD use memtable_flush_writers = #vCPUs

™
Horizontal scale is not always possible with
Cassandra
❖ When you are using Cassandra for super high-speed
writes or using it with very large datasets
❖ You may have to scale up your Cassandra nodes and
add more vCPU and memory by using larger EC2
instances
❖ Vertical scale-up is also needed in some cases
❖ When horizontally scaling, Cassandra does a lot of
streaming, you could make instances larger (gradually),
add your nodes, and then gradually make the
Cassandra instances smaller

™
EC2, Cassandra and NUMA
❖ i3.8xlarge+, m4.10xlarge+ - Non-Uniform Memory Architecture(NUMA) controls are
available.
❖ Transferring memory between CPU sockets more expensive
❖ Cassandra uses numactl –interleave by default
❖ Add -XX:+UseNUMA to cassandra-env.sh
❖ JVM can handle NUMA directly
❖ GC divide GC efforts across domains
❖ Cassandra uses modified SEDA most likely NUMA pin not as needed
❖ prefer using a smaller EC2 instance before NUMA pin
❖ If you are running running other JVM processes (examples in notes), Force JVM
bind to NUMA node, so all memory is local, and all threads will execute on the same
core (speed)
Read Al Tolbert blog post on Cassandra tuning

™
CPU Cache sizes
❖ Use latest generation of EC2 instances as they have
larger L1 and L2 cache sizes (between 25 MB and 30
MB of on CPU cache)

™
AWS Cassandra
System Memory
Guidelines
Cassandra system memory
guidelines for Amazon EC2
AWS Cassandra System Memory Guidelines

™
Basic System Memory
Guidelines
❖ Do not use less than 8GB JVM Heap
❖ More RAM the better for Cassandra
❖ Use G1GC
❖ EC2 instance m4.xlarge has 16GB of memory use this
or higher (m4.xlarge is light on CPU)
❖ i2.xlarge and d2.xlarge exceed min memory
requirements

™
Cassandra JVM Heap Usage
❖ Bloom filters
❖ Partition summary
❖ Partition key cache
❖ Compression offsets
❖ SSTable index summary
Some grow as JVM heap grows

™
Cassandra uses memory 4
ways
❖ Java heap
❖ Off-heap memory
❖ OS page cache
❖ OS TCP/IP stack I/O cache

™
Memory: More is better
❖ More memory the better
❖ If memory is available, Cassandra and the Linux OS can use it
❖ In Java heap, Cassandra can use memory for the key cache which can speed up
queries
❖ For smaller tables, that are read often, you can use the row cache which uses off-heap
❖ If cache hit rate is high, then there is less read IO
❖ In the NoSQL world, Cassandra is king for writes -Cache helps it have good marks
for reads
❖ Read-heavy system in EC2 Cassandra world,
❖ Might make sense to go into 60 GB to 120 GB (e.g., m4.4xlarge, i3.2xlarge)
❖ Above this range in EC2, and you have to worry about NUMA concerns

™
Cassandra needs OS
memory!
❖ OS memory should be 2x to 6x the size of the JVM!
❖ Cassandra relies heavily on the Linux OS page cache for
caching of data stored on EBS and local instances volumes
❖ Every read that the OS gets a cache hit on, means the data
is read from RAM not the EC2 volume,
❖ Linux OS Page Cache takes IOPs and throughput of the
EBS out of the equation
❖ Leave memory for the Linux OS!
❖ Leave some space for Linux IO buffers.

™
Cassandra Off-heap memory
usage
❖ Page cache
❖ Bloom filter
❖ Compression offset maps
❖ Row caches

™
Cassandra JVM vs Linux System Memory table
for EC2

™
JVM Garbage Collector for
Cassandra
❖ Due to Cassandra has some long lived objects on the heap…
❖ Choice in GCs come down to CMS and GCG1. Choose GCG1.
❖ General rule is don’t use GGC1 if your heap is under 5GB (some say 8GB, some 6 GB, Oracle
says under 1GB)
❖ You will notice on the preceding chart, no JVM configuration with a heap less than 5GB
❖ In General DON’T USE CMS! (see notes)
❖ Especially, do not use JVM CMS garbage collector if your JVM is over 16 GB (fragmented
memory, long stop the world GC)
❖ CMS is deprecated in JDK 9
❖ A case could be made for a heap size between 5 GB and 8 GB for CMS
Eden S0 S1 Tenured
Young Generation Old Generation
Image Credit: Ranjith Ramachandran

™
Eden S0 S1 Tenured
Credit : Oracle
Credit: Cloudera

™
Amazon EC2 instances taking CMS out of
equation!
❖ Note: Amazon has a Cassandra on Amazon guide that says
never use over 8 GB for JVM. This is a mistake! See note!
Eden S0 S1 Tenured

™
Guideline for GCG1 Cassandra
JVM AWS Cassandra System Memory Guidelines
GCG1 will self adjust using ergonomics and runtime statistics.
The only setting that you really need to set is –XX:MaxGCPauseMillis.
Very Large Heap Low Pause
Credit: Intel: HBaseCon

™
GC settings for both CMS and
GCG1 AWS Cassandra System Memory Guidelines

™
Don’t use CMS
❖ Don’t use CMS
❖ If you need JVM heap between
5GB and 8GB, and having an easy
to configure, reliable systems does
not win out over raw speed, then
maybe CMS
❖ Remember, take CMS out of
equation by
using m4.2xlarge and i3.2xlarge as
smallest EC2 instances for
Cassandra
❖ Definitely do not use CMS above
8GB JVM heap
• CMS is deprecated in Java 9
• CMS is harder to tune
• CMS has problems with fragmented memory
• GCG1 is the replacement
• GCG1 is easier to tune
• Better to learn how to tune GCG1 now
• Harder to reach 99.9 SLAs

™
Guide to using CMS
BTW Don’t use CMS

™
Credit: Image source Intel from talk at HBaseCon2015
After: Very Large Heap Low Pause Credit: Intel: HBaseCon

™
Take pressure off JVM GC by using
off-heap
❖ Reduce pressure garbage collection
❖ Cassandra uses native libraries to
allocate memory if available.
❖ Ensure JNA and JEMALLOC are
installed on Linux machine Amazon
AMI
❖ yum install -y jna
❖ yum install -y jemalloc
❖ If you are creating an Amazon AMI
image with both of those
❖ Use offheap_objects
❖ Modify memtable space by changing
the memtable_heap_space_in_mb and
memtable_offheap_space_in_mb
Credit: Facebook
Tech Talk
On JEMalloc

™
Cassandra Networking
Guidelines
requirements with Amazon
EC2

™
AWS Networking for
Cassandra
❖ AWS EC2 has placement groups / enhanced networking
❖ Allow high-speed throughput for clustered software like Cassandra (10GBE)
❖ Networking is important to Cassandra due to replication of data
❖ Most deployments an AZ is treated like a rack, and Cassandra tries to store
replica data on nodes that are in a different rack (in EC2’s case a different AZ)
❖ EC2 placement groups and enhanced networking only works per AZ
❖ Most common use case of Cassandra cluster network would not use enhanced
networking (placement groups) at all
❖ Now if you replicate higher than 2 then some replication will happen within the
same AZ and placement groups (enhanced networking) could speed that up
❖ Go ahead and use enhanced networking, it helps with quorum reads and writes

™
Cluster Networking
❖ R4, X1, M4, C4, C3, I2, CR1, G2, HS1, P2, and D2 support
cluster networking aka enhanced networking
❖ Cassandra EC2 Instances launched into placement group form
a logical EC2 cluster
❖ provides high-bandwidth, low-latency networking between all
Cassandra EC2 instances in cluster
❖ Placement group per cluster per EC2 region
❖ Can Utilize up to 10 Gbps for single-flow
❖ 20 Gbps for multi-flow traffic in each direction
❖ Network traffic outside placement group limited to 5 Gbps

™
Enhanced networking vs.
none
Use enhanced networking!Enhanced Networking

™
10 GBE
❖ 10 GBE is the recommendation for high-performance
Cassandra clusters
❖ With M4 series you need m4.10xlarge to get 10GBE
❖ m4.16xlarge has 20GBE (two nics)
❖ c4.8xlarge supports 10GBE as well
❖ All I3 series support 10GBE (bonus point for I3)
What bandwidth do you think you would get with a m4.4xlarge?

™
Subnet per AZ for quorum
❖ What happens if the AZ goes down?
❖ Do your reads stop working?
❖ Do your writes stop working?
❖ Availability Zones <= Replication Factor

™
Failure Scenarios
Source/Credit Highscalability.com Todd Hoff

™
guidelines
❖ Deploy Cassandra nodes spread across multiple AZs
availability zones
❖ VPC subnet lives in a AZ, you need subnet per AZ
❖ Start with a replication factor of 3 combined with 3
availability zones
❖ Allows you to use local quorum reads and writes even
during a single AZ failure
❖ Use EC2 instances that support enhanced networking
and deploy them in the same placement group

™
What is a snitch?
❖ Snitch sets network topology
❖ Snitch determines where nodes live. Which Datacenter? Which Rack?
❖ Cassandra uses network topology information to distribute replicas
❖ Cassandra can also use this information
❖ To determine datacenter locality with local quorum writes and
reads
❖ To optimize client reads and writes with data consistency
❖ Why go to another datacenter to do a consistent read when there is a
server on the same rack backplane with a very low latency connection?
❖ When replicating data, info used to not put replica on the same rack

™
Review types of Snitches
❖ DynamicSnitch – Determines locality of Cassandra nodes by
performance of reads (runtime snitch)
❖ SimpleSnitch – single deployment datacenters – not rack
aware or data-center aware
❖ RackInffering Snitch – determines rack and datacenter by IP.
10.1.1.10 (Datacenter 1, Rack 1, Node 10) 10.2.3.10
(Datacenter 2, Rack 3, Node 10)
❖ GossipingPropertyFileSnitch – property file exposes rack,
server setup. Servers can be added through gossip.
❖ Cloud specific snitches

™
AWS: Stiches for Snitches
❖ There are two snitches specific for Cassandra running
on AWS
❖ EC2Snitch
❖ Treats AZs as Racks
❖ EC2MultiRegionSnitch
❖ Treats AZs as Racks
❖ Treats Regions as Datacenters

™
Pitfalls of EC2*Snitch
❖ Relies on EC2 API
❖ EC2 API has gone down for a time
❖ EC2 APIs are rate limited
❖ If you exceed, limit, no calls for you
❖ Keep Production and Development on two different
accounts

™
EC2Snitch AWS Setup P1
❖ AWS NAT Gateways are needed for security patches,
and software updates of nodes
❖ No incoming traffic just outgoing but can respond
❖ Private subnets are used for Cassandra Cluster
❖ Limit access to private subnets via route table, NACL
and security groups
❖ Only apps that need it, bastion, should have
access/routes

™
EC2Snitch AWS Setup P2
❖ Use Bastion Host to attach via ssh for public and corporate
access
❖ Bastion can be in a VPN Subnet or a Public Subnet
❖ Public Subnet can use IGW, host NAT Gateway
❖ Cassandra Seed servers
❖ At least one seed per AZ in case of outage
❖ Can use ENIs to keep same private IP
❖ Seed servers can be assigned internal DNS hostnames
via Route53

™
EC2Snitch layout 1 Region
VPC
Private Subnet 1
for Cassandra Cluster
Public Subnet 1
AWS Internet GatewayPrivate Subnet 2
Public Subnet 2
Private Subnet 3
Public Subnet 3
NAT Gateway
NAT Gateway
NAT Gateway
Seed
CN1
CN2 CN3 CN4
Seed
CN10
CN12 CN13 CN14
Seed
CN20
CN22 CN23 CN24
Bastion Host
AWS Region: us-west-2
AZ: us-west-2a
AZ: us-west-2b
AZ: us-west-2c
AZ: us-west-2a
AZ: us-west-2b
AZ: us-west-2c

™
Steps
❖ Step 1: Create AMI with all the goodies
❖ Step 2: Run cloud formation to form VPC
❖ Step 3: Launch EC2 instances
❖ Step 4: Login and make sure cluster is healthy

™
Step 1: create AMI
❖ Tools to monitor Linux OS to CloudWatch metrics
❖ Tools to monitor Cassandra KPIs to CloudWatch metrics
❖ Tools to send logs from Linux OS to CloudWatch logs
❖ Tools to send logs from Cassandra to CloudWatch logs
❖ Cassandra, and config files
❖ AWS command line tools for S3 backup of Cassandra
snapshots
❖ Tools to configure Cassandra with EC2

™
metricsd
Metrics daemon to collect OS metrics, Cassandra metrics,
and send results to AWS CloudWatch Metrics
metricsd

™
Cassandra Cloud
Generates
Cassandra YAML
From Template

™
Cassandra Image (examples)
❖ cassandra-image
❖ Packer (create
AMI image)
❖ Vagrant (create
cluster)
❖ CloudFormation
(create cluster)
❖ Ansible (manage
cassandra,
updates)
❖ Aws-cli

™
Step 1: Create AMI: Use Packer to create
AMIs
Read notes

™
Step 1: Build AMI with PackerRead notes!

™
Step 1: Build AMI Monitoring
tools Read notes!

™
Step 1: Build AMI : Log
aggregation Read notes!

™
Step 1: Build AMI : Install
Cassandra

™
AWS CLI is a must!
❖ You must use the AWS CLI!
❖ You can launch instances, query instances for their
public IP
❖ AWS CLI is the Swiss army knife of AWS cloud

™
AWS CLI: Common scripts
we use
❖ bin/ec2-env.sh - setups common AWS references to subnets,
security groups, key pairs
❖ bin/create-ec2-instance.sh - uses aws command line to create
an ec2 instance
❖ bin/login-ec2-cassandra.sh Uses ssh to log into Cassandra
node we are testing
❖ bin/get-IP-cassandra.sh Uses aws command line to get the
public IP address of the cassandra instance
❖ bin/run-vpc-cloudformation.sh - Launch cloud formation that
forms VPC, subnets, IGW, NGW, route tables, security groups
❖ Many more

™
AWS CLI: Common
Environment

™
AWS CLI: Create an EC2
instance

™
AWS CLI: Login, Get IP

™
AWS CLI: Putting it all
together

™
Ansible, Cassandra and
EC2/AWS
❖ Configuration automation needed
❖ Puppet, Ansible, Chef, Boto, etc.
❖ Ansible is an agentless architecture and works over ssh (secure shell)
❖ See Setting up Ansible for our Cassandra Cluster for DevOps for more details
❖ Many useful Ansible/AWS (beyond scope)
❖ The Ansible framework allows DevOps staff to run commands against Amazon EC2
instances as soon as they are available
❖ Ansible is useful provisioning hosts (works with Packer)
❖ Ansible is usefule for DevOps tasks like replacing a failed node, backing up a node,
profiling Cassandra, performing a rolling upgrade and more.
❖ Since Ansible relies on ssh, we should make sure that ssh is working for us.

™
Step 2: Run VPC
CloudFormation

™
Step 2: Watch CloudFormation
logs

™
Step 2: Modify Env to match output of
CloudWatch

™
Step 3: Launch the servers

™
How does it know which IP to
listen on?
❖ We could listen on listen_interface (cassandra.yaml)
❖ We listen on listen_address
❖ But how do we know the address?

™
We use EC2 meta-data

™
EC2 Instance UserData and
MetaData
❖ Instance metadata is data about the EC2 instance
❖ You can use the data to configure things
❖ user data is part of meta-data
❖ Can be anything you want
❖ If it is a script that then AWS will launch it when the
instance first initializes
❖ you use to configure an EC2 instance when its User
Data script runs

™
EC2 Instance Data

™
Checking the status of the Cassandra cluster
Setting up SSH and ansible Part 1
STEP 4 MAKE SURE IT WORKS!

™
SSH config

™
Cassandra YAML (generated)

™
Questions
❖ Which servers are the seed servers?
❖ Which servers are in AZ a?
❖ Which servers are in AZ b?

™
Ec2MultiRegionSnitch

™
Ec2MultiRegionSnitch Pitfalls
❖ Cassandra nodes have to live in a
VPC public subnet
❖ NACL and Security group can
tighten access
❖ Traffic is over public Internet so
anyone can listen
❖ You have to use SSL
❖ SSL Java performance is not
great
❖ Setup is more difficult, you must
setup seeds that are public IPs
❖ use AWS ENIs, AWS Route 53 or
AWS EIPs to make access to
seed nodes more sane

™
Ec2MultiRegionSnitch 1
region
VPC
Public Subnet 1
AWS
Internet
GatewayPublic Subnet 2
Public Subnet 3
Seed
CN1
CN2 CN3 CN4
Seed
CN10
CN12 CN13 CN14
Seed
CN20
CN22 CN23 CN24
AZ: us-west-2a
AZ: us-west-2b
AZ: us-west-2c

™
regions
VPC
Public Subnet 1
AWS
Internet
Gateway
Public Subnet 2
Public Subnet 3
Seed
CN1
CN2 CN3 CN4
Seed
CN10
CN12 CN13 CN14
Seed
CN20
CN22 CN23 CN24
AZ: us-west-2a
AZ: us-west-2b
AZ: us-west-2c
VPC
Public Subnet 1
AWS
Internet
Gateway
Public Subnet 2
Public Subnet 3
Seed
CN1
CN2 CN3 CN4
Seed
CN10
CN12 CN13 CN14
Seed
CN20
CN22 CN23 CN24
AWS Region: us-east-1
AZ: us-east-1a
AZ: us-east-1b
AZ: us-east-c
USA Virginia
USA Oregon

™
regions
VPC
Public Subnet 1
AWS
Internet
Gateway
Public Subnet 2
Public Subnet 3
Seed
CN1
CN2 CN3 CN4
Seed
CN10
CN12 CN13 CN14
Seed
CN20
CN22 CN23 CN24
AZ: us-west-2a
AZ: us-west-2b
AZ: us-west-2c
VPC
Public Subnet 1
AWS
Internet
Gateway
Public Subnet 2
Public Subnet 3
Seed
CN1
CN2 CN3 CN4
Seed
CN10
CN12 CN13 CN14
Seed
CN20
CN22 CN23 CN24
AZ: us-east-2a
AZ: us-east-2b
AZ: us-east-2c
USA East Coast Ohio
USA West Coast Oregon
VPC
Public Subnet 1
AWS
Internet
Gateway
Public Subnet 2
Public Subnet 3
Seed
CN1
CN2 CN3 CN4
Seed
CN10
CN12 CN13 CN14
Seed
CN20
CN22 CN23 CN24
AWS Region: sa-east-1
AZ: sa-east-1a
AZ: sa-east-1b
AZ: sa-east-c
Brazil – South America
VPC
Public Subnet 1
AWS
Internet
Gateway
Public Subnet 2
Public Subnet 3
Seed
CN1
CN2 CN3 CN4
Seed
CN10
CN12 CN13 CN14
Seed
CN20
CN22 CN23 CN24
AWS Region: eu-west-1
AZ: eu-west-1a
AZ: eu-west-1b
AZ: eu-west-1c
Ireland - Europe

™
❖ broadcast_address must be set to public IP
❖ listen_address must be set to private IP
❖ seed nodes must be set
❖ 1 seed per AZ, assume 3 AZ per region
❖ 9 entries for 3 datacenters / regions
❖ Don’t make all nodes seeds (gossip too chatty)
❖ Ec2Snitch is easy because you know node IPs ahead of time
❖ If you use Ec2MultiRegionSnitch, use ENI to make public IP /
seed server constant or use Route53 and put domain names as
seeds

™
First step SSL!
❖ Set up Cassandra for SSL and CQL clients
❖ Cassandra allows you to secure the client
transport (CQL) as well as the cluster transport
(storage transport).
❖ We have to use SSL because we are using
Ec2MultiRegionSnitch over the public Internet
Setting up Cassandra SSL

™
Why SSL? Just in case
❖ Data that travels over a network could be accessed by
someone you don’t want accessing said data with tools
like wire shark
❖ If data includes private information, SSN number, credentials
(password, username), credit card numbers or account
numbers, then we want to make that data unintelligible
(encrypted) to any and all 3rd parties
❖ This is especially important if we don’t control the network.
❖ TLS/SSL ensures data has not been tampered
❖ Cassandra is written in Java. Java defines the JSSE
framework and Java Cryptography Architecture (JCA)

™
setupkeys-cassandra-
security.sh Setting up Cassandra SSL

™
Create the SSL Cassandra
Key Setting up Cassandra SSL

™
Export a public key for the Cassandra
cluster key Setting up Cassandra SSL

™
Import Public key for Cassandra
cluster key into trust storeSetting up Cassandra SSL

™
Creating client pem files

™
SSL Files Generated

™
SSL Files Explained
❖ CLIENT_test_PUBLIC.cer
❖ public client key for the test
cluster.
❖ cassandra.pks12.keystore
❖ PKS12 keystore for client used
to generate pem
❖ test_CLIENT.key.pem
❖ private client key in pem
format used by csqlsh
❖ CLUSTER_test_PUBLIC.cer
❖ public cluster key for the test
cluster
❖ cassandra.truststore
❖ Trust store used by
cassandra
❖ cassandra.keystore
❖ Key store used by cassandra
❖ test_CLIENT.cer.pem
❖ public client key in pem
format used by csqlsh

™
Provision Cassandra to Use
Keys

™
Configure Cassandra to use
the keys

™
Remaining tasks for
Ec2MultiRegionSnitch❖ Parameterize the CloudFormation so we can pass
region
❖ Parameterize the CloudFormation so we can pass CIDR
❖ Change Snitch types
❖ Use ENI or DNS or hack 
❖ Ec2MultiRegionSnitch
❖ Changes to CoudFormation and scripts are described
here: Cassandra Tutorial 7: Setting up Cassandra
Cluster in EC2 Part 2 Multi Region with

™
Parameterizing
CloudFormation

™
Parameterize launch script

™
Pass CIDR and regions to
run-vpc-cloudformation.sh

™
When launching instances
specify the region

™
Switch clusters to

™
Using cassandra-cloud from
Ansible

™
Run playbook

™
Verify the setup

™
Connecting Cluster via VPN

™
Using VPN instead of public Internet
for Multi DC/Region Cassandra Setup
❖ Enable multi-region cluster communication via Internet Protocol Security
(IPsec) tunnels
❖ Use VPN
❖ Private IP address are used for cross-region communication
❖ Company VPN is usually connected to VPG
❖ Setup VPC peering between VPC for Cassandra cluster and Company
VPC connected to VPN via VPG
❖ Recommend to use Ec2Snitch or GossippingPropertyFileSnitch
❖ The CIDR addresses for the VPNs cannot overlap.
❖ Care must be taken in setting up multiple private VPCs that can
communication cross region

™
GossippingPropertyFileSnitch to
VPN
VPC
Private Subnet 1
VPN Subnet 1
Virtual
Private
Gateway
Private Subnet 2
VPN Subnet 2
Private Subnet 3
VPN Subnet 3
NAT Gateway
NAT Gateway
NAT Gateway
Seed
CN1
CN2 CN3 CN4
Seed
CN10
CN12 CN13 CN14
Seed
CN20
CN22 CN23 CN24
Bastion Host
AZ: us-west-2a
AZ: us-west-2b
AZ: us-west-2c
AZ: us-west-2a
AZ: us-west-2b
AZ: us-west-2a

™
GossippingPropertyFileSnitch via
VPN via VPC Peer
VPC
Private Subnet 1
VPN Subnet 1
Company
VPC
For
VPN
Private Subnet 2
VPN Subnet 2
Private Subnet 3
VPN Subnet 3
NAT Gateway
NAT Gateway
NAT Gateway
Seed
CN1
CN2 CN3 CN4
Seed
CN10
CN12 CN13 CN14
Seed
CN20
CN22 CN23 CN24
Bastion Host
AZ: us-west-2a
AZ: us-west-2b
AZ: us-west-2c
AZ: us-west-2a
AZ: us-west-2b
AZ: us-west-2a
Virtual
Private
Gateway
VPC
Peering

™
GossippingPropertyFileSnitch
4 regions / DCs
VPC
Private Subnet 1
VPN Subnet 1
Company
VPC
For
VPN
Private Subnet 2
VPN Subnet 2
Private Subnet 3
VPN Subnet 3
NAT Gateway
NAT Gateway
NAT Gateway
Seed
CN1
CN2 CN3 CN4
Seed
CN10
CN12 CN13 CN14
Seed
CN20
CN22 CN23 CN24
Bastion Host
AZ: us-west-2a
AZ: us-west-2b
AZ: us-west-2c
AZ: us-west-2a
AZ: us-west-2b
AZ: us-west-2a
VPC
Peering
VPC
Private Subnet 1
VPN Subnet 1
Company
VPC
For
VPN
Private Subnet 2
VPN Subnet 2
Private Subnet 3
VPN Subnet 3
NAT Gateway
NAT Gateway
NAT Gateway
Seed
CN1
CN2 CN3 CN4
Seed
CN10
CN12 CN13 CN14
Seed
CN20
CN22 CN23 CN24
Bastion Host
VPC
Peering
VPC
Private Subnet 1
VPN Subnet 1
Company
VPC
For
VPN
Private Subnet 2
VPN Subnet 2
Private Subnet 3
VPN Subnet 3
NAT Gateway
NAT Gateway
NAT Gateway
Seed
CN1
CN2 CN3 CN4
Seed
CN10
CN12 CN13 CN14
Seed
CN20
CN22 CN23 CN24
Bastion Host
AWS Region: eu-west-1
VPC
Private Subnet 1
VPN Subnet 1
Company
VPC
For
VPN
Private Subnet 2
VPN Subnet 2
Private Subnet 3
VPN Subnet 3
NAT Gateway
NAT Gateway
NAT Gateway
Seed
CN1
CN2 CN3 CN4
Seed
CN10
CN12 CN13 CN14
Seed
CN20
CN22 CN23 CN24
Bastion Host
AWS Region: sa-east-1

™
Final Thoughts Some final thoughts

™
Engineering Tradeoffs
❖ Less servers and scale up
❖ Potential for reduce AWS spend
❖ Perhaps harder to horizontal scale if you have to (more
streaming when you bring up node)
❖ There may not be an exact match EC2 instance
❖ Do you have lots of spare memory? Bump up the key
caches, and IO buffers (use what you have)
❖ Do you have spare CPU? Enable compression to minimize
IO overhead (first SSTable, then commit log, then
internode communication all)

™
Company
Overview How we got our start

™
Different companies same
challenges
❖ How to setup a Cluster across multiple AZs
❖ Where does enhanced networking fit it
❖ Should we use EBS or instance storage
❖ Monitoring and logging that can be actionable
❖ Integration with AWS services like CloudFormation, and
CloudWatch.
❖ Best fit for images, VPC setup, peering, subnets,
firewalls

™
Services we provide
❖ Training
❖ Consulting
❖ Setting up Cassandra in AWS/EC2
❖ AWS CloudFormations
❖ Subscription Support around Cassandra running in
AWS/EC2
❖ AWS CloudWatch monitoring
❖ AWS CloudWatch logging

™
Visit us: http://cloudurable.com/

™
SETTING UP ANSIBLE/SSH FOR
CASSANDRA DATABASE CLUSTER
DEVOPS PART 1
IN ANSIBLE
March 11, 2017
Cassandra Cluster Tutorial 3: Part 1 of 2
Setting up Ansible/SSH for our Cassandra
Database Cluster for DevOps/DBA Tasks
Ansible and ssh are essential DevOps/DBA
tools for common DBA/DevOps tasks like
managing backups, rolling upgrades to the
Cassandra cluster in AWS/EC2, and so much
more. An excellent aspect of Ansible is that it
uses ssh, so you do not have to install an
agent to use Ansible. This article series
centers on how DevOps/DBA tasks with the
Cassandra Database.
PART 2 SETTING UP ANSIBLE AND SSH
FOR CASSANDRA DATABASE CLUSTER
DEVOPS
IN ANSIBLE
March 11, 2017
Cassandra Cluster Tutorial 3: Part 2 of 2
Setting up Ansible and SSH for our Cassandra
Database Cluster for DevOps/DBA Tasks This
tutorial series centers on how DevOps/DBA
tasks with the Cassandra Database. As we
mentioned before, Ansible and ssh are
essential DevOps/DBA tools for common
DBA/DevOps tasks whilst working with
Cassandra Clusters. Please read part 1 before
reading part 2. In part 1, we set up Ansible for
our Cassandra Database Cluster to automate
common DevOps/DBA tasks.

™
SETTING UP A CASSANDRA
CLUSTER WITH SSL FOR CLIENT
AND CLUSTER TRANSPORTS FOR
DEVOPS
IN CASSANDRA
February 2, 2017
Setting up client and cluster SSL
transport for a Cassandra cluster This
articles is a Cassandra tutorial on
Cassandra setup for SSL and CQL
clients, as well as installing Cassandra
with SSL configured on a series of
Linux servers. Cassandra allows you
to secure the client transport (CQL) as
well as the cluster transport (storage
transport). SSL/TLS have some
overhead. This is especially true in the
JVM world which is not as performant
for handling SSL/TLS unless you are
using Netty/OpenSSl integration.
SETTING UP A CASSANDRA
CLUSTER WITH CASSANDRA IMAGE
AND CASSANDRA CLOUD PROJECT
WITH VAGRANT FOR DEVOPS
IN CASSANDRA
February 1, 2017
The cassandra-image project creates
CentOS Cassandra Database images
for docker, virtualbox/vagrant and
AWS/EC2 using best practices for
Cassandra OS setup. It is nice to use
vagrant and/or docker for local
development. At this time it is hard to
develop systemd services using Docker
so we use Vagrant. Since we do a lot of
that, we like to use Vagrant. Vagrant is
important for developers and DevOps
not to mention Cassandra DBAs.
CONTINUE READING

™
FOLLOW CLOUDURABLE™
facebook page
google plus
twitter
linkedin

Amazon Cassandra Basics & Guidelines for AWS/EC2/VPC/EBS

More Related Content

What's hot (20)

Viewers also liked (17)

Similar to Amazon Cassandra Basics & Guidelines for AWS/EC2/VPC/EBS (20)

Recently uploaded (20)

Amazon Cassandra Basics & Guidelines for AWS/EC2/VPC/EBS