3. How did you get here?, or Why are you trying to get
here?
You don’t like having a social life.
You love complexity.
This is your idea of fun.
Or ….
16. How to do the magic
MULTICLOUD MANAGER ARCHITECTURE
17. Why not use an existing controller?
Scale to millions, maybe billions of endpoints.
Be able to manage hybrid clouds, or even things that
don’t “look” like clouds.
18. How not to screw this up
Be a manager, not a micromanager.
Make the clouds do the heavy lifting.
For example – *don’t* go to MCM to validate Keystone
tokens.
Support multiple backends through a pluggable
architecture. OS “just another backend”.
19. Let’s make a controller!
We’ll spend the next two years making the platform.
Another two making it highly available.
And another two years making it scale.
Today
Six years of working on a controller
So let’s not.
20. Does such a unicorn exist?
Well, yes!
You use them every day.
They scale to millions of users and billions of
transactions.
Yes, we’re talking about web applications.
They load balance, auto scale, can be distributed
geographically and still play nice.
Plus, you can build one in just a few weeks.
21. An experiment
Write the MCM as a web application.
Don’t worry about “platform”.
There’s no need to solve every distributed computing
problem already solved.
Just use a PaaS.
23. Which PaaS
Any PaaS would do, we used google app engine APIs
powered by opensource AppScale.
This lets us deploy MCM inside a customer’s private
cloud of any flavor.
This architecture also lets us offer a hosted service
running “in the cloud” for MCM.
24. Multi Cloud Manager Architecture
PaaS
Webapp2 framework
MCM top half
MCM bottom half
OS
plugin
Physical
Router
plugin
IoT
plugi
n
AWS
plugi
n
Swagger
RESTful
API, json
in/out
Outside
World
Schedule
right
bottom half
DB
acces
ses
using
PaaS
API
25. MCM Platform Features
Supports load based auto scaling.
Distributed database backend (big table, cassandra).
Memcache for fast access of database contents.
Web based interface for viewing and monitoring
database contents.
Channels allow MCM to send real time messages to
clients without polling.
Etc., etc.
27. How to protect your cluster from Godzilla
Make two or more.
Using MCM templates, synchronize your config for
keystone, nova, glance, neutron, etc.
Application data is persisted by their databases doing
remote sync. Why?
Too much work for MCM, and we have a less-is-more
approach.
28. A/A or A/S clouds
VM images, user accounts,
compute, storage and
networking config DB
MCM Top Half
MCM Bottom
Half
App
DB
App
DB
• FM takes care of persisting configs and
images.
• Apps are responsible for syncing run-
time databases.
29. A/A or A/S clouds
VM images, user accounts,
compute, storage and
networking config DB
FM Top Half
FM Bottom Half
App
DB
App
DB
30. A/A or A/S clouds
VM images, user accounts,
compute, storage and
networking config DB
MCM Top Half
MCM Bottom
Half
App
DB
• Keystone data, glance images etc were
already synced by FM.
• App’s database had been setup to do
remote replication.
• No impact on your keystone, swift, etc
architecture or backends.
• The switch from one active zone to another
can be done using a GSLB or LB.
31. How to do authentication and authorization
IDENTITY MANAGEMENT
32. This is very boring
Basically, the authentication and authorization is done
“at the periphery” of the system, and MCM programs the
clouds using admin accounts on trusted/encrypted
channels.
MCM can use an external IdP (like oauth, saml, ldap
etc).
33. Server Creation
MCM
Keystone Nova
PG/
networking
1. Create
server
IdP (local
or
external)
2. get user &
group
Assignment
Authorization
Policy
3. get role, VDs,
tenant, etc.
4. check policy for
(operation, role)
5. Create server
using token
5’. If token has
expired,
reauthenticate
Bottom Half
Neutron
6. Check token 7. Create
port using
svc user
token
8. Create
port using
svc user
token
(keystone or
PG?)