Transcription
Let's go ahead and jump into our discussion on the architecture and topologies. So when we talk about VMware cloud foundation, one of the first concepts that we need to make sure we understand is the concept of a workload domain. So the workload domain is essentially the building block of the private cloud. When you think of a workload domain, think of a pool of capacity that has been carved out for hosting a specific type of workload. And these pools of capacity, these workload domains, they're secure, they're independent, and they're scaled independently uh as well.
So each workload domain is going to have its own venter server. It's going to have its own pool of storage. That storage can be VSAN, it can be NFS, it can be fiber channel. It's going to leverage softwaredefined networking capabilities from vsspere with the vSphere distributed switch as well as uh have at its disposal the capabilities of VMware NSX and the full set of softwaredefined networking capabilities. And we basically bring these together in a standardized and repeatable format that makes it very easy to stand it up using a fully automated approach. And once we stand stand it up, we can then uh monitor it with VCF operations. If we need to scale it up, scale it out, we can again leverage automation to do that. So the workload domain is key and it's very important you have a good understanding of the concept of a workload domain.
And to help underscore that, let's look at an example here where we have a VMware cloud foundation environment deployed in a data center. Now you'll notice that I'm starting with a management domain. The first there's two there's two types of domains in cloud foundation. We call the first one the management domain and the other is a virtual infrastructure workload domain. Those are the two types. uh this the difference between the two and the significance of the management domain is the management domain is where it's a special purpose domain because one it's the first domain that gets created as part of a VCF instance and it's also the domain where we're going to by default host all the vsenter servers the NSX managers as well as the fleet components such as V uh VCF operations and VCF automation and we can also have other components like uh NSX edge clusters running in there but the point being that the manager domain is where we host the infrastructure components or the infrastructure management components that are used to manage the private cloud. And so we put those in that first cluster um that first the first cluster in the management domain. And so that's the significance of the management domain.
Now when we want to go in and we want to start deploying workloads in our private cloud, we look at the data center as a pool of capacity represented here on the slide as the inventory. And now if I want to go in and deploy some workloads, say I have some some traditional VM based workloads, I want to go in and create a workload domain for that. So I'll go in and I'll create a production cluster. And then maybe I have some developers who are wanting to do some Kubernetes work. And I maybe have some people wanting to look at using private AI and they want to run this all on the infrastructure that I own and manage inside the data center. So I go out and I create these workload domains. So here I've created three VI or virtual infrastructure workload domains. one for production, one for for private AI, one for Kubernetes. And again, each of these is isolated behind its own vsenter server. Each has its own pool of storage, separate networking, um, and it's it's a independent pool of capacity that's available for hosting workloads.
Now, in addition, I can scale these separately as well. So, for example, here I have my private AI, but it's only got two servers in it. And maybe um, after I do initial set test, I realize, hey, I need more capacity in my private AI workload domain. in that first cluster. So what I can do is I can go back to my data center where I can provision some more resources in the data center and put those in inventory and then I can go in and use the automation to basically expand that private AI uh workload domain by adding host to that existing cluster. So this is just a quick example to kind of underscore this concept of a workload domain and how we can basically provision workload domains. Now I'll just take a moment to kind of underscore that here everything's a single cluster but in reality a workload domain could have one or more clusters up to vster maximums. So uh you can scale up quite large um with VMware private cloud based on VMware cloud foundation uh by leveraging this concept of workload domains and uh scaling to a large number of clusters behind them.
Now in addition, I've touched on this before, but uh when we look at these workload domains, we have to understand too that workload domains uh they don't always run in the data center. Um sometimes they need to be stretched across data centers, you know, or what we refer to as availability zones in a stretch topology. And we do have support for VSAN stretch clusters and sometimes we need may need to run these out at the edge as well. And we can also uh deploy cloud foundation in the public cloud in order to have cloud foundation running in the public cloud as well. But the point being here that with workload domains we have this ability to go in and using automation to stand up this standardized repeatable pool of infrastructure that can can then be managed and scaled individually and we can do this in a way that's stretched across data centers for high availability data protection as a VSAN stretch cluster as well as out to remote sites for supporting edge use cases or retail use cases or things like that.
Okay, so that's the concept of a workload domain. Now the second concept we need to get a be aware of is this idea of a VCF instance. So everything I've talked about so far with having a VCF management domain with one or more virtual infrastructure workload domains that represents a VCF instance. Each VCF instance is going to be designated by having a a single management domain. And as we've seen you can go into a VCF instance and you can add additional VI workload domains uh in order to help scale that up. And of course in this management domain and this VI workload domain you can have many clusters as well. Okay. So that's a VCF instance.
Now with VCF9 we're introducing a new term called a VCF fleet. And essentially what a VCF fleet is is it's a collection of one or more VCF instances. And what makes a fleet unique is that the fleet is where we run the fleet level components that span across VCF instances. This includes VCF operations and VCF automation. So while I can have a single VCF operations instance and a single VCF automation instance managing multiple VCF instances. So and then that way I can scale out and as I deploy in multiple locations I can deploy a fleet in my first data center. I can deploy a fleet in my second data center, a fleet in my third data center and then I can basically have these fleets acting as my VCF private cloud. So again, the workload domain, the VCF instance and the fleet. So I kind of did that from a bottom up, but if you look at it from a top down approach, we start by deploying a VCF fleet. That VCF fleet is comprised of one or more VCF instances. And those VCF instances are comprised of one or more workload domains. So that's the terminology. So hopefully we're we're clear on those uh components and um and how they are kind of relating and how we can build the private cloud using those.
Now we'll get into a little bit more detail around how we deploy the clusters and inside these workload domains. So there's a couple of options here. So one of the options that we have is when we stand up a new VCF instance. Um I can basically have a separate management domain where I host those infrastructure components that I mentioned earlier, the vscenter server, the NSX manager, uh my operations, my automation. I can put those in that management domain and I can leave that management domain dedicated for those infrastructure components. Thus ensuring that I I have separation of my management from my compute workloads. making sure that I have resources dedicated to each and then I can go in and create virtual infrastructure workload domains to host those user workloads or those compute workloads in my environment. And so this is the default architecture. Traditionally, we've called this the standard architecture, but it's we do have flexibility. And one of the themes you'll hear as we go through this presentation on VCF9 is this idea of flexibility and meeting customers where they are and giving them flexibility in how they deploy Cloud Foundation.
Because in addition to having this standard topology that I've just discussed, we can also go in and do what we call a consolidated deployment where maybe I have a smaller deployment or maybe I want to start small and then scale out. So maybe I don't want to start with two domains. I just want to start with one domain, but I want to have enough host in that domain to maybe I could put some my infrastructure on some host, my compute workloads on other hosts. I can basically run them together on the same domain. And that's definitely doable. And that's what we call this consolidated uh architecture. And this is where you basically deploy a VCF instance with a single manager domain and then you use resource pools to provide isolation between the infrastructure components and the compute components. And this works great um particularly in some of the smaller use cases uh maybe some of the remote edge use cases uh but again both are viable options and uh it's you know there for our customers to kind of look and decide which option would best meet their needs.
Now in addition to being able to deploy um the different the standard architecture the consolidated architecture we also have different ways of providing availability for the clusters that make up our workload domains. So for example, by default we will deploy all the clusters in a single rack. Okay. So this has some benefits. Uh you put everything in a single rack and particular if you're using something like VSAN where um you have the hypercon conversion infrastructure and you're using the storage in there all the east west storage traffic is going to be confined within the rack. So you're not sending a lot of your storage data up to the top rack switches and out across um the top rack switches out across the spine. You're keeping that all contained within the rack. So there's some some benefits to that. However, the disadvantage to that of course is what happens if I lose a rack? Well, if I lose a rack, I would lose my entire cluster. So we do have the ability to support uh cross rack deployments as well where I can take a workload domain, I can take a cluster and a workload domain and I can span that across racks. Thus, if I lose a single rack, I can make sure that I have resiliency in my fault domains as configured in VSAN in order to ensure that I can survive a rack failure. And of course, as the diagram is showing here, I can mix the two. I can have some clusters in one rack, other clusters spanning across racks. But again, the point here is I have flexibility. The customer has flexibility in order to choose which deployment model will work best for them.
Now in addition to weighing concern being concerned about rack resiliency, some customers may have u multiple data centers in a close proximity to each other and they may want to take a step further and introduce uh stretch clustering with VSAN stretch clusters where they basically stretch a cluster across availability zones. So here you'll see we've taken uh that workload domain two. We've added another cluster that is stretched across Iraq and availability zone one and a rack in availability zone 2. Thus providing a higher level of data protection by allowing us to uh survive a larger scale outage within a single data center or single data center hall and by stretching that across to another availability zone. In addition to the resilience that was built in, we also have support for VSAN storage clusters. So this is where I can build a storage cluster and I can have that comprised inside of one rack and then I can mount the storage provided by that storage cluster off into other clusters running on other racks. So as you can see when it comes to the workload domain and cluster topologies we have a lot of options. We have a lot of flexibility and so there's a um so we could definitely go in and satisfy pretty much most customer use cases in the sense of do they want to separate compute for management? Do they want to run together? Are they worried about rack resiliency? Do they want to spread across racks? Do they want to stay within a rack? Do they want stretch clusters? And are they looking at something like uh VSAN storage clusters? Um regardless of what they're looking for, we have uh the the the support for a topology that will meet those needs.
And taking this a step further, you know, we looked at within the data center, but now let's talk about at remote clusters or remote sites. Uh so we go out and we're we're outside the data center now and maybe we have some remote sites and maybe we have just a small number of remote sites and we want to put a separate workload domain out at each of these sites and we want this workload domain to be kind of self-sufficient independent. Um but we want to be able to centrally manage it from the SDC manager and from VCF operations. So we can definitely do that uh where we can just go in and put a cluster at each remote location and centrally manage that. In addition, we can go in and we can take that a step further and we can go out and we can have remote sites where we have multiple clusters. Um and um we we can pick and choose the topology we want whether the vsenter server runs in the main data center at the central site or whether the vsenter server is going to run at the remote site. Um of course there's implications with each of these decisions um being uh primarily around the type of networking that you're using um the location of the vsenter server and the ability to scale and scale up and scale out. And so there there are some uh pros and cons with each approach, but the point being that as your customers looking at their remote site needs uh they look at their need for how do I manage this? How am I going to scale this? uh they can basically choose an architecture that works well for them and keep in mind their implications on those decisions as it may influence the type of networking they use or it may influence uh how much bandwidth or latency requirements are are needed and the availability of those as well. So uh the point here being again flexibility and the ability to basically support deploying VCF at the edge and these remote topologies uh using a number of different supported topologies with cloud foundation.