2. Firstly….Thank you
• Wish to acknowledge the contributions of the
community and the sponsoring organisations
Believe OpenStack is on the
cusp of being to Cloud what
Linux was/is to the OS
• Hope that this presentation adds value to this
conference – and helps this community through
understanding of how this fabulous and innovative
software is being taken to market by Australia’s
leading next-generation technology solutions
company 2
3. Scope of Presentation
• Current Context
– About Mach Technology
– Who is Paul Pettigrew? Why am I here?
– Underlying Facilities Platform
– How we define Cloud
– Cloud Security Lessons
• Integrated Technology + Services Solution
– Our “NG” Project’s Business Requirements
– Integrated Solution Architecture
– Rollout Strategy
– Our “todo wish list” for OpenStack
• Conclusion & Questions
3
5. About Mach Technology
• Founded in 2005 on rising wave of Open Source,
Linux and High Performance / Federated Grid
Computing – to deliver outsourced solutions,
smarter, better & at lower cost than proprietary
• Lines of business and deep expertise in:
– Consulting & Project Management
– Mach owned & operated Data Centres, Hosting and
Cloud (inc IaaS/PaaS/SaaS)
– Service Desk
– Technical Services
– Onsite Field Services
– 24/7 automated deep monitoring and self-healing
– Turnkey outsourced ICT Managed Services 5
6. Who & Why am I here?
• Loved technology and computing, since
wrote first program on a 1” thick pile of
IBM cards in the early 80’s
• F/A-18 Instructor & Fighter Pilot,
also on front line of modern
computing introduction into
Royal Australian Air Force
• Presenting is Mach’s way to make a contribution to the
community and share our hard-learned knowledge
• To learn from the experts, and take knowledge back to
Australia and pass onto others in our industry & clients
• Validate and improve our strategy 6
7. Underlying Facilities #1 Services: Shared
nothing, federated HA, 4N
Platform & Data Centres Since 2005 go-live, not a
single second of down time
7
8. How we define “Cloud”
• Elastic: resources are re-allocated, increased or decreased on demand
(typically instantly)
• Multi-tenant: compute, storage and network resources are shared to deliver
multiple platform services per each hardware component and dynamically
(re)allocated as required
• Thin Provisioning: compute, storage and network assets provided via
virtualised, location independent, technology agnostic platforms (no vendor
lock-in) – i.e. using real hardware resources only when required
• Over Subscription: compute, storage and network assets are over-allocated
but pro-actively capacity managed to have physical provisioning occur in time
for actual demand
plus
• Automation: Extreme levels of automation: provisioning, monitoring, self-
healing, patching/updating & maintaining
• Open: Portable sub-systems / no proprietary lock-in
• Billing: Sophisticated presentation of data to enable “to the second” invoicing
8
9. Cloud Service Layers
“X-as-a-Service”
Applications
Acknowledge: based on depiction produced by Cloud.com
Application A Application B Application C Application D Application E
Platforms
Directory Database Message Web Other
User Interface
Developer API
Administrator End User Console
Availability and Security Image Libraries
Integration API
Backup Firewall HA Monitoring
Application Catalogue SaaS
Dynamic Workload Management
Custom Templates PaaS
Resource Management
Servers Storage Network Operating Systems ISOs IaaS
Service Management (Billing, Metering, Accounts, Monitoring, etc)
Virtualisation Layer
Servers Network Storage
9
11. Cloud Security Lessons
• Current bandwagon/marketing hype is not helping
• Mach has government and large commercial clients acutely aware of the issues
– Mach has solved to date, without incident – but not in fashion that meets our future
automation and multi-tenant objectives
• We must leverage “education” in market
– E.g. “VLAN” accepted, but no understanding of what “OpenFlow” is and if it is
“secure”
– Public Key cryptography “PKI” also known and trusted
• Storage must be addressed through unified security and identity management
– Easy option for encryption of files, using PKI
• We must be able to answer the question “is my data safe, secure and private”
in a single word = Yes!
• Goal: build upon the acceptance of the VLAN ID “tag” concept, and apply it
across all IaaS aspects to create unified “security zones”
– Networking: VLAN (and also OpenFlow)
– Storage: encrypted files
– Server: SSH / PKI based access already proven and trusted
Can “Cloud Security” be as simple as PKI+VLAN per “security zone”?
11
13. Elevator Pitches
• “Bill to the second, on demand”
• “Australia’s first Next Generation, IPv6 XaaS Cloud
Hosting Solutions”
• “Consulting, Services, XaaS, Onsite – Unified
Platform”
• “Price per VM = others’ price per website”
• “Single bill, single sign-on”
• “Metal + Virtualisation”
• “Quad Data Centres, redundant highly available
deployment”
13
14. Business Requirements
• Vision: next-generation of full ICT service outsourcing
• Principles:
– 100% free libre Open Source; commodity hardware
– Mach value-adds through SI and staff service excellence
– Flexible, to accommodate waves of innovation over next 5 years
– Extreme levels of automation and self-healing
– No real technical skill required to enact subscriptions
– Moderate technical skill required to provision and maintain platform
– Scale out “just-in-time” per sales/revenue
– Multi-DC, federated architecture
– IPv6
14
16. Integrated Architecture
• Issue with first line-up? Too much SI
• Have progressed with aspects knew would be right
(Phase 1)
• Fundamental: Integration of Billing Engine,
Identity Management, Ticketing and Provisioning
• Knew from experience that IaaS solution must be
simplified and integrated across Storage +
Compute + Network
• Held off over past year for technology to
emerge…and then we discovered OpenStack…
16
18. Use Cases
• Mach is not in the business of competing
with massive scale, constrained product
parameters Cloud hosting
• Our value is leveraging emerging
technologies in a thrifty + high quality
fashion, to deliver a total solution
• Must accommodate both “metal” &/or
“virtual”
• Security Lessons must be addressed
• Able to abstract to 5x Use Cases…
18
19. Scenario 1: Single VM
• Single VM connected to the internal network for storage access and the
external network for WAN
• Should be able to talk L2 to management system, storage nodes and
WAN gateway, but nothing else (VM1 and VM2 cannot see each other)
• Should be the default for all new VMs
L2 Zone
Storage
External Network
Internal Network
VM1 WAN
nodes and
Gateway
management
VM2
19
20. Scenario 2: Multiple VMs
• Multiple VMs connected to the internal network for storage access and the
external network for WAN, all in the same security zone
• Like scenario 1, but the VMs in the same zone should be able to talk L2 to each
other (VMs 1,2 and 3 can communicate, but cannot talk to VM4)
• This is for customers with multiple VMs that need to communicate at L2 (they
can already communicate at L3 via the WAN Gateway)
L2 Zone
VM1
Storage
External Network
Internal Network
VM2 WAN
nodes and
Gateway
management
VM3
VM4
20
21. Scenario 3: VSD
• Single or multiple VMs connected to the internal network for storage
access and the external network for WAN, with a VSD in the same
security zone
• All access to the VMs from the WAN filtered (bridged or routed modes
supported) by VSD, VMs cannot talk to WAN gateway directly
L2 Zone
VM1
Storage
External Network
Internal Network
VM2 VSD WAN
nodes and
Gateway
management
VM3
VM4
21
22. Scenario 4: Physical FW
• Single or multiple VMs connected to the internal network for storage
access and the external network for WAN, with a physical FW (i.e.
Cisco ASA device) in the same security zone
• All access to the VMs from the WAN filtered by FW device, VMs cannot
talk L2 to WAN gateway directly
L2 Zone
VM1
Storage Phys.
External Network
Internal Network
VM2 WAN
nodes and FW Gateway
management
VM3
VM4
22
23. Scenario 5: Dedicated Metal
• To support customer requests for non-virtualised, physical
server OS deployment (i.e. Linux/Windows running on
metal) – “dedicated metal machines” (DMM)
• We want them to be configured the same as all compute
nodes such that they can easily be managed in the same
way and converted DMM<->VM
– Any solution that gets these servers onto the virtual switching
fabric so we can control their L2 in the same way requires
repatching when a DMM becomes a VM host or vice versa
• The solution is to gateway the DMM L2 through a box that
is on the virtual switching fabric – see next slide
23
24. Scenario 5: DMM Patching
• Dedicated metal machines repatched to gateway through a
Linux GW that places them on virtual switching fabric
• The physical switch is configured with every port in it’s own
port-based VLAN, with the Linux GW port in every VLAN
• Supporting the feature will guarantee we can meet
specialist/dedicated requirements of our large customers
DMM
DMM
Physical Linux Virtual
Switch GW Switch
DMM
24
25. What was left?
• Identity
– Issue is that every subsystem has its own
identity/auth solution
– Critical that a centralised, multi-tenant, multi-
subsystems platform exist
• Billing
– Basic subscription billing for a rudimentary
Cloud hosting product stack easy
– As an outsourcer, must support single invoice
• Subscription + Fixed Price or T&M + Known & Ad
Hoc
25
26. Identity Management
• Closely integrated with the Billing Engine is the idea of
Identity Management
• Needs to map all of our Accounts, all of their Users and all
of the access control for which users can access which
Subscriptions
• Billing can use this information for generation of XaaS
billing data
• Ticketing can use this information for linking Tickets to
associated Subscription procured
– E.g. Add a note “article” to a ticket for 15mins worked on “Hosted
Exchange” for Account “ABC”
• Provisioning can use this information for access control to
systems/applications
26
27. Centralised Directory
(389 HA)
• Clustered 389 Directory Server for centralised
authentication, account and billing metadata
– Multi-master replication of directory writes
– Many active nodes for directory reads (authentications
etc)
– Support multiple customers in directory hierarchy
– Easily add new attributes for billing and account/profile
metadata to be used in other applications
– Support SSL authentications over the Internet
– Provide password and account metadata
synchronisation for Active Directory
27
28. Billing Architecture
In-house
Bill Presentment Ticket
Website Shopping Cart Management
& Payment Presentment
Tools
Mach API
Integrate
Integrate
Identity
Billing Engine
Integrate
Integrate
Single
Invoice Management
(jBilling)
(389)
Happy Customers
Mediation
Process
Billing Data
VMs
Storage VZ Tickets
SaaS
SaaS
PaaS
Plesk PBAS Timesheet OTRS
OpenStack DNS Work
Networking Orders
Identity Data
28
30. Phase 1 – Alignment /
Initial Steps
• Phase 1 – Alignment / Initial Steps
– Mediawiki for all doco, smart URL linking access from other systems
(1,944 articles, 15,708 edits/updates)
– Zabbix for 24/7 monitoring & (initial) self-healing via federated HA
platform (578 hosts; 17573 data items; 6325 smart trigger
calculations; 5592 automated tests performed per minute)
– OTRS::ITSM for ITILv3 Service Management (2,700 tickets per
month)
– Bacula for backup & recovery independent of cloud platform
(42,689 backups, 0.53TB delta per day across 546 volumes)
– 389 Directory Server Cluster, deployed federated HA (~3000
customers)
– BETA: KVM based platforms for Linux/Windows/BSD/Solaris (15
hosts, 55 VMs)
Completed & working perfectly :-)
30
32. Phase 3 – BETA Launch
• Phase 3 – BETA Launch
– Phase 1 + 2 aspects completed
– Across 2x DC’s (only) to prove distributed/federated
solution
– Limited (spin-off brand) launch to prove in marketplace
32
33. Phase 4 – New Normal
• Phase 4 – New Normal (no longer
“Next Generation”)
– New sales onto new platform
– Migrate old services
– Complete 6-9mths
• Risks addressed in Phases 2/3 before the
company goes “all in”
33
34. OpenStack Wishlist
• CAVEAT: very happy to be corrected if these points are already
addressed
• Unified security zone across compute + storage + network, for each
cloud/domain
– Spans multiple DC’s (low WAN comms)
– Multiple clouds per account
– Encryption of storage objects (files, VM disk images, etc)
• Billing units and metering
– Billing platform must not need to know detailed technical operation
– Abstract to universal “billing unit”, price book applied in billing platform
– Bill “on demand” to the second
• Class of service – abstracted as a high level concept, then given technical
meaning and billing alignment, e.g.:
– Single
– Cold/offline DR failover
– Hot/live HA failover
• Extreme automation, especially in management of platform and patching
burden
– An integrated and supported toolchain 34
