another consideration. When we're talking about servers as many counts, we cluster servers. We want multiple physical devices. Acting is a single logical entity, a single logical unit. So of course, that gives us, you know, the
redundancy. It gives us load balancing in many instances. And we have a lot of resource. Is that our working together? So we get tremendous capability in power.
We have to think about things like what our limitations are. We may set reservations for specific host to specific resource is, um, you know, some software is allowed to, you know, has the capability of load balancing or provisioning
based on the priority like void traffic, needing quality of service and needing that priority,
uh, we make sure the resource is air scheduled if we anticipate there being a conflict where there would be a large amount of traffic. You know, clustering. Really. The two big things that we look for from clustering is redundancy for fault, tolerance and load balancing. So scheduling the load scheduling service's
running at certain times or access to those service is
Now, the last two bullet points your clustered hosts are either going to be tightly coupled or usefully coupled. And when we talk about tight coupling their own the same
physical plane, meaning they share the same physical link, they're on the same physical network. So you can imagine being on the same physical network. We get a lot more speed, we get higher performance. What? We don't have. This flexibility, though,
when we look at a loosely coupled network that's distributed, and that same cluster may be built of servers in multiple locations, and in that case we have the ease of adding additional components without having to be into specific physical location. So tight coupling on the same
physical network loose coupling, not
they both have their benefits.