Ervaringen met OpenStack als Virtualisatie platform voor MKB

OpenStack is wellicht bij veel mensen al bekend als een cloud management platform gebaseerd op open source en KVM virtualisatie. In de afgelopen jaren zie je dat steeds meer bedrijven een eigen OpenStack implementatie maken of intensief gebruiken, denk hierbij aan RedHat, Oracle, IBM, Cisco en vast nog veel meer bedrijven. En dat steeds meer producten, waaronder ISE, Prime, vWLC, switches, routers, standaard ook onder KVM worden worden.Dit ook omdat de markt (providers) er duidelijk om vraagt.. VMWare en Microsoft hebben in de cloud-wereld er duidelijk een concurrent bij (zeker als je bedenkt dat PayPal in 2013 al haar omgeving aan het omzetten was naar OpenStack om uiteindelijk het volledige ebay-platform a 80-duizend servers naar Openstack te verplaatsen en VMWare te vervangen).

De afgelopen jaren heeft OpenStack een enorme vlucht genomen in zowel gebruik als ook de volwassenheid van het systeem. Zelf volg ik de ontwikkelingen binnen OpenStack al een aantal jaren met veel interesse. Afgelopen zomer op Cisco Live heb ik een techtorial sessie gevolgd over OpenStack in het algemeen en de netwerkkant in het bijzonder.
De meest recente release van Openstack, Openstack Newton, lijkt een behoorlijk volwassen omgeving geworden. En ik vraag me al wat langere tijd af of OpenStack niet inmiddels ook volwassen genoeg is geworden om gebruikt te kunnen worden als virtualisatie-platform voor de MKB-markt (als tegenhanger van VMWare en Microsoft).

En wat is een betere manier om deze vraag te beantwoorden dan om het zelf uit te gaan proberen, en mijn huidige virtualisatie-server (HP Microserver Gen 8 met 16Gb memory, paar 4 TB disken en een LaCie Big5 NAS) maar eens om te gaan zetten van VMWare vSphere naar Openstack. En daarbij mijn paar gevirtualiseerde servers (FirePower management center, paar CentOS servers, asterisk voor SIP) om te zetten naar KVM.
Daarbij zou het ook nog weleens interessant kunnen zijn om de Cisco Nexus1000V voor KVM te integreren in de openstack omgeving, om weer “lekker” met interface- en port-profile configuraties te kunnen werken. De 1000V essentials is immers een gratis product.

En de afgelopen week heb ik wat tijd en ruimte gekregen om dit voor elkaar te krijgen, maar hoe zorg je er nu voor dat je bestaande omgeving blijft draaien en jezelf bezig kan zijn.. Eigenlijk heel eenvoudig, ik had nog een oude laptop en een oude VMWare Fusion beschikbaar, met vlan interfaces op de Mac de juiste bridges gemaakt en de essentiële vm’s lekker laten draaien onder VMware Fusion. Dat werkt goed en had ik tijd en rust om eens rustig met OpenStack aan de gang te gaan en mijn ervaringen te delen over OpenStack.

OpenStack

Openstack is een op open source gebaseerd cloud provisioning en management platform. Dat betekent dat er een paar architectuur gedachtes achter OpenStack liggen die wellicht handig zijn om kort toe te lichten. De uitleg die ik hier geef is een (summiere) samenvatting van een veel grotere architectuur, die goed op OpenStack te lezen valt.

Zoals gezegd is OpenStack een Cloud platform, dat betekent dat het per definitie een multi-tenant omgeving is (waar dus op een fysieke infrastructuur meerdere omgevingen geïsoleerd van elkaar moeten kunnen functioneren). Binnen OpenStack wordt elke tenant een Project genoemd, en elk project heeft vanzelfsprekend users (met rechten en rollen) en een quota aan beschikbare resources binnen de volledige omgeving. Je kan en mag daar als “gebruiker” dan ook niet overheen gaan. In de omgeving die ik heb gemaakt mag mijn eigen omgeving maar 20 vCPU’s aanmaken en heeft 1TB aan storage.

Iedere tenant krijgt eigenlijk de mogelijkheid om zelf een volledig eigen omgeving, bestaande uit compute (rekenkracht en memory), storage (images en volumes) en connectiviteit (networking) in te richten, net als binnen Azure, AWS, Google Cloud, etc en kan er eventueel afgerekend worden op gebruik.

Om een virtuele machine (instance) te starten heb je binnen OpenStack een paar zaken nodig, anders kan de instance niet aangemaakt worden.

– Opslag (de harde schijf waar de gegevens van de VM opstaan)
– Networking (een ip-adres voor conncetiviteit)
– Compute (hoeveelheid vCPU en memory)

En in de opslag zit een mooie feature van OpenStack. OpenStack kent namelijk twee soorten van opslag, images en Volumes. Het verschil zit hem in het volgende, een Image moet je zien als een basis-disk van een VM die de specifieke instance niet kan wijzigen, in plaats daarvan wordt er bij de VM een “ephemeral” disk gekoppeld, waarin de wijzigingen voor die specifieke VM opgeslagen worden. En deze wijzigingen zijn beperkt tot een geconfigureerde hoeveelheid gb’s. Deze hoeveelheid Gb’s zijn gekoppeld aan de “flavor” die aan de instance gekoppeld moet worden. Deze flavor vertelt ook hoeveel vCPU en memory beschikbaar is. Wordt de instance verwijderd, dan worden de wijzigingen ook verwijderd. Daar moet je dus goed mee opletten als je een instance aanmaakt op basis van een image. Dit is natuurlijk heel mooi voor gestandaardiseerde (grote) omgevingen zoals webservers, application servers én natuurlijk ook virtuele desktops (dit wordt namelijk ook door VMWare bij VDI toegepast).

Het alternatief is gebruik te maken van een volume voor de instance, hierbij worden de wijzigingen wél opgeslagen op het specifieke volume. Verwijder je de instance, wordt het volume niet verwijderd, tenzij je dat bij het aanmaken van de instance hebt aangegeven natuurlijk. Nadeel van volume’s is dat je meer opslagruimte nodig hebt en dat er wat meer “klassiek” gedacht is, maar voor servers die je niet en masse uitrolt is dit natuurlijk een prima oplossing…

Binnen OpenStack moet je natuurlijk ook connectiviteit realiseren, zowel binnen in je eigen virtuele omgeving als ook de connectiviteit naar buiten. Ook hier werkt OpenStack vanzelfsprekend met de cloud-gedachte. Je kan en mag zelf één of meerdere lokale subnetten maken die via een virtuele router aan elkaar worden gekoppeld. Vanuit de provider (beheerder) krijg je vaak een gedeeld subnet (het externe netwerk) waarmee machines naar buiten kunnen communiceren.

Voor alle netwerken geldt dat OpenStack op basis van subnets en reeksen ip-adressen automatisch (en dynamisch) toekent aan de instance, een load balancer of dns moeten dan zorgen voor de rest.. Want als de instance uitgaat kan daardoor het ip-adres hergebruikt worden voor een andere instance.. Het is echter ook mogelijk om vaste ip-adressen aan te maken, hier later meer over.

Elke instance heeft ook één of meerdere security-groups gekoppeld. In een security-group definieer je ACL-regels voor inkomend en uitgaand verkeer. Tot nu toe ben ik uitgegaan van een vrij open omgeving, maar die kan fors dichtgezet worden. Zonder security-groups is er met de instance géén communicatie mogelijk.

Veel zaken binnen OpenStack zijn dus (vanzelfsprekend) gebaseerd op cloud (standaard images, eigen of publieke), tijdelijke opslag voor een instance), dynamsiche inregeling en beperking van de resources.

Wellicht ook doordat het (bijna) volledig open source is, is er niet één project OpenStack maar zijn er meerdere projecten die gezamenlijk als geheel OpenStack vormen. Die modulariteit is natuurlijk heel mooi (en flexibel), maar is ook behoorlijk overweldigend, want elk project heeft zijn eigen naam en ook vaak meerdere services die er weer onder vallen. Zie onderstaande conceptuele architectuurplaat.

En bijna elke module werkt in een controller – node structuur, dus een controller die aanstuurt en de node die het werk uitvoert. Het voordeel hiervan is dat je, in een grotere omgeving, de controllers op een apart cluster kan plaatsen (wellicht zelfs in Docker Containers voor upgradebaarheid) en

De projecten (modules) die ik het meeste gebruikt heb, en daarmee voor mij “makkelijker” zijn geworden, zijn als volgt

Module	Uitleg
Nova	Dit is de Compute module van OpenStack en zorgt voor de hypervisor omgeving waarin de instances worden gestart en uitgevoerd. Hierbij wordt de opslag behorend bij een instance standaard gekopieerd naar lokale disk om vanaf daar verder uit te voeren. Dit heeft mij in het begin wel even genekt in de opzet
Horizon	Dit is de web-frontend / dashboard voor OpenStack. Na de configuratie van OpenStack (welke node heeft welke module) kan je hier de omgevingen en klanten in beheren.
Neutron	Dit is de networking module, waarmee de connectiviteit wordt ingeregeld. Neutron is ook weer modulair opgebouwd met standaard router, dhcp, laag2 functionaliteit via openswitch. Het is ook mogelijk om hier een Nexus1000V in te plaatsen
Keystone	Wordt gebruikt voor authenticatie en beheer
Glance	Glance wordt gebruikt voor het beheren (inclusief importeren en aanmaken) van images, die gebruikt kunnen worden bij het opstarten van de vm’s (instances)
Cinder	Cinder voorziet in het beheer van (bijna) opslag. Cinder gebruikt weer één of meerdere (zeer krachtig) backend opslag devices, zoals lvm (Linux local disks, NFS, iSCSI, CEPH (open source gedistribueerd opslag systeem op basis van normale computers) en ook specifieke backends (commercieel) voor NetApp, EMC, Dell, Hitachi (HNAS), etc.. Ook FC wordt ondersteund..
PackStack	Het is natuurlijk mogelijk om zelf stap voor stap OpenStack met alle modules te configureren en in te richten. Maar dat kan (gelukkig) ook eenvoudiger. PackStack is een module die, op basis van puppet, alle machines binnen OpenStack voor je kan inrichten. De standaard waardes zijn goed voor een proof of concept, maar mijn ervaring is dat je de answer-file moet aanpassen voordat je naar een wat ruimere omgeving gaat.

OpenStack is nog veel uitgebreider, met bijvoorbeeld ook modules voor object-opslag (handig voor zaken die niet veel wijzigen), of een “fileshare” opslag, zodat je binnen je cloud ook volumes kan maken die je standaard kan delen over meerdere instances heen (handig voor de website-data of fileserver data). Er is ook veel literatuur te vinden over OpenStack, met ook tot in detail uitleg over hoe de flows lopen.

Ervaringen

Installatie

De ervaringen die ik heb met OpenStack zijn wisselend, zo heb ik uiteindelijk OpenStack de afgelopen week 3x geïnstalleerd (waar je wel steeds handiger in wordt) en liep ik ook wel tegen verschillende problemen aan die meer met HP en Raid Controllers te maken had dan met OpenStack zelf..  De pogingen die ik gedaan heb met de daarop volgende conclusies:

1. Packstack met de standaard antwoorden én demo-omgeving
   Deze installatie is voor een all-in-one en proof of concept heel mooi, met wat aanpassingen en toevoegingen heb ik een provider VLAN netwerk kunnen toevoegen en ben ik enthousiast verder gaan bouwen. Maar standaard wordt maar 20Gb aan Cinder volume aangemaakt en had ik een SSD disk gebruikt, dus onvoldoende opslag voor de vm’s die Nova nodig heeft
2. Packstack met standaard antwoorden, zonder demo-omgeving en met Ceph
   Ceph is een open source oplossing voor het aanbieden voor gedistribueerde, redundante én schaalbare opslag via standaard software en harde schijven. Een behoorlijk volwassen product en krijgt binnen OpenStack steeds meer tractie, omdat je hierdoor ook lokale disken en hardware kan gebruiken om extra opslag te regelen. Maar voor één server met één lokale disk krijg je weinig redundantie en gaf het in mijn beleving met de server die ik heb wat mindere performance. Ook liep ik tegen wat provider-VLAN networking issues aan, en dus naar poging 3
3. Packstack standaard antwoorden, zonder demo-omgeving, LVM als opslag
   Dit is de huidige oplossing die ik heb staan. Een schone CentOS install, met voldoende ruimte  op /  (/home beperkt), packstack de antwoorden laten genereren en deze aangepast. Hierbij éérst een LVM volume voor Cinder aangemaakt en daarna packstack het werk laten doen. Provider VLAN netwerken aangemaakt en de virtuele machines zijn uitgerold.

Networking

Binnen de wat kleinere (of klassiekere) server omgevingen kom ik vaak  MKB virtualisatie omgeving kom ik toch vaak tegen dat de VM’s gelijk gekoppeld worden aan een externe datacenter switch middels VLAN’s. Dus zolang een klant nog een hybrid cloud heeft, vxlans (worden trouwens ook ondersteund) of andere zaken, is het configureren van OpenStack met zogenaamde “Provider VLAN” networking een verstandige optie.

Wat je hiermee bereikt is dat de netwerken die binnen OpenStack aangemaakt worden rechtstreeks gekoppeld worden aan VLAN’s in je netwerk. Ik heb de volgende configuratie aanpassingen gedaan op een schone OpenStack installatie om dit werkend te maken (op CentOS)

in /etc/neutron/plugins/ml2_conf.ini
onder [ml2_type_vlan]:
network_vlan_ranges = default:1:1399

Ik gebruik hier bewust default, omdat Horizon dit standaard invult als provider network, de twee nummers erachter bepaalt de vlanreeks die je kan gebruiken
onder [ml2]

type_drivers = local,vlan,vxlan
tenant_network_types = local,vlan,vlan

In /etc/neutron/l3_agent.ini
Pas networking_bridge aan naar het volgende:
external_network_bridge =
Deze optie is weliswaar deprecated, maar ik vermoed dat hij me wel voor problemen heeft gezorgd.
in /etc/neutron/plugins/openvswitch_agent.ini
Pas de tekst bridge_mappings aan naar het volgende:
bridge_mappings = default:br-ex

Hiermee vertel je Neutron dat het ProviderNetwork “default” op de networking node (dus daar waar de instances draaien)  gekoppeld moet worden aan de OVS bridge br-ex
En die bridge wordt via packstack standaard aangemaakt, dus hoef je alleen nog maar te doen:

ovs-vsctl add-port br-ex <ethernetname>

Deze bovenste regel maak je consistent door in CentOS de volgende files aan in /etc/sysconfig/network-scripts:

Filename ifcfg-br-ex:

DEVICE=br-ex
TYPE=OVSBridge
DEVICETYPE=ovs
ONBOOT=yes
NM_CONTROLLED=no
BOOTPROTO=none

Filename ifcfg-eno2: (eno2 is de naam van de fysieke ethernet interface)

TYPE=OVSPort
DEVICETYPE=ovs
OVS_BRIDGE=br-ex
ONBOT=yes
NAME=eno2
UUID=04274555-340a-4ce7-8066-8e69a7f1d7af
DEVICE=eno2
BOOTPROTO=none

Op deze manier kan je heel eenvoudig een network in OpenStack aanmaken voor een project met een specifiek vlan (bijv 204):

En koppel hier vervolgens het juiste subnet aan.

Compute

Nova is het compute gedeelte van OpenStack. Hou er rekening mee dat als je een instance aanmaakt, Nova via een scheduler kijkt op welke compute de instance past en dat vervolgens een kopie wordt gemaakt van de instance (volume of de ephemeral volume) naar de lokale schijf. Dit kan aangepast worden voor volumes. Snapshots worden ook eerst lokaal (/var/lib/nova/instances/snapshots) opgeslagen voordat ze naar Cinder worden verplaatst. Hier moet je rekening mee houden met de installatie van het hypervisor-OS (dus of een apart volume voor /var/lib maken of /home minder geven en / meer):

Storage

Ik heb ook Ceph geprobeerd als backend voor de opslag, Ceph is een open source, gedistribueerde, block storage oplossing, waarbij je de mogelijkheid hebt om de data op verschillende disken via het netwerk automatisch op te slaan. Ceph voor één disk werkt wel, maar je mist wel de kracht van Ceph. Ik denk ook dat mijn beperkte hardware zorgde voor wat performance uitdagingen. Uiteindelijk ben ik bij LVM gebleven; in een grotere omgeving is er vaak al shared storage aanwezig.

Voor nieuwere omgevingen die hyperconverged zijn is Ceph natuurlijk wel een uitkomst..

Eindsituatie

Na wat uitzoeken, proberen, en herinstallaties, ben ik uiteindelijk uitgekomen op de volgende configuratie van OpenStack, zowel in netwerk perspectief als logisch gezien binnen in de HP microserver zelf.

Dit is een All-in-one OpenStack deployment, waarbij ik de twee 4TB disken los heb getrokken. De eerste 4TB is de CentOS installatie waar OpenStack op is geïnstalleerd en geconfigureerd. De tweede 4TB disk heb ik volledig ingericht voor Cinder, zodat ik 4TB aan opslag heb voor volumes en instances. Ceph heb ik losgelaten en gebruik “gewoon” LVM local disk. Dat voldoet eigenlijk prima. Ik ben nog aan het zoeken hoe ik ook Nova kan laten wijzen naar Cinder voor de volumes, dat is me eerder al gelukt. Beide Gigabit Ethernet interfaces zijn verbonden aan het netwerk mét jumbo frames. De tweede ethernet interface wordt dedicated gebruikt voor de vlan netwerken en de eerste ethernet interface alleen voor management van de omgeving.

Binnen de omgeving heb ik nu één project waarbinnen ik, op basis van volumes, de drie VM’s nu heb draaien.

Conclusie

De omgeving draait nu een dag zoals ik hem wil hebben, maar wel met een weekje ervaringen en troubleshooten van OpenStack. Ondanks dat ik live migration en shared storage niet heb getest (lastig met één node) en de Nexus1000V niet heb kunnen testen, ben ik van mening dat OpenStack Neutron met de bovengenoemde pointers zeker een goede oplossing kan zijn voor datacenters met kleine servers. Ik ben wel benieuwd hoe Windows onder KVM fungeert, maar ook daar verwacht ik eigenlijk niet zoveel problemen.

Het dashboard, via Horizon, werkt goed voor alle dagelijke gangbare taken, maar dan moet OpenStack wel goed ingericht zijn. Ik ben nog er niet achter gekomen hoe ik de specifieke foutmelding terug kan halen in Horizon als bijvoorbeeld een instance niet aangemaakt kan worden. Ik val dan toch snel terug naar de CLI, maar dat is dan ook denk ik de ervaring die meespeelt. Ik gebruik ook de CLI wat eerder voor het importeren van images en het aanmaken van de vaste ip-adressen omdat ik dat ook makkelijker vind.

Dus als je je er voldoende in verdiept, bereid bent om heel veel informatie tot je te nemen, is OpenStack zeker een mooie oplossing. Het is zeker niet voor de “faint-hearted”, maar als je mensen met kennis (zowel linux, networking als openstack) om je heen kan verzamelen, dan kan OpenStack zeker een alternatief zijn op Hyper-V en VMWare voor een commercieel bedrijf met eigen datacenter.

Tips & Tricks

Als laatste nog wat kleine tips & tricks die mij veel geholpen hebben met OpenStack

Packstack

PackStack is echt makkelijk om te gebruiken. Laat eerst PackStack een answer-file genereren en pas die daarna aan. Gebruik de quickstart op rdoproject.org voor CentoS en vergeet niet om de standaard mariadb-libs te verwijderen (yum erase mariadb-libs) , die is niet compatible met packstack. Begin met de PoC en wees bereid om het daarna opnieuw te doen voor de definitieve uitrol. Gebruik daarvoor een answer-file die je aanpast naar de specifieke inrichting die jij wilt hebben. Als je zorgt dat alle OpenStack hosts een goede basis Linux OS hebben, zal packstack ook OpenStack kunnen uitrollen op de andere nodes.

Cinder

Als je cinder met LVM wilt gebruiken, maak dan een LVM aan met de naam “cinder-volumes” voordat je packstack gaat laten installeren (en pas in de answer file aan dat packstack een cinder-volume wilt aanmaken). Anders gaat packstack voor jou een loopback device aanmaken met 20Gb aan opslag voor Cinder. En dat is niet veel voor productie.

Provider VLAN networking

Maak ook een vlan networking omgeving aan als je niet alles genat wilt hebben, die kost wel wat energie in inlezen van Neutron en configuratie (naamgeving), maar maakt het leven daarna eenvoudiger. En vergeet niet om altijd een subnet aan te maken bij het VLAN, enable DHCP als je ook floating-ip’s (dus dynamische toewijzing) wilt gebruiken.

Vaste IP-adressen

Voor sommige services wil (of moet) je gewoon  een vast ip-adres en mac addres hebben. Dit kan je het beste doen op de CLI, voor het specifieke project. Voer daarvoor de volgende stappen uit

1. Login op de controller
2. Configureer keystone dat je als admin kan inloggen via het commando source keystone_admin
3. Vraag nu de lijst op van de netwerken via het commando neutron net-list
4. Vraag nu de lijst op van de subnets die beschikbaar zijn via het commando neutron subnet-list
5. Maak nu een vast ip-adres aan met het volgende commandoneutron port-create --fixed-ip subnet_id=<id-van-subnet-uit-stap4>,ip_address=<ipadres> --name <hostname-netname> --mac-address <mac-adres> <id-van-netwerk-waar-subnet-binnen-valt>

Hiermee maak je een port met een vast ip-adres (mac-address is optioneel). Die koppel je vervolgens aan een instance in plaats van het netwerk en die instance heeft vervolgens standaard dat ip-adres. Kan je dan als DHCP of handmatig instellen binnen de VM.

Volumes

Als je geen gestandaardiseerde deployments hebt, maak dan gebruik van volumes. gebruik in de migratie het commando qemu-img convert <srcfile> <dstfile> om een vmdk file (moet flat zijn) om te zetten naar het qcow2 format. Importeer vervolgens de disk via het volgende commando (progress zorgt ervoor dat je weet hoever glance is)

glance image-create --name "img-vm-name" --file <filename> ---disk-format qcow2 --container-format bare --progress

Vervolgens kan je in Horizon op basis van deze image een volume creéren die je aan de instance koppelt. Daarna kan je het image weggooien.

Troubleshooting

Wees niet bang om te troubleshooten en veel te lezen. De logging van OpenStack is uitgebreid, lang en gebruik de id’s (uuid’s) uit Horizon om via grep te achterhalen wat er is gebeurd. De logging is gestructureerd in de structuur /var/log/<module>/<servicenaam.log>

Dus bijvoorbeeld een instance troubleshooten heb ik het volgende commando gebruikt
egrep <uuid-van-instance> /var/log/nova/*
en daarna
egrep <uuid-van-instance> /var/log/nova/nova-compute.log
om te zien waar het mis is gegaan en waarom.

Service herstarten

Voor veel zaken moet je specifieke services van OpenStack herstarten, ik gebruik daar het volgende commando iedere keer voor:
service restart openstack-<modulenaam>-<servicenaam>
Voordeel is dat service autocomplete kent via tab, dus dat is makkelijker zoeken

Handige commando’s

De volgende CLI entries heb ik zelf veelvulidg gebruikt om dingen na te gaan:

cinder get-pools (--detail)	om de volume pool op te vragen en de status
glance image-list	voor lijst van networks
glance image-create	om een image te importeren
neutron net-list	voor lijst van netwerken
neutron subnet-list	voor lijst van subnets
neutron port-create --fixed-ip	om een vast ip-adres aan te maken
openstack project list	Lijst van projecten binnen OpenStack
openstack volume list	Overzicht van alle volumes
openstack volume create --size vol1	Om een vol1 aan te maken van 1Gb
openstack volume delete <volname>	Om een volume te verwijderen