2 hours 58 minutes
Hi, You are watching the, um Lavey sphere. Lesson one virtualization 11
By the end of this video, you'll learn how servers were used. In the pre federalization era, however, authorization came to be and most importantly, what problems it was set to solve.
Now let's begin.
We're back in the 19 nineties, when virtualization was not yet mainstream.
And here's our friend John. He's a fresh graduate, and he has just been hired by a new tech company.
His task is to install and manage three different services
a Web service, an email service and a database service.
Well, John will not reinvent the wheel. He'll just do what everybody has done for over a decade.
He takes a server, installs a server operating system, and then, on top of that, he installs his three services.
In a few hours. John's masterpiece is up and running.
This architecture's called application consolidation because many applications are running within the same seven.
But a few hours later, a new database security patch is out
and must be installed. Asper, the vendor recommendation So John is up for it.
Get downloads and installed the patch update at the end of which the operating system asks for a reboot. Poor John hesitates to pull the trigger because he bloody well knows that this will bring down the email service. End the Web service as well.
But he's in luck because his masterpiece is not yet put into production. So he does pull the trigger and gets on with his life.
But it bothers him.
What if this happened in a production environment?
What if the database experiences performance degradation because of the other two services?
So John realizes how fragile application consolidation is
updates and patch roll ups can cause destruction across all the services running on the same server.
But John Easy, proactive kid his stays up all night and reads about another architecture called application Isolation.
The next day, he tries to convince the finance team to buy two additional service.
He explains that he wants to move the email and Web services each to a different server in order to avoid performance issues, support issues with defenders and service disruption in case off a reboot.
Clever, however, the finance team is far from being convinced because new servers equals new capital expenditure,
which includes additional maintenance contracts, less space in the server room and power consumption for operation and cooling.
To support his request, John goes on to say that many companies out there are doing the same. It's a shame to fall behind, isn't it?
Eventually, everyone agrees that they have no choice but to go with the purchase.
So John wins, but he'll have to wait for a few days to get his to toys
when they finally arrive. He spent several hours setting the OS ready,
and then he finally moves the Web service and the email service.
Good job Now, every services running on its own physical server.
Later on, a new major update for the email application is out. So John confidently downloads installed. The update and reboots is over. Except that this time only the email services down. And there's no impact whatsoever on either the Web or the database services.
We call this application isolation because each service is isolated from the others.
So John is happy.
Jones boss is happy,
and everyone is
application. Isolation proves to be a success.
It is put into production, and the company sticks with it.
Then one morning,
John walks into the server room and finds that the database ever is offline.
After several unsuccessful attempts to bring it online, it appears to be a hardware failure.
Luckily, John has been faithfully performing backups off the database ever since it was put into production
and eventually retrieves a backup that dates back to only six hours.
Now he has to quickly performer restore on another server until the maintenance team takes care off the damage server.
But there is no spare. Sever
John decides to restore toe a regular machine as a quick work around to minimize downtime
after restoring, the computer refuses to boot.
In fact, John is unaware of the fact that unless he restores into the same server were at least server with identical hardware and mother board, his backup image is unusable. This is due to the fact that the operating system installs hardware specific privates.
And guess what?
These drivers get included in the pack of image
and when you restore into another hardware your system boots and finds hardware for which it does not have any drivers and it refuses to cooperate.
So John is as down as it's been Lovat servant, but he's learned a valuable thing.
Portability off a system with all the application data into another machine. Hardware is just a nightmare. So for now, his only option is to, well, wait for the maintenance team to save the day. Meanwhile, John has been monitoring his three servers every day and notices that none of them
ever exceeds 15% of resource consumption.
What a waste of processing power, he thinks to himself.
Application isolation comes at a cost, which is the under utilisation off computing resources.
This will become known as service Brawl.
John keeps a notebook at work where he writes down important things he's learned so far, and he summarized them like so.
Application consultation causes performance issues, service disruption and may avoid your support contracts.
The operating system is bound for the hardware, which makes system portability to a different hardware. Very tricky.
And lastly, application isolation causes Senator sprawl.
After reading his notes, John asks himself naively,
Is it possible to achieve application consolidation and isolation at the same time and eliminate service brought?
Can we make the operating system independent from the underlying hardware and achieve system portability with ease?
Suddenly, John wakes up in the middle of the night and realizes he was dreaming.
Or was he?
Because somewhere at that time,
many groups of people have been working on bringing about such a solution.
Sometime in the early two thousands,
VM Ware released their first stable high provider, which is a new type of operating system that will revolutionize the I T world.
Here's where virtualization comes in.
Take a single bare metal servers
and install the hyper visor or the virtualization layer, as it is also called.
Now you can create what we call a virtual machine containing its own operating system and whatever application you choose to install.
In fact, you can create many virtual machines, each with its own operating system and application.
And guess what?
These federal machines are isolated from each other.
So whatever happens with virtual machine number two, for example, will not affect any other virtual machine and vice versa.
So these V EMS will share. The underlying resource is off physical server, so the hyper visors drop is to ultimately give every virtual machine it's portion off the hardware on which it will run.
So from the high improvisers standpoint,
each virtual machine appears as an application waiting to be scheduled on the hardware.
What's more, you can now move a virtual machine toe, another server that runs the same hyper visor without wondering about hardware compatibility because each virtual machine is completely independent off the physical hardware. That's because the hyper visor
presents generic drivers to the operating system off the VM.
John is blown away. He can now run all his three services on the same server.
This has huge implications on his server room,
one server to rule them all, which means better resource utilization.
One server to bring them all, which means consolidation
and one server to unbind them all, which means isolation.
So John returns to his notes.
It takes a closer look,
and it realizes he was not dreaming actual.
Now, if there's one thing you need to remember from this introduction, it is This
Ventre ization is born to make better use of hardware. Resource is through consolidation
while still maintaining isolation between applications.
Thanks for watching and also you in the next lesson