ops for developers

Post on 18-Dec-2014

325 Views

Category:

Technology

5 Downloads

Preview:

Click to see full reader

DESCRIPTION

Ops for Developers, training session, presented by Ben Klang at Lone Star Ruby Conference 6 2012

TRANSCRIPT

Ops for DevelopersOr: How I Learned To Stop Worrying And Love The Shell

Ben Klangbklang@mojolingo.com

spkr8.com/t/13191

Friday, August 10, 12

Prologue

Introductions

Friday, August 10, 12

Who Am I?

Ben Klang@bklang Github/Twitterbklang@mojolingo.com

Friday, August 10, 12

What are my passions?

• Telephony Applications

• Information Security

• Performance and Availability Design

• Open Source

Friday, August 10, 12

What do I do?

• Today I write code and run Mojo Lingo

• But Yesterday...

Friday, August 10, 12

This was my world

Friday, August 10, 12

Ops Culture

Friday, August 10, 12

“I am allergic to downtime”

Friday, August 10, 12

It’s About Risk

• If something breaks, it will be my pager that goes off at 2am

• New software == New ways to break

• If I can’t see it, I can’t manage it or monitor it and it will break

Friday, August 10, 12

Agenda• 9:00 - 10:30

• Operating Systems & Hardware

• All About Bootup

• 10:30 - 11:00: Break

• 11:00 - 12:30

• Observing a Running System

• Optimization/Tuning

• 12:30 - 1:30 Lunch

• 1:30 - 3:00

• Autopsy of an HTTP Request

• Dealing with Murphy

• 3:00 - 3:30: Break

• 3:30 - 5:00

• Scaling Up

• Deploying Apps

• Audience Requests

Friday, August 10, 12

Part I

Operating Systems & Hardware

Friday, August 10, 12

OS History LessonBSD, System V, Linux and Windows

Friday, August 10, 12

UNICS(Sep. 1969)

Soon renamed “Unix Time Sharing System

Version 1”

UNIX Time Sharing System Version 5(Jun. 1974)

UNIX Sys III(Nov. 1981)

1BSD(Mar. 1978)

4.3BSD(Jun. 1986)

UNIX Sys V(Jan. 1983)

Friday, August 10, 12

Friday, August 10, 12

Hardware Components

Friday, August 10, 12

Common Architectures

• Intel x86 (i386, x86_64)

• SPARC

• POWER

• ARM

• But none of this really matters anymore

Friday, August 10, 12

CPU Configurations

• Individual CPU

• SMP: Symmetric Multi-Processing

• Multiple Cores

• Hyperthreading/Virtual Cores

Friday, August 10, 12

(Virtual) Memory

• RAM + Swap = Available Memory

• Swapping strategies vary across OSes

• What your code sees is a complete virtualization of this

• x86/32-bit processes can only “see” 3GB of RAM from a 4GB address space

Friday, August 10, 12

Storage Types

• Local Storage (SATA, SAS, USB, Firewire)

• Network Storage (NFS, SMB, iSCSI, AOE)

• Storage Network (FibreChannel, Fabrics)

Friday, August 10, 12

Networking

• LAN (100Mb still common; 1Gbit standard; 10Gb and 100Gb on horizon)

• WAN (T-1, Frame Relay, ATM, MetroE)

• Important Characteristics

• Throughput

• Loss

• Delay

Friday, August 10, 12

Part II

All About Bootup

Friday, August 10, 12

Phases

• BIOS

• Kernel Bootstrap

• Hardware Detection

• Init System

Friday, August 10, 12

System Services

• Varies by OS

• Common: SysV Init Scripts; /etc/inittab; rc.local

• Solaris: SMF

• Ubuntu: Upstart

• Debian: SysV default; Upstart optional

• OSX: launchd

• RedHat/CentOS: SysV Init Scripts

Friday, August 10, 12

SysV Init Scripts

• Created in /etc/init.d; Symlinked into runlevel directories

• Symlinks prefixed with special characters to control startup/shutdown order

• Prefixed with “S” or “K” to start or stop service in each level

• Numeric prefix determines order

• /etc/rc3.d/S10sshd -> /etc/init.d/sshdFriday, August 10, 12

rc.local

• Single “dumb” startup script

• Run at end of system startup

• Quick/dirty mechanism to start something at bootup

Friday, August 10, 12

/etc/inittab

• The original process supervisor

• Not (easily) scriptable

• Starts a process in a given runlevel

• Restarts the process when it dies

Friday, August 10, 12

Supervisor Processes

• Solaris SMF

• Ubuntu Upstart

• OSX launchd

• daemontools

Friday, August 10, 12

Ruby Integrations

• Supervisor Processes

• Bluepill

• God

• Startup Script Generator

• Foreman

Friday, August 10, 12

Choosing a Boot Mechanism

• Is automatic recovery desirable?(Hint: sometimes it’s not)

• Does it integrate with monitoring?

• Is it a one-off that will get forgotten?

• Does it integrate into OS startup/shutdown?

• How much work to integrate with your app?

Friday, August 10, 12

Part III

Observing a Running System

Friday, August 10, 12

Common Tools

• top

• free

• vmstat

• netstat

• fuser

• ps

• sar (not always installed by default)

Friday, August 10, 12

Power Tools

• lsof

• iostat

• iftop

• pstree

• Tracing tools

• strace

• tcpdump/wireshark

Friday, August 10, 12

Observing CPU

• Go-to tools: top, ps

• CPU is not just about computation

• Most Important:%user, %system, %nice, %idle, %wait

• Other: hardware/software interrupts, “stolen” time (especially on EC2)

Friday, August 10, 12

The Mystical Load Avg.

• Broken into 1, 5 and 15 minute averages

• Gives a coarse view of overall system load

• Based on # processes waiting for CPU time

• Rule of thumb: stay below the number of CPUs in a system (eg. a 4 CPU host should be below a 4.00 load average)

Friday, August 10, 12

When am I CPU bound?

• 15 minute load average exceeding the number of non-HT processors

• %user + %system consistently above 90%

Friday, August 10, 12

Observing RAM

• Go-to tools: top, vmstat

• Available memory isn’t just “Free”

• Buffers + Cache fill to consume available RAM (this is a good thing!)

Friday, August 10, 12

RAM vs. Swap

• RAM is the amount of physical memory

• Swap is disk used to augment RAM

• Swap is orders of magnitude slower

• Some VM types have no meaningful swap

• Rule of thumb: pretend swap doesn’t exist

Friday, August 10, 12

Paging Strategies

• Solaris: Page in advance

• Linux: Page on demand (last resort)

• Windows: Craziness

Friday, August 10, 12

When am I memory bound?

• Free + buffers + cache < 15% of RAM

• Swap utilization above 10% avail. swap (Linux only)

• Check for high disk utilization to confirm “thrashing”

Friday, August 10, 12

Observing Disk

• Go-to tools: iostat, top

• Disk is usually hardest thing to observe

• Better in recent Linux kernels (> 2.6.20)

Friday, August 10, 12

RAID

• Redundant Array of Inexpensive Drives

• Different strategies have different performance/durability tradeoffs

• RAID-0

• RAID-1

• RAID-10

• RAID-5

• RAID-6Friday, August 10, 12

When am I disk bound?

• %wait is consistently above 10% to 20%

• ... though %wait can be network too

• SCSI and FC command queues are long

• Known failure mode: disk more than 85% full causes tremendous VFS overhead

Friday, August 10, 12

Observing Network

• Go-to tools: netstat, iftop, wireshark

• Be wary of choke-points

• Switch interconnects

• WAN links

• Firewalls

Friday, August 10, 12

Link Optimization

• Use Jumbo Frames for Gbit+ links

• Port aggregation for throughput:

• Best: many-to-many

• Good: one-to-many

• Useless: one-to-one

• ... but still useful for HA

Friday, August 10, 12

When am I network bound?

• This one is easy: 99% of the time this is link saturation

• Gotchas: which link?

• Addendum: loss/delay (especially for TCP) can wreak havoc on throughput

• ... but usually only a problem across WAN

Friday, August 10, 12

Part IV

Optimization & Performance Tuning

Friday, August 10, 12

Hardware Options

• A.K.A. “Throw hardware at it”

• Not the first thing to try

• Are the services tuned? SQL queries, application behavior, caching options

• Is something broken, causing performance degradation?

Friday, August 10, 12

Hardware Options

• RAM is usually the single biggest performance win (cost/benefit tradeoff)

• Faster disk is next best

• Then look at CPU and/or Network

• ...but do the work to figure out why your performance is limited in the first place

Friday, August 10, 12

Kernel Tunables

• Not as necessary as in the “old days”

• Almost all settings can be adjusted at runtime on Linux, Solaris

• Most valuable settings are buffer limits or counters/timers

• There be dragons! Read carefully before twisting these knobs

Friday, August 10, 12

Environment Settings

• ulimits

• max files

• stack size

• memory limits

• core dumps

• others

• Still subject to system-wide (kernel) limits

Friday, August 10, 12

Environment limits

• Hard limits cannot be raised by unprivileged users

• PAM configuration may also be in effect

Friday, August 10, 12

Application Tunables• There are not many for C-Ruby

• JVM has many

• Mostly related to how RAM is allocated and garbage collected

• Very dependent on application

• Any time an “xVM” is involved, there is probably a tunable (JVM, CLR)

• But we are developers! Tune/profile your app before looking to the environment

Friday, August 10, 12

Performance Management Tools

• sysstat (sar)

• SNMP (and related tools like Cacti)

• Integrated Monitoring + Trending tools

• Zabbix

• OpenNMS

• and a plethora of commercial tools

Friday, August 10, 12

Part V

Putting It All TogetherAutopsy of a single HTTP request, end-to-end

Friday, August 10, 12

Live Demo/Whiteboard

Friday, August 10, 12

Part VI

Pulling It All ApartAnticipating Murphy and his Law

Friday, August 10, 12

Most Common Pitfalls

• Disk Full

• DNS Unavailable/Slow

• Insufficient RAM

• Suboptimal Service Configuration

• Firewall misconfiguration

• Archaic: Network mismatch (Full/Half Duplex)

Friday, August 10, 12

DNS and Performance

• Possibly most-overlooked perf. impact

• Everything uses DNS

• If you make nothing else redundant, make this redundant!

Friday, August 10, 12

Part VII

Scaling Up

Friday, August 10, 12

Horizontal or Vertical?

• Vertical: Making one server/instance go faster

• Horizontal: Parallelizing requests to get more things done in the same amount of time

Friday, August 10, 12

Clustering

• Parallelizing requests to increase overall throughput: horizontal scaling

• Techniques to make information more available:

• Caching (memcache, file-based caching)

• Distribute data sets

• Replication

Friday, August 10, 12

Distributing Data

• Replication

• Split Reads (One writer/master; multiple slaves/readers)

• Multiple Masters (dangerous!)

• Sharding (must consider HA)

Friday, August 10, 12

Failover/HA

• Consistency requires concept of Quorum

• Losing partition gets killed: STONITH

• Multi-master systems ignore this at the cost of potential non-determinisim

Friday, August 10, 12

Tuning Services

• Some VM types (especially JVM or CLR) have tunables for memory consumption

• Databases usually have memory settings

• These can make dramatic differences

• Very workload dependent

• Deep troubleshooting: strace, wireshark

Friday, August 10, 12

Part VIII

Deploying Applications

Friday, August 10, 12

12 Factor Application

• Deployability starts with application design

• Clear line between configuration and logic

• Permit easy horizontal scaling

• Are OS-agnostic (yay Ruby!)

• Minimize differences between dev and prod

• http://12factor.net - by Heroku cofounder

Friday, August 10, 12

Deployment Tools

• Capistrano

• The de facto standard

• Requires effort to set up, test

• Requires integration with system startup

• Most flexible

Friday, August 10, 12

Deployment Tools

• “Move it to the cloud”

• Heroku

• Cloud Foundry

Friday, August 10, 12

top related