How do you operationalize OpenStack?

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?

OpenStack cloud-init cannot contact or ping to establish meta-data connection – fix

Using OpenStack Open vSwitch with VLAN’s removes a lot of the trickery involved with using public and private IP’s. That way each VM gets it’s own real IP address assigned to it.

In this case, our network layout looks as such:

Logical Network Layout
Logical Network Layout

That being said, the VM’s still need a way to get back to for access to the OpenStack metadata service. In this case, the fix was to add a static route to the VM and re-configure the neutron-dhcp-agent service as such.

On the vm template, add /etc/sysconfig/network-scripts/route-eth0: dev eth0

Then add the following to /etc/neutron/dhcp-agent.ini

enable_isolated_metadata = True
enable_metadata_network = False

and then restart the Neutron dhcp agent service:

service neutron_dhcp_agent restart

Once this is finished, you should then be able to add the updated image to glance and deploy without issue.

vCloud Automation Center 6.0 Installation fails with error code 1603 – Fix

So during my IAAS installation of vCloud Automation Center 6.0 (vCAC), I was getting the error during the installation saying:

VCAC Server Setup Installation Failed, ExitCode:1603

After digging and digging, I realized that .NET Framework 4.5.1 was installed. So as a hunch, I uninstalled .NET Framework 4.5.1 and re-installed it from the IIAS installation URL (https://vcac.domain.local:5480/installer/).

After re-installing, I was then successfully able to run the vCAC IAAS installer.


Microsoft announces their support and contribution to the OpenCompute project

On the brink of Open Compute Project Summit 2040 (OCP Summit V) starting tomorrow morning, Microsoft today announced the contribution of their cloud server designs to the Open Compute Project.

Microsoft OCP Keynote
Microsoft OCP Keynote

Interestingly enough, Bill Laing was scheduled to present a keynote tomorrow at the summit. This was surprising to me as Microsoft has been traditionally quiet about elaboration as to what kind of equipment they were using to power Azure. Now officially defined as the Microsoft Cloud Server Platform. This puts Microsoft in line with Facebook, to be the only cloud service providers to publicly release their server specifications. Continue reading “Microsoft announces their support and contribution to the OpenCompute project”