So after “living with OpenStack” for a couple months now, I’ve been taking notes and such, figured I’d share them. This view is from a managed services environment, but an enterprise view would be ok as well.

• Our OpenStack architecture cannot, and will-not look like our Vmware architecture where each hypervisor node also provides storage, etc.
  • Compute nodes would be just that, compute nodes with storage client connectivity (gluster, cinder, NFS, gpfs, etc)
  • Compute nodes would also need to run neutron
  • Controller nodes would be services nodes:
    • Heat
    • Glance
    • Horizon
    • Keystone
    • Nova
    • Neutron
  • Storage Nodes would be services nodes:
    • Cinder
    • NFS
    • GPFS/Gluster
  • Storage tiering as we know it (pick the datastore you want) does not exist in OpenStack
    • For storage tiering, you can skin that cat many ways:
    • Multiple cinder nodes with different storage backings
    • Multiple gluster/ceph nodes with different storage backings
  • Networking… so far, we’ve approached networking the same way we’re doing it now, where each VM has its own real IP address.
    • OpenStack allows us to empower the customer to build/destroy/configure their own networks
      • Faults to this: we’re not mature enough in managed services (skill-set throughout the stack)
      • Our customers are not mature enough
      • Further complicates an already complicated stance
  • HA OpenStack (VMware clone) would be impossible to operationalize
    • Some services would need to be cloned then load balanced
    • Some service would need to be configured in failover capability
    • This further obfuscates the entire stack beyond what it already is.
  • Horizon is a huge step in the right direction for customer interaction.
    • Horizon community is lacking essential services plugins (billing, automation, networking, storage
  • Image management
    • This is nonexistent and very cumbersome
    • The “best” method I’ve found is to build your images on vmware, then import the VMDK.
    • Tinkering with qemu-kvm is bothersome because of the network separation between qemu-kvm and OpenStack
    • Static routes need to be present in Linux VM’s, Additional routes are added to VLAN’s for Windows VM’s
  • Celiometer
    • API interaction/CLI interaction only, not available via Horizon
  • Heat
    • More of a vAPP utility than a orchestration engine as we know it
  • Still very powerful, but very difficult to interact with (customer/operations)
• My #1 complaint is the fact that there are sooooooo many interfaces to interact with when it comes to just running OpenStack.
  • Linux
  • Nova
  • Keystone
  • Cinder
  • Neutron
  • Heat
  • Celiometer
  • Horizon
  • Glance
  • Storage subsystems
  • NFS
  • iSCSI
  • Local
  • Gluster
  • CEPH
  • GPFS
  • Pacemaker

How do you then operationalize OpenStack? Even using a product like IBM SmartCloud Orchestrator, or VMware vCAC to “hide” OpenStack behind; you still need operations procedures for when “it” breaks… and as we all know, “it” will break.

How do you operationalize OpenStack?

Tags: Open Stack, OpenStack, Operationalization, Operations