Virtualization and HA, Scalability
-
@dustinb3403 what do u mean 4 pieces i am dyslexic
-
This article is about SAN, but really applies equally to all external shared storage in the manner that your professor proposed:
-
Pretty much in any case of any piece of the triangle fails, you lose services.
Take any 1 away and something is gone / not functional until repaired or replaced.
-
Here is a video talking about why everyone is trying to take advantage of businesses, by trying to sell them a SAN that they clearly have no need for.
-
I've seen a lot of people (not in professional communities, of course, but this could easily come up in a buyer's community or in a uni class...) claim that anything a vendor is willing to sell them HAS to be a good idea, because, presumably, vendors are infallible and altruistic?
-
I know that this is a lot of material, but this is a really important subject, and one that you could go back to the uni and show not only that you know more than the class, but more than the professor and, very likely, more than the uni themselves.
-
Now what often happens in that a sales person will say "You can lose a server and everything will migrate to the second server.
And this can be true.
But what they aren't telling you is if you lose the base (storage server) or the switch or (both physical server 1 and 2) that everything is gone.
And what is worse is you may not have the available resources on physical server 2 to run the entire combined workload that was previously split among the 2 servers.
-
@dustinb3403 said in Virtualization and HA, Scalability:
Now what often happens in that a sales person will say "You can lose a server and everything will migrate to the second server.
And this can be true.
Right, we call this the "top down trick." It's a way of taking the architecture, which should be viewed from its side (showing the inverted pyramid triangle) and looking only from the top. Basically looking from the side is what engineers do, looking from the top is what end users do.
From the top, the inverted pyramid appears to be broad and stable, everything that the non-technical customer sees is that the servers, the one piece that they can physically grasp the purpose for, is "redundant" and "redundant" is a clever trick word that people assume means "reliable", but doesn't.
So non-technical customers can be easily convinced that they have something reliable, and that all of the extra cost is to magically make that reliability happen. When, in reality, they are looking from the wrong angle and all of the risks have been cleverly hidden until after the sale has been completed.
-
@kelsey said in Virtualization and HA, Scalability:
Now with Hyperconvergence, the above example uses local storage inside of physical host #1 and physcal host #2, using some kind of software (like StarWind vSAN or Microsoft's Storage Spaces Direct) that treats the storage in each Host as a single pool of shared storage. (like how in your picture the "storage server" is portrayed, but tha twould go away and would be inside of each physical host)
This way, you have no single point of storage failure.
If host 1 goes down, all data is also on host 2 where everything can continue running after the VMs fail over. Same with if Host2 goes down.
-
@scottalanmiller said in Virtualization and HA, Scalability:
@dustinb3403 said in Virtualization and HA, Scalability:
Now what often happens in that a sales person will say "You can lose a server and everything will migrate to the second server.
And this can be true.
Right, we call this the "top down trick." It's a way of taking the architecture, which should be viewed from its side (showing the inverted pyramid triangle) and looking only from the top. Basically looking from the side is what engineers do, looking from the top is what end users do.
From the top, the inverted pyramid appears to be broad and stable, everything that the non-technical customer sees is that the servers, the one piece that they can physically grasp the purpose for, is "redundant" and "redundant" is a clever trick word that people assume means "reliable", but doesn't.
So non-technical customers can be easily convinced that they have something reliable, and that all of the extra cost is to magically make that reliability happen. When, in reality, they are looking from the wrong angle and all of the risks have been cleverly hidden until after the sale has been completed.
And it seems as though the professor is looking from the top down, and not realizing this is all riding on the single, most fragile part of the whole thing.
In this graphic, what you want to be HA is the virtual machines. If the "storage server" dies, the whole thing crashes. The storage server is a single point of failure, and as others already mentioned, is also the most likely thing to fail and the most fragile part of the whole thing.
-
@tim_g said in Virtualization and HA, Scalability:
@scottalanmiller said in Virtualization and HA, Scalability:
@dustinb3403 said in Virtualization and HA, Scalability:
Now what often happens in that a sales person will say "You can lose a server and everything will migrate to the second server.
And this can be true.
Right, we call this the "top down trick." It's a way of taking the architecture, which should be viewed from its side (showing the inverted pyramid triangle) and looking only from the top. Basically looking from the side is what engineers do, looking from the top is what end users do.
From the top, the inverted pyramid appears to be broad and stable, everything that the non-technical customer sees is that the servers, the one piece that they can physically grasp the purpose for, is "redundant" and "redundant" is a clever trick word that people assume means "reliable", but doesn't.
So non-technical customers can be easily convinced that they have something reliable, and that all of the extra cost is to magically make that reliability happen. When, in reality, they are looking from the wrong angle and all of the risks have been cleverly hidden until after the sale has been completed.
And it seems as though the professor is looking from the top down, and not realizing this is all riding on the single, most fragile part of the whole thing.
Right, like an end user rather than like an IT person.
-
@scottalanmiller said in Virtualization and HA, Scalability:
@tim_g said in Virtualization and HA, Scalability:
@scottalanmiller said in Virtualization and HA, Scalability:
@dustinb3403 said in Virtualization and HA, Scalability:
Now what often happens in that a sales person will say "You can lose a server and everything will migrate to the second server.
And this can be true.
Right, we call this the "top down trick." It's a way of taking the architecture, which should be viewed from its side (showing the inverted pyramid triangle) and looking only from the top. Basically looking from the side is what engineers do, looking from the top is what end users do.
From the top, the inverted pyramid appears to be broad and stable, everything that the non-technical customer sees is that the servers, the one piece that they can physically grasp the purpose for, is "redundant" and "redundant" is a clever trick word that people assume means "reliable", but doesn't.
So non-technical customers can be easily convinced that they have something reliable, and that all of the extra cost is to magically make that reliability happen. When, in reality, they are looking from the wrong angle and all of the risks have been cleverly hidden until after the sale has been completed.
And it seems as though the professor is looking from the top down, and not realizing this is all riding on the single, most fragile part of the whole thing.
Right, like an end user rather than like an IT person.
Or as an IT Buyer rather than as an IT Pro.
-
@tim_g said in Virtualization and HA, Scalability:
@kelsey said in Virtualization and HA, Scalability:
Now with Hyperconvergence, the above example uses local storage inside of physical host #1 and physcal host #2, using some kind of software (like StarWind vSAN or Microsoft's Storage Spaces Direct) that treats the storage in each Host as a single pool of shared storage. (like how in your picture the "storage server" is portrayed, but tha twould go away and would be inside of each physical host)
This way, you have no single point of storage failure.
If host 1 goes down, all data is also on host 2 where everything can continue running after the VMs fail over. Same with if Host2 goes down.
Here's a nice diagram from StarWind, which I've taken without asking. Please forgive me @KOOLER
-
@scottalanmiller video here can help explain the difference between IT Buyers and IT Pros, but simply put Buyers don't need to know how everything is set to work together, that is the IT Pros job.
-
@tim_g hi is there a website about scalable for information
-
@kelsey said in Virtualization and HA, Scalability:
@tim_g hi is there a website about scalable for information
In a general sense, or related to a specific product or architecture?
-
@kelsey said in Virtualization and HA, Scalability:
@tim_g hi is there a website about scalable for information
I'm not sure what you're asking.
-
@kelsey said in Virtualization and HA, Scalability:
@tim_g hi is there a website about scalable for information
Pretty much any hyperconvergence vender will have info on their site.
-
So there's another way I don't think I've seen anyone mention. That's doing application level HA. Rather than relying on the hosts to replicate data between each other, you just run multiple instances of a service. Then you have some kind of scheduler decide where the VM needs to live. That could be a person (if you're manually building), your orchestration tool by just defining which machine you want it to run on, or programmatically (like with cloud infrastructure). Then you can use a service discovery tool like Consul to register that service and have it added to your load balancer. Consul also does health checks that you script (for instance if you get anything other than a 200 response from a site it's unhealthy) and then it will auto remove it from the pool of available systems.
-
There's also the container schedulers and service discovery tools like Kubernetes. You define how many pods you want running and Kubernetes handles where all of those should run and takes care of ensuring that many exist. If one goes down, it automatically brings another up in it's place.
