Archive | August 2015

VMworld 2015 San Francisco Keynote dag 1

vmw2015-0

VMworld 2015 eerste ronde, READY FOR ANY!

Na de allerlaatste PEX in San Francisco afgelopen februari is het nu tijd voor het virtualisatie event van het jaar: VMworld. Net als vorig jaar wordt VMwordl gehouden in het Moscone Center in San Francisco. Ik ben heel benieuwd wat er dit keer bekend wordt gemaakt. Vorig jaar moest ik mijn trip een week van te voren afzeggen, dit jaar ben ik er in verband met de geboorte van mijn zoon niet bij.

Omdat de slides die getoond werden erg krachtig en duidelijk zijn vertellen eigenlijk zelf hun verhaal…

De keynote begon met een intro film over applicaties in de cloud.

vmw2015-1

Na deze opening betrad Carl Eschenbach het toneel, vergezld door een stel dansende cloud native applicaties, die hij wegjoeg om zijn verhaal te starten.

vmw2015-2

Dit jaar kent een record aantal deelbnemers, meer dan 23.000 uit 88 landen en meer dan 50.000 online volgers van de keynote.
vmw2015-3

Het gaat allemaal om de volgende uitdagingen:

vmw2015-4

vmw2015-5

vmw2015-6

Ben jij klaar voor “any”?

vmw2015-7

vmw2015-9

vmw2015-10

vmw2015-11

vmw2015-14

Na Carl (jawel, in jeans) nam Bill Fathers het stokje over (ook in jeans).

vmw2015-15

Bill vertelde over de noodzaak van het kunnen schalen van applicaties en VMware’s mogeijkheden om applicaties in de cloud te verbinden met applicaties die in het eigen datacenter draaien, waardoor zogenaamde hybride applicaties ontstaan.

vmw2015-16

vmw2015-17

vmw2015-18

vmw2015-19

Raghu Raghuram nam het over en werd vergezeld doorYanbing Li. Zij kondigden EVO: SDDC aan

vmw2015-20

vmw2015-21

En wat kan EVO: SDDC?

vmw2015-22

vmw2015-23

vmw2015-24

en zo maakt het dus de unified hybrid cloud mogelijk…

vmw2015-25

vmw2015-26

Na EVO:SDDC toonde Yanbin Li de tech preview Cross-cloud vMotion:

vmw2015-27

En dat was echt cool. Ik herinner me de eerste keer dat ik vMotion zag en de eerste demo van wat we nu kennen als Fault Tolerance, en dit had een zelfde impact. Helaas is het nog maar een tech preview…

vmw2015-28

Ten slotte gaven Ray O’Farrell de nieuwe CTO en hoofd van R&D en Kit Colbert hun presentatie over containers

vmw2015-29

Ze vertelden over de tweeledige aanpak door VMware van containers: vSphere integrated containers en Photon voor Cloud Native Apps.

vmw2015-30

vmw2015-31

vmw2015-32

vmw2015-33

Na jeOS (just enough OS) hebben we nu jeVM (just enough virtualisation).

vmw2015-34

vmw2015-35

Ray en Kit kondigden een neiwu platform voor Cloud Native Apps aan, Photon.

vmw2015-36

vmw2015-37

vmw2015-38

Photon zal op de volgende wijzen beschikbaar komen:

vmw2015-39

De twee oplossingen naast elkaar:

vmw2015-40

vmw2015-41

 

 

VMworld 2015 San Francisco Keynote day 1

vmw2015-0

VMworld 2015 first round, READY FOR ANY!

After the last PEX in San Francisco in February, it is now time for VMworld. Like last year, VMworld takes place at Moscone Center in San Francisco, California. I am very curious to see what will be announced this year. Last year my trip got cancelled a week before VMworld, this year I will not take part because of a wonderful reason, the birth of my son.

 

As the slides shown are really powerful, they kind of tell their own story…

The keynote opened with a nice movie about applications in the cloud.

vmw2015-1

After the intro movie, Carl Eschenbach took the stage, joined by some dancing cloud native apps which he chased away to start his key note.

vmw2015-2

This year has a record breaking amount of attendees, over 23000 on premises form 88 countries and another 50000 online watching the keynote.
vmw2015-3

It is all about these challenges:

vmw2015-4

vmw2015-5

vmw2015-6

Are you ready for “any”?

vmw2015-7

vmw2015-9

vmw2015-10

vmw2015-11

vmw2015-14

After Carl (yes, in jeans) Bill Fathers took the stage (in jeans too).

vmw2015-15

Bill talked about the need for application scaling and VMware’s ability to connect on premises applications with cloud based applications, creating so-called hybrid applications.

vmw2015-16

vmw2015-17

vmw2015-18

vmw2015-19

Raghu Raghuram took over and was joined by Yanbing Li. They announced EVO: SDDC

vmw2015-20

vmw2015-21

So, what does EVO: SDDC?

vmw2015-22

vmw2015-23

vmw2015-24

and so it enables the unified hybrid cloud…

vmw2015-25

vmw2015-26

After this announcement she then presented the tech preview Cross-cloud vMotion:

vmw2015-27

And that was quite cool. I remember the first vMotion demo and the first demo of Fault Tolerance and this kind of had the same impact… unfortunately it is still in tech preview…

vmw2015-28

Finally the new CTO and VP of R&D Ray O’ Farrell delivered his presentation supported by Kit Colbert

vmw2015-29

They talked about the two pronged approach to containers: vSphere integrated containers and Photon for Cloud Native Apps.

vmw2015-30

vmw2015-31

vmw2015-32

vmw2015-33

After jeOS (just enough OS) we now have jeVM (just enough virtualisation).

vmw2015-34

vmw2015-35

Ray and Kit then announced a new platform, Photon.

vmw2015-36

vmw2015-37

vmw2015-38

Photon will become available in these ways:

vmw2015-39

The two approaches side by side:

vmw2015-40

vmw2015-41

 

 

Ontwerpmogelijkheden met vCloud Director vApps

door Eric Groot en Eelco de Boer

Als gebruik gemaakt wordt van een op VMware vCloud-Director gebaseerde IaaS omgeving, dan is het gebruik van vApps verplicht. Daarom is het belangrijk om het fenomeen vApps onderdeel te laten zijn van een virtueel datacenter ontwerp, temeer omdat er naast voordelen ook beperkingen bestaan, waar rekening mee moet worden gehouden.

Voordelen

vCloud Director vApp is een service container waar virtuele machines en netwerken in geplaatst kunnen worden. Een vApp gedraagt zich als een virtuele machine en ze zijn onder meer handig voor testomgevingen. Je kunt bijvoorbeeld een template van een vApp maken en uitrollen, inclusief de servers die erin staan. Je kunt ze klonen, verplaatsen en isoleren. Ook kan binnen een vApp de opstartvolgorde van machines worden bepaald en tenslotte kunnen vApps gemigreerd worden over datacenters m.b.v. vCloud Connector/ vCloud API.

Beperkingen

Er zijn ook beperkingen ten aanzien van het gebruik van vApps. Beperkingen waarmee vooral in productieomgevingen rekening moet worden gehouden.

De belangrijkste beperkingen zijn:

  • Er passen maximaal 128 objecten (VM’s en /of vApps) in een vApp. Voor een omgeving met meer virtuele machines kan dus niet met 1 grote vApp worden volstaan, je moet er wel meerdere gebruiken. Dus moet over een zinvolle indeling worden nagedacht.
  • Als een aan een vApp gekoppeld netwerk verwijderd moet worden, dan moet de gehele vApp, inclusief alle servers die daarin zitten, worden afgesloten. Voor ontwikkel- en testomgevingen geen groot probleem, maar onacceptabel voor productieomgevingen. De netwerkconfiguratie moet dus goed ontworpen en stabiel zijn.
  • Als een virtuele server verplaatst wordt van de ene naar de andere vApp, dan moet deze server worden afgesloten.
  • Bij een migratie van een vApp over datacenters worden de netwerken niet mee-gemigreerd en moeten dus opnieuw worden gebouwd en/of gekoppeld
  • Er kan niet met Site Recovery Manager worden gewerkt omdat vCloud Director hiermee nog niet compatibel is
  • Als een machine of appliance van vApp moet worden gemigreerd, dan krijgt deze standaard een nieuw MAC adres, wat een probleem is als licenties aan MAC adressen zijn gekoppeld. Overigens kunnen MAC adressen wel statisch worden gemaakt.
  • Zonder vCloud Connector moeten te verplaatsen vApps worden geëxporteerd en geïmporteerd.

Gebruiksdoelen

Richtinggevend voor het ontwerp en inrichting van vApps zijn de gebruiksdoelen daarvan. Waarom een vApp wordt ingezet is bepalend voor zijn inrichting en voor de groepering van diensten. Er kunnen meerdere vApps om verschillende redenen worden opgezet. De belangrijkste gebruiksdoelen van vApps zijn:

  • Verplaatsbaarheid van een applicatieomgeving. Het doel is de gehele vApp te kunnen verplaatsen naar een ander virtueel datacenter
  • Het regelen van portal toegang en permissies t.b.v. beheerwerkzaamheden aan de vApp
  • Het toepassen van managementpolicies op een vApp-omgeving, zoals security-, monitoring-, configuratie-, datamanagement- en disaster recovery policies
  • Het klonen van vApps van en naar ontwikkel, test, acceptatie en productie omgevingen

Netwerken

Voor dit artikel gebruiken we een netwerkindeling waarbij de toegang tot diensten vanuit het internet via zones verloopt. Het is een klassieke netwerkzonering, waarbij de netwerken als vCloud “organizational  networks” geïmplementeerd zijn.

 vApps1

Direct, Routed en Fenced netwerken.

Een vApp is verbonden aan de organizational netwerken in een VDC. Als dit een directe verbinding is, dan wordt het organizational netwerk doorgetrokken in de vApp.

Bij een routed verbinding zijn de subnets binnen de vApp anders dan de organizational subnets. Een Edge device wordt geïnstalleerd indien voor deze optie wordt gekozen, zodat deze voor de routering kan zorgen.

Bij een fenced vApp wordt ook een Edge device uitgerold en wordt al het verkeer van en naar de vAPP ge-NAT. Verder wijzigen de MAC adressen naar statisch, waardoor deze niet meer zo maar door vCloud Director gewijzigd kunnen worden.

Gebruiksdoel: verplaatsbaarheid

De verplaatsbaarheid van vApps kent serieuze beperkingen. De vShield edge of NSX device die de vApp koppelt aan een organizational network is gebonden aan een vCenter server. Daardoor kan de vApp niet in zijn geheel verplaatst worden naar een VDC in een ander datacenter, omdat deze door een andere vCenter server gemanaged wordt. De vApp netwerken en het edge device moeten bij een migratie (in feite geen migratie maar een export en import) opnieuw opgezet worden.

Bij een routed of fenced koppeling kan in de vApp een loadbalancer, een reverse proxy server of firewall worden ondergebracht, zodat een completer applicatie-ecosysteem kan worden gekloond of gemigreerd.

vApps2Voor de verplaatsbaarheid kunnen ook 3rd party oplossingen worden gekozen die niet afhankelijk zijn van vCenter. Echter, niet alle 3rd party oplossingen integreren met vCloud Director en dus met vApps. Een zorgvuldige keuze is dus geboden, als verplaatsbaarheid belangrijk is.

Het nadeel van het onderbrengen van loadbalancing, proxy en firewall functies binnen een vApp is de toegenomen kosten en beheerlast, doordat meerdere exemplaren van eenzelfde dienst moet worden onderhouden.

Standaardisatie en automatisering van uitrol en configuraties kan dan uitkomst bieden.

Gebruiksdoel: toegang t.b.v. beheerwerkzaamheden

In de vCloud portal kan beheertoegang worden geregeld tot vApps. De standaard rollen die via de vCloud Director portal kunnen worden uitgedeeld (zie VMware artikel) bieden voor productieomgevingen niet altijd de goede set aan permissies. Zo kan een standaard vApp-user de vApp (met alles daarin) verwijderen. Het creëren van custom-roles is dan een optie. Het is verstandig deze custom roles zorgvuldig vast te stellen en te beschrijven, want het zijn system-wide roles, m.a.w. alle tenants kunnen gebruik maken van deze rollen.

Het regelen van toegang voor beheerwerkzaamheden geldt alleen voor de vCloud Director portal, en niet voor de console toegang op de virtuele machines zelf. De beheer-rollen en permissies moeten dus nog steeds ook op machine/domain niveau geregeld worden.

Het meest voor de hand ligt de vApps ten behoeve van beheer vast te stellen op basis van applicaties en gespecialiseerd beheer.

In de afbeelding staan voorbeelden van vApps die ingericht kunnen zijn ten behoeve van beheertoegang.

  • De 2-3 tier applicatie vApp, met een dedicated database geeft een leverancier alle mogelijkheden voor beheer en configuratie, eventueel inclusief specifieke tooling.
  • Een vApp voor een business applicatie die gebruik maakt van een voordeliger shared (hosted) database-service volstaat in veel gevallen voor leverancier en beheerders. Zij kunnen nog steeds databases updaten (via de applicatie-server, en beheer- of service accounts), echter de databaseserver zelf valt buiten scope van beheer.
  • Een vApp voor database hosting, waar alleen gespecialiseerde database-beheerders toegang toe krijgen. Hetzelfde kan gedaan worden met Identity en Access Management oplossingen, met monitoring diensten, met orchestratie tooling, met access services (zoals reverse proxy, load-balancers, direct access en VPN solutions), et cetera.

vApps3

 Gebruiksdoel: het toepassen van managementpolicies 

Management-tooling kan ingericht worden om gebruik te maken van de vCloud API of andere, zoals de storage- of de VIX API, om zodoende vApps te beheren. De meest gebruikte management-tooling die gericht wordt op vApps is back-up, restore en disaster recovery software. Meerdere leveranciers van backup en restore of disaster recovery producten, w.o. IBM Tivoli, NetApp, Zerto, Commvault, et cetera, haken in op vApps.  Bij het maken van een backup wordt de vApp in maintenance mode gezet en wordt in de backup ook de vApp metadata bewaard. Restores kunnen voor de gehele vApp plaatsvinden of van een individuele machine. De meerwaarde van deze werkwijze is gelegen in het feit dat men virtuele machines kan groeperen met het oog op een back-up methode of een SLA.

Opstartvolgorde

Voor (disaster) recovery doeleinden kan een opstartvolgorde (en ook een shutdown volgorde) van machines binnen een vApp worden bepaald. Dit is zondermeer een nuttige toepassing van vApps. Meestal wil men eerst een ldap server starten, daarna de databaseservers, dan de applicatieservers en ten slotte de presentatieservers. Het probleem is wel dat deze servers zich in verschillende vApps kunnen bevinden en zonder third party back-up en restore software is er geen manier om de opstartvolgorde tussen vApps te kunnen bepalen. Ook Site Recovery Manager wordt niet ondersteund door vCloud Director. In principe kan men vApps nesten, en dat zou een oplossing kunnen bieden, maar andere gebruiksdoelen van vApps kunnen dan komen te vervallen. Daarnaast is de impact van een falende/corrupte/verwijderde parent-vApp potentieel groot.

 Operations/configuration en orchestratie

Alle handelingen die men vanuit de user interface kan uitvoeren met een virtuele machine of een vApp, kan door operations-, configuration- en orchestratiemanagement tooling worden uitgevoerd.

Er kan programmatisch vApps uit een template worden geïnstantieerd of een vApp vanuit bestaande virtuele machines worden gecreëerd. Een vApp kan in maintenance mode worden geplaatst, en er kunnen machines in vApps worden uitgerold, gestopt, gestart, een snapshot worden gemaakt, verwijderd of teruggezet, en netwerk- en harddisk settings voor virtuele machines worden aangepast, et cetera.

In productieomgevingen zullen de meeste operations-, configuratie en orchestratie werkzaamheden niet op vApps maar op individuele machines met bepaalde kenmerken worden gericht.

Gebruiksdoel: klonen van vApps naar ontwikkel, test en acceptatieomgevingen

vApps zijn geschikt om een template van samen te stellen die vervolgens kan worden uitgerold ten behoeve van ontwikkel-, test en acceptatieomgevingen. Dit kan de configuratie en onderhoud van volledige ontwikkel-, test- en acceptatieomgevingen overbodig maken en een DevOps werkstijl mogelijk maken. Door van de productieomgeving templates te maken van bestaande vApps, en deze vervolgens uit te rollen op zo’n manier dat ze afgeschermd zijn van de productieomgeving kan “on the fly” een representatieve testomgeving worden gecreëerd. Eventueel kan een vApp uitgerold worden in andere, netwerk-technisch gescheiden VDC. Na test en acceptatie van de doorgevoerde changes kan opnieuw een template gecreëerd worden die terug uitgerold wordt naar productie.

vApps4

Conclusies

Omdat het gebruik van vApps in een vCloud Director omgeving verplicht is, moet men rekening houden met de mogelijkheden en beperkingen van vApps. Men moet men een duidelijk idee hebben waarvoor men ze gaat inzetten, maar ook of deze doelen (of combinatie van doelen) wel haalbaar zijn. Zorgvuldig vooronderzoek is noodzakelijk om te komen tot een vApp ontwerp dat gaat werken voor alle partijen. Het ontwerp en inrichting moet in 1 keer goed zijn, want wijzigingen kunnen grote impact hebben.

Design options with vCloud Director vApps

by Eric Groot and Eelco de Boer

When consuming IaaS based on VMware vCloud director, the use of vApps is mandatory. Therefore it is important to make the phenomenon vApp a key component of the virtual data center design, more so because next to advantages, there are disadvantages as well that should be taken into account.

Benefits

A vCloud Director vApp is a service container that might contain virtual machines and networks. A vApp behaves similar to a virtual machine and vApps are, for example, convenient for test environments. It is easy to create a template from a vApp and deploy a vApp from a template, including the servers contained within that vApp. vApps can be cloned, moved and isolated. Start up and shut down order can be set within a vApp and finally vApps can be migrated across data centers using vCloud Connector / vCloud API.

Limitations

vApps also have their limitations. Limitations that should be taken into account in production environments. The most important limitations are:

  • A maximum of 128 objects (VM’s and/or vApps) in a vApp. One big vApp cannot suffice in environments with more virtual machines, more have to be used. Therefore a meaningful mapping must be considered.
  • If a network attached to a vApp has to be removed, the entire vApp, including all servers contained, must be shut down. In test or development environments this may not be a big issue, but it’s unacceptable in production environments. The network configuration has to be well designed and be stable.
  • When a virtual server is moved between vApps, the server must be shut down
  • When migrating a vApp across data centers, networks will not be migrated and will have to be rebuild or (re)connected.
  • Site Recovery Manager cannot be implemented because vCloud Director is not yet compatible
  • When a machine or appliance needs to be migrated between vApps, by default vCloud director will generate a new MAC address. This is a problem when using MAC based licensing. However MAC addresses can be made static.
  • Without vCloud Connector, vApps that are to be moved must be exported and imported

Use cases

First consideration for the design and construction of vApps is their uses. Why a vApp is implemented determines its construction and the grouping of services. Several vApps can be implemented for different reasons. The most important use cases for vApps are:

  • Portability of an application environment. The goal is to be able to move the entire vApp to another virtual data center.
  • Arranging portal access and permissions for the benefit of management and administration of the vApp
  • Implementing management policies on a vApp-environment, like security, monitoring, configuration, data management and disaster recovery policies.
  • Cloning vApps from and to development, test, acceptance and production environments

Networks

For this article we use a network layout that allows access to services from the internet via zones. It’s a classic network zoning and networks have been implemented as vCloud “organizational networks” .

vApps1

Direct, Fenced and Routed networks.

A vApp is attached to the organizational networks in a VDC. If this is a Direct connection, the organizational network will be extended in the vApp.

In a Routed connection the subnets within the vApp are different to the organizational subnets. An Edge device is installed, if this option is chosen, so that it can provide the routing function.

In a Fenced vApp an Edge device is also deployed and all traffic to and from the vApp is NAT-ed. Furthermore, the MAC addresses are modified to static, making it no longer possible for them to be changed by vCloud Director.

Use case: portability

The portability of vApps has serious limitations. The vShield edge or NSX device that links the vApp to an organizational network is bound to a vCenter server. As a result, the vApp cannot be moved in its entirety to a VDC in another data center, because it is managed by another vCenter server. The vApp networks and edge device must present a migration (in fact not a migration but an export and import) and be set up again.

In a routed or fenced coupling, a load balancer, reverse proxy server or firewall can be implemented in the vApp, so that a more complete application ecosystem can be cloned or migrated.

3rd party solutions may also be chosen that are not dependent on vCenter. However, not all 3rd party solutions integrate with vCloud Director and thus with vApps. Careful consideration is required, if portability is important.

The disadvantage of the incorporation of load balancing, proxy and firewall functions within a vApp is the increased cost and management burden by creating multiple copies of the same service that have to be maintained.

Standardization and automation of deployment and configuration can provide a solution.

vApps2

Use case: management and administration

In the vCloud portal, management access can be controlled to vApps. The standard roles that can be distributed via the portal vCloud Director (see VMware article) do not always provide the correct set of permissions for production environments. A standard vApp-user may remove the vApp (and everything in it). Therefore, the creation of custom-roles is an option. It is wise to adopt these custom roles carefully and describe because they are system-wide roles, i.e. all tenants can use these roles.

Access control for management activities applies only to the vCloud Director portal, and not for the console access to virtual machines themselves. The management roles and permissions still need to be controlled at machine / domain level.

The most obvious solution is to fix the vApps based upon applications and specialized management.

The illustration shows examples of vApps that can be arranged for management access.

  • The 2-3 tier application vApp, with a dedicated database gives a supplier possibilities for management and configuration, possibly including specific tooling.
  • A vApp for a business application that uses a cheaper shared (hosted) database service is sufficient in many cases for supplier and administrators. They can still update databases (via the application server, and management of service accounts), but the database server itself is out of the scope of management.
  • A vApp for database hosting, that only specialized database administrators can access. The same can be done with Identity and Access Management solutions, monitoring services, orchestration tooling, with access services (such as reverse proxy, load balancers, direct access and VPN solutions), et cetera.

vApps3

Use case: application of management policies

Management-tooling can be arranged to make use of the vCloud API, or others, such as the storage- or the VIX API, to manage  vApps. The most common management tooling on vApps is focused on backup, restore and disaster recovery software. Several vendors of backup and restore or disaster recovery products, e.g. IBM Tivoli, NetApp, Zerto, CommVault, et cetera, attach to vApps. When creating a backup, the vApp is placed in maintenance mode and the vApp metadata is also stored in the backup. Restores can be made for the entire vApp or an individual machine. The added value of this method lies in the fact that one can group virtual machines with a view to a back-up method or a SLA.

Boot Sequence

For (disaster) recovery purposes, a boot sequence (and a shutdown order) machines are determined within a vApp. This is undoubtedly a useful application of vApps. Usually one first wants to start an ldap server, then the database server, the application servers, and finally the presentation servers. The problem is that these servers may be located in different vApps and without third-party backup and restore software, there is no way to determine the boot sequence between vApps. Also, Site Recovery Manager is not supported by vCloud Director. In principle, one can nest vApps, which could offer a solution, but other uses of vApps are then cancelled out. In addition, the impact of a failed / corrupted / deleted parent vApp can be potentially large.

Operations / configuration and orchestration

All operations that can be performed from the user interface to a virtual machine or a vApp, can be carried out by operation-, configuration- and orchestration-management tooling. vApps can be programmatically instantiated from a vApp template or created from existing virtual machines. A vApp can be placed in maintenance mode, and machines in vApps can be rolled-out, stopped, started, snapshotted, removed or put back, and network and disk settings for virtual machines can be adapted, et cetera. In production environments most operations, configuration and orchestration activities will not be aimed at vApps but at individual machines with certain characteristics.

Use case: cloning vApps to development, test and acceptance environments

vApps are suitable to create a template which can then be rolled out for the purpose of development, testing and acceptance environments. This can make the configuration and maintenance of complete development, testing and acceptance environments superfluous and facilitate a DevOps workflow. By making templates of the production environment of existing vApps, and then rolling them out in such a way that they are shielded from the production environment, it is possible to create a representative test environment “on the fly”. Alternatively a vApp can be deployed in another, network-technically separated VDC. After testing and acceptance of the implemented changes, another template can be created that can be rolled back into production.

vApps4

Conclusions

Because the use of vApps in a vCloud Director environment is mandatory, one must take into account the possibilities and limitations of vApps. One must have a clear idea what they are to be used for, but also whether these goals (or combination of goals) are feasible. Careful research is needed to achieve a vApp design that will work for all parties. The design and layout should work first time, because changes can have a big impact.

Quick update

Quick update just to let you know that Eric Groot has asked me to participate on his new blogpost, which I’ll share on my blog as well. Besides that I’ll be posting all new posts in Dutch as well as English from my next blog on.engdu

%d bloggers like this: