Sardina Systems Resource Management Presentation

Sardina Systems Proprietary. Copyright (C) 2014 -- 2019. Sardina Systems. All rights reserved.
S A R D I N A
OpenStack + Kubernetes
resource management, efficiency, optimization
Kenneth Tan
kenneth.tan@sardinasystems.com
+44 798 941 7838 
+421 948 251 435
www.sardinasystems.com

1.
Sardina Systems
Integrated cloud platform:
Full-lifecycle automation

Smart Cloud Platform
Full OpenStack + Kubernetes
platform
Zero Downtime Operation
Assurance — industry-first
Option: OpenShift Origin
European Innovation
European cloud automation
ISV with presence in UK,
Romania, Russia, Slovakia
OpenStack Foundation
Corporate Sponsor
Young, Innovative
Founded in 2014
Day-1 Team: supercomputing,
finance, defence, telco
Today: 20+ people, PhDs
Award Winning
DCD Global Award
IDC HPC Innovation Award
EU H2020 winner
UK Data 50 Award
and more
Partners

2. resource management: vm, containers
3. back to basics: nuts and bolts
4. kvm
5. cpu
6. memory
7. storage
8. network
9. data center view: the payoff
10 & 11. solution and success stories
agenda

2.
resource
management

operator-consumer relationship
when relationship between operator and service
consumer is close and trusted, segregation and
contention is seldom a problem

operator-consumer relationship
when relationship between operator and service
consumer not close and trusted, management
of segregation and contention is key

containers
Unix V7: chroot process
isolation, filesystem access
segregation, tar packaging
1979
FreeBSD: jails, segregate
IP, configuration
2000
Linux VServer: jails,
segregate filesystem,
network, memory
2001
Solaris: Containers,
segregate system
resources, leverage ZFS
2004
Virtuozzo/OpenVZ: kernel
based virtualization,
isolation
2005
Linux: Process Containers,
cgoups, segregate CPU,
memory, disk, network
2006
Linux Containers (LXC):
container manager, croups,
namespaces
2008
Docker: LXC then
libcontainer, programable,
packaging with image
2013

containers: key functions
packaging system
kernel slicer

containers: key question
which kernel?
host kernel vs VM kernel

containers: slice host kernel
escape risk
operator: highly risky

containers: slice vm kernel
operator: no risk
any escape would be contained
within consumer’s environment

vm vs container, host vs vm
live migration
escape
nature of organizations

loosely-coupled relationship
commonly run workloads in vms
k8s, containers in vms
cleanly manage segregation

organizations and businesses
tightly coupled consumer + operator:
common in smaller organizations
loosely coupled = containers in vms
can be a mixture

enterprise
focus: loosely-coupled operator-consumer
relationship
typical in major enterprises

cloud resource management
1. given new vm requests, where should the vm be
placed (optimally)?
2. how can workloads in an environment be optimally
rebalanced across the servers?

what’s the payoff?
optimized capex + opex
cater to more workload with same capex + opex
optimized workload performance

translation …
costs go down
user + boss happiness go up :-)

3.
back to basics

constituents of cloud infrastructure
1. servers
2. storage devices
3. networking devices

infrastructure resource management
workload runs on servers
storage and networking are supporting/
enabling devices
focus on: servers, servers, servers!

what makes up a server?
1. cpu
2. memory
3. disk
4. network

what makes up a server?
1. cpu
2. memory
3. disk
4. network
these hardware parts are
managed by the
operating system,
typically linux.

4.
kvm

what is a vm?
from host’s perspective: a vm is nothing more than a
process
vm only emulates a machine, relying on underlying host
to provide actual cpu, memory, disk(s) and network
resources

vm resource management: reduces to process management

5.
cpu

cpu
linux is responsible for scheduling a process’ access to
the cpu

cpu
when process is ready to execute, linux queues the
process in an execution queue

cpu
length of execution queue: “system load”

cpu
processes in queue given time slices to execute on cpu

a common approach
manage cpu resource based on system load, try to
fit/match system load to notional cpu capacity

or worse …
matching static vcpu reservation to static resource
capacity!

what’s the problem with these approaches?

problem: cpu has many sub-parts
cpu has multiple execution units (integer, fp, for a
start!)
cpu’s execution units handle different operations,
which can be mutually exclusive!

problem: cpu has many sub-parts
but (the simple) “system load” view does not
differentiate between them!

problem: cpu needs data in registers
cpu can only operate on data in registers
if data required is not in registers, the data will
have to be fetched from higher levels of memory

cpu is idle when waiting for data!
… but “system load” will still show 1!

problem: cpu heterogeneity
with cpu heterogeneity, “system load” on one
machine may not necessarily translate “system
load” on another machine (or even linearly
comparable in any way!)

problem: cpu vs idleness
a loaded program that is idle does not require cpu
resource

demand spikes
operating system queues processes and allocates
the processes time to execute on cpu
demand spikes can therefore be handled
gracefully

(longer) demand spikes?
demand “spike” lasting more than “short” periods
of time are no longer spikes!

forecasting behavior?
operating system does not forecast behavior of
processes
why: expensive computationally, low likelihood of
accuracy

forecasting behavior
better: handle resource requirement dynamically
effectively

cpu resources in cloud infrastructure
bad idea to allocate based on static “units” of cpu
and overcommitment
leads to gross wastage, while real resource
contention problems remain!

cpu resources in cloud infrastructure
this is not news! …since 1968!
every time-sharing os since 1968 addresses this
problem!

the smart(er) way …
dynamic cpu resource allocation for vms
based on live utilization of each detailed subpart
resource of cpu
do it data-center-wide!

6.
memory

memory
a machine has multiple levels of memory hierarchy
(eg: caches, memory, swap)
not all memory are equal!

memory
operating system is responsible for moving data
throughout the memory hierarchy
data movement is not elemental, contrary to
popular assumption! data movement happens in
aggregate!

memory
memory organized as pages
memory is not allocated by linux when requested
by a process

memory
linux actively moves a process’ memory pages out
to swap, bring back when needed
access to multiple levels of memory hierarchy have
limits

a common approach
manage memory based on simplified view of
reserved memory of a vm, and overcommit

what’s the problem with this approach?

problem: data locality
not taking into account data locality (and why the
data is there)
not all memory are equal

problem: data locality
limits on access to multiple levels of memory
hierarchy
operating system actively page in/out a process’
memory

cpu can only operate on data in registers
when data is needed by a process in its execution
on a cpu, it will need to be moved in to the
registers
and there are limits on access to the multiple
levels of memory hierarchy

memory resources in cloud infrastructure
bad idea to just manage based on grossly
simplified view of static “reserved memory” and
overcommitment
leads to gross wastage while not addressing
resource contention problems, ignoring how an
operating system works!

memory resources in cloud infrastructure
this is not news! … since 1970!
these are the problems handled by every virtual
memory operating systems since 1970!

the smart(er) way …
dynamic memory resource management for vms
based on live utilization of each detailed resource
in the multiple memory hierarchy levels

7.
storage

storage
operating system is responsible for managing a
process’ access to storage devices
process does not read/write. process asks the
operating system to read/write!

storage
resource management: data volume and transfer
amount
physical limits on read/write access to data

a common approach
simply try to manage based on volume of
allocated storage, or try to be “smarter”, by
statically allocating i/o access

problem: getting to data
vms seldom access all data in allocated storage
volume at once: volume is not the key resume
management problem
bigger problem: physical limits on read/write
access to storage not taken into account

storage resources in cloud infrastructure
bad idea to just manage storage volume
allocation
bad idea to allocate based on static “units” of i/o
access, with or without overcommitment

storage resources in cloud infrastructure
yes, this is not news either!

the smart(er) approach …
dynamic storage resource management for vms:
important to be able to read/write the data!
based on live i/o subsystem resource utilization

8.
network

network
the operating system manages a process’ access
to network
networking stack (ip stack) handles HUGE variety
of network characteristics
operating system: queues network packets, flow
control, retransmission, etc.

network
bandwidth is not unlimited
bandwidth is not all … what about latency?

a common approach
assign amount of network bandwidth per vm,
whether statically or based on a formulaic profile

problem: not all ports are equal
uplinks and downlinks are not symmetric
ports on different switches may not be equal
what about cross-section bandwidth?

problem: networks are dynamic
contrast: data transfer vs flow control,
retransmission, network queue, buffers (for
example)
these network factors (and their underlying causes)
are not taken into account

network resources in cloud infrastructure
bad idea to just manage bandwidth allocation
(regardless of whether static or based on formulaic
profile)
not a solution for handling causes of
fragmentation, retransmission, flow control
problems, buffer bloat

yes, this is not news either!

dynamic network resource management for vms:
important to be able to send/receive the data!
based on live network i/o states

9.
“know” the data
center

full view of the data center
occurrence: what
reason: why
time points: when
locality: where
source: which

full view approach enables …
where to place new workload taking into account
live resource utilization across the facility
how to rebalance workload optimally on servers
taking into account live resource utilization across
the facility

more importantly …
to do so without negatively impacting overall
performance

knowing the data center solves …
catering to the workload with optimal number of
servers
maximize utilization on the servers without
impacting performance of the vms

knowing the data center …
costs go down
user + boss happiness go up :-)

10.
Sardina FishOS

Sardina FishOS
Smart Cloud Platform
OpenStack + Kubernetes
Full cloud platform: including
Ceph, management tools
Optional: Integrate OpenShift
Origin
Optimized OpEx + CapEx
World’s first energy-optimizing
and utilization-improving
Drop TCO by 60+%
Full VMware functionalities &
more at 10% of VMware price
Market-Leading Automation
Technology
Fully automated zero-
downtime operations
Infrastructure-as-code
AI-Driven
Provides AI-driven smart,
efficient, super-scalable cloud
automation technology
Automated smart fault
handling ensuring service
continuity
Built for Reliability
HA-by-default solution
architecture
Zero-downtime Upgrade
Scalable multi-site HA
Award Winning
DCD Global Award
IDC HPC Innovation Award
EU H2020 winner
UK Data 50 Award
and more

Cloud Platform Automation
— Built by Operators for
Operators
Fully automated Zero-
Downtime operations
Flexible, scalable, reliable,
efficient

11.
Success stories
Market-proven in large scale
environments

Successful FishOS implementations
Sun Trading (Finance)
❖ Top 10 trader on NY market
❖ 4 sites globally, managed as 1
Alpha System (Service Provider)
❖ FishOS solution blueprint
❖ Time scales: 1 day
❖ Hardware up at 1400
❖ FishOS environment up by 1700
Site: Government
❖ 150k VMs
❖ 1 site
Site: Research
❖ Major R&D site
❖ Full system design, retro-fit to fix
existing problematic, non-
upgradable system
Site: Financial Services
❖ Major European banking group
❖ 3 data centers in HQ location
❖ Time scales: 2 weeks
CFMS (Manufacturing)
❖ Aerospace design facility
❖ 1 site

Successful FishOS implementations
UniCORE (IT Services)
❖ IT services: finance, insurance
sector
❖ Accelerated development
U of Edinburgh (Academic,
Research)
❖ Largest UK public sector site
❖ Integration: deployment,
authentication, storage
Site: IT Services
❖ Technical computing
❖ Time scales: 1 week
❖ High performance storage and
networking integration
Site: IT Services
❖ IT services: public sector, utilities
Site: Machine Learning
❖ Major German public sector
❖ GPU-powered workload
… your site?

want a job?
want a free FishOS system?
kenneth.tan@sardinasystems.com
+44 798 941 7838
+421 948 251 435

Sardina Systems Resource Management Presentation

Recommended

Recommended

More Related Content

Similar to Sardina Systems Resource Management Presentation

Similar to Sardina Systems Resource Management Presentation (20)

More from OpenInfra Days Poland 2019

More from OpenInfra Days Poland 2019 (9)

Recently uploaded

Recently uploaded (20)

Sardina Systems Resource Management Presentation