Feature Friday Episode 67 - vRealize Automation Adaptor for VCD

Video Statistics and Information

Video
Captions Word Cloud
Reddit Comments
Captions
welcome to another feature fridays my name is guy bartram director of product marketing in our cloud infrastructure business group and today again i'm joined by york york you want to introduce yourself uh sure yeah hey my name is sierra cliff i'm a technical product manager in vmware's cloud services business unit and today we're here to talk about something uh pretty cool actually and it's it's always been something that's been kind of requested by service providers and by tenants um and this is a a vra adapter for vcd right yeah that's correct so with the latest release of viralized automation or the re-rely suite um 8.6 which was released just a few weeks ago with october they added out of the box an endpoint for cloud director in vrealize automation so that means and we will see that later in the demo that you can use your cloud director managed org vdc as an endpoint in new realized automation so i guess this is this is a use case for tenants and for providers so tenants obviously can if they've got vra today you know mostly on-prem they can then now configure their vra to point to a vcd instance whether that's a cloud provider managed instance or something else um but also for a service provider to provide that layer of service management to their operational teams perhaps um into onboarding customers yeah that's possible as well so in re-realize automation well there's a lot of mechanisms there for approval processes for service catalogs that can be useful for a service provider and then they can use that adapter and the integration with vcd to offer either viralize automation as managed services to their tenants or even just use it internally for their own operation team and then use the service catalog in vra for they their own day-to-day operations and what are the kind of um when we're talking about vra driving something into vcd we're talking about vra basically providing a blueprint uh for a vc vm perhaps or a v-app um we're not necessarily going up to the level above that where it'd be like a blueprint for an awk vdc area that's all going to be there and configured and working yeah that's correct so um let's first start with what the current integration does not do so yeah it does not change anything in the multi-tenancy or business group separation capabilities in visualize automation and it does not change anything in the way cloud director carves up the resources into oracle dc's so it's literally uh vra and the blueprints being able to consume cloud director resources to manage deploy and manage virtual machine objects okay so it's using the vcd api to make those calls yeah okay that's correct it's using the uh the public vcd api in tenant context and that's very important for two reasons first of all the fact that it's using the public apis means that as a service provider you don't have to do any special configuration on vcd site it just works out of the box with the organization or tenant access to bcd and then that's a second aspect since it works on a tenant in tenant context in cloud director that allows uh even on-prem vra customers to connect to their org vdc's without the service provider even yeah have to know about it it just acts as a another api client in um cloud director to deploy and manage virtual machines okay and um yeah those are two really good points and what version of vcd is supported with this adapter um it is backwards compatible to 10.2 any tender two or later releases okay that's good for vra you need the latest version 8.6 because it uses some endpoint extensibility apis which are only available in 8.6 and well that's the other big benefits or two big benefits it comes out of the box so even as a vra customer you don't have anything to install special additional to vra it just works out of the box and it comes with the vra advanced license so it's available for pretty much all the vra customers and allows them to connect to their org vdc while when they want to manage other hyperscaler endpoints in a comparable way they would need the enterprise license of vra okay and there has been in the past previous integrations between vr and vcd um most haven't been great because they've been trying to um and correct them if i'm wrong here but they've been trying to create a synchronization between two kind of databases which has caused huge amounts of issues um yeah and it's not sustainable volume at scale this one is different because this one is like you say it's just using that tenant api to kind of push a request or pull information back about some architecture yeah that's correct as well so there is no kind of alignment or synchronization of the tenancy concepts in vra with the tenant concepts in bcd and that is intentionally because we really want to work vra on a single tenant endpoint in uh in cloud director so that a tenant user they can use all the different business groups and the allocations and the entitlements of the services and the blueprints and all these approval processes and the power that vra brings um to the table from a consumer perspective and they can use that to consume the org vdc resources they they get from a vcpp provider now tell me uh yeah that makes absolute sense so in the tenant case a a single tenant uh you know from their premise to a vcd or vdc that makes absolute sense you're limited by the bounds of what you can create within the api within network vdc and the blueprints within vray for the for the plugin for the adapter um if i was a service provider admin and i wanted to deliver you know more than just the stuff within the old vdc modern video vms the apps like firewalls and the other stuff would this be a way i could control the service management around doing that or is that something that's probably better done with terraform or some other kind of capability with vra yeah with that well we do have all these different options and you have the flexibility as a service provider partner to use these different tools vra has a lot of automation and extensibility itself a lot is based on viralize orchestrator obviously but it also has a powerful integration with terraform for the blueprints and now with the acquisition of saltstack a couple of months back there's a lot of functionality when it comes to um configuration management of the deployments through vra and that is something if you want to offer that as a service provider that's likely rather in the area of a managed service where you have a single instance of vra pointing to the org vdc and perhaps to some dedicated private cloud offering for a single tenant and then the tenant can use the vra gear functionality to consume these resources or the services through the service broker and service catalog and vra right all right okay well um should we have a look around it yeah absolutely so let me switch over to the demo environment here and i'm starting here with the view that we hopefully all know in the tenant portal in cloud director just to show you what's there and how the the different components and objects that you have in cloud director then will be used and translated into or mapped to resources in vrealize automation so i am logged in as an organization administrator to cloudtracker where i have three different arc vdcs available and then one org bdc that we are going to use um for the vra integration um you can see that already a bunch of virtual machines running that i deployed just natively through the vcd portal i also have a few networks um or dc networks that are some direct networks some are routed with the nice powerful vct network functionality there's also two edges that are rolled out to connect these rvdc networks to the outside world and i have access to some storage policies that the provider configured for me so that the rbdc can consume or the vms can consume these large resources in the shared cloud offering okay i also have that's important for um later we also have some catalogs available in here and a lot of yeah v-app templates that have been configured either by a subscribed catalog or me as a tenant user in cloud director i can create my own catalog items and catalogs and upload them to the catalog and deploy new stuff from there yeah with that um that's all native out of the works functionality in bcd nothing special to configure here as mentioned now let's switch over to vrealize automation so here i'm logged in as a well cloud administrator or service architect role in vrealize automation and that vra instances for example could be an on-prem instance of vra and let's start the like the consumer experience so i can use the service broker and viralize automation to request new services and in these new services there is now my example one service available for an ubuntu virtual machine and then i can yeah just follow the out-of-the-box vra functionality to um deploy uh new or to yeah do a new request for a new virtual machine machine and based on the blueprint that's behind the service request which we will see in a second then you can define all these different information and input forms that are needed for the request now that deployment starts and that's all native vra functionality based on the blueprint it figures out which network resources to use and then eventually will trigger the deployment of a v-app template into a vm in the orgv dc in cloud directory so we can see the different steps running here and if we switch back to the cloud director tenant portal we should eventually see a new task spinning off to deploy the new virtual machine unless they're in the service broker you didn't have any option for the york vdc to kind of choose that was baked into the blueprint i see yeah that's something um i will i will show in a second because that's where the power of vra comes in that you have a attacking mechanism and you can define policies based on either requirements for the blueprints or based on the user and project or group allocation to which of these endpoints and resources they should be able to use we'll see that in a second um yeah so here we can see that there has been a new task trigger to compose a virtual machine and that virtual machine now reflects like the deployment in service broke it will take a while to uh be deployed and yeah now it's being uh poured on and once this task finishes eventually the deployment will be um successful in in bra yeah for the deployments um that will take a while because in vra the deployment um yes mark depending on the on the blueprint um it needs some yeah power cycle for a virtual machine and then now you can see that the status is powered on and we can have a look at the details of the deployment itself where you can see the topology in this case it's a super simple blueprint so just a single virtual machine connected to a cloud network one of the routed network and yeah from there we can use the vra functionality now to manage that virtual machine so we can see in the general tab there are certain certain information about the virtual machine where it's actually where it landed actually we can see the eventually once the operating guest operating system is booted up with vmware tools we will be able to see the ip address we see the storage that is being used and the network connection for the tool machine and nvra there are also some second day operations available for the whole deployment so that means change leases based on the um these configuration and virtualized automation edit deployments power cycle and so on and for the individual virtual machine there's a bit more you can create snapshots and resize um the virtual machine so add cpu memory or just capacity you can add an independent disk and again yeah power cycle between machines so that that [Music] period of the request that has been granted by default on this machine if you then say i want to decommission the machine after five days or something like that that that action is going to call the club apis do that so those actions have been already built using the uh the valid directory okay yeah that's correct and by the way there is no um alignment um to like the the uh permissions or the lease mechanisms in cloud director yeah that um is all managed now by vra so it's assumed that vray manages the virtual machine you still of course see it in your um or vdc you so you can see these cloud machine one which is based uh the name in the in the blueprint um you can see the virtual machines and they behave and act like regular virtual machines so you can have full access to them through cloud director to access the console to manage see network configurations and details of the virtual machine in vcd but of course they are managed by vra so if you do any i don't know if you delete the virtual machine here or power off the virtual machine it might take some time and then um your a will pick up the new state and of course you might break any relationships in in vray if you i don't know migrate yeah into a different order dc or so that's what i was going to ask you so if i start making changes now in vcd to this this the app then that's basically not good it's not not recommended not recommended yeah things like power cycles or power operations or console access are no big problem that the inventory collection of vra will just pick that up within a few minutes but of course if you yeah change the network connection or delete the virtual machine stuff like that then it will eventually just flag in bra but that's um on the other hand in theory the the tenant may not even have access to vcd in this respect that's correct yeah so if you have in this case you can use the different role-based access control or viralize automation to configure the xs so the nice thing about vra is that well vra is designed that end users like it consumers who do something with this ubuntu vm for example they can use the vra console and you have some very fine-grained permission control here which of these different tasks and second day operations should be accessible for the consumer user and they don't have to care about where that virtual machine actually landed and where it runs that's the idea of we are having bra as an abstraction layer of these different cloud resources yeah and we will see that when we have a look at the the infrastructure the infrastructure where it's set up that you can have or the idea of ura is that you build these blueprints in a cloud-agnostic way so it doesn't matter or it can be provisioned in an on-prem vcenter in perhaps one of the hyperscaler clouds or now with the new adapter in a vct organization but as an end user i don't need to know that yeah so the recommendation here would be kind of perhaps not to match vcdss vra driving vcd in the same customer without access because it it could get uh it could get messy yeah right and i think that isn't that that's fine it's just worth knowing that that's the way it should be yeah absolutely okay um yeah with that let me switch over now service broker is like the service management and consumer application within the viralized automation environment let's now switch over to cloud assembly which is the way or the rule where you define the blueprints and configure the the different endpoints for the deployment tell me your i know vra is also available as a sas solution so do these these components cloud assembly service broker do they work with the uh adapter in the cloud versions as well um the all the components for service broker and cloud assembly are the same in the sas and we realize automation cloud however i think in the current version the vcd endpoint is not yet available in the sas version okay but that's something we are definitely looking into because that makes perfect sense for cloud service endpoints definitely yeah okay yeah here in cloud assembly first of all we have a comparable deployment screen to manage the existing deployments but the more interesting stuff happens in the design and the infrastructure tabs so let's first move over to the infrastructure tab here and see how we can connect vra to cloud director endpoint now that happens in the infrastructure tab down here in the cloud account section with the connections we can see in my demo environment i already set up one connection to cloud director and one to on-prem recenter server and if you add a new cloud account here that's where you define these different endpoints for the hyperscaler clouds you can see aws google azure platform for on-prem vsphere or cloud foundation and of course the an integration with vmc on aws as well in my case we want to use the memory cloud director cloud account and then um that's where you add um yeah the name you give it a like a name to identify the um cloud account i'm not going to do that because i already have set it up just to walk you through the wizard for the url you would just get your cloud director tenant url and for username and password that's your org admin credentials yeah so again important the whole connector works in the tenant aspect tenant space of on cloud director as a service provider you don't need to do any special configuration and then um yeah once you're locked in you can select the um the organization and then uh the org vdc's let me show that in the ones that has already set up the capability tags there come to that in a second very sharp eye and good question jumping ahead okay okay um yeah so here's the one that i set up with the url um the cloud director cc02 is the tenant name or organization name in cloud director and in my case i just selected two oracle dc's for that are available for deployment to provision new resources okay now these capability tags these are generic tags that are available for pretty much all the different objects in vrealize automation and they can be used to influence the decision making in vra where certain blueprints should be deployed or where workloads should be deployed in a more generic way so um typically you use these capabilities for resource providers like a cloud account here or later when we talk about the individual mappings for storage profiles for example you use the tags to identify different classes of endpoints or uniquely identify different endpoints and then in the permission settings for the blueprints and for the projects which is like the tendency aspect in vra to group different things that's where you define um which or where certain blueprints can land i hope this makes sense yes yes absolutely yeah yeah it's it's a way a very powerful because it's a very generic way um that allows very flexible to have different blueprints and different projects to deploy wherever we have free resources i don't care um to which one but then you might have other projects where you um i don't know definitely always want to land these workloads to an on-prem vcenter server because they are not allowed to go to cloud provider for example something like that yeah okay that makes a lot of sense okay um yeah once we set this up the inventory collection will come in so there's a data collection that runs um i think every 10 minutes and then once a day there's some image synchronization and then you can use this cloud endpoint as resources in vra so the image synchronization that's synchronizing the uh app catalog from vcd and it's not not doing anything without launch pad at this point that's correct as well yeah um well technically at launchpad um creates a regular vcd catalog so in the libraries i think i have app launched activated for this year earlier catalog and these catalogs item items they will show up in the image mappings as well but you don't have any access to the different well nice single deployment features single click deployment features of app launchpad because that's part of the app launchpad ui yeah so like the uh the options small medium large the t-shirt size in the networks to connect yeah that's that's different different setup yeah academic sense okay yeah once we set this up um we do have access or we see the different compute resources that are now available my two org vdcs in um in cloud director and that single small on-prem vcenter server that i have connected here as an endpoint we see for the networks the port groups with the on-prem vcenter or any nsx constructs if you connect it to an on-prem nsxv or nsxt manager and we can see the org networks that are available in all these different organizations in cloud director and then in the same way we can see storage policies for example and data stores from on-prem and the storage policies that we have in vcd and with that we can now start to map the different constructs so cloud zones are like destinations for vra deployment and they map to the organization vdcs typically they get automatically created as soon as you connect to a bcd endpoint and then you can have flavor mappings which are the t-shirt sizes so they map to either certain defined cpu and memory sizes in a vcenter case or for cloud director they pick up the sizing profiles um that so the t-shirt size configuration that we have in cloud director with that mechanism okay for image mappings that's where you map a generic image that can be used in a blueprint so in my case you would do for example to the templates so to a template in vsphere for example if vr a sites based on tags or other mechanisms to deploy in vsphere it would pick up the template that's defined here so just uh basic tiny linux templates that um that's available here in the um in the vcd in the vcenter inventory and in um vcd that's where you select the um the app image from the catalog item in cloud director all right and here you could also again define some constraints for example that could be used and for tags based on the project definitions um to influence which region and which image to the deployment mechanism of vra should pick for the actual deployment of a blueprint yeah then we have the network profiles they map to the org networks so you can define and select org networks for the network profiles when you use these network objects in [Music] the blueprint we'll see in a second and again you can define capability tags here for resource providers to influence the placement and we have storage profiles which are just sort of mapping to the storage profiles in from vcd all of these capability tags we're defining here can these be used across tenant so if i wanted to create a a uh or use vra as a tenant interface but i wanted to kind of pull in some existing work i've done from another vra instance or yeah um well they are globally visible in one vra installation so you can use them for different projects is like the grouping mechanism in vra and when with the configuration um you can define for these projects where um they have some yeah which where you define the like the the tax on the consumer side and then vr8 tries to do some uh some matching now tell me just just so it might be a stupid question but um you know previously we had troubles with with or concerns with tenancy with vra to vcd and now i think it's a lot more um specific to the you know the lock down on which orcs you're going to be connecting to does that mean then effectively there's a using the existing vcd multi-tenancy constructs and then putting vra as a you know a shim on top it also allows vra to become a multi-tenanted console yeah it does not follow the complete multi-tenancy so the role-based access control in vra does not fully for example allow you to have role-based access control for individual cloud accounts so that does work or it would work if you use um certain roles like the cloud administrator role in vra who's capable of adding these cloud accounts they see or they would be able to connect to all the different organizations and then you can use the tags again and the project and business groups and vra to um split that up but there's no automatic synchronization so as i mentioned in the beginning vcd does not influence any of the multi-tenancy or business groups constructs in vra and you would have to do as a service provider you really have to make sure um to use proper role-based access control so that your tenants for example do not have access to this cloud account settings otherwise they would be able to like see other tenant endpoints yeah okay let's be done with a few like gotchas and watch out for you know yeah basically giving visibility across all connections okay it's it's likely likely easier or the more common way um to really have like in to follow the scenario that we are showing here within that mimics an on-prem dedicated vra installation for one tenant and then have the tenant full access to the cloud account because that access just gives them access to their tenant in vcd and then they can within the tenant they can use the different business groups and draw based access control um for consuming the resources yeah that makes sense i mean yeah that that's i was just kind of wondering on top of my head whether it could be used especially when you've got these uh capability to do uh the additional kind of metadata tagging and things like that whether it could be used in a multi-ten scenario yeah the thing is that in vra a lot of the the other objects that you use even if you don't have access them to them during deployment they are still visible so when you define tags for example they are globally visible which tags are defined and so on and that's something which in vcd we do not have so in vcd if i'm locked in with my tenant credentials i do not know even the existing existence of any other tenants and would never see any objects of other tenants yeah through api or in the ui and in vra um since it's based on or focused on enterprise customers where you of course have separation and different business groups but it's still possible to see like existing of other business groups because they're in the same enterprise and you know them anyway yeah be interested to see how this works out when uh vra for cloud like the sas solution supports the adapter whether you could have multiple instances for multiple tenants connecting to a single you know cloud director service or cloud director instance um that way i mean that likely um will be possible because then it's different instances of realized automation and they connect to well different tenants in vcd and if that's the same vcd that's likely comparable if you have multiple instances connecting to aws to the same region in aws with different credentials of course yeah okay okay yeah let's go back um to the mappings so we set up the flavor mappings image mappings and so on and now we have all the components that are needed to define the blueprints so i'm switching over to the design section here in viralize automation and that's now where a service architect role in vra would create blueprints either based on some templates or existing blueprints or just start from scratch with a blank blueprint and then you can share that with the different project and also automatically publish it in the service broker if you want then in the blueprint that's where on the left hand side you have the pad with the different objects for the blueprint that map to infrastructure resources and then you can define these and for the vcd adapter the important one are really the cloud agnostic ones so you would use the cloud agnostic virtual machine to drag and drop in there and for example cloud agnostic network which maps to in the infrastructure tab map to an org vdc network and volumes would map to named disks in bcd so if you want to have some like persistent disks um it would be the name disk functionality in bcd that is used for the volume management or maps two volumes here in bra okay so the thing here is to use the cloud agnostic um assets rather than anything else okay exactly so um and that that's the idea because these are cloud agnostic ones they map to with the all the mappings that we've seen in the infrastructure tab they are generic enough to map to all the different endpoints so that cloud agnostic blueprint can be deployed to an on-prem vcenter to either the hyper or one of the hyperscaler endpoints or to cloud director yeah environment and there are some specific ones in there as well for the other hyperscalers so if you look at aws you have a lot of these additional aws instances um and functionality for google you have some for i'm sure you have some but once you use these specific ones then you lose of course the multi-cloud aspect of that blueprint and then you pretty much create a blueprint that is really specific to that one single endpoint okay yeah for the machines you define the important aspects that are needed which is mainly the image and the flavor for the deployment that we've mapped into the in the infrastructure tab and again um see the um we just have here the generic ubuntu name we do not map directly to any objects in vcd that's the point of that abstraction layer of vra and then for these you can also that's where the things come in where you can have um for the properties you can have some additional constraints where you now could use tags for well this virtual machine just um i don't know place it to an uh on-prem environment for example or yeah uh just use certain networks with certain capabilities when you do the drop in will all of those map to through to vcd because i see those things like boot disk sizing and stuff like that with that you would have to have a mapping wouldn't you for that to work from a vcd standpoint like an api to call limit yeah so these these don't um map through to the um objects in vcd because we use and that that's why they are sort of in the additional properties for these properties you might also if you go too much into details you might also like break the cloud agnostic aspect sure yeah of course okay yeah you connect the you can connect virtual machines to networks or define the connection to the networks and in the network you would again yeah currently support existing networks so predefined networks that's an important part by the way where currently the first version of the adapter in vra 8.6 does not do any network automation towards vcd in terms of creating new networks but in the infrastructure tab you use existing networks that are pre-configured in the org vdc with their services and load balancers and edge devices and labors and um functionality so sorry that's fine from a design perspective when you execute though that will then challenge you for which network you want to attach it to um no that's uh based on the in the network mappings vra knows to which network to connect the virtual machine but for example it does not configure any additional services on the edge gateway or it does not create new org networks or v-app networks in vcd that's uh currently not not possible that's something we might look into um the future to both bring a lot of the powerful network self-service capabilities into the blueprints as well but it opens up some yeah questions how far does um in which way does it make sense to really be cloud agnostic yeah once you define the blueprint um then you can um save that and publish it use the version control export it to a yaml file or just deploy it directly from here so from there my job as a service architect would be complete i can add additional machines connect them to the networks and so on and then publish this blueprint into the service broker catalog and then that's where we come back where we started for the end consumer really to use the service broker to deploy the blueprint awesome yeah that's uh that's pretty cool i think there's there's a lot of value in in now having cloud director obviously as a as an end point from the different use case we've discussed and i think there's like you've demonstrated right there's a really good um i think mindset to get into in terms of the multi-cloud and keeping those machines as agnostic as possible um to make sure you can adapt you know to whatever environment you need to run in yeah and again as a service provider um this episode is a very nice to have if you are not interested in offering vra as a service because if you run vcd and offer org vdc's to your tenants you don't have to care about anything vra on-prem at your customer will just use as an additional way to hopefully create a lot of virtual machines and consume a lot of your resources and again if you are interested of course um to get more into vra or yourself then have a look at the the mappings and the role-based access control to really make sure to um yeah use vra in the proper tenancy way that fits your business model yeah yeah yeah i mean this this will for service providers who don't want to use vra this will just kind of make the meter spin faster and generate more consumption but also i think it's a really interesting option for customers who aren't in a region where there's a hyperscaler and need public cloud services and they also want to manage their on-prem as well and they've got an existing it team with vra already there um you know this for them is a nice way of having a public cloud service from your local service provider and tying it all in together to the same it operations that they run today yeah absolutely so all the value add and value proposition of vra of course still is true and even more now because we now also have vcd or vdcs as an endpoint for the vra multi-cloud management capabilities yeah yeah brilliant anything final to finish up on um yeah two more things just links that we um i want to share first um we do have for the vra documentation there is one section about the um the cloud director endpoint in viralize automation that pretty much walks you through the same step that i've done in the demo just make sure to read through that to understand if there are any restrictions in your environment and to configure the proper setup for the different object mappings and we also have one block article that explains again pretty much what i've demonstrated in the last couple of minutes how to um configure the uh the vcd endpoint in vra okay i'll make sure they're both linked in the video but york thank you very much for walking us around the the vra adapter uh it's really cool to see this and it's it's been something's been asked for like i said the beginning right it's been awesome for many years i'm very happy to see it finally released yeah pretty thank you take care okay thanks bye [Music]
Info
Channel: VMware Cloud Provider
Views: 7,482
Rating: undefined out of 5
Keywords: vmware, cloud providers, VMware Cloud Director, Cloud Director, VCD, vRA, vRealize Automation, vRealize Automation for Cloud Director
Id: 27U7q4ishxw
Channel Id: undefined
Length: 42min 30sec (2550 seconds)
Published: Fri Oct 29 2021
Related Videos
Note
Please note that this website is currently a work in progress! Lots of interesting data and statistics to come.