Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Replacing vCloud with OpenNebula

123 views

Published on

A deep insight into a project with codename "TARDIS" at HAUFE Lexware with the purpose to replace vCloud with OpenNebula. A technical deep dive into a focussed project done by real DevOps experts.

Published in: Software
  • Be the first to comment

  • Be the first to like this

Replacing vCloud with OpenNebula

  1. 1. OpenNebula @ Haufe Group A somewhat unusual Use-case 26th of September 2019 | Techday@NTS, Vienna
  2. 2. PATRICK MARTINS SYSTEMS ENGINEER JENS LANGHAMMER LINUX DEVOPS PROFESSIONAL
  3. 3. Table of Contents • What we do, who we are • Current Situation • Why OpenNebula • What OpenNebula is missing • Planned Architecture • Public Cloud
  4. 4. What we do at Haufe • We make software (e.g. tax, finance, payroll) • A wide range of Products • From Web-Applications over mobile Apps to Desktop Applications • Many small, autonomous teams • Teams can consume central Services, but don’t have to
  5. 5. Haufe, NTS and OpenNebula
  6. 6. Tardis • Project Owner à Alexander Keller • Technical Lead à Jens Langhammer • Patrick Martins à external Support • 3 planed releases Future-proof virtualisation orchestration for software testing with commercial support
  7. 7. Current Situation – Software Testing • vCloud Director SP • vSphere 6.5 • 14 Hosts, 128 Cores, 2 TB RAM • 650+ VMs • Interactions • Testers create new VMs via the Portal • VMs are created via the API • Use-cases • Automated Builds • Support Agents replicating Client Setups
  8. 8. Current Workflow • vApps to ”containerise” Images • Single Client VM • Server + Client VM • Network is always fenced • About 1500 pre-built Images • Base Images for all sorts of Operating Systems • Automated builds create Images
  9. 9. Issues • Unknown Future of vCloud Director • High Maintenance effort • Little Customisation • High License costs • Locked into the VMware-ecosystem
  10. 10. How OpenNebula helps us • Fewer License Costs • Hosts running Ubuntu • Support through NTS • Open-Source, thus customizable • Abstraction • Workloads might need vSphere for Support • Possibility to use Public Clouds • Easier Maintenance
  11. 11. What OpenNebula is missing • Fully automated Network Virtualization • Higher Quality Console • Lifecycle for OpenNebula Services • VM Leases OpenNebula „Fund a feature“
  12. 12. Planned Architecture Virtual Cloud Infrastructure IaaS Cloud Stack Bare-Metal-Deployment & Life-Cycle-Management Config-Management (SDI) Automation Infrastructure Physical Hardware Hypervisor Storage Networking Physical Infrastructure NFS 802.1Q VLAN VXLAN (OpenNebula Services Provider)
  13. 13. Public Cloud Beware the Buzzwords
  14. 14. Current Situation – Public Cloud • AWS Accounts per Project • Default Subnets, Security Groups, etc • No ”hard” guidelines – Teams can do what they want
  15. 15. Goal • Make it easier to deploy • Provide a single Interface • Prevent Users from abuse • Familiar Environment
  16. 16. Enter Watson… • Simplify AWS Network Selection • Simplify AWS EC2 Authentication • Simplify Domain Join
  17. 17. Behind the scenes • Set SUBNETID • Set SECURITYGROUPIDS • Set Name Tag based on OpenNebula Name • Linux • Set SSH-Key based on User’s SSH-Key • Windows • Set Random Password • Domain Join (the complicated way)
  18. 18. Demo Time!

×