Cloud applications

Building cloud-ready applications

2

Today's talk topics

• Limitations and potential dangers of traditional hosting

• 12 factor apps and scaling best practices

• Load balancing in OpenStack with Neutron

• Telemetry in OpenStack with Ceilometer

• Autoscaling in OpenStack with Heat

• Storage models: block storage, object storage, datastores

• OpenStack Database service: concepts and common operations

• Resiliency principles and resource isolation: Compute cells, Availability Zones, Regions, Host aggregates

Limitations, scaling, pets vs cattle

TRADITIONAL WEB HOSTING

3

4

Traditional solution

RACKSPACE REFERENCE ARCHITECTURE ICONS

CORE NETWORKING/ROUTING FIREWALL FIREWALLS (HA)

SERVER INSTANCE

WEB APPLICATION FIREWALL

MONITORING RAPID DEPLOYMENT

LOAD BALANCER LOAD BALANCERS (HA)

DEDICATED SERVER (LARGE) DEDICATED SERVER (MEDIUM) DEDICATED SERVER (SMALL) CLOUD SERVER (LARGE) CLOUD SERVER (MEDIUM) CLOUD SERVER (SMALL)

PAYMENT SERVICES SSL / ENCRYPTION

SERVER ROOM/DATA CENTER

SERVER INSTANCES SERVER RACKVPN NETWORK CONNECTION GLOBAL TRAFFIC MANAGER

BUILDING 1 BUILDING 3BUILDING 2 GLOBEL (LARGE) GLOBEL (SMALL)

DDoS MITIGATION GENERIC DEVICE 1 GENERIC DEVICE 2 GENERIC DEVICE 3 CONFIGURATIONINTRUSION DETECTION (IDS)

WEBSITE ECOMMERCE SITE



SERVER INSTANCE













SERVER INSTANCE










WEBSITE ECOMMERCE SITERACKSPACE REFERENCE ARCHITECTURE ICONS

FLAMESHIELD (LARGE) SHIELD (SMALL)

LICENSE (LARGE)

PERFORMANCE TUNING

LICENSE (SMALL)

POWERED ON

CODE / SCRIPTS

BOLT GEAR

BOLT SHIELD

MAINTENANCE

CHECKMARK (LARGE)

LOCK SHIELD

ARCHITECTURE DESIGN

LOCK SHIELD CHECKED

INSTALLATION

ANTIVIRUS & MALWARE

DATA REPLICATION SERVICES DATA REPLICATION CLOUD DNS DATABASE DATA STORAGE BACKUPS

RAPID DEPLOY (SMALL) STOP WATCH MONITOR

PATCHING SHIELD

STACKS

OS MAINTENANCE

PERFORMANCE TUNING 2

KEY (SMALL) KEY (LARGE)FLAME SHIELD

SECURITY ASSESSMENT

TARGET / FOCUSHEART PIGGY BANK SAVE MONEY UPTIME

CACHINGARCHIVING GITHUB REPOSITORY GITHUB REPOSITORY 2

RANDOM ICONS

Firewall

Web server

Application

Database & cache

5

How do we evolve?

• What happens when our business needs change?

• What happens when our app wildly succeeds? What happens when things die down?

• What happens when our app fails catastrophically?

• What happens when we get new customers? How well can we cope with short deadlines?

6

Solutions for website scale



SERVER INSTANCE













SERVER INSTANCE













SERVER INSTANCE












LICENSE (LARGE)

PERFORMANCE TUNING

LICENSE (SMALL)

POWERED ON

CODE / SCRIPTS

BOLT GEAR

BOLT SHIELD

MAINTENANCE

CHECKMARK (LARGE)

LOCK SHIELD

ARCHITECTURE DESIGN

LOCK SHIELD CHECKED

INSTALLATION

ANTIVIRUS & MALWARE



PATCHING SHIELD

STACKS

OS MAINTENANCE



SECURITY ASSESSMENT



RANDOM ICONS

RACKSPACE WEBSITE ICONS (WEBICONS - SMALL)

CART - OPERATING SYSTEM

CART - SECURITY

CART - FIREWALL

CART - CALCULATOR

CART - NETWORKING

WEB PAGE

CART - DATABASE CART - BACKUP CART - ANTI-VIRUS

PDF (SMALL) DOCUMENT FILE TEXT FILE IMAGE FILE CODE SNIPPET HELP ARTICLE (SMALL)

VIDEO CART - DEDICATED SERVER CART - PROCESSOR CART - RAM CART - HARD DRIVE CART - SSD HARD DRIVE

SNAKE

SUPPORT KITTY PUPPY



CART - SECURITY

CART - FIREWALL

CART - CALCULATOR

CART - NETWORKING

WEB PAGE




SNAKE

SUPPORT KITTY PUPPY



CART - SECURITY

CART - FIREWALL

CART - CALCULATOR

CART - NETWORKING

WEB PAGE




SNAKE

SUPPORT KITTY PUPPY



CART - SECURITY

CART - FIREWALL

CART - CALCULATOR

CART - NETWORKING

WEB PAGE




SNAKE

SUPPORT KITTY PUPPY



CART - SECURITY

CART - FIREWALL

CART - CALCULATOR

CART - NETWORKING

WEB PAGE




SNAKE

SUPPORT KITTY PUPPY



CART - SECURITY

CART - FIREWALL

CART - CALCULATOR

CART - NETWORKING

WEB PAGE




SNAKE

SUPPORT KITTY PUPPY



CART - SECURITY

CART - FIREWALL

CART - CALCULATOR

CART - NETWORKING

WEB PAGE




SNAKE

SUPPORT KITTY PUPPY



CART - SECURITY

CART - FIREWALL

CART - CALCULATOR

CART - NETWORKING

WEB PAGE




SNAKE

SUPPORT KITTY PUPPY



CART - SECURITY

CART - FIREWALL

CART - CALCULATOR

CART - NETWORKING

WEB PAGE




SNAKE

SUPPORT KITTY PUPPY

7

Solutions for business scale



SERVER INSTANCE













SERVER INSTANCE













SERVER INSTANCE












LICENSE (LARGE)

PERFORMANCE TUNING

LICENSE (SMALL)

POWERED ON

CODE / SCRIPTS

BOLT GEAR

BOLT SHIELD

MAINTENANCE

CHECKMARK (LARGE)

LOCK SHIELD

ARCHITECTURE DESIGN

LOCK SHIELD CHECKED

INSTALLATION

ANTIVIRUS & MALWARE



PATCHING SHIELD

STACKS

OS MAINTENANCE



SECURITY ASSESSMENT



RANDOM ICONS



SERVER INSTANCE













LICENSE (LARGE)

PERFORMANCE TUNING

LICENSE (SMALL)

POWERED ON

CODE / SCRIPTS

BOLT GEAR

BOLT SHIELD

MAINTENANCE

CHECKMARK (LARGE)

LOCK SHIELD

ARCHITECTURE DESIGN

LOCK SHIELD CHECKED

INSTALLATION

ANTIVIRUS & MALWARE



PATCHING SHIELD

STACKS

OS MAINTENANCE



SECURITY ASSESSMENT



RANDOM ICONS



SERVER INSTANCE













SERVER INSTANCE













SERVER INSTANCE













SERVER INSTANCE













LICENSE (LARGE)

PERFORMANCE TUNING

LICENSE (SMALL)

POWERED ON

CODE / SCRIPTS

BOLT GEAR

BOLT SHIELD

MAINTENANCE

CHECKMARK (LARGE)

LOCK SHIELD

ARCHITECTURE DESIGN

LOCK SHIELD CHECKED

INSTALLATION

ANTIVIRUS & MALWARE



PATCHING SHIELD

STACKS

OS MAINTENANCE



SECURITY ASSESSMENT



RANDOM ICONS



SERVER INSTANCE













SERVER INSTANCE













SERVER INSTANCE











8

What are the disadvantages?

• Adding hardware is an inflexible.

• Provisioning hardware is slow.

• Raw hardware requires up-front expense.

• Developers, project managers, business analysts, and managers should not worry about hardware capabilities. All we want is a quick, efficient solution to the problem.

9

Paradigm shift

• Cloud abstracts away hardware capabilities by treating it like software.

• Pets vs Cattle

• We can adjust our infrastructure programmatically.

• Added flexibility, more automation, better (automated) decisions, cost and time savings.

• Provides resiliency through scaling and redundancy.

10

Cloud reference architecture: web app

AUTO SCALE GROUP

MASTERREPLICA

Cloud Load Balancer

PRIVATE NETWORK

WWW

Your Web App

Compute Infrastructure Asset Management

HTTP

11

Cloud reference architecture: eCommerce

AUTO SCALE GROUP

MASTER REPLICA

Cloud Load Balancer

WWW

ONMETALSERVER

Elastic Search

ONMETALSERVER

REDIS

Breaking up the monoliths, 12 factor principles

CLOUD APPLICATIONS

12

13

But what about our apps?

• Architecture alone does not guarantee scale.

• Monolithic apps need to be restructured to integrate with our new cloud model.

• Good examples are Magento, WordPress -- traditional apps that have not made the shift to cloud-friendly codebases.

Logging

TLS certs

Background tasks

Database backupsDatabase

Caching

14

What do I mean by monolith?

Web server

Presentation layer

Controller layer

Model layer

Data access layer



LICENSE (LARGE)

PERFORMANCE TUNING

LICENSE (SMALL)

POWERED ON

CODE / SCRIPTS

BOLT GEAR

BOLT SHIELD

MAINTENANCE

CHECKMARK (LARGE)

LOCK SHIELD

ARCHITECTURE DESIGN

LOCK SHIELD CHECKED

INSTALLATION

ANTIVIRUS & MALWARE



PATCHING SHIELD

STACKS

OS MAINTENANCE



SECURITY ASSESSMENT



LICENSE (LARGE)

PERFORMANCE TUNING

LICENSE (SMALL)

POWERED ON

CODE / SCRIPTS

BOLT GEAR

BOLT SHIELD

MAINTENANCE

CHECKMARK (LARGE)

LOCK SHIELD

ARCHITECTURE DESIGN

LOCK SHIELD CHECKED

INSTALLATION

ANTIVIRUS & MALWARE



PATCHING SHIELD

STACKS

OS MAINTENANCE



SECURITY ASSESSMENT



RANDOM ICONS



LICENSE (LARGE)

PERFORMANCE TUNING

LICENSE (SMALL)

POWERED ON

CODE / SCRIPTS

BOLT GEAR

BOLT SHIELD

MAINTENANCE

CHECKMARK (LARGE)

LOCK SHIELD

ARCHITECTURE DESIGN

LOCK SHIELD CHECKED

INSTALLATION

ANTIVIRUS & MALWARE



PATCHING SHIELD

STACKS

OS MAINTENANCE



SECURITY ASSESSMENT



LICENSE (LARGE)

PERFORMANCE TUNING

LICENSE (SMALL)

POWERED ON

CODE / SCRIPTS

BOLT GEAR

BOLT SHIELD

MAINTENANCE

CHECKMARK (LARGE)

LOCK SHIELD

ARCHITECTURE DESIGN

LOCK SHIELD CHECKED

INSTALLATION

ANTIVIRUS & MALWARE



PATCHING SHIELD

STACKS

OS MAINTENANCE



SECURITY ASSESSMENT



LICENSE (LARGE)

PERFORMANCE TUNING

LICENSE (SMALL)

POWERED ON

CODE / SCRIPTS

BOLT GEAR

BOLT SHIELD

MAINTENANCE

CHECKMARK (LARGE)

LOCK SHIELD

ARCHITECTURE DESIGN

LOCK SHIELD CHECKED

INSTALLATION

ANTIVIRUS & MALWARE



PATCHING SHIELD

STACKS

OS MAINTENANCE



SECURITY ASSESSMENT



LICENSE (LARGE)

PERFORMANCE TUNING

LICENSE (SMALL)

POWERED ON

CODE / SCRIPTS

BOLT GEAR

BOLT SHIELD

MAINTENANCE

CHECKMARK (LARGE)

LOCK SHIELD

ARCHITECTURE DESIGN

LOCK SHIELD CHECKED

INSTALLATION

ANTIVIRUS & MALWARE



PATCHING SHIELD

STACKS

OS MAINTENANCE



SECURITY ASSESSMENT

Assets


CLOUD ENCLOSURE (EDGES) CLOUD ENCLOSURE (CORNERS)

CHECKLIST

ALERT (TRIANGLE)

GEAR (LARGE)

DESKTOP

REOCCURRING PROCESS

SEARCH (LARGE)

GEAR (MEDIUM)

LAPTOP

CHECKMARK

SEARCH (SMALL)

GEAR (SMALL)

CALENDAR (LARGE)

DENIED

BOLT 1

GEAR (ENCLOSED)

CALENDAR (SMALL)

POWER

BOLT 2

SUPPORT (LARGE)

ALERT (CIRCLE)

BOLT 3

PLUGIN (LARGE) PLUGIN (SMALL) LOCK (LARGE) LOCK (SMALL) FILE (LARGE) FILE (SMALL)

FILES (LARGE) FILES (SMALL) IMAGE FILE (LARGE) IMAGE FILE (SMALL) TEXT FILE (LARGE) TEXT FILE (SMALL)

SUPPORT (MEDIUM)

15

So what should a modern app look like?

• 12 factor pattern is a set of principles to create software-as-a-service (SaaS) applications.

• Aims to have an easy-to-deploy, easy-to-maintain, easy-to-scale application that has a clean contract with the OS and external services.

• Overall systems are composed of discrete applications working in tandem, but loosely coupled.

• Not always possible to convert legacy apps to be fully 12fa compatible. Sensible compromises are okay.

16

1. Small components, one codebase

• Decompose our large monoliths into smaller, discrete components with single responsibilities.

• Each component has its one codebase in a version control system, like git, subversion or mercurial.

• One codebase, multiple deploys. Same codebase across deployments.

• "If there are multiple codebases, it’s not an app – it’s a distributed system. Each component in a distributed system is an app, and each can individually comply with twelve-factor."

17

2. Explicitly define dependencies

• Never assume or rely on implicit existence of system-wide packages. This also applies to tools like cURL, language extensions, and specific versions of software.

• Explicitly declare deps in a manifest (e.g. pom.xml).

• Many languages have package managers (Pip for Python, NPM for Node, Composer for PHP, Rubygems for Ruby, etc.)

• Tools like Ansible, Chef, Puppet, and Docker can help make these dependency declarations more explicit and reproducible in different environments.

18

3. Extract configuration into environment

• Strict separation of configuration from application. Configuration varies across deploys, code does not.

• Avoid the risk of committing configuration to your VCS.

• Many recommend the use of environment variables. Values or environment files are then made available during deployment process.

• More advanced solutions are starting to emerge in the container landscape with things like etcd, consul, confd.

19

4. Services that back your app

• A "service" is a remote endpoint that provides functionality to your app.

• Applications treats all services in a remote way by referencing a URL endpoint and a port.

• Use consistent, standardised protocols to improve long-term maintainability.

• Connecting to a service is a contract: should not matter whether a different implementation is swapped out or where the service lives.

20

5. Separate build, deploy, and run tasks

• Improve efficiency of development and deployment processes.

• Use CI/CD to reduce risk. Code changes on live production systems should be almost impossible (and unnecessary).

• Make failovers, roll-backs and other deployment mechanisms automated, so nobody wakes up at 4am.

• A good deployment process also allows developers to focus on writing their code.

21

6. Statelessness

• Application processes are stateless and share-nothing. Storing sessions on the host filesystem introduces brittleness. LB sticky sessions are not the solution.

• Docker, for example, places great emphasis on developers decomposing their applications into single-process containers with ephemeral filesystems.

• Should not matter on which host your applications run. Also does not matter the size of your cluster: easy to scale up and down.

22

7. Port binding

• Web apps are often tightly coupled with a web server. PHP apps run as a module inside Apache; Java apps might run inside Tomcat.

• An app should be self-contained and not rely on runtime injection of a web server into the execution environment to create a web-facing service. Instead the web app exports HTTP as a service by binding to a port, and listening to requests coming in on that port.

• We do this as a way to declare contracts, so that our app can itself be used as a backing service if needs be.

23

8. Use concurrent processes to scale

• Processes are a first class citizen, like Unix service daemons.

• Apps handle diverse workloads by assigning each type of work to a process type: HTTP requests are handled by a web process, long-running background tasks handled by a worker process.

• Provides horizontal scaling because adding more concurrency is a simple and reliable operation.

• Do not daemonize or write PID files; instead, rely on the OS’s process manager (like systemd, upstart or Foreman) to manage output streams, respond to crashed processes, and handle user-initiated restarts and shutdowns.

24

9. Disposability

• Applications should be disposable - they can be started and stopped at a moment's notice without affecting the overall performance of the system.

• Minimal start-up time is a priority. A load balancer should not wait minutes for added capacity.

• Graceful shut-downs are a priority, as is robustness against sudden death.

25

10. Development/production parity

• Aim is to keep the delta between development and production environments as small as possible.

Traditional app 12-factor app

Time between deploys Weeks or days Hours or minutes

Code authors vs code deployers Different Same

Dev vs production environments Divergent Identical

26

11. Logging

• Treat logs as event streams.

• An application should not concern itself with the routing or storing of its output stream - those are external concerns.

• Collect the output stream and send it to an aggregation and parsing service, like logstash.

• Use a service like ElasticSearch to analyse logs for metrics, patterns, and trends.

• Allow a presentation layer or GUI like Kibana to access and explore it visually.

27

12. Admin processes

• Throwaway or ephemeral admin actions introduce risk because state changes cannot be tracked.

• Instead, run these tasks as one-off processes on an environment that has parity with production.

• Database migrations, asset pipelines, resetting the cache are examples.

LBaaS v1 and v2 extensions for Neutron

LOAD BALANCING IN OPENSTACK

28

29

What else?

• Apart from modern best practices, we also need our applications to address a few more considerations.

• Scale: what happens when our application succeeds?

• Resiliency: what happens when our applications fails catastrophically?

30

What is resiliency?

• Availability: The proportion of time the system is up and running.

• Reliability: The ability of the system to keep operating over time in the context of errors and in situations of unexpected or incorrect usage. A reliable system performs in a predictable, prescribed manner.

31

Load balancing

• Enables you to:

• Load-balance client traffic from one network to applications (running on virtual machines) running on the same or a different network.

• Load-balance several protocols, such as TCP and HTTP.

• Monitor the health of applications. • Support session persistence.

• Load balancing as a service (LBaaS) is available as an advanced extension in Neutron. Plans to shift to own project under networking umbrella.

32

LBaaS terminology

• Load balancers are the front end objects which receive client traffic on a virtual IP.

• A pool is a logical set of devices, like Nova instances, where apps live and which the load balancer will forward traffic to.

• A listener is an abstraction which represents a single listening port, and optionally the protocol.

• A member is the application on the back-end server.

• A health monitor determines whether or not back-end members in a pool can process a request. PING, TCP, HTTP, HTTPS are options.

• Session persistence allows request in the same session to be processed by the same member. SOURCE_IP, HTTP_COOKIE and APP_COOKIE are options.

33

Step 0: Prerequisites

• An OpenStack or devstack cluster running with Neutron, Nova and the LBaaS v2 extension.

• A private Neutron subnet.

• A few VMs running, attached to the subnet.

• We will not be handling SSL termination. You would need generate a certificate chain and private key, then import into Barbican (key/secret management for OpenStack).

34

Step 1: Create a load balancer

neutron lbaas-‐loadbalancer-‐create \ <subnetId> \ -‐-‐name lb1 \ -‐-‐description "Front end LB"

35

Step 2: Create listener

neutron lbaas-‐listener-‐create \ -‐-‐loadbalancer lb1 \ -‐-‐connection-‐limit 100 \ -‐-‐protocol HTTP \ -‐-‐protocol-‐port 80 \ -‐-‐name listener1

36

Step 3: Create member pool

neutron lbaas-‐pool-‐create \ -‐-‐name pool1 \ -‐-‐protocol HTTP \ -‐-‐listener listener1 \ -‐-‐lb-‐algorithm ROUND_ROBIN

37

Step 4: Add instance members

neutron lbaas-‐member-‐create \ -‐-‐address <instanceIPv4> \ -‐-‐subnet <subnetId> \ -‐-‐protocol-‐port 80 \ pool1

38

Step 5: Verify!

curl http://$(neutron lbaas-‐loadbalancer-‐list | awk '/ lb1 / {print $6}')

OpenStack telemetry and monitoring-as-a-service

CEILOMETER

39

40

Telemetry

• Ceilometer is an OpenStack project whose aim is to gather metrics about system components.

• Main use cases are to allow for customer billing and integration with auto scale.

• Integrates with multiple different projects and has different measurement types for each one.

41

Telemetry service daemons

• compute agent polls the local libvirt daemon to acquire performance data

• central agent polls OpenStack APIs to keep tabs on resource existence

• collector service consumes AMQP notifications and dispatches data to the metering store

• API service presents aggregated data to consumers

• alarm-evaluator service determines when alarms fire

• alarm-notifier service initiates alarm actions, for example, executing an Auto Scale web hook

42

Meters

• Measure measure a particular aspect of resource usage (existence, CPU utilisation).

• Each meter has a name, unit of measurement, and a specific type:

• cumulative (overall CPU usage over time)

• delta (number of resources that can be deleted)

• standalone metric based on current point in time (current CPU)

• Samples are collections of data that were collected by a meter at one point in time. As such, they're given a timestamp.

43

Compute measurements

Name Unit Description

instance instance Existence of instance

memory.usage MBVolume of RAM used by the instance from the amount of

its allocated memory

cpu_util % Average CPU utilisation

disk.read.requests request Number of read requests

network.incoming.bytes B Number of incoming bytes

disk.ephemeral.size GB Size of ephemeral disk

44

LBaaS measurements

Name Description

network.services.lb.pool Existence of LB pool

network.services.lb.total.connections Total connections on a LB

network.services.lb.active.connections Active connections on a LB

network.services.lb.incoming.bytes Number of incoming bytes

network.services.lb.outgoing.bytes Number of outgoing Bytes

45

Statistics and pipelines

• Statistics represent aggregated data samples over a duration of time.

• Several functions to work with data records: count, max, min, avg, sum.

• Pipelines are middleware that transform data from a metric source into a more meaningful format. Use cases are unit conversion (Celsius to Fahrenheit), aggregation (collection over a finite duration) and rate of change.

46

Alarms

• Set of rules defining a monitor, plus a current state and a set of actions that must be triggered for particular changes of state.

• States are "ok", "alarm", and "insufficient data"

• Alarm dimensioning is the ability to narrow or widen the scope of an alarm's metering capacity, e.g. 1 alarm per resource, or 1 alarm for the entirety of a user's resources.

Concepts and Heat templates

AUTO SCALING IN OPENSTACK

47

48

Auto Scale

• Auto Scale groups will categorise our Nova instances.

• Scaling policies determine how groups grow or shrink.

• Ceilometer monitors resource usage on Nova instances.

• As events happen which trigger a policy that changes the number of instances in a scaling group, the autoscale API will generate a new template, and update-stack the stack that it manages.

49

Heat resources

• Autoscale group is the entity that represents an arbitrary set of heat resources to be scaled. Composed of a name, max_size, min_size, cooldown, and resources attributes.

• A scaling policy describes a particular type of change to a scaling group, such as "add -1 capacity" or "add +10% capacity" or "set 5 capacity".

• Represents a revokable webhook endpoint for executing a policy.

50

Auto scaling with Heat templates

git clone https://github.com/openstack/heat-‐templates

heat stack-‐create stack1 \ -‐-‐template-‐file heat-‐templates/hot/autoscale.yaml

51

Heat template

• OS::Neutron::LoadBalancer resource to distribute traffic to our OS::Neutron::Pool. We also attach an OS::Neutron::HealthMonitor resource to our LB.

• OS::Heat::AutoScalingGroup resource, composed of OS::Nova::Server resources. Every instance is a OS::Neutron::PoolMember according to its IPv4.

• OS::Ceilometer::Alarm resources for high and low CPU usage.

• OS::Heat::ScalingPolicy resources that scale group up and down based on Ceilometer alarm metrics.

• OS::Nova::Server resource for dedicated database instance.

Block storage, object storage, ephemeral storage, datastores

STORAGE MODELS

52

53

Storage models

Ephemeral Block storage Object storage

Used to... Run OS and scratch space

Add additional persistence to VM

Store long-term persistent data

Accessed through... File system Block device (partitioned,

formatted, mounted) REST API

Accessible from.. Within a VM Within a VM Anywhere

Managed by... Nova Cinder Swift

Persists until... VM termination Block device is deleted Resources are deleted

Sizing determined by... Flavors User Available storage

Encryption set by... Param in nova.conf Encrypted volume types N/A

54

Persistent storage hard drive types

• HDDs are efficient and economical when handling sequential I/O operations. Use standard persistent disks when your limiting factor is space or streaming throughput.

• SDDs are efficient and economical when handling high rates of random I/O operations per second. Use when your limiting factor is random IOPS or streaming throughput with low latency.

55

Commodity storage solutions

• Swift: highly scalable default for OpenStack

• Ceph and Gluster: distributed, shared file system.

• Linux Volume Manager (LVM): abstraction layer on top of physical disks to expose logical volumes to OS.

• ZFS: file system that also has functionality of a volume manager. Like LVM, it has no replication.

• Sheepdog: userspace distributed storage system.

56

Network-attached storage with Gluster

• Software product that allows you to build and consume a distributed file system across multiple server nodes.

• A brick is a storage server and its exported local mount point: storage1.intershop.com:/mnt/disk1

• A volume is a logical collection of bricks.

• FUSE is a module for unix OSs which enables non-privileged users to create their own filesystems without editing kernel code.

• Geo-replication across multiple DCs is one of the strongest reasons to use.

57

Distributed volume type

58

Replicated volumes

59

Striped volumes

60

How do our apps use these storage models?

• Filesystem storage of assets - use Swift and a CDN.

• Upload to a temporary location, then use worker instances and a job queue to upload the temporary files to Swift.

• Use JavaScript to transfer the file to Swift via an upload service. Perhaps it could provide upload progress so front end polling could happen.

• You use Swift's FormPost middleware to allow direct uploads to a container, either as a staging location before processing or the final location.

Scaling principles, NoSQL or RDBMS, OpenStack Trove

DATABASES IN OPENSTACK

61

62

Database scaling

• What do we mean by "scaling"?

• read scaling (handle higher volume of read ops);

• write scaling (high volumes of write ops).

• RDBMS: MySQL, PostgreSQL, SQLite.

• NoSQL

• key/value: Redis, MemcacheDB, etc.

• column: Cassandra, HBase, etc.

• document: MongoDB, Couchbase

• graph: OrientDB, Neo4J, etc.

63

Does NoSQL scale better?

• Isn't really a trade-off between NoSQL and RDBMS, but rather a trade-off between BASE and ACID.

• ACID can usually handle read scaling quite well. Sometimes BASE has perf bottlenecks due to missing functionality (joins, where restrictions etc.)

• Atomicity

• Consistency

• Durability

64

Scaling MySQL

• Check MySQL buffers are configured properly.

• Indexing is important.

• Use slaves for reading and masters for writing.

• Use a caching layer on top of MySQL.

• Use appropriate table types.

65

OpenStack Trove

• Trove is OpenStack's DBaaS. Introduced in Icehouse, mid-2014.

• Provides API to execute common database operations like creating and deleting databases, creating users, granting and revoking access.

• Runs on Nova instances with custom database images.

• More convenient than running database software yourself on bare VMs, but can be a bit more difficult to debug.

66

Trove architecture

67

Trove datastores

trove datastore-‐list

trove datastore-‐version-‐list <datastoreName>

68

Trove clusters

trove cluster-‐create <name> <datastore> <version> \ -‐-‐instance flavor=<flavorId> \ -‐-‐instance flavor=<flavorName> \ -‐-‐instance volume=<volumeId>

trove cluster-‐instances

trove cluster-‐grow <name> -‐-‐instance flavor=<id>

trove cluster-‐shrink <name> <instanceId>

69

Trove configuration groups

trove configuration-‐create <name> <configDictionary> \ -‐-‐datastore <name> \ -‐-‐datastore_version <version> \ -‐-‐description <desc>

trove configuration-‐attach <instance> <configuration>

trove configuration-‐parameter-‐list <id>

trove configuration-‐patch <id> <configDictionary>

70

Trove databases

trove database-‐create <instanceId> <dbName> \ -‐-‐character_set <charSet> \ -‐-‐collate <collate>

trove database-‐list

trove database-‐delete <id>

71

Trove users

trove user-‐create <instanceId> <name> <password> \ -‐-‐host <host> \ -‐-‐databases <db1> <db2> <db3> ...

trove user-‐list <instanceId>

trove user-‐grant-‐access <instance> <name> <db1> ...

trove user-‐revoke-‐access <instanceId> <name> <dbName>

72

Data backups

• Not just of data, but all codebases and databases need to be in revision control system.

• DB transaction manager improves availability and reliability by helping to ensure that the system is always in a consistent state and by providing a system-wide strategy for handling certain classes of failures.

• Operators guide helps you determine which paths on which machines should be regularly backed up.

Cells, regions, availability zones, host aggregate zones

RESOURCE ISOLATION

73

74

Isolation

• Segregating your private cloud across different regions is important for: • legal jurisdiction of data • natural disaster redundancy (earthquake fault lines, etc.) • low-latency API calls

• Cells and regions segregate an entire cloud and result in running separate Compute deployments.

• Availability Zones and Host Aggregates divide a single Compute deployment.

75

Cells and Regions

• Compute hosts are partitioned into groups called cells, which are configured in a tree.

• Top-level API cell running nova-‐api. Child cells run all other nova-‐* services.

• Allows one API server to control access to multiple cloud installations.

• Regions have a separate API endpoint per installation, providing more separation.

76

Availability Zones

• Enables Compute hosts to be categorised into logical groupings.

• AZ grouping provides physical isolation and added redundancy.

• For example, the common attribute could be: you can place racks that share a power source in one AZ; or categorise instead by different classes of hardware.

77

Host aggregates zones

• Enables you to further partition an availability zone into logical groups for load balancing and instance distribution.

• Usually works in the form of key/value pairs assigned to machines based on common attributes.

• For example, it can group a set of hosts that share specific flavours or images.

• While AZs are visible to users, HAs are only visible to administrators.

78

Comparison

Cells Regions AZs HAs

Use caseSingle Compute API endpoint, or second level of scheduling

Separate API endpoints with no

coordination

Logical separation for physical isolation or redundancy

To schedule a group of hosts with common

features

Example1 cloud with multiple sites: schedule VMs "anywhere" or on a

particular site

1 cloud with multiple sites: schedule VMs to a particular site

and share infra

A single-site cloud with equipment fed by separate power

supplies

Scheduling to hosts with trusted hardware support

OverheadExperimental.

Full nova instance per cell

Different API endpoint per region. Full nova instance

per region

Configuration changes to

nova.conf file

Configuration changes to

nova.conf file

Shared services

Keystone and the nova-api service Keystone Keystone. All nova

servicesKeystone. All nova services

79

Failover

• Elimination of single points of failure (SPOF). Need redundancy mechanisms for:

• Network components, such as switches and routers

• Applications and automatic service migration

• Storage components, such as block devices and Swift rings

• Facility services such as power, air conditioning, fire protection.

• CloudFlare DNS protection against DDoS etc.

• Frequent resiliency tests -- utilise standard cloud scenario tests to ensure your application remains resilient after many CI/CD cycles.

Cloud applications

Technology

Transcript of Cloud applications