Hi, You are watching Veum. Ravi's Fear 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.
We're back in the 19 nineties, when veterans ation 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 managed three different service is
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 service is
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
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 and the Web service as well.
But he's in luck because of his masterpieces, not yet put into production. So he does pull the trigger and gets on with his life.
What if this happened in a production environment?
What if the database experiences performance degradation because of the other two? Service is
so John realizes how fragile application consolidation is
updates and patch roll ups can cause destruction. Across all, the service is running on the same server,
but John is a proactive kid. He stays up all night and reads about another architecture called application Isolation.
The next day, he tries to convince the finance team two by two additional service.
He explains that he wants to move the email and Web service is each toe 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 two toys
when they finally arrive. He spent several hours setting the OS ready, and then he finally moves the Web service and the E mail service.
Now every service is 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. It's ever except that this time only the e mail service is down. And there's no impact whatsoever on either the Web or the database. Service is.
We call this application isolation because each service is isolated from the others.
John's bosses happy,
application. Isolation proves to be a success.
It is put into production, and the company sticks with it.
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 perform a restore on another server until the maintenance team takes care off the damage server.
But there is no spare server.
John decides to restore to 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, or at least server with identical hardware and motherboard, his backup image is unusable.
This is due to the fact that the operating system installs hardware specific privates.
These drivers get included in the back 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 loving 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 underutilization 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 center 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.
Because somewhere at that time,
many groups of people have been working on bringing about such a solution.
Sometime in the early two thousands, of'em were 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 server
and installed the hyper visor or the rituals action 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.
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 PM's 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 V. M.
John is blown away. He can now run all his three service is on the same side.
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 realizes he was not dreaming. Actually,
Now, if there's one thing you need to remember from this introduction, it is this.
Veterans ation is born to make better use of hardware. Resource is through consolidation
while still maintaining isolation between applications.
Thanks for watching Andi. I'll see you in the next lesson.