VCD RoundTable

Yves Sandfort: 00:00

Hello, and welcome. Oh, I thought Toby would come to my side, but then we actually move around a bit. We are trying a new format and actually doing it live outside. So it's going to be a bit more funny today. We are recording episode 27 of the VCD roundtable today from Germany, from the Petersburg.

Yves Sandfort: 00:19

For a long time, it's the first time that we are all in the same place, actually, again. And we have a few more technical topics. We know there have been changes on the cloud provider program, but we cover that in other videos. So let's stick with the technical parts. But before we get started, who are you?

Yves Sandfort: 00:37

Sasha.

Tobias Paschek: 00:38

Matthias is here. Tobias is here as well. Hello?

Yves Sandfort: 00:42

So Yves. What's the topic?

Matthias Eisner: 00:44

What's the topic, Sasha? You started with some messed up root certificates and the weird algorithm being used in a root CA whatever stuff? Yeah.

Sascha Schwunk: 00:54

So we had an customer calling us with expired certificates, and the customer created new certificates, uploaded it in the latest versions over the web UI, so not longer over the, yeah, console with SSH. And, yeah, after uploading the certificates, we can cannot access the system. So cloud director was more or less offline. And, yeah, then we figured out what is the problem, and just Toby solved it.

Matthias Eisner: 01:25

But what what's the problem?

Tobias Paschek: 01:26

What was what's the problem? The one of the funniest problem was that, yeah, it was not work working in Chrome. It was not working in Edge as well.

Yves Sandfort: 01:36

But,

Matthias Eisner: 01:37

Did it work in Firefox?

Tobias Paschek: 01:38

It was working in Firefox. And so we figured out, okay. Maybe there is something weird going on. And the weird thing what's what's going on with the release of, VCT 10 dot 5 dot 1, so latest, release. There is a change in the, open SSL behavior.

Tobias Paschek: 01:58

And if you are going to use an certificate based on an key in the root certificate, and that's the most important part, it is only there if you utilize the root certificate signed with a key. The certificate chain more or less from an, Edge and Chrome, perspective seems to be broken, and you are not able to load the website. So it is working, as you mentioned before, in Firefox, but it is not working in any kind of other browsers.

Matthias Eisner: 02:29

But what you could have done, what many companies are still doing, have you tried the good old Internet Explorer 11? No. No. And we are not utilizing here. Okay.

Matthias Eisner: 02:41

So, just just a a short fun statement because that what we see in companies a lot still some really old boxes with IE 11 and, oh, yeah. Let's try this one. Oh, it works with that. So let's stop troubleshooting because it's still working. So that's the the interesting root certificate issue, but our our How

Yves Sandfort: 03:01

do you get a bigger root certificate then? So how do you get a changed route certificate? Because that is nothing you actually demand by yourself. Which brings us to

Tobias Paschek: 03:12

the point, utilize, yeah, not not pro properly signed, to be honest, because the certificate was properly signed. But let's call it there are cheaper, certificates are available on the market, and there are not so cheap certificate in the market available. And, yeah, there is the change with the key. Alright.

Matthias Eisner: 03:36

Who buys cheap, buys double, pays double. I think that's that's the point behind it. Okay. Thanks on that one. Pretty interesting.

Matthias Eisner: 03:44

So next one is a technical topic around design cloud director design. So we are we're covering, like, what's better or how do you decide if you wanna do multi site with a single VCD instance or go into federation with multiple sites? So what are basic requirements and design decisions for that area in cloud directory? Because it's a very niche area, and I think not many are really considering, is it better to have multiple sites or multiple instances and even put federation on top.

Yves Sandfort: 04:16

Yeah. So before I get that, if Matthias is jumping around, it's because there are little insects behind him, and he is not used to be in the outside that much. To bump it. It's it's not that big. So coming coming back to the single versus multisite discussion, it's it's very typical when we start with new service providers that the demand is very often it's like, yeah.

Yves Sandfort: 04:36

We have so many sites. We wanna have one VCD on top of it to manage all of them. And that is typically where we start the whole discussion and try to figure out why exactly do you wanna do that. And very often, the result is, yeah, we wanna do that because if one side goes down so that the customers have the other side. And what you need to keep in mind, VCD is still running in one location.

Yves Sandfort: 04:57

Can we can certainly try to stretch VCD on top of it, but there are a lot of complications with that. So, in the end, the question is really when it comes down to availability, is a single site or a single VCD instance across multiple sites going to help you? And in most cases for that, the answer is going to be no. That's not going to solve any of your issues because VCD, if it's in the wrong site, might still be gone. So, that is one of the first things we need to we need to consider when we when we look at that.

Yves Sandfort: 05:28

The other things are more from a sizing perspective. That is where I would agree. That is not hitting the majority of service providers because it's not that many many who have 10,000 of VMs and actually hit any of the of the limits from that perspective. So, oh, that was so you see, it's a lot of fun with us outside, so we should do more outside. No.

Yves Sandfort: 05:50

But coming coming back to it, so doing this whole set up from an availability perspective is not necessarily going to bring you anything. So you really need to consider that. Where the argument, which then very often comes, but it's easier for customers to utilize resources from different sites. And then when you come to the point, it's like, but federation solves the same. So when we look at these scenarios, we very often get back to the point is, like, every, let's say and I always compare it with the AWS model or, Azure or something else where you have regions, and then you have availability zones within the region.

Yves Sandfort: 06:25

And very often, the design and scenario we come back with is that we say within one region, you have one VCD instance. Across regions, you have multiple. So if one region or one area, like, say, in the US Northeast would completely go down, you still have Southwest or something like that. And that way, it's easier to manage from that perspective. If there are specific demands, which comes up then very often, it's like, yeah, but we need to have customers who have one specific network stretched across.

Yves Sandfort: 06:55

From my perspective, the most important question then is often is like, how many customers are that really? How many networks are we talking about? And then when you dig into it, it's very often that it's not that many, actually. And you get, much easier to manage infrastructure if you work with a region and availability zone perspective because you also need to think about updates and other things like

Matthias Eisner: 07:18

that. And it's also it's a very interesting point if you talk about stretched networks and stuff because if you design and calculate it properly and you put a a real price tag behind the stretched network, Many customers are like, oh, yeah. In that case, I might not need that whole thing.

Yves Sandfort: 07:36

Parts of parts of that have changed now with the VCF licensing because in the past, that was the point where we had to explain everybody. We are now talking about n six enterprise. And that immediately bumped up the points dramatically. That has changed now because there is no difference from that perspective. It clearly will influence our edges and everything else, but it's not dramatically changing the pricing anymore.

Yves Sandfort: 08:00

So in the end, you are open from that discussion.

Matthias Eisner: 08:04

That's true. But that's that's directly into another interesting topic. So how does, like, multi instance VCD federated align with the underlying now VCF infrastructure? How so which design considerations, can be taken?

Yves Sandfort: 08:43

Oh, there it is again.

Tobias Paschek: 08:45

There and there it is again.

Matthias Eisner: 08:47

What do we do? IT.

Tobias Paschek: 08:51

So you can utilize the underlying, VCF instances inside your federation environment, but you must not, and that's the most important part. You if you have a multisite, VCF deployment, you can go there with an, multisite, VCD, but it is not necessarily needed. So if you have multiple sites inside the same VCF, you can still use, one single CloudDirect on top.

Matthias Eisner: 09:19

Or have one management domain per site VCD on top, federate VCD interest match across everything. I think NSX design will be a lot different in that scenario, but it's a very rare corner case, and that needs

Tobias Paschek: 09:35

to be solved aside. Also, if you would like to stretch networks. Depends if you are going with the with the part that you say you stretch the networks across domains. But HCX is part of the license. Yeah.

Tobias Paschek: 09:50

HCX is part of the license, for example. Absolutely.

Matthias Eisner: 09:56

You wanna add something?

Yves Sandfort: 09:58

No. Sasha, it's pretty quiet today. Yeah. No. But I think that's that's an important point to to consider from a from a design perspective.

Yves Sandfort: 10:08

So that is okay. So we now agree we have multiple regions. We have different BCD instances. So federation, what does federation actually do in the end? Do you wanna or you want to?

Matthias Eisner: 10:21

No. Not really, but I can't. So federation is just, like, adding more management instances to the whole equation. That's it. So I can log into site a, manage my workloads across all the different sites that CSP provides, but in the end, that's it.

Matthias Eisner: 10:37

So a federated VCD does not add any additional availability to the customer workloads. It just adds, different management entry points to access my virtual machine management. So, I think from a a product and packaging and marketing communication perspective, a CSP needs to be very careful because if we start marketing, like, we have a federated VCT across multiple sites, it's just management if and if, the the network links between the sites break, so they are not available anymore, I can't man I can't even access the other site or manage virtual machine virtual machines in different data centers.

Yves Sandfort: 11:23

But I think on the other side, once it's back up, it's actually back up again. So the the the good part out of it in contrast to having non federated environments where people need to learn the different addresses, etcetera. What you the only thing you need to think about as a service provider, whether you just provide URLs for the bless you. Whether you provide URLs for the different sites and just tell your customers, this is your primary site. This is what you connect to.

Yves Sandfort: 11:47

If that one fails, this is the secondary site. That way you get around the fact that you need a GSLB. Or if you wanna put a GSLB in front of it, whether it's, AVIFY, f 5, or anything else, that's totally up to you. Whether you do something fancy with DNS, which I would never necessarily really, consider for something that critical. But those are the different options you have.

Yves Sandfort: 12:09

And then you can actually use that, and the users can actually access everything from one side. It's more or less the same what you have with AWS, Azure, etcetera, where you can basically then switch between the different regions, and then you can utilize each individual region and, bring up the workloads and everything else from there, which also means you are not saving anything. So, for example, if you are sitting in the northeast and you're actually connecting to VCD northeast and you upload a file, it's not going to go first to northeast and then to southwest. It will still send everything directly to southwest because in the back end, that's exactly what it does. It's just from a UI perspective where you get the federation, into the system.

Yves Sandfort: 12:50

But I think that's overall, it's a good thing because it makes, VCD far more scalable, especially if you have a global setup. You are much more near to what the hyperscalers are offering. You can basically present all your different sites and everything else. Whereas with a single site VCD, you could potentially do the same as long as you stick within the 150 milliseconds latency to the vCenters. But in the end, it's also a very high risky game because if that one side is going to die, yes, we could stretch it across different availability zones.

Yves Sandfort: 13:22

But still, if that area is down, and we have all seen how hyperscalers, at least for a couple of hours or something like that, lose a complete region. Like, there are talks about always is, like, good friends don't tell people to use US, whatsoever at a very specific hyperscaler. And, that would still be a problem. So I think that's where a combination out of multisite and federation, makes everything a lot easier from that perspective.

Matthias Eisner: 13:52

But you mentioned GSLB in front of VCD just to access systems. What needs to be considered is the GSLB is not solving any of the customer northbound networking. So if you have a customer with workloads in different locations and sites and data centers, A VCD federation is not solving any of the northbound routing, interconnectivity, and other stuff. Maybe a few thoughts on that?

Tobias Paschek: 14:20

Yeah. More or less as you just mentioned, their network problems are still there. And then it more and more comes to the part, okay. Now we need to talk about, NSX federation as well. So if you federate your, cloud director, then you say, hey.

Tobias Paschek: 14:34

I would like to have, also, the same opportunity for my customers, then you need to talk about, federated n s six that you really can solve the whole northbound rule things. You're saying, hey. I go with data center groups, stretch across, multiple VCD instances, have the networks, have the edge, groups.

Matthias Eisner: 14:54

Local egress.

Tobias Paschek: 14:55

Local egress and stuff like this, which really brings us to more and more complexity.

Matthias Eisner: 15:00

Yeah. Yeah.

Sascha Schwunk: 15:02

And that shows us again that we need a good design if we when we start. So we need to define the requirements that the different service providers have, and we need to write down the design with all the pros and cons, and then we can take the decision if we need to go with the federated environment or within single environment per data center, whatever.

Matthias Eisner: 15:23

And that's very interesting, and and especially if we talk NSX federation and also Cloud Director Federation, if we start with the design, it's not at that end road. So it's not from the beginning taking decision, I go either single instance or federated for both, VCD and NSX. Later on, I can still change the existing infrastructure to a federated environment. Yes. It it's a migration scenario, but it's not like I have a 3 weeks downtime maintenance windows all over the place and other stuff.

Matthias Eisner: 15:52

It's just like I need to, prepare a proper migration plan and move the infrastructure over. It can be built side by side, and then you just migrate the workloads to the new network environment of the customer because that's actually something I played with one of our CSPs last week. So that's an very interesting game deciding, do we go with federation from the beginning or can we postpone a bit because we need to validate what the new customers will ask for.

Yves Sandfort: 16:22

Good. Anything else we need to cover? We could pull Fabian, and if he's not on the phone, he's walking behind us just to be in the video now. Okay. Anything we missed on multi site, single site, federation?

Matthias Eisner: 16:44

Always keep the latency in mind.

Yves Sandfort: 16:48

Okay. And then you had another topic, which was catalogs.

Matthias Eisner: 16:54

Yeah. Catalogs. Very interesting. So in in VCD, we have the catalogs, and we have local catalogs which a customer can create themselves, or we have central provider catalogs by CSPs for their customer hosting like templates or media files to enable operating system installations, especially with VCF because VCF enables us to deploy multiple workload domains, and oh, sorry, multiple clusters per workload domain. I'm still struggling with the names a bit.

Matthias Eisner: 17:26

Sorry for that. But if we think VCF, the the Broadcom way, each cluster has its own vSAN. So a vSAN is always local to a cluster. And if we add storage or the vSAN is the storage and we add a catalog on top from a service provider perspective, it could be hosted on the management cluster if it's part of the VCD or on one of the clusters in one of the remote domains. But you can mount an ISO to a virtual machine only if a host has access to the data store and if the ISO, the media pool which is hosted centrally by CSP is located on the vSAN, that's a weird situation because it's local to a single cluster.

Matthias Eisner: 18:06

So we need to design around central catalogs which storage to be used and we have with clusters a I can do it. I can do it. I can do it. It's called not called secondary storage. It's supplemental storage.

Matthias Eisner: 18:20

That's the name. So we can add supplemental storage. And if you design for centralized catalogs, design for additional supplemental storages for the clusters in the workload domains.

Sascha Schwunk: 18:34

Yeah. Good idea.

Matthias Eisner: 18:35

Thank you. Thanks.

Yves Sandfort: 18:37

And it's coming back why for many, many, many, many, many years. We always said catalogs are best stored on NFS storage because that's the easiest to attach to many more clusters because you don't have, node limits and stuff like that. So as long as, it's reasonable from a sizing perspective, NFS in many cases is still one of the best choices, to store. Plus, let's face it. I mean, yes, we have now vSAN and everything in place.

Yves Sandfort: 19:04

But in many cases, catalogs do not need high performance storage. And if we build clusters now with vSAN and everything else, I would always question is, like, shouldn't we keep the high performance storage for our customers and rather have some more decent storage for our catalog, especially if it's a service provider which we have from time to time who say is like, yeah, we wanna more or less store any Windows version, any any Linux version, any whatsoever on the catalog, then, that is, that is an important part. The other part with catalogs is, keep in mind, you can still, subscribe and synchronize them. But what you they have improved the synchronization a bit. Yeah.

Matthias Eisner: 19:46

They improved it massively. They improved massively because 20% of nearly 0 is a lot. Right? To improve the subs the publish and subscribe mechanism, it's more efficient compared to the previous versions. But still inside a single data center, go with the NFS route.

Matthias Eisner: 20:09

2 thoughts 2 technical thoughts on the NFS route. First, make sure every cluster accesses the NFS data store with the same protocol version. Do not mix 34.1, never ever, or you're interested in a very good surprise, go for it, but, don't mix those.

Yves Sandfort: 20:32

Interesting spot.

Matthias Eisner: 20:33

Yes. Very interesting. And secondly, if you add a supplemental storage for catalogs, please flip the pre provision on storage policy switch to make sure that all files will be stored on the right data store. It's a technical session.

Yves Sandfort: 20:51

Yes. Yeah. It's perfectly fine, but, you know, you can keep it.

Matthias Eisner: 20:54

I can keep it with catalogs. You can also use scripts to kind of migrate files between NFS data stores, and that's a cool thing in NFS. Question is, if you just do an NFS copy, how to get it back into cloud director because he's not aware that the ISO file remains on the NFS data store, but that can be solved. Exactly. But importing something from vCenter is sysadmin, but I'm always sysadmin.

Matthias Eisner: 21:23

Any thoughts on catalogs? No. Okay. Thank you. It's not.

Matthias Eisner: 21:29

Alright. So I think that will conclude today's VCD roundtable. We covered more technical topics as promised in the last episode. So let's do a a short closing round. Some famous last words.

Tobias Paschek: 21:42

Thank you. No. Not really. But, as we also, figured out, we will now go down the technical road in the future more and more because we have talked so much about licenses in the in the past. So we will now bring back the technical sessions, and let's see what we will do in the next episodes.

Tobias Paschek: 22:01

Thank you.

Matthias Eisner: 22:02

Yeah. Also, thanks for me for watching. Hope we had a few interesting topics. The neck one of the next ones will be maybe we do some NSX federation with VCD in a more detailed view.

Sascha Schwunk: 22:15

Yeah. So thank you for joining. So we will see you in the next, yeah, events. So we have service providers, Amit. We also run the architecture Zinc tank in the 1st week of June.

Sascha Schwunk: 22:27

So if you want to join us, contact us.

Matthias Eisner: 22:30

Austin, Texas.

Sascha Schwunk: 22:31

In Austin, Texas. Yeah. And in the days after, we we are on the CloudFest. So maybe if you are on the CloudFest

Matthias Eisner: 22:38

Austin, Texas.

Sascha Schwunk: 22:39

Ping us in, yeah, ping us, and we will meet in Austin, Texas.

Yves Sandfort: 22:45

So, yeah, as Asher mentioned, we will be in Austin, Texas. Also, if you have ever any questions or any topics which we should cover, please feel free, to drop us in the comments or actually ping one of us via social media, direct message, whatsoever, so that we can add that to the list. And, for those media streams where we can, we will add a link to the architecture think tank in the comments so that you can directly sign up for that one. For those in Europe who will not make it to the US, stay tuned. We will also run an architecture think tank later in the year somewhere in the EMEA region.

Yves Sandfort: 23:19

We are still working out location and time slot, but we will get that out to you very, very soon. Thank you for watching, and goodbye.